commit 018831037aaaccbcd7a7586c862fb4717e9a8318
Author: io2020 <io2020@88.com>
Date:   Mon Jul 21 01:06:10 2025 +0800

    init: 初始化提交--源码学习笔记

diff --git a/Dubbo/01-Dubbo 面试题.md b/Dubbo/01-Dubbo 面试题.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/02-Dubbo 学习指南.md b/Dubbo/02-Dubbo 学习指南.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/03-Dubbo 源码分析-调试环境搭建.md b/Dubbo/03-Dubbo 源码分析-调试环境搭建.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/04-Dubbo 源码分析-项目结构一览.md b/Dubbo/04-Dubbo 源码分析-项目结构一览.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/05-Dubbo 源码分析-API 配置（一）之应用.md b/Dubbo/05-Dubbo 源码分析-API 配置（一）之应用.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/06-Dubbo 源码分析-API 配置（二）之服务提供者.md b/Dubbo/06-Dubbo 源码分析-API 配置（二）之服务提供者.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/07-Dubbo 源码分析-API 配置（三）之服务消费者.md b/Dubbo/07-Dubbo 源码分析-API 配置（三）之服务消费者.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/08-Dubbo 源码分析-属性配置.md b/Dubbo/08-Dubbo 源码分析-属性配置.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/09-Dubbo 源码分析-XML 配置.md b/Dubbo/09-Dubbo 源码分析-XML 配置.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/10-Dubbo 源码分析-注解配置.md b/Dubbo/10-Dubbo 源码分析-注解配置.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/11-Dubbo 源码分析-外部化配置.md b/Dubbo/11-Dubbo 源码分析-外部化配置.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/12-Dubbo 源码分析-核心流程一览.md b/Dubbo/12-Dubbo 源码分析-核心流程一览.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/13-Dubbo 源码分析-拓展机制 SPI.md b/Dubbo/13-Dubbo 源码分析-拓展机制 SPI.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/14-Dubbo 源码分析-线程池.md b/Dubbo/14-Dubbo 源码分析-线程池.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/15-Dubbo 源码分析-服务暴露（一）之本地暴露（Injvm）.md b/Dubbo/15-Dubbo 源码分析-服务暴露（一）之本地暴露（Injvm）.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/16-Dubbo 源码分析-服务暴露（二）之远程暴露（Dubbo）.md b/Dubbo/16-Dubbo 源码分析-服务暴露（二）之远程暴露（Dubbo）.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/17-Dubbo 源码分析-服务引用（一）之本地引用（Injvm）.md b/Dubbo/17-Dubbo 源码分析-服务引用（一）之本地引用（Injvm）.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/18-Dubbo 源码分析-服务引用（二）之远程引用（Dubbo）.md b/Dubbo/18-Dubbo 源码分析-服务引用（二）之远程引用（Dubbo）.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/19-Dubbo 源码分析-Zookeeper 客户端.md b/Dubbo/19-Dubbo 源码分析-Zookeeper 客户端.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/20-Dubbo 源码分析-注册中心（一）之抽象 API.md b/Dubbo/20-Dubbo 源码分析-注册中心（一）之抽象 API.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/21-Dubbo 源码分析-注册中心（二）之 Zookeeper.md b/Dubbo/21-Dubbo 源码分析-注册中心（二）之 Zookeeper.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/22-Dubbo 源码分析-注册中心（三）之 Redis.md b/Dubbo/22-Dubbo 源码分析-注册中心（三）之 Redis.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/23-Dubbo 源码分析-动态编译（一）之 Javassist.md b/Dubbo/23-Dubbo 源码分析-动态编译（一）之 Javassist.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/24-Dubbo 源码分析-动态代理（一）之 Javassist.md b/Dubbo/24-Dubbo 源码分析-动态代理（一）之 Javassist.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/25-Dubbo 源码分析-动态代理（二）之 JDK.md b/Dubbo/25-Dubbo 源码分析-动态代理（二）之 JDK.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/26-Dubbo 源码分析-动态代理（三）之本地存根 Stub.md b/Dubbo/26-Dubbo 源码分析-动态代理（三）之本地存根 Stub.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/27-Dubbo 源码分析-服务调用（一）之本地调用（Injvm）.md b/Dubbo/27-Dubbo 源码分析-服务调用（一）之本地调用（Injvm）.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/28-Dubbo 源码分析-服务调用（二）之远程调用（Dubbo）【1】通信实现.md b/Dubbo/28-Dubbo 源码分析-服务调用（二）之远程调用（Dubbo）【1】通信实现.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/29-Dubbo 源码分析-服务调用（二）之远程调用（Dubbo）【2】同步调用.md b/Dubbo/29-Dubbo 源码分析-服务调用（二）之远程调用（Dubbo）【2】同步调用.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/30-Dubbo 源码分析-服务调用（三）之远程调用（Dubbo）【3】异步调用.md b/Dubbo/30-Dubbo 源码分析-服务调用（三）之远程调用（Dubbo）【3】异步调用.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/31-Dubbo 源码分析-服务调用（三）之远程调用（HTTP）.md b/Dubbo/31-Dubbo 源码分析-服务调用（三）之远程调用（HTTP）.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/32-Dubbo 源码分析-服务调用（四）之远程调用（Hessian）.md b/Dubbo/32-Dubbo 源码分析-服务调用（四）之远程调用（Hessian）.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/33-Dubbo 源码分析-服务调用（五）之远程调用（WebService）.md b/Dubbo/33-Dubbo 源码分析-服务调用（五）之远程调用（WebService）.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/34-Dubbo 源码分析-服务调用（六）之远程调用（REST）.md b/Dubbo/34-Dubbo 源码分析-服务调用（六）之远程调用（REST）.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/35-Dubbo 源码分析-服务调用（七）之远程调用（WebService）.md b/Dubbo/35-Dubbo 源码分析-服务调用（七）之远程调用（WebService）.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/36-Dubbo 源码分析-服务调用（八）之远程调用（Redis）.md b/Dubbo/36-Dubbo 源码分析-服务调用（八）之远程调用（Redis）.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/37-Dubbo 源码分析-服务调用（九）之远程调用（Memcached）.md b/Dubbo/37-Dubbo 源码分析-服务调用（九）之远程调用（Memcached）.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/38-Dubbo 源码分析-调用特性（一）之回声测试.md b/Dubbo/38-Dubbo 源码分析-调用特性（一）之回声测试.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/39-Dubbo 源码分析-调用特性（二）之泛化引用.md b/Dubbo/39-Dubbo 源码分析-调用特性（二）之泛化引用.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/40-Dubbo 源码分析-调用特性（三）之泛化实现.md b/Dubbo/40-Dubbo 源码分析-调用特性（三）之泛化实现.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/41-Dubbo 源码分析-过滤器（一）之 ClassLoaderFilter.md b/Dubbo/41-Dubbo 源码分析-过滤器（一）之 ClassLoaderFilter.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/42-Dubbo 源码分析-过滤器（二）之 ContextFilter.md b/Dubbo/42-Dubbo 源码分析-过滤器（二）之 ContextFilter.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/43-Dubbo 源码分析-过滤器（三）之 AccessLogFilter.md b/Dubbo/43-Dubbo 源码分析-过滤器（三）之 AccessLogFilter.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/44-Dubbo 源码分析-过滤器（四）之 ActiveLimitFilter && ExecuteLimitFilter.md b/Dubbo/44-Dubbo 源码分析-过滤器（四）之 ActiveLimitFilter && ExecuteLimitFilter.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/45-Dubbo 源码分析-过滤器（五）之 TimeoutFilter.md b/Dubbo/45-Dubbo 源码分析-过滤器（五）之 TimeoutFilter.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/46-Dubbo 源码分析-过滤器（六）之 DeprecatedFilter.md b/Dubbo/46-Dubbo 源码分析-过滤器（六）之 DeprecatedFilter.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/47-Dubbo 源码分析-过滤器（七）之 ExceptionFilter.md b/Dubbo/47-Dubbo 源码分析-过滤器（七）之 ExceptionFilter.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/48-Dubbo 源码分析-过滤器（八）之 TokenFilter.md b/Dubbo/48-Dubbo 源码分析-过滤器（八）之 TokenFilter.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/49-Dubbo 源码分析-过滤器（九）之 TpsLimitFilter.md b/Dubbo/49-Dubbo 源码分析-过滤器（九）之 TpsLimitFilter.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/50-Dubbo 源码分析-过滤器（十）之 CacheFilter.md b/Dubbo/50-Dubbo 源码分析-过滤器（十）之 CacheFilter.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/51-Dubbo 源码分析-过滤器（十一）之 ValidationFilter.md b/Dubbo/51-Dubbo 源码分析-过滤器（十一）之 ValidationFilter.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/52-Dubbo 源码分析-NIO 服务器（一）之抽象 API.md b/Dubbo/52-Dubbo 源码分析-NIO 服务器（一）之抽象 API.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/53-Dubbo 源码分析-NIO 服务器（二）之 Transport 层.md b/Dubbo/53-Dubbo 源码分析-NIO 服务器（二）之 Transport 层.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/54-Dubbo 源码分析-NIO 服务器（三）之 Telnet 层.md b/Dubbo/54-Dubbo 源码分析-NIO 服务器（三）之 Telnet 层.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/55-Dubbo 源码分析-NIO 服务器（四）之 Exchange 层.md b/Dubbo/55-Dubbo 源码分析-NIO 服务器（四）之 Exchange 层.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/56-Dubbo 源码分析-NIO 服务器（五）之 Buffer 层.md b/Dubbo/56-Dubbo 源码分析-NIO 服务器（五）之 Buffer 层.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/57-Dubbo 源码分析-NIO 服务器（六）之 Netty4 实现.md b/Dubbo/57-Dubbo 源码分析-NIO 服务器（六）之 Netty4 实现.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/58-Dubbo 源码分析-NIO 服务器（七）之 Netty3 实现.md b/Dubbo/58-Dubbo 源码分析-NIO 服务器（七）之 Netty3 实现.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/59-Dubbo 源码分析-HTTP 服务器.md b/Dubbo/59-Dubbo 源码分析-HTTP 服务器.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/60-Dubbo 源码分析-序列化（一）之总体实现.md b/Dubbo/60-Dubbo 源码分析-序列化（一）之总体实现.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/61-Dubbo 源码分析-序列化（二）之 Dubbo 实现.md b/Dubbo/61-Dubbo 源码分析-序列化（二）之 Dubbo 实现.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/62-Dubbo 源码分析-序列化（三）之 Kryo 实现.md b/Dubbo/62-Dubbo 源码分析-序列化（三）之 Kryo 实现.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/63-Dubbo 源码分析-服务容器.md b/Dubbo/63-Dubbo 源码分析-服务容器.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/64-Dubbo 源码解析-集群容错（一）之抽象 API.md b/Dubbo/64-Dubbo 源码解析-集群容错（一）之抽象 API.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/65-Dubbo 源码解析-集群容错（二）之 Cluster 实现.md b/Dubbo/65-Dubbo 源码解析-集群容错（二）之 Cluster 实现.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/66-Dubbo 源码解析-集群容错（三）之 Directory 实现.md b/Dubbo/66-Dubbo 源码解析-集群容错（三）之 Directory 实现.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/67-Dubbo 源码解析-集群容错（四）之 LoadBalance 实现.md b/Dubbo/67-Dubbo 源码解析-集群容错（四）之 LoadBalance 实现.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/68-Dubbo 源码解析-集群容错（五）之 Merger 实现.md b/Dubbo/68-Dubbo 源码解析-集群容错（五）之 Merger 实现.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/69-Dubbo 源码解析-集群容错（六）之 Configurator 实现.md b/Dubbo/69-Dubbo 源码解析-集群容错（六）之 Configurator 实现.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/70-Dubbo 源码解析-集群容错（七）之 Router 实现.md b/Dubbo/70-Dubbo 源码解析-集群容错（七）之 Router 实现.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/71-Dubbo 源码解析-集群容错（八）之 Mock 实现.md b/Dubbo/71-Dubbo 源码解析-集群容错（八）之 Mock 实现.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/72-Dubbo 源码解析-优雅停机.md b/Dubbo/72-Dubbo 源码解析-优雅停机.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/73-Dubbo 源码解析-日志适配.md b/Dubbo/73-Dubbo 源码解析-日志适配.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/74-Dubbo 源码分析-集成 Spring Cloud.md b/Dubbo/74-Dubbo 源码分析-集成 Spring Cloud.md
new file mode 100644
index 0000000..e69de29
diff --git a/Dubbo/file-create.py b/Dubbo/file-create.py
new file mode 100644
index 0000000..a412975
--- /dev/null
+++ b/Dubbo/file-create.py
@@ -0,0 +1,27 @@
+import os
+import pyperclip
+
+# 获取当前脚本的路径
+script_dir = os.path.dirname(os.path.abspath(__file__))
+
+# 从剪贴板获取文件名列表，假设每行一个文件名
+file_names = pyperclip.paste().strip().split('\n')
+
+# 遍历文件名列表，为每个文件名添加排序前缀并创建文件
+for index, file_name in enumerate(file_names, start=1):
+    # 去除文件名两端的空白字符
+    file_name = file_name.strip()
+    
+    # 添加排序前缀和.md后缀
+    file_name_with_prefix = f"{index:02d}-{file_name}.md"  # 这里使用3位数的排序前缀，可以根据需要调整
+    
+    # 构建文件的完整路径
+    file_path = os.path.join(script_dir, file_name_with_prefix)
+    
+    # 创建文件
+    with open(file_path, 'w') as file:
+        # 如果需要写入初始内容，可以在这里添加
+        # 例如：file.write("This is the content of the file.")
+        pass  # 如果不需要写入内容，则使用pass
+
+print(f"Files created successfully in {script_dir}")
\ No newline at end of file
diff --git a/Dubbo/tmp.txt b/Dubbo/tmp.txt
new file mode 100644
index 0000000..790ae94
--- /dev/null
+++ b/Dubbo/tmp.txt
@@ -0,0 +1,74 @@
+Dubbo 面试题
+Dubbo 学习指南
+Dubbo 源码分析-调试环境搭建
+Dubbo 源码分析-项目结构一览
+Dubbo 源码分析-API 配置（一）之应用
+Dubbo 源码分析-API 配置（二）之服务提供者
+Dubbo 源码分析-API 配置（三）之服务消费者
+Dubbo 源码分析-属性配置
+Dubbo 源码分析-XML 配置
+Dubbo 源码分析-注解配置
+Dubbo 源码分析-外部化配置
+Dubbo 源码分析-核心流程一览
+Dubbo 源码分析-拓展机制 SPI
+Dubbo 源码分析-线程池
+Dubbo 源码分析-服务暴露（一）之本地暴露（Injvm）
+Dubbo 源码分析-服务暴露（二）之远程暴露（Dubbo）
+Dubbo 源码分析-服务引用（一）之本地引用（Injvm）
+Dubbo 源码分析-服务引用（二）之远程引用（Dubbo）
+Dubbo 源码分析-Zookeeper 客户端
+Dubbo 源码分析-注册中心（一）之抽象 API
+Dubbo 源码分析-注册中心（二）之 Zookeeper
+Dubbo 源码分析-注册中心（三）之 Redis
+Dubbo 源码分析-动态编译（一）之 Javassist
+Dubbo 源码分析-动态代理（一）之 Javassist
+Dubbo 源码分析-动态代理（二）之 JDK
+Dubbo 源码分析-动态代理（三）之本地存根 Stub
+Dubbo 源码分析-服务调用（一）之本地调用（Injvm）
+Dubbo 源码分析-服务调用（二）之远程调用（Dubbo）【1】通信实现
+Dubbo 源码分析-服务调用（二）之远程调用（Dubbo）【2】同步调用
+Dubbo 源码分析-服务调用（三）之远程调用（Dubbo）【3】异步调用
+Dubbo 源码分析-服务调用（三）之远程调用（HTTP）
+Dubbo 源码分析-服务调用（四）之远程调用（Hessian）
+Dubbo 源码分析-服务调用（五）之远程调用（WebService）
+Dubbo 源码分析-服务调用（六）之远程调用（REST）
+Dubbo 源码分析-服务调用（七）之远程调用（WebService）
+Dubbo 源码分析-服务调用（八）之远程调用（Redis）
+Dubbo 源码分析-服务调用（九）之远程调用（Memcached）
+Dubbo 源码分析-调用特性（一）之回声测试
+Dubbo 源码分析-调用特性（二）之泛化引用
+Dubbo 源码分析-调用特性（三）之泛化实现
+Dubbo 源码分析-过滤器（一）之 ClassLoaderFilter
+Dubbo 源码分析-过滤器（二）之 ContextFilter
+Dubbo 源码分析-过滤器（三）之 AccessLogFilter
+Dubbo 源码分析-过滤器（四）之 ActiveLimitFilter && ExecuteLimitFilter
+Dubbo 源码分析-过滤器（五）之 TimeoutFilter
+Dubbo 源码分析-过滤器（六）之 DeprecatedFilter
+Dubbo 源码分析-过滤器（七）之 ExceptionFilter
+Dubbo 源码分析-过滤器（八）之 TokenFilter
+Dubbo 源码分析-过滤器（九）之 TpsLimitFilter
+Dubbo 源码分析-过滤器（十）之 CacheFilter
+Dubbo 源码分析-过滤器（十一）之 ValidationFilter
+Dubbo 源码分析-NIO 服务器（一）之抽象 API
+Dubbo 源码分析-NIO 服务器（二）之 Transport 层
+Dubbo 源码分析-NIO 服务器（三）之 Telnet 层
+Dubbo 源码分析-NIO 服务器（四）之 Exchange 层
+Dubbo 源码分析-NIO 服务器（五）之 Buffer 层
+Dubbo 源码分析-NIO 服务器（六）之 Netty4 实现
+Dubbo 源码分析-NIO 服务器（七）之 Netty3 实现
+Dubbo 源码分析-HTTP 服务器
+Dubbo 源码分析-序列化（一）之总体实现
+Dubbo 源码分析-序列化（二）之 Dubbo 实现
+Dubbo 源码分析-序列化（三）之 Kryo 实现
+Dubbo 源码分析-服务容器
+Dubbo 源码解析-集群容错（一）之抽象 API
+Dubbo 源码解析-集群容错（二）之 Cluster 实现
+Dubbo 源码解析-集群容错（三）之 Directory 实现
+Dubbo 源码解析-集群容错（四）之 LoadBalance 实现
+Dubbo 源码解析-集群容错（五）之 Merger 实现
+Dubbo 源码解析-集群容错（六）之 Configurator 实现
+Dubbo 源码解析-集群容错（七）之 Router 实现
+Dubbo 源码解析-集群容错（八）之 Mock 实现
+Dubbo 源码解析-优雅停机
+Dubbo 源码解析-日志适配
+Dubbo 源码分析-集成 Spring Cloud
\ No newline at end of file
diff --git a/jdk/01-JDK 源码解析-调试环境搭建（一）入门.md b/jdk/01-JDK 源码解析-调试环境搭建（一）入门.md
new file mode 100644
index 0000000..9bafc45
--- /dev/null
+++ b/jdk/01-JDK 源码解析-调试环境搭建（一）入门.md	
@@ -0,0 +1,65 @@
+# 精尽 JDK 源码解析 —— 调试环境搭建（一）入门
+
+> 本文，我们在原来文章 [《JDK 源码解析 —— 调试环境搭建》](http://vip.iocoder.cn/JDK/build-debugging-environment/?self) 的基础上，从 JDK11 调整成 JDK13 ，并使用 Git 取代 Mercurial 获取 OpenJDK 的源码。
+>
+> 在艿艿写完 [《精尽 JDK 源码解析 —— 调试环境搭建（二）进阶》](http://svip.iocoder.cn/JDK/build-debugging-environment-more?self) 之后，艿艿突然发现，从 Git 克隆的是 OpenJDK14 的 EA（Early Access抢 先体验版）。暂时不就纠正，反正胖友要记得，整个系列是基于 **OpenJDK14 的 EA** 写的。
+
+# 0. 友情提示
+
+JDK 源码的调试环境，实际上暂时没有特别好的方案。
+
+因为，我们程序运行以来 JDK ，但是我们如果在 JDK 上增加源码相关的注释，就会导致代码行数的错乱。所以，艿艿目前的想法是，如下两个步骤：
+
+- 1、从官方的 Mercurial 获取 OpenJDK 源码，在上面添加源码注释。
+
+  > 获取 OpenJDK 源码的方式，一共有三种
+  >
+  > - 1、从 http://jdk.java.net/ 网站上，直接下载源码。
+  > - 2、使用 Mercurial ，从 http://hg.openjdk.java.net/jdk/ 克隆对应版本的源码。例如说，我们在 [《JDK 源码解析 —— 调试环境搭建》](http://vip.iocoder.cn/JDK/build-debugging-environment/?self) 文章中，就是这么干的。
+  > - 3、使用 Git ，从 https://github.com/openjdk/jdk克隆对应版本的源码。该仓库就是 http://hg.openjdk.java.net/jdk/ 的镜像，方便我们使用我们所熟悉的 Git 而不是 Mercurial 。在本文，我们就会从该仓库克隆。
+
+- 2、自己搭建一个项目，使用 JDK13 ，然后进行调试。
+
+# 1. 获取 OpenJDK 源码
+
+从官方仓库 https://github.com/openjdk/jdk Fork 出属于自己的仓库。为什么要 Fork ？既然开始阅读、调试源码，我们可能会写一些注释，有了自己的仓库，可以进行自由的提交。😈
+
+使用 IntelliJ IDEA 从 Fork 出来的仓库拉取代码。因为 JDK 的源码比较大，所以拉取会花费漫长时间，耐心等待下。
+
+> 如果拉取比较慢，也可以考虑使用 https://gitee.com/zhijiantianya/jdk 地址。这个是艿艿使用 Gitee 对 https://github.com/openjdk/jdk 做的镜像。毕竟，Github 对国内的网络，不是非常友好。
+
+拉取完成后，我们可以搜索想看的类。例如说，HashMap 如下图所示：[![HashMap](http://static.iocoder.cn/images/JDK/2019_01_01/01.jpg)](http://static.iocoder.cn/images/JDK/2019_01_01/01.jpg)HashMap
+
+如此，我们就可以愉快的在其上添加源码注释。
+
+> 可能胖友导入在 IDEA 看到的项目结构比较奇怪。可以先 IDEA 关闭 OpenJDK 项目，然后删除项目本地根目录下面 IDEA 相关的配置，最后再使用 IDEA 打开 OpenJDK 项目。
+
+# 2. 搭建项目调试
+
+① 下载 JDK
+
+从 https://www.oracle.com/technetwork/java/javase/downloads/jdk13-downloads-5672538.html 上，下载 Oracle JDK13 。
+
+虽然说，我们在 [「1. 获取 OpenJDK 源码」](https://svip.iocoder.cn/JDK/build-debugging-environment/#) 中下载的是 OpenJDK 的源码，但是我们使用 Oracle JDK13 作为调试环境，也是没啥问题的。因为，Oracle JDK 和 OpenJDK 绝大部分源码是相同的。
+
+> 如果想要纯粹以 OpenJDK 作为调试环境，可以参考 [《Mac 上的 JDK 多版本管理》](https://www.jishuwen.com/d/pm5V/zh-hk) 文章，使用 brew 安装对应版本的 OpenJDK 。
+
+② 搭建项目
+
+这个比较简单，就不重复赘述了。**需要注意的是，设置 Project SDK 要是 Oracle JDK13 噢**。
+
+还有一个注意点，IDEA 需要升级到 2019.2 或以上版本，因为 2019.2 才支持 JDK13 。
+
+> 友情提示：当然，胖友如果自己有精力，可以将**克隆的** OpenJDK13 **编译**出来，作为项目使用的 Project SDK 。
+
+③ 调试
+
+直接调试，这个无需多说列。
+
+例如说，艿艿就在 https://github.com/YunaiV/openjdk 项目下，创建了一个叫 `yunai` 的 Maven 项目，各种创建测试类，各种调试。
+
+# 666. 彩蛋
+
+2019 年的下半年，艿艿准备写写大家比较常用的 JDK 类的源码解析，希望对胖友有一些帮助。共勉，2019 ，加油！
+
+当然，可能会有胖友会有疑惑，目前 JDK8 版本才是主流，而艿艿为什么使用 JDK13 呢？虽然说，Oracle JDK8 某个版本（具体不太记得了）之后，需要更新，但是我们最终还是会不断更新版本。Java 的强大，不是因为 Oracle ，而是完善的整个社区体系。
\ No newline at end of file
diff --git a/jdk/02-JDK 源码解析-调试环境搭建（二）进阶.assets/01.png b/jdk/02-JDK 源码解析-调试环境搭建（二）进阶.assets/01.png
new file mode 100644
index 0000000..05ac5ce
Binary files /dev/null and b/jdk/02-JDK 源码解析-调试环境搭建（二）进阶.assets/01.png differ
diff --git a/jdk/02-JDK 源码解析-调试环境搭建（二）进阶.assets/02.png b/jdk/02-JDK 源码解析-调试环境搭建（二）进阶.assets/02.png
new file mode 100644
index 0000000..6f2a4e6
Binary files /dev/null and b/jdk/02-JDK 源码解析-调试环境搭建（二）进阶.assets/02.png differ
diff --git a/jdk/02-JDK 源码解析-调试环境搭建（二）进阶.assets/03.png b/jdk/02-JDK 源码解析-调试环境搭建（二）进阶.assets/03.png
new file mode 100644
index 0000000..c93d1b6
Binary files /dev/null and b/jdk/02-JDK 源码解析-调试环境搭建（二）进阶.assets/03.png differ
diff --git a/jdk/02-JDK 源码解析-调试环境搭建（二）进阶.md b/jdk/02-JDK 源码解析-调试环境搭建（二）进阶.md
new file mode 100644
index 0000000..67f0acf
--- /dev/null
+++ b/jdk/02-JDK 源码解析-调试环境搭建（二）进阶.md	
@@ -0,0 +1,200 @@
+# 精尽 JDK 源码解析 —— 调试环境搭建（二）进阶
+
+# 0. 概述
+
+在 [《精尽 JDK 源码解析 —— 调试环境搭建（一）入门》](http://svip.iocoder.cn/JDK/build-debugging-environment?self) 中，我们已经能够简单的调试。但是，有些跟我一样“杠”的胖友，我要调试 JDK 源码，还要使用自己**编译**出来的 OpenJDK 。
+
+对，所以本文，**我们就来自己编译 OpenJDK13 ，并使用它来调试**。
+
+另外，因为每个人编译 OpenJDK 碰到的问题都不同，所以艿艿尽量多贴一些艿艿自己碰到的每个问题时，参考的文章。
+
+还有一个，本文是基于 MacOS 系统。嘿嘿，因为手头暂时没有 Windows 的开发环境。
+
+# 1. 依赖工具
+
+## 1.1 编译源码
+
+在 [《精尽 JDK 源码解析 —— 调试环境搭建（一）入门》](http://svip.iocoder.cn/JDK/build-debugging-environment?self) 中，我们已经使用 Git 从 https://github.com/YunaiV/openjdk 克隆了 OpenJDK**13** 的源码，直接使用它。
+
+## 1.2 Xcode
+
+编译需要用到 Xcode 工具，一般情况下，我们都已经安装的。如果没有安装的胖友，记得安装下。T T 艿艿之前不小心卸载了，一脸懵逼。
+
+建议的话，打开 https://apps.apple.com/cn/app/xcode/id497799835?mt=12 地址，去 App Store 更新到最新版本。
+
+## 1.3 引导 JDK
+
+> 艿艿：如果嫌弃哔哔的有点长，可以看本小节最后一端。
+
+编译 OpenJDK 时，需要一个引导 JDK（Boot JDK）。具体原因，艿艿看了下 [《Ubuntu 下编译 openjdk8》](https://www.jianshu.com/p/8a53708dd08a) 文章：
+
+> 安装引导 jdk ，openjdk 的源码编译是需要引导 jdk 的，引导 jdk 需要比要编译的 openjdk 低一个版本，比如我们要编译 openjdk8 ，就需要 jdk7 来做引导 jdk ，可以是 openjdk7 ，也可以是 oraclejdk7 。
+>
+> 那么为什么需要引导 jdk 呢？我们知道 jdk 版本都是在前一个版本的基础上开发出来的，我们要编译的 openjdk8 在开发的时候，是需要用 jdk7 做环境的，在 jdk7 上做开发测试，是在 jdk7 的基础上开发出来的。
+
+但是艿艿自己在编译 OpenJDK13 本地时，并未安装 JDK12 在本地。在 configure 成功，看了下自动使用了本地的 Oracle JDK13 (`java version "13-ea" 2019-09-17 Java(TM) SE Runtime Environment (build 13-ea+33) Java HotSpot(TM) 64-Bit Server VM (build 13-ea+33, mixed mode, sharing) (at /Library/Java/JavaVirtualMachines/jdk-13.jdk/Contents/Home)`) 。所以艿艿就搜了下，在 [《编译 OPENJDK 小记》](https://juejin.im/entry/5b3cbfaee51d451914629415) 文章：
+
+> 还有一个比较坑的地方。以前编译过虚拟机的同学应该都知道，编译虚拟机需要一个 `boot jdk` ，即为引导jdk。这个 `boot jdk` 是如果要编译 1.8 版本的jdk，需要 1.7 版本的jdk。
+>
+> 但是笔者编译 `openjdk1.9` 的时候，总是报错 `boot jdk` 版本不对，非常蛋疼（笔者机器上装的1.8）。一开始我以为是路径不对，改了几次发现，其实编译会自动扫描 `JAVA_HOME` 下的jdk版本并且找一个合适的，在此提醒各位，如果发现有类似的问题，赶紧按照提示用 `brew cask install java` 下载一个最新版本的 jdk 就好了。
+
+所以呢，**引导 JDK 这步的安装，胖友可以先忽略**。在出现问题的时候，可以直接使用 `brew cask install java` 安装一个**最新版本**的 JDK ，也是可以引导成功的。
+
+## 1.4 autoconf
+
+```
+brew install autoconf
+```
+
+如果不安装 autoconf 的话，待会在 make 时会找不到配置文件。
+
+# 2. 开始编译
+
+## 2.1 configure
+
+在 OpenJDK 根目录下，执行命令如下：
+
+```
+# 这一句，仅仅是为了告诉胖友，一定要在根目录下
+$ pwd
+/Users/yunai/Java/openjdk13
+
+# 如下命令，才是正觉
+$ bash configure --enable-debug --with-jvm-variants=server --enable-dtrace
+```
+
+接着等待一会，如果出现如下日志，说明 configure 成功了：
+
+```
+Configuration summary:
+* Debug level:    fastdebug
+* HS debug level: fastdebug
+* JVM variants:   server
+* JVM features:   server: 'aot cds cmsgc compiler1 compiler2 dtrace epsilongc g1gc graal jfr jni-check jvmci jvmti management nmt parallelgc serialgc services shenandoahgc vm-structs'
+* OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64
+* Version string: 14-internal+0-adhoc.yunai.openjdk13 (14-internal)
+
+Tools summary:
+* Boot JDK:       java version "13-ea" 2019-09-17 Java(TM) SE Runtime Environment (build 13-ea+33) Java HotSpot(TM) 64-Bit Server VM (build 13-ea+33, mixed mode, sharing)  (at /Library/Java/JavaVirtualMachines/jdk-13.jdk/Contents/Home)
+* Toolchain:      clang (clang/LLVM from Xcode 11.0)
+* C Compiler:     Version 11.0.0 (at /usr/bin/clang)
+* C++ Compiler:   Version 11.0.0 (at /usr/bin/clang++)
+
+Build performance summary:
+* Cores to use:   12
+* Memory limit:   32768 MB
+```
+
+不过往往，都是会碰到一些报错。艿艿在如下列举了部分，胖友逐个对照排查。如果没有，可以在星球里留言提问。
+
+**报错 1**
+
+报错如下：
+
+```
+configure: error: No xcodebuild tool and no system framework headers found, use --with-sysroot or --with-sdk-name to provide a path to a valid SDK
+```
+
+> 参考文章 [《如何在 macOS 中编译 OpenJDK10 源代码》](https://blog.csdn.net/asahinokawa/article/details/82226093) 。
+
+输入如下命令：
+
+```
+sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
+```
+
+**报错 2**
+
+报错如下：
+
+```
+configure: error: Unable to determine SYSROOT and no headers found in /System/Library/Frameworks. Check Xcode configuration, --with-sysroot or --with-sdk-name arguments.
+```
+
+> 参考文章 [《build fails with OSX Mojave》](https://github.com/neovim/neovim/issues/9050) 。
+
+输入如下命令：
+
+```
+open /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg
+```
+
+## 2.2 make
+
+在 OpenJDK 根目录下，执行命令如下：
+
+```
+$ export LANG=C
+$ make all
+```
+
+接着好久一会，如果出现如下日志，说明 make 成功了：
+
+```
+Creating jdk image
+Creating CDS archive for jdk image
+Stopping sjavac server
+Finished building target 'all' in configuration 'macosx-x86_64-server-fastdebug'
+```
+
+到 `build` 目录下，我们来看看我们编译的 `java` 的版本：
+
+```
+$ build/macosx-x86_64-server-fastdebug/jdk/
+$ bin/java -version
+
+openjdk version "14-internal" 2020-03-17
+OpenJDK Runtime Environment (fastdebug build 14-internal+0-adhoc.yunai.openjdk13)
+OpenJDK 64-Bit Server VM (fastdebug build 14-internal+0-adhoc.yunai.openjdk13, mixed mode)
+```
+
+- **T T 有一点很尴尬，实际我们使用的是 OpenJDK14 的 EA（Early Access抢 先体验版）。**
+
+一般情况下，这步是不太会碰到报错，但是也可能会碰到一些报错。艿艿在如下列举了部分，胖友逐个对照排查。如果没有，可以在星球里留言提问。
+
+**报错 1**
+
+报错如下：
+
+```
+Undefined symbols for architecture x86_64:
+  "_objc_loadClassref", referenced from:
+      __ARCLite__load() in libarclite_macosx.a(arclite.o)
+ld: symbol(s) not found for architecture x86_64
+```
+
+> 参考文章 https://bugs.openjdk.java.net/browse/JDK-8231572
+
+删除 `Lib-java.base.gmk` 文件中的 `-fobjc-link-runtime` 代码。可以看看艿艿 Git 的[461da7026034fdd63df8a9776d0b11895f361523](https://github.com/YunaiV/openjdk/commit/461da7026034fdd63df8a9776d0b11895f361523) 提交。
+
+# 3. 使用调试
+
+**SDKs**
+
+在 IDEA 中，创建我们编译出来的 OpenJDK 的 SDKs ，如下图所示：[![SDKs](02-JDK 源码解析-调试环境搭建（二）进阶.assets/01.png)](http://static.iocoder.cn/images/JDK/2019_01_04/01.png)SDKs
+
+**Project SDK**
+
+然后，记得将 Project SDK 修改成我们编译出来的 OpenJDK 的 SDK ，如下图所示：
+
+[![Project SDK](02-JDK 源码解析-调试环境搭建（二）进阶.assets/02.png)](http://static.iocoder.cn/images/JDK/2019_01_04/02.png)Project SDK
+
+**Module SDK**
+
+最后，还要将 Module SDK 修改成我们编译出来的 OpenJDK 的 SDK ，如下图所示：[![Module SDK](02-JDK 源码解析-调试环境搭建（二）进阶.assets/03.png)](http://static.iocoder.cn/images/JDK/2019_01_04/03.png)Module SDK
+
+之后，我们就可以愉快的调试了。
+
+# 666. 彩蛋
+
+编译的过程中，可能每个人碰到的问题不同，如下是艿艿在编译过程中，参考过的文章：
+
+- [《Ubuntu 下编译 openjdk8》](https://www.jianshu.com/p/8a53708dd08a)
+- [《Ubuntu 下编译 openjdk11》](https://www.jianshu.com/p/53472697f2ef)
+- [《在 MAC 上编译 JDK》](https://www.jianshu.com/p/b8177780c939)
+- [《JVM(一):java 技术体系与编译 openjdk》](https://www.jianshu.com/p/8523d36d1d6e)
+- [《编译 openJdk10》](https://thurstonzk2008.com/2019/08/26/编译openjdk10/)
+
+虽然 2013 年的时候，在 Ubuntu 上成功编译过一次 OpenJDK 。但是时隔 6 年之后，整个过程还是磕磕碰碰的。
+
+国庆的最后一天假期的 21 点 55 分，准备休息，放空自己。
\ No newline at end of file
diff --git a/jdk/03-JDK 源码解析-集合（一）数组 ArrayList.assets/01.png b/jdk/03-JDK 源码解析-集合（一）数组 ArrayList.assets/01.png
new file mode 100644
index 0000000..c9b4a4d
Binary files /dev/null and b/jdk/03-JDK 源码解析-集合（一）数组 ArrayList.assets/01.png differ
diff --git a/jdk/03-JDK 源码解析-集合（一）数组 ArrayList.assets/02.png b/jdk/03-JDK 源码解析-集合（一）数组 ArrayList.assets/02.png
new file mode 100644
index 0000000..9314f15
Binary files /dev/null and b/jdk/03-JDK 源码解析-集合（一）数组 ArrayList.assets/02.png differ
diff --git a/jdk/03-JDK 源码解析-集合（一）数组 ArrayList.assets/03.png b/jdk/03-JDK 源码解析-集合（一）数组 ArrayList.assets/03.png
new file mode 100644
index 0000000..cb05feb
Binary files /dev/null and b/jdk/03-JDK 源码解析-集合（一）数组 ArrayList.assets/03.png differ
diff --git a/jdk/03-JDK 源码解析-集合（一）数组 ArrayList.assets/04.png b/jdk/03-JDK 源码解析-集合（一）数组 ArrayList.assets/04.png
new file mode 100644
index 0000000..f279bdf
Binary files /dev/null and b/jdk/03-JDK 源码解析-集合（一）数组 ArrayList.assets/04.png differ
diff --git a/jdk/03-JDK 源码解析-集合（一）数组 ArrayList.md b/jdk/03-JDK 源码解析-集合（一）数组 ArrayList.md
new file mode 100644
index 0000000..b3a73cd
--- /dev/null
+++ b/jdk/03-JDK 源码解析-集合（一）数组 ArrayList.md	
@@ -0,0 +1,1471 @@
+# 精尽 JDK 源码解析 —— 集合（一）数组 ArrayList
+
+# 1. 概述
+
+ArrayList ，基于 `[]` 数组实现的，支持**自动扩容**的动态数组。相比数组来说，因为其支持**自动扩容**的特性，成为我们日常开发中，最常用的集合类，没有之一。
+
+在前些年，实习或初级工程师的面试，可能最爱问的就是 ArrayList 和 LinkedList 的区别与使用场景。不过貌似，现在问的已经不多了，因为现在信息非常发达，这种常规面试题已经无法区分能力了。当然即使如此，也不妨碍我们拿它开刀，毕竟是咱的“老朋友”。
+
+# 2. 类图
+
+ArrayList 实现的接口、继承的抽象类，如下图所示：[![类图](03-JDK 源码解析-集合（一）数组 ArrayList.assets/01.png)](http://static.iocoder.cn/images/JDK/2019_12_01/01.png)类图
+
+实现了 4 个接口，分别是：
+
+- [`java.util.List`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/util/List.java) 接口，提供数组的添加、删除、修改、迭代遍历等操作。
+
+- [`java.util.RandomAccess`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/util/RandomAccess.java) 接口，表示 ArrayList 支持**快速**的随机访问。
+
+  > 关于 RandomAccess **标记**接口，我们这里先不展开，胖友可以自行阅读 [《RandomAccess 这个空架子有何用？》](https://juejin.im/post/5a26134af265da43085de060) 文章。
+
+- [`java.io.Serializable`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/io/Serializable.java) 接口，表示 ArrayList 支持序列化的功能。
+
+  > 关于 Serializable **标记**接口，我们这里先不展开，胖友可以自行阅读 [《Java 序列化与反序列化》](https://www.jianshu.com/p/e554c787c286) 文章。
+
+- [`java.lang.Cloneable`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/lang/Cloneable.java) 接口，表示 ArrayList 支持克隆。
+
+  > 关于 Cloneable **标记**接口，我们这里先不展开，胖友可以自行阅读 [《在 Java 中为什么实现了 Cloneable 接口，就能调用 Object 的 clone 方法？》](https://www.zhihu.com/question/52490586/answer/130786763) 讨论，特别是 R 大的回答。
+
+继承了 [`java.util.AbstractList`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/util/AbstractList.java) 抽象类，而 AbstractList 提供了 List 接口的骨架实现，大幅度的减少了实现**迭代遍历**相关操作的代码。可能这样表述有点抽象，胖友点到 [`java.util.AbstractList`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/util/AbstractList.java) 抽象类中看看，例如说 `#iterator()`、`#indexOf(Object o)` 等方法。
+
+😈 不过实际上，在下面中我们会看到，ArrayList 大量重写了 AbstractList 提供的方法实现。所以，AbstractList 对于 ArrayList 意义不大，更多的是 AbstractList 其它子类享受了这个福利。
+
+# 3. 属性
+
+ArrayList 的属性很少，仅仅 **2** 个。如下图所示：
+
+[![ArrayList](03-JDK 源码解析-集合（一）数组 ArrayList.assets/02.png)](http://static.iocoder.cn/images/JDK/2019_12_01/02.png)ArrayList
+
+- `elementData` 属性：元素数组。其中，图中红色空格代表我们已经添加元素，白色空格代表我们并未使用。
+- `size` 属性：数组大小。注意，`size` 代表的是 ArrayList 已使用 `elementData` 的元素的数量，对于开发者看到的 `#size()` 也是该大小。并且，当我们添加新的元素时，恰好其就是元素添加到 `elementData` 的位置（下标）。当然，我们知道 ArrayList **真正**的大小是 `elementData` 的大小。
+
+对应代码如下：
+
+```
+// ArrayList.java
+
+/**
+ * 元素数组。
+ *
+ * 当添加新的元素时，如果该数组不够，会创建新数组，并将原数组的元素拷贝到新数组。之后，将该变量指向新数组。
+ *
+ * The array buffer into which the elements of the ArrayList are stored.
+ * The capacity of the ArrayList is the length of this array buffer. Any
+ * empty ArrayList with elementData == DEFAULTCAPACITY_EMPTY_ELEMENTDATA
+ * will be expanded to DEFAULT_CAPACITY when the first element is added.
+ */
+transient Object[] elementData; // non-private to simplify nested class access 不使用 private 修复，方便内嵌类的访问。
+
+/**
+ * 已使用的数组大小
+ *
+ * The size of the ArrayList (the number of elements it contains).
+ *
+ * @serial
+ */
+private int size;
+```
+
+# 4. 构造方法
+
+ArrayList 一共有三个构造方法，我们分别来看看。
+
+**① `#ArrayList(int initialCapacity)`**
+
+`#ArrayList(int initialCapacity)` 构造方法，根据传入的初始化容量，创建 ArrayList 数组。如果我们在使用时，如果预先指到数组大小，一定要使用该构造方法，可以避免数组扩容提升性能，同时也是合理使用内存。代码如下：
+
+```
+// ArrayList.java
+
+/**
+ * 共享的空数组对象。
+ *
+ * 在 {@link #ArrayList(int)} 或 {@link #ArrayList(Collection)} 构造方法中，
+ * 如果传入的初始化大小或者集合大小为 0 时，将 {@link #elementData} 指向它。
+ *
+ * Shared empty array instance used for empty instances.
+ */
+private static final Object[] EMPTY_ELEMENTDATA = {};
+
+public ArrayList(int initialCapacity) {
+    // 初始化容量大于 0 时，创建 Object 数组
+    if (initialCapacity > 0) {
+        this.elementData = new Object[initialCapacity];
+    // 初始化容量等于 0 时，使用 EMPTY_ELEMENTDATA 对象
+    } else if (initialCapacity == 0) {
+        this.elementData = EMPTY_ELEMENTDATA;
+    // 初始化容量小于 0 时，抛出 IllegalArgumentException 异常
+    } else {
+        throw new IllegalArgumentException("Illegal Capacity: "+
+                                           initialCapacity);
+    }
+}
+```
+
+- 比较特殊的是，如果初始化容量为 0 时，使用 `EMPTY_ELEMENTDATA` 空数组。在添加元素的时候，会进行扩容创建需要的数组。
+
+**② `#ArrayList(Collection<? extends E> c)`**
+
+`#ArrayList(Collection<? extends E> c)` 构造方法，使用传入的 `c` 集合，作为 ArrayList 的 `elementData` 。代码如下：
+
+```
+// ArrayList.java
+
+public ArrayList(Collection<? extends E> c) {
+    // 将 c 转换成 Object 数组
+    elementData = c.toArray();
+    // 如果数组大小大于 0
+    if ((size = elementData.length) != 0) {
+        // defend against c.toArray (incorrectly) not returning Object[]
+        // (see e.g. https://bugs.openjdk.java.net/browse/JDK-6260652)
+        // <X> 如果集合元素不是 Object[] 类型，则会创建新的 Object[] 数组，并将 elementData 赋值到其中，最后赋值给 elementData 。
+        if (elementData.getClass() != Object[].class)
+            elementData = Arrays.copyOf(elementData, size, Object[].class);
+    // 如果数组大小等于 0 ，则使用 EMPTY_ELEMENTDATA 。
+    } else {
+        // replace with empty array.
+        this.elementData = EMPTY_ELEMENTDATA;
+    }
+}
+```
+
+- 比较让人费解的是，在 `<X>` 处的代码。它是用于解决 [JDK-6260652](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6260652) 的 Bug 。它在 JDK9 中被解决，😈 也就是说，JDK8 还会存在该问题。
+
+我们来看一段能够触发 [JDK-6260652](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6260652) 的测试代码，然后分别在 JDK8 和 JDK13 下执行。代码如下：
+
+```
+// ArrayListTest.java
+
+public static void test02() {
+    List<Integer> list = Arrays.asList(1, 2, 3);
+    Object[] array = list.toArray(); // JDK8 返回 Integer[] 数组，JDK9+ 返回 Object[] 数组。
+    System.out.println("array className ：" + array.getClass().getSimpleName());
+
+    // 此处，在 JDK8 和 JDK9+ 表现不同，前者会报 ArrayStoreException 异常，后者不会。
+    array[0] = new Object();
+}
+```
+
+- JDK8 执行如下图所示：[![img](03-JDK 源码解析-集合（一）数组 ArrayList.assets/03.png)](http://static.iocoder.cn/images/JDK/2019_12_01/03.png)
+- JDK13 执行如下图所示：[![img](03-JDK 源码解析-集合（一）数组 ArrayList.assets/04.png)](http://static.iocoder.cn/images/JDK/2019_12_01/04.png)
+- 在 JDK8 中，返回的实际是 `Integer []` 数组，那么我们将 Object 对象设置到其中，肯定是会报错的。具体怎么修复的，看 [JDK-6260652](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6260652) 的最末尾一段。
+
+**③ `#ArrayList()`**
+
+无参数构造方法 `#ArrayList()` 构造方法，也是我们使用最多的构造方法。代码如下：
+
+```
+// ArrayList.java
+
+/**
+ * 默认初始化容量
+ *
+ * Default initial capacity.
+ */
+private static final int DEFAULT_CAPACITY = 10;
+
+/**
+ * 共享的空数组对象，用于 {@link #ArrayList()} 构造方法。
+ *
+ * 通过使用该静态变量，和 {@link #EMPTY_ELEMENTDATA} 区分开来，在第一次添加元素时。
+ *
+ * Shared empty array instance used for default sized empty instances. We
+ * distinguish this from EMPTY_ELEMENTDATA to know how much to inflate when
+ * first element is added.
+ */
+private static final Object[] DEFAULTCAPACITY_EMPTY_ELEMENTDATA = {};
+
+/**
+ * Constructs an empty list with an initial capacity of ten.
+ */
+public ArrayList() {
+    this.elementData = DEFAULTCAPACITY_EMPTY_ELEMENTDATA;
+}
+```
+
+- 在我们学习 ArrayList 的时候，一直被灌输了一个概念，在未设置初始化容量时，ArrayList 默认大小为 10 。但是此处，我们可以看到初始化为 `DEFAULTCAPACITY_EMPTY_ELEMENTDATA` 这个空数组。这是为什么呢？ArrayList 考虑到节省内存，一些使用场景下仅仅是创建了 ArrayList 对象，实际并未使用。所以，ArrayList 优化成初始化是个空数组，在首次添加元素时，才真正初始化为容量为 10 的数组。
+- 那么为什么单独声明了 `DEFAULTCAPACITY_EMPTY_ELEMENTDATA` 空数组，而不直接使用 `EMPTY_ELEMENTDATA` 呢？在下文中，我们会看到 `DEFAULTCAPACITY_EMPTY_ELEMENTDATA` 首次扩容为 10 ，而 `EMPTY_ELEMENTDATA` 按照 **1.5 倍**扩容从 0 开始而不是 10 。😈 两者的起点不同，嘿嘿。
+
+# 5. 添加单个元素
+
+`#add(E e)` 方法，**顺序**添加单个元素到数组。代码如下：
+
+```
+// ArrayList.java
+
+@Override
+public boolean add(E e) {
+    // <1> 增加数组修改次数
+    modCount++;
+    // 添加元素
+    add(e, elementData, size);
+    // 返回添加成功
+    return true;
+}
+
+private void add(E e, Object[] elementData, int s) {
+    // <2> 如果容量不够，进行扩容
+    if (s == elementData.length)
+        elementData = grow();
+    // <3> 设置到末尾
+    elementData[s] = e;
+    // <4> 数量大小加一
+    size = s + 1;
+}
+```
+
+- `<1>` 处，增加数组修改次数 `modCount` 。在父类 AbstractList 上，定义了 `modCount` 属性，用于记录数组修改次数。
+- `<2>` 处，如果元素添加的位置就超过末尾（数组下标是从 0 开始，而数组大小比最大下标大 1），说明数组容量不够，需要进行扩容，那么就需要调用 `#grow()` 方法，进行扩容。稍后我们在 [「6. 数组扩容」](https://svip.iocoder.cn/JDK/Collection-ArrayList/#) 小节来讲。
+- `<3>` 处，设置到末尾。
+- `<4>` 处，数量大小加一。
+
+总体流程上来说，抛开扩容功能，和我们日常往 `[]` 数组里添加元素是一样的。
+
+看懂这个方法后，胖友自己来看看 `#add(int index, E element)` 方法，**插入**单个元素到指定位置。代码如下：
+
+```
+// ArrayList.java
+
+public void add(int index, E element) {
+    // 校验位置是否在数组范围内
+    rangeCheckForAdd(index);
+    // 增加数组修改次数
+    modCount++;
+    // 如果数组大小不够，进行扩容
+    final int s;
+    Object[] elementData;
+    if ((s = size) == (elementData = this.elementData).length)
+        elementData = grow();
+    // 将 index + 1 位置开始的元素，进行往后挪
+    System.arraycopy(elementData, index,
+                     elementData, index + 1,
+                     s - index);
+    // 设置到指定位置
+    elementData[index] = element;
+    // 数组大小加一
+    size = s + 1;
+}
+
+private void rangeCheckForAdd(int index) {
+    if (index > size || index < 0)
+        throw new IndexOutOfBoundsException(outOfBoundsMsg(index));
+}
+```
+
+# 6. 数组扩容
+
+`#grow()` 方法，扩容数组，并返回它。整个的扩容过程，首先创建一个新的更大的数组，一般是 **1.5 倍**大小（为什么说是一般呢，稍后我们会看到，会有一些小细节），然后将原数组复制到新数组中，最后返回新数组。代码如下：
+
+```
+// ArrayList.java
+
+private Object[] grow() {
+    // <1>
+    return grow(size + 1);
+}
+
+private Object[] grow(int minCapacity) {
+    int oldCapacity = elementData.length;
+    // <2> 如果原容量大于 0 ，或者数组不是 DEFAULTCAPACITY_EMPTY_ELEMENTDATA 时，计算新的数组大小，并创建扩容
+    if (oldCapacity > 0 || elementData != DEFAULTCAPACITY_EMPTY_ELEMENTDATA) {
+        int newCapacity = ArraysSupport.newLength(oldCapacity,
+                minCapacity - oldCapacity, /* minimum growth */
+                oldCapacity >> 1           /* preferred growth */);
+        return elementData = Arrays.copyOf(elementData, newCapacity);
+    // <3> 如果是 DEFAULTCAPACITY_EMPTY_ELEMENTDATA 数组，直接创建新的数组即可。
+    } else {
+        return elementData = new Object[Math.max(DEFAULT_CAPACITY, minCapacity)];
+    }
+}
+```
+
+- `<1>` 处，调用 `#grow(int minCapacity)` 方法，要求扩容后**至少**比原有大 1 。因为是最小扩容的要求，实际是允许比它大。
+
+- ```
+  <2>
+  ```
+
+   
+
+  处，如果原容量大于 0 时，又或者数组不是 DEFAULTCAPACITY_EMPTY_ELEMENTDATA 时，则计算新的数组大小，并创建扩容。
+
+  - `ArraysSupport#newLength(int oldLength, int minGrowth, int prefGrowth)` 方法，计算新的数组大小。简单来说，结果就是 `Math.max(minGrowth, prefGrowth) + oldLength` ，按照 `minGrowth` 和 `prefGrowth` 取大的。
+  - 一般情况下，从 `oldCapacity >> 1` 可以看处，是 **1.5 倍**扩容。但是会有两个特殊情况：1）初始化数组要求大小为 0 的时候，`0 >> 1` 时（`>> 1 为右移操作，相当于除以 2`）还是 0 ，此时使用 `minCapacity` 传入的 1 。2）在下文中，我们会看到添加多个元素，此时传入的 `minCapacity` 不再仅仅加 1 ，而是扩容到 `elementData` 数组恰好可以添加下多个元素，而该数量可能会超过当前 ArrayList **0.5** 倍的容量。
+
+- `<3>` 处，如果是 `DEFAULTCAPACITY_EMPTY_ELEMENTDATA` 数组，直接创建新的数组即可。思考下，如果无参构造方法使用 `EMPTY_ELEMENTDATA` 的话，无法实现该效果了。
+
+既然有数组扩容方法，那么是否有缩容方法呢？在 `#trimToSize()` 方法中，会创建大小恰好够用的新数组，并将原数组复制到其中。代码如下：
+
+```
+// ArrayList.java
+
+public void trimToSize() {
+    // 增加修改次数
+    modCount++;
+    // 如果有多余的空间，则进行缩容
+    if (size < elementData.length) {
+        elementData = (size == 0)
+          ? EMPTY_ELEMENTDATA // 大小为 0 时，直接使用 EMPTY_ELEMENTDATA
+          : Arrays.copyOf(elementData, size); // 大小大于 0 ，则创建大小为 size 的新数组，将原数组复制到其中。
+    }
+}
+```
+
+同时，提供 `#ensureCapacity(int minCapacity)` 方法，保证 `elementData` 数组容量至少有 `minCapacity` 。代码如下：
+
+```
+// ArrayList.java
+
+public void ensureCapacity(int minCapacity) {
+    if (minCapacity > elementData.length // 如果 minCapacity 大于数组的容量
+        && !(elementData == DEFAULTCAPACITY_EMPTY_ELEMENTDATA
+             && minCapacity <= DEFAULT_CAPACITY)) { // 如果 elementData 是 DEFAULTCAPACITY_EMPTY_ELEMENTDATA 的时候，
+                                                    // 需要最低 minCapacity 容量大于 DEFAULT_CAPACITY ，因为实际上容量是 DEFAULT_CAPACITY 。
+        // 数组修改次数加一
+        modCount++;
+        // 扩容
+        grow(minCapacity);
+    }
+}
+```
+
+- 比较简单，我们可以将这个方法理解成主动扩容。
+
+# 7. 添加多个元素
+
+`#addAll(Collection<? extends E> c)` 方法，批量添加多个元素。在我们明确知道会添加多个元素时，推荐使用该该方法而不是添加单个元素，避免可能多次扩容。代码如下：
+
+```
+// ArrayList.java
+
+public boolean addAll(Collection<? extends E> c) {
+    // 转成 a 数组
+    Object[] a = c.toArray();
+    // 增加修改次数
+    modCount++;
+    // 如果 a 数组大小为 0 ，返回 ArrayList 数组无变化
+    int numNew = a.length;
+    if (numNew == 0)
+        return false;
+    // <1> 如果 elementData 剩余的空间不够，则进行扩容。要求扩容的大小，至于能够装下 a 数组。
+    Object[] elementData;
+    final int s;
+    if (numNew > (elementData = this.elementData).length - (s = size))
+        elementData = grow(s + numNew);
+    // <2> 将 a 复制到 elementData 从 s 开始位置
+    System.arraycopy(a, 0, elementData, s, numNew);
+    // 数组大小加 numNew
+    size = s + numNew;
+    return true;
+}
+```
+
+- `<1>` 处，如果 `elementData` 剩余的空间不足，则进行扩容。要求扩容的大小，至于能够装下 `a` 数组。当然，在 [「6. 数组扩容」](https://svip.iocoder.cn/JDK/Collection-ArrayList/#) 的小节，我们已经看到，如果要求扩容的空间太小，则扩容 **1.5 倍**。
+- `<2>` 处，将 `a` 复制到 `elementData` 从 `s` 开始位置。
+
+总的看下来，就是 `#add(E e)` 方法的批量版本，优势就正如我们在本节开头说的，避免可能多次扩容。
+
+看懂这个方法后，胖友自己来看看 `#addAll(int index, Collection<? extends E> c)` 方法，从指定位置开始插入多个元素。代码如下：
+
+```
+// ArrayList.java
+
+public boolean addAll(int index, Collection<? extends E> c) {
+    // 校验位置是否在数组范围内
+    rangeCheckForAdd(index);
+
+    // 转成 a 数组
+    Object[] a = c.toArray();
+    // 增加数组修改次数
+    modCount++;
+    // 如果 a 数组大小为 0 ，返回 ArrayList 数组无变化
+    int numNew = a.length;
+    if (numNew == 0)
+        return false;
+    // 如果 elementData 剩余的空间不够，则进行扩容。要求扩容的大小，至于能够装下 a 数组。
+    Object[] elementData;
+    final int s;
+    if (numNew > (elementData = this.elementData).length - (s = size))
+        elementData = grow(s + numNew);
+
+    // 【差异点】如果 index 开始的位置已经被占用，将它们后移
+    int numMoved = s - index;
+    if (numMoved > 0)
+        System.arraycopy(elementData, index,
+                         elementData, index + numNew,
+                         numMoved);
+
+    // 将 a 复制到 elementData 从 s 开始位置
+    System.arraycopy(a, 0, elementData, index, numNew);
+    // 数组大小加 numNew
+    size = s + numNew;
+    return true;
+}
+```
+
+- 重点看【差异点】部分。
+
+# 8. 移除单个元素
+
+`#remove(int index)` 方法，移除指定位置的元素，并返回该位置的原元素。代码如下：
+
+```
+// ArrayList.java
+
+public E remove(int index) {
+    // 校验 index 不要超过 size
+    Objects.checkIndex(index, size);
+    final Object[] es = elementData;
+
+    // 记录该位置的原值
+    @SuppressWarnings("unchecked") E oldValue = (E) es[index];
+    // <X>快速移除
+    fastRemove(es, index);
+
+    // 返回该位置的原值
+    return oldValue;
+}
+```
+
+- 重点是 `<X>` 处，调用 `#fastRemove(Object[] es, int i)` 方法，快速移除。代码如下
+
+  ```
+  // ArrayList.java
+  
+  private void fastRemove(Object[] es, int i) {
+      // 增加数组修改次数
+      modCount++;
+      // <Y>如果 i 不是移除最末尾的元素，则将 i + 1 位置的数组往前挪
+      final int newSize;
+      if ((newSize = size - 1) > i) // -1 的原因是，size 是从 1 开始，而数组下标是从 0 开始。
+          System.arraycopy(es, i + 1, es, i, newSize - i);
+      // 将新的末尾置为 null ，帮助 GC
+      es[size = newSize] = null;
+  }
+  ```
+
+  - `<Y>` 处，看起来比较复杂，胖友按照“如果 i 不是移除最末尾的元素，则将 i + 1 位置的数组往前挪”来理解，就很好懂了。
+
+`#remove(Object o)` 方法，移除首个为 `o` 的元素，并返回是否移除到。代码如下：
+
+```
+// ArrayList.java
+
+public boolean remove(Object o) {
+    final Object[] es = elementData;
+    final int size = this.size;
+    // <Z> 寻找首个为 o 的位置
+    int i = 0;
+    found: {
+        if (o == null) { // o 为 null 的情况
+            for (; i < size; i++)
+                if (es[i] == null)
+                    break found;
+        } else { // o 非 null 的情况
+            for (; i < size; i++)
+                if (o.equals(es[i]))
+                    break found;
+        }
+        // 如果没找到，返回 false
+        return false;
+    }
+    // 快速移除
+    fastRemove(es, i);
+    // 找到了，返回 true
+    return true;
+}
+```
+
+- 和 `#remove(int index)` 差不多，就是在 `<Z>` 处，改成获得首个为 `o` 的位置，之后就调用 `#fastRemove(Object[] es, int i)` 方法，快速移除即可。
+
+# 9. 移除多个元素
+
+我们先来看 `#removeRange(int fromIndex, int toIndex)` 方法，批量移除 `[fromIndex, toIndex)` 的多个元素，注意不包括 `toIndex` 的元素噢。代码如下：
+
+```
+// ArrayList.java
+
+protected void removeRange(int fromIndex, int toIndex) {
+    // 范围不正确，抛出 IndexOutOfBoundsException 异常
+    if (fromIndex > toIndex) {
+        throw new IndexOutOfBoundsException(
+                outOfBoundsMsg(fromIndex, toIndex));
+    }
+    // 增加数组修改次数
+    modCount++;
+    // <X> 移除 [fromIndex, toIndex) 的多个元素
+    shiftTailOverGap(elementData, fromIndex, toIndex);
+}
+
+private static String outOfBoundsMsg(int fromIndex, int toIndex) {
+    return "From Index: " + fromIndex + " > To Index: " + toIndex;
+}
+```
+
+- `<X>` 处，调用 `#shiftTailOverGap(Object[] es, int lo, int hi)` 方法，移除 `[fromIndex, toIndex)` 的多个元素。代码如下：
+
+  ```
+  // ArrayList.java
+  
+  private void shiftTailOverGap(Object[] es, int lo, int hi) {
+      // 将 es 从 hi 位置开始的元素，移到 lo 位置开始。
+      System.arraycopy(es, hi, es, lo, size - hi);
+      // 将从 [size - hi + lo, size) 的元素置空，因为已经被挪到前面了。
+      for (int to = size, i = (size -= hi - lo); i < to; i++)
+          es[i] = null;
+  }
+  ```
+
+  - 和 `#fastRemove(Object[] es, int i)` 方法一样的套路，先挪后置 `null` 。
+  - 有一点要注意，ArrayList 特别喜欢把多行代码写成一行。所以，可能会有胖又会有疑惑，貌似这里没有修改数组的大小 `size` 啊？答案在 `i = (size -= hi - lo)` ，简直到精简到难懂。
+
+`#removeAll(Collection<?> c)` 方法，批量移除指定的多个元素。实现逻辑比较简单，但是看起来会比较绕。简单来说，通过两个变量 `w`（写入位置）和 `r`（读取位置），按照 `r` 顺序遍历数组(`elementData`)，如果不存在于指定的多个元素中，则写入到 `elementData` 的 `w` 位置，然后 `w` 位置 + 1 ，跳到下一个写入位置。通过这样的方式，实现将不存在 `elementData` 覆盖写到 `w` 位置。可能理解起来有点绕，当然看代码也会有点绕绕，嘿嘿。代码如下：
+
+```
+// ArrayList.java
+
+public boolean removeAll(Collection<?> c) {
+    return batchRemove(c, false, 0, size);
+}
+```
+
+- 调用 `#batchRemove(Collection<?> c, boolean complement, final int from, final int end)` 方法，批量移除指定的多个元素。代码如下：
+
+  ```
+  // ArrayList.java
+  
+  boolean batchRemove(Collection<?> c, boolean complement, final int from, final int end) {
+      // 校验 c 非 null 。
+      Objects.requireNonNull(c);
+      final Object[] es = elementData;
+      int r;
+      // Optimize for initial run of survivors
+      // <1> 优化，顺序遍历 elementData 数组，找到第一个不符合 complement ，然后结束遍历。
+      for (r = from;; r++) {
+          // <1.1> 遍历到尾，都没不符合条件的，直接返回 false 。
+          if (r == end)
+              return false;
+          // <1.2> 如果包含结果不符合 complement 时，结束
+          if (c.contains(es[r]) != complement)
+              break;
+      }
+      // <2> 设置开始写入 w 为 r ，注意不是 r++ 。
+      // r++ 后，用于读取下一个位置的元素。因为通过上的优化循环，我们已经 es[r] 是不符合条件的。
+      int w = r++;
+      try {
+          // <3> 继续遍历 elementData 数组，如何符合条件，则进行移除
+          for (Object e; r < end; r++)
+              if (c.contains(e = es[r]) == complement) // 判断符合条件
+                  es[w++] = e; // 移除的方式，通过将当前值 e 写入到 w 位置，然后 w 跳到下一个位置。
+      } catch (Throwable ex) {
+          // Preserve behavioral compatibility with AbstractCollection,
+          // even if c.contains() throws.
+          // <4> 如果 contains 方法发生异常，则将 es 从 r 位置的数据写入到 es 从 w 开始的位置
+          System.arraycopy(es, r, es, w, end - r);
+          w += end - r;
+          // 继续抛出异常
+          throw ex;
+      } finally { // <5>
+          // 增加数组修改次数
+          modCount += end - w;
+          // 将数组 [w, end) 位置赋值为 null 。
+          shiftTailOverGap(es, w, end);
+      }
+      return true;
+  }
+  ```
+
+  - 不要慌，我们先一起看下每一小块的逻辑。然后，胖友自己调试下，妥妥的就明白了。
+
+  - ```
+    complement
+    ```
+
+     
+
+    参数，翻译过来是“补足”的意思。怎么理解呢？表示如果
+
+     
+
+    ```
+    elementData
+    ```
+
+     
+
+    元素在
+
+     
+
+    ```
+    c
+    ```
+
+     
+
+    集合中时，是否保留。
+
+    - 如果 `complement` 为 `false` 时，表示在集合中，就不保留，这显然符合 `#removeAll(Collection<?> c)` 方法要移除的意图。
+    - 如果 `complement` 为 `true` 时，表示在集合中，就暴露，这符合我们后面会看到的 `#retainAll(Collection<?> c)` 方法要求交集的意图。
+
+  - ```
+    <1>
+    ```
+
+     
+
+    处，首先我们要知道这是一个基于 Optimize 优化的目的。我们是希望先判断是否
+
+     
+
+    ```
+    elementData
+    ```
+
+     
+
+    没有任何一个符合
+
+     
+
+    ```
+    c
+    ```
+
+     
+
+    的，这样就无需进行执行对应的移除逻辑。但是，我们又希望能够避免重复遍历，于是就有了这样一块的逻辑。总的来说，这块逻辑的目的是，优化，顺序遍历
+
+     
+
+    ```
+    elementData
+    ```
+
+     
+
+    数组，找到第一个不符合
+
+     
+
+    ```
+    complement
+    ```
+
+     
+
+    ，然后结束遍历。
+
+    - `<1.1>` 处，遍历到尾，都没不符合条件的，直接返回 `false` 。也就是说，丫根就不需要进行移除的逻辑。
+    - `<1.2>` 处，如果包含结果不符合 `complement` 时，结束循环。可能有点难理解，我们来举个例子。假设 `elementData` 是 `[1, 2, 3, 1]` 时，`c` 是 `[2]` 时，那么在遍历第 0 个元素 `1` 时，则 `c.contains(es[r]) != complement => false != false` 不符合，所以继续缓存；然后，在遍历第 1 个元素 `2` 时，`c.contains(es[r]) != complement => true != false` 符合，所以结束循环。此时，我们便找到了第一个需要移除的元素的位置。当然，移除不是在这里执行，我们继续往下看。😈 淡定~
+
+  - `<2>` 处，设置开始写入 `w` 为 `r` ，注意不是 `r++` 。这样，我们后续在循环 `elementData` 数组，就会从 `w` 开始写入。并且此时，`r` 也跳到了下一个位置，这样间接我们可以发现，`w` 位置的元素已经被“跳过”了。
+
+  - `<3>` 处，继续遍历 `elementData` 数组，如何符合条件，则进行移除。可能有点难理解，我们继续上述例子。遍历第 2 个元素 `3` 时候，`c.contains(es[r]) == complement => false == false` 符合，所以将 `3` 写入到 `w` 位置，同时 `w` 指向下一个位置；遍历第三个元素 `1` 时候，`c.contains(es[r]) == complement => true == false` 不符合，所以不进行任何操作。
+
+  - `<4>` 处，如果 contains 方法发生异常，则将 `es` 从 `r` 位置的数据写入到 `es` 从 `w` 开始的位置。这样，保证我们剩余未遍历到的元素，能够挪到从从 `w` 开始的位置，避免多出来一些元素。
+
+  - `<5>` 处，是不是很熟悉，将数组 `[w, end)` 位置赋值为 `null` 。
+
+  - 还是那句话，如果觉得绕，多调试，可以手绘点图，辅助理解下哈。
+
+`#retainAll(Collection<?> c)` 方法，求 `elementData` 数组和指定多个元素的交集。简单来说，恰好和 `#removeAll(Collection<?> c)` 相反，移除不在 `c` 中的元素。代码如下：
+
+```
+// ArrayList.java
+
+public boolean retainAll(Collection<?> c) {
+    return batchRemove(c, true, 0, size);
+}
+```
+
+- 试着按照艿艿上面解释的，自己走一波。
+
+# 10. 查找单个元素
+
+`#indexOf(Object o)` 方法，查找首个为指定元素的位置。代码如下：
+
+```
+// ArrayList.java
+
+public int indexOf(Object o) {
+    return indexOfRange(o, 0, size);
+}
+
+int indexOfRange(Object o, int start, int end) {
+    Object[] es = elementData;
+    // o 为 null 的情况
+    if (o == null) {
+        for (int i = start; i < end; i++) {
+            if (es[i] == null) {
+                return i;
+            }
+        }
+    // o 非 null 的情况
+    } else {
+        for (int i = start; i < end; i++) {
+            if (o.equals(es[i])) {
+                return i;
+            }
+        }
+    }
+    // 找不到，返回 -1
+    return -1;
+}
+```
+
+而 `#contains(Object o)` 方法，就是基于该方法实现。代码如下：
+
+```
+// ArrayList.java
+
+public boolean contains(Object o) {
+    return indexOf(o) >= 0;
+}
+```
+
+有时我们需要查找最后一个为指定元素的位置，所以会使用到 `#lastIndexOf(Object o)` 方法。代码如下：
+
+```
+// ArrayList.java
+
+public int lastIndexOf(Object o) {
+    return lastIndexOfRange(o, 0, size);
+}
+
+int lastIndexOfRange(Object o, int start, int end) {
+    Object[] es = elementData;
+    // o 为 null 的情况
+    if (o == null) {
+        for (int i = end - 1; i >= start; i--) { // 倒序
+            if (es[i] == null) {
+                return i;
+            }
+        }
+    // o 非 null 的情况
+    } else {
+        for (int i = end - 1; i >= start; i--) { // 倒序
+            if (o.equals(es[i])) {
+                return i;
+            }
+        }
+    }
+
+    // 找不到，返回 -1
+    return -1;
+}
+```
+
+# 11. 获得指定位置的元素
+
+`#get(int index)` 方法，获得指定位置的元素。代码如下：
+
+```
+// ArrayList.java
+
+public E get(int index) {
+    // 校验 index 不要超过 size
+    Objects.checkIndex(index, size);
+    // 获得 index 位置的元素
+    return elementData(index);
+}
+
+E elementData(int index) {
+    return (E) elementData[index];
+}
+```
+
+- 随机访问 `index` 位置的元素，时间复杂度为 O(1) 。
+
+# 12. 设置指定位置的元素
+
+`#set(int index, E element)` 方法，设置指定位置的元素。代码如下：
+
+```
+// ArrayList.java
+
+public E set(int index, E element) {
+    // 校验 index 不要超过 size
+    Objects.checkIndex(index, size);
+    // 获得 index 位置的原元素
+    E oldValue = elementData(index);
+    // 修改 index 位置为新元素
+    elementData[index] = element;
+    // 返回 index 位置的原元素
+    return oldValue;
+}
+```
+
+# 13. 转换成数组
+
+`#toArray()` 方法，将 ArrayList 转换成 `[]` 数组。代码如下：
+
+```
+// ArrayList.java
+
+public Object[] toArray() {
+    return Arrays.copyOf(elementData, size);
+}
+
+// Arrays.java
+
+public static <T> T[] copyOf(T[] original, int newLength) {
+    return (T[]) copyOf(original, newLength, original.getClass());
+}
+```
+
+- 注意，返回的是 `Object[]` 类型噢。
+
+实际场景下，我们可能想要指定 `T` 泛型的数组，那么我们就需要使用到 `#toArray(T[] a)` 方法。代码如下：
+
+```
+// ArrayList.java
+
+public <T> T[] toArray(T[] a) {
+    // <1> 如果传入的数组小于 size 大小，则直接复制一个新数组返回
+    if (a.length < size)
+        // Make a new array of a's runtime type, but my contents:
+        return (T[]) Arrays.copyOf(elementData, size, a.getClass());
+    // <2> 将 elementData 复制到 a 中
+    System.arraycopy(elementData, 0, a, 0, size);
+    // <2.1> 如果传入的数组大于 size 大小，则将 size 赋值为 null
+    if (a.length > size)
+        a[size] = null;
+    // <2.2> 返回 a
+    return a;
+}
+```
+
+- 分成 2 个情况，根据传入的 `a` 数组是否足够大。
+
+- `<1>` 处，如果传入的数组小于 `size` 大小，则直接复制一个新数组返回。一般情况下，我们不会这么干。
+
+- ```
+  <2>
+  ```
+
+   
+
+  处，将
+
+   
+
+  ```
+  elementData
+  ```
+
+   
+
+  复制到
+
+   
+
+  ```
+  a
+  ```
+
+   
+
+  中。
+
+  - `<2.1>` 处，如果传入的数组大于 `size` 大小，则将 `size` 位置赋值为 `null` 。额，有点没搞懂这个有啥目的。
+  - `<2.2>` 处，返回传入的 `a` 。很稳。
+
+- 考虑到 `<1>` 处，可能会返回一个新数组，所以即使 `<2>` 返回的就是 `a` 数组，最好使用还是按照 `a = list.toArray(a)` 。
+
+# 14. 求哈希值
+
+`#hashCode()` 方法，求 ArrayList 的哈希值。代码如下：
+
+```
+// ArrayList.java
+
+public int hashCode() {
+    // 获得当前的数组修改次数
+    int expectedModCount = modCount;
+    // 计算哈希值
+    int hash = hashCodeRange(0, size);
+    // 如果修改次数发生改变，则抛出 ConcurrentModificationException 异常
+    checkForComodification(expectedModCount);
+    return hash;
+}
+
+int hashCodeRange(int from, int to) {
+    final Object[] es = elementData;
+    // 如果 to 超过大小，则抛出 ConcurrentModificationException 异常
+    if (to > es.length) {
+        throw new ConcurrentModificationException();
+    }
+    // 遍历每个元素，* 31 求哈希。
+    int hashCode = 1;
+    for (int i = from; i < to; i++) {
+        Object e = es[i];
+        hashCode = 31 * hashCode + (e == null ? 0 : e.hashCode());
+    }
+    return hashCode;
+}
+```
+
+- 可能胖友会好奇，为什么使用 31 作为乘子呢？可以看看 [《科普：为什么 String hashCode 方法选择数字 31 作为乘子》](http://www.iocoder.cn/Fight/Why-did-the-String-hashCode-method-select-the-number-31-as-a-multiplier/?vip&self) 。
+
+# 15. 判断相等
+
+`#equals(Object o)` 方法，判断是否相等。代码如下：
+
+```
+// ArrayList.java
+
+public boolean equals(Object o) {
+    // 如果是自己，直接返回相等
+    if (o == this) {
+        return true;
+    }
+
+    // 如果不为 List 类型，直接不相等
+    if (!(o instanceof List)) {
+        return false;
+    }
+
+    // 获得当前的数组修改次数
+    final int expectedModCount = modCount;
+    // ArrayList can be subclassed and given arbitrary behavior, but we can
+    // still deal with the common case where o is ArrayList precisely
+    // <X> 根据不同类型，调用不同比对的方法。主要考虑 ArrayList 可以直接使用其 elementData 属性，性能更优。
+    boolean equal = (o.getClass() == ArrayList.class)
+        ? equalsArrayList((ArrayList<?>) o)
+        : equalsRange((List<?>) o, 0, size);
+
+    // 如果修改次数发生改变，则抛出 ConcurrentModificationException 异常
+    checkForComodification(expectedModCount);
+    return equal;
+}
+```
+
+- 可能第一眼让胖友比较费解的是，为什么根据类型是否为 ArrayList ，调用了两个不同的方法去比对呢？因为普通的 List ，我们只能使用 Iterator 进行迭代，相比 ArrayList 的 `elementData` 属性遍历，性能会略低一些。😈 处处是细节哈。
+
+- 这两个方法的代码如下，已经添加详细注释。代码如下：
+
+  ```
+  // ArrayList.java
+  
+  boolean equalsRange(List<?> other, int from, int to) {
+      // 如果 to 大于 es 大小，说明说明发生改变，抛出 ConcurrentModificationException 异常
+      final Object[] es = elementData;
+      if (to > es.length) {
+          throw new ConcurrentModificationException();
+      }
+      // 通过迭代器遍历 other ，然后逐个元素对比
+      var oit = other.iterator();
+      for (; from < to; from++) {
+          // 如果 oit 没有下一个，或者元素不相等，返回 false 不匹配
+          if (!oit.hasNext() || !Objects.equals(es[from], oit.next())) {
+              return false;
+          }
+      }
+      // 通过 oit 是否遍历完。实现大小是否相等的效果。
+      return !oit.hasNext();
+  }
+  
+  private boolean equalsArrayList(ArrayList<?> other) {
+      // 获得 other 数组修改次数
+      final int otherModCount = other.modCount;
+      final int s = size;
+      boolean equal;
+      // 判断数组大小是否相等
+      if (equal = (s == other.size)) {
+          final Object[] otherEs = other.elementData;
+          final Object[] es = elementData;
+          // 如果 s 大于 es 或者 otherEs 的长度，说明发生改变，抛出 ConcurrentModificationException 异常
+          if (s > es.length || s > otherEs.length) {
+              throw new ConcurrentModificationException();
+          }
+          // 遍历，逐个比较每个元素是否相等
+          for (int i = 0; i < s; i++) {
+              if (!Objects.equals(es[i], otherEs[i])) {
+                  equal = false;
+                  break; // 如果不相等，则 break
+              }
+          }
+      }
+      // 如果 other 修改次数发生改变，则抛出 ConcurrentModificationException 异常
+      other.checkForComodification(otherModCount);
+      return equal;
+  }
+  ```
+
+# 16. 清空数组
+
+`#clear()` 方法，清空数组。代码如下：
+
+```
+// ArrayList.java
+
+public void clear() {
+    // 获得当前的数组修改次数
+    modCount++;
+    // 遍历数组，倒序设置为 null
+    final Object[] es = elementData;
+    for (int to = size, i = size = 0; i < to; i++)
+        es[i] = null;
+}
+```
+
+# 17. 序列化数组
+
+`#writeObject(java.io.ObjectOutputStream s)` 方法，实现 ArrayList 的序列化。代码如下：
+
+```
+// ArrayList.java
+
+@java.io.Serial
+private void writeObject(java.io.ObjectOutputStream s)
+    throws java.io.IOException {
+    // Write out element count, and any hidden stuff
+    // 获得当前的数组修改次数
+    int expectedModCount = modCount;
+
+    // <1> 写入非静态属性、非 transient 属性
+    s.defaultWriteObject();
+
+    // Write out size as capacity for behavioral compatibility with clone()
+    // <2> 写入 size ，主要为了与 clone 方法的兼容
+    s.writeInt(size);
+
+    // Write out all elements in the proper order.
+    // <3> 逐个写入 elementData 数组的元素
+    for (int i = 0; i < size; i++) {
+        s.writeObject(elementData[i]);
+    }
+
+    // 如果 other 修改次数发生改变，则抛出 ConcurrentModificationException 异常
+    if (modCount != expectedModCount) {
+        throw new ConcurrentModificationException();
+    }
+}
+```
+
+- `<1>` 处，调用 `ObjectOutputStream#defaultWriteObject()` 方法，写入非静态属性、非 `transient` 属性。可能有些胖友不了解 Java 的序列化相关的知识，可以看看 [《Serializable 原理》](https://juejin.im/entry/5bf622436fb9a04a0b21cbe7) 文章。
+- `<2>` 处，写入 `size` ，主要为了与 clone 方法的兼容。不过艿艿也觉得挺奇怪的，明明在 `<1>` 处，已经写入了 `size` ，这里怎么还来这么一出呢？各种翻查资料，暂时只看到 [《源码分析：ArrayList 的 writeobject 方法中的实现是否多此一举？》](https://www.zhihu.com/question/41512382) 有个讨论。
+- `<3>` 吹，逐个写入 `elementData` 元素的数组。我们回过来看下 `elementData` 的定义，它是一个 `transient` 修饰的属性。为什么呢？因为 `elementData` 数组，并不一定是全满的，而可能是扩容的时候有一定的预留，如果直接序列化，会有很多空间的浪费，所以只序列化从 `[0, size)` 的元素，减少空间的占用。
+
+# 18. 反序列化数组
+
+`#readObject(java.io.ObjectInputStream s)` 方法，反序列化数组。代码如下：
+
+```
+// ArrayList.java
+
+@java.io.Serial
+private void readObject(java.io.ObjectInputStream s)
+    throws java.io.IOException, ClassNotFoundException {
+
+    // Read in size, and any hidden stuff
+    // 读取非静态属性、非 transient 属性
+    s.defaultReadObject();
+
+    // Read in capacity
+    // 读取 size ，不过忽略不用
+    s.readInt(); // ignored
+
+    if (size > 0) {
+        // like clone(), allocate array based upon size not capacity
+        SharedSecrets.getJavaObjectInputStreamAccess().checkArray(s, Object[].class, size); // 不知道作甚，哈哈哈。
+        // 创建 elements 数组
+        Object[] elements = new Object[size];
+
+        // Read in all elements in the proper order.
+        // 逐个读取
+        for (int i = 0; i < size; i++) {
+            elements[i] = s.readObject();
+        }
+
+        // 赋值给 elementData
+        elementData = elements;
+    } else if (size == 0) {
+        // 如果 size 是 0 ，则直接使用空数组
+        elementData = EMPTY_ELEMENTDATA;
+    } else {
+        throw new java.io.InvalidObjectException("Invalid size: " + size);
+    }
+}
+```
+
+- 和序列化的过程，恰好相反（哈哈哈，不然还想咋样），一眼就看的明白。
+
+# 19. 克隆
+
+`#clone()` 方法，克隆 ArrayList 对象。代码如下：
+
+```
+// ArrayList.java
+
+public Object clone() {
+    try {
+        // 调用父类，进行克隆
+        ArrayList<?> v = (ArrayList<?>) super.clone();
+        // 拷贝一个新的数组
+        v.elementData = Arrays.copyOf(elementData, size);
+        // 设置数组修改次数为 0
+        v.modCount = 0;
+        return v;
+    } catch (CloneNotSupportedException e) {
+        // this shouldn't happen, since we are Cloneable
+        throw new InternalError(e);
+    }
+}
+```
+
+- 注意，`elementData` 是重新拷贝出来的新的数组，避免和原数组共享。
+
+# 20. 创建子数组
+
+`#subList(int fromIndex, int toIndex)` 方法，创建 ArrayList 的子数组。代码如下：
+
+```
+// ArrayList.java
+
+public List<E> subList(int fromIndex, int toIndex) {
+    subListRangeCheck(fromIndex, toIndex, size);
+    return new SubList<>(this, fromIndex, toIndex);
+}
+
+private static class SubList<E> extends AbstractList<E> implements RandomAccess {
+
+    /**
+     * 根 ArrayList
+     */
+    private final ArrayList<E> root;
+    /**
+     *  父 SubList
+     */
+    private final SubList<E> parent;
+    /**
+     * 起始位置
+     */
+    private final int offset;
+    /**
+     * 大小
+     */
+    private int size;
+
+    // ... 省略代码
+}
+```
+
+- 实际使用时，一定要注意，SubList 不是一个**只读**数组，而是和根数组 `root` 共享相同的 `elementData` 数组，只是说限制了 `[fromIndex, toIndex)` 的范围。
+- 这块的源码，并不复杂，所以这里也就不展开了。一般情况下，我们也不需要了解它的源码，嘿嘿。
+
+# 21. 创建 Iterator 迭代器
+
+`#iterator()` 方法，创建迭代器。一般情况下，我们使用迭代器遍历 ArrayList、LinkedList 等等 List 的实现类。代码如下：
+
+```
+// ArrayList.java
+
+public Iterator<E> iterator() {
+    return new Itr();
+}
+```
+
+- 创建 Itr 迭代器。Itr 实现 [`java.util.Iterator`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/util/List.java) 接口，是 ArrayList 的内部类。虽然说 AbstractList 也提供了一个 Itr 的实现，但是 ArrayList 为了更好的性能，所以自己实现了，在其类上也有注释“An optimized version of AbstractList.Itr”。
+
+Itr 一共有 3 个属性，如下：
+
+```
+// ArrayList.java#Itr
+
+/**
+ * 下一个访问元素的位置，从下标 0 开始。
+ */
+int cursor;       // index of next element to return
+/**
+ * 上一次访问元素的位置。
+ *
+ * 1. 初始化为 -1 ，表示无上一个访问的元素
+ * 2. 遍历到下一个元素时，lastRet 会指向当前元素，而 cursor 会指向下一个元素。这样，如果我们要实现 remove 方法，移除当前元素，就可以实现了。
+ * 3. 移除元素时，设置为 -1 ，表示最后访问的元素不存在了，都被移除咧。
+ */
+int lastRet = -1; // index of last element returned; -1 if no such
+/**
+ * 创建迭代器时，数组修改次数。
+ *
+ * 在迭代过程中，如果数组发生了变化，会抛出 ConcurrentModificationException 异常。
+ */
+int expectedModCount = modCount;
+
+// prevent creating a synthetic constructor
+Itr() {}
+```
+
+- 每个属性，胖友自己看看注释噢。
+
+下面，让我们来看看 Itr 对 Iterator 的 4 个实现方法。
+
+`#hasNext()` 方法，判断是否还可以继续迭代。代码如下：
+
+```
+// ArrayList.java#Itr
+
+public boolean hasNext() {
+    return cursor != size;
+}
+```
+
+- `cursor` 如果等于 `size` ，说明已经到数组末尾，无法继续迭代了。
+
+`#next()` 方法，下一个元素。代码如下：
+
+```
+// ArrayList.java#Itr
+
+public E next() {
+    // 校验是否数组发生了变化
+    checkForComodification();
+    // 判断如果超过 size 范围，抛出 NoSuchElementException 异常
+    int i = cursor; // <1> i 记录当前 cursor 的位置
+    if (i >= size)
+        throw new NoSuchElementException();
+    // 判断如果超过 elementData 大小，说明可能被修改了，抛出 ConcurrentModificationException 异常
+    Object[] elementData = ArrayList.this.elementData;
+    if (i >= elementData.length)
+        throw new ConcurrentModificationException();
+    // <2> cursor 指向下一个位置
+    cursor = i + 1;
+    // <3> 返回当前位置的元素
+    return (E) elementData[lastRet = i]; // <4> 此处，会将 lastRet 指向当前位置
+}
+
+final void checkForComodification() {
+    if (modCount != expectedModCount)
+        throw new ConcurrentModificationException();
+}
+```
+
+- `<1>` 处，记录当前 `cursor` 的位置。因为我们当前返回的就是要求 `cursor` 位置的元素。
+- `<2>` 处，`cursor` 指向下一个位置。
+- `<3>` 处，返回当前位置的元素。同时在 `<4>` 处，会将 `lastRet` 指向当前位置。
+
+`#remove()` 方法，移除当前元素。代码如下：
+
+```
+// ArrayList.java#Itr
+
+public void remove() {
+    // 如果 lastRet 小于 0 ，说明没有指向任何元素，抛出 IllegalStateException 异常
+    if (lastRet < 0)
+        throw new IllegalStateException();
+    // 校验是否数组发生了变化
+    checkForComodification();
+
+    try {
+        // <1> 移除 lastRet 位置的元素
+        ArrayList.this.remove(lastRet);
+        // <2> cursor 指向 lastRet 位置，因为被移了，所以需要后退下
+        cursor = lastRet;
+        // <3> lastRet 标记为 -1 ，因为当前元素被移除了
+        lastRet = -1;
+        // <4> 记录新的数组的修改次数
+        expectedModCount = modCount;
+    } catch (IndexOutOfBoundsException ex) {
+        throw new ConcurrentModificationException();
+    }
+}
+```
+
+- `<1>` 处，调用 `#remove(int index)` 方法，移除 `lastRet` 位置的元素。所以，如果要注意，如果移除元素比较前面，会将后面位置的往前挪，即复制，可能比较消耗性能。
+- `<2>` 处，`cursor` 指向 `lastRet` 位置，因为被移了，所以需要后退下。
+- `<3>` 处，`lastRet` 标记为 `-1` ，因为当前元素被移除了。
+- `<4>` 处，记录新的数组的修改次数。因为此处修改了数组，如果不修改下，后续迭代肯定会报错。
+
+`#forEachRemaining(Consumer<? super E> action)` 方法，消费剩余未迭代的元素。代码如下：
+
+```
+// ArrayList.java#Itr
+
+@Override
+public void forEachRemaining(Consumer<? super E> action) {
+    // 要求 action 非空
+    Objects.requireNonNull(action);
+    // 获得当前数组大小
+    final int size = ArrayList.this.size;
+    // 记录 i 指向 cursor
+    int i = cursor;
+    if (i < size) {
+        // 判断如果超过 elementData 大小，说明可能被修改了，抛出 ConcurrentModificationException 异常
+        final Object[] es = elementData;
+        if (i >= es.length)
+            throw new ConcurrentModificationException();
+        // 逐个处理
+        for (; i < size && modCount == expectedModCount; i++)
+            action.accept(elementAt(es, i));
+        // update once at end to reduce heap write traffic
+        // 更新 cursor 和 lastRet 的指向
+        cursor = i;
+        lastRet = i - 1;
+        // 校验是否数组发生了变化
+        checkForComodification();
+    }
+}
+```
+
+- 比较简单，胖友自己瞅瞅。貌似平时这个方法用的不是很多。
+
+# 22. 创建 ListIterator 迭代器
+
+> 艿艿：可能一些胖友不了解 ListIterator 迭代器，因为平时使用不多。可以先去看看 [《Java 集合框架之 Iterator 和 ListIterator》](https://my.oschina.net/jackieyeah/blog/220134) 。简单来说，ListIterator 是为 List 设计的，功能更强大的 Iterator 迭代器。
+
+`#listIterator(...)` 方法，创建 ListIterator 迭代器。代码如下：
+
+```
+// ArrayList.java
+
+public ListIterator<E> listIterator(int index) {
+    rangeCheckForAdd(index);
+    return new ListItr(index);
+}
+
+public ListIterator<E> listIterator() {
+    return new ListItr(0);
+}
+```
+
+- 创建 ListItr 迭代器。ListItr 实现 [`java.util.ListIterator`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/util/ListIterator.java) 接口，是 ArrayList 的内部类。虽然说 AbstractList 也提供了一个 ListItr 的实现，但是 ArrayList 为了更好的性能，所以自己实现了，在其类上也有注释“An optimized version of AbstractList.ListItr”。
+
+ListItr 直接继承 Itr 类，无自定义的属性。代码如下：
+
+```
+// ArrayList.java#ListItr
+
+ListItr(int index) {
+    super();
+    cursor = index;
+}
+```
+
+- 可以手动设置指定的位置开始迭代。
+
+因为 ListItr 的实现代码比较简单，我们就不逐个来看了，直接贴加了注释的代码。代码如下：
+
+```
+// ArrayList.java#ListItr
+
+/**
+ * @return 是否有前一个
+ */
+public boolean hasPrevious() {
+    return cursor != 0;
+}
+
+/**
+ * @return 下一个位置
+ */
+public int nextIndex() {
+    return cursor;
+}
+
+/**
+ * @return 前一个位置
+ */
+public int previousIndex() {
+    return cursor - 1;
+}
+
+/**
+ * @return 前一个元素
+ */
+@SuppressWarnings("unchecked")
+public E previous() {
+    // 校验是否数组发生了变化
+    checkForComodification();
+    // 判断如果小于 0 ，抛出 NoSuchElementException 异常
+    int i = cursor - 1;
+    if (i < 0)
+        throw new NoSuchElementException();
+    // 判断如果超过 elementData 大小，说明可能被修改了，抛出 ConcurrentModificationException 异常
+    Object[] elementData = ArrayList.this.elementData;
+    if (i >= elementData.length)
+        throw new ConcurrentModificationException();
+    // cursor 指向上一个位置
+    cursor = i;
+    // 返回当前位置的元素
+    return (E) elementData[lastRet = i]; // 此处，会将 lastRet 指向当前位置
+}
+
+/**
+ * 设置当前元素
+ *
+ * @param e 设置的元素
+ */
+public void set(E e) {
+    // 如果 lastRet 无指向，抛出 IllegalStateException 异常
+    if (lastRet < 0)
+        throw new IllegalStateException();
+    // 校验是否数组发生了变化
+    checkForComodification();
+
+    try {
+        // 设置
+        ArrayList.this.set(lastRet, e);
+    } catch (IndexOutOfBoundsException ex) {
+        throw new ConcurrentModificationException();
+    }
+}
+
+/**
+ * 添加元素当当前位置
+ *
+ * @param e 添加的元素
+ */
+public void add(E e) {
+    // 校验是否数组发生了变化
+    checkForComodification();
+
+    try {
+        // 添加元素到当前位置
+        int i = cursor;
+        ArrayList.this.add(i, e);
+        // cursor 指向下一个位置，因为当前位置添加了新的元素，所以需要后挪
+        cursor = i + 1;
+        // lastRet 标记为 -1 ，因为当前元素并未访问
+        lastRet = -1;
+        // 记录新的数组的修改次数
+        expectedModCount = modCount;
+    } catch (IndexOutOfBoundsException ex) {
+        throw new ConcurrentModificationException();
+    }
+}
+```
+
+# 666. 彩蛋
+
+咳咳咳，比想象中的长的多的一篇文章。并且实际上，我们还有几个 ArrayList 的方法的解析没有写，如下：
+
+- `#spliterator()`
+- `#removeIf(Predicate<? super E> filter)`
+- `#replaceAll(UnaryOperator<E> operator)`
+- `#sort(Comparator<? super E> c)`
+- `#forEach(Consumer<? super E> action)`
+
+哈哈，也是比较简单的方法，胖友自己可以解决一波的哈。就当，课后作业？！嘿嘿。
+
+下面，我们来对 ArrayList 做一个简单的小结：
+
+- ArrayList 是基于 `[]` 数组实现的 List 实现类，支持在数组容量不够时，一般按照 **1.5** 倍**自动**扩容。同时，它支持**手动**扩容、**手动**缩容。
+
+- ArrayList 随机访问时间复杂度是 O(1) ，查找指定元素的**平均**时间复杂度是 O(n) 。
+
+  > 可能胖友对时间复杂度的计算方式不是很了解，可以看看 [《算法复杂度分析（上）：分析算法运行时，时间资源及空间资源的消耗》](https://www.cnblogs.com/jonins/p/9950799.html) 和 [《算法复杂度分析（下）：最好、最坏、平均、均摊等时间复杂度概述》](https://www.cnblogs.com/jonins/p/9956752.html) 两文。
+
+- ArrayList 移除指定位置的元素的最好时间复杂度是 O(1) ，最坏时间复杂度是 O(n) ，平均时间复杂度是 O(n) 。
+
+  > 最好时间复杂度发生在末尾移除的情况。
+
+- ArrayList 移除指定元素的时间复杂度是 O(n) 。
+
+  > 因为首先需要进行查询，然后在使用移除指定位置的元素，无论怎么计算，都需要 O(n) 的时间复杂度。
+
+- ArrayList 添加元素的最好时间复杂度是 O(1) ，最坏时间复杂度是 O(n) ，平均时间复杂度是 O(n) 。
+
+  > 最好时间复杂度发生在末尾添加的情况。
+
+结尾在抛个拓展，在 Redis String 的数据结构，实现方式是类似 Java ArrayList 的方式，感兴趣的胖友可以自己去瞅瞅。
\ No newline at end of file
diff --git a/jdk/04-JDK 源码解析-集合（二）链表 LinkedList.assets/01.jpg b/jdk/04-JDK 源码解析-集合（二）链表 LinkedList.assets/01.jpg
new file mode 100644
index 0000000..fdc17c1
Binary files /dev/null and b/jdk/04-JDK 源码解析-集合（二）链表 LinkedList.assets/01.jpg differ
diff --git a/jdk/04-JDK 源码解析-集合（二）链表 LinkedList.assets/02.jpg b/jdk/04-JDK 源码解析-集合（二）链表 LinkedList.assets/02.jpg
new file mode 100644
index 0000000..ae2f18f
Binary files /dev/null and b/jdk/04-JDK 源码解析-集合（二）链表 LinkedList.assets/02.jpg differ
diff --git a/jdk/04-JDK 源码解析-集合（二）链表 LinkedList.md b/jdk/04-JDK 源码解析-集合（二）链表 LinkedList.md
new file mode 100644
index 0000000..c2355a9
--- /dev/null
+++ b/jdk/04-JDK 源码解析-集合（二）链表 LinkedList.md	
@@ -0,0 +1,1279 @@
+# 精尽 JDK 源码解析 —— 集合（二）链表 LinkedList
+
+> 考虑到 LinkedList 和 ArrayList 是 List 绝代双骄，所以本文在编写的时候，尽量保持标题一致，方便胖友对比。
+>
+> 相比来说，LinkedList 会简单蛮多。看完本文后，胖友可以试着做下 [设计链表](https://leetcode-cn.com/problems/design-linked-list/) 题目。
+
+# 1. 概述
+
+LinkedList ，基于节点实现的**双向**链表的 List ，每个节点都指向前一个和后一个节点从而形成链表。
+
+相比 ArrayList 来说，我们日常开发使用 LinkedList 相对比较少。如果胖友打开 IDEA ，搜下项目中 LinkedList 后，会发现使用的少之又少。
+
+# 2. 类图
+
+LinkedList 实现的接口、继承的抽象类，如下图所示：[![类图](04-JDK 源码解析-集合（二）链表 LinkedList.assets/01.jpg)](http://static.iocoder.cn/images/JDK/2019_12_04/01.jpg)类图
+
+如下 3 个接口是 ArrayList 一致的：
+
+- [`java.util.List`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/util/List.java) 接口
+- [`java.io.Serializable`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/io/Serializable.java) 接口
+- [`java.lang.Cloneable`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/lang/Cloneable.java) 接口
+
+如下 1 个接口是少于 ArrayList 的：
+
+- [`java.util.RandomAccess`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/util/RandomAccess.java) 接口，LinkedList 不同于 ArrayList 的很大一点，不支持随机访问。
+
+如下 1 个接口是多于 ArrayList 的：
+
+- [`java.util.Deque`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/util/Deque.java) 接口，提供**双端**队列的功能，LinkedList 支持快速的在头尾添加元素和读取元素，所以很容易实现该特性。
+
+  > 注意，以为 LinkedList 实现了 Deque 接口，所以我们在 [「5. 添加单个元素」](https://svip.iocoder.cn/JDK/Collection-LinkedList/#) 和 [「7. 移除单个元素」](https://svip.iocoder.cn/JDK/Collection-LinkedList/#) 中，会看到多种方法，胖友可以快速看过去即可。😈 因为确实蛮多的。
+  >
+  > 也因为实现 Deque 即可以作为队列使用，也可以作为栈使用。当然，作为双端队列，也是可以的。
+
+继承了 [`java.util.AbstractSequentialList`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/util/AbstractSequentialList.java) 抽象类，它是 AbstractList 的子类，实现了只能**连续**访问“数据存储”（例如说链表）的 `#get(int index)`、`#add(int index, E element)` 等等**随机**操作的方法。可能这样表述有点抽象，胖友点到 [`java.util.AbstractSequentialList`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/util/AbstractSequentialList.java) 抽象类中看看这几个方法，基于迭代器顺序遍历后，从而实现后续的操作。
+
+- 但是呢，LinkedList 和 ArrayList 多是一个有点“脾气”的小伙子，都为了结合自身的特性，更加高效的实现，多选择了重写了 AbstractSequentialList 的方法，嘿嘿。
+- 不过一般情况下，对于支持随机访问数据的继承 AbstractList 抽象类，不支持的继承 AbstractSequentialList 抽象类。
+
+# 3. 属性
+
+LinkedList 一共有 **3** 个属性。如下图所示：
+
+[![LinkedList](04-JDK 源码解析-集合（二）链表 LinkedList.assets/02.jpg)](http://static.iocoder.cn/images/JDK/2019_12_04/02.jpg)LinkedList
+
+> 艿艿：发现自己真是画图鬼才，画的真丑，哈哈哈哈。
+
+- 通过 Node 节点指向前后节点，从而形成双向链表。
+
+- ```
+  first
+  ```
+
+   
+
+  和
+
+   
+
+  ```
+  last
+  ```
+
+   
+
+  属性：链表的头尾指针。
+
+  - 在初始时候，`first` 和 `last` 指向 `null` ，因为此时暂时没有 Node 节点。
+  - 在添加完首个节点后，创建对应的 Node 节点 `node1` ，前后指向 `null` 。此时，`first` 和 `last` 指向该 Node 节点。
+  - 继续添加一个节点后，创建对应的 Node 节点 `node2` ，其 `prev = node1` 和 `next = null` ，而 `node1` 的 `prev = null` 和 `next = node2` 。此时，`first` 保持不变，指向 `node1` ，`last` 发生改变，指向 `node2` 。
+
+- `size` 属性：链表的节点数量。通过它进行计数，避免每次需要 List 大小时，需要从头到尾的遍历。
+
+对应代码如下：
+
+```
+// LinkedList.java
+
+/**
+ * 链表大小
+ */
+transient int size = 0;
+
+/**
+ * 头节点
+ *
+ * Pointer to first node.
+ */
+transient Node<E> first;
+
+/**
+ * 尾节点
+ *
+ * Pointer to last node.
+ */
+transient Node<E> last;
+
+/**
+ * 节点
+ *
+ * @param <E> 元素泛型
+ */
+private static class Node<E> {
+
+    /**
+     * 元素
+     */
+    E item;
+    /**
+     * 前一个节点
+     */
+    Node<E> next;
+    /**
+     * 后一个节点
+     */
+    Node<E> prev;
+
+    Node(Node<E> prev, E element, Node<E> next) {
+        this.item = element;
+        this.next = next;
+        this.prev = prev;
+    }
+
+}
+```
+
+# 4. 构造方法
+
+ArrayList 一共有两个构造方法，我们分别来看看。代码如下：
+
+```
+public LinkedList() {
+}
+
+public LinkedList(Collection<? extends E> c) {
+    this();
+    // 添加 c 到链表中
+    addAll(c);
+}
+```
+
+相比 ArrayList 来说，因为没有容量一说，所以不需要提供 `#ArrayList(int initialCapacity)` 这样的构造方法。
+
+# 5. 添加单个元素
+
+`#add(E e)` 方法，**顺序**添加单个元素到链表。代码如下：
+
+```
+// LinkedList.java
+
+public boolean add(E e) {
+    // <X> 添加末尾
+    linkLast(e);
+    return true;
+}
+
+void linkLast(E e) {
+    // <1> 记录原 last 节点
+    final Node<E> l = last;
+    // <2> 创建新节点
+    // 第一个参数表示，newNode 的前一个节点为 l 。
+    // 第二个参数表示，e 为元素。
+    // 第三个参数表示，newNode 的后一个节点为 null 。
+    final Node<E> newNode = new Node<>(l, e, null);
+    // <3> last 指向新节点
+    last = newNode;
+    // <4.1> 如果原 last 为 null ，说明 first 也为空，则 first 也指向新节点
+    if (l == null)
+        first = newNode;
+    // <4.2> 如果原 last 非 null ，说明 first 也非空，则原 last 的 next 指向新节点。
+    else
+        l.next = newNode;
+    // <5> 增加链表大小
+    size++;
+    // <6> 增加数组修改次数
+    modCount++;
+}
+```
+
+- `<X>` 处，调用 `#linkLast(E e)` 方法，将新元素添加到链表的尾巴。所以，`#add(E e)` 方法，实际就是 `#linkLast(E e)` 方法。
+- 总体来说，代码实现比较简单。重点就是对 `last` 的处理。
+- 相比 ArrayList 来说，无需考虑容量不够时的扩容。
+
+看懂这个方法后，我们来看看 `#add(int index, E element)` 方法，**插入**单个元素到指定位置。代码如下：
+
+```
+// LinkedList.java
+
+public void add(int index, E element) {
+    // 校验不要超过范围
+    checkPositionIndex(index);
+
+    // <1> 如果刚好等于链表大小，直接添加到尾部即可
+    if (index == size)
+        linkLast(element);
+    // <2> 添加到第 index 的节点的前面
+    else
+        linkBefore(element, node(index));
+}
+```
+
+- `<1>` 处，如果刚好等于链表大小，直接调用 `#linkLast(E element)` 方法，添加到尾部即可。
+
+- `<2>` 处，先调用 `#node(int index)` 方法，获得第 `index` 位置的 Node 节点 `node` 。然后，调用 `#linkBefore(E element, Node node)` 方法，将新节点添加到 `node` 的前面。相当于说，`node` 的前一个节点的 `next` 指向新节点，`node` 的 `prev` 指向新节点。
+
+- `#node(int index)` 方法，获得第 `index` 个 Node 节点。代码如下：
+
+  ```
+  // LinkedList.java
+  
+  Node<E> node(int index) {
+      // assert isElementIndex(index);
+  
+      // 如果 index 小于 size 的一半，就正序遍历，获得第 index 个节点
+      if (index < (size >> 1)) {
+          Node<E> x = first;
+          for (int i = 0; i < index; i++)
+              x = x.next;
+          return x;
+      // 如果 index 大于 size 的一半，就倒序遍历，获得第 index 个节点
+      } else {
+          Node<E> x = last;
+          for (int i = size - 1; i > index; i--)
+              x = x.prev;
+          return x;
+      }
+  }
+  ```
+
+  - 这里 LinkedList 做的一个小骚操作，根据 `index` 是否超过链表的一半大小，选择是否使用倒序遍历替代正序遍历，从而减少遍历次数。
+
+- `#linkBefore(E e, Node<E> succ)` 方法，添加元素 `e` 到 `succ` 节点的前面。代码如下：
+
+  ```
+  // LinkedList.java
+  
+  void linkBefore(E e, Node<E> succ) {
+      // assert succ != null;
+      // 获得 succ 的前一个节点
+      final Node<E> pred = succ.prev;
+      // 创建新的节点 newNode
+      final Node<E> newNode = new Node<>(pred, e, succ);
+      // <Y> 设置 succ 的前一个节点为新节点
+      succ.prev = newNode;
+      // 如果 pred 为 null ，说明 first 也为空，则 first 也指向新节点
+      if (pred == null)
+          first = newNode;
+      // 如果 pred 非 null ，说明 first 也为空，则 pred 也指向新节点
+      else
+          pred.next = newNode;
+      // 增加链表大小
+      size++;
+      // 增加数组修改次数
+      modCount++;
+  }
+  ```
+
+  - 逻辑上，和 `#linkLast(E e)` 方法差不多。差别在于 `<Y>` 处，设置 `succ` 的前一个节点为新节点。
+
+因为 LinkedList 实现了 Deque 接口，所以它实现了 `#addFirst(E e)` 和 `#addLast(E e)` 方法，分别添加元素到链表的头尾。代码如下：
+
+```
+// LinkedList.java 实现 Deque 接口
+
+public void addFirst(E e) {
+    linkFirst(e);
+}
+public boolean offerFirst(E e) {
+    addFirst(e); // 调用上面的方法
+    return true;
+}
+
+public void addLast(E e) {
+    linkLast(e);
+}
+public boolean offerLast(E e) {
+    addLast(e); // 调用上面的方法
+    return true;
+}
+```
+
+- `#linkLast(E e)` 方法，和 `#add(E e)` 方法是一致的，就不哔哔了。
+
+- `#addFirst(E e)` 方法，调用 `#linkFirst(E e)` 方法，添加元素到队头。代码如下：
+
+  ```
+  // LinkedList.java
+  
+  private void linkFirst(E e) {
+      // 记录原 first 节点
+      final Node<E> f = first;
+      // 创建新节点
+      final Node<E> newNode = new Node<>(null, e, f);
+      // first 指向新节点
+      first = newNode;
+      // 如果原 first 为空，说明 last 也为空，则 last 也指向新节点
+      if (f == null)
+          last = newNode;
+      // 如果原 first 非空，说明 last 也非空，则原 first 的 next 指向新节点。
+      else
+          f.prev = newNode;
+      // 增加链表大小
+      size++;
+      // 增加数组修改次数
+      modCount++;
+  }
+  ```
+
+  - 逻辑上，和 `#linkLast(E e)` 方法差不多。就不重复哔哔了。
+
+因为 LinkedList 实现了 Queue 接口，所以它实现了 `#push(E e)` 和 `#offer(E e)` 方法，添加元素到链表的头尾。代码如下：
+
+```
+// LinkedList.java 实现 Queue 接口
+
+public void push(E e) {
+    addFirst(e);
+}
+
+public boolean offer(E e) {
+    return add(e);
+}
+```
+
+总的来说，添加单个元素，分成三个情况：
+
+- 添加元素到队头
+- 添加元素到队尾
+- 添加元素到中间
+
+对于链表的操作，代码会比较简洁，胖友如果不太理解，可以在草稿纸上手绘下整个过程。
+
+# 6. 链表扩容
+
+LinkedList 不存在扩容的需求，因为通过 Node 的前后指向即可。
+
+# 7. 添加多个元素
+
+`#addAll(Collection<? extends E> c)` 方法，批量添加多个元素。代码如下：
+
+```
+// LinkedList.java
+
+public boolean addAll(Collection<? extends E> c) {
+    return addAll(size, c);
+}
+
+public boolean addAll(int index, Collection<? extends E> c) {
+    checkPositionIndex(index);
+
+    // <1> 将 c 转成 a 数组
+    Object[] a = c.toArray();
+    int numNew = a.length;
+    if (numNew == 0) // 如果无添加元素，直接返回 false 数组未变更
+        return false;
+
+    // <2> 获得第 index 位置的节点 succ ，和其前一个节点 pred
+    Node<E> pred, succ;
+    if (index == size) { // 如果 index 就是链表大小，那说明插入队尾，所以 succ 为 null ，pred 为 last 。
+        succ = null;
+        pred = last;
+    } else { // 如果 index 小于链表大小，则 succ 是第 index 个节点，prev 是 succ 的前一个二节点。
+        succ = node(index);
+        pred = succ.prev;
+    }
+
+    // <3> 遍历 a 数组，添加到 pred 的后面
+    for (Object o : a) {
+        // 创建新节点
+        @SuppressWarnings("unchecked") E e = (E) o;
+        Node<E> newNode = new Node<>(pred, e, null);
+        // 如果 pred 为 null ，说明 first 也为 null ，则直接将 first 指向新节点
+        if (pred == null)
+            first = newNode;
+        // pred 下一个指向新节点
+        else
+            pred.next = newNode;
+        // 修改 pred 指向新节点
+        pred = newNode;
+    }
+
+    // <4> 修改 succ 和 pred 的指向
+    if (succ == null) { // 如果 succ 为 null ，说明插入队尾，则直接修改 last 指向最后一个 pred
+        last = pred;
+    } else { // 如果 succ 非 null ，说明插入到 succ 的前面
+        pred.next = succ; // prev 下一个指向 succ
+        succ.prev = pred; // succes 前一个指向 pred
+    }
+
+    // <5> 增加链表大小
+    size += numNew;
+    // <6> 增加数组修改次数
+    modCount++;
+    // 返回 true 数组有变更
+    return true;
+}
+```
+
+- `#addAll(Collection<? extends E> c)` 方法，其内部调用的是 `#addAll(int index, Collection<? extends E> c)` 方法，表示在队列之后，继续添加 `c` 集合。
+- `<2>` 处，获得第 `index` 位置的节点 `succ` ，和其前一个节点 `pred` 。分成两种情况，胖友自己看注释。实际上，ArrayList 在添加 `c` 集合的时候，也是分成跟 LinkedList 一样的两种情况，只是说 LinkedList 在一个方法统一实现了。
+- `<3>` 处，遍历 `a` 数组，添加到 `pred` 的后面。其实，我们可以把 `pred` 理解成“尾巴”，然后不断的指向新节点，而新节点又称为新的 `pred` 尾巴。如此反复插入~
+- `<4>` 处，修改 `succ` 和 `pred` 的指向。根据 `<2>` 处分的两种情况，进行处理。
+- 😈 虽然很长，但是还是很简单的。
+
+# 8. 移除单个元素
+
+`#remove(int index)` 方法，移除指定位置的元素，并返回该位置的原元素。代码如下：
+
+```
+// LinkedList.java
+
+public E remove(int index) {
+    checkElementIndex(index);
+    // 获得第 index 的 Node 节点，然后进行移除。
+    return unlink(node(index));
+}
+```
+
+- 首先，调用 `#node(int index)` 方法，获得第 `index` 的 Node 节点。然后偶，调用 `#unlink(Node<E> x)` 方法，移除该节点。
+
+- `#unlink(Node<E> x)` 方法，代码如下：
+
+  ```
+  // LinkedList.java
+  
+  E unlink(Node<E> x) {
+      // assert x != null;
+      // <1> 获得 x 的前后节点 prev、next
+      final E element = x.item;
+      final Node<E> next = x.next;
+      final Node<E> prev = x.prev;
+  
+      // <2> 将 prev 的 next 指向下一个节点
+      if (prev == null) { // <2.1> 如果 prev 为空，说明 first 被移除，则直接将 first 指向 next
+          first = next;
+      } else { // <2.2> 如果 prev 非空
+          prev.next = next; // prev 的 next 指向 next
+          x.prev = null; // x 的 pre 指向 null
+      }
+  
+      // <3> 将 next 的 prev 指向上一个节点
+      if (next == null) { // <3.1> 如果 next 为空，说明 last 被移除，则直接将 last 指向 prev
+          last = prev;
+      } else { // <3.2> 如果 next 非空
+          next.prev = prev; // next 的 prev 指向 prev
+          x.next = null; // x 的 next 指向 null
+      }
+  
+      // <4> 将 x 的 item 设置为 null ，帮助 GC
+      x.item = null;
+      // <5> 减少链表大小
+      size--;
+      // <6> 增加数组的修改次数
+      modCount++;
+      return element;
+  }
+  ```
+
+  - `<2>` 处，将 `prev` 的 `next` 指向下一个节点。其中，`<2.1>` 处，是移除队头 `first` 的情况。
+  - `<3>` 处，将 `next` 的 `prev` 指向上一个节点。其中，`<3.1>` 处，如果 `next` 为空，说明队尾 `last` 被移除的情况。
+  - 其它步骤，胖友自己看看代码注释。
+
+`#remove(Object o)` 方法，移除首个为 `o` 的元素，并返回是否移除到。代码如下：
+
+```
+// LinkedList.java
+
+public boolean remove(Object o) {
+    if (o == null) { // o 为 null 的情况
+        // 顺序遍历，找到 null 的元素后，进行移除
+        for (Node<E> x = first; x != null; x = x.next) {
+            if (x.item == null) {
+                unlink(x);
+                return true;
+            }
+        }
+    } else {
+        // 顺序遍历，找到等于 o 的元素后，进行移除
+        for (Node<E> x = first; x != null; x = x.next) {
+            if (o.equals(x.item)) {
+                unlink(x);
+                return true;
+            }
+        }
+    }
+    return false;
+}
+```
+
+- 相比 `#remove(int index)` 方法来说，需要去寻找首个等于 `o` 的节点进行移除。当然，最终还是调用 `#unlink(Node<E> x)` 方法，移除该节点。
+
+`#removeFirstOccurrence(Object o)` 和 `#removeLastOccurrence(Object o)` 方法，分别实现移除链表首个节点和最后节点。代码如下：
+
+```
+// LinkedList.java 实现 Deque 接口
+
+public boolean removeFirstOccurrence(Object o) { // 移除首个
+    return remove(o);
+}
+
+public boolean removeLastOccurrence(Object o) {
+    if (o == null) { // o 为 null 的情况
+        // 倒序遍历，找到 null 的元素后，进行移除
+        for (Node<E> x = last; x != null; x = x.prev) {
+            if (x.item == null) {
+                unlink(x);
+                return true;
+            }
+        }
+    } else {
+        // 倒序遍历，找到等于 o 的元素后，进行移除
+        for (Node<E> x = last; x != null; x = x.prev) {
+            if (o.equals(x.item)) {
+                unlink(x);
+                return true;
+            }
+        }
+    }
+    return false;
+}
+```
+
+`#remove()` 方法，移除链表首个节点。代码如下：
+
+```
+// LinkedList.java 实现 Queue 接口
+
+public E remove() {
+    return removeFirst();
+}
+
+public E removeFirst() {
+    final Node<E> f = first;
+    // <1> 如果链表为空，抛出 NoSuchElementException 异常
+    if (f == null)
+        throw new NoSuchElementException();
+    // <2> 移除链表时首个元素
+    return unlinkFirst(f);
+}
+
+private E unlinkFirst(Node<E> f) {
+    // assert f == first && f != null;
+    final E element = f.item;
+    // 获得 f 的下一个节点
+    final Node<E> next = f.next;
+    // 设置 f 的 item 为 null ，帮助 GC
+    f.item = null;
+    // 设置 f 的 next 为 null ，帮助 GC
+    f.next = null; // help GC
+    // 修改 fisrt 指向 next
+    first = next;
+    // 修改 next 节点的 prev 指向 null
+    if (next == null) // 如果链表只有一个元素，说明被移除后，队列就是空的，则 last 设置为 null
+        last = null;
+    else
+        next.prev = null;
+    // 链表大小减一
+    size--;
+    // 增加数组修改次数
+    modCount++;
+    return element;
+}
+```
+
+- `<1>` 处，如果链表为空，抛出 NoSuchElementException 异常。
+- `<2>` 处，移除链表时首个元素。比较简单，胖友自己看看。😈 因为 LinkedList 有 `first` 和 `last` 头尾节点，所以添加和删除操作，都可能需要小心处理。
+
+`#removeLast()` 方法，移除链表最后一个节点。代码如下：
+
+```
+// LinkedList.java 实现 Deque 接口
+
+public E removeLast() {
+    final Node<E> l = last;
+    // 如果链表为空，则抛出 NoSuchElementException 移除
+    if (l == null)
+        throw new NoSuchElementException();
+    // 移除链表的最后一个元素
+    return unlinkLast(l);
+}
+
+private E unlinkLast(Node<E> l) {
+    // assert l == last && l != null;
+    final E element = l.item;
+    // 获得 f 的上一个节点
+    final Node<E> prev = l.prev;
+    // 设置 l 的 item 为 null ，帮助 GC
+    l.item = null;
+    // 设置 l 的 prev 为 null ，帮助 GC
+    l.prev = null; // help GC
+    // 修改 last 指向 prev
+    last = prev;
+    // 修改 prev 节点的 next 指向 null
+    if (prev == null) // 如果链表只有一个元素，说明被移除后，队列就是空的，则 first 设置为 null
+        first = null;
+    else
+        prev.next = null;
+    // 链表大小减一
+    size--;
+    // 增加数组修改次数
+    modCount++;
+    return element;
+}
+```
+
+- 和 `#removeFirst()` 方法**相反**，当然实现上是差不多。
+
+`#poll()` 和 `#` 方法，移除链表的头或尾，差异点在于链表为空时候，不会抛出 NoSuchElementException 异常。代码如下：
+
+```
+// LinkedList.java 实现 Queue 接口
+
+public E poll() { // 移除头
+    final Node<E> f = first;
+    return (f == null) ? null : unlinkFirst(f);
+}
+
+public E pop() {
+    return removeFirst(); // 这个方法，如果队列为空，还是会抛出 NoSuchElementException 异常。😈 不知道放在哪里哈。这里来凑凑~
+}
+
+// LinkedList.java 实现 Deque 接口
+
+public E pollFirst() { // 移除头
+    final Node<E> f = first;
+    return (f == null) ? null : unlinkFirst(f);
+}
+
+public E pollLast() { // 移除尾
+    final Node<E> l = last;
+    return (l == null) ? null : unlinkLast(l);
+}
+```
+
+# 9. 移除多个元素
+
+`#removeAll(Collection<?> c)` 方法，批量移除指定的多个元素。代码如下：
+
+```
+// AbstractCollection.java
+
+public boolean removeAll(Collection<?> c) {
+    Objects.requireNonNull(c);
+    boolean modified = false;
+    // 获得迭代器
+    Iterator<?> it = iterator();
+    // 通过迭代器遍历
+    while (it.hasNext()) {
+        // 如果 c 中存在该元素，则进行移除
+        if (c.contains(it.next())) {
+            it.remove();
+            modified = true; // 标记修改
+        }
+    }
+    return modified;
+}
+```
+
+- 该方法，是通过父类 AbstractCollection 来实现的，通过迭代器来遍历 LinkedList ，然后判断 `c` 中如果包含，则进行移除。
+
+`#retainAll(Collection<?> c)` 方法，求 LinkedList 和指定多个元素的交集。简单来说，恰好和 `#removeAll(Collection<?> c)` 相反，移除不在 `c` 中的元素。代码如下：
+
+```
+// AbstractCollection.java
+
+public boolean retainAll(Collection<?> c) {
+    Objects.requireNonNull(c);
+    boolean modified = false;
+    // 获得迭代器
+    Iterator<E> it = iterator();
+    // 通过迭代器遍历
+    while (it.hasNext()) {
+        // <X> 如果 c 中不存在该元素，则进行移除
+        if (!c.contains(it.next())) {
+            it.remove();
+            modified = true;
+        }
+    }
+    return modified;
+}
+```
+
+- 逻辑比较简单，`<X>` 处的判断条件进行了调整。
+
+# 10. 查找单个元素
+
+`#indexOf(Object o)` 方法，查找首个为指定元素的位置。代码如下：
+
+```
+// LinkedList.java
+
+public int indexOf(Object o) {
+    int index = 0;
+    if (o == null) { // 如果 o 为 null 的情况
+        // 顺序遍历，如果 item 为 null 的节点，进行返回
+        for (Node<E> x = first; x != null; x = x.next) {
+            if (x.item == null)
+                return index; // 找到
+            index++;
+        }
+    } else { // 如果 o 非 null 的情况
+        // 顺序遍历，如果 item 为 o 的节点，进行返回
+        for (Node<E> x = first; x != null; x = x.next) {
+            if (o.equals(x.item))
+                return index; // 找到
+            index++;
+        }
+    }
+    // 未找到
+    return -1;
+}
+```
+
+而 `#contains(Object o)` 方法，就是基于该方法实现。代码如下：
+
+```
+// LinkedList.java
+
+public boolean contains(Object o) {
+    return indexOf(o) >= 0;
+}
+```
+
+有时我们需要查找最后一个为指定元素的位置，所以会使用到 `#lastIndexOf(Object o)` 方法。代码如下：
+
+```
+// LinkedList.java
+
+public int lastIndexOf(Object o) {
+    int index = size;
+    if (o == null) { // 如果 o 为 null 的情况
+        // 倒序遍历，如果 item 为 null 的节点，进行返回
+        for (Node<E> x = last; x != null; x = x.prev) {
+            index--;
+            if (x.item == null)
+                return index; // 找到
+        }
+    } else { // 如果 o 非 null 的情况
+        // 倒序遍历，如果 item 为 o 的节点，进行返回
+        for (Node<E> x = last; x != null; x = x.prev) {
+            index--;
+            if (o.equals(x.item))
+                return index; // 找到
+        }
+    }
+    // 未找到
+    return -1;
+}
+```
+
+# 11. 获得指定位置的元素
+
+`#get(int index)` 方法，获得指定位置的元素。代码如下：
+
+```
+// LinkedList.java
+
+public E get(int index) {
+    checkElementIndex(index);
+    // 基于 node(int index) 方法实现
+    return node(index).item;
+}
+```
+
+- 随机访问 `index` 位置的元素，时间复杂度为 O(n) 。
+
+因为 LinkedList 实现了 Deque 接口，所以它实现了 `#peekFirst()` 和 `#peekLast()` 方法，分别获得元素到链表的头尾。代码如下：
+
+```
+// LinkedList.java 实现 Deque 接口
+
+public E peekFirst() {
+    final Node<E> f = first;
+    return (f == null) ? null : f.item;
+}
+
+public E peekLast() {
+    final Node<E> l = last;
+    return (l == null) ? null : l.item;
+}
+```
+
+因为 LinkedList 实现了 Queue 接口，所以它实现了 `#peek()` 和 `#peek()` 和 `#element()` 方法，分别获得元素到链表的头。代码如下：
+
+```
+// LinkedList.java 实现 Queue 接口
+
+public E peek() {
+    final Node<E> f = first;
+    return (f == null) ? null : f.item;
+}
+
+public E element() { // 如果链表为空识，抛出 NoSuchElementException 异常
+    return getFirst();
+}
+public E getFirst() {
+    final Node<E> f = first;
+    if (f == null) // 如果链表为空识，抛出 NoSuchElementException 异常
+        throw new NoSuchElementException();
+    return f.item;
+}
+```
+
+# 12. 设置指定位置的元素
+
+`#set(int index, E element)` 方法，设置指定位置的元素。代码如下：
+
+```
+// LinkedList.java
+
+public E set(int index, E element) {
+    checkElementIndex(index);
+    // 获得第 index 位置的节点
+    Node<E> x = node(index);
+    E oldVal = x.item;
+    // 修改对应的值
+    x.item = element;
+    return oldVal;
+}
+```
+
+# 13. 转换成数组
+
+`#toArray()` 方法，将 ArrayList 转换成 `[]` 数组。代码如下：
+
+```
+// LinkedList.java
+
+public Object[] toArray() {
+    // 创建 Object 数组
+    Object[] result = new Object[size];
+    // 顺序遍历节点，设置到 Object 数组中
+    int i = 0;
+    for (Node<E> x = first; x != null; x = x.next)
+        result[i++] = x.item;
+    return result;
+}
+```
+
+实际场景下，我们可能想要指定 `T` 泛型的数组，那么我们就需要使用到 `#toArray(T[] a)` 方法。代码如下：
+
+```
+// LinkedList.java
+
+public <T> T[] toArray(T[] a) {
+    // <1> 如果传入的数组小于 size 大小，则直接复制一个新数组返回
+    if (a.length < size)
+        a = (T[])java.lang.reflect.Array.newInstance(
+                            a.getClass().getComponentType(), size);
+    // <2> 顺序遍历链表，复制到 a 中
+    int i = 0;
+    Object[] result = a;
+    for (Node<E> x = first; x != null; x = x.next)
+        result[i++] = x.item;
+
+    // <2.1> 如果传入的数组大于 size 大小，则将 size 赋值为 null
+    if (a.length > size)
+        a[size] = null;
+
+    // <2.2> 返回 a
+    return a;
+}
+```
+
+# 14. 求哈希值
+
+`#hashCode()` 方法，求 LinkedList 的哈希值。代码如下：
+
+```
+// AbstractList.java
+
+public int hashCode() {
+    int hashCode = 1;
+    // 遍历，求哈希
+    for (E e : this)
+        hashCode = 31*hashCode + (e==null ? 0 : e.hashCode());
+    return hashCode;
+}
+```
+
+- 该方法，是通过父类 AbstractList 来实现的，通过 `for` 来遍历 LinkedList ，然后进行求哈希。可能有胖友不了解 `for( : )` 语法糖，它最终会编译转换成 Iterator 迭代器。
+
+# 15. 判断相等
+
+`#equals(Object o)` 方法，判断是否相等。代码如下：
+
+```
+// AbstractList.java
+
+public boolean equals(Object o) {
+    // 如果 o 就是自己，直接返回 true
+    if (o == this)
+        return true;
+    // 如果不为 List 类型，直接返回 false
+    if (!(o instanceof List))
+        return false;
+
+    // 创建迭代器，顺序遍历比对
+    ListIterator<E> e1 = listIterator();
+    ListIterator<?> e2 = ((List<?>) o).listIterator();
+    while (e1.hasNext() && e2.hasNext()) {
+        E o1 = e1.next();
+        Object o2 = e2.next();
+        if (!(o1==null ? o2==null : o1.equals(o2))) // 如果不相等，返回 false
+            return false;
+    }
+    // 如果有迭代器没有遍历完，说明两者长度不等，所以就不相等；否则，就相等了
+    return !(e1.hasNext() || e2.hasNext());
+}
+```
+
+- 该方法，是通过父类 AbstractList 来实现的，通过迭代器，实现遍历比对。
+
+# 16. 清空链表
+
+`#clear()` 方法，清空链表。代码如下：
+
+```
+// LinkedList.java
+
+public void clear() {
+    // Clearing all of the links between nodes is "unnecessary", but:
+    // - helps a generational GC if the discarded nodes inhabit
+    //   more than one generation
+    // - is sure to free memory even if there is a reachable Iterator
+    // 顺序遍历链表，设置每个节点前后指向为 null
+    // 通过这样的方式，帮助 GC
+    for (Node<E> x = first; x != null; ) {
+        // 获得下一个节点
+        Node<E> next = x.next;
+        // 设置 x 的 item、next、prev 为空。
+        x.item = null;
+        x.next = null;
+        x.prev = null;
+        // 设置 x 为下一个节点
+        x = next;
+    }
+    // 清空 first 和 last 指向
+    first = last = null;
+    // 设置链表大小为 0
+    size = 0;
+    // 增加数组修改次数
+    modCount++;
+}
+```
+
+# 17. 序列化链表
+
+`#writeObject(java.io.ObjectOutputStream s)` 方法，实现 LinkedList 的序列化。代码如下：
+
+```
+// LinkedList.java
+
+@java.io.Serial
+private void writeObject(java.io.ObjectOutputStream s)
+    throws java.io.IOException {
+    // Write out any hidden serialization magic
+    // 写入非静态属性、非 transient 属性
+    s.defaultWriteObject();
+
+    // Write out size
+    // 写入链表大小
+    s.writeInt(size);
+
+    // Write out all elements in the proper order.
+    // 顺序遍历，逐个序列化
+    for (Node<E> x = first; x != null; x = x.next)
+        s.writeObject(x.item);
+}
+```
+
+# 18. 反序列化链表
+
+`#readObject(java.io.ObjectInputStream s)` 方法，反序列化数组。代码如下：
+
+```
+// LinkedList.java
+
+@java.io.Serial
+private void readObject(java.io.ObjectInputStream s)
+    throws java.io.IOException, ClassNotFoundException {
+    // Read in any hidden serialization magic
+    // 读取非静态属性、非 transient 属性
+    s.defaultReadObject();
+
+    // Read in size
+    // 读取 size
+    int size = s.readInt();
+
+    // Read in all elements in the proper order.
+    // 顺序遍历，逐个反序列化
+    for (int i = 0; i < size; i++)
+        linkLast((E)s.readObject()); // 添加到链表尾部
+}
+```
+
+# 19. 克隆
+
+`#clone()` 方法，克隆 LinkedList 对象。代码如下：
+
+```
+// LinkedList.java
+
+public Object clone() {
+    // 调用父类，进行克隆
+    LinkedList<E> clone = superClone();
+
+    // Put clone into "virgin" state
+    // 重置 clone 为初始化状态
+    clone.first = clone.last = null;
+    clone.size = 0;
+    clone.modCount = 0;
+
+    // Initialize clone with our elements
+    // 遍历遍历，逐个添加到 clone 中
+    for (Node<E> x = first; x != null; x = x.next)
+        clone.add(x.item);
+
+    return clone;
+}
+```
+
+- 注意，`first`、`last` 等都是重新初始化进来，不与原 LinkedList 共享。
+
+# 20. 创建子数组
+
+`#subList(int fromIndex, int toIndex)` 方法，创建 ArrayList 的子数组。代码如下：
+
+```
+// AbstractList.java
+
+public List<E> subList(int fromIndex, int toIndex) {
+    subListRangeCheck(fromIndex, toIndex, size());
+    // 根据判断 RandomAccess 接口，判断是否支持随机访问
+    return (this instanceof RandomAccess ?
+            new RandomAccessSubList<>(this, fromIndex, toIndex) :
+            new SubList<>(this, fromIndex, toIndex));
+}
+```
+
+- 该方法，是通过父类 AbstractList 来实现的。
+- 根据判断 RandomAccess 接口，判断是否支持随机访问，从而创建 RandomAccessSubList 或 SubList 对象。这里，我们就不拓展开解析这两个类，感兴趣的胖友自己去瞅瞅噢。
+
+# 21. 创建 Iterator 迭代器
+
+`#iterator()` 方法，创建迭代器。代码如下：
+
+```
+// AbstractSequentialList.java
+public Iterator<E> iterator() {
+    return listIterator();
+}
+
+// AbstractList.java
+public ListIterator<E> listIterator() {
+    return listIterator(0);
+}
+
+// AbstractSequentialList.java
+public abstract ListIterator<E> listIterator(int index);
+```
+
+- 该方法，是通过父类 AbstractSequentialList 来实现的。
+- 整个调用过程是，`iterator() => listIterator() => listIterator(int index)` 的顺序，就是我们在代码里贴进去的顺序。最终呢，是调用 LinkedList 对 `#listIterator(int index)` 的实现，我们在 [「22. 创建 ListIterator 迭代器」](https://svip.iocoder.cn/JDK/Collection-LinkedList/#) 小节来看。
+
+# 22. 创建 ListIterator 迭代器
+
+`#listIterator(int index)` 方法，创建 ListIterator 迭代器。代码如下：
+
+```
+// LinkedList.java
+
+public ListIterator<E> listIterator(int index) {
+    checkPositionIndex(index);
+    return new ListItr(index);
+}
+```
+
+- 创建 ListItr 迭代器。
+
+因为 ListItr 的实现代码比较简单，我们就不逐个来看了，直接贴加了注释的代码。代码如下：
+
+```
+// LinkedList.java
+
+private class ListItr implements ListIterator<E> {
+
+    /**
+     * 最后返回的节点
+     */
+    private Node<E> lastReturned;
+    /**
+     * 下一个节点
+     */
+    private Node<E> next;
+    /**
+     * 下一个访问元素的位置，从下标 0 开始。
+     *
+     * 主要用于 {@link #nextIndex()} 中，判断是否遍历结束
+     */
+    private int nextIndex;
+    /**
+     * 创建迭代器时，数组修改次数。
+     *
+     * 在迭代过程中，如果数组发生了变化，会抛出 ConcurrentModificationException 异常。
+     */
+    private int expectedModCount = modCount;
+
+    ListItr(int index) {
+        // assert isPositionIndex(index);
+        // 获得下一个节点
+        next = (index == size) ? null : node(index);
+        // 下一个节点的位置
+        nextIndex = index;
+    }
+
+    public boolean hasNext() {
+        return nextIndex < size;
+    }
+
+    public E next() {
+        // 校验是否数组发生了变化
+        checkForComodification();
+        // 如果已经遍历到结尾，抛出 NoSuchElementException 异常
+        if (!hasNext())
+            throw new NoSuchElementException();
+
+        // lastReturned 指向，记录最后访问节点
+        lastReturned = next;
+        // next 指向，下一个节点
+        next = next.next;
+        // 下一个节点的位置 + 1
+        nextIndex++;
+        // 返回 lastReturned
+        return lastReturned.item;
+    }
+
+    public boolean hasPrevious() {
+        return nextIndex > 0;
+    }
+
+    public E previous() {
+        // 校验是否数组发生了变化
+        checkForComodification();
+        // 如果已经遍历到结尾，抛出 NoSuchElementException 异常
+        if (!hasPrevious())
+            throw new NoSuchElementException();
+
+        // 修改 lastReturned 和 next 的指向。此时，lastReturned 和 next 是相等的。
+        lastReturned = next = (next == null) ? last : next.prev;
+        // 下一个节点的位置 - 1
+        nextIndex--;
+        // 返回 lastReturned
+        return lastReturned.item;
+    }
+
+    public int nextIndex() {
+        return nextIndex;
+    }
+
+    public int previousIndex() {
+        return nextIndex - 1;
+    }
+
+    public void remove() {
+        // 校验是否数组发生了变化
+        checkForComodification();
+        // 如果 lastReturned 为空，抛出 IllegalStateException 异常，因为无法移除了。
+        if (lastReturned == null)
+            throw new IllegalStateException();
+
+        // 获得 lastReturned 的下一个
+        Node<E> lastNext = lastReturned.next;
+        // 移除 lastReturned 节点
+        unlink(lastReturned);
+        // 此处，会分成两种情况
+        if (next == lastReturned) // 说明发生过调用 `#previous()` 方法的情况，next 指向下一个节点，而 nextIndex 是无需更改的
+            next = lastNext;
+        else
+            nextIndex--; // nextIndex 减一。
+
+        // 设置 lastReturned 为空
+        lastReturned = null;
+        // 增加数组修改次数
+        expectedModCount++;
+    }
+
+    public void set(E e) {
+        // 如果 lastReturned 为空，抛出 IllegalStateException 异常，因为无法修改了。
+        if (lastReturned == null)
+            throw new IllegalStateException();
+        // 校验是否数组发生了变化
+        checkForComodification();
+        // 修改 lastReturned 的 item 为 e
+        lastReturned.item = e;
+    }
+
+    public void add(E e) {
+        // 校验是否数组发生了变化
+        checkForComodification();
+        // 设置 lastReturned 为空
+        lastReturned = null;
+        // 此处，会分成两种情况
+        if (next == null) // 如果 next 已经遍历到尾，则 e 作为新的尾节点，进行插入。算是性能优化
+            linkLast(e);
+        else // 插入到 next 的前面
+            linkBefore(e, next);
+        // nextIndex 加一。
+        nextIndex++;
+        // 增加数组修改次数
+        expectedModCount++;
+    }
+
+    public void forEachRemaining(Consumer<? super E> action) {
+        Objects.requireNonNull(action);
+        // 遍历剩余链表
+        while (modCount == expectedModCount && nextIndex < size) {
+            // 执行 action 逻辑
+            action.accept(next.item);
+            // lastReturned 指向 next
+            lastReturned = next;
+            //  next 指向下一个节点
+            next = next.next;
+            // nextIndex 加一。
+            nextIndex++;
+        }
+        // 校验是否数组发生了变化
+        checkForComodification();
+    }
+
+    final void checkForComodification() {
+        if (modCount != expectedModCount)
+            throw new ConcurrentModificationException();
+    }
+
+}
+```
+
+- 虽然有点长，但是保持淡定哟。
+
+# 666. 彩蛋
+
+咳咳咳，总体还是有点长，不过相比 ArrayList 来说，LinkedList 确实简单蛮多。主要篇幅长的原因，还是因为 LinkedList 实现了 Deque 接口，需要多实现很多方法。
+
+下面，我们来对 LinkedList 做一个简单的小结：
+
+- LinkedList 基于节点实现的**双向**链表的 List ，每个节点都指向前一个和后一个节点从而形成链表。
+
+- LinkedList 提供队列、双端队列、栈的功能。
+
+  > 因为 `first` 节点，所以提供了队列的功能的实现的功能。
+  > 因为 `last` 节点，所以提供了栈的功能的实现的功能。
+  > 因为同时具有 `first` + `last` 节点，所以提供了双端队列的功能。
+
+- LinkedList 随机访问**平均**时间复杂度是 O(n) ，查找指定元素的**平均**时间复杂度是 O(n) 。
+
+- LinkedList 移除指定位置的元素的最好时间复杂度是 O(1) ，最坏时间复杂度是 O(n) ，平均时间复杂度是 O(n) 。
+
+  > 最好时间复杂度发生在头部、或尾部移除的情况。
+
+- LinkedList 移除指定位置的元素的最好时间复杂度是 O(1) ，最坏时间复杂度是 O(n) ，平均时间复杂度是 O(n) 。
+
+  > 最好时间复杂度发生在头部移除的情况。
+
+- LinkedList 添加元素的最好时间复杂度是 O(1) ，最坏时间复杂度是 O(n) ，平均时间复杂度是 O(n) 。
+
+  > 最好时间复杂度发生在头部、或尾部添加的情况。
+
+因为 LinkedList 提供了多种添加、删除、查找的方法，会根据是否能够找到对应的元素进行操作，抛出 NoSuchElementException 异常。我们整理了一个表格，避免胖友错误使用。
+
+|      | 返回结果                                           | 抛出异常    |
+| :--- | :------------------------------------------------- | :---------- |
+| 添加 | `#add(…)`、`#offset(...)`                          |             |
+| 删除 | `#remove(int index)`、`#remove(E e)`、`#poll(E E)` | `#remove()` |
+| 查找 | `#get(int index)`、`#peek()`                       | `#poll()`   |
+
+😈 这个表主要整理了 List 和 Queue 的操作，暂时没有整理 Deque 的操作。因为，Deque 相同前缀的方法，表现结果同 Queue 。
+
+OK ，还是在结尾抛个拓展，在 Redis List 的数据结构，实现方式是类似 Java LinkedList 的方式，感兴趣的胖友可以自己去瞅瞅。
\ No newline at end of file
diff --git a/jdk/05-JDK 源码解析-集合（三）哈希表 HashMap.assets/01.jpg b/jdk/05-JDK 源码解析-集合（三）哈希表 HashMap.assets/01.jpg
new file mode 100644
index 0000000..c07ac81
Binary files /dev/null and b/jdk/05-JDK 源码解析-集合（三）哈希表 HashMap.assets/01.jpg differ
diff --git a/jdk/05-JDK 源码解析-集合（三）哈希表 HashMap.assets/02.jpg b/jdk/05-JDK 源码解析-集合（三）哈希表 HashMap.assets/02.jpg
new file mode 100644
index 0000000..b12e2b5
Binary files /dev/null and b/jdk/05-JDK 源码解析-集合（三）哈希表 HashMap.assets/02.jpg differ
diff --git a/jdk/05-JDK 源码解析-集合（三）哈希表 HashMap.assets/03.jpg b/jdk/05-JDK 源码解析-集合（三）哈希表 HashMap.assets/03.jpg
new file mode 100644
index 0000000..fc54959
Binary files /dev/null and b/jdk/05-JDK 源码解析-集合（三）哈希表 HashMap.assets/03.jpg differ
diff --git a/jdk/05-JDK 源码解析-集合（三）哈希表 HashMap.assets/04.jpg b/jdk/05-JDK 源码解析-集合（三）哈希表 HashMap.assets/04.jpg
new file mode 100644
index 0000000..69cdd0c
Binary files /dev/null and b/jdk/05-JDK 源码解析-集合（三）哈希表 HashMap.assets/04.jpg differ
diff --git a/jdk/05-JDK 源码解析-集合（三）哈希表 HashMap.md b/jdk/05-JDK 源码解析-集合（三）哈希表 HashMap.md
new file mode 100644
index 0000000..530deae
--- /dev/null
+++ b/jdk/05-JDK 源码解析-集合（三）哈希表 HashMap.md	
@@ -0,0 +1,1430 @@
+# 精尽 JDK 源码解析 —— 集合（三）哈希表 HashMap
+
+# 1. 简介
+
+HashMap ，是一种[散列表](https://zh.wikipedia.org/wiki/哈希表)，用于存储 key-value 键值对的数据结构，一般翻译为“哈希表”，提供**平均**时间复杂度为 O(1) 的、基于 key 级别的 get/put 等操作。
+
+之前我们在分享 [《精尽 JDK 源码解析 —— 集合（一）数组 ArrayList》](http://svip.iocoder.cn/JDK/Collection-ArrayList) 中提到过，“在前些年，实习或初级工程师的面试，可能最爱问的就是 ArrayList 和 LinkedList 的区别与使用场景”。现在已经改变成，HashMap 的实现原理是什么。😈 相信令大多数胖友头疼不已，有木有噢。
+
+在日常的业务开发中，HashMap 可以说是和 ArrayList 一样常用的集合类，特别是考虑到数据库的性能，又或者服务的拆分后，我们把关联数据的拼接，放到了内存中，这就需要使用到 HashMap 了。
+
+# 2. 类图
+
+HashMap 实现的接口、继承的抽象类，如下图所示：[![类图](05-JDK 源码解析-集合（三）哈希表 HashMap.assets/03.jpg)](http://static.iocoder.cn/images/JDK/2019_12_07/03.jpg)类图
+
+- 实现 [`java.util.Map`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/util/Map.java) 接口，并继承 [`java.util.AbstractMap`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/util/AbstractMap.java) 抽像类。
+- 实现 [`java.io.Serializable`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/io/Serializable.java) 接口。
+- 实现 [`java.lang.Cloneable`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/lang/Cloneable.java) 接口。
+
+# 3. 属性
+
+在开始看 HashMap 的具体属性之前，我们先来简单说说 HashMap 的实现原理。
+
+> 艿艿：实际上，我更加推荐大家去看 [《数据结构与算法》](http://www.iocoder.cn/images/jikeshijian/数据结构与算法之美.jpg) 的《散列表》章节。一方面是确实讲的有趣生动又系统，另一方面自己有几个知识盲点在里面解决了。
+
+相信很多胖友，在初次看到 HashMap 时，都惊奇于其 **O(1)** 的 get 操作的时间复杂度。当时在我们已知的数据结构中，只有基于下标访问数组时，才能提供 **O(1)** get 操作的时间复杂度。
+
+实际上，HashMap 所提供的 O(1) 是**平均**时间复杂度，大多数情况下保证 O(1) 。其实极端情况下，有可能退化为 O(N) 的时间复杂度噢，这又是为什么呢？
+
+HashMap 其实是在数组的基础上实现的，一个“加强版”的数组。如下图所示：[![数组](05-JDK 源码解析-集合（三）哈希表 HashMap.assets/01.jpg)](http://static.iocoder.cn/images/JDK/2019_12_07/01.jpg)数组
+
+好像有点不对？！key 并不是一个整数，可以放入指向数组中的指定下标。咳咳咳，我们要 O(1) 的性能！！！所以，**hash** 就正式登场了，通过 `hash(key)` 的过程，我们可以将 key 成功的转成一个整数。但是，`hash(key)` 可能会超过数组的容量，所以我们需要 `hash(key) % size` 作为下标，放入数组的对应位置。至此，我们是不是已经可以通过 O(1) 的方式，快速的从 HashMap 中进行 get 读取操作了。
+
+> 注意，一般每个数组的“位置”，比较专业的说法，叫做“槽位”（slot）或者“桶”。因为代码注释里，已经都使用了“位置”，所以我们就暂时不进行修正了。
+
+😈 好像还是不对！？原因有两点：
+
+- 1、`hash(key)` 计算出来的哈希值，并不能保证唯一；
+- 2、`hash(key) % size` 的操作后，即使不同的哈希值，也可能变成相同的结果。
+
+这样，就导致我们常说的“哈希冲突”。那么怎么解决呢？方法有两种：
+
+- 1、开放寻址法
+
+  > 本文暂时不展开关于开放寻址法的内容，胖友可以看看 [《散列表的开放寻址法》](https://blog.csdn.net/zuoyigexingfude/article/details/40394859) 。等后面我们写到 ThreadLocalMap 的时候，我们在详细掰扯掰扯。
+
+- 2、链表法
+
+在 Java HashMap 中，采用了链表法。如果有看过 Redis Hash 数据结构的胖友，它也是采用了链表法。通过将数组的每个元素对应一个链表，我们将相同的 `hash(key) % size` 放到对应下标的链表中即可。
+
+> 当然，put / get 操作需要做下是否等于指定 key 的判断，这个具体我们在源码中分享。
+
+仿佛一切都很美好，但是我们试着来想，如果我们放入的 N 个 key-value 键值对到 HashMap 的情况：
+
+- 1、每个 key 经过 `hash(key) % size` 对应唯一下标，则 get 时间复杂度是 O(1) 。
+- 2、k 个 key 经过 `hash(key) % size` 对应唯一下标，那么在 get 这 k 个 key 的时间复杂度是 O(k) 。
+- 3、在情况 2 的极端情况下，k 恰好等于 N ，那么是不是就出现我们在上面说的 O(N) 的时间复杂度的情况。
+
+所以，为了解决最差 O(N) 的时间复杂度的情况，我们可以将数组的每个元素对应成其它数据结构，例如说：1）红黑树；2）跳表。它们两者的时间复杂度是 O(logN) ，这样 O(N) 就可以缓解成 O(logN) 的时间复杂度。
+
+> 😈 红黑树是相对复杂的数据结构，= = 反正艿艿没花时间去深究它，所以本文关于 HashMap 红黑树部分的源码，也并不会去分析。同时，也不是很建议胖友去看，因为看 HashMap 重点是搞懂 HashMap 本身。
+>
+> 当然，对红黑树感兴趣的胖友，还是可以单独去看的。
+>
+> 另外，跳表是我们一定要掌握甚至必须能够手写代码的数据结构，在 Redis Zset 数据结果，就采用了改造过的跳表。
+
+- 在 JDK7 的版本中，HashMap 采用“数组 + 链表”的形式实现。
+
+- 在 JDK8 开始的版本，HashMap 采用“数组 + 链表 + 红黑树”的形式实现，在空间和时间复杂度中做取舍。
+
+  > 这一点和 Redis 是相似的，即使是一个数据结构，可能内部采用多种数据结构，混合实现，为了平衡空间和时间复杂度。毕竟，时间不是唯一的因素，我们还需要考虑内存的情况。
+
+如此，HashMap 的整体结构如下图：[![HashMap](05-JDK 源码解析-集合（三）哈希表 HashMap.assets/02.jpg)](http://static.iocoder.cn/images/JDK/2019_12_07/02.jpg)HashMap
+
+这样就结束了么？既然这么问，肯定还有故事，那就是“扩容”。我们是希望 HashMap 尽可能能够达到 O(1) 的时间复杂度，链表法只是我们解决哈希冲突的无奈之举。而在 O(1) 的时间复杂度，基本是“一个萝卜一个坑”，所以在 HashMap 的 key-value 键值对数量达到阀值后，就会进行**扩容**。
+
+那么阀值是什么，又是怎么计算呢？此时就引入**负载因子**的概念。我们假设 HashMap 的数组容量为 `capacity` ，key-value 键值对数量为 `size` ，负载因子为 `loadFactor` 。那么，当 `capacity / size > loadFactor` 时，也就是使用的数组大小到达 `loadFactor` 比例时，我们就需要进行扩容。如此，我们便可以尽量达到“一个萝卜一个坑”的目的，从而尽可能的 O(1) 的时间复杂度。
+
+> 🐱 貌似写了大 2000 字了。如果有不理解的地方，可以星球里给艿艿提问。
+>
+> 当然，我们也可以结合下面的 HashMap 源码，更好的理解 HashMap 的实现原理。毕竟，源码之前，了无秘密。
+>
+> 不过，还是再次推荐 [《数据结构与算法》](http://www.iocoder.cn/images/jikeshijian/数据结构与算法之美.jpg) ，写的真好，羡慕~
+
+哔哔了这么多，重点就是几处：
+
+- 哈希 key
+- 哈希冲突的解决
+- 扩容
+
+------
+
+下面，我们来看看 HashMap 的属性。代码如下：
+
+```
+// HashMap.java
+
+/* ---------------- Fields -------------- */
+
+/**
+ * 底层存储的数组
+ *
+ * The table, initialized on first use, and resized as
+ * necessary. When allocated, length is always a power of two.
+ * (We also tolerate length zero in some operations to allow
+ * bootstrapping mechanics that are currently not needed.)
+ */
+transient Node<K,V>[] table;
+
+/**
+ * 调用 `#entrySet()` 方法后的缓存
+ *
+ * Holds cached entrySet(). Note that AbstractMap fields are used
+ * for keySet() and values().
+ */
+transient Set<Map.Entry<K,V>> entrySet;
+
+/**
+ * key-value 的键值对数量
+ *
+ * The number of key-value mappings contained in this map.
+ */
+transient int size;
+
+/**
+ * HashMap 的修改次数
+ *
+ * The number of times this HashMap has been structurally modified
+ * Structural modifications are those that change the number of mappings in
+ * the HashMap or otherwise modify its internal structure (e.g.,
+ * rehash).  This field is used to make iterators on Collection-views of
+ * the HashMap fail-fast.  (See ConcurrentModificationException).
+ */
+transient int modCount;
+
+/**
+ * 阀值，当 {@link #size} 超过 {@link #threshold} 时，会进行扩容
+ *
+ * The next size value at which to resize (capacity * load factor).
+ *
+ * @serial
+ */
+// (The javadoc description is true upon serialization.
+// Additionally, if the table array has not been allocated, this
+// field holds the initial array capacity, or zero signifying
+// DEFAULT_INITIAL_CAPACITY.)
+int threshold;
+
+/**
+ * 扩容因子
+ *
+ * The load factor for the hash table.
+ *
+ * @serial
+ */
+final float loadFactor;
+```
+
+- 胖友重点看下 `table`、`size`、`threshold`、`loadFactor` 四个属性。
+
+具体的解释，我们在「4. 构造方法」中来看。这里我们先来看看 `table` Node 数组。代码如下：
+
+```
+// HashMap.java#Node.java
+
+static class Node<K,V> implements Map.Entry<K,V> {
+
+    /**
+     * 哈希值
+     */
+    final int hash;
+    /**
+     * KEY 键
+     */
+    final K key;
+    /**
+     * VALUE 值
+     */
+    V value;
+    /**
+     * 下一个节点
+     */
+    Node<K,V> next;
+
+    // ... 省略实现方法
+
+}
+```
+
+- 实现了 Map.Entry 接口，该接口定义在 [`java.util.Map`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/util/Map.java) 接口中。相信这个接口，胖友已经很熟悉了，就不重复哔哔了。
+- `hash` + `key` + `value` 属性，定义了 Node 节点的 3 个重要属性。
+- `next` 属性，指向下一个节点。通过它可以实现 `table` 数组的每一个位置可以形成链表。
+
+Node 子类如下图：[![Node 子类类图](05-JDK 源码解析-集合（三）哈希表 HashMap.assets/04.jpg)](http://static.iocoder.cn/images/JDK/2019_12_07/04.jpg)Node 子类类图
+
+- TreeNode ，定义在 HashMap 中，红黑树节点。通过它可以实现 `table` 数组的每一个位置可以形成红黑树。因为本文不深入红黑树部分，所以我们也就不看 TreeNode 中的具体代码了。如果胖友自己对 HashMap 中的红黑树部分的实现，可以自己看看这块的代码。
+
+# 4. 构造方法
+
+HashMap 一共有四个构造方法，我们分别来看看。
+
+**① `#HashMap()`**
+
+`#HashMap()` 构造方法，创建一个初始化容量为 16 的 HashMap 对象。代码如下：
+
+```
+// HashMap.java
+
+/**
+ * 默认的初始化容量
+ *
+ * The default initial capacity - MUST be a power of two.
+ */
+static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; // aka 16
+
+/**
+ * 默认加载因子为 0.75
+ *
+ * The load factor used when none specified in constructor.
+ */
+static final float DEFAULT_LOAD_FACTOR = 0.75f;
+
+/**
+ * Constructs an empty {@code HashMap} with the default initial capacity
+ * (16) and the default load factor (0.75).
+ */
+public HashMap() {
+    this.loadFactor = DEFAULT_LOAD_FACTOR; // all other fields defaulted
+}
+```
+
+- 初始化 `loadFactor` 为 `DEFAULT_LOAD_FACTOR = 0.75` 。
+- 在该构造方法上，我们并没有看到 `table` 数组的初始化。它是**延迟**初始化，在我们开始往 HashMap 中添加 key-value 键值对时，在 `#resize()` 方法中才真正初始化。
+
+**② `#HashMap(int initialCapacity)`**
+
+`#HashMap(int initialCapacity)` 方法，初始化容量为 `initialCapacity` 的 HashMap 对象。代码如下：
+
+```
+// HashMap.java
+
+public HashMap(int initialCapacity) {
+    this(initialCapacity, DEFAULT_LOAD_FACTOR);
+}
+```
+
+- 内部调用 `#HashMap(int initialCapacity, float loadFactor)` 构造方法。
+
+**③ `#HashMap(int initialCapacity, float loadFactor)`**
+
+`#HashMap(int initialCapacity, float loadFactor)` 构造方法，初始化容量为 `initialCapacity` 、加载因子为 `loadFactor` 的 HashMap 对象。代码如下：
+
+```
+// HashMap.java
+
+/**
+ * 最大的容量为 2^30 。
+ *
+ * The maximum capacity, used if a higher value is implicitly specified
+ * by either of the constructors with arguments.
+ * MUST be a power of two <= 1<<30.
+ */
+static final int MAXIMUM_CAPACITY = 1 << 30;
+
+public HashMap(int initialCapacity, float loadFactor) {
+    // 校验 initialCapacity 参数
+    if (initialCapacity < 0)
+        throw new IllegalArgumentException("Illegal initial capacity: " +
+                                           initialCapacity);
+    // 避免 initialCapacity 超过 MAXIMUM_CAPACITY
+    if (initialCapacity > MAXIMUM_CAPACITY)
+        initialCapacity = MAXIMUM_CAPACITY;
+    // 校验 loadFactor 参数
+    if (loadFactor <= 0 || Float.isNaN(loadFactor))
+        throw new IllegalArgumentException("Illegal load factor: " +
+                                           loadFactor);
+    // 设置 loadFactor 属性
+    this.loadFactor = loadFactor;
+    // <X> 计算 threshold 阀值
+    this.threshold = tableSizeFor(initialCapacity);
+}
+```
+
+- 我们重点来看 `<X>` 处，调用 `#tableSizeFor(int cap)` 方法，返回大于 `cap` 的最小 2 的 N 次方。例如说，`cap = 10` 时返回 16 ，`cap = 28` 时返回 32 。代码如下：
+
+  ```
+  // HashMap.java
+  
+  static final int tableSizeFor(int cap) {
+      // 将 cap 从最高位（最左边）第一个为 1 开始的位开始，全部设置为 1 。
+      int n = -1 >>> Integer.numberOfLeadingZeros(cap - 1);
+      // 因为 n 已经是 0..01..1 的情况，那么 n + 1 就能满足 cap 的最小 2 的 N 次方
+      // 在 cap 为 0 和 1 的时候，n 会为 -1 ，则此时最小 2 的 N 次方为 2^0 = 1 。
+      return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1;
+  }
+  ```
+
+  - 胖友先抛开里面的**位计算**，单纯看看这 2 行代码的注释。
+
+  - 理解之后，想要深究的就看看 [《Java8 —— HashMap 之tableSizeFor()》](https://www.jianshu.com/p/cbe3f22793be) 文章，不想的就继续跟着艿艿往下继续看 HashMap 的源码。
+
+    > 😈 看源码就是这样，需要先把重点给看完，不然就会陷入无限的调用栈的深入。当然，实在难受的，可以加一个“TODO 后续深入”之类的，回头在干。
+    >
+    > 总之，先整体，后局部。
+
+  - 那么，为什么这里的 `threshold` 要返回大于等于 `initialCapacity` 的最小 2 的 N 次方呢？
+
+    > 艿艿的理解，不一定正确，但是要哔哔下。
+    >
+    > 在 put 方法中，计算 `table` 数组对应的位置，逻辑是 `(n - 1) & hash` ，这个和我们预想的 `hash % (n - 1)` 的有差别。这两者在 `n` 是 2 的 N 次方情况下是等价的。那么考虑到性能，我们会选择 `&` 位操作。这样，就要求数组容量 `n` 要尽可能是 2 的 N 次方。
+    >
+    > 而在 `#resize()` 扩容方法中，我们会看到 HashMap 的容量，一直能够保证是 2 的 N 次方。
+    >
+    > 如此，`#tableSizeFor(int cap)` 方法，也需要保证返回的是 2 的 N 次方。
+
+**四 `#HashMap(Map<? extends K, ? extends V> m)`**
+
+`#HashMap(Map<? extends K, ? extends V> m)` 构造方法，创建 HashMap 对象，并将 `c` 集合添加到其中。代码如下：
+
+```
+// HashMap.java
+
+public HashMap(Map<? extends K, ? extends V> m) {
+    // 设置加载因子
+    this.loadFactor = DEFAULT_LOAD_FACTOR;
+    // <X> 批量添加到 table 中
+    putMapEntries(m, false);
+}
+```
+
+- `<X>` 处，调用 `#putMapEntries(Map<? extends K, ? extends V> m, boolean evict)` 方法，批量添加到 `table` 中。代码如下：
+
+  ```
+  // HashMap.java
+  
+  final void putMapEntries(Map<? extends K, ? extends V> m, boolean evict) {
+      int s = m.size();
+      // <1>
+      if (s > 0) {
+          // 如果 table 为空，说明还没初始化，适合在构造方法的情况
+          if (table == null) { // pre-size
+              // 根据 s 的大小 + loadFactor 负载因子，计算需要最小的 tables 大小
+              float ft = ((float)s / loadFactor) + 1.0F; // + 1.0F 的目的，是因为下面 (int) 直接取整，避免不够。
+              int t = ((ft < (float)MAXIMUM_CAPACITY) ?
+                       (int)ft : MAXIMUM_CAPACITY);
+              // 如果计算出来的 t 大于阀值，则计算新的阀值
+              if (t > threshold)
+                  threshold = tableSizeFor(t);
+          // 如果 table 非空，说明已经初始化，需要不断扩容到阀值超过 s 的数量，避免扩容
+          } else {
+              // Because of linked-list bucket constraints, we cannot
+              // expand all at once, but can reduce total resize
+              // effort by repeated doubling now vs later
+              while (s > threshold && table.length < MAXIMUM_CAPACITY)
+                  resize(); // 扩容
+          }
+  
+          // <2> 遍历 m 集合，逐个添加到 HashMap 中。
+          for (Map.Entry<? extends K, ? extends V> e : m.entrySet()) {
+              K key = e.getKey();
+              V value = e.getValue();
+              putVal(hash(key), key, value, false, evict);
+          }
+      }
+  }
+  ```
+
+  - 整个过程分成 `<1>` 和 `<2>` 的两个步骤。
+  - `<1>` 处，保证 `table` 容量足够，分成了 `table` 是否为空有不同的处理。可能胖友比较疑惑的是，`table` 为空的情况的处理？因为此时 `table` 未初始化，我们只需要保证 `threshold` 大于数组大小即可，在 put key-value 键值的时候，在去真正的初始化 `table` 就好咧。
+  - `<2>` 处，遍历 `m` 集合，逐个调用 `#putVal(hash, key, val, onlyIfAbsent, evict)` 方法，添加到 HashMap 中。关于这块的逻辑，我们本文的后面再来详细解析。
+
+# 5. 哈希函数
+
+对于哈希函数来说，有两个方面特别重要：
+
+- 性能足够高。因为基本 HashMap 所有的操作，都需要用到哈希函数。
+- 对于计算出来的哈希值足够离散，保证哈希冲突的概率更小。
+
+在 HashMap 中，`#hash(Object key)` 静态方法，计算 key 的哈希值。代码如下：
+
+```
+// HashMap.java
+
+static final int hash(Object key) {
+    int h;
+    // h = key.hashCode() 计算哈希值
+    // ^ (h >>> 16) 高 16 位与自身进行异或计算，保证计算出来的 hash 更加离散
+    return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
+}
+```
+
+- 高效性：从整个计算过程上来说，`^ (h >>> 16)` 只有这一块的逻辑，两个位操作，性能肯定是有保障的。那么，如果想要保证哈希函数的高效性，就需要传入的 `key` 自身的 `Object#hashCode()` 方法的高效即可。
+- 离散型：和大多数胖友有一样的疑惑，为什么有 `^ (h >>> 16)` 一段代码呢，总结来说，就是保证“hash 更加离散”。关于这块的解释，直接来看 [《JDK 源码中 HashMap 的 hash 方法原理是什么？》](https://www.zhihu.com/question/20733617/answer/111577937) 的胖君的解答 ，好强！
+
+# 6. 添加单个元素
+
+`#put(K key, V value)` 方法，添加单个元素。代码如下：
+
+```
+// HashMap.java
+
+public V put(K key, V value) {
+    // hash(key) 计算哈希值
+    return putVal(hash(key), key, value, false, true);
+}
+
+final V putVal(int hash, K key, V value, boolean onlyIfAbsent,
+               boolean evict) {
+    Node<K,V>[] tab; // tables 数组
+    Node<K,V> p; // 对应位置的 Node 节点
+    int n; // 数组大小
+    int i; // 对应的 table 的位置
+    // <1> 如果 table 未初始化，或者容量为 0 ，则进行扩容
+    if ((tab = table) == null || (n = tab.length) == 0)
+        n = (tab = resize() /*扩容*/ ).length;
+    // <2> 如果对应位置的 Node 节点为空，则直接创建 Node 节点即可。
+    if ((p = tab[i = (n - 1) & hash] /*获得对应位置的 Node 节点*/) == null)
+        tab[i] = newNode(hash, key, value, null);
+    // <3> 如果对应位置的 Node 节点非空，则可能存在哈希冲突
+    else {
+        Node<K,V> e; // key 在 HashMap 对应的老节点
+        K k;
+        // <3.1> 如果找到的 p 节点，就是要找的，则则直接使用即可
+        if (p.hash == hash && // 判断 hash 值相等
+            ((k = p.key) == key || (key != null && key.equals(k)))) // 判断 key 真正相等
+            e = p;
+        // <3.2> 如果找到的 p 节点，是红黑树 Node 节点，则直接添加到树中
+        else if (p instanceof TreeNode)
+            e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value);
+        // <3.3> 如果找到的 p 是 Node 节点，则说明是链表，需要遍历查找
+        else {
+            // 顺序遍历链表
+            for (int binCount = 0; ; ++binCount) {
+                // `(e = p.next)`：e 指向下一个节点，因为上面我们已经判断了最开始的 p 节点。
+                // 如果已经遍历到链表的尾巴，则说明 key 在 HashMap 中不存在，则需要创建
+                if ((e = p.next) == null) {
+                    // 创建新的 Node 节点
+                    p.next = newNode(hash, key, value, null);
+                    // 链表的长度如果数量达到 TREEIFY_THRESHOLD（8）时，则进行树化。
+                    if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st
+                        treeifyBin(tab, hash);
+                    break; // 结束
+                }
+                // 如果遍历的 e 节点，就是要找的，则则直接使用即可
+                if (e.hash == hash &&
+                    ((k = e.key) == key || (key != null && key.equals(k))))
+                    break; // 结束
+                // p 指向下一个节点
+                p = e;
+            }
+        }
+        // <4.1> 如果找到了对应的节点
+        if (e != null) { // existing mapping for key
+            V oldValue = e.value;
+            // 修改节点的 value ，如果允许修改
+            if (!onlyIfAbsent || oldValue == null)
+                e.value = value;
+            // 节点被访问的回调
+            afterNodeAccess(e);
+            // 返回老的值
+            return oldValue;
+        }
+    }
+    // <4.2>
+    // 增加修改次数
+    ++modCount;
+    // 如果超过阀值，则进行扩容
+    if (++size > threshold)
+        resize();
+    // 添加节点后的回调
+    afterNodeInsertion(evict);
+    // 返回 null
+    return null;
+}
+```
+
+- 有点长，不过逻辑上来说，简单的一笔噢。
+
+- `<1>` 处，如果 `table` 未初始化，或者容量为 0 ，则调用 `#resize()` 方法，进行扩容。
+
+- `<2>` 处，如果对应位置的 Node 节点为空，则直接创建 Node 节点即可。
+
+  - `i = (n - 1) & hash` 代码段，计算 `table` 所在对应位置的下标。😈 此处，结合我们在 `#tableSizeFor(int cap)` 方法，在理解一波。
+
+  - 调用 `#newNode(int hash, K key, V value, Node<K,V> next)` 方法，创建 Node 节点即可。代码如下：
+
+    ```
+    // HashMap.java
+    
+    Node<K,V> newNode(int hash, K key, V value, Node<K,V> next) {
+        return new Node<>(hash, key, value, next);
+    }
+    ```
+
+    - 这样，一个新的链表就出现了。当然，此处的 `next` 肯定是 `null` 。
+
+- `<3>` 处，如果对应位置的 Node 节点非空，则可能存在哈希冲突。需要分成 Node 节点是链表（`<3.3>`），还是红黑树（`<3.2>`）的情况。
+
+- `<3.1>` 处，如果找到的 `p` 节点，就是要找的，则则直接使用即可。这是一个优化操作，无论 Node 节点是链表还是红黑树。
+
+- `<3.2>` 处，如果找到的 `p` 节点，是红黑树 Node 节点，则调用 `TreeNode#putTreeVal(HashMap<K,V> map, Node<K,V>[] tab, int h, K k, V v)` 方法，直接添加到树中。这块，咱就先不深入了。
+
+- `<3.3>` 处，如果找到的 `p` 是 Node 节点，则说明是链表，需要遍历查找。比较简单，胖友自己看下代码注释即可。其中，`binCount >= TREEIFY_THRESHOLD - 1` 代码段，在链表的长度超过 `TREEIFY_THRESHOLD = 8` 的时候，会调用 `#treeifyBin(Node<K,V>[] tab, int hash)` 方法，将链表进行树化。当然，树化还有一个条件，具体在 [「TODO. 树化」](https://svip.iocoder.cn/JDK/Collection-HashMap/#) 中详细来看。
+
+- `<4>` 处，根据是否在 HashMap 中已经存在 key 对应的节点，有不同的处理。
+
+- ```
+  <4.1>
+  ```
+
+   
+
+  处，如果存在的情况，会有如下处理：
+
+  - 1）如果满足需要修改节点，则进行修改。
+  - 2）如果节点被访问时，调用 `#afterNodeAccess((Node<K,V> p)` 方法，节点被访问的回调。目前这是个一个空方法，用于 HashMap 的子类 LinkedHashMap 需要做的拓展逻辑。
+  - 3）返回老的值。
+
+- ```
+  <4.2>
+  ```
+
+   
+
+  处，如果不存在的情况，会有如下处理：
+
+  - 1）增加修改次数。
+  - 2）增加 key-value 键值对 `size` 数。并且 `size` 如果超过阀值，则调用 `#resize()` 方法，进行扩容。
+  - 3）调用 `#afterNodeInsertion(boolean evict)` 方法，添加节点后的回调。目前这是个一个空方法，用于 HashMap 的子类 LinkedHashMap 需要做的拓展逻辑。
+  - 4）返回 `null` ，因为老值不存在。
+
+> 艿艿：厚着脸皮来个互动。欢迎胖友在看完这块逻辑后，画个 HashMap 的 put 操作的流程图投稿给艿艿哟。
+
+`#putIfAbsent(K key, V value)` 方法，当 `key` 不存在的时候，添加 key-value 键值对到其中。代码如下：
+
+```
+// HashMap.java
+
+@Override
+public V putIfAbsent(K key, V value) {
+    return putVal(hash(key), key, value, true, true);
+}
+```
+
+# 7. 扩容
+
+`#resize()` 方法，**两倍扩容** HashMap 。实际上，我们在 [「4. 构造方法」](https://svip.iocoder.cn/JDK/Collection-HashMap/#) 中，看到 `table` 数组并未初始化，它是在 `#resize()` 方法中进行初始化，所以这是该方法的另外一个作用：**初始化数组**。代码如下：
+
+```
+// HashMap.java
+
+final Node<K,V>[] resize() {
+    Node<K,V>[] oldTab = table;
+    int oldCap = (oldTab == null) ? 0 : oldTab.length;
+    int oldThr = threshold;
+    int newCap, newThr = 0;
+    // <1> 开始：
+    // <1.1> oldCap 大于 0 ，说明 table 非空
+    if (oldCap > 0) {
+        // <1.1.1> 超过最大容量，则直接设置 threshold 阀值为 Integer.MAX_VALUE ，不再允许扩容
+        if (oldCap >= MAXIMUM_CAPACITY) {
+            threshold = Integer.MAX_VALUE;
+            return oldTab;
+        }
+        // <1.1.2> newCap = oldCap << 1 ，目的是两倍扩容
+        // 如果 oldCap >= DEFAULT_INITIAL_CAPACITY 满足，说明当前容量大于默认值（16），则 2 倍阀值。
+        else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY &&
+                 oldCap >= DEFAULT_INITIAL_CAPACITY)
+            newThr = oldThr << 1; // double threshold
+    }
+    // <1.2.1>【非默认构造方法】oldThr 大于 0 ，则使用 oldThr 作为新的容量
+    else if (oldThr > 0) // initial capacity was placed in threshold
+        newCap = oldThr;
+    // <1.2.2>【默认构造方法】oldThr 等于 0 ，则使用 DEFAULT_INITIAL_CAPACITY 作为新的容量，使用 DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY 作为新的容量
+    else {               // zero initial threshold signifies using defaults
+        newCap = DEFAULT_INITIAL_CAPACITY;
+        newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY);
+    }
+    // 1.3 如果上述的逻辑，未计算新的阀值，则使用 newCap * loadFactor 作为新的阀值
+    if (newThr == 0) {
+        float ft = (float)newCap * loadFactor;
+        newThr = (newCap < MAXIMUM_CAPACITY && ft < (float)MAXIMUM_CAPACITY ?
+                  (int)ft : Integer.MAX_VALUE);
+    }
+    // <2> 开始：
+    // 将 newThr 赋值给 threshold 属性
+    threshold = newThr;
+    // 创建新的 Node 数组，赋值给 table 属性
+    @SuppressWarnings({"rawtypes","unchecked"})
+    Node<K,V>[] newTab = (Node<K,V>[])new Node[newCap];
+    table = newTab;
+    // 如果老的 table 数组非空，则需要进行一波搬运
+    if (oldTab != null) {
+        for (int j = 0; j < oldCap; ++j) {
+            // 获得老的 table 数组第 j 位置的 Node 节点 e
+            Node<K,V> e;
+            if ((e = oldTab[j]) != null) {
+                // 置空老的 table 数组第 j 位置
+                oldTab[j] = null;
+                // <2.1> 如果 e 节点只有一个元素，直接赋值给新的 table 即可
+                if (e.next == null)
+                    newTab[e.hash & (newCap - 1)] = e;
+                // <2.2> 如果 e 节点是红黑树节点，则通过红黑树分裂处理
+                else if (e instanceof TreeNode)
+                    ((TreeNode<K,V>)e).split(this, newTab, j, oldCap);
+                // <2.3> 如果 e 节点是链表
+                else { // preserve order
+                    // HashMap 是成倍扩容，这样原来位置的链表的节点们，会被分散到新的 table 的两个位置中去
+                    // 通过 e.hash & oldCap 计算，根据结果分到高位、和低位的位置中。
+                    // 1. 如果结果为 0 时，则放置到低位
+                    // 2. 如果结果非 1 时，则放置到高位
+                    Node<K,V> loHead = null, loTail = null;
+                    Node<K,V> hiHead = null, hiTail = null;
+                    Node<K,V> next;
+                    // 这里 do while 的原因是，e 已经非空，所以减少一次判断。细节~
+                    do {
+                        // next 指向下一个节点
+                        next = e.next;
+                        // 满足低位
+                        if ((e.hash & oldCap) == 0) {
+                            if (loTail == null)
+                                loHead = e;
+                            else
+                                loTail.next = e;
+                            loTail = e;
+                        }
+                        // 满足高位
+                        else {
+                            if (hiTail == null)
+                                hiHead = e;
+                            else
+                                hiTail.next = e;
+                            hiTail = e;
+                        }
+                    } while ((e = next) != null);
+                    // 设置低位到新的 newTab 的 j 位置上
+                    if (loTail != null) {
+                        loTail.next = null;
+                        newTab[j] = loHead;
+                    }
+                    // 设置高位到新的 newTab 的 j + oldCap 位置上
+                    if (hiTail != null) {
+                        hiTail.next = null;
+                        newTab[j + oldCap] = hiHead;
+                    }
+                }
+            }
+        }
+    }
+    return newTab;
+}
+```
+
+- 不要怕，仅仅是代码长了点，逻辑很明确，就两步：1）计算新的容量和扩容阀值，并创建新的 `table` 数组；2）将老的 `table` 复制到新的 `table` 数组中。
+
+下面开始，我们进入【第一步】。
+
+- ```
+  <1.1>
+  ```
+
+   
+
+  处，
+
+  ```
+  oldCap
+  ```
+
+   
+
+  大于 0 ，说明
+
+   
+
+  ```
+  table
+  ```
+
+   
+
+  非空，说明是
+
+  两倍扩容
+
+  的骚操作。
+
+  - `<1.1.1>` 处，超过最大容量，则直接设置 `threshold` 阀值为 `Integer.MAX_VALUE` ，不再允许扩容。
+  - 【重要】`<1.1.2>` 处，**两倍扩容**，这个暗搓搓的 `newCap = oldCap << 1)` 代码段，😈 差点就看漏了。因为容量是两倍扩容，那么再 `newCap * loadFactor` 逻辑，相比直接 `oldThr << 1` 慢，所以直接使用 `oldThr << 1` 位运算的方案。
+
+- ```
+  <1.2.1>
+  ```
+
+   
+
+  和
+
+   
+
+  ```
+  <1.2.2>
+  ```
+
+   
+
+  处，
+
+  ```
+  oldCap
+  ```
+
+   
+
+  等于 0 ，说明
+
+   
+
+  ```
+  table
+  ```
+
+   
+
+  为空，说明是
+
+  初始化
+
+  的骚操作。
+
+  - `<1.2.1>` 处，`oldThr` 大于 0 ，说明使用的是【非默认构造方法】，则使用 `oldThr` 作为新的容量。这里，我们结合 `#tableSizeFor(int cap)` 方法，发现 HashMap 容量一定会是 2 的 N 次方。
+  - `<1.2.2>` 处，`oldThr` 等于 0 ，说明使用的是【默认构造方法】，则使用 `DEFAULT_INITIAL_CAPACITY` 作为新的容量，然后计算新的 `newThr` 阀值。
+
+- `<1.3>` 处，如果上述的逻辑，未计算新的阀值，则使用 `newCap * loadFactor` 作为新的阀值。满足该情况的，有 `<1.2.1>` 和 `<1.1.1>` 的部分情况（胖友自己看下那个判断条件）。
+
+下面开始，我们进入【第二步】。
+
+- 一共分成 `<2.1>`、`<2.2>`、`<2.3>` 的三种情况。😈 相信看懂了 `#put(K key, V value)` 也是分成三种情况，就很容易明白是为什么了。
+
+- `<2.1>` 处，如果 `e` 节点只有一个元素，直接赋值给新的 `table` 即可。这是一个优化操作，无论 Node 节点是链表还是红黑树。
+
+- `<2.2>` 处，如果 `e` 节点是红黑树节点，则通过红黑树分裂处理。
+
+- `<2.3>` 处，如果 `e` 节点是链表，以为 HashMap 是成倍扩容，这样原来位置的链表的节点们，会被分散到新的 `table` 的两个位置中去。可能这里对于不熟悉位操作的胖友有点难理解，我们来一步一步看看：
+
+  > 为了方便举例，`{}` 中的数字，胖友记得是二进制表示哈。
+
+  - 1）我们在选择 `hash & (cap - 1)` 方式，来获得到在 `table` 的位置。那么经过计算，`hash` 在 `cap` 最高位（最左边）的 **1** 自然就被抹去了。例如说，`11 & (4 - 1) = {1011 & 011} = {11} = 3` ，而 `15 & (4 - 1) = {1111 & 011} = {11}= 3` 。相当于 `15` 的 `1[1]11` 的 `[1]` 被**抹去**了。
+  - 2）HashMap 成倍扩容之后，我们在来看看示例。`11 & (7 - 1) = {1011 & 0111} = {11} = 3` ，而 `15 & (8 - 1) = {1111 & 0111} = {111}= 7` 。相当于 `15` 的 `1[1]11` 的 `[1]` 被**保留**了。
+  - 3）那么怎么判断这 `[1]` 是否能够在扩容的时候被保留呢，那就使用 `hash & oldCap` 是否等于 1 即可得到。既然 `[1]` 被保留下来，那么其位置就会 `j + oldCap` ，因为 `[1]` 的**价值**就是 `+ oldCap` 。
+  - 🙂 如果不了解的胖友，可以在纸上画一画整个过程。
+
+在 HashMap 中，暂时未提供**缩容**的操作。不过我们可以结合 `<2.3>` 处的逻辑，缩容可以理解将**高位**的位置的 Node 节点，放回其对应的**低位**的位置的 Node 节点中。😈 想要继续死磕的胖友，可以去研究下 Redis 的 Hash 数据结构在缩容的处理。
+
+# 8. 树化
+
+`#treeifyBin(Node<K,V>[] tab, int hash)` 方法，将 `hash` 对应 `table` 位置的链表，转换成红黑树。代码如下：
+
+```
+// HashMap.java
+
+/**
+ * 每个位置链表树化成红黑树，需要的链表最小长度
+ *
+ * The bin count threshold for using a tree rather than list for a
+ * bin.  Bins are converted to trees when adding an element to a
+ * bin with at least this many nodes. The value must be greater
+ * than 2 and should be at least 8 to mesh with assumptions in
+ * tree removal about conversion back to plain bins upon
+ * shrinkage.
+ */
+static final int TREEIFY_THRESHOLD = 8;
+
+/**
+ * HashMap 允许树化最小 key-value 键值对数
+ *
+ * The smallest table capacity for which bins may be treeified.
+ * (Otherwise the table is resized if too many nodes in a bin.)
+ * Should be at least 4 * TREEIFY_THRESHOLD to avoid conflicts
+ * between resizing and treeification thresholds.
+ */
+static final int MIN_TREEIFY_CAPACITY = 64;
+
+final void treeifyBin(Node<K,V>[] tab, int hash) {
+    int n, index; Node<K,V> e;
+    // <1> 如果 table 容量小于 MIN_TREEIFY_CAPACITY(64) ，则选择扩容
+    if (tab == null || (n = tab.length) < MIN_TREEIFY_CAPACITY)
+        resize();
+    // <2> 将 hash 对应位置进行树化
+    else if ((e = tab[index = (n - 1) & hash]) != null) {
+        // 顺序遍历链表，逐个转换成 TreeNode 节点
+        TreeNode<K,V> hd = null, tl = null;
+        do {
+            TreeNode<K,V> p = replacementTreeNode(e, null);
+            if (tl == null)
+                hd = p;
+            else {
+                p.prev = tl;
+                tl.next = p;
+            }
+            tl = p;
+        } while ((e = e.next) != null);
+        // 树化
+        if ((tab[index] = hd) != null)
+            hd.treeify(tab);
+    }
+}
+```
+
+- 在 [「6. 添加单个元素」](https://svip.iocoder.cn/JDK/Collection-HashMap/#) 中，我们已经看到，每个位置的链表想要树化成红黑树，想要链表长度大于等于 `TREEIFY_THRESHOLD = 8` 。那么可能胖友会疑惑，为什么是 8 呢？我们可以在 HashMap 代码上搜 `Implementation notes.` ，其中部分内容就解释了它。
+
+  ```
+  // HashMap.java
+  
+   * Because TreeNodes are about twice the size of regular nodes, we
+   * use them only when bins contain enough nodes to warrant use
+   * (see TREEIFY_THRESHOLD). And when they become too small (due to
+   * removal or resizing) they are converted back to plain bins.  In
+   * usages with well-distributed user hashCodes, tree bins are
+   * rarely used.  Ideally, under random hashCodes, the frequency of
+   * nodes in bins follows a Poisson distribution
+   * (http://en.wikipedia.org/wiki/Poisson_distribution) with a
+   * parameter of about 0.5 on average for the default resizing
+   * threshold of 0.75, although with a large variance because of
+   * resizing granularity. Ignoring variance, the expected
+   * occurrences of list size k are (exp(-0.5) * pow(0.5, k) /
+   * factorial(k)). The first values are:
+   *
+   * 0:    0.60653066
+   * 1:    0.30326533
+   * 2:    0.07581633
+   * 3:    0.01263606
+   * 4:    0.00157952
+   * 5:    0.00015795
+   * 6:    0.00001316
+   * 7:    0.00000094
+   * 8:    0.00000006
+   * more: less than 1 in ten million
+  ```
+
+  - 首先，参考 [泊松概率函数(Poisson distribution)](http://en.wikipedia.org/wiki/Poisson_distribution) ，当链表长度到达 8 的概率是 0.00000006 ，不到千万分之一。所以绝大多数情况下，在 hash 算法正常的时，不太会出现链表转红黑树的情况。
+  - 其次，TreeNode 相比普通的 Node 来说，会有**两倍**的空间占用。并且在长度比较小的情况下，红黑树的查找性能和链表是差别不大的。例如说，红黑树的 `O(logN) = log8 = 3` 和链表的 `O(N) = 8` 只相差 5 。
+  - 毕竟 HashMap 是 JDK 提供的基础数据结构，必须在空间和时间做抉择。所以，选择链表是空间复杂度优先，选择红黑树是时间复杂度优化。在绝大多数情况下，不会出现需要红黑树的情况。
+
+- `<1>` 处，如果 `table` 容量小于 `MIN_TREEIFY_CAPACITY = 64` 时，则调用 `#resize()` 方法，进行扩容。一般情况下，该链表可以分裂到两个位置上。😈 当然，极端情况下，解决不了，这时候一般是 hash 算法有问题。
+
+- `<2>` 处，如果 `table` 容量大于等于 `MIN_TREEIFY_CAPACITY = 64` 时，则将 `hash` 对应位置进行树化。一共有两步，因为和红黑树相关，这里就不拓展开了。
+
+有树化，必然有取消树化。当 HashMap 因为移除 key 时，导致对应 `table` 位置的红黑树的内部节点数小于等于 `UNTREEIFY_THRESHOLD = 6` 时，则将红黑树退化成链表。具体在 `HashMap.TreeNode#untreeify(HashMap<K,V> map)` 中实现，整列就不拓展开了。代码如下：
+
+```
+// HashMap.java
+
+/**
+ * The bin count threshold for untreeifying a (split) bin during a
+ * resize operation. Should be less than TREEIFY_THRESHOLD, and at
+ * most 6 to mesh with shrinkage detection under removal.
+ */
+static final int UNTREEIFY_THRESHOLD = 6;
+```
+
+- 暂时没有行明白为什么使用 6 作为取消树化的阀值。暂时的想法，避免后续移除 key 时，红黑树如果内部节点数小于 7 就退化成链表，这样可能导致过于频繁的树化和取消树化。
+
+# 9. 添加多个元素
+
+`#putAll(Map<? extends K, ? extends V> m)` 方法，添加多个元素到 HashMap 中。代码如下：
+
+```
+// HashMap.java
+
+public void putAll(Map<? extends K, ? extends V> m) {
+    putMapEntries(m, true);
+}
+```
+
+- 和 `#HashMap(Map<? extends K, ? extends V> m)` 构造方法一样，都调用 `#putMapEntries(Map<? extends K, ? extends V> m, boolean evict)` 方法。
+
+# 10. 移除单个元素
+
+`#remove(Object key)` 方法，移除 key 对应的 value ，并返回该 value 。代码如下：
+
+```
+// HashMap.java
+
+public V remove(Object key) {
+    Node<K,V> e;
+    // hash(key) 求哈希值
+    return (e = removeNode(hash(key), key, null, false, true)) == null ?
+        null : e.value;
+}
+
+final Node<K,V> removeNode(int hash, Object key, Object value,
+                           boolean matchValue, boolean movable) {
+    Node<K,V>[] tab; // table 数组
+    Node<K,V> p; // hash 对应 table 位置的 p 节点
+    int n, index;
+    // <1> 查找 hash 对应 table 位置的 p 节点
+    if ((tab = table) != null && (n = tab.length) > 0 &&
+        (p = tab[index = (n - 1) & hash]) != null) {
+        Node<K,V> node = null, // 如果找到 key 对应的节点，则赋值给 node
+                e;
+        K k; V v;
+        // <1.1> 如果找到的 p 节点，就是要找的，则则直接使用即可
+        if (p.hash == hash &&
+            ((k = p.key) == key || (key != null && key.equals(k))))
+            node = p;
+        else if ((e = p.next) != null) {
+            // <1.2> 如果找到的 p 节点，是红黑树 Node 节点，则直接在红黑树中查找
+            if (p instanceof TreeNode)
+                node = ((TreeNode<K,V>)p).getTreeNode(hash, key);
+            // <1.3> 如果找到的 p 是 Node 节点，则说明是链表，需要遍历查找
+            else {
+                do {
+                    // 如果遍历的 e 节点，就是要找的，则则直接使用即可
+                    if (e.hash == hash &&
+                        ((k = e.key) == key ||
+                         (key != null && key.equals(k)))) {
+                        node = e;
+                        break; // 结束
+                    }
+                    p = e; // 注意，这里 p 会保存找到节点的前一个节点
+                } while ((e = e.next) != null);
+            }
+        }
+        // <2> 如果找到 node 节点，则进行移除
+        // 如果有要求匹配 value 的条件，这里会进行一次判断先移除
+        if (node != null && (!matchValue || (v = node.value) == value ||
+                             (value != null && value.equals(v)))) {
+            // <2.1> 如果找到的 node 节点，是红黑树 Node 节点，则直接在红黑树中删除
+            if (node instanceof TreeNode)
+                ((TreeNode<K,V>)node).removeTreeNode(this, tab, movable);
+            // <2.2.1> 如果查找到的是链表的头节点，则直接将 table 对应位置指向 node 的下一个节点，实现删除
+            else if (node == p)
+                tab[index] = node.next;
+            // <2.2.2> 如果查找到的是链表的中间节点，则将 p 指向 node 的下一个节点，实现删除
+            else
+                p.next = node.next;
+            // 增加修改次数
+            ++modCount;
+            // 减少 HashMap 数量
+            --size;
+            // 移除 Node 后的回调
+            afterNodeRemoval(node);
+            // 返回 node
+            return node;
+        }
+    }
+    // 查找不到，则返回 null
+    return null;
+}
+```
+
+- 在 HashMap 中，移除 和添加 key-value 键值对，整个流程是比较接近的。一共分成两步：
+  - `<1>` 处，查找到 key 对应的 Node 节点。
+  - `<2>` 处，将查找到的 Node 节点进行移除。
+- 整体逻辑比较简单，这里就不哔哔，胖友可以顺着：
+  - 第一步，`<1.1>`、`<1.2>`、`<1.3>` 三种情况。
+  - 第二步，`<2.1>`、`<2.2.1> + <2.2.2>` 两种情况。
+
+`#remove(Object key, Object value)` 方法，移除指定 key-value 的键值对。代码如下：
+
+```
+// HashMap.java
+
+@Override
+public boolean remove(Object key, Object value) {
+    return removeNode(hash(key), key, value, true, true) != null;
+}
+```
+
+- 也是基于 `#removeNode(int hash, Object key, Object value, boolean matchValue, boolean movable)` 方法来实现的，差别在于传入了 `value` 和 `matchValue = true` 参数。
+
+HashMap 暂时不提供批量移除多个元素的方法。
+
+# 11. 查找单个元素
+
+`#get(Object key)` 方法，查找单个元素。代码如下：
+
+```
+// HashMap.java
+
+public V get(Object key) {
+    Node<K,V> e;
+    // hash(key) 哈希值
+    return (e = getNode(hash(key), key)) == null ? null : e.value;
+}
+
+final Node<K,V> getNode(int hash, Object key) {
+    Node<K,V>[] tab; Node<K,V> first, e; int n; K k;
+    // 查找 hash 对应 table 位置的 p 节点
+    if ((tab = table) != null && (n = tab.length) > 0 &&
+        (first = tab[(n - 1) & hash]) != null) {
+        // 如果找到的 first 节点，就是要找的，则则直接使用即可
+        if (first.hash == hash && // always check first node
+            ((k = first.key) == key || (key != null && key.equals(k))))
+            return first;
+        if ((e = first.next) != null) {
+            // 如果找到的 first 节点，是红黑树 Node 节点，则直接在红黑树中查找
+            if (first instanceof TreeNode)
+                return ((TreeNode<K,V>)first).getTreeNode(hash, key);
+            // 如果找到的 e 是 Node 节点，则说明是链表，需要遍历查找
+            do {
+                if (e.hash == hash &&
+                    ((k = e.key) == key || (key != null && key.equals(k))))
+                    return e;
+            } while ((e = e.next) != null);
+        }
+    }
+    return null;
+}
+```
+
+- 比较简单，`#removeNode(int hash, Object key, Object value, boolean matchValue, boolean movable)` 的 SE 版。
+
+  > 艿艿：这里 SE 指的是阉割版。咳咳咳。
+
+`#containsKey(Object key)` 方法，就是基于该方法实现。代码如下：
+
+```
+// HashMap.java
+
+public boolean containsKey(Object key) {
+    return getNode(hash(key), key) != null;
+}
+```
+
+`#containsValue(Object value)` 方法，查找指定 value 是否存在。代码如下：
+
+```
+// HashMap.java
+
+public boolean containsValue(Object value) {
+    Node<K,V>[] tab; V v;
+    if ((tab = table) != null && size > 0) {
+        // 遍历 table 数组
+        for (Node<K,V> e : tab) {
+            // 处理链表或者红黑树节点
+            for (; e != null; e = e.next) {
+                // 如果值相等，则返回 true
+                if ((v = e.value) == value ||
+                    (value != null && value.equals(v)))
+                    return true;
+            }
+        }
+    }
+    // 找不到，返回 false
+    return false;
+}
+```
+
+> 艿艿：看到这里，基本 HashMap 的源码解析已经结束，对后面方法不感兴趣的胖友，可以直接跳到 [666. 彩蛋](https://svip.iocoder.cn/JDK/Collection-HashMap/#) 中。
+
+`#getOrDefault(Object key, V defaultValue)` 方法，获得 key 对应的 value 。如果不存在，则返回 `defaultValue` 默认值。代码如下：
+
+```
+// HashMap.java
+
+@Override
+public V getOrDefault(Object key, V defaultValue) {
+    Node<K,V> e;
+    return (e = getNode(hash(key), key)) == null ? defaultValue : e.value;
+}
+```
+
+# 12. 转换成数组
+
+`#keysToArray(T[] a)` 方法，转换出 key 数组返回。代码如下：
+
+```
+// HashMap.java
+
+<T> T[] keysToArray(T[] a) {
+    Object[] r = a;
+    Node<K,V>[] tab;
+    int idx = 0;
+    if (size > 0 && (tab = table) != null) {
+        // 遍历 table 数组
+        for (Node<K,V> e : tab) {
+            // 遍历链表或红黑树
+            for (; e != null; e = e.next) {
+                // 逐个设置 key 到 r 数组中
+                r[idx++] = e.key;
+            }
+        }
+    }
+    // 返回
+    return a;
+}
+```
+
+- 细心的胖友，可能已经意识到了，如果 `a` 数组的大小不够放下 HashMap 的所有 key 怎么办？答案是可以通过 `#prepareArray(T[] a)` 方法来保证。代码如下：
+
+  ```
+  // HashMap.java
+  
+  final <T> T[] prepareArray(T[] a) {
+      int size = this.size;
+      // 如果 a 数组小于 HashMap 大小，则创建一个新的数组返回
+      if (a.length < size) {
+          return (T[]) java.lang.reflect.Array
+                  .newInstance(a.getClass().getComponentType(), size);
+      }
+      // 如果 a 数组大于 HashMap 大小，则将 size 位置设置为 null
+      if (a.length > size) {
+          a[size] = null;
+      }
+      return a;
+  }
+  ```
+
+  - 当 `a` 数组过小时，会创建一个新的数组返回。
+  - 当然，一般情况下，我们肯定是不会使用到该方法。😈 至今貌似也没有使用过。
+
+`#valuesToArray(T[] a)` 方法，转换出 value 数组返回。代码如下：
+
+```
+// HashMap.java
+
+<T> T[] valuesToArray(T[] a) {
+    Object[] r = a;
+    Node<K,V>[] tab;
+    int idx = 0;
+    if (size > 0 && (tab = table) != null) {
+        // 遍历 table 数组
+        for (Node<K,V> e : tab) {
+            // 遍历链表或红黑树
+            for (; e != null; e = e.next) {
+                // 逐个设置 value 到 r 数组中
+                r[idx++] = e.value;
+            }
+        }
+    }
+    // 返回
+    return a;
+}
+```
+
+# 13. 转换成 Set/Collection
+
+`#keySet()` 方法，获得 key Set 。代码如下：
+
+```
+// AbstractMap.java
+transient Set<K>        keySet;
+
+// HashMap.java
+public Set<K> keySet() {
+    // 获得 keySet 缓存
+    Set<K> ks = keySet;
+    // 如果不存在，则进行创建
+    if (ks == null) {
+        ks = new KeySet();
+        keySet = ks;
+    }
+    return ks;
+}
+```
+
+- 创建的 KeySet 类，实现了 [`java.util.AbstractSet`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/util/AbstractSet.java) 抽像类，是 HashMap 的内部类。比较简单，就不哔哔了。
+
+`#values()` 方法，获得 value 集合。代码如下：
+
+```
+// AbstractMap.java
+transient Collection<V> values;
+
+// HashMap.java
+public Collection<V> values() {
+    // 获得 vs 缓存
+    Collection<V> vs = values;
+    // 如果不存在，则进行创建
+    if (vs == null) {
+        vs = new Values();
+        values = vs;
+    }
+    return vs;
+}
+```
+
+- 创建的 Values 类，实现了 [`java.util.AbstractCollection`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/util/AbstractCollection.java) 抽像类，是 HashMap 的内部类。比较简单，就不哔哔了。
+
+`#entrySet()` 方法，获得 key-value Set 。代码如下：
+
+```
+// HashMap.java
+
+transient Set<Map.Entry<K,V>> entrySet;
+
+public Set<Map.Entry<K,V>> entrySet() {
+    Set<Map.Entry<K,V>> es;
+    // 获得 entrySet 缓存
+    // 如果不存在，则进行创建
+    return (es = entrySet) == null ? (entrySet = new EntrySet()) : es;
+}
+```
+
+- 创建的 EntrySet 类，实现了 [`java.util.AbstractSet`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/util/AbstractSet.java) 抽像类，是 HashMap 的内部类。比较简单，就不哔哔了。
+
+> 艿艿：感觉会被胖友锤死。嘿嘿。
+
+# 14. 清空
+
+`#clear()` 方法，清空 HashMap 。代码如下：
+
+```
+// HashMap.java
+
+public void clear() {
+    Node<K,V>[] tab;
+    // 增加修改次数
+    modCount++;
+    if ((tab = table) != null && size > 0) {
+        // 设置大小为 0
+        size = 0;
+        // 设置每个位置为 null
+        for (int i = 0; i < tab.length; ++i)
+            tab[i] = null;
+    }
+}
+```
+
+# 15. 序列化
+
+`#writeObject(ObjectOutputStream s)` 方法，序列化 HashMap 对象。代码如下：
+
+```
+// HashMap.java
+
+@java.io.Serial
+private void writeObject(java.io.ObjectOutputStream s)
+    throws IOException {
+    // 获得 HashMap table 数组大小
+    int buckets = capacity();
+    // Write out the threshold, loadfactor, and any hidden stuff
+    // 写入非静态属性、非 transient 属性
+    s.defaultWriteObject();
+    // 写入 table 数组大小
+    s.writeInt(buckets);
+    // 写入 key-value 键值对数量
+    s.writeInt(size);
+    // 写入具体的 key-value 键值对
+    internalWriteEntries(s);
+}
+
+final int capacity() { // table 数组大小。封装方法的原因，需要考虑 table 未初始化的情况。
+    return (table != null) ? table.length :
+        (threshold > 0) ? threshold :
+        DEFAULT_INITIAL_CAPACITY;
+}
+
+// Called only from writeObject, to ensure compatible ordering.
+void internalWriteEntries(java.io.ObjectOutputStream s) throws IOException {
+    Node<K,V>[] tab;
+    if (size > 0 && (tab = table) != null) {
+        // 遍历 table 数组
+        for (Node<K,V> e : tab) {
+            // 遍历链表或红黑树
+            for (; e != null; e = e.next) {
+                // 写入 key
+                s.writeObject(e.key);
+                // 写入 value
+                s.writeObject(e.value);
+            }
+        }
+    }
+}
+```
+
+- 比较简单，胖友自己瞅瞅即可。
+
+# 16. 反序列化
+
+`#readObject(ObjectInputStream s)` 方法，反序列化成 HashMap 对象。代码如下：
+
+```
+// HashMap.java
+
+@java.io.Serial
+private void readObject(java.io.ObjectInputStream s)
+    throws IOException, ClassNotFoundException {
+    // Read in the threshold (ignored), loadfactor, and any hidden stuff
+    // 读取非静态属性、非 transient 属性
+    s.defaultReadObject();
+    // 重新初始化
+    reinitialize();
+    // 校验 loadFactor 参数
+    if (loadFactor <= 0 || Float.isNaN(loadFactor))
+        throw new InvalidObjectException("Illegal load factor: " +
+                                         loadFactor);
+    // 读取 HashMap table 数组大小
+    s.readInt();                // Read and ignore number of buckets
+    // 读取 key-value 键值对数量 size
+    int mappings = s.readInt(); // Read number of mappings (size)
+    // 校验 size 参数
+    if (mappings < 0)
+        throw new InvalidObjectException("Illegal mappings count: " +
+                                         mappings);
+    else if (mappings > 0) { // (if zero, use defaults)
+        // Size the table using given load factor only if within
+        // range of 0.25...4.0
+        float lf = Math.min(Math.max(0.25f, loadFactor), 4.0f);
+        float fc = (float)mappings / lf + 1.0f;
+        // 计算容量
+        int cap = ((fc < DEFAULT_INITIAL_CAPACITY) ?
+                   DEFAULT_INITIAL_CAPACITY :
+                   (fc >= MAXIMUM_CAPACITY) ?
+                   MAXIMUM_CAPACITY :
+                   tableSizeFor((int)fc));
+        // 计算 threshold 阀值
+        float ft = (float)cap * lf;
+        threshold = ((cap < MAXIMUM_CAPACITY && ft < MAXIMUM_CAPACITY) ?
+                     (int)ft : Integer.MAX_VALUE);
+
+        // Check Map.Entry[].class since it's the nearest public type to
+        // what we're actually creating.
+        SharedSecrets.getJavaObjectInputStreamAccess().checkArray(s, Map.Entry[].class, cap); // 不知道作甚，哈哈哈。
+        // 创建 table 数组
+        @SuppressWarnings({"rawtypes","unchecked"})
+        Node<K,V>[] tab = (Node<K,V>[])new Node[cap];
+        table = tab;
+
+        // Read the keys and values, and put the mappings in the HashMap
+        // 遍历读取 key-value 键值对
+        for (int i = 0; i < mappings; i++) {
+            // 读取 key
+            @SuppressWarnings("unchecked")
+            K key = (K) s.readObject();
+            // 读取 value
+            @SuppressWarnings("unchecked")
+            V value = (V) s.readObject();
+            // 添加 key-value 键值对
+            putVal(hash(key), key, value, false, false);
+        }
+    }
+}
+
+/**
+ * Reset to initial default state.  Called by clone and readObject.
+ */
+void reinitialize() {
+    table = null;
+    entrySet = null;
+    keySet = null;
+    values = null;
+    modCount = 0;
+    threshold = 0;
+    size = 0;
+}
+```
+
+- 相比序列化的过程，复杂了一丢丢。跟着顺序往下看即可，嘿嘿。
+
+# 17. 克隆
+
+`#clone()` 方法，克隆 HashMap 对象。代码如下：
+
+```
+// HashMap.java
+
+@Override
+public Object clone() {
+    // 克隆 HashMap 对象
+    HashMap<K,V> result;
+    try {
+        result = (HashMap<K,V>)super.clone();
+    } catch (CloneNotSupportedException e) {
+        // this shouldn't happen, since we are Cloneable
+        throw new InternalError(e);
+    }
+    // 重新初始化
+    result.reinitialize();
+    // 批量添加 key-value 键值对到其中
+    result.putMapEntries(this, false);
+    // 返回 result
+    return result;
+}
+```
+
+- 对于 key-value 键值对是浅拷贝，这点要注意哈。
+
+# 666. 彩蛋
+
+咳咳咳，在理解 HashMap 的实现原理之后，再去看 HashMap 的实现代码，其实会比想象中简单非常多。艿艿自己的卡壳点，主要还是 hash 函数的一些细节，😈 不知道胖友在哪些地方卡壳了？
+
+看完之后，有没觉得，面试的时候很稳，这里我们就不要吊打面试官了，毕竟万一让我们手写红黑树，我们不就可能 GG 了。
+
+关于在 JDK8 新增的几个方法，艿艿暂时没有去写，主要如下：
+
+- `#replace(K key, V oldValue, V newValue)`
+- `#replace(K key, V value)`
+- `#computeIfAbsent(K key, Function<? super K, ? extends V> mappingFunction)`
+- `#computeIfPresent(K key, BiFunction<? super K, ? super V, ? extends V> remappingFunction)`
+- `#compute(K key, BiFunction<? super K, ? super V, ? extends V> remappingFunction)`
+- `#merge(K key, V value, BiFunction<? super V, ? super V, ? extends V> remappingFunction)`
+- `#forEach(BiConsumer<? super K, ? super V> action)`
+- `#replaceAll(BiFunction<? super K, ? super V, ? extends V> function)`
+
+哈哈，也是比较简单的方法，胖友自己可以解决一波的哈。就当，课后作业？！嘿嘿。
+
+下面，我们来对 HashMap 做一个简单的小结：
+
+- HashMap 是一种散列表的数据结构，底层采用数组 + 链表 + 红黑树来实现存储。
+
+  > Redis Hash 数据结构，采用数组 + 链表实现。
+  >
+  > Redis Zset 数据结构，采用跳表实现。
+  >
+  > 因为红黑树实现起来相对复杂，我们自己在实现 HashMap 可以考虑采用数组 + 链表 + 跳表来实现存储。
+
+- HashMap 默认容量为 16(`1 << 4`)，每次超过阀值时，按照两倍大小进行自动扩容，所以容量总是 2^N 次方。并且，底层的 `table` 数组是延迟初始化，在首次添加 key-value 键值对才进行初始化。
+
+- HashMap 默认加载因子是 0.75 ，如果我们已知 HashMap 的大小，需要正确设置容量和加载因子。
+
+- HashMap 每个槽位在满足如下两个条件时，可以进行树化成红黑树，避免槽位是链表数据结构时，链表过长，导致查找性能过慢。
+
+  - 条件一，HashMap 的 `table` 数组大于等于 64 。
+  - 条件二，槽位链表长度大于等于 8 时。选择 8 作为阀值的原因是，参考 [泊松概率函数(Poisson distribution)](http://en.wikipedia.org/wiki/Poisson_distribution) ，概率不足千万分之一。
+  - 在槽位的红黑树的节点数量小于等于 6 时，会退化回链表。
+
+- HashMap 的查找和添加 key-value 键值对的
+
+  平均
+
+  时间复杂度为 O(1) 。
+
+  - 对于槽位是链表的节点，**平均**时间复杂度为 O(k) 。其中 k 为链表长度。
+  - 对于槽位是红黑树的节点，**平均**时间复杂度为 O(logk) 。其中 k 为红黑树节点数量。
+
+OK ，还是在结尾抛个拓展，对于 Redis 的 Hash 和 ZSet 数据结构，胖友去研究下。
+
+在故事的结尾，在推荐一篇美团技术团队的 [《Java 8 系列之重新认识HashMap》](https://zhuanlan.zhihu.com/p/21673805) 文章，写的更加生动细致。
\ No newline at end of file
diff --git a/jdk/06-JDK 源码解析-集合（四）哈希表 LinkedHashMap.assets/01.png b/jdk/06-JDK 源码解析-集合（四）哈希表 LinkedHashMap.assets/01.png
new file mode 100644
index 0000000..445955c
Binary files /dev/null and b/jdk/06-JDK 源码解析-集合（四）哈希表 LinkedHashMap.assets/01.png differ
diff --git a/jdk/06-JDK 源码解析-集合（四）哈希表 LinkedHashMap.assets/04.jpg b/jdk/06-JDK 源码解析-集合（四）哈希表 LinkedHashMap.assets/04.jpg
new file mode 100644
index 0000000..69cdd0c
Binary files /dev/null and b/jdk/06-JDK 源码解析-集合（四）哈希表 LinkedHashMap.assets/04.jpg differ
diff --git a/jdk/06-JDK 源码解析-集合（四）哈希表 LinkedHashMap.md b/jdk/06-JDK 源码解析-集合（四）哈希表 LinkedHashMap.md
new file mode 100644
index 0000000..08beae1
--- /dev/null
+++ b/jdk/06-JDK 源码解析-集合（四）哈希表 LinkedHashMap.md	
@@ -0,0 +1,740 @@
+# 精尽 JDK 源码解析 —— 集合（四）哈希表 LinkedHashMap
+
+# 1. 概述
+
+众所周知，HashMap 提供的访问，是**无序**的。而在一些业务场景下，我们希望能够提供**有序**访问的 HashMap 。那么此时，我们就有两种选择：
+
+- TreeMap ：按照 key 的顺序。
+- LinkedHashMap ：按照 key 的插入和访问的顺序。
+
+LinkedHashMap ，在 HashMap 的基础之上，提供了**顺序**访问的特性。而这里的顺序，包括两种：
+
+- 按照 key-value 的**插入**顺序进行访问。关于这一点，相信大多数人都知道。
+
+  > 艿艿：如果不知道，那就赶紧知道。这不找抽么，哈哈哈。
+
+- 按照 key-value 的**访问**顺序进行访问。通过这个特性，我们实现基于 LRU 算法的缓存。😈 相信这一点，可能还是有部分胖友不知道的噢，下文我们也会提供一个示例。
+
+  > 艿艿：面试中，有些面试官会喜欢问你，如何实现一个 LRU 的缓存。
+
+实际上，LinkedHashMap 可以理解成是 LinkedList + HashMap 的组合。为什么这么说呢？让我们带着这样的疑问，一起往下看。
+
+# 2. 类图
+
+LinkedHashMap 实现的接口、继承的类，如下图所示：[![类图](06-JDK 源码解析-集合（四）哈希表 LinkedHashMap.assets/01.png)](http://static.iocoder.cn/images/JDK/2019_12_10/01.png)类图
+
+- 实现 Map 接口。
+- 继承 HashMap 类。
+
+😈 很简单，很粗暴。嘿嘿~
+
+> 艿艿：因为 LinkedHashMap 继承自 HashMap 类，所以它的代码并不多，不到 500 行。
+
+# 3. 属性
+
+在开始看 LinkedHashMap 的属性之前，我们先来看在 [《精尽 JDK 源码解析 —— 集合（三）哈希表 HashMap》](http://svip.iocoder.cn/JDK/Collection-HashMap/) 看到的 HashMap 的 Node 子类图：[![Node 类图](06-JDK 源码解析-集合（四）哈希表 LinkedHashMap.assets/04.jpg)](http://static.iocoder.cn/images/JDK/2019_12_07/04.jpg)Node 类图
+
+在图中，我们可以看到 LinkedHashMap 实现了自定义的节点 Entry ，一个支持指向前后节点的 Node 子类。代码如下：
+
+```
+// LinkedHashMap.java
+
+static class Entry<K,V> extends HashMap.Node<K,V> {
+
+    Entry<K,V> before, // 前一个节点
+            after; // 后一个节点
+
+    Entry(int hash, K key, V value, Node<K,V> next) {
+        super(hash, key, value, next);
+    }
+
+}
+```
+
+- `before` 属性，指向前一个节点。`after` 属性，指向后一个节点。
+- 通过 `before` + `after` 属性，我们就可以形成一个以 Entry 为节点的链表。😈 胖友，发挥下你的想象力。
+
+既然 LinkedHashMap 是 LinkedList + HashMap 的组合，那么必然就会有头尾节点两兄弟。所以属性如下：
+
+```
+// LinkedHashMap.java
+
+/**
+ * 头节点。
+ *
+ * 越老的节点，放在越前面。所以头节点，指向链表的开头
+ *
+ * The head (eldest) of the doubly linked list.
+ */
+transient LinkedHashMap.Entry<K,V> head;
+
+/**
+ * 尾节点
+ *
+ * 越新的节点，放在越后面。所以尾节点，指向链表的结尾
+ *
+ * The tail (youngest) of the doubly linked list.
+ */
+transient LinkedHashMap.Entry<K,V> tail;
+
+/**
+ * 是否按照访问的顺序。
+ *
+ * true ：按照 key-value 的访问顺序进行访问。
+ * false ：按照 key-value 的插入顺序进行访问。
+ *
+ * The iteration ordering method for this linked hash map: {@code true}
+ * for access-order, {@code false} for insertion-order.
+ *
+ * @serial
+ */
+final boolean accessOrder;
+```
+
+- 仔细看下每个属性的注释。
+
+- `head` + `tail` 属性，形成 LinkedHashMap 的双向链表。而访问的顺序，就是 `head => tail` 的过程。
+
+- ```
+  accessOrder
+  ```
+
+   
+
+  属性，决定了 LinkedHashMap 的顺序。也就是说:
+
+  - `true` 时，当 Entry 节点被访问时，放置到链表的结尾，被 `tail` 指向。
+  - `false` 时，当 Entry 节点被添加时，放置到链表的结尾，被 `tail` 指向。如果插入的 key 对应的 Entry 节点已经存在，也会被放到结尾。
+
+总结来说，就是如下一张图：
+
+> FROM [《Working of LinkedHashMap》](http://www.thejavageek.com/2016/06/05/working-linkedhashmap-java/)
+>
+> [![LinkedHashMap 结构图](http://www.thejavageek.com/wp-content/uploads/2016/06/SecondObjectInserted.png)](http://www.thejavageek.com/wp-content/uploads/2016/06/SecondObjectInserted.png)LinkedHashMap 结构图
+
+# 4. 构造方法
+
+LinkedHashMap 一共有 5 个构造方法，其中四个和 HashMap 相同，只是多初始化 `accessOrder = false` 。所以，默认使用**插入**顺序进行访问。
+
+另外一个 `#LinkedHashMap(int initialCapacity, float loadFactor, boolean accessOrder)` 构造方法，允许自定义 `accessOrder` 属性。代码如下：
+
+```
+// LinkedHashMap.java
+
+public LinkedHashMap(int initialCapacity,
+                     float loadFactor,
+                     boolean accessOrder) {
+    super(initialCapacity, loadFactor);
+    this.accessOrder = accessOrder;
+}
+```
+
+# 5. 创建节点
+
+在插入 key-value 键值对时，例如说 `#put(K key, V value)` 方法，如果不存在对应的节点，则会调用 `#newNode(int hash, K key, V value, Node<K,V> e)` 方法，创建节点。
+
+因为 LinkedHashMap 自定义了 Entry 节点，所以必然需要重写该方法。代码如下：
+
+```
+// LinkedHashMap.java
+
+Node<K,V> newNode(int hash, K key, V value, Node<K,V> e) {
+    // <1> 创建 Entry 节点
+    LinkedHashMap.Entry<K,V> p =
+        new LinkedHashMap.Entry<>(hash, key, value, e);
+    // <2> 添加到结尾
+    linkNodeLast(p);
+    // 返回
+    return p;
+}
+```
+
+- `<1>` 处，创建 Entry 节点。虽然此处传入 `e` 作为 `Entry.next` 属性，指向下一个节点。但是实际上，`#put(K key, V value)` 方法中，传入的 `e = null` 。
+
+- `<2>` 处，调用 `#linkNodeLast(LinkedHashMap.Entry<K,V> p)` 方法，添加到结尾。代码如下：
+
+  ```
+  // LinkedHashMap.java
+  
+  private void linkNodeLast(LinkedHashMap.Entry<K,V> p) {
+      // 记录原尾节点到 last 中
+      LinkedHashMap.Entry<K,V> last = tail;
+      // 设置 tail 指向 p ，变更新的尾节点
+      tail = p;
+      // 如果原尾节点 last 为空，说明 head 也为空，所以 head 也指向 p
+      if (last == null)
+          head = p;
+      // last <=> p ，相互指向
+      else {
+          p.before = last;
+          last.after = p;
+      }
+  }
+  ```
+
+  - 这样，符合越新的节点，放到链表的越后面。
+
+# 6. 节点操作回调
+
+在 HashMap 的读取、添加、删除时，分别提供了 `#afterNodeAccess(Node<K,V> e)`、`#afterNodeInsertion(boolean evict)`、`#afterNodeRemoval(Node<K,V> e)` 回调方法。这样，LinkedHashMap 可以通过它们实现自定义拓展逻辑。
+
+## 6.1 afterNodeAccess
+
+在 `accessOrder` 属性为 `true` 时，当 Entry 节点被访问时，放置到链表的结尾，被 `tail` 指向。所以 `#afterNodeAccess(Node<K,V> e)` 方法的代码如下：
+
+```
+// LinkedHashMap.java
+
+void afterNodeAccess(Node<K,V> e) { // move node to last
+    LinkedHashMap.Entry<K,V> last;
+    // accessOrder 判断必须是满足按访问顺序。
+    // (last = tail) != e 将 tail 赋值给 last ，并且判断是否 e 已经是队尾。如果是队尾，就不用处理了。
+    if (accessOrder && (last = tail) != e) {
+        // 将 e 赋值给 p 【因为要 Node 类型转换成 Entry 类型】
+        // 同时 b、a 分别是 e 的前后节点
+        LinkedHashMap.Entry<K,V> p =
+            (LinkedHashMap.Entry<K,V>)e, b = p.before, a = p.after;
+        // 第一步，将 p 从链表中移除
+        p.after = null;
+        // 处理 b 的下一个节点指向 a
+        if (b == null)
+            head = a;
+        else
+            b.after = a;
+        // 处理 a 的前一个节点指向 b
+        if (a != null)
+            a.before = b;
+        else
+            last = b;
+        // 第二步，将 p 添加到链表的尾巴。实际这里的代码，和 linkNodeLast 是一致的。
+        if (last == null)
+            head = p;
+        else {
+            p.before = last;
+            last.after = p;
+        }
+        // tail 指向 p ，实际就是 e 。
+        tail = p;
+        // 增加修改次数
+        ++modCount;
+    }
+}
+```
+
+- 代码已经添加详细的注释，胖友认真看看噢。
+- 链表的操作看起来比较繁琐，实际一共分成两步：1）第一步，将 `p` 从链表中移除；2）将 `p` 添加到链表的尾巴。
+
+因为 HashMap 提供的 `#get(Object key)` 和 `#getOrDefault(Object key, V defaultValue)` 方法，并未调用 `#afterNodeAccess(Node<K,V> e)` 方法，这在按照**读取**顺序访问显然不行，所以 LinkedHashMap 重写这两方法的代码，如下：
+
+```
+// LinkedHashMap.java
+
+public V get(Object key) {
+    // 获得 key 对应的 Node
+    Node<K,V> e;
+    if ((e = getNode(hash(key), key)) == null)
+        return null;
+    // 如果访问到，回调节点被访问
+    if (accessOrder)
+        afterNodeAccess(e);
+    return e.value;
+}
+
+public V getOrDefault(Object key, V defaultValue) {
+    // 获得 key 对应的 Node
+    Node<K,V> e;
+   if ((e = getNode(hash(key), key)) == null)
+       return defaultValue;
+    // 如果访问到，回调节点被访问
+    if (accessOrder)
+       afterNodeAccess(e);
+   return e.value;
+}
+```
+
+## 6.2 afterNodeInsertion
+
+在开始看 `#afterNodeInsertion(boolean evict)` 方法之前，我们先来看看如何基于 LinkedHashMap 实现 LRU 算法的缓存。代码如下：
+
+```
+class LRUCache<K, V> extends LinkedHashMap<K, V> {
+
+    private final int CACHE_SIZE;
+
+    /**
+     * 传递进来最多能缓存多少数据
+     *
+     * @param cacheSize 缓存大小
+     */
+    public LRUCache(int cacheSize) {
+        // true 表示让 LinkedHashMap 按照访问顺序来进行排序，最近访问的放在头部，最老访问的放在尾部。
+        super((int) Math.ceil(cacheSize / 0.75) + 1, 0.75f, true);
+        CACHE_SIZE = cacheSize;
+    }
+
+    @Override
+    protected boolean removeEldestEntry(Map.Entry<K, V> eldest) {
+        // 当 map 中的数据量大于指定的缓存个数的时候，就自动删除最老的数据。
+        return size() > CACHE_SIZE;
+    }
+
+}
+```
+
+为什么能够这么实现呢？我们在 `#afterNodeInsertion(boolean evict)` 方法中来理解。代码如下：
+
+```
+// LinkedHashMap.java
+
+// evict 翻译为驱逐，表示是否允许移除元素
+void afterNodeInsertion(boolean evict) { // possibly remove eldest
+    LinkedHashMap.Entry<K,V> first;
+    // first = head 记录当前头节点。因为移除从头开始，最老
+    // <1> removeEldestEntry(first) 判断是否满足移除最老节点
+    if (evict && (first = head) != null && removeEldestEntry(first)) {
+        // <2> 移除指定节点
+        K key = first.key;
+        removeNode(hash(key), key, null, false, true);
+    }
+}
+```
+
+- `<1>` 处，调用 `#removeEldestEntry(Map.Entry<K,V> eldest)` 方法，判断是否移除最老节点。代码如下：
+
+  ```
+  // LinkedHashMap.java
+  
+  protected boolean removeEldestEntry(Map.Entry<K,V> eldest) {
+      return false;
+  }
+  ```
+
+  - 默认情况下，**都不**移除最老的节点。所以在上述的 LRU 缓存的示例，重写了该方法，判断 LinkedHashMap 是否超过缓存最大大小。如果是，则移除最老的节点。
+
+- `<2>` 处，如果满足条件，则调用 `#removeNode(...)` 方法，移除最老的节点。
+
+😈 这样，是不是很容易理解基于 LinkedHashMap 实现 LRU 算法的缓存。
+
+## 6.3 afterNodeRemoval
+
+在节点被移除时，LinkedHashMap 需要将节点也从链表中移除，所以重写 `#afterNodeRemoval(Node<K,V> e)` 方法，实现该逻辑。代码如下：
+
+```
+// LinkedHashMap.java
+
+void afterNodeRemoval(Node<K,V> e) { // unlink
+    // 将 e 赋值给 p 【因为要 Node 类型转换成 Entry 类型】
+    // 同时 b、a 分别是 e 的前后节点
+    LinkedHashMap.Entry<K,V> p =
+        (LinkedHashMap.Entry<K,V>)e, b = p.before, a = p.after;
+    // 将 p 从链表中移除
+    p.before = p.after = null;
+    // 处理 b 的下一个节点指向 a
+    if (b == null)
+        head = a;
+    else
+        b.after = a;
+    // 处理 a 的前一个节点指向 b
+    if (a == null)
+        tail = b;
+    else
+        a.before = b;
+}
+```
+
+# 7. 转换成数组
+
+因为 LinkedHashMap 需要满足按**顺序**访问，所以需要重写 HashMap 提供的好多方法，例如说本小节我们看到的几个。
+
+`#keysToArray(T[] a)` 方法，转换出 key 数组**顺序**返回。代码如下：
+
+```
+// LinkedHashMap.java
+
+@Override
+final <T> T[] keysToArray(T[] a) {
+    Object[] r = a;
+    int idx = 0;
+    // 通过 head 顺序遍历，从头到尾
+    for (LinkedHashMap.Entry<K,V> e = head; e != null; e = e.after) {
+        r[idx++] = e.key;
+    }
+    return a;
+}
+```
+
+- 要小心噢，必须保证 `a` 放得下 LinkedHashMap 所有的元素。
+
+`#valuesToArray(T[] a)` 方法，转换出 value 数组**顺序**返回。代码如下：
+
+```
+// LinkedHashMap.java
+
+@Override
+final <T> T[] valuesToArray(T[] a) {
+    Object[] r = a;
+    int idx = 0;
+    // 通过 head 顺序遍历，从头到尾
+    for (LinkedHashMap.Entry<K,V> e = head; e != null; e = e.after) {
+        r[idx++] = e.value;
+    }
+    return a;
+}
+```
+
+> 艿艿：看到此处，胖友基本可以结束本文落。
+
+# 8. 转换成 Set/Collection
+
+`#keySet()` 方法，获得 key Set 。代码如下：
+
+```
+// LinkedHashMap.java
+
+public Set<K> keySet() {
+    // 获得 keySet 缓存
+    Set<K> ks = keySet;
+    // 如果不存在，则进行创建
+    if (ks == null) {
+        ks = new LinkedKeySet(); // LinkedKeySet 是 LinkedHashMap 自定义的
+        keySet = ks;
+    }
+    return ks;
+}
+```
+
+- 其中， LinkedKeySet 是 LinkedHashMap 自定义的 Set 实现类。代码如下：
+
+  ```
+  // LinkedHashMap.java
+  
+  final class LinkedKeySet extends AbstractSet<K> {
+  
+      public final int size()                 { return size; }
+      public final void clear()               { LinkedHashMap.this.clear(); }
+      public final Iterator<K> iterator() {
+          return new LinkedKeyIterator(); // <X>
+      }
+      public final boolean contains(Object o) { return containsKey(o); }
+      public final boolean remove(Object key) {
+          return removeNode(hash(key), key, null, false, true) != null;
+      }
+      public final Spliterator<K> spliterator()  {
+          return Spliterators.spliterator(this, Spliterator.SIZED |
+                                          Spliterator.ORDERED |
+                                          Spliterator.DISTINCT);
+      }
+  
+      public Object[] toArray() {
+          return keysToArray(new Object[size]);
+      }
+  
+      public <T> T[] toArray(T[] a) {
+          return keysToArray(prepareArray(a));
+      }
+  
+      public final void forEach(Consumer<? super K> action) {
+          if (action == null)
+              throw new NullPointerException();
+          int mc = modCount;
+          for (LinkedHashMap.Entry<K,V> e = head; e != null; e = e.after)
+              action.accept(e.key);
+          if (modCount != mc)
+              throw new ConcurrentModificationException();
+      }
+  }
+  ```
+
+  - 其内部，调用的都是 LinkedHashMap 提供的方法。
+
+`#values()` 方法，获得 value Collection 。代码如下：
+
+```
+// LinkedHashMap.java
+
+public Collection<V> values() {
+    // 获得 values 缓存
+    Collection<V> vs = values;
+    // 如果不存在，则进行创建
+    if (vs == null) {
+        vs = new LinkedValues(); // LinkedValues 是 LinkedHashMap 自定义的
+        values = vs;
+    }
+    return vs;
+}
+```
+
+- 其中， LinkedValues 是 LinkedHashMap 自定义的 Collection 实现类。代码如下：
+
+  ```
+  // LinkedHashMap.java
+  
+  final class LinkedValues extends AbstractCollection<V> {
+      public final int size()                 { return size; }
+      public final void clear()               { LinkedHashMap.this.clear(); }
+      public final Iterator<V> iterator() {
+          return new LinkedValueIterator(); // <X>
+      }
+      public final boolean contains(Object o) { return containsValue(o); }
+      public final Spliterator<V> spliterator() {
+          return Spliterators.spliterator(this, Spliterator.SIZED |
+                                          Spliterator.ORDERED);
+      }
+  
+      public Object[] toArray() {
+          return valuesToArray(new Object[size]);
+      }
+  
+      public <T> T[] toArray(T[] a) {
+          return valuesToArray(prepareArray(a));
+      }
+  
+      public final void forEach(Consumer<? super V> action) {
+          if (action == null)
+              throw new NullPointerException();
+          int mc = modCount;
+          for (LinkedHashMap.Entry<K,V> e = head; e != null; e = e.after)
+              action.accept(e.value);
+          if (modCount != mc)
+              throw new ConcurrentModificationException();
+      }
+  }
+  ```
+
+  - 其内部，调用的都是 LinkedHashMap 提供的方法。
+
+`#entrySet()` 方法，获得 key-value Set 。代码如下：
+
+```
+// LinkedHashMap.java
+
+public Set<Map.Entry<K,V>> entrySet() {
+    Set<Map.Entry<K,V>> es;
+    // LinkedEntrySet 是 LinkedHashMap 自定义的
+    return (es = entrySet) == null ? (entrySet = new LinkedEntrySet()) : es;
+}
+```
+
+- 其中， LinkedEntrySet 是 LinkedHashMap 自定义的 Set 实现类。代码如下：
+
+  ```
+  // LinkedHashMap.java
+  
+  final class LinkedEntrySet extends AbstractSet<Map.Entry<K,V>> {
+      public final int size()                 { return size; }
+      public final void clear()               { LinkedHashMap.this.clear(); }
+      public final Iterator<Map.Entry<K,V>> iterator() {
+          return new LinkedEntryIterator(); // <X>
+      }
+      public final boolean contains(Object o) {
+          if (!(o instanceof Map.Entry))
+              return false;
+          Map.Entry<?,?> e = (Map.Entry<?,?>) o;
+          Object key = e.getKey();
+          Node<K,V> candidate = getNode(hash(key), key);
+          return candidate != null && candidate.equals(e);
+      }
+      public final boolean remove(Object o) {
+          if (o instanceof Map.Entry) {
+              Map.Entry<?,?> e = (Map.Entry<?,?>) o;
+              Object key = e.getKey();
+              Object value = e.getValue();
+              return removeNode(hash(key), key, value, true, true) != null;
+          }
+          return false;
+      }
+      public final Spliterator<Map.Entry<K,V>> spliterator() {
+          return Spliterators.spliterator(this, Spliterator.SIZED |
+                                          Spliterator.ORDERED |
+                                          Spliterator.DISTINCT);
+      }
+      public final void forEach(Consumer<? super Map.Entry<K,V>> action) {
+          if (action == null)
+              throw new NullPointerException();
+          int mc = modCount;
+          for (LinkedHashMap.Entry<K,V> e = head; e != null; e = e.after)
+              action.accept(e);
+          if (modCount != mc)
+              throw new ConcurrentModificationException();
+      }
+  }
+  ```
+
+  - 其内部，调用的都是 LinkedHashMap 提供的方法。
+
+在上面的代码中，艿艿实际标记了三处 `<X>` 标记，分别是 LinkedKeyIterator、LinkedValueIterator、LinkedEntryIterator ，用于迭代遍历 key、value、Entry 。而它们都继承了 LinkedHashIterator 抽象类，代码如下：
+
+```
+// LinkedHashMap.java
+
+abstract class LinkedHashIterator {
+
+    /**
+     * 下一个节点
+     */
+    LinkedHashMap.Entry<K,V> next;
+    /**
+     * 当前节点
+     */
+    LinkedHashMap.Entry<K,V> current;
+    /**
+     * 修改次数
+     */
+    int expectedModCount;
+
+    LinkedHashIterator() {
+        next = head;
+        expectedModCount = modCount;
+        current = null;
+    }
+
+    public final boolean hasNext() {
+        return next != null;
+    }
+
+    final LinkedHashMap.Entry<K,V> nextNode() {
+        LinkedHashMap.Entry<K,V> e = next;
+        // 如果发生了修改，抛出 ConcurrentModificationException 异常
+        if (modCount != expectedModCount)
+            throw new ConcurrentModificationException();
+        // 如果 e 为空，说明没有下一个节点，则抛出 NoSuchElementException 异常
+        if (e == null)
+            throw new NoSuchElementException();
+        // 遍历到下一个节点
+        current = e;
+        next = e.after;
+        return e;
+    }
+
+    public final void remove() {
+        // 移除当前节点
+        Node<K,V> p = current;
+        if (p == null)
+            throw new IllegalStateException();
+        // 如果发生了修改，抛出 ConcurrentModificationException 异常
+        if (modCount != expectedModCount)
+            throw new ConcurrentModificationException();
+        // 标记 current 为空，因为被移除了
+        current = null;
+        // 移除节点
+        removeNode(p.hash, p.key, null, false, false);
+        // 修改 expectedModCount 次数
+        expectedModCount = modCount;
+    }
+
+}
+
+final class LinkedKeyIterator extends LinkedHashIterator
+    implements Iterator<K> {
+
+    // key
+    public final K next() { return nextNode().getKey(); }
+}
+
+final class LinkedValueIterator extends LinkedHashIterator
+    implements Iterator<V> {
+
+    // value
+    public final V next() { return nextNode().value; }
+}
+
+final class LinkedEntryIterator extends LinkedHashIterator
+    implements Iterator<Map.Entry<K,V>> {
+
+    // Entry
+    public final Map.Entry<K,V> next() { return nextNode(); }
+}
+```
+
+# 9. 清空
+
+`#clear()` 方法，清空 LinkedHashMap 。代码如下：
+
+```
+// LinkedHashMap.java
+
+public void clear() {
+    // 清空
+    super.clear();
+    // 标记 head 和 tail 为 null
+    head = tail = null;
+}
+```
+
+- 需要额外清空 `head`、`tail` 。
+
+# 10. 其它方法
+
+> 本小节，我们会罗列下其他 LinkedHashMap 重写的方法。当然，可以选择不看。
+
+在序列化时，会调用到 `#internalWriteEntries(java.io.ObjectOutputStream s)` 方法，重写代码如下：
+
+```
+// LinkedHashMap.java
+
+void internalWriteEntries(java.io.ObjectOutputStream s) throws IOException {
+    // 通过 head 顺序遍历，从头到尾
+    for (LinkedHashMap.Entry<K,V> e = head; e != null; e = e.after) {
+        // 写入 key
+        s.writeObject(e.key);
+        // 写入 value
+        s.writeObject(e.value);
+    }
+}
+```
+
+在反序列化时，会调用 `#reinitialize()` 方法，重写代码如下：
+
+```
+// LinkedHashMap.java
+
+void reinitialize() {
+    // 调用父方法，初始化
+    super.reinitialize();
+    // 标记 head 和 tail 为 null
+    head = tail = null;
+}
+```
+
+查找值时，会调用 `#containsValue(Object value)` 方法，重写代码如下：
+
+```
+// LinkedHashMap.java
+
+public boolean containsValue(Object value) {
+    // 通过 head 顺序遍历，从头到尾
+    for (LinkedHashMap.Entry<K,V> e = head; e != null; e = e.after) {
+        V v = e.value;
+        // 判断是否相等
+        if (v == value || (value != null && value.equals(v)))
+            return true;
+    }
+    return false;
+}
+```
+
+# 666. 彩蛋
+
+如下几个方法，是 LinkedHashMap 重写和红黑树相关的几个方法，胖友可以自己瞅瞅：
+
+- `#replacementNode(Node<K,V> p, Node<K,V> next)`
+- `#newTreeNode(int hash, K key, V value, Node<K,V> next)`
+- `#replacementTreeNode(Node<K,V> p, Node<K,V> next)`
+- `#transferLinks(LinkedHashMap.Entry<K,V> src, LinkedHashMap.Entry<K,V> dst)`
+
+下面，我们来对 LinkedHashMap 做一个简单的小结：
+
+- LinkedHashMap 是 HashMap 的子类，增加了
+
+  顺序
+
+  访问的特性。
+
+  - 【默认】当 `accessOrder = false` 时，按照 key-value 的**插入**顺序进行访问。
+  - 当 `accessOrder = true` 时，按照 key-value 的**读取**顺序进行访问。
+
+- LinkedHashMap 的**顺序**特性，通过内部的双向链表实现，所以我们把它看成是 LinkedList + LinkedHashMap 的组合。
+
+- LinkedHashMap 通过重写 HashMap 提供的回调方法，从而实现其对**顺序**的特性的处理。同时，因为 LinkedHashMap 的**顺序**特性，需要重写 `#keysToArray(T[] a)` 等**遍历**相关的方法。
+
+- LinkedHashMap 可以方便实现 LRU 算法的缓存，
\ No newline at end of file
diff --git a/jdk/07-JDK 源码解析-集合（五）哈希集合 HashSet.assets/01.png b/jdk/07-JDK 源码解析-集合（五）哈希集合 HashSet.assets/01.png
new file mode 100644
index 0000000..d4c9659
Binary files /dev/null and b/jdk/07-JDK 源码解析-集合（五）哈希集合 HashSet.assets/01.png differ
diff --git a/jdk/07-JDK 源码解析-集合（五）哈希集合 HashSet.md b/jdk/07-JDK 源码解析-集合（五）哈希集合 HashSet.md
new file mode 100644
index 0000000..4d09607
--- /dev/null
+++ b/jdk/07-JDK 源码解析-集合（五）哈希集合 HashSet.md	
@@ -0,0 +1,301 @@
+# 精尽 JDK 源码解析 —— 集合（五）哈希集合 HashSet
+
+# 1. 概述
+
+> 艿艿：突然有点词穷，不知道怎么介绍，嘿嘿。
+
+HashSet ，基于 HashMap 的 Set 实现类。在业务中，如果我们有排重的需求，一般会考虑使用 HashSet 。
+
+在 Redis 提供的 Set 数据结构，不考虑编码的情况下，它是基于 Redis 自身的 Hash 数据结构实现的。这点，JDK 和 Redis 是相同的。😈 感兴趣的胖友，看完本文后，可以自己去撸一撸。
+
+# 2. 类图
+
+HashSet 实现的接口、继承的类，如下图所示：[![类图](07-JDK 源码解析-集合（五）哈希集合 HashSet.assets/01.png)](http://static.iocoder.cn/images/JDK/2019_12_13/01.png)类图
+
+- 实现 [`java.util.Set`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/util/Set.java) 接口，并继承 [`java.util.AbstractSet`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/util/AbstractSet.java) 抽像类。
+- 实现 [`java.io.Serializable`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/io/Serializable.java) 接口。
+- 实现 [`java.lang.Cloneable`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/lang/Cloneable.java) 接口。
+
+# 3. 属性
+
+HashSet 只有一个属性，那就是 `map` 。代码如下：
+
+```
+// HashSet.java
+
+private transient HashMap<E, Object> map;
+```
+
+- `map` 的 key ，存储 HashSet 的每个 key 。
+
+- `map` 的 value ，因为 HashSet 没有 value 的需要，所以使用一个统一的 `PRESENT` 即可。代码如下：
+
+  ```
+  // HashSet.java
+  
+  // Dummy value to associate with an Object in the backing Map
+  private static final Object PRESENT = new Object();
+  ```
+
+# 4. 构造方法
+
+HashSet 一共有 5 个构造方法，代码如下：
+
+```
+// HashSet.java
+
+public HashSet() {
+    map = new HashMap<>();
+}
+
+public HashSet(Collection<? extends E> c) {
+    // 最小必须是 16 。
+    // (int) (c.size()/.75f) + 1 避免扩容
+    map = new HashMap<>(Math.max((int) (c.size()/.75f) + 1, 16));
+    // 批量添加
+    addAll(c);
+}
+
+public HashSet(int initialCapacity, float loadFactor) {
+    map = new HashMap<>(initialCapacity, loadFactor);
+}
+
+public HashSet(int initialCapacity) {
+    map = new HashMap<>(initialCapacity);
+}
+
+HashSet(int initialCapacity, float loadFactor, boolean dummy) {
+    map = new LinkedHashMap<>(initialCapacity, loadFactor); // 注意，这种情况下的构造方法，创建的是 LinkedHashMap 对象
+}
+```
+
+- 在构造方法中，会创建 HashMap 或 LinkedHashMap 对象。
+
+# 5. 添加单个元素
+
+`#add(E e)` 方法，添加单个元素。代码如下：
+
+```
+// HashSet.java
+
+public boolean add(E e) {
+    return map.put(e, PRESENT)==null;
+}
+```
+
+- `map` 的 value 值，就是我们看到的 `PRESENT` 。
+
+而添加多个元素，继承自 AbstractCollection 抽象类，通过 `#addAll(Collection<? extends E> c)` 方法，代码如下：
+
+```
+// AbstractCollection.java
+
+public boolean addAll(Collection<? extends E> c) {
+    boolean modified = false;
+    // 遍历 c 集合，逐个添加
+    for (E e : c)
+        if (add(e))
+            modified = true;
+    return modified;
+}
+```
+
+- 在方法内部，会逐个调用 `#add(E e)` 方法，逐个添加单个元素。
+
+# 6. 移除单个元素
+
+`#remove(Object key)` 方法，移除 key 对应的 value ，并返回该 value 。代码如下：
+
+```
+// HashSet.java
+
+public boolean remove(Object o) {
+    return map.remove(o) == PRESENT;
+}
+```
+
+# 7. 查找单个元素
+
+`#contains(Object key)` 方法，判断 key 是否存在。代码如下：
+
+```
+// HashSet.java
+
+public boolean contains(Object o) {
+    return map.containsKey(o);
+}
+```
+
+> 艿艿：后面的内容，快速看即可。
+
+# 8. 转换成数组
+
+`#toArray(T[] a)` 方法，转换出 key 数组返回。代码如下：
+
+```
+// HashSet.java
+
+@Override
+public Object[] toArray() {
+    return map.keysToArray(new Object[map.size()]);
+}
+
+@Override
+public <T> T[] toArray(T[] a) {
+    return map.keysToArray(map.prepareArray(a));
+}
+```
+
+# 9. 清空
+
+`#clear()` 方法，清空 HashSet 。代码如下：
+
+```
+// HashSet.java
+
+public void clear() {
+    map.clear();
+}
+```
+
+# 10. 序列化
+
+`#writeObject(ObjectOutputStream s)` 方法，序列化 HashSet 对象。代码如下：
+
+```
+// HashSet.java
+
+@java.io.Serial
+private void writeObject(java.io.ObjectOutputStream s)
+    throws java.io.IOException {
+    // Write out any hidden serialization magic
+    // 写入非静态属性、非 transient 属性
+    s.defaultWriteObject();
+
+    // Write out HashMap capacity and load factor
+    // 写入 map table 数组大小
+    s.writeInt(map.capacity());
+    // 写入 map 加载因子
+    s.writeFloat(map.loadFactor());
+
+    // Write out size
+    // 写入 map 大小
+    s.writeInt(map.size());
+
+    // Write out all elements in the proper order.
+    // 遍历 map ，逐个 key 序列化
+    for (E e : map.keySet())
+        s.writeObject(e);
+}
+```
+
+# 11. 反序列化
+
+`#readObject(ObjectInputStream s)` 方法，反序列化成 HashSet 对象。代码如下：
+
+```
+// HashSet.java
+
+@java.io.Serial
+private void readObject(java.io.ObjectInputStream s)
+    throws java.io.IOException, ClassNotFoundException {
+    // Read in any hidden serialization magic
+    // 读取非静态属性、非 transient 属性
+    s.defaultReadObject();
+
+    // Read capacity and verify non-negative.
+    // 读取 HashMap table 数组大小
+    int capacity = s.readInt();
+    // 校验 capacity 参数
+    if (capacity < 0) {
+        throw new InvalidObjectException("Illegal capacity: " +
+                                         capacity);
+    }
+
+    // Read load factor and verify positive and non NaN.
+    // 获得加载因子 loadFactor
+    float loadFactor = s.readFloat();
+    // 校验 loadFactor 参数
+    if (loadFactor <= 0 || Float.isNaN(loadFactor)) {
+        throw new InvalidObjectException("Illegal load factor: " +
+                                         loadFactor);
+    }
+
+    // Read size and verify non-negative.
+    // 读取 key-value 键值对数量 size
+    int size = s.readInt();
+    // 校验 size 参数
+    if (size < 0) {
+        throw new InvalidObjectException("Illegal size: " +
+                                         size);
+    }
+
+    // Set the capacity according to the size and load factor ensuring that
+    // the HashMap is at least 25% full but clamping to maximum capacity.
+    // 计算容量
+    capacity = (int) Math.min(size * Math.min(1 / loadFactor, 4.0f),
+            HashMap.MAXIMUM_CAPACITY);
+
+    // Constructing the backing map will lazily create an array when the first element is
+    // added, so check it before construction. Call HashMap.tableSizeFor to compute the
+    // actual allocation size. Check Map.Entry[].class since it's the nearest public type to
+    // what is actually created.
+    SharedSecrets.getJavaObjectInputStreamAccess()
+                 .checkArray(s, Map.Entry[].class, HashMap.tableSizeFor(capacity)); // 不知道作甚，哈哈哈。
+
+    // Create backing HashMap
+    // 创建 LinkedHashMap 或 HashMap 对象
+    map = (((HashSet<?>)this) instanceof LinkedHashSet ?
+           new LinkedHashMap<>(capacity, loadFactor) :
+           new HashMap<>(capacity, loadFactor));
+
+    // Read in all elements in the proper order.
+    // 遍历读取 key 键，添加到 map 中
+    for (int i=0; i<size; i++) {
+        @SuppressWarnings("unchecked")
+            E e = (E) s.readObject();
+        map.put(e, PRESENT);
+    }
+}
+```
+
+# 12. 克隆
+
+`#clone()` 方法，克隆 HashSet 对象。代码如下：
+
+```
+// HashSet.java
+
+public Object clone() {
+    try {
+        // 调用父方法，克隆创建 newSet 对象
+        HashSet<E> newSet = (HashSet<E>) super.clone();
+        // 可控 mao 属性，赋值给 newSet
+        newSet.map = (HashMap<E, Object>) map.clone();
+        // 返回
+        return newSet;
+    } catch (CloneNotSupportedException e) {
+        throw new InternalError(e);
+    }
+}
+```
+
+# 13. 获得迭代器
+
+`#iterator()` 方法，获得迭代器。代码如下：
+
+```
+// HashSet.java
+
+public Iterator<E> iterator() {
+    return map.keySet().iterator();
+}
+```
+
+# 666. 彩蛋
+
+😈 总的来说，比较简单，相信胖友一会会时间就已经看完了。
+
+可能偶尔我们会使用到 LinkedHashSet ，它是 HashSet 的子类，胖友自己去看。更加简单~
+
+关于 HashSet 的总结，只有一句话：HashSet 是基于 HashMap 的 Set 实现类。
\ No newline at end of file
diff --git a/jdk/08-JDK 源码解析-集合（六）TreeMap.assets/01.png b/jdk/08-JDK 源码解析-集合（六）TreeMap.assets/01.png
new file mode 100644
index 0000000..5980550
Binary files /dev/null and b/jdk/08-JDK 源码解析-集合（六）TreeMap.assets/01.png differ
diff --git a/jdk/08-JDK 源码解析-集合（六）TreeMap.assets/02.png b/jdk/08-JDK 源码解析-集合（六）TreeMap.assets/02.png
new file mode 100644
index 0000000..78e7a28
Binary files /dev/null and b/jdk/08-JDK 源码解析-集合（六）TreeMap.assets/02.png differ
diff --git a/jdk/08-JDK 源码解析-集合（六）TreeMap.assets/03.png b/jdk/08-JDK 源码解析-集合（六）TreeMap.assets/03.png
new file mode 100644
index 0000000..4dfd23e
Binary files /dev/null and b/jdk/08-JDK 源码解析-集合（六）TreeMap.assets/03.png differ
diff --git a/jdk/08-JDK 源码解析-集合（六）TreeMap.md b/jdk/08-JDK 源码解析-集合（六）TreeMap.md
new file mode 100644
index 0000000..8ecc825
--- /dev/null
+++ b/jdk/08-JDK 源码解析-集合（六）TreeMap.md	
@@ -0,0 +1,2853 @@
+# 精尽 JDK 源码解析 —— 集合（六）TreeMap
+
+# 1. 概述
+
+在 [《精尽 JDK 源码解析 —— 集合（四）哈希表 LinkedHashMap》](http://svip.iocodder.cn/JDK/Collection-LinkedHashMap) 中，我们提到了两种**有序** Map 的选择。一种是 LinkedHashMap ，以前在该文进行了详细解析，而本文，我们开始 TreeMap 之旅，**按照 key 的顺序**的 Map 实现类。
+
+在开始之前，艿艿捉摸了下，什么业务场景下适合使用 TreeMap 呢？发现好像基本没有，嘿嘿。然后，我又翻了自己团队的几个项目，发现唯一在使用的，就是在 [签名生成算法](https://pay.weixin.qq.com/wiki/doc/api/jsapi.php?chapter=4_3) 时，要求按照请求参数的 key 排序，然后拼接后加密。如果胖友有 TreeMap 的使用场景，请一定在星球给留言，艿艿可以补充到本文。
+
+# 2. 类图
+
+TreeMap 实现的接口、继承的类，如下图所示：[![类图](08-JDK 源码解析-集合（六）TreeMap.assets/01.png)](http://static.iocoder.cn/images/JDK/2019_12_13_02/01.png)类图
+
+- 实现 [`java.util.Map`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/util/Map.java) 接口，并继承 [`java.util.AbstractMap`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/util/AbstractMap.java) 抽像类。
+
+- 直接实现
+
+   
+
+  `java.util.NavigableMap`
+
+   
+
+  接口，间接实现
+
+   
+
+  `java.util.NavigableMap`
+
+   
+
+  接口。关于这两接口的定义的操作，已经添加注释，胖友可以直接点击查看。因为 SortedMap 有很多雷同的寻找最接近 key 的操作，这里简单总结下：
+
+  - lower ：小于 ；floor ：小于等于
+  - higher ：大于；ceiling ：大于等于
+
+- 实现 [`java.io.Serializable`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/io/Serializable.java) 接口。
+
+- 实现 [`java.lang.Cloneable`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/lang/Cloneable.java) 接口。
+
+# 3. 属性
+
+在开始看 TreeMap 的具体属性之前，我们先来简单说说 TreeMap 的实现原理。
+
+在 [《精尽 JDK 源码解析 —— 集合（三）哈希表 HashMap》](http://svip.iocoder.cn/JDK/Collection-HashMap) 文章中，我们提到，HashMap 的数组，每个桶的链表在元素过多的情况下，会转换成**红黑树**。而 TreeMap 也是基于红黑树实现的，并且只是**一棵**红黑树。所以 TreeMap 可以理解成 HashMap 数组中的**一个**转换成**红黑树**的桶。
+
+为什么 TreeMap 会采用红黑树实现呢？我们来看一段红黑树的定义：
+
+> FROM [《维基百科 —— 红黑树》](https://zh.wikipedia.org/wiki/红黑树)
+>
+> **红黑树**（英语：Red–black tree）是一种[自平衡二叉查找树](https://zh.wikipedia.org/wiki/自平衡二叉查找树)，是在[计算机科学](https://zh.wikipedia.org/wiki/计算机科学)中用到的一种[数据结构](https://zh.wikipedia.org/wiki/数据结构)，典型的用途是实现[关联数组](https://zh.wikipedia.org/wiki/关联数组)。
+>
+> 它在 1972 年由[鲁道夫·贝尔](https://zh.wikipedia.org/wiki/鲁道夫·贝尔)发明，被称为”**对称二叉B树**“，它现代的名字源于 Leo J. Guibas 和 [Robert Sedgewick](https://zh.wikipedia.org/wiki/Robert_Sedgewick) 于 [1978年] (https://zh.wikipedia.org/wiki/1978年) 写的一篇论文。红黑树的结构复杂，但它的操作有着良好的最坏情况[运行时间](https://zh.wikipedia.org/wiki/算法分析)，并且在实践中高效：它可以在 `logN` 时间内完成查找，插入和删除，这里的 `N` 是树中元素的数目。
+
+- **有序性**：红黑树是一种**二叉查找树**，父节点的 key 小于左子节点的 key ，大于右子节点的 key 。这样，就完成了 TreeMap 的有序的特性。
+- **高性能**：红黑树会进行**自平衡**，避免树的高度过高，导致查找性能下滑。这样，红黑树能够提供 `logN` 的时间复杂度。
+
+> 艿艿：绝大多数情况下，包括面试，我们无需了解红黑树是怎么实现的，甚至原理是什么。只要知道，红黑树的上述概念，和时间复杂度即可。
+>
+> 所以，本文我们不会涉及红黑树的**自平衡**的内容。如果感兴趣的胖友，可以自己阅读如下的文章：
+>
+> - [《教你初步了解红黑树》](https://blog.csdn.net/v_july_v/article/details/6105630)
+> - [《史上最清晰的红黑树讲解（上）》](https://www.cnblogs.com/CarpenterLee/p/5503882.html)
+> - [《史上最清晰的红黑树讲解（下）》](https://www.cnblogs.com/CarpenterLee/p/5525688.html)
+
+下面，让我们来看看 TreeMap 的属性。代码如下：
+
+```
+// TreeMap.java
+
+/**
+ * key 排序器
+ */
+private final Comparator<? super K> comparator;
+
+/**
+ * 红黑树的根节点
+ */
+private transient Entry<K,V> root;
+
+/**
+ * key-value 键值对数量
+ */
+private transient int size = 0;
+
+/**
+ * 修改次数
+ */
+private transient int modCount = 0;
+```
+
+- `comparator` 属性，key 排序器。通过该属性，可以自定义 key 的排序规则。如果未设置，则使用 key 类型自己的排序。
+
+- `root` 属性，红黑树的根节点。其中，Entry 是 TreeMap 的内部静态类，代码如下：
+
+  ```
+  // TreeMap.java
+  
+  /**
+   * 颜色 - 红色
+   */
+  private static final boolean RED   = false;
+  /**
+   * 颜色 - 黑色
+   */
+  private static final boolean BLACK = true;
+  
+  static final class Entry<K,V> implements Map.Entry<K,V> {
+  
+      /**
+       * key 键
+       */
+      K key;
+      /**
+       * value 值
+       */
+      V value;
+      /**
+       * 左子节点
+       */
+      Entry<K,V> left;
+      /**
+       * 右子节点
+       */
+      Entry<K,V> right;
+      /**
+       * 父节点
+       */
+      Entry<K,V> parent;
+      /**
+       * 颜色
+       */
+      boolean color = BLACK;
+      
+      // ... 省略一些
+      
+  }
+  ```
+
+# 4. 构造方法
+
+TreeMap 一共有四个构造方法，我们分别来看看。
+
+**① `#TreeMap()`**
+
+```
+// TreeMap.java
+
+public TreeMap() {
+    comparator = null;
+}
+```
+
+- 默认构造方法，不使用自定义排序，所以此时 `comparator` 为空。
+
+**② `#TreeMap(Comparator<? super K> comparator)`**
+
+```
+// TreeMap.java
+
+public TreeMap(Comparator<? super K> comparator) {
+    this.comparator = comparator;
+}
+```
+
+- 可传入 `comparator` 参数，自定义 key 的排序规则。
+
+**③ `#TreeMap(SortedMap<K, ? extends V> m)`**
+
+```
+// TreeMap.java
+
+public TreeMap(SortedMap<K, ? extends V> m) {
+    // <1> 设置 comparator 属性
+    comparator = m.comparator();
+    try {
+        // <2> 使用 m 构造红黑树
+        buildFromSorted(m.size(), m.entrySet().iterator(), null, null);
+    } catch (java.io.IOException | ClassNotFoundException cannotHappen) {
+    }
+}
+```
+
+- 传入已经排序的 `m` ，然后构建出 TreeMap 。
+- `<1>` 处，使用 `m` 的 key 排序器，设置到 `comparator` 属性。
+- `<2>` 处，调用 `#buildFromSorted(int size, Iterator<?> it, ObjectInputStream str, V defaultVal)` 方法，使用 `m` 构造红黑树。因为 `m` 是 SortedMap 类型，所以天然**有序**，所以可以基于 `m` 的中间为红黑树的根节点，`m` 的左边为左子树，`m` 的右边为右子树。😈 胖友，发挥下自己的想象力。
+
+`#buildFromSorted(int size, Iterator<?> it, ObjectInputStream str, V defaultVal)` ，代码如下：
+
+```
+// TreeMap.java
+
+private void buildFromSorted(int size, Iterator<?> it,
+                             java.io.ObjectInputStream str,
+                             V defaultVal)
+    throws  java.io.IOException, ClassNotFoundException {
+    // <1> 设置 key-value 键值对的数量
+    this.size = size;
+    // <2> computeRedLevel(size) 方法，计算红黑树的高度
+    // <3> 使用 m 构造红黑树，返回根节点
+    root = buildFromSorted(0, 0, size - 1, computeRedLevel(size),
+                           it, str, defaultVal);
+}
+```
+
+- `<1>` 处，设置 key-value 键值对的数量到 `size` 。
+
+- `<2>` 处，调用 `#computeRedLevel(int size)` 方法，计算红黑树的高度。代码如下：
+
+  ```
+  // TreeMap.java
+  
+  private static int computeRedLevel(int size) {
+      return 31 - Integer.numberOfLeadingZeros(size + 1);
+  }
+  ```
+
+- `<3>` 处，调用 `#buildFromSorted(int level, int lo, int hi, int redLevel, Iterator<?> it, ObjectInputStream str, V defaultVal)` 方法，使用 `m` 构造红黑树，返回根节点。
+
+`#buildFromSorted(int level, int lo, int hi, int redLevel, Iterator<?> it, ObjectInputStream str, V defaultVal)` 方法，代码如下：
+
+```
+// TreeMap.java
+
+private final Entry<K,V> buildFromSorted(int level, int lo, int hi,
+                                         int redLevel,
+                                         Iterator<?> it,
+                                         java.io.ObjectInputStream str,
+                                         V defaultVal)
+    throws  java.io.IOException, ClassNotFoundException {
+    /*
+     * Strategy: The root is the middlemost element. To get to it, we
+     * have to first recursively construct the entire left subtree,
+     * so as to grab all of its elements. We can then proceed with right
+     * subtree.
+     *
+     * The lo and hi arguments are the minimum and maximum
+     * indices to pull out of the iterator or stream for current subtree.
+     * They are not actually indexed, we just proceed sequentially,
+     * ensuring that items are extracted in corresponding order.
+     */
+    // <1.1> 递归结束
+    if (hi < lo) return null;
+
+    // <1.2> 计算中间值
+    int mid = (lo + hi) >>> 1;
+
+    // <2.1> 创建左子树
+    Entry<K,V> left  = null;
+    if (lo < mid)
+        // <2.2> 递归左子树
+        left = buildFromSorted(level + 1, lo, mid - 1, redLevel,
+                               it, str, defaultVal);
+
+    // extract key and/or value from iterator or stream
+    // <3.1> 获得 key-value 键值对
+    K key;
+    V value;
+    if (it != null) { // 使用 it 迭代器，获得下一个值
+        if (defaultVal == null) {
+            Map.Entry<?,?> entry = (Map.Entry<?,?>)it.next(); // 从 it 获得下一个 Entry 节点
+            key = (K) entry.getKey(); // 读取 key
+            value = (V) entry.getValue(); // 读取 value
+        } else {
+            key = (K)it.next();  // 读取 key
+            value = defaultVal; // 设置 default 为 value
+        }
+    } else { // use stream 处理 str 流的情况
+        key = (K) str.readObject(); //  从 str 读取 key 值
+        value = (defaultVal != null ? defaultVal : (V) str.readObject()); // 从 str 读取 value 值
+    }
+
+    
+    // <3.2> 创建中间节点
+    Entry<K,V> middle =  new Entry<>(key, value, null);
+
+    // color nodes in non-full bottommost level red
+    // <3.3> 如果到树的最大高度，则设置为红节点
+    if (level == redLevel)
+        middle.color = RED;
+
+    // <3.4> 如果左子树非空，则进行设置
+    if (left != null) {
+        middle.left = left; // 当前节点，设置左子树
+        left.parent = middle; // 左子树，设置父节点为当前节点
+    }
+
+    // <4.1> 创建右子树
+    if (mid < hi) {
+        // <4.2> 递归右子树
+        Entry<K,V> right = buildFromSorted(level + 1, mid + 1, hi, redLevel,
+                                           it, str, defaultVal);
+        // <4.3> 当前节点，设置右子树
+        middle.right = right;
+        // <4.3> 右子树，设置父节点为当前节点
+        right.parent = middle;
+    }
+
+    // 返回当前节点
+    return middle;
+}
+```
+
+- 基于**有序**的 `it` 迭代器或者 `str` 输入流，将其的中间点作为根节点，其左边作为左子树，其右边作为右子树。因为是基于递归实现，所以中间点是基于 `lo` 和 `hi` 作为 `it` 或 `str` 的“数组”范围。
+
+  > 如果胖友有学习过数据结构与算法，这里代码的实现，就是基于 [《五大常用算法之一：分治算法》](https://www.cnblogs.com/steven_oyj/archive/2010/05/22/1741370.html) 。
+
+- `<1.1>` 处，如果 `hi` 小于 `lo` ，说明已经超过范围，所以可以结束循环。
+
+- `<1.2>` 处，计算中间位置。
+
+- 左子树
+
+  - `<2.1>` 处，处理 `mid` 中间位置的左边，处理左子树。
+  - `<2.2>` 处，调用 `#buildFromSorted(int level, int lo, int hi, int redLevel, Iterator<?> it, ObjectInputStream str, V defaultVal)` 方法，递归处理 `it` 或 `str` 的 `[lo, mid - 1]` 范围，创建左子树，返回该子树的根节点，赋值给 `left` 。
+
+- 当前节点（中间节点）
+
+  - `<3.1>` 处，获得 key-value 键值对。分成使用 `it` 或 `str` 读取的两种情况。有一点要注意，在 `defaultVal` 非空的时候，使用它作为 value 。
+  - `<3.2>` 处，创建当前节点。
+  - `<3.3>` 处，如果到树的最大高度，则设置为红节点。
+  - `<3.4>` 处，如果左子树非空，则进行设置。
+
+- 右子树
+
+  - `<4.1>` 处，处理 `mid` 中间位置的右边，处理右子树。
+  - `<4.2>` 处，调用 `#buildFromSorted(int level, int lo, int hi, int redLevel, Iterator<?> it, ObjectInputStream str, V defaultVal)` 方法，递归处理 `it` 或 `str` 的 `[mid + 1, high]` 范围，创建右子树，返回该子树的根节点，赋值给 `right` 。
+  - `<4.3>` 处，设置右子树。
+
+- 返回当前节点。因为是递归，所以递归的第一层，是 TreeMap 红黑树的根节点。
+
+**④ `#TreeMap(Map<? extends K, ? extends V> m)`**
+
+```
+// TreeMap.java
+
+public TreeMap(Map<? extends K, ? extends V> m) {
+    comparator = null;
+    // 添加所有元素
+    putAll(m);
+}
+```
+
+- 传入 `m` 的是 Map 类型，构建成初始的 TreeMap 。
+- 调用 `#putAll(Map<? extends K, ? extends V> map)` 方法，添加所有元素。
+
+`#putAll(Map<? extends K, ? extends V> map)` 方法，代码如下：
+
+```
+// TreeMap.java
+
+public void putAll(Map<? extends K, ? extends V> map) {
+    // <1> 路径一，满足如下条件，调用 buildFromSorted 方法来优化处理
+    int mapSize = map.size();
+    if (size == 0 // 如果 TreeMap 的大小为 0
+            && mapSize != 0 // map 的大小非 0
+            && map instanceof SortedMap) { // 如果是 map 是 SortedMap 类型
+        if (Objects.equals(comparator, ((SortedMap<?,?>)map).comparator())) { // 排序规则相同
+            // 增加修改次数
+            ++modCount;
+            // 基于 SortedMap 顺序迭代插入即可
+            try {
+                buildFromSorted(mapSize, map.entrySet().iterator(),
+                                null, null);
+            } catch (java.io.IOException | ClassNotFoundException cannotHappen) {
+            }
+            return;
+        }
+    }
+    // <2> 路径二，直接遍历 map 来添加
+    super.putAll(map);
+}
+```
+
+- 分成 `<1>` 和 `<2>` 两种情况。其中，`<1>` 是作为优化的方式，处理在 TreeMap 为空时，并且 `map` 为 SortedMap 类型时，可以直接调用 `#buildFromSorted(int level, int lo, int hi, int redLevel, Iterator<?> it, ObjectInputStream str, V defaultVal)` 方法，可以基于 SortedMap 顺序迭代插入即可，性能更优。
+
+# 5. 添加单个元素
+
+`#put(K key, V value)` 方法，添加单个元素。代码如下：
+
+```
+// TreeMap.java
+
+public V put(K key, V value) {
+    // 记录当前根节点
+    Entry<K,V> t = root;
+    // <1> 如果无根节点，则直接使用 key-value 键值对，创建根节点
+    if (t == null) {
+        // <1.1> 校验 key 类型。
+        compare(key, key); // type (and possibly null) check
+
+        // <1.2> 创建 Entry 节点
+        root = new Entry<>(key, value, null);
+        // <1.3> 设置 key-value 键值对的数量
+        size = 1;
+        // <1.4> 增加修改次数
+        modCount++;
+        return null;
+    }
+    // <2> 遍历红黑树
+    int cmp; // key 比父节点小还是大
+    Entry<K,V> parent; // 父节点
+    // split comparator and comparable paths
+    Comparator<? super K> cpr = comparator;
+    if (cpr != null) { // 如果有自定义 comparator ，则使用它来比较
+        do {
+            // <2.1> 记录新的父节点
+            parent = t;
+            // <2.2> 比较 key
+            cmp = cpr.compare(key, t.key);
+            // <2.3> 比 key 小，说明要遍历左子树
+            if (cmp < 0)
+                t = t.left;
+            // <2.4> 比 key 大，说明要遍历右子树
+            else if (cmp > 0)
+                t = t.right;
+            // <2.5> 说明，相等，说明要找到的 t 就是 key 对应的节点，直接设置 value 即可。
+            else
+                return t.setValue(value);
+        } while (t != null);  // <2.6>
+    } else { // 如果没有自定义 comparator ，则使用 key 自身比较器来比较
+        if (key == null) // 如果 key 为空，则抛出异常
+            throw new NullPointerException();
+        @SuppressWarnings("unchecked")
+        Comparable<? super K> k = (Comparable<? super K>) key;
+        do {
+            // <2.1> 记录新的父节点
+            parent = t;
+            // <2.2> 比较 key
+            cmp = k.compareTo(t.key);
+            // <2.3> 比 key 小，说明要遍历左子树
+            if (cmp < 0)
+                t = t.left;
+            // <2.4> 比 key 大，说明要遍历右子树
+            else if (cmp > 0)
+                t = t.right;
+            // <2.5> 说明，相等，说明要找到的 t 就是 key 对应的节点，直接设置 value 即可。
+            else
+                return t.setValue(value);
+        } while (t != null); // <2.6>
+    }
+    // <3> 创建 key-value 的 Entry 节点
+    Entry<K,V> e = new Entry<>(key, value, parent);
+    // 设置左右子树
+    if (cmp < 0) // <3.1>
+        parent.left = e;
+    else // <3.2>
+        parent.right = e;
+    // <3.3> 插入后，进行自平衡
+    fixAfterInsertion(e);
+    // <3.4> 设置 key-value 键值对的数量
+    size++;
+    // <3.5> 增加修改次数
+    modCount++;
+    return null;
+}
+```
+
+- 虽然比较长，逻辑还是相对清晰的。因为红黑树是二叉查找树，所以我们可以使用二分查找的方式遍历红黑树。循环遍历红黑树的节点，根据不同的结果，进行处理：
+
+  - 如果当前节点比 `key` 小，则遍历左子树。
+  - 如果当前节点比 `key` 大，则遍历右子树。
+  - 如果当前节点比 `key` 相等，则直接设置该节点的 `value` 即可。
+  - 如果遍历到叶子节点，无法满足上述情况，则说明我们需要给 key-value 键值对，创建 Entry 节点。如果比叶子节点小，则作为左子树；如果比叶子节点大，则作为右子树。
+
+- `<1>` 处，如果无根节点，则直接使用 key-value 键值对，创建根节点。
+
+  - `<1.1>` 处，调用 `#compare(Object k1, Object k2)` 方法， 比较 `key` 。代码如下：
+
+    ```
+    // TreeMap.java
+    
+    final int compare(Object k1, Object k2) {
+        return comparator == null ?
+                ((Comparable<? super K>)k1).compareTo((K)k2) // 如果没有自定义 comparator 比较器，则使用 key 自身比较
+                : comparator.compare((K)k1, (K)k2); // 如果有自定义 comparator 比较器，则使用它来比较。
+    }
+    ```
+
+    - 根据是否有自定义的 `comparator` 比较器，进行 key 的比较。
+
+  - `<1.2>` 处，创建 key-value 键值对的 Entry 节点，并赋值给 `root` 节点。
+
+- ```
+  <2>
+  ```
+
+   
+
+  处，遍历红黑树。会分成是否有自定义的
+
+   
+
+  ```
+  comparator
+  ```
+
+   
+
+  作为遍历左右节点的比较器，逻辑是相同的。所以，我们只看
+
+   
+
+  ```
+  cpr != null
+  ```
+
+   
+
+  的部分先。
+
+  - `<2.1>` 处，记录新的父节点。目的是，如果遍历到叶子节点 `t` 时，无法继续遍历时，此时 `parent` 作为被插入的父节点。
+  - `<2.2>` 处，比较 key 。
+  - `<2.3>` 处， 比 `key` 小，说明要遍历左子树。
+  - `<2.4>` 处，比 `key` 大，说明要遍历右子树。
+  - `<2.5>` 处，相等，说明要找到的 `t` 就是 `key` 对应的节点，直接设置 value 即可。
+  - `<2.6>` 处，通过 `while(t != null)` 来不断遍历，而 `t` 作为当前遍历到的节点。如果遍历到 `t` 为空时，说明二分查找不到 `key` 对应的节点，此时只能创建 key-value 的节点，根据 `key` 大小作为 `parent` 的左右节点。
+
+- ```
+  <3>
+  ```
+
+   
+
+  处，创建 key-value 的 Entry 节点。
+
+  - `<3.1>` 处，如果 `key` 比 `parent` 节点的 key 小，作为 `parent` 的左子节点。
+  - `<3.2>` 处，如果 `key` 比 `parent` 节点的 key 大，作为 `parent` 的右子节点。
+  - `<3.3>` 处，调用 `fixAfterInsertion(Entry<K,V> x)` 方法，插入后，进行**自平衡**。关于这块，我们就先不进行深入了。
+
+另外，因为 TreeMap 是基于树的结构实现，所以无需考虑扩容问题。
+
+# 6. 获得单个元素
+
+`#get(Object key)` 方法，获得 `key` 对应的 value 值。代码如下：
+
+```
+// TreeMap.java
+
+public V get(Object key) {
+    // 获得 key 对应的 Entry 节点
+    Entry<K,V> p = getEntry(key);
+    // 返回 value 值
+    return (p == null ? null : p.value);
+}
+
+final Entry<K,V> getEntry(Object key) { // 不使用 comparator 查找
+    // Offload comparator-based version for sake of performance
+    // 如果自定义了 comparator 比较器，则基于 comparator 比较来查找
+    if (comparator != null)
+        return getEntryUsingComparator(key);
+    // 如果 key 为空，抛出异常
+    if (key == null)
+        throw new NullPointerException();
+    @SuppressWarnings("unchecked")
+    Comparable<? super K> k = (Comparable<? super K>) key;
+    // 遍历红黑树
+    Entry<K,V> p = root;
+    while (p != null) {
+        // 比较值
+        int cmp = k.compareTo(p.key);
+        // 如果 key 小于当前节点，则遍历左子树
+        if (cmp < 0)
+            p = p.left;
+        // 如果 key 大于当前节点，则遍历右子树
+        else if (cmp > 0)
+            p = p.right;
+        // 如果 key 相等，则返回该节点
+        else
+            return p;
+    }
+    // 查找不到，返回 null
+    return null;
+}
+
+final Entry<K,V> getEntryUsingComparator(Object key) { // 使用 comparator 查找
+    @SuppressWarnings("unchecked")
+    K k = (K) key;
+    Comparator<? super K> cpr = comparator;
+    if (cpr != null) {
+        // 遍历红黑树
+        Entry<K,V> p = root;
+        while (p != null) {
+            // 比较值
+            int cmp = cpr.compare(k, p.key);
+            // 如果 key 小于当前节点，则遍历左子树
+            if (cmp < 0)
+                p = p.left;
+            // 如果 key 大于当前节点，则遍历右子树
+            else if (cmp > 0)
+                p = p.right;
+            // 如果 key 相等，则返回该节点
+            else
+                return p;
+        }
+    }
+    // 查找不到，返回 null
+    return null;
+}
+```
+
+- 和我们在 [「5. 添加单个元素」](https://svip.iocoder.cn/JDK/Collection-TreeMap/#) 中看到的，也是基于红黑树进行二分查找，逻辑是一致的。
+- 如果未自定义 `comparator` 比较器，则调用 `#getEntry(Object key)` 方法，使用 key 自身的排序，进行比较二分查找。
+- 如果有自定义 `comparator` 比较器，则调用 `#getEntryUsingComparator(Object key)` 方法，使用 `comparator` 的排序，进行比较二分查找。
+
+`#containsKey(Object key)` 方法，判断是否存在指定 key 。代码如下：
+
+```
+// TreeMap.java
+
+public boolean containsKey(Object key) {
+    return getEntry(key) != null;
+}
+```
+
+- 基于 `#getEntry(key)` 方法来实现。
+
+# 7. 删除单个元素
+
+相比 [「5. 添加单个元素」](https://svip.iocoder.cn/JDK/Collection-TreeMap/#) 来说，删除会更加复杂一些。所以呢，我们先看删除的四种情况。为了让案例更加复杂，我们会使用一颗二叉查找树来举例子。因为，在去掉自平衡的逻辑的情况下，红黑树的删除和二叉查查找树的删除逻辑是一致的。
+
+对于二叉查找树的删除，需要保证删除节点后，能够继续满足**二叉**和**查找**的特性。
+
+[![查找二叉树](08-JDK 源码解析-集合（六）TreeMap.assets/02.png)](http://static.iocoder.cn/images/JDK/2019_12_13_02/02.png)查找二叉树
+
+> 该图通过 http://btv.melezinek.cz/binary-search-tree.html 绘制，胖友可以通过使用它，辅助理解这个过程。
+
+情况一，无子节点。
+直接删除父节点对其的指向即可。
+例如说，叶子节点 5、11、14、18 。
+
+情况二，**只**有左子节点。
+将删除节点的父节点，指向删除节点的左子节点。
+例如说，节点 20 。可以通过将节点 15 的右子节点指向节点 19 。
+
+情况三，**只**有右子节点。
+和情况二的处理方式一致。将删除节点的父节点，指向删除节点的右子节点。
+图中暂无示例，胖友自己脑补下，嘿嘿。
+
+情况四，有左子节点 + 右子节点。
+这种情况，相对会比较复杂，因为无法使用子节点替换掉删除的节点。所以此时有一个巧妙的思路。我们结合删除节点 15 来举例。
+
+- 1、先查找节点 15 的右子树的**最小值**，找到是节点 17 。
+- 2、将节点 17 设置到节点 15 上。因为节点 17 是右子树的最小值，能够满足比节点 15 的左子树都大，右子树都小。这样，问题就可以变成删除节点 17 。
+- 3、删除节点 17 的过程，满足情况三。将节点 19 的左子节点指向节点 18 即可。
+
+理解完这四种情况后，我们来看看代码。`#remove(Object key)` 方法，移除 `key` 对应的 Entry 节点。代码如下：
+
+```
+// TreeMap.java
+
+public V remove(Object key) {
+    // <1> 获得 key 对应的 Entry 节点
+    Entry<K,V> p = getEntry(key);
+    // <2> 如果不存在，则返回 null ，无需删除
+    if (p == null)
+        return null;
+
+    V oldValue = p.value;
+    // <3> 删除节点
+    deleteEntry(p);
+    return oldValue;
+}
+```
+
+- `<1>` 处，调用 `#getEntry(Object key)` 方法，获得 `key` 对应的 Entry 节点。
+- `<2>` 处，如果不存在，则返回 `null` ，无需删除。
+- `<3>` 处，调用 `#deleteEntry(Entry<K,V> p)` 方法，删除该节点。
+
+`#deleteEntry(Entry<K,V> p)` 方法，代码如下：
+
+```
+// TreeMap.java
+
+private void deleteEntry(Entry<K,V> p) {
+    // 增加修改次数
+    modCount++;
+    // 减少 key-value 键值对数
+    size--;
+
+    // If strictly internal, copy successor's element to p and then make p
+    // point to successor.
+    // <1> 如果删除的节点 p 既有左子节点，又有右子节点，
+    if (p.left != null && p.right != null) {
+        // <1.1> 获得右子树的最小值
+        Entry<K,V> s = successor(p);
+        // <1.2> 修改 p 的 key-value 为 s 的 key-value 键值对
+        p.key = s.key;
+        p.value = s.value;
+        // <1.3> 设置 p 指向 s 。此时，就变成删除 s 节点了。
+        p = s;
+    } // p has 2 children
+
+    // Start fixup at replacement node, if it exists.
+    // <2> 获得替换节点
+    Entry<K,V> replacement = (p.left != null ? p.left : p.right);
+    // <3> 有子节点的情况
+    if (replacement != null) {
+        // Link replacement to parent
+        // <3.1> 替换节点的父节点，指向 p 的父节点
+        replacement.parent = p.parent;
+        // <3.2.1> 如果 p 的父节点为空，则说明 p 是根节点，直接 root 设置为替换节点
+        if (p.parent == null)
+            root = replacement;
+        // <3.2.2> 如果 p 是父节点的左子节点，则 p 的父子节的左子节指向替换节点
+        else if (p == p.parent.left)
+            p.parent.left  = replacement;
+        // <3.2.3> 如果 p 是父节点的右子节点，则 p 的父子节的右子节指向替换节点
+        else
+            p.parent.right = replacement;
+
+        // Null out links so they are OK to use by fixAfterDeletion.
+        // <3.3> 置空 p 的所有指向
+        p.left = p.right = p.parent = null;
+
+        // Fix replacement
+        // <3.4> 如果 p 的颜色是黑色，则执行自平衡
+        if (p.color == BLACK)
+            fixAfterDeletion(replacement);
+    // <4> 如果 p 没有父节点，说明删除的是根节点，直接置空 root 即可
+    } else if (p.parent == null) { // return if we are the only node.
+        root = null;
+    // <5> 如果删除的没有左子树，又没有右子树
+    } else { //  No children. Use self as phantom replacement and unlink.
+        // <5.1> 如果 p 的颜色是黑色，则执行自平衡
+        if (p.color == BLACK)
+            fixAfterDeletion(p);
+
+        // <5.2> 删除 p 和其父节点的相互指向
+        if (p.parent != null) {
+            // 如果 p 是父节点的左子节点，则置空父节点的左子节点
+            if (p == p.parent.left)
+                p.parent.left = null;
+            // 如果 p 是父节点的右子节点，则置空父节点的右子节点
+            else if (p == p.parent.right)
+                p.parent.right = null;
+            // 置空 p 对父节点的指向
+            p.parent = null;
+        }
+    }
+}
+```
+
+- ```
+  <1>
+  ```
+
+   
+
+  处，如果删除的节点
+
+   
+
+  ```
+  p
+  ```
+
+   
+
+  既有左子节点，又有右子节点，则符合我们提到的情况四。在这里，我们需要将其转换成情况三。
+
+  - `<1.1>` 处，调用 `#successor(Entry<K,V> t)` 方法，获得右子树的最小值。这里，我们先不深究 `#successor(Entry<K,V> t)` 方法的具体代码，知道在这里的用途即可。
+  - `<1.2>` 处，修改 `p` 的 key-value 为 `s` 的 key-value 键值对。这样，我们就完成 `s` 对 `p` 的替换。
+  - `<1.3>` 处，设置 `p` 指向 `s` 。此时，就变成删除 `s` 节点了。此时，情况四就转换成了情况三了。
+
+- `<2>` 处，获得替换节点。此时对于 `p` 来说，至多有一个子节点，要么左子节点，要么右子节点，要么没有子节点。
+
+- ```
+  <3>
+  ```
+
+   
+
+  处，有左子节点，或者右子节点的情况：
+
+  - `<3.1>` 处，替换节点的父节点，指向 `p` 的父节点。
+  - `<3.2.1>` + `<3.2.2>` + `<3.2.3>` 处，将 `p` 的父节点的子节点，指向替换节点。
+  - `<3.3>` 处， 置空 `p` 的所有指向。
+  - `<3.4>` 处，如果 p 的颜色是黑色，则调用 `#fixAfterDeletion(Entry<K,V> x)` 方法，执行自平衡。
+
+- `<4>` 处，如果 `p` 没有父节点，说明删除的是根节点，直接置空 `root` 即可。
+
+- ```
+  <5>
+  ```
+
+   
+
+  处，既没有左子树，又没有右子树的情况：
+
+  - `<5.1>` 处，如果 p 的颜色是黑色，则调用 `#fixAfterDeletion(Entry<K,V> x)` 方法，执行自平衡。
+  - `<5.2>` 处，删除 `p` 和其父节点的相互指向。
+
+这样一看，其实删除节点的逻辑，也并不是怎么复杂噢。感兴趣的胖友，可以去 LeetCode 找树的题目刷一刷，哈哈。
+
+在前面，我们漏了一个 `#successor(Entry<K,V> t)` 静态方法，没有详细来看。获得 `t` 节点的后继节点，代码如下：
+
+```
+// TreeMap.java
+
+static <K,V> TreeMap.Entry<K,V> successor(Entry<K,V> t) {
+    // <1> 如果 t 为空，则返回 null
+    if (t == null)
+        return null;
+    // <2> 如果 t 的右子树非空，则取右子树的最小值
+    else if (t.right != null) {
+        // 先取右子树的根节点
+        Entry<K,V> p = t.right;
+        // 再取该根节点的做子树的最小值，即不断遍历左节点
+        while (p.left != null)
+            p = p.left;
+        // 返回
+        return p;
+    // <3> 如果 t 的右子树为空
+    } else {
+        // 先获得 t 的父节点
+        Entry<K,V> p = t.parent;
+        // 不断向上遍历父节点，直到子节点 ch 不是父节点 p 的右子节点
+        Entry<K,V> ch = t;
+        while (p != null // 还有父节点
+                && ch == p.right) { // 继续遍历的条件，必须是子节点 ch 是父节点 p 的右子节点
+            ch = p;
+            p = p.parent;
+        }
+        return p;
+    }
+}
+```
+
+- 对于树来说，会存在前序遍历，中序遍历，后续遍历。对于二叉查找树来说，中序遍历恰好满足 key **顺序递增**。所以，这个方法是基于中序遍历的方式，寻找传入 `t` 节点的后续节点，也是下一个比 `t` 大的节点。
+
+- `<1>` 处，如果 `t` 为空，则返回 `null` 。
+
+- `<2>` 处，如果 `t` 有右子树，则右子树的最小值，肯定是它的后继节点。胖友可以自己看下艿艿在代码里写的注释。在 `#deleteEntry(Entry<K,V> p)` 方法的 `<1.1>` 处，就走了这块代码分支逻辑。
+
+- ```
+  <3>
+  ```
+
+   
+
+  处，如果
+
+   
+
+  ```
+  t
+  ```
+
+   
+
+  没有右子树，则需要向上遍历父节点。胖友可以自己看下艿艿在代码里写的注释，结合
+
+   
+
+  图
+
+   
+
+  来理解。
+
+  - 简单来说，**寻找第一个祖先节点 `p` 是其父节点的左子节点**。因为是中序遍历，该节点的左子树肯定已经遍历完，在没有右子节点的情况下，需要找到其所在的“大子树”，成为左子树的情况。
+  - 例如说，节点 14 来说，需要按照 `14 -> 13 -> 15` 的路径，从而找到节点 15 是其后继节点。
+
+# 8. 查找接近的元素
+
+在 NavigableMap 中，定义了四个查找接近的元素：
+
+- `#lowerEntry(K key)` 方法，小于 `key` 的节点
+- `#floorEntry(K key)` 方法，小于等于 `key` 的节点
+- `#higherEntry(K key)` 方法，大于 `key` 的节点
+- `#ceilingEntry(K key)` 方法，大于等于 `key` 的节点
+
+我们逐个来看看哈。
+
+`#ceilingEntry(K key)` 方法，大于等于 `key` 的节点。代码如下：
+
+```
+// TreeMap.java
+
+public Map.Entry<K,V> ceilingEntry(K key) {
+    // <1>
+    // <2>
+    return exportEntry(getCeilingEntry(key));
+}
+
+static <K,V> Map.Entry<K,V> exportEntry(TreeMap.Entry<K,V> e) {
+    return (e == null) ? null :
+        new AbstractMap.SimpleImmutableEntry<>(e);
+}
+
+final Entry<K,V> getCeilingEntry(K key) {
+    Entry<K,V> p = root;
+    // <3> 循环二叉查找遍历红黑树
+    while (p != null) {
+        // <3.1> 比较 key
+        int cmp = compare(key, p.key);
+        // <3.2> 当前节点比 key 大，则遍历左子树，这样缩小节点的值
+        if (cmp < 0) {
+            // <3.2.1> 如果有左子树，则遍历左子树
+            if (p.left != null)
+                p = p.left;
+            // <3.2.2.> 如果没有，则直接返回该节点
+            else
+                return p;
+        // <3.3> 当前节点比 key 小，则遍历右子树，这样放大节点的值
+        } else if (cmp > 0) {
+            // <3.3.1> 如果有右子树，则遍历右子树
+            if (p.right != null) {
+                p = p.right;
+            } else {
+                // <3.3.2> 找到当前的后继节点
+                Entry<K,V> parent = p.parent;
+                Entry<K,V> ch = p;
+                while (parent != null && ch == parent.right) {
+                    ch = parent;
+                    parent = parent.parent;
+                }
+                return parent;
+            }
+        // <3.4> 如果相等，则返回该节点即可
+        } else
+            return p;
+    }
+    // <3.5> 
+    return null;
+}
+```
+
+- `<1>` 处，调用 `#getCeilingEntry(K key)` 方法，查找满足大于等于 `key` 的 Entry 节点。
+
+- `<2>` 处，调用 `#exportEntry(TreeMap.Entry<K,V> e)` 方法，创建不可变的 SimpleImmutableEntry 节点。这样，避免使用者直接修改节点，例如说修改 `key` 导致破坏红黑树。
+
+- 本质上，`#getCeilingEntry(K key)` 方法，是加强版的二叉树查找，在找不到 `key` 的情况下，找到比 `key` **大且最接近**的节点。
+
+- `<3>` 处，循环二叉查找遍历红黑树，每一轮都会在 `<3.1>` 处，通过调用 `#compare(Object k1, Object k2)` 方法，比较当前节点的 key 与 `key` 的大小。
+
+- `<3.4>` 处，当前节点和 `key` 相等，则返回该节点。此时，我们找到了和 `key` **相等**的节点。
+
+- ```
+  <3.2>
+  ```
+
+   
+
+  处，当前节点比
+
+   
+
+  ```
+  key
+  ```
+
+   
+
+  大，则遍历左子树，这样缩小节点的值。
+
+  - `<3.2.1>` 处，如果有左子树，则遍历左子树。
+  - `<3.2.2>` 处，如果没有，则直接返回该节点。此时，我们找到的是比 `key` **大且最接近**的节点。
+
+- ```
+  <3.3>
+  ```
+
+   
+
+  处，当前节点比
+
+   
+
+  ```
+  key
+  ```
+
+   
+
+  小，则遍历右子树，这样放大节点的值。
+
+  - `<3.3.1>` 处，如果有右子树，则遍历右子树。
+  - `<3.3.2>` 处，找到当前的后继节点。这小块的代码，和我们在 [「7. 删除单个元素」](https://svip.iocoder.cn/JDK/Collection-TreeMap/#) 的 `#successor(Entry<K,V> t)」` 方法的 `<3>` 处的代码是一致的。
+
+- `<3.5>` 处，极端情况下，找不到，返回 `null` 。
+
+对于 `<3.3.2>` 的逻辑，可能胖友理解起来会有一点懵逼。我们来看一个示例。如下图：[![查找二叉树](08-JDK 源码解析-集合（六）TreeMap.assets/03.png)](http://static.iocoder.cn/images/JDK/2019_12_13_02/03.png)查找二叉树
+
+- 假设查找节点 60 时，遍历路径为 `20 -> 30 -> 40 -> 50` ，此时没有右子树，查找后继节点为不存在，返回 `null`。
+
+- 假设查找节点 19 时，遍历路径为 `20 -> 10 -> 15 -> 18` ，此时没有右子树，查找后继节点为节点 20 ，返回节点 20 。
+
+  > 艿艿：有点不造怎么特别理论的描述，为什么这样 `<3.3.2>` 的逻辑是成立的。
+  >
+  > 从直观感受上来说，对于没有右子树的节点，其后继节点一定大于它。
+  >
+  > 并且，以节点 10 举例子。在我们因为 `key` 比节点 20 小时，遍历其左子树 `leftTree` 。在找不到匹配的节点时，此时 `leftTree` 的根节点 20 ，肯定是满足比 `key` **大且最接近**的节点。恰好，根节点 20 就是节点 18 的后继节点。
+  >
+  > 等后面我在想想怎么能够描述的更清楚。如果胖友有更好的解释，可以星球给艿艿留言。
+  >
+  > 目前的话，可以多画图理解。
+
+`#higherEntry(K key)` 方法，大于 `key` 的节点。代码如下：
+
+```
+// TreeMap.java
+
+public Map.Entry<K,V> higherEntry(K key) {
+    return exportEntry(getHigherEntry(key));
+}
+
+final Entry<K,V> getHigherEntry(K key) {
+    Entry<K,V> p = root;
+    // 循环二叉查找遍历红黑树
+    while (p != null) {
+        // 比较 key
+        int cmp = compare(key, p.key);
+        // 当前节点比 key 大，则遍历左子树，这样缩小节点的值
+        if (cmp < 0) {
+            // 如果有左子树，则遍历左子树
+            if (p.left != null)
+                p = p.left;
+            // 如果没有，则直接返回该节点
+            else
+                return p;
+        // 当前节点比 key 小，则遍历右子树，这样放大节点的值
+        } else {
+            // 如果有右子树，则遍历右子树
+            if (p.right != null) {
+                p = p.right;
+            } else {
+                // 找到当前的后继节点
+                Entry<K,V> parent = p.parent;
+                Entry<K,V> ch = p;
+                while (parent != null && ch == parent.right) {
+                    ch = parent;
+                    parent = parent.parent;
+                }
+                return parent;
+            }
+        }
+        // <X> 此处，相等的情况下，不返回
+    }
+    // 查找不到，返回 null
+    return null;
+}
+```
+
+- 和 `#ceilingEntry(K key)` 逻辑的差异，在于 `<X>` 处，相等的情况下，不返回该节点。
+
+`#ceilingEntry(K key)` 方法，小于等于 `key` 的节点。代码如下：
+
+```
+// TreeMap.java
+
+public Map.Entry<K,V> floorEntry(K key) {
+    return exportEntry(getFloorEntry(key));
+}
+
+final Entry<K,V> getFloorEntry(K key) {
+    Entry<K,V> p = root;
+    // 循环二叉查找遍历红黑树
+    while (p != null) {
+        // 比较 key
+        int cmp = compare(key, p.key);
+        if (cmp > 0) {
+            // 如果有右子树，则遍历右子树
+            if (p.right != null)
+                p = p.right;
+            // 如果没有，则直接返回该节点
+            else
+                return p;
+        // 当前节点比 key 小，则遍历右子树，这样放大节点的值
+        } else if (cmp < 0) {
+            // 如果有左子树，则遍历左子树
+            if (p.left != null) {
+                p = p.left;
+            } else {
+                // 找到当前节点的前继节点
+                Entry<K,V> parent = p.parent;
+                Entry<K,V> ch = p;
+                while (parent != null && ch == parent.left) {
+                    ch = parent;
+                    parent = parent.parent;
+                }
+                return parent;
+            }
+        // 如果相等，则返回该节点即可
+        } else
+            return p;
+
+    }
+    // 查找不到，返回 null
+    return null;
+}
+```
+
+- 思路是一致的，胖友自己看下注释噢。
+
+`#getLowerEntry(K key)` 方法，小于 `key` 的节点。代码如下：
+
+```
+// TreeMap.java
+
+public Map.Entry<K,V> lowerEntry(K key) {
+    return exportEntry(getLowerEntry(key));
+}
+
+final Entry<K,V> getLowerEntry(K key) {
+    Entry<K,V> p = root;
+    // 循环二叉查找遍历红黑树
+    while (p != null) {
+        // 比较 key
+        int cmp = compare(key, p.key);
+        // 当前节点比 key 小，则遍历右子树，这样放大节点的值
+        if (cmp > 0) {
+            // 如果有右子树，则遍历右子树
+            if (p.right != null)
+                p = p.right;
+            // 如果没有，则直接返回该节点
+            else
+                return p;
+        // 当前节点比 key 大，则遍历左子树，这样缩小节点的值
+        } else {
+            // 如果有左子树，则遍历左子树
+            if (p.left != null) {
+                p = p.left;
+            } else {
+                // 找到当前节点的前继节点
+                Entry<K,V> parent = p.parent;
+                Entry<K,V> ch = p;
+                while (parent != null && ch == parent.left) {
+                    ch = parent;
+                    parent = parent.parent;
+                }
+                return parent;
+            }
+        }
+        // 此处，相等的情况下，不返回
+    }
+    // 查找不到，返回 null
+    return null;
+}
+```
+
+- 思路是一致的，胖友自己看下注释噢。
+
+在一些场景下，我们并不需要返回 Entry 节点，只需要返回符合条件的 key 即可。所以有了对应的如下四个方法：
+
+```
+// TreeMap.java
+
+public K lowerKey(K key) {
+    return keyOrNull(getLowerEntry(key));
+}
+
+public K floorKey(K key) {
+    return keyOrNull(getFloorEntry(key));
+}
+
+public K ceilingKey(K key) {
+    return keyOrNull(getCeilingEntry(key));
+}
+
+public K higherKey(K key) {
+    return keyOrNull(getHigherEntry(key));
+}
+
+static <K,V> K keyOrNull(TreeMap.Entry<K,V> e) {
+    return (e == null) ? null : e.key;
+}
+```
+
+# 9. 获得首尾的元素
+
+`#firstEntry()` 方法，获得首个 Entry 节点。代码如下：
+
+```
+// TreeMap.java
+
+public Map.Entry<K,V> firstEntry() {
+    return exportEntry(getFirstEntry());
+}
+
+final Entry<K,V> getFirstEntry() {
+    Entry<K,V> p = root;
+    if (p != null)
+        // 循环，不断遍历到左子节点，直到没有左子节点
+        while (p.left != null)
+            p = p.left;
+    return p;
+}
+```
+
+- 通过不断遍历到左子节点，直到没有左子节点。
+
+- 在 `#getFirstEntry()` 方法的基础上，还提供了另外两个方法：
+
+  ```
+  // TreeMap.java
+  
+  public Map.Entry<K,V> pollFirstEntry() { // 获得并移除首个 Entry 节点
+      // 获得首个 Entry 节点
+      Entry<K,V> p = getFirstEntry();
+      Map.Entry<K,V> result = exportEntry(p);
+      // 如果存在，则进行删除。
+      if (p != null)
+          deleteEntry(p);
+      return result;
+  }
+  
+  public K firstKey() {
+      return key(getFirstEntry());
+  }
+  static <K> K key(Entry<K,?> e) {
+      if (e == null) // 如果不存在 e 元素，则抛出 NoSuchElementException 异常
+          throw new NoSuchElementException();
+      return e.key;
+  }
+  ```
+
+`#lastEntry()` 方法，获得尾部 Entry 节点。代码如下：
+
+```
+// TreeMap.java
+
+public Map.Entry<K,V> lastEntry() {
+    return exportEntry(getLastEntry());
+}
+
+final Entry<K,V> getLastEntry() {
+    Entry<K,V> p = root;
+    if (p != null)
+        // 循环，不断遍历到右子节点，直到没有右子节点
+        while (p.right != null)
+            p = p.right;
+    return p;
+}
+```
+
+- 通过不断遍历到右子节点，直到没有右子节点。
+
+- 在 `#getLastEntry()` 方法的基础上，还提供了另外两个方法：
+
+  ```
+  // TreeMap.java
+  
+  public Map.Entry<K,V> pollLastEntry() { // 获得并移除尾部 Entry 节点
+      // 获得尾部 Entry 节点
+      Entry<K,V> p = getLastEntry();
+      Map.Entry<K,V> result = exportEntry(p);
+      // 如果存在，则进行删除。
+      if (p != null)
+          deleteEntry(p);
+      return result;
+  }
+  
+  public K lastKey() {
+      return key(getLastEntry());
+  }
+  ```
+
+在这里，补充一个 `#containsValue(Object value)` 方法，通过中序遍历的方式，遍历查找值为 `value` 的节点是否存在。代码如下：
+
+```
+// TreeMap.java
+
+public boolean containsValue(Object value) {
+    for (Entry<K,V> e = getFirstEntry(); // 获得首个 Entry 节点
+         e != null;  // 遍历到没有下一个节点
+         e = successor(e)) { // 通过中序遍历，获得下一个节点
+        if (valEquals(value, e.value)) // 判断值是否相等
+            return true;
+    }
+    return false;
+}
+
+static final boolean valEquals(Object o1, Object o2) {
+    return (o1==null ? o2==null : o1.equals(o2));
+}
+```
+
+# 10. 清空
+
+`#clear()` 方法，清空。代码如下：
+
+```
+// TreeMap.java
+
+public void clear() {
+    // 增加修改次数
+    modCount++;
+    // key-value 数量置为 0
+    size = 0;
+    // 设置根节点为 null
+    root = null;
+}
+```
+
+# 11. 克隆
+
+`#clone()` 方法，克隆 TreeMap 。代码如下：
+
+```
+// TreeMap.java
+
+public Object clone() {
+    // 克隆创建 TreeMap 对象
+    TreeMap<?,?> clone;
+    try {
+        clone = (TreeMap<?,?>) super.clone();
+    } catch (CloneNotSupportedException e) {
+        throw new InternalError(e);
+    }
+
+    // Put clone into "virgin" state (except for comparator)
+    // 重置 clone 对象的属性
+    clone.root = null;
+    clone.size = 0;
+    clone.modCount = 0;
+    clone.entrySet = null;
+    clone.navigableKeySet = null;
+    clone.descendingMap = null;
+
+    // Initialize clone with our mappings
+    // 使用自己，构造 clone 对象的红黑树
+    try {
+        clone.buildFromSorted(size, entrySet().iterator(), null, null);
+    } catch (java.io.IOException | ClassNotFoundException cannotHappen) {
+    }
+
+    return clone;
+}
+```
+
+# 12. 序列化
+
+`#writeObject(ObjectOutputStream s)` 方法，序列化 TreeMap 对象。代码如下：
+
+```
+// TreeMap.java
+
+@java.io.Serial
+private void writeObject(java.io.ObjectOutputStream s)
+    throws java.io.IOException {
+    // Write out the Comparator and any hidden stuff
+    // 写入非静态属性、非 transient 属性
+    s.defaultWriteObject();
+
+    // Write out size (number of Mappings)
+    // 写入 key-value 键值对数量
+    s.writeInt(size);
+
+    // Write out keys and values (alternating)
+    // 写入具体的 key-value 键值对
+    for (Map.Entry<K, V> e : entrySet()) {
+        s.writeObject(e.getKey());
+        s.writeObject(e.getValue());
+    }
+}
+```
+
+- 比较简单，胖友自己瞅瞅即可。
+
+# 13. 反序列化
+
+`#readObject(ObjectInputStream s)` 方法，反序列化成 TreeMap 对象。代码如下：
+
+```
+// TreeMap.java
+
+@java.io.Serial
+private void readObject(final java.io.ObjectInputStream s)
+    throws java.io.IOException, ClassNotFoundException {
+    // Read in the Comparator and any hidden stuff
+    // 读取非静态属性、非 transient 属性
+    s.defaultReadObject();
+
+    // Read in size
+    // 读取 key-value 键值对数量 size
+    int size = s.readInt();
+
+    // 使用输入流，构建红黑树。
+    // 因为序列化时，已经是顺序的，所以输入流也是顺序的
+    buildFromSorted(size, null, s, null); // 注意，此时传入的是 s 参数，输入流
+}
+```
+
+# 14. 获得迭代器
+
+> 艿艿：本小节，可以选择性看，或者不看。
+
+`#keyIterator()` 方法，获得 key 的**正序**迭代器。代码如下：
+
+```
+// TreeMap.java
+
+Iterator<K> keyIterator() {
+    return new KeyIterator(getFirstEntry()); // 获得的是首个元素
+}
+```
+
+- 创建的是 KeyIterator 迭代器。在 [「14.2 KeyIterator」](https://svip.iocoder.cn/JDK/Collection-TreeMap/#) 详细解析。
+
+`#descendingKeyIterator()` 方法，获得 key 的**倒序**迭代器。代码如下：
+
+```
+// TreeMap.java
+
+Iterator<K> descendingKeyIterator() {
+    return new DescendingKeyIterator(getLastEntry()); // 获得的是尾部元素
+}
+```
+
+- 创建的是 DescendingKeyIterator 迭代器。在 [「14.3 DescendingKeyIterator」](https://svip.iocoder.cn/JDK/Collection-TreeMap/#) 详细解析。
+
+不过上述两个方法，都不是 `public` 方法，只提供给 TreeMap 内部使用。
+
+## 14.1 PrivateEntryIterator
+
+PrivateEntryIterator ，实现 Iterator 接口，提供了 TreeMap 的通用实现 Iterator 的抽象类。代码如下：
+
+```
+// TreeMap.java
+
+abstract class PrivateEntryIterator<T> implements Iterator<T> {
+
+    /**
+     * 下一个节点
+     */
+    Entry<K,V> next;
+    /**
+     * 最后返回的节点
+     */
+    Entry<K,V> lastReturned;
+    /**
+     * 当前的修改次数
+     */
+    int expectedModCount;
+
+    PrivateEntryIterator(Entry<K,V> first) {
+        expectedModCount = modCount;
+        lastReturned = null;
+        next = first;
+    }
+
+    public final boolean hasNext() {
+        return next != null;
+    }
+
+    final Entry<K,V> nextEntry() { // 获得下一个 Entry 节点
+        // 记录当前节点
+        Entry<K,V> e = next;
+        // 如果没有下一个，抛出 NoSuchElementException 异常
+        if (e == null)
+            throw new NoSuchElementException();
+        // 如果发生了修改，抛出 ConcurrentModificationException 异常
+        if (modCount != expectedModCount)
+            throw new ConcurrentModificationException();
+        // 获得 e 的后继节点，赋值给 next
+        next = successor(e);
+        // 记录最后返回的节点
+        lastReturned = e;
+        // 返回当前节点
+        return e;
+    }
+
+    final Entry<K,V> prevEntry() { // 获得前一个 Entry 节点
+        // 记录当前节点
+        Entry<K,V> e = next;
+        // 如果没有下一个，抛出 NoSuchElementException 异常
+        if (e == null)
+            throw new NoSuchElementException();
+        // 如果发生了修改，抛出 ConcurrentModificationException 异常
+        if (modCount != expectedModCount)
+            throw new ConcurrentModificationException();
+        // 获得 e 的前继节点，赋值给 next
+        next = predecessor(e);
+        // 记录最后返回的节点
+        lastReturned = e;
+        // 返回当前节点
+        return e;
+    }
+
+    public void remove() { // 删除节点
+        // 如果当前返回的节点不存在，则抛出 IllegalStateException 异常
+        if (lastReturned == null)
+            throw new IllegalStateException();
+        // 如果发生了修改，抛出 ConcurrentModificationException 异常
+        if (modCount != expectedModCount)
+            throw new ConcurrentModificationException();
+        // deleted entries are replaced by their successors
+        // 在 lastReturned 左右节点都存在的时候，实际在 deleteEntry 方法中，是将后继节点替换到 lastReturned 中
+        // 因此，next 需要指向 lastReturned
+        if (lastReturned.left != null && lastReturned.right != null)
+            next = lastReturned;
+        // 删除节点
+        deleteEntry(lastReturned);
+        // 记录新的修改次数
+        expectedModCount = modCount;
+        // 置空 lastReturned
+        lastReturned = null;
+    }
+
+}
+```
+
+- 整体代码比较简单，胖友自己看看艿艿写的注释噢。
+
+在上述代码中，我们会看到 `#predecessor(Entry<K,V> t)` 静态方法，我们来看看。获得 `t` 节点的前继节点，代码如下：
+
+```
+// TreeMap.java
+
+static <K,V> Entry<K,V> predecessor(Entry<K,V> t) {
+    // 如果 t 为空，则返回 null
+    if (t == null)
+        return null;
+    // 如果 t 的左子树非空，则取左子树的最大值
+    else if (t.left != null) {
+        Entry<K,V> p = t.left;
+        while (p.right != null)
+            p = p.right;
+        return p;
+    // 如果 t 的左子树为空
+    } else {
+        // 先获得 t 的父节点
+        Entry<K,V> p = t.parent;
+        // 不断向上遍历父节点，直到子节点 ch 不是父节点 p 的左子节点
+        Entry<K,V> ch = t;
+        while (p != null // 还有父节点
+                && ch == p.left) { // 继续遍历的条件，必须是子节点 ch 是父节点 p 的左子节点
+            ch = p;
+            p = p.parent;
+        }
+        return p;
+    }
+}
+```
+
+- 和 `#successor(Entry<K,V> t)` 方法，是一样的思路。所以，胖友跟着注释，自己再理解下。
+
+## 14.2 KeyIterator
+
+KeyIterator ，继承 PrivateEntryIterator 抽象类，key 的**正序**迭代器。代码如下：
+
+```
+// TreeMap.java
+
+final class KeyIterator extends PrivateEntryIterator<K> {
+
+    KeyIterator(Entry<K,V> first) {
+        super(first);
+    }
+
+    // 实现 next 方法，实现正序
+    public K next() {
+        return nextEntry().key;
+    }
+
+}
+```
+
+## 14.3 DescendingKeyIterator
+
+DescendingKeyIterator ，继承 PrivateEntryIterator 抽象类，key 的**倒序**迭代器。代码如下：
+
+```
+// TreeMap.java
+
+final class DescendingKeyIterator extends PrivateEntryIterator<K> {
+
+    DescendingKeyIterator(Entry<K,V> first) {
+        super(first);
+    }
+
+    // 实现 next 方法，实现倒序
+    public K next() {
+        return prevEntry().key;
+    }
+
+    // 重写 remove 方法，因为在 deleteEntry 方法中，在 lastReturned 左右节点都存在的时候，是将后继节点替换到 lastReturned 中。
+    // 而这个逻辑，对于倒序遍历，没有影响。
+    public void remove() {
+        // 如果当前返回的节点不存在，则抛出 IllegalStateException 异常
+        if (lastReturned == null)
+            throw new IllegalStateException();
+        // 如果发生了修改，抛出 ConcurrentModificationException 异常
+        if (modCount != expectedModCount)
+            throw new ConcurrentModificationException();
+        // 删除节点
+        deleteEntry(lastReturned);
+        // 置空 lastReturned
+        lastReturned = null;
+        // 记录新的修改次数
+        expectedModCount = modCount;
+    }
+
+}
+```
+
+## 14.4 EntryIterator
+
+EntryIterator ，继承 PrivateEntryIterator 抽象类，Entry 的**正序**迭代器。代码如下：
+
+```
+// TreeMap.java
+
+final class EntryIterator extends PrivateEntryIterator<Map.Entry<K,V>> {
+
+    EntryIterator(Entry<K,V> first) {
+        super(first);
+    }
+
+    // 实现 next 方法，实现正序
+    public Map.Entry<K,V> next() {
+        return nextEntry();
+    }
+
+}
+```
+
+## 14.5 ValueIterator
+
+ValueIterator ，继承 PrivateEntryIterator 抽象类，value 的**正序**迭代器。代码如下：
+
+```
+// TreeMap.java
+
+final class ValueIterator extends PrivateEntryIterator<V> {
+
+    ValueIterator(Entry<K,V> first) {
+        super(first);
+    }
+
+    // 实现 next 方法，实现正序
+    public V next() {
+        return nextEntry().value;
+    }
+
+}
+```
+
+# 15. 转换成 Set/Collection
+
+> 艿艿：本小节，可以选择性看，或者不看。
+
+## 15.1 keySet
+
+`#keySet()` 方法，获得**正序**的 key Set 。代码如下：
+
+```
+// TreeMap.java
+
+/**
+ * 正序的 KeySet 缓存对象
+ */
+private transient KeySet<K> navigableKeySet;
+
+public Set<K> keySet() {
+    return navigableKeySet();
+}
+
+public NavigableSet<K> navigableKeySet() {
+    KeySet<K> nks = navigableKeySet;
+    return (nks != null) ? nks : (navigableKeySet = new KeySet<>(this));
+}
+```
+
+- 创建的 KeySet 类。它实现 NavigableSet 接口，继承了 [`java.util.AbstractSet`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/util/AbstractSet.java) 抽像类，是 TreeMap 的内部类。比较简单，就不哔哔了。
+- KeySet 使用的迭代器，就是 [「14.2 KeyIterator」](https://svip.iocoder.cn/JDK/Collection-TreeMap/#) 。
+
+## 15.2 descendingKeySet
+
+`#descendingKeySet()` 方法，获得**倒序**的 key Set 。代码如下：
+
+```
+// TreeMap.java
+
+/**
+ * 倒序的 NavigableMap 缓存对象
+ */
+private transient NavigableMap<K,V> descendingMap;
+
+public NavigableSet<K> descendingKeySet() {
+    return descendingMap().navigableKeySet();
+}
+
+public NavigableMap<K, V> descendingMap() {
+    NavigableMap<K, V> km = descendingMap;
+    return (km != null) ? km :
+        (descendingMap = new DescendingSubMap<>(this,
+                                                true, null, true,
+                                                true, null, true));
+}
+```
+
+- 首先，调用 `#descendingMap()` 方法，返回**倒序**访问当前 TreeMap 的 DescendingSubMap 对象。
+- 然后，调用 `#navigableKeySet()` 方法，返回 DescendingSubMap 对象的**正序**的 key Set 。
+- 关于 DescendingSubMap 类，我们在 TODO 来详细解析。
+
+## 15.3 values
+
+`#values()` 方法，获得 value 集合。代码如下：
+
+```
+// TreeMap.java
+
+public Collection<V> values() {
+    Collection<V> vs = values;
+    if (vs == null) {
+        vs = new Values();
+        values = vs; // values 缓存，来自 AbstractMap 的属性
+    }
+    return vs;
+}
+```
+
+- 创建的 Values 类。它继承了 [`java.util.AbstractCollection`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/util/AbstractCollection.java) 抽像类，是 TreeMap 的内部类。比较简单，就不哔哔了。
+- Values 使用的迭代器，就是 [「14.4 ValueIterator」](https://svip.iocoder.cn/JDK/Collection-TreeMap/#) 。
+
+## 15.4 entrySet
+
+`#entrySet()` 方法，获得 Entry 集合。代码如下：
+
+```
+// TreeMap.java
+
+/**
+ * Entry 缓存集合
+ */
+private transient EntrySet entrySet;
+
+public Set<Map.Entry<K,V>> entrySet() {
+    EntrySet es = entrySet;
+    return (es != null) ? es : (entrySet = new EntrySet());
+}
+```
+
+- 创建的 EntrySet 类。它继承了 [`java.util.AbstractSet`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/util/AbstractSet.java) 抽像类，是 TreeMap 的内部类。比较简单，就不哔哔了。
+- EntrySet 使用的迭代器，就是 [「14.3 EntryIterator」](https://svip.iocoder.cn/JDK/Collection-TreeMap/#) 。
+
+# 16. 查找范围的元素
+
+> 艿艿：本小节，可以选择性看，或者不看。
+>
+> 这部分，内容有点长。
+
+在 SortedMap 接口中，定义了按照 key 查找范围，返回子 SortedMap 结果的方法：
+
+- `#subMap(K fromKey, K toKey)`
+- `#headMap(K toKey)`
+- `#tailMap(K fromKey)`
+
+在 NavigableMap 中，定义了按照 key 查找范围，返回子 NavigableMap 结果的方法：
+
+- `#subMap(K fromKey, K toKey)`
+- `#subMap(K fromKey, boolean fromInclusive, K toKey, boolean toInclusive)`
+- `#headMap(K toKey)`
+- `#headMap(K toKey, boolean inclusive)`
+- `#tailMap(K fromKey)`
+- `#tailMap(K fromKey, boolean inclusive)`
+
+TreeMap 对上述接口，实现如下方法：
+
+```
+// TreeMap.java
+
+// subMap 组
+public SortedMap<K,V> subMap(K fromKey, K toKey) {
+    return subMap(fromKey, true, toKey, false);
+}
+public NavigableMap<K,V> subMap(K fromKey, boolean fromInclusive,
+                                K toKey,   boolean toInclusive) {
+    return new AscendingSubMap<>(this,
+                                 false, fromKey, fromInclusive,
+                                 false, toKey,   toInclusive);
+}
+
+// headMap 组
+public SortedMap<K,V> headMap(K toKey) {
+    return headMap(toKey, false);
+}
+public NavigableMap<K,V> headMap(K toKey, boolean inclusive) {
+    return new AscendingSubMap<>(this,
+                                 true,  null,  true,
+                                 false, toKey, inclusive);
+}
+
+// tailMap 组
+public SortedMap<K,V> tailMap(K fromKey) {
+    return tailMap(fromKey, true);
+}
+public NavigableMap<K,V> tailMap(K fromKey, boolean inclusive) {
+    return new AscendingSubMap<>(this,
+                                 false, fromKey, inclusive,
+                                 true,  null,    true);
+}
+```
+
+- 返回的都是 AscendingSubMap 对象。所以，我们在 [「XX. AscendingSubMap」](https://svip.iocoder.cn/JDK/Collection-TreeMap/#) 来看。
+
+## 16.1 NavigableSubMap
+
+NavigableSubMap ，实现 NavigableMap、Serializable 接口，继承 AbstractMap 抽象类，**子 NavigableMap 的抽象类**。
+
+后续，我们会看到 NavigableSubMap 的两个子类：
+
+- AscendingSubMap ，**正序**的 子 NavigableMap 的实现类。
+- DescendingSubMap ，**倒序**的 子 NavigableMap 的实现类。
+
+### 16.1.1 构造方法
+
+NavigableSubMap 仅有一个构造方法，代码如下：
+
+```
+// TreeMap.java#NavigableSubMap.java
+
+/**
+ * The backing map.
+ */
+final TreeMap<K,V> m;
+
+/**
+ * lo - 开始位置
+ * hi - 结束位置
+ */
+final K lo, hi;
+/**
+ * fromStart - 是否从 TreeMap 开头开始。如果是的话，{@link #lo} 可以不传
+ * toEnd - 是否从 TreeMap 结尾结束。如果是的话，{@link #hi} 可以不传
+ */
+final boolean fromStart, toEnd;
+/**
+ * loInclusive - 是否包含 key 为 {@link #lo}  的元素
+ * hiInclusive - 是否包含 key 为 {@link #hi} 的元素
+ */
+final boolean loInclusive, hiInclusive;
+
+NavigableSubMap(TreeMap<K,V> m,
+                boolean fromStart, K lo, boolean loInclusive,
+                boolean toEnd,     K hi, boolean hiInclusive) {
+    // 如果既不从开头开始，又不从结尾结束，那么就要校验 lo 小于 hi ，否则抛出 IllegalArgumentException 异常
+    if (!fromStart && !toEnd) {
+        if (m.compare(lo, hi) > 0)
+            throw new IllegalArgumentException("fromKey > toKey");
+    } else {
+        // 如果不从开头开始，则进行 lo 的类型校验
+        if (!fromStart) // type check
+            m.compare(lo, lo);
+        // 如果不从结尾结束，则进行 hi 的类型校验
+        if (!toEnd)
+            m.compare(hi, hi);
+    }
+
+    // 赋值属性
+    this.m = m;
+    this.fromStart = fromStart;
+    this.lo = lo;
+    this.loInclusive = loInclusive;
+    this.toEnd = toEnd;
+    this.hi = hi;
+    this.hiInclusive = hiInclusive;
+}
+```
+
+- 每个属性，胖友自己看代码上的注释。
+
+### 16.1.2 范围校验
+
+因为 NavigableSubMap 是 TreeMap 的**子** NavigableMap ，所以其所有的操作，不能超过其**子范围**，既我们在创建 NavigableSubMap 时，锁设置的开始和结束的 key 位置。
+
+`#inRange(Object key)` 方法，校验传入的 `key` 是否在子范围中。代码如下：
+
+```
+// TreeMap.java#NavigableSubMap.java
+
+final boolean inRange(Object key) {
+    return !tooLow(key) 
+            && !tooHigh(key);
+}
+```
+
+- 调用 `#tooLow(Object key)` 方法，判断 `key` 是否小于 NavigableSubMap 的开始位置的 key 。代码如下：
+
+  ```
+  // TreeMap.java#NavigableSubMap.java
+  
+  final boolean tooLow(Object key) {
+      if (!fromStart) {
+          // 比较 key
+          int c = m.compare(key, lo);
+          if (c < 0 // 如果小于，则肯定过小
+                  || (c == 0 && !loInclusive)) // 如果相等，则进一步判断是否 !loInclusive ，不包含 lo 的情况
+              return true;
+      }
+      return false;
+  }
+  ```
+
+- 调用 `#tooHigh(Object key)` 方法，判断 `key` 是否大于 NavigableSubMap 的结束位置的 key 。代码如下：
+
+  ```
+  // TreeMap.java#NavigableSubMap.java
+  
+  final boolean tooHigh(Object key) {
+      if (!toEnd) {
+          // 比较 key
+          int c = m.compare(key, hi);
+          if (c > 0 // 如果大于，则肯定过大
+                  || (c == 0 && !hiInclusive)) // 如果相等，则进一步判断是否 !hiInclusive ，不包含 high 的情况
+              return true;
+      }
+      return false;
+  }
+  ```
+
+- 通过这样两个判断，不过大，且不过小，那么就在范围之内了。
+
+`#inClosedRange(Object key)` 方法，判断是否在闭合的范围内。代码如下：
+
+```
+// TreeMap.java#NavigableSubMap.java
+
+final boolean inClosedRange(Object key) {
+    return (fromStart || m.compare(key, lo) >= 0)
+        && (toEnd || m.compare(hi, key) >= 0);
+}
+```
+
+- 也就是说，不包含包含边界的情况。
+
+`#inRange(Object key, boolean inclusive)` 方法，根据传入的 `inclusive` 参数，调用上述的两种范围判断的方法。代码如下：
+
+```
+// TreeMap.java#NavigableSubMap.java
+
+final boolean inRange(Object key, boolean inclusive) {
+    return inclusive ? inRange(key) : inClosedRange(key);
+}
+```
+
+### 16.1.3 添加单个元素
+
+`#put(K key, V value)` 方法，添加单个元素。代码如下：
+
+```
+// TreeMap.java#NavigableSubMap.java
+
+public final V put(K key, V value) {
+    // 校验 key 的范围，如果不在，则抛出 IllegalArgumentException 异常
+    if (!inRange(key))
+        throw new IllegalArgumentException("key out of range");
+    // 执行添加单个元素
+    return m.put(key, value);
+}
+```
+
+### 16.1.4 获得单个元素
+
+`#get(Object key)` 方法，获得 `key` 对应的 value 值。代码如下：
+
+```
+// TreeMap.java#NavigableSubMap.java
+
+public final V get(Object key) {
+    return !inRange(key) // 校验 key 的范围
+            ? null : // 如果不在，则返回 null
+            m.get(key); // 执行获得单个元素
+}
+```
+
+`#containsKey(Object key)` 方法，判断是否存在指定 key 。代码如下：
+
+```
+// TreeMap.java
+
+public final boolean containsKey(Object key) {
+    return inRange(key)
+            && m.containsKey(key);
+}
+```
+
+- 基于 `#getEntry(key)` 方法来实现。
+
+### 16.1.5 删除单个元素
+
+`#remove(Object key)` 方法，移除 `key` 对应的 Entry 节点。代码如下：
+
+```
+// TreeMap.java#NavigableSubMap.java
+
+public final V remove(Object key) {
+    return !inRange(key) // 校验 key 的范围
+            ? null : // 如果不在，则返回 null
+            m.remove(key); // 执行移除单个元素
+}
+```
+
+### 16.1.6 查找接近的元素
+
+```
+// TreeMap.java#NavigableSubMap.java
+
+public final Map.Entry<K,V> ceilingEntry(K key) {
+    return exportEntry(subCeiling(key));
+}
+public final K ceilingKey(K key) {
+    return keyOrNull(subCeiling(key));
+}
+
+public final Map.Entry<K,V> higherEntry(K key) {
+    return exportEntry(subHigher(key));
+}
+public final K higherKey(K key) {
+    return keyOrNull(subHigher(key));
+}
+
+public final Map.Entry<K,V> floorEntry(K key) {
+    return exportEntry(subFloor(key));
+}
+public final K floorKey(K key) {
+    return keyOrNull(subFloor(key));
+}
+
+public final Map.Entry<K,V> lowerEntry(K key) {
+    return exportEntry(subLower(key));
+}
+public final K lowerKey(K key) {
+    return keyOrNull(subLower(key));
+}
+```
+
+因为子类的**排序规则不同**，所以 NavigableSubMap 定义了如下抽象方法，交给子类实现。代码如下：
+
+```
+// TreeMap.java#NavigableSubMap.java
+
+abstract TreeMap.Entry<K,V> subLowest();
+abstract TreeMap.Entry<K,V> subHighest();
+abstract TreeMap.Entry<K,V> subCeiling(K key);
+abstract TreeMap.Entry<K,V> subHigher(K key);
+abstract TreeMap.Entry<K,V> subFloor(K key);
+abstract TreeMap.Entry<K,V> subLower(K key);
+```
+
+当然，NavigableSubMap 为了子类实现更方便，提供了如下方法：
+
+```
+// TreeMap.java#NavigableSubMap.java
+
+final TreeMap.Entry<K,V> absLowest() { // 获得 NavigableSubMap 开始位置的 Entry 节点
+    TreeMap.Entry<K,V> e =
+        (fromStart ?  m.getFirstEntry() : // 如果从 TreeMap 开始，则获得 TreeMap 的首个 Entry 节点
+         (loInclusive ? m.getCeilingEntry(lo) : // 如果 key 从 lo 开始（包含），则获得 TreeMap 从 lo 开始（>=）最接近的 Entry 节点
+                        m.getHigherEntry(lo))); // 如果 key 从 lo 开始（不包含），则获得 TreeMap 从 lo 开始(>)最接近的 Entry 节点
+    return (e == null || tooHigh(e.key)) /** 超过 key 过大 **/ ? null : e;
+}
+
+final TreeMap.Entry<K,V> absHighest() { // 获得 NavigableSubMap 结束位置的 Entry 节点
+    TreeMap.Entry<K,V> e =
+        (toEnd ?  m.getLastEntry() : // 如果从 TreeMap 开始，则获得 TreeMap 的尾部 Entry 节点
+         (hiInclusive ?  m.getFloorEntry(hi) : // 如果 key 从 hi 开始（包含），则获得 TreeMap 从 hi 开始（<=）最接近的 Entry 节点
+                         m.getLowerEntry(hi))); // 如果 key 从 lo 开始（不包含），则获得 TreeMap 从 lo 开始(<)最接近的 Entry 节点
+    return (e == null || tooLow(e.key)) /** 超过 key 过小 **/ ? null : e;
+}
+
+final TreeMap.Entry<K,V> absCeiling(K key) { // 获得 NavigableSubMap >= key 最接近的 Entry 节点
+    // 如果 key 过小，则只能通过 `#absLowest()` 方法，获得 NavigableSubMap 开始位置的 Entry 节点
+    if (tooLow(key))
+        return absLowest();
+    // 获得 NavigableSubMap >= key 最接近的 Entry 节点
+    TreeMap.Entry<K,V> e = m.getCeilingEntry(key);
+    return (e == null || tooHigh(e.key)) /** 超过 key 过大 **/ ? null : e;
+}
+
+final TreeMap.Entry<K,V> absHigher(K key) { // 获得 NavigableSubMap > key 最接近的 Entry 节点
+    // 如果 key 过小，则只能通过 `#absLowest()` 方法，获得 NavigableSubMap 开始位置的 Entry 节点
+    if (tooLow(key))
+        return absLowest();
+    // 获得 NavigableSubMap > key 最接近的 Entry 节点
+    TreeMap.Entry<K,V> e = m.getHigherEntry(key);
+    return (e == null || tooHigh(e.key)) /** 超过 key 过大 **/ ? null : e;
+}
+
+final TreeMap.Entry<K,V> absFloor(K key) { // 获得 NavigableSubMap <= key 最接近的 Entry 节点
+    // 如果 key 过大，则只能通过 `#absHighest()` 方法，获得 NavigableSubMap 结束位置的 Entry 节点
+    if (tooHigh(key))
+        return absHighest();
+    // 获得 NavigableSubMap <= key 最接近的 Entry 节点
+    TreeMap.Entry<K,V> e = m.getFloorEntry(key);
+    return (e == null || tooLow(e.key)) /** 超过 key 过小 **/ ? null : e;
+}
+
+final TreeMap.Entry<K,V> absLower(K key) { // 获得 NavigableSubMap < key 最接近的 Entry 节点
+    // 如果 key 过大，则只能通过 `#absHighest()` 方法，获得 NavigableSubMap 结束位置的 Entry 节点
+    if (tooHigh(key))
+        return absHighest();
+    // 获得 NavigableSubMap < key 最接近的 Entry 节点
+    TreeMap.Entry<K,V> e = m.getLowerEntry(key);
+    return (e == null || tooLow(e.key)) /** 超过 key 过小 **/ ? null : e;
+}
+
+/** Returns the absolute high fence for ascending traversal */
+final TreeMap.Entry<K,V> absHighFence() { // 获得 TreeMap 最大 key 的 Entry 节点，用于升序遍历的时候。注意，是 TreeMap 。
+    // toEnd 为真时，意味着无限大，所以返回 null
+    return (toEnd ? null : (hiInclusive ?
+                            m.getHigherEntry(hi) : // 获得 TreeMap > hi 最接近的 Entry 节点。
+                            m.getCeilingEntry(hi))); // 获得 TreeMap => hi 最接近的 Entry 节点。
+}
+
+/** Return the absolute low fence for descending traversal  */
+final TreeMap.Entry<K,V> absLowFence() { // 获得 TreeMap 最小 key 的 Entry 节点，用于降序遍历的时候。注意，是 TreeMap 。
+    return (fromStart ? null : (loInclusive ?
+                                m.getLowerEntry(lo) :  // 获得 TreeMap < lo 最接近的 Entry 节点。
+                                m.getFloorEntry(lo))); // 获得 TreeMap <= lo 最接近的 Entry 节点。
+}
+```
+
+- 方法有点点小多，不过基本是雷同的。耐心如我~
+
+### 16.1.7 获得首尾的元素
+
+`#firstEntry()` 方法，获得首个 Entry 节点。代码如下：
+
+```
+// TreeMap.java#NavigableSubMap.java
+
+public final Map.Entry<K,V> firstEntry() {
+    return exportEntry(subLowest());
+}
+
+public final K firstKey() {
+    return key(subLowest());
+}
+
+public final Map.Entry<K,V> pollFirstEntry() {
+    // 获得 NavigableSubMap 的首个 Entry 节点
+    TreeMap.Entry<K,V> e = subLowest();
+    Map.Entry<K,V> result = exportEntry(e);
+    // 如果存在，则进行删除。
+    if (e != null)
+        m.deleteEntry(e);
+    return result;
+}
+```
+
+`#lastEntry()` 方法，获得尾部 Entry 节点。代码如下：
+
+```
+// TreeMap.java#NavigableSubMap.java
+
+public final Map.Entry<K,V> lastEntry() {
+    return exportEntry(subHighest());
+}
+
+public final K lastKey() {
+    return key(subHighest());
+}
+
+public final Map.Entry<K,V> pollLastEntry() {
+    // 获得 NavigableSubMap 的尾部 Entry 节点
+    TreeMap.Entry<K,V> e = subHighest();
+    Map.Entry<K,V> result = exportEntry(e);
+    // 如果存在，则进行删除。
+    if (e != null)
+        m.deleteEntry(e);
+    return result;
+}
+```
+
+### 16.1.8 清空
+
+直接使用继承自 AbstractMap 的 `#clear()` 方法，仅清空自己范围内的数据。代码如下：
+
+```
+// AbstractMap.java
+
+public void clear() {
+    entrySet().clear();
+}
+```
+
+- 而 `#entrySet()` 方法，NavigableSubMap 的子类在实现时，会重写该方法。这样，能够保证仅清空自己范围内的数据。
+
+### 16.1.9 获得迭代器
+
+SubMapIterator ，实现 Iterator 接口，提供了 NavigableSubMap 的通用实现 Iterator 的抽象类。代码如下：
+
+```
+// TreeMap.java#NavigableSubMap.java
+
+abstract class SubMapIterator<T> implements Iterator<T> {
+
+    /**
+     * 最后返回的节点
+     */
+    TreeMap.Entry<K,V> lastReturned;
+    /**
+     * 下一个节点
+     */
+    TreeMap.Entry<K,V> next;
+    /**
+     * 遍历的上限 key 。
+     *
+     * 如果遍历到该 key ，说明已经超过范围了
+     */
+    final Object fenceKey;
+    /**
+     * 当前的修改次数
+     */
+    int expectedModCount;
+
+    SubMapIterator(TreeMap.Entry<K,V> first,
+                   TreeMap.Entry<K,V> fence) {
+        expectedModCount = m.modCount;
+        lastReturned = null;
+        next = first;
+        fenceKey = fence == null ? UNBOUNDED /** 无界限 **/ : fence.key;
+    }
+
+    public final boolean hasNext() { // 是否还有下一个节点
+        return next != null && next.key != fenceKey;
+    }
+
+    final TreeMap.Entry<K,V> nextEntry() { // 获得下一个 Entry 节点
+        // 记录当前节点
+        TreeMap.Entry<K,V> e = next;
+        // 如果没有下一个，抛出 NoSuchElementException 异常
+        if (e == null || e.key == fenceKey)
+            throw new NoSuchElementException();
+        // 如果发生了修改，抛出 ConcurrentModificationException 异常
+        if (m.modCount != expectedModCount)
+            throw new ConcurrentModificationException();
+        // 获得 e 的后继节点，赋值给 next
+        next = successor(e);
+        // 记录最后返回的节点
+        lastReturned = e;
+        // 返回当前节点
+        return e;
+    }
+
+    final TreeMap.Entry<K,V> prevEntry() { // 获得前一个 Entry 节点
+        // 记录当前节点
+        TreeMap.Entry<K,V> e = next;
+        // 如果没有下一个，抛出 NoSuchElementException 异常
+        if (e == null || e.key == fenceKey)
+            throw new NoSuchElementException();
+        // 如果发生了修改，抛出 ConcurrentModificationException 异常
+        if (m.modCount != expectedModCount)
+            throw new ConcurrentModificationException();
+        // 获得 e 的前继节点，赋值给 next
+        next = predecessor(e);
+        // 记录最后返回的节点
+        lastReturned = e;
+        // 返回当前节点
+        return e;
+    }
+
+    final void removeAscending() { // 删除节点（顺序遍历的情况下）
+        // 如果当前返回的节点不存在，则抛出 IllegalStateException 异常
+        if (lastReturned == null)
+            throw new IllegalStateException();
+        // 如果发生了修改，抛出 ConcurrentModificationException 异常
+        if (m.modCount != expectedModCount)
+            throw new ConcurrentModificationException();
+        // deleted entries are replaced by their successors
+        // 在 lastReturned 左右节点都存在的时候，实际在 deleteEntry 方法中，是将后继节点替换到 lastReturned 中
+        // 因此，next 需要指向 lastReturned
+        if (lastReturned.left != null && lastReturned.right != null)
+            next = lastReturned;
+        // 删除节点
+        m.deleteEntry(lastReturned);
+        // 置空 lastReturned
+        lastReturned = null;
+        // 记录新的修改次数
+        expectedModCount = m.modCount;
+    }
+
+    final void removeDescending() { // 删除节点倒序遍历的情况下）
+        // 如果当前返回的节点不存在，则抛出 IllegalStateException 异常
+        if (lastReturned == null)
+            throw new IllegalStateException();
+        // 如果发生了修改，抛出 ConcurrentModificationException 异常
+        if (m.modCount != expectedModCount)
+            throw new ConcurrentModificationException();
+        // 删除节点
+        m.deleteEntry(lastReturned);
+        // 置空 lastReturned
+        lastReturned = null;
+        // 记录新的修改次数
+        expectedModCount = m.modCount;
+    }
+
+}
+```
+
+- 整体代码比较简单，胖友自己看看艿艿写的注释噢。
+
+#### 16.1.9.1 SubMapKeyIterator
+
+SubMapKeyIterator ，继承 SubMapIterator 抽象类，key 的**正序**迭代器。代码如下：
+
+```
+// TreeMap.java#NavigableSubMap.java
+
+final class SubMapKeyIterator extends SubMapIterator<K>
+    implements Spliterator<K> {
+
+    SubMapKeyIterator(TreeMap.Entry<K,V> first,
+                      TreeMap.Entry<K,V> fence) {
+        super(first, fence);
+    }
+
+    // 实现 next 方法，实现正序
+    public K next() {
+        return nextEntry().key;
+    }
+
+    // 实现 remove 方法，实现正序的移除方法
+    public void remove() {
+        removeAscending();
+    }
+
+    public Spliterator<K> trySplit() {
+        return null;
+    }
+    public void forEachRemaining(Consumer<? super K> action) {
+        while (hasNext())
+            action.accept(next());
+    }
+    public boolean tryAdvance(Consumer<? super K> action) {
+        if (hasNext()) {
+            action.accept(next());
+            return true;
+        }
+        return false;
+    }
+    public long estimateSize() {
+        return Long.MAX_VALUE;
+    }
+    public int characteristics() {
+        return Spliterator.DISTINCT | Spliterator.ORDERED |
+            Spliterator.SORTED;
+    }
+    public final Comparator<? super K>  getComparator() {
+        return NavigableSubMap.this.comparator();
+    }
+}
+```
+
+#### 16.1.9.2 DescendingSubMapKeyIterator
+
+DescendingSubMapKeyIterator ，继承 SubMapIterator 抽象类，key 的**倒序**迭代器。代码如下：
+
+```
+// TreeMap.java#NavigableSubMap.java
+
+final class DescendingSubMapKeyIterator extends SubMapIterator<K>
+    implements Spliterator<K> {
+
+    DescendingSubMapKeyIterator(TreeMap.Entry<K,V> last,
+                                TreeMap.Entry<K,V> fence) {
+        super(last, fence);
+    }
+
+    // 实现 next 方法，实现倒序
+    public K next() {
+        return prevEntry().key;
+    }
+
+    // 实现 remove 方法，实现倒序的移除方法
+    public void remove() {
+        removeDescending();
+    }
+
+    public Spliterator<K> trySplit() {
+        return null;
+    }
+    public void forEachRemaining(Consumer<? super K> action) {
+        while (hasNext())
+            action.accept(next());
+    }
+    public boolean tryAdvance(Consumer<? super K> action) {
+        if (hasNext()) {
+            action.accept(next());
+            return true;
+        }
+        return false;
+    }
+    public long estimateSize() {
+        return Long.MAX_VALUE;
+    }
+    public int characteristics() {
+        return Spliterator.DISTINCT | Spliterator.ORDERED;
+    }
+}
+```
+
+#### 16.1.9.3 SubMapEntryIterator
+
+SubMapEntryIterator ，继承 SubMapIterator 抽象类，Entry 的**正序**迭代器。代码如下：
+
+```
+// TreeMap.java#NavigableSubMap.java
+
+final class SubMapEntryIterator extends SubMapIterator<Map.Entry<K,V>> {
+
+    SubMapEntryIterator(TreeMap.Entry<K,V> first,
+                        TreeMap.Entry<K,V> fence) {
+        super(first, fence);
+    }
+
+    // 实现 next 方法，实现正序
+    public Map.Entry<K,V> next() {
+        return nextEntry();
+    }
+
+    // 实现 remove 方法，实现正序的移除方法
+    public void remove() {
+        removeAscending();
+    }
+
+}
+```
+
+#### 16.1.9.4 DescendingSubMapEntryIterator
+
+DescendingSubMapEntryIterator ，继承 SubMapIterator 抽象类，Entry 的**倒序**迭代器。代码如下：
+
+```
+// TreeMap.java#NavigableSubMap.java
+
+final class DescendingSubMapEntryIterator extends SubMapIterator<Map.Entry<K,V>> {
+
+    DescendingSubMapEntryIterator(TreeMap.Entry<K,V> last,
+                                  TreeMap.Entry<K,V> fence) {
+        super(last, fence);
+    }
+
+    // 实现 next 方法，实现倒序
+    public Map.Entry<K,V> next() {
+        return prevEntry();
+    }
+
+    // 实现 remove 方法，实现倒序的移除方法
+    public void remove() {
+        removeDescending();
+    }
+}
+```
+
+### 16.1.10 转换成 Set/Collection
+
+#### 16.1.10.1 keySet
+
+`#keySet()` 方法，获得**正序**的 key Set 。代码如下：
+
+```
+// TreeMap.java#NavigableSubMap.java
+
+/**
+ * 正序的 KeySet 缓存对象
+ */
+transient KeySet<K> navigableKeySetView;
+        
+public final Set<K> keySet() {
+    return navigableKeySet();
+}
+
+public final NavigableSet<K> navigableKeySet() {
+    KeySet<K> nksv = navigableKeySetView;
+    return (nksv != null) ? nksv :
+        (navigableKeySetView = new TreeMap.KeySet<>(this));
+}
+```
+
+- KeySet 使用的迭代器，就是 [「16.1.9.1 SubMapKeyIterator」](https://svip.iocoder.cn/JDK/Collection-TreeMap/#) 。
+
+#### 16.1.10.2 navigableKeySet
+
+`#navigableKeySet()` 方法，获得**倒序**的 key Set 。代码如下：
+
+```
+// TreeMap.java#NavigableSubMap.java
+
+/**
+ * 倒序的 KeySet 缓存对象
+ */
+transient NavigableMap<K,V> descendingMapView;
+
+public NavigableSet<K> descendingKeySet() {
+    return descendingMap().navigableKeySet();
+}
+```
+
+- 其中，`#descendingMap()` 方法，子类自己实现。
+
+#### 16.1.10.3 values
+
+直接使用继承自 AbstractMap 的 `#values()` 方法，代码如下：
+
+```
+// AbstractMap.java
+
+transient Collection<V> values;
+
+public Collection<V> values() {
+    Collection<V> vals = values;
+    if (vals == null) {
+        vals = new AbstractCollection<V>() {
+            public Iterator<V> iterator() {
+                return new Iterator<V>() {
+                    private Iterator<Entry<K,V>> i = entrySet().iterator();
+
+                    public boolean hasNext() {
+                        return i.hasNext();
+                    }
+
+                    public V next() {
+                        return i.next().getValue();
+                    }
+
+                    public void remove() {
+                        i.remove();
+                    }
+                };
+            }
+
+            public int size() {
+                return AbstractMap.this.size();
+            }
+
+            public boolean isEmpty() {
+                return AbstractMap.this.isEmpty();
+            }
+
+            public void clear() {
+                AbstractMap.this.clear();
+            }
+
+            public boolean contains(Object v) {
+                return AbstractMap.this.containsValue(v);
+            }
+        };
+        values = vals;
+    }
+    return vals;
+}
+```
+
+- 也是基于 `#entrySet()` 方法，来实现。
+
+#### 16.1.10.4 entrySet
+
+NavigableSubMap 未提供 `#entrySet()` 方法的实现，不过提供了 EntrySetView 抽象类，它实现了 [`java.util.AbstractSet`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/util/AbstractSet.java) 抽像类，是 NavigableSubMap 的内部类。比较简单，就不哔哔了。
+
+### 16.1.11 查找范围的元素
+
+```
+// TreeMap.java#NavigableSubMap.java
+
+public final SortedMap<K,V> subMap(K fromKey, K toKey) {
+    return subMap(fromKey, true, toKey, false);
+}
+
+public final SortedMap<K,V> headMap(K toKey) {
+    return headMap(toKey, false);
+}
+
+public final SortedMap<K,V> tailMap(K fromKey) {
+    return tailMap(fromKey, true);
+}
+```
+
+- 每个方法内部调用的方法，都是子类来实现。
+
+## 16.2 AscendingSubMap
+
+AscendingSubMap ，继承 NavigableSubMap 抽象类，**正序**的 子 NavigableMap 的实现类。
+
+### 16.2.1 查找接近的元素
+
+```
+// TreeMap.java#AscendingSubMap.java
+
+TreeMap.Entry<K,V> subLowest()       { return absLowest(); }
+TreeMap.Entry<K,V> subHighest()      { return absHighest(); }
+TreeMap.Entry<K,V> subCeiling(K key) { return absCeiling(key); }
+TreeMap.Entry<K,V> subHigher(K key)  { return absHigher(key); }
+TreeMap.Entry<K,V> subFloor(K key)   { return absFloor(key); }
+TreeMap.Entry<K,V> subLower(K key)   { return absLower(key); }
+```
+
+### 16.2.2 获得迭代器
+
+```
+// TreeMap.java#AscendingSubMap.java
+
+Iterator<K> keyIterator() {
+    return new SubMapKeyIterator(absLowest(), absHighFence());
+}
+
+Iterator<K> descendingKeyIterator() {
+    return new DescendingSubMapKeyIterator(absHighest(), absLowFence());
+}
+```
+
+### 16.2.3 转换成 Set/Collection
+
+#### 16.2.3.1 descendingMap
+
+`#descendingMap()` 方法，获得**倒序** descendingMap。代码如下：
+
+```
+// TreeMap.java#AscendingSubMap.java
+
+public NavigableMap<K,V> descendingMap() {
+    NavigableMap<K,V> mv = descendingMapView;
+    return (mv != null) ? mv :
+        (descendingMapView =
+         new DescendingSubMap<>(m,
+                                fromStart, lo, loInclusive,
+                                toEnd,     hi, hiInclusive));
+}
+```
+
+- 该方法，会被 [「16.1.9.2 DescendingSubMapKeyIterator」](https://svip.iocoder.cn/JDK/Collection-TreeMap/#) 调用。
+
+#### 16.2.3.2 entrySet
+
+`#entrySet()` 方法，获得 Entry 集合。代码如下：
+
+```
+// TreeMap.java#AscendingSubMap.java
+
+public Set<Map.Entry<K,V>> entrySet() {
+    EntrySetView es = entrySetView;
+    return (es != null) ? es : (entrySetView = new AscendingEntrySetView());
+}
+
+final class AscendingEntrySetView extends EntrySetView {
+    public Iterator<Map.Entry<K,V>> iterator() {
+        return new SubMapEntryIterator(absLowest(), absHighFence());
+    }
+}
+```
+
+- AscendingEntrySetView 使用的迭代器，就是 [「16.1.9.3 SubMapEntryIterator」](https://svip.iocoder.cn/JDK/Collection-TreeMap/#) 。
+
+### 16.2.4 查找范围的元素
+
+```
+// TreeMap.java#AscendingSubMap.java
+
+public NavigableMap<K,V> subMap(K fromKey, boolean fromInclusive,
+                                K toKey,   boolean toInclusive) {
+    // 如果不在范围，抛出 IllegalArgumentException 异常
+    if (!inRange(fromKey, fromInclusive))
+        throw new IllegalArgumentException("fromKey out of range");
+    // 如果不在范围，抛出 IllegalArgumentException 异常
+    if (!inRange(toKey, toInclusive))
+        throw new IllegalArgumentException("toKey out of range");
+    // 创建 AscendingSubMap 对象
+    return new AscendingSubMap<>(m,
+                                 false, fromKey, fromInclusive,
+                                 false, toKey,   toInclusive);
+}
+
+public NavigableMap<K,V> headMap(K toKey, boolean inclusive) {
+    // 如果不在范围，抛出 IllegalArgumentException 异常
+    if (!inRange(toKey, inclusive))
+        throw new IllegalArgumentException("toKey out of range");
+    // 创建 AscendingSubMap 对象
+    return new AscendingSubMap<>(m,
+                                 fromStart, lo,    loInclusive,
+                                 false,     toKey, inclusive);
+}
+
+public NavigableMap<K,V> tailMap(K fromKey, boolean inclusive) {
+    // 如果不在范围，抛出 IllegalArgumentException 异常
+    if (!inRange(fromKey, inclusive))
+        throw new IllegalArgumentException("fromKey out of range");
+    // 创建 AscendingSubMap 对象
+    return new AscendingSubMap<>(m,
+                                 false, fromKey, inclusive,
+                                 toEnd, hi,      hiInclusive);
+}
+```
+
+### 16.2.5 获得排序器
+
+`#comparator()` 方法，代码如下：
+
+```
+// TreeMap.java#AscendingSubMap.java
+
+// 排序器，使用传入的 TreeMap
+public Comparator<? super K> comparator() {
+    return m.comparator();
+}
+```
+
+## 16.3 DescendingSubMap
+
+DescendingSubMap ，继承 NavigableSubMap 抽象类，**倒序**的 子 NavigableMap 的实现类。
+
+### 16.3.1 查找接近的元素
+
+```
+// TreeMap.java#DescendingSubMap.java
+
+TreeMap.Entry<K,V> subLowest()       { return absHighest(); }
+TreeMap.Entry<K,V> subHighest()      { return absLowest(); }
+TreeMap.Entry<K,V> subCeiling(K key) { return absFloor(key); }
+TreeMap.Entry<K,V> subHigher(K key)  { return absLower(key); }
+TreeMap.Entry<K,V> subFloor(K key)   { return absCeiling(key); }
+TreeMap.Entry<K,V> subLower(K key)   { return absHigher(key); }
+```
+
+- 恰好是反过来。
+
+### 16.3.2 获得迭代器
+
+```
+// TreeMap.java#DescendingSubMap.java
+
+Iterator<K> keyIterator() {
+    return new DescendingSubMapKeyIterator(absHighest(), absLowFence());
+}
+
+Iterator<K> descendingKeyIterator() {
+    return new SubMapKeyIterator(absLowest(), absHighFence());
+}
+```
+
+- 恰好是反过来。
+
+### 16.3.3 转换成 Set/Collection
+
+#### 16.3.3.1 descendingMap
+
+`#descendingMap()` 方法，获得**倒序** descendingMap。代码如下：
+
+> 负负得正，其实返回的是正序的。
+
+```
+// TreeMap.java#DescendingSubMap.java
+
+public NavigableMap<K,V> descendingMap() {
+    NavigableMap<K,V> mv = descendingMapView;
+    return (mv != null) ? mv :
+        (descendingMapView =
+         new AscendingSubMap<>(m,
+                               fromStart, lo, loInclusive,
+                               toEnd,     hi, hiInclusive));
+}
+```
+
+- 该方法，会被 [「16.1.9.2 DescendingSubMapKeyIterator」](https://svip.iocoder.cn/JDK/Collection-TreeMap/#) 调用。
+
+#### 16.3.3.2 entrySet
+
+`#entrySet()` 方法，获得 Entry 集合。代码如下：
+
+```
+// TreeMap.java#DescendingSubMap.java
+
+public Set<Map.Entry<K,V>> entrySet() {
+    EntrySetView es = entrySetView;
+    return (es != null) ? es : (entrySetView = new DescendingEntrySetView());
+}
+
+final class DescendingEntrySetView extends EntrySetView {
+    public Iterator<Map.Entry<K,V>> iterator() {
+        return new DescendingSubMapEntryIterator(absHighest(), absLowFence());
+    }
+}
+```
+
+- AscendingEntrySetView 使用的迭代器，就是 [「16.1.9.4 DescendingSubMapEntryIterator」](https://svip.iocoder.cn/JDK/Collection-TreeMap/#) 。
+
+### 16.3.4 查找范围的元素
+
+```
+// TreeMap.java#DescendingSubMap.java
+
+public NavigableMap<K,V> subMap(K fromKey, boolean fromInclusive,
+                                K toKey,   boolean toInclusive) {
+    // 如果不在范围，抛出 IllegalArgumentException 异常
+    if (!inRange(fromKey, fromInclusive))
+        throw new IllegalArgumentException("fromKey out of range");
+    // 如果不在范围，抛出 IllegalArgumentException 异常
+    if (!inRange(toKey, toInclusive))
+        throw new IllegalArgumentException("toKey out of range");
+    // 创建 DescendingSubMap 对象
+    return new DescendingSubMap<>(m,
+                                  false, toKey,   toInclusive,
+                                  false, fromKey, fromInclusive);
+}
+
+public NavigableMap<K,V> headMap(K toKey, boolean inclusive) {
+    // 如果不在范围，抛出 IllegalArgumentException 异常
+    if (!inRange(toKey, inclusive))
+        throw new IllegalArgumentException("toKey out of range");
+    // 创建 DescendingSubMap 对象
+    return new DescendingSubMap<>(m,
+                                  false, toKey, inclusive,
+                                  toEnd, hi,    hiInclusive);
+}
+
+public NavigableMap<K,V> tailMap(K fromKey, boolean inclusive) {
+    // 如果不在范围，抛出 IllegalArgumentException 异常
+    if (!inRange(fromKey, inclusive))
+        throw new IllegalArgumentException("fromKey out of range");
+    // 创建 DescendingSubMap 对象
+    return new DescendingSubMap<>(m,
+                                  fromStart, lo, loInclusive,
+                                  false, fromKey, inclusive);
+}
+```
+
+### 16.3.5 获得排序器
+
+`#comparator()` 方法，代码如下：
+
+```
+// TreeMap.java#DescendingSubMap.java
+
+/**
+ * 倒序排序器
+ */
+private final Comparator<? super K> reverseComparator =
+    Collections.reverseOrder(m.comparator);
+
+public Comparator<? super K> comparator() {
+    return reverseComparator;
+}
+```
+
+# 666. 彩蛋
+
+抛开红黑树的自平衡的逻辑来说，TreeMap 的实现代码，实际是略简单于 HashMap 的。当然，因为 TreeMap 提供的方法较多，所以导致本文会比 HashMap 写的长一些。
+
+下面，我们来对 TreeMap 做一个简单的小结：
+
+- TreeMap 按照 key 的**顺序**的 Map 实现类，底层采用**红黑树**来实现存储。
+
+- TreeMap 因为采用树结构，所以无需初始考虑像 HashMap 考虑**容量**问题，也不存在扩容问题。
+
+- TreeMap 的 **key** 不允许为空( `null` )，可能是因为红黑树是一颗二叉查找树，需要对 key 进行排序。
+
+  > 看了下 [《为什么 TreeMap 中不允许使用 null 键？》](https://codeday.me/bug/20190205/621458.html) 文章，也是这个观点。
+
+- TreeMap 的查找、添加、删除 key-value 键值对的**平均**时间复杂度为 `O(logN)` 。原因是，TreeMap 采用红黑树，操作都需要经过二分查找，而二分查找的时间复杂度是 `O(logN)` 。
+
+- 相比 HashMap 来说，TreeMap 不仅仅支持指定 key 的查找，也支持 key **范围**的查找。当然，这也得益于 TreeMap 数据结构能够提供的有序特性。
\ No newline at end of file
diff --git a/jdk/09-JDK 源码解析-集合（七）TreeSet.assets/01.png b/jdk/09-JDK 源码解析-集合（七）TreeSet.assets/01.png
new file mode 100644
index 0000000..2c05113
Binary files /dev/null and b/jdk/09-JDK 源码解析-集合（七）TreeSet.assets/01.png differ
diff --git a/jdk/09-JDK 源码解析-集合（七）TreeSet.md b/jdk/09-JDK 源码解析-集合（七）TreeSet.md
new file mode 100644
index 0000000..be84585
--- /dev/null
+++ b/jdk/09-JDK 源码解析-集合（七）TreeSet.md	
@@ -0,0 +1,378 @@
+# 精尽 JDK 源码解析 —— 集合（七）TreeSet
+
+# 1. 概述
+
+> 本文，和 [《精尽 JDK 源码解析 —— 集合（五）哈希集合 HashSet》](http://svip.iocoder.cn/JDK/Collection-HashSet/?self) 基本是一致的。
+
+TreeSet ，基于 TreeSet 的 Set 实现类。在业务中，如果我们有排重+ **排序**的需求，一般会考虑使用 TreeSet 。不过，貌似很少会出现排重+ **排序**的双重需求。所以呢，TreeSet 反正艿艿是木有使用过。
+
+# 2. 类图
+
+TreeSet 实现的接口、继承的类，如下图所示：[![类图](09-JDK 源码解析-集合（七）TreeSet.assets/01.png)](http://static.iocoder.cn/images/JDK/2019_12_16/01.png)类图
+
+- 实现 [`java.util.NavigableSet`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/util/NavigableSet.java) 接口，并继承 [`java.util.AbstractSet`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/util/AbstractSet.java) 抽像类。
+- 实现 [`java.io.Serializable`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/io/Serializable.java) 接口。
+- 实现 [`java.lang.Cloneable`](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/lang/Cloneable.java) 接口。
+
+对于 [NavigableSet](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/util/NavigableSet.java) 和 [SortedMap](https://github.com/YunaiV/openjdk/blob/master/src/java.base/share/classes/java/util/SortedMap.java) 接口，已经添加注释，胖友可以直接点击查看。
+
+# 3. 属性
+
+TreeSet 只有一个属性，那就是 `m` 。代码如下：
+
+```
+// TreeSet.java
+
+private transient NavigableMap<E,Object> m;
+```
+
+- `m` 的 key ，存储 HashSet 的每个 key 。
+
+- `map` 的 value ，因为 TreeSet 没有 value 的需要，所以使用一个统一的 `PRESENT` 即可。代码如下：
+
+  ```
+  // TreeSet.java
+  
+  // Dummy value to associate with an Object in the backing Map
+  private static final Object PRESENT = new Object();
+  ```
+
+# 4. 构造方法
+
+TreeSet 一共有 5 个构造方法，代码如下：
+
+```
+// TreeSet.java
+
+TreeSet(NavigableMap<E,Object> m) {
+    this.m = m;
+}
+
+public TreeSet() {
+    this(new TreeMap<>());
+}
+
+public TreeSet(Comparator<? super E> comparator) {
+    this(new TreeMap<>(comparator));
+}
+
+public TreeSet(Collection<? extends E> c) {
+    this();
+    // 批量添加
+    addAll(c);
+}
+
+public TreeSet(SortedSet<E> s) {
+    this(s.comparator());
+    // 批量添加
+    addAll(s);
+}
+```
+
+- 在构造方法中，会创建 TreeMap 对象，赋予到 `m` 属性。
+
+# 5. 添加单个元素
+
+`#add(E e)` 方法，添加单个元素。代码如下：
+
+```
+// TreeSet.java
+
+public boolean add(E e) {
+    return m.put(e, PRESENT)==null;
+}
+```
+
+- `m` 的 value 值，就是我们看到的 `PRESENT` 。
+
+`#addAll(Collection<? extends E> c)` 方法，批量添加。代码如下：
+
+```
+// TreeSet.java
+
+public  boolean addAll(Collection<? extends E> c) {
+    // Use linear-time version if applicable
+    // 情况一
+    if (m.size()==0 && c.size() > 0 &&
+        c instanceof SortedSet &&
+        m instanceof TreeMap) {
+        SortedSet<? extends E> set = (SortedSet<? extends E>) c;
+        TreeMap<E,Object> map = (TreeMap<E, Object>) m;
+        if (Objects.equals(set.comparator(), map.comparator())) {
+            map.addAllForTreeSet(set, PRESENT);
+            return true;
+        }
+    }
+    // 情况二
+    return super.addAll(c);
+}
+```
+
+- 在实现上，和 TreeMap 的批量添加是一样的，对于情况一，会进行优化。
+
+# 6. 移除单个元素
+
+`#remove(Object o)` 方法，移除 `o` 对应的 value ，并返回是否成功。代码如下：
+
+```
+// TreeSet.java
+
+public boolean remove(Object o) {
+    return m.remove(o)==PRESENT;
+}
+```
+
+# 7. 查找单个元素
+
+`#contains(Object key)` 方法，判断 key 是否存在。代码如下：
+
+```
+// TreeSet.java
+
+public boolean contains(Object o) {
+    return m.containsKey(o);
+}
+```
+
+> 艿艿：后面的内容，快速看即可。
+
+# 8. 查找接近的元素
+
+在 NavigableSet 中，定义了四个查找接近的元素：
+
+- `#lower(E e)` 方法，小于 `e` 的 key
+- `#floor(E e)` 方法，小于等于 `e` 的 key
+- `#higher(E e)` 方法，大于 `e` 的 key
+- `#ceiling(E e)` 方法，大于等于 `e` 的 key
+
+我们一起来看看哈。
+
+```
+// TreeSet.java
+
+public E lower(E e) {
+    return m.lowerKey(e);
+}
+
+public E floor(E e) {
+    return m.floorKey(e);
+}
+
+public E ceiling(E e) {
+    return m.ceilingKey(e);
+}
+
+public E higher(E e) {
+    return m.higherKey(e);
+}
+```
+
+# 9. 获得首尾的元素
+
+`#first()` 方法，获得首个 key 。代码如下：
+
+```
+// TreeSet.java
+
+public E first() {
+    return m.firstKey();
+}
+```
+
+- `#pollFirst()` 方法，获得并移除首个 key 。代码如下：
+
+  ```
+  // TreeSet.java
+  
+  public E pollFirst() {
+      Map.Entry<E,?> e = m.pollFirstEntry();
+      return (e == null) ? null : e.getKey();
+  }
+  ```
+
+`#last()` 方法，获得尾部 key 。代码如下：
+
+```
+// TreeSet.java
+
+public E last() {
+    return m.lastKey();
+}
+```
+
+- `#pollLast()` 方法，获得并移除尾部 key 。代码如下：
+
+  ```
+  // TreeSet.java
+  
+  public E pollLast() {
+      Map.Entry<E,?> e = m.pollLastEntry();
+      return (e == null) ? null : e.getKey();
+  }
+  ```
+
+# 10. 清空
+
+`#clear()` 方法，清空。代码如下：
+
+```
+// TreeSet.java
+
+public void clear() {
+    m.clear();
+}
+```
+
+# 11. 克隆
+
+`#clone()` 方法，克隆 TreeSet 。代码如下：
+
+```
+// TreeSet.java
+
+public Object clone() {
+    // 克隆创建 TreeSet 对象
+    TreeSet<E> clone;
+    try {
+        clone = (TreeSet<E>) super.clone();
+    } catch (CloneNotSupportedException e) {
+        throw new InternalError(e);
+    }
+
+    // 创建 TreeMap 对象，赋值给 clone 的 m 属性
+    clone.m = new TreeMap<>(m);
+    return clone;
+}
+```
+
+# 12. 序列化
+
+`#writeObject(ObjectOutputStream s)` 方法，序列化 TreeSet 对象。代码如下：
+
+```
+// TreeSet.java
+
+@java.io.Serial
+private void writeObject(java.io.ObjectOutputStream s)
+    throws java.io.IOException {
+    // Write out any hidden stuff
+    // 写入非静态属性、非 transient 属性
+    s.defaultWriteObject();
+
+    // Write out Comparator
+    // 写入比较器
+    s.writeObject(m.comparator());
+
+    // Write out size
+    // 写入 key-value 键值对数量
+    s.writeInt(m.size());
+
+    // Write out all elements in the proper order.
+    // 写入具体的 key-value 键值对
+    for (E e : m.keySet())
+        s.writeObject(e);
+}
+```
+
+# 13. 反序列化
+
+`#readObject(ObjectInputStream s)` 方法，反序列化成 TreeSet 对象。代码如下：
+
+```
+// TreeSet.java
+
+@java.io.Serial
+private void readObject(java.io.ObjectInputStream s)
+    throws java.io.IOException, ClassNotFoundException {
+    // Read in any hidden stuff
+    // 读取非静态属性、非 transient 属性
+    s.defaultReadObject();
+
+    // Read in Comparator
+    // 读取比较器
+    @SuppressWarnings("unchecked")
+    Comparator<? super E> c = (Comparator<? super E>) s.readObject();
+
+    // Create backing TreeMap
+    // 创建 TreeMap 对象
+    TreeMap<E,Object> tm = new TreeMap<>(c);
+    m = tm;
+
+    // Read in size
+    // 读取 key-value 键值对数量
+    int size = s.readInt();
+
+    // 读取具体的 key-value 键值对
+    tm.readTreeSet(size, s, PRESENT);
+}
+
+// TreeMap.java
+
+void readTreeSet(int size, java.io.ObjectInputStream s, V defaultVal)
+    throws java.io.IOException, ClassNotFoundException {
+    buildFromSorted(size, null, s, defaultVal);
+}
+```
+
+# 14. 获得迭代器
+
+```
+// TreeSet.java
+
+public Iterator<E> iterator() { // 正序 Iterator 迭代器
+    return m.navigableKeySet().iterator();
+}
+
+public Iterator<E> descendingIterator() { // 倒序 Iterator 迭代器
+    return m.descendingKeySet().iterator();
+}
+```
+
+# 15. 转换成 Set/Collection
+
+```
+// TreeSet.java
+
+public NavigableSet<E> descendingSet() {
+    return new TreeSet<>(m.descendingMap());
+}
+```
+
+# 16. 查找范围的元素
+
+```
+// TreeSet.java
+
+// subSet 组
+public NavigableSet<E> subSet(E fromElement, boolean fromInclusive,
+                              E toElement,   boolean toInclusive) {
+    return new TreeSet<>(m.subMap(fromElement, fromInclusive,
+                                   toElement,   toInclusive));
+}
+public SortedSet<E> subSet(E fromElement, E toElement) {
+    return subSet(fromElement, true, toElement, false);
+}
+
+// headSet 组
+public NavigableSet<E> headSet(E toElement, boolean inclusive) {
+    return new TreeSet<>(m.headMap(toElement, inclusive));
+}
+public SortedSet<E> headSet(E toElement) {
+    return headSet(toElement, false);
+}
+
+// tailSet 组
+public NavigableSet<E> tailSet(E fromElement, boolean inclusive) {
+    return new TreeSet<>(m.tailMap(fromElement, inclusive));
+}
+
+public SortedSet<E> tailSet(E fromElement) {
+    return tailSet(fromElement, true);
+}
+```
+
+# 666. 彩蛋
+
+😈 总的来说，比较简单，相信胖友一会会时间就已经看完了。
+
+关于 TreeSet 的总结，只有一句话：TreeSet 是基于 TreeMap 的 Set 实现类。
\ No newline at end of file
diff --git a/jdk/file-create.py b/jdk/file-create.py
new file mode 100644
index 0000000..a412975
--- /dev/null
+++ b/jdk/file-create.py
@@ -0,0 +1,27 @@
+import os
+import pyperclip
+
+# 获取当前脚本的路径
+script_dir = os.path.dirname(os.path.abspath(__file__))
+
+# 从剪贴板获取文件名列表，假设每行一个文件名
+file_names = pyperclip.paste().strip().split('\n')
+
+# 遍历文件名列表，为每个文件名添加排序前缀并创建文件
+for index, file_name in enumerate(file_names, start=1):
+    # 去除文件名两端的空白字符
+    file_name = file_name.strip()
+    
+    # 添加排序前缀和.md后缀
+    file_name_with_prefix = f"{index:02d}-{file_name}.md"  # 这里使用3位数的排序前缀，可以根据需要调整
+    
+    # 构建文件的完整路径
+    file_path = os.path.join(script_dir, file_name_with_prefix)
+    
+    # 创建文件
+    with open(file_path, 'w') as file:
+        # 如果需要写入初始内容，可以在这里添加
+        # 例如：file.write("This is the content of the file.")
+        pass  # 如果不需要写入内容，则使用pass
+
+print(f"Files created successfully in {script_dir}")
\ No newline at end of file
diff --git a/jdk/tmp.txt b/jdk/tmp.txt
new file mode 100644
index 0000000..277cfa0
--- /dev/null
+++ b/jdk/tmp.txt
@@ -0,0 +1,9 @@
+JDK 源码解析-调试环境搭建（一）入门
+JDK 源码解析-调试环境搭建（二）进阶
+JDK 源码解析-集合（一）数组 ArrayList
+JDK 源码解析-集合（二）链表 LinkedList
+JDK 源码解析-集合（三）哈希表 HashMap
+JDK 源码解析-集合（四）哈希表 LinkedHashMap
+JDK 源码解析-集合（五）哈希集合 HashSet
+JDK 源码解析-集合（六）TreeMap
+JDK 源码解析-集合（七）TreeSet
\ No newline at end of file
diff --git a/mybatis/00-mybatis-面试.assets/02.png b/mybatis/00-mybatis-面试.assets/02.png
new file mode 100644
index 0000000..94bf127
Binary files /dev/null and b/mybatis/00-mybatis-面试.assets/02.png differ
diff --git a/mybatis/00-mybatis-面试.md b/mybatis/00-mybatis-面试.md
new file mode 100644
index 0000000..2f0ec2d
--- /dev/null
+++ b/mybatis/00-mybatis-面试.md
@@ -0,0 +1,637 @@
+# 精尽 MyBatis 面试题「最新更新时间：2024-02」
+
+以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。
+
+如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的 MyBatis 面试题的大保健。
+
+而题目的难度，艿艿尽量按照从容易到困难的顺序，逐步下去。
+
+## MyBatis 编程步骤
+
+1. 创建 SqlSessionFactory 对象。
+2. 通过 SqlSessionFactory 获取 SqlSession 对象。
+3. 通过 SqlSession 获得 Mapper 代理对象。
+4. 通过 Mapper 代理对象，执行数据库操作。
+5. 执行成功，则使用 SqlSession 提交事务。
+6. 执行失败，则使用 SqlSession 回滚事务。
+7. 最终，关闭会话。
+
+## `#{}` 和 `${}` 的区别是什么？
+
+`${}` 是 Properties 文件中的变量占位符，它可以用于 XML 标签属性值和 SQL 内部，属于**字符串替换**。例如将 `${driver}` 会被静态替换为 `com.mysql.jdbc.Driver` ：
+
+```
+<dataSource type="UNPOOLED">
+    <property name="driver" value="${driver}"/>
+    <property name="url" value="${url}"/>
+    <property name="username" value="${username}"/>
+</dataSource>
+```
+
+`${}` 也可以对传递进来的参数**原样拼接**在 SQL 中。代码如下：
+
+```
+<select id="getSubject3" parameterType="Integer" resultType="Subject">
+    SELECT * FROM subject
+    WHERE id = ${id}
+</select>
+```
+
+- 实际场景下，不推荐这么做。因为，可能有 SQL 注入的风险。
+
+------
+
+`#{}` 是 SQL 的参数占位符，Mybatis 会将 SQL 中的 `#{}` 替换为 `?` 号，在 SQL 执行前会使用 PreparedStatement 的参数设置方法，按序给 SQL 的 `?` 号占位符设置参数值，比如 `ps.setInt(0, parameterValue)` 。 所以，`#{}` 是**预编译处理**，可以有效防止 SQL 注入，提高系统安全性。
+
+------
+
+另外，`#{}` 和 `${}` 的取值方式非常方便。例如：`#{item.name}` 的取值方式，为使用反射从参数对象中，获取 `item` 对象的 `name` 属性值，相当于 `param.getItem().getName()` 。
+
+## 当实体类中的属性名和表中的字段名不一样 ，怎么办？
+
+第一种， 通过在查询的 SQL 语句中定义字段名的别名，让字段名的别名和实体类的属性名一致。代码如下：
+
+```
+<select id="selectOrder" parameterType="Integer" resultType="Order"> 
+    SELECT order_id AS id, order_no AS orderno, order_price AS price 
+    FROM orders 
+    WHERE order_id = #{id}
+</select>
+```
+
+- 这里，艿艿还有几点建议：
+  - 1、数据库的关键字，统一使用大写，例如：`SELECT`、`AS`、`FROM`、`WHERE` 。
+  - 2、每 5 个查询字段换一行，保持整齐。
+  - 3、`,` 的后面，和 `=` 的前后，需要有空格，更加清晰。
+  - 4、`SELECT`、`FROM`、`WHERE` 等，单独一行，高端大气。
+
+------
+
+第二种，是第一种的特殊情况。大多数场景下，数据库字段名和实体类中的属性名差，主要是前者为**下划线风格**，后者为**驼峰风格**。在这种情况下，可以直接配置如下，实现自动的下划线转驼峰的功能。
+
+```
+<setting name="logImpl" value="LOG4J"/>
+    <setting name="mapUnderscoreToCamelCase" value="true" />
+</settings>
+```
+
+😈 也就说，约定大于配置。非常推荐！
+
+------
+
+第三种，通过 `<resultMap>` 来映射字段名和实体类属性名的一一对应的关系。代码如下：
+
+```
+<resultMap type="me.gacl.domain.Order" id=”OrderResultMap”> 
+    <!–- 用 id 属性来映射主键字段 -–> 
+    <id property="id" column="order_id"> 
+    <!–- 用 result 属性来映射非主键字段，property 为实体类属性名，column 为数据表中的属性 -–> 
+    <result property="orderNo" column ="order_no" /> 
+    <result property="price" column="order_price" /> 
+</resultMap>
+
+<select id="getOrder" parameterType="Integer" resultMap="OrderResultMap">
+    SELECT * 
+    FROM orders 
+    WHERE order_id = #{id}
+</select>
+```
+
+- 此处 `SELECT *` 仅仅作为示例只用，实际场景下，千万千万千万不要这么干。用多少字段，查询多少字段。
+- 相比第一种，第三种的**重用性**会一些。
+
+## XML 映射文件中，除了常见的 select | insert | update | delete标 签之外，还有哪些标签？
+
+如下部分，可见 [《MyBatis 文档 —— Mapper XML 文件》](http://www.mybatis.org/mybatis-3/zh/sqlmap-xml.html) ：
+
+- `<cache />`标签，给定命名空间的缓存配置。
+  - `<cache-ref />` 标签，其他命名空间缓存配置的引用。
+- `<resultMap />` 标签，是最复杂也是最强大的元素，用来描述如何从数据库结果集中来加载对象。
+- `<sql />`标签，可被其他语句引用的可重用语句块。
+  
+  - `<include />` 标签，引用 `<sql />` 标签的语句。
+- `<selectKey />` 标签，不支持自增的主键生成策略标签。
+
+如下部分，可见 [《MyBatis 文档 —— 动态 SQL》](http://www.mybatis.org/mybatis-3/zh/dynamic-sql.html) ：
+
+- `<if />`
+- `<choose />`、`<when />`、`<otherwise />`
+- `<trim />`、`<where />`、`<set />`
+- `<foreach />`
+- `<bind />`
+
+## Mybatis 动态 SQL 是做什么的？都有哪些动态 SQL ？能简述一下动态 SQL 的执行原理吗？
+
+- Mybatis 动态 SQL ，可以让我们在 XML 映射文件内，以 XML 标签的形式编写动态 SQL ，完成逻辑判断和动态拼接 SQL 的功能。
+- Mybatis 提供了 9 种动态 SQL 标签：`<if />`、`<choose />`、`<when />`、`<otherwise />`、`<trim />`、`<where />`、`<set />`、`<foreach />`、`<bind />` 。
+- 其执行原理为，使用 **OGNL** 的表达式，从 SQL 参数对象中计算表达式的值，根据表达式的值动态拼接 SQL ，以此来完成动态 SQL 的功能。
+
+如上的内容，更加详细的话，请看 [《MyBatis 文档 —— 动态 SQL》](http://www.mybatis.org/mybatis-3/zh/dynamic-sql.html) 文档。
+
+## 最佳实践中，通常一个 XML 映射文件，都会写一个 Mapper 接口与之对应。请问，这个 Mapper 接口的工作原理是什么？Mapper 接口里的方法，参数不同时，方法能重载吗？
+
+Mapper 接口，对应的关系如下：
+
+- 接口的全限名，就是映射文件中的 `"namespace"` 的值。
+- 接口的方法名，就是映射文件中 MappedStatement 的 `"id"` 值。
+- 接口方法内的参数，就是传递给 SQL 的参数。
+
+Mapper 接口是没有实现类的，当调用接口方法时，接口全限名 + 方法名拼接字符串作为 key 值，可唯一定位一个对应的 MappedStatement 。举例：`com.mybatis3.mappers.StudentDao.findStudentById` ，可以唯一找到 `"namespace"` 为 `com.mybatis3.mappers.StudentDao` 下面 `"id"` 为 `findStudentById` 的 MappedStatement 。
+
+总结来说，在 Mybatis 中，每一个 `<select />`、`<insert />`、`<update />`、`<delete />` 标签，都会被解析为一个 MappedStatement 对象。
+
+另外，Mapper 接口的实现类，通过 MyBatis 使用 **JDK Proxy** 自动生成其代理对象 Proxy ，而代理对象 Proxy 会拦截接口方法，从而“调用”对应的 MappedStatement 方法，最终执行 SQL ，返回执行结果。整体流程如下图：[![流程](http://static.iocoder.cn/images/MyBatis/2020_03_15/02.png)](http://static.iocoder.cn/images/MyBatis/2020_03_15/02.png)流程
+
+- 其中，SqlSession 在调用 Executor 之前，会获得对应的 MappedStatement 方法。例如：`DefaultSqlSession#select(String statement, Object parameter, RowBounds rowBounds, ResultHandler handler)` 方法，代码如下：
+
+  ```
+  // DefaultSqlSession.java
+  
+  @Override
+  public void select(String statement, Object parameter, RowBounds rowBounds, ResultHandler handler) {
+      try {
+          // 获得 MappedStatement 对象
+          MappedStatement ms = configuration.getMappedStatement(statement);
+          // 执行查询
+          executor.query(ms, wrapCollection(parameter), rowBounds, handler);
+      } catch (Exception e) {
+          throw ExceptionFactory.wrapException("Error querying database.  Cause: " + e, e);
+      } finally {
+          ErrorContext.instance().reset();
+      }
+  }
+  ```
+
+  - 完整的流程，胖友可以慢慢撸下 MyBatis 的源码。
+
+------
+
+Mapper 接口里的方法，是不能重载的，因为是**全限名 + 方法名**的保存和寻找策略。😈 所以有时，想个 Mapper 接口里的方法名，还是蛮闹心的，嘿嘿。
+
+## Mapper 
接口绑定有几种实现方式,分别是怎么实现的?
+
+接口绑定有三种实现方式：
+
+第一种，通过 **XML Mapper** 里面写 SQL 来绑定。在这种情况下，要指定 XML 映射文件里面的 `"namespace"` 必须为接口的全路径名。
+
+第二种，通过**注解**绑定，就是在接口的方法上面加上 `@Select`、`@Update`、`@Insert`、`@Delete` 注解，里面包含 SQL 语句来绑定。
+
+第三种，是第二种的特例，也是通过**注解**绑定，在接口的方法上面加上 `@


SelectProvider`、`@UpdateProvider`、`@InsertProvider`、`@DeleteProvider` 注解，通过 Java 代码，生成对应的动态 SQL 。
+
+------
+
+实际场景下，最最最推荐的是**第一种**方式。因为，SQL 通过注解写在 Java 代码中，会非常杂乱。而写在 XML 中，更加有整体性，并且可以更加方便的使用 OGNL 表达式。
+
+## Mybatis 的 XML Mapper文件中，不同的 XML 映射文件，id 是否可以重复？
+
+不同的 XML Mapper 文件，如果配置了 `"namespace"` ，那么 id 可以重复；如果没有配置 `"namespace"` ，那么 id 不能重复。毕竟`"namespace"` 不是必须的，只是最佳实践而已。
+
+原因就是，`namespace + id` 是作为 `Map<String, MappedStatement>` 的 key 使用的。如果没有 `"namespace"`，就剩下 id ，那么 id 重复会导致数据互相覆盖。如果有了 `"namespace"`，自然 id 就可以重复，`"namespace"`不同，`namespace + id` 自然也就不同。
+
+## 如何获取自动生成的(主)键值?
+
+不同的数据库，获取自动生成的(主)键值的方式是不同的。
+
+MySQL 有两种方式，但是**自增主键**，代码如下：
+
+```
+// 方式一，使用 useGeneratedKeys + keyProperty 属性
+<insert id="insert" parameterType="Person" useGeneratedKeys="true" keyProperty="id">
+    INSERT INTO person(name, pswd)
+    VALUE (#{name}, #{pswd})
+</insert>
+    
+// 方式二，使用 `<selectKey />` 标签
+<insert id="insert" parameterType="Person">
+    <selectKey keyProperty="id" resultType="long" order="AFTER">
+        SELECT LAST_INSERT_ID()
+    </selectKey>
+        
+    INSERT INTO person(name, pswd)
+    VALUE (#{name}, #{pswd})
+</insert>
+```
+
+- 其中，**方式一**较为常用。
+
+------
+
+Oracle 有两种方式，**序列**和**触发器**。因为艿艿自己不了解 Oracle ，所以问了银行的朋友，他们是使用**序列**。而基于**序列**，根据 `<selectKey />` 执行的时机，也有两种方式，代码如下：
+
+```
+// 这个是创建表的自增序列
+CREATE SEQUENCE student_sequence
+INCREMENT BY 1
+NOMAXVALUE
+NOCYCLE
+CACHE 10;
+
+// 方式一，使用 `<selectKey />` 标签 + BEFORE
+<insert id="add" parameterType="Student">
+　　<selectKey keyProperty="student_id" resultType="int" order="BEFORE">
+      select student_sequence.nextval FROM dual
+    </selectKey>
+    
+     INSERT INTO student(student_id, student_name, student_age)
+     VALUES (#{student_id},#{student_name},#{student_age})
+</insert>
+
+// 方式二，使用 `<selectKey />` 标签 + AFTER
+<insert id="save" parameterType="com.threeti.to.ZoneTO" >
+    <selectKey resultType="java.lang.Long" keyProperty="id" order="AFTER" >
+      SELECT SEQ_ZONE.CURRVAL AS id FROM dual
+    </selectKey>
+    
+    INSERT INTO TBL_ZONE (ID, NAME ) 
+    VALUES (SEQ_ZONE.NEXTVAL, #{name,jdbcType=VARCHAR})
+</insert>
+```
+
+- 他们使用第一种方式，没有具体原因，可能就没什么讲究吧。嘿嘿。
+
+至于为什么不用**触发器**呢？朋友描述如下：
+
+> 朋友：触发器不行啊，我们这边原来也有触发器，一有数据更改就会有问题了呀
+> 艿艿：数据更改指的是？
+> 朋友：就改线上某几条数据
+> 艿艿：噢噢。手动改是吧？
+> 朋友：不行~
+
+------
+
+当然，数据库还有 SQLServer、PostgreSQL、DB2、H2 等等，具体的方式，胖友自己 Google 下噢。
+
+关于如何获取自动生成的(主)键值的**原理**，可以看看 [《精尽 MyBatis 源码分析 —— SQL 执行（三）之 KeyGenerator》](http://svip.iocoder.cn/MyBatis/executor-3/) 。
+
+## Mybatis 执行批量插入，能返回数据库主键列表吗？
+
+能，JDBC 都能做，Mybatis 当然也能做。
+
+## 在 Mapper 中如何传递多个参数?
+
+第一种，使用 Map 集合，装载多个参数进行传递。代码如下：
+
+```
+// 调用方法
+Map<String, Object> map = new HashMap();
+map.put("start", start);
+map.put("end", end);
+return studentMapper.selectStudents(map);
+
+// Mapper 接口
+List<Student> selectStudents(Map<String, Object> map);
+
+// Mapper XML 代码
+<select id="selectStudents" parameterType="Map" resultType="Student">
+    SELECT * 
+    FROM students 
+    LIMIT #{start}, #{end}
+</select>
+```
+
+- 显然，这不是一种优雅的方式。
+
+------
+
+第二种，保持传递多个参数，使用 `@Param` 注解。代码如下：
+
+```
+// 调用方法
+return studentMapper.selectStudents(0, 10);
+
+// Mapper 接口
+List<Student> selectStudents(@Param("start") Integer start, @Param("end") Integer end);
+
+// Mapper XML 代码
+<select id="selectStudents" resultType="Student">
+    SELECT * 
+    FROM students 
+    LIMIT #{start}, #{end}
+</select>
+```
+
+- 推荐使用这种方式。
+
+------
+
+第三种，保持传递多个参数，不使用 `@Param` 注解。代码如下：
+
+```
+// 调用方法
+return studentMapper.selectStudents(0, 10);
+
+// Mapper 接口
+List<Student> selectStudents(Integer start, Integer end);
+
+// Mapper XML 代码
+<select id="selectStudents" resultType="Student">
+    SELECT * 
+    FROM students 
+    LIMIT #{param1}, #{param2}
+</select>
+```
+
+- 其中，按照参数在方法方法中的位置，从 1 开始，逐个为 `#{param1}`、`#{param2}`、`#{param3}` 不断向下。
+
+## Mybatis 是否可以映射 Enum 枚举类？
+
+Mybatis 可以映射枚举类，对应的实现类为 EnumTypeHandler 或 EnumOrdinalTypeHandler 。
+
+- EnumTypeHandler ，基于 `Enum.name` 属性( String )。**默认**。
+- EnumOrdinalTypeHandler ，基于 `Enum.ordinal` 属性( `int` )。可通过 `<setting name="defaultEnumTypeHandler" value="EnumOrdinalTypeHandler" />` 来设置。
+
+😈 当然，实际开发场景，我们很少使用 Enum 类型，更加的方式是，代码如下：
+
+```
+public class Dog {
+
+    public static final int STATUS_GOOD = 1;
+    public static final int STATUS_BETTER = 2;
+    public static final int STATUS_BEST = 3；
+    
+    private int status;
+    
+}
+```
+
+------
+
+并且，不单可以映射枚举类，Mybatis 可以映射任何对象到表的一列上。映射方式为自定义一个 TypeHandler 类，实现 TypeHandler 的`#setParameter(...)` 和 `#getResult(...)` 接口方法。
+
+TypeHandler 有两个作用：
+
+- 一是，完成从 javaType 至 jdbcType 的转换。
+- 二是，完成 jdbcType 至 javaType 的转换。
+
+具体体现为 `#setParameter(...)` 和 `#getResult(..)` 两个方法，分别代表设置 SQL 问号占位符参数和获取列查询结果。
+
+关于 TypeHandler 的**原理**，可以看看 [《精尽 MyBatis 源码分析 —— 类型模块》](http://svip.iocoder.cn/MyBatis/type-package/) 。
+
+## Mybatis 都有哪些 Executor 执行器？它们之间的区别是什么？
+
+Mybatis 有四种 Executor 执行器，分别是 SimpleExecutor、ReuseExecutor、BatchExecutor、CachingExecutor 。
+
+- SimpleExecutor ：每执行一次 update 或 select 操作，就创建一个 Statement 对象，用完立刻关闭 Statement 对象。
+- ReuseExecutor ：执行 update 或 select 操作，以 SQL 作为key 查找**缓存**的 Statement 对象，存在就使用，不存在就创建；用完后，不关闭 Statement 对象，而是放置于缓存 `Map<String, Statement>` 内，供下一次使用。简言之，就是重复使用 Statement 对象。
+- BatchExecutor ：执行 update 操作（没有 select 操作，因为 JDBC 批处理不支持 select 操作），将所有 SQL 都添加到批处理中（通过 addBatch 方法），等待统一执行（使用 executeBatch 方法）。它缓存了多个 Statement 对象，每个 Statement 对象都是调用 addBatch 方法完毕后，等待一次执行 executeBatch 批处理。**实际上，整个过程与 JDBC 批处理是相同**。
+- CachingExecutor ：在上述的三个执行器之上，增加**二级缓存**的功能。
+
+------
+
+通过设置 `<setting name="defaultExecutorType" value="">` 的 `"value"` 属性，可传入 SIMPLE、REUSE、BATCH 三个值，分别使用 SimpleExecutor、ReuseExecutor、BatchExecutor 执行器。
+
+通过设置 `<setting name="cacheEnabled" value=""` 的 `"value"` 属性为 `true` 时，创建 CachingExecutor 执行器。
+
+------
+
+这块的源码解析，可见 [《精尽 MyBatis 源码分析 —— SQL 执行（一）之 Executor》](http://svip.iocoder.cn/MyBatis/executor-1) 。
+
+## MyBatis 如何执行批量插入?
+
+首先，在 Mapper XML 编写一个简单的 Insert 语句。代码如下：
+
+```
+<insert id="insertUser" parameterType="String"> 
+    INSERT INTO users(name) 
+    VALUES (#{value}) 
+</insert>
+```
+
+然后，然后在对应的 Mapper 接口中，编写映射的方法。代码如下：
+
+```
+public interface UserMapper {
+    
+    void insertUser(@Param("name") String name);
+
+}
+```
+
+最后，调用该 Mapper 接口方法。代码如下：
+
+```
+private static SqlSessionFactory sqlSessionFactory;
+
+@Test
+public void testBatch() {
+    // 创建要插入的用户的名字的数组
+    List<String> names = new ArrayList<>();
+    names.add("占小狼");
+    names.add("朱小厮");
+    names.add("徐妈");
+    names.add("飞哥");
+
+    // 获得执行器类型为 Batch 的 SqlSession 对象，并且 autoCommit = false ，禁止事务自动提交
+    try (SqlSession session = sqlSessionFactory.openSession(ExecutorType.BATCH, false)) {
+        // 获得 Mapper 对象
+        UserMapper mapper = session.getMapper(UserMapper.class);
+        // 循环插入
+        for (String name : names) {
+            mapper.insertUser(name);
+        }
+        // 提交批量操作
+        session.commit();
+    }
+}
+```
+
+代码比较简单，胖友仔细看看。当然，还有另一种方式，代码如下：
+
+```
+INSERT INTO [表名]([列名],[列名]) 
+VALUES
+([列值],[列值])),
+([列值],[列值])),
+([列值],[列值]));
+```
+
+- 对于这种方式，需要保证单条 SQL 不超过语句的最大限制 `max_allowed_packet` 大小，默认为 1 M 。
+
+这两种方式的性能对比，可以看看 [《[实验\]mybatis批量插入方式的比较》](https://www.jianshu.com/p/cce617be9f9e) 。
+
+## 介绍 MyBatis 的一级缓存和二级缓存的概念和实现原理？
+
+内容有些长，直接参见 [《聊聊 MyBatis 缓存机制》](https://tech.meituan.com/mybatis_cache.html) 一文。
+
+------
+
+这块的源码解析，可见 [《精尽 MyBatis 源码分析 —— 缓存模块》](http://svip.iocoder.cn/MyBatis/cache-package) 。
+
+## Mybatis 是否支持延迟加载？如果支持，它的实现原理是什么？
+
+Mybatis 仅支持 association 关联对象和 collection 关联集合对象的延迟加载。其中，association 指的就是**一对一**，collection 指的就是**一对多查询**。
+
+在 Mybatis 配置文件中，可以配置 `<setting name="lazyLoadingEnabled" value="true" />` 来启用延迟加载的功能。默认情况下，延迟加载的功能是**关闭**的。
+
+------
+
+它的原理是，使用 CGLIB 或 Javassist( 默认 ) 创建目标对象的代理对象。当调用代理对象的延迟加载属性的 getting 方法时，进入拦截器方法。比如调用 `a.getB().getName()` 方法，进入拦截器的 `invoke(...)` 方法，发现 `a.getB()` 需要延迟加载时，那么就会单独发送事先保存好的查询关联 B 对象的 SQL ，把 B 查询上来，然后调用`a.setB(b)` 方法，于是 `a` 对象 `b` 属性就有值了，接着完成`a.getB().getName()` 方法的调用。这就是延迟加载的基本原理。
+
+当然了，不光是 Mybatis，几乎所有的包括 Hibernate 在内，支持延迟加载的原理都是一样的。
+
+------
+
+这块的源码解析，可见 [《 精尽 MyBatis 源码分析 —— SQL 执行（五）之延迟加载》](http://svip.iocoder.cn/MyBatis/executor-5) 文章。
+
+## Mybatis 能否执行一对一、一对多的关联查询吗？都有哪些实现方式，以及它们之间的区别。
+
+> 艿艿：这道题有点难度。理解倒是好理解，主要那块源码的实现，艿艿看的有点懵逼。大体的意思是懂的，但是一些细节没扣完。
+
+能，Mybatis 不仅可以执行一对一、一对多的关联查询，还可以执行多对一，多对多的关联查询。
+
+> 艿艿：不过貌似，我自己实际开发中，还是比较喜欢自己去查询和拼接映射的数据。😈
+
+- 多对一查询，其实就是一对一查询，只需要把 `selectOne(...)` 修改为 `selectList(...)` 即可。案例可见 [《MyBatis：多对一表关系详解》](https://blog.csdn.net/xzm_rainbow/article/details/15336959) 。
+- 多对多查询，其实就是一对多查询，只需要把 `#selectOne(...)` 修改为 `selectList(...)` 即可。案例可见 [《【MyBatis学习10】高级映射之多对多查询》](https://blog.csdn.net/eson_15/article/details/51655188) 。
+
+------
+
+关联对象查询，有两种实现方式：
+
+> 艿艿：所有的技术方案，即会有好处，又会有坏处。很难出现，一个完美的银弹方案。
+
+- 一种是单独发送一个 SQL 去查询关联对象，赋给主对象，然后返回主对象。好处是多条 SQL 分开，相对简单，坏处是发起的 SQL 可能会比较多。
+- 另一种是使用嵌套查询，嵌套查询的含义为使用 `join` 查询，一部分列是 A 对象的属性值，另外一部分列是关联对象 B 的属性值。好处是只发一个 SQL 查询，就可以把主对象和其关联对象查出来，坏处是 SQL 可能比较复杂。
+
+那么问题来了，`join` 查询出来 100 条记录，如何确定主对象是 5 个，而不是 100 个呢？其去重复的原理是 `<resultMap>` 标签内的`<id>` 子标签，指定了唯一确定一条记录的 `id` 列。Mybatis 会根据`<id>` 列值来完成 100 条记录的去重复功能，`<id>` 可以有多个，代表了联合主键的语意。
+
+同样主对象的关联对象，也是根据这个原理去重复的。尽管一般情况下，只有主对象会有重复记录，关联对象一般不会重复。例如：下面 `join` 查询出来6条记录，一、二列是 Teacher 对象列，第三列为 Student 对象列。Mybatis 去重复处理后，结果为 1 个老师和 6 个学生，而不是 6 个老师和 6 个学生。
+
+| t_id | t_name  | s_id |
+| :--- | :------ | :--- |
+| 1    | teacher | 38   |
+| 1    | teacher | 39   |
+| 1    | teacher | 40   |
+| 1    | teacher | 41   |
+| 1    | teacher | 42   |
+| 1    | teacher | 43   |
+
+## 简述 Mybatis 的插件运行原理？以及如何编写一个插件？
+
+Mybatis 仅可以编写针对 ParameterHandler、ResultSetHandler、StatementHandler、Executor 这 4 种接口的插件。
+
+Mybatis 使用 JDK 的动态代理，为需要拦截的接口生成代理对象以实现接口方法拦截功能，每当执行这 4 种接口对象的方法时，就会进入拦截方法，具体就是 InvocationHandler 的 `#invoke(...)`方法。当然，只会拦截那些你指定需要拦截的方法。
+
+------
+
+编写一个 MyBatis 插件的步骤如下：
+
+1. 首先，实现 Mybatis 的 Interceptor 接口，并实现 `#intercept(...)` 方法。
+2. 然后，在给插件编写注解，指定要拦截哪一个接口的哪些方法即可
+3. 最后，在配置文件中配置你编写的插件。
+
+具体的，可以参考 [《MyBatis 官方文档 —— 插件》](http://www.mybatis.org/mybatis-3/zh/configuration.html#plugins) 。
+
+------
+
+插件的详细解析，可以看看 [《精尽 MyBatis 源码分析 —— 插件体系（一）之原理》](http://svip.iocoder.cn/MyBatis/plugin-1) 。
+
+## Mybatis 是如何进行分页的？分页插件的原理是什么？
+
+Mybatis 使用 RowBounds 对象进行分页，它是针对 ResultSet 结果集执行的**内存分页**，而非**数据库分页**。
+
+所以，实际场景下，不适合直接使用 MyBatis 原有的 RowBounds 对象进行分页。而是使用如下两种方案：
+
+- 在 SQL 内直接书写带有数据库分页的参数来完成数据库分页功能
+- 也可以使用分页插件来完成数据库分页。
+
+这两者都是基于数据库分页，差别在于前者是工程师**手动**编写分页条件，后者是插件**自动**添加分页条件。
+
+------
+
+分页插件的基本原理是使用 Mybatis 提供的插件接口，实现自定义分页插件。在插件的拦截方法内，拦截待执行的 SQL ，然后重写 SQL ，根据dialect 方言，添加对应的物理分页语句和物理分页参数。
+
+举例：`SELECT * FROM student` ，拦截 SQL 后重写为：`select * FROM student LIMI 0，10` 。
+
+目前市面上目前使用比较广泛的 MyBatis 分页插件有：
+
+- [Mybatis-PageHelper](https://github.com/pagehelper/Mybatis-PageHelper)
+- [MyBatis-Plus](https://github.com/baomidou/mybatis-plus)
+
+从现在看来，[MyBatis-Plus](https://github.com/baomidou/mybatis-plus) 逐步使用的更加广泛。
+
+关于 MyBatis 分页插件的原理深入，可以看看 [《精尽 MyBatis 源码分析 —— 插件体系（二）之 PageHelper》](http://svip.iocoder.cn/MyBatis/plugin-2) 。
+
+## MyBatis 与 Hibernate 有哪些不同？
+
+Mybatis 和 Hibernate 不同，它**不完全是**一个 ORM 框架，因为MyBatis 需要程序员自己编写 SQL 语句。不过 MyBatis 可以通过 XML 或注解方式灵活配置要运行的 SQL 语句，并将 Java 对象和 SQL 语句映射生成最终执行的 SQL ，最后将 SQL 执行的结果再映射生成 Java 对象。
+
+Mybatis 学习门槛低，简单易学，程序员直接编写原生态 SQL ，可严格控制 SQL 执行性能，灵活度高。但是灵活的前提是 MyBatis 无法做到数据库无关性，如果需要实现支持多种数据库的软件则需要自定义多套 SQL 映射文件，工作量大。
+
+Hibernate 对象/关系映射能力强，数据库无关性好。如果用 Hibernate 开发可以节省很多代码，提高效率。但是 Hibernate 的缺点是学习门槛高，要精通门槛更高，而且怎么设计 O/R 映射，在性能和对象模型之间如何权衡，以及怎样用好 Hibernate 需要具有很强的经验和能力才行。
+
+总之，按照用户的需求在有限的资源环境下只要能做出维护性、扩展性良好的软件架构都是好架构，所以框架只有适合才是最好。简单总结如下：
+
+- Hibernate 属于全自动 ORM 映射工具，使用 Hibernate 查询关联对象或者关联集合对象时，可以根据对象关系模型直接获取。
+- Mybatis 属于半自动 ORM 映射工具，在查询关联对象或关联集合对象时，需要手动编写 SQL 来完成。
+
+另外，在 [《浅析 Mybatis 与 Hibernate 的区别与用途》](https://www.jianshu.com/p/96171e647885) 文章，也是写的非常不错的。
+
+当然，实际上，MyBatis 也可以搭配自动生成代码的工具，提升开发效率，还可以使用 [MyBatis-Plus](http://mp.baomidou.com/) 框架，已经内置常用的 SQL 操作，也是非常不错的。
+
+## JDBC 编程有哪些不足之处，MyBatis是如何解决这些问题的？
+
+问题一：SQL 语句写在代码中造成代码不易维护，且代码会比较混乱。
+
+解决方式：将 SQL 语句配置在 Mapper XML 文件中，与 Java 代码分离。
+
+------
+
+问题二：根据参数不同，拼接不同的 SQL 语句非常麻烦。例如 SQL 语句的 WHERE 条件不一定，可能多也可能少，占位符需要和参数一一对应。
+
+解决方式：MyBatis 提供 `<where />`、`<if />` 等等动态语句所需要的标签，并支持 OGNL 表达式，简化了动态 SQL 拼接的代码，提升了开发效率。
+
+------
+
+问题三，对结果集解析麻烦，SQL 变化可能导致解析代码变化，且解析前需要遍历。
+
+解决方式：Mybatis 自动将 SQL 执行结果映射成 Java 对象。
+
+------
+
+问题四，数据库链接创建、释放频繁造成系统资源浪费从而影响系统性能，如果使用数据库链接池可解决此问题。
+
+解决方式：在 `mybatis-config.xml` 中，配置数据链接池，使用连接池管理数据库链接。
+
+😈 当然，即使不使用 MyBatis ，也可以使用数据库连接池。
+另外，MyBatis 默认提供了数据库连接池的实现，只是说，因为其它开源的数据库连接池性能更好，所以一般很少使用 MyBatis 自带的连接池实现。
+
+## Mybatis 比 IBatis 比较大的几个改进是什么？
+
+> 这是一个选择性了解的问题，因为可能现在很多面试官，都没用过 IBatis 框架。
+
+1. 有接口绑定，包括注解绑定 SQL 和 XML 绑定 SQL 。
+2. 动态 SQL 由原来的节点配置变成 OGNL 表达式。
+3. 在一对一或一对多的时候，引进了 `association` ，在一对多的时候，引入了 `collection`节点，不过都是在 `<resultMap />` 里面配置。
+
+## Mybatis 映射文件中，如果 A 标签通过 include 引用了B标签的内容，请问，B 标签能否定义在 A 标签的后面，还是说必须定义在A标签的前面？
+
+> 老艿艿：这道题目，已经和源码实现，有点关系了。
+
+虽然 Mybatis 解析 XML 映射文件是**按照顺序**解析的。但是，被引用的 B 标签依然可以定义在任何地方，Mybatis 都可以正确识别。**也就是说，无需按照顺序，进行定义**。
+
+原理是，Mybatis 解析 A 标签，发现 A 标签引用了 B 标签，但是 B 标签尚未解析到，尚不存在，此时，Mybatis 会将 A 标签标记为**未解析状态**。然后，继续解析余下的标签，包含 B 标签，待所有标签解析完毕，Mybatis 会重新解析那些被标记为未解析的标签，此时再解析A标签时，B 标签已经存在，A 标签也就可以正常解析完成了。
+
+可能有一些绕，胖友可以看看 [《精尽 MyBatis 源码解析 —— MyBatis 初始化（一）之加载 mybatis-config》](http://svip.iocoder.cn/MyBatis/builder-package-1) 。
+
+此处，我们在引申一个问题，Spring IOC 中，存在互相依赖的 Bean 对象，该如何解决呢？答案见 [《【死磕 Spring】—— IoC 之加载 Bean：创建 Bean（五）之循环依赖处理》](http://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-5/) 。
+
+## 简述 Mybatis 的 XML 映射文件和 Mybatis 内部数据结构之间的映射关系？
+
+> 老艿艿：这道题目，已经和源码实现，有点关系了。
+
+Mybatis 将所有 XML 配置信息都封装到 All-In-One 重量级对象Configuration内部。
+
+在 XML Mapper 文件中：
+
+- `<parameterMap>` 标签，会被解析为 ParameterMap 对象，其每个子元素会被解析为 ParameterMapping 对象。
+- `<resultMap>` 标签，会被解析为 ResultMap 对象，其每个子元素会被解析为 ResultMapping 对象。
+- 每一个 `<select>`、`<insert>`、`<update>`、`<delete>` 标签，均会被解析为一个 MappedStatement 对象，标签内的 SQL 会被解析为一个 BoundSql 对象。
+
+## 666. 彩蛋
+
+参考与推荐如下文章：
+
+- 祖大俊 [《Mybatis3.4.x技术内幕（二十三）：Mybatis面试问题集锦（大结局）》](https://my.oschina.net/zudajun/blog/747682)
+- Java3y [《Mybatis 常见面试题》](https://segmentfault.com/a/1190000013678579)
+- Homiss [《MyBatis 面试题》](https://github.com/Homiss/Java-interview-questions/blob/master/框架/MyBatis面试题.md)
\ No newline at end of file
diff --git a/mybatis/01-mybatis-学习指南.md b/mybatis/01-mybatis-学习指南.md
new file mode 100644
index 0000000..979eadd
--- /dev/null
+++ b/mybatis/01-mybatis-学习指南.md
@@ -0,0 +1,78 @@
+[MYBATIS](https://svip.iocoder.cn/categories/MyBatis/)
+
+# 精尽 MyBatis 学习指南
+
+# 视频
+
+- [《MyBatis 视频教程全集》](https://www.bilibili.com/video/av59564271/?pikaqiu) 一共 235P 。
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 本视频分成 A/B/C 三部分。
+  >
+  > - 【必选】A 部分（MyBatis 篇） P01-P88
+  >
+  >   MyBatis配置文件编写，MyBatis动态SQL，MyBatis缓存机制，MyBatis-Spring整合，MyBatis逆向工程，MyBatis高级内容（MyBatis源码解析，MyBatis单/多插件运行机制，MyBatis四大对象工作原理，自定义TypeHandler、MyBatis存储过程&游标处理等）。 视频中会在重要的地方对比MyBatis操作MySQL以及Oracle之间的差异性。
+  >
+  > - 【可选】B 部分（MyBatis-Plus 篇） P89-P178
+  >
+  >   MyBatis-Plus是一款非常强大的MyBatis增强工具包,只做增强不做改变.在不用编写任何SQL语句的情况下即可以极其方便的实现单一、批量、分页等操作。本套教程基于MyBatis-Plus新2.3版本。
+  >
+  > - 【随意】C 部分（通用 Mapper 篇） P179-P235
+  >
+  >   通用Mapper是一款非常好用的MyBatis插件，它能够帮助我们自动生成常用增删改查操作的SQL语句，克服MyBatis开发过程中需要大量编写SQL语句的弊端。由于通用Mapper是根据实体类的属性自动生成对应的SQL语句，所以可以说通用Mapper插件是对MyBatis在ORM方面不足的重要补充。
+
+- [《SSM 整合视频教程全集》](https://www.bilibili.com/video/av59585780/?pikaqiu) 一共有 35P 。
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 和《尚硅谷 Spring 视频教程》是同一个讲师。
+
+- 源生活 [《通过自动回复机器人学 Mybatis — 基础版》](https://www.imooc.com/learn/154) 一共 4 小时 30 分钟。
+
+- 源生活 [《通过自动回复机器人学Mybatis — 加强版》](https://www.imooc.com/learn/260) 一共 2 小时 43 分钟。
+
+- 黑马程序员 [《黑马程序员 - mybatis》](https://www.bilibili.com/video/av17774929) 一共有 50P 。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 书籍
+
+[《MyBatis 书单整理》](http://www.iocoder.cn/Books/MyBatis-books-recommended)
+
+- 刘增辉 [《MyBatis 从入门到精通》](https://book.douban.com/subject/27074809/) 豆瓣评分 7.2 分
+- 杨开振 [《深入浅出 MyBatis 技术原理与实战》](https://book.douban.com/subject/26858114/) 豆瓣 5.2 分
+- 徐郡明 [《MyBatis 技术内幕》](https://book.douban.com/subject/27087564/) 豆瓣评分 7.9 分 重源码
+
+如果是为了入门学习，推荐第一本。
+如果是为了阅读源码，推荐第三本。
+
+# 文章
+
+非常重要，一定一定一定认真看官方文档 [《MyBatis 官方文档》](http://www.mybatis.org/mybatis-3/zh/index.html) 。
+
+- [《芋道 Spring Boot 数据库连接池入门》](http://www.iocoder.cn/Spring-Boot/datasource-pool/?vip) 对应 [lab-19](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-19)
+
+- [《芋道 Spring Boot MyBatis 入门》](http://www.iocoder.cn/Spring-Boot/MyBatis/?vip) 对应 [lab-12-mybatis](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-12-mybatis)
+
+- [《芋道 Spring Boot 多数据源（读写分离）入门》](http://www.iocoder.cn/Spring-Boot/dynamic-datasource/?vip) 对应 [lab-17](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-17)
+
+- [《芋道 Spring Boot 分库分表入门》](http://www.iocoder.cn/Spring-Boot/sharding-datasource/?vip) 对应 [lab-18](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-18)
+
+- 《芋道 Spring Boot 数据库版本管理入门》对应lab-20
+
+  - [《芋道 Spring Boot 数据表结构文档》](http://www.iocoder.cn/Spring-Boot/DB-Doc-screw/?vip) 对应 [lab-70-db-doc](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-70-db-doc)
+
+- [《性能测试 —— MySQL 基准测试》](http://www.iocoder.cn/Performance-Testing/MySQL-benchmark/?github)
+
+- [《Spring Boot 整合 MyBatis》](http://www.iocoder.cn/Spring-Boot/didi/spring-boot-mybatis/?svip)
+
+- [《Spring Boot 中使用 MyBatis 注解配置详解》](http://www.iocoder.cn/Spring-Boot/didi/spring-boot-mybatis-annotations/?svip)
+
+- [《一起来学 SpringBoot 2.x | 第七篇：整合 Mybatis》](http://www.iocoder.cn/Spring-Boot/battcn/v2-orm-mybatis/?svip)
+
+- [《Spring Boot 整合 Mybatis 的完整 Web 案例》](http://www.iocoder.cn/Spring-Boot/bysocket/spring-boot-mybatis-with-web-in-action/?svip)
+
+- [《Spring Boot 整合 Mybatis Annotation 注解案例》](http://www.iocoder.cn/Spring-Boot/byscoket/spring-boot-mybatis-annotations-in-action/?svip)
+
+- [《Spring Boot 整合 Mybatis 实现 Druid 多数据源配置》](http://www.iocoder.cn/Spring-Boot/byscoket/spring-boot-mybatis-with-druid?svip)
\ No newline at end of file
diff --git a/mybatis/02-mybatis-调试环境搭建.assets/01.jpg b/mybatis/02-mybatis-调试环境搭建.assets/01.jpg
new file mode 100644
index 0000000..ea700fd
Binary files /dev/null and b/mybatis/02-mybatis-调试环境搭建.assets/01.jpg differ
diff --git a/mybatis/02-mybatis-调试环境搭建.md b/mybatis/02-mybatis-调试环境搭建.md
new file mode 100644
index 0000000..9794e30
--- /dev/null
+++ b/mybatis/02-mybatis-调试环境搭建.md
@@ -0,0 +1,376 @@
+# 精尽 MyBatis 源码分析 —— 调试环境搭建
+
+# 1. 依赖工具
+
+- Maven
+- Git
+- JDK
+- IntelliJ IDEA
+
+# 2. 源码拉取
+
+从官方仓库 https://github.com/mybatis/mybatis-3 `Fork` 出属于自己的仓库。为什么要 `Fork` ？既然开始阅读、调试源码，我们可能会写一些注释，有了自己的仓库，可以进行自由的提交。😈
+
+使用 `IntelliJ IDEA` 从 `Fork` 出来的仓库拉取代码。
+
+本文使用的 MyBatis 版本为 `3.5.0-SNAPSHOT` 。
+
+因为 MyBatis 是有些年份的框架，所以克隆的过程可能比较慢，耐心等待。
+
+# 3. 调试
+
+MyBatis 想要调试，非常方便，只需要打开 `org.apache.ibatis.autoconstructor.AutoConstructorTest` 单元测试类，任意一个单元测试方法，右键，开始调试即可。
+
+当然，考虑到让大家更好的理解 AutoConstructorTest 这个类，下面，我们还是详细解析下。AutoConstructorTest 所在在 `autoconstructor` 包下，整体结构如下：
+
+[![包结构图](02-mybatis-调试环境搭建.assets/01.jpg)](http://static.iocoder.cn/images/MyBatis/2020_01_01/01.jpg)包结构图
+
+# 4. mybatis-config.xml
+
+`mybatis-config.xml` ，MyBatis 配置文件。XML 如下：
+
+```
+<!DOCTYPE configuration
+        PUBLIC "-//mybatis.org//DTD Config 3.0//EN"
+        "http://mybatis.org/dtd/mybatis-3-config.dtd">
+
+<configuration>
+
+    <!-- autoMappingBehavior should be set in each test case -->
+
+    <environments default="development">
+        <environment id="development">
+            <!-- 配置事务管理 -->
+            <transactionManager type="JDBC">
+                <property name="" value=""/>
+            </transactionManager>
+            <!-- 配置数据源  -->
+            <dataSource type="UNPOOLED">
+                <property name="driver" value="org.hsqldb.jdbcDriver"/>
+                <property name="url" value="jdbc:hsqldb:mem:automapping"/>
+                <property name="username" value="sa"/>
+            </dataSource>
+        </environment>
+    </environments>
+
+    <!-- 扫描 Mapper 文件  -->
+    <mappers>
+        <mapper resource="org/apache/ibatis/autoconstructor/AutoConstructorMapper.xml"/>
+    </mappers>
+
+</configuration>
+```
+
+- 在 `<environments />` 标签中，配置了事务管理和数据源。考虑到减少外部依赖，所以使用了 [HSQLDB](https://zh.wikipedia.org/wiki/HSQLDB) 。
+- 在 `<mappers />` 标签中，配置了需要扫描的 Mapper 文件。目前，仅仅扫描 `AutoConstructorMapper.xml` 文件。
+
+# 5. AutoConstructorMapper.xml
+
+`AutoConstructorMapper.xml` ，Mapper 文件。代码如下：
+
+```
+<!DOCTYPE mapper
+    PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
+    "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
+
+<mapper namespace="org.apache.ibatis.autoconstructor.AutoConstructorMapper">
+</mapper>
+```
+
+- 对应的接口为 `org.apache.ibatis.autoconstructor.AutoConstructorMapper` 。
+
+## 5.1 AutoConstructorMapper
+
+```
+public interface AutoConstructorMapper {
+
+    // ========== PrimitiveSubject ==========
+
+    @Select("SELECT * FROM subject WHERE id = #{id}")
+    PrimitiveSubject getSubject(final int id);
+    @Select("SELECT * FROM subject")
+    List<PrimitiveSubject> getSubjects();
+
+    // ========== AnnotatedSubject ==========
+
+    @Select("SELECT * FROM subject")
+    List<AnnotatedSubject> getAnnotatedSubjects();
+
+    // ========== BadSubject ==========
+
+    @Select("SELECT * FROM subject")
+    List<BadSubject> getBadSubjects();
+
+    // ========== ExtensiveSubject ==========
+
+    @Select("SELECT * FROM extensive_subject")
+    List<ExtensiveSubject> getExtensiveSubject();
+
+}
+```
+
+- 使用注解的方法，编写 SQL 。
+
+# 6. CreateDB.sql
+
+`CreateDB.sql` 文件，用于单元测试里，初始化数据库的数据。如下：
+
+```
+DROP TABLE subject
+IF EXISTS;
+
+DROP TABLE extensive_subject
+IF EXISTS;
+
+CREATE TABLE subject (
+  id     INT NOT NULL,
+  name   VARCHAR(20),
+  age    INT NOT NULL,
+  height INT,
+  weight INT,
+  active BIT,
+  dt     TIMESTAMP
+);
+
+CREATE TABLE extensive_subject (
+  aByte      TINYINT,
+  aShort     SMALLINT,
+  aChar      CHAR,
+  anInt      INT,
+  aLong      BIGINT,
+  aFloat     FLOAT,
+  aDouble    DOUBLE,
+  aBoolean   BIT,
+  aString    VARCHAR(255),
+  anEnum     VARCHAR(50),
+  aClob      LONGVARCHAR,
+  aBlob      LONGVARBINARY,
+  aTimestamp TIMESTAMP
+);
+
+INSERT INTO subject VALUES
+  (1, 'a', 10, 100, 45, 1, CURRENT_TIMESTAMP),
+  (2, 'b', 10, NULL, 45, 1, CURRENT_TIMESTAMP),
+  (2, 'c', 10, NULL, NULL, 0, CURRENT_TIMESTAMP);
+
+INSERT INTO extensive_subject
+VALUES
+  (1, 1, 'a', 1, 1, 1, 1.0, 1, 'a', 'AVALUE', 'ACLOB', 'aaaaaabbbbbb', CURRENT_TIMESTAMP),
+  (2, 2, 'b', 2, 2, 2, 2.0, 2, 'b', 'BVALUE', 'BCLOB', '010101010101', CURRENT_TIMESTAMP),
+  (3, 3, 'c', 3, 3, 3, 3.0, 3, 'c', 'CVALUE', 'CCLOB', '777d010078da', CURRENT_TIMESTAMP);
+```
+
+- 创建了 `subject` 表，并初始化三条数据。
+- 创建了 `extensive_subject` 表，并初始化三条数据。
+
+# 7. POJO
+
+在 AutoConstructorMapper 中，我们可以看到有四个 POJO 类。但是，从 `CreateDB.sql` 中，实际只有两个表。这个是为什么呢？继续往下看噢。
+
+## 7.1 AnnotatedSubject
+
+```
+package org.apache.ibatis.autoconstructor;
+
+import org.apache.ibatis.annotations.AutomapConstructor;
+
+public class AnnotatedSubject {
+
+    private final int id;
+    private final String name;
+    private final int age;
+    private final int height;
+    private final int weight;
+
+    public AnnotatedSubject(final int id, final String name, final int age, final int height, final int weight) {
+        this.id = id;
+        this.name = name;
+        this.age = age;
+        this.height = height;
+        this.weight = weight;
+    }
+
+    @AutomapConstructor
+    public AnnotatedSubject(final int id, final String name, final int age, final Integer height, final Integer weight) {
+        this.id = id;
+        this.name = name;
+        this.age = age;
+        this.height = height == null ? 0 : height;
+        this.weight = weight == null ? 0 : weight;
+    }
+
+}
+```
+
+- 对应 `subject` 表。
+
+- ```
+  @AutomapConstructor
+  ```
+
+   
+
+  注解，表示 MyBatis 查询后，在创建 AnnotatedSubject 对象，使用该构造方法。
+
+  - 😈 实际场景下，非常少使用这个注解，甚至 Google 上资料也不多。
+
+### 7.1.1 PrimitiveSubject
+
+```
+package org.apache.ibatis.autoconstructor;
+
+import java.util.Date;
+
+public class PrimitiveSubject {
+
+    private final int id;
+    private final String name;
+    private final int age;
+    private final int height;
+    private final int weight;
+    private final boolean active;
+    private final Date dt;
+
+    public PrimitiveSubject(final int id, final String name, final int age, final int height, final int weight, final boolean active, final Date dt) {
+        this.id = id;
+        this.name = name;
+        this.age = age;
+        this.height = height;
+        this.weight = weight;
+        this.active = active;
+        this.dt = dt;
+    }
+
+}
+```
+
+- 对应的也是 `subject` 表。
+
+- 和 AnnotatedSubject 不同，在其构造方法上，`weight` 和 `height` 方法参数的类型是 `int` ，而不是 Integer
+
+  。那么，如果 `subject` 表中的记录，这两个字段为 `NULL` 时，会创建 PrimitiveSubject 对象报错。
+
+### 7.1.2 BadSubject
+
+```
+package org.apache.ibatis.autoconstructor;
+
+public class BadSubject {
+
+    private final int id;
+    private final String name;
+    private final int age;
+    private final Height height;
+    private final Double weight;
+
+    public BadSubject(final int id, final String name, final int age, final Height height, final Double weight) {
+        this.id = id;
+        this.name = name;
+        this.age = age;
+        this.height = height;
+        this.weight = weight == null ? 0 : weight;
+    }
+
+    private class Height {
+
+    }
+
+}
+```
+
+- 对应的也是 `subject` 表。
+- 和 AnnotatedSubject 不同，在其构造方法上，`height` 方法参数的类型是 Height ，而不是 Integer 。因为 MyBatis 无法识别 Height 类，所以会创建 BadSubject 对象报错。
+
+> 老艿艿：一般情况下，POJO 对象里，不使用基本类型。
+
+## 7.2 ExtensiveSubject
+
+```
+package org.apache.ibatis.autoconstructor;
+
+public class ExtensiveSubject {
+    private final byte aByte;
+    private final short aShort;
+    private final char aChar;
+    private final int anInt;
+    private final long aLong;
+    private final float aFloat;
+    private final double aDouble;
+    private final boolean aBoolean;
+    private final String aString;
+
+    // enum types
+    private final TestEnum anEnum;
+
+    // array types
+
+    // string to lob types:
+    private final String aClob;
+    private final String aBlob;
+
+    public ExtensiveSubject(final byte aByte,
+                            final short aShort,
+                            final char aChar,
+                            final int anInt,
+                            final long aLong,
+                            final float aFloat,
+                            final double aDouble,
+                            final boolean aBoolean,
+                            final String aString,
+                            final TestEnum anEnum,
+                            final String aClob,
+                            final String aBlob) {
+        this.aByte = aByte;
+        this.aShort = aShort;
+        this.aChar = aChar;
+        this.anInt = anInt;
+        this.aLong = aLong;
+        this.aFloat = aFloat;
+        this.aDouble = aDouble;
+        this.aBoolean = aBoolean;
+        this.aString = aString;
+        this.anEnum = anEnum;
+        this.aClob = aClob;
+        this.aBlob = aBlob;
+    }
+
+    public enum TestEnum {
+        AVALUE, BVALUE, CVALUE;
+    }
+
+}
+```
+
+- 对应的也是 `extensive_subject` 表。
+- 这是个复杂对象，基本涵盖了各种类型的数据。
+
+# 8. AutoConstructorTest
+
+`org.apache.ibatis.autoconstructor.AutoConstructorTest` ，单元测试类。
+
+## 8.1 setUp
+
+```
+private static SqlSessionFactory sqlSessionFactory;
+
+@BeforeClass
+public static void setUp() throws Exception {
+    // create a SqlSessionFactory
+    // 创建 SqlSessionFactory 对象，基于 mybatis-config.xml 配置文件。
+    try (Reader reader = Resources.getResourceAsReader("org/apache/ibatis/autoconstructor/mybatis-config.xml")) {
+        sqlSessionFactory = new SqlSessionFactoryBuilder().build(reader);
+    }
+
+    // populate in-memory database
+    // 初始化数据到内存数据库，基于 CreateDB.sql SQL 文件。
+    BaseDataTest.runScript(sqlSessionFactory.getConfiguration().getEnvironment().getDataSource(),
+            "org/apache/ibatis/autoconstructor/CreateDB.sql");
+}
+```
+
+- 创建 SqlSessionFactory 对象，基于 `mybatis-config.xml` 配置文件。
+- 初始化数据到内存数据库，基于 `CreateDB.sql` SQL 文件。
+
+## 8.2 测试方法
+
+右键任一单元测试方法，愉快的调试起来把。
\ No newline at end of file
diff --git a/mybatis/03-mybatis-项目结构一览.assets/01.png b/mybatis/03-mybatis-项目结构一览.assets/01.png
new file mode 100644
index 0000000..a88490f
Binary files /dev/null and b/mybatis/03-mybatis-项目结构一览.assets/01.png differ
diff --git a/mybatis/03-mybatis-项目结构一览.assets/02.png b/mybatis/03-mybatis-项目结构一览.assets/02.png
new file mode 100644
index 0000000..651dab8
Binary files /dev/null and b/mybatis/03-mybatis-项目结构一览.assets/02.png differ
diff --git a/mybatis/03-mybatis-项目结构一览.assets/03.png b/mybatis/03-mybatis-项目结构一览.assets/03.png
new file mode 100644
index 0000000..fdb70ea
Binary files /dev/null and b/mybatis/03-mybatis-项目结构一览.assets/03.png differ
diff --git a/mybatis/03-mybatis-项目结构一览.assets/04.png b/mybatis/03-mybatis-项目结构一览.assets/04.png
new file mode 100644
index 0000000..503b9bf
Binary files /dev/null and b/mybatis/03-mybatis-项目结构一览.assets/04.png differ
diff --git a/mybatis/03-mybatis-项目结构一览.assets/05.png b/mybatis/03-mybatis-项目结构一览.assets/05.png
new file mode 100644
index 0000000..72f7dc6
Binary files /dev/null and b/mybatis/03-mybatis-项目结构一览.assets/05.png differ
diff --git a/mybatis/03-mybatis-项目结构一览.assets/06.png b/mybatis/03-mybatis-项目结构一览.assets/06.png
new file mode 100644
index 0000000..c2a4e8e
Binary files /dev/null and b/mybatis/03-mybatis-项目结构一览.assets/06.png differ
diff --git a/mybatis/03-mybatis-项目结构一览.md b/mybatis/03-mybatis-项目结构一览.md
new file mode 100644
index 0000000..3add251
--- /dev/null
+++ b/mybatis/03-mybatis-项目结构一览.md
@@ -0,0 +1,216 @@
+# 精尽 MyBatis 源码分析 —— 项目结构一览
+
+# 1. 概述
+
+本文主要分享 **MyBatis 的项目结构**。
+希望通过本文能让胖友对 MyBatis 的整体项目有个简单的了解。
+
+另外，[http://www.mybatis.org](http://www.mybatis.org/mybatis-3/zh/index.html) 提供了 MyBatis 非常不错的中文文档。如果胖友对 MyBatis 碰到一些使用上的问题，可以常常翻阅。
+
+在拉取 MyBatis 项目后，我们会发现拆分了**好多**包。是不是内心一紧，产生了恐惧感？不要方，我们就是继续怼。
+
+[![项目结构](03-mybatis-项目结构一览.assets/01.png)](http://static.iocoder.cn/images/MyBatis/2020_01_04/01.png)项目结构
+
+# 2. 代码统计
+
+这里先分享一个小技巧。笔者在开始源码学习时，会首先了解项目的代码量。
+
+**第一种方式**，使用 [IDEA Statistic](https://plugins.jetbrains.com/plugin/4509-statistic) 插件，统计整体代码量。
+
+[![Statistic 统计代码量](03-mybatis-项目结构一览.assets/02.png)](http://static.iocoder.cn/images/MyBatis/2020_01_04/02.png)Statistic 统计代码量
+
+我们可以粗略的看到，总的代码量在 21441 行。还是在可接受的范围。
+
+**第二种方式**，使用 [Shell 脚本命令逐个 Maven 模块统计](http://blog.csdn.net/yhhwatl/article/details/52623879) 。
+
+一般情况下，笔者使用 `find . -name "*.java"|xargs cat|grep -v -e ^$ -e ^\s*\/\/.*$|wc -l` 。这个命令只过滤了**部分注释**，所以相比 [IDEA Statistic](https://plugins.jetbrains.com/plugin/4509-statistic) 会**偏多**。
+
+如下是艿艿 `cd` 到每个包下，然后执行脚本统计后的结果：
+
+[![Statistic 统计代码量](03-mybatis-项目结构一览.assets/03.png)](http://static.iocoder.cn/images/MyBatis/2020_01_04/03.png)Statistic 统计代码量
+
+# 3. 整体架构
+
+> 老艿艿：本小节的内容，笔者会基于 [《MyBatis 技术内幕》](https://item.jd.com/12125531.html) 的 [「1.4 MyBatis整体架构」](https://svip.iocoder.cn/MyBatis/intro/#) 小节来编写。
+>
+> 这本书非常不错，笔者在死磕的源码的时候，帮助灰常大。
+
+MyBatis 的整体架构分为三层：
+
+1. 基础支持层
+2. 核心处理层
+3. 接口层
+
+> [![整体架构](03-mybatis-项目结构一览.assets/04.png)](http://static.iocoder.cn/images/MyBatis/2020_01_04/04.png)整体架构
+
+## 3.1 基础支持层
+
+基础支持层，包含整个 MyBatis 的基础模块，这些模块为核心处理层的功能提供了良好的支撑。
+
+### 3.1.1 反射模块
+
+对应 `reflection` 包。
+
+> Java 中的反射虽然功能强大，但对大多数开发人员来说，写出高质量的反射代码还是 有一定难度的。MyBatis 中专门提供了反射模块，该模块对 Java 原生的反射进行了良好的封装，提了更加**简洁易用的 API**，方便上层使调用，并且对**反射操作进行了一系列优化**，例如缓存了类的元数据，提高了反射操作的性能。
+
+### 3.1.2 类型模块
+
+对应 `type` 包。
+
+> ① MyBatis 为简化配置文件提供了**别名机制**，该机制是类型转换模块的主要功能之一。
+>
+> ② 类型转换模块的另一个功能是**实现 JDBC 类型与 Java 类型之间**的转换，该功能在为 SQL 语句绑定实参以及映射查询结果集时都会涉及：
+>
+> - 在为 SQL 语句绑定实参时，会将数据由 Java 类型转换成 JDBC 类型。
+> - 而在映射结果集时，会将数据由 JDBC 类型转换成 Java 类型。
+
+### 3.1.3 日志模块
+
+对应 `logging` 包。
+
+> 无论在开发测试环境中，还是在线上生产环境中，日志在整个系统中的地位都是非常重要的。良好的日志功能可以帮助开发人员和测试人员快速定位 Bug 代码，也可以帮助运维人员快速定位性能瓶颈等问题。目前的 Java 世界中存在很多优秀的日志框架，例如 Log4j、 Log4j2、Slf4j 等。
+>
+> MyBatis 作为一个设计优良的框架，除了提供详细的日志输出信息，还要能够集成多种日志框架，其日志模块的一个主要功能就是**集成第三方日志框架**。
+
+### 3.1.4 IO 模块
+
+对应 `io` 包。
+
+> 资源加载模块，主要是对类加载器进行封装，确定类加载器的使用顺序，并提供了加载类文件以及其他资源文件的功能 。
+
+### 3.1.5 解析器模块
+
+对应 `parsing` 包。
+
+> 解析器模块，主要提供了两个功能:
+>
+> - 一个功能，是对 [XPath](http://www.w3school.com.cn/xpath/index.asp) 进行封装，为 MyBatis 初始化时解析 `mybatis-config.xml` 配置文件以及映射配置文件提供支持。
+> - 另一个功能，是为处理动态 SQL 语句中的占位符提供支持。
+
+### 3.1.6 数据源模块
+
+对应 `datasource` 包。
+
+> 数据源是实际开发中常用的组件之一。现在开源的数据源都提供了比较丰富的功能，例如，连接池功能、检测连接状态等，选择性能优秀的数据源组件对于提升 ORM 框架乃至整个应用的性能都是非常重要的。
+>
+> MyBatis **自身提供了相应的数据源实现，当然 MyBatis 也提供了与第三方数据源集成的接口，这些功能都位于数据源模块之中**。
+
+### 3.1.7 事务模块
+
+对应 `transaction` 包。
+
+> MyBatis 对数据库中的事务进行了抽象，其自身提供了**相应的事务接口和简单实现**。
+>
+> 在很多场景中，MyBatis 会与 Spring 框架集成，并由 **Spring 框架管理事务**。
+
+### 3.1.8 缓存模块
+
+对应 `cache` 包。
+
+> 在优化系统性能时，优化数据库性能是非常重要的一个环节，而添加缓存则是优化数据库时最有效的手段之一。正确、合理地使用缓存可以将一部分数据库请求拦截在缓存这一层。
+>
+> MyBatis 中提供了**一级缓存和二级缓存**，而这两级缓存都是依赖于基础支持层中的缓 存模块实现的。这里需要读者注意的是，MyBatis 中自带的这两级缓存与 MyBatis 以及整个应用是运行在同一个 JVM 中的，共享同一块堆内存。如果这两级缓存中的数据量较大， 则可能影响系统中其他功能的运行，所以当需要缓存大量数据时，优先考虑使用 Redis、Memcache 等缓存产品。
+
+### 3.1.9 Binding 模块
+
+对应 `binding` 包。
+
+> 在调用 SqlSession 相应方法执行数据库操作时，需要指定映射文件中定义的 SQL 节点，如果出现拼写错误，我们只能在运行时才能发现相应的异常。为了尽早发现这种错误，MyBatis 通过 Binding 模块，将用户自定义的 Mapper 接口与映射配置文件关联起来，系统可以通过调用自定义 Mapper 接口中的方法执行相应的 SQL 语句完成数据库操作，从而避免上述问题。
+>
+> 值得读者注意的是，开发人员无须编写自定义 Mapper 接口的实现，MyBatis 会自动为其创建动态代理对象。在有些场景中，自定义 Mapper 接口可以完全代替映射配置文件，但有的映射规则和 SQL 语句的定义还是写在映射配置文件中比较方便，例如动态 SQL 语句的定义。
+
+### 3.1.10 注解模块
+
+对应 `annotations` 包。
+
+随着 Java 注解的慢慢流行，MyBatis 提供了**注解**的方式，使得我们方便的在 Mapper 接口上编写简单的数据库 SQL 操作代码，而无需像之前一样，必须编写 SQL 在 XML 格式的 Mapper 文件中。虽然说，实际场景下，大家还是喜欢在 XML 格式的 Mapper 文件中编写响应的 SQL 操作。
+
+### 3.1.11 异常模块
+
+对应 `exceptions` 包。
+
+定义了 MyBatis 专有的 PersistenceException 和 TooManyResultsException 异常。
+
+## 3.2 核心处理层
+
+在核心处理层中，实现了 MyBatis 的核心处理流程，其中包括 MyBatis 的**初始化**以及完成一次**数据库操作**的涉及的全部流程 。
+
+### 3.2.1 配置解析
+
+对应 `builder` 和 `mapping` 模块。前者为配置**解析过程**，后者主要为 SQL 操作解析后的**映射**。
+
+> 在 MyBatis 初始化过程中，会加载 `mybatis-config.xml` 配置文件、映射配置文件以及 Mapper 接口中的注解信息，解析后的配置信息会形成相应的对象并保存到 Configuration 对象中。例如：
+>
+> - `<resultMap>`节点(即 ResultSet 的映射规则) 会被解析成 ResultMap 对象。
+> - `<result>` 节点(即属性映射)会被解析成 ResultMapping 对象。
+>
+> 之后，利用该 Configuration 对象创建 SqlSessionFactory对象。待 MyBatis 初始化之后，开发人员可以通过初始化得到 SqlSessionFactory 创建 SqlSession 对象并完成数据库操作。
+
+### 3.2.2 SQL 解析
+
+对应 `scripting` 模块。
+
+> 拼凑 SQL 语句是一件烦琐且易出错的过程，为了将开发人员从这项枯燥无趣的工作中 解脱出来，MyBatis 实现**动态 SQL 语句**的功能，提供了多种动态 SQL语句对应的节点。例如`<where>` 节点、`<if>` 节点、`<foreach>` 节点等 。通过这些节点的组合使用， 开发人 员可以写出几乎满足所有需求的动态 SQL 语句。
+>
+> MyBatis 中的 `scripting` 模块，会根据用户传入的实参，解析映射文件中定义的动态 SQL 节点，并形成数据库可执行的 SQL 语句。之后会处理 SQL 语句中的占位符，绑定用户传入的实参。
+
+### 3.2.3 SQL 执行
+
+对应 `executor` 和 `cursor` 模块。前者对应**执行器**，后者对应执行**结果的游标**。
+
+> SQL 语句的执行涉及多个组件 ，其中比较重要的是 Executor、StatementHandler、ParameterHandler 和 ResultSetHandler 。
+>
+> - **Executor** 主要负责维护一级缓存和二级缓存，并提供事务管理的相关操作，它会将数据库相关操作委托给 StatementHandler完成。
+> - **StatementHandler** 首先通过 **ParameterHandler** 完成 SQL 语句的实参绑定，然后通过 `java.sql.Statement` 对象执行 SQL 语句并得到结果集，最后通过 **ResultSetHandler** 完成结果集的映射，得到结果对象并返回。
+>
+> 整体过程如下图：
+>
+> [![整体过程](03-mybatis-项目结构一览.assets/05.png)](http://static.iocoder.cn/images/MyBatis/2020_01_04/05.png)整体过程
+
+### 3.2.4 插件层
+
+对应 `plugin` 模块。
+
+> Mybatis 自身的功能虽然强大，但是并不能完美切合所有的应用场景，因此 MyBatis 提供了插件接口，我们可以通过添加用户自定义插件的方式对 MyBatis 进行扩展。用户自定义插件也可以改变 Mybatis 的默认行为，例如，我们可以拦截 SQL 语句并对其进行重写。
+>
+> 由于用户自定义插件会影响 MyBatis 的核心行为，在使用自定义插件之前，开发人员需要了解 MyBatis 内部的原理，这样才能编写出安全、高效的插件。
+
+## 3.3 接口层
+
+对应 `session` 模块。
+
+> 接口层相对简单，其核心是 SqlSession 接口，该接口中定义了 MyBatis 暴露给应用程序调用的 API，也就是上层应用与 MyBatis 交互的桥梁。接口层在接收到调用请求时，会调用核心处理层的相应模块来完成具体的数据库操作。
+
+## 3.4 其它层
+
+这块，严格来说，不能叫做一个层。考虑到统一，就简单这么命名把。哈哈哈。
+
+### 3.4.1 JDBC 模块
+
+对应 `jdbc` 包。
+
+JDBC **单元测试**工具类。所以，不感兴趣的同学，已经可以忽略 1236 行代码了。
+
+### 3.4.2 Lang 模块
+
+对应 `lang` 包。
+
+看不懂具体用途，暂时误会。
+
+## 3.4 总结
+
+总的来说，MyBatis 的代码，还是比较简单易懂。并且，看着包名，基本也能猜到大体的用途。在网络上找了一个总结的图，大家瞅瞅：
+
+> FROM [《mybatis 源码分析之整体架构分析》](http://zeng233.github.io/2015/08/20/2.1mybatis源码分析之前言/)
+>
+> [![模块图](03-mybatis-项目结构一览.assets/06.png)](http://static.iocoder.cn/images/MyBatis/2020_01_04/06.png)模块图
+
+# 666. 彩蛋
+
+有种，把 [《MyBatis 技术内幕》](https://item.jd.com/12125531.html) 复制了一遍的感觉。不要打我的脸。
+
+后续的文章，和 [《MyBatis 技术内幕》](https://item.jd.com/12125531.html) 一样，按照**基础支持层 => 核心处理层 => 接口层**的顺序，逐步详细解析。虽然说，艿艿也想直接开始干核心处理层，但是考虑框架是自下而上，还是一点一点来。当然，热情的胖友，也可以从核心处理层开始看，然后看到不懂的地方，回到基础支持层。
+
+如果对 MyBatis 不熟悉的胖友，推荐阅读下田小波的 [《MyBatis 源码分析系列文章导读》](https://www.tianxiaobo.com/2018/07/16/MyBatis-源码分析系列文章导读/) 。
+
+同时，也推荐阅读无忌的 [《MyBatis 源码解读之源码结构》](https://my.oschina.net/wenjinglian/blog/1625437) 。
\ No newline at end of file
diff --git a/mybatis/04-mybatis-解析器模块.assets/01.png b/mybatis/04-mybatis-解析器模块.assets/01.png
new file mode 100644
index 0000000..39bc81c
Binary files /dev/null and b/mybatis/04-mybatis-解析器模块.assets/01.png differ
diff --git a/mybatis/04-mybatis-解析器模块.assets/02.png b/mybatis/04-mybatis-解析器模块.assets/02.png
new file mode 100644
index 0000000..3b9ff18
Binary files /dev/null and b/mybatis/04-mybatis-解析器模块.assets/02.png differ
diff --git a/mybatis/04-mybatis-解析器模块.md b/mybatis/04-mybatis-解析器模块.md
new file mode 100644
index 0000000..cac55ac
--- /dev/null
+++ b/mybatis/04-mybatis-解析器模块.md
@@ -0,0 +1,743 @@
+# 精尽 MyBatis 源码分析 —— 解析器模块
+
+# 1. 概述
+
+本文，我们来分享 MyBatis 的解析器模块，对应 `parsing` 包。如下图所示：[![`parsing` 包](04-mybatis-解析器模块.assets/01.png)](http://static.iocoder.cn/images/MyBatis/2020_01_07/01.png)`parsing` 包
+
+在 [《精尽 MyBatis 源码解析 —— 项目结构一览》](http://svip.iocoder.cn/MyBatis/intro) 中，简单介绍了这个模块如下：
+
+> 解析器模块，主要提供了两个功能:
+>
+> - 一个功能，是对 [XPath](http://www.w3school.com.cn/xpath/index.asp) 进行封装，为 MyBatis 初始化时解析 `mybatis-config.xml` 配置文件以及映射配置文件提供支持。
+> - 另一个功能，是为处理动态 SQL 语句中的占位符提供支持。
+
+下面，我们就来看看具体的源码。因为 `parsing` 是基础支持层，**所以建议胖友在我们讲解到的类和方法中，打折断点一起来了解**。
+
+# 2. XPathParser
+
+`org.apache.ibatis.parsing.XPathParser` ，基于 Java **XPath** 解析器，用于解析 MyBatis `mybatis-config.xml` 和 `**Mapper.xml` 等 XML 配置文件。属性如下：
+
+```
+// XPathParser.java
+
+/**
+ * XML Document 对象
+ */
+private final Document document;
+/**
+ * 是否校验
+ */
+private boolean validation;
+/**
+ * XML 实体解析器
+ */
+private EntityResolver entityResolver;
+/**
+ * 变量 Properties 对象
+ */
+private Properties variables;
+/**
+ * Java XPath 对象
+ */
+private XPath xpath;
+```
+
+- ```
+  document
+  ```
+
+   
+
+  属性，XML 被解析后，生成的
+
+   
+
+  ```
+  org.w3c.dom.Document
+  ```
+
+   
+
+  对象。
+
+  - `validation` 属性，是否校验 XML 。一般情况下，值为 `true` 。
+
+  - ```
+    entityResolver
+    ```
+
+     
+
+    属性，
+
+    ```
+    org.xml.sax.EntityResolver
+    ```
+
+     
+
+    对象，XML 实体解析器。默认情况下，对 XML 进行校验时，会基于 XML 文档开始位置指定的 DTD 文件或 XSD 文件。例如说，解析
+
+     
+
+    ```
+    mybatis-config.xml
+    ```
+
+     
+
+    配置文件时，会加载
+
+     
+
+    ```
+    http://mybatis.org/dtd/mybatis-3-config.dtd
+    ```
+
+     
+
+    这个 DTD 文件。但是，如果每个应用启动都从网络加载该 DTD 文件，势必在弱网络下体验非常下，甚至说应用部署在无网络的环境下，还会导致下载不下来，那么就会出现 XML 校验失败的情况。所以，在实际场景下，MyBatis 自定义了 EntityResolver 的实现，达到使用
+
+    本地
+
+     
+
+    DTD 文件，从而避免下载
+
+    网络
+
+     
+
+    DTD 文件的效果。详细解析，见
+
+     
+
+    「3. XMLMapperEntityResolver」
+
+     
+
+    。
+
+    - 另外，Spring 也自定义了 EntityResolver 的实现，感兴趣的胖友，可以看看 [《【死磕 Spring】—— IoC 之获取验证模型》](http://svip.iocoder.cn/Spring/IoC-Validation-Mode-For-Resource) 。
+
+- `xpath` 属性，`javax.xml.xpath.XPath` 对象，用于查询 XML 中的节点和元素。如果对 XPath 的使用不了解的胖友，请先跳转 [《Java XPath 解析器 - 解析 XML 文档》](https://www.yiibai.com/java_xml/java_xpath_parse_document.html) 中，进行简单学习，灰常简单。
+
+- `variables` 属性，变量 Properties 对象，用来替换需要动态配置的属性值。例如：
+
+  ```
+  <dataSource type="POOLED">
+    <property name="driver" value="${driver}"/>
+    <property name="url" value="${url}"/>
+    <property name="username" value="${username}"/>
+    <property name="password" value="${password}"/>
+  </dataSource>
+  ```
+
+  - `variables` 的来源，即可以在常用的 Java Properties 文件中配置，也可以使用 MyBatis `<property />` 标签中配置。例如：
+
+    ```
+    <properties resource="org/mybatis/example/config.properties">
+      <property name="username" value="dev_user"/>
+      <property name="password" value="F2Fa3!33TYyg"/>
+    </properties>
+    ```
+
+    - 这里配置的 `username` 和 `password` 属性，就可以替换上面的 `${username}` 和 `${password}` 这两个动态属性。
+    - 具体如何实现的，我们来看下面的 `PropertyParser#parse(String string, Properties variables)` 方法。
+
+## 2.1 构造方法
+
+XPathParser 的构造方法有 16 个之多，当然基本都非常相似，我们来挑选其中一个。代码如下：
+
+```
+// XPathParser.java
+
+/**
+ * 构造 XPathParser 对象
+ *
+ * @param xml XML 文件地址
+ * @param validation 是否校验 XML
+ * @param variables 变量 Properties 对象
+ * @param entityResolver XML 实体解析器
+ */
+public XPathParser(String xml, boolean validation, Properties variables, EntityResolver entityResolver) {
+    commonConstructor(validation, variables, entityResolver);
+    this.document = createDocument(new InputSource(new StringReader(xml)));
+}
+```
+
+- 调用 `#commonConstructor(boolean validation, Properties variables, EntityResolver entityResolver)` 方法，公用的构造方法逻辑。代码如下：
+
+  ```
+  // XPathParser.java
+  
+  private void commonConstructor(boolean validation, Properties variables, EntityResolver entityResolver) {
+      this.validation = validation;
+      this.entityResolver = entityResolver;
+      this.variables = variables;
+      // 创建 XPathFactory 对象
+      XPathFactory factory = XPathFactory.newInstance();
+      this.xpath = factory.newXPath();
+  }
+  ```
+
+- 调用 `#createDocument(InputSource inputSource)` 方法，将 XML 文件解析成 Document 对象。代码如下：
+
+  ```
+  // XPathParser.java
+  
+  /**
+   * 创建 Document 对象
+   *
+   * @param inputSource XML 的 InputSource 对象
+   * @return Document 对象
+   */
+  private Document createDocument(InputSource inputSource) {
+      // important: this must only be called AFTER common constructor
+      try {
+          // 1> 创建 DocumentBuilderFactory 对象
+          DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
+          factory.setValidating(validation); // 设置是否验证 XML
+  
+          factory.setNamespaceAware(false);
+          factory.setIgnoringComments(true);
+          factory.setIgnoringElementContentWhitespace(false);
+          factory.setCoalescing(false);
+          factory.setExpandEntityReferences(true);
+  
+          // 2> 创建 DocumentBuilder 对象
+          DocumentBuilder builder = factory.newDocumentBuilder();
+          builder.setEntityResolver(entityResolver); // 设置实体解析器
+          builder.setErrorHandler(new ErrorHandler() { // 实现都空的
+  
+              @Override
+              public void error(SAXParseException exception) throws SAXException {
+                  throw exception;
+              }
+  
+              @Override
+              public void fatalError(SAXParseException exception) throws SAXException {
+                  throw exception;
+              }
+  
+              @Override
+              public void warning(SAXParseException exception) throws SAXException {
+              }
+  
+          });
+          // 3> 解析 XML 文件
+          return builder.parse(inputSource);
+      } catch (Exception e) {
+          throw new BuilderException("Error creating document instance.  Cause: " + e, e);
+      }
+  }
+  ```
+
+  - 就是简单的 Java XML API 的使用，不了解的胖友，可以 Google 学习下。
+
+## 2.2 eval 方法族
+
+XPathParser 提供了一系列的 `#eval*` 方法，用于获得 Boolean、Short、Integer、Long、Float、Double、String、Node 类型的元素或节点的“值”。当然，虽然方法很多，但是都是基于 `#evaluate(String expression, Object root, QName returnType)` 方法，代码如下：
+
+```
+// XPathParser.java
+
+/**
+ * 获得指定元素或节点的值
+ *
+ * @param expression 表达式
+ * @param root 指定节点
+ * @param returnType 返回类型
+ * @return 值
+ */
+private Object evaluate(String expression, Object root, QName returnType) {
+    try {
+        return xpath.evaluate(expression, root, returnType);
+    } catch (Exception e) {
+        throw new BuilderException("Error evaluating XPath.  Cause: " + e, e);
+    }
+}
+```
+
+- 调用 `xpath` 的 `evaluate(String expression, Object root, QName returnType)` 方法，获得指定元素或节点的值。
+
+### 2.2.1 eval 元素
+
+eval 元素的方法，用于获得 Boolean、Short、Integer、Long、Float、Double、String 类型的**元素**的值。我们以 `#evalString(Object root, String expression)` 方法为例子，代码如下：
+
+```
+// XPathParser.java
+
+public String evalString(Object root, String expression) {
+    // <1> 获得值
+    String result = (String) evaluate(expression, root, XPathConstants.STRING);
+    // <2> 基于 variables 替换动态值，如果 result 为动态值
+    result = PropertyParser.parse(result, variables);
+    return result;
+}
+```
+
+- `<1>` 处，调用 `#evaluate(String expression, Object root, QName returnType)` 方法，获得值。其中，`returnType` 方法传入的是 `XPathConstants.STRING` ，表示返回的值是 String 类型。
+- `<2>` 处，调用 `PropertyParser#parse(String string, Properties variables)` 方法，基于 `variables` 替换**动态值**，如果 `result` 为**动态值**。这就是 MyBatis 如何替换掉 XML 中的动态值实现的方式。关于 PropertyParser ，我们会在 [「5. PropertyParser」](https://svip.iocoder.cn/MyBatis/parsing-package/#) 详细解析。
+
+### 2.2.2 eval 节点
+
+eval 元素的方法，用于获得 Node 类型的**节点**的值。代码如下：
+
+```
+// XPathParser.java
+
+public List<XNode> evalNodes(String expression) { // Node 数组
+    return evalNodes(document, expression);
+}
+
+public List<XNode> evalNodes(Object root, String expression) { // Node 数组
+    // <1> 获得 Node 数组
+    NodeList nodes = (NodeList) evaluate(expression, root, XPathConstants.NODESET);
+    // <2> 封装成 XNode 数组
+    List<XNode> xnodes = new ArrayList<>();
+    for (int i = 0; i < nodes.getLength(); i++) {
+        xnodes.add(new XNode(this, nodes.item(i), variables));
+    }
+    return xnodes;
+}
+
+public XNode evalNode(String expression) { // Node 对象
+    return evalNode(document, expression);
+}
+
+public XNode evalNode(Object root, String expression) { // Node 对象
+    // <1> 获得 Node 对象
+    Node node = (Node) evaluate(expression, root, XPathConstants.NODE);
+    if (node == null) {
+        return null;
+    }
+    // <2> 封装成 XNode 对象
+    return new XNode(this, node, variables);
+}
+```
+
+- `<1>` 处，返回结果有 Node **对象**和**数组**两种情况，根据方法参数 `expression` 需要获取的节点不同。
+
+- `<2>` 处， 最终结果会将 Node 封装成 `org.apache.ibatis.parsing.XNode` 对象，主要为了**动态值的替换**。例如：
+
+  ```
+  // XNode.java
+  
+  public String evalString(String expression) {
+      return xpathParser.evalString(node, expression);
+  }
+  ```
+
+  - 其它方法，就不详细解析。感兴趣的胖友，可以自己翻翻。
+
+# 3. XMLMapperEntityResolver
+
+`org.apache.ibatis.builder.xml.XMLMapperEntityResolver` ，实现 EntityResolver 接口，MyBatis 自定义 EntityResolver 实现类，用于加载本地的 `mybatis-3-config.dtd` 和 `mybatis-3-mapper.dtd` 这两个 DTD 文件。代码如下：
+
+```
+// XMLMapperEntityResolver.java
+
+public class XMLMapperEntityResolver implements EntityResolver {
+
+    private static final String IBATIS_CONFIG_SYSTEM = "ibatis-3-config.dtd";
+    private static final String IBATIS_MAPPER_SYSTEM = "ibatis-3-mapper.dtd";
+    private static final String MYBATIS_CONFIG_SYSTEM = "mybatis-3-config.dtd";
+    private static final String MYBATIS_MAPPER_SYSTEM = "mybatis-3-mapper.dtd";
+
+    /**
+     * 本地 mybatis-config.dtd 文件
+     */
+    private static final String MYBATIS_CONFIG_DTD = "org/apache/ibatis/builder/xml/mybatis-3-config.dtd";
+    /**
+     * 本地 mybatis-mapper.dtd 文件
+     */
+    private static final String MYBATIS_MAPPER_DTD = "org/apache/ibatis/builder/xml/mybatis-3-mapper.dtd";
+
+    /**
+     * Converts a public DTD into a local one
+     *
+     * @param publicId The public id that is what comes after "PUBLIC"
+     * @param systemId The system id that is what comes after the public id.
+     * @return The InputSource for the DTD
+     *
+     * @throws org.xml.sax.SAXException If anything goes wrong
+     */
+    @Override
+    public InputSource resolveEntity(String publicId, String systemId) throws SAXException {
+        try {
+            if (systemId != null) {
+                String lowerCaseSystemId = systemId.toLowerCase(Locale.ENGLISH);
+                // 本地 mybatis-config.dtd 文件
+                if (lowerCaseSystemId.contains(MYBATIS_CONFIG_SYSTEM) || lowerCaseSystemId.contains(IBATIS_CONFIG_SYSTEM)) {
+                    return getInputSource(MYBATIS_CONFIG_DTD, publicId, systemId);
+                // 本地 mybatis-mapper.dtd 文件
+                } else if (lowerCaseSystemId.contains(MYBATIS_MAPPER_SYSTEM) || lowerCaseSystemId.contains(IBATIS_MAPPER_SYSTEM)) {
+                    return getInputSource(MYBATIS_MAPPER_DTD, publicId, systemId);
+                }
+            }
+            return null;
+        } catch (Exception e) {
+            throw new SAXException(e.toString());
+        }
+    }
+
+    private InputSource getInputSource(String path, String publicId, String systemId) {
+        InputSource source = null;
+        if (path != null) {
+            try {
+                // 创建 InputSource 对象
+                InputStream in = Resources.getResourceAsStream(path);
+                source = new InputSource(in);
+                // 设置  publicId、systemId 属性
+                source.setPublicId(publicId);
+                source.setSystemId(systemId);
+            } catch (IOException e) {
+                // ignore, null is ok
+            }
+        }
+        return source;
+    }
+
+}
+```
+
+- 代码比较简单，胖友自己瞅瞅哈。
+
+# 4. GenericTokenParser
+
+`org.apache.ibatis.parsing.GenericTokenParser` ，**通用**的 Token 解析器。代码如下：
+
+```
+// GenericTokenParser.java
+
+public class GenericTokenParser {
+
+    /**
+     * 开始的 Token 字符串
+     */
+    private final String openToken;
+    /**
+     * 结束的 Token 字符串
+     */
+    private final String closeToken;
+    private final TokenHandler handler;
+
+    public GenericTokenParser(String openToken, String closeToken, TokenHandler handler) {
+        this.openToken = openToken;
+        this.closeToken = closeToken;
+        this.handler = handler;
+    }
+
+    public String parse(String text) {
+        if (text == null || text.isEmpty()) {
+            return "";
+        }
+        // search open token
+        // 寻找开始的 openToken 的位置
+        int start = text.indexOf(openToken, 0);
+        if (start == -1) { // 找不到，直接返回
+            return text;
+        }
+        char[] src = text.toCharArray();
+        int offset = 0; // 起始查找位置
+        // 结果
+        final StringBuilder builder = new StringBuilder();
+        StringBuilder expression = null; // 匹配到 openToken 和 closeToken 之间的表达式
+        // 循环匹配
+        while (start > -1) {
+            // 转义字符
+            if (start > 0 && src[start - 1] == '\\') {
+                // this open token is escaped. remove the backslash and continue.
+                // 因为 openToken 前面一个位置是 \ 转义字符，所以忽略 \
+                // 添加 [offset, start - offset - 1] 和 openToken 的内容，添加到 builder 中
+                builder.append(src, offset, start - offset - 1).append(openToken);
+                // 修改 offset
+                offset = start + openToken.length();
+            // 非转义字符
+            } else {
+                // found open token. let's search close token.
+                // 创建/重置 expression 对象
+                if (expression == null) {
+                    expression = new StringBuilder();
+                } else {
+                    expression.setLength(0);
+                }
+                // 添加 offset 和 openToken 之间的内容，添加到 builder 中
+                builder.append(src, offset, start - offset);
+                // 修改 offset
+                offset = start + openToken.length();
+                // 寻找结束的 closeToken 的位置
+                int end = text.indexOf(closeToken, offset);
+                while (end > -1) {
+                    // 转义
+                    if (end > offset && src[end - 1] == '\\') {
+                        // this close token is escaped. remove the backslash and continue.
+                        // 因为 endToken 前面一个位置是 \ 转义字符，所以忽略 \
+                        // 添加 [offset, end - offset - 1] 和 endToken 的内容，添加到 builder 中
+                        expression.append(src, offset, end - offset - 1).append(closeToken);
+                        // 修改 offset
+                        offset = end + closeToken.length();
+                        // 继续，寻找结束的 closeToken 的位置
+                        end = text.indexOf(closeToken, offset);
+                    // 非转义
+                    } else {
+                        // 添加 [offset, end - offset] 的内容，添加到 builder 中
+                        expression.append(src, offset, end - offset);
+                        break;
+                    }
+                }
+                // 拼接内容
+                if (end == -1) {
+                    // close token was not found.
+                    // closeToken 未找到，直接拼接
+                    builder.append(src, start, src.length - start);
+                    // 修改 offset
+                    offset = src.length;
+                } else {
+                    // <x> closeToken 找到，将 expression 提交给 handler 处理 ，并将处理结果添加到 builder 中
+                    builder.append(handler.handleToken(expression.toString()));
+                    // 修改 offset
+                    offset = end + closeToken.length();
+                }
+            }
+            // 继续，寻找开始的 openToken 的位置
+            start = text.indexOf(openToken, offset);
+        }
+        // 拼接剩余的部分
+        if (offset < src.length) {
+            builder.append(src, offset, src.length - offset);
+        }
+        return builder.toString();
+    }
+
+}
+```
+
+- 代码看起来好冗长，但是淡定，就一个 `#parse(String text)` 方法，**循环**( 因为可能不只一个 )，解析以 `openToken` 开始，以 `closeToken` 结束的 Token ，并提交给 `handler` 进行处理，即 `<x>` 处。
+- 所以所以所以，胖友可以耐心看下这段逻辑，也可以忽略，大体理解就好。
+- 关于 `handler` 这个 TokenHandler ，详细见 [「5. TokenHandler」](https://svip.iocoder.cn/MyBatis/parsing-package/#) 。当然，这也是为什么 GenericTokenParser 叫做**通用**的原因，而 TokenHandler 处理**特定**的逻辑。
+
+# 5. PropertyParser
+
+`org.apache.ibatis.parsing.PropertyParser` ，动态属性解析器。代码如下：
+
+```
+// PropertyParser.java
+
+public class PropertyParser {
+
+    // ... 省略部分无关的
+
+    private PropertyParser() { // <1>
+        // Prevent Instantiation
+    }
+
+    public static String parse(String string, Properties variables) { // <2>
+        // <2.1> 创建 VariableTokenHandler 对象
+        VariableTokenHandler handler = new VariableTokenHandler(variables);
+        // <2.2> 创建 GenericTokenParser 对象
+        GenericTokenParser parser = new GenericTokenParser("${", "}", handler);
+        // <2.3> 执行解析
+        return parser.parse(string);
+    }
+    
+}
+```
+
+- `<1>` ，构造方法，修饰符为 `private` ，禁止构造 PropertyParser 对象，因为它是一个静态方法的工具类。
+
+- ```
+  <2>
+  ```
+
+   
+
+  ，基于
+
+   
+
+  ```
+  variables
+  ```
+
+   
+
+  变量，替换
+
+   
+
+  ```
+  string
+  ```
+
+   
+
+  字符串中的动态属性，并返回结果。
+
+  - `<2.1>` ，创建 VariableTokenHandler 对象。
+
+  - ```
+    <2.2>
+    ```
+
+     
+
+    ，创建 GenericTokenParser 对象。
+
+    - 我们可以看到，`openToken = {` ，`closeToken = }` ，这不就是上面看到的 `${username}` 和 `{password}` 的么。
+    - 同时，我们也可以看到，`handler` 类型为 VariableTokenHandler ，也就是说，通过它实现**自定义**的处理逻辑。关于它，在 [「6.1 VariableTokenHandler」](https://svip.iocoder.cn/MyBatis/parsing-package/#) 中详细解析。
+
+  - `<2.3>` ，调用 `GenericTokenParser#parse(String text)` 方法，执行解析。
+
+# 6. TokenHandler
+
+`org.apache.ibatis.parsing.TokenHandler` ，Token 处理器接口。代码如下：
+
+```
+// TokenHandler.java
+
+public interface TokenHandler {
+
+    /**
+     * 处理 Token
+     *
+     * @param content Token 字符串
+     * @return 处理后的结果
+     */
+    String handleToken(String content);
+
+}
+```
+
+- `#handleToken(String content)` 方法，处理 Token ，在 [「4. GenericTokenParser」](https://svip.iocoder.cn/MyBatis/parsing-package/#) 中，我们已经看到它的调用了。
+
+TokenHandler 有四个子类实现，如下图所示：[![TokenHandler 子类](04-mybatis-解析器模块.assets/02.png)](http://static.iocoder.cn/images/MyBatis/2020_01_07/02.png)TokenHandler 子类
+
+- 本文暂时只解析 VariableTokenHandler 类，因为只有它在 `parsing` 包中，和解析器模块相关。
+
+## 6.1 VariableTokenHandler
+
+VariableTokenHandler ，是 PropertyParser 的内部静态类，变量 Token 处理器。具体什么用途？上面不是已经整的明明白白啦，就不重复解释啦。
+
+### 6.1.1 构造方法
+
+```
+// PropertyParser.java
+
+private static final String KEY_PREFIX = "org.apache.ibatis.parsing.PropertyParser.";
+/**
+ * The special property key that indicate whether enable a default value on placeholder.
+ * <p>
+ *   The default value is {@code false} (indicate disable a default value on placeholder)
+ *   If you specify the {@code true}, you can specify key and default value on placeholder (e.g. {@code ${db.username:postgres}}).
+ * </p>
+ * @since 3.4.2
+ */
+public static final String KEY_ENABLE_DEFAULT_VALUE = KEY_PREFIX + "enable-default-value";
+
+/**
+ * The special property key that specify a separator for key and default value on placeholder.
+ * <p>
+ *   The default separator is {@code ":"}.
+ * </p>
+ * @since 3.4.2
+ */
+public static final String KEY_DEFAULT_VALUE_SEPARATOR = KEY_PREFIX + "default-value-separator";
+
+private static final String ENABLE_DEFAULT_VALUE = "false";
+private static final String DEFAULT_VALUE_SEPARATOR = ":";
+
+// VariableTokenHandler 类里
+
+/**
+ * 变量 Properties 对象
+ */
+private final Properties variables;
+/**
+ * 是否开启默认值功能。默认为 {@link #ENABLE_DEFAULT_VALUE}
+ */
+private final boolean enableDefaultValue;
+/**
+ * 默认值的分隔符。默认为 {@link #KEY_DEFAULT_VALUE_SEPARATOR} ，即 ":" 。
+ */
+private final String defaultValueSeparator;
+
+private VariableTokenHandler(Properties variables) {
+    this.variables = variables;
+    this.enableDefaultValue = Boolean.parseBoolean(getPropertyValue(KEY_ENABLE_DEFAULT_VALUE, ENABLE_DEFAULT_VALUE));
+    this.defaultValueSeparator = getPropertyValue(KEY_DEFAULT_VALUE_SEPARATOR, DEFAULT_VALUE_SEPARATOR);
+}
+
+private String getPropertyValue(String key, String defaultValue) {
+    return (variables == null) ? defaultValue : variables.getProperty(key, defaultValue);
+}
+```
+
+- 虽然看起来有一大坨的变量，但是不要怕。
+
+- `variables` 属性，变量 Properties 对象。
+
+- `enableDefaultValue` 属性，是否开启默认值功能。默认为 `ENABLE_DEFAULT_VALUE` ，即**不开启**。想要开启，可以配置如下：
+
+  ```
+  <properties resource="org/mybatis/example/config.properties">
+    <!-- ... -->
+    <property name="org.apache.ibatis.parsing.PropertyParser.enable-default-value" value="true"/> <!-- Enable this feature -->
+  </properties>
+  ```
+
+- `defaultValueSeparator` 属性，默认值的分隔符。默认为 `KEY_DEFAULT_VALUE_SEPARATOR` ，即 `":"` 。想要修改，可以配置如下：
+
+  ```
+  <properties resource="org/mybatis/example/config.properties">
+    <!-- ... -->
+    <property name="org.apache.ibatis.parsing.PropertyParser.default-value-separator" value="?:"/> <!-- Change default value of separator -->
+  </properties>
+  ```
+
+  - 分隔符被修改成了 `?:` 。
+
+### 6.1.2 handleToken
+
+```
+// VariableTokenHandler 类里
+
+@Override
+public String handleToken(String content) {
+    if (variables != null) {
+        String key = content;
+        // 开启默认值功能
+        if (enableDefaultValue) {
+            // 查找默认值
+            final int separatorIndex = content.indexOf(defaultValueSeparator);
+            String defaultValue = null;
+            if (separatorIndex >= 0) {
+                key = content.substring(0, separatorIndex);
+                defaultValue = content.substring(separatorIndex + defaultValueSeparator.length());
+            }
+            // 有默认值，优先替换，不存在则返回默认值
+            if (defaultValue != null) {
+                return variables.getProperty(key, defaultValue);
+            }
+        }
+        // 未开启默认值功能，直接替换
+        if (variables.containsKey(key)) {
+            return variables.getProperty(key);
+        }
+    }
+    // 无 variables ，直接返回
+    return "${" + content + "}";
+}
+```
+
+- 比较简单，胖友自己看。
+
+# 666. 彩蛋
+
+小文一篇。按照前面的代码统计，我们已经看掉了小 1000 行的代码了。继续搞起。
+
+参考和推荐如下文章：
+
+- 徐郡明 [《MyBatis 技术内幕》](https://item.jd.com/12125531.html) 的 [「2.1 解析器模块」](https://svip.iocoder.cn/MyBatis/parsing-package/#) 小节
+- 祖大俊 [《Mybatis3.3.x技术内幕（七）：Mybatis初始化之六个工具》](https://my.oschina.net/zudajun/blog/668596)
\ No newline at end of file
diff --git a/mybatis/05-mybatis-反射模块.assets/01.png b/mybatis/05-mybatis-反射模块.assets/01.png
new file mode 100644
index 0000000..42f55cf
Binary files /dev/null and b/mybatis/05-mybatis-反射模块.assets/01.png differ
diff --git a/mybatis/05-mybatis-反射模块.assets/02.png b/mybatis/05-mybatis-反射模块.assets/02.png
new file mode 100644
index 0000000..a1fe985
Binary files /dev/null and b/mybatis/05-mybatis-反射模块.assets/02.png differ
diff --git a/mybatis/05-mybatis-反射模块.md b/mybatis/05-mybatis-反射模块.md
new file mode 100644
index 0000000..cbe0a85
--- /dev/null
+++ b/mybatis/05-mybatis-反射模块.md
@@ -0,0 +1,3151 @@
+# 精尽 MyBatis 源码分析 —— 反射模块
+
+# 1. 概述
+
+本文，我们来分享 MyBatis 的反射模块，对应 `reflection` 包。如下图所示：[![`reflection` 包](05-mybatis-反射模块.assets/01.png)](http://static.iocoder.cn/images/MyBatis/2020_01_10/01.png)`reflection` 包
+
+- 相比 `parsing` 包来说，`reflection` 包的代码量大概是 2-3 倍。当然，不要慌，都是比较简单的代码。
+- 当然，这是一篇非常非常非常长的博客，因为笔者基本贴了这个模块所有的代码。**如果想要比较好的理解这个模块，胖友一定要基于 MyBatis 提供的这个模块的单元测试，多多调试**。
+
+在 [《精尽 MyBatis 源码解析 —— 项目结构一览》](http://svip.iocoder.cn/MyBatis/intro) 中，简单介绍了这个模块如下：
+
+> Java 中的反射虽然功能强大，但对大多数开发人员来说，写出高质量的反射代码还是 有一定难度的。MyBatis 中专门提供了反射模块，该模块对 Java 原生的反射进行了良好的封装，提了更加**简洁易用的 API**，方便上层使调用，并且对**反射操作进行了一系列优化**，例如缓存了类的元数据，提高了反射操作的性能。
+
+下面，我们就来看看具体的源码。因为 `reflection` 是基础支持层，**所以建议胖友在我们讲解到的类和方法中，打折断点一起来了解**。
+
+# 2. Reflector
+
+`org.apache.ibatis.reflection.Reflector` ，反射器，每个 Reflector 对应一个类。Reflector 会缓存反射操作需要的类的信息，例如：构造方法、属性名、setting / getting 方法等等。代码如下：
+
+```
+// Reflector.java
+
+public class Reflector {
+
+    /**
+     * 对应的类
+     */
+    private final Class<?> type;
+    /**
+     * 可读属性数组
+     */
+    private final String[] readablePropertyNames;
+    /**
+     * 可写属性集合
+     */
+    private final String[] writeablePropertyNames;
+    /**
+     * 属性对应的 setting 方法的映射。
+     *
+     * key 为属性名称
+     * value 为 Invoker 对象
+     */
+    private final Map<String, Invoker> setMethods = new HashMap<>();
+    /**
+     * 属性对应的 getting 方法的映射。
+     *
+     * key 为属性名称
+     * value 为 Invoker 对象
+     */
+    private final Map<String, Invoker> getMethods = new HashMap<>();
+    /**
+     * 属性对应的 setting 方法的方法参数类型的映射。{@link #setMethods}
+     *
+     * key 为属性名称
+     * value 为方法参数类型
+     */
+    private final Map<String, Class<?>> setTypes = new HashMap<>();
+    /**
+     * 属性对应的 getting 方法的返回值类型的映射。{@link #getMethods}
+     *
+     * key 为属性名称
+     * value 为返回值的类型
+     */
+    private final Map<String, Class<?>> getTypes = new HashMap<>();
+    /**
+     * 默认构造方法
+     */
+    private Constructor<?> defaultConstructor;
+    /**
+     * 不区分大小写的属性集合
+     */
+    private Map<String, String> caseInsensitivePropertyMap = new HashMap<>();
+
+    public Reflector(Class<?> clazz) {
+        // 设置对应的类
+        type = clazz;
+        // <1> 初始化 defaultConstructor
+        addDefaultConstructor(clazz);
+        // <2> // 初始化 getMethods 和 getTypes ，通过遍历 getting 方法
+        addGetMethods(clazz);
+        // <3> // 初始化 setMethods 和 setTypes ，通过遍历 setting 方法。
+        addSetMethods(clazz);
+        // <4> // 初始化 getMethods + getTypes 和 setMethods + setTypes ，通过遍历 fields 属性。
+        addFields(clazz);
+        // <5> 初始化 readablePropertyNames、writeablePropertyNames、caseInsensitivePropertyMap 属性
+        readablePropertyNames = getMethods.keySet().toArray(new String[getMethods.keySet().size()]);
+        writeablePropertyNames = setMethods.keySet().toArray(new String[setMethods.keySet().size()]);
+        for (String propName : readablePropertyNames) {
+            caseInsensitivePropertyMap.put(propName.toUpperCase(Locale.ENGLISH), propName);
+        }
+        for (String propName : writeablePropertyNames) {
+            caseInsensitivePropertyMap.put(propName.toUpperCase(Locale.ENGLISH), propName);
+        }
+    }
+
+    // ... 省略一些方法
+}
+```
+
+- `type` 属性，每个 Reflector 对应的类。
+- `defaultConstructor` 属性，默认**无参**构造方法。在 `<1>` 处初始化，详细解析，见 [「2.1 addDefaultConstructor」](https://svip.iocoder.cn/MyBatis/reflection-package/#) 。
+- `getMethods`、`getTypes` 属性，分别为属性对应的 **getting 方法**、**getting 方法的返回类型**的映射。在 `<2>` 处初始化，详细解析，见 [「2.2 addGetMethods」](https://svip.iocoder.cn/MyBatis/reflection-package/#) 。
+- `setMethods`、`setTypes` 属性，分别为属性对应的 **setting 方法**、**setting 方法的参数类型**的映射。在 `<3>` 处初始化，详细解析，见 [「2.3 addSetMethods」](https://svip.iocoder.cn/MyBatis/reflection-package/#) 。
+- `<4>` 处，初始化 `getMethods` + `getTypes` 和 `setMethods` + `setTypes` ，通过遍历 fields 属性。详细解析，见 [「2.4 addFields」](https://svip.iocoder.cn/MyBatis/reflection-package/#) 。
+- `<5>` 处，初始化 `readablePropertyNames`、`writeablePropertyNames`、`caseInsensitivePropertyMap` 属性。
+
+## 2.1 addDefaultConstructor
+
+`#addDefaultConstructor(Class<?> clazz)` 方法，查找默认无参构造方法。代码如下：
+
+```
+// Reflector.java
+
+private void addDefaultConstructor(Class<?> clazz) {
+    // 获得所有构造方法
+    Constructor<?>[] consts = clazz.getDeclaredConstructors();
+    // 遍历所有构造方法，查找无参的构造方法
+    for (Constructor<?> constructor : consts) {
+        // 判断无参的构造方法
+        if (constructor.getParameterTypes().length == 0) {
+            // 设置构造方法可以访问，避免是 private 等修饰符
+            if (canControlMemberAccessible()) {
+                try {
+                    constructor.setAccessible(true);
+                } catch (Exception e) {
+                    // Ignored. This is only a final precaution, nothing we can do.
+                }
+            }
+            // 如果构造方法可以访问，赋值给 defaultConstructor
+            if (constructor.isAccessible()) {
+                this.defaultConstructor = constructor;
+            }
+        }
+    }
+}
+
+/**
+ * Checks whether can control member accessible.
+ *
+ * 判断，是否可以修改可访问性
+ *
+ * @return If can control member accessible, it return {@literal true}
+ * @since 3.5.0
+ */
+public static boolean canControlMemberAccessible() {
+    try {
+        SecurityManager securityManager = System.getSecurityManager();
+        if (null != securityManager) {
+            securityManager.checkPermission(new ReflectPermission("suppressAccessChecks"));
+        }
+    } catch (SecurityException e) {
+        return false;
+    }
+    return true;
+}
+```
+
+## 2.2 addGetMethods
+
+`#addGetMethods(Class<?> cls)` 方法，初始化 `getMethods` 和 `getTypes` ，通过遍历 getting 方法。代码如下：
+
+```
+// Reflector.java
+
+private void addGetMethods(Class<?> cls) {
+    // <1> 属性与其 getting 方法的映射。
+    Map<String, List<Method>> conflictingGetters = new HashMap<>();
+    // <2> 获得所有方法
+    Method[] methods = getClassMethods(cls);
+    // <3> 遍历所有方法
+    for (Method method : methods) {
+        // <3.1> 参数大于 0 ，说明不是 getting 方法，忽略
+        if (method.getParameterTypes().length > 0) {
+            continue;
+        }
+        // <3.2> 以 get 和 is 方法名开头，说明是 getting 方法
+        String name = method.getName();
+        if ((name.startsWith("get") && name.length() > 3)
+                || (name.startsWith("is") && name.length() > 2)) {
+            // <3.3> 获得属性
+            name = PropertyNamer.methodToProperty(name);
+            // <3.4> 添加到 conflictingGetters 中
+            addMethodConflict(conflictingGetters, name, method);
+        }
+    }
+    // <4> 解决 getting 冲突方法
+    resolveGetterConflicts(conflictingGetters);
+}
+```
+
+- `<1>` 处，`conflictingGetters` 变量，属性与其 getting 方法的映射。因为父类和子类都可能定义了相同属性的 getting 方法，所以 `VALUE` 会是个数组。
+
+- `<2>` 处，调用 `#getClassMethods(Class<?> cls)` 方法，获得所有方法。详细解析，见 [「2.2.1 getClassMethods」](https://svip.iocoder.cn/MyBatis/reflection-package/#) 。
+
+- `<3>` 处，遍历所有方法，挑选符合的 getting 方法，添加到 `conflictingGetters` 中。
+
+  - `<3.1>` 处，方法参数大于 0 ，说明不是 getting 方法，忽略。
+
+  - `<3.2>` 处，方法名以 get 和 is 方法名开头，说明是 getting 方法。
+
+  - `<3.3>` 处，调用 `PropertyNamer#methodToProperty(String name)` 方法，获得属性名。详细解析，见 [「6.3 PropertyNamer」](https://svip.iocoder.cn/MyBatis/reflection-package/#) 。
+
+  - `<3.4>` 处，调用 `#addMethodConflict(Map<String, List<Method>> conflictingMethods, String name, Method method)` 方法，添加到 `conflictingGetters` 中。代码如下：
+
+    ```
+    // Reflector.java
+    
+    private void addMethodConflict(Map<String, List<Method>> conflictingMethods, String name, Method method) {
+        List<Method> list = conflictingMethods.computeIfAbsent(name, k -> new ArrayList<>());
+        list.add(method);
+    }
+    ```
+
+    - JDK8 编写这样的逻辑，真心方便。
+
+- `<4>` 处，调用 `#resolveGetterConflicts(Map<String, List<Method>>)` 方法，解决 getting 冲突方法。详细解析，见 [「2.2.2 resolveGetterConflicts」](https://svip.iocoder.cn/MyBatis/reflection-package/#) 。
+
+### 2.2.1 getClassMethods
+
+`#getClassMethods(Class<?> cls)` 方法，获得所有方法。代码如下：
+
+```
+// Reflector.java
+
+private Method[] getClassMethods(Class<?> cls) {
+    // 每个方法签名与该方法的映射
+    Map<String, Method> uniqueMethods = new HashMap<>();
+    // 循环类，类的父类，类的父类的父类，直到父类为 Object
+    Class<?> currentClass = cls;
+    while (currentClass != null && currentClass != Object.class) {
+        // <1> 记录当前类定义的方法
+        addUniqueMethods(uniqueMethods, currentClass.getDeclaredMethods());
+
+        // we also need to look for interface methods -
+        // because the class may be abstract
+        // <2> 记录接口中定义的方法
+        Class<?>[] interfaces = currentClass.getInterfaces();
+        for (Class<?> anInterface : interfaces) {
+            addUniqueMethods(uniqueMethods, anInterface.getMethods());
+        }
+
+        // 获得父类
+        currentClass = currentClass.getSuperclass();
+    }
+
+    // 转换成 Method 数组返回
+    Collection<Method> methods = uniqueMethods.values();
+    return methods.toArray(new Method[methods.size()]);
+}
+```
+
+- 代码比较简单，胖友自己看注释。
+
+- `<1>` 和 `<2>` 处，会调用 `#addUniqueMethods(Map<String, Method> uniqueMethods, Method[] methods)` 方法，添加方法数组到 `uniqueMethods` 中。代码如下：
+
+  ```
+  // Reflector.java
+  
+  private void addUniqueMethods(Map<String, Method> uniqueMethods, Method[] methods) {
+      for (Method currentMethod : methods) {
+          if (!currentMethod.isBridge()) { // 忽略 bridge 方法，参见 https://www.zhihu.com/question/54895701/answer/141623158 文章
+              // <3> 获得方法签名
+              String signature = getSignature(currentMethod);
+              // check to see if the method is already known
+              // if it is known, then an extended class must have
+              // overridden a method
+              // 当 uniqueMethods 不存在时，进行添加
+              if (!uniqueMethods.containsKey(signature)) {
+                  // 设置方法可访问
+                  if (canControlMemberAccessible()) {
+                      try {
+                          currentMethod.setAccessible(true);
+                      } catch (Exception e) {
+                          // Ignored. This is only a final precaution, nothing we can do.
+                      }
+                  }
+                  // 添加到 uniqueMethods 中
+                  uniqueMethods.put(signature, currentMethod);
+              }
+          }
+      }
+  }
+  ```
+
+  - `<3>` 处，会调用 `#getSignature(Method method)` 方法，获得方法签名。代码如下：
+
+    ```
+    // Reflector.java
+    
+    private String getSignature(Method method) {
+        StringBuilder sb = new StringBuilder();
+        // 返回类型
+        Class<?> returnType = method.getReturnType();
+        if (returnType != null) {
+            sb.append(returnType.getName()).append('#');
+        }
+        // 方法名
+        sb.append(method.getName());
+        // 方法参数
+        Class<?>[] parameters = method.getParameterTypes();
+        for (int i = 0; i < parameters.length; i++) {
+            if (i == 0) {
+                sb.append(':');
+            } else {
+                sb.append(',');
+            }
+            sb.append(parameters[i].getName());
+        }
+        return sb.toString();
+    }
+    ```
+
+    - 格式：`returnType#方法名:参数名1,参数名2,参数名3` 。
+    - 例如：`void#checkPackageAccess:java.lang.ClassLoader,boolean` 。
+
+### 2.2.2 resolveGetterConflicts
+
+`#resolveGetterConflicts(Map<String, List<Method>>)` 方法，解决 getting 冲突方法。最终，一个属性，只保留一个对应的方法。代码如下：
+
+```
+// Reflector.java
+
+private void resolveGetterConflicts(Map<String, List<Method>> conflictingGetters) {
+    // 遍历每个属性，查找其最匹配的方法。因为子类可以覆写父类的方法，所以一个属性，可能对应多个 getting 方法
+    for (Entry<String, List<Method>> entry : conflictingGetters.entrySet()) {
+        Method winner = null; // 最匹配的方法
+        String propName = entry.getKey();
+        for (Method candidate : entry.getValue()) {
+            // winner 为空，说明 candidate 为最匹配的方法
+            if (winner == null) {
+                winner = candidate;
+                continue;
+            }
+            // <1> 基于返回类型比较
+            Class<?> winnerType = winner.getReturnType();
+            Class<?> candidateType = candidate.getReturnType();
+            // 类型相同
+            if (candidateType.equals(winnerType)) {
+                // 返回值了诶选哪个相同，应该在 getClassMethods 方法中，已经合并。所以抛出 ReflectionException 异常
+                if (!boolean.class.equals(candidateType)) {
+                    throw new ReflectionException(
+                            "Illegal overloaded getter method with ambiguous type for property "
+                                    + propName + " in class " + winner.getDeclaringClass()
+                                    + ". This breaks the JavaBeans specification and can cause unpredictable results.");
+                // 选择 boolean 类型的 is 方法
+                } else if (candidate.getName().startsWith("is")) {
+                    winner = candidate;
+                }
+            // 不符合选择子类
+            } else if (candidateType.isAssignableFrom(winnerType)) {
+                // OK getter type is descendant
+            // <1.1> 符合选择子类。因为子类可以修改放大返回值。例如，父类的一个方法的返回值为 List ，子类对该方法的返回值可以覆写为 ArrayList 。
+            } else if (winnerType.isAssignableFrom(candidateType)) {
+                winner = candidate;
+            // <1.2> 返回类型冲突，抛出 ReflectionException 异常
+            } else {
+                throw new ReflectionException(
+                        "Illegal overloaded getter method with ambiguous type for property "
+                                + propName + " in class " + winner.getDeclaringClass()
+                                + ". This breaks the JavaBeans specification and can cause unpredictable results.");
+            }
+        }
+        // <2> 添加到 getMethods 和 getTypes 中
+        addGetMethod(propName, winner);
+    }
+}
+```
+
+- 总体比较简单，胖友自己瞅瞅。我们只说两个关键点哈。
+
+- `<1>` 处，基于返回类型比较。重点在 `<1.1>` 和 `<1.2>` 的情况，因为子类可以修改放大返回值，**所以在出现这个情况时，选择子类的该方法**。例如，父类的一个方法的返回值为 List ，子类对该方法的返回值可以覆写为 ArrayList 。代码如下：
+
+  ```
+  public class A {
+  
+      List<String> getXXXX();
+  
+  }
+  
+  public class B extends A {
+  
+      ArrayList<String> getXXXX(); // 选择它
+  
+  }
+  ```
+
+- `<2>` 处，调用 `#addGetMethod(String name, Method method)` 方法，添加方法到 `getMethods` 和 `getTypes` 中。代码如下：
+
+  ```
+  // Reflector.java
+  
+  private void addGetMethod(String name, Method method) {
+      // <2.1> 判断是合理的属性名
+      if (isValidPropertyName(name)) {
+          // <2.2> 添加到 getMethods 中
+          getMethods.put(name, new MethodInvoker(method));
+          // <2.3> 添加到 getTypes 中
+          Type returnType = TypeParameterResolver.resolveReturnType(method, type);
+          getTypes.put(name, typeToClass(returnType));
+      }
+  }
+  ```
+
+  - `<2.1>` 处，调用 `#isValidPropertyName(String name)` 方法，判断是合理的属性名。代码如下：
+
+    ```
+    // Reflector.java
+    
+    private boolean isValidPropertyName(String name) {
+        return !(name.startsWith("$") || "serialVersionUID".equals(name) || "class".equals(name));
+    }
+    ```
+
+    - x
+
+  - `<2.2>` 处，添加到 `getMethods` 中。此处，我们可以看到一个 MethodInvoker 类，详细解析，见 [「4.3 MethodInvoker」](https://svip.iocoder.cn/MyBatis/reflection-package/#) 。
+
+  - `<2.3>` 处，添加到 `getTypes` 中。
+
+    - 此处，我们可以看到一个 TypeParameterResolver 类，详细解析，见 [「14. TypeParameterResolver」](https://svip.iocoder.cn/MyBatis/reflection-package/#) 。
+
+    - `#typeToClass(Type src)` 方法，获得 `java.lang.reflect.Type` 对应的类。代码如下：
+
+      ```
+      // Reflector.java
+      
+      private Class<?> typeToClass(Type src) {
+          Class<?> result = null;
+          // 普通类型，直接使用类
+          if (src instanceof Class) {
+              result = (Class<?>) src;
+          // 泛型类型，使用泛型
+          } else if (src instanceof ParameterizedType) {
+              result = (Class<?>) ((ParameterizedType) src).getRawType();
+          // 泛型数组，获得具体类
+          } else if (src instanceof GenericArrayType) {
+              Type componentType = ((GenericArrayType) src).getGenericComponentType();
+              if (componentType instanceof Class) { // 普通类型
+                  result = Array.newInstance((Class<?>) componentType, 0).getClass();
+              } else {
+                  Class<?> componentClass = typeToClass(componentType); // 递归该方法，返回类
+                  result = Array.newInstance(componentClass, 0).getClass();
+              }
+          }
+          // 都不符合，使用 Object 类
+          if (result == null) {
+              result = Object.class;
+          }
+          return result;
+      }
+      ```
+
+      - 代码比较简单，就是寻找 Type 真正对应的类。
+
+## 2.3 addSetMethods
+
+`#addSetMethods(Class<?> cls)` 方法，初始化 `setMethods` 和 `setTypes` ，通过遍历 setting 方法。代码如下：
+
+```
+// Reflector.java
+
+private void addSetMethods(Class<?> cls) {
+    // 属性与其 setting 方法的映射。
+    Map<String, List<Method>> conflictingSetters = new HashMap<>();
+    // 获得所有方法
+    Method[] methods = getClassMethods(cls);
+    // 遍历所有方法
+    for (Method method : methods) {
+        String name = method.getName();
+        // <1> 方法名为 set 开头
+        // 参数数量为 1
+        if (name.startsWith("set") && name.length() > 3) {
+            if (method.getParameterTypes().length == 1) {
+                // 获得属性
+                name = PropertyNamer.methodToProperty(name);
+                // 添加到 conflictingSetters 中
+                addMethodConflict(conflictingSetters, name, method);
+            }
+        }
+    }
+    // <2> 解决 setting 冲突方法
+    resolveSetterConflicts(conflictingSetters);
+}
+```
+
+- 总体逻辑和 `#addGetMethods(Class<?> cls)` 方法差不多。主要差异点在 `<1>` 和 `<2>` 处。因为 `<1>` 一眼就能明白，所以我们只看 `<2>` ，调用 `#resolveSetterConflicts(Map<String, List<Method>> conflictingSetters)` 方法，解决 setting 冲突方法。详细解析，见 [「2.3.1 resolveSetterConflicts」](https://svip.iocoder.cn/MyBatis/reflection-package/#) 中。
+
+### 2.3.1 resolveSetterConflicts
+
+`#resolveSetterConflicts(Map<String, List<Method>> conflictingSetters)` 方法，解决 setting 冲突方法。代码如下：
+
+```
+// Reflector.java
+
+private void resolveSetterConflicts(Map<String, List<Method>> conflictingSetters) {
+    // 遍历每个属性，查找其最匹配的方法。因为子类可以覆写父类的方法，所以一个属性，可能对应多个 setting 方法
+    for (String propName : conflictingSetters.keySet()) {
+        List<Method> setters = conflictingSetters.get(propName);
+        Class<?> getterType = getTypes.get(propName);
+        Method match = null;
+        ReflectionException exception = null;
+        // <1> 遍历属性对应的 setting 方法
+        for (Method setter : setters) {
+            Class<?> paramType = setter.getParameterTypes()[0];
+            // 和 getterType 相同，直接使用
+            if (paramType.equals(getterType)) {
+                // should be the best match
+                match = setter;
+                break;
+            }
+            if (exception == null) {
+                try {
+                    // 选择一个更加匹配的
+                    match = pickBetterSetter(match, setter, propName);
+                } catch (ReflectionException e) {
+                    // there could still be the 'best match'
+                    match = null;
+                    exception = e;
+                }
+            }
+        }
+        // <2> 添加到 setMethods 和 setTypes 中
+        if (match == null) {
+            throw exception;
+        } else {
+            addSetMethod(propName, match);
+        }
+    }
+}
+```
+
+- 总体比较简单，胖友自己瞅瞅。我们只说两个关键点哈。
+
+- `<1>` 处，解决冲突 setting 方法的方式，实际和 getting 方法的方式是**不太一样**的。首先，多的就是考虑了对应的 `getterType` 为优先级**最高**。其次，`#pickBetterSetter(Method setter1, Method setter2, String property)` 方法，选择一个更加匹配的，和 getting 方法是**相同**的，因为要选择精准的方法。代码如下：
+
+  ```
+  // Reflector.java
+  
+  private Method pickBetterSetter(Method setter1, Method setter2, String property) {
+      if (setter1 == null) {
+          return setter2;
+      }
+      Class<?> paramType1 = setter1.getParameterTypes()[0];
+      Class<?> paramType2 = setter2.getParameterTypes()[0];
+      if (paramType1.isAssignableFrom(paramType2)) {
+          return setter2;
+      } else if (paramType2.isAssignableFrom(paramType1)) {
+          return setter1;
+      }
+      throw new ReflectionException("Ambiguous setters defined for property '" + property + "' in class '"
+              + setter2.getDeclaringClass() + "' with types '" + paramType1.getName() + "' and '"
+              + paramType2.getName() + "'.");
+  }
+  ```
+
+  - 胖友在体会体会。感谢【闷油壶】同学指出问题。
+
+- `<2>` 处，调用 `#addSetMethod(String name, Method method)` 方法，添加到 `setMethods` 和 `setTypes` 中。代码如下：
+
+  ```
+  // Reflector.java
+  
+  private void addSetMethod(String name, Method method) {
+      if (isValidPropertyName(name)) {
+          // 添加到 setMethods 中
+          setMethods.put(name, new MethodInvoker(method));
+          // 添加到 setTypes 中
+          Type[] paramTypes = TypeParameterResolver.resolveParamTypes(method, type);
+          setTypes.put(name, typeToClass(paramTypes[0]));
+      }
+  }
+  ```
+
+  - 比较简单，和 `#addGetMethod(String name, Method method)` 方法是类似的。
+
+## 2.4 addFields
+
+`#addFields(Class<?> clazz)` 方法，初始化 `getMethods` + `getTypes` 和 `setMethods` + `setTypes` ，通过遍历 fields 属性。实际上，它是 `#addGetMethods(...)` 和 `#addSetMethods(...)` 方法的补充，因为有些 field ，不存在对应的 setting 或 getting 方法，**所以直接使用对应的 field** ，而不是方法。代码如下：
+
+```
+// Reflector.java
+
+private void addFields(Class<?> clazz) {
+    // 获得所有 field 们
+    Field[] fields = clazz.getDeclaredFields();
+    for (Field field : fields) {
+        // 设置 field 可访问
+        if (canControlMemberAccessible()) {
+            try {
+                field.setAccessible(true);
+            } catch (Exception e) {
+                // Ignored. This is only a final precaution, nothing we can do.
+            }
+        }
+        if (field.isAccessible()) {
+            // <1> 添加到 setMethods 和 setTypes 中
+            if (!setMethods.containsKey(field.getName())) {
+                // issue #379 - removed the check for final because JDK 1.5 allows
+                // modification of final fields through reflection (JSR-133). (JGB)
+                // pr #16 - final static can only be set by the classloader
+                int modifiers = field.getModifiers();
+                if (!(Modifier.isFinal(modifiers) && Modifier.isStatic(modifiers))) {
+                    addSetField(field);
+                }
+            }
+            // 添加到 getMethods 和 getTypes 中
+            if (!getMethods.containsKey(field.getName())) {
+                addGetField(field);
+            }
+        }
+    }
+    // 递归，处理父类
+    if (clazz.getSuperclass() != null) {
+        addFields(clazz.getSuperclass());
+    }
+}
+```
+
+- `<1>` 处，若 `setMethods` 不存在，则调用 `#addSetField(Field field)` 方法，添加到 `setMethods` 和 `setTypes` 中。代码如下：
+
+  ```
+  // Reflector.java
+  
+  private void addSetField(Field field) {
+      // 判断是合理的属性
+      if (isValidPropertyName(field.getName())) {
+          // 添加到 setMethods 中
+          setMethods.put(field.getName(), new SetFieldInvoker(field));
+          // 添加到 setTypes 中
+          Type fieldType = TypeParameterResolver.resolveFieldType(field, type);
+          setTypes.put(field.getName(), typeToClass(fieldType));
+      }
+  }
+  ```
+
+  - 注意，此处创建的是 SetFieldInvoker 对象。详细解析，见 [「4.2 SetFieldInvoker」](https://svip.iocoder.cn/MyBatis/reflection-package/#) 。
+
+- `<2>` 处，若 `getMethods` 不存在，则调用 `#addGetField(Field field)` 方法，添加到 `getMethods` 和 `getTypes` 中。代码如下：
+
+  ```
+  // Reflector.java
+  
+  private void addGetField(Field field) {
+      // 判断是合理的属性
+      if (isValidPropertyName(field.getName())) {
+          // 添加到 getMethods 中
+          getMethods.put(field.getName(), new GetFieldInvoker(field));
+          // 添加到 getMethods 中
+          Type fieldType = TypeParameterResolver.resolveFieldType(field, type);
+          getTypes.put(field.getName(), typeToClass(fieldType));
+      }
+  }
+  ```
+
+  - 注意，此处创建的是 GetFieldInvoker 对象。详细解析，，见 [「4.1 GetFieldInvoker」](https://svip.iocoder.cn/MyBatis/reflection-package/#) 。
+
+## 2.5 其它方法
+
+Reflector 中，还有其它方法，用于对它的属性进行访问。比较简单，感兴趣的胖友，自己来瞅瞅。例如：
+
+```
+// Reflector.java
+
+public Invoker getSetInvoker(String propertyName) {
+    Invoker method = setMethods.get(propertyName);
+    if (method == null) {
+        throw new ReflectionException("There is no setter for property named '" + propertyName + "' in '" + type + "'");
+    }
+    return method;
+}
+```
+
+# 3. ReflectorFactory
+
+`org.apache.ibatis.reflection.ReflectorFactory` ，Reflector 工厂接口，用于创建和缓存 Reflector 对象。代码如下：
+
+```
+// ReflectorFactory.java
+
+public interface ReflectorFactory {
+
+    /**
+     * @return 是否缓存 Reflector 对象
+     */
+    boolean isClassCacheEnabled();
+
+    /**
+     * 设置是否缓存 Reflector 对象
+     *
+     * @param classCacheEnabled 是否缓存
+     */
+    void setClassCacheEnabled(boolean classCacheEnabled);
+
+    /**
+     * 获取 Reflector 对象
+     *
+     * @param type 指定类
+     * @return Reflector 对象
+     */
+    Reflector findForClass(Class<?> type);
+
+}
+```
+
+## 3.1 DefaultReflectorFactory
+
+`org.apache.ibatis.reflection.DefaultReflectorFactory` ，实现 ReflectorFactory 接口，默认的 ReflectorFactory 实现类。代码如下：
+
+```
+// DefaultReflectorFactory.java
+
+public class DefaultReflectorFactory implements ReflectorFactory {
+
+    /**
+     * 是否缓存
+     */
+    private boolean classCacheEnabled = true;
+    /**
+     * Reflector 的缓存映射
+     *
+     * KEY：类
+     * VALUE：Reflector 对象
+     */
+    private final ConcurrentMap<Class<?>, Reflector> reflectorMap = new ConcurrentHashMap<>();
+
+    public DefaultReflectorFactory() {
+    }
+
+    @Override
+    public boolean isClassCacheEnabled() {
+        return classCacheEnabled;
+    }
+
+    @Override
+    public void setClassCacheEnabled(boolean classCacheEnabled) {
+        this.classCacheEnabled = classCacheEnabled;
+    }
+
+    @Override
+    public Reflector findForClass(Class<?> type) {
+        // 开启缓存，则从 reflectorMap 中获取
+        if (classCacheEnabled) {
+            // synchronized (type) removed see issue #461
+            return reflectorMap.computeIfAbsent(type, Reflector::new); // 不存在，则进行创建
+        // 关闭缓存，则创建 Reflector 对象
+        } else {
+            return new Reflector(type);
+        }
+    }
+
+}
+```
+
+- 代码比较简单，胖友一眼就能看懂。
+
+# 4. Invoker
+
+`org.apache.ibatis.reflection.invoker.Invoker` ，调用者接口。代码如下：
+
+```
+// Invoker.java
+
+public interface Invoker {
+
+    /**
+     * 执行调用
+     *
+     * @param target 目标
+     * @param args 参数
+     * @return 结果
+     * @throws IllegalAccessException
+     * @throws InvocationTargetException
+     */
+    Object invoke(Object target, Object[] args) throws IllegalAccessException, InvocationTargetException;
+
+    /**
+     * @return 类
+     */
+    Class<?> getType();
+
+}
+```
+
+- 核心是 `#invoke(Object target, Object[] args)` 方法，执行一次调用。而具体调用什么方法，由子类来实现。
+
+## 4.1 GetFieldInvoker
+
+`org.apache.ibatis.reflection.invoker.GetFieldInvoker` ，实现 Invoker 接口，获得 Field 调用者。代码如下：
+
+```
+// GetFieldInvoker.java
+
+public class GetFieldInvoker implements Invoker {
+
+    /**
+     * Field 对象
+     */
+    private final Field field;
+
+    public GetFieldInvoker(Field field) {
+        this.field = field;
+    }
+
+    // 获得属性
+    @Override
+    public Object invoke(Object target, Object[] args) throws IllegalAccessException, InvocationTargetException {
+        return field.get(target);
+    }
+
+    // 返回属性类型
+    @Override
+    public Class<?> getType() {
+        return field.getType();
+    }
+
+}
+```
+
+## 4.2 SetFieldInvoker
+
+`org.apache.ibatis.reflection.invoker.SetFieldInvoker` ，实现 Invoker 接口，设置 Field 调用者。代码如下：
+
+```
+// SetFieldInvoker.java
+
+public class SetFieldInvoker implements Invoker {
+
+    /**
+     * Field 对象
+     */
+    private final Field field;
+
+    public SetFieldInvoker(Field field) {
+        this.field = field;
+    }
+
+    // 设置 Field 属性
+    @Override
+    public Object invoke(Object target, Object[] args) throws IllegalAccessException, InvocationTargetException {
+        field.set(target, args[0]);
+        return null;
+    }
+
+    // 返回属性类型
+    @Override
+    public Class<?> getType() {
+        return field.getType();
+    }
+
+}
+```
+
+## 4.3 MethodInvoker
+
+`org.apache.ibatis.reflection.invoker.MethodInvoker` ，实现 Invoker 接口，指定方法的调用器。代码如下：
+
+```
+// MethodInvoker.java
+
+public class MethodInvoker implements Invoker {
+
+    /**
+     * 类型
+     */
+    private final Class<?> type;
+    /**
+     * 指定方法
+     */
+    private final Method method;
+
+    public MethodInvoker(Method method) {
+        this.method = method;
+
+        // 参数大小为 1 时，一般是 setting 方法，设置 type 为方法参数[0]
+        if (method.getParameterTypes().length == 1) {
+            type = method.getParameterTypes()[0];
+        // 否则，一般是 getting 方法，设置 type 为返回类型
+        } else {
+            type = method.getReturnType();
+        }
+    }
+
+    // 执行指定方法
+    @Override
+    public Object invoke(Object target, Object[] args) throws IllegalAccessException, InvocationTargetException {
+        return method.invoke(target, args);
+    }
+
+    @Override
+    public Class<?> getType() {
+        return type;
+    }
+
+}
+```
+
+# 5. ObjectFactory
+
+`org.apache.ibatis.reflection.factory.ObjectFactory` ，Object 工厂接口，用于创建指定类的对象。代码如下：
+
+```
+// ObjectFactory.java
+
+public interface ObjectFactory {
+
+  /**
+   * 设置 Properties
+   *
+   * Sets configuration properties.
+   * @param properties configuration properties
+   */
+  void setProperties(Properties properties);
+
+  /**
+   * 创建指定类的对象，使用默认构造方法
+   *
+   * Creates a new object with default constructor.
+   * @param type Object type
+   * @return 对象
+   */
+  <T> T create(Class<T> type);
+
+  /**
+   * Creates a new object with the specified constructor and params.
+   *
+   * 创建指定类的对象，使用特定的构造方法
+   *
+   * @param type Object type
+   * @param constructorArgTypes Constructor argument types 指定构造方法的参数列表
+   * @param constructorArgs Constructor argument values 参数数组
+   * @return 对象
+   */
+  <T> T create(Class<T> type, List<Class<?>> constructorArgTypes, List<Object> constructorArgs);
+
+  /**
+   * Returns true if this object can have a set of other objects.
+   * It's main purpose is to support non-java.util.Collection objects like Scala collections.
+   *
+   * 判断指定类是否为集合类
+   *
+   * @param type Object type
+   * @return whether it is a collection or not
+   * @since 3.1.0
+   */
+  <T> boolean isCollection(Class<T> type);
+
+}
+```
+
+- 比较简单，一共有三类方法。
+
+## 5.1 DefaultObjectFactory
+
+`org.apache.ibatis.reflection.factory.DefaultObjectFactory` ，实现 ObjectFactory、Serializable 接口，默认 ObjectFactory 实现类。
+
+### 5.1.1 create
+
+`#create(Class<T> type, ...)` 方法，创建指定类的对象。代码如下：
+
+```
+// DefaultObjectFactory.java
+
+@Override
+public <T> T create(Class<T> type) {
+    return create(type, null, null);
+}
+
+@SuppressWarnings("unchecked")
+@Override
+public <T> T create(Class<T> type, List<Class<?>> constructorArgTypes, List<Object> constructorArgs) {
+    // <1> 获得需要创建的类
+    Class<?> classToCreate = resolveInterface(type);
+    // we know types are assignable
+    // <2> 创建指定类的对象
+    return (T) instantiateClass(classToCreate, constructorArgTypes, constructorArgs);
+}
+```
+
+- `<1>` 处，调用 `#resolveInterface(Class<?> type)` 方法，获得需要创建的类。代码如下：
+
+  ```
+  // DefaultObjectFactory.java
+  
+  protected Class<?> resolveInterface(Class<?> type) {
+      Class<?> classToCreate;
+      if (type == List.class || type == Collection.class || type == Iterable.class) {
+          classToCreate = ArrayList.class;
+      } else if (type == Map.class) {
+          classToCreate = HashMap.class;
+      } else if (type == SortedSet.class) { // issue #510 Collections Support
+          classToCreate = TreeSet.class;
+      } else if (type == Set.class) {
+          classToCreate = HashSet.class;
+      } else {
+          classToCreate = type;
+      }
+      return classToCreate;
+  }
+  ```
+
+  - 对于我们常用的**集合接口**，返回对应的实现类。
+
+- `<1>` 处，调用 `#instantiateClass(Class<T> type, List<Class<?>> constructorArgTypes, List<Object> constructorArgs)` 方法，创建指定类的对象。代码如下：
+
+  ```
+  // DefaultObjectFactory.java
+  
+  private <T> T instantiateClass(Class<T> type, List<Class<?>> constructorArgTypes, List<Object> constructorArgs) {
+      try {
+          Constructor<T> constructor;
+          // <x1> 通过无参构造方法，创建指定类的对象
+          if (constructorArgTypes == null || constructorArgs == null) {
+              constructor = type.getDeclaredConstructor();
+              if (!constructor.isAccessible()) {
+                  constructor.setAccessible(true);
+              }
+              return constructor.newInstance();
+          }
+          // <x2> 使用特定构造方法，创建指定类的对象
+          constructor = type.getDeclaredConstructor(constructorArgTypes.toArray(new Class[constructorArgTypes.size()]));
+          if (!constructor.isAccessible()) {
+              constructor.setAccessible(true);
+          }
+          return constructor.newInstance(constructorArgs.toArray(new Object[constructorArgs.size()]));
+      } catch (Exception e) {
+          // 拼接 argTypes
+          StringBuilder argTypes = new StringBuilder();
+          if (constructorArgTypes != null && !constructorArgTypes.isEmpty()) {
+              for (Class<?> argType : constructorArgTypes) {
+                  argTypes.append(argType.getSimpleName());
+                  argTypes.append(",");
+              }
+              argTypes.deleteCharAt(argTypes.length() - 1); // remove trailing ,
+          }
+          // 拼接 argValues
+          StringBuilder argValues = new StringBuilder();
+          if (constructorArgs != null && !constructorArgs.isEmpty()) {
+              for (Object argValue : constructorArgs) {
+                  argValues.append(String.valueOf(argValue));
+                  argValues.append(",");
+              }
+              argValues.deleteCharAt(argValues.length() - 1); // remove trailing ,
+          }
+          // 抛出 ReflectionException 异常
+          throw new ReflectionException("Error instantiating " + type + " with invalid types (" + argTypes + ") or values (" + argValues + "). Cause: " + e, e);
+      }
+  }
+  ```
+
+  - 代码比较简单，分成 `<x1>`、`<x2>` 两种情况。
+
+### 5.1.2 isCollection
+
+`#isCollection(Class<T> type)` 方法，判断指定类是否为集合类。代码如下：
+
+```
+// DefaultObjectFactory.java
+
+@Override
+public <T> boolean isCollection(Class<T> type) {
+    return Collection.class.isAssignableFrom(type);
+}
+```
+
+- 判断是否为 `java.util.Collection` 的子类。
+
+### 5.1.3 setProperties
+
+`#setProperties(Properties properties)` 方法，设置 Properties 。代码如下：
+
+```
+// DefaultObjectFactory.java
+
+@Override
+public void setProperties(Properties properties) {
+    // no props for default
+}
+```
+
+- 目前是个空实现。所以，暂时可以忽略这个方法。
+
+# 6. Property 工具类
+
+`org.apache.ibatis.reflection.property` 包下，提供了 PropertyCopier、PropertyNamer、PropertyTokenizer 三个属性相关的工具类。接下来，我们逐小节来解析。
+
+## 6.1 PropertyCopier
+
+`org.apache.ibatis.reflection.property.PropertyCopier` ，属性复制器。代码如下：
+
+```
+// PropertyNamer.java
+
+public final class PropertyCopier {
+
+    private PropertyCopier() {
+        // Prevent Instantiation of Static Class
+    }
+
+    /**
+     * 将 sourceBean 的属性，复制到 destinationBean 中
+     *
+     * @param type 指定类
+     * @param sourceBean 来源 Bean 对象
+     * @param destinationBean 目标 Bean 对象
+     */
+    public static void copyBeanProperties(Class<?> type, Object sourceBean, Object destinationBean) {
+        // 循环，从当前类开始，不断复制到父类，直到父类不存在
+        Class<?> parent = type;
+        while (parent != null) {
+            // 获得当前 parent 类定义的属性
+            final Field[] fields = parent.getDeclaredFields();
+            for (Field field : fields) {
+                try {
+                    // 设置属性可访问
+                    field.setAccessible(true);
+                    // 从 sourceBean 中，复制到 destinationBean 去
+                    field.set(destinationBean, field.get(sourceBean));
+                } catch (Exception e) {
+                    // Nothing useful to do, will only fail on final fields, which will be ignored.
+                }
+            }
+            // 获得父类
+            parent = parent.getSuperclass();
+        }
+    }
+
+}
+```
+
+- 比较简单，胖友一眼看懂。
+
+## 6.2 PropertyNamer
+
+`org.apache.ibatis.reflection.property.PropertyNamer` ，属性名相关的工具类方法。代码如下：
+
+```
+public final class PropertyNamer {
+
+    private PropertyNamer() {
+        // Prevent Instantiation of Static Class
+    }
+
+    /**
+     * 根据方法名，获得对应的属性名
+     *
+     * @param name 方法名
+     * @return 属性名
+     */
+    public static String methodToProperty(String name) {
+        // is 方法
+        if (name.startsWith("is")) {
+            name = name.substring(2);
+        // get 或者 set 方法
+        } else if (name.startsWith("get") || name.startsWith("set")) {
+            name = name.substring(3);
+        // 抛出 ReflectionException 异常，因为只能处理 is、set、get 方法
+        } else {
+            throw new ReflectionException("Error parsing property name '" + name + "'.  Didn't start with 'is', 'get' or 'set'.");
+        }
+
+        // 首字母小写
+        if (name.length() == 1 || (name.length() > 1 && !Character.isUpperCase(name.charAt(1)))) {
+            name = name.substring(0, 1).toLowerCase(Locale.ENGLISH) + name.substring(1);
+        }
+
+        return name;
+    }
+
+    /**
+     * 判断是否为 is、get、set 方法
+     *
+     * @param name 方法名
+     * @return 是否
+     */
+    public static boolean isProperty(String name) {
+        return name.startsWith("get") || name.startsWith("set") || name.startsWith("is");
+    }
+
+    /**
+     * 判断是否为 get、is 方法
+     *
+     * @param name 方法名
+     * @return 是否
+     */
+    public static boolean isGetter(String name) {
+        return name.startsWith("get") || name.startsWith("is");
+    }
+
+    /**
+     * 判断是否为 set 方法
+     *
+     * @param name 方法名
+     * @return 是否
+     */
+    public static boolean isSetter(String name) {
+        return name.startsWith("set");
+    }
+
+}
+```
+
+- 比较简单，胖友一眼看懂。
+
+## 6.3 PropertyTokenizer
+
+`org.apache.ibatis.reflection.property.PropertyTokenizer` ，实现 Iterator 接口，属性分词器，支持迭代器的访问方式。
+
+举个例子，在访问 `"order[0].item[0].name"` 时，我们希望拆分成 `"order[0]"`、`"item[0]"`、`"name"` 三段，那么就可以通过 PropertyTokenizer 来实现。
+
+### 6.3.1 构造方法
+
+```
+// PropertyTokenizer.java
+
+/**
+ * 当前字符串
+ */
+private String name;
+/**
+ * 索引的 {@link #name} ，因为 {@link #name} 如果存在 {@link #index} 会被更改
+ */
+private final String indexedName;
+/**
+ * 编号。
+ *
+ * 对于数组 name[0] ，则 index = 0
+ * 对于 Map map[key] ，则 index = key
+ */
+private String index;
+/**
+ * 剩余字符串
+ */
+private final String children;
+
+public PropertyTokenizer(String fullname) {
+    // <1> 初始化 name、children 字符串，使用 . 作为分隔
+    int delim = fullname.indexOf('.');
+    if (delim > -1) {
+        name = fullname.substring(0, delim);
+        children = fullname.substring(delim + 1);
+    } else {
+        name = fullname;
+        children = null;
+    }
+    // <2> 记录当前 name
+    indexedName = name;
+    // 若存在 [ ，则获得 index ，并修改 name 。
+    delim = name.indexOf('[');
+    if (delim > -1) {
+        index = name.substring(delim + 1, name.length() - 1);
+        name = name.substring(0, delim);
+    }
+}
+```
+
+- `name` 属性，当前字符串。
+
+- `children` 属性，剩余字符串。
+
+- `<1>` 处，初始化 `name`、`children` 字符串，使用 `'.'` 作为分隔。
+
+- `indexedName` 属性，索引的 `name` 属性，因为 `name` 如果存在 `index` 会被更改。
+
+- `<2>` 处，记录当前 `name` 。
+
+- ```
+  index
+  ```
+
+   
+
+  属性，编号。分成两种情况：
+
+  - `name` 为数组 `item[0]` 时，则 `index` 为 `"0"` 。
+  - `name` 为 Map `map[key]` 时，则 `index` 为 `"key"` 。
+
+- `<3>` 处，初始化 `index` ，并修改 `name` 字符串，使用 `'['` 作为分隔符。
+
+### 6.3.2 next
+
+`#next()` 方法，迭代获得下一个 PropertyTokenizer 对象。代码如下：
+
+```
+// PropertyTokenizer.java
+
+@Override
+public PropertyTokenizer next() {
+    return new PropertyTokenizer(children);
+}
+```
+
+- 酱紫，它又会执行[「6.3.1 构造方法」](https://svip.iocoder.cn/MyBatis/reflection-package/#) 的流程。
+
+### 6.3.3 hasNext
+
+`#hasNext()` 方法，判断是否有下一个元素。代码如下：
+
+```
+// PropertyTokenizer.java
+
+public String getChildren() {
+    return children;
+}
+```
+
+### 6.3.4 其它方法
+
+PropertyTokenizer 中，还有其它方法，比较简单，感兴趣的胖友，自己来瞅瞅。
+
+# 7. MetaClass
+
+`org.apache.ibatis.reflection.MetaClass` ，类的元数据，基于 Reflector 和 PropertyTokenizer ，提供对指定类的各种骚操作。
+
+## 7.1 构造方法
+
+```
+// MetaClass.java
+
+private final ReflectorFactory reflectorFactory;
+private final Reflector reflector;
+
+private MetaClass(Class<?> type, ReflectorFactory reflectorFactory) {
+    this.reflectorFactory = reflectorFactory;
+    this.reflector = reflectorFactory.findForClass(type);
+}
+```
+
+- 通过构造方法，我们可以看出，一个 MetaClass 对象，对应一个 Class 对象。
+
+目前有两个方法会涉及到调用该构造方法:
+
+- ① `#forClass(Class<?> type, ReflectorFactory reflectorFactory)` **静态**方法，创建指定类的 MetaClass 对象。代码如下：
+
+  ```
+  // MetaClass.java
+  
+  public static MetaClass forClass(Class<?> type, ReflectorFactory reflectorFactory) {
+      return new MetaClass(type, reflectorFactory);
+  }
+  ```
+
+- ② `#metaClassForProperty(String name)` 方法，创建类的指定属性的类的 MetaClass 对象。代码如下：
+
+  ```
+  // MetaClass.java
+  
+  public MetaClass metaClassForProperty(String name) {
+      // 获得属性的类
+      Class<?> propType = reflector.getGetterType(name);
+      // 创建 MetaClass 对象
+      return MetaClass.forClass(propType, reflectorFactory);
+  }
+  ```
+
+## 7.2 findProperty
+
+`#findProperty(String name, boolean useCamelCaseMapping)` 方法，根据表达式，获得属性。代码如下：
+
+```
+// MetaClass.java
+
+public String findProperty(String name, boolean useCamelCaseMapping) {
+    // <1> 下划线转驼峰
+    if (useCamelCaseMapping) {
+        name = name.replace("_", "");
+    }
+    // <2> 获得属性
+    return findProperty(name);
+}
+```
+
+- `useCamelCaseMapping` 属性，是否要[下划线转驼峰](https://www.cnblogs.com/flying607/p/8473075.html) 。但是，在 `<1>` 处，我们仅仅看到 `_` 被替换成了空串。这是为什么呢？继续往下看。
+
+- `<2>` 处，调用 `#findProperty(String name)` 方法，根据表达式，获得属性。代码如下：
+
+  ```
+  // MetaClass.java
+  
+  public String findProperty(String name) {
+      // <3> 构建属性
+      StringBuilder prop = buildProperty(name, new StringBuilder());
+      return prop.length() > 0 ? prop.toString() : null;
+  }
+  ```
+
+  - `<3>` 处，调用 `#buildProperty(String name, StringBuilder builder)` 方法，构建属性。代码如下：
+
+```
+// MetaClass.javaprivate StringBuilder buildProperty(String name, StringBuilder builder) {    // 创建 PropertyTokenizer 对象，对 name 进行分词    PropertyTokenizer prop = new PropertyTokenizer(name);    // 有子表达式    if (prop.hasNext()) {        // <4> 获得属性名，并添加到 builder 中        String propertyName = reflector.findPropertyName(prop.getName());        if (propertyName != null) {            // 拼接属性到 builder 中            builder.append(propertyName);            builder.append(".");            // 创建 MetaClass 对象            MetaClass metaProp = metaClassForProperty(propertyName);            // 递归解析子表达式 children ，并将结果添加到 builder 中            metaProp.buildProperty(prop.getChildren(), builder);        }    // 无子表达式    } else {        // <4> 获得属性名，并添加到 builder 中        String propertyName = reflector.findPropertyName(name);        if (propertyName != null) {            builder.append(propertyName);        }    }    return builder;} * 创建 PropertyTokenizer 对象，对 `name` 进行**分词**。当有子表达式，继续递归调用 `#buildProperty(String name, StringBuilder builder)` 方法，并将结果添加到 `builder` 中；否则，结束，直接添加到 `builder` 中。 * 在两个 `<4>` 处，解决“下划线转驼峰”的关键是，通过 `Reflector.caseInsensitivePropertyMap` 属性，忽略大小写。代码如下：     // Reflector.java/** * 不区分大小写的属性集合 */private Map<String, String> caseInsensitivePropertyMap = new HashMap<>();public String findPropertyName(String name) {    return caseInsensitivePropertyMap.get(name.toUpperCase(Locale.ENGLISH));}     * x 
+```
+
+------
+
+如果胖友，你有点懵逼，可以运行下 `MetaClassTest#shouldFindPropertyName()` 这个单元测试方法。
+
+## 7.3 hasGetter
+
+`#hasGetter(String name)` 方法，判断指定属性是否有 getting 方法。代码如下：
+
+```
+// MetaClass.java
+
+public boolean hasGetter(String name) {
+    // 创建 PropertyTokenizer 对象，对 name 进行分词
+    PropertyTokenizer prop = new PropertyTokenizer(name);
+    // 有子表达式
+    if (prop.hasNext()) {
+        // 判断是否有该属性的 getting 方法
+        if (reflector.hasGetter(prop.getName())) {
+            // <1> 创建 MetaClass 对象
+            MetaClass metaProp = metaClassForProperty(prop);
+            // 递归判断子表达式 children ，是否有 getting 方法
+            return metaProp.hasGetter(prop.getChildren());
+        } else {
+            return false;
+        }
+    // 无子表达式
+    } else {
+        // 判断是否有该属性的 getting 方法
+        return reflector.hasGetter(prop.getName());
+    }
+}
+```
+
+- 思路和 `#findProperty((String name, ...)` 方法是一样的，所以胖友自己看下。
+
+- `<1>` 处，调用 `#metaClassForProperty(PropertyTokenizer prop)` 方法，创建 创建 MetaClass 对象。代码如下：
+
+  ```
+  // MetaClass.java
+  
+  private MetaClass metaClassForProperty(PropertyTokenizer prop) {
+      // 【调用】获得 getting 方法返回的类型
+      Class<?> propType = getGetterType(prop);
+      // 创建 MetaClass 对象
+      return MetaClass.forClass(propType, reflectorFactory);
+  }
+  
+  private Class<?> getGetterType(PropertyTokenizer prop) {
+      // 获得返回类型
+      Class<?> type = reflector.getGetterType(prop.getName());
+      // 如果获取数组的某个位置的元素，则获取其泛型。例如说：list[0].field ，那么就会解析 list 是什么类型，这样才好通过该类型，继续获得 field
+      if (prop.getIndex() != null && Collection.class.isAssignableFrom(type)) {
+          // 【调用】获得返回的类型
+          Type returnType = getGenericGetterType(prop.getName());
+          // 如果是泛型，进行解析真正的类型
+          if (returnType instanceof ParameterizedType) {
+              Type[] actualTypeArguments = ((ParameterizedType) returnType).getActualTypeArguments();
+              if (actualTypeArguments != null && actualTypeArguments.length == 1) { // 为什么这里判断大小为 1 呢，因为 Collection 是 Collection<T> ，至多一个。
+                  returnType = actualTypeArguments[0];
+                  if (returnType instanceof Class) {
+                      type = (Class<?>) returnType;
+                  } else if (returnType instanceof ParameterizedType) {
+                      type = (Class<?>) ((ParameterizedType) returnType).getRawType();
+                  }
+              }
+          }
+      }
+      return type;
+  }
+  
+  private Type getGenericGetterType(String propertyName) {
+      try {
+          // 获得 Invoker 对象
+          Invoker invoker = reflector.getGetInvoker(propertyName);
+          // 如果 MethodInvoker 对象，则说明是 getting 方法，解析方法返回类型
+          if (invoker instanceof MethodInvoker) {
+              Field _method = MethodInvoker.class.getDeclaredField("method");
+              _method.setAccessible(true);
+              Method method = (Method) _method.get(invoker);
+              return TypeParameterResolver.resolveReturnType(method, reflector.getType());
+          // 如果 GetFieldInvoker 对象，则说明是 field ，直接访问
+          } else if (invoker instanceof GetFieldInvoker) {
+              Field _field = GetFieldInvoker.class.getDeclaredField("field");
+              _field.setAccessible(true);
+              Field field = (Field) _field.get(invoker);
+              return TypeParameterResolver.resolveFieldType(field, reflector.getType());
+          }
+      } catch (NoSuchFieldException | IllegalAccessException ignored) {
+      }
+      return null;
+  }
+  ```
+
+  - 代码比较长，胖友跟着代码注释，运行下。另外，每个上面的方法， 会调用下面的方法，也就说 `metaClassForProperty => getGetterType => getGenericGetterType` 。
+
+------
+
+另外，`#hasSetter(String name)` 方法，判断指定属性是否有 setting 方法。逻辑上，和 `#hasGetter(String name)` 方法类似，胖友可以自己瞅瞅。
+
+## 7.4 getGetterType
+
+`#getGetterType(String name)` 方法，获得指定属性的 getting 方法的返回值的类型。代码如下：
+
+```
+// MetaClass.java
+
+public Class<?> getGetterType(String name) {
+    // 创建 PropertyTokenizer 对象，对 name 进行分词
+    PropertyTokenizer prop = new PropertyTokenizer(name);
+    // 有子表达式
+    if (prop.hasNext()) {
+        // 创建 MetaClass 对象
+        MetaClass metaProp = metaClassForProperty(prop);
+        // 递归判断子表达式 children ，获得返回值的类型
+        return metaProp.getGetterType(prop.getChildren());
+    }
+    // issue #506. Resolve the type inside a Collection Object
+    // 直接获得返回值的类型
+    return getGetterType(prop);
+}
+```
+
+- 和 `#hasGetter(String name)` 方法类似，胖友可以自己瞅瞅。
+
+------
+
+另外，`#getSetterType(String name)` 方法，判断指定属性是否有 setting 方法。逻辑上，和 `#getGetterType(String name)` 方法类似，胖友可以自己瞅瞅。
+
+## 7.5 其它方法
+
+MetaClass 还有其它方法，比较简单，是基于 Reflector 方法的封装，感兴趣的胖友，可以自己看看。
+
+# 8. ObjectWrapper
+
+`org.apache.ibatis.reflection.wrapper.ObjectWrapper` ，对象包装器接口，基于 MetaClass 工具类，定义对指定对象的各种操作。或者可以说，ObjectWrapper 是 MetaClass 的指定类的具象化。代码如下：
+
+```
+// ObjectWrapper.java
+
+public interface ObjectWrapper {
+
+    /**
+     * 获得值
+     *
+     * @param prop PropertyTokenizer 对象，相当于键
+     * @return 值
+     */
+    Object get(PropertyTokenizer prop);
+    /**
+     * 设置值
+     *
+     * @param prop PropertyTokenizer 对象，相当于键
+     * @param value 值
+     */
+    void set(PropertyTokenizer prop, Object value);
+
+    /**
+     * {@link MetaClass#findProperty(String, boolean)}
+     */
+    String findProperty(String name, boolean useCamelCaseMapping);
+    /**
+     * {@link MetaClass#getGetterNames()}
+     */
+    String[] getGetterNames();
+    /**
+     * {@link MetaClass#getSetterNames()}
+     */
+    String[] getSetterNames();
+    /**
+     * {@link MetaClass#getSetterType(String)}
+     */
+    Class<?> getSetterType(String name);
+    /**
+     * {@link MetaClass#getGetterType(String)}
+     */
+    Class<?> getGetterType(String name);
+    /**
+     * {@link MetaClass#hasSetter(String)}
+     */
+    boolean hasSetter(String name);
+    /**
+     * {@link MetaClass#hasGetter(String)}
+     */
+    boolean hasGetter(String name);
+
+    /**
+     * {@link MetaObject#forObject(Object, ObjectFactory, ObjectWrapperFactory, ReflectorFactory)}
+     */
+    MetaObject instantiatePropertyValue(String name, PropertyTokenizer prop, ObjectFactory objectFactory);
+
+    /**
+     * 是否为集合
+     */
+    boolean isCollection();
+    /**
+     * 添加元素到集合
+     */
+    void add(Object element);
+
+    /**
+     * 添加多个元素到集合
+     */
+    <E> void addAll(List<E> element);
+
+}
+```
+
+- 从接口中，我们可以看到，主要是对 MetaObject 方法的调用。
+
+------
+
+ObjectWrapper 的子类实现如下图：[![ObjectWrapper 类图](05-mybatis-反射模块.assets/02.png)](http://static.iocoder.cn/images/MyBatis/2020_01_10/02.png)ObjectWrapper 类图
+
+## 8.1 BaseWrapper
+
+`org.apache.ibatis.reflection.wrapper.BaseWrapper` ，实现 ObjectWrapper 接口，ObjectWrapper 抽象类，为子类 BeanWrapper 和 MapWrapper 提供属性值的获取和设置的公用方法。代码如下：
+
+```
+// BaseWrapper.java
+
+public abstract class BaseWrapper implements ObjectWrapper {
+
+    protected static final Object[] NO_ARGUMENTS = new Object[0];
+
+    /**
+     * MetaObject 对象
+     */
+    protected final MetaObject metaObject;
+
+    protected BaseWrapper(MetaObject metaObject) {
+        this.metaObject = metaObject;
+    }
+
+    /**
+     * 获得指定属性的值
+     *
+     * @param prop PropertyTokenizer 对象
+     * @param object 指定 Object 对象
+     * @return 值
+     */
+    protected Object resolveCollection(PropertyTokenizer prop, Object object) {
+        if ("".equals(prop.getName())) {
+            return object;
+        } else {
+            return metaObject.getValue(prop.getName());
+        }
+    }
+
+    /**
+     * 获得集合中指定位置的值
+     *
+     * @param prop PropertyTokenizer 对象
+     * @param collection 集合
+     * @return 值
+     */
+    protected Object getCollectionValue(PropertyTokenizer prop, Object collection) {
+        if (collection instanceof Map) {
+            return ((Map) collection).get(prop.getIndex());
+        } else {
+            int i = Integer.parseInt(prop.getIndex());
+            if (collection instanceof List) {
+                return ((List) collection).get(i);
+            } else if (collection instanceof Object[]) {
+                return ((Object[]) collection)[i];
+            } else if (collection instanceof char[]) {
+                return ((char[]) collection)[i];
+            } else if (collection instanceof boolean[]) {
+                return ((boolean[]) collection)[i];
+            } else if (collection instanceof byte[]) {
+                return ((byte[]) collection)[i];
+            } else if (collection instanceof double[]) {
+                return ((double[]) collection)[i];
+            } else if (collection instanceof float[]) {
+                return ((float[]) collection)[i];
+            } else if (collection instanceof int[]) {
+                return ((int[]) collection)[i];
+            } else if (collection instanceof long[]) {
+                return ((long[]) collection)[i];
+            } else if (collection instanceof short[]) {
+                return ((short[]) collection)[i];
+            } else {
+                throw new ReflectionException("The '" + prop.getName() + "' property of " + collection + " is not a List or Array.");
+            }
+        }
+    }
+
+    /**
+     * 设置集合中指定位置的值
+     *
+     * @param prop PropertyTokenizer 对象
+     * @param collection 集合
+     * @param value 值
+     */
+    protected void setCollectionValue(PropertyTokenizer prop, Object collection, Object value) {
+        if (collection instanceof Map) {
+            ((Map) collection).put(prop.getIndex(), value);
+        } else {
+            int i = Integer.parseInt(prop.getIndex());
+            if (collection instanceof List) {
+                ((List) collection).set(i, value);
+            } else if (collection instanceof Object[]) {
+                ((Object[]) collection)[i] = value;
+            } else if (collection instanceof char[]) {
+                ((char[]) collection)[i] = (Character) value;
+            } else if (collection instanceof boolean[]) {
+                ((boolean[]) collection)[i] = (Boolean) value;
+            } else if (collection instanceof byte[]) {
+                ((byte[]) collection)[i] = (Byte) value;
+            } else if (collection instanceof double[]) {
+                ((double[]) collection)[i] = (Double) value;
+            } else if (collection instanceof float[]) {
+                ((float[]) collection)[i] = (Float) value;
+            } else if (collection instanceof int[]) {
+                ((int[]) collection)[i] = (Integer) value;
+            } else if (collection instanceof long[]) {
+                ((long[]) collection)[i] = (Long) value;
+            } else if (collection instanceof short[]) {
+                ((short[]) collection)[i] = (Short) value;
+            } else {
+                throw new ReflectionException("The '" + prop.getName() + "' property of " + collection + " is not a List or Array.");
+            }
+        }
+    }
+
+}
+```
+
+- 代码比较简单，胖友看下注释。关于 MetaObject 类，会在 [「10. MetaObject」](https://svip.iocoder.cn/MyBatis/reflection-package/#) 中，详细解析。
+
+### 8.1.1 BeanWrapper
+
+`org.apache.ibatis.reflection.wrapper.BeanWrapper` ，继承 BaseWrapper 抽象类，**普通对象**的 ObjectWrapper 实现类，例如 User、Order 这样的 POJO 类。属性如下：
+
+```
+// BeanWrapper.java
+
+/**
+ * 普通对象
+ */
+private final Object object;
+private final MetaClass metaClass;
+
+public BeanWrapper(MetaObject metaObject, Object object) {
+    super(metaObject);
+    this.object = object;
+    // 创建 MetaClass 对象
+    this.metaClass = MetaClass.forClass(object.getClass(), metaObject.getReflectorFactory());
+}
+```
+
+#### 8.1.1.1 get
+
+`#get(PropertyTokenizer prop)` 方法，获得指定属性的值。代码如下：
+
+```
+// BeanWrapper.java
+
+@Override
+public Object get(PropertyTokenizer prop) {
+    // <1> 获得集合类型的属性的指定位置的值
+    if (prop.getIndex() != null) {
+        // 获得集合类型的属性
+        Object collection = resolveCollection(prop, object);
+        // 获得指定位置的值
+        return getCollectionValue(prop, collection);
+    // <2> 获得属性的值
+    } else {
+        return getBeanProperty(prop, object);
+    }
+}
+```
+
+- `<1>` 处，获得集合类型的属性的指定位置的值。例如说：User 对象的 `list[0]` 。所调用的方法，都是 BaseWrapper 所提供的公用方法。
+
+- `<2>` 处，调用 `#getBeanProperty(PropertyTokenizer prop, Object object)` 方法，获得属性的值。代码如下：
+
+  ```
+  // BeanWrapper.java
+  
+  private Object getBeanProperty(PropertyTokenizer prop, Object object) {
+      try {
+          Invoker method = metaClass.getGetInvoker(prop.getName());
+          try {
+              return method.invoke(object, NO_ARGUMENTS);
+          } catch (Throwable t) {
+              throw ExceptionUtil.unwrapThrowable(t);
+          }
+      } catch (RuntimeException e) {
+          throw e;
+      } catch (Throwable t) {
+          throw new ReflectionException("Could not get property '" + prop.getName() + "' from " + object.getClass() + ".  Cause: " + t.toString(), t);
+      }
+  }
+  ```
+
+  - 通过调用 Invoker 方法，获得属性的值。
+
+#### 8.1.1.2 set
+
+`#set(PropertyTokenizer prop, Object value)` 方法，设置指定属性的值。代码如下：
+
+```
+// BeanWrapper.java
+
+@Override
+public void set(PropertyTokenizer prop, Object value) {
+    // 设置集合类型的属性的指定位置的值
+    if (prop.getIndex() != null) {
+        // 获得集合类型的属性
+        Object collection = resolveCollection(prop, object);
+        // 设置指定位置的值
+        setCollectionValue(prop, collection, value);
+    // 设置属性的值
+    } else {
+        setBeanProperty(prop, object, value);
+    }
+}
+
+private void setBeanProperty(PropertyTokenizer prop, Object object, Object value) {
+    try {
+        Invoker method = metaClass.getSetInvoker(prop.getName());
+        Object[] params = {value};
+        try {
+            method.invoke(object, params);
+        } catch (Throwable t) {
+            throw ExceptionUtil.unwrapThrowable(t);
+        }
+    } catch (Throwable t) {
+        throw new ReflectionException("Could not set property '" + prop.getName() + "' of '" + object.getClass() + "' with value '" + value + "' Cause: " + t.toString(), t);
+    }
+}
+```
+
+- 比较简单，胖友直接看看就成。
+
+#### 8.1.1.3 getGetterType
+
+`#getGetterType(String name)` 方法，获得指定属性的 getting 方法的返回值。代码如下：
+
+```
+// BeanWrapper.java
+
+@Override
+public Class<?> getGetterType(String name) {
+    // 创建 PropertyTokenizer 对象，对 name 进行分词
+    PropertyTokenizer prop = new PropertyTokenizer(name);
+    // 有子表达式
+    if (prop.hasNext()) {
+        // <1> 创建 MetaObject 对象
+        MetaObject metaValue = metaObject.metaObjectForProperty(prop.getIndexedName());
+        // 如果 metaValue 为空，则基于 metaClass 获得返回类型
+        if (metaValue == SystemMetaObject.NULL_META_OBJECT) {
+            return metaClass.getGetterType(name);
+        // 如果 metaValue 非空，则基于 metaValue 获得返回类型。
+        // 例如：richType.richMap.nihao ，其中 richMap 是 Map 类型，而 nihao 的类型，需要获得到 nihao 的具体值，才能做真正的判断。
+        } else {
+            // 递归判断子表达式 children ，获得返回值的类型
+            return metaValue.getGetterType(prop.getChildren());
+        }
+    // 有子表达式
+    } else {
+        // 直接获得返回值的类型
+        return metaClass.getGetterType(name);
+    }
+}
+```
+
+- 大体逻辑和 MetaClass 的 `#getGetterType(String name)` 方法是一致的。差异点主要在 `<1>` 处。
+
+- ```
+  <1>
+  ```
+
+   
+
+  处，基于当前属性，创建 MetaObject 对象。如果该属性对应的值为空，那么
+
+   
+
+  ```
+  metaValue
+  ```
+
+   
+
+  会等于
+
+   
+
+  ```
+  SystemMetaObject.NULL_META_OBJECT
+  ```
+
+   
+
+  。也因为为空，那么就不能基于
+
+   
+
+  ```
+  metaValue
+  ```
+
+   
+
+  去做递归，获取返回值的类型。
+
+  - 关于 MetaObject 类，在 [「10. MetaObject」](https://svip.iocoder.cn/MyBatis/reflection-package/#) 中详细解析。
+
+- 当然，以上说起来比较绕，可以添加如下测试用例，跑一次就大体明白了。代码如下：
+
+  ```
+  @Test
+  public void test01() {
+      RichType object = new RichType();
+  
+      if (true) {
+          object.setRichType(new RichType());
+          object.getRichType().setRichMap(new HashMap());
+          object.getRichType().getRichMap().put("nihao", "123");
+      }
+  
+      MetaObject meta = MetaObject.forObject(object, SystemMetaObject.DEFAULT_OBJECT_FACTORY, new CustomBeanWrapperFactory(), new DefaultReflectorFactory());
+      Class<?> clazz = meta.getObjectWrapper().getGetterType("richType.richMap.nihao");
+      System.out.println(clazz);
+  }
+  ```
+
+  - 这个测试用例，就是笔者在代码注释上添加的“例如：`richType.richMap.nihao` ，其中 `richMap` 是 Map 类型，而 `nihao` 的类型，需要获得到 `nihao` 的具体值，才能做真正的判断。”
+
+------
+
+`#getSetterType(String name)` 方法，获得指定属性的 setting 方法的方法参数。逻辑上和 `#getGetterType(String name)` 方法类似的，所以感兴趣的胖友，自己研究。
+
+#### 8.1.1.6 hasGetter
+
+`#hasGetter(String name)` 方法，是否有指定属性的 getting 方法。代码如下：
+
+```
+// BeanWrapper.java
+
+@Override
+public boolean hasGetter(String name) {
+    // 创建 PropertyTokenizer 对象，对 name 进行分词
+    PropertyTokenizer prop = new PropertyTokenizer(name);
+    // 有子表达式
+    if (prop.hasNext()) {
+        // 判断是否有该属性的 getting 方法
+        if (metaClass.hasGetter(prop.getIndexedName())) {
+            // 创建 MetaObject 对象
+            MetaObject metaValue = metaObject.metaObjectForProperty(prop.getIndexedName());
+            // 如果 metaValue 为空，则基于 metaClass 判断是否有该属性的 getting 方法
+            if (metaValue == SystemMetaObject.NULL_META_OBJECT) {
+                return metaClass.hasGetter(name);
+            // 如果 metaValue 非空，则基于 metaValue 判断是否有 getting 方法。
+            } else {
+                // 递归判断子表达式 children ，判断是否有 getting 方法
+                return metaValue.hasGetter(prop.getChildren());
+            }
+        } else {
+            return false;
+        }
+    // 有子表达式
+    } else {
+        // 判断是否有该属性的 getting 方法
+        return metaClass.hasGetter(name);
+    }
+}
+```
+
+和 `#getGetterType(String name)` 方法类似，胖友可以自己瞅瞅。
+
+------
+
+`#hasSetter(String name)` 方法，判断指定属性是否有 setting 方法的方法。逻辑上和 `#hasGetter(String name)` 方法类似的，所以感兴趣的胖友，自己研究。
+
+#### 8.1.1.5 instantiatePropertyValue
+
+`#instantiatePropertyValue(String name, PropertyTokenizer prop, ObjectFactory objectFactory)` 方法，创建指定属性的值。代码如下：
+
+```
+// BeanWrapper.java
+
+@Override
+public MetaObject instantiatePropertyValue(String name, PropertyTokenizer prop, ObjectFactory objectFactory) {
+    MetaObject metaValue;
+    // 获得 setting 方法的方法参数类型
+    Class<?> type = getSetterType(prop.getName());
+    try {
+        // 创建对象
+        Object newObject = objectFactory.create(type);
+        // 创建 MetaObject 对象
+        metaValue = MetaObject.forObject(newObject, metaObject.getObjectFactory(), metaObject.getObjectWrapperFactory(), metaObject.getReflectorFactory());
+        // <1> 设置当前对象的值
+        set(prop, newObject);
+    } catch (Exception e) {
+        throw new ReflectionException("Cannot set value of property '" + name + "' because '" + name + "' is null and cannot be instantiated on instance of " + type.getName() + ". Cause:" + e.toString(), e);
+    }
+    return metaValue;
+}
+```
+
+- `<1>` 处，调用 `#set(PropertyTokenizer prop, Object value)` 方法，设置 `newObject` 到当前对象的 `prop` 属性种。
+- 关于这个方法，可能比较难理解，可以调试下 `MetaObjectTest#shouldGetAndSetNestedMapPairUsingArraySyntax()` 这个单元测试方法。
+
+#### 8.1.1.6 isCollection
+
+`#isCollection()` 方法，返回 `false` ，表示不是集合。代码如下：
+
+```
+// BeanWrapper.java
+
+@Override
+public boolean isCollection() {
+    return false;
+}
+```
+
+因此，`#add(Object element)` 和 `#addAll(List<E> list)` 方法都是不支持的，直接抛出 UnsupportedOperationException 异常。代码如下：
+
+```
+// BeanWrapper.java
+
+@Override
+public void add(Object element) {
+    throw new UnsupportedOperationException();
+}
+
+@Override
+public <E> void addAll(List<E> list) {
+    throw new UnsupportedOperationException();
+}
+```
+
+### 8.1.2 MapWrapper
+
+`org.apache.ibatis.reflection.wrapper.MapWrapper` ，继承 BaseWrapper 抽象类，**Map** 对象的 ObjectWrapper 实现类。
+
+MapWrapper 和 BeanWrapper 的大体逻辑是一样的，差异点主要如下：
+
+```
+// MapWrapper.java
+
+// object 变成了 map
+private final Map<String, Object> map;
+
+// 属性的操作变成了
+map.put(prop.getName(), value);
+map.get(prop.getName());
+```
+
+- 这里就不详细解析了，感兴趣的胖友，自己查看下噢。
+
+## 8.2 CollectionWrapper
+
+`org.apache.ibatis.reflection.wrapper.CollectionWrapper` ，实现 ObjectWrapper 接口，集合 ObjectWrapper 实现类。比较简单，直接看代码：
+
+```
+// CollectionWrapper.java
+
+public class CollectionWrapper implements ObjectWrapper {
+
+    private final Collection<Object> object;
+
+    public CollectionWrapper(MetaObject metaObject, Collection<Object> object) {
+        this.object = object;
+    }
+
+    @Override
+    public Object get(PropertyTokenizer prop) {
+        throw new UnsupportedOperationException();
+    }
+
+    @Override
+    public void set(PropertyTokenizer prop, Object value) {
+        throw new UnsupportedOperationException();
+    }
+
+    @Override
+    public String findProperty(String name, boolean useCamelCaseMapping) {
+        throw new UnsupportedOperationException();
+    }
+
+    @Override
+    public String[] getGetterNames() {
+        throw new UnsupportedOperationException();
+    }
+
+    @Override
+    public String[] getSetterNames() {
+        throw new UnsupportedOperationException();
+    }
+
+    @Override
+    public Class<?> getSetterType(String name) {
+        throw new UnsupportedOperationException();
+    }
+
+    @Override
+    public Class<?> getGetterType(String name) {
+        throw new UnsupportedOperationException();
+    }
+
+    @Override
+    public boolean hasSetter(String name) {
+        throw new UnsupportedOperationException();
+    }
+
+    @Override
+    public boolean hasGetter(String name) {
+        throw new UnsupportedOperationException();
+    }
+
+    @Override
+    public MetaObject instantiatePropertyValue(String name, PropertyTokenizer prop, ObjectFactory objectFactory) {
+        throw new UnsupportedOperationException();
+    }
+
+    @Override
+    public boolean isCollection() {
+        return true;
+    }
+
+    @Override
+    public void add(Object element) {
+        object.add(element);
+    }
+
+    @Override
+    public <E> void addAll(List<E> element) {
+        object.addAll(element);
+    }
+
+}
+```
+
+- 仅仅支持 `#add(Object element)` 和 `#addAll(List<E> element)` 两个操作方法。
+
+# 9. ObjectWrapperFactory
+
+`org.apache.ibatis.reflection.wrapper.ObjectWrapperFactory` ，ObjectWrapper 工厂接口。代码如下：
+
+```
+// ObjectWrapperFactory.java
+
+public interface ObjectWrapperFactory {
+
+    /**
+     * 是否包装了指定对象
+     *
+     * @param object 指定对象
+     * @return 是否
+     */
+    boolean hasWrapperFor(Object object);
+
+    /**
+     * 获得指定对象的 ObjectWrapper 对象
+     *
+     * @param metaObject MetaObject 对象
+     * @param object 指定对象
+     * @return ObjectWrapper 对象
+     */
+    ObjectWrapper getWrapperFor(MetaObject metaObject, Object object);
+
+}
+```
+
+## 9.1 DefaultObjectWrapperFactory
+
+`org.apache.ibatis.reflection.wrapper.DefaultObjectWrapperFactory` ，实现 ObjectWrapperFactory 接口，**默认** ObjectWrapperFactory 实现类。代码如下：
+
+```
+public class DefaultObjectWrapperFactory implements ObjectWrapperFactory {
+
+    @Override
+    public boolean hasWrapperFor(Object object) {
+        return false;
+    }
+
+    @Override
+    public ObjectWrapper getWrapperFor(MetaObject metaObject, Object object) {
+        throw new ReflectionException("The DefaultObjectWrapperFactory should never be called to provide an ObjectWrapper.");
+    }
+
+}
+```
+
+- 诶？貌似是个空的实现类？？？实际上，默认情况下，我们是不使用 ObjectWrapperFactory 对象的。
+
+# 10. MetaObject
+
+`org.apache.ibatis.reflection.MetaObject` ，对象元数据，提供了对象的属性值的获得和设置等等方法。😈 可以理解成，对 BaseWrapper 操作的进一步**增强**。
+
+## 10.1 构造方法
+
+```
+// MetaObject.java
+
+/**
+ * 原始 Object 对象
+ */
+private final Object originalObject;
+/**
+ * 封装过的 Object 对象
+ */
+private final ObjectWrapper objectWrapper;
+private final ObjectFactory objectFactory;
+private final ObjectWrapperFactory objectWrapperFactory;
+private final ReflectorFactory reflectorFactory;
+
+private MetaObject(Object object, ObjectFactory objectFactory, ObjectWrapperFactory objectWrapperFactory, ReflectorFactory reflectorFactory) {
+    this.originalObject = object;
+    this.objectFactory = objectFactory;
+    this.objectWrapperFactory = objectWrapperFactory;
+    this.reflectorFactory = reflectorFactory;
+
+    // <1>
+    if (object instanceof ObjectWrapper) {
+        this.objectWrapper = (ObjectWrapper) object;
+    } else if (objectWrapperFactory.hasWrapperFor(object)) { // <2>
+        // 创建 ObjectWrapper 对象
+        this.objectWrapper = objectWrapperFactory.getWrapperFor(this, object);
+    } else if (object instanceof Map) {
+        // 创建 MapWrapper 对象
+        this.objectWrapper = new MapWrapper(this, (Map) object);
+    } else if (object instanceof Collection) {
+        // 创建 CollectionWrapper 对象
+        this.objectWrapper = new CollectionWrapper(this, (Collection) object);
+    } else {
+        // 创建 BeanWrapper 对象
+        this.objectWrapper = new BeanWrapper(this, object);
+    }
+}
+```
+
+- ```
+  <1>
+  ```
+
+   
+
+  处，会根据
+
+   
+
+  ```
+  object
+  ```
+
+   
+
+  类型的不同，创建对应的 ObjectWrapper 对象。
+
+  - 其中，`<2>` 处，我们可以看到 ObjectWrapperFactory 的使用，因为默认情况下的 DefaultObjectWrapperFactory 未实现任何逻辑，所以这块逻辑相当于暂时不起作用。如果想要起作用，需要自定义 ObjectWrapperFactory 的实现类。
+
+## 10.2 forObject
+
+`#forObject(Object object, ObjectFactory objectFactory, ObjectWrapperFactory objectWrapperFactory, ReflectorFactory reflectorFactory)` **静态**方法，创建 MetaObject 对象。代码如下：
+
+```
+// MetaObject.java
+
+/**
+ * 创建 MetaObject 对象
+ *
+ * @param object 原始 Object 对象
+ * @param objectFactory
+ * @param objectWrapperFactory
+ * @param reflectorFactory
+ * @return MetaObject 对象
+ */
+public static MetaObject forObject(Object object, ObjectFactory objectFactory, ObjectWrapperFactory objectWrapperFactory, ReflectorFactory reflectorFactory) {
+    if (object == null) {
+        return SystemMetaObject.NULL_META_OBJECT;
+    } else {
+        return new MetaObject(object, objectFactory, objectWrapperFactory, reflectorFactory);
+    }
+}
+```
+
+- 如果 `object` 为**空**的情况下，返回 `SystemMetaObject.NULL_META_OBJECT` 。
+
+## 10.3 metaObjectForProperty
+
+`#metaObjectForProperty(String name)` 方法，创建指定属性的 MetaObject 对象。代码如下：
+
+```
+// MetaObject.java
+
+public MetaObject metaObjectForProperty(String name) {
+    // 获得属性值
+    Object value = getValue(name);
+    // 创建 MetaObject 对象
+    return MetaObject.forObject(value, objectFactory, objectWrapperFactory, reflectorFactory);
+}
+```
+
+## 10.4 getValue
+
+`#getValue(String name)` 方法，获得指定属性的值。代码如下：
+
+```
+// MetaObject.java
+
+public Object getValue(String name) {
+    // 创建 PropertyTokenizer 对象，对 name 分词
+    PropertyTokenizer prop = new PropertyTokenizer(name);
+    // 有子表达式
+    if (prop.hasNext()) {
+        // 创建 MetaObject 对象
+        MetaObject metaValue = metaObjectForProperty(prop.getIndexedName());
+        // <2> 递归判断子表达式 children ，获取值
+        if (metaValue == SystemMetaObject.NULL_META_OBJECT) {
+            return null;
+        } else {
+            return metaValue.getValue(prop.getChildren());
+        }
+    // 无子表达式
+    } else {
+        // <1> 获取值
+        return objectWrapper.get(prop);
+    }
+}
+```
+
+- 大体逻辑上，就是不断对 `name` 分词，递归查找属性，直到 `<1>` 处，返回最终的结果。
+- 比较特殊的是，在 `<2>` 处，如果属性的值为 `null` 时，则直接返回 `null` ，因为值就是空的哈。
+
+## 10.5 setValue
+
+`#setValue(String name, Object value)` 方法，设置指定属性的指定值。代码如下：
+
+```
+// MetaObject.java
+
+public void setValue(String name, Object value) {
+    // 创建 PropertyTokenizer 对象，对 name 分词
+    PropertyTokenizer prop = new PropertyTokenizer(name);
+    // 有子表达式
+    if (prop.hasNext()) {
+        // 创建 MetaObject 对象
+        MetaObject metaValue = metaObjectForProperty(prop.getIndexedName());
+        // 递归判断子表达式 children ，设置值
+        if (metaValue == SystemMetaObject.NULL_META_OBJECT) {
+            if (value == null) {
+                // don't instantiate child path if value is null
+                return;
+            } else {
+                // <1> 创建值
+                metaValue = objectWrapper.instantiatePropertyValue(name, prop, objectFactory);
+            }
+        }
+        // 设置值
+        metaValue.setValue(prop.getChildren(), value);
+    // 无子表达式
+    } else {
+        // <1> 设置值
+        objectWrapper.set(prop, value);
+    }
+}
+```
+
+- 大体逻辑上，就是不断对 `name` 分词，递归查找属性，最终在 `<1>` 处，设置对应的值。
+- 比较特殊的是，在 `<2>` 处，如果属性的值为 `null` 时，调用 `ObjectWrapper#instantiatePropertyValue(name, prop, objectFactory)` 方法，创建**当前** `name` 的 `prop` 属性的空对象，然后继续递归。可能有点难理解，胖友可以调试下 `MetaObjectTest#shouldGetAndSetNestedMapPairUsingArraySyntax()` 这个单元测试方法。
+
+## 10.6 isCollection
+
+`#isCollection()` 方法，判断是否为集合。代码如下：
+
+```
+// MetaObject.java
+
+public boolean isCollection() {
+    return objectWrapper.isCollection();
+}
+
+public void add(Object element) {
+    objectWrapper.add(element);
+}
+
+public <E> void addAll(List<E> list) {
+    objectWrapper.addAll(list);
+}
+```
+
+- 直接调用 `objectWrapper` 的对应的方法。
+
+# 11. SystemMetaObject
+
+`org.apache.ibatis.reflection.SystemMetaObject` ，系统级的 MetaObject 对象，主要提供了 ObjectFactory、ObjectWrapperFactory、空 MetaObject 的单例。代码如下：
+
+```
+// SystemMetaObject.java
+
+public final class SystemMetaObject {
+
+    /**
+     * ObjectFactory 的单例
+     */
+    public static final ObjectFactory DEFAULT_OBJECT_FACTORY = new DefaultObjectFactory();
+    /**
+     * ObjectWrapperFactory 的单例
+     */
+    public static final ObjectWrapperFactory DEFAULT_OBJECT_WRAPPER_FACTORY = new DefaultObjectWrapperFactory();
+
+    /**
+     * 空对象的 MetaObject 对象单例
+     */
+    public static final MetaObject NULL_META_OBJECT = MetaObject.forObject(NullObject.class, DEFAULT_OBJECT_FACTORY, DEFAULT_OBJECT_WRAPPER_FACTORY, new DefaultReflectorFactory());
+
+    private SystemMetaObject() {
+        // Prevent Instantiation of Static Class
+    }
+
+    private static class NullObject {
+    }
+
+    /**
+     * 创建 MetaObject 对象
+     *
+     * @param object 指定对象
+     * @return MetaObject 对象
+     */
+    public static MetaObject forObject(Object object) {
+        return MetaObject.forObject(object, DEFAULT_OBJECT_FACTORY, DEFAULT_OBJECT_WRAPPER_FACTORY, new DefaultReflectorFactory());
+    }
+
+}
+```
+
+- 核心就是 `#forObject(Object object)` 方法，创建指定对象的 MetaObject 对象。
+
+# 12. ParamNameUtil
+
+`org.apache.ibatis.reflection.ParamNameUtil` ，参数名工具类，获得构造方法、普通方法的参数列表。代码如下：
+
+```
+// ParamNameUtil.java
+
+public class ParamNameUtil {
+
+    /**
+     * 获得普通方法的参数列表
+     *
+     * @param method 普通方法
+     * @return 参数集合
+     */
+    public static List<String> getParamNames(Method method) {
+        return getParameterNames(method);
+    }
+
+    /**
+     * 获得构造方法的参数列表
+     *
+     * @param constructor 构造方法
+     * @return 参数集合
+     */
+    public static List<String> getParamNames(Constructor<?> constructor) {
+        return getParameterNames(constructor);
+    }
+
+    private static List<String> getParameterNames(Executable executable) {
+        final List<String> names = new ArrayList<>();
+        // 获得 Parameter 数组
+        final Parameter[] params = executable.getParameters();
+        // 获得参数名，并添加到 names 中
+        for (Parameter param : params) {
+            names.add(param.getName());
+        }
+        return names;
+    }
+
+    private ParamNameUtil() {
+        super();
+    }
+
+}
+```
+
+# 13. ParamNameResolver
+
+`org.apache.ibatis.reflection.ParamNameResolver` ，参数名解析器。
+
+## 13.1 构造方法
+
+```
+// ParamNameResolver.java
+
+/**
+ * <p>
+ * The key is the index and the value is the name of the parameter.<br />
+ * The name is obtained from {@link Param} if specified. When {@link Param} is not specified,
+ * the parameter index is used. Note that this index could be different from the actual index
+ * when the method has special parameters (i.e. {@link RowBounds} or {@link ResultHandler}).
+ * </p>
+ * <ul>
+ * <li>aMethod(@Param("M") int a, @Param("N") int b) -&gt; {{0, "M"}, {1, "N"}}</li>
+ * <li>aMethod(int a, int b) -&gt; {{0, "0"}, {1, "1"}}</li>
+ * <li>aMethod(int a, RowBounds rb, int b) -&gt; {{0, "0"}, {2, "1"}}</li>
+ * </ul>
+ *
+ * 参数名映射
+ *
+ * KEY：参数顺序
+ * VALUE：参数名
+ */
+private final SortedMap<Integer, String> names;
+/**
+ * 是否有 {@link Param} 注解的参数
+ */
+private boolean hasParamAnnotation;
+
+public ParamNameResolver(Configuration config, Method method) {
+    final Class<?>[] paramTypes = method.getParameterTypes();
+    final Annotation[][] paramAnnotations = method.getParameterAnnotations();
+    final SortedMap<Integer, String> map = new TreeMap<>();
+    int paramCount = paramAnnotations.length;
+    // get names from @Param annotations
+    for (int paramIndex = 0; paramIndex < paramCount; paramIndex++) {
+        // 忽略，如果是特殊参数
+        if (isSpecialParameter(paramTypes[paramIndex])) {
+            // skip special parameters
+            continue;
+        }
+        String name = null;
+        // 首先，从 @Param 注解中获取参数
+        for (Annotation annotation : paramAnnotations[paramIndex]) {
+            if (annotation instanceof Param) {
+                hasParamAnnotation = true;
+                name = ((Param) annotation).value();
+                break;
+            }
+        }
+        if (name == null) {
+            // @Param was not specified.
+            // 其次，获取真实的参数名
+            if (config.isUseActualParamName()) { // 默认开启
+                name = getActualParamName(method, paramIndex);
+            }
+            // 最差，使用 map 的顺序，作为编号
+            if (name == null) {
+                // use the parameter index as the name ("0", "1", ...)
+                // gcode issue #71
+                name = String.valueOf(map.size());
+            }
+        }
+        // 添加到 map 中
+        map.put(paramIndex, name);
+    }
+    // 构建不可变集合
+    names = Collections.unmodifiableSortedMap(map);
+}
+
+private String getActualParamName(Method method, int paramIndex) {
+    return ParamNameUtil.getParamNames(method).get(paramIndex);
+}
+
+private static boolean isSpecialParameter(Class<?> clazz) {
+    return RowBounds.class.isAssignableFrom(clazz) || ResultHandler.class.isAssignableFrom(clazz);
+}
+```
+
+- 代码比较简单，胖友看下注释。
+
+## 13.2 getNamedParams
+
+`#getNamedParams(Object[] args)` 方法，获得参数名与值的映射。代码如下：
+
+```
+// ParamNameResolver.java
+
+private static final String GENERIC_NAME_PREFIX = "param";
+
+/**
+ * <p>
+ * A single non-special parameter is returned without a name.
+ * Multiple parameters are named using the naming rule.
+ * In addition to the default names, this method also adds the generic names (param1, param2,
+ * ...).
+ * </p>
+ *
+ * 获得参数名与值的映射
+ */
+public Object getNamedParams(Object[] args) {
+    final int paramCount = names.size();
+    // 无参数，则返回 null
+    if (args == null || paramCount == 0) {
+        return null;
+    // 只有一个非注解的参数，直接返回首元素
+    } else if (!hasParamAnnotation && paramCount == 1) {
+        return args[names.firstKey()];
+    } else {
+        // 集合。
+        // 组合 1 ：KEY：参数名，VALUE：参数值
+        // 组合 2 ：KEY：GENERIC_NAME_PREFIX + 参数顺序，VALUE ：参数值
+        final Map<String, Object> param = new ParamMap<>();
+        int i = 0;
+        // 遍历 names 集合
+        for (Map.Entry<Integer, String> entry : names.entrySet()) {
+            // 组合 1 ：添加到 param 中
+            param.put(entry.getValue(), args[entry.getKey()]);
+            // add generic param names (param1, param2, ...)
+            // 组合 2 ：添加到 param 中
+            final String genericParamName = GENERIC_NAME_PREFIX + String.valueOf(i + 1);
+            // ensure not to overwrite parameter named with @Param
+            if (!names.containsValue(genericParamName)) {
+                param.put(genericParamName, args[entry.getKey()]);
+            }
+            i++;
+        }
+        return param;
+    }
+}
+```
+
+- 代码比较简单，胖友看下注释。
+
+# 14. TypeParameterResolver
+
+`org.apache.ibatis.reflection.TypeParameterResolver` ，工具类，`java.lang.reflect.Type` 参数解析器。因为 Type 是相对冷门的知识，我表示也不会，所以推荐先阅读如下任一文章：
+
+- 贾博岩 [《我眼中的 Java-Type 体系(1)》](https://www.jianshu.com/p/7649f86614d3)
+- xujun9411 [《java Type 详解》](https://www.jianshu.com/p/cae76008b36b)
+
+> FROM 西瓜1994 [《MyBatis源码分析-2-基础支持层-反射模块-TypeParameterResolver/ObjectFactory》](https://my.oschina.net/u/3905482/blog/2249537)
+>
+> 当存在复杂的继承关系以及泛型定义时， TypeParameterResolver 可以帮助我们解析字段、方法参数或方法返回值的类型。
+
+## 14.1 暴露方法
+
+TypeParameterResolver 暴露了**三个** 公用静态方法，分别用于解析 Field 类型、Method 返回类型、方法参数类型。代码如下：
+
+```
+// TypeParameterResolver.java
+
+/**
+ * 解析属性类型
+ *
+ * @return The field type as {@link Type}. If it has type parameters in the declaration,<br>
+ *         they will be resolved to the actual runtime {@link Type}s.
+ */
+public static Type resolveFieldType(Field field, Type srcType) {
+    // 属性类型
+    Type fieldType = field.getGenericType();
+    // 定义的类
+    Class<?> declaringClass = field.getDeclaringClass();
+    // 解析类型
+    return resolveType(fieldType, srcType, declaringClass);
+}
+
+/**
+ * 解析方法返回类型
+ *
+ * @return The return type of the method as {@link Type}. If it has type parameters in the declaration,<br>
+ *         they will be resolved to the actual runtime {@link Type}s.
+ */
+public static Type resolveReturnType(Method method, Type srcType) {
+    // 属性类型
+    Type returnType = method.getGenericReturnType();
+    // 定义的类
+    Class<?> declaringClass = method.getDeclaringClass();
+    // 解析类型
+    return resolveType(returnType, srcType, declaringClass);
+}
+
+/**
+ * 解析方法参数的类型数组
+ *
+ * @return The parameter types of the method as an array of {@link Type}s. If they have type parameters in the declaration,<br>
+ *         they will be resolved to the actual runtime {@link Type}s.
+ */
+public static Type[] resolveParamTypes(Method method, Type srcType) {
+    // 获得方法参数类型数组
+    Type[] paramTypes = method.getGenericParameterTypes();
+    // 定义的类
+    Class<?> declaringClass = method.getDeclaringClass();
+    // 解析类型们
+    Type[] result = new Type[paramTypes.length];
+    for (int i = 0; i < paramTypes.length; i++) {
+        result[i] = resolveType(paramTypes[i], srcType, declaringClass);
+    }
+    return result;
+}
+```
+
+- 大体逻辑都类似，最终都会调用 `#resolveType(Type type, Type srcType, Class<?> declaringClass)` 方法，解析类型。详细解析，见 [「4.2 resolveType」](https://svip.iocoder.cn/MyBatis/reflection-package/#) 。
+
+## 14.2 resolveType
+
+`#resolveType(Type type, Type srcType, Class<?> declaringClass)` 方法，解析 `type` 类型。代码如下：
+
+```
+// TypeParameterResolver.java
+
+/**
+ * 解析类型
+ *
+ * @param type 类型
+ * @param srcType 来源类型
+ * @param declaringClass 定义的类
+ * @return 解析后的类型
+ */
+private static Type resolveType(Type type, Type srcType, Class<?> declaringClass) {
+    if (type instanceof TypeVariable) {
+        return resolveTypeVar((TypeVariable<?>) type, srcType, declaringClass);
+    } else if (type instanceof ParameterizedType) {
+        return resolveParameterizedType((ParameterizedType) type, srcType, declaringClass);
+    } else if (type instanceof GenericArrayType) {
+        return resolveGenericArrayType((GenericArrayType) type, srcType, declaringClass);
+    } else {
+        return type;
+    }
+}
+```
+
+- 根据 `type` 对应不同的 Type 类型，调用不同的方法，进行解析。
+
+### 14.2.1 resolveParameterizedType
+
+`#resolveParameterizedType(ParameterizedType parameterizedType, Type srcType, Class<?> declaringClass)` 方法，解析 ParameterizedType 类型。代码如下：
+
+```
+// TypeParameterResolver.java
+
+/**
+ * 解析 ParameterizedType 类型
+ *
+ * @param parameterizedType ParameterizedType 类型
+ * @param srcType 来源类型
+ * @param declaringClass 定义的类
+ * @return 解析后的类型
+ */
+private static ParameterizedType resolveParameterizedType(ParameterizedType parameterizedType, Type srcType, Class<?> declaringClass) {
+    Class<?> rawType = (Class<?>) parameterizedType.getRawType();
+    // 【1】解析 <> 中实际类型
+    Type[] typeArgs = parameterizedType.getActualTypeArguments();
+    Type[] args = new Type[typeArgs.length];
+    for (int i = 0; i < typeArgs.length; i++) {
+        if (typeArgs[i] instanceof TypeVariable) {
+            args[i] = resolveTypeVar((TypeVariable<?>) typeArgs[i], srcType, declaringClass);
+        } else if (typeArgs[i] instanceof ParameterizedType) {
+            args[i] = resolveParameterizedType((ParameterizedType) typeArgs[i], srcType, declaringClass);
+        } else if (typeArgs[i] instanceof WildcardType) {
+            args[i] = resolveWildcardType((WildcardType) typeArgs[i], srcType, declaringClass);
+        } else {
+            args[i] = typeArgs[i];
+        }
+    }
+    // 【2】
+    return new ParameterizedTypeImpl(rawType, null, args);
+}
+```
+
+- `【1】` 处，解析 `<>` 中实际类型。
+
+- `【2】` 处，创建 ParameterizedTypeImpl 对象。代码如下：
+
+  ```
+  // TypeParameterResolver.java 内部静态类
+  
+  /**
+   * ParameterizedType 实现类
+   *
+   * 参数化类型，即泛型。例如：List<T>、Map<K, V>等带有参数化的配置
+   */
+  static class ParameterizedTypeImpl implements ParameterizedType {
+  
+      // 以 List<T> 举例子
+  
+      /**
+       * <> 前面实际类型
+       *
+       * 例如：List
+       */
+      private Class<?> rawType;
+      /**
+       * 如果这个类型是某个属性所有，则获取这个所有者类型；否则，返回 null
+       */
+      private Type ownerType;
+      /**
+       * <> 中实际类型
+       *
+       * 例如：T
+       */
+      private Type[] actualTypeArguments;
+  
+      public ParameterizedTypeImpl(Class<?> rawType, Type ownerType, Type[] actualTypeArguments) {
+          super();
+          this.rawType = rawType;
+          this.ownerType = ownerType;
+          this.actualTypeArguments = actualTypeArguments;
+      }
+  
+      @Override
+      public Type[] getActualTypeArguments() {
+          return actualTypeArguments;
+      }
+  
+      @Override
+      public Type getOwnerType() {
+          return ownerType;
+      }
+  
+      @Override
+      public Type getRawType() {
+          return rawType;
+      }
+  
+      @Override
+      public String toString() {
+          return "ParameterizedTypeImpl [rawType=" + rawType + ", ownerType=" + ownerType + ", actualTypeArguments=" + Arrays.toString(actualTypeArguments) + "]";
+      }
+  
+  }
+  ```
+
+### 14.2.2 resolveWildcardType
+
+`#resolveWildcardType(WildcardType wildcardType, Type srcType, Class<?> declaringClass)` 方法，解析 WildcardType 类型。代码如下：
+
+```
+// TypeParameterResolver.java
+
+private static Type resolveWildcardType(WildcardType wildcardType, Type srcType, Class<?> declaringClass) {
+    // <1.1> 解析泛型表达式下界（下限 super）
+    Type[] lowerBounds = resolveWildcardTypeBounds(wildcardType.getLowerBounds(), srcType, declaringClass);
+    // <1.2> 解析泛型表达式上界（上限 extends）
+    Type[] upperBounds = resolveWildcardTypeBounds(wildcardType.getUpperBounds(), srcType, declaringClass);
+    // <2> 创建 WildcardTypeImpl 对象
+    return new WildcardTypeImpl(lowerBounds, upperBounds);
+}
+
+private static Type[] resolveWildcardTypeBounds(Type[] bounds, Type srcType, Class<?> declaringClass) {
+    Type[] result = new Type[bounds.length];
+    for (int i = 0; i < bounds.length; i++) {
+        if (bounds[i] instanceof TypeVariable) {
+            result[i] = resolveTypeVar((TypeVariable<?>) bounds[i], srcType, declaringClass);
+        } else if (bounds[i] instanceof ParameterizedType) {
+            result[i] = resolveParameterizedType((ParameterizedType) bounds[i], srcType, declaringClass);
+        } else if (bounds[i] instanceof WildcardType) {
+            result[i] = resolveWildcardType((WildcardType) bounds[i], srcType, declaringClass);
+        } else {
+            result[i] = bounds[i];
+        }
+    }
+    return result;
+}
+```
+
+- `<1.1>`、`<1.2>` 处，解析泛型表达式下界（下限 `super`）和上界( 上限 `extends` )。
+
+- `<2>` 创建 WildcardTypeImpl 对象。代码如下：
+
+  ```
+  // TypeParameterResolver.java 内部静态类
+  
+  /**
+   * WildcardType 实现类
+   *
+   * 泛型表达式（或者通配符表达式），即 ? extend Number、? super Integer 这样的表达式。
+   * WildcardType 虽然是 Type 的子接口，但却不是 Java 类型中的一种。
+   */
+  static class WildcardTypeImpl implements WildcardType {
+  
+      /**
+       * 泛型表达式下界（下限 super）
+       */
+      private Type[] lowerBounds;
+      /**
+       * 泛型表达式上界（上界 extends）
+       */
+      private Type[] upperBounds;
+  
+      WildcardTypeImpl(Type[] lowerBounds, Type[] upperBounds) {
+          super();
+          this.lowerBounds = lowerBounds;
+          this.upperBounds = upperBounds;
+      }
+  
+      @Override
+      public Type[] getLowerBounds() {
+          return lowerBounds;
+      }
+  
+      @Override
+      public Type[] getUpperBounds() {
+          return upperBounds;
+      }
+  }
+  
+  static class GenericArrayTypeImpl implements GenericArrayType {
+      private Type genericComponentType;
+  
+      GenericArrayTypeImpl(Type genericComponentType) {
+          super();
+          this.genericComponentType = genericComponentType;
+      }
+  
+      @Override
+      public Type getGenericComponentType() {
+          return genericComponentType;
+      }
+  }
+  ```
+
+### 14.2.3 resolveGenericArrayType
+
+```
+// TypeParameterResolver.java
+
+private static Type resolveGenericArrayType(GenericArrayType genericArrayType, Type srcType, Class<?> declaringClass) {
+    // 【1】解析 componentType
+    Type componentType = genericArrayType.getGenericComponentType();
+    Type resolvedComponentType = null;
+    if (componentType instanceof TypeVariable) {
+        resolvedComponentType = resolveTypeVar((TypeVariable<?>) componentType, srcType, declaringClass);
+    } else if (componentType instanceof GenericArrayType) {
+        resolvedComponentType = resolveGenericArrayType((GenericArrayType) componentType, srcType, declaringClass);
+    } else if (componentType instanceof ParameterizedType) {
+        resolvedComponentType = resolveParameterizedType((ParameterizedType) componentType, srcType, declaringClass);
+    }
+    // 【2】创建 GenericArrayTypeImpl 对象
+    if (resolvedComponentType instanceof Class) {
+        return Array.newInstance((Class<?>) resolvedComponentType, 0).getClass();
+    } else {
+        return new GenericArrayTypeImpl(resolvedComponentType);
+    }
+}
+```
+
+- `【1】` 处，解析 `componentType` 类型。
+
+- `【2】` 处，创建 GenericArrayTypeImpl 对象。代码如下：
+
+  ```
+  // TypeParameterResolver.java 内部静态类
+  
+  /**
+   * GenericArrayType 实现类
+   *
+   * 泛型数组类型，用来描述 ParameterizedType、TypeVariable 类型的数组；即 List<T>[]、T[] 等；
+   */
+  static class GenericArrayTypeImpl implements GenericArrayType {
+  
+      /**
+       * 数组元素类型
+       */
+      private Type genericComponentType;
+  
+      GenericArrayTypeImpl(Type genericComponentType) {
+          super();
+          this.genericComponentType = genericComponentType;
+      }
+  
+      @Override
+      public Type getGenericComponentType() {
+          return genericComponentType;
+      }
+  
+  }
+  ```
+
+### 14.2.4 resolveTypeVar
+
+TODO 1001 芋艿，暂时看不太懂。暂时无视
+
+想要死磕的胖友，可以看看 [《mybatis-TypeParameterResolver 工具类分析》](https://cdn2.jianshu.io/p/423c9a8e4424?utm_campaign=maleskine&utm_content=note&utm_medium=seo_notes&utm_source=recommendation) 。
+
+可以通过调试 `org.apache.ibatis.reflection.TypeParameterResolverTest` 这个单元测试类，触发各种情况。
+
+# 15. ArrayUtil
+
+`org.apache.ibatis.reflection.ArrayUtil` ，数组工具类。代码如下：
+
+```
+// ArrayUtil.java
+
+public class ArrayUtil {
+
+    /**
+     * Returns a hash code for {@code obj}.
+     *
+     * @param obj
+     *          The object to get a hash code for. May be an array or <code>null</code>.
+     * @return A hash code of {@code obj} or 0 if {@code obj} is <code>null</code>
+     */
+    public static int hashCode(Object obj) {
+        if (obj == null) {
+            // for consistency with Arrays#hashCode() and Objects#hashCode()
+            return 0;
+        }
+        // 普通类
+        final Class<?> clazz = obj.getClass();
+        if (!clazz.isArray()) {
+            return obj.hashCode();
+        }
+        // 数组类型
+        final Class<?> componentType = clazz.getComponentType();
+        if (long.class.equals(componentType)) {
+            return Arrays.hashCode((long[]) obj);
+        } else if (int.class.equals(componentType)) {
+            return Arrays.hashCode((int[]) obj);
+        } else if (short.class.equals(componentType)) {
+            return Arrays.hashCode((short[]) obj);
+        } else if (char.class.equals(componentType)) {
+            return Arrays.hashCode((char[]) obj);
+        } else if (byte.class.equals(componentType)) {
+            return Arrays.hashCode((byte[]) obj);
+        } else if (boolean.class.equals(componentType)) {
+            return Arrays.hashCode((boolean[]) obj);
+        } else if (float.class.equals(componentType)) {
+            return Arrays.hashCode((float[]) obj);
+        } else if (double.class.equals(componentType)) {
+            return Arrays.hashCode((double[]) obj);
+        } else {
+            return Arrays.hashCode((Object[]) obj);
+        }
+    }
+
+    /**
+     * Compares two objects. Returns <code>true</code> if
+     * <ul>
+     * <li>{@code thisObj} and {@code thatObj} are both <code>null</code></li>
+     * <li>{@code thisObj} and {@code thatObj} are instances of the same type and
+     * {@link Object#equals(Object)} returns <code>true</code></li>
+     * <li>{@code thisObj} and {@code thatObj} are arrays with the same component type and
+     * equals() method of {@link Arrays} returns <code>true</code> (not deepEquals())</li>
+     * </ul>
+     *
+     * @param thisObj
+     *          The left hand object to compare. May be an array or <code>null</code>
+     * @param thatObj
+     *          The right hand object to compare. May be an array or <code>null</code>
+     * @return <code>true</code> if two objects are equal; <code>false</code> otherwise.
+     */
+    public static boolean equals(Object thisObj, Object thatObj) {
+        if (thisObj == null) {
+            return thatObj == null;
+        } else if (thatObj == null) {
+            return false;
+        }
+        final Class<?> clazz = thisObj.getClass();
+        if (!clazz.equals(thatObj.getClass())) {
+            return false;
+        }
+        // 普通类
+        if (!clazz.isArray()) {
+            return thisObj.equals(thatObj);
+        }
+        // 数组类型
+        final Class<?> componentType = clazz.getComponentType();
+        if (long.class.equals(componentType)) {
+            return Arrays.equals((long[]) thisObj, (long[]) thatObj);
+        } else if (int.class.equals(componentType)) {
+            return Arrays.equals((int[]) thisObj, (int[]) thatObj);
+        } else if (short.class.equals(componentType)) {
+            return Arrays.equals((short[]) thisObj, (short[]) thatObj);
+        } else if (char.class.equals(componentType)) {
+            return Arrays.equals((char[]) thisObj, (char[]) thatObj);
+        } else if (byte.class.equals(componentType)) {
+            return Arrays.equals((byte[]) thisObj, (byte[]) thatObj);
+        } else if (boolean.class.equals(componentType)) {
+            return Arrays.equals((boolean[]) thisObj, (boolean[]) thatObj);
+        } else if (float.class.equals(componentType)) {
+            return Arrays.equals((float[]) thisObj, (float[]) thatObj);
+        } else if (double.class.equals(componentType)) {
+            return Arrays.equals((double[]) thisObj, (double[]) thatObj);
+        } else {
+            return Arrays.equals((Object[]) thisObj, (Object[]) thatObj);
+        }
+    }
+
+    /**
+     * If the {@code obj} is an array, toString() method of {@link Arrays} is called. Otherwise
+     * {@link Object#toString()} is called. Returns "null" if {@code obj} is <code>null</code>.
+     *
+     * @param obj
+     *          An object. May be an array or <code>null</code>.
+     * @return String representation of the {@code obj}.
+     */
+    public static String toString(Object obj) {
+        if (obj == null) {
+            return "null";
+        }
+        // 普通类
+        final Class<?> clazz = obj.getClass();
+        if (!clazz.isArray()) {
+            return obj.toString();
+        }
+        // 数组类型
+        final Class<?> componentType = obj.getClass().getComponentType();
+        if (long.class.equals(componentType)) {
+            return Arrays.toString((long[]) obj);
+        } else if (int.class.equals(componentType)) {
+            return Arrays.toString((int[]) obj);
+        } else if (short.class.equals(componentType)) {
+            return Arrays.toString((short[]) obj);
+        } else if (char.class.equals(componentType)) {
+            return Arrays.toString((char[]) obj);
+        } else if (byte.class.equals(componentType)) {
+            return Arrays.toString((byte[]) obj);
+        } else if (boolean.class.equals(componentType)) {
+            return Arrays.toString((boolean[]) obj);
+        } else if (float.class.equals(componentType)) {
+            return Arrays.toString((float[]) obj);
+        } else if (double.class.equals(componentType)) {
+            return Arrays.toString((double[]) obj);
+        } else {
+            return Arrays.toString((Object[]) obj);
+        }
+    }
+
+}
+```
+
+# 16. ExceptionUtil
+
+`org.apache.ibatis.reflection.ExceptionUtil` ，异常工具类。代码如下：
+
+```
+// ExceptionUtil.java
+
+public class ExceptionUtil {
+
+    private ExceptionUtil() {
+        // Prevent Instantiation
+    }
+
+    /**
+     * 去掉异常的包装
+     *
+     * @param wrapped 被包装的异常
+     * @return 去除包装后的异常
+     */
+    public static Throwable unwrapThrowable(Throwable wrapped) {
+        Throwable unwrapped = wrapped;
+        while (true) {
+            if (unwrapped instanceof InvocationTargetException) {
+                unwrapped = ((InvocationTargetException) unwrapped).getTargetException();
+            } else if (unwrapped instanceof UndeclaredThrowableException) {
+                unwrapped = ((UndeclaredThrowableException) unwrapped).getUndeclaredThrowable();
+            } else {
+                return unwrapped;
+            }
+        }
+    }
+
+}
+```
+
+# 666. 彩蛋
+
+比想象中，长了超级超级超级多的文章。写的都快吐血了，鬼知道我经历了什么！！！
+
+参考和推荐如下文章：
+
+- 徐郡明 [《MyBatis 技术内幕》](https://item.jd.com/12125531.html) 的 [「2.2 反射工具箱」](https://svip.iocoder.cn/MyBatis/reflection-package/#) 小节
+- 祖大俊 [《Mybatis3.3.x技术内幕（七）：Mybatis初始化之六个工具》](https://my.oschina.net/zudajun/blog/668596)
+
+如果胖友看到此处，还是一脸懵逼，还是那句话，多多调试！！！
\ No newline at end of file
diff --git a/mybatis/06-mybatis-异常模块.assets/01.png b/mybatis/06-mybatis-异常模块.assets/01.png
new file mode 100644
index 0000000..20b89df
Binary files /dev/null and b/mybatis/06-mybatis-异常模块.assets/01.png differ
diff --git a/mybatis/06-mybatis-异常模块.assets/02.png b/mybatis/06-mybatis-异常模块.assets/02.png
new file mode 100644
index 0000000..c29a09c
Binary files /dev/null and b/mybatis/06-mybatis-异常模块.assets/02.png differ
diff --git a/mybatis/06-mybatis-异常模块.md b/mybatis/06-mybatis-异常模块.md
new file mode 100644
index 0000000..95cba93
--- /dev/null
+++ b/mybatis/06-mybatis-异常模块.md
@@ -0,0 +1,178 @@
+# 精尽 MyBatis 源码分析 —— 异常模块
+
+# 1. 概述
+
+本文，我们来分享 MyBatis 的异常模块，对应 `exceptions` 包。如下图所示：[![`exceptions` 包](06-mybatis-异常模块.assets/01.png)](http://static.iocoder.cn/images/MyBatis/2020_01_13/01.png)`exceptions` 包
+
+在 [《精尽 MyBatis 源码解析 —— 项目结构一览》](http://svip.iocoder.cn/MyBatis/intro) 中，简单介绍了这个模块如下：
+
+> 定义了 MyBatis 专有的 PersistenceException 和 TooManyResultsException 异常。
+
+实际上，MyBatis 不仅仅在 `exceptions` 包下有异常，在其他包下也有异常，整体如下类图：[![异常体系](06-mybatis-异常模块.assets/02.png)](http://static.iocoder.cn/images/MyBatis/2020_01_13/02.png)异常体系
+
+下面，我们逐个包的异常看过看过去。
+
+# 2. `exceptions` 包
+
+## 2.1 IbatisException
+
+`org.apache.ibatis.exceptions.IbatisException` ，实现 RuntimeException 类，IBatis 的**异常基类**。代码如下：
+
+```
+@Deprecated
+public class IbatisException extends RuntimeException {
+
+  private static final long serialVersionUID = 3880206998166270511L;
+
+  public IbatisException() {
+    super();
+  }
+
+  public IbatisException(String message) {
+    super(message);
+  }
+
+  public IbatisException(String message, Throwable cause) {
+    super(message, cause);
+  }
+
+  public IbatisException(Throwable cause) {
+    super(cause);
+  }
+
+}
+```
+
+- 实际上，IbatisException 已经在 2015 年被废弃，取代它的是 PersistenceException 类。
+
+## 2.2 PersistenceException
+
+`org.apache.ibatis.exceptions.PersistenceException` ，继承 IbatisException 类，目前 MyBatis **真正的异常基类**。代码如下：
+
+```
+public class PersistenceException extends IbatisException {
+
+    private static final long serialVersionUID = -7537395265357977271L;
+
+    public PersistenceException() {
+        super();
+    }
+
+    public PersistenceException(String message) {
+        super(message);
+    }
+
+    public PersistenceException(String message, Throwable cause) {
+        super(message, cause);
+    }
+
+    public PersistenceException(Throwable cause) {
+        super(cause);
+    }
+    
+}
+```
+
+### 2.2.1 ExceptionFactory
+
+`org.apache.ibatis.exceptions.ExceptionFactory` ，异常工厂。代码如下：
+
+```
+public class ExceptionFactory {
+
+    private ExceptionFactory() {
+        // Prevent Instantiation
+    }
+
+    /**
+     * 包装异常成 PersistenceException
+     *
+     * @param message 消息
+     * @param e 发生的异常
+     * @return PersistenceException
+     */
+    public static RuntimeException wrapException(String message, Exception e) {
+        return new PersistenceException(ErrorContext.instance().message(message).cause(e).toString(), e);
+    }
+
+}
+```
+
+## 2.3 TooManyResultsException
+
+`org.apache.ibatis.exceptions.TooManyResultsException` ，继承 PersistenceException 类，查询返回过多结果的异常。期望返回一条，实际返回了多条。代码如下：
+
+```
+public class TooManyResultsException extends PersistenceException {
+
+    private static final long serialVersionUID = 8935197089745865786L;
+
+    public TooManyResultsException() {
+        super();
+    }
+
+    public TooManyResultsException(String message) {
+        super(message);
+    }
+
+    public TooManyResultsException(String message, Throwable cause) {
+        super(message, cause);
+    }
+
+    public TooManyResultsException(Throwable cause) {
+        super(cause);
+    }
+
+}
+```
+
+# 3. `parsing` 包
+
+## 3.1 ParsingException
+
+`org.apache.ibatis.parsing.ParsingException` ，继承 PersistenceException 类，解析异常。代码如下：
+
+```
+public class ParsingException extends PersistenceException {
+
+    private static final long serialVersionUID = -176685891441325943L;
+
+    public ParsingException() {
+        super();
+    }
+
+    public ParsingException(String message) {
+        super(message);
+    }
+
+    public ParsingException(String message, Throwable cause) {
+        super(message, cause);
+    }
+
+    public ParsingException(Throwable cause) {
+        super(cause);
+    }
+
+}
+```
+
+# 3. 其它包
+
+实际上，我们会看到其他包，会和 `parsing` 包一样，都会定义其**独有**的异常类。但是，代码都是相同的。所以，这里就简单整理如下：
+
+- `reflection` 包：ReflectionException
+- `logging` 包：LogException
+- `builder` 包：BuilderException、IncompleteElementException
+- `scripting` 包：ScriptingException
+- `binding` 包：BindingException
+- `type` 包：TypeException
+- `session` 包：SqlSessionException
+- `cache` 包：CacheException
+- `transaction` 包：TransactionException
+- `datasource` 包：DataSourceException
+- `executor` 包：ResultMapException、ExecutorException、BatchExecutorException
+- `plugin` 包：PluginException
+
+# 666. 彩蛋
+
+哈哈哈，因为 [《精尽 MyBatis 源码分析 —— 反射模块》](http://svip.iocoder.cn/MyBatis/reflection-package) 一文让我们都很累，所以这篇文章，给我们度假下。哈哈哈。
\ No newline at end of file
diff --git a/mybatis/07-mybatis-数据源模块.assets/01.png b/mybatis/07-mybatis-数据源模块.assets/01.png
new file mode 100644
index 0000000..003d50d
Binary files /dev/null and b/mybatis/07-mybatis-数据源模块.assets/01.png differ
diff --git a/mybatis/07-mybatis-数据源模块.assets/02.png b/mybatis/07-mybatis-数据源模块.assets/02.png
new file mode 100644
index 0000000..9d0f040
Binary files /dev/null and b/mybatis/07-mybatis-数据源模块.assets/02.png differ
diff --git a/mybatis/07-mybatis-数据源模块.assets/03.png b/mybatis/07-mybatis-数据源模块.assets/03.png
new file mode 100644
index 0000000..770f44d
Binary files /dev/null and b/mybatis/07-mybatis-数据源模块.assets/03.png differ
diff --git a/mybatis/07-mybatis-数据源模块.assets/04.png b/mybatis/07-mybatis-数据源模块.assets/04.png
new file mode 100644
index 0000000..79b7c54
Binary files /dev/null and b/mybatis/07-mybatis-数据源模块.assets/04.png differ
diff --git a/mybatis/07-mybatis-数据源模块.md b/mybatis/07-mybatis-数据源模块.md
new file mode 100644
index 0000000..fe973c3
--- /dev/null
+++ b/mybatis/07-mybatis-数据源模块.md
@@ -0,0 +1,1447 @@
+# 精尽 MyBatis 源码分析 —— 数据源模块
+
+# 1. 概述
+
+本文，我们来分享 MyBatis 的数据源模块，对应 `datasource` 包。如下图所示：[![`datasource` 包](07-mybatis-数据源模块.assets/01.png)](http://static.iocoder.cn/images/MyBatis/2020_01_16/01.png)`datasource` 包
+
+在 [《精尽 MyBatis 源码解析 —— 项目结构一览》](http://svip.iocoder.cn/MyBatis/intro) 中，简单介绍了这个模块如下：
+
+> 数据源是实际开发中常用的组件之一。现在开源的数据源都提供了比较丰富的功能，例如，连接池功能、检测连接状态等，选择性能优秀的数据源组件对于提升 ORM 框架乃至整个应用的性能都是非常重要的。
+>
+> MyBatis **自身提供了相应的数据源实现，当然 MyBatis 也提供了与第三方数据源集成的接口，这些功能都位于数据源模块之中**。
+
+本文涉及的类如下图所示：[![类图](07-mybatis-数据源模块.assets/02.png)](http://static.iocoder.cn/images/MyBatis/2020_01_16/02.png)类图
+
+下面，我们就一起来看看具体的源码实现。
+
+# 2. DataSourceFactory
+
+`org.apache.ibatis.datasource.DataSourceFactory` ，`javax.sql.DataSource` 工厂接口。代码如下：
+
+```
+public interface DataSourceFactory {
+
+    /**
+     * 设置 DataSource 对象的属性
+     *
+     * @param props 属性
+     */
+    void setProperties(Properties props);
+
+    /**
+     * 获得 DataSource 对象
+     *
+     * @return DataSource 对象
+     */
+    DataSource getDataSource();
+
+}
+```
+
+## 2.1 UnpooledDataSourceFactory
+
+`org.apache.ibatis.datasource.unpooled.UnpooledDataSourceFactory` ，实现 DataSourceFactory 接口，非池化的 DataSourceFactory 实现类。
+
+> FROM [《MyBatis 文档 —— XML 映射配置文件》](http://www.mybatis.org/mybatis-3/zh/configuration.html)
+>
+> **UNPOOLED**– 这个数据源的实现只是每次被请求时打开和关闭连接。虽然有点慢，但对于在数据库连接可用性方面没有太高要求的简单应用程序来说，是一个很好的选择。 不同的数据库在性能方面的表现也是不一样的，对于某些数据库来说，使用连接池并不重要，这个配置就很适合这种情形。UNPOOLED 类型的数据源仅仅需要配置以下 5 种属性：
+>
+> - `driver` – 这是 JDBC 驱动的 Java 类的完全限定名（并不是 JDBC 驱动中可能包含的数据源类）。
+> - `url` – 这是数据库的 JDBC URL 地址。
+> - `username` – 登录数据库的用户名。
+> - `password` – 登录数据库的密码。
+> - `defaultTransactionIsolationLevel` – 默认的连接事务隔离级别。
+>
+> 作为可选项，你也可以传递属性给数据库驱动。要这样做，属性的前缀为“driver.”，例如：
+>
+> - `driver.encoding=UTF8`
+>
+> 这将通过 `DriverManager.getConnection(url,driverProperties)` 方法传递值为 `UTF8` 的 `encoding` 属性给数据库驱动。
+
+### 2.1.1 构造方法
+
+```
+// UnpooledDataSourceFactory.java
+
+/**
+ * DataSource 对象
+ */
+protected DataSource dataSource;
+
+public UnpooledDataSourceFactory() {
+    // 创建 UnpooledDataSource 对象
+    this.dataSource = new UnpooledDataSource();
+}
+```
+
+- 默认创建了 UnpooledDataSource 对象。
+
+### 2.1.2 getDataSource
+
+`#getDataSource()` 方法，返回 DataSource 对象。代码如下：
+
+```
+// UnpooledDataSourceFactory.java
+
+@Override
+public DataSource getDataSource() {
+    return dataSource;
+}
+```
+
+### 2.1.3 setProperties
+
+`#setProperties(Properties properties)` 方法，将 `properties` 的属性，初始化到 `dataSource` 中。代码如下：
+
+```
+// UnpooledDataSourceFactory.java
+
+@Override
+public void setProperties(Properties properties) {
+    Properties driverProperties = new Properties();
+    // 创建 dataSource 对应的 MetaObject 对象
+    MetaObject metaDataSource = SystemMetaObject.forObject(dataSource);
+    // 遍历 properties 属性，初始化到 driverProperties 和 MetaObject 中
+    for (Object key : properties.keySet()) {
+        String propertyName = (String) key;
+        // 初始化到 driverProperties 中
+        if (propertyName.startsWith(DRIVER_PROPERTY_PREFIX)) { // 以 "driver." 开头的配置
+            String value = properties.getProperty(propertyName);
+            driverProperties.setProperty(propertyName.substring(DRIVER_PROPERTY_PREFIX_LENGTH), value);
+        // 初始化到 MetaObject 中
+        } else if (metaDataSource.hasSetter(propertyName)) {
+            String value = (String) properties.get(propertyName);
+            Object convertedValue = convertValue(metaDataSource, propertyName, value); // <1> 转化属性
+            metaDataSource.setValue(propertyName, convertedValue);
+        } else {
+            throw new DataSourceException("Unknown DataSource property: " + propertyName);
+        }
+    }
+    // 设置 driverProperties 到 MetaObject 中
+    if (driverProperties.size() > 0) {
+        metaDataSource.setValue("driverProperties", driverProperties);
+    }
+}
+```
+
+- 代码比较简单，胖友直接看下代码。
+- `<1>` 处，调用 `#convertValue(MetaObject metaDataSource, String propertyName, String value)` 方法，将字符串转化成对应属性的类型。代码如下：
+
+```
+// UnpooledDataSourceFactory.java
+
+private Object convertValue(MetaObject metaDataSource, String propertyName, String value) {
+    Object convertedValue = value;
+    // 获得该属性的 setting 方法的参数类型
+    Class<?> targetType = metaDataSource.getSetterType(propertyName);
+    // 转化
+    if (targetType == Integer.class || targetType == int.class) {
+        convertedValue = Integer.valueOf(value);
+    } else if (targetType == Long.class || targetType == long.class) {
+        convertedValue = Long.valueOf(value);
+    } else if (targetType == Boolean.class || targetType == boolean.class) {
+        convertedValue = Boolean.valueOf(value);
+    }
+    // 返回
+    return convertedValue;
+}
+```
+
+## 2.2 PooledDataSourceFactory
+
+`org.apache.ibatis.datasource.pooled.PooledDataSourceFactory` ，继承 UnpooledDataSourceFactory 类，池化的 DataSourceFactory 实现类。
+
+> FROM [《MyBatis 文档 —— XML 映射配置文件》](http://www.mybatis.org/mybatis-3/zh/configuration.html)
+>
+> **POOLED**– 这种数据源的实现利用“池”的概念将 JDBC 连接对象组织起来，避免了创建新的连接实例时所必需的初始化和认证时间。 这是一种使得并发 Web 应用快速响应请求的流行处理方式。
+>
+> 除了上述提到 UNPOOLED 下的属性外，还有更多属性用来配置 POOLED 的数据源：
+>
+> - `poolMaximumActiveConnections` – 在任意时间可以存在的活动（也就是正在使用）连接数量，默认值：10
+> - `poolMaximumIdleConnections` – 任意时间可能存在的空闲连接数。
+> - `poolMaximumCheckoutTime` – 在被强制返回之前，池中连接被检出（checked out）时间，默认值：20000 毫秒（即 20 秒）
+> - `poolTimeToWait` – 这是一个底层设置，如果获取连接花费了相当长的时间，连接池会打印状态日志并重新尝试获取一个连接（避免在误配置的情况下一直安静的失败），默认值：20000 毫秒（即 20 秒）。
+> - `poolMaximumLocalBadConnectionTolerance` – 这是一个关于坏连接容忍度的底层设置， 作用于每一个尝试从缓存池获取连接的线程. 如果这个线程获取到的是一个坏的连接，那么这个数据源允许这个线程尝试重新获取一个新的连接，但是这个重新尝试的次数不应该超过 `poolMaximumIdleConnections` 与 `poolMaximumLocalBadConnectionTolerance` 之和。 默认值：3 (新增于 3.4.5)
+> - `poolPingQuery` – 发送到数据库的侦测查询，用来检验连接是否正常工作并准备接受请求。默认是“NO PING QUERY SET”，这会导致多数数据库驱动失败时带有一个恰当的错误消息。
+> - `poolPingEnabled` – 是否启用侦测查询。若开启，需要设置 `poolPingQuery` 属性为一个可执行的 SQL 语句（最好是一个速度非常快的 SQL 语句），默认值：false。
+> - `poolPingConnectionsNotUsedFor` – 配置 poolPingQuery 的频率。可以被设置为和数据库连接超时时间一样，来避免不必要的侦测，默认值：0（即所有连接每一时刻都被侦测 — 当然仅当 poolPingEnabled 为 true 时适用）。
+
+- PooledDataSource 比 UnpooledDataSource 的配置项**多很多**。
+
+代码如下：
+
+```
+// PooledDataSourceFactory.java
+
+public class PooledDataSourceFactory extends UnpooledDataSourceFactory {
+
+    public PooledDataSourceFactory() {
+        this.dataSource = new PooledDataSource();
+    }
+
+}
+```
+
+- 默认创建了 PooledDataSource 对象。
+
+其它方法，在父类中 UnpooledDataSourceFactory 中已经实现。所以，真正的**池化**逻辑，在 PooledDataSource 对象中。
+
+## 2.3 JndiDataSourceFactory
+
+`org.apache.ibatis.datasource.jndi.JndiDataSourceFactory` ，实现 DataSourceFactory 接口，基于 JNDI 的 DataSourceFactory 实现类。
+
+> FROM [《MyBatis 文档 —— XML 映射配置文件》](http://www.mybatis.org/mybatis-3/zh/configuration.html)
+>
+> **JNDI** – 这个数据源的实现是为了能在如 EJB 或应用服务器这类容器中使用，容器可以集中或在外部配置数据源，然后放置一个 JNDI 上下文的引用。这种数据源配置只需要两个属性：
+>
+> - `initial_context` – 这个属性用来在 InitialContext 中寻找上下文（即，initialContext.lookup(initial_context)）。这是个可选属性，如果忽略，那么 data_source 属性将会直接从 InitialContext 中寻找。
+> - `data_source` – 这是引用数据源实例位置的上下文的路径。提供了 initial_context 配置时会在其返回的上下文中进行查找，没有提供时则直接在 InitialContext 中查找。
+>
+> 和其他数据源配置类似，可以通过添加前缀“env.”直接把属性传递给初始上下文。比如：
+>
+> - `env.encoding=UTF8`
+>
+> 这就会在初始上下文（InitialContext）实例化时往它的构造方法传递值为 `UTF8` 的 `encoding` 属性。
+
+### 2.3.1 构造方法
+
+```
+// JndiDataSourceFactory.java
+
+private DataSource dataSource;
+```
+
+- 不同于 UnpooledDataSourceFactory 和 PooledDataSourceFactory ，`dataSource` 不在构造方法中创建，而是在 `#setProperties(Properties properties)` 中。
+
+### 2.3.2 getDataSource
+
+`#getDataSource()` 方法，返回 DataSource 对象。代码如下：
+
+```
+// JndiDataSourceFactory.java
+
+@Override
+public DataSource getDataSource() {
+    return dataSource;
+}
+```
+
+### 2.3.3 setProperties
+
+`#setProperties(Properties properties)` 方法，从上下文中，获得 DataSource 对象。代码如下：
+
+```
+// JndiDataSourceFactory.java
+
+public static final String INITIAL_CONTEXT = "initial_context";
+public static final String DATA_SOURCE = "data_source";
+public static final String ENV_PREFIX = "env.";
+
+@Override
+public void setProperties(Properties properties) {
+    try {
+        InitialContext initCtx;
+        // <1> 获得系统 Properties 对象
+        Properties env = getEnvProperties(properties);
+        // 创建 InitialContext 对象
+        if (env == null) {
+            initCtx = new InitialContext();
+        } else {
+            initCtx = new InitialContext(env);
+        }
+
+        // 从 InitialContext 上下文中，获取 DataSource 对象
+        if (properties.containsKey(INITIAL_CONTEXT)
+                && properties.containsKey(DATA_SOURCE)) {
+            Context ctx = (Context) initCtx.lookup(properties.getProperty(INITIAL_CONTEXT));
+            dataSource = (DataSource) ctx.lookup(properties.getProperty(DATA_SOURCE));
+        } else if (properties.containsKey(DATA_SOURCE)) {
+            dataSource = (DataSource) initCtx.lookup(properties.getProperty(DATA_SOURCE));
+        }
+    } catch (NamingException e) {
+        throw new DataSourceException("There was an error configuring JndiDataSourceTransactionPool. Cause: " + e, e);
+    }
+}
+```
+
+- 目前已经很少使用 JNDI 功能了，所以胖友简单了解下就好。
+
+- `<1>` 处，调用 `#getEnvProperties(Properties allProps)` 方法，获得系统 Properties 对象。代码如下：
+
+  ```
+  // JndiDataSourceFactory.java
+  
+  private static Properties getEnvProperties(Properties allProps) {
+      final String PREFIX = ENV_PREFIX;
+      Properties contextProperties = null;
+      for (Entry<Object, Object> entry : allProps.entrySet()) {
+          String key = (String) entry.getKey();
+          String value = (String) entry.getValue();
+          if (key.startsWith(PREFIX)) {
+              if (contextProperties == null) {
+                  contextProperties = new Properties();
+              }
+              contextProperties.put(key.substring(PREFIX.length()), value);
+          }
+      }
+      return contextProperties;
+  }
+  ```
+
+# 3. DataSource
+
+`javax.sql.DataSource` 是个**神奇**的接口，在其上可以衍生出数据连接池、分库分表、读写分离等等功能。
+
+如果你对 DataSource 如何实现分库分表的功能，可以看看 [《Sharding-JDBC 源码分析 —— JDBC实现与读写分离》](http://www.iocoder.cn/Sharding-JDBC/jdbc-implement-and-read-write-splitting/?svip) 。
+
+## 3.1 UnpooledDataSource
+
+`org.apache.ibatis.datasource.unpooled.UnpooledDataSource` ，实现 DataSource 接口，非池化的 DataSource 对象。
+
+### 3.1.1 构造方法
+
+```
+// UnpooledDataSource.java
+
+/**
+ * 已注册的 Driver 映射
+ *
+ * KEY：Driver 类名
+ * VALUE：Driver 对象
+ */
+private static Map<String, Driver> registeredDrivers = new ConcurrentHashMap<>();
+
+/**
+ * Driver 类加载器
+ */
+private ClassLoader driverClassLoader;
+/**
+ * Driver 属性
+ */
+private Properties driverProperties;
+
+/**
+ * Driver 类名
+ */
+private String driver;
+/**
+ * 数据库 URL
+ */
+private String url;
+/**
+ * 数据库用户名
+ */
+private String username;
+/**
+ * 数据库密码
+ */
+private String password;
+
+/**
+ * 是否自动提交事务
+ */
+private Boolean autoCommit;
+/**
+ * 默认事务隔离级别
+ */
+private Integer defaultTransactionIsolationLevel;
+
+static {
+    // 初始化 registeredDrivers
+    Enumeration<Driver> drivers = DriverManager.getDrivers();
+    while (drivers.hasMoreElements()) {
+        Driver driver = drivers.nextElement();
+        registeredDrivers.put(driver.getClass().getName(), driver);
+    }
+}
+
+public UnpooledDataSource() {
+}
+
+public UnpooledDataSource(String driver, String url, String username, String password) {
+    this.driver = driver;
+    this.url = url;
+    this.username = username;
+    this.password = password;
+}
+
+public UnpooledDataSource(String driver, String url, Properties driverProperties) {
+    this.driver = driver;
+    this.url = url;
+    this.driverProperties = driverProperties;
+}
+
+public UnpooledDataSource(ClassLoader driverClassLoader, String driver, String url, String username, String password) {
+    this.driverClassLoader = driverClassLoader;
+    this.driver = driver;
+    this.url = url;
+    this.username = username;
+    this.password = password;
+}
+
+public UnpooledDataSource(ClassLoader driverClassLoader, String driver, String url, Properties driverProperties) {
+    this.driverClassLoader = driverClassLoader;
+    this.driver = driver;
+    this.url = url;
+    this.driverProperties = driverProperties;
+}
+```
+
+- 比较简单，就是属性的赋值。
+
+### 3.1.2 getConnection
+
+`#getConnection(...)` 方法，获得 Connection 连接。代码如下：
+
+```
+// UnpooledDataSource.java
+
+@Override
+public Connection getConnection() throws SQLException {
+    return doGetConnection(username, password);
+}
+
+@Override
+public Connection getConnection(String username, String password) throws SQLException {
+    return doGetConnection(username, password);
+}
+```
+
+- 都是调用 `#doGetConnection(String username, String password)` 方法，获取 Connection 连接。代码如下：
+
+  ```
+  // UnpooledDataSource.java
+  
+  private Connection doGetConnection(String username, String password) throws SQLException {
+      // 创建 Properties 对象
+      Properties props = new Properties();
+      // 设置 driverProperties 到 props 中
+      if (driverProperties != null) {
+          props.putAll(driverProperties);
+      }
+      // 设置 user 和 password 到 props 中
+      if (username != null) {
+          props.setProperty("user", username);
+      }
+      if (password != null) {
+          props.setProperty("password", password);
+      }
+      // 执行获得 Connection 连接
+      return doGetConnection(props);
+  }
+  
+  private Connection doGetConnection(Properties properties) throws SQLException {
+      // <1> 初始化 Driver
+      initializeDriver();
+      // <2> 获得 Connection 对象
+      Connection connection = DriverManager.getConnection(url, properties);
+      // <3> 配置 Connection 对象
+      configureConnection(connection);
+      return connection;
+  }
+  ```
+
+  - `<1>` 处，调用 `#initializeDriver()` 方法，初始化 Driver 。详细解析，见 [「3.1.2.1 initializeDriver」](https://svip.iocoder.cn/MyBatis/datasource-package/#) 。
+  - `<2>` 处，调用 `java.sql.DriverManager#getConnection(String url, Properties info)` 方法，获得 Connection 对象。
+  - `<3>` 处，调用 `#configureConnection(Connection conn)` 方法，配置 Connection 对象。详细解析，见 [「3.1.2.2 configureConnection」](https://svip.iocoder.cn/MyBatis/datasource-package/#) 。
+
+#### 3.1.2.1 initializeDriver
+
+`#initializeDriver()` 方法，初始化 Driver 。代码如下：
+
+```
+// UnpooledDataSource.java
+
+private synchronized void initializeDriver() throws SQLException { // <1>
+    // 判断 registeredDrivers 是否已经存在该 driver ，若不存在，进行初始化
+    if (!registeredDrivers.containsKey(driver)) {
+        Class<?> driverType;
+        try {
+            // <2> 获得 driver 类
+            if (driverClassLoader != null) {
+                driverType = Class.forName(driver, true, driverClassLoader);
+            } else {
+                driverType = Resources.classForName(driver);
+            }
+            // <3> 创建 Driver 对象
+            // DriverManager requires the driver to be loaded via the system ClassLoader.
+            // http://www.kfu.com/~nsayer/Java/dyn-jdbc.html
+            Driver driverInstance = (Driver) driverType.newInstance();
+            // 创建 DriverProxy 对象，并注册到 DriverManager 中
+            DriverManager.registerDriver(new DriverProxy(driverInstance));
+            // 添加到 registeredDrivers 中
+            registeredDrivers.put(driver, driverInstance);
+        } catch (Exception e) {
+            throw new SQLException("Error setting driver on UnpooledDataSource. Cause: " + e);
+        }
+    }
+}
+```
+
+- 总体逻辑比较简单，判断 `registeredDrivers` 是否已经存在该 `driver` ？若不存在，进行初始化。
+
+- `<1>` 处，`synchronized` 锁的粒度太大，可以减小到基于 `registeredDrivers` 来同步，并且很多时候，不需要加锁。
+
+- `<2>` 处，获得 `driver` 类，实际上，就是我们常见的 `"Class.forName("com.mysql.jdbc.Driver")"` 。
+
+- `<3>` 处，创建 Driver 对象，并注册到 DriverManager 中，以及添加到 `registeredDrivers` 中。为什么此处会有使用 DriverProxy 呢？DriverProxy 的代码如下：
+
+  ```
+  // UnpooledDataSource.java 的内部私有静态类
+  
+  private static class DriverProxy implements Driver {
+      private Driver driver;
+  
+      DriverProxy(Driver d) {
+          this.driver = d;
+      }
+  
+      @Override
+      public boolean acceptsURL(String u) throws SQLException {
+          return this.driver.acceptsURL(u);
+      }
+  
+      @Override
+      public Connection connect(String u, Properties p) throws SQLException {
+          return this.driver.connect(u, p);
+      }
+  
+      @Override
+      public int getMajorVersion() {
+          return this.driver.getMajorVersion();
+      }
+  
+      @Override
+      public int getMinorVersion() {
+          return this.driver.getMinorVersion();
+      }
+  
+      @Override
+      public DriverPropertyInfo[] getPropertyInfo(String u, Properties p) throws SQLException {
+          return this.driver.getPropertyInfo(u, p);
+      }
+  
+      @Override
+      public boolean jdbcCompliant() {
+          return this.driver.jdbcCompliant();
+      }
+  
+      // @Override only valid jdk7+
+      public Logger getParentLogger() {
+          return Logger.getLogger(Logger.GLOBAL_LOGGER_NAME); // <4>
+      }
+  
+  }
+  ```
+
+  - 因为 `<4>` 处，使用 MyBatis 自定义的 Logger 对象。
+  - 其他方法，实际就是直接调用 `driver` 对应的方法。
+
+#### 3.1.2.2 configureConnection
+
+`#configureConnection(Connection conn)` 方法，配置 Connection 对象。代码如下：
+
+```
+// UnpooledDataSource.java
+
+private void configureConnection(Connection conn) throws SQLException {
+    // 设置自动提交
+    if (autoCommit != null && autoCommit != conn.getAutoCommit()) {
+        conn.setAutoCommit(autoCommit);
+    }
+    // 设置事务隔离级别
+    if (defaultTransactionIsolationLevel != null) {
+        conn.setTransactionIsolation(defaultTransactionIsolationLevel);
+    }
+}
+```
+
+### 3.1.3 其它方法
+
+UnpooledDataSource 还实现了 DataSource 的其它方法，感兴趣的胖友，可以自己看。实际上，不看也行。哈哈哈哈。
+
+## 3.2 PooledDataSource
+
+`org.apache.ibatis.datasource.pooled.PooledDataSource` ，实现 DataSource 接口，池化的 DataSource 实现类。
+
+> FROM PooledDataSource 类上的注释
+>
+> This is a simple, synchronous, thread-safe database connection pool.
+
+- 实际场景下，我们基本不用 MyBatis 自带的数据库连接池的实现。所以，本文更多的目的，是让胖友们对数据库连接池的实现，有个大体的理解。
+
+### 3.2.1 构造方法
+
+```
+// PooledDataSource.java
+
+/**
+ * PoolState 对象，记录池化的状态
+ */
+private final PoolState state = new PoolState(this);
+
+/**
+ * UnpooledDataSource 对象
+ */
+private final UnpooledDataSource dataSource;
+
+// OPTIONAL CONFIGURATION FIELDS
+/**
+ * 在任意时间可以存在的活动（也就是正在使用）连接数量
+ */
+protected int poolMaximumActiveConnections = 10;
+/**
+ * 任意时间可能存在的空闲连接数
+ */
+protected int poolMaximumIdleConnections = 5;
+/**
+ * 在被强制返回之前，池中连接被检出（checked out）时间。单位：毫秒
+ */
+protected int poolMaximumCheckoutTime = 20000;
+/**
+ * 这是一个底层设置，如果获取连接花费了相当长的时间，连接池会打印状态日志并重新尝试获取一个连接（避免在误配置的情况下一直安静的失败）。单位：毫秒
+ */
+protected int poolTimeToWait = 20000;
+/**
+ * 这是一个关于坏连接容忍度的底层设置，作用于每一个尝试从缓存池获取连接的线程. 如果这个线程获取到的是一个坏的连接，那么这个数据源允许这个线程尝试重新获取一个新的连接，但是这个重新尝试的次数不应该超过 poolMaximumIdleConnections 与 poolMaximumLocalBadConnectionTolerance 之和。
+ */
+protected int poolMaximumLocalBadConnectionTolerance = 3;
+/**
+ * 发送到数据库的侦测查询，用来检验连接是否正常工作并准备接受请求。
+ */
+protected String poolPingQuery = "NO PING QUERY SET";
+/**
+ * 是否启用侦测查询。若开启，需要设置 poolPingQuery 属性为一个可执行的 SQL 语句（最好是一个速度非常快的 SQL 语句）
+ */
+protected boolean poolPingEnabled;
+/**
+ * 配置 poolPingQuery 的频率。可以被设置为和数据库连接超时时间一样，来避免不必要的侦测，默认值：0（即所有连接每一时刻都被侦测 — 当然仅当 poolPingEnabled 为 true 时适用）
+ */
+protected int poolPingConnectionsNotUsedFor;
+
+/**
+ * 期望 Connection 的类型编码，通过 {@link #assembleConnectionTypeCode(String, String, String)} 计算。
+ */
+private int expectedConnectionTypeCode;
+
+public PooledDataSource() {
+    dataSource = new UnpooledDataSource();
+}
+
+public PooledDataSource(UnpooledDataSource dataSource) {
+    this.dataSource = dataSource;
+}
+
+public PooledDataSource(String driver, String url, String username, String password) {
+    dataSource = new UnpooledDataSource(driver, url, username, password);
+    expectedConnectionTypeCode = assembleConnectionTypeCode(dataSource.getUrl(), dataSource.getUsername(), dataSource.getPassword());
+}
+
+public PooledDataSource(String driver, String url, Properties driverProperties) {
+    dataSource = new UnpooledDataSource(driver, url, driverProperties);
+    expectedConnectionTypeCode = assembleConnectionTypeCode(dataSource.getUrl(), dataSource.getUsername(), dataSource.getPassword());
+}
+
+public PooledDataSource(ClassLoader driverClassLoader, String driver, String url, String username, String password) {
+    dataSource = new UnpooledDataSource(driverClassLoader, driver, url, username, password);
+    expectedConnectionTypeCode = assembleConnectionTypeCode(dataSource.getUrl(), dataSource.getUsername(), dataSource.getPassword());
+}
+
+public PooledDataSource(ClassLoader driverClassLoader, String driver, String url, Properties driverProperties) {
+    // 创建 UnpooledDataSource 对象
+    dataSource = new UnpooledDataSource(driverClassLoader, driver, url, driverProperties);
+    // 计算  expectedConnectionTypeCode 的值
+    expectedConnectionTypeCode = assembleConnectionTypeCode(dataSource.getUrl(), dataSource.getUsername(), dataSource.getPassword());
+}
+```
+
+- 属性都比较简单，看起来虽然多，主要是可选的**配置**属性。我们就看几个重点的。
+
+- `dataSource` 属性，UnpooledDataSource 对象。这样，就能重用 UnpooledDataSource 的代码了。说白了，获取真正连接的逻辑，还是在 UnpooledDataSource 中实现。
+
+- `expectedConnectionTypeCode` 属性，调用 `#assembleConnectionTypeCode(ClassLoader driverClassLoader, String driver, String url, Properties driverProperties)` 方法，计算 `expectedConnectionTypeCode` 的值。代码如下：
+
+  ```
+  // PooledDataSource.java
+  
+  private int assembleConnectionTypeCode(String url, String username, String password) {
+      return ("" + url + username + password).hashCode();
+  }
+  ```
+
+- `state` 属性，PoolState 对象，记录池化的状态。这是一个非常重要的类，下文也会花一定的篇幅，详细解析。
+
+### 3.2.2 getConnection
+
+`#getConnection(...)` 方法，获得 Connection 连接。代码如下：
+
+```
+// PooledDataSource.java
+
+@Override
+public Connection getConnection() throws SQLException {
+    return popConnection(dataSource.getUsername(), dataSource.getPassword()).getProxyConnection();
+}
+
+@Override
+public Connection getConnection(String username, String password) throws SQLException {
+    return popConnection(username, password).getProxyConnection();
+}
+```
+
+- 调用 `#popConnection(String username, String password)` 方法，获取 `org.apache.ibatis.datasource.pooled.PooledConnection` 对象，这是一个**池化**的连接。非常关键的一个方法，详细解析，见 [「3.2.2.1 popConnection」](https://svip.iocoder.cn/MyBatis/datasource-package/#) 。
+- 调用 `PooledConnection#getProxyConnection()` 方法，返回代理的 Connection 对象。这样，每次对数据库的操作，才能被 PooledConnection 的 [「5.2 invoke」](https://svip.iocoder.cn/MyBatis/datasource-package/#) **代理拦截**。
+
+#### 3.2.2.1 popConnection
+
+`#popConnection(String username, String password)` 方法，获取 PooledConnection 对象。
+
+整体流程如下图：
+
+> FROM [《MyBatis 技术内幕》](https://item.jd.com/12125531.html)
+>
+> [![整体流程](07-mybatis-数据源模块.assets/03.png)](http://static.iocoder.cn/images/MyBatis/2020_01_16/03.png)整体流程
+
+代码如下：
+
+```
+// PooledDataSource.java
+
+  1: private PooledConnection popConnection(String username, String password) throws SQLException {
+  2:     boolean countedWait = false; // 标记，获取连接时，是否进行了等待
+  3:     PooledConnection conn = null; // 最终获取到的链接对象
+  4:     long t = System.currentTimeMillis(); // 记录当前时间
+  5:     int localBadConnectionCount = 0; // 记录当前方法，获取到坏连接的次数
+  6: 
+  7:     // 循环，获取可用的 Connection 连接
+  8:     while (conn == null) {
+  9:         synchronized (state) {
+ 10:             // 空闲连接非空
+ 11:             if (!state.idleConnections.isEmpty()) {
+ 12:                 // Pool has available connection
+ 13:                 // 通过移除的方式，获得首个空闲的连接
+ 14:                 conn = state.idleConnections.remove(0);
+ 15:                 if (log.isDebugEnabled()) {
+ 16:                     log.debug("Checked out connection " + conn.getRealHashCode() + " from pool.");
+ 17:                 }
+ 18:             // 无空闲空闲连接
+ 19:             } else {
+ 20:                 // Pool does not have available connection
+ 21:                 // 激活的连接数小于 poolMaximumActiveConnections
+ 22:                 if (state.activeConnections.size() < poolMaximumActiveConnections) {
+ 23:                     // Can create new connection
+ 24:                     // 创建新的 PooledConnection 连接对象
+ 25:                     conn = new PooledConnection(dataSource.getConnection(), this);
+ 26:                     if (log.isDebugEnabled()) {
+ 27:                         log.debug("Created connection " + conn.getRealHashCode() + ".");
+ 28:                     }
+ 29:                 } else {
+ 30:                     // Cannot create new connection
+ 31:                     // 获得首个激活的 PooledConnection 对象
+ 32:                     PooledConnection oldestActiveConnection = state.activeConnections.get(0);
+ 33:                     // 检查该连接是否超时
+ 34:                     long longestCheckoutTime = oldestActiveConnection.getCheckoutTime();
+ 35:                     if (longestCheckoutTime > poolMaximumCheckoutTime) { // 检查到超时
+ 36:                         // Can claim overdue connection
+ 37:                         // 对连接超时的时间的统计
+ 38:                         state.claimedOverdueConnectionCount++;
+ 39:                         state.accumulatedCheckoutTimeOfOverdueConnections += longestCheckoutTime;
+ 40:                         state.accumulatedCheckoutTime += longestCheckoutTime;
+ 41:                         // 从活跃的连接集合中移除
+ 42:                         state.activeConnections.remove(oldestActiveConnection);
+ 43:                         // 如果非自动提交的，需要进行回滚。即将原有执行中的事务，全部回滚。
+ 44:                         if (!oldestActiveConnection.getRealConnection().getAutoCommit()) {
+ 45:                             try {
+ 46:                                 oldestActiveConnection.getRealConnection().rollback();
+ 47:                             } catch (SQLException e) {
+ 48:                                 /*
+ 49:                                    Just log a message for debug and continue to execute the following
+ 50:                                    statement like nothing happened.
+ 51:                                    Wrap the bad connection with a new PooledConnection, this will help
+ 52:                                    to not interrupt current executing thread and give current thread a
+ 53:                                    chance to join the next competition for another valid/good database
+ 54:                                    connection. At the end of this loop, bad {@link @conn} will be set as null.
+ 55:                                 */
+ 56:                                 log.debug("Bad connection. Could not roll back");
+ 57:                             }
+ 58:                         }
+ 59:                         // 创建新的 PooledConnection 连接对象
+ 60:                         conn = new PooledConnection(oldestActiveConnection.getRealConnection(), this);
+ 61:                         conn.setCreatedTimestamp(oldestActiveConnection.getCreatedTimestamp());
+ 62:                         conn.setLastUsedTimestamp(oldestActiveConnection.getLastUsedTimestamp());
+ 63:                         // 设置 oldestActiveConnection 为无效
+ 64:                         oldestActiveConnection.invalidate();
+ 65:                         if (log.isDebugEnabled()) {
+ 66:                             log.debug("Claimed overdue connection " + conn.getRealHashCode() + ".");
+ 67:                         }
+ 68:                     } else { // 检查到未超时
+ 69:                         // Must wait
+ 70:                         try {
+ 71:                             // 对等待连接进行统计。通过 countedWait 标识，在这个循环中，只记录一次。
+ 72:                             if (!countedWait) {
+ 73:                                 state.hadToWaitCount++;
+ 74:                                 countedWait = true;
+ 75:                             }
+ 76:                             if (log.isDebugEnabled()) {
+ 77:                                 log.debug("Waiting as long as " + poolTimeToWait + " milliseconds for connection.");
+ 78:                             }
+ 79:                             // 记录当前时间
+ 80:                             long wt = System.currentTimeMillis();
+ 81:                             // 等待，直到超时，或 pingConnection 方法中归还连接时的唤醒
+ 82:                             state.wait(poolTimeToWait);
+ 83:                             // 统计等待连接的时间
+ 84:                             state.accumulatedWaitTime += System.currentTimeMillis() - wt;
+ 85:                         } catch (InterruptedException e) {
+ 86:                             break;
+ 87:                         }
+ 88:                     }
+ 89:                 }
+ 90:             }
+ 91:             // 获取到连接
+ 92:             if (conn != null) {
+ 93:                 // ping to server and check the connection is valid or not
+ 94:                 // 通过 ping 来测试连接是否有效
+ 95:                 if (conn.isValid()) {
+ 96:                     // 如果非自动提交的，需要进行回滚。即将原有执行中的事务，全部回滚。
+ 97:                     // 这里又执行了一次，有点奇怪。目前猜测，是不是担心上一次适用方忘记提交或回滚事务 TODO 1001 芋艿
+ 98:                     if (!conn.getRealConnection().getAutoCommit()) {
+ 99:                         conn.getRealConnection().rollback();
+100:                     }
+101:                     // 设置获取连接的属性
+102:                     conn.setConnectionTypeCode(assembleConnectionTypeCode(dataSource.getUrl(), username, password));
+103:                     conn.setCheckoutTimestamp(System.currentTimeMillis());
+104:                     conn.setLastUsedTimestamp(System.currentTimeMillis());
+105:                     // 添加到活跃的连接集合
+106:                     state.activeConnections.add(conn);
+107:                     // 对获取成功连接的统计
+108:                     state.requestCount++;
+109:                     state.accumulatedRequestTime += System.currentTimeMillis() - t;
+110:                 } else {
+111:                     if (log.isDebugEnabled()) {
+112:                         log.debug("A bad connection (" + conn.getRealHashCode() + ") was returned from the pool, getting another connection.");
+113:                     }
+114:                     // 统计获取到坏的连接的次数
+115:                     state.badConnectionCount++;
+116:                     // 记录获取到坏的连接的次数【本方法】
+117:                     localBadConnectionCount++;
+118:                     // 将 conn 置空，那么可以继续获取
+119:                     conn = null;
+120:                     // 如果超过最大次数，抛出 SQLException 异常
+121:                     // 为什么次数要包含 poolMaximumIdleConnections 呢？相当于把激活的连接，全部遍历一次。
+122:                     if (localBadConnectionCount > (poolMaximumIdleConnections + poolMaximumLocalBadConnectionTolerance)) {
+123:                         if (log.isDebugEnabled()) {
+124:                             log.debug("PooledDataSource: Could not get a good connection to the database.");
+125:                         }
+126:                         throw new SQLException("PooledDataSource: Could not get a good connection to the database.");
+127:                     }
+128:                 }
+129:             }
+130:         }
+131:     }
+132: 
+133:     // 获取不到连接，抛出 SQLException 异常
+134:     if (conn == null) {
+135:         if (log.isDebugEnabled()) {
+136:             log.debug("PooledDataSource: Unknown severe error condition.  The connection pool returned a null connection.");
+137:         }
+138:         throw new SQLException("PooledDataSource: Unknown severe error condition.  The connection pool returned a null connection.");
+139:     }
+140: 
+141:     return conn;
+142: }
+```
+
+- 第 2 至 5 行：声明四个变量，具体用途，看看注释。
+
+- 第 8 行：`while` 循环，获取可用的 Connection 连接，或超过获取次数上限( `poolMaximumIdleConnections + poolMaximumLocalBadConnectionTolerance` )。
+
+- 第 9 行：基于 `state` 变量做同步，避免并发问题。从这个锁的粒度来说，颗粒度还是比较大的，所以 MyBatis 自带的数据池连接池性能应该一般。从 [《Druid 锁的公平模式问题》](https://github.com/alibaba/druid/wiki/Druid锁的公平模式问题) 文章来看，Druid 在锁的处理上，肯定是**相对**精细的。
+
+- ============== 获取连接，分成四种 ==============
+
+- 第 10 至 17 行：
+
+  第一种
+
+  ，空闲连接
+
+  非空
+
+  ，此处就使用到了
+
+   
+
+  ```
+  PoolState.idleConnections
+  ```
+
+   
+
+  属性。
+
+  - 第 14 行：通过移除 `PoolState.idleConnections` 的方式，获得首个空闲的连接。
+
+- 第 20 至 28 行：
+
+  第二种
+
+  ，空闲连接
+
+  为空
+
+  ，激活的连接数小于
+
+   
+
+  ```
+  poolMaximumActiveConnections
+  ```
+
+   
+
+  。
+
+  - 第 25 行：创建新的 PooledConnection 连接对象。此处，**真正**的数据库连接，是通过 `UnpooledConnection#getConnection()` 方法获取到的。
+
+- 第 32 行：获取首个激活的 PooledConnection 对象，从 `PoolState.activeConnections` 中。
+
+- 第 36 至 67 行：
+
+  第三种
+
+  ，获取的连接
+
+  已超时
+
+  ，那么就可以
+
+  重新
+
+  使用该连接的
+
+  真实数据库连接
+
+  了。所以，我们可以发现，连接的超时发现，并不是由一个定时任务后台执行，而是有点类似
+
+  懒加载
+
+  的方式，在连接不够的时候，再去进行处理。实际上，很多“东西”的过期，都是基于这样的思路，例如 Redis 的键过期。
+
+  - 第 36 至 40 行：对连接超时的时间的统计。
+  - 第 42 行：从活跃的连接集合 `PoolState.activeConnections` 中移除。
+  - 第 43 至 58 行：如果非自动提交的，需要进行回滚。即将原有执行中的事务，全部回滚。
+  - 第 59 至 62 行：创建新的 PooledConnection 连接对象。此处，使用的是 `oldestActiveConnection.realConnection` 。
+  - 第 64 行：调用 `PooledConnection#invalidate()` 方法，设置 `oldestActiveConnection` 为无效。这样，如果目前正在使用该连接的调用方，如果在发起数据库操作，将可以抛出异常。具体原因，可见 [「5.2 invoke」](https://svip.iocoder.cn/MyBatis/datasource-package/#) 。
+
+- 第 68 至 87 行：**第四种**，获取的连接**未超时**，那么就只能**等待**。
+
+  - 第 71 至 75 行：对等待连接进行统计。通过 `countedWait` 标识，在这个循环中，只记录一次。
+  - 【重要】第 82 行：**等待**，直到**超时**，或 `pingConnection` 方法中归还连接时的**唤醒**。
+  - 第 80 && 84 行：统计等待连接的时间。
+
+- ============== 校验连接 ==============
+
+- 第 95 行：调用 `PooledConnection#isValid()` 方法，校验获得的连接是否可用。详细解析，见 [「5.3 isValid」](https://svip.iocoder.cn/MyBatis/datasource-package/#) 。
+
+- 第 95 至 109 行：连接
+
+  可用
+
+  。
+
+  - 第 96 至 100 行：如果非自动提交的，需要进行回滚。即将原有执行中的事务，全部回滚。这里又执行了一次，有点奇怪。目前猜测，是不是担心上一次适用方忘记提交或回滚事务 TODO 1002 芋艿
+  - 第 101 至 104 行：设置获取连接的属性。
+  - 第 106 行：添加到活跃的连接集合 `PoolState.activeConnections` 中。
+  - 第 107 至 109 行：对获取成功连接的统计。
+
+- 第 110 至 128 行：连接**不可用**。
+
+  - 第 115 行：统计获取到坏的连接的次数。
+  - 第 117 行：记录获取到坏的连接的次数【本方法】`localBadConnectionCount` 。
+  - 第 119 行：将 `conn` 置空，那么可以继续获取，即回到【第 8 行】代码。
+  - 第 120 至 127 行：如果超过最大次数，抛出 SQLException 异常。为什么次数要包含 `poolMaximumIdleConnections` 呢？相当于把激活的连接，全部遍历一次。
+
+- ============== 循环结束 ==============
+
+- 第 133 至 139 行：获取不到连接，抛出 SQLException 异常。实际上，这块逻辑是不会执行到的，无论是从上面的逻辑推导，还是从官方在抛出的 SQLException 异常的描述。
+
+嘿嘿，代码有点长。胖友好好品味下。
+
+### 3.2.3 pushConnection
+
+`#pushConnection(PooledConnection conn)` 方法，将使用完的连接，添加回连接池中。
+
+整体流程如下图：
+
+> FROM [《MyBatis 技术内幕》](https://item.jd.com/12125531.html)
+>
+> [![整体流程](07-mybatis-数据源模块.assets/04.png)](http://static.iocoder.cn/images/MyBatis/2020_01_16/04.png)整体流程
+
+代码如下：
+
+```
+// PooledDataSource.java
+
+protected void pushConnection(PooledConnection conn) throws SQLException {
+    synchronized (state) {
+        // 从激活的连接集合中移除该连接
+        state.activeConnections.remove(conn);
+        // 通过 ping 来测试连接是否有效
+        if (conn.isValid()) { // 有效
+            // 判断是否超过空闲连接上限，并且和当前连接池的标识匹配
+            if (state.idleConnections.size() < poolMaximumIdleConnections && conn.getConnectionTypeCode() == expectedConnectionTypeCode) {
+                // 统计连接使用时长
+                state.accumulatedCheckoutTime += conn.getCheckoutTime();
+                // 回滚事务，避免适用房未提交或者回滚事务
+                if (!conn.getRealConnection().getAutoCommit()) {
+                    conn.getRealConnection().rollback();
+                }
+                // 创建 PooledConnection 对象，并添加到空闲的链接集合中
+                PooledConnection newConn = new PooledConnection(conn.getRealConnection(), this);
+                state.idleConnections.add(newConn);
+                newConn.setCreatedTimestamp(conn.getCreatedTimestamp());
+                newConn.setLastUsedTimestamp(conn.getLastUsedTimestamp());
+                // 设置原连接失效
+                // 为什么这里要创建新的 PooledConnection 对象呢？避免使用方还在使用 conn ，通过将它设置为失效，万一再次调用，会抛出异常
+                conn.invalidate();
+                if (log.isDebugEnabled()) {
+                    log.debug("Returned connection " + newConn.getRealHashCode() + " to pool.");
+                }
+                // 唤醒正在等待连接的线程
+                state.notifyAll();
+            } else {
+                // 统计连接使用时长
+                state.accumulatedCheckoutTime += conn.getCheckoutTime();
+                // 回滚事务，避免适用房未提交或者回滚事务
+                if (!conn.getRealConnection().getAutoCommit()) {
+                    conn.getRealConnection().rollback();
+                }
+                // 关闭真正的数据库连接
+                conn.getRealConnection().close();
+                if (log.isDebugEnabled()) {
+                    log.debug("Closed connection " + conn.getRealHashCode() + ".");
+                }
+                // 设置原连接失效
+                conn.invalidate();
+            }
+        } else { // 失效
+            if (log.isDebugEnabled()) {
+                log.debug("A bad connection (" + conn.getRealHashCode() + ") attempted to return to the pool, discarding connection.");
+            }
+            // 统计获取到坏的连接的次数
+            state.badConnectionCount++;
+        }
+    }
+}
+```
+
+- 代码虽长，胖友耐心跟着代码注释读读。还是蛮简单的。
+- 该方法会被 PooledConnection 的 [「5.2 invoke」](https://svip.iocoder.cn/MyBatis/datasource-package/#) 在 `methodName = close` 方法的情况下时被调用。
+
+### 3.2.4 pingConnection
+
+`#pingConnection(PooledConnection conn)` 方法，通过向数据库发起 `poolPingQuery` 语句来发起“ping”操作，以判断数据库连接是否有效。代码如下：
+
+```
+// PooledDataSource.java
+
+/**
+ * Method to check to see if a connection is still usable
+ *
+ * @param conn - the connection to check
+ * @return True if the connection is still usable
+ */
+protected boolean pingConnection(PooledConnection conn) {
+    // 记录是否 ping 成功
+    boolean result;
+
+    // 判断真实的连接是否已经关闭。若已关闭，就意味着 ping 肯定是失败的。
+    try {
+        result = !conn.getRealConnection().isClosed();
+    } catch (SQLException e) {
+        if (log.isDebugEnabled()) {
+            log.debug("Connection " + conn.getRealHashCode() + " is BAD: " + e.getMessage());
+        }
+        result = false;
+    }
+
+    if (result) {
+        // 是否启用侦测查询
+        if (poolPingEnabled) {
+            // 判断是否长时间未使用。若是，才需要发起 ping
+            if (poolPingConnectionsNotUsedFor >= 0 && conn.getTimeElapsedSinceLastUse() > poolPingConnectionsNotUsedFor) {
+                try {
+                    if (log.isDebugEnabled()) {
+                        log.debug("Testing connection " + conn.getRealHashCode() + " ...");
+                    }
+                    // 通过执行 poolPingQuery 语句来发起 ping
+                    Connection realConn = conn.getRealConnection();
+                    try (Statement statement = realConn.createStatement()) {
+                        statement.executeQuery(poolPingQuery).close();
+                    }
+                    if (!realConn.getAutoCommit()) {
+                        realConn.rollback();
+                    }
+                    // 标记执行成功
+                    result = true;
+                    if (log.isDebugEnabled()) {
+                        log.debug("Connection " + conn.getRealHashCode() + " is GOOD!");
+                    }
+                } catch (Exception e) {
+                    // 关闭数据库真实的连接
+                    log.warn("Execution of ping query '" + poolPingQuery + "' failed: " + e.getMessage());
+                    try {
+                        conn.getRealConnection().close();
+                    } catch (Exception e2) {
+                        //ignore
+                    }
+                    // 标记执行失败
+                    result = false;
+                    if (log.isDebugEnabled()) {
+                        log.debug("Connection " + conn.getRealHashCode() + " is BAD: " + e.getMessage());
+                    }
+                }
+            }
+        }
+    }
+    return result;
+}
+```
+
+- 代码虽长，胖友耐心跟着代码注释读读。还是蛮简单的。
+- 该方法会被 PooledConnection 的 [「5.2 invoke」](https://svip.iocoder.cn/MyBatis/datasource-package/#) 在 `methodName != close` 方法的情况下时被调用，校验连接是否可用。
+
+### 3.2.5 forceCloseAll
+
+`#forceCloseAll()` 方法，关闭所有的 `activeConnections` 和 `idleConnections` 的连接。代码如下：
+
+```
+// PooledDataSource.java
+
+/*
+ * Closes all active and idle connections in the pool
+ */
+public void forceCloseAll() {
+    synchronized (state) {
+        // 计算 expectedConnectionTypeCode
+        expectedConnectionTypeCode = assembleConnectionTypeCode(dataSource.getUrl(), dataSource.getUsername(), dataSource.getPassword());
+        // 遍历 activeConnections ，进行关闭
+        for (int i = state.activeConnections.size(); i > 0; i--) {
+            try {
+                // 设置为失效
+                PooledConnection conn = state.activeConnections.remove(i - 1);
+                conn.invalidate();
+
+                // 回滚事务，如果有事务未提交或回滚
+                Connection realConn = conn.getRealConnection();
+                if (!realConn.getAutoCommit()) {
+                    realConn.rollback();
+                }
+                // 关闭真实的连接
+                realConn.close();
+            } catch (Exception e) {
+                // ignore
+            }
+        }
+        // 遍历 idleConnections ，进行关闭
+        //【实现代码上，和上面是一样的】
+        for (int i = state.idleConnections.size(); i > 0; i--) {
+            try {
+                // 设置为失效
+                PooledConnection conn = state.idleConnections.remove(i - 1);
+                conn.invalidate();
+
+                // 回滚事务，如果有事务未提交或回滚
+                Connection realConn = conn.getRealConnection();
+                if (!realConn.getAutoCommit()) {
+                    realConn.rollback();
+                }
+                // 关闭真实的连接
+                realConn.close();
+            } catch (Exception e) {
+                // ignore
+            }
+        }
+    }
+    if (log.isDebugEnabled()) {
+        log.debug("PooledDataSource forcefully closed/removed all connections.");
+    }
+}
+```
+
+- 代码虽长，胖友耐心跟着代码注释读读。还是蛮简单的。
+
+- 该方法会被 `#finalize()` 方法所调用，即当前 PooledDataSource 对象被释放时。代码如下：
+
+  ```
+  // PoolState.java
+  
+  protected void finalize() throws Throwable {
+      // 关闭所有连接
+      forceCloseAll();
+      // 执行对象销毁
+      super.finalize();
+  }
+  ```
+
+### 3.2.6 unwrapConnection
+
+`#unwrapConnection(Connection conn)` 方法，获取真实的数据库连接。代码如下：
+
+```
+// PoolState.java
+
+/**
+ * Unwraps a pooled connection to get to the 'real' connection
+ *
+ * @param conn - the pooled connection to unwrap
+ * @return The 'real' connection
+ */
+public static Connection unwrapConnection(Connection conn) {
+    // 如果传入的是被代理的连接
+    if (Proxy.isProxyClass(conn.getClass())) {
+        // 获取 InvocationHandler 对象
+        InvocationHandler handler = Proxy.getInvocationHandler(conn);
+        // 如果是 PooledConnection 对象，则获取真实的连接
+        if (handler instanceof PooledConnection) {
+            return ((PooledConnection) handler).getRealConnection();
+        }
+    }
+    return conn;
+}
+```
+
+### 3.2.7 其它方法
+
+PooledDataSource 还有其它简单方法，胖友自己瞅瞅，都简单。
+
+# 4. PoolState
+
+`org.apache.ibatis.datasource.pooled.PoolState` ，连接池状态，记录空闲和激活的 PooledConnection 集合，以及相关的数据统计。代码如下：
+
+```
+ // PoolState.java
+ 
+ /**
+ * 所属的 PooledDataSource 对象
+ */
+protected PooledDataSource dataSource;
+
+/**
+ * 空闲的 PooledConnection 集合
+ */
+protected final List<PooledConnection> idleConnections = new ArrayList<>();
+/**
+ * 激活的的 PooledConnection 集合
+ */
+protected final List<PooledConnection> activeConnections = new ArrayList<>();
+
+/**
+ * 全局统计 - 获取连接的次数
+ */
+protected long requestCount = 0;
+/**
+ * 全局统计 - 获取连接的时间
+ */
+protected long accumulatedRequestTime = 0;
+/**
+ * 全局统计 - 获取到连接非超时 + 超时的占用时长
+ *
+ * 所以，包括 {@link #accumulatedCheckoutTimeOfOverdueConnections} 部分
+ */
+protected long accumulatedCheckoutTime = 0;
+/**
+ * 全局统计 - 获取到连接超时的次数
+ */
+protected long claimedOverdueConnectionCount = 0;
+/**
+ * 全局统计 - 获取到连接超时的占用时长
+ */
+protected long accumulatedCheckoutTimeOfOverdueConnections = 0;
+/**
+ * 全局统计 - 等待连接的时间
+ */
+protected long accumulatedWaitTime = 0;
+/**
+ * 全局统计 - 等待连接的次数
+ */
+protected long hadToWaitCount = 0;
+/**
+ * 全局统计 - 获取到坏的连接的次数
+ */
+protected long badConnectionCount = 0;
+```
+
+- `dataSource` 属性，所属的 PooledDataSource 对象。
+- `idleConnections` 属性，空闲的 PooledConnection 集合，即该连接**未**被使用，还在连接池中。
+- `activeConnections` 属性，激活的 PooledConnection 集合，即该连接**正在**被使用，不在连接池中。
+- 其它全局**统计**属性，指的是和当前 `dataSource` 获得连接相关的统计。
+
+PoolState 还有一些其它方法，比较简单，感兴趣的胖友，可以自己去看。
+
+# 5. PooledConnection
+
+`org.apache.ibatis.datasource.pooled.PooledConnection` ，实现 InvocationHandler 接口，池化的 Connection 对象。
+
+## 5.1 构造方法
+
+```
+// PooledConnection.java
+
+/**
+ * 关闭 Connection 方法名
+ */
+private static final String CLOSE = "close";
+
+/**
+ * JDK Proxy 的接口
+ */
+private static final Class<?>[] IFACES = new Class<?>[]{Connection.class};
+
+/**
+ * 对象的标识，基于 {@link #realConnection} 求 hashCode
+ */
+private final int hashCode;
+/**
+ * 所属的 PooledDataSource 对象
+ */
+private final PooledDataSource dataSource;
+/**
+ * 真实的 Connection 连接
+ */
+private final Connection realConnection;
+/**
+ * 代理的 Connection 连接，即 {@link PooledConnection} 这个动态代理的 Connection 对象
+ */
+private final Connection proxyConnection;
+/**
+ * 从连接池中，获取走的时间戳
+ */
+private long checkoutTimestamp;
+/**
+ * 对象创建时间
+ */
+private long createdTimestamp;
+/**
+ * 最后更新时间
+ */
+private long lastUsedTimestamp;
+/**
+ * 连接的标识，即 {@link PooledDataSource#expectedConnectionTypeCode}
+ */
+private int connectionTypeCode;
+/**
+ * 是否有效
+ */
+private boolean valid;
+
+/**
+ * Constructor for SimplePooledConnection that uses the Connection and PooledDataSource passed in
+ *
+ * @param connection - the connection that is to be presented as a pooled connection
+ * @param dataSource - the dataSource that the connection is from
+ */
+public PooledConnection(Connection connection, PooledDataSource dataSource) {
+    this.hashCode = connection.hashCode();
+    this.realConnection = connection;
+    this.dataSource = dataSource;
+    this.createdTimestamp = System.currentTimeMillis();
+    this.lastUsedTimestamp = System.currentTimeMillis();
+    this.valid = true;
+    // <1> 创建代理的 Connection 对象
+    this.proxyConnection = (Connection) Proxy.newProxyInstance(Connection.class.getClassLoader(), IFACES, this);
+}
+```
+
+- 属性比较简单，胖友直接看代码注释。
+- `dataSource` 属性，所属的 PooledDataSource 对象。
+- `realConnection` 属性，**真实**的 Connection 连接。
+- `proxyConnection` 属性，**代理**的 Connection 连接，在 `<1>` 处，基于 JDK Proxy 创建 Connection 对象，并且 `handler` 对象就是 `this` ，也就是自己。那意味着什么？后续对 `proxyConnection` 的所有方法调用，都会委托给 `PooledConnection#invoke(Object proxy, Method method, Object[] args)` 方法。更多“秘密”，见 [「5.2 invoke」](https://svip.iocoder.cn/MyBatis/datasource-package/#) 。
+
+## 5.2 invoke
+
+`#invoke(Object proxy, Method method, Object[] args)` 方法，代理调用方法。代码如下：
+
+```
+// PooledConnection.java
+
+@Override
+public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
+    String methodName = method.getName();
+    // <1> 判断是否为 CLOSE 方法，则将连接放回到连接池中，避免连接被关闭
+    if (CLOSE.hashCode() == methodName.hashCode() && CLOSE.equals(methodName)) {
+        dataSource.pushConnection(this);
+        return null;
+    } else {
+        try {
+            // <2.1> 判断非 Object 的方法，则先检查连接是否可用
+            if (!Object.class.equals(method.getDeclaringClass())) {
+                // issue #579 toString() should never fail
+                // throw an SQLException instead of a Runtime
+                checkConnection();
+            }
+            // <2.2> 反射调用对应的方法
+            return method.invoke(realConnection, args);
+        } catch (Throwable t) {
+            throw ExceptionUtil.unwrapThrowable(t);
+        }
+    }
+}
+```
+
+- `<1>` 处，判断调用的方法是不是 `Connection#close()` 方法，如果是，则调用 `PooledDataSource#pushConnection(PooledConnection conn)` 方法，将该连接放回到连接池中，从而避免连接被关闭。
+
+- `<2.1>` 处，判断非 Object 的方法，则**额外**调用 `#checkConnection()` 方法，则先检查连接是否可用。代码如下：
+
+  ```
+  // PooledConnection.java
+  
+  private void checkConnection() throws SQLException {
+      if (!valid) {
+          throw new SQLException("Error accessing PooledConnection. Connection is invalid.");
+      }
+  }
+  ```
+
+  - 当 `valid` 为 `false` 时，意味着连接无效，所以抛出 SQLException 异常。
+
+- `<2.2>` 处，反射调用对应的方法。
+
+## 5.3 isValid
+
+`#isValid()` 方法，校验连接是否可用。代码如下：
+
+```
+// PooledConnection.java
+
+public boolean isValid() {
+    return valid && realConnection != null && dataSource.pingConnection(this);
+}
+```
+
+- 当连接有效时，调用 `PooledDataSource#pingConnection(PooledConnection conn)` 方法，向数据库发起 “ping” 请求，判断连接是否真正有效。
+
+## 5.4 invalidate
+
+`#invalidate()` 方法，设置连接无效。代码如下：
+
+```
+// PooledConnection.java
+
+public boolean isValid() {
+    return valid && realConnection != null && dataSource.pingConnection(this);
+}
+```
+
+## 5.5 其它方法
+
+PooledConnection 还有其它简单方法，胖友自己瞅瞅，都简单。
+
+# 666. 彩蛋
+
+呼呼，又对数据库连接池又加深了认识，有机会看看 Druid 或者 HikariCP 的源码实现。如果胖友对 HikariCP 感兴趣，可以看看 [《HikariCP 实现原理与源码解析系统 —— 精品合集》](http://www.iocoder.cn/HikariCP/good-collection/?svip) 。
+
+参考和推荐如下文章：
+
+- 田小波 [《MyBatis 源码分析 - 内置数据源》](https://www.tianxiaobo.com/2018/08/19/MyBatis-源码分析-内置数据源/)
+- 徐郡明 [《MyBatis 技术内幕》](https://item.jd.com/12125531.html) 的 [「2.6 DataSource」](https://svip.iocoder.cn/MyBatis/datasource-package/#) 小节
\ No newline at end of file
diff --git a/mybatis/08-mybatis-事务模块.md b/mybatis/08-mybatis-事务模块.md
new file mode 100644
index 0000000..847f97c
--- /dev/null
+++ b/mybatis/08-mybatis-事务模块.md
@@ -0,0 +1,467 @@
+# 精尽 MyBatis 源码分析 —— 事务模块
+
+# 1. 概述
+
+本文，我们来分享 MyBatis 的事务模块，对应 `transaction` 包。如下图所示：[`transaction` 包](http://static.iocoder.cn/images/MyBatis/2020_01_19/01.png)
+
+在 [《精尽 MyBatis 源码解析 —— 项目结构一览》](http://svip.iocoder.cn/MyBatis/intro) 中，简单介绍了这个模块如下：
+
+> MyBatis 对数据库中的事务进行了抽象，其自身提供了**相应的事务接口和简单实现**。
+>
+> 在很多场景中，MyBatis 会与 Spring 框架集成，并由 **Spring 框架管理事务**。
+
+本文涉及的类如下图所示：[类图](http://static.iocoder.cn/images/MyBatis/2020_01_19/02.png)
+
+下面，我们就一起来看看具体的源码实现。
+
+# 2. Transaction
+
+`org.apache.ibatis.transaction.Transaction` ，事务接口。代码如下：
+
+```
+// Transaction.java
+
+public interface Transaction {
+
+    /**
+     * 获得连接
+     * 
+     * Retrieve inner database connection
+     *
+     * @return DataBase connection
+     * @throws SQLException
+     */
+    Connection getConnection() throws SQLException;
+
+    /**
+     * 事务提交
+     * 
+     * Commit inner database connection.
+     *
+     * @throws SQLException
+     */
+    void commit() throws SQLException;
+
+    /**
+     * 事务回滚
+     * 
+     * Rollback inner database connection.
+     *
+     * @throws SQLException
+     */
+    void rollback() throws SQLException;
+
+    /**
+     * 关闭连接
+     * 
+     * Close inner database connection.
+     *
+     * @throws SQLException
+     */
+    void close() throws SQLException;
+
+    /**
+     * 获得事务超时时间
+     * 
+     * Get transaction timeout if set
+     *
+     * @throws SQLException
+     */
+    Integer getTimeout() throws SQLException;
+
+}
+```
+
+- 连接相关
+  - `#getConnection()` 方法，获得连接。
+  - `#close()` 方法，关闭连接。
+- 事务相关
+  - `#commit()` 方法，事务提交。
+  - `#rollback()` 方法，事务回滚。
+  - `#getTimeout()` 方法，事务超时时间。实际上，目前这个方法都是空实现。
+
+## 2.1 JdbcTransaction
+
+`org.apache.ibatis.transaction.jdbc.JdbcTransaction` ，实现 Transaction 接口，基于 JDBC 的事务实现类。代码如下：
+
+```
+// JdbcTransaction.java
+
+public class JdbcTransaction implements Transaction {
+
+    private static final Log log = LogFactory.getLog(JdbcTransaction.class);
+
+    /**
+     * Connection 对象
+     */
+    protected Connection connection;
+    /**
+     * DataSource 对象
+     */
+    protected DataSource dataSource;
+    /**
+     * 事务隔离级别
+     */
+    protected TransactionIsolationLevel level;
+    /**
+     * 是否自动提交
+     */
+    protected boolean autoCommit;
+
+    public JdbcTransaction(DataSource ds, TransactionIsolationLevel desiredLevel, boolean desiredAutoCommit) {
+        dataSource = ds;
+        level = desiredLevel;
+        autoCommit = desiredAutoCommit;
+    }
+
+    public JdbcTransaction(Connection connection) {
+        this.connection = connection;
+    }
+
+    @Override
+    public Connection getConnection() throws SQLException {
+        // 连接为空，进行创建
+        if (connection == null) {
+            openConnection();
+        }
+        return connection;
+    }
+
+    @Override
+    public void commit() throws SQLException {
+        // 非自动提交，则执行提交事务
+        if (connection != null && !connection.getAutoCommit()) {
+            if (log.isDebugEnabled()) {
+                log.debug("Committing JDBC Connection [" + connection + "]");
+            }
+            connection.commit();
+        }
+    }
+
+    @Override
+    public void rollback() throws SQLException {
+        // 非自动提交。则回滚事务
+        if (connection != null && !connection.getAutoCommit()) {
+            if (log.isDebugEnabled()) {
+                log.debug("Rolling back JDBC Connection [" + connection + "]");
+            }
+            connection.rollback();
+        }
+    }
+
+    @Override
+    public void close() throws SQLException {
+        if (connection != null) {
+            // 重置连接为自动提交
+            resetAutoCommit();
+            if (log.isDebugEnabled()) {
+                log.debug("Closing JDBC Connection [" + connection + "]");
+            }
+            // 关闭连接
+            connection.close();
+        }
+    }
+
+    /**
+     * 设置指定的 autoCommit 属性
+     *
+     * @param desiredAutoCommit 指定的 autoCommit 属性
+     */
+    protected void setDesiredAutoCommit(boolean desiredAutoCommit) {
+        try {
+            if (connection.getAutoCommit() != desiredAutoCommit) {
+                if (log.isDebugEnabled()) {
+                    log.debug("Setting autocommit to " + desiredAutoCommit + " on JDBC Connection [" + connection + "]");
+                }
+                connection.setAutoCommit(desiredAutoCommit);
+            }
+        } catch (SQLException e) {
+            // Only a very poorly implemented driver would fail here,
+            // and there's not much we can do about that.
+            throw new TransactionException("Error configuring AutoCommit.  "
+                    + "Your driver may not support getAutoCommit() or setAutoCommit(). "
+                    + "Requested setting: " + desiredAutoCommit + ".  Cause: " + e, e);
+        }
+    }
+
+    /**
+     * 重置 autoCommit 属性
+     */
+    protected void resetAutoCommit() {
+        try {
+            if (!connection.getAutoCommit()) {
+                // MyBatis does not call commit/rollback on a connection if just selects were performed.
+                // Some databases start transactions with select statements
+                // and they mandate a commit/rollback before closing the connection.
+                // A workaround is setting the autocommit to true before closing the connection.
+                // Sybase throws an exception here.
+                if (log.isDebugEnabled()) {
+                    log.debug("Resetting autocommit to true on JDBC Connection [" + connection + "]");
+                }
+                connection.setAutoCommit(true);
+            }
+        } catch (SQLException e) {
+            if (log.isDebugEnabled()) {
+                log.debug("Error resetting autocommit to true "
+                        + "before closing the connection.  Cause: " + e);
+            }
+        }
+    }
+
+    /**
+     * 获得 Connection 对象
+     *
+     * @throws SQLException 获得失败
+     */
+    protected void openConnection() throws SQLException {
+        if (log.isDebugEnabled()) {
+            log.debug("Opening JDBC Connection");
+        }
+        // 获得连接
+        connection = dataSource.getConnection();
+        // 设置隔离级别
+        if (level != null) {
+            connection.setTransactionIsolation(level.getLevel());
+        }
+        // 设置 autoCommit 属性
+        setDesiredAutoCommit(autoCommit);
+    }
+
+    @Override
+    public Integer getTimeout() throws SQLException {
+        return null;
+    }
+
+}
+```
+
+- 简单，胖友瞄一瞄。
+
+## 2.2 ManagedTransaction
+
+`org.apache.ibatis.transaction.managed.ManagedTransaction` ，实现 Transaction 接口，基于容器管理的事务实现类。代码如下：
+
+```
+// ManagedTransaction.java
+
+public class ManagedTransaction implements Transaction {
+
+    private static final Log log = LogFactory.getLog(ManagedTransaction.class);
+
+    /**
+     * Connection 对象
+     */
+    private Connection connection;
+    /**
+     * DataSource 对象
+     */
+    private DataSource dataSource;
+    /**
+     * 事务隔离级别
+     */
+    private TransactionIsolationLevel level;
+    /**
+     * 是否关闭连接
+     *
+     * 这个属性是和 {@link org.apache.ibatis.transaction.jdbc.JdbcTransaction} 不同的
+     */
+    private final boolean closeConnection;
+
+    public ManagedTransaction(Connection connection, boolean closeConnection) {
+        this.connection = connection;
+        this.closeConnection = closeConnection;
+    }
+
+    public ManagedTransaction(DataSource ds, TransactionIsolationLevel level, boolean closeConnection) {
+        this.dataSource = ds;
+        this.level = level;
+        this.closeConnection = closeConnection;
+    }
+
+    @Override
+    public Connection getConnection() throws SQLException {
+        // 连接为空，进行创建
+        if (this.connection == null) {
+            openConnection();
+        }
+        return this.connection;
+    }
+
+    @Override
+    public void commit() throws SQLException {
+        // Does nothing
+    }
+
+    @Override
+    public void rollback() throws SQLException {
+        // Does nothing
+    }
+
+    @Override
+    public void close() throws SQLException {
+        // 如果开启关闭连接功能，则关闭连接
+        if (this.closeConnection && this.connection != null) {
+            if (log.isDebugEnabled()) {
+                log.debug("Closing JDBC Connection [" + this.connection + "]");
+            }
+            this.connection.close();
+        }
+    }
+
+    protected void openConnection() throws SQLException {
+        if (log.isDebugEnabled()) {
+            log.debug("Opening JDBC Connection");
+        }
+        // 获得连接
+        this.connection = this.dataSource.getConnection();
+        // 设置隔离级别
+        if (this.level != null) {
+            this.connection.setTransactionIsolation(this.level.getLevel());
+        }
+    }
+
+    @Override
+    public Integer getTimeout() throws SQLException {
+        return null;
+    }
+
+}
+```
+
+- 和 JdbcTransaction 相比，少了 `autoCommit` 属性，空实现 `#commit()` 和 `#rollback()` 方法。因此，事务的管理，交给了容器。
+- 简单了解下就成，实际没用过这个。
+
+## 2.3 SpringManagedTransaction
+
+`org.mybatis.spring.transaction.SpringManagedTransaction` ，实现 Transaction 接口，基于 Spring 管理的事务实现类。实际真正在使用的，本文暂时不分享，感兴趣的胖友可以自己先愁一愁 [SpringManagedTransaction](https://github.com/eddumelendez/mybatis-spring/blob/master/src/main/java/org/mybatis/spring/transaction/SpringManagedTransaction.java) 。
+
+# 3. TransactionFactory
+
+`org.apache.ibatis.transaction.TransactionFactory` ，Transaction 工厂接口。代码如下：
+
+```
+// TransactionFactory.java
+
+public interface TransactionFactory {
+
+    /**
+     * Sets transaction factory custom properties.
+     *
+     * 设置工厂的属性
+     *
+     * @param props 属性
+     */
+    void setProperties(Properties props);
+
+    /**
+     * Creates a {@link Transaction} out of an existing connection.
+     *
+     * 创建 Transaction 事务
+     *
+     * @param conn Existing database connection
+     * @return Transaction
+     * @since 3.1.0
+     */
+    Transaction newTransaction(Connection conn);
+
+    /**
+     * Creates a {@link Transaction} out of a datasource.
+     *
+     * 创建 Transaction 事务
+     *
+     * @param dataSource DataSource to take the connection from
+     * @param level      Desired isolation level
+     * @param autoCommit Desired autocommit
+     * @return Transaction
+     * @since 3.1.0
+     */
+    Transaction newTransaction(DataSource dataSource, TransactionIsolationLevel level, boolean autoCommit);
+
+}
+```
+
+## 3.1 JdbcTransactionFactory
+
+`org.apache.ibatis.transaction.jdbc.JdbcTransactionFactory` ，实现 TransactionFactory 接口，JdbcTransaction 工厂实现类。代码如下：
+
+```
+// JdbcTransactionFactory.java
+
+public class JdbcTransactionFactory implements TransactionFactory {
+
+    @Override
+    public void setProperties(Properties props) {
+    }
+
+    @Override
+    public Transaction newTransaction(Connection conn) {
+        // 创建 JdbcTransaction 对象
+        return new JdbcTransaction(conn);
+    }
+
+    @Override
+    public Transaction newTransaction(DataSource ds, TransactionIsolationLevel level, boolean autoCommit) {
+        // 创建 JdbcTransaction 对象
+        return new JdbcTransaction(ds, level, autoCommit);
+    }
+
+}
+```
+
+- 胖友随便瞅一眼。
+
+## 3.2 ManagedTransactionFactory
+
+`org.apache.ibatis.transaction.managed.ManagedTransactionFactory` ，实现 TransactionFactory 接口，ManagedTransaction 工厂实现类。代码如下：
+
+```
+// ManagedTransactionFactory.java
+
+public class ManagedTransactionFactory implements TransactionFactory {
+
+    /**
+     * 是否关闭连接
+     */
+    private boolean closeConnection = true;
+
+    @Override
+    public void setProperties(Properties props) {
+        // 获得是否关闭连接属性
+        if (props != null) {
+            String closeConnectionProperty = props.getProperty("closeConnection");
+            if (closeConnectionProperty != null) {
+                closeConnection = Boolean.valueOf(closeConnectionProperty);
+            }
+        }
+    }
+
+    @Override
+    public Transaction newTransaction(Connection conn) {
+        // 创建 ManagedTransaction 对象
+        return new ManagedTransaction(conn, closeConnection);
+    }
+
+    @Override
+    public Transaction newTransaction(DataSource ds, TransactionIsolationLevel level, boolean autoCommit) {
+        // Silently ignores autocommit and isolation level, as managed transactions are entirely
+        // controlled by an external manager.  It's silently ignored so that
+        // code remains portable between managed and unmanaged configurations.
+        // 创建 ManagedTransaction 对象
+        return new ManagedTransaction(ds, level, closeConnection);
+    }
+
+}
+```
+
+## 3.3 SpringManagedTransactionFactory
+
+`org.mybatis.spring.transaction.SpringManagedTransactionFactory` ，实现 TransactionFactory 接口，SpringManagedTransaction 工厂实现类。实际真正在使用的，本文暂时不分享，感兴趣的胖友可以自己先愁一愁 [SpringManagedTransactionFactory](https://github.com/eddumelendez/mybatis-spring/blob/c5834f93bd4a5879f86854fe188957787e56ef95/src/main/java/org/mybatis/spring/transaction/SpringManagedTransactionFactory.java) 。
+
+# 666. 彩蛋
+
+水文一篇，开心。
+
+参考和推荐如下文章：
+
+- 祖大俊 [《Mybatis3.3.x技术内幕（三）：Mybatis事务管理（将颠覆你心中目前对事务的理解）》](https://my.oschina.net/zudajun/blog/666764)
+- 徐郡明 [《MyBatis 技术内幕》](https://item.jd.com/12125531.html) 的 [「2.7 Transaction」](https://svip.iocoder.cn/MyBatis/transaction-package/#) 小节
\ No newline at end of file
diff --git a/mybatis/09-mybatis-缓存模块.assets/01.png b/mybatis/09-mybatis-缓存模块.assets/01.png
new file mode 100644
index 0000000..08ea0b4
Binary files /dev/null and b/mybatis/09-mybatis-缓存模块.assets/01.png differ
diff --git a/mybatis/09-mybatis-缓存模块.assets/02.png b/mybatis/09-mybatis-缓存模块.assets/02.png
new file mode 100644
index 0000000..2756d51
Binary files /dev/null and b/mybatis/09-mybatis-缓存模块.assets/02.png differ
diff --git a/mybatis/09-mybatis-缓存模块.md b/mybatis/09-mybatis-缓存模块.md
new file mode 100644
index 0000000..0a34c01
--- /dev/null
+++ b/mybatis/09-mybatis-缓存模块.md
@@ -0,0 +1,1403 @@
+# 精尽 MyBatis 源码分析 —— 缓存模块
+
+# 1. 概述
+
+本文，我们来分享 MyBatis 的缓存模块，对应 `cache` 包。如下图所示：[![`transaction` 包](09-mybatis-缓存模块.assets/01.png)](http://static.iocoder.cn/images/MyBatis/2020_01_22/01.png)`transaction` 包
+
+在 [《精尽 MyBatis 源码解析 —— 项目结构一览》](http://svip.iocoder.cn/MyBatis/intro) 中，简单介绍了这个模块如下：
+
+> 在优化系统性能时，优化数据库性能是非常重要的一个环节，而添加缓存则是优化数据库时最有效的手段之一。正确、合理地使用缓存可以将一部分数据库请求拦截在缓存这一层。
+>
+> MyBatis 中提供了**一级缓存和二级缓存**，而这两级缓存都是依赖于基础支持层中的缓 存模块实现的。这里需要读者注意的是，MyBatis 中自带的这两级缓存与 MyBatis 以及整个应用是运行在同一个 JVM 中的，共享同一块堆内存。如果这两级缓存中的数据量较大， 则可能影响系统中其他功能的运行，所以当需要缓存大量数据时，优先考虑使用 Redis、Memcache 等缓存产品。
+
+本文涉及的类如下图所示：[![类图](09-mybatis-缓存模块.assets/02.png)](http://static.iocoder.cn/images/MyBatis/2020_01_22/02.png)类图
+
+下面，我们就一起来看看具体的源码实现。另外，如果你对 MyBatis 的 Cache 机制不是很了解，可以简单阅读下 [《MyBatis 文档 —— 缓存》](http://www.mybatis.org/mybatis-3/zh/sqlmap-xml.html#cache) 。
+
+# 2. Cache
+
+`org.apache.ibatis.cache.Cache` ，缓存**容器**接口。**注意，它是一个容器，有点类似 HashMap ，可以往其中添加各种缓存**。代码如下：
+
+```
+// Cache.java
+
+public interface Cache {
+
+    /**
+     * @return The identifier of this cache 标识
+     */
+    String getId();
+
+    /**
+     * 添加指定键的值
+     *
+     * @param key Can be any object but usually it is a {@link CacheKey}
+     * @param value The result of a select.
+     */
+    void putObject(Object key, Object value);
+
+    /**
+     * 获得指定键的值
+     *
+     * @param key The key
+     * @return The object stored in the cache.
+     */
+    Object getObject(Object key);
+
+    /**
+     * 移除指定键的值
+     *
+     * As of 3.3.0 this method is only called during a rollback
+     * for any previous value that was missing in the cache.
+     * This lets any blocking cache to release the lock that
+     * may have previously put on the key.
+     * A blocking cache puts a lock when a value is null
+     * and releases it when the value is back again.
+     * This way other threads will wait for the value to be
+     * available instead of hitting the database.
+     *
+     *
+     * @param key The key
+     * @return Not used
+     */
+    Object removeObject(Object key);
+
+    /**
+     * 清空缓存
+     *
+     * Clears this cache instance
+     */
+    void clear();
+
+    /**
+     * 获得容器中缓存的数量
+     *
+     * Optional. This method is not called by the core.
+     *
+     * @return The number of elements stored in the cache (not its capacity).
+     */
+    int getSize();
+
+    /**
+     * 获得读取写锁。该方法可以忽略了已经。
+     *
+     * Optional. As of 3.2.6 this method is no longer called by the core.
+     *
+     * Any locking needed by the cache must be provided internally by the cache provider.
+     *
+     * @return A ReadWriteLock
+     */
+    @Deprecated // add by 芋艿
+    ReadWriteLock getReadWriteLock();
+
+}
+```
+
+- 方法比较简单。
+
+Cache 基于不同的**缓存过期策略**、**特性**，有不同的实现类。下面，我们来逐个来看。可以组合**多种** Cache ，实现特性的组合。这种方式，就是常见的设计模式，[《【设计模式读书笔记】装饰者模式》](http://www.iocoder.cn/DesignPattern/xiaomingge/Decorator-Pattern/?vip) 。
+
+## 2.1 PerpetualCache
+
+`org.apache.ibatis.cache.impl.PerpetualCache` ，实现 Cache 接口，**永不过期**的 Cache 实现类，基于 HashMap 实现类。代码如下：
+
+```
+// PerpetualCache.java
+
+public class PerpetualCache implements Cache {
+
+    /**
+     * 标识
+     */
+    private final String id;
+    /**
+     * 缓存容器
+     */
+    private Map<Object, Object> cache = new HashMap<>();
+
+    public PerpetualCache(String id) {
+        this.id = id;
+    }
+
+    @Override
+    public String getId() {
+        return id;
+    }
+
+    @Override
+    public int getSize() {
+        return cache.size();
+    }
+
+    @Override
+    public void putObject(Object key, Object value) {
+        cache.put(key, value);
+    }
+
+    @Override
+    public Object getObject(Object key) {
+        return cache.get(key);
+    }
+
+    @Override
+    public Object removeObject(Object key) {
+        return cache.remove(key);
+    }
+
+    @Override
+    public void clear() {
+        cache.clear();
+    }
+    
+    // ... 省略 equals 和 hashCode 方法
+    
+}
+```
+
+- 比较简单，胖友自己瞅瞅。
+
+## 2.2 LoggingCache
+
+`org.apache.ibatis.cache.decorators.LoggingCache` ，实现 Cache 接口，**支持打印日志**的 Cache 实现类。代码如下：
+
+```
+// LoggingCache.java
+
+public class LoggingCache implements Cache {
+
+    /**
+     * MyBatis Log 对象
+     */
+    private final Log log;
+    /**
+     * 装饰的 Cache 对象
+     */
+    private final Cache delegate;
+    /**
+     * 统计请求缓存的次数
+     */
+    protected int requests = 0;
+    /**
+     * 统计命中缓存的次数
+     */
+    protected int hits = 0;
+
+    public LoggingCache(Cache delegate) {
+        this.delegate = delegate;
+        this.log = LogFactory.getLog(getId());
+    }
+
+    @Override
+    public String getId() {
+        return delegate.getId();
+    }
+
+    @Override
+    public int getSize() {
+        return delegate.getSize();
+    }
+
+    @Override
+    public void putObject(Object key, Object object) {
+        delegate.putObject(key, object);
+    }
+
+    @Override
+    public Object getObject(Object key) {
+        // 请求次数 ++
+        requests++;
+        // 获得缓存
+        final Object value = delegate.getObject(key);
+        // 如果命中缓存，则命中次数 ++
+        if (value != null) {
+            hits++;
+        }
+        if (log.isDebugEnabled()) {
+            log.debug("Cache Hit Ratio [" + getId() + "]: " + getHitRatio());
+        }
+        return value;
+    }
+
+    @Override
+    public Object removeObject(Object key) {
+        return delegate.removeObject(key);
+    }
+
+    @Override
+    public void clear() {
+        delegate.clear();
+    }
+
+    /**
+     * @return 命中比率
+     */
+    private double getHitRatio() {
+        return (double) hits / (double) requests;
+    }
+
+    // ... 省略 equals 和 hashCode 方法
+    
+}
+```
+
+- `delegate` 属性，被装饰的 Cache 对象。
+- 在 `#getObject(Object key)` 方法，增加了 `requests` 和 `hits` 的计数，从而实现命中比率的统计，即 `#getHitRatio()` 方法。
+
+## 2.3 BlockingCache
+
+`org.apache.ibatis.cache.decoratorsBlockingCache` ，实现 Cache 接口，**阻塞的** Cache 实现类。
+
+这里的阻塞比较特殊，当线程去获取缓存值时，如果不存在，则会阻塞后续的其他线程去获取该缓存。
+为什么这么有这样的设计呢？因为当线程 A 在获取不到缓存值时，一般会去设置对应的缓存值，这样就避免其他也需要该缓存的线程 B、C 等，重复添加缓存。
+
+代码如下：
+
+```
+// BlockingCache.java
+
+public class BlockingCache implements Cache {
+
+    /**
+     * 阻塞等待超时时间
+     */
+    private long timeout;
+    /**
+     * 装饰的 Cache 对象
+     */
+    private final Cache delegate;
+    /**
+     * 缓存键与 ReentrantLock 对象的映射
+     */
+    private final ConcurrentHashMap<Object, ReentrantLock> locks;
+
+    public BlockingCache(Cache delegate) {
+        this.delegate = delegate;
+        this.locks = new ConcurrentHashMap<>();
+    }
+
+    @Override
+    public String getId() {
+        return delegate.getId();
+    }
+
+    @Override
+    public int getSize() {
+        return delegate.getSize();
+    }
+
+    @Override
+    public void putObject(Object key, Object value) {
+        try {
+            // <2.1> 添加缓存
+            delegate.putObject(key, value);
+        } finally {
+            // <2.2> 释放锁
+            releaseLock(key);
+        }
+    }
+
+    @Override
+    public Object getObject(Object key) {
+        // <1.1> 获得锁
+        acquireLock(key);
+        // <1.2> 获得缓存值
+        Object value = delegate.getObject(key);
+        // <1.3> 释放锁
+        if (value != null) {
+            releaseLock(key);
+        }
+        return value;
+    }
+
+    @Override
+    public Object removeObject(Object key) {
+        // despite of its name, this method is called only to release locks
+        // 释放锁
+        releaseLock(key);
+        return null;
+    }
+
+    @Override
+    public void clear() {
+        delegate.clear();
+    }
+
+    @Override
+    public ReadWriteLock getReadWriteLock() {
+        return null;
+    }
+
+    /**
+     * 获得 ReentrantLock 对象。如果不存在，进行添加
+     *
+     * @param key 缓存键
+     * @return ReentrantLock 对象
+     */
+    private ReentrantLock getLockForKey(Object key) {
+        ReentrantLock lock = new ReentrantLock();
+        ReentrantLock previous = locks.putIfAbsent(key, lock);
+        return previous == null ? lock : previous;
+    }
+
+    private void acquireLock(Object key) {
+        // 获得 ReentrantLock 对象。
+        Lock lock = getLockForKey(key);
+        // 获得锁，直到超时
+        if (timeout > 0) {
+            try {
+                boolean acquired = lock.tryLock(timeout, TimeUnit.MILLISECONDS);
+                if (!acquired) {
+                    throw new CacheException("Couldn't get a lock in " + timeout + " for the key " + key + " at the cache " + delegate.getId());
+                }
+            } catch (InterruptedException e) {
+                throw new CacheException("Got interrupted while trying to acquire lock for key " + key, e);
+            }
+        } else {
+            // 释放锁
+            lock.lock();
+        }
+    }
+
+    private void releaseLock(Object key) {
+        // 获得 ReentrantLock 对象
+        ReentrantLock lock = locks.get(key);
+        // 如果当前线程持有，进行释放
+        if (lock.isHeldByCurrentThread()) {
+            lock.unlock();
+        }
+    }
+
+    public long getTimeout() {
+        return timeout;
+    }
+
+    public void setTimeout(long timeout) {
+        this.timeout = timeout;
+    }
+
+}
+```
+
+- ```
+  locks
+  ```
+
+   
+
+  属性，缓存键与 ReentrantLock 对象的映射。
+
+  - `#getLockForKey(Object key)` 方法，获得 ReentrantLock 对象。如果不存在，进行添加。
+  - `#acquireLock(Object key)` 方法，锁定 ReentrantLock 对象。
+  - `#releaseLock(Object key)` 方法，释放 ReentrantLock 对象。
+
+- ```
+  #getObject(Object key)
+  ```
+
+   
+
+  方法：
+
+  - `<1.1>` 处，首先会获得锁。这样其它线程来获取该值时，将被阻塞等待。那岂不是有问题？答案在 `<1.3>` 处。
+  - `<1.2>` 处，然后，获得缓存值。
+  - `<1.3>` 处，获得缓存值**成功**时，会释放锁，这样被阻塞等待的其他线程就可以去获取缓存了。但是，如果获得缓存值**失败**时，就需要在 `#putObject(Object key, Object value)` 方法中，添加缓存时，才会释放锁，这样被阻塞等待的其它线程就不会重复添加缓存了。
+
+- ```
+  #putObject(Object key, Object value)
+  ```
+
+   
+
+  方法：
+
+  - `<2.1>` 处，添加缓存。
+  - `<2.2>` 处，释放锁。
+
+- `#removeObject(Object key)` 方法，它很**特殊**，和方法名字有所“冲突”，不会移除对应的缓存，只会移除锁。
+
+## 2.4 SynchronizedCache
+
+`org.apache.ibatis.cache.decorators.SynchronizedCache` ，实现 Cache 接口，**同步**的 Cache 实现类。代码如下：
+
+```
+// SynchronizedCache.java
+
+public class SynchronizedCache implements Cache {
+
+    /**
+     * 装饰的 Cache 对象
+     */
+    private final Cache delegate;
+
+    public SynchronizedCache(Cache delegate) {
+        this.delegate = delegate;
+    }
+
+    @Override
+    public String getId() {
+        return delegate.getId();
+    }
+
+    @Override // 同步
+    public synchronized int getSize() {
+        return delegate.getSize();
+    }
+
+    @Override // 同步
+    public synchronized void putObject(Object key, Object object) {
+        delegate.putObject(key, object);
+    }
+
+    @Override // 同步
+    public synchronized Object getObject(Object key) {
+        return delegate.getObject(key);
+    }
+
+    @Override // 同步
+    public synchronized Object removeObject(Object key) {
+        return delegate.removeObject(key);
+    }
+
+    @Override // 同步
+    public synchronized void clear() {
+        delegate.clear();
+    }
+
+    // ... 省略 equals 和 hashCode 方法
+
+}
+```
+
+- 比较简单，相应的方法，添加了 `synchronized` 修饰符。
+
+## 2.5 SerializedCache
+
+`org.apache.ibatis.cache.decorators.SerializedCache` ，实现 Cache 接口，**支持序列化值**的 Cache 实现类。代码如下：
+
+```
+// SerializedCache.java
+
+public class SerializedCache implements Cache {
+
+    /**
+     * 装饰的 Cache 对象
+     */
+    private final Cache delegate;
+
+    public SerializedCache(Cache delegate) {
+        this.delegate = delegate;
+    }
+
+    @Override
+    public String getId() {
+        return delegate.getId();
+    }
+
+    @Override
+    public int getSize() {
+        return delegate.getSize();
+    }
+
+    @Override
+    public void putObject(Object key, Object object) {
+        if (object == null || object instanceof Serializable) {
+            delegate.putObject(key, serialize((Serializable) object)); // 序列化
+        } else {
+            throw new CacheException("SharedCache failed to make a copy of a non-serializable object: " + object);
+        }
+    }
+
+    @Override
+    public Object getObject(Object key) {
+        Object object = delegate.getObject(key);
+        return object == null ? null : deserialize((byte[]) object); // 反序列化
+    }
+
+    @Override
+    public Object removeObject(Object key) {
+        return delegate.removeObject(key);
+    }
+
+    @Override
+    public void clear() {
+        delegate.clear();
+    }
+
+    // ... 省略 equals 和 hashCode 方法
+
+    private byte[] serialize(Serializable value) {
+        try (ByteArrayOutputStream bos = new ByteArrayOutputStream();
+             ObjectOutputStream oos = new ObjectOutputStream(bos)) {
+            oos.writeObject(value);
+            oos.flush();
+            return bos.toByteArray();
+        } catch (Exception e) {
+            throw new CacheException("Error serializing object.  Cause: " + e, e);
+        }
+    }
+
+    private Serializable deserialize(byte[] value) {
+        Serializable result;
+        try (ByteArrayInputStream bis = new ByteArrayInputStream(value);
+             ObjectInputStream ois = new CustomObjectInputStream(bis)) {
+            result = (Serializable) ois.readObject();
+        } catch (Exception e) {
+            throw new CacheException("Error deserializing object.  Cause: " + e, e);
+        }
+        return result;
+    }
+
+    public static class CustomObjectInputStream extends ObjectInputStream {
+
+        public CustomObjectInputStream(InputStream in) throws IOException {
+            super(in);
+        }
+
+        @Override
+        protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException, ClassNotFoundException {
+            return Resources.classForName(desc.getName()); // 解析类
+        }
+
+    }
+
+}
+```
+
+- 比较简单，胖友自己看看。
+
+## 2.6 ScheduledCache
+
+`org.apache.ibatis.cache.decorators.ScheduledCache` ，实现 Cache 接口，**定时清空整个容器**的 Cache 实现类。代码如下：
+
+```
+// ScheduledCache.java
+
+public class ScheduledCache implements Cache {
+
+    /**
+     * 被装饰的 Cache 对象
+     */
+    private final Cache delegate;
+    /**
+     * 清空间隔，单位：毫秒
+     */
+    protected long clearInterval;
+    /**
+     * 最后清空时间，单位：毫秒
+     */
+    protected long lastClear;
+
+    public ScheduledCache(Cache delegate) {
+        this.delegate = delegate;
+        this.clearInterval = 60 * 60 * 1000; // 1 hour
+        this.lastClear = System.currentTimeMillis();
+    }
+
+    public void setClearInterval(long clearInterval) {
+        this.clearInterval = clearInterval;
+    }
+
+    @Override
+    public String getId() {
+        return delegate.getId();
+    }
+
+    @Override
+    public int getSize() {
+        // 判断是否要全部清空
+        clearWhenStale();
+        return delegate.getSize();
+    }
+
+    @Override
+    public void putObject(Object key, Object object) {
+        // 判断是否要全部清空
+        clearWhenStale();
+        delegate.putObject(key, object);
+    }
+
+    @Override
+    public Object getObject(Object key) {
+        // 判断是否要全部清空
+        return clearWhenStale() ? null : delegate.getObject(key); // 获得值
+    }
+
+    @Override
+    public Object removeObject(Object key) {
+        // 判断是否要全部清空
+        clearWhenStale();
+        return delegate.removeObject(key);
+    }
+
+    @Override
+    public void clear() {
+        // 记录清空时间
+        lastClear = System.currentTimeMillis();
+        // 全部清空
+        delegate.clear();
+    }
+
+    @Override
+    public ReadWriteLock getReadWriteLock() {
+        return null;
+    }
+
+    @Override
+    public int hashCode() {
+        return delegate.hashCode();
+    }
+
+    @Override
+    public boolean equals(Object obj) {
+        return delegate.equals(obj);
+    }
+
+    /**
+     * 判断是否要全部清空
+     *
+     * @return 是否全部清空
+     */
+    private boolean clearWhenStale() {
+        // 判断是否要全部清空
+        if (System.currentTimeMillis() - lastClear > clearInterval) {
+            // 清空
+            clear();
+            return true;
+        }
+        return false;
+    }
+
+}
+```
+
+- 每次缓存操作时，都调用 `#clearWhenStale()` 方法，根据情况，是否清空全部缓存。
+
+## 2.7 FifoCache
+
+`org.apache.ibatis.cache.decorators.FifoCache` ，实现 Cache 接口，**基于先进先出的淘汰机制**的 Cache 实现类。代码如下：
+
+```
+// FifoCache.java
+
+public class FifoCache implements Cache {
+
+    /**
+     * 装饰的 Cache 对象
+     */
+    private final Cache delegate;
+    /**
+     * 双端队列，记录缓存键的添加
+     */
+    private final Deque<Object> keyList;
+    /**
+     * 队列上限
+     */
+    private int size;
+
+    public FifoCache(Cache delegate) {
+        this.delegate = delegate;
+        this.keyList = new LinkedList<>(); // 使用了 LinkedList
+        this.size = 1024; // 默认为 1024
+    }
+
+    @Override
+    public String getId() {
+        return delegate.getId();
+    }
+
+    @Override
+    public int getSize() {
+        return delegate.getSize();
+    }
+
+    public void setSize(int size) {
+        this.size = size;
+    }
+
+    @Override
+    public void putObject(Object key, Object value) {
+        // 循环 keyList
+        cycleKeyList(key);
+        delegate.putObject(key, value);
+    }
+
+    @Override
+    public Object getObject(Object key) {
+        return delegate.getObject(key);
+    }
+
+    @Override
+    public Object removeObject(Object key) {
+        // <2> 此处，理论应该也要移除 keyList 呀
+        return delegate.removeObject(key);
+    }
+
+    @Override
+    public void clear() {
+        delegate.clear();
+        keyList.clear();
+    }
+
+    @Override
+    public ReadWriteLock getReadWriteLock() {
+        return null;
+    }
+
+    private void cycleKeyList(Object key) {
+        // <1> 添加到 keyList 对位
+        keyList.addLast(key);
+        // 超过上限，将队首位移除
+        if (keyList.size() > size) {
+            Object oldestKey = keyList.removeFirst();
+            delegate.removeObject(oldestKey);
+        }
+    }
+
+}
+```
+
+- 目前 FifoCache 的逻辑实现上，有一定的问题，主要有两点。
+- `<1>` 处，如果重复添加一个缓存，那么在 `keyList` 里会存储两个，占用了缓存上限的两个名额。
+- `<2>` 处，在移除指定缓存时，不会移除 `keyList` 里占用的一个名额。
+
+## 2.8 LruCache
+
+`org.apache.ibatis.cache.decorators.LruCache` ，实现 Cache 接口，**基于最少使用的淘汰机制**的 Cache 实现类。代码如下：
+
+```
+// LruCache.java
+
+public class LruCache implements Cache {
+
+    /**
+     * 装饰的 Cache 对象
+     */
+    private final Cache delegate;
+    /**
+     * 基于 LinkedHashMap 实现淘汰机制
+     */
+    private Map<Object, Object> keyMap;
+    /**
+     * 最老的键，即要被淘汰的
+     */
+    private Object eldestKey;
+
+    public LruCache(Cache delegate) {
+        this.delegate = delegate;
+        // 初始化 keyMap 对象
+        setSize(1024);
+    }
+
+    @Override
+    public String getId() {
+        return delegate.getId();
+    }
+
+    @Override
+    public int getSize() {
+        return delegate.getSize();
+    }
+
+    public void setSize(final int size) {
+        // LinkedHashMap的一个构造函数，当参数accessOrder为true时，即会按照访问顺序排序，最近访问的放在最前，最早访问的放在后面
+        keyMap = new LinkedHashMap<Object, Object>(size, .75F, true) { //
+
+            private static final long serialVersionUID = 4267176411845948333L;
+
+            // LinkedHashMap自带的判断是否删除最老的元素方法，默认返回false，即不删除老数据
+            // 我们要做的就是重写这个方法，当满足一定条件时删除老数据
+            @Override
+            protected boolean removeEldestEntry(Map.Entry<Object, Object> eldest) {
+                boolean tooBig = size() > size;
+                if (tooBig) {
+                    eldestKey = eldest.getKey();
+                }
+                return tooBig;
+            }
+
+        };
+    }
+
+    @Override
+    public void putObject(Object key, Object value) {
+        // 添加到缓存
+        delegate.putObject(key, value);
+        // 循环 keyMap
+        cycleKeyList(key);
+    }
+
+    @Override
+    public Object getObject(Object key) {
+        // 刷新 keyMap 的访问顺序
+        keyMap.get(key); // touch
+        // 获得缓存值
+        return delegate.getObject(key);
+    }
+
+    @Override
+    public Object removeObject(Object key) {
+        return delegate.removeObject(key);
+    }
+
+    @Override
+    public void clear() {
+        delegate.clear();
+        keyMap.clear();
+    }
+
+    @Override
+    public ReadWriteLock getReadWriteLock() {
+        return null;
+    }
+
+    private void cycleKeyList(Object key) {
+        // 添加到 keyMap 中
+        keyMap.put(key, key);
+        // 如果超过上限，则从 delegate 中，移除最少使用的那个
+        if (eldestKey != null) {
+            delegate.removeObject(eldestKey);
+            eldestKey = null; // 置空
+        }
+    }
+
+}
+```
+
+- 实现的原理，胖友可以看看 [《LRU缓存实现(Java)》](https://www.cnblogs.com/lzrabbit/p/3734850.html) 这篇文章，主要是对于 LinkedHashMap 的黑科技用法。
+
+## 2.9 WeakCache
+
+`org.apache.ibatis.cache.decorators.WeakCache` ，实现 Cache 接口，基于 `java.lang.ref.WeakReference` 的 Cache 实现类。代码如下：
+
+```
+// WeakCache.java
+
+public class WeakCache implements Cache {
+
+    /**
+     * 强引用的键的队列
+     */
+    private final Deque<Object> hardLinksToAvoidGarbageCollection;
+    /**
+     * {@link #hardLinksToAvoidGarbageCollection} 的大小
+     */
+    private int numberOfHardLinks;
+    /**
+     * 被 GC 回收的 WeakEntry 集合，避免被 GC。
+     */
+    private final ReferenceQueue<Object> queueOfGarbageCollectedEntries;
+    /**
+     * 装饰的 Cache 对象
+     */
+    private final Cache delegate;
+
+    public WeakCache(Cache delegate) {
+        this.delegate = delegate;
+        this.numberOfHardLinks = 256;
+        this.hardLinksToAvoidGarbageCollection = new LinkedList<>();
+        this.queueOfGarbageCollectedEntries = new ReferenceQueue<>();
+    }
+
+    @Override
+    public String getId() {
+        return delegate.getId();
+    }
+
+    @Override
+    public int getSize() {
+        // 移除已经被 GC 回收的 WeakEntry
+        removeGarbageCollectedItems();
+        return delegate.getSize();
+    }
+
+    public void setSize(int size) {
+        this.numberOfHardLinks = size;
+    }
+
+    @Override
+    public void putObject(Object key, Object value) {
+        // 移除已经被 GC 回收的 WeakEntry
+        removeGarbageCollectedItems();
+        // 添加到 delegate 中
+        delegate.putObject(key, new WeakEntry(key, value, queueOfGarbageCollectedEntries));
+    }
+
+    @Override
+    public Object getObject(Object key) {
+        Object result = null;
+        @SuppressWarnings("unchecked") // assumed delegate cache is totally managed by this cache
+        // 获得值的 WeakReference 对象
+        WeakReference<Object> weakReference = (WeakReference<Object>) delegate.getObject(key);
+        if (weakReference != null) {
+            // 获得值
+            result = weakReference.get();
+            // 为空，从 delegate 中移除 。为空的原因是，意味着已经被 GC 回收
+            if (result == null) {
+                delegate.removeObject(key);
+            // 非空，添加到 hardLinksToAvoidGarbageCollection 中，避免被 GC
+            } else {
+                // 添加到 hardLinksToAvoidGarbageCollection 的队头
+                hardLinksToAvoidGarbageCollection.addFirst(result);
+                // 超过上限，移除 hardLinksToAvoidGarbageCollection 的队尾
+                if (hardLinksToAvoidGarbageCollection.size() > numberOfHardLinks) {
+                    hardLinksToAvoidGarbageCollection.removeLast();
+                }
+            }
+        }
+        return result;
+    }
+
+    @Override
+    public Object removeObject(Object key) {
+        // 移除已经被 GC 回收的 WeakEntry
+        removeGarbageCollectedItems();
+        // 移除出 delegate
+        return delegate.removeObject(key);
+    }
+
+    @Override
+    public void clear() {
+        // 清空 hardLinksToAvoidGarbageCollection
+        hardLinksToAvoidGarbageCollection.clear();
+        // 移除已经被 GC 回收的 WeakEntry
+        removeGarbageCollectedItems();
+        // 清空 delegate
+        delegate.clear();
+    }
+
+    @Override
+    public ReadWriteLock getReadWriteLock() {
+        return null;
+    }
+
+    /**
+     * 移除已经被 GC 回收的键
+     */
+    private void removeGarbageCollectedItems() {
+        WeakEntry sv;
+        while ((sv = (WeakEntry) queueOfGarbageCollectedEntries.poll()) != null) {
+            delegate.removeObject(sv.key);
+        }
+    }
+
+    private static class WeakEntry extends WeakReference<Object> {
+
+        /**
+         * 键
+         */
+        private final Object key;
+
+        private WeakEntry(Object key, Object value, ReferenceQueue<Object> garbageCollectionQueue) {
+            super(value, garbageCollectionQueue);
+            this.key = key;
+        }
+
+    }
+
+}
+```
+
+- 因为有些胖友，对 Java 的四种引用类型不是很熟悉，推荐先阅读下 [《Java 中的四种引用类型》](https://juejin.im/post/5a5129f5f265da3e317dfc08) ，很有趣！！！
+
+- WeakEntry ，继承 WeakReference 类，因为要多定一个 `key` 属性，代表**缓存键**。
+
+- `#removeGarbageCollectedItems()` 方法，从 `delegate` 中移除已经被 GC 回收的 WeakEntry 。为什么能这样做呢？答案见 `#putObject(Object key, Object value)` 方法。
+
+- `#putObject(Object key, Object value)` 方法，我们可以看到，添加到 `delegate` 中的值是创建的 WeakEntry 对象，并且 WeakEntry 对象的 `garbageCollectionQueue` 属性为 `queueOfGarbageCollectedEntries` 。也就说，如果 WeakEntry 对象被 GC 时，就会添加到 `queueOfGarbageCollectedEntries` 队列中，那么 `#removeGarbageCollectedItems()` 方法就可以从 `delegate` 中移除已经被 GC 回收的 WeakEntry 。可能胖友会有点懵逼，但是这个真的非常有趣。
+
+- ```
+  #getObject(Object key)
+  ```
+
+   
+
+  方法：
+
+  - 首先，从 `delegate` 获取键对应的 WeakReference 对象。
+
+  - 如果，值**为空**，说明已经被 GC 掉，只能从 `delegate` 中移除。
+
+  - 如果，值
+
+    非空
+
+    ，为了避免被 GC 掉，所以添加到
+
+     
+
+    ```
+    hardLinksToAvoidGarbageCollection
+    ```
+
+     
+
+    队
+
+    头
+
+    。但是，该队列设置了一个上限(
+
+     
+
+    ```
+    numberOfHardLinks
+    ```
+
+     
+
+    )，避免队列无限大。
+
+    - 另外，这里添加到 `hardLinksToAvoidGarbageCollection` 队**头**应该是有问题的。因为，可能存在**重复**添加，如果获取相同的键。
+
+- 其它方法，胖友自己看看，比较简单的。
+
+## 2.10 SoftCache
+
+`org.apache.ibatis.cache.decorators.SoftCache` ，实现 Cache 接口，基于 `java.lang.ref.SoftReference` 的 Cache 实现类。代码如下：
+
+```
+// SoftCache.java
+
+public class SoftCache implements Cache {
+
+    /**
+     * 强引用的键的队列
+     */
+    private final Deque<Object> hardLinksToAvoidGarbageCollection;
+    /**
+     * {@link #hardLinksToAvoidGarbageCollection} 的大小
+     */
+    private int numberOfHardLinks;
+    /**
+     * 被 GC 回收的 WeakEntry 集合，避免被 GC。
+     */
+    private final ReferenceQueue<Object> queueOfGarbageCollectedEntries;
+    /**
+     * 装饰的 Cache 对象
+     */
+    private final Cache delegate;
+
+
+    public SoftCache(Cache delegate) {
+        this.delegate = delegate;
+        this.numberOfHardLinks = 256;
+        this.hardLinksToAvoidGarbageCollection = new LinkedList<>();
+        this.queueOfGarbageCollectedEntries = new ReferenceQueue<>();
+    }
+
+    @Override
+    public String getId() {
+        return delegate.getId();
+    }
+
+    @Override
+    public int getSize() {
+        removeGarbageCollectedItems();
+        return delegate.getSize();
+    }
+
+
+    public void setSize(int size) {
+        this.numberOfHardLinks = size;
+    }
+
+    @Override
+    public void putObject(Object key, Object value) {
+        // 移除已经被 GC 回收的 SoftEntry
+        removeGarbageCollectedItems();
+        delegate.putObject(key, new SoftEntry(key, value, queueOfGarbageCollectedEntries));
+    }
+
+    @Override
+    public Object getObject(Object key) {
+        Object result = null;
+        @SuppressWarnings("unchecked") // assumed delegate cache is totally managed by this cache
+        // 获得值的 WeakReference 对象
+        SoftReference<Object> softReference = (SoftReference<Object>) delegate.getObject(key);
+        if (softReference != null) {
+            // 获得值
+            result = softReference.get();
+            // 为空，从 delegate 中移除 。为空的原因是，意味着已经被 GC 回收
+            if (result == null) {
+                delegate.removeObject(key);
+            // 非空，添加到 hardLinksToAvoidGarbageCollection 中，避免被 GC
+            } else {
+                // See #586 (and #335) modifications need more than a read lock
+                // 添加到 hardLinksToAvoidGarbageCollection 的队头
+                synchronized (hardLinksToAvoidGarbageCollection) {
+                    hardLinksToAvoidGarbageCollection.addFirst(result);
+                    // 超过上限，移除 hardLinksToAvoidGarbageCollection 的队尾
+                    if (hardLinksToAvoidGarbageCollection.size() > numberOfHardLinks) {
+                        hardLinksToAvoidGarbageCollection.removeLast();
+                    }
+                }
+            }
+        }
+        return result;
+    }
+
+    @Override
+    public Object removeObject(Object key) {
+        // 移除已经被 GC 回收的 SoftEntry
+        removeGarbageCollectedItems();
+        // 移除出 delegate
+        return delegate.removeObject(key);
+    }
+
+    @Override
+    public void clear() {
+        // 清空 hardLinksToAvoidGarbageCollection
+        synchronized (hardLinksToAvoidGarbageCollection) {
+            hardLinksToAvoidGarbageCollection.clear();
+        }
+        // 移除已经被 GC 回收的 WeakEntry
+        removeGarbageCollectedItems();
+        // 清空 delegate
+        delegate.clear();
+    }
+
+    @Override
+    public ReadWriteLock getReadWriteLock() {
+        return null;
+    }
+
+    private void removeGarbageCollectedItems() {
+        SoftEntry sv;
+        while ((sv = (SoftEntry) queueOfGarbageCollectedEntries.poll()) != null) {
+            delegate.removeObject(sv.key);
+        }
+    }
+
+    private static class SoftEntry extends SoftReference<Object> {
+
+        /**
+         * 键
+         */
+        private final Object key;
+
+        SoftEntry(Object key, Object value, ReferenceQueue<Object> garbageCollectionQueue) {
+            super(value, garbageCollectionQueue);
+            this.key = key;
+        }
+    }
+
+}
+```
+
+- 实现逻辑上，和 WeakCache 是一致的，差异在使用 SoftEntry 替代了 WeakEntry 类。
+
+# 3. CacheKey
+
+`org.apache.ibatis.cache.CacheKey` ，实现 Cloneable、Serializable 接口，缓存键。
+
+因为 MyBatis 中的缓存键不是一个简单的 String ，**而是通过多个对象组成**。所以 CacheKey 可以理解成将多个对象放在一起，计算其缓存键。
+
+## 3.1 构造方法
+
+```
+// CacheKey.java
+
+private static final long serialVersionUID = 1146682552656046210L;
+
+/**
+ * 单例 - 空缓存键
+ */
+public static final CacheKey NULL_CACHE_KEY = new NullCacheKey();
+
+/**
+ * 默认 {@link #multiplier} 的值
+ */
+private static final int DEFAULT_MULTIPLYER = 37;
+/**
+ * 默认 {@link #hashcode} 的值
+ */
+private static final int DEFAULT_HASHCODE = 17;
+
+/**
+ * hashcode 求值的系数
+ */
+private final int multiplier;
+/**
+ * 缓存键的 hashcode
+ */
+private int hashcode;
+/**
+ * 校验和
+ */
+private long checksum;
+/**
+ * {@link #update(Object)} 的数量
+ */
+private int count;
+// 8/21/2017 - Sonarlint flags this as needing to be marked transient.  While true if content is not serializable, this is not always true and thus should not be marked transient.
+/**
+ * 计算 {@link #hashcode} 的对象的集合
+ */
+private List<Object> updateList;
+
+public CacheKey() {
+    this.hashcode = DEFAULT_HASHCODE;
+    this.multiplier = DEFAULT_MULTIPLYER;
+    this.count = 0;
+    this.updateList = new ArrayList<>();
+}
+
+public CacheKey(Object[] objects) {
+    this();
+    // 基于 objects ，更新相关属性
+    updateAll(objects);
+}
+```
+
+- 当构造方法的方法参数为 `Object[] objects` 时，会调用 `#updateAll(Object[] objects)` 方法，更新相关属性。
+
+## 3.2 updateAll
+
+`#updateAll(Object[] objects)` 方法，更新相关属性。代码如下：
+
+```
+// CacheKey.java
+
+public void updateAll(Object[] objects) {
+    for (Object o : objects) {
+        update(o);
+    }
+}
+```
+
+- 遍历 `objects` 数组，调用 `#update(Object)` 方法，更新相关属性。代码如下：
+
+  ```
+  // CacheKey.java
+  
+  public void update(Object object) {
+      // 方法参数 object 的 hashcode
+      int baseHashCode = object == null ? 1 : ArrayUtil.hashCode(object);
+  
+      count++;
+  
+      // checksum 为 baseHashCode 的求和
+      checksum += baseHashCode;
+  
+      // 计算新的 hashcode 值
+      baseHashCode *= count;
+      hashcode = multiplier * hashcode + baseHashCode;
+  
+      // 添加 object 到 updateList 中
+      updateList.add(object);
+  }
+  ```
+
+## 3.3 hashCode
+
+`#hashCode()` 方法，获得 `hashcode` 值。代码如下：
+
+```
+// CacheKey.java
+
+@Override
+public int hashCode() {
+    return hashcode;
+}
+```
+
+## 3.4 equals
+
+`#equals(Object object)` 方法，比较是否相等。代码如下：
+
+```
+// CacheKey.java
+
+@Override
+public boolean equals(Object object) {
+    if (this == object) {
+        return true;
+    }
+    if (!(object instanceof CacheKey)) {
+        return false;
+    }
+
+    final CacheKey cacheKey = (CacheKey) object;
+
+    if (hashcode != cacheKey.hashcode) {
+        return false;
+    }
+    if (checksum != cacheKey.checksum) {
+        return false;
+    }
+    if (count != cacheKey.count) {
+        return false;
+    }
+
+    // 比较 updateList 数组
+    for (int i = 0; i < updateList.size(); i++) {
+        Object thisObject = updateList.get(i);
+        Object thatObject = cacheKey.updateList.get(i);
+        if (!ArrayUtil.equals(thisObject, thatObject)) {
+            return false;
+        }
+    }
+    return true;
+}
+```
+
+## 3.5 clone
+
+`#clone()` 方法，克隆对象。代码如下：
+
+```
+// CacheKey.java
+
+@Override
+public CacheKey clone() throws CloneNotSupportedException {
+    // 克隆 CacheKey 对象
+    CacheKey clonedCacheKey = (CacheKey) super.clone();
+    // 创建 updateList 数组，避免原数组修改
+    clonedCacheKey.updateList = new ArrayList<>(updateList);
+    return clonedCacheKey;
+}
+```
+
+## 3.6 NullCacheKey
+
+`org.apache.ibatis.cache.NullCacheKey` ，继承 CacheKey 类，空缓存键。代码如下：
+
+```
+// NullCacheKey.java
+
+public final class NullCacheKey extends CacheKey {
+
+    private static final long serialVersionUID = 3704229911977019465L;
+
+    public NullCacheKey() {
+        super();
+    }
+
+    @Override
+    public void update(Object object) {
+        throw new CacheException("Not allowed to update a NullCacheKey instance.");
+    }
+
+    @Override
+    public void updateAll(Object[] objects) {
+        throw new CacheException("Not allowed to update a NullCacheKey instance.");
+    }
+
+}
+```
+
+# 4. 二级缓存
+
+MyBatis 的二级缓存，和执行器有很大的关联，所以放在 [《精尽 MyBatis 源码分析 —— SQL 执行（一）之 Executor》](http://svip.iocoder.cn/MyBatis/executor-1) 中，统一解析。
+
+- TransactionalCache
+- TransactionalCacheManager
+
+# 666. 彩蛋
+
+对缓存又多了解了一丢丢，hohoho 。
+
+参考和推荐如下文章：
+
+- 祖大俊 [《Mybatis3.4.x技术内幕（二十二）：Mybatis一级、二级缓存原理分析》](https://my.oschina.net/zudajun/blog/747499)
+- 徐郡明 [《MyBatis 技术内幕》](https://item.jd.com/12125531.html) 的 [「2.9 缓存模块」](https://svip.iocoder.cn/MyBatis/cache-package/#) 小节
\ No newline at end of file
diff --git a/mybatis/10-mybatis-类型模块.assets/01.png b/mybatis/10-mybatis-类型模块.assets/01.png
new file mode 100644
index 0000000..21faf7b
Binary files /dev/null and b/mybatis/10-mybatis-类型模块.assets/01.png differ
diff --git a/mybatis/10-mybatis-类型模块.assets/02.png b/mybatis/10-mybatis-类型模块.assets/02.png
new file mode 100644
index 0000000..deb06a1
Binary files /dev/null and b/mybatis/10-mybatis-类型模块.assets/02.png differ
diff --git a/mybatis/10-mybatis-类型模块.assets/03.png b/mybatis/10-mybatis-类型模块.assets/03.png
new file mode 100644
index 0000000..5257e55
Binary files /dev/null and b/mybatis/10-mybatis-类型模块.assets/03.png differ
diff --git a/mybatis/10-mybatis-类型模块.assets/04.png b/mybatis/10-mybatis-类型模块.assets/04.png
new file mode 100644
index 0000000..53a1d3e
Binary files /dev/null and b/mybatis/10-mybatis-类型模块.assets/04.png differ
diff --git a/mybatis/10-mybatis-类型模块.assets/05.png b/mybatis/10-mybatis-类型模块.assets/05.png
new file mode 100644
index 0000000..b888e1f
Binary files /dev/null and b/mybatis/10-mybatis-类型模块.assets/05.png differ
diff --git a/mybatis/10-mybatis-类型模块.md b/mybatis/10-mybatis-类型模块.md
new file mode 100644
index 0000000..2b98d78
--- /dev/null
+++ b/mybatis/10-mybatis-类型模块.md
@@ -0,0 +1,1714 @@
+# 精尽 MyBatis 源码分析 —— 类型模块
+
+# 1. 概述
+
+本文，我们来分享 MyBatis 的类型模块，对应 `type` 包。如下图所示：[![`type` 包](10-mybatis-类型模块.assets/01.png)](http://static.iocoder.cn/images/MyBatis/2020_01_25/01.png)`type` 包
+
+在 [《精尽 MyBatis 源码解析 —— 项目结构一览》](http://svip.iocoder.cn/MyBatis/intro) 中，简单介绍了这个模块如下：
+
+> ① MyBatis 为简化配置文件提供了**别名机制**，该机制是类型转换模块的主要功能之一。
+>
+> ② 类型转换模块的另一个功能是**实现 JDBC 类型与 Java 类型之间**的转换，该功能在为 SQL 语句绑定实参以及映射查询结果集时都会涉及：
+>
+> - 在为 SQL 语句绑定实参时，会将数据由 Java 类型转换成 JDBC 类型。
+> - 而在映射结果集时，会将数据由 JDBC 类型转换成 Java 类型。
+
+本文涉及的类如下图所示：[![类图](10-mybatis-类型模块.assets/02.png)](http://static.iocoder.cn/images/MyBatis/2020_01_25/02.png)类图
+
+# 2. TypeHandler
+
+`org.apache.ibatis.type.TypeHandler` ，类型转换处理器。代码如下：
+
+```
+// TypeHandler.java
+
+public interface TypeHandler<T> {
+
+    /**
+     * 设置 PreparedStatement 的指定参数
+     *
+     * Java Type => JDBC Type
+     *
+     * @param ps PreparedStatement 对象
+     * @param i 参数占位符的位置
+     * @param parameter 参数
+     * @param jdbcType JDBC 类型
+     * @throws SQLException 当发生 SQL 异常时
+     */
+    void setParameter(PreparedStatement ps, int i, T parameter, JdbcType jdbcType) throws SQLException;
+
+    /**
+     * 获得 ResultSet 的指定字段的值
+     *
+     * JDBC Type => Java Type
+     *
+     * @param rs ResultSet 对象
+     * @param columnName 字段名
+     * @return 值
+     * @throws SQLException 当发生 SQL 异常时
+     */
+    T getResult(ResultSet rs, String columnName) throws SQLException;
+
+    /**
+     * 获得 ResultSet 的指定字段的值
+     *
+     * JDBC Type => Java Type
+     *
+     * @param rs ResultSet 对象
+     * @param columnIndex 字段位置
+     * @return 值
+     * @throws SQLException 当发生 SQL 异常时
+     */
+    T getResult(ResultSet rs, int columnIndex) throws SQLException;
+
+    /**
+     * 获得 CallableStatement 的指定字段的值
+     *
+     * JDBC Type => Java Type
+     *
+     * @param cs CallableStatement 对象，支持调用存储过程
+     * @param columnIndex 字段位置
+     * @return 值
+     * @throws SQLException
+     */
+    T getResult(CallableStatement cs, int columnIndex) throws SQLException;
+
+}
+```
+
+- 一共有两类方法，分别是：
+
+  - `#setParameter(...)` 方法，是 `Java Type => JDBC Type` 的过程。
+  - `#getResult(...)` 方法，是 `JDBC Type => Java Type` 的过程。
+
+- 流程如下图：
+
+  ![流程](10-mybatis-类型模块.assets/03.png)
+
+  流程
+
+  - 左边是 `#setParameter(...)` 方法，是 `Java Type => JDBC Type` 的过程，从上往下看。
+  - 右边是 `#getResult(...)` 方法，是 `JDBC Type => Java Type` 的过程，从下往上看。
+
+## 2.1 BaseTypeHandler
+
+`org.apache.ibatis.type.BaseTypeHandler` ，实现 TypeHandler 接口，继承 TypeReference 抽象类，TypeHandler 基础抽象类。
+
+- 关于 TypeReference ，我们在 [「3. TypeHandler」](https://svip.iocoder.cn/MyBatis/type-package/#) 中，详细解析。
+
+### 2.1.1 setParameter
+
+`#setParameter(PreparedStatement ps, int i, T parameter, JdbcType jdbcType)` 方法，代码如下：
+
+```
+// BaseTypeHandler.java
+
+@Override
+public void setParameter(PreparedStatement ps, int i, T parameter, JdbcType jdbcType) throws SQLException {
+    // <1> 参数为空时，设置为 null 类型
+    if (parameter == null) {
+        if (jdbcType == null) {
+            throw new TypeException("JDBC requires that the JdbcType must be specified for all nullable parameters.");
+        }
+        try {
+            ps.setNull(i, jdbcType.TYPE_CODE);
+        } catch (SQLException e) {
+            throw new TypeException("Error setting null for parameter #" + i + " with JdbcType " + jdbcType + " . " +
+                    "Try setting a different JdbcType for this parameter or a different jdbcTypeForNull configuration property. " +
+                    "Cause: " + e, e);
+        }
+    // 参数非空时，设置对应的参数
+    } else {
+        try {
+            setNonNullParameter(ps, i, parameter, jdbcType);
+        } catch (Exception e) {
+            throw new TypeException("Error setting non null for parameter #" + i + " with JdbcType " + jdbcType + " . " +
+                    "Try setting a different JdbcType for this parameter or a different configuration property. " +
+                    "Cause: " + e, e);
+        }
+    }
+}
+```
+
+- `<1>` 处，参数为空，设置为 `null` 类型。
+
+- `<2>` 处，参数非空，调用 `#setNonNullParameter(PreparedStatement ps, int i, T parameter, JdbcType jdbcType)` **抽象**方法，设置对应的参数。代码如下：
+
+  ```
+  // BaseTypeHandler.java
+  
+  public abstract void setNonNullParameter(PreparedStatement ps, int i, T parameter, JdbcType jdbcType) throws SQLException;
+  ```
+
+  - 该方法由子类实现。
+
+- 当发生异常时，统一抛出 TypeException 异常。
+
+### 2.1.2 getResult
+
+`#getResult(...)` 方法，代码如下：
+
+```
+// BaseTypeHandler.java
+
+@Override
+public T getResult(ResultSet rs, String columnName) throws SQLException {
+    try {
+        return getNullableResult(rs, columnName);
+    } catch (Exception e) {
+        throw new ResultMapException("Error attempting to get column '" + columnName + "' from result set.  Cause: " + e, e);
+    }
+}
+
+@Override
+public T getResult(ResultSet rs, int columnIndex) throws SQLException {
+    try {
+        return getNullableResult(rs, columnIndex);
+    } catch (Exception e) {
+        throw new ResultMapException("Error attempting to get column #" + columnIndex + " from result set.  Cause: " + e, e);
+    }
+}
+
+@Override
+public T getResult(CallableStatement cs, int columnIndex) throws SQLException {
+    try {
+        return getNullableResult(cs, columnIndex);
+    } catch (Exception e) {
+        throw new ResultMapException("Error attempting to get column #" + columnIndex + " from callable statement.  Cause: " + e, e);
+    }
+}
+```
+
+- 调用 `#getNullableResult(...)` **抽象**方法，获得指定结果的字段值。代码如下：
+
+  ```
+  // BaseTypeHandler.java
+  
+  public abstract T getNullableResult(ResultSet rs, String columnName) throws SQLException;
+  
+  public abstract T getNullableResult(ResultSet rs, int columnIndex) throws SQLException;
+  
+  public abstract T getNullableResult(CallableStatement cs, int columnIndex) throws SQLException;
+  ```
+
+  - 该方法由子类实现。
+
+- 当发生异常时，统一抛出 ResultMapException 异常。
+
+## 2.2 子类
+
+TypeHandler 有非常多的子类，**当然所有子类都是继承自 BaseTypeHandler 抽象类**。考虑到篇幅，我们就挑选几个来聊聊。
+
+### 2.2.1 IntegerTypeHandler
+
+`org.apache.ibatis.type.IntegerTypeHandler` ，继承 BaseTypeHandler 抽象类，Integer 类型的 TypeHandler 实现类。代码如下：
+
+```
+// IntegerTypeHandler.java
+
+public class IntegerTypeHandler extends BaseTypeHandler<Integer> {
+
+    @Override
+    public void setNonNullParameter(PreparedStatement ps, int i, Integer parameter, JdbcType jdbcType)
+            throws SQLException {
+        // 直接设置参数即可
+        ps.setInt(i, parameter);
+    }
+
+    @Override
+    public Integer getNullableResult(ResultSet rs, String columnName)
+            throws SQLException {
+        // 获得字段的值
+        int result = rs.getInt(columnName);
+        // 先通过 rs 判断是否空，如果是空，则返回 null ，否则返回 result
+        return (result == 0 && rs.wasNull()) ? null : result;
+    }
+
+    @Override
+    public Integer getNullableResult(ResultSet rs, int columnIndex)
+            throws SQLException {
+        // 获得字段的值
+        int result = rs.getInt(columnIndex);
+        // 先通过 rs 判断是否空，如果是空，则返回 null ，否则返回 result
+        return (result == 0 && rs.wasNull()) ? null : result;
+    }
+
+    @Override
+    public Integer getNullableResult(CallableStatement cs, int columnIndex)
+            throws SQLException {
+        // 获得字段的值
+        int result = cs.getInt(columnIndex);
+        // 先通过 cs 判断是否空，如果是空，则返回 null ，否则返回 result
+        return (result == 0 && cs.wasNull()) ? null : result;
+    }
+}
+```
+
+- 比较简单，胖友瞅瞅。比较有意思的是 `ResultSet#wasNull()` 方法，它会判断**最后读取**的字段是否为空。
+
+### 2.2.2 DateTypeHandler
+
+`org.apache.ibatis.type.DateTypeHandler` ，继承 BaseTypeHandler 抽象类，Date 类型的 TypeHandler 实现类。代码如下：
+
+```
+// DateTypeHandler.java
+
+public class DateTypeHandler extends BaseTypeHandler<Date> {
+
+    @Override
+    public void setNonNullParameter(PreparedStatement ps, int i, Date parameter, JdbcType jdbcType)
+            throws SQLException {
+        // 将 Date 转换成 Timestamp 类型
+        // 然后设置到 ps 中
+        ps.setTimestamp(i, new Timestamp(parameter.getTime()));
+    }
+
+    @Override
+    public Date getNullableResult(ResultSet rs, String columnName)
+            throws SQLException {
+        // 获得 Timestamp 的值
+        Timestamp sqlTimestamp = rs.getTimestamp(columnName);
+        // 将 Timestamp 转换成 Date 类型
+        if (sqlTimestamp != null) {
+            return new Date(sqlTimestamp.getTime());
+        }
+        return null;
+    }
+
+    @Override
+    public Date getNullableResult(ResultSet rs, int columnIndex)
+            throws SQLException {
+        // 获得 Timestamp 的值
+        Timestamp sqlTimestamp = rs.getTimestamp(columnIndex);
+        // 将 Timestamp 转换成 Date 类型
+        if (sqlTimestamp != null) {
+            return new Date(sqlTimestamp.getTime());
+        }
+        return null;
+    }
+
+    @Override
+    public Date getNullableResult(CallableStatement cs, int columnIndex)
+            throws SQLException {
+        // 获得 Timestamp 的值
+        Timestamp sqlTimestamp = cs.getTimestamp(columnIndex);
+        // 将 Timestamp 转换成 Date 类型
+        if (sqlTimestamp != null) {
+            return new Date(sqlTimestamp.getTime());
+        }
+        return null;
+    }
+
+}
+```
+
+- `java.util.Date` 和 `java.sql.Timestamp` 的互相转换。
+
+### 2.2.3 DateOnlyTypeHandler
+
+`org.apache.ibatis.type.DateOnlyTypeHandler` ，继承 BaseTypeHandler 抽象类，Date 类型的 TypeHandler 实现类。代码如下：
+
+```
+// DateOnlyTypeHandler.java
+
+public class DateOnlyTypeHandler extends BaseTypeHandler<Date> {
+
+    @Override
+    public void setNonNullParameter(PreparedStatement ps, int i, Date parameter, JdbcType jdbcType)
+            throws SQLException {
+        // 将 java Date 转换成 sql Date 类型
+        ps.setDate(i, new java.sql.Date(parameter.getTime()));
+    }
+
+    @Override
+    public Date getNullableResult(ResultSet rs, String columnName)
+            throws SQLException {
+        // 获得 sql Date 的值
+        java.sql.Date sqlDate = rs.getDate(columnName);
+        // 将 sql Date 转换成 java Date 类型
+        if (sqlDate != null) {
+            return new Date(sqlDate.getTime());
+        }
+        return null;
+    }
+
+    @Override
+    public Date getNullableResult(ResultSet rs, int columnIndex)
+            throws SQLException {
+        // 获得 sql Date 的值
+        java.sql.Date sqlDate = rs.getDate(columnIndex);
+        // 将 sql Date 转换成 java Date 类型
+        if (sqlDate != null) {
+            return new Date(sqlDate.getTime());
+        }
+        return null;
+    }
+
+    @Override
+    public Date getNullableResult(CallableStatement cs, int columnIndex)
+            throws SQLException {
+        // 获得 sql Date 的值
+        java.sql.Date sqlDate = cs.getDate(columnIndex);
+        // 将 sql Date 转换成 java Date 类型
+        if (sqlDate != null) {
+            return new Date(sqlDate.getTime());
+        }
+        return null;
+    }
+
+}
+```
+
+- `java.util.Date` 和 `java.sql.Date` 的互相转换。
+- 数据库里的时间有多种类型，以 MySQL 举例子，有 `date`、`timestamp`、`datetime` 三种类型。
+
+### 2.2.4 EnumTypeHandler
+
+`org.apache.ibatis.type.EnumTypeHandler` ，继承 BaseTypeHandler 抽象类，Enum 类型的 TypeHandler 实现类。代码如下：
+
+```
+// EnumTypeHandler.java
+
+public class EnumTypeHandler<E extends Enum<E>> extends BaseTypeHandler<E> {
+
+    /**
+     * 枚举类
+     */
+    private final Class<E> type;
+
+    public EnumTypeHandler(Class<E> type) {
+        if (type == null) {
+            throw new IllegalArgumentException("Type argument cannot be null");
+        }
+        this.type = type;
+    }
+
+    @Override
+    public void setNonNullParameter(PreparedStatement ps, int i, E parameter, JdbcType jdbcType) throws SQLException {
+        // 将 Enum 转换成 String 类型
+        if (jdbcType == null) {
+            ps.setString(i, parameter.name());
+        } else {
+            ps.setObject(i, parameter.name(), jdbcType.TYPE_CODE); // see r3589
+        }
+    }
+
+    @Override
+    public E getNullableResult(ResultSet rs, String columnName) throws SQLException {
+        // 获得 String 的值
+        String s = rs.getString(columnName);
+        // 将 String 转换成 Enum 类型
+        return s == null ? null : Enum.valueOf(type, s);
+    }
+
+    @Override
+    public E getNullableResult(ResultSet rs, int columnIndex) throws SQLException {
+        // 获得 String 的值
+        String s = rs.getString(columnIndex);
+        // 将 String 转换成 Enum 类型
+        return s == null ? null : Enum.valueOf(type, s);
+    }
+
+    @Override
+    public E getNullableResult(CallableStatement cs, int columnIndex) throws SQLException {
+        // 获得 String 的值
+        String s = cs.getString(columnIndex);
+        // 将 String 转换成 Enum 类型
+        return s == null ? null : Enum.valueOf(type, s);
+    }
+
+}
+```
+
+- `java.lang.Enum` 和 `java.util.String` 的互相转换。
+- 因为数据库不存在枚举类型，所以讲枚举类型持久化到数据库有两种方式，`Enum.name <=> String` 和 `Enum.ordinal <=> int` 。我们目前看到的 EnumTypeHandler 是前者，下面我们将看到的 EnumOrdinalTypeHandler 是后者。
+
+### 2.2.5 EnumOrdinalTypeHandler
+
+`org.apache.ibatis.type.EnumOrdinalTypeHandler` ，继承 BaseTypeHandler 抽象类，Enum 类型的 TypeHandler 实现类。代码如下：
+
+```
+// EnumOrdinalTypeHandler.java
+
+public class EnumOrdinalTypeHandler<E extends Enum<E>> extends BaseTypeHandler<E> {
+
+    /**
+     * 枚举类
+     */
+    private final Class<E> type;
+    /**
+     * {@link #type} 下所有的枚举
+     *
+     * @see Class#getEnumConstants()
+     */
+    private final E[] enums;
+
+    public EnumOrdinalTypeHandler(Class<E> type) {
+        if (type == null) {
+            throw new IllegalArgumentException("Type argument cannot be null");
+        }
+        this.type = type;
+        this.enums = type.getEnumConstants();
+        if (this.enums == null) {
+            throw new IllegalArgumentException(type.getSimpleName() + " does not represent an enum type.");
+        }
+    }
+
+    @Override
+    public void setNonNullParameter(PreparedStatement ps, int i, E parameter, JdbcType jdbcType) throws SQLException {
+        // 将 Enum 转换成 int 类型
+        ps.setInt(i, parameter.ordinal());
+    }
+
+    @Override
+    public E getNullableResult(ResultSet rs, String columnName) throws SQLException {
+        // 获得 int 的值
+        int i = rs.getInt(columnName);
+        // 将 int 转换成 Enum 类型
+        if (i == 0 && rs.wasNull()) {
+            return null;
+        } else {
+            try {
+                return enums[i];
+            } catch (Exception ex) {
+                throw new IllegalArgumentException("Cannot convert " + i + " to " + type.getSimpleName() + " by ordinal value.", ex);
+            }
+        }
+    }
+
+    @Override
+    public E getNullableResult(ResultSet rs, int columnIndex) throws SQLException {
+        // 获得 int 的值
+        int i = rs.getInt(columnIndex);
+        // 将 int 转换成 Enum 类型
+        if (i == 0 && rs.wasNull()) {
+            return null;
+        } else {
+            try {
+                return enums[i];
+            } catch (Exception ex) {
+                throw new IllegalArgumentException("Cannot convert " + i + " to " + type.getSimpleName() + " by ordinal value.", ex);
+            }
+        }
+    }
+
+    @Override
+    public E getNullableResult(CallableStatement cs, int columnIndex) throws SQLException {
+        // 获得 int 的值
+        int i = cs.getInt(columnIndex);
+        // 将 int 转换成 Enum 类型
+        if (i == 0 && cs.wasNull()) {
+            return null;
+        } else {
+            try {
+                return enums[i];
+            } catch (Exception ex) {
+                throw new IllegalArgumentException("Cannot convert " + i + " to " + type.getSimpleName() + " by ordinal value.", ex);
+            }
+        }
+    }
+
+}
+```
+
+- `java.lang.Enum` 和 `int` 的互相转换。
+
+### 2.2.6 ObjectTypeHandler
+
+`org.apache.ibatis.type.ObjectTypeHandler` ，继承 BaseTypeHandler 抽象类，Object 类型的 TypeHandler 实现类。代码如下：
+
+```
+// ObjectTypeHandler.java
+
+public class ObjectTypeHandler extends BaseTypeHandler<Object> {
+
+    @Override
+    public void setNonNullParameter(PreparedStatement ps, int i, Object parameter, JdbcType jdbcType)
+            throws SQLException {
+        ps.setObject(i, parameter);
+    }
+
+    @Override
+    public Object getNullableResult(ResultSet rs, String columnName)
+            throws SQLException {
+        return rs.getObject(columnName);
+    }
+
+    @Override
+    public Object getNullableResult(ResultSet rs, int columnIndex)
+            throws SQLException {
+        return rs.getObject(columnIndex);
+    }
+
+    @Override
+    public Object getNullableResult(CallableStatement cs, int columnIndex)
+            throws SQLException {
+        return cs.getObject(columnIndex);
+    }
+
+}
+```
+
+### 2.2.7 UnknownTypeHandler
+
+`org.apache.ibatis.type.UnknownTypeHandler` ，继承 BaseTypeHandler 抽象类，**未知的** TypeHandler 实现类。通过获取对应的 TypeHandler ，进行处理。代码如下：
+
+```
+// UnknownTypeHandler.java
+
+public class UnknownTypeHandler extends BaseTypeHandler<Object> {
+
+    /**
+     * ObjectTypeHandler 单例
+     */
+    private static final ObjectTypeHandler OBJECT_TYPE_HANDLER = new ObjectTypeHandler();
+
+    /**
+     * TypeHandler 注册表
+     */
+    private TypeHandlerRegistry typeHandlerRegistry;
+
+    public UnknownTypeHandler(TypeHandlerRegistry typeHandlerRegistry) {
+        this.typeHandlerRegistry = typeHandlerRegistry;
+    }
+
+    @Override
+    public void setNonNullParameter(PreparedStatement ps, int i, Object parameter, JdbcType jdbcType)
+            throws SQLException {
+        // 获得参数对应的处理器
+        TypeHandler handler = resolveTypeHandler(parameter, jdbcType); // <1>
+        // 使用 handler 设置参数
+        handler.setParameter(ps, i, parameter, jdbcType);
+    }
+
+    @Override
+    public Object getNullableResult(ResultSet rs, String columnName)
+            throws SQLException {
+        // 获得参数对应的处理器
+        TypeHandler<?> handler = resolveTypeHandler(rs, columnName); // <2>
+        // 使用 handler 获得值
+        return handler.getResult(rs, columnName);
+    }
+
+    @Override
+    public Object getNullableResult(ResultSet rs, int columnIndex)
+            throws SQLException {
+        // 获得参数对应的处理器
+        TypeHandler<?> handler = resolveTypeHandler(rs.getMetaData(), columnIndex); // <3>
+        // 如果找不到对应的处理器，使用 OBJECT_TYPE_HANDLER
+        if (handler == null || handler instanceof UnknownTypeHandler) {
+            handler = OBJECT_TYPE_HANDLER;
+        }
+        // 使用 handler 获得值
+        return handler.getResult(rs, columnIndex);
+    }
+
+    @Override
+    public Object getNullableResult(CallableStatement cs, int columnIndex)
+            throws SQLException {
+        return cs.getObject(columnIndex);
+    }
+
+    private TypeHandler<? extends Object> resolveTypeHandler(Object parameter, JdbcType jdbcType) { // <1>
+        TypeHandler<? extends Object> handler;
+        // 参数为空，返回 OBJECT_TYPE_HANDLER
+        if (parameter == null) {
+            handler = OBJECT_TYPE_HANDLER;
+        // 参数非空，使用参数类型获得对应的 TypeHandler
+        } else {
+            handler = typeHandlerRegistry.getTypeHandler(parameter.getClass(), jdbcType);
+            // check if handler is null (issue #270)
+            // 获取不到，则使用 OBJECT_TYPE_HANDLER
+            if (handler == null || handler instanceof UnknownTypeHandler) {
+                handler = OBJECT_TYPE_HANDLER;
+            }
+        }
+        return handler;
+    }
+
+    private TypeHandler<?> resolveTypeHandler(ResultSet rs, String column) {
+        try {
+            // 获得 columnIndex
+            Map<String, Integer> columnIndexLookup = new HashMap<>();
+            ResultSetMetaData rsmd = rs.getMetaData(); // 通过 metaData
+            int count = rsmd.getColumnCount();
+            for (int i = 1; i <= count; i++) {
+                String name = rsmd.getColumnName(i);
+                columnIndexLookup.put(name, i);
+            }
+            Integer columnIndex = columnIndexLookup.get(column);
+            TypeHandler<?> handler = null;
+            // 首先，通过 columnIndex 获得 TypeHandler
+            if (columnIndex != null) {
+                handler = resolveTypeHandler(rsmd, columnIndex); // <3>
+            }
+            // 获得不到，使用 OBJECT_TYPE_HANDLER
+            if (handler == null || handler instanceof UnknownTypeHandler) {
+                handler = OBJECT_TYPE_HANDLER;
+            }
+            return handler;
+        } catch (SQLException e) {
+            throw new TypeException("Error determining JDBC type for column " + column + ".  Cause: " + e, e);
+        }
+    }
+
+    private TypeHandler<?> resolveTypeHandler(ResultSetMetaData rsmd, Integer columnIndex) { // <3>
+        TypeHandler<?> handler = null;
+        // 获得 JDBC Type 类型
+        JdbcType jdbcType = safeGetJdbcTypeForColumn(rsmd, columnIndex);
+        // 获得 Java Type 类型
+        Class<?> javaType = safeGetClassForColumn(rsmd, columnIndex);
+        //获得对应的 TypeHandler 对象
+        if (javaType != null && jdbcType != null) {
+            handler = typeHandlerRegistry.getTypeHandler(javaType, jdbcType);
+        } else if (javaType != null) {
+            handler = typeHandlerRegistry.getTypeHandler(javaType);
+        } else if (jdbcType != null) {
+            handler = typeHandlerRegistry.getTypeHandler(jdbcType);
+        }
+        return handler;
+    }
+
+    private JdbcType safeGetJdbcTypeForColumn(ResultSetMetaData rsmd, Integer columnIndex) {
+        try {
+            // 从 ResultSetMetaData 中，获得字段类型
+            // 获得 JDBC Type
+            return JdbcType.forCode(rsmd.getColumnType(columnIndex));
+        } catch (Exception e) {
+            return null;
+        }
+    }
+
+    private Class<?> safeGetClassForColumn(ResultSetMetaData rsmd, Integer columnIndex) {
+        try {
+            // 从 ResultSetMetaData 中，获得字段类型
+            // 获得 Java Type
+            return Resources.classForName(rsmd.getColumnClassName(columnIndex));
+        } catch (Exception e) {
+            return null;
+        }
+    }
+    
+}
+```
+
+- 代码比较简单，胖友自己瞅瞅。
+
+# 3. TypeReference
+
+`org.apache.ibatis.type.TypeReference` ，引用泛型抽象类。目的很简单，就是解析类上定义的泛型。代码如下：
+
+```
+// TypeReference.java
+
+public abstract class TypeReference<T> {
+
+    /**
+     * 泛型
+     */
+    private final Type rawType;
+
+    protected TypeReference() {
+        rawType = getSuperclassTypeParameter(getClass());
+    }
+
+    Type getSuperclassTypeParameter(Class<?> clazz) {
+        // 【1】从父类中获取 <T>
+        Type genericSuperclass = clazz.getGenericSuperclass();
+        if (genericSuperclass instanceof Class) {
+            // 能满足这个条件的，例如 GenericTypeSupportedInHierarchiesTestCase.CustomStringTypeHandler 这个类
+            // try to climb up the hierarchy until meet something useful
+            if (TypeReference.class != genericSuperclass) { // 排除 TypeReference 类
+                return getSuperclassTypeParameter(clazz.getSuperclass());
+            }
+
+            throw new TypeException("'" + getClass() + "' extends TypeReference but misses the type parameter. "
+                    + "Remove the extension or add a type parameter to it.");
+        }
+
+        // 【2】获取 <T>
+        Type rawType = ((ParameterizedType) genericSuperclass).getActualTypeArguments()[0];
+        // TODO remove this when Reflector is fixed to return Types
+        // 必须是泛型，才获取 <T>
+        if (rawType instanceof ParameterizedType) {
+            rawType = ((ParameterizedType) rawType).getRawType();
+        }
+
+        return rawType;
+    }
+
+    public final Type getRawType() {
+        return rawType;
+    }
+
+    @Override
+    public String toString() {
+        return rawType.toString();
+    }
+
+}
+```
+
+- 举个例子，[「2.2.1 IntegerTypeHandler」](https://svip.iocoder.cn/MyBatis/type-package/#) 解析后的结果 `rawType` 为 Integer 。
+
+- `【1】` 处，从父类中获取 `<T>` 。举个例子，代码如下：
+
+  ```
+  // GenericTypeSupportedInHierarchiesTestCase.java 的内部静态类
+  
+  public static final class CustomStringTypeHandler extends StringTypeHandler {
+  
+      /**
+       * Defined as reported in #581
+       */
+      @Override
+      public void setNonNullParameter(PreparedStatement ps, int i, String parameter, JdbcType jdbcType) throws SQLException {
+          // do something
+          super.setNonNullParameter(ps, i, parameter, jdbcType);
+      }
+  
+  }
+  ```
+
+  - 因为 CustomStringTypeHandler 自身是没有泛型的，需要从父类 StringTypeHandler 中获取。并且，获取的结果会是 `rawType` 为 String 。
+
+- `【2】` 处，从当前类获取 `<T>` 。
+
+# 4. 注解
+
+`type` 包中，也定义了三个注解，我们逐个来看看。
+
+## 4.1 @MappedTypes
+
+`org.apache.ibatis.type.@MappedTypes` ，匹配的 Java Type 类型的注解。代码如下：
+
+```
+// MappedTypes.java
+
+@Documented
+@Retention(RetentionPolicy.RUNTIME)
+@Target(ElementType.TYPE) // 注册到类
+public @interface MappedTypes {
+
+    /**
+     * @return 匹配的 Java Type 类型的数组
+     */
+    Class<?>[] value();
+
+}
+```
+
+## 4.2 @MappedJdbcTypes
+
+`org.apache.ibatis.type.@MappedJdbcTypes` ，匹配的 JDBC Type 类型的注解。代码如下：
+
+```
+// MappedJdbcTypes.java
+
+@Documented
+@Retention(RetentionPolicy.RUNTIME)
+@Target(ElementType.TYPE) // 注册到类
+public @interface MappedJdbcTypes {
+
+    /**
+     * @return 匹配的 JDBC Type 类型的注解
+     */
+    JdbcType[] value();
+
+    /**
+     * @return 是否包含 {@link java.sql.JDBCType#NULL}
+     */
+    boolean includeNullJdbcType() default false;
+
+}
+```
+
+## 4.3 Alias
+
+`org.apache.ibatis.type.@Alias` ，别名的注解。代码如下：
+
+```
+// Alias.java
+
+@Documented
+@Retention(RetentionPolicy.RUNTIME)
+@Target(ElementType.TYPE)
+public @interface Alias {
+
+    /**
+     * @return 别名
+     */
+    String value();
+
+}
+```
+
+# 5. JdbcType
+
+`org.apache.ibatis.type.JdbcType` ，Jdbc Type 枚举。代码如下：
+
+```
+// JdbcType.java
+
+public enum JdbcType {
+
+    /*
+     * This is added to enable basic support for the
+     * ARRAY data type - but a custom type handler is still required
+     */
+    ARRAY(Types.ARRAY),
+    BIT(Types.BIT),
+    TINYINT(Types.TINYINT),
+    SMALLINT(Types.SMALLINT),
+    INTEGER(Types.INTEGER),
+    BIGINT(Types.BIGINT),
+    FLOAT(Types.FLOAT),
+    REAL(Types.REAL),
+    DOUBLE(Types.DOUBLE),
+    NUMERIC(Types.NUMERIC),
+    DECIMAL(Types.DECIMAL),
+    CHAR(Types.CHAR),
+    VARCHAR(Types.VARCHAR),
+    LONGVARCHAR(Types.LONGVARCHAR),
+    DATE(Types.DATE),
+    TIME(Types.TIME),
+    TIMESTAMP(Types.TIMESTAMP),
+    BINARY(Types.BINARY),
+    VARBINARY(Types.VARBINARY),
+    LONGVARBINARY(Types.LONGVARBINARY),
+    NULL(Types.NULL),
+    OTHER(Types.OTHER),
+    BLOB(Types.BLOB),
+    CLOB(Types.CLOB),
+    BOOLEAN(Types.BOOLEAN),
+    CURSOR(-10), // Oracle
+    UNDEFINED(Integer.MIN_VALUE + 1000),
+    NVARCHAR(Types.NVARCHAR), // JDK6
+    NCHAR(Types.NCHAR), // JDK6
+    NCLOB(Types.NCLOB), // JDK6
+    STRUCT(Types.STRUCT),
+    JAVA_OBJECT(Types.JAVA_OBJECT),
+    DISTINCT(Types.DISTINCT),
+    REF(Types.REF),
+    DATALINK(Types.DATALINK),
+    ROWID(Types.ROWID), // JDK6
+    LONGNVARCHAR(Types.LONGNVARCHAR), // JDK6
+    SQLXML(Types.SQLXML), // JDK6
+    DATETIMEOFFSET(-155); // SQL Server 2008
+
+    /**
+     * 类型编号。嘿嘿，此处代码不规范
+     */
+    public final int TYPE_CODE;
+
+    /**
+     * 代码编号和 {@link JdbcType} 的映射
+     */
+    private static Map<Integer, JdbcType> codeLookup = new HashMap<>();
+
+    static {
+        // 初始化 codeLookup
+        for (JdbcType type : JdbcType.values()) {
+            codeLookup.put(type.TYPE_CODE, type);
+        }
+    }
+
+    JdbcType(int code) {
+        this.TYPE_CODE = code;
+    }
+
+    public static JdbcType forCode(int code) {
+        return codeLookup.get(code);
+    }
+
+}
+```
+
+# 6. TypeHandlerRegistry
+
+`org.apache.ibatis.type.TypeHandlerRegistry` ，TypeHandler 注册表，相当于管理 TypeHandler 的容器，从其中能获取到对应的 TypeHandler 。
+
+## 6.1 构造方法
+
+```
+// TypeHandlerRegistry.java
+
+/**
+ * 空 TypeHandler 集合的标识，即使 {@link #TYPE_HANDLER_MAP} 中，某个 KEY1 对应的 Map<JdbcType, TypeHandler<?>> 为空。
+ *
+ * @see #getJdbcHandlerMap(Type)
+ */
+private static final Map<JdbcType, TypeHandler<?>> NULL_TYPE_HANDLER_MAP = Collections.emptyMap();
+
+/**
+ * JDBC Type 和 {@link TypeHandler} 的映射
+ *
+ * {@link #register(JdbcType, TypeHandler)}
+ */
+private final Map<JdbcType, TypeHandler<?>> JDBC_TYPE_HANDLER_MAP = new EnumMap<>(JdbcType.class);
+/**
+ * {@link TypeHandler} 的映射
+ *
+ * KEY1：JDBC Type
+ * KEY2：Java Type
+ * VALUE：{@link TypeHandler} 对象
+ */
+private final Map<Type, Map<JdbcType, TypeHandler<?>>> TYPE_HANDLER_MAP = new ConcurrentHashMap<>();
+/**
+ * 所有 TypeHandler 的“集合”
+ *
+ * KEY：{@link TypeHandler#getClass()}
+ * VALUE：{@link TypeHandler} 对象
+ */
+private final Map<Class<?>, TypeHandler<?>> ALL_TYPE_HANDLERS_MAP = new HashMap<>();
+
+/**
+ * {@link UnknownTypeHandler} 对象
+ */
+private final TypeHandler<Object> UNKNOWN_TYPE_HANDLER = new UnknownTypeHandler(this);
+/**
+ * 默认的枚举类型的 TypeHandler 对象
+ */
+private Class<? extends TypeHandler> defaultEnumTypeHandler = EnumTypeHandler.class;
+
+public TypeHandlerRegistry() {
+    // ... 省略其它类型的注册
+
+    // <1>
+    register(Date.class, new DateTypeHandler());
+    register(Date.class, JdbcType.DATE, new DateOnlyTypeHandler());
+    register(Date.class, JdbcType.TIME, new TimeOnlyTypeHandler());
+    // <2>
+    register(JdbcType.TIMESTAMP, new DateTypeHandler());
+    register(JdbcType.DATE, new DateOnlyTypeHandler());
+    register(JdbcType.TIME, new TimeOnlyTypeHandler());
+
+    // ... 省略其它类型的注册
+}
+```
+
+- ```
+  TYPE_HANDLER_MAP
+  ```
+
+   
+
+  属性，TypeHandler 的映射。
+
+  - 一个 Java Type 可以对应多个 JDBC Type ，也就是多个 TypeHandler ，所以 Map 的第一层的值是 `Map<JdbcType, TypeHandler<?>` 。在 `<1>` 处，我们可以看到，Date 对应了多个 JDBC 的 TypeHandler 的注册。
+  - 当一个 Java Type 不存在对应的 JDBC Type 时，就使用 `NULL_TYPE_HANDLER_MAP` **静态**属性，添加到 `TYPE_HANDLER_MAP` 中进行占位。
+
+- ```
+  JDBC_TYPE_HANDLER_MAP
+  ```
+
+   
+
+  属性，JDBC Type 和 TypeHandler 的映射。
+
+  - 一个 JDBC Type 只对应一个 Java Type ，也就是一个 TypeHandler ，不同于 `TYPE_HANDLER_MAP` 属性。在 `<2>` 处，我们可以看到，我们可以看到，三个时间类型的 JdbcType 注册到 `JDBC_TYPE_HANDLER_MAP` 中。
+  - 那么可能会有胖友问，`JDBC_TYPE_HANDLER_MAP` 是**一一**映射，简单就可以获得 JDBC Type 对应的 TypeHandler ，而 `TYPE_HANDLER_MAP` 是**一对多**映射，一个 JavaType 怎么获取到对应的 TypeHandler 呢？继续往下看，答案在 `#getTypeHandler(Type type, JdbcType jdbcType)` 方法。
+
+- `ALL_TYPE_HANDLERS_MAP` 属性，所有 TypeHandler 的“集合” 。
+
+- `UNKNOWN_TYPE_HANDLER` 属性，UnknownTypeHandler 对象，用于 Object 类型的注册。
+
+- `defaultEnumTypeHandler` 属性，默认的枚举类型的 TypeHandler 对象。
+
+- 在构造方法中，有默认的 Java Type 和 JDBC Type 对 TypeHandler 的注册，因为有丢丢多，所以被艿艿省略了。
+
+- 另外，这里的变量命名是不符合 Java 命名规范，不要学习。
+
+## 6.2 getInstance
+
+`#getInstance(Class<?> javaTypeClass, Class<?> typeHandlerClass)` 方法，创建 TypeHandler 对象。代码如下：
+
+```
+// TypeHandlerRegistry.java
+
+public <T> TypeHandler<T> getInstance(Class<?> javaTypeClass, Class<?> typeHandlerClass) {
+    // 获得 Class 类型的构造方法
+    if (javaTypeClass != null) {
+        try {
+            Constructor<?> c = typeHandlerClass.getConstructor(Class.class);
+            return (TypeHandler<T>) c.newInstance(javaTypeClass); // 符合这个条件的，例如 EnumTypeHandler
+        } catch (NoSuchMethodException ignored) {
+            // ignored 忽略该异常，继续向下
+        } catch (Exception e) {
+            throw new TypeException("Failed invoking constructor for handler " + typeHandlerClass, e);
+        }
+    }
+    // <2> 获得空参的构造方法
+    try {
+        Constructor<?> c = typeHandlerClass.getConstructor();
+        return (TypeHandler<T>) c.newInstance(); // 符合这个条件的，例如 IntegerTypeHandler
+    } catch (Exception e) {
+        throw new TypeException("Unable to find a usable constructor for " + typeHandlerClass, e);
+    }
+}
+```
+
+- `<1>` 处，获得 Class 类型的构造方法，适合 [「2.2.4 EnumTypeHandler」](https://svip.iocoder.cn/MyBatis/type-package/#) 的情况。
+- `<2>` 处，获得空参的构造方法，适合 [「2.2.1 IntegerTypeHandler」](https://svip.iocoder.cn/MyBatis/type-package/#) 的情况。
+
+## 6.3 register
+
+`#register(...)` 方法，注册 TypeHandler 。TypeHandlerRegistry 中有大量该方法的重载实现，大体整理如下：
+
+> FROM 徐郡明 [《MyBatis 技术内幕》](https://item.jd.com/12125531.html)
+>
+> [![register 方法](10-mybatis-类型模块.assets/04.png)](http://static.iocoder.cn/images/MyBatis/2020_01_25/04.png)register 方法
+
+除了 ⑤ 以外，所有方法最终都会调用 ④ ，即 `#register(Type javaType, JdbcType jdbcType, TypeHandler<?> handler)` 方法，代码如下：
+
+```
+// TypeHandlerRegistry.java
+
+private void register(Type javaType, JdbcType jdbcType, TypeHandler<?> handler) {
+    // <1> 添加 handler 到 TYPE_HANDLER_MAP 中
+    if (javaType != null) {
+        // 获得 Java Type 对应的 map
+        Map<JdbcType, TypeHandler<?>> map = TYPE_HANDLER_MAP.get(javaType);
+        if (map == null || map == NULL_TYPE_HANDLER_MAP) { // 如果不存在，则进行创建
+            map = new HashMap<>();
+            TYPE_HANDLER_MAP.put(javaType, map);
+        }
+        // 添加到 handler 中 map 中
+        map.put(jdbcType, handler);
+    }
+    // <2> 添加 handler 到 ALL_TYPE_HANDLERS_MAP 中
+    ALL_TYPE_HANDLERS_MAP.put(handler.getClass(), handler);
+}
+```
+
+- `<1>` 处，添加 `handler` 到 `TYPE_HANDLER_MAP` 中。
+- `<2>` 处，添加 `handler` 到 `ALL_TYPE_HANDLERS_MAP` 中。
+- 这个方法还是比较简单的，我们看看其他调用的方法。
+
+① `#register(String packageName)` 方法，扫描指定包下的所有 TypeHandler 类，并发起注册。代码如下：
+
+```
+// TypeHandlerRegistry.java
+    
+public void register(String packageName) {
+    // 扫描指定包下的所有 TypeHandler 类
+    ResolverUtil<Class<?>> resolverUtil = new ResolverUtil<>();
+    resolverUtil.find(new ResolverUtil.IsA(TypeHandler.class), packageName);
+    Set<Class<? extends Class<?>>> handlerSet = resolverUtil.getClasses();
+    // 遍历 TypeHandler 数组，发起注册
+    for (Class<?> type : handlerSet) {
+        //Ignore inner classes and interfaces (including package-info.java) and abstract classes
+        // 排除匿名类、接口、抽象类
+        if (!type.isAnonymousClass() && !type.isInterface() && !Modifier.isAbstract(type.getModifiers())) {
+            register(type);
+        }
+    }
+}
+```
+
+- 在方法，会调用 ⑥ `#register(Class<?> typeHandlerClass)` 方法，注册指定 TypeHandler **类**。代码如下：
+
+  ```
+  // TypeHandlerRegistry.java
+  
+  public void register(Class<?> typeHandlerClass) {
+      boolean mappedTypeFound = false;
+      // <3> 获得 @MappedTypes 注解
+      MappedTypes mappedTypes = typeHandlerClass.getAnnotation(MappedTypes.class);
+      if (mappedTypes != null) {
+          // 遍历注解的 Java Type 数组，逐个进行注册
+          for (Class<?> javaTypeClass : mappedTypes.value()) {
+              register(javaTypeClass, typeHandlerClass);
+              mappedTypeFound = true;
+          }
+      }
+      // <4> 未使用 @MappedTypes 注解，则直接注册
+      if (!mappedTypeFound) {
+          register(getInstance(null, typeHandlerClass)); // 创建 TypeHandler 对象
+      }
+  }
+  ```
+
+  - 分成 `<3>` `<4>` 两种情况。
+
+  - `<3>` 处，**基于** `@MappedTypes` 注解，调用 `#register(Class<?> javaTypeClass, Class<?> typeHandlerClass)` 方法，注册指定 Java Type 的指定 TypeHandler **类**。代码如下：
+
+    ```
+    // TypeHandlerRegistry.java
+    
+    public void register(Class<?> javaTypeClass, Class<?> typeHandlerClass) {
+        register(javaTypeClass, getInstance(javaTypeClass, typeHandlerClass)); // 创建 TypeHandler 对象
+    }
+    ```
+
+    - 调用 ③ `#register(Class<T> javaType, TypeHandler<? extends T> typeHandler)` 方法，注册指定 Java Type 的指定 TypeHandler **对象**。代码如下：
+
+      ```
+      // TypeHandlerRegistry.java
+      
+      private <T> void register(Type javaType, TypeHandler<? extends T> typeHandler) {
+          // 获得 MappedJdbcTypes 注解
+          MappedJdbcTypes mappedJdbcTypes = typeHandler.getClass().getAnnotation(MappedJdbcTypes.class);
+          if (mappedJdbcTypes != null) {
+              // 遍历 MappedJdbcTypes 注册的 JDBC Type 进行注册
+              for (JdbcType handledJdbcType : mappedJdbcTypes.value()) {
+                  register(javaType, handledJdbcType, typeHandler);
+              }
+              if (mappedJdbcTypes.includeNullJdbcType()) {
+                  // <5>
+                  register(javaType, null, typeHandler); // jdbcType = null
+              }
+          } else {
+              // <5>
+              register(javaType, null, typeHandler); // jdbcType = null
+          }
+      }
+      ```
+
+      - **有** `@MappedJdbcTypes` 注解的 ④ `#register(Type javaType, JdbcType jdbcType, TypeHandler<?> handler)` 方法，发起**最终**注册。
+      - 对于 `<5>` 处，发起注册时，`jdbcType` 参数为 `null` ，这是为啥？😈 下文详细解析。
+
+  - `<4>` 处，调用 ② `#register(TypeHandler<T> typeHandler)` 方法，**未使用** `@MappedTypes` 注解，调用 `#register(TypeHandler<T> typeHandler)` 方法，注册 TypeHandler 对象。代码如下：
+
+    ```
+    // TypeHandlerRegistry.java
+    
+    public <T> void register(TypeHandler<T> typeHandler) {
+        boolean mappedTypeFound = false;
+        // <5> 获得 @MappedTypes 注解
+        MappedTypes mappedTypes = typeHandler.getClass().getAnnotation(MappedTypes.class);
+        // 优先，使用 @MappedTypes 注解的 Java Type 进行注册
+        if (mappedTypes != null) {
+            for (Class<?> handledType : mappedTypes.value()) {
+                register(handledType, typeHandler);
+                mappedTypeFound = true;
+            }
+        }
+        // @since 3.1.0 - try to auto-discover the mapped type
+        // <6> 其次，当 typeHandler 为 TypeReference 子类时，进行注册
+        if (!mappedTypeFound && typeHandler instanceof TypeReference) {
+            try {
+                TypeReference<T> typeReference = (TypeReference<T>) typeHandler;
+                register(typeReference.getRawType(), typeHandler); // Java Type 为 <T> 泛型
+                mappedTypeFound = true;
+            } catch (Throwable t) {
+                // maybe users define the TypeReference with a different type and are not assignable, so just ignore it
+            }
+        }
+        // <7> 最差，使用 Java Type 为 null 进行注册
+        if (!mappedTypeFound) {
+            register((Class<T>) null, typeHandler);
+        }
+    }
+    ```
+
+    - 分成三种情况，最终都是调用 `#register(Type javaType, TypeHandler<? extends T> typeHandler)` 方法，进行注册，也就是跳到 ③ 。
+    - `<5>` 处，优先，有符合的 `@MappedTypes` 注解时，使用 `@MappedTypes` 注解的 Java Type 进行注册。
+    - `<6>` 处，其次，当 `typeHandler` 为 TypeReference 子类时，使用 `<T>` 作为 Java Type 进行注册。
+    - `<7>` 处，最差，使用 `null` 作为 Java Type 进行注册。但是，这种情况下，只会将 `typeHandler` 添加到 `ALL_TYPE_HANDLERS_MAP` 中。因为，实际上没有 Java Type 。
+
+因为重载的方法有点多，理解起来可能比较绕，胖友可能会比较闷逼。哈哈哈，实际在自己写的过程中，也有点懵逼。那怎么办？大体理解就好，另外 `@MappedTypes` 和 `@MappedJdbcTypes` 这两个注解基本不会用到，所以也可以先“忽略”。
+
+另外，`#register(...)` 方法，还有其它重载方法，胖友可以自己翻下。
+
+------
+
+⑤ `#register(JdbcType jdbcType, TypeHandler<?> handler)` 方法，注册 `handler` 到 `JDBC_TYPE_HANDLER_MAP` 中。代码如下：
+
+```
+// TypeHandlerRegistry.java
+
+public void register(JdbcType jdbcType, TypeHandler<?> handler) {
+    JDBC_TYPE_HANDLER_MAP.put(jdbcType, handler);
+}
+```
+
+- 和上述的 `#register(...)` 方法是不同的。
+
+## 6.4 getTypeHandler
+
+`#getTypeHandler(...)` 方法，获得 TypeHandler 。TypeHandlerRegistry 有大量该方法的重载实现，大体整体如下：
+
+> FROM 徐郡明 [《MyBatis 技术内幕》](https://item.jd.com/12125531.html)
+>
+> [![getTypeHandler 方法](10-mybatis-类型模块.assets/05.png)](http://static.iocoder.cn/images/MyBatis/2020_01_25/05.png)getTypeHandler 方法
+
+从图中，我们可以看到，最终会调用 ① 处的 `#getTypeHandler(Type type, JdbcType jdbcType)` 方法。当然，我们先来看看三种调用的情况：
+
+- 调用情况一：`#getTypeHandler(Class<T> type)` 方法，代码如下：
+
+  ```
+  // TypeHandlerRegistry.java
+  
+  public <T> TypeHandler<T> getTypeHandler(Class<T> type) {
+      return getTypeHandler((Type) type, null);
+  }
+  ```
+
+  - `jdbcType` 为 `null` 。
+
+- 调用情况二：`#getTypeHandler(Class<T> type, JdbcType jdbcType)` 方法，代码如下：
+
+  ```
+  // TypeHandlerRegistry.java
+  
+  public <T> TypeHandler<T> getTypeHandler(Class<T> type, JdbcType jdbcType) {
+      return getTypeHandler((Type) type, jdbcType);
+  }
+  ```
+
+  - 将 `type` 转换成 Type 类型。
+
+- 调用情况三：`#getTypeHandler(TypeReference<T> javaTypeReference, ...)` 方法，代码如下：
+
+  ```
+  // TypeHandlerRegistry.java
+  
+  public <T> TypeHandler<T> getTypeHandler(TypeReference<T> javaTypeReference) {
+      return getTypeHandler(javaTypeReference, null);
+  }
+  
+  public <T> TypeHandler<T> getTypeHandler(TypeReference<T> javaTypeReference, JdbcType jdbcType) {
+      return getTypeHandler(javaTypeReference.getRawType(), jdbcType);
+  }
+  ```
+
+  - 使用 `<T>` 泛型作为 `type` 。
+
+下面，正式来看看 ① 处的 `#getTypeHandler(Type type, JdbcType jdbcType)` 方法。代码如下：
+
+```
+// TypeHandlerRegistry.java
+
+private <T> TypeHandler<T> getTypeHandler(Type type, JdbcType jdbcType) {
+    // 忽略 ParamMap 的情况
+    if (ParamMap.class.equals(type)) {
+        return null;
+    }
+    // <1> 获得 Java Type 对应的 TypeHandler 集合
+    Map<JdbcType, TypeHandler<?>> jdbcHandlerMap = getJdbcHandlerMap(type);
+    TypeHandler<?> handler = null;
+    if (jdbcHandlerMap != null) {
+        // <2.1> 优先，使用 jdbcType 获取对应的 TypeHandler
+        handler = jdbcHandlerMap.get(jdbcType);
+        // <2.2> 其次，使用 null 获取对应的 TypeHandler ，可以认为是默认的 TypeHandler
+        if (handler == null) {
+            handler = jdbcHandlerMap.get(null);
+        }
+        // <2.3> 最差，从 TypeHandler 集合中选择一个唯一的 TypeHandler
+        if (handler == null) {
+            // #591
+            handler = pickSoleHandler(jdbcHandlerMap);
+        }
+    }
+    // type drives generics here
+    return (TypeHandler<T>) handler;
+}
+```
+
+- `<1>` 处，调用 `#getJdbcHandlerMap(Type type)` 方法，获得 Java Type 对应的 TypeHandler 集合。代码如下：
+
+  ```
+  // TypeHandlerRegistry.java
+  
+  private Map<JdbcType, TypeHandler<?>> getJdbcHandlerMap(Type type) {
+      // <1.1> 获得 Java Type 对应的 TypeHandler 集合
+      Map<JdbcType, TypeHandler<?>> jdbcHandlerMap = TYPE_HANDLER_MAP.get(type);
+      // <1.2> 如果为 NULL_TYPE_HANDLER_MAP ，意味着为空，直接返回
+      if (NULL_TYPE_HANDLER_MAP.equals(jdbcHandlerMap)) {
+          return null;
+      }
+      // <1.3> 如果找不到
+      if (jdbcHandlerMap == null && type instanceof Class) {
+          Class<?> clazz = (Class<?>) type;
+          // 枚举类型
+          if (clazz.isEnum()) {
+              // 获得父类对应的 TypeHandler 集合
+              jdbcHandlerMap = getJdbcHandlerMapForEnumInterfaces(clazz, clazz);
+              // 如果找不到
+              if (jdbcHandlerMap == null) {
+                  // 注册 defaultEnumTypeHandler ，并使用它
+                  register(clazz, getInstance(clazz, defaultEnumTypeHandler));
+                  // 返回结果
+                  return TYPE_HANDLER_MAP.get(clazz);
+              }
+          // 非枚举类型
+          } else {
+              // 获得父类对应的 TypeHandler 集合
+              jdbcHandlerMap = getJdbcHandlerMapForSuperclass(clazz);
+          }
+      }
+      // <1.4> 如果结果为空，设置为 NULL_TYPE_HANDLER_MAP ，提升查找速度，避免二次查找
+      TYPE_HANDLER_MAP.put(type, jdbcHandlerMap == null ? NULL_TYPE_HANDLER_MAP : jdbcHandlerMap);
+      // 返回结果
+      return jdbcHandlerMap;
+  }
+  ```
+
+  - `<1.1>` 处，获得 Java Type 对应的 TypeHandler 集合。
+
+  - `<1.2>` 处，如果为 `NULL_TYPE_HANDLER_MAP` ，意味着为空，直接返回。原因可见 `<1.4>` 处。
+
+  - `<1.3>` 处，找不到，则根据 `type` 是否为枚举类型，进行不同处理。
+
+    - 【枚举】
+
+    - 先调用 `#getJdbcHandlerMapForEnumInterfaces(Class<?> clazz, Class<?> enumClazz)` 方法， 获得父类对应的 TypeHandler 集合。代码如下：
+
+      ```
+      // TypeHandlerRegistry.java
+      
+      private Map<JdbcType, TypeHandler<?>> getJdbcHandlerMapForEnumInterfaces(Class<?> clazz, Class<?> enumClazz) {
+          // 遍历枚举类的所有接口
+          for (Class<?> iface : clazz.getInterfaces()) {
+              // 获得该接口对应的 jdbcHandlerMap 集合
+              Map<JdbcType, TypeHandler<?>> jdbcHandlerMap = TYPE_HANDLER_MAP.get(iface);
+              // 为空，递归 getJdbcHandlerMapForEnumInterfaces 方法，继续从父类对应的 TypeHandler 集合
+              if (jdbcHandlerMap == null) {
+                  jdbcHandlerMap = getJdbcHandlerMapForEnumInterfaces(iface, enumClazz);
+              }
+              // 如果找到，则从 jdbcHandlerMap 初始化中 newMap 中，并进行返回
+              if (jdbcHandlerMap != null) {
+                  // Found a type handler regsiterd to a super interface
+                  HashMap<JdbcType, TypeHandler<?>> newMap = new HashMap<>();
+                  for (Entry<JdbcType, TypeHandler<?>> entry : jdbcHandlerMap.entrySet()) {
+                      // Create a type handler instance with enum type as a constructor arg
+                      newMap.put(entry.getKey(), getInstance(enumClazz, entry.getValue().getClass()));
+                  }
+                  return newMap;
+              }
+          }
+          // 找不到，则返回 null
+          return null;
+      }
+      ```
+
+      - 代码比较简单，看下代码注释。
+
+    - 找不到，则注册 `defaultEnumTypeHandler` ，并使用它。
+
+    - 【非枚举】
+
+    - 调用 `#getJdbcHandlerMapForSuperclass(Class<?> clazz)` 方法，获得父类对应的 TypeHandler 集合。代码如下：
+
+      ```
+      // TypeHandlerRegistry.java
+      
+      private Map<JdbcType, TypeHandler<?>> getJdbcHandlerMapForSuperclass(Class<?> clazz) {
+          // 获得父类
+          Class<?> superclass = clazz.getSuperclass();
+          // 不存在非 Object 的父类，返回 null
+          if (superclass == null || Object.class.equals(superclass)) {
+              return null;
+          }
+          // 获得父类对应的 TypeHandler 集合
+          Map<JdbcType, TypeHandler<?>> jdbcHandlerMap = TYPE_HANDLER_MAP.get(superclass);
+          // 找到，则直接返回
+          if (jdbcHandlerMap != null) {
+              return jdbcHandlerMap;
+          // 找不到，则递归 getJdbcHandlerMapForSuperclass 方法，继续获得父类对应的 TypeHandler 集合
+          } else {
+              return getJdbcHandlerMapForSuperclass(superclass);
+          }
+      }
+      ```
+
+      - 代码比较简单，看下代码注释。
+
+  - `<1.4>` 处，如果结果为空，设置为 `NULL_TYPE_HANDLER_MAP` ，提升查找速度，避免二次查找。
+
+- `<2.1>` 处，优先，使用 `jdbcType` 获取对应的 TypeHandler 。
+
+- `<2.2>` 处，其次，使用 `null` 获取对应的 TypeHandler ，可以认为是**默认**的 TypeHandler 。这里是解决一个 Java Type 可能对应多个 TypeHandler 的**方式之一**。
+
+- `<2.3>` 处，最差，调用 `#pickSoleHandler(Map<JdbcType, TypeHandler<?>> jdbcHandlerMap)` 方法，从 TypeHandler 集合中选择一个**唯一**的 TypeHandler 。代码如下：
+
+  ```
+  // TypeHandlerRegistry.java
+  
+  private TypeHandler<?> pickSoleHandler(Map<JdbcType, TypeHandler<?>> jdbcHandlerMap) {
+      TypeHandler<?> soleHandler = null;
+      for (TypeHandler<?> handler : jdbcHandlerMap.values()) {
+          // 选择一个
+          if (soleHandler == null) {
+              soleHandler = handler;
+          // 如果还有，并且不同类，那么不好选择，所以返回 null
+          } else if (!handler.getClass().equals(soleHandler.getClass())) {
+              // More than one type handlers registered.
+              return null;
+          }
+      }
+      return soleHandler;
+  }
+  ```
+
+  - 这段代码看起来比较绕，其实目的很清晰，就是选择**第一个**，并且不能有其它的**不同类**的处理器。
+  - 这里是解决一个 Java Type 可能对应多个 TypeHandler 的**方式之一**。
+
+- 通过 `<2.1>` + `<2.2>` + `<2.3>` 三处，解决 Java Type 对应的 TypeHandler 集合。
+
+------
+
+`#getTypeHandler(JdbcType jdbcType)` 方法，获得 `jdbcType` 对应的 TypeHandler 。代码如下：
+
+```
+// TypeHandlerRegistry.java
+
+public TypeHandler<?> getTypeHandler(JdbcType jdbcType) {
+    return JDBC_TYPE_HANDLER_MAP.get(jdbcType);
+}
+```
+
+# 7. TypeAliasRegistry
+
+`org.apache.ibatis.type.TypeAliasRegistry` ，类型与别名的注册表。通过别名，我们在 Mapper XML 中的 `resultType` 和 `parameterType` 属性，直接使用，而不用写全类名。
+
+## 7.1 构造方法
+
+```
+// TypeAliasRegistry.java
+
+/**
+ * 类型与别名的映射。
+ */
+private final Map<String, Class<?>> TYPE_ALIASES = new HashMap<>();
+
+/**
+ * 初始化默认的类型与别名
+ *
+ * 另外，在 {@link org.apache.ibatis.session.Configuration} 构造方法中，也有默认的注册
+ */
+public TypeAliasRegistry() {
+    registerAlias("string", String.class);
+
+    registerAlias("byte", Byte.class);
+    registerAlias("long", Long.class);
+    registerAlias("short", Short.class);
+    registerAlias("int", Integer.class);
+    registerAlias("integer", Integer.class);
+    registerAlias("double", Double.class);
+    registerAlias("float", Float.class);
+    registerAlias("boolean", Boolean.class);
+
+    // ... 省略其他注册调用
+}
+```
+
+- `TYPE_ALIASES` 属性，类型与别名的映射。
+- 构造方法，初始化默认的类型与别名。
+- 另外，在 `org.apache.ibatis.session.Configuration` 构造方法中，也有默认的注册类型与别名。
+
+## 7.2 registerAlias
+
+`#registerAlias(Class<?> type)` 方法，注册指定类。代码如下：
+
+```
+// TypeAliasRegistry.java
+
+public void registerAlias(Class<?> type) {
+    // <1> 默认为，简单类名
+    String alias = type.getSimpleName();
+    // <2> 如果有注解，使用注册上的名字
+    Alias aliasAnnotation = type.getAnnotation(Alias.class);
+    if (aliasAnnotation != null) {
+        alias = aliasAnnotation.value();
+    }
+    // <3> 注册类型与别名的注册表
+    registerAlias(alias, type);
+}
+```
+
+- 别名的规则
+
+  - `<1>` ，默认为，简单类名。
+  - `<2>` ，可通过 `@Alias` 注解的别名。
+
+- `<3>` ，调用 `#registerAlias(String alias, Class<?> value)` 方法，注册类型与别名的注册表。代码如下：
+
+  ```
+  // TypeAliasRegistry.java
+  
+  public void registerAlias(String alias, Class<?> value) {
+      if (alias == null) {
+          throw new TypeException("The parameter alias cannot be null");
+      }
+      // issue #748
+      // <1> 转换成小写
+      String key = alias.toLowerCase(Locale.ENGLISH);
+      if (TYPE_ALIASES.containsKey(key) && TYPE_ALIASES.get(key) != null && !TYPE_ALIASES.get(key).equals(value)) { // <2> 冲突，抛出 TypeException 异常
+          throw new TypeException("The alias '" + alias + "' is already mapped to the value '" + TYPE_ALIASES.get(key).getName() + "'.");
+      }
+      // <3>
+      TYPE_ALIASES.put(key, value);
+  }
+  ```
+
+```
+* `<1>` 处，将别名转换成**小写**。这样的话，无论我们在 Mapper XML 中，写 `String` 还是 `string` 甚至是 `STRING` ，都是对应的 String 类型。 * `<2>` 处，如果已经注册，并且类型不一致，说明有冲突，抛出 TypeException 异常。 * `<3>` 处，添加到 `TYPE_ALIASES` 中。 * 另外，`#registerAlias(String alias, String value)` 方法，也会调用该方法。代码如下： // TypeAliasRegistry.javapublic void registerAlias(String alias, String value) {    try {        registerAlias(alias,                Resources.classForName(value) // 通过类名的字符串，获得对应的类。        );    } catch (ClassNotFoundException e) {        throw new TypeException("Error registering type alias " + alias + " for " + value + ". Cause: " + e, e);    }} 
+```
+
+## 7.3 registerAliases
+
+`#registerAliases(String packageName, ...)` 方法，扫描指定包下的所有类，并进行注册。代码如下：
+
+```
+// TypeAliasRegistry.java
+
+/**
+ * 注册指定包下的别名与类的映射
+ *
+ * @param packageName 指定包
+ */
+public void registerAliases(String packageName) {
+    registerAliases(packageName, Object.class);
+}
+
+/**
+ * 注册指定包下的别名与类的映射。另外，要求类必须是 {@param superType} 类型（包括子类）。
+ *
+ * @param packageName 指定包
+ * @param superType 指定父类
+ */
+public void registerAliases(String packageName, Class<?> superType) {
+    // 获得指定包下的类门
+    ResolverUtil<Class<?>> resolverUtil = new ResolverUtil<>();
+    resolverUtil.find(new ResolverUtil.IsA(superType), packageName);
+    Set<Class<? extends Class<?>>> typeSet = resolverUtil.getClasses();
+    // 遍历，逐个注册类型与别名的注册表
+    for (Class<?> type : typeSet) {
+        // Ignore inner classes and interfaces (including package-info.java)
+        // Skip also inner classes. See issue #6
+        if (!type.isAnonymousClass() // 排除匿名类
+                && !type.isInterface()  // 排除接口
+                && !type.isMemberClass()) { // 排除内部类
+            registerAlias(type);
+        }
+    }
+}
+```    
+
+## 7.4 resolveAlias
+
+`#resolveAlias(String string)` 方法，获得别名对应的类型。代码如下：
+
+```Java
+// TypeAliasRegistry.java
+
+public <T> Class<T> resolveAlias(String string) {
+    try {
+        if (string == null) {
+            return null;
+        }
+        // issue #748
+        // <1> 转换成小写
+        String key = string.toLowerCase(Locale.ENGLISH);
+        Class<T> value;
+        // <2.1> 首先，从 TYPE_ALIASES 中获取
+        if (TYPE_ALIASES.containsKey(key)) {
+            value = (Class<T>) TYPE_ALIASES.get(key);
+        // <2.2> 其次，直接获得对应类
+        } else {
+            value = (Class<T>) Resources.classForName(string);
+        }
+        return value;
+    } catch (ClassNotFoundException e) { // <2.3> 异常
+        throw new TypeException("Could not resolve type alias '" + string + "'.  Cause: " + e, e);
+    }
+}
+```
+
+- `<1>` 处，将别名转换成**小写**。
+- `<2.1>` 处，首先，从 `TYPE_ALIASES` 中获取对应的类型。
+- `<2.2>` 处，其次，直接获取对应的类。所以，这个方法，同时处理了别名与全类名两种情况。
+- `<2.3>` 处，最差，找不到对应的类，发生异常，抛出 TypeException 异常。
+
+# 8. SimpleTypeRegistry
+
+`org.apache.ibatis.type.SimpleTypeRegistry` ，简单类型注册表。代码如下：
+
+```
+// SimpleTypeRegistry.java
+
+public class SimpleTypeRegistry {
+
+    /**
+     * 简单类型的集合
+     */
+    private static final Set<Class<?>> SIMPLE_TYPE_SET = new HashSet<>();
+
+    // 初始化常用类到 SIMPLE_TYPE_SET 中
+    static {
+        SIMPLE_TYPE_SET.add(String.class);
+        SIMPLE_TYPE_SET.add(Byte.class);
+        SIMPLE_TYPE_SET.add(Short.class);
+        SIMPLE_TYPE_SET.add(Character.class);
+        SIMPLE_TYPE_SET.add(Integer.class);
+        SIMPLE_TYPE_SET.add(Long.class);
+        SIMPLE_TYPE_SET.add(Float.class);
+        SIMPLE_TYPE_SET.add(Double.class);
+        SIMPLE_TYPE_SET.add(Boolean.class);
+        SIMPLE_TYPE_SET.add(Date.class);
+        SIMPLE_TYPE_SET.add(Class.class);
+        SIMPLE_TYPE_SET.add(BigInteger.class);
+        SIMPLE_TYPE_SET.add(BigDecimal.class);
+    }
+
+    private SimpleTypeRegistry() {
+        // Prevent Instantiation
+    }
+
+    /*
+     * Tells us if the class passed in is a known common type
+     *
+     * @param clazz The class to check
+     * @return True if the class is known
+     */
+    public static boolean isSimpleType(Class<?> clazz) {
+        return SIMPLE_TYPE_SET.contains(clazz);
+    }
+
+}
+```
+
+# 9. ByteArrayUtils
+
+`org.apache.ibatis.type.ByteArrayUtils` ，Byte 数组的工具类。代码如下：
+
+```
+// ByteArrayUtils.java
+
+class ByteArrayUtils {
+
+    private ByteArrayUtils() {
+        // Prevent Instantiation
+    }
+
+    // Byte[] => byte[]
+    static byte[] convertToPrimitiveArray(Byte[] objects) {
+        final byte[] bytes = new byte[objects.length];
+        for (int i = 0; i < objects.length; i++) {
+            bytes[i] = objects[i];
+        }
+        return bytes;
+    }
+
+    // byte[] => Byte[]
+    static Byte[] convertToObjectArray(byte[] bytes) {
+        final Byte[] objects = new Byte[bytes.length];
+        for (int i = 0; i < bytes.length; i++) {
+            objects[i] = bytes[i];
+        }
+        return objects;
+    }
+
+}
+```
+
+# 666. 彩蛋
+
+`type` 模块的代码，还是相对多的，不过比较简单的。
+
+参考和推荐如下文章：
+
+- 祖大俊 [《Mybatis3.3.x技术内幕（十二）：Mybatis之TypeHandler》](https://my.oschina.net/zudajun/blog/671075)
+- 徐郡明 [《MyBatis 技术内幕》](https://item.jd.com/12125531.html) 的 [「2.3 类型转换」](https://svip.iocoder.cn/MyBatis/type-package/#) 小节
\ No newline at end of file
diff --git a/mybatis/11-mybatis-IO 模块.assets/01.png b/mybatis/11-mybatis-IO 模块.assets/01.png
new file mode 100644
index 0000000..aeead7a
Binary files /dev/null and b/mybatis/11-mybatis-IO 模块.assets/01.png differ
diff --git a/mybatis/11-mybatis-IO 模块.assets/02.png b/mybatis/11-mybatis-IO 模块.assets/02.png
new file mode 100644
index 0000000..aa7d05a
Binary files /dev/null and b/mybatis/11-mybatis-IO 模块.assets/02.png differ
diff --git a/mybatis/11-mybatis-IO 模块.md b/mybatis/11-mybatis-IO 模块.md
new file mode 100644
index 0000000..31c40bd
--- /dev/null
+++ b/mybatis/11-mybatis-IO 模块.md	
@@ -0,0 +1,1218 @@
+# 精尽 MyBatis 源码分析 —— IO 模块
+
+# 1. 概述
+
+本文，我们来分享 MyBatis 的 IO 模块，对应 `io` 包。如下图所示：[![`io` 包](11-mybatis-IO 模块.assets/01.png)](http://static.iocoder.cn/images/MyBatis/2020_01_28/01.png)`io` 包
+
+在 [《精尽 MyBatis 源码解析 —— 项目结构一览》](http://svip.iocoder.cn/MyBatis/intro) 中，简单介绍了这个模块如下：
+
+> 资源加载模块，主要是对类加载器进行封装，确定类加载器的使用顺序，并提供了加载类文件以及其他资源文件的功能 。
+
+本文涉及的类如下图所示：[![类图](11-mybatis-IO 模块.assets/02.png)](http://static.iocoder.cn/images/MyBatis/2020_01_28/02.png)类图
+
+# 2. ClassLoaderWrapper
+
+`org.apache.ibatis.io.ClassLoaderWrapper` ，ClassLoader 包装器。可使用多个 ClassLoader 加载对应的资源，直到有一成功后返回资源。
+
+## 2.1 构造方法
+
+```
+// ClassLoaderWrapper.java
+
+/**
+ * 默认 ClassLoader 对象
+ */
+ClassLoader defaultClassLoader;
+/**
+ * 系统 ClassLoader 对象
+ */
+ClassLoader systemClassLoader;
+
+ClassLoaderWrapper() {
+    try {
+        systemClassLoader = ClassLoader.getSystemClassLoader();
+    } catch (SecurityException ignored) {
+        // AccessControlException on Google App Engine
+    }
+}
+```
+
+- `defaultClassLoader` 属性，默认 ClassLoader 对象。目前不存在初始化该属性的构造方法。可通过 `ClassLoaderWrapper.defaultClassLoader = xxx` 的方式，进行设置。
+- `systemClassLoader` 属性，系统 ClassLoader 对象。在构造方法中，已经初始化。
+
+## 2.2 getClassLoaders
+
+`#getClassLoaders(ClassLoader classLoader)` 方法，获得 ClassLoader 数组。代码如下：
+
+```
+// ClassLoaderWrapper.java
+
+ClassLoader[] getClassLoaders(ClassLoader classLoader) {
+    return new ClassLoader[]{
+            classLoader,
+            defaultClassLoader,
+            Thread.currentThread().getContextClassLoader(),
+            getClass().getClassLoader(),
+            systemClassLoader};
+}
+```
+
+## 2.3 getResourceAsURL
+
+`#getResourceAsURL(String resource, ...)` 方法，获得指定资源的 URL 。代码如下：
+
+```
+// ClassLoaderWrapper.java
+
+/**
+ * Get a resource as a URL using the current class path
+ *
+ * @param resource - the resource to locate
+ * @return the resource or null
+ */
+public URL getResourceAsURL(String resource) {
+    return getResourceAsURL(resource, getClassLoaders(null));
+}
+ 
+/**
+ * Get a resource from the classpath, starting with a specific class loader
+ *
+ * @param resource    - the resource to find
+ * @param classLoader - the first classloader to try
+ * @return the stream or null
+ */
+public URL getResourceAsURL(String resource, ClassLoader classLoader) {
+    return getResourceAsURL(resource, getClassLoaders(classLoader));
+}
+```
+
+- 先调用 `#getClassLoaders(ClassLoader classLoader)` 方法，获得 ClassLoader 数组。
+
+- 再调用 `#getResourceAsURL(String resource, ClassLoader[] classLoader)` 方法，获得指定资源的 InputStream 。代码如下：
+
+  ```
+  // ClassLoaderWrapper.java
+  
+  /**
+   * Get a resource as a URL using the current class path
+   *
+   * @param resource    - the resource to locate
+   * @param classLoader - the class loaders to examine
+   * @return the resource or null
+   */
+  URL getResourceAsURL(String resource, ClassLoader[] classLoader) {
+      URL url;
+      // 遍历 ClassLoader 数组
+      for (ClassLoader cl : classLoader) {
+          if (null != cl) {
+              // 获得 URL ，不带 /
+              // look for the resource as passed in...
+              url = cl.getResource(resource);
+              // 获得 URL ，带 /
+              // ...but some class loaders want this leading "/", so we'll add it
+              // and try again if we didn't find the resource
+              if (null == url) {
+                  url = cl.getResource("/" + resource);
+              }
+  
+              // "It's always in the last place I look for it!"
+              // ... because only an idiot would keep looking for it after finding it, so stop looking already.
+              // 成功获得到，返回
+              if (null != url) {
+                  return url;
+              }
+  
+          }
+      }
+      // didn't find it anywhere.
+      return null;
+  }
+  ```
+
+## 2.4 getResourceAsStream
+
+`#getResourceAsStream(String resource, ...)` 方法，获得指定资源的 InputStream 对象。代码如下：
+
+```
+// ClassLoaderWrapper.java
+
+/**
+ * Get a resource from the classpath
+ *
+ * @param resource - the resource to find
+ * @return the stream or null
+ */
+public InputStream getResourceAsStream(String resource) {
+    return getResourceAsStream(resource, getClassLoaders(null));
+}
+
+/**
+ * Get a resource from the classpath, starting with a specific class loader
+ *
+ * @param resource    - the resource to find
+ * @param classLoader - the first class loader to try
+ * @return the stream or null
+ */
+public InputStream getResourceAsStream(String resource, ClassLoader classLoader) {
+    return getResourceAsStream(resource, getClassLoaders(classLoader));
+}
+```
+
+- 先调用 `#getClassLoaders(ClassLoader classLoader)` 方法，获得 ClassLoader 数组。
+
+- 再调用 `#getResourceAsStream(String resource, ClassLoader[] classLoader)` 方法，获得指定资源的 InputStream 。代码如下：
+
+  ```
+  // ClassLoaderWrapper.java
+  
+  InputStream getResourceAsStream(String resource, ClassLoader[] classLoader) {
+      // 遍历 ClassLoader 数组
+      for (ClassLoader cl : classLoader) {
+          if (null != cl) {
+              // 获得 InputStream ，不带 /
+              // try to find the resource as passed
+              InputStream returnValue = cl.getResourceAsStream(resource);
+              // now, some class loaders want this leading "/", so we'll add it and try again if we didn't find the resource
+              // 获得 InputStream ，带 /
+              if (null == returnValue) {
+                  returnValue = cl.getResourceAsStream("/" + resource);
+              }
+  
+              // 成功获得到，返回
+              if (null != returnValue) {
+                  return returnValue;
+              }
+          }
+      }
+      return null;
+  }
+  ```
+
+  - 可使用多个 ClassLoader 加载对应的资源，直到有一成功后返回资源。
+
+## 2.5 classForName
+
+`#classForName(String name, ...)` 方法，获得指定类名对应的类。代码如下：
+
+```
+// ClassLoaderWrapper.java
+
+/**
+ * Find a class on the classpath (or die trying)
+ *
+ * @param name - the class to look for
+ * @return - the class
+ * @throws ClassNotFoundException Duh.
+ */
+public Class<?> classForName(String name) throws ClassNotFoundException {
+    return classForName(name, getClassLoaders(null));
+}
+
+/**
+ * Find a class on the classpath, starting with a specific classloader (or die trying)
+ *
+ * @param name        - the class to look for
+ * @param classLoader - the first classloader to try
+ * @return - the class
+ * @throws ClassNotFoundException Duh.
+ */
+public Class<?> classForName(String name, ClassLoader classLoader) throws ClassNotFoundException {
+    return classForName(name, getClassLoaders(classLoader));
+}
+```
+
+- 先调用 `#getClassLoaders(ClassLoader classLoader)` 方法，获得 ClassLoader 数组。
+
+- 再调用 `#classForName(String name, ClassLoader[] classLoader)` 方法，获得指定类名对应的类。代码如下：
+
+  ```
+  // ClassLoaderWrapper.java
+  
+  Class<?> classForName(String name, ClassLoader[] classLoader) throws ClassNotFoundException {
+      // 遍历 ClassLoader 数组
+      for (ClassLoader cl : classLoader) {
+          if (null != cl) {
+              try {
+                  // 获得类
+                  Class<?> c = Class.forName(name, true, cl);
+  
+                  // 成功获得到，返回
+                  if (null != c) {
+                      return c;
+                  }
+              } catch (ClassNotFoundException e) {
+                  // we'll ignore this until all classloaders fail to locate the class
+              }
+          }
+      }
+      // 获得不到，抛出 ClassNotFoundException 异常
+      throw new ClassNotFoundException("Cannot find class: " + name);
+  }
+  ```
+
+  - 可使用多个 ClassLoader 加载对应的类，直到有一成功后返回类。
+
+# 3. Resources
+
+`org.apache.ibatis.io.Resources` ，Resource 工具类。
+
+## 3.1 构造方法
+
+```
+// Resources.java
+
+/**
+ * ClassLoaderWrapper 对象
+ */
+private static ClassLoaderWrapper classLoaderWrapper = new ClassLoaderWrapper();
+
+/**
+ * 字符集
+ */
+private static Charset charset;
+
+Resources() {
+}
+
+public static void setDefaultClassLoader(ClassLoader defaultClassLoader) {defaultClassLoader
+    classLoaderWrapper.defaultClassLoader = defaultClassLoader; // 修改 ClassLoaderWrapper.
+}
+
+public static void setCharset(Charset charset) {
+    Resources.charset = charset;
+}
+```
+
+## 3.2 getResource
+
+基于 `classLoaderWrapper` 属性的封装。
+
+### 3.2.1 getResourceURL
+
+`#getResourceURL(String resource)` **静态**方法，获得指定资源的 URL 。代码如下：
+
+```
+// Resources.java
+
+public static URL getResourceURL(String resource) throws IOException {
+    // issue #625
+    return getResourceURL(null, resource);
+}
+
+public static URL getResourceURL(ClassLoader loader, String resource) throws IOException {
+    URL url = classLoaderWrapper.getResourceAsURL(resource, loader);
+    if (url == null) {
+        throw new IOException("Could not find resource " + resource);
+    }
+    return url;
+}
+```
+
+### 3.2.2 getResourceAsStream
+
+`#getResourceAsStream(String resource)` **静态**方法，获得指定资源的 InputStream 。代码如下：
+
+```
+// Resources.java
+
+public static InputStream getResourceAsStream(String resource) throws IOException {
+    return getResourceAsStream(null, resource);
+}
+
+public static InputStream getResourceAsStream(ClassLoader loader, String resource) throws IOException {
+    InputStream in = classLoaderWrapper.getResourceAsStream(resource, loader);
+    if (in == null) {
+        throw new IOException("Could not find resource " + resource);
+    }
+    return in;
+}
+```
+
+### 3.2.3 getResourceAsReader
+
+`#getResourceAsReader(String resource)` **静态**方法，获得指定资源的 Reader 。代码如下：
+
+```
+// Resources.java
+
+public static Reader getResourceAsReader(String resource) throws IOException {
+    Reader reader;
+    if (charset == null) {
+        reader = new InputStreamReader(getResourceAsStream(resource));
+    } else {
+        reader = new InputStreamReader(getResourceAsStream(resource), charset);
+    }
+    return reader;
+}
+
+public static Reader getResourceAsReader(ClassLoader loader, String resource) throws IOException {
+    Reader reader;
+    if (charset == null) {
+        reader = new InputStreamReader(getResourceAsStream(loader, resource));
+    } else {
+        reader = new InputStreamReader(getResourceAsStream(loader, resource), charset);
+    }
+    return reader;
+}
+```
+
+### 3.2.4 getResourceAsFile
+
+`#getResourceAsFile(String resource)` **静态**方法，获得指定资源的 File 。代码如下：
+
+```
+// Resources.java
+
+public static File getResourceAsFile(String resource) throws IOException {
+    return new File(getResourceURL(resource).getFile());
+}
+
+public static File getResourceAsFile(ClassLoader loader, String resource) throws IOException {
+    return new File(getResourceURL(loader, resource).getFile());
+}
+```
+
+- 基于 `classLoaderWrapper` 属性的封装。
+
+### 3.2.5 getResourceAsProperties
+
+`#getResourceAsProperties(ClassLoader loader)` **静态**方法，获得指定资源的 Properties 。代码如下：
+
+```
+// Resources.java
+
+public static Properties getResourceAsProperties(String resource) throws IOException {
+    Properties props = new Properties();
+    // 读取
+    try (InputStream in = getResourceAsStream(resource)) {
+        props.load(in);
+    }
+    return props;
+}
+
+public static Properties getResourceAsProperties(ClassLoader loader, String resource) throws IOException {
+    Properties props = new Properties();
+    // 读取
+    try (InputStream in = getResourceAsStream(loader, resource)) {
+        props.load(in);
+    }
+    return props;
+}
+```
+
+## 3.3 getUrl
+
+### 3.3.1 getUrlAsStream
+
+`#getUrlAsStream(String urlString)` **静态**方法，获得指定 URL 。代码如下：
+
+```
+// Resources.java
+
+public static InputStream getUrlAsStream(String urlString) throws IOException {
+    URL url = new URL(urlString);
+    // 打开 URLConnection
+    URLConnection conn = url.openConnection();
+    return conn.getInputStream();
+}
+```
+
+### 3.3.2 getUrlAsReader
+
+`#getUrlAsReader(String urlString)` **静态**方法，指定 URL 的 Reader 。代码如下：
+
+```
+// Resources.java
+
+public static Reader getUrlAsReader(String urlString) throws IOException {
+    Reader reader;
+    if (charset == null) {
+        reader = new InputStreamReader(getUrlAsStream(urlString));
+    } else {
+        reader = new InputStreamReader(getUrlAsStream(urlString), charset);
+    }
+    return reader;
+}
+```
+
+### 3.3.3 getUrlAsProperties
+
+`#getUrlAsReader(String urlString)` **静态**方法，指定 URL 的 Properties 。代码如下：
+
+```
+// Resources.java
+
+public static Properties getUrlAsProperties(String urlString) throws IOException {
+    Properties props = new Properties();
+    try (InputStream in = getUrlAsStream(urlString)) {
+        props.load(in);
+    }
+    return props;
+}
+```
+
+## 3.4 classForName
+
+`#classForName(String className)` **静态**方法，获得指定类名对应的类。代码如下：
+
+```
+// Resources.java
+
+public static Class<?> classForName(String className) throws ClassNotFoundException {
+    return classLoaderWrapper.classForName(className);
+}
+```
+
+# 4. ResolverUtil
+
+`org.apache.ibatis.io.ResolverUtil` ，解析器工具类，用于获得指定目录**符合条件**的类们。
+
+## 4.1 Test
+
+Test ，匹配判断接口。代码如下：
+
+```
+// ResolverUtil.java 内部类
+
+/**
+ * A simple interface that specifies how to test classes to determine if they
+ * are to be included in the results produced by the ResolverUtil.
+ */
+public interface Test {
+
+    /**
+     * Will be called repeatedly with candidate classes. Must return True if a class
+     * is to be included in the results, false otherwise.
+     */
+    boolean matches(Class<?> type);
+
+}
+```
+
+### 4.1.1 IsA
+
+IsA ，实现 Test 接口，判断是否为指定类。代码如下：
+
+```
+// ResolverUtil.java 内部类
+
+/**
+ * A Test that checks to see if each class is assignable to the provided class. Note
+ * that this test will match the parent type itself if it is presented for matching.
+ */
+public static class IsA implements Test {
+
+    /**
+     * 指定类
+     */
+    private Class<?> parent;
+
+    /** Constructs an IsA test using the supplied Class as the parent class/interface. */
+    public IsA(Class<?> parentType) {
+        this.parent = parentType;
+    }
+
+    /** Returns true if type is assignable to the parent type supplied in the constructor. */
+    @Override
+    public boolean matches(Class<?> type) {
+        return type != null && parent.isAssignableFrom(type);
+    }
+
+}
+```
+
+### 4.1.2 AnnotatedWith
+
+AnnotatedWith ，判断是否有指定注解。代码如下：
+
+```
+// ResolverUtil.java 内部类
+
+/**
+ * A Test that checks to see if each class is annotated with a specific annotation. If it
+ * is, then the test returns true, otherwise false.
+ */
+public static class AnnotatedWith implements Test {
+
+    /**
+     * 注解
+     */
+    private Class<? extends Annotation> annotation;
+
+    /** Constructs an AnnotatedWith test for the specified annotation type. */
+    public AnnotatedWith(Class<? extends Annotation> annotation) {
+        this.annotation = annotation;
+    }
+
+    /** Returns true if the type is annotated with the class provided to the constructor. */
+    @Override
+    public boolean matches(Class<?> type) {
+        return type != null && type.isAnnotationPresent(annotation);
+    }
+
+}
+```
+
+## 4.2 构造方法
+
+```
+// ResolverUtil.java
+
+/** The set of matches being accumulated. */
+private Set<Class<? extends T>> matches = new HashSet<>(); // 符合条件的类的集合
+
+private ClassLoader classloader;
+
+public Set<Class<? extends T>> getClasses() {
+    return matches;
+}
+
+public ClassLoader getClassLoader() {
+    return classloader == null ? Thread.currentThread().getContextClassLoader() : classloader;
+}
+public void setClassLoader(ClassLoader classloader) {
+    this.classloader = classloader;
+}
+```
+
+## 4.3 find
+
+`#find(Test test, String packageName)` 方法，获得指定包下，符合条件的类。代码如下：
+
+```
+// ResolverUtil.java
+
+public ResolverUtil<T> find(Test test, String packageName) {
+    // <1> 获得包的路径
+    String path = getPackagePath(packageName);
+
+    try {
+        // <2> 获得路径下的所有文件
+        List<String> children = VFS.getInstance().list(path);
+        // <3> 遍历
+        for (String child : children) {
+            // 是 Java Class
+            if (child.endsWith(".class")) {
+                // 如果匹配，则添加到结果集
+                addIfMatching(test, child);
+            }
+        }
+    } catch (IOException ioe) {
+        log.error("Could not read package: " + packageName, ioe);
+    }
+
+    return this;
+}
+```
+
+- `<1>` 处，调用 `#getPackagePath(String packageName)` 方法，获得包的路径。代码如下：
+
+  ```
+  // ResolverUtil.java
+  
+  protected String getPackagePath(String packageName) {
+      return packageName == null ? null : packageName.replace('.', '/');
+  }
+  ```
+
+- `<2>` 处，获得路径下的所有文件。详细解析，见 [「5. VFS」](https://svip.iocoder.cn/MyBatis/io-package/#) 。
+
+- `<3>` 处，遍历 Java Class 文件，调用 `#addIfMatching(Test test, String fqn)` 方法，如果匹配，则添加到结果集。代码如下：
+
+  ```
+  // ResolverUtil.java
+  
+  protected void addIfMatching(Test test, String fqn) {
+      try {
+          // 获得全类名
+          String externalName = fqn.substring(0, fqn.indexOf('.')).replace('/', '.');
+          ClassLoader loader = getClassLoader();
+          if (log.isDebugEnabled()) {
+              log.debug("Checking to see if class " + externalName + " matches criteria [" + test + "]");
+          }
+  
+          // 加载类
+          Class<?> type = loader.loadClass(externalName);
+  
+          // 判断是否匹配
+          if (test.matches(type)) {
+              matches.add((Class<T>) type);
+          }
+      } catch (Throwable t) {
+          log.warn("Could not examine class '" + fqn + "'" + " due to a " +
+                  t.getClass().getName() + " with message: " + t.getMessage());
+      }
+  }
+  ```
+
+```
+* 使用对应的 `test` 的进行匹配。
+```
+
+### 4.3.1 findImplementations
+
+`#findImplementations(Class<?> parent, String... packageNames)` 方法，判断指定目录下**们**，符合**指定类**的类们。代码如下：
+
+```
+// ResolverUtil.java
+
+public ResolverUtil<T> findImplementations(Class<?> parent, String... packageNames) {
+    if (packageNames == null) {
+        return this;
+    }
+
+    Test test = new IsA(parent);
+    for (String pkg : packageNames) {
+        find(test, pkg);
+    }
+
+    return this;
+}
+```
+
+### 4.3.2 findAnnotated
+
+`#findAnnotated(Class<? extends Annotation> annotation, String... packageNames)` 方法，判断指定目录下**们**，符合**指定注解**的类们。代码如下：
+
+```
+// ResolverUtil.java
+
+public ResolverUtil<T> findAnnotated(Class<? extends Annotation> annotation, String... packageNames) {
+    if (packageNames == null) {
+        return this;
+    }
+
+    Test test = new AnnotatedWith(annotation);
+    for (String pkg : packageNames) {
+        find(test, pkg);
+    }
+
+    return this;
+}
+```
+
+# 5. VFS
+
+`org.apache.ibatis.io.VFS` ，虚拟文件系统( Virtual File System )**抽象类**，用来查找指定路径下的的文件们。
+
+## 5.1 静态属性
+
+```
+// VFS.java
+
+/** The built-in implementations. */
+public static final Class<?>[] IMPLEMENTATIONS = {JBoss6VFS.class, DefaultVFS.class}; // 内置的 VFS 实现类的数组
+
+/** The list to which implementations are added by {@link #addImplClass(Class)}. */
+public static final List<Class<? extends VFS>> USER_IMPLEMENTATIONS = new ArrayList<>(); // 自定义的 VFS 实现类的数组
+
+public static void addImplClass(Class<? extends VFS> clazz) {
+    if (clazz != null) {
+        USER_IMPLEMENTATIONS.add(clazz);
+    }
+}
+```
+
+- `IMPLEMENTATIONS` **静态**属性，内置的 VFS 实现类的数组。目前 VFS 有 JBoss6VFS 和 DefaultVFS 两个实现类。
+- `USER_IMPLEMENTATIONS` **静态**属性，自定义的 VFS 实现类的数组。可通过 `#addImplClass(Class<? extends VFS> clazz)` 方法，进行添加。
+
+## 5.2 getInstance
+
+`#getInstance()` 方法，获得 VFS 单例。代码如下：
+
+```
+// VFS.java
+
+public static VFS getInstance() {
+    return VFSHolder.INSTANCE;
+}
+
+private static class VFSHolder {
+
+    static final VFS INSTANCE = createVFS();
+
+    @SuppressWarnings("unchecked")
+    static VFS createVFS() {
+        // Try the user implementations first, then the built-ins
+        List<Class<? extends VFS>> impls = new ArrayList<>();
+        impls.addAll(USER_IMPLEMENTATIONS);
+        impls.addAll(Arrays.asList((Class<? extends VFS>[]) IMPLEMENTATIONS));
+
+        // Try each implementation class until a valid one is found
+        // 创建 VFS 对象，选择最后一个符合的
+        VFS vfs = null;
+        for (int i = 0; vfs == null || !vfs.isValid(); i++) {
+            Class<? extends VFS> impl = impls.get(i);
+            try {
+                vfs = impl.newInstance();
+                if (vfs == null || !vfs.isValid()) {
+                    if (log.isDebugEnabled()) {
+                        log.debug("VFS implementation " + impl.getName() +
+                                " is not valid in this environment.");
+                    }
+                }
+            } catch (InstantiationException | IllegalAccessException e) {
+                log.error("Failed to instantiate " + impl, e);
+                return null;
+            }
+        }
+
+        if (log.isDebugEnabled()) {
+            log.debug("Using VFS adapter " + vfs.getClass().getName());
+        }
+
+        return vfs;
+    }
+}
+```
+
+- 单例有多种实现方式，该类采用的是“懒汉式，线程安全”，感兴趣的胖友，可以看看 [《单例模式的七种写法》](http://cantellow.iteye.com/blog/838473) 。
+- `INSTANCE` 属性，最后通过 `#createVFS()` **静态**方法来创建，虽然 `USER_IMPLEMENTATIONS` 和 `IMPLEMENTATIONS` 有多种 VFS 的实现类，但是最终选择的是，**最后一个符合**的创建的 VFS 对象。
+
+## 5.3 反射相关方法
+
+因为 VFS 自己有反射调用方法的需求，所以自己实现了三个方法。代码如下：
+
+```
+// VFS.java
+
+protected static Class<?> getClass(String className) {
+    try {
+        return Thread.currentThread().getContextClassLoader().loadClass(className);
+    } catch (ClassNotFoundException e) {
+        if (log.isDebugEnabled()) {
+            log.debug("Class not found: " + className);
+        }
+        return null;
+    }
+}
+
+protected static Method getMethod(Class<?> clazz, String methodName, Class<?>... parameterTypes) {
+    if (clazz == null) {
+        return null;
+    }
+    try {
+        return clazz.getMethod(methodName, parameterTypes);
+    } catch (SecurityException e) {
+        log.error("Security exception looking for method " + clazz.getName() + "." + methodName + ".  Cause: " + e);
+        return null;
+    } catch (NoSuchMethodException e) {
+        log.error("Method not found " + clazz.getName() + "." + methodName + "." + methodName + ".  Cause: " + e);
+        return null;
+    }
+}
+
+protected static <T> T invoke(Method method, Object object, Object... parameters)
+        throws IOException, RuntimeException {
+    try {
+        return (T) method.invoke(object, parameters);
+    } catch (IllegalArgumentException | IllegalAccessException e) {
+        throw new RuntimeException(e);
+    } catch (InvocationTargetException e) {
+        if (e.getTargetException() instanceof IOException) {
+            throw (IOException) e.getTargetException();
+        } else {
+            throw new RuntimeException(e);
+        }
+    }
+}
+```
+
+## 5.4 isValid
+
+`#isValid()` **抽象**方法，判断是否为合法的 VFS 。代码如下：
+
+```
+// VFS.java
+
+/** Return true if the {@link VFS} implementation is valid for the current environment. */
+public abstract boolean isValid();
+```
+
+- 该方法由子类实现。
+
+## 5.5 list
+
+`#list(String path)` 方法，获得指定路径下的所有资源。代码如下：
+
+```
+// VFS.java
+
+public List<String> list(String path) throws IOException {
+    List<String> names = new ArrayList<>();
+    for (URL url : getResources(path)) {
+        names.addAll(list(url, path));
+    }
+    return names;
+}
+```
+
+- 先调用 `#getResources(String path)` **静态**方法，获得指定路径下的 URL 数组。代码如下：
+
+  ```
+  // VFS.java
+  
+  protected static List<URL> getResources(String path) throws IOException {
+      return Collections.list(Thread.currentThread().getContextClassLoader().getResources(path));
+  }
+  ```
+
+- 后遍历 URL 数组，调用 `#list(URL url, String forPath)` 方法，**递归**的列出所有的资源们。代码如下：
+
+  ```
+  // VFS.java
+  
+  /**
+   * Recursively list the full resource path of all the resources that are children of the
+   * resource identified by a URL.
+   *
+   * @param url The URL that identifies the resource to list.
+   * @param forPath The path to the resource that is identified by the URL. Generally, this is the
+   *            value passed to {@link #getResources(String)} to get the resource URL.
+   * @return A list containing the names of the child resources.
+   * @throws IOException If I/O errors occur
+   */
+  protected abstract List<String> list(URL url, String forPath) throws IOException;
+  ```
+
+  - 该方法由子类进行实现。
+
+## 5.5 DefaultVFS
+
+`org.apache.ibatis.io.DefaultVFS` ，继承 VFS 抽象类，默认的 VFS 实现类。
+
+### 5.5.1 isValid
+
+```
+// DefaultVFS.java
+
+@Override
+public boolean isValid() {
+    return true;
+}
+```
+
+- 都返回 `true` ，因为默认支持。
+
+### 5.5.2 list
+
+`#list(URL url, String path)` 方法，**递归**的列出所有的资源们。代码如下：
+
+```
+// DefaultVFS.java
+
+@Override
+public List<String> list(URL url, String path) throws IOException {
+    InputStream is = null;
+    try {
+        List<String> resources = new ArrayList<>();
+
+        // First, try to find the URL of a JAR file containing the requested resource. If a JAR
+        // file is found, then we'll list child resources by reading the JAR.
+        // 如果 url 指向的是 Jar Resource ，则返回该 Jar Resource ，否则返回 null
+        URL jarUrl = findJarForResource(url);
+        if (jarUrl != null) {
+            is = jarUrl.openStream();
+            if (log.isDebugEnabled()) {
+                log.debug("Listing " + url);
+            }
+            // 遍历 Jar Resource
+            resources = listResources(new JarInputStream(is), path);
+        } else {
+            List<String> children = new ArrayList<>();
+            try {
+                // 判断为 JAR URL
+                if (isJar(url)) {
+                    // Some versions of JBoss VFS might give a JAR stream even if the resource
+                    // referenced by the URL isn't actually a JAR
+                    is = url.openStream();
+                    try (JarInputStream jarInput = new JarInputStream(is)) {
+                        if (log.isDebugEnabled()) {
+                            log.debug("Listing " + url);
+                        }
+                        for (JarEntry entry; (entry = jarInput.getNextJarEntry()) != null; ) {
+                            if (log.isDebugEnabled()) {
+                                log.debug("Jar entry: " + entry.getName());
+                            }
+                            children.add(entry.getName());
+                        }
+                    }
+                } else {
+                    /*
+                     * Some servlet containers allow reading from directory resources like a
+                     * text file, listing the child resources one per line. However, there is no
+                     * way to differentiate between directory and file resources just by reading
+                     * them. To work around that, as each line is read, try to look it up via
+                     * the class loader as a child of the current resource. If any line fails
+                     * then we assume the current resource is not a directory.
+                     */
+                    // 【重点】<1> 获得路径下的所有资源
+                    is = url.openStream();
+                    BufferedReader reader = new BufferedReader(new InputStreamReader(is));
+                    List<String> lines = new ArrayList<>();
+                    for (String line; (line = reader.readLine()) != null; ) {
+                        if (log.isDebugEnabled()) {
+                            log.debug("Reader entry: " + line);
+                        }
+                        lines.add(line);
+                        if (getResources(path + "/" + line).isEmpty()) {
+                            lines.clear();
+                            break;
+                        }
+                    }
+
+                    if (!lines.isEmpty()) {
+                        if (log.isDebugEnabled()) {
+                            log.debug("Listing " + url);
+                        }
+                        children.addAll(lines);
+                    }
+                }
+            } catch (FileNotFoundException e) {
+                /*
+                 * For file URLs the openStream() call might fail, depending on the servlet
+                 * container, because directories can't be opened for reading. If that happens,
+                 * then list the directory directly instead.
+                 */
+                if ("file".equals(url.getProtocol())) {
+                    File file = new File(url.getFile());
+                    if (log.isDebugEnabled()) {
+                        log.debug("Listing directory " + file.getAbsolutePath());
+                    }
+                    if (file.isDirectory()) {
+                        if (log.isDebugEnabled()) {
+                            log.debug("Listing " + url);
+                        }
+                        children = Arrays.asList(file.list());
+                    }
+                } else {
+                    // No idea where the exception came from so rethrow it
+                    throw e;
+                }
+            }
+
+            // The URL prefix to use when recursively listing child resources
+            // 【重点】<2> 计算 prefix
+            String prefix = url.toExternalForm();
+            if (!prefix.endsWith("/")) {
+                prefix = prefix + "/";
+            }
+
+            // Iterate over immediate children, adding files and recursing into directories
+            // 【重点】 <2> 遍历子路径
+            for (String child : children) {
+                // 添加到 resources 中
+                String resourcePath = path + "/" + child;
+                resources.add(resourcePath);
+                // 递归遍历子路径，并将结果添加到 resources 中
+                URL childUrl = new URL(prefix + child);
+                resources.addAll(list(childUrl, resourcePath));
+            }
+        }
+
+        return resources;
+    } finally {
+        // 关闭文件流
+        if (is != null) {
+            try {
+                is.close();
+            } catch (Exception e) {
+                // Ignore
+            }
+        }
+    }
+}
+```
+
+- 代码有点长，重点读懂 `<1>` 和 `<2>` 处的代码，基本就可以了。大体逻辑就是，不断递归文件夹，获得到所有文件。设计到对 Jar 的处理，感兴趣的胖友，可以自己理解下。😈 艿艿暂时没看的特别细。
+
+- `#findJarForResource(URL url)` 方法，如果 `url` 指向的是 Jar Resource ，则返回该 Jar Resource ，否则返回 `null` 。代码如下：
+
+  ```
+  // DefaultVFS.java
+  
+  protected URL findJarForResource(URL url) throws MalformedURLException {
+      if (log.isDebugEnabled()) {
+          log.debug("Find JAR URL: " + url);
+      }
+  
+      // If the file part of the URL is itself a URL, then that URL probably points to the JAR
+      // 这段代码看起来比较神奇，虽然看起来没有 break 的条件，但是是通过 MalformedURLException 异常进行
+      // 正如上面英文注释，如果 URL 的文件部分本身就是 URL ，那么该 URL 可能指向 JAR
+      try {
+          for (; ; ) {
+              url = new URL(url.getFile());
+              if (log.isDebugEnabled()) {
+                  log.debug("Inner URL: " + url);
+              }
+          }
+      } catch (MalformedURLException e) {
+          // This will happen at some point and serves as a break in the loop
+      }
+  
+      // Look for the .jar extension and chop off everything after that
+      // 判断是否意 .jar 结尾
+      StringBuilder jarUrl = new StringBuilder(url.toExternalForm());
+      int index = jarUrl.lastIndexOf(".jar");
+      if (index >= 0) {
+          jarUrl.setLength(index + 4);
+          if (log.isDebugEnabled()) {
+              log.debug("Extracted JAR URL: " + jarUrl);
+          }
+      } else {
+          if (log.isDebugEnabled()) {
+              log.debug("Not a JAR: " + jarUrl);
+          }
+          return null; // 如果不以 .jar 结尾，则直接返回 null
+      }
+  
+      // Try to open and test it
+      try {
+          URL testUrl = new URL(jarUrl.toString());
+          // 判断是否为 Jar 文件
+          if (isJar(testUrl)) {
+              return testUrl;
+          } else {
+              // WebLogic fix: check if the URL's file exists in the filesystem.
+              if (log.isDebugEnabled()) {
+                  log.debug("Not a JAR: " + jarUrl);
+              }
+              // 获得文件
+              jarUrl.replace(0, jarUrl.length(), testUrl.getFile()); // 替换
+              File file = new File(jarUrl.toString());
+              // File name might be URL-encoded
+              if (!file.exists()) { // 处理路径编码问题
+                  try {
+                      file = new File(URLEncoder.encode(jarUrl.toString(), "UTF-8"));
+                  } catch (UnsupportedEncodingException e) {
+                      throw new RuntimeException("Unsupported encoding?  UTF-8?  That's unpossible.");
+                  }
+              }
+  
+              // 判断文件存在
+              if (file.exists()) {
+                  if (log.isDebugEnabled()) {
+                      log.debug("Trying real file: " + file.getAbsolutePath());
+                  }
+                  testUrl = file.toURI().toURL();
+                  // 判断是否为 Jar 文件
+                  if (isJar(testUrl)) {
+                      return testUrl;
+                  }
+              }
+          }
+      } catch (MalformedURLException e) {
+          log.warn("Invalid JAR URL: " + jarUrl);
+      }
+  
+      if (log.isDebugEnabled()) {
+          log.debug("Not a JAR: " + jarUrl);
+      }
+      return null;
+  }
+  ```
+
+  - 会判断要求，`url` 以 `.jar` 结尾。
+
+- `#isJar(URL url)` 方法，判断是否为 JAR URL 。代码如下：
+
+  ```
+  // DefaultVFS.java
+  
+  /** The magic header that indicates a JAR (ZIP) file. */
+  private static final byte[] JAR_MAGIC = {'P', 'K', 3, 4};
+  
+  protected boolean isJar(URL url) {
+      return isJar(url, new byte[JAR_MAGIC.length]);
+  }
+  
+  protected boolean isJar(URL url, byte[] buffer) {
+      InputStream is = null;
+      try {
+          is = url.openStream();
+          // 读取文件头
+          is.read(buffer, 0, JAR_MAGIC.length);
+          // 判断文件头的 magic number 是否符合 JAR
+          if (Arrays.equals(buffer, JAR_MAGIC)) {
+              if (log.isDebugEnabled()) {
+                  log.debug("Found JAR: " + url);
+              }
+              return true;
+          }
+      } catch (Exception e) {
+          // Failure to read the stream means this is not a JAR
+      } finally {
+          if (is != null) {
+              try {
+                  is.close();
+              } catch (Exception e) {
+                  // Ignore
+              }
+          }
+      }
+      return false;
+  }
+  ```
+
+- `#listResources(JarInputStream jar, String path)` 方法，遍历 Jar Resource 。代码如下：
+
+  ```
+  // DefaultVFS.java
+  
+  protected List<String> listResources(JarInputStream jar, String path) throws IOException {
+      // Include the leading and trailing slash when matching names
+      // 保证头尾都是 /
+      if (!path.startsWith("/")) {
+          path = "/" + path;
+      }
+      if (!path.endsWith("/")) {
+          path = path + "/";
+      }
+  
+      // Iterate over the entries and collect those that begin with the requested path
+      // 遍历条目并收集以请求路径开头的条目
+      List<String> resources = new ArrayList<>();
+      for (JarEntry entry; (entry = jar.getNextJarEntry()) != null; ) {
+          if (!entry.isDirectory()) {
+              // Add leading slash if it's missing
+              String name = entry.getName();
+              if (!name.startsWith("/")) {
+                  name = "/" + name;
+              }
+  
+              // Check file name
+              if (name.startsWith(path)) {
+                  if (log.isDebugEnabled()) {
+                      log.debug("Found resource: " + name);
+                  }
+                  // Trim leading slash
+                  resources.add(name.substring(1));
+              }
+          }
+      }
+      return resources;
+  }
+  ```
+
+## 5.6 JBoss6VFS
+
+`org.apache.ibatis.io.JBoss6VFS` ，继承 VFS 抽象类，基于 JBoss 的 VFS 实现类。使用时，需要引入如下：
+
+```
+<dependency>
+    <groupId>org.jboss</groupId>
+    <artifactId>jboss-vfs</artifactId>
+    <version>${version></version>
+</dependency>
+```
+
+因为实际基本没使用到，所以暂时不分析这个类。感兴趣的胖友，可以自己瞅瞅。还是简单的。反正艿艿暂时不感兴趣，哈哈哈。
+
+# 666. 彩蛋
+
+周末偷懒了，写到 1 点多，还没写完。这篇对 `DefaultVFS#list(URL url, String path)` 方法的源码解析，有点着急，代码看着有点乱和糟心。后续有时间，在详细补充下。
+
+参考和推荐如下文章：
+
+- 无忌 [《MyBatis 源码解读之工具类》](https://my.oschina.net/wenjinglian/blog/1631911)
+- 徐郡明 [《MyBatis 技术内幕》](https://item.jd.com/12125531.html) 的 [「2.5 资源加载」](https://svip.iocoder.cn/MyBatis/io-package/#) 小节
\ No newline at end of file
diff --git a/mybatis/12-mybatis-日志模块.assets/01.png b/mybatis/12-mybatis-日志模块.assets/01.png
new file mode 100644
index 0000000..450b837
Binary files /dev/null and b/mybatis/12-mybatis-日志模块.assets/01.png differ
diff --git a/mybatis/12-mybatis-日志模块.assets/02.png b/mybatis/12-mybatis-日志模块.assets/02.png
new file mode 100644
index 0000000..5983bbe
Binary files /dev/null and b/mybatis/12-mybatis-日志模块.assets/02.png differ
diff --git a/mybatis/12-mybatis-日志模块.md b/mybatis/12-mybatis-日志模块.md
new file mode 100644
index 0000000..3f11ce1
--- /dev/null
+++ b/mybatis/12-mybatis-日志模块.md
@@ -0,0 +1,357 @@
+# 精尽 MyBatis 源码分析 —— 日志模块
+
+# 1. 概述
+
+本文，我们来分享 MyBatis 的日志模块，对应 `logging` 包。如下图所示：[![`logging` 包](12-mybatis-日志模块.assets/01.png)](http://static.iocoder.cn/images/MyBatis/2020_01_31/01.png)`logging` 包
+
+在 [《精尽 MyBatis 源码解析 —— 项目结构一览》](http://svip.iocoder.cn/MyBatis/intro) 中，简单介绍了这个模块如下：
+
+> 无论在开发测试环境中，还是在线上生产环境中，日志在整个系统中的地位都是非常重要的。良好的日志功能可以帮助开发人员和测试人员快速定位 Bug 代码，也可以帮助运维人员快速定位性能瓶颈等问题。目前的 Java 世界中存在很多优秀的日志框架，例如 Log4j、 Log4j2、Slf4j 等。
+>
+> MyBatis 作为一个设计优良的框架，除了提供详细的日志输出信息，还要能够集成多种日志框架，其日志模块的一个主要功能就是**集成第三方日志框架**。
+
+本文涉及的类如下图所示：[![类图](12-mybatis-日志模块.assets/02.png)](http://static.iocoder.cn/images/MyBatis/2020_01_31/02.png)类图
+
+- 从图的**上面**部分，我们可以看到非常多的 Logger 类的实现，分别对应我们常用的日志框架 Log4j、Slf4j ，这就是 MyBatis 对这些日志框架的适配。
+- 从图的**下面**部分，我们可以看到 BaseJdbcLogger 以及其四个子类，这个并不是将日志打印到数据库，而是 MyBatis 通过 JDK 动态代理的方式，将 JDBC 的操作，打印到日志中。即 [《设置Mybatis打印调试sql的两种方式》](https://blog.csdn.net/gao36951/article/details/53641432) 。
+
+另外，[《MyBatis 文档 —— 日志》](http://www.mybatis.org/mybatis-3/zh/logging.html) 一文，也对日志模块做了简单的介绍，不熟悉这块的胖友，也可以看看。
+
+下面，让我们开始干源码吧。
+
+# 2. LogFactory
+
+`org.apache.ibatis.logging.LogFactory` ，Log 工厂类。
+
+## 2.1 构造方法
+
+```
+// LogFactory.java
+
+/**
+ * Marker to be used by logging implementations that support markers
+ */
+public static final String MARKER = "MYBATIS";
+
+/**
+ * 使用的 Log 的构造方法
+ */
+private static Constructor<? extends Log> logConstructor;
+
+static {
+    // <1> 逐个尝试，判断使用哪个 Log 的实现类，即初始化 logConstructor 属性
+    tryImplementation(LogFactory::useSlf4jLogging);
+    tryImplementation(LogFactory::useCommonsLogging);
+    tryImplementation(LogFactory::useLog4J2Logging);
+    tryImplementation(LogFactory::useLog4JLogging);
+    tryImplementation(LogFactory::useJdkLogging);
+    tryImplementation(LogFactory::useNoLogging);
+}
+
+private LogFactory() {
+    // disable construction
+}
+```
+
+- `<1>` 处，我们可以看到，按照 Slf4j、CommonsLogging、Log4J2Logging、Log4JLogging、JdkLogging、NoLogging 的顺序，逐个尝试，判断使用哪个 Log 的实现类，即初始化 `logConstructor` 属性。
+
+- `#tryImplementation(Runnable runnable)` 方法，判断使用哪个 Log 的实现类。代码如下：
+
+  ```
+  // LogFactory.java
+  
+  private static void tryImplementation(Runnable runnable) {
+      if (logConstructor == null) {
+          try {
+              runnable.run();
+          } catch (Throwable t) {
+              // ignore
+          }
+      }
+  }
+  ```
+
+  - 当 `logConstructor` 为空时，执行 `runnable` 的方法。那么，`runnable` 怎么来的呢。实际上，`<1>` 处，使用了 Lambda 表达式，所以看起来不是很清晰。即 `tryImplementation(LogFactory::useSlf4jLogging)` 代码块，对应为：
+
+    ```
+    tryImplementation(new Runnable() {
+        @Override
+        public void run() {
+            LogFactory.useSlf4jLogging();
+        }
+    });
+    ```
+
+    - 这样，看起来是不是就清晰多了。
+
+- `#useSlf4jLogging()` 方法，尝试使用 Slf4j 。代码如下：
+
+  ```
+  // LogFactory.java
+  
+  public static synchronized void useSlf4jLogging() {
+      setImplementation(org.apache.ibatis.logging.slf4j.Slf4jImpl.class);
+  }
+  ```
+
+  - 在该方法内部，会调用 `#setImplementation(Class<? extends Log> implClass)` 方法，尝试使用指定的 Log 实现类，例如此处为 `org.apache.ibatis.logging.slf4j.Slf4jImpl` 。代码如下：
+
+    ```
+    // LogFactory.java
+    
+    private static void setImplementation(Class<? extends Log> implClass) {
+        try {
+            // 获得参数为 String 的构造方法
+            Constructor<? extends Log> candidate = implClass.getConstructor(String.class);
+            // 创建 Log 对象
+            Log log = candidate.newInstance(LogFactory.class.getName());
+            if (log.isDebugEnabled()) {
+                log.debug("Logging initialized using '" + implClass + "' adapter.");
+            }
+            // 创建成功，意味着可以使用，设置为 logConstructor
+            logConstructor = candidate;
+        } catch (Throwable t) {
+            throw new LogException("Error setting Log implementation.  Cause: " + t, t);
+        }
+    }
+    ```
+
+    - 如果对应的类能创建成功，意味着可以使用，设置为 `logConstructor` 。也就是说，其它类，就不会执行到该方法啦。
+
+- 其它 Log 类的该方法，代码如下：
+
+  ```
+  // LogFactory.java
+  
+  public static synchronized void useCommonsLogging() {
+      setImplementation(org.apache.ibatis.logging.commons.JakartaCommonsLoggingImpl.class);
+  }
+  
+  public static synchronized void useLog4JLogging() {
+      setImplementation(org.apache.ibatis.logging.log4j.Log4jImpl.class);
+  }
+  
+  public static synchronized void useLog4J2Logging() {
+      setImplementation(org.apache.ibatis.logging.log4j2.Log4j2Impl.class);
+  }
+  
+  public static synchronized void useJdkLogging() {
+      setImplementation(org.apache.ibatis.logging.jdk14.Jdk14LoggingImpl.class);
+  }
+  
+  public static synchronized void useStdOutLogging() {
+      setImplementation(org.apache.ibatis.logging.stdout.StdOutImpl.class);
+  }
+  
+  public static synchronized void useNoLogging() {
+      setImplementation(org.apache.ibatis.logging.nologging.NoLoggingImpl.class);
+  }
+  ```
+
+- 当然，也可以通过 `#useCustomLogging(Class<? extends Log> clazz)` 方法，设置自定义的 Log 实现类。代码如下：
+
+  ```
+  // LogFactory.java
+  
+  public static synchronized void useCustomLogging(Class<? extends Log> clazz) {
+      setImplementation(clazz);
+  }
+  ```
+
+  - 这里的自定义，可以是你自己实现的 Log 类，也可以是上述的 MyBatis 内置的 Log 实现类。
+
+## 2.2 getLog
+
+`#getLog(...)` 方法，获得 Log 对象。代码如下：
+
+```
+// LogFactory.java
+
+public static Log getLog(Class<?> aClass) {
+    return getLog(aClass.getName());
+}
+
+public static Log getLog(String logger) {
+    try {
+        return logConstructor.newInstance(logger);
+    } catch (Throwable t) {
+        throw new LogException("Error creating logger for logger " + logger + ".  Cause: " + t, t);
+    }
+}
+```
+
+# 3. Log
+
+`org.apache.ibatis.logging.Log` ，MyBatis Log 接口。代码如下：
+
+```
+// Log.java
+
+public interface Log {
+
+    boolean isDebugEnabled();
+
+    boolean isTraceEnabled();
+
+    void error(String s, Throwable e);
+
+    void error(String s);
+
+    void debug(String s);
+
+    void trace(String s);
+
+    void warn(String s);
+
+}
+```
+
+Log 的实现类较多，我们就看看 Slf4jImpl 和 StdOutImpl 这两个实现类。
+
+## 3.1 StdOutImpl
+
+`org.apache.ibatis.logging.stdout.StdOutImpl` ，实现 Log 接口，StdOut 实现类。代码如下：
+
+```
+// StdOutImpl.java
+
+public class StdOutImpl implements Log {
+
+    public StdOutImpl(String clazz) {
+        // Do Nothing
+    }
+
+    @Override
+    public boolean isDebugEnabled() {
+        return true;
+    }
+
+    @Override
+    public boolean isTraceEnabled() {
+        return true;
+    }
+
+    @Override
+    public void error(String s, Throwable e) {
+        System.err.println(s);
+        e.printStackTrace(System.err);
+    }
+
+    @Override
+    public void error(String s) {
+        System.err.println(s);
+    }
+
+    @Override
+    public void debug(String s) {
+        System.out.println(s);
+    }
+
+    @Override
+    public void trace(String s) {
+        System.out.println(s);
+    }
+
+    @Override
+    public void warn(String s) {
+        System.out.println(s);
+    }
+}
+```
+
+- 比较简单，基于 `System.out` 和 `System.err` 来实现。
+
+## 3.2 Slf4jImpl
+
+`org.apache.ibatis.logging.slf4j.Slf4jImpl` ，实现 Log 接口，Slf4j 实现类。代码如下：
+
+```
+// Slf4jImpl.java
+
+public class Slf4jImpl implements Log {
+
+    private Log log;
+
+    public Slf4jImpl(String clazz) {
+        // 使用 SLF LoggerFactory 获得 SLF Logger 对象
+        Logger logger = LoggerFactory.getLogger(clazz);
+
+        // 如果是 LocationAwareLogger ，则创建 Slf4jLocationAwareLoggerImpl 对象
+        if (logger instanceof LocationAwareLogger) {
+            try {
+                // check for slf4j >= 1.6 method signature
+                logger.getClass().getMethod("log", Marker.class, String.class, int.class, String.class, Object[].class, Throwable.class);
+                log = new Slf4jLocationAwareLoggerImpl((LocationAwareLogger) logger);
+                return;
+            } catch (SecurityException | NoSuchMethodException e) {
+                // fail-back to Slf4jLoggerImpl
+            }
+        }
+
+        // Logger is not LocationAwareLogger or slf4j version < 1.6
+        // 否则，创建 Slf4jLoggerImpl 对象
+        log = new Slf4jLoggerImpl(logger);
+    }
+
+    @Override
+    public boolean isDebugEnabled() {
+        return log.isDebugEnabled();
+    }
+
+    @Override
+    public boolean isTraceEnabled() {
+        return log.isTraceEnabled();
+    }
+
+    @Override
+    public void error(String s, Throwable e) {
+        log.error(s, e);
+    }
+
+    @Override
+    public void error(String s) {
+        log.error(s);
+    }
+
+    @Override
+    public void debug(String s) {
+        log.debug(s);
+    }
+
+    @Override
+    public void trace(String s) {
+        log.trace(s);
+    }
+
+    @Override
+    public void warn(String s) {
+        log.warn(s);
+    }
+
+}
+```
+
+- 在构造方法中，可以看到，适配不同的 SLF4J 的版本，分别使用 `org.apache.ibatis.logging.slf4j.Slf4jLocationAwareLoggerImpl` 和 `org.apache.ibatis.logging.slf4j.Slf4jLoggerImpl` 类。
+- 具体的方法实现，委托调用对应的 SLF4J 的方法。
+
+# 4. BaseJdbcLogger
+
+在 `org.apache.ibatis.logging` 包下的 `jdbc` 包，有如下五个类：
+
+- BaseJdbcLogger
+  - ConnectionLogger
+  - PreparedStatementLogger
+  - StatementLogger
+  - ResultSetLogger
+
+和 [《精尽 MyBatis 源码分析 —— 数据源模块》](http://svip.iocoder.cn/MyBatis/datasource-package) 类似，又是一个基于 JDBC 接口实现**增强**的案例，而原理上，也是基于 JDK 实现动态代理。
+
+代码比较简单，感兴趣的胖友，自己简单看看即可。😈 有木有发现，MyBatis 大量的使用 JDK 实现动态代理。
+
+# 666. 彩蛋
+
+在地铁上撸完这篇博客，舒服。
+
+参考和推荐如下文章：
+
+- 徐郡明 [《MyBatis 技术内幕》](https://item.jd.com/12125531.html) 的 [「2.4 日志模块」](https://svip.iocoder.cn/MyBatis/logging-package/#) 小节
\ No newline at end of file
diff --git a/mybatis/13-mybatis-注解模块.assets/01.png b/mybatis/13-mybatis-注解模块.assets/01.png
new file mode 100644
index 0000000..689177e
Binary files /dev/null and b/mybatis/13-mybatis-注解模块.assets/01.png differ
diff --git a/mybatis/13-mybatis-注解模块.md b/mybatis/13-mybatis-注解模块.md
new file mode 100644
index 0000000..86366df
--- /dev/null
+++ b/mybatis/13-mybatis-注解模块.md
@@ -0,0 +1,936 @@
+# 精尽 MyBatis 源码分析 —— 注解模块
+
+# 1. 概述
+
+本文，我们来分享 MyBatis 的注解模块，对应 `annotations` 包。如下图所示：[![`annotations` 包](13-mybatis-注解模块.assets/01.png)](http://static.iocoder.cn/images/MyBatis/2020_02_04/01.png)`annotations` 包
+
+在 [《精尽 MyBatis 源码解析 —— 项目结构一览》](http://svip.iocoder.cn/MyBatis/intro) 中，简单介绍了这个模块如下：
+
+> 随着 Java 注解的慢慢流行，MyBatis 提供了**注解**的方式，使得我们方便的在 Mapper 接口上编写简单的数据库 SQL 操作代码，而无需像之前一样，必须编写 SQL 在 XML 格式的 Mapper 文件中。虽然说，实际场景下，大家还是喜欢在 XML 格式的 Mapper 文件中编写响应的 SQL 操作。
+
+注解比较多，艿艿尽量对它们的用途，进行规整。
+
+另外，想要看 MyBatis 注解文档的胖友，可以看看 [《MyBatis 文档 —— Java API》](http://www.mybatis.org/mybatis-3/zh/java-api.html) 。
+
+> 艿艿的补充：在写完本文后，发现田守枝对注解的整理更好，引用如下：
+>
+> FROM [《mybatis 注解配置详解》](http://www.tianshouzhi.com/api/tutorials/mybatis/393)
+>
+> - **增删改查：** @Insert、@Update、@Delete、@Select、@MapKey、@Options、@SelelctKey、@Param、@InsertProvider、@UpdateProvider、@DeleteProvider、@SelectProvider
+> - **结果集映射：** @Results、@Result、@ResultMap、@ResultType、@ConstructorArgs、@Arg、@One、@Many、@TypeDiscriminator、@Case
+> - **缓存：** @CacheNamespace、@Property、@CacheNamespaceRef、@Flush
+
+# 2. CRUD 常用操作注解
+
+示例如下：
+
+```
+package com.whut.inter;
+import java.util.List;
+import org.apache.ibatis.annotations.Delete;
+import org.apache.ibatis.annotations.Insert;
+import org.apache.ibatis.annotations.Param;
+import org.apache.ibatis.annotations.Select;
+import org.apache.ibatis.annotations.Update;
+import com.whut.model.User;
+
+// 最基本的注解CRUD
+public interface IUserDAO {
+
+    @Select("select *from User")
+    public List<User> retrieveAllUsers();
+                                                                                                                                                                                                                                  
+    //注意这里只有一个参数，则#{}中的标识符可以任意取
+    @Select("select *from User where id=#{idss}")
+    public User retrieveUserById(int id);
+                                                                                                                                                                                                                                  
+    @Select("select *from User where id=#{id} and userName like #{name}")
+    public User retrieveUserByIdAndName(@Param("id")int id,@Param("name")String names);
+                                                                                                                                                                                                                                  
+    @Insert("INSERT INTO user(userName,userAge,userAddress) VALUES(#{userName},"
+            + "#{userAge},#{userAddress})")
+    public void addNewUser(User user);
+                                                                                                                                                                                                                                  
+    @Delete("delete from user where id=#{id}")
+    public void deleteUser(int id);
+                                                                                                                                                                                                                                  
+    @Update("update user set userName=#{userName},userAddress=#{userAddress}"
+            + " where id=#{id}")
+    public void updateUser(User user);
+    
+}
+```
+
+## 2.1 @Select
+
+`org.apache.ibatis.annotations.@Select` ，查询语句注解。代码如下：
+
+```
+// Select.java
+
+@Documented
+@Retention(RetentionPolicy.RUNTIME)
+@Target(ElementType.METHOD) // 方法
+public @interface Select {
+
+    /**
+     * @return 查询语句
+     */
+    String[] value();
+
+}
+```
+
+## 2.2 @Insert
+
+`org.apache.ibatis.annotations.@Insert` ，插入语句注解。代码如下：
+
+```
+// Insert.java
+
+@Documented
+@Retention(RetentionPolicy.RUNTIME)
+@Target(ElementType.METHOD) // 方法
+public @interface Insert {
+
+    /**
+     * @return 插入语句
+     */
+    String[] value();
+
+}
+```
+
+## 2.3 @Update
+
+`org.apache.ibatis.annotations.@Update` ，更新语句注解。代码如下：
+
+```
+// Update.java
+
+@Documented
+@Retention(RetentionPolicy.RUNTIME)
+@Target(ElementType.METHOD)
+public @interface Update {
+
+    /**
+     * @return 更新语句
+     */
+    String[] value();
+
+}
+```
+
+## 2.4 @Delete
+
+`org.apache.ibatis.annotations.@Delete` ，删除语句注解。代码如下：
+
+```
+// Delete.java
+
+@Documented
+@Retention(RetentionPolicy.RUNTIME)
+@Target(ElementType.METHOD) // 方法
+public @interface Delete {
+
+    /**
+     * @return 删除语句
+     */
+    String[] value();
+
+}
+```
+
+## 2.5 @Param
+
+`org.apache.ibatis.annotations.@Param` ，方法参数名的注解。代码如下：
+
+> 当映射器方法需多个参数，这个注解可以被应用于映射器方法参数来给每个参数一个名字。否则，多参数将会以它们的顺序位置来被命名。比如 `#{1}`，`#{2}` 等，这是默认的。
+>
+> 使用 `@Param("person")` ，SQL 中参数应该被命名为 `#{person}` 。
+
+```
+// Param.java
+
+@Documented
+@Retention(RetentionPolicy.RUNTIME)
+@Target(ElementType.PARAMETER) // 参数
+public @interface Param {
+
+    /**
+     * @return 参数名
+     */
+    String value();
+
+}
+```
+
+# 3. CRUD 高级操作注解
+
+示例如下：
+
+- IBlogDAO 接口：
+
+  ```
+  package com.whut.inter;
+  import java.util.List;
+  import org.apache.ibatis.annotations.CacheNamespace;
+  import org.apache.ibatis.annotations.DeleteProvider;
+  import org.apache.ibatis.annotations.InsertProvider;
+  import org.apache.ibatis.annotations.Options;
+  import org.apache.ibatis.annotations.Param;
+  import org.apache.ibatis.annotations.Result;
+  import org.apache.ibatis.annotations.ResultMap;
+  import org.apache.ibatis.annotations.Results;
+  import org.apache.ibatis.annotations.SelectProvider;
+  import org.apache.ibatis.annotations.UpdateProvider;
+  import org.apache.ibatis.type.JdbcType;
+  import com.whut.model.Blog;
+  import com.whut.sqlTool.BlogSqlProvider;
+  
+  @CacheNamespace(size=100)
+  public interface IBlogDAO {
+  
+      @SelectProvider(type = BlogSqlProvider.class, method = "getSql") 
+      @Results(value ={ 
+              @Result(id=true, property="id",column="id",javaType=Integer.class,jdbcType=JdbcType.INTEGER),
+              @Result(property="title",column="title",javaType=String.class,jdbcType=JdbcType.VARCHAR),
+              @Result(property="date",column="date",javaType=String.class,jdbcType=JdbcType.VARCHAR),
+              @Result(property="authername",column="authername",javaType=String.class,jdbcType=JdbcType.VARCHAR),
+              @Result(property="content",column="content",javaType=String.class,jdbcType=JdbcType.VARCHAR),
+              }) 
+      public Blog getBlog(@Param("id") int id);
+                                                                                                                                                                                        
+      @SelectProvider(type = BlogSqlProvider.class, method = "getAllSql") 
+      @Results(value ={ 
+              @Result(id=true, property="id",column="id",javaType=Integer.class,jdbcType=JdbcType.INTEGER),
+              @Result(property="title",column="title",javaType=String.class,jdbcType=JdbcType.VARCHAR),
+              @Result(property="date",column="date",javaType=String.class,jdbcType=JdbcType.VARCHAR),
+              @Result(property="authername",column="authername",javaType=String.class,jdbcType=JdbcType.VARCHAR),
+              @Result(property="content",column="content",javaType=String.class,jdbcType=JdbcType.VARCHAR),
+              }) 
+      public List<Blog> getAllBlog();
+                                                                                                                                                                                        
+      @SelectProvider(type = BlogSqlProvider.class, method = "getSqlByTitle") 
+      @ResultMap(value = "sqlBlogsMap") 
+      // 这里调用resultMap，这个是SQL配置文件中的,必须该SQL配置文件与本接口有相同的全限定名
+      // 注意文件中的namespace路径必须是使用@resultMap的类路径
+      public List<Blog> getBlogByTitle(@Param("title")String title);
+                                                                                                                                                                                        
+      @InsertProvider(type = BlogSqlProvider.class, method = "insertSql") 
+      public void insertBlog(Blog blog);
+                                                                                                                                                                                        
+      @UpdateProvider(type = BlogSqlProvider.class, method = "updateSql")
+      public void updateBlog(Blog blog);
+                                                                                                                                                                                        
+      @DeleteProvider(type = BlogSqlProvider.class, method = "deleteSql")
+      @Options(useCache = true, flushCache = false, timeout = 10000) 
+      public void deleteBlog(int ids);
+                                                                                                                                                                                        
+  }
+  ```
+
+- BlogSqlProvider 类：
+
+  ```
+  package com.whut.sqlTool;
+  import java.util.Map;
+  import static org.apache.ibatis.jdbc.SqlBuilder.*;
+  package com.whut.sqlTool;
+  import java.util.Map;
+  import static org.apache.ibatis.jdbc.SqlBuilder.*;
+  
+  public class BlogSqlProvider {
+  
+      private final static String TABLE_NAME = "blog";
+      
+      public String getSql(Map<Integer, Object> parameter) {
+          BEGIN();
+          //SELECT("id,title,authername,date,content");
+          SELECT("*");
+          FROM(TABLE_NAME);
+          //注意这里这种传递参数方式，#{}与map中的key对应，而map中的key又是注解param设置的
+          WHERE("id = #{id}");
+          return SQL();
+      }
+      
+      public String getAllSql() {
+          BEGIN();
+          SELECT("*");
+          FROM(TABLE_NAME);
+          return SQL();
+      }
+      
+      public String getSqlByTitle(Map<String, Object> parameter) {
+          String title = (String) parameter.get("title");
+          BEGIN();
+          SELECT("*");
+          FROM(TABLE_NAME);
+          if (title != null)
+              WHERE(" title like #{title}");
+          return SQL();
+      }
+      
+      public String insertSql() {
+          BEGIN();
+          INSERT_INTO(TABLE_NAME);
+          VALUES("title", "#{title}");
+          //  VALUES("title", "#{tt.title}");
+          //这里是传递一个Blog对象的，如果是利用上面tt.方式，则必须利用Param来设置别名
+          VALUES("date", "#{date}");
+          VALUES("authername", "#{authername}");
+          VALUES("content", "#{content}");
+          return SQL();
+      }
+      
+      public String deleteSql() {
+          BEGIN();
+          DELETE_FROM(TABLE_NAME);
+          WHERE("id = #{id}");
+          return SQL();
+      }
+      
+      public String updateSql() {
+          BEGIN();
+          UPDATE(TABLE_NAME);
+          SET("content = #{content}");
+          WHERE("id = #{id}");
+          return SQL();
+      }
+  }
+  ```
+
+  - 该示例使用 `org.apache.ibatis.jdbc.SqlBuilder` 来实现 SQL 的拼接与生成。实际上，目前该类已经废弃，推荐使用个的是 `org.apache.ibatis.jdbc.SQL` 类。
+  - 具体的 SQL 使用示例，可参见 `org.apache.ibatis.jdbc.SQLTest` 单元测试类。
+
+- Mapper XML 配置：
+
+  ```
+  <?xml version="1.0" encoding="UTF-8"?>
+  <!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
+  "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
+  <mapper namespace="com.whut.inter.IBlogDAO">
+     <resultMap type="Blog" id="sqlBlogsMap">
+        <id property="id" column="id"/>
+        <result property="title" column="title"/>
+        <result property="authername" column="authername"/>
+        <result property="date" column="date"/>
+        <result property="content" column="content"/>
+     </resultMap> 
+  </mapper>
+  ```
+
+## 3.1 @SelectProvider
+
+`org.apache.ibatis.annotations.@SelectProvider` ，查询语句提供器。代码如下：
+
+```
+// SelectProvider.java
+
+@Documented
+@Retention(RetentionPolicy.RUNTIME)
+@Target(ElementType.METHOD) // 方法
+public @interface SelectProvider {
+
+    /**
+     * @return 提供的类
+     */
+    Class<?> type();
+
+    /**
+     * @return 提供的方法
+     */
+    String method();
+
+}
+```
+
+- 从上面的使用示例可知，XXXProvider 的用途是，指定一个类( `type` )的指定方法( `method` )，返回使用的 SQL 。并且，该方法可以使用 `Map<String,Object> params` 来作为方法参数，传递参数。
+
+## 3.2 @InsertProvider
+
+`org.apache.ibatis.annotations.@InsertProvider` ，插入语句提供器。代码如下：
+
+```
+// InsertProvider.java
+
+@Documented
+@Retention(RetentionPolicy.RUNTIME)
+@Target(ElementType.METHOD) // 方法
+public @interface InsertProvider {
+
+    /**
+     * @return 提供的类
+     */
+    Class<?> type();
+
+    /**
+     * @return 提供的方法
+     */
+    String method();
+
+}
+```
+
+## 3.3 @UpdateProvider
+
+`org.apache.ibatis.annotations.@UpdateProvider` ，更新语句提供器。代码如下：
+
+```
+// UpdateProvider.java
+
+@Documented
+@Retention(RetentionPolicy.RUNTIME)
+@Target(ElementType.METHOD) // 方法
+public @interface UpdateProvider {
+
+    /**
+     * @return 提供的类
+     */
+    Class<?> type();
+
+    /**
+     * @return 提供的方法
+     */
+    String method();
+
+}
+```
+
+## 3.4 @DeleteProvider
+
+`org.apache.ibatis.annotations.@DeleteProvider` ，删除语句提供器。代码如下：
+
+```
+// DeleteProvider.java
+
+@Documented
+@Retention(RetentionPolicy.RUNTIME)
+@Target(ElementType.METHOD) // 方法
+public @interface DeleteProvider {
+
+    /**
+     * @return 提供的类
+     */
+    Class<?> type();
+
+    /**
+     * @return 提供的方法
+     */
+    String method();
+
+}
+```
+
+## 3.5 @Results
+
+`org.apache.ibatis.annotations.@Results` ，结果的注解。代码如下：
+
+> 对应 XML 标签为 `<resultMap />`
+
+```
+// Results.java
+
+@Documented
+@Retention(RetentionPolicy.RUNTIME)
+@Target(ElementType.METHOD)
+public @interface Results {
+
+    /**
+     * The name of the result map.
+     */
+    String id() default "";
+
+    /**
+     * @return {@link Result} 数组
+     */
+    Result[] value() default {};
+
+}
+```
+
+## 3.6 @Result
+
+`org.apache.ibatis.annotations.@Results` ，结果字段的注解。代码如下：
+
+```
+// Result.java
+
+@Documented
+@Retention(RetentionPolicy.RUNTIME)
+@Target({})
+public @interface Result {
+
+    /**
+     * @return 是否是 ID 字段
+     */
+    boolean id() default false;
+
+    /**
+     * @return Java 类中的属性
+     */
+    String property() default "";
+
+    /**
+     * @return 数据库的字段
+     */
+    String column() default "";
+
+    /**
+     * @return Java Type
+     */
+    Class<?> javaType() default void.class;
+
+    /**
+     * @return JDBC Type
+     */
+    JdbcType jdbcType() default JdbcType.UNDEFINED;
+
+    /**
+     * @return 使用的 TypeHandler 处理器
+     */
+    Class<? extends TypeHandler> typeHandler() default UnknownTypeHandler.class;
+
+    /**
+     * @return {@link One} 注解
+     */
+    One one() default @One;
+
+    /**
+     * @return {@link Many} 注解
+     */
+    Many many() default @Many;
+
+}
+```
+
+### 3.6.1 @One
+
+`org.apache.ibatis.annotations.@One` ，复杂类型的单独属性值的注解。代码如下：
+
+```
+@Documented
+@Retention(RetentionPolicy.RUNTIME)
+@Target({})
+public @interface One {
+
+    /**
+     * @return 已映射语句（也就是映射器方法）的全限定名
+     */
+    String select() default "";
+
+    /**
+     * @return 加载类型
+     */
+    FetchType fetchType() default FetchType.DEFAULT;
+
+}
+```
+
+### 3.6.2 @Many
+
+`org.apache.ibatis.annotations.@Many` ，复杂类型的集合属性值的注解。代码如下：
+
+```
+// Many.java
+
+@Documented
+@Retention(RetentionPolicy.RUNTIME)
+@Target({})
+public @interface Many {
+
+    /**
+     * @return 已映射语句（也就是映射器方法）的全限定名
+     */
+    String select() default "";
+
+    /**
+     * @return 加载类型
+     */
+    FetchType fetchType() default FetchType.DEFAULT;
+
+}
+```
+
+## 3.7 @ResultMap
+
+`org.apache.ibatis.annotations.@ResultMap` ，使用的结果集的注解。代码如下：
+
+```
+// ResultMap.java
+
+@Documented
+@Retention(RetentionPolicy.RUNTIME)
+@Target(ElementType.METHOD) // 方法
+public @interface ResultMap {
+
+    /**
+     * @return 结果集
+     */
+    String[] value();
+
+}
+```
+
+- 例如上述示例的 `#getBlogByTitle(@Param("title")String title)` 方法，使用的注解为 `@ResultMap(value = "sqlBlogsMap")`，而 `"sqlBlogsMap"` 中 Mapper XML 中有相关的定义。
+
+## 3.8 @ResultType
+
+`org.apache.ibatis.annotations.@ResultType` ，结果类型。代码如下：
+
+```
+// ResultType.java
+
+@Documented
+@Retention(RetentionPolicy.RUNTIME)
+@Target(ElementType.METHOD)
+public @interface ResultType {
+
+    /**
+     * @return 类型
+     */
+    Class<?> value();
+
+}
+```
+
+## 3.9 @CacheNamespace
+
+`org.apache.ibatis.annotations.@CacheNamespace` ，缓存空间配置的注解。代码如下：
+
+> 对应 XML 标签为 `<cache />`
+
+```
+@Documented
+@Retention(RetentionPolicy.RUNTIME)
+@Target(ElementType.TYPE) // Mapper 类上
+public @interface CacheNamespace {
+
+    /**
+     * @return 负责存储的 Cache 实现类
+     */
+    Class<? extends org.apache.ibatis.cache.Cache> implementation() default PerpetualCache.class;
+
+    /**
+     * @return 负责过期的 Cache 实现类
+     */
+    Class<? extends org.apache.ibatis.cache.Cache> eviction() default LruCache.class;
+
+    /**
+     * @return 清空缓存的频率。0 代表不清空
+     */
+    long flushInterval() default 0;
+
+    /**
+     * @return 缓存容器大小
+     */
+    int size() default 1024;
+
+    /**
+     * @return 是否序列化。{@link org.apache.ibatis.cache.decorators.SerializedCache}
+     */
+    boolean readWrite() default true;
+
+    /**
+     * @return 是否阻塞。{@link org.apache.ibatis.cache.decorators.BlockingCache}
+     */
+    boolean blocking() default false;
+
+    /**
+     * Property values for a implementation object.
+     * @since 3.4.2
+     *
+     * {@link Property} 数组
+     */
+    Property[] properties() default {};
+
+}
+```
+
+### 3.9.1 @Property
+
+`org.apache.ibatis.annotations.@Property` ，属性的注解。代码如下：
+
+```
+// Property.java
+
+@Documented
+@Retention(RetentionPolicy.RUNTIME)
+@Target({})
+public @interface Property {
+
+    /**
+     * 属性名
+     *
+     * A target property name
+     */
+    String name();
+
+    /**
+     * 属性值
+     *
+     * A property value or placeholder
+     */
+    String value();
+
+}
+```
+
+## 3.10 @CacheNamespaceRef
+
+`org.apache.ibatis.annotations.@CacheNamespaceRef` ，指向指定命名空间的注解。代码如下：
+
+> 对应 XML 标签为 `<cache-ref />`
+
+```
+// CacheNamespaceRef.java
+
+@Documented
+@Retention(RetentionPolicy.RUNTIME)
+@Target(ElementType.TYPE) // 类型
+public @interface CacheNamespaceRef {
+
+    /**
+     * 见 {@link MapperAnnotationBuilder#parseCacheRef()} 方法
+     *
+     * A namespace type to reference a cache (the namespace name become a FQCN of specified type)
+     */
+    Class<?> value() default void.class;
+
+    /**
+     * 指向的命名空间
+     *
+     * A namespace name to reference a cache
+     * @since 3.4.2
+     */
+    String name() default "";
+
+}
+```
+
+## 3.11 @Options
+
+`org.apache.ibatis.annotations.@Options` ，操作可选项。代码如下：
+
+```
+// Options.java
+
+@Documented
+@Retention(RetentionPolicy.RUNTIME)
+@Target(ElementType.METHOD)
+public @interface Options {
+
+    /**
+     * The options for the {@link Options#flushCache()}.
+     * The default is {@link FlushCachePolicy#DEFAULT}
+     */
+    enum FlushCachePolicy {
+        /** <code>false</code> for select statement; <code>true</code> for insert/update/delete statement. */
+        DEFAULT,
+        /** Flushes cache regardless of the statement type. */
+        TRUE,
+        /** Does not flush cache regardless of the statement type. */
+        FALSE
+    }
+
+    /**
+     * @return 是否使用缓存
+     */
+    boolean useCache() default true;
+
+    /**
+     * @return 刷新缓存的策略
+     */
+    FlushCachePolicy flushCache() default FlushCachePolicy.DEFAULT;
+
+    /**
+     * @return 结果类型
+     */
+    ResultSetType resultSetType() default ResultSetType.DEFAULT;
+
+    /**
+     * @return 语句类型
+     */
+    StatementType statementType() default StatementType.PREPARED;
+
+    /**
+     * @return 加载数量
+     */
+    int fetchSize() default -1;
+
+    /**
+     * @return 超时时间
+     */
+    int timeout() default -1;
+
+    /**
+     * @return 是否生成主键
+     */
+    boolean useGeneratedKeys() default false;
+
+    /**
+     * @return 主键在 Java 类中的属性
+     */
+    String keyProperty() default "";
+
+    /**
+     * @return 主键在数据库中的字段
+     */
+    String keyColumn() default "";
+
+    /**
+     * @return 结果集
+     */
+    String resultSets() default "";
+
+}
+```
+
+- 通过 `useGeneratedKeys` + `keyProperty` + `keyColumn` 属性，可实现返回自增 ID 。示例见 [《【MyBatis】 MyBatis修炼之八 MyBatis 注解方式的基本用法》的 「返回自增主键」 小节](https://www.jianshu.com/p/b5f823ac5355) 。
+
+## 3.12 @SelectKey
+
+`org.apache.ibatis.annotations.@SelectKey` ，通过 SQL 语句获得主键的注解。代码如下：
+
+```
+// SelectKey.java
+
+@Documented
+@Retention(RetentionPolicy.RUNTIME)
+@Target(ElementType.METHOD)
+public @interface SelectKey {
+
+    /**
+     * @return 语句
+     */
+    String[] statement();
+
+    /**
+     * @return {@link #statement()} 的类型
+     */
+    StatementType statementType() default StatementType.PREPARED;
+
+    /**
+     * @return Java 对象的属性
+     */
+    String keyProperty();
+
+    /**
+     * @return 数据库的字段
+     */
+    String keyColumn() default "";
+
+    /**
+     * @return 在插入语句执行前，还是执行后
+     */
+    boolean before();
+
+    /**
+     * @return 返回类型
+     */
+    Class<?> resultType();
+
+}
+```
+
+- 具体使用示例，可见 [《【MyBatis】 MyBatis修炼之八 MyBatis 注解方式的基本用法》的 「返回非自增主键」 小节](https://www.jianshu.com/p/b5f823ac5355) 。
+
+## 3.13 @MapKey
+
+`org.apache.ibatis.annotations.@MapKey` ，Map 结果的键的注解。代码如下：
+
+```
+// MapKey.java
+
+@Documented
+@Retention(RetentionPolicy.RUNTIME)
+@Target(ElementType.METHOD) // 方法上
+public @interface MapKey {
+
+    /**
+     * @return 键名
+     */
+    String value();
+
+}
+```
+
+- 这个注解看的艿艿一脸懵逼，具体使用示例，见 [《MyBatis使用@MapKey注解接收多个查询记录到Map中，以便方便地用get()方法获取字段的值》](https://blog.csdn.net/ClementAD/article/details/50589459) 。
+
+## 3.14 @Flush
+
+`org.apache.ibatis.annotations.@Flush` ，Flush 注解。代码如下：
+
+> 如果使用了这个注解，定义在 Mapper 接口中的方法能够调用 `SqlSession#flushStatements()` 方法。（Mybatis 3.3及以上）
+
+```
+// Flush.java
+
+@Documented
+@Retention(RetentionPolicy.RUNTIME)
+@Target(ElementType.METHOD) // 方法上
+public @interface Flush {
+}
+```
+
+# 4. 其它注解
+
+## 4.1 @Mapper
+
+`org.apache.ibatis.annotations.Mapper` ，标记这是个 Mapper 的注解。代码如下：
+
+```
+// Mapper.java
+
+@Documented
+@Inherited
+@Retention(RUNTIME)
+@Target({TYPE, METHOD, FIELD, PARAMETER})
+public @interface Mapper {
+
+    // Interface Mapper
+
+}
+```
+
+- 使用示例，见 [《MyBatis中的@Mapper注解及配套注解使用详解（上）》](https://blog.csdn.net/phenomenonsTell/article/details/79033144) 。
+
+## 4.2 @Lang
+
+`org.apache.ibatis.annotations.@Lang` ，语言驱动的注解。代码如下：
+
+```
+// Lang.java
+
+@Documented
+@Retention(RetentionPolicy.RUNTIME)
+@Target(ElementType.METHOD) // 方法
+public @interface Lang {
+
+    /**
+     * @return 驱动类
+     */
+    Class<? extends LanguageDriver> value();
+
+}
+```
+
+- 具体使用示例，可见 [《增强MyBatis注解》的 「自定义Select In注解」 小节](https://www.jianshu.com/p/03642b807688) 。
+
+## 4.3 暂时省略
+
+如下几个注解，暂时省略，使用较少。
+
+- `@TypeDiscriminator` + `@Case`
+- `@ConstructorArgs` + `@Arg`
+- `@AutomapConstructor`
+
+# 666. 彩蛋
+
+实际代码编写时，还是推荐使用 XML 的方式，而不是注解的方式。因为，好统一维护。
+
+参考和推荐如下文章：
+
+- 田守枝 [《mybayis注解配置详解》](http://www.tianshouzhi.com/api/tutorials/mybatis/393)
+- 开心跳蚤 [《【MyBatis】 MyBatis修炼之八 MyBatis 注解方式的基本用法》](https://www.jianshu.com/p/b5f823ac5355)
+- zhao_xiao_long [《MyBatis注解Annotation介绍及Demo》](http://blog.51cto.com/computerdragon/1399742)
\ No newline at end of file
diff --git a/mybatis/14-mybatis-Binding 模块.md b/mybatis/14-mybatis-Binding 模块.md
new file mode 100644
index 0000000..6ccefb1
--- /dev/null
+++ b/mybatis/14-mybatis-Binding 模块.md	
@@ -0,0 +1,612 @@
+# 精尽 MyBatis 源码分析 —— Binding 模块
+
+# 1. 概述
+
+本文，我们来分享 MyBatis 的 Binding 模块，对应 `binding` 包。如下图所示：[`binding` 包](http://static.iocoder.cn/images/MyBatis/2020_02_07/01.png)
+
+在 [《精尽 MyBatis 源码解析 —— 项目结构一览》](http://svip.iocoder.cn/MyBatis/intro) 中，简单介绍了这个模块如下：
+
+> 在调用 SqlSession 相应方法执行数据库操作时，需要指定映射文件中定义的 SQL 节点，如果出现拼写错误，我们只能在运行时才能发现相应的异常。为了尽早发现这种错误，MyBatis 通过 Binding 模块，将用户自定义的 Mapper 接口与映射配置文件关联起来，系统可以通过调用自定义 Mapper 接口中的方法执行相应的 SQL 语句完成数据库操作，从而避免上述问题。
+>
+> 值得读者注意的是，开发人员无须编写自定义 Mapper 接口的实现，MyBatis 会自动为其创建动态代理对象。在有些场景中，自定义 Mapper 接口可以完全代替映射配置文件，但有的映射规则和 SQL 语句的定义还是写在映射配置文件中比较方便，例如动态 SQL 语句的定义。
+
+本文涉及的类如下图所示：[类图](http://static.iocoder.cn/images/MyBatis/2020_02_07/02.png)
+
+# 2. MapperRegistry
+
+`org.apache.ibatis.binding.MapperRegistry` ，Mapper 注册表。
+
+## 2.1 构造方法
+
+```
+// MapperRegistry.java
+
+/**
+ * MyBatis Configuration 对象
+ */
+private final Configuration config;
+/**
+ * MapperProxyFactory 的映射
+ * 
+ * KEY：Mapper 接口
+ */
+private final Map<Class<?>, MapperProxyFactory<?>> knownMappers = new HashMap<>();
+
+public MapperRegistry(Configuration config) {
+    this.config = config;
+}
+```
+
+## 2.2 addMappers
+
+`#addMappers(String packageName, ...)` 方法，扫描指定包，并将符合的类，添加到 `knownMappers` 中。代码如下：
+
+```
+// MapperRegistry.java
+
+public void addMappers(String packageName) {
+    addMappers(packageName, Object.class);
+}
+    
+public void addMappers(String packageName, Class<?> superType) {
+    // <1> 扫描指定包下的指定类
+    ResolverUtil<Class<?>> resolverUtil = new ResolverUtil<>();
+    resolverUtil.find(new ResolverUtil.IsA(superType), packageName);
+    Set<Class<? extends Class<?>>> mapperSet = resolverUtil.getClasses();
+    // <2> 遍历，添加到 knownMappers 中
+    for (Class<?> mapperClass : mapperSet) {
+        addMapper(mapperClass);
+    }
+}
+```
+
+- `<1>` 处，使用 ResolverUtil 扫描指定包下的指定类。详细解析，在 [《精尽 MyBatis 源码分析 —— IO 模块》](http://svip.iocoder.cn/MyBatis/io-package) 中有。
+
+## 2.3 hasMapper
+
+`#hasMapper(Class<T> type)` 方法，判断是否有 Mapper 。代码如下：
+
+```
+// MapperRegistry.java
+
+public <T> boolean hasMapper(Class<T> type) {
+    return knownMappers.containsKey(type);
+}
+```
+
+## 2.4 addMapper
+
+`#addMapper(Class<T> type)` 方法，添加到 `knownMappers` 中。代码如下：
+
+```
+// MapperRegistry.java
+
+public <T> void addMapper(Class<T> type) {
+    // <1> 判断，必须是接口。
+    if (type.isInterface()) {
+        // <2> 已经添加过，则抛出 BindingException 异常
+        if (hasMapper(type)) {
+            throw new BindingException("Type " + type + " is already known to the MapperRegistry.");
+        }
+        boolean loadCompleted = false;
+        try {
+            // <3> 添加到 knownMappers 中
+            knownMappers.put(type, new MapperProxyFactory<>(type));
+            // It's important that the type is added before the parser is run
+            // otherwise the binding may automatically be attempted by the
+            // mapper parser. If the type is already known, it won't try.
+            // <4> 解析 Mapper 的注解配置
+            MapperAnnotationBuilder parser = new MapperAnnotationBuilder(config, type);
+            parser.parse();
+            // <5> 标记加载完成
+            loadCompleted = true;
+        } finally {
+            // <6> 若加载未完成，从 knownMappers 中移除
+            if (!loadCompleted) {
+                knownMappers.remove(type);
+            }
+        }
+    }
+}
+```
+
+- `<1>` 处，判断 `type` 必须是接口，也就是说 Mapper 接口。
+- `<2>` 处，已经添加过，则抛出 BindingException 异常。
+- `<3>` 处，添加到 `knownMappers` 中。
+- `<4>` 处，解析 Mapper 的注解配置。
+- `<5>` 处，创建 MapperAnnotationBuilder 对象，解析 Mapper 的注解配置。
+- `<6>` 处，若加载未完成，从 `knownMappers` 中移除。
+
+## 2.5 getMapper
+
+`#getMapper(Class<T> type, SqlSession sqlSession)` 方法，获得 Mapper Proxy 对象。代码如下：
+
+```
+// MapperRegistry.java
+
+public <T> T getMapper(Class<T> type, SqlSession sqlSession) {
+    // <1> 获得 MapperProxyFactory 对象
+    final MapperProxyFactory<T> mapperProxyFactory = (MapperProxyFactory<T>) knownMappers.get(type);
+    // 不存在，则抛出 BindingException 异常
+    if (mapperProxyFactory == null) {
+        throw new BindingException("Type " + type + " is not known to the MapperRegistry.");
+    }
+    // 创建 Mapper Proxy 对象
+    try {
+        return mapperProxyFactory.newInstance(sqlSession);
+    } catch (Exception e) {
+        throw new BindingException("Error getting mapper instance. Cause: " + e, e);
+    }
+}
+```
+
+- `<1>` 处，从 `knownMappers` 中，获得 MapperProxyFactory 对象。
+- `<2>` 处，调用 `MapperProxyFactory#newInstance(SqlSession sqlSession)` 方法，创建 Mapper Proxy 对象。详细解析，见 [「3. MapperProxyFactory」](https://svip.iocoder.cn/MyBatis/binding-package/#) 。
+
+# 3. MapperProxyFactory
+
+`org.apache.ibatis.binding.MapperProxyFactory` ，Mapper Proxy 工厂类。
+
+## 3.1 构造方法
+
+```
+// MapperProxyFactory.java
+
+/**
+ * Mapper 接口
+ */
+private final Class<T> mapperInterface;
+/**
+ * 方法与 MapperMethod 的映射
+ */
+private final Map<Method, MapperMethod> methodCache = new ConcurrentHashMap<>();
+
+public MapperProxyFactory(Class<T> mapperInterface) {
+    this.mapperInterface = mapperInterface;
+}
+
+public Class<T> getMapperInterface() {
+    return mapperInterface;
+}
+
+public Map<Method, MapperMethod> getMethodCache() {
+    return methodCache;
+}
+```
+
+## 3.2 newInstance
+
+`#newInstance(...)` 方法，创建 Mapper Proxy 对象。代码如下：
+
+```
+// MapperProxyFactory.java
+
+protected T newInstance(MapperProxy<T> mapperProxy) {
+    return (T) Proxy.newProxyInstance(mapperInterface.getClassLoader(), new Class[]{mapperInterface}, mapperProxy);
+}
+
+public T newInstance(SqlSession sqlSession) {
+    final MapperProxy<T> mapperProxy = new MapperProxy<>(sqlSession, mapperInterface, methodCache);
+    return newInstance(mapperProxy);
+}
+```
+
+- 依然是稳稳的基于 JDK Proxy 实现，而 InvocationHandler 参数是 MapperProxy 对象。关于 MapperProxy ，详细解析，见 [「4. MapperProxy」](https://svip.iocoder.cn/MyBatis/binding-package/#) 。
+
+# 4. MapperProxy
+
+`org.apache.ibatis.binding.MapperProxy` ，实现 InvocationHandler、Serializable 接口，Mapper Proxy 。关键是 `java.lang.reflect.InvocationHandler` 接口，你懂的。
+
+## 4.1 构造方法
+
+```
+// MapperProxy.java
+
+/**
+ * SqlSession 对象
+ */
+private final SqlSession sqlSession;
+/**
+ * Mapper 接口
+ */
+private final Class<T> mapperInterface;
+/**
+ * 方法与 MapperMethod 的映射
+ *
+ * 从 {@link MapperProxyFactory#methodCache} 传递过来
+ */
+private final Map<Method, MapperMethod> methodCache;
+
+public MapperProxy(SqlSession sqlSession, Class<T> mapperInterface, Map<Method, MapperMethod> methodCache) {
+    this.sqlSession = sqlSession;
+    this.mapperInterface = mapperInterface;
+    this.methodCache = methodCache;
+}
+```
+
+## 4.2 invoke
+
+`#invoke(Object proxy, Method method, Object[] args)` 方法，调用方法。代码如下：
+
+```
+// MapperProxy.java
+
+@Override
+public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
+    try {
+        // <1> 如果是 Object 定义的方法，直接调用
+        if (Object.class.equals(method.getDeclaringClass())) {
+            return method.invoke(this, args);
+        // 见 https://github.com/mybatis/mybatis-3/issues/709 ，支持 JDK8 default 方法
+        } else if (isDefaultMethod(method)) {
+            return invokeDefaultMethod(proxy, method, args);
+        }
+    } catch (Throwable t) {
+        throw ExceptionUtil.unwrapThrowable(t);
+    }
+    // <3.1> 获得 MapperMethod 对象
+    final MapperMethod mapperMethod = cachedMapperMethod(method);
+    // <3.2> 执行 MapperMethod 方法
+    return mapperMethod.execute(sqlSession, args);
+}
+```
+
+- `<1>` 处，如果是 Object 定义的方法，直接调用。
+
+- `<2>` 处，调用 `#isDefaultMethod((Method method)` 方法，判断是否为 `default` 修饰的方法，若是，则调用 `#invokeDefaultMethod(Object proxy, Method method, Object[] args)` 方法，进行反射调用。代码如下：
+
+  ```
+  // MapperProxy.java
+  
+  private Object invokeDefaultMethod(Object proxy, Method method, Object[] args)
+          throws Throwable {
+      final Constructor<MethodHandles.Lookup> constructor = MethodHandles.Lookup.class
+              .getDeclaredConstructor(Class.class, int.class);
+      if (!constructor.isAccessible()) {
+          constructor.setAccessible(true);
+      }
+      final Class<?> declaringClass = method.getDeclaringClass();
+      return constructor
+              .newInstance(declaringClass,
+                      MethodHandles.Lookup.PRIVATE | MethodHandles.Lookup.PROTECTED
+                              | MethodHandles.Lookup.PACKAGE | MethodHandles.Lookup.PUBLIC)
+              .unreflectSpecial(method, declaringClass).bindTo(proxy).invokeWithArguments(args);
+  }
+  
+  /**
+   * Backport of java.lang.reflect.Method#isDefault()
+   */
+  private boolean isDefaultMethod(Method method) {
+      return (method.getModifiers()
+              & (Modifier.ABSTRACT | Modifier.PUBLIC | Modifier.STATIC)) == Modifier.PUBLIC
+              && method.getDeclaringClass().isInterface();
+  }
+  ```
+
+  - JDK8 在接口上，新增了 `default` 修饰符。怎么进行反射调用，见 [《java8 通过反射执行接口的default方法》](https://www.jianshu.com/p/63691220f81f) 一文。
+  - 关于这段代码，在 https://github.com/mybatis/mybatis-3/issues/709 上有讨论。
+
+- `<3.1>` 处，调用 `#cachedMapperMethod(Method method)` 方法，获得 MapperMethod 对象。代码如下：
+
+  ```
+  // MapperProxy.java
+  
+  private MapperMethod cachedMapperMethod(Method method) {
+      return methodCache.computeIfAbsent(method, k -> new MapperMethod(mapperInterface, method, sqlSession.getConfiguration()));
+  }
+  ```
+
+  - 默认从 `methodCache` 缓存中获取。如果不存在，则进行创建，并进行缓存。
+
+- `<3.2>` 处，调用 `MapperMethod#execute(SqlSession sqlSession, Object[] args)` 方法，执行 MapperMethod 方法。关于 MapperMethod ，在 [「5. MapperMethod」](https://svip.iocoder.cn/MyBatis/binding-package/#) 中，详细解析。
+
+# 5. MapperMethod
+
+`org.apache.ibatis.binding.MapperMethod` ，Mapper 方法。在 Mapper 接口中，每个定义的方法，对应一个 MapperMethod 对象。
+
+## 5.1 构造方法
+
+```
+// MapperMethod.java
+
+/**
+ * SqlCommand 对象
+ */
+private final SqlCommand command;
+/**
+ * MethodSignature 对象
+ */
+private final MethodSignature method;
+
+public MapperMethod(Class<?> mapperInterface, Method method, Configuration config) {
+    this.command = new SqlCommand(config, mapperInterface, method);
+    this.method = new MethodSignature(config, mapperInterface, method);
+}
+```
+
+- `command` 属性，SqlCommand 对象。关于它的详细解析，见 [「6. SqlCommand」](https://svip.iocoder.cn/MyBatis/binding-package/#) 。
+- `method` 属性，MethodSignature 对象。关于它的详细解析，见 [「7. MethodSignature」](https://svip.iocoder.cn/MyBatis/binding-package/#) 。
+
+## 5.2 execute
+
+因为涉及比较多的后面的内容，所以放在 详细解析。
+
+心急的胖友，可以先看看 [《Mybatis3.3.x技术内幕（十一）：执行一个Sql命令的完整流程》](https://my.oschina.net/zudajun/blog/670373) 。
+
+# 6. SqlCommand
+
+SqlCommand ，是 MapperMethod 的内部静态类，SQL 命令。
+
+## 6.1 构造方法
+
+```
+// SqlCommand.java
+
+/**
+ * {@link MappedStatement#getId()}
+ */
+private final String name;
+/**
+ * SQL 命令类型
+ */
+private final SqlCommandType type;
+
+public SqlCommand(Configuration configuration, Class<?> mapperInterface, Method method) {
+    final String methodName = method.getName();
+    final Class<?> declaringClass = method.getDeclaringClass();
+    // <1> 获得 MappedStatement 对象
+    MappedStatement ms = resolveMappedStatement(mapperInterface, methodName, declaringClass,
+            configuration);
+    // <2> 找不到 MappedStatement
+    if (ms == null) {
+        // 如果有 @Flush 注解，则标记为 FLUSH 类型
+        if (method.getAnnotation(Flush.class) != null) {
+            name = null;
+            type = SqlCommandType.FLUSH;
+        } else { // 抛出 BindingException 异常，如果找不到 MappedStatement
+            throw new BindingException("Invalid bound statement (not found): "
+                    + mapperInterface.getName() + "." + methodName);
+        }
+    // <3> 找到 MappedStatement
+    } else {
+        // 获得 name
+        name = ms.getId();
+        // 获得 type
+        type = ms.getSqlCommandType();
+        if (type == SqlCommandType.UNKNOWN) { // 抛出 BindingException 异常，如果是 UNKNOWN 类型
+            throw new BindingException("Unknown execution method for: " + name);
+        }
+    }
+}
+```
+
+- `name` 属性，对应 `MappedStatement#getId()` 方法获得的标识。实际上，就是 `${NAMESPACE_NAME}.${语句_ID}`， 例如：`"org.apache.ibatis.autoconstructor.AutoConstructorMapper.getSubject2"` 。
+
+- `type` 属性，SQL 命令类型。`org.apache.ibatis.mapping.SqlCommandType` 类，代码如下：
+
+  ```
+  // SqlCommandType.java
+  
+  public enum SqlCommandType {
+  
+      /**
+       * 未知
+       */
+      UNKNOWN,
+      /**
+       * 插入
+       */
+      INSERT,
+      /**
+       * 更新
+       */
+      UPDATE,
+      /**
+       * 删除
+       */
+      DELETE,
+      /**
+       * 查询
+       */
+      SELECT,
+      /**
+       * FLUSH
+       */
+      FLUSH
+  
+  }
+  ```
+
+- `<1>` 处，调用 `#resolveMappedStatement(Class<?> mapperInterface, String methodName, Class<?> declaringClass, Configuration configuration)` 方法，获得 MappedStatement 对象。详细解析，胖友先跳到 [「6.2 resolveMappedStatement」](https://svip.iocoder.cn/MyBatis/binding-package/#) 。
+- `<2>` 处，如果找不到 MappedStatement 对象，说明该方法上，没有对应的 SQL 声明。那么在判断是否有 `@Flush` 注解，如果有，说明该方法是用于执行 flush 操作，否则，抛出 BindingException 异常。
+- `<3>` 处，如果找到 MappedStatement 对象，则初始化 `name` 和 `type` 属性。
+
+## 6.2 resolveMappedStatement
+
+`#resolveMappedStatement(Class<?> mapperInterface, String methodName, Class<?> declaringClass, Configuration configuration)` 方法，获得 MappedStatement 对象。代码如下：
+
+```
+// SqlCommand.java
+
+private MappedStatement resolveMappedStatement(Class<?> mapperInterface, String methodName,
+                                               Class<?> declaringClass, Configuration configuration) {
+    // <1> 获得编号
+    String statementId = mapperInterface.getName() + "." + methodName;
+    // <2> 如果有，获得 MappedStatement 对象，并返回
+    if (configuration.hasStatement(statementId)) {
+        return configuration.getMappedStatement(statementId);
+    // 如果没有，并且当前方法就是 declaringClass 声明的，则说明真的找不到
+    } else if (mapperInterface.equals(declaringClass)) {
+        return null;
+    }
+    // 遍历父接口，继续获得 MappedStatement 对象
+    for (Class<?> superInterface : mapperInterface.getInterfaces()) {
+        if (declaringClass.isAssignableFrom(superInterface)) {
+            MappedStatement ms = resolveMappedStatement(superInterface, methodName,
+                    declaringClass, configuration);
+            if (ms != null) {
+                return ms;
+            }
+        }
+    }
+    // 真的找不到，返回 null
+    return null;
+}
+```
+
+- `<1>` 处，获得编号。这个编号，和我们上文提到的 `${NAMESPACE_NAME}.${语句_ID}` 。
+- `<2>` 处，通过 `Configuration#hasStatement(String statementId)` 方法，判断是否有 MappedStatement 。如果有，则调用 `Configuration#getMappedStatement(String statementId)` 方法，获得 MappedStatement 对象。关于 Configuration ，我们在后续的文章中，详细解析。在这里，胖友只需要知道，Configuration 里缓存了所有的 MappedStatement ，并且每一个 XML 里声明的例如 `<select />` 或者 `<update />` 等等，都对应一个 MappedStatement 对象。
+- `<3>` 处，如果没有，并且当前方法就是 `declaringClass` 声明的，则说明真的找不到。
+- `<4>` 处，遍历父接口，**递归**继续获得 MappedStatement 对象。**因为，该该方法定义在父接口中**。
+
+# 7. MethodSignature
+
+MethodSignature ，是 MapperMethod 的内部静态类，方法签名。
+
+## 7.1 构造方法
+
+```
+// MethodSignature.java
+
+/**
+ * 返回类型是否为集合
+ */
+private final boolean returnsMany;
+/**
+ * 返回类型是否为 Map
+ */
+private final boolean returnsMap;
+/**
+ * 返回类型是否为 void
+ */
+private final boolean returnsVoid;
+/**
+ * 返回类型是否为 {@link org.apache.ibatis.cursor.Cursor}
+ */
+private final boolean returnsCursor;
+/**
+ * 返回类型是否为 {@link java.util.Optional}
+ */
+private final boolean returnsOptional;
+/**
+ * 返回类型
+ */
+private final Class<?> returnType;
+/**
+ * 返回方法上的 {@link MapKey#value()} ，前提是返回类型为 Map
+ */
+private final String mapKey;
+/**
+ * 获得 {@link ResultHandler} 在方法参数中的位置。
+ *
+ * 如果为 null ，说明不存在这个类型
+ */
+private final Integer resultHandlerIndex;
+/**
+ * 获得 {@link RowBounds} 在方法参数中的位置。
+ *
+ * 如果为 null ，说明不存在这个类型
+ */
+private final Integer rowBoundsIndex;
+/**
+ * ParamNameResolver 对象
+ */
+private final ParamNameResolver paramNameResolver;
+
+public MethodSignature(Configuration configuration, Class<?> mapperInterface, Method method) {
+    // 初始化 returnType 属性
+    Type resolvedReturnType = TypeParameterResolver.resolveReturnType(method, mapperInterface);
+    if (resolvedReturnType instanceof Class<?>) { // 普通类
+        this.returnType = (Class<?>) resolvedReturnType;
+    } else if (resolvedReturnType instanceof ParameterizedType) { // 泛型
+        this.returnType = (Class<?>) ((ParameterizedType) resolvedReturnType).getRawType();
+    } else { // 内部类等等
+        this.returnType = method.getReturnType();
+    }
+    // 初始化 returnsVoid 属性
+    this.returnsVoid = void.class.equals(this.returnType);
+    // 初始化 returnsMany 属性
+    this.returnsMany = configuration.getObjectFactory().isCollection(this.returnType) || this.returnType.isArray();
+    // 初始化 returnsCursor 属性
+    this.returnsCursor = Cursor.class.equals(this.returnType);
+    // 初始化 returnsOptional 属性
+    this.returnsOptional = Optional.class.equals(this.returnType);
+    // <1> 初始化 mapKey
+    this.mapKey = getMapKey(method);
+    // 初始化 returnsMap
+    this.returnsMap = this.mapKey != null;
+    // <2> 初始化 rowBoundsIndex、resultHandlerIndex
+    this.rowBoundsIndex = getUniqueParamIndex(method, RowBounds.class);
+    this.resultHandlerIndex = getUniqueParamIndex(method, ResultHandler.class);
+    // 初始化 paramNameResolver
+    this.paramNameResolver = new ParamNameResolver(configuration, method);
+}
+```
+
+- `<1>` 处，调用 `#getMapKey(Method method)` 方法，获得注解的 `{@link MapKey#value()}` 。代码如下：
+
+  ```
+  // MethodSignature.java
+  
+  private String getMapKey(Method method) {
+      String mapKey = null;
+      // 返回类型为 Map
+      if (Map.class.isAssignableFrom(method.getReturnType())) {
+          // 使用 @MapKey 注解
+          final MapKey mapKeyAnnotation = method.getAnnotation(MapKey.class);
+          // 获得 @MapKey 注解的键
+          if (mapKeyAnnotation != null) {
+              mapKey = mapKeyAnnotation.value();
+          }
+      }
+      return mapKey;
+  }
+  ```
+
+- `<2>` 处，调用 `#getUniqueParamIndex(Method method, Class<?> paramType)` 方法，获得指定参数类型在方法参数中的位置。代码如下：
+
+  ```
+  // MethodSignature.java
+  
+  private Integer getUniqueParamIndex(Method method, Class<?> paramType) {
+      Integer index = null;
+      // 遍历方法参数
+      final Class<?>[] argTypes = method.getParameterTypes();
+      for (int i = 0; i < argTypes.length; i++) {
+          if (paramType.isAssignableFrom(argTypes[i])) { // 类型符合
+              // 获得第一次的位置
+              if (index == null) {
+                  index = i;
+              // 如果重复类型了，则抛出 BindingException 异常
+              } else {
+                  throw new BindingException(method.getName() + " cannot have multiple " + paramType.getSimpleName() + " parameters");
+              }
+          }
+      }
+      return index;
+  }
+  ```
+
+## 7.2 convertArgsToSqlCommandParam
+
+`#convertArgsToSqlCommandParam(Object[] args)` 方法，获得 SQL 通用参数。代码如下：
+
+```
+// MethodSignature.java
+
+public Object convertArgsToSqlCommandParam(Object[] args) {
+    return paramNameResolver.getNamedParams(args);
+}
+```
+
+- 在内部，会调用 `ParamNameResolver#getNamedParams(Object[] args)` 方法。在 [《精尽 MyBatis 源码分析 —— 反射模块》](http://svip.iocoder.cn/MyBatis/reflection-package) 中，有详细解析。
+- 如下图是一个 `args` 和转换后的结果的示例：[示例](http://static.iocoder.cn/images/MyBatis/2020_02_07/03.png)
+
+# 666. 彩蛋
+
+木有彩蛋，哈哈哈哈。
+
+参考和推荐如下文章：
+
+- 祖大俊 [《Mybatis3.3.x技术内幕（二）：动态代理之投鞭断流（自动映射器Mapper的底层实现原理）》](https://my.oschina.net/zudajun/blog/666223)
+- 徐郡明 [《MyBatis 技术内幕》](https://item.jd.com/12125531.html) 的 [「2.8 bind 模块」](https://svip.iocoder.cn/MyBatis/binding-package/#) 小节
\ No newline at end of file
diff --git a/mybatis/15-mybatis-MyBatis 初始化（一）之加载 mybatis-config.assets/01.png b/mybatis/15-mybatis-MyBatis 初始化（一）之加载 mybatis-config.assets/01.png
new file mode 100644
index 0000000..faa5ec9
Binary files /dev/null and b/mybatis/15-mybatis-MyBatis 初始化（一）之加载 mybatis-config.assets/01.png differ
diff --git a/mybatis/15-mybatis-MyBatis 初始化（一）之加载 mybatis-config.md b/mybatis/15-mybatis-MyBatis 初始化（一）之加载 mybatis-config.md
new file mode 100644
index 0000000..edca214
--- /dev/null
+++ b/mybatis/15-mybatis-MyBatis 初始化（一）之加载 mybatis-config.md	
@@ -0,0 +1,1293 @@
+# 精尽 MyBatis 源码分析 —— MyBatis 初始化（一）之加载 mybatis-config
+
+# 1. 概述
+
+从本文开始，我们来分享 MyBatis 初始化的流程。在 [《精尽 MyBatis 源码分析 —— 项目结构一览》](http://svip.iocoder.cn/MyBatis/intro) 中，我们简单介绍这个流程如下：
+
+> 在 MyBatis 初始化过程中，会加载 `mybatis-config.xml` 配置文件、映射配置文件以及 Mapper 接口中的注解信息，解析后的配置信息会形成相应的对象并保存到 Configuration 对象中。例如：
+>
+> - `<resultMap>`节点(即 ResultSet 的映射规则) 会被解析成 ResultMap 对象。
+> - `<result>` 节点(即属性映射)会被解析成 ResultMapping 对象。
+>
+> 之后，利用该 Configuration 对象创建 SqlSessionFactory对象。待 MyBatis 初始化之后，开发人员可以通过初始化得到 SqlSessionFactory 创建 SqlSession 对象并完成数据库操作。
+
+- 对应 `builder` 模块，为配置**解析过程**
+- 对应 `mapping` 模块，主要为 SQL 操作解析后的**映射**。
+
+因为整个 MyBatis 的初始化流程涉及代码颇多，所以拆分成三篇文章：
+
+- 加载 `mybatis-config.xml` 配置文件。
+- 加载 Mapper 映射配置文件。
+- 加载 Mapper 接口中的注解信息。
+
+本文就主要分享第一部分「加载 `mybatis-config.xml` 配置文件」。
+
+------
+
+MyBatis 的初始化流程的**入口**是 SqlSessionFactoryBuilder 的 `#build(Reader reader, String environment, Properties properties)` 方法，代码如下：
+
+> SqlSessionFactoryBuilder 中，build 方法有多种重载方式。这里就选取一个。
+
+```
+// SqlSessionFactoryBuilder.java
+
+/**
+ * 构造 SqlSessionFactory 对象
+ *
+ * @param reader Reader 对象
+ * @param environment 环境
+ * @param properties Properties 变量
+ * @return SqlSessionFactory 对象
+ */
+public SqlSessionFactory build(Reader reader, String environment, Properties properties) {
+    try {
+        // <1> 创建 XMLConfigBuilder 对象
+        XMLConfigBuilder parser = new XMLConfigBuilder(reader, environment, properties);
+        // <2> 执行 XML 解析
+        // <3> 创建 DefaultSqlSessionFactory 对象
+        return build(parser.parse());
+    } catch (Exception e) {
+        throw ExceptionFactory.wrapException("Error building SqlSession.", e);
+    } finally {
+        ErrorContext.instance().reset();
+        try {
+            reader.close();
+        } catch (IOException e) {
+            // Intentionally ignore. Prefer previous error.
+        }
+    }
+}
+```
+
+- `<1>` 处，创建 XMLConfigBuilder 对象。
+- `<2>` 处，调用 `XMLConfigBuilder#parse()` 方法，执行 XML 解析，返回 Configuration 对象。
+- `<3>` 处，创建 DefaultSqlSessionFactory 对象。
+- 本文的重点是 `<1>` 和 `<2>` 处，即 XMLConfigBuilder 类。详细解析，见 [「3. XMLConfigBuilder」](https://svip.iocoder.cn/MyBatis/builder-package-1/#) 。
+
+# 2. BaseBuilder
+
+`org.apache.ibatis.builder.BaseBuilder` ，基础构造器抽象类，为子类提供通用的工具类。
+
+为什么不直接讲 XMLConfigBuilder ，而是先讲 BaseBuilder 呢？因为，BaseBuilder 是 XMLConfigBuilder 的父类，并且它还有其他的子类。如下图所示：[![BaseBuilder 类图](15-mybatis-MyBatis 初始化（一）之加载 mybatis-config.assets/01.png)](http://static.iocoder.cn/images/MyBatis/2020_02_10/01.png)BaseBuilder 类图
+
+## 2.1 构造方法
+
+```
+// BaseBuilder.java
+
+/**
+ * MyBatis Configuration 对象
+ */
+protected final Configuration configuration;
+protected final TypeAliasRegistry typeAliasRegistry;
+protected final TypeHandlerRegistry typeHandlerRegistry;
+
+public BaseBuilder(Configuration configuration) {
+    this.configuration = configuration;
+    this.typeAliasRegistry = this.configuration.getTypeAliasRegistry();
+    this.typeHandlerRegistry = this.configuration.getTypeHandlerRegistry();
+}
+```
+
+- `configuration` 属性，MyBatis Configuration 对象。XML 和注解中解析到的配置，最终都会设置到 [`org.apache.ibatis.session.Configuration`](https://github.com/YunaiV/mybatis-3/blob/master/src/main/java/org/apache/ibatis/session/Configuration.java) 中。感兴趣的胖友，可以先点击瞅一眼。抽完之后，马上回来。
+
+## 2.2 parseExpression
+
+`#parseExpression(String regex, String defaultValue)` 方法，创建正则表达式。代码如下：
+
+```
+// BaseBuilder.java
+
+/**
+ * 创建正则表达式
+ *
+ * @param regex 指定表达式
+ * @param defaultValue 默认表达式
+ * @return 正则表达式
+ */
+@SuppressWarnings("SameParameterValue")
+protected Pattern parseExpression(String regex, String defaultValue) {
+    return Pattern.compile(regex == null ? defaultValue : regex);
+}
+```
+
+## 2.3 xxxValueOf
+
+`#xxxValueOf(...)` 方法，将字符串转换成对应的数据类型的值。代码如下：
+
+```
+// BaseBuilder.java
+
+protected Boolean booleanValueOf(String value, Boolean defaultValue) {
+    return value == null ? defaultValue : Boolean.valueOf(value);
+}
+
+protected Integer integerValueOf(String value, Integer defaultValue) {
+    return value == null ? defaultValue : Integer.valueOf(value);
+}
+
+protected Set<String> stringSetValueOf(String value, String defaultValue) {
+    value = (value == null ? defaultValue : value);
+    return new HashSet<>(Arrays.asList(value.split(",")));
+}
+```
+
+## 2.4 resolveJdbcType
+
+`#resolveJdbcType(String alias)` 方法，解析对应的 JdbcType 类型。代码如下：
+
+```
+// BaseBuilder.java
+
+protected JdbcType resolveJdbcType(String alias) {
+    if (alias == null) {
+        return null;
+    }
+    try {
+        return JdbcType.valueOf(alias);
+    } catch (IllegalArgumentException e) {
+        throw new BuilderException("Error resolving JdbcType. Cause: " + e, e);
+    }
+}
+```
+
+## 2.5 resolveResultSetType
+
+`#resolveResultSetType(String alias)` 方法，解析对应的 ResultSetType 类型。代码如下：
+
+```
+// BaseBuilder.java
+
+protected ResultSetType resolveResultSetType(String alias) {
+    if (alias == null) {
+        return null;
+    }
+    try {
+        return ResultSetType.valueOf(alias);
+    } catch (IllegalArgumentException e) {
+        throw new BuilderException("Error resolving ResultSetType. Cause: " + e, e);
+    }
+}
+```
+
+## 2.6 resolveParameterMode
+
+`#resolveParameterMode(String alias)` 方法，解析对应的 ParameterMode 类型。代码如下：
+
+```
+// BaseBuilder.java
+
+protected ParameterMode resolveParameterMode(String alias) {
+    if (alias == null) {
+        return null;
+    }
+    try {
+        return ParameterMode.valueOf(alias);
+    } catch (IllegalArgumentException e) {
+        throw new BuilderException("Error resolving ParameterMode. Cause: " + e, e);
+    }
+}
+```
+
+## 2.7 createInstance
+
+`#createInstance(String alias)` 方法，创建指定对象。代码如下：
+
+```
+// BaseBuilder.java
+
+protected Object createInstance(String alias) {
+    // <1> 获得对应的类型
+    Class<?> clazz = resolveClass(alias);
+    if (clazz == null) {
+        return null;
+    }
+    try {
+        // <2> 创建对象
+        return resolveClass(alias).newInstance(); // 这里重复获得了一次
+    } catch (Exception e) {
+        throw new BuilderException("Error creating instance. Cause: " + e, e);
+    }
+}
+```
+
+- `<1>` 处，调用 `#resolveClass(String alias)` 方法，获得对应的类型。代码如下：
+
+  ```
+  // BaseBuilder.java
+  
+  protected <T> Class<? extends T> resolveClass(String alias) {
+      if (alias == null) {
+          return null;
+      }
+      try {
+          return resolveAlias(alias);
+      } catch (Exception e) {
+          throw new BuilderException("Error resolving class. Cause: " + e, e);
+      }
+  }
+  
+  protected <T> Class<? extends T> resolveAlias(String alias) {
+      return typeAliasRegistry.resolveAlias(alias);
+  }
+  ```
+
+  - 从 `typeAliasRegistry` 中，通过别名或类全名，获得对应的类。
+
+- `<2>` 处，创建对象。
+
+## 2.8 resolveTypeHandler
+
+`#resolveTypeHandler(Class<?> javaType, String typeHandlerAlias)` 方法，从 `typeHandlerRegistry` 中获得或创建对应的 TypeHandler 对象。代码如下：
+
+```
+// BaseBuilder.java
+
+protected TypeHandler<?> resolveTypeHandler(Class<?> javaType, Class<? extends TypeHandler<?>> typeHandlerType) {
+    if (typeHandlerType == null) {
+        return null;
+    }
+    // javaType ignored for injected handlers see issue #746 for full detail
+    // 先获得 TypeHandler 对象
+    TypeHandler<?> handler = typeHandlerRegistry.getMappingTypeHandler(typeHandlerType);
+    if (handler == null) { // 如果不存在，进行创建 TypeHandler 对象
+        // not in registry, create a new one
+        handler = typeHandlerRegistry.getInstance(javaType, typeHandlerType);
+    }
+    return handler;
+}
+```
+
+# 3. XMLConfigBuilder
+
+`org.apache.ibatis.builder.xml.XMLConfigBuilder` ，继承 BaseBuilder 抽象类，XML 配置构建器，主要负责解析 mybatis-config.xml 配置文件。即对应 [《MyBatis 文档 —— XML 映射配置文件》](http://www.mybatis.org/mybatis-3/zh/configuration.html) 。
+
+## 3.1 构造方法
+
+```
+// XMLConfigBuilder.java
+
+/**
+ * 是否已解析
+ */
+private boolean parsed;
+/**
+ * 基于 Java XPath 解析器
+ */
+private final XPathParser parser;
+/**
+ * 环境
+ */
+private String environment;
+/**
+ * ReflectorFactory 对象
+ */
+private final ReflectorFactory localReflectorFactory = new DefaultReflectorFactory();
+
+public XMLConfigBuilder(Reader reader) {
+    this(reader, null, null);
+}
+
+public XMLConfigBuilder(Reader reader, String environment) {
+    this(reader, environment, null);
+}
+
+public XMLConfigBuilder(Reader reader, String environment, Properties props) {
+    this(new XPathParser(reader, true, props, new XMLMapperEntityResolver()), environment, props);
+}
+
+public XMLConfigBuilder(InputStream inputStream) {
+    this(inputStream, null, null);
+}
+
+public XMLConfigBuilder(InputStream inputStream, String environment) {
+    this(inputStream, environment, null);
+}
+
+public XMLConfigBuilder(InputStream inputStream, String environment, Properties props) {
+    this(new XPathParser(inputStream, true, props, new XMLMapperEntityResolver()), environment, props);
+}
+
+private XMLConfigBuilder(XPathParser parser, String environment, Properties props) {
+    // <1> 创建 Configuration 对象
+    super(new Configuration());
+    ErrorContext.instance().resource("SQL Mapper Configuration");
+    // <2> 设置 Configuration 的 variables 属性
+    this.configuration.setVariables(props);
+    this.parsed = false;
+    this.environment = environment;
+    this.parser = parser;
+}
+```
+
+- `parser` 属性，XPathParser 对象。在 [《精尽 MyBatis 源码分析 —— 解析器模块》](http://svip.iocoder.cn/MyBatis/parsing-package) 中，已经详细解析。
+
+- `localReflectorFactory` 属性，DefaultReflectorFactory 对象。在 [《精尽 MyBatis 源码分析 —— 反射模块》](http://svip.iocoder.cn/MyBatis/reflection-package) 中，已经详细解析。
+
+- 构造方法重载了比较多，只需要看最后一个。
+
+  - `<1>` 处，创建 Configuration 对象。
+
+  - `<2>` 处，设置 Configuration 对象的 `variables` 属性。代码如下：
+
+    ```
+    // Configuration.java
+    
+    /**
+     * 变量 Properties 对象。
+     *
+     * 参见 {@link org.apache.ibatis.builder.xml.XMLConfigBuilder#propertiesElement(XNode context)} 方法
+     */
+    protected Properties variables = new Properties();
+    
+    public void setVariables(Properties variables) {
+        this.variables = variables;
+    }
+    ```
+
+## 3.2 parse
+
+`#parse()` 方法，解析 XML 成 Configuration 对象。代码如下：
+
+```
+// XMLConfigBuilder.java
+
+public Configuration parse() {
+    // <1.1> 若已解析，抛出 BuilderException 异常
+    if (parsed) {
+        throw new BuilderException("Each XMLConfigBuilder can only be used once.");
+    }
+    // <1.2> 标记已解析
+    parsed = true;
+    // <2> 解析 XML configuration 节点
+    parseConfiguration(parser.evalNode("/configuration"));
+    return configuration;
+}
+```
+
+- `<1.1>` 处，若已解析，抛出 BuilderException 异常。
+- `<1.2>` 处，标记已解析。
+- `<2>` 处，调用 `XPathParser#evalNode(String expression)` 方法，获得 XML `<configuration />` 节点，后调用 `#parseConfiguration(XNode root)` 方法，解析该节点。详细解析，见 [「3.3 parseConfiguration」](https://svip.iocoder.cn/MyBatis/builder-package-1/#) 。
+
+## 3.3 parseConfiguration
+
+`#parseConfiguration(XNode root)` 方法，解析 `<configuration />` 节点。代码如下：
+
+```
+// XMLConfigBuilder.java
+
+private void parseConfiguration(XNode root) {
+    try {
+        //issue #117 read properties first
+        // <1> 解析 <properties /> 标签
+        propertiesElement(root.evalNode("properties"));
+        // <2> 解析 <settings /> 标签
+        Properties settings = settingsAsProperties(root.evalNode("settings"));
+        // <3> 加载自定义 VFS 实现类
+        loadCustomVfs(settings);
+        // <4> 解析 <typeAliases /> 标签
+        typeAliasesElement(root.evalNode("typeAliases"));
+        // <5> 解析 <plugins /> 标签
+        pluginElement(root.evalNode("plugins"));
+        // <6> 解析 <objectFactory /> 标签
+        objectFactoryElement(root.evalNode("objectFactory"));
+        // <7> 解析 <objectWrapperFactory /> 标签
+        objectWrapperFactoryElement(root.evalNode("objectWrapperFactory"));
+        // <8> 解析 <reflectorFactory /> 标签
+        reflectorFactoryElement(root.evalNode("reflectorFactory"));
+        // <9> 赋值 <settings /> 到 Configuration 属性
+        settingsElement(settings);
+        // read it after objectFactory and objectWrapperFactory issue #631
+        // <10> 解析 <environments /> 标签
+        environmentsElement(root.evalNode("environments"));
+        // <11> 解析 <databaseIdProvider /> 标签
+        databaseIdProviderElement(root.evalNode("databaseIdProvider"));
+        // <12> 解析 <typeHandlers /> 标签
+        typeHandlerElement(root.evalNode("typeHandlers"));
+        // <13> 解析 <mappers /> 标签
+        mapperElement(root.evalNode("mappers"));
+    } catch (Exception e) {
+        throw new BuilderException("Error parsing SQL Mapper Configuration. Cause: " + e, e);
+    }
+}
+```
+
+- `<1>` 处，调用 `#propertiesElement(XNode context)` 方法，解析 `<properties />` 节点。详细解析，见 [「3.3.1 propertiesElement」](https://svip.iocoder.cn/MyBatis/builder-package-1/#) 。
+- `<2>` 处，调用 `#settingsAsProperties(XNode context)` 方法，解析 `<settings />` 节点。详细解析，见 [「3.3.2 settingsAsProperties」](https://svip.iocoder.cn/MyBatis/builder-package-1/#) 。
+- `<3>` 处，调用 `#loadCustomVfs(Properties settings)` 方法，加载自定义 VFS 实现类。详细解析，见 [「3.3.3 loadCustomVfs」](https://svip.iocoder.cn/MyBatis/builder-package-1/#) 。
+- `<4>` 处，调用 `#typeAliasesElement(XNode parent)` 方法，解析 `<typeAliases />` 节点。详细解析，见 [「3.3.4 typeAliasesElement」](https://svip.iocoder.cn/MyBatis/builder-package-1/#) 。
+- `<5>` 处，调用 `#typeAliasesElement(XNode parent)` 方法，解析 `<plugins />` 节点。详细解析，见 [「3.3.5 pluginElement」](https://svip.iocoder.cn/MyBatis/builder-package-1/#) 。
+- `<6>` 处，调用 `#objectFactoryElement(XNode parent)` 方法，解析 `<objectFactory />` 节点。详细解析，见 [「3.3.6 pluginElement」](https://svip.iocoder.cn/MyBatis/builder-package-1/#) 。
+- `<7>` 处，调用 `#objectWrapperFactoryElement(XNode parent)` 方法，解析 `<objectWrapperFactory />` 节点。详细解析，见 [「3.3.7 objectWrapperFactoryElement」](https://svip.iocoder.cn/MyBatis/builder-package-1/#) 。
+- `<8>` 处，调用 `#reflectorFactoryElement(XNode parent)` 方法，解析 `<reflectorFactory />` 节点。详细解析，见 [「3.3.8 reflectorFactoryElement」](https://svip.iocoder.cn/MyBatis/builder-package-1/#) 。
+- `<9>` 处，调用 `#settingsElement(Properties props)` 方法，赋值 `<settings />` 到 Configuration 属性。详细解析，见 [「3.3.9 settingsElement」](https://svip.iocoder.cn/MyBatis/builder-package-1/#) 。
+- `<10>` 处，调用 `#environmentsElement(XNode context)` 方法，解析 `<environments />` 标签。详细解析，见 [「3.3.10 environmentsElement」](https://svip.iocoder.cn/MyBatis/builder-package-1/#) 。
+- `<11>` 处，调用 `#databaseIdProviderElement(XNode context)` 方法，解析 `<databaseIdProvider />` 标签。详细解析，见 [「3.3.11 databaseIdProviderElement」](https://svip.iocoder.cn/MyBatis/builder-package-1/#) 。
+- `<12>` 处，调用 `#typeHandlerElement(XNode context)` 方法，解析 `<typeHandlers />` 标签。详细解析，见 [「3.3.12 typeHandlerElement」](https://svip.iocoder.cn/MyBatis/builder-package-1/#) 。
+- `<13>` 处，调用 `#mapperElement(XNode context)` 方法，解析 `<mappers />` 标签。详细解析，见 [「3.3.13 mapperElement」](https://svip.iocoder.cn/MyBatis/builder-package-1/#) 。
+
+### 3.3.1 propertiesElement
+
+`#propertiesElement(XNode context)` 方法，解析 `<properties />` 节点。大体逻辑如下：
+
+1. 解析 `<properties />` 标签，成 Properties 对象。
+2. 覆盖 `configuration` 中的 Properties 对象到上面的结果。
+3. 设置结果到 `parser` 和 `configuration` 中。
+
+代码如下：
+
+```
+// XMLConfigBuilder.java
+
+private void propertiesElement(XNode context) throws Exception {
+    if (context != null) {
+        // 读取子标签们，为 Properties 对象
+        Properties defaults = context.getChildrenAsProperties();
+        // 读取 resource 和 url 属性
+        String resource = context.getStringAttribute("resource");
+        String url = context.getStringAttribute("url");
+        if (resource != null && url != null) { // resource 和 url 都存在的情况下，抛出 BuilderException 异常
+            throw new BuilderException("The properties element cannot specify both a URL and a resource based property file reference.  Please specify one or the other.");
+        }
+        // 读取本地 Properties 配置文件到 defaults 中。
+        if (resource != null) {
+            defaults.putAll(Resources.getResourceAsProperties(resource));
+            // 读取远程 Properties 配置文件到 defaults 中。
+        } else if (url != null) {
+            defaults.putAll(Resources.getUrlAsProperties(url));
+        }
+        // 覆盖 configuration 中的 Properties 对象到 defaults 中。
+        Properties vars = configuration.getVariables();
+        if (vars != null) {
+            defaults.putAll(vars);
+        }
+        // 设置 defaults 到 parser 和 configuration 中。
+        parser.setVariables(defaults);
+        configuration.setVariables(defaults);
+    }
+}
+```
+
+### 3.3.2 settingsAsProperties
+
+`#settingsElement(Properties props)` 方法，将 `<setting />` 标签解析为 Properties 对象。代码如下：
+
+```
+// XMLConfigBuilder.java
+
+private Properties settingsAsProperties(XNode context) {
+    // 将子标签，解析成 Properties 对象
+    if (context == null) {
+        return new Properties();
+    }
+    Properties props = context.getChildrenAsProperties();
+    // Check that all settings are known to the configuration class
+    // 校验每个属性，在 Configuration 中，有相应的 setting 方法，否则抛出 BuilderException 异常
+    MetaClass metaConfig = MetaClass.forClass(Configuration.class, localReflectorFactory);
+    for (Object key : props.keySet()) {
+        if (!metaConfig.hasSetter(String.valueOf(key))) {
+            throw new BuilderException("The setting " + key + " is not known.  Make sure you spelled it correctly (case sensitive).");
+        }
+    }
+    return props;
+}
+```
+
+### 3.3.3 loadCustomVfs
+
+`#loadCustomVfs(Properties settings)` 方法，加载自定义 VFS 实现类。代码如下：
+
+```
+// XMLConfigBuilder.java
+
+private void loadCustomVfs(Properties props) throws ClassNotFoundException {
+    // 获得 vfsImpl 属性
+    String value = props.getProperty("vfsImpl");
+    if (value != null) {
+        // 使用 , 作为分隔符，拆成 VFS 类名的数组
+        String[] clazzes = value.split(",");
+        // 遍历 VFS 类名的数组
+        for (String clazz : clazzes) {
+            if (!clazz.isEmpty()) {
+                // 获得 VFS 类
+                @SuppressWarnings("unchecked")
+                Class<? extends VFS> vfsImpl = (Class<? extends VFS>) Resources.classForName(clazz);
+                // 设置到 Configuration 中
+                configuration.setVfsImpl(vfsImpl);
+            }
+        }
+    }
+}
+
+// Configuration.java
+
+/**
+ * VFS 实现类
+ */
+protected Class<? extends VFS> vfsImpl;
+
+public void setVfsImpl(Class<? extends VFS> vfsImpl) {
+    if (vfsImpl != null) {
+        // 设置 vfsImpl 属性
+        this.vfsImpl = vfsImpl;
+        // 添加到 VFS 中的自定义 VFS 类的集合
+        VFS.addImplClass(this.vfsImpl);
+    }
+}
+```
+
+### 3.3.4 typeAliasesElement
+
+`#typeAliasesElement(XNode parent)` 方法，解析 `<typeAliases />` 标签，将配置类注册到 `typeAliasRegistry` 中。代码如下：
+
+```
+// XMLConfigBuilder.java
+
+private void typeAliasesElement(XNode parent) {
+    if (parent != null) {
+        // 遍历子节点
+        for (XNode child : parent.getChildren()) {
+            // 指定为包的情况下，注册包下的每个类
+            if ("package".equals(child.getName())) {
+                String typeAliasPackage = child.getStringAttribute("name");
+                configuration.getTypeAliasRegistry().registerAliases(typeAliasPackage);
+            // 指定为类的情况下，直接注册类和别名
+            } else {
+                String alias = child.getStringAttribute("alias");
+                String type = child.getStringAttribute("type");
+                try {
+                    Class<?> clazz = Resources.classForName(type); // 获得类是否存在
+                    // 注册到 typeAliasRegistry 中
+                    if (alias == null) {
+                        typeAliasRegistry.registerAlias(clazz);
+                    } else {
+                        typeAliasRegistry.registerAlias(alias, clazz);
+                    }
+                } catch (ClassNotFoundException e) { // 若类不存在，则抛出 BuilderException 异常
+                    throw new BuilderException("Error registering typeAlias for '" + alias + "'. Cause: " + e, e);
+                }
+            }
+        }
+    }
+}
+```
+
+### 3.3.5 pluginElement
+
+`#pluginElement(XNode parent)` 方法，解析 `<plugins />` 标签，添加到 `Configuration#interceptorChain` 中。代码如下：
+
+```
+// XMLConfigBuilder.java
+
+private void pluginElement(XNode parent) throws Exception {
+    if (parent != null) {
+        // 遍历 <plugins /> 标签
+        for (XNode child : parent.getChildren()) {
+            String interceptor = child.getStringAttribute("interceptor");
+            Properties properties = child.getChildrenAsProperties();
+            // <1> 创建 Interceptor 对象，并设置属性
+            Interceptor interceptorInstance = (Interceptor) resolveClass(interceptor).newInstance();
+            interceptorInstance.setProperties(properties);
+            // <2> 添加到 configuration 中
+            configuration.addInterceptor(interceptorInstance);
+        }
+    }
+}
+```
+
+- `<1>` 处，创建 Interceptor 对象，并设置属性。关于 Interceptor 类，后续文章，详细解析。
+
+- `<2>` 处，调用 `Configuration#addInterceptor(Interceptor interceptor)` 方法，添加到 `configuration` 中。代码如下：
+
+  ```
+  // Configuration.java
+  
+  /**
+   * 拦截器链
+   */
+  protected final InterceptorChain interceptorChain = new InterceptorChain();
+  
+  public void addInterceptor(Interceptor interceptor) {
+      interceptorChain.addInterceptor(interceptor);
+  }
+  ```
+
+  - 关于 InterceptorChain 类，后续文章，详细解析。
+
+### 3.3.6 objectFactoryElement
+
+`#objectFactoryElement(XNode parent)` 方法，解析 `<objectFactory />` 节点。代码如下：
+
+```
+// XMLConfigBuilder.java
+
+private void objectFactoryElement(XNode context) throws Exception {
+    if (context != null) {
+        // 获得 ObjectFactory 的实现类
+        String type = context.getStringAttribute("type");
+        // 获得 Properties 属性
+        Properties properties = context.getChildrenAsProperties();
+        // <1> 创建 ObjectFactory 对象，并设置 Properties 属性
+        ObjectFactory factory = (ObjectFactory) resolveClass(type).newInstance();
+        factory.setProperties(properties);
+        // <2> 设置 Configuration 的 objectFactory 属性
+        configuration.setObjectFactory(factory);
+    }
+}
+```
+
+- `<1>` 处，创建 ObjectFactory 对象，并设置 Properties 属性。
+
+- `<2>` 处，调用 `Configuration#setObjectFactory(ObjectFactory objectFactory)` 方法，设置 Configuration 的 `objectFactory` 属性。代码如下：
+
+  ```
+  // Configuration.java
+  
+  /**
+   * ObjectFactory 对象
+   */
+  protected ObjectFactory objectFactory = new DefaultObjectFactory();
+  
+  public void setObjectFactory(ObjectFactory objectFactory) {
+      this.objectFactory = objectFactory;
+  }
+  ```
+
+### 3.3.7 objectWrapperFactoryElement
+
+`#objectWrapperFactoryElement(XNode context)` 方法，解析 `<objectWrapperFactory />` 节点。代码如下：
+
+```
+// XMLConfigBuilder.java
+
+private void objectWrapperFactoryElement(XNode context) throws Exception {
+    if (context != null) {
+        // 获得 ObjectFactory 的实现类
+        String type = context.getStringAttribute("type");
+        // <1> 创建 ObjectWrapperFactory 对象
+        ObjectWrapperFactory factory = (ObjectWrapperFactory) resolveClass(type).newInstance();
+        // 设置 Configuration 的 objectWrapperFactory 属性
+        configuration.setObjectWrapperFactory(factory);
+    }
+}
+```
+
+- `<1>` 处，创建 ObjectWrapperFactory 对象。
+
+- `<2>` 处，调用 `Configuration#setObjectWrapperFactory(ObjectWrapperFactory objectWrapperFactory)` 方法，设置 Configuration 的 `objectWrapperFactory` 属性。代码如下：
+
+  ```
+  // Configuration.java
+  
+  /**
+   * ObjectWrapperFactory 对象
+   */
+  protected ObjectWrapperFactory objectWrapperFactory = new DefaultObjectWrapperFactory();
+  
+  public void setObjectWrapperFactory(ObjectWrapperFactory objectWrapperFactory) {
+      this.objectWrapperFactory = objectWrapperFactory;
+  }
+  ```
+
+### 3.3.8 reflectorFactoryElement
+
+`#reflectorFactoryElement(XNode parent)` 方法，解析 `<reflectorFactory />` 节点。代码如下：
+
+```
+// XMLConfigBuilder.java
+
+private void reflectorFactoryElement(XNode context) throws Exception {
+    if (context != null) {
+        // 获得 ReflectorFactory 的实现类
+        String type = context.getStringAttribute("type");
+        // 创建 ReflectorFactory 对象
+        ReflectorFactory factory = (ReflectorFactory) resolveClass(type).newInstance();
+        // 设置 Configuration 的 reflectorFactory 属性
+        configuration.setReflectorFactory(factory);
+    }
+}
+```
+
+- `<1>` 处，创建 ReflectorFactory 对象。
+
+- `<2>` 处，调用 `Configuration#setReflectorFactory(ReflectorFactory reflectorFactory)` 方法，设置 Configuration 的 `reflectorFactory` 属性。代码如下：
+
+  ```
+  // Configuration.java
+  
+  /**
+   * ReflectorFactory 对象
+   */
+  protected ReflectorFactory reflectorFactory = new DefaultReflectorFactory();
+  
+  public void setReflectorFactory(ReflectorFactory reflectorFactory) {
+      this.reflectorFactory = reflectorFactory;
+  }
+  ```
+
+### 3.3.9 settingsElement
+
+`#settingsElement(Properties props)` 方法，赋值 `<settings />` 到 Configuration 属性。代码如下：
+
+```
+// XMLConfigBuilder.java
+
+private void settingsElement(Properties props) throws Exception {
+    configuration.setAutoMappingBehavior(AutoMappingBehavior.valueOf(props.getProperty("autoMappingBehavior", "PARTIAL")));
+    configuration.setAutoMappingUnknownColumnBehavior(AutoMappingUnknownColumnBehavior.valueOf(props.getProperty("autoMappingUnknownColumnBehavior", "NONE")));
+    configuration.setCacheEnabled(booleanValueOf(props.getProperty("cacheEnabled"), true));
+    configuration.setProxyFactory((ProxyFactory) createInstance(props.getProperty("proxyFactory")));
+    configuration.setLazyLoadingEnabled(booleanValueOf(props.getProperty("lazyLoadingEnabled"), false));
+    configuration.setAggressiveLazyLoading(booleanValueOf(props.getProperty("aggressiveLazyLoading"), false));
+    configuration.setMultipleResultSetsEnabled(booleanValueOf(props.getProperty("multipleResultSetsEnabled"), true));
+    configuration.setUseColumnLabel(booleanValueOf(props.getProperty("useColumnLabel"), true));
+    configuration.setUseGeneratedKeys(booleanValueOf(props.getProperty("useGeneratedKeys"), false));
+    configuration.setDefaultExecutorType(ExecutorType.valueOf(props.getProperty("defaultExecutorType", "SIMPLE")));
+    configuration.setDefaultStatementTimeout(integerValueOf(props.getProperty("defaultStatementTimeout"), null));
+    configuration.setDefaultFetchSize(integerValueOf(props.getProperty("defaultFetchSize"), null));
+    configuration.setMapUnderscoreToCamelCase(booleanValueOf(props.getProperty("mapUnderscoreToCamelCase"), false));
+    configuration.setSafeRowBoundsEnabled(booleanValueOf(props.getProperty("safeRowBoundsEnabled"), false));
+    configuration.setLocalCacheScope(LocalCacheScope.valueOf(props.getProperty("localCacheScope", "SESSION")));
+    configuration.setJdbcTypeForNull(JdbcType.valueOf(props.getProperty("jdbcTypeForNull", "OTHER")));
+    configuration.setLazyLoadTriggerMethods(stringSetValueOf(props.getProperty("lazyLoadTriggerMethods"), "equals,clone,hashCode,toString"));
+    configuration.setSafeResultHandlerEnabled(booleanValueOf(props.getProperty("safeResultHandlerEnabled"), true));
+    configuration.setDefaultScriptingLanguage(resolveClass(props.getProperty("defaultScriptingLanguage")));
+    @SuppressWarnings("unchecked")
+    Class<? extends TypeHandler> typeHandler = resolveClass(props.getProperty("defaultEnumTypeHandler"));
+    configuration.setDefaultEnumTypeHandler(typeHandler);
+    configuration.setCallSettersOnNulls(booleanValueOf(props.getProperty("callSettersOnNulls"), false));
+    configuration.setUseActualParamName(booleanValueOf(props.getProperty("useActualParamName"), true));
+    configuration.setReturnInstanceForEmptyRow(booleanValueOf(props.getProperty("returnInstanceForEmptyRow"), false));
+    configuration.setLogPrefix(props.getProperty("logPrefix"));
+    @SuppressWarnings("unchecked")
+    Class<? extends Log> logImpl = resolveClass(props.getProperty("logImpl"));
+    configuration.setLogImpl(logImpl);
+    configuration.setConfigurationFactory(resolveClass(props.getProperty("configurationFactory")));
+}
+```
+
+- 属性比较多，瞟一眼就行。
+
+### 3.3.10 environmentsElement
+
+`#environmentsElement(XNode context)` 方法，解析 `<environments />` 标签。代码如下：
+
+```
+// XMLConfigBuilder.java
+
+private void environmentsElement(XNode context) throws Exception {
+    if (context != null) {
+        // <1> environment 属性非空，从 default 属性获得
+        if (environment == null) {
+            environment = context.getStringAttribute("default");
+        }
+        // 遍历 XNode 节点
+        for (XNode child : context.getChildren()) {
+            // <2> 判断 environment 是否匹配
+            String id = child.getStringAttribute("id");
+            if (isSpecifiedEnvironment(id)) {
+                // <3> 解析 `<transactionManager />` 标签，返回 TransactionFactory 对象
+                TransactionFactory txFactory = transactionManagerElement(child.evalNode("transactionManager"));
+                // <4> 解析 `<dataSource />` 标签，返回 DataSourceFactory 对象
+                DataSourceFactory dsFactory = dataSourceElement(child.evalNode("dataSource"));
+                DataSource dataSource = dsFactory.getDataSource();
+                // <5> 创建 Environment.Builder 对象
+                Environment.Builder environmentBuilder = new Environment.Builder(id)
+                        .transactionFactory(txFactory)
+                        .dataSource(dataSource);
+                // <6> 构造 Environment 对象，并设置到 configuration 中
+                configuration.setEnvironment(environmentBuilder.build());
+            }
+        }
+    }
+}
+```
+
+- `<1>` 处，若 `environment` 属性非空，从 `default` 属性种获得 `environment` 属性。
+
+- `<2>` 处，遍历 XNode 节点，获得其 `id` 属性，后调用 `#isSpecifiedEnvironment(String id)` 方法，判断 `environment` 和 `id` 是否匹配。代码如下：
+
+  ```
+  // XMLConfigBuilder.java
+  
+  private boolean isSpecifiedEnvironment(String id) {
+      if (environment == null) {
+          throw new BuilderException("No environment specified.");
+      } else if (id == null) {
+          throw new BuilderException("Environment requires an id attribute.");
+      } else if (environment.equals(id)) { // 相等
+          return true;
+      }
+      return false;
+  }
+  ```
+
+- `<3>` 处，调用 `#transactionManagerElement(XNode context)` 方法，解析 `<transactionManager />` 标签，返回 TransactionFactory 对象。代码如下：
+
+  ```
+  // XMLConfigBuilder.java
+  
+  private TransactionFactory transactionManagerElement(XNode context) throws Exception {
+      if (context != null) {
+          // 获得 TransactionFactory 的类
+          String type = context.getStringAttribute("type");
+          // 获得 Properties 属性
+          Properties props = context.getChildrenAsProperties();
+          // 创建 TransactionFactory 对象，并设置属性
+          TransactionFactory factory = (TransactionFactory) resolveClass(type).newInstance();
+          factory.setProperties(props);
+          return factory;
+      }
+      throw new BuilderException("Environment declaration requires a TransactionFactory.");
+  }
+  ```
+
+- `<4>` 处，调用 `#dataSourceElement(XNode context)` 方法，解析 `<dataSource />` 标签，返回 DataSourceFactory 对象，而后返回 DataSource 对象。代码如下：
+
+  ```
+  // XMLConfigBuilder.java
+  
+  private DataSourceFactory dataSourceElement(XNode context) throws Exception {
+      if (context != null) {
+          // 获得 DataSourceFactory 的类
+          String type = context.getStringAttribute("type");
+          // 获得 Properties 属性
+          Properties props = context.getChildrenAsProperties();
+          // 创建 DataSourceFactory 对象，并设置属性
+          DataSourceFactory factory = (DataSourceFactory) resolveClass(type).newInstance();
+          factory.setProperties(props);
+          return factory;
+      }
+      throw new BuilderException("Environment declaration requires a DataSourceFactory.");
+  }
+  ```
+
+- `<5>` 处，创建 Environment.Builder 对象。
+
+- `<6>` 处，构造 Environment 对象，并设置到 `configuration` 中。代码如下：
+
+  ```
+  // Configuration.java
+  
+  /**
+   * DB Environment 对象
+   */
+  protected Environment environment;
+  
+  public void setEnvironment(Environment environment) {
+      this.environment = environment;
+  }
+  ```
+
+#### 3.3.10.1 Environment
+
+`org.apache.ibatis.mapping.Environment` ，DB 环境。代码如下：
+
+```
+// Environment.java
+
+public final class Environment {
+
+    /**
+     * 环境变好
+     */
+    private final String id;
+    /**
+     * TransactionFactory 对象
+     */
+    private final TransactionFactory transactionFactory;
+    /**
+     * DataSource 对象
+     */
+    private final DataSource dataSource;
+
+    public Environment(String id, TransactionFactory transactionFactory, DataSource dataSource) {
+        if (id == null) {
+            throw new IllegalArgumentException("Parameter 'id' must not be null");
+        }
+        if (transactionFactory == null) {
+            throw new IllegalArgumentException("Parameter 'transactionFactory' must not be null");
+        }
+        this.id = id;
+        if (dataSource == null) {
+            throw new IllegalArgumentException("Parameter 'dataSource' must not be null");
+        }
+        this.transactionFactory = transactionFactory;
+        this.dataSource = dataSource;
+    }
+
+    /**
+     * 构造器
+     */
+    public static class Builder {
+
+        /**
+         * 环境变好
+         */
+        private String id;
+        /**
+         * TransactionFactory 对象
+         */
+        private TransactionFactory transactionFactory;
+        /**
+         * DataSource 对象
+         */
+        private DataSource dataSource;
+
+        public Builder(String id) {
+            this.id = id;
+        }
+
+        public Builder transactionFactory(TransactionFactory transactionFactory) {
+            this.transactionFactory = transactionFactory;
+            return this;
+        }
+
+        public Builder dataSource(DataSource dataSource) {
+            this.dataSource = dataSource;
+            return this;
+        }
+
+        public String id() {
+            return this.id;
+        }
+
+        public Environment build() {
+            return new Environment(this.id, this.transactionFactory, this.dataSource);
+        }
+
+    }
+
+    public String getId() {
+        return this.id;
+    }
+
+    public TransactionFactory getTransactionFactory() {
+        return this.transactionFactory;
+    }
+
+    public DataSource getDataSource() {
+        return this.dataSource;
+    }
+
+}
+```
+
+### 3.3.11 databaseIdProviderElement
+
+`#databaseIdProviderElement(XNode context)` 方法，解析 `<databaseIdProvider />` 标签。代码如下：
+
+```
+// XMLConfigBuilder.java
+
+private void databaseIdProviderElement(XNode context) throws Exception {
+    DatabaseIdProvider databaseIdProvider = null;
+    if (context != null) {
+        // <1> 获得 DatabaseIdProvider 的类
+        String type = context.getStringAttribute("type");
+        // awful patch to keep backward compatibility 保持兼容
+        if ("VENDOR".equals(type)) {
+            type = "DB_VENDOR";
+        }
+        // <2> 获得 Properties 对象
+        Properties properties = context.getChildrenAsProperties();
+        // <3> 创建 DatabaseIdProvider 对象，并设置对应的属性
+        databaseIdProvider = (DatabaseIdProvider) resolveClass(type).newInstance();
+        databaseIdProvider.setProperties(properties);
+    }
+    Environment environment = configuration.getEnvironment();
+    if (environment != null && databaseIdProvider != null) {
+        // <4> 获得对应的 databaseId 编号
+        String databaseId = databaseIdProvider.getDatabaseId(environment.getDataSource());
+        // <5> 设置到 configuration 中
+        configuration.setDatabaseId(databaseId);
+    }
+}
+```
+
+- 不了解的胖友，可以先看看 [《MyBatis 文档 —— XML 映射配置文件 —— databaseIdProvider 数据库厂商标识》](http://www.mybatis.org/mybatis-3/zh/configuration.html#databaseIdProvider) 。
+
+- `<1>` 处，获得 DatabaseIdProvider 的类。
+
+- `<2>` 处，获得 Properties 对象。
+
+- `<3>` 处，创建 DatabaseIdProvider 对象，并设置对应的属性。
+
+- `<4>` 处，调用 `DatabaseIdProvider#getDatabaseId(DataSource dataSource)` 方法，获得对应的 `databaseId` **标识**。
+
+- `<5>` 处，设置到 `configuration` 中。代码如下：
+
+  ```
+  // Configuration.java
+  
+  /**
+   * 数据库标识
+   */
+  protected String databaseId;
+  
+  public void setDatabaseId(String databaseId) {
+      this.databaseId = databaseId;
+  }
+  ```
+
+#### 3.3.11.1 DatabaseIdProvider
+
+`org.apache.ibatis.mapping.DatabaseIdProvider` ，数据库标识提供器接口。代码如下：
+
+```
+public interface DatabaseIdProvider {
+
+    /**
+     * 设置属性
+     *
+     * @param p Properties 对象
+     */
+    void setProperties(Properties p);
+
+    /**
+     * 获得数据库标识
+     *
+     * @param dataSource 数据源
+     * @return 数据库标识
+     * @throws SQLException 当 DB 发生异常时
+     */
+    String getDatabaseId(DataSource dataSource) throws SQLException;
+
+}
+```
+
+#### 3.3.11.2 VendorDatabaseIdProvider
+
+`org.apache.ibatis.mapping.VendorDatabaseIdProvider` ，实现 DatabaseIdProvider 接口，供应商数据库标识提供器实现类。
+
+**① 构造方法**
+
+```
+// VendorDatabaseIdProvider.java
+
+/**
+ * Properties 对象
+ */
+private Properties properties;
+
+@Override
+public String getDatabaseId(DataSource dataSource) {
+    if (dataSource == null) {
+        throw new NullPointerException("dataSource cannot be null");
+    }
+    try {
+        return getDatabaseName(dataSource);
+    } catch (Exception e) {
+        log.error("Could not get a databaseId from dataSource", e);
+    }
+    return null;
+}
+
+@Override
+public void setProperties(Properties p) {
+    this.properties = p;
+}
+```
+
+**② 获得数据库标识**
+
+`#getDatabaseId(DataSource dataSource)` 方法，代码如下：
+
+```
+// VendorDatabaseIdProvider.java
+
+@Override
+public String getDatabaseId(DataSource dataSource) {
+    if (dataSource == null) {
+        throw new NullPointerException("dataSource cannot be null");
+    }
+    try {
+        // 获得数据库标识
+        return getDatabaseName(dataSource);
+    } catch (Exception e) {
+        log.error("Could not get a databaseId from dataSource", e);
+    }
+    return null;
+}
+
+private String getDatabaseName(DataSource dataSource) throws SQLException {
+    // <1> 获得数据库产品名
+    String productName = getDatabaseProductName(dataSource);
+    if (this.properties != null) {
+        for (Map.Entry<Object, Object> property : properties.entrySet()) {
+            // 如果产品名包含 KEY ，则返回对应的  VALUE
+            if (productName.contains((String) property.getKey())) {
+                return (String) property.getValue();
+            }
+        }
+        // no match, return null
+        return null;
+    }
+    // <3> 不存在 properties ，则直接返回 productName
+    return productName;
+}
+```
+
+- `<1>` 处，调用 `#getDatabaseProductName(DataSource dataSource)` 方法，获得数据库产品名。代码如下：
+
+  ```
+  // VendorDatabaseIdProvider.java
+  
+  private String getDatabaseProductName(DataSource dataSource) throws SQLException {
+      try (Connection con = dataSource.getConnection()) {
+          // 获得数据库连接
+          DatabaseMetaData metaData = con.getMetaData();
+          // 获得数据库产品名
+          return metaData.getDatabaseProductName();
+      }
+  }
+  ```
+
+  - 通过从 Connection 获得数据库产品名。
+
+- `<2>` 处，如果 `properties` 非空，则从 `properties` 中匹配 `KEY` ？若成功，则返回 `VALUE` ，否则，返回 `null` 。
+
+- `<3>` 处，如果 `properties` 为空，则直接返回 `productName` 。
+
+### 3.3.12 typeHandlerElement
+
+`#typeHandlerElement(XNode parent)` 方法，解析 `<typeHandlers />` 标签。代码如下：
+
+```
+// XMLConfigBuilder.java
+
+private void typeHandlerElement(XNode parent) throws Exception {
+    if (parent != null) {
+        // 遍历子节点
+        for (XNode child : parent.getChildren()) {
+            // <1> 如果是 package 标签，则扫描该包
+            if ("package".equals(child.getName())) {
+                String typeHandlerPackage = child.getStringAttribute("name");
+                typeHandlerRegistry.register(typeHandlerPackage);
+            // <2> 如果是 typeHandler 标签，则注册该 typeHandler 信息
+            } else {
+                // 获得 javaType、jdbcType、handler
+                String javaTypeName = child.getStringAttribute("javaType");
+                String jdbcTypeName = child.getStringAttribute("jdbcType");
+                String handlerTypeName = child.getStringAttribute("handler");
+                Class<?> javaTypeClass = resolveClass(javaTypeName);
+                JdbcType jdbcType = resolveJdbcType(jdbcTypeName);
+                Class<?> typeHandlerClass = resolveClass(handlerTypeName); // 非空
+                // 注册 typeHandler
+                if (javaTypeClass != null) {
+                    if (jdbcType == null) {
+                        typeHandlerRegistry.register(javaTypeClass, typeHandlerClass);
+                    } else {
+                        typeHandlerRegistry.register(javaTypeClass, jdbcType, typeHandlerClass);
+                    }
+                } else {
+                    typeHandlerRegistry.register(typeHandlerClass);
+                }
+            }
+        }
+    }
+}
+```
+
+- 遍历子节点，分别处理 `<1>` 是 `<package />` 和 `<2>` 是 `<typeHandler />` 两种标签的情况。逻辑比较简单，最终都是注册到 `typeHandlerRegistry` 中。
+
+### 3.3.13 mapperElement
+
+`#mapperElement(XNode context)` 方法，解析 `<mappers />` 标签。代码如下：
+
+```
+// XMLConfigBuilder.java
+
+private void mapperElement(XNode parent) throws Exception {
+    if (parent != null) {
+        // <0> 遍历子节点
+        for (XNode child : parent.getChildren()) {
+            // <1> 如果是 package 标签，则扫描该包
+            if ("package".equals(child.getName())) {
+                // 获得包名
+                String mapperPackage = child.getStringAttribute("name");
+                // 添加到 configuration 中
+                configuration.addMappers(mapperPackage);
+            // 如果是 mapper 标签，
+            } else {
+                // 获得 resource、url、class 属性
+                String resource = child.getStringAttribute("resource");
+                String url = child.getStringAttribute("url");
+                String mapperClass = child.getStringAttribute("class");
+                // <2> 使用相对于类路径的资源引用
+                if (resource != null && url == null && mapperClass == null) {
+                    ErrorContext.instance().resource(resource);
+                    // 获得 resource 的 InputStream 对象
+                    InputStream inputStream = Resources.getResourceAsStream(resource);
+                    // 创建 XMLMapperBuilder 对象
+                    XMLMapperBuilder mapperParser = new XMLMapperBuilder(inputStream, configuration, resource, configuration.getSqlFragments());
+                    // 执行解析
+                    mapperParser.parse();
+                // <3> 使用完全限定资源定位符（URL）
+                } else if (resource == null && url != null && mapperClass == null) {
+                    ErrorContext.instance().resource(url);
+                    // 获得 url 的 InputStream 对象
+                    InputStream inputStream = Resources.getUrlAsStream(url);
+                    // 创建 XMLMapperBuilder 对象
+                    XMLMapperBuilder mapperParser = new XMLMapperBuilder(inputStream, configuration, url, configuration.getSqlFragments());
+                    // 执行解析
+                    mapperParser.parse();
+                // <4> 使用映射器接口实现类的完全限定类名
+                } else if (resource == null && url == null && mapperClass != null) {
+                    // 获得 Mapper 接口
+                    Class<?> mapperInterface = Resources.classForName(mapperClass);
+                    // 添加到 configuration 中
+                    configuration.addMapper(mapperInterface);
+                } else {
+                    throw new BuilderException("A mapper element may only specify a url, resource or class, but not more than one.");
+                }
+            }
+        }
+    }
+}
+```
+
+- `<0>` 处，遍历子节点，处理每一个节点。根据节点情况，会分成 `<1>`、`<2>`、`<3>`、`<4>` 种情况，并且第一个是处理 `<package />` 标签，后三个是处理 `<mapper />` 标签。
+
+- `<1>` 处，如果是 `<package />` 标签，则获得 `name` 报名，并调用 `Configuration#addMappers(String packageName)` 方法，扫描该包下的所有 Mapper 接口。代码如下：
+
+  ```
+  // Configuration.java
+  
+  /**
+   * MapperRegistry 对象
+   */
+  protected final MapperRegistry mapperRegistry = new MapperRegistry(this);
+  
+  public void addMappers(String packageName) {
+      // 扫描该包下所有的 Mapper 接口，并添加到 mapperRegistry 中
+      mapperRegistry.addMappers(packageName);
+  }
+  ```
+
+- `<4>` 处，如果是 `mapperClass` 非空，则是使用映射器接口实现类的完全限定类名，则获得 Mapper 接口，并调用 `Configuration#addMapper(Class<T> type)` 方法，直接添加到 `configuration` 中。代码如下：
+
+  ```
+  // Configuration.java
+  
+  public <T> void addMapper(Class<T> type) {
+      mapperRegistry.addMapper(type);
+  }
+  ```
+
+  - 实际上，`<1>` 和 `<4>` 是相似情况，差别在于前者需要扫描，才能获取到所有的 Mapper 接口，而后者明确知道是哪个 Mapper 接口。
+
+- `<2>` 处，如果是 `resource` 非空，则是使用相对于类路径的资源引用，则需要创建 XMLMapperBuilder 对象，并调用 `XMLMapperBuilder#parse()` 方法，执行解析 Mapper XML 配置。执行之后，我们就能知道这个 Mapper XML 配置对应的 Mapper 接口。关于 XMLMapperBuilder 类，我们放在下一篇博客中，详细解析。
+
+- `<3>` 处，如果是 `url` 非空，则是使用完全限定资源定位符（URL），情况和 `<2>` 是类似的。
+
+# 666. 彩蛋
+
+一篇体力活的文章，有点无趣哈。
+
+参考和推荐如下文章：
+
+- 祖大俊 [《Mybatis3.3.x技术内幕（八）：Mybatis初始化流程（上）》](https://my.oschina.net/zudajun/blog/668738)
+- 田小波 [《MyBatis 源码分析 - 配置文件解析过程》](https://www.tianxiaobo.com/2018/07/20/MyBatis-源码分析-配置文件解析过程/)
+- 无忌 [《MyBatis 源码解读之配置》](https://my.oschina.net/wenjinglian/blog/1833051)
+- 徐郡明 [《MyBatis 技术内幕》](https://item.jd.com/12125531.html) 的 [「3.1 MyBatis 初始化」](https://svip.iocoder.cn/MyBatis/builder-package-1/#) 小节
\ No newline at end of file
diff --git a/mybatis/16-mybatis-MyBatis 初始化（二）之加载 Mapper 映射配置文件.assets/01.png b/mybatis/16-mybatis-MyBatis 初始化（二）之加载 Mapper 映射配置文件.assets/01.png
new file mode 100644
index 0000000..9fc30b2
Binary files /dev/null and b/mybatis/16-mybatis-MyBatis 初始化（二）之加载 Mapper 映射配置文件.assets/01.png differ
diff --git a/mybatis/16-mybatis-MyBatis 初始化（二）之加载 Mapper 映射配置文件.assets/02.png b/mybatis/16-mybatis-MyBatis 初始化（二）之加载 Mapper 映射配置文件.assets/02.png
new file mode 100644
index 0000000..9dd04f8
Binary files /dev/null and b/mybatis/16-mybatis-MyBatis 初始化（二）之加载 Mapper 映射配置文件.assets/02.png differ
diff --git a/mybatis/16-mybatis-MyBatis 初始化（二）之加载 Mapper 映射配置文件.md b/mybatis/16-mybatis-MyBatis 初始化（二）之加载 Mapper 映射配置文件.md
new file mode 100644
index 0000000..1e01255
--- /dev/null
+++ b/mybatis/16-mybatis-MyBatis 初始化（二）之加载 Mapper 映射配置文件.md	
@@ -0,0 +1,1436 @@
+# 精尽 MyBatis 源码分析 —— MyBatis 初始化（二）之加载 Mapper 映射配置文件
+
+# 1. 概述
+
+本文接 [《精尽 MyBatis 源码分析 —— MyBatis 初始化（一）之加载 mybatis-config》](http://svip.iocoder.cn/MyBatis/builder-package-1) 一文，来分享 MyBatis 初始化的第二步，**加载 Mapper 映射配置文件**。而这个步骤的入口是 XMLMapperBuilder 。下面，我们一起来看看它的代码实现。
+
+> FROM [《Mybatis3.3.x技术内幕（八）：Mybatis初始化流程（上）》](https://my.oschina.net/zudajun/blog/668738)
+>
+> [![解析](16-mybatis-MyBatis 初始化（二）之加载 Mapper 映射配置文件.assets/01.png)](http://static.iocoder.cn/images/MyBatis/2020_02_13/01.png)解析
+
+- 上图，就是 Mapper 映射配置文件的解析结果。
+
+# 2. XMLMapperBuilder
+
+`org.apache.ibatis.builder.xml.XMLMapperBuilder` ，继承 BaseBuilder 抽象类，Mapper XML 配置构建器，主要负责解析 Mapper 映射配置文件。
+
+## 2.1 构造方法
+
+```
+// XMLMapperBuilder.java
+
+/**
+ * 基于 Java XPath 解析器
+ */
+private final XPathParser parser;
+/**
+ * Mapper 构造器助手
+ */
+private final MapperBuilderAssistant builderAssistant;
+/**
+ * 可被其他语句引用的可重用语句块的集合
+ *
+ * 例如：<sql id="userColumns"> ${alias}.id,${alias}.username,${alias}.password </sql>
+ */
+private final Map<String, XNode> sqlFragments;
+/**
+ * 资源引用的地址
+ */
+private final String resource;
+
+public XMLMapperBuilder(InputStream inputStream, Configuration configuration, String resource, Map<String, XNode> sqlFragments, String namespace) {
+    this(inputStream, configuration, resource, sqlFragments);
+    this.builderAssistant.setCurrentNamespace(namespace);
+}
+
+public XMLMapperBuilder(InputStream inputStream, Configuration configuration, String resource, Map<String, XNode> sqlFragments) {
+    this(new XPathParser(inputStream, true, configuration.getVariables(), new XMLMapperEntityResolver()),
+            configuration, resource, sqlFragments);
+}
+
+private XMLMapperBuilder(XPathParser parser, Configuration configuration, String resource, Map<String, XNode> sqlFragments) {
+    super(configuration);
+    // 创建 MapperBuilderAssistant 对象
+    this.builderAssistant = new MapperBuilderAssistant(configuration, resource);
+    this.parser = parser;
+    this.sqlFragments = sqlFragments;
+    this.resource = resource;
+}
+```
+
+- `builderAssistant` 属性，MapperBuilderAssistant 对象，是 XMLMapperBuilder 和 MapperAnnotationBuilder 的小助手，提供了一些公用的方法，例如创建 ParameterMap、MappedStatement 对象等等。关于 MapperBuilderAssistant 类，可见 [「3. MapperBuilderAssistant」](https://svip.iocoder.cn/MyBatis/builder-package-2/#) 。
+
+## 2.2 parse
+
+`#parse()` 方法，解析 Mapper XML 配置文件。代码如下：
+
+```
+// XMLMapperBuilder.java
+
+public void parse() {
+    // <1> 判断当前 Mapper 是否已经加载过
+    if (!configuration.isResourceLoaded(resource)) {
+        // <2> 解析 `<mapper />` 节点
+        configurationElement(parser.evalNode("/mapper"));
+        // <3> 标记该 Mapper 已经加载过
+        configuration.addLoadedResource(resource);
+        // <4> 绑定 Mapper
+        bindMapperForNamespace();
+    }
+
+    // <5> 解析待定的 <resultMap /> 节点
+    parsePendingResultMaps();
+    // <6> 解析待定的 <cache-ref /> 节点
+    parsePendingCacheRefs();
+    // <7> 解析待定的 SQL 语句的节点
+    parsePendingStatements();
+}
+```
+
+- `<1>` 处，调用 `Configuration#isResourceLoaded(String resource)` 方法，判断当前 Mapper 是否已经加载过。代码如下：
+
+  ```
+  // Configuration.java
+  
+  /**
+   * 已加载资源( Resource )集合
+   */
+  protected final Set<String> loadedResources = new HashSet<>();
+  
+  public boolean isResourceLoaded(String resource) {
+      return loadedResources.contains(resource);
+  }
+  ```
+
+- `<3>` 处，调用 `Configuration#addLoadedResource(String resource)` 方法，标记该 Mapper 已经加载过。代码如下：
+
+  ```
+  // Configuration.java
+  
+  public void addLoadedResource(String resource) {
+      loadedResources.add(resource);
+  }
+  ```
+
+- `<2>` 处，调用 `#configurationElement(XNode context)` 方法，解析 `<mapper />` 节点。详细解析，见 [「2.3 configurationElement」](https://svip.iocoder.cn/MyBatis/builder-package-2/#) 。
+
+- `<4>` 处，调用 `#bindMapperForNamespace()` 方法，绑定 Mapper 。详细解析，
+
+- `<5>`、`<6>`、`<7>` 处，解析对应的**待定**的节点。详细解析，见 [「2.5 parsePendingXXX」](https://svip.iocoder.cn/MyBatis/builder-package-2/#) 。
+
+## 2.3 configurationElement
+
+`#configurationElement(XNode context)` 方法，解析 `<mapper />` 节点。代码如下：
+
+```
+// XMLMapperBuilder.java
+
+private void configurationElement(XNode context) {
+    try {
+        // <1> 获得 namespace 属性
+        String namespace = context.getStringAttribute("namespace");
+        if (namespace == null || namespace.equals("")) {
+            throw new BuilderException("Mapper's namespace cannot be empty");
+        }
+        // <1> 设置 namespace 属性
+        builderAssistant.setCurrentNamespace(namespace);
+        // <2> 解析 <cache-ref /> 节点
+        cacheRefElement(context.evalNode("cache-ref"));
+        // <3> 解析 <cache /> 节点
+        cacheElement(context.evalNode("cache"));
+        // 已废弃！老式风格的参数映射。内联参数是首选,这个元素可能在将来被移除，这里不会记录。
+        parameterMapElement(context.evalNodes("/mapper/parameterMap"));
+        // <4> 解析 <resultMap /> 节点们
+        resultMapElements(context.evalNodes("/mapper/resultMap"));
+        // <5> 解析 <sql /> 节点们
+        sqlElement(context.evalNodes("/mapper/sql"));
+        // <6> 解析 <select /> <insert /> <update /> <delete /> 节点们
+        buildStatementFromContext(context.evalNodes("select|insert|update|delete"));
+    } catch (Exception e) {
+        throw new BuilderException("Error parsing Mapper XML. The XML location is '" + resource + "'. Cause: " + e, e);
+    }
+}
+```
+
+- `<1>` 处，获得 `namespace` 属性，并设置到 MapperAnnotationBuilder 中。
+- `<2>` 处，调用 `#cacheRefElement(XNode context)` 方法，解析 `<cache-ref />` 节点。详细解析，见 [「2.3.1 cacheElement」](https://svip.iocoder.cn/MyBatis/builder-package-2/#) 。
+- `<3>` 处，调用 `#cacheElement(XNode context)` 方法，解析 `cache />` 标签。详细解析，见 [「2.3.2 cacheElement」](https://svip.iocoder.cn/MyBatis/builder-package-2/#) 。
+- `<4>` 处，调用 `#resultMapElements(List<XNode> list)` 方法，解析 `<resultMap />` 节点们。详细解析，见 [「2.3.3 resultMapElements」](https://svip.iocoder.cn/MyBatis/builder-package-2/#) 。
+- `<5>` 处，调用 `#sqlElement(List<XNode> list)` 方法，解析 `<sql />` 节点们。详细解析，见 [「2.3.4 sqlElement」](https://svip.iocoder.cn/MyBatis/builder-package-2/#) 。
+- `<6>` 处，调用 `#buildStatementFromContext(List<XNode> list)` 方法，解析 `<select />`、`<insert />`、`<update />`、`<delete />` 节点们。详细解析，见 [「2.3.5 buildStatementFromContext」](https://svip.iocoder.cn/MyBatis/builder-package-2/#) 。
+
+### 2.3.1 cacheElement
+
+`#cacheRefElement(XNode context)` 方法，解析 `<cache-ref />` 节点。代码如下：
+
+```
+// XMLMapperBuilder.java
+
+private void cacheRefElement(XNode context) {
+    if (context != null) {
+        // <1> 获得指向的 namespace 名字，并添加到 configuration 的 cacheRefMap 中
+        configuration.addCacheRef(builderAssistant.getCurrentNamespace(), context.getStringAttribute("namespace"));
+        // <2> 创建 CacheRefResolver 对象，并执行解析
+        CacheRefResolver cacheRefResolver = new CacheRefResolver(builderAssistant, context.getStringAttribute("namespace"));
+        try {
+            cacheRefResolver.resolveCacheRef();
+        } catch (IncompleteElementException e) {
+            // <3> 解析失败，添加到 configuration 的 incompleteCacheRefs 中
+            configuration.addIncompleteCacheRef(cacheRefResolver);
+        }
+    }
+}
+```
+
+- 示例如下：
+
+  ```
+  <cache-ref namespace="com.someone.application.data.SomeMapper"/>
+  ```
+
+- `<1>` 处，获得指向的 `namespace` 名字，并调用 `Configuration#addCacheRef(String namespace, String referencedNamespace)` 方法，添加到 `configuration` 的 `cacheRefMap` 中。代码如下：
+
+  ```
+  // Configuration.java
+  
+  /**
+   * A map holds cache-ref relationship. The key is the namespace that
+   * references a cache bound to another namespace and the value is the
+   * namespace which the actual cache is bound to.
+   *
+   * Cache 指向的映射
+   *
+   * @see #addCacheRef(String, String)
+   * @see org.apache.ibatis.builder.xml.XMLMapperBuilder#cacheRefElement(XNode)
+   */
+  protected final Map<String, String> cacheRefMap = new HashMap<>();
+  
+  public void addCacheRef(String namespace, String referencedNamespace) {
+      cacheRefMap.put(namespace, referencedNamespace);
+  }
+  ```
+
+- `<2>` 处，创建 CacheRefResolver 对象，并调用 `CacheRefResolver#resolveCacheRef()` 方法，执行解析。关于 CacheRefResolver ，在 [「2.3.1.1 CacheRefResolver」](https://svip.iocoder.cn/MyBatis/builder-package-2/#) 详细解析。
+
+- `<3>` 处，解析失败，因为此处指向的 Cache 对象可能未初始化，则先调用 `Configuration#addIncompleteCacheRef(CacheRefResolver incompleteCacheRef)` 方法，添加到 `configuration` 的 `incompleteCacheRefs` 中。代码如下：
+
+  ```
+  // Configuration.java
+  
+  /**
+   * CacheRefResolver 集合
+   */
+  protected final Collection<CacheRefResolver> incompleteCacheRefs = new LinkedList<>();
+  
+  public void addIncompleteCacheRef(CacheRefResolver incompleteCacheRef) {
+      incompleteCacheRefs.add(incompleteCacheRef);
+  }
+  ```
+
+#### 2.3.1.1 CacheRefResolver
+
+`org.apache.ibatis.builder.CacheRefResolver` ，Cache 指向解析器。代码如下：
+
+```
+// CacheRefResolver.java
+
+public class CacheRefResolver {
+
+    private final MapperBuilderAssistant assistant;
+    /**
+     * Cache 指向的命名空间
+     */
+    private final String cacheRefNamespace;
+
+    public CacheRefResolver(MapperBuilderAssistant assistant, String cacheRefNamespace) {
+        this.assistant = assistant;
+        this.cacheRefNamespace = cacheRefNamespace;
+    }
+
+    public Cache resolveCacheRef() {
+        return assistant.useCacheRef(cacheRefNamespace);
+    }
+
+}
+```
+
+- 在 `#resolveCacheRef()` 方法中，会调用 `MapperBuilderAssistant#useCacheRef(String namespace)` 方法，获得指向的 Cache 对象。详细解析，见 [「3.3 useCacheRef」](https://svip.iocoder.cn/MyBatis/builder-package-2/#) 。
+
+### 2.3.2 cacheElement
+
+`#cacheElement(XNode context)` 方法，解析 `cache />` 标签。代码如下：
+
+```
+// XMLMapperBuilder.java
+
+private void cacheElement(XNode context) throws Exception {
+    if (context != null) {
+        // <1> 获得负责存储的 Cache 实现类
+        String type = context.getStringAttribute("type", "PERPETUAL");
+        Class<? extends Cache> typeClass = typeAliasRegistry.resolveAlias(type);
+        // <2> 获得负责过期的 Cache 实现类
+        String eviction = context.getStringAttribute("eviction", "LRU");
+        Class<? extends Cache> evictionClass = typeAliasRegistry.resolveAlias(eviction);
+        // <3> 获得 flushInterval、size、readWrite、blocking 属性
+        Long flushInterval = context.getLongAttribute("flushInterval");
+        Integer size = context.getIntAttribute("size");
+        boolean readWrite = !context.getBooleanAttribute("readOnly", false);
+        boolean blocking = context.getBooleanAttribute("blocking", false);
+        // <4> 获得 Properties 属性
+        Properties props = context.getChildrenAsProperties();
+        // <5> 创建 Cache 对象
+        builderAssistant.useNewCache(typeClass, evictionClass, flushInterval, size, readWrite, blocking, props);
+    }
+}
+```
+
+- 示例如下：
+
+  ```
+  // 使用默认缓存
+  <cache eviction="FIFO" flushInterval="60000"  size="512" readOnly="true"/>
+  
+  // 使用自定义缓存
+  <cache type="com.domain.something.MyCustomCache">
+    <property name="cacheFile" value="/tmp/my-custom-cache.tmp"/>
+  </cache>
+  ```
+
+- `<1>`、`<2>`、`<3>`、`<4>` 处，见代码注释即可。
+
+- `<5>` 处，调用 `MapperBuilderAssistant#useNewCache(...)` 方法，创建 Cache 对象。详细解析，见 [「3.4 useNewCache」](https://svip.iocoder.cn/MyBatis/builder-package-2/#) 中。
+
+### 2.3.3 resultMapElements
+
+> 老艿艿：开始高能，保持耐心。
+
+整体流程如下：
+
+> FROM [《Mybatis3.3.x技术内幕（十）：Mybatis初始化流程（下）》](https://my.oschina.net/zudajun/blog/669868)
+>
+> [![解析``](http://static.iocoder.cn/images/MyBatis/2020_02_13/03.png)](http://static.iocoder.cn/images/MyBatis/2020_02_13/03.png)解析``
+
+`#resultMapElements(List<XNode> list)` 方法，解析 `<resultMap />` 节点们。代码如下：
+
+```
+// XMLMapperBuilder.java
+
+// 解析 <resultMap /> 节点们
+private void resultMapElements(List<XNode> list) throws Exception {
+    // 遍历 <resultMap /> 节点们
+    for (XNode resultMapNode : list) {
+        try {
+            // 处理单个 <resultMap /> 节点
+            resultMapElement(resultMapNode);
+        } catch (IncompleteElementException e) {
+            // ignore, it will be retried
+        }
+    }
+}
+
+// 解析 <resultMap /> 节点
+private ResultMap resultMapElement(XNode resultMapNode) throws Exception {
+    return resultMapElement(resultMapNode, Collections.<ResultMapping>emptyList());
+}
+
+// 解析 <resultMap /> 节点
+private ResultMap resultMapElement(XNode resultMapNode, List<ResultMapping> additionalResultMappings) throws Exception {
+    ErrorContext.instance().activity("processing " + resultMapNode.getValueBasedIdentifier());
+    // <1> 获得 id 属性
+    String id = resultMapNode.getStringAttribute("id",
+            resultMapNode.getValueBasedIdentifier());
+    // <1> 获得 type 属性
+    String type = resultMapNode.getStringAttribute("type",
+            resultMapNode.getStringAttribute("ofType",
+                    resultMapNode.getStringAttribute("resultType",
+                            resultMapNode.getStringAttribute("javaType"))));
+    // <1> 获得 extends 属性
+    String extend = resultMapNode.getStringAttribute("extends");
+    // <1> 获得 autoMapping 属性
+    Boolean autoMapping = resultMapNode.getBooleanAttribute("autoMapping");
+    // <1> 解析 type 对应的类
+    Class<?> typeClass = resolveClass(type);
+    Discriminator discriminator = null;
+    // <2> 创建 ResultMapping 集合
+    List<ResultMapping> resultMappings = new ArrayList<>();
+    resultMappings.addAll(additionalResultMappings);
+    // <2> 遍历 <resultMap /> 的子节点
+    List<XNode> resultChildren = resultMapNode.getChildren();
+    for (XNode resultChild : resultChildren) {
+        // <2.1> 处理 <constructor /> 节点
+        if ("constructor".equals(resultChild.getName())) {
+            processConstructorElement(resultChild, typeClass, resultMappings);
+        // <2.2> 处理 <discriminator /> 节点
+        } else if ("discriminator".equals(resultChild.getName())) {
+            discriminator = processDiscriminatorElement(resultChild, typeClass, resultMappings);
+        // <2.3> 处理其它节点
+        } else {
+            List<ResultFlag> flags = new ArrayList<>();
+            if ("id".equals(resultChild.getName())) {
+                flags.add(ResultFlag.ID);
+            }
+            resultMappings.add(buildResultMappingFromContext(resultChild, typeClass, flags));
+        }
+    }
+    // <3> 创建 ResultMapResolver 对象，执行解析
+    ResultMapResolver resultMapResolver = new ResultMapResolver(builderAssistant, id, typeClass, extend, discriminator, resultMappings, autoMapping);
+    try {
+        return resultMapResolver.resolve();
+    } catch (IncompleteElementException e) {
+        // <4> 解析失败，添加到 configuration 中
+        configuration.addIncompleteResultMap(resultMapResolver);
+        throw e;
+    }
+}
+```
+
+- `<resultMap />` 标签的解析，是相对复杂的过程，情况比较多，所以胖友碰到不懂的，可以看看 [《MyBatis 文档 —— Mapper XML 文件》](http://www.mybatis.org/mybatis-3/zh/sqlmap-xml.html) 文档。
+
+- `<1>` 处，获得 `id`、`type`、`extends`、`autoMapping` 属性，并解析 `type` 对应的类型。
+
+- ```
+  <2>
+  ```
+
+   
+
+  处，创建 ResultMapping 集合，后遍历
+
+   
+
+  ```
+  <resultMap />
+  ```
+
+   
+
+  的
+
+  子
+
+  节点们，将每一个子节点解析成一个或多个 ResultMapping 对象，添加到集合中。即如下图所示：
+
+  ![ResultMap 与 ResultMapping 的映射](16-mybatis-MyBatis 初始化（二）之加载 Mapper 映射配置文件.assets/02.png)
+
+  ResultMap 与 ResultMapping 的映射
+
+  - `<2.1>` 处，调用 `#processConstructorElement(...)` 方法，处理 `<constructor />` 节点。详细解析，见 [「2.3.3.1 processConstructorElement」](https://svip.iocoder.cn/MyBatis/builder-package-2/#) 。
+  - `<2.2>` 处，调用 `#processDiscriminatorElement(...)` 方法，处理 `<discriminator />` 节点。详细解析，见 [「2.3.3.2 processDiscriminatorElement」](https://svip.iocoder.cn/MyBatis/builder-package-2/#) 。
+  - `<2.3>` 处，调用 `#buildResultMappingFromContext(XNode context, Class<?> resultType, List<ResultFlag> flags)` 方法，将当前子节点构建成 ResultMapping 对象，并添加到 `resultMappings` 中。详细解析，见 [「2.3.3.3 buildResultMappingFromContext」](https://svip.iocoder.cn/MyBatis/builder-package-2/#) 。🌞 这一块，和 [「2.3.3.1 processConstructorElement」](https://svip.iocoder.cn/MyBatis/builder-package-2/#) 的 `<3>` 是一致的。
+
+- `<3>` 处，创建 ResultMapResolver 对象，执行解析。关于 ResultMapResolver ，在 「2.3.1.1 CacheRefResolver」 详细解析。
+
+- `<4>` 处，如果解析失败，说明有依赖的信息不全，所以调用 `Configuration#addIncompleteResultMap(ResultMapResolver resultMapResolver)` 方法，添加到 Configuration 的 `incompleteResultMaps` 中。代码如下：
+
+  ```
+  // Configuration.java
+  
+  /**
+   * ResultMapResolver 集合
+   */
+  protected final Collection<ResultMapResolver> incompleteResultMaps = new LinkedList<>();
+  
+  public void addIncompleteResultMap(ResultMapResolver resultMapResolver) {
+      incompleteResultMaps.add(resultMapResolver);
+  }
+  ```
+
+#### 2.3.3.1 processConstructorElement
+
+`#processConstructorElement(XNode resultChild, Class<?> resultType, List<ResultMapping> resultMappings)` 方法，处理 `<constructor />` 节点。代码如下：
+
+```
+// XMLMapperBuilder.java
+
+private void processConstructorElement(XNode resultChild, Class<?> resultType, List<ResultMapping> resultMappings) throws Exception {
+    // <1> 遍历 <constructor /> 的子节点们
+    List<XNode> argChildren = resultChild.getChildren();
+    for (XNode argChild : argChildren) {
+        // <2> 获得 ResultFlag 集合
+        List<ResultFlag> flags = new ArrayList<>();
+        flags.add(ResultFlag.CONSTRUCTOR);
+        if ("idArg".equals(argChild.getName())) {
+            flags.add(ResultFlag.ID);
+        }
+        // <3> 将当前子节点构建成 ResultMapping 对象，并添加到 resultMappings 中
+        resultMappings.add(buildResultMappingFromContext(argChild, resultType, flags));
+    }
+}
+```
+
+- `<1>` 和 `<3>` 处，遍历 `<constructor />` 的子节点们，调用 `#buildResultMappingFromContext(XNode context, Class<?> resultType, List<ResultFlag> flags)` 方法，将当前子节点构建成 ResultMapping 对象，并添加到 `resultMappings` 中。详细解析，见 [「2.3.3.3 buildResultMappingFromContext」](https://svip.iocoder.cn/MyBatis/builder-package-2/#) 。
+
+- `<2>` 处，我们可以看到一个 `org.apache.ibatis.mapping.ResultFlag` 枚举类，结果标识。代码如下：
+
+  ```
+  // ResultFlag.java
+  
+  public enum ResultFlag {
+  
+      /**
+       * ID
+       */
+      ID,
+      /**
+       * 构造方法
+       */
+      CONSTRUCTOR
+  
+  }
+  ```
+
+  - 具体的用途，见下文。
+
+#### 2.3.3.2 processDiscriminatorElement
+
+`#processDiscriminatorElement(XNode context, Class<?> resultType, List<ResultMapping> resultMappings)` 方法，处理 `<constructor />` 节点。代码如下：
+
+```
+// XMLMapperBuilder.java
+
+private Discriminator processDiscriminatorElement(XNode context, Class<?> resultType, List<ResultMapping> resultMappings) throws Exception {
+    // <1> 解析各种属性
+    String column = context.getStringAttribute("column");
+    String javaType = context.getStringAttribute("javaType");
+    String jdbcType = context.getStringAttribute("jdbcType");
+    String typeHandler = context.getStringAttribute("typeHandler");
+    // <1> 解析各种属性对应的类
+    Class<?> javaTypeClass = resolveClass(javaType);
+    Class<? extends TypeHandler<?>> typeHandlerClass = resolveClass(typeHandler);
+    JdbcType jdbcTypeEnum = resolveJdbcType(jdbcType);
+    // <2> 遍历 <discriminator /> 的子节点，解析成 discriminatorMap 集合
+    Map<String, String> discriminatorMap = new HashMap<>();
+    for (XNode caseChild : context.getChildren()) {
+        String value = caseChild.getStringAttribute("value");
+        String resultMap = caseChild.getStringAttribute("resultMap", processNestedResultMappings(caseChild, resultMappings)); // <2.1>
+        discriminatorMap.put(value, resultMap);
+    }
+    // <3> 创建 Discriminator 对象
+    return builderAssistant.buildDiscriminator(resultType, column, javaTypeClass, jdbcTypeEnum, typeHandlerClass, discriminatorMap);
+}
+```
+
+- 可能大家对 `<discriminator />` 标签不是很熟悉，可以打开 [《MyBatis 文档 —— Mapper XML 文件》](http://www.mybatis.org/mybatis-3/zh/sqlmap-xml.html) 文档，然后下【鉴别器】。😈 当然，这块简单了解下就好，实际场景下，艿艿貌似都不知道它的存在，哈哈哈哈。
+
+- `<1>` 处，解析各种属性以及属性对应的类。
+
+- `<2>` 处，遍历 `<discriminator />` 的子节点，解析成 `discriminatorMap` 集合。
+
+- `<2.1>` 处，如果是内嵌的 ResultMap 的情况，则调用 `#processNestedResultMappings(XNode context, List<ResultMapping> resultMappings)` 方法，处理**内嵌**的 ResultMap 的情况。代码如下：
+
+  ```
+  // XMLMapperBuilder.java
+  
+  private String processNestedResultMappings(XNode context, List<ResultMapping> resultMappings) throws Exception {
+      if ("association".equals(context.getName())
+              || "collection".equals(context.getName())
+              || "case".equals(context.getName())) {
+          if (context.getStringAttribute("select") == null) {
+              // 解析，并返回 ResultMap
+              ResultMap resultMap = resultMapElement(context, resultMappings);
+              return resultMap.getId();
+          }
+      }
+      return null;
+  }
+  ```
+
+  - 该方法，会“递归”调用 `#resultMapElement(XNode context, List<ResultMapping> resultMappings)` 方法，处理内嵌的 ResultMap 的情况。也就是返回到 [「2.3.3 resultMapElement」](https://svip.iocoder.cn/MyBatis/builder-package-2/#) 流程。
+
+- `<3>` 处，调用 `MapperBuilderAssistant#buildDiscriminator(...)` 方法，创建 Discriminator 对象。详细解析，见 [「3.6 buildDiscriminator」](https://svip.iocoder.cn/MyBatis/builder-package-2/#) 。
+
+#### 2.3.3.3 buildResultMappingFromContext
+
+`#buildResultMappingFromContext(XNode context, Class<?> resultType, List<ResultFlag> flags)` 方法，将当前节点构建成 ResultMapping 对象。代码如下：
+
+```
+// XMLMapperBuilder.java
+
+private ResultMapping buildResultMappingFromContext(XNode context, Class<?> resultType, List<ResultFlag> flags) throws Exception {
+    // <1> 获得各种属性
+    String property;
+    if (flags.contains(ResultFlag.CONSTRUCTOR)) {
+        property = context.getStringAttribute("name");
+    } else {
+        property = context.getStringAttribute("property");
+    }
+    String column = context.getStringAttribute("column");
+    String javaType = context.getStringAttribute("javaType");
+    String jdbcType = context.getStringAttribute("jdbcType");
+    String nestedSelect = context.getStringAttribute("select");
+    String nestedResultMap = context.getStringAttribute("resultMap",
+            processNestedResultMappings(context, Collections.emptyList()));
+    String notNullColumn = context.getStringAttribute("notNullColumn");
+    String columnPrefix = context.getStringAttribute("columnPrefix");
+    String typeHandler = context.getStringAttribute("typeHandler");
+    String resultSet = context.getStringAttribute("resultSet");
+    String foreignColumn = context.getStringAttribute("foreignColumn");
+    boolean lazy = "lazy".equals(context.getStringAttribute("fetchType", configuration.isLazyLoadingEnabled() ? "lazy" : "eager"));
+    // <1> 获得各种属性对应的类
+    Class<?> javaTypeClass = resolveClass(javaType);
+    Class<? extends TypeHandler<?>> typeHandlerClass = resolveClass(typeHandler);
+    JdbcType jdbcTypeEnum = resolveJdbcType(jdbcType);
+    // <2> 构建 ResultMapping 对象
+    return builderAssistant.buildResultMapping(resultType, property, column, javaTypeClass, jdbcTypeEnum, nestedSelect, nestedResultMap, notNullColumn, columnPrefix, typeHandlerClass, flags, resultSet, foreignColumn, lazy);
+}
+```
+
+- `<1>` 处，解析各种属性以及属性对应的类。
+- `<2>` 处，调用 `MapperBuilderAssistant#buildResultMapping(...)` 方法，构建 ResultMapping 对象。详细解析，见 [「3.5 buildResultMapping」](https://svip.iocoder.cn/MyBatis/builder-package-2/#) 。
+
+#### 2.3.3.4 ResultMapResolver
+
+`org.apache.ibatis.builder.ResultMapResolver`，ResultMap 解析器。代码如下：
+
+```
+// ResultMapResolver.java
+
+public class ResultMapResolver {
+
+    private final MapperBuilderAssistant assistant;
+    /**
+     * ResultMap 编号
+     */
+    private final String id;
+    /**
+     * 类型
+     */
+    private final Class<?> type;
+    /**
+     * 继承自哪个 ResultMap
+     */
+    private final String extend;
+    /**
+     * Discriminator 对象
+     */
+    private final Discriminator discriminator;
+    /**
+     * ResultMapping 集合
+     */
+    private final List<ResultMapping> resultMappings;
+    /**
+     * 是否自动匹配
+     */
+    private final Boolean autoMapping;
+
+    public ResultMapResolver(MapperBuilderAssistant assistant, String id, Class<?> type, String extend, Discriminator discriminator, List<ResultMapping> resultMappings, Boolean autoMapping) {
+        this.assistant = assistant;
+        this.id = id;
+        this.type = type;
+        this.extend = extend;
+        this.discriminator = discriminator;
+        this.resultMappings = resultMappings;
+        this.autoMapping = autoMapping;
+    }
+
+    public ResultMap resolve() {
+        return assistant.addResultMap(this.id, this.type, this.extend, this.discriminator, this.resultMappings, this.autoMapping);
+    }
+
+}
+```
+
+- 在 `#resolve()` 方法中，会调用 `MapperBuilderAssistant#addResultMap(...)` 方法，创建 ResultMap 对象。详细解析，见 [「3.7 addResultMap」](https://svip.iocoder.cn/MyBatis/builder-package-2/#) 。
+
+### 2.3.4 sqlElement
+
+`#sqlElement(List<XNode> list)` 方法，解析 `<sql />` 节点们。代码如下：
+
+```
+// XMLMapperBuilder.java
+
+private void sqlElement(List<XNode> list) throws Exception {
+    if (configuration.getDatabaseId() != null) {
+        sqlElement(list, configuration.getDatabaseId());
+    }
+    sqlElement(list, null);
+    // 上面两块代码，可以简写成 sqlElement(list, configuration.getDatabaseId());
+}
+
+private void sqlElement(List<XNode> list, String requiredDatabaseId) throws Exception {
+    // <1> 遍历所有 <sql /> 节点
+    for (XNode context : list) {
+        // <2> 获得 databaseId 属性
+        String databaseId = context.getStringAttribute("databaseId");
+        // <3> 获得完整的 id 属性，格式为 `${namespace}.${id}` 。
+        String id = context.getStringAttribute("id");
+        id = builderAssistant.applyCurrentNamespace(id, false);
+        // <4> 判断 databaseId 是否匹配
+        if (databaseIdMatchesCurrent(id, databaseId, requiredDatabaseId)) {
+            // <5> 添加到 sqlFragments 中
+            sqlFragments.put(id, context);
+        }
+    }
+}
+```
+
+- `<1>` 处，遍历所有 `<sql />` 节点，逐个处理。
+
+- `<2>` 处，获得 `databaseId` 属性。
+
+- `<3>` 处，获得完整的 `id` 属性，格式为 `${namespace}.${id}` 。
+
+- `<4>` 处，调用 `#databaseIdMatchesCurrent(String id, String databaseId, String requiredDatabaseId)` 方法，判断 `databaseId` 是否匹配。代码如下：
+
+  ```
+  // XMLMapperBuilder.java
+  
+  private boolean databaseIdMatchesCurrent(String id, String databaseId, String requiredDatabaseId) {
+      // 如果不匹配，则返回 false
+      if (requiredDatabaseId != null) {
+          return requiredDatabaseId.equals(databaseId);
+      } else {
+          // 如果未设置 requiredDatabaseId ，但是 databaseId 存在，说明还是不匹配，则返回 false
+          // mmp ，写的好绕
+          if (databaseId != null) {
+              return false;
+          }
+          // skip this fragment if there is a previous one with a not null databaseId
+          // 判断是否已经存在
+          if (this.sqlFragments.containsKey(id)) {
+              XNode context = this.sqlFragments.get(id);
+              // 若存在，则判断原有的 sqlFragment 是否 databaseId 为空。因为，当前 databaseId 为空，这样两者才能匹配。
+              return context.getStringAttribute("databaseId") == null;
+          }
+      }
+      return true;
+  }
+  ```
+
+- `<5>` 处，添加到 `sqlFragments` 中。因为 `sqlFragments` 是来自 Configuration 的 `sqlFragments` 属性，所以相当于也被添加了。代码如下：
+
+  ```
+  // Configuration.java
+  
+   /**
+   * 可被其他语句引用的可重用语句块的集合
+   *
+   * 例如：<sql id="userColumns"> ${alias}.id,${alias}.username,${alias}.password </sql>
+   */
+  protected final Map<String, XNode> sqlFragments = new StrictMap<>("XML fragments parsed from previous mappers");
+  ```
+
+### 2.3.5 buildStatementFromContext
+
+`#buildStatementFromContext(List<XNode> list)` 方法，解析 `<select />`、`<insert />`、`<update />`、`<delete />` 节点们。代码如下：
+
+```
+// XMLMapperBuilder.java
+
+private void buildStatementFromContext(List<XNode> list) {
+    if (configuration.getDatabaseId() != null) {
+        buildStatementFromContext(list, configuration.getDatabaseId());
+    }
+    buildStatementFromContext(list, null);
+    // 上面两块代码，可以简写成 buildStatementFromContext(list, configuration.getDatabaseId());
+}
+
+private void buildStatementFromContext(List<XNode> list, String requiredDatabaseId) {
+    // <1> 遍历 <select /> <insert /> <update /> <delete /> 节点们
+    for (XNode context : list) {
+        // <1> 创建 XMLStatementBuilder 对象，执行解析
+        final XMLStatementBuilder statementParser = new XMLStatementBuilder(configuration, builderAssistant, context, requiredDatabaseId);
+        try {
+            statementParser.parseStatementNode();
+        } catch (IncompleteElementException e) {
+            // <2> 解析失败，添加到 configuration 中
+            configuration.addIncompleteStatement(statementParser);
+        }
+    }
+}
+```
+
+- `<1>` 处，遍历 `<select />`、`<insert />`、`<update />`、`<delete />` 节点们，逐个创建 XMLStatementBuilder 对象，执行解析。关于 XMLStatementBuilder 类，我们放在下篇文章，详细解析。
+
+- `<2>` 处，解析失败，调用 `Configuration#addIncompleteStatement(XMLStatementBuilder incompleteStatement)` 方法，添加到 `configuration` 中。代码如下：
+
+  ```
+  // Configuration.java
+  
+  /**
+   * XMLStatementBuilder 集合
+   */
+  protected final Collection<XMLStatementBuilder> incompleteStatements = new LinkedList<>();
+  
+  public void addIncompleteStatement(XMLStatementBuilder incompleteStatement) {
+      incompleteStatements.add(incompleteStatement);
+  }
+  ```
+
+## 2.4 bindMapperForNamespace
+
+`#bindMapperForNamespace()` 方法，绑定 Mapper 。代码如下：
+
+```
+// XMLMapperBuilder.java
+
+private void bindMapperForNamespace() {
+    String namespace = builderAssistant.getCurrentNamespace();
+    if (namespace != null) {
+        // <1> 获得 Mapper 映射配置文件对应的 Mapper 接口，实际上类名就是 namespace 。嘿嘿，这个是常识。
+        Class<?> boundType = null;
+        try {
+            boundType = Resources.classForName(namespace);
+        } catch (ClassNotFoundException e) {
+            //ignore, bound type is not required
+        }
+        if (boundType != null) {
+            // <2> 不存在该 Mapper 接口，则进行添加
+            if (!configuration.hasMapper(boundType)) {
+                // Spring may not know the real resource name so we set a flag
+                // to prevent loading again this resource from the mapper interface
+                // look at MapperAnnotationBuilder#loadXmlResource
+                // <3> 标记 namespace 已经添加，避免 MapperAnnotationBuilder#loadXmlResource(...) 重复加载
+                configuration.addLoadedResource("namespace:" + namespace);
+                // <4> 添加到 configuration 中
+                configuration.addMapper(boundType);
+            }
+        }
+    }
+}
+```
+
+- `<1>` 处，获得 Mapper 映射配置文件对应的 Mapper 接口，实际上类名就是 `namespace` 。嘿嘿，这个是常识。
+
+- `<2>` 处，调用 `Configuration#hasMapper(Class<?> type)` 方法，判断若谷不存在该 Mapper 接口，则进行绑定。代码如下：
+
+  ```
+  // Configuration.java
+  
+  /**
+   * MapperRegistry 对象
+   */
+  protected final MapperRegistry mapperRegistry = new MapperRegistry(this);
+  
+  public boolean hasMapper(Class<?> type) {
+      return mapperRegistry.hasMapper(type);
+  }
+  ```
+
+- `<3>` 处，调用 `Configuration#addLoadedResource(String resource)` 方法，标记 `namespace` 已经添加，避免 `MapperAnnotationBuilder#loadXmlResource(...)` 重复加载。代码如下：
+
+  ```
+  // MapperAnnotationBuilder.java
+  
+  private void loadXmlResource() {
+      // Spring may not know the real resource name so we check a flag
+      // to prevent loading again a resource twice
+      // this flag is set at XMLMapperBuilder#bindMapperForNamespace
+      if (!configuration.isResourceLoaded("namespace:" + type.getName())) {
+          // ... 省略创建 XMLMapperBuilder ，进行解析的代码
+      }
+  }
+  ```
+
+- `<4>` 处，调用 `Configuration#addMapper(Class<T> type)` 方法，添加到 `configuration` 的 `mapperRegistry` 中。代码如下：
+
+  ```
+  // Configuration.java
+  
+  public <T> void addMapper(Class<T> type) {
+      mapperRegistry.addMapper(type);
+  }
+  ```
+
+## 2.5 parsePendingXXX
+
+有三个 parsePendingXXX 方法，代码如下：
+
+```
+// XMLMapperBuilder.java
+
+private void parsePendingResultMaps() {
+    // 获得 ResultMapResolver 集合，并遍历进行处理
+    Collection<ResultMapResolver> incompleteResultMaps = configuration.getIncompleteResultMaps();
+    synchronized (incompleteResultMaps) {
+        Iterator<ResultMapResolver> iter = incompleteResultMaps.iterator();
+        while (iter.hasNext()) {
+            try {
+                // 执行解析
+                iter.next().resolve();
+                // 移除
+                iter.remove();
+            } catch (IncompleteElementException e) {
+                // ResultMap is still missing a resource...
+                // 解析失败，不抛出异常
+            }
+        }
+    }
+}
+
+private void parsePendingCacheRefs() {
+    // 获得 CacheRefResolver 集合，并遍历进行处理
+    Collection<CacheRefResolver> incompleteCacheRefs = configuration.getIncompleteCacheRefs();
+    synchronized (incompleteCacheRefs) {
+        Iterator<CacheRefResolver> iter = incompleteCacheRefs.iterator();
+        while (iter.hasNext()) {
+            try {
+                // 执行解析
+                iter.next().resolveCacheRef();
+                // 移除
+                iter.remove();
+            } catch (IncompleteElementException e) {
+                // Cache ref is still missing a resource...
+            }
+        }
+    }
+}
+
+private void parsePendingStatements() {
+    // 获得 XMLStatementBuilder 集合，并遍历进行处理
+    Collection<XMLStatementBuilder> incompleteStatements = configuration.getIncompleteStatements();
+    synchronized (incompleteStatements) {
+        Iterator<XMLStatementBuilder> iter = incompleteStatements.iterator();
+        while (iter.hasNext()) {
+            try {
+                // 执行解析
+                iter.next().parseStatementNode();
+                // 移除
+                iter.remove();
+            } catch (IncompleteElementException e) {
+                // Statement is still missing a resource...
+            }
+        }
+    }
+}
+```
+
+- 三个方法的逻辑思路基本一致：1）获得对应的集合；2）遍历集合，执行解析；3）执行成功，则移除出集合；4）执行失败，忽略异常。
+- 当然，实际上，此处还是可能有执行解析失败的情况，但是随着每一个 Mapper 配置文件对应的 XMLMapperBuilder 执行一次这些方法，逐步逐步就会被全部解析完。😈
+
+# 3. MapperBuilderAssistant
+
+`org.apache.ibatis.builder.MapperBuilderAssistant` ，继承 BaseBuilder 抽象类，Mapper 构造器的小助手，提供了一些公用的方法，例如创建 ParameterMap、MappedStatement 对象等等。
+
+## 3.1 构造方法
+
+```
+// MapperBuilderAssistant.java
+
+/**
+ * 当前 Mapper 命名空间
+ */
+private String currentNamespace;
+/**
+ * 资源引用的地址
+ */
+private final String resource;
+/**
+ * 当前 Cache 对象
+ */
+private Cache currentCache;
+/**
+ * 是否未解析成功 Cache 引用
+ */
+private boolean unresolvedCacheRef; // issue #676
+
+public MapperBuilderAssistant(Configuration configuration, String resource) {
+    super(configuration);
+    ErrorContext.instance().resource(resource);
+    this.resource = resource;
+}
+```
+
+- 实际上，😈 如果要不是为了 XMLMapperBuilder 和 MapperAnnotationBuilder 都能调用到这个公用方法，可能都不需要这个类。
+
+## 3.2 setCurrentNamespace
+
+`#setCurrentNamespace(String currentNamespace)` 方法，设置 `currentNamespace` 属性。代码如下：
+
+```
+// MapperBuilderAssistant.java
+
+public void setCurrentNamespace(String currentNamespace) {
+    // 如果传入的 currentNamespace 参数为空，抛出 BuilderException 异常
+    if (currentNamespace == null) {
+        throw new BuilderException("The mapper element requires a namespace attribute to be specified.");
+    }
+
+    // 如果当前已经设置，并且还和传入的不相等，抛出 BuilderException 异常
+    if (this.currentNamespace != null && !this.currentNamespace.equals(currentNamespace)) {
+        throw new BuilderException("Wrong namespace. Expected '"
+                + this.currentNamespace + "' but found '" + currentNamespace + "'.");
+    }
+
+    // 设置
+    this.currentNamespace = currentNamespace;
+}
+```
+
+## 3.3 useCacheRef
+
+`#useCacheRef(String namespace)` 方法，获得指向的 Cache 对象。如果获得不到，则抛出 IncompleteElementException 异常。代码如下：
+
+```
+// MapperBuilderAssistant.java
+
+public Cache useCacheRef(String namespace) {
+    if (namespace == null) {
+        throw new BuilderException("cache-ref element requires a namespace attribute.");
+    }
+    try {
+        unresolvedCacheRef = true; // 标记未解决
+        // <1> 获得 Cache 对象
+        Cache cache = configuration.getCache(namespace);
+        // 获得不到，抛出 IncompleteElementException 异常
+        if (cache == null) {
+            throw new IncompleteElementException("No cache for namespace '" + namespace + "' could be found.");
+        }
+        // 记录当前 Cache 对象
+        currentCache = cache;
+        unresolvedCacheRef = false; // 标记已解决
+        return cache;
+    } catch (IllegalArgumentException e) {
+        throw new IncompleteElementException("No cache for namespace '" + namespace + "' could be found.", e);
+    }
+}
+```
+
+- `<1>` 处，调用 `Configuration#getCache(String id)` 方法，获得 Cache 对象。代码如下：
+
+  ```
+  // Configuration.java
+  
+  /**
+   * Cache 对象集合
+   *
+   * KEY：命名空间 namespace
+   */
+  protected final Map<String, Cache> caches = new StrictMap<>("Caches collection");
+  
+  public Cache getCache(String id) {
+      return caches.get(id);
+  }
+  ```
+
+## 3.4 useNewCache
+
+`#useNewCache(Class<? extends Cache> typeClass, Class<? extends Cache> evictionClass, Long flushInterval, Integer size, boolean readWrite, boolean blocking, Properties props)` 方法，创建 Cache 对象。代码如下：
+
+```
+// MapperBuilderAssistant.java
+
+public Cache useNewCache(Class<? extends Cache> typeClass,
+                         Class<? extends Cache> evictionClass,
+                         Long flushInterval,
+                         Integer size,
+                         boolean readWrite,
+                         boolean blocking,
+                         Properties props) {
+    // <1> 创建 Cache 对象
+    Cache cache = new CacheBuilder(currentNamespace)
+            .implementation(valueOrDefault(typeClass, PerpetualCache.class))
+            .addDecorator(valueOrDefault(evictionClass, LruCache.class))
+            .clearInterval(flushInterval)
+            .size(size)
+            .readWrite(readWrite)
+            .blocking(blocking)
+            .properties(props)
+            .build();
+    // <2> 添加到 configuration 的 caches 中
+    configuration.addCache(cache);
+    // <3> 赋值给 currentCache
+    currentCache = cache;
+    return cache;
+}
+```
+
+- `<1>` 处，创建 Cache 对象。关于 CacheBuilder 类，详细解析，见 [「3.4.1 CacheBuilder」](https://svip.iocoder.cn/MyBatis/builder-package-2/#) 。
+
+- `<2>` 处，调用 `Configuration#addCache(Cache cache)` 方法，添加到 `configuration` 的 `caches` 中。代码如下：
+
+  ```
+  // Configuration.java
+  
+  public void addCache(Cache cache) {
+      caches.put(cache.getId(), cache);
+  }
+  ```
+
+- `<3>` 处，赋值给 `currentCache` 。
+
+### 3.4.1 CacheBuilder
+
+`org.apache.ibatis.mapping.CacheBuilder` ，Cache 构造器。基于装饰者设计模式，进行 Cache 对象的构造。代码比较简单，但是有点略长，胖友直接点击 [链接](https://github.com/YunaiV/mybatis-3/blob/master/src/main/java/org/apache/ibatis/mapping/CacheBuilder.java) 查看，已经添加了完整的注释。
+
+## 3.5 buildResultMapping
+
+`#buildResultMapping(Class<?> resultType, String property, String column,Class<?> javaType, JdbcType jdbcType, String nestedSelect, String nestedResultMap, String notNullColumn, String columnPrefix, Class<? extends TypeHandler<?>> typeHandler, List<ResultFlag> flags, String resultSet, String foreignColumn, boolean lazy)` 方法，构造 ResultMapping 对象。代码如下：
+
+```
+// MapperBuilderAssistant.java
+
+public ResultMapping buildResultMapping(
+        Class<?> resultType,
+        String property,
+        String column,
+        Class<?> javaType,
+        JdbcType jdbcType,
+        String nestedSelect,
+        String nestedResultMap,
+        String notNullColumn,
+        String columnPrefix,
+        Class<? extends TypeHandler<?>> typeHandler,
+        List<ResultFlag> flags,
+        String resultSet,
+        String foreignColumn,
+        boolean lazy) {
+    // <1> 解析对应的 Java Type 类和 TypeHandler 对象
+    Class<?> javaTypeClass = resolveResultJavaType(resultType, property, javaType);
+    TypeHandler<?> typeHandlerInstance = resolveTypeHandler(javaTypeClass, typeHandler);
+    // <2> 解析组合字段名称成 ResultMapping 集合。涉及「关联的嵌套查询」
+    List<ResultMapping> composites = parseCompositeColumnName(column);
+    // <3> 创建 ResultMapping 对象
+    return new ResultMapping.Builder(configuration, property, column, javaTypeClass)
+            .jdbcType(jdbcType)
+            .nestedQueryId(applyCurrentNamespace(nestedSelect, true)) // <3.1>
+            .nestedResultMapId(applyCurrentNamespace(nestedResultMap, true)) // <3.1>
+            .resultSet(resultSet)
+            .typeHandler(typeHandlerInstance)
+            .flags(flags == null ? new ArrayList<>() : flags)
+            .composites(composites)
+            .notNullColumns(parseMultipleColumnNames(notNullColumn)) // <3.2>
+            .columnPrefix(columnPrefix)
+            .foreignColumn(foreignColumn)
+            .lazy(lazy)
+}
+```
+
+- `<1>` 处，解析对应的 Java Type 类和 TypeHandler 对象。
+
+- `<2>` 处，调用 `#parseCompositeColumnName(String columnName)` 方法，解析组合字段名称成 ResultMapping 集合。详细解析，见 [「3.5.1 parseCompositeColumnName」](https://svip.iocoder.cn/MyBatis/builder-package-2/#) 中。
+
+- ```
+  <3>
+  ```
+
+   
+
+  处，创建 ResultMapping 对象。
+
+  - `<3.1>` 处，调用 `#applyCurrentNamespace(String base, boolean isReference)` 方法，拼接命名空间。详细解析，见 [「3.5.2 applyCurrentNamespace」](https://svip.iocoder.cn/MyBatis/builder-package-2/#) 。
+  - `<3.2>` 处，调用 `#parseMultipleColumnNames(String notNullColumn)` 方法，将字符串解析成集合。详细解析，见 [「3.5.3 parseMultipleColumnNames」](https://svip.iocoder.cn/MyBatis/builder-package-2/#) 。
+  - 关于 ResultMapping 类，在 [「3.5.4 ResultMapping」](https://svip.iocoder.cn/MyBatis/builder-package-2/#) 中详细解析。
+
+### 3.5.1 parseCompositeColumnName
+
+`#parseCompositeColumnName(String columnName)` 方法，解析组合字段名称成 ResultMapping 集合。代码如下：
+
+```
+// MapperBuilderAssistant.java
+
+private List<ResultMapping> parseCompositeColumnName(String columnName) {
+    List<ResultMapping> composites = new ArrayList<>();
+    // 分词，解析其中的 property 和 column 的组合对
+    if (columnName != null && (columnName.indexOf('=') > -1 || columnName.indexOf(',') > -1)) {
+        StringTokenizer parser = new StringTokenizer(columnName, "{}=, ", false);
+        while (parser.hasMoreTokens()) {
+            String property = parser.nextToken();
+            String column = parser.nextToken();
+            // 创建 ResultMapping 对象
+            ResultMapping complexResultMapping = new ResultMapping.Builder(
+                    configuration, property, column, configuration.getTypeHandlerRegistry().getUnknownTypeHandler()).build();
+            // 添加到 composites 中
+            composites.add(complexResultMapping);
+        }
+    }
+    return composites;
+}
+```
+
+- 对于这种情况，官方文档说明如下：
+
+  > FROM [《MyBatis 文档 —— Mapper XML 文件》](http://www.mybatis.org/mybatis-3/zh/sqlmap-xml.html) 的 「关联的嵌套查询」 小节
+  >
+  > 来自数据库的列名,或重命名的列标签。这和通常传递给 resultSet.getString(columnName)方法的字符串是相同的。 column 注 意 : 要 处 理 复 合 主 键 , 你 可 以 指 定 多 个 列 名 通 过 column= ” {prop1=col1,prop2=col2} ” 这种语法来传递给嵌套查询语 句。这会引起 prop1 和 prop2 以参数对象形式来设置给目标嵌套查询语句。
+
+- 😈 不用理解太细，如果胖友和我一样，基本用不到这个特性。
+
+### 3.5.2 applyCurrentNamespace
+
+`#applyCurrentNamespace(String base, boolean isReference)` 方法，拼接命名空间。代码如下：
+
+```
+// MapperBuilderAssistant.java
+
+public String applyCurrentNamespace(String base, boolean isReference) {
+    if (base == null) {
+        return null;
+    }
+    if (isReference) {
+        // is it qualified with any namespace yet?
+        if (base.contains(".")) {
+            return base;
+        }
+    } else {
+        // is it qualified with this namespace yet?
+        if (base.startsWith(currentNamespace + ".")) {
+            return base;
+        }
+        if (base.contains(".")) {
+            throw new BuilderException("Dots are not allowed in element names, please remove it from " + base);
+        }
+    }
+    // 拼接 currentNamespace + base
+    return currentNamespace + "." + base;
+}
+```
+
+- 通过这样的方式，生成**唯一**在的标识。
+
+### 3.5.3 parseMultipleColumnNames
+
+`#parseMultipleColumnNames(String notNullColumn)` 方法，将字符串解析成集合。代码如下：
+
+```
+// MapperBuilderAssistant.java
+
+private Set<String> parseMultipleColumnNames(String columnName) {
+    Set<String> columns = new HashSet<>();
+    if (columnName != null) {
+        // 多个字段，使用 ，分隔
+        if (columnName.indexOf(',') > -1) {
+            StringTokenizer parser = new StringTokenizer(columnName, "{}, ", false);
+            while (parser.hasMoreTokens()) {
+                String column = parser.nextToken();
+                columns.add(column);
+            }
+        } else {
+            columns.add(columnName);
+        }
+    }
+    return columns;
+}
+```
+
+### 3.5.4 ResultMapping
+
+`org.apache.ibatis.mapping.ResultMapping` ，ResultMap 中的每一条结果字段的映射。代码比较简单，但是有点略长，胖友直接点击 [链接](https://github.com/YunaiV/mybatis-3/blob/master/src/main/java/org/apache/ibatis/mapping/ResultMapping.java) 查看，已经添加了完整的注释。
+
+## 3.6 buildDiscriminator
+
+`#buildDiscriminator(Class<?> resultType, String column, Class<?> javaType, JdbcType jdbcType, Class<? extends TypeHandler<?>> typeHandler, Map<String, String> discriminatorMap)` 方法，构建 Discriminator 对象。代码如下：
+
+```
+// MapperBuilderAssistant.java
+
+public Discriminator buildDiscriminator(
+        Class<?> resultType,
+        String column,
+        Class<?> javaType,
+        JdbcType jdbcType,
+        Class<? extends TypeHandler<?>> typeHandler,
+        Map<String, String> discriminatorMap) {
+    // 构建 ResultMapping 对象
+    ResultMapping resultMapping = buildResultMapping(
+            resultType,
+            null,
+            column,
+            javaType,
+            jdbcType,
+            null,
+            null,
+            null,
+            null,
+            typeHandler,
+            new ArrayList<ResultFlag>(),
+            null,
+            null,
+            false);
+    // 创建 namespaceDiscriminatorMap 映射
+    Map<String, String> namespaceDiscriminatorMap = new HashMap<>();
+    for (Map.Entry<String, String> e : discriminatorMap.entrySet()) {
+        String resultMap = e.getValue();
+        resultMap = applyCurrentNamespace(resultMap, true); // 生成 resultMap 标识
+        namespaceDiscriminatorMap.put(e.getKey(), resultMap);
+    }
+    // 构建 Discriminator 对象
+    return new Discriminator.Builder(configuration, resultMapping, namespaceDiscriminatorMap).build();
+}
+```
+
+- 简单看看就好，`<discriminator />` 平时用的很少。
+
+### 3.6.1 Discriminator
+
+`org.apache.ibatis.mapping.Discriminator` ，鉴别器，代码比较简单，胖友直接点击 [链接](https://github.com/YunaiV/mybatis-3/blob/master/src/main/java/org/apache/ibatis/mapping/Discriminator.java) 查看，已经添加了完整的注释。
+
+## 3.7 addResultMap
+
+`#addResultMap(String id, Class<?> type, String extend, Discriminator discriminator, List<ResultMapping> resultMappings, Boolean autoMapping)` 方法，创建 ResultMap 对象，并添加到 Configuration 中。代码如下：
+
+```
+// MapperBuilderAssistant.java
+
+public ResultMap addResultMap(
+        String id,
+        Class<?> type,
+        String extend,
+        Discriminator discriminator,
+        List<ResultMapping> resultMappings,
+        Boolean autoMapping) {
+    // <1> 获得 ResultMap 编号，即格式为 `${namespace}.${id}` 。
+    id = applyCurrentNamespace(id, false);
+    // <2.1> 获取完整的 extend 属性，即格式为 `${namespace}.${extend}` 。从这里的逻辑来看，貌似只能自己 namespace 下的 ResultMap 。
+    extend = applyCurrentNamespace(extend, true);
+
+    // <2.2> 如果有父类，则将父类的 ResultMap 集合，添加到 resultMappings 中。
+    if (extend != null) {
+        // <2.2.1> 获得 extend 对应的 ResultMap 对象。如果不存在，则抛出 IncompleteElementException 异常
+        if (!configuration.hasResultMap(extend)) {
+            throw new IncompleteElementException("Could not find a parent resultmap with id '" + extend + "'");
+        }
+        ResultMap resultMap = configuration.getResultMap(extend);
+        // 获取 extend 的 ResultMap 对象的 ResultMapping 集合，并移除 resultMappings
+        List<ResultMapping> extendedResultMappings = new ArrayList<>(resultMap.getResultMappings());
+        extendedResultMappings.removeAll(resultMappings);
+        // Remove parent constructor if this resultMap declares a constructor.
+        // 判断当前的 resultMappings 是否有构造方法，如果有，则从 extendedResultMappings 移除所有的构造类型的 ResultMapping 们
+        boolean declaresConstructor = false;
+        for (ResultMapping resultMapping : resultMappings) {
+            if (resultMapping.getFlags().contains(ResultFlag.CONSTRUCTOR)) {
+                declaresConstructor = true;
+                break;
+            }
+        }
+        if (declaresConstructor) {
+            extendedResultMappings.removeIf(resultMapping -> resultMapping.getFlags().contains(ResultFlag.CONSTRUCTOR));
+        }
+        // 将 extendedResultMappings 添加到 resultMappings 中
+        resultMappings.addAll(extendedResultMappings);
+    }
+    // <3> 创建 ResultMap 对象
+    ResultMap resultMap = new ResultMap.Builder(configuration, id, type, resultMappings, autoMapping)
+            .discriminator(discriminator)
+            .build();
+    // <4> 添加到 configuration 中
+    configuration.addResultMap(resultMap);
+    return resultMap;
+}
+```
+
+- `<1>` 处，获得 ResultMap 编号，即格式为 `${namespace}.${id}` 。
+
+- `<2.1>` 处，获取完整的 extend 属性，即格式为 `${namespace}.${extend}` 。**从这里的逻辑来看，貌似只能自己 namespace 下的 ResultMap** 。
+
+- `<2.2>` 处，如果有父类，则将父类的 ResultMap 集合，添加到 `resultMappings` 中。逻辑有些绕，胖友耐心往下看。
+
+  - `<2.2.1>` 处，获得 `extend` 对应的 ResultMap 对象。如果不存在，则抛出 IncompleteElementException 异常。代码如下：
+
+    ```
+    // Configuration.java
+    
+    /**
+     * ResultMap 的映射
+     *
+     * KEY：`${namespace}.${id}`
+     */
+    protected final Map<String, ResultMap> resultMaps = new StrictMap<>("Result Maps collection");
+    
+    public ResultMap getResultMap(String id) {
+        return resultMaps.get(id);
+    }
+    
+    public boolean hasResultMap(String id) {
+        return resultMaps.containsKey(id);
+    }
+    ```
+
+    - x
+
+- `<3>` 处，创建 ResultMap 对象。详细解析，见 [「3.7.1 ResultMap」](https://svip.iocoder.cn/MyBatis/builder-package-2/#) 。
+
+- `<4>` 处， 调用 `Configuration#addResultMap(ResultMap rm)` 方法，添加到 Configuration 的 `resultMaps` 中。代码如下：
+
+  ```
+  // Configuration.java
+  
+  public void addResultMap(ResultMap rm) {
+      // <1> 添加到 resultMaps 中
+      resultMaps.put(rm.getId(), rm);
+      // 遍历全局的 ResultMap 集合，若其拥有 Discriminator 对象，则判断是否强制标记为有内嵌的 ResultMap
+      checkLocallyForDiscriminatedNestedResultMaps(rm);
+      // 若传入的 ResultMap 不存在内嵌 ResultMap 并且有 Discriminator ，则判断是否需要强制表位有内嵌的 ResultMap
+      checkGloballyForDiscriminatedNestedResultMaps(rm);
+  }
+  ```
+
+  - `<1>` 处，添加到 `resultMaps` 中。
+
+  - `<2>` 处，调用 `#checkLocallyForDiscriminatedNestedResultMaps(ResultMap rm)` 方法，遍历全局的 ResultMap 集合，若其拥有 Discriminator 对象，则判断是否强制标记为有内嵌的 ResultMap 。代码如下：
+
+    ```
+    // Configuration.java
+    
+    // Slow but a one time cost. A better solution is welcome.
+    protected void checkGloballyForDiscriminatedNestedResultMaps(ResultMap rm) {
+        // 如果传入的 ResultMap 有内嵌的 ResultMap
+        if (rm.hasNestedResultMaps()) {
+            // 遍历全局的 ResultMap 集合
+            for (Map.Entry<String, ResultMap> entry : resultMaps.entrySet()) {
+                Object value = entry.getValue();
+                if (value != null) {
+                    ResultMap entryResultMap = (ResultMap) value;
+                    // 判断遍历的全局的 entryResultMap 不存在内嵌 ResultMap 并且有 Discriminator
+                    if (!entryResultMap.hasNestedResultMaps() && entryResultMap.getDiscriminator() != null) {
+                        // 判断是否 Discriminator 的 ResultMap 集合中，使用了传入的 ResultMap 。
+                        // 如果是，则标记为有内嵌的 ResultMap
+                        Collection<String> discriminatedResultMapNames = entryResultMap.getDiscriminator().getDiscriminatorMap().values();
+                        if (discriminatedResultMapNames.contains(rm.getId())) {
+                            entryResultMap.forceNestedResultMaps();
+                        }
+                    }
+                }
+            }
+        }
+    }
+    ```
+
+    - 逻辑有点绕，胖友耐心看下去。。。
+
+  - `<3>` 处，调用 `#checkLocallyForDiscriminatedNestedResultMaps(ResultMap rm)` 方法，若传入的 ResultMap 不存在内嵌 ResultMap 并且有 Discriminator ，则判断是否需要强制表位有内嵌的 ResultMap 。代码如下：
+
+    ```
+    // Configuration.java
+    
+    // Slow but a one time cost. A better solution is welcome.
+    protected void checkLocallyForDiscriminatedNestedResultMaps(ResultMap rm) {
+        // 如果传入的 ResultMap 不存在内嵌 ResultMap 并且有 Discriminator
+        if (!rm.hasNestedResultMaps() && rm.getDiscriminator() != null) {
+            // 遍历传入的 ResultMap 的 Discriminator 的 ResultMap 集合
+            for (Map.Entry<String, String> entry : rm.getDiscriminator().getDiscriminatorMap().entrySet()) {
+                String discriminatedResultMapName = entry.getValue();
+                if (hasResultMap(discriminatedResultMapName)) {
+                    // 如果引用的 ResultMap 存在内嵌 ResultMap ，则标记传入的 ResultMap 存在内嵌 ResultMap
+                    ResultMap discriminatedResultMap = resultMaps.get(discriminatedResultMapName);
+                    if (discriminatedResultMap.hasNestedResultMaps()) {
+                        rm.forceNestedResultMaps();
+                        break;
+                    }
+                }
+            }
+        }
+    }
+    ```
+
+    - 逻辑有点绕，胖友耐心看下去。。。整体逻辑，和 `#checkGloballyForDiscriminatedNestedResultMaps(ResultMap rm)` 方法是**类似**的，互为“倒影”。
+
+### 3.7.1 ResultMap
+
+`org.apache.ibatis.mapping.ResultMap` ，结果集，例如 `<resultMap />` 解析后的对象。代码比较简单，但是有点略长，胖友直接点击 [链接](https://github.com/YunaiV/mybatis-3/blob/master/src/main/java/org/apache/ibatis/mapping/ResultMap.java) 查看，已经添加了完整的注释。
+
+# 666. 彩蛋
+
+😈 又写到早上 1 点 30 左右，哈哈哈哈。
+
+涉及配置解析类的文章，往往写起来枯燥，胖友读起来也枯燥。当然，本文提供的配置示例非常少（自我吐槽），所以胖友先辛苦下，耐心搭配 [《MyBatis 文档 —— Mapper XML 文件》](http://www.mybatis.org/mybatis-3/zh/sqlmap-xml.html) 一起看看。
+
+如果，胖友看到有疑问，一定一定一定要来星球给艿艿提供。这样，艿艿也好针对的优化这个文章。hohoho 。
+
+参考和推荐如下文章：
+
+- 祖大俊 [《Mybatis3.3.x技术内幕（八）：Mybatis初始化流程（上）》](https://my.oschina.net/zudajun/blog/668738)
+- 祖大俊 [《Mybatis3.3.x技术内幕（九）：Mybatis初始化流程（中）》](https://my.oschina.net/zudajun/blog/668787)
+- 祖大俊 [《Mybatis3.3.x技术内幕（十）：Mybatis初始化流程（下）》](https://my.oschina.net/zudajun/blog/669868)
+- 田小波 [《MyBatis 源码分析 - 映射文件解析过程》](https://www.tianxiaobo.com/2018/07/30/MyBatis-源码分析-映射文件解析过程/)
+- 徐郡明 [《MyBatis 技术内幕》](https://item.jd.com/12125531.html) 的 [「3.1 MyBatis 初始化」](https://svip.iocoder.cn/MyBatis/builder-package-2/#) 小节
\ No newline at end of file
diff --git a/mybatis/17-mybatis-MyBatis 初始化（三）之加载 Statement 配置.assets/01.png b/mybatis/17-mybatis-MyBatis 初始化（三）之加载 Statement 配置.assets/01.png
new file mode 100644
index 0000000..442d141
Binary files /dev/null and b/mybatis/17-mybatis-MyBatis 初始化（三）之加载 Statement 配置.assets/01.png differ
diff --git a/mybatis/17-mybatis-MyBatis 初始化（三）之加载 Statement 配置.assets/02.png b/mybatis/17-mybatis-MyBatis 初始化（三）之加载 Statement 配置.assets/02.png
new file mode 100644
index 0000000..d89f895
Binary files /dev/null and b/mybatis/17-mybatis-MyBatis 初始化（三）之加载 Statement 配置.assets/02.png differ
diff --git a/mybatis/17-mybatis-MyBatis 初始化（三）之加载 Statement 配置.md b/mybatis/17-mybatis-MyBatis 初始化（三）之加载 Statement 配置.md
new file mode 100644
index 0000000..7c0f3c0
--- /dev/null
+++ b/mybatis/17-mybatis-MyBatis 初始化（三）之加载 Statement 配置.md	
@@ -0,0 +1,958 @@
+# 精尽 MyBatis 源码分析 —— MyBatis 初始化（三）之加载 Statement 配置
+
+# 1. 概述
+
+本文接 [《精尽 MyBatis 源码分析 —— MyBatis 初始化（二）之加载 Mapper 映射配置文件》](http://svip.iocoder.cn/MyBatis/builder-package-2) 一文，来分享 MyBatis 初始化的第三步，**加载 Statement 配置**。而这个步骤的入口是 XMLStatementBuilder 。下面，我们一起来看看它的代码实现。
+
+在 [《精尽 MyBatis 源码分析 —— MyBatis 初始化（二）之加载 Mapper 映射配置文件》](http://svip.iocoder.cn/MyBatis/builder-package-2) 的 [「2.3.5 buildStatementFromContext」](https://svip.iocoder.cn/MyBatis/builder-package-3/#) 中，我们已经看到对 XMLStatementBuilder 的调用代码。代码如下：
+
+```
+// XMLMapperBuilder.java
+
+private void buildStatementFromContext(List<XNode> list) {
+    if (configuration.getDatabaseId() != null) {
+        buildStatementFromContext(list, configuration.getDatabaseId());
+    }
+    buildStatementFromContext(list, null);
+    // 上面两块代码，可以简写成 buildStatementFromContext(list, configuration.getDatabaseId());
+}
+
+private void buildStatementFromContext(List<XNode> list, String requiredDatabaseId) {
+    // <1> 遍历 <select /> <insert /> <update /> <delete /> 节点们
+    for (XNode context : list) {
+        // <1> 创建 XMLStatementBuilder 对象，执行解析
+        final XMLStatementBuilder statementParser = new XMLStatementBuilder(configuration, builderAssistant, context, requiredDatabaseId);
+        try {
+            statementParser.parseStatementNode();
+        } catch (IncompleteElementException e) {
+            // <2> 解析失败，添加到 configuration 中
+            configuration.addIncompleteStatement(statementParser);
+        }
+    }
+}
+```
+
+# 2. XMLStatementBuilder
+
+`org.apache.ibatis.builder.xml.XMLStatementBuilder` ，继承 BaseBuilder 抽象类，Statement XML 配置构建器，主要负责解析 Statement 配置，即 `<select />`、`<insert />`、`<update />`、`<delete />` 标签。
+
+## 2.1 构造方法
+
+```
+// XMLStatementBuilder.java
+
+private final MapperBuilderAssistant builderAssistant;
+/**
+ * 当前 XML 节点，例如：<select />、<insert />、<update />、<delete /> 标签
+ */
+private final XNode context;
+/**
+ * 要求的 databaseId
+ */
+private final String requiredDatabaseId;
+
+public XMLStatementBuilder(Configuration configuration, MapperBuilderAssistant builderAssistant, XNode context, String databaseId) {
+    super(configuration);
+    this.builderAssistant = builderAssistant;
+    this.context = context;
+    this.requiredDatabaseId = databaseId;
+}
+```
+
+## 2.2 parseStatementNode
+
+`#parseStatementNode()` 方法，执行 Statement 解析。代码如下：
+
+```
+// XMLStatementBuilder.java
+
+public void parseStatementNode() {
+    // <1> 获得 id 属性，编号。
+    String id = context.getStringAttribute("id");
+    // <2> 获得 databaseId ， 判断 databaseId 是否匹配
+    String databaseId = context.getStringAttribute("databaseId");
+    if (!databaseIdMatchesCurrent(id, databaseId, this.requiredDatabaseId)) {
+        return;
+    }
+
+    // <3> 获得各种属性
+    Integer fetchSize = context.getIntAttribute("fetchSize");
+    Integer timeout = context.getIntAttribute("timeout");
+    String parameterMap = context.getStringAttribute("parameterMap");
+    String parameterType = context.getStringAttribute("parameterType");
+    Class<?> parameterTypeClass = resolveClass(parameterType);
+    String resultMap = context.getStringAttribute("resultMap");
+    String resultType = context.getStringAttribute("resultType");
+    String lang = context.getStringAttribute("lang");
+
+    // <4> 获得 lang 对应的 LanguageDriver 对象
+    LanguageDriver langDriver = getLanguageDriver(lang);
+
+    // <5> 获得 resultType 对应的类
+    Class<?> resultTypeClass = resolveClass(resultType);
+    // <6> 获得 resultSet 对应的枚举值
+    String resultSetType = context.getStringAttribute("resultSetType");
+    ResultSetType resultSetTypeEnum = resolveResultSetType(resultSetType);
+    // <7> 获得 statementType 对应的枚举值
+    StatementType statementType = StatementType.valueOf(context.getStringAttribute("statementType", StatementType.PREPARED.toString()));
+
+    // <8> 获得 SQL 对应的 SqlCommandType 枚举值
+    String nodeName = context.getNode().getNodeName();
+    SqlCommandType sqlCommandType = SqlCommandType.valueOf(nodeName.toUpperCase(Locale.ENGLISH));
+    // <9> 获得各种属性
+    boolean isSelect = sqlCommandType == SqlCommandType.SELECT;
+    boolean flushCache = context.getBooleanAttribute("flushCache", !isSelect);
+    boolean useCache = context.getBooleanAttribute("useCache", isSelect);
+    boolean resultOrdered = context.getBooleanAttribute("resultOrdered", false);
+
+    // Include Fragments before parsing
+    // <10> 创建 XMLIncludeTransformer 对象，并替换 <include /> 标签相关的内容
+    XMLIncludeTransformer includeParser = new XMLIncludeTransformer(configuration, builderAssistant);
+    includeParser.applyIncludes(context.getNode());
+
+    // Parse selectKey after includes and remove them.
+    // <11> 解析 <selectKey /> 标签
+    processSelectKeyNodes(id, parameterTypeClass, langDriver);
+
+    // Parse the SQL (pre: <selectKey> and <include> were parsed and removed)
+    // <12> 创建 SqlSource
+    SqlSource sqlSource = langDriver.createSqlSource(configuration, context, parameterTypeClass);
+    // <13> 获得 KeyGenerator 对象
+    String resultSets = context.getStringAttribute("resultSets");
+    String keyProperty = context.getStringAttribute("keyProperty");
+    String keyColumn = context.getStringAttribute("keyColumn");
+    KeyGenerator keyGenerator;
+    // <13.1> 优先，从 configuration 中获得 KeyGenerator 对象。如果存在，意味着是 <selectKey /> 标签配置的
+    String keyStatementId = id + SelectKeyGenerator.SELECT_KEY_SUFFIX;
+    keyStatementId = builderAssistant.applyCurrentNamespace(keyStatementId, true);
+    if (configuration.hasKeyGenerator(keyStatementId)) {
+        keyGenerator = configuration.getKeyGenerator(keyStatementId);
+    // <13.2> 其次，根据标签属性的情况，判断是否使用对应的 Jdbc3KeyGenerator 或者 NoKeyGenerator 对象
+    } else {
+        keyGenerator = context.getBooleanAttribute("useGeneratedKeys", // 优先，基于 useGeneratedKeys 属性判断
+                configuration.isUseGeneratedKeys() && SqlCommandType.INSERT.equals(sqlCommandType)) // 其次，基于全局的 useGeneratedKeys 配置 + 是否为插入语句类型
+                ? Jdbc3KeyGenerator.INSTANCE : NoKeyGenerator.INSTANCE;
+    }
+
+    // 创建 MappedStatement 对象
+    builderAssistant.addMappedStatement(id, sqlSource, statementType, sqlCommandType,
+            fetchSize, timeout, parameterMap, parameterTypeClass, resultMap, resultTypeClass,
+            resultSetTypeEnum, flushCache, useCache, resultOrdered,
+            keyGenerator, keyProperty, keyColumn, databaseId, langDriver, resultSets);
+}
+```
+
+- `<1>` 处，获得 `id` 属性，编号。
+- `<2>` 处，获得 `databaseId` 属性，并调用 `#databaseIdMatchesCurrent(String id, String databaseId, String requiredDatabaseId)` 方法，判断 `databaseId` 是否匹配。详细解析，见 [「2.3 databaseIdMatchesCurrent」](https://svip.iocoder.cn/MyBatis/builder-package-3/#) 。
+- `<3>` 处，获得各种属性。
+- `<4>` 处，调用 `#getLanguageDriver(String lang)` 方法，获得 `lang` 对应的 LanguageDriver 对象。详细解析，见 [「2.4 getLanguageDriver」](https://svip.iocoder.cn/MyBatis/builder-package-3/#) 。
+- `<5>` 处，获得 `resultType` 对应的类。
+- `<6>` 处，获得 `resultSet` 对应的枚举值。关于 `org.apache.ibatis.mapping.ResultSetType` 枚举类，点击[查看](https://github.com/YunaiV/mybatis-3/blob/master/src/main/java/org/apache/ibatis/mapping/ResultSetType.java)。一般情况下，不会设置该值。它是基于 `java.sql.ResultSet` 结果集的几种模式，感兴趣的话，可以看看 [《ResultSet 的 Type 属性》](http://jinguo.iteye.com/blog/365373) 。
+- `<7>` 处，获得 `statementType` 对应的枚举值。关于 `org.apache.ibatis.mapping.StatementType` 枚举类，点击[查看](https://github.com/YunaiV/mybatis-3/blob/master/src/main/java/org/apache/ibatis/mapping/StatementType.java)。
+- `<8>` 处，获得 SQL 对应的 SqlCommandType 枚举值。
+- `<9>` 处，获得各种属性。
+- `<10>` 处，创建 XMLIncludeTransformer 对象，并调用 `XMLIncludeTransformer#applyIncludes(Node source)` 方法，替换 `<include />` 标签相关的内容。详细解析，见 [「3. XMLIncludeTransformer」](https://svip.iocoder.cn/MyBatis/builder-package-3/#) 。
+- `<11>` 处，调用 `#processSelectKeyNodes(String id, Class<?> parameterTypeClass, LanguageDriver langDriver)` 方法，解析 `<selectKey />` 标签。详细解析，见 [「2.5 processSelectKeyNodes」](https://svip.iocoder.cn/MyBatis/builder-package-3/#) 。
+- `<12>` 处，调用 `LanguageDriver#createSqlSource(Configuration configuration, XNode script, Class<?> parameterType)` 方法，创建 SqlSource 对象。详细解析，见后续文章。
+- `<13>` 处，获得 KeyGenerator 对象。分成 `<13.1>` 和 `<13.2>` 两种情况。具体的，胖友耐心看下代码注释。
+- `<14>` 处，调用 `MapperBuilderAssistant#addMappedStatement(...)` 方法，创建 MappedStatement 对象。详细解析，见 [「4.1 addMappedStatement」](https://svip.iocoder.cn/MyBatis/builder-package-3/#) 中。
+
+## 2.3 databaseIdMatchesCurrent
+
+`#databaseIdMatchesCurrent(String id, String databaseId, String requiredDatabaseId)` 方法，判断 `databaseId` 是否匹配。代码如下：
+
+```
+// XMLStatementBuilder.java
+
+private boolean databaseIdMatchesCurrent(String id, String databaseId, String requiredDatabaseId) {
+    // 如果不匹配，则返回 false
+    if (requiredDatabaseId != null) {
+        return requiredDatabaseId.equals(databaseId);
+    } else {
+        // 如果未设置 requiredDatabaseId ，但是 databaseId 存在，说明还是不匹配，则返回 false
+        // mmp ，写的好绕
+        if (databaseId != null) {
+            return false;
+        }
+        // skip this statement if there is a previous one with a not null databaseId
+        // 判断是否已经存在
+        id = builderAssistant.applyCurrentNamespace(id, false);
+        if (this.configuration.hasStatement(id, false)) {
+            MappedStatement previous = this.configuration.getMappedStatement(id, false); // issue #2
+            // 若存在，则判断原有的 sqlFragment 是否 databaseId 为空。因为，当前 databaseId 为空，这样两者才能匹配。
+            return previous.getDatabaseId() == null;
+        }
+    }
+    return true;
+}
+```
+
+- 代码比较简单，胖友自己瞅瞅就得。从逻辑上，和我们在 XMLMapperBuilder 看到的同名方法 `#databaseIdMatchesCurrent(String id, String databaseId, String requiredDatabaseId)` 方法是一致的。
+
+## 2.4 getLanguageDriver
+
+`#getLanguageDriver(String lang)` 方法，获得 `lang` 对应的 LanguageDriver 对象。代码如下：
+
+```
+// XMLStatementBuilder.java
+
+private LanguageDriver getLanguageDriver(String lang) {
+    // 解析 lang 对应的类
+    Class<? extends LanguageDriver> langClass = null;
+    if (lang != null) {
+        langClass = resolveClass(lang);
+    }
+    // 获得 LanguageDriver 对象
+    return builderAssistant.getLanguageDriver(langClass);
+}
+```
+
+- 调用 `MapperBuilderAssistant#getLanguageDriver(lass<? extends LanguageDriver> langClass)` 方法，获得 LanguageDriver 对象。代码如下：
+
+  ```
+  // MapperBuilderAssistant.java
+  
+  public LanguageDriver getLanguageDriver(Class<? extends LanguageDriver> langClass) {
+      // 获得 langClass 类
+      if (langClass != null) {
+          configuration.getLanguageRegistry().register(langClass);
+      } else { // 如果为空，则使用默认类
+          langClass = configuration.getLanguageRegistry().getDefaultDriverClass();
+      }
+      // 获得 LanguageDriver 对象
+      return configuration.getLanguageRegistry().getDriver(langClass);
+  }
+  ```
+
+  - 关于 `org.apache.ibatis.scripting.LanguageDriverRegistry` 类，我们在后续的文章，详细解析。
+
+## 2.5 processSelectKeyNodes
+
+`#processSelectKeyNodes(String id, Class<?> parameterTypeClass, LanguageDriver langDriver)` 方法，解析 `<selectKey />` 标签。代码如下：
+
+```
+// XMLStatementBuilder.java
+
+private void processSelectKeyNodes(String id, Class<?> parameterTypeClass, LanguageDriver langDriver) {
+    // <1> 获得 <selectKey /> 节点们
+    List<XNode> selectKeyNodes = context.evalNodes("selectKey");
+    // <2> 执行解析 <selectKey /> 节点们
+    if (configuration.getDatabaseId() != null) {
+        parseSelectKeyNodes(id, selectKeyNodes, parameterTypeClass, langDriver, configuration.getDatabaseId());
+    }
+    parseSelectKeyNodes(id, selectKeyNodes, parameterTypeClass, langDriver, null);
+    // <3> 移除 <selectKey /> 节点们
+    removeSelectKeyNodes(selectKeyNodes);
+}
+```
+
+- `<1>` 处，获得 `<selectKey />` 节点们。
+
+- `<2>` 处，调用 `#parseSelectKeyNodes(...)` 方法，执行解析 `<selectKey />` 节点们。详细解析，见 [「2.5.1 parseSelectKeyNodes」](https://svip.iocoder.cn/MyBatis/builder-package-3/#) 。
+
+- `<3>` 处，调用 `#removeSelectKeyNodes(List<XNode> selectKeyNodes)` 方法，移除 `<selectKey />` 节点们。代码如下：
+
+  ```
+  // XMLStatementBuilder.java
+  
+  private void removeSelectKeyNodes(List<XNode> selectKeyNodes) {
+      for (XNode nodeToHandle : selectKeyNodes) {
+          nodeToHandle.getParent().getNode().removeChild(nodeToHandle.getNode());
+      }
+  }
+  ```
+
+### 2.5.1 parseSelectKeyNodes
+
+`#parseSelectKeyNodes(String parentId, List<XNode> list, Class<?> parameterTypeClass, LanguageDriver langDriver, String skRequiredDatabaseId)` 方法，执行解析 `<selectKey />` 子节点们。代码如下：
+
+```
+// XMLStatementBuilder.java
+
+private void parseSelectKeyNodes(String parentId, List<XNode> list, Class<?> parameterTypeClass, LanguageDriver langDriver, String skRequiredDatabaseId) {
+    // <1> 遍历 <selectKey /> 节点们
+    for (XNode nodeToHandle : list) {
+        // <2> 获得完整 id ，格式为 `${id}!selectKey`
+        String id = parentId + SelectKeyGenerator.SELECT_KEY_SUFFIX;
+        // <3> 获得 databaseId ， 判断 databaseId 是否匹配
+        String databaseId = nodeToHandle.getStringAttribute("databaseId");
+        if (databaseIdMatchesCurrent(id, databaseId, skRequiredDatabaseId)) {
+            // <4> 执行解析单个 <selectKey /> 节点
+            parseSelectKeyNode(id, nodeToHandle, parameterTypeClass, langDriver, databaseId);
+        }
+    }
+}
+```
+
+- `<1>` 处，遍历 `<selectKey />` 节点们，逐个处理。
+- `<2>` 处，获得完整 `id` 编号，格式为 `${id}!selectKey` 。这里很重要，最终解析的 `<selectKey />` 节点，会创建成一个 MappedStatement 对象。而该对象的编号，就是 `id` 。
+- `<3>` 处，获得 `databaseId` ，并调用 `#databaseIdMatchesCurrent(String id, String databaseId, String requiredDatabaseId)` 方法，判断 `databaseId` 是否匹配。😈 通过此处，我们可以看到，即使有多个 `<selectionKey />` 节点，但是最终只会有一个节点被解析，就是符合的 `databaseId` 对应的。因为不同的数据库实现不同，对于获取主键的方式也会不同。
+- `<4>` 处，调用 `#parseSelectKeyNode(...)` 方法，执行解析**单个** `<selectKey />` 节点。详细解析，见 [「2.5.2 parseSelectKeyNode」](https://svip.iocoder.cn/MyBatis/builder-package-3/#) 。
+
+### 2.5.2 parseSelectKeyNode
+
+`#parseSelectKeyNode(...)` 方法，执行解析**单个** `<selectKey />` 节点。代码如下：
+
+```
+// XMLStatementBuilder.java
+
+private void parseSelectKeyNode(String id, XNode nodeToHandle, Class<?> parameterTypeClass, LanguageDriver langDriver, String databaseId) {
+    // <1.1> 获得各种属性和对应的类
+    String resultType = nodeToHandle.getStringAttribute("resultType");
+    Class<?> resultTypeClass = resolveClass(resultType);
+    StatementType statementType = StatementType.valueOf(nodeToHandle.getStringAttribute("statementType", StatementType.PREPARED.toString()));
+    String keyProperty = nodeToHandle.getStringAttribute("keyProperty");
+    String keyColumn = nodeToHandle.getStringAttribute("keyColumn");
+    boolean executeBefore = "BEFORE".equals(nodeToHandle.getStringAttribute("order", "AFTER"));
+
+    // defaults
+    // <1.2> 创建 MappedStatement 需要用到的默认值
+    boolean useCache = false;
+    boolean resultOrdered = false;
+    KeyGenerator keyGenerator = NoKeyGenerator.INSTANCE;
+    Integer fetchSize = null;
+    Integer timeout = null;
+    boolean flushCache = false;
+    String parameterMap = null;
+    String resultMap = null;
+    ResultSetType resultSetTypeEnum = null;
+
+    // <1.3> 创建 SqlSource 对象
+    SqlSource sqlSource = langDriver.createSqlSource(configuration, nodeToHandle, parameterTypeClass);
+    SqlCommandType sqlCommandType = SqlCommandType.SELECT;
+
+    // <1.4> 创建 MappedStatement 对象
+    builderAssistant.addMappedStatement(id, sqlSource, statementType, sqlCommandType,
+            fetchSize, timeout, parameterMap, parameterTypeClass, resultMap, resultTypeClass,
+            resultSetTypeEnum, flushCache, useCache, resultOrdered,
+            keyGenerator, keyProperty, keyColumn, databaseId, langDriver, null);
+
+    // <2.1> 获得 SelectKeyGenerator 的编号，格式为 `${namespace}.${id}`
+    id = builderAssistant.applyCurrentNamespace(id, false);
+    // <2.2> 获得 MappedStatement 对象
+    MappedStatement keyStatement = configuration.getMappedStatement(id, false);
+    // <2.3> 创建 SelectKeyGenerator 对象，并添加到 configuration 中
+    configuration.addKeyGenerator(id, new SelectKeyGenerator(keyStatement, executeBefore));
+}
+```
+
+- `<1.1>` 处理，获得各种属性和对应的类。
+
+- `<1.2>` 处理，创建 MappedStatement 需要用到的默认值。
+
+- `<1.3>` 处理，调用 `LanguageDriver#createSqlSource(Configuration configuration, XNode script, Class<?> parameterType)` 方法，创建 SqlSource 对象。详细解析，见后续文章。
+
+- `<1.4>` 处理，调用 `MapperBuilderAssistant#addMappedStatement(...)` 方法，创建 MappedStatement 对象。
+
+- `<2.1>` 处理，获得 SelectKeyGenerator 的编号，格式为 `${namespace}.${id}` 。
+
+- `<2.2>` 处理，获得 MappedStatement 对象。该对象，实际就是 `<1.4>` 处创建的 MappedStatement 对象。
+
+- `<2.3>` 处理，调用 `Configuration#addKeyGenerator(String id, KeyGenerator keyGenerator)` 方法，创建 SelectKeyGenerator 对象，并添加到 `configuration` 中。代码如下：
+
+  ```
+  // Configuration.java
+  
+  /**
+   * KeyGenerator 的映射
+   *
+   * KEY：在 {@link #mappedStatements} 的 KEY 的基础上，跟上 {@link SelectKeyGenerator#SELECT_KEY_SUFFIX}
+   */
+  protected final Map<String, KeyGenerator> keyGenerators = new StrictMap<>("Key Generators collection");
+  
+  public void addKeyGenerator(String id, KeyGenerator keyGenerator) {
+      keyGenerators.put(id, keyGenerator);
+  }
+  ```
+
+# 3. XMLIncludeTransformer
+
+`org.apache.ibatis.builder.xml.XMLIncludeTransformer` ，XML `<include />` 标签的转换器，负责将 SQL 中的 `<include />` 标签转换成对应的 `<sql />` 的内容。
+
+## 3.1 构造方法
+
+```
+// XMLIncludeTransformer.java
+
+private final Configuration configuration;
+private final MapperBuilderAssistant builderAssistant;
+
+public XMLIncludeTransformer(Configuration configuration, MapperBuilderAssistant builderAssistant) {
+    this.configuration = configuration;
+    this.builderAssistant = builderAssistant;
+}
+```
+
+## 3.2 applyIncludes
+
+`#applyIncludes(Node source)` 方法，将 `<include />` 标签，替换成引用的 `<sql />` 。代码如下：
+
+```
+// XMLIncludeTransformer.java
+
+public void applyIncludes(Node source) {
+    // <1> 创建 variablesContext ，并将 configurationVariables 添加到其中
+    Properties variablesContext = new Properties();
+    Properties configurationVariables = configuration.getVariables();
+    if (configurationVariables != null) {
+        variablesContext.putAll(configurationVariables);
+    }
+    // <2> 处理 <include />
+    applyIncludes(source, variablesContext, false);
+}
+```
+
+- `<1>` 处，创建 `variablesContext` ，并将 `configurationVariables` 添加到其中。这里的目的是，避免 `configurationVariables` 被下面使用时候，可能被修改。实际上，从下面的实现上，不存在这个情况。
+- `<2>` 处，调用 `#applyIncludes(Node source, final Properties variablesContext, boolean included)` 方法，处理 `<include />` 。
+
+------
+
+`#applyIncludes(Node source, final Properties variablesContext, boolean included)` 方法，使用递归的方式，将 `<include />` 标签，替换成引用的 `<sql />` 。代码如下：
+
+```
+// XMLIncludeTransformer.java
+
+private void applyIncludes(Node source, final Properties variablesContext, boolean included) {
+    // <1> 如果是 <include /> 标签
+    if (source.getNodeName().equals("include")) {
+        // <1.1> 获得 <sql /> 对应的节点
+        Node toInclude = findSqlFragment(getStringAttribute(source, "refid"), variablesContext);
+        // <1.2> 获得包含 <include /> 标签内的属性
+        Properties toIncludeContext = getVariablesContext(source, variablesContext);
+        // <1.3> 递归调用 #applyIncludes(...) 方法，继续替换。注意，此处是 <sql /> 对应的节点
+        applyIncludes(toInclude, toIncludeContext, true);
+        if (toInclude.getOwnerDocument() != source.getOwnerDocument()) { // 这个情况，艿艿暂时没调试出来
+            toInclude = source.getOwnerDocument().importNode(toInclude, true);
+        }
+        // <1.4> 将 <include /> 节点替换成 <sql /> 节点
+        source.getParentNode().replaceChild(toInclude, source); // 注意，这是一个奇葩的 API ，前者为 newNode ，后者为 oldNode
+        // <1.4> 将 <sql /> 子节点添加到 <sql /> 节点前面
+        while (toInclude.hasChildNodes()) {
+            toInclude.getParentNode().insertBefore(toInclude.getFirstChild(), toInclude); // 这里有个点，一定要注意，卡了艿艿很久。当子节点添加到其它节点下面后，这个子节点会不见了，相当于是“移动操作”
+        }
+        // <1.4> 移除 <include /> 标签自身
+        toInclude.getParentNode().removeChild(toInclude);
+    // <2> 如果节点类型为 Node.ELEMENT_NODE
+    } else if (source.getNodeType() == Node.ELEMENT_NODE) {
+        // <2.1> 如果在处理 <include /> 标签中，则替换其上的属性，例如 <sql id="123" lang="${cpu}"> 的情况，lang 属性是可以被替换的
+        if (included && !variablesContext.isEmpty()) {
+            // replace variables in attribute values
+            NamedNodeMap attributes = source.getAttributes();
+            for (int i = 0; i < attributes.getLength(); i++) {
+                Node attr = attributes.item(i);
+                attr.setNodeValue(PropertyParser.parse(attr.getNodeValue(), variablesContext));
+            }
+        }
+        // <2.2> 遍历子节点，递归调用 #applyIncludes(...) 方法，继续替换
+        NodeList children = source.getChildNodes();
+        for (int i = 0; i < children.getLength(); i++) {
+            applyIncludes(children.item(i), variablesContext, included);
+        }
+    // <3> 如果在处理 <include /> 标签中，并且节点类型为 Node.TEXT_NODE ，并且变量非空
+    // 则进行变量的替换，并修改原节点 source
+    } else if (included && source.getNodeType() == Node.TEXT_NODE
+            && !variablesContext.isEmpty()) {
+        // replace variables in text node
+        source.setNodeValue(PropertyParser.parse(source.getNodeValue(), variablesContext));
+    }
+}
+```
+
+- 这是个有**自递归逻辑**的方法，所以理解起来会有点绕，实际上还是蛮简单的。为了更好的解释，我们假设示例如下：
+
+  ```
+  // mybatis-config.xml
+  
+  <properties>
+      <property name="cpu" value="16c" />
+      <property name="target_sql" value="123" />
+  </properties>
+  
+  // Mapper.xml
+  
+  <sql id="123" lang="${cpu}">
+      ${cpu}
+      aoteman
+      qqqq
+  </sql>
+  
+  <select id="testForInclude">
+      SELECT * FROM subject
+      <include refid="${target_sql}" />
+  </select>
+  ```
+
+- 方法参数 `included` ，是否**正在**处理 `<include />` 标签中。😈 一脸懵逼？不要方，继续往下看。
+
+- 在上述示例的
+
+   
+
+  ```
+  <select />
+  ```
+
+   
+
+  节点进入这个方法时，会首先进入
+
+   
+
+  ```
+  <2>
+  ```
+
+   
+
+  这块逻辑。
+
+  - `<2.1>` 处，因为 不满足 `included` 条件，初始传入是 `false` ，所以跳过。
+
+  - ```
+    <2.2>
+    ```
+
+     
+
+    处，遍历子节点，
+
+    递归
+
+    调用
+
+     
+
+    ```
+    #applyIncludes(...)
+    ```
+
+     
+
+    方法，继续替换。如图所示：
+
+    ![子节点](17-mybatis-MyBatis 初始化（三）之加载 Statement 配置.assets/01.png)
+
+    子节点
+
+    - 子节点 `[0]` 和 `[2]` ，执行该方法时，不满足 `<1>`、`<2>`、`<3>` 任一一种情况，所以可以忽略。虽然说，满足 `<3>` 的节点类型为 `Node.TEXT_NODE` ，但是 `included` 此时为 `false` ，所以不满足。
+    - 子节点 `[1]` ，执行该方法时，满足 `<1>` 的情况，所以走起。
+
+- 在子节点
+
+   
+
+  ```
+  [1]
+  ```
+
+   
+
+  ，即
+
+   
+
+  ```
+  <include />
+  ```
+
+   
+
+  节点进入
+
+   
+
+  ```
+  <1>
+  ```
+
+   
+
+  这块逻辑：
+
+  - `<1.1>` 处，调用 `#findSqlFragment(String refid, Properties variables)` 方法，获得 `<sql />` 对应的节点，即上述示例看到的，`<sql id="123" lang="${cpu}"> ... </>` 。详细解析，见 [「3.3 findSqlFragment」](https://svip.iocoder.cn/MyBatis/builder-package-3/#) 。
+  - `<1.2>` 处，调用 `#getVariablesContext(Node node, Properties inheritedVariablesContext)` 方法，获得包含 `<include />` 标签内的属性 Properties 对象。详细解析，见 [「3.4 getVariablesContext」](https://svip.iocoder.cn/MyBatis/builder-package-3/#) 。
+  - `<1.3>` 处，**递归**调用 `#applyIncludes(...)` 方法，继续替换。注意，此处是 `<sql />` 对应的节点，并且 `included` 参数为 `true` 。详细的结果，见 😈😈😈 处。
+  - `<1.4>` 处，将处理好的 `<sql />` 节点，替换掉 `<include />` 节点。逻辑有丢丢绕，胖友耐心看下注释，好好思考。
+
+- 😈😈😈 在
+
+   
+
+  ```
+  <sql />
+  ```
+
+   
+
+  节点，会进入
+
+   
+
+  ```
+  <2>
+  ```
+
+   
+
+  这块逻辑：
+
+  - `<2.1>` 处，因为 `included` 为 `true` ，所以能满足这块逻辑，会进行执行。如 `<sql id="123" lang="${cpu}">` 的情况，`lang` 属性是可以被替换的。
+
+  - ```
+    <2.2>
+    ```
+
+     
+
+    处，遍历子节点，
+
+    递归
+
+    调用
+
+     
+
+    ```
+    #applyIncludes(...)
+    ```
+
+     
+
+    方法，继续替换。如图所示：
+
+    ![子节点](17-mybatis-MyBatis 初始化（三）之加载 Statement 配置.assets/02.png)
+
+    子节点
+
+    - 子节点 `[0]` ，执行该方法时，满足 `<3>` 的情况，所以可以使用变量 Properteis 对象，进行替换，并修改原节点。
+
+其实，整理一下，逻辑也不会很绕。耐心耐心耐心。
+
+## 3.3 findSqlFragment
+
+`#findSqlFragment(String refid, Properties variables)` 方法，获得对应的 `<sql />` 节点。代码如下：
+
+```
+// XMLIncludeTransformer.java
+
+private Node findSqlFragment(String refid, Properties variables) {
+    // 因为 refid 可能是动态变量，所以进行替换
+    refid = PropertyParser.parse(refid, variables);
+    // 获得完整的 refid ，格式为 "${namespace}.${refid}"
+    refid = builderAssistant.applyCurrentNamespace(refid, true);
+    try {
+        // 获得对应的 <sql /> 节点
+        XNode nodeToInclude = configuration.getSqlFragments().get(refid);
+        // 获得 Node 节点，进行克隆
+        return nodeToInclude.getNode().cloneNode(true);
+    } catch (IllegalArgumentException e) {
+        throw new IncompleteElementException("Could not find SQL statement to include with refid '" + refid + "'", e);
+    }
+}
+
+private String getStringAttribute(Node node, String name) {
+    return node.getAttributes().getNamedItem(name).getNodeValue();
+}
+```
+
+- 比较简单，胖友瞅瞅注释。
+
+## 3.4 getVariablesContext
+
+`#getVariablesContext(Node node, Properties inheritedVariablesContext)` 方法，获得包含 `<include />` 标签内的属性 Properties 对象。代码如下：
+
+```
+// XMLIncludeTransformer.java
+
+private Properties getVariablesContext(Node node, Properties inheritedVariablesContext) {
+    // 获得 <include /> 标签的属性集合
+    Map<String, String> declaredProperties = null;
+    NodeList children = node.getChildNodes();
+    for (int i = 0; i < children.getLength(); i++) {
+        Node n = children.item(i);
+        if (n.getNodeType() == Node.ELEMENT_NODE) {
+            String name = getStringAttribute(n, "name");
+            // Replace variables inside
+            String value = PropertyParser.parse(getStringAttribute(n, "value"), inheritedVariablesContext);
+            if (declaredProperties == null) {
+                declaredProperties = new HashMap<>();
+            }
+            if (declaredProperties.put(name, value) != null) { // 如果重复定义，抛出异常
+                throw new BuilderException("Variable " + name + " defined twice in the same include definition");
+            }
+        }
+    }
+    // 如果 <include /> 标签内没有属性，直接使用 inheritedVariablesContext 即可
+    if (declaredProperties == null) {
+        return inheritedVariablesContext;
+    // 如果 <include /> 标签内有属性，则创建新的 newProperties 集合，将 inheritedVariablesContext + declaredProperties 合并
+    } else {
+        Properties newProperties = new Properties();
+        newProperties.putAll(inheritedVariablesContext);
+        newProperties.putAll(declaredProperties);
+        return newProperties;
+    }
+}
+```
+
+- 比较简单，胖友瞅瞅注释。
+
+- 如下是 `<include />` 标签内有属性的示例：
+
+  ```
+  <sql id="userColumns"> ${alias}.id,${alias}.username,${alias}.password </sql>
+  
+  <select id="selectUsers" resultType="map">
+    select
+      <include refid="userColumns"><property name="alias" value="t1"/></include>,
+      <include refid="userColumns"><property name="alias" value="t2"/></include>
+    from some_table t1
+      cross join some_table t2
+  </select>
+  ```
+
+# 4. MapperBuilderAssistant
+
+## 4.1 addMappedStatement
+
+`#addMappedStatement(String id, SqlSource sqlSource, StatementType statementType, SqlCommandType sqlCommandType, Integer fetchSize, Integer timeout, String parameterMap, Class<?> parameterType, String resultMap, Class<?> resultType, ResultSetType resultSetType, boolean flushCache, boolean useCache, boolean resultOrdered, KeyGenerator keyGenerator, String keyProperty, String keyColumn, String databaseId, LanguageDriver lang, String resultSets)` 方法，构建 MappedStatement 对象。代码如下：
+
+```
+// MapperBuilderAssistant.java
+
+public MappedStatement addMappedStatement(
+        String id,
+        SqlSource sqlSource,
+        StatementType statementType,
+        SqlCommandType sqlCommandType,
+        Integer fetchSize,
+        Integer timeout,
+        String parameterMap,
+        Class<?> parameterType,
+        String resultMap,
+        Class<?> resultType,
+        ResultSetType resultSetType,
+        boolean flushCache,
+        boolean useCache,
+        boolean resultOrdered,
+        KeyGenerator keyGenerator,
+        String keyProperty,
+        String keyColumn,
+        String databaseId,
+        LanguageDriver lang,
+        String resultSets) {
+
+    // <1> 如果只想的 Cache 未解析，抛出 IncompleteElementException 异常
+    if (unresolvedCacheRef) {
+        throw new IncompleteElementException("Cache-ref not yet resolved");
+    }
+
+    // <2> 获得 id 编号，格式为 `${namespace}.${id}`
+    id = applyCurrentNamespace(id, false);
+    boolean isSelect = sqlCommandType == SqlCommandType.SELECT;
+
+    // <3> 创建 MappedStatement.Builder 对象
+    MappedStatement.Builder statementBuilder = new MappedStatement.Builder(configuration, id, sqlSource, sqlCommandType)
+            .resource(resource)
+            .fetchSize(fetchSize)
+            .timeout(timeout)
+            .statementType(statementType)
+            .keyGenerator(keyGenerator)
+            .keyProperty(keyProperty)
+            .keyColumn(keyColumn)
+            .databaseId(databaseId)
+            .lang(lang)
+            .resultOrdered(resultOrdered)
+            .resultSets(resultSets)
+            .resultMaps(getStatementResultMaps(resultMap, resultType, id)) // <3.1> 获得 ResultMap 集合
+            .resultSetType(resultSetType)
+            .flushCacheRequired(valueOrDefault(flushCache, !isSelect))
+            .useCache(valueOrDefault(useCache, isSelect))
+            .cache(currentCache);
+
+    // <3.2> 获得 ParameterMap ，并设置到 MappedStatement.Builder 中
+    ParameterMap statementParameterMap = getStatementParameterMap(parameterMap, parameterType, id);
+    if (statementParameterMap != null) {
+        statementBuilder.parameterMap(statementParameterMap);
+    }
+
+    // <4> 创建 MappedStatement 对象
+    MappedStatement statement = statementBuilder.build();
+    // <5> 添加到 configuration 中
+    configuration.addMappedStatement(statement);
+    return statement;
+}
+```
+
+- `<1>` 处，如果只想的 Cache 未解析，抛出 IncompleteElementException 异常。
+
+- `<2>` 处，获得 `id` 编号，格式为 `${namespace}.${id}` 。
+
+- ```
+  <3>
+  ```
+
+   
+
+  处，创建 MappedStatement.Builder 对象。详细解析，见
+
+   
+
+  「4.1.3 MappedStatement」
+
+   
+
+  。
+
+  - `<3.1>` 处，调用 `#getStatementResultMaps(...)` 方法，获得 ResultMap 集合。详细解析，见 [「4.1.3 getStatementResultMaps」](https://svip.iocoder.cn/MyBatis/builder-package-3/#) 。
+  - `<3.2>` 处，调用 `#getStatementParameterMap(...)` 方法，获得 ParameterMap ，并设置到 MappedStatement.Builder 中。详细解析，见 [4.1.4 getStatementResultMaps」](https://svip.iocoder.cn/MyBatis/builder-package-3/#) 。
+
+- `<4>` 处，创建 MappedStatement 对象。详细解析，见 [「4.1.1 MappedStatement」](https://svip.iocoder.cn/MyBatis/builder-package-3/#) 。
+
+- `<5>` 处，调用 `Configuration#addMappedStatement(statement)` 方法，添加到 `configuration` 中。代码如下：
+
+  ```
+  // Configuration.java
+  
+  /**
+   * MappedStatement 映射
+   *
+   * KEY：`${namespace}.${id}`
+   */
+  protected final Map<String, MappedStatement> mappedStatements = new StrictMap<>("Mapped Statements collection");
+  
+  public void addMappedStatement(MappedStatement ms) {
+      mappedStatements.put(ms.getId(), ms);
+  }
+  ```
+
+### 4.1.1 MappedStatement
+
+`org.apache.ibatis.mapping.MappedStatement` ，映射的语句，每个 `<select />`、`<insert />`、`<update />`、`<delete />` 对应一个 MappedStatement 对象。代码比较简单，但是有点略长，胖友直接点击 [链接](https://github.com/YunaiV/mybatis-3/blob/master/src/main/java/org/apache/ibatis/mapping/MappedStatement.java) 查看，已经添加了完整的注释。
+
+另外，比较特殊的是，`<selectKey />` 解析后，也会对应一个 MappedStatement 对象。
+
+在另外，MappedStatement 有一个非常重要的方法 `#getBoundSql(Object parameterObject)` 方法，获得 BoundSql 对象。代码如下：
+
+```
+// MappedStatement.java
+
+public BoundSql getBoundSql(Object parameterObject) {
+    // 获得 BoundSql 对象
+    BoundSql boundSql = sqlSource.getBoundSql(parameterObject);
+    // 忽略，因为 <parameterMap /> 已经废弃，参见 http://www.mybatis.org/mybatis-3/zh/sqlmap-xml.html 文档
+    List<ParameterMapping> parameterMappings = boundSql.getParameterMappings();
+    if (parameterMappings == null || parameterMappings.isEmpty()) {
+        boundSql = new BoundSql(configuration, boundSql.getSql(), parameterMap.getParameterMappings(), parameterObject);
+    }
+
+    // check for nested result maps in parameter mappings (issue #30)
+    // 判断传入的参数中，是否有内嵌的结果 ResultMap 。如果有，则修改 hasNestedResultMaps 为 true
+    // 存储过程相关，暂时无视
+    for (ParameterMapping pm : boundSql.getParameterMappings()) {
+        String rmId = pm.getResultMapId();
+        if (rmId != null) {
+            ResultMap rm = configuration.getResultMap(rmId);
+            if (rm != null) {
+                hasNestedResultMaps |= rm.hasNestedResultMaps();
+            }
+        }
+    }
+
+    return boundSql;
+}
+```
+
+- 需要结合后续文章 [《精尽 MyBatis 源码分析 —— SQL 初始化（下）之 SqlSource》](http://svip.iocoder.cn/MyBatis/scripting-2) 。胖友可以看完那篇文章后，再回过头看这个方法。
+
+### 4.1.2 ParameterMap
+
+`org.apache.ibatis.mapping.ParameterMap` ，参数集合，对应 `paramType=""` 或 `paramMap=""` 标签属性。代码比较简单，但是有点略长，胖友直接点击 [链接](https://github.com/YunaiV/mybatis-3/blob/master/src/main/java/org/apache/ibatis/mapping/ParameterMap.java) 查看，已经添加了完整的注释。
+
+### 4.1.3 getStatementResultMaps
+
+`#getStatementResultMaps(...)` 方法，获得 ResultMap 集合。代码如下：
+
+```
+// MapperBuilderAssistant.java
+
+private List<ResultMap> getStatementResultMaps(
+        String resultMap,
+        Class<?> resultType,
+        String statementId) {
+    // 获得 resultMap 的编号
+    resultMap = applyCurrentNamespace(resultMap, true);
+
+    // 创建 ResultMap 集合
+    List<ResultMap> resultMaps = new ArrayList<>();
+    // 如果 resultMap 非空，则获得 resultMap 对应的 ResultMap 对象(们）
+    if (resultMap != null) {
+        String[] resultMapNames = resultMap.split(",");
+        for (String resultMapName : resultMapNames) {
+            try {
+                resultMaps.add(configuration.getResultMap(resultMapName.trim())); // 从 configuration 中获得
+            } catch (IllegalArgumentException e) {
+                throw new IncompleteElementException("Could not find result map " + resultMapName, e);
+            }
+        }
+    // 如果 resultType 非空，则创建 ResultMap 对象
+    } else if (resultType != null) {
+        ResultMap inlineResultMap = new ResultMap.Builder(
+                configuration,
+                statementId + "-Inline",
+                resultType,
+                new ArrayList<>(),
+                null).build();
+        resultMaps.add(inlineResultMap);
+    }
+    return resultMaps;
+}
+```
+
+- 整体代码比较简单，胖友自己看下。
+- 比较奇怪的是，方法参数 `resultMap` 存在使用逗号分隔的情况。这个出现在使用存储过程的时候，参见 [《mybatis调用存储过程返回多个结果集》](https://blog.csdn.net/sinat_25295611/article/details/75103358) 。
+
+### 4.1.4 getStatementResultMaps
+
+`#getStatementParameterMap(...)` 方法，获得 ParameterMap 对象。代码如下：
+
+```
+// MapperBuilderAssistant.java
+
+private ParameterMap getStatementParameterMap(
+        String parameterMapName,
+        Class<?> parameterTypeClass,
+        String statementId) {
+    // 获得 ParameterMap 的编号，格式为 `${namespace}.${parameterMapName}`
+    parameterMapName = applyCurrentNamespace(parameterMapName, true);
+    ParameterMap parameterMap = null;
+    // <2> 如果 parameterMapName 非空，则获得 parameterMapName 对应的 ParameterMap 对象
+    if (parameterMapName != null) {
+        try {
+            parameterMap = configuration.getParameterMap(parameterMapName);
+        } catch (IllegalArgumentException e) {
+            throw new IncompleteElementException("Could not find parameter map " + parameterMapName, e);
+        }
+    // <1> 如果 parameterTypeClass 非空，则创建 ParameterMap 对象
+    } else if (parameterTypeClass != null) {
+        List<ParameterMapping> parameterMappings = new ArrayList<>();
+        parameterMap = new ParameterMap.Builder(
+                configuration,
+                statementId + "-Inline",
+                parameterTypeClass,
+                parameterMappings).build();
+    }
+    return parameterMap;
+}
+```
+
+- 主要看 `<1>` 处，如果 `parameterTypeClass` 非空，则创建 ParameterMap 对象。
+- 关于 `<2>` 处，MyBatis 官方不建议使用 `parameterMap` 的方式。
+
+# 666. 彩蛋
+
+相比 [《精尽 MyBatis 源码分析 —— MyBatis 初始化（二）之加载 Mapper 映射配置文件》](http://svip.iocoder.cn/MyBatis/builder-package-2) 来说，简单太多太多，可能就 XMLIncludeTransformer 相对绕一丢丢。总的来说，轻松蛮多。
+
+- 祖大俊 [《Mybatis3.3.x技术内幕（十）：Mybatis初始化流程（下）》](https://my.oschina.net/zudajun/blog/669868)
+- 祖大俊 [《Mybatis3.4.x技术内幕（十六）：Mybatis之sqlFragment（可复用的sql片段）》](https://my.oschina.net/zudajun/blog/687326)
+- 徐郡明 [《MyBatis 技术内幕》](https://item.jd.com/12125531.html) 的 [「3.1 MyBatis 初始化」](https://svip.iocoder.cn/MyBatis/builder-package-3/#) 小节
\ No newline at end of file
diff --git a/mybatis/18-mybatis-MyBatis 初始化（四）之加载注解配置.md b/mybatis/18-mybatis-MyBatis 初始化（四）之加载注解配置.md
new file mode 100644
index 0000000..920ea99
--- /dev/null
+++ b/mybatis/18-mybatis-MyBatis 初始化（四）之加载注解配置.md	
@@ -0,0 +1,1258 @@
+# 精尽 MyBatis 源码分析 —— MyBatis 初始化（四）之加载注解配置
+
+# 1. 概述
+
+本文接 [《精尽 MyBatis 源码分析 —— MyBatis 初始化（三）之加载 Statement 配置》](http://svip.iocoder.cn/MyBatis/builder-package-3) 一文，来分享 MyBatis 初始化的第 2 步的一部分，**加载注解配置**。而这个部分的入口是 MapperAnnotationBuilder 。下面，我们一起来看看它的代码实现。
+
+在 [《精尽 MyBatis 源码分析 —— MyBatis 初始化（二）之加载 Mapper 映射配置文件》](http://svip.iocoder.cn/MyBatis/builder-package-2) 的 [「3.3.13 mapperElement」](https://svip.iocoder.cn/MyBatis/builder-package-4/#) 中，我们已经看到对 MapperAnnotationBuilder 的调用代码。代码如下：
+
+```
+// Configuration.java
+    
+public <T> void addMapper(Class<T> type) {
+    mapperRegistry.addMapper(type);
+}
+
+// MapperRegistry.java
+
+public <T> void addMapper(Class<T> type) {
+    // 判断，必须是接口。
+    if (type.isInterface()) {
+        // 已经添加过，则抛出 BindingException 异常
+        if (hasMapper(type)) {
+            throw new BindingException("Type " + type + " is already known to the MapperRegistry.");
+        }
+        boolean loadCompleted = false;
+        try {
+            // 添加到 knownMappers 中
+            knownMappers.put(type, new MapperProxyFactory<>(type));
+            // It's important that the type is added before the parser is run
+            // otherwise the binding may automatically be attempted by the
+            // mapper parser. If the type is already known, it won't try.
+            // 解析 Mapper 的注解配置 <====== 😈 看我 😈 =====>
+            MapperAnnotationBuilder parser = new MapperAnnotationBuilder(config, type);
+            parser.parse();
+            // 标记加载完成
+            loadCompleted = true;
+        } finally {
+            // 若加载未完成，从 knownMappers 中移除
+            if (!loadCompleted) {
+                knownMappers.remove(type);
+            }
+        }
+    }
+}
+```
+
+- 调用处，请看 😈 处。
+
+# 2. MapperAnnotationBuilder
+
+`org.apache.ibatis.builder.annotation.MapperAnnotationBuilder` ，Mapper 注解构造器，负责解析 Mapper 接口上的注解。
+
+## 2.1 构造方法
+
+```
+// MapperAnnotationBuilder.java
+
+/**
+ * SQL 操作注解集合
+ */
+private static final Set<Class<? extends Annotation>> SQL_ANNOTATION_TYPES = new HashSet<>();
+/**
+ * SQL 操作提供者注解集合
+ */
+private static final Set<Class<? extends Annotation>> SQL_PROVIDER_ANNOTATION_TYPES = new HashSet<>();
+
+private final Configuration configuration;
+private final MapperBuilderAssistant assistant;
+/**
+ * Mapper 接口类
+ */
+private final Class<?> type;
+
+static {
+    SQL_ANNOTATION_TYPES.add(Select.class);
+    SQL_ANNOTATION_TYPES.add(Insert.class);
+    SQL_ANNOTATION_TYPES.add(Update.class);
+    SQL_ANNOTATION_TYPES.add(Delete.class);
+
+    SQL_PROVIDER_ANNOTATION_TYPES.add(SelectProvider.class);
+    SQL_PROVIDER_ANNOTATION_TYPES.add(InsertProvider.class);
+    SQL_PROVIDER_ANNOTATION_TYPES.add(UpdateProvider.class);
+    SQL_PROVIDER_ANNOTATION_TYPES.add(DeleteProvider.class);
+}
+
+public MapperAnnotationBuilder(Configuration configuration, Class<?> type) {
+    // 创建 MapperBuilderAssistant 对象
+    String resource = type.getName().replace('.', '/') + ".java (best guess)";
+    this.assistant = new MapperBuilderAssistant(configuration, resource);
+    this.configuration = configuration;
+    this.type = type;
+}
+```
+
+- 比较简单，胖友扫一眼。
+
+## 2.2 parse
+
+`#parse()` 方法，解析注解。代码如下：
+
+```
+// MapperAnnotationBuilder.java
+
+public void parse() {
+    // <1> 判断当前 Mapper 接口是否应加载过。
+    String resource = type.toString();
+    if (!configuration.isResourceLoaded(resource)) {
+        // <2> 加载对应的 XML Mapper
+        loadXmlResource();
+        // <3> 标记该 Mapper 接口已经加载过
+        configuration.addLoadedResource(resource);
+        // <4> 设置 namespace 属性
+        assistant.setCurrentNamespace(type.getName());
+        // <5> 解析 @CacheNamespace 注解
+        parseCache();
+        // <6> 解析 @CacheNamespaceRef 注解
+        parseCacheRef();
+        // <7> 遍历每个方法，解析其上的注解
+        Method[] methods = type.getMethods();
+        for (Method method : methods) {
+            try {
+                // issue #237
+                if (!method.isBridge()) {
+                    // <7.1> 执行解析
+                    parseStatement(method);
+                }
+            } catch (IncompleteElementException e) {
+                // <7.2> 解析失败，添加到 configuration 中
+                configuration.addIncompleteMethod(new MethodResolver(this, method));
+            }
+        }
+    }
+    // <8> 解析待定的方法
+    parsePendingMethods();
+}
+```
+
+- `<1>` 处，调用 `Configuration#isResourceLoaded(String resource)` 方法，判断当前 Mapper 接口是否应加载过。
+
+- `<2>` 处，调用 `#loadXmlResource()` 方法，加载对应的 XML Mapper 。详细解析，见 [「2.3 loadXmlResource」](https://svip.iocoder.cn/MyBatis/builder-package-4/#) 。
+
+- `<3>` 处，调用 `Configuration#addLoadedResource(String resource)` 方法，标记该 Mapper 接口已经加载过。
+
+- `<4>` 处，调用 `MapperBuilderAssistant#setCurrentNamespace(String currentNamespace)` 方法，设置 `namespace` 属性。
+
+- `<5>` 处，调用 `#parseCache()` 方法，`@CacheNamespace` 注解。详细解析，见 [「2.4 parseCache」](https://svip.iocoder.cn/MyBatis/builder-package-4/#) 。
+
+- `<6>` 处，调用 `#parseCacheRef()` 方法，`@CacheNamespaceRef` 注解。详细解析，见 [「2.5 parseCacheRef」](https://svip.iocoder.cn/MyBatis/builder-package-4/#) 。
+
+- `<7>` 处，遍历每个方法，解析其上的注解。
+
+  - `<7.1>` 处，调用 `#parseStatement(Method method)` 方法，执行解析每个方法的注解。详细解析，见 [「2.6 parseStatement」](https://svip.iocoder.cn/MyBatis/builder-package-4/#) 。
+
+  - `<7.2>` 处，解析失败，调用 `Configuration#addIncompleteMethod(MethodResolver builder)` 方法，添加到 `configuration` 中。代码如下：
+
+    ```
+    // Configuration.java
+    
+    /**
+     * 未完成的 MethodResolver 集合
+     */
+    protected final Collection<MethodResolver> incompleteMethods = new LinkedList<>();
+    
+    public void addIncompleteMethod(MethodResolver builder) {
+        incompleteMethods.add(builder);
+    }
+    ```
+
+    - 关于 MethodResolver 类，详细解析，见 [「2.7 MethodResolver」](https://svip.iocoder.cn/MyBatis/builder-package-4/#) 。
+
+- `<8>` 处，调用 `#parsePendingMethods()` 方法，解析待定的方法。详细解析，见 [「2.8 parsePendingMethods」](https://svip.iocoder.cn/MyBatis/builder-package-4/#) 。
+
+## 2.3 loadXmlResource
+
+`#loadXmlResource()` 方法，加载对应的 XML Mapper 。代码如下：
+
+```
+// MapperAnnotationBuilder.java
+
+private void loadXmlResource() {
+    // Spring may not know the real resource name so we check a flag
+    // to prevent loading again a resource twice
+    // this flag is set at XMLMapperBuilder#bindMapperForNamespace
+    // <1> 判断 Mapper XML 是否已经加载过，如果加载过，就不加载了。
+    // 此处，是为了避免和 XMLMapperBuilder#parse() 方法冲突，重复解析
+    if (!configuration.isResourceLoaded("namespace:" + type.getName())) {
+        // <2> 获得 InputStream 对象
+        String xmlResource = type.getName().replace('.', '/') + ".xml";
+        // #1347
+        InputStream inputStream = type.getResourceAsStream("/" + xmlResource);
+        if (inputStream == null) {
+            // Search XML mapper that is not in the module but in the classpath.
+            try {
+                inputStream = Resources.getResourceAsStream(type.getClassLoader(), xmlResource);
+            } catch (IOException e2) {
+                // ignore, resource is not required
+            }
+        }
+        // <2> 创建 XMLMapperBuilder 对象，执行解析
+        if (inputStream != null) {
+            XMLMapperBuilder xmlParser = new XMLMapperBuilder(inputStream, assistant.getConfiguration(), xmlResource, configuration.getSqlFragments(), type.getName());
+            xmlParser.parse();
+        }
+    }
+}
+```
+
+- `<1>` 处，判断 Mapper XML 是否已经加载过，如果加载过，就不加载了。此处，是为了避免和 `XMLMapperBuilder#parse()` 方法冲突，重复解析。
+- `<2>` 处，获得 InputStream 对象，然后创建 XMLMapperBuilder 对象，最后调用 `XMLMapperBuilder#parse()` 方法，执行解析。
+- 这里，如果是先解析 Mapper 接口，那就会达到再解析对应的 Mapper XML 的情况。
+
+## 2.4 parseCache
+
+`#parseCache()` 方法，解析 `@CacheNamespace` 注解。代码如下：
+
+```
+// MapperAnnotationBuilder.java
+
+private void parseCache() {
+    // <1> 获得类上的 @CacheNamespace 注解
+    CacheNamespace cacheDomain = type.getAnnotation(CacheNamespace.class);
+    if (cacheDomain != null) {
+        // <2> 获得各种属性
+        Integer size = cacheDomain.size() == 0 ? null : cacheDomain.size();
+        Long flushInterval = cacheDomain.flushInterval() == 0 ? null : cacheDomain.flushInterval();
+        // <3> 获得 Properties 属性
+        Properties props = convertToProperties(cacheDomain.properties());
+        // <4> 创建 Cache 对象
+        assistant.useNewCache(cacheDomain.implementation(), cacheDomain.eviction(), flushInterval, size, cacheDomain.readWrite(), cacheDomain.blocking(), props);
+    }
+}
+```
+
+- `<1>` 处，获得**类**上的 `@CacheNamespace` 注解。
+
+- `<2>` 处，获得各种属性。
+
+- `<3>` 处，调用 `#convertToProperties(Property[] properties)` 方法，将 `@Property` 注解数组，转换成 Properties 对象。代码如下：
+
+  ```
+  // MapperAnnotationBuilder.java
+  
+  private Properties convertToProperties(Property[] properties) {
+      if (properties.length == 0) {
+          return null;
+      }
+      Properties props = new Properties();
+      for (Property property : properties) {
+          props.setProperty(property.name(),
+                  PropertyParser.parse(property.value(), configuration.getVariables())); // 替换
+      }
+      return props;
+  }
+  ```
+
+- `<4>` 处，调用 `MapperBuilderAssistant#useNewCache(...)` 方法，创建 Cache 对象。在 [《精尽 MyBatis 源码分析 —— MyBatis 初始化（二）之加载 Mapper 映射配置文件》](http://svip.iocoder.cn/MyBatis/builder-package-2) 的 [「3.4 useNewCache」](https://svip.iocoder.cn/MyBatis/builder-package-4/#) 中，已经详细解析。
+
+## 2.5 parseCacheRef
+
+`#parseCacheRef()` 方法，解析 `@CacheNamespaceRef` 注解。代码如下：
+
+```
+// MapperAnnotationBuilder.java
+
+private void parseCacheRef() {
+    // 获得类上的 @CacheNamespaceRef 注解
+    CacheNamespaceRef cacheDomainRef = type.getAnnotation(CacheNamespaceRef.class);
+    if (cacheDomainRef != null) {
+        // <2> 获得各种属性
+        Class<?> refType = cacheDomainRef.value();
+        String refName = cacheDomainRef.name();
+        // <2> 校验，如果 refType 和 refName 都为空，则抛出 BuilderException 异常
+        if (refType == void.class && refName.isEmpty()) {
+            throw new BuilderException("Should be specified either value() or name() attribute in the @CacheNamespaceRef");
+        }
+        // <2> 校验，如果 refType 和 refName 都不为空，则抛出 BuilderException 异常
+        if (refType != void.class && !refName.isEmpty()) {
+            throw new BuilderException("Cannot use both value() and name() attribute in the @CacheNamespaceRef");
+        }
+        // <2> 获得最终的 namespace 属性
+        String namespace = (refType != void.class) ? refType.getName() : refName;
+        // <3> 获得指向的 Cache 对象
+        assistant.useCacheRef(namespace);
+    }
+}
+```
+
+- `<1>` 处，获得**类**上的 `@CacheNamespaceRef` 注解。
+- `<2>` 处，获得各种属性，进行校验，最终获得 `namespace` 属性。
+- `<3>` 处，调用 `MapperBuilderAssistant#useCacheRef(String namespace)` 方法，获得指向的 Cache 对象。在 [《精尽 MyBatis 源码分析 —— MyBatis 初始化（二）之加载 Mapper 映射配置文件》](http://svip.iocoder.cn/MyBatis/builder-package-2) 的 [「3.3 useCacheRef」](https://svip.iocoder.cn/MyBatis/builder-package-4/#) 中，已经详细解析。
+
+## 2.6 parseStatement
+
+`#parseStatement(Method method)` 方法，解析方法上的 SQL 操作相关的注解。代码如下：
+
+```
+// MapperAnnotationBuilder.java
+
+void parseStatement(Method method) {
+    // <1> 获得参数的类型
+    Class<?> parameterTypeClass = getParameterType(method);
+    // <2> 获得 LanguageDriver 对象
+    LanguageDriver languageDriver = getLanguageDriver(method);
+    // <3> 获得 SqlSource 对象
+    SqlSource sqlSource = getSqlSourceFromAnnotations(method, parameterTypeClass, languageDriver);
+    if (sqlSource != null) {
+        // <4> 获得各种属性
+        Options options = method.getAnnotation(Options.class);
+        final String mappedStatementId = type.getName() + "." + method.getName();
+        Integer fetchSize = null;
+        Integer timeout = null;
+        StatementType statementType = StatementType.PREPARED;
+        ResultSetType resultSetType = null;
+        SqlCommandType sqlCommandType = getSqlCommandType(method);
+        boolean isSelect = sqlCommandType == SqlCommandType.SELECT;
+        boolean flushCache = !isSelect;
+        boolean useCache = isSelect;
+
+        // <5> 获得 KeyGenerator 对象
+        KeyGenerator keyGenerator;
+        String keyProperty = null;
+        String keyColumn = null;
+        if (SqlCommandType.INSERT.equals(sqlCommandType) || SqlCommandType.UPDATE.equals(sqlCommandType)) { // 有
+            // first check for SelectKey annotation - that overrides everything else
+            // <5.1> 如果有 @SelectKey 注解，则进行处理
+            SelectKey selectKey = method.getAnnotation(SelectKey.class);
+            if (selectKey != null) {
+                keyGenerator = handleSelectKeyAnnotation(selectKey, mappedStatementId, getParameterType(method), languageDriver);
+                keyProperty = selectKey.keyProperty();
+            // <5.2> 如果无 @Options 注解，则根据全局配置处理
+            } else if (options == null) {
+                keyGenerator = configuration.isUseGeneratedKeys() ? Jdbc3KeyGenerator.INSTANCE : NoKeyGenerator.INSTANCE;
+            // <5.3> 如果有 @Options 注解，则使用该注解的配置处理
+            } else {
+                keyGenerator = options.useGeneratedKeys() ? Jdbc3KeyGenerator.INSTANCE : NoKeyGenerator.INSTANCE;
+                keyProperty = options.keyProperty();
+                keyColumn = options.keyColumn();
+            }
+        // <5.4> 无
+        } else {
+            keyGenerator = NoKeyGenerator.INSTANCE;
+        }
+
+        // <6> 初始化各种属性
+        if (options != null) {
+            if (FlushCachePolicy.TRUE.equals(options.flushCache())) {
+                flushCache = true;
+            } else if (FlushCachePolicy.FALSE.equals(options.flushCache())) {
+                flushCache = false;
+            }
+            useCache = options.useCache();
+            fetchSize = options.fetchSize() > -1 || options.fetchSize() == Integer.MIN_VALUE ? options.fetchSize() : null; //issue #348
+            timeout = options.timeout() > -1 ? options.timeout() : null;
+            statementType = options.statementType();
+            resultSetType = options.resultSetType();
+        }
+
+        // <7> 获得 resultMapId 编号字符串
+        String resultMapId = null;
+        // <7.1> 如果有 @ResultMap 注解，使用该注解为 resultMapId 属性
+        ResultMap resultMapAnnotation = method.getAnnotation(ResultMap.class);
+        if (resultMapAnnotation != null) {
+            String[] resultMaps = resultMapAnnotation.value();
+            StringBuilder sb = new StringBuilder();
+            for (String resultMap : resultMaps) {
+                if (sb.length() > 0) {
+                    sb.append(",");
+                }
+                sb.append(resultMap);
+            }
+            resultMapId = sb.toString();
+        // <7.2> 如果无 @ResultMap 注解，解析其它注解，作为 resultMapId 属性
+        } else if (isSelect) {
+            resultMapId = parseResultMap(method);
+        }
+
+        // 构建 MappedStatement 对象
+        assistant.addMappedStatement(
+                mappedStatementId,
+                sqlSource,
+                statementType,
+                sqlCommandType,
+                fetchSize,
+                timeout,
+                // ParameterMapID
+                null,
+                parameterTypeClass,
+                resultMapId,
+                getReturnType(method), // 获得返回类型
+                resultSetType,
+                flushCache,
+                useCache,
+                // TODO gcode issue #577
+                false,
+                keyGenerator,
+                keyProperty,
+                keyColumn,
+                // DatabaseID
+                null,
+                languageDriver,
+                // ResultSets
+                options != null ? nullOrEmpty(options.resultSets()) : null);
+    }
+}
+```
+
+- `<1>` 处，调用 `#getParameterType(Method method)` 方法，获得参数的类型。详细解析，见 [「2.6.1 getParameterType」](https://svip.iocoder.cn/MyBatis/builder-package-4/#) 。
+
+- `<2>` 处，调用 `#getLanguageDriver(Method method)` 方法，获得 LanguageDriver 对象。详细解析，见 [「2.6.2 getLanguageDriver」](https://svip.iocoder.cn/MyBatis/builder-package-4/#) 。
+
+- `<3>` 处，调用 `#getSqlSourceFromAnnotations(...)` 方法，从注解中，获得 SqlSource 对象。详细解析，见 [「2.6.3 getSqlSourceFromAnnotations」](https://svip.iocoder.cn/MyBatis/builder-package-4/#) 。
+
+- ```
+  <4>
+  ```
+
+   
+
+  处，获得各种属性。
+
+  - 
+
+- ```
+  <5>
+  ```
+
+   
+
+  处，获得 KeyGenerator 对象。
+
+  - `<5.1>` 处，如果有 `@SelectKey` 注解，则调用 `#handleSelectKeyAnnotation(...)` 方法，处理 `@@SelectKey` 注解，生成对应的 SelectKey 对象。详细解析，见 [「2.6.4 handleSelectKeyAnnotation」](https://svip.iocoder.cn/MyBatis/builder-package-4/#) 。
+  - `<5.2>` 处，如果无 `@Options` 注解，则根据全局配置处理，使用 Jdbc3KeyGenerator 或 NoKeyGenerator 单例。
+  - `<5.3>` 处，如果有 `@Options` 注解，则使用该注解的配置处理。
+  - `<5.4>` 处，非插入和更新语句，无需 KeyGenerator 对象，所以使用 NoKeyGenerator 单例。
+
+- `<6>` 处，初始化各种属性。
+
+- ```
+  <7>
+  ```
+
+   
+
+  处，获得
+
+   
+
+  ```
+  resultMapId
+  ```
+
+   
+
+  编号字符串。
+
+  - `<7.1>` 处，如果有 `@ResultMap` 注解，使用该注解为 `resultMapId` 属性。因为 `@ResultMap` 注解的作用，就是注解使用的结果集。
+  - `<7.2>` 处，如果无 `@ResultMap` 注解，调用 `#parseResultMap(Method method)` 方法，解析其它注解，作为 `resultMapId` 属性。详细解析，见 [「2.6.6 parseResultMap」](https://svip.iocoder.cn/MyBatis/builder-package-4/#) 。
+
+### 2.6.1 getParameterType
+
+调用 `#getParameterType(Method method)` 方法，获得参数的类型。代码如下：
+
+```
+// MapperAnnotationBuilder.java
+
+private Class<?> getParameterType(Method method) {
+    Class<?> parameterType = null;
+    // 遍历参数类型数组
+    // 排除 RowBounds 和 ResultHandler 两种参数
+    // 1. 如果是多参数，则是 ParamMap 类型
+    // 2. 如果是单参数，则是该参数的类型
+    Class<?>[] parameterTypes = method.getParameterTypes();
+    for (Class<?> currentParameterType : parameterTypes) {
+        if (!RowBounds.class.isAssignableFrom(currentParameterType) && !ResultHandler.class.isAssignableFrom(currentParameterType)) {
+            if (parameterType == null) {
+                parameterType = currentParameterType;
+            } else {
+                // issue #135
+                parameterType = ParamMap.class;
+            }
+        }
+    }
+    return parameterType;
+}
+```
+
+- 比较简单，根据是否为多参数，返回是 ParamMap 类型，还是单参数对应的类型。
+
+### 2.6.2 getLanguageDriver
+
+`#getLanguageDriver(Method method)` 方法，获得 LanguageDriver 对象。代码如下：
+
+```
+// MapperAnnotationBuilder.java
+
+private LanguageDriver getLanguageDriver(Method method) {
+    // 解析 @Lang 注解，获得对应的类型
+    Lang lang = method.getAnnotation(Lang.class);
+    Class<? extends LanguageDriver> langClass = null;
+    if (lang != null) {
+        langClass = lang.value();
+    }
+    // 获得 LanguageDriver 对象
+    // 如果 langClass 为空，即无 @Lang 注解，则会使用默认 LanguageDriver 类型
+    return assistant.getLanguageDriver(langClass);
+}
+```
+
+- 调用 `MapperBuilderAssistant#getLanguageDriver(Class<? extends LanguageDriver> langClass)` 方法，获得 LanguageDriver 对象。在 [《精尽 MyBatis 源码分析 —— MyBatis 初始化（三）之加载 Statement 配置》](http://svip.iocoder.cn/MyBatis/builder-package-3) 的 [「2.4 getLanguageDriver」](https://svip.iocoder.cn/MyBatis/builder-package-4/#) 中，已经详细解析。
+
+### 2.6.3 getSqlSourceFromAnnotations
+
+`#getSqlSourceFromAnnotations(Method method, Class<?> parameterType, LanguageDriver languageDriver)` 方法，从注解中，获得 SqlSource 对象。代码如下：
+
+```
+// MapperAnnotationBuilder.java
+
+private SqlSource getSqlSourceFromAnnotations(Method method, Class<?> parameterType, LanguageDriver languageDriver) {
+    try {
+        // <1.1> <1.2> 获得方法上的 SQL_ANNOTATION_TYPES 和 SQL_PROVIDER_ANNOTATION_TYPES 对应的类型
+        Class<? extends Annotation> sqlAnnotationType = getSqlAnnotationType(method);
+        Class<? extends Annotation> sqlProviderAnnotationType = getSqlProviderAnnotationType(method);
+        // <2> 如果 SQL_ANNOTATION_TYPES 对应的类型非空
+        if (sqlAnnotationType != null) {
+            // 如果 SQL_PROVIDER_ANNOTATION_TYPES 对应的类型非空，则抛出 BindingException 异常，因为冲突了。
+            if (sqlProviderAnnotationType != null) {
+                throw new BindingException("You cannot supply both a static SQL and SqlProvider to method named " + method.getName());
+            }
+            // <2.1> 获得 SQL_ANNOTATION_TYPES 对应的注解
+            Annotation sqlAnnotation = method.getAnnotation(sqlAnnotationType);
+            // <2.2> 获得 value 属性
+            final String[] strings = (String[]) sqlAnnotation.getClass().getMethod("value").invoke(sqlAnnotation);
+            // <2.3> 创建 SqlSource 对象
+            return buildSqlSourceFromStrings(strings, parameterType, languageDriver);
+        // <3> 如果 SQL_PROVIDER_ANNOTATION_TYPES 对应的类型非空
+        } else if (sqlProviderAnnotationType != null) {
+            // <3.1> 获得 SQL_PROVIDER_ANNOTATION_TYPES 对应的注解
+            Annotation sqlProviderAnnotation = method.getAnnotation(sqlProviderAnnotationType);
+            // <3.2> 创建 ProviderSqlSource 对象
+            return new ProviderSqlSource(assistant.getConfiguration(), sqlProviderAnnotation, type, method);
+        }
+        // <4> 返回空
+        return null;
+    } catch (Exception e) {
+        throw new BuilderException("Could not find value method on SQL annotation.  Cause: " + e, e);
+    }
+}
+```
+
+- `<1.1>` 处，调用 `#getSqlAnnotationType(Method method)` 方法，获得方法上的 `SQL_ANNOTATION_TYPES` 类型的注解类型。详细解析，见 [「2.6.3.1 getSqlAnnotationType」](https://svip.iocoder.cn/MyBatis/builder-package-4/#) 。
+
+- `<1.2>` 处，调用 `#getSqlProviderAnnotationType(Method method)` 方法，获得方法上的 `SQL_PROVIDER_ANNOTATION_TYPES` 类型的注解类型。详细解析，见 [「2.6.3.2 getSqlAnnotationType」](https://svip.iocoder.cn/MyBatis/builder-package-4/#) 。
+
+- ```
+  <2>
+  ```
+
+   
+
+  处，如果
+
+   
+
+  ```
+  SQL_ANNOTATION_TYPES
+  ```
+
+   
+
+  对应的类型非空的情况，例如
+
+   
+
+  ```
+  @Insert
+  ```
+
+   
+
+  注解：
+
+  - `<2.1>` 处，获得 `SQL_ANNOTATION_TYPES` 对应的注解。
+  - `<2.2>` 处，通过反射，获得对应的 `value` 属性。因为这里的注解类有多种，所以只好通过反射方法来获取该属性。
+  - `<2.3>` 处，调用 `#buildSqlSourceFromStrings(...)` 方法，创建 SqlSource 对象。详细解析，见 [「2.6.3.3 buildSqlSourceFromStrings」](https://svip.iocoder.cn/MyBatis/builder-package-4/#) 。
+
+- ```
+  <3>
+  ```
+
+   
+
+  处，如果
+
+   
+
+  ```
+  SQL_PROVIDER_ANNOTATION_TYPES
+  ```
+
+   
+
+  对应的类型非空的情况，例如
+
+   
+
+  ```
+  @InsertProvider
+  ```
+
+   
+
+  注解：
+
+  - `<3.1>` 处，获得 `SQL_PROVIDER_ANNOTATION_TYPES` 对应的注解。
+  - `<3.2>` 处，创建 ProviderSqlSource 对象。详细解析，见后续的文章。
+
+- `<4>` 处，没有空，没有符合的注解。
+
+#### 2.6.3.1 getSqlAnnotationType
+
+`#getSqlAnnotationType(Method method)` 方法，获得方法上的 `SQL_ANNOTATION_TYPES` 类型的注解类型。代码如下：
+
+```
+// MapperAnnotationBuilder.java
+
+private Class<? extends Annotation> getSqlAnnotationType(Method method) {
+    return chooseAnnotationType(method, SQL_ANNOTATION_TYPES);
+}
+
+/**
+ * 获得符合指定类型的注解类型
+ *
+ * @param method 方法
+ * @param types 指定类型
+ * @return 查到的注解类型
+ */
+private Class<? extends Annotation> chooseAnnotationType(Method method, Set<Class<? extends Annotation>> types) {
+    for (Class<? extends Annotation> type : types) {
+        Annotation annotation = method.getAnnotation(type);
+        if (annotation != null) {
+            return type;
+        }
+    }
+    return null;
+}
+```
+
+#### 2.6.3.2 getSqlProviderAnnotationType
+
+`#getSqlProviderAnnotationType(Method method)` 方法，获得方法上的 `SQL_ANNOTATION_TYPES` 类型的注解类型。代码如下：
+
+```
+// MapperAnnotationBuilder.java
+
+private Class<? extends Annotation> getSqlProviderAnnotationType(Method method) {
+    return chooseAnnotationType(method, SQL_PROVIDER_ANNOTATION_TYPES);
+}
+```
+
+#### 2.6.3.3 buildSqlSourceFromStrings
+
+`#buildSqlSourceFromStrings(String[] strings, Class<?> parameterTypeClass, LanguageDriver languageDriver)` 方法，创建 SqlSource 对象。代码如下：
+
+```
+// MapperAnnotationBuilder.java
+
+private SqlSource buildSqlSourceFromStrings(String[] strings, Class<?> parameterTypeClass, LanguageDriver languageDriver) {
+    // <1> 拼接 SQL
+    final StringBuilder sql = new StringBuilder();
+    for (String fragment : strings) {
+        sql.append(fragment);
+        sql.append(" ");
+    }
+    // <2> 创建 SqlSource 对象
+    return languageDriver.createSqlSource(configuration, sql.toString().trim(), parameterTypeClass);
+}
+```
+
+- `<1>` 处，拼接 SQL ，使用 `" "` 空格分隔。因为，`@Select` 等注解，`value` 属性是个**数组**。
+- `<2>` 处，调用 `LanguageDriver#createSqlSource(Configuration configuration, String script, Class<?> parameterType)` 方法，创建 SqlSource 对象。详细解析，见后续文章。
+
+### 2.6.4 handleSelectKeyAnnotation
+
+`#handleSelectKeyAnnotation(SelectKey selectKeyAnnotation, String baseStatementId, Class<?> parameterTypeClass, LanguageDriver languageDriver)` 方法，处理 `@@SelectKey` 注解，生成对应的 SelectKey 对象。代码如下：
+
+```
+// MapperAnnotationBuilder.java
+
+private KeyGenerator handleSelectKeyAnnotation(SelectKey selectKeyAnnotation, String baseStatementId, Class<?> parameterTypeClass, LanguageDriver languageDriver) {
+    // 获得各种属性和对应的类
+    String id = baseStatementId + SelectKeyGenerator.SELECT_KEY_SUFFIX;
+    Class<?> resultTypeClass = selectKeyAnnotation.resultType();
+    StatementType statementType = selectKeyAnnotation.statementType();
+    String keyProperty = selectKeyAnnotation.keyProperty();
+    String keyColumn = selectKeyAnnotation.keyColumn();
+    boolean executeBefore = selectKeyAnnotation.before();
+
+    // defaults
+    // 创建 MappedStatement 需要用到的默认值
+    boolean useCache = false;
+    KeyGenerator keyGenerator = NoKeyGenerator.INSTANCE;
+    Integer fetchSize = null;
+    Integer timeout = null;
+    boolean flushCache = false;
+    String parameterMap = null;
+    String resultMap = null;
+    ResultSetType resultSetTypeEnum = null;
+
+    // 创建 SqlSource 对象
+    SqlSource sqlSource = buildSqlSourceFromStrings(selectKeyAnnotation.statement(), parameterTypeClass, languageDriver);
+    SqlCommandType sqlCommandType = SqlCommandType.SELECT;
+
+    // 创建 MappedStatement 对象
+    assistant.addMappedStatement(id, sqlSource, statementType, sqlCommandType, fetchSize, timeout, parameterMap, parameterTypeClass, resultMap, resultTypeClass, resultSetTypeEnum,
+            flushCache, useCache, false,
+            keyGenerator, keyProperty, keyColumn, null, languageDriver, null);
+
+    // 获得 SelectKeyGenerator 的编号，格式为 `${namespace}.${id}`
+    id = assistant.applyCurrentNamespace(id, false);
+    // 获得 MappedStatement 对象
+    MappedStatement keyStatement = configuration.getMappedStatement(id, false);
+    // 创建 SelectKeyGenerator 对象，并添加到 configuration 中
+    SelectKeyGenerator answer = new SelectKeyGenerator(keyStatement, executeBefore);
+    configuration.addKeyGenerator(id, answer);
+    return answer;
+}
+```
+
+- 从实现逻辑上，我们会发现，和 `XMLStatementBuilder#parseSelectKeyNode(String id, XNode nodeToHandle, Class<?> parameterTypeClass, LanguageDriver langDriver, String databaseId)` 方法是**一致**的。所以就不重复解析了，胖友可以看看 [《精尽 MyBatis 源码分析 —— MyBatis 初始化（三）之加载 Statement 配置》](http://svip.iocoder.cn/MyBatis/builder-package-3) 的 [「2.5.2 parseSelectKeyNode」](https://svip.iocoder.cn/MyBatis/builder-package-4/#) 。
+
+### 2.6.5 getSqlCommandType
+
+`#getSqlCommandType(Method method)` 方法，获得方法对应的 SQL 命令类型。代码如下：
+
+```
+// MapperAnnotationBuilder.java
+
+private SqlCommandType getSqlCommandType(Method method) {
+    // 获得符合 SQL_ANNOTATION_TYPES 类型的注解类型
+    Class<? extends Annotation> type = getSqlAnnotationType(method);
+
+    if (type == null) {
+        // 获得符合 SQL_PROVIDER_ANNOTATION_TYPES 类型的注解类型
+        type = getSqlProviderAnnotationType(method);
+
+        // 找不到，返回 SqlCommandType.UNKNOWN
+        if (type == null) {
+            return SqlCommandType.UNKNOWN;
+        }
+
+        // 转换成对应的枚举
+        if (type == SelectProvider.class) {
+            type = Select.class;
+        } else if (type == InsertProvider.class) {
+            type = Insert.class;
+        } else if (type == UpdateProvider.class) {
+            type = Update.class;
+        } else if (type == DeleteProvider.class) {
+            type = Delete.class;
+        }
+    }
+
+    // 转换成对应的枚举
+    return SqlCommandType.valueOf(type.getSimpleName().toUpperCase(Locale.ENGLISH));
+}
+```
+
+### 2.6.6 parseResultMap
+
+`#parseResultMap(Method method)` 方法，解析其它注解，返回 `resultMapId` 属性。代码如下：
+
+```
+// MapperAnnotationBuilder.java
+
+private String parseResultMap(Method method) {
+    // <1> 获得返回类型
+    Class<?> returnType = getReturnType(method);
+    // <2> 获得 @ConstructorArgs、@Results、@TypeDiscriminator 注解
+    ConstructorArgs args = method.getAnnotation(ConstructorArgs.class);
+    Results results = method.getAnnotation(Results.class);
+    TypeDiscriminator typeDiscriminator = method.getAnnotation(TypeDiscriminator.class);
+    // <3> 生成 resultMapId
+    String resultMapId = generateResultMapName(method);
+    // <4> 生成 ResultMap 对象
+    applyResultMap(resultMapId, returnType, argsIf(args), resultsIf(results), typeDiscriminator);
+    return resultMapId;
+}
+```
+
+- `<1>` 处，调用 `#getReturnType(Method method)` 方法，获得返回类型。详细解析，见 [「2.6.6.1 getReturnType」](https://svip.iocoder.cn/MyBatis/builder-package-4/#) 。
+
+- `<2>` 处，获得 `@ConstructorArgs`、`@Results`、`@TypeDiscriminator` 注解。
+
+- `<3>` 处，调用 `#generateResultMapName(Method method)` 方法，生成 `resultMapId` 。详细解析，见 [「2.6.6.2 generateResultMapName」](https://svip.iocoder.cn/MyBatis/builder-package-4/#) 。
+
+- `<4>` 处，调用 `#argsIf(ConstructorArgs args)` 方法，获得 `@ConstructorArgs` 注解的 `@Arg[]` 数组。代码如下：
+
+  ```
+  // MapperAnnotationBuilder.java
+  
+  private Arg[] argsIf(ConstructorArgs args) {
+      return args == null ? new Arg[0] : args.value();
+  }
+  ```
+
+- `<4>` 处，调用 `#resultsIf((Results results)` 方法，获得 `@(Results` 注解的 `@Result[]` 数组。
+
+  ```
+  // MapperAnnotationBuilder.java
+  
+  private Result[] resultsIf(Results results) {
+      return results == null ? new Result[0] : results.value();
+  }
+  ```
+
+- `<4>` 处，调用 `#applyResultMap(...)` 方法，生成 ResultMap 对象。详细解析，见 [「2.6.6.3 applyResultMap」](https://svip.iocoder.cn/MyBatis/builder-package-4/#) 。
+
+#### 2.6.6.1 getReturnType
+
+`#getReturnType(Method method)` 方法，获得返回类型。代码如下：
+
+```
+// MapperAnnotationBuilder.java
+
+private Class<?> getReturnType(Method method) {
+    // 获得方法的返回类型
+    Class<?> returnType = method.getReturnType();
+    // 解析成对应的 Type
+    Type resolvedReturnType = TypeParameterResolver.resolveReturnType(method, type);
+    // 如果 Type 是 Class ，普通类
+    if (resolvedReturnType instanceof Class) {
+        returnType = (Class<?>) resolvedReturnType;
+        // 如果是数组类型，则使用 componentType
+        if (returnType.isArray()) {
+            returnType = returnType.getComponentType();
+        }
+        // gcode issue #508
+        // 如果返回类型是 void ，则尝试使用 @ResultType 注解
+        if (void.class.equals(returnType)) {
+            ResultType rt = method.getAnnotation(ResultType.class);
+            if (rt != null) {
+                returnType = rt.value();
+            }
+        }
+    // 如果 Type 是 ParameterizedType ，泛型
+    } else if (resolvedReturnType instanceof ParameterizedType) {
+        // 获得泛型 rawType
+        ParameterizedType parameterizedType = (ParameterizedType) resolvedReturnType;
+        Class<?> rawType = (Class<?>) parameterizedType.getRawType();
+        // 如果是 Collection 或者 Cursor 类型时
+        if (Collection.class.isAssignableFrom(rawType) || Cursor.class.isAssignableFrom(rawType)) {
+            // 获得 <> 中实际类型
+            Type[] actualTypeArguments = parameterizedType.getActualTypeArguments();
+            // 如果 actualTypeArguments 的大小为 1 ，进一步处理
+            if (actualTypeArguments != null && actualTypeArguments.length == 1) {
+                Type returnTypeParameter = actualTypeArguments[0];
+                // 如果是 Class ，则直接使用 Class
+                if (returnTypeParameter instanceof Class<?>) {
+                    returnType = (Class<?>) returnTypeParameter;
+                // 如果是 ParameterizedType ，则获取 <> 中实际类型
+                } else if (returnTypeParameter instanceof ParameterizedType) {
+                    // (gcode issue #443) actual type can be a also a parameterized type
+                    returnType = (Class<?>) ((ParameterizedType) returnTypeParameter).getRawType();
+                // 如果是泛型数组类型，则获得 genericComponentType 对应的类
+                } else if (returnTypeParameter instanceof GenericArrayType) {
+                    Class<?> componentType = (Class<?>) ((GenericArrayType) returnTypeParameter).getGenericComponentType();
+                    // (gcode issue #525) support List<byte[]>
+                    returnType = Array.newInstance(componentType, 0).getClass();
+                }
+            }
+        // 如果有 @MapKey 注解，并且是 Map 类型
+        } else if (method.isAnnotationPresent(MapKey.class) && Map.class.isAssignableFrom(rawType)) {
+            // (gcode issue 504) Do not look into Maps if there is not MapKey annotation
+            // 获得 <> 中实际类型
+            Type[] actualTypeArguments = parameterizedType.getActualTypeArguments();
+            // 如果 actualTypeArguments 的大小为 2 ，进一步处理。
+            // 为什么是 2 ，因为 Map<K, V> 呀，有 K、V 两个泛型
+            if (actualTypeArguments != null && actualTypeArguments.length == 2) {
+                // 处理 V 泛型
+                Type returnTypeParameter = actualTypeArguments[1];
+                // 如果 V 泛型为 Class ，则直接使用 Class
+                if (returnTypeParameter instanceof Class<?>) {
+                    returnType = (Class<?>) returnTypeParameter;
+                // 如果 V 泛型为 ParameterizedType ，则获取 <> 中实际类型
+                } else if (returnTypeParameter instanceof ParameterizedType) {
+                    // (gcode issue 443) actual type can be a also a parameterized type
+                    returnType = (Class<?>) ((ParameterizedType) returnTypeParameter).getRawType();
+                }
+            }
+        // 如果是 Optional 类型时
+        } else if (Optional.class.equals(rawType)) {
+            // 获得 <> 中实际类型
+            Type[] actualTypeArguments = parameterizedType.getActualTypeArguments();
+            // 因为是 Optional<T> 类型，所以 actualTypeArguments 数组大小是一
+            Type returnTypeParameter = actualTypeArguments[0];
+            // 如果 <T> 泛型为 Class ，则直接使用 Class
+            if (returnTypeParameter instanceof Class<?>) {
+                returnType = (Class<?>) returnTypeParameter;
+            }
+        }
+    }
+
+    return returnType;
+}
+```
+
+- 方法非常的长，主要是进一步处理方法的返回类型 `Method.returnType` ，例如是数组类型、泛型类型、有 `@MapKey` 注解，或是 Optional 类型，等等情况。
+- 胖友大体看看就好，也不需要看的特别细。等回过头有需要，在详细看。
+
+#### 2.6.6.2 generateResultMapName
+
+`#generateResultMapName(Method method)` 方法，生成 `resultMapId` 。代码如下：
+
+```
+// MapperAnnotationBuilder.java
+
+private String generateResultMapName(Method method) {
+    // 第一种情况，已经声明
+    // 如果有 @Results 注解，并且有设置 id 属性，则直接返回。格式为：`${type.name}.${Results.id}` 。
+    Results results = method.getAnnotation(Results.class);
+    if (results != null && !results.id().isEmpty()) {
+        return type.getName() + "." + results.id();
+    }
+    // 第二种情况，自动生成
+    // 获得 suffix 前缀，相当于方法参数构成的签名
+    StringBuilder suffix = new StringBuilder();
+    for (Class<?> c : method.getParameterTypes()) {
+        suffix.append("-");
+        suffix.append(c.getSimpleName());
+    }
+    if (suffix.length() < 1) {
+        suffix.append("-void");
+    }
+    // 拼接返回。格式为 `${type.name}.${method.name}${suffix}` 。
+    return type.getName() + "." + method.getName() + suffix;
+}
+```
+
+- 分成两种情况：已经声明和自动生成。
+- 代码比较简单，胖友自己瞅瞅。
+
+#### 2.6.6.3 applyResultMap
+
+`#applyResultMap(String resultMapId, Class<?> returnType, Arg[] args, Result[] results, TypeDiscriminator discriminator)` 方法，创建 ResultMap 对象。代码如下：
+
+```
+// MapperAnnotationBuilder.java
+
+private void applyResultMap(String resultMapId, Class<?> returnType, Arg[] args, Result[] results, TypeDiscriminator discriminator) {
+    // <1> 创建 ResultMapping 数组
+    List<ResultMapping> resultMappings = new ArrayList<>();
+    // <2> 将 @Arg[] 注解数组，解析成对应的 ResultMapping 对象们，并添加到 resultMappings 中。
+    applyConstructorArgs(args, returnType, resultMappings);
+    // <3> 将 @Result[] 注解数组，解析成对应的 ResultMapping 对象们，并添加到 resultMappings 中。
+    applyResults(results, returnType, resultMappings);
+    // <4> 创建 Discriminator 对象
+    Discriminator disc = applyDiscriminator(resultMapId, returnType, discriminator);
+    // TODO add AutoMappingBehaviour
+    // <5> ResultMap 对象
+    assistant.addResultMap(resultMapId, returnType, null, disc, resultMappings, null);
+    // <6> 创建 Discriminator 的 ResultMap 对象们
+    createDiscriminatorResultMaps(resultMapId, returnType, discriminator);
+}
+```
+
+- `<1>` 处，创建 ResultMapping 数组。
+- `<2>` 处，调用 `#applyConstructorArgs(...)` 方法，将 `@Arg[]` 注解数组，解析成对应的 ResultMapping 对象们，并添加到 `resultMappings` 中。详细解析，见 [「2.6.6.3.1 applyConstructorArgs」](https://svip.iocoder.cn/MyBatis/builder-package-4/#) 。
+- `<3>` 处，调用 `#applyResults(...)` 方法，将 `@Result[]` 注解数组，解析成对应的 ResultMapping 对象们，并添加到 `resultMappings` 中。 详细解析，见 [「2.6.6.3.2 applyResults」](https://svip.iocoder.cn/MyBatis/builder-package-4/#) 。
+- `<4>` 处，调用 `#applyDiscriminator(...)` 方法，创建 Discriminator 对象。详细解析，见 [「2.6.6.3.3 applyDiscriminator」](https://svip.iocoder.cn/MyBatis/builder-package-4/#) 。
+- `<5>` 处，调用 `MapperAnnotationBuilder#addResultMap(...)` 方法，创建 ResultMap 对象。
+- `<6>` 处，调用 `#createDiscriminatorResultMaps(...)` 方法，创建 Discriminator 的 ResultMap 对象们。详细解析，见 [「2.6.6.3.4 createDiscriminatorResultMaps」](https://svip.iocoder.cn/MyBatis/builder-package-4/#) 。
+- 看完上述逻辑后，你会发现该方法，和 `XMLMapperBuilder#resultMapElement(XNode resultMapNode, List<ResultMapping> additionalResultMappings)` 方法是类似的。所以，胖友后续可以自己去回味下。
+
+##### 2.6.6.3.1 applyConstructorArgs
+
+`#applyConstructorArgs(...)` 方法，将 `@Arg[]` 注解数组，解析成对应的 ResultMapping 对象们，并添加到 `resultMappings` 中。代码如下：
+
+```
+// MapperAnnotationBuilder.java
+
+private void applyConstructorArgs(Arg[] args, Class<?> resultType, List<ResultMapping> resultMappings) {
+    // 遍历 @Arg[] 数组
+    for (Arg arg : args) {
+        // 创建 ResultFlag 数组
+        List<ResultFlag> flags = new ArrayList<>();
+        flags.add(ResultFlag.CONSTRUCTOR);
+        if (arg.id()) {
+            flags.add(ResultFlag.ID);
+        }
+        @SuppressWarnings("unchecked")
+        // 获得 TypeHandler 乐
+        Class<? extends TypeHandler<?>> typeHandler = (Class<? extends TypeHandler<?>>)
+                (arg.typeHandler() == UnknownTypeHandler.class ? null : arg.typeHandler());
+        // 将当前 @Arg 注解构建成 ResultMapping 对象
+        ResultMapping resultMapping = assistant.buildResultMapping(
+                resultType,
+                nullOrEmpty(arg.name()),
+                nullOrEmpty(arg.column()),
+                arg.javaType() == void.class ? null : arg.javaType(),
+                arg.jdbcType() == JdbcType.UNDEFINED ? null : arg.jdbcType(),
+                nullOrEmpty(arg.select()),
+                nullOrEmpty(arg.resultMap()),
+                null,
+                nullOrEmpty(arg.columnPrefix()),
+                typeHandler,
+                flags,
+                null,
+                null,
+                false);
+        // 添加到 resultMappings 中
+        resultMappings.add(resultMapping);
+    }
+}
+```
+
+- 从实现逻辑上，我们会发现，和 `XMLMapperBuilder#processConstructorElement(XNode resultChild, Class<?> resultType, List<ResultMapping> resultMappings)` 方法是**一致**的。所以就不重复解析了，胖友可以看看 [《精尽 MyBatis 源码分析 —— MyBatis 初始化（二）之加载 Mapper 映射配置》](http://svip.iocoder.cn/MyBatis/builder-package-2) 的 [「2.3.3.1 processConstructorElement」](https://svip.iocoder.cn/MyBatis/builder-package-4/#) 。
+
+##### 2.6.6.3.2 applyResults
+
+`#applyResults(Result[] results, Class<?> resultType, List<ResultMapping> resultMappings)` 方法，将 `@Result[]` 注解数组，解析成对应的 ResultMapping 对象们，并添加到 `resultMappings` 中。代码如下：
+
+```
+// MapperAnnotationBuilder.java
+
+private void applyResults(Result[] results, Class<?> resultType, List<ResultMapping> resultMappings) {
+    // 遍历 @Result[] 数组
+    for (Result result : results) {
+        // 创建 ResultFlag 数组
+        List<ResultFlag> flags = new ArrayList<>();
+        if (result.id()) {
+            flags.add(ResultFlag.ID);
+        }
+        @SuppressWarnings("unchecked")
+        // 获得 TypeHandler 类
+        Class<? extends TypeHandler<?>> typeHandler = (Class<? extends TypeHandler<?>>)
+                ((result.typeHandler() == UnknownTypeHandler.class) ? null : result.typeHandler());
+        // 构建 ResultMapping 对象
+        ResultMapping resultMapping = assistant.buildResultMapping(
+                resultType,
+                nullOrEmpty(result.property()),
+                nullOrEmpty(result.column()),
+                result.javaType() == void.class ? null : result.javaType(),
+                result.jdbcType() == JdbcType.UNDEFINED ? null : result.jdbcType(),
+                hasNestedSelect(result) ? nestedSelectId(result) : null, // <1.1> <1.2> 
+                null,
+                null,
+                null,
+                typeHandler,
+                flags,
+                null,
+                null,
+                isLazy(result)); // <2>
+        // 添加到 resultMappings 中
+        resultMappings.add(resultMapping);
+    }
+}
+```
+
+- 从实现逻辑上，我们会发现，和 `XMLMapperBuilder#buildResultMappingFromContext(XNode context, Class<?> resultType, List<ResultFlag> flags)` 方法是**一致**的。所以就不重复解析了，胖友可以看看 [《精尽 MyBatis 源码分析 —— MyBatis 初始化（二）之加载 Mapper 映射配置》](http://svip.iocoder.cn/MyBatis/builder-package-2) 的 [「2.3.3.3 buildResultMappingFromContext」](https://svip.iocoder.cn/MyBatis/builder-package-4/#) 。
+
+- `<1.1>` 处，调用 `#hasNestedSelect(Result result)` 方法，判断是否有内嵌的查询。代码如下：
+
+  ```
+  // MapperAnnotationBuilder.java
+  
+  private boolean hasNestedSelect(Result result) {
+      if (result.one().select().length() > 0 && result.many().select().length() > 0) {
+          throw new BuilderException("Cannot use both @One and @Many annotations in the same @Result");
+      }
+      // 判断有 @One 或 @Many 注解
+      return result.one().select().length() > 0 || result.many().select().length() > 0;
+  }
+  ```
+
+- `<1.2>` 处，调用 `#nestedSelectId((Result result)` 方法，调用 `#nestedSelectId(Result result)` 方法，获得内嵌的查询编号。代码如下：
+
+  ```
+  // MapperAnnotationBuilder.java
+  
+  private String nestedSelectId(Result result) {
+      // 先获得 @One 注解
+      String nestedSelect = result.one().select();
+      // 获得不到，则再获得 @Many
+      if (nestedSelect.length() < 1) {
+          nestedSelect = result.many().select();
+      }
+      // 获得内嵌查询编号，格式为 `{type.name}.${select}`
+      if (!nestedSelect.contains(".")) {
+          nestedSelect = type.getName() + "." + nestedSelect;
+      }
+      return nestedSelect;
+  }
+  ```
+
+- `<2>` 处，调用 `#isLazy(Result result)` 方法，判断是否懒加载。代码如下：
+
+  ```
+  // MapperAnnotationBuilder.java
+  
+  private boolean isLazy(Result result) {
+      // 判断是否开启懒加载
+      boolean isLazy = configuration.isLazyLoadingEnabled();
+      // 如果有 @One 注解，则判断是否懒加载
+      if (result.one().select().length() > 0 && FetchType.DEFAULT != result.one().fetchType()) {
+          isLazy = result.one().fetchType() == FetchType.LAZY;
+      // 如果有 @Many 注解，则判断是否懒加载
+      } else if (result.many().select().length() > 0 && FetchType.DEFAULT != result.many().fetchType()) {
+          isLazy = result.many().fetchType() == FetchType.LAZY;
+      }
+      return isLazy;
+  }
+  ```
+
+  - 根据全局是否懒加载 + `@One` 或 `@Many` 注解。
+
+##### 2.6.6.3.3 applyDiscriminator
+
+`#applyDiscriminator(...)` 方法，创建 Discriminator 对象。代码如下：
+
+```
+// MapperAnnotationBuilder.java
+
+private Discriminator applyDiscriminator(String resultMapId, Class<?> resultType, TypeDiscriminator discriminator) {
+    if (discriminator != null) {
+        // 解析各种属性
+        String column = discriminator.column();
+        Class<?> javaType = discriminator.javaType() == void.class ? String.class : discriminator.javaType();
+        JdbcType jdbcType = discriminator.jdbcType() == JdbcType.UNDEFINED ? null : discriminator.jdbcType();
+        @SuppressWarnings("unchecked")
+        // 获得 TypeHandler 类
+        Class<? extends TypeHandler<?>> typeHandler = (Class<? extends TypeHandler<?>>)
+                (discriminator.typeHandler() == UnknownTypeHandler.class ? null : discriminator.typeHandler());
+        // 遍历 @Case[] 注解数组，解析成 discriminatorMap 集合
+        Case[] cases = discriminator.cases();
+        Map<String, String> discriminatorMap = new HashMap<>();
+        for (Case c : cases) {
+            String value = c.value();
+            String caseResultMapId = resultMapId + "-" + value;
+            discriminatorMap.put(value, caseResultMapId);
+        }
+        // 创建 Discriminator 对象
+        return assistant.buildDiscriminator(resultType, column, javaType, jdbcType, typeHandler, discriminatorMap);
+    }
+    return null;
+}
+```
+
+- 从实现逻辑上，我们会发现，和 `XMLMapperBuilder#processDiscriminatorElement(XNode context, Class<?> resultType, List<ResultMapping> resultMappings)` 方法是**一致**的。所以就不重复解析了，胖友可以看看 [《精尽 MyBatis 源码分析 —— MyBatis 初始化（二）之加载 Mapper 映射配置》](http://svip.iocoder.cn/MyBatis/builder-package-2) 的 [「2.3.3.2 processDiscriminatorElement」](https://svip.iocoder.cn/MyBatis/builder-package-4/#) 。
+
+##### 2.6.6.3.4 createDiscriminatorResultMaps
+
+`#createDiscriminatorResultMaps(...)` 方法，创建 Discriminator 的 ResultMap 对象们。代码如下：
+
+```
+// MapperAnnotationBuilder.java
+
+private void createDiscriminatorResultMaps(String resultMapId, Class<?> resultType, TypeDiscriminator discriminator) {
+    if (discriminator != null) {
+        // 遍历 @Case 注解
+        for (Case c : discriminator.cases()) {
+            // 创建 @Case 注解的 ResultMap 的编号
+            String caseResultMapId = resultMapId + "-" + c.value();
+            // 创建 ResultMapping 数组
+            List<ResultMapping> resultMappings = new ArrayList<>();
+            // issue #136
+            // 将 @Arg[] 注解数组，解析成对应的 ResultMapping 对象们，并添加到 resultMappings 中。
+            applyConstructorArgs(c.constructArgs(), resultType, resultMappings);
+            // 将 @Result[] 注解数组，解析成对应的 ResultMapping 对象们，并添加到 resultMappings 中。
+            applyResults(c.results(), resultType, resultMappings);
+            // TODO add AutoMappingBehaviour
+            // 创建 ResultMap 对象
+            assistant.addResultMap(caseResultMapId, c.type(), resultMapId, null, resultMappings, null);
+        }
+    }
+}
+```
+
+- 逻辑比较简单，遍历 `@Case[]` 注解数组，创建每个 `@Case` 对应的 ResultMap 对象。
+
+## 2.7 MethodResolver
+
+`org.apache.ibatis.builder.annotation.MethodResolver` ，注解方法的处理器。代码如下：
+
+```
+// MethodResolver.java
+
+public class MethodResolver {
+
+    /**
+     * MapperAnnotationBuilder 对象
+     */
+    private final MapperAnnotationBuilder annotationBuilder;
+    /**
+     * Method 方法
+     */
+    private final Method method;
+
+    public MethodResolver(MapperAnnotationBuilder annotationBuilder, Method method) {
+        this.annotationBuilder = annotationBuilder;
+        this.method = method;
+    }
+
+    public void resolve() {
+        // 执行注解方法的解析
+        annotationBuilder.parseStatement(method);
+    }
+
+}
+```
+
+- 在 `#resolve()` 方法里，可以调用 `MapperAnnotationBuilder#parseStatement(Method method)` 方法，执行注解方法的解析。
+
+## 2.8 parsePendingMethods
+
+`#parsePendingMethods()` 方法，代码如下：
+
+```
+private void parsePendingMethods() {
+    // 获得 MethodResolver 集合，并遍历进行处理
+    Collection<MethodResolver> incompleteMethods = configuration.getIncompleteMethods();
+    synchronized (incompleteMethods) {
+        Iterator<MethodResolver> iter = incompleteMethods.iterator();
+        while (iter.hasNext()) {
+            try {
+                // 执行解析
+                iter.next().resolve();
+                iter.remove();
+                iter.remove();
+            } catch (IncompleteElementException e) {
+                // This method is still missing a resource
+            }
+        }
+    }
+}
+```
+
+- 《精尽 MyBatis 源码分析 —— MyBatis 初始化（二）之加载 Mapper 映射配置文件》
+
+   
+
+  的
+
+   
+
+  「2.5 parsePendingXXX」
+
+   
+
+  是一个思路。
+
+  - 1）获得对应的集合；2）遍历集合，执行解析；3）执行成功，则移除出集合；4）执行失败，忽略异常。
+  - 当然，实际上，此处还是可能有执行解析失败的情况，但是随着每一个 Mapper 接口对应的 MapperAnnotationBuilder 执行一次这些方法，逐步逐步就会被全部解析完。😈
+
+# 666. 彩蛋
+
+简单的小文一篇，实际就是 [《精尽 MyBatis 源码分析 —— MyBatis 初始化（二）之加载 Mapper 映射配置文件》](http://svip.iocoder.cn/MyBatis/builder-package-2) 和 [《精尽 MyBatis 源码分析 —— MyBatis 初始化（三）之加载 Statement 配置》](http://svip.iocoder.cn/MyBatis/builder-package-3) 的 **注解** 版。
+
+至此，MyBatis XML 配置和注解配置已经都解析完成了，当然，这个不包括 SQL 的解析。MyBatis 提供了强大的 [动态 SQL](http://www.mybatis.org/mybatis-3/zh/dynamic-sql.html) 的功能，这也就是我们从下篇文章，会开始分享的内容。
\ No newline at end of file
diff --git a/mybatis/19-mybatis-SQL 初始化（上）之 SqlNode.assets/01.png b/mybatis/19-mybatis-SQL 初始化（上）之 SqlNode.assets/01.png
new file mode 100644
index 0000000..f925b56
Binary files /dev/null and b/mybatis/19-mybatis-SQL 初始化（上）之 SqlNode.assets/01.png differ
diff --git a/mybatis/19-mybatis-SQL 初始化（上）之 SqlNode.assets/02.png b/mybatis/19-mybatis-SQL 初始化（上）之 SqlNode.assets/02.png
new file mode 100644
index 0000000..ce56e09
Binary files /dev/null and b/mybatis/19-mybatis-SQL 初始化（上）之 SqlNode.assets/02.png differ
diff --git a/mybatis/19-mybatis-SQL 初始化（上）之 SqlNode.assets/03.png b/mybatis/19-mybatis-SQL 初始化（上）之 SqlNode.assets/03.png
new file mode 100644
index 0000000..3003d6d
Binary files /dev/null and b/mybatis/19-mybatis-SQL 初始化（上）之 SqlNode.assets/03.png differ
diff --git a/mybatis/19-mybatis-SQL 初始化（上）之 SqlNode.assets/04.png b/mybatis/19-mybatis-SQL 初始化（上）之 SqlNode.assets/04.png
new file mode 100644
index 0000000..d6c3769
Binary files /dev/null and b/mybatis/19-mybatis-SQL 初始化（上）之 SqlNode.assets/04.png differ
diff --git a/mybatis/19-mybatis-SQL 初始化（上）之 SqlNode.assets/05.png b/mybatis/19-mybatis-SQL 初始化（上）之 SqlNode.assets/05.png
new file mode 100644
index 0000000..a07c1bc
Binary files /dev/null and b/mybatis/19-mybatis-SQL 初始化（上）之 SqlNode.assets/05.png differ
diff --git a/mybatis/19-mybatis-SQL 初始化（上）之 SqlNode.assets/06.png b/mybatis/19-mybatis-SQL 初始化（上）之 SqlNode.assets/06.png
new file mode 100644
index 0000000..320523f
Binary files /dev/null and b/mybatis/19-mybatis-SQL 初始化（上）之 SqlNode.assets/06.png differ
diff --git a/mybatis/19-mybatis-SQL 初始化（上）之 SqlNode.md b/mybatis/19-mybatis-SQL 初始化（上）之 SqlNode.md
new file mode 100644
index 0000000..4efaf9c
--- /dev/null
+++ b/mybatis/19-mybatis-SQL 初始化（上）之 SqlNode.md	
@@ -0,0 +1,2319 @@
+# 精尽 MyBatis 源码分析 —— SQL 初始化（上）之 SqlNode
+
+# 1. 概述
+
+本文，我们来分享 MyBatis 的脚本模块，对应 `scripting` 包。如下图所示：[![`scripting` 包](19-mybatis-SQL 初始化（上）之 SqlNode.assets/01.png)](http://static.iocoder.cn/images/MyBatis/2020_02_22/01.png)`scripting` 包
+
+在 [《精尽 MyBatis 源码解析 —— 项目结构一览》](http://svip.iocoder.cn/MyBatis/intro) 中，简单介绍了这个模块如下：
+
+> 拼凑 SQL 语句是一件烦琐且易出错的过程，为了将开发人员从这项枯燥无趣的工作中 解脱出来，MyBatis 实现**动态 SQL 语句**的功能，提供了多种动态 SQL语句对应的节点。例如`<where>` 节点、`<if>` 节点、`<foreach>` 节点等 。通过这些节点的组合使用， 开发人 员可以写出几乎满足所有需求的动态 SQL 语句。
+>
+> MyBatis 中的 `scripting` 模块，会根据用户传入的实参，解析映射文件中定义的动态 SQL 节点，并形成数据库可执行的 SQL 语句。之后会处理 SQL 语句中的占位符，绑定用户传入的实参。
+
+- 总结来说，`scripting` 模块，最大的作用，就是实现了 MyBatis 的**动态 SQL 语句**的功能。关于这个功能，对应文档为 [《MyBatis 文档 —— 动态 SQL》](http://www.mybatis.org/mybatis-3/zh/dynamic-sql.html) 。
+
+本文涉及的类如下图所示：[![类图](19-mybatis-SQL 初始化（上）之 SqlNode.assets/02.png)](http://static.iocoder.cn/images/MyBatis/2020_02_22/02.png)类图
+
+- LanguageDriver
+- SqlSource
+- SqlNode
+- NodeHandler
+- 基于 OGNL 表达式
+
+下面，我们来逐个来瞅瞅。
+
+# 2. LanguageDriver
+
+`org.apache.ibatis.scripting.LanguageDriver` ，语言驱动接口。代码如下：
+
+```
+// LanguageDriver.java
+
+public interface LanguageDriver {
+
+    /**
+     * Creates a {@link ParameterHandler} that passes the actual parameters to the the JDBC statement.
+     *
+     * 创建 ParameterHandler 对象。
+     *
+     * @param mappedStatement The mapped statement that is being executed
+     * @param parameterObject The input parameter object (can be null)
+     * @param boundSql The resulting SQL once the dynamic language has been executed.
+     * @return
+     * @author Frank D. Martinez [mnesarco]
+     * @see DefaultParameterHandler
+     */
+    ParameterHandler createParameterHandler(MappedStatement mappedStatement, Object parameterObject, BoundSql boundSql);
+
+    /**
+     * Creates an {@link SqlSource} that will hold the statement read from a mapper xml file.
+     * It is called during startup, when the mapped statement is read from a class or an xml file.
+     *
+     * 创建 SqlSource 对象，从 Mapper XML 配置的 Statement 标签中，即 <select /> 等。
+     *
+     * @param configuration The MyBatis configuration
+     * @param script XNode parsed from a XML file
+     * @param parameterType input parameter type got from a mapper method or specified in the parameterType xml attribute. Can be null.
+     * @return
+     */
+    SqlSource createSqlSource(Configuration configuration, XNode script, Class<?> parameterType);
+
+    /**
+     * Creates an {@link SqlSource} that will hold the statement read from an annotation.
+     * It is called during startup, when the mapped statement is read from a class or an xml file.
+     *
+     * 创建 SqlSource 对象，从方法注解配置，即 @Select 等。
+     *
+     * @param configuration The MyBatis configuration
+     * @param script The content of the annotation
+     * @param parameterType input parameter type got from a mapper method or specified in the parameterType xml attribute. Can be null.
+     * @return
+     */
+    SqlSource createSqlSource(Configuration configuration, String script, Class<?> parameterType);
+
+}
+```
+
+## 2.1 XMLLanguageDriver
+
+`org.apache.ibatis.scripting.xmltags.XMLLanguageDriver` ，实现 LanguageDriver 接口，XML 语言驱动实现类。
+
+### 2.1.1 createParameterHandler
+
+`#createParameterHandler(MappedStatement mappedStatement, Object parameterObject, BoundSql boundSql)` 方法，代码如下：
+
+```
+// XMLLanguageDriver.java
+
+@Override
+public ParameterHandler createParameterHandler(MappedStatement mappedStatement, Object parameterObject, BoundSql boundSql) {
+    // 创建 DefaultParameterHandler 对象
+    return new DefaultParameterHandler(mappedStatement, parameterObject, boundSql);
+}
+```
+
+- 创建的是 DefaultParameterHandler 对象。详细解析，见 [《精尽 MyBatis 源码分析 —— SQL 初始化（下）之 SqlSource》](http://svip.iocoder.cn/MyBatis/scripting-2) 的 [「7.1 DefaultParameterHandler」](https://svip.iocoder.cn/MyBatis/scripting-1/#) 。
+
+### 2.1.2 createSqlSource
+
+`#createSqlSource(Configuration configuration, XNode script, Class<?> parameterType)` 方法，代码如下：
+
+```
+// XMLLanguageDriver.java
+
+@Override
+public SqlSource createSqlSource(Configuration configuration, XNode script, Class<?> parameterType) {
+    // 创建 XMLScriptBuilder 对象，执行解析
+    XMLScriptBuilder builder = new XMLScriptBuilder(configuration, script, parameterType);
+    return builder.parseScriptNode();
+}
+```
+
+- 创建 XMLScriptBuilder 对象，执行 `XMLScriptBuilder#parseScriptNode()` 方法，执行解析。详细解析，见 [「3. XMLScriptBuilder」](https://svip.iocoder.cn/MyBatis/scripting-1/#) 。
+
+### 2.1.3 createSqlSource
+
+`#createSqlSource(Configuration configuration, String script, Class<?> parameterType)` 方法，代码如下：
+
+```
+// XMLLanguageDriver.java
+
+@Override
+public SqlSource createSqlSource(Configuration configuration, String script, Class<?> parameterType) {
+    // issue #3
+    // <1> 如果是 <script> 开头，使用 XML 配置的方式，使用动态 SQL 
+    if (script.startsWith("<script>")) {
+        // <1.1> 创建 XPathParser 对象，解析出 <script /> 节点
+        XPathParser parser = new XPathParser(script, false, configuration.getVariables(), new XMLMapperEntityResolver());
+        // <1.2> 调用上面的 #createSqlSource(...) 方法，创建 SqlSource 对象
+        return createSqlSource(configuration, parser.evalNode("/script"), parameterType);
+    // <2>
+    } else {
+        // issue #127
+        // <2.1> 变量替换
+        script = PropertyParser.parse(script, configuration.getVariables());
+        // <2.2> 创建 TextSqlNode 对象
+        TextSqlNode textSqlNode = new TextSqlNode(script);
+        // <2.3.1> 如果是动态 SQL ，则创建 DynamicSqlSource 对象
+        if (textSqlNode.isDynamic()) {
+            return new DynamicSqlSource(configuration, textSqlNode);
+        // <2.3.2> 如果非动态 SQL ，则创建 RawSqlSource 对象
+        } else {
+            return new RawSqlSource(configuration, script, parameterType);
+        }
+    }
+}
+```
+
+- ```
+  <1>
+  ```
+
+   
+
+  处，如果是
+
+   
+
+  ```
+  <script>
+  ```
+
+   
+
+  开头，使用 XML 配置的方式，使用动态 SQL 。没使用过的胖友，可以看看
+
+   
+
+  《spring boot(8)-mybatis三种动态sql》
+
+   
+
+  。
+
+  - `<1.1>` 处，创建 XPathParser 对象，解析出 XML `<script />` 节点。
+  - `<1.2>` 处，调用 `#createSqlSource(Configuration configuration, XNode script, Class<?> parameterType)` 方法，创建 SqlSource 对象。
+
+- ```
+  <2>
+  ```
+
+   
+
+  处，
+
+  - `<2.1>` 处，变量替换。
+  - `<2.2.>` 处，创建 TextSqlNode 对象。详细解析，见 [「6.9 TextSqlNode」](https://svip.iocoder.cn/MyBatis/scripting-1/#) 。
+  - `<2.3.1>` 处，如果是动态 SQL ，则创建 DynamicSqlSource 对象。详细解析，见 [《精尽 MyBatis 源码分析 —— SQL 初始化（下）之 SqlSource》](http://svip.iocoder.cn/MyBatis/scripting-2) 的 [「4.2 DynamicSqlSource」](https://svip.iocoder.cn/MyBatis/scripting-1/#) 。
+  - `<2.3.2>` 处，如果非动态 SQL ，则创建 RawSqlSource 对象。详细解析，见 [《精尽 MyBatis 源码分析 —— SQL 初始化（下）之 SqlSource》](http://svip.iocoder.cn/MyBatis/scripting-2) 的 [「4.3 RawSqlSource」](https://svip.iocoder.cn/MyBatis/scripting-1/#) 。
+
+## 2.2 RawLanguageDriver
+
+`org.apache.ibatis.scripting.defaults.RawLanguageDriver` ，继承 XMLLanguageDriver 类，**RawSqlSource** 语言驱动器实现类，确保创建的 SqlSource 是 **RawSqlSource** 类。代码如下：
+
+```
+// RawLanguageDriver.java
+
+public class RawLanguageDriver extends XMLLanguageDriver {
+
+    @Override
+    public SqlSource createSqlSource(Configuration configuration, XNode script, Class<?> parameterType) {
+        // 调用父类，创建 SqlSource 对象
+        SqlSource source = super.createSqlSource(configuration, script, parameterType);
+        // 校验创建的是 RawSqlSource 对象
+        checkIsNotDynamic(source);
+        return source;
+    }
+
+    @Override
+    public SqlSource createSqlSource(Configuration configuration, String script, Class<?> parameterType) {
+        // 调用父类，创建 SqlSource 对象
+        SqlSource source = super.createSqlSource(configuration, script, parameterType);
+        // 校验创建的是 RawSqlSource 对象
+        checkIsNotDynamic(source);
+        return source;
+    }
+
+    /**
+     * 校验是 RawSqlSource 对象
+     *
+     * @param source 创建的 SqlSource 对象
+     */
+    private void checkIsNotDynamic(SqlSource source) {
+        if (!RawSqlSource.class.equals(source.getClass())) {
+            throw new BuilderException("Dynamic content is not allowed when using RAW language");
+        }
+    }
+
+}
+```
+
+- 先基于父方法，创建 SqlSource 对象，然后再调用 `#checkIsNotDynamic(SqlSource source)` 方法，进行校验是否为 RawSqlSource 对象。
+
+## 2.3 LanguageDriverRegistry
+
+> 老艿艿：这个类不是 LanguageDriver 的子类。
+
+`org.apache.ibatis.scripting.LanguageDriverRegistry` ，LanguageDriver 注册表。代码如下：
+
+```
+// LanguageDriverRegistry.java
+
+public class LanguageDriverRegistry {
+
+    /**
+     * LanguageDriver 映射
+     */
+    private final Map<Class<? extends LanguageDriver>, LanguageDriver> LANGUAGE_DRIVER_MAP = new HashMap<>();
+    /**
+     * 默认的 LanguageDriver 类
+     */
+    private Class<? extends LanguageDriver> defaultDriverClass;
+
+    public void register(Class<? extends LanguageDriver> cls) {
+        if (cls == null) {
+            throw new IllegalArgumentException("null is not a valid Language Driver");
+        }
+        // 创建 cls 对应的对象，并添加到 LANGUAGE_DRIVER_MAP 中
+        if (!LANGUAGE_DRIVER_MAP.containsKey(cls)) {
+            try {
+                LANGUAGE_DRIVER_MAP.put(cls, cls.newInstance());
+            } catch (Exception ex) {
+                throw new ScriptingException("Failed to load language driver for " + cls.getName(), ex);
+            }
+        }
+    }
+
+    public void register(LanguageDriver instance) {
+        if (instance == null) {
+            throw new IllegalArgumentException("null is not a valid Language Driver");
+        }
+        // 添加到 LANGUAGE_DRIVER_MAP 中
+        Class<? extends LanguageDriver> cls = instance.getClass();
+        if (!LANGUAGE_DRIVER_MAP.containsKey(cls)) {
+            LANGUAGE_DRIVER_MAP.put(cls, instance);
+        }
+    }
+
+    public LanguageDriver getDriver(Class<? extends LanguageDriver> cls) {
+        return LANGUAGE_DRIVER_MAP.get(cls);
+    }
+
+    public LanguageDriver getDefaultDriver() {
+        return getDriver(getDefaultDriverClass());
+    }
+
+    public Class<? extends LanguageDriver> getDefaultDriverClass() {
+        return defaultDriverClass;
+    }
+
+    /**
+     * 设置 {@link #defaultDriverClass}
+     *
+     * @param defaultDriverClass 默认的 LanguageDriver 类
+     */
+    public void setDefaultDriverClass(Class<? extends LanguageDriver> defaultDriverClass) {
+        // 注册到 LANGUAGE_DRIVER_MAP 中
+        register(defaultDriverClass);
+        // 设置 defaultDriverClass 属性
+        this.defaultDriverClass = defaultDriverClass;
+    }
+
+}
+```
+
+- 比较简单，胖友自己瞅瞅就好。
+
+### 2.3.1 初始化
+
+在 Configuration 的构造方法中，会进行初始化。代码如下：
+
+```
+// Configuration.java
+
+/**
+ * LanguageDriverRegistry 对象
+ */
+protected final LanguageDriverRegistry languageRegistry = new LanguageDriverRegistry();
+
+public Configuration() {
+    // ... 省略其它代码
+    
+    // 注册到 languageRegistry 中
+    languageRegistry.setDefaultDriverClass(XMLLanguageDriver.class);
+    languageRegistry.register(RawLanguageDriver.class);
+}
+```
+
+- 默认情况下，使用 XMLLanguageDriver 类。
+
+- 大多数情况下，我们不会去设置使用的 LanguageDriver 类，而是使用 **XMLLanguageDriver** 类。从 `#getLanguageDriver(Class<? extends LanguageDriver> langClass)` 方法，可知。代码如下：
+
+  ```
+  // Configuration.java
+  
+  public LanguageDriver getLanguageDriver(Class<? extends LanguageDriver> langClass) {
+      // 获得 langClass 类
+      if (langClass != null) {
+          configuration.getLanguageRegistry().register(langClass);
+      } else { // 如果为空，则使用默认类
+          langClass = configuration.getLanguageRegistry().getDefaultDriverClass();
+      }
+      // 获得 LanguageDriver 对象
+      return configuration.getLanguageRegistry().getDriver(langClass);
+  }
+  ```
+
+# 3. XMLScriptBuilder
+
+`org.apache.ibatis.scripting.xmltags.XMLScriptBuilder` ，继承 BaseBuilder 抽象类，XML 动态语句( SQL )构建器，负责将 SQL 解析成 SqlSource 对象。
+
+## 3.1 构造方法
+
+```
+// XMLScriptBuilder.java
+
+/**
+ * 当前 SQL 的 XNode 对象
+ */
+private final XNode context;
+/**
+ * 是否为动态 SQL
+ */
+private boolean isDynamic;
+/**
+ * SQL 方法类型
+ */
+private final Class<?> parameterType;
+/**
+ * NodeNodeHandler 的映射
+ */
+private final Map<String, NodeHandler> nodeHandlerMap = new HashMap<>();
+
+public XMLScriptBuilder(Configuration configuration, XNode context, Class<?> parameterType) {
+    super(configuration);
+    this.context = context;
+    this.parameterType = parameterType;
+    // 初始化 nodeHandlerMap 属性
+    initNodeHandlerMap();
+}
+```
+
+- 调用 `#initNodeHandlerMap()` 方法，初始化 `nodeHandlerMap` 属性。代码如下：
+
+  ```
+  // XMLScriptBuilder.java
+  
+  private void initNodeHandlerMap() {
+      nodeHandlerMap.put("trim", new TrimHandler());
+      nodeHandlerMap.put("where", new WhereHandler());
+      nodeHandlerMap.put("set", new SetHandler());
+      nodeHandlerMap.put("foreach", new ForEachHandler());
+      nodeHandlerMap.put("if", new IfHandler());
+      nodeHandlerMap.put("choose", new ChooseHandler());
+      nodeHandlerMap.put("when", new IfHandler());
+      nodeHandlerMap.put("otherwise", new OtherwiseHandler());
+      nodeHandlerMap.put("bind", new BindHandler());
+  }
+  ```
+
+  - 我们可以看到，`nodeHandlerMap` 的 KEY 是熟悉的 MyBatis 的自定义的 XML 标签。并且，每个标签对应**专属**的一个 NodeHandler 实现类。
+
+## 3.2 parseScriptNode
+
+`#parseScriptNode()` 方法，负责将 SQL 解析成 SqlSource 对象。代码如下：
+
+```
+// XMLScriptBuilder.java
+
+public SqlSource parseScriptNode() {
+    // <1> 解析 SQL
+    MixedSqlNode rootSqlNode = parseDynamicTags(context);
+    // <2> 创建 SqlSource 对象
+    SqlSource sqlSource;
+    if (isDynamic) {
+        sqlSource = new DynamicSqlSource(configuration, rootSqlNode);
+    } else {
+        sqlSource = new RawSqlSource(configuration, rootSqlNode, parameterType);
+    }
+    return sqlSource;
+}
+```
+
+- `<1>` 方法，调用 `#parseDynamicTags(XNode node)` 方法，解析 SQL 成 MixedSqlNode 对象。详细解析，见 [「3.3 parseDynamicTags」](https://svip.iocoder.cn/MyBatis/scripting-1/#) 。
+- `<2>` 方法，根据是否是动态 SQL ，创建对应的 DynamicSqlSource 或 RawSqlSource 对象。
+
+## 3.3 parseDynamicTags
+
+`#parseDynamicTags(XNode node)` 方法，解析 SQL 成 MixedSqlNode 对象。代码如下：
+
+```
+// XMLScriptBuilder.java
+
+protected MixedSqlNode parseDynamicTags(XNode node) {
+    // <1> 创建 SqlNode 数组
+    List<SqlNode> contents = new ArrayList<>();
+    // <2> 遍历 SQL 节点的所有子节点
+    NodeList children = node.getNode().getChildNodes();
+    for (int i = 0; i < children.getLength(); i++) {
+        // 当前子节点
+        XNode child = node.newXNode(children.item(i));
+        // <2.1> 如果类型是 Node.CDATA_SECTION_NODE 或者 Node.TEXT_NODE 时
+        if (child.getNode().getNodeType() == Node.CDATA_SECTION_NODE || child.getNode().getNodeType() == Node.TEXT_NODE) {
+            // <2.1.1> 获得内容
+            String data = child.getStringBody("");
+            // <2.1.2> 创建 TextSqlNode 对象
+            TextSqlNode textSqlNode = new TextSqlNode(data);
+            // <2.1.2.1> 如果是动态的 TextSqlNode 对象
+            if (textSqlNode.isDynamic()) {
+                // 添加到 contents 中
+                contents.add(textSqlNode);
+                // 标记为动态 SQL
+                isDynamic = true;
+            // <2.1.2.2> 如果是非动态的 TextSqlNode 对象
+            } else {
+                // <2.1.2> 创建 StaticTextSqlNode 添加到 contents 中
+                contents.add(new StaticTextSqlNode(data));
+            }
+        // <2.2> 如果类型是 Node.ELEMENT_NODE
+        } else if (child.getNode().getNodeType() == Node.ELEMENT_NODE) { // issue #628
+            // <2.2.1> 根据子节点的标签，获得对应的 NodeHandler 对象
+            String nodeName = child.getNode().getNodeName();
+            NodeHandler handler = nodeHandlerMap.get(nodeName);
+            if (handler == null) { // 获得不到，说明是未知的标签，抛出 BuilderException 异常
+                throw new BuilderException("Unknown element <" + nodeName + "> in SQL statement.");
+            }
+            // <2.2.2> 执行 NodeHandler 处理
+            handler.handleNode(child, contents);
+            // <2.2.3> 标记为动态 SQL
+            isDynamic = true;
+        }
+    }
+    // <3> 创建 MixedSqlNode 对象
+    return new MixedSqlNode(contents);
+}
+```
+
+- `<1>` 处，创建 SqlNode 数组。
+
+- ```
+  <2>
+  ```
+
+   
+
+  处，遍历 SQL 节点的所有子节点，处理每个子节点成对应的 SqlNode 对象，添加到数组中。如下图，是一个示例：
+
+  ![示例](19-mybatis-SQL 初始化（上）之 SqlNode.assets/03.png)
+
+  示例
+
+  - XML 本身是个**嵌套**的树结构，所以最终的结果，也是**嵌套**的 SqlNode 数组结构。
+
+  - ```
+    <2.1>
+    ```
+
+     
+
+    处，如果节点类型是
+
+     
+
+    ```
+    Node.CDATA_SECTION_NODE
+    ```
+
+     
+
+    或者
+
+     
+
+    ```
+    Node.TEXT_NODE
+    ```
+
+     
+
+    时。
+
+    - `<2.1.1>` 处， 获得节点的内容。
+
+    - ```
+      <2.1.2>
+      ```
+
+       
+
+      处，创建 TextSqlNode 对象。
+
+      - `<2.1.2.1>` 处，如果是动态的 TextSqlNode 对象，则添加到 `contents` 中，并标记为动态 SQL 。例如：`SELECT * FROM subject` 。
+      - `<2.1.2.2>` 处，如果非动态的 TextSqlNode 对象，则创建 StaticTextSqlNode 对象，并添加到 `contents` 中。例如：`id = ${id}` 。
+
+  - ```
+    <2.2>
+    ```
+
+     
+
+    处，如果节点类型是
+
+     
+
+    ```
+    Node.ELEMENT_NODE
+    ```
+
+     
+
+    时。例如：
+
+    ```
+    <where> <choose> <when test="${id != null}"> id = ${id} </when> </choose> </where>
+    ```
+
+    。
+
+    - `<2.2.1>` 处，根据子节点的标签，获得对应的 NodeHandler 对象。
+    - `<2.2.2>` 处，执行 NodeHandler 处理。
+    - `<2.2.3>` 处，标记为动态 SQL 。
+
+- `<3>` 处，将 `contents` 数组，封装成 MixedSqlNode 对象。详细解析，见 [「6.10 MixedSqlNode」](https://svip.iocoder.cn/MyBatis/scripting-1/#) 。
+
+- 关于这块逻辑，胖友可以自己多多调试下。
+
+# 4. NodeHandler
+
+NodeHandler ，在 XMLScriptBuilder 类中，Node 处理器接口。代码如下：
+
+```
+// XMLScriptBuilder.java
+
+private interface NodeHandler {
+
+    /**
+     * 处理 Node
+     *
+     * @param nodeToHandle 要处理的 XNode 节点
+     * @param targetContents 目标的 SqlNode 数组。实际上，被处理的 XNode 节点会创建成对应的 SqlNode 对象，添加到 targetContents 中
+     */
+    void handleNode(XNode nodeToHandle, List<SqlNode> targetContents);
+
+}
+```
+
+NodeHandler 有多个子类实现，如下图所示：[![NodeHandler 子类](19-mybatis-SQL 初始化（上）之 SqlNode.assets/04.png)](http://static.iocoder.cn/images/MyBatis/2020_02_22/04.png)NodeHandler 子类
+
+- 并且，每个 NodeHandler 实现类，也是 **XMLScriptBuilder** 类中。
+
+## 4.1 BindHandler
+
+BindHandler ，实现 NodeHandler 接口，`<bind />` 标签的处理器。代码如下：
+
+```
+// XMLScriptBuilder.java
+
+private class BindHandler implements NodeHandler {
+
+    public BindHandler() {
+        // Prevent Synthetic Access
+    }
+
+    @Override
+    public void handleNode(XNode nodeToHandle, List<SqlNode> targetContents) {
+        // 解析 name、value 属性
+        final String name = nodeToHandle.getStringAttribute("name");
+        final String expression = nodeToHandle.getStringAttribute("value");
+        // 创建 VarDeclSqlNode 对象
+        final VarDeclSqlNode node = new VarDeclSqlNode(name, expression);
+        // 添加到 targetContents 中
+        targetContents.add(node);
+    }
+}
+```
+
+- 解析 `name`、`value` 属性，并创建 VarDeclSqlNode 对象，最后添加到 `targetContents` 中。
+- 关于 VarDeclSqlNode 类，详细解析，见 [「6.1 VarDeclSqlNode」](https://svip.iocoder.cn/MyBatis/scripting-1/#) 。
+
+## 4.2 TrimHandler
+
+TrimHandler ，实现 NodeHandler 接口，`<trim />` 标签的处理器。代码如下：
+
+```
+// XMLScriptBuilder.java
+
+private class TrimHandler implements NodeHandler {
+
+    public TrimHandler() {
+        // Prevent Synthetic Access
+    }
+
+    @Override
+    public void handleNode(XNode nodeToHandle, List<SqlNode> targetContents) {
+        // <1> 解析内部的 SQL 节点，成 MixedSqlNode 对象
+        MixedSqlNode mixedSqlNode = parseDynamicTags(nodeToHandle);
+        // <2> 获得 prefix、prefixOverrides、"suffix"、suffixOverrides 属性
+        String prefix = nodeToHandle.getStringAttribute("prefix");
+        String prefixOverrides = nodeToHandle.getStringAttribute("prefixOverrides");
+        String suffix = nodeToHandle.getStringAttribute("suffix");
+        String suffixOverrides = nodeToHandle.getStringAttribute("suffixOverrides");
+        // <3> 创建 TrimSqlNode 对象
+        TrimSqlNode trim = new TrimSqlNode(configuration, mixedSqlNode, prefix, prefixOverrides, suffix, suffixOverrides);
+        // <4> 添加到 targetContents 中
+        targetContents.add(trim);
+    }
+
+}
+```
+
+- `<1>` 处，调用 `#parseDynamicTags(XNode node)` 方法，解析内部的 SQL 节点，成 MixedSqlNode 对象。即 [「3.3 parseDynamicTags」](https://svip.iocoder.cn/MyBatis/scripting-1/#) 的流程。
+- `<2>` 处，获得 `prefix`、`prefixOverrides`、`suffix`、`suffixOverrides` 属性。
+- `<3>` 处，创建 TrimSqlNode 对象。详细解析，见 [「6.2 TrimSqlNode」](https://svip.iocoder.cn/MyBatis/scripting-1/#) 。
+- `<4>` 处，添加到 `targetContents` 中。
+
+## 4.3 WhereHandler
+
+WhereHandler ，实现 NodeHandler 接口，`<where />` 标签的处理器。代码如下：
+
+```
+// XMLScriptBuilder.java
+
+private class WhereHandler implements NodeHandler {
+
+    public WhereHandler() {
+        // Prevent Synthetic Access
+    }
+
+    @Override
+    public void handleNode(XNode nodeToHandle, List<SqlNode> targetContents) {
+        // 解析内部的 SQL 节点，成 MixedSqlNode 对象
+        MixedSqlNode mixedSqlNode = parseDynamicTags(nodeToHandle);
+        // 创建 WhereSqlNode 对象
+        WhereSqlNode where = new WhereSqlNode(configuration, mixedSqlNode);
+        // 添加到 targetContents 中
+        targetContents.add(where);
+    }
+
+}
+```
+
+- 从实现逻辑的思路上，和 TrimHandler 是一个套路的。
+- 关于 WhereSqlNode ，详细解析，见 [「6.3 WhereSqlNode」](https://svip.iocoder.cn/MyBatis/scripting-1/#) 。
+
+## 4.4 SetHandler
+
+SetHandler ，实现 NodeHandler 接口，`<set />` 标签的处理器。代码如下：
+
+```
+// XMLScriptBuilder.java
+
+private class SetHandler implements NodeHandler {
+
+    public SetHandler() {
+        // Prevent Synthetic Access
+    }
+
+    @Override
+    public void handleNode(XNode nodeToHandle, List<SqlNode> targetContents) {
+        // 解析内部的 SQL 节点，成 MixedSqlNode 对象
+        MixedSqlNode mixedSqlNode = parseDynamicTags(nodeToHandle);
+        // 创建 SetSqlNode 对象
+        SetSqlNode set = new SetSqlNode(configuration, mixedSqlNode);
+        // 添加到 targetContents 中
+        targetContents.add(set);
+    }
+
+}
+```
+
+- 从实现逻辑的思路上，和 TrimHandler 也是一个套路的。
+- 关于 SetSqlNode ，详细解析，见 [「6.4 SetSqlNode」](https://svip.iocoder.cn/MyBatis/scripting-1/#) 。
+
+## 4.5 ForEachHandler
+
+ForEachHandler ，实现 NodeHandler 接口，`<foreach />` 标签的处理器。代码如下：
+
+```
+// XMLScriptBuilder.java
+
+private class ForEachHandler implements NodeHandler {
+
+    public ForEachHandler() {
+        // Prevent Synthetic Access
+    }
+
+    @Override
+    public void handleNode(XNode nodeToHandle, List<SqlNode> targetContents) {
+        // 解析内部的 SQL 节点，成 MixedSqlNode 对象
+        MixedSqlNode mixedSqlNode = parseDynamicTags(nodeToHandle);
+        // 获得 collection、item、index、open、close、separator 属性
+        String collection = nodeToHandle.getStringAttribute("collection");
+        String item = nodeToHandle.getStringAttribute("item");
+        String index = nodeToHandle.getStringAttribute("index");
+        String open = nodeToHandle.getStringAttribute("open");
+        String close = nodeToHandle.getStringAttribute("close");
+        String separator = nodeToHandle.getStringAttribute("separator");
+        // 创建 ForEachSqlNode 对象
+        ForEachSqlNode forEachSqlNode = new ForEachSqlNode(configuration, mixedSqlNode, collection, index, item, open, close, separator);
+        // 添加到 targetContents 中
+        targetContents.add(forEachSqlNode);
+    }
+
+}
+```
+
+- 关于 ForEachSqlNode ，详细解析，见 [「6.5 ForEachSqlNode」](https://svip.iocoder.cn/MyBatis/scripting-1/#) 。
+
+## 4.6 IfHandler
+
+IfHandler ，实现 NodeHandler 接口，`<if />` 标签的处理器。代码如下：
+
+```
+// XMLScriptBuilder.java
+
+private class IfHandler implements NodeHandler {
+
+    public IfHandler() {
+        // Prevent Synthetic Access
+    }
+
+    @Override
+    public void handleNode(XNode nodeToHandle, List<SqlNode> targetContents) {
+        // 解析内部的 SQL 节点，成 MixedSqlNode 对象
+        MixedSqlNode mixedSqlNode = parseDynamicTags(nodeToHandle);
+        // 获得 test 属性
+        String test = nodeToHandle.getStringAttribute("test");
+        // 创建 IfSqlNode 对象
+        IfSqlNode ifSqlNode = new IfSqlNode(mixedSqlNode, test);
+        // 添加到 targetContents 中
+        targetContents.add(ifSqlNode);
+    }
+    
+}
+```
+
+- 关于 ForEachSqlNode ，详细解析，见 [「6.6 IfSqlNode」](https://svip.iocoder.cn/MyBatis/scripting-1/#) 。
+
+## 4.7 OtherwiseHandler
+
+OtherwiseHandler ，实现 NodeHandler 接口，`<otherwise />` 标签的处理器。代码如下：
+
+```
+// XMLScriptBuilder.java
+
+private class OtherwiseHandler implements NodeHandler {
+
+    public OtherwiseHandler() {
+        // Prevent Synthetic Access
+    }
+
+    @Override
+    public void handleNode(XNode nodeToHandle, List<SqlNode> targetContents) {
+        // 解析内部的 SQL 节点，成 MixedSqlNode 对象
+        MixedSqlNode mixedSqlNode = parseDynamicTags(nodeToHandle);
+        // 添加到 targetContents 中
+        targetContents.add(mixedSqlNode);
+    }
+
+}
+```
+
+- 对于 `<otherwise />` 标签，解析的结果是 MixedSqlNode 对象即可。因为，只要执行到，**一定满足条件**。
+
+## 4.8 ChooseHandler
+
+ChooseHandler ，实现 NodeHandler 接口，`<choose />` 标签的处理器。代码如下：
+
+```
+// XMLScriptBuilder.java
+
+private class ChooseHandler implements NodeHandler {
+
+    public ChooseHandler() {
+        // Prevent Synthetic Access
+    }
+
+    @Override
+    public void handleNode(XNode nodeToHandle, List<SqlNode> targetContents) {
+        List<SqlNode> whenSqlNodes = new ArrayList<>();
+        List<SqlNode> otherwiseSqlNodes = new ArrayList<>();
+        // 解析 `<when />` 和 `<otherwise />` 的节点们
+        handleWhenOtherwiseNodes(nodeToHandle, whenSqlNodes, otherwiseSqlNodes);
+        // 获得 `<otherwise />` 的节点
+        SqlNode defaultSqlNode = getDefaultSqlNode(otherwiseSqlNodes);
+        // 创建 ChooseSqlNode 对象
+        ChooseSqlNode chooseSqlNode = new ChooseSqlNode(whenSqlNodes, defaultSqlNode);
+        // 添加到 targetContents 中
+        targetContents.add(chooseSqlNode);
+    }
+
+    private void handleWhenOtherwiseNodes(XNode chooseSqlNode, List<SqlNode> ifSqlNodes, List<SqlNode> defaultSqlNodes) {
+        List<XNode> children = chooseSqlNode.getChildren();
+        for (XNode child : children) {
+            String nodeName = child.getNode().getNodeName();
+            NodeHandler handler = nodeHandlerMap.get(nodeName);
+            if (handler instanceof IfHandler) { // 处理 `<when />` 标签的情况
+                handler.handleNode(child, ifSqlNodes);
+            } else if (handler instanceof OtherwiseHandler) { // 处理 `<otherwise />` 标签的情况
+                handler.handleNode(child, defaultSqlNodes);
+            }
+        }
+    }
+
+    // 至多允许有一个 SqlNode 节点
+    private SqlNode getDefaultSqlNode(List<SqlNode> defaultSqlNodes) {
+        SqlNode defaultSqlNode = null;
+        if (defaultSqlNodes.size() == 1) {
+            defaultSqlNode = defaultSqlNodes.get(0);
+        } else if (defaultSqlNodes.size() > 1) {
+            throw new BuilderException("Too many default (otherwise) elements in choose statement.");
+        }
+        return defaultSqlNode;
+    }
+}
+```
+
+- 通过组合 IfHandler 和 OtherwiseHandler 两个处理器，实现对子节点们的解析。最终，生成 ChooseSqlNode 对象。关于 ChooseSqlNode 类，详细解析，见 。
+
+# 5. DynamicContext
+
+`org.apache.ibatis.scripting.xmltags.DynamicContext` ，动态 SQL ，用于每次执行 SQL 操作时，记录动态 SQL 处理后的最终 SQL 字符串。
+
+## 5.1 构造方法
+
+```
+// DynamicContext.java
+
+/**
+ * {@link #bindings} _parameter 的键，参数
+ */
+public static final String PARAMETER_OBJECT_KEY = "_parameter";
+/**
+ * {@link #bindings} _databaseId 的键，数据库编号
+ */
+public static final String DATABASE_ID_KEY = "_databaseId";
+
+static {
+    // <1.2> 设置 OGNL 的属性访问器
+    OgnlRuntime.setPropertyAccessor(ContextMap.class, new ContextAccessor());
+}
+
+/**
+ * 上下文的参数集合
+ */
+private final ContextMap bindings;
+/**
+ * 生成后的 SQL
+ */
+private final StringBuilder sqlBuilder = new StringBuilder();
+/**
+ * 唯一编号。在 {@link org.apache.ibatis.scripting.xmltags.XMLScriptBuilder.ForEachHandler} 使用
+ */
+private int uniqueNumber = 0;
+
+// 当需要使用到 OGNL 表达式时，parameterObject 非空
+public DynamicContext(Configuration configuration, Object parameterObject) {
+    // <1> 初始化 bindings 参数
+    if (parameterObject != null && !(parameterObject instanceof Map)) {
+        MetaObject metaObject = configuration.newMetaObject(parameterObject); // <1.1>
+        bindings = new ContextMap(metaObject);
+    } else {
+        bindings = new ContextMap(null);
+    }
+    // <2> 添加 bindings 的默认值
+    bindings.put(PARAMETER_OBJECT_KEY, parameterObject);
+    bindings.put(DATABASE_ID_KEY, configuration.getDatabaseId());
+}
+```
+
+- `<1>` 处，初始化 `bindings` 参数，创建 ContextMap 对象。
+
+  - `parameterObject` 方法参数，当需要使用到 OGNL 表达式时，`parameterObject` 才会非空。下文，我们将会看到为什么。
+
+  - `<1.1>` 处，我们可以看到，调用 `Configuration#newMetaObject(Object object)` 方法，创建 MetaObject 对象，实现对 `parameterObject` 参数的访问。代码如下：
+
+    ```
+    // Configuration.java
+    
+    protected ReflectorFactory reflectorFactory = new DefaultReflectorFactory();
+    protected ObjectFactory objectFactory = new DefaultObjectFactory();
+    protected ObjectWrapperFactory objectWrapperFactory = new DefaultObjectWrapperFactory();
+        
+    public MetaObject newMetaObject(Object object) {
+        return MetaObject.forObject(object, objectFactory, objectWrapperFactory, reflectorFactory);
+    }
+    ```
+
+    - 关于 MetaObject ，在 [《精尽 MyBatis 源码分析 —— 反射模块》](http://svip.iocoder.cn/MyBatis/reflection-package)
+
+  - `<1.2>` 处， 设置 OGNL 的属性访问器。其中，OgnlRuntime 是 [`ognl`](https://mvnrepository.com/artifact/ognl/ognl) 库中的类。并且，ContextMap 对应的访问器是 ContextAccessor 类。
+
+- `<2>` 处，添加 `bindings` 的默认值。目前有 `PARAMETER_OBJECT_KEY`、`DATABASE_ID_KEY` 属性。
+
+## 5.2 bindings 属性相关的方法
+
+```
+// DynamicContext.java
+
+public Map<String, Object> getBindings() {
+    return bindings;
+}
+
+public void bind(String name, Object value) {
+    bindings.put(name, value);
+}
+```
+
+- 可以往 `bindings` 属性中，添加新的 KV 键值对。
+
+## 5.3 sqlBuilder 属性相关的方法
+
+```
+// DynamicContext.java
+
+public void appendSql(String sql) {
+    sqlBuilder.append(sql);
+    sqlBuilder.append(" ");
+}
+
+public String getSql() {
+    return sqlBuilder.toString().trim();
+}
+```
+
+- 可以不断向 `sqlBuilder` 属性中，添加 SQL **段**。
+
+## 5.4 uniqueNumber 属性相关的方法
+
+```
+// DynamicContext.java
+
+public int getUniqueNumber() {
+    return uniqueNumber++;
+}
+```
+
+- 每次请求，获得新的序号。
+
+## 5.5 ContextMap
+
+ContextMap ，是 DynamicContext 的内部静态类，继承 HashMap 类，上下文的参数集合。代码如下：
+
+```
+// DynamicContext.java
+
+static class ContextMap extends HashMap<String, Object> {
+
+    private static final long serialVersionUID = 2977601501966151582L;
+
+    /**
+     * parameter 对应的 MetaObject 对象
+     */
+    private MetaObject parameterMetaObject;
+
+    public ContextMap(MetaObject parameterMetaObject) {
+        this.parameterMetaObject = parameterMetaObject;
+    }
+
+    @Override
+    public Object get(Object key) {
+        // 如果有 key 对应的值，直接获得
+        String strKey = (String) key;
+        if (super.containsKey(strKey)) {
+            return super.get(strKey);
+        }
+
+        // 从 parameterMetaObject 中，获得 key 对应的属性
+        if (parameterMetaObject != null) {
+            // issue #61 do not modify the context when reading
+            return parameterMetaObject.getValue(strKey);
+        }
+
+        return null;
+    }
+}
+```
+
+- 该类在 HashMap 的基础上，增加支持对 `parameterMetaObject` 属性的访问。
+
+## 5.6 ContextAccessor
+
+ContextAccessor ，是 DynamicContext 的内部静态类，实现 `ognl.PropertyAccessor` 接口，上下文访问器。代码如下：
+
+```
+// DynamicContext.java
+
+static class ContextAccessor implements PropertyAccessor {
+
+    @Override
+    public Object getProperty(Map context, Object target, Object name)
+            throws OgnlException {
+        Map map = (Map) target;
+
+        // 优先从 ContextMap 中，获得属性
+        Object result = map.get(name);
+        if (map.containsKey(name) || result != null) {
+            return result;
+        }
+
+        // <x> 如果没有，则从 PARAMETER_OBJECT_KEY 对应的 Map 中，获得属性
+        Object parameterObject = map.get(PARAMETER_OBJECT_KEY);
+        if (parameterObject instanceof Map) {
+            return ((Map) parameterObject).get(name);
+        }
+
+        return null;
+    }
+
+    @Override
+    public void setProperty(Map context, Object target, Object name, Object value)
+            throws OgnlException {
+        Map<Object, Object> map = (Map<Object, Object>) target;
+        map.put(name, value);
+    }
+
+    @Override
+    public String getSourceAccessor(OgnlContext arg0, Object arg1, Object arg2) {
+        return null;
+    }
+
+    @Override
+    public String getSourceSetter(OgnlContext arg0, Object arg1, Object arg2) {
+        return null;
+    }
+}
+```
+
+- `<x>` 处，为什么可以访问 `PARAMETER_OBJECT_KEY` 属性，并且是 Map 类型呢？回看 DynamicContext 构造方法，就可以明白了。
+
+# 6. SqlNode
+
+`org.apache.ibatis.scripting.xmltags.SqlNode` ，SQL Node 接口，每个 XML Node 会解析成对应的 SQL Node 对象。代码如下：
+
+```
+// SqlNode.java
+
+public interface SqlNode {
+
+    /**
+     * 应用当前 SQL Node 节点
+     *
+     * @param context 上下文
+     * @return 当前 SQL Node 节点是否应用成功。
+     */
+    boolean apply(DynamicContext context);
+
+}
+```
+
+- 比较难以理解的是 `#apply(DynamicContext context)` 方法，返回值类型是 `boolean` 。为什么呢？具体在 ChooseSqlNode 可找到答案。
+
+## 6.1 VarDeclSqlNode
+
+`org.apache.ibatis.scripting.xmltags.VarDeclSqlNode` ，实现 SqlNode 接口，`<bind />` 标签的 SqlNode 实现类。代码如下：
+
+```
+// VarDeclSqlNode.java
+
+public class VarDeclSqlNode implements SqlNode {
+
+    /**
+     * 名字
+     */
+    private final String name;
+    /**
+     * 表达式
+     */
+    private final String expression;
+
+    public VarDeclSqlNode(String var, String exp) {
+        name = var;
+        expression = exp;
+    }
+
+    @Override
+    public boolean apply(DynamicContext context) {
+        // <1> 获得值
+        final Object value = OgnlCache.getValue(expression, context.getBindings());
+        // <2> 绑定到上下文
+        context.bind(name, value);
+        return true;
+    }
+
+}
+```
+
+- `<1>` 处，调用 `OgnlCache#getValue(String expression, Object root)` 方法，获得表达式对应的值。详细解析，见 [「7.1 OgnlCache」](https://svip.iocoder.cn/MyBatis/scripting-1/#) 。
+- `<2>` 处，调用 `DynamicContext#bind(String name, Object value)` 方法，绑定到上下文。
+
+## 6.2 TrimSqlNode
+
+`org.apache.ibatis.scripting.xmltags.TrimSqlNode` ，实现 SqlNode 接口，`<trim />` 标签的 SqlNode 实现类。
+
+关于 TrimSqlNode 的概念，可能从类名上无法很好的反馈出来，可以看下文档 [《MyBatis 文档 —— 动态 SQL》](http://www.mybatis.org/mybatis-3/zh/dynamic-sql.html) ，搜 [「trim」](https://svip.iocoder.cn/MyBatis/scripting-1/#) 关键字。
+
+另外，在下文中，我们会看到，`trim />` 标签是 `<where />` 和 `<set />` 标签的**基础**。
+
+### 6.2.1 构造方法
+
+```
+// TrimSqlNode.java
+
+/**
+ * 内含的 SqlNode 节点
+ */
+private final SqlNode contents;
+/**
+ * 前缀
+ */
+private final String prefix;
+/**
+ * 后缀
+ */
+private final String suffix;
+/**
+ * 需要被删除的前缀
+ */
+private final List<String> prefixesToOverride;
+/**
+ * 需要被删除的后缀
+ */
+private final List<String> suffixesToOverride;
+private final Configuration configuration;
+
+public TrimSqlNode(Configuration configuration, SqlNode contents, String prefix, String prefixesToOverride, String suffix, String suffixesToOverride) {
+    this(configuration, contents, prefix, parseOverrides(prefixesToOverride), suffix, parseOverrides(suffixesToOverride));
+}
+
+protected TrimSqlNode(Configuration configuration, SqlNode contents, String prefix, List<String> prefixesToOverride, String suffix, List<String> suffixesToOverride) {
+    this.contents = contents;
+    this.prefix = prefix;
+    this.prefixesToOverride = prefixesToOverride;
+    this.suffix = suffix;
+    this.suffixesToOverride = suffixesToOverride;
+    this.configuration = configuration;
+}
+```
+
+- `#parseOverrides(String overrides)` 方法，使用 `|` 分隔字符串成字符串数组，并都转换成**大写**。代码如下：
+
+  ```
+  // TrimSqlNode.java
+  
+  private static List<String> parseOverrides(String overrides) {
+      if (overrides != null) {
+          final StringTokenizer parser = new StringTokenizer(overrides, "|", false);
+          final List<String> list = new ArrayList<>(parser.countTokens());
+          while (parser.hasMoreTokens()) {
+              list.add(parser.nextToken().toUpperCase(Locale.ENGLISH));
+          }
+          return list;
+      }
+      return Collections.emptyList();
+  }
+  ```
+
+### 6.2.2 apply
+
+```
+// TrimSqlNode.java
+
+@Override
+public boolean apply(DynamicContext context) {
+    // <1> 创建 FilteredDynamicContext 对象
+    FilteredDynamicContext filteredDynamicContext = new FilteredDynamicContext(context);
+    // <2> 执行 contents 的应用
+    boolean result = contents.apply(filteredDynamicContext);
+    // <3> 执行 FilteredDynamicContext 的应用
+    filteredDynamicContext.applyAll();
+    return result;
+}
+```
+
+- `<1>` 处，创建 FilteredDynamicContext 对象。关于 FilteredDynamicContext 类，在 [「6.2.3 FilteredDynamicContext」](https://svip.iocoder.cn/MyBatis/scripting-1/#) 。
+- `<2>` 处，执行 `contents` 的应用。
+- `<3>` 处，调用 `FilteredDynamicContext#applyAll()` 方法，执行 FilteredDynamicContext 的应用。
+
+### 6.2.3 FilteredDynamicContext
+
+FilteredDynamicContext ，是 TrimSqlNode 的内部类，继承 DynamicContext 类，支持 **trim** 逻辑的 DynamicContext 实现类。
+
+#### 6.2.3.1 构造方法
+
+```
+// TrimSqlNode.java
+
+/**
+ * 委托的 DynamicContext 对象
+ */
+private DynamicContext delegate;
+/**
+ * 是否 prefix 已经被应用
+ */
+private boolean prefixApplied;
+/**
+ * 是否 suffix 已经被应用
+ */
+private boolean suffixApplied;
+/**
+ * StringBuilder 对象
+ *
+ * @see #appendSql(String)
+ */
+private StringBuilder sqlBuffer;
+
+public FilteredDynamicContext(DynamicContext delegate) {
+    super(configuration, null);
+    this.delegate = delegate;
+    this.prefixApplied = false;
+    this.suffixApplied = false;
+    this.sqlBuffer = new StringBuilder();
+}
+
+@Override
+public Map<String, Object> getBindings() {
+    return delegate.getBindings();
+}
+
+@Override
+public void bind(String name, Object value) {
+    delegate.bind(name, value);
+}
+
+@Override
+public int getUniqueNumber() {
+    return delegate.getUniqueNumber();
+}
+
+@Override
+public String getSql() {
+    return delegate.getSql();
+}
+```
+
+- 每个实现的方法，都直接调用 `delegate` 对应的方法。除了 `#append(String sql)` 方法，**以外**。详细解析，见 [「7.2.3.2」](https://svip.iocoder.cn/MyBatis/scripting-1/#) 。
+
+#### 7.2.3.2 append
+
+```
+// TrimSqlNode.java
+
+@Override
+public void appendSql(String sql) {
+    sqlBuffer.append(sql);
+}
+```
+
+- 该方法，将拼接的 `sql` ，暂时存储到 `sqlBuffer` 中。
+- 最终，会通过 `#applyAll()` 方法，将 `sqlBuffer` 处理完后，添加回 `delegate.sqlBuffer` 中。
+
+#### 7.2.3.3 applyAll
+
+```
+// TrimSqlNode.java
+
+public void applyAll() {
+    // <1> trim 掉多余的空格，生成新的 sqlBuffer 对象
+    sqlBuffer = new StringBuilder(sqlBuffer.toString().trim());
+    // <2> 将 sqlBuffer 大写，生成新的 trimmedUppercaseSql 对象
+    String trimmedUppercaseSql = sqlBuffer.toString().toUpperCase(Locale.ENGLISH);
+    // <3> 应用 TrimSqlNode 的 trim 逻辑
+    if (trimmedUppercaseSql.length() > 0) {
+        applyPrefix(sqlBuffer, trimmedUppercaseSql);
+        applySuffix(sqlBuffer, trimmedUppercaseSql);
+    }
+    // <4> 将结果，添加到 delegate 中
+    delegate.appendSql(sqlBuffer.toString());
+}
+```
+
+- `<1>` 处，trim 掉多余的空格，生成新的 `sqlBuffer` 对象。
+
+- `<2>` 处，将 `sqlBuffer` **大写**，生成新的 `trimmedUppercaseSql` 对象。为什么呢？因为，TrimSqlNode 对 `prefixesToOverride` 和 `suffixesToOverride` 属性，都进行了**大写**的处理，需要保持统一。但是，又不能直接修改 `sqlBuffer` ，因为这样就相当于修改了原始的 SQL 。
+
+- `<3>` 处，应用 TrimSqlNode 的 trim 逻辑。
+
+  - `#applyPrefix(StringBuilder sql, String trimmedUppercaseSql)` 方法，代码如下：
+
+    ```
+    // TrimSqlNode.java
+    
+    private void applyPrefix(StringBuilder sql, String trimmedUppercaseSql) {
+        if (!prefixApplied) {
+            prefixApplied = true;
+            // prefixesToOverride 非空，先删除
+            if (prefixesToOverride != null) {
+                for (String toRemove : prefixesToOverride) {
+                    if (trimmedUppercaseSql.startsWith(toRemove)) {
+                        sql.delete(0, toRemove.trim().length());
+                        break;
+                    }
+                }
+            }
+            // prefix 非空，再添加
+            if (prefix != null) {
+                sql.insert(0, " ");
+                sql.insert(0, prefix);
+            }
+        }
+    }
+    ```
+
+    - x
+
+  - `#applySuffix(StringBuilder sql, String trimmedUppercaseSql)` 方法，代码如下：
+
+    ```
+    // TrimSqlNode.java
+    
+    private void applySuffix(StringBuilder sql, String trimmedUppercaseSql) {
+        if (!suffixApplied) {
+            suffixApplied = true;
+            // suffixesToOverride 非空，先删除
+            if (suffixesToOverride != null) {
+                for (String toRemove : suffixesToOverride) {
+                    if (trimmedUppercaseSql.endsWith(toRemove) || trimmedUppercaseSql.endsWith(toRemove.trim())) {
+                        int start = sql.length() - toRemove.trim().length();
+                        int end = sql.length();
+                        sql.delete(start, end);
+                        break;
+                    }
+                }
+            }
+            // suffix 非空，再添加
+            if (suffix != null) {
+                sql.append(" ");
+                sql.append(suffix);
+            }
+        }
+    }
+    ```
+
+    - x
+
+- `<4>` 处，将结果，添加到 `delegate` 中。
+
+## 6.3 WhereSqlNode
+
+`org.apache.ibatis.scripting.xmltags.WhereSqlNode` ，继承 TrimSqlNode 类，`<where />` 标签的 SqlNode 实现类。代码如下：
+
+```
+// WhereSqlNode.java
+
+public class WhereSqlNode extends TrimSqlNode {
+
+    private static List<String> prefixList = Arrays.asList("AND ", "OR ", "AND\n", "OR\n", "AND\r", "OR\r", "AND\t", "OR\t");
+
+    public WhereSqlNode(Configuration configuration, SqlNode contents) {
+        super(configuration, contents, "WHERE", prefixList, null, null);
+    }
+
+}
+```
+
+- 这就是为什么，说 WhereHandler 和 TrimHandler 是一个套路的原因。
+
+## 6.4 SetSqlNode
+
+`org.apache.ibatis.scripting.xmltags.SetSqlNode` ，继承 TrimSqlNode 类，`<set />` 标签的 SqlNode 实现类。代码如下：
+
+```
+// WhereSqlNode.java
+
+public class SetSqlNode extends TrimSqlNode {
+
+    private static List<String> suffixList = Collections.singletonList(",");
+
+    public SetSqlNode(Configuration configuration, SqlNode contents) {
+        super(configuration, contents, "SET", null, null, suffixList);
+    }
+
+}
+```
+
+- 这就是为什么，说 SetHandler 和 TrimHandler 是一个套路的原因。
+
+## 6.5 ForEachSqlNode
+
+`org.apache.ibatis.scripting.xmltags.ForEachSqlNode` ，实现 SqlNode 接口，`<foreach />` 标签的 SqlNode 实现类。
+
+### 6.5.1 构造方法
+
+```
+// ForEachSqlNode.java
+
+private final ExpressionEvaluator evaluator;
+/**
+ * 集合的表达式
+ */
+private final String collectionExpression;
+private final SqlNode contents;
+private final String open;
+private final String close;
+private final String separator;
+/**
+ * 集合项
+ */
+private final String item;
+/**
+ * 索引变量
+ */
+private final String index;
+private final Configuration configuration;
+
+public ForEachSqlNode(Configuration configuration, SqlNode contents, String collectionExpression, String index, String item, String open, String close, String separator) {
+    this.evaluator = new ExpressionEvaluator();
+    this.collectionExpression = collectionExpression;
+    this.contents = contents;
+    this.open = open;
+    this.close = close;
+    this.separator = separator;
+    this.index = index;
+    this.item = item;
+    this.configuration = configuration;
+}
+```
+
+### 6.5.2 apply
+
+```
+// ForEachSqlNode.java
+
+@Override
+public boolean apply(DynamicContext context) {
+    Map<String, Object> bindings = context.getBindings();
+    // <1> 获得遍历的集合的 Iterable 对象，用于遍历。
+    final Iterable<?> iterable = evaluator.evaluateIterable(collectionExpression, bindings);
+    if (!iterable.iterator().hasNext()) {
+        return true;
+    }
+    boolean first = true;
+    // <2> 添加 open 到 SQL 中
+    applyOpen(context);
+    int i = 0;
+    for (Object o : iterable) {
+        // <3> 记录原始的 context 对象
+        DynamicContext oldContext = context;
+        // <4> 生成新的 context
+        if (first || separator == null) {
+            context = new PrefixedContext(context, "");
+        } else {
+            context = new PrefixedContext(context, separator);
+        }
+        // <5> 获得唯一编号
+        int uniqueNumber = context.getUniqueNumber();
+        // Issue #709
+        // <6> 绑定到 context 中
+        if (o instanceof Map.Entry) {
+            @SuppressWarnings("unchecked")
+            Map.Entry<Object, Object> mapEntry = (Map.Entry<Object, Object>) o;
+            applyIndex(context, mapEntry.getKey(), uniqueNumber);
+            applyItem(context, mapEntry.getValue(), uniqueNumber);
+        } else {
+            applyIndex(context, i, uniqueNumber);
+            applyItem(context, o, uniqueNumber);
+        }
+        // <7> 执行 contents 的应用
+        contents.apply(new FilteredDynamicContext(configuration, context, index, item, uniqueNumber));
+        // <8> 判断 prefix 是否已经插入
+        if (first) {
+            first = !((PrefixedContext) context).isPrefixApplied();
+        }
+        // <9> 恢复原始的 context 对象
+        context = oldContext;
+        i++;
+    }
+    // <10> 添加 close 到 SQL 中
+    applyClose(context);
+    // <11> 移除 index 和 item 对应的绑定
+    context.getBindings().remove(item);
+    context.getBindings().remove(index);
+    return true;
+}
+```
+
+- 这个方法的逻辑，相对会比较复杂。胖友最好自己也调试下。
+
+- 我们假设以如下查询为示例：
+
+  ```
+  <select id="getSubjectList" parameterType="List" resultType="List">
+      SELECT id FROM subject
+      WHERE id IN
+        <foreach collection="ids" index="idx" item="item" open="("  close=")" separator=",">
+            #{item}
+        </foreach>
+  </select>
+  ```
+
+- `<1>` 处，调用 `ExpressionEvaluator#evaluateBoolean(String expression, Object parameterObject)` 方法，获得遍历的集合的 Iterable 对象，用于遍历。详细解析，见 [「7.4 ExpressionEvaluator」](https://svip.iocoder.cn/MyBatis/scripting-1/#) 。
+
+- `<2>` 处，调用 `#applyOpen(DynamicContext context)` 方法，添加 `open` 到 SQL 中。代码如下：
+
+  ```
+  // ForEachSqlNode.java
+  
+  private void applyOpen(DynamicContext context) {
+      if (open != null) {
+          context.appendSql(open);
+      }
+  }
+  ```
+
+- 下面开始，我们要遍历 `iterable` 了。
+
+- `<3>` 处，记录原始的 `context` 对象。为什么呢？因为 `<4>` 处，会生成新的 `context` 对象。
+
+- `<4>` 处，生成新的 `context` 对象。类型为 PrefixedContext 对象，只有在非首次，才会传入 `separator` 属性。因为，PrefixedContext 处理的是集合元素之间的分隔符。详细解析，见 [「6.5.3 PrefixedContext」](https://svip.iocoder.cn/MyBatis/scripting-1/#) 。
+
+- `<5>` 处，获得**唯一**编号。
+
+- `<6>` 处，绑定到 `context` 中。调用的两个方法，代码如下：
+
+  ```
+  // ForEachSqlNode.java
+  
+  public static final String ITEM_PREFIX = "__frch_";
+  
+  private void applyIndex(DynamicContext context, Object o, int i) {
+      if (index != null) {
+          context.bind(index, o);
+          context.bind(itemizeItem(index, i), o);
+      }
+  }
+  
+  private void applyItem(DynamicContext context, Object o, int i) {
+      if (item != null) {
+          context.bind(item, o);
+          context.bind(itemizeItem(item, i), o);
+      }
+  }
+  
+  private static String itemizeItem(String item, int i) {
+      return ITEM_PREFIX + item + "_" + i;
+  }
+  ```
+
+  - 上述实例，效果如下图：[![效果](19-mybatis-SQL 初始化（上）之 SqlNode.assets/05.png)](http://static.iocoder.cn/images/MyBatis/2020_02_22/05.png)效果
+
+  - 另外，此处也根据是否为 Map.Entry 类型，分成了两种情况。官方文档说明如下：
+
+    > 你可以将任何可迭代对象（如 List、Set 等）、Map 对象或者数组对象传递给 foreach 作为集合参数。当使用可迭代对象或者数组时，index 是当前迭代的次数，item 的值是本次迭代获取的元素。当使用 Map 对象（或者 Map.Entry 对象的集合）时，index 是键，item 是值。
+
+- `<7>` 处，执行 `contents` 的应用。
+
+  - 例如说，此处 `contents` 就是上述示例的 `" #{item}"` 。
+  - 另外，进一步将 `context` 对象，封装成 FilteredDynamicContext 对象。
+
+- `<8>` 处，判断 `prefix` 是否已经插入。如果是，则 `first` 会被设置为 `false` 。然后，胖友回过头看看 `<4>` 处的逻辑，是不是清晰多了。
+
+- `<9>` 处，恢复原始的 `context` 对象。然后，胖友回过头看看 `<3>` 处的逻辑，是不是清晰多了。
+
+- `<10>` 处，调用 `#applyClose(DynamicContext context)` 方法，添加 `close` 到 SQL 中。代码如下：
+
+  ```
+  // ForEachSqlNode.java
+  
+  private void applyClose(DynamicContext context) {
+      if (close != null) {
+          context.appendSql(close);
+      }
+  }
+  ```
+
+- `<11>` 处，移除 `index` 和 `item` 属性对应的绑定。这两个绑定，是在 `<6>` 处被添加的。
+
+### 6.5.3 PrefixedContext
+
+PrefixedContext ，是 ForEachSqlNode 的内部类，继承 DynamicContext 类，支持添加 `<foreach />` 标签中，多个元素之间的**分隔符**的 DynamicContext 实现类。代码如下：
+
+```
+// ForEachSqlNode.java
+
+private class PrefixedContext extends DynamicContext {
+
+    private final DynamicContext delegate;
+    private final String prefix;
+    /**
+     * 是否已经应用 prefix
+     */
+    private boolean prefixApplied;
+
+    public PrefixedContext(DynamicContext delegate, String prefix) {
+        super(configuration, null);
+        this.delegate = delegate;
+        this.prefix = prefix;
+        this.prefixApplied = false;
+    }
+
+    public boolean isPrefixApplied() {
+        return prefixApplied;
+    }
+
+    @Override
+    public Map<String, Object> getBindings() {
+        return delegate.getBindings();
+    }
+
+    @Override
+    public void bind(String name, Object value) {
+        delegate.bind(name, value);
+    }
+
+    @Override
+    public void appendSql(String sql) {
+        // 如果未应用 prefix ，并且，方法参数 sql 非空
+        // 则添加 prefix 到 delegate 中，并标记 prefixApplied 为 true ，表示已经应用
+        if (!prefixApplied && sql != null && sql.trim().length() > 0) {
+            delegate.appendSql(prefix);
+            prefixApplied = true;
+        }
+
+        // 添加 sql 到 delegate 中
+        delegate.appendSql(sql);
+    }
+
+    @Override
+    public String getSql() {
+        return delegate.getSql();
+    }
+
+    @Override
+    public int getUniqueNumber() {
+        return delegate.getUniqueNumber();
+    }
+}
+```
+
+- `prefix` 属性，虽然属性命名上是 `prefix` ，但是对应到 ForEachSqlNode 的 `separator` 属性。
+- 重心在于 `#appendSql(String sql)` 方法的实现。逻辑还是比较简单的，就是判断之前是否添加过 `prefix` ，没有就进行添加。而判断的依据，就是 `prefixApplied` 标识。
+
+### 6.5.4 FilteredDynamicContext
+
+FilteredDynamicContext ，是 ForEachSqlNode 的内部类，继承 DynamicContext 类，实现子节点访问 `<foreach />` 标签中的变量的**替换**的 DynamicContext 实现类。说起来比较绕，我们直接来看代码。代码如下：
+
+```
+// ForEachSqlNode.java
+
+private static class FilteredDynamicContext extends DynamicContext {
+
+    private final DynamicContext delegate;
+    /**
+     * 唯一标识 {@link DynamicContext#getUniqueNumber()}
+     */
+    private final int index;
+    /**
+     * 索引变量 {@link ForEachSqlNode#index}
+     */
+    private final String itemIndex;
+    /**
+     * 集合项 {@link ForEachSqlNode#item}
+     */
+    private final String item;
+
+    public FilteredDynamicContext(Configuration configuration, DynamicContext delegate, String itemIndex, String item, int i) {
+        super(configuration, null);
+        this.delegate = delegate;
+        this.index = i;
+        this.itemIndex = itemIndex;
+        this.item = item;
+    }
+
+    @Override
+    public Map<String, Object> getBindings() {
+        return delegate.getBindings();
+    }
+
+    @Override
+    public void bind(String name, Object value) {
+        delegate.bind(name, value);
+    }
+
+    @Override
+    public String getSql() {
+        return delegate.getSql();
+    }
+
+    @Override
+    public void appendSql(String sql) {
+        GenericTokenParser parser = new GenericTokenParser("#{", "}", content -> {
+            // 将对 item 的访问，替换成 itemizeItem(item, index) 。
+            String newContent = content.replaceFirst("^\\s*" + item + "(?![^.,:\\s])", itemizeItem(item, index));
+            // 将对 itemIndex 的访问，替换成 itemizeItem(itemIndex, index) 。
+            if (itemIndex != null && newContent.equals(content)) {
+                newContent = content.replaceFirst("^\\s*" + itemIndex + "(?![^.,:\\s])", itemizeItem(itemIndex, index));
+            }
+            // 返回
+            return "#{" + newContent + "}";
+        });
+
+        // 执行 GenericTokenParser 的解析
+        // 添加到 delegate 中
+        delegate.appendSql(parser.parse(sql));
+    }
+
+    @Override
+    public int getUniqueNumber() {
+        return delegate.getUniqueNumber();
+    }
+
+}
+```
+
+- 核心方法是 `#appendSql(String sql)` 方法的重写。胖友可以集合下图示例，理解下具体的代码实现。[![效果](19-mybatis-SQL 初始化（上）之 SqlNode.assets/06.png)](http://static.iocoder.cn/images/MyBatis/2020_02_22/06.png)效果
+- 那可能胖友会有疑惑，如果变成这样，具体的值，在哪里设置呢？答案在 DefaultParameterHandler 类中。所以，继续往下看。哈哈哈哈。
+
+## 6.6 IfSqlNode
+
+`org.apache.ibatis.scripting.xmltags.IfSqlNode` ，实现 SqlNode 接口，`<if />` 标签的 SqlNode 实现类。代码如下：
+
+```
+// IfSqlNode.java
+
+public class IfSqlNode implements SqlNode {
+
+    private final ExpressionEvaluator evaluator;
+    /**
+     * 判断表达式
+     */
+    private final String test;
+    /**
+     * 内嵌的 SqlNode 节点
+     */
+    private final SqlNode contents;
+
+    public IfSqlNode(SqlNode contents, String test) {
+        this.test = test;
+        this.contents = contents;
+        this.evaluator = new ExpressionEvaluator();
+    }
+
+    @Override
+    public boolean apply(DynamicContext context) {
+        // <1> 判断是否符合条件
+        if (evaluator.evaluateBoolean(test, context.getBindings())) {
+            // <2> 符合，执行 contents 的应用
+            contents.apply(context);
+            // 返回成功
+            return true;
+        }
+        // <3> 不符合，返回失败
+        return false;
+    }
+
+}
+```
+
+- `<1>` 处，会调用 `ExpressionEvaluator#evaluateBoolean(String expression, Object parameterObject)` 方法，判断是否符合条件。
+- `<2>` 处，如果**符合**条件，则执行 `contents` 的应用，并返回成功 `true` 。
+- `<3>` 处，如果**不符**条件，则返回失败 `false` 。 😈 此处，终于出现一个返回 `false` 的情况，最终会在 ChooseSqlNode 中，会看到 `true` 和 `false` 的用处。
+
+## 6.7 ChooseSqlNode
+
+`org.apache.ibatis.scripting.xmltags.ChooseSqlNode` ，实现 SqlNode 接口，`<choose />` 标签的 SqlNode 实现类。代码如下：
+
+```
+// ChooseSqlNode.java
+
+public class ChooseSqlNode implements SqlNode {
+
+    /**
+     * <otherwise /> 标签对应的 SqlNode 节点
+     */
+    private final SqlNode defaultSqlNode;
+    /**
+     * <when /> 标签对应的 SqlNode 节点数组
+     */
+    private final List<SqlNode> ifSqlNodes;
+
+    public ChooseSqlNode(List<SqlNode> ifSqlNodes, SqlNode defaultSqlNode) {
+        this.ifSqlNodes = ifSqlNodes;
+        this.defaultSqlNode = defaultSqlNode;
+    }
+
+    @Override
+    public boolean apply(DynamicContext context) {
+        // <1> 先判断  <when /> 标签中，是否有符合条件的节点。
+        // 如果有，则进行应用。并且只因应用一个 SqlNode 对象
+        for (SqlNode sqlNode : ifSqlNodes) {
+            if (sqlNode.apply(context)) {
+                return true;
+            }
+        }
+        // <2> 再判断  <otherwise /> 标签，是否存在
+        // 如果存在，则进行应用
+        if (defaultSqlNode != null) {
+            defaultSqlNode.apply(context);
+            return true;
+        }
+        // <3> 返回都失败
+        return false;
+    }
+
+}
+```
+
+- `<1>` 处，先判断 `<when />` 标签中，是否有符合条件的节点。如果有，则进行应用。并且只因应用**一个** SqlNode 对象。这里，我们就看到了，`SqlNode#apply(context)` 方法，返回 `true` 或 `false` 的用途了。
+- `<2>` 处，再判断 `<otherwise />` 标签，是否存在。如果存在，则进行应用。
+- `<3>` 处，返回都失败。
+
+## 6.8 StaticTextSqlNode
+
+`org.apache.ibatis.scripting.xmltags.StaticTextSqlNode` ，实现 SqlNode 接口，静态文本的 SqlNode 实现类。代码如下：
+
+```
+// StaticTextSqlNode.java
+
+public class StaticTextSqlNode implements SqlNode {
+
+    /**
+     * 静态文本
+     */
+    private final String text;
+
+    public StaticTextSqlNode(String text) {
+        this.text = text;
+    }
+
+    @Override
+    public boolean apply(DynamicContext context) {
+        // 直接拼接到 context 中
+        context.appendSql(text);
+        return true;
+    }
+
+}
+```
+
+## 6.9 TextSqlNode
+
+`org.apache.ibatis.scripting.xmltags.TextSqlNode` ，实现 SqlNode 接口，文本的 SqlNode 实现类。相比 StaticTextSqlNode 的实现来说，TextSqlNode 不确定是否为静态文本，所以提供 `#isDynamic()` 方法，进行判断是否为动态文本。
+
+### 6.9.1 构造方法
+
+```
+// TextSqlNode.java
+
+/**
+ * 文本
+ */
+private final String text;
+/**
+ * 目前该属性只在单元测试中使用，暂时无视
+ */
+private final Pattern injectionFilter;
+
+public TextSqlNode(String text) {
+    this(text, null);
+}
+
+public TextSqlNode(String text, Pattern injectionFilter) {
+    this.text = text;
+    this.injectionFilter = injectionFilter;
+}
+```
+
+### 6.9.2 isDynamic
+
+`#isDynamic()` 方法，判断是否为动态文本。代码如下：
+
+```
+// TextSqlNode.java
+
+public boolean isDynamic() {
+    // <1> 创建 DynamicCheckerTokenParser 对象
+    DynamicCheckerTokenParser checker = new DynamicCheckerTokenParser();
+    // <2> 创建 GenericTokenParser 对象
+    GenericTokenParser parser = createParser(checker);
+    // <3> 执行解析
+    parser.parse(text);
+    // <4> 判断是否为动态文本
+    return checker.isDynamic();
+}
+```
+
+- `<2>` 处，调用 `#createParser(TokenHandler handler)` 方法，创建 GenericTokenParser 对象。代码如下：
+
+  ```
+  // TextSqlNode.java
+   
+  private GenericTokenParser createParser(TokenHandler handler) {
+      return new GenericTokenParser("${", "}", handler);
+  }
+  ```
+
+  - 通过这个方法，我们可以得知，只要存在 `${xxx}` 对，就认为是动态文本。另外，如果胖友遗忘了 GenericTokenParser 类，回到 [《精尽 MyBatis 源码分析 —— 解析器模块》](http://svip.iocoder.cn/MyBatis/parsing-package) 再复习下。
+
+- `<3>` 处，调用 `GenericTokenParser#parse(String text)` 方法，执行解析，寻找 `${xxx}` 对。
+
+- `<1>` 处，创建 DynamicCheckerTokenParser 对象。代码如下：
+
+  ```
+  // TextSqlNode.java
+  
+  private static class DynamicCheckerTokenParser implements TokenHandler {
+  
+      /**
+       * 是否为动态文本
+       */
+      private boolean isDynamic;
+  
+      public DynamicCheckerTokenParser() {
+          // Prevent Synthetic Access
+      }
+  
+      public boolean isDynamic() {
+          return isDynamic;
+      }
+  
+      @Override
+      public String handleToken(String content) {
+          // 当检测到 token ，标记为动态文本
+          this.isDynamic = true;
+          return null;
+      }
+  }
+  ```
+
+  - DynamicCheckerTokenParser 是 TextSqlNode 的内部静态类。
+  - 当 GenericTokenParser 发现 token 时，会调用 `#handleToken(String content)` 方法，标记 `isDynamic` 为 `true` ，即标记为动态文本。
+
+- `<4>` 处，调用 `DynamicCheckerTokenParser#isDynamic()` 方法，判断是否为动态文本。
+
+### 6.9.3 apply
+
+```
+// TextSqlNode.java
+
+@Override
+public boolean apply(DynamicContext context) {
+    // <1> 创建 BindingTokenParser 对象
+    // <2> 创建 GenericTokenParser 对象
+    GenericTokenParser parser = createParser(new BindingTokenParser(context, injectionFilter));
+    // <3> 执行解析
+    // <4> 将解析的结果，添加到 context 中
+    context.appendSql(parser.parse(text));
+    return true;
+}
+```
+
+- `<2>` 处，创建 GenericTokenParser 对象
+
+- `<3>` 处，调用 `GenericTokenParser#parse(String text)` 方法，执行解析。当解析到 `${xxx}` 时，会调用 BindingTokenParser 的 `#handleToken(String content)` 方法，执行相应的逻辑。
+
+- `<4>` 处，将解析的结果，添加到 `context` 中。
+
+- `<1>` 处，创建 BindingTokenParser 对象。代码如下：
+
+  ```
+  // TextSqlNode.java
+  
+  private static class BindingTokenParser implements TokenHandler {
+  
+      private DynamicContext context;
+      private Pattern injectionFilter;
+  
+      public BindingTokenParser(DynamicContext context, Pattern injectionFilter) {
+          this.context = context;
+          this.injectionFilter = injectionFilter;
+      }
+  
+      @Override
+      public String handleToken(String content) {
+          // 初始化 value 属性到 context 中
+          Object parameter = context.getBindings().get("_parameter");
+          if (parameter == null) {
+              context.getBindings().put("value", null);
+          } else if (SimpleTypeRegistry.isSimpleType(parameter.getClass())) {
+              context.getBindings().put("value", parameter);
+          }
+          // 使用 OGNL 表达式，获得对应的值
+          Object value = OgnlCache.getValue(content, context.getBindings());
+          String srtValue = (value == null ? "" : String.valueOf(value)); // issue #274 return "" instead of "null"
+          checkInjection(srtValue);
+          // 返回该值
+          return srtValue;
+      }
+  
+      private void checkInjection(String value) {
+          if (injectionFilter != null && !injectionFilter.matcher(value).matches()) {
+              throw new ScriptingException("Invalid input. Please conform to regex" + injectionFilter.pattern());
+          }
+      }
+  }
+  ```
+
+  - 对于该方法，如下的示例：
+
+    ```
+    SELECT * FROM subject WHERE id = ${id}
+    ```
+
+    - `id = ${id}` 的 `${id}` 部分，将被替换成对应的具体编号。例如说，`id` 为 1 ，则会变成 `SELECT * FROM subject WHERE id = 1` 。
+
+  - 而对于如下的示例：
+
+    ```
+    SELECT * FROM subject WHERE id = #{id}
+    ```
+
+    - `id = #{id}` 的 `#{id}` 部分，则**不会进行替换**。
+
+## 6.10 MixedSqlNode
+
+`org.apache.ibatis.scripting.xmltags.MixedSqlNode` ，实现 SqlNode 接口，混合的 SqlNode 实现类。代码如下：
+
+```
+// MixedSqlNode.java
+
+public class MixedSqlNode implements SqlNode {
+
+    /**
+     * 内嵌的 SqlNode 数组
+     */
+    private final List<SqlNode> contents;
+
+    public MixedSqlNode(List<SqlNode> contents) {
+        this.contents = contents;
+    }
+
+    @Override
+    public boolean apply(DynamicContext context) {
+        // 遍历 SqlNode 数组，逐个应用
+        for (SqlNode sqlNode : contents) {
+            sqlNode.apply(context);
+        }
+        return true;
+    }
+
+}
+```
+
+- MixedSqlNode 内含有 SqlNode 数组。
+- 在 `#apply(DynamicContext context)` 方法中，遍历 SqlNode 数组，逐个应用。
+
+# 7. OGNL 相关
+
+对 OGNL 不熟悉的胖友，可以简单看看如下三篇文章：
+
+- 金剑 [《OGNL 语言介绍与实践》](https://www.ibm.com/developerworks/cn/opensource/os-cn-ognl/index.html)
+- 阿春阿晓 [《OGNL表达式介绍》](https://www.cnblogs.com/renchunxiao/p/3423299.html)
+- 岑宇 [《Ognl表达式基本原理和使用方法》](https://www.cnblogs.com/cenyu/p/6233942.html)
+
+## 7.1 OgnlCache
+
+`org.apache.ibatis.scripting.xmltags.OgnlCache` ，OGNL 缓存类。代码如下：
+
+```
+// OgnlCache.java
+
+public final class OgnlCache {
+
+    /**
+     * OgnlMemberAccess 单例
+     */
+    private static final OgnlMemberAccess MEMBER_ACCESS = new OgnlMemberAccess();
+    /**
+     * OgnlClassResolver 单例
+     */
+    private static final OgnlClassResolver CLASS_RESOLVER = new OgnlClassResolver();
+
+    /**
+     * 表达式的缓存的映射
+     *
+     * KEY：表达式
+     * VALUE：表达式的缓存 @see #parseExpression(String)
+     */
+    private static final Map<String, Object> expressionCache = new ConcurrentHashMap<>();
+
+    private OgnlCache() {
+        // Prevent Instantiation of Static Class
+    }
+
+    public static Object getValue(String expression, Object root) {
+        try {
+            // <1> 创建 OGNL Context 对象
+            Map context = Ognl.createDefaultContext(root, MEMBER_ACCESS, CLASS_RESOLVER, null);
+            // <2> 解析表达式
+            // <3> 获得表达式对应的值
+            return Ognl.getValue(parseExpression(expression), context, root);
+        } catch (OgnlException e) {
+            throw new BuilderException("Error evaluating expression '" + expression + "'. Cause: " + e, e);
+        }
+    }
+
+    private static Object parseExpression(String expression) throws OgnlException {
+        Object node = expressionCache.get(expression);
+        if (node == null) {
+            node = Ognl.parseExpression(expression);
+            expressionCache.put(expression, node);
+        }
+        return node;
+    }
+
+}
+```
+
+- ```
+  <1>
+  ```
+
+   
+
+  处，调用
+
+   
+
+  ```
+  Ognl#createDefaultContext(Object root, MemberAccess memberAccess, ClassResolver classResolver, TypeConverter converter)
+  ```
+
+   
+
+  方法，创建 OGNL Context 对象。其中：
+
+  - `memberAccess` 属性，使用 `MEMBER_ACCESS` 单例。详细解析，见 [「7.2 OgnlMemberAccess」](https://svip.iocoder.cn/MyBatis/scripting-1/#) 。
+  - `classResolver` 属性，使用 `CLASS_RESOLVER` 单例。详细解析，见 [「7.3 OgnlClassResolver」](https://svip.iocoder.cn/MyBatis/scripting-1/#) 。
+
+- `<2>` 处，调用 `#parseExpression(String expression)` 方法，解析表达式。在该方法中，我们会看到，会缓存解析的表达式到 `expressionCache` 中。
+
+- `<3>` 处，调用 `Ognl#getValue((Object tree, Map context, Object root)` 方法，获得表达式对应的值。
+
+## 7.2 OgnlMemberAccess
+
+`org.apache.ibatis.scripting.xmltags.OgnlMemberAccess`，实现 `ognl.MemberAccess` 接口，OGNL 成员访问器实现类。代码如下：
+
+```
+// OgnlMemberAccess.java
+
+class OgnlMemberAccess implements MemberAccess {
+
+    /**
+     * 是否可以修改成员的可访问
+     */
+    private final boolean canControlMemberAccessible;
+
+    OgnlMemberAccess() {
+        this.canControlMemberAccessible = Reflector.canControlMemberAccessible();
+    }
+
+    @Override
+    public Object setup(Map context, Object target, Member member, String propertyName) {
+        Object result = null;
+        // 判断是否可以修改
+        if (isAccessible(context, target, member, propertyName)) {
+            AccessibleObject accessible = (AccessibleObject) member;
+            // 不可访问，则设置为可访问
+            if (!accessible.isAccessible()) {
+                // 标记原来是不可访问的
+                result = Boolean.FALSE;
+                // 修改可访问
+                accessible.setAccessible(true);
+            }
+        }
+        return result;
+    }
+
+    @Override
+    public void restore(Map context, Object target, Member member, String propertyName,
+                        Object state) {
+        if (state != null) {
+            // 修改为原来的可访问
+            ((AccessibleObject) member).setAccessible(((Boolean) state));
+        }
+    }
+
+    @Override
+    public boolean isAccessible(Map context, Object target, Member member, String propertyName) {
+        return canControlMemberAccessible;
+    }
+
+}
+```
+
+- `#setup(...)` 方法，和 `#restore(...)` 方法是**相辅相成**的。
+- `#setup(...)` 方法，当发现需要访问的成员 `member` 不可访问，并且可以修改时，会修改为可访问，并返回之前是不可访问( `result = false` )。
+- `#restore(...)` 方法，如果 `#setup(...)` 方法，修改了可访问级别，那么 `state != null` 成立，就会进行恢复。
+
+## 7.3 OgnlClassResolver
+
+`org.apache.ibatis.scripting.xmltags.OgnlClassResolver`，继承 `ognl.DefaultClassResolver` 类，OGNL 类解析器实现类。代码如下：
+
+```
+// OgnlClassResolver.java
+
+public class OgnlClassResolver extends DefaultClassResolver {
+
+    @Override
+    protected Class toClassForName(String className) throws ClassNotFoundException {
+        return Resources.classForName(className);
+    }
+
+}
+```
+
+- 在方法内部，使用的是 `org.apache.ibatis.io.Resources` 类。
+
+## 7.4 ExpressionEvaluator
+
+`org.apache.ibatis.scripting.xmltags.ExpressionEvaluator` ，OGNL 表达式计算器。代码如下：
+
+```
+// ExpressionEvaluator.java
+
+public class ExpressionEvaluator {
+
+    /**
+     * 判断表达式对应的值，是否为 true
+     *
+     * @param expression 表达式
+     * @param parameterObject 参数对象
+     * @return 是否为 true
+     */
+    public boolean evaluateBoolean(String expression, Object parameterObject) {
+        // 获得表达式对应的值
+        Object value = OgnlCache.getValue(expression, parameterObject);
+        // 如果是 Boolean 类型，直接判断
+        if (value instanceof Boolean) {
+            return (Boolean) value;
+        }
+        // 如果是 Number 类型，则判断不等于 0
+        if (value instanceof Number) {
+            return new BigDecimal(String.valueOf(value)).compareTo(BigDecimal.ZERO) != 0;
+        }
+        // 如果是其它类型，判断非空
+        return value != null;
+    }
+
+    /**
+     * 获得表达式对应的集合
+     *
+     * @param expression 表达式
+     * @param parameterObject 参数对象
+     * @return 迭代器对象
+     */
+    public Iterable<?> evaluateIterable(String expression, Object parameterObject) {
+        // 获得表达式对应的值
+        Object value = OgnlCache.getValue(expression, parameterObject);
+        if (value == null) {
+            throw new BuilderException("The expression '" + expression + "' evaluated to a null value.");
+        }
+        // 如果是 Iterable 类型，直接返回
+        if (value instanceof Iterable) {
+            return (Iterable<?>) value;
+        }
+        // 如果是数组类型，则返回数组
+        if (value.getClass().isArray()) {
+            // the array may be primitive, so Arrays.asList() may throw
+            // a ClassCastException (issue 209).  Do the work manually
+            // Curse primitives! :) (JGB)
+            int size = Array.getLength(value);
+            List<Object> answer = new ArrayList<>();
+            for (int i = 0; i < size; i++) {
+                Object o = Array.get(value, i);
+                answer.add(o);
+            }
+            return answer;
+        }
+        // 如果是 Map 类型，则返回 Map.entrySet 集合
+        if (value instanceof Map) {
+            return ((Map) value).entrySet();
+        }
+        throw new BuilderException("Error evaluating expression '" + expression + "'.  Return value (" + value + ") was not iterable.");
+    }
+
+}
+```
+
+- 两个方法，比较简单，胖友自己看看。
+
+# 666. 彩蛋
+
+本文略长，所以考虑了下，还是拆成上下两篇，避免胖友看的苦闷，艿艿写的苦逼。
+
+参考和推荐如下文章：
+
+- 祖大俊 [《Mybatis3.4.x技术内幕（十七）：Mybatis之动态Sql设计原本（上）》](https://my.oschina.net/zudajun/blog/735553)
+- 祖大俊 [《Mybatis3.4.x技术内幕（十八）：Mybatis之动态Sql设计原本（下）》](https://my.oschina.net/zudajun/blog/735731)
+- 徐郡明 [《MyBatis 技术内幕》](https://item.jd.com/12125531.html) 的 [「3.2 SqlNode&SqlSource」](https://svip.iocoder.cn/MyBatis/scripting-1/#) 小节
\ No newline at end of file
diff --git a/mybatis/20-mybatis-SQL 初始化（下）之 SqlSource.assets/01.png b/mybatis/20-mybatis-SQL 初始化（下）之 SqlSource.assets/01.png
new file mode 100644
index 0000000..7b67271
Binary files /dev/null and b/mybatis/20-mybatis-SQL 初始化（下）之 SqlSource.assets/01.png differ
diff --git a/mybatis/20-mybatis-SQL 初始化（下）之 SqlSource.assets/02.png b/mybatis/20-mybatis-SQL 初始化（下）之 SqlSource.assets/02.png
new file mode 100644
index 0000000..6dda3cc
Binary files /dev/null and b/mybatis/20-mybatis-SQL 初始化（下）之 SqlSource.assets/02.png differ
diff --git a/mybatis/20-mybatis-SQL 初始化（下）之 SqlSource.assets/03.png b/mybatis/20-mybatis-SQL 初始化（下）之 SqlSource.assets/03.png
new file mode 100644
index 0000000..9aeae31
Binary files /dev/null and b/mybatis/20-mybatis-SQL 初始化（下）之 SqlSource.assets/03.png differ
diff --git a/mybatis/20-mybatis-SQL 初始化（下）之 SqlSource.assets/07.png b/mybatis/20-mybatis-SQL 初始化（下）之 SqlSource.assets/07.png
new file mode 100644
index 0000000..bb3a186
Binary files /dev/null and b/mybatis/20-mybatis-SQL 初始化（下）之 SqlSource.assets/07.png differ
diff --git a/mybatis/20-mybatis-SQL 初始化（下）之 SqlSource.md b/mybatis/20-mybatis-SQL 初始化（下）之 SqlSource.md
new file mode 100644
index 0000000..3feee29
--- /dev/null
+++ b/mybatis/20-mybatis-SQL 初始化（下）之 SqlSource.md	
@@ -0,0 +1,951 @@
+# 精尽 MyBatis 源码分析 —— SQL 初始化（下）之 SqlSource
+
+# 1. 概述
+
+本文接 [《精尽 MyBatis 源码分析 —— SQL 初始化（上）之 SqlNode》](http://svip.iocoder.cn/MyBatis/scripting-1) 一文，来分享 SQL 初始化的下半部分，SqlSource 相关的内容。
+
+# 2. SqlSource
+
+`org.apache.ibatis.mapping.SqlSource` ，SQL 来源接口。它代表从 Mapper XML 或方法注解上，读取的一条 SQL 内容。代码如下：
+
+```
+// SqlSource.java
+
+/**
+ * Represents the content of a mapped statement read from an XML file or an annotation. 
+ * It creates the SQL that will be passed to the database out of the input parameter received from the user.
+ */
+public interface SqlSource {
+
+    /**
+     * 根据传入的参数对象，返回 BoundSql 对象
+     *
+     * @param parameterObject 参数对象
+     * @return BoundSql 对象
+     */
+    BoundSql getBoundSql(Object parameterObject);
+
+}
+```
+
+SqlSource 有多个实现类，如下图所示：[![类图](20-mybatis-SQL 初始化（下）之 SqlSource.assets/07.png)](http://static.iocoder.cn/images/MyBatis/2020_02_22/07.png)类图
+
+# 3. SqlSourceBuilder
+
+`org.apache.ibatis.builder.SqlSourceBuilder` ，继承 BaseBuilder 抽象类，SqlSource 构建器，负责将 SQL 语句中的 `#{}` 替换成相应的 `?` 占位符，并获取该 `?` 占位符对应的 `org.apache.ibatis.mapping.ParameterMapping` 对象。
+
+## 3.1 构造方法
+
+```
+// SqlSourceBuilder.java
+
+private static final String parameterProperties = "javaType,jdbcType,mode,numericScale,resultMap,typeHandler,jdbcTypeName";
+
+public SqlSourceBuilder(Configuration configuration) {
+    super(configuration);
+}
+```
+
+- 为什么 `parameterProperties` 属性是这个值，答案在 [《MyBatis 文档 —— Mapper XML 文件 —— 参数（Parameters）》](http://www.mybatis.org/mybatis-3/zh/sqlmap-xml.html#Parameters)
+
+## 3.2 parse
+
+```
+// SqlSourceBuilder.java
+
+/**
+ * 执行解析原始 SQL ，成为 SqlSource 对象
+ *
+ * @param originalSql 原始 SQL
+ * @param parameterType 参数类型
+ * @param additionalParameters 附加参数集合。可能是空集合，也可能是 {@link org.apache.ibatis.scripting.xmltags.DynamicContext#bindings} 集合
+ * @return SqlSource 对象
+ */
+public SqlSource parse(String originalSql, Class<?> parameterType, Map<String, Object> additionalParameters) {
+    // <1> 创建 ParameterMappingTokenHandler 对象
+    ParameterMappingTokenHandler handler = new ParameterMappingTokenHandler(configuration, parameterType, additionalParameters);
+    // <2> 创建 GenericTokenParser 对象
+    GenericTokenParser parser = new GenericTokenParser("#{", "}", handler);
+    // <3> 执行解析
+    String sql = parser.parse(originalSql);
+    // <4> 创建 StaticSqlSource 对象
+    return new StaticSqlSource(configuration, sql, handler.getParameterMappings());
+}
+```
+
+- `<2>` 处，创建 GenericTokenParser 对象。注意，传入的参数是 `#{` 和 `}` 对。
+- `<1>` 处，创建 ParameterMappingTokenHandler 对象。
+- `<3>` 处，调用 `GenericTokenParser#parse(String originalSql)` 方法，执行解析。如果匹配到 `#{` + `}` 对后，会调用 ParameterMappingTokenHandler 对应的 `#handleToken(String content)` 方法。详细解析，见 [「3.3 ParameterMappingTokenHandler」](https://svip.iocoder.cn/MyBatis/scripting-2/#) 。
+- `<4>` 处，创建 StaticSqlSource 对象。关于 StaticSqlSource 类，详细解析，见 [「4.1 StaticSqlSource」](https://svip.iocoder.cn/MyBatis/scripting-2/#) 。
+
+## 3.3 ParameterMappingTokenHandler
+
+ParameterMappingTokenHandler ，实现 TokenHandler 接口，继承 BaseBuilder 抽象类，负责将匹配到的 `#{` 和 `}` 对，替换成相应的 `?` 占位符，并获取该 `?` 占位符对应的 `org.apache.ibatis.mapping.ParameterMapping` 对象。
+
+### 3.3.1 构造方法
+
+> ParameterMappingTokenHandler 是 SqlSourceBuilder 的内部私有静态类。
+
+```
+// SqlSourceBuilder.java
+
+/**
+ * ParameterMapping 数组
+ */
+private List<ParameterMapping> parameterMappings = new ArrayList<>();
+/**
+ * 参数类型
+ */
+private Class<?> parameterType;
+/**
+ * additionalParameters 参数的对应的 MetaObject 对象
+ */
+private MetaObject metaParameters;
+
+public ParameterMappingTokenHandler(Configuration configuration, Class<?> parameterType, Map<String, Object> additionalParameters) {
+    super(configuration);
+    this.parameterType = parameterType;
+    // 创建 additionalParameters 参数的对应的 MetaObject 对象
+    this.metaParameters = configuration.newMetaObject(additionalParameters);
+}
+```
+
+### 3.3.2 handleToken
+
+```
+// SqlSourceBuilder.java
+
+@Override
+public String handleToken(String content) {
+    // <1> 构建 ParameterMapping 对象，并添加到 parameterMappings 中
+    parameterMappings.add(buildParameterMapping(content));
+    // <2> 返回 ? 占位符
+    return "?";
+}
+```
+
+- `<1>` 处，调用 `#buildParameterMapping(String content)` 方法，构建 ParameterMapping 对象，并添加到 `parameterMappings` 中。详细解析，见 [「3.3.3 buildParameterMapping」](https://svip.iocoder.cn/MyBatis/scripting-2/#) 。
+- `<2>` 处，返回 `?` 占位符。
+- 如上两个步骤，就是 ParameterMappingTokenHandler 的核心。
+
+### 3.3.3 buildParameterMapping
+
+`#buildParameterMapping(String content)` 方法，构建 ParameterMapping 对象。代码如下：
+
+```
+// SqlSourceBuilder.java
+
+private ParameterMapping buildParameterMapping(String content) {
+    // <1> 解析成 Map 集合
+    Map<String, String> propertiesMap = parseParameterMapping(content);
+    // <2> 获得属性的名字和类型
+    String property = propertiesMap.get("property"); // 名字
+    Class<?> propertyType; // 类型
+    if (metaParameters.hasGetter(property)) { // issue #448 get type from additional params
+        propertyType = metaParameters.getGetterType(property);
+    } else if (typeHandlerRegistry.hasTypeHandler(parameterType)) {
+        propertyType = parameterType;
+    } else if (JdbcType.CURSOR.name().equals(propertiesMap.get("jdbcType"))) {
+        propertyType = java.sql.ResultSet.class;
+    } else if (property == null || Map.class.isAssignableFrom(parameterType)) {
+        propertyType = Object.class;
+    } else {
+        MetaClass metaClass = MetaClass.forClass(parameterType, configuration.getReflectorFactory());
+        if (metaClass.hasGetter(property)) {
+            propertyType = metaClass.getGetterType(property);
+        } else {
+            propertyType = Object.class;
+        }
+    }
+    // <3> 创建 ParameterMapping.Builder 对象
+    ParameterMapping.Builder builder = new ParameterMapping.Builder(configuration, property, propertyType);
+    // <3.1> 初始化 ParameterMapping.Builder 对象的属性
+    Class<?> javaType = propertyType;
+    String typeHandlerAlias = null;
+    for (Map.Entry<String, String> entry : propertiesMap.entrySet()) {
+        String name = entry.getKey();
+        String value = entry.getValue();
+        if ("javaType".equals(name)) {
+            javaType = resolveClass(value);
+            builder.javaType(javaType);
+        } else if ("jdbcType".equals(name)) {
+            builder.jdbcType(resolveJdbcType(value));
+        } else if ("mode".equals(name)) {
+            builder.mode(resolveParameterMode(value));
+        } else if ("numericScale".equals(name)) {
+            builder.numericScale(Integer.valueOf(value));
+        } else if ("resultMap".equals(name)) {
+            builder.resultMapId(value);
+        } else if ("typeHandler".equals(name)) {
+            typeHandlerAlias = value;
+        } else if ("jdbcTypeName".equals(name)) {
+            builder.jdbcTypeName(value);
+        } else if ("property".equals(name)) {
+            // Do Nothing
+        } else if ("expression".equals(name)) {
+            throw new BuilderException("Expression based parameters are not supported yet");
+        } else {
+            throw new BuilderException("An invalid property '" + name + "' was found in mapping #{" + content + "}.  Valid properties are " + parameterProperties);
+        }
+    }
+    // <3.2> 如果 typeHandlerAlias 非空，则获得对应的 TypeHandler 对象，并设置到 ParameterMapping.Builder 对象中
+    if (typeHandlerAlias != null) {
+        builder.typeHandler(resolveTypeHandler(javaType, typeHandlerAlias));
+    }
+    // <3.3> 创建 ParameterMapping 对象
+    return builder.build();
+}
+```
+
+- `<1>` 处，调用 `#parseParameterMapping(String content)` 方法，解析成 Map 集合。代码如下：
+
+  ```
+  // SqlSourceBuilder.java
+  
+  private Map<String, String> parseParameterMapping(String content) {
+      try {
+          return new ParameterExpression(content);
+      } catch (BuilderException ex) {
+          throw ex;
+      } catch (Exception ex) {
+          throw new BuilderException("Parsing error was found in mapping #{" + content + "}.  Check syntax #{property|(expression), var1=value1, var2=value2, ...} ", ex);
+      }
+  }
+  ```
+
+  - [`org.apache.ibatis.builder.ParameterExpression`](https://github.com/YunaiV/mybatis-3/blob/master/src/main/java/org/apache/ibatis/builder/ParameterExpression.java) 类，继承 HashMap 类，负责参数表达式。感兴趣的胖友，可以自己看看。😈 艿艿暂时没细看。
+  - 假设 `content = "#{age,javaType=int,jdbcType=NUMERIC,typeHandler=MyTypeHandler}"` 的结果如下图：[![示例](20-mybatis-SQL 初始化（下）之 SqlSource.assets/01.png)](http://static.iocoder.cn/images/MyBatis/2020_02_25/01.png)示例
+
+- `<2>` 处，获得**属性**的名字和类型。
+
+- ```
+  <3>
+  ```
+
+   
+
+  处，创建 ParameterMapping.Builder 对象。
+
+  - `<3.1>` 处，初始化 ParameterMapping.Builder 对象的属性。
+  - `<3.2>` 处，如果 `typeHandlerAlias` 非空，则获得对应的 TypeHandler 对象，并设置到 ParameterMapping.Builder 对象中。
+  - `<3.3>` 处，创建 ParameterMapping 对象。
+  - 关于 ParameterMapping 类，胖友可以跳到 [「5.1 ParameterMapping」](https://svip.iocoder.cn/MyBatis/scripting-2/#) 中看看。
+
+# 4. SqlSource 的实现类
+
+## 4.1 StaticSqlSource
+
+`org.apache.ibatis.builder.StaticSqlSource` ，实现 SqlSource 接口，静态的 SqlSource 实现类。代码如下：
+
+```
+// StaticSqlSource.java
+
+public class StaticSqlSource implements SqlSource {
+
+    /**
+     * 静态的 SQL
+     */
+    private final String sql;
+    /**
+     * ParameterMapping 集合
+     */
+    private final List<ParameterMapping> parameterMappings;
+    private final Configuration configuration;
+
+    public StaticSqlSource(Configuration configuration, String sql) {
+        this(configuration, sql, null);
+    }
+
+    public StaticSqlSource(Configuration configuration, String sql, List<ParameterMapping> parameterMappings) {
+        this.sql = sql;
+        this.parameterMappings = parameterMappings;
+        this.configuration = configuration;
+    }
+
+    @Override
+    public BoundSql getBoundSql(Object parameterObject) {
+        // 创建 BoundSql 对象
+        return new BoundSql(configuration, sql, parameterMappings, parameterObject);
+    }
+
+}
+```
+
+- StaticSqlSource 的静态，是相对于 DynamicSqlSource 和 RawSqlSource 来说呢。实际上，`StaticSqlSource.sql` 属性，上面还是可能包括 `?` 占位符。
+- `#getBoundSql((Object parameterObject)` 方法，创建 BoundSql 对象。通过 `parameterMappings` 和 `parameterObject` 属性，可以设置 `sql` 上的每个占位符的值。例如：[![示例](20-mybatis-SQL 初始化（下）之 SqlSource.assets/02.png)](http://static.iocoder.cn/images/MyBatis/2020_02_25/02.png)示例
+- 另外，我们在回过头看看 SqlSourceBuilder 类，它创建的也是 StaticSqlSource 对象。
+
+------
+
+下面，我们来看看下图的两段代码，胖友看看是否发现了什么规律：[![示例](20-mybatis-SQL 初始化（下）之 SqlSource.assets/03.png)](http://static.iocoder.cn/images/MyBatis/2020_02_25/03.png)示例
+
+- 如果**是**动态 SQL 的情况下，则创建 DynamicSqlSource 对象。
+- 如果**非**动态 SQL 的情况下，则创建 RawSqlSource 对象。
+
+下面，我们在「4.2」和「4.3」中，看看两者的区别。
+
+## 4.2 DynamicSqlSource
+
+`org.apache.ibatis.scripting.xmltags.DynamicSqlSource` ，实现 SqlSource 接口，动态的 SqlSource 实现类。代码如下：
+
+```
+// DynamicSqlSource.java
+
+public class DynamicSqlSource implements SqlSource {
+
+    private final Configuration configuration;
+    /**
+     * 根 SqlNode 对象
+     */
+    private final SqlNode rootSqlNode;
+
+    public DynamicSqlSource(Configuration configuration, SqlNode rootSqlNode) {
+        this.configuration = configuration;
+        this.rootSqlNode = rootSqlNode;
+    }
+
+    @Override
+    public BoundSql getBoundSql(Object parameterObject) {
+        // <1> 应用 rootSqlNode
+        DynamicContext context = new DynamicContext(configuration, parameterObject);
+        rootSqlNode.apply(context);
+        // <2> 创建 SqlSourceBuilder 对象
+        SqlSourceBuilder sqlSourceParser = new SqlSourceBuilder(configuration);
+        // <2> 解析出 SqlSource 对象
+        Class<?> parameterType = parameterObject == null ? Object.class : parameterObject.getClass();
+        SqlSource sqlSource = sqlSourceParser.parse(context.getSql(), parameterType, context.getBindings());
+        // <3> 获得 BoundSql 对象
+        BoundSql boundSql = sqlSource.getBoundSql(parameterObject);
+        // <4> 添加附加参数到 BoundSql 对象中
+        for (Map.Entry<String, Object> entry : context.getBindings().entrySet()) {
+            boundSql.setAdditionalParameter(entry.getKey(), entry.getValue());
+        }
+        // <5> 返回 BoundSql 对象
+        return boundSql;
+    }
+
+}
+```
+
+- 适用于使用了 OGNL 表达式，或者使用了 `${}` 表达式的 SQL ，所以它是**动态**的，需要在每次执行 `#getBoundSql(Object parameterObject)` 方法，根据参数，生成对应的 SQL 。
+
+- `<1>` 处，创建 DynamicContext 对象，并执行 `DynamicContext#apply(DynamicContext context)` 方法，应用 `rootSqlNode` ，相当于生成**动态** SQL 。
+
+- ```
+  <2>
+  ```
+
+   
+
+  处，创建 SqlSourceBuilder 对象，并执行
+
+   
+
+  ```
+  SqlSourceBuilder#parse(String originalSql, Class<?> parameterType, Map<String, Object> additionalParameters)
+  ```
+
+   
+
+  方法，解析出 SqlSource 对象。
+
+  注意
+
+  ：
+
+  - 返回的 SqlSource 对象，类型是 **StaticSqlSource** 类。
+  - 这个过程，会将 `#{}` 对，转换成对应的 `?` 占位符，并获取该占位符对应的 ParameterMapping 对象。
+
+- `<3>` 处，调用 `StaticSqlSource#getBoundSql(Object parameterObject)` 方法，获得 BoundSql 对象。
+
+- `<4>` 处，从 `context.bindings` 中，添加附加参数到 BoundSql 对象中。为什么要这么做？胖友回看下 [《精尽 MyBatis 源码分析 —— SQL 初始化（上）之 SqlNode》](http://svip.iocoder.cn/MyBatis/scripting-1) 的 [「6.7 ChooseSqlNode」](https://svip.iocoder.cn/MyBatis/scripting-2/#) 就明白了。
+
+- `<5>` 处，返回 BoundSql 对象。
+
+## 4.3 RawSqlSource
+
+`org.apache.ibatis.scripting.xmltags.RawSqlSource` ，实现 SqlSource 接口，**原始**的 SqlSource 实现类。代码如下：
+
+```
+// RawSqlSource.java
+
+public class RawSqlSource implements SqlSource {
+
+    /**
+     * SqlSource 对象
+     */
+    private final SqlSource sqlSource;
+
+    public RawSqlSource(Configuration configuration, SqlNode rootSqlNode, Class<?> parameterType) {
+        // <1> 获得 Sql
+        this(configuration, getSql(configuration, rootSqlNode), parameterType);
+    }
+
+    public RawSqlSource(Configuration configuration, String sql, Class<?> parameterType) {
+        // <2> 创建 SqlSourceBuilder 对象
+        SqlSourceBuilder sqlSourceParser = new SqlSourceBuilder(configuration);
+        Class<?> clazz = parameterType == null ? Object.class : parameterType;
+        // <2> 获得 SqlSource 对象
+        sqlSource = sqlSourceParser.parse(sql, clazz, new HashMap<>());
+    }
+
+    private static String getSql(Configuration configuration, SqlNode rootSqlNode) {
+        // 创建 DynamicContext 对象
+        DynamicContext context = new DynamicContext(configuration, null);
+        // 解析出 SqlSource 对象
+        rootSqlNode.apply(context);
+        // 获得 sql
+        return context.getSql();
+    }
+
+    @Override
+    public BoundSql getBoundSql(Object parameterObject) {
+        // 获得 BoundSql 对象
+        return sqlSource.getBoundSql(parameterObject);
+    }
+
+}
+```
+
+- 适用于仅使用 `#{}` 表达式，或者不使用任何表达式的情况，所以它是**静态**的，仅需要在构造方法中，直接生成对应的 SQL 。
+
+- 在构造方法中：
+
+  - `<1>` 处，调用 `#getSql(Configuration configuration, SqlNode rootSqlNode)` 方法，获得 SQL 。
+  - `<2>` 处，创建 SqlSourceBuilder 对象，并执行 `SqlSourceBuilder#parse(String originalSql, Class<?> parameterType, Map<String, Object> additionalParameters)` 方法，解析出 SqlSource 对象。
+  - 对应到 DynamicSqlSource ，就是 `<1>` + `<2>` 了。
+
+- 在
+
+   
+
+  ```
+  #getBoundSql(Object parameterObject)
+  ```
+
+   
+
+  方法中：
+
+  - `<3>` 处，调用 `StaticSqlSource#getBoundSql(Object parameterObject)` 方法，获得 BoundSql 对象。
+  - 对应到 DynamicSqlSource ，就是 `<1>` + `<2>` 了。
+
+这样，RawSqlSource 和 DynamicSqlSource 的区别，是不是就清晰了。
+
+## 4.4 ProviderSqlSource
+
+`org.apache.ibatis.builder.annotation.ProviderSqlSource` ，实现 SqlSource 接口，基于方法上的 `@ProviderXXX` 注解的 SqlSource 实现类。
+
+### 4.4.1 构造方法
+
+```
+// ProviderSqlSource.java
+
+private final Configuration configuration;
+private final SqlSourceBuilder sqlSourceParser;
+/**
+ * `@ProviderXXX` 注解的对应的类
+ */
+private final Class<?> providerType;
+/**
+ * `@ProviderXXX` 注解的对应的方法
+ */
+private Method providerMethod;
+/**
+ * `@ProviderXXX` 注解的对应的方法的参数名数组
+ */
+private String[] providerMethodArgumentNames;
+/**
+ * `@ProviderXXX` 注解的对应的方法的参数类型数组
+ */
+private Class<?>[] providerMethodParameterTypes;
+/**
+ * 若 {@link #providerMethodParameterTypes} 参数有 ProviderContext 类型的，创建 ProviderContext 对象
+ */
+private ProviderContext providerContext;
+/**
+ * {@link #providerMethodParameterTypes} 参数中，ProviderContext 类型的参数，在数组中的位置
+ */
+private Integer providerContextIndex;
+
+/**
+ * @deprecated Please use the {@link #ProviderSqlSource(Configuration, Object, Class, Method)} instead of this.
+ */
+@Deprecated
+public ProviderSqlSource(Configuration configuration, Object provider) {
+    this(configuration, provider, null, null);
+}
+
+/**
+ * @since 3.4.5
+ */
+public ProviderSqlSource(Configuration configuration, Object provider, Class<?> mapperType, Method mapperMethod) {
+    String providerMethodName;
+    try {
+        this.configuration = configuration;
+        // 创建 SqlSourceBuilder 对象
+        this.sqlSourceParser = new SqlSourceBuilder(configuration);
+        // 获得 @ProviderXXX 注解的对应的类
+        this.providerType = (Class<?>) provider.getClass().getMethod("type").invoke(provider);
+        // 获得 @ProviderXXX 注解的对应的方法相关的信息
+        providerMethodName = (String) provider.getClass().getMethod("method").invoke(provider);
+        for (Method m : this.providerType.getMethods()) {
+            if (providerMethodName.equals(m.getName()) && CharSequence.class.isAssignableFrom(m.getReturnType())) {
+                if (providerMethod != null) {
+                    throw new BuilderException("Error creating SqlSource for SqlProvider. Method '"
+                            + providerMethodName + "' is found multiple in SqlProvider '" + this.providerType.getName()
+                            + "'. Sql provider method can not overload.");
+                }
+                this.providerMethod = m;
+                this.providerMethodArgumentNames = new ParamNameResolver(configuration, m).getNames();
+                this.providerMethodParameterTypes = m.getParameterTypes();
+            }
+        }
+    } catch (BuilderException e) {
+        throw e;
+    } catch (Exception e) {
+        throw new BuilderException("Error creating SqlSource for SqlProvider.  Cause: " + e, e);
+    }
+    if (this.providerMethod == null) {
+        throw new BuilderException("Error creating SqlSource for SqlProvider. Method '"
+                + providerMethodName + "' not found in SqlProvider '" + this.providerType.getName() + "'.");
+    }
+    // 初始化 providerContext 和 providerContextIndex 属性
+    for (int i = 0; i < this.providerMethodParameterTypes.length; i++) {
+        Class<?> parameterType = this.providerMethodParameterTypes[i];
+        if (parameterType == ProviderContext.class) {
+            if (this.providerContext != null) {
+                throw new BuilderException("Error creating SqlSource for SqlProvider. ProviderContext found multiple in SqlProvider method ("
+                        + this.providerType.getName() + "." + providerMethod.getName()
+                        + "). ProviderContext can not define multiple in SqlProvider method argument.");
+            }
+            this.providerContext = new ProviderContext(mapperType, mapperMethod);
+            this.providerContextIndex = i;
+        }
+    }
+}
+```
+
+- 参数比较多，但是灰常简单，胖友耐心的瞅瞅。
+
+### 4.4.2 getBoundSql
+
+```
+// ProviderSqlSource.java
+
+@Override
+public BoundSql getBoundSql(Object parameterObject) {
+    // <1> 创建 SqlSource 对象
+    SqlSource sqlSource = createSqlSource(parameterObject);
+    // <2> 获得 BoundSql 对象
+    return sqlSource.getBoundSql(parameterObject);
+}
+```
+
+- `<1>` 处，调用 `#createSqlSource(Object parameterObject)` 方法，创建 SqlSource 对象。因为它是通过 `@ProviderXXX` 注解的指定类的指定方法，动态生成 SQL 。所以，从思路上，和 DynamicSqlSource 是有点接近的。详细解析，见 [「4.4.3 createSqlSource」](https://svip.iocoder.cn/MyBatis/scripting-2/#) 。
+- `<2>` 处，调用 `SqlSource#getBoundSql(Object parameterObject)` 方法，获得 BoundSql 对象。
+
+### 4.4.3 createSqlSource
+
+`#createSqlSource(Object parameterObject)` 方法，创建 SqlSource 对象。代码如下：
+
+```
+// ProviderSqlSource.java
+
+private SqlSource createSqlSource(Object parameterObject) {
+    try {
+        // <1> 获得 SQL
+        int bindParameterCount = providerMethodParameterTypes.length - (providerContext == null ? 0 : 1);
+        String sql;
+        if (providerMethodParameterTypes.length == 0) {
+            sql = invokeProviderMethod();
+        } else if (bindParameterCount == 0) {
+            sql = invokeProviderMethod(providerContext);
+        } else if (bindParameterCount == 1 &&
+                (parameterObject == null || providerMethodParameterTypes[(providerContextIndex == null || providerContextIndex == 1) ? 0 : 1].isAssignableFrom(parameterObject.getClass()))) {
+            sql = invokeProviderMethod(extractProviderMethodArguments(parameterObject)); // <1.1>
+        } else if (parameterObject instanceof Map) {
+            @SuppressWarnings("unchecked")
+            Map<String, Object> params = (Map<String, Object>) parameterObject;
+            sql = invokeProviderMethod(extractProviderMethodArguments(params, providerMethodArgumentNames)); <1.2>
+        } else {
+            throw new BuilderException("Error invoking SqlProvider method ("
+                    + providerType.getName() + "." + providerMethod.getName()
+                    + "). Cannot invoke a method that holds "
+                    + (bindParameterCount == 1 ? "named argument(@Param)" : "multiple arguments")
+                    + " using a specifying parameterObject. In this case, please specify a 'java.util.Map' object.");
+        }
+        // <2> 获得参数
+        Class<?> parameterType = parameterObject == null ? Object.class : parameterObject.getClass();
+        // <3> 替换掉 SQL 上的属性
+        // <4> 解析出 SqlSource 对象
+        return sqlSourceParser.parse(replacePlaceholder(sql), parameterType, new HashMap<>());
+    } catch (BuilderException e) {
+        throw e;
+    } catch (Exception e) {
+        throw new BuilderException("Error invoking SqlProvider method ("
+                + providerType.getName() + "." + providerMethod.getName()
+                + ").  Cause: " + e, e);
+    }
+}
+```
+
+- `<1>` 处，获得 SQL 。
+
+  - `<1.1>` 处，调用 `#extractProviderMethodArguments(Object parameterObject)` 方法，获得方法参数。代码如下：
+
+    ```
+    // ProviderSqlSource.java
+    
+    private Object[] extractProviderMethodArguments(Object parameterObject) {
+        if (providerContext != null) {
+            Object[] args = new Object[2];
+            args[providerContextIndex == 0 ? 1 : 0] = parameterObject;
+            args[providerContextIndex] = providerContext;
+            return args;
+        } else {
+            return new Object[]{parameterObject};
+        }
+    }
+    ```
+
+```
+    * 逻辑比较简单，胖友思考下。 * `<1.2>` 处，调用 `#extractProviderMethodArguments(Map<String, Object> params, String[] argumentNames)` 方法，获得方法参数。代码如下：     // ProviderSqlSource.javaprivate Object[] extractProviderMethodArguments(Map<String, Object> params, String[] argumentNames) {    Object[] args = new Object[argumentNames.length];    for (int i = 0; i < args.length; i++) {        if (providerContextIndex != null && providerContextIndex == i) {            args[i] = providerContext;        } else {            args[i] = params.get(argumentNames[i]);        }    }    return args;}     * 逻辑比较简单，胖友思考下。  * 上面两个方法，无法理解的胖友，可以看看 `org.apache.ibatis.submitted.sqlprovider.Mapper` 和 `org.apache.ibatis.submitted.sqlprovider.OurSqlBuilder` 类。 * 调用 `#invokeProviderMethod(Object... args)` 方法，执行方法，生成 SQL 。代码如下：     // ProviderSqlSource.javaprivate String invokeProviderMethod(Object... args) throws Exception {    Object targetObject = null;    // 获得对象    if (!Modifier.isStatic(providerMethod.getModifiers())) {        targetObject = providerType.newInstance();    }    // 反射调用方法    CharSequence sql = (CharSequence) providerMethod.invoke(targetObject, args);    return sql != null ? sql.toString() : null;}     * 反射调用方法。 
+```
+
+- `<2>` 处，获得参数类型。
+
+- `<3>` 处，调用 `#replacePlaceholder(String sql)` 方法，替换掉 SQL 上的属性。代码如下：
+
+  ```
+  // ProviderSqlSource.java
+  
+  private String replacePlaceholder(String sql) {
+      return PropertyParser.parse(sql, configuration.getVariables());
+  }
+  ```
+
+- `<4>` 处，调用 `SqlSourceBuilder#parse(String originalSql, Class<?> parameterType, Map<String, Object> additionalParameters)` 方法，解析出 SqlSource 对象。
+- 代码比较长，胖友回过头自己再细看。😈 不过一般来说，MyBatis 注解使用较少，所以胖友也可以不用细看。
+
+### 4.4.4 ProviderContext
+
+`org.apache.ibatis.builder.annotation.ProviderContext` ，ProviderSqlSource 的上下文。代码如下：
+
+```
+// ProviderContext.java
+
+public final class ProviderContext {
+
+    /**
+     * Mapper 接口
+     */
+    private final Class<?> mapperType;
+    /**
+     * Mapper 的方法
+     */
+    private final Method mapperMethod;
+
+    /**
+     * Constructor.
+     *
+     * @param mapperType A mapper interface type that specified provider
+     * @param mapperMethod A mapper method that specified provider
+     */
+    ProviderContext(Class<?> mapperType, Method mapperMethod) {
+        this.mapperType = mapperType;
+        this.mapperMethod = mapperMethod;
+    }
+
+    public Class<?> getMapperType() {
+        return mapperType;
+    }
+    
+    public Method getMapperMethod() {
+        return mapperMethod;
+    }
+
+}
+```
+
+# 5. BoundSql
+
+`org.apache.ibatis.mapping.BoundSql` ，一次可执行的 SQL 封装。代码如下：
+
+```
+// BoundSql.java
+
+public class BoundSql {
+
+    /**
+     * SQL 语句
+     */
+    private final String sql;
+    /**
+     * ParameterMapping 数组
+     */
+    private final List<ParameterMapping> parameterMappings;
+    /**
+     * 参数对象
+     */
+    private final Object parameterObject;
+    /**
+     * 附加的参数集合
+     */
+    private final Map<String, Object> additionalParameters;
+    /**
+     * {@link #additionalParameters} 的 MetaObject 对象
+     */
+    private final MetaObject metaParameters;
+
+    public BoundSql(Configuration configuration, String sql, List<ParameterMapping> parameterMappings, Object parameterObject) {
+        this.sql = sql;
+        this.parameterMappings = parameterMappings;
+        this.parameterObject = parameterObject;
+        this.additionalParameters = new HashMap<>();
+        this.metaParameters = configuration.newMetaObject(additionalParameters);
+    }
+
+    public String getSql() {
+        return sql;
+    }
+
+    public List<ParameterMapping> getParameterMappings() {
+        return parameterMappings;
+    }
+
+    public Object getParameterObject() {
+        return parameterObject;
+    }
+
+    public boolean hasAdditionalParameter(String name) {
+        String paramName = new PropertyTokenizer(name).getName();
+        return additionalParameters.containsKey(paramName);
+    }
+
+    public void setAdditionalParameter(String name, Object value) {
+        metaParameters.setValue(name, value);
+    }
+
+    public Object getAdditionalParameter(String name) {
+        return metaParameters.getValue(name);
+    }
+
+}
+```
+
+## 5.1 ParameterMapping
+
+`org.apache.ibatis.mapping.ParameterMapping` ，参数映射。代码如下：
+
+```
+// ParameterMapping.java
+
+private Configuration configuration;
+
+/**
+ * 属性的名字
+ */
+private String property;
+/**
+ * 参数类型。
+ *
+ * 目前只需要关注 ParameterMode.IN 的情况，另外的 OUT、INOUT 是在存储过程中使用，暂时无视
+ */
+private ParameterMode mode;
+/**
+ * Java 类型
+ */
+private Class<?> javaType = Object.class;
+/**
+ * JDBC 类型
+ */
+private JdbcType jdbcType;
+/**
+ * 对于数值类型，还有一个小数保留位数的设置，来确定小数点后保留的位数
+ */
+private Integer numericScale;
+/**
+ * TypeHandler 对象
+ *
+ * {@link Builder#resolveTypeHandler()}
+ */
+private TypeHandler<?> typeHandler;
+/**
+ * 貌似只在 ParameterMode 在 OUT、INOUT 是在存储过程中使用
+ */
+private String resultMapId;
+/**
+ * 貌似只在 ParameterMode 在 OUT、INOUT 是在存储过程中使用
+ */
+private String jdbcTypeName;
+/**
+ * 表达式。
+ *
+ * ps：目前暂时不支持
+ */
+private String expression;
+
+public static class Builder {
+    
+    // ... 省略代码
+    
+}
+```
+
+- 参数比较简单，胖友自己看看注释。可以忽略 ParameterMode 属性为 `OUT` 和 `INOUT` 是在存储过程中使用的情况。
+- 完整的该类，可点击 [ParameterMapping](https://github.com/YunaiV/mybatis-3/blob/master/src/main/java/org/apache/ibatis/mapping/ParameterMapping.java) 查看。
+- 关于 ParameterMode 属性为 `OUT` 和 `INOUT` 是在存储过程中使用的情况，可以看看 [《Mybatis调用MySQL存储过程》](https://blog.csdn.net/u010046908/article/details/69944959) 。当然，也可以不看，因为很少使用存储过程了。
+
+## 5.2 ParameterMode
+
+`org.apache.ibatis.mapping.ParameterMode` ，参数类型。代码如下：
+
+```
+// ParameterMode.java
+
+public enum ParameterMode {
+
+    /**
+     * 输入
+     */
+    IN,
+    /**
+     * 输出
+     */
+    OUT,
+    /**
+     * IN + OUT
+     */
+    INOUT
+
+}
+```
+
+- 只需要关注 `IN` 的情况。
+- 另外，MyBatis 存储过程相关的源码，本系列会直接忽略。嘿嘿。
+
+# 7. ParameterHandler
+
+`org.apache.ibatis.executor.parameter.ParameterHandler` ，参数处理器接口。代码如下：
+
+```
+// ParameterHandler.java
+
+/**
+ * A parameter handler sets the parameters of the {@code PreparedStatement}
+ */
+public interface ParameterHandler {
+
+    /**
+     * @return 参数对象
+     */
+    Object getParameterObject();
+
+    /**
+     * 设置 PreparedStatement 的占位符参数
+     *
+     * @param ps PreparedStatement 对象
+     * @throws SQLException 发生 SQL 异常时
+     */
+    void setParameters(PreparedStatement ps) throws SQLException;
+
+}
+```
+
+## 7.1 DefaultParameterHandler
+
+`org.apache.ibatis.scripting.default.DefaultParameterHandler` ，实现 ParameterHandler 接口，默认 ParameterHandler 实现类。
+
+### 7.1.1 构造方法
+
+```
+// DefaultParameterHandler.java
+
+private final TypeHandlerRegistry typeHandlerRegistry;
+/**
+ * MappedStatement 对象
+ */
+private final MappedStatement mappedStatement;
+/**
+ * 参数对象
+ */
+private final Object parameterObject;
+/**
+ * BoundSql 对象
+ */
+private final BoundSql boundSql;
+private final Configuration configuration;
+
+public DefaultParameterHandler(MappedStatement mappedStatement, Object parameterObject, BoundSql boundSql) {
+    this.mappedStatement = mappedStatement;
+    this.configuration = mappedStatement.getConfiguration();
+    this.typeHandlerRegistry = mappedStatement.getConfiguration().getTypeHandlerRegistry();
+    this.parameterObject = parameterObject;
+    this.boundSql = boundSql;
+}
+```
+
+### 7.1.2 setParameters
+
+`#setParameters(PreparedStatement ps)` 方法，代码如下：
+
+```
+// DefaultParameterHandler.java
+
+@Override
+public void setParameters(PreparedStatement ps) {
+    ErrorContext.instance().activity("setting parameters").object(mappedStatement.getParameterMap().getId());
+    // <1> 遍历 ParameterMapping 数组
+    List<ParameterMapping> parameterMappings = boundSql.getParameterMappings();
+    if (parameterMappings != null) {
+        for (int i = 0; i < parameterMappings.size(); i++) {
+            // <2> 获得 ParameterMapping 对象
+            ParameterMapping parameterMapping = parameterMappings.get(i);
+            if (parameterMapping.getMode() != ParameterMode.OUT) {
+                // <3> 获得值
+                Object value;
+                String propertyName = parameterMapping.getProperty();
+                if (boundSql.hasAdditionalParameter(propertyName)) { // issue #448 ask first for additional params
+                    value = boundSql.getAdditionalParameter(propertyName);
+                } else if (parameterObject == null) {
+                    value = null;
+                } else if (typeHandlerRegistry.hasTypeHandler(parameterObject.getClass())) {
+                    value = parameterObject;
+                } else {
+                    MetaObject metaObject = configuration.newMetaObject(parameterObject);
+                    value = metaObject.getValue(propertyName);
+                }
+                // <4> 获得 typeHandler、jdbcType 属性
+                TypeHandler typeHandler = parameterMapping.getTypeHandler();
+                JdbcType jdbcType = parameterMapping.getJdbcType();
+                if (value == null && jdbcType == null) {
+                    jdbcType = configuration.getJdbcTypeForNull();
+                }
+                // <5> 设置 ? 占位符的参数
+                try {
+                    typeHandler.setParameter(ps, i + 1, value, jdbcType);
+                } catch (TypeException | SQLException e) {
+                    throw new TypeException("Could not set parameters for mapping: " + parameterMapping + ". Cause: " + e, e);
+                }
+            }
+        }
+    }
+}
+```
+
+- `<1>` 处，遍历 ParameterMapping 数组。
+- `<2>` 处，获得 ParameterMapping 对象。
+- `<3>` 处，获得值。有多种情况，胖友可以细看下。
+- `<4>` 处，获得 `typeHandler`、`jdbcType` 属性。
+- 【重要】`<5>` 处，调用 `TypeHandler#setParameter(PreparedStatement ps, int i, T parameter, JdbcType jdbcType)` 方法，设置指定位置的 `?` 占位符的参数。
+
+# 666. 彩蛋
+
+hoho，刚开始写的有点懵逼。现在清晰多了。哈哈哈哈。
+
+参考和推荐如下文章：
+
+- 祖大俊 [《Mybatis3.4.x技术内幕（十七）：Mybatis之动态Sql设计原本（上）》](https://my.oschina.net/zudajun/blog/735553)
+- 祖大俊 [《Mybatis3.4.x技术内幕（十八）：Mybatis之动态Sql设计原本（下）》](https://my.oschina.net/zudajun/blog/735731)
+- 徐郡明 [《MyBatis 技术内幕》](https://item.jd.com/12125531.html) 的 [「3.2 SqlNode&SqlSource」](https://svip.iocoder.cn/MyBatis/scripting-2/#) 小节
\ No newline at end of file
diff --git a/mybatis/21-mybatis-SQL 执行（一）之 Executor.assets/01.png b/mybatis/21-mybatis-SQL 执行（一）之 Executor.assets/01.png
new file mode 100644
index 0000000..a1277d6
Binary files /dev/null and b/mybatis/21-mybatis-SQL 执行（一）之 Executor.assets/01.png differ
diff --git a/mybatis/21-mybatis-SQL 执行（一）之 Executor.assets/02.png b/mybatis/21-mybatis-SQL 执行（一）之 Executor.assets/02.png
new file mode 100644
index 0000000..aa3073e
Binary files /dev/null and b/mybatis/21-mybatis-SQL 执行（一）之 Executor.assets/02.png differ
diff --git a/mybatis/21-mybatis-SQL 执行（一）之 Executor.assets/03.png b/mybatis/21-mybatis-SQL 执行（一）之 Executor.assets/03.png
new file mode 100644
index 0000000..15a9991
Binary files /dev/null and b/mybatis/21-mybatis-SQL 执行（一）之 Executor.assets/03.png differ
diff --git a/mybatis/21-mybatis-SQL 执行（一）之 Executor.assets/04.png b/mybatis/21-mybatis-SQL 执行（一）之 Executor.assets/04.png
new file mode 100644
index 0000000..25fea0b
Binary files /dev/null and b/mybatis/21-mybatis-SQL 执行（一）之 Executor.assets/04.png differ
diff --git a/mybatis/21-mybatis-SQL 执行（一）之 Executor.assets/05.png b/mybatis/21-mybatis-SQL 执行（一）之 Executor.assets/05.png
new file mode 100644
index 0000000..72f7dc6
Binary files /dev/null and b/mybatis/21-mybatis-SQL 执行（一）之 Executor.assets/05.png differ
diff --git a/mybatis/21-mybatis-SQL 执行（一）之 Executor.md b/mybatis/21-mybatis-SQL 执行（一）之 Executor.md
new file mode 100644
index 0000000..7183951
--- /dev/null
+++ b/mybatis/21-mybatis-SQL 执行（一）之 Executor.md	
@@ -0,0 +1,2145 @@
+# 精尽 MyBatis 源码分析 —— SQL 执行（一）之 Executor
+
+# 1. 概述
+
+从本文开始，我们来分享 SQL **执行**的流程。在 [《精尽 MyBatis 源码分析 —— 项目结构一览》](http://svip.iocoder.cn/MyBatis/intro) 中，我们简单介绍这个流程如下：
+
+> 对应 `executor` 和 `cursor` 模块。前者对应**执行器**，后者对应执行**结果的游标**。
+>
+> SQL 语句的执行涉及多个组件 ，其中比较重要的是 Executor、StatementHandler、ParameterHandler 和 ResultSetHandler 。
+>
+> - **Executor** 主要负责维护一级缓存和二级缓存，并提供事务管理的相关操作，它会将数据库相关操作委托给 StatementHandler完成。
+> - **StatementHandler** 首先通过 **ParameterHandler** 完成 SQL 语句的实参绑定，然后通过 `java.sql.Statement` 对象执行 SQL 语句并得到结果集，最后通过 **ResultSetHandler** 完成结果集的映射，得到结果对象并返回。
+>
+> 整体过程如下图：
+>
+> [![整体过程](21-mybatis-SQL 执行（一）之 Executor.assets/05.png)](http://static.iocoder.cn/images/MyBatis/2020_01_04/05.png)整体过程
+
+下面，我们在看看 `executor` 包下的列情况，如下图所示：[![`executor` 包](21-mybatis-SQL 执行（一）之 Executor.assets/01.png)](http://static.iocoder.cn/images/MyBatis/2020_02_28/01.png)`executor` 包
+
+- 正如该包下的分包情况，每个包对应一个功能。
+
+- `statement` 包，实现向数据库发起 SQL 命令。
+
+- ```
+  parameter
+  ```
+
+   
+
+  包，实现设置 PreparedStatement 的占位符参数。
+
+  - 目前只有一个 ParameterHandler 接口，在 [《精尽 MyBatis 源码分析 —— SQL 初始化（下）之 SqlSource》](http://svip.iocoder.cn/MyBatis/scripting-2) 已经详细解析。
+
+- `keygen` 包，实现数据库主键生成( 获得 )的功能。
+
+- `resultset` 包，实现 ResultSet 结果集的处理，将其映射成对应的结果对象。
+
+- `result` 包，结果的处理，被 `resultset` 包所调用。可能胖友会好奇为啥会有 `resultset` 和 `result` 两个“重叠”的包。答案见 [《精尽 MyBatis 源码分析 —— SQL 执行（四）之 ResultSetHandler》](http://svip.iocoder.cn/MyBatis/executor-4) 。
+
+- `loader` 包，实现延迟加载的功能。
+
+- 根目录，Executor 接口及其实现类，作为 SQL 执行的核心入口。
+
+考虑到整个 `executor` 包的代码量近 5000 行，所以我们将每一个子包，作为一篇文章，逐包解析。所以，本文我们先来分享 根目录，也就是 Executor 接口及其实现类。
+
+# 2. Executor
+
+`org.apache.ibatis.executor.Executor` ，执行器接口。代码如下：
+
+```
+// Executor.java
+
+public interface Executor {
+
+    // 空 ResultHandler 对象的枚举
+    ResultHandler NO_RESULT_HANDLER = null;
+
+    // 更新 or 插入 or 删除，由传入的 MappedStatement 的 SQL 所决定
+    int update(MappedStatement ms, Object parameter) throws SQLException;
+
+    // 查询，带 ResultHandler + CacheKey + BoundSql
+    <E> List<E> query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey cacheKey, BoundSql boundSql) throws SQLException;
+    // 查询，带 ResultHandler
+    <E> List<E> query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler) throws SQLException;
+    // 查询，返回值为 Cursor
+    <E> Cursor<E> queryCursor(MappedStatement ms, Object parameter, RowBounds rowBounds) throws SQLException;
+
+    // 刷入批处理语句
+    List<BatchResult> flushStatements() throws SQLException;
+
+    // 提交事务
+    void commit(boolean required) throws SQLException;
+    // 回滚事务
+    void rollback(boolean required) throws SQLException;
+
+    // 创建 CacheKey 对象
+    CacheKey createCacheKey(MappedStatement ms, Object parameterObject, RowBounds rowBounds, BoundSql boundSql);
+    // 判断是否缓存
+    boolean isCached(MappedStatement ms, CacheKey key);
+    // 清除本地缓存
+    void clearLocalCache();
+
+    // 延迟加载
+    void deferLoad(MappedStatement ms, MetaObject resultObject, String property, CacheKey key, Class<?> targetType);
+
+    // 获得事务
+    Transaction getTransaction();
+    // 关闭事务
+    void close(boolean forceRollback);
+    // 判断事务是否关闭
+    boolean isClosed();
+
+    // 设置包装的 Executor 对象
+    void setExecutorWrapper(Executor executor);
+
+}
+```
+
+- 读和写操作相关的方法
+- 事务相关的方法
+- 缓存相关的方法
+- 设置延迟加载的方法
+- 设置包装的 Executor 对象的方法
+
+------
+
+Executor 的实现类如下图所示：[![Executor 类图](21-mybatis-SQL 执行（一）之 Executor.assets/02.png)](http://static.iocoder.cn/images/MyBatis/2020_02_28/02.png)Executor 类图
+
+- 我们可以看到，Executor 的直接子类有 BaseExecutor 和 CachingExecutor 两个。
+- 实际上，CachingExecutor 在 BaseExecutor 的基础上，实现**二级缓存**功能。
+- 在下文中，BaseExecutor 的**本地**缓存，就是**一级**缓存。
+
+下面，我们按照先看 BaseExecutor 侧的实现类的源码解析，再看 CachingExecutor 的。
+
+# 3. BaseExecutor
+
+`org.apache.ibatis.executor.BaseExecutor` ，实现 Executor 接口，提供骨架方法，从而使子类只要实现指定的几个抽象方法即可。
+
+## 3.1 构造方法
+
+```
+// BaseExecutor.java
+
+/**
+ * 事务对象
+ */
+protected Transaction transaction;
+/**
+ * 包装的 Executor 对象
+ */
+protected Executor wrapper;
+
+/**
+ * DeferredLoad( 延迟加载 ) 队列
+ */
+protected ConcurrentLinkedQueue<DeferredLoad> deferredLoads;
+/**
+ * 本地缓存，即一级缓存
+ */
+protected PerpetualCache localCache;
+/**
+ * 本地输出类型的参数的缓存
+ */
+protected PerpetualCache localOutputParameterCache;
+protected Configuration configuration;
+
+/**
+ * 记录嵌套查询的层级
+ */
+protected int queryStack;
+/**
+ * 是否关闭
+ */
+private boolean closed;
+
+protected BaseExecutor(Configuration configuration, Transaction transaction) {
+    this.transaction = transaction;
+    this.deferredLoads = new ConcurrentLinkedQueue<>();
+    this.localCache = new PerpetualCache("LocalCache");
+    this.localOutputParameterCache = new PerpetualCache("LocalOutputParameterCache");
+    this.closed = false;
+    this.configuration = configuration;
+    this.wrapper = this; // 自己
+}
+```
+
+- 和延迟加载相关，后续文章，详细解析。详细解析，见
+
+   
+
+  《精尽 MyBatis 源码分析 —— SQL 执行（五）之延迟加载》
+
+   
+
+  。
+
+  - `queryStack` 属性，记录**递归**嵌套查询的层级。
+  - `deferredLoads` 属性，DeferredLoad( 延迟加载 ) 队列。
+
+- `wrapper` 属性，在构造方法中，初始化为 `this` ，即自己。
+
+- `localCache` 属性，本地缓存，即**一级缓存**。那什么是一级缓存呢？
+
+  > 基于 [《MyBatis 的一级缓存实现详解及使用注意事项》](https://blog.csdn.net/luanlouis/article/details/41280959) 进行修改
+  >
+  > 每当我们使用 MyBatis 开启一次和数据库的会话，MyBatis 会创建出一个 SqlSession 对象表示一次数据库会话，**而每个 SqlSession 都会创建一个 Executor 对象**。
+  >
+  > 在对数据库的一次会话中，我们有可能会反复地执行完全相同的查询语句，如果不采取一些措施的话，每一次查询都会查询一次数据库，而我们在极短的时间内做了完全相同的查询，那么它们的结果极有可能完全相同，由于查询一次数据库的代价很大，这有可能造成很大的资源浪费。
+  >
+  > 为了解决这一问题，减少资源的浪费，MyBatis 会在表示会话的SqlSession 对象中建立一个简单的缓存，将每次查询到的结果结果缓存起来，当下次查询的时候，如果判断先前有个完全一样的查询，会直接从缓存中直接将结果取出，返回给用户，不需要再进行一次数据库查询了。😈 **注意，这个“简单的缓存”就是一级缓存，且默认开启，无法关闭**。
+  >
+  > 如下图所示，MyBatis 会在一次会话的表示 —— 一个 SqlSession 对象中创建一个本地缓存( `localCache` )，对于每一次查询，都会尝试根据查询的条件去本地缓存中查找是否在缓存中，如果在缓存中，就直接从缓存中取出，然后返回给用户；否则，从数据库读取数据，将查询结果存入缓存并返回给用户。
+  >
+  > [![整体过程](21-mybatis-SQL 执行（一）之 Executor.assets/03.png)](http://static.iocoder.cn/images/MyBatis/2020_02_28/03.png)整体过程
+  >
+  > - 关于这段话，胖友要理解 SqlSession 和 Executor 和一级缓存的关系。
+  > - 😈 另外，下文，我们还会介绍**二级缓存**是什么。
+
+- `transaction` 属性，事务对象。该属性，是通过构造方法传入。为什么呢？待我们看 `org.apache.ibatis.session.session` 包。
+
+## 3.2 clearLocalCache
+
+`#clearLocalCache()` 方法，清理一级（本地）缓存。代码如下：
+
+```
+// BaseExecutor.java
+
+@Override
+public void clearLocalCache() {
+    if (!closed) {
+        // 清理 localCache
+        localCache.clear();
+        // 清理 localOutputParameterCache
+        localOutputParameterCache.clear();
+    }
+}
+```
+
+## 3.3 createCacheKey
+
+`#createCacheKey(MappedStatement ms, Object parameterObject, RowBounds rowBounds, BoundSql boundSql)` 方法，创建 CacheKey 对象。代码如下：
+
+```
+// BaseExecutor.java
+
+@Override
+public CacheKey createCacheKey(MappedStatement ms, Object parameterObject, RowBounds rowBounds, BoundSql boundSql) {
+    if (closed) {
+        throw new ExecutorException("Executor was closed.");
+    }
+    // <1> 创建 CacheKey 对象
+    CacheKey cacheKey = new CacheKey();
+    // <2> 设置 id、offset、limit、sql 到 CacheKey 对象中
+    cacheKey.update(ms.getId());
+    cacheKey.update(rowBounds.getOffset());
+    cacheKey.update(rowBounds.getLimit());
+    cacheKey.update(boundSql.getSql());
+    // <3> 设置 ParameterMapping 数组的元素对应的每个 value 到 CacheKey 对象中
+    List<ParameterMapping> parameterMappings = boundSql.getParameterMappings();
+    TypeHandlerRegistry typeHandlerRegistry = ms.getConfiguration().getTypeHandlerRegistry();
+    // mimic DefaultParameterHandler logic 这块逻辑，和 DefaultParameterHandler 获取 value 是一致的。
+    for (ParameterMapping parameterMapping : parameterMappings) {
+        if (parameterMapping.getMode() != ParameterMode.OUT) {
+            Object value;
+            String propertyName = parameterMapping.getProperty();
+            if (boundSql.hasAdditionalParameter(propertyName)) {
+                value = boundSql.getAdditionalParameter(propertyName);
+            } else if (parameterObject == null) {
+                value = null;
+            } else if (typeHandlerRegistry.hasTypeHandler(parameterObject.getClass())) {
+                value = parameterObject;
+            } else {
+                MetaObject metaObject = configuration.newMetaObject(parameterObject);
+                value = metaObject.getValue(propertyName);
+            }
+            cacheKey.update(value);
+        }
+    }
+    // <4> 设置 Environment.id 到 CacheKey 对象中
+    if (configuration.getEnvironment() != null) {
+        // issue #176
+        cacheKey.update(configuration.getEnvironment().getId());
+    }
+    return cacheKey;
+}
+```
+
+- `<1>` 处，创建 CacheKey 对象。关于 CacheKey 类，在 [《精尽 MyBatis 源码分析 —— 缓存模块》](http://svip.iocoder.cn/MyBatis/cache-package) 已经详细解析。
+- `<2>` 处，设置 `id`、`offset`、`limit`、`sql` 到 CacheKey 对象中。
+- `<3>` 处，设置 ParameterMapping 数组的元素对应的每个 `value` 到 CacheKey 对象中。注意，这块逻辑，和 DefaultParameterHandler 获取 `value` 是一致的。
+- `<4>` 处，设置 `Environment.id` 到 CacheKey 对象中。
+
+## 3.4 isCached
+
+`#isCached(MappedStatement ms, CacheKey key)` 方法，判断一级缓存是否存在。代码如下：
+
+```
+// BaseExecutor.java
+
+@Override
+public boolean isCached(MappedStatement ms, CacheKey key) {
+    return localCache.getObject(key) != null;
+}
+```
+
+## 3.5 query
+
+① `#query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler)` 方法，读操作。代码如下：
+
+```
+// BaseExecutor.java
+
+@Override
+public <E> List<E> query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler) throws SQLException {
+    // <1> 获得 BoundSql 对象
+    BoundSql boundSql = ms.getBoundSql(parameter);
+    // <2> 创建 CacheKey 对象
+    CacheKey key = createCacheKey(ms, parameter, rowBounds, boundSql);
+    // <3> 查询
+    return query(ms, parameter, rowBounds, resultHandler, key, boundSql);
+}
+```
+
+- `<1>` 处，调用 `MappedStatement#getBoundSql(Object parameterObject)` 方法，获得 BoundSql 对象。
+- `<2>` 处，调用 `#createCacheKey(MappedStatement ms, Object parameterObject, RowBounds rowBounds, BoundSql boundSql)` 方法，创建 CacheKey 对象。
+- `<3>` 处，调用 `#query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql)` 方法，读操作。通过这样的方式，两个 `#query(...)` 方法，实际是统一的。
+
+② `#query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql)` 方法，读操作。代码如下：
+
+```
+// BaseExecutor.java
+
+@Override
+public <E> List<E> query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException {
+    ErrorContext.instance().resource(ms.getResource()).activity("executing a query").object(ms.getId());
+    // <1> 已经关闭，则抛出 ExecutorException 异常
+    if (closed) {
+        throw new ExecutorException("Executor was closed.");
+    }
+    // <2> 清空本地缓存，如果 queryStack 为零，并且要求清空本地缓存。
+    if (queryStack == 0 && ms.isFlushCacheRequired()) {
+        clearLocalCache();
+    }
+    List<E> list;
+    try {
+        // <3> queryStack + 1
+        queryStack++;
+        // <4.1> 从一级缓存中，获取查询结果
+        list = resultHandler == null ? (List<E>) localCache.getObject(key) : null;
+        // <4.2> 获取到，则进行处理
+        if (list != null) {
+            handleLocallyCachedOutputParameters(ms, key, parameter, boundSql);
+        // <4.3> 获得不到，则从数据库中查询
+        } else {
+            list = queryFromDatabase(ms, parameter, rowBounds, resultHandler, key, boundSql);
+        }
+    } finally {
+        // <5> queryStack - 1
+        queryStack--;
+    }
+    if (queryStack == 0) {
+        // <6.1> 执行延迟加载
+        for (DeferredLoad deferredLoad : deferredLoads) {
+            deferredLoad.load();
+        }
+        // issue #601
+        // <6.2> 清空 deferredLoads
+        deferredLoads.clear();
+        // <7> 如果缓存级别是 LocalCacheScope.STATEMENT ，则进行清理
+        if (configuration.getLocalCacheScope() == LocalCacheScope.STATEMENT) {
+            // issue #482
+            clearLocalCache();
+        }
+    }
+    return list;
+}
+```
+
+- `<1>` 处，已经关闭，则抛出 ExecutorException 异常。
+
+- `<2>` 处，调用 `#clearLocalCache()` 方法，清空本地缓存，如果 `queryStack` 为零，并且要求清空本地缓存。例如：`<select flushCache="true"> ... </a>` 。
+
+- `<3>` 处，`queryStack` + 1 。
+
+- ```
+  <4.1>
+  ```
+
+   
+
+  处，从一级缓存
+
+   
+
+  ```
+  localCache
+  ```
+
+   
+
+  中，获取查询结果。
+
+  - `<4.2>` 处，获取到，则进行处理。对于 `#handleLocallyCachedOutputParameters(MappedStatement ms, CacheKey key, Object parameter, BoundSql boundSql)` 方法，是处理存储过程的情况，所以我们就忽略。
+  - `<4.3>` 处，获得不到，则调用 `#queryFromDatabase()` 方法，从数据库中查询。详细解析，见 [「3.5.1 queryFromDatabase」](https://svip.iocoder.cn/MyBatis/executor-1/#) 。
+
+- `<5>` 处，`queryStack` - 1 。
+
+- ```
+  <6.1>
+  ```
+
+   
+
+  处，遍历 DeferredLoad 队列，逐个调用
+
+   
+
+  ```
+  DeferredLoad#load()
+  ```
+
+   
+
+  方法，执行延迟加载。详细解析，见
+
+   
+
+  《精尽 MyBatis 源码分析 —— SQL 执行（五）之延迟加载》
+
+   
+
+  。
+
+  - `<6.2>` 处，清空 DeferredLoad 队列。
+
+- `<7>` 处，如果缓存级别是 `LocalCacheScope.STATEMENT` ，则调用 `#clearLocalCache()` 方法，清空本地缓存。默认情况下，缓存级别是 `LocalCacheScope.SESSION` 。代码如下：
+
+  ```
+  // Configuration.java
+  
+  /**
+   * {@link BaseExecutor} 本地缓存范围
+   */
+  protected LocalCacheScope localCacheScope = LocalCacheScope.SESSION;
+  
+  // LocalCacheScope.java
+  
+  public enum LocalCacheScope {
+  
+      /**
+       * 会话级
+       */
+      SESSION,
+      /**
+       * SQL 语句级
+       */
+      STATEMENT
+  
+  }
+  ```
+
+### 3.5.1 queryFromDatabase
+
+`#queryFromDatabase(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql)` 方法，从数据库中读取操作。代码如下：
+
+```
+// BaseExecutor.java
+
+private <E> List<E> queryFromDatabase(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException {
+    List<E> list;
+    // <1> 在缓存中，添加占位对象。此处的占位符，和延迟加载有关，可见 `DeferredLoad#canLoad()` 方法
+    localCache.putObject(key, EXECUTION_PLACEHOLDER);
+    try {
+        // <2> 执行读操作
+        list = doQuery(ms, parameter, rowBounds, resultHandler, boundSql);
+    } finally {
+        // <3> 从缓存中，移除占位对象
+        localCache.removeObject(key);
+    }
+    // <4> 添加到缓存中
+    localCache.putObject(key, list);
+    // <5> 暂时忽略，存储过程相关
+    if (ms.getStatementType() == StatementType.CALLABLE) {
+        localOutputParameterCache.putObject(key, parameter);
+    }
+    return list;
+}
+```
+
+- `<1>` 处，在缓存中，添加**占位对象**。此处的占位符，和延迟加载有关，后续可见 `DeferredLoad#canLoad()` 方法。
+
+  ```
+  // BaseExecutor.java
+  
+  public enum ExecutionPlaceholder {
+  
+      /**
+       * 正在执行中的占位符
+       */
+      EXECUTION_PLACEHOLDER
+  
+  }
+  ```
+
+- `<2>` 处，调用 `#doQuery(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql)` 执行读操作。这是个抽象方法，由子类实现。
+
+- `<3>` 处，从缓存中，移除占位对象。
+
+- `<4>` 处，添加**结果**到缓存中。
+
+- `<5>` 处，暂时忽略，存储过程相关。
+
+### 3.5.2 doQuery
+
+```
+// BaseExecutor.java
+
+protected abstract <E> List<E> doQuery(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql)
+        throws SQLException;
+```
+
+## 3.6 queryCursor
+
+`#queryCursor(MappedStatement ms, Object parameter, RowBounds rowBounds)` 方法，执行查询，返回的结果为 Cursor 游标对象。代码如下：
+
+```
+// BaseExecutor.java
+
+@Override
+public <E> Cursor<E> queryCursor(MappedStatement ms, Object parameter, RowBounds rowBounds) throws SQLException {
+    // <1> 获得 BoundSql 对象
+    BoundSql boundSql = ms.getBoundSql(parameter);
+    // 执行查询
+    return doQueryCursor(ms, parameter, rowBounds, boundSql);
+}
+```
+
+- `<1>` 处，调用 `MappedStatement#getBoundSql(Object parameterObject)` 方法，获得 BoundSql 对象。
+- `<2>` 处，调用 `#doQueryCursor(MappedStatement ms, Object parameter, RowBounds rowBounds, BoundSql boundSql)` 方法，执行读操作。这是个抽象方法，由子类实现。
+
+### 3.6.1 doQueryCursor
+
+```
+// BaseExecutor.java
+
+protected abstract <E> Cursor<E> doQueryCursor(MappedStatement ms, Object parameter, RowBounds rowBounds, BoundSql boundSql)
+        throws SQLException;
+```
+
+## 3.7 update
+
+`#update(MappedStatement ms, Object parameter)` 方法，执行写操作。代码如下：
+
+```
+// BaseExecutor.java
+
+@Override
+public int update(MappedStatement ms, Object parameter) throws SQLException {
+    ErrorContext.instance().resource(ms.getResource()).activity("executing an update").object(ms.getId());
+    // <1> 已经关闭，则抛出 ExecutorException 异常
+    if (closed) {
+        throw new ExecutorException("Executor was closed.");
+    }
+    // <2> 清空本地缓存
+    clearLocalCache();
+    // <3> 执行写操作
+    return doUpdate(ms, parameter);
+}
+```
+
+- `<1>` 处，已经关闭，则抛出 ExecutorException 异常。
+- `<2>` 处，调用 `#clearLocalCache()` 方法，清空本地缓存。因为，更新后，可能缓存会失效。但是，又没很好的办法，判断哪一些失效。所以，最稳妥的做法，就是全部清空。
+- `<3>` 处，调用 `#doUpdate(MappedStatement ms, Object parameter)` 方法，执行写操作。这是个抽象方法，由子类实现。
+
+### 3.7.1 doUpdate
+
+```
+// BaseExecutor.java
+
+protected abstract int doUpdate(MappedStatement ms, Object parameter)
+        throws SQLException;
+```
+
+## 3.8 flushStatements
+
+`#flushStatements()` 方法，刷入批处理语句。代码如下：
+
+```
+// BaseExecutor.java
+
+@Override
+public List<BatchResult> flushStatements() throws SQLException {
+    return flushStatements(false);
+}
+
+public List<BatchResult> flushStatements(boolean isRollBack) throws SQLException {
+    // <1> 已经关闭，则抛出 ExecutorException 异常
+    if (closed) {
+        throw new ExecutorException("Executor was closed.");
+    }
+    // <2> 执行刷入批处理语句
+    return doFlushStatements(isRollBack);
+}
+```
+
+- `isRollBack` 属性，目前看下来没什么逻辑。唯一看到在 BatchExecutor 中，如果 `isRollBack = true` ，则**不执行**刷入批处理语句。有点奇怪。
+- `<1>` 处，已经关闭，则抛出 ExecutorException 异常。
+- `<2>` 处，调用 `#doFlushStatements(boolean isRollback)` 方法，执行刷入批处理语句。这是个抽象方法，由子类实现。
+
+### 3.8.1 doFlushStatements
+
+```
+// BaseExecutor.java
+
+protected abstract List<BatchResult> doFlushStatements(boolean isRollback)
+        throws SQLException;
+```
+
+------
+
+至此，我们已经看到了 BaseExecutor 所定义的**四个抽象方法**：
+
+- 「3.5.2 doQuery」
+- 「3.6.1 doQueryCursor」
+- 「3.7.1 doUpdate」
+- 「3.8.1 doFlushStatements」
+
+## 3.9 getTransaction
+
+`#getTransaction()` 方法，获得事务对象。代码如下：
+
+```
+// BaseExecutor.java
+
+@Override
+public Transaction getTransaction() {
+    if (closed) {
+        throw new ExecutorException("Executor was closed.");
+    }
+    return transaction;
+}
+```
+
+### 3.9.1 commit
+
+```
+// BaseExecutor.java
+
+@Override
+public void commit(boolean required) throws SQLException {
+    // 已经关闭，则抛出 ExecutorException 异常
+    if (closed) {
+        throw new ExecutorException("Cannot commit, transaction is already closed");
+    }
+    // 清空本地缓存
+    clearLocalCache();
+    // 刷入批处理语句
+    flushStatements();
+    // 是否要求提交事务。如果是，则提交事务。
+    if (required) {
+        transaction.commit();
+    }
+}
+```
+
+### 3.9.2 rollback
+
+```
+// BaseExecutor.java
+
+public void rollback(boolean required) throws SQLException {
+    if (!closed) {
+        try {
+            // 清空本地缓存
+            clearLocalCache();
+            // 刷入批处理语句
+            flushStatements(true);
+        } finally {
+            if (required) {
+                // 是否要求回滚事务。如果是，则回滚事务。
+                transaction.rollback();
+            }
+        }
+    }
+}
+```
+
+## 3.10 close
+
+`#close()` 方法，关闭执行器。代码如下：
+
+```
+// BaseExecutor.java
+
+@Override
+public void close(boolean forceRollback) {
+    try {
+        // 回滚事务
+        try {
+            rollback(forceRollback);
+        } finally {
+            // 关闭事务
+            if (transaction != null) {
+                transaction.close();
+            }
+        }
+    } catch (SQLException e) {
+        // Ignore.  There's nothing that can be done at this point.
+        log.warn("Unexpected exception on closing transaction.  Cause: " + e);
+    } finally {
+        // 置空变量
+        transaction = null;
+        deferredLoads = null;
+        localCache = null;
+        localOutputParameterCache = null;
+        closed = true;
+    }
+}
+```
+
+### 3.10.1 isClosed
+
+```
+// BaseExecutor.java
+
+@Override
+public boolean isClosed() {
+    return closed;
+}
+```
+
+## 3.11 deferLoad
+
+详细解析，见 [《精尽 MyBatis 源码分析 —— SQL 执行（五）之延迟加载》](http://svip.iocoder.cn/MyBatis/executor-5) 。
+
+## 3.12 setExecutorWrapper
+
+`#setExecutorWrapper(Executor wrapper)` 方法，设置包装器。代码如下：
+
+```
+// BaseExecutor.java
+
+@Override
+public void setExecutorWrapper(Executor wrapper) {
+    this.wrapper = wrapper;
+}
+```
+
+## 3.13 其它方法
+
+```
+// BaseExecutor.java
+
+// 获得 Connection 对象
+protected Connection getConnection(Log statementLog) throws SQLException {
+    // 获得 Connection 对象
+    Connection connection = transaction.getConnection();
+    // 如果 debug 日志级别，则创建 ConnectionLogger 对象，进行动态代理
+    if (statementLog.isDebugEnabled()) {
+        return ConnectionLogger.newInstance(connection, statementLog, queryStack);
+    } else {
+        return connection;
+    }
+}
+
+// 设置事务超时时间
+protected void applyTransactionTimeout(Statement statement) throws SQLException {
+    StatementUtil.applyTransactionTimeout(statement, statement.getQueryTimeout(), transaction.getTimeout());
+}
+
+// 关闭 Statement 对象
+protected void closeStatement(Statement statement) {
+    if (statement != null) {
+        try {
+            if (!statement.isClosed()) {
+                statement.close();
+            }
+        } catch (SQLException e) {
+            // ignore
+        }
+    }
+}
+```
+
+- 关于 StatementUtil 类，可以点击 [`org.apache.ibatis.executor.statement.StatementUtil`](https://github.com/YunaiV/mybatis-3/blob/master/src/main/java/org/apache/ibatis/executor/statement/StatementUtil.java) 查看。
+
+# 4. SimpleExecutor
+
+`org.apache.ibatis.executor.SimpleExecutor` ，继承 BaseExecutor 抽象类，简单的 Executor 实现类。
+
+- 每次开始读或写操作，都创建对应的 Statement 对象。
+- 执行完成后，关闭该 Statement 对象。
+
+## 4.1 构造方法
+
+```
+// SimpleExecutor.java
+
+public SimpleExecutor(Configuration configuration, Transaction transaction) {
+    super(configuration, transaction);
+}
+```
+
+## 4.2 doQuery
+
+> 老艿艿：从此处开始，我们会看到 StatementHandler 相关的调用，胖友可以结合 [《精尽 MyBatis 源码分析 —— SQL 执行（二）之 StatementHandler》](http://svip.iocoder.cn/MyBatis/executor-2) 一起看。
+
+```
+// SimpleExecutor.java
+
+@Override
+public <E> List<E> doQuery(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql) throws SQLException {
+    Statement stmt = null;
+    try {
+        Configuration configuration = ms.getConfiguration();
+        // <1> 创建 StatementHandler 对象
+        StatementHandler handler = configuration.newStatementHandler(wrapper, ms, parameter, rowBounds, resultHandler, boundSql);
+        // <2> 初始化 StatementHandler 对象
+        stmt = prepareStatement(handler, ms.getStatementLog());
+        // <3> 执行 StatementHandler  ，进行读操作
+        return handler.query(stmt, resultHandler);
+    } finally {
+        // <4> 关闭 StatementHandler 对象
+        closeStatement(stmt);
+    }
+}
+```
+
+- `<1>` 处，调用 `Configuration#newStatementHandler(Executor executor, MappedStatement mappedStatement, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql)` 方法，创建 StatementHandler 对象。
+
+- `<2>` 处，调用 `#prepareStatement(StatementHandler handler, Log statementLog)` 方法，初始化 StatementHandler 对象。代码如下：
+
+  ```
+  // SimpleExecutor.java
+  
+  private Statement prepareStatement(StatementHandler handler, Log statementLog) throws SQLException {
+      Statement stmt;
+      // <2.1> 获得 Connection 对象
+      Connection connection = getConnection(statementLog);
+      // <2.2> 创建 Statement 或 PrepareStatement 对象
+      stmt = handler.prepare(connection, transaction.getTimeout());
+      // <2.3> 设置 SQL 上的参数，例如 PrepareStatement 对象上的占位符
+      handler.parameterize(stmt);
+      return stmt;
+  }
+  ```
+
+  - `<2.1>` 处，调用 `#getConnection(Log statementLog)` 方法，获得 Connection 对象。
+  - `<2.2>` 处，调用 `StatementHandler#prepare(Connection connection, Integer transactionTimeout)` 方法，创建 Statement 或 PrepareStatement 对象。
+  - `<2.3>` 处，调用 `StatementHandler#prepare(Statement statement)` 方法，设置 SQL 上的参数，例如 PrepareStatement 对象上的占位符。
+
+- `<3>` 处，调用 `StatementHandler#query(Statement statement, ResultHandler resultHandler)` 方法，进行**读操作**。
+
+- `<4>` 处，调用 `#closeStatement(Statement stmt)` 方法，关闭 StatementHandler 对象。
+
+## 4.3 doQueryCursor
+
+```
+// SimpleExecutor.java
+
+@Override
+protected <E> Cursor<E> doQueryCursor(MappedStatement ms, Object parameter, RowBounds rowBounds, BoundSql boundSql) throws SQLException {
+    Configuration configuration = ms.getConfiguration();
+    // 创建 StatementHandler 对象
+    StatementHandler handler = configuration.newStatementHandler(wrapper, ms, parameter, rowBounds, null, boundSql);
+    // 初始化 StatementHandler 对象
+    Statement stmt = prepareStatement(handler, ms.getStatementLog());
+    // 设置 Statement ，如果执行完成，则进行自动关闭
+    stmt.closeOnCompletion();
+    // 执行 StatementHandler  ，进行读操作
+    return handler.queryCursor(stmt);
+}
+```
+
+- 和 `#doQuery(...)` 方法的思路是一致的，胖友自己看下。
+
+## 4.4 doUpdate
+
+```
+// SimpleExecutor.java
+
+@Override
+public int doUpdate(MappedStatement ms, Object parameter) throws SQLException {
+    Statement stmt = null;
+    try {
+        Configuration configuration = ms.getConfiguration();
+        // 创建 StatementHandler 对象
+        StatementHandler handler = configuration.newStatementHandler(this, ms, parameter, RowBounds.DEFAULT, null, null);
+        // 初始化 StatementHandler 对象
+        stmt = prepareStatement(handler, ms.getStatementLog());
+        // <3> 执行 StatementHandler ，进行写操作
+        return handler.update(stmt);
+    } finally {
+        // 关闭 StatementHandler 对象
+        closeStatement(stmt);
+    }
+}
+```
+
+- 相比 `#doQuery(...)` 方法，差异点在 `<3>` 处，换成了调用 `StatementHandler#update(Statement statement)` 方法，进行**写操作**。
+
+## 4.5 doFlushStatements
+
+```
+// SimpleExecutor.java
+
+@Override
+public List<BatchResult> doFlushStatements(boolean isRollback) throws SQLException {
+    return Collections.emptyList();
+}
+```
+
+- 不存在批量操作的情况，所以直接返回空数组。
+
+# 5. ReuseExecutor
+
+`org.apache.ibatis.executor.ReuseExecutor` ，继承 BaseExecutor 抽象类，可重用的 Executor 实现类。
+
+- 每次开始读或写操作，优先从缓存中获取对应的 Statement 对象。如果不存在，才进行创建。
+- 执行完成后，不关闭该 Statement 对象。
+- 其它的，和 SimpleExecutor 是一致的。
+
+## 5.1 构造方法
+
+```
+// ReuseExecutor.java
+
+/**
+ * Statement 的缓存
+ *
+ * KEY ：SQL
+ */
+private final Map<String, Statement> statementMap = new HashMap<>();
+
+public ReuseExecutor(Configuration configuration, Transaction transaction) {
+    super(configuration, transaction);
+}
+```
+
+## 5.2 doQuery
+
+```
+// ReuseExecutor.java
+
+@Override
+public <E> List<E> doQuery(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql) throws SQLException {
+    Configuration configuration = ms.getConfiguration();
+    // 创建 StatementHandler 对象
+    StatementHandler handler = configuration.newStatementHandler(wrapper, ms, parameter, rowBounds, resultHandler, boundSql);
+    // <1> 初始化 StatementHandler 对象
+    Statement stmt = prepareStatement(handler, ms.getStatementLog());
+    // 执行 StatementHandler  ，进行读操作
+    return handler.query(stmt, resultHandler);
+}
+```
+
+- 差异一，在于 `<1>` 处，调用 `#prepareStatement(StatementHandler handler, Log statementLog)` 方法，初始化 StatementHandler 对象。代码如下：
+
+  ```
+  // ReuseExecutor.java
+  
+  private Statement prepareStatement(StatementHandler handler, Log statementLog) throws SQLException {
+      Statement stmt;
+      BoundSql boundSql = handler.getBoundSql();
+      String sql = boundSql.getSql();
+      // 存在
+      if (hasStatementFor(sql)) {
+          // <1.1> 从缓存中获得 Statement 或 PrepareStatement 对象
+          stmt = getStatement(sql);
+          // <1.2> 设置事务超时时间
+          applyTransactionTimeout(stmt);
+      // 不存在
+      } else {
+          // <2.1> 获得 Connection 对象
+          Connection connection = getConnection(statementLog);
+          // <2.2> 创建 Statement 或 PrepareStatement 对象
+          stmt = handler.prepare(connection, transaction.getTimeout());
+          // <2.3> 添加到缓存中
+          putStatement(sql, stmt);
+      }
+      // <2> 设置 SQL 上的参数，例如 PrepareStatement 对象上的占位符
+      handler.parameterize(stmt);
+      return stmt;
+  }
+  ```
+
+  - 调用 `#hasStatementFor(String sql)` 方法，判断是否存在对应的 Statement 对象。代码如下：
+
+    ```
+    // ReuseExecutor.java
+    
+    private boolean hasStatementFor(String sql) {
+        try {
+            return statementMap.keySet().contains(sql) && !statementMap.get(sql).getConnection().isClosed();
+        } catch (SQLException e) {
+            return false;
+        }
+    }
+    ```
+
+    - 并且，要求连接**未关闭**。
+
+  - 存在
+
+    - `<1.1>` 处，调用 `#getStatement(String s)` 方法，获得 Statement 对象。代码如下：
+
+      ```
+      // ReuseExecutor.java
+      
+      private Statement getStatement(String s) {
+          return statementMap.get(s);
+      }
+      ```
+
+      - x
+
+    - 【差异】`<1.2>` 处，调用 `#applyTransactionTimeout(Statement stmt)` 方法，设置事务超时时间。
+
+  - 不存在
+
+    - `<2.1>` 处，获得 Connection 对象。
+
+    - `<2.2>` 处，调用 `StatementHandler#prepare(Connection connection, Integer transactionTimeout)` 方法，创建 Statement 或 PrepareStatement 对象。
+
+    - 【差异】`<2.3>` 处，调用 `#putStatement(String sql, Statement stmt)` 方法，添加 Statement 对象到缓存中。代码如下：
+
+      ```
+      // ReuseExecutor.java
+      
+      private void putStatement(String sql, Statement stmt) {
+          statementMap.put(sql, stmt);
+      }
+      ```
+
+      - x
+
+  - `<2>` 处，调用 `StatementHandler#prepare(Statement statement)` 方法，设置 SQL 上的参数，例如 PrepareStatement 对象上的占位符。
+
+- 差异二，在执行完数据库操作后，不会关闭 Statement 。
+
+## 5.3 doQueryCursor
+
+```
+// ReuseExecutor.java
+
+@Override
+protected <E> Cursor<E> doQueryCursor(MappedStatement ms, Object parameter, RowBounds rowBounds, BoundSql boundSql) throws SQLException {
+    Configuration configuration = ms.getConfiguration();
+    // 创建 StatementHandler 对象
+    StatementHandler handler = configuration.newStatementHandler(wrapper, ms, parameter, rowBounds, null, boundSql);
+    // 初始化 StatementHandler 对象
+    Statement stmt = prepareStatement(handler, ms.getStatementLog());
+    // 执行 StatementHandler  ，进行读操作
+    return handler.queryCursor(stmt);
+}
+```
+
+## 5.4 doUpdate
+
+```
+// ReuseExecutor.java
+
+@Override
+public int doUpdate(MappedStatement ms, Object parameter) throws SQLException {
+    Configuration configuration = ms.getConfiguration();
+    // 创建 StatementHandler 对象
+    StatementHandler handler = configuration.newStatementHandler(this, ms, parameter, RowBounds.DEFAULT, null, null);
+    // 初始化 StatementHandler 对象
+    Statement stmt = prepareStatement(handler, ms.getStatementLog());
+    // 执行 StatementHandler  ，进行写操作
+    return handler.update(stmt);
+}
+```
+
+## 5.5 doFlushStatements
+
+```
+// ReuseExecutor.java
+
+@Override
+public List<BatchResult> doFlushStatements(boolean isRollback) throws SQLException {
+    // 关闭缓存的 Statement 对象们
+    for (Statement stmt : statementMap.values()) {
+        closeStatement(stmt);
+    }
+    statementMap.clear();
+    // 返回空集合
+    return Collections.emptyList();
+}
+```
+
+- ReuseExecutor 考虑到重用性，但是 Statement 最终还是需要有地方关闭。答案就在 `#doFlushStatements(boolean isRollback)` 方法中。而 BaseExecutor 在关闭 `#close()` 方法中，最终也会调用该方法，从而完成关闭缓存的 Statement 对象们
+  。
+- 另外，BaseExecutor 在提交或者回滚事务方法中，最终也会调用该方法，也能完成关闭缓存的 Statement 对象们。
+
+# 6. BatchExecutor
+
+`org.apache.ibatis.executor.BatchExecutor` ，继承 BaseExecutor 抽象类，批量执行的 Executor 实现类。
+
+> FROM 祖大俊 [《Mybatis3.3.x技术内幕（四）：五鼠闹东京之执行器Executor设计原本》](https://my.oschina.net/zudajun/blog/667214)
+>
+> 执行update（没有select，JDBC批处理不支持select），将所有sql都添加到批处理中（addBatch()），等待统一执行（executeBatch()），它缓存了多个Statement对象，每个Statement对象都是addBatch()完毕后，等待逐一执行executeBatch()批处理的；BatchExecutor相当于维护了多个桶，每个桶里都装了很多属于自己的SQL，就像苹果蓝里装了很多苹果，番茄蓝里装了很多番茄，最后，再统一倒进仓库。（可以是Statement或PrepareStatement对象）
+
+## 6.1 构造方法
+
+```
+// BatchExecutor.java
+
+/**
+ * Statement 数组
+ */
+private final List<Statement> statementList = new ArrayList<>();
+/**
+ * BatchResult 数组
+ *
+ * 每一个 BatchResult 元素，对应一个 {@link #statementList} 的 Statement 元素
+ */
+private final List<BatchResult> batchResultList = new ArrayList<>();
+/**
+ * 当前 SQL
+ */
+private String currentSql;
+/**
+ * 当前 MappedStatement 对象
+ */
+private MappedStatement currentStatement;
+
+public BatchExecutor(Configuration configuration, Transaction transaction) {
+    super(configuration, transaction);
+}
+```
+
+- `currentSql` 和 `currentStatement` 属性，当前 SQL 和 MappedStatement 对象。
+- `batchResultList` 和 `statementList` 属性，分别是 BatchResult 和 Statement 数组。并且，每一个 `batchResultList` 的 BatchResult 元素，对应一个 `statementList` 的 Statement 元素。
+- 具体怎么应用上述属性，我们见 `#doUpdate(...)` 和 `#doFlushStatements(...)` 方法。
+
+## 6.2 BatchResult
+
+`org.apache.ibatis.executor.BatchResult` ，相同 SQL 聚合的结果。代码如下：
+
+```
+// BatchResult.java
+
+/**
+ * MappedStatement 对象
+ */
+private final MappedStatement mappedStatement;
+/**
+ * SQL
+ */
+private final String sql;
+/**
+ * 参数对象集合
+ *
+ * 每一个元素，对应一次操作的参数
+ */
+private final List<Object> parameterObjects;
+/**
+ * 更新数量集合
+ *
+ * 每一个元素，对应一次操作的更新数量
+ */
+private int[] updateCounts;
+
+// ... 省略 setting / getting 相关方法
+```
+
+## 6.3 doUpdate
+
+```
+// BatchExecutor.java
+
+@Override
+public int doUpdate(MappedStatement ms, Object parameterObject) throws SQLException {
+    final Configuration configuration = ms.getConfiguration();
+    // <1> 创建 StatementHandler 对象
+    final StatementHandler handler = configuration.newStatementHandler(this, ms, parameterObject, RowBounds.DEFAULT, null, null);
+    final BoundSql boundSql = handler.getBoundSql();
+    final String sql = boundSql.getSql();
+    final Statement stmt;
+    // <2> 如果匹配最后一次 currentSql 和 currentStatement ，则聚合到 BatchResult 中
+    if (sql.equals(currentSql) && ms.equals(currentStatement)) {
+        // <2.1> 获得最后一次的 Statement 对象
+        int last = statementList.size() - 1;
+        stmt = statementList.get(last);
+        // <2.2> 设置事务超时时间
+        applyTransactionTimeout(stmt);
+        // <2.3> 设置 SQL 上的参数，例如 PrepareStatement 对象上的占位符
+        handler.parameterize(stmt);//fix Issues 322
+        // <2.4> 获得最后一次的 BatchResult 对象，并添加参数到其中
+        BatchResult batchResult = batchResultList.get(last);
+        batchResult.addParameterObject(parameterObject);
+    // <3> 如果不匹配最后一次 currentSql 和 currentStatement ，则新建 BatchResult 对象
+    } else {
+        // <3.1> 获得 Connection
+        Connection connection = getConnection(ms.getStatementLog());
+        // <3.2> 创建 Statement 或 PrepareStatement 对象
+        stmt = handler.prepare(connection, transaction.getTimeout());
+        // <3.3> 设置 SQL 上的参数，例如 PrepareStatement 对象上的占位符
+        handler.parameterize(stmt);    //fix Issues 322
+        // <3.4> 重新设置 currentSql 和 currentStatement
+        currentSql = sql;
+        currentStatement = ms;
+        // <3.5> 添加 Statement 到 statementList 中
+        statementList.add(stmt);
+        // <3.6> 创建 BatchResult 对象，并添加到 batchResultList 中
+        batchResultList.add(new BatchResult(ms, sql, parameterObject));
+    }
+    // handler.parameterize(stmt);
+    // <4> 批处理
+    handler.batch(stmt);
+    return BATCH_UPDATE_RETURN_VALUE;
+}
+```
+
+- `<1>` 处，调用 `Configuration#newStatementHandler(...)` 方法，创建 StatementHandler 对象。
+
+- `<2>` 和 `<3>` 处，就是两种不同的情况，差异点在于传入的 `sql` 和 `ms` 是否匹配当前的 `currentSql` 和 `currentStatement` 。如果是，则继续聚合到最后的 BatchResult 中，否则，创建新的 BatchResult 对象，进行“聚合”。
+
+- ```
+  <2>
+  ```
+
+   
+
+  块：
+
+  - `<2.1>`、`<2.2>`、`<2.3>` 处，逻辑和 ReuseExecutor 相似，使用可重用的 Statement 对象，并进行初始化。
+  - `<2.4>` 处，获得最后一次的 BatchResult 对象，并添加参数到其中。
+
+- ```
+  <3>
+  ```
+
+   
+
+  块：
+
+  - `<3.1>`、`<3.2>`、`<3.3>` 处，逻辑和 SimpleExecutor 相似，创建新的 Statement 对象，并进行初始化。
+  - `<3.4>` 处，重新设置 `currentSql` 和 `currentStatement` ，为当前传入的 `sql` 和 `ms` 。
+  - `<3.5>` 处，添加 Statement 到 `statementList` 中。
+  - `<3.6>` 处，创建 BatchResult 对象，并添加到 `batchResultList` 中。
+  - 那么，如果下一次执行这个方法，如果传递相同的 `sql` 和 `ms` 进来，就会聚合到目前新创建的 BatchResult 对象中。
+
+- `<4>` 处，调用 `StatementHandler#batch(Statement statement)` 方法，批处理。代码如下：
+
+  ```
+  // 有多个实现类，先看两个
+  
+  // PreparedStatementHandler.java
+  
+  @Override
+  public void batch(Statement statement) throws SQLException {
+      PreparedStatement ps = (PreparedStatement) statement;
+      ps.addBatch();
+  }
+  
+  // SimpleStatementHandler.java
+  
+  @Override
+  public void batch(Statement statement) throws SQLException {
+      String sql = boundSql.getSql();
+      statement.addBatch(sql);
+  }
+  ```
+
+  - 这段代码，是不是非常熟悉。
+
+## 6.4 doFlushStatements
+
+```
+// BatchExecutor.java
+
+@Override
+public List<BatchResult> doFlushStatements(boolean isRollback) throws SQLException {
+    try {
+        // <1> 如果 isRollback 为 true ，返回空数组
+        if (isRollback) {
+            return Collections.emptyList();
+        }
+        // <2> 遍历 statementList 和 batchResultList 数组，逐个提交批处理
+        List<BatchResult> results = new ArrayList<>();
+        for (int i = 0, n = statementList.size(); i < n; i++) {
+            // <2.1> 获得 Statement 和 BatchResult 对象
+            Statement stmt = statementList.get(i);
+            applyTransactionTimeout(stmt);
+            BatchResult batchResult = batchResultList.get(i);
+            try {
+                // <2.2> 批量执行
+                batchResult.setUpdateCounts(stmt.executeBatch());
+                // <2.3> 处理主键生成
+                MappedStatement ms = batchResult.getMappedStatement();
+                List<Object> parameterObjects = batchResult.getParameterObjects();
+                KeyGenerator keyGenerator = ms.getKeyGenerator();
+                if (Jdbc3KeyGenerator.class.equals(keyGenerator.getClass())) {
+                    Jdbc3KeyGenerator jdbc3KeyGenerator = (Jdbc3KeyGenerator) keyGenerator;
+                    jdbc3KeyGenerator.processBatch(ms, stmt, parameterObjects);
+                } else if (!NoKeyGenerator.class.equals(keyGenerator.getClass())) { //issue #141
+                    for (Object parameter : parameterObjects) {
+                        keyGenerator.processAfter(this, ms, stmt, parameter);
+                    }
+                }
+                // Close statement to close cursor #1109
+                // <2.4> 关闭 Statement 对象
+                closeStatement(stmt);
+            } catch (BatchUpdateException e) {
+                // 如果发生异常，则抛出 BatchExecutorException 异常
+                StringBuilder message = new StringBuilder();
+                message.append(batchResult.getMappedStatement().getId())
+                        .append(" (batch index #")
+                        .append(i + 1)
+                        .append(")")
+                        .append(" failed.");
+                if (i > 0) {
+                    message.append(" ")
+                            .append(i)
+                            .append(" prior sub executor(s) completed successfully, but will be rolled back.");
+                }
+                throw new BatchExecutorException(message.toString(), e, results, batchResult);
+            }
+            // <2.5> 添加到结果集
+            results.add(batchResult);
+        }
+        return results;
+    } finally {
+        // <3.1> 关闭 Statement 们
+        for (Statement stmt : statementList) {
+            closeStatement(stmt);
+        }
+        // <3.2> 置空 currentSql、statementList、batchResultList 属性
+        currentSql = null;
+        statementList.clear();
+        batchResultList.clear();
+    }
+}
+```
+
+- `<1>` 处，如果 `isRollback` 为 `true` ，返回空数组。
+
+- ```
+  <2>
+  ```
+
+   
+
+  处，遍历
+
+   
+
+  ```
+  statementList
+  ```
+
+   
+
+  和
+
+   
+
+  ```
+  batchResultList
+  ```
+
+   
+
+  数组，逐个 Statement 提交批处理。
+
+  - `<2.1>` 处，获得 Statement 和 BatchResult 对象。
+  - 【重要】`<2.2>` 处，调用 `Statement#executeBatch()` 方法，批量执行。执行完成后，将结果赋值到 `BatchResult.updateCounts` 中。
+  - `<2.3>` 处，处理主键生成。详细解析，见 [《精尽 MyBatis 源码分析 —— SQL 执行（三）之 KeyGenerator》](http://svip.iocoder.cn/MyBatis/executor-3) 。
+  - `<2.4>` 处，调用 `#closeStatement(stmt)` 方法，关闭 Statement 对象。
+  - `<2.5>` 处，添加到结果集。
+
+- `<3.1>` 处，关闭 `Statement` 们。
+
+- `<3.2>` 处，置空 `currentSql`、`statementList`、`batchResultList` 属性。
+
+## 6.5 doQuery
+
+```
+// BatchExecutor.java
+
+@Override
+public <E> List<E> doQuery(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql)
+        throws SQLException {
+    Statement stmt = null;
+    try {
+        // <1> 刷入批处理语句
+        flushStatements();
+        Configuration configuration = ms.getConfiguration();
+        // 创建 StatementHandler 对象
+        StatementHandler handler = configuration.newStatementHandler(wrapper, ms, parameterObject, rowBounds, resultHandler, boundSql);
+        // 获得 Connection 对象
+        Connection connection = getConnection(ms.getStatementLog());
+        // 创建 Statement 或 PrepareStatement 对象
+        stmt = handler.prepare(connection, transaction.getTimeout());
+        // 设置 SQL 上的参数，例如 PrepareStatement 对象上的占位符
+        handler.parameterize(stmt);
+        // 执行 StatementHandler  ，进行读操作
+        return handler.query(stmt, resultHandler);
+    } finally {
+        // 关闭 StatementHandler 对象
+        closeStatement(stmt);
+    }
+}
+```
+
+- 和 SimpleExecutor 的该方法，逻辑差不多。差别在于 `<1>` 处，发生查询之前，先调用 `#flushStatements()` 方法，刷入批处理语句。
+
+## 6.6 doQueryCursor
+
+```
+// BatchExecutor.java
+
+@Override
+protected <E> Cursor<E> doQueryCursor(MappedStatement ms, Object parameter, RowBounds rowBounds, BoundSql boundSql) throws SQLException {
+    // <1> 刷入批处理语句
+    flushStatements();
+    Configuration configuration = ms.getConfiguration();
+    // 创建 StatementHandler 对象
+    StatementHandler handler = configuration.newStatementHandler(wrapper, ms, parameter, rowBounds, null, boundSql);
+    // 获得 Connection 对象
+    Connection connection = getConnection(ms.getStatementLog());
+    // 创建 Statement 或 PrepareStatement 对象
+    Statement stmt = handler.prepare(connection, transaction.getTimeout());
+    // 设置 Statement ，如果执行完成，则进行自动关闭
+    stmt.closeOnCompletion();
+    // 设置 SQL 上的参数，例如 PrepareStatement 对象上的占位符
+    handler.parameterize(stmt);
+    // 执行 StatementHandler  ，进行读操作
+    return handler.queryCursor(stmt);
+}
+```
+
+- 和 SimpleExecutor 的该方法，逻辑差不多。差别在于 `<1>` 处，发生查询之前，先调用 `#flushStatements()` 方法，刷入批处理语句。
+
+# 7. 二级缓存
+
+在开始看具体源码之间，我们先来理解**二级缓存**的定义：
+
+> FROM 凯伦 [《聊聊MyBatis缓存机制》](https://tech.meituan.com/mybatis_cache.html)
+>
+> 在上文中提到的一级缓存中，**其最大的共享范围就是一个 SqlSession 内部**，如果多个 SqlSession 之间需要共享缓存，则需要使用到**二级缓存**。开启二级缓存后，会使用 CachingExecutor 装饰 Executor ，进入一级缓存的查询流程前，先在 CachingExecutor 进行二级缓存的查询，具体的工作流程如下所示。
+>
+> [![大体流程](21-mybatis-SQL 执行（一）之 Executor.assets/04.png)](http://static.iocoder.cn/images/MyBatis/2020_02_28/04.png)大体流程
+
+- 那么，二级缓存，反应到具体代码里，是长什么样的呢？我们来打开 MappedStatement 类，代码如下：
+
+  ```
+  // MappedStatement.java
+  
+  /**
+   * Cache 对象
+   */
+  private Cache cache;
+  ```
+
+  - 就是 `cache` 属性。在前面的文章中，我们已经看到，每个 XML Mapper 或 Mapper 接口的每个 SQL 操作声明，对应一个 MappedStatement 对象。通过 `@CacheNamespace` 或 `<cache />` 来声明，创建其所使用的 Cache 对象；也可以通过 `@CacheNamespaceRef` 或 `<cache-ref />` 来声明，使用指定 Namespace 的 Cache 对象。
+
+  - 最终在 Configuration 类中的体现，代码如下：
+
+    ```
+    // Configuration.java
+    
+    /**
+     * Cache 对象集合
+     *
+     * KEY：命名空间 namespace
+     */
+    protected final Map<String, Cache> caches = new StrictMap<>("Caches collection");
+    ```
+
+    - 一个 KEY 为 Namespace 的 Map 对象。
+
+  - 可能上述描述比较绕口，胖友好好理解下。
+
+- 通过在 `mybatis-config.xml` 中，配置如下开启二级缓存功能：
+
+  ```
+  <setting name="cacheEnabled" value="true"/>
+  ```
+
+## 7.1 CachingExecutor
+
+`org.apache.ibatis.executor.CachingExecutor` ，实现 Executor 接口，支持**二级缓存**的 Executor 的实现类。
+
+### 7.1.1 构造方法
+
+```
+// CachingExecutor.java
+
+/**
+ * 被委托的 Executor 对象
+ */
+private final Executor delegate;
+/**
+ * TransactionalCacheManager 对象
+ */
+private final TransactionalCacheManager tcm = new TransactionalCacheManager();
+
+public CachingExecutor(Executor delegate) {
+    // <1>
+    this.delegate = delegate;
+    // <2> 设置 delegate 被当前执行器所包装
+    delegate.setExecutorWrapper(this);
+}
+```
+
+- `tcm` 属性，TransactionalCacheManager 对象，支持事务的缓存管理器。因为**二级缓存**是支持跨 Session 进行共享，此处需要考虑事务，**那么，必然需要做到事务提交时，才将当前事务中查询时产生的缓存，同步到二级缓存中**。这个功能，就通过 TransactionalCacheManager 来实现。
+- `<1>` 处，设置 `delegate` 属性，为被委托的 Executor 对象。
+- `<2>` 处，调用 `delegate` 属性的 `#setExecutorWrapper(Executor executor)` 方法，设置 `delegate` 被**当前执行器**所包装。
+
+### 7.1.2 直接调用委托方法
+
+CachingExecutor 的如下方法，具体的实现代码，是直接调用委托执行器 `delegate` 的对应的方法。代码如下：
+
+```
+// CachingExecutor.java
+
+public Transaction getTransaction() { return delegate.getTransaction(); }
+
+@Override
+public boolean isClosed() { return delegate.isClosed(); }
+
+@Override
+public List<BatchResult> flushStatements() throws SQLException { return delegate.flushStatements(); }
+
+@Override
+public CacheKey createCacheKey(MappedStatement ms, Object parameterObject, RowBounds rowBounds, BoundSql boundSql) { return delegate.createCacheKey(ms, parameterObject, rowBounds, boundSql); }
+
+@Override
+public boolean isCached(MappedStatement ms, CacheKey key) { return delegate.isCached(ms, key); }
+
+@Override
+public void deferLoad(MappedStatement ms, MetaObject resultObject, String property, CacheKey key, Class<?> targetType) { delegate.deferLoad(ms, resultObject, property, key, targetType); }
+
+@Override
+public void clearLocalCache() { delegate.clearLocalCache(); }
+```
+
+### 7.1.3 query
+
+```
+// CachingExecutor.java
+
+@Override
+public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler) throws SQLException {
+    // 获得 BoundSql 对象
+    BoundSql boundSql = ms.getBoundSql(parameterObject);
+    // 创建 CacheKey 对象
+    CacheKey key = createCacheKey(ms, parameterObject, rowBounds, boundSql);
+    // 查询
+    return query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
+}
+
+@Override
+public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql)
+        throws SQLException {
+    // <1> 
+    Cache cache = ms.getCache();
+    if (cache != null) { // <2> 
+        // <2.1> 如果需要清空缓存，则进行清空
+        flushCacheIfRequired(ms);
+        if (ms.isUseCache() && resultHandler == null) { // <2.2>
+            // 暂时忽略，存储过程相关
+            ensureNoOutParams(ms, boundSql);
+            @SuppressWarnings("unchecked")
+            // <2.3> 从二级缓存中，获取结果
+            List<E> list = (List<E>) tcm.getObject(cache, key);
+            if (list == null) {
+                // <2.4.1> 如果不存在，则从数据库中查询
+                list = delegate.query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
+                // <2.4.2> 缓存结果到二级缓存中
+                tcm.putObject(cache, key, list); // issue #578 and #116
+            }
+            // <2.5> 如果存在，则直接返回结果
+            return list;
+        }
+    }
+    // <3> 不使用缓存，则从数据库中查询
+    return delegate.query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
+}
+```
+
+- `<1>` 处，调用 `MappedStatement#getCache()` 方法，获得 Cache 对象，即当前 MappedStatement 对象的**二级缓存**。
+
+- `<3>` 处，如果**没有** Cache 对象，说明该 MappedStatement 对象，未设置**二级缓存**，则调用 `delegate` 属性的 `#query(...)` 方法，直接从数据库中查询。
+
+- `<2>` 处，如果**有** Cache 对象，说明该 MappedStatement 对象，有设置**二级缓存**：
+
+  - `<2.1>` 处，调用 `#flushCacheIfRequired(MappedStatement ms)` 方法，如果需要清空缓存，则进行清空。代码如下：
+
+    ```
+    // CachingExecutor.java
+    
+    private void flushCacheIfRequired(MappedStatement ms) {
+        Cache cache = ms.getCache();
+        if (cache != null && ms.isFlushCacheRequired()) { // 是否需要清空缓存
+            tcm.clear(cache);
+        }
+    }
+    ```
+
+    - 通过 `@Options(flushCache = Options.FlushCachePolicy.TRUE)` 或 `<select flushCache="true">` 方式，开启需要清空缓存。
+    - 调用 `TransactionalCache#clear()` 方法，清空缓存。**注意**，此**时**清空的仅仅，当前事务中查询数据产生的缓存。而**真正**的清空，在事务的提交时。这是为什么呢？还是因为**二级缓存**是跨 Session 共享缓存，在事务尚未结束时，不能对二级缓存做任何修改。😈 可能有点绕，胖友好好理解。
+
+  - `<2.2>` 处，当 `MappedStatement#isUseCache()` 方法，返回 `true` 时，才使用二级缓存。默认开启。可通过 `@Options(useCache = false)` 或 `<select useCache="false">` 方法，关闭。
+
+  - `<2.3>` 处，调用 `TransactionalCacheManager#getObject(Cache cache, CacheKey key)` 方法，从二级缓存中，获取结果。
+
+  - 如果不存在缓存
+
+    - `<2.4.1>` 处，调用 `delegate` 属性的 `#query(...)` 方法，再从数据库中查询。
+    - `<2.4.2>` 处，调用 `TransactionalCacheManager#put(Cache cache, CacheKey key, Object value)` 方法，缓存结果到二级缓存中。😈 当然，正如上文所言，实际上，此处结果还没添加到二级缓存中。那具体是怎么样的呢？答案见 TransactionalCache 。
+
+  - 如果存在缓存
+
+    - `<2.5>` 处，如果存在，则直接返回结果。
+
+### 7.1.4 queryCursor
+
+```
+// CachingExecutor.java
+
+@Override
+public <E> Cursor<E> queryCursor(MappedStatement ms, Object parameter, RowBounds rowBounds) throws SQLException {
+    // 如果需要清空缓存，则进行清空
+    flushCacheIfRequired(ms);
+    // 执行 delegate 对应的方法
+    return delegate.queryCursor(ms, parameter, rowBounds);
+}
+```
+
+- 无法开启二级缓存，所以只好调用 `delegate` 对应的方法。
+
+### 7.1.5 update
+
+```
+// CachingExecutor.java
+
+@Override
+public int update(MappedStatement ms, Object parameterObject) throws SQLException {
+    // 如果需要清空缓存，则进行清空
+    flushCacheIfRequired(ms);
+    // 执行 delegate 对应的方法
+    return delegate.update(ms, parameterObject);
+}
+```
+
+### 7.1.6 commit
+
+```
+// CachingExecutor.java
+
+@Override
+public void commit(boolean required) throws SQLException {
+    // 执行 delegate 对应的方法
+    delegate.commit(required);
+    // 提交 TransactionalCacheManager
+    tcm.commit();
+}
+```
+
+- `delegate` 和 `tcm` 先后提交。
+
+### 7.1.7 rollback
+
+```
+// CachingExecutor.java
+
+@Override
+public void rollback(boolean required) throws SQLException {
+    try {
+        // 执行 delegate 对应的方法
+        delegate.rollback(required);
+    } finally {
+        if (required) {
+            // 回滚 TransactionalCacheManager
+            tcm.rollback();
+        }
+    }
+}
+```
+
+- `delegate` 和 `tcm` 先后回滚。
+
+### 7.1.8 close
+
+```
+// CachingExecutor.java
+
+@Override
+public void close(boolean forceRollback) {
+    try {
+        //issues #499, #524 and #573
+        // 如果强制回滚，则回滚 TransactionalCacheManager
+        if (forceRollback) {
+            tcm.rollback();
+        // 如果强制提交，则提交 TransactionalCacheManager
+        } else {
+            tcm.commit();
+        }
+    } finally {
+        // 执行 delegate 对应的方法
+        delegate.close(forceRollback);
+    }
+}
+```
+
+- 根据 `forceRollback` 属性，进行 `tcm` 和 `delegate` 对应的操作。
+
+## 7.2 TransactionalCacheManager
+
+`org.apache.ibatis.cache.TransactionalCacheManager` ，TransactionalCache 管理器。
+
+### 7.2.1 构造方法
+
+```
+// TransactionalCacheManager.java
+
+/**
+ * Cache 和 TransactionalCache 的映射
+ */
+private final Map<Cache, TransactionalCache> transactionalCaches = new HashMap<>();
+```
+
+- 我们可以看到，`transactionalCaches` 是一个使用 Cache 作为 KEY ，TransactionalCache 作为 VALUE 的 Map 对象。
+
+- 为什么是一个 Map 对象呢？因为在一次的事务过程中，可能有多个不同的 MappedStatement 操作，而它们可能对应多个 Cache 对象。
+
+- TransactionalCache 是怎么创建的呢？答案在 `#getTransactionalCache(Cache cache)` 方法，代码如下：
+
+  ```
+  // TransactionalCacheManager.java
+  
+  private TransactionalCache getTransactionalCache(Cache cache) {
+      return transactionalCaches.computeIfAbsent(cache, TransactionalCache::new);
+  }
+  ```
+
+  - 优先，从 `transactionalCaches` 获得 Cache 对象，对应的 TransactionalCache 对象。
+  - 如果不存在，则创建一个 TransactionalCache 对象，并添加到 `transactionalCaches` 中。
+
+### 7.2.2 putObject
+
+`#putObject(Cache cache, CacheKey key, Object value)` 方法，添加 Cache + KV ，到缓存中。代码如下：
+
+```
+// TransactionalCacheManager.java
+
+public void putObject(Cache cache, CacheKey key, Object value) {
+    // 首先，获得 Cache 对应的 TransactionalCache 对象
+    // 然后，添加 KV 到 TransactionalCache 对象中
+    getTransactionalCache(cache).putObject(key, value);
+}
+```
+
+### 7.2.3 getObject
+
+`#getObject(Cache cache, CacheKey key)` 方法，获得缓存中，指定 Cache + K 的值。代码如下：
+
+```
+// TransactionalCacheManager.java
+
+public Object getObject(Cache cache, CacheKey key) {
+    // 首先，获得 Cache 对应的 TransactionalCache 对象
+    // 然后从 TransactionalCache 对象中，获得 key 对应的值
+    return getTransactionalCache(cache).getObject(key);
+}
+```
+
+### 7.2.4 clear
+
+`#clear()` 方法，清空缓存。代码如下：
+
+```
+// TransactionalCacheManager.java
+
+public void clear(Cache cache) {
+    getTransactionalCache(cache).clear();
+}
+```
+
+### 7.2.5 commit
+
+`#commit()` 方法，提交所有 TransactionalCache 。代码如下：
+
+```
+// TransactionalCacheManager.java
+
+public void commit() {
+    for (TransactionalCache txCache : transactionalCaches.values()) {
+        txCache.commit();
+    }
+}
+```
+
+- 通过调用该方法，TransactionalCache 存储的当前事务的缓存，会同步到其对应的 Cache 对象。
+
+### 7.2.6 rollback
+
+`#rollback()` 方法，回滚所有 TransactionalCache 。代码如下：
+
+```
+// TransactionalCacheManager.java
+
+public void rollback() {
+    for (TransactionalCache txCache : transactionalCaches.values()) {
+        txCache.rollback();
+    }
+}
+```
+
+## 7.3 TransactionalCache
+
+`org.apache.ibatis.cache.decorators.TransactionalCache` ，实现 Cache 接口，支持事务的 Cache 实现类，主要用于二级缓存中。英语比较好的胖友，可以看看如下注释：
+
+> This class holds all cache entries that are to be added to the 2nd level cache during a Session.
+> Entries are sent to the cache when commit is called or discarded if the Session is rolled back.
+> Blocking cache support has been added. Therefore any get() that returns a cache miss
+> will be followed by a put() so any lock associated with the key can be released.
+
+### 7.3.1 构造方法
+
+```
+// TransactionalCache.java
+
+/**
+ * 委托的 Cache 对象。
+ *
+ * 实际上，就是二级缓存 Cache 对象。
+ */
+private final Cache delegate;
+/**
+ * 提交时，清空 {@link #delegate}
+ *
+ * 初始时，该值为 false
+ * 清理后{@link #clear()} 时，该值为 true ，表示持续处于清空状态
+ */
+private boolean clearOnCommit;
+/**
+ * 待提交的 KV 映射
+ */
+private final Map<Object, Object> entriesToAddOnCommit;
+/**
+ * 查找不到的 KEY 集合
+ */
+private final Set<Object> entriesMissedInCache;
+
+public TransactionalCache(Cache delegate) {
+    this.delegate = delegate;
+    this.clearOnCommit = false;
+    this.entriesToAddOnCommit = new HashMap<>();
+    this.entriesMissedInCache = new HashSet<>();
+}
+```
+
+- 胖友认真看下每个变量上的注释。
+- 在事务未提交时，`entriesToAddOnCommit` 属性，会暂存当前事务新产生的缓存 KV 对。
+- 在事务提交时，`entriesToAddOnCommit` 属性，会同步到二级缓存 `delegate` 中。
+
+### 7.3.2 getObject
+
+```
+// TransactionalCache.java
+
+@Override
+public Object getObject(Object key) {
+    // issue #116
+    // <1> 从 delegate 中获取 key 对应的 value
+    Object object = delegate.getObject(key);
+    // <2> 如果不存在，则添加到 entriesMissedInCache 中
+    if (object == null) {
+        entriesMissedInCache.add(key);
+    }
+    // issue #146
+    // <3> 如果 clearOnCommit 为 true ，表示处于持续清空状态，则返回 null
+    if (clearOnCommit) {
+        return null;
+    // <4> 返回 value
+    } else {
+        return object;
+    }
+}
+```
+
+- `<1>` 处，调用 `delegate` 的 `#getObject(Object key)` 方法，从 `delegate` 中获取 `key` 对应的 value 。
+- `<2>` 处，如果不存在，则添加到 `entriesMissedInCache` 中。这是个神奇的逻辑？？？答案见 `commit()` 和 `#rollback()` 方法。
+- `<3>` 处，如果 `clearOnCommit` 为 `true` ，表示处于持续清空状态，则返回 `null` 。因为在事务未结束前，我们执行的**清空缓存**操作不好同步到 `delegate` 中，所以只好通过 `clearOnCommit` 来标记处于清空状态。那么，如果处于该状态，自然就不能返回 `delegate` 中查找的结果。
+- `<4>` 处，返回 value 。
+
+### 7.3.3 putObject
+
+`#putObject(Object key, Object object)` 方法，暂存 KV 到 `entriesToAddOnCommit` 中。代码如下：
+
+```
+// TransactionalCache.java
+
+@Override
+public void putObject(Object key, Object object) {
+    // 暂存 KV 到 entriesToAddOnCommit 中
+    entriesToAddOnCommit.put(key, object);
+}
+```
+
+### 7.3.4 removeObject
+
+```
+// TransactionalCache.java
+
+public Object removeObject(Object key) {
+    return null;
+}
+```
+
+- 不太明白为什么是这样的实现。不过目前也暂时不存在调用该方法的情况。暂时忽略。
+
+### 7.3.5 clear
+
+`#clear()` 方法，清空缓存。代码如下：
+
+```
+// TransactionalCache.java
+
+@Override
+public void clear() {
+    // <1> 标记 clearOnCommit 为 true
+    clearOnCommit = true;
+    // <2> 清空 entriesToAddOnCommit
+    entriesToAddOnCommit.clear();
+}
+```
+
+- `<1>` 处，标记 `clearOnCommit` 为 `true` 。
+- `<2>` 处，清空 `entriesToAddOnCommit` 。
+- 该方法，不会清空 `delegate` 的缓存。真正的清空，在事务提交时。
+
+### 7.3.6 commit
+
+`#commit()` 方法，提交事务。**重头戏**，代码如下：
+
+```
+// TransactionalCache.java
+
+public void commit() {
+    // <1> 如果 clearOnCommit 为 true ，则清空 delegate 缓存
+    if (clearOnCommit) {
+        delegate.clear();
+    }
+    // 将 entriesToAddOnCommit、entriesMissedInCache 刷入 delegate 中
+    flushPendingEntries();
+    // 重置
+    reset();
+}
+```
+
+- `<1>` 处，如果 `clearOnCommit` 为 `true` ，则清空 `delegate` 缓存。
+
+- `<2>` 处，调用 `#flushPendingEntries()` 方法，将 `entriesToAddOnCommit`、`entriesMissedInCache` 同步到 `delegate` 中。代码如下：
+
+  ```
+  // TransactionalCache.java
+  
+  private void flushPendingEntries() {
+      // 将 entriesToAddOnCommit 刷入 delegate 中
+      for (Map.Entry<Object, Object> entry : entriesToAddOnCommit.entrySet()) {
+          delegate.putObject(entry.getKey(), entry.getValue());
+      }
+      // 将 entriesMissedInCache 刷入 delegate 中
+      for (Object entry : entriesMissedInCache) {
+          if (!entriesToAddOnCommit.containsKey(entry)) {
+              delegate.putObject(entry, null);
+          }
+      }
+  }
+  ```
+
+  - 在看这段代码时，笔者一直疑惑 `entriesMissedInCache` 同步到 `delegate` 中，会不会存在问题。因为当前事务未查找到，不代表其他事务恰好实际能查到。这样，岂不是会将缓存错误的置空。后来一想，缓存即使真的被错误的置空，最多也就多从数据库中查询一次罢了。😈
+
+- `<3>` 处，调用 `#reset()` 方法，重置对象。代码如下：
+
+  ```
+  // TransactionalCache.java
+  
+  private void reset() {
+      // 重置 clearOnCommit 为 false
+      clearOnCommit = false;
+      // 清空 entriesToAddOnCommit、entriesMissedInCache
+      entriesToAddOnCommit.clear();
+      entriesMissedInCache.clear();
+  }
+  ```
+
+  - 因为，一个 Executor 可以提交多次事务，而 TransactionalCache 需要被重用，那么就需要重置回初始状态。
+
+### 7.3.7 rollback
+
+`#rollback()` 方法，回滚事务。代码如下：
+
+```
+// TransactionalCache.java
+
+public void rollback() {
+    // <1> 从 delegate 移除出 entriesMissedInCache
+    unlockMissedEntries();
+    // <2> 重置
+    reset();
+}
+```
+
+- `<1>` 处，调用 `#unlockMissedEntries()` 方法，将 `entriesMissedInCache` 同步到 `delegate` 中。代码如下：
+
+  ```
+  // TransactionalCache.java
+  
+  private void unlockMissedEntries() {
+      for (Object entry : entriesMissedInCache) {
+          try {
+              delegate.removeObject(entry);
+          } catch (Exception e) {
+              log.warn("Unexpected exception while notifiying a rollback to the cache adapter."
+                      + "Consider upgrading your cache adapter to the latest version.  Cause: " + e);
+          }
+      }
+  }
+  ```
+
+  - 即使事务回滚，也不妨碍在事务的执行过程中，发现 `entriesMissedInCache` 不存在对应的缓存。
+
+- `<2>` 处，调用 `#reset()` 方法，重置对象。
+
+# 8. 创建 Executor 对象
+
+在上面的文章中，我们已经看了各种 Executor 的实现代码。那么，Executor 对象究竟在 MyBatis 中，是如何被创建的呢？Configuration 类中，提供 `#newExecutor(Transaction transaction, ExecutorType executorType)` 方法，代码如下：
+
+```
+// Configuration.java
+
+/**
+ * 创建 Executor 对象
+ *
+ * @param transaction 事务对象
+ * @param executorType 执行器类型
+ * @return Executor 对象
+ */
+public Executor newExecutor(Transaction transaction, ExecutorType executorType) {
+    // <1> 获得执行器类型
+    executorType = executorType == null ? defaultExecutorType : executorType; // 使用默认
+    executorType = executorType == null ? ExecutorType.SIMPLE : executorType; // 使用 ExecutorType.SIMPLE
+    // <2> 创建对应实现的 Executor 对象
+    Executor executor;
+    if (ExecutorType.BATCH == executorType) {
+        executor = new BatchExecutor(this, transaction);
+    } else if (ExecutorType.REUSE == executorType) {
+        executor = new ReuseExecutor(this, transaction);
+    } else {
+        executor = new SimpleExecutor(this, transaction);
+    }
+    // <3> 如果开启缓存，创建 CachingExecutor 对象，进行包装
+    if (cacheEnabled) {
+        executor = new CachingExecutor(executor);
+    }
+    // <4> 应用插件
+    executor = (Executor) interceptorChain.pluginAll(executor);
+    return executor;
+}
+```
+
+- `<1>` 处，获得执行器类型。可以通过在 `mybatis-config.xml` 配置文件，如下：
+
+  ```
+  // value 有三种类型：SIMPLE REUSE BATCH
+  <setting name="defaultExecutorType" value="" />
+  ```
+
+- `org.apache.ibatis.session.ExecutorType` ，执行器类型。代码如下：
+
+  ```
+  // ExecutorType.java
+  
+  public enum ExecutorType {
+  
+      /**
+       * {@link org.apache.ibatis.executor.SimpleExecutor}
+       */
+      SIMPLE,
+      /**
+       * {@link org.apache.ibatis.executor.ReuseExecutor}
+       */
+      REUSE,
+      /**
+       * {@link org.apache.ibatis.executor.BatchExecutor}
+       */
+      BATCH
+  
+  }
+  ```
+
+- `<2>` 处，创建对应实现的 Executor 对象。默认为 SimpleExecutor 对象。
+
+- `<3>` 处，如果开启缓存，创建 CachingExecutor 对象，进行包装。
+
+- `<4>` 处，应用插件。关于**插件**，我们在后续的文章中，详细解析。
+
+# 9. ClosedExecutor
+
+> 老艿艿：写到凌晨 1 点多，以为已经写完了，结果发现….
+
+在 ResultLoaderMap 类中，有一个 ClosedExecutor 内部静态类，继承 BaseExecutor 抽象类，已经关闭的 Executor 实现类。代码如下：
+
+```
+// ResultLoaderMap.java
+
+private static final class ClosedExecutor extends BaseExecutor {
+
+    public ClosedExecutor() {
+        super(null, null);
+    }
+
+    @Override
+    public boolean isClosed() {
+        return true;
+    }
+
+    @Override
+    protected int doUpdate(MappedStatement ms, Object parameter) throws SQLException {
+        throw new UnsupportedOperationException("Not supported.");
+    }
+
+    @Override
+    protected List<BatchResult> doFlushStatements(boolean isRollback) throws SQLException {
+        throw new UnsupportedOperationException("Not supported.");
+    }
+
+    @Override
+    protected <E> List<E> doQuery(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql) throws SQLException {
+        throw new UnsupportedOperationException("Not supported.");
+    }
+
+    @Override
+    protected <E> Cursor<E> doQueryCursor(MappedStatement ms, Object parameter, RowBounds rowBounds, BoundSql boundSql) throws SQLException {
+        throw new UnsupportedOperationException("Not supported.");
+    }
+}
+```
+
+- 仅仅在 ResultLoaderMap 中，作为一个“空”的 Executor 对象。没有什么特殊的意义和用途。
+
+# 10. ErrorContext
+
+`org.apache.ibatis.executor.ErrorContext` ，错误上下文，负责记录错误日志。代码比较简单，也蛮有意思，胖友可以自己研究研究。
+
+另外，也可以参考下 [《Mybatis 源码中获取到的错误日志灵感》](https://www.jianshu.com/p/2af47a3e473c) 。
+
+# 666. 彩蛋
+
+困的来，写到大半夜 1 点多。回家偷懒了下，果然不行~~~
+
+参考和推荐如下文章：
+
+- 凯伦 [《聊聊MyBatis缓存机制》](https://tech.meituan.com/mybatis_cache.html)
+- 祖大俊 [《Mybatis3.3.x技术内幕（四）：五鼠闹东京之执行器Executor设计原本》](https://my.oschina.net/zudajun/blog/667214)
+- 祖大俊 [《Mybatis3.3.x技术内幕（五）：Executor之doFlushStatements()》](https://my.oschina.net/zudajun/blog/668323)
+- 祖大俊 [《Mybatis3.4.x技术内幕（二十二）：Mybatis一级、二级缓存原理分析》](https://my.oschina.net/zudajun/blog/747499)
+- 徐郡明 [《MyBatis 技术内幕》](https://item.jd.com/12125531.html) 的 [「3.6 Executor](https://svip.iocoder.cn/MyBatis/executor-1/#) 小节
\ No newline at end of file
diff --git a/mybatis/22-mybatis-SQL 执行（二）之 StatementHandler.assets/01.png b/mybatis/22-mybatis-SQL 执行（二）之 StatementHandler.assets/01.png
new file mode 100644
index 0000000..070dbe4
Binary files /dev/null and b/mybatis/22-mybatis-SQL 执行（二）之 StatementHandler.assets/01.png differ
diff --git a/mybatis/22-mybatis-SQL 执行（二）之 StatementHandler.assets/02.png b/mybatis/22-mybatis-SQL 执行（二）之 StatementHandler.assets/02.png
new file mode 100644
index 0000000..f4010ac
Binary files /dev/null and b/mybatis/22-mybatis-SQL 执行（二）之 StatementHandler.assets/02.png differ
diff --git a/mybatis/22-mybatis-SQL 执行（二）之 StatementHandler.assets/03.png b/mybatis/22-mybatis-SQL 执行（二）之 StatementHandler.assets/03.png
new file mode 100644
index 0000000..6da6dfc
Binary files /dev/null and b/mybatis/22-mybatis-SQL 执行（二）之 StatementHandler.assets/03.png differ
diff --git a/mybatis/22-mybatis-SQL 执行（二）之 StatementHandler.md b/mybatis/22-mybatis-SQL 执行（二）之 StatementHandler.md
new file mode 100644
index 0000000..91ba6b4
--- /dev/null
+++ b/mybatis/22-mybatis-SQL 执行（二）之 StatementHandler.md	
@@ -0,0 +1,670 @@
+# 精尽 MyBatis 源码分析 —— SQL 执行（二）之 StatementHandler
+
+# 1. 概述
+
+本文，我们来分享 SQL 执行的第二部分，`statement` 包。整体类图如下：[![类图](22-mybatis-SQL 执行（二）之 StatementHandler.assets/01.png)](http://static.iocoder.cn/images/MyBatis/2020_03_03/01.png)类图
+
+- 我们可以看到，整体是以 StatementHandler 为核心。所以，本文主要会看到的就是 StatementHandler 对 JDBC Statement 的各种操作。
+
+而 StatementHandler 在整个 SQL 执行过程中，所处的位置如下：[![整体流程](22-mybatis-SQL 执行（二）之 StatementHandler.assets/02.png)](http://static.iocoder.cn/images/MyBatis/2020_03_03/02.png)整体流程
+
+# 2. StatementHandler
+
+`org.apache.ibatis.executor.statement.StatementHandler` ，Statement 处理器，其中 Statement 包含 `java.sql.Statement`、`java.sql.PreparedStatement`、`java.sql.CallableStatement` 三种。代码如下：
+
+```
+// StatementHandler.java
+
+public interface StatementHandler {
+
+    /**
+     * 准备操作，可以理解成创建 Statement 对象
+     *
+     * @param connection         Connection 对象
+     * @param transactionTimeout 事务超时时间
+     * @return Statement 对象
+     */
+    Statement prepare(Connection connection, Integer transactionTimeout) throws SQLException;
+
+    /**
+     * 设置 Statement 对象的参数
+     *
+     * @param statement Statement 对象
+     */
+    void parameterize(Statement statement) throws SQLException;
+    
+    /**
+     * 添加 Statement 对象的批量操作
+     *
+     * @param statement Statement 对象
+     */
+    void batch(Statement statement) throws SQLException;
+    /**
+     * 执行写操作
+     *
+     * @param statement Statement 对象
+     * @return 影响的条数
+     */
+    int update(Statement statement) throws SQLException;
+    /**
+     * 执行读操作
+     *
+     * @param statement Statement 对象
+     * @param resultHandler ResultHandler 对象，处理结果
+     * @param <E> 泛型
+     * @return 读取的结果
+     */
+    <E> List<E> query(Statement statement, ResultHandler resultHandler) throws SQLException;
+    /**
+     * 执行读操作，返回 Cursor 对象
+     *
+     * @param statement Statement 对象
+     * @param <E> 泛型
+     * @return Cursor 对象
+     */
+    <E> Cursor<E> queryCursor(Statement statement) throws SQLException;
+
+    /**
+     * @return BoundSql 对象
+     */
+    BoundSql getBoundSql();
+    /**
+     * @return ParameterHandler 对象
+     */
+    ParameterHandler getParameterHandler();
+
+}
+```
+
+- 比较简单，胖友愁一愁。
+
+StatementHandler 有多个子类，如下图所示：[![类图](http://static.iocoder.cn/images/MyBatis/2020_03_03/03.png)](http://static.iocoder.cn/images/MyBatis/2020_03_03/03.png)类图
+
+- 左边的三个实现类，分别对应 `java.sql.Statement`、`java.sql.PreparedStatement`、`java.sql.CallableStatement` 三种不同的实现类。
+- 右边的 RoutingStatementHandler 实现类，负责将不同的 Statement 类型，路由到上述三个实现类上。
+
+下面，我们先看右边的实现类，再看左边的实现类。
+
+# 3. RoutingStatementHandler
+
+`org.apache.ibatis.executor.statement.RoutingStatementHandler` ，实现 StatementHandler 接口，路由的 StatementHandler 对象，根据 Statement 类型，转发到对应的 StatementHandler 实现类中。
+
+## 3.1 构造方法
+
+```
+// RoutingStatementHandler.java
+
+/**
+ * 被委托的 StatementHandler 对象
+ */
+private final StatementHandler delegate;
+
+public RoutingStatementHandler(Executor executor, MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql) {
+    // 根据不同的类型，创建对应的 StatementHandler 实现类
+    switch (ms.getStatementType()) {
+        case STATEMENT:
+            delegate = new SimpleStatementHandler(executor, ms, parameter, rowBounds, resultHandler, boundSql);
+            break;
+        case PREPARED:
+            delegate = new PreparedStatementHandler(executor, ms, parameter, rowBounds, resultHandler, boundSql);
+            break;
+        case CALLABLE:
+            delegate = new CallableStatementHandler(executor, ms, parameter, rowBounds, resultHandler, boundSql);
+            break;
+        default:
+            throw new ExecutorException("Unknown statement type: " + ms.getStatementType());
+    }
+}
+```
+
+- 根据不同的类型，创建对应的 StatementHandler 实现类。
+- 😈 经典的装饰器模式。实际上，有点多余。。。还不如改成工厂模式。
+
+## 3.2 实现方法
+
+所有的实现方法，调用 `delegate` 对应的方法即可。代码如下：
+
+```
+// RoutingStatementHandler.java
+
+@Override
+public Statement prepare(Connection connection, Integer transactionTimeout) throws SQLException {
+    return delegate.prepare(connection, transactionTimeout);
+}
+
+@Override
+public void parameterize(Statement statement) throws SQLException {
+    delegate.parameterize(statement);
+}
+
+@Override
+public void batch(Statement statement) throws SQLException {
+    delegate.batch(statement);
+}
+
+@Override
+public int update(Statement statement) throws SQLException {
+    return delegate.update(statement);
+}
+
+@Override
+public <E> List<E> query(Statement statement, ResultHandler resultHandler) throws SQLException {
+    return delegate.query(statement, resultHandler);
+}
+
+@Override
+public <E> Cursor<E> queryCursor(Statement statement) throws SQLException {
+    return delegate.queryCursor(statement);
+}
+
+@Override
+public BoundSql getBoundSql() {
+    return delegate.getBoundSql();
+}
+
+@Override
+public ParameterHandler getParameterHandler() {
+    return delegate.getParameterHandler();
+}
+```
+
+- 是不是更加觉得，换成工厂模式更合适。
+
+# 4. BaseStatementHandler
+
+`org.apache.ibatis.executor.statement.BaseStatementHandler` ，实现 StatementHandler 接口，StatementHandler 基类，提供骨架方法，从而使子类只要实现指定的几个抽象方法即可。
+
+## 4.1 构造方法
+
+```
+// BaseStatementHandler.java
+
+protected final Configuration configuration;
+protected final ObjectFactory objectFactory;
+protected final TypeHandlerRegistry typeHandlerRegistry;
+protected final ResultSetHandler resultSetHandler;
+protected final ParameterHandler parameterHandler;
+
+protected final Executor executor;
+protected final MappedStatement mappedStatement;
+protected final RowBounds rowBounds;
+
+protected BoundSql boundSql;
+
+protected BaseStatementHandler(Executor executor, MappedStatement mappedStatement, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql) {
+    // 获得 Configuration 对象
+    this.configuration = mappedStatement.getConfiguration();
+
+    this.executor = executor;
+    this.mappedStatement = mappedStatement;
+    this.rowBounds = rowBounds;
+
+    // 获得 TypeHandlerRegistry 和 ObjectFactory 对象
+    this.typeHandlerRegistry = configuration.getTypeHandlerRegistry();
+    this.objectFactory = configuration.getObjectFactory();
+
+    // <1> 如果 boundSql 为空，一般是写类操作，例如：insert、update、delete ，则先获得自增主键，然后再创建 BoundSql 对象
+    if (boundSql == null) { // issue #435, get the key before calculating the statement
+        // <1.1> 获得自增主键
+        generateKeys(parameterObject);
+        // <1.2> 创建 BoundSql 对象
+        boundSql = mappedStatement.getBoundSql(parameterObject);
+    }
+    this.boundSql = boundSql;
+
+    // <2> 创建 ParameterHandler 对象
+    this.parameterHandler = configuration.newParameterHandler(mappedStatement, parameterObject, boundSql);
+    // <3> 创建 ResultSetHandler 对象
+    this.resultSetHandler = configuration.newResultSetHandler(executor, mappedStatement, rowBounds, parameterHandler, resultHandler, boundSql);
+}
+```
+
+- 大体是比较好理解的，我们就看几个点。
+
+- `<1>` 处，如果 `boundSql` 为空：
+
+  - 一般是**写**类操作，例如：`insert`、`update`、`delete` 。代码如下：
+
+    ```
+    // SimpleExecutor.java
+    
+    @Override
+    public int doUpdate(MappedStatement ms, Object parameter) throws SQLException {
+        Statement stmt = null;
+        try {
+            Configuration configuration = ms.getConfiguration();
+            // <x> 创建 StatementHandler 对象
+            StatementHandler handler = configuration.newStatementHandler(this, ms, parameter, RowBounds.DEFAULT, null, null);
+            // 初始化 StatementHandler 对象
+            stmt = prepareStatement(handler, ms.getStatementLog());
+            // 执行 StatementHandler ，进行写操作
+            return handler.update(stmt);
+        } finally {
+            // 关闭 StatementHandler 对象
+            closeStatement(stmt);
+        }
+    }
+    ```
+
+    - `<x>` 处，调用 `Configuration#newStatementHandler(Executor executor, MappedStatement mappedStatement, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql)` 方法，创建 StatementHandler 对象。其中，方法参数 `boundSql` 为 `null` 。
+
+  - `<1.1>` 处，调用 `#generateKeys(Object parameter)` 方法，获得自增主键。代码如下：
+
+    ```
+    // BaseStatementHandler.java
+    
+    protected void generateKeys(Object parameter) {
+        // 获得 KeyGenerator 对象
+        KeyGenerator keyGenerator = mappedStatement.getKeyGenerator();
+        ErrorContext.instance().store();
+        // 前置处理，创建自增编号到 parameter 中
+        keyGenerator.processBefore(executor, mappedStatement, null, parameter);
+        ErrorContext.instance().recall();
+    }
+    ```
+
+    - 通过 KeyGenerator 对象，创建自增编号到 `parameter` 中。😈 详细的解析，见后续的 KeyGenerator 的内容。
+
+  - `<1.2>` 处，调用 `MappedStatement#getBoundSql(Object parameterObject)` 方法，创建 BoundSql 对象。
+
+  - 这个流程，可以调试下 `BindingTest#shouldInsertAuthorWithSelectKeyAndDynamicParams()` 单元测试方法。
+
+- `<2>` 处，调用 `Configuration#newParameterHandler(MappedStatement mappedStatement, Object parameterObject, BoundSql boundSql)` 方法，创建 ParameterHandler 对象。代码如下：
+
+  ```
+  // Configuration.java
+  
+  public ParameterHandler newParameterHandler(MappedStatement mappedStatement, Object parameterObject, BoundSql boundSql) {
+      // 创建 ParameterHandler 对象
+      ParameterHandler parameterHandler = mappedStatement.getLang().createParameterHandler(mappedStatement, parameterObject, boundSql);
+      // 应用插件
+      parameterHandler = (ParameterHandler) interceptorChain.pluginAll(parameterHandler);
+      return parameterHandler;
+  }
+  
+  // XMLLanguageDriver.java
+  
+  @Override
+  public ParameterHandler createParameterHandler(MappedStatement mappedStatement, Object parameterObject, BoundSql boundSql) {
+      // 创建 DefaultParameterHandler 对象
+      return new DefaultParameterHandler(mappedStatement, parameterObject, boundSql);
+  }
+  ```
+
+  - 从代码中，可以看到，创建的是 DefaultParameterHandler 对象。而这个类，在 [《精尽 MyBatis 源码分析 —— SQL 初始化（下）之 SqlSource》](http://svip.iocoder.cn/MyBatis/scripting-2) 的 [「7.1 DefaultParameterHandler」](https://svip.iocoder.cn/MyBatis/executor-2/#) 已经有详细解析啦。
+
+- `<3>` 处，创建 ResultSetHandler 对象。详细解析，见 [《精尽 MyBatis 源码分析 —— SQL 执行（四）之 ResultSetHandler》](http://svip.iocoder.cn/MyBatis/executor-4) 。
+
+## 4.2 prepare
+
+```
+// BaseStatementHandler.java
+
+@Override
+public Statement prepare(Connection connection, Integer transactionTimeout) throws SQLException {
+    ErrorContext.instance().sql(boundSql.getSql());
+    Statement statement = null;
+    try {
+        // <1> 创建 Statement 对象
+        statement = instantiateStatement(connection);
+        // 设置超时时间
+        setStatementTimeout(statement, transactionTimeout);
+        // 设置 fetchSize
+        setFetchSize(statement);
+        return statement;
+    } catch (SQLException e) {
+        // 发生异常，进行关闭
+        closeStatement(statement);
+        throw e;
+    } catch (Exception e) {
+        // 发生异常，进行关闭
+        closeStatement(statement);
+        throw new ExecutorException("Error preparing statement.  Cause: " + e, e);
+    }
+}
+```
+
+- `<1>` 处，创建 `#instantiateStatement(Connection connection)` 方法，创建 Statement 对象。这是一个抽象方法，需要子类去实现。代码如下：
+
+  ```
+  // BaseStatementHandler.java
+  
+  protected abstract Statement instantiateStatement(Connection connection) throws SQLException;
+  ```
+
+- `<2>` 处，调用 `#setStatementTimeout(Statement stmt, Integer transactionTimeout)` 方法，设置超时时间。代码如下：
+
+  ```
+  // BaseStatementHandler.java
+  
+  protected void setStatementTimeout(Statement stmt, Integer transactionTimeout) throws SQLException {
+      // 获得 queryTimeout
+      Integer queryTimeout = null;
+      if (mappedStatement.getTimeout() != null) {
+          queryTimeout = mappedStatement.getTimeout();
+      } else if (configuration.getDefaultStatementTimeout() != null) {
+          queryTimeout = configuration.getDefaultStatementTimeout();
+      }
+      // 设置查询超时时间
+      if (queryTimeout != null) {
+          stmt.setQueryTimeout(queryTimeout);
+      }
+      // 设置事务超时时间
+      StatementUtil.applyTransactionTimeout(stmt, queryTimeout, transactionTimeout);
+  }
+  ```
+
+- `<3>` 处，设置 `fetchSize` 。代码如下：
+
+  ```
+  // BaseStatementHandler.java
+  
+  protected void setFetchSize(Statement stmt) throws SQLException {
+      // 获得 fetchSize 。非空，则进行设置
+      Integer fetchSize = mappedStatement.getFetchSize();
+      if (fetchSize != null) {
+          stmt.setFetchSize(fetchSize);
+          return;
+      }
+      // 获得 defaultFetchSize 。非空，则进行设置
+      Integer defaultFetchSize = configuration.getDefaultFetchSize();
+      if (defaultFetchSize != null) {
+          stmt.setFetchSize(defaultFetchSize);
+      }
+  }
+  ```
+
+  - 感兴趣的胖友，可以看看 [《聊聊jdbc statement的fetchSize》](https://juejin.im/post/5a6757e351882573541c86bb) 和 [《正确使用MySQL JDBC setFetchSize()方法解决JDBC处理大结果集 java.lang.OutOfMemoryError: Java heap space》](https://blog.csdn.net/seven_3306/article/details/9303879) 。
+
+# 5. SimpleStatementHandler
+
+`org.apache.ibatis.executor.statement.SimpleStatementHandler` ，继承 BaseStatementHandler 抽象类，`java.sql.Statement` 的 StatementHandler 实现类。
+
+## 5.1 构造方法
+
+```
+// SimpleStatementHandler.java
+
+public SimpleStatementHandler(Executor executor, MappedStatement mappedStatement, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql) {
+    super(executor, mappedStatement, parameter, rowBounds, resultHandler, boundSql);
+}
+```
+
+## 5.2 instantiateStatement
+
+`#instantiateStatement()` 方法，创建 `java.sql.Statement` 对象。代码如下：
+
+```
+// SimpleStatementHandler.java
+
+@Override
+protected Statement instantiateStatement(Connection connection) throws SQLException {
+    if (mappedStatement.getResultSetType() == ResultSetType.DEFAULT) {
+        return connection.createStatement();
+    } else {
+        return connection.createStatement(mappedStatement.getResultSetType().getValue(), ResultSet.CONCUR_READ_ONLY);
+    }
+}
+```
+
+## 5.3 parameterize
+
+```
+// SimpleStatementHandler.java
+
+@Override
+public void parameterize(Statement statement) throws SQLException {
+    // N/A
+}
+```
+
+- 空，因为无需做占位符参数的处理。
+
+## 5.4 query
+
+```
+// SimpleStatementHandler.java
+
+@Override
+public <E> List<E> query(Statement statement, ResultHandler resultHandler) throws SQLException {
+    String sql = boundSql.getSql();
+    // <1> 执行查询
+    statement.execute(sql);
+    // <2> 处理返回结果
+    return resultSetHandler.handleResultSets(statement);
+}
+```
+
+- `<1>` 处，调用 `Statement#execute(String sql)` 方法，执行查询。
+- `<2>` 处，调用 `ResultHandler#handleResultSets(Statement stmt)` 方法，处理返回结果。
+
+## 5.5 queryCursor
+
+```
+// SimpleStatementHandler.java
+
+@Override
+public <E> Cursor<E> queryCursor(Statement statement) throws SQLException {
+    String sql = boundSql.getSql();
+    // <1> 执行查询
+    statement.execute(sql);
+    // <2> 处理返回的 Cursor 结果
+    return resultSetHandler.handleCursorResultSets(statement);
+}
+```
+
+- `<1>` 处，调用 `Statement#execute(String sql)` 方法，执行查询。
+- `<2>` 处，调用 `ResultHandler#handleCursorResultSets(Statement stmt)` 方法，处理返回的 Cursor 结果。
+
+## 5.6 batch
+
+```
+// SimpleStatementHandler.java
+
+@Override
+public void batch(Statement statement) throws SQLException {
+    String sql = boundSql.getSql();
+    // 添加到批处理
+    statement.addBatch(sql);
+}
+```
+
+- 调用 `Statement#addBatch(String sql)` 方法，添加到批处理。
+
+## 5.7 update
+
+```
+// SimpleStatementHandler.java
+
+@Override
+public int update(Statement statement) throws SQLException {
+    String sql = boundSql.getSql();
+    Object parameterObject = boundSql.getParameterObject();
+    KeyGenerator keyGenerator = mappedStatement.getKeyGenerator();
+    int rows;
+    // 如果是 Jdbc3KeyGenerator 类型
+    if (keyGenerator instanceof Jdbc3KeyGenerator) {
+        // <1.1> 执行写操作
+        statement.execute(sql, Statement.RETURN_GENERATED_KEYS);
+        // <2.2> 获得更新数量
+        rows = statement.getUpdateCount();
+        // <1.3> 执行 keyGenerator 的后置处理逻辑
+        keyGenerator.processAfter(executor, mappedStatement, statement, parameterObject);
+    // 如果是 SelectKeyGenerator 类型
+    } else if (keyGenerator instanceof SelectKeyGenerator) {
+        // <2.1> 执行写操作
+        statement.execute(sql);
+        // <2.2> 获得更新数量
+        rows = statement.getUpdateCount();
+        // <2.3> 执行 keyGenerator 的后置处理逻辑
+        keyGenerator.processAfter(executor, mappedStatement, statement, parameterObject);
+    } else {
+        // <3.1> 执行写操作
+        statement.execute(sql);
+        // <3.2> 获得更新数量
+        rows = statement.getUpdateCount();
+    }
+    return rows;
+}
+```
+
+- 根据 `keyGenerator` 的类型，执行的逻辑，略有差异。
+- `<1.1>`、`<1.2>`、`<1.3>` 处，调用 `Statement#execute(String sql, ...)` 方法，执行写操作。其中，`<1.1>` 比较特殊，使用数据自带的自增功能。
+- `<1.2>`、`<2.2>`、`<3.2>` 处，调用 `Statement#getUpdateCount()` 方法，获得更新数量。
+- `<1.3>`、`<2.3>` 处，调用 `KeyGenerator#processAfter(Executor executor, MappedStatement ms, Statement stmt, Object parameter)` 方法，执行 `keyGenerator` 的后置处理逻辑。
+- 虽然有点长，逻辑还是很清晰的。
+
+# 6. PreparedStatementHandler
+
+`org.apache.ibatis.executor.statement.PreparedStatementHandler` ，继承 BaseStatementHandler 抽象类，`java.sql.PreparedStatement` 的 StatementHandler 实现类。
+
+## 6.1 构造方法
+
+```
+// PreparedStatementHandler.java
+
+public PreparedStatementHandler(Executor executor, MappedStatement mappedStatement, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql) {
+    super(executor, mappedStatement, parameter, rowBounds, resultHandler, boundSql);
+}
+```
+
+## 6.2 instantiateStatement
+
+`#instantiateStatement()` 方法，创建 `java.sql.Statement` 对象。代码如下：
+
+```
+// PreparedStatementHandler.java
+
+@Override
+protected Statement instantiateStatement(Connection connection) throws SQLException {
+    String sql = boundSql.getSql();
+    // <1> 处理 Jdbc3KeyGenerator 的情况
+    if (mappedStatement.getKeyGenerator() instanceof Jdbc3KeyGenerator) {
+        String[] keyColumnNames = mappedStatement.getKeyColumns();
+        if (keyColumnNames == null) {
+            return connection.prepareStatement(sql, PreparedStatement.RETURN_GENERATED_KEYS);
+        } else {
+            return connection.prepareStatement(sql, keyColumnNames);
+        }
+    // <2>
+    } else if (mappedStatement.getResultSetType() == ResultSetType.DEFAULT) {
+        return connection.prepareStatement(sql);
+    // <3>
+    } else {
+        return connection.prepareStatement(sql, mappedStatement.getResultSetType().getValue(), ResultSet.CONCUR_READ_ONLY);
+    }
+}
+```
+
+- `<1>` 处，处理 Jdbc3KeyGenerator 的情况。
+- `<2>` + `<3>` 处，和 SimpleStatementHandler 的方式是一致的。
+
+## 6.3 parameterize
+
+```
+// PreparedStatementHandler.java
+
+@Override
+public void parameterize(Statement statement) throws SQLException {
+    parameterHandler.setParameters((PreparedStatement) statement);
+}
+```
+
+- 调用 `ParameterHandler#setParameters(PreparedStatement ps)` 方法，设置 PreparedStatement 的占位符参数。
+
+## 6.4 query
+
+```
+// PreparedStatementHandler.java
+
+@Override
+public <E> List<E> query(Statement statement, ResultHandler resultHandler) throws SQLException {
+    PreparedStatement ps = (PreparedStatement) statement;
+    // 执行查询
+    ps.execute();
+    // 处理返回结果
+    return resultSetHandler.handleResultSets(ps);
+}
+```
+
+## 6.5 queryCursor
+
+```
+// PreparedStatementHandler.java
+
+@Override
+public <E> Cursor<E> queryCursor(Statement statement) throws SQLException {
+    PreparedStatement ps = (PreparedStatement) statement;
+    // 执行查询
+    ps.execute();
+    // 处理返回的 Cursor 结果
+    return resultSetHandler.handleCursorResultSets(ps);
+}
+```
+
+## 6.6 batch
+
+```
+// PreparedStatementHandler.java
+
+@Override
+public void batch(Statement statement) throws SQLException {
+    PreparedStatement ps = (PreparedStatement) statement;
+    // 添加到批处理
+    ps.addBatch();
+}
+```
+
+## 6.7 update
+
+```
+// PreparedStatementHandler.java
+
+@Override
+public int update(Statement statement) throws SQLException {
+    PreparedStatement ps = (PreparedStatement) statement;
+    // 执行写操作
+    ps.execute();
+    int rows = ps.getUpdateCount();
+    // 获得更新数量
+    Object parameterObject = boundSql.getParameterObject();
+    // 执行 keyGenerator 的后置处理逻辑
+    KeyGenerator keyGenerator = mappedStatement.getKeyGenerator();
+    keyGenerator.processAfter(executor, mappedStatement, ps, parameterObject);
+    return rows;
+}
+```
+
+# 7. CallableStatementHandler
+
+`org.apache.ibatis.executor.statement.CallableStatementHandler` ，继承 BaseStatementHandler 抽象类，`java.sql.CallableStatement` 的 StatementHandler 实现类。
+
+因为本系列不分享**存储过程**相关的内容，所以省略。感兴趣的胖友，自己研究哈。
+
+# 8. 创建 StatementHandler 对象
+
+在上面的文章中，我们已经看了各种 StatementHandler 的实现代码。那么，StatementHandler 对象究竟在 MyBatis 中，是如何被创建的呢？Configuration 类中，提供 `#newStatementHandler(Executor executor, MappedStatement mappedStatement, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql)` 方法，代码如下：
+
+```
+// Configuration.java
+
+public StatementHandler newStatementHandler(Executor executor, MappedStatement mappedStatement, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql) {
+    // <1> 创建 RoutingStatementHandler 对象
+    StatementHandler statementHandler = new RoutingStatementHandler(executor, mappedStatement, parameterObject, rowBounds, resultHandler, boundSql);
+    // 应用插件
+    statementHandler = (StatementHandler) interceptorChain.pluginAll(statementHandler);
+    return statementHandler;
+}
+```
+
+- `<1>` 处，创建 RoutingStatementHandler 对象。通过它，自动**路由**到适合的 StatementHandler 实现类。😈 此处一看，更加适合，使用工厂模式。
+- `<2>` 处，应用插件。关于**插件**，我们在后续的文章中，详细解析。
+
+# 666. 彩蛋
+
+比较简单，都是咱们熟悉的 Statement 的方法封装。
+
+参考和推荐如下文章：
+
+- 祖大俊 [《Mybatis3.3.x技术内幕（六）：StatementHandler（Box stop here）》](https://my.oschina.net/zudajun/blog/668378)
+- 徐郡明 [《MyBatis 技术内幕》](https://item.jd.com/12125531.html) 的 [「3.5 StatementHandler](https://svip.iocoder.cn/MyBatis/executor-2/#) 小节
\ No newline at end of file
diff --git a/mybatis/23-mybatis-SQL 执行（三）之 KeyGenerator.assets/01.png b/mybatis/23-mybatis-SQL 执行（三）之 KeyGenerator.assets/01.png
new file mode 100644
index 0000000..dd82c1a
Binary files /dev/null and b/mybatis/23-mybatis-SQL 执行（三）之 KeyGenerator.assets/01.png differ
diff --git a/mybatis/23-mybatis-SQL 执行（三）之 KeyGenerator.md b/mybatis/23-mybatis-SQL 执行（三）之 KeyGenerator.md
new file mode 100644
index 0000000..a030d80
--- /dev/null
+++ b/mybatis/23-mybatis-SQL 执行（三）之 KeyGenerator.md	
@@ -0,0 +1,601 @@
+# 精尽 MyBatis 源码分析 —— SQL 执行（三）之 KeyGenerator
+
+# 1. 概述
+
+本文，我们来分享 SQL 执行的第三部分，`keygen` 包。整体类图如下：[![类图](23-mybatis-SQL 执行（三）之 KeyGenerator.assets/01.png)](http://static.iocoder.cn/images/MyBatis/2020_03_06/01.png)类图
+
+- 我们可以看到，整体是以 KeyGenerator 为核心。所以，本文主要会看到的就是 KeyGenerator 对**自增主键**的获取。
+
+# 2. KeyGenerator
+
+`org.apache.ibatis.executor.keygen.KeyGenerator` ，主键生成器接口。代码如下：
+
+```
+// KeyGenerator.java
+
+public interface KeyGenerator {
+
+    // SQL 执行前
+    void processBefore(Executor executor, MappedStatement ms, Statement stmt, Object parameter);
+
+    // SQL 执行后
+    void processAfter(Executor executor, MappedStatement ms, Statement stmt, Object parameter);
+
+}
+```
+
+- 可在 SQL 执行**之前**或**之后**，进行处理主键的生成。
+
+- 实际上，KeyGenerator 类的命名虽然包含 Generator ，但是目前 MyBatis 默认的 KeyGenerator 实现类，都是基于数据库来实现**主键自增**的功能。
+
+- `parameter` 参数，指的是什么呢？以下面的方法为示例：
+
+  ```
+  @Options(useGeneratedKeys = true, keyProperty = "id")
+  @Insert({"insert into country (countryname,countrycode) values (#{countryname},#{countrycode})"})
+  int insertBean(Country country);
+  ```
+
+  - 上面的，`country` 方法参数，就是一个 `parameter` 参数。
+  - **KeyGenerator 在获取到主键后，会设置回 `parameter` 参数的对应属性**。
+
+KeyGenerator 有三个子类，如下图所示：[![类图](23-mybatis-SQL 执行（三）之 KeyGenerator.assets/01.png)](http://static.iocoder.cn/images/MyBatis/2020_03_06/01.png)类图
+
+- 具体的，我们下面逐小节来分享。
+
+# 3. Jdbc3KeyGenerator
+
+`org.apache.ibatis.executor.keygen.Jdbc3KeyGenerator` ，实现 KeyGenerator 接口，基于 `Statement#getGeneratedKeys()` 方法的 KeyGenerator 实现类，适用于 MySQL、H2 主键生成。
+
+## 3.1 构造方法
+
+```
+// Jdbc3KeyGenerator.java
+
+/**
+ * A shared instance.
+ *
+ * 共享的单例
+ *
+ * @since 3.4.3
+ */
+public static final Jdbc3KeyGenerator INSTANCE = new Jdbc3KeyGenerator();
+```
+
+- 单例。
+
+## 3.2 processBefore
+
+```
+@Override
+public void processBefore(Executor executor, MappedStatement ms, Statement stmt, Object parameter) {
+    // do nothing
+}
+```
+
+- 空实现。因为对于 Jdbc3KeyGenerator 类的主键，是在 SQL 执行后，才生成。
+
+## 3.3 processAfter
+
+```
+// Jdbc3KeyGenerator.java
+
+@Override
+public void processAfter(Executor executor, MappedStatement ms, Statement stmt, Object parameter) {
+    processBatch(ms, stmt, parameter);
+}
+```
+
+- 调用 `#processBatch(Executor executor, MappedStatement ms, Statement stmt, Object parameter)` 方法，处理返回的自增主键。单个 `parameter` 参数，可以认为是批量的一个**特例**。
+
+## 3.4 processBatch
+
+```
+// Jdbc3KeyGenerator.java
+
+public void processBatch(MappedStatement ms, Statement stmt, Object parameter) {
+    // <1> 获得主键属性的配置。如果为空，则直接返回，说明不需要主键
+    final String[] keyProperties = ms.getKeyProperties();
+    if (keyProperties == null || keyProperties.length == 0) {
+        return;
+    }
+    ResultSet rs = null;
+    try {
+        // <2> 获得返回的自增主键
+        rs = stmt.getGeneratedKeys();
+        final Configuration configuration = ms.getConfiguration();
+        if (rs.getMetaData().getColumnCount() >= keyProperties.length) {
+            // <3> 获得唯一的参数对象
+            Object soleParam = getSoleParameter(parameter);
+            if (soleParam != null) {
+                // <3.1> 设置主键们，到参数 soleParam 中
+                assignKeysToParam(configuration, rs, keyProperties, soleParam);
+            } else {
+                // <3.2> 设置主键们，到参数 parameter 中
+                assignKeysToOneOfParams(configuration, rs, keyProperties, (Map<?, ?>) parameter);
+            }
+        }
+    } catch (Exception e) {
+        throw new ExecutorException("Error getting generated key or setting result to parameter object. Cause: " + e, e);
+    } finally {
+        // <4> 关闭 ResultSet 对象
+        if (rs != null) {
+            try {
+                rs.close();
+            } catch (Exception e) {
+                // ignore
+            }
+        }
+    }
+}
+```
+
+- `<1>` 处，获得主键属性的配置。如果为空，则直接返回，说明不需要主键。
+
+- 【重要】`<2>` 处，调用 `Statement#getGeneratedKeys()` 方法，获得返回的自增主键。
+
+- ```
+  <3>
+  ```
+
+   
+
+  处，调用
+
+   
+
+  ```
+  #getSoleParameter(Object parameter)
+  ```
+
+   
+
+  方法，获得唯一的参数对象。详细解析，先跳到
+
+   
+
+  「3.4.1 getSoleParameter」
+
+   
+
+  。
+
+  - `<3.1>` 处，调用 `#assignKeysToParam(...)` 方法，设置主键们，到参数 `soleParam` 中。详细解析，见 [「3.4.2 assignKeysToParam」](https://svip.iocoder.cn/MyBatis/executor-3/#) 。
+  - `<3.2>` 处，调用 `#assignKeysToOneOfParams(...)` 方法，设置主键们，到参数 `parameter` 中。详细解析，见 [「3.4.3 assignKeysToOneOfParams」](https://svip.iocoder.cn/MyBatis/executor-3/#) 。
+
+- `<4>` 处，关闭 ResultSet 对象。
+
+### 3.4.1 getSoleParameter
+
+```
+// Jdbc3KeyGenerator.java
+
+/**
+ * 获得唯一的参数对象
+ *
+ * 如果获得不到唯一的参数对象，则返回 null
+ *
+ * @param parameter 参数对象
+ * @return 唯一的参数对象
+ */
+private Object getSoleParameter(Object parameter) {
+    // <1> 如果非 Map 对象，则直接返回 parameter
+    if (!(parameter instanceof ParamMap || parameter instanceof StrictMap)) {
+        return parameter;
+    }
+    // <3> 如果是 Map 对象，则获取第一个元素的值
+    // <2> 如果有多个元素，则说明获取不到唯一的参数对象，则返回 null
+    Object soleParam = null;
+    for (Object paramValue : ((Map<?, ?>) parameter).values()) {
+        if (soleParam == null) {
+            soleParam = paramValue;
+        } else if (soleParam != paramValue) {
+            soleParam = null;
+            break;
+        }
+    }
+    return soleParam;
+}
+```
+
+- `<1>` 处，如下可以符合这个条件。代码如下：
+
+  ```
+  @Options(useGeneratedKeys = true, keyProperty = "id")
+  @Insert({"insert into country (countryname,countrycode) values (#{country.countryname},#{country.countrycode})"})
+  int insertNamedBean(@Param("country") Country country);
+  ```
+
+- `<2>` 处，如下可以符合这个条件。代码如下：
+
+  ```
+  @Options(useGeneratedKeys = true, keyProperty = "country.id")
+  @Insert({"insert into country (countryname, countrycode) values (#{country.countryname}, #{country.countrycode})"})
+  int insertMultiParams_keyPropertyWithWrongParamName2(@Param("country") Country country,
+                                                       @Param("someId") Integer someId);
+  ```
+
+  - 虽然有 `country` 和 `someId` 参数，但是最终会被封装成一个 `parameter` 参数，类型为 ParamMap 类型。为什么呢？答案在 `ParamNameResolver#getNamedParams(Object[] args)` 方法中。
+  - 如果是这个情况，获得的主键，会设置回 `country` 的 `id` 属性，因为注解上的 `keyProperty = "country.id"` 配置。
+  - 😈 此处比较绕，也相对用的少。
+
+- `<3>` 处，如下可以符合这个条件。代码如下：
+
+  ```
+  @Options(useGeneratedKeys = true, keyProperty = "id")
+  @Insert({"insert into country (countryname, countrycode) values (#{country.countryname}, #{country.countrycode})"})
+  int insertMultiParams_keyPropertyWithWrongParamName3(@Param("country") Country country);
+  ```
+
+  - 相比 `<2>` 的示例，主要是 `keyProperty = "id"` 的修改，和去掉了 `@Param("someId") Integer someId` 参数。
+  - 实际上，这种情况，和 `<1>` 是类似的。
+
+- 三种情况，`<2>` 和 `<3>` 有点复杂，胖友实际上，理解 `<1>` 即可。
+
+### 3.4.2 assignKeysToParam
+
+```
+// Jdbc3KeyGenerator.java
+
+private void assignKeysToParam(final Configuration configuration, ResultSet rs, final String[] keyProperties, Object param)
+        throws SQLException {
+    final TypeHandlerRegistry typeHandlerRegistry = configuration.getTypeHandlerRegistry();
+    final ResultSetMetaData rsmd = rs.getMetaData();
+    // Wrap the parameter in Collection to normalize the logic.
+    // <1> 包装成 Collection 对象
+    Collection<?> paramAsCollection;
+    if (param instanceof Object[]) {
+        paramAsCollection = Arrays.asList((Object[]) param);
+    } else if (!(param instanceof Collection)) {
+        paramAsCollection = Collections.singletonList(param);
+    } else {
+        paramAsCollection = (Collection<?>) param;
+    }
+    TypeHandler<?>[] typeHandlers = null;
+    // <2> 遍历 paramAsCollection 数组
+    for (Object obj : paramAsCollection) {
+        // <2.1> 顺序遍历 rs
+        if (!rs.next()) {
+            break;
+        }
+        // <2.2> 创建 MetaObject 对象
+        MetaObject metaParam = configuration.newMetaObject(obj);
+        // <2.3> 获得 TypeHandler 数组
+        if (typeHandlers == null) {
+            typeHandlers = getTypeHandlers(typeHandlerRegistry, metaParam, keyProperties, rsmd);
+        }
+        // <2.4> 填充主键们
+        populateKeys(rs, metaParam, keyProperties, typeHandlers);
+    }
+}
+```
+
+- `<1>` 处，包装成 Collection 对象。通过这样的方式，使单个 `param` 参数的情况下，可以统一。
+
+- `<2>` 处，遍历 `paramAsCollection` 数组：
+
+  - `<2.1>` 处， 顺序遍历 `rs` ，相当于把当前的 ResultSet 对象的主键们，赋值给 `obj` 对象的对应属性。
+
+  - `<2.2>` 处，创建 MetaObject 对象，实现对 `obj` 对象的属性访问。
+
+  - `<2.3>` 处，调用 `#getTypeHandlers(...)` 方法，获得 TypeHandler 数组。代码如下：
+
+    ```
+    // Jdbc3KeyGenerator.java
+    
+    private TypeHandler<?>[] getTypeHandlers(TypeHandlerRegistry typeHandlerRegistry, MetaObject metaParam, String[] keyProperties, ResultSetMetaData rsmd) throws SQLException {
+        // 获得主键们，对应的每个属性的，对应的 TypeHandler 对象
+        TypeHandler<?>[] typeHandlers = new TypeHandler<?>[keyProperties.length];
+        for (int i = 0; i < keyProperties.length; i++) {
+            if (metaParam.hasSetter(keyProperties[i])) {
+                Class<?> keyPropertyType = metaParam.getSetterType(keyProperties[i]);
+                typeHandlers[i] = typeHandlerRegistry.getTypeHandler(keyPropertyType, JdbcType.forCode(rsmd.getColumnType(i + 1)));
+            } else {
+                throw new ExecutorException("No setter found for the keyProperty '" + keyProperties[i] + "' in '"
+                        + metaParam.getOriginalObject().getClass().getName() + "'.");
+            }
+        }
+        return typeHandlers;
+    }
+    ```
+
+    - x
+
+  - `<2.4>` 处，调用 `#populateKeys(...)` 方法，填充主键们。详细解析，见 [「3.5 populateKeys」](https://svip.iocoder.cn/MyBatis/executor-3/#) 。
+
+### 3.4.3 assignKeysToOneOfParams
+
+```
+// Jdbc3KeyGenerator.java
+
+protected void assignKeysToOneOfParams(final Configuration configuration, ResultSet rs, final String[] keyProperties,
+                                       Map<?, ?> paramMap) throws SQLException {
+    // Assuming 'keyProperty' includes the parameter name. e.g. 'param.id'.
+    // <1> 需要有 `.` 。
+    int firstDot = keyProperties[0].indexOf('.');
+    if (firstDot == -1) {
+        throw new ExecutorException(
+                "Could not determine which parameter to assign generated keys to. "
+                        + "Note that when there are multiple parameters, 'keyProperty' must include the parameter name (e.g. 'param.id'). "
+                        + "Specified key properties are " + ArrayUtil.toString(keyProperties) + " and available parameters are "
+                        + paramMap.keySet());
+    }
+    // 获得真正的参数值
+    String paramName = keyProperties[0].substring(0, firstDot);
+    Object param;
+    if (paramMap.containsKey(paramName)) {
+        param = paramMap.get(paramName);
+    } else {
+        throw new ExecutorException("Could not find parameter '" + paramName + "'. "
+                + "Note that when there are multiple parameters, 'keyProperty' must include the parameter name (e.g. 'param.id'). "
+                + "Specified key properties are " + ArrayUtil.toString(keyProperties) + " and available parameters are "
+                + paramMap.keySet());
+    }
+    // Remove param name from 'keyProperty' string. e.g. 'param.id' -> 'id'
+    // 获得主键的属性的配置
+    String[] modifiedKeyProperties = new String[keyProperties.length];
+    for (int i = 0; i < keyProperties.length; i++) {
+        if (keyProperties[i].charAt(firstDot) == '.' && keyProperties[i].startsWith(paramName)) {
+            modifiedKeyProperties[i] = keyProperties[i].substring(firstDot + 1);
+        } else {
+            throw new ExecutorException("Assigning generated keys to multiple parameters is not supported. "
+                    + "Note that when there are multiple parameters, 'keyProperty' must include the parameter name (e.g. 'param.id'). "
+                    + "Specified key properties are " + ArrayUtil.toString(keyProperties) + " and available parameters are "
+                    + paramMap.keySet());
+        }
+    }
+    // 设置主键们，到参数 param 中
+    assignKeysToParam(configuration, rs, modifiedKeyProperties, param);
+}
+```
+
+- `<1>` 处，需要有 `.` 。例如：`@Options(useGeneratedKeys = true, keyProperty = "country.id")` 。
+- `<2>` 处，获得真正的参数值。
+- `<3>` 处，获得主键的属性的配置。
+- `<4>` 处，调用 `#assignKeysToParam(...)` 方法，设置主键们，到参数 `param` 中。所以，后续流程，又回到了 [「3.4.2」](https://svip.iocoder.cn/MyBatis/executor-3/#) 咧。
+- 关于这个方法，胖友自己模拟下这个情况，调试下会比较好理解。😈 当然，也可以不理解，嘿嘿。
+
+## 3.5 populateKeys
+
+```
+// Jdbc3KeyGenerator.java
+
+private void populateKeys(ResultSet rs, MetaObject metaParam, String[] keyProperties, TypeHandler<?>[] typeHandlers) throws SQLException {
+    // 遍历 keyProperties
+    for (int i = 0; i < keyProperties.length; i++) {
+        // 获得属性名
+        String property = keyProperties[i];
+        // 获得 TypeHandler 对象
+        TypeHandler<?> th = typeHandlers[i];
+        if (th != null) {
+            // 从 rs 中，获得对应的 值
+            Object value = th.getResult(rs, i + 1);
+            // 设置到 metaParam 的对应 property 属性种
+            metaParam.setValue(property, value);
+        }
+    }
+}
+```
+
+- 代码比较简单，胖友看下注释即可。
+
+# 4. SelectKeyGenerator
+
+`org.apache.ibatis.executor.keygen.SelectKeyGenerator` ，实现 KeyGenerator 接口，基于从数据库查询主键的 KeyGenerator 实现类，适用于 Oracle、PostgreSQL 。
+
+## 4.1 构造方法
+
+```
+// SelectKeyGenerator.java
+
+    public static final String SELECT_KEY_SUFFIX = "!selectKey";
+
+/**
+ * 是否在 before 阶段执行
+ *
+ * true ：before
+ * after ：after
+ */
+private final boolean executeBefore;
+/**
+ * MappedStatement 对象
+ */
+private final MappedStatement keyStatement;
+
+public SelectKeyGenerator(MappedStatement keyStatement, boolean executeBefore) {
+    this.executeBefore = executeBefore;
+    this.keyStatement = keyStatement;
+}
+```
+
+## 4.2 processBefore
+
+```
+// SelectKeyGenerator.java
+
+@Override
+public void processBefore(Executor executor, MappedStatement ms, Statement stmt, Object parameter) {
+    if (executeBefore) {
+        processGeneratedKeys(executor, ms, parameter);
+    }
+}
+```
+
+- 调用 `#processGeneratedKeys(...)` 方法。
+
+## 4.3 processAfter
+
+```
+// SelectKeyGenerator.java
+
+@Override
+public void processAfter(Executor executor, MappedStatement ms, Statement stmt, Object parameter) {
+    if (!executeBefore) {
+        processGeneratedKeys(executor, ms, parameter);
+    }
+}
+```
+
+- 也是调用 `#processGeneratedKeys(...)` 方法。
+
+## 4.4 processGeneratedKeys
+
+```
+// SelectKeyGenerator.java
+
+private void processGeneratedKeys(Executor executor, MappedStatement ms, Object parameter) {
+    try {
+        // <1> 有查询主键的 SQL 语句，即 keyStatement 对象非空
+        if (parameter != null && keyStatement != null && keyStatement.getKeyProperties() != null) {
+            String[] keyProperties = keyStatement.getKeyProperties();
+            final Configuration configuration = ms.getConfiguration();
+            final MetaObject metaParam = configuration.newMetaObject(parameter);
+            // Do not close keyExecutor.
+            // The transaction will be closed by parent executor.
+            // <2> 创建执行器，类型为 SimpleExecutor
+            Executor keyExecutor = configuration.newExecutor(executor.getTransaction(), ExecutorType.SIMPLE);
+            // <3> 执行查询主键的操作
+            List<Object> values = keyExecutor.query(keyStatement, parameter, RowBounds.DEFAULT, Executor.NO_RESULT_HANDLER);
+            // <4.1> 查不到结果，抛出 ExecutorException 异常
+            if (values.size() == 0) {
+                throw new ExecutorException("SelectKey returned no data.");
+            // <4.2> 查询的结果过多，抛出 ExecutorException 异常
+            } else if (values.size() > 1) {
+                throw new ExecutorException("SelectKey returned more than one value.");
+            } else {
+                // <4.3> 创建 MetaObject 对象，访问查询主键的结果
+                MetaObject metaResult = configuration.newMetaObject(values.get(0));
+                // <4.3.1> 单个主键
+                if (keyProperties.length == 1) {
+                    // 设置属性到 metaParam 中，相当于设置到 parameter 中
+                    if (metaResult.hasGetter(keyProperties[0])) {
+                        setValue(metaParam, keyProperties[0], metaResult.getValue(keyProperties[0]));
+                    } else {
+                        // no getter for the property - maybe just a single value object
+                        // so try that
+                        setValue(metaParam, keyProperties[0], values.get(0));
+                    }
+                // <4.3.2> 多个主键
+                } else {
+                    // 遍历，进行赋值
+                    handleMultipleProperties(keyProperties, metaParam, metaResult);
+                }
+            }
+        }
+    } catch (ExecutorException e) {
+        throw e;
+    } catch (Exception e) {
+        throw new ExecutorException("Error selecting key or setting result to parameter object. Cause: " + e, e);
+    }
+}
+```
+
+- `<1>` 处，有查询主键的 SQL 语句，即 `keyStatement` 对象非空。
+
+- `<2>` 处，创建执行器，类型为 SimpleExecutor 。
+
+- 【重要】 `<3>` 处，调用 `Executor#query(...)` 方法，执行查询主键的操作。😈 简单脑暴下，按照 SelectKeyGenerator 的思路，岂不是可以可以接入 SnowFlake 算法，从而实现分布式主键。
+
+- `<4.1>` 处，查不到结果，抛出 ExecutorException 异常。
+
+- `<4.2>` 处，查询的结果过多，抛出 ExecutorException 异常。
+
+- `<4.3>` 处，创建 MetaObject 对象，访问查询主键的结果。
+
+  - `<4.3.1>` 处，**单个主键**，调用 `#setValue(MetaObject metaParam, String property, Object value)` 方法，设置属性到 `metaParam` 中，相当于设置到 `parameter` 中。代码如下：
+
+    ```
+    // SelectKeyGenerator.java
+    
+    private void setValue(MetaObject metaParam, String property, Object value) {
+        if (metaParam.hasSetter(property)) {
+            metaParam.setValue(property, value);
+        } else {
+            throw new ExecutorException("No setter found for the keyProperty '" + property + "' in " + metaParam.getOriginalObject().getClass().getName() + ".");
+        }
+    }
+    ```
+
+    - 简单，胖友自己瞅瞅。
+
+  - `<4.3.2>` 处，**多个主键**，调用 `#handleMultipleProperties(String[] keyProperties, MetaObject metaParam, MetaObject metaResult)` 方法，遍历，进行赋值。代码如下：
+
+    ```
+    // SelectKeyGenerator.java
+    
+    private void handleMultipleProperties(String[] keyProperties,
+                                          MetaObject metaParam, MetaObject metaResult) {
+        String[] keyColumns = keyStatement.getKeyColumns();
+        // 遍历，进行赋值
+        if (keyColumns == null || keyColumns.length == 0) {
+            // no key columns specified, just use the property names
+            for (String keyProperty : keyProperties) {
+                setValue(metaParam, keyProperty, metaResult.getValue(keyProperty));
+            }
+        } else {
+            if (keyColumns.length != keyProperties.length) {
+                throw new ExecutorException("If SelectKey has key columns, the number must match the number of key properties.");
+            }
+            for (int i = 0; i < keyProperties.length; i++) {
+                setValue(metaParam, keyProperties[i], metaResult.getValue(keyColumns[i]));
+            }
+        }
+    }
+    ```
+
+    - 最终，还是会调用 `#setValue(...)` 方法，进行赋值。
+
+## 4.5 示例
+
+- [《MyBatis + Oracle 实现主键自增长的几种常用方式》](https://blog.csdn.net/wal1314520/article/details/77132305)
+- [《mybatis + postgresql 返回递增主键的正确姿势及勘误》](https://blog.csdn.net/cdnight/article/details/72735108)
+
+# 5. NoKeyGenerator
+
+`org.apache.ibatis.executor.keygen.NoKeyGenerator` ，实现 KeyGenerator 接口，空的 KeyGenerator 实现类，即无需主键生成。代码如下：
+
+```
+// NoKeyGenerator.java
+
+public class NoKeyGenerator implements KeyGenerator {
+
+    /**
+     * A shared instance.
+     * @since 3.4.3
+     */
+    public static final NoKeyGenerator INSTANCE = new NoKeyGenerator();
+
+    @Override
+    public void processBefore(Executor executor, MappedStatement ms, Statement stmt, Object parameter) {
+        // Do Nothing
+    }
+
+    @Override
+    public void processAfter(Executor executor, MappedStatement ms, Statement stmt, Object parameter) {
+        // Do Nothing
+    }
+
+}
+```
+
+# 666. 彩蛋
+
+简单小文，嘿嘿。
+
+参考和推荐如下文章：
+
+- 祖大俊 [《Mybatis3.3.x技术内幕（十四）：Mybatis之KeyGenerator》](https://my.oschina.net/zudajun/blog/673612)
+
+- 祖大俊
+
+   
+
+  《Mybatis3.3.x技术内幕（十五）：Mybatis之foreach批量insert，返回主键id列表（修复Mybatis返回null的bug）》
+
+   
+
+  强烈推荐
+
+  - 目前已经修复，参见 https://github.com/mybatis/mybatis-3/pull/324 。
+
+- 徐郡明 [《MyBatis 技术内幕》](https://item.jd.com/12125531.html) 的 [「3.4 KeyGenerator」](https://svip.iocoder.cn/MyBatis/executr-3/#) 小节
\ No newline at end of file
diff --git a/mybatis/24-mybatis-SQL 执行（四）之 ResultSetHandler.assets/01.png b/mybatis/24-mybatis-SQL 执行（四）之 ResultSetHandler.assets/01.png
new file mode 100644
index 0000000..23b7e38
Binary files /dev/null and b/mybatis/24-mybatis-SQL 执行（四）之 ResultSetHandler.assets/01.png differ
diff --git a/mybatis/24-mybatis-SQL 执行（四）之 ResultSetHandler.md b/mybatis/24-mybatis-SQL 执行（四）之 ResultSetHandler.md
new file mode 100644
index 0000000..0f8733f
--- /dev/null
+++ b/mybatis/24-mybatis-SQL 执行（四）之 ResultSetHandler.md	
@@ -0,0 +1,2285 @@
+# 精尽 MyBatis 源码分析 —— SQL 执行（四）之 ResultSetHandler
+
+# 1. 概述
+
+本文，我们来分享 SQL 执行的第四部分，SQL 执行后，响应的结果集 ResultSet 的处理，涉及 `executor/resultset`、`executor/result`、`cursor` 包。整体类图如下：[![类图](24-mybatis-SQL 执行（四）之 ResultSetHandler.assets/01.png)](http://static.iocoder.cn/images/MyBatis/2020_03_09/01.png)类图
+
+- 核心类是 ResultSetHandler 接口及其实现类 DefaultResultSetHandler 。在它的代码逻辑中，会调用类图中的其它类，实现将查询结果的 ResultSet ，转换成映射的对应结果。
+
+# 2. ResultSetWrapper
+
+> 老艿艿：在看具体的 DefaultResultSetHandler 的实现代码之前，我们先看看 ResultSetWrapper 的代码。因为 DefaultResultSetHandler 对 ResultSetWrapper 的调用比较多，避免混着解析。
+
+`org.apache.ibatis.executor.resultset.ResultSetWrapper` ，`java.sql.ResultSet` 的 包装器，可以理解成 ResultSet 的工具类，提供给 DefaultResultSetHandler 使用。
+
+## 2.1 构造方法
+
+```
+// ResultSetWrapper.java
+
+/**
+ * ResultSet 对象
+ */
+private final ResultSet resultSet;
+private final TypeHandlerRegistry typeHandlerRegistry;
+/**
+ * 字段的名字的数组
+ */
+private final List<String> columnNames = new ArrayList<>();
+/**
+ * 字段的 Java Type 的数组
+ */
+private final List<String> classNames = new ArrayList<>();
+/**
+ * 字段的 JdbcType 的数组
+ */
+private final List<JdbcType> jdbcTypes = new ArrayList<>();
+private final Map<String, Map<Class<?>, TypeHandler<?>>> typeHandlerMap = new HashMap<>();
+private final Map<String, List<String>> mappedColumnNamesMap = new HashMap<>();
+private final Map<String, List<String>> unMappedColumnNamesMap = new HashMap<>();
+
+public ResultSetWrapper(ResultSet rs, Configuration configuration) throws SQLException {
+    this.typeHandlerRegistry = configuration.getTypeHandlerRegistry();
+    this.resultSet = rs;
+    // <1> 遍历 ResultSetMetaData 的字段们，解析出 columnNames、jdbcTypes、classNames 属性
+    final ResultSetMetaData metaData = rs.getMetaData();
+    final int columnCount = metaData.getColumnCount();
+    for (int i = 1; i <= columnCount; i++) {
+        columnNames.add(configuration.isUseColumnLabel() ? metaData.getColumnLabel(i) : metaData.getColumnName(i));
+        jdbcTypes.add(JdbcType.forCode(metaData.getColumnType(i)));
+        classNames.add(metaData.getColumnClassName(i));
+    }
+}
+```
+
+- `resultSet` 属性，被包装的 ResultSet 对象。
+- `columnNames`、`classNames`、`jdbcTypes` 属性，在 `<1>` 处，通过遍历 ResultSetMetaData 的字段们，从而解析出来。
+
+## 2.2 getTypeHandler
+
+```
+// ResultSetWrapper.java
+
+/**
+ * TypeHandler 的映射
+ *
+ * KEY1：字段的名字
+ * KEY2：Java 属性类型
+ */
+private final Map<String, Map<Class<?>, TypeHandler<?>>> typeHandlerMap = new HashMap<>();
+
+/**
+ * Gets the type handler to use when reading the result set.
+ * Tries to get from the TypeHandlerRegistry by searching for the property type.
+ * If not found it gets the column JDBC type and tries to get a handler for it.
+ *
+ * 获得指定字段名的指定 JavaType 类型的 TypeHandler 对象
+ *
+ * @param propertyType JavaType
+ * @param columnName 执行字段
+ * @return TypeHandler 对象
+ */
+public TypeHandler<?> getTypeHandler(Class<?> propertyType, String columnName) {
+    TypeHandler<?> handler = null;
+    // <1> 先从缓存的 typeHandlerMap 中，获得指定字段名的指定 JavaType 类型的 TypeHandler 对象
+    Map<Class<?>, TypeHandler<?>> columnHandlers = typeHandlerMap.get(columnName);
+    if (columnHandlers == null) {
+        columnHandlers = new HashMap<>();
+        typeHandlerMap.put(columnName, columnHandlers);
+    } else {
+        handler = columnHandlers.get(propertyType);
+    }
+    // <2> 如果获取不到，则进行查找
+    if (handler == null) {
+        // <2> 获得 JdbcType 类型
+        JdbcType jdbcType = getJdbcType(columnName);
+        // <2> 获得 TypeHandler 对象
+        handler = typeHandlerRegistry.getTypeHandler(propertyType, jdbcType);
+        // Replicate logic of UnknownTypeHandler#resolveTypeHandler
+        // See issue #59 comment 10
+        // <3> 如果获取不到，则再次进行查找
+        if (handler == null || handler instanceof UnknownTypeHandler) {
+            // <3> 使用 classNames 中的类型，进行继续查找 TypeHandler 对象
+            final int index = columnNames.indexOf(columnName);
+            final Class<?> javaType = resolveClass(classNames.get(index));
+            if (javaType != null && jdbcType != null) {
+                handler = typeHandlerRegistry.getTypeHandler(javaType, jdbcType);
+            } else if (javaType != null) {
+                handler = typeHandlerRegistry.getTypeHandler(javaType);
+            } else if (jdbcType != null) {
+                handler = typeHandlerRegistry.getTypeHandler(jdbcType);
+            }
+        }
+        // <4> 如果获取不到，则使用 ObjectTypeHandler 对象
+        if (handler == null || handler instanceof UnknownTypeHandler) {
+            handler = new ObjectTypeHandler();
+        }
+        // <5> 缓存到 typeHandlerMap 中
+        columnHandlers.put(propertyType, handler);
+    }
+    return handler;
+}
+```
+
+- `<1>` 处，先从缓存的 `typeHandlerMap` 中，获得指定字段名的指定 JavaType 类型的 TypeHandler 对象。
+
+- `<2>` 处，如果获取不到，则基于 `propertyType` + `jdbcType` 进行查找。其中，`#getJdbcType(String columnName)` 方法，获得 JdbcType 类型。代码如下：
+
+  ```
+  // ResultSetWrapper.java
+  
+  public JdbcType getJdbcType(String columnName) {
+      for (int i = 0; i < columnNames.size(); i++) {
+          if (columnNames.get(i).equalsIgnoreCase(columnName)) {
+              return jdbcTypes.get(i);
+          }
+      }
+      return null;
+  }
+  ```
+
+  - 通过 `columnNames` 索引到位置 `i` ，从而到 `jdbcTypes` 中获得 JdbcType 类型。
+
+- `<3>` 处，如果获取不到，则基于 `javaType` + `jdbcType` 进行查找。其中，`javaType` 使用 `classNames` 中的类型。而 `#resolveClass(String className)` 方法，获得对应的类。代码如下：
+
+  ```
+  // ResultSetWrapper.java
+  
+  private Class<?> resolveClass(String className) {
+      try {
+          // #699 className could be null
+          if (className != null) {
+              return Resources.classForName(className);
+          }
+      } catch (ClassNotFoundException e) {
+          // ignore
+      }
+      return null;
+  }
+  ```
+
+- `<4>` 处，如果获取不到，则使用 ObjectTypeHandler 对象。
+
+- `<5>` 处，缓存 TypeHandler 对象，到 `typeHandlerMap` 中。
+
+## 2.3 loadMappedAndUnmappedColumnNames
+
+`#loadMappedAndUnmappedColumnNames(ResultMap resultMap, String columnPrefix)` 方法，初始化**有 mapped** 和**无 mapped**的字段的名字数组。代码如下：
+
+```
+// ResultSetWrapper.java
+
+/**
+ * 有 mapped 的字段的名字的映射
+ *
+ * KEY：{@link #getMapKey(ResultMap, String)}
+ * VALUE：字段的名字的数组
+ */
+private final Map<String, List<String>> mappedColumnNamesMap = new HashMap<>();
+/**
+ * 无 mapped 的字段的名字的映射
+ *
+ * 和 {@link #mappedColumnNamesMap} 相反
+ */
+private final Map<String, List<String>> unMappedColumnNamesMap = new HashMap<>();
+
+private void loadMappedAndUnmappedColumnNames(ResultMap resultMap, String columnPrefix) throws SQLException {
+    List<String> mappedColumnNames = new ArrayList<>();
+    List<String> unmappedColumnNames = new ArrayList<>();
+    // <1> 将 columnPrefix 转换成大写，并拼接到 resultMap.mappedColumns 属性上
+    final String upperColumnPrefix = columnPrefix == null ? null : columnPrefix.toUpperCase(Locale.ENGLISH);
+    final Set<String> mappedColumns = prependPrefixes(resultMap.getMappedColumns(), upperColumnPrefix);
+    // <2> 遍历 columnNames 数组，根据是否在 mappedColumns 中，分别添加到 mappedColumnNames 和 unmappedColumnNames 中
+    for (String columnName : columnNames) {
+        final String upperColumnName = columnName.toUpperCase(Locale.ENGLISH);
+        if (mappedColumns.contains(upperColumnName)) {
+            mappedColumnNames.add(upperColumnName);
+        } else {
+            unmappedColumnNames.add(columnName);
+        }
+    }
+    // <3> 将 mappedColumnNames 和 unmappedColumnNames 结果，添加到 mappedColumnNamesMap 和 unMappedColumnNamesMap 中
+    mappedColumnNamesMap.put(getMapKey(resultMap, columnPrefix), mappedColumnNames);
+    unMappedColumnNamesMap.put(getMapKey(resultMap, columnPrefix), unmappedColumnNames);
+}
+```
+
+- `<1>` 处，将 `columnPrefix` 转换成大写，后调用 `#prependPrefixes(Set<String> columnNames, String prefix)` 方法，拼接到 `resultMap.mappedColumns` 属性上。代码如下：
+
+  ```
+  // ResultSetWrapper.java
+  
+  private Set<String> prependPrefixes(Set<String> columnNames, String prefix) {
+      // 直接返回 columnNames ，如果符合如下任一情况
+      if (columnNames == null || columnNames.isEmpty() || prefix == null || prefix.length() == 0) {
+          return columnNames;
+      }
+      // 拼接前缀 prefix ，然后返回
+      final Set<String> prefixed = new HashSet<>();
+      for (String columnName : columnNames) {
+          prefixed.add(prefix + columnName);
+      }
+      return prefixed;
+  }
+  ```
+
+  - 当然，可能有胖友，跟我会懵逼，可能已经忘记什么是 `resultMap.mappedColumns` 。我们来举个示例：
+
+    ```
+    <resultMap id="B" type="Object">
+        <result property="year" column="year"/>
+    </resultMap>
+    
+    <select id="testResultMap" parameterType="Integer" resultMap="A">
+        SELECT * FROM subject
+    </select>
+    ```
+
+    - 此处的 `column="year"` ，就会被添加到 `resultMap.mappedColumns` 属性上。
+
+- `<2>` 处，遍历 `columnNames` 数组，根据是否在 `mappedColumns` 中，分别添加到 `mappedColumnNames` 和 `unmappedColumnNames` 中。
+
+- `<3>` 处，将 `mappedColumnNames` 和 `unmappedColumnNames` 结果，添加到 `mappedColumnNamesMap` 和 `unMappedColumnNamesMap` 中。其中，`#getMapKey(ResultMap resultMap, String columnPrefix)` 方法，获得缓存的 KEY 。代码如下：
+
+  ```
+  // ResultSetWrapper.java
+  
+  private String getMapKey(ResultMap resultMap, String columnPrefix) {
+      return resultMap.getId() + ":" + columnPrefix;
+  }
+  ```
+
+下面，我们看个类似的，会调用该方法的方法：
+
+- `#getMappedColumnNames(ResultMap resultMap, String columnPrefix)` 方法，获得**有** mapped 的字段的名字的数组。代码如下：
+
+  ```
+  // ResultSetWrapper.java
+  
+  public List<String> getMappedColumnNames(ResultMap resultMap, String columnPrefix) throws SQLException {
+      // 获得对应的 mapped 数组
+      List<String> mappedColumnNames = mappedColumnNamesMap.get(getMapKey(resultMap, columnPrefix));
+      if (mappedColumnNames == null) {
+          // 初始化
+          loadMappedAndUnmappedColumnNames(resultMap, columnPrefix);
+          // 重新获得对应的 mapped 数组
+          mappedColumnNames = mappedColumnNamesMap.get(getMapKey(resultMap, columnPrefix));
+      }
+      return mappedColumnNames;
+  }
+  ```
+
+- `#getUnmappedColumnNames(ResultMap resultMap, String columnPrefix)` 方法，获得**无** mapped 的字段的名字的数组。代码如下：
+
+  ```
+  // ResultSetWrapper.java
+  
+  public List<String> getUnmappedColumnNames(ResultMap resultMap, String columnPrefix) throws SQLException {
+      // 获得对应的 unMapped 数组
+      List<String> unMappedColumnNames = unMappedColumnNamesMap.get(getMapKey(resultMap, columnPrefix));
+      if (unMappedColumnNames == null) {
+          // 初始化
+          loadMappedAndUnmappedColumnNames(resultMap, columnPrefix);
+          // 重新获得对应的 unMapped 数组
+          unMappedColumnNames = unMappedColumnNamesMap.get(getMapKey(resultMap, columnPrefix));
+      }
+      return unMappedColumnNames;
+  }
+  ```
+
+😈 具体这两个方法什么用途呢？待到我们在 DefaultResultSetHandler 类里来看。
+
+# 3. ResultSetHandler
+
+`org.apache.ibatis.executor.resultset.ResultSetHandler` ，`java.sql.ResultSet` 处理器接口。代码如下：
+
+```
+// ResultSetHandler.java
+
+public interface ResultSetHandler {
+
+    /**
+     * 处理 {@link java.sql.ResultSet} 成映射的对应的结果
+     *
+     * @param stmt Statement 对象
+     * @param <E> 泛型
+     * @return 结果数组
+     */
+    <E> List<E> handleResultSets(Statement stmt) throws SQLException;
+
+    /**
+     * 处理 {@link java.sql.ResultSet} 成 Cursor 对象
+     *
+     * @param stmt Statement 对象
+     * @param <E> 泛型
+     * @return Cursor 对象
+     */
+    <E> Cursor<E> handleCursorResultSets(Statement stmt) throws SQLException;
+
+    // 暂时忽略，和存储过程相关
+    void handleOutputParameters(CallableStatement cs) throws SQLException;
+
+}
+```
+
+## 3.1 DefaultResultSetHandler
+
+> 老艿艿：保持冷静，DefaultResultSetHandler 有小 1000 行的代码。
+
+`org.apache.ibatis.executor.resultset.DefaultResultSetHandler` ，实现 ResultSetHandler 接口，默认的 ResultSetHandler 实现类。
+
+### 3.1.1 构造方法
+
+```
+// DefaultResultSetHandler.java
+
+private static final Object DEFERED = new Object();
+
+private final Executor executor;
+private final Configuration configuration;
+private final MappedStatement mappedStatement;
+private final RowBounds rowBounds;
+private final ParameterHandler parameterHandler;
+/**
+ * 用户指定的用于处理结果的处理器。
+ *
+ * 一般情况下，不设置
+ */
+private final ResultHandler<?> resultHandler;
+private final BoundSql boundSql;
+private final TypeHandlerRegistry typeHandlerRegistry;
+private final ObjectFactory objectFactory;
+private final ReflectorFactory reflectorFactory;
+
+// nested resultmaps
+private final Map<CacheKey, Object> nestedResultObjects = new HashMap<>();
+private final Map<String, Object> ancestorObjects = new HashMap<>();
+private Object previousRowValue;
+
+// multiple resultsets
+// 存储过程相关的多 ResultSet 涉及的属性，可以暂时忽略
+private final Map<String, ResultMapping> nextResultMaps = new HashMap<>();
+private final Map<CacheKey, List<PendingRelation>> pendingRelations = new HashMap<>();
+
+// Cached Automappings
+/**
+ * 自动映射的缓存
+ *
+ * KEY：{@link ResultMap#getId()} + ":" +  columnPrefix
+ *
+ * @see #createRowKeyForUnmappedProperties(ResultMap, ResultSetWrapper, CacheKey, String) 
+ */
+private final Map<String, List<UnMappedColumnAutoMapping>> autoMappingsCache = new HashMap<>();
+
+// temporary marking flag that indicate using constructor mapping (use field to reduce memory usage)
+/**
+ * 是否使用构造方法创建该结果对象
+ */
+private boolean useConstructorMappings;
+
+public DefaultResultSetHandler(Executor executor, MappedStatement mappedStatement, ParameterHandler parameterHandler, ResultHandler<?> resultHandler, BoundSql boundSql, RowBounds rowBounds) {
+    this.executor = executor;
+    this.configuration = mappedStatement.getConfiguration();
+    this.mappedStatement = mappedStatement;
+    this.rowBounds = rowBounds;
+    this.parameterHandler = parameterHandler;
+    this.boundSql = boundSql;
+    this.typeHandlerRegistry = configuration.getTypeHandlerRegistry();
+    this.objectFactory = configuration.getObjectFactory();
+    this.reflectorFactory = configuration.getReflectorFactory();
+    this.resultHandler = resultHandler;
+}
+```
+
+- 属性比较多，我们看重点的几个。
+- `resultHandler` 属性，ResultHandler 对象。用户指定的用于处理结果的处理器，一般情况下，不设置。详细解析，见 [「5. ResultHandler」](https://svip.iocoder.cn/MyBatis/executor-4/#) 和 [「3.1.2.3.3 storeObject」](https://svip.iocoder.cn/MyBatis/executor-4/#) 。
+- `autoMappingsCache` 属性，自动映射的缓存。其中，KEY 为 `{@link ResultMap#getId()} + ":" + columnPrefix` 。详细解析，见 [「3.1.2.3.2.4 applyAutomaticMappings」](https://svip.iocoder.cn/MyBatis/executor-4/#) 。
+
+### 3.1.2 handleResultSets
+
+`#handleResultSets(Statement stmt)` 方法，处理 `java.sql.ResultSet` 结果集，转换成映射的对应结果。代码如下：
+
+```
+// DefaultResultSetHandler.java
+
+@Override
+public List<Object> handleResultSets(Statement stmt) throws SQLException {
+    ErrorContext.instance().activity("handling results").object(mappedStatement.getId());
+
+    // <1> 多 ResultSet 的结果集合，每个 ResultSet 对应一个 Object 对象。而实际上，每个 Object 是 List<Object> 对象。
+    // 在不考虑存储过程的多 ResultSet 的情况，普通的查询，实际就一个 ResultSet ，也就是说，multipleResults 最多就一个元素。
+    final List<Object> multipleResults = new ArrayList<>();
+
+    int resultSetCount = 0;
+    // <2> 获得首个 ResultSet 对象，并封装成 ResultSetWrapper 对象
+    ResultSetWrapper rsw = getFirstResultSet(stmt);
+
+    // <3> 获得 ResultMap 数组
+    // 在不考虑存储过程的多 ResultSet 的情况，普通的查询，实际就一个 ResultSet ，也就是说，resultMaps 就一个元素。
+    List<ResultMap> resultMaps = mappedStatement.getResultMaps();
+    int resultMapCount = resultMaps.size();
+    validateResultMapsCount(rsw, resultMapCount); // <3.1> 校验
+    while (rsw != null && resultMapCount > resultSetCount) {
+        // <4.1> 获得 ResultMap 对象
+        ResultMap resultMap = resultMaps.get(resultSetCount);
+        // <4.2> 处理 ResultSet ，将结果添加到 multipleResults 中
+        handleResultSet(rsw, resultMap, multipleResults, null);
+        // <4.3> 获得下一个 ResultSet 对象，并封装成 ResultSetWrapper 对象
+        rsw = getNextResultSet(stmt);
+        // <4.4> 清理
+        cleanUpAfterHandlingResultSet();
+        // resultSetCount ++
+        resultSetCount++;
+    }
+
+    // <5> 因为 `mappedStatement.resultSets` 只在存储过程中使用，本系列暂时不考虑，忽略即可
+    String[] resultSets = mappedStatement.getResultSets();
+    if (resultSets != null) {
+        while (rsw != null && resultSetCount < resultSets.length) {
+            ResultMapping parentMapping = nextResultMaps.get(resultSets[resultSetCount]);
+            if (parentMapping != null) {
+                String nestedResultMapId = parentMapping.getNestedResultMapId();
+                ResultMap resultMap = configuration.getResultMap(nestedResultMapId);
+                handleResultSet(rsw, resultMap, null, parentMapping);
+            }
+            rsw = getNextResultSet(stmt);
+            cleanUpAfterHandlingResultSet();
+            resultSetCount++;
+        }
+    }
+
+    // <6> 如果是 multipleResults 单元素，则取首元素返回
+    return collapseSingleResultList(multipleResults);
+}
+```
+
+- 这个方法，不仅仅支持处理 Statement 和 PreparedStatement 返回的结果集，也支持存储过程的 CallableStatement 返回的结果集。而 CallableStatement 是支持返回多结果集的，这个大家要注意。😈 当然，还是老样子，本文不分析仅涉及存储过程的相关代码。哈哈哈。
+
+- `<1>` 处，多 ResultSet 的结果集合，每个 ResultSet 对应一个 Object 对象。而实际上，每个 Object 是 List 对象。在不考虑存储过程的多 ResultSet 的情况，普通的查询，实际就一个 ResultSet ，也就是说，`multipleResults` **最多就一个元素**。
+
+- `<2>` 处，调用 `#getFirstResultSet(Statement stmt)` 方法，获得首个 ResultSet 对象，并封装成 ResultSetWrapper 对象。代码如下：
+
+  ```
+  // DefaultResultSetHandler.java
+  
+  private ResultSetWrapper getFirstResultSet(Statement stmt) throws SQLException {
+      ResultSet rs = stmt.getResultSet();
+      // 可以忽略
+      while (rs == null) {
+          // move forward to get the first resultset in case the driver
+          // doesn't return the resultset as the first result (HSQLDB 2.1)
+          if (stmt.getMoreResults()) {
+              rs = stmt.getResultSet();
+          } else {
+              if (stmt.getUpdateCount() == -1) {
+                  // no more results. Must be no resultset
+                  break;
+              }
+          }
+      }
+      // 将 ResultSet 对象，封装成 ResultSetWrapper 对象
+      return rs != null ? new ResultSetWrapper(rs, configuration) : null;
+  }
+  ```
+
+- `<3>` 处，调用 `MappedStatement#getResultMaps()` 方法，获得 ResultMap 数组。在不考虑存储过程的多 ResultSet 的情况，普通的查询，实际就一个 ResultSet ，也就是说，`resultMaps` **就一个元素**。
+
+  - `<3.1>` 处，调用 `#validateResultMapsCount(ResultSetWrapper rsw, int resultMapCount)` 方法，校验至少有一个 ResultMap 对象。代码如下：
+
+    ```
+    // DefaultResultSetHandler.java
+    
+    private void validateResultMapsCount(ResultSetWrapper rsw, int resultMapCount) {
+        if (rsw != null && resultMapCount < 1) {
+            throw new ExecutorException("A query was run and no Result Maps were found for the Mapped Statement '" + mappedStatement.getId()
+                    + "'.  It's likely that neither a Result Type nor a Result Map was specified.");
+        }
+    }
+    ```
+
+    - 不符合，则抛出 ExecutorException 异常。
+
+- `<4.1>` 处，获得 ResultMap 对象。
+
+- `<4.2>` 处，调用 `#handleResultSet(ResultSetWrapper rsw, ResultMap resultMap, List<Object> multipleResults, ResultMapping parentMapping)` 方法，处理 ResultSet ，将结果添加到 `multipleResults` 中。详细解析，见 [「3.1.2.1 handleResultSet」](https://svip.iocoder.cn/MyBatis/executor-4/#) 。
+
+- `<4.3>` 处，调用 `#getNextResultSet(Statement stmt)` 方法，获得下一个 ResultSet 对象，并封装成 ResultSetWrapper 对象。😈 只有存储过程才有多 ResultSet 对象，所以可以忽略。也就是说，实际上，这个 `while` 循环对我们来说，就不需要啦。
+
+- `<4.4>` 处，调用 `#cleanUpAfterHandlingResultSet()` 方法，执行清理。代码如下：
+
+  ```
+  // DefaultResultSetHandler.java
+  
+  private void cleanUpAfterHandlingResultSet() {
+      nestedResultObjects.clear();
+  }
+  ```
+
+- `<5>` 处，因为 `mappedStatement.resultSets` 只在存储过程中使用，本系列暂时不考虑，忽略即可。
+
+- `<6>` 处，调用 `#collapseSingleResultList(List<Object> multipleResults)` 方法，如果是 `multipleResults` 单元素，则取首元素返回。代码如下：
+
+  ```
+  // DefaultResultSetHandler.java
+  
+  private List<Object> collapseSingleResultList(List<Object> multipleResults) {
+      return multipleResults.size() == 1 ? (List<Object>) multipleResults.get(0) : multipleResults;
+  }
+  ```
+
+  - 对于非存储过程的结果处理，都能符合 `multipleResults.size()` 。
+
+#### 3.1.2.1 handleResultSet
+
+`#handleResultSet(ResultSetWrapper rsw, ResultMap resultMap, List<Object> multipleResults, ResultMapping parentMapping)` 方法，处理 ResultSet ，将结果添加到 `multipleResults` 中。代码如下：
+
+```
+// DefaultResultSetHandler.java
+
+private void handleResultSet(ResultSetWrapper rsw, ResultMap resultMap, List<Object> multipleResults, ResultMapping parentMapping) throws SQLException {
+    try {
+        // <1> 暂时忽略，因为只有存储过程的情况，调用该方法，parentMapping 为非空
+        if (parentMapping != null) {
+            handleRowValues(rsw, resultMap, null, RowBounds.DEFAULT, parentMapping);
+        } else {
+            // <2> 如果没有自定义的 resultHandler ，则创建默认的 DefaultResultHandler 对象
+            if (resultHandler == null) {
+                // <2> 创建 DefaultResultHandler 对象
+                DefaultResultHandler defaultResultHandler = new DefaultResultHandler(objectFactory);
+                // <3> 处理 ResultSet 返回的每一行 Row
+                handleRowValues(rsw, resultMap, defaultResultHandler, rowBounds, null);
+                // <4> 添加 defaultResultHandler 的处理的结果，到 multipleResults 中
+                multipleResults.add(defaultResultHandler.getResultList());
+            } else {
+                // <3> 处理 ResultSet 返回的每一行 Row
+                handleRowValues(rsw, resultMap, resultHandler, rowBounds, null);
+            }
+        }
+    } finally {
+        // issue #228 (close resultsets)
+        // 关闭 ResultSet 对象
+        closeResultSet(rsw.getResultSet());
+    }
+}
+```
+
+- `<1>` 处，暂时忽略，因为只有存储过程的情况，调用该方法，`parentMapping` 为非空。
+
+- `<2>` 处，如果没有自定义的 `resultHandler` ，则创建默认的 DefaultResultHandler 对象。
+
+- `<3>` 处，调用 `#handleRowValues(ResultSetWrapper rsw, ResultMap resultMap, ResultHandler<?> resultHandler, RowBounds rowBounds, ResultMapping parentMapping)` 方法，处理 ResultSet 返回的每一行 Row 。详细解析，见 [「3.1.2.2 handleRowValues」](https://svip.iocoder.cn/MyBatis/executor-4/#) 。
+
+- 【特殊】`<4>` 处，使用**默认**的 DefaultResultHandler 对象，最终会将 `defaultResultHandler` 的处理的结果，到 `multipleResults` 中。而使用**自定义**的 `resultHandler` ，不会添加到 `multipleResults` 中。当然，因为自定义的 `resultHandler` 对象，是作为一个对象传入，所以在其内部，还是可以存储结果的。例如：
+
+  ```
+  @Select("select * from users")
+  @ResultType(User.class)
+  void getAllUsers(UserResultHandler resultHandler);
+  ```
+
+  - 感兴趣的胖友，可以看看 [《mybatis ResultHandler 示例》](http://outofmemory.cn/code-snippet/13271/mybatis-complex-bean-property-handle-with-custom-ResultHandler) 。
+
+- `<5>` 处，调用 `#closeResultSet(ResultSet rs)` 方法关闭 ResultSet 对象。代码如下：
+
+  ```
+  // DefaultResultSetHandler.java
+  
+  private void closeResultSet(ResultSet rs) {
+      try {
+          if (rs != null) {
+              rs.close();
+          }
+      } catch (SQLException e) {
+          // ignore
+      }
+  }
+  ```
+
+#### 3.1.2.2 handleRowValues
+
+`#handleRowValues(ResultSetWrapper rsw, ResultMap resultMap, ResultHandler<?> resultHandler, RowBounds rowBounds, ResultMapping parentMapping)` 方法，处理 ResultSet 返回的每一行 Row 。代码如下：
+
+```
+// DefaultResultSetHandler.java
+
+public void handleRowValues(ResultSetWrapper rsw, ResultMap resultMap, ResultHandler<?> resultHandler, RowBounds rowBounds, ResultMapping parentMapping) throws SQLException {
+    // <1> 处理嵌套映射的情况
+    if (resultMap.hasNestedResultMaps()) {
+        // 校验不要使用 RowBounds
+        ensureNoRowBounds();
+        // 校验不要使用自定义的 resultHandler
+        checkResultHandler();
+        // 处理嵌套映射的结果
+        handleRowValuesForNestedResultMap(rsw, resultMap, resultHandler, rowBounds, parentMapping);
+    // <2> 处理简单映射的情况
+    } else {
+        // <2.1> 处理简单映射的结果
+        handleRowValuesForSimpleResultMap(rsw, resultMap, resultHandler, rowBounds, parentMapping);
+    }
+}
+```
+
+- 分成**嵌套映射**和**简单映射**的两种情况。
+
+- ```
+  <2>
+  ```
+
+   
+
+  处理嵌套映射的情况：
+
+  - `<2.1>` 处，调用 `#handleRowValuesForSimpleResultMap(...)` 方法，处理简单映射的结果。详细解析，见 [「3.1.2.3 handleRowValuesForSimpleResultMap 简单映射」](https://svip.iocoder.cn/MyBatis/executor-4/#) 。
+
+- `<1>` 处理嵌套映射的情况：
+
+  - `<1.1>` 处，调用 `#ensureNoRowBounds()` 方法，校验不要使用 RowBounds 。代码如下：
+
+    ```
+    // DefaultResultSetHandler.java
+    
+    private void ensureNoRowBounds() {
+        // configuration.isSafeRowBoundsEnabled() 默认为 false
+        if (configuration.isSafeRowBoundsEnabled() && rowBounds != null && (rowBounds.getLimit() < RowBounds.NO_ROW_LIMIT || rowBounds.getOffset() > RowBounds.NO_ROW_OFFSET)) {
+            throw new ExecutorException("Mapped Statements with nested result mappings cannot be safely constrained by RowBounds. "
+                    + "Use safeRowBoundsEnabled=false setting to bypass this check.");
+        }
+    }
+    ```
+
+    - 简单看看即可。
+
+  - `<1.2>` 处，调用 `#checkResultHandler()` 方法，校验不要使用自定义的 `resultHandler` 。代码如下：
+
+    ```
+    // DefaultResultSetHandler.java
+    
+    protected void checkResultHandler() {
+        // configuration.isSafeResultHandlerEnabled() 默认为 false
+        if (resultHandler != null && configuration.isSafeResultHandlerEnabled() && !mappedStatement.isResultOrdered()) {
+            throw new ExecutorException("Mapped Statements with nested result mappings cannot be safely used with a custom ResultHandler. "
+                    + "Use safeResultHandlerEnabled=false setting to bypass this check "
+                    + "or ensure your statement returns ordered data and set resultOrdered=true on it.");
+        }
+    }
+    ```
+
+    - 简单看看即可。
+
+  - `<1.3>` 处，调用 `#handleRowValuesForSimpleResultMap(...)` 方法，处理嵌套映射的结果。详细解析，见 [「3.1.2.3 handleRowValuesForNestedResultMap 嵌套映射」](https://svip.iocoder.cn/MyBatis/executor-4/#) 。
+
+#### 3.1.2.3 handleRowValuesForSimpleResultMap 简单映射
+
+`#handleRowValuesForSimpleResultMap(ResultSetWrapper rsw, ResultMap resultMap, ResultHandler<?> resultHandler, RowBounds rowBounds, ResultMapping parentMapping)` 方法，处理简单映射的结果。代码如下：
+
+```
+// DefaultResultSetHandler.java
+
+private void handleRowValuesForSimpleResultMap(ResultSetWrapper rsw, ResultMap resultMap, ResultHandler<?> resultHandler, RowBounds rowBounds, ResultMapping parentMapping) throws SQLException {
+    // <1> 创建 DefaultResultContext 对象
+    DefaultResultContext<Object> resultContext = new DefaultResultContext<>();
+    // <2> 获得 ResultSet 对象，并跳到 rowBounds 指定的开始位置
+    ResultSet resultSet = rsw.getResultSet();
+    skipRows(resultSet, rowBounds);
+    // <3> 循环
+    while (shouldProcessMoreRows(resultContext, rowBounds) // 是否继续处理 ResultSet
+            && !resultSet.isClosed() // ResultSet 是否已经关闭
+            && resultSet.next()) { // ResultSet 是否还有下一条
+        // <4> 根据该行记录以及 ResultMap.discriminator ，决定映射使用的 ResultMap 对象
+        ResultMap discriminatedResultMap = resolveDiscriminatedResultMap(resultSet, resultMap, null);
+        // <5> 根据最终确定的 ResultMap 对 ResultSet 中的该行记录进行映射，得到映射后的结果对象
+        Object rowValue = getRowValue(rsw, discriminatedResultMap, null);
+        // <6> 将映射创建的结果对象添加到 ResultHandler.resultList 中保存
+        storeObject(resultHandler, resultContext, rowValue, parentMapping, resultSet);
+    }
+}
+```
+
+- `<1>` 处，创建 DefaultResultContext 对象。详细解析，胖友**先**跳到 [「4. ResultContext」](https://svip.iocoder.cn/MyBatis/executor-4/#) 中，看完就回来。
+
+- `<2>` 处，获得 ResultSet 对象，并调用 `#skipRows(ResultSet rs, RowBounds rowBounds)` 方法，跳到 `rowBounds` 指定的开始位置。代码如下：
+
+  ```
+  // DefaultResultSetHandler.java
+  
+  private void skipRows(ResultSet rs, RowBounds rowBounds) throws SQLException {
+      if (rs.getType() != ResultSet.TYPE_FORWARD_ONLY) {
+          // 直接跳转到指定开始的位置
+          if (rowBounds.getOffset() != RowBounds.NO_ROW_OFFSET) {
+              rs.absolute(rowBounds.getOffset());
+          }
+      } else {
+          // 循环，不断跳到开始的位置
+          for (int i = 0; i < rowBounds.getOffset(); i++) {
+              if (!rs.next()) {
+                  break;
+              }
+          }
+      }
+  }
+  ```
+
+  - 关于 `org.apache.ibatis.session.RowBounds` 类，胖友可以看看 [《Mybatis3.3.x技术内幕（十三）：Mybatis之RowBounds分页原理》](https://my.oschina.net/zudajun/blog/671446) ，解释的非常不错。
+
+- `<3>` 处，循环，满足如下三个条件。其中 `#shouldProcessMoreRows(ResultContext<?> context, RowBounds rowBounds)` 方法，是否继续处理 ResultSet 。代码如下：
+
+  ```
+  // DefaultResultSetHandler.java
+  
+  private boolean shouldProcessMoreRows(ResultContext<?> context, RowBounds rowBounds) {
+      return !context.isStopped() && context.getResultCount() < rowBounds.getLimit();
+  }
+  ```
+
+- `<4>` 处，调用 `#resolveDiscriminatedResultMap(...)` 方法，根据该行记录以及 `ResultMap.discriminator` ，决定映射使用的 ResultMap 对象。详细解析，等下看 [「3.1.2.3.1 resolveDiscriminatedResultMap」](https://svip.iocoder.cn/MyBatis/executor-4/#) 。
+
+- `<5>` 处，调用 `#getRowValue(...)` 方法，根据最终确定的 ResultMap 对 ResultSet 中的该行记录进行映射，得到映射后的结果对象。详细解析，等下看 [「3.1.2.3.2 getRowValue」](https://svip.iocoder.cn/MyBatis/executor-4/#) 。
+
+- `<6>` 处，调用 `#storeObject(...)` 方法，将映射创建的结果对象添加到 `ResultHandler.resultList` 中保存。详细解析，等下看 [「3.1.2.3.3 storeObject」](https://svip.iocoder.cn/MyBatis/executor-4/#) 。
+
+##### 3.1.2.3.1 resolveDiscriminatedResultMap
+
+`#resolveDiscriminatedResultMap(ResultSet rs, ResultMap resultMap, String columnPrefix)` 方法，根据该行记录以及 `ResultMap.discriminator` ，决定映射使用的 ResultMap 对象。代码如下：
+
+```
+// DefaultResultSetHandler.java
+
+public ResultMap resolveDiscriminatedResultMap(ResultSet rs, ResultMap resultMap, String columnPrefix) throws SQLException {
+    // 记录已经处理过的 Discriminator 对应的 ResultMap 的编号
+    Set<String> pastDiscriminators = new HashSet<>();
+    // 如果存在 Discriminator 对象，则基于其获得 ResultMap 对象
+    Discriminator discriminator = resultMap.getDiscriminator();
+    while (discriminator != null) { // 因为 Discriminator 可以嵌套 Discriminator ，所以是一个递归的过程
+        // 获得 Discriminator 的指定字段，在 ResultSet 中该字段的值
+        final Object value = getDiscriminatorValue(rs, discriminator, columnPrefix);
+        // 从 Discriminator 获取该值对应的 ResultMap 的编号
+        final String discriminatedMapId = discriminator.getMapIdFor(String.valueOf(value));
+        // 如果存在，则使用该 ResultMap 对象
+        if (configuration.hasResultMap(discriminatedMapId)) {
+            // 获得该 ResultMap 对象
+            resultMap = configuration.getResultMap(discriminatedMapId);
+            // 判断，如果出现“重复”的情况，结束循环
+            Discriminator lastDiscriminator = discriminator;
+            discriminator = resultMap.getDiscriminator();
+            if (discriminator == lastDiscriminator || !pastDiscriminators.add(discriminatedMapId)) {
+                break;
+            }
+        // 如果不存在，直接结束循环
+        } else {
+            break;
+        }
+    }
+    return resultMap;
+}
+```
+
+- 对于大多数情况下，大家不太会使用 Discriminator 的功能，此处就直接返回 `resultMap` ，不会执行这个很复杂的逻辑。😈 所以，如果看不太懂的胖友，可以略过这个方法，问题也不大。
+
+- 代码比较繁杂，胖友跟着注释看看，甚至可以调试下。其中，`<1>` 处，调用 `#getDiscriminatorValue(ResultSet rs, Discriminator discriminator, String columnPrefix)` 方法，获得 Discriminator 的指定字段，在 ResultSet 中该字段的值。代码如下：
+
+  ```
+  // DefaultResultSetHandler.java
+  
+  /**
+   * 获得 ResultSet 的指定字段的值
+   *
+   * @param rs ResultSet 对象
+   * @param discriminator Discriminator 对象
+   * @param columnPrefix 字段名的前缀
+   * @return 指定字段的值
+   */
+  private Object getDiscriminatorValue(ResultSet rs, Discriminator discriminator, String columnPrefix) throws SQLException {
+      final ResultMapping resultMapping = discriminator.getResultMapping();
+      final TypeHandler<?> typeHandler = resultMapping.getTypeHandler();
+      // 获得 ResultSet 的指定字段的值
+      return typeHandler.getResult(rs, prependPrefix(resultMapping.getColumn(), columnPrefix));
+  }
+  
+  /**
+   * 拼接指定字段的前缀
+   *
+   * @param columnName 字段的名字
+   * @param prefix 前缀
+   * @return prefix + columnName
+   */
+  private String prependPrefix(String columnName, String prefix) {
+      if (columnName == null || columnName.length() == 0 || prefix == null || prefix.length() == 0) {
+          return columnName;
+      }
+      return prefix + columnName;
+  }
+  ```
+
+##### 3.1.2.3.2 getRowValue
+
+`#getRowValue(ResultSetWrapper rsw, ResultMap resultMap, String columnPrefix)` 方法，根据最终确定的 ResultMap 对 ResultSet 中的该行记录进行映射，得到映射后的结果对象。代码如下：
+
+```
+// DefaultResultSetHandler.java
+
+private Object getRowValue(ResultSetWrapper rsw, ResultMap resultMap, String columnPrefix) throws SQLException {
+    // <1> 创建 ResultLoaderMap 对象
+    final ResultLoaderMap lazyLoader = new ResultLoaderMap();
+    // <2> 创建映射后的结果对象
+    Object rowValue = createResultObject(rsw, resultMap, lazyLoader, columnPrefix);
+    // <3> 如果 hasTypeHandlerForResultObject(rsw, resultMap.getType()) 返回 true ，意味着 rowValue 是基本类型，无需执行下列逻辑。
+    if (rowValue != null && !hasTypeHandlerForResultObject(rsw, resultMap.getType())) {
+        // <4> 创建 MetaObject 对象，用于访问 rowValue 对象
+        final MetaObject metaObject = configuration.newMetaObject(rowValue);
+        // <5> foundValues 代表，是否成功映射任一属性。若成功，则为 true ，若失败，则为 false
+        boolean foundValues = this.useConstructorMappings;
+        /// <6.1> 判断是否开启自动映射功能
+        if (shouldApplyAutomaticMappings(resultMap, false)) {
+            // <6.2> 自动映射未明确的列
+            foundValues = applyAutomaticMappings(rsw, resultMap, metaObject, columnPrefix) || foundValues;
+        }
+        // <7> 映射 ResultMap 中明确映射的列
+        foundValues = applyPropertyMappings(rsw, resultMap, metaObject, lazyLoader, columnPrefix) || foundValues;
+        // <8> ↑↑↑ 至此，当前 ResultSet 的该行记录的数据，已经完全映射到结果对象 rowValue 的对应属性种
+        foundValues = lazyLoader.size() > 0 || foundValues;
+        // <9> 如果没有成功映射任意属性，则置空 rowValue 对象。
+        // 当然，如果开启 `configuration.returnInstanceForEmptyRow` 属性，则不置空。默认情况下，该值为 false
+        rowValue = foundValues || configuration.isReturnInstanceForEmptyRow() ? rowValue : null;
+    }
+    return rowValue;
+}
+```
+
+- `<1>` 处，创建 ResultLoaderMap 对象。延迟加载相关。
+
+- `<2>` 处，调用 `#createResultObject(...)` 方法，创建映射后的结果对象。详细解析，见 [「3.1.2.3.2.1 createResultObject」](https://svip.iocoder.cn/MyBatis/executor-4/#) 。😈 mmp ，这个逻辑的嵌套，真的太深太深了。
+
+- `<3>` 处，调用 `#hasTypeHandlerForResultObject(rsw, resultMap.getType())` 方法，返回 `true` ，意味着 `rowValue` 是基本类型，无需执行下列逻辑。代码如下：
+
+  ```
+  // DefaultResultSetHandler.java
+  
+  // 判断是否结果对象是否有 TypeHandler 对象
+  private boolean hasTypeHandlerForResultObject(ResultSetWrapper rsw, Class<?> resultType) {
+      // 如果返回的字段只有一个，则直接判断该字段是否有 TypeHandler 对象
+      if (rsw.getColumnNames().size() == 1) {
+          return typeHandlerRegistry.hasTypeHandler(resultType, rsw.getJdbcType(rsw.getColumnNames().get(0)));
+      }
+      // 判断 resultType 是否有对应的 TypeHandler 对象
+      return typeHandlerRegistry.hasTypeHandler(resultType);
+  }
+  ```
+
+  - 有点绕，胖友可以调试下 `BindingTest#shouldInsertAuthorWithSelectKeyAndDynamicParams()` 方法。
+  - 再例如，`<select resultType="Integer" />` 的情况。
+
+- `<4>` 处，创建 MetaObject 对象，用于访问 `rowValue` 对象。
+
+- `<5>` 处，`foundValues` 代表，是否成功映射任一属性。若成功，则为 `true` ，若失败，则为 `false` 。另外，此处使用 `useConstructorMappings` 作为 `foundValues` 的初始值，原因是，使用了构造方法创建该结果对象，意味着一定找到了任一属性。
+
+- `<6.1>` 处，调用 `#shouldApplyAutomaticMappings(ResultMap resultMap, boolean isNested)` 方法，判断是否使用自动映射的功能。代码如下：
+
+  ```
+  // DefaultResultSetHandler.java
+  
+  private boolean shouldApplyAutomaticMappings(ResultMap resultMap, boolean isNested) {
+      // 判断是否开启自动映射功能
+      if (resultMap.getAutoMapping() != null) {
+          return resultMap.getAutoMapping();
+      } else {
+          // 内嵌查询或嵌套映射时
+          if (isNested) {
+              return AutoMappingBehavior.FULL == configuration.getAutoMappingBehavior(); // 需要 FULL
+          // 普通映射
+          } else {
+              return AutoMappingBehavior.NONE != configuration.getAutoMappingBehavior(); // 需要 PARTIAL 或 FULL
+          }
+      }
+  }
+  ```
+
+  - `org.apache.ibatis.session.AutoMappingBehavior` ，自动映射行为的枚举。代码如下：
+
+    ```
+    // AutoMappingBehavior.java
+    
+    /**
+     * Specifies if and how MyBatis should automatically map columns to fields/properties.
+     *
+     * 自动映射行为的枚举
+     *
+     * @author Eduardo Macarron
+     */
+    public enum AutoMappingBehavior {
+    
+        /**
+         * Disables auto-mapping.
+         *
+         * 禁用自动映射的功能
+         */
+        NONE,
+    
+        /**
+         * Will only auto-map results with no nested result mappings defined inside.
+         *
+         * 开启部分映射的功能
+         */
+        PARTIAL,
+    
+        /**
+         * Will auto-map result mappings of any complexity (containing nested or otherwise).
+         *
+         * 开启全部映射的功能
+         */
+        FULL
+    
+    }
+    ```
+
+    - x
+
+  - `Configuration.autoMappingBehavior` 属性，默认为 `AutoMappingBehavior.PARTIAL` 。
+
+- `<6.2>` 处，调用 `#applyAutomaticMappings(...)` 方法，自动映射未明确的列。代码有点长，所以，详细解析，见 [「3.1.2.3.2.3 applyAutomaticMappings」](https://svip.iocoder.cn/MyBatis/executor-4/#) 。
+
+- `<7>` 处，调用 `#applyPropertyMappings(...)` 方法，映射 ResultMap 中明确映射的列。代码有点长，所以，详细解析，见 [「3.1.2.3.2.4 applyPropertyMappings」](https://svip.iocoder.cn/MyBatis/executor-4/#) 。
+
+- `<8>` 处，↑↑↑ 至此，当前 ResultSet 的该行记录的数据，已经完全映射到结果对象 `rowValue` 的对应属性中。😈 整个过程，非常非常非常长，胖友耐心理解和调试下。
+
+- `<9>` 处，如果没有成功映射任意属性，则置空 rowValue 对象。当然，如果开启 `configuration.returnInstanceForEmptyRow` 属性，则不置空。默认情况下，该值为 `false` 。
+
+###### 3.1.2.3.2.1 createResultObject
+
+`#createResultObject(ResultSetWrapper rsw, ResultMap resultMap, ResultLoaderMap lazyLoader, String columnPrefix)` 方法，创建映射后的结果对象。代码如下：
+
+```
+// DefaultResultSetHandler.java
+
+private Object createResultObject(ResultSetWrapper rsw, ResultMap resultMap, ResultLoaderMap lazyLoader, String columnPrefix) throws SQLException {
+    // <1> useConstructorMappings ，表示是否使用构造方法创建该结果对象。此处将其重置
+    this.useConstructorMappings = false; // reset previous mapping result
+    final List<Class<?>> constructorArgTypes = new ArrayList<>(); // 记录使用的构造方法的参数类型的数组
+    final List<Object> constructorArgs = new ArrayList<>(); // 记录使用的构造方法的参数值的数组
+    // <2> 创建映射后的结果对象
+    Object resultObject = createResultObject(rsw, resultMap, constructorArgTypes, constructorArgs, columnPrefix);
+    if (resultObject != null && !hasTypeHandlerForResultObject(rsw, resultMap.getType())) {
+        // <3> 如果有内嵌的查询，并且开启延迟加载，则创建结果对象的代理对象
+        final List<ResultMapping> propertyMappings = resultMap.getPropertyResultMappings();
+        for (ResultMapping propertyMapping : propertyMappings) {
+            // issue gcode #109 && issue #149
+            if (propertyMapping.getNestedQueryId() != null && propertyMapping.isLazy()) {
+                resultObject = configuration.getProxyFactory().createProxy(resultObject, lazyLoader, configuration, objectFactory, constructorArgTypes, constructorArgs);
+                break;
+            }
+        }
+    }
+    // <4> 判断是否使用构造方法创建该结果对象
+    this.useConstructorMappings = resultObject != null && !constructorArgTypes.isEmpty(); // set current mapping result
+    return resultObject;
+}
+```
+
+- `<1>` 处，`useConstructorMappings` ，表示是否使用构造方法创建该结果对象。而此处，将其重置为 `false` 。
+- `<2>` 处，调用 `#createResultObject(...)` 方法，创建映射后的结果对象。详细解析，往下看。😈 再次 mmp ，调用链太长了。
+- `<3>` 处，如果有内嵌的查询，并且开启延迟加载，则调用 `ProxyFactory#createProxy(...)` 方法，创建结果对象的代理对象。详细解析，见 [《精尽 MyBatis 源码分析 —— SQL 执行（五）之延迟加载》](http://svip.iocoder.cn/MyBatis/executor-5) 。
+- `<4>` 处，判断是否使用构造方法创建该结果对象，并设置到 `useConstructorMappings` 中。
+
+------
+
+`#createResultObject(ResultSetWrapper rsw, ResultMap resultMap, List<Class<?>> constructorArgTypes, List<Object> constructorArgs, String columnPrefix)` 方法，创建映射后的结果对象。代码如下：
+
+```
+// DefaultResultSetHandler.java
+
+private Object createResultObject(ResultSetWrapper rsw, ResultMap resultMap, List<Class<?>> constructorArgTypes, List<Object> constructorArgs, String columnPrefix)
+        throws SQLException {
+    final Class<?> resultType = resultMap.getType();
+    final MetaClass metaType = MetaClass.forClass(resultType, reflectorFactory);
+    final List<ResultMapping> constructorMappings = resultMap.getConstructorResultMappings();
+    // 下面，分成四种创建结果对象的情况
+    // <1> 情况一，如果有对应的 TypeHandler 对象，则意味着是基本类型，直接创建对结果应对象
+    if (hasTypeHandlerForResultObject(rsw, resultType)) {
+        return createPrimitiveResultObject(rsw, resultMap, columnPrefix);
+    // 情况二，如果 ResultMap 中，如果定义了 `<constructor />` 节点，则通过反射调用该构造方法，创建对应结果对象
+    } else if (!constructorMappings.isEmpty()) {
+        return createParameterizedResultObject(rsw, resultType, constructorMappings, constructorArgTypes, constructorArgs, columnPrefix);
+    // 情况三，如果有默认的无参的构造方法，则使用该构造方法，创建对应结果对象
+    } else if (resultType.isInterface() || metaType.hasDefaultConstructor()) {
+        return objectFactory.create(resultType);
+    // 情况四，通过自动映射的方式查找合适的构造方法，后使用该构造方法，创建对应结果对象
+    } else if (shouldApplyAutomaticMappings(resultMap, false)) {
+        return createByConstructorSignature(rsw, resultType, constructorArgTypes, constructorArgs, columnPrefix);
+    }
+    // 不支持，抛出 ExecutorException 异常
+    throw new ExecutorException("Do not know how to create an instance of " + resultType);
+}
+```
+
+- 分成四种创建结果对象的情况。
+
+- `<1>` 处，情况一，如果有对应的 TypeHandler 对象，则意味着是基本类型，直接创建对结果应对象。调用 `#createPrimitiveResultObject(ResultSetWrapper rsw, ResultMap resultMap, String columnPrefix)` 方法，代码如下：
+
+  ```
+  // DefaultResultSetHandler.java
+  
+  private Object createPrimitiveResultObject(ResultSetWrapper rsw, ResultMap resultMap, String columnPrefix) throws SQLException {
+      final Class<?> resultType = resultMap.getType();
+      // 获得字段名
+      final String columnName;
+      if (!resultMap.getResultMappings().isEmpty()) {
+          final List<ResultMapping> resultMappingList = resultMap.getResultMappings();
+          final ResultMapping mapping = resultMappingList.get(0);
+          columnName = prependPrefix(mapping.getColumn(), columnPrefix);
+      } else {
+          columnName = rsw.getColumnNames().get(0);
+      }
+      // 获得 TypeHandler 对象
+      final TypeHandler<?> typeHandler = rsw.getTypeHandler(resultType, columnName);
+      // 获得 ResultSet 的指定字段的值
+      return typeHandler.getResult(rsw.getResultSet(), columnName);
+  }
+  ```
+
+- `<2>` 处，情况二，如果 ResultMap 中，如果定义了 `<constructor />` 节点，则通过反射调用该构造方法，创建对应结果对象。调用 `#createParameterizedResultObject(ResultSetWrapper rsw, Class<?> resultType, List<ResultMapping> constructorMappings, List<Class<?>> constructorArgTypes, List<Object> constructorArgs, String columnPrefix)` 方法，代码如下：
+
+  ```
+  // DefaultResultSetHandler.java
+  
+  Object createParameterizedResultObject(ResultSetWrapper rsw, Class<?> resultType, List<ResultMapping> constructorMappings,
+                                         List<Class<?>> constructorArgTypes, List<Object> constructorArgs, String columnPrefix) {
+      // 获得到任一的属性值。即，只要一个结果对象，有一个属性非空，就会设置为 true
+      boolean foundValues = false;
+      for (ResultMapping constructorMapping : constructorMappings) {
+          // 获得参数类型
+          final Class<?> parameterType = constructorMapping.getJavaType();
+          // 获得数据库的字段名
+          final String column = constructorMapping.getColumn();
+          // 获得属性值
+          final Object value;
+          try {
+              // 如果是内嵌的查询，则获得内嵌的值
+              if (constructorMapping.getNestedQueryId() != null) {
+                  value = getNestedQueryConstructorValue(rsw.getResultSet(), constructorMapping, columnPrefix);
+              // 如果是内嵌的 resultMap ，则递归 getRowValue 方法，获得对应的属性值
+              } else if (constructorMapping.getNestedResultMapId() != null) {
+                  final ResultMap resultMap = configuration.getResultMap(constructorMapping.getNestedResultMapId());
+                  value = getRowValue(rsw, resultMap, constructorMapping.getColumnPrefix());
+              // 最常用的情况，直接使用 TypeHandler 获取当前 ResultSet 的当前行的指定字段的值
+              } else {
+                  final TypeHandler<?> typeHandler = constructorMapping.getTypeHandler();
+                  value = typeHandler.getResult(rsw.getResultSet(), prependPrefix(column, columnPrefix));
+              }
+          } catch (ResultMapException | SQLException e) {
+              throw new ExecutorException("Could not process result for mapping: " + constructorMapping, e);
+          }
+          // 添加到 constructorArgTypes 和 constructorArgs 中
+          constructorArgTypes.add(parameterType);
+          constructorArgs.add(value);
+          // 判断是否获得到属性值
+          foundValues = value != null || foundValues;
+      }
+      // 查找 constructorArgTypes 对应的构造方法
+      // 查找到后，传入 constructorArgs 作为参数，创建结果对象
+      return foundValues ? objectFactory.create(resultType, constructorArgTypes, constructorArgs) : null;
+  }
+  ```
+
+  - 代码比较简单，胖友看下注释即可。
+  - 当然，里面的 `#getNestedQueryConstructorValue(ResultSet rs, ResultMapping constructorMapping, String columnPrefix)` 方法的逻辑，还是略微比较复杂的。所以，我们在讲完情况三、情况四，我们再来看看它的实现。😈 写到这里，艿艿的心里无比苦闷。详细解析，见 [「3.1.2.3.2.2 getNestedQueryConstructorValue」](https://svip.iocoder.cn/MyBatis/executor-4/#) 。
+
+- `<3>` 处，情况三，如果有默认的无参的构造方法，则使用该构造方法，创建对应结果对象。
+
+- `<4>` 处，情况四，通过自动映射的方式查找合适的构造方法，后使用该构造方法，创建对应结果对象。调用 `#createByConstructorSignature(ResultSetWrapper rsw, Class<?> resultType, List<Class<?>> constructorArgTypes, List<Object> constructorArgs, String columnPrefix)` 方法，代码如下：
+
+  ```
+  // DefaultResultSetHandler.java
+  
+  private Object createByConstructorSignature(ResultSetWrapper rsw, Class<?> resultType, List<Class<?>> constructorArgTypes, List<Object> constructorArgs,
+                                              String columnPrefix) throws SQLException {
+      // <1> 获得所有构造方法
+      final Constructor<?>[] constructors = resultType.getDeclaredConstructors();
+      // <2> 获得默认构造方法
+      final Constructor<?> defaultConstructor = findDefaultConstructor(constructors);
+      // <3> 如果有默认构造方法，使用该构造方法，创建结果对象
+      if (defaultConstructor != null) {
+          return createUsingConstructor(rsw, resultType, constructorArgTypes, constructorArgs, columnPrefix, defaultConstructor);
+      } else {
+          // <4> 遍历所有构造方法，查找符合的构造方法，创建结果对象
+          for (Constructor<?> constructor : constructors) {
+              if (allowedConstructorUsingTypeHandlers(constructor, rsw.getJdbcTypes())) {
+                  return createUsingConstructor(rsw, resultType, constructorArgTypes, constructorArgs, columnPrefix, constructor);
+              }
+          }
+      }
+      throw new ExecutorException("No constructor found in " + resultType.getName() + " matching " + rsw.getClassNames());
+  }
+  ```
+
+  - `<1>` 处，获得所有构造方法。
+
+  - `<2>` 处，调用 `#findDefaultConstructor(final Constructor<?>[] constructors)` 方法，获得默认构造方法。代码如下：
+
+    ```
+    // DefaultResultSetHandler.java
+    
+    private Constructor<?> findDefaultConstructor(final Constructor<?>[] constructors) {
+        // 构造方法只有一个，直接返回
+        if (constructors.length == 1) return constructors[0];
+        // 获得使用 @AutomapConstructor 注解的构造方法
+        for (final Constructor<?> constructor : constructors) {
+            if (constructor.isAnnotationPresent(AutomapConstructor.class)) {
+                return constructor;
+            }
+        }
+        return null;
+    }
+    ```
+
+    - 两种情况，比较简单。
+
+  - `<3>` 处，如果有默认构造方法，调用 `#createUsingConstructor(ResultSetWrapper rsw, Class<?> resultType, List<Class<?>> constructorArgTypes, List<Object> constructorArgs, String columnPrefix, Constructor<?> constructor)` 方法，使用该构造方法，创建结果对象。代码如下：
+
+    ```
+    // DefaultResultSetHandler.java
+    
+    private Object createUsingConstructor(ResultSetWrapper rsw, Class<?> resultType, List<Class<?>> constructorArgTypes, List<Object> constructorArgs, String columnPrefix, Constructor<?> constructor) throws SQLException {
+        boolean foundValues = false;
+        for (int i = 0; i < constructor.getParameterTypes().length; i++) {
+            // 获得参数类型
+            Class<?> parameterType = constructor.getParameterTypes()[i];
+            // 获得数据库的字段名
+            String columnName = rsw.getColumnNames().get(i);
+            // 获得 TypeHandler 对象
+            TypeHandler<?> typeHandler = rsw.getTypeHandler(parameterType, columnName);
+            // 获取当前 ResultSet 的当前行的指定字段的值
+            Object value = typeHandler.getResult(rsw.getResultSet(), prependPrefix(columnName, columnPrefix));
+            // 添加到 constructorArgTypes 和 constructorArgs 中
+            constructorArgTypes.add(parameterType);
+            constructorArgs.add(value);
+            // 判断是否获得到属性值
+            foundValues = value != null || foundValues;
+        }
+        // 查找 constructorArgTypes 对应的构造方法
+        // 查找到后，传入 constructorArgs 作为参数，创建结果对象
+        return foundValues ? objectFactory.create(resultType, constructorArgTypes, constructorArgs) : null;
+    }
+    ```
+
+    - 从代码实现上，和 `#createParameterizedResultObject(...)` 方法，类似。
+
+  - `<4>` 处，遍历所有构造方法，调用 `#allowedConstructorUsingTypeHandlers(final Constructor<?> constructor, final List<JdbcType> jdbcTypes)` 方法，查找符合的构造方法，后创建结果对象。代码如下：
+
+    ```
+    // DefaultResultSetHandler.java
+    
+    private boolean allowedConstructorUsingTypeHandlers(final Constructor<?> constructor, final List<JdbcType> jdbcTypes) {
+        final Class<?>[] parameterTypes = constructor.getParameterTypes();
+        // 结果集的返回字段的数量，要和构造方法的参数数量，一致
+        if (parameterTypes.length != jdbcTypes.size()) return false;
+        // 每个构造方法的参数，和对应的返回字段，都要有对应的 TypeHandler 对象
+        for (int i = 0; i < parameterTypes.length; i++) {
+            if (!typeHandlerRegistry.hasTypeHandler(parameterTypes[i], jdbcTypes.get(i))) {
+                return false;
+            }
+        }
+        // 返回匹配
+        return true;
+    }
+    ```
+
+    - 基于结果集的返回字段和构造方法的参数做比较。
+
+###### 3.1.2.3.2.2 getNestedQueryConstructorValue 嵌套查询
+
+> 老艿艿：冲鸭！！！太冗长了！！！各种各种各种！！！！情况！！！！！
+
+`#getNestedQueryConstructorValue(ResultSet rs, ResultMapping constructorMapping, String columnPrefix)` 方法，获得嵌套查询的值。代码如下：
+
+```
+// DefaultResultSetHandler.java
+
+private Object getNestedQueryConstructorValue(ResultSet rs, ResultMapping constructorMapping, String columnPrefix) throws SQLException {
+    // <1> 获得内嵌查询的编号
+    final String nestedQueryId = constructorMapping.getNestedQueryId();
+    // <1> 获得内嵌查询的 MappedStatement 对象
+    final MappedStatement nestedQuery = configuration.getMappedStatement(nestedQueryId);
+    // <1> 获得内嵌查询的参数类型
+    final Class<?> nestedQueryParameterType = nestedQuery.getParameterMap().getType();
+    // <2> 获得内嵌查询的参数对象
+    final Object nestedQueryParameterObject = prepareParameterForNestedQuery(rs, constructorMapping, nestedQueryParameterType, columnPrefix);
+    Object value = null;
+    // <3> 执行查询
+    if (nestedQueryParameterObject != null) {
+        // <3.1> 获得 BoundSql 对象
+        final BoundSql nestedBoundSql = nestedQuery.getBoundSql(nestedQueryParameterObject);
+        // <3.2> 获得 CacheKey 对象
+        final CacheKey key = executor.createCacheKey(nestedQuery, nestedQueryParameterObject, RowBounds.DEFAULT, nestedBoundSql);
+        final Class<?> targetType = constructorMapping.getJavaType();
+        // <3.3> 创建 ResultLoader 对象
+        final ResultLoader resultLoader = new ResultLoader(configuration, executor, nestedQuery, nestedQueryParameterObject, targetType, key, nestedBoundSql);
+        // <3.3> 加载结果
+        value = resultLoader.loadResult();
+    }
+    return value;
+}
+```
+
+- 关于这个方法，胖友可以调试 `BaseExecutorTest#shouldFetchOneOrphanedPostWithNoBlog()` 这个单元测试方法。
+
+- `<1>` 处，获得内嵌查询的**编号**、**MappedStatement 对象**、**参数类型**。
+
+- `<2>` 处，调用 `#prepareParameterForNestedQuery(ResultSet rs, ResultMapping resultMapping, Class<?> parameterType, String columnPrefix)` 方法，获得内嵌查询的**参数对象**。代码如下：
+
+  ```
+  // DefaultResultSetHandler.java
+  
+  // 获得内嵌查询的参数类型
+  private Object prepareParameterForNestedQuery(ResultSet rs, ResultMapping resultMapping, Class<?> parameterType, String columnPrefix) throws SQLException {
+      if (resultMapping.isCompositeResult()) { // ② 组合
+          return prepareCompositeKeyParameter(rs, resultMapping, parameterType, columnPrefix);
+      } else { // ① 普通
+          return prepareSimpleKeyParameter(rs, resultMapping, parameterType, columnPrefix);
+      }
+  }
+  
+  // ① 获得普通类型的内嵌查询的参数对象
+  private Object prepareSimpleKeyParameter(ResultSet rs, ResultMapping resultMapping, Class<?> parameterType, String columnPrefix) throws SQLException {
+      // 获得 TypeHandler 对象
+      final TypeHandler<?> typeHandler;
+      if (typeHandlerRegistry.hasTypeHandler(parameterType)) {
+          typeHandler = typeHandlerRegistry.getTypeHandler(parameterType);
+      } else {
+          typeHandler = typeHandlerRegistry.getUnknownTypeHandler();
+      }
+      // 获得指定字段的值
+      return typeHandler.getResult(rs, prependPrefix(resultMapping.getColumn(), columnPrefix));
+  }
+  
+  // ② 获得组合类型的内嵌查询的参数对象
+  private Object prepareCompositeKeyParameter(ResultSet rs, ResultMapping resultMapping, Class<?> parameterType, String columnPrefix) throws SQLException {
+      // 创建参数对象
+      final Object parameterObject = instantiateParameterObject(parameterType);
+      // 创建参数对象的 MetaObject 对象，可对其进行访问
+      final MetaObject metaObject = configuration.newMetaObject(parameterObject);
+      boolean foundValues = false;
+      // 遍历组合的所有字段
+      for (ResultMapping innerResultMapping : resultMapping.getComposites()) {
+          // 获得属性类型
+          final Class<?> propType = metaObject.getSetterType(innerResultMapping.getProperty());
+          // 获得对应的 TypeHandler 对象
+          final TypeHandler<?> typeHandler = typeHandlerRegistry.getTypeHandler(propType);
+          // 获得指定字段的值
+          final Object propValue = typeHandler.getResult(rs, prependPrefix(innerResultMapping.getColumn(), columnPrefix));
+          // issue #353 & #560 do not execute nested query if key is null
+          // 设置到 parameterObject 中，通过 metaObject
+          if (propValue != null) {
+              metaObject.setValue(innerResultMapping.getProperty(), propValue);
+              foundValues = true; // 标记 parameterObject 非空对象
+          }
+      }
+      // 返回参数对象
+      return foundValues ? parameterObject : null;
+  }
+  
+  // ② 创建参数对象
+  private Object instantiateParameterObject(Class<?> parameterType) {
+      if (parameterType == null) {
+          return new HashMap<>();
+      } else if (ParamMap.class.equals(parameterType)) {
+          return new HashMap<>(); // issue #649
+      } else {
+          return objectFactory.create(parameterType);
+      }
+  }
+  ```
+
+  - 虽然代码比较长，但是非常简单。注意下，艿艿添加了 `①` 和 `②` 两个序号，分别对应两种情况。
+
+- ```
+  <3>
+  ```
+
+   
+
+  处，整体是，执行查询，获得值。
+
+  - `<3.1>` 处，调用 `MappedStatement#getBoundSql(Object parameterObject)` 方法，获得 BoundSql 对象。
+  - `<3.2>` 处，创建 CacheKey 对象。
+  - `<3.3>` 处，创建 ResultLoader 对象，并调用 `ResultLoader#loadResult()` 方法，加载结果。详细解析，见 [《精尽 MyBatis 源码分析 —— SQL 执行（五）之延迟加载》](http://svip.iocoder.cn/MyBatis/executor-5) 。
+
+###### 3.1.2.3.2.3 applyAutomaticMappings
+
+`#createResultObject(ResultSetWrapper rsw, ResultMap resultMap, List<Class<?>> constructorArgTypes, List<Object> constructorArgs, String columnPrefix)` 方法，创建映射后的结果对象。代码如下：
+
+```
+// DefaultResultSetHandler.java
+
+private boolean applyAutomaticMappings(ResultSetWrapper rsw, ResultMap resultMap, MetaObject metaObject, String columnPrefix) throws SQLException {
+    // <1> 获得 UnMappedColumnAutoMapping 数组
+    List<UnMappedColumnAutoMapping> autoMapping = createAutomaticMappings(rsw, resultMap, metaObject, columnPrefix);
+    boolean foundValues = false;
+    if (!autoMapping.isEmpty()) {
+        // <2> 遍历 UnMappedColumnAutoMapping 数组
+        for (UnMappedColumnAutoMapping mapping : autoMapping) {
+            // 获得指定字段的值
+            final Object value = mapping.typeHandler.getResult(rsw.getResultSet(), mapping.column);
+            // 若非空，标记 foundValues 有值
+            if (value != null) {
+                foundValues = true;
+            }
+            // 设置到 parameterObject 中，通过 metaObject
+            if (value != null || (configuration.isCallSettersOnNulls() && !mapping.primitive)) {
+                // gcode issue #377, call setter on nulls (value is not 'found')
+                metaObject.setValue(mapping.property, value);
+            }
+        }
+    }
+    return foundValues;
+}
+```
+
+- `<1>` 处，调用 `#createAutomaticMappings(ResultSetWrapper rsw, ResultMap resultMap, MetaObject metaObject, String columnPrefix)` 方法，获得 UnMappedColumnAutoMapping 数组。代码如下：
+
+  ```
+  // DefaultResultSetHandler.java
+  
+  private List<UnMappedColumnAutoMapping> createAutomaticMappings(ResultSetWrapper rsw, ResultMap resultMap, MetaObject metaObject, String columnPrefix) throws SQLException {
+      // 生成 autoMappingsCache 的 KEY
+      final String mapKey = resultMap.getId() + ":" + columnPrefix;
+      // 从缓存 autoMappingsCache 中，获得 UnMappedColumnAutoMapping 数组
+      List<UnMappedColumnAutoMapping> autoMapping = autoMappingsCache.get(mapKey);
+      // 如果获取不到，则进行初始化
+      if (autoMapping == null) {
+          autoMapping = new ArrayList<>();
+          // 获得未 mapped 的字段的名字的数组
+          final List<String> unmappedColumnNames = rsw.getUnmappedColumnNames(resultMap, columnPrefix);
+          // 遍历 unmappedColumnNames 数组
+          for (String columnName : unmappedColumnNames) {
+              // 获得属性名
+              String propertyName = columnName;
+              if (columnPrefix != null && !columnPrefix.isEmpty()) {
+                  // When columnPrefix is specified,
+                  // ignore columns without the prefix.
+                  if (columnName.toUpperCase(Locale.ENGLISH).startsWith(columnPrefix)) {
+                      propertyName = columnName.substring(columnPrefix.length());
+                  } else {
+                      continue;
+                  }
+              }
+              // 从结果对象的 metaObject 中，获得对应的属性名
+              final String property = metaObject.findProperty(propertyName, configuration.isMapUnderscoreToCamelCase());
+              // 获得到属性名，并且可以进行设置
+              if (property != null && metaObject.hasSetter(property)) {
+                  // 排除已映射的属性
+                  if (resultMap.getMappedProperties().contains(property)) {
+                      continue;
+                  }
+                  // 获得属性的类型
+                  final Class<?> propertyType = metaObject.getSetterType(property);
+                  // 判断是否有对应的 TypeHandler 对象。如果有，则创建 UnMappedColumnAutoMapping 对象，并添加到 autoMapping 中
+                  if (typeHandlerRegistry.hasTypeHandler(propertyType, rsw.getJdbcType(columnName))) {
+                      final TypeHandler<?> typeHandler = rsw.getTypeHandler(propertyType, columnName);
+                      autoMapping.add(new UnMappedColumnAutoMapping(columnName, property, typeHandler, propertyType.isPrimitive()));
+                  // 如果没有，则执行 AutoMappingUnknownColumnBehavior 对应的逻辑
+                  } else {
+                      configuration.getAutoMappingUnknownColumnBehavior()
+                              .doAction(mappedStatement, columnName, property, propertyType);
+                  }
+              // 如果没有属性，或者无法设置，则则执行 AutoMappingUnknownColumnBehavior 对应的逻辑
+              } else {
+                  configuration.getAutoMappingUnknownColumnBehavior()
+                          .doAction(mappedStatement, columnName, (property != null) ? property : propertyName, null);
+              }
+          }
+          // 添加到缓存中
+          autoMappingsCache.put(mapKey, autoMapping);
+      }
+      return autoMapping;
+  }
+  ```
+
+  - 虽然代码比较长，但是逻辑很简单。遍历未 mapped 的字段的名字的数组，映射每一个字段在**结果对象**的相同名字的属性，最终生成 UnMappedColumnAutoMapping 对象。
+
+  - UnMappedColumnAutoMapping ，是 DefaultResultSetHandler 的内部静态类，未 mapped 字段自动映射后的对象。代码如下：
+
+    ```
+    // DefaultResultSetHandler.java
+    
+    private static class UnMappedColumnAutoMapping {
+    
+        /**
+         * 字段名
+         */
+        private final String column;
+        /**
+         * 属性名
+         */
+        private final String property;
+        /**
+         * TypeHandler 处理器
+         */
+        private final TypeHandler<?> typeHandler;
+        /**
+         * 是否为基本属性
+         */
+        private final boolean primitive;
+    
+        public UnMappedColumnAutoMapping(String column, String property, TypeHandler<?> typeHandler, boolean primitive) {
+            this.column = column;
+            this.property = property;
+            this.typeHandler = typeHandler;
+            this.primitive = primitive;
+        }
+    
+    }
+    ```
+
+    - x
+
+  - 当找不到映射的属性时，会调用 `AutoMappingUnknownColumnBehavior#doAction(MappedStatement mappedStatement, String columnName, String propertyName, Class<?> propertyType)` 方法，执行相应的逻辑。比较简单，胖友直接看 [`org.apache.ibatis.session.AutoMappingUnknownColumnBehavior`](https://github.com/YunaiV/mybatis-3/blob/master/src/main/java/org/apache/ibatis/session/AutoMappingUnknownColumnBehavior.java) 即可。
+
+  - `Configuration.autoMappingUnknownColumnBehavior` 为 `AutoMappingUnknownColumnBehavior.NONE` ，即**不处理**。
+
+- `<2>` 处，遍历 UnMappedColumnAutoMapping 数组，获得指定字段的值，设置到 `parameterObject` 中，通过 `metaObject` 。
+
+###### 3.1.2.3.2.4 applyPropertyMappings
+
+`#applyPropertyMappings(ResultSetWrapper rsw, ResultMap resultMap, MetaObject metaObject, ResultLoaderMap lazyLoader, String columnPrefix)` 方法，映射 ResultMap 中明确映射的列。代码如下：
+
+```
+// DefaultResultSetHandler.java
+
+private boolean applyPropertyMappings(ResultSetWrapper rsw, ResultMap resultMap, MetaObject metaObject, ResultLoaderMap lazyLoader, String columnPrefix)
+        throws SQLException {
+    // 获得 mapped 的字段的名字的数组
+    final List<String> mappedColumnNames = rsw.getMappedColumnNames(resultMap, columnPrefix);
+    boolean foundValues = false;
+    // 遍历 ResultMapping 数组
+    final List<ResultMapping> propertyMappings = resultMap.getPropertyResultMappings();
+    for (ResultMapping propertyMapping : propertyMappings) {
+        // 获得字段名
+        String column = prependPrefix(propertyMapping.getColumn(), columnPrefix);
+        if (propertyMapping.getNestedResultMapId() != null) {
+            // the user added a column attribute to a nested result map, ignore it
+            column = null;
+        }
+        if (propertyMapping.isCompositeResult() // 组合
+                || (column != null && mappedColumnNames.contains(column.toUpperCase(Locale.ENGLISH))) // 属于 mappedColumnNames
+                || propertyMapping.getResultSet() != null) { // 存储过程
+            // <1> 获得指定字段的值
+            Object value = getPropertyMappingValue(rsw.getResultSet(), metaObject, propertyMapping, lazyLoader, columnPrefix);
+            // issue #541 make property optional
+            final String property = propertyMapping.getProperty();
+            if (property == null) {
+                continue;
+            // 存储过程相关，忽略
+            } else if (value == DEFERED) {
+                foundValues = true;
+                continue;
+            }
+            // 标记获取到任一属性
+            if (value != null) {
+                foundValues = true;
+            }
+            // 设置到 parameterObject 中，通过 metaObject
+            if (value != null || (configuration.isCallSettersOnNulls() && !metaObject.getSetterType(property).isPrimitive())) {
+                // gcode issue #377, call setter on nulls (value is not 'found')
+                metaObject.setValue(property, value);
+            }
+        }
+    }
+    return foundValues;
+}
+```
+
+- 虽然代码比较长，但是逻辑很简单。胖友自己瞅瞅。
+
+- 在 `<1>` 处，调用 `#getPropertyMappingValue(ResultSet rs, MetaObject metaResultObject, ResultMapping propertyMapping, ResultLoaderMap lazyLoader, String columnPrefix)` 方法，获得指定字段的值。代码如下：
+
+  ```
+  // DefaultResultSetHandler.java
+  
+  private Object getPropertyMappingValue(ResultSet rs, MetaObject metaResultObject, ResultMapping propertyMapping, ResultLoaderMap lazyLoader, String columnPrefix)
+          throws SQLException {
+      // <2> 内嵌查询，获得嵌套查询的值
+      if (propertyMapping.getNestedQueryId() != null) {
+          return getNestedQueryMappingValue(rs, metaResultObject, propertyMapping, lazyLoader, columnPrefix);
+      // 存储过程相关，忽略
+      } else if (propertyMapping.getResultSet() != null) {
+          addPendingChildRelation(rs, metaResultObject, propertyMapping);   // TODO is that OK?
+          return DEFERED;
+      // 普通，直接获得指定字段的值
+      } else {
+          final TypeHandler<?> typeHandler = propertyMapping.getTypeHandler();
+          final String column = prependPrefix(propertyMapping.getColumn(), columnPrefix);
+          return typeHandler.getResult(rs, column);
+      }
+  }
+  ```
+
+  - 在 `<2>` 处，我们又碰到了一个内嵌查询，调用 `#getNestedQueryMappingValue(ResultSet rs, MetaObject metaResultObject, ResultMapping propertyMapping, ResultLoaderMap lazyLoader, String columnPrefix)` 方法，获得嵌套查询的值。详细解析，见 [「」](https://svip.iocoder.cn/MyBatis/executor-4/#) 。
+
+###### 3.1.2.3.2.5 getNestedQueryMappingValue 嵌套查询
+
+`#getNestedQueryMappingValue(ResultSet rs, MetaObject metaResultObject, ResultMapping propertyMapping, ResultLoaderMap lazyLoader, String columnPrefix)` 方法，获得嵌套查询的值。代码如下：
+
+```
+// DefaultResultSetHandler.java
+
+private Object getNestedQueryMappingValue(ResultSet rs, MetaObject metaResultObject, ResultMapping propertyMapping, ResultLoaderMap lazyLoader, String columnPrefix)
+        throws SQLException {
+    // 获得内嵌查询的编号
+    final String nestedQueryId = propertyMapping.getNestedQueryId();
+    // 获得属性名
+    final String property = propertyMapping.getProperty();
+    // 获得内嵌查询的 MappedStatement 对象
+    final MappedStatement nestedQuery = configuration.getMappedStatement(nestedQueryId);
+    // 获得内嵌查询的参数类型
+    final Class<?> nestedQueryParameterType = nestedQuery.getParameterMap().getType();
+    // 获得内嵌查询的参数对象
+    final Object nestedQueryParameterObject = prepareParameterForNestedQuery(rs, propertyMapping, nestedQueryParameterType, columnPrefix);
+    Object value = null;
+    if (nestedQueryParameterObject != null) {
+        // 获得 BoundSql 对象
+        final BoundSql nestedBoundSql = nestedQuery.getBoundSql(nestedQueryParameterObject);
+        // 获得 CacheKey 对象
+        final CacheKey key = executor.createCacheKey(nestedQuery, nestedQueryParameterObject, RowBounds.DEFAULT, nestedBoundSql);
+        final Class<?> targetType = propertyMapping.getJavaType();
+        // <1> 检查缓存中已存在
+        if (executor.isCached(nestedQuery, key)) { //  有缓存
+            // <2.1> 创建 DeferredLoad 对象，并通过该 DeferredLoad 对象从缓存中加载结采对象
+            executor.deferLoad(nestedQuery, metaResultObject, property, key, targetType);
+            // <2.2> 返回已定义
+            value = DEFERED;
+        // 检查缓存中不存在
+        } else { // 无缓存
+            // <3.1> 创建 ResultLoader 对象
+            final ResultLoader resultLoader = new ResultLoader(configuration, executor, nestedQuery, nestedQueryParameterObject, targetType, key, nestedBoundSql);
+            // <3.2> 如果要求延迟加载，则延迟加载
+            if (propertyMapping.isLazy()) {
+                // 如果该属性配置了延迟加载，则将其添加到 `ResultLoader.loaderMap` 中，等待真正使用时再执行嵌套查询并得到结果对象。
+                lazyLoader.addLoader(property, metaResultObject, resultLoader);
+                // 返回已定义
+                value = DEFERED;
+            // <3.3> 如果不要求延迟加载，则直接执行加载对应的值
+            } else {
+                value = resultLoader.loadResult();
+            }
+        }
+    }
+    return value;
+}
+```
+
+- 和
+
+   
+
+  「3.1.2.3.2.2 getNestedQueryConstructorValue」
+
+   
+
+  一样，也是
+
+  嵌套查询
+
+  。所以，从整体代码的实现上，也是非常
+
+  类似
+
+  的。差别在于：
+
+  - `#getNestedQueryConstructorValue(...)` 方法，用于构造方法需要用到的嵌套查询的值，它是**不用**考虑延迟加载的。
+  - `#getNestedQueryMappingValue(...)` 方法，用于 setting 方法需要用到的嵌套查询的值，它是**需要**考虑延迟加载的。
+
+- `<1>` 处，调用 `Executor#isCached(MappedStatement ms, CacheKey key)` 方法，检查缓存中已存在。下面，我们分成两种情况来解析。
+
+- ========== 有缓存 ==========
+
+- `<2.1>` 处，调用 `Executor#deferLoad(...)` 方法，创建 DeferredLoad 对象，并通过该 DeferredLoad 对象从缓存中加载结采对象。详细解析，见 [《精尽 MyBatis 源码分析 —— SQL 执行（五）之延迟加载》](http://svip.iocoder.cn/MyBatis/executor-5) 。
+
+- `<2.2>` 处，返回已定义 `DEFERED` 。
+
+- ========== 有缓存 ==========
+
+- `<3.1>` 处，创建 ResultLoader 对象。
+
+- ```
+  <3.2>
+  ```
+
+   
+
+  处，如果要求延迟加载，则延迟加载。
+
+  - `<3.2.1>` 处，调用 `ResultLoader#addLoader(...)` 方法，如果该属性配置了延迟加载，则将其添加到 `ResultLoader.loaderMap` 中，等待真正使用时再执行嵌套查询并得到结果对象。详细解析，见 [《精尽 MyBatis 源码分析 —— SQL 执行（五）之延迟加载》](http://svip.iocoder.cn/MyBatis/executor-5) 。
+
+- `<3.3>` 处，如果不要求延迟加载，则调用 `ResultLoader#loadResult()` 方法，直接执行加载对应的值。
+
+##### 3.1.2.3.3 storeObject
+
+`#storeObject(ResultHandler<?> resultHandler, DefaultResultContext<Object> resultContext, Object rowValue, ResultMapping parentMapping, ResultSet rs)` 方法，将映射创建的结果对象添加到 `ResultHandler.resultList` 中保存。代码如下：
+
+```
+// DefaultResultSetHandler.java
+
+private void storeObject(ResultHandler<?> resultHandler, DefaultResultContext<Object> resultContext, Object rowValue, ResultMapping parentMapping, ResultSet rs) throws SQLException {
+    // 暂时忽略，这个情况，只有存储过程会出现
+    if (parentMapping != null) {
+        linkToParents(rs, parentMapping, rowValue);
+    } else {
+        callResultHandler(resultHandler, resultContext, rowValue);
+    }
+}
+
+@SuppressWarnings("unchecked" /* because ResultHandler<?> is always ResultHandler<Object>*/)
+// 调用 ResultHandler ，进行结果的处理
+private void callResultHandler(ResultHandler<?> resultHandler, DefaultResultContext<Object> resultContext, Object rowValue) {
+    // 设置结果对象到 resultContext 中
+    resultContext.nextResultObject(rowValue);
+    // <x> 使用 ResultHandler 处理结果。
+    // 如果使用 DefaultResultHandler 实现类的情况，会将映射创建的结果对象添加到 ResultHandler.resultList 中保存
+    ((ResultHandler<Object>) resultHandler).handleResult(resultContext);
+}
+```
+
+- 逻辑比较简单，认真看下注释，特别是 `<x>` 处。
+
+#### 3.1.2.4 handleRowValuesForNestedResultMap 嵌套映射
+
+可能胖友对**嵌套映射**的概念不是很熟悉，胖友可以调试 `AncestorRefTest#testAncestorRef()` 这个单元测试方法。
+
+------
+
+> 老艿艿：本小节，还是建议看 [《MyBatis 技术内幕》](https://item.jd.com/12125531.html) 的 [「3.3.4 嵌套映射」](https://svip.iocoder.cn/MyBatis/executor-4/#) 小节。因为，它提供了比较好的这块逻辑的原理讲解，并且配置了大量的图。
+>
+> 😈 精力有限，后续补充哈。
+> 😜 实际是，因为艿艿比较少用嵌套映射，所以对这块逻辑，不是很感兴趣。
+
+`#handleRowValuesForNestedResultMap(ResultSetWrapper rsw, ResultMap resultMap, ResultHandler<?> resultHandler, RowBounds rowBounds, ResultMapping parentMapping)` 方法，处理嵌套**映射**的结果。代码如下：
+
+```
+// DefaultResultSetHandler.java
+```
+
+- TODO 9999 状态不太好，有点写不太明白。不感兴趣的胖友，可以跳过。感兴趣的胖友，可以看看 [《MyBatis 技术内幕》](https://item.jd.com/12125531.html) 的 [「3.3.4 嵌套映射」](https://svip.iocoder.cn/MyBatis/executor-4/#) 小节。
+
+### 3.1.3 handleCursorResultSets
+
+`#handleCursorResultSets(Statement stmt)` 方法，处理 `java.sql.ResultSet` 成 Cursor 对象。代码如下：
+
+```
+// DefaultResultSetHandler.java
+
+@Override
+public <E> Cursor<E> handleCursorResultSets(Statement stmt) throws SQLException {
+    ErrorContext.instance().activity("handling cursor results").object(mappedStatement.getId());
+
+    // 获得首个 ResultSet 对象，并封装成 ResultSetWrapper 对象
+    ResultSetWrapper rsw = getFirstResultSet(stmt);
+
+    // 游标方式的查询，只允许一个 ResultSet 对象。因此，resultMaps 数组的数量，元素只能有一个
+    List<ResultMap> resultMaps = mappedStatement.getResultMaps();
+    int resultMapCount = resultMaps.size();
+    validateResultMapsCount(rsw, resultMapCount);
+    if (resultMapCount != 1) {
+        throw new ExecutorException("Cursor results cannot be mapped to multiple resultMaps");
+    }
+
+    // 获得 ResultMap 对象，后创建 DefaultCursor 对象
+    ResultMap resultMap = resultMaps.get(0);
+    return new DefaultCursor<>(this, resultMap, rsw, rowBounds);
+}
+```
+
+- 最终，创建成 DefaultCursor 对象。详细解析，见 [「6. DefaultCursor」](https://svip.iocoder.cn/MyBatis/executor-4/#) 。
+- 可能很多人没用 MyBatis Cursor 功能，所以可以看看 [《Mybatis 3.4.0 Cursor的使用》](https://www.jianshu.com/p/97d96201295b) 。
+
+# 4. ResultContext
+
+> 老艿艿：这个类，大体看看每个方法的用途，结合上文一起理解即可。
+
+`org.apache.ibatis.session.ResultContext` ，结果上下文接口。代码如下：
+
+```
+// ResultContext.java
+
+public interface ResultContext<T> {
+
+    /**
+     * @return 当前结果对象
+     */
+    T getResultObject();
+
+    /**
+     * @return 总的结果对象的数量
+     */
+    int getResultCount();
+
+    /**
+     * @return 是否暂停
+     */
+    boolean isStopped();
+
+    /**
+     * 暂停
+     */
+    void stop();
+
+}
+```
+
+## 4.1 DefaultResultContext
+
+`org.apache.ibatis.executor.result.DefaultResultContext` ，实现 ResultContext 接口，默认的 ResultContext 的实现类。代码如下：
+
+```
+// DefaultResultContext.java
+
+public class DefaultResultContext<T> implements ResultContext<T> {
+
+    /**
+     * 当前结果对象
+     */
+    private T resultObject;
+    /**
+     * 总的结果对象的数量
+     */
+    private int resultCount;
+    /**
+     * 是否暂停
+     */
+    private boolean stopped;
+
+    public DefaultResultContext() {
+        resultObject = null;
+        resultCount = 0;
+        stopped = false; // 默认非暂停
+    }
+
+    @Override
+    public T getResultObject() {
+        return resultObject;
+    }
+
+    @Override
+    public int getResultCount() {
+        return resultCount;
+    }
+
+    @Override
+    public boolean isStopped() {
+        return stopped;
+    }
+
+    /**
+     * 当前结果对象
+     *
+     * @param resultObject 当前结果对象
+     */
+    public void nextResultObject(T resultObject) {
+        // 数量 + 1
+        resultCount++;
+        // 当前结果对象
+        this.resultObject = resultObject;
+    }
+
+    @Override
+    public void stop() {
+        this.stopped = true;
+    }
+
+}
+```
+
+# 5. ResultHandler
+
+`org.apache.ibatis.session.ResultHandler` ，结果处理器接口。代码如下：
+
+```
+// ResultHandler.java
+
+public interface ResultHandler<T> {
+
+    /**
+     * 处理当前结果
+     *
+     * @param resultContext ResultContext 对象。在其中，可以获得当前结果
+     */
+    void handleResult(ResultContext<? extends T> resultContext);
+
+}
+```
+
+## 5.1 DefaultResultHandler
+
+`org.apache.ibatis.executor.result.DefaultResultHandler` ，实现 ResultHandler 接口，默认的 ResultHandler 的实现类。代码如下：
+
+```
+// DefaultResultHandler.java
+
+public class DefaultResultHandler implements ResultHandler<Object> {
+
+    /**
+     * 结果数组
+     */
+    private final List<Object> list;
+
+    public DefaultResultHandler() {
+        list = new ArrayList<>();
+    }
+
+    @SuppressWarnings("unchecked")
+    public DefaultResultHandler(ObjectFactory objectFactory) {
+        list = objectFactory.create(List.class);
+    }
+
+    @Override
+    public void handleResult(ResultContext<? extends Object> context) {
+        // <1> 将当前结果，添加到结果数组中 
+        list.add(context.getResultObject());
+    }
+
+    public List<Object> getResultList() {
+        return list;
+    }
+
+}
+```
+
+- 核心代码就是 `<1>` 处，将当前结果，添加到结果数组中。
+
+## 5.2 DefaultMapResultHandler
+
+该类在 `session` 包中实现，我们放在**会话模块**的文章中，详细解析。
+
+# 6. Cursor
+
+`org.apache.ibatis.cursor.Cursor` ，继承 Closeable、Iterable 接口，游标接口。代码如下：
+
+```
+// Cursor.java
+
+public interface Cursor<T> extends Closeable, Iterable<T> {
+
+    /**
+     * 是否处于打开状态
+     *
+     * @return true if the cursor has started to fetch items from database.
+     */
+    boolean isOpen();
+
+    /**
+     * 是否全部消费完成
+     *
+     * @return true if the cursor is fully consumed and has returned all elements matching the query.
+     */
+    boolean isConsumed();
+
+    /**
+     * 获得当前索引
+     *
+     * Get the current item index. The first item has the index 0.
+     * @return -1 if the first cursor item has not been retrieved. The index of the current item retrieved.
+     */
+    int getCurrentIndex();
+
+}
+```
+
+## 6.1 DefaultCursor
+
+`org.apache.ibatis.cursor.defaults.DefaultCursor` ，实现 Cursor 接口，默认 Cursor 实现类。
+
+### 6.1.1 构造方法
+
+```
+// DefaultCursor.java
+
+// ResultSetHandler stuff
+private final DefaultResultSetHandler resultSetHandler;
+private final ResultMap resultMap;
+private final ResultSetWrapper rsw;
+private final RowBounds rowBounds;
+/**
+ * ObjectWrapperResultHandler 对象
+ */
+private final ObjectWrapperResultHandler<T> objectWrapperResultHandler = new ObjectWrapperResultHandler<>();
+
+/**
+ * CursorIterator 对象，游标迭代器。
+ */
+private final CursorIterator cursorIterator = new CursorIterator();
+/**
+ * 是否开始迭代
+ *
+ * {@link #iterator()}
+ */
+private boolean iteratorRetrieved;
+/**
+ * 游标状态
+ */
+private CursorStatus status = CursorStatus.CREATED;
+/**
+ * 已完成映射的行数
+ */
+private int indexWithRowBound = -1;
+
+public DefaultCursor(DefaultResultSetHandler resultSetHandler, ResultMap resultMap, ResultSetWrapper rsw, RowBounds rowBounds) {
+    this.resultSetHandler = resultSetHandler;
+    this.resultMap = resultMap;
+    this.rsw = rsw;
+    this.rowBounds = rowBounds;
+}
+```
+
+- 大体瞄下每个属性的意思。下面，每个方法，胖友会更好的理解每个属性。
+
+### 6.1.2 CursorStatus
+
+CursorStatus ，是 DefaultCursor 的内部枚举类。代码如下：
+
+```
+// DefaultCursor.java
+
+private enum CursorStatus {
+
+    /**
+     * A freshly created cursor, database ResultSet consuming has not started
+     */
+    CREATED,
+    /**
+     * A cursor currently in use, database ResultSet consuming has started
+     */
+    OPEN,
+    /**
+     * A closed cursor, not fully consumed
+     *
+     * 已关闭，并未完全消费
+     */
+    CLOSED,
+    /**
+     * A fully consumed cursor, a consumed cursor is always closed
+     *
+     * 已关闭，并且完全消费
+     */
+    CONSUMED
+}
+```
+
+### 6.1.3 isOpen
+
+```
+// DefaultCursor.java
+
+@Override
+public boolean isOpen() {
+    return status == CursorStatus.OPEN;
+}
+```
+
+### 6.1.4 isConsumed
+
+```
+// DefaultCursor.java
+
+@Override
+public boolean isConsumed() {
+    return status == CursorStatus.CONSUMED;
+}
+```
+
+### 6.1.5 iterator
+
+`#iterator()` 方法，获取迭代器。代码如下：
+
+```
+// DefaultCursor.java
+
+@Override
+public Iterator<T> iterator() {
+    // 如果已经获取，则抛出 IllegalStateException 异常
+    if (iteratorRetrieved) {
+        throw new IllegalStateException("Cannot open more than one iterator on a Cursor");
+    }
+    if (isClosed()) {
+        throw new IllegalStateException("A Cursor is already closed.");
+    }
+    // 标记已经获取
+    iteratorRetrieved = true;
+    return cursorIterator;
+}
+```
+
+- 通过 `iteratorRetrieved` 属性，保证有且仅返回一次 `cursorIterator` 对象。
+
+### 6.1.6 ObjectWrapperResultHandler
+
+ObjectWrapperResultHandler ，DefaultCursor 的内部静态类，实现 ResultHandler 接口，代码如下：
+
+```
+// DefaultCursor.java
+
+private static class ObjectWrapperResultHandler<T> implements ResultHandler<T> {
+
+    /**
+     * 结果对象
+     */
+    private T result;
+
+    @Override
+    public void handleResult(ResultContext<? extends T> context) {
+        // <1> 设置结果对象
+        this.result = context.getResultObject();
+        // <2> 暂停
+        context.stop();
+    }
+
+}
+```
+
+- `<1>` 处，暂存 [「3.1 DefaultResultSetHandler」](https://svip.iocoder.cn/MyBatis/executor-4/#) 处理的 ResultSet 的**当前行**的结果。
+
+- `<2>` 处，通过调用 `ResultContext#stop()` 方法，暂停 DefaultResultSetHandler 在向下遍历下一条记录，从而实现每次在调用 `CursorIterator#hasNext()` 方法，只遍历一行 ResultSet 的记录。如果胖友有点懵逼，可以在看看 `DefaultResultSetHandler#shouldProcessMoreRows(ResultContext<?> context, RowBounds rowBounds)` 方法，代码如下：
+
+  ```
+  // DefaultCursor.java
+  
+  private boolean shouldProcessMoreRows(ResultContext<?> context, RowBounds rowBounds) {
+      return !context.isStopped() && context.getResultCount() < rowBounds.getLimit();
+  }
+  ```
+
+### 6.1.7 CursorIterator
+
+CursorIterator ，DefaultCursor 的内部类，实现 Iterator 接口，游标的迭代器实现类。代码如下：
+
+```
+// DefaultCursor.java
+
+private class CursorIterator implements Iterator<T> {
+
+    /**
+     * Holder for the next object to be returned
+     *
+     * 结果对象，提供给 {@link #next()} 返回
+     */
+    T object;
+
+    /**
+     * Index of objects returned using next(), and as such, visible to users.
+     * 索引位置
+     */
+    int iteratorIndex = -1;
+
+    @Override
+    public boolean hasNext() {
+        // <1> 如果 object 为空，则遍历下一条记录
+        if (object == null) {
+            object = fetchNextUsingRowBound();
+        }
+        // <2> 判断 object 是否非空
+        return object != null;
+    }
+
+    @Override
+    public T next() {
+        // <3> Fill next with object fetched from hasNext()
+        T next = object;
+
+        // <4> 如果 next 为空，则遍历下一条记录
+        if (next == null) {
+            next = fetchNextUsingRowBound();
+        }
+
+        // <5> 如果 next 非空，说明有记录，则进行返回
+        if (next != null) {
+            // <5.1> 置空 object 对象
+            object = null;
+            // <5.2> 增加 iteratorIndex
+            iteratorIndex++;
+            // <5.3> 返回 next
+            return next;
+        }
+
+        // <6> 如果 next 为空，说明没有记录，抛出 NoSuchElementException 异常
+        throw new NoSuchElementException();
+    }
+
+    @Override
+    public void remove() {
+        throw new UnsupportedOperationException("Cannot remove element from Cursor");
+    }
+
+}
+```
+
+- ```
+  #hasNext()
+  ```
+
+   
+
+  方法，判断是否有
+
+  下一个
+
+  结果对象：
+
+  - `<1>` 处，如果 `object` 为空，则调用 `#fetchNextUsingRowBound()` 方法，遍历下一条记录。也就是说，该方法是先获取下一条记录，然后在判断是否存在下一条记录。实际上，和 `java.util.ResultSet` 的方式，是一致的。如果再调用一次该方法，则不会去遍历下一条记录。关于 `#fetchNextUsingRowBound()` 方法，详细解析，见 [「6.1.8 fetchNextUsingRowBound」](https://svip.iocoder.cn/MyBatis/executor-4/#) 。
+  - `<2>` 处，判断 `object` 非空。
+
+- ```
+  #next()
+  ```
+
+   
+
+  方法，获得
+
+  下一个
+
+  结果对象：
+
+  - `<3>` 处，先记录 `object` 到 `next` 中。为什么要这么做呢？继续往下看。
+
+  - `<4>` 处，如果 `next` 为空，有两种可能性：1）使用方未调用 `#hasNext()` 方法；2）调用 `#hasNext()` 方法，发现没下一条，还是调用了 `#next()` 方法。如果 `next()` 方法为空，通过“再次”调用 `#fetchNextUsingRowBound()` 方法，去遍历下一条记录。
+
+  - ```
+    <5>
+    ```
+
+     
+
+    处，如果
+
+     
+
+    ```
+    next
+    ```
+
+     
+
+    非空，说明有记录，则进行返回。
+
+    - `<5.1>` 处，置空 `object` 对象。
+    - `<5.2>` 处，增加 `iteratorIndex` 。
+    - `<5.3>` 处，返回 `next` 。如果 `<3>` 处，不进行 `next` 的赋值，如果 `<5.1>` 处的置空，此处就无法返回 `next` 了。
+
+  - `<6>` 处，如果 `next` 为空，说明没有记录，抛出 NoSuchElementException 异常。
+
+### 6.1.8 fetchNextUsingRowBound
+
+`#fetchNextUsingRowBound()` 方法，遍历下一条记录。代码如下：
+
+```
+// DefaultCursor.java
+
+protected T fetchNextUsingRowBound() {
+    // <1> 遍历下一条记录
+    T result = fetchNextObjectFromDatabase();
+    // 循环跳过 rowBounds 的索引
+    while (result != null && indexWithRowBound < rowBounds.getOffset()) {
+        result = fetchNextObjectFromDatabase();
+    }
+    // 返回记录
+    return result;
+}
+```
+
+- `<1>` 处，调用 `#fetchNextObjectFromDatabase()` 方法，遍历下一条记录。代码如下：
+
+```
+// DefaultCursor.java
+
+protected T fetchNextObjectFromDatabase() {
+    // <1> 如果已经关闭，返回 null
+    if (isClosed()) {
+        return null;
+    }
+
+    try {
+        // <2> 设置状态为 CursorStatus.OPEN
+        status = CursorStatus.OPEN;
+        // <3> 遍历下一条记录
+        if (!rsw.getResultSet().isClosed()) {
+            resultSetHandler.handleRowValues(rsw, resultMap, objectWrapperResultHandler, RowBounds.DEFAULT, null);
+        }
+    } catch (SQLException e) {
+        throw new RuntimeException(e);
+    }
+
+    // <4> 复制给 next
+    T next = objectWrapperResultHandler.result;
+    // <5> 增加 indexWithRowBound
+    if (next != null) {
+        indexWithRowBound++;
+    }
+    // No more object or limit reached
+    // <6> 没有更多记录，或者到达 rowBounds 的限制索引位置，则关闭游标，并设置状态为 CursorStatus.CONSUMED
+    if (next == null || getReadItemsCount() == rowBounds.getOffset() + rowBounds.getLimit()) {
+        close();
+        status = CursorStatus.CONSUMED;
+    }
+    // <7> 置空 objectWrapperResultHandler.result 属性
+    objectWrapperResultHandler.result = null;
+    // <8> 返回下一条结果
+    return next;
+}
+```
+
+- `<1>` 处，调用 `#isClosed()` 方法，判断是否已经关闭。若是，则返回 `null` 。代码如下：
+
+  ```
+  // DefaultCursor.java
+  
+  private boolean isClosed() {
+      return status == CursorStatus.CLOSED || status == CursorStatus.CONSUMED;
+  }
+  ```
+
+- `<2>` 处，设置状态为 `CursorStatus.OPEN` 。
+
+- `<3>` 处，调用 `DefaultResultSetHandler#handleRowValues(...)` 方法，遍历下一条记录。也就是说，回到了 [[「3.1.2.2 handleRowValues」](https://svip.iocoder.cn/MyBatis/executor-4/#) 的流程。遍历的下一条件记录，会暂存到 `objectWrapperResultHandler.result` 中。
+
+- `<4>` 处，复制给 `next` 。
+
+- `<5>` 处，增加 `indexWithRowBound` 。
+
+- `<6>` 处，没有更多记录，或者到达 `rowBounds` 的限制索引位置，则关闭游标，并设置状态为 `CursorStatus.CONSUMED` 。其中，涉及到的方法，代码如下：
+
+  ```
+  // DefaultCursor.java
+  
+  private int getReadItemsCount() {
+      return indexWithRowBound + 1;
+  }
+  
+  @Override
+  public void close() {
+      if (isClosed()) {
+          return;
+      }
+  
+      // 关闭 ResultSet
+      ResultSet rs = rsw.getResultSet();
+      try {
+          if (rs != null) {
+              rs.close();
+          }
+      } catch (SQLException e) {
+          // ignore
+      } finally {
+          // 设置状态为 CursorStatus.CLOSED
+          status = CursorStatus.CLOSED;
+      }
+  }
+  ```
+
+- `<7>` 处，置空 `objectWrapperResultHandler.result` 属性。
+- `<8>` 处，返回 `next` 。
+
+# 666. 彩蛋
+
+卧槽，太他喵的长了。写的我的 MWeb( 写作编辑器 )都一卡一卡的。同时，写的有点崩溃，可能有些细节描述的不到位，如果有错误，或者不好理解的地方，记得给我星球留言，多多交流。
+
+参考和推荐如下文章：
+
+- 祖大俊 [《Mybatis3.4.x技术内幕（二十一）：参数设置、结果封装、级联查询、延迟加载原理分析》](https://my.oschina.net/zudajun/blog/747283)
+- 徐郡明 [《MyBatis 技术内幕》](https://item.jd.com/12125531.html) 的 [「3.3 ResultSetHandler」](https://svip.iocoder.cn/MyBatis/executor-4/#) 小节
\ No newline at end of file
diff --git a/mybatis/25-mybatis-SQL 执行（五）之延迟加载.assets/01.png b/mybatis/25-mybatis-SQL 执行（五）之延迟加载.assets/01.png
new file mode 100644
index 0000000..9b1f842
Binary files /dev/null and b/mybatis/25-mybatis-SQL 执行（五）之延迟加载.assets/01.png differ
diff --git a/mybatis/25-mybatis-SQL 执行（五）之延迟加载.md b/mybatis/25-mybatis-SQL 执行（五）之延迟加载.md
new file mode 100644
index 0000000..9968fb9
--- /dev/null
+++ b/mybatis/25-mybatis-SQL 执行（五）之延迟加载.md	
@@ -0,0 +1,923 @@
+# 精尽 MyBatis 源码分析 —— SQL 执行（五）之延迟加载
+
+# 1. 概述
+
+本文，我们来分享 SQL 执行的第五部分，延迟加载的功能的实现，涉及 `executor/loader` 包。整体类图如下：[![类图](25-mybatis-SQL 执行（五）之延迟加载.assets/01.png)](http://static.iocoder.cn/images/MyBatis/2020_03_12/01.png)类图
+
+- 从类图，我们发现，延迟加载的功能，是通过**动态代理**实现的。也就是说，通过拦截指定方法，执行数据加载，从而实现延迟加载。
+- 并且，MyBatis 提供了 Cglib 和 Javassist 两种动态代理的创建方式。
+
+在 [《精尽 MyBatis 源码分析 —— SQL 执行（四）之 ResultSetHandler》](http://svip.iocoder.cn/MyBatis/executor-4) 方法中，我们已经看到延迟加载相关的代码，下面让我们一处一处来看看。
+
+另外，如果胖友并未使用过 MyBatis 的延迟加载的功能，可以先看看 [《【MyBatis框架】高级映射-延迟加载》](https://blog.csdn.net/acmman/article/details/46696167) 文章。
+
+# 2. ResultLoader
+
+在 DefaultResultSetHandler 的 `#getNestedQueryConstructorValue(ResultSet rs, ResultMapping constructorMapping, String columnPrefix)` 方法中，我们可以看到 ResultLoader 的身影。代码如下：
+
+```
+// DefaultResultSetHandler.java
+
+// 获得嵌套查询的值
+private Object getNestedQueryConstructorValue(ResultSet rs, ResultMapping constructorMapping, String columnPrefix) throws SQLException {
+    // 获得内嵌查询的编号
+    final String nestedQueryId = constructorMapping.getNestedQueryId();
+    // 获得内嵌查询的 MappedStatement 对象
+    final MappedStatement nestedQuery = configuration.getMappedStatement(nestedQueryId);
+    // 获得内嵌查询的参数类型
+    final Class<?> nestedQueryParameterType = nestedQuery.getParameterMap().getType();
+    // 获得内嵌查询的参数对象
+    final Object nestedQueryParameterObject = prepareParameterForNestedQuery(rs, constructorMapping, nestedQueryParameterType, columnPrefix);
+    Object value = null;
+    if (nestedQueryParameterObject != null) {
+        // 获得 BoundSql 对象
+        final BoundSql nestedBoundSql = nestedQuery.getBoundSql(nestedQueryParameterObject);
+        // 获得 CacheKey 对象
+        final CacheKey key = executor.createCacheKey(nestedQuery, nestedQueryParameterObject, RowBounds.DEFAULT, nestedBoundSql);
+        final Class<?> targetType = constructorMapping.getJavaType();
+        // <x> 创建 ResultLoader 对象
+        final ResultLoader resultLoader = new ResultLoader(configuration, executor, nestedQuery, nestedQueryParameterObject, targetType, key, nestedBoundSql);
+        // 加载结果
+        value = resultLoader.loadResult();
+    }
+    return value;
+}
+```
+
+- `<x>` 处，因为是结果对象的构造方法中使用的值，无法使用延迟加载的功能，所以使用 ResultLoader 直接加载。
+
+------
+
+`org.apache.ibatis.executor.loader.ResultLoader` ，结果加载器。
+
+## 2.1 构造方法
+
+```
+// ResultLoader.java
+
+protected final Configuration configuration;
+protected final Executor executor;
+protected final MappedStatement mappedStatement;
+/**
+ * 查询的参数对象
+ */
+protected final Object parameterObject;
+/**
+ * 结果的类型
+ */
+protected final Class<?> targetType;
+protected final ObjectFactory objectFactory;
+protected final CacheKey cacheKey;
+protected final BoundSql boundSql;
+/**
+ * ResultExtractor 对象
+ */
+protected final ResultExtractor resultExtractor;
+/**
+ * 创建 ResultLoader 对象时，所在的线程
+ */
+protected final long creatorThreadId;
+
+/**
+ * 是否已经加载
+ */
+protected boolean loaded;
+/**
+ * 查询的结果对象
+ */
+protected Object resultObject;
+
+public ResultLoader(Configuration config, Executor executor, MappedStatement mappedStatement, Object parameterObject, Class<?> targetType, CacheKey cacheKey, BoundSql boundSql) {
+    this.configuration = config;
+    this.executor = executor;
+    this.mappedStatement = mappedStatement;
+    this.parameterObject = parameterObject;
+    this.targetType = targetType;
+    this.objectFactory = configuration.getObjectFactory();
+    this.cacheKey = cacheKey;
+    this.boundSql = boundSql;
+    // 初始化 resultExtractor
+    this.resultExtractor = new ResultExtractor(configuration, objectFactory);
+    // 初始化 creatorThreadId
+    this.creatorThreadId = Thread.currentThread().getId();
+}
+```
+
+- 重点属性，看添加了中文注释的。
+
+## 2.2 loadResult
+
+`#loadResult()` 方法，加载结果。代码如下：
+
+```
+// ResultLoader.java
+
+public Object loadResult() throws SQLException {
+    // <1> 查询结果
+    List<Object> list = selectList();
+    // <2> 提取结果
+    resultObject = resultExtractor.extractObjectFromList(list, targetType);
+    // <3> 返回结果
+    return resultObject;
+}
+```
+
+- `<1>` 处，调用 `#selectList()` 方法，查询结果。详细解析，见 [「2.3 selectList」](https://svip.iocoder.cn/MyBatis/executor-5/#) 。
+- `<2>` 处，调用 `ResultExtractor#extractObjectFromList(List<Object> list, Class<?> targetType)` 方法，提取结果。详细解析，见 [「3. ResultExtractor」](https://svip.iocoder.cn/MyBatis/executor-5/#) 。
+- `<3>` 处，返回结果。
+
+## 2.3 selectList
+
+`#selectList()` 方法，查询结果。代码如下：
+
+```
+// ResultLoader.java
+
+private <E> List<E> selectList() throws SQLException {
+    // <1> 获得 Executor 对象
+    Executor localExecutor = executor;
+    if (Thread.currentThread().getId() != this.creatorThreadId || localExecutor.isClosed()) {
+        localExecutor = newExecutor();
+    }
+    // <2> 执行查询
+    try {
+        return localExecutor.query(mappedStatement, parameterObject, RowBounds.DEFAULT, Executor.NO_RESULT_HANDLER, cacheKey, boundSql);
+    } finally {
+        // <3> 关闭 Executor 对象
+        if (localExecutor != executor) {
+            localExecutor.close(false);
+        }
+    }
+}
+```
+
+- `<1>` 处，如果当前线程不是创建线程，则调用 `#newExecutor()` 方法，创建 Executor 对象，因为 Executor 是非线程安全的。代码如下：
+
+  ```
+  // ResultLoader.java
+  
+  private Executor newExecutor() {
+      // 校验 environment
+      final Environment environment = configuration.getEnvironment();
+      if (environment == null) {
+          throw new ExecutorException("ResultLoader could not load lazily.  Environment was not configured.");
+      }
+      // 校验 ds
+      final DataSource ds = environment.getDataSource();
+      if (ds == null) {
+          throw new ExecutorException("ResultLoader could not load lazily.  DataSource was not configured.");
+      }
+      // 创建 Transaction 对象
+      final TransactionFactory transactionFactory = environment.getTransactionFactory();
+      final Transaction tx = transactionFactory.newTransaction(ds, null, false);
+      // 创建 Executor 对象
+      return configuration.newExecutor(tx, ExecutorType.SIMPLE);
+  }
+  ```
+
+- `<2>` 处，调用 `Executor#query(...)` 方法，执行查询。
+
+- `<3>` 处，如果是新创建的 Executor 对象，则调用 `Executor#close()` 方法，关闭 Executor 对象。
+
+## 2.4 wasNull
+
+`#wasNull()` 方法，是否结果为空。代码如下：
+
+```
+// ResultLoader.java
+
+public boolean wasNull() {
+    return resultObject == null;
+}
+```
+
+# 3. ResultExtractor
+
+`org.apache.ibatis.executor.ResultExtractor` ，结果提取器。代码如下：
+
+```
+// ResultExtractor.java
+
+public class ResultExtractor {
+
+    private final Configuration configuration;
+    private final ObjectFactory objectFactory;
+
+    public ResultExtractor(Configuration configuration, ObjectFactory objectFactory) {
+        this.configuration = configuration;
+        this.objectFactory = objectFactory;
+    }
+
+    /**
+     * 从 list 中，提取结果
+     *
+     * @param list list
+     * @param targetType 结果类型
+     * @return 结果
+     */
+    public Object extractObjectFromList(List<Object> list, Class<?> targetType) {
+        Object value = null;
+        // 情况一，targetType 就是 list ，直接返回
+        if (targetType != null && targetType.isAssignableFrom(list.getClass())) {
+            value = list;
+        // 情况二，targetType 是集合，添加到其中
+        } else if (targetType != null && objectFactory.isCollection(targetType)) {
+            // 创建 Collection 对象
+            value = objectFactory.create(targetType);
+            // 将结果添加到其中
+            MetaObject metaObject = configuration.newMetaObject(value);
+            metaObject.addAll(list);
+        // 情况三，targetType 是数组
+        } else if (targetType != null && targetType.isArray()) {
+            // 创建 array 数组
+            Class<?> arrayComponentType = targetType.getComponentType();
+            Object array = Array.newInstance(arrayComponentType, list.size());
+            // 赋值到 array 中
+            if (arrayComponentType.isPrimitive()) {
+                for (int i = 0; i < list.size(); i++) {
+                    Array.set(array, i, list.get(i));
+                }
+                value = array;
+            } else {
+                value = list.toArray((Object[]) array);
+            }
+        // 情况四，普通对象，取首个对象
+        } else {
+            if (list != null && list.size() > 1) {
+                throw new ExecutorException("Statement returned more than one row, where no more than one was expected.");
+            } else if (list != null && list.size() == 1) {
+                value = list.get(0);
+            }
+        }
+        return value;
+    }
+    
+}
+```
+
+- 分成四种情况，胖友看下代码注释。
+
+# 4. ResultLoaderMap
+
+在 DefaultResultSetHandler 的 `#getNestedQueryMappingValue(ResultSet rs, MetaObject metaResultObject, ResultMapping propertyMapping, ResultLoaderMap lazyLoader, String columnPrefix)` 方法中，我们可以看到 ResultLoaderMap 的身影。代码如下：
+
+```
+// DefaultResultSetHandler.java
+
+// 获得嵌套查询的值
+private Object getNestedQueryMappingValue(ResultSet rs, MetaObject metaResultObject, ResultMapping propertyMapping, ResultLoaderMap lazyLoader, String columnPrefix)
+        throws SQLException {
+    // 获得内嵌查询的编号
+    final String nestedQueryId = propertyMapping.getNestedQueryId();
+    // 获得属性名
+    final String property = propertyMapping.getProperty();
+    // 获得内嵌查询的 MappedStatement 对象
+    final MappedStatement nestedQuery = configuration.getMappedStatement(nestedQueryId);
+    // 获得内嵌查询的参数类型
+    final Class<?> nestedQueryParameterType = nestedQuery.getParameterMap().getType();
+    // 获得内嵌查询的参数对象
+    final Object nestedQueryParameterObject = prepareParameterForNestedQuery(rs, propertyMapping, nestedQueryParameterType, columnPrefix);
+    Object value = null;
+    if (nestedQueryParameterObject != null) {
+        // 获得 BoundSql 对象
+        final BoundSql nestedBoundSql = nestedQuery.getBoundSql(nestedQueryParameterObject);
+        // 获得 CacheKey 对象
+        final CacheKey key = executor.createCacheKey(nestedQuery, nestedQueryParameterObject, RowBounds.DEFAULT, nestedBoundSql);
+        final Class<?> targetType = propertyMapping.getJavaType();
+        // <y> 检查缓存中已存在
+        if (executor.isCached(nestedQuery, key)) {
+            // 创建 DeferredLoad 对象，并通过该 DeferredLoad 对象从缓存中加载结采对象
+            executor.deferLoad(nestedQuery, metaResultObject, property, key, targetType);
+            // 返回已定义
+            value = DEFERED;
+        // 检查缓存中不存在
+        } else {
+            // 创建 ResultLoader 对象
+            final ResultLoader resultLoader = new ResultLoader(configuration, executor, nestedQuery, nestedQueryParameterObject, targetType, key, nestedBoundSql);
+            // <x> 如果要求延迟加载，则延迟加载
+            if (propertyMapping.isLazy()) {
+                // 如果该属性配置了延迟加载，则将其添加到 `ResultLoader.loaderMap` 中，等待真正使用时再执行嵌套查询并得到结果对象。
+                lazyLoader.addLoader(property, metaResultObject, resultLoader);
+                // 返回已定义
+                value = DEFERED;
+            // 如果不要求延迟加载，则直接执行加载对应的值
+            } else {
+                value = resultLoader.loadResult();
+            }
+        }
+    }
+    return value;
+}
+```
+
+- `<x>` 处，因为是结果对象的 setting 方法中使用的值，可以使用延迟加载的功能，所以使用 ResultLoaderMap 记录。最终会创建结果对象的**代理对象**，而 ResultLoaderMap 对象会传入其中，作为一个参数。从而能够，在加载该属性时，能够调用 `ResultLoader#loadResult()` 方法，加载结果。
+
+- 另外，在 `<y>` 处，检查缓存中已存在，则会调用 `Executor#deferLoad(...)` 方法，**尝试**加载结果。代码如下：
+
+  > 老艿艿：此处是插入，😈 找不到适合放这块内容的地方了，哈哈哈。
+
+  ```
+  // 该方法在 BaseExecutor 抽象类中实现
+  // BaseExecutor.java 
+      
+  /**
+   * DeferredLoad( 延迟加载 ) 队列
+   */
+  protected ConcurrentLinkedQueue<DeferredLoad> deferredLoads;
+  
+  @Override
+  public void deferLoad(MappedStatement ms, MetaObject resultObject, String property, CacheKey key, Class<?> targetType) {
+      // 如果执行器已关闭，抛出 ExecutorException 异常
+      if (closed) {
+          throw new ExecutorException("Executor was closed.");
+      }
+      // 创建 DeferredLoad 对象
+      DeferredLoad deferredLoad = new DeferredLoad(resultObject, property, key, localCache, configuration, targetType);
+      // 如果可加载，则执行加载
+      if (deferredLoad.canLoad()) {
+          deferredLoad.load();
+      // 如果不可加载，则添加到 deferredLoads 中
+      } else {
+          deferredLoads.add(new DeferredLoad(resultObject, property, key, localCache, configuration, targetType));
+      }
+  }
+  
+  private static class DeferredLoad {
+  
+      private final MetaObject resultObject;
+      private final String property;
+      private final Class<?> targetType;
+      private final CacheKey key;
+      private final PerpetualCache localCache;
+      private final ObjectFactory objectFactory;
+      private final ResultExtractor resultExtractor;
+  
+      // issue #781
+      public DeferredLoad(MetaObject resultObject,
+                          String property,
+                          CacheKey key,
+                          PerpetualCache localCache,
+                          Configuration configuration,
+                          Class<?> targetType) {
+          this.resultObject = resultObject;
+          this.property = property;
+          this.key = key;
+          this.localCache = localCache;
+          this.objectFactory = configuration.getObjectFactory();
+          this.resultExtractor = new ResultExtractor(configuration, objectFactory);
+          this.targetType = targetType;
+      }
+  
+      public boolean canLoad() {
+          return localCache.getObject(key) != null && localCache.getObject(key) != EXECUTION_PLACEHOLDER;
+      }
+  
+      public void load() {
+          @SuppressWarnings("unchecked")
+          // we suppose we get back a List
+          // 从缓存 localCache 中获取
+          List<Object> list = (List<Object>) localCache.getObject(key);
+          // 解析结果
+          Object value = resultExtractor.extractObjectFromList(list, targetType);
+          // 设置到 resultObject 中
+          resultObject.setValue(property, value);
+      }
+  
+  }
+  ```
+
+  - 代码比较简单，胖友自己瞅瞅。
+
+------
+
+`org.apache.ibatis.executor.loader.ResultLoaderMap` ， ResultLoader 的映射。该映射，最终创建代理对象时，会作为参数传入代理。
+
+## 4.1 构造方法
+
+```
+// ResultLoaderMap.java
+
+/**
+ * LoadPair 的映射
+ */
+private final Map<String, LoadPair> loaderMap = new HashMap<>();
+```
+
+## 4.2 addLoader
+
+`#addLoader(String property, MetaObject metaResultObject, ResultLoader resultLoader)` 方法，添加到 `loaderMap` 中。代码如下：
+
+```
+// ResultLoaderMap.java
+
+public void addLoader(String property, MetaObject metaResultObject, ResultLoader resultLoader) {
+    String upperFirst = getUppercaseFirstProperty(property);
+    // 已存在，则抛出 ExecutorException 异常
+    if (!upperFirst.equalsIgnoreCase(property) && loaderMap.containsKey(upperFirst)) {
+        throw new ExecutorException("Nested lazy loaded result property '" + property +
+                "' for query id '" + resultLoader.mappedStatement.getId() +
+                " already exists in the result map. The leftmost property of all lazy loaded properties must be unique within a result map.");
+    }
+    // 创建 LoadPair 对象，添加到 loaderMap 中
+    loaderMap.put(upperFirst, new LoadPair(property, metaResultObject, resultLoader));
+}
+
+/**
+ * 使用 . 分隔属性，并获得首个字符串，并大写
+ *
+ * @param property 属性
+ * @return 字符串 + 大写
+ */
+private static String getUppercaseFirstProperty(String property) {
+    String[] parts = property.split("\\.");
+    return parts[0].toUpperCase(Locale.ENGLISH);
+}
+```
+
+- 其中，LoadPair 是 ResultLoaderMap 的内部静态类。代码如下：
+
+  ```
+  // ResultLoaderMap.java
+  
+  public static class LoadPair implements Serializable {
+  
+      private static final long serialVersionUID = 20130412;
+  
+      /**
+       * Name of factory method which returns database connection.
+       */
+      private static final String FACTORY_METHOD = "getConfiguration";
+      /**
+       * Object to check whether we went through serialization..
+       */
+      private final transient Object serializationCheck = new Object();
+      /**
+       * Meta object which sets loaded properties.
+       */
+      private transient MetaObject metaResultObject;
+      /**
+       * Result loader which loads unread properties.
+       */
+      private transient ResultLoader resultLoader;
+      /**
+       * Wow, logger.
+       */
+      private transient Log log;
+      /**
+       * Factory class through which we get database connection.
+       */
+      private Class<?> configurationFactory;
+      /**
+       * Name of the unread property.
+       */
+      private String property;
+      /**
+       * ID of SQL statement which loads the property.
+       */
+      private String mappedStatement;
+      /**
+       * Parameter of the sql statement.
+       */
+      private Serializable mappedParameter;
+  
+      private LoadPair(final String property, MetaObject metaResultObject, ResultLoader resultLoader) {
+          this.property = property;
+          this.metaResultObject = metaResultObject;
+          this.resultLoader = resultLoader;
+  
+          /* Save required information only if original object can be serialized. */
+          // 当 `metaResultObject.originalObject` 可序列化时，则记录 mappedStatement、mappedParameter、configurationFactory 属性
+          if (metaResultObject != null && metaResultObject.getOriginalObject() instanceof Serializable) {
+              final Object mappedStatementParameter = resultLoader.parameterObject;
+  
+              /* @todo May the parameter be null? */
+              if (mappedStatementParameter instanceof Serializable) {
+                  this.mappedStatement = resultLoader.mappedStatement.getId();
+                  this.mappedParameter = (Serializable) mappedStatementParameter;
+  
+                  this.configurationFactory = resultLoader.configuration.getConfigurationFactory();
+              } else {
+                  Log log = this.getLogger();
+                  if (log.isDebugEnabled()) {
+                      log.debug("Property [" + this.property + "] of ["
+                              + metaResultObject.getOriginalObject().getClass() + "] cannot be loaded "
+                              + "after deserialization. Make sure it's loaded before serializing "
+                              + "forenamed object.");
+                  }
+              }
+          }
+      }
+      
+      // ... 暂时省略其它方法
+  }
+  ```
+
+## 4.3 load
+
+`#load(String property)` 方法，执行指定属性的加载。代码如下：
+
+```
+// ResultLoaderMap.java
+
+public boolean load(String property) throws SQLException {
+    // 获得 LoadPair 对象，并移除
+    LoadPair pair = loaderMap.remove(property.toUpperCase(Locale.ENGLISH));
+    // 执行加载
+    if (pair != null) {
+        pair.load();
+        return true; // 加载成功
+    }
+    return false; // 加载失败
+}
+```
+
+- 调用 `LoadPair#load()` 方法，执行加载。代码如下：
+
+```
+// ResultLoaderMap.java
+
+public void load() throws SQLException {
+    /* These field should not be null unless the loadpair was serialized.
+     * Yet in that case this method should not be called. */
+    // 若 metaResultObject 或 resultLoader 为空，抛出 IllegalArgumentException 异常
+    if (this.metaResultObject == null) {
+        throw new IllegalArgumentException("metaResultObject is null");
+    }
+    if (this.resultLoader == null) {
+        throw new IllegalArgumentException("resultLoader is null");
+    }
+
+    // 执行加载
+    this.load(null);
+}
+
+public void load(final Object userObject) throws SQLException {
+    if (this.metaResultObject == null || this.resultLoader == null) { // <1>
+        if (this.mappedParameter == null) {
+            throw new ExecutorException("Property [" + this.property + "] cannot be loaded because "
+                    + "required parameter of mapped statement ["
+                    + this.mappedStatement + "] is not serializable.");
+        }
+
+        // 获得 Configuration 对象
+        final Configuration config = this.getConfiguration();
+        // 获得 MappedStatement 对象
+        final MappedStatement ms = config.getMappedStatement(this.mappedStatement);
+        if (ms == null) {
+            throw new ExecutorException("Cannot lazy load property [" + this.property
+                    + "] of deserialized object [" + userObject.getClass()
+                    + "] because configuration does not contain statement ["
+                    + this.mappedStatement + "]");
+        }
+
+        // 获得对应的 MetaObject 对象
+        this.metaResultObject = config.newMetaObject(userObject);
+        // 创建 ResultLoader 对象
+        this.resultLoader = new ResultLoader(config, new ClosedExecutor(), ms, this.mappedParameter,
+                metaResultObject.getSetterType(this.property), null, null);
+    }
+
+    /* We are using a new executor because we may be (and likely are) on a new thread
+     * and executors aren't thread safe. (Is this sufficient?)
+     *
+     * A better approach would be making executors thread safe. */
+    if (this.serializationCheck == null) { // <2>
+        final ResultLoader old = this.resultLoader;
+        this.resultLoader = new ResultLoader(old.configuration, new ClosedExecutor(), old.mappedStatement,
+                old.parameterObject, old.targetType, old.cacheKey, old.boundSql);
+    }
+
+    // <3>
+    this.metaResultObject.setValue(property, this.resultLoader.loadResult());
+}
+```
+
+- `<1>` 和 `<2>` 处，胖友可以暂时无视，主要用于延迟加载在**序列化和反序列化**的时候，一般很少碰到。当然，感兴趣的胖友，可以调试下 `org.apache.ibatis.submitted.lazy_deserialize.LazyDeserializeTest` 单元测试类。
+- 【重点】`<3>` 处，调用 `ResultLoader#loadResult()` 方法，执行查询结果。
+- `<3>` 处，调用 `MetaObject#setValue(String name, Object value)` 方法，设置属性。
+
+## 4.4 loadAll
+
+`#loadAll()` 方法，执行所有属性的加载。代码如下：
+
+```
+// ResultLoaderMap.java
+
+public void loadAll() throws SQLException {
+    // 遍历 loaderMap 属性
+    final Set<String> methodNameSet = loaderMap.keySet();
+    String[] methodNames = methodNameSet.toArray(new String[methodNameSet.size()]);
+    for (String methodName : methodNames) {
+        // 执行加载
+        load(methodName);
+    }
+}
+```
+
+## 4.5 其它方法
+
+ResultLoaderMap 还有其它方法，比较简单，胖友可以自己看看。
+
+# 5. ProxyFactory
+
+在 DefaultResultSetHandler 的 `#createResultObject(ResultSetWrapper rsw, ResultMap resultMap, ResultLoaderMap lazyLoader, String columnPrefix)` 方法中，我们可以看到 ProxyFactory 的身影。代码如下：
+
+```
+// DefaultResultSetHandler.java
+
+private Object createResultObject(ResultSetWrapper rsw, ResultMap resultMap, ResultLoaderMap lazyLoader, String columnPrefix) throws SQLException {
+    // useConstructorMappings ，表示是否使用构造方法创建该结果对象。此处将其重置
+    this.useConstructorMappings = false; // reset previous mapping result
+    final List<Class<?>> constructorArgTypes = new ArrayList<>(); // 记录使用的构造方法的参数类型的数组
+    final List<Object> constructorArgs = new ArrayList<>(); // 记录使用的构造方法的参数值的数组
+    // 创建映射后的结果对象
+    Object resultObject = createResultObject(rsw, resultMap, constructorArgTypes, constructorArgs, columnPrefix);
+    if (resultObject != null && !hasTypeHandlerForResultObject(rsw, resultMap.getType())) {
+        // 如果有内嵌的查询，并且开启延迟加载，则创建结果对象的代理对象
+        final List<ResultMapping> propertyMappings = resultMap.getPropertyResultMappings();
+        for (ResultMapping propertyMapping : propertyMappings) {
+            // issue gcode #109 && issue #149
+            if (propertyMapping.getNestedQueryId() != null && propertyMapping.isLazy()) {
+                resultObject = configuration.getProxyFactory().createProxy(resultObject, lazyLoader, configuration, objectFactory, constructorArgTypes, constructorArgs); // <X>
+                break;
+            }
+        }
+    }
+    // 判断是否使用构造方法创建该结果对象
+    this.useConstructorMappings = resultObject != null && !constructorArgTypes.isEmpty(); // set current mapping result
+    return resultObject;
+}
+```
+
+- `<x>` 处，调用 `ProxyFactory#createProxy(...)` 方法，创建结果对象的代理对象。
+
+------
+
+`org.apache.ibatis.executor.loader.ProxyFactory` ，代理工厂接口，用于创建需要延迟加载属性的结果对象。代码如下：
+
+```
+// ProxyFactory.java
+
+public interface ProxyFactory {
+
+    // 设置属性，目前是空实现。可以暂时无视该方法
+    void setProperties(Properties properties);
+
+    // 创建代理对象
+    Object createProxy(Object target, ResultLoaderMap lazyLoader, Configuration configuration, ObjectFactory objectFactory, List<Class<?>> constructorArgTypes, List<Object> constructorArgs);
+
+}
+```
+
+- ProxyFactory 有 JavassistProxyFactory 和 CglibProxyFactory 两个实现类，默认使用**前者**。原因见如下代码：
+
+  ```
+  // Configuration.java
+  
+  protected ProxyFactory proxyFactory = new JavassistProxyFactory(); // #224 Using internal Javassist instead of OGNL
+  ```
+
+## 5.1 JavassistProxyFactory
+
+`org.apache.ibatis.executor.loader.javassist.JavassistProxyFactory` ，实现 ProxyFactory 接口，基于 Javassist 的 ProxyFactory 实现类。
+
+### 5.1.1 构造方法
+
+```
+// JavassistProxyFactory.java
+
+private static final Log log = LogFactory.getLog(JavassistProxyFactory.class);
+
+private static final String FINALIZE_METHOD = "finalize";
+private static final String WRITE_REPLACE_METHOD = "writeReplace";
+
+public JavassistProxyFactory() {
+    try {
+        // 加载 javassist.util.proxy.ProxyFactory 类
+        Resources.classForName("javassist.util.proxy.ProxyFactory");
+    } catch (Throwable e) {
+        throw new IllegalStateException("Cannot enable lazy loading because Javassist is not available. Add Javassist to your classpath.", e);
+    }
+}
+```
+
+### 5.1.2 createDeserializationProxy
+
+`#createDeserializationProxy(Object target, Map<String, ResultLoaderMap.LoadPair> unloadedProperties, ObjectFactory objectFactory, List<Class<?>> constructorArgTypes, List<Object> constructorArgs)` 方法，创建支持**反序列化**的代理对象。代码如下：
+
+```
+// JavassistProxyFactory.java
+
+public Object createDeserializationProxy(Object target, Map<String, ResultLoaderMap.LoadPair> unloadedProperties, ObjectFactory objectFactory, List<Class<?>> constructorArgTypes, List<Object> constructorArgs) {
+    return EnhancedDeserializationProxyImpl.createProxy(target, unloadedProperties, objectFactory, constructorArgTypes, constructorArgs);
+}
+```
+
+- 因为实际场景下，不太使用该功能，所以本文暂时无视。
+
+### 5.1.3 createProxy 普通方法
+
+`#createProxy(Object target, ResultLoaderMap lazyLoader, Configuration configuration, ObjectFactory objectFactory, List<Class<?>> constructorArgTypes, List<Object> constructorArgs)` 方法，创建代理对象。代码如下：
+
+```
+// JavassistProxyFactory.java
+
+@Override
+public Object createProxy(Object target, ResultLoaderMap lazyLoader, Configuration configuration, ObjectFactory objectFactory, List<Class<?>> constructorArgTypes, List<Object> constructorArgs) {
+    return EnhancedResultObjectProxyImpl.createProxy(target, lazyLoader, configuration, objectFactory, constructorArgTypes, constructorArgs);
+}
+```
+
+### 5.1.4 crateProxy 静态方法
+
+`#crateProxy(Class<?> type, MethodHandler callback, List<Class<?>> constructorArgTypes, List<Object> constructorArgs)` **静态**方法，创建代理对象。代码如下：
+
+```
+// JavassistProxyFactory.java
+
+static Object crateProxy(Class<?> type, MethodHandler callback, List<Class<?>> constructorArgTypes, List<Object> constructorArgs) {
+    // 创建 javassist ProxyFactory 对象
+    ProxyFactory enhancer = new ProxyFactory();
+    // 设置父类
+    enhancer.setSuperclass(type);
+
+    // 根据情况，设置接口为 WriteReplaceInterface 。和序列化相关，可以无视
+    try {
+        type.getDeclaredMethod(WRITE_REPLACE_METHOD); // 如果已经存在 writeReplace 方法，则不用设置接口为 WriteReplaceInterface
+        // ObjectOutputStream will call writeReplace of objects returned by writeReplace
+        if (log.isDebugEnabled()) {
+            log.debug(WRITE_REPLACE_METHOD + " method was found on bean " + type + ", make sure it returns this");
+        }
+    } catch (NoSuchMethodException e) {
+        enhancer.setInterfaces(new Class[]{WriteReplaceInterface.class}); // 如果不存在 writeReplace 方法，则设置接口为 WriteReplaceInterface
+    } catch (SecurityException e) {
+        // nothing to do here
+    }
+
+    // 创建代理对象
+    Object enhanced;
+    Class<?>[] typesArray = constructorArgTypes.toArray(new Class[constructorArgTypes.size()]);
+    Object[] valuesArray = constructorArgs.toArray(new Object[constructorArgs.size()]);
+    try {
+        enhanced = enhancer.create(typesArray, valuesArray);
+    } catch (Exception e) {
+        throw new ExecutorException("Error creating lazy proxy.  Cause: " + e, e);
+    }
+
+    // <x> 设置代理对象的执行器
+    ((Proxy) enhanced).setHandler(callback);
+    return enhanced;
+}
+```
+
+- 常见的基于 Javassist 的 API ，创建代理对象。
+- `<x>` 处，设置代理对象的执行器。该执行器，就是 EnhancedResultObjectProxyImpl 对象。详细解析，见 [「5.1.5 EnhancedResultObjectProxyImpl」](https://svip.iocoder.cn/MyBatis/executor-5/#) 。
+
+### 5.1.5 EnhancedResultObjectProxyImpl
+
+EnhancedResultObjectProxyImpl ，是 JavassistProxyFactory 的内部静态类，实现 `javassist.util.proxy.MethodHandler` 接口，方法处理器实现类。
+
+#### 5.1.5.1 构造方法
+
+```
+// JavassistProxyFactory.java
+
+private static class EnhancedResultObjectProxyImpl implements MethodHandler {
+
+    private final Class<?> type;
+    private final ResultLoaderMap lazyLoader;
+    private final boolean aggressive;
+    private final Set<String> lazyLoadTriggerMethods;
+    private final ObjectFactory objectFactory;
+    private final List<Class<?>> constructorArgTypes;
+    private final List<Object> constructorArgs;
+
+    private EnhancedResultObjectProxyImpl(Class<?> type, ResultLoaderMap lazyLoader, Configuration configuration, ObjectFactory objectFactory, List<Class<?>> constructorArgTypes, List<Object> constructorArgs) {
+        this.type = type;
+        this.lazyLoader = lazyLoader;
+        this.aggressive = configuration.isAggressiveLazyLoading();
+        this.lazyLoadTriggerMethods = configuration.getLazyLoadTriggerMethods();
+        this.objectFactory = objectFactory;
+        this.constructorArgTypes = constructorArgTypes;
+        this.constructorArgs = constructorArgs;
+    }
+    
+    // ... 暂时省略无关方法
+}
+```
+
+- 涉及的 `aggressive` 和 `lazyLoadTriggerMethods` 属性，在 Configuration 定义如下：
+
+  ```
+  // Configuration.java
+  
+  /**
+   * 当开启时，任何方法的调用都会加载该对象的所有属性。否则，每个属性会按需加载（参考lazyLoadTriggerMethods)
+   */
+  protected boolean aggressiveLazyLoading;
+  
+  /**
+   * 指定哪个对象的方法触发一次延迟加载。
+   */
+  protected Set<String> lazyLoadTriggerMethods = new HashSet<>(Arrays.asList("equals", "clone", "hashCode", "toString"));
+  ```
+
+#### 5.1.5.2 createProxy
+
+`#createProxy(Object target, ResultLoaderMap lazyLoader, Configuration configuration, ObjectFactory objectFactory, List<Class<?>> constructorArgTypes, List<Object> constructorArgs)` 方法，创建代理对象，并设置方法处理器为 EnhancedResultObjectProxyImpl 对象。代码如下：
+
+> 因为方法名 createProxy 一直在重复，所以这里艿艿说下调用链：
+>
+> 「5.1.3 createProxy 普通方法」 => 「5.1.4.2 createProxy」 => 「5.1.4 createProxy 静态方法」
+
+```
+// JavassistProxyFactory.java
+
+public static Object createProxy(Object target, ResultLoaderMap lazyLoader, Configuration configuration, ObjectFactory objectFactory, List<Class<?>> constructorArgTypes, List<Object> constructorArgs) {
+    final Class<?> type = target.getClass();
+    // 创建 EnhancedResultObjectProxyImpl 对象
+    EnhancedResultObjectProxyImpl callback = new EnhancedResultObjectProxyImpl(type, lazyLoader, configuration, objectFactory, constructorArgTypes, constructorArgs);
+    // 创建代理对象
+    Object enhanced = crateProxy(type, callback, constructorArgTypes, constructorArgs);
+    // 将 target 的属性，复制到 enhanced 中
+    PropertyCopier.copyBeanProperties(type, target, enhanced);
+    return enhanced;
+}
+```
+
+- 代码比较简单，胖友仔细瞅瞅，不要绕晕噢。
+
+#### 5.1.5.3 invoke
+
+`#invoke(Object enhanced, Method method, Method methodProxy, Object[] args)` 方法，执行方法。代码如下：
+
+```
+// JavassistProxyFactory.java
+
+    @Override
+    public Object invoke(Object enhanced, Method method, Method methodProxy, Object[] args) throws Throwable {
+        final String methodName = method.getName();
+        try {
+            synchronized (lazyLoader) {
+                // 忽略 WRITE_REPLACE_METHOD ，和序列化相关
+                if (WRITE_REPLACE_METHOD.equals(methodName)) {
+                    Object original;
+                    if (constructorArgTypes.isEmpty()) {
+                        original = objectFactory.create(type);
+                    } else {
+                        original = objectFactory.create(type, constructorArgTypes, constructorArgs);
+                    }
+                    PropertyCopier.copyBeanProperties(type, enhanced, original);
+                    if (lazyLoader.size() > 0) {
+                        return new JavassistSerialStateHolder(original, lazyLoader.getProperties(), objectFactory, constructorArgTypes, constructorArgs);
+                    } else {
+                        return original;
+                    }
+                } else {
+                    if (lazyLoader.size() > 0 && !FINALIZE_METHOD.equals(methodName)) {
+                        // <1.1> 加载所有延迟加载的属性
+                        if (aggressive || lazyLoadTriggerMethods.contains(methodName)) {
+                            lazyLoader.loadAll();
+                        // <1.2> 如果调用了 setting 方法，则不在使用延迟加载
+                        } else if (PropertyNamer.isSetter(methodName)) {
+                            final String property = PropertyNamer.methodToProperty(methodName);
+                            lazyLoader.remove(property); // 移除
+                        // <1.3> 如果调用了 getting 方法，则执行延迟加载
+                        } else if (PropertyNamer.isGetter(methodName)) {
+                            final String property = PropertyNamer.methodToProperty(methodName);
+                            if (lazyLoader.hasLoader(property)) {
+                                lazyLoader.load(property);
+                            }
+                        }
+                    }
+                }
+            }
+            // <2> 继续执行原方法
+            return methodProxy.invoke(enhanced, args);
+        } catch (Throwable t) {
+            throw ExceptionUtil.unwrapThrowable(t);
+        }
+    }
+}
+```
+
+- `<1.1>` 处，如果满足条件，则调用 `ResultLoaderMap#loadAll()` 方法，加载所有延迟加载的属性。
+- `<1.2>` 处，如果调用了 setting 方法，则调用 `ResultLoaderMap#remove(String property)` 方法，不在使用延迟加载。因为，具体的值都设置了，无需在延迟加载了。
+- `<1.3>` 处，如果调用了 getting 方法，则调用 `ResultLoaderMap#load(String property)` 方法，执行指定属性的延迟加载。**此处，就会去数据库中查询，并设置到对应的属性**。
+- `<2>` 处，继续执行原方法。
+
+## 5.2 CglibProxyFactory
+
+`org.apache.ibatis.executor.loader.cglib.CglibProxyFactory` ，实现 ProxyFactory 接口，基于 Cglib 的 ProxyFactory 实现类。
+
+CglibProxyFactory 和 JavassistProxyFactory 的代码实现非常类似，此处就不重复解析了。感兴趣的胖友，自己研究下。
+
+# 666. 彩蛋
+
+哎哟，比想象中的简单好多。嘿嘿。
+
+参考和推荐如下文章：
+
+- 祖大俊 [《Mybatis3.4.x技术内幕（二十一）：参数设置、结果封装、级联查询、延迟加载原理分析》](https://my.oschina.net/zudajun/blog/747283)
+- 无忌 [《MyBatis源码解读之延迟加载》](https://my.oschina.net/wenjinglian/blog/1857581)
+- 徐郡明 [《MyBatis 技术内幕》](https://item.jd.com/12125531.html) 的 [「3.3.5 嵌套查询&延迟加载」](https://svip.iocoder.cn/MyBatis/executor-5/#) 小节
\ No newline at end of file
diff --git a/mybatis/26-mybatis-会话 SqlSession.assets/01.png b/mybatis/26-mybatis-会话 SqlSession.assets/01.png
new file mode 100644
index 0000000..a410fe5
Binary files /dev/null and b/mybatis/26-mybatis-会话 SqlSession.assets/01.png differ
diff --git a/mybatis/26-mybatis-会话 SqlSession.assets/02.png b/mybatis/26-mybatis-会话 SqlSession.assets/02.png
new file mode 100644
index 0000000..94bf127
Binary files /dev/null and b/mybatis/26-mybatis-会话 SqlSession.assets/02.png differ
diff --git a/mybatis/26-mybatis-会话 SqlSession.assets/05.png b/mybatis/26-mybatis-会话 SqlSession.assets/05.png
new file mode 100644
index 0000000..72f7dc6
Binary files /dev/null and b/mybatis/26-mybatis-会话 SqlSession.assets/05.png differ
diff --git a/mybatis/26-mybatis-会话 SqlSession.md b/mybatis/26-mybatis-会话 SqlSession.md
new file mode 100644
index 0000000..626f4a7
--- /dev/null
+++ b/mybatis/26-mybatis-会话 SqlSession.md	
@@ -0,0 +1,1667 @@
+# 精尽 MyBatis 源码分析 —— 会话 SqlSession
+
+# 1. 概述
+
+在前面，我们已经详细解析了 MyBatis 执行器 Executor 相关的内容，但是显然，Executor 是不适合直接暴露给用户使用的，而是需要通过 SqlSession 。
+
+流程如下图：
+
+> [![流程图](26-mybatis-会话 SqlSession.assets/05.png)](http://static.iocoder.cn/images/MyBatis/2020_01_04/05.png)流程图
+
+示例代码如下：
+
+```
+// 仅仅是示例哈
+
+// 构建 SqlSessionFactory 对象
+Reader reader = Resources.getResourceAsReader("org/apache/ibatis/autoconstructor/mybatis-config.xml");
+SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(reader);
+
+// 获得 SqlSession 对象
+SqlSession sqlSession = sqlSessionFactory.openSession();
+
+// 获得 Mapper 对象
+final AutoConstructorMapper mapper = sqlSession.getMapper(AutoConstructorMapper.class);
+
+// 执行查询
+final Object subject = mapper.getSubject(1);
+```
+
+而本文解析的类，都在 `session` 包下，整体类图如下：
+
+> 老艿艿：省略了一部分前面已经解析过的类。
+
+[![类图](26-mybatis-会话 SqlSession.assets/01.png)](http://static.iocoder.cn/images/MyBatis/2020_03_15/01.png)类图
+
+- 核心是 SqlSession 。
+- SqlSessionFactory ，负责创建 SqlSession 对象的工厂。
+- SqlSessionFactoryBuilder ，是 SqlSessionFactory 的构建器。
+
+下面，我们按照 SqlSessionFactoryBuilder => SqlSessionFactory => SqlSession 来详细解析。
+
+# 2. SqlSessionFactoryBuilder
+
+`org.apache.ibatis.session.SqlSessionFactoryBuilder` ，SqlSessionFactory 构造器。代码如下：
+
+```
+// SqlSessionFactory.java
+
+public class SqlSessionFactoryBuilder {
+
+    public SqlSessionFactory build(Reader reader) {
+        return build(reader, null, null);
+    }
+
+    public SqlSessionFactory build(Reader reader, String environment) {
+        return build(reader, environment, null);
+    }
+
+    public SqlSessionFactory build(Reader reader, Properties properties) {
+        return build(reader, null, properties);
+    }
+
+    /**
+     * 构造 SqlSessionFactory 对象
+     *
+     * @param reader Reader 对象
+     * @param environment 环境
+     * @param properties Properties 变量
+     * @return SqlSessionFactory 对象
+     */
+    @SuppressWarnings("Duplicates")
+    public SqlSessionFactory build(Reader reader, String environment, Properties properties) {
+        try {
+            // 创建 XMLConfigBuilder 对象
+            XMLConfigBuilder parser = new XMLConfigBuilder(reader, environment, properties);
+            // 执行 XML 解析
+            // 创建 DefaultSqlSessionFactory 对象
+            return build(parser.parse());
+        } catch (Exception e) {
+            throw ExceptionFactory.wrapException("Error building SqlSession.", e);
+        } finally {
+            ErrorContext.instance().reset();
+            try {
+                reader.close();
+            } catch (IOException e) {
+                // Intentionally ignore. Prefer previous error.
+            }
+        }
+    }
+
+    public SqlSessionFactory build(InputStream inputStream) {
+        return build(inputStream, null, null);
+    }
+
+    public SqlSessionFactory build(InputStream inputStream, String environment) {
+        return build(inputStream, environment, null);
+    }
+
+    public SqlSessionFactory build(InputStream inputStream, Properties properties) {
+        return build(inputStream, null, properties);
+    }
+
+    public SqlSessionFactory build(InputStream inputStream, String environment, Properties properties) {
+        try {
+            // 创建 XMLConfigBuilder 对象
+            XMLConfigBuilder parser = new XMLConfigBuilder(inputStream, environment, properties);
+            // 执行 XML 解析
+            // 创建 DefaultSqlSessionFactory 对象
+            return build(parser.parse());
+        } catch (Exception e) {
+            throw ExceptionFactory.wrapException("Error building SqlSession.", e);
+        } finally {
+            ErrorContext.instance().reset();
+            try {
+                inputStream.close();
+            } catch (IOException e) {
+                // Intentionally ignore. Prefer previous error.
+            }
+        }
+    }
+
+    /**
+     * 创建 DefaultSqlSessionFactory 对象
+     *
+     * @param config Configuration 对象
+     * @return DefaultSqlSessionFactory 对象
+     */
+    public SqlSessionFactory build(Configuration config) {
+        return new DefaultSqlSessionFactory(config);
+    }
+
+}
+```
+
+- 提供了各种 build 的重载方法，核心的套路都是解析出 Configuration 配置对象，从而创建出 DefaultSqlSessionFactory 对象。
+
+# 3. SqlSessionFactory
+
+`org.apache.ibatis.session.SqlSessionFactory` ，SqlSession 工厂接口。代码如下：
+
+```
+// SqlSessionFactory.java
+
+public interface SqlSessionFactory {
+
+    SqlSession openSession();
+
+    SqlSession openSession(boolean autoCommit);
+
+    SqlSession openSession(Connection connection);
+
+    SqlSession openSession(TransactionIsolationLevel level);
+
+    SqlSession openSession(ExecutorType execType);
+
+    SqlSession openSession(ExecutorType execType, boolean autoCommit);
+
+    SqlSession openSession(ExecutorType execType, TransactionIsolationLevel level);
+
+    SqlSession openSession(ExecutorType execType, Connection connection);
+
+    Configuration getConfiguration();
+
+}
+```
+
+- 定义了 `#openSession(...)` 和 `#getConfiguration()` 两类方法。
+
+## 3.1 DefaultSqlSessionFactory
+
+`org.apache.ibatis.session.defaults.DefaultSqlSessionFactory` ，实现 SqlSessionFactory 接口，默认的 SqlSessionFactory 实现类。
+
+### 3.1.1 构造方法
+
+```
+// DefaultSqlSessionFactory.java
+
+private final Configuration configuration;
+
+public DefaultSqlSessionFactory(Configuration configuration) {
+    this.configuration = configuration;
+}
+
+@Override
+public Configuration getConfiguration() {
+    return configuration;
+}
+```
+
+### 3.1.2 openSession
+
+```
+// DefaultSqlSessionFactory.java
+
+@Override
+public SqlSession openSession() {
+    return openSessionFromDataSource(configuration.getDefaultExecutorType(), null, false);
+}
+
+@Override
+public SqlSession openSession(boolean autoCommit) {
+    return openSessionFromDataSource(configuration.getDefaultExecutorType(), null, autoCommit);
+}
+
+@Override
+public SqlSession openSession(ExecutorType execType) {
+    return openSessionFromDataSource(execType, null, false);
+}
+
+@Override
+public SqlSession openSession(TransactionIsolationLevel level) {
+    return openSessionFromDataSource(configuration.getDefaultExecutorType(), level, false);
+}
+
+@Override
+public SqlSession openSession(ExecutorType execType, TransactionIsolationLevel level) {
+    return openSessionFromDataSource(execType, level, false);
+}
+
+@Override
+public SqlSession openSession(ExecutorType execType, boolean autoCommit) {
+    return openSessionFromDataSource(execType, null, autoCommit);
+}
+
+@Override
+public SqlSession openSession(Connection connection) {
+    return openSessionFromConnection(configuration.getDefaultExecutorType(), connection);
+}
+
+@Override
+public SqlSession openSession(ExecutorType execType, Connection connection) {
+    return openSessionFromConnection(execType, connection);
+}
+```
+
+- 调用 `#openSessionFromDataSource(ExecutorType execType, TransactionIsolationLevel level, boolean autoCommit)` 方法，获得 SqlSession 对象。代码如下：
+
+  ```
+  // DefaultSqlSessionFactory.java
+  
+  private SqlSession openSessionFromDataSource(ExecutorType execType, TransactionIsolationLevel level, boolean autoCommit) {
+      Transaction tx = null;
+      try {
+          // 获得 Environment 对象
+          final Environment environment = configuration.getEnvironment();
+          // 创建 Transaction 对象
+          final TransactionFactory transactionFactory = getTransactionFactoryFromEnvironment(environment);
+          tx = transactionFactory.newTransaction(environment.getDataSource(), level, autoCommit);
+          // 创建 Executor 对象
+          final Executor executor = configuration.newExecutor(tx, execType);
+          // 创建 DefaultSqlSession 对象
+          return new DefaultSqlSession(configuration, executor, autoCommit);
+      } catch (Exception e) {
+          // 如果发生异常，则关闭 Transaction 对象
+          closeTransaction(tx); // may have fetched a connection so lets call close()
+          throw ExceptionFactory.wrapException("Error opening session.  Cause: " + e, e);
+      } finally {
+          ErrorContext.instance().reset();
+      }
+  }
+  ```
+
+  - DefaultSqlSession 的创建，需要 `configuration`、`executor`、`autoCommit` 三个参数。
+
+- `#openSessionFromConnection(ExecutorType execType, Connection connection)` 方法，获得 SqlSession 对象。代码如下：
+
+  ```
+  // DefaultSqlSessionFactory.java
+  
+  private SqlSession openSessionFromConnection(ExecutorType execType, Connection connection) {
+      try {
+          // 获得是否可以自动提交
+          boolean autoCommit;
+          try {
+              autoCommit = connection.getAutoCommit();
+          } catch (SQLException e) {
+              // Failover to true, as most poor drivers
+              // or databases won't support transactions
+              autoCommit = true;
+          }
+          // 获得 Environment 对象
+          final Environment environment = configuration.getEnvironment();
+          // 创建 Transaction 对象
+          final TransactionFactory transactionFactory = getTransactionFactoryFromEnvironment(environment);
+          final Transaction tx = transactionFactory.newTransaction(connection);
+          // 创建 Executor 对象
+          final Executor executor = configuration.newExecutor(tx, execType);
+          // 创建 DefaultSqlSession 对象
+          return new DefaultSqlSession(configuration, executor, autoCommit);
+      } catch (Exception e) {
+          throw ExceptionFactory.wrapException("Error opening session.  Cause: " + e, e);
+      } finally {
+          ErrorContext.instance().reset();
+      }
+  }
+  ```
+
+### 3.1.3 getTransactionFactoryFromEnvironment
+
+```
+// DefaultSqlSessionFactory.java
+
+private TransactionFactory getTransactionFactoryFromEnvironment(Environment environment) {
+    // 情况一，创建 ManagedTransactionFactory 对象
+    if (environment == null || environment.getTransactionFactory() == null) {
+        return new ManagedTransactionFactory();
+    }
+    // 情况二，使用 `environment` 中的
+    return environment.getTransactionFactory();
+}
+```
+
+### 3.1.4 closeTransaction
+
+```
+// DefaultSqlSessionFactory.java
+
+private void closeTransaction(Transaction tx) {
+    if (tx != null) {
+        try {
+            tx.close();
+        } catch (SQLException ignore) {
+            // Intentionally ignore. Prefer previous error.
+        }
+    }
+}
+```
+
+# 4. SqlSession
+
+`org.apache.ibatis.session.SqlSession` ，SQL Session 接口。代码如下：
+
+```
+// SqlSession.java
+
+public interface SqlSession extends Closeable {
+
+    <T> T selectOne(String statement);
+    <T> T selectOne(String statement, Object parameter);
+
+    <E> List<E> selectList(String statement);
+    <E> List<E> selectList(String statement, Object parameter);
+    <E> List<E> selectList(String statement, Object parameter, RowBounds rowBounds);
+
+    <K, V> Map<K, V> selectMap(String statement, String mapKey);
+    <K, V> Map<K, V> selectMap(String statement, Object parameter, String mapKey);
+    <K, V> Map<K, V> selectMap(String statement, Object parameter, String mapKey, RowBounds rowBounds);
+
+    <T> Cursor<T> selectCursor(String statement);
+    <T> Cursor<T> selectCursor(String statement, Object parameter);
+    <T> Cursor<T> selectCursor(String statement, Object parameter, RowBounds rowBounds);
+
+    void select(String statement, Object parameter, ResultHandler handler);
+    void select(String statement, ResultHandler handler);
+    void select(String statement, Object parameter, RowBounds rowBounds, ResultHandler handler);
+
+    int insert(String statement);
+    int insert(String statement, Object parameter);
+
+    int update(String statement);
+    int update(String statement, Object parameter);
+
+    int delete(String statement);
+    int delete(String statement, Object parameter);
+
+    void commit();
+    void commit(boolean force);
+    void rollback();
+    void rollback(boolean force);
+
+    List<BatchResult> flushStatements();
+
+    @Override
+    void close();
+
+    void clearCache();
+
+    Configuration getConfiguration();
+
+    /**
+     * Retrieves a mapper.
+     * @param <T> the mapper type
+     * @param type Mapper interface class
+     * @return a mapper bound to this SqlSession
+     */
+    <T> T getMapper(Class<T> type);
+
+    /**
+     * Retrieves inner database connection
+     * @return Connection
+     */
+    Connection getConnection();
+
+}
+```
+
+- 大体接口上，和 Executor 接口是相似的。
+
+## 4.1 DefaultSqlSession
+
+`org.apache.ibatis.session.defaults.DefaultSqlSession` ，实现 SqlSession 接口，默认的 SqlSession 实现类。
+
+### 4.1.1 构造方法
+
+```
+// DefaultSqlSession.java
+
+private final Configuration configuration;
+private final Executor executor;
+
+/**
+ * 是否自动提交事务
+ */
+private final boolean autoCommit;
+/**
+ * 是否发生数据变更
+ */
+private boolean dirty;
+/**
+ * Cursor 数组
+ */
+private List<Cursor<?>> cursorList;
+
+public DefaultSqlSession(Configuration configuration, Executor executor, boolean autoCommit) {
+    this.configuration = configuration;
+    this.executor = executor;
+    this.dirty = false;
+    this.autoCommit = autoCommit;
+}
+
+public DefaultSqlSession(Configuration configuration, Executor executor) {
+    this(configuration, executor, false);
+}
+```
+
+### 4.1.2 selectList
+
+```
+// DefaultSqlSession.java
+
+@Override
+public <E> List<E> selectList(String statement) {
+    return this.selectList(statement, null);
+}
+
+@Override
+public <E> List<E> selectList(String statement, Object parameter) {
+    return this.selectList(statement, parameter, RowBounds.DEFAULT);
+}
+
+@Override
+public <E> List<E> selectList(String statement, Object parameter, RowBounds rowBounds) {
+    try {
+        // <1> 获得 MappedStatement 对象
+        MappedStatement ms = configuration.getMappedStatement(statement);
+        // <2> 执行查询
+        return executor.query(ms, wrapCollection(parameter), rowBounds, Executor.NO_RESULT_HANDLER);
+    } catch (Exception e) {
+        throw ExceptionFactory.wrapException("Error querying database.  Cause: " + e, e);
+    } finally {
+        ErrorContext.instance().reset();
+    }
+}
+```
+
+- `<1>` 处，调用 `Configuration#getMappedStatement(String id)` 方法，获得 MappedStatement 对象。代码如下：
+
+  ```
+  // DefaultSqlSession.java
+  
+  /**
+   * MappedStatement 映射
+   *
+   * KEY：`${namespace}.${id}`
+   */
+  protected final Map<String, MappedStatement> mappedStatements = new StrictMap<>("Mapped Statements collection");
+  
+  public MappedStatement getMappedStatement(String id, boolean validateIncompleteStatements) {
+      // 校验，保证所有 MappedStatement 已经构造完毕
+      if (validateIncompleteStatements) {
+          buildAllStatements();
+      }
+      // 获取 MappedStatement 对象
+      return mappedStatements.get(id);
+  }
+  
+  protected void buildAllStatements() {
+      if (!incompleteResultMaps.isEmpty()) {
+          synchronized (incompleteResultMaps) { // 保证 incompleteResultMaps 被解析完
+              // This always throws a BuilderException.
+              incompleteResultMaps.iterator().next().resolve();
+          }
+      }
+      if (!incompleteCacheRefs.isEmpty()) {
+          synchronized (incompleteCacheRefs) { // 保证 incompleteCacheRefs 被解析完
+              // This always throws a BuilderException.
+              incompleteCacheRefs.iterator().next().resolveCacheRef();
+          }
+      }
+      if (!incompleteStatements.isEmpty()) {
+          synchronized (incompleteStatements) { // 保证 incompleteStatements 被解析完
+              // This always throws a BuilderException.
+              incompleteStatements.iterator().next().parseStatementNode();
+          }
+      }
+      if (!incompleteMethods.isEmpty()) {
+          synchronized (incompleteMethods) { // 保证 incompleteMethods 被解析完
+              // This always throws a BuilderException.
+              incompleteMethods.iterator().next().resolve();
+          }
+      }
+  }
+  ```
+
+  - 其中，`#buildAllStatements()` 方法，是用来保证所有 MappedStatement 已经构造完毕。不过艿艿，暂时没想到，什么情况下，会出现 MappedStatement 没被正确构建的情况。猜测有可能是防御性编程。
+
+- `<2>` 处，调用 `Executor#query(...)` 方法，执行查询。
+
+### 4.1.3 selectOne
+
+```
+// DefaultSqlSession.java
+
+@Override
+public <T> T selectOne(String statement) {
+    return this.selectOne(statement, null);
+}
+
+@Override
+public <T> T selectOne(String statement, Object parameter) {
+    // Popular vote was to return null on 0 results and throw exception on too many.
+    List<T> list = this.selectList(statement, parameter);
+    if (list.size() == 1) {
+        return list.get(0);
+    } else if (list.size() > 1) {
+        throw new TooManyResultsException("Expected one result (or null) to be returned by selectOne(), but found: " + list.size());
+    } else {
+        return null;
+    }
+}
+```
+
+- 内部调用 `#selectList(String statement, Object parameter)` 方法，进行实现。
+
+### 4.1.4 selectMap
+
+`#selectMap(...)` 方法，查询结果，并基于 Map 聚合结果。代码如下：
+
+```
+// DefaultSqlSession.java
+
+@Override
+public <K, V> Map<K, V> selectMap(String statement, String mapKey) {
+    return this.selectMap(statement, null, mapKey, RowBounds.DEFAULT);
+}
+
+@Override
+public <K, V> Map<K, V> selectMap(String statement, Object parameter, String mapKey) {
+    return this.selectMap(statement, parameter, mapKey, RowBounds.DEFAULT);
+}
+
+@Override
+public <K, V> Map<K, V> selectMap(String statement, Object parameter, String mapKey, RowBounds rowBounds) {
+    // <1> 执行查询
+    final List<? extends V> list = selectList(statement, parameter, rowBounds);
+    // <2> 创建 DefaultMapResultHandler 对象
+    final DefaultMapResultHandler<K, V> mapResultHandler = new DefaultMapResultHandler<>(mapKey,
+            configuration.getObjectFactory(), configuration.getObjectWrapperFactory(), configuration.getReflectorFactory());
+    // <3> 创建 DefaultResultContext 对象
+    final DefaultResultContext<V> context = new DefaultResultContext<>();
+    // <4> 遍历查询结果
+    for (V o : list) {
+        // 设置 DefaultResultContext 中
+        context.nextResultObject(o);
+        // 使用 DefaultMapResultHandler 处理结果的当前元素
+        mapResultHandler.handleResult(context);
+    }
+    // <5> 返回结果
+    return mapResultHandler.getMappedResults();
+}
+```
+
+- `<1>` 处，调用 `#selectList(String statement, Object parameter, RowBounds rowBounds)` 方法，执行查询。
+
+- `<2>` 处，创建 DefaultMapResultHandler 对象。
+
+- `<3>` 处，创建 DefaultResultContext 对象。
+
+- `<4>` 处，遍历查询结果，并调用 `DefaultMapResultHandler#handleResult(context)` 方法，将结果的当前元素，聚合成 Map 。代码如下：
+
+  ```
+  // DefaultMapResultHandler.java
+  
+  public class DefaultMapResultHandler<K, V> implements ResultHandler<V> {
+  
+      /**
+       * 结果，基于 Map 聚合
+       */
+      private final Map<K, V> mappedResults;
+      /**
+       * {@link #mappedResults} 的 KEY 属性名
+       */
+      private final String mapKey;
+      private final ObjectFactory objectFactory;
+      private final ObjectWrapperFactory objectWrapperFactory;
+      private final ReflectorFactory reflectorFactory;
+  
+      @SuppressWarnings("unchecked")
+      public DefaultMapResultHandler(String mapKey, ObjectFactory objectFactory, ObjectWrapperFactory objectWrapperFactory, ReflectorFactory reflectorFactory) {
+          this.objectFactory = objectFactory;
+          this.objectWrapperFactory = objectWrapperFactory;
+          this.reflectorFactory = reflectorFactory;
+          // 创建 Map 对象
+          this.mappedResults = objectFactory.create(Map.class);
+          this.mapKey = mapKey;
+      }
+  
+      @Override
+      public void handleResult(ResultContext<? extends V> context) {
+          // 获得 KEY 对应的属性
+          final V value = context.getResultObject();
+          final MetaObject mo = MetaObject.forObject(value, objectFactory, objectWrapperFactory, reflectorFactory);
+          // TODO is that assignment always true?
+          final K key = (K) mo.getValue(mapKey);
+          // 添加到 mappedResults 中
+          mappedResults.put(key, value);
+      }
+  
+      public Map<K, V> getMappedResults() {
+          return mappedResults;
+      }
+  
+  }
+  ```
+
+- `<5>` 处，返回结果。
+
+### 4.1.5 selectCursor
+
+```
+// DefaultSqlSession.java
+
+@Override
+public <T> Cursor<T> selectCursor(String statement) {
+    return selectCursor(statement, null);
+}
+
+@Override
+public <T> Cursor<T> selectCursor(String statement, Object parameter) {
+    return selectCursor(statement, parameter, RowBounds.DEFAULT);
+}
+
+@Override
+public <T> Cursor<T> selectCursor(String statement, Object parameter, RowBounds rowBounds) {
+    try {
+        // <1> 获得 MappedStatement 对象
+        MappedStatement ms = configuration.getMappedStatement(statement);
+        // <2> 执行查询
+        Cursor<T> cursor = executor.queryCursor(ms, wrapCollection(parameter), rowBounds);
+        // <3> 添加 cursor 到 cursorList 中
+        registerCursor(cursor);
+        return cursor;
+    } catch (Exception e) {
+        throw ExceptionFactory.wrapException("Error querying database.  Cause: " + e, e);
+    } finally {
+        ErrorContext.instance().reset();
+    }
+}
+```
+
+- `<1>` 处，调用 `Configuration#getMappedStatement(String id)` 方法，获得 MappedStatement 对象。
+
+- `<2>` 处，调用 `Executor#queryCursor(...)` 方法，执行查询。
+
+- `<3>` 处，调用 `#registerCursor(Cursor<T> cursor)` 方法，添加 `cursor` 到 `cursorList` 中。代码如下：
+
+  ```
+  // DefaultSqlSession.java
+  
+  private <T> void registerCursor(Cursor<T> cursor) {
+      if (cursorList == null) {
+          cursorList = new ArrayList<>();
+      }
+      cursorList.add(cursor);
+  }
+  ```
+
+### 4.1.6 select
+
+`#select(..., ResultHandler handler)` 方法，执行查询，使用传入的 `handler` 方法参数，对结果进行处理。代码如下：
+
+```
+// DefaultSqlSession.java
+
+@Override
+public void select(String statement, Object parameter, ResultHandler handler) {
+    select(statement, parameter, RowBounds.DEFAULT, handler);
+}
+
+@Override
+public void select(String statement, ResultHandler handler) {
+    select(statement, null, RowBounds.DEFAULT, handler);
+}
+
+@Override
+public void select(String statement, Object parameter, RowBounds rowBounds, ResultHandler handler) {
+    try {
+        // 获得 MappedStatement 对象
+        MappedStatement ms = configuration.getMappedStatement(statement);
+        // 执行查询
+        executor.query(ms, wrapCollection(parameter), rowBounds, handler);
+    } catch (Exception e) {
+        throw ExceptionFactory.wrapException("Error querying database.  Cause: " + e, e);
+    } finally {
+        ErrorContext.instance().reset();
+    }
+}
+```
+
+### 4.1.7 wrapCollection
+
+在上述的查询方法中，我们都可以看到一个 `#wrapCollection(final Object object)` 方法，若参数 `object` 是 Collection、Array、Map 参数类型的情况下，包装成 Map 返回。代码如下：
+
+```
+// DefaultSqlSession.java
+
+private Object wrapCollection(final Object object) {
+    if (object instanceof Collection) {
+        // 如果是集合，则添加到 collection 中
+        StrictMap<Object> map = new StrictMap<>();
+        map.put("collection", object);
+        // 如果是 List ，则添加到 list 中
+        if (object instanceof List) {
+            map.put("list", object);
+        }
+        return map;
+    } else if (object != null && object.getClass().isArray()) {
+        // 如果是 Array ，则添加到 array 中
+        StrictMap<Object> map = new StrictMap<>();
+        map.put("array", object);
+        return map;
+    }
+    return object;
+}
+```
+
+### 4.1.8 update
+
+```
+// DefaultSqlSession.java
+
+@Override
+public int update(String statement) {
+    return update(statement, null);
+}
+
+@Override
+public int update(String statement, Object parameter) {
+    try {
+        // <1> 标记 dirty ，表示执行过写操作
+        dirty = true;
+        // <2> 获得 MappedStatement 对象
+        MappedStatement ms = configuration.getMappedStatement(statement);
+        // <3> 执行更新操作
+        return executor.update(ms, wrapCollection(parameter));
+    } catch (Exception e) {
+        throw ExceptionFactory.wrapException("Error updating database.  Cause: " + e, e);
+    } finally {
+        ErrorContext.instance().reset();
+    }
+}
+```
+
+- `<1>` 处，标记 `dirty` ，表示执行过写操作。该参数，会在事务的提交和回滚，产生其用途。
+- `<2>` 处，获得 MappedStatement 对象。
+- `<3>` 处，调用 `Executor#update(MappedStatement ms, Object parameter)` 方法，执行更新操作。
+
+### 4.1.9 insert
+
+```
+// DefaultSqlSession.java
+
+@Override
+public int insert(String statement) {
+    return insert(statement, null);
+}
+
+@Override
+public int insert(String statement, Object parameter) {
+    return update(statement, parameter);
+}
+```
+
+- 基于 `#update(...)` 方法来实现。
+
+### 4.1.10 delete
+
+```
+// DefaultSqlSession.java
+
+@Override
+public int delete(String statement) {
+    return update(statement, null);
+}
+
+@Override
+public int delete(String statement, Object parameter) {
+    return update(statement, parameter);
+}
+```
+
+- 基于 `#update(...)` 方法来实现。
+
+### 4.1.11 flushStatements
+
+`#flushStatements()` 方法，提交批处理。代码如下：
+
+```
+// DefaultSqlSession.java
+
+@Override
+public List<BatchResult> flushStatements() {
+    try {
+        return executor.flushStatements();
+    } catch (Exception e) {
+        throw ExceptionFactory.wrapException("Error flushing statements.  Cause: " + e, e);
+    } finally {
+        ErrorContext.instance().reset();
+    }
+}
+```
+
+### 4.1.12 commit
+
+```
+// DefaultSqlSession.java
+
+@Override
+public void commit() {
+    commit(false);
+}
+
+@Override
+public void commit(boolean force) {
+    try {
+        // 提交事务
+        executor.commit(isCommitOrRollbackRequired(force));
+        // 标记 dirty 为 false
+        dirty = false;
+    } catch (Exception e) {
+        throw ExceptionFactory.wrapException("Error committing transaction.  Cause: " + e, e);
+    } finally {
+        ErrorContext.instance().reset();
+    }
+}
+```
+
+- 其中，`#isCommitOrRollbackRequired(boolean force)` 方法，判断是否执行提交或回滚。代码如下：
+
+  ```
+  // DefaultSqlSession.java
+  
+  private boolean isCommitOrRollbackRequired(boolean force) {
+      return (!autoCommit && dirty) || force;
+  }
+  ```
+
+  - 有两种情况需要触发：
+  - 1）未开启自动提交，并且数据发生写操作
+  - 2）强制提交
+
+### 4.1.13 rollback
+
+```
+// DefaultSqlSession.java
+
+@Override
+public void rollback() {
+    rollback(false);
+}
+
+@Override
+public void rollback(boolean force) {
+    try {
+        // 回滚事务
+        executor.rollback(isCommitOrRollbackRequired(force));
+        // 标记 dirty 为 false
+        dirty = false;
+    } catch (Exception e) {
+        throw ExceptionFactory.wrapException("Error rolling back transaction.  Cause: " + e, e);
+    } finally {
+        ErrorContext.instance().reset();
+    }
+}
+```
+
+### 4.1.14 close
+
+`#close()` 方法，关闭会话。代码如下：
+
+```
+// DefaultSqlSession.java
+
+@Override
+public void close() {
+    try {
+        // <1> 关闭执行器
+        executor.close(isCommitOrRollbackRequired(false));
+        // <2> 关闭所有游标
+        closeCursors();
+        // <3> 重置 dirty 为 false
+        dirty = false;
+    } finally {
+        ErrorContext.instance().reset();
+    }
+}
+```
+
+- `<1>` 处，调用 `Executor#close(boolean forceRollback)` 方法，关闭执行器。并且，根据 `forceRollback` 参数，是否进行事务回滚。
+
+- `<2>` 处，调用 `#closeCursors()` 方法，关闭所有游标。代码如下：
+
+  ```
+  // DefaultSqlSession.java
+  
+  private void closeCursors() {
+      if (cursorList != null && cursorList.size() != 0) {
+          for (Cursor<?> cursor : cursorList) {
+              try {
+                  cursor.close();
+              } catch (IOException e) {
+                  throw ExceptionFactory.wrapException("Error closing cursor.  Cause: " + e, e);
+              }
+          }
+          cursorList.clear();
+      }
+  }
+  ```
+
+- `<3>` 处，重置 `dirty` 为 `false` 。
+
+### 4.1.15 getConfiguration
+
+```
+// DefaultSqlSession.java
+
+@Override
+public Configuration getConfiguration() {
+    return configuration;
+}
+```
+
+### 4.1.16 getMapper
+
+```
+// DefaultSqlSession.java
+
+@Override
+public <T> T getMapper(Class<T> type) {
+    return configuration.getMapper(type, this);
+}
+```
+
+### 4.1.17 getConnection
+
+```
+// DefaultSqlSession.java
+
+@Override
+public Connection getConnection() {
+    try {
+        return executor.getTransaction().getConnection();
+    } catch (SQLException e) {
+        throw ExceptionFactory.wrapException("Error getting a new connection.  Cause: " + e, e);
+    }
+}
+```
+
+### 4.1.18 clearCache
+
+```
+// DefaultSqlSession.java
+
+@Override
+public void clearCache() {
+    executor.clearLocalCache();
+}
+```
+
+# 5. SqlSessionManager
+
+`org.apache.ibatis.session.SqlSessionManager` ，实现 SqlSessionFactory、SqlSession 接口，SqlSession 管理器。所以，从这里已经可以看出，SqlSessionManager 是 SqlSessionFactory 和 SqlSession 的职能相加。
+
+## 5.1 构造方法
+
+```
+// SqlSessionManager.java
+
+private final SqlSessionFactory sqlSessionFactory;
+private final SqlSession sqlSessionProxy;
+
+/**
+ * 线程变量，当前线程的 SqlSession 对象
+ */
+private final ThreadLocal<SqlSession> localSqlSession = new ThreadLocal<>(); // <1>
+
+private SqlSessionManager(SqlSessionFactory sqlSessionFactory) {
+    this.sqlSessionFactory = sqlSessionFactory;
+    // <2> 创建 SqlSession 的代理对象
+    this.sqlSessionProxy = (SqlSession) Proxy.newProxyInstance(
+            SqlSessionFactory.class.getClassLoader(),
+            new Class[]{SqlSession.class},
+            new SqlSessionInterceptor());
+}
+```
+
+- 比较有意思的有两点，我们逐条来看。
+- `<1>` 处，`localSqlSession` 属性，线程变量，记录当前线程的 SqlSession 对象。
+- `<2>` 处，创建 SqlSession 的代理对象，而方法的拦截器是 SqlSessionInterceptor 类。详细解析，见 [「5.6 SqlSessionInterceptor」](https://svip.iocoder.cn/MyBatis/session/#) 。
+
+## 5.2 newInstance
+
+`#newInstance(...)` **静态**方法，创建 SqlSessionManager 对象。代码如下：
+
+```
+// SqlSessionManager.java
+
+public static SqlSessionManager newInstance(Reader reader) {
+    return new SqlSessionManager(new SqlSessionFactoryBuilder().build(reader, null, null));
+}
+
+public static SqlSessionManager newInstance(Reader reader, String environment) {
+    return new SqlSessionManager(new SqlSessionFactoryBuilder().build(reader, environment, null));
+}
+
+public static SqlSessionManager newInstance(Reader reader, Properties properties) {
+    return new SqlSessionManager(new SqlSessionFactoryBuilder().build(reader, null, properties));
+}
+
+public static SqlSessionManager newInstance(InputStream inputStream) {
+    return new SqlSessionManager(new SqlSessionFactoryBuilder().build(inputStream, null, null));
+}
+
+public static SqlSessionManager newInstance(InputStream inputStream, String environment) {
+    return new SqlSessionManager(new SqlSessionFactoryBuilder().build(inputStream, environment, null));
+}
+
+public static SqlSessionManager newInstance(InputStream inputStream, Properties properties) {
+    return new SqlSessionManager(new SqlSessionFactoryBuilder().build(inputStream, null, properties));
+}
+
+public static SqlSessionManager newInstance(SqlSessionFactory sqlSessionFactory) {
+    return new SqlSessionManager(sqlSessionFactory);
+}
+```
+
+- 代码比较简单，胖友自己瞅瞅。
+
+## 5.3 startManagedSession
+
+`#startManagedSession(...)` 方法，发起一个**可被管理的** SqlSession 。代码如下：
+
+```
+// SqlSessionManager.java
+
+public void startManagedSession() {
+    this.localSqlSession.set(openSession());
+}
+
+public void startManagedSession(boolean autoCommit) {
+    this.localSqlSession.set(openSession(autoCommit));
+}
+
+public void startManagedSession(Connection connection) {
+    this.localSqlSession.set(openSession(connection));
+}
+
+public void startManagedSession(TransactionIsolationLevel level) {
+    this.localSqlSession.set(openSession(level));
+}
+
+public void startManagedSession(ExecutorType execType) {
+    this.localSqlSession.set(openSession(execType));
+}
+
+public void startManagedSession(ExecutorType execType, boolean autoCommit) {
+    this.localSqlSession.set(openSession(execType, autoCommit));
+}
+
+public void startManagedSession(ExecutorType execType, TransactionIsolationLevel level) {
+    this.localSqlSession.set(openSession(execType, level));
+}
+
+public void startManagedSession(ExecutorType execType, Connection connection) {
+    this.localSqlSession.set(openSession(execType, connection));
+}
+```
+
+- 可能胖友很难理解“可被管理”的 SqlSession 的意思？继续往下看。
+
+## 5.4 对 SqlSessionFactory 的实现方法
+
+```
+// SqlSessionManager.java
+
+@Override
+public SqlSession openSession() {
+    return sqlSessionFactory.openSession();
+}
+
+@Override
+public SqlSession openSession(boolean autoCommit) {
+    return sqlSessionFactory.openSession(autoCommit);
+}
+
+@Override
+public SqlSession openSession(Connection connection) {
+    return sqlSessionFactory.openSession(connection);
+}
+
+@Override
+public SqlSession openSession(TransactionIsolationLevel level) {
+    return sqlSessionFactory.openSession(level);
+}
+
+@Override
+public SqlSession openSession(ExecutorType execType) {
+    return sqlSessionFactory.openSession(execType);
+}
+
+@Override
+public SqlSession openSession(ExecutorType execType, boolean autoCommit) {
+    return sqlSessionFactory.openSession(execType, autoCommit);
+}
+
+@Override
+public SqlSession openSession(ExecutorType execType, TransactionIsolationLevel level) {
+    return sqlSessionFactory.openSession(execType, level);
+}
+
+@Override
+public SqlSession openSession(ExecutorType execType, Connection connection) {
+    return sqlSessionFactory.openSession(execType, connection);
+}
+```
+
+- 直接调用 `sqlSessionFactory` 对应的方法即可。
+
+## 5.5 对 SqlSession 的实现方法
+
+```
+// SqlSessionManager.java
+
+@Override
+public <T> T selectOne(String statement) {
+    return sqlSessionProxy.selectOne(statement);
+}
+
+@Override
+public <T> T selectOne(String statement, Object parameter) {
+    return sqlSessionProxy.selectOne(statement, parameter);
+}
+
+@Override
+public <K, V> Map<K, V> selectMap(String statement, String mapKey) {
+    return sqlSessionProxy.selectMap(statement, mapKey);
+}
+
+@Override
+public <K, V> Map<K, V> selectMap(String statement, Object parameter, String mapKey) {
+    return sqlSessionProxy.selectMap(statement, parameter, mapKey);
+}
+
+@Override
+public <K, V> Map<K, V> selectMap(String statement, Object parameter, String mapKey, RowBounds rowBounds) {
+    return sqlSessionProxy.selectMap(statement, parameter, mapKey, rowBounds);
+}
+
+@Override
+public <T> Cursor<T> selectCursor(String statement) {
+    return sqlSessionProxy.selectCursor(statement);
+}
+
+@Override
+public <T> Cursor<T> selectCursor(String statement, Object parameter) {
+    return sqlSessionProxy.selectCursor(statement, parameter);
+}
+
+@Override
+public <T> Cursor<T> selectCursor(String statement, Object parameter, RowBounds rowBounds) {
+    return sqlSessionProxy.selectCursor(statement, parameter, rowBounds);
+}
+
+@Override
+public <E> List<E> selectList(String statement) {
+    return sqlSessionProxy.selectList(statement);
+}
+
+@Override
+public <E> List<E> selectList(String statement, Object parameter) {
+    return sqlSessionProxy.selectList(statement, parameter);
+}
+
+@Override
+public <E> List<E> selectList(String statement, Object parameter, RowBounds rowBounds) {
+    return sqlSessionProxy.selectList(statement, parameter, rowBounds);
+}
+
+@Override
+public void select(String statement, ResultHandler handler) {
+    sqlSessionProxy.select(statement, handler);
+}
+
+@Override
+public void select(String statement, Object parameter, ResultHandler handler) {
+    sqlSessionProxy.select(statement, parameter, handler);
+}
+
+@Override
+public void select(String statement, Object parameter, RowBounds rowBounds, ResultHandler handler) {
+    sqlSessionProxy.select(statement, parameter, rowBounds, handler);
+}
+
+@Override
+public int insert(String statement) {
+    return sqlSessionProxy.insert(statement);
+}
+
+@Override
+public int insert(String statement, Object parameter) {
+    return sqlSessionProxy.insert(statement, parameter);
+}
+
+@Override
+public int update(String statement) {
+    return sqlSessionProxy.update(statement);
+}
+
+@Override
+public int update(String statement, Object parameter) {
+    return sqlSessionProxy.update(statement, parameter);
+}
+
+@Override
+public int delete(String statement) {
+    return sqlSessionProxy.delete(statement);
+}
+
+@Override
+public int delete(String statement, Object parameter) {
+    return sqlSessionProxy.delete(statement, parameter);
+}
+
+@Override
+public <T> T getMapper(Class<T> type) {
+    return getConfiguration().getMapper(type, this);
+}
+
+@Override
+public Connection getConnection() {
+    final SqlSession sqlSession = localSqlSession.get();
+    if (sqlSession == null) {
+        throw new SqlSessionException("Error:  Cannot get connection.  No managed session is started.");
+    }
+    return sqlSession.getConnection();
+}
+
+@Override
+public void clearCache() {
+    final SqlSession sqlSession = localSqlSession.get();
+    if (sqlSession == null) {
+        throw new SqlSessionException("Error:  Cannot clear the cache.  No managed session is started.");
+    }
+    sqlSession.clearCache();
+}
+
+@Override
+public void commit() {
+    final SqlSession sqlSession = localSqlSession.get();
+    if (sqlSession == null) {
+        throw new SqlSessionException("Error:  Cannot commit.  No managed session is started.");
+    }
+    sqlSession.commit();
+}
+
+@Override
+public void commit(boolean force) {
+    final SqlSession sqlSession = localSqlSession.get();
+    if (sqlSession == null) {
+        throw new SqlSessionException("Error:  Cannot commit.  No managed session is started.");
+    }
+    sqlSession.commit(force);
+}
+
+@Override
+public void rollback() {
+    final SqlSession sqlSession = localSqlSession.get();
+    if (sqlSession == null) {
+        throw new SqlSessionException("Error:  Cannot rollback.  No managed session is started.");
+    }
+    sqlSession.rollback();
+}
+
+@Override
+public void rollback(boolean force) {
+    final SqlSession sqlSession = localSqlSession.get();
+    if (sqlSession == null) {
+        throw new SqlSessionException("Error:  Cannot rollback.  No managed session is started.");
+    }
+    sqlSession.rollback(force);
+}
+
+@Override
+public List<BatchResult> flushStatements() {
+    final SqlSession sqlSession = localSqlSession.get();
+    if (sqlSession == null) {
+        throw new SqlSessionException("Error:  Cannot rollback.  No managed session is started.");
+    }
+    return sqlSession.flushStatements();
+}
+
+@Override
+public void close() {
+    final SqlSession sqlSession = localSqlSession.get();
+    if (sqlSession == null) {
+        throw new SqlSessionException("Error:  Cannot close.  No managed session is started.");
+    }
+    try {
+        sqlSession.close();
+    } finally {
+        localSqlSession.set(null);
+    }
+}
+```
+
+- 调用 `localSqlSession` 中的 SqlSession 对象，对应的方法。
+
+## 5.6 SqlSessionInterceptor
+
+SqlSessionInterceptor ，是 SqlSessionManager 内部类，实现 InvocationHandler 接口，实现对 `sqlSessionProxy` 的调用的拦截。代码如下：
+
+```
+// SqlSessionManager.java
+
+private class SqlSessionInterceptor implements InvocationHandler {
+
+    public SqlSessionInterceptor() {
+        // Prevent Synthetic Access
+    }
+
+    @Override
+    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
+        // 情况一，如果 localSqlSession 中存在 SqlSession 对象，说明是自管理模式
+        final SqlSession sqlSession = SqlSessionManager.this.localSqlSession.get();
+        if (sqlSession != null) {
+            try {
+                // 直接执行方法
+                return method.invoke(sqlSession, args);
+            } catch (Throwable t) {
+                throw ExceptionUtil.unwrapThrowable(t);
+            }
+        // 情况二，如果没有 SqlSession 对象，则直接创建一个
+        } else {
+            // 创建新的 SqlSession 对象
+            try (SqlSession autoSqlSession = openSession()) { // 同时，通过 try 的语法糖，实现结束时，关闭 SqlSession 对象
+                try {
+                    // 执行方法
+                    final Object result = method.invoke(autoSqlSession, args);
+                    // 提交 SqlSession 对象
+                    autoSqlSession.commit();
+                    return result;
+                } catch (Throwable t) {
+                    // 发生异常时，回滚
+                    autoSqlSession.rollback();
+                    throw ExceptionUtil.unwrapThrowable(t);
+                }
+            }
+        }
+    }
+
+}
+```
+
+- 分成两种情况，胖友直接看代码注释。hoho 。
+
+## 5.7 嘿嘿嘿
+
+貌似，SqlSessionManager 在实际项目中木有什么用。这里，胖友就是去理解，以及动态代理的使用。
+
+# 6. Configuration
+
+`org.apache.ibatis.session.Configuration` ，MyBatis 配置对象。在前面已经不断在介绍了，这里就不重复了。
+
+# 7. MapperMethod
+
+在前面的文章中，我们很**分块**的介绍了 MyBatis 的各个组件，那么一条 SQL 命令的完整流程是怎么样的呢？如下图所示：
+
+> FROM 祖大俊 [《Mybatis3.3.x技术内幕（十一）：执行一个Sql命令的完整流程》](https://my.oschina.net/zudajun/blog/670373)
+>
+> [![流程图](26-mybatis-会话 SqlSession.assets/02.png)](http://static.iocoder.cn/images/MyBatis/2020_03_15/02.png)流程图
+
+那么从这个图中可以看出，MapperMethod 在里面扮演了非常重要的角色，将方法转换成对应的 SqlSession 方法，并返回执行结果。实际上，在 [《精尽 MyBatis 源码分析 —— Binding 模块》](http://svip.iocoder.cn/MyBatis/binding-package) 中，我们已经介绍了 MapperMethod 类，但是因为 `#execute(SqlSession sqlSession, Object[] args)` 方法，涉及内容较多，所以没有详细解析。那么此处，让我们撸起这个方法。代码如下：
+
+```
+// MapperMethod.java
+
+public Object execute(SqlSession sqlSession, Object[] args) {
+    Object result;
+    switch (command.getType()) {
+        case INSERT: {
+            // 转换参数
+            Object param = method.convertArgsToSqlCommandParam(args);
+            // 执行 INSERT 操作
+            // 转换 rowCount
+            result = rowCountResult(sqlSession.insert(command.getName(), param));
+            break;
+        }
+        case UPDATE: {
+            // <1.1> 转换参数
+            Object param = method.convertArgsToSqlCommandParam(args);
+            // <1.2> 执行更新
+            // <1.3> 转换 rowCount
+            result = rowCountResult(sqlSession.update(command.getName(), param));
+            break;
+        }
+        case DELETE: {
+            // 转换参数
+            Object param = method.convertArgsToSqlCommandParam(args);
+            // 转换 rowCount
+            result = rowCountResult(sqlSession.delete(command.getName(), param));
+            break;
+        }
+        case SELECT:
+            // <2.1> 无返回，并且有 ResultHandler 方法参数，则将查询的结果，提交给 ResultHandler 进行处理
+            if (method.returnsVoid() && method.hasResultHandler()) {
+                executeWithResultHandler(sqlSession, args);
+                result = null;
+            // <2.2> 执行查询，返回列表
+            } else if (method.returnsMany()) {
+                result = executeForMany(sqlSession, args);
+            // <2.3> 执行查询，返回 Map
+            } else if (method.returnsMap()) {
+                result = executeForMap(sqlSession, args);
+            // <2.4> 执行查询，返回 Cursor
+            } else if (method.returnsCursor()) {
+                result = executeForCursor(sqlSession, args);
+            // <2.5> 执行查询，返回单个对象
+            } else {
+                // 转换参数
+                Object param = method.convertArgsToSqlCommandParam(args);
+                // 查询单条
+                result = sqlSession.selectOne(command.getName(), param);
+                if (method.returnsOptional() &&
+                        (result == null || !method.getReturnType().equals(result.getClass()))) {
+                    result = Optional.ofNullable(result);
+                }
+            }
+            break;
+        case FLUSH:
+            result = sqlSession.flushStatements();
+            break;
+        default:
+            throw new BindingException("Unknown execution method for: " + command.getName());
+    }
+    // 返回结果为 null ，并且返回类型为基本类型，则抛出 BindingException 异常
+    if (result == null && method.getReturnType().isPrimitive() && !method.returnsVoid()) {
+        throw new BindingException("Mapper method '" + command.getName()
+                + " attempted to return null from a method with a primitive return type (" + method.getReturnType() + ").");
+    }
+    // 返回结果
+    return result;
+}
+```
+
+- `INSERT` 命令类型
+
+  - `<1.1>` 处，调用 `MethodSignature#convertArgsToSqlCommandParam(args)` 方法，转换参数。
+
+  - `<1.2>` 处，调用 `SqlSession#insert(String statement, Object parameter)` 方法，执行 INSERT 操作。
+
+  - `<1.3>` 处，调用 `#rowCountResult(int rowCount)` 方法，将返回的行变更数，转换成方法实际要返回的类型。代码如下：
+
+    ```
+    // MapperMethod.java
+    
+    private Object rowCountResult(int rowCount) {
+        final Object result;
+        if (method.returnsVoid()) { // Void 情况，不用返回
+            result = null;
+        } else if (Integer.class.equals(method.getReturnType()) || Integer.TYPE.equals(method.getReturnType())) { // Int
+            result = rowCount;
+        } else if (Long.class.equals(method.getReturnType()) || Long.TYPE.equals(method.getReturnType())) { // Long
+            result = (long) rowCount;
+        } else if (Boolean.class.equals(method.getReturnType()) || Boolean.TYPE.equals(method.getReturnType())) { // Boolean
+            result = rowCount > 0;
+        } else {
+            throw new BindingException("Mapper method '" + command.getName() + "' has an unsupported return type: " + method.getReturnType());
+        }
+        return result;
+    }
+    ```
+
+    - 根据方法的返回类型，做相应的转化处理。
+
+- `UPDATE` 命令类型，同 `INSERT` 命令类型。
+
+- `DELETE` 命令类型，同 `INSERT` 命令类型。
+
+- ```
+  SELECT
+  ```
+
+   
+
+  命令类型
+
+  - `<2.1>` 处，无返回，并且有 ResultHandler 方法参数，则调用 `#executeWithResultHandler(SqlSession sqlSession, Object[] args)` 方法，将查询的结果，提交给 ResultHandler 进行处理。详细解析，见 [「7.1 executeWithResultHandler」](https://svip.iocoder.cn/MyBatis/session/#) 。
+  - `<2.2>` 处，调用 `#executeForMany(SqlSession sqlSession, Object[] args)` 方法，执行查询，返回列表。详细解析，见 [「7.2 executeForMany」](https://svip.iocoder.cn/MyBatis/session/#) 。
+  - `<2.3>` 处，调用 `#executeForMap(SqlSession sqlSession, Object[] args)` 方法，执行查询，返回 Map。详细解析，见 [「7.3 executeForMap」](https://svip.iocoder.cn/MyBatis/session/#) 。
+  - `<2.4>` 处，调用 `#executeForCursor(SqlSession sqlSession, Object[] args)` 方法，执行查询，返回 Map。详细解析，见 [「7.4 executeForCursor」](https://svip.iocoder.cn/MyBatis/session/#) 。
+  - `<2.5>` 处，执行查询，返回单个对象。此处是，对 SqlSession 的 [「4.1.3 selectOne」](https://svip.iocoder.cn/MyBatis/session/#) 方法的封装。
+
+## 7.1 executeWithResultHandler
+
+```
+// MapperMethod.java
+
+private void executeWithResultHandler(SqlSession sqlSession, Object[] args) {
+    // 获得 MappedStatement 对象
+    MappedStatement ms = sqlSession.getConfiguration().getMappedStatement(command.getName());
+    if (!StatementType.CALLABLE.equals(ms.getStatementType()) // 校验存储过程的情况。不符合，抛出 BindingException 异常
+            && void.class.equals(ms.getResultMaps().get(0).getType())) {
+        throw new BindingException("method " + command.getName()
+                + " needs either a @ResultMap annotation, a @ResultType annotation,"
+                + " or a resultType attribute in XML so a ResultHandler can be used as a parameter.");
+    }
+    // 转换参数
+    Object param = method.convertArgsToSqlCommandParam(args);
+    // 执行 SELECT 操作
+    if (method.hasRowBounds()) {
+        RowBounds rowBounds = method.extractRowBounds(args);
+        sqlSession.select(command.getName(), param, rowBounds, method.extractResultHandler(args));
+    } else {
+        sqlSession.select(command.getName(), param, method.extractResultHandler(args));
+    }
+}
+```
+
+- 对 SqlSession 的 [「4.1.6 select」](https://svip.iocoder.cn/MyBatis/session/#) 方法的封装。
+
+## 7.2 executeForMany
+
+```
+// MapperMethod.java
+
+private <E> Object executeForMany(SqlSession sqlSession, Object[] args) {
+    List<E> result;
+    // 转换参数
+    Object param = method.convertArgsToSqlCommandParam(args);
+    // 执行 SELECT 操作
+    if (method.hasRowBounds()) {
+        RowBounds rowBounds = method.extractRowBounds(args);
+        result = sqlSession.selectList(command.getName(), param, rowBounds);
+    } else {
+        result = sqlSession.selectList(command.getName(), param);
+    }
+    // issue #510 Collections & arrays support
+    // 封装 Array 或 Collection 结果
+    if (!method.getReturnType().isAssignableFrom(result.getClass())) {
+        if (method.getReturnType().isArray()) { // 情况一，Array
+            return convertToArray(result);
+        } else {
+            return convertToDeclaredCollection(sqlSession.getConfiguration(), result); // 情况二，Collection
+        }
+    }
+    // 直接返回的结果
+    return result; // 情况三，默认
+}
+```
+
+- 对 SqlSession 的 [「4.1.2 selectList」](https://svip.iocoder.cn/MyBatis/session/#) 方法的封装。
+
+- 情况一，Array 。代码如下：
+
+  ```
+  // MapperMethod.java
+  
+  private <E> Object convertToArray(List<E> list) {
+      Class<?> arrayComponentType = method.getReturnType().getComponentType();
+      Object array = Array.newInstance(arrayComponentType, list.size());
+      if (arrayComponentType.isPrimitive()) {
+          for (int i = 0; i < list.size(); i++) {
+              Array.set(array, i, list.get(i));
+          }
+          return array;
+      } else {
+          return list.toArray((E[]) array);
+      }
+  }
+  ```
+
+- 情况二，Collection 。代码如下：
+
+  ```
+  // MapperMethod.java
+  
+  private <E> Object convertToDeclaredCollection(Configuration config, List<E> list) {
+      Object collection = config.getObjectFactory().create(method.getReturnType());
+      MetaObject metaObject = config.newMetaObject(collection);
+      metaObject.addAll(list);
+      return collection;
+  }
+  ```
+
+## 7.3 executeForMap
+
+```
+// MapperMethod.java
+
+private <K, V> Map<K, V> executeForMap(SqlSession sqlSession, Object[] args) {
+    Map<K, V> result;
+    // 转换参数
+    Object param = method.convertArgsToSqlCommandParam(args);
+    // 执行 SELECT 操作
+    if (method.hasRowBounds()) {
+        RowBounds rowBounds = method.extractRowBounds(args);
+        result = sqlSession.<K, V>selectMap(command.getName(), param, method.getMapKey(), rowBounds);
+    } else {
+        result = sqlSession.<K, V>selectMap(command.getName(), param, method.getMapKey());
+    }
+    return result;
+}
+```
+
+- 对 SqlSession 的 [「4.1.4 selectMap」](https://svip.iocoder.cn/MyBatis/session/#) 方法的封装。
+
+## 7.4 executeForCursor
+
+```
+// MapperMethod.java
+
+private <T> Cursor<T> executeForCursor(SqlSession sqlSession, Object[] args) {
+    Cursor<T> result;
+    // 转换参数
+    Object param = method.convertArgsToSqlCommandParam(args);
+    // 执行 SELECT 操作
+    if (method.hasRowBounds()) {
+        RowBounds rowBounds = method.extractRowBounds(args);
+        result = sqlSession.selectCursor(command.getName(), param, rowBounds);
+    } else {
+        result = sqlSession.selectCursor(command.getName(), param);
+    }
+    return result;
+}
+```
+
+# 666. 彩蛋
+
+貌似，又是一片简单的文章。淡定~~
+
+参考和推荐如下文章：
+
+- 祖大俊 [《Mybatis3.3.x技术内幕（一）：SqlSession和SqlSessionFactory列传》](https://my.oschina.net/zudajun/blog/665956)
+- 祖大俊 [《Mybatis3.3.x技术内幕（十一）：执行一个Sql命令的完整流程》](https://my.oschina.net/zudajun/blog/670373)
+- 田小波 [《MyBatis 源码分析 - SQL 的执行过程》](https://www.tianxiaobo.com/2018/08/17/MyBatis-源码分析-SQL-的执行过程/)
+- 无忌 [《MyBatis 源码解读之 SqlSession》](https://my.oschina.net/wenjinglian/blog/1631901)
+- 徐郡明 [《MyBatis 技术内幕》](https://item.jd.com/12125531.html) 的 [「3.7 接口层」](https://svip.iocoder.cn/MyBatis/session/#) 小节
\ No newline at end of file
diff --git a/mybatis/27-mybatis-插件体系（一）之原理.assets/01.png b/mybatis/27-mybatis-插件体系（一）之原理.assets/01.png
new file mode 100644
index 0000000..f19caaf
Binary files /dev/null and b/mybatis/27-mybatis-插件体系（一）之原理.assets/01.png differ
diff --git a/mybatis/27-mybatis-插件体系（一）之原理.assets/02.png b/mybatis/27-mybatis-插件体系（一）之原理.assets/02.png
new file mode 100644
index 0000000..d8bc4c4
Binary files /dev/null and b/mybatis/27-mybatis-插件体系（一）之原理.assets/02.png differ
diff --git a/mybatis/27-mybatis-插件体系（一）之原理.assets/03.png b/mybatis/27-mybatis-插件体系（一）之原理.assets/03.png
new file mode 100644
index 0000000..7b128fd
Binary files /dev/null and b/mybatis/27-mybatis-插件体系（一）之原理.assets/03.png differ
diff --git a/mybatis/27-mybatis-插件体系（一）之原理.md b/mybatis/27-mybatis-插件体系（一）之原理.md
new file mode 100644
index 0000000..e7ee67e
--- /dev/null
+++ b/mybatis/27-mybatis-插件体系（一）之原理.md
@@ -0,0 +1,421 @@
+# 精尽 MyBatis 源码分析 —— 插件体系（一）之原理
+
+# 1. 概述
+
+本文，我们来分享 MyBatis 的插件模块，对应 `plugin` 包。如下图所示：[![`scripting` 包](27-mybatis-插件体系（一）之原理.assets/01.png)](http://static.iocoder.cn/images/MyBatis/2020_03_18/01.png)`scripting` 包
+
+在 [《精尽 MyBatis 源码解析 —— 项目结构一览》](http://svip.iocoder.cn/MyBatis/intro) 中，简单介绍了这个模块如下：
+
+> Mybatis 自身的功能虽然强大，但是并不能完美切合所有的应用场景，因此 MyBatis 提供了插件接口，我们可以通过添加用户自定义插件的方式对 MyBatis 进行扩展。用户自定义插件也可以改变 Mybatis 的默认行为，例如，我们可以拦截 SQL 语句并对其进行重写。
+>
+> 由于用户自定义插件会影响 MyBatis 的核心行为，在使用自定义插件之前，开发人员需要了解 MyBatis 内部的原理，这样才能编写出安全、高效的插件。
+
+- 总的来说，MyBatis 的插件，还是基于**动态代理**来实现。所以，😈 胖友有没发现，动态代理，无处不在。嘿嘿。
+- 另外，胖友先看看 [《MyBatis 官方文档 —— 插件》](http://www.mybatis.org/mybatis-3/zh/configuration.html#plugins) 文档，对 MyBatis 插件的概念和配置，再有一个了解。
+
+本文涉及的类如下图所示：[![类图](27-mybatis-插件体系（一）之原理.assets/02.png)](http://static.iocoder.cn/images/MyBatis/2020_03_18/02.png)类图
+
+下面，我们逐个类来瞅瞅。
+
+# 2. Interceptor
+
+`org.apache.ibatis.plugin.Interceptor` ，拦截器接口。代码如下：
+
+```
+// Interceptor.java
+
+public interface Interceptor {
+
+    /**
+     * 拦截方法
+     *
+     * @param invocation 调用信息
+     * @return 调用结果
+     * @throws Throwable 若发生异常
+     */
+    Object intercept(Invocation invocation) throws Throwable;
+
+    /**
+     * 应用插件。如应用成功，则会创建目标对象的代理对象
+     *
+     * @param target 目标对象
+     * @return 应用的结果对象，可以是代理对象，也可以是 target 对象，也可以是任意对象。具体的，看代码实现
+     */
+    Object plugin(Object target);
+
+    /**
+     * 设置拦截器属性
+     *
+     * @param properties 属性
+     */
+    void setProperties(Properties properties);
+
+}
+```
+
+- 关于三个方法，胖友看看代码注释。
+
+## 2.1 示例
+
+我们来看看 `org.apache.ibatis.plugin.PluginTest` ，提供了 AlwaysMapPlugin 示例。代码如下：
+
+```
+@Intercepts({
+        @Signature(type = Map.class, method = "get", args = {Object.class})}) // <1>
+public static class AlwaysMapPlugin implements Interceptor {
+
+    @Override // <4>
+    public Object intercept(Invocation invocation) throws Throwable {
+        return "Always";
+    }
+
+    @Override // <2>
+    public Object plugin(Object target) {
+        return Plugin.wrap(target, this);
+    }
+
+    @Override // <3>
+    public void setProperties(Properties properties) {
+    }
+
+}
+```
+
+- `<1>` 处，通过 `@Intercepts` 和 `@Signature` 注解，定义了需要拦截的方法为 Map 类型、方法为 `"get"` 方法，方法参数为 `Object.class` 。详细解析，见 TODO。
+- `<2>` 处，在实现方法 `#plugin(Object target)` 方法内部，他调用 `Plugin#wrap(Object target, Interceptor interceptor)` 方法，执行代理对象的创建。详细解析，见 TODO。
+- `<3>` 处，在实现方法 `#setProperties(Properties properties)` 方法内部，暂未做任何实现。此处可以实现，若 AlwaysMapPlugin 有属性，可以从 `properties` 获取一些需要的属性值。
+- `<4>` 处，在实现方法 `#intercept(Invocation invocation)` 方法，直接返回 `"Always"` 字符串。也就是说，当所有的 `target` 类型为 Map 类型，并且调用 `Map#get(Object)` 方法时，返回的都是 `"Always"` 。
+
+这个示例，胖友可以跑下 PluginTest 单元测试里的方法，可以更加好理解。
+
+## 2.2 Invocation
+
+`org.apache.ibatis.plugin.Invocation` ，方法调用信息，作为 `Interceptor#intercept(Invocation invocation)` 的方法参数。代码如下：
+
+```
+// Invocation.java
+
+public interface Interceptor {
+
+    /**
+     * 拦截方法
+     *
+     * @param invocation 调用信息
+     * @return 调用结果
+     * @throws Throwable 若发生异常
+     */
+    Object intercept(Invocation invocation) throws Throwable;
+
+    /**
+     * 应用插件。如应用成功，则会创建目标对象的代理对象
+     *
+     * @param target 目标对象
+     * @return 应用的结果对象，可以是代理对象，也可以是 target 对象，也可以是任意对象。具体的，看代码实现
+     */
+    Object plugin(Object target);
+
+    /**
+     * 设置拦截器属性
+     *
+     * @param properties 属性
+     */
+    void setProperties(Properties properties);
+
+}
+```
+
+# 3. InterceptorChain
+
+`org.apache.ibatis.plugin.InterceptorChain` ，拦截器 Interceptor 链。
+
+## 3.1 构造方法
+
+```
+// InterceptorChain.java
+
+/**
+ * 拦截器数组
+ */
+private final List<Interceptor> interceptors = new ArrayList<>();
+```
+
+## 3.2 addInterceptor
+
+`#addInterceptor(Interceptor interceptor)` 方法，添加拦截器。代码如下：
+
+```
+// InterceptorChain.java
+
+public void addInterceptor(Interceptor interceptor) {
+    interceptors.add(interceptor);
+}
+```
+
+------
+
+该方法在 Configuration 的 `#pluginElement(XNode parent)` 方法中被调用，代码如下：
+
+```
+// XMLConfigBuilder.java
+
+/**
+ * 解析 <plugins /> 标签，添加到 {@link Configuration#interceptorChain} 中
+ *
+ * @param parent 节点
+ * @throws Exception 发生异常时
+ */
+private void pluginElement(XNode parent) throws Exception {
+    if (parent != null) {
+        // 遍历 <plugins /> 标签
+        for (XNode child : parent.getChildren()) {
+            String interceptor = child.getStringAttribute("interceptor");
+            Properties properties = child.getChildrenAsProperties();
+            // <1> 创建 Interceptor 对象，并设置属性
+            Interceptor interceptorInstance = (Interceptor) resolveClass(interceptor).newInstance();
+            interceptorInstance.setProperties(properties);
+            // 添加到 configuration 中
+            configuration.addInterceptor(interceptorInstance);
+        }
+    }
+}
+```
+
+- `<1>` 处，创建 Interceptor 对象，并调用 `Interceptor#setProperties(properties)` 方法，设置拦截器的属性。
+
+- `<2>` 处，调用 `Configuration#addInterceptor(interceptorInstance)` 方法，添加到 `Configuration.interceptorChain` 中。代码如下：
+
+  ```
+  // Configuration.java
+  
+  /**
+   * 拦截器链
+   */
+  protected final InterceptorChain interceptorChain = new InterceptorChain();
+  
+  public void addInterceptor(Interceptor interceptor) {
+      interceptorChain.addInterceptor(interceptor);
+  }
+  ```
+
+## 3.3 pluginAll
+
+`#pluginAll(Object target)` 方法，应用所有拦截器到指定目标对象。代码如下：
+
+```
+// InterceptorChain.java
+
+public Object pluginAll(Object target) {
+    for (Interceptor interceptor : interceptors) {
+        target = interceptor.plugin(target);
+    }
+    return target;
+}
+```
+
+------
+
+该方法被 Configuration 的如下四处方法中调用：[![调用处](27-mybatis-插件体系（一）之原理.assets/03.png)](http://static.iocoder.cn/images/MyBatis/2020_03_18/03.png)调用处
+
+- 一共可以有四种目标对象类型可以被拦截：1）Executor；2）StatementHandler；3）ParameterHandler；4）ResultSetHandler 。
+
+# 4. @Intercepts
+
+`org.apache.ibatis.plugin.@Intercepts` ，拦截器注解。代码如下：
+
+```
+// Intercepts.java
+
+@Documented
+@Retention(RetentionPolicy.RUNTIME)
+@Target(ElementType.TYPE)
+public @interface Intercepts {
+
+    /**
+     * @return 拦截的方法签名的数组
+     */
+    Signature[] value();
+
+}
+```
+
+## 4.1 @Signature
+
+`org.apache.ibatis.plugin.@Signature` ，方法签名的注解。代码如下：
+
+```
+// Signature.java
+
+@Documented
+@Retention(RetentionPolicy.RUNTIME)
+@Target({})
+public @interface Signature {
+
+    /**
+     * @return 类
+     */
+    Class<?> type();
+
+    /**
+     * @return 方法名
+     */
+    String method();
+
+    /**
+     * @return 参数类型
+     */
+    Class<?>[] args();
+
+}
+```
+
+# 5. Plugin
+
+`org.apache.ibatis.plugin.Plugin` ，实现 InvocationHandler 接口，插件类，一方面提供创建动态代理对象的方法，另一方面实现对指定类的指定方法的拦截处理。
+
+注意，Plugin 是 MyBatis 插件体系的核心类。
+
+## 5.1 构造方法
+
+```
+// Plugin.java
+
+/**
+ * 目标对象
+ */
+private final Object target;
+/**
+ * 拦截器
+ */
+private final Interceptor interceptor;
+/**
+ * 拦截的方法映射
+ *
+ * KEY：类
+ * VALUE：方法集合
+ */
+private final Map<Class<?>, Set<Method>> signatureMap;
+
+private Plugin(Object target, Interceptor interceptor, Map<Class<?>, Set<Method>> signatureMap) {
+    this.target = target;
+    this.interceptor = interceptor;
+    this.signatureMap = signatureMap;
+}
+```
+
+## 5.2 wrap
+
+`#wrap(Object target, Interceptor interceptor)` **静态**方法，创建目标类的代理对象。代码如下：
+
+```
+// Plugin.java
+
+public static Object wrap(Object target, Interceptor interceptor) {
+    // <1> 获得拦截的方法映射
+    Map<Class<?>, Set<Method>> signatureMap = getSignatureMap(interceptor);
+    // <2> 获得目标类的类型
+    Class<?> type = target.getClass();
+    // <2> 获得目标类的接口集合
+    Class<?>[] interfaces = getAllInterfaces(type, signatureMap);
+    // <3.1> 若有接口，则创建目标对象的 JDK Proxy 对象
+    if (interfaces.length > 0) {
+        return Proxy.newProxyInstance(
+                type.getClassLoader(),
+                interfaces,
+                new Plugin(target, interceptor, signatureMap)); // 因为 Plugin 实现了 InvocationHandler 接口，所以可以作为 JDK 动态代理的调用处理器
+    }
+    // <3.2> 如果没有，则返回原始的目标对象
+    return target;
+}
+```
+
+- `<1>` 处，调用 `#getSignatureMap(Interceptor interceptor)` 方法，获得拦截的方法映射。代码如下：
+
+  ```
+  // Plugin.java
+  
+  private static Map<Class<?>, Set<Method>> getSignatureMap(Interceptor interceptor) {
+      Intercepts interceptsAnnotation = interceptor.getClass().getAnnotation(Intercepts.class);
+      // issue #251
+      if (interceptsAnnotation == null) {
+          throw new PluginException("No @Intercepts annotation was found in interceptor " + interceptor.getClass().getName());
+      }
+      Signature[] sigs = interceptsAnnotation.value();
+      Map<Class<?>, Set<Method>> signatureMap = new HashMap<>();
+      for (Signature sig : sigs) {
+          Set<Method> methods = signatureMap.computeIfAbsent(sig.type(), k -> new HashSet<>());
+          try {
+              Method method = sig.type().getMethod(sig.method(), sig.args());
+              methods.add(method);
+          } catch (NoSuchMethodException e) {
+              throw new PluginException("Could not find method on " + sig.type() + " named " + sig.method() + ". Cause: " + e, e);
+          }
+      }
+      return signatureMap;
+  }
+  ```
+
+  - 基于 `@Intercepts` 和 `@Signature` 注解。
+
+- `<2>` 处，调用 `#getAllInterfaces(Class<?> type, Map<Class<?>, Set<Method>> signatureMap)` 方法，获得目标类的接口集合。代码如下：
+
+  ```
+  // Plugin.java
+  
+  private static Class<?>[] getAllInterfaces(Class<?> type, Map<Class<?>, Set<Method>> signatureMap) {
+      // 接口的集合
+      Set<Class<?>> interfaces = new HashSet<>();
+      // 循环递归 type 类，机器父类
+      while (type != null) {
+          // 遍历接口集合，若在 signatureMap 中，则添加到 interfaces 中
+          for (Class<?> c : type.getInterfaces()) {
+              if (signatureMap.containsKey(c)) {
+                  interfaces.add(c);
+              }
+          }
+          // 获得父类
+          type = type.getSuperclass();
+      }
+      // 创建接口的数组
+      return interfaces.toArray(new Class<?>[interfaces.size()]);
+  }
+  ```
+
+  - 从这里可以看出，`@Signature` 注解的 `type` 属性，必须是**接口**。
+
+- `<3.1>` 处，**情况一**，若有接口，则创建目标对象的 JDK Proxy 对象。
+
+- `<3.2>` 处，**情况二**，若无接口，则返回原始的目标对象。
+
+## 5.3 invoke
+
+```
+// Plugin.java
+
+@Override
+public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
+    try {
+        // 获得目标方法是否被拦截
+        Set<Method> methods = signatureMap.get(method.getDeclaringClass());
+        if (methods != null && methods.contains(method)) {
+            // 如果是，则拦截处理该方法
+            return interceptor.intercept(new Invocation(target, method, args));
+        }
+        // 如果不是，则调用原方法
+        return method.invoke(target, args);
+    } catch (Exception e) {
+        throw ExceptionUtil.unwrapThrowable(e);
+    }
+}
+```
+
+- 具体，见代码注释。简单~
+
+# 666. 彩蛋
+
+在地铁上，撸完了这篇博客，小文一篇。后续，我们会找一些 MyBatis 的插件，详细解析。另外，MyBatis 并未提供自带的插件实现。
+
+参考和推荐如下文章：
+
+- 祖大俊 [《Mybatis3.4.x技术内幕（十九）：Mybatis之plugin插件设计原理》](https://my.oschina.net/zudajun/blog/738973)
+- 田小波 [《MyBatis 源码分析 - 插件机制》](https://www.tianxiaobo.com/2018/08/26/MyBatis-源码分析-插件机制/)
+- 徐郡明 [《MyBatis 技术内幕》](https://item.jd.com/12125531.html) 的 [「4.1 插件模块」](https://svip.iocoder.cn/MyBatis/plugin-1/#) 小节
\ No newline at end of file
diff --git a/mybatis/28-mybatis-插件体系（二）之 PageHelper.md b/mybatis/28-mybatis-插件体系（二）之 PageHelper.md
new file mode 100644
index 0000000..92943f4
--- /dev/null
+++ b/mybatis/28-mybatis-插件体系（二）之 PageHelper.md	
@@ -0,0 +1,18 @@
+# 精尽 MyBatis 源码分析 —— 插件体系（二）之 PageHelper
+
+[Mybatis-PageHelper](https://github.com/pagehelper/Mybatis-PageHelper) ，基于 MyBatis 插件体系，实现了**分页**功能。感兴趣的胖友，可以看看它的源码。艿艿暂时不是特别感兴趣，因为：
+
+1. 团队目前主要以手写 SQL 为主，或者自动生成 SQL 为辅。
+2. [MyBatis-Plus](https://github.com/baomidou/mybatis-plus) 也提供了分页插件，并且据艿艿了解到，可能更加广泛。它的分页插件的拦截器是 `com.baomidou.mybatisplus.plugins.PaginationInterceptor` ，具体可参见文档 [《MyBatis-Plus 文档 —— 分页插件》](http://mp.baomidou.com/guide/page.html) 。
+
+当然，考虑到胖友可能比较感兴趣，艿艿还是翻了翻目前网络上的文章，目前写的比较好的是：
+
+- 祖大俊
+
+   
+
+  《Mybatis3.4.x技术内幕（二十）：PageHelper分页插件源码及原理剖析》
+
+  - 因为写的比较早，所以对应的 [Mybatis-PageHelper](https://github.com/pagehelper/Mybatis-PageHelper) 的代码比较早，所以和目前的代码，已经对应不上了。
+
+- 【**相对推荐**】一直不懂 [《【Mybatis源码分析】12-插件PageHelper机制》](https://blog.csdn.net/shenchaohao12321/article/details/80168655)
\ No newline at end of file
diff --git a/mybatis/29-mybatis-Spring 集成（一）之调试环境搭建.assets/01.png b/mybatis/29-mybatis-Spring 集成（一）之调试环境搭建.assets/01.png
new file mode 100644
index 0000000..a860989
Binary files /dev/null and b/mybatis/29-mybatis-Spring 集成（一）之调试环境搭建.assets/01.png differ
diff --git a/mybatis/29-mybatis-Spring 集成（一）之调试环境搭建.assets/02.png b/mybatis/29-mybatis-Spring 集成（一）之调试环境搭建.assets/02.png
new file mode 100644
index 0000000..24ae02d
Binary files /dev/null and b/mybatis/29-mybatis-Spring 集成（一）之调试环境搭建.assets/02.png differ
diff --git a/mybatis/29-mybatis-Spring 集成（一）之调试环境搭建.md b/mybatis/29-mybatis-Spring 集成（一）之调试环境搭建.md
new file mode 100644
index 0000000..172986b
--- /dev/null
+++ b/mybatis/29-mybatis-Spring 集成（一）之调试环境搭建.md	
@@ -0,0 +1,70 @@
+# 精尽 MyBatis 源码解析 —— Spring 集成（一）之调试环境搭建
+
+# 1. 依赖工具
+
+- Maven
+- Git
+- JDK
+- IntelliJ IDEA
+
+# 2. 源码拉取
+
+从官方仓库 https://github.com/mybatis/spring `Fork` 出属于自己的仓库。为什么要 `Fork` ？既然开始阅读、调试源码，我们可能会写一些注释，有了自己的仓库，可以进行自由的提交。😈
+
+使用 `IntelliJ IDEA` 从 `Fork` 出来的仓库拉取代码。
+
+本文使用的 MyBatis 版本为 `2.0.0-SNAPSHOT` 。统计代码量如下：[![代码统计](29-mybatis-Spring 集成（一）之调试环境搭建.assets/01.png)](http://static.iocoder.cn/images/MyBatis/2020_06_01/01.png)代码统计
+
+# 3. 调试
+
+MyBatis 想要调试，非常方便，只需要打开 `org.mybatis.spring.sample.AbstractSampleTest` 单元测试类，选择 `#testFooService()` 方法，右键，开始调试即可。
+
+```
+@DirtiesContext
+public abstract class AbstractSampleTest {
+
+    @Autowired
+    protected FooService fooService;
+
+    @Test
+    final void testFooService() {
+        User user = this.fooService.doSomeBusinessStuff("u1");
+        assertThat(user).isNotNull();
+        assertThat(user.getName()).isEqualTo("Pocoyo");
+    }
+
+}
+```
+
+有两点要注意：
+
+1、因为单元测试基于 Junit5 ，所以需要依赖 JDK10 的环境，因此需要修改项目的 Project SDK 为 JDK10 。如下图所示：[![修改 Project SDK](29-mybatis-Spring 集成（一）之调试环境搭建.assets/02.png)](http://static.iocoder.cn/images/MyBatis/2020_06_01/02.png)修改 Project SDK
+
+2、AbstractSampleTest 是示例单元测试**基类**，它有五种实现类，分别如下：
+
+```
+/**
+ * 示例单元测试基类
+ *
+ * 1. {@link SampleEnableTest}
+ *      基于 @MapperScan 注解，扫描指定包
+ *
+ * 2. {@link SampleMapperTest}
+ *      基于 {@link org.mybatis.spring.mapper.MapperFactoryBean} 类，直接声明指定的 Mapper 接口
+ *
+ * 3. {@link SampleNamespaceTest}
+ *      基于 <mybatis:scan /> 标签，扫描指定包
+ *
+ * 4. {@link SampleScannerTest}
+ *      基于 {@link org.mybatis.spring.mapper.MapperScannerConfigurer} 类，扫描指定包
+ *
+ * 5. {@link SampleBatchTest}
+ *      在 SampleMapperTest 的基础上，使用 BatchExecutor 执行器
+ */
+```
+
+- 每种实现类，都对应其配置类或配置文件。胖友可以根据自己需要，运行 AbstractSampleTest 时，选择对应的实现类。
+
+# 666. 彩蛋
+
+小撸怡情，大撸伤身。
\ No newline at end of file
diff --git a/mybatis/30-mybatis-Spring 集成（二）之初始化.assets/mybatis-spring-17182468635001.xsd b/mybatis/30-mybatis-Spring 集成（二）之初始化.assets/mybatis-spring-17182468635001.xsd
new file mode 100644
index 0000000..a94b8a5
--- /dev/null
+++ b/mybatis/30-mybatis-Spring 集成（二）之初始化.assets/mybatis-spring-17182468635001.xsd	
@@ -0,0 +1,1178 @@
+
+
+
+
+
+
+<!DOCTYPE html>
+<html
+  lang="en"
+  
+  data-color-mode="auto" data-light-theme="light" data-dark-theme="dark"
+  data-a11y-animated-images="system" data-a11y-link-underlines="true"
+  >
+
+
+  <head>
+    <meta charset="utf-8">
+  <link rel="dns-prefetch" href="https://github.githubassets.com">
+  <link rel="dns-prefetch" href="https://avatars.githubusercontent.com">
+  <link rel="dns-prefetch" href="https://github-cloud.s3.amazonaws.com">
+  <link rel="dns-prefetch" href="https://user-images.githubusercontent.com/">
+  <link rel="preconnect" href="https://github.githubassets.com" crossorigin>
+  <link rel="preconnect" href="https://avatars.githubusercontent.com">
+
+  
+
+
+  <link crossorigin="anonymous" media="all" rel="stylesheet" href="https://github.githubassets.com/assets/light-f552bab6ce72.css" /><link crossorigin="anonymous" media="all" rel="stylesheet" href="https://github.githubassets.com/assets/dark-4589f64a2275.css" /><link data-color-theme="dark_dimmed" crossorigin="anonymous" media="all" rel="stylesheet" data-href="https://github.githubassets.com/assets/dark_dimmed-a7246d2d6733.css" /><link data-color-theme="dark_high_contrast" crossorigin="anonymous" media="all" rel="stylesheet" data-href="https://github.githubassets.com/assets/dark_high_contrast-f2ef05cef2f1.css" /><link data-color-theme="dark_colorblind" crossorigin="anonymous" media="all" rel="stylesheet" data-href="https://github.githubassets.com/assets/dark_colorblind-daa1fe317131.css" /><link data-color-theme="light_colorblind" crossorigin="anonymous" media="all" rel="stylesheet" data-href="https://github.githubassets.com/assets/light_colorblind-1ab6fcc64845.css" /><link data-color-theme="light_high_contrast" crossorigin="anonymous" media="all" rel="stylesheet" data-href="https://github.githubassets.com/assets/light_high_contrast-46de871e876c.css" /><link data-color-theme="light_tritanopia" crossorigin="anonymous" media="all" rel="stylesheet" data-href="https://github.githubassets.com/assets/light_tritanopia-c9754fef2a31.css" /><link data-color-theme="dark_tritanopia" crossorigin="anonymous" media="all" rel="stylesheet" data-href="https://github.githubassets.com/assets/dark_tritanopia-dba748981a29.css" />
+    <link crossorigin="anonymous" media="all" rel="stylesheet" href="https://github.githubassets.com/assets/primer-primitives-4cbeaa0795ef.css" />
+    <link crossorigin="anonymous" media="all" rel="stylesheet" href="https://github.githubassets.com/assets/primer-87f353b17355.css" />
+    <link crossorigin="anonymous" media="all" rel="stylesheet" href="https://github.githubassets.com/assets/global-545513c45073.css" />
+    <link crossorigin="anonymous" media="all" rel="stylesheet" href="https://github.githubassets.com/assets/github-f1af66156f94.css" />
+  <link crossorigin="anonymous" media="all" rel="stylesheet" href="https://github.githubassets.com/assets/repository-2e900f0ac288.css" />
+<link crossorigin="anonymous" media="all" rel="stylesheet" href="https://github.githubassets.com/assets/code-33498bbbf39d.css" />
+
+  
+
+
+  <script type="application/json" id="client-env">{"locale":"en","featureFlags":["code_vulnerability_scanning","copilot_chat_static_thread_suggestions","copilot_conversational_ux_history_refs","copilot_followup_to_agent","copilot_smell_icebreaker_ux","copilot_implicit_context","copilot_stop_response","copilot_updated_function_buttons","failbot_handle_non_errors","geojson_azure_maps","image_metric_tracking","marketing_forms_api_integration_contact_request","marketing_pages_search_explore_provider","turbo_experiment_risky","sample_network_conn_type","no_character_key_shortcuts_in_inputs","react_start_transition_for_navigations","custom_inp","remove_child_patch","kb_source_repos"]}</script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/wp-runtime-b7025357e898.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_dompurify_dist_purify_js-810e4b1b9abd.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_oddbird_popover-polyfill_dist_popover_js-4ac41d0a76fd.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_smoothscroll-polyfill_dist_smoothscroll_js-node_modules_stacktrace-parse-a448e4-bdc28e06dc01.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/environment-65dcc25bed15.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_primer_behaviors_dist_esm_focus-zone_js-f669b9466f06.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_github_selector-observer_dist_index_esm_js-9f960d9b217c.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_github_combobox-nav_dist_index_js-node_modules_github_markdown-toolbar-e-820fc0-1176135e4d90.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_github_auto-complete-element_dist_index_js-node_modules_github_catalyst_-392fe4-5df1d85d02da.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_github_text-expander-element_dist_index_js-b2135edb5ced.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_github_filter-input-element_dist_index_js-node_modules_github_remote-inp-b7d8f4-6e6f83bcc978.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_github_mini-throttle_dist_index_js-node_modules_delegated-events_dist_in-b63d41-1e3984e4dd2f.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_github_file-attachment-element_dist_index_js-node_modules_primer_view-co-3959a9-1ccb1cef5682.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/app_assets_modules_github_onfocus_ts-ui_packages_trusted-types-policies_policy_ts-ui_packages-6fe316-4083e7233d28.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/github-elements-c9cd2492b1b3.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/element-registry-16ae4a83aa73.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_braintree_browser-detection_dist_browser-detection_js-node_modules_githu-fd5530-79ffdad54bcd.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_lit-html_lit-html_js-cc7cb714ead5.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_morphdom_dist_morphdom-esm_js-node_modules_github_memoize_dist_esm_index_js-8d7117d67c36.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_github_turbo_dist_turbo_es2017-esm_js-1cea0f5eff45.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_github_remote-form_dist_index_js-node_modules_delegated-events_dist_inde-893f9f-880ac2bbb719.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_scroll-anchoring_dist_scroll-anchoring_esm_js-node_modules_github_hotkey-1a1d91-1bb71f3f93c2.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_color-convert_index_js-cdd1e82b3795.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_primer_behaviors_dist_esm_dimensions_js-node_modules_github_jtml_lib_index_js-b1947a1d4855.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_github_session-resume_dist_index_js-node_modules_primer_behaviors_dist_e-da6ec6-77ce2f267f4e.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_github_quote-selection_dist_index_js-node_modules_github_textarea-autosi-9e0349-7c78ee755ad3.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/app_assets_modules_github_updatable-content_ts-7fcc5f2841d8.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/app_assets_modules_github_behaviors_task-list_ts-app_assets_modules_github_onfocus_ts-app_ass-421cec-d3af2356fb47.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/app_assets_modules_github_sticky-scroll-into-view_ts-3dc342dedcb0.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/app_assets_modules_github_behaviors_ajax-error_ts-app_assets_modules_github_behaviors_include-467754-0b06f9573e1c.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/app_assets_modules_github_behaviors_commenting_edit_ts-app_assets_modules_github_behaviors_ht-83c235-5276a3faf037.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/behaviors-4f7a77997eec.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_delegated-events_dist_index_js-node_modules_github_catalyst_lib_index_js-06ff531-2ea61fcc9a71.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/notifications-global-0409f6303340.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/app_assets_modules_github_repositories_get-repo-element_ts-e21ae6671295.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/code-menu-67595c3a6d0c.js"></script>
+  
+  <script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/react-lib-dc88c1a68b28.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_primer_octicons-react_dist_index_esm_js-node_modules_primer_react_lib-es-541a38-2ad77ede4dad.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_primer_react_lib-esm_Box_Box_js-5a335cbe71ad.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_primer_react_lib-esm_FeatureFlags_FeatureFlags_js-node_modules_github_ca-9009bd-47065f21e9ac.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_primer_react_lib-esm_Button_Button_js-618154c88198.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_primer_react_lib-esm_TooltipV2_Tooltip_js-98aea6945770.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_primer_react_node_modules_primer_octicons-react_dist_index_esm_mjs-dc98a76c65d6.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_primer_react_lib-esm_ActionList_index_js-a2fe8fc7236e.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_primer_react_lib-esm_TextInput_TextInput_js-57e9c5f82efe.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_primer_react_lib-esm_FormControl_FormControl_js-61ac46c67a7e.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_primer_react_lib-esm_ActionMenu_ActionMenu_js-node_modules_primer_react_-5b2420-3d111386e1c1.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_react-router-dom_dist_index_js-2b1dbeadb6d4.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_primer_react_lib-esm_Link_Link_js-node_modules_primer_react_lib-esm_Rela-a903d7-17c01d44f123.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_primer_react_lib-esm_ConfirmationDialog_ConfirmationDialog_js-04806264ff4d.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_primer_react_lib-esm_Heading_Heading_js-node_modules_primer_react_lib-es-8280c5-4772b28bff07.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_primer_react_lib-esm_PageLayout_PageLayout_js-node_modules_github_hydro--f8521d-a461a484b308.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_primer_react_lib-esm_Button_LinkButton_js-node_modules_primer_react_lib--a52ff3-7e9e67a2b35e.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_primer_react_lib-esm_TreeView_TreeView_js-9456d871c361.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_primer_react_lib-esm_AvatarStack_AvatarStack_js-node_modules_primer_reac-f8b822-fa26f2c87125.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/ui_packages_react-core_create-browser-history_ts-ui_packages_safe-storage_safe-storage_ts-ui_-682c2c-44ed51a2083d.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/ui_packages_react-core_register-app_ts-a7b9de7616e6.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/ui_packages_paths_index_ts-d30e09039de9.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/ui_packages_ref-selector_RefSelector_tsx-84a0dce6bcb2.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/ui_packages_code-view-shared_hooks_shortcuts_ts-ui_packages_commit-attribution_index_ts-ui_pa-e33d1b-9311565c937c.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/app_assets_modules_react-shared_hooks_use-canonical-object_ts-ui_packages_code-view-shared_ho-7d1336-f60ff61341ea.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/app_assets_modules_github_blob-anchor_ts-app_assets_modules_github_filter-sort_ts-app_assets_-e50ab6-06193ffb3fd6.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/react-code-view-f1ff0c9d791b.js"></script>
+<link crossorigin="anonymous" media="all" rel="stylesheet" href="https://github.githubassets.com/assets/react-code-view.98a0f4bdacd6223a0b70.module.css" />
+
+
+  <title>mybatis-spring/src/main/java/org/mybatis/spring/config/mybatis-spring.xsd at master · YunaiV/mybatis-spring · GitHub</title>
+
+
+
+  <meta name="route-pattern" content="/:user_id/:repository/blob/*name(/*path)" data-turbo-transient>
+  <meta name="route-controller" content="blob" data-turbo-transient>
+  <meta name="route-action" content="show" data-turbo-transient>
+
+    
+  <meta name="current-catalog-service-hash" content="82c569b93da5c18ed649ebd4c2c79437db4611a6a1373e805a3cb001c64130b7">
+
+
+  <meta name="request-id" content="5C1E:2EF152:1EA91:1F48E:666A5DDC" data-pjax-transient="true"/><meta name="html-safe-nonce" content="39e3dbae91094f0ea5d05b0b7acb1f4087f9e51f8eff75e30386b757ff0766bd" data-pjax-transient="true"/><meta name="visitor-payload" content="eyJyZWZlcnJlciI6IiIsInJlcXVlc3RfaWQiOiI1QzFFOjJFRjE1MjoxRUE5MToxRjQ4RTo2NjZBNUREQyIsInZpc2l0b3JfaWQiOiIxOTQ1OTE3NDU0Mzc3NzA0OTI0IiwicmVnaW9uX2VkZ2UiOiJzZWEiLCJyZWdpb25fcmVuZGVyIjoic2VhIn0=" data-pjax-transient="true"/><meta name="visitor-hmac" content="155a13a9c0d67cabbdbb8e17bd6312b04ac2b9f46b93a8efed2b371774063e7e" data-pjax-transient="true"/>
+
+
+    <meta name="hovercard-subject-tag" content="repository:156698356" data-turbo-transient>
+
+
+  <meta name="github-keyboard-shortcuts" content="repository,source-code,file-tree,copilot" data-turbo-transient="true" />
+  
+
+  <meta name="selected-link" value="repo_source" data-turbo-transient>
+  <link rel="assets" href="https://github.githubassets.com/">
+
+    <meta name="google-site-verification" content="Apib7-x98H0j5cPqHWwSMm6dNU4GmODRoqxLiDzdx9I">
+
+<meta name="octolytics-url" content="https://collector.github.com/github/collect" />
+
+  <meta name="analytics-location" content="/&lt;user-name&gt;/&lt;repo-name&gt;/blob/show" data-turbo-transient="true" />
+
+  
+
+
+
+
+    <meta name="user-login" content="">
+
+  
+
+    <meta name="viewport" content="width=device-width">
+
+    
+
+      <meta name="description" content="源码解析中文地址：http://www.iocoder.cn/MyBatis/good-collection?github - mybatis-spring/src/main/java/org/mybatis/spring/config/mybatis-spring.xsd at master · YunaiV/mybatis-spring">
+
+      <link rel="search" type="application/opensearchdescription+xml" href="/opensearch.xml" title="GitHub">
+
+    <link rel="fluid-icon" href="https://github.com/fluidicon.png" title="GitHub">
+    <meta property="fb:app_id" content="1401488693436528">
+    <meta name="apple-itunes-app" content="app-id=1477376905, app-argument=https://github.com/YunaiV/mybatis-spring/blob/master/src/main/java/org/mybatis/spring/config/mybatis-spring.xsd" />
+
+      <meta name="twitter:image:src" content="https://opengraph.githubassets.com/01bf7268aef0ecd55264a238783beaebc1fde883d7abc4164bde2ed823d4e9de/YunaiV/mybatis-spring" /><meta name="twitter:site" content="@github" /><meta name="twitter:card" content="summary_large_image" /><meta name="twitter:title" content="mybatis-spring/src/main/java/org/mybatis/spring/config/mybatis-spring.xsd at master · YunaiV/mybatis-spring" /><meta name="twitter:description" content="源码解析中文地址：http://www.iocoder.cn/MyBatis/good-collection?github - YunaiV/mybatis-spring" />
+  <meta property="og:image" content="https://opengraph.githubassets.com/01bf7268aef0ecd55264a238783beaebc1fde883d7abc4164bde2ed823d4e9de/YunaiV/mybatis-spring" /><meta property="og:image:alt" content="源码解析中文地址：http://www.iocoder.cn/MyBatis/good-collection?github - YunaiV/mybatis-spring" /><meta property="og:image:width" content="1200" /><meta property="og:image:height" content="600" /><meta property="og:site_name" content="GitHub" /><meta property="og:type" content="object" /><meta property="og:title" content="mybatis-spring/src/main/java/org/mybatis/spring/config/mybatis-spring.xsd at master · YunaiV/mybatis-spring" /><meta property="og:url" content="https://github.com/YunaiV/mybatis-spring/blob/master/src/main/java/org/mybatis/spring/config/mybatis-spring.xsd" /><meta property="og:description" content="源码解析中文地址：http://www.iocoder.cn/MyBatis/good-collection?github - YunaiV/mybatis-spring" />
+  
+
+
+
+
+      <meta name="hostname" content="github.com">
+
+
+
+        <meta name="expected-hostname" content="github.com">
+
+
+  <meta http-equiv="x-pjax-version" content="f73b40b0e87456d1ee83faec3554d35b01be13766611afaaafe2e2d6f08d500a" data-turbo-track="reload">
+  <meta http-equiv="x-pjax-csp-version" content="cd708ee2def842997e00c6ea48122249b3249615ca3c50f1e66cc10581f34f3c" data-turbo-track="reload">
+  <meta http-equiv="x-pjax-css-version" content="a231bdac81d3a969a38b5854f9189b5fd6b6771f9788e9c2a20fadd334ed3906" data-turbo-track="reload">
+  <meta http-equiv="x-pjax-js-version" content="a625ed4b7913849d98588605d3846b7e09e185b44da5b7a6bd210f826b517207" data-turbo-track="reload">
+
+  <meta name="turbo-cache-control" content="no-preview" data-turbo-transient="">
+
+      <meta name="turbo-cache-control" content="no-cache" data-turbo-transient>
+    <meta data-hydrostats="publish">
+  <meta name="go-import" content="github.com/YunaiV/mybatis-spring git https://github.com/YunaiV/mybatis-spring.git">
+
+  <meta name="octolytics-dimension-user_id" content="2015545" /><meta name="octolytics-dimension-user_login" content="YunaiV" /><meta name="octolytics-dimension-repository_id" content="156698356" /><meta name="octolytics-dimension-repository_nwo" content="YunaiV/mybatis-spring" /><meta name="octolytics-dimension-repository_public" content="true" /><meta name="octolytics-dimension-repository_is_fork" content="true" /><meta name="octolytics-dimension-repository_parent_id" content="8247368" /><meta name="octolytics-dimension-repository_parent_nwo" content="mybatis/spring" /><meta name="octolytics-dimension-repository_network_root_id" content="8247368" /><meta name="octolytics-dimension-repository_network_root_nwo" content="mybatis/spring" />
+
+
+
+    
+
+    <meta name="turbo-body-classes" content="logged-out env-production page-responsive">
+
+
+  <meta name="browser-stats-url" content="https://api.github.com/_private/browser/stats">
+
+  <meta name="browser-errors-url" content="https://api.github.com/_private/browser/errors">
+
+  <link rel="mask-icon" href="https://github.githubassets.com/assets/pinned-octocat-093da3e6fa40.svg" color="#000000">
+  <link rel="alternate icon" class="js-site-favicon" type="image/png" href="https://github.githubassets.com/favicons/favicon.png">
+  <link rel="icon" class="js-site-favicon" type="image/svg+xml" href="https://github.githubassets.com/favicons/favicon.svg">
+
+<meta name="theme-color" content="#1e2327">
+<meta name="color-scheme" content="light dark" />
+
+
+  <link rel="manifest" href="/manifest.json" crossOrigin="use-credentials">
+
+  </head>
+
+  <body class="logged-out env-production page-responsive" style="word-wrap: break-word;">
+    <div data-turbo-body class="logged-out env-production page-responsive" style="word-wrap: break-word;">
+      
+
+
+    <div class="position-relative js-header-wrapper ">
+      <a href="#start-of-content" data-skip-target-assigned="false" class="px-2 py-4 color-bg-accent-emphasis color-fg-on-emphasis show-on-focus js-skip-to-content">Skip to content</a>
+
+      <span data-view-component="true" class="progress-pjax-loader Progress position-fixed width-full">
+    <span style="width: 0%;" data-view-component="true" class="Progress-item progress-pjax-loader-bar left-0 top-0 color-bg-accent-emphasis"></span>
+</span>      
+      
+      
+
+
+
+
+
+
+
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_primer_react_lib-esm_Button_IconButton_js-node_modules_primer_react_lib--1cd808-d9a0e71b26f4.js"></script>
+
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/keyboard-shortcuts-dialog-92ca2d9ac2b1.js"></script>
+
+<react-partial
+  partial-name="keyboard-shortcuts-dialog"
+  data-ssr="false"
+>
+  
+  <script type="application/json" data-target="react-partial.embeddedData">{"props":{"docsUrl":"https://docs.github.com/get-started/accessibility/keyboard-shortcuts"}}</script>
+  <div data-target="react-partial.reactRoot"></div>
+</react-partial>
+
+
+
+
+      
+
+        
+
+            
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/vendors-node_modules_github_remote-form_dist_index_js-node_modules_delegated-events_dist_inde-94fd67-8743f7dc256e.js"></script>
+<script crossorigin="anonymous" defer="defer" type="application/javascript" src="https://github.githubassets.com/assets/sessions-458fee042571.js"></script>
+<header class="Header-old header-logged-out js-details-container Details position-relative f4 py-3" role="banner" data-color-mode=light data-light-theme=light data-dark-theme=dark>
+  <h2 class="sr-only">Navigation Menu</h2>
+
+  <button type="button" class="Header-backdrop d-lg-none border-0 position-fixed top-0 left-0 width-full height-full js-details-target" aria-label="Toggle navigation">
+    <span class="d-none">Toggle navigation</span>
+  </button>
+
+  <div class=" d-flex flex-column flex-lg-row flex-items-center p-responsive height-full position-relative z-1">
+    <div class="d-flex flex-justify-between flex-items-center width-full width-lg-auto">
+      <a class="mr-lg-3 color-fg-inherit flex-order-2" href="https://github.com/" aria-label="Homepage" data-ga-click="(Logged out) Header, go to homepage, icon:logo-wordmark">
+        <svg height="32" aria-hidden="true" viewBox="0 0 16 16" version="1.1" width="32" data-view-component="true" class="octicon octicon-mark-github">
+    <path d="M8 0c4.42 0 8 3.58 8 8a8.013 8.013 0 0 1-5.45 7.59c-.4.08-.55-.17-.55-.38 0-.27.01-1.13.01-2.2 0-.75-.25-1.23-.54-1.48 1.78-.2 3.65-.88 3.65-3.95 0-.88-.31-1.59-.82-2.15.08-.2.36-1.02-.08-2.12 0 0-.67-.22-2.2.82-.64-.18-1.32-.27-2-.27-.68 0-1.36.09-2 .27-1.53-1.03-2.2-.82-2.2-.82-.44 1.1-.16 1.92-.08 2.12-.51.56-.82 1.28-.82 2.15 0 3.06 1.86 3.75 3.64 3.95-.23.2-.44.55-.51 1.07-.46.21-1.61.55-2.33-.66-.15-.24-.6-.83-1.23-.82-.67.01-.27.38.01.53.34.19.73.9.82 1.13.16.45.68 1.31 2.69.94 0 .67.01 1.3.01 1.49 0 .21-.15.45-.55.38A7.995 7.995 0 0 1 0 8c0-4.42 3.58-8 8-8Z"></path>
+</svg>
+      </a>
+
+      <div class="flex-1">
+        <a href="/login?return_to=https%3A%2F%2Fgithub.com%2FYunaiV%2Fmybatis-spring%2Fblob%2Fmaster%2Fsrc%2Fmain%2Fjava%2Forg%2Fmybatis%2Fspring%2Fconfig%2Fmybatis-spring.xsd"
+          class="d-inline-block d-lg-none flex-order-1 f5 no-underline border color-border-default rounded-2 px-2 py-1 color-fg-inherit"
+          data-hydro-click="{&quot;event_type&quot;:&quot;authentication.click&quot;,&quot;payload&quot;:{&quot;location_in_page&quot;:&quot;site header menu&quot;,&quot;repository_id&quot;:null,&quot;auth_type&quot;:&quot;SIGN_UP&quot;,&quot;originating_url&quot;:&quot;https://github.com/YunaiV/mybatis-spring/blob/master/src/main/java/org/mybatis/spring/config/mybatis-spring.xsd&quot;,&quot;user_id&quot;:null}}" data-hydro-click-hmac="23a350f04210ca282e56bf8b6195788c422b8f00997747219cb664ea99254860"
+          data-ga-click="(Logged out) Header, clicked Sign in, text:sign-in">
+          Sign in
+        </a>
+      </div>
+
+      <div class="flex-1 flex-order-2 text-right">
+        <button aria-label="Toggle navigation" aria-expanded="false" type="button" data-view-component="true" class="js-details-target Button--link Button--medium Button d-lg-none color-fg-inherit p-1">  <span class="Button-content">
+    <span class="Button-label"><div class="HeaderMenu-toggle-bar rounded my-1"></div>
+            <div class="HeaderMenu-toggle-bar rounded my-1"></div>
+            <div class="HeaderMenu-toggle-bar rounded my-1"></div></span>
+  </span>
+</button>
+      </div>
+    </div>
+
+
+    <div class="HeaderMenu--logged-out p-responsive height-fit position-lg-relative d-lg-flex flex-column flex-auto pt-7 pb-4 top-0">
+      <div class="header-menu-wrapper d-flex flex-column flex-self-end flex-lg-row flex-justify-between flex-auto p-3 p-lg-0 rounded rounded-lg-0 mt-3 mt-lg-0">
+          <nav class="mt-0 px-3 px-lg-0 mb-3 mb-lg-0" aria-label="Global">
+            <ul class="d-lg-flex list-style-none">
+                <li class="HeaderMenu-item position-relative flex-wrap flex-justify-between flex-items-center d-block d-lg-flex flex-lg-nowrap flex-lg-items-center js-details-container js-header-menu-item">
+      <button type="button" class="HeaderMenu-link border-0 width-full width-lg-auto px-0 px-lg-2 py-3 py-lg-2 no-wrap d-flex flex-items-center flex-justify-between js-details-target" aria-expanded="false">
+        Product
+        <svg opacity="0.5" aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-chevron-down HeaderMenu-icon ml-1">
+    <path d="M12.78 5.22a.749.749 0 0 1 0 1.06l-4.25 4.25a.749.749 0 0 1-1.06 0L3.22 6.28a.749.749 0 1 1 1.06-1.06L8 8.939l3.72-3.719a.749.749 0 0 1 1.06 0Z"></path>
+</svg>
+      </button>
+      <div class="HeaderMenu-dropdown dropdown-menu rounded m-0 p-0 py-2 py-lg-4 position-relative position-lg-absolute left-0 left-lg-n3 d-lg-flex dropdown-menu-wide">
+          <div class="px-lg-4 border-lg-right mb-4 mb-lg-0 pr-lg-7">
+            <ul class="list-style-none f5" >
+                <li>
+  <a class="HeaderMenu-dropdown-link lh-condensed d-block no-underline position-relative py-2 Link--secondary d-flex flex-items-center pb-lg-3" data-analytics-event="{&quot;category&quot;:&quot;Header dropdown (logged out), Product&quot;,&quot;action&quot;:&quot;click to go to Actions&quot;,&quot;label&quot;:&quot;ref_cta:Actions;&quot;}" href="https://github.com/features/actions">
+      <svg aria-hidden="true" height="24" viewBox="0 0 24 24" version="1.1" width="24" data-view-component="true" class="octicon octicon-workflow color-fg-subtle mr-3">
+    <path d="M1 3a2 2 0 0 1 2-2h6.5a2 2 0 0 1 2 2v6.5a2 2 0 0 1-2 2H7v4.063C7 16.355 7.644 17 8.438 17H12.5v-2.5a2 2 0 0 1 2-2H21a2 2 0 0 1 2 2V21a2 2 0 0 1-2 2h-6.5a2 2 0 0 1-2-2v-2.5H8.437A2.939 2.939 0 0 1 5.5 15.562V11.5H3a2 2 0 0 1-2-2Zm2-.5a.5.5 0 0 0-.5.5v6.5a.5.5 0 0 0 .5.5h6.5a.5.5 0 0 0 .5-.5V3a.5.5 0 0 0-.5-.5ZM14.5 14a.5.5 0 0 0-.5.5V21a.5.5 0 0 0 .5.5H21a.5.5 0 0 0 .5-.5v-6.5a.5.5 0 0 0-.5-.5Z"></path>
+</svg>
+      <div>
+        <div class="color-fg-default h4">Actions</div>
+        Automate any workflow
+      </div>
+
+    
+</a></li>
+
+                <li>
+  <a class="HeaderMenu-dropdown-link lh-condensed d-block no-underline position-relative py-2 Link--secondary d-flex flex-items-center pb-lg-3" data-analytics-event="{&quot;category&quot;:&quot;Header dropdown (logged out), Product&quot;,&quot;action&quot;:&quot;click to go to Packages&quot;,&quot;label&quot;:&quot;ref_cta:Packages;&quot;}" href="https://github.com/features/packages">
+      <svg aria-hidden="true" height="24" viewBox="0 0 24 24" version="1.1" width="24" data-view-component="true" class="octicon octicon-package color-fg-subtle mr-3">
+    <path d="M12.876.64V.639l8.25 4.763c.541.313.875.89.875 1.515v9.525a1.75 1.75 0 0 1-.875 1.516l-8.25 4.762a1.748 1.748 0 0 1-1.75 0l-8.25-4.763a1.75 1.75 0 0 1-.875-1.515V6.917c0-.625.334-1.202.875-1.515L11.126.64a1.748 1.748 0 0 1 1.75 0Zm-1 1.298L4.251 6.34l7.75 4.474 7.75-4.474-7.625-4.402a.248.248 0 0 0-.25 0Zm.875 19.123 7.625-4.402a.25.25 0 0 0 .125-.216V7.639l-7.75 4.474ZM3.501 7.64v8.803c0 .09.048.172.125.216l7.625 4.402v-8.947Z"></path>
+</svg>
+      <div>
+        <div class="color-fg-default h4">Packages</div>
+        Host and manage packages
+      </div>
+
+    
+</a></li>
+
+                <li>
+  <a class="HeaderMenu-dropdown-link lh-condensed d-block no-underline position-relative py-2 Link--secondary d-flex flex-items-center pb-lg-3" data-analytics-event="{&quot;category&quot;:&quot;Header dropdown (logged out), Product&quot;,&quot;action&quot;:&quot;click to go to Security&quot;,&quot;label&quot;:&quot;ref_cta:Security;&quot;}" href="https://github.com/features/security">
+      <svg aria-hidden="true" height="24" viewBox="0 0 24 24" version="1.1" width="24" data-view-component="true" class="octicon octicon-shield-check color-fg-subtle mr-3">
+    <path d="M16.53 9.78a.75.75 0 0 0-1.06-1.06L11 13.19l-1.97-1.97a.75.75 0 0 0-1.06 1.06l2.5 2.5a.75.75 0 0 0 1.06 0l5-5Z"></path><path d="m12.54.637 8.25 2.675A1.75 1.75 0 0 1 22 4.976V10c0 6.19-3.771 10.704-9.401 12.83a1.704 1.704 0 0 1-1.198 0C5.77 20.705 2 16.19 2 10V4.976c0-.758.489-1.43 1.21-1.664L11.46.637a1.748 1.748 0 0 1 1.08 0Zm-.617 1.426-8.25 2.676a.249.249 0 0 0-.173.237V10c0 5.46 3.28 9.483 8.43 11.426a.199.199 0 0 0 .14 0C17.22 19.483 20.5 15.461 20.5 10V4.976a.25.25 0 0 0-.173-.237l-8.25-2.676a.253.253 0 0 0-.154 0Z"></path>
+</svg>
+      <div>
+        <div class="color-fg-default h4">Security</div>
+        Find and fix vulnerabilities
+      </div>
+
+    
+</a></li>
+
+                <li>
+  <a class="HeaderMenu-dropdown-link lh-condensed d-block no-underline position-relative py-2 Link--secondary d-flex flex-items-center pb-lg-3" data-analytics-event="{&quot;category&quot;:&quot;Header dropdown (logged out), Product&quot;,&quot;action&quot;:&quot;click to go to Codespaces&quot;,&quot;label&quot;:&quot;ref_cta:Codespaces;&quot;}" href="https://github.com/features/codespaces">
+      <svg aria-hidden="true" height="24" viewBox="0 0 24 24" version="1.1" width="24" data-view-component="true" class="octicon octicon-codespaces color-fg-subtle mr-3">
+    <path d="M3.5 3.75C3.5 2.784 4.284 2 5.25 2h13.5c.966 0 1.75.784 1.75 1.75v7.5A1.75 1.75 0 0 1 18.75 13H5.25a1.75 1.75 0 0 1-1.75-1.75Zm-2 12c0-.966.784-1.75 1.75-1.75h17.5c.966 0 1.75.784 1.75 1.75v4a1.75 1.75 0 0 1-1.75 1.75H3.25a1.75 1.75 0 0 1-1.75-1.75ZM5.25 3.5a.25.25 0 0 0-.25.25v7.5c0 .138.112.25.25.25h13.5a.25.25 0 0 0 .25-.25v-7.5a.25.25 0 0 0-.25-.25Zm-2 12a.25.25 0 0 0-.25.25v4c0 .138.112.25.25.25h17.5a.25.25 0 0 0 .25-.25v-4a.25.25 0 0 0-.25-.25Z"></path><path d="M10 17.75a.75.75 0 0 1 .75-.75h6.5a.75.75 0 0 1 0 1.5h-6.5a.75.75 0 0 1-.75-.75Zm-4 0a.75.75 0 0 1 .75-.75h.5a.75.75 0 0 1 0 1.5h-.5a.75.75 0 0 1-.75-.75Z"></path>
+</svg>
+      <div>
+        <div class="color-fg-default h4">Codespaces</div>
+        Instant dev environments
+      </div>
+
+    
+</a></li>
+
+                <li>
+  <a class="HeaderMenu-dropdown-link lh-condensed d-block no-underline position-relative py-2 Link--secondary d-flex flex-items-center pb-lg-3" data-analytics-event="{&quot;category&quot;:&quot;Header dropdown (logged out), Product&quot;,&quot;action&quot;:&quot;click to go to GitHub Copilot&quot;,&quot;label&quot;:&quot;ref_cta:GitHub Copilot;&quot;}" href="https://github.com/features/copilot">
+      <svg aria-hidden="true" height="24" viewBox="0 0 24 24" version="1.1" width="24" data-view-component="true" class="octicon octicon-copilot color-fg-subtle mr-3">
+    <path d="M23.922 16.992c-.861 1.495-5.859 5.023-11.922 5.023-6.063 0-11.061-3.528-11.922-5.023A.641.641 0 0 1 0 16.736v-2.869a.841.841 0 0 1 .053-.22c.372-.935 1.347-2.292 2.605-2.656.167-.429.414-1.055.644-1.517a10.195 10.195 0 0 1-.052-1.086c0-1.331.282-2.499 1.132-3.368.397-.406.89-.717 1.474-.952 1.399-1.136 3.392-2.093 6.122-2.093 2.731 0 4.767.957 6.166 2.093.584.235 1.077.546 1.474.952.85.869 1.132 2.037 1.132 3.368 0 .368-.014.733-.052 1.086.23.462.477 1.088.644 1.517 1.258.364 2.233 1.721 2.605 2.656a.832.832 0 0 1 .053.22v2.869a.641.641 0 0 1-.078.256ZM12.172 11h-.344a4.323 4.323 0 0 1-.355.508C10.703 12.455 9.555 13 7.965 13c-1.725 0-2.989-.359-3.782-1.259a2.005 2.005 0 0 1-.085-.104L4 11.741v6.585c1.435.779 4.514 2.179 8 2.179 3.486 0 6.565-1.4 8-2.179v-6.585l-.098-.104s-.033.045-.085.104c-.793.9-2.057 1.259-3.782 1.259-1.59 0-2.738-.545-3.508-1.492a4.323 4.323 0 0 1-.355-.508h-.016.016Zm.641-2.935c.136 1.057.403 1.913.878 2.497.442.544 1.134.938 2.344.938 1.573 0 2.292-.337 2.657-.751.384-.435.558-1.15.558-2.361 0-1.14-.243-1.847-.705-2.319-.477-.488-1.319-.862-2.824-1.025-1.487-.161-2.192.138-2.533.529-.269.307-.437.808-.438 1.578v.021c0 .265.021.562.063.893Zm-1.626 0c.042-.331.063-.628.063-.894v-.02c-.001-.77-.169-1.271-.438-1.578-.341-.391-1.046-.69-2.533-.529-1.505.163-2.347.537-2.824 1.025-.462.472-.705 1.179-.705 2.319 0 1.211.175 1.926.558 2.361.365.414 1.084.751 2.657.751 1.21 0 1.902-.394 2.344-.938.475-.584.742-1.44.878-2.497Z"></path><path d="M14.5 14.25a1 1 0 0 1 1 1v2a1 1 0 0 1-2 0v-2a1 1 0 0 1 1-1Zm-5 0a1 1 0 0 1 1 1v2a1 1 0 0 1-2 0v-2a1 1 0 0 1 1-1Z"></path>
+</svg>
+      <div>
+        <div class="color-fg-default h4">GitHub Copilot</div>
+        Write better code with AI
+      </div>
+
+    
+</a></li>
+
+                <li>
+  <a class="HeaderMenu-dropdown-link lh-condensed d-block no-underline position-relative py-2 Link--secondary d-flex flex-items-center pb-lg-3" data-analytics-event="{&quot;category&quot;:&quot;Header dropdown (logged out), Product&quot;,&quot;action&quot;:&quot;click to go to Code review&quot;,&quot;label&quot;:&quot;ref_cta:Code review;&quot;}" href="https://github.com/features/code-review">
+      <svg aria-hidden="true" height="24" viewBox="0 0 24 24" version="1.1" width="24" data-view-component="true" class="octicon octicon-code-review color-fg-subtle mr-3">
+    <path d="M10.3 6.74a.75.75 0 0 1-.04 1.06l-2.908 2.7 2.908 2.7a.75.75 0 1 1-1.02 1.1l-3.5-3.25a.75.75 0 0 1 0-1.1l3.5-3.25a.75.75 0 0 1 1.06.04Zm3.44 1.06a.75.75 0 1 1 1.02-1.1l3.5 3.25a.75.75 0 0 1 0 1.1l-3.5 3.25a.75.75 0 1 1-1.02-1.1l2.908-2.7-2.908-2.7Z"></path><path d="M1.5 4.25c0-.966.784-1.75 1.75-1.75h17.5c.966 0 1.75.784 1.75 1.75v12.5a1.75 1.75 0 0 1-1.75 1.75h-9.69l-3.573 3.573A1.458 1.458 0 0 1 5 21.043V18.5H3.25a1.75 1.75 0 0 1-1.75-1.75ZM3.25 4a.25.25 0 0 0-.25.25v12.5c0 .138.112.25.25.25h2.5a.75.75 0 0 1 .75.75v3.19l3.72-3.72a.749.749 0 0 1 .53-.22h10a.25.25 0 0 0 .25-.25V4.25a.25.25 0 0 0-.25-.25Z"></path>
+</svg>
+      <div>
+        <div class="color-fg-default h4">Code review</div>
+        Manage code changes
+      </div>
+
+    
+</a></li>
+
+                <li>
+  <a class="HeaderMenu-dropdown-link lh-condensed d-block no-underline position-relative py-2 Link--secondary d-flex flex-items-center pb-lg-3" data-analytics-event="{&quot;category&quot;:&quot;Header dropdown (logged out), Product&quot;,&quot;action&quot;:&quot;click to go to Issues&quot;,&quot;label&quot;:&quot;ref_cta:Issues;&quot;}" href="https://github.com/features/issues">
+      <svg aria-hidden="true" height="24" viewBox="0 0 24 24" version="1.1" width="24" data-view-component="true" class="octicon octicon-issue-opened color-fg-subtle mr-3">
+    <path d="M12 1c6.075 0 11 4.925 11 11s-4.925 11-11 11S1 18.075 1 12 5.925 1 12 1ZM2.5 12a9.5 9.5 0 0 0 9.5 9.5 9.5 9.5 0 0 0 9.5-9.5A9.5 9.5 0 0 0 12 2.5 9.5 9.5 0 0 0 2.5 12Zm9.5 2a2 2 0 1 1-.001-3.999A2 2 0 0 1 12 14Z"></path>
+</svg>
+      <div>
+        <div class="color-fg-default h4">Issues</div>
+        Plan and track work
+      </div>
+
+    
+</a></li>
+
+                <li>
+  <a class="HeaderMenu-dropdown-link lh-condensed d-block no-underline position-relative py-2 Link--secondary d-flex flex-items-center" data-analytics-event="{&quot;category&quot;:&quot;Header dropdown (logged out), Product&quot;,&quot;action&quot;:&quot;click to go to Discussions&quot;,&quot;label&quot;:&quot;ref_cta:Discussions;&quot;}" href="https://github.com/features/discussions">
+      <svg aria-hidden="true" height="24" viewBox="0 0 24 24" version="1.1" width="24" data-view-component="true" class="octicon octicon-comment-discussion color-fg-subtle mr-3">
+    <path d="M1.75 1h12.5c.966 0 1.75.784 1.75 1.75v9.5A1.75 1.75 0 0 1 14.25 14H8.061l-2.574 2.573A1.458 1.458 0 0 1 3 15.543V14H1.75A1.75 1.75 0 0 1 0 12.25v-9.5C0 1.784.784 1 1.75 1ZM1.5 2.75v9.5c0 .138.112.25.25.25h2a.75.75 0 0 1 .75.75v2.19l2.72-2.72a.749.749 0 0 1 .53-.22h6.5a.25.25 0 0 0 .25-.25v-9.5a.25.25 0 0 0-.25-.25H1.75a.25.25 0 0 0-.25.25Z"></path><path d="M22.5 8.75a.25.25 0 0 0-.25-.25h-3.5a.75.75 0 0 1 0-1.5h3.5c.966 0 1.75.784 1.75 1.75v9.5A1.75 1.75 0 0 1 22.25 20H21v1.543a1.457 1.457 0 0 1-2.487 1.03L15.939 20H10.75A1.75 1.75 0 0 1 9 18.25v-1.465a.75.75 0 0 1 1.5 0v1.465c0 .138.112.25.25.25h5.5a.75.75 0 0 1 .53.22l2.72 2.72v-2.19a.75.75 0 0 1 .75-.75h2a.25.25 0 0 0 .25-.25v-9.5Z"></path>
+</svg>
+      <div>
+        <div class="color-fg-default h4">Discussions</div>
+        Collaborate outside of code
+      </div>
+
+    
+</a></li>
+
+            </ul>
+          </div>
+          <div class="px-lg-4">
+              <span class="d-block h4 color-fg-default my-1" id="product-explore-heading">Explore</span>
+            <ul class="list-style-none f5" aria-labelledby="product-explore-heading">
+                <li>
+  <a class="HeaderMenu-dropdown-link lh-condensed d-block no-underline position-relative py-2 Link--secondary" data-analytics-event="{&quot;category&quot;:&quot;Header dropdown (logged out), Product&quot;,&quot;action&quot;:&quot;click to go to All features&quot;,&quot;label&quot;:&quot;ref_cta:All features;&quot;}" href="https://github.com/features">
+      All features
+
+    
+</a></li>
+
+                <li>
+  <a class="HeaderMenu-dropdown-link lh-condensed d-block no-underline position-relative py-2 Link--secondary" target="_blank" data-analytics-event="{&quot;category&quot;:&quot;Header dropdown (logged out), Product&quot;,&quot;action&quot;:&quot;click to go to Documentation&quot;,&quot;label&quot;:&quot;ref_cta:Documentation;&quot;}" href="https://docs.github.com">
+      Documentation
+
+    <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-link-external HeaderMenu-external-icon color-fg-subtle">
+    <path d="M3.75 2h3.5a.75.75 0 0 1 0 1.5h-3.5a.25.25 0 0 0-.25.25v8.5c0 .138.112.25.25.25h8.5a.25.25 0 0 0 .25-.25v-3.5a.75.75 0 0 1 1.5 0v3.5A1.75 1.75 0 0 1 12.25 14h-8.5A1.75 1.75 0 0 1 2 12.25v-8.5C2 2.784 2.784 2 3.75 2Zm6.854-1h4.146a.25.25 0 0 1 .25.25v4.146a.25.25 0 0 1-.427.177L13.03 4.03 9.28 7.78a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042l3.75-3.75-1.543-1.543A.25.25 0 0 1 10.604 1Z"></path>
+</svg>
+</a></li>
+
+                <li>
+  <a class="HeaderMenu-dropdown-link lh-condensed d-block no-underline position-relative py-2 Link--secondary" target="_blank" data-analytics-event="{&quot;category&quot;:&quot;Header dropdown (logged out), Product&quot;,&quot;action&quot;:&quot;click to go to GitHub Skills&quot;,&quot;label&quot;:&quot;ref_cta:GitHub Skills;&quot;}" href="https://skills.github.com">
+      GitHub Skills
+
+    <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-link-external HeaderMenu-external-icon color-fg-subtle">
+    <path d="M3.75 2h3.5a.75.75 0 0 1 0 1.5h-3.5a.25.25 0 0 0-.25.25v8.5c0 .138.112.25.25.25h8.5a.25.25 0 0 0 .25-.25v-3.5a.75.75 0 0 1 1.5 0v3.5A1.75 1.75 0 0 1 12.25 14h-8.5A1.75 1.75 0 0 1 2 12.25v-8.5C2 2.784 2.784 2 3.75 2Zm6.854-1h4.146a.25.25 0 0 1 .25.25v4.146a.25.25 0 0 1-.427.177L13.03 4.03 9.28 7.78a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042l3.75-3.75-1.543-1.543A.25.25 0 0 1 10.604 1Z"></path>
+</svg>
+</a></li>
+
+                <li>
+  <a class="HeaderMenu-dropdown-link lh-condensed d-block no-underline position-relative py-2 Link--secondary" target="_blank" data-analytics-event="{&quot;category&quot;:&quot;Header dropdown (logged out), Product&quot;,&quot;action&quot;:&quot;click to go to Blog&quot;,&quot;label&quot;:&quot;ref_cta:Blog;&quot;}" href="https://github.blog">
+      Blog
+
+    <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-link-external HeaderMenu-external-icon color-fg-subtle">
+    <path d="M3.75 2h3.5a.75.75 0 0 1 0 1.5h-3.5a.25.25 0 0 0-.25.25v8.5c0 .138.112.25.25.25h8.5a.25.25 0 0 0 .25-.25v-3.5a.75.75 0 0 1 1.5 0v3.5A1.75 1.75 0 0 1 12.25 14h-8.5A1.75 1.75 0 0 1 2 12.25v-8.5C2 2.784 2.784 2 3.75 2Zm6.854-1h4.146a.25.25 0 0 1 .25.25v4.146a.25.25 0 0 1-.427.177L13.03 4.03 9.28 7.78a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042l3.75-3.75-1.543-1.543A.25.25 0 0 1 10.604 1Z"></path>
+</svg>
+</a></li>
+
+            </ul>
+          </div>
+      </div>
+</li>
+
+
+                <li class="HeaderMenu-item position-relative flex-wrap flex-justify-between flex-items-center d-block d-lg-flex flex-lg-nowrap flex-lg-items-center js-details-container js-header-menu-item">
+      <button type="button" class="HeaderMenu-link border-0 width-full width-lg-auto px-0 px-lg-2 py-3 py-lg-2 no-wrap d-flex flex-items-center flex-justify-between js-details-target" aria-expanded="false">
+        Solutions
+        <svg opacity="0.5" aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-chevron-down HeaderMenu-icon ml-1">
+    <path d="M12.78 5.22a.749.749 0 0 1 0 1.06l-4.25 4.25a.749.749 0 0 1-1.06 0L3.22 6.28a.749.749 0 1 1 1.06-1.06L8 8.939l3.72-3.719a.749.749 0 0 1 1.06 0Z"></path>
+</svg>
+      </button>
+      <div class="HeaderMenu-dropdown dropdown-menu rounded m-0 p-0 py-2 py-lg-4 position-relative position-lg-absolute left-0 left-lg-n3 px-lg-4">
+          <div class="border-bottom pb-3 mb-3">
+              <span class="d-block h4 color-fg-default my-1" id="solutions-for-heading">For</span>
+            <ul class="list-style-none f5" aria-labelledby="solutions-for-heading">
+                <li>
+  <a class="HeaderMenu-dropdown-link lh-condensed d-block no-underline position-relative py-2 Link--secondary" data-analytics-event="{&quot;category&quot;:&quot;Header dropdown (logged out), Solutions&quot;,&quot;action&quot;:&quot;click to go to Enterprise&quot;,&quot;label&quot;:&quot;ref_cta:Enterprise;&quot;}" href="https://github.com/enterprise">
+      Enterprise
+
+    
+</a></li>
+
+                <li>
+  <a class="HeaderMenu-dropdown-link lh-condensed d-block no-underline position-relative py-2 Link--secondary" data-analytics-event="{&quot;category&quot;:&quot;Header dropdown (logged out), Solutions&quot;,&quot;action&quot;:&quot;click to go to Teams&quot;,&quot;label&quot;:&quot;ref_cta:Teams;&quot;}" href="https://github.com/team">
+      Teams
+
+    
+</a></li>
+
+                <li>
+  <a class="HeaderMenu-dropdown-link lh-condensed d-block no-underline position-relative py-2 Link--secondary" data-analytics-event="{&quot;category&quot;:&quot;Header dropdown (logged out), Solutions&quot;,&quot;action&quot;:&quot;click to go to Startups&quot;,&quot;label&quot;:&quot;ref_cta:Startups;&quot;}" href="https://github.com/enterprise/startups">
+      Startups
+
+    
+</a></li>
+
+                <li>
+  <a class="HeaderMenu-dropdown-link lh-condensed d-block no-underline position-relative py-2 Link--secondary" target="_blank" data-analytics-event="{&quot;category&quot;:&quot;Header dropdown (logged out), Solutions&quot;,&quot;action&quot;:&quot;click to go to Education&quot;,&quot;label&quot;:&quot;ref_cta:Education;&quot;}" href="https://education.github.com">
+      Education
+
+    <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-link-external HeaderMenu-external-icon color-fg-subtle">
+    <path d="M3.75 2h3.5a.75.75 0 0 1 0 1.5h-3.5a.25.25 0 0 0-.25.25v8.5c0 .138.112.25.25.25h8.5a.25.25 0 0 0 .25-.25v-3.5a.75.75 0 0 1 1.5 0v3.5A1.75 1.75 0 0 1 12.25 14h-8.5A1.75 1.75 0 0 1 2 12.25v-8.5C2 2.784 2.784 2 3.75 2Zm6.854-1h4.146a.25.25 0 0 1 .25.25v4.146a.25.25 0 0 1-.427.177L13.03 4.03 9.28 7.78a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042l3.75-3.75-1.543-1.543A.25.25 0 0 1 10.604 1Z"></path>
+</svg>
+</a></li>
+
+            </ul>
+          </div>
+          <div class="border-bottom pb-3 mb-3">
+              <span class="d-block h4 color-fg-default my-1" id="solutions-by-solution-heading">By Solution</span>
+            <ul class="list-style-none f5" aria-labelledby="solutions-by-solution-heading">
+                <li>
+  <a class="HeaderMenu-dropdown-link lh-condensed d-block no-underline position-relative py-2 Link--secondary" data-analytics-event="{&quot;category&quot;:&quot;Header dropdown (logged out), Solutions&quot;,&quot;action&quot;:&quot;click to go to CI/CD &amp;amp; Automation&quot;,&quot;label&quot;:&quot;ref_cta:CI/CD &amp;amp; Automation;&quot;}" href="https://github.com/solutions/ci-cd">
+      CI/CD &amp; Automation
+
+    
+</a></li>
+
+                <li>
+  <a class="HeaderMenu-dropdown-link lh-condensed d-block no-underline position-relative py-2 Link--secondary" data-analytics-event="{&quot;category&quot;:&quot;Header dropdown (logged out), Solutions&quot;,&quot;action&quot;:&quot;click to go to DevOps&quot;,&quot;label&quot;:&quot;ref_cta:DevOps;&quot;}" href="https://github.com/solutions/devops">
+      DevOps
+
+    
+</a></li>
+
+                <li>
+  <a class="HeaderMenu-dropdown-link lh-condensed d-block no-underline position-relative py-2 Link--secondary" target="_blank" data-analytics-event="{&quot;category&quot;:&quot;Header dropdown (logged out), Solutions&quot;,&quot;action&quot;:&quot;click to go to DevSecOps&quot;,&quot;label&quot;:&quot;ref_cta:DevSecOps;&quot;}" href="https://resources.github.com/devops/fundamentals/devsecops">
+      DevSecOps
+
+    <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-link-external HeaderMenu-external-icon color-fg-subtle">
+    <path d="M3.75 2h3.5a.75.75 0 0 1 0 1.5h-3.5a.25.25 0 0 0-.25.25v8.5c0 .138.112.25.25.25h8.5a.25.25 0 0 0 .25-.25v-3.5a.75.75 0 0 1 1.5 0v3.5A1.75 1.75 0 0 1 12.25 14h-8.5A1.75 1.75 0 0 1 2 12.25v-8.5C2 2.784 2.784 2 3.75 2Zm6.854-1h4.146a.25.25 0 0 1 .25.25v4.146a.25.25 0 0 1-.427.177L13.03 4.03 9.28 7.78a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042l3.75-3.75-1.543-1.543A.25.25 0 0 1 10.604 1Z"></path>
+</svg>
+</a></li>
+
+            </ul>
+          </div>
+          <div class="">
+              <span class="d-block h4 color-fg-default my-1" id="solutions-resources-heading">Resources</span>
+            <ul class="list-style-none f5" aria-labelledby="solutions-resources-heading">
+                <li>
+  <a class="HeaderMenu-dropdown-link lh-condensed d-block no-underline position-relative py-2 Link--secondary" target="_blank" data-analytics-event="{&quot;category&quot;:&quot;Header dropdown (logged out), Solutions&quot;,&quot;action&quot;:&quot;click to go to Learning Pathways&quot;,&quot;label&quot;:&quot;ref_cta:Learning Pathways;&quot;}" href="https://resources.github.com/learn/pathways">
+      Learning Pathways
+
+    <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-link-external HeaderMenu-external-icon color-fg-subtle">
+    <path d="M3.75 2h3.5a.75.75 0 0 1 0 1.5h-3.5a.25.25 0 0 0-.25.25v8.5c0 .138.112.25.25.25h8.5a.25.25 0 0 0 .25-.25v-3.5a.75.75 0 0 1 1.5 0v3.5A1.75 1.75 0 0 1 12.25 14h-8.5A1.75 1.75 0 0 1 2 12.25v-8.5C2 2.784 2.784 2 3.75 2Zm6.854-1h4.146a.25.25 0 0 1 .25.25v4.146a.25.25 0 0 1-.427.177L13.03 4.03 9.28 7.78a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042l3.75-3.75-1.543-1.543A.25.25 0 0 1 10.604 1Z"></path>
+</svg>
+</a></li>
+
+                <li>
+  <a class="HeaderMenu-dropdown-link lh-condensed d-block no-underline position-relative py-2 Link--secondary" target="_blank" data-analytics-event="{&quot;category&quot;:&quot;Header dropdown (logged out), Solutions&quot;,&quot;action&quot;:&quot;click to go to White papers, Ebooks, Webinars&quot;,&quot;label&quot;:&quot;ref_cta:White papers, Ebooks, Webinars;&quot;}" href="https://resources.github.com">
+      White papers, Ebooks, Webinars
+
+    <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-link-external HeaderMenu-external-icon color-fg-subtle">
+    <path d="M3.75 2h3.5a.75.75 0 0 1 0 1.5h-3.5a.25.25 0 0 0-.25.25v8.5c0 .138.112.25.25.25h8.5a.25.25 0 0 0 .25-.25v-3.5a.75.75 0 0 1 1.5 0v3.5A1.75 1.75 0 0 1 12.25 14h-8.5A1.75 1.75 0 0 1 2 12.25v-8.5C2 2.784 2.784 2 3.75 2Zm6.854-1h4.146a.25.25 0 0 1 .25.25v4.146a.25.25 0 0 1-.427.177L13.03 4.03 9.28 7.78a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042l3.75-3.75-1.543-1.543A.25.25 0 0 1 10.604 1Z"></path>
+</svg>
+</a></li>
+
+                <li>
+  <a class="HeaderMenu-dropdown-link lh-condensed d-block no-underline position-relative py-2 Link--secondary" data-analytics-event="{&quot;category&quot;:&quot;Header dropdown (logged out), Solutions&quot;,&quot;action&quot;:&quot;click to go to Customer Stories&quot;,&quot;label&quot;:&quot;ref_cta:Customer Stories;&quot;}" href="https://github.com/customer-stories">
+      Customer Stories
+
+    
+</a></li>
+
+                <li>
+  <a class="HeaderMenu-dropdown-link lh-condensed d-block no-underline position-relative py-2 Link--secondary" target="_blank" data-analytics-event="{&quot;category&quot;:&quot;Header dropdown (logged out), Solutions&quot;,&quot;action&quot;:&quot;click to go to Partners&quot;,&quot;label&quot;:&quot;ref_cta:Partners;&quot;}" href="https://partner.github.com">
+      Partners
+
+    <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-link-external HeaderMenu-external-icon color-fg-subtle">
+    <path d="M3.75 2h3.5a.75.75 0 0 1 0 1.5h-3.5a.25.25 0 0 0-.25.25v8.5c0 .138.112.25.25.25h8.5a.25.25 0 0 0 .25-.25v-3.5a.75.75 0 0 1 1.5 0v3.5A1.75 1.75 0 0 1 12.25 14h-8.5A1.75 1.75 0 0 1 2 12.25v-8.5C2 2.784 2.784 2 3.75 2Zm6.854-1h4.146a.25.25 0 0 1 .25.25v4.146a.25.25 0 0 1-.427.177L13.03 4.03 9.28 7.78a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042l3.75-3.75-1.543-1.543A.25.25 0 0 1 10.604 1Z"></path>
+</svg>
+</a></li>
+
+            </ul>
+          </div>
+      </div>
+</li>
+
+
+                <li class="HeaderMenu-item position-relative flex-wrap flex-justify-between flex-items-center d-block d-lg-flex flex-lg-nowrap flex-lg-items-center js-details-container js-header-menu-item">
+      <button type="button" class="HeaderMenu-link border-0 width-full width-lg-auto px-0 px-lg-2 py-3 py-lg-2 no-wrap d-flex flex-items-center flex-justify-between js-details-target" aria-expanded="false">
+        Open Source
+        <svg opacity="0.5" aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-chevron-down HeaderMenu-icon ml-1">
+    <path d="M12.78 5.22a.749.749 0 0 1 0 1.06l-4.25 4.25a.749.749 0 0 1-1.06 0L3.22 6.28a.749.749 0 1 1 1.06-1.06L8 8.939l3.72-3.719a.749.749 0 0 1 1.06 0Z"></path>
+</svg>
+      </button>
+      <div class="HeaderMenu-dropdown dropdown-menu rounded m-0 p-0 py-2 py-lg-4 position-relative position-lg-absolute left-0 left-lg-n3 px-lg-4">
+          <div class="border-bottom pb-3 mb-3">
+            <ul class="list-style-none f5" >
+                <li>
+  <a class="HeaderMenu-dropdown-link lh-condensed d-block no-underline position-relative py-2 Link--secondary d-flex flex-items-center" data-analytics-event="{&quot;category&quot;:&quot;Header dropdown (logged out), Open Source&quot;,&quot;action&quot;:&quot;click to go to GitHub Sponsors&quot;,&quot;label&quot;:&quot;ref_cta:GitHub Sponsors;&quot;}" href="/sponsors">
+      
+      <div>
+        <div class="color-fg-default h4">GitHub Sponsors</div>
+        Fund open source developers
+      </div>
+
+    
+</a></li>
+
+            </ul>
+          </div>
+          <div class="border-bottom pb-3 mb-3">
+            <ul class="list-style-none f5" >
+                <li>
+  <a class="HeaderMenu-dropdown-link lh-condensed d-block no-underline position-relative py-2 Link--secondary d-flex flex-items-center" data-analytics-event="{&quot;category&quot;:&quot;Header dropdown (logged out), Open Source&quot;,&quot;action&quot;:&quot;click to go to The ReadME Project&quot;,&quot;label&quot;:&quot;ref_cta:The ReadME Project;&quot;}" href="https://github.com/readme">
+      
+      <div>
+        <div class="color-fg-default h4">The ReadME Project</div>
+        GitHub community articles
+      </div>
+
+    
+</a></li>
+
+            </ul>
+          </div>
+          <div class="">
+              <span class="d-block h4 color-fg-default my-1" id="open-source-repositories-heading">Repositories</span>
+            <ul class="list-style-none f5" aria-labelledby="open-source-repositories-heading">
+                <li>
+  <a class="HeaderMenu-dropdown-link lh-condensed d-block no-underline position-relative py-2 Link--secondary" data-analytics-event="{&quot;category&quot;:&quot;Header dropdown (logged out), Open Source&quot;,&quot;action&quot;:&quot;click to go to Topics&quot;,&quot;label&quot;:&quot;ref_cta:Topics;&quot;}" href="https://github.com/topics">
+      Topics
+
+    
+</a></li>
+
+                <li>
+  <a class="HeaderMenu-dropdown-link lh-condensed d-block no-underline position-relative py-2 Link--secondary" data-analytics-event="{&quot;category&quot;:&quot;Header dropdown (logged out), Open Source&quot;,&quot;action&quot;:&quot;click to go to Trending&quot;,&quot;label&quot;:&quot;ref_cta:Trending;&quot;}" href="https://github.com/trending">
+      Trending
+
+    
+</a></li>
+
+                <li>
+  <a class="HeaderMenu-dropdown-link lh-condensed d-block no-underline position-relative py-2 Link--secondary" data-analytics-event="{&quot;category&quot;:&quot;Header dropdown (logged out), Open Source&quot;,&quot;action&quot;:&quot;click to go to Collections&quot;,&quot;label&quot;:&quot;ref_cta:Collections;&quot;}" href="https://github.com/collections">
+      Collections
+
+    
+</a></li>
+
+            </ul>
+          </div>
+      </div>
+</li>
+
+
+                <li class="HeaderMenu-item position-relative flex-wrap flex-justify-between flex-items-center d-block d-lg-flex flex-lg-nowrap flex-lg-items-center js-details-container js-header-menu-item">
+      <button type="button" class="HeaderMenu-link border-0 width-full width-lg-auto px-0 px-lg-2 py-3 py-lg-2 no-wrap d-flex flex-items-center flex-justify-between js-details-target" aria-expanded="false">
+        Enterprise
+        <svg opacity="0.5" aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-chevron-down HeaderMenu-icon ml-1">
+    <path d="M12.78 5.22a.749.749 0 0 1 0 1.06l-4.25 4.25a.749.749 0 0 1-1.06 0L3.22 6.28a.749.749 0 1 1 1.06-1.06L8 8.939l3.72-3.719a.749.749 0 0 1 1.06 0Z"></path>
+</svg>
+      </button>
+      <div class="HeaderMenu-dropdown dropdown-menu rounded m-0 p-0 py-2 py-lg-4 position-relative position-lg-absolute left-0 left-lg-n3 px-lg-4">
+          <div class="border-bottom pb-3 mb-3">
+            <ul class="list-style-none f5" >
+                <li>
+  <a class="HeaderMenu-dropdown-link lh-condensed d-block no-underline position-relative py-2 Link--secondary d-flex flex-items-center" data-analytics-event="{&quot;category&quot;:&quot;Header dropdown (logged out), Enterprise&quot;,&quot;action&quot;:&quot;click to go to Enterprise platform&quot;,&quot;label&quot;:&quot;ref_cta:Enterprise platform;&quot;}" href="/enterprise">
+      <svg aria-hidden="true" height="24" viewBox="0 0 24 24" version="1.1" width="24" data-view-component="true" class="octicon octicon-stack color-fg-subtle mr-3">
+    <path d="M11.063 1.456a1.749 1.749 0 0 1 1.874 0l8.383 5.316a1.751 1.751 0 0 1 0 2.956l-8.383 5.316a1.749 1.749 0 0 1-1.874 0L2.68 9.728a1.751 1.751 0 0 1 0-2.956Zm1.071 1.267a.25.25 0 0 0-.268 0L3.483 8.039a.25.25 0 0 0 0 .422l8.383 5.316a.25.25 0 0 0 .268 0l8.383-5.316a.25.25 0 0 0 0-.422Z"></path><path d="M1.867 12.324a.75.75 0 0 1 1.035-.232l8.964 5.685a.25.25 0 0 0 .268 0l8.964-5.685a.75.75 0 0 1 .804 1.267l-8.965 5.685a1.749 1.749 0 0 1-1.874 0l-8.965-5.685a.75.75 0 0 1-.231-1.035Z"></path><path d="M1.867 16.324a.75.75 0 0 1 1.035-.232l8.964 5.685a.25.25 0 0 0 .268 0l8.964-5.685a.75.75 0 0 1 .804 1.267l-8.965 5.685a1.749 1.749 0 0 1-1.874 0l-8.965-5.685a.75.75 0 0 1-.231-1.035Z"></path>
+</svg>
+      <div>
+        <div class="color-fg-default h4">Enterprise platform</div>
+        AI-powered developer platform
+      </div>
+
+    
+</a></li>
+
+            </ul>
+          </div>
+          <div class="">
+              <span class="d-block h4 color-fg-default my-1" id="enterprise-available-add-ons-heading">Available add-ons</span>
+            <ul class="list-style-none f5" aria-labelledby="enterprise-available-add-ons-heading">
+                <li>
+  <a class="HeaderMenu-dropdown-link lh-condensed d-block no-underline position-relative py-2 Link--secondary d-flex flex-items-center pb-lg-3" data-analytics-event="{&quot;category&quot;:&quot;Header dropdown (logged out), Enterprise&quot;,&quot;action&quot;:&quot;click to go to Advanced Security&quot;,&quot;label&quot;:&quot;ref_cta:Advanced Security;&quot;}" href="https://github.com/enterprise/advanced-security">
+      <svg aria-hidden="true" height="24" viewBox="0 0 24 24" version="1.1" width="24" data-view-component="true" class="octicon octicon-shield-check color-fg-subtle mr-3">
+    <path d="M16.53 9.78a.75.75 0 0 0-1.06-1.06L11 13.19l-1.97-1.97a.75.75 0 0 0-1.06 1.06l2.5 2.5a.75.75 0 0 0 1.06 0l5-5Z"></path><path d="m12.54.637 8.25 2.675A1.75 1.75 0 0 1 22 4.976V10c0 6.19-3.771 10.704-9.401 12.83a1.704 1.704 0 0 1-1.198 0C5.77 20.705 2 16.19 2 10V4.976c0-.758.489-1.43 1.21-1.664L11.46.637a1.748 1.748 0 0 1 1.08 0Zm-.617 1.426-8.25 2.676a.249.249 0 0 0-.173.237V10c0 5.46 3.28 9.483 8.43 11.426a.199.199 0 0 0 .14 0C17.22 19.483 20.5 15.461 20.5 10V4.976a.25.25 0 0 0-.173-.237l-8.25-2.676a.253.253 0 0 0-.154 0Z"></path>
+</svg>
+      <div>
+        <div class="color-fg-default h4">Advanced Security</div>
+        Enterprise-grade security features
+      </div>
+
+    
+</a></li>
+
+                <li>
+  <a class="HeaderMenu-dropdown-link lh-condensed d-block no-underline position-relative py-2 Link--secondary d-flex flex-items-center pb-lg-3" data-analytics-event="{&quot;category&quot;:&quot;Header dropdown (logged out), Enterprise&quot;,&quot;action&quot;:&quot;click to go to GitHub Copilot&quot;,&quot;label&quot;:&quot;ref_cta:GitHub Copilot;&quot;}" href="/features/copilot#enterprise">
+      <svg aria-hidden="true" height="24" viewBox="0 0 24 24" version="1.1" width="24" data-view-component="true" class="octicon octicon-copilot color-fg-subtle mr-3">
+    <path d="M23.922 16.992c-.861 1.495-5.859 5.023-11.922 5.023-6.063 0-11.061-3.528-11.922-5.023A.641.641 0 0 1 0 16.736v-2.869a.841.841 0 0 1 .053-.22c.372-.935 1.347-2.292 2.605-2.656.167-.429.414-1.055.644-1.517a10.195 10.195 0 0 1-.052-1.086c0-1.331.282-2.499 1.132-3.368.397-.406.89-.717 1.474-.952 1.399-1.136 3.392-2.093 6.122-2.093 2.731 0 4.767.957 6.166 2.093.584.235 1.077.546 1.474.952.85.869 1.132 2.037 1.132 3.368 0 .368-.014.733-.052 1.086.23.462.477 1.088.644 1.517 1.258.364 2.233 1.721 2.605 2.656a.832.832 0 0 1 .053.22v2.869a.641.641 0 0 1-.078.256ZM12.172 11h-.344a4.323 4.323 0 0 1-.355.508C10.703 12.455 9.555 13 7.965 13c-1.725 0-2.989-.359-3.782-1.259a2.005 2.005 0 0 1-.085-.104L4 11.741v6.585c1.435.779 4.514 2.179 8 2.179 3.486 0 6.565-1.4 8-2.179v-6.585l-.098-.104s-.033.045-.085.104c-.793.9-2.057 1.259-3.782 1.259-1.59 0-2.738-.545-3.508-1.492a4.323 4.323 0 0 1-.355-.508h-.016.016Zm.641-2.935c.136 1.057.403 1.913.878 2.497.442.544 1.134.938 2.344.938 1.573 0 2.292-.337 2.657-.751.384-.435.558-1.15.558-2.361 0-1.14-.243-1.847-.705-2.319-.477-.488-1.319-.862-2.824-1.025-1.487-.161-2.192.138-2.533.529-.269.307-.437.808-.438 1.578v.021c0 .265.021.562.063.893Zm-1.626 0c.042-.331.063-.628.063-.894v-.02c-.001-.77-.169-1.271-.438-1.578-.341-.391-1.046-.69-2.533-.529-1.505.163-2.347.537-2.824 1.025-.462.472-.705 1.179-.705 2.319 0 1.211.175 1.926.558 2.361.365.414 1.084.751 2.657.751 1.21 0 1.902-.394 2.344-.938.475-.584.742-1.44.878-2.497Z"></path><path d="M14.5 14.25a1 1 0 0 1 1 1v2a1 1 0 0 1-2 0v-2a1 1 0 0 1 1-1Zm-5 0a1 1 0 0 1 1 1v2a1 1 0 0 1-2 0v-2a1 1 0 0 1 1-1Z"></path>
+</svg>
+      <div>
+        <div class="color-fg-default h4">GitHub Copilot</div>
+        Enterprise-grade AI features
+      </div>
+
+    
+</a></li>
+
+                <li>
+  <a class="HeaderMenu-dropdown-link lh-condensed d-block no-underline position-relative py-2 Link--secondary d-flex flex-items-center" data-analytics-event="{&quot;category&quot;:&quot;Header dropdown (logged out), Enterprise&quot;,&quot;action&quot;:&quot;click to go to Premium Support&quot;,&quot;label&quot;:&quot;ref_cta:Premium Support;&quot;}" href="/premium-support">
+      <svg aria-hidden="true" height="24" viewBox="0 0 24 24" version="1.1" width="24" data-view-component="true" class="octicon octicon-comment-discussion color-fg-subtle mr-3">
+    <path d="M1.75 1h12.5c.966 0 1.75.784 1.75 1.75v9.5A1.75 1.75 0 0 1 14.25 14H8.061l-2.574 2.573A1.458 1.458 0 0 1 3 15.543V14H1.75A1.75 1.75 0 0 1 0 12.25v-9.5C0 1.784.784 1 1.75 1ZM1.5 2.75v9.5c0 .138.112.25.25.25h2a.75.75 0 0 1 .75.75v2.19l2.72-2.72a.749.749 0 0 1 .53-.22h6.5a.25.25 0 0 0 .25-.25v-9.5a.25.25 0 0 0-.25-.25H1.75a.25.25 0 0 0-.25.25Z"></path><path d="M22.5 8.75a.25.25 0 0 0-.25-.25h-3.5a.75.75 0 0 1 0-1.5h3.5c.966 0 1.75.784 1.75 1.75v9.5A1.75 1.75 0 0 1 22.25 20H21v1.543a1.457 1.457 0 0 1-2.487 1.03L15.939 20H10.75A1.75 1.75 0 0 1 9 18.25v-1.465a.75.75 0 0 1 1.5 0v1.465c0 .138.112.25.25.25h5.5a.75.75 0 0 1 .53.22l2.72 2.72v-2.19a.75.75 0 0 1 .75-.75h2a.25.25 0 0 0 .25-.25v-9.5Z"></path>
+</svg>
+      <div>
+        <div class="color-fg-default h4">Premium Support</div>
+        Enterprise-grade 24/7 support
+      </div>
+
+    
+</a></li>
+
+            </ul>
+          </div>
+      </div>
+</li>
+
+
+                <li class="HeaderMenu-item position-relative flex-wrap flex-justify-between flex-items-center d-block d-lg-flex flex-lg-nowrap flex-lg-items-center js-details-container js-header-menu-item">
+    <a class="HeaderMenu-link no-underline px-0 px-lg-2 py-3 py-lg-2 d-block d-lg-inline-block" data-analytics-event="{&quot;category&quot;:&quot;Header menu top item (logged out)&quot;,&quot;action&quot;:&quot;click to go to Pricing&quot;,&quot;label&quot;:&quot;ref_cta:Pricing;&quot;}" href="https://github.com/pricing">Pricing</a>
+</li>
+
+            </ul>
+          </nav>
+
+        <div class="d-lg-flex flex-items-center mb-3 mb-lg-0 text-center text-lg-left ml-3" style="">
+                
+
+
+<qbsearch-input class="search-input" data-scope="repo:YunaiV/mybatis-spring" data-custom-scopes-path="/search/custom_scopes" data-delete-custom-scopes-csrf="5vHYp8limV4jxGe3lFI_ka7hDAKNsuSAptWhe7vAZOiP4Py_wZM4HgQOLs0l7wIUaj0q4u6NHwlw1WaVGInKHQ" data-max-custom-scopes="10" data-header-redesign-enabled="false" data-initial-value="" data-blackbird-suggestions-path="/search/suggestions" data-jump-to-suggestions-path="/_graphql/GetSuggestedNavigationDestinations" data-current-repository="YunaiV/mybatis-spring" data-current-org="" data-current-owner="YunaiV" data-logged-in="false" data-copilot-chat-enabled="false" data-blackbird-indexed-repo-csrf="<esi:include src=&quot;/_esi/rails_csrf_token_form_hidden?r=H8NRZxtXbjhNHLWjV%2BDBNTn5pfMsdp%2B5tXze4bZYnwVsuAt5x0lRFgGMLC2HD8wGDPRkxVwTikgGl7bylyU7OSaXPWmKuIaw%2BQdaotwD1223vIN5hgMjPDP4MnbIafIwirIb0NkUp6yEwmyxkQT7%2BPPgSFfQTHZtbvxC%2F4cnvxZVdcKfEK2Oa1YXLmp7qK3uyGLVnPv9eXVVkS7nYHAqYOcH5otpSSc%2FxBHdZZkPurP27CCO8N4ED6Qc0ap33ZmJaJ1k8MbkjT4EtDsAXXXohh07OCM7kcNJCqqsXzpCzecoWuXGpfCH4sjoXGWFzfX98MiBj9TNhjEfWrno6t%2FXh8h2MVLFSVnWN3%2BNhV6M0XmZBT5mkfPffxQXx40zbZdW8UCYf3kaH3Or50CnmoWCnyDKXSqrm2%2BZDXzb23LDh66qY8qUOt5Jnww2IY0yqTXWF4vlPj7o%2B%2BePhLL1iUgqwvIm6NcwUHKZuopinB8l1pLtYB2%2BMs%2FaK0wTs4s8IPupsifYlr9hA8tF0RHeWOTQ502H1v1v62larGtrj7dRqw0ImNAT7yQnmgzwdpqKnzVVgxOgeFmB6dzMmqut%2BJFBV4GoZyLDfLk9Iy6XSspV81%2BWy%2BHQBTo%2FfcrPGG1qh9rfEh2R3fnsZmLxAatTT2jSkVIY--bDMyFNtqzSrhLKve--iuIrG0elbiAxKjpO%2B6whjQ%3D%3D&quot; />">
+  <div
+    class="search-input-container search-with-dialog position-relative d-flex flex-row flex-items-center mr-4 rounded"
+    data-action="click:qbsearch-input#searchInputContainerClicked"
+  >
+      <button
+        type="button"
+        class="header-search-button placeholder  input-button form-control d-flex flex-1 flex-self-stretch flex-items-center no-wrap width-full py-0 pl-2 pr-0 text-left border-0 box-shadow-none"
+        data-target="qbsearch-input.inputButton"
+        placeholder="Search or jump to..."
+        data-hotkey=s,/
+        autocapitalize="off"
+        data-action="click:qbsearch-input#handleExpand"
+      >
+        <div class="mr-2 color-fg-muted">
+          <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-search">
+    <path d="M10.68 11.74a6 6 0 0 1-7.922-8.982 6 6 0 0 1 8.982 7.922l3.04 3.04a.749.749 0 0 1-.326 1.275.749.749 0 0 1-.734-.215ZM11.5 7a4.499 4.499 0 1 0-8.997 0A4.499 4.499 0 0 0 11.5 7Z"></path>
+</svg>
+        </div>
+        <span class="flex-1" data-target="qbsearch-input.inputButtonText">Search or jump to...</span>
+          <div class="d-flex" data-target="qbsearch-input.hotkeyIndicator">
+            <svg xmlns="http://www.w3.org/2000/svg" width="22" height="20" aria-hidden="true" class="mr-1"><path fill="none" stroke="#979A9C" opacity=".4" d="M3.5.5h12c1.7 0 3 1.3 3 3v13c0 1.7-1.3 3-3 3h-12c-1.7 0-3-1.3-3-3v-13c0-1.7 1.3-3 3-3z"></path><path fill="#979A9C" d="M11.8 6L8 15.1h-.9L10.8 6h1z"></path></svg>
+
+          </div>
+      </button>
+
+    <input type="hidden" name="type" class="js-site-search-type-field">
+
+    
+<div class="Overlay--hidden " data-modal-dialog-overlay>
+  <modal-dialog data-action="close:qbsearch-input#handleClose cancel:qbsearch-input#handleClose" data-target="qbsearch-input.searchSuggestionsDialog" role="dialog" id="search-suggestions-dialog" aria-modal="true" aria-labelledby="search-suggestions-dialog-header" data-view-component="true" class="Overlay Overlay--width-large Overlay--height-auto">
+      <h1 id="search-suggestions-dialog-header" class="sr-only">Search code, repositories, users, issues, pull requests...</h1>
+    <div class="Overlay-body Overlay-body--paddingNone">
+      
+          <div data-view-component="true">        <div class="search-suggestions position-fixed width-full color-shadow-large border color-fg-default color-bg-default overflow-hidden d-flex flex-column query-builder-container"
+          style="border-radius: 12px;"
+          data-target="qbsearch-input.queryBuilderContainer"
+          hidden
+        >
+          <!-- '"` --><!-- </textarea></xmp> --></option></form><form id="query-builder-test-form" action="" accept-charset="UTF-8" method="get">
+  <query-builder data-target="qbsearch-input.queryBuilder" id="query-builder-query-builder-test" data-filter-key=":" data-view-component="true" class="QueryBuilder search-query-builder">
+    <div class="FormControl FormControl--fullWidth">
+      <label id="query-builder-test-label" for="query-builder-test" class="FormControl-label sr-only">
+        Search
+      </label>
+      <div
+        class="QueryBuilder-StyledInput width-fit "
+        data-target="query-builder.styledInput"
+      >
+          <span id="query-builder-test-leadingvisual-wrap" class="FormControl-input-leadingVisualWrap QueryBuilder-leadingVisualWrap">
+            <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-search FormControl-input-leadingVisual">
+    <path d="M10.68 11.74a6 6 0 0 1-7.922-8.982 6 6 0 0 1 8.982 7.922l3.04 3.04a.749.749 0 0 1-.326 1.275.749.749 0 0 1-.734-.215ZM11.5 7a4.499 4.499 0 1 0-8.997 0A4.499 4.499 0 0 0 11.5 7Z"></path>
+</svg>
+          </span>
+        <div data-target="query-builder.styledInputContainer" class="QueryBuilder-StyledInputContainer">
+          <div
+            aria-hidden="true"
+            class="QueryBuilder-StyledInputContent"
+            data-target="query-builder.styledInputContent"
+          ></div>
+          <div class="QueryBuilder-InputWrapper">
+            <div aria-hidden="true" class="QueryBuilder-Sizer" data-target="query-builder.sizer"></div>
+            <input id="query-builder-test" name="query-builder-test" value="" autocomplete="off" type="text" role="combobox" spellcheck="false" aria-expanded="false" aria-describedby="validation-d218889b-1c0f-4cd9-8101-38df4de512d5" data-target="query-builder.input" data-action="
+          input:query-builder#inputChange
+          blur:query-builder#inputBlur
+          keydown:query-builder#inputKeydown
+          focus:query-builder#inputFocus
+        " data-view-component="true" class="FormControl-input QueryBuilder-Input FormControl-medium" />
+          </div>
+        </div>
+          <span class="sr-only" id="query-builder-test-clear">Clear</span>
+          <button role="button" id="query-builder-test-clear-button" aria-labelledby="query-builder-test-clear query-builder-test-label" data-target="query-builder.clearButton" data-action="
+                click:query-builder#clear
+                focus:query-builder#clearButtonFocus
+                blur:query-builder#clearButtonBlur
+              " variant="small" hidden="hidden" type="button" data-view-component="true" class="Button Button--iconOnly Button--invisible Button--medium mr-1 px-2 py-0 d-flex flex-items-center rounded-1 color-fg-muted">  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-x-circle-fill Button-visual">
+    <path d="M2.343 13.657A8 8 0 1 1 13.658 2.343 8 8 0 0 1 2.343 13.657ZM6.03 4.97a.751.751 0 0 0-1.042.018.751.751 0 0 0-.018 1.042L6.94 8 4.97 9.97a.749.749 0 0 0 .326 1.275.749.749 0 0 0 .734-.215L8 9.06l1.97 1.97a.749.749 0 0 0 1.275-.326.749.749 0 0 0-.215-.734L9.06 8l1.97-1.97a.749.749 0 0 0-.326-1.275.749.749 0 0 0-.734.215L8 6.94Z"></path>
+</svg>
+</button>
+
+      </div>
+      <template id="search-icon">
+  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-search">
+    <path d="M10.68 11.74a6 6 0 0 1-7.922-8.982 6 6 0 0 1 8.982 7.922l3.04 3.04a.749.749 0 0 1-.326 1.275.749.749 0 0 1-.734-.215ZM11.5 7a4.499 4.499 0 1 0-8.997 0A4.499 4.499 0 0 0 11.5 7Z"></path>
+</svg>
+</template>
+
+<template id="code-icon">
+  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-code">
+    <path d="m11.28 3.22 4.25 4.25a.75.75 0 0 1 0 1.06l-4.25 4.25a.749.749 0 0 1-1.275-.326.749.749 0 0 1 .215-.734L13.94 8l-3.72-3.72a.749.749 0 0 1 .326-1.275.749.749 0 0 1 .734.215Zm-6.56 0a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042L2.06 8l3.72 3.72a.749.749 0 0 1-.326 1.275.749.749 0 0 1-.734-.215L.47 8.53a.75.75 0 0 1 0-1.06Z"></path>
+</svg>
+</template>
+
+<template id="file-code-icon">
+  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-file-code">
+    <path d="M4 1.75C4 .784 4.784 0 5.75 0h5.586c.464 0 .909.184 1.237.513l2.914 2.914c.329.328.513.773.513 1.237v8.586A1.75 1.75 0 0 1 14.25 15h-9a.75.75 0 0 1 0-1.5h9a.25.25 0 0 0 .25-.25V6h-2.75A1.75 1.75 0 0 1 10 4.25V1.5H5.75a.25.25 0 0 0-.25.25v2.5a.75.75 0 0 1-1.5 0Zm1.72 4.97a.75.75 0 0 1 1.06 0l2 2a.75.75 0 0 1 0 1.06l-2 2a.749.749 0 0 1-1.275-.326.749.749 0 0 1 .215-.734l1.47-1.47-1.47-1.47a.75.75 0 0 1 0-1.06ZM3.28 7.78 1.81 9.25l1.47 1.47a.751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018l-2-2a.75.75 0 0 1 0-1.06l2-2a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042Zm8.22-6.218V4.25c0 .138.112.25.25.25h2.688l-.011-.013-2.914-2.914-.013-.011Z"></path>
+</svg>
+</template>
+
+<template id="history-icon">
+  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-history">
+    <path d="m.427 1.927 1.215 1.215a8.002 8.002 0 1 1-1.6 5.685.75.75 0 1 1 1.493-.154 6.5 6.5 0 1 0 1.18-4.458l1.358 1.358A.25.25 0 0 1 3.896 6H.25A.25.25 0 0 1 0 5.75V2.104a.25.25 0 0 1 .427-.177ZM7.75 4a.75.75 0 0 1 .75.75v2.992l2.028.812a.75.75 0 0 1-.557 1.392l-2.5-1A.751.751 0 0 1 7 8.25v-3.5A.75.75 0 0 1 7.75 4Z"></path>
+</svg>
+</template>
+
+<template id="repo-icon">
+  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-repo">
+    <path d="M2 2.5A2.5 2.5 0 0 1 4.5 0h8.75a.75.75 0 0 1 .75.75v12.5a.75.75 0 0 1-.75.75h-2.5a.75.75 0 0 1 0-1.5h1.75v-2h-8a1 1 0 0 0-.714 1.7.75.75 0 1 1-1.072 1.05A2.495 2.495 0 0 1 2 11.5Zm10.5-1h-8a1 1 0 0 0-1 1v6.708A2.486 2.486 0 0 1 4.5 9h8ZM5 12.25a.25.25 0 0 1 .25-.25h3.5a.25.25 0 0 1 .25.25v3.25a.25.25 0 0 1-.4.2l-1.45-1.087a.249.249 0 0 0-.3 0L5.4 15.7a.25.25 0 0 1-.4-.2Z"></path>
+</svg>
+</template>
+
+<template id="bookmark-icon">
+  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-bookmark">
+    <path d="M3 2.75C3 1.784 3.784 1 4.75 1h6.5c.966 0 1.75.784 1.75 1.75v11.5a.75.75 0 0 1-1.227.579L8 11.722l-3.773 3.107A.751.751 0 0 1 3 14.25Zm1.75-.25a.25.25 0 0 0-.25.25v9.91l3.023-2.489a.75.75 0 0 1 .954 0l3.023 2.49V2.75a.25.25 0 0 0-.25-.25Z"></path>
+</svg>
+</template>
+
+<template id="plus-circle-icon">
+  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-plus-circle">
+    <path d="M8 0a8 8 0 1 1 0 16A8 8 0 0 1 8 0ZM1.5 8a6.5 6.5 0 1 0 13 0 6.5 6.5 0 0 0-13 0Zm7.25-3.25v2.5h2.5a.75.75 0 0 1 0 1.5h-2.5v2.5a.75.75 0 0 1-1.5 0v-2.5h-2.5a.75.75 0 0 1 0-1.5h2.5v-2.5a.75.75 0 0 1 1.5 0Z"></path>
+</svg>
+</template>
+
+<template id="circle-icon">
+  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-dot-fill">
+    <path d="M8 4a4 4 0 1 1 0 8 4 4 0 0 1 0-8Z"></path>
+</svg>
+</template>
+
+<template id="trash-icon">
+  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-trash">
+    <path d="M11 1.75V3h2.25a.75.75 0 0 1 0 1.5H2.75a.75.75 0 0 1 0-1.5H5V1.75C5 .784 5.784 0 6.75 0h2.5C10.216 0 11 .784 11 1.75ZM4.496 6.675l.66 6.6a.25.25 0 0 0 .249.225h5.19a.25.25 0 0 0 .249-.225l.66-6.6a.75.75 0 0 1 1.492.149l-.66 6.6A1.748 1.748 0 0 1 10.595 15h-5.19a1.75 1.75 0 0 1-1.741-1.575l-.66-6.6a.75.75 0 1 1 1.492-.15ZM6.5 1.75V3h3V1.75a.25.25 0 0 0-.25-.25h-2.5a.25.25 0 0 0-.25.25Z"></path>
+</svg>
+</template>
+
+<template id="team-icon">
+  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-people">
+    <path d="M2 5.5a3.5 3.5 0 1 1 5.898 2.549 5.508 5.508 0 0 1 3.034 4.084.75.75 0 1 1-1.482.235 4 4 0 0 0-7.9 0 .75.75 0 0 1-1.482-.236A5.507 5.507 0 0 1 3.102 8.05 3.493 3.493 0 0 1 2 5.5ZM11 4a3.001 3.001 0 0 1 2.22 5.018 5.01 5.01 0 0 1 2.56 3.012.749.749 0 0 1-.885.954.752.752 0 0 1-.549-.514 3.507 3.507 0 0 0-2.522-2.372.75.75 0 0 1-.574-.73v-.352a.75.75 0 0 1 .416-.672A1.5 1.5 0 0 0 11 5.5.75.75 0 0 1 11 4Zm-5.5-.5a2 2 0 1 0-.001 3.999A2 2 0 0 0 5.5 3.5Z"></path>
+</svg>
+</template>
+
+<template id="project-icon">
+  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-project">
+    <path d="M1.75 0h12.5C15.216 0 16 .784 16 1.75v12.5A1.75 1.75 0 0 1 14.25 16H1.75A1.75 1.75 0 0 1 0 14.25V1.75C0 .784.784 0 1.75 0ZM1.5 1.75v12.5c0 .138.112.25.25.25h12.5a.25.25 0 0 0 .25-.25V1.75a.25.25 0 0 0-.25-.25H1.75a.25.25 0 0 0-.25.25ZM11.75 3a.75.75 0 0 1 .75.75v7.5a.75.75 0 0 1-1.5 0v-7.5a.75.75 0 0 1 .75-.75Zm-8.25.75a.75.75 0 0 1 1.5 0v5.5a.75.75 0 0 1-1.5 0ZM8 3a.75.75 0 0 1 .75.75v3.5a.75.75 0 0 1-1.5 0v-3.5A.75.75 0 0 1 8 3Z"></path>
+</svg>
+</template>
+
+<template id="pencil-icon">
+  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-pencil">
+    <path d="M11.013 1.427a1.75 1.75 0 0 1 2.474 0l1.086 1.086a1.75 1.75 0 0 1 0 2.474l-8.61 8.61c-.21.21-.47.364-.756.445l-3.251.93a.75.75 0 0 1-.927-.928l.929-3.25c.081-.286.235-.547.445-.758l8.61-8.61Zm.176 4.823L9.75 4.81l-6.286 6.287a.253.253 0 0 0-.064.108l-.558 1.953 1.953-.558a.253.253 0 0 0 .108-.064Zm1.238-3.763a.25.25 0 0 0-.354 0L10.811 3.75l1.439 1.44 1.263-1.263a.25.25 0 0 0 0-.354Z"></path>
+</svg>
+</template>
+
+<template id="copilot-icon">
+  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-copilot">
+    <path d="M7.998 15.035c-4.562 0-7.873-2.914-7.998-3.749V9.338c.085-.628.677-1.686 1.588-2.065.013-.07.024-.143.036-.218.029-.183.06-.384.126-.612-.201-.508-.254-1.084-.254-1.656 0-.87.128-1.769.693-2.484.579-.733 1.494-1.124 2.724-1.261 1.206-.134 2.262.034 2.944.765.05.053.096.108.139.165.044-.057.094-.112.143-.165.682-.731 1.738-.899 2.944-.765 1.23.137 2.145.528 2.724 1.261.566.715.693 1.614.693 2.484 0 .572-.053 1.148-.254 1.656.066.228.098.429.126.612.012.076.024.148.037.218.924.385 1.522 1.471 1.591 2.095v1.872c0 .766-3.351 3.795-8.002 3.795Zm0-1.485c2.28 0 4.584-1.11 5.002-1.433V7.862l-.023-.116c-.49.21-1.075.291-1.727.291-1.146 0-2.059-.327-2.71-.991A3.222 3.222 0 0 1 8 6.303a3.24 3.24 0 0 1-.544.743c-.65.664-1.563.991-2.71.991-.652 0-1.236-.081-1.727-.291l-.023.116v4.255c.419.323 2.722 1.433 5.002 1.433ZM6.762 2.83c-.193-.206-.637-.413-1.682-.297-1.019.113-1.479.404-1.713.7-.247.312-.369.789-.369 1.554 0 .793.129 1.171.308 1.371.162.181.519.379 1.442.379.853 0 1.339-.235 1.638-.54.315-.322.527-.827.617-1.553.117-.935-.037-1.395-.241-1.614Zm4.155-.297c-1.044-.116-1.488.091-1.681.297-.204.219-.359.679-.242 1.614.091.726.303 1.231.618 1.553.299.305.784.54 1.638.54.922 0 1.28-.198 1.442-.379.179-.2.308-.578.308-1.371 0-.765-.123-1.242-.37-1.554-.233-.296-.693-.587-1.713-.7Z"></path><path d="M6.25 9.037a.75.75 0 0 1 .75.75v1.501a.75.75 0 0 1-1.5 0V9.787a.75.75 0 0 1 .75-.75Zm4.25.75v1.501a.75.75 0 0 1-1.5 0V9.787a.75.75 0 0 1 1.5 0Z"></path>
+</svg>
+</template>
+
+<template id="workflow-icon">
+  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-workflow">
+    <path d="M0 1.75C0 .784.784 0 1.75 0h3.5C6.216 0 7 .784 7 1.75v3.5A1.75 1.75 0 0 1 5.25 7H4v4a1 1 0 0 0 1 1h4v-1.25C9 9.784 9.784 9 10.75 9h3.5c.966 0 1.75.784 1.75 1.75v3.5A1.75 1.75 0 0 1 14.25 16h-3.5A1.75 1.75 0 0 1 9 14.25v-.75H5A2.5 2.5 0 0 1 2.5 11V7h-.75A1.75 1.75 0 0 1 0 5.25Zm1.75-.25a.25.25 0 0 0-.25.25v3.5c0 .138.112.25.25.25h3.5a.25.25 0 0 0 .25-.25v-3.5a.25.25 0 0 0-.25-.25Zm9 9a.25.25 0 0 0-.25.25v3.5c0 .138.112.25.25.25h3.5a.25.25 0 0 0 .25-.25v-3.5a.25.25 0 0 0-.25-.25Z"></path>
+</svg>
+</template>
+
+<template id="book-icon">
+  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-book">
+    <path d="M0 1.75A.75.75 0 0 1 .75 1h4.253c1.227 0 2.317.59 3 1.501A3.743 3.743 0 0 1 11.006 1h4.245a.75.75 0 0 1 .75.75v10.5a.75.75 0 0 1-.75.75h-4.507a2.25 2.25 0 0 0-1.591.659l-.622.621a.75.75 0 0 1-1.06 0l-.622-.621A2.25 2.25 0 0 0 5.258 13H.75a.75.75 0 0 1-.75-.75Zm7.251 10.324.004-5.073-.002-2.253A2.25 2.25 0 0 0 5.003 2.5H1.5v9h3.757a3.75 3.75 0 0 1 1.994.574ZM8.755 4.75l-.004 7.322a3.752 3.752 0 0 1 1.992-.572H14.5v-9h-3.495a2.25 2.25 0 0 0-2.25 2.25Z"></path>
+</svg>
+</template>
+
+<template id="code-review-icon">
+  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-code-review">
+    <path d="M1.75 1h12.5c.966 0 1.75.784 1.75 1.75v8.5A1.75 1.75 0 0 1 14.25 13H8.061l-2.574 2.573A1.458 1.458 0 0 1 3 14.543V13H1.75A1.75 1.75 0 0 1 0 11.25v-8.5C0 1.784.784 1 1.75 1ZM1.5 2.75v8.5c0 .138.112.25.25.25h2a.75.75 0 0 1 .75.75v2.19l2.72-2.72a.749.749 0 0 1 .53-.22h6.5a.25.25 0 0 0 .25-.25v-8.5a.25.25 0 0 0-.25-.25H1.75a.25.25 0 0 0-.25.25Zm5.28 1.72a.75.75 0 0 1 0 1.06L5.31 7l1.47 1.47a.751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018l-2-2a.75.75 0 0 1 0-1.06l2-2a.75.75 0 0 1 1.06 0Zm2.44 0a.75.75 0 0 1 1.06 0l2 2a.75.75 0 0 1 0 1.06l-2 2a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042L10.69 7 9.22 5.53a.75.75 0 0 1 0-1.06Z"></path>
+</svg>
+</template>
+
+<template id="codespaces-icon">
+  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-codespaces">
+    <path d="M0 11.25c0-.966.784-1.75 1.75-1.75h12.5c.966 0 1.75.784 1.75 1.75v3A1.75 1.75 0 0 1 14.25 16H1.75A1.75 1.75 0 0 1 0 14.25Zm2-9.5C2 .784 2.784 0 3.75 0h8.5C13.216 0 14 .784 14 1.75v5a1.75 1.75 0 0 1-1.75 1.75h-8.5A1.75 1.75 0 0 1 2 6.75Zm1.75-.25a.25.25 0 0 0-.25.25v5c0 .138.112.25.25.25h8.5a.25.25 0 0 0 .25-.25v-5a.25.25 0 0 0-.25-.25Zm-2 9.5a.25.25 0 0 0-.25.25v3c0 .138.112.25.25.25h12.5a.25.25 0 0 0 .25-.25v-3a.25.25 0 0 0-.25-.25Z"></path><path d="M7 12.75a.75.75 0 0 1 .75-.75h4.5a.75.75 0 0 1 0 1.5h-4.5a.75.75 0 0 1-.75-.75Zm-4 0a.75.75 0 0 1 .75-.75h.5a.75.75 0 0 1 0 1.5h-.5a.75.75 0 0 1-.75-.75Z"></path>
+</svg>
+</template>
+
+<template id="comment-icon">
+  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-comment">
+    <path d="M1 2.75C1 1.784 1.784 1 2.75 1h10.5c.966 0 1.75.784 1.75 1.75v7.5A1.75 1.75 0 0 1 13.25 12H9.06l-2.573 2.573A1.458 1.458 0 0 1 4 13.543V12H2.75A1.75 1.75 0 0 1 1 10.25Zm1.75-.25a.25.25 0 0 0-.25.25v7.5c0 .138.112.25.25.25h2a.75.75 0 0 1 .75.75v2.19l2.72-2.72a.749.749 0 0 1 .53-.22h4.5a.25.25 0 0 0 .25-.25v-7.5a.25.25 0 0 0-.25-.25Z"></path>
+</svg>
+</template>
+
+<template id="comment-discussion-icon">
+  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-comment-discussion">
+    <path d="M1.75 1h8.5c.966 0 1.75.784 1.75 1.75v5.5A1.75 1.75 0 0 1 10.25 10H7.061l-2.574 2.573A1.458 1.458 0 0 1 2 11.543V10h-.25A1.75 1.75 0 0 1 0 8.25v-5.5C0 1.784.784 1 1.75 1ZM1.5 2.75v5.5c0 .138.112.25.25.25h1a.75.75 0 0 1 .75.75v2.19l2.72-2.72a.749.749 0 0 1 .53-.22h3.5a.25.25 0 0 0 .25-.25v-5.5a.25.25 0 0 0-.25-.25h-8.5a.25.25 0 0 0-.25.25Zm13 2a.25.25 0 0 0-.25-.25h-.5a.75.75 0 0 1 0-1.5h.5c.966 0 1.75.784 1.75 1.75v5.5A1.75 1.75 0 0 1 14.25 12H14v1.543a1.458 1.458 0 0 1-2.487 1.03L9.22 12.28a.749.749 0 0 1 .326-1.275.749.749 0 0 1 .734.215l2.22 2.22v-2.19a.75.75 0 0 1 .75-.75h1a.25.25 0 0 0 .25-.25Z"></path>
+</svg>
+</template>
+
+<template id="organization-icon">
+  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-organization">
+    <path d="M1.75 16A1.75 1.75 0 0 1 0 14.25V1.75C0 .784.784 0 1.75 0h8.5C11.216 0 12 .784 12 1.75v12.5c0 .085-.006.168-.018.25h2.268a.25.25 0 0 0 .25-.25V8.285a.25.25 0 0 0-.111-.208l-1.055-.703a.749.749 0 1 1 .832-1.248l1.055.703c.487.325.779.871.779 1.456v5.965A1.75 1.75 0 0 1 14.25 16h-3.5a.766.766 0 0 1-.197-.026c-.099.017-.2.026-.303.026h-3a.75.75 0 0 1-.75-.75V14h-1v1.25a.75.75 0 0 1-.75.75Zm-.25-1.75c0 .138.112.25.25.25H4v-1.25a.75.75 0 0 1 .75-.75h2.5a.75.75 0 0 1 .75.75v1.25h2.25a.25.25 0 0 0 .25-.25V1.75a.25.25 0 0 0-.25-.25h-8.5a.25.25 0 0 0-.25.25ZM3.75 6h.5a.75.75 0 0 1 0 1.5h-.5a.75.75 0 0 1 0-1.5ZM3 3.75A.75.75 0 0 1 3.75 3h.5a.75.75 0 0 1 0 1.5h-.5A.75.75 0 0 1 3 3.75Zm4 3A.75.75 0 0 1 7.75 6h.5a.75.75 0 0 1 0 1.5h-.5A.75.75 0 0 1 7 6.75ZM7.75 3h.5a.75.75 0 0 1 0 1.5h-.5a.75.75 0 0 1 0-1.5ZM3 9.75A.75.75 0 0 1 3.75 9h.5a.75.75 0 0 1 0 1.5h-.5A.75.75 0 0 1 3 9.75ZM7.75 9h.5a.75.75 0 0 1 0 1.5h-.5a.75.75 0 0 1 0-1.5Z"></path>
+</svg>
+</template>
+
+<template id="rocket-icon">
+  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-rocket">
+    <path d="M14.064 0h.186C15.216 0 16 .784 16 1.75v.186a8.752 8.752 0 0 1-2.564 6.186l-.458.459c-.314.314-.641.616-.979.904v3.207c0 .608-.315 1.172-.833 1.49l-2.774 1.707a.749.749 0 0 1-1.11-.418l-.954-3.102a1.214 1.214 0 0 1-.145-.125L3.754 9.816a1.218 1.218 0 0 1-.124-.145L.528 8.717a.749.749 0 0 1-.418-1.11l1.71-2.774A1.748 1.748 0 0 1 3.31 4h3.204c.288-.338.59-.665.904-.979l.459-.458A8.749 8.749 0 0 1 14.064 0ZM8.938 3.623h-.002l-.458.458c-.76.76-1.437 1.598-2.02 2.5l-1.5 2.317 2.143 2.143 2.317-1.5c.902-.583 1.74-1.26 2.499-2.02l.459-.458a7.25 7.25 0 0 0 2.123-5.127V1.75a.25.25 0 0 0-.25-.25h-.186a7.249 7.249 0 0 0-5.125 2.123ZM3.56 14.56c-.732.732-2.334 1.045-3.005 1.148a.234.234 0 0 1-.201-.064.234.234 0 0 1-.064-.201c.103-.671.416-2.273 1.15-3.003a1.502 1.502 0 1 1 2.12 2.12Zm6.94-3.935c-.088.06-.177.118-.266.175l-2.35 1.521.548 1.783 1.949-1.2a.25.25 0 0 0 .119-.213ZM3.678 8.116 5.2 5.766c.058-.09.117-.178.176-.266H3.309a.25.25 0 0 0-.213.119l-1.2 1.95ZM12 5a1 1 0 1 1-2 0 1 1 0 0 1 2 0Z"></path>
+</svg>
+</template>
+
+<template id="shield-check-icon">
+  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-shield-check">
+    <path d="m8.533.133 5.25 1.68A1.75 1.75 0 0 1 15 3.48V7c0 1.566-.32 3.182-1.303 4.682-.983 1.498-2.585 2.813-5.032 3.855a1.697 1.697 0 0 1-1.33 0c-2.447-1.042-4.049-2.357-5.032-3.855C1.32 10.182 1 8.566 1 7V3.48a1.75 1.75 0 0 1 1.217-1.667l5.25-1.68a1.748 1.748 0 0 1 1.066 0Zm-.61 1.429.001.001-5.25 1.68a.251.251 0 0 0-.174.237V7c0 1.36.275 2.666 1.057 3.859.784 1.194 2.121 2.342 4.366 3.298a.196.196 0 0 0 .154 0c2.245-.957 3.582-2.103 4.366-3.297C13.225 9.666 13.5 8.358 13.5 7V3.48a.25.25 0 0 0-.174-.238l-5.25-1.68a.25.25 0 0 0-.153 0ZM11.28 6.28l-3.5 3.5a.75.75 0 0 1-1.06 0l-1.5-1.5a.749.749 0 0 1 .326-1.275.749.749 0 0 1 .734.215l.97.97 2.97-2.97a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042Z"></path>
+</svg>
+</template>
+
+<template id="heart-icon">
+  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-heart">
+    <path d="m8 14.25.345.666a.75.75 0 0 1-.69 0l-.008-.004-.018-.01a7.152 7.152 0 0 1-.31-.17 22.055 22.055 0 0 1-3.434-2.414C2.045 10.731 0 8.35 0 5.5 0 2.836 2.086 1 4.25 1 5.797 1 7.153 1.802 8 3.02 8.847 1.802 10.203 1 11.75 1 13.914 1 16 2.836 16 5.5c0 2.85-2.045 5.231-3.885 6.818a22.066 22.066 0 0 1-3.744 2.584l-.018.01-.006.003h-.002ZM4.25 2.5c-1.336 0-2.75 1.164-2.75 3 0 2.15 1.58 4.144 3.365 5.682A20.58 20.58 0 0 0 8 13.393a20.58 20.58 0 0 0 3.135-2.211C12.92 9.644 14.5 7.65 14.5 5.5c0-1.836-1.414-3-2.75-3-1.373 0-2.609.986-3.029 2.456a.749.749 0 0 1-1.442 0C6.859 3.486 5.623 2.5 4.25 2.5Z"></path>
+</svg>
+</template>
+
+<template id="server-icon">
+  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-server">
+    <path d="M1.75 1h12.5c.966 0 1.75.784 1.75 1.75v4c0 .372-.116.717-.314 1 .198.283.314.628.314 1v4a1.75 1.75 0 0 1-1.75 1.75H1.75A1.75 1.75 0 0 1 0 12.75v-4c0-.358.109-.707.314-1a1.739 1.739 0 0 1-.314-1v-4C0 1.784.784 1 1.75 1ZM1.5 2.75v4c0 .138.112.25.25.25h12.5a.25.25 0 0 0 .25-.25v-4a.25.25 0 0 0-.25-.25H1.75a.25.25 0 0 0-.25.25Zm.25 5.75a.25.25 0 0 0-.25.25v4c0 .138.112.25.25.25h12.5a.25.25 0 0 0 .25-.25v-4a.25.25 0 0 0-.25-.25ZM7 4.75A.75.75 0 0 1 7.75 4h4.5a.75.75 0 0 1 0 1.5h-4.5A.75.75 0 0 1 7 4.75ZM7.75 10h4.5a.75.75 0 0 1 0 1.5h-4.5a.75.75 0 0 1 0-1.5ZM3 4.75A.75.75 0 0 1 3.75 4h.5a.75.75 0 0 1 0 1.5h-.5A.75.75 0 0 1 3 4.75ZM3.75 10h.5a.75.75 0 0 1 0 1.5h-.5a.75.75 0 0 1 0-1.5Z"></path>
+</svg>
+</template>
+
+<template id="globe-icon">
+  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-globe">
+    <path d="M8 0a8 8 0 1 1 0 16A8 8 0 0 1 8 0ZM5.78 8.75a9.64 9.64 0 0 0 1.363 4.177c.255.426.542.832.857 1.215.245-.296.551-.705.857-1.215A9.64 9.64 0 0 0 10.22 8.75Zm4.44-1.5a9.64 9.64 0 0 0-1.363-4.177c-.307-.51-.612-.919-.857-1.215a9.927 9.927 0 0 0-.857 1.215A9.64 9.64 0 0 0 5.78 7.25Zm-5.944 1.5H1.543a6.507 6.507 0 0 0 4.666 5.5c-.123-.181-.24-.365-.352-.552-.715-1.192-1.437-2.874-1.581-4.948Zm-2.733-1.5h2.733c.144-2.074.866-3.756 1.58-4.948.12-.197.237-.381.353-.552a6.507 6.507 0 0 0-4.666 5.5Zm10.181 1.5c-.144 2.074-.866 3.756-1.58 4.948-.12.197-.237.381-.353.552a6.507 6.507 0 0 0 4.666-5.5Zm2.733-1.5a6.507 6.507 0 0 0-4.666-5.5c.123.181.24.365.353.552.714 1.192 1.436 2.874 1.58 4.948Z"></path>
+</svg>
+</template>
+
+<template id="issue-opened-icon">
+  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-issue-opened">
+    <path d="M8 9.5a1.5 1.5 0 1 0 0-3 1.5 1.5 0 0 0 0 3Z"></path><path d="M8 0a8 8 0 1 1 0 16A8 8 0 0 1 8 0ZM1.5 8a6.5 6.5 0 1 0 13 0 6.5 6.5 0 0 0-13 0Z"></path>
+</svg>
+</template>
+
+<template id="device-mobile-icon">
+  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-device-mobile">
+    <path d="M3.75 0h8.5C13.216 0 14 .784 14 1.75v12.5A1.75 1.75 0 0 1 12.25 16h-8.5A1.75 1.75 0 0 1 2 14.25V1.75C2 .784 2.784 0 3.75 0ZM3.5 1.75v12.5c0 .138.112.25.25.25h8.5a.25.25 0 0 0 .25-.25V1.75a.25.25 0 0 0-.25-.25h-8.5a.25.25 0 0 0-.25.25ZM8 13a1 1 0 1 1 0-2 1 1 0 0 1 0 2Z"></path>
+</svg>
+</template>
+
+<template id="package-icon">
+  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-package">
+    <path d="m8.878.392 5.25 3.045c.54.314.872.89.872 1.514v6.098a1.75 1.75 0 0 1-.872 1.514l-5.25 3.045a1.75 1.75 0 0 1-1.756 0l-5.25-3.045A1.75 1.75 0 0 1 1 11.049V4.951c0-.624.332-1.201.872-1.514L7.122.392a1.75 1.75 0 0 1 1.756 0ZM7.875 1.69l-4.63 2.685L8 7.133l4.755-2.758-4.63-2.685a.248.248 0 0 0-.25 0ZM2.5 5.677v5.372c0 .09.047.171.125.216l4.625 2.683V8.432Zm6.25 8.271 4.625-2.683a.25.25 0 0 0 .125-.216V5.677L8.75 8.432Z"></path>
+</svg>
+</template>
+
+<template id="credit-card-icon">
+  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-credit-card">
+    <path d="M10.75 9a.75.75 0 0 0 0 1.5h1.5a.75.75 0 0 0 0-1.5h-1.5Z"></path><path d="M0 3.75C0 2.784.784 2 1.75 2h12.5c.966 0 1.75.784 1.75 1.75v8.5A1.75 1.75 0 0 1 14.25 14H1.75A1.75 1.75 0 0 1 0 12.25ZM14.5 6.5h-13v5.75c0 .138.112.25.25.25h12.5a.25.25 0 0 0 .25-.25Zm0-2.75a.25.25 0 0 0-.25-.25H1.75a.25.25 0 0 0-.25.25V5h13Z"></path>
+</svg>
+</template>
+
+<template id="play-icon">
+  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-play">
+    <path d="M8 0a8 8 0 1 1 0 16A8 8 0 0 1 8 0ZM1.5 8a6.5 6.5 0 1 0 13 0 6.5 6.5 0 0 0-13 0Zm4.879-2.773 4.264 2.559a.25.25 0 0 1 0 .428l-4.264 2.559A.25.25 0 0 1 6 10.559V5.442a.25.25 0 0 1 .379-.215Z"></path>
+</svg>
+</template>
+
+<template id="gift-icon">
+  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-gift">
+    <path d="M2 2.75A2.75 2.75 0 0 1 4.75 0c.983 0 1.873.42 2.57 1.232.268.318.497.668.68 1.042.183-.375.411-.725.68-1.044C9.376.42 10.266 0 11.25 0a2.75 2.75 0 0 1 2.45 4h.55c.966 0 1.75.784 1.75 1.75v2c0 .698-.409 1.301-1 1.582v4.918A1.75 1.75 0 0 1 13.25 16H2.75A1.75 1.75 0 0 1 1 14.25V9.332C.409 9.05 0 8.448 0 7.75v-2C0 4.784.784 4 1.75 4h.55c-.192-.375-.3-.8-.3-1.25ZM7.25 9.5H2.5v4.75c0 .138.112.25.25.25h4.5Zm1.5 0v5h4.5a.25.25 0 0 0 .25-.25V9.5Zm0-4V8h5.5a.25.25 0 0 0 .25-.25v-2a.25.25 0 0 0-.25-.25Zm-7 0a.25.25 0 0 0-.25.25v2c0 .138.112.25.25.25h5.5V5.5h-5.5Zm3-4a1.25 1.25 0 0 0 0 2.5h2.309c-.233-.818-.542-1.401-.878-1.793-.43-.502-.915-.707-1.431-.707ZM8.941 4h2.309a1.25 1.25 0 0 0 0-2.5c-.516 0-1 .205-1.43.707-.337.392-.646.975-.879 1.793Z"></path>
+</svg>
+</template>
+
+<template id="code-square-icon">
+  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-code-square">
+    <path d="M0 1.75C0 .784.784 0 1.75 0h12.5C15.216 0 16 .784 16 1.75v12.5A1.75 1.75 0 0 1 14.25 16H1.75A1.75 1.75 0 0 1 0 14.25Zm1.75-.25a.25.25 0 0 0-.25.25v12.5c0 .138.112.25.25.25h12.5a.25.25 0 0 0 .25-.25V1.75a.25.25 0 0 0-.25-.25Zm7.47 3.97a.75.75 0 0 1 1.06 0l2 2a.75.75 0 0 1 0 1.06l-2 2a.749.749 0 0 1-1.275-.326.749.749 0 0 1 .215-.734L10.69 8 9.22 6.53a.75.75 0 0 1 0-1.06ZM6.78 6.53 5.31 8l1.47 1.47a.749.749 0 0 1-.326 1.275.749.749 0 0 1-.734-.215l-2-2a.75.75 0 0 1 0-1.06l2-2a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042Z"></path>
+</svg>
+</template>
+
+<template id="device-desktop-icon">
+  <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-device-desktop">
+    <path d="M14.25 1c.966 0 1.75.784 1.75 1.75v7.5A1.75 1.75 0 0 1 14.25 12h-3.727c.099 1.041.52 1.872 1.292 2.757A.752.752 0 0 1 11.25 16h-6.5a.75.75 0 0 1-.565-1.243c.772-.885 1.192-1.716 1.292-2.757H1.75A1.75 1.75 0 0 1 0 10.25v-7.5C0 1.784.784 1 1.75 1ZM1.75 2.5a.25.25 0 0 0-.25.25v7.5c0 .138.112.25.25.25h12.5a.25.25 0 0 0 .25-.25v-7.5a.25.25 0 0 0-.25-.25ZM9.018 12H6.982a5.72 5.72 0 0 1-.765 2.5h3.566a5.72 5.72 0 0 1-.765-2.5Z"></path>
+</svg>
+</template>
+
+        <div class="position-relative">
+                <ul
+                  role="listbox"
+                  class="ActionListWrap QueryBuilder-ListWrap"
+                  aria-label="Suggestions"
+                  data-action="
+                    combobox-commit:query-builder#comboboxCommit
+                    mousedown:query-builder#resultsMousedown
+                  "
+                  data-target="query-builder.resultsList"
+                  data-persist-list=false
+                  id="query-builder-test-results"
+                ></ul>
+        </div>
+      <div class="FormControl-inlineValidation" id="validation-d218889b-1c0f-4cd9-8101-38df4de512d5" hidden="hidden">
+        <span class="FormControl-inlineValidation--visual">
+          <svg aria-hidden="true" height="12" viewBox="0 0 12 12" version="1.1" width="12" data-view-component="true" class="octicon octicon-alert-fill">
+    <path d="M4.855.708c.5-.896 1.79-.896 2.29 0l4.675 8.351a1.312 1.312 0 0 1-1.146 1.954H1.33A1.313 1.313 0 0 1 .183 9.058ZM7 7V3H5v4Zm-1 3a1 1 0 1 0 0-2 1 1 0 0 0 0 2Z"></path>
+</svg>
+        </span>
+        <span></span>
+</div>    </div>
+    <div data-target="query-builder.screenReaderFeedback" aria-live="polite" aria-atomic="true" class="sr-only"></div>
+</query-builder></form>
+          <div class="d-flex flex-row color-fg-muted px-3 text-small color-bg-default search-feedback-prompt">
+            <a target="_blank" href="https://docs.github.com/search-github/github-code-search/understanding-github-code-search-syntax" data-view-component="true" class="Link color-fg-accent text-normal ml-2">
+              Search syntax tips
+</a>            <div class="d-flex flex-1"></div>
+          </div>
+        </div>
+</div>
+
+    </div>
+</modal-dialog></div>
+  </div>
+  <div data-action="click:qbsearch-input#retract" class="dark-backdrop position-fixed" hidden data-target="qbsearch-input.darkBackdrop"></div>
+  <div class="color-fg-default">
+    
+<dialog-helper>
+  <dialog data-target="qbsearch-input.feedbackDialog" data-action="close:qbsearch-input#handleDialogClose cancel:qbsearch-input#handleDialogClose" id="feedback-dialog" aria-modal="true" aria-labelledby="feedback-dialog-title" aria-describedby="feedback-dialog-description" data-view-component="true" class="Overlay Overlay-whenNarrow Overlay--size-medium Overlay--motion-scaleFade">
+    <div data-view-component="true" class="Overlay-header">
+  <div class="Overlay-headerContentWrap">
+    <div class="Overlay-titleWrap">
+      <h1 class="Overlay-title " id="feedback-dialog-title">
+        Provide feedback
+      </h1>
+        
+    </div>
+    <div class="Overlay-actionWrap">
+      <button data-close-dialog-id="feedback-dialog" aria-label="Close" type="button" data-view-component="true" class="close-button Overlay-closeButton"><svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-x">
+    <path d="M3.72 3.72a.75.75 0 0 1 1.06 0L8 6.94l3.22-3.22a.749.749 0 0 1 1.275.326.749.749 0 0 1-.215.734L9.06 8l3.22 3.22a.749.749 0 0 1-.326 1.275.749.749 0 0 1-.734-.215L8 9.06l-3.22 3.22a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042L6.94 8 3.72 4.78a.75.75 0 0 1 0-1.06Z"></path>
+</svg></button>
+    </div>
+  </div>
+  
+</div>
+      <scrollable-region data-labelled-by="feedback-dialog-title">
+        <div data-view-component="true" class="Overlay-body">        <!-- '"` --><!-- </textarea></xmp> --></option></form><form id="code-search-feedback-form" data-turbo="false" action="/search/feedback" accept-charset="UTF-8" method="post"><input type="hidden" data-csrf="true" name="authenticity_token" value="7uQADYHtrr9FJBUB1Dr/Q79r7+fmqeUtUBuxjP8f8NvuCYXChF3p3AIGEg951K2/eYV5aEsUqlyscuWM4dhykA==" />
+          <p>We read every piece of feedback, and take your input very seriously.</p>
+          <textarea name="feedback" class="form-control width-full mb-2" style="height: 120px" id="feedback"></textarea>
+          <input name="include_email" id="include_email" aria-label="Include my email address so I can be contacted" class="form-control mr-2" type="checkbox">
+          <label for="include_email" style="font-weight: normal">Include my email address so I can be contacted</label>
+</form></div>
+      </scrollable-region>
+      <div data-view-component="true" class="Overlay-footer Overlay-footer--alignEnd">          <button data-close-dialog-id="feedback-dialog" type="button" data-view-component="true" class="btn">    Cancel
+</button>
+          <button form="code-search-feedback-form" data-action="click:qbsearch-input#submitFeedback" type="submit" data-view-component="true" class="btn-primary btn">    Submit feedback
+</button>
+</div>
+</dialog></dialog-helper>
+
+    <custom-scopes data-target="qbsearch-input.customScopesManager">
+    
+<dialog-helper>
+  <dialog data-target="custom-scopes.customScopesModalDialog" data-action="close:qbsearch-input#handleDialogClose cancel:qbsearch-input#handleDialogClose" id="custom-scopes-dialog" aria-modal="true" aria-labelledby="custom-scopes-dialog-title" aria-describedby="custom-scopes-dialog-description" data-view-component="true" class="Overlay Overlay-whenNarrow Overlay--size-medium Overlay--motion-scaleFade">
+    <div data-view-component="true" class="Overlay-header Overlay-header--divided">
+  <div class="Overlay-headerContentWrap">
+    <div class="Overlay-titleWrap">
+      <h1 class="Overlay-title " id="custom-scopes-dialog-title">
+        Saved searches
+      </h1>
+        <h2 id="custom-scopes-dialog-description" class="Overlay-description">Use saved searches to filter your results more quickly</h2>
+    </div>
+    <div class="Overlay-actionWrap">
+      <button data-close-dialog-id="custom-scopes-dialog" aria-label="Close" type="button" data-view-component="true" class="close-button Overlay-closeButton"><svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-x">
+    <path d="M3.72 3.72a.75.75 0 0 1 1.06 0L8 6.94l3.22-3.22a.749.749 0 0 1 1.275.326.749.749 0 0 1-.215.734L9.06 8l3.22 3.22a.749.749 0 0 1-.326 1.275.749.749 0 0 1-.734-.215L8 9.06l-3.22 3.22a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042L6.94 8 3.72 4.78a.75.75 0 0 1 0-1.06Z"></path>
+</svg></button>
+    </div>
+  </div>
+  
+</div>
+      <scrollable-region data-labelled-by="custom-scopes-dialog-title">
+        <div data-view-component="true" class="Overlay-body">        <div data-target="custom-scopes.customScopesModalDialogFlash"></div>
+
+        <div hidden class="create-custom-scope-form" data-target="custom-scopes.createCustomScopeForm">
+        <!-- '"` --><!-- </textarea></xmp> --></option></form><form id="custom-scopes-dialog-form" data-turbo="false" action="/search/custom_scopes" accept-charset="UTF-8" method="post"><input type="hidden" data-csrf="true" name="authenticity_token" value="XQClZus6dFnsgYH94nQjtvIYnAg0CO3JNtLckVJ2jow9T7uGnd2VMfnMXTgJctiKHQurxczChujAK8gJ+AzZog==" />
+          <div data-target="custom-scopes.customScopesModalDialogFlash"></div>
+
+          <input type="hidden" id="custom_scope_id" name="custom_scope_id" data-target="custom-scopes.customScopesIdField">
+
+          <div class="form-group">
+            <label for="custom_scope_name">Name</label>
+            <auto-check src="/search/custom_scopes/check_name" required>
+              <input
+                type="text"
+                name="custom_scope_name"
+                id="custom_scope_name"
+                data-target="custom-scopes.customScopesNameField"
+                class="form-control"
+                autocomplete="off"
+                placeholder="github-ruby"
+                required
+                maxlength="50">
+              <input type="hidden" data-csrf="true" value="Zqoc2AT6E+e3AJExiYFA9e/8KJKkAKMIi//G77abC/VJxinOAgmdmsh4m3DtsdzxoQjeKyrC1CQ9vULLZ0tSYw==" />
+            </auto-check>
+          </div>
+
+          <div class="form-group">
+            <label for="custom_scope_query">Query</label>
+            <input
+              type="text"
+              name="custom_scope_query"
+              id="custom_scope_query"
+              data-target="custom-scopes.customScopesQueryField"
+              class="form-control"
+              autocomplete="off"
+              placeholder="(repo:mona/a OR repo:mona/b) AND lang:python"
+              required
+              maxlength="500">
+          </div>
+
+          <p class="text-small color-fg-muted">
+            To see all available qualifiers, see our <a class="Link--inTextBlock" href="https://docs.github.com/search-github/github-code-search/understanding-github-code-search-syntax">documentation</a>.
+          </p>
+</form>        </div>
+
+        <div data-target="custom-scopes.manageCustomScopesForm">
+          <div data-target="custom-scopes.list"></div>
+        </div>
+
+</div>
+      </scrollable-region>
+      <div data-view-component="true" class="Overlay-footer Overlay-footer--alignEnd Overlay-footer--divided">          <button data-action="click:custom-scopes#customScopesCancel" type="button" data-view-component="true" class="btn">    Cancel
+</button>
+          <button form="custom-scopes-dialog-form" data-action="click:custom-scopes#customScopesSubmit" data-target="custom-scopes.customScopesSubmitButton" type="submit" data-view-component="true" class="btn-primary btn">    Create saved search
+</button>
+</div>
+</dialog></dialog-helper>
+    </custom-scopes>
+  </div>
+</qbsearch-input><input type="hidden" data-csrf="true" class="js-data-jump-to-suggestions-path-csrf" value="E00Ka8/a7FhAYn6S3oGOtsv8mlmSxUieQg6jU1RctcXk9wi2h+0ff6kb80FHSzWYVu4D+E2VenFzYqzMRn1yzA==" />
+
+
+          <div class="position-relative mr-lg-3 d-lg-inline-block">
+            <a href="/login?return_to=https%3A%2F%2Fgithub.com%2FYunaiV%2Fmybatis-spring%2Fblob%2Fmaster%2Fsrc%2Fmain%2Fjava%2Forg%2Fmybatis%2Fspring%2Fconfig%2Fmybatis-spring.xsd"
+              class="HeaderMenu-link HeaderMenu-link--sign-in flex-shrink-0 no-underline d-block d-lg-inline-block border border-lg-0 rounded rounded-lg-0 p-2 p-lg-0"
+              data-hydro-click="{&quot;event_type&quot;:&quot;authentication.click&quot;,&quot;payload&quot;:{&quot;location_in_page&quot;:&quot;site header menu&quot;,&quot;repository_id&quot;:null,&quot;auth_type&quot;:&quot;SIGN_UP&quot;,&quot;originating_url&quot;:&quot;https://github.com/YunaiV/mybatis-spring/blob/master/src/main/java/org/mybatis/spring/config/mybatis-spring.xsd&quot;,&quot;user_id&quot;:null}}" data-hydro-click-hmac="23a350f04210ca282e56bf8b6195788c422b8f00997747219cb664ea99254860"
+              data-ga-click="(Logged out) Header, clicked Sign in, text:sign-in">
+              Sign in
+            </a>
+          </div>
+
+            <a href="/signup?ref_cta=Sign+up&amp;ref_loc=header+logged+out&amp;ref_page=%2F%3Cuser-name%3E%2F%3Crepo-name%3E%2Fblob%2Fshow&amp;source=header-repo&amp;source_repo=YunaiV%2Fmybatis-spring"
+              class="HeaderMenu-link HeaderMenu-link--sign-up flex-shrink-0 d-none d-lg-inline-block no-underline border color-border-default rounded px-2 py-1"
+              data-hydro-click="{&quot;event_type&quot;:&quot;authentication.click&quot;,&quot;payload&quot;:{&quot;location_in_page&quot;:&quot;site header menu&quot;,&quot;repository_id&quot;:null,&quot;auth_type&quot;:&quot;SIGN_UP&quot;,&quot;originating_url&quot;:&quot;https://github.com/YunaiV/mybatis-spring/blob/master/src/main/java/org/mybatis/spring/config/mybatis-spring.xsd&quot;,&quot;user_id&quot;:null}}" data-hydro-click-hmac="23a350f04210ca282e56bf8b6195788c422b8f00997747219cb664ea99254860"
+              data-analytics-event="{&quot;category&quot;:&quot;Sign up&quot;,&quot;action&quot;:&quot;click to sign up for account&quot;,&quot;label&quot;:&quot;ref_page:/&lt;user-name&gt;/&lt;repo-name&gt;/blob/show;ref_cta:Sign up;ref_loc:header logged out&quot;}"
+            >
+              Sign up
+            </a>
+        </div>
+      </div>
+    </div>
+  </div>
+</header>
+
+      <div hidden="hidden" data-view-component="true" class="js-stale-session-flash stale-session-flash flash flash-warn flash-full mb-3">
+  
+        <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-alert">
+    <path d="M6.457 1.047c.659-1.234 2.427-1.234 3.086 0l6.082 11.378A1.75 1.75 0 0 1 14.082 15H1.918a1.75 1.75 0 0 1-1.543-2.575Zm1.763.707a.25.25 0 0 0-.44 0L1.698 13.132a.25.25 0 0 0 .22.368h12.164a.25.25 0 0 0 .22-.368Zm.53 3.996v2.5a.75.75 0 0 1-1.5 0v-2.5a.75.75 0 0 1 1.5 0ZM9 11a1 1 0 1 1-2 0 1 1 0 0 1 2 0Z"></path>
+</svg>
+        <span class="js-stale-session-flash-signed-in" hidden>You signed in with another tab or window. <a class="Link--inTextBlock" href="">Reload</a> to refresh your session.</span>
+        <span class="js-stale-session-flash-signed-out" hidden>You signed out in another tab or window. <a class="Link--inTextBlock" href="">Reload</a> to refresh your session.</span>
+        <span class="js-stale-session-flash-switched" hidden>You switched accounts on another tab or window. <a class="Link--inTextBlock" href="">Reload</a> to refresh your session.</span>
+
+    <button id="icon-button-e76c5692-6ed2-4941-bce7-c9172101cbf2" aria-labelledby="tooltip-3716490d-83a0-4bae-98e4-726b95a73741" type="button" data-view-component="true" class="Button Button--icon
\ No newline at end of file
diff --git a/mybatis/30-mybatis-Spring 集成（二）之初始化.md b/mybatis/30-mybatis-Spring 集成（二）之初始化.md
new file mode 100644
index 0000000..40efffd
--- /dev/null
+++ b/mybatis/30-mybatis-Spring 集成（二）之初始化.md	
@@ -0,0 +1,1275 @@
+# 精尽 MyBatis 源码解析 —— Spring 集成（二）之初始化
+
+# 1. 概述
+
+在前面的，我们已经看了四篇 MyBatis 初始化相关的文章：
+
+- [《MyBatis 初始化（一）之加载 mybatis-config》](http://svip.iocoder.cn/MyBatis/builder-package-1)
+- [《MyBatis 初始化（二）之加载 Mapper 映射配置文件》](http://svip.iocoder.cn/MyBatis/builder-package-2)
+- [《MyBatis 初始化（三）之加载 Statement 配置》](http://svip.iocoder.cn/MyBatis/builder-package-3)
+- [《MyBatis 初始化（四）之加载注解配置》](http://svip.iocoder.cn/MyBatis/builder-package-4)
+
+那么，本文我们就来看看，Spring 和 MyBatis 如何集成。主要涉及如下三个包：
+
+- `annotation`
+- `config`
+- `mapper`
+
+# 2. SqlSessionFactoryBean
+
+`org.mybatis.spring.SqlSessionFactoryBean` ，实现 FactoryBean、InitializingBean、ApplicationListener 接口，负责创建 SqlSessionFactory 对象。
+
+使用示例如下：
+
+```
+<!-- simplest possible SqlSessionFactory configuration -->
+<bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean">
+    <property name="dataSource" ref="dataSource" />
+    <!-- Directly specify the location of the MyBatis mapper xml file. This
+         is NOT required when using MapperScannerConfigurer or
+         MapperFactoryBean; they will load the xml automatically if it is
+         in the same classpath location as the DAO interface. Rather than
+         directly referencing the xml files, the 'configLocation' property
+         could also be used to specify the location of a MyBatis config
+         file. This config file could, in turn, contain &ltmapper&gt
+         elements that point to the correct mapper xml files.
+     -->
+    <property name="mapperLocations" value="classpath:org/mybatis/spring/sample/mapper/*.xml" />
+</bean>
+```
+
+另外，如果胖友不熟悉 Spring FactoryBean 的机制。可以看看 [《Spring bean 之 FactoryBean》](https://www.jianshu.com/p/d6c42d723464) 文章。
+
+## 2.1 构造方法
+
+```
+// SqlSessionFactoryBean.java
+
+private static final Logger LOGGER = LoggerFactory.getLogger(SqlSessionFactoryBean.class);
+
+/**
+ * 指定 mybatis-config.xml 路径的 Resource 对象
+ */
+private Resource configLocation;
+
+private Configuration configuration;
+
+/**
+ * 指定 Mapper 路径的 Resource 数组
+ */
+private Resource[] mapperLocations;
+
+private DataSource dataSource;
+
+private TransactionFactory transactionFactory;
+
+private Properties configurationProperties;
+
+private SqlSessionFactoryBuilder sqlSessionFactoryBuilder = new SqlSessionFactoryBuilder();
+
+private SqlSessionFactory sqlSessionFactory;
+
+//EnvironmentAware requires spring 3.1
+private String environment = SqlSessionFactoryBean.class.getSimpleName();
+
+private boolean failFast;
+
+private Interceptor[] plugins;
+
+private TypeHandler<?>[] typeHandlers;
+
+private String typeHandlersPackage;
+
+private Class<?>[] typeAliases;
+
+private String typeAliasesPackage;
+
+private Class<?> typeAliasesSuperType;
+
+//issue #19. No default provider.
+private DatabaseIdProvider databaseIdProvider;
+
+private Class<? extends VFS> vfs;
+
+private Cache cache;
+
+private ObjectFactory objectFactory;
+
+private ObjectWrapperFactory objectWrapperFactory;
+
+// 省略 setting 方法
+```
+
+- 是不是各种熟悉的属性，这里就不多解释每个对象了。你比我懂，嘿嘿。
+
+## 2.2 afterPropertiesSet
+
+`#afterPropertiesSet()` 方法，构建 SqlSessionFactory 对象。代码如下：
+
+```
+// SqlSessionFactoryBean.java
+
+@Override
+public void afterPropertiesSet() throws Exception {
+    notNull(dataSource, "Property 'dataSource' is required");
+    notNull(sqlSessionFactoryBuilder, "Property 'sqlSessionFactoryBuilder' is required");
+    state((configuration == null && configLocation == null) || !(configuration != null && configLocation != null),
+            "Property 'configuration' and 'configLocation' can not specified with together");
+
+    // 创建 SqlSessionFactory 对象
+    this.sqlSessionFactory = buildSqlSessionFactory();
+}
+
+/**
+ * Build a {@code SqlSessionFactory} instance.
+ *
+ * The default implementation uses the standard MyBatis {@code XMLConfigBuilder} API to build a
+ * {@code SqlSessionFactory} instance based on an Reader.
+ * Since 1.3.0, it can be specified a {@link Configuration} instance directly(without config file).
+ *
+ * @return SqlSessionFactory
+ * @throws IOException if loading the config file failed
+ */
+protected SqlSessionFactory buildSqlSessionFactory() throws IOException {
+    Configuration configuration;
+
+    // 初始化 configuration 对象，和设置其 `configuration.variables` 属性
+    XMLConfigBuilder xmlConfigBuilder = null;
+    if (this.configuration != null) {
+        configuration = this.configuration;
+        if (configuration.getVariables() == null) {
+            configuration.setVariables(this.configurationProperties);
+        } else if (this.configurationProperties != null) {
+            configuration.getVariables().putAll(this.configurationProperties);
+        }
+    } else if (this.configLocation != null) {
+        xmlConfigBuilder = new XMLConfigBuilder(this.configLocation.getInputStream(), null, this.configurationProperties);
+        configuration = xmlConfigBuilder.getConfiguration();
+    } else {
+        LOGGER.debug(() -> "Property 'configuration' or 'configLocation' not specified, using default MyBatis Configuration");
+        configuration = new Configuration();
+        if (this.configurationProperties != null) {
+            configuration.setVariables(this.configurationProperties);
+        }
+    }
+
+    // 设置 `configuration.objectFactory` 属性
+    if (this.objectFactory != null) {
+        configuration.setObjectFactory(this.objectFactory);
+    }
+
+    // 设置 `configuration.objectWrapperFactory` 属性
+    if (this.objectWrapperFactory != null) {
+        configuration.setObjectWrapperFactory(this.objectWrapperFactory);
+    }
+
+    // 设置 `configuration.vfs` 属性
+    if (this.vfs != null) {
+        configuration.setVfsImpl(this.vfs);
+    }
+
+    // 设置 `configuration.typeAliasesPackage` 属性
+    if (hasLength(this.typeAliasesPackage)) {
+        String[] typeAliasPackageArray = tokenizeToStringArray(this.typeAliasesPackage,
+                ConfigurableApplicationContext.CONFIG_LOCATION_DELIMITERS);
+        for (String packageToScan : typeAliasPackageArray) {
+            configuration.getTypeAliasRegistry().registerAliases(packageToScan,
+                    typeAliasesSuperType == null ? Object.class : typeAliasesSuperType);
+            LOGGER.debug(() -> "Scanned package: '" + packageToScan + "' for aliases");
+        }
+    }
+
+    // 设置 `configuration.typeAliases` 属性
+    if (!isEmpty(this.typeAliases)) {
+        for (Class<?> typeAlias : this.typeAliases) {
+            configuration.getTypeAliasRegistry().registerAlias(typeAlias);
+            LOGGER.debug(() -> "Registered type alias: '" + typeAlias + "'");
+        }
+    }
+
+    // 初始化 `configuration.interceptorChain` 属性，即拦截器
+    if (!isEmpty(this.plugins)) {
+        for (Interceptor plugin : this.plugins) {
+            configuration.addInterceptor(plugin);
+            LOGGER.debug(() -> "Registered plugin: '" + plugin + "'");
+        }
+    }
+
+    // 扫描 typeHandlersPackage 包，注册 TypeHandler
+    if (hasLength(this.typeHandlersPackage)) {
+        String[] typeHandlersPackageArray = tokenizeToStringArray(this.typeHandlersPackage,
+                ConfigurableApplicationContext.CONFIG_LOCATION_DELIMITERS);
+        for (String packageToScan : typeHandlersPackageArray) {
+            configuration.getTypeHandlerRegistry().register(packageToScan);
+            LOGGER.debug(() -> "Scanned package: '" + packageToScan + "' for type handlers");
+        }
+    }
+    // 如果 typeHandlers 非空，注册对应的 TypeHandler
+    if (!isEmpty(this.typeHandlers)) {
+        for (TypeHandler<?> typeHandler : this.typeHandlers) {
+            configuration.getTypeHandlerRegistry().register(typeHandler);
+            LOGGER.debug(() -> "Registered type handler: '" + typeHandler + "'");
+        }
+    }
+
+    // 设置 `configuration.databaseId` 属性
+    if (this.databaseIdProvider != null) {//fix #64 set databaseId before parse mapper xmls
+        try {
+            configuration.setDatabaseId(this.databaseIdProvider.getDatabaseId(this.dataSource));
+        } catch (SQLException e) {
+            throw new NestedIOException("Failed getting a databaseId", e);
+        }
+    }
+
+    // 设置 `configuration.cache` 属性
+    if (this.cache != null) {
+        configuration.addCache(this.cache);
+    }
+
+    // <1> 解析 mybatis-config.xml 配置
+    if (xmlConfigBuilder != null) {
+        try {
+            xmlConfigBuilder.parse();
+            LOGGER.debug(() -> "Parsed configuration file: '" + this.configLocation + "'");
+        } catch (Exception ex) {
+            throw new NestedIOException("Failed to parse config resource: " + this.configLocation, ex);
+        } finally {
+            ErrorContext.instance().reset();
+        }
+    }
+
+    // 初始化 TransactionFactory 对象
+    if (this.transactionFactory == null) {
+        this.transactionFactory = new SpringManagedTransactionFactory();
+    }
+    // 设置 `configuration.environment` 属性
+    configuration.setEnvironment(new Environment(this.environment, this.transactionFactory, this.dataSource));
+
+    // 扫描 Mapper XML 文件们，并进行解析
+    if (!isEmpty(this.mapperLocations)) {
+        for (Resource mapperLocation : this.mapperLocations) {
+            if (mapperLocation == null) {
+                continue;
+            }
+
+            try {
+                XMLMapperBuilder xmlMapperBuilder = new XMLMapperBuilder(mapperLocation.getInputStream(),
+                        configuration, mapperLocation.toString(), configuration.getSqlFragments());
+                xmlMapperBuilder.parse();
+            } catch (Exception e) {
+                throw new NestedIOException("Failed to parse mapping resource: '" + mapperLocation + "'", e);
+            } finally {
+                ErrorContext.instance().reset();
+            }
+            LOGGER.debug(() -> "Parsed mapper file: '" + mapperLocation + "'");
+        }
+    } else {
+        LOGGER.debug(() -> "Property 'mapperLocations' was not specified or no matching resources found");
+    }
+
+    // 创建 SqlSessionFactory 对象
+    return this.sqlSessionFactoryBuilder.build(configuration);
+}
+```
+
+- 代码比较长，胖友自己耐心看下注释，我们只挑重点的瞅瞅。
+- `<1>` 处，调用 `XMLConfigBuilder#parse()` 方法，解析 `mybatis-config.xml` 配置。即对应 [《MyBatis 初始化（一）之加载 mybatis-config》](http://svip.iocoder.cn/MyBatis/builder-package-1) 文章。
+- `<2>` 处，调用 `XMLMapperBuilder#parse()` 方法，解析 Mapper XML 配置。即对应 [《MyBatis 初始化（二）之加载 Mapper 映射配置文件》](http://svip.iocoder.cn/MyBatis/builder-package-2) 。
+- `<3>` 处，调用 `SqlSessionFactoryBuilder#build(Configuration config)` 方法，创建 SqlSessionFactory 对象。
+- 另外，我们看到 `LOGGER` 的使用。那么，可能胖友会跟艿艿有一样的疑问，`org.mybatis.logging` 包下，又定义了 Logger 呢？因为想使用方法参数为 `Supplier<String>` 的方法，即使用起来更加方便。这也是 `mybatis-spring` 项目的 `logging` 包的用途。感兴趣的胖友，可以自己去看看。
+
+## 2.3 getObject
+
+`#getObject()` 方法，获得 SqlSessionFactory 对象。代码如下：
+
+```
+// SqlSessionFactoryBean.java
+
+@Override
+public SqlSessionFactory getObject() throws Exception {
+    // 保证 SqlSessionFactory 对象的初始化
+    if (this.sqlSessionFactory == null) {
+        afterPropertiesSet();
+    }
+
+    return this.sqlSessionFactory;
+}
+```
+
+## 2.4 getObjectType
+
+```
+// SqlSessionFactoryBean.java
+
+@Override
+public Class<? extends SqlSessionFactory> getObjectType() {
+    return this.sqlSessionFactory == null ? SqlSessionFactory.class : this.sqlSessionFactory.getClass();
+}
+```
+
+## 2.5 isSingleton
+
+```
+// SqlSessionFactoryBean.java
+
+@Override
+public boolean isSingleton() {
+    return true;
+}
+```
+
+## 2.6 onApplicationEvent
+
+`#onApplicationEvent()` 方法，监听 ContextRefreshedEvent 事件，如果 MapperStatement 们，没有都初始化**都**完成，会抛出 IncompleteElementException 异常。代码如下：
+
+```
+// SqlSessionFactoryBean.java
+
+@Override
+public void onApplicationEvent(ApplicationEvent event) {
+    if (failFast && event instanceof ContextRefreshedEvent) {
+        // fail-fast -> check all statements are completed
+        // 如果 MapperStatement 们，没有都初始化完成，会抛出 IncompleteElementException 异常
+        this.sqlSessionFactory.getConfiguration().getMappedStatementNames();
+    }
+}
+```
+
+- 使用该功能时，需要设置 `fastFast` 属性，为 `true` 。
+
+------
+
+在 `mybatis-spring` 项目中，提供了多种配置 Mapper 的方式。下面，我们一种一种来看。😈 实际上，配置 `SqlSessionFactoryBean.mapperLocations` 属性，也是方式之一。嘿嘿嘿。
+
+# 3. MapperFactoryBean
+
+`org.mybatis.spring.mapper.MapperFactoryBean` ，实现 FactoryBean 接口，继承 SqlSessionDaoSupport 抽象类，创建 Mapper 对象。
+
+使用示例如下：
+
+```
+<!-- Directly injecting mappers. The required SqlSessionFactory will be autowired. -->
+<bean id="userMapper" class="org.mybatis.spring.mapper.MapperFactoryBean" autowire="byType">
+	<property name="mapperInterface" value="org.mybatis.spring.sample.mapper.UserMapper" />
+</bean>
+```
+
+- 该示例来自 `org.mybatis.spring.sample.SampleMapperTest` 单元测试。胖友可以基于它调试。
+
+## 3.1 MapperFactoryBean
+
+```
+// MapperFactoryBean.java
+
+/**
+ * Mapper 接口
+ */
+private Class<T> mapperInterface;
+/**
+ * 是否添加到 {@link Configuration} 中
+ */
+private boolean addToConfig = true;
+
+public MapperFactoryBean() {
+    //intentionally empty
+}
+
+public MapperFactoryBean(Class<T> mapperInterface) {
+    this.mapperInterface = mapperInterface;
+}
+
+// 省略 setting 方法
+```
+
+## 3.2 checkDaoConfig
+
+```
+// MapperFactoryBean.java
+
+@Override
+protected void checkDaoConfig() {
+    // <1> 校验 sqlSessionTemplate 非空
+    super.checkDaoConfig();
+    // <2> 校验 mapperInterface 非空
+    notNull(this.mapperInterface, "Property 'mapperInterface' is required");
+
+    // <3> 添加 Mapper 接口到 configuration 中
+    Configuration configuration = getSqlSession().getConfiguration();
+    if (this.addToConfig && !configuration.hasMapper(this.mapperInterface)) {
+        try {
+            configuration.addMapper(this.mapperInterface);
+        } catch (Exception e) {
+            logger.error("Error while adding the mapper '" + this.mapperInterface + "' to configuration.", e);
+            throw new IllegalArgumentException(e);
+        } finally {
+            ErrorContext.instance().reset();
+        }
+    }
+}
+```
+
+- 该方法，是在 `org.springframework.dao.support.DaoSupport` 定义，被 `#afterPropertiesSet()` 方法所调用，代码如下：
+
+  ```
+  // DaoSupport.java
+  
+  public final void afterPropertiesSet() throws IllegalArgumentException, BeanInitializationException {
+      this.checkDaoConfig();
+  
+      try {
+          this.initDao();
+      } catch (Exception var2) {
+          throw new BeanInitializationException("Initialization of DAO failed", var2);
+      }
+  }
+  ```
+
+  - 所以此处，就和 [「2.2 afterPropertiesSet」](https://svip.iocoder.cn/MyBatis/Spring-Integration-2/#) 的等价。
+
+- `<1>` 处，调用父 `SqlSessionDaoSupport#checkDaoConfig()` 方法，校验 `sqlSessionTemplate` 非空。😈 关于 SqlSessionDaoSupport 抽象类，后续我们详细解析。
+
+- `<2>` 处，校验 `mapperInterface` 非空。
+
+- `<3>` 处，调用 `Configuration#addMapper(mapperInterface)` 方法，添加 Mapper 接口到 `configuration` 中。
+
+## 3.3 getObject
+
+`#getObject()` 方法，获得 Mapper 对象。**注意**，返回的是基于 Mapper 接口自动生成的代理对象。代码如下：
+
+```
+// MapperFactoryBean.java
+
+@Override
+public T getObject() throws Exception {
+    return getSqlSession().getMapper(this.mapperInterface);
+}
+```
+
+## 3.4 getObjectType
+
+```
+// MapperFactoryBean.java
+
+@Override
+public Class<T> getObjectType() {
+    return this.mapperInterface;
+}
+```
+
+## 3.5 isSingleton
+
+```
+// MapperFactoryBean.java
+
+@Override
+public boolean isSingleton() {
+    return true;
+}
+```
+
+# 4. @MapperScan
+
+> 艿艿：本小节，需要胖友对 Spring IOC 有一定的了解。如果不熟悉的胖友，建议不需要特别深入的理解。或者说，先去看 [《精尽 Spring 源码解析》](http://svip.iocoder.cn/categories/Spring/) 。
+
+`org.mybatis.spring.annotation.@MapperScan` 注解，指定需要扫描的包，将包中符合的 Mapper 接口，注册成 `beanClass` 为 MapperFactoryBean 的 BeanDefinition 对象，从而实现创建 Mapper 对象。代码如下：
+
+```
+// MapperScan.java
+
+@Retention(RetentionPolicy.RUNTIME)
+@Target(ElementType.TYPE)
+@Documented
+@Import(MapperScannerRegistrar.class)
+@Repeatable(MapperScans.class)
+public @interface MapperScan {
+
+    /**
+     * Alias for the {@link #basePackages()} attribute. Allows for more concise
+     * annotation declarations e.g.:
+     * {@code @MapperScan("org.my.pkg")} instead of {@code @MapperScan(basePackages = "org.my.pkg"})}.
+     *
+     * 和 {@link #basePackages()} 相同意思
+     *
+     * @return base package names
+     */
+    String[] value() default {};
+
+    /**
+     * Base packages to scan for MyBatis interfaces. Note that only interfaces
+     * with at least one method will be registered; concrete classes will be
+     * ignored.
+     *
+     * 扫描的包地址
+     *
+     * @return base package names for scanning mapper interface
+     */
+    String[] basePackages() default {};
+
+    /**
+     * Type-safe alternative to {@link #basePackages()} for specifying the packages
+     * to scan for annotated components. The package of each class specified will be scanned.
+     * <p>Consider creating a special no-op marker class or interface in each package
+     * that serves no purpose other than being referenced by this attribute.
+     *
+     * @return classes that indicate base package for scanning mapper interface
+     */
+    Class<?>[] basePackageClasses() default {};
+
+    /**
+     * The {@link BeanNameGenerator} class to be used for naming detected components
+     * within the Spring container.
+     *
+     * @return the class of {@link BeanNameGenerator}
+     */
+    Class<? extends BeanNameGenerator> nameGenerator() default BeanNameGenerator.class;
+
+    /**
+     * This property specifies the annotation that the scanner will search for.
+     * <p>
+     * The scanner will register all interfaces in the base package that also have
+     * the specified annotation.
+     * <p>
+     * Note this can be combined with markerInterface.
+     *
+     * 指定注解
+     *
+     * @return the annotation that the scanner will search for
+     */
+    Class<? extends Annotation> annotationClass() default Annotation.class;
+
+    /**
+     * This property specifies the parent that the scanner will search for.
+     * <p>
+     * The scanner will register all interfaces in the base package that also have
+     * the specified interface class as a parent.
+     * <p>
+     * Note this can be combined with annotationClass.
+     *
+     * 指定接口
+     *
+     * @return the parent that the scanner will search for
+     */
+    Class<?> markerInterface() default Class.class;
+
+    /**
+     * Specifies which {@code SqlSessionTemplate} to use in the case that there is
+     * more than one in the spring context. Usually this is only needed when you
+     * have more than one datasource.
+     *
+     * 指向的 SqlSessionTemplate 的名字
+     *
+     * @return the bean name of {@code SqlSessionTemplate}
+     */
+    String sqlSessionTemplateRef() default "";
+
+    /**
+     * Specifies which {@code SqlSessionFactory} to use in the case that there is
+     * more than one in the spring context. Usually this is only needed when you
+     * have more than one datasource.
+     *
+     * 指向的 SqlSessionFactory 的名字
+     *
+     * @return the bean name of {@code SqlSessionFactory}
+     */
+    String sqlSessionFactoryRef() default "";
+
+    /**
+     * Specifies a custom MapperFactoryBean to return a mybatis proxy as spring bean.
+     *
+     * 可自定义 MapperFactoryBean 的实现类
+     *
+     * @return the class of {@code MapperFactoryBean}
+     */
+    Class<? extends MapperFactoryBean> factoryBean() default MapperFactoryBean.class;
+
+}
+```
+
+- 属性比较多，实际上，胖友常用的就是 `value()` 属性。
+- 重点是 `@Import(MapperScannerRegistrar.class)` 。为什么呢？`@Import` 注解，负责资源的导入。如果导入的是一个 Java 类，例如此处为 MapperScannerRegistrar 类，Spring 会将其注册成一个 Bean 对象。而 MapperScannerRegistrar 类呢？详细解析，见 [「4.1 MapperScannerRegistrar」](https://svip.iocoder.cn/MyBatis/Spring-Integration-2/#) 。
+
+使用示例如下：
+
+```
+@Configuration
+@ImportResource("classpath:org/mybatis/spring/sample/config/applicationContext-infrastructure.xml")
+@MapperScan("org.mybatis.spring.sample.mapper") // here
+static class AppConfig {
+}
+```
+
+- 该示例来自 `org.mybatis.spring.sample.SampleEnableTest` 单元测试。胖友可以基于它调试。
+
+## 4.1 MapperScannerRegistrar
+
+`org.mybatis.spring.annotation.MapperScannerRegistrar` ，实现 ImportBeanDefinitionRegistrar、ResourceLoaderAware 接口，`@MapperScann` 的注册器，负责将扫描到的 Mapper 接口，注册成 beanClass 为 MapperFactoryBean 的 BeanDefinition 对象，从而实现创建 Mapper 对象。
+
+### 4.1.1 构造方法
+
+```
+// MapperScannerRegistrar.java
+
+/**
+ * ResourceLoader 对象
+ */
+private ResourceLoader resourceLoader;
+
+@Override
+public void setResourceLoader(ResourceLoader resourceLoader) {
+    this.resourceLoader = resourceLoader;
+}
+```
+
+- 因为实现了 ResourceLoaderAware 接口，所以 `resourceLoader` 属性，能够被注入。
+
+### 4.1.2 registerBeanDefinitions
+
+```
+// MapperScannerRegistrar.java
+
+@Override
+public void registerBeanDefinitions(AnnotationMetadata importingClassMetadata, BeanDefinitionRegistry registry) {
+    // <1> 获得 @MapperScan 注解信息
+    AnnotationAttributes mapperScanAttrs = AnnotationAttributes
+            .fromMap(importingClassMetadata.getAnnotationAttributes(MapperScan.class.getName()));
+    // <2> 扫描包，将扫描到的 Mapper 接口，注册成 beanClass 为 MapperFactoryBean 的 BeanDefinition 对象
+    registerBeanDefinitions(mapperScanAttrs, registry);
+}
+
+void registerBeanDefinitions(AnnotationAttributes annoAttrs, BeanDefinitionRegistry registry) {
+    // <3.1> 创建 ClassPathMapperScanner 对象
+    ClassPathMapperScanner scanner = new ClassPathMapperScanner(registry);
+
+    // <3.2> 设置 resourceLoader 属性到 scanner 中
+    // this check is needed in Spring 3.1
+    if (resourceLoader != null) {
+        scanner.setResourceLoader(resourceLoader);
+    }
+
+    // <3.3> 获得 @(MapperScan 注解上的属性，设置到 scanner 中
+    Class<? extends Annotation> annotationClass = annoAttrs.getClass("annotationClass");
+    if (!Annotation.class.equals(annotationClass)) {
+        scanner.setAnnotationClass(annotationClass);
+    }
+    Class<?> markerInterface = annoAttrs.getClass("markerInterface");
+    if (!Class.class.equals(markerInterface)) {
+        scanner.setMarkerInterface(markerInterface);
+    }
+    Class<? extends BeanNameGenerator> generatorClass = annoAttrs.getClass("nameGenerator");
+    if (!BeanNameGenerator.class.equals(generatorClass)) {
+        scanner.setBeanNameGenerator(BeanUtils.instantiateClass(generatorClass));
+    }
+    Class<? extends MapperFactoryBean> mapperFactoryBeanClass = annoAttrs.getClass("factoryBean");
+    if (!MapperFactoryBean.class.equals(mapperFactoryBeanClass)) {
+        scanner.setMapperFactoryBean(BeanUtils.instantiateClass(mapperFactoryBeanClass));
+    }
+    scanner.setSqlSessionTemplateBeanName(annoAttrs.getString("sqlSessionTemplateRef"));
+    scanner.setSqlSessionFactoryBeanName(annoAttrs.getString("sqlSessionFactoryRef"));
+
+    // <4> 获得要扫描的包
+    List<String> basePackages = new ArrayList<>();
+    basePackages.addAll(
+            Arrays.stream(annoAttrs.getStringArray("value")) // 包
+                    .filter(StringUtils::hasText)
+                    .collect(Collectors.toList()));
+    basePackages.addAll(
+            Arrays.stream(annoAttrs.getStringArray("basePackages")) // 包
+                    .filter(StringUtils::hasText)
+                    .collect(Collectors.toList()));
+    basePackages.addAll(
+            Arrays.stream(annoAttrs.getClassArray("basePackageClasses")) // 类
+                    .map(ClassUtils::getPackageName)
+                    .collect(Collectors.toList()));
+
+    // <5> 注册 scanner 的过滤器
+    scanner.registerFilters();
+    // <6> 执行扫描
+    scanner.doScan(StringUtils.toStringArray(basePackages));
+}
+```
+
+- `<1>` 处，获得 `@MapperScan` 注解信息。
+
+- `<2>` 处，调用 `#registerBeanDefinitions(AnnotationAttributes annoAttrs, BeanDefinitionRegistry registry)` 方法，扫描包，将扫描到的 Mapper 接口，注册成 `beanClass` 为 MapperFactoryBean 的 BeanDefinition 对象。
+
+- ```
+  <3.1>
+  ```
+
+   
+
+  处，创建 ClassPathMapperScanner 对象。下面的代码，都是和 ClassPathMapperScanner 相关。所以，详细的解析，最终看
+
+   
+
+  「4.2 ClassPathMapperScanner」
+
+   
+
+  。
+
+  - `<3.2>` 处， 设置 `resourceLoader` 属性到 `scanner` 中。
+  - `<3.3>` 处，获得 `@MapperScan` 注解上的属性，设置到 `scanner` 中。
+
+- `<4>` 处，获得要扫描的包。
+
+- `<5>` 处，调用 `ClassPathMapperScanner#registerFilters()` 方法，注册 scanner 的过滤器。
+
+- `<6>` 处，调用 `ClassPathMapperScanner#doScan(String... basePackages)` 方法，执行扫描，将扫描到的 Mapper 接口，注册成 beanClass 为 MapperFactoryBean 的 BeanDefinition 对象，从而实现创建 Mapper 对象。
+
+- 😈 上面看了一堆的 ClassPathMapperScanner 类的调用，下面开始我们的旅程。
+
+## 4.2 ClassPathMapperScanner
+
+`org.mybatis.spring.mapper.ClassPathMapperScanner` ，继承 `org.springframework.context.annotation.ClassPathMapperScanner` 类，负责执行扫描，将扫描到的 Mapper 接口，注册成 beanClass 为 MapperFactoryBean 的 BeanDefinition 对象，从而实现创建 Mapper 对象。
+
+可能很多胖友不熟悉 ClassPathMapperScanner 类，可以看看 [《Spring自定义类扫描器》](https://fangjian0423.github.io/2017/06/11/spring-custom-component-provider/) 文章。哈哈哈，艿艿也是现学的。
+
+### 4.2.1 构造方法
+
+```
+// ClassPathMapperScanner.java
+
+/**
+ * 是否添加到 {@link org.apache.ibatis.session.Configuration} 中
+ */
+private boolean addToConfig = true;
+
+private SqlSessionFactory sqlSessionFactory;
+
+private SqlSessionTemplate sqlSessionTemplate;
+
+/**
+ * {@link #sqlSessionTemplate} 的 bean 名字
+ */
+private String sqlSessionTemplateBeanName;
+
+/**
+ * {@link #sqlSessionFactory} 的 bean 名字
+ */
+private String sqlSessionFactoryBeanName;
+
+/**
+ * 指定注解
+ */
+private Class<? extends Annotation> annotationClass;
+
+/**
+ * 指定接口
+ */
+private Class<?> markerInterface;
+
+/**
+ * MapperFactoryBean 对象
+ */
+private MapperFactoryBean<?> mapperFactoryBean = new MapperFactoryBean<>();
+
+// ... 省略 setting 方法
+```
+
+### 4.2.2 registerFilters
+
+`#registerFilters()` 方法，注册过滤器。代码如下：
+
+```
+// ClassPathMapperScanner.java
+
+/**
+ * Configures parent scanner to search for the right interfaces. It can search
+ * for all interfaces or just for those that extends a markerInterface or/and
+ * those annotated with the annotationClass
+ *
+ * 注册过滤器
+ */
+public void registerFilters() {
+    boolean acceptAllInterfaces = true; // 是否接受所有接口
+
+    // if specified, use the given annotation and / or marker interface
+    // 如果指定了注解，则添加 INCLUDE 过滤器 AnnotationTypeFilter 对象
+    if (this.annotationClass != null) {
+        addIncludeFilter(new AnnotationTypeFilter(this.annotationClass));
+        acceptAllInterfaces = false; // 标记不是接受所有接口
+    }
+
+    // override AssignableTypeFilter to ignore matches on the actual marker interface
+    // 如果指定了接口，则添加 INCLUDE 过滤器 AssignableTypeFilter 对象
+    if (this.markerInterface != null) {
+        addIncludeFilter(new AssignableTypeFilter(this.markerInterface) {
+            @Override
+            protected boolean matchClassName(String className) {
+                return false;
+            }
+        });
+        acceptAllInterfaces = false; // 标记不是接受所有接口
+    }
+
+    // 如果接受所有接口，则添加自定义 INCLUDE 过滤器 TypeFilter ，全部返回 true
+    if (acceptAllInterfaces) {
+        // default include filter that accepts all classes
+        addIncludeFilter((metadataReader, metadataReaderFactory) -> true);
+    }
+
+    // exclude package-info.java
+    // 添加 INCLUDE 过滤器，排除 package-info.java
+    addExcludeFilter((metadataReader, metadataReaderFactory) -> {
+        String className = metadataReader.getClassMetadata().getClassName();
+        return className.endsWith("package-info");
+    });
+}
+```
+
+- 根据配置，添加 INCLUDE 和 EXCLUDE 过滤器。
+
+### 4.2.3 doScan
+
+`#doScan(String... basePackages)` 方法，执行扫描，将扫描到的 Mapper 接口，注册成 beanClass 为 MapperFactoryBean 的 BeanDefinition 对象。代码如下：
+
+```
+// ClassPathMapperScanner.java
+
+/**
+ * Calls the parent search that will search and register all the candidates.
+ * Then the registered objects are post processed to set them as
+ * MapperFactoryBeans
+ */
+@Override
+public Set<BeanDefinitionHolder> doScan(String... basePackages) {
+    // <1> 执行扫描，获得包下符合的类们，并分装成 BeanDefinitionHolder 对象的集合
+    Set<BeanDefinitionHolder> beanDefinitions = super.doScan(basePackages);
+
+    if (beanDefinitions.isEmpty()) {
+        LOGGER.warn(() -> "No MyBatis mapper was found in '" + Arrays.toString(basePackages) + "' package. Please check your configuration.");
+    } else {
+        // 处理 BeanDefinitionHolder 对象的集合
+        processBeanDefinitions(beanDefinitions);
+    }
+
+    return beanDefinitions;
+}
+```
+
+- `<1>` 处，调用父 `ClassPathBeanDefinitionScanner#doScan(basePackages)` 方法，执行扫描，获得包下符合的类们，并分装成 BeanDefinitionHolder 对象的集合。
+
+- `<2>` 处，调用 `#processBeanDefinitions((Set<BeanDefinitionHolder> beanDefinitions)` 方法，处理 BeanDefinitionHolder 对象的集合。代码如下：
+
+  ```
+  // ClassPathMapperScanner.java
+  
+  private void processBeanDefinitions(Set<BeanDefinitionHolder> beanDefinitions) {
+      GenericBeanDefinition definition;
+      // <1> 遍历 BeanDefinitionHolder 数组，逐一设置属性
+      for (BeanDefinitionHolder holder : beanDefinitions) {
+          definition = (GenericBeanDefinition) holder.getBeanDefinition();
+          String beanClassName = definition.getBeanClassName();
+          LOGGER.debug(() -> "Creating MapperFactoryBean with name '" + holder.getBeanName()
+                  + "' and '" + beanClassName + "' mapperInterface");
+  
+          // the mapper interface is the original class of the bean
+          // but, the actual class of the bean is MapperFactoryBean
+          // <2> 此处 definition 的 beanClass 为 Mapper 接口，需要修改成 MapperFactoryBean 类，从而创建 Mapper 代理对象
+          definition.getConstructorArgumentValues().addGenericArgumentValue(beanClassName); // issue #59
+          definition.setBeanClass(this.mapperFactoryBean.getClass());
+  
+          // <3> 设置 `MapperFactoryBean.addToConfig` 属性
+          definition.getPropertyValues().add("addToConfig", this.addToConfig);
+  
+          boolean explicitFactoryUsed = false; // <4.1>是否已经显式设置了 sqlSessionFactory 或 sqlSessionFactory 属性
+          // <4.2> 如果 sqlSessionFactoryBeanName 或 sqlSessionFactory 非空，设置到 `MapperFactoryBean.sqlSessionFactory` 属性
+          if (StringUtils.hasText(this.sqlSessionFactoryBeanName)) {
+              definition.getPropertyValues().add("sqlSessionFactory", new RuntimeBeanReference(this.sqlSessionFactoryBeanName));
+              explicitFactoryUsed = true;
+          } else if (this.sqlSessionFactory != null) {
+              definition.getPropertyValues().add("sqlSessionFactory", this.sqlSessionFactory);
+              explicitFactoryUsed = true;
+          }
+          // <4.3> 如果 sqlSessionTemplateBeanName 或 sqlSessionTemplate 非空，设置到 `MapperFactoryBean.sqlSessionTemplate` 属性
+          if (StringUtils.hasText(this.sqlSessionTemplateBeanName)) {
+              if (explicitFactoryUsed) {
+                  LOGGER.warn(() -> "Cannot use both: sqlSessionTemplate and sqlSessionFactory together. sqlSessionFactory is ignored.");
+              }
+              definition.getPropertyValues().add("sqlSessionTemplate", new RuntimeBeanReference(this.sqlSessionTemplateBeanName));
+              explicitFactoryUsed = true;
+          } else if (this.sqlSessionTemplate != null) {
+              if (explicitFactoryUsed) {
+                  LOGGER.warn(() -> "Cannot use both: sqlSessionTemplate and sqlSessionFactory together. sqlSessionFactory is ignored.");
+              }
+              definition.getPropertyValues().add("sqlSessionTemplate", this.sqlSessionTemplate);
+              explicitFactoryUsed = true;
+          }
+          // <4.4> 如果未显式设置，则设置根据类型自动注入
+          if (!explicitFactoryUsed) {
+              LOGGER.debug(() -> "Enabling autowire by type for MapperFactoryBean with name '" + holder.getBeanName() + "'.");
+              definition.setAutowireMode(AbstractBeanDefinition.AUTOWIRE_BY_TYPE);
+          }
+      }
+  }
+  ```
+
+  - 虽然方法很长，重点就是修改 BeanDefinitionHolder 的相关属性。
+
+  - `<1>` 处，遍历 BeanDefinitionHolder 数组，逐一设置属性。
+
+  - `<2>` 处，此处 `definition` 的 `beanClass` 为 Mapper 接口，需要修改成 MapperFactoryBean 类，从而创建 Mapper 代理对象。
+
+  - `<3>` 处，设置 `MapperFactoryBean.addToConfig` 属性。
+
+  - ```
+    <4.1>
+    ```
+
+     
+
+    处，是否已经显式设置了
+
+     
+
+    ```
+    sqlSessionFactory 或 sqlSessionFactory
+    ```
+
+     
+
+    属性。
+
+    - `<4.2>` 处，如果 `sqlSessionFactoryBeanName` 或 `sqlSessionFactory` 非空，设置到 `MapperFactoryBean.sqlSessionFactory` 属性。
+    - `<4.3>` 处，如果 `sqlSessionTemplateBeanName` 或 `sqlSessionTemplate` 非空，设置到 `MapperFactoryBean.sqlSessionTemplate` 属性。
+    - `<4.4>` 处，如果未显式设置，**则设置根据类型自动注入**。
+
+### 4.3 @MapperScans
+
+`org.mybatis.spring.annotation.@MapperScans` ，多 `@MapperScan` 的注解，功能是相同的。代码如下：
+
+```
+// MapperScans.java
+
+@Retention(RetentionPolicy.RUNTIME)
+@Target(ElementType.TYPE)
+@Documented
+@Import(MapperScannerRegistrar.RepeatingRegistrar.class)
+public @interface MapperScans {
+
+    /**
+     * @return @MapperScan 数组
+     */
+    MapperScan[] value();
+
+}
+```
+
+- 此处，`@Import(MapperScannerRegistrar.RepeatingRegistrar.class)` 是 RepeatingRegistrar 类。
+
+### 4.4 RepeatingRegistrar
+
+RepeatingRegistrar ，是 MapperScannerRegistrar 的内部静态类，继承 MapperScannerRegistrar 类，`@MapperScans` 的注册器。代码如下：
+
+```
+// MapperScannerRegistrar.java
+
+static class RepeatingRegistrar extends MapperScannerRegistrar {
+    
+    @Override
+    public void registerBeanDefinitions(AnnotationMetadata importingClassMetadata, BeanDefinitionRegistry registry) {
+        // 获得 @MapperScans 注解信息
+        AnnotationAttributes mapperScansAttrs = AnnotationAttributes
+                .fromMap(importingClassMetadata.getAnnotationAttributes(MapperScans.class.getName()));
+        // 遍历 @MapperScans 的值，调用 `#registerBeanDefinitions(mapperScanAttrs, registry)` 方法，循环扫描处理
+        Arrays.stream(mapperScansAttrs.getAnnotationArray("value"))
+                .forEach(mapperScanAttrs -> registerBeanDefinitions(mapperScanAttrs, registry));
+    }
+
+}
+```
+
+- [「4.1.2 registerBeanDefinitions」](https://svip.iocoder.cn/MyBatis/Spring-Integration-2/#) 的**循环**版。
+
+# 5. 自定义 `<mybatis:scan />` 标签
+
+使用示例如下：
+
+```
+ <!-- Scan for mappers and let them be autowired; notice there is no
+     UserDaoImplementation needed. The required SqlSessionFactory will be
+     autowired. -->
+<mybatis:scan base-package="org.mybatis.spring.sample.mapper" />
+```
+
+- 该示例来自 `org.mybatis.spring.sample.SampleNamespaceTest` 单元测试。胖友可以基于它调试。
+
+简单来理解，`<mybatis:scan />` 标签，和 `@MapperScan` 注解，用途是等价的。
+
+## 5.1 spring.schemas
+
+MyBatis 在 `META-INF/spring.schemas` 定义如下：
+
+```
+http\://mybatis.org/schema/mybatis-spring-1.2.xsd=org/mybatis/spring/config/mybatis-spring.xsd
+http\://mybatis.org/schema/mybatis-spring.xsd=org/mybatis/spring/config/mybatis-spring.xsd
+```
+
+- xmlns 为 `http://mybatis.org/schema/mybatis-spring-1.2.xsd` 或 `http://mybatis.org/schema/mybatis-spring.xsd` 。
+- xsd 为 `org/mybatis/spring/config/mybatis-spring.xsd` 。
+
+## 5.2 mybatis-spring.xsd
+
+[![mybatis-spring.xsd](https://github.com/YunaiV/mybatis-spring/blob/master/src/main/java/org/mybatis/spring/config/mybatis-spring.xsd)](https://github.com/YunaiV/mybatis-spring/blob/master/src/main/java/org/mybatis/spring/config/mybatis-spring.xsd)mybatis-spring.xsd定义如下：[mybatis-spring.xsd](http://static.iocoder.cn/images/MyBatis/2020_06_04/01.png)
+
+## 5.3 spring.handler
+
+`spring.handlers` 定义如下：
+
+```
+http\://mybatis.org/schema/mybatis-spring=org.mybatis.spring.config.NamespaceHandler
+```
+
+定义了 MyBatis 的 XML Namespace 的处理器 NamespaceHandler 。
+
+## 5.4 NamespaceHandler
+
+`org.mybatis.spring.config.NamespaceHandler` ，继承 NamespaceHandlerSupport 抽象类，MyBatis 的 XML Namespace 的处理器。代码如下：
+
+```
+// NamespaceHandler.java
+
+public class NamespaceHandler extends NamespaceHandlerSupport {
+
+    @Override
+    public void init() {
+        registerBeanDefinitionParser("scan", new MapperScannerBeanDefinitionParser());
+    }
+
+}
+```
+
+- `<mybatis:scan />` 标签，使用 MapperScannerBeanDefinitionParser 解析。
+
+## 5.5 MapperScannerBeanDefinitionParser
+
+`org.mybatis.spring.config.MapperScannerBeanDefinitionParser` ，实现 BeanDefinitionParser 接口，`<mybatis:scan />` 的解析器。代码如下：
+
+```
+// BeanDefinitionParser.java
+
+public class MapperScannerBeanDefinitionParser implements BeanDefinitionParser {
+
+    private static final String ATTRIBUTE_BASE_PACKAGE = "base-package";
+    private static final String ATTRIBUTE_ANNOTATION = "annotation";
+    private static final String ATTRIBUTE_MARKER_INTERFACE = "marker-interface";
+    private static final String ATTRIBUTE_NAME_GENERATOR = "name-generator";
+    private static final String ATTRIBUTE_TEMPLATE_REF = "template-ref";
+    private static final String ATTRIBUTE_FACTORY_REF = "factory-ref";
+
+    /**
+     * {@inheritDoc}
+     */
+    @Override
+    public synchronized BeanDefinition parse(Element element, ParserContext parserContext) {
+        // 创建 ClassPathMapperScanner 对象
+        ClassPathMapperScanner scanner = new ClassPathMapperScanner(parserContext.getRegistry());
+        ClassLoader classLoader = scanner.getResourceLoader().getClassLoader();
+        XmlReaderContext readerContext = parserContext.getReaderContext();
+        scanner.setResourceLoader(readerContext.getResourceLoader()); // 设置 resourceLoader 属性
+        try {
+            // 解析 annotation 属性
+            String annotationClassName = element.getAttribute(ATTRIBUTE_ANNOTATION);
+            if (StringUtils.hasText(annotationClassName)) {
+                @SuppressWarnings("unchecked")
+                Class<? extends Annotation> markerInterface = (Class<? extends Annotation>) classLoader.loadClass(annotationClassName);
+                scanner.setAnnotationClass(markerInterface);
+            }
+            // 解析 marker-interface 属性
+            String markerInterfaceClassName = element.getAttribute(ATTRIBUTE_MARKER_INTERFACE);
+            if (StringUtils.hasText(markerInterfaceClassName)) {
+                Class<?> markerInterface = classLoader.loadClass(markerInterfaceClassName);
+                scanner.setMarkerInterface(markerInterface);
+            }
+            // 解析 name-generator 属性
+            String nameGeneratorClassName = element.getAttribute(ATTRIBUTE_NAME_GENERATOR);
+            if (StringUtils.hasText(nameGeneratorClassName)) {
+                Class<?> nameGeneratorClass = classLoader.loadClass(nameGeneratorClassName);
+                BeanNameGenerator nameGenerator = BeanUtils.instantiateClass(nameGeneratorClass, BeanNameGenerator.class);
+                scanner.setBeanNameGenerator(nameGenerator);
+            }
+        } catch (Exception ex) {
+            readerContext.error(ex.getMessage(), readerContext.extractSource(element), ex.getCause());
+        }
+        // 解析 template-ref 属性
+        String sqlSessionTemplateBeanName = element.getAttribute(ATTRIBUTE_TEMPLATE_REF);
+        scanner.setSqlSessionTemplateBeanName(sqlSessionTemplateBeanName);
+        // 解析 factory-ref 属性
+        String sqlSessionFactoryBeanName = element.getAttribute(ATTRIBUTE_FACTORY_REF);
+        scanner.setSqlSessionFactoryBeanName(sqlSessionFactoryBeanName);
+
+        // 注册 scanner 的过滤器
+        scanner.registerFilters();
+
+        // 获得要扫描的包
+        String basePackage = element.getAttribute(ATTRIBUTE_BASE_PACKAGE);
+        // 执行扫描
+        scanner.scan(StringUtils.tokenizeToStringArray(basePackage, ConfigurableApplicationContext.CONFIG_LOCATION_DELIMITERS));
+        return null;
+    }
+
+}
+```
+
+- 代码实现上，和 [「4.2 ClassPathMapperScanner」](https://svip.iocoder.cn/MyBatis/Spring-Integration-2/#) 是基本一致的。所以就不详细解析啦。
+
+# 6. MapperScannerConfigurer
+
+`org.mybatis.spring.mapper.MapperScannerConfigurer` ，实现 BeanDefinitionRegistryPostProcessor、InitializingBean、ApplicationContextAware、BeanNameAware 接口，定义需要扫描的包，将包中符合的 Mapper 接口，注册成 beanClass 为 MapperFactoryBean 的 BeanDefinition 对象，从而实现创建 Mapper 对象。
+
+使用示例如下：
+
+```
+// XML
+
+<!-- Scan for mappers and let them be autowired; notice there is no
+     UserDaoImplementation needed. The required SqlSessionFactory will be
+     autowired. -->
+<bean class="org.mybatis.spring.mapper.MapperScannerConfigurer">
+    <property name="basePackage" value="org.mybatis.spring.sample.mapper" />
+</bean>
+```
+
+- 该示例来自 `org.mybatis.spring.sample.MapperScannerConfigurer` 单元测试。胖友可以基于它调试。
+
+## 6.1 构造方法
+
+```
+// MapperScannerConfigurer.java
+
+private String basePackage;
+
+private boolean addToConfig = true;
+
+private SqlSessionFactory sqlSessionFactory;
+
+private SqlSessionTemplate sqlSessionTemplate;
+
+private String sqlSessionFactoryBeanName;
+
+private String sqlSessionTemplateBeanName;
+
+private Class<? extends Annotation> annotationClass;
+
+private Class<?> markerInterface;
+
+private ApplicationContext applicationContext;
+
+private String beanName;
+
+private boolean processPropertyPlaceHolders;
+
+private BeanNameGenerator nameGenerator;
+
+// 省略 setting 方法
+```
+
+## 6.2 afterPropertiesSet
+
+```
+// MapperScannerConfigurer.java
+
+@Override
+public void afterPropertiesSet() throws Exception {
+    notNull(this.basePackage, "Property 'basePackage' is required");
+}
+```
+
+- 啥都不做。
+
+## 6.3 postProcessBeanFactory
+
+```
+// MapperScannerConfigurer.java
+
+@Override
+public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) {
+    // left intentionally blank
+}
+```
+
+## 6.4 postProcessBeanDefinitionRegistry
+
+```
+// MapperScannerConfigurer.java
+
+@Override
+public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) {
+    // <1> 如果有属性占位符，则进行获得，例如 ${basePackage} 等等
+    if (this.processPropertyPlaceHolders) {
+        processPropertyPlaceHolders();
+    }
+
+    // <2> 创建 ClassPathMapperScanner 对象，并设置其相关属性
+    ClassPathMapperScanner scanner = new ClassPathMapperScanner(registry);
+    scanner.setAddToConfig(this.addToConfig);
+    scanner.setAnnotationClass(this.annotationClass);
+    scanner.setMarkerInterface(this.markerInterface);
+    scanner.setSqlSessionFactory(this.sqlSessionFactory);
+    scanner.setSqlSessionTemplate(this.sqlSessionTemplate);
+    scanner.setSqlSessionFactoryBeanName(this.sqlSessionFactoryBeanName);
+    scanner.setSqlSessionTemplateBeanName(this.sqlSessionTemplateBeanName);
+    scanner.setResourceLoader(this.applicationContext);
+    scanner.setBeanNameGenerator(this.nameGenerator);
+    // 注册 scanner 过滤器
+    scanner.registerFilters();
+    // 执行扫描
+    scanner.scan(StringUtils.tokenizeToStringArray(this.basePackage, ConfigurableApplicationContext.CONFIG_LOCATION_DELIMITERS));
+}
+```
+
+- `<1>` 处，调用 `#processPropertyPlaceHolders()` 方法，如果有属性占位符，则进行获得，例如 `${basePackage}` 等等。代码如下：
+
+  ```
+  // MapperScannerConfigurer.java
+  
+  private void processPropertyPlaceHolders() {
+      Map<String, PropertyResourceConfigurer> prcs = applicationContext.getBeansOfType(PropertyResourceConfigurer.class);
+  
+      if (!prcs.isEmpty() && applicationContext instanceof ConfigurableApplicationContext) {
+          BeanDefinition mapperScannerBean = ((ConfigurableApplicationContext) applicationContext)
+                  .getBeanFactory().getBeanDefinition(beanName);
+  
+          // PropertyResourceConfigurer does not expose any methods to explicitly perform
+          // property placeholder substitution. Instead, create a BeanFactory that just
+          // contains this mapper scanner and post process the factory.
+          DefaultListableBeanFactory factory = new DefaultListableBeanFactory();
+          factory.registerBeanDefinition(beanName, mapperScannerBean);
+  
+          for (PropertyResourceConfigurer prc : prcs.values()) {
+              prc.postProcessBeanFactory(factory);
+          }
+  
+          PropertyValues values = mapperScannerBean.getPropertyValues();
+  
+          this.basePackage = updatePropertyValue("basePackage", values);
+          this.sqlSessionFactoryBeanName = updatePropertyValue("sqlSessionFactoryBeanName", values);
+          this.sqlSessionTemplateBeanName = updatePropertyValue("sqlSessionTemplateBeanName", values);
+      }
+  }
+  
+  // 获得属性值，并转换成 String 类型
+  private String updatePropertyValue(String propertyName, PropertyValues values) {
+      PropertyValue property = values.getPropertyValue(propertyName);
+      Object value = property.getValue();
+      if (value instanceof String) {
+          return value.toString();
+      } else if (value instanceof TypedStringValue) {
+          return ((TypedStringValue) value).getValue();
+      } else {
+          return null;
+      }
+  }
+  ```
+
+- `<2>` 处，代码实现上，和 [「4.2 ClassPathMapperScanner」](https://svip.iocoder.cn/MyBatis/Spring-Integration-2/#) 是基本一致的。所以就不详细解析啦。
+
+# 666. 彩蛋
+
+略微冗长，但是易于理解的一篇文章。
+
+我们简单把 3 ~ 6 小节做个小结的话：
+
+- 「3」MapperFactoryBean 类，是最**基础**的、**单个**的负责创建 Mapper 代理对象的类。
+- 「4」「5」「6」，都是基于 MapperFactoryBean 之上，使用 ClassPathMapperScanner 扫描指定包，创建成 MapperFactoryBean 对象，从而创建 Mapper 代理对象。
\ No newline at end of file
diff --git a/mybatis/31-mybatis-Spring 集成（三）之 SqlSession.md b/mybatis/31-mybatis-Spring 集成（三）之 SqlSession.md
new file mode 100644
index 0000000..b0510c5
--- /dev/null
+++ b/mybatis/31-mybatis-Spring 集成（三）之 SqlSession.md	
@@ -0,0 +1,445 @@
+# 精尽 MyBatis 源码解析 —— Spring 集成（三）之 SqlSession
+
+# 1. 概述
+
+本文我们就来看看，Spring 和 MyBatis 的 SqlSession 是如何集成。
+
+# 2. SqlSessionTemplate
+
+`org.mybatis.spring.SqlSessionTemplate` ，实现 SqlSession、DisposableBean 接口，SqlSession 操作模板实现类。实际上，代码实现和 `org.apache.ibatis.session.SqlSessionManager` 超级相似。或者说，这是 `mybatis-spring` 项目实现的 “SqlSessionManager” 类。
+
+## 2.1 构造方法
+
+```
+// SqlSessionTemplate.java
+
+private final SqlSessionFactory sqlSessionFactory;
+
+/**
+ * 执行器类型
+ */
+private final ExecutorType executorType;
+/**
+ * SqlSession 代理对象
+ */
+private final SqlSession sqlSessionProxy;
+/**
+ * 异常转换器
+ */
+private final PersistenceExceptionTranslator exceptionTranslator;
+
+public SqlSessionTemplate(SqlSessionFactory sqlSessionFactory) {
+    this(sqlSessionFactory, sqlSessionFactory.getConfiguration().getDefaultExecutorType());
+}
+
+public SqlSessionTemplate(SqlSessionFactory sqlSessionFactory, ExecutorType executorType) {
+    this(sqlSessionFactory, executorType,
+            new MyBatisExceptionTranslator(
+                    sqlSessionFactory.getConfiguration().getEnvironment().getDataSource(), true));
+}
+
+public SqlSessionTemplate(SqlSessionFactory sqlSessionFactory, ExecutorType executorType,
+                          PersistenceExceptionTranslator exceptionTranslator) {
+
+    notNull(sqlSessionFactory, "Property 'sqlSessionFactory' is required");
+    notNull(executorType, "Property 'executorType' is required");
+
+    this.sqlSessionFactory = sqlSessionFactory;
+    this.executorType = executorType;
+    this.exceptionTranslator = exceptionTranslator;
+    // <1> 创建 sqlSessionProxy 对象
+    this.sqlSessionProxy = (SqlSession) newProxyInstance(
+            SqlSessionFactory.class.getClassLoader(),
+            new Class[]{SqlSession.class},
+            new SqlSessionInterceptor());
+}
+
+// ... 省略 setting 方法
+```
+
+- `executorType` 属性，执行器类型。后续，根据它来创建对应类型的执行器。
+- `sqlSessionProxy` 属性，SqlSession 代理对象。在 `<1>` 处，进行创建 `sqlSessionProxy` 对象，使用的方法拦截器是 SqlSessionInterceptor 类。😈 是不是发现和 SqlSessionManager 灰常像。
+- `exceptionTranslator` 属性，异常转换器。
+
+## 2.2 对 SqlSession 的实现方法
+
+① 如下是直接调用 `sqlSessionProxy` 对应的方法。代码如下：
+
+```
+// SqlSessionTemplate.java
+
+@Override
+public <T> T selectOne(String statement) {
+    return this.sqlSessionProxy.selectOne(statement);
+}
+
+@Override
+public <T> T selectOne(String statement, Object parameter) {
+    return this.sqlSessionProxy.selectOne(statement, parameter);
+}
+
+@Override
+public <K, V> Map<K, V> selectMap(String statement, String mapKey) {
+    return this.sqlSessionProxy.selectMap(statement, mapKey);
+}
+
+@Override
+public <K, V> Map<K, V> selectMap(String statement, Object parameter, String mapKey) {
+    return this.sqlSessionProxy.selectMap(statement, parameter, mapKey);
+}
+
+@Override
+public <K, V> Map<K, V> selectMap(String statement, Object parameter, String mapKey, RowBounds rowBounds) {
+    return this.sqlSessionProxy.selectMap(statement, parameter, mapKey, rowBounds);
+}
+
+@Override
+public <T> Cursor<T> selectCursor(String statement) {
+    return this.sqlSessionProxy.selectCursor(statement);
+}
+
+@Override
+public <T> Cursor<T> selectCursor(String statement, Object parameter) {
+    return this.sqlSessionProxy.selectCursor(statement, parameter);
+}
+
+@Override
+public <T> Cursor<T> selectCursor(String statement, Object parameter, RowBounds rowBounds) {
+    return this.sqlSessionProxy.selectCursor(statement, parameter, rowBounds);
+}
+
+@Override
+public <E> List<E> selectList(String statement) {
+    return this.sqlSessionProxy.selectList(statement);
+}
+
+@Override
+public <E> List<E> selectList(String statement, Object parameter) {
+    return this.sqlSessionProxy.selectList(statement, parameter);
+}
+
+@Override
+public <E> List<E> selectList(String statement, Object parameter, RowBounds rowBounds) {
+    return this.sqlSessionProxy.selectList(statement, parameter, rowBounds);
+}
+
+@Override
+public void select(String statement, ResultHandler handler) {
+    this.sqlSessionProxy.select(statement, handler);
+}
+
+@Override
+public void select(String statement, Object parameter, ResultHandler handler) {
+    this.sqlSessionProxy.select(statement, parameter, handler);
+}
+
+@Override
+public void select(String statement, Object parameter, RowBounds rowBounds, ResultHandler handler) {
+    this.sqlSessionProxy.select(statement, parameter, rowBounds, handler);
+}
+
+@Override
+public int insert(String statement) {
+    return this.sqlSessionProxy.insert(statement);
+}
+
+@Override
+public int insert(String statement, Object parameter) {
+    return this.sqlSessionProxy.insert(statement, parameter);
+}
+
+@Override
+public int update(String statement) {
+    return this.sqlSessionProxy.update(statement);
+}
+
+@Override
+public int update(String statement, Object parameter) {
+    return this.sqlSessionProxy.update(statement, parameter);
+}
+
+@Override
+public int delete(String statement) {
+    return this.sqlSessionProxy.delete(statement);
+}
+
+@Override
+public int delete(String statement, Object parameter) {
+    return this.sqlSessionProxy.delete(statement, parameter);
+}
+
+@Override
+public <T> T getMapper(Class<T> type) {
+    return getConfiguration().getMapper(type, this);
+}
+
+@Override
+public void clearCache() {
+    this.sqlSessionProxy.clearCache();
+}
+
+@Override
+public Configuration getConfiguration() {
+    return this.sqlSessionFactory.getConfiguration();
+}
+
+@Override
+public Connection getConnection() {
+    return this.sqlSessionProxy.getConnection();
+}
+
+@Override
+public List<BatchResult> flushStatements() {
+    return this.sqlSessionProxy.flushStatements();
+}
+```
+
+② 如下是不支持的方法，直接抛出 UnsupportedOperationException 异常。代码如下：
+
+```
+// SqlSessionTemplate.java
+
+@Override
+public void commit() {
+    throw new UnsupportedOperationException("Manual commit is not allowed over a Spring managed SqlSession");
+}
+
+@Override
+public void commit(boolean force) {
+    throw new UnsupportedOperationException("Manual commit is not allowed over a Spring managed SqlSession");
+}
+
+@Override
+public void rollback() {
+    throw new UnsupportedOperationException("Manual rollback is not allowed over a Spring managed SqlSession");
+}
+
+@Override
+public void rollback(boolean force) {
+    throw new UnsupportedOperationException("Manual rollback is not allowed over a Spring managed SqlSession");
+}
+
+@Override
+public void close() {
+    throw new UnsupportedOperationException("Manual close is not allowed over a Spring managed SqlSession");
+}
+```
+
+- 和事务相关的方法，不允许**手动**调用。
+
+## 2.3 destroy
+
+```
+// SqlSessionTemplate.java
+
+@Override
+public void destroy() throws Exception {
+    //This method forces spring disposer to avoid call of SqlSessionTemplate.close() which gives UnsupportedOperationException
+}
+```
+
+## 2.4 SqlSessionInterceptor
+
+SqlSessionInterceptor ，是 SqlSessionTemplate 的内部类，实现 InvocationHandler 接口，将 SqlSession 的操作，路由到 Spring 托管的事务管理器中。代码如下：
+
+```
+// SqlSessionTemplate.java
+
+/**
+ * Proxy needed to route MyBatis method calls to the proper SqlSession got
+ * from Spring's Transaction Manager
+ * It also unwraps exceptions thrown by {@code Method#invoke(Object, Object...)} to
+ * pass a {@code PersistenceException} to the {@code PersistenceExceptionTranslator}.
+ */
+private class SqlSessionInterceptor implements InvocationHandler {
+
+    @Override
+    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
+        // <1> 获得 SqlSession 对象
+        SqlSession sqlSession = getSqlSession(
+                SqlSessionTemplate.this.sqlSessionFactory,
+                SqlSessionTemplate.this.executorType,
+                SqlSessionTemplate.this.exceptionTranslator);
+        try {
+            // 执行 SQL 操作
+            Object result = method.invoke(sqlSession, args);
+            // 如果非 Spring 托管的 SqlSession 对象，则提交事务
+            if (!isSqlSessionTransactional(sqlSession, SqlSessionTemplate.this.sqlSessionFactory)) {
+                // force commit even on non-dirty sessions because some databases require
+                // a commit/rollback before calling close()
+                sqlSession.commit(true);
+            }
+            // 返回结果
+            return result;
+        } catch (Throwable t) {
+            // <4.1> 如果是 PersistenceException 异常，则进行转换
+            Throwable unwrapped = unwrapThrowable(t);
+            if (SqlSessionTemplate.this.exceptionTranslator != null && unwrapped instanceof PersistenceException) {
+                // release the connection to avoid a deadlock if the translator is no loaded. See issue #22
+                // <4.2> 根据情况，关闭 SqlSession 对象
+                // 如果非 Spring 托管的 SqlSession 对象，则关闭 SqlSession 对象
+                // 如果是 Spring 托管的 SqlSession 对象，则减少其 SqlSessionHolder 的计数
+                closeSqlSession(sqlSession, SqlSessionTemplate.this.sqlSessionFactory);
+                // <4.3> 置空，避免下面 final 又做处理
+                sqlSession = null;
+                // <4.4> 进行转换
+                Throwable translated = SqlSessionTemplate.this.exceptionTranslator.translateExceptionIfPossible((PersistenceException) unwrapped);
+                if (translated != null) {
+                    unwrapped = translated;
+                }
+            }
+            // <4.5> 抛出异常
+            throw unwrapped;
+        } finally {
+            // <5> 根据情况，关闭 SqlSession 对象
+            // 如果非 Spring 托管的 SqlSession 对象，则关闭 SqlSession 对象
+            // 如果是 Spring 托管的 SqlSession 对象，则减少其 SqlSessionHolder 的计数
+            if (sqlSession != null) {
+                closeSqlSession(sqlSession, SqlSessionTemplate.this.sqlSessionFactory);
+            }
+        }
+    }
+}
+```
+
+- 类上的英文注释，胖友可以耐心看下。
+
+- `<1>` 处，调用 `SqlSessionUtils#getSqlSession(SqlSessionFactory sessionFactory, ExecutorType executorType, PersistenceExceptionTranslator exceptionTranslator)` 方法，获得 SqlSession 对象。此处，和 Spring 事务托管的事务已经相关。详细的解析，见 [《精尽 MyBatis 源码解析 —— Spring 集成（四）之事务》](http://svip.iocoder.cn/MyBatis/Spring-Integration-4) 中。下面，和事务相关的，我们也统一放在该文中。
+
+- `<2>` 处，调用 `Method#invoke(sqlSession, args)` 方法，**反射执行 SQL 操作**。
+
+- `<3>` 处，调用 `SqlSessionUtils#isSqlSessionTransactional(SqlSession session, SqlSessionFactory sessionFactory)` 方法，判断是否为**非** Spring 托管的 SqlSession 对象，则调用 `SqlSession#commit(true)` 方法，提交事务。
+
+- ```
+  <4.1>
+  ```
+
+   
+
+  处，如果是 PersistenceException 异常，则：
+
+  - `<4.2>` 处，调用 `SqlSessionUtils#closeSqlSession(SqlSession session, SqlSessionFactory sessionFactory)` 方法，根据情况，关闭 SqlSession 对象。1）如果非 Spring 托管的 SqlSession 对象，则关闭 SqlSession 对象。2）如果是 Spring 托管的 SqlSession 对象，则减少其 SqlSessionHolder 的计数。😈 也就是说，Spring 托管事务的情况下，最终是在“外部”执行最终的事务处理。
+  - `<4.3>` 处，置空 `sqlSession` 属性，避免下面 `final` 又做关闭处理。
+  - `<4.4>` 处，调用 `MyBatisExceptionTranslator#translateExceptionIfPossible(RuntimeException e)` 方法，转换异常。
+  - `<4.5>` 处，抛出异常。
+
+- `<5>` 处，如果 `sqlSession` 非空，则调用 `SqlSessionUtils#closeSqlSession(SqlSession session, SqlSessionFactory sessionFactory)` 方法，根据情况，关闭 SqlSession 对象。
+
+# 3. SqlSessionDaoSupport
+
+`org.mybatis.spring.support.SqlSessionDaoSupport` ，继承 DaoSupport 抽象类，SqlSession 的 DaoSupport 抽象类。代码如下：
+
+```
+// SqlSessionDaoSupport.java
+
+public abstract class SqlSessionDaoSupport extends DaoSupport {
+
+    /**
+     * SqlSessionTemplate 对象
+     */
+    private SqlSessionTemplate sqlSessionTemplate;
+
+    /**
+     * Set MyBatis SqlSessionFactory to be used by this DAO.
+     * Will automatically create SqlSessionTemplate for the given SqlSessionFactory.
+     *
+     * @param sqlSessionFactory a factory of SqlSession
+     */
+    public void setSqlSessionFactory(SqlSessionFactory sqlSessionFactory) {
+        if (this.sqlSessionTemplate == null || sqlSessionFactory != this.sqlSessionTemplate.getSqlSessionFactory()) {
+            this.sqlSessionTemplate = createSqlSessionTemplate(sqlSessionFactory); // 使用 sqlSessionFactory 属性，创建 sqlSessionTemplate 对象
+        }
+    }
+
+    /**
+     * Create a SqlSessionTemplate for the given SqlSessionFactory.
+     * Only invoked if populating the DAO with a SqlSessionFactory reference!
+     * <p>Can be overridden in subclasses to provide a SqlSessionTemplate instance
+     * with different configuration, or a custom SqlSessionTemplate subclass.
+     * @param sqlSessionFactory the MyBatis SqlSessionFactory to create a SqlSessionTemplate for
+     * @return the new SqlSessionTemplate instance
+     * @see #setSqlSessionFactory
+     */
+    @SuppressWarnings("WeakerAccess")
+    protected SqlSessionTemplate createSqlSessionTemplate(SqlSessionFactory sqlSessionFactory) {
+        return new SqlSessionTemplate(sqlSessionFactory);
+    }
+
+    /**
+     * Return the MyBatis SqlSessionFactory used by this DAO.
+     *
+     * @return a factory of SqlSession
+     */
+    public final SqlSessionFactory getSqlSessionFactory() {
+        return (this.sqlSessionTemplate != null ? this.sqlSessionTemplate.getSqlSessionFactory() : null);
+    }
+
+
+    /**
+     * Set the SqlSessionTemplate for this DAO explicitly,
+     * as an alternative to specifying a SqlSessionFactory.
+     *
+     * @param sqlSessionTemplate a template of SqlSession
+     * @see #setSqlSessionFactory
+     */
+    public void setSqlSessionTemplate(SqlSessionTemplate sqlSessionTemplate) {
+        this.sqlSessionTemplate = sqlSessionTemplate;
+    }
+
+    /**
+     * Users should use this method to get a SqlSession to call its statement methods
+     * This is SqlSession is managed by spring. Users should not commit/rollback/close it
+     * because it will be automatically done.
+     *
+     * @return Spring managed thread safe SqlSession
+     */
+    public SqlSession getSqlSession() {
+        return this.sqlSessionTemplate;
+    }
+
+    /**
+     * Return the SqlSessionTemplate for this DAO,
+     * pre-initialized with the SessionFactory or set explicitly.
+     * <p><b>Note: The returned SqlSessionTemplate is a shared instance.</b>
+     * You may introspect its configuration, but not modify the configuration
+     * (other than from within an {@link #initDao} implementation).
+     * Consider creating a custom SqlSessionTemplate instance via
+     * {@code new SqlSessionTemplate(getSqlSessionFactory())}, in which case
+     * you're allowed to customize the settings on the resulting instance.
+     *
+     * @return a template of SqlSession
+     */
+    public SqlSessionTemplate getSqlSessionTemplate() {
+        return this.sqlSessionTemplate;
+    }
+
+    /**
+     * {@inheritDoc}
+     */
+    @Override
+    protected void checkDaoConfig() {
+        notNull(this.sqlSessionTemplate, "Property 'sqlSessionFactory' or 'sqlSessionTemplate' are required");
+    }
+
+}
+```
+
+- 主要用途是，`sqlSessionTemplate` 属性的初始化，或者注入。
+- 具体示例，可以看看 `org.mybatis.spring.sample.dao.UserDaoImpl` 类。
+
+# 4. 异常相关
+
+`mybatis-spring` 项目中，有两个异常相关的类：
+
+- `org.mybatis.spring.MyBatisExceptionTranslator` ，MyBatis 自定义的异常转换器。
+- `org.mybatis.spring.MyBatisSystemException` ，MyBatis 自定义的异常类。
+
+代码比较简单，胖友自己去看。
+
+# 666. 彩蛋
+
+简单水更，哈哈哈哈。
+
+参考和推荐如下文章：
+
+- 大新博客 [《Mybatis SqlSessionTemplate 源码解析》](https://www.cnblogs.com/daxin/p/3544188.html)
\ No newline at end of file
diff --git a/mybatis/32-mybatis-Spring 集成（四）之事务.md b/mybatis/32-mybatis-Spring 集成（四）之事务.md
new file mode 100644
index 0000000..3947bed
--- /dev/null
+++ b/mybatis/32-mybatis-Spring 集成（四）之事务.md	
@@ -0,0 +1,694 @@
+# 精尽 MyBatis 源码解析 —— Spring 集成（四）之事务
+
+# 1. 概述
+
+本文我们就来看看，Spring 和 MyBatis 的**事务**是如何集成。需要胖友阅读的前置文章是：
+
+- [《精尽 MyBatis 源码分析 —— 事务模块》](http://svip.iocoder.cn/MyBatis/transaction-package/)
+- [《精尽 Spring 源码分析 —— Transaction 源码简单导读》](http://svip.iocoder.cn/Spring/transaction-simple-intro/) 需要胖友对 Spring Transaction 有源码级的了解，否则对该文章，会有点懵逼。
+
+# 2. SpringManagedTransaction
+
+`org.mybatis.spring.transaction.SpringManagedTransaction` ，实现 `org.apache.ibatis.transaction.Transaction` 接口，Spring 托管事务的 Transaction 实现类。
+
+## 2.1 构造方法
+
+```
+// SpringManagedTransaction.java
+
+/**
+ * DataSource 对象
+ */
+private final DataSource dataSource;
+/**
+ * Connection 对象
+ */
+private Connection connection;
+/**
+ * 当前连接是否处于事务中
+ *
+ * @see DataSourceUtils#isConnectionTransactional(Connection, DataSource)
+ */
+private boolean isConnectionTransactional;
+/**
+ * 是否自动提交
+ */
+private boolean autoCommit;
+
+public SpringManagedTransaction(DataSource dataSource) {
+    notNull(dataSource, "No DataSource specified");
+    this.dataSource = dataSource;
+}
+```
+
+## 2.2 getConnection
+
+`#getConnection()` 方法，获得连接。代码如下：
+
+```
+// SpringManagedTransaction.java
+
+@Override
+public Connection getConnection() throws SQLException {
+    if (this.connection == null) {
+        // 如果连接不存在，获得连接
+        openConnection();
+    }
+    return this.connection;
+}
+```
+
+- 如果 `connection` 为空，则调用 `#openConnection()` 方法，获得连接。代码如下：
+
+  ```
+  // SpringManagedTransaction.java
+  
+  /**
+   * Gets a connection from Spring transaction manager and discovers if this
+   * {@code Transaction} should manage connection or let it to Spring.
+   * <p>
+   * It also reads autocommit setting because when using Spring Transaction MyBatis
+   * thinks that autocommit is always false and will always call commit/rollback
+   * so we need to no-op that calls.
+   */
+  private void openConnection() throws SQLException {
+      // 获得连接
+      this.connection = DataSourceUtils.getConnection(this.dataSource);
+      this.autoCommit = this.connection.getAutoCommit();
+      this.isConnectionTransactional = DataSourceUtils.isConnectionTransactional(this.connection, this.dataSource);
+  
+      LOGGER.debug(() ->
+              "JDBC Connection ["
+                      + this.connection
+                      + "] will"
+                      + (this.isConnectionTransactional ? " " : " not ")
+                      + "be managed by Spring");
+  }
+  ```
+
+  - 比较有趣的是，此处获取连接，不是通过 `DataSource#getConnection()` 方法，而是通过 `org.springframework.jdbc.datasource.DataSourceUtils#getConnection(DataSource dataSource)` 方法，获得 Connection 对象。而实际上，基于 Spring Transaction 体系，如果此处正在**事务中**时，已经有和当前线程绑定的 Connection 对象，就是存储在 ThreadLocal 中。
+
+## 2.3 commit
+
+`#commit()` 方法，提交事务。代码如下：
+
+```
+// SpringManagedTransaction.java
+
+@Override
+public void commit() throws SQLException {
+    if (this.connection != null && !this.isConnectionTransactional && !this.autoCommit) {
+        LOGGER.debug(() -> "Committing JDBC Connection [" + this.connection + "]");
+        this.connection.commit();
+    }
+}
+```
+
+## 2.4 rollback
+
+`#rollback()` 方法，回滚事务。代码如下：
+
+```
+// SpringManagedTransaction.java
+
+@Override
+public void rollback() throws SQLException {
+    if (this.connection != null && !this.isConnectionTransactional && !this.autoCommit) {
+        LOGGER.debug(() -> "Rolling back JDBC Connection [" + this.connection + "]");
+        this.connection.rollback();
+    }
+}
+```
+
+## 2.5 close
+
+`#close()` 方法，释放连接。代码如下：
+
+```
+// SpringManagedTransaction.java
+
+@Override
+public void close() throws SQLException {
+    DataSourceUtils.releaseConnection(this.connection, this.dataSource);
+}
+```
+
+- 比较有趣的是，此处获取连接，不是通过 `Connection#close()` 方法，而是通过 `org.springframework.jdbc.datasource.DataSourceUtils#releaseConnection(Connection connection,DataSource dataSource)` 方法，“释放”连接。但是，具体会不会关闭连接，根据当前线程绑定的 Connection 对象，是不是传入的 `connection` 参数。
+
+## 2.6 getTimeout
+
+```
+// SpringManagedTransaction.java
+
+@Override
+public Integer getTimeout() throws SQLException {
+    ConnectionHolder holder = (ConnectionHolder) TransactionSynchronizationManager.getResource(dataSource);
+    if (holder != null && holder.hasTimeout()) {
+        return holder.getTimeToLiveInSeconds();
+    }
+    return null;
+}
+```
+
+# 3. SpringManagedTransactionFactory
+
+`org.mybatis.spring.transaction.SpringManagedTransactionFactory` ，实现 TransactionFactory 接口，SpringManagedTransaction 的工厂实现类。代码如下：
+
+```
+// SpringManagedTransactionFactory.java
+
+public class SpringManagedTransactionFactory implements TransactionFactory {
+
+    @Override
+    public Transaction newTransaction(DataSource dataSource, TransactionIsolationLevel level, boolean autoCommit) {
+        // 创建 SpringManagedTransaction 对象
+        return new SpringManagedTransaction(dataSource);
+    }
+
+    @Override
+    public Transaction newTransaction(Connection conn) {
+        // 抛出异常，因为 Spring 事务，需要一个 DataSource 对象
+        throw new UnsupportedOperationException("New Spring transactions require a DataSource");
+    }
+
+    @Override
+    public void setProperties(Properties props) {
+        // not needed in this version
+    }
+
+}
+```
+
+# 4. SqlSessionHolder
+
+`org.mybatis.spring.SqlSessionHolder` ，继承 `org.springframework.transaction.support.ResourceHolderSupport` 抽象类，SqlSession 持有器，用于保存当前 SqlSession 对象，保存到 `org.springframework.transaction.support.TransactionSynchronizationManager` 中。代码如下：
+
+```
+// SqlSessionHolder.java
+
+/**
+ * Used to keep current {@code SqlSession} in {@code TransactionSynchronizationManager}.
+ *
+ * The {@code SqlSessionFactory} that created that {@code SqlSession} is used as a key.
+ * {@code ExecutorType} is also kept to be able to check if the user is trying to change it
+ * during a TX (that is not allowed) and throw a Exception in that case.
+ *
+ * SqlSession 持有器，用于保存当前 SqlSession 对象，保存到 TransactionSynchronizationManager 中
+ *
+ * @author Hunter Presnall
+ * @author Eduardo Macarron
+ */
+public final class SqlSessionHolder extends ResourceHolderSupport {
+
+    /**
+     * SqlSession 对象
+     */
+    private final SqlSession sqlSession;
+    /**
+     * 执行器类型
+     */
+    private final ExecutorType executorType;
+    /**
+     * PersistenceExceptionTranslator 对象
+     */
+    private final PersistenceExceptionTranslator exceptionTranslator;
+
+    /**
+     * Creates a new holder instance.
+     *
+     * @param sqlSession the {@code SqlSession} has to be hold.
+     * @param executorType the {@code ExecutorType} has to be hold.
+     * @param exceptionTranslator the {@code PersistenceExceptionTranslator} has to be hold.
+     */
+    public SqlSessionHolder(SqlSession sqlSession,
+                            ExecutorType executorType,
+                            PersistenceExceptionTranslator exceptionTranslator) {
+        notNull(sqlSession, "SqlSession must not be null");
+        notNull(executorType, "ExecutorType must not be null");
+
+        this.sqlSession = sqlSession;
+        this.executorType = executorType;
+        this.exceptionTranslator = exceptionTranslator;
+    }
+
+    // ... 省略 getting 方法
+
+}
+```
+
+- 当存储到 TransactionSynchronizationManager 中时，使用的 KEY 为创建该 SqlSession 对象的 SqlSessionFactory 对象。详细解析，见 `SqlSessionUtils#registerSessionHolder(...)` 方法。
+
+# 5. SqlSessionUtils
+
+`org.mybatis.spring.SqlSessionUtils` ，SqlSession 工具类。它负责处理 MyBatis SqlSession 的生命周期。它可以从 Spring TransactionSynchronizationManager 中，注册和获得对应的 SqlSession 对象。同时，它也支持当前不处于事务的情况下。
+
+😈 当然，这个描述看起来，有点绕。所以，我们直接干起代码。
+
+## 5.1 构造方法
+
+```
+// SqlSessionUtils.java
+
+private static final String NO_EXECUTOR_TYPE_SPECIFIED = "No ExecutorType specified";
+private static final String NO_SQL_SESSION_FACTORY_SPECIFIED = "No SqlSessionFactory specified";
+private static final String NO_SQL_SESSION_SPECIFIED = "No SqlSession specified";
+
+/**
+ * This class can't be instantiated, exposes static utility methods only.
+ */
+private SqlSessionUtils() {
+    // do nothing
+}
+```
+
+- 空的，直接跳过。
+
+## 5.2 getSqlSession
+
+`#getSqlSession(SqlSessionFactory sessionFactory, ...)` 方法，获得 SqlSession 对象。代码如下：
+
+```
+// SqlSessionUtils.java
+
+/**
+ * Creates a new MyBatis {@code SqlSession} from the {@code SqlSessionFactory}
+ * provided as a parameter and using its {@code DataSource} and {@code ExecutorType}
+ *
+ * @param sessionFactory a MyBatis {@code SqlSessionFactory} to create new sessions
+ * @return a MyBatis {@code SqlSession}
+ * @throws TransientDataAccessResourceException if a transaction is active and the
+ *             {@code SqlSessionFactory} is not using a {@code SpringManagedTransactionFactory}
+ */
+public static SqlSession getSqlSession(SqlSessionFactory sessionFactory) {
+    // 获得执行器类型
+    ExecutorType executorType = sessionFactory.getConfiguration().getDefaultExecutorType();
+    // 获得 SqlSession 对象
+    return getSqlSession(sessionFactory, executorType, null);
+}
+
+/**
+ * Gets an SqlSession from Spring Transaction Manager or creates a new one if needed.
+ * Tries to get a SqlSession out of current transaction. If there is not any, it creates a new one.
+ * Then, it synchronizes the SqlSession with the transaction if Spring TX is active and
+ * <code>SpringManagedTransactionFactory</code> is configured as a transaction manager.
+ *
+ * @param sessionFactory a MyBatis {@code SqlSessionFactory} to create new sessions
+ * @param executorType The executor type of the SqlSession to create
+ * @param exceptionTranslator Optional. Translates SqlSession.commit() exceptions to Spring exceptions.
+ * @return an SqlSession managed by Spring Transaction Manager
+ * @throws TransientDataAccessResourceException if a transaction is active and the
+ *             {@code SqlSessionFactory} is not using a {@code SpringManagedTransactionFactory}
+ * @see SpringManagedTransactionFactory
+ */
+public static SqlSession getSqlSession(SqlSessionFactory sessionFactory, ExecutorType executorType, PersistenceExceptionTranslator exceptionTranslator) {
+    notNull(sessionFactory, NO_SQL_SESSION_FACTORY_SPECIFIED);
+    notNull(executorType, NO_EXECUTOR_TYPE_SPECIFIED);
+
+    // <1> 获得 SqlSessionHolder 对象
+    SqlSessionHolder holder = (SqlSessionHolder) TransactionSynchronizationManager.getResource(sessionFactory);
+
+    // <2.1> 获得 SqlSession 对象
+    SqlSession session = sessionHolder(executorType, holder);
+    if (session != null) { // <2.2> 如果非空，直接返回
+        return session;
+    }
+
+    LOGGER.debug(() -> "Creating a new SqlSession");
+    // <3.1> 创建 SqlSession 对象
+    session = sessionFactory.openSession(executorType);
+    // <3.2> 注册到 TransactionSynchronizationManager 中
+    registerSessionHolder(sessionFactory, executorType, exceptionTranslator, session);
+
+    return session;
+}
+```
+
+- 我们先看看每一步的作用，然后胖友在自己看下上面的英文注释，嘿嘿。
+
+- `<1>` 处，调用 `TransactionSynchronizationManager#getResource(sessionFactory)` 方法，获得 SqlSessionHolder 对象。为什么可以获取到呢？答案在 `<3.2>` 中。关于 TransactionSynchronizationManager 类，如果不熟悉的胖友，真的真的真的，先去看懂 Spring Transaction 体系。
+
+- `<2.1>` 处，调用 `#sessionHolder(ExecutorType executorType, SqlSessionHolder holder)` 方法，从 SqlSessionHolder 中，获得 SqlSession 对象。代码如下：
+
+  ```
+  // SqlSessionUtils.java
+  
+  private static SqlSession sessionHolder(ExecutorType executorType, SqlSessionHolder holder) {
+      SqlSession session = null;
+      if (holder != null && holder.isSynchronizedWithTransaction()) {
+          // 如果执行器类型发生了变更，抛出 TransientDataAccessResourceException 异常
+          if (holder.getExecutorType() != executorType) {
+              throw new TransientDataAccessResourceException("Cannot change the ExecutorType when there is an existing transaction");
+          }
+  
+          // <1> 增加计数
+          holder.requested();
+  
+          LOGGER.debug(() -> "Fetched SqlSession [" + holder.getSqlSession() + "] from current transaction");
+          // <2> 获得 SqlSession 对象
+          session = holder.getSqlSession();
+      }
+      return session;
+  }
+  ```
+
+  - `<1>` 处，调用 `SqlSessionHolder#requested()` 方法，增加计数。注意，这个的计数，是用于关闭 SqlSession 时使用。详细解析，见 TODO 方法。
+  - `<2>` 处，调用 `SqlSessionHolder#getSqlSession()` 方法，获得 SqlSession 对象。
+
+- `<2.2>` 处，如果非空，直接返回。
+
+- `<3.1>` 处，调用 `SqlSessionFactory#openSession(executorType)` 方法，创建 SqlSession 对象。其中，使用的执行器类型，由传入的 `executorType` 方法参数所决定。
+
+- `<3.2>` 处，调用 `#registerSessionHolder(SqlSessionFactory sessionFactory, ExecutorType executorType, PersistenceExceptionTranslator exceptionTranslator, SqlSession session)` 方法，注册 SqlSession 对象，到 TransactionSynchronizationManager 中。代码如下：
+
+  ```
+  // SqlSessionUtils.java
+  
+  /**
+   * Register session holder if synchronization is active (i.e. a Spring TX is active).
+   *
+   * Note: The DataSource used by the Environment should be synchronized with the
+   * transaction either through DataSourceTxMgr or another tx synchronization.
+   * Further assume that if an exception is thrown, whatever started the transaction will
+   * handle closing / rolling back the Connection associated with the SqlSession.
+   *
+   * @param sessionFactory sqlSessionFactory used for registration.
+   * @param executorType executorType used for registration.
+   * @param exceptionTranslator persistenceExceptionTranslator used for registration.
+   * @param session sqlSession used for registration.
+   */
+  private static void registerSessionHolder(SqlSessionFactory sessionFactory, ExecutorType executorType,
+                                            PersistenceExceptionTranslator exceptionTranslator, SqlSession session) {
+      SqlSessionHolder holder;
+      if (TransactionSynchronizationManager.isSynchronizationActive()) {
+          Environment environment = sessionFactory.getConfiguration().getEnvironment();
+  
+          // <1> 如果使用 Spring 事务管理器
+          if (environment.getTransactionFactory() instanceof SpringManagedTransactionFactory) {
+              LOGGER.debug(() -> "Registering transaction synchronization for SqlSession [" + session + "]");
+  
+              // <1.1> 创建 SqlSessionHolder 对象
+              holder = new SqlSessionHolder(session, executorType, exceptionTranslator);
+              // <1.2> 绑定到 TransactionSynchronizationManager 中
+              TransactionSynchronizationManager.bindResource(sessionFactory, holder);
+              // <1.3> 创建 SqlSessionSynchronization 到 TransactionSynchronizationManager 中
+              TransactionSynchronizationManager.registerSynchronization(new SqlSessionSynchronization(holder, sessionFactory));
+              // <1.4> 设置同步
+              holder.setSynchronizedWithTransaction(true);
+              // <1.5> 增加计数
+              holder.requested();
+          // <2> 如果非 Spring 事务管理器，抛出 TransientDataAccessResourceException 异常
+          } else {
+              TransactionSynchronizationManager.getResource(environment.getDataSource());
+              throw new TransientDataAccessResourceException(
+                      "SqlSessionFactory must be using a SpringManagedTransactionFactory in order to use Spring transaction synchronization");
+          }
+      } else {
+          LOGGER.debug(() -> "SqlSession [" + session + "] was not registered for synchronization because synchronization is not active");
+      }
+  }
+  ```
+
+  - `<2>` 处，如果非 Spring 事务管理器，抛出 TransientDataAccessResourceException 异常。
+
+  - ```
+    <1>
+    ```
+
+     
+
+    处，如果使用 Spring 事务管理器(
+
+     
+
+    SpringManagedTransactionFactory
+
+     
+
+    )，则进行注册。
+
+    - `<1.1>` 处，将 `sqlSession` 封装成 SqlSessionHolder 对象。
+    - `<1.2>` 处，调用 `TransactionSynchronizationManager#bindResource(sessionFactory, holder)` 方法，绑定 `holder` 到 TransactionSynchronizationManager 中。**注意**，此时的 KEY 是 `sessionFactory` ，就创建 `sqlSession` 的 SqlSessionFactory 对象。
+    - `<1.3>` 处，创建 SqlSessionSynchronization 到 TransactionSynchronizationManager 中。详细解析，见 [「6. SqlSessionSynchronization」](https://svip.iocoder.cn/MyBatis/Spring-Integration-4/#) 。
+    - `<1.4>` 处，设置同步。
+    - `<1.5>` 处，调用 `SqlSessionHolder#requested()` 方法，增加计数。
+
+## 5.3 isSqlSessionTransactional
+
+`#isSqlSessionTransactional(SqlSession session, SqlSessionFactory sessionFactory)` 方法，判断传入的 SqlSession 参数，是否在 Spring 事务中。代码如下：
+
+```
+// SqlSessionUtils.java
+
+/**
+ * Returns if the {@code SqlSession} passed as an argument is being managed by Spring
+ *
+ * @param session a MyBatis SqlSession to check
+ * @param sessionFactory the SqlSessionFactory which the SqlSession was built with
+ * @return true if session is transactional, otherwise false
+ */
+public static boolean isSqlSessionTransactional(SqlSession session, SqlSessionFactory sessionFactory) {
+    notNull(session, NO_SQL_SESSION_SPECIFIED);
+    notNull(sessionFactory, NO_SQL_SESSION_FACTORY_SPECIFIED);
+
+    // 从 TransactionSynchronizationManager 中，获得 SqlSessionHolder 对象
+    SqlSessionHolder holder = (SqlSessionHolder) TransactionSynchronizationManager.getResource(sessionFactory);
+    // 如果相等，说明在 Spring 托管的事务中
+    return (holder != null) && (holder.getSqlSession() == session);
+}
+```
+
+- 代码比较简单，直接看注释。
+
+## 5.4 closeSqlSession
+
+`#closeSqlSession(SqlSession session, SqlSessionFactory sessionFactory)` 方法，关闭 SqlSession 对象。代码如下：
+
+```
+// SqlSessionUtils.java
+
+/**
+ * Checks if {@code SqlSession} passed as an argument is managed by Spring {@code TransactionSynchronizationManager}
+ * If it is not, it closes it, otherwise it just updates the reference counter and
+ * lets Spring call the close callback when the managed transaction ends
+ *
+ * @param session a target SqlSession
+ * @param sessionFactory a factory of SqlSession
+ */
+public static void closeSqlSession(SqlSession session, SqlSessionFactory sessionFactory) {
+    notNull(session, NO_SQL_SESSION_SPECIFIED);
+    notNull(sessionFactory, NO_SQL_SESSION_FACTORY_SPECIFIED);
+
+    // <1> 从 TransactionSynchronizationManager 中，获得 SqlSessionHolder 对象
+    SqlSessionHolder holder = (SqlSessionHolder) TransactionSynchronizationManager.getResource(sessionFactory);
+
+    // <2.1> 如果相等，说明在 Spring 托管的事务中，则释放 holder 计数
+    if ((holder != null) && (holder.getSqlSession() == session)) {
+        LOGGER.debug(() -> "Releasing transactional SqlSession [" + session + "]");
+        holder.released();
+    // <2.2> 如果不相等，说明不在 Spring 托管的事务中，直接关闭 SqlSession 对象
+    } else {
+        LOGGER.debug(() -> "Closing non transactional SqlSession [" + session + "]");
+        session.close();
+    }
+}
+```
+
+- `<1>` 处，从 TransactionSynchronizationManager 中，获得 SqlSessionHolder 对象。
+- `<2.1>` 处，如果相等，说明在 Spring 托管的事务中，则释放 `holder` 计数。那有什么用呢？具体原因，见 [「6. SqlSessionSynchronization」](https://svip.iocoder.cn/MyBatis/Spring-Integration-4/#) 。
+- `<2.2>` 处，如果不相等，说明不在 Spring 托管的事务中，直接关闭 SqlSession 对象。
+
+# 6. SqlSessionSynchronization
+
+SqlSessionSynchronization ，是 SqlSessionUtils 的内部类，继承 TransactionSynchronizationAdapter 抽象类，SqlSession 的 同步器，基于 Spring Transaction 体系。
+
+```
+/**
+ * Callback for cleaning up resources. It cleans TransactionSynchronizationManager and
+ * also commits and closes the {@code SqlSession}.
+ * It assumes that {@code Connection} life cycle will be managed by
+ * {@code DataSourceTransactionManager} or {@code JtaTransactionManager}
+ */
+```
+
+## 6.1 构造方法
+
+```
+// SqlSessionSynchronization.java
+
+/**
+ * SqlSessionHolder 对象
+ */
+private final SqlSessionHolder holder;
+/**
+ * SqlSessionFactory 对象
+ */
+private final SqlSessionFactory sessionFactory;
+/**
+ * 是否开启
+ */
+private boolean holderActive = true;
+
+public SqlSessionSynchronization(SqlSessionHolder holder, SqlSessionFactory sessionFactory) {
+    notNull(holder, "Parameter 'holder' must be not null");
+    notNull(sessionFactory, "Parameter 'sessionFactory' must be not null");
+
+    this.holder = holder;
+    this.sessionFactory = sessionFactory;
+}
+```
+
+## 6.2 getOrder
+
+```
+// SqlSessionSynchronization.java
+
+@Override
+public int getOrder() {
+    // order right before any Connection synchronization
+    return DataSourceUtils.CONNECTION_SYNCHRONIZATION_ORDER - 1;
+}
+```
+
+## 6.3 suspend
+
+`#suspend()` 方法，当事务挂起时，取消当前线程的绑定的 SqlSessionHolder 对象。代码如下：
+
+```
+// SqlSessionSynchronization.java
+
+@Override
+public void suspend() {
+    if (this.holderActive) {
+        LOGGER.debug(() -> "Transaction synchronization suspending SqlSession [" + this.holder.getSqlSession() + "]");
+        TransactionSynchronizationManager.unbindResource(this.sessionFactory);
+    }
+}
+```
+
+## 6.4 resume
+
+`#resume()` 方法，当事务恢复时，重新绑定当前线程的 SqlSessionHolder 对象。代码如下：
+
+```
+// SqlSessionSynchronization.java
+
+public void resume() {
+    if (this.holderActive) {
+        LOGGER.debug(() -> "Transaction synchronization resuming SqlSession [" + this.holder.getSqlSession() + "]");
+        TransactionSynchronizationManager.bindResource(this.sessionFactory, this.holder);
+    }
+}
+```
+
+- 因为，当前 SqlSessionSynchronization 对象中，有 `holder` 对象，所以可以直接恢复。
+
+## 6.5 beforeCommit
+
+`#beforeCommit(boolean readOnly)` 方法，在事务提交之前，调用 `SqlSession#commit()` 方法，提交事务。虽然说，Spring 自身也会调用 `Connection#commit()` 方法，进行事务的提交。但是，`SqlSession#commit()` 方法中，不仅仅有事务的提交，还有提交批量操作，刷新本地缓存等等。代码如下：
+
+```
+// SqlSessionSynchronization.java
+
+@Override
+public void beforeCommit(boolean readOnly) {
+    // Connection commit or rollback will be handled by ConnectionSynchronization or
+    // DataSourceTransactionManager.
+    // But, do cleanup the SqlSession / Executor, including flushing BATCH statements so
+    // they are actually executed.
+    // SpringManagedTransaction will no-op the commit over the jdbc connection
+    // TODO This updates 2nd level caches but the tx may be rolledback later on!
+    if (TransactionSynchronizationManager.isActualTransactionActive()) {
+        try {
+            LOGGER.debug(() -> "Transaction synchronization committing SqlSession [" + this.holder.getSqlSession() + "]");
+            // 提交事务
+            this.holder.getSqlSession().commit();
+        } catch (PersistenceException p) {
+            // 如果发生异常，则进行转换，并抛出异常
+            if (this.holder.getPersistenceExceptionTranslator() != null) {
+                DataAccessException translated = this.holder
+                        .getPersistenceExceptionTranslator()
+                        .translateExceptionIfPossible(p);
+                throw translated;
+            }
+            throw p;
+        }
+    }
+}
+```
+
+- 耐心的看看英文注释，更有助于理解该方法。
+
+## 6.6 beforeCompletion
+
+> 老艿艿：TransactionSynchronization 的事务提交的执行顺序是：beforeCommit => beforeCompletion => 提交操作 => afterCompletion => afterCommit 。
+
+`#beforeCompletion()` 方法，提交事务完成之前，关闭 SqlSession 对象。代码如下：
+
+```
+// SqlSessionSynchronization.java
+
+@Override
+public void beforeCompletion() {
+    // Issue #18 Close SqlSession and deregister it now
+    // because afterCompletion may be called from a different thread
+    if (!this.holder.isOpen()) {
+        LOGGER.debug(() -> "Transaction synchronization deregistering SqlSession [" + this.holder.getSqlSession() + "]");
+        // 取消当前线程的绑定的 SqlSessionHolder 对象
+        TransactionSynchronizationManager.unbindResource(sessionFactory);
+        // 标记无效
+        this.holderActive = false;
+        LOGGER.debug(() -> "Transaction synchronization closing SqlSession [" + this.holder.getSqlSession() + "]");
+        // 关闭 SqlSession 对象
+        this.holder.getSqlSession().close();
+    }
+}
+```
+
+- 因为，beforeCompletion 方法是在 beforeCommit 之后执行，并且在 beforeCommit 已经提交了事务，所以此处可以放心关闭 SqlSession 对象了。
+
+- 要执行关闭操作之前，需要先调用 `SqlSessionHolder#isOpen()` 方法来判断，是否处于开启状态。代码如下：
+
+  ```
+  // ResourceHolderSupport.java
+  
+  public boolean isOpen() {
+  	return (this.referenceCount > 0);
+  }
+  ```
+
+  - 这就是，我们前面看到的各种计数增减的作用。
+
+## 6.7 afterCompletion
+
+`#afterCompletion()` 方法，解决可能出现的**跨线程**的情况，简单理解下就好。代码如下：
+
+```
+// ResourceHolderSupport.java
+
+@Override
+public void afterCompletion(int status) {
+    if (this.holderActive) { // 处于有效状态
+        // afterCompletion may have been called from a different thread
+        // so avoid failing if there is nothing in this one
+        LOGGER.debug(() -> "Transaction synchronization deregistering SqlSession [" + this.holder.getSqlSession() + "]");
+        // 取消当前线程的绑定的 SqlSessionHolder 对象
+        TransactionSynchronizationManager.unbindResourceIfPossible(sessionFactory);
+        // 标记无效
+        this.holderActive = false;
+        LOGGER.debug(() -> "Transaction synchronization closing SqlSession [" + this.holder.getSqlSession() + "]");
+        // 关闭 SqlSession 对象
+        this.holder.getSqlSession().close();
+    }
+    this.holder.reset();
+}
+```
+
+- 😈 貌似，官方没对这块做单元测试。
+
+# 666. 彩蛋
+
+越写越清晰，哈哈哈哈。
+
+参考和推荐如下文章：
+
+- fifadxj [《mybatis-spring事务处理机制分析》](https://my.oschina.net/fifadxj/blog/785621) 提供了序列图
\ No newline at end of file
diff --git a/mybatis/33-mybatis-Spring 集成（五）之批处理.md b/mybatis/33-mybatis-Spring 集成（五）之批处理.md
new file mode 100644
index 0000000..d02df77
--- /dev/null
+++ b/mybatis/33-mybatis-Spring 集成（五）之批处理.md	
@@ -0,0 +1,512 @@
+# 精尽 MyBatis 源码解析 —— Spring 集成（五）之批处理
+
+# 1. 概述
+
+本文我们就来看看，Spring 和 MyBatis 的**批处理**是如何集成。它在 `batch` 包下实现，基于 [Spring Batch](https://spring.io/projects/spring-batch) 框架实现，整体类图如下：[![类图](http://static.iocoder.cn/images/MyBatis/2020_06_13/01.png)](http://static.iocoder.cn/images/MyBatis/2020_06_13/01.png)类图
+
+- 读操作：MyBatisCursorItemReader、MyBatisPagingItemReader 。
+- 写操作：MyBatisBatchItemWriter 。
+
+# 2. 调试环境
+
+在 `org.mybatis.spring.batch.SpringBatchTest` 单元测试类中，可以直接进行调试。
+
+😈 调试起来把，胖友。
+
+# 2. MyBatisPagingItemReader
+
+`org.mybatis.spring.batch.MyBatisPagingItemReader` ，继承 `org.springframework.batch.item.database.AbstractPagingItemReader` 抽象类，基于分页的 MyBatis 的读取器。
+
+## 2.1 示例
+
+```
+// SpringBatchTest.java
+
+@Test
+@Transactional
+void shouldDuplicateSalaryOfAllEmployees() throws Exception {
+    // <x> 批量读取 Employee 数组
+    List<Employee> employees = new ArrayList<>();
+    Employee employee = pagingNoNestedItemReader.read();
+    while (employee != null) {
+        employee.setSalary(employee.getSalary() * 2);
+        employees.add(employee);
+        employee = pagingNoNestedItemReader.read();
+    }
+
+    // 批量写入
+    //noinspection Duplicates
+    writer.write(employees);
+
+    assertThat((Integer) session.selectOne("checkSalarySum")).isEqualTo(20000);
+    assertThat((Integer) session.selectOne("checkEmployeeCount")).isEqualTo(employees.size());
+}
+```
+
+- `<x>` 处，不断读取，直到为空。
+
+## 2.2 构造方法
+
+```
+// MyBatisPagingItemReader.java
+
+/**
+ * SqlSessionFactory 对象
+ */
+private SqlSessionFactory sqlSessionFactory;
+/**
+ * SqlSessionTemplate 对象
+ */
+private SqlSessionTemplate sqlSessionTemplate;
+/**
+ * 查询编号
+ */
+private String queryId;
+/**
+ * 参数值的映射
+ */
+private Map<String, Object> parameterValues;
+
+public MyBatisPagingItemReader() {
+    setName(getShortName(MyBatisPagingItemReader.class));
+}
+
+// ... 省略 setting 方法
+```
+
+## 2.3 afterPropertiesSet
+
+```
+// MyBatisPagingItemReader.java
+
+@Override
+public void afterPropertiesSet() throws Exception {
+    // 父类的处理
+    super.afterPropertiesSet();
+    notNull(sqlSessionFactory, "A SqlSessionFactory is required.");
+    // 创建 SqlSessionTemplate 对象
+    sqlSessionTemplate = new SqlSessionTemplate(sqlSessionFactory, ExecutorType.BATCH);
+    notNull(queryId, "A queryId is required.");
+}
+```
+
+- 主要目的，是创建 SqlSessionTemplate 对象。
+
+## 2.4 doReadPage
+
+`#doReadPage()` 方法，执行每一次分页的读取。代码如下：
+
+```
+// MyBatisPagingItemReader.java
+
+@Override
+protected void doReadPage() {
+    // <1> 创建 parameters 参数
+    Map<String, Object> parameters = new HashMap<>();
+    // <1.1> 设置原有参数
+    if (parameterValues != null) {
+        parameters.putAll(parameterValues);
+    }
+    // <1.2> 设置分页参数
+    parameters.put("_page", getPage());
+    parameters.put("_pagesize", getPageSize());
+    parameters.put("_skiprows", getPage() * getPageSize());
+    // <2> 清空目前的 results 结果
+    if (results == null) {
+        results = new CopyOnWriteArrayList<>();
+    } else {
+        results.clear();
+    }
+    // <3> 查询结果
+    results.addAll(sqlSessionTemplate.selectList(queryId, parameters));
+}
+```
+
+- ```
+  <1>
+  ```
+
+   
+
+  处，创建
+
+   
+
+  ```
+  parameters
+  ```
+
+   
+
+  参数。
+
+  - `<1.1>` 处，设置原有参数。
+  - `<1.2>` 处，设置分页参数。
+
+- `<2>` 处，创建或清空当前的 `results` ，保证是空的数组。使用 CopyOnWriteArrayList 的原因是，可能存在并发读取的问题。
+
+- 【重要】 `<3>` 处，调用 `SqlSessionTemplate#selectList(queryId, parameters)` 方法，执行查询列表。查询后，将结果添加到 `results` 中。
+
+## 2.5 doJumpToPage
+
+```
+// MyBatisPagingItemReader.java
+
+@Override
+protected void doJumpToPage(int itemIndex) {
+    // Not Implemented
+}
+```
+
+# 3. MyBatisCursorItemReader
+
+`org.mybatis.spring.batch.MyBatisCursorItemReader` ，继承 `org.springframework.batch.item.support.AbstractItemCountingItemStreamItemReader` 抽象类，实现 InitializingBean 接口，基于 **Cursor** 的 MyBatis 的读取器。
+
+## 3.1 示例
+
+```
+// SpringBatchTest.java
+
+@Test
+@Transactional
+void checkCursorReadingWithoutNestedInResultMap() throws Exception {
+    // 打开 Cursor
+    cursorNoNestedItemReader.doOpen();
+    try {
+        // Employee 数组
+        List<Employee> employees = new ArrayList<>();
+        // <x> 循环读取，写入到 Employee 数组中
+        Employee employee = cursorNoNestedItemReader.read();
+        while (employee != null) {
+            employee.setSalary(employee.getSalary() * 2);
+            employees.add(employee);
+            employee = cursorNoNestedItemReader.read();
+        }
+
+        // 批量写入
+        writer.write(employees);
+
+        assertThat((Integer) session.selectOne("checkSalarySum")).isEqualTo(20000);
+        assertThat((Integer) session.selectOne("checkEmployeeCount")).isEqualTo(employees.size());
+    } finally {
+        // 关闭 Cursor
+        cursorNoNestedItemReader.doClose();
+    }
+}
+```
+
+- `<x>` 处，不断读取，直到为空。
+
+## 3.2 构造方法
+
+```
+// MyBatisCursorItemReader.java
+
+/**
+ * SqlSessionFactory 对象
+ */
+private SqlSessionFactory sqlSessionFactory;
+/**
+ * SqlSession 对象
+ */
+private SqlSession sqlSession;
+
+/**
+ * 查询编号
+ */
+private String queryId;
+/**
+ * 参数值的映射
+ */
+private Map<String, Object> parameterValues;
+
+/**
+ * Cursor 对象
+ */
+private Cursor<T> cursor;
+/**
+ * {@link #cursor} 的迭代器
+ */
+private Iterator<T> cursorIterator;
+
+public MyBatisCursorItemReader() {
+    setName(getShortName(MyBatisCursorItemReader.class));
+}
+
+// ... 省略 setting 方法
+```
+
+## 3.3 afterPropertiesSet
+
+```
+// MyBatisCursorItemReader.java
+
+@Override
+public void afterPropertiesSet() throws Exception {
+    notNull(sqlSessionFactory, "A SqlSessionFactory is required.");
+    notNull(queryId, "A queryId is required.");
+}
+```
+
+## 3.4 doOpen
+
+`#doOpen()` 方法，打开 Cursor 。代码如下：
+
+```
+// MyBatisCursorItemReader.java
+
+@Override
+protected void doOpen() throws Exception {
+    // <1> 创建 parameters 参数
+    Map<String, Object> parameters = new HashMap<>();
+    if (parameterValues != null) {
+        parameters.putAll(parameterValues);
+    }
+
+    // <2> 创建 SqlSession 对象
+    sqlSession = sqlSessionFactory.openSession(ExecutorType.SIMPLE);
+
+    // <3.1> 查询，返回 Cursor 对象
+    cursor = sqlSession.selectCursor(queryId, parameters);
+    // <3.2> 获得 cursor 的迭代器
+    cursorIterator = cursor.iterator();
+}
+```
+
+- `<1>` 处，创建 parameters 参数。
+
+- `<2>` 处，调用 `SqlSessionFactory#openSession(ExecutorType.SIMPLE)` 方法，创建简单执行器的 SqlSession 对象。
+
+- ```
+  <3.1>
+  ```
+
+   
+
+  处，调用
+
+   
+
+  ```
+  SqlSession#selectCursor(queryId, parameters)
+  ```
+
+   
+
+  方法，返回 Cursor 对象。
+
+  - `<3.2>` 处，调用 `Cursor#iterator()` 方法，获得迭代器。
+
+## 3.5 doRead
+
+`#doRead()` 方法，读取下一条数据。代码如下：
+
+```
+// MyBatisCursorItemReader.java
+
+@Override
+protected T doRead() throws Exception {
+    // 置空 next
+    T next = null;
+    // 读取下一条
+    if (cursorIterator.hasNext()) {
+        next = cursorIterator.next();
+    }
+    // 返回
+    return next;
+}
+```
+
+## 3.6 doClose
+
+`#doClose()` 方法，关闭 Cursor 和 SqlSession 对象。代码如下：
+
+```
+// MyBatisCursorItemReader.java
+
+@Override
+protected void doClose() throws Exception {
+    // 关闭 cursor 对象
+    if (cursor != null) {
+        cursor.close();
+    }
+    // 关闭 sqlSession 对象
+    if (sqlSession != null) {
+        sqlSession.close();
+    }
+    // 置空 cursorIterator
+    cursorIterator = null;
+}
+```
+
+# 4. MyBatisBatchItemWriter
+
+`org.mybatis.spring.batch.MyBatisBatchItemWriter` ，实现 `org.springframework.batch.item.ItemWriter`、InitializingBean 接口，MyBatis 批量写入器。
+
+## 4.1 示例
+
+```
+// SpringBatchTest.java
+
+@Test
+@Transactional
+void shouldDuplicateSalaryOfAllEmployees() throws Exception {
+    // 批量读取 Employee 数组
+    List<Employee> employees = new ArrayList<>();
+    Employee employee = pagingNoNestedItemReader.read();
+    while (employee != null) {
+        employee.setSalary(employee.getSalary() * 2);
+        employees.add(employee);
+        employee = pagingNoNestedItemReader.read();
+    }
+
+    // <x> 批量写入
+    writer.write(employees);
+
+    assertThat((Integer) session.selectOne("checkSalarySum")).isEqualTo(20000);
+    assertThat((Integer) session.selectOne("checkEmployeeCount")).isEqualTo(employees.size());
+}
+```
+
+- `<x>` 处，执行**一次**批量写入到数据库中。
+
+## 4.2 构造方法
+
+```
+// SpringBatchTest.java
+
+/**
+ * SqlSessionTemplate 对象
+ */
+private SqlSessionTemplate sqlSessionTemplate;
+
+/**
+ * 语句编号
+ */
+private String statementId;
+
+/**
+ * 是否校验
+ */
+private boolean assertUpdates = true;
+
+/**
+ * 参数转换器
+ */
+private Converter<T, ?> itemToParameterConverter = new PassThroughConverter<>();
+
+// ... 省略 setting 方法
+```
+
+## 4.3 PassThroughConverter
+
+PassThroughConverter ，是 MyBatisBatchItemWriter 的内部静态类，实现 Converter 接口，直接返回自身。代码如下：
+
+```
+// MyBatisBatchItemWriter.java
+
+private static class PassThroughConverter<T> implements Converter<T, T> {
+
+    @Override
+    public T convert(T source) {
+        return source;
+    }
+
+}
+```
+
+- 这是一个默认的 Converter 实现类。我们可以自定义 Converter 实现类，设置到 MyBatisBatchItemWriter 中。那么具体什么用呢？答案见 [「4.5 write」](https://svip.iocoder.cn/MyBatis/Spring-Integration-5/#) 。
+
+## 4.4 afterPropertiesSet
+
+```
+// MyBatisBatchItemWriter
+
+@Override
+public void afterPropertiesSet() {
+    notNull(sqlSessionTemplate, "A SqlSessionFactory or a SqlSessionTemplate is required.");
+    isTrue(ExecutorType.BATCH == sqlSessionTemplate.getExecutorType(), "SqlSessionTemplate's executor type must be BATCH");
+    notNull(statementId, "A statementId is required.");
+    notNull(itemToParameterConverter, "A itemToParameterConverter is required.");
+}
+```
+
+## 4.5 write
+
+`#write(List<? extends T> items)` 方法，将传入的 `items` 数组，执行一次批量操作，仅执行一次批量操作。代码如下：
+
+```
+// MyBatisBatchItemWriter.java
+
+@Override
+public void write(final List<? extends T> items) {
+    if (!items.isEmpty()) {
+        LOGGER.debug(() -> "Executing batch with " + items.size() + " items.");
+
+        // <1> 遍历 items 数组，提交到 sqlSessionTemplate 中
+        for (T item : items) {
+            sqlSessionTemplate.update(statementId, itemToParameterConverter.convert(item));
+        }
+        // <2> 执行一次批量操作
+        List<BatchResult> results = sqlSessionTemplate.flushStatements();
+
+        if (assertUpdates) {
+            // 如果有多个返回结果，抛出 InvalidDataAccessResourceUsageException 异常
+            if (results.size() != 1) {
+                throw new InvalidDataAccessResourceUsageException("Batch execution returned invalid results. " +
+                        "Expected 1 but number of BatchResult objects returned was " + results.size());
+            }
+
+            // <3> 遍历执行结果，若存在未更新的情况，则抛出 EmptyResultDataAccessException 异常
+            int[] updateCounts = results.get(0).getUpdateCounts();
+            for (int i = 0; i < updateCounts.length; i++) {
+                int value = updateCounts[i];
+                if (value == 0) {
+                    throw new EmptyResultDataAccessException("Item " + i + " of " + updateCounts.length
+                            + " did not update any rows: [" + items.get(i) + "]", 1);
+                }
+            }
+        }
+    }
+}
+```
+
+- ```
+  <1>
+  ```
+
+   
+
+  处，遍历
+
+   
+
+  ```
+  items
+  ```
+
+   
+
+  数组，提交到
+
+   
+
+  ```
+  sqlSessionTemplate
+  ```
+
+   
+
+  中。
+
+  - `<2>` 处，执行一次批量操作。
+
+- `<3>` 处，遍历执行结果，若存在未更新的情况，则抛出 EmptyResultDataAccessException 异常。
+
+# 5. Builder 类
+
+在 `batch/builder` 包下，读取器和写入器都有 Builder 类，胖友自己去瞅瞅，灰常简单。
+
+# 666. 彩蛋
+
+一篇靠体力活的文章，嘿嘿嘿。
\ No newline at end of file
diff --git a/netty/01-Netty 面试题.assets/01.png b/netty/01-Netty 面试题.assets/01.png
new file mode 100644
index 0000000..2dbf0ca
Binary files /dev/null and b/netty/01-Netty 面试题.assets/01.png differ
diff --git a/netty/01-Netty 面试题.assets/02.png b/netty/01-Netty 面试题.assets/02.png
new file mode 100644
index 0000000..7635d92
Binary files /dev/null and b/netty/01-Netty 面试题.assets/02.png differ
diff --git a/netty/01-Netty 面试题.assets/03.png b/netty/01-Netty 面试题.assets/03.png
new file mode 100644
index 0000000..bcba6e1
Binary files /dev/null and b/netty/01-Netty 面试题.assets/03.png differ
diff --git a/netty/01-Netty 面试题.assets/85d98e3cb0e6e39f80d02234e039a4dd.jpeg b/netty/01-Netty 面试题.assets/85d98e3cb0e6e39f80d02234e039a4dd.jpeg
new file mode 100644
index 0000000..f6f0a4e
Binary files /dev/null and b/netty/01-Netty 面试题.assets/85d98e3cb0e6e39f80d02234e039a4dd.jpeg differ
diff --git a/netty/01-Netty 面试题.md b/netty/01-Netty 面试题.md
new file mode 100644
index 0000000..cf1d643
--- /dev/null
+++ b/netty/01-Netty 面试题.md	
@@ -0,0 +1,731 @@
+# 精尽 Netty 面试题「最新更新时间：2024-02」
+
+以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。
+
+如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的 Netty 面试题的大保健。
+
+而题目的难度，艿艿尽量按照从容易到困难的顺序，逐步下去。
+
+## BIO 是什么？
+
+🦅 **概念**
+
+- BIO ，全称 Block-IO ，是一种**阻塞** + **同步**的通信模式。
+- 是一个比较传统的通信方式，模式简单，使用方便。但并发处理能力低，通信耗时，依赖网速。
+
+🦅 **原理**
+
+- 服务器通过一个 Acceptor 线程，负责监听客户端请求和为每个客户端创建一个新的线程进行链路处理。典型的**一请求一应答模式**。
+- 若客户端数量增多，频繁地创建和销毁线程会给服务器打开很大的压力。后改良为用线程池的方式代替新增线程，被称为伪异步 IO 。
+
+🦅 **示例**
+
+- 代码参见 [bio](https://github.com/ITDragonBlog/daydayup/tree/master/Netty/socket-io/src/com/itdragon/bio) 。
+
+🦅 **小结**
+
+BIO 模型中，通过 Socket 和 ServerSocket 实现套接字通道的通信。阻塞，同步，建立连接耗时。
+
+## NIO 是什么？
+
+🦅 **概念**
+
+- NIO ，全称 New IO ，也叫 Non-Block IO ，是一种**非阻塞** + 同步的通信模式。
+- [《精尽 Netty 源码分析 —— NIO 基础（一）之简介》](http://svip.iocoder.cn/Netty/nio-1-intro/)
+
+🦅 **原理**
+
+- NIO 相对于 BIO 来说一大进步。客户端和服务器之间通过 Channel 通信。NIO 可以在 Channel 进行读写操作。这些 Channel 都会被注册在 Selector 多路复用器上。Selector 通过一个线程不停的轮询这些 Channel 。找出已经准备就绪的 Channel 执行 IO 操作。
+- NIO 通过一个线程轮询，实现千万个客户端的请求，这就是非阻塞 NIO 的特点。
+  - 缓冲区 Buffer ：它是 NIO 与 BIO 的一个重要区别。
+    - BIO 是将数据直接写入或读取到流 Stream 对象中。
+    - NIO 的数据操作都是在 Buffer 中进行的。Buffer 实际上是一个数组。Buffer 最常见的类型是ByteBuffer，另外还有 CharBuffer，ShortBuffer，IntBuffer，LongBuffer，FloatBuffer，DoubleBuffer。
+    - [《精尽 Netty 源码分析 —— NIO 基础（三）之 Buffer》](http://svip.iocoder.cn/Netty/nio-3-buffer/)
+  - 通道 Channel ：和流 Stream 不同，通道是双向的。NIO可以通过 Channel 进行数据的读、写和同时读写操作。
+    - 通道分为两大类：一类是网络读写（SelectableChannel），一类是用于文件操作（FileChannel）。我们使用的是前者 SocketChannel 和 ServerSocketChannel ，都是SelectableChannel 的子类。
+    - [《精尽 Netty 源码分析 —— NIO 基础（二）之 Channel》](http://svip.iocoder.cn/Netty/nio-2-channel/)
+  - 多路复用器 Selector ：NIO 编程的基础。多路复用器提供选择已经就绪的任务的能力：就是 Selector 会不断地轮询注册在其上的通道（Channel），如果某个通道处于就绪状态，会被 Selector 轮询出来，然后通过 SelectionKey 可以取得就绪的Channel集合，从而进行后续的 IO 操作。
+    - 服务器端只要提供一个线程负责 Selector 的轮询，就可以接入成千上万个客户端，这就是 JDK NIO 库的巨大进步。
+    - [《精尽 Netty 源码分析 —— NIO 基础（四）之 Selector》](http://svip.iocoder.cn/Netty/nio-4-selector/)
+
+🦅 **示例**
+
+- 代码参见 [nio](https://github.com/ITDragonBlog/daydayup/tree/master/Netty/socket-io/src/com/itdragon/nio)
+- [《精尽 Netty 源码分析 —— NIO 基础（五）之示例》](http://svip.iocoder.cn/Netty/nio-5-demo/)
+
+🦅 **小结**
+
+NIO 模型中通过 SocketChannel 和 ServerSocketChannel 实现套接字通道的通信。非阻塞，同步，避免为每个 TCP 连接创建一个线程。
+
+🦅 **继续挖掘**
+
+可能有胖友对非阻塞和阻塞，同步和异步的定义有点懵逼，我们再来看下 [《精尽 Netty 源码分析 —— NIO 基础（一）之简介》](http://svip.iocoder.cn/Netty/nio-1-intro/) 提到的一段话：
+
+> 老艿艿：在一些文章中，会将 Java NIO 描述成**异步** IO ，实际是不太正确的： Java NIO 是**同步** IO ，Java AIO ( 也称为 NIO 2 )是**异步** IO。具体原因，推荐阅读文章：
+>
+> - [《异步和非阻塞一样吗? (内容涉及 BIO, NIO, AIO, Netty)》](https://blog.csdn.net/matthew_zhang/article/details/71328697) 。
+> - [《BIO与NIO、AIO的区别(这个容易理解)》](https://blog.csdn.net/skiof007/article/details/52873421)
+>
+> 总结来说，在 **Unix IO 模型**的语境下：
+>
+> - 同步和异步的区别：数据拷贝阶段是否需要完全由操作系统处理。
+> - 阻塞和非阻塞操作：是针对发起 IO 请求操作后，是否有立刻返回一个标志信息而不让请求线程等待。
+>
+> 因此，Java NIO 是**同步**且非阻塞的 IO 。
+
+- 另外，胖友在瞅瞅下面这个图来理解下：[![Unix 的 5 种 IO 模型](01-Netty 面试题.assets/01.png)](http://static.iocoder.cn/images/Netty/2017_10_24/01.png)Unix 的 5 种 IO 模型
+
+## AIO 是什么？
+
+> 艿艿：这个面试题，重点在于陈述我们对 BIO、NIO 的理解，对于 AIO 来说，基本理解即可。
+
+🦅 **概念**
+
+- AIO ，全称 Asynchronous IO ，也叫 NIO**2** ，是一种**非阻塞** + **异步**的通信模式。在 NIO 的基础上，引入了新的异步通道的概念，并提供了异步文件通道和异步套接字通道的实现。
+- 原理：
+- AIO 并没有采用 NIO 的多路复用器，而是使用异步通道的概念。其 read，write 方法的返回类型，都是 Future 对象。而 Future 模型是异步的，其核心思想是：**去主函数等待时间**。
+
+🦅 **示例**
+
+- 代码参见 [aio](https://github.com/ITDragonBlog/daydayup/tree/master/Netty/socket-io/src/com/itdragon/aio)
+
+🦅 **小结**
+
+AIO 模型中通过 AsynchronousSocketChannel 和 AsynchronousServerSocketChannel 实现套接字通道的通信。非阻塞，异步。
+
+## BIO、NIO 有什么区别？
+
+- 线程模型不同
+  - BIO：一个连接一个线程，客户端有连接请求时服务器端就需要启动一个线程进行处理。所以，线程开销大。可改良为用线程池的方式代替新创建线程，被称为伪异步 IO 。
+  - NIO：一个请求一个线程，但客户端发送的连接请求都会注册到多路复用器上，多路复用器轮询到连接有新的 I/O 请求时，才启动一个线程进行处理。可改良为一个线程处理多个请求，基于 [多 Reactor 模型](http://svip.iocoder.cn/Netty/EventLoop-1-Reactor-Model/)。
+- BIO 是面向流( Stream )的，而 NIO 是面向缓冲区( Buffer )的。
+- BIO 的各种操作是阻塞的，而 NIO 的各种操作是非阻塞的。
+- BIO 的 Socket 是单向的，而 NIO 的 Channel 是双向的。
+
+可能文字比较难记，整理出来就是下图：[![BIO 对比 NIO 对比 AIO](01-Netty 面试题.assets/02.png)](http://static.iocoder.cn/images/Netty/2017_10_24/02.png)BIO 对比 NIO 对比 AIO
+
+- 有一点要注意，虽然图中说 NIO 的性能一般，但是在绝大多数我们日常业务场景，NIO 和 AIO 的性能差距实际没这么大。在 Netty5 中，基于 AIO 改造和支持，最后发现，性能并没有想象中这么强悍，所以 Netty5 被废弃，而是继续保持 Netty4 为主版本，使用 NIO 为主。
+
+为了胖友能更好的记住和理解 BIO、NIO、AIO 的流程，胖友可以在理解下图：[![BIO、NIO、AIO 的流程图](01-Netty 面试题.assets/03.png)](http://static.iocoder.cn/images/Netty/2017_10_24/03.png)BIO、NIO、AIO 的流程图
+
+## 什么是 Netty ？
+
+> Netty 是一款提供异步的、事件驱动的网络应用程序框架和工具，用以快速开发高性能、高可靠性的网络服务器和客户端程序。
+>
+> 也就是说，Netty 是一个基于 NIO 的客户、服务器端编程框架。使用 Netty 可以确保你快速和简单地开发出一个网络应用，例如实现了某种协议的客户，服务端应用。Netty 相当简化和流线化了网络应用的编程开发过程，例如，TCP 和 UDP 的 socket 服务开发。
+>
+> （以上摘自百度百科）。
+
+Netty 具有如下特性( 摘自《Netty in Action》 )
+
+| 分类     | Netty的特性                                                  |
+| :------- | :----------------------------------------------------------- |
+| 设计     | 1. 统一的 API ，支持多种传输类型( 阻塞和非阻塞的 ) 2. 简单而强大的线程模型 3. 真正的无连接数据报套接字( UDP )支持 4. 连接逻辑组件( ChannelHander 中顺序处理消息 )以及组件复用( 一个 ChannelHandel 可以被多个ChannelPipeLine 复用 ) |
+| 易于使用 | 1. 详实的 Javadoc 和大量的示例集 2. 不需要超过 JDK 1.6+ 的依赖 |
+| 性能     | 拥有比 Java 的核心 API 更高的吞吐量以及更低的延迟( 得益于池化和复用 )，更低的资源消耗以及最少的内存复制 |
+| 健壮性   | 1. 不会因为慢速、快速或者超载的连接而导致 OutOfMemoryError 2. 消除在高速网络中 NIO 应用程序常见的不公平读 / 写比率 |
+| 安全性   | 完整的 SSL/TLS 以及 StartTLs 支持，可用于受限环境下，如 Applet 和 OSGI |
+| 社区驱动 | 发布快速而且频繁                                             |
+
+## 为什么选择 Netty ？
+
+- **使用简单**：API 使用简单，开发门槛低。
+- **功能强大**：预置了多种编解码功能，支持多种主流协议。
+- **定制能力强**：可以通过 ChannelHandler 对通信框架进行灵活的扩展。
+- **性能高**：通过与其它业界主流的 NIO 框架对比，Netty 的综合性能最优。
+- **成熟稳定**：Netty 修复了已经发现的所有 JDK NIO BUG，业务开发人员不需要再为 NIO 的 BUG 而烦恼。
+- **社区活跃**：版本迭代周期短，发现的BUG可以被及时修复，同时，更多的新功能会被加入。
+- **案例丰富**：经历了大规模的商业应用考验，质量已经得到验证。在互联网、大数据、网络游戏、企业应用、电信软件等众多行业得到成功商用，证明了它可以完全满足不同行业的商业应用。
+
+实际上，这个也是我们做技术选型的一些参考点，不仅仅适用于 Netty ，也同样适用于其他技术栈。当然，😈 面试都可以酱紫回答，显得很高端。
+
+## 为什么说 Netty 使用简单？
+
+🦅 我们假设要搭建一个 Server 服务器，使用 **Java NIO 的步骤**如下：
+
+1. 创建 ServerSocketChannel 。
+
+   - 绑定监听端口，并配置为非阻塞模式。
+
+2. 创建 Selector，将之前创建的 ServerSocketChannel 注册到 Selector 上，监听
+
+    
+
+   ```
+   SelectionKey.OP_ACCEPT
+   ```
+
+    
+
+   。
+
+   - 循环执行 `Selector#select()` 方法，轮询就绪的 Channel。
+
+3. 轮询就绪的 Channel 时，如果是处于
+
+    
+
+   ```
+   OP_ACCEPT
+   ```
+
+    
+
+   状态，说明是新的客户端接入，调用
+
+    
+
+   ```
+   ServerSocketChannel#accept()
+   ```
+
+    
+
+   方法，接收新的客户端。
+
+   - 设置新接入的 SocketChannel 为非阻塞模式，并注册到 Selector 上，监听 `OP_READ` 。
+
+4. 如果轮询的 Channel 状态是
+
+    
+
+   ```
+   OP_READ
+   ```
+
+    
+
+   ，说明有新的就绪数据包需要读取，则构造 ByteBuffer 对象，读取数据。
+
+   - 这里，解码数据包的过程，需要我们自己编写。
+
+> 艿艿：注意噢，上述步骤还是最简的 Java NIO 启动步骤，不包括**多 Reactor 多线程模型**噢！可能有胖友不知道什么是 Reactor 模型，在 [「什么是 Reactor 模型？」](https://svip.iocoder.cn/Netty/Interview/#) 问题中，我们会详细解释。
+
+🦅 使用 **Netty 的步骤**如下：
+
+1. 创建 NIO 线程组 EventLoopGroup 和 ServerBootstrap。
+   - 设置 ServerBootstrap 的属性：线程组、SO_BACKLOG 选项，设置 NioServerSocketChannel 为 Channel
+   - 设置业务处理 Handler 和 编解码器 Codec 。
+   - 绑定端口，启动服务器程序。
+2. 在业务处理 Handler 中，处理客户端发送的数据，并给出响应。
+
+🦅 那么相比 Java NIO，使用 Netty 开发程序，都**简化了哪些步骤**呢？
+
+1. 无需关心 `OP_ACCEPT`、`OP_READ`、`OP_WRITE` 等等 **IO 操作**，Netty 已经封装，对我们在使用是透明无感的。
+2. 使用 boss 和 worker EventLoopGroup ，Netty 直接提供**多 Reactor 多线程模型**。
+3. 在 Netty 中，我们看到有使用一个解码器 FixedLengthFrameDecoder，可以用于处理定长消息的问题，能够解决 **TCP 粘包拆包**问题，十分方便。如果使用 Java NIO ，需要我们自行实现解码器。
+
+------
+
+😈 如果胖友不知道如何使用 Java NIO 编写一个 Server ，建议自己去实现以下。
+😈 如果胖友没有使用过 Netty 编写一个 Server ，建议去入门下。
+
+## 说说业务中 Netty 的使用场景？
+
+- 构建高性能、低时延的各种 Java 中间件，Netty 主要作为基础通信框架提供高性能、低时延的通信服务。例如：
+  - RocketMQ ，分布式消息队列。
+  - Dubbo ，服务调用框架。
+  - Spring WebFlux ，基于响应式的 Web 框架。
+  - HDFS ，分布式文件系统。
+- 公有或者私有协议栈的基础通信框架，例如可以基于 Netty 构建异步、高性能的 WebSocket、Protobuf 等协议的支持。
+- 各领域应用，例如大数据、游戏等，Netty 作为高性能的通信框架用于内部各模块的数据分发、传输和汇总等，实现模块之间高性能通信。
+
+## 说说 Netty 如何实现高性能？
+
+1. **线程模型** ：更加优雅的 Reactor 模式实现、灵活的线程模型、利用 EventLoop 等创新性的机制，可以非常高效地管理成百上千的 Channel 。
+
+2. **内存池设计** ：使用池化的 Direct Buffer 等技术，在提高 IO 性能的同时，减少了对象的创建和销毁。并且，内吃吃的内部实现是用一颗二叉查找树，更好的管理内存分配情况。
+
+3. **内存零拷贝** ：使用 Direct Buffer ，可以使用 Zero-Copy 机制。
+
+   > Zero-Copy ，在操作数据时，不需要将数据 Buffer 从一个内存区域拷贝到另一个内存区域。因为少了一次内存的拷贝，因此 CPU 的效率就得到的提升。
+
+4. **协议支持** ：提供对 Protobuf 等高性能序列化协议支持。
+
+5. 使用更多本地代码
+
+   。例如：
+
+   - 直接利用 JNI 调用 Open SSL 等方式，获得比 Java 内建 SSL 引擎更好的性能。
+   - 利用 JNI 提供了 Native Socket Transport ，在使用 Epoll edge-triggered 的情况下，可以有一定的性能提升。
+
+6. 其它：
+
+   - 利用反射等技术直接操纵 SelectionKey ，使用数组而不是 Java 容器等。
+   - 实现 [FastThreadLocal](https://segmentfault.com/a/1190000012926809) 类，当请求频繁时，带来更好的性能。
+   - ….
+
+另外，推荐阅读白衣大大的两篇文章：
+
+1. [《Netty高性能编程备忘录(上)》](http://calvin1978.blogcn.com/articles/netty-performance.html)
+2. [《Netty高性能编程备忘录（下）》](http://calvin1978.blogcn.com/articles/netty-performance2.html)
+
+> 下面三连问！
+>
+> Netty 是一个高性能的、高可靠的、可扩展的异步通信框架，那么高性能、高可靠、可扩展设计体现在哪里呢？
+
+## Netty 的高性能如何体现？
+
+> 这个问题，和 [「说说 Netty 如何实现高性能？」](https://svip.iocoder.cn/Netty/Interview/#) 问题，会有点重叠。没事，反正理解就好，也背不下来。哈哈哈哈。
+
+性能是设计出来的，而不是测试出来的。那么，Netty 的架构设计是如何实现高性能的呢？
+
+1. **线程模型** ：采用异步非阻塞的 I/O 类库，基于 Reactor 模式实现，解决了传统同步阻塞 I/O 模式下服务端无法平滑处理客户端线性增长的问题。
+
+2. **堆外内存** ：TCP 接收和发送缓冲区采用直接内存代替堆内存，避免了内存复制，提升了 I/O 读取和写入性能。
+
+3. **内存池设计** ：支持通过内存池的方式循环利用 ByteBuf，避免了频繁创建和销毁 ByteBuf 带来的性能消耗。
+
+4. **参数配置** ：可配置的 I/O 线程数目和 TCP 参数等，为不同用户提供定制化的调优参数，满足不同的性能场景。
+
+5. **队列优化** ：采用环形数组缓冲区，实现无锁化并发编程，代替传统的线程安全容器或锁。
+
+6. **并发能力** ：合理使用线程安全容器、原子类等，提升系统的并发能力。
+
+7. **降低锁竞争** ：关键资源的使用采用单线程串行化的方式，避免多线程并发访问带来的锁竞争和额外的 CPU 资源消耗问题。
+
+8. 内存泄露检测
+
+    
+
+   ：通过引用计数器及时地释放不再被引用的对象，细粒度的内存管理降低了 GC 的频率，减少频繁 GC 带来的时延增大和 CPU 损耗。
+
+   - [《精尽 Netty 源码解析 —— Buffer 之 ByteBuf（三）内存泄露检测》](http://svip.iocoder.cn/Netty/ByteBuf-1-3-ByteBuf-resource-leak-detector/)
+
+## Netty 的高可靠如何体现？
+
+1. 链路有效性检测
+
+   ：由于长连接不需要每次发送消息都创建链路，也不需要在消息完成交互时关闭链路，因此相对于短连接性能更高。为了保证长连接的链路有效性，往往需要通过心跳机制周期性地进行链路检测。使用心跳机制的原因是，避免在系统空闲时因网络闪断而断开连接，之后又遇到海量业务冲击导致消息积压无法处理。为了解决这个问题，需要周期性地对链路进行有效性检测，一旦发现问题，可以及时关闭链路，重建 TCP 连接。为了支持心跳，Netty 提供了两种链路空闲检测机制：
+
+   - 读空闲超时机制：连续 T 周期没有消息可读时，发送心跳消息，进行链路检测。如果连续 N 个周期没有读取到心跳消息，可以主动关闭链路，重建连接。
+   - 写空闲超时机制：连续 T 周期没有消息需要发送时，发送心跳消息，进行链路检测。如果连续 N 个周期没有读取对方发回的心跳消息，可以主动关闭链路，重建连接。
+   - [《精尽 Netty 源码解析 —— ChannelHandler（五）之 IdleStateHandler》](http://svip.iocoder.cn/Netty/ChannelHandler-5-idle/)
+
+2. 内存保护机制
+
+   ：Netty 提供多种机制对内存进行保护，包括以下几个方面：
+
+   - 通过对象引用计数器对 ByteBuf 进行细粒度的内存申请和释放，对非法的对象引用进行检测和保护。
+   - 可设置的内存容量上限，包括 ByteBuf、线程池线程数等，避免异常请求耗光内存。
+
+3. 优雅停机
+
+   ：优雅停机功能指的是当系统推出时，JVM 通过注册的 Shutdown Hook 拦截到退出信号量，然后执行推出操作，释放相关模块的资源占用，将缓冲区的消息处理完成或清空，将待刷新的数据持久化到磁盘和数据库中，等到资源回收和缓冲区消息处理完成之后，再退出。
+
+   - [《精尽 Netty 源码解析 —— EventLoop（八）之 EventLoop 优雅关闭》](http://svip.iocoder.cn/Netty/EventLoop-8-EventLoop-shutdown/)
+
+## Netty 的可扩展如何体现？
+
+可定制、易扩展。
+
+- **责任链模式** ：ChannelPipeline 基于责任链模式开发，便于业务逻辑的拦截、定制和扩展。
+- **基于接口的开发** ：关键的类库都提供了接口或抽象类，便于用户自定义实现。
+- **提供大量的工厂类** ：通过重载这些工厂类，可以按需创建出用户需要的对象。
+- **提供大量系统参数** ：供用户按需设置，增强系统的场景定制性。
+
+------
+
+> 艿艿：说个题外话。
+>
+> 实际上，任何的技术的研究，我们都可以去思考，它的高性能是怎么体现的，它的可靠性是怎么体现的，它的可拓展是怎么体现的。
+>
+> 当然，因为很多时候有近义词，所以：
+>
+> - 高性能 => 高并发
+> - 可靠性 => 高可用
+> - 可拓展 => 高拓展
+>
+> 例如说，MySQL 如何实现高性能，MySQL 如何搭建高可用，😈 MySQL 如何做拓展貌似暂时没，哈哈哈哈。
+
+## 简单介绍 Netty 的核心组件？
+
+Netty 有如下六个核心组件：
+
+- Bootstrap & ServerBootstrap
+- Channel
+- ChannelFuture
+- EventLoop & EventLoopGroup
+- ChannelHandler
+- ChannelPipeline
+
+详细的，请直接阅读 [《精尽 Netty 源码分析 —— Netty 简介（二）之核心组件》](http://svip.iocoder.cn/Netty/intro-2/) 一文。
+
+## 说说 Netty 的逻辑架构？
+
+Netty 采用了典型的**三层网络架构**进行设计和开发，其逻辑架构如下图所示：
+
+[![Netty 逻辑架构图](01-Netty 面试题.assets/85d98e3cb0e6e39f80d02234e039a4dd.jpeg)](http://static.iocoder.cn/85d98e3cb0e6e39f80d02234e039a4dd)Netty 逻辑架构图
+
+> 艿艿：注意，这个图是自下向上看。哈哈哈~
+
+1. **Reactor 通信调度层**：由一系列辅助类组成，包括 Reactor 线程 NioEventLoop 及其父类，NioSocketChannel 和 NioServerSocketChannel 等等。该层的职责就是监听网络的读写和连接操作，负责将网络层的数据读到内存缓冲区，然后触发各自网络事件，例如连接创建、连接激活、读事件、写事件等。将这些事件触发到 pipeline 中，由 pipeline 管理的职责链来进行后续的处理。
+2. **职责链 ChannelPipeline**：负责事件在职责链中的有序传播，以及负责动态地编排职责链。职责链可以选择监听和处理自己关心的事件，拦截处理和向后传播事件。
+3. **业务逻辑编排层**：业务逻辑编排层通常有两类，一类是纯粹的业务逻辑编排，一类是应用层协议插件，用于特定协议相关的会话和链路管理。由于应用层协议栈往往是开发一次到处运行，并且变动较小，故而将应用协议到 POJO 的转变和上层业务放到不同的 ChannelHandler 中，就可以实现协议层和业务逻辑层的隔离，实现架构层面的分层隔离。
+
+## 什么是 Reactor 模型？
+
+直接阅读 [《精尽 Netty 源码解析 —— EventLoop（一）之 Reactor 模型》](http://svip.iocoder.cn/Netty/EventLoop-1-Reactor-Model/) 一文。
+
+认真仔细读，这是一个高频面试题。
+
+## 请介绍 Netty 的线程模型？
+
+还是阅读 [《精尽 Netty 源码解析 —— EventLoop（一）之 Reactor 模型》](http://svip.iocoder.cn/Netty/EventLoop-1-Reactor-Model/) 一文。
+
+认真仔细读，这真的真的真的是一个高频面试题。
+
+## 什么是业务线程池？
+
+🦅 **问题**
+
+在 [「什么是 Reactor 模型？」](https://svip.iocoder.cn/Netty/Interview/#) 问题中，无论是那种类型的 Reactor 模型，都需要在 Reactor 所在的线程中，进行读写操作。那么此时就会有一个问题，如果我们读取到数据，需要进行业务逻辑处理，并且这个业务逻辑需要对数据库、缓存等等进行操作，会有什么问题呢？假设这个数据库操作需要 5 ms ，那就意味着这个 Reactor 线程在这 5 ms 无法进行注册在这个 Reactor 的 Channel 进行读写操作。也就是说，多个 Channel 的所有读写操作都变成了串行。势必，这样的效率会非常非常非常的低。
+
+🦅 **解决**
+
+那么怎么解决呢？创建业务线程池，将读取到的数据，提交到业务线程池中进行处理。这样，Reactor 的 Channel 就不会被阻塞，而 Channel 的所有读写操作都变成了并行了。
+
+🦅 **案例**
+
+如果胖友熟悉 Dubbo 框架，就会发现 [《Dubbo 用户指南 —— 线程模型》](http://dubbo.apache.org/zh-cn/docs/user/demos/thread-model.html) 。😈 认真读下，可以跟面试官吹一吹啦。
+
+## TCP 粘包 / 拆包的原因？应该这么解决？
+
+🦅 **概念**
+
+TCP 是以流的方式来处理数据，所以会导致粘包 / 拆包。
+
+- 拆包：一个完整的包可能会被 TCP 拆分成多个包进行发送。
+- 粘包：也可能把小的封装成一个大的数据包发送。
+
+🦅 **原因**
+
+- 应用程序写入的字节大小大于套接字发送缓冲区的大小，会发生**拆包**现象。而应用程序写入数据小于套接字缓冲区大小，网卡将应用多次写入的数据发送到网络上，这将会发生**粘包**现象。
+- 待发送数据大于 MSS（最大报文长度），TCP 在传输前将进行**拆包**。
+- 以太网帧的 payload（净荷）大于 MTU（默认为 1500 字节）进行 IP 分片**拆包**。
+- 接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生**粘包**。
+
+🦅 **解决**
+
+在 Netty 中，提供了多个 Decoder 解析类，如下：
+
+- ① FixedLengthFrameDecoder ，基于**固定长度**消息进行粘包拆包处理的。
+- ② LengthFieldBasedFrameDecoder ，基于**消息头指定消息长度**进行粘包拆包处理的。
+- ③ LineBasedFrameDecoder ，基于**换行**来进行消息粘包拆包处理的。
+- ④ DelimiterBasedFrameDecoder ，基于**指定消息边界方式**进行粘包拆包处理的。
+
+实际上，上述四个 FrameDecoder 实现可以进行规整：
+
+- ① 是 ② 的特例，**固定长度**是**消息头指定消息长度**的一种形式。
+- ③ 是 ④ 的特例，**换行**是于**指定消息边界方式**的一种形式。
+
+感兴趣的胖友，可以看看如下两篇文章：
+
+- [《精尽 Netty 源码解析 —— Codec 之 ByteToMessageDecoder（一）Cumulator》](http://svip.iocoder.cn/Netty/Codec-1-1-ByteToMessageDecoder-core-impl/)
+- [《精尽 Netty 源码解析 —— Codec 之 ByteToMessageDecoder（二）FrameDecoder》](http://svip.iocoder.cn/Netty/Codec-1-2-ByteToMessageDecoder-FrameDecoder/)
+
+## 了解哪几种序列化协议？
+
+🦅 **概念**
+
+- 序列化（编码），是将对象序列化为二进制形式（字节数组），主要用于网络传输、数据持久化等。
+- 反序列化（解码），则是将从网络、磁盘等读取的字节数组还原成原始对象，主要用于网络传输对象的解码，以便完成远程调用。
+
+🦅 **选型**
+
+在选择序列化协议的选择，主要考虑以下三个因素：
+
+- 序列化后的**字节大小**。更少的字节数，可以减少网络带宽、磁盘的占用。
+- 序列化的**性能**。对 CPU、内存资源占用情况。
+- 是否支持**跨语言**。例如，异构系统的对接和开发语言切换。
+
+🦅 **方案**
+
+> 如果对序列化工具了解不多的胖友，可能一看有这么多优缺点会比较懵逼，可以先记得有哪些序列化工具，然后在慢慢熟悉它们的优缺点。
+>
+> 重点，还是知道【**选型**】的考虑点。
+
+1. 【重点】Java 默认提供的序列化
+
+   - 无法跨语言；序列化后的字节大小太大；序列化的性能差。
+
+2. 【重点】XML 。
+
+   - 优点：人机可读性好，可指定元素或特性的名称。
+   - 缺点：序列化数据只包含数据本身以及类的结构，不包括类型标识和程序集信息；只能序列化公共属性和字段；不能序列化方法；文件庞大，文件格式复杂，传输占带宽。
+   - 适用场景：当做配置文件存储数据，实时数据转换。
+
+3. 【重点】JSON ，是一种轻量级的数据交换格式。
+
+   - 优点：兼容性高、数据格式比较简单，易于读写、序列化后数据较小，可扩展性好，兼容性好。与 XML 相比，其协议比较简单，解析速度比较快。
+   - 缺点：数据的描述性比 XML 差、不适合性能要求为 ms 级别的情况、额外空间开销比较大。
+   - 适用场景（可替代 XML ）：跨防火墙访问、可调式性要求高、基于Restful API 请求、传输数据量相对小，实时性要求相对低（例如秒级别）的服务。
+
+4. 【了解】Thrift ，不仅是序列化协议，还是一个 RPC 框架。
+
+   - 优点：序列化后的体积小, 速度快、支持多种语言和丰富的数据类型、对于数据字段的增删具有较强的兼容性、支持二进制压缩编码。
+   - 缺点：使用者较少、跨防火墙访问时，不安全、不具有可读性，调试代码时相对困难、不能与其他传输层协议共同使用（例如 HTTP）、无法支持向持久层直接读写数据，即不适合做数据持久化序列化协议。
+   - 适用场景：分布式系统的 RPC 解决方案。
+
+5. 【了解】Avro ，Hadoop 的一个子项目，解决了JSON的冗长和没有IDL的问题。
+
+   - 优点：支持丰富的数据类型、简单的动态语言结合功能、具有自我描述属性、提高了数据解析速度、快速可压缩的二进制数据形式、可以实现远程过程调用 RPC、支持跨编程语言实现。
+   - 缺点：对于习惯于静态类型语言的用户不直观。
+   - 适用场景：在 Hadoop 中做 Hive、Pig 和 MapReduce 的持久化数据格式。
+
+6. 【重点】Protobuf ，将数据结构以
+
+    
+
+   ```
+   .proto
+   ```
+
+    
+
+   文件进行描述，通过代码生成工具可以生成对应数据结构的 POJO 对象和 Protobuf 相关的方法和属性。
+
+   - 优点：序列化后码流小，性能高、结构化数据存储格式（XML JSON等）、通过标识字段的顺序，可以实现协议的前向兼容、结构化的文档更容易管理和维护。
+   - 缺点：需要依赖于工具生成代码、支持的语言相对较少，官方只支持Java 、C++、python。
+   - 适用场景：对性能要求高的 RPC 调用、具有良好的跨防火墙的访问属性、适合应用层对象的持久化。
+
+7. 其它
+
+   - 【重点】Protostuff ，基于 Protobuf 协议，但不需要配置proto 文件，直接导包即可。
+
+     - 目前，微博 RPC 框架 Motan 在使用它。
+
+   - 【了解】Jboss Marshaling ，可以直接序列化 Java 类， 无须实 `java.io.Serializable` 接口。
+
+   - 【了解】Message Pack ，一个高效的二进制序列化格式。
+
+   - 【重点】
+
+     Hessian
+
+      
+
+     ，采用二进制协议的轻量级 remoting on http 服务。
+
+     - 目前，阿里 RPC 框架 Dubbo 的**默认**序列化协议。
+
+   - 【重要】kryo ，是一个快速高效的Java对象图形序列化框架，主要特点是性能、高效和易用。该项目用来序列化对象到文件、数据库或者网络。
+
+     - 目前，阿里 RPC 框架 Dubbo 的可选序列化协议。
+
+   - 【重要】FST ，fast-serialization 是重新实现的 Java 快速对象序列化的开发包。序列化速度更快（2-10倍）、体积更小，而且兼容 JDK 原生的序列化。要求 JDK 1.7 支持。
+
+     - 目前，阿里 RPC 框架 Dubbo 的可选序列化协议。
+
+## Netty 的零拷贝实现？
+
+Netty 的零拷贝实现，是体现在多方面的，主要如下：
+
+1. 【重点】Netty 的接收和发送 ByteBuffer 采用堆外直接内存
+
+    
+
+   Direct Buffer
+
+    
+
+   。
+
+   - 使用堆外直接内存进行 Socket 读写，不需要进行字节缓冲区的二次拷贝；使用堆内内存会多了一次内存拷贝，JVM 会将堆内存 Buffer 拷贝一份到直接内存中，然后才写入 Socket 中。
+   - Netty 创建的 ByteBuffer 类型，由 ChannelConfig 配置。而 ChannelConfig 配置的 ByteBufAllocator 默认创建 Direct Buffer 类型。
+
+2. CompositeByteBuf
+
+    
+
+   类，可以将多个 ByteBuf 合并为一个逻辑上的 ByteBuf ，避免了传统通过内存拷贝的方式将几个小 Buffer 合并成一个大的 Buffer 。
+
+   - `#addComponents(...)` 方法，可将 header 与 body 合并为一个逻辑上的 ByteBuf 。这两个 ByteBuf 在CompositeByteBuf 内部都是单独存在的，即 CompositeByteBuf 只是逻辑上是一个整体。
+
+3. 通过
+
+    
+
+   FileRegion
+
+    
+
+   包装的 FileChannel 。
+
+   - `#tranferTo(...)` 方法，实现文件传输, 可以直接将文件缓冲区的数据发送到目标 Channel ，避免了传统通过循环 write 方式，导致的内存拷贝问题。
+
+4. 通过 **wrap** 方法, 我们可以将 `byte[]` 数组、ByteBuf、ByteBuffer 等包装成一个 Netty ByteBuf 对象, 进而避免了拷贝操作。
+
+## 原生的 NIO 存在 Epoll Bug 是什么？Netty 是怎么解决的？
+
+🦅 **Java NIO Epoll BUG**
+
+Java NIO Epoll 会导致 Selector 空轮询，最终导致 CPU 100% 。
+
+官方声称在 JDK 1.6 版本的 update18 修复了该问题，但是直到 JDK 1.7 版本该问题仍旧存在，只不过该 BUG 发生概率降低了一些而已，它并没有得到根本性解决。
+
+🦅 **Netty 解决方案**
+
+对 Selector 的 select 操作周期进行**统计**，每完成一次**空**的 select 操作进行一次计数，若在某个周期内连续发生 N 次空轮询，则判断触发了 Epoll 死循环 Bug 。
+
+> 艿艿：此处**空**的 select 操作的定义是，select 操作执行了 0 毫秒。
+
+此时，Netty **重建** Selector 来解决。判断是否是其他线程发起的重建请求，若不是则将原 SocketChannel 从旧的 Selector 上取消注册，然后重新注册到新的 Selector 上，最后将原来的 Selector 关闭。
+
+## 什么是 Netty 空闲检测？
+
+在 Netty 中，提供了 IdleStateHandler 类，正如其名，空闲状态处理器，用于检测连接的读写是否处于空闲状态。如果是，则会触发 IdleStateEvent 。
+
+IdleStateHandler 目前提供三种类型的心跳检测，通过构造方法来设置。代码如下：
+
+```
+// IdleStateHandler.java
+
+public IdleStateHandler(
+        int readerIdleTimeSeconds,
+        int writerIdleTimeSeconds,
+        int allIdleTimeSeconds) {
+    this(readerIdleTimeSeconds, writerIdleTimeSeconds, allIdleTimeSeconds,
+         TimeUnit.SECONDS);
+}
+```
+
+- `readerIdleTimeSeconds` 参数：为读超时时间，即测试端一定时间内未接受到被测试端消息。
+- `writerIdleTimeSeconds` 参数：为写超时时间，即测试端一定时间内向被测试端发送消息。
+- `allIdleTimeSeconds` 参数：为读或写超时时间。
+
+------
+
+另外，我们会在网络上看到类似《IdleStateHandler 心跳机制》这样标题的文章，实际上空闲检测和心跳机制是**两件事**。
+
+- 只是说，因为我们使用 IdleStateHandler 的目的，就是检测到连接处于空闲，通过心跳判断其是否还是**有效的连接**。
+- 虽然说，TCP 协议层提供了 Keeplive 机制，但是该机制默认的心跳时间是 2 小时，依赖操作系统实现不够灵活。因而，我们才在应用层上，自己实现心跳机制。
+
+具体的，我们来看看下面的问题 [「Netty 如何实现重连？」](https://svip.iocoder.cn/Netty/Interview/#) 。
+
+## Netty 如何实现重连？
+
+- 客户端，通过 IdleStateHandler 实现定时检测是否空闲，例如说 15 秒。
+  - 如果空闲，则向服务端发起心跳。
+  - 如果多次心跳失败，则关闭和服务端的连接，然后重新发起连接。
+- 服务端，通过 IdleStateHandler 实现定时检测客户端是否空闲，例如说 90 秒。
+  - 如果检测到空闲，则关闭客户端。
+  - 注意，如果接收到客户端的心跳请求，要反馈一个心跳响应给客户端。通过这样的方式，使客户端知道自己心跳成功。
+
+如下艿艿在自己的 [TaroRPC](https://github.com/YunaiV/TaroRPC) 中提供的一个示例：
+
+- [NettyClient.java](https://github.com/YunaiV/TaroRPC/blob/master/transport/transport-netty4/src/main/java/cn/iocoder/taro/transport/netty4/NettyClient.java) 中，设置 IdleStateHandler 和 ClientHeartbeatHandler。核心代码如下：
+
+  ```
+  // NettyHandler.java
+  
+  .addLast("idleState", new IdleStateHandler(TaroConstants.TRANSPORT_CLIENT_IDLE, TaroConstants.TRANSPORT_CLIENT_IDLE, 0, TimeUnit.MILLISECONDS))
+  .addLast("heartbeat", new ClientHeartbeatHandler())
+  ```
+
+- [NettyServer.java](https://github.com/YunaiV/TaroRPC/blob/master/transport/transport-netty4/src/main/java/cn/iocoder/taro/transport/netty4/NettyServer.java) 中，设置 IdleStateHandler 和 ServerHeartbeatHandler。核心代码如下：
+
+  ```
+  // NettyServer.java
+  
+  .addLast("idleState", new IdleStateHandler(0, 0, TaroConstants.TRANSPORT_SERVER_IDLE, TimeUnit.MILLISECONDS))
+  .addLast("heartbeat", new ServerHeartbeatHandler())
+  ```
+
+- [ClientHeartbeatHandler.java](https://github.com/YunaiV/TaroRPC/blob/master/transport/transport-netty4/src/main/java/cn/iocoder/taro/transport/netty4/heartbeat/ClientHeartbeatHandler.java) 中，碰到空闲，则发起心跳。不过，如何重连，暂时没有实现。需要考虑，重新发起连接可能会失败的情况。具体的，可以看看 [《一起学Netty（十四）之 Netty生产级的心跳和重连机制》](https://blog.csdn.net/linuu/article/details/51509847) 文章中的，ConnectionWatchdog 的代码。
+
+- [ServerHeartbeatHandler.java](https://github.com/YunaiV/TaroRPC/blob/6ce2af911ccec9ed5dc75c7f3ebda9c758272f3b/transport/transport-netty4/src/main/java/cn/iocoder/taro/transport/netty4/heartbeat/ServerHeartbeatHandler.java) 中，检测到客户端空闲，则直接关闭连接。
+
+## Netty 自己实现的 ByteBuf 有什么优点？
+
+如下是 [《Netty 实战》](http://svip.iocoder.cn/Netty/ByteBuf-1-1-ByteBuf-intro/#) 对它的**优点总**结：
+
+> - A01. 它可以被用户自定义的**缓冲区类型**扩展
+> - A02. 通过内置的符合缓冲区类型实现了透明的**零拷贝**
+> - A03. 容量可以**按需增长**
+> - A04. 在读和写这两种模式之间切换不需要调用 `#flip()` 方法
+> - A05. 读和写使用了**不同的索引**
+> - A06. 支持方法的**链式**调用
+> - A07. 支持引用计数
+> - A08. 支持**池化**
+
+- 特别是第 A04 这点，相信很多胖友都被 NIO ByteBuffer 反人类的读模式和写模式给坑哭了。在 [《精尽 Netty 源码分析 —— NIO 基础（三）之 Buffer》](http://svip.iocoder.cn/Netty/nio-3-buffer/) 中，我们也吐槽过了。😈
+
+想要进一步深入的，可以看看 [《精尽 Netty 源码解析 —— Buffer 之 ByteBuf（一）简介》](http://svip.iocoder.cn/Netty/ByteBuf-1-1-ByteBuf-intro/) 。
+
+## Netty 为什么要实现内存管理？
+
+🦅 **老艿艿的理解**
+
+在 Netty 中，IO 读写必定是非常频繁的操作，而考虑到更高效的网络传输性能，Direct ByteBuffer 必然是最合适的选择。但是 Direct ByteBuffer 的申请和释放是高成本的操作，那么进行**池化**管理，多次重用是比较有效的方式。但是，不同于一般于我们常见的对象池、连接池等**池化**的案例，ByteBuffer 是有**大小**一说。又但是，申请多大的 Direct ByteBuffer 进行池化又会是一个大问题，太大会浪费内存，太小又会出现频繁的扩容和内存复制！！！所以呢，就需要有一个合适的内存管理算法，解决**高效分配内存**的同时又解决**内存碎片化**的问题。
+
+🦅 **官方的说法**
+
+> FROM [《Netty 学习笔记 —— Pooled buffer》](https://skyao.gitbooks.io/learning-netty/content/buffer/pooled_buffer.html)
+>
+> Netty 4.x 增加了 Pooled Buffer，实现了高性能的 buffer 池，分配策略则是结合了 buddy allocation 和 slab allocation 的 **jemalloc** 变种，代码在`io.netty.buffer.PoolArena` 中。
+>
+> 官方说提供了以下优势：
+>
+> - 频繁分配、释放 buffer 时减少了 GC 压力。
+> - 在初始化新 buffer 时减少内存带宽消耗( 初始化时不可避免的要给buffer数组赋初始值 )。
+> - 及时的释放 direct buffer 。
+
+🦅 **hushi55 大佬的理解**
+
+> > C/C++ 和 java 中有个围城，城里的想出来，城外的想进去！**
+>
+> 这个围城就是自动内存管理！
+>
+> **Netty 4 buffer 介绍**
+>
+> Netty4 带来一个与众不同的特点是其 ByteBuf 的实现，相比之下，通过维护两个独立的读写指针， 要比 `io.netty.buffer.ByteBuf` 简单不少，也会更高效一些。不过，Netty 的 ByteBuf 带给我们的最大不同，就是他不再基于传统 JVM 的 GC 模式，相反，它采用了类似于 C++ 中的 malloc/free 的机制，需要开发人员来手动管理回收与释放。从手动内存管理上升到GC，是一个历史的巨大进步， 不过，在20年后，居然有曲线的回归到了手动内存管理模式，正印证了马克思哲学观： **社会总是在螺旋式前进的，没有永远的最好。**
+>
+> **① GC 内存管理分析**
+>
+> 的确，就内存管理而言，GC带给我们的价值是不言而喻的，不仅大大的降低了程序员的心智包袱， 而且，也极大的减少了内存管理带来的 Crash 困扰，为函数式编程（大量的临时对象）、脚本语言编程带来了春天。 并且，高效的GC算法也让大部分情况下程序可以有更高的执行效率。 不过，也有很多的情况，可能是手工内存管理更为合适的。譬如：
+>
+> - 对于类似于业务逻辑相对简单，譬如网络路由转发型应用（很多erlang应用其实是这种类型）， 但是 QPS 非常高，比如1M级，在这种情况下，在每次处理中即便产生1K的垃圾，都会导致频繁的GC产生。 在这种模式下，erlang 的按进程回收模式，或者是 C/C++ 的手工回收机制，效率更高。
+> - Cache 型应用，由于对象的存在周期太长，GC 基本上就变得没有价值。
+>
+> 所以，理论上，尴尬的GC实际上比较适合于处理介于这 2 者之间的情况： 对象分配的频繁程度相比数据处理的时间要少得多的，但又是相对短暂的， 典型的，对于OLTP型的服务，处理能力在 1K QPS 量级，每个请求的对象分配在 10K-50K 量级， 能够在 5-10s 的时间内进行一 次younger GC ，每次GC的时间可以控制在 10ms 水平上， 这类的应用，实在是太适合 GC 行的模式了，而且结合 Java 高效的分代 GC ，简直就是一个理想搭配。
+>
+> **② 影响**
+>
+> Netty 4 引入了手工内存的模式，我觉得这是一大创新，这种模式甚至于会延展， 应用到 Cache 应用中。实际上，结合 JVM 的诸多优秀特性，如果用 Java 来实现一个 Redis 型 Cache、 或者 In-memory SQL Engine，或者是一个 Mongo DB，我觉得相比 C/C++ 而言，都要更简单很多。 实际上，JVM 也已经提供了打通这种技术的机制，就是 Direct Memory 和 Unsafe 对象。 基于这个基础，我们可以像 C 语言一样直接操作内存。实际上，Netty4 的 ByteBuf 也是基于这个基础的。
+
+更多详细的内容，胖友可以看看 [《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（一）简介》](http://svip.iocoder.cn/Netty/ByteBuf-3-1-Jemalloc-intro/) 。
+
+## Netty 如何实心内存管理？
+
+> 这个题目，简单了解即可，如果深入，就要去看 [《精尽 Netty 源码解析 —— Buffer》](http://svip.iocoder.cn/categories/Netty/) 相关的源码。而且，看完就忘记，比较难和复杂。
+>
+> 当然，看懂那一刻，乐趣无穷，哈哈哈哈。
+
+Netty 内存管理机制，基于 [Jemalloc](http://www.cnhalo.net/2016/06/13/memory-optimize/) 算法。
+
+- 首先会预申请一大块内存 **Arena** ，Arena 由许多 Chunk 组成，而每个 Chunk 默认由2048个page组成。
+- **Chunk** 通过 **AVL** 树的形式组织 **Page** ，每个叶子节点表示一个 Page ，而中间节点表示内存区域，节点自己记录它在整个 Arena 中的偏移地址。当区域被分配出去后，中间节点上的标记位会被标记，这样就表示这个中间节点以下的所有节点都已被分配了。大于 8k 的内存分配在 **PoolChunkList** 中，而 **PoolSubpage** 用于分配小于 8k 的内存，它会把一个 page 分割成多段，进行内存分配。
+
+## 什么是 Netty 的内存泄露检测？是如何进行实现的？
+
+> 艿艿：这是一道比较复杂的面试题，可以挑战一下。
+
+推荐阅读如下两篇文章：
+
+- [《Netty 之有效规避内存泄漏》](http://calvin1978.blogcn.com/articles/netty-leak.html) 从原理层面解释。
+- [《精尽 Netty 源码解析 —— Buffer 之 ByteBuf（三）内存泄露检测》](http://svip.iocoder.cn/Netty/ByteBuf-1-3-ByteBuf-resource-leak-detector/) 从源码层面解读。
+
+另外，Netty 的内存泄露检测的实现，是对 WeakReference 和 ReferenceQueue 很好的学习。之前很多胖友在看了 [《Java 中的四种引用类型》](http://www.iocoder.cn/Fight/Four-reference-types-in-Java) 之后，是不太理解 Java 的四种引用的具体使用场景，这不就来了么。
+
+# 666. 彩蛋
+
+😈 撸完 Netty 源码之后，一段时间没去用，东西都忘了蛮多。不过因为读过源码，在看这些面试题，会发现轻松太多了。有一种，“老朋友”的感觉。妥妥的。
+
+参考与推荐如下文章：
+
+- itdragon [《Netty 序章之 BIO NIO AIO 演变》](https://segmentfault.com/a/1190000012976683)
+- 白夜行515 [《【面试题】Netty相关》](https://blog.csdn.net/baiye_xing/article/details/76735113)
+- albon [《Netty 权威指南笔记（二）：Java NIO 和 Netty 对比》](https://www.jianshu.com/p/93876f1bf6d1)
+- albon [《Netty 权威指南笔记（四）：架构剖析》](https://www.jianshu.com/p/ececec069cc1)
+- 狗窝 [《面试题之 Netty》](https://nizouba.com/articles/2018/11/04/1541322296629.html) 题目很不错，就是图片都挂了。
\ No newline at end of file
diff --git a/netty/02-Netty 学习指南.md b/netty/02-Netty 学习指南.md
new file mode 100644
index 0000000..e5d4447
--- /dev/null
+++ b/netty/02-Netty 学习指南.md	
@@ -0,0 +1,39 @@
+# 精尽 Netty 学习指南
+
+# 视频
+
+- [《NIO 视频教程全集》](https://www.bilibili.com/video/av59543731/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共有 13P ，3 小时多。
+  >
+  > 适合对 NIO 了解不多的胖哟偶偶
+
+- [《Netty 视频教程全集》](https://www.bilibili.com/video/av59683486?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 92 P ，61 小时。涉及的还是蛮广的。
+
+- 闪电侠 [《Java 读源码之 Netty 深入剖析》](https://coding.imooc.com/class/ds/230) 好基友，艿艿已经看过一遍，灰常不错
+
+- 学徒无忧 [《全网首部 Netty 源码剖析与 NIO + Netty 5 各种RPC架构实战演练》](https://www.bilibili.com/video/av33238175) 一共 60 P ，源码解析为主，基于 Netty 5 ，有点不清晰
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 书籍
+
+[《Netty 书单整理》](http://www.iocoder.cn/Books/Netty-books-recommended)
+
+- 闪电侠 [《Netty 入门与实战：仿写微信 IM 即时通讯系统》](https://juejin.im/book/5b4bc28bf265da0f60130116?referrer=5904c637b123db3ee479d923) 最易懂的 Netty 入门与实战的书籍
+- 诺曼·毛瑞尔 [《Netty 实战》](https://union-click.jd.com/jdc?d=RakFcl) 豆瓣评分 8.1 分，还是不错的书籍，艿艿买了
+
+# 文章
+
+1. [微信聊天表结构设计](https://wenku.baidu.com/view/b7c83e54ba0d4a7302763acf.html)
+2. [微信小程序中如何使用 WebSocket 实现长连接](https://www.cnblogs.com/imstudy/p/9224604.html)
+3. [新手入门一篇就够：从零开发移动端 IM](http://www.52im.net/thread-464-1-1.html)
+4. [大佬的 Netty 企业即时通讯系统博客](http://www.cookqq.com/listBlog.action?type=8a10a5f34e38beab014e4cd6b9e801cf)
+5. [《Netty高性能编程备忘录(上)》](http://calvin1978.blogcn.com/articles/netty-performance.html)
+6. [《Netty高性能编程备忘录（下）》](http://calvin1978.blogcn.com/articles/netty-performance2.html)
\ No newline at end of file
diff --git a/netty/03-Netty 源码分析-调试环境搭建.assets/01.png b/netty/03-Netty 源码分析-调试环境搭建.assets/01.png
new file mode 100644
index 0000000..3b81038
Binary files /dev/null and b/netty/03-Netty 源码分析-调试环境搭建.assets/01.png differ
diff --git a/netty/03-Netty 源码分析-调试环境搭建.assets/02.png b/netty/03-Netty 源码分析-调试环境搭建.assets/02.png
new file mode 100644
index 0000000..89b5e10
Binary files /dev/null and b/netty/03-Netty 源码分析-调试环境搭建.assets/02.png differ
diff --git a/netty/03-Netty 源码分析-调试环境搭建.md b/netty/03-Netty 源码分析-调试环境搭建.md
new file mode 100644
index 0000000..55727fa
--- /dev/null
+++ b/netty/03-Netty 源码分析-调试环境搭建.md	
@@ -0,0 +1,106 @@
+# 精尽 Netty 源码分析 —— 调试环境搭建
+
+# 1. 依赖工具
+
+- Maven
+- Git
+- JDK
+- IntelliJ IDEA
+
+# 2. 源码拉取
+
+从官方仓库 https://github.com/netty/netty `Fork` 出属于自己的仓库。为什么要 `Fork` ？既然开始阅读、调试源码，我们可能会写一些注释，有了自己的仓库，可以进行自由的提交。😈
+
+使用 `IntelliJ IDEA` 从 `Fork` 出来的仓库拉取代码。
+
+本文使用的 Netty 版本为 `4.1.26.Final-SNAPSHOT` 。
+
+# 3. Maven Profile
+
+打开 IDEA 的 **Maven Projects** ，选择对应的 Profiles 。如下图所示：
+
+[![Maven Projects](03-Netty 源码分析-调试环境搭建.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_01_01/01.png)Maven Projects
+
+- `jdk8` ：笔者使用的 JDK 版本是 8 ，所以勾选了 `jdk8` 。如果错误的选择，可能会报如下错误：
+
+  ```
+  java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer
+  ```
+
+- `mac` ：选择对应的系统版本。😈 笔者手头没有 windows 的电脑，所以不知道该怎么选。
+
+修改完成后，点击左上角的【刷新】按钮，进行依赖下载，耐心等待…
+
+# 4. 解决依赖报错
+
+在 `codec-redis` 模块中，类 FixedRedisMessagePool 会报如下类不存在的问题：
+
+```
+import io.netty.util.collection.LongObjectHashMap;
+import io.netty.util.collection.LongObjectMap;
+```
+
+- 具体如下图所示：[![依赖报错](03-Netty 源码分析-调试环境搭建.assets/02.png)](http://static.iocoder.cn/images/Netty/2018_01_01/02.png)依赖报错
+
+解决方式如下：
+
+```
+cd common;
+mvn clean compile;
+```
+
+- 跳转到 `common` 模块中，编译生成对应的类。为什么可以通过编译生成对应的类呢，原因参见 `common` 模块的 `src/java/templates/io/netty/util/collection` 目录下的 `.template` 文件。
+
+在 Github 上，也有多个针对这个情况讨论的 issue ：
+
+- [《Can not find class io.netty.util.collection.LongObjectHashMap in 4.1.8.final》](https://github.com/netty/netty/issues/7518)
+- [《io.netty.util.collection.LongObjectHashMap not found at branch 4.1》](https://github.com/netty/netty/issues/5447)
+
+# 5. example 模块
+
+在 `example` 模块里，官网提供了多个 Netty 的使用示例。
+本文以 `echo` 包下来作为示例。哈哈哈，因为最简单。
+
+## 5.1 EchoServer
+
+执行 `io.netty.example.echo.EchoServer` 的 `#main(args)` 方法，启动服务端。输出日志如下：
+
+```
+20:41:41.215 [nioEventLoopGroup-2-1] INFO  i.n.handler.logging.LoggingHandler - [id: 0xd0219f1c] REGISTERED
+20:41:41.222 [nioEventLoopGroup-2-1] INFO  i.n.handler.logging.LoggingHandler - [id: 0xd0219f1c] BIND: 0.0.0.0/0.0.0.0:8007
+20:41:41.228 [nioEventLoopGroup-2-1] INFO  i.n.handler.logging.LoggingHandler - [id: 0xd0219f1c, L:/0:0:0:0:0:0:0:0:8007] ACTIVE
+```
+
+## 5.2 EchoClient
+
+执行 `io.netty.example.echo.EchoClientr` 的 `#main(args)` 方法，启动客户端。**不输出任何日志**。
+
+但是，EchoServer 会新输出如下日志：
+
+```
+20:41:45.642 [nioEventLoopGroup-2-1] INFO  i.n.handler.logging.LoggingHandler - [id: 0xd0219f1c, L:/0:0:0:0:0:0:0:0:8007] READ: [id: 0x32721f32, L:/127.0.0.1:8007 - R:/127.0.0.1:50663]
+20:41:45.646 [nioEventLoopGroup-2-1] INFO  i.n.handler.logging.LoggingHandler - [id: 0xd0219f1c, L:/0:0:0:0:0:0:0:0:8007] READ COMPLETE
+```
+
+# 6. 结尾
+
+如此，我们就可以愉快的进行 Netty 调试啦。读源码，一定要多多调试源码。非常重要！！！
+
+另外，也推荐基友 zhisheng 的文章：[《Netty系列文章（一）：Netty 源码阅读之初始环境搭建》](http://www.54tianzhisheng.cn/2017/12/08/netty-01-env/) 。
+
+# 7. 为什么使用 Netty
+
+如下内容，引用自我的基友闪电侠的分享
+
+> FROM [《Netty 源码分析之服务端启动全解析》](https://www.jianshu.com/p/c5068caab217)
+>
+> netty 底层基于 jdk 的 NIO ，我们为什么不直接基于 jdk 的 nio 或者其他 nio 框架？下面是我总结出来的原因
+>
+> 1. 使用 jdk 自带的 nio 需要了解太多的概念，编程复杂
+> 2. netty 底层 IO 模型随意切换，而这一切只需要做微小的改动
+> 3. netty 自带的拆包解包，异常检测等机制让你从nio的繁重细节中脱离出来，让你只需要关心业务逻辑
+> 4. netty 解决了 jdk 的很多包括空轮训在内的 bug
+> 5. netty 底层对线程，selector 做了很多细小的优化，精心设计的 reactor 线程做到非常高效的并发处理
+> 6. 自带各种协议栈让你处理任何一种通用协议都几乎不用亲自动手
+> 7. netty 社区活跃，遇到问题随时邮件列表或者 issue
+> 8. netty 已经历各大rpc框架，消息中间件，分布式通信中间件线上的广泛验证，健壮性无比强大
\ No newline at end of file
diff --git a/netty/04-Netty 源码分析-NIO 基础（一）之简介.md b/netty/04-Netty 源码分析-NIO 基础（一）之简介.md
new file mode 100644
index 0000000..a4faf7c
--- /dev/null
+++ b/netty/04-Netty 源码分析-NIO 基础（一）之简介.md	
@@ -0,0 +1,89 @@
+# 精尽 Netty 源码分析 —— NIO 基础（一）之简介
+
+# 1. 概述
+
+Java NIO( New IO 或者 Non Blocking IO ) ，从 Java 1.4 版本开始引入的**非阻塞** IO ，用于替换**标准**( 有些文章也称为**传统**，或者 Blocking IO 。下文统称为 BIO ) Java IO API 的 IO API 。
+
+> 老艿艿：在一些文章中，会将 Java NIO 描述成**异步** IO ，实际是不太正确的： Java NIO 是**同步** IO ，Java AIO ( 也称为 NIO 2 )是**异步** IO。具体原因，推荐阅读文章：
+>
+> - [《异步和非阻塞一样吗? (内容涉及 BIO, NIO, AIO, Netty)》](https://blog.csdn.net/matthew_zhang/article/details/71328697) 。
+> - [《BIO与NIO、AIO的区别(这个容易理解)》](https://blog.csdn.net/skiof007/article/details/52873421)
+>
+> 总结来说，在 **Unix IO 模型**的语境下：
+>
+> - 同步和异步的区别：数据拷贝阶段是否需要完全由操作系统处理。
+> - 阻塞和非阻塞操作：是针对发起 IO 请求操作后，是否有立刻返回一个标志信息而不让请求线程等待。
+>
+> 因此，Java NIO 是**同步**且非阻塞的 IO 。
+
+# 2. 核心组件
+
+Java NIO 由如下**三个**核心组件组成：
+
+- Channel
+- Buffer
+- Selector
+
+后续的每篇文章，我们会分享对应的一个组件。
+
+# 3. NIO 和 BIO 的对比
+
+NIO 和 BIO 的区别主要体现在三个方面：
+
+| NIO                  | BIO              |
+| :------------------- | :--------------- |
+| 基于缓冲区( Buffer ) | 基于流( Stream ) |
+| **非**阻塞 IO        | 阻塞 IO          |
+| 选择器( Selector )   | 无               |
+
+- 其中，选择器( Selector )是 NIO 能实现**非**阻塞的基础。
+
+## 3.1 基于 Buffer 与基于 Stream
+
+BIO 是面向字节流或者字符流的，而在 NIO 中，它摒弃了传统的 IO 流，而是引入 Channel 和 Buffer 的概念：从 Channel 中读取数据到 Buffer 中，或者将数据从 Buffer 中写到 Channel 中。
+
+① 那么什么是**基于 Stream**呢？
+
+在一般的 Java IO 操作中，我们以**流式**的方式，**顺序**的从一个 Stream 中读取一个或者多个字节，直至读取所有字节。因为它没有缓存区，所以我们就不能随意改变读取指针的位置。
+
+② 那么什么是**基于 Buffer** 呢？
+
+基于 Buffer 就显得有点不同了。我们在从 Channel 中读取数据到 Buffer 中，这样 Buffer 中就有了数据后，我们就可以对这些数据进行操作了。并且不同于一般的 Java IO 操作那样是**顺序**操作，NIO 中我们可以随意的读取任意位置的数据，这样大大增加了处理过程中的灵活性。
+
+> 老艿艿：**写入**操作，也符合上述**读取**操作的情况。
+
+## 3.2 阻塞与非阻塞 IO
+
+Java IO 的各种流是**阻塞**的 IO 操作。这就意味着，当一个线程执行读或写 IO 操作时，该线程会被**阻塞**，直到有一些数据被读取，或者数据完全写入。
+
+------
+
+Java NIO 可以让我们**非阻塞**的使用 IO 操作。例如：
+
+- 当一个线程执行从 Channel 执行读取 IO 操作时，当此时有数据，则读取数据并返回；当此时无数据，则直接返回**而不会阻塞当前线程**。
+- 当一个线程执行向 Channel 执行写入 IO 操作时，**不需要阻塞等待它完全写入**，这个线程同时可以做别的事情。
+
+也就是说，线程可以将非阻塞 IO 的空闲时间用于在其他 Channel 上执行 IO 操作。所以，一个单独的线程，可以管理多个 Channel 的读取和写入 IO 操作。
+
+## 3.3 Selector
+
+Java NIO 引入 Selector ( 选择器 )的概念，它是 Java NIO 得以实现非阻塞 IO 操作的**最最最关键**。
+
+我们可以注册**多个** Channel 到**一个** Selector 中。而 Selector 内部的机制，就可以自动的为我们不断的执行查询( select )操作，判断这些注册的 Channel 是否有**已就绪的 IO 事件( 例如可读，可写，网络连接已完成 )**。
+通过这样的机制，**一个**线程通过使用**一个** Selector ，就可以非常简单且高效的来管理**多个** Channel 了。
+
+# 4. NIO 和 AIO 的对比
+
+考虑到 Netty 4.1.X 版本实际并未基于 Java AIO 实现，所以我们就省略掉这块内容。那么，感兴趣的同学，可以自己 Google 下 Java NIO 和 Java AIO 的对比。
+
+具体为什么 Netty 4.1.X 版本不支持 Java AIO 的原因，可参见 [《Netty（二）：Netty 为啥去掉支持 AIO ?》](https://juejin.im/entry/5a8ed33b6fb9a0634c26801c) 文章。
+
+也因此，Netty 4.1.X 一般情况下，使用的是**同步非阻塞的 NIO 模型**。当然，如果真的有必要，也可以使用**同步阻塞的 BIO 模型**。
+
+# 666. 彩蛋
+
+参考文章如下：
+
+- [《高并发 Java（8）：NIO 和 AIO》](http://www.importnew.com/21341.html)
+- [《Java NIO 的前生今世 之一 简介》](https://segmentfault.com/a/1190000006824091)
+- [《Java NIO 系列教程（十二） Java NIO 与 IO》](http://ifeve.com/java-nio-vs-io/)
\ No newline at end of file
diff --git a/netty/05-Netty 源码分析-NIO 基础（二）之 Channel.assets/01.png b/netty/05-Netty 源码分析-NIO 基础（二）之 Channel.assets/01.png
new file mode 100644
index 0000000..478e46c
Binary files /dev/null and b/netty/05-Netty 源码分析-NIO 基础（二）之 Channel.assets/01.png differ
diff --git a/netty/05-Netty 源码分析-NIO 基础（二）之 Channel.md b/netty/05-Netty 源码分析-NIO 基础（二）之 Channel.md
new file mode 100644
index 0000000..3d8a4bc
--- /dev/null
+++ b/netty/05-Netty 源码分析-NIO 基础（二）之 Channel.md	
@@ -0,0 +1,68 @@
+# 精尽 Netty 源码分析 —— NIO 基础（二）之 Channel
+
+# 1. 概述
+
+在 Java NIO 中，基本上所有的 IO 操作都是从 Channel 开始。数据可以从 Channel 读取到 Buffer 中，也可以从 Buffer 写到 Channel 中。如下图所示：
+
+[![Buffer <=> Channel](05-Netty 源码分析-NIO 基础（二）之 Channel.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_02_05/01.png)Buffer <=> Channel
+
+# 2. NIO Channel 对比 Java Stream
+
+NIO Channel **类似** Java Stream ，但又有几点不同：
+
+1. 对于**同一个** Channel ，我们可以从它读取数据，也可以向它写入数据。而对于**同一个** Stream ，通畅要么只能读，要么只能写，二选一( 有些文章也描述成“单向”，也是这个意思 )。
+2. Channel 可以**非阻塞**的读写 IO 操作，而 Stream 只能**阻塞**的读写 IO 操作。
+3. Channel **必须配合** Buffer 使用，总是先读取到一个 Buffer 中，又或者是向一个 Buffer 写入。也就是说，我们无法绕过 Buffer ，直接向 Channel 写入数据。
+
+# 3. Channel 的实现
+
+Channel 在 Java 中，作为一个**接口**，`java.nio.channels.Channel` ，定义了 IO 操作的**连接与关闭**。代码如下：
+
+```
+public interface Channel extends Closeable {
+
+    /**
+     * 判断此通道是否处于打开状态。 
+     */
+    public boolean isOpen();
+
+    /**
+     *关闭此通道。
+     */
+    public void close() throws IOException;
+
+}
+```
+
+Channel 有非常多的实现类，最为重要的**四个** Channel 实现类如下：
+
+- SocketChannel ：一个客户端用来**发起** TCP 的 Channel 。
+- ServerSocketChannel ：一个服务端用来**监听**新进来的连接的 TCP 的 Channel 。对于每一个新进来的连接，都会创建一个对应的 SocketChannel 。
+- DatagramChannel ：通过 UDP 读写数据。
+- FileChannel ：从文件中，读写数据。
+
+> 老艿艿：因为 [《Java NIO 系列教程》](http://ifeve.com/java-nio-all/) 对上述的 Channel 解释的非常不错，我就直接引用啦。
+>
+> 我们在使用 Netty 时，主要使用 TCP 协议，所以胖友可以只看 [「3.2 SocketChannel」](https://svip.iocoder.cn/Netty/nio-2-channel/#) 和 [「3.1 ServerSocketChannel」](https://svip.iocoder.cn/Netty/nio-2-channel/#) 。
+
+## 3.1 ServerSocketChannel
+
+[《Java NIO系列教程（九） ServerSocketChannel》](http://ifeve.com/server-socket-channel/)
+
+## 3.2 SocketChannel
+
+[《Java NIO 系列教程（八） SocketChannel》](http://ifeve.com/socket-channel/)
+
+## 3.3 DatagramChannel
+
+[《Java NIO系列教程（十） Java NIO DatagramChannel》](http://ifeve.com/datagram-channel/)
+
+## 3.4 FileChannel
+
+[《Java NIO系列教程（七） FileChannel》](http://ifeve.com/file-channel/)
+
+# 666. 彩蛋
+
+参考文章如下：
+
+- [《Java NIO 系列教程（二） Channel》](http://ifeve.com/channels/)
\ No newline at end of file
diff --git a/netty/06-Netty 源码分析-NIO 基础（三）之 Buffer.assets/01.png b/netty/06-Netty 源码分析-NIO 基础（三）之 Buffer.assets/01.png
new file mode 100644
index 0000000..0913393
Binary files /dev/null and b/netty/06-Netty 源码分析-NIO 基础（三）之 Buffer.assets/01.png differ
diff --git a/netty/06-Netty 源码分析-NIO 基础（三）之 Buffer.assets/02.png b/netty/06-Netty 源码分析-NIO 基础（三）之 Buffer.assets/02.png
new file mode 100644
index 0000000..cfca3bc
Binary files /dev/null and b/netty/06-Netty 源码分析-NIO 基础（三）之 Buffer.assets/02.png differ
diff --git a/netty/06-Netty 源码分析-NIO 基础（三）之 Buffer.md b/netty/06-Netty 源码分析-NIO 基础（三）之 Buffer.md
new file mode 100644
index 0000000..f799797
--- /dev/null
+++ b/netty/06-Netty 源码分析-NIO 基础（三）之 Buffer.md	
@@ -0,0 +1,507 @@
+# 精尽 Netty 源码分析 —— NIO 基础（三）之 Buffer
+
+# 1. 概述
+
+一个 Buffer ，本质上是内存中的一块，我们可以将数据写入这块内存，之后从这块内存获取数据。通过将这块内存封装成 NIO Buffer 对象，并提供了一组常用的方法，方便我们对该块内存的读写。
+
+Buffer 在 `java.nio` 包中实现，被定义成**抽象类**，从而实现一组常用的方法。整体类图如下：
+
+[![类图](06-Netty 源码分析-NIO 基础（三）之 Buffer.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_02_10/01.png)类图
+
+- 我们可以将 Buffer 理解为**一个数组的封装**，例如 IntBuffer、CharBuffer、ByteBuffer 等分别对应 `int[]`、`char[]`、`byte[]` 等。
+- MappedByteBuffer 用于实现内存映射文件，不是本文关注的重点。因此，感兴趣的胖友，可以自己 Google 了解，还是蛮有趣的。
+
+# 2. 基本属性
+
+Buffer 中有 **4** 个非常重要的属性：`capacity`、`limit`、`position`、`mark` 。代码如下：
+
+```
+public abstract class Buffer {
+
+    // Invariants: mark <= position <= limit <= capacity
+    private int mark = -1;
+    private int position = 0;
+    private int limit;
+    private int capacity;
+
+    // Used only by direct buffers
+    // NOTE: hoisted here for speed in JNI GetDirectBufferAddress
+    long address;
+
+    Buffer(int mark, int pos, int lim, int cap) {       // package-private
+        if (cap < 0)
+            throw new IllegalArgumentException("Negative capacity: " + cap);
+        this.capacity = cap;
+        limit(lim);
+        position(pos);
+        if (mark >= 0) {
+            if (mark > pos)
+                throw new IllegalArgumentException("mark > position: ("
+                                                   + mark + " > " + pos + ")");
+            this.mark = mark;
+        }
+    }
+    
+    // ... 省略具体方法的代码
+}
+```
+
+- `capacity` 属性，容量，Buffer 能容纳的数据元素的**最大值**。这一容量在 Buffer 创建时被赋值，并且**永远不能被修改**。
+
+- Buffer 分成
+
+  写模式
+
+  和
+
+  读模式
+
+  两种情况。如下图所示：
+
+  ![写模式 v.s. 读模式](06-Netty 源码分析-NIO 基础（三）之 Buffer.assets/02.png)
+
+  写模式 v.s. 读模式
+
+  - 从图中，我们可以看到，两种模式下，`position` 和 `limit` 属性分别代表不同的含义。下面，我们来分别看看。
+
+- ```
+  position
+  ```
+
+   
+
+  属性，位置，初始值为 0 。
+
+  - **写**模式下，每往 Buffer 中写入一个值，`position` 就自动加 1 ，代表下一次的写入位置。
+  - **读**模式下，每从 Buffer 中读取一个值，`position` 就自动加 1 ，代表下一次的读取位置。( *和写模式类似* )
+
+- ```
+  limit
+  ```
+
+   
+
+  属性，上限。
+
+  - **写**模式下，代表最大能写入的数据上限位置，这个时候 `limit` 等于 `capacity` 。
+  - **读**模式下，在 Buffer 完成所有数据写入后，通过调用 `#flip()` 方法，切换到**读**模式。此时，`limit` 等于 Buffer 中实际的数据大小。因为 Buffer 不一定被写满，所以不能使用 `capacity` 作为实际的数据大小。
+
+- ```
+  mark
+  ```
+
+   
+
+  属性，标记，通过
+
+   
+
+  ```
+  #mark()
+  ```
+
+   
+
+  方法，记录当前
+
+   
+
+  ```
+  position
+  ```
+
+   
+
+  ；通过
+
+   
+
+  ```
+  reset()
+  ```
+
+   
+
+  方法，恢复
+
+   
+
+  ```
+  position
+  ```
+
+   
+
+  为标记。
+
+  - **写**模式下，标记上一次写位置。
+  - **读**模式下，标记上一次读位置。
+
+- 从代码注释上，我们可以看到，四个属性总是遵循如下大小关系：
+
+  ```
+  mark <= position <= limit <= capacity
+  ```
+
+------
+
+写到此处，忍不住吐槽了下，Buffer 的读模式和写模式，我认为是有一点“**糟糕**”。相信大多数人在理解的时候，都会开始一脸懵逼的状态。相比较来说，Netty 的 ByteBuf 就**优雅**的非常多，基本属性设计如下：
+
+```
+0 <= readerIndex <= writerIndex <= capacity
+```
+
+- 通过 `readerIndex` 和 `writerIndex` 两个属性，避免出现读模式和写模式的切换。
+
+# 3. 创建 Buffer
+
+① 每个 Buffer 实现类，都提供了 `#allocate(int capacity)` 静态方法，帮助我们快速**实例化**一个 Buffer 对象。以 ByteBuffer 举例子，代码如下：
+
+```
+// ByteBuffer.java
+public static ByteBuffer allocate(int capacity) {
+    if (capacity < 0)
+        throw new IllegalArgumentException();
+    return new HeapByteBuffer(capacity, capacity);
+}
+```
+
+- ByteBuffer 实际是个抽象类，返回的是它的**基于堆内( Non-Direct )内存**的实现类 HeapByteBuffer 的对象。
+
+② 每个 Buffer 实现类，都提供了 `#wrap(array)` 静态方法，帮助我们将其对应的数组**包装**成一个 Buffer 对象。还是以 ByteBuffer 举例子，代码如下：
+
+```
+// ByteBuffer.java
+public static ByteBuffer wrap(byte[] array, int offset, int length){
+    try {
+        return new HeapByteBuffer(array, offset, length);
+    } catch (IllegalArgumentException x) {
+        throw new IndexOutOfBoundsException();
+    }
+}
+
+public static ByteBuffer wrap(byte[] array) {
+    return wrap(array, 0, array.length);
+}
+```
+
+- 和 `#allocate(int capacity)` 静态方法**一样**，返回的也是 HeapByteBuffer 的对象。
+
+③ 每个 Buffer 实现类，都提供了 `#allocateDirect(int capacity)` 静态方法，帮助我们快速**实例化**一个 Buffer 对象。以 ByteBuffer 举例子，代码如下：
+
+```
+// ByteBuffer.java
+public static ByteBuffer allocateDirect(int capacity) {
+    return new DirectByteBuffer(capacity);
+}
+```
+
+- 和 `#allocate(int capacity)` 静态方法**不一样**，返回的是它的**基于堆外( Direct )内存**的实现类 DirectByteBuffer 的对象。
+
+## 3.1 关于 Direct Buffer 和 Non-Direct Buffer 的区别
+
+> FROM [《Java NIO 的前生今世 之三 NIO Buffer 详解》](https://segmentfault.com/a/1190000006824155)
+>
+> **Direct Buffer:**
+>
+> - 所分配的内存不在 JVM 堆上, 不受 GC 的管理.(但是 Direct Buffer 的 Java 对象是由 GC 管理的, 因此当发生 GC, 对象被回收时, Direct Buffer 也会被释放)
+> - 因为 Direct Buffer 不在 JVM 堆上分配, 因此 Direct Buffer 对应用程序的内存占用的影响就不那么明显(实际上还是占用了这么多内存, 但是 JVM 不好统计到非 JVM 管理的内存.)
+> - 申请和释放 Direct Buffer 的开销比较大. 因此正确的使用 Direct Buffer 的方式是在初始化时申请一个 Buffer, 然后不断复用此 buffer, 在程序结束后才释放此 buffer.
+> - 使用 Direct Buffer 时, 当进行一些底层的系统 IO 操作时, 效率会比较高, 因为此时 JVM 不需要拷贝 buffer 中的内存到中间临时缓冲区中.
+>
+> **Non-Direct Buffer:**
+>
+> - 直接在 JVM 堆上进行内存的分配, 本质上是 byte[] 数组的封装.
+> - 因为 Non-Direct Buffer 在 JVM 堆中, 因此当进行操作系统底层 IO 操作中时, 会将此 buffer 的内存复制到中间临时缓冲区中. 因此 Non-Direct Buffer 的效率就较低.
+
+笔者之前研究 JVM 内存时，也整理过一个脑图，感兴趣的胖友可以下载：[传送门](http://static.iocoder.cn/Java内存.xmind) 。
+
+# 4. 向 Buffer 写入数据
+
+每个 Buffer 实现类，都提供了 `#put(...)` 方法，向 Buffer 写入数据。以 ByteBuffer 举例子，代码如下：
+
+```
+// 写入 byte
+public abstract ByteBuffer put(byte b); 
+public abstract ByteBuffer put(int index, byte b);
+// 写入 byte 数组
+public final ByteBuffer put(byte[] src) { ... }
+public ByteBuffer put(byte[] src, int offset, int length) {...}
+// ... 省略，还有其他 put 方法
+```
+
+对于 Buffer 来说，有一个非常重要的操作就是，我们要讲来自 Channel 的数据写入到 Buffer 中。在系统层面上，这个操作我们称为**读操作**，因为数据是从外部( 文件或者网络等 )读取到内存中。示例如下：
+
+```
+int num = channel.read(buffer);
+```
+
+- 上述方法会返回从 Channel 中写入到 Buffer 的数据大小。对应方法的代码如下：
+
+  ```
+  public interface ReadableByteChannel extends Channel {
+  
+      public int read(ByteBuffer dst) throws IOException;
+      
+  }
+  ```
+
+> 注意，通常在说 NIO 的读操作的时候，我们说的是从 Channel 中读数据到 Buffer 中，对应的是对 Buffer 的写入操作，初学者需要理清楚这个。
+
+# 5. 从 Buffer 读取数据
+
+每个 Buffer 实现类，都提供了 `#get(...)` 方法，从 Buffer 读取数据。以 ByteBuffer 举例子，代码如下：
+
+```
+// 读取 byte
+public abstract byte get();
+public abstract byte get(int index);
+// 读取 byte 数组
+public ByteBuffer get(byte[] dst, int offset, int length) {...}
+public ByteBuffer get(byte[] dst) {...}
+// ... 省略，还有其他 get 方法
+```
+
+对于 Buffer 来说，还有一个非常重要的操作就是，我们要讲来向 Channel 的写入 Buffer 中的数据。在系统层面上，这个操作我们称为**写操作**，因为数据是从内存中写入到外部( 文件或者网络等 )。示例如下：
+
+```
+int num = channel.write(buffer);
+```
+
+- 上述方法会返回向 Channel 中写入 Buffer 的数据大小。对应方法的代码如下：
+
+  ```
+  public interface WritableByteChannel extends Channel {
+  
+      public int write(ByteBuffer src) throws IOException;
+      
+  }
+  ```
+
+# 6. rewind() v.s. flip() v.s. clear()
+
+## 6.1 flip
+
+如果要读取 Buffer 中的数据，需要切换模式，**从写模式切换到读模式**。对应的为 `#flip()` 方法，代码如下：
+
+```
+public final Buffer flip() {
+    limit = position; // 设置读取上限
+    position = 0; // 重置 position
+    mark = -1; // 清空 mark
+    return this;
+}
+```
+
+使用示例，代码如下：
+
+```
+buf.put(magic);    // Prepend header
+in.read(buf);      // Read data into rest of buffer
+buf.flip();        // Flip buffer
+channel.write(buf);    // Write header + data to channel
+```
+
+## 6.2 rewind
+
+`#rewind()` 方法，可以**重置** `position` 的值为 0 。因此，我们可以重新**读取和写入** Buffer 了。
+
+大多数情况下，该方法主要针对于**读模式**，所以可以翻译为“倒带”。也就是说，和我们当年的磁带倒回去是一个意思。代码如下：
+
+```
+public final Buffer rewind() {
+    position = 0; // 重置 position
+    mark = -1; // 清空 mark
+    return this;
+}
+```
+
+- 从代码上，和 `#flip()` 相比，非常类似，除了少了第一行的 `limit = position` 的代码块。
+
+使用示例，代码如下：
+
+```
+channel.write(buf);    // Write remaining data
+buf.rewind();      // Rewind buffer
+buf.get(array);    // Copy data into array
+```
+
+## 6.3 clear
+
+`#clear()` 方法，可以“**重置**” Buffer 的数据。因此，我们可以重新**读取和写入** Buffer 了。
+
+大多数情况下，该方法主要针对于**写模式**。代码如下：
+
+```
+public final Buffer clear() {
+    position = 0; // 重置 position
+    limit = capacity; // 恢复 limit 为 capacity
+    mark = -1; // 清空 mark
+    return this;
+}
+```
+
+- 从源码上，我们可以看出，Buffer 的数据实际并未清理掉，所以使用时需要注意。
+- 读模式下，尽量不要调用 `#clear()` 方法，因为 `limit` 可能会被错误的赋值为 `capacity` 。相比来说，调用 `#rewind()` 更合理，如果有重读的需求。
+
+使用示例，代码如下：
+
+```
+buf.clear();     // Prepare buffer for reading
+in.read(buf);    // Read data
+```
+
+# 7. mark() 搭配 reset()
+
+## 7.1 mark
+
+`#mark()` 方法，保存当前的 `position` 到 `mark` 中。代码如下：
+
+```
+public final Buffer mark() {
+    mark = position;
+    return this;
+}
+```
+
+## 7.2 reset
+
+`#reset()` 方法，恢复当前的 `postion` 为 `mark` 。代码如下：
+
+```
+public final Buffer reset() {
+    int m = mark;
+    if (m < 0)
+        throw new InvalidMarkException();
+    position = m;
+    return this;
+}
+```
+
+# 8. 其它方法
+
+Buffer 中还有其它方法，比较简单，所以胖友自己研究噢。代码如下：
+
+```
+// ========== capacity ==========
+public final int capacity() {
+    return capacity;
+}
+
+// ========== position ==========
+public final int position() {
+    return position;
+}
+
+public final Buffer position(int newPosition) {
+    if ((newPosition > limit) || (newPosition < 0))
+        throw new IllegalArgumentException();
+    position = newPosition;
+    if (mark > position) mark = -1;
+    return this;
+}
+
+// ========== limit ==========
+public final int limit() {
+    return limit;
+}
+    
+public final Buffer limit(int newLimit) {
+    if ((newLimit > capacity) || (newLimit < 0))
+        throw new IllegalArgumentException();
+    limit = newLimit;
+    if (position > limit) position = limit;
+    if (mark > limit) mark = -1;
+    return this;
+}
+
+// ========== mark ==========
+final int markValue() {                             // package-private
+    return mark;
+}
+
+final void discardMark() {                          // package-private
+    mark = -1;
+}
+
+// ========== 数组相关 ==========
+public final int remaining() {
+    return limit - position;
+}
+
+public final boolean hasRemaining() {
+    return position < limit;
+}
+
+public abstract boolean hasArray();
+
+public abstract Object array();
+
+public abstract int arrayOffset();
+
+public abstract boolean isDirect();
+
+// ========== 下一个读 / 写 position ==========
+final int nextGetIndex() {                          // package-private
+    if (position >= limit)
+        throw new BufferUnderflowException();
+    return position++;
+}
+
+final int nextGetIndex(int nb) {                    // package-private
+    if (limit - position < nb)
+        throw new BufferUnderflowException();
+    int p = position;
+    position += nb;
+    return p;
+}
+
+final int nextPutIndex() {                          // package-private
+    if (position >= limit)
+        throw new BufferOverflowException();
+    return position++;
+}
+
+final int nextPutIndex(int nb) {                    // package-private
+    if (limit - position < nb)
+        throw new BufferOverflowException();
+    int p = position;
+    position += nb;
+    return p;
+}
+
+final int checkIndex(int i) {                       // package-private
+    if ((i < 0) || (i >= limit))
+        throw new IndexOutOfBoundsException();
+    return i;
+}
+
+final int checkIndex(int i, int nb) {               // package-private
+    if ((i < 0) || (nb > limit - i))
+        throw new IndexOutOfBoundsException();
+    return i;
+}
+
+// ========== 其它方法 ==========
+final void truncate() {                             // package-private
+    mark = -1;
+    position = 0;
+    limit = 0;
+    capacity = 0;
+}
+
+static void checkBounds(int off, int len, int size) { // package-private
+    if ((off | len | (off + len) | (size - (off + len))) < 0)
+        throw new IndexOutOfBoundsException();
+}
+```
+
+# 666. 彩蛋
+
+参考文章如下：
+
+- [《Java NIO：Buffer、Channel 和 Selector》](http://www.importnew.com/28007.html)
+- [《Java NIO系列教程（三） Buffer》](http://ifeve.com/buffers/)
+- [《Java NIO 的前生今世 之三 NIO Buffer 详解》](https://segmentfault.com/a/1190000006824155)
+- [《深入浅出NIO之Channel、Buffer》](https://www.jianshu.com/p/052035037297)
+- [《NIO学习笔记——缓冲区（Buffer）详解》](https://blog.csdn.net/fuyuwei2015/article/details/73521681)
\ No newline at end of file
diff --git a/netty/07-Netty 源码分析-NIO 基础（四）之 Selector.assets/01.png b/netty/07-Netty 源码分析-NIO 基础（四）之 Selector.assets/01.png
new file mode 100644
index 0000000..0a55a5d
Binary files /dev/null and b/netty/07-Netty 源码分析-NIO 基础（四）之 Selector.assets/01.png differ
diff --git a/netty/07-Netty 源码分析-NIO 基础（四）之 Selector.assets/02.png b/netty/07-Netty 源码分析-NIO 基础（四）之 Selector.assets/02.png
new file mode 100644
index 0000000..dafb86a
Binary files /dev/null and b/netty/07-Netty 源码分析-NIO 基础（四）之 Selector.assets/02.png differ
diff --git a/netty/07-Netty 源码分析-NIO 基础（四）之 Selector.md b/netty/07-Netty 源码分析-NIO 基础（四）之 Selector.md
new file mode 100644
index 0000000..0671803
--- /dev/null
+++ b/netty/07-Netty 源码分析-NIO 基础（四）之 Selector.md	
@@ -0,0 +1,287 @@
+# 精尽 Netty 源码分析 —— NIO 基础（四）之 Selector
+
+# 1. 概述
+
+Selector ， 一般称为**选择器**。它是 Java NIO 核心组件中的一个，用于轮询一个或多个 NIO Channel 的状态是否处于可读、可写。如此，一个线程就可以管理多个 Channel ，也就说可以管理多个网络连接。也因此，Selector 也被称为**多路复用器**。
+
+那么 Selector 是如何轮询的呢？
+
+- 首先，需要将 Channel 注册到 Selector 中，这样 Selector 才知道哪些 Channel 是它需要管理的。
+- 之后，Selector 会不断地轮询注册在其上的 Channel 。如果某个 Channel 上面发生了读或者写事件，这个 Channel 就处于就绪状态，会被 Selector 轮询出来，然后通过 SelectionKey 可以获取就绪 Channel 的集合，进行后续的 I/O 操作。
+
+下图是一个 Selector 管理三个 Channel 的示例：
+
+[![Selector <=> Channel](07-Netty 源码分析-NIO 基础（四）之 Selector.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_02_15/01.png)Selector <=> Channel
+
+# 2. 优缺点
+
+① **优点**
+
+使用一个线程**能够**处理多个 Channel 的优点是，只需要更少的线程来处理 Channel 。事实上，可以使用一个线程处理所有的 Channel 。对于操作系统来说，线程之间上下文切换的开销很大，而且每个线程都要占用系统的一些资源( 例如 CPU、内存 )。因此，使用的线程越少越好。
+
+② **缺点**
+
+因为在一个线程中使用了多个 Channel ，因此会造成每个 Channel 处理效率的降低。
+
+当然，Netty 在设计实现上，通过 n 个线程处理多个 Channel ，从而很好的解决了这样的缺点。其中，n 的指的是有限的线程数，默认情况下为 CPU * 2 。
+
+# 3. Selector 类图
+
+Selector 在 `java.nio` 包中，被定义成**抽象类**，整体实现类图如下：
+
+[![Selector 类图](07-Netty 源码分析-NIO 基础（四）之 Selector.assets/02.png)](http://static.iocoder.cn/images/Netty/2018_02_15/02.png)Selector 类图
+
+- Selector 的实现不是本文的重点，感兴趣的胖友可以看看占小狼的 [《深入浅出NIO之Selector实现原理》](https://www.jianshu.com/p/0d497fe5484a) 。
+
+# 3. 创建 Selector
+
+通过 `#open()` 方法，我们可以创建一个 Selector 对象。代码如下：
+
+```
+Selector selector = Selector.open();
+```
+
+# 4. 注册 Chanel 到 Selector 中
+
+为了让 Selector 能够管理 Channel ，我们需要将 Channel 注册到 Selector 中。代码如下：
+
+```
+channel.configureBlocking(false); // <1>
+SelectionKey key = channel.register(selector, SelectionKey.OP_READ);
+```
+
+- **注意**，如果一个 Channel 要注册到 Selector 中，那么该 Channel 必须是**非阻塞**，所以 `<1>` 处的 `channel.configureBlocking(false);` 代码块。也因此，FileChannel 是不能够注册到 Channel 中的，因为它是**阻塞**的。
+
+- 在 `#register(Selector selector, int interestSet)` 方法的**第二个参数**，表示一个“interest 集合”，意思是通过 Selector 监听 Channel 时，对**哪些**( 可以是多个 )事件感兴趣。可以监听四种不同类型的事件：
+
+  - Connect ：连接完成事件( TCP 连接 )，仅适用于客户端，对应 `SelectionKey.OP_CONNECT` 。
+  - Accept ：接受新连接事件，仅适用于服务端，对应 `SelectionKey.OP_ACCEPT` 。
+  - Read ：读事件，适用于两端，对应 `SelectionKey.OP_READ` ，表示 Buffer 可读。
+  - Write ：写时间，适用于两端，对应 `SelectionKey.OP_WRITE` ，表示 Buffer 可写。
+
+  Channel 触发了一个事件，意思是该事件已经就绪：
+
+- 一个 Client Channel Channel 成功连接到另一个服务器，称为“连接就绪”。
+
+- 一个 Server Socket Channel 准备好接收新进入的连接，称为“接收就绪”。
+
+- 一个有数据可读的 Channel ，可以说是“读就绪”。
+
+- 一个等待写数据的 Channel ，可以说是“写就绪”。
+
+------
+
+因为 Selector 可以对 Channel 的**多个**事件感兴趣，所以在我们想要注册 Channel 的多个事件到 Selector 中时，可以使用**或运算** `|` 来组合多个事件。示例代码如下：
+
+```
+int interestSet = SelectionKey.OP_READ | SelectionKey.OP_WRITE;
+```
+
+------
+
+实际使用时，我们会有**改变** Selector 对 Channel 感兴趣的事件集合，可以通过再次调用 `#register(Selector selector, int interestSet)` 方法来进行变更。示例代码如下：
+
+```
+channel.register(selector, SelectionKey.OP_READ);
+channel.register(selector, SelectionKey.OP_READ | SelectionKey.OP_WRITE);
+```
+
+- 初始时，Selector 仅对 Channel 的 `SelectionKey.OP_READ` 事件感兴趣。
+- 修改后，Selector 仅对 Channel 的 `SelectionKey.OP_READ` 和 `SelectionKey.OP_WRITE)` 事件**都**感兴趣。
+
+# 5. SelectionKey 类
+
+上一小节, 当我们调用 Channel 的 `#register(...)` 方法，向 Selector 注册一个 Channel 后，会返回一个 SelectionKey 对象。那么 SelectionKey 是什么呢？SelectionKey 在 `java.nio.channels` 包下，被定义成一个**抽象类**，表示一个 Channel 和一个 Selector 的注册关系，包含如下内容：
+
+- interest set ：感兴趣的事件集合。
+- ready set ：就绪的事件集合。
+- Channel
+- Selector
+- attachment ：*可选的*附加对象。
+
+## 5.1 interest set
+
+通过调用 `#interestOps()` 方法，返回感兴趣的事件集合。示例代码如下：
+
+```
+int interestSet = selectionKey.interestOps();
+
+// 判断对哪些事件感兴趣
+boolean isInterestedInAccept  = interestSet & SelectionKey.OP_ACCEPT != 0;
+boolean isInterestedInConnect = interestSet & SelectionKey.OP_CONNECT != 0;
+boolean isInterestedInRead    = interestSet & SelectionKey.OP_READ != 0;
+boolean isInterestedInWrite   = interestSet & SelectionKey.OP_WRITE != 0;
+```
+
+- 其中每个事件 Key 在 SelectionKey 中枚举，通过位( bit ) 表示。代码如下：
+
+  ```
+  //  SelectionKey.java
+  
+  public static final int OP_READ = 1 << 0;
+  public static final int OP_WRITE = 1 << 2;
+  public static final int OP_CONNECT = 1 << 3;
+  public static final int OP_ACCEPT = 1 << 4;
+  ```
+
+  - 所以，在上述示例的后半段的代码，可以通过与运算 `&` 来判断是否对指定事件感兴趣。
+
+## 5.2 ready set
+
+通过调用 `#readyOps()` 方法，返回就绪的事件集合。示例代码如下：
+
+```
+int readySet = selectionKey.readyOps();
+
+// 判断哪些事件已就绪
+selectionKey.isAcceptable();
+selectionKey.isConnectable();
+selectionKey.isReadable();
+selectionKey.isWritable();
+```
+
+- 相比 interest set 来说，ready set 已经内置了判断事件的方法。代码如下：
+
+  ```
+  // SelectionKey.java
+  public final boolean isReadable() {
+      return (readyOps() & OP_READ) != 0;
+  }
+  public final boolean isWritable() {
+      return (readyOps() & OP_WRITE) != 0;
+  }
+  public final boolean isConnectable() {
+      return (readyOps() & OP_CONNECT) != 0;
+  }
+  public final boolean isAcceptable() {
+      return (readyOps() & OP_ACCEPT) != 0;
+  }
+  ```
+
+## 5.3 attachment
+
+通过调用 `#attach(Object ob)` 方法，可以向 SelectionKey 添加附加对象；通过调用 `#attachment()` 方法，可以获得 SelectionKey 获得附加对象。示例代码如下：
+
+```
+selectionKey.attach(theObject);
+Object attachedObj = selectionKey.attachment();
+```
+
+又获得在注册时，直接添加附加对象。示例代码如下：
+
+```
+SelectionKey key = channel.register(selector, SelectionKey.OP_READ, theObject);
+```
+
+# 6. 通过 Selector 选择 Channel
+
+在 Selector 中，提供三种类型的选择( select )方法，返回当前有感兴趣事件准备就绪的 Channel **数量**：
+
+```
+// Selector.java
+
+// 阻塞到至少有一个 Channel 在你注册的事件上就绪了。
+public abstract int select() throws IOException;
+
+// 在 `#select()` 方法的基础上，增加超时机制。
+public abstract int select(long timeout) throws IOException;
+
+// 和 `#select()` 方法不同，立即返回数量，而不阻塞。
+public abstract int selectNow() throws IOException;
+```
+
+- 有一点**非常需要注意**：select 方法返回的 `int` 值，表示有多少 Channel 已经就绪。亦即，**自上次调用 select 方法后有多少 Channel 变成就绪状态**。如果调用 select 方法，因为有一个 Channel 变成就绪状态则返回了 1 ；若再次调用 select 方法，如果另一个 Channel 就绪了，它会再次返回1。如果对第一个就绪的 Channel 没有做任何操作，现在就有两个就绪的 Channel ，**但在每次 select 方法调用之间，只有一个 Channel 就绪了，所以才返回 1**。
+
+# 7. 获取可操作的 Channel
+
+一旦调用了 select 方法，并且返回值表明有一个或更多个 Channel 就绪了，然后可以通过调用Selector 的 `#selectedKeys()` 方法，访问“已选择键集( selected key set )”中的**就绪** Channel 。示例代码所示：
+
+```
+Set selectedKeys = selector.selectedKeys();
+```
+
+- 注意，当有**新增就绪**的 Channel ，需要先调用 select 方法，才会添加到“已选择键集( selected key set )”中。否则，我们直接调用 `#selectedKeys()` 方法，是无法获得它们对应的 SelectionKey 们。
+
+# 8. 唤醒 Selector 选择
+
+某个线程调用 `#select()` 方法后，发生阻塞了，即使没有通道已经就绪，也有办法让其从 `#select()` 方法返回。
+
+- 只要让其它线程在第一个线程调用 `select()` 方法的那个 Selector 对象上，调用该 Selector 的 `#wakeup()` 方法，进行唤醒该 Selector 即可。
+- 那么，阻塞在 `#select()`方法上的线程，会立马返回。
+
+> Selector 的 `#select(long timeout)` 方法，若未超时的情况下，也可以满足上述方式。
+
+注意，如果有其它线程调用了 `#wakeup()` 方法，但当前没有线程阻塞在 `#select()` 方法上，下个调用 `#select()` 方法的线程会立即被唤醒。😈 有点神奇。
+
+# 9. 关闭 Selector
+
+当我们不再使用 Selector 时，可以调用 Selector 的 `#close()` 方法，将它进行关闭。
+
+- Selector 相关的所有 SelectionKey 都**会失效**。
+- Selector 相关的所有 Channel 并**不会关闭**。
+
+注意，此时若有线程阻塞在 `#select()` 方法上，也会被唤醒返回。
+
+# 10. 简单 Selector 示例
+
+如下是一个简单的 Selector 示例，创建一个 Selector ，并将一个 Channel注册到这个 Selector上( Channel 的初始化过程略去 )，然后持续轮询这个 Selector 的四种事件( 接受，连接，读，写 )是否就绪。代码如下：
+
+> 老艿艿：本代码取自 [《Java NIO系列教程（六） Selector》](http://ifeve.com/selectors/) 提供的示例，实际生产环境下并非这样的代码。🙂 最佳的实践，我们将在 Netty 中看到。
+
+```
+// 创建 Selector
+Selector selector = Selector.open();
+// 注册 Channel 到 Selector 中
+channel.configureBlocking(false);
+SelectionKey key = channel.register(selector, SelectionKey.OP_READ);
+while (true) {
+      // 通过 Selector 选择 Channel 
+	int readyChannels = selector.select();
+	if (readyChannels == 0) {
+	   continue;
+	}
+	// 获得可操作的 Channel
+	Set selectedKeys = selector.selectedKeys();
+	// 遍历 SelectionKey 数组
+	Iterator<SelectionKey> keyIterator = selectedKeys.iterator();
+	while (keyIterator.hasNext()) {
+		SelectionKey key = keyIterator.next();
+		if (key.isAcceptable()) {
+			// a connection was accepted by a ServerSocketChannel.
+		} else if (key.isConnectable()) {
+			// a connection was established with a remote server.
+		} else if (key.isReadable()) {
+			// a channel is ready for reading
+		} else if (key.isWritable()) {
+			// a channel is ready for writing
+		}
+		// 移除
+		keyIterator.remove(); // <1>
+	}
+}
+```
+
+- 注意
+
+  , 在每次迭代时, 我们都调用
+
+   
+
+  ```
+  keyIterator.remove()
+  ```
+
+   
+
+  代码块，将这个 key 从迭代器中删除。
+
+  - 因为 `#select()` 方法仅仅是简单地将就绪的 Channel 对应的 SelectionKey 放到 selected keys 集合中。
+  - 因此，如果我们从 selected keys 集合中，获取到一个 key ，但是没有将它删除，那么下一次 `#select` 时, 这个 SelectionKey 还在 selectedKeys 中.
+
+# 666. 彩蛋
+
+参考文章如下：
+
+- [《Java NIO系列教程（六） Selector》](http://ifeve.com/selectors/)
+- [《Java NIO之Selector（选择器）》](https://www.cnblogs.com/snailclimb/p/9086334.html)
+- [《Java NIO 的前生今世 之四 NIO Selector 详解》](https://segmentfault.com/a/1190000006824196)
\ No newline at end of file
diff --git a/netty/08-Netty 源码分析-NIO 基础（五）之示例.md b/netty/08-Netty 源码分析-NIO 基础（五）之示例.md
new file mode 100644
index 0000000..dd70ee4
--- /dev/null
+++ b/netty/08-Netty 源码分析-NIO 基础（五）之示例.md	
@@ -0,0 +1,665 @@
+# 精尽 Netty 源码分析 —— NIO 基础（五）之示例
+
+# 1. 概述
+
+在前面的四篇文章，我们已经对 NIO 的概念已经有了一定的了解。当然，胖友也可能和我一样，已经被一堆概念烦死了。
+
+那么本文，我们撸起袖子，就是干代码，不瞎比比了。
+
+当然，下面更多的是提供一个 NIO 示例。真正生产级的 NIO 代码，建议胖友重新写，或者直接使用 Netty 。
+
+代码仓库在 [example/yunai/nio](https://github.com/YunaiV/netty/tree/f7016330f1483021ef1c38e0923e1c8b7cef0d10/example/src/main/java/io/netty/example/yunai/nio) 目录下。一共 3 个类：
+
+- NioServer ：NIO 服务端。
+- NioClient ：NIO 客户端。
+- CodecUtil ：消息编解码工具类。
+
+# 2. 服务端
+
+```
+  1: public class NioServer {
+  2: 
+  3:     private ServerSocketChannel serverSocketChannel;
+  4:     private Selector selector;
+  5: 
+  6:     public NioServer() throws IOException {
+  7:         // 打开 Server Socket Channel
+  8:         serverSocketChannel = ServerSocketChannel.open();
+  9:         // 配置为非阻塞
+ 10:         serverSocketChannel.configureBlocking(false);
+ 11:         // 绑定 Server port
+ 12:         serverSocketChannel.socket().bind(new InetSocketAddress(8080));
+ 13:         // 创建 Selector
+ 14:         selector = Selector.open();
+ 15:         // 注册 Server Socket Channel 到 Selector
+ 16:         serverSocketChannel.register(selector, SelectionKey.OP_ACCEPT);
+ 17:         System.out.println("Server 启动完成");
+ 18: 
+ 19:         handleKeys();
+ 20:     }
+ 21: 
+ 22:     private void handleKeys() throws IOException {
+ 23:         while (true) {
+ 24:             // 通过 Selector 选择 Channel
+ 25:             int selectNums = selector.select(30 * 1000L);
+ 26:             if (selectNums == 0) {
+ 27:                 continue;
+ 28:             }
+ 29:             System.out.println("选择 Channel 数量：" + selectNums);
+ 30: 
+ 31:             // 遍历可选择的 Channel 的 SelectionKey 集合
+ 32:             Iterator<SelectionKey> iterator = selector.selectedKeys().iterator();
+ 33:             while (iterator.hasNext()) {
+ 34:                 SelectionKey key = iterator.next();
+ 35:                 iterator.remove(); // 移除下面要处理的 SelectionKey
+ 36:                 if (!key.isValid()) { // 忽略无效的 SelectionKey
+ 37:                     continue;
+ 38:                 }
+ 39: 
+ 40:                 handleKey(key);
+ 41:             }
+ 42:         }
+ 43:     }
+ 44: 
+ 45:     private void handleKey(SelectionKey key) throws IOException {
+ 46:         // 接受连接就绪
+ 47:         if (key.isAcceptable()) {
+ 48:             handleAcceptableKey(key);
+ 49:         }
+ 50:         // 读就绪
+ 51:         if (key.isReadable()) {
+ 52:             handleReadableKey(key);
+ 53:         }
+ 54:         // 写就绪
+ 55:         if (key.isWritable()) {
+ 56:             handleWritableKey(key);
+ 57:         }
+ 58:     }
+ 59: 
+ 60:     private void handleAcceptableKey(SelectionKey key) throws IOException {
+ 61:         // 接受 Client Socket Channel
+ 62:         SocketChannel clientSocketChannel = ((ServerSocketChannel) key.channel()).accept();
+ 63:         // 配置为非阻塞
+ 64:         clientSocketChannel.configureBlocking(false);
+ 65:         // log
+ 66:         System.out.println("接受新的 Channel");
+ 67:         // 注册 Client Socket Channel 到 Selector
+ 68:         clientSocketChannel.register(selector, SelectionKey.OP_READ, new ArrayList<String>());
+ 69:     }
+ 70: 
+ 71:     private void handleReadableKey(SelectionKey key) throws IOException {
+ 72:         // Client Socket Channel
+ 73:         SocketChannel clientSocketChannel = (SocketChannel) key.channel();
+ 74:         // 读取数据
+ 75:         ByteBuffer readBuffer = CodecUtil.read(clientSocketChannel);
+ 76:         // 处理连接已经断开的情况
+ 77:         if (readBuffer == null) {
+ 78:             System.out.println("断开 Channel");
+ 79:             clientSocketChannel.register(selector, 0);
+ 80:             return;
+ 81:         }
+ 82:         // 打印数据
+ 83:         if (readBuffer.position() > 0) {
+ 84:             String content = CodecUtil.newString(readBuffer);
+ 85:             System.out.println("读取数据：" + content);
+ 86: 
+ 87:             // 添加到响应队列
+ 88:             List<String> responseQueue = (ArrayList<String>) key.attachment();
+ 89:             responseQueue.add("响应：" + content);
+ 90:             // 注册 Client Socket Channel 到 Selector
+ 91:             clientSocketChannel.register(selector, SelectionKey.OP_WRITE, key.attachment());
+ 92:         }
+ 93:     }
+ 94: 
+ 95:     @SuppressWarnings("Duplicates")
+ 96:     private void handleWritableKey(SelectionKey key) throws ClosedChannelException {
+ 97:         // Client Socket Channel
+ 98:         SocketChannel clientSocketChannel = (SocketChannel) key.channel();
+ 99: 
+100:         // 遍历响应队列
+101:         List<String> responseQueue = (ArrayList<String>) key.attachment();
+102:         for (String content : responseQueue) {
+103:             // 打印数据
+104:             System.out.println("写入数据：" + content);
+105:             // 返回
+106:             CodecUtil.write(clientSocketChannel, content);
+107:         }
+108:         responseQueue.clear();
+109: 
+110:         // 注册 Client Socket Channel 到 Selector
+111:         clientSocketChannel.register(selector, SelectionKey.OP_READ, responseQueue);
+112:     }
+113: 
+114:     public static void main(String[] args) throws IOException {
+115:         NioServer server = new NioServer();
+116:     }
+117: 
+118: }
+```
+
+整块代码我们可以分成 3 部分：
+
+- 构造方法：初始化 NIO 服务端。
+- `#handleKeys()` 方法：基于 Selector 处理 IO 操作。
+- `#main(String[] args)` 方法：创建 NIO 服务端。
+
+下面，我们逐小节来分享。
+
+## 2.1 构造方法
+
+> 对应【第 3 至 20 行】的代码。
+
+- `serverSocketChannel` 属性，服务端的 ServerSocketChannel ，在【第 7 至 12 行】的代码进行初始化，重点是此处启动了服务端，并监听指定端口( 此处为 8080 )。
+- `selector` 属性，选择器，在【第 14 至 16 行】的代码进行初始化，重点是此处将 `serverSocketChannel` 到 `selector` 中，并对 `SelectionKey.OP_ACCEPT` 事件感兴趣。这样子，在客户端连接服务端时，我们就可以处理该 IO 事件。
+- 第 19 行：调用 `#handleKeys()` 方法，基于 Selector 处理 IO 事件。
+
+## 2.2 handleKeys
+
+> 对应【第 22 至 43 行】的代码。
+
+- 第 23 行：死循环。本文的示例，不考虑服务端关闭的逻辑。
+
+- 第 24 至 29 行：调用 `Selector#select(long timeout)` 方法，每 30 秒阻塞等待有就绪的 IO 事件。此处的 30 秒为笔者随意写的，实际也可以改成其他超时时间，或者 `Selector#select()` 方法。当不存在就绪的 IO 事件，直接 `continue` ，继续下一次阻塞等待。
+
+- 第 32 行：调用
+
+   
+
+  ```
+  Selector#selectedKeys()
+  ```
+
+   
+
+  方法，获得有就绪的 IO 事件( 也可以称为“选择的” ) Channel 对应的 SelectionKey 集合。
+
+  - 第 33 行 至 35 行：遍历 `iterator` ，进行逐个 SelectionKey 处理。重点注意下，处理完需要进行移除，具体原因，在 [《精尽 Netty 源码分析 —— NIO 基础（四）之 Selector》「10. 简单 Selector 示例」](http://svip.iocoder.cn/Netty/nio-4-selector/#10-简单-Selector-示例) 有详细解析。
+  - 第 36 至 38 行：在遍历的过程中，可能该 SelectionKey 已经**失效**，直接 `continue` ，不进行处理。
+  - 第 40 行：调用 `#handleKey()` 方法，逐个 SelectionKey 处理。
+
+### 2.2.1 handleKey
+
+> 对应【第 45 至 58 行】的代码。
+
+- 通过调用 SelectionKey 的 `#isAcceptable()`、`#isReadable()`、`#isWritable()` 方法，**分别**判断 Channel 是**接受连接**就绪，还是**读**就绪，或是**写**就绪，并调用相应的 `#handleXXXX(SelectionKey key)` 方法，处理对应的 IO 事件。
+- 因为 SelectionKey 可以**同时**对**一个** Channel 的**多个**事件感兴趣，所以此处的代码都是 `if` 判断，而不是 `if else` 判断。😈 虽然，考虑到让示例更简单，本文的并未编写同时对一个 Channel 的多个事件感兴趣，后续我们会在 Netty 的源码解析中看到。
+- `SelectionKey.OP_CONNECT` 使用在**客户端**中，所以此处不需要做相应的判断和处理。
+
+### 2.2.2 handleAcceptableKey
+
+> 对应【第 60 至 69 行】的代码。
+
+- 第 62 行：调用 `ServerSocketChannel#accept()` 方法，获得连接的客户端的 SocketChannel 。
+
+- 第 64 行：配置客户端的 SocketChannel 为非阻塞，否则无法使用 Selector 。
+
+- 第 66 行：打印日志，方便调试。实际场景下，使用 Logger 而不要使用 `System.out` 进行输出。
+
+- 第 68 行：注册客户端的 SocketChannel 到
+
+   
+
+  ```
+  selector
+  ```
+
+   
+
+  中，并对
+
+   
+
+  ```
+  SelectionKey.OP_READ
+  ```
+
+   
+
+  事件感兴趣。这样子，在客户端发送消息( 数据 )到服务端时，我们就可以处理该 IO 事件。
+
+  - 为什么不对 `SelectionKey.OP_WRITE` 事件感兴趣呢？因为这个时候，服务端一般不会主动向客户端发送消息，所以不需要对 `SelectionKey.OP_WRITE` 事件感兴趣。
+  - 细心的胖友会发现，`Channel#register(Selector selector, int ops, Object attachment)` 方法的第 3 个参数，我们注册了 SelectionKey 的 `attachment` 属性为 `new ArrayList<String>()` ，这又是为什么呢？结合下面的 `#handleReadableKey(Selection key)` 方法，我们一起解析。
+
+### 2.2.3 handleReadableKey
+
+> 对应【第 71 至 93 行】的代码。
+
+- 第 73 行：调用 `SelectionKey#channel()` 方法，获得该 SelectionKey 对应的 SocketChannel ，即客户端的 SocketChannel 。
+
+- 第 75 行：调用 `CodecUtil#read(SocketChannel channel)` 方法，读取数据。具体代码如下：
+
+  ```
+  // CodecUtil.java
+  
+  public static ByteBuffer read(SocketChannel channel) {
+      // 注意，不考虑拆包的处理
+      ByteBuffer buffer = ByteBuffer.allocate(1024);
+      try {
+          int count = channel.read(buffer);
+          if (count == -1) {
+              return null;
+          }
+      } catch (IOException e) {
+          throw new RuntimeException(e);
+      }
+      return buffer;
+  }
+  ```
+
+  - 考虑到示例的简单性，数据的读取，就不考虑拆包的处理。不理解的胖友，可以自己 Google 下。
+  - 调用 `SocketChannel#read(ByteBuffer)` 方法，读取 Channel 的缓冲区的数据到 ByteBuffer 中。若返回的结果( `count` ) 为 -1 ，意味着客户端连接已经断开，我们直接返回 `null` 。为什么是返回 `null` 呢？下面继续见分晓。
+
+- 第 76 至 81 行：若读取数据返回的结果为 `null` 时，意味着客户端的连接已经断开，因此取消注册 `selector` 对该客户端的 SocketChannel 的感兴趣的 IO 事件。通过调用注册方法，并且第 2 个参数 `ops` 为 0 ，可以达到取消注册的效果。😈 感兴趣的胖友，可以将这行代码进行注释，测试下效果就很容易明白了。
+
+- 第 83 行：通过调用 `ByteBuffer#position()` 大于 0 ，来判断**实际**读取到数据。
+
+  - 第 84 至 85 行：调用 `CodecUtil#newString(ByteBuffer)` 方法，格式化为字符串，并进行打印。代码如下：
+
+    ```
+    // CodecUtil.java
+    
+    public static String newString(ByteBuffer buffer) {
+        buffer.flip();
+        byte[] bytes = new byte[buffer.remaining()];
+        System.arraycopy(buffer.array(), buffer.position(), bytes, 0, buffer.remaining());
+        try {
+            return new String(bytes, "UTF-8");
+        } catch (UnsupportedEncodingException e) {
+            throw new RuntimeException(e);
+        }
+    }
+    ```
+
+    - 注意，需要调用 `ByteBuffer#flip()` 方法，将 ByteBuffer 从**写**模式切换到**读**模式。
+
+  - 第 86 行：一般在此处，我们可以进行一些业务逻辑的处理，并返回处理的相应结果。例如，我们熟悉的 Request / Response 的处理。当然，考虑到性能，我们甚至可以将逻辑的处理，丢到逻辑线程池。
+
+    - 😈 如果不理解，木有关系，在 [《精尽 Dubbo 源码分析 —— NIO 服务器（二）之 Transport 层》「8. Dispacher」](http://svip.iocoder.cn/Dubbo/remoting-api-transport/) 中，有详细解析。
+    - 🙂 考虑到示例的简洁性，所以在【第 88 至 89 行】的代码中，我们直接返回（`"响应："` + 请求内容）给客户端。
+
+  - 第 88 行：通过调用
+
+     
+
+    ```
+    SelectionKey#attachment()
+    ```
+
+     
+
+    方法，获得我们
+
+    附加
+
+    在 SelectionKey 的响应队列(
+
+     
+
+    ```
+    responseQueue
+    ```
+
+     
+
+    )。可能有胖友会问啦，为什么不调用
+
+     
+
+    ```
+    SocketChannel#write(ByteBuf)
+    ```
+
+     
+
+    方法，直接写数据给客户端呢？虽然大多数情况下，SocketChannel 都是
+
+    可写
+
+    的，但是如果写入比较频繁，超过 SocketChannel 的缓存区大小，就会导致数据“
+
+    丢失
+
+    ”，并未写给客户端。
+
+    - 所以，此处笔者在示例中，处理的方式为添加响应数据到 `responseQueue` 中，并在【第 91 行】的代码中，注册客户端的 SocketChannel 到 `selector` 中，并对 `SelectionKey.OP_WRITE` 事件感兴趣。这样子，在 SocketChannel **写就绪**时，在 `#handleWritableKey(SelectionKey key)` 方法中，统一处理写数据给客户端。
+    - 当然，还是因为是示例，所以这样的实现方式不是最优。在 Netty 中，具体的实现方式是，先尝试调用 `SocketChannel#write(ByteBuf)` 方法，写数据给客户端。若写入失败( 方法返回结果为 0 )时，再进行类似笔者的上述实现方式。牛逼！Netty ！
+    - 如果不太理解分享的原因，可以再阅读如下两篇文章：
+      - [《深夜对话：NIO 中 SelectionKey.OP_WRITE 你了解多少》](https://mp.weixin.qq.com/s/V4tEH1j64FHFmB8bReNI7g)
+      - [《Java.nio 中 socketChannle.write() 返回 0 的简易解决方案》](https://blog.csdn.net/a34140974/article/details/48464845)
+
+  - 第 91 行：有一点需要注意，`Channel#register(Selector selector, int ops, Object attachment)` 方法的第 3 个参数，需要继续传入响应队列( `responseQueue` )，因为每次注册生成**新**的 SelectionKey 。若不传入，下面的 `#handleWritableKey(SelectionKey key)` 方法，会获得不到响应队列( `responseQueue` )。
+
+### 2.2.4 handleWritableKey
+
+> 对应【第 96 至 112 行】的代码。
+
+- 第 98 行：调用 `SelectionKey#channel()` 方法，获得该 SelectionKey 对应的 SocketChannel ，即客户端的 SocketChannel 。
+
+- 第 101 行：通过调用 `SelectionKey#attachment()` 方法，获得我们**附加**在 SelectionKey 的响应队列( `responseQueue` )。
+
+  - 第 102 行：遍历响应队列。
+
+  - 第 106 行：调用 `CodeUtil#write(SocketChannel, content)` 方法，写入响应数据给客户端。代码如下：
+
+    ```
+     // CodecUtil.java
+     
+    public static void write(SocketChannel channel, String content) {
+        // 写入 Buffer
+        ByteBuffer buffer = ByteBuffer.allocate(1024);
+        try {
+            buffer.put(content.getBytes("UTF-8"));
+        } catch (UnsupportedEncodingException e) {
+            throw new RuntimeException(e);
+        }
+        // 写入 Channel
+        buffer.flip();
+        try {
+            // 注意，不考虑写入超过 Channel 缓存区上限。
+            channel.write(buffer);
+        } catch (IOException e) {
+            throw new RuntimeException(e);
+        }
+    }
+    ```
+
+    - 代码比较简单，**还是要注意**，需要调用 `ByteBuffer#flip()` 方法，将 ByteBuffer 从**写**模式切换到**读**模式。
+
+- 第 111 行：**注意**，再结束写入后，需要**重新**注册客户端的 SocketChannel 到 `selector` 中，并对 `SelectionKey.OP_READ` 事件感兴趣。为什么呢？其实还是我们在上文中提到的，大多数情况下，SocketChannel **都是写就绪的**，如果不取消掉注册掉对 `SelectionKey.OP_READ` 事件感兴趣，就会导致反复触发无用的写事件处理。😈 感兴趣的胖友，可以将这行代码进行注释，测试下效果就很容易明白了。
+
+## 2.3 main
+
+> 对应【第 114 至 116 行】
+
+- 比较简单，就是创建一个 NioServer 对象。
+
+撸到此处，我们可以直接通过 `telnet 127.0.0.1 8080` 的方式，连接服务端，进行读写数据的测试。
+
+# 3. 客户端
+
+客户端的实现代码，绝大数和服务端相同，所以我们分析的相对会简略一些。不然，自己都嫌弃自己太啰嗦了。
+
+```
+  1: public class NioClient {
+  2: 
+  3:     private SocketChannel clientSocketChannel;
+  4:     private Selector selector;
+  5:     private final List<String> responseQueue = new ArrayList<String>();
+  6: 
+  7:     private CountDownLatch connected = new CountDownLatch(1);
+  8: 
+  9:     public NioClient() throws IOException, InterruptedException {
+ 10:         // 打开 Client Socket Channel
+ 11:         clientSocketChannel = SocketChannel.open();
+ 12:         // 配置为非阻塞
+ 13:         clientSocketChannel.configureBlocking(false);
+ 14:         // 创建 Selector
+ 15:         selector = Selector.open();
+ 16:         // 注册 Server Socket Channel 到 Selector
+ 17:         clientSocketChannel.register(selector, SelectionKey.OP_CONNECT);
+ 18:         // 连接服务器
+ 19:         clientSocketChannel.connect(new InetSocketAddress(8080));
+ 20: 
+ 21:         new Thread(new Runnable() {
+ 22:             @Override
+ 23:             public void run() {
+ 24:                 try {
+ 25:                     handleKeys();
+ 26:                 } catch (IOException e) {
+ 27:                     e.printStackTrace();
+ 28:                 }
+ 29:             }
+ 30:         }).start();
+ 31: 
+ 32:         if (connected.getCount() != 0) {
+ 33:             connected.await();
+ 34:         }
+ 35:         System.out.println("Client 启动完成");
+ 36:     }
+ 37: 
+ 38:     @SuppressWarnings("Duplicates")
+ 39:     private void handleKeys() throws IOException {
+ 40:         while (true) {
+ 41:             // 通过 Selector 选择 Channel
+ 42:             int selectNums = selector.select(30 * 1000L);
+ 43:             if (selectNums == 0) {
+ 44:                 continue;
+ 45:             }
+ 46: 
+ 47:             // 遍历可选择的 Channel 的 SelectionKey 集合
+ 48:             Iterator<SelectionKey> iterator = selector.selectedKeys().iterator();
+ 49:             while (iterator.hasNext()) {
+ 50:                 SelectionKey key = iterator.next();
+ 51:                 iterator.remove(); // 移除下面要处理的 SelectionKey
+ 52:                 if (!key.isValid()) { // 忽略无效的 SelectionKey
+ 53:                     continue;
+ 54:                 }
+ 55: 
+ 56:                 handleKey(key);
+ 57:             }
+ 58:         }
+ 59:     }
+ 60: 
+ 61:     private synchronized void handleKey(SelectionKey key) throws IOException {
+ 62:         // 接受连接就绪
+ 63:         if (key.isConnectable()) {
+ 64:             handleConnectableKey(key);
+ 65:         }
+ 66:         // 读就绪
+ 67:         if (key.isReadable()) {
+ 68:             handleReadableKey(key);
+ 69:         }
+ 70:         // 写就绪
+ 71:         if (key.isWritable()) {
+ 72:             handleWritableKey(key);
+ 73:         }
+ 74:     }
+ 75: 
+ 76:     private void handleConnectableKey(SelectionKey key) throws IOException {
+ 77:         // 完成连接
+ 78:         if (!clientSocketChannel.isConnectionPending()) {
+ 79:             return;
+ 80:         }
+ 81:         clientSocketChannel.finishConnect();
+ 82:         // log
+ 83:         System.out.println("接受新的 Channel");
+ 84:         // 注册 Client Socket Channel 到 Selector
+ 85:         clientSocketChannel.register(selector, SelectionKey.OP_READ, responseQueue);
+ 86:         // 标记为已连接
+ 87:         connected.countDown();
+ 88:     }
+ 89: 
+ 90:     @SuppressWarnings("Duplicates")
+ 91:     private void handleReadableKey(SelectionKey key) throws ClosedChannelException {
+ 92:         // Client Socket Channel
+ 93:         SocketChannel clientSocketChannel = (SocketChannel) key.channel();
+ 94:         // 读取数据
+ 95:         ByteBuffer readBuffer = CodecUtil.read(clientSocketChannel);
+ 96:         // 打印数据
+ 97:         if (readBuffer.position() > 0) { // 写入模式下，
+ 98:             String content = CodecUtil.newString(readBuffer);
+ 99:             System.out.println("读取数据：" + content);
+100:         }
+101:     }
+102: 
+103:     @SuppressWarnings("Duplicates")
+104:     private void handleWritableKey(SelectionKey key) throws ClosedChannelException {
+105:         // Client Socket Channel
+106:         SocketChannel clientSocketChannel = (SocketChannel) key.channel();
+107: 
+108:         // 遍历响应队列
+109:         List<String> responseQueue = (ArrayList<String>) key.attachment();
+110:         for (String content : responseQueue) {
+111:             // 打印数据
+112:             System.out.println("写入数据：" + content);
+113:             // 返回
+114:             CodecUtil.write(clientSocketChannel, content);
+115:         }
+116:         responseQueue.clear();
+117: 
+118:         // 注册 Client Socket Channel 到 Selector
+119:         clientSocketChannel.register(selector, SelectionKey.OP_READ, responseQueue);
+120:     }
+121: 
+122:     public synchronized void send(String content) throws ClosedChannelException {
+123:         // 添加到响应队列
+124:         responseQueue.add(content);
+125:         // 打印数据
+126:         System.out.println("写入数据：" + content);
+127:         // 注册 Client Socket Channel 到 Selector
+128:         clientSocketChannel.register(selector, SelectionKey.OP_WRITE, responseQueue);
+129:         selector.wakeup();
+130:     }
+131: 
+132:     public static void main(String[] args) throws IOException, InterruptedException {
+133:         NioClient client = new NioClient();
+134:         for (int i = 0; i < 30; i++) {
+135:             client.send("nihao: " + i);
+136:             Thread.sleep(1000L);
+137:         }
+138:     }
+139: 
+140: }
+```
+
+整块代码我们可以分成 3 部分：
+
+- 构造方法：初始化 NIO 客户端。
+- `#handleKeys()` 方法：基于 Selector 处理 IO 操作。
+- `#main(String[] args)` 方法：创建 NIO 客户端，并向服务器发送请求数据。
+
+下面，我们逐小节来分享。
+
+## 3.1 构造方法
+
+> 对应【第 3 至 36 行】的代码。
+
+- `clientSocketChannel` 属性，客户端的 SocketChannel ，在【第 9 至 13 行】和【第 19 行】的代码进行初始化，重点是此处连接了指定服务端。
+
+- `selector` 属性，选择器，在【第 14 至 17 行】的代码进行初始化，重点是此处将 `clientSocketChannel` 到 `selector` 中，并对 `SelectionKey.OP_CONNECT` 事件感兴趣。这样子，在客户端连接服务端**成功**时，我们就可以处理该 IO 事件。
+
+- `responseQueue` 属性，直接声明为 NioClient 的成员变量，是为了方便 `#send(String content)` 方法的实现。
+
+- 第 21 至 30 行：调用 `#handleKeys()` 方法，基于 Selector 处理 IO 事件。比较特殊的是，我们是启动了一个**线程**进行处理。因为在后续的 `#main()` 方法中，我们需要调用发送请求数据的方法，不能直接在**主线程**，轮询处理 IO 事件。😈 机智的胖友，可能已经发现，NioServer 严格来说，也是应该这样处理。
+
+- 第 32 至 34 行：通过 CountDownLatch 来实现阻塞等待客户端成功连接上服务端。具体的
+
+   
+
+  ```
+  CountDownLatch#countDown()
+  ```
+
+   
+
+  方法，在
+
+   
+
+  ```
+  #handleConnectableKey(SelectionKey key)
+  ```
+
+   
+
+  方法中调用。当然，除了可以使用 CountDownLatch 来实现阻塞等待，还可以通过如下方式:
+
+  - Object 的 wait 和 notify 的方式。
+  - Lock 的 await 和 notify 的方式。
+  - Queue 的阻塞等待方式。
+  - 😈 开心就好，皮一下很开心。
+
+## 3.2 handleKeys
+
+> 对应【第 38 至 59 行】的代码。
+
+**完全**和 NioServer 中的该方法一模一样，省略。
+
+### 3.2.1 handleKey
+
+> 对应【第 61 至 74 行】的代码。
+
+**大体**逻辑和 NioServer 中的该方法一模一样，差别将对 `SelectionKey.OP_WRITE` 事件的处理改成对 `SelectionKey.OP_CONNECT` 事件的处理。
+
+### 3.3.2 handleConnectableKey
+
+> 对应【第 76 至 88 行】的代码。
+
+- 第 77 至 81 行：判断客户端的 SocketChannel 上是否**正在进行连接**的操作，若是，则完成连接。
+- 第 83 行：打印日志。
+- 第 85 行：注册客户端的 SocketChannel 到 `selector` 中，并对 `SelectionKey.OP_READ` 事件感兴趣。这样子，在客户端接收到到服务端的消息( 数据 )时，我们就可以处理该 IO 事件。
+- 第 87 行：调用 `CountDownLatch#countDown()` 方法，结束 NioClient 构造方法中的【第 32 至 34 行】的阻塞等待连接完成。
+
+### 3.3.3 handleReadableKey
+
+> 对应【第 91 至 101 行】的代码。
+
+**大体**逻辑和 NioServer 中的该方法一模一样，**去掉响应请求的相关逻辑**。😈 如果不去掉，就是客户端和服务端互发消息的“死循环”了。
+
+### 3.3.4 handleWritableKey
+
+> 对应【第 103 至 120 行】的代码。
+
+**完全**和 NioServer 中的该方法一模一样。
+
+## 3.3 send
+
+> 对应【第 122 至 130 行】的代码。
+
+客户端发送请求消息给服务端。
+
+- 第 124 行：添加到响应队列( `responseQueue` ) 中。
+
+- 第 126 行：打印日志。
+
+- 第 128 行：注册客户端的 SocketChannel 到 `selector` 中，并对 `SelectionKey.OP_WRITE` 事件感兴趣。具体的原因，和 NioServer 的 `#handleReadableKey(SelectionKey key)` 方法的【第 88 行】一样。
+
+- 第 129 行：调用
+
+   
+
+  ```
+  Selector#wakeup()
+  ```
+
+   
+
+  方法，唤醒
+
+   
+
+  ```
+  #handleKeys()
+  ```
+
+   
+
+  方法中，
+
+  ```
+  Selector#select(long timeout)
+  ```
+
+   
+
+  方法的阻塞等待。
+
+  - 因为，在 `Selector#select(long timeout)` 方法的实现中，是以调用**当时**，对 SocketChannel 的感兴趣的事件 。
+  - 所以，在【第 128 行】的代码中，即使修改了对 SocketChannel 的感兴趣的事件，也不会结束 `Selector#select(long timeout)` 方法的阻塞等待。因此，需要进行唤醒操作。
+  - 😈 感兴趣的胖友，可以将这行代码进行注释，测试下效果就很容易明白了。
+
+## 3.4 main
+
+> 对应【第 132 至 137 行】的代码。
+
+- 第 133 行：创建一个 NioClient 对象。
+- 第 134 至 137 行：每秒发送一次请求。考虑到代码没有处理拆包的逻辑，所以增加了间隔 1 秒的 sleep 。
+
+# 666. 彩蛋
+
+呼呼，凌晨 1 点。困累，写的有点着急了。简单 Review 了一遍，如果有不正确的，烦请斧正！谢谢！
+
+推荐阅读文章如下：
+
+- [《【NIO系列】—— Reactor 模式》](https://mp.weixin.qq.com/s/GpeaNowZKo1plaES9oxZ7g)
+- [《lanux/java-demo/nio/example》](https://github.com/lanux/java-demo/tree/5b29c4b0d0056578a6eaa847e0d1efc9e42e48a4/src/main/java/com/lanux/io/nio)
\ No newline at end of file
diff --git a/netty/09-Netty 源码分析-Netty 简介（一）之项目结构.md b/netty/09-Netty 源码分析-Netty 简介（一）之项目结构.md
new file mode 100644
index 0000000..85d7fb9
--- /dev/null
+++ b/netty/09-Netty 源码分析-Netty 简介（一）之项目结构.md	
@@ -0,0 +1,148 @@
+# 精尽 Netty 源码分析 —— Netty 简介（一）之项目结构
+
+# 1. 概述
+
+本文主要分享 **Netty 的项目结构**。
+希望通过本文能让胖友对 Netty 的整体项目有个简单的了解。
+
+在拉取 Netty 项目后，我们会发现拆分了**好多** Maven 项目。是不是内心一紧，产生了恐惧感？不要方，我们就是继续怼。
+
+[![项目结构](http://static.iocoder.cn/images/Netty/2018_03_01/01.png)](http://static.iocoder.cn/images/Netty/2018_03_01/01.png)项目结构
+
+# 2. 代码统计
+
+这里先分享一个小技巧。笔者在开始源码学习时，会首先了解项目的代码量。
+
+**第一种方式**，使用 [IDEA Statistic](https://plugins.jetbrains.com/plugin/4509-statistic) 插件，统计整体代码量。
+
+[![Statistic 统计代码量](http://static.iocoder.cn/images/Netty/2018_03_01/02.png)](http://static.iocoder.cn/images/Netty/2018_03_01/02.png)Statistic 统计代码量
+
+我们可以粗略的看到，总的代码量在 251365 行。这其中还包括单元测试，示例等等代码。
+所以，不慌。
+
+**第二种方式**，使用 [Shell 脚本命令逐个 Maven 模块统计](http://blog.csdn.net/yhhwatl/article/details/52623879) 。
+
+一般情况下，笔者使用 `find . -name "*.java"|xargs cat|grep -v -e ^$ -e ^\s*\/\/.*$|wc -l` 。这个命令只过滤了**部分注释**，所以相比 [IDEA Statistic](https://plugins.jetbrains.com/plugin/4509-statistic) 会**偏多**。
+
+当然，考虑到准确性，胖友需要手动 `cd` 到每个 Maven 项目的 `src/main/java` 目录下，以达到排除单元测试的代码量。
+
+[![Shell 脚本统计代码量](http://static.iocoder.cn/images/Netty/2018_03_01/03.png)](http://static.iocoder.cn/images/Netty/2018_03_01/03.png)Shell 脚本统计代码量
+
+- 😈 偷懒了下，暂时只统计**核心**模块，未统计**拓展**模块。
+
+# 3. 架构图
+
+在看具体每个 Netty 的 Maven 项目之前，我们还是先来看看 Netty 的整体架构图。
+
+[![架构图](http://static.iocoder.cn/images/Netty/2018_03_01/04.png)](http://static.iocoder.cn/images/Netty/2018_03_01/04.png)架构图
+
+- Core
+
+   
+
+  ：核心部分，是底层的网络通用抽象和部分实现。
+
+  - Extensible Event Model ：可拓展的事件模型。Netty 是基于事件模型的网络应用框架。
+  - Universal Communication API ：通用的通信 API 层。Netty 定义了一套抽象的通用通信层的 API 。
+  - Zero-Copy-Capable Rich Byte Buffer ：支持零拷贝特性的 Byte Buffer 实现。
+
+- Transport Services
+
+   
+
+  ：传输( 通信 )服务，具体的网络传输的定义与实现。
+
+  - Socket & Datagram ：TCP 和 UDP 的传输实现。
+  - HTTP Tunnel ：HTTP 通道的传输实现。
+  - In-VM Piple ：JVM 内部的传输实现。😈 理解起来有点怪，后续看具体代码，会易懂。
+
+- **Protocol Support** ：协议支持。Netty 对于一些通用协议的编解码实现。例如：HTTP、Redis、DNS 等等。
+
+# 4. 项目依赖图
+
+Netty 的 Maven 项目之间**主要依赖**如下图：
+
+[![依赖图](http://static.iocoder.cn/images/Netty/2018_03_01/07.png)](http://static.iocoder.cn/images/Netty/2018_03_01/07.png)依赖图
+
+- 本图省略**非主要依赖**。例如，`handler-proxy` 对 `codec` 有依赖，但是并未画出。
+- 本图省略**非主要的项目**。例如，`resolver`、`testsuite`、`example` 等等。
+
+下面，我们来详细介绍每个项目。
+
+# 5. common
+
+`common` 项目，该项目是一个通用的工具类项目，几乎被所有的其它项目依赖使用，它提供了一些数据类型处理工具类，并发编程以及多线程的扩展，计数器等等通用的工具类。
+
+[![common 项目](http://static.iocoder.cn/images/Netty/2018_03_01/05.png)](http://static.iocoder.cn/images/Netty/2018_03_01/05.png)common 项目
+
+# 6. buffer
+
+> 该项目实现了 Netty 架构图中的 Zero-Copy-Capable Rich Byte Buffer 。
+
+`buffer` 项目，该项目下是 Netty 自行实现的一个 Byte Buffer 字节缓冲区。该包的实现相对于 JDK 自带的 ByteBuffer 有很多**优点**：无论是 API 的功能，使用体验，性能都要更加优秀。它提供了**一系列( 多种 )**的抽象定义以及实现，以满足不同场景下的需要。
+
+[![buffer 项目](http://static.iocoder.cn/images/Netty/2018_03_01/06.png)](http://static.iocoder.cn/images/Netty/2018_03_01/06.png)buffer 项目
+
+# 7. transport
+
+> 该项是核心项目，实现了 Netty 架构图中 Transport Services、Universal Communication API 和 Extensible Event Model 等多部分内容。
+
+`transport` 项目，该项目是网络传输通道的抽象和实现。它定义通信的统一通信 API ，统一了 JDK 的 OIO、NIO ( 不包括 AIO )等多种编程接口。
+
+[![transport 项目](http://static.iocoder.cn/images/Netty/2018_03_01/08.png)](http://static.iocoder.cn/images/Netty/2018_03_01/08.png)transport 项目
+
+另外，它提供了多个子项目，实现不同的传输类型。例如：`transport-native-epoll`、`transport-native-kqueue`、`transport-rxtx`、`transport-udt` 和 `transport-sctp` 等等。
+
+# 8. codec
+
+> 该项目实现了Netty 架构图中的 Protocol Support 。
+
+`codec` 项目，该项目是协议编解码的抽象与**部分**实现：JSON、Google Protocol、Base64、XML 等等。
+
+[![codec 项目](http://static.iocoder.cn/images/Netty/2018_03_01/09.png)](http://static.iocoder.cn/images/Netty/2018_03_01/09.png)codec 项目
+
+另外，它提供了多个子项目，实现不同协议的编解码。例如：`codec-dns`、`codec-haproxy`、`codec-http`、`codec-http2`、`codec-mqtt`、`codec-redis`、`codec-memcached`、`codec-smtp`、`codec-socks`、`codec-stomp`、`codec-xml` 等等。
+
+# 9. handler
+
+`handler` 项目，该项目是提供**内置的**连接通道处理器( ChannelHandler )实现类。例如：SSL 处理器、日志处理器等等。
+
+[![handler 项目](http://static.iocoder.cn/images/Netty/2018_03_01/10.png)](http://static.iocoder.cn/images/Netty/2018_03_01/10.png)handler 项目
+
+另外，它提供了一个子项目 `handler-proxy` ，实现对 HTTP、Socks 4、Socks 5 的代理转发。
+
+# 10. example
+
+`example` 项目，该项目是提供各种 Netty 使用示例，良心开源项目。
+
+[![example 项目](http://static.iocoder.cn/images/Netty/2018_03_01/11.png)](http://static.iocoder.cn/images/Netty/2018_03_01/11.png)example 项目
+
+# 11. 其它项目
+
+Netty 中还有其它项目，考虑到不是本系列的重点，就暂时进行省略。
+
+- `all` ：All In One 的 `pom` 声明。
+
+- `bom` ：Netty Bill Of Materials 的缩写，不了解的胖友，可以看看 [《Maven 与Spring BOM( Bill Of Materials )简化 Spring 版本控制》](https://blog.csdn.net/fanxiaobin577328725/article/details/66974896) 。
+
+- `microbench` ：微基准测试。
+
+- `resolver` ：终端( Endpoint ) 的地址解析器。
+
+- `resolver-dns`
+
+- `tarball` ：All In One 打包工具。
+
+- `testsuite` ：测试集。
+
+  > 测试集( TestSuite ) ：测试集是把多个相关测试归入一个组的表达方式。在 Junit 中，如果我们没有明确的定义一个测试集，那么 Juint 会自动的提供一个测试集。一个测试集一般将同一个包的测试类归入一组。
+
+- `testsuite-autobahhn`
+
+- `testsuite-http2`
+
+- `testsuite-osgi`
+
+# 666. 彩蛋
+
+本文基于杨武兵大佬的 [《Netty 源码分析系列 —— 概述》](https://my.oschina.net/ywbrj042/blog/856596) 进行修改。
\ No newline at end of file
diff --git a/netty/10-Netty 源码分析-Netty 简介（二）之核心组件.assets/01.png b/netty/10-Netty 源码分析-Netty 简介（二）之核心组件.assets/01.png
new file mode 100644
index 0000000..34b796a
Binary files /dev/null and b/netty/10-Netty 源码分析-Netty 简介（二）之核心组件.assets/01.png differ
diff --git a/netty/10-Netty 源码分析-Netty 简介（二）之核心组件.assets/02.png b/netty/10-Netty 源码分析-Netty 简介（二）之核心组件.assets/02.png
new file mode 100644
index 0000000..4af76e8
Binary files /dev/null and b/netty/10-Netty 源码分析-Netty 简介（二）之核心组件.assets/02.png differ
diff --git a/netty/10-Netty 源码分析-Netty 简介（二）之核心组件.assets/03.png b/netty/10-Netty 源码分析-Netty 简介（二）之核心组件.assets/03.png
new file mode 100644
index 0000000..4b35a3e
Binary files /dev/null and b/netty/10-Netty 源码分析-Netty 简介（二）之核心组件.assets/03.png differ
diff --git a/netty/10-Netty 源码分析-Netty 简介（二）之核心组件.md b/netty/10-Netty 源码分析-Netty 简介（二）之核心组件.md
new file mode 100644
index 0000000..364ba99
--- /dev/null
+++ b/netty/10-Netty 源码分析-Netty 简介（二）之核心组件.md	
@@ -0,0 +1,177 @@
+# 精尽 Netty 源码分析 —— Netty 简介（二）之核心组件
+
+# 1. 概述
+
+什么是 Netty ？
+
+> Netty 是一款提供异步的、事件驱动的网络应用程序框架和工具，用以快速开发高性能、高可靠性的网络服务器和客户端程序。
+>
+> 也就是说，Netty 是一个基于 NIO 的客户、服务器端编程框架。使用 Netty 可以确保你快速和简单地开发出一个网络应用，例如实现了某种协议的客户，服务端应用。Netty 相当简化和流线化了网络应用的编程开发过程，例如，TCP 和 UDP 的 socket 服务开发。
+>
+> （以上摘自百度百科）。
+
+Netty 具有如下特性( 摘自《Netty in Action》 )
+
+| 分类     | Netty的特性                                                  |
+| :------- | :----------------------------------------------------------- |
+| 设计     | 1. 统一的 API ，支持多种传输类型( 阻塞和非阻塞的 ) 2. 简单而强大的线程模型 3. 真正的无连接数据报套接字( UDP )支持 4. 连接逻辑组件( ChannelHander 中顺序处理消息 )以及组件复用( 一个 ChannelHandel 可以被多个ChannelPipeLine 复用 ) |
+| 易于使用 | 1. 详实的 Javadoc 和大量的示例集 2. 不需要超过 JDK 1.6+ 的依赖 |
+| 性能     | 拥有比 Java 的核心 API 更高的吞吐量以及更低的延迟( 得益于池化和复用 )，更低的资源消耗以及最少的内存复制 |
+| 健壮性   | 1. 不会因为慢速、快速或者超载的连接而导致 OutOfMemoryError 2. 消除在高速网络中 NIO 应用程序常见的不公平读 / 写比率 |
+| 安全性   | 完整的 SSL/TLS 以及 StartTLs 支持，可用于受限环境下，如 Applet 和 OSGI |
+| 社区驱动 | 发布快速而且频繁                                             |
+
+# 2. Netty 核心组件
+
+为了后期更好地理解和进一步深入 Netty，有必要总体认识一下 Netty 所用到的核心组件以及他们在整个 Netty 架构中是如何协调工作的。
+
+Netty 有如下几个核心组件：
+
+- Bootstrap & ServerBootstrap
+- Channel
+- ChannelFuture
+- EventLoop & EventLoopGroup
+- ChannelHandler
+- ChannelPipeline
+
+核心组件的高层类图如下：
+
+[![高层类图](10-Netty 源码分析-Netty 简介（二）之核心组件.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_03_05/01.png)高层类图
+
+## 2.1 Bootstrap & ServerBootstrap
+
+这 2 个类都继承了AbstractBootstrap，因此它们有很多相同的方法和职责。它们都是**启动器**，能够帮助 Netty 使用者更加方便地组装和配置 Netty ，也可以更方便地启动 Netty 应用程序。相比使用者自己从头去将 Netty 的各部分组装起来要方便得多，降低了使用者的学习和使用成本。它们是我们使用 Netty 的入口和最重要的 API ，可以通过它来连接到一个主机和端口上，也可以通过它来绑定到一个本地的端口上。总的来说，**它们两者之间相同之处要大于不同**。
+
+> 老艿艿：Bootstrap & ServerBootstrap 对于 Netty ，就相当于 Spring Boot 是 Spring 的启动器。
+
+它们和其它组件之间的关系是它们将 Netty 的其它组件进行组装和配置，所以它们会组合和直接或间接依赖其它的类。
+
+Bootstrap 用于启动一个 Netty TCP 客户端，或者 UDP 的一端。
+
+- 通常使用 `#connet(...)` 方法连接到远程的主机和端口，作为一个 Netty TCP 客户端。
+- 也可以通过 `#bind(...)` 方法绑定本地的一个端口，作为 UDP 的一端。
+- 仅仅需要使用**一个** EventLoopGroup 。
+
+ServerBootstrap 往往是用于启动一个 Netty 服务端。
+
+- 通常使用 `#bind(...)` 方法绑定本地的端口上，然后等待客户端的连接。
+- 使用**两个** EventLoopGroup 对象( 当然这个对象可以引用同一个对象 )：第一个用于处理它本地 Socket **连接**的 IO 事件处理，而第二个责负责处理远程客户端的 IO 事件处理。
+
+## 2.2 Channel
+
+Channel 是 Netty 网络操作抽象类，它除了包括基本的 I/O 操作，如 bind、connect、read、write 之外，还包括了 Netty 框架相关的一些功能，如获取该 Channel 的 EventLoop 。
+
+在传统的网络编程中，作为核心类的 Socket ，它对程序员来说并不是那么友好，直接使用其成本还是稍微高了点。而 Netty 的 Channel 则提供的一系列的 API ，它大大降低了直接与 Socket 进行操作的复杂性。而相对于原生 NIO 的 Channel，Netty 的 Channel 具有如下优势( 摘自《Netty权威指南( 第二版 )》) ：
+
+- 在 Channel 接口层，采用 Facade 模式进行统一封装，将网络 I/O 操作、网络 I/O 相关联的其他操作封装起来，统一对外提供。
+- Channel 接口的定义尽量大而全，为 SocketChannel 和 ServerSocketChannel 提供统一的视图，由不同子类实现不同的功能，公共功能在抽象父类中实现，最大程度地实现功能和接口的重用。
+- 具体实现采用聚合而非包含的方式，将相关的功能类聚合在 Channel 中，由 Channel 统一负责和调度，功能实现更加灵活。
+
+## 2.2 EventLoop && EventLoopGroup
+
+Netty 基于**事件驱动模型**，使用不同的事件来通知我们状态的改变或者操作状态的改变。它定义了在整个连接的生命周期里当有事件发生的时候处理的核心抽象。
+
+Channel 为Netty 网络操作抽象类，EventLoop 负责处理注册到其上的 Channel 处理 I/O 操作，两者配合参与 I/O 操作。
+
+EventLoopGroup 是一个 EventLoop 的分组，它可以获取到一个或者多个 EventLoop 对象，因此它提供了迭代出 EventLoop 对象的方法。
+
+下图是 Channel、EventLoop、Thread、EventLoopGroup 之间的关系( 摘自《Netty In Action》) ：
+
+[![Channel、EventLoop、Thread、EventLoopGroup](10-Netty 源码分析-Netty 简介（二）之核心组件.assets/02.png)](http://static.iocoder.cn/images/Netty/2018_03_05/02.png)Channel、EventLoop、Thread、EventLoopGroup
+
+- 一个 EventLoopGroup 包含一个或多个 EventLoop ，即 EventLoopGroup : EventLoop = `1 : n` 。
+- 一个 EventLoop 在它的生命周期内，只能与一个 Thread 绑定，即 EventLoop : Thread = `1 : 1` 。
+- 所有有 EventLoop 处理的 I/O 事件都将在它**专有**的 Thread 上被处理，从而保证线程安全，即 Thread : EventLoop = `1 : 1`。
+- 一个 Channel 在它的生命周期内只能注册到一个 EventLoop 上，即 Channel : EventLoop = `n : 1` 。
+- 一个 EventLoop 可被分配至一个或多个 Channel ，即 EventLoop : Channel = `1 : n` 。
+
+当一个连接到达时，Netty 就会创建一个 Channel，然后从 EventLoopGroup 中分配一个 EventLoop 来给这个 Channel 绑定上，在该 Channel 的整个生命周期中都是有这个绑定的 EventLoop 来服务的。
+
+## 2.4 ChannelFuture
+
+Netty 为异步非阻塞，即所有的 I/O 操作都为异步的，因此，我们不能立刻得知消息是否已经被处理了。Netty 提供了 ChannelFuture 接口，通过该接口的 `#addListener(...)` 方法，注册一个 ChannelFutureListener，当操作执行成功或者失败时，监听就会自动触发返回结果。
+
+## 2.5 ChannelHandler
+
+ChannelHandler ，连接通道处理器，我们使用 Netty 中**最常用**的组件。ChannelHandler 主要用来处理各种事件，这里的事件很广泛，比如可以是连接、数据接收、异常、数据转换等。
+
+ChannelHandler 有两个核心子类 ChannelInboundHandler 和 ChannelOutboundHandler，其中 ChannelInboundHandler 用于接收、处理入站( Inbound )的数据和事件，而 ChannelOutboundHandler 则相反，用于接收、处理出站( Outbound )的数据和事件。
+
+- ChannelInboundHandler 的实现类还包括一系列的 **Decoder** 类，对输入字节流进行解码。
+- ChannelOutboundHandler 的实现类还包括一系列的 **Encoder** 类，对输入字节流进行编码。
+
+ChannelDuplexHandler 可以**同时**用于接收、处理入站和出站的数据和时间。
+
+ChannelHandler 还有其它的一系列的抽象实现 Adapter ，以及一些用于编解码具体协议的 ChannelHandler 实现类。
+
+## 2.6 ChannelPipeline
+
+ChannelPipeline 为 ChannelHandler 的**链**，提供了一个容器并定义了用于沿着链传播入站和出站事件流的 API 。一个数据或者事件可能会被多个 Handler 处理，在这个过程中，数据或者事件经流 ChannelPipeline ，由 ChannelHandler 处理。在这个处理过程中，一个 ChannelHandler 接收数据后处理完成后交给下一个 ChannelHandler，或者什么都不做直接交给下一个 ChannelHandler。
+
+[![ChannelPipeline](10-Netty 源码分析-Netty 简介（二）之核心组件.assets/03.png)](http://static.iocoder.cn/images/Netty/2018_03_05/03.png)ChannelPipeline
+
+- 当一个数据流进入 ChannelPipeline 时，它会从 ChannelPipeline 头部开始，传给第一个 ChannelInboundHandler 。当第一个处理完后再传给下一个，一直传递到管道的尾部。
+- 与之相对应的是，当数据被写出时，它会从管道的尾部开始，先经过管道尾部的“最后”一个ChannelOutboundHandler ，当它处理完成后会传递给前一个 ChannelOutboundHandler 。
+
+上图更详细的，可以是如下过程：
+
+```
+*                                                 I/O Request
+*                                            via {@link Channel} or
+*                                        {@link ChannelHandlerContext}
+*                                                      |
+*  +---------------------------------------------------+---------------+
+*  |                           ChannelPipeline         |               |
+*  |                                                  \|/              |
+*  |    +---------------------+            +-----------+----------+    |
+*  |    | Inbound Handler  N  |            | Outbound Handler  1  |    |
+*  |    +----------+----------+            +-----------+----------+    |
+*  |              /|\                                  |               |
+*  |               |                                  \|/              |
+*  |    +----------+----------+            +-----------+----------+    |
+*  |    | Inbound Handler N-1 |            | Outbound Handler  2  |    |
+*  |    +----------+----------+            +-----------+----------+    |
+*  |              /|\                                  .               |
+*  |               .                                   .               |
+*  | ChannelHandlerContext.fireIN_EVT() ChannelHandlerContext.OUT_EVT()|
+*  |        [ method call]                       [method call]         |
+*  |               .                                   .               |
+*  |               .                                  \|/              |
+*  |    +----------+----------+            +-----------+----------+    |
+*  |    | Inbound Handler  2  |            | Outbound Handler M-1 |    |
+*  |    +----------+----------+            +-----------+----------+    |
+*  |              /|\                                  |               |
+*  |               |                                  \|/              |
+*  |    +----------+----------+            +-----------+----------+    |
+*  |    | Inbound Handler  1  |            | Outbound Handler  M  |    |
+*  |    +----------+----------+            +-----------+----------+    |
+*  |              /|\                                  |               |
+*  +---------------+-----------------------------------+---------------+
+*                  |                                  \|/
+*  +---------------+-----------------------------------+---------------+
+*  |               |                                   |               |
+*  |       [ Socket.read() ]                    [ Socket.write() ]     |
+*  |                                                                   |
+*  |  Netty Internal I/O Threads (Transport Implementation)            |
+*  +-------------------------------------------------------------------+
+```
+
+------
+
+当 ChannelHandler 被添加到 ChannelPipeline 时，它将会被分配一个 **ChannelHandlerContext** ，它代表了 ChannelHandler 和 ChannelPipeline 之间的绑定。其中 ChannelHandler 添加到 ChannelPipeline 中，通过 ChannelInitializer 来实现，过程如下：
+
+1. 一个 ChannelInitializer 的实现对象，被设置到了 BootStrap 或 ServerBootStrap 中。
+2. 当 `ChannelInitializer#initChannel()` 方法被调用时，ChannelInitializer 将在 ChannelPipeline 中创建**一组**自定义的 ChannelHandler 对象。
+3. ChannelInitializer 将它自己从 ChannelPipeline 中移除。
+
+> ChannelInitializer 是一个特殊的 ChannelInboundHandlerAdapter 抽象类。
+
+# 666. 彩蛋
+
+本文整理于如下两篇文章：
+
+- 小明哥 [《【死磕 Netty 】—— Netty的核心组件》](https://cloud.tencent.com/developer/article/1110061)
+- 杨武兵 [《Netty 源码分析系列 —— 概述》](https://my.oschina.net/ywbrj042/blog/856596)
+- 乒乓狂魔 [《Netty 源码分析（一）概览》](https://my.oschina.net/pingpangkuangmo/blog/734051)
+
+😈 见谅，不擅长写理论型的内容哈。
\ No newline at end of file
diff --git a/netty/11-Netty 源码分析-启动（一）之服务端.assets/01.png b/netty/11-Netty 源码分析-启动（一）之服务端.assets/01.png
new file mode 100644
index 0000000..a1e68d8
Binary files /dev/null and b/netty/11-Netty 源码分析-启动（一）之服务端.assets/01.png differ
diff --git a/netty/11-Netty 源码分析-启动（一）之服务端.assets/02.png b/netty/11-Netty 源码分析-启动（一）之服务端.assets/02.png
new file mode 100644
index 0000000..d3d0bd4
Binary files /dev/null and b/netty/11-Netty 源码分析-启动（一）之服务端.assets/02.png differ
diff --git a/netty/11-Netty 源码分析-启动（一）之服务端.assets/03.png b/netty/11-Netty 源码分析-启动（一）之服务端.assets/03.png
new file mode 100644
index 0000000..1513b8b
Binary files /dev/null and b/netty/11-Netty 源码分析-启动（一）之服务端.assets/03.png differ
diff --git a/netty/11-Netty 源码分析-启动（一）之服务端.assets/04.png b/netty/11-Netty 源码分析-启动（一）之服务端.assets/04.png
new file mode 100644
index 0000000..6e3980f
Binary files /dev/null and b/netty/11-Netty 源码分析-启动（一）之服务端.assets/04.png differ
diff --git a/netty/11-Netty 源码分析-启动（一）之服务端.assets/05.png b/netty/11-Netty 源码分析-启动（一）之服务端.assets/05.png
new file mode 100644
index 0000000..fc8b7ba
Binary files /dev/null and b/netty/11-Netty 源码分析-启动（一）之服务端.assets/05.png differ
diff --git a/netty/11-Netty 源码分析-启动（一）之服务端.assets/06.png b/netty/11-Netty 源码分析-启动（一）之服务端.assets/06.png
new file mode 100644
index 0000000..3eebc1a
Binary files /dev/null and b/netty/11-Netty 源码分析-启动（一）之服务端.assets/06.png differ
diff --git a/netty/11-Netty 源码分析-启动（一）之服务端.assets/07.png b/netty/11-Netty 源码分析-启动（一）之服务端.assets/07.png
new file mode 100644
index 0000000..8db266d
Binary files /dev/null and b/netty/11-Netty 源码分析-启动（一）之服务端.assets/07.png differ
diff --git a/netty/11-Netty 源码分析-启动（一）之服务端.assets/08.png b/netty/11-Netty 源码分析-启动（一）之服务端.assets/08.png
new file mode 100644
index 0000000..ce8544e
Binary files /dev/null and b/netty/11-Netty 源码分析-启动（一）之服务端.assets/08.png differ
diff --git a/netty/11-Netty 源码分析-启动（一）之服务端.assets/09.png b/netty/11-Netty 源码分析-启动（一）之服务端.assets/09.png
new file mode 100644
index 0000000..a3955c2
Binary files /dev/null and b/netty/11-Netty 源码分析-启动（一）之服务端.assets/09.png differ
diff --git a/netty/11-Netty 源码分析-启动（一）之服务端.assets/10.png b/netty/11-Netty 源码分析-启动（一）之服务端.assets/10.png
new file mode 100644
index 0000000..709c2a7
Binary files /dev/null and b/netty/11-Netty 源码分析-启动（一）之服务端.assets/10.png differ
diff --git a/netty/11-Netty 源码分析-启动（一）之服务端.md b/netty/11-Netty 源码分析-启动（一）之服务端.md
new file mode 100644
index 0000000..e091f7c
--- /dev/null
+++ b/netty/11-Netty 源码分析-启动（一）之服务端.md	
@@ -0,0 +1,1878 @@
+# 精尽 Netty 源码分析 —— 启动（一）之服务端
+
+# 1. 概述
+
+对于所有 Netty 的新手玩家，我们**最先**使用的就是 Netty 的 Bootstrap 和 ServerBootstrap 组这两个“**启动器**”组件。它们在 `transport` 模块的 `bootstrap` 包下实现，如下图所示：
+
+[![`bootstrap` 包](11-Netty 源码分析-启动（一）之服务端.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_04_01/01.png)`bootstrap` 包
+
+在图中，我们可以看到三个以 Bootstrap 结尾的类，类图如下：
+
+[![Bootstrap 类图](11-Netty 源码分析-启动（一）之服务端.assets/02.png)](http://static.iocoder.cn/images/Netty/2018_04_01/02.png)Bootstrap 类图
+
+- 为什么是这样的类关系呢？因为 ServerBootstrap 和 Bootstrap **大部分**的方法和职责都是相同的。
+
+本文仅分享 ServerBootstrap 启动 Netty 服务端的过程。下一篇文章，我们再分享 Bootstrap 分享 Netty 客户端。
+
+# 2. ServerBootstrap 示例
+
+下面，我们先来看一个 ServerBootstrap 的使用示例，就是我们在 [《精尽 Netty 源码分析 —— 调试环境搭建》](http://svip.iocoder.cn/Netty/build-debugging-environment/#5-1-EchoServer) 搭建的 EchoServer 示例。代码如下：
+
+```
+ 1: public final class EchoServer {
+ 2: 
+ 3:     static final boolean SSL = System.getProperty("ssl") != null;
+ 4:     static final int PORT = Integer.parseInt(System.getProperty("port", "8007"));
+ 5: 
+ 6:     public static void main(String[] args) throws Exception {
+ 7:         // Configure SSL.
+ 8:         // 配置 SSL
+ 9:         final SslContext sslCtx;
+10:         if (SSL) {
+11:             SelfSignedCertificate ssc = new SelfSignedCertificate();
+12:             sslCtx = SslContextBuilder.forServer(ssc.certificate(), ssc.privateKey()).build();
+13:         } else {
+14:             sslCtx = null;
+15:         }
+16: 
+17:         // Configure the server.
+18:         // 创建两个 EventLoopGroup 对象
+19:         EventLoopGroup bossGroup = new NioEventLoopGroup(1); // 创建 boss 线程组 用于服务端接受客户端的连接
+20:         EventLoopGroup workerGroup = new NioEventLoopGroup(); // 创建 worker 线程组 用于进行 SocketChannel 的数据读写
+21:         // 创建 EchoServerHandler 对象
+22:         final EchoServerHandler serverHandler = new EchoServerHandler();
+23:         try {
+24:             // 创建 ServerBootstrap 对象
+25:             ServerBootstrap b = new ServerBootstrap();
+26:             b.group(bossGroup, workerGroup) // 设置使用的 EventLoopGroup
+27:              .channel(NioServerSocketChannel.class) // 设置要被实例化的为 NioServerSocketChannel 类
+28:              .option(ChannelOption.SO_BACKLOG, 100) // 设置 NioServerSocketChannel 的可选项
+29:              .handler(new LoggingHandler(LogLevel.INFO)) // 设置 NioServerSocketChannel 的处理器
+30:              .childHandler(new ChannelInitializer<SocketChannel>() {
+31:                  @Override
+32:                  public void initChannel(SocketChannel ch) throws Exception { // 设置连入服务端的 Client 的 SocketChannel 的处理器
+33:                      ChannelPipeline p = ch.pipeline();
+34:                      if (sslCtx != null) {
+35:                          p.addLast(sslCtx.newHandler(ch.alloc()));
+36:                      }
+37:                      //p.addLast(new LoggingHandler(LogLevel.INFO));
+38:                      p.addLast(serverHandler);
+39:                  }
+40:              });
+41: 
+42:             // Start the server.
+43:             // 绑定端口，并同步等待成功，即启动服务端
+44:             ChannelFuture f = b.bind(PORT).sync();
+45: 
+46:             // Wait until the server socket is closed.
+47:             // 监听服务端关闭，并阻塞等待
+48:             f.channel().closeFuture().sync();
+49:         } finally {
+50:             // Shut down all event loops to terminate all threads.
+51:             // 优雅关闭两个 EventLoopGroup 对象
+52:             bossGroup.shutdownGracefully();
+53:             workerGroup.shutdownGracefully();
+54:         }
+55:     }
+56: }
+```
+
+- 第 7 至 15 行：配置 SSL ，暂时可以忽略。
+- 第 17 至 20 行：创建两个 EventLoopGroup 对象。
+  - **boss** 线程组：用于服务端接受客户端的**连接**。
+  - **worker** 线程组：用于进行客户端的 SocketChannel 的**数据读写**。
+  - 关于为什么是**两个** EventLoopGroup 对象，我们在后续的文章，进行分享。
+- 第 22 行：创建 [`io.netty.example.echo.EchoServerHandler`](https://github.com/YunaiV/netty/blob/f7016330f1483021ef1c38e0923e1c8b7cef0d10/example/src/main/java/io/netty/example/echo/EchoServerHandler.java) 对象。
+- 第 24 行：创建 ServerBootstrap 对象，用于设置服务端的启动配置。
+  - 第 26 行：调用 `#group(EventLoopGroup parentGroup, EventLoopGroup childGroup)` 方法，设置使用的 EventLoopGroup 。
+  - 第 27 行：调用 `#channel(Class<? extends C> channelClass)` 方法，设置要被实例化的 Channel 为 NioServerSocketChannel 类。在下文中，我们会看到该 Channel 内嵌了 `java.nio.channels.ServerSocketChannel` 对象。是不是很熟悉 😈 ？
+  - 第 28 行：调用 `#option(ChannelOption<T> option, T value)` 方法，设置 NioServerSocketChannel 的可选项。在 [`io.netty.channel.ChannelOption`](https://github.com/YunaiV/netty/blob/f7016330f1483021ef1c38e0923e1c8b7cef0d10/transport/src/main/java/io/netty/channel/ChannelOption.java) 类中，枚举了相关的可选项。
+  - 第 29 行：调用 `#handler(ChannelHandler handler)` 方法，设置 NioServerSocketChannel 的处理器。在本示例中，使用了 `io.netty.handler.logging.LoggingHandler` 类，用于打印服务端的每个事件。详细解析，见后续文章。
+  - 第 30 至 40 行：调用 `#childHandler(ChannelHandler handler)` 方法，设置连入服务端的 Client 的 SocketChannel 的处理器。在本实例中，使用 ChannelInitializer 来初始化连入服务端的 Client 的 SocketChannel 的处理器。
+- 第 44 行：**先**调用 `#bind(int port)` 方法，绑定端口，**后**调用 `ChannelFuture#sync()` 方法，阻塞等待成功。这个过程，就是“**启动服务端**”。
+- 第 48 行：**先**调用 `#closeFuture()` 方法，**监听**服务器关闭，**后**调用 `ChannelFuture#sync()` 方法，阻塞等待成功。😈 注意，此处不是关闭服务器，而是“**监听**”关闭。
+- 第 49 至 54 行：执行到此处，说明服务端已经关闭，所以调用 `EventLoopGroup#shutdownGracefully()` 方法，分别关闭两个 EventLoopGroup 对象。
+
+> 老艿艿的自我吐槽：😈 貌似又啰嗦了一把？？？
+
+# 3. AbstractBootstrap
+
+我们再一起来看看 AbstractBootstrap 的代码实现。因为 ServerBootstrap 和 Bootstrap 都实现这个类，所以和 ServerBootstrap 相关度高的方法，我们会放在 [「4. ServerBootstrap」](https://svip.iocoder.cn/Netty/bootstrap-1-server/#) 中分享，而和 Bootstrap 相关度高的方法，我们会放在下一篇 Bootstrap 的文章分享。
+
+> 老艿艿：下面我会开始分享一系列的 AbstractBootstrap 的配置方法，如果比较熟悉的胖友，可以直接跳到 [「3.13 bind」](https://svip.iocoder.cn/Netty/bootstrap-1-server/#) 开始看。
+
+## 3.1 构造方法
+
+```
+public abstract class AbstractBootstrap<B extends AbstractBootstrap<B, C>, C extends Channel> implements Cloneable {
+
+    /**
+     * EventLoopGroup 对象
+     */
+    volatile EventLoopGroup group;
+    /**
+     * Channel 工厂，用于创建 Channel 对象。
+     */
+    @SuppressWarnings("deprecation")
+    private volatile ChannelFactory<? extends C> channelFactory;
+    /**
+     * 本地地址
+     */
+    private volatile SocketAddress localAddress;
+    /**
+     * 可选项集合
+     */
+    private final Map<ChannelOption<?>, Object> options = new LinkedHashMap<ChannelOption<?>, Object>();
+    /**
+     * 属性集合
+     */
+    private final Map<AttributeKey<?>, Object> attrs = new LinkedHashMap<AttributeKey<?>, Object>();
+    /**
+     * 处理器
+     */
+    private volatile ChannelHandler handler;
+
+    AbstractBootstrap() {
+        // Disallow extending from a different package.
+    }
+
+    AbstractBootstrap(AbstractBootstrap<B, C> bootstrap) {
+        group = bootstrap.group;
+        channelFactory = bootstrap.channelFactory;
+        handler = bootstrap.handler;
+        localAddress = bootstrap.localAddress;
+        synchronized (bootstrap.options) { // <1>
+            options.putAll(bootstrap.options);
+        }
+        synchronized (bootstrap.attrs) { // <2>
+            attrs.putAll(bootstrap.attrs);
+        }
+    }
+    
+    // ... 省略无关代码
+}
+```
+
+- AbstractBootstrap 是个
+
+  抽象类
+
+  ，并且实现 Cloneable 接口。另外，它声明了
+
+   
+
+  ```
+  B
+  ```
+
+   
+
+  、
+
+  ```
+  C
+  ```
+
+   
+
+  两个泛型：
+
+  - `B` ：继承 AbstractBootstrap 类，用于表示**自身**的类型。
+  - `C` ：继承 Channel 类，表示表示**创建**的 Channel 类型。
+
+- 每个属性比较简单，结合下面我们要分享的每个方法，就更易懂啦。
+
+- 在 `<1>` 和 `<2>` 两处，比较神奇的使用了 `synchronized` 修饰符。老艿艿也是疑惑了一下，但是这并难不倒我。因为传入的 `bootstrap` 参数的 `options` 和 `attrs` 属性，可能在另外的线程被修改( 例如，我们下面会看到的 `#option(hannelOption<T> option, T value)` 方法)，通过 `synchronized` 来同步，解决此问题。
+
+## 3.2 self
+
+`#self()` 方法，返回自己。代码如下：
+
+```
+private B self() {
+    return (B) this;
+}
+```
+
+- 这里就使用到了 AbstractBootstrap 声明的 `B` 泛型。
+
+## 3.3 group
+
+`#group(EventLoopGroup group)` 方法，设置 EventLoopGroup 到 `group` 中。代码如下：
+
+```
+public B group(EventLoopGroup group) {
+    if (group == null) {
+        throw new NullPointerException("group");
+    }
+    if (this.group != null) { // 不允许重复设置
+        throw new IllegalStateException("group set already");
+    }
+    this.group = group;
+    return self();
+}
+```
+
+- 最终调用 `#self()` 方法，返回自己。实际上，AbstractBootstrap 整个方法的调用，基本都是[“**链式调用**”](https://en.wikipedia.org/wiki/Method_chaining#Java)。
+
+## 3.4 channel
+
+`#channel(Class<? extends C> channelClass)` 方法，设置要被**实例化**的 Channel 的类。代码如下：
+
+```
+public B channel(Class<? extends C> channelClass) {
+    if (channelClass == null) {
+        throw new NullPointerException("channelClass");
+    }
+    return channelFactory(new ReflectiveChannelFactory<C>(channelClass));
+}
+```
+
+- 虽然传入的 `channelClass` 参数，但是会使用 `io.netty.channel.ReflectiveChannelFactory` 进行封装。
+
+- 调用 `#channelFactory(io.netty.channel.ChannelFactory<? extends C> channelFactory)` 方法，设置 `channelFactory` 属性。代码如下：
+
+  ```
+  public B channelFactory(io.netty.channel.ChannelFactory<? extends C> channelFactory) {
+      return channelFactory((ChannelFactory<C>) channelFactory);
+  }
+  
+  @Deprecated
+  public B channelFactory(io.netty.bootstrap.ChannelFactory<? extends C> channelFactory) {
+      if (channelFactory == null) {
+          throw new NullPointerException("channelFactory");
+      }
+      if (this.channelFactory != null) { // 不允许重复设置
+          throw new IllegalStateException("channelFactory set already");
+      }
+  
+      this.channelFactory = channelFactory;
+      return self();
+  }
+  ```
+
+  - 我们可以看到有两个 `#channelFactory(...)` 方法，并且第**二**个是 `@Deprecated` 的方法。从 ChannelFactory 使用的**包名**，我们就可以很容易的判断，最初 ChannelFactory 在 `bootstrap` 中，后**重构**到 `channel` 包中。
+
+### 3.4.1 ChannelFactory
+
+`io.netty.channel.ChannelFactory` ，Channel 工厂**接口**，用于创建 Channel 对象。代码如下：
+
+```
+public interface ChannelFactory<T extends Channel> extends io.netty.bootstrap.ChannelFactory<T> {
+
+    /**
+     * Creates a new channel.
+     *
+     * 创建 Channel 对象
+     *
+     */
+    @Override
+    T newChannel();
+
+}
+```
+
+- `#newChannel()` 方法，用于创建 Channel 对象。
+
+### 3.4.2 ReflectiveChannelFactory
+
+`io.netty.channel.ReflectiveChannelFactory` ，实现 ChannelFactory 接口，反射调用默认构造方法，创建 Channel 对象的工厂实现类。代码如下：
+
+```
+public class ReflectiveChannelFactory<T extends Channel> implements ChannelFactory<T> {
+
+    /**
+     * Channel 对应的类
+     */
+    private final Class<? extends T> clazz;
+
+    public ReflectiveChannelFactory(Class<? extends T> clazz) {
+        if (clazz == null) {
+            throw new NullPointerException("clazz");
+        }
+        this.clazz = clazz;
+    }
+
+    @Override
+    public T newChannel() {
+        try {
+            // 反射调用默认构造方法，创建 Channel 对象
+            return clazz.getConstructor().newInstance();
+        } catch (Throwable t) {
+            throw new ChannelException("Unable to create Channel from class " + clazz, t);
+        }
+    }
+
+}
+```
+
+- 重点看 `clazz.getConstructor().newInstance()` 代码块。
+
+## 3.5 localAddress
+
+`#localAddress(...)` 方法，设置创建 Channel 的本地地址。有四个**重载**的方法，代码如下：
+
+```
+public B localAddress(SocketAddress localAddress) {
+    this.localAddress = localAddress;
+    return self();
+}
+
+public B localAddress(int inetPort) {
+    return localAddress(new InetSocketAddress(inetPort));
+}
+
+public B localAddress(String inetHost, int inetPort) {
+    return localAddress(SocketUtils.socketAddress(inetHost, inetPort));
+}
+
+public B localAddress(InetAddress inetHost, int inetPort) {
+    return localAddress(new InetSocketAddress(inetHost, inetPort));
+}
+```
+
+- 一般情况下，不会调用该方法进行配置，而是调用 `#bind(...)` 方法，例如 [「2. ServerBootstrap 示例」](https://svip.iocoder.cn/Netty/bootstrap-1-server/#) 。
+
+## 3.6 option
+
+`#option(ChannelOption<T> option, T value)` 方法，设置创建 Channel 的可选项。代码如下：
+
+```
+public <T> B option(ChannelOption<T> option, T value) {
+    if (option == null) {
+        throw new NullPointerException("option");
+    }
+    if (value == null) { // 空，意味着移除
+        synchronized (options) {
+            options.remove(option);
+        }
+    } else { // 非空，进行修改
+        synchronized (options) {
+            options.put(option, value);
+        }
+    }
+    return self();
+}
+```
+
+## 3.7 attr
+
+`#attr(AttributeKey<T> key, T value)` 方法，设置创建 Channel 的属性。代码如下：
+
+```
+public <T> B attr(AttributeKey<T> key, T value) {
+    if (key == null) {
+        throw new NullPointerException("key");
+    }
+    if (value == null) { // 空，意味着移除
+        synchronized (attrs) {
+            attrs.remove(key);
+        }
+    } else { // 非空，进行修改
+        synchronized (attrs) {
+            attrs.put(key, value);
+        }
+    }
+    return self();
+}
+```
+
+- 怎么理解 `attrs` 属性呢？我们可以理解成 `java.nio.channels.SelectionKey` 的 `attachment` 属性，并且类型为 Map 。
+
+## 3.8 handler
+
+`#handler(ChannelHandler handler)` 方法，设置创建 Channel 的处理器。代码如下：
+
+```
+public B handler(ChannelHandler handler) {
+    if (handler == null) {
+        throw new NullPointerException("handler");
+    }
+    this.handler = handler;
+    return self();
+}
+```
+
+## 3.9 validate
+
+`#validate()` 方法，校验配置是否正确。代码如下：
+
+```
+public B validate() {
+    if (group == null) {
+        throw new IllegalStateException("group not set");
+    }
+    if (channelFactory == null) {
+        throw new IllegalStateException("channel or channelFactory not set");
+    }
+    return self();
+}
+```
+
+- 在 `#bind(...)` 方法中，绑定本地地址时，会调用该方法进行校验。
+
+## 3.10 clone
+
+`#clone()` **抽象**方法，克隆一个 AbstractBootstrap 对象。代码如下。
+
+```
+/**
+ * Returns a deep clone of this bootstrap which has the identical configuration.  This method is useful when making
+ * multiple {@link Channel}s with similar settings.  Please note that this method does not clone the
+ * {@link EventLoopGroup} deeply but shallowly, making the group a shared resource.
+ */
+@Override
+public abstract B clone();
+```
+
+- 来自实现 Cloneable 接口，在子类中实现。这是
+
+  深
+
+  拷贝，即创建一个新对象，但不是所有的属性是
+
+  深
+
+  拷贝。可参见
+
+   
+
+  「3.1 构造方法」
+
+   
+
+  ：
+
+  - **浅**拷贝属性：`group`、`channelFactory`、`handler`、`localAddress` 。
+  - **深**拷贝属性：`options`、`attrs` 。
+
+## 3.11 config
+
+`#config()` 方法，返回当前 AbstractBootstrap 的配置对象。代码如下：
+
+```
+public abstract AbstractBootstrapConfig<B, C> config();
+```
+
+### 3.11.1 AbstractBootstrapConfig
+
+`io.netty.bootstrap.AbstractBootstrapConfig` ，BootstrapConfig **抽象类**。代码如下：
+
+```
+public abstract class AbstractBootstrapConfig<B extends AbstractBootstrap<B, C>, C extends Channel> {
+
+    protected final B bootstrap;
+
+    protected AbstractBootstrapConfig(B bootstrap) {
+        this.bootstrap = ObjectUtil.checkNotNull(bootstrap, "bootstrap");
+    }
+    
+    public final SocketAddress localAddress() {
+        return bootstrap.localAddress();
+    }
+    
+    public final ChannelFactory<? extends C> channelFactory() {
+        return bootstrap.channelFactory();
+    }
+
+    public final ChannelHandler handler() {
+        return bootstrap.handler();
+    }
+
+    public final Map<ChannelOption<?>, Object> options() {
+        return bootstrap.options();
+    }
+
+    public final Map<AttributeKey<?>, Object> attrs() {
+        return bootstrap.attrs();
+    }
+
+    public final EventLoopGroup group() {
+        return bootstrap.group();
+    }
+    
+}
+```
+
+- `bootstrap` 属性，对应的启动类对象。在每个方法中，我们可以看到，都是直接调用 `boostrap` 属性对应的方法，读取对应的配置。
+
+------
+
+AbstractBootstrapConfig 的整体类图如下：[![AbstractBootstrapConfig 类图](11-Netty 源码分析-启动（一）之服务端.assets/03.png)](http://static.iocoder.cn/images/Netty/2018_04_01/03.png)AbstractBootstrapConfig 类图
+
+- 每个 Config 类，对应一个 Bootstrap 类。
+- ServerBootstrapConfig 和 BootstrapConfig 的实现代码，和 AbstractBootstrapConfig 基本一致，所以胖友自己去查看噢。
+
+## 3.12 setChannelOptions
+
+`#setChannelOptions(...)` **静态**方法，设置传入的 Channel 的**多个**可选项。代码如下：
+
+```
+static void setChannelOptions(
+        Channel channel, Map<ChannelOption<?>, Object> options, InternalLogger logger) {
+    for (Map.Entry<ChannelOption<?>, Object> e: options.entrySet()) {
+        setChannelOption(channel, e.getKey(), e.getValue(), logger);
+    }
+}
+
+static void setChannelOptions(
+        Channel channel, Map.Entry<ChannelOption<?>, Object>[] options, InternalLogger logger) {
+    for (Map.Entry<ChannelOption<?>, Object> e: options) {
+        setChannelOption(channel, e.getKey(), e.getValue(), logger);
+    }
+}
+```
+
+- 在两个方法的内部，**都**调用 `#setChannelOption(Channel channel, ChannelOption<?> option, Object value, InternalLogger logger)` **静态**方法，设置传入的 Channel 的**一个**可选项。代码如下：
+
+  ```
+  private static void setChannelOption(
+          Channel channel, ChannelOption<?> option, Object value, InternalLogger logger) {
+      try {
+          if (!channel.config().setOption((ChannelOption<Object>) option, value)) {
+              logger.warn("Unknown channel option '{}' for channel '{}'", option, channel);
+          }
+      } catch (Throwable t) {
+          logger.warn("Failed to set channel option '{}' with value '{}' for channel '{}'", option, value, channel, t);
+      }
+  }
+  ```
+
+  - 不同于 [「3.6 option」](https://svip.iocoder.cn/Netty/bootstrap-1-server/#) 方法，它是设置要创建的 Channel 的可选项。而 `#setChannelOption(...)` 方法，它是设置已经创建的 Channel 的可选项。
+
+## 3.13 bind
+
+> 老艿艿：`#bind(...)` 方法，也可以启动 UDP 的一端，考虑到这个系列主要分享 Netty 在 NIO 相关的源码解析，所以如下所有的分享，都不考虑 UDP 的情况。
+
+`#bind(...)` 方法，绑定端口，启动服务端。代码如下：
+
+```
+public ChannelFuture bind() {
+    // 校验服务启动需要的必要参数
+    validate();
+    SocketAddress localAddress = this.localAddress;
+    if (localAddress == null) {
+        throw new IllegalStateException("localAddress not set");
+    }
+    // 绑定本地地址( 包括端口 )
+    return doBind(localAddress);
+}
+
+public ChannelFuture bind(int inetPort) {
+    return bind(new InetSocketAddress(inetPort));
+}
+
+public ChannelFuture bind(String inetHost, int inetPort) {
+    return bind(SocketUtils.socketAddress(inetHost, inetPort));
+}
+
+public ChannelFuture bind(InetAddress inetHost, int inetPort) {
+    return bind(new InetSocketAddress(inetHost, inetPort));
+}
+
+public ChannelFuture bind(SocketAddress localAddress) {
+    // 校验服务启动需要的必要参数
+    validate();
+    if (localAddress == null) {
+        throw new NullPointerException("localAddress");
+    }
+    // 绑定本地地址( 包括端口 )
+    return doBind(localAddress);
+}
+```
+
+- 该方法返回的是 ChannelFuture 对象，也就是**异步**的绑定端口，启动服务端。如果需要**同步**，则需要调用 `ChannelFuture#sync()` 方法。
+
+`#bind(...)` 方法，核心流程如下图：
+
+[![核心流程](11-Netty 源码分析-启动（一）之服务端.assets/04.png)](http://static.iocoder.cn/images/Netty/2018_04_01/04.png)核心流程
+
+- 主要有 4 个步骤，下面我们来拆解代码，看看和我们在 [《精尽 Netty 源码分析 —— NIO 基础（五）之示例》](http://svip.iocoder.cn/Netty/nio-5-demo/?self) 的 NioServer 的代码，是**怎么对应**的。
+
+### 3.13.1 doBind
+
+`#doBind(final SocketAddress localAddress)` 方法，代码如下：
+
+```
+ 1: private ChannelFuture doBind(final SocketAddress localAddress) {
+ 2:     // 初始化并注册一个 Channel 对象，因为注册是异步的过程，所以返回一个 ChannelFuture 对象。
+ 3:     final ChannelFuture regFuture = initAndRegister();
+ 4:     final Channel channel = regFuture.channel();
+ 5:     if (regFuture.cause() != null) { // 若发生异常，直接进行返回。
+ 6:         return regFuture;
+ 7:     }
+ 8: 
+ 9:     // 绑定 Channel 的端口，并注册 Channel 到 SelectionKey 中。
+10:     if (regFuture.isDone()) { // 未
+11:         // At this point we know that the registration was complete and successful.
+12:         ChannelPromise promise = channel.newPromise();
+13:         doBind0(regFuture, channel, localAddress, promise); // 绑定
+14:         return promise;
+15:     } else {
+16:         // Registration future is almost always fulfilled already, but just in case it's not.
+17:         final PendingRegistrationPromise promise = new PendingRegistrationPromise(channel);
+18:         regFuture.addListener(new ChannelFutureListener() {
+19:             @Override
+20:             public void operationComplete(ChannelFuture future) throws Exception {
+22:                 Throwable cause = future.cause();
+23:                 if (cause != null) {
+24:                     // Registration on the EventLoop failed so fail the ChannelPromise directly to not cause an
+25:                     // IllegalStateException once we try to access the EventLoop of the Channel.
+26:                     promise.setFailure(cause);
+27:                 } else {
+28:                     // Registration was successful, so set the correct executor to use.
+29:                     // See https://github.com/netty/netty/issues/2586
+30:                     promise.registered();
+31: 
+32:                     doBind0(regFuture, channel, localAddress, promise); // 绑定
+33:                 }
+34:             }
+35:         });
+36:         return promise;
+37:     }
+38: }
+```
+
+- 第 3 行：调用
+
+   
+
+  ```
+  #initAndRegister()
+  ```
+
+   
+
+  方法，初始化并注册一个 Channel 对象。因为注册是
+
+  异步
+
+  的过程，所以返回一个 ChannelFuture 对象。详细解析，见
+
+   
+
+  「3.14 initAndRegister」
+
+   
+
+  。
+
+  - 第 5 至 7 行：若发生异常，直接进行返回。
+
+- 第 9 至 37 行：因为注册是
+
+  异步
+
+  的过程，有可能已完成，有可能未完成。所以实现代码分成了【第 10 至 14 行】和【第 15 至 36 行】分别处理已完成和未完成的情况。
+
+  - **核心**在【第 13 行】或者【第 32 行】的代码，调用 `#doBind0(final ChannelFuture regFuture, final Channel channel, final SocketAddress localAddress, final ChannelPromise promise)` 方法，绑定 Channel 的端口，并注册 Channel 到 SelectionKey 中。
+  - 如果**异步**注册对应的 ChanelFuture 未完成，则调用 `ChannelFuture#addListener(ChannelFutureListener)` 方法，添加监听器，在**注册**完成后，进行回调执行 `#doBind0(...)` 方法的逻辑。详细解析，见 见 [「3.13.2 doBind0」](https://svip.iocoder.cn/Netty/bootstrap-1-server/#) 。
+  - 所以总结来说，**bind 的逻辑，执行在 register 的逻辑之后**。
+  - TODO 1001 Promise 2. PendingRegistrationPromise
+
+### 3.13.2 doBind0
+
+> 老艿艿：此小节的内容，胖友先看完 [「3.14 initAndRegister」](https://svip.iocoder.cn/Netty/bootstrap-1-server/#) 的内容在回过头来看。因为 `#doBind0(...)` 方法的执行，在 `#initAndRegister()` 方法之后。
+
+`#doBind0(...)` 方法，执行 Channel 的端口绑定逻辑。代码如下：
+
+```
+ 1: private static void doBind0(
+ 2:         final ChannelFuture regFuture, final Channel channel,
+ 3:         final SocketAddress localAddress, final ChannelPromise promise) {
+ 4: 
+ 5:     // This method is invoked before channelRegistered() is triggered.  Give user handlers a chance to set up
+ 6:     // the pipeline in its channelRegistered() implementation.
+ 7:     channel.eventLoop().execute(new Runnable() {
+ 8:         @Override
+ 9:         public void run() {
+11:             // 注册成功，绑定端口
+12:             if (regFuture.isSuccess()) {
+13:                 channel.bind(localAddress, promise).addListener(ChannelFutureListener.CLOSE_ON_FAILURE);
+14:             // 注册失败，回调通知 promise 异常
+15:             } else {
+16:                 promise.setFailure(regFuture.cause());
+17:             }
+18:         }
+19:     });
+20: }
+```
+
+- 第 7 行：调用 EventLoop 执行 Channel 的端口绑定逻辑。但是，实际上当前线程已经是 EventLoop 所在的线程了，为何还要这样操作呢？答案在【第 5 至 6 行】的英语注释。感叹句，Netty 虽然代码量非常庞大且复杂，但是英文注释真的是非常齐全，包括 Github 的 issue 对代码提交的描述，也非常健全。
+
+- 第 14 至 17 行：注册失败，回调通知 `promise` 异常。
+
+- 第 11 至 13 行：注册成功，调用
+
+   
+
+  ```
+  Channel#bind(SocketAddress localAddress, ChannelPromise promise)
+  ```
+
+   
+
+  方法，执行 Channel 的端口绑定逻辑。后续的方法栈调用如下图：
+
+  ![Channel bind 流程](11-Netty 源码分析-启动（一）之服务端.assets/09.png)
+
+  Channel bind 流程
+
+  - 还是老样子，我们先省略掉 pipeline 的内部实现代码，从 `AbstractUnsafe#bind(final SocketAddress localAddress, final ChannelPromise promise)` 方法，继续向下分享。
+
+`AbstractUnsafe#bind(final SocketAddress localAddress, final ChannelPromise promise)` 方法，Channel 的端口绑定逻辑。代码如下：
+
+```
+ 1: @Override
+ 2: public final void bind(final SocketAddress localAddress, final ChannelPromise promise) {
+ 3:     // 判断是否在 EventLoop 的线程中。
+ 4:     assertEventLoop();
+ 5: 
+ 6:     if (!promise.setUncancellable() || !ensureOpen(promise)) {
+ 7:         return;
+ 8:     }
+ 9: 
+10:     // See: https://github.com/netty/netty/issues/576
+11:     if (Boolean.TRUE.equals(config().getOption(ChannelOption.SO_BROADCAST)) &&
+12:         localAddress instanceof InetSocketAddress &&
+13:         !((InetSocketAddress) localAddress).getAddress().isAnyLocalAddress() &&
+14:         !PlatformDependent.isWindows() && !PlatformDependent.maybeSuperUser()) {
+15:         // Warn a user about the fact that a non-root user can't receive a
+16:         // broadcast packet on *nix if the socket is bound on non-wildcard address.
+17:         logger.warn(
+18:                 "A non-root user can't receive a broadcast packet if the socket " +
+19:                 "is not bound to a wildcard address; binding to a non-wildcard " +
+20:                 "address (" + localAddress + ") anyway as requested.");
+21:     }
+22: 
+23:     // 记录 Channel 是否激活
+24:     boolean wasActive = isActive();
+25: 
+26:     // 绑定 Channel 的端口
+27:     try {
+28:         doBind(localAddress);
+29:     } catch (Throwable t) {
+30:         safeSetFailure(promise, t);
+31:         closeIfClosed();
+32:         return;
+33:     }
+34: 
+35:     // 若 Channel 是新激活的，触发通知 Channel 已激活的事件。
+36:     if (!wasActive && isActive()) {
+37:         invokeLater(new Runnable() {
+38:             @Override
+39:             public void run() {
+40:                 pipeline.fireChannelActive();
+41:             }
+42:         });
+43:     }
+44: 
+45:     // 回调通知 promise 执行成功
+46:     safeSetSuccess(promise);
+47: }
+```
+
+- 第 4 行：调用 `#assertEventLoop()` 方法，判断是否在 EventLoop 的线程中。即该方法，只允许在 EventLoop 的线程中执行。代码如下：
+
+  ```
+  // AbstractUnsafe.java
+  private void assertEventLoop() {
+      assert !registered || eventLoop.inEventLoop();
+  }
+  ```
+
+- 第 6 至 8 行：和 `#register0(...)` 方法的【第 5 至 8 行】的代码，是一致的。
+
+- 第 10 至 21 行：https://github.com/netty/netty/issues/576
+
+- 第 24 行：调用 `#isActive()` 方法，获得 Channel 是否激活( active )。NioServerSocketChannel 对该方法的实现代码如下：
+
+  ```
+  // NioServerSocketChannel.java
+  
+  @Override
+  public boolean isActive() {
+      return javaChannel().socket().isBound();
+  }
+  ```
+
+  - NioServerSocketChannel 的 `#isActive()` 的方法实现，判断 ServerSocketChannel 是否绑定端口。此时，一般返回的是 `false` 。
+
+- 第 28 行：调用 `#doBind(SocketAddress localAddress)` 方法，绑定 Channel 的端口。代码如下：
+
+  ```
+  // NioServerSocketChannel.java
+  
+  @Override
+  protected void doBind(SocketAddress localAddress) throws Exception {
+      if (PlatformDependent.javaVersion() >= 7) {
+          javaChannel().bind(localAddress, config.getBacklog());
+      } else {
+          javaChannel().socket().bind(localAddress, config.getBacklog());
+      }
+  }
+  ```
+
+  - 【重要】到了此处，服务端的 Java 原生 NIO ServerSocketChannel 终于绑定端口。😈
+
+- 第 36 行：再次调用 `#isActive()` 方法，获得 Channel 是否激活。此时，一般返回的是 `true` 。因此，Channel 可以认为是**新激活**的，满足【第 36 至 43 行】代码的执行条件。
+
+  - 第 37 行：调用 `#invokeLater(Runnable task)` 方法，提交任务，让【第 40 行】的代码执行，异步化。代码如下：
+
+    ```
+    // AbstractUnsafe.java
+    private void invokeLater(Runnable task) {
+        try {
+            // This method is used by outbound operation implementations to trigger an inbound event later.
+            // They do not trigger an inbound event immediately because an outbound operation might have been
+            // triggered by another inbound event handler method.  If fired immediately, the call stack
+            // will look like this for example:
+            //
+            //   handlerA.inboundBufferUpdated() - (1) an inbound handler method closes a connection.
+            //   -> handlerA.ctx.close()
+            //      -> channel.unsafe.close()
+            //         -> handlerA.channelInactive() - (2) another inbound handler method called while in (1) yet
+            //
+            // which means the execution of two inbound handler methods of the same handler overlap undesirably.
+            eventLoop().execute(task);
+        } catch (RejectedExecutionException e) {
+            logger.warn("Can't invoke task later as EventLoop rejected it", e);
+        }
+    }
+    ```
+
+    - 从实现代码可以看出，是通过提交一个新的任务到 EventLoop 的线程中。
+    - 英文注释虽然有丢丢长，但是胖友耐心看完。有道在手，英文不愁啊。
+
+  - 第 40 行：调用 `DefaultChannelPipeline#fireChannelActive()` 方法，触发 Channel 激活的事件。详细解析，见 [「3.13.3 beginRead」](https://svip.iocoder.cn/Netty/bootstrap-1-server/#) 。
+
+- 第 46 行：调用 `#safeSetSuccess(ChannelPromise)` 方法，回调通知 `promise` 执行成功。此处的通知，对应回调的是我们添加到 `#bind(...)` 方法返回的 ChannelFuture 的 ChannelFutureListener 的监听器。示例代码如下：
+
+  ```
+  ChannelFuture f = b.bind(PORT).addListener(new ChannelFutureListener() { // 回调的就是我！！！
+      @Override
+      public void operationComplete(ChannelFuture future) throws Exception {
+          System.out.println("测试下被触发");
+      }
+  }).sync();
+  ```
+
+### 3.13.3 beginRead
+
+> 老艿艿：此小节的内容，胖友先看完 [「3.14 initAndRegister」](https://svip.iocoder.cn/Netty/bootstrap-1-server/#) 的内容在回过头来看。因为 `#beginRead(...)` 方法的执行，在 `#doBind0(...)` 方法之后。
+
+在 `#bind(final SocketAddress localAddress, final ChannelPromise promise)` 方法的【第 40 行】代码，调用 `Channel#bind(SocketAddress localAddress, ChannelPromise promise)` 方法，触发 Channel 激活的事件。后续的方法栈调用如下图：[![触发 Channel 激活的事件](11-Netty 源码分析-启动（一）之服务端.assets/10.png)](http://static.iocoder.cn/images/Netty/2018_04_01/10.png)触发 Channel 激活的事件
+
+```
+* 还是老样子，我们先省略掉 pipeline 的内部实现代码，从 `AbstractUnsafe#beginRead()` 方法，继续向下分享。
+```
+
+`AbstractUnsafe#beginRead()` 方法，开始读取操作。代码如下：
+
+```
+@Override
+public final void beginRead() {
+    // 判断是否在 EventLoop 的线程中。
+    assertEventLoop();
+
+    // Channel 必须激活
+    if (!isActive()) {
+        return;
+    }
+
+    // 执行开始读取
+    try {
+        doBeginRead();
+    } catch (final Exception e) {
+        invokeLater(new Runnable() {
+            @Override
+            public void run() {
+                pipeline.fireExceptionCaught(e);
+            }
+        });
+        close(voidPromise());
+    }
+}
+```
+
+- 调用 `Channel#doBeginRead()` 方法，执行开始读取。对于 NioServerSocketChannel 来说，该方法实现代码如下：
+
+  ```
+  // AbstractNioMessageChannel.java
+  @Override
+  protected void doBeginRead() throws Exception {
+      if (inputShutdown) {
+          return;
+      }
+      super.doBeginRead();
+  }
+  
+  // AbstractNioChannel.java
+  @Override
+  protected void doBeginRead() throws Exception {
+      // Channel.read() or ChannelHandlerContext.read() was called
+      final SelectionKey selectionKey = this.selectionKey;
+      if (!selectionKey.isValid()) {
+          return;
+      }
+  
+      readPending = true;
+  
+      final int interestOps = selectionKey.interestOps();
+      if ((interestOps & readInterestOp) == 0) {
+          selectionKey.interestOps(interestOps | readInterestOp);
+      }
+  }
+  ```
+
+  - 【重要】在最后几行，我们可以看到，调用 `SelectionKey#interestOps(ops)` 方法，将我们创建 NioServerSocketChannel 时，设置的 `readInterestOp = SelectionKey.OP_ACCEPT` 添加为感兴趣的事件。也就说，服务端可以开始处理客户端的连接事件。
+
+## 3.14 initAndRegister
+
+`#initAndRegister()` 方法，初始化并注册一个 Channel 对象，并返回一个 ChannelFuture 对象。代码如下：
+
+```
+  1: final ChannelFuture initAndRegister() {
+ 2:     Channel channel = null;
+ 3:     try {
+ 4:         // 创建 Channel 对象
+ 5:         channel = channelFactory.newChannel();
+ 6:         // 初始化 Channel 配置
+ 7:         init(channel);
+ 8:     } catch (Throwable t) {
+ 9:         if (channel != null) { // 已创建 Channel 对象
+10:             // channel can be null if newChannel crashed (eg SocketException("too many open files"))
+11:             channel.unsafe().closeForcibly(); // 强制关闭 Channel
+12:             // as the Channel is not registered yet we need to force the usage of the GlobalEventExecutor
+13:             return new DefaultChannelPromise(channel, GlobalEventExecutor.INSTANCE).setFailure(t);
+14:         }
+15:         // as the Channel is not registered yet we need to force the usage of the GlobalEventExecutor
+16:         return new DefaultChannelPromise(new FailedChannel(), GlobalEventExecutor.INSTANCE).setFailure(t);
+17:     }
+18: 
+19:     // 注册 Channel 到 EventLoopGroup 中
+20:     ChannelFuture regFuture = config().group().register(channel);
+21:     if (regFuture.cause() != null) {
+22:         if (channel.isRegistered()) {
+23:             channel.close();
+24:         } else {
+25:             channel.unsafe().closeForcibly(); // 强制关闭 Channel
+26:         }
+27:     }
+28: 
+29:     return regFuture;
+30: }
+```
+
+- 第 5 行：调用
+
+   
+
+  ```
+  ChannelFactory#newChannel()
+  ```
+
+   
+
+  方法，创建 Channel 对象。在本文的示例中，会使用 ReflectiveChannelFactory 创建 NioServerSocketChannel 对象。详细解析，见
+
+   
+
+  「3.14.1 创建 Channel」
+
+   
+
+  。
+
+  - 第 16 行：返回带异常的 DefaultChannelPromise 对象。因为创建 Channel 对象失败，所以需要创建一个 FailedChannel 对象，设置到 DefaultChannelPromise 中才可以返回。
+
+- 第 7 行：调用
+
+   
+
+  ```
+  #init(Channel)
+  ```
+
+   
+
+  方法，初始化 Channel 配置。详细解析，见
+
+   
+
+  「3.14.1 创建 Channel」
+
+   
+
+  。
+
+  - 第 9 至 14 行：返回带异常的 DefaultChannelPromise 对象。因为初始化 Channel 对象失败，所以需要调用 `#closeForcibly()` 方法，强制关闭 Channel 。
+
+- 第 20 行：首先获得 EventLoopGroup 对象，后调用 `EventLoopGroup#register(Channel)` 方法，注册 Channel 到 EventLoopGroup 中。实际在方法内部，EventLoopGroup 会分配一个 EventLoop 对象，将 Channel 注册到其上。详细解析，见 [「3.14.3 注册 Channel 到 EventLoopGroup」](https://svip.iocoder.cn/Netty/bootstrap-1-server/#) 。
+
+  - 第 22 至 23 行：若发生异常，并且 Channel 已经注册成功，则调用 `#close()` 方法，正常关闭 Channel 。
+
+  - 第 24 至 26 行：若发生异常，并且 Channel 并未注册成功，则调用 `#closeForcibly()` 方法，强制关闭 Channel 。也就是说，和【第 9 至 14 行】一致。为什么会有正常和强制关闭 Channel 两种不同的处理呢？我们来看下 `#close()` 和 `#closeForcibly()` 方法的注释：
+
+    ```
+    // Channel.java#Unsafe
+    
+    /**
+     * Close the {@link Channel} of the {@link ChannelPromise} and notify the {@link ChannelPromise} once the
+     * operation was complete.
+     */
+    void close(ChannelPromise promise);
+    
+    /**
+     * Closes the {@link Channel} immediately without firing any events.  Probably only useful
+     * when registration attempt failed.
+     */
+    void closeForcibly();
+    ```
+
+    - 调用的前提，在于 Channel 是否注册到 EventLoopGroup 成功。😈 因为注册失败，也不好触发相关的事件。
+
+### 3.14.1 创建 Channel 对象
+
+考虑到本文的内容，我们以 NioServerSocketChannel 的创建过程作为示例。流程图如下：
+
+[![创建 NioServerSocketChannel 对象](11-Netty 源码分析-启动（一）之服务端.assets/05.png)](http://static.iocoder.cn/images/Netty/2018_04_01/05.png)创建 NioServerSocketChannel 对象
+
+- 我们可以看到，整个流程涉及到 NioServerSocketChannel 的父类们。类图如下：[![Channel 类图](11-Netty 源码分析-启动（一）之服务端.assets/06.png)](http://static.iocoder.cn/images/Netty/2018_04_01/06.png)Channel 类图
+
+- 可能有部分胖友对 Netty Channel 的定义不是很理解，如下是官方的英文注释：
+
+  > A nexus to a network socket or a component which is capable of I/O operations such as read, write, connect, and bind
+
+  - 简单点来说，我们可以把 Netty Channel 和 Java 原生 Socket 对应，而 Netty NIO Channel 和 Java 原生 NIO SocketChannel 对象。
+
+下面，我们来看看整个 NioServerSocketChannel 的创建过程的代码实现。
+
+#### 3.14.1.1 NioServerSocketChannel
+
+```
+private static final SelectorProvider DEFAULT_SELECTOR_PROVIDER = SelectorProvider.provider();
+
+private final ServerSocketChannelConfig config;
+
+public NioServerSocketChannel() {
+    this(newSocket(DEFAULT_SELECTOR_PROVIDER));
+}
+
+public NioServerSocketChannel(SelectorProvider provider) {
+    this(newSocket(provider));
+}
+```
+
+- `DEFAULT_SELECTOR_PROVIDER` **静态**属性，默认的 SelectorProvider 实现类。
+
+- `config` 属性，Channel 对应的配置对象。每种 Channel 实现类，也会对应一个 ChannelConfig 实现类。例如，NioServerSocketChannel 类，对应 ServerSocketChannelConfig 配置类。
+
+  > ChannelConfig 的官网英文描述： A set of configuration properties of a Channel.
+
+- 在构造方法中，调用 `#newSocket(SelectorProvider provider)` 方法，创建 NIO 的 ServerSocketChannel 对象。代码如下：
+
+  ```
+  private static ServerSocketChannel newSocket(SelectorProvider provider) {
+      try {
+          return provider.openServerSocketChannel();
+      } catch (IOException e) {
+          throw new ChannelException("Failed to open a server socket.", e);
+      }
+  }
+  ```
+
+  - 😈 是不是很熟悉这样的代码，效果和 `ServerSocketChannel#open()` 方法创建 ServerSocketChannel 对象是一致。
+
+- `#NioServerSocketChannel(ServerSocketChannel channel)` 构造方法，代码如下：
+
+  ```
+  public NioServerSocketChannel(ServerSocketChannel channel) {
+      super(null, channel, SelectionKey.OP_ACCEPT);
+      config = new NioServerSocketChannelConfig(this, javaChannel().socket());
+  }
+  ```
+
+  - 调用父 AbstractNioMessageChannel 的构造方法。详细解析，见 [「3.14.1.2 AbstractNioMessageChannel」](https://svip.iocoder.cn/Netty/bootstrap-1-server/#) 。注意传入的 SelectionKey 的值为 `OP_ACCEPT` 。
+  - 初始化 `config` 属性，创建 NioServerSocketChannelConfig 对象。
+
+#### 3.14.1.2 AbstractNioMessageChannel
+
+```
+protected AbstractNioMessageChannel(Channel parent, SelectableChannel ch, int readInterestOp) {
+    super(parent, ch, readInterestOp);
+}
+```
+
+- 直接调用父 AbstractNioChannel 的构造方法。详细解析，见 [「3.14.1.3 AbstractNioChannel」](https://svip.iocoder.cn/Netty/bootstrap-1-server/#) 。
+
+#### 3.14.1.3 AbstractNioChannel
+
+```
+private final SelectableChannel ch;
+protected final int readInterestOp;
+
+protected AbstractNioChannel(Channel parent, SelectableChannel ch, int readInterestOp) {
+    super(parent);
+    this.ch = ch;
+    this.readInterestOp = readInterestOp;
+    try {
+        ch.configureBlocking(false);
+    } catch (IOException e) {
+        try {
+            ch.close();
+        } catch (IOException e2) {
+            if (logger.isWarnEnabled()) {
+                logger.warn("Failed to close a partially initialized socket.", e2);
+            }
+        }
+
+        throw new ChannelException("Failed to enter non-blocking mode.", e);
+    }
+}
+```
+
+- `ch` 属性，**Netty NIO Channel 对象，持有的 Java 原生 NIO 的 Channel 对象**。
+
+- ```
+  readInterestOp
+  ```
+
+   
+
+  属性，感兴趣的读事件的操作位值。
+
+  - 目前笔者看了 AbstractNioMessageChannel 是 `SelectionKey.OP_ACCEPT` ， 而 AbstractNioByteChannel 是 `SelectionKey.OP_READ` 。
+  - 详细的用途，我们会在 [「3.13.3 beginRead」](https://svip.iocoder.cn/Netty/bootstrap-1-server/#) 看到。
+
+- 调用父 AbstractNioChannel 的构造方法。详细解析，见 [「3.14.1.4 AbstractChannel」](https://svip.iocoder.cn/Netty/bootstrap-1-server/#) 。
+
+- 调用
+
+   
+
+  ```
+  SelectableChannel#configureBlocking(false)
+  ```
+
+   
+
+  方法，设置 NIO Channel 为
+
+  非阻塞
+
+  。😈 这块代码是不是非常熟悉哟。
+
+  - 若发生异常，关闭 NIO Channel ，并抛出异常。
+
+#### 3.14.1.4 AbstractChannel
+
+```
+/**
+ * 父 Channel 对象
+ */
+private final Channel parent;
+/**
+ * Channel 编号
+ */
+private final ChannelId id;
+/**
+ * Unsafe 对象
+ */
+private final Unsafe unsafe;
+/**
+ * DefaultChannelPipeline 对象
+ */
+private final DefaultChannelPipeline pipeline;
+
+protected AbstractChannel(Channel parent) {
+    this.parent = parent;
+    // 创建 ChannelId 对象
+    id = newId();
+    // 创建 Unsafe 对象
+    unsafe = newUnsafe();
+    // 创建 DefaultChannelPipeline 对象
+    pipeline = newChannelPipeline();
+}
+```
+
+- `parent` 属性，父 Channel 对象。对于 NioServerSocketChannel 的 `parent` 为空。
+
+- `id` 属性，Channel 编号对象。在构造方法中，通过调用 `#newId()` 方法，进行创建。本文就先不分享，感兴趣的胖友自己看。
+
+- `unsafe` 属性，Unsafe 对象。在构造方法中，通过调用 `#newUnsafe()` 方法，进行创建。本文就先不分享，感兴趣的胖友自己看。
+
+  - 这里的 Unsafe 并不是我们常说的 Java 自带的`sun.misc.Unsafe` ，而是 `io.netty.channel.Channel#Unsafe`。
+
+    ```
+    // Channel.java#Unsafe
+    /**
+    * <em>Unsafe</em> operations that should <em>never</em> be called from user-code. These methods
+    * are only provided to implement the actual transport, and must be invoked from an I/O thread except for the
+    * following methods:
+    * <ul>
+    *   <li>{@link #localAddress()}</li>
+    *   <li>{@link #remoteAddress()}</li>
+    *   <li>{@link #closeForcibly()}</li>
+    *   <li>{@link #register(EventLoop, ChannelPromise)}</li>
+    *   <li>{@link #deregister(ChannelPromise)}</li>
+    *   <li>{@link #voidPromise()}</li>
+    * </ul>
+    */
+    ```
+
+    - 这就是为什么叫 Unsafe 的原因。按照上述官网类的英文注释，Unsafe 操作不允许被用户代码使用。这些函数是真正用于数据传输操作，必须被IO线程调用。
+    - 实际上，Channel 真正的具体操作，通过调用对应的 Unsafe 实现。😈 下文，我们将会看到。
+
+  - Unsafe 不是一个具体的类，而是一个定义在 Channel 接口中的接口。不同的 Channel 类对应不同的 Unsafe 实现类。整体类图如下：
+
+    ![Unsafe 类图](11-Netty 源码分析-启动（一）之服务端.assets/07.png)
+
+    Unsafe 类图
+
+    - 对于 NioServerSocketChannel ，Unsafe 的实现类为 NioMessageUnsafe 。
+
+- `pipeline` 属性，DefaultChannelPipeline 对象。在构造方法中，通过调用 `#newChannelPipeline()` 方法，进行创建。本文就先不分享，感兴趣的胖友自己看。
+
+  > ChannelPipeline 的英文注释：A list of ChannelHandlers which handles or intercepts inbound events and outbound operations of a Channel 。
+
+#### 3.14.1.5 小结
+
+看到此处，我们来对 [「3.1.4.1 创建 Channel 对象」](https://svip.iocoder.cn/Netty/bootstrap-1-server/#) 作一个小结。
+
+对于一个 Netty NIO Channel 对象，它会包含如下几个核心组件：
+
+- ChannelId
+- Unsafe
+- Pipeline
+  - ChannelHandler
+- ChannelConfig
+- **Java 原生 NIO Channel**
+
+如果不太理解，可以撸起袖子，多调试几次。
+
+### 3.14.2 初始化 Channel 配置
+
+`#init(Channel channel)` 方法，初始化 Channel 配置。它是个**抽象**方法，由子类 ServerBootstrap 或 Bootstrap 自己实现。代码如下：
+
+```
+abstract void init(Channel channel) throws Exception;
+```
+
+- ServerBootstrap 对该方法的实现，我们在 [「4. ServerBootstrap」](https://svip.iocoder.cn/Netty/bootstrap-1-server/#) 中，详细解析。
+
+### 3.14.3 注册 Channel 到 EventLoopGroup
+
+`EventLoopGroup#register(Channel channel)` 方法，注册 Channel 到 EventLoopGroup 中。整体流程如下：
+
+[![register 流程](11-Netty 源码分析-启动（一）之服务端.assets/08.png)](http://static.iocoder.cn/images/Netty/2018_04_01/08.png)register 流程
+
+#### 3.14.3.1 register
+
+EventLoopGroup 和 EventLoop 不是本文的重点，所以省略 1 + 2 + 3 部分的代码，从第 4 步的 `AbstractUnsafe#register(EventLoop eventLoop, final ChannelPromise promise)` 方法开始，代码如下：
+
+```
+ 1: @Override
+ 2: public final void register(EventLoop eventLoop, final ChannelPromise promise) {
+ 3:     // 校验传入的 eventLoop 非空
+ 4:     if (eventLoop == null) {
+ 5:         throw new NullPointerException("eventLoop");
+ 6:     }
+ 7:     // 校验未注册
+ 8:     if (isRegistered()) {
+ 9:         promise.setFailure(new IllegalStateException("registered to an event loop already"));
+10:         return;
+11:     }
+12:     // 校验 Channel 和 eventLoop 匹配
+13:     if (!isCompatible(eventLoop)) {
+14:         promise.setFailure(new IllegalStateException("incompatible event loop type: " + eventLoop.getClass().getName()));
+15:         return;
+16:     }
+17: 
+18:     // 设置 Channel 的 eventLoop 属性
+19:     AbstractChannel.this.eventLoop = eventLoop;
+20: 
+21:     // 在 EventLoop 中执行注册逻辑
+22:     if (eventLoop.inEventLoop()) {
+23:         register0(promise);
+24:     } else {
+25:         try {
+26:             eventLoop.execute(new Runnable() {
+27:                 @Override
+28:                 public void run() {
+31:                     register0(promise);
+32:                 }
+33:             });
+34:         } catch (Throwable t) {
+35:             logger.warn("Force-closing a channel whose registration task was not accepted by an event loop: {}", AbstractChannel.this, t);
+36:             closeForcibly();
+37:             closeFuture.setClosed();
+38:             safeSetFailure(promise, t);
+39:         }
+40:     }
+41: }
+```
+
+- 第 3 至 6 行：校验传入的 `eventLoop` 参数非空。
+
+- 第 7 至 11 行：调用 `#isRegistered()` 方法，校验未注册。代码如下：
+
+  ```
+  // AbstractChannel.java
+  
+  /**
+   * 是否注册
+   */
+  private volatile boolean registered;
+  
+  @Override
+  public boolean isRegistered() {
+      return registered;
+  }
+  ```
+
+- 第 12 至 16 行：校验 Channel 和 `eventLoop` 类型是否匹配，因为它们都有多种实现类型。代码如下：
+
+  ```
+  @Override
+  protected boolean isCompatible(EventLoop loop) {
+      return loop instanceof NioEventLoop;
+  }
+  ```
+
+  - 要求 `eventLoop` 的类型为 NioEventLoop 。
+
+- 第 19 行：【重要】设置 Channel 的 `eventLoop` 属性。
+
+- 第 21 至 40 行：在
+
+   
+
+  ```
+  evnetLoop
+  ```
+
+   
+
+  中，调用
+
+   
+
+  ```
+  #register0()
+  ```
+
+   
+
+  方法，执行注册的逻辑。详细解析，见
+
+   
+
+  「3.14.3.2 register0」
+
+   
+
+  。
+
+  - 第 34 至 39 行：若调用
+
+     
+
+    ```
+    EventLoop#execute(Runnable)
+    ```
+
+     
+
+    方法发生异常，则进行处理：
+
+    - 第 36 行：调用 `AbstractUnsafe#closeForcibly()` 方法，强制关闭 Channel 。
+    - 第 37 行：调用 `CloseFuture#setClosed()` 方法，通知 `closeFuture` 已经关闭。详细解析，见 [《精尽 Netty 源码解析 —— Channel（七）之 close 操作》](http://svip.iocoder.cn/Netty/Channel-7-close/) 。
+    - 第 38 行：调用 `AbstractUnsafe#safeSetFailure(ChannelPromise promise, Throwable cause)` 方法，回调通知 `promise` 发生该异常。
+
+#### 3.14.3.2 register0
+
+`#register0(ChannelPromise promise)` 方法，注册逻辑。代码如下：
+
+```
+ 1: private void register0(ChannelPromise promise) {
+ 2:     try {
+ 3:         // check if the channel is still open as it could be closed in the mean time when the register
+ 4:         // call was outside of the eventLoop
+ 5:         if (!promise.setUncancellable() // TODO 1001 Promise
+ 6:                 || !ensureOpen(promise)) { // 确保 Channel 是打开的
+ 7:             return;
+ 8:         }
+ 9:         // 记录是否为首次注册
+10:         boolean firstRegistration = neverRegistered;
+11: 
+12:         // 执行注册逻辑
+13:         doRegister();
+14: 
+15:         // 标记首次注册为 false
+16:         neverRegistered = false;
+17:         // 标记 Channel 为已注册
+18:         registered = true;
+19: 
+20:         // Ensure we call handlerAdded(...) before we actually notify the promise. This is needed as the
+21:         // user may already fire events through the pipeline in the ChannelFutureListener.
+22:         pipeline.invokeHandlerAddedIfNeeded();
+23: 
+24:         // 回调通知 `promise` 执行成功
+25:         safeSetSuccess(promise);
+26: 
+27:         // 触发通知已注册事件
+28:         pipeline.fireChannelRegistered();
+29: 
+30:         // TODO 芋艿
+31:         // Only fire a channelActive if the channel has never been registered. This prevents firing
+32:         // multiple channel actives if the channel is deregistered and re-registered.
+33:         if (isActive()) {
+34:             if (firstRegistration) {
+35:                 pipeline.fireChannelActive();
+36:             } else if (config().isAutoRead()) {
+37:                 // This channel was registered before and autoRead() is set. This means we need to begin read
+38:                 // again so that we process inbound data.
+39:                 //
+40:                 // See https://github.com/netty/netty/issues/4805
+41:                 beginRead();
+42:             }
+43:         }
+44:     } catch (Throwable t) {
+45:         // Close the channel directly to avoid FD leak.
+46:         closeForcibly();
+47:         closeFuture.setClosed();
+48:         safeSetFailure(promise, t);
+49:     }
+50: }
+```
+
+- 第 5 行：// TODO 1001 Promise
+
+- 第 6 行：调用 `#ensureOpen(ChannelPromise)` 方法，确保 Channel 是打开的。代码如下：
+
+  ```
+  // AbstractUnsafe.java
+  protected final boolean ensureOpen(ChannelPromise promise) {
+      if (isOpen()) {
+          return true;
+      }
+  
+      // 若未打开，回调通知 promise 异常
+      safeSetFailure(promise, ENSURE_OPEN_CLOSED_CHANNEL_EXCEPTION);
+      return false;
+  }
+  
+  // AbstractNioChannel.java
+  @Override
+  public boolean isOpen() {
+      return ch.isOpen();
+  }
+  ```
+
+- 第 10 行：记录是否**首次**注册。`neverRegistered` 变量声明在 AbstractUnsafe 中，代码如下：
+
+  ```
+  /**
+   * 是否重未注册过，用于标记首次注册
+   *
+   * true if the channel has never been registered, false otherwise
+   */
+  private boolean neverRegistered = true;
+  ```
+
+- 第 13 行：调用 `#doRegister()` 方法，执行注册逻辑。代码如下：
+
+  ```
+  // NioUnsafe.java
+    1: @Override
+    2: protected void doRegister() throws Exception {
+    3:     boolean selected = false;
+    4:     for (;;) {
+    5:         try {
+    6:             selectionKey = javaChannel().register(eventLoop().unwrappedSelector(), 0, this);
+    7:             return;
+    8:         } catch (CancelledKeyException e) {
+    9:             // TODO TODO 1003 doRegister 异常
+   10:             if (!selected) {
+   11:                 // Force the Selector to select now as the "canceled" SelectionKey may still be
+   12:                 // cached and not removed because no Select.select(..) operation was called yet.
+   13:                 eventLoop().selectNow();
+   14:                 selected = true;
+   15:             } else {
+   16:                 // We forced a select operation on the selector before but the SelectionKey is still cached
+   17:                 // for whatever reason. JDK bug ?
+   18:                 throw e;
+   19:             }
+   20:         }
+   21:     }
+   22: }
+  ```
+
+  - 第 6 行：调用 `#unwrappedSelector()` 方法，返回 Java 原生 NIO Selector 对象。代码如下：
+
+    ```
+    // NioEventLoop.java
+    
+    private Selector unwrappedSelector;
+    
+    Selector unwrappedSelector() {
+        return unwrappedSelector;
+    }
+    ```
+
+    - 每个 NioEventLoop 对象上，都**独有**一个 Selector 对象。
+
+  - 第 6 行：调用 `#javaChannel()` 方法，获得 Java 原生 NIO 的 Channel 对象。
+
+  - 第 6 行：【重要】调用 `SelectableChannel#register(Selector sel, int ops, Object att)` 方法，注册 Java 原生 NIO 的 Channel 对象到 Selector 对象上。相信胖友对这块的代码是非常熟悉的，但是为什么感兴趣的事件是为 **0** 呢？正常情况下，对于服务端来说，需要注册 `SelectionKey.OP_ACCEPT` 事件呢！这样做的**目的**是( 摘自《Netty权威指南（第二版）》 )：
+
+    > 1. 注册方式是多态的，它既可以被 NIOServerSocketChannel 用来监听客户端的连接接入，也可以注册 SocketChannel 用来监听网络读或者写操作。
+    >
+    > 2. 通过
+    >
+    >     
+    >
+    >    ```
+    >    SelectionKey#interestOps(int ops)
+    >    ```
+    >
+    >     
+    >
+    >    方法可以方便地修改监听操作位。所以，此处注册需要获取 SelectionKey 并给 AbstractNIOChannel 的成员变量
+    >
+    >     
+    >
+    >    ```
+    >    selectionKey
+    >    ```
+    >
+    >     
+    >
+    >    赋值。
+    >
+    >    - 如果不理解，没关系，在下文中，我们会看到服务端对 `SelectionKey.OP_ACCEPT` 事件的关注。😈
+
+  - 第 8 至 20 行：TODO 1003 doRegister 异常
+
+- 第 16 行：标记首次注册为 `false` 。
+
+- 第 18 行：标记 Channel 为已注册。`registered` 变量声明在 AbstractChannel 中，代码如下：
+
+  ```
+  /**
+   * 是否注册
+   */
+  private volatile boolean registered;
+  ```
+
+- 第 22 行：调用 `DefaultChannelPipeline#invokeHandlerAddedIfNeeded()` 方法，触发 ChannelInitializer 执行，进行 Handler 初始化。也就是说，我们在 [「4.init」](https://svip.iocoder.cn/Netty/bootstrap-1-server/#) 写的 ServerBootstrap 对 Channel 设置的 ChannelInitializer 将被执行，进行 Channel 的 Handler 的初始化。
+
+  - 具体的 pipeline 的内部调用过程，我们在后续文章分享。
+
+- 第 25 行：调用 `#safeSetSuccess(ChannelPromise promise)` 方法，回调通知 `promise` 执行。在 [「3.13.1 doBind」](https://svip.iocoder.cn/Netty/bootstrap-1-server/#) 小节，我们向 `regFuture` 注册的 ChannelFutureListener ，就会被**立即回调执行**。
+
+  > 老艿艿：胖友在看完这小节的内容，可以调回 [「3.13.2 doBind0」](https://svip.iocoder.cn/Netty/bootstrap-1-server/#) 小节的内容继续看。
+
+- 第 28 行：调用 `DefaultChannelPipeline#invokeHandlerAddedIfNeeded()` 方法，触发通知 Channel 已注册的事件。
+
+  - 具体的 pipeline 的内部调用过程，我们在后续文章分享。
+  - 笔者目前调试下来，没有涉及服务端启动流程的逻辑代码。
+
+- 第 33 至 43 行：TODO 芋艿
+
+- 第 44 至 49 行：发生异常，和 `#register(EventLoop eventLoop, final ChannelPromise promise)` 方法的处理异常的代码，是一致的。
+
+# 4. ServerBootstrap
+
+`io.netty.bootstrap.ServerBootstrap` ，实现 AbstractBootstrap 抽象类，用于 Server 的启动器实现类。
+
+## 4.1 构造方法
+
+```
+/**
+ * 启动类配置对象
+ */
+private final ServerBootstrapConfig config = new ServerBootstrapConfig(this);
+/**
+ * 子 Channel 的可选项集合
+ */
+private final Map<ChannelOption<?>, Object> childOptions = new LinkedHashMap<ChannelOption<?>, Object>();
+/**
+ * 子 Channel 的属性集合
+ */
+private final Map<AttributeKey<?>, Object> childAttrs = new LinkedHashMap<AttributeKey<?>, Object>();
+/**
+ * 子 Channel 的 EventLoopGroup 对象
+ */
+private volatile EventLoopGroup childGroup;
+/**
+ * 子 Channel 的处理器
+ */
+private volatile ChannelHandler childHandler;
+
+public ServerBootstrap() { }
+
+private ServerBootstrap(ServerBootstrap bootstrap) {
+    super(bootstrap);
+    childGroup = bootstrap.childGroup;
+    childHandler = bootstrap.childHandler;
+    synchronized (bootstrap.childOptions) {
+        childOptions.putAll(bootstrap.childOptions);
+    }
+    synchronized (bootstrap.childAttrs) {
+        childAttrs.putAll(bootstrap.childAttrs);
+    }
+}
+```
+
+- `config` 属性，ServerBootstrapConfig 对象，启动类配置对象。
+- 在 Server 接受**一个** Client 的连接后，会创建**一个**对应的 Channel 对象。因此，我们看到 ServerBootstrap 的 `childOptions`、`childAttrs`、`childGroup`、`childHandler` 属性，都是这种 Channel 的可选项集合、属性集合、EventLoopGroup 对象、处理器。下面，我们会看到 ServerBootstrap 针对这些配置项的设置方法。
+
+## 4.2 group
+
+`#group(..)` 方法，设置 EventLoopGroup 到 `group`、`childGroup` 中。代码如下：
+
+```
+@Override
+public ServerBootstrap group(EventLoopGroup group) {
+    return group(group, group);
+}
+
+public ServerBootstrap group(EventLoopGroup parentGroup, EventLoopGroup childGroup) {
+    super.group(parentGroup);
+    if (childGroup == null) {
+        throw new NullPointerException("childGroup");
+    }
+    if (this.childGroup != null) {
+        throw new IllegalStateException("childGroup set already");
+    }
+    this.childGroup = childGroup;
+    return this;
+}
+```
+
+- 当只传入一个 EventLoopGroup 对象时，即调用的是 `#group(EventLoopGroup group)` 时，`group` 和 `childGroup` 使用同一个。一般情况下，我们不使用这个方法。
+
+## 4.3 childOption
+
+`#childOption(ChannelOption<T> option, T value)` 方法，设置子 Channel 的可选项。代码如下：
+
+```
+public <T> ServerBootstrap childOption(ChannelOption<T> childOption, T value) {
+    if (childOption == null) {
+        throw new NullPointerException("childOption");
+    }
+    if (value == null) { // 空，意味着移除
+        synchronized (childOptions) {
+            childOptions.remove(childOption);
+        }
+    } else { // 非空，进行修改
+        synchronized (childOptions) {
+            childOptions.put(childOption, value);
+        }
+    }
+    return this;
+}
+```
+
+## 4.4 childAttr
+
+`#childAttr(AttributeKey<T> key, T value)` 方法，设置子 Channel 的属性。代码如下：
+
+```
+public <T> ServerBootstrap childAttr(AttributeKey<T> childKey, T value) {
+    if (childKey == null) {
+        throw new NullPointerException("childKey");
+    }
+    if (value == null) { // 空，意味着移除
+        childAttrs.remove(childKey);
+    } else { // 非空，进行修改
+        childAttrs.put(childKey, value);
+    }
+    return this;
+}
+```
+
+## 4.5 childHandler
+
+`#childHandler(ChannelHandler handler)` 方法，设置子 Channel 的处理器。代码如下：
+
+```
+public ServerBootstrap childHandler(ChannelHandler childHandler) {
+    if (childHandler == null) {
+        throw new NullPointerException("childHandler");
+    }
+    this.childHandler = childHandler;
+    return this;
+}
+```
+
+## 4.6 validate
+
+`#validate()` 方法，校验配置是否正确。代码如下：
+
+```
+@Override
+public ServerBootstrap validate() {
+    super.validate();
+    if (childHandler == null) {
+        throw new IllegalStateException("childHandler not set");
+    }
+    if (childGroup == null) {
+        logger.warn("childGroup is not set. Using parentGroup instead.");
+        childGroup = config.group();
+    }
+    return this;
+}
+```
+
+## 4.7 clone
+
+`#clone()` 方法，克隆 ServerBootstrap 对象。代码如下：
+
+```
+@Override
+public ServerBootstrap clone() {
+    return new ServerBootstrap(this);
+}
+```
+
+- 调用参数为 `bootstrap` 为 ServerBootstrap 构造方法，克隆一个 ServerBootstrap 对象。
+
+## 4.8 init
+
+`#init(Channel channel)` 方法，初始化 Channel 配置。代码如下：
+
+```
+1: @Override
+2: void init(Channel channel) throws Exception {
+3:     // 初始化 Channel 的可选项集合
+4:     final Map<ChannelOption<?>, Object> options = options0();
+5:     synchronized (options) {
+6:         setChannelOptions(channel, options, logger);
+7:     }
+8: 
+9:     // 初始化 Channel 的属性集合
+10:     final Map<AttributeKey<?>, Object> attrs = attrs0();
+11:     synchronized (attrs) {
+12:         for (Entry<AttributeKey<?>, Object> e: attrs.entrySet()) {
+13:             @SuppressWarnings("unchecked")
+14:             AttributeKey<Object> key = (AttributeKey<Object>) e.getKey();
+15:             channel.attr(key).set(e.getValue());
+16:         }
+17:     }
+18: 
+19:     ChannelPipeline p = channel.pipeline();
+20: 
+21:     // 记录当前的属性
+22:     final EventLoopGroup currentChildGroup = childGroup;
+23:     final ChannelHandler currentChildHandler = childHandler;
+24:     final Entry<ChannelOption<?>, Object>[] currentChildOptions;
+25:     final Entry<AttributeKey<?>, Object>[] currentChildAttrs;
+26:     synchronized (childOptions) {
+27:         currentChildOptions = childOptions.entrySet().toArray(newOptionArray(0));
+28:     }
+29:     synchronized (childAttrs) {
+30:         currentChildAttrs = childAttrs.entrySet().toArray(newAttrArray(0));
+31:     }
+32: 
+33:     // 添加 ChannelInitializer 对象到 pipeline 中，用于后续初始化 ChannelHandler 到 pipeline 中。
+34:     p.addLast(new ChannelInitializer<Channel>() {
+35:         @Override
+36:         public void initChannel(final Channel ch) throws Exception {
+38:             final ChannelPipeline pipeline = ch.pipeline();
+39: 
+40:             // 添加配置的 ChannelHandler 到 pipeline 中。
+41:             ChannelHandler handler = config.handler();
+42:             if (handler != null) {
+43:                 pipeline.addLast(handler);
+44:             }
+45: 
+46:             // 添加 ServerBootstrapAcceptor 到 pipeline 中。
+47:             // 使用 EventLoop 执行的原因，参见 https://github.com/lightningMan/netty/commit/4638df20628a8987c8709f0f8e5f3679a914ce1a
+48:             ch.eventLoop().execute(new Runnable() {
+49:                 @Override
+50:                 public void run() {
+52:                     pipeline.addLast(new ServerBootstrapAcceptor(
+53:                             ch, currentChildGroup, currentChildHandler, currentChildOptions, currentChildAttrs));
+54:                 }
+55:             });
+56:         }
+57:     });
+58: }}
+```
+
+- 第 3 至 7 行：将启动器配置的可选项集合，调用 `#setChannelOptions(channel, options, logger)` 方法，设置到 Channel 的可选项集合中。
+
+- 第 9 至 17 行：将启动器配置的属性集合，设置到 Channel 的属性集合中。
+
+- 第 21 至 31 行：记录启动器配置的**子 Channel**的属性，用于【第 52 至 53 行】的代码，创建 ServerBootstrapAcceptor 对象。
+
+- 第 34 至 57 行：创建 ChannelInitializer 对象，添加到 pipeline 中，用于后续初始化 ChannelHandler 到 pipeline 中。
+
+  - 第 40 至 44 行：添加启动器配置的 ChannelHandler 到 pipeline 中。
+
+  - 第 46 至 55 行：创建 ServerBootstrapAcceptor 对象，添加到 pipeline 中。为什么使用 EventLoop 执行**添加的过程**？如果启动器配置的处理器，并且 ServerBootstrapAcceptor 不使用 EventLoop 添加，则会导致 ServerBootstrapAcceptor 添加到配置的处理器之前。示例代码如下：
+
+    ```
+    ServerBootstrap b = new ServerBootstrap();
+    b.handler(new ChannelInitializer<Channel>() {
+    
+        @Override
+        protected void initChannel(Channel ch) {
+            final ChannelPipeline pipeline = ch.pipeline();
+            ch.eventLoop().execute(new Runnable() {
+                @Override
+                public void run() {
+                    pipeline.addLast(new LoggingHandler(LogLevel.INFO));
+                }
+            });
+        }
+    
+    });
+    ```
+
+    - Netty 官方的提交，可见 [github commit](https://github.com/lightningMan/netty/commit/4638df20628a8987c8709f0f8e5f3679a914ce1a) 。
+
+  - ServerBootstrapAcceptor 也是一个 ChannelHandler 实现类，用于接受客户端的连接请求。详细解析，见后续文章。
+
+  - 该 ChannelInitializer 的初始化的执行，在 `AbstractChannel#register0(ChannelPromise promise)` 方法中触发执行。
+
+  - 那么为什么要使用 ChannelInitializer 进行处理器的初始化呢？而不直接添加到 pipeline 中。例如修改为如下代码：
+
+    ```
+    final Channel ch = channel;
+    final ChannelPipeline pipeline = ch.pipeline();
+    
+    // 添加配置的 ChannelHandler 到 pipeline 中。
+    ChannelHandler handler = config.handler();
+    if (handler != null) {
+        pipeline.addLast(handler);
+    }
+    
+    // 添加 ServerBootstrapAcceptor 到 pipeline 中。
+    // 使用 EventLoop 执行的原因，参见 https://github.com/lightningMan/netty/commit/4638df20628a8987c8709f0f8e5f3679a914ce1a
+    ch.eventLoop().execute(new Runnable() {
+        @Override
+        public void run() {
+            System.out.println(Thread.currentThread() + ": ServerBootstrapAcceptor");
+            pipeline.addLast(new ServerBootstrapAcceptor(
+                    ch, currentChildGroup, currentChildHandler, currentChildOptions, currentChildAttrs));
+        }
+    });
+    ```
+
+    - 因为此时 Channel 并未注册到 EventLoop 中。如果调用 `EventLoop#execute(Runnable runnable)` 方法，会抛出 `Exception in thread "main" java.lang.IllegalStateException: channel not registered to an event loop` 异常。
+
+# 666. 彩蛋
+
+Netty 服务端启动涉及的流程非常多，所以有不理解的地方，胖友可以多多调试。在其中涉及到的 EventLoopGroup、EventLoop、Pipeline 等等组件，我们后在后续的文章，正式分享。
+
+另外，也推荐如下和 Netty 服务端启动相关的文章，以加深理解：
+
+- 闪电侠 [《Netty 源码分析之服务端启动全解析》](https://www.jianshu.com/p/c5068caab217)
+- 小明哥 [《【死磕 Netty 】—— 服务端启动过程分析》](http://cmsblogs.com/?p=2470)
+- 占小狼 [《Netty 源码分析之服务启动》](https://www.jianshu.com/p/e577803f0fb8)
+- 杨武兵 [《Netty 源码分析系列 —— Bootstrap》](https://my.oschina.net/ywbrj042/blog/868798)
+- 永顺 [《Netty 源码分析之 一 揭开 Bootstrap 神秘的红盖头 (服务器端)》](https://segmentfault.com/a/1190000007283053)
\ No newline at end of file
diff --git a/netty/12-Netty 源码分析-启动（二）之客户端.assets/01.png b/netty/12-Netty 源码分析-启动（二）之客户端.assets/01.png
new file mode 100644
index 0000000..9979521
Binary files /dev/null and b/netty/12-Netty 源码分析-启动（二）之客户端.assets/01.png differ
diff --git a/netty/12-Netty 源码分析-启动（二）之客户端.assets/02.png b/netty/12-Netty 源码分析-启动（二）之客户端.assets/02.png
new file mode 100644
index 0000000..7086af9
Binary files /dev/null and b/netty/12-Netty 源码分析-启动（二）之客户端.assets/02.png differ
diff --git a/netty/12-Netty 源码分析-启动（二）之客户端.assets/03.png b/netty/12-Netty 源码分析-启动（二）之客户端.assets/03.png
new file mode 100644
index 0000000..902c0b1
Binary files /dev/null and b/netty/12-Netty 源码分析-启动（二）之客户端.assets/03.png differ
diff --git a/netty/12-Netty 源码分析-启动（二）之客户端.md b/netty/12-Netty 源码分析-启动（二）之客户端.md
new file mode 100644
index 0000000..c3c04cd
--- /dev/null
+++ b/netty/12-Netty 源码分析-启动（二）之客户端.md	
@@ -0,0 +1,919 @@
+# 精尽 Netty 源码分析 —— 启动（二）之客户端
+
+# 1. 概述
+
+本文，我们来分享 Bootstrap 分享 Netty 客户端。因为我们日常使用 Netty 主要使用 NIO 部分，所以本文也只分享 Netty NIO 客户端。
+
+# 2. Bootstrap 示例
+
+下面，我们先来看一个 ServerBootstrap 的使用示例，就是我们在 [《精尽 Netty 源码分析 —— 调试环境搭建》](http://svip.iocoder.cn/Netty/build-debugging-environment/#5-2-EchoClient) 搭建的 EchoClient 示例。代码如下：
+
+```
+public final class EchoClient {
+
+    static final boolean SSL = System.getProperty("ssl") != null;
+    static final String HOST = System.getProperty("host", "127.0.0.1");
+    static final int PORT = Integer.parseInt(System.getProperty("port", "8007"));
+    static final int SIZE = Integer.parseInt(System.getProperty("size", "256"));
+
+    public static void main(String[] args) throws Exception {
+        // Configure SSL.git
+        // 配置 SSL
+        final SslContext sslCtx;
+        if (SSL) {
+            sslCtx = SslContextBuilder.forClient()
+                .trustManager(InsecureTrustManagerFactory.INSTANCE).build();
+        } else {
+            sslCtx = null;
+        }
+
+        // Configure the client.
+        // 创建一个 EventLoopGroup 对象
+        EventLoopGroup group = new NioEventLoopGroup();
+        try {
+            // 创建 Bootstrap 对象
+            Bootstrap b = new Bootstrap();
+            b.group(group) // 设置使用的 EventLoopGroup
+             .channel(NioSocketChannel.class) // 设置要被实例化的为 NioSocketChannel 类
+             .option(ChannelOption.TCP_NODELAY, true) // 设置 NioSocketChannel 的可选项
+             .handler(new ChannelInitializer<SocketChannel>() { // 设置 NioSocketChannel 的处理器
+                 @Override
+                 public void initChannel(SocketChannel ch) throws Exception {
+                     ChannelPipeline p = ch.pipeline();
+                     if (sslCtx != null) {
+                         p.addLast(sslCtx.newHandler(ch.alloc(), HOST, PORT));
+                     }
+                     //p.addLast(new LoggingHandler(LogLevel.INFO));
+                     p.addLast(new EchoClientHandler());
+                 }
+             });
+
+            // Start the client.
+            // 连接服务器，并同步等待成功，即启动客户端
+            ChannelFuture f = b.connect(HOST, PORT).sync();
+
+            // Wait until the connection is closed.
+            // 监听客户端关闭，并阻塞等待
+            f.channel().closeFuture().sync();
+        } finally {
+            // Shut down the event loop to terminate all threads.
+            // 优雅关闭一个 EventLoopGroup 对象
+            group.shutdownGracefully();
+        }
+    }
+}
+```
+
+- 示例比较简单，已经添加中文注释，胖友自己查看。
+
+# 3. Bootstrap
+
+`io.netty.bootstrap.Bootstrap` ，实现 AbstractBootstrap 抽象类，用于 Client 的启动器实现类。
+
+## 3.1 构造方法
+
+```
+/**
+ * 默认地址解析器对象
+ */
+private static final AddressResolverGroup<?> DEFAULT_RESOLVER = DefaultAddressResolverGroup.INSTANCE;
+
+/**
+ * 启动类配置对象
+ */
+private final BootstrapConfig config = new BootstrapConfig(this);
+/**
+ * 地址解析器对象
+ */
+@SuppressWarnings("unchecked")
+private volatile AddressResolverGroup<SocketAddress> resolver = (AddressResolverGroup<SocketAddress>) DEFAULT_RESOLVER;
+/**
+ * 连接地址
+ */
+private volatile SocketAddress remoteAddress;
+
+public Bootstrap() { }
+
+private Bootstrap(Bootstrap bootstrap) {
+    super(bootstrap);
+    resolver = bootstrap.resolver;
+    remoteAddress = bootstrap.remoteAddress;
+}
+```
+
+- `config` 属性，BootstrapConfig 对象，启动类配置对象。
+- `resolver` 属性，地址解析器对象。绝大多数情况下，使用 `DEFAULT_RESOLVER` 即可。
+- `remoteAddress` 属性，连接地址。
+
+## 3.2 resolver
+
+`#resolver(AddressResolverGroup<?> resolver)` 方法，设置 `resolver` 属性。代码如下：
+
+```
+public Bootstrap resolver(AddressResolverGroup<?> resolver) {
+    this.resolver = (AddressResolverGroup<SocketAddress>) (resolver == null ? DEFAULT_RESOLVER : resolver);
+    return this;
+}
+```
+
+## 3.3 remoteAddress
+
+`#remoteAddress(...)` 方法，设置 `remoteAddress` 属性。代码如下：
+
+```
+public Bootstrap resolver(AddressResolverGroup<?> resolver) {
+    this.resolver = (AddressResolverGroup<SocketAddress>) (resolver == null ? DEFAULT_RESOLVER : resolver);
+    return this;
+}
+
+public Bootstrap remoteAddress(SocketAddress remoteAddress) {
+    this.remoteAddress = remoteAddress;
+    return this;
+}
+
+public Bootstrap remoteAddress(String inetHost, int inetPort) {
+    remoteAddress = InetSocketAddress.createUnresolved(inetHost, inetPort);
+    return this;
+}
+
+public Bootstrap remoteAddress(InetAddress inetHost, int inetPort) {
+    remoteAddress = new InetSocketAddress(inetHost, inetPort);
+    return this;
+}
+```
+
+## 3.4 validate
+
+`#validate()` 方法，校验配置是否正确。代码如下：
+
+```
+@Override
+public Bootstrap validate() {
+    // 父类校验
+    super.validate();
+    // handler 非空
+    if (config.handler() == null) {
+        throw new IllegalStateException("handler not set");
+    }
+    return this;
+}
+```
+
+- 在 `#connect(...)` 方法中，连接服务端时，会调用该方法进行校验。
+
+## 3.5 clone
+
+`#clone(...)` 方法，克隆 Bootstrap 对象。代码如下：
+
+```
+@Override
+public Bootstrap clone() {
+    return new Bootstrap(this);
+}
+
+public Bootstrap clone(EventLoopGroup group) {
+    Bootstrap bs = new Bootstrap(this);
+    bs.group = group;
+    return bs;
+}
+```
+
+- 两个克隆方法，都是调用参数为 `bootstrap` 为 Bootstrap 构造方法，克隆一个 Bootstrap 对象。差别在于，下面的方法，多了对 `group` 属性的赋值。
+
+## 3.6 connect
+
+`#connect(...)` 方法，连接服务端，即启动客户端。代码如下：
+
+```
+public ChannelFuture connect() {
+    // 校验必要参数
+    validate();
+    SocketAddress remoteAddress = this.remoteAddress;
+    if (remoteAddress == null) {
+        throw new IllegalStateException("remoteAddress not set");
+    }
+    // 解析远程地址，并进行连接
+    return doResolveAndConnect(remoteAddress, config.localAddress());
+}
+
+public ChannelFuture connect(String inetHost, int inetPort) {
+    return connect(InetSocketAddress.createUnresolved(inetHost, inetPort));
+}
+
+public ChannelFuture connect(InetAddress inetHost, int inetPort) {
+    return connect(new InetSocketAddress(inetHost, inetPort));
+}
+
+public ChannelFuture connect(SocketAddress remoteAddress) {
+    // 校验必要参数
+    validate();
+    if (remoteAddress == null) {
+        throw new NullPointerException("remoteAddress");
+    }
+    // 解析远程地址，并进行连接
+    return doResolveAndConnect(remoteAddress, config.localAddress());
+}
+
+public ChannelFuture connect(SocketAddress remoteAddress, SocketAddress localAddress) {
+    // 校验必要参数
+    validate();
+    if (remoteAddress == null) {
+        throw new NullPointerException("remoteAddress");
+    }
+    // 解析远程地址，并进行连接
+    return doResolveAndConnect(remoteAddress, localAddress);
+}
+```
+
+- 该方法返回的是 ChannelFuture 对象，也就是**异步**的连接服务端，启动客户端。如果需要**同步**，则需要调用 `ChannelFuture#sync()` 方法。
+
+`#connect(...)` 方法，核心流程如下图：
+
+`#bind(...)` 方法，核心流程如下图：
+
+[![核心流程](12-Netty 源码分析-启动（二）之客户端.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_04_05/01.png)核心流程
+
+- 主要有 5 个步骤，下面我们来拆解代码，看看和我们在 [《精尽 Netty 源码分析 —— NIO 基础（五）之示例》](http://svip.iocoder.cn/Netty/nio-5-demo/?self) 的 NioClient 的代码，是**怎么对应**的。
+- 相比 `#bind(...)` 方法的流程，主要是**绿色**的 2 个步骤。
+
+### 3.6.1 doResolveAndConnect
+
+`#doResolveAndConnect(final SocketAddress remoteAddress, final SocketAddress localAddress)` 方法，代码如下：
+
+```
+ 1: private ChannelFuture doResolveAndConnect(final SocketAddress remoteAddress, final SocketAddress localAddress) {
+ 2:     // 初始化并注册一个 Channel 对象，因为注册是异步的过程，所以返回一个 ChannelFuture 对象。
+ 3:     final ChannelFuture regFuture = initAndRegister();
+ 4:     final Channel channel = regFuture.channel();
+ 5: 
+ 6:     if (regFuture.isDone()) {
+ 7:         // 若执行失败，直接进行返回。
+ 8:         if (!regFuture.isSuccess()) {
+ 9:             return regFuture;
+10:         }
+11:         // 解析远程地址，并进行连接
+12:         return doResolveAndConnect0(channel, remoteAddress, localAddress, channel.newPromise());
+13:     } else {
+14:         // Registration future is almost always fulfilled already, but just in case it's not.
+15:         final PendingRegistrationPromise promise = new PendingRegistrationPromise(channel);
+16:         regFuture.addListener(new ChannelFutureListener() {
+17: 
+18:             @Override
+19:             public void operationComplete(ChannelFuture future) throws Exception {
+20:                 // Directly obtain the cause and do a null check so we only need one volatile read in case of a
+21:                 // failure.
+22:                 Throwable cause = future.cause();
+23:                 if (cause != null) {
+24:                     // Registration on the EventLoop failed so fail the ChannelPromise directly to not cause an
+25:                     // IllegalStateException once we try to access the EventLoop of the Channel.
+26:                     promise.setFailure(cause);
+27:                 } else {
+28:                     // Registration was successful, so set the correct executor to use.
+29:                     // See https://github.com/netty/netty/issues/2586
+30:                     promise.registered();
+31: 
+32:                     // 解析远程地址，并进行连接
+33:                     doResolveAndConnect0(channel, remoteAddress, localAddress, promise);
+34:                 }
+35:             }
+36: 
+37:         });
+38:         return promise;
+39:     }
+40: }
+```
+
+- 第 3 行：调用
+
+   
+
+  ```
+  #initAndRegister()
+  ```
+
+   
+
+  方法，初始化并注册一个 Channel 对象。因为注册是
+
+  异步
+
+  的过程，所以返回一个 ChannelFuture 对象。详细解析，见
+
+   
+
+  「3.7 initAndRegister」
+
+   
+
+  。
+
+  - 第 6 至 10 行：若执行失败，直接进行返回 `regFuture` 对象。
+
+- 第 9 至 37 行：因为注册是
+
+  异步
+
+  的过程，有可能已完成，有可能未完成。所以实现代码分成了【第 12 行】和【第 13 至 37 行】分别处理已完成和未完成的情况。
+
+  - **核心**在【第 12 行】或者【第 33 行】的代码，调用 `#doResolveAndConnect0(final Channel channel, SocketAddress remoteAddress, final SocketAddress localAddress, final ChannelPromise promise)` 方法，解析远程地址，并进行连接。
+  - 如果**异步**注册对应的 ChanelFuture 未完成，则调用 `ChannelFuture#addListener(ChannelFutureListener)` 方法，添加监听器，在**注册**完成后，进行回调执行 `#doResolveAndConnect0(...)` 方法的逻辑。详细解析，见 [「3.6.2 doResolveAndConnect0」](https://svip.iocoder.cn/Netty/bootstrap-2-client/#) 。
+  - 所以总结来说，**resolve 和 connect 的逻辑，执行在 register 的逻辑之后**。
+
+### 3.6.2 doResolveAndConnect0
+
+> 老艿艿：此小节的内容，胖友先看完 [「3.7 initAndRegister」](https://svip.iocoder.cn/Netty/bootstrap-2-client/#) 的内容在回过头来看。因为 `#doResolveAndConnect0(...)` 方法的执行，在 `#initAndRegister()` 方法之后。
+
+`#doResolveAndConnect0(...)` 方法，解析远程地址，并进行连接。代码如下：
+
+```
+ 1: private ChannelFuture doResolveAndConnect0(final Channel channel, SocketAddress remoteAddress,
+ 2:                                            final SocketAddress localAddress, final ChannelPromise promise) {
+ 3:     try {
+ 4:         final EventLoop eventLoop = channel.eventLoop();
+ 5:         final AddressResolver<SocketAddress> resolver = this.resolver.getResolver(eventLoop);
+ 6: 
+ 7:         if (!resolver.isSupported(remoteAddress) || resolver.isResolved(remoteAddress)) {
+ 8:             // Resolver has no idea about what to do with the specified remote address or it's resolved already.
+ 9:             doConnect(remoteAddress, localAddress, promise);
+10:             return promise;
+11:         }
+12: 
+13:         // 解析远程地址
+14:         final Future<SocketAddress> resolveFuture = resolver.resolve(remoteAddress);
+15: 
+16:         if (resolveFuture.isDone()) {
+17:             // 解析远程地址失败，关闭 Channel ，并回调通知 promise 异常
+18:             final Throwable resolveFailureCause = resolveFuture.cause();
+19:             if (resolveFailureCause != null) {
+20:                 // Failed to resolve immediately
+21:                 channel.close();
+22:                 promise.setFailure(resolveFailureCause);
+23:             } else {
+24:                 // Succeeded to resolve immediately; cached? (or did a blocking lookup)
+25:                 // 连接远程地址
+26:                 doConnect(resolveFuture.getNow(), localAddress, promise);
+27:             }
+28:             return promise;
+29:         }
+30: 
+31:         // Wait until the name resolution is finished.
+32:         resolveFuture.addListener(new FutureListener<SocketAddress>() {
+33:             @Override
+34:             public void operationComplete(Future<SocketAddress> future) throws Exception {
+35:                 // 解析远程地址失败，关闭 Channel ，并回调通知 promise 异常
+36:                 if (future.cause() != null) {
+37:                     channel.close();
+38:                     promise.setFailure(future.cause());
+39:                 // 解析远程地址成功，连接远程地址
+40:                 } else {
+41:                     doConnect(future.getNow(), localAddress, promise);
+42:                 }
+43:             }
+44:         });
+45:     } catch (Throwable cause) {
+46:         // 发生异常，并回调通知 promise 异常
+47:         promise.tryFailure(cause);
+48:     }
+49:     return promise;
+50: }
+```
+
+- 第 3 至 14 行：使用
+
+   
+
+  ```
+  resolver
+  ```
+
+   
+
+  解析远程地址。因为解析是
+
+  异步
+
+  的过程，所以返回一个 Future 对象。
+
+  - 详细的解析远程地址的代码，考虑到暂时不是本文的重点，所以暂时省略。😈 老艿艿猜测胖友应该也暂时不感兴趣，哈哈哈。
+
+- 第 16 至 44 行：因为注册是
+
+  异步
+
+  的过程，有可能已完成，有可能未完成。所以实现代码分成了【第 16 至 29 行】和【第 31 至 44 行】分别处理已完成和未完成的情况。
+
+  - **核心**在【第 26 行】或者【第 41 行】的代码，调用 `#doConnect(...)` 方法，连接远程地址。
+  - 如果**异步**解析对应的 Future 未完成，则调用 `Future#addListener(FutureListener)` 方法，添加监听器，在**解析**完成后，进行回调执行 `#doConnect(...)` 方法的逻辑。详细解析，见 见 [「3.13.3 doConnect」](https://svip.iocoder.cn/Netty/bootstrap-2-client/#) 。
+  - 所以总结来说，**connect 的逻辑，执行在 resolve 的逻辑之后**。
+  - 老艿艿目前使用 [「2. Bootstrap 示例」](https://svip.iocoder.cn/Netty/bootstrap-2-client/#) 测试下来，符合【第 16 至 30 行】的条件，即无需走**异步**的流程。
+
+### 3.6.3 doConnect
+
+`#doConnect(...)` 方法，执行 Channel 连接远程地址的逻辑。代码如下：
+
+```
+ 1: private static void doConnect(final SocketAddress remoteAddress, final SocketAddress localAddress, final ChannelPromise connectPromise) {
+ 2: 
+ 3:     // This method is invoked before channelRegistered() is triggered.  Give user handlers a chance to set up
+ 4:     // the pipeline in its channelRegistered() implementation.
+ 5:     final Channel channel = connectPromise.channel();
+ 6:     channel.eventLoop().execute(new Runnable() {
+ 7: 
+ 8:         @Override
+ 9:         public void run() {
+10:             if (localAddress == null) {
+11:                 channel.connect(remoteAddress, connectPromise);
+12:             } else {
+13:                 channel.connect(remoteAddress, localAddress, connectPromise);
+14:             }
+15:             connectPromise.addListener(ChannelFutureListener.CLOSE_ON_FAILURE);
+16:         }
+17: 
+18:     });
+19: }
+```
+
+- 第 6 行：调用 EventLoop 执行 Channel 连接远程地址的逻辑。但是，实际上当前线程已经是 EventLoop 所在的线程了，为何还要这样操作呢？答案在【第 3 至 4 行】的英语注释。感叹句，Netty 虽然代码量非常庞大且复杂，但是英文注释真的是非常齐全，包括 Github 的 issue 对代码提交的描述，也非常健全。
+
+- 第 10 至 14 行：调用
+
+   
+
+  ```
+  Channel#connect(...)
+  ```
+
+   
+
+  方法，执行 Channel 连接远程地址的逻辑。后续的方法栈调用如下图：
+
+  ![Channel connect 流程](12-Netty 源码分析-启动（二）之客户端.assets/02.png)
+
+  Channel connect 流程
+
+  - 还是老样子，我们先省略掉 pipeline 的内部实现代码，从 `AbstractNioUnsafe#connect(final SocketAddress remoteAddress, final SocketAddress localAddress, final ChannelPromise promise)` 方法，继续向下分享。
+
+`AbstractNioUnsafe#connect(final SocketAddress remoteAddress, final SocketAddress localAddress, final ChannelPromise promise)` 方法，执行 Channel 连接远程地址的逻辑。代码如下：
+
+```
+ 1: @Override
+ 2: public final void connect(final SocketAddress remoteAddress, final SocketAddress localAddress, final ChannelPromise promise) {
+ 3:     if (!promise.setUncancellable() || !ensureOpen(promise)) {
+ 4:         return;
+ 5:     }
+ 6: 
+ 7:     try {
+ 8:         // 目前有正在连接远程地址的 ChannelPromise ，则直接抛出异常，禁止同时发起多个连接。
+ 9:         if (connectPromise != null) {
+10:             // Already a connect in process.
+11:             throw new ConnectionPendingException();
+12:         }
+13: 
+14:         // 记录 Channel 是否激活
+15:         boolean wasActive = isActive();
+16: 
+17:         // 执行连接远程地址
+18:         if (doConnect(remoteAddress, localAddress)) {
+19:             fulfillConnectPromise(promise, wasActive);
+20:         } else {
+21:             // 记录 connectPromise
+22:             connectPromise = promise;
+23:             // 记录 requestedRemoteAddress
+24:             requestedRemoteAddress = remoteAddress;
+25: 
+26:             // 使用 EventLoop 发起定时任务，监听连接远程地址超时。若连接超时，则回调通知 connectPromise 超时异常。
+27:             // Schedule connect timeout.
+28:             int connectTimeoutMillis = config().getConnectTimeoutMillis(); // 默认 30 * 1000 毫秒
+29:             if (connectTimeoutMillis > 0) {
+30:                 connectTimeoutFuture = eventLoop().schedule(new Runnable() {
+31:                     @Override
+32:                     public void run() {
+33:                         ChannelPromise connectPromise = AbstractNioChannel.this.connectPromise;
+34:                         ConnectTimeoutException cause = new ConnectTimeoutException("connection timed out: " + remoteAddress);
+35:                         if (connectPromise != null && connectPromise.tryFailure(cause)) {
+36:                             close(voidPromise());
+37:                         }
+38:                     }
+39:                 }, connectTimeoutMillis, TimeUnit.MILLISECONDS);
+40:             }
+41: 
+42:             // 添加监听器，监听连接远程地址取消。
+43:             promise.addListener(new ChannelFutureListener() {
+44:                 @Override
+45:                 public void operationComplete(ChannelFuture future) throws Exception {
+46:                     if (future.isCancelled()) {
+47:                         // 取消定时任务
+48:                         if (connectTimeoutFuture != null) {
+49:                             connectTimeoutFuture.cancel(false);
+50:                         }
+51:                         // 置空 connectPromise
+52:                         connectPromise = null;
+53:                         close(voidPromise());
+54:                     }
+55:                 }
+56:             });
+57:         }
+58:     } catch (Throwable t) {
+59:         // 回调通知 promise 发生异常
+60:         promise.tryFailure(annotateConnectException(t, remoteAddress));
+61:         closeIfClosed();
+62:     }
+63: }
+```
+
+- 第 8 至 12 行：目前有正在连接远程地址的 ChannelPromise ，则直接抛出异常，禁止同时发起多个连接。`connectPromise` 变量，定义在 AbstractNioChannel 类中，代码如下：
+
+  ```
+  /**
+   * 目前正在连接远程地址的 ChannelPromise 对象。
+   *
+   * The future of the current connection attempt.  If not null, subsequent
+   * connection attempts will fail.
+   */
+  private ChannelPromise connectPromise;
+  ```
+
+- 第 15 行：调用 `#isActive()` 方法，获得 Channel 是否激活。NioSocketChannel 对该方法的实现代码如下：
+
+  ```
+  @Override
+  public boolean isActive() {
+      SocketChannel ch = javaChannel();
+      return ch.isOpen() && ch.isConnected();
+  }
+  ```
+
+  - 判断 SocketChannel 是否处于打开，并且连接的状态。此时，一般返回的是 `false` 。
+
+- 第 18 行：调用 `#doConnect(SocketAddress remoteAddress, SocketAddress localAddress)` 方法，执行连接远程地址。代码如下：
+
+  ```
+  // NioSocketChannel.java
+    1: @Override
+    2: protected boolean doConnect(SocketAddress remoteAddress, SocketAddress localAddress) throws Exception {
+    3:     // 绑定本地地址
+    4:     if (localAddress != null) {
+    5:         doBind0(localAddress);
+    6:     }
+    7: 
+    8:     boolean success = false; // 执行是否成功
+    9:     try {
+   10:         // 连接远程地址
+   11:         boolean connected = SocketUtils.connect(javaChannel(), remoteAddress);
+   12:         // 若未连接完成，则关注连接( OP_CONNECT )事件。
+   13:         if (!connected) {
+   14:             selectionKey().interestOps(SelectionKey.OP_CONNECT);
+   15:         }
+   16:         // 标记执行是否成功
+   17:         success = true;
+   18:         // 返回是否连接完成
+   19:         return connected;
+   20:     } finally {
+   21:         // 执行失败，则关闭 Channel
+   22:         if (!success) {
+   23:             doClose();
+   24:         }
+   25:     }
+   26: }
+  ```
+
+  - 第 3 至 6 行：若 `localAddress` 非空，则调用 `#doBind0(SocketAddress)` 方法，绑定本地地址。一般情况下，NIO Client 是不需要绑定本地地址的。默认情况下，系统会随机分配一个可用的本地地址，进行绑定。
+
+  - 第 11 行：调用 `SocketUtils#connect(SocketChannel socketChannel, SocketAddress remoteAddress)` 方法，Java 原生 NIO SocketChannel 连接 远程地址，并返回是否连接完成( 成功 )。代码如下：
+
+    ```
+    public static boolean connect(final SocketChannel socketChannel, final SocketAddress remoteAddress) throws IOException {
+        try {
+            return AccessController.doPrivileged(new PrivilegedExceptionAction<Boolean>() {
+                @Override
+                public Boolean run() throws IOException {
+                    return socketChannel.connect(remoteAddress);
+                }
+            });
+        } catch (PrivilegedActionException e) {
+            throw (IOException) e.getCause();
+        }
+    }
+    ```
+
+    - 可能有胖友有和我一样的疑问，为什么将 connect 操作包在 AccessController 中呢？我们来看下 SocketUtils 类的注释：
+
+      ```
+      /**
+       * Provides socket operations with privileges enabled. This is necessary for applications that use the
+       * {@link SecurityManager} to restrict {@link SocketPermission} to their application. By asserting that these
+       * operations are privileged, the operations can proceed even if some code in the calling chain lacks the appropriate
+       * {@link SocketPermission}.
+       */
+      ```
+
+      - 一般情况下，我们用不到，所以也可以暂时不用理解。
+      - 感兴趣的胖友，可以 Google “AccessController” 关键字，或者阅读 [《Java 安全模型介绍》](https://www.ibm.com/developerworks/cn/java/j-lo-javasecurity/index.html) 。
+
+  - 【重要】第 12 至 15 行：若连接未完成( `connected == false` )时，我们可以看到，调用 `SelectionKey#interestOps(ops)` 方法，添加连接事件( `SelectionKey.OP_CONNECT` )为感兴趣的事件。也就说，也就是说，当连接远程地址成功时，Channel 对应的 Selector 将会轮询到该事件，可以进一步处理。
+
+  - 第 20 至 25 行：若执行失败( `success == false` )时，调用 `#doClose()` 方法，关闭 Channel 。
+
+- 第 18 至 19 行：笔者测试下来，`#doConnect(SocketChannel socketChannel, SocketAddress remoteAddress)` 方法的结果为 `false` ，所以不会执行【第 19 行】代码的 `#fulfillConnectPromise(ChannelPromise promise, boolean wasActive)` 方法，而是执行【第 20 至 57 行】的代码逻辑。
+
+- 第 22 行：记录 `connectPromise` 。
+
+- 第 24 行：记录 `requestedRemoteAddress` 。`requestedRemoteAddress` 变量，在 AbstractNioChannel 类中定义，代码如下：
+
+  ```
+  /**
+   * 正在连接的远程地址
+   */
+  private SocketAddress requestedRemoteAddress;
+  ```
+
+- 第 26 至 40 行：调用 `EventLoop#schedule(Runnable command, long delay, TimeUnit unit)` 方法，发起定时任务 `connectTimeoutFuture` ，监听连接远程地址**是否超时**。若连接超时，则回调通知 `connectPromise` 超时异常。`connectPromise` 变量，在 AbstractNioChannel 类中定义，代码如下：
+
+  ```
+  /**
+   * 连接超时监听 ScheduledFuture 对象。
+   */
+  private ScheduledFuture<?> connectTimeoutFuture;
+  ```
+
+- 第 42 至 57 行：调用 `ChannelPromise#addListener(ChannelFutureListener)` 方法，添加监听器，监听连接远程地址**是否取消**。若取消，则取消 `connectTimeoutFuture` 任务，并置空 `connectPromise` 。这样，客户端 Channel 可以发起下一次连接。
+
+### 3.6.4 finishConnect
+
+看到此处，可能胖友会有疑问，客户端的连接在哪里完成呢？答案在 `AbstractNioUnsafe#finishConnect()` 方法中。而该方法通过 Selector 轮询到 `SelectionKey.OP_CONNECT` 事件时，进行触发。调用栈如下图：[![finishConnect 调用栈](12-Netty 源码分析-启动（二）之客户端.assets/03.png)](http://static.iocoder.cn/images/Netty/2018_04_05/03.png)finishConnect 调用栈
+
+```
+* 哈哈哈，还是老样子，我们先省略掉 EventLoop 的内部实现代码，从 `AbstractNioUnsafe#finishConnect()` 方法，继续向下分享。
+```
+
+`AbstractNioUnsafe#finishConnect()` 方法，完成客户端的连接。代码如下：
+
+```
+ 1: @Override
+ 2: public final void finishConnect() {
+ 3:     // Note this method is invoked by the event loop only if the connection attempt was
+ 4:     // neither cancelled nor timed out.
+ 5:     // 判断是否在 EventLoop 的线程中。
+ 6:     assert eventLoop().inEventLoop();
+ 7: 
+ 8:     try {
+ 9:         // 获得 Channel 是否激活
+10:         boolean wasActive = isActive();
+11:         // 执行完成连接
+12:         doFinishConnect();
+13:         // 通知 connectPromise 连接完成
+14:         fulfillConnectPromise(connectPromise, wasActive);
+15:     } catch (Throwable t) {
+16:         // 通知 connectPromise 连接异常
+17:         fulfillConnectPromise(connectPromise, annotateConnectException(t, requestedRemoteAddress));
+18:     } finally {
+19:         // 取消 connectTimeoutFuture 任务
+20:         // Check for null as the connectTimeoutFuture is only created if a connectTimeoutMillis > 0 is used
+21:         // See https://github.com/netty/netty/issues/1770
+22:         if (connectTimeoutFuture != null) {
+23:             connectTimeoutFuture.cancel(false);
+24:         }
+25:         // 置空 connectPromise
+26:         connectPromise = null;
+27:     }
+28: }
+```
+
+- 第 6 行：判断是否在 EventLoop 的线程中。
+- 第 10 行：调用 `#isActive()` 方法，获得 Channel 是否激活。笔者调试时，此时返回 `false` ，因为连接还没完成。
+- 第 12 行：调用 `#doFinishConnect()` 方法，执行完成连接的逻辑。详细解析，见 [「3.6.4.1 doFinishConnect」](https://svip.iocoder.cn/Netty/bootstrap-2-client/#) 。
+- 第 14 行：执行完成连接**成功**，调用 `#fulfillConnectPromise(ChannelPromise promise, boolean wasActive)` 方法，通知 `connectPromise` 连接完成。详细解析，见 [「3.6.4.2 fulfillConnectPromise 成功」](https://svip.iocoder.cn/Netty/bootstrap-2-client/#) 。
+- 第 15 至 17 行：执行完成连接**异常**，调用 `#fulfillConnectPromise(ChannelPromise promise, Throwable cause)` 方法，通知 `connectPromise` 连接异常。详细解析，见 [「3.6.4.3 fulfillConnectPromise 异常」](https://svip.iocoder.cn/Netty/bootstrap-2-client/#) 。
+- 第 18 至 27 行：执行完成连接**结束**，取消 `connectTimeoutFuture` 任务，并置空 `connectPromise` 。
+
+#### 3.6.4.1 doFinishConnect
+
+`NioSocketChannel#doFinishConnect()` 方法，执行完成连接的逻辑。代码如下：
+
+```
+@Override
+protected void doFinishConnect() throws Exception {
+    if (!javaChannel().finishConnect()) {
+        throw new Error();
+    }
+}
+```
+
+- 【重要】是不是非常熟悉的，调用 `SocketChannel#finishConnect()` 方法，完成连接。😈 美滋滋。
+
+#### 3.6.4.2 fulfillConnectPromise 成功
+
+`AbstractNioUnsafe#fulfillConnectPromise(ChannelPromise promise, Throwable cause)` 方法，通知 `connectPromise` 连接完成。代码如下：
+
+```
+ 1: private void fulfillConnectPromise(ChannelPromise promise, boolean wasActive) {
+ 2:     if (promise == null) {
+ 3:         // Closed via cancellation and the promise has been notified already.
+ 4:         return;
+ 5:     }
+ 6: 
+ 7:     // 获得 Channel 是否激活
+ 8:     // Get the state as trySuccess() may trigger an ChannelFutureListener that will close the Channel.
+ 9:     // We still need to ensure we call fireChannelActive() in this case.
+10:     boolean active = isActive();
+11: 
+12:     // 回调通知 promise 执行成功
+13:     // trySuccess() will return false if a user cancelled the connection attempt.
+14:     boolean promiseSet = promise.trySuccess();
+15: 
+16:     // 若 Channel 是新激活的，触发通知 Channel 已激活的事件。
+17:     // Regardless if the connection attempt was cancelled, channelActive() event should be triggered,
+18:     // because what happened is what happened.
+19:     if (!wasActive && active) {
+20:         pipeline().fireChannelActive();
+21:     }
+22: 
+23:     // If a user cancelled the connection attempt, close the channel, which is followed by channelInactive().
+24:     // TODO 芋艿
+25:     if (!promiseSet) {
+26:         close(voidPromise());
+27:     }
+28: }
+```
+
+- 第 10 行：调用 `#isActive()` 方法，获得 Channel 是否激活。笔者调试时，此时返回 `true` ，因为连接已经完成。
+
+- 第 14 行：回调通知 `promise` 执行成功。此处的通知，对应回调的是我们添加到 `#connect(...)` 方法返回的 ChannelFuture 的 ChannelFutureListener 的监听器。示例代码如下：
+
+  ```
+  ChannelFuture f = b.connect(HOST, PORT).addListener(new ChannelFutureListener() { // 回调的就是我！！！
+      @Override
+      public void operationComplete(ChannelFuture future) throws Exception {
+          System.out.println("连接完成");
+      }
+  }).sync();
+  ```
+
+- 第 19 行：因为
+
+   
+
+  ```
+  wasActive == false
+  ```
+
+   
+
+  并且
+
+   
+
+  ```
+  active == true
+  ```
+
+   
+
+  ，因此，Channel 可以认为是
+
+  新激活
+
+  的，满足【第 20 行】代码的执行条件。
+
+  - 第 40 行：调用 `DefaultChannelPipeline#fireChannelActive()` 方法，触发 Channel 激活的事件。【重要】后续的流程，和 NioServerSocketChannel 一样，也就说，会调用到 `AbstractUnsafe#beginRead()` 方法。这意味着什么呢？将我们创建 NioSocketChannel 时，设置的 `readInterestOp = SelectionKey.OP_READ` 添加为感兴趣的事件。也就说，客户端可以读取服务端发送来的数据。
+  - 关于 `AbstractUnsafe#beginRead()` 方法的解析，见 [《精尽 Netty 源码分析 —— 启动（一）之服务端》的 「3.13.3 beginRead」](http://svip.iocoder.cn/Netty/bootstrap-1-server/?self) 部分。
+
+- 第 23 至 27 行：TODO 芋艿 1004 fulfillConnectPromise promiseSet
+
+#### 3.6.4.3 fulfillConnectPromise 异常
+
+`#fulfillConnectPromise(ChannelPromise promise, Throwable cause)` 方法，通知 `connectPromise` 连接异常。代码如下：
+
+```
+private void fulfillConnectPromise(ChannelPromise promise, Throwable cause) {
+    if (promise == null) {
+        // Closed via cancellation and the promise has been notified already.
+        return;
+    }
+
+    // 回调通知 promise 发生异常
+    // Use tryFailure() instead of setFailure() to avoid the race against cancel().
+    promise.tryFailure(cause);
+    // 关闭
+    closeIfClosed();
+}
+```
+
+- 比较简单，已经添加中文注释，胖友自己查看。
+
+## 3.7 initAndRegister
+
+Bootstrap 继承 AbstractBootstrap 抽象类，所以 `#initAndRegister()` 方法的流程上是一致的。所以和 ServerBootstrap 的差别在于：
+
+1. 创建的 Channel 对象不同。
+2. 初始化 Channel 配置的代码实现不同。
+
+### 3.7.1 创建 Channel 对象
+
+考虑到本文的内容，我们以 NioSocketChannel 的创建过程作为示例。创建 NioSocketChannel 对象的流程，和 NioServerSocketChannel 基本是一致的，所以流程图我们就不提供了，直接开始撸源码。
+
+#### 3.7.1.1 NioSocketChannel
+
+```
+private static final SelectorProvider DEFAULT_SELECTOR_PROVIDER = SelectorProvider.provider();
+
+private final SocketChannelConfig config;
+
+public NioSocketChannel() {
+    this(DEFAULT_SELECTOR_PROVIDER);
+}
+
+public NioSocketChannel(SelectorProvider provider) {
+    this(newSocket(provider));
+}
+```
+
+- `DEFAULT_SELECTOR_PROVIDER` **静态**属性，默认的 SelectorProvider 实现类。
+
+- `config` 属性，Channel 对应的配置对象。每种 Channel 实现类，也会对应一个 ChannelConfig 实现类。例如，NioSocketChannel 类，对应 SocketChannelConfig 配置类。
+
+- 在构造方法中，调用 `#newSocket(SelectorProvider provider)` 方法，创建 NIO 的 ServerSocketChannel 对象。代码如下：
+
+  ```
+  private static SocketChannel newSocket(SelectorProvider provider) {
+      try {
+          /**
+           *  Use the {@link SelectorProvider} to open {@link SocketChannel} and so remove condition in
+           *  {@link SelectorProvider#provider()} which is called by each SocketChannel.open() otherwise.
+           *
+           *  See <a href="https://github.com/netty/netty/issues/2308">#2308</a>.
+           */
+          return provider.openSocketChannel();
+      } catch (IOException e) {
+          throw new ChannelException("Failed to open a socket.", e);
+      }
+  }
+  ```
+
+  - 😈 是不是很熟悉这样的代码，效果和 `SocketChannel#open()` 方法创建 SocketChannel 对象是一致。
+
+- `#NioSocketChannel(SocketChannel channel)` 构造方法，代码如下：
+
+  ```
+  public NioSocketChannel(SocketChannel socket) {
+      this(null, socket);
+  }
+  
+  public NioSocketChannel(Channel parent, SocketChannel socket) {
+      super(parent, socket);
+      config = new NioSocketChannelConfig(this, socket.socket());
+  }
+  ```
+
+  - 调用父 AbstractNioByteChannel 的构造方法。详细解析，见 [「3.7.1.2 AbstractNioByteChannel」](https://svip.iocoder.cn/Netty/bootstrap-2-client/#) 。
+  - 初始化 `config` 属性，创建 NioSocketChannelConfig 对象。
+
+#### 3.7.1.2 AbstractNioByteChannel
+
+```
+protected AbstractNioByteChannel(Channel parent, SelectableChannel ch) {
+    super(parent, ch, SelectionKey.OP_READ);
+}
+```
+
+- 调用父 AbstractNioChannel 的构造方法。后续的构造方法，和 NioServerSocketChannel 是一致的。
+  - 注意传入的 SelectionKey 的值为 `OP_READ` 。
+
+### 3.7.2 初始化 Channel 配置
+
+`#init(Channel channel)` 方法，初始化 Channel 配置。代码如下：
+
+```
+@Override
+void init(Channel channel) throws Exception {
+    ChannelPipeline p = channel.pipeline();
+
+    // 添加处理器到 pipeline 中
+    p.addLast(config.handler());
+
+    // 初始化 Channel 的可选项集合
+    final Map<ChannelOption<?>, Object> options = options0();
+    synchronized (options) {
+        setChannelOptions(channel, options, logger);
+    }
+
+    // 初始化 Channel 的属性集合
+    final Map<AttributeKey<?>, Object> attrs = attrs0();
+    synchronized (attrs) {
+        for (Entry<AttributeKey<?>, Object> e: attrs.entrySet()) {
+            channel.attr((AttributeKey<Object>) e.getKey()).set(e.getValue());
+        }
+    }
+}
+```
+
+- 比较简单，已经添加中文注释，胖友自己查看。
+
+# 666. 彩蛋
+
+撸完 Netty 服务端启动之后，再撸 Netty 客户端启动之后，出奇的顺手。美滋滋。
+
+另外，也推荐如下和 Netty 客户端启动相关的文章，以加深理解：
+
+- 杨武兵 [《Netty 源码分析系列 —— Bootstrap》](https://my.oschina.net/ywbrj042/blog/868798)
+- 永顺 [《Netty 源码分析之 一 揭开 Bootstrap 神秘的红盖头 (客户端)》](https://segmentfault.com/a/1190000007282789)
\ No newline at end of file
diff --git a/netty/13-Netty 源码解析-EventLoop（一）之 Reactor 模型.assets/01.png b/netty/13-Netty 源码解析-EventLoop（一）之 Reactor 模型.assets/01.png
new file mode 100644
index 0000000..f56fb86
Binary files /dev/null and b/netty/13-Netty 源码解析-EventLoop（一）之 Reactor 模型.assets/01.png differ
diff --git a/netty/13-Netty 源码解析-EventLoop（一）之 Reactor 模型.assets/02.png b/netty/13-Netty 源码解析-EventLoop（一）之 Reactor 模型.assets/02.png
new file mode 100644
index 0000000..86a429a
Binary files /dev/null and b/netty/13-Netty 源码解析-EventLoop（一）之 Reactor 模型.assets/02.png differ
diff --git a/netty/13-Netty 源码解析-EventLoop（一）之 Reactor 模型.assets/03.png b/netty/13-Netty 源码解析-EventLoop（一）之 Reactor 模型.assets/03.png
new file mode 100644
index 0000000..3600450
Binary files /dev/null and b/netty/13-Netty 源码解析-EventLoop（一）之 Reactor 模型.assets/03.png differ
diff --git a/netty/13-Netty 源码解析-EventLoop（一）之 Reactor 模型.md b/netty/13-Netty 源码解析-EventLoop（一）之 Reactor 模型.md
new file mode 100644
index 0000000..794df80
--- /dev/null
+++ b/netty/13-Netty 源码解析-EventLoop（一）之 Reactor 模型.md	
@@ -0,0 +1,364 @@
+# 精尽 Netty 源码解析 —— EventLoop（一）之 Reactor 模型
+
+# 1. 概述
+
+从本文开始，我们来分享 Netty 非常重要的一个组件 EventLoop 。在看 EventLoop 的具体实现之前，我们先来对 Reactor 模型做个简单的了解。
+
+为什么要了解 Reactor 模型呢？因为 EventLoop 是 Netty 基于 Reactor 模型的思想进行实现。所以理解 Reactor 模型，对于我们理解 EventLoop 会有很大帮助。
+
+我们来看看 Reactor 模型的**核心思想**：
+
+> 将关注的 I/O 事件注册到多路复用器上，一旦有 I/O 事件触发，将事件分发到事件处理器中，执行就绪 I/O 事件对应的处理函数中。模型中有三个重要的组件：
+>
+> - 多路复用器：由操作系统提供接口，Linux 提供的 I/O 复用接口有select、poll、epoll 。
+> - 事件分离器：将多路复用器返回的就绪事件分发到事件处理器中。
+> - 事件处理器：处理就绪事件处理函数。
+
+初步一看，Java NIO 符合 Reactor 模型啊？因为 Reactor 有 3 种模型实现：
+
+1. 单 Reactor 单线程模型
+2. 单 Reactor 多线程模型
+3. 多 Reactor 多线程模型
+
+> 😈 由于老艿艿不擅长相对理论文章的内容编写，所以 [「2.」](https://svip.iocoder.cn/Netty/EventLoop-1-Reactor-Model/#)、[「3.」](https://svip.iocoder.cn/Netty/EventLoop-1-Reactor-Model/#)、[「4.」](https://svip.iocoder.cn/Netty/EventLoop-1-Reactor-Model/#) 小节的内容，我决定一本正经的引用基友 wier 的 [《【NIO 系列】—— 之Reactor 模型》](https://my.oschina.net/u/1859679/blog/1844109) 。
+
+# 2. 单 Reactor 单线程模型
+
+示例图如下：
+
+[![单 Reactor 单线程模型](13-Netty 源码解析-EventLoop（一）之 Reactor 模型.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_05_01/01.png)单 Reactor 单线程模型
+
+> 老艿艿：示例代码主要表达大体逻辑，比较奔放。所以，胖友理解大体意思就好。
+
+Reactor 示例代码如下：
+
+```
+/**
+* 等待事件到来，分发事件处理
+*/
+class Reactor implements Runnable {
+
+  private Reactor() throws Exception {
+      SelectionKey sk = serverSocket.register(selector, SelectionKey.OP_ACCEPT);
+      // attach Acceptor 处理新连接
+      sk.attach(new Acceptor());
+  }
+
+  @Override
+  public void run() {
+      try {
+          while (!Thread.interrupted()) {
+              selector.select();
+              Set selected = selector.selectedKeys();
+              Iterator it = selected.iterator();
+              while (it.hasNext()) {
+                  it.remove();
+                  //分发事件处理
+                  dispatch((SelectionKey) (it.next()));
+              }
+          }
+      } catch (IOException ex) {
+          //do something
+      }
+  }
+
+  void dispatch(SelectionKey k) {
+      // 若是连接事件获取是acceptor
+      // 若是IO读写事件获取是handler
+      Runnable runnable = (Runnable) (k.attachment());
+      if (runnable != null) {
+          runnable.run();
+      }
+  }
+
+}
+```
+
+> 老艿艿：示例的 Handler 的代码实现应该是漏了。胖友脑补一个实现 Runnable 接口的 Handler 类。😈
+
+这是最基础的单 Reactor 单线程模型。
+
+Reactor 线程，负责多路分离套接字。
+
+- 有新连接到来触发 `OP_ACCEPT` 事件之后， 交由 Acceptor 进行处理。
+- 有 IO 读写事件之后，交给 Handler 处理。
+
+Acceptor 主要任务是构造 Handler 。
+
+- 在获取到 Client 相关的 SocketChannel 之后，绑定到相应的 Handler 上。
+- 对应的 SocketChannel 有读写事件之后，基于 Reactor 分发，Handler 就可以处理了。
+
+**注意，所有的 IO 事件都绑定到 Selector 上，由 Reactor 统一分发**。
+
+------
+
+该模型适用于处理器链中业务处理组件能快速完成的场景。不过，这种单线程模型不能充分利用多核资源，**所以实际使用的不多**。
+
+# 3. 单 Reactor 多线程模型
+
+示例图如下：
+
+[![单 Reactor 多线程模型](13-Netty 源码解析-EventLoop（一）之 Reactor 模型.assets/02.png)](http://static.iocoder.cn/images/Netty/2018_05_01/02.png)单 Reactor 多线程模型
+
+相对于第一种单线程的模式来说，在处理业务逻辑，也就是获取到 IO 的读写事件之后，交由线程池来处理，这样可以减小主 Reactor 的性能开销，从而更专注的做事件分发工作了，从而提升整个应用的吞吐。
+
+MultiThreadHandler 示例代码如下：
+
+```
+/**
+* 多线程处理读写业务逻辑
+*/
+class MultiThreadHandler implements Runnable {
+  public static final int READING = 0, WRITING = 1;
+  int state;
+  final SocketChannel socket;
+  final SelectionKey sk;
+
+  //多线程处理业务逻辑
+  ExecutorService executorService = Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors());
+
+
+  public MultiThreadHandler(SocketChannel socket, Selector sl) throws Exception {
+      this.state = READING;
+      this.socket = socket;
+      sk = socket.register(selector, SelectionKey.OP_READ);
+      sk.attach(this);
+      socket.configureBlocking(false);
+  }
+
+  @Override
+  public void run() {
+      if (state == READING) {
+          read();
+      } else if (state == WRITING) {
+          write();
+      }
+  }
+
+  private void read() {
+      //任务异步处理
+      executorService.submit(() -> process());
+
+      //下一步处理写事件
+      sk.interestOps(SelectionKey.OP_WRITE);
+      this.state = WRITING;
+  }
+
+  private void write() {
+      //任务异步处理
+      executorService.submit(() -> process());
+
+      //下一步处理读事件
+      sk.interestOps(SelectionKey.OP_READ);
+      this.state = READING;
+  }
+
+  /**
+    * task 业务处理
+    */
+  public void process() {
+      //do IO ,task,queue something
+  }
+}
+```
+
+- 在 `#read()` 和 `#write()` 方法中，提交 `executorService` 线程池，进行处理。
+
+# 4. 多 Reactor 多线程模型
+
+示例图如下：
+
+[![多 Reactor 多线程模型](13-Netty 源码解析-EventLoop（一）之 Reactor 模型.assets/03.png)](http://static.iocoder.cn/images/Netty/2018_05_01/03.png)多 Reactor 多线程模型
+
+第三种模型比起第二种模型，是将 Reactor 分成两部分：
+
+1. mainReactor 负责监听 ServerSocketChannel ，用来处理客户端新连接的建立，并将建立的客户端的 SocketChannel 指定注册给 subReactor 。
+2. subReactor 维护自己的 Selector ，基于 mainReactor 建立的客户端的 SocketChannel 多路分离 IO 读写事件，读写网络数据。对于业务处理的功能，另外扔给 worker 线程池来完成。
+
+MultiWorkThreadAcceptor 示例代码如下：
+
+```
+/**
+* 多work 连接事件Acceptor,处理连接事件
+*/
+class MultiWorkThreadAcceptor implements Runnable {
+
+  // cpu线程数相同多work线程
+  int workCount = Runtime.getRuntime().availableProcessors();
+  SubReactor[] workThreadHandlers = new SubReactor[workCount];
+  volatile int nextHandler = 0;
+
+  public MultiWorkThreadAcceptor() {
+      this.init();
+  }
+
+  public void init() {
+      nextHandler = 0;
+      for (int i = 0; i < workThreadHandlers.length; i++) {
+          try {
+              workThreadHandlers[i] = new SubReactor();
+          } catch (Exception e) {
+          }
+      }
+  }
+
+  @Override
+  public void run() {
+      try {
+          SocketChannel c = serverSocket.accept();
+          if (c != null) {// 注册读写
+              synchronized (c) {
+                  // 顺序获取SubReactor，然后注册channel 
+                  SubReactor work = workThreadHandlers[nextHandler];
+                  work.registerChannel(c);
+                  nextHandler++;
+                  if (nextHandler >= workThreadHandlers.length) {
+                      nextHandler = 0;
+                  }
+              }
+          }
+      } catch (Exception e) {
+      }
+  }
+}
+```
+
+SubReactor 示例代码如下：
+
+```
+/**
+* 多work线程处理读写业务逻辑
+*/
+class SubReactor implements Runnable {
+  final Selector mySelector;
+
+  //多线程处理业务逻辑
+  int workCount =Runtime.getRuntime().availableProcessors();
+  ExecutorService executorService = Executors.newFixedThreadPool(workCount);
+
+
+  public SubReactor() throws Exception {
+      // 每个SubReactor 一个selector 
+      this.mySelector = SelectorProvider.provider().openSelector();
+  }
+
+  /**
+    * 注册chanel
+    *
+    * @param sc
+    * @throws Exception
+    */
+  public void registerChannel(SocketChannel sc) throws Exception {
+      sc.register(mySelector, SelectionKey.OP_READ | SelectionKey.OP_CONNECT);
+  }
+
+  @Override
+  public void run() {
+      while (true) {
+          try {
+          //每个SubReactor 自己做事件分派处理读写事件
+              selector.select();
+              Set<SelectionKey> keys = selector.selectedKeys();
+              Iterator<SelectionKey> iterator = keys.iterator();
+              while (iterator.hasNext()) {
+                  SelectionKey key = iterator.next();
+                  iterator.remove();
+                  if (key.isReadable()) {
+                      read();
+                  } else if (key.isWritable()) {
+                      write();
+                  }
+              }
+
+          } catch (Exception e) {
+
+          }
+      }
+  }
+
+  private void read() {
+      //任务异步处理
+      executorService.submit(() -> process());
+  }
+
+  private void write() {
+      //任务异步处理
+      executorService.submit(() -> process());
+  }
+
+  /**
+    * task 业务处理
+    */
+  public void process() {
+      //do IO ,task,queue something
+  }
+}
+```
+
+从代码中，我们可以看到：
+
+1. mainReactor 主要用来处理网络 IO 连接建立操作，通常，mainReactor 只需要一个，因为它一个线程就可以处理。
+2. subReactor 主要和建立起来的客户端的 SocketChannel 做数据交互和事件业务处理操作。通常，subReactor 的个数和 CPU 个数**相等**，每个 subReactor **独占**一个线程来处理。
+
+------
+
+此种模式中，每个模块的工作更加专一，耦合度更低，性能和稳定性也大大的提升，支持的可并发客户端数量可达到上百万级别。
+
+> 老艿艿：一般来说，是达到数十万级别。
+
+关于此种模式的应用，目前有很多优秀的框架已经在应用，比如 Mina 和 Netty 等等。**上述中去掉线程池的第三种形式的变种，也是 Netty NIO 的默认模式**。
+
+# 5. Netty NIO 客户端
+
+我们来看看 Netty NIO 客户端的示例代码中，和 EventLoop 相关的代码：
+
+```
+// 创建一个 EventLoopGroup 对象
+EventLoopGroup group = new NioEventLoopGroup();
+// 创建 Bootstrap 对象
+Bootstrap b = new Bootstrap();
+// 设置使用的 EventLoopGroup
+b.group(group);
+```
+
+- 对于 Netty NIO 客户端来说，仅创建一个 EventLoopGroup 。
+- 一个 EventLoop 可以对应一个 Reactor 。因为 EventLoopGroup 是 EventLoop 的分组，所以对等理解，EventLoopGroup 是**一种** Reactor 的分组。
+- 一个 Bootstrap 的启动，只能发起对一个远程的地址。所以只会使用一个 NIO Selector ，也就是说仅使用**一个** Reactor 。即使，我们在声明使用一个 EventLoopGroup ，该 EventLoopGroup 也只会分配一个 EventLoop 对 IO 事件进行处理。
+- 因为 Reactor 模型主要使用服务端的开发中，如果套用在 Netty NIO 客户端中，到底使用了哪一种模式呢？
+  - 如果只有一个业务线程使用 Netty NIO 客户端，那么可以认为是【单 Reactor **单**线程模型】。
+  - 如果有**多个**业务线程使用 Netty NIO 客户端，那么可以认为是【单 Reactor **多**线程模型】。
+- 那么 Netty NIO 客户端是否能够使用【多 Reactor 多线程模型】呢？😈 创建多个 Netty NIO 客户端，连接同一个服务端。那么多个 Netty 客户端就可以认为符合多 Reactor 多线程模型了。
+  - 一般情况下，我们不会这么干。
+  - 当然，实际也有这样的示例。例如 Dubbo 或 Motan 这两个 RPC 框架，支持通过配置，同一个 Consumer 对同一个 Provider 实例同时建立多个客户端连接。
+
+# 6. Netty NIO 服务端
+
+我们来看看 Netty NIO 服务端的示例代码中，和 EventLoop 相关的代码：
+
+```
+// 创建两个 EventLoopGroup 对象
+EventLoopGroup bossGroup = new NioEventLoopGroup(1); // 创建 boss 线程组 用于服务端接受客户端的连接
+EventLoopGroup workerGroup = new NioEventLoopGroup(); // 创建 worker 线程组 用于进行 SocketChannel 的数据读写
+// 创建 ServerBootstrap 对象
+ServerBootstrap b = new ServerBootstrap();
+// 设置使用的 EventLoopGroup
+b.group(bossGroup, workerGroup);
+```
+
+- 对于 Netty NIO 服务端来说，创建两个 EventLoopGroup 。
+  - `bossGroup` 对应 Reactor 模式的 mainReactor ，用于服务端接受客户端的连接。比较特殊的是，传入了方法参数 `nThreads = 1` ，表示只使用一个 EventLoop ，即只使用一个 Reactor 。这个也符合我们上面提到的，“*通常，mainReactor 只需要一个，因为它一个线程就可以处理*”。
+  - `workerGroup` 对应 Reactor 模式的 subReactor ，用于进行 SocketChannel 的数据读写。对于 EventLoopGroup ，如果未传递方法参数 `nThreads` ，表示使用 CPU 个数 Reactor 。这个也符合我们上面提到的，“*通常，subReactor 的个数和 CPU 个数相等，每个 subReactor 独占一个线程来处理*”。
+- 因为使用两个 EventLoopGroup ，所以符合【多 Reactor 多线程模型】的多 Reactor 的要求。实际在使用时，`workerGroup` 在读完数据时，具体的业务逻辑处理，我们会提交到**专门的业务逻辑线程池**，例如在 Dubbo 或 Motan 这两个 RPC 框架中。这样一来，就完全符合【多 Reactor 多线程模型】。
+- 那么可能有胖友可能和我有一样的疑问，`bossGroup` 如果配置多个线程，是否可以使用**多个 mainReactor** 呢？我们来分析一波，一个 Netty NIO 服务端**同一时间**，只能 bind 一个端口，那么只能使用一个 Selector 处理客户端连接事件。又因为，Selector 操作是非线程安全的，所以无法在多个 EventLoop ( 多个线程 )中，同时操作。所以这样就导致，即使 `bossGroup` 配置多个线程，实际能够使用的也就是一个线程。
+- 那么如果一定一定一定要多个 mainReactor 呢？创建多个 Netty NIO 服务端，并绑定多个端口。
+
+# 666. 彩蛋
+
+如果 Reactor 模式讲解的不够清晰，或者想要更加深入的理解，推荐阅读如下文章：
+
+- wier [《【NIO 系列】—— 之 Reactor 模型》](https://my.oschina.net/u/1859679/blog/1844109)
+- 永顺 [《Netty 源码分析之 三 我就是大名鼎鼎的 EventLoop(一)》](https://segmentfault.com/a/1190000007403873) 里面有几个图不错。
+- Essviv [《Reactor 模型》](https://essviv.github.io/2017/01/25/IO/netty/reactor模型/) 里面的代码示例不错。
+- xieshuang [《异步网络模型》](https://tech.youzan.com/yi-bu-wang-luo-mo-xing/) 内容很高端，一看就是高玩。
+
+另外，还有一个经典的 Proactor 模型，因为 Netty 并未实现，所以笔者就省略了。如果感兴趣的胖友，可以自行 Google 理解下。
\ No newline at end of file
diff --git a/netty/14-Netty 源码解析-EventLoop（二）之 EventLoopGroup.assets/01.png b/netty/14-Netty 源码解析-EventLoop（二）之 EventLoopGroup.assets/01.png
new file mode 100644
index 0000000..1687e8a
Binary files /dev/null and b/netty/14-Netty 源码解析-EventLoop（二）之 EventLoopGroup.assets/01.png differ
diff --git a/netty/14-Netty 源码解析-EventLoop（二）之 EventLoopGroup.md b/netty/14-Netty 源码解析-EventLoop（二）之 EventLoopGroup.md
new file mode 100644
index 0000000..1cd967a
--- /dev/null
+++ b/netty/14-Netty 源码解析-EventLoop（二）之 EventLoopGroup.md	
@@ -0,0 +1,928 @@
+# 精尽 Netty 源码解析 —— EventLoop（二）之 EventLoopGroup
+
+# 1. 概述
+
+在 [《精尽 Netty 源码分析 —— Netty 简介（二）之核心组件》](http://svip.iocoder.cn/Netty/intro-2/?self) 中，对 EventLoopGroup 和 EventLoop 做了定义，我们再来回顾下：
+
+> - Channel 为Netty 网络操作抽象类，EventLoop 负责处理注册到其上的 Channel 处理 I/O 操作，两者配合参与 I/O 操作。
+> - EventLoopGroup 是一个 EventLoop 的分组，它可以获取到一个或者多个 EventLoop 对象，因此它提供了迭代出 EventLoop 对象的方法。
+
+在 [《精尽 Netty 源码分析 —— 启动》](https://svip.iocoder.cn/Netty/EventLoop-2-EventLoopGroup/#) 中，我们特别熟悉的一段代码就是：
+
+- `new NioEventLoopGroup()` ，创建一个 EventLoopGroup 对象。
+- `EventLoopGroup#register(Channel channel)` ，将 Channel 注册到 EventLoopGroup 上。
+
+那么，本文我们分享 EventLoopGroup 的具体代码实现，来一探究竟。
+
+# 2. 类结构图
+
+EventLoopGroup 的整体类结构如下图：
+
+[![EventLoopGroup 类图](14-Netty 源码解析-EventLoop（二）之 EventLoopGroup.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_05_04/01.png)EventLoopGroup 类图
+
+- 红框部分，为 EventLoopGroup 相关的类关系。其他部分，为 EventLoop 相关的类关系。
+- 因为我们实际上使用的是 **NioEventLoopGroup** 和 NioEventLoop ，所以笔者省略了其它相关的类，例如 OioEventLoopGroup、EmbeddedEventLoop 等等。
+
+下面，我们逐层看看每个接口和类的实现代码。
+
+# 3. EventExecutorGroup
+
+`io.netty.util.concurrent.EventExecutorGroup` ，实现 Iterable、ScheduledExecutorService 接口，EventExecutor ( 事件执行器 )的分组接口。代码如下：
+
+```
+// ========== 自定义接口 ==========
+
+boolean isShuttingDown();
+
+// 优雅关闭
+Future<?> shutdownGracefully();
+Future<?> shutdownGracefully(long quietPeriod, long timeout, TimeUnit unit);
+
+Future<?> terminationFuture();
+
+// 选择一个 EventExecutor 对象
+EventExecutor next(); 
+
+// ========== 实现自 Iterable 接口 ==========
+
+@Override
+Iterator<EventExecutor> iterator();
+
+// ========== 实现自 ExecutorService 接口 ==========
+
+@Override
+Future<?> submit(Runnable task);
+@Override
+<T> Future<T> submit(Runnable task, T result);
+@Override
+<T> Future<T> submit(Callable<T> task);
+
+@Override
+@Deprecated
+void shutdown();
+@Override
+@Deprecated
+List<Runnable> shutdownNow();
+
+// ========== 实现自 ScheduledExecutorService 接口 ==========
+
+@Override
+ScheduledFuture<?> schedule(Runnable command, long delay, TimeUnit unit);
+@Override
+<V> ScheduledFuture<V> schedule(Callable<V> callable, long delay, TimeUnit unit);
+@Override
+ScheduledFuture<?> scheduleAtFixedRate(Runnable command, long initialDelay, long period, TimeUnit unit);
+@Override
+ScheduledFuture<?> scheduleWithFixedDelay(Runnable command, long initialDelay, long delay, TimeUnit unit);
+```
+
+- 每个接口的方法的意思比较好理解，笔者就不一一赘述了。
+- 比较特殊的是，接口方法返回类型为 Future 不是 Java 原生的 `java.util.concurrent.Future` ，而是 Netty 自己实现的 Future 接口。详细解析，见后续文章。
+- EventExecutorGroup 自身不执行任务，而是将任务 `#submit(...)` 或 `#schedule(...)` 给自己管理的 EventExecutor 的分组。至于提交给哪一个 EventExecutor ，一般是通过 `#next()` 方法，选择一个 EventExecutor 。
+
+# 4. AbstractEventExecutorGroup
+
+`io.netty.util.concurrent.AbstractEventExecutorGroup` ，实现 EventExecutorGroup 接口，EventExecutor ( 事件执行器 )的分组抽象类。
+
+## 4.1 submit
+
+`#submit(...)` 方法，提交**一个**普通任务到 EventExecutor 中。代码如下：
+
+```
+@Override
+public Future<?> submit(Runnable task) {
+    return next().submit(task);
+}
+
+@Override
+public <T> Future<T> submit(Runnable task, T result) {
+    return next().submit(task, result);
+}
+
+@Override
+public <T> Future<T> submit(Callable<T> task) {
+    return next().submit(task);
+}
+```
+
+- 提交的 EventExecutor ，通过 `#next()` 方法选择。
+
+## 4.2 schedule
+
+`#schedule(...)` 方法，提交**一个**定时任务到 EventExecutor 中。代码如下：
+
+```
+@Override
+public ScheduledFuture<?> schedule(Runnable command, long delay, TimeUnit unit) {
+    return next().schedule(command, delay, unit);
+}
+
+@Override
+public <V> ScheduledFuture<V> schedule(Callable<V> callable, long delay, TimeUnit unit) {
+    return next().schedule(callable, delay, unit);
+}
+
+@Override
+public ScheduledFuture<?> scheduleAtFixedRate(Runnable command, long initialDelay, long period, TimeUnit unit) {
+    return next().scheduleAtFixedRate(command, initialDelay, period, unit);
+}
+
+@Override
+public ScheduledFuture<?> scheduleWithFixedDelay(Runnable command, long initialDelay, long delay, TimeUnit unit) {
+    return next().scheduleWithFixedDelay(command, initialDelay, delay, unit);
+}
+```
+
+- 提交的 EventExecutor ，通过 `#next()` 方法选择。
+
+## 4.3 execute
+
+`#execute(...)` 方法，在 EventExecutor 中执行**一个**普通任务。代码如下：
+
+```
+@Override
+public void execute(Runnable command) {
+    next().execute(command);
+}
+```
+
+- 执行的 EventExecutor ，通过 `#next()` 方法选择。
+- 看起来 `#execute(...)` 和 `#submit(...)` 方法有几分相似，具体的差异，由 EventExecutor 的实现决定。
+
+## 4.4 invokeAll
+
+`#invokeAll(...)` 方法，在 EventExecutor 中执行**多个**普通任务。代码如下：
+
+```
+@Override
+public <T> List<java.util.concurrent.Future<T>> invokeAll(Collection<? extends Callable<T>> tasks) throws InterruptedException {
+    return next().invokeAll(tasks);
+}
+
+@Override
+public <T> List<java.util.concurrent.Future<T>> invokeAll(Collection<? extends Callable<T>> tasks, long timeout, TimeUnit unit) throws InterruptedException {
+    return next().invokeAll(tasks, timeout, unit);
+}
+```
+
+- 执行的 EventExecutor ，通过 `#next()` 方法选择。并且，多个任务使用同一个 EventExecutor 。
+
+## 4.5 invokeAny
+
+`#invokeAll(...)` 方法，在 EventExecutor 中执行**多个**普通任务，有**一个**执行完成即可。代码如下：
+
+```
+@Override
+public <T> T invokeAny(Collection<? extends Callable<T>> tasks) throws InterruptedException, ExecutionException {
+    return next().invokeAny(tasks);
+}
+
+@Override
+public <T> T invokeAny(Collection<? extends Callable<T>> tasks, long timeout, TimeUnit unit) throws InterruptedException, ExecutionException, TimeoutException {
+    return next().invokeAny(tasks, timeout, unit);
+}
+```
+
+- 执行的 EventExecutor ，通过 `#next()` 方法选择。并且，多个任务使用同一个 EventExecutor 。
+
+## 4.6 shutdown
+
+`#shutdown(...)` 方法，关闭 EventExecutorGroup 。代码如下：
+
+```
+@Override
+public Future<?> shutdownGracefully() {
+    return shutdownGracefully(DEFAULT_SHUTDOWN_QUIET_PERIOD /* 2 */, DEFAULT_SHUTDOWN_TIMEOUT /* 15 */, TimeUnit.SECONDS);
+}
+
+@Override
+@Deprecated
+public List<Runnable> shutdownNow() {
+    shutdown();
+    return Collections.emptyList();
+}
+
+@Override
+@Deprecated
+public abstract void shutdown();
+```
+
+- 具体的 `#shutdownGracefully(long quietPeriod, long timeout, TimeUnit unit)` 和 `#shutdown()` 方法，由子类实现。
+
+# 5. MultithreadEventExecutorGroup
+
+`io.netty.util.concurrent.MultithreadEventExecutorGroup` ，继承 AbstractEventExecutorGroup 抽象类，**基于多线程**的 EventExecutor ( 事件执行器 )的分组抽象类。
+
+## 5.1 构造方法
+
+```
+/**
+ * EventExecutor 数组
+ */
+private final EventExecutor[] children;
+/**
+ * 不可变( 只读 )的 EventExecutor 数组
+ *
+ * @see #MultithreadEventExecutorGroup(int, Executor, EventExecutorChooserFactory, Object...)
+ */
+private final Set<EventExecutor> readonlyChildren;
+/**
+ * 已终止的 EventExecutor 数量
+ */
+private final AtomicInteger terminatedChildren = new AtomicInteger();
+/**
+ * 用于终止 EventExecutor 的异步 Future
+ */
+private final Promise<?> terminationFuture = new DefaultPromise(GlobalEventExecutor.INSTANCE);
+/**
+ * EventExecutor 选择器
+ */
+private final EventExecutorChooserFactory.EventExecutorChooser chooser;
+
+protected MultithreadEventExecutorGroup(int nThreads, ThreadFactory threadFactory, Object... args) {
+    this(nThreads, threadFactory == null ? null : new ThreadPerTaskExecutor(threadFactory), args);
+}
+
+protected MultithreadEventExecutorGroup(int nThreads, Executor executor, Object... args) {
+    this(nThreads, executor, DefaultEventExecutorChooserFactory.INSTANCE, args);
+}
+
+  1: protected MultithreadEventExecutorGroup(int nThreads, Executor executor, EventExecutorChooserFactory chooserFactory, Object... args) {
+  2:     if (nThreads <= 0) {
+  3:         throw new IllegalArgumentException(String.format("nThreads: %d (expected: > 0)", nThreads));
+  4:     }
+  5: 
+  6:     // 创建执行器
+  7:     if (executor == null) {
+  8:         executor = new ThreadPerTaskExecutor(newDefaultThreadFactory());
+  9:     }
+ 10: 
+ 11:     // 创建 EventExecutor 数组
+ 12:     children = new EventExecutor[nThreads];
+ 13: 
+ 14:     for (int i = 0; i < nThreads; i ++) {
+ 15:         boolean success = false; // 是否创建成功
+ 16:         try {
+ 17:             // 创建 EventExecutor 对象
+ 18:             children[i] = newChild(executor, args);
+ 19:             // 标记创建成功
+ 20:             success = true;
+ 21:         } catch (Exception e) {
+ 22:             // 创建失败，抛出 IllegalStateException 异常
+ 23:             // TODO: Think about if this is a good exception type
+ 24:             throw new IllegalStateException("failed to create a child event loop", e);
+ 25:         } finally {
+ 26:             // 创建失败，关闭所有已创建的 EventExecutor
+ 27:             if (!success) {
+ 28:                 // 关闭所有已创建的 EventExecutor
+ 29:                 for (int j = 0; j < i; j ++) {
+ 30:                     children[j].shutdownGracefully();
+ 31:                 }
+ 32:                 // 确保所有已创建的 EventExecutor 已关闭
+ 33:                 for (int j = 0; j < i; j ++) {
+ 34:                     EventExecutor e = children[j];
+ 35:                     try {
+ 36:                         while (!e.isTerminated()) {
+ 37:                             e.awaitTermination(Integer.MAX_VALUE, TimeUnit.SECONDS);
+ 38:                         }
+ 39:                     } catch (InterruptedException interrupted) {
+ 40:                         // Let the caller handle the interruption.
+ 41:                         Thread.currentThread().interrupt();
+ 42:                         break;
+ 43:                     }
+ 44:                 }
+ 45:             }
+ 46:         }
+ 47:     }
+ 48: 
+ 49:     // 创建 EventExecutor 选择器
+ 50:     chooser = chooserFactory.newChooser(children);
+ 51: 
+ 52:     // 创建监听器，用于 EventExecutor 终止时的监听
+ 53:     final FutureListener<Object> terminationListener = new FutureListener<Object>() {
+ 54: 
+ 55:         @Override
+ 56:         public void operationComplete(Future<Object> future) throws Exception {
+ 57:             if (terminatedChildren.incrementAndGet() == children.length) { // 全部关闭
+ 58:                 terminationFuture.setSuccess(null); // 设置结果，并通知监听器们。
+ 59:             }
+ 60:         }
+ 61: 
+ 62:     };
+ 63:     // 设置监听器到每个 EventExecutor 上
+ 64:     for (EventExecutor e: children) {
+ 65:         e.terminationFuture().addListener(terminationListener);
+ 66:     }
+ 67: 
+ 68:     // 创建不可变( 只读 )的 EventExecutor 数组
+ 69:     Set<EventExecutor> childrenSet = new LinkedHashSet<EventExecutor>(children.length);
+ 70:     Collections.addAll(childrenSet, children);
+ 71:     readonlyChildren = Collections.unmodifiableSet(childrenSet);
+ 72: }
+```
+
+- 每个属性的定义，胖友直接看代码注释。
+
+- 方法参数
+
+   
+
+  ```
+  executor
+  ```
+
+   
+
+  ，执行器。详细解析，见
+
+   
+
+  「5.2 ThreadPerTaskExecutor」
+
+   
+
+  。
+
+  - 第 6 至 9 行：若 `executor` 为空，则创建执行器。
+
+- 第 12 行：创建 EventExecutor 数组。
+
+  - 第 18 行：调用 `#newChild(Executor executor, Object... args)` 方法，创建 EventExecutor 对象，然后设置到数组中。
+  - 第 21 至 24 行：创建失败，抛出 IllegalStateException 异常。
+  - 第 25 至 45 行：创建失败，关闭所有已创建的 EventExecutor 。
+
+- 第 50 行：调用 `EventExecutorChooserFactory#newChooser(EventExecutor[] executors)` 方法，创建 EventExecutor 选择器。详细解析，见 [「5.3 EventExecutorChooserFactory」](https://svip.iocoder.cn/Netty/EventLoop-2-EventLoopGroup/#) 。
+
+- 第 52 至 62 行：创建监听器，用于 EventExecutor 终止时的监听。
+
+  - 第 55 至 60 行：回调的具体逻辑是，当所有 EventExecutor 都终止完成时，通过调用 `Future#setSuccess(V result)` 方法，通知监听器们。至于为什么设置的值是 `null` ，因为监听器们不关注具体的结果。
+  - 第 63 至 66 行：设置监听器到每个 EventExecutor 上。
+
+- 第 68 至 71 行：创建不可变( 只读 )的 EventExecutor 数组。
+
+## 5.2 ThreadPerTaskExecutor
+
+`io.netty.util.concurrent.ThreadPerTaskExecutor` ，实现 Executor 接口，每个任务一个线程的执行器实现类。代码如下：
+
+```
+public final class ThreadPerTaskExecutor implements Executor {
+
+    /**
+     * 线程工厂对象
+     */
+    private final ThreadFactory threadFactory;
+
+    public ThreadPerTaskExecutor(ThreadFactory threadFactory) {
+        if (threadFactory == null) {
+            throw new NullPointerException("threadFactory");
+        }
+        this.threadFactory = threadFactory;
+    }
+
+    /**
+     * 执行任务
+     *
+     * @param command 任务
+     */
+    @Override
+    public void execute(Runnable command) {
+        threadFactory.newThread(command).start();
+    }
+
+}
+```
+
+- `threadFactory` 属性，线程工厂对象。Netty 实现自定义的 ThreadFactory 类，为 `io.netty.util.concurrent.DefaultThreadFactory` 。关于 DefaultThreadFactory 比较简单，胖友可以自己看看。
+- `#execute(Runnable command)` 方法，通过 `ThreadFactory#newThread(Runnable)` 方法，创建一个 Thread ，然后调用 `Thread#start()` 方法，**启动线程执行任务**。
+
+## 5.3 EventExecutorChooserFactory
+
+`io.netty.util.concurrent.EventExecutorChooserFactory` ，EventExecutorChooser 工厂接口。代码如下：
+
+```
+public interface EventExecutorChooserFactory {
+
+    /**
+     * 创建一个 EventExecutorChooser 对象
+     *
+     * Returns a new {@link EventExecutorChooser}.
+     */
+    EventExecutorChooser newChooser(EventExecutor[] executors);
+
+    /**
+     *  EventExecutor 选择器接口
+     *
+     * Chooses the next {@link EventExecutor} to use.
+     */
+    @UnstableApi
+    interface EventExecutorChooser {
+
+        /**
+         * 选择下一个 EventExecutor 对象
+         *
+         * Returns the new {@link EventExecutor} to use.
+         */
+        EventExecutor next();
+
+    }
+
+}
+```
+
+- `#newChooser(EventExecutor[] executors)` 方法，创建一个 EventExecutorChooser 对象。
+- EventExecutorChooser 接口，EventExecutor 选择器接口。
+  - `#next()` 方法，选择下一个 EventExecutor 对象。
+
+### 5.3.1 DefaultEventExecutorChooserFactory
+
+`io.netty.util.concurrent.DefaultEventExecutorChooserFactory` ，实现 EventExecutorChooserFactory 接口，默认 EventExecutorChooser 工厂实现类。代码如下
+
+```
+/**
+ * 单例
+ */
+public static final DefaultEventExecutorChooserFactory INSTANCE = new DefaultEventExecutorChooserFactory();
+
+private DefaultEventExecutorChooserFactory() { }
+
+@SuppressWarnings("unchecked")
+@Override
+public EventExecutorChooser newChooser(EventExecutor[] executors) {
+    if (isPowerOfTwo(executors.length)) { // 是否为 2 的幂次方
+        return new PowerOfTwoEventExecutorChooser(executors);
+    } else {
+        return new GenericEventExecutorChooser(executors);
+    }
+}
+
+private static boolean isPowerOfTwo(int val) {
+    return (val & -val) == val;
+}
+```
+
+- `INSTANCE` **静态**属性，单例。
+
+- ```
+  #newChooser(EventExecutor[] executors)
+  ```
+
+   
+
+  方法，调用
+
+   
+
+  ```
+  #isPowerOfTwo(int val)
+  ```
+
+   
+
+  方法，判断 EventExecutor 数组的大小是否为 2 的幂次方。
+
+  - 若是，创建 PowerOfTwoEventExecutorChooser 对象。详细解析，见 [「5.3.3 PowerOfTwoEventExecutorChooser」](https://svip.iocoder.cn/Netty/EventLoop-2-EventLoopGroup/#) 。
+  - 若否，创建 GenericEventExecutorChooser 对象。详细解析，见 [「5.3.2 GenericEventExecutorChooser」](https://svip.iocoder.cn/Netty/EventLoop-2-EventLoopGroup/#) 。
+
+- ```
+  #isPowerOfTwo(int val)
+  ```
+
+   
+
+  方法，为什么
+
+   
+
+  ```
+  (val & -val) == val
+  ```
+
+   
+
+  可以判断数字是否为 2 的幂次方呢？
+
+  - 我们以 8 来举个例子。
+    - 8 的二进制为 `1000` 。
+    - -8 的二进制使用补码表示。所以，先求反生成反码为 `0111` ，然后加一生成补码为 `1000` 。
+    - 8 和 -8 并操作后，还是 8 。
+    - 实际上，以 2 为幂次方的数字，都是最高位为 1 ，剩余位为 0 ，所以对应的负数，求完补码还是自己。
+  - 胖友也可以自己试试非 2 的幂次方数字的效果。
+
+### 5.3.2 GenericEventExecutorChooser
+
+GenericEventExecutorChooser 实现 EventExecutorChooser 接口，通用的 EventExecutor 选择器实现类。代码如下：
+
+> GenericEventExecutorChooser 内嵌在 DefaultEventExecutorChooserFactory 类中。
+
+```
+private static final class GenericEventExecutorChooser implements EventExecutorChooser {
+
+    /**
+     * 自增序列
+     */
+    private final AtomicInteger idx = new AtomicInteger();
+    /**
+     * EventExecutor 数组
+     */
+    private final EventExecutor[] executors;
+
+    GenericEventExecutorChooser(EventExecutor[] executors) {
+        this.executors = executors;
+    }
+
+    @Override
+    public EventExecutor next() {
+        return executors[Math.abs(idx.getAndIncrement() % executors.length)];
+    }
+
+}
+```
+
+- 实现比较**简单**，使用 `idx` 自增，并使用 EventExecutor 数组的大小来取余。
+
+### 5.3.3 PowerOfTwoEventExecutorChooser
+
+PowerOfTwoEventExecutorChooser 实现 EventExecutorChooser 接口，基于 EventExecutor 数组的大小为 2 的幂次方的 EventExecutor 选择器实现类。这是一个优化的实现，代码如下：
+
+> PowerOfTwoEventExecutorChooser 内嵌在 DefaultEventExecutorChooserFactory 类中。
+
+```
+private static final class PowerOfTwoEventExecutorChooser implements EventExecutorChooser {
+
+    /**
+     * 自增序列
+     */
+    private final AtomicInteger idx = new AtomicInteger();
+    /**
+     * EventExecutor 数组
+     */
+    private final EventExecutor[] executors;
+
+    PowerOfTwoEventExecutorChooser(EventExecutor[] executors) {
+        this.executors = executors;
+    }
+
+    @Override
+    public EventExecutor next() {
+        return executors[idx.getAndIncrement() & executors.length - 1];
+    }
+
+}
+```
+
+- 实现比较
+
+  巧妙
+
+  ，通过
+
+   
+
+  ```
+  idx
+  ```
+
+   
+
+  自增，并使用【EventExecutor 数组的大小 - 1】进行进行
+
+   
+
+  ```
+  &
+  ```
+
+   
+
+  并操作。
+
+  - 因为 `-` ( 二元操作符 ) 的计算优先级高于 `&` ( 一元操作符 ) 。
+  - 因为 EventExecutor 数组的大小是以 2 为幂次方的数字，那么减一后，除了最高位是 0 ，剩余位都为 1 ( 例如 8 减一后等于 7 ，而 7 的二进制为 0111 。)，那么无论 `idx` 无论如何递增，再进行 `&` 并操作，都不会超过 EventExecutor 数组的大小。并且，还能保证顺序递增。
+
+## 5.4 newDefaultThreadFactory
+
+`#newDefaultThreadFactory()` 方法，创建线程工厂对象。代码如下：
+
+```
+protected ThreadFactory newDefaultThreadFactory() {
+    return new DefaultThreadFactory(getClass());
+}
+```
+
+- 创建的对象为 DefaultThreadFactory ，并且使用类名作为 `poolType` 。
+
+## 5.5 next
+
+`#next()` 方法，选择下一个 EventExecutor 对象。代码如下：
+
+```
+@Override
+public EventExecutor next() {
+    return chooser.next();
+}
+```
+
+## 5.6 iterator
+
+`#iterator()` 方法，获得 EventExecutor 数组的迭代器。代码如下：
+
+```
+@Override
+public Iterator<EventExecutor> iterator() {
+    return readonlyChildren.iterator();
+}
+```
+
+- 为了避免调用方，获得迭代器后，对 EventExecutor 数组进行修改，所以返回是**不可变**的 EventExecutor 数组 `readonlyChildren` 的迭代器。
+
+## 5.7 executorCount
+
+`#executorCount()` 方法，获得 EventExecutor 数组的大小。代码如下：
+
+```
+public final int executorCount() {
+    return children.length;
+}
+```
+
+## 5.8 newChild
+
+`#newChild(Executor executor, Object... args)` **抽象**方法，创建 EventExecutor 对象。代码如下：
+
+```
+protected abstract EventExecutor newChild(Executor executor, Object... args) throws Exception;
+```
+
+- 子类实现该方法，创建其对应的 EventExecutor 实现类的对象。
+
+## 5.9 关闭相关方法
+
+如下是关闭相关的方法，比较简单，胖友自己研究：
+
+- `#terminationFuture()`
+- `#shutdownGracefully(long quietPeriod, long timeout, TimeUnit unit)`
+- `#shutdown()`
+- `#awaitTermination(long timeout, TimeUnit unit)`
+- `#isShuttingDown()`
+- `#isShutdown()`
+- `#isTerminated()`
+
+# 6. EventLoopGroup
+
+`io.netty.channel.EventExecutorGroup` ，继承 EventExecutorGroup 接口，EventLoop 的分组接口。代码如下：
+
+```
+// ========== 自定义接口 ==========
+
+/**
+ * Register a {@link Channel} with this {@link EventLoop}. The returned {@link ChannelFuture}
+ * will get notified once the registration was complete.
+ */
+ChannelFuture register(Channel channel);
+ChannelFuture register(ChannelPromise promise);
+@Deprecated
+ChannelFuture register(Channel channel, ChannelPromise promise);
+
+// ========== 实现自 EventExecutorGroup 接口 ==========
+
+@Override
+EventLoop next();
+```
+
+- `#next()` 方法，选择下一个 EventLoop 对象。
+- `#register(...)` 方法，注册 Channel 到 EventLoopGroup 中。实际上，EventLoopGroup 会分配一个 EventLoop 给该 Channel 注册。
+
+# 7. MultithreadEventLoopGroup
+
+`io.netty.channel.MultithreadEventLoopGroup` ，实现 EventLoopGroup 接口，继承 MultithreadEventExecutorGroup 抽象类，**基于多线程**的 EventLoop 的分组抽象类。
+
+## 7.1 构造方法
+
+```
+/**
+ * 默认 EventLoop 线程数
+ */
+private static final int DEFAULT_EVENT_LOOP_THREADS;
+
+static {
+    DEFAULT_EVENT_LOOP_THREADS = Math.max(1, SystemPropertyUtil.getInt("io.netty.eventLoopThreads", NettyRuntime.availableProcessors() * 2));
+
+    if (logger.isDebugEnabled()) {
+        logger.debug("-Dio.netty.eventLoopThreads: {}", DEFAULT_EVENT_LOOP_THREADS);
+    }
+}
+
+protected MultithreadEventLoopGroup(int nThreads, Executor executor, Object... args) {
+    super(nThreads == 0 ? DEFAULT_EVENT_LOOP_THREADS : nThreads, executor, args);
+}
+
+protected MultithreadEventLoopGroup(int nThreads, ThreadFactory threadFactory, Object... args) {
+    super(nThreads == 0 ? DEFAULT_EVENT_LOOP_THREADS : nThreads, threadFactory, args);
+}
+
+protected MultithreadEventLoopGroup(int nThreads, Executor executor, EventExecutorChooserFactory chooserFactory, Object... args) {
+    super(nThreads == 0 ? DEFAULT_EVENT_LOOP_THREADS : nThreads, executor, chooserFactory, args);
+}
+```
+
+- ```
+  DEFAULT_EVENT_LOOP_THREADS
+  ```
+
+   
+
+  属性，EventLoopGroup 默认拥有的 EventLoop 数量。因为一个 EventLoop 对应一个线程，所以为 CPU 数量 * 2 。
+
+  - 为什么会 * 2 呢？因为目前 CPU 基本都是超线程，**一个 CPU 可对应 2 个线程**。
+  - 在构造方法未传入 `nThreads` 方法参数时，使用 `DEFAULT_EVENT_LOOP_THREADS` 。
+
+## 7.2 newDefaultThreadFactory
+
+newDefaultThreadFactory
+
+`#newDefaultThreadFactory()` 方法，创建线程工厂对象。代码如下：
+
+```
+@Override
+protected ThreadFactory newDefaultThreadFactory() {
+    return new DefaultThreadFactory(getClass(), Thread.MAX_PRIORITY);
+}
+```
+
+- 覆盖父类方法，增加了线程优先级为 `Thread.MAX_PRIORITY` 。
+
+## 7.3 next
+
+`#next()` 方法，选择下一个 EventLoop 对象。代码如下：
+
+```
+@Override
+public EventLoop next() {
+    return (EventLoop) super.next();
+}
+```
+
+- 覆盖父类方法，将返回值转换成 EventLoop 类。
+
+## 7.4 newChild
+
+`#newChild(Executor executor, Object... args)` **抽象**方法，创建 EventExecutor 对象。代码如下：
+
+```
+@Override
+protected abstract EventLoop newChild(Executor executor, Object... args) throws Exception;
+```
+
+- 覆盖父类方法，返回值改为 EventLoop 类。
+
+## 7.5 register
+
+`#register()` 方法，注册 Channel 到 EventLoopGroup 中。实际上，EventLoopGroup 会分配一个 EventLoop 给该 Channel 注册。代码如下：
+
+```
+@Override
+public ChannelFuture register(Channel channel) {
+    return next().register(channel);
+}
+
+@Override
+public ChannelFuture register(ChannelPromise promise) {
+    return next().register(promise);
+}
+
+@Deprecated
+@Override
+public ChannelFuture register(Channel channel, ChannelPromise promise) {
+    return next().register(channel, promise);
+}
+```
+
+- Channel 注册的 EventLoop ，通过 `#next()` 方法来选择。
+
+# 8. NioEventLoopGroup
+
+`io.netty.channel.nio.NioEventLoopGroup` ，继承 MultithreadEventLoopGroup 抽象类，NioEventLoop 的分组实现类。
+
+## 8.1 构造方法
+
+```
+public NioEventLoopGroup() {
+    this(0);
+}
+
+public NioEventLoopGroup(int nThreads) {
+    this(nThreads, (Executor) null);
+}
+
+public NioEventLoopGroup(int nThreads, ThreadFactory threadFactory) {
+    this(nThreads, threadFactory, SelectorProvider.provider());
+}
+
+public NioEventLoopGroup(int nThreads, Executor executor) {
+    this(nThreads, executor, SelectorProvider.provider());
+}
+
+public NioEventLoopGroup(
+        int nThreads, ThreadFactory threadFactory, final SelectorProvider selectorProvider) {
+    this(nThreads, threadFactory, selectorProvider, DefaultSelectStrategyFactory.INSTANCE);
+}
+
+public NioEventLoopGroup(int nThreads, ThreadFactory threadFactory,
+    final SelectorProvider selectorProvider, final SelectStrategyFactory selectStrategyFactory) {
+    super(nThreads, threadFactory, selectorProvider, selectStrategyFactory, RejectedExecutionHandlers.reject());
+}
+
+public NioEventLoopGroup(int nThreads, Executor executor, final SelectorProvider selectorProvider) {
+    this(nThreads, executor, selectorProvider, DefaultSelectStrategyFactory.INSTANCE);
+}
+
+public NioEventLoopGroup(int nThreads, Executor executor, final SelectorProvider selectorProvider,
+                         final SelectStrategyFactory selectStrategyFactory) {
+    super(nThreads, executor, selectorProvider, selectStrategyFactory, RejectedExecutionHandlers.reject());
+}
+
+public NioEventLoopGroup(int nThreads, Executor executor, EventExecutorChooserFactory chooserFactory,
+                         final SelectorProvider selectorProvider,
+                         final SelectStrategyFactory selectStrategyFactory) {
+    super(nThreads, executor, chooserFactory, selectorProvider, selectStrategyFactory,
+            RejectedExecutionHandlers.reject());
+}
+
+public NioEventLoopGroup(int nThreads, Executor executor, EventExecutorChooserFactory chooserFactory,
+                         final SelectorProvider selectorProvider,
+                         final SelectStrategyFactory selectStrategyFactory,
+                         final RejectedExecutionHandler rejectedExecutionHandler) {
+    super(nThreads, executor, chooserFactory, selectorProvider, selectStrategyFactory, rejectedExecutionHandler);
+}
+```
+
+- 构造方法比较多，主要是明确了父构造方法的
+
+   
+
+  ```
+  Object ... args
+  ```
+
+   
+
+  方法参数：
+
+  - 第一个参数，`selectorProvider` ，`java.nio.channels.spi.SelectorProvider` ，用于创建 Java NIO Selector 对象。
+  - 第二个参数，`selectStrategyFactory` ，`io.netty.channel.SelectStrategyFactory` ，选择策略工厂。详细解析，见后续文章。
+  - 第三个参数，`rejectedExecutionHandler` ，`io.netty.channel.SelectStrategyFactory` ，拒绝执行处理器。详细解析，见后续文章。
+
+## 8.2 newChild
+
+`#newChild(Executor executor, Object... args)` 方法，创建 NioEventLoop 对象。代码如下：
+
+```
+@Override
+protected EventLoop newChild(Executor executor, Object... args) throws Exception {
+    return new NioEventLoop(this, executor,
+            (SelectorProvider) args[0], ((SelectStrategyFactory) args[1]).newSelectStrategy(), (RejectedExecutionHandler) args[2]);
+}
+```
+
+- 通过 `Object... args` 方法参数，传入给 NioEventLoop 创建需要的参数。
+
+## 8.3 setIoRatio
+
+`#setIoRatio(int ioRatio)` 方法，设置所有 EventLoop 的 IO 任务占用执行时间的比例。代码如下：
+
+```
+/**
+ * Sets the percentage of the desired amount of time spent for I/O in the child event loops.  The default value is
+ * {@code 50}, which means the event loop will try to spend the same amount of time for I/O as for non-I/O tasks.
+ */
+public void setIoRatio(int ioRatio) {
+    for (EventExecutor e: this) {
+        ((NioEventLoop) e).setIoRatio(ioRatio);
+    }
+}
+```
+
+## 8.4 rebuildSelectors
+
+`#rebuildSelectors()` 方法，重建所有 EventLoop 的 Selector 对象。代码如下：
+
+```
+/**
+ * Replaces the current {@link Selector}s of the child event loops with newly created {@link Selector}s to work
+ * around the  infamous epoll 100% CPU bug.
+ */
+public void rebuildSelectors() {
+    for (EventExecutor e: this) {
+        ((NioEventLoop) e).rebuildSelector();
+    }
+}
+```
+
+- 因为 JDK 有 [epoll 100% CPU Bug](https://www.jianshu.com/p/da4398743b5a) 。实际上，NioEventLoop 当触发该 Bug 时，也会**自动**调用 `NioEventLoop#rebuildSelector()` 方法，进行重建 Selector 对象，以修复该问题。
+
+# 666. 彩蛋
+
+还是比较简单的文章。如果有不清晰的地方，也可以阅读如下文章：
+
+- 永顺 [《Netty 源码分析之 三 我就是大名鼎鼎的 EventLoop(一)》](https://segmentfault.com/a/1190000007403873#articleHeader2) 的 [「NioEventLoopGroup 实例化过程」](https://svip.iocoder.cn/Netty/EventLoop-2-EventLoopGroup/#) 小节。
+- Hypercube [《自顶向下深入分析Netty（四）—— EventLoop-1》](https://www.jianshu.com/p/da4398743b5a)
\ No newline at end of file
diff --git a/netty/15-Netty 源码解析-EventLoop（三）之 EventLoop 初始化.assets/01-17199756203261.png b/netty/15-Netty 源码解析-EventLoop（三）之 EventLoop 初始化.assets/01-17199756203261.png
new file mode 100644
index 0000000..bf95b54
Binary files /dev/null and b/netty/15-Netty 源码解析-EventLoop（三）之 EventLoop 初始化.assets/01-17199756203261.png differ
diff --git a/netty/15-Netty 源码解析-EventLoop（三）之 EventLoop 初始化.assets/01.png b/netty/15-Netty 源码解析-EventLoop（三）之 EventLoop 初始化.assets/01.png
new file mode 100644
index 0000000..1687e8a
Binary files /dev/null and b/netty/15-Netty 源码解析-EventLoop（三）之 EventLoop 初始化.assets/01.png differ
diff --git a/netty/15-Netty 源码解析-EventLoop（三）之 EventLoop 初始化.assets/02.png b/netty/15-Netty 源码解析-EventLoop（三）之 EventLoop 初始化.assets/02.png
new file mode 100644
index 0000000..393392d
Binary files /dev/null and b/netty/15-Netty 源码解析-EventLoop（三）之 EventLoop 初始化.assets/02.png differ
diff --git a/netty/15-Netty 源码解析-EventLoop（三）之 EventLoop 初始化.assets/03.png b/netty/15-Netty 源码解析-EventLoop（三）之 EventLoop 初始化.assets/03.png
new file mode 100644
index 0000000..4fade55
Binary files /dev/null and b/netty/15-Netty 源码解析-EventLoop（三）之 EventLoop 初始化.assets/03.png differ
diff --git a/netty/15-Netty 源码解析-EventLoop（三）之 EventLoop 初始化.assets/04.png b/netty/15-Netty 源码解析-EventLoop（三）之 EventLoop 初始化.assets/04.png
new file mode 100644
index 0000000..c6a3ab1
Binary files /dev/null and b/netty/15-Netty 源码解析-EventLoop（三）之 EventLoop 初始化.assets/04.png differ
diff --git a/netty/15-Netty 源码解析-EventLoop（三）之 EventLoop 初始化.md b/netty/15-Netty 源码解析-EventLoop（三）之 EventLoop 初始化.md
new file mode 100644
index 0000000..a39c04f
--- /dev/null
+++ b/netty/15-Netty 源码解析-EventLoop（三）之 EventLoop 初始化.md	
@@ -0,0 +1,1460 @@
+# 精尽 Netty 源码解析 —— EventLoop（三）之 EventLoop 初始化
+
+# 1. 概述
+
+本文我们分享 EventLoop 的具体代码实现。因为 EventLoop 涉及的代码量较大，所以笔者会分成好几篇文章分别分享。而本文，我们来分享 EventLoop 的初始化。
+
+但是要将 EventLoop 拆出“初始化”部分的内容，笔者又觉得是件非常困难的事情。所以本文希望能达到如下的效果：
+
+1. 理解 EventLoop 有哪些属性
+2. 创建 EventLoop 的过程
+3. Channel 注册到 EventLoop 的过程
+4. EventLoop 的任务提交。
+   - 虽然任务的提交，比较接近任务的执行，但是考虑到胖友可以更容易的理解 EventLoop ，所以放在本文。
+
+# 2. 类结构图
+
+EventLoopGroup 的整体类结构如下图：
+
+[![EventLoopGroup 类图](15-Netty 源码解析-EventLoop（三）之 EventLoop 初始化.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_05_04/01.png)EventLoopGroup 类图
+
+- 红框部分，为 EventLoopGroup 相关的类关系。**其他部分，为 EventLoop 相关的类关系**。
+- 因为我们实际上使用的是 NioEventLoopGroup 和 **NioEventLoop** ，所以笔者省略了其它相关的类，例如 OioEventLoopGroup、EmbeddedEventLoop 等等。
+
+下面，我们逐层看看每个接口和类的实现代码。
+
+# 3. EventExecutor
+
+`io.netty.util.concurrent.EventExecutor` ，继承 EventExecutorGroup 接口，事件执行器接口。代码如下：
+
+```
+// ========== 实现自 EventExecutorGroup 接口 ==========
+
+/**
+ * 返回自己
+ *
+ * Returns a reference to itself.
+ */
+@Override
+EventExecutor next();
+
+// ========== 自定义接口 ==========
+
+/**
+ * 所属 EventExecutorGroup
+ *
+ * Return the {@link EventExecutorGroup} which is the parent of this {@link EventExecutor},
+ */
+EventExecutorGroup parent();
+
+/**
+ * 当前线程是否在 EventLoop 线程中
+ *
+ * Calls {@link #inEventLoop(Thread)} with {@link Thread#currentThread()} as argument
+ */
+boolean inEventLoop();
+/**
+ * 指定线程是否是 EventLoop 线程
+ *
+ * Return {@code true} if the given {@link Thread} is executed in the event loop,
+ * {@code false} otherwise.
+ */
+boolean inEventLoop(Thread thread);
+
+/**
+ * 创建一个 Promise 对象
+ *
+ * Return a new {@link Promise}.
+ */
+<V> Promise<V> newPromise();
+/**
+ * 创建一个 ProgressivePromise 对象
+ *
+ * Create a new {@link ProgressivePromise}.
+ */
+<V> ProgressivePromise<V> newProgressivePromise();
+/**
+ * 创建成功结果的 Future 对象
+ *
+ * Create a new {@link Future} which is marked as succeeded already. So {@link Future#isSuccess()}
+ * will return {@code true}. All {@link FutureListener} added to it will be notified directly. Also
+ * every call of blocking methods will just return without blocking.
+ */
+<V> Future<V> newSucceededFuture(V result);
+/**
+ * 创建异常的 Future 对象
+ *
+ * Create a new {@link Future} which is marked as failed already. So {@link Future#isSuccess()}
+ * will return {@code false}. All {@link FutureListener} added to it will be notified directly. Also
+ * every call of blocking methods will just return without blocking.
+ */
+<V> Future<V> newFailedFuture(Throwable cause);
+```
+
+- 接口定义的方法比较简单，已经添加中文注释，胖友自己看下。
+
+# 4. OrderedEventExecutor
+
+`io.netty.util.concurrent.OrderedEventExecutor` ，继承 EventExecutor 接口，有序的事件执行器接口。代码如下：
+
+```
+/**
+ * Marker interface for {@link EventExecutor}s that will process all submitted tasks in an ordered / serial fashion.
+ */
+public interface OrderedEventExecutor extends EventExecutor {
+}
+```
+
+- 没有定义任何方法，仅仅是一个标记接口，表示该执行器会有序 / 串行的方式执行。
+
+# 5. EventLoop
+
+`io.netty.channel.EventLoop` ，继承 OrderedEventExecutor 和 EventLoopGroup 接口，EventLoop 接口。代码如下：
+
+```
+/**
+ * Will handle all the I/O operations for a {@link Channel} once registered.
+ *
+ * One {@link EventLoop} instance will usually handle more than one {@link Channel} but this may depend on
+ * implementation details and internals.
+ *
+ */
+public interface EventLoop extends OrderedEventExecutor, EventLoopGroup {
+
+    @Override
+    EventLoopGroup parent();
+
+}
+```
+
+- `#parent()` 接口方法，覆写方法的返回类型为 EventLoopGroup 。
+- 接口上的英文注释，意思如下：
+  - EventLoop 将会处理注册在其上的 Channel 的所有 IO 操作。
+  - 通常，一个 EventLoop 上可以注册不只一个 Channel 。当然，这个也取决于具体的实现。
+
+# 6. AbstractEventExecutor
+
+`io.netty.util.concurrent.AbstractEventExecutor` ，实现 EventExecutor 接口，继承 AbstractExecutorService 抽象类，EventExecutor 抽象类。
+
+## 6.1 构造方法
+
+```
+/**
+ * 所属 EventExecutorGroup
+ */
+private final EventExecutorGroup parent;
+/**
+ * EventExecutor 数组。只包含自己，用于 {@link #iterator()}
+ */
+private final Collection<EventExecutor> selfCollection = Collections.<EventExecutor>singleton(this);
+
+protected AbstractEventExecutor() {
+    this(null);
+}
+
+protected AbstractEventExecutor(EventExecutorGroup parent) {
+    this.parent = parent;
+}
+```
+
+## 6.2 parent
+
+`#parent()` 方法，获得所属 EventExecutorGroup 。代码如下：
+
+```
+@Override
+public EventExecutorGroup parent() {
+    return parent;
+}
+```
+
+## 6.3 next
+
+`#next()` 方法，获得自己。代码如下：
+
+```
+@Override
+public EventExecutor next() {
+    return this;
+}
+```
+
+## 6.4 inEventLoop()
+
+`#inEventLoop()` 方法，判断当前线程是否在 EventLoop 线程中。代码如下：
+
+```
+@Override
+public boolean inEventLoop() {
+    return inEventLoop(Thread.currentThread());
+}
+```
+
+- 具体的 `#inEventLoop(Thread thread)` 方法，需要在子类实现。因为 AbstractEventExecutor 类还体现不出它所拥有的线程。
+
+## 6.5 iterator
+
+`#iterator()` 方法，代码如下：
+
+```
+@Override
+public Iterator<EventExecutor> iterator() {
+    return selfCollection.iterator();
+}
+```
+
+## 6.6 newPromise 和 newProgressivePromise
+
+`#newPromise()` 和 `#newProgressivePromise()` 方法，分别创建 DefaultPromise 和 DefaultProgressivePromise 对象。代码如下：
+
+```
+@Override
+public <V> Promise<V> newPromise() {
+    return new DefaultPromise<V>(this);
+}
+
+@Override
+public <V> ProgressivePromise<V> newProgressivePromise() {
+    return new DefaultProgressivePromise<V>(this);
+}
+```
+
+- 我们可以看到，创建的 Promise 对象，都会传入自身作为 EventExecutor 。关于 Promise 相关的，我们在后续文章详细解析。实在想了解，也可以看看 [《Netty 源码笔记 —— 第四章 Future 和 Promise》](https://www.kancloud.cn/ssj234/netty-source/433215) 。
+
+## 6.7 newSucceededFuture 和 newFailedFuture
+
+`#newSucceededFuture(V result)` 和 `#newFailedFuture(Throwable cause)` 方法，分别创建成功结果和异常的 Future 对象。代码如下：
+
+```
+@Override
+public <V> Future<V> newSucceededFuture(V result) {
+    return new SucceededFuture<V>(this, result);
+}
+
+@Override
+public <V> Future<V> newFailedFuture(Throwable cause) {
+    return new FailedFuture<V>(this, cause);
+}
+```
+
+- 创建的 Future 对象，会传入自身作为 EventExecutor ，并传入 `result` 或 `cause` 分别作为成功结果和异常。
+
+## 6.8 newTaskFor
+
+`#newTaskFor(...)` 方法，创建 PromiseTask 对象。代码如下：
+
+```
+@Override
+protected final <T> RunnableFuture<T> newTaskFor(Runnable runnable, T value) {
+    return new PromiseTask<T>(this, runnable, value);
+}
+
+@Override
+protected final <T> RunnableFuture<T> newTaskFor(Callable<T> callable) {
+    return new PromiseTask<T>(this, callable);
+}
+```
+
+- 创建的 PromiseTask 对象，会传入自身作为 EventExecutor ，并传入 Runnable + Value 或 Callable 作为任务( Task )。
+
+## 6.9 submit
+
+`#submit(...)` 方法，提交任务。代码如下：
+
+```
+@Override
+public Future<?> submit(Runnable task) {
+    return (Future<?>) super.submit(task);
+}
+
+@Override
+public <T> Future<T> submit(Runnable task, T result) {
+    return (Future<T>) super.submit(task, result);
+}
+
+@Override
+public <T> Future<T> submit(Callable<T> task) {
+    return (Future<T>) super.submit(task);
+}
+```
+
+- 每个方法的实现上，是调用父类 AbstractExecutorService 的实现。
+
+## 6.10 schedule
+
+`#schedule(...)` 方法，都不支持，交给子类 AbstractScheduledEventExecutor 实现。代码如下：
+
+```
+@Override
+public ScheduledFuture<?> schedule(Runnable command, long delay, TimeUnit unit) {
+    throw new UnsupportedOperationException();
+}
+@Override
+public <V> ScheduledFuture<V> schedule(Callable<V> callable, long delay, TimeUnit unit) {
+    throw new UnsupportedOperationException();
+}
+
+@Override
+public ScheduledFuture<?> scheduleAtFixedRate(Runnable command, long initialDelay, long period, TimeUnit unit) {
+    throw new UnsupportedOperationException();
+}
+@Override
+public ScheduledFuture<?> scheduleWithFixedDelay(Runnable command, long initialDelay, long delay, TimeUnit unit) {
+    throw new UnsupportedOperationException();
+}
+```
+
+## 6.11 safeExecute
+
+`#safeExecute(Runnable task)` **静态**方法，安全的执行任务。代码如下：
+
+```
+protected static void safeExecute(Runnable task) {
+    try {
+        task.run();
+    } catch (Throwable t) {
+        logger.warn("A task raised an exception. Task: {}", task, t);
+    }
+}
+```
+
+- 所谓“安全”指的是，当任务执行发生异常时，仅仅打印**告警**日志。
+
+## 6.12 shutdown
+
+`#shutdown()` 方法，关闭执行器。代码如下：
+
+```
+@Override
+public Future<?> shutdownGracefully() {
+    return shutdownGracefully(DEFAULT_SHUTDOWN_QUIET_PERIOD, DEFAULT_SHUTDOWN_TIMEOUT, TimeUnit.SECONDS);
+}
+
+@Override
+@Deprecated
+public List<Runnable> shutdownNow() {
+    shutdown();
+    return Collections.emptyList();
+}
+```
+
+- 具体的 `#shutdownGracefully(long quietPeriod, long timeout, TimeUnit unit)` 和 `#shutdown()` 方法的实现，在子类中。
+
+# 7. AbstractScheduledEventExecutor
+
+`io.netty.util.concurrent.AbstractScheduledEventExecutor` ，继承 AbstractEventExecutor 抽象类，**支持定时任务**的 EventExecutor 的抽象类。
+
+详细解析，见 [《精尽 Netty 源码解析 —— EventLoop（七）之 EventLoop 处理定时任务》](http://svip.iocoder.cn/Netty/EventLoop-3-EventLoop-init) 。
+
+# 8. SingleThreadEventExecutor
+
+`io.netty.util.concurrent.SingleThreadEventExecutor` ，实现 OrderedEventExecutor 接口，继承 AbstractScheduledEventExecutor 抽象类，基于单线程的 EventExecutor 抽象类，**即一个 EventExecutor 对应一个线程**。
+
+## 8.1 构造方法
+
+```
+/**
+ * {@link #state} 字段的原子更新器
+ */
+private static final AtomicIntegerFieldUpdater<SingleThreadEventExecutor> STATE_UPDATER =AtomicIntegerFieldUpdater.newUpdater(SingleThreadEventExecutor.class, "state");
+/**
+ * {@link #thread} 字段的原子更新器
+ */
+private static final AtomicReferenceFieldUpdater<SingleThreadEventExecutor, ThreadProperties> PROPERTIES_UPDATER = AtomicReferenceFieldUpdater.newUpdater(SingleThreadEventExecutor.class, ThreadProperties.class, "threadProperties");
+
+/**
+ * 任务队列
+ *
+ * @see #newTaskQueue(int)
+ */
+private final Queue<Runnable> taskQueue;
+/**
+ * 线程
+ */
+private volatile Thread thread;
+/**
+ * 线程属性
+ */
+@SuppressWarnings("unused")
+private volatile ThreadProperties threadProperties;
+/**
+ * 执行器
+ */
+private final Executor executor;
+/**
+ * 线程是否已经打断
+ *
+ * @see #interruptThread()
+ */
+private volatile boolean interrupted;
+
+/**
+ * TODO 1006 EventLoop 优雅关闭
+ */
+private final Semaphore threadLock = new Semaphore(0);
+/**
+ * TODO 1006 EventLoop 优雅关闭
+ */
+private final Set<Runnable> shutdownHooks = new LinkedHashSet<Runnable>();
+/**
+ * 添加任务时，是否唤醒线程{@link #thread}
+ */
+private final boolean addTaskWakesUp;
+/**
+ * 最大等待执行任务数量，即 {@link #taskQueue} 的队列大小
+ */
+private final int maxPendingTasks;
+/**
+ * 拒绝执行处理器
+ *
+ * @see #reject()
+ * @see #reject(Runnable)
+ */
+private final RejectedExecutionHandler rejectedExecutionHandler;
+
+/**
+ * 最后执行时间
+ */
+private long lastExecutionTime;
+
+/**
+ * 状态
+ */
+@SuppressWarnings({ "FieldMayBeFinal", "unused" })
+private volatile int state = ST_NOT_STARTED;
+
+/**
+ * TODO 优雅关闭
+ */
+private volatile long gracefulShutdownQuietPeriod;
+/**
+ * 优雅关闭超时时间，单位：毫秒 TODO 1006 EventLoop 优雅关闭
+ */
+private volatile long gracefulShutdownTimeout;
+/**
+ * 优雅关闭开始时间，单位：毫秒 TODO 1006 EventLoop 优雅关闭
+ */
+private long gracefulShutdownStartTime;
+
+/**
+ * TODO 1006 EventLoop 优雅关闭
+ */
+private final Promise<?> terminationFuture = new DefaultPromise<Void>(GlobalEventExecutor.INSTANCE);
+
+protected SingleThreadEventExecutor(
+        EventExecutorGroup parent, ThreadFactory threadFactory, boolean addTaskWakesUp) {
+    this(parent, new ThreadPerTaskExecutor(threadFactory), addTaskWakesUp);
+}
+
+protected SingleThreadEventExecutor(
+        EventExecutorGroup parent, ThreadFactory threadFactory,
+        boolean addTaskWakesUp, int maxPendingTasks, RejectedExecutionHandler rejectedHandler) {
+    this(parent, new ThreadPerTaskExecutor(threadFactory), addTaskWakesUp, maxPendingTasks, rejectedHandler);
+}
+
+protected SingleThreadEventExecutor(EventExecutorGroup parent, Executor executor, boolean addTaskWakesUp) {
+    this(parent, executor, addTaskWakesUp, DEFAULT_MAX_PENDING_EXECUTOR_TASKS, RejectedExecutionHandlers.reject());
+}
+
+protected SingleThreadEventExecutor(EventExecutorGroup parent, Executor executor,
+                                    boolean addTaskWakesUp, int maxPendingTasks,
+                                    RejectedExecutionHandler rejectedHandler) {
+    super(parent);
+    this.addTaskWakesUp = addTaskWakesUp;
+    this.maxPendingTasks = Math.max(16, maxPendingTasks);
+    this.executor = ObjectUtil.checkNotNull(executor, "executor");
+    taskQueue = newTaskQueue(this.maxPendingTasks);
+    rejectedExecutionHandler = ObjectUtil.checkNotNull(rejectedHandler, "rejectedHandler");
+}
+```
+
+- 属性比较多，我们耐心往下看。
+
+- ```
+  taskQueue
+  ```
+
+   
+
+  属性，任务队列。
+
+  - `addTaskWakesUp` 属性，添加任务到 `taskQueue` 队列时，是否唤醒 `thread` 线程。详细解析，见 [「8.11 execute」](https://svip.iocoder.cn/Netty/EventLoop-3-EventLoop-init/#) 。
+  - `maxPendingTasks` 属性，最大等待执行任务数量，即 `taskQueue` 队列大小。
+  - `rejectedExecutionHandler` 属性，拒绝执行处理器。在 `taskQueue` 队列超过最大任务数量时，怎么拒绝处理新提交的任务。
+
+- `thread` 属性，线程。在 SingleThreadEventExecutor 中，任务是提交到 `taskQueue` 队列中，而执行在 `thread` 线程中。
+
+  - `threadProperties` 属性，线程属性。详细解析，见 [「8.15 threadProperties」](https://svip.iocoder.cn/Netty/EventLoop-3-EventLoop-init/#) 。
+
+  - `executor` 属性，执行器。通过它创建 `thread` 线程。详细解析，见 [「8.11 execute」](https://svip.iocoder.cn/Netty/EventLoop-3-EventLoop-init/#) 。
+
+  - `interrupted` 属性，线程是否打断。详细解析，详细解析，见 [「8.14 interruptThread」](https://svip.iocoder.cn/Netty/EventLoop-3-EventLoop-init/#) 。
+
+  - `lastExecutionTime` 属性，最后执行时间。
+
+  - `state` 属性，线程状态。SingleThreadEventExecutor 在实现上，`thread` 的初始化采用延迟启动的方式，只有在第一个任务时，`executor` 才会执行并创建该线程，从而节省资源。目前 `thread` 线程有 5 种状态，代码如下：
+
+    ```
+    private static final int ST_NOT_STARTED = 1; // 未开始
+    private static final int ST_STARTED = 2; // 已开始
+    private static final int ST_SHUTTING_DOWN = 3; // 正在关闭中
+    private static final int ST_SHUTDOWN = 4; // 已关闭
+    private static final int ST_TERMINATED = 5; // 已经终止
+    ```
+
+    - 状态变更流程如下图：[![状态变更流程](15-Netty 源码解析-EventLoop（三）之 EventLoop 初始化.assets/01-17199756203261.png)](http://static.iocoder.cn/images/Netty/2018_05_07/01.png)状态变更流程
+
+- 构造方法，虽然比较多，但是很简单，胖友自己看下。
+
+## 8.2 newTaskQueue
+
+`#newTaskQueue(int maxPendingTasks)` 方法，创建任务队列。代码如下：
+
+```
+/**
+ * Create a new {@link Queue} which will holds the tasks to execute. This default implementation will return a
+ * {@link LinkedBlockingQueue} but if your sub-class of {@link SingleThreadEventExecutor} will not do any blocking
+ * calls on the this {@link Queue} it may make sense to {@code @Override} this and return some more performant
+ * implementation that does not support blocking operations at all.
+ */
+protected Queue<Runnable> newTaskQueue(int maxPendingTasks) {
+    return new LinkedBlockingQueue<Runnable>(maxPendingTasks);
+}
+```
+
+- 方法上有一大段注释，简单的说，这个方法默认返回的是 LinkedBlockingQueue 阻塞队列。如果子类有更好的队列选择( 例如非阻塞队列 )，可以重写该方法。在下文，我们会看到它的子类 NioEventLoop ，就重写了这个方法。
+
+## 8.3 inEventLoop
+
+`#inEventLoop(Thread thread)` 方法，判断指定线程是否是 EventLoop 线程。代码如下：
+
+```
+@Override
+public boolean inEventLoop(Thread thread) {
+    return thread == this.thread;
+}
+```
+
+## 8.4 offerTask
+
+`#offerTask(Runnable task)` 方法，添加任务到队列中。若添加失败，则返回 `false` 。代码如下：
+
+```
+final boolean offerTask(Runnable task) {
+    // 关闭时，拒绝任务
+    if (isShutdown()) {
+        reject();
+    }
+    // 添加任务到队列
+    return taskQueue.offer(task);
+}
+```
+
+- 注意，即使对于 BlockingQueue 的 `#offer(E e)` 方法，也**不是阻塞的**！
+
+## 8.5 addTask
+
+`#offerTask(Runnable task)` 方法，在 `#offerTask(Runnable task)` 的方法的基础上，若添加任务到队列中失败，则进行拒绝任务。代码如下：
+
+```
+protected void addTask(Runnable task) {
+    if (task == null) {
+        throw new NullPointerException("task");
+    }
+    // 添加任务到队列
+    if (!offerTask(task)) {
+        // 添加失败，则拒绝任务
+        reject(task);
+    }
+}
+```
+
+- 调用 `#reject(task)` 方法，拒绝任务。详细解析，见 [「8.6 reject」](https://svip.iocoder.cn/Netty/EventLoop-3-EventLoop-init/#) 。
+- 该方法是 `void` ，无返回值。
+
+## 8.6 removeTask
+
+`#removeTask(Runnable task)` 方法，移除指定任务。代码如下：
+
+```
+protected boolean removeTask(Runnable task) {
+    if (task == null) {
+        throw new NullPointerException("task");
+    }
+    return taskQueue.remove(task);
+}
+```
+
+## 8.7 peekTask
+
+`#peekTask()` 方法，返回队头的任务，但是**不移除**。代码如下：
+
+```
+protected Runnable peekTask() {
+    assert inEventLoop(); // 仅允许在 EventLoop 线程中执行
+    return taskQueue.peek();
+}
+```
+
+## 8.8 hasTasks
+
+`#hasTasks()` 方法，队列中是否有任务。代码如下：
+
+```
+protected boolean hasTasks() {
+    assert inEventLoop(); // 仅允许在 EventLoop 线程中执行
+    return !taskQueue.isEmpty();
+}
+```
+
+## 8.9 pendingTasks
+
+`#pendingTasks()` 方法，获得队列中的任务数。代码如下：
+
+```
+public int pendingTasks() {
+    return taskQueue.size();
+}
+```
+
+## 8.10 reject
+
+`#reject(Runnable task)` 方法，拒绝任务。代码如下：
+
+```
+protected final void reject(Runnable task) {
+    rejectedExecutionHandler.rejected(task, this);
+}
+```
+
+- 调用 `RejectedExecutionHandler#rejected(Runnable task, SingleThreadEventExecutor executor)` 方法，拒绝该任务。
+
+`#reject()` 方法，拒绝任何任务，用于 SingleThreadEventExecutor 已关闭( `#isShutdown()` 方法返回的结果为 `true` )的情况。代码如下：
+
+```
+protected static void reject() {
+    throw new RejectedExecutionException("event executor terminated");
+}
+```
+
+### 8.10.1 RejectedExecutionHandler
+
+`io.netty.util.concurrent.RejectedExecutionHandler` ，拒绝执行处理器接口。代码如下：
+
+```
+/**
+ * Called when someone tried to add a task to {@link SingleThreadEventExecutor} but this failed due capacity
+ * restrictions.
+ */
+void rejected(Runnable task, SingleThreadEventExecutor executor);
+```
+
+### 8.10.2 RejectedExecutionHandlers
+
+`io.netty.util.concurrent.RejectedExecutionHandlers` ，RejectedExecutionHandler 实现类枚举，目前有 2 种实现类。
+
+**第一种**
+
+```
+private static final RejectedExecutionHandler REJECT = new RejectedExecutionHandler() {
+
+    @Override
+    public void rejected(Runnable task, SingleThreadEventExecutor executor) {
+        throw new RejectedExecutionException();
+    }
+
+};
+
+public static RejectedExecutionHandler reject() {
+    return REJECT;
+}
+```
+
+- 通过 `#reject()` 方法，返回 `REJECT` 实现类的对象。该实现在拒绝时，直接抛出 RejectedExecutionException 异常。
+- 默认情况下，使用这种实现。
+
+**第二种**
+
+```
+public static RejectedExecutionHandler backoff(final int retries, long backoffAmount, TimeUnit unit) {
+    ObjectUtil.checkPositive(retries, "retries");
+    final long backOffNanos = unit.toNanos(backoffAmount);
+    return new RejectedExecutionHandler() {
+        @Override
+        public void rejected(Runnable task, SingleThreadEventExecutor executor) {
+            if (!executor.inEventLoop()) { // 非 EventLoop 线程中。如果在 EventLoop 线程中，就无法执行任务，这就导致完全无法重试了。
+                // 循环多次尝试添加到队列中
+                for (int i = 0; i < retries; i++) {
+                    // 唤醒执行器，进行任务执行。这样，就可能执行掉部分任务。
+                    // Try to wake up the executor so it will empty its task queue.
+                    executor.wakeup(false);
+
+                    // 阻塞等待
+                    LockSupport.parkNanos(backOffNanos);
+                    // 添加任务
+                    if (executor.offerTask(task)) {
+                        return;
+                    }
+                }
+            }
+            // Either we tried to add the task from within the EventLoop or we was not able to add it even with
+            // backoff.
+            // 多次尝试添加失败，抛出 RejectedExecutionException 异常
+            throw new RejectedExecutionException();
+        }
+    };
+}
+```
+
+- 通过 `#backoff(final int retries, long backoffAmount, TimeUnit unit)` 方法，创建带多次尝试添加到任务队列的 RejectedExecutionHandler 实现类。
+- 代码已经添加中文注释，胖友自己理解下，比较简单的。
+
+## 8.11 execute
+
+`#execute(Runnable task)` 方法，执行一个任务。但是方法名无法很完整的体现出具体的方法实现，甚至有一些出入，所以我们直接看源码，代码如下：
+
+```
+ 1: @Override
+ 2: public void execute(Runnable task) {
+ 3:     if (task == null) {
+ 4:         throw new NullPointerException("task");
+ 5:     }
+ 6: 
+ 7:     // 获得当前是否在 EventLoop 的线程中
+ 8:     boolean inEventLoop = inEventLoop();
+ 9:     // 添加到任务队列
+10:     addTask(task);
+11:     if (!inEventLoop) {
+12:         // 创建线程
+13:         startThread();
+14:         // 若已经关闭，移除任务，并进行拒绝
+15:         if (isShutdown() && removeTask(task)) {
+16:             reject();
+17:         }
+18:     }
+19: 
+20:     // 唤醒线程
+21:     if (!addTaskWakesUp && wakesUpForTask(task)) {
+22:         wakeup(inEventLoop);
+23:     }
+24: }
+```
+
+- 第 8 行：调用 `#inEventLoop()` 方法，获得当前是否在 EventLoop 的线程中。
+
+- 第 10 行：调用 `#addTask(Runnable task)` 方法，添加任务到队列中。
+
+- 第 11 行：非 EventLoop 的线程
+
+  - 第 13 行：调用 `#startThread()` 方法，启动 EventLoop **独占**的线程，即 `thread` 属性。详细解析，见 [「8.12 startThread」](https://svip.iocoder.cn/Netty/EventLoop-3-EventLoop-init/#) 。
+  - 第 14 至 17 行：若已经关闭，则移除任务，并拒绝执行。
+
+- 第 20 至 23 行：调用 `#wakeup(boolean inEventLoop)` 方法，唤醒线程。详细解析，见 [「8.13 wakeup」](https://svip.iocoder.cn/Netty/EventLoop-3-EventLoop-init/#) 。
+
+  - 等等，第 21 行的
+
+     
+
+    ```
+    !addTaskWakesUp
+    ```
+
+     
+
+    有点奇怪，不是说好的
+
+     
+
+    ```
+    addTaskWakesUp
+    ```
+
+     
+
+    表示“添加任务时，是否唤醒线程”？！但是，怎么使用
+
+     
+
+    ```
+    !
+    ```
+
+     
+
+    取反了。这样反倒变成了，“添加任务时，是否【
+
+    不
+
+    】唤醒线程”。具体的原因是为什么呢？笔者 Google、Github Netty Issue、和基佬讨论，都未找到解答。目前笔者的理解是：
+
+    ```
+    addTaskWakesUp
+    ```
+
+     
+
+    真正的意思是，“添加任务后，任务是否会自动导致线程唤醒”。为什么呢？
+
+    - 对于 Nio 使用的 NioEventLoop ，它的线程执行任务是基于 Selector 监听感兴趣的事件，所以当任务添加到 `taskQueue` 队列中时，线程是无感知的，所以需要调用 `#wakeup(boolean inEventLoop)` 方法，进行**主动**的唤醒。
+    - 对于 Oio 使用的 ThreadPerChannelEventLoop ，它的线程执行是基于 `taskQueue` 队列监听( **阻塞拉取** )事件和任务，所以当任务添加到 `taskQueue` 队列中时，线程是可感知的，相当于说，进行**被动**的唤醒。
+    - 感谢闪电侠，证实我的理解是正确的。参见：
+      - https://github.com/netty/netty/commit/23d017849429c18e1890b0a5799e5262df4f269f
+        - [![提交图](http://static.iocoder.cn/images/Netty/2018_05_07/05.png)](http://static.iocoder.cn/images/Netty/2018_05_07/05.png)提交图
+
+  - 调用 `#wakesUpForTask(task)` 方法，判断该任务是否需要唤醒线程。代码如下：
+
+    ```
+    protected boolean wakesUpForTask(Runnable task) {
+        return true;
+    }
+    ```
+
+    - 默认返回 `true` 。在 [「9. SingleThreadEventLoop」](https://svip.iocoder.cn/Netty/EventLoop-3-EventLoop-init/#) 中，我们会看到对该方法的重写。
+
+## 8.12 startThread
+
+`#startThread()` 方法，启动 EventLoop **独占**的线程，即 `thread` 属性。代码如下：
+
+```
+ 1: private void doStartThread() {
+ 2:     assert thread == null;
+ 3:     executor.execute(new Runnable() {
+ 4: 
+ 5:         @Override
+ 6:         public void run() {
+ 7:             // 记录当前线程
+ 8:             thread = Thread.currentThread();
+ 9: 
+10:             // 如果当前线程已经被标记打断，则进行打断操作。
+11:             if (interrupted) {
+12:                 thread.interrupt();
+13:             }
+14: 
+15:             boolean success = false; // 是否执行成功
+16: 
+17:             // 更新最后执行时间
+18:             updateLastExecutionTime();
+19:             try {
+20:                 // 执行任务
+21:                 SingleThreadEventExecutor.this.run();
+22:                 success = true; // 标记执行成功
+23:             } catch (Throwable t) {
+24:                 logger.warn("Unexpected exception from an event executor: ", t);
+25:             } finally {
+26:                 // TODO 1006 EventLoop 优雅关闭
+27:                 for (;;) {
+28:                     int oldState = state;
+29:                     if (oldState >= ST_SHUTTING_DOWN || STATE_UPDATER.compareAndSet(
+30:                             SingleThreadEventExecutor.this, oldState, ST_SHUTTING_DOWN)) {
+31:                         break;
+32:                     }
+33:                 }
+34: 
+35:                 // TODO 1006 EventLoop 优雅关闭
+36:                 // Check if confirmShutdown() was called at the end of the loop.
+37:                 if (success && gracefulShutdownStartTime == 0) {
+38:                     if (logger.isErrorEnabled()) {
+39:                         logger.error("Buggy " + EventExecutor.class.getSimpleName() + " implementation; " +
+40:                                 SingleThreadEventExecutor.class.getSimpleName() + ".confirmShutdown() must " +
+41:                                 "be called before run() implementation terminates.");
+42:                     }
+43:                 }
+44: 
+45:                 // TODO 1006 EventLoop 优雅关闭
+46:                 try {
+47:                     // Run all remaining tasks and shutdown hooks.
+48:                     for (;;) {
+49:                         if (confirmShutdown()) {
+50:                             break;
+51:                         }
+52:                     }
+53:                 } finally {
+54:                     try {
+55:                         cleanup(); // 清理，释放资源
+56:                     } finally {
+57:                         STATE_UPDATER.set(SingleThreadEventExecutor.this, ST_TERMINATED);
+58:                         threadLock.release();
+59:                         if (!taskQueue.isEmpty()) {
+60:                             if (logger.isWarnEnabled()) {
+61:                                 logger.warn("An event executor terminated with " +
+62:                                         "non-empty task queue (" + taskQueue.size() + ')');
+63:                             }
+64:                         }
+65: 
+66:                         terminationFuture.setSuccess(null);
+67:                     }
+68:                 }
+69:             }
+70:             
+71:         }
+72:     });
+73: }
+```
+
+- 第 2 行：断言，保证 `thread` 为空。
+
+- 第 3 行 至 72 行：调用 `Executor#execute(Runnable runnable)` 方法，执行任务。下面，我们来详细解析。
+
+- 第 8 行：赋值当前的线程给 `thread` 属性。这就是，每个 SingleThreadEventExecutor 独占的线程的创建方式。
+
+- 第 10 至 13 行：如果当前线程已经被标记打断，则进行打断操作。为什么会有这样的逻辑呢？详细解析，见 [「8.14 interruptThread」](https://svip.iocoder.cn/Netty/EventLoop-3-EventLoop-init/#) 。
+
+- 第 18 行：调用 `#updateLastExecutionTime()` 方法，更新最后执行时间。代码如下：
+
+  ```
+  /**
+   * Updates the internal timestamp that tells when a submitted task was executed most recently.
+   * {@link #runAllTasks()} and {@link #runAllTasks(long)} updates this timestamp automatically, and thus there's
+   * usually no need to call this method.  However, if you take the tasks manually using {@link #takeTask()} or
+   * {@link #pollTask()}, you have to call this method at the end of task execution loop for accurate quiet period
+   * checks.
+   */
+  protected void updateLastExecutionTime() {
+      lastExecutionTime = ScheduledFutureTask.nanoTime();
+  }
+  ```
+
+  - 英文注释，自己看。😈
+
+- 第 21 行：调用 `SingleThreadEventExecutor#run()` 方法，执行任务。详细解析，见 [8.X run](https://svip.iocoder.cn/Netty/EventLoop-3-EventLoop-init/#) 。
+
+- 第 25 至 69 行：TODO 1006 EventLoop 优雅关闭
+
+- 第 55 行：调用 `#cleanup()` 方法，清理释放资源。详细解析，见 [8.X cleanup](https://svip.iocoder.cn/Netty/EventLoop-3-EventLoop-init/#) 。
+
+## 8.13 wakeup
+
+`#wakeup(boolean inEventLoop)` 方法，唤醒线程。代码如下：
+
+```
+protected void wakeup(boolean inEventLoop) {
+    if (!inEventLoop // <1>
+            || state == ST_SHUTTING_DOWN) { // TODO 1006 EventLoop 优雅关闭
+        // Use offer as we actually only need this to unblock the thread and if offer fails we do not care as there
+        // is already something in the queue.
+        taskQueue.offer(WAKEUP_TASK); // <2>
+    }
+}
+```
+
+- `<1>` 处的 `!inEventLoop` 代码段，判断不在 EventLoop 的线程中。因为，如果在 EventLoop 线程中，意味着线程就在执行中，不必要唤醒。
+
+- `<2>` 处，调用 `Queue#offer(E e)` 方法，添加任务到队列中。而添加的任务是 `WAKEUP_TASK` ，代码如下：
+
+  ```
+  private static final Runnable WAKEUP_TASK = new Runnable() {
+      @Override
+      public void run() {
+          // Do nothing.
+      }
+  };
+  ```
+
+  - 这是一个空的 Runnable 实现类。仅仅用于唤醒基于 `taskQueue` 阻塞拉取的 EventLoop 实现类。
+
+  - 对于 NioEventLoop 会重写该方法，代码如下：
+
+    ```
+    @Override
+    protected void wakeup(boolean inEventLoop) {
+        if (!inEventLoop && wakenUp.compareAndSet(false, true)) {
+            selector.wakeup();
+        }
+    }
+    ```
+
+    - 通过 NIO Selector 唤醒。
+
+## 8.14 interruptThread
+
+`#interruptThread()` 方法，打断 EventLoop 的线程。代码如下：
+
+```
+protected void interruptThread() {
+    Thread currentThread = thread;
+    // 线程不存在，则标记线程被打断
+    if (currentThread == null) {
+        interrupted = true;
+    // 打断线程
+    } else {
+        currentThread.interrupt();
+    }
+}
+```
+
+- 因为 EventLoop 的线程是延迟启动，所以可能 `thread` 并未创建，此时通过 `interrupted` 标记打断。之后在 `#startThread()` 方法中，创建完线程后，再进行打断，也就是说，“延迟打断”。
+
+## 8.15 threadProperties
+
+`#threadProperties()` 方法，获得 EventLoop 的线程属性。代码如下：
+
+```
+ 1: public final ThreadProperties threadProperties() {
+ 2:     ThreadProperties threadProperties = this.threadProperties;
+ 3:     if (threadProperties == null) {
+ 4:         Thread thread = this.thread;
+ 5:         if (thread == null) {
+ 6:             assert !inEventLoop();
+ 7:             // 提交空任务，促使 execute 方法执行
+ 8:             submit(NOOP_TASK).syncUninterruptibly();
+ 9:             // 获得线程
+10:             thread = this.thread;
+11:             assert thread != null;
+12:         }
+13: 
+14:         // 创建 DefaultThreadProperties 对象
+15:         threadProperties = new DefaultThreadProperties(thread);
+16:         // CAS 修改 threadProperties 属性
+17:         if (!PROPERTIES_UPDATER.compareAndSet(this, null, threadProperties)) {
+18:             threadProperties = this.threadProperties;
+19:         }
+20:     }
+21: 
+22:     return threadProperties;
+23: }
+```
+
+- 第 2 至 3 行：获得 ThreadProperties 对象。若不存在，则进行创建 ThreadProperties 对象。
+  - 第 4 至 5 行：获得 EventLoop 的线程。因为线程是延迟启动的，所以会出现线程为空的情况。若线程为空，则需要进行创建。
+    - 第 8 行：调用 `#submit(Runnable)` 方法，提交任务，就能促使 `#execute(Runnable)` 方法执行。如下图所示：[![submit => execute 的流程](15-Netty 源码解析-EventLoop（三）之 EventLoop 初始化.assets/02.png)](http://static.iocoder.cn/images/Netty/2018_05_07/02.png)submit => execute 的流程
+    - 第 8 行：调用 `Future#syncUninterruptibly()` 方法，保证 `execute()` 方法中**异步**创建 `thread` 完成。
+    - 第 10 至 11 行：获得线程，并断言保证线程存在。
+  - 第 15 行：调用 DefaultThreadProperties 对象。
+  - 第 16 至 19 行：CAS 修改 `threadProperties` 属性。
+- 第 22 行：返回 `threadProperties` 。
+
+### 8.15.1 ThreadProperties
+
+`io.netty.util.concurrent.ThreadProperties` ，线程属性接口。代码如下：
+
+```
+Thread.State state();
+
+int priority();
+
+boolean isInterrupted();
+
+boolean isDaemon();
+
+String name();
+
+long id();
+
+StackTraceElement[] stackTrace();
+
+boolean isAlive();
+```
+
+### 8.15.2 DefaultThreadProperties
+
+DefaultThreadProperties 实现 ThreadProperties 接口，默认线程属性实现类。代码如下：
+
+> DefaultThreadProperties 内嵌在 SingleThreadEventExecutor 中。
+
+```
+private static final class DefaultThreadProperties implements ThreadProperties {
+
+    private final Thread t;
+
+    DefaultThreadProperties(Thread t) {
+        this.t = t;
+    }
+
+    @Override
+    public State state() {
+        return t.getState();
+    }
+
+    @Override
+    public int priority() {
+        return t.getPriority();
+    }
+
+    @Override
+    public boolean isInterrupted() {
+        return t.isInterrupted();
+    }
+
+    @Override
+    public boolean isDaemon() {
+        return t.isDaemon();
+    }
+
+    @Override
+    public String name() {
+        return t.getName();
+    }
+
+    @Override
+    public long id() {
+        return t.getId();
+    }
+
+    @Override
+    public StackTraceElement[] stackTrace() {
+        return t.getStackTrace();
+    }
+
+    @Override
+    public boolean isAlive() {
+        return t.isAlive();
+    }
+
+}
+```
+
+- 我们可以看到，每个实现方法，实际上就是对被包装的线程 `t` 的方法的封装。
+- 那为什么 `#threadProperties()` 方法不直接返回 `thread` 呢？因为如果直接返回 `thread` ，调用方可以调用到该变量的其他方法，这个是我们不希望看到的。
+
+## 8.16 run
+
+`#run()` 方法，它是一个**抽象方法**，由子类实现，如何执行 `taskQueue` 队列中的任务。代码如下：
+
+```
+protected abstract void run();
+```
+
+SingleThreadEventExecutor 提供了很多执行任务的方法，方便子类在实现自定义运行任务的逻辑时：
+
+- [x] `#runAllTasks()`
+- [x] `#runAllTasks(long timeoutNanos)`
+- [x] `#runAllTasksFrom(Queue<Runnable> taskQueue)`
+- [x] `#afterRunningAllTasks()`
+- [x] `#pollTask()`
+- [x] `#pollTaskFrom(Queue<Runnable> taskQueue)`
+- `#takeTask()`
+- `#fetchFromScheduledTaskQueue()`
+- `#delayNanos(long currentTimeNanos)`
+
+详细解析，见 [《精尽 Netty 源码解析 —— EventLoop（四）之 EventLoop 运行》](http://svip.iocoder.cn/Netty/EventLoop-4-EventLoop-run) 。
+
+## 8.17 cleanup
+
+`#cleanup()` 方法，清理释放资源。代码如下：
+
+```
+/**
+ * Do nothing, sub-classes may override
+ */
+protected void cleanup() {
+    // NOOP
+}
+```
+
+- 目前该方法为空的。在子类 NioEventLoop 中，我们会看到它覆写该方法，关闭 NIO Selector 对象。
+
+## 8.18 invokeAll
+
+`#invokeAll(...)` 方法，在 EventExecutor 中执行**多个**普通任务。代码如下：
+
+```
+@Override
+public <T> List<java.util.concurrent.Future<T>> invokeAll(Collection<? extends Callable<T>> tasks)
+        throws InterruptedException {
+    throwIfInEventLoop("invokeAll");
+    return super.invokeAll(tasks);
+}
+
+@Override
+public <T> List<java.util.concurrent.Future<T>> invokeAll(
+        Collection<? extends Callable<T>> tasks, long timeout, TimeUnit unit) throws InterruptedException {
+    throwIfInEventLoop("invokeAll");
+    return super.invokeAll(tasks, timeout, unit);
+}
+```
+
+- 调用 `#throwIfInEventLoop(String method)` 方法，判断若在 EventLoop 的线程中调用该方法，抛出 RejectedExecutionException 异常。代码如下：
+
+  ```
+  private void throwIfInEventLoop(String method) {
+      if (inEventLoop()) {
+          throw new RejectedExecutionException("Calling " + method + " from within the EventLoop is not allowed");
+      }
+  }
+  ```
+
+- 调用父类 AbstractScheduledEventExecutor 的 `#invokeAll(tasks, ...)` 方法，执行**多个**普通任务。在该方法内部，会调用 `#execute(Runnable task)` 方法，执行任务。调用栈如下图：[![invokeAll => execute 的流程](15-Netty 源码解析-EventLoop（三）之 EventLoop 初始化.assets/03.png)](http://static.iocoder.cn/images/Netty/2018_05_07/03.png)invokeAll => execute 的流程
+
+## 8.19 invokeAny
+
+> 和 `#invokeAll(...)` 方法，**类似**。
+
+`#invokeAll(...)` 方法，在 EventExecutor 中执行**多个**普通任务，有**一个**执行完成即可。代码如下：
+
+```
+@Override
+public <T> T invokeAny(Collection<? extends Callable<T>> tasks) throws InterruptedException, ExecutionException {
+    throwIfInEventLoop("invokeAny");
+    return super.invokeAny(tasks);
+}
+
+@Override
+public <T> T invokeAny(Collection<? extends Callable<T>> tasks, long timeout, TimeUnit unit)
+        throws InterruptedException, ExecutionException, TimeoutException {
+    throwIfInEventLoop("invokeAny");
+    return super.invokeAny(tasks, timeout, unit);
+}
+```
+
+- 调用 `#throwIfInEventLoop(String method)` 方法，判断若在 EventLoop 的线程中调用该方法，抛出 RejectedExecutionException 异常。
+- 调用父类 AbstractScheduledEventExecutor 的 `#invokeAny(tasks, ...)` 方法，执行**多个**普通任务，有**一个**执行完成即可。在该方法内部，会调用 `#execute(Runnable task)` 方法，执行任务。调用栈如下图：[![invokeAny => execute 的流程](15-Netty 源码解析-EventLoop（三）之 EventLoop 初始化.assets/04.png)](http://static.iocoder.cn/images/Netty/2018_05_07/04.png)invokeAny => execute 的流程
+
+## 8.20 shutdown
+
+如下是优雅关闭，我们在 TODO 1006 EventLoop 优雅关闭
+
+- `#addShutdownHook(final Runnable task)`
+- `#removeShutdownHook(final Runnable task)`
+- `#runShutdownHooks()`
+- `#shutdownGracefully(long quietPeriod, long timeout, TimeUnit unit)`
+- `#shutdown()`
+- `#terminationFuture()`
+- `#isShuttingDown()`
+- `#isShutdown()`
+- `#isTerminated()`
+- `#confirmShutdown()`
+- `#awaitTermination(long timeout, TimeUnit unit)`
+
+# 9. SingleThreadEventLoop
+
+`io.netty.channel.SingleThreadEventLoop` ，实现 EventLoop 接口，继承 SingleThreadEventExecutor 抽象类，基于单线程的 EventLoop 抽象类，主要增加了 Channel 注册到 EventLoop 上。
+
+## 9.1 构造方法
+
+```
+/**
+ * 默认任务队列最大数量
+ */
+protected static final int DEFAULT_MAX_PENDING_TASKS = Math.max(16, SystemPropertyUtil.getInt("io.netty.eventLoop.maxPendingTasks", Integer.MAX_VALUE));
+
+/**
+ * 尾部任务队列，执行在 {@link #taskQueue} 之后
+ *
+ * Commits
+ *  * [Ability to run a task at the end of an eventloop iteration.](https://github.com/netty/netty/pull/5513)
+ *
+ * Issues
+ *  * [Auto-flush for channels. (`ChannelHandler` implementation)](https://github.com/netty/netty/pull/5716)
+ *  * [Consider removing executeAfterEventLoopIteration](https://github.com/netty/netty/issues/7833)
+ *
+ * 老艿艿：未来会移除该队列，前提是实现了 Channel 的 auto flush 功能。按照最后一个 issue 的讨论
+ */
+private final Queue<Runnable> tailTasks;
+
+protected SingleThreadEventLoop(EventLoopGroup parent, ThreadFactory threadFactory, boolean addTaskWakesUp) {
+    this(parent, threadFactory, addTaskWakesUp, DEFAULT_MAX_PENDING_TASKS, RejectedExecutionHandlers.reject());
+}
+
+protected SingleThreadEventLoop(EventLoopGroup parent, Executor executor, boolean addTaskWakesUp) {
+    this(parent, executor, addTaskWakesUp, DEFAULT_MAX_PENDING_TASKS, RejectedExecutionHandlers.reject());
+}
+
+protected SingleThreadEventLoop(EventLoopGroup parent, ThreadFactory threadFactory,
+                                boolean addTaskWakesUp, int maxPendingTasks,
+                                RejectedExecutionHandler rejectedExecutionHandler) {
+    super(parent, threadFactory, addTaskWakesUp, maxPendingTasks, rejectedExecutionHandler);
+    tailTasks = newTaskQueue(maxPendingTasks);
+}
+
+protected SingleThreadEventLoop(EventLoopGroup parent, Executor executor,
+                                boolean addTaskWakesUp, int maxPendingTasks,
+                                RejectedExecutionHandler rejectedExecutionHandler) {
+    super(parent, executor, addTaskWakesUp, maxPendingTasks, rejectedExecutionHandler);
+    tailTasks = newTaskQueue(maxPendingTasks);
+}
+```
+
+- 新增了一条 `tailTasks` 队列，执行的顺序在 `taskQueue` 之后。详细解析，见 [《精尽 Netty 源码解析 —— EventLoop（六）之 EventLoop 处理普通任务》](http://svip.iocoder.cn/Netty/EventLoop-6-EventLoop-handle-normal-task) 。
+- 构造方法比较简单，胖友自己看下就可以了。
+
+## 9.2 parent
+
+`#parent()` 方法，获得所属 EventLoopGroup 。代码如下：
+
+```
+@Override
+public EventLoopGroup parent() {
+    return (EventLoopGroup) super.parent();
+}
+```
+
+- 覆盖父类方法，将返回值转换成 EventLoopGroup 类。
+
+## 9.3 next
+
+`#next()` 方法，获得自己。代码如下：
+
+```
+@Override
+public EventLoop next() {
+    return (EventLoop) super.next();
+}
+```
+
+- 覆盖父类方法，将返回值转换成 EventLoop 类。
+
+## 9.4 register
+
+`#register(Channel channel)` 方法，注册 Channel 到 EventLoop 上。代码如下：
+
+```
+@Override
+public ChannelFuture register(Channel channel) {
+    return register(new DefaultChannelPromise(channel, this));
+}
+```
+
+- 将 Channel 和 EventLoop 创建一个 DefaultChannelPromise 对象。通过这个 DefaultChannelPromise 对象，我们就能实现对**异步**注册过程的监听。
+
+- 调用 `#register(final ChannelPromise promise)` 方法，注册 Channel 到 EventLoop 上。代码如下：
+
+  ```
+  @Override
+  public ChannelFuture register(final ChannelPromise promise) {
+      ObjectUtil.checkNotNull(promise, "promise");
+      // 注册 Channel 到 EventLoop 上
+      promise.channel().unsafe().register(this, promise);
+      // 返回 ChannelPromise 对象
+      return promise;
+  }
+  ```
+
+  - 在方法内部，我们就看到在 [《精尽 Netty 源码分析 —— 启动（一）之服务端》](http://svip.iocoder.cn/Netty/bootstrap-1-server?self) 的 [「3.14.3 注册 Channel 到 EventLoopGroup」](https://svip.iocoder.cn/Netty/EventLoop-3-EventLoop-init/#) 章节，熟悉的内容，调用 `AbstractUnsafe#register(EventLoop eventLoop, final ChannelPromise promise)` 方法，**注册 Channel 到 EventLoop 上**。
+
+## 9.5 hasTasks
+
+`#hasTasks()` 方法，队列中是否有任务。代码如下：
+
+```
+@Override
+protected boolean hasTasks() {
+    return super.hasTasks() || !tailTasks.isEmpty();
+}
+```
+
+- 基于两个队列来判断是否还有任务。
+
+## 9.6 pendingTasks
+
+`#pendingTasks()` 方法，获得队列中的任务数。代码如下：
+
+```
+@Override
+public int pendingTasks() {
+    return super.pendingTasks() + tailTasks.size();
+}
+```
+
+- 计算两个队列的任务之和。
+
+## 9.7 executeAfterEventLoopIteration
+
+`#executeAfterEventLoopIteration(Runnable task)` 方法，执行一个任务。但是方法名无法很完整的体现出具体的方法实现，甚至有一些出入，所以我们直接看源码，代码如下：
+
+```
+ 1: @UnstableApi
+ 2: public final void executeAfterEventLoopIteration(Runnable task) {
+ 3:     ObjectUtil.checkNotNull(task, "task");
+ 4:     // 关闭时，拒绝任务
+ 5:     if (isShutdown()) {
+ 6:         reject();
+ 7:     }
+ 8: 
+ 9:     // 添加到任务队列
+10:     if (!tailTasks.offer(task)) {
+11:         // 添加失败，则拒绝任务
+12:         reject(task);
+13:     }
+14: 
+15:     // 唤醒线程
+16:     if (wakesUpForTask(task)) {
+17:         wakeup(inEventLoop());
+18:     }
+19: }
+```
+
+- 第 4 至 7 行：SingleThreadEventLoop 关闭时，拒绝任务。
+
+- 第 10 行：调用
+
+   
+
+  ```
+  Queue#offer(E e)
+  ```
+
+   
+
+  方法，添加任务到队列中。
+
+  - 第 12 行：若添加失败，调用 `#reject(Runnable task)` 方法，拒绝任务。
+
+- 第 15 至 18 行：唤醒线程。
+
+  - 第 16 行：SingleThreadEventLoop 重写了 `#wakesUpForTask(Runnable task)` 方法。详细解析，见 [「9.9 wakesUpForTask」](https://svip.iocoder.cn/Netty/EventLoop-3-EventLoop-init/#) 。
+
+## 9.8 removeAfterEventLoopIterationTask
+
+`#removeAfterEventLoopIterationTask(Runnable task)` 方法，移除指定任务。代码如下：
+
+```
+@UnstableApi
+final boolean removeAfterEventLoopIterationTask(Runnable task) {
+    return tailTasks.remove(ObjectUtil.checkNotNull(task, "task"));
+}
+```
+
+## 9.9 wakesUpForTask
+
+`#wakesUpForTask(task)` 方法，判断该任务是否需要唤醒线程。代码如下：
+
+```
+@Override
+protected boolean wakesUpForTask(Runnable task) {
+    return !(task instanceof NonWakeupRunnable);
+}
+```
+
+- 当任务类型为 NonWakeupRunnable ，则不进行唤醒线程。
+
+### 9.9.1 NonWakeupRunnable
+
+NonWakeupRunnable 实现 Runnable 接口，用于标记不唤醒线程的任务。代码如下：
+
+```
+/**
+ * Marker interface for {@link Runnable} that will not trigger an {@link #wakeup(boolean)} in all cases.
+ */
+interface NonWakeupRunnable extends Runnable { }
+```
+
+## 9.10 afterRunningAllTasks
+
+`#afterRunningAllTasks()` 方法，在运行完所有任务后，执行 `tailTasks` 队列中的任务。代码如下：
+
+```
+protected void afterRunningAllTasks() {
+    runAllTasksFrom(tailTasks);
+}
+```
+
+- 调用 `#runAllTasksFrom(queue)` 方法，执行 `tailTasks` 队列中的所有任务。
+
+# 10. NioEventLoop
+
+`io.netty.channel.nio.NioEventLoop` ，继承 SingleThreadEventLoop 抽象类，NIO EventLoop 实现类，实现对注册到其中的 Channel 的就绪的 IO 事件，和对用户提交的任务进行处理。
+
+详细解析，见 [《精尽 Netty 源码解析 —— EventLoop（四）之 EventLoop 运行》](http://svip.iocoder.cn/Netty/EventLoop-4-EventLoop-run) 。
+
+# 666. 彩蛋
+
+自顶向下的过了下 EventLoop 相关的类和方法。因为仅涉及 EventLoop 初始化相关的内容，所以对于 EventLoop 运行相关的内容，就不得不省略了。
+
+那么，饥渴难耐的我们，[《精尽 Netty 源码解析 —— EventLoop（四）之 EventLoop 运行》](http://svip.iocoder.cn/Netty/EventLoop-4-EventLoop-run) ，走起！
+
+------
+
+推荐阅读如下文章：
+
+- 永顺 [《Netty 源码分析之 三 我就是大名鼎鼎的 EventLoop(一)》](https://segmentfault.com/a/1190000007403873#articleHeader7) 的 [「NioEventLoop」](https://svip.iocoder.cn/Netty/EventLoop-3-EventLoop-init/#) 小节。
+- Hypercube [《自顶向下深入分析Netty（四）—— EventLoop-2》](https://www.jianshu.com/p/d0f06b13e2fb)
\ No newline at end of file
diff --git a/netty/16-Netty 源码解析-EventLoop（四）之 EventLoop 运行.assets/01.png b/netty/16-Netty 源码解析-EventLoop（四）之 EventLoop 运行.assets/01.png
new file mode 100644
index 0000000..a760792
Binary files /dev/null and b/netty/16-Netty 源码解析-EventLoop（四）之 EventLoop 运行.assets/01.png differ
diff --git a/netty/16-Netty 源码解析-EventLoop（四）之 EventLoop 运行.md b/netty/16-Netty 源码解析-EventLoop（四）之 EventLoop 运行.md
new file mode 100644
index 0000000..7bbf51c
--- /dev/null
+++ b/netty/16-Netty 源码解析-EventLoop（四）之 EventLoop 运行.md	
@@ -0,0 +1,965 @@
+# 精尽 Netty 源码解析 —— EventLoop（四）之 EventLoop 运行
+
+# 1. 概述
+
+本文我们分享 EventLoop 的**运行**相关代码的实现。
+
+因为 EventLoop 的**运行**主要是通过 NioEventLoop 的 `#run()` 方法实现，考虑到内容相对的完整性，在 [《精尽 Netty 源码解析 —— EventLoop（三）之 EventLoop 初始化》](http://svip.iocoder.cn/) 一文中，我们并未分享 NioEventLoop 的**初始化**，所以本文也会分享这部分的内容。
+
+OK ，还是老样子，自上而下的方式，一起来看看 NioEventLoop 的代码实现。
+
+> 老艿艿，本文的重点在 [「2.9 run」](https://svip.iocoder.cn/Netty/EventLoop-4-EventLoop-run/#) 和 [「2.12 select」](https://svip.iocoder.cn/Netty/EventLoop-4-EventLoop-run/#) 中。
+
+# 2. NioEventLoop
+
+`io.netty.channel.nio.NioEventLoop` ，继承 SingleThreadEventLoop 抽象类，NIO EventLoop 实现类，实现对注册到其中的 Channel 的就绪的 IO 事件，和对用户提交的任务进行处理。
+
+## 2.1 static
+
+在 `static` 代码块中，初始化了 NioEventLoop 的静态属性们。代码如下：
+
+```
+/**
+ * TODO 1007 NioEventLoop cancel
+ */
+private static final int CLEANUP_INTERVAL = 256; // XXX Hard-coded value, but won't need customization.
+
+/**
+ * 是否禁用 SelectionKey 的优化，默认开启
+ */
+private static final boolean DISABLE_KEYSET_OPTIMIZATION = SystemPropertyUtil.getBoolean("io.netty.noKeySetOptimization", false);
+
+/**
+ * 少于该 N 值，不开启空轮询重建新的 Selector 对象的功能
+ */
+private static final int MIN_PREMATURE_SELECTOR_RETURNS = 3;
+/**
+ * NIO Selector 空轮询该 N 次后，重建新的 Selector 对象
+ */
+private static final int SELECTOR_AUTO_REBUILD_THRESHOLD;
+
+static {
+    // 解决 Selector#open() 方法 // <1>
+    final String key = "sun.nio.ch.bugLevel";
+    final String buglevel = SystemPropertyUtil.get(key);
+    if (buglevel == null) {
+        try {
+            AccessController.doPrivileged(new PrivilegedAction<Void>() {
+                @Override
+                public Void run() {
+                    System.setProperty(key, "");
+                    return null;
+                }
+            });
+        } catch (final SecurityException e) {
+            logger.debug("Unable to get/set System Property: " + key, e);
+        }
+    }
+
+    // 初始化
+    int selectorAutoRebuildThreshold = SystemPropertyUtil.getInt("io.netty.selectorAutoRebuildThreshold", 512);
+    if (selectorAutoRebuildThreshold < MIN_PREMATURE_SELECTOR_RETURNS) {
+        selectorAutoRebuildThreshold = 0;
+    }
+    SELECTOR_AUTO_REBUILD_THRESHOLD = selectorAutoRebuildThreshold;
+
+    if (logger.isDebugEnabled()) {
+        logger.debug("-Dio.netty.noKeySetOptimization: {}", DISABLE_KEYSET_OPTIMIZATION);
+        logger.debug("-Dio.netty.selectorAutoRebuildThreshold: {}", SELECTOR_AUTO_REBUILD_THRESHOLD);
+    }
+}
+```
+
+- `CLEANUP_INTERVAL` 属性，TODO 1007 NioEventLoop cancel
+
+- `DISABLE_KEYSET_OPTIMIZATION` 属性，是否禁用 SelectionKey 的优化，默认开启。详细解析，见 [《精尽 Netty 源码解析 —— EventLoop（五）之 EventLoop 处理 IO 事件》](http://svip.iocoder.cn/Netty/EventLoop-5-EventLoop-handle-io-event?self) 。
+
+- ```
+  SELECTOR_AUTO_REBUILD_THRESHOLD
+  ```
+
+   
+
+  属性，NIO Selector 空轮询该 N 次后，重建新的 Selector 对象，用以解决 JDK NIO 的 epoll 空轮询 Bug 。
+
+  - `MIN_PREMATURE_SELECTOR_RETURNS` 属性，少于该 N 值，不开启空轮询重建新的 Selector 对象的功能。
+
+- `<1>` 处，解决 `Selector#open()` 方法，发生 NullPointException 异常。详细解析，见 http://bugs.sun.com/view_bug.do?bug_id=6427854 和 https://github.com/netty/netty/issues/203 。
+
+- `<2>` 处，初始化 `SELECTOR_AUTO_REBUILD_THRESHOLD` 属性。默认 512 。
+
+## 2.2 构造方法
+
+```
+/**
+ * The NIO {@link Selector}.
+ *
+ * 包装的 Selector 对象，经过优化
+ *
+ * {@link #openSelector()}
+ */
+private Selector selector;
+/**
+ * 未包装的 Selector 对象
+ */
+private Selector unwrappedSelector;
+/**
+ * 注册的 SelectionKey 集合。Netty 自己实现，经过优化。
+ */
+private SelectedSelectionKeySet selectedKeys;
+/**
+ * SelectorProvider 对象，用于创建 Selector 对象
+ */
+private final SelectorProvider provider;
+
+/**
+ * Boolean that controls determines if a blocked Selector.select should
+ * break out of its selection process. In our case we use a timeout for
+ * the select method and the select method will block for that time unless
+ * waken up.
+ *
+ * 唤醒标记。因为唤醒方法 {@link Selector#wakeup()} 开销比较大，通过该标识，减少调用。
+ *
+ * @see #wakeup(boolean)
+ * @see #run() 
+ */
+private final AtomicBoolean wakenUp = new AtomicBoolean();
+/**
+ * Select 策略
+ *
+ * @see #select(boolean)
+ */
+private final SelectStrategy selectStrategy;
+/**
+ * 处理 Channel 的就绪的 IO 事件，占处理任务的总时间的比例
+ */
+private volatile int ioRatio = 50;
+/**
+ * 取消 SelectionKey 的数量
+ *
+ * TODO 1007 NioEventLoop cancel
+ */
+private int cancelledKeys;
+/**
+ * 是否需要再次 select Selector 对象
+ *
+ * TODO 1007 NioEventLoop cancel
+ */
+private boolean needsToSelectAgain;
+
+NioEventLoop(NioEventLoopGroup parent, Executor executor, SelectorProvider selectorProvider,
+             SelectStrategy strategy, RejectedExecutionHandler rejectedExecutionHandler) {
+    super(parent, executor, false, DEFAULT_MAX_PENDING_TASKS, rejectedExecutionHandler);
+    if (selectorProvider == null) {
+        throw new NullPointerException("selectorProvider");
+    }
+    if (strategy == null) {
+        throw new NullPointerException("selectStrategy");
+    }
+    provider = selectorProvider;
+    // 创建 Selector 对象 <1>
+    final SelectorTuple selectorTuple = openSelector();
+    selector = selectorTuple.selector;
+    unwrappedSelector = selectorTuple.unwrappedSelector;
+    selectStrategy = strategy;
+}
+```
+
+- Selector 相关：
+  - `unwrappedSelector` 属性，未包装的 NIO Selector 对象。
+  - `selector` 属性，包装的 NIO Selector 对象。Netty 对 NIO Selector 做了优化。详细解析，见 [《精尽 Netty 源码解析 —— EventLoop（五）之 EventLoop 处理 IO 事件》](http://svip.iocoder.cn/Netty/EventLoop-5-EventLoop-handle-io-event?self) 。
+  - `selectedKeys` 属性，注册的 NIO SelectionKey 集合。Netty 自己实现，经过优化。详细解析，见 [《精尽 Netty 源码解析 —— EventLoop（五）之 EventLoop 处理 IO 事件》](http://svip.iocoder.cn/Netty/EventLoop-5-EventLoop-handle-io-event?self) 。
+  - `provider` 属性，NIO SelectorProvider 对象，用于创建 NIO Selector 对象。
+  - 在 `<1>` 处，调用 `#openSelector()` 方法，创建 NIO Selector 对象。
+- `wakenUp` 属性，唤醒标记。因为唤醒方法 `Selector#wakeup()` 开销比较大，通过该标识，减少调用。详细解析，见 [「2.8 wakeup」](https://svip.iocoder.cn/Netty/EventLoop-4-EventLoop-run/#) 。
+- `selectStrategy` 属性，Select 策略。详细解析，见 [「2.10 SelectStrategy」](https://svip.iocoder.cn/Netty/EventLoop-4-EventLoop-run/#) 。
+- `ioRatio` 属性，在 NioEventLoop 中，会三种类型的任务：1) Channel 的就绪的 IO 事件；2) 普通任务；3) 定时任务。而 `ioRatio` 属性，处理 Channel 的就绪的 IO 事件，占处理任务的总时间的比例。
+- 取消 SelectionKey 相关：
+  - `cancelledKeys` 属性， 取消 SelectionKey 的数量。TODO 1007 NioEventLoop cancel
+  - `needsToSelectAgain` 属性，是否需要再次 select Selector 对象。TODO 1007 NioEventLoop cancel
+
+## 2.3 openSelector
+
+`#openSelector()` 方法，创建 NIO Selector 对象。
+
+考虑到让本文更专注在 EventLoop 的逻辑，并且不影响对本文的理解，所以暂时不讲解它的具体实现。详细解析，见 [《精尽 Netty 源码解析 —— EventLoop（五）之 EventLoop 处理 IO 事件》](http://svip.iocoder.cn/Netty/EventLoop-5-EventLoop-handle-io-event?self) 。
+
+## 2.4 rebuildSelector
+
+`#rebuildSelector()` 方法，重建 NIO Selector 对象。
+
+考虑到让本文更专注在 EventLoop 的逻辑，并且不影响对本文的理解，所以暂时不讲解它的具体实现。详细解析，见 [《精尽 Netty 源码解析 —— EventLoop（五）之 EventLoop 处理 IO 事件》](http://svip.iocoder.cn/Netty/EventLoop-5-EventLoop-handle-io-event?self) 。
+
+## 2.5 newTaskQueue
+
+`#newTaskQueue(int maxPendingTasks)` 方法，创建任务队列。代码如下：
+
+> 该方法覆写父类的该方法。
+
+```
+@Override
+protected Queue<Runnable> newTaskQueue(int maxPendingTasks) {
+    // This event loop never calls takeTask()
+    return maxPendingTasks == Integer.MAX_VALUE ? PlatformDependent.<Runnable>newMpscQueue()
+                                                : PlatformDependent.<Runnable>newMpscQueue(maxPendingTasks);
+}
+```
+
+- 调用 `PlatformDependent#newMpscQueue(...)` 方法，创建 mpsc 队列。我们来看看代码注释对 mpsc 队列的描述：
+
+  ```
+  Create a new {@link Queue} which is safe to use for multiple producers (different threads) and a single consumer (one thread!).
+  ```
+
+  - mpsc 是 multiple producers and a single consumer 的缩写。
+  - mpsc 是对**多**线程生产任务，**单**线程消费任务的消费，恰好符合 NioEventLoop 的情况。
+  - 详细解析，见后续文章。当然，着急的胖友，可以先看看 [《原理剖析（第 012 篇）Netty 之无锁队列 MpscUnboundedArrayQueue 原理分析》](https://www.jianshu.com/p/119a03332619) 。
+
+## 2.6 pendingTasks
+
+`#pendingTasks()` 方法，获得待执行的任务数量。代码如下：
+
+> 该方法覆写父类的该方法。
+
+```
+@Override
+public int pendingTasks() {
+    // As we use a MpscQueue we need to ensure pendingTasks() is only executed from within the EventLoop as
+    // otherwise we may see unexpected behavior (as size() is only allowed to be called by a single consumer).
+    // See https://github.com/netty/netty/issues/5297
+    if (inEventLoop()) {
+        return super.pendingTasks();
+    } else {
+        return submit(pendingTasksCallable).syncUninterruptibly().getNow();
+    }
+}
+```
+
+- 因为 MpscQueue 仅允许单消费，所以获得队列的大小，仅允许在 EventLoop 的线程中调用。
+
+## 2.7 setIoRatio
+
+`#setIoRatio(int ioRatio)` 方法，设置 `ioRatio` 属性。代码如下：
+
+```
+/**
+ * Sets the percentage of the desired amount of time spent for I/O in the event loop.  The default value is
+ * {@code 50}, which means the event loop will try to spend the same amount of time for I/O as for non-I/O tasks.
+ */
+public void setIoRatio(int ioRatio) {
+    if (ioRatio <= 0 || ioRatio > 100) {
+        throw new IllegalArgumentException("ioRatio: " + ioRatio + " (expected: 0 < ioRatio <= 100)");
+    }
+    this.ioRatio = ioRatio;
+}
+```
+
+## 2.8 wakeup
+
+`#wakeup(boolean inEventLoop)` 方法，唤醒线程。代码如下：
+
+```
+@Override
+protected void wakeup(boolean inEventLoop) {
+    if (!inEventLoop && wakenUp.compareAndSet(false, true)) { // <2>
+        selector.wakeup(); // <1>
+    }
+}
+```
+
+- `<1>` 处，因为 NioEventLoop 的线程阻塞，主要是调用 `Selector#select(long timeout)` 方法，阻塞等待有 Channel 感兴趣的 IO 事件，或者超时。所以需要调用 `Selector#wakeup()` 方法，进行唤醒 Selector 。
+- `<2>` 处，因为 `Selector#wakeup()` 方法的唤醒操作是开销比较大的操作，并且每次重复调用相当于重复唤醒。所以，通过 `wakenUp` 属性，通过 CAS 修改 `false => true` ，保证有且仅有进行一次唤醒。
+- 当然，详细的解析，可以结合 [「2.9 run」](https://svip.iocoder.cn/Netty/EventLoop-4-EventLoop-run/#) 一起看，这样会更加清晰明了。
+
+## 2.9 run
+
+`#run()` 方法，NioEventLoop 运行，处理任务。**这是本文最重要的方法**。代码如下：
+
+```
+ 1: @Override
+ 2: protected void run() {
+ 3:     for (;;) {
+ 4:         try {
+ 5:             switch (selectStrategy.calculateStrategy(selectNowSupplier, hasTasks())) {
+ 6:                 case SelectStrategy.CONTINUE: // 默认实现下，不存在这个情况。
+ 7:                     continue;
+ 8:                 case SelectStrategy.SELECT:
+ 9:                     // 重置 wakenUp 标记为 false
+10:                     // 选择( 查询 )任务
+11:                     select(wakenUp.getAndSet(false));
+12: 
+13:                     // 'wakenUp.compareAndSet(false, true)' is always evaluated
+14:                     // before calling 'selector.wakeup()' to reduce the wake-up
+15:                     // overhead. (Selector.wakeup() is an expensive operation.)
+16:                     //
+17:                     // However, there is a race condition in this approach.
+18:                     // The race condition is triggered when 'wakenUp' is set to
+19:                     // true too early.
+20:                     //
+21:                     // 'wakenUp' is set to true too early if:
+22:                     // 1) Selector is waken up between 'wakenUp.set(false)' and
+23:                     //    'selector.select(...)'. (BAD)
+24:                     // 2) Selector is waken up between 'selector.select(...)' and
+25:                     //    'if (wakenUp.get()) { ... }'. (OK)
+26:                     //
+27:                     // In the first case, 'wakenUp' is set to true and the
+28:                     // following 'selector.select(...)' will wake up immediately.
+29:                     // Until 'wakenUp' is set to false again in the next round,
+30:                     // 'wakenUp.compareAndSet(false, true)' will fail, and therefore
+31:                     // any attempt to wake up the Selector will fail, too, causing
+32:                     // the following 'selector.select(...)' call to block
+33:                     // unnecessarily.
+34:                     //
+35:                     // To fix this problem, we wake up the selector again if wakenUp
+36:                     // is true immediately after selector.select(...).
+37:                     // It is inefficient in that it wakes up the selector for both
+38:                     // the first case (BAD - wake-up required) and the second case
+39:                     // (OK - no wake-up required).
+40: 
+41:                     // 唤醒。原因，见上面中文注释
+42:                     if (wakenUp.get()) {
+43:                         selector.wakeup();
+44:                     }
+45:                     // fall through
+46:                 default:
+47:             }
+48: 
+49:             // TODO 1007 NioEventLoop cancel 方法
+50:             cancelledKeys = 0;
+51:             needsToSelectAgain = false;
+52: 
+53:             final int ioRatio = this.ioRatio;
+54:             if (ioRatio == 100) {
+55:                 try {
+56:                     // 处理 Channel 感兴趣的就绪 IO 事件
+57:                     processSelectedKeys();
+58:                 } finally {
+59:                     // 运行所有普通任务和定时任务，不限制时间
+60:                     // Ensure we always run tasks.
+61:                     runAllTasks();
+62:                 }
+63:             } else {
+64:                 final long ioStartTime = System.nanoTime();
+65:                 try {
+66:                     // 处理 Channel 感兴趣的就绪 IO 事件
+67:                     processSelectedKeys();
+68:                 } finally {
+69:                     // 运行所有普通任务和定时任务，限制时间
+70:                     // Ensure we always run tasks.
+71:                     final long ioTime = System.nanoTime() - ioStartTime;
+72:                     runAllTasks(ioTime * (100 - ioRatio) / ioRatio);
+73:                 }
+74:             }
+75:         } catch (Throwable t) {
+76:             handleLoopException(t);
+77:         }
+78:         // TODO 1006 EventLoop 优雅关闭
+79:         // Always handle shutdown even if the loop processing threw an exception.
+80:         try {
+81:             if (isShuttingDown()) {
+82:                 closeAll();
+83:                 if (confirmShutdown()) {
+84:                     return;
+85:                 }
+86:             }
+87:         } catch (Throwable t) {
+88:             handleLoopException(t);
+89:         }
+90:     }
+91: }
+```
+
+- 第 3 行：“死”循环，直到 NioEventLoop 关闭，即【第 78 至 89 行】的代码。
+
+- 第 5 行：调用
+
+   
+
+  ```
+  SelectStrategy#calculateStrategy(IntSupplier selectSupplier, boolean hasTasks)
+  ```
+
+   
+
+  方法，获得使用的 select 策略。详细解析，胖友先跳到
+
+   
+
+  「2.10 SelectStrategy」
+
+   
+
+  中研究。😈 看完回来。
+
+  - 我们知道 `SelectStrategy#calculateStrategy(...)` 方法，有 3 种返回的情况。
+
+  - 第 6 至 7 行：第一种，`SelectStrategy.CONTINUE` ，默认实现下，不存在这个情况。
+
+  - 第 8 至 44 行：第二种，
+
+    ```
+    SelectStrategy.SELECT
+    ```
+
+     
+
+    ，进行 Selector
+
+     
+
+    阻塞
+
+     
+
+    select 。
+
+    - 第 11 行：重置 `wakeUp` 标识为 `false` ，并返回修改前的值。
+
+    - 第 11 行：调用 `#select(boolean oldWakeUp)` 方法，选择( 查询 )任务。直接看这个方法不能完全表达出该方法的用途，所以详细解析，见 [「2.12 select」](https://svip.iocoder.cn/Netty/EventLoop-4-EventLoop-run/#) 。
+
+    - 第 41 至 44 行：若唤醒标识
+
+       
+
+      ```
+      wakeup
+      ```
+
+       
+
+      为
+
+       
+
+      ```
+      true
+      ```
+
+       
+
+      时，调用
+
+       
+
+      ```
+      Selector#wakeup()
+      ```
+
+       
+
+      方法，唤醒 Selector 。可能看到此处，很多胖友会和我一样，一脸懵逼。实际上，
+
+      耐下性子
+
+      ，答案在上面的
+
+      英文注释
+
+      中。笔者来简单解析下：
+
+      - 1）在 `wakenUp.getAndSet(false)` 和 `#select(boolean oldWakeUp)` 之间，在标识 `wakeUp` 设置为 `false` 时，在 `#select(boolean oldWakeUp)` 方法中，正在调用 `Selector#select(...)` 方法，处于**阻塞**中。
+      - 2）此时，有另外的线程调用了 `#wakeup()` 方法，会将标记 `wakeUp` 设置为 `true` ，并**唤醒** `Selector#select(...)` 方法的阻塞等待。
+      - 3）标识 `wakeUp` 为 `true` ，所以再有另外的线程调用 `#wakeup()` 方法，都无法唤醒 `Selector#select(...)` 。为什么呢？因为 `#wakeup()` 的 CAS 修改 `false => true` 会**失败**，导致无法调用 `Selector#wakeup()` 方法。
+      - 解决方式：所以在 `#select(boolean oldWakeUp)` 执行完后，增加了【第 41 至 44 行】来解决。
+      - 😈😈😈 整体比较绕，胖友结合实现代码 + 英文注释，再好好理解下。
+
+  - 第 46 行：第三种，`>= 0` ，已经有可以处理的任务，直接向下。
+
+- 第 49 至 51 行：TODO 1007 NioEventLoop cancel 方法
+
+- 第 53 至 74 行：根据
+
+   
+
+  ```
+  ioRatio
+  ```
+
+   
+
+  的配置不同，分成
+
+  略有差异
+
+  的 2 种：
+
+  - 第一种，
+
+    ```
+    ioRatio
+    ```
+
+     
+
+    为 100 ，则
+
+    不考虑
+
+    时间占比的分配。
+
+    - 第 57 行：调用 `#processSelectedKeys()` 方法，处理 Channel 感兴趣的就绪 IO 事件。详细解析，见 [《精尽 Netty 源码解析 —— EventLoop（五）之 EventLoop 处理 IO 事件》](http://svip.iocoder.cn/Netty/EventLoop-5-EventLoop-handle-io-event?self) 。
+    - 第 58 至 62 行：调用 `#runAllTasks()` 方法，运行所有普通任务和定时任务，**不限制时间**。详细解析，见 [《精尽 Netty 源码解析 —— EventLoop（五）之 EventLoop 处理 IO 事件》](http://svip.iocoder.cn/Netty/EventLoop-5-EventLoop-handle-io-event?self) 。
+
+  - 第二种，
+
+    ```
+    ioRatio
+    ```
+
+     
+
+    为
+
+     
+
+    ```
+    < 100
+    ```
+
+     
+
+    ，则
+
+    考虑
+
+    时间占比的分配。
+
+    - 第 64 行：记录当前时间。
+    - 第 67 行：和【第 57 行】的代码**一样**。
+    - 第 71 至 72 行：🙂 比较巧妙的方式，是不是和胖友之前认为的不太一样。它是以 `#processSelectedKeys()` 方法的执行时间作为**基准**，计算 `#runAllTasks(long timeoutNanos)` 方法可执行的时间。
+    - 第 72 行：调用 #runAllTasks(long timeoutNanos)` 方法，运行所有普通任务和定时任务，**限制时间**。
+
+- 第 75 至 77 行：当发生异常时，调用 `#handleLoopException(Throwable t)` 方法，处理异常。代码如下：
+
+  ```
+  private static void handleLoopException(Throwable t) {
+      logger.warn("Unexpected exception in the selector loop.", t);
+  
+      // Prevent possible consecutive immediate failures that lead to
+      // excessive CPU consumption.
+      try {
+          Thread.sleep(1000);
+      } catch (InterruptedException e) {
+          // Ignore.
+      }
+  }
+  ```
+
+- 第 78 至 89 行：TODO 1006 EventLoop 优雅关闭
+
+- 总的来说，`#run()` 的执行过程，就是如下一张图：[![run](16-Netty 源码解析-EventLoop（四）之 EventLoop 运行.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_05_10/01.png)run
+
+## 2.10 SelectStrategy
+
+`io.netty.channel.SelectStrategy` ，选择( select )策略接口。代码如下：
+
+```
+public interface SelectStrategy {
+
+    /**
+     * Indicates a blocking select should follow.
+     *
+     * 表示使用阻塞 select 的策略。
+     */
+    int SELECT = -1;
+    /**
+     * Indicates the IO loop should be retried, no blocking select to follow directly.
+     *
+     * 表示需要进行重试的策略。
+     */
+    int CONTINUE = -2;
+
+    /**
+     * The {@link SelectStrategy} can be used to steer the outcome of a potential select
+     * call.
+     *
+     * @param selectSupplier The supplier with the result of a select result.
+     * @param hasTasks true if tasks are waiting to be processed.
+     * @return {@link #SELECT} if the next step should be blocking select {@link #CONTINUE} if
+     *         the next step should be to not select but rather jump back to the IO loop and try
+     *         again. Any value >= 0 is treated as an indicator that work needs to be done.
+     */
+    int calculateStrategy(IntSupplier selectSupplier, boolean hasTasks) throws Exception;
+    
+}
+```
+
+- ```
+  calculateStrategy(IntSupplier selectSupplier, boolean hasTasks)
+  ```
+
+   
+
+  接口方法有
+
+   
+
+  3
+
+   
+
+  种返回的情况：
+
+  - `SELECT`，`-1` ，表示使用阻塞 **select** 的策略。
+  - `CONTINUE`，`-2`，表示需要进行重试的策略。实际上，默认情况下，不会返回 `CONTINUE` 的策略。
+  - `>= 0` ，表示不需要 select ，目前已经有可以执行的任务了。
+
+### 2.10.1 DefaultSelectStrategy
+
+`io.netty.channel.DefaultSelectStrategy` ，实现 SelectStrategy 接口，默认选择策略实现类。代码如下：
+
+```
+final class DefaultSelectStrategy implements SelectStrategy {
+
+    /**
+     * 单例
+     */
+    static final SelectStrategy INSTANCE = new DefaultSelectStrategy();
+
+    private DefaultSelectStrategy() { }
+
+    @Override
+    public int calculateStrategy(IntSupplier selectSupplier, boolean hasTasks) throws Exception {
+        return hasTasks ? selectSupplier.get() : SelectStrategy.SELECT;
+    }
+
+}
+```
+
+- 当 `hasTasks` 为 `true` ，表示当前已经有任务，所以调用 `IntSupplier#get()` 方法，返回当前 Channel 新增的 IO 就绪事件的数量。代码如下：
+
+  ```
+  private final IntSupplier selectNowSupplier = new IntSupplier() {
+      @Override
+      public int get() throws Exception {
+          return selectNow();
+      }
+  };
+  ```
+
+  - `io.netty.util.IntSupplier` ，代码如下：
+
+    ```
+    public interface IntSupplier {
+    
+        /**
+         * Gets a result.
+         *
+         * @return a result
+         */
+        int get() throws Exception;
+    
+    }
+    ```
+
+    - 类似 Java 自带的 `Callable<Int>` 。
+
+  - IntSupplier 在 NioEventLoop 中的实现为 `selectNowSupplier` 属性。在它的内部会调用 `#selectNow()` 方法。详细解析，见 [「2.11 selectNow」](https://svip.iocoder.cn/Netty/EventLoop-4-EventLoop-run/#) 。
+
+  - 实际上，这里不调用 `IntSupplier#get()` 方法，也是可以的。只不过考虑到，可以通过 `#selectNow()` 方法，**无阻塞**的 select Channel 是否有感兴趣的就绪事件。
+
+- 当 `hasTasks` 为 `false` 时，直接返回 `SelectStrategy.SELECT` ，进行**阻塞** select Channel 感兴趣的就绪 IO 事件。
+
+## 2.11 selectNow
+
+`#selectNow()` 方法，代码如下：
+
+```
+int selectNow() throws IOException {
+    try {
+        return selector.selectNow(); // <1>
+    } finally {
+        // restore wakeup state if needed <2>
+        if (wakenUp.get()) {
+            selector.wakeup();
+        }
+    }
+}
+```
+
+- `<1>` 处，调用 `Selector#selectorNow()` 方法，立即( **无阻塞** )返回 Channel 新增的感兴趣的就绪 IO 事件数量。
+
+- `<2>` 处，若唤醒标识 `wakeup` 为 `true` 时，调用 `Selector#wakeup()` 方法，唤醒 Selector 。因为 `<1>` 处的 `Selector#selectorNow()` 会使用我们对 Selector 的唤醒，所以需要进行**复原**。有一个冷知道，可能有胖友不知道：
+
+  > 注意，如果有其它线程调用了 `#wakeup()` 方法，但当前没有线程阻塞在 `#select()` 方法上，下个调用 `#select()` 方法的线程会立即被唤醒。😈 有点神奇。
+
+## 2.12 select
+
+`#select(boolean oldWakenUp)` 方法，选择( 查询 )任务。**这是本文最重要的方法**。代码如下：
+
+```
+  1: private void select(boolean oldWakenUp) throws IOException {
+  2:     // 记录下 Selector 对象
+  3:     Selector selector = this.selector;
+  4:     try {
+  5:         // select 计数器
+  6:         int selectCnt = 0; // cnt 为 count 的缩写
+  7:         // 记录当前时间，单位：纳秒
+  8:         long currentTimeNanos = System.nanoTime();
+  9:         // 计算 select 截止时间，单位：纳秒。
+ 10:         long selectDeadLineNanos = currentTimeNanos + delayNanos(currentTimeNanos);
+ 11: 
+ 12:         for (;;) {
+ 13:             // 计算本次 select 的超时时长，单位：毫秒。
+ 14:             // + 500000L 是为了四舍五入
+ 15:             // / 1000000L 是为了纳秒转为毫秒
+ 16:             long timeoutMillis = (selectDeadLineNanos - currentTimeNanos + 500000L) / 1000000L;
+ 17:             // 如果超时时长，则结束 select
+ 18:             if (timeoutMillis <= 0) {
+ 19:                 if (selectCnt == 0) { // 如果是首次 select ，selectNow 一次，非阻塞
+ 20:                     selector.selectNow();
+ 21:                     selectCnt = 1;
+ 22:                 }
+ 23:                 break;
+ 24:             }
+ 25: 
+ 26:             // If a task was submitted when wakenUp value was true, the task didn't get a chance to call
+ 27:             // Selector#wakeup. So we need to check task queue again before executing select operation.
+ 28:             // If we don't, the task might be pended until select operation was timed out.
+ 29:             // It might be pended until idle timeout if IdleStateHandler existed in pipeline.
+ 30:             // 若有新的任务加入
+ 31:             if (hasTasks() && wakenUp.compareAndSet(false, true)) {
+ 32:                 // selectNow 一次，非阻塞
+ 33:                 selector.selectNow();
+ 34:                 // 重置 select 计数器
+ 35:                 selectCnt = 1;
+ 36:                 break;
+ 37:             }
+ 38: 
+ 39:             // 阻塞 select ，查询 Channel 是否有就绪的 IO 事件
+ 40:             int selectedKeys = selector.select(timeoutMillis);
+ 41:             // select 计数器 ++
+ 42:             selectCnt ++;
+ 43: 
+ 44:             // 结束 select ，如果满足下面任一一个条件
+ 45:             if (selectedKeys != 0 || oldWakenUp || wakenUp.get() || hasTasks() || hasScheduledTasks()) {
+ 46:                 // - Selected something,
+ 47:                 // - waken up by user, or
+ 48:                 // - the task queue has a pending task.
+ 49:                 // - a scheduled task is ready for processing
+ 50:                 break;
+ 51:             }
+ 52:             // 线程被打断。一般情况下不会出现，出现基本是 bug ，或者错误使用。
+ 53:             if (Thread.interrupted()) {
+ 54:                 // Thread was interrupted so reset selected keys and break so we not run into a busy loop.
+ 55:                 // As this is most likely a bug in the handler of the user or it's client library we will
+ 56:                 // also log it.
+ 57:                 //
+ 58:                 // See https://github.com/netty/netty/issues/2426
+ 59:                 if (logger.isDebugEnabled()) {
+ 60:                     logger.debug("Selector.select() returned prematurely because " +
+ 61:                             "Thread.currentThread().interrupt() was called. Use " +
+ 62:                             "NioEventLoop.shutdownGracefully() to shutdown the NioEventLoop.");
+ 63:                 }
+ 64:                 selectCnt = 1;
+ 65:                 break;
+ 66:             }
+ 67: 
+ 68:             // 记录当前时间
+ 69:             long time = System.nanoTime();
+ 70:             // 符合 select 超时条件，重置 selectCnt 为 1
+ 71:             if (time - TimeUnit.MILLISECONDS.toNanos(timeoutMillis) >= currentTimeNanos) {
+ 72:                 // timeoutMillis elapsed without anything selected.
+ 73:                 selectCnt = 1;
+ 74:             // 不符合 select 超时的提交，若 select 次数到达重建 Selector 对象的上限，进行重建
+ 75:             } else if (SELECTOR_AUTO_REBUILD_THRESHOLD > 0 &&
+ 76:                     selectCnt >= SELECTOR_AUTO_REBUILD_THRESHOLD) {
+ 77:                 // The selector returned prematurely many times in a row.
+ 78:                 // Rebuild the selector to work around the problem.
+ 79:                 logger.warn("Selector.select() returned prematurely {} times in a row; rebuilding Selector {}.", selectCnt, selector);
+ 80: 
+ 81:                 // 重建 Selector 对象
+ 82:                 rebuildSelector();
+ 83:                 // 修改下 Selector 对象
+ 84:                 selector = this.selector;
+ 85: 
+ 86:                 // Select again to populate selectedKeys.
+ 87:                 // 立即 selectNow 一次，非阻塞
+ 88:                 selector.selectNow();
+ 89:                 // 重置 selectCnt 为 1
+ 90:                 selectCnt = 1;
+ 91:                 // 结束 select
+ 92:                 break;
+ 93:             }
+ 94: 
+ 95:             currentTimeNanos = time;
+ 96:         }
+ 97: 
+ 98:         if (selectCnt > MIN_PREMATURE_SELECTOR_RETURNS) {
+ 99:             if (logger.isDebugEnabled()) {
+100:                 logger.debug("Selector.select() returned prematurely {} times in a row for Selector {}.", selectCnt - 1, selector);
+101:             }
+102:         }
+103:     } catch (CancelledKeyException e) {
+104:         if (logger.isDebugEnabled()) {
+105:             logger.debug(CancelledKeyException.class.getSimpleName() + " raised by a Selector {} - JDK bug?", selector, e);
+106:         }
+107:         // Harmless exception - log anyway
+108:     }
+109: }
+```
+
+- 第 3 行：获得使用的 Selector 对象，不需要每次访问使用 `volatile` 修饰的 `selector` 属性。
+
+- 第 6 行：获得 select 操作的计数器。主要用于记录 Selector 空轮询次数，所以每次在正在轮询完成( 例如：轮询超时 )，则重置 `selectCnt` 为 1 。
+
+- 第 8 行：记录当前时间，单位：纳秒。
+
+- 第 10 行：计算 select 操作的截止时间，单位：纳秒。
+
+  - `#delayNanos(currentTimeNanos)` 方法返回的为下一个定时任务距离现在的时间，如果不存在定时任务，则默认返回 1000 ms 。该方法的详细解析，见后续文章。
+
+- 第 12 行：“死”循环，直到符合如下
+
+  任一
+
+  一种情况后
+
+  结束
+
+  ：
+
+  1. select 操作超时，对应【第 18 至 24 行】。
+  2. 若有新的任务加入，对应【第 26 至 37 行】。
+  3. 查询到任务或者唤醒，对应【第 45 至 51 行】。
+  4. 线程被异常打断，对应【第 52 至 66 行】。
+  5. 发生 NIO 空轮询的 Bug 后重建 Selector 对象后，对应【第 75 至 93 行】。
+
+- 第 16 行：计算本次 select 的**超时时长**，单位：毫秒。因为【第 40 行】的 `Selector#select(timeoutMillis)` 方法，可能因为**各种情况结束**，所以需要循环，并且每次**重新**计算超时时间。至于 `+ 500000L` 和 `/ 1000000L` 的用途，看下代码注释。
+
+- 第 17 至 24 行：如果超过 select 超时时长，则结束 select 。
+
+  - 第 19 至 21 行：如果是首次 select ，则调用 `Selector#selectNow()` 方法，获得**非阻塞**的 Channel 感兴趣的就绪的 IO 事件，并重置 `selectCnt` 为 1 。
+
+- 第 26 至 37 行：若有新的任务加入。这里实际要分成两种情况：
+
+  - 第一种，提交的任务的类型是 NonWakeupRunnable ，那么它并不会调用 `#wakeup()` 方法，原因胖友自己看 `#execute(Runnable task)` 思考下。Netty 在 `#select()` 方法的设计上，**能尽快执行任务**。此时如果标记 `wakeup` 为 `false` ，说明符合这种情况，直接结束 select 。
+
+  - 第二种，提交的任务的类型
+
+    不是
+
+     
+
+    NonWakeupRunnable ，那么在
+
+     
+
+    ```
+    #run()
+    ```
+
+     
+
+    方法的【第 8 至 11 行】的
+
+     
+
+    ```
+    wakenUp.getAndSet(false)
+    ```
+
+     
+
+    之前，发起了一次
+
+     
+
+    ```
+    #wakeup()
+    ```
+
+     
+
+    方法，那么因为
+
+     
+
+    ```
+    wakenUp.getAndSet(false)
+    ```
+
+     
+
+    会将标记
+
+     
+
+    ```
+    wakeUp
+    ```
+
+     
+
+    设置为
+
+     
+
+    ```
+    false
+    ```
+
+     
+
+    ，所以就能满足
+
+     
+
+    ```
+    hasTasks() && wakenUp.compareAndSet(false, true)
+    ```
+
+     
+
+    的条件。
+
+    - 这个解释，就和【第 27 至 28 行】的英文注释 `So we need to check task queue again before executing select operation.If we don't, the task might be pended until select operation was timed out.` 有出入了？这是为什么呢？因为 Selector 被提前 wakeup 了，所以下一次 Selector 的 select 是被直接唤醒结束的。
+
+  - 第 33 行：虽然已经发现任务，但是还是调用 `Selector#selectNow()` 方法，**非阻塞**的获取一次 Channel 新增的就绪的 IO 事件。
+
+  - 对应 Github 的代码提交为 https://github.com/lightningMan/netty/commit/f44f3e7926f1676315ae86d0f18bdd9b95681d9f 。
+
+- 第 40 行：调用 `Selector#select(timeoutMillis)` 方法，**阻塞** select ，获得 Channel 新增的就绪的 IO 事件的数量。
+
+- 第 42 行：select 计数器加 1 。
+
+- 第 44 至 51 行：如果满足下面
+
+  任一
+
+  一个条件，结束 select ：
+
+  1. `selectedKeys != 0` 时，表示有 Channel 新增的就绪的 IO 事件，所以结束 select ，很好理解。
+  2. `oldWakenUp || wakenUp.get()` 时，表示 Selector 被唤醒，所以结束 select 。
+  3. `hasTasks() || hasScheduledTasks()` ，表示有普通任务或定时任务，所以结束 select 。
+  4. 那么剩余的情况，主要是 select **超时**或者发生**空轮询**，即【第 68 至 93 行】的代码。
+
+- 第 52 至 66 行：线程被打断。一般情况下不会出现，出现基本是 **bug** ，或者错误使用。感兴趣的胖友，可以看看 https://github.com/netty/netty/issues/2426 。
+
+- 第 69 行：记录当前时间。
+
+  - 第 70 至 73 行：若满足 `time - TimeUnit.MILLISECONDS.toNanos(timeoutMillis) >= currentTimeNanos` ，说明到达此处时，Selector 是**超时** select ，那么是**正常**的，所以重置 `selectCnt` 为 1 。
+
+  - 第 74 至 93 行：不符合 select 超时的提交，若 select 次数到达重建 Selector 对象的上限，进行重建。
+
+    这就是 Netty 判断发生 NIO Selector 空轮询的方式
+
+    ，N ( 默认 512 )次 select 并未阻塞超时这么长，那么就认为发生 NIO Selector 空轮询。过多的 NIO Selector 将会导致 CPU 100% 。
+
+    - 第 82 行：调用 `#rebuildSelector()` 方法，重建 Selector 对象。
+    - 第 84 行：**重新**获得使用的 Selector 对象。
+    - 第 86 至 90 行：同【第 20 至 21 行】的代码。
+    - 第 92 行：结束 select 。
+
+- 第 95 行：记录新的当前时间，用于【第 16 行】，**重新**计算本次 select 的超时时长。
+
+# 666. 彩蛋
+
+总的来说还是比较简单的，比较困难的，在于对标记 `wakeup` 的理解。真的是，细思极恐！！！感谢在理解过程中，闪电侠和大表弟普架的帮助。
+
+推荐阅读文章：
+
+- 闪电侠 [《netty 源码分析之揭开 reactor 线程的面纱（一）》](https://www.jianshu.com/p/0d0eece6d467)
+- Hypercube [《自顶向下深入分析 Netty（四）–EventLoop-2》](https://www.jianshu.com/p/d0f06b13e2fb)
+
+> 老艿艿：全文的 NIO Selector 空轮询，指的是 epoll cpu 100% 的 bug 。
\ No newline at end of file
diff --git a/netty/17-Netty 源码解析-EventLoop（五）之 EventLoop 处理 IO 事件.assets/01.png b/netty/17-Netty 源码解析-EventLoop（五）之 EventLoop 处理 IO 事件.assets/01.png
new file mode 100644
index 0000000..a760792
Binary files /dev/null and b/netty/17-Netty 源码解析-EventLoop（五）之 EventLoop 处理 IO 事件.assets/01.png differ
diff --git a/netty/17-Netty 源码解析-EventLoop（五）之 EventLoop 处理 IO 事件.md b/netty/17-Netty 源码解析-EventLoop（五）之 EventLoop 处理 IO 事件.md
new file mode 100644
index 0000000..ac0a353
--- /dev/null
+++ b/netty/17-Netty 源码解析-EventLoop（五）之 EventLoop 处理 IO 事件.md	
@@ -0,0 +1,912 @@
+# 精尽 Netty 源码解析 —— EventLoop（五）之 EventLoop 处理 IO 事件
+
+# 1. 概述
+
+本文我们分享 EventLoop 的**处理 IO 事件**相关代码的实现。对应如下图的绿条 **process selected keys** 部分：[![run](17-Netty 源码解析-EventLoop（五）之 EventLoop 处理 IO 事件.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_05_10/01.png)run
+
+因为在 [《精尽 Netty 源码解析 —— EventLoop（四）之 EventLoop 运行》](http://svip.iocoder.cn/Netty/EventLoop-5-EventLoop-handle-io-event?self) 中，`#openSelector()` 和 `#rebuildSelector()` 方法并未做分享，所以我们先来一起看看。
+
+# 2. SelectorTuple
+
+SelectorTuple ，Selector 元组。代码如下：
+
+> SelectorTuple 内嵌在 NioEventLoop
+
+```
+private static final class SelectorTuple {
+
+    /**
+     * 未包装的 Selector 对象
+     */
+    final Selector unwrappedSelector;
+    /**
+     * 未包装的 Selector 对象
+     */
+    final Selector selector;
+
+    SelectorTuple(Selector unwrappedSelector) {
+        this.unwrappedSelector = unwrappedSelector;
+        this.selector = unwrappedSelector;
+    }
+
+    SelectorTuple(Selector unwrappedSelector, Selector selector) {
+        this.unwrappedSelector = unwrappedSelector;
+        this.selector = selector;
+    }
+
+}
+```
+
+# 3. openSelector
+
+`#openSelector()` 方法，创建 Selector 对象。代码如下：
+
+```
+ 1: private SelectorTuple openSelector() {
+ 2:     // 创建 Selector 对象，作为 unwrappedSelector
+ 3:     final Selector unwrappedSelector;
+ 4:     try {
+ 5:         unwrappedSelector = provider.openSelector();
+ 6:     } catch (IOException e) {
+ 7:         throw new ChannelException("failed to open a new selector", e);
+ 8:     }
+ 9: 
+10:     // 禁用 SelectionKey 的优化，则直接返回 SelectorTuple 对象。即，selector 也使用 unwrappedSelector 。
+11:     if (DISABLE_KEYSET_OPTIMIZATION) {
+12:         return new SelectorTuple(unwrappedSelector);
+13:     }
+14: 
+15:     // 获得 SelectorImpl 类
+16:     Object maybeSelectorImplClass = AccessController.doPrivileged(new PrivilegedAction<Object>() {
+17:         @Override
+18:         public Object run() {
+19:             try {
+20:                 return Class.forName(
+21:                         "sun.nio.ch.SelectorImpl",
+22:                         false,
+23:                         PlatformDependent.getSystemClassLoader()); // 成功，则返回该类
+24:             } catch (Throwable cause) {
+25:                 return cause; // 失败，则返回该异常
+26:             }
+27:         }
+28:     });
+29: 
+30:     // 获得 SelectorImpl 类失败，则直接返回 SelectorTuple 对象。即，selector 也使用 unwrappedSelector 。
+31:     if (!(maybeSelectorImplClass instanceof Class) ||
+32:             // ensure the current selector implementation is what we can instrument.
+33:             !((Class<?>) maybeSelectorImplClass).isAssignableFrom(unwrappedSelector.getClass())) {
+34:         if (maybeSelectorImplClass instanceof Throwable) {
+35:             Throwable t = (Throwable) maybeSelectorImplClass;
+36:             logger.trace("failed to instrument a special java.util.Set into: {}", unwrappedSelector, t);
+37:         }
+38:         return new SelectorTuple(unwrappedSelector);
+39:     }
+40: 
+41:     final Class<?> selectorImplClass = (Class<?>) maybeSelectorImplClass;
+42: 
+43:     // 创建 SelectedSelectionKeySet 对象
+44:     final SelectedSelectionKeySet selectedKeySet = new SelectedSelectionKeySet();
+45: 
+46:     // 设置 SelectedSelectionKeySet 对象到 unwrappedSelector 中
+47:     Object maybeException = AccessController.doPrivileged(new PrivilegedAction<Object>() {
+48:         @Override
+49:         public Object run() {
+50:             try {
+51:                 // 获得 "selectedKeys" "publicSelectedKeys" 的 Field
+52:                 Field selectedKeysField = selectorImplClass.getDeclaredField("selectedKeys");
+53:                 Field publicSelectedKeysField = selectorImplClass.getDeclaredField("publicSelectedKeys");
+54: 
+55:                 // 设置 Field 可访问
+56:                 Throwable cause = ReflectionUtil.trySetAccessible(selectedKeysField, true);
+57:                 if (cause != null) {
+58:                     return cause;
+59:                 }
+60:                 cause = ReflectionUtil.trySetAccessible(publicSelectedKeysField, true);
+61:                 if (cause != null) {
+62:                     return cause;
+63:                 }
+64: 
+65:                 // 设置 SelectedSelectionKeySet 对象到 unwrappedSelector 的 Field 中
+66:                 selectedKeysField.set(unwrappedSelector, selectedKeySet);
+67:                 publicSelectedKeysField.set(unwrappedSelector, selectedKeySet);
+68:                 return null;
+69:             } catch (NoSuchFieldException e) {
+70:                 return e; // 失败，则返回该异常
+71:             } catch (IllegalAccessException e) {
+72:                 return e; // 失败，则返回该异常
+73:             }
+74:         }
+75:     });
+76: 
+77:     // 设置 SelectedSelectionKeySet 对象到 unwrappedSelector 中失败，则直接返回 SelectorTuple 对象。即，selector 也使用 unwrappedSelector 。
+78:     if (maybeException instanceof Exception) {
+79:         selectedKeys = null;
+80:         Exception e = (Exception) maybeException;
+81:         logger.trace("failed to instrument a special java.util.Set into: {}", unwrappedSelector, e);
+82:         return new SelectorTuple(unwrappedSelector);
+83:     }
+84: 
+85:     // 设置 SelectedSelectionKeySet 对象到 selectedKeys 中
+86:     selectedKeys = selectedKeySet;
+87:     logger.trace("instrumented a special java.util.Set into: {}", unwrappedSelector);
+88: 
+89:     // 创建 SelectedSelectionKeySetSelector 对象
+90:     // 创建 SelectorTuple 对象。即，selector 也使用 SelectedSelectionKeySetSelector 对象。
+91:     return new SelectorTuple(unwrappedSelector, new SelectedSelectionKeySetSelector(unwrappedSelector, selectedKeySet));
+92: }
+```
+
+- 第 2 至 8 行：创建 Selector 对象，作为 `unwrappedSelector` 。
+
+- 第 10 至 13 行：禁用 SelectionKey 的优化，则直接返回 SelectorTuple 对象。即，`selector` 也使用 `unwrappedSelector` 。
+
+- 第 15 至 28 行：获得 SelectorImpl 类。胖友可以自动过滤掉
+
+   
+
+  ```
+  AccessController#.doPrivileged(...)
+  ```
+
+   
+
+  外层代码。在方法内部，调用
+
+   
+
+  ```
+  Class#forName(String name, boolean initialize, ClassLoader loader)
+  ```
+
+   
+
+  方法，加载
+
+   
+
+  ```
+  sun.nio.ch.SelectorImpl
+  ```
+
+   
+
+  类。加载成功，则返回该类，否则返回异常。
+
+  - 第 30 至 39 行： 获得 SelectorImpl 类失败，则直接返回 SelectorTuple 对象。即，`selector` 也使用 `unwrappedSelector` 。
+
+- 第 44 行：创建 SelectedSelectionKeySet 对象。这是 Netty 对 Selector 的 `selectionKeys` 的优化。关于 SelectedSelectionKeySet 的详细实现，见 [「4. SelectedSelectionKeySet」](https://svip.iocoder.cn/Netty/EventLoop-5-EventLoop-handle-io-event/#) 。
+
+  - 第 46 至 75 行： 设置 SelectedSelectionKeySet 对象到 `unwrappedSelector` 中的 `selectedKeys` 和 `publicSelectedKeys` 属性。整个过程，笔者已经添加中文注释，胖友自己看下。
+
+  - `selectedKeys` 和 `publicSelectedKeys` 属性在 SelectorImpl 类中，代码如下：
+
+    ```
+    protected HashSet<SelectionKey> keys = new HashSet(); // => publicKeys
+    private Set<SelectionKey> publicKeys;
+    
+    protected Set<SelectionKey> selectedKeys = new HashSet(); // => publicSelectedKeys
+    private Set<SelectionKey> publicSelectedKeys;
+    
+    protected SelectorImpl(SelectorProvider var1) {
+        super(var1);
+        if (Util.atBugLevel("1.4")) { // 可以无视
+            this.publicKeys = this.keys;
+            this.publicSelectedKeys = this.selectedKeys;
+        } else {
+            this.publicKeys = Collections.unmodifiableSet(this.keys);
+            this.publicSelectedKeys = Util.ungrowableSet(this.selectedKeys);
+        }
+    
+    }
+    ```
+
+    - 可以看到，`selectedKeys` 和 `publicSelectedKeys` 的类型都是 HashSet 。
+
+  - 第 77 至 83 行：设置 SelectedSelectionKeySet 对象到 `unwrappedSelector` 中失败，则直接返回 SelectorTuple 对象。即，`selector` 也使用 `unwrappedSelector` 。
+
+- 第 86 行：设置 SelectedSelectionKeySet 对象到 `selectedKeys` 中。在下文，我们会看到，是否成功优化 Selector 对象，是通过 `selectedKeys` 是否成功初始化来判断。
+
+- 第 91 行：创建 SelectedSelectionKeySetSelector 对象。这是 Netty 对 Selector 的优化实现类。关于 SelectedSelectionKeySetSelector 的详细实现，见 [「5. SelectedSelectionKeySetSelector」](https://svip.iocoder.cn/Netty/EventLoop-5-EventLoop-handle-io-event/#) 。
+
+- 第 91 行：创建 SelectorTuple 对象。即，`selector` 使用 SelectedSelectionKeySetSelector 对象。😈 总算，创建成功优化的 `selector` 对象了。
+
+# 4. SelectedSelectionKeySet
+
+`io.netty.channel.nio.SelectedSelectionKeySet` ，继承 AbstractSet 抽象类，已 **select** 的 NIO SelectionKey 集合。代码如下：
+
+```
+final class SelectedSelectionKeySet extends AbstractSet<SelectionKey> {
+
+    /**
+     * SelectionKey 数组
+     */
+    SelectionKey[] keys;
+    /**
+     * 数组可读大小
+     */
+    int size;
+
+    SelectedSelectionKeySet() {
+        keys = new SelectionKey[1024]; // 默认 1024 大小
+    }
+
+    @Override
+    public boolean add(SelectionKey o) {
+        if (o == null) {
+            return false;
+        }
+
+        // 添加到数组
+        keys[size++] = o;
+
+        // 超过数组大小上限，进行扩容
+        if (size == keys.length) {
+            increaseCapacity();
+        }
+
+        return true;
+    }
+
+    @Override
+    public int size() {
+        return size;
+    }
+
+    @Override
+    public boolean remove(Object o) {
+        return false;
+    }
+
+    @Override
+    public boolean contains(Object o) {
+        return false;
+    }
+
+    @Override
+    public Iterator<SelectionKey> iterator() {
+        throw new UnsupportedOperationException();
+    }
+
+    void reset() {
+        reset(0);
+    }
+
+    void reset(int start) {
+        // 重置数组内容为空
+        Arrays.fill(keys, start, size, null);
+        // 重置可读大小为 0
+        size = 0;
+    }
+
+    private void increaseCapacity() {
+        // 两倍扩容
+        SelectionKey[] newKeys = new SelectionKey[keys.length << 1];
+        // 复制老数组到新数组
+        System.arraycopy(keys, 0, newKeys, 0, size);
+        // 赋值给老数组
+        keys = newKeys;
+    }
+
+}
+```
+
+- 通过 `keys` 和 `size` 两个属性，实现**可重用**的数组。
+- `#add(SelectionKey o)` 方法，添加新 **select** 到就绪事件的 SelectionKey 到 `keys` 中。当超过数组大小上限时，调用 `#increaseCapacity()` 方法，进行**两倍**扩容。相比 SelectorImpl 中使用的 `selectedKeys` 所使用的 HashSet 的 `#add(E e)` 方法，事件复杂度从 `O(lgn)` **降低**到 `O(1)` 。
+- `#reset(...)` 方法，每次读取使用完数据，调用该方法，进行重置。
+- 因为 `#remove(Object o)`、`#contains(Object o)`、`#iterator()` 不会使用到，索性不进行实现。
+
+# 5. SelectedSelectionKeySetSelector
+
+`io.netty.channel.nio.SelectedSelectionKeySetSelector` ，基于 Netty SelectedSelectionKeySet 作为 `selectionKeys` 的 Selector 实现类。代码如下：
+
+```
+final class SelectedSelectionKeySetSelector extends Selector {
+
+    /**
+     * SelectedSelectionKeySet 对象
+     */
+    private final SelectedSelectionKeySet selectionKeys;
+    /**
+     * 原始 Java NIO Selector 对象
+     */
+    private final Selector delegate;
+
+    SelectedSelectionKeySetSelector(Selector delegate, SelectedSelectionKeySet selectionKeys) {
+        this.delegate = delegate;
+        this.selectionKeys = selectionKeys;
+    }
+
+    @Override
+    public boolean isOpen() {
+        return delegate.isOpen();
+    }
+
+    @Override
+    public SelectorProvider provider() {
+        return delegate.provider();
+    }
+
+    @Override
+    public Set<SelectionKey> keys() {
+        return delegate.keys();
+    }
+
+    @Override
+    public Set<SelectionKey> selectedKeys() {
+        return delegate.selectedKeys();
+    }
+
+    @Override
+    public int selectNow() throws IOException {
+        // 重置 selectionKeys
+        selectionKeys.reset();
+        // selectNow
+        return delegate.selectNow();
+    }
+
+    @Override
+    public int select(long timeout) throws IOException {
+        // 重置 selectionKeys
+        selectionKeys.reset();
+        // select
+        return delegate.select(timeout);
+    }
+
+    @Override
+    public int select() throws IOException {
+        // 重置 selectionKeys
+        selectionKeys.reset();
+        // select
+        return delegate.select();
+    }
+
+    @Override
+    public Selector wakeup() {
+        return delegate.wakeup();
+    }
+
+    @Override
+    public void close() throws IOException {
+        delegate.close();
+    }
+
+}
+```
+
+- 除了 **select** 相关的 3 个方法，每个实现方法，都是基于 Java NIO Selector 对应的方法的调用。
+- **select** 相关的 3 个方法，在调用对应的 Java NIO Selector 方法之前，会调用 `SelectedSelectionKeySet#reset()` 方法，重置 `selectionKeys` 。从而实现，每次 select 之后，都是**新的**已 select 的 NIO SelectionKey 集合。
+
+# 6. rebuildSelector
+
+`#rebuildSelector()` 方法，重建 Selector 对象。代码如下：
+
+> 该方法用于 NIO Selector 发生 epoll bug 时，重建 Selector 对象。
+>
+> 😈 突然又找到一个讨论，可以看看 [《JDK 1.7 及以下 NIO 的 epoll bug》](https://github.com/Yhzhtk/note/issues/26) 和 [《应用服务器中对JDK的epoll空转bug的处理》](http://www.10tiao.com/html/308/201602/401718035/1.html) 。
+
+```
+public void rebuildSelector() {
+    // 只允许在 EventLoop 的线程中执行
+    if (!inEventLoop()) {
+        execute(new Runnable() {
+            @Override
+            public void run() {
+                rebuildSelector0();
+            }
+        });
+        return;
+    }
+    rebuildSelector0();
+}
+```
+
+- 只允许在 EventLoop 的线程中，调用 `#rebuildSelector0()` 方法，重建 Selector 对象。
+
+## 6.1 rebuildSelector0
+
+`#rebuildSelector0()` 方法，重建 Selector 对象。代码如下：
+
+```
+ 1: private void rebuildSelector0() {
+ 2:     final Selector oldSelector = selector;
+ 3:     if (oldSelector == null) {
+ 4:         return;
+ 5:     }
+ 6: 
+ 7:     // 创建新的 Selector 对象
+ 8:     final SelectorTuple newSelectorTuple;
+ 9:     try {
+10:         newSelectorTuple = openSelector();
+11:     } catch (Exception e) {
+12:         logger.warn("Failed to create a new Selector.", e);
+13:         return;
+14:     }
+15: 
+16:     // Register all channels to the new Selector.
+17:     // 将注册在 NioEventLoop 上的所有 Channel ，注册到新创建 Selector 对象上
+18:     int nChannels = 0; // 计算重新注册成功的 Channel 数量
+19:     for (SelectionKey key: oldSelector.keys()) {
+20:         Object a = key.attachment();
+21:         try {
+22:             if (!key.isValid() || key.channel().keyFor(newSelectorTuple.unwrappedSelector) != null) {
+23:                 continue;
+24:             }
+25: 
+26:             int interestOps = key.interestOps();
+27:             // 取消老的 SelectionKey
+28:             key.cancel();
+29:             // 将 Channel 注册到新的 Selector 对象上
+30:             SelectionKey newKey = key.channel().register(newSelectorTuple.unwrappedSelector, interestOps, a);
+31:             // 修改 Channel 的 selectionKey 指向新的 SelectionKey 上
+32:             if (a instanceof AbstractNioChannel) {
+33:                 // Update SelectionKey
+34:                 ((AbstractNioChannel) a).selectionKey = newKey;
+35:             }
+36: 
+37:             // 计数 ++
+38:             nChannels ++;
+39:         } catch (Exception e) {
+40:             logger.warn("Failed to re-register a Channel to the new Selector.", e);
+41:             // 关闭发生异常的 Channel
+42:             if (a instanceof AbstractNioChannel) {
+43:                 AbstractNioChannel ch = (AbstractNioChannel) a;
+44:                 ch.unsafe().close(ch.unsafe().voidPromise());
+45:             // 调用 NioTask 的取消注册事件
+46:             } else {
+47:                 @SuppressWarnings("unchecked")
+48:                 NioTask<SelectableChannel> task = (NioTask<SelectableChannel>) a;
+49:                 invokeChannelUnregistered(task, key, e);
+50:             }
+51:         }
+52:     }
+53: 
+54:     // 修改 selector 和 unwrappedSelector 指向新的 Selector 对象
+55:     selector = newSelectorTuple.selector;
+56:     unwrappedSelector = newSelectorTuple.unwrappedSelector;
+57: 
+58:     // 关闭老的 Selector 对象
+59:     try {
+60:         // time to close the old selector as everything else is registered to the new one
+61:         oldSelector.close();
+62:     } catch (Throwable t) {
+63:         if (logger.isWarnEnabled()) {
+64:             logger.warn("Failed to close the old Selector.", t);
+65:         }
+66:     }
+67: 
+68:     if (logger.isInfoEnabled()) {
+69:         logger.info("Migrated " + nChannels + " channel(s) to the new Selector.");
+70:     }
+71: }
+```
+
+- 第 7 行：调用 `#openSelector()` 方法，创建新的 Selector 对象。
+
+- 第 16 至 52 行：遍历
+
+  老
+
+  的 Selector 对象的
+
+   
+
+  ```
+  selectionKeys
+  ```
+
+   
+
+  ，将注册在 NioEventLoop 上的所有 Channel ，注册到
+
+  新
+
+  创建 Selector 对象上。
+
+  - 第 22 至 24 行：校验 SelectionKey 有效，并且 Java NIO Channel 并未注册在**新**的 Selector 对象上。
+
+  - 第 28 行：调用 `SelectionKey#cancel()` 方法，取消**老**的 SelectionKey 。
+
+  - 第 30 行：将 Java NIO Channel 注册到**新**的 Selector 对象上，返回**新**的 SelectionKey 对象。
+
+  - 第 31 至 35 行：修改 Channel 的 `selectionKey` 指向**新**的 SelectionKey 对象
+
+  - 第 39 至 51 行：当发生异常时候，根据不同的 SelectionKey 的
+
+     
+
+    ```
+    attachment
+    ```
+
+     
+
+    来判断处理方式：
+
+    - 第 41 至 44 行：当 `attachment` 是 Netty NIO Channel 时，调用 `Unsafe#close(ChannelPromise promise)` 方法，**关闭**发生异常的 Channel 。
+    - 第 45 至 50 行：当 `attachment` 是 Netty NioTask 时，调用 `#invokeChannelUnregistered(NioTask<SelectableChannel> task, SelectionKey k, Throwable cause)` 方法，通知 Channel 取消注册。详细解析，见 [「8. NioTask」](https://svip.iocoder.cn/Netty/EventLoop-5-EventLoop-handle-io-event/#) 。
+
+- 第 54 至 56 行：修改 `selector` 和 `unwrappedSelector` 指向**新**的 Selector 对象。
+
+- 第 58 至 66 行：调用 `Selector#close()` 方法，关闭**老**的 Selector 对象。
+
+总的来说，`#rebuildSelector()` 方法，相比 `#openSelector()` 方法，主要是需要将老的 Selector 对象的“数据”复制到新的 Selector 对象上，并关闭老的 Selector 对象。
+
+# 7. processSelectedKeys
+
+在 `#run()` 方法中，会调用 `#processSelectedKeys()` 方法，处理 Channel **新增**就绪的 IO 事件。代码如下：
+
+```
+private void processSelectedKeys() {
+    if (selectedKeys != null) {
+        processSelectedKeysOptimized();
+    } else {
+        processSelectedKeysPlain(selector.selectedKeys());
+    }
+}
+```
+
+- 当 `selectedKeys` 非空，意味着使用优化的 SelectedSelectionKeySetSelector ，所以调用 `#processSelectedKeysOptimized()` 方法；否则，调用 `#processSelectedKeysPlain()` 方法。
+
+## 7.1 processSelectedKeysOptimized
+
+`#processSelectedKeysOptimized()` 方法，基于 Netty SelectedSelectionKeySetSelector ，处理 Channel **新增**就绪的 IO 事件。代码如下：
+
+> 老艿艿：从方法名，我们也可以看出，这是个经过**优化**的实现。
+
+```
+ 1: private void processSelectedKeysOptimized() {
+ 2:     // 遍历数组
+ 3:     for (int i = 0; i < selectedKeys.size; ++i) {
+ 4:         final SelectionKey k = selectedKeys.keys[i];
+ 5:         // null out entry in the array to allow to have it GC'ed once the Channel close
+ 6:         // See https://github.com/netty/netty/issues/2363
+ 7:         selectedKeys.keys[i] = null;
+ 8: 
+ 9:         final Object a = k.attachment();
+10: 
+11:         // 处理一个 Channel 就绪的 IO 事件
+12:         if (a instanceof AbstractNioChannel) {
+13:             processSelectedKey(k, (AbstractNioChannel) a);
+14:         // 使用 NioTask 处理一个 Channel 就绪的 IO 事件
+15:         } else {
+16:             @SuppressWarnings("unchecked")
+17:             NioTask<SelectableChannel> task = (NioTask<SelectableChannel>) a;
+18:             processSelectedKey(k, task);
+19:         }
+20: 
+21:         // TODO 1007 NioEventLoop cancel 方法
+22:         if (needsToSelectAgain) {
+23:             // null out entries in the array to allow to have it GC'ed once the Channel close
+24:             // See https://github.com/netty/netty/issues/2363
+25:             selectedKeys.reset(i + 1);
+26: 
+27:             selectAgain();
+28:             i = -1;
+29:         }
+30:     }
+31: }
+```
+
+- 第 3 行：循环
+
+   
+
+  ```
+  selectedKeys
+  ```
+
+   
+
+  数组。
+
+  - 第 4 至 7 行：置空，原因见 https://github.com/netty/netty/issues/2363 。
+  - 第 11 至 13 行：当 `attachment` 是 Netty NIO Channel 时，调用 `#processSelectedKey(SelectionKey k, AbstractNioChannel ch)` 方法，处理一个 Channel 就绪的 IO 事件。详细解析，见 [「7.3 processSelectedKey」](https://svip.iocoder.cn/Netty/EventLoop-5-EventLoop-handle-io-event/#) 。
+  - 第 14 至 19 行：当 `attachment` 是 Netty NioTask 时，调用 `#processSelectedKey(SelectionKey k, NioTask<SelectableChannel> task)` 方法，使用 NioTask 处理一个 Channel 的 IO 事件。详细解析，见 [「8. NioTask」](https://svip.iocoder.cn/Netty/EventLoop-5-EventLoop-handle-io-event/#) 。
+  - 第 21 至 29 行：TODO 1007 NioEventLoop cancel 方法
+
+## 7.2 processSelectedKeysPlain
+
+`#processSelectedKeysOptimized()` 方法，基于 Java NIO 原生 Selecotr ，处理 Channel **新增**就绪的 IO 事件。代码如下：
+
+> 老艿艿：总体和 `#processSelectedKeysOptimized()` 方法**类似**。
+
+```
+ 1: private void processSelectedKeysPlain(Set<SelectionKey> selectedKeys) {
+ 2:     // check if the set is empty and if so just return to not create garbage by
+ 3:     // creating a new Iterator every time even if there is nothing to process.
+ 4:     // See https://github.com/netty/netty/issues/597
+ 5:     if (selectedKeys.isEmpty()) {
+ 6:         return;
+ 7:     }
+ 8: 
+ 9:     // 遍历 SelectionKey 迭代器
+10:     Iterator<SelectionKey> i = selectedKeys.iterator();
+11:     for (;;) {
+12:         // 获得 SelectionKey 对象
+13:         final SelectionKey k = i.next();
+14:         // 从迭代器中移除
+15:         i.remove();
+16: 
+17:         final Object a = k.attachment();
+18:         // 处理一个 Channel 就绪的 IO 事件
+19:         if (a instanceof AbstractNioChannel) {
+20:             processSelectedKey(k, (AbstractNioChannel) a);
+21:         // 使用 NioTask 处理一个 Channel 就绪的 IO 事件
+22:         } else {
+23:             @SuppressWarnings("unchecked")
+24:             NioTask<SelectableChannel> task = (NioTask<SelectableChannel>) a;
+25:             processSelectedKey(k, task);
+26:         }
+27: 
+28:         // 无下一个节点，结束
+29:         if (!i.hasNext()) {
+30:             break;
+31:         }
+32: 
+33:         // TODO 1007 NioEventLoop cancel 方法
+34:         if (needsToSelectAgain) {
+35:             selectAgain();
+36:             selectedKeys = selector.selectedKeys();
+37: 
+38:             // Create the iterator again to avoid ConcurrentModificationException
+39:             if (selectedKeys.isEmpty()) {
+40:                 break;
+41:             } else {
+42:                 i = selectedKeys.iterator();
+43:             }
+44:         }
+45:     }
+46: }
+```
+
+- 第 10 至 11 行：遍历 SelectionKey
+
+   
+
+  迭代器
+
+  。
+
+  - 第 12 至 15 行：获得下一个 SelectionKey 对象，并从迭代器中移除。
+  - 第 18 至 20 行：当 `attachment` 是 Netty NIO Channel 时，调用 `#processSelectedKey(SelectionKey k, AbstractNioChannel ch)` 方法，处理一个 Channel 就绪的 IO 事件。详细解析，见 [「7.3 processSelectedKey」](https://svip.iocoder.cn/Netty/EventLoop-5-EventLoop-handle-io-event/#) 。
+  - 第 21 至 26 行：当 `attachment` 是 Netty NioTask 时，调用 `#processSelectedKey(SelectionKey k, NioTask<SelectableChannel> task)` 方法，使用 NioTask 处理一个 Channel 的 IO 事件。详细解析，见 [「8. NioTask」](https://svip.iocoder.cn/Netty/EventLoop-5-EventLoop-handle-io-event/#) 。
+  - 第 33 至 44 行：TODO 1007 NioEventLoop cancel 方法
+
+## 7.3 processSelectedKey
+
+`#processSelectedKey(SelectionKey k, AbstractNioChannel ch)` 方法，处理一个 Channel 就绪的 IO 事件。代码如下：
+
+```
+ 1: private void processSelectedKey(SelectionKey k, AbstractNioChannel ch) {
+ 2:     // 如果 SelectionKey 是不合法的，则关闭 Channel
+ 3:     final AbstractNioChannel.NioUnsafe unsafe = ch.unsafe();
+ 4:     if (!k.isValid()) {
+ 5:         final EventLoop eventLoop;
+ 6:         try {
+ 7:             eventLoop = ch.eventLoop();
+ 8:         } catch (Throwable ignored) {
+ 9:             // If the channel implementation throws an exception because there is no event loop, we ignore this
+10:             // because we are only trying to determine if ch is registered to this event loop and thus has authority
+11:             // to close ch.
+12:             return;
+13:         }
+14:         // Only close ch if ch is still registered to this EventLoop. ch could have deregistered from the event loop
+15:         // and thus the SelectionKey could be cancelled as part of the deregistration process, but the channel is
+16:         // still healthy and should not be closed.
+17:         // See https://github.com/netty/netty/issues/5125
+18:         if (eventLoop != this) {
+19:             return;
+20:         }
+21:         // close the channel if the key is not valid anymore
+22:         unsafe.close(unsafe.voidPromise());
+23:         return;
+24:     }
+25: 
+26:     try {
+27:         // 获得就绪的 IO 事件的 ops
+28:         int readyOps = k.readyOps();
+29: 
+30:         // OP_CONNECT 事件就绪
+31:         // We first need to call finishConnect() before try to trigger a read(...) or write(...) as otherwise
+32:         // the NIO JDK channel implementation may throw a NotYetConnectedException.
+33:         if ((readyOps & SelectionKey.OP_CONNECT) != 0) {
+34:             // 移除对 OP_CONNECT 感兴趣
+35:             // remove OP_CONNECT as otherwise Selector.select(..) will always return without blocking
+36:             // See https://github.com/netty/netty/issues/924
+37:             int ops = k.interestOps();
+38:             ops &= ~SelectionKey.OP_CONNECT;
+39:             k.interestOps(ops);
+40:             // 完成连接
+41:             unsafe.finishConnect();
+42:         }
+43: 
+44:         // OP_WRITE 事件就绪
+45:         // Process OP_WRITE first as we may be able to write some queued buffers and so free memory.
+46:         if ((readyOps & SelectionKey.OP_WRITE) != 0) {
+47:             // Call forceFlush which will also take care of clear the OP_WRITE once there is nothing left to write
+48:             // 向 Channel 写入数据
+49:             ch.unsafe().forceFlush();
+50:         }
+51: 
+52:         // SelectionKey.OP_READ 或 SelectionKey.OP_ACCEPT 就绪
+53:         // readyOps == 0 是对 JDK Bug 的处理，防止空的死循环
+54:         // Also check for readOps of 0 to workaround possible JDK bug which may otherwise lead
+55:         // to a spin loop
+56:         if ((readyOps & (SelectionKey.OP_READ | SelectionKey.OP_ACCEPT)) != 0 || readyOps == 0) {
+57:             unsafe.read();
+58:         }
+59:     } catch (CancelledKeyException ignored) {
+60:         // 发生异常，关闭 Channel
+61:         unsafe.close(unsafe.voidPromise());
+62:     }
+63: }
+```
+
+- 第 2 至 24 行：如果 SelectionKey 是不合法的，则关闭 Channel 。
+
+- 第 30 至 42 行：如果对
+
+   
+
+  ```
+  OP_CONNECT
+  ```
+
+   
+
+  事件就绪：
+
+  - 第 34 至 39 行：移除对 `OP_CONNECT` 的感兴趣，即不再监听连接事件。
+  - 【重要】第 41 行：调用 `Unsafe#finishConnect()` 方法，完成连接。后续的逻辑，对应 [《精尽 Netty 源码分析 —— 启动（二）之客户端》](http://svip.iocoder.cn/Netty/bootstrap-2-client/) 的 [「3.6.4 finishConnect」](https://svip.iocoder.cn/Netty/EventLoop-5-EventLoop-handle-io-event/#) 小节。
+
+- 第 44 至 50 行：如果对 `OP_WRITE` 事件就绪，调用 `Unsafe#forceFlush()` 方法，向 Channel 写入数据。在完成写入数据后，会移除对 `OP_WRITE` 的感兴趣。想要提前了解的胖友，可以自己看下 `AbstractNioByteChannel#clearOpWrite()` 和 `AbstractNioMessageChannel#doWrite(ChannelOutboundBuffer in)` 方法。
+
+- 第 52 至 58 行：如果对 `OP_READ` 或 `OP_ACCEPT` 事件就绪：调用 `Unsafe#read()` 方法，处理读**或者**者接受客户端连接的事件。
+
+# 8. NioTask
+
+`io.netty.channel.nio.NioTask` ，用于自定义 Nio 事件处理**接口**。对于每个 Nio 事件，可以认为是一个任务( Task )，代码如下：
+
+```
+public interface NioTask<C extends SelectableChannel> {
+
+    /**
+     * Invoked when the {@link SelectableChannel} has been selected by the {@link Selector}.
+     */
+    void channelReady(C ch, SelectionKey key) throws Exception;
+
+    /**
+     * Invoked when the {@link SelectionKey} of the specified {@link SelectableChannel} has been cancelled and thus
+     * this {@link NioTask} will not be notified anymore.
+     *
+     * @param cause the cause of the unregistration. {@code null} if a user called {@link SelectionKey#cancel()} or
+     *              the event loop has been shut down.
+     */
+    void channelUnregistered(C ch, Throwable cause) throws Exception;
+
+}
+```
+
+- `#channelReady(C ch, SelectionKey key)` 方法，处理 Channel IO 就绪的事件。相当于说，我们可以通过实现该接口方法，实现 [「7.3 processSelectedKey」](https://svip.iocoder.cn/Netty/EventLoop-5-EventLoop-handle-io-event/#) 的逻辑。
+- `#channelUnregistered(C ch, Throwable cause)` 方法，Channel 取消注册。一般来说，我们可以通过实现该接口方法，关闭 Channel 。
+
+😈 实际上，NioTask 在 Netty 自身中并未有相关的实现类，并且和闪电侠沟通了下，他在项目中，也并未使用。所以对 NioTask 不感兴趣的胖友，可以跳过本小节。另外，NioTask 是在 [Allow a user to access the Selector of an EventLoop](https://github.com/netty/netty/issues/681) 中有相关的讨论。
+
+## 8.1 register
+
+`#register(final SelectableChannel ch, final int interestOps, final NioTask<?> task)` 方法，注册 Java NIO Channel ( 不一定需要通过 Netty 创建的 Channel )到 Selector 上，相当于说，也注册到了 EventLoop 上。代码如下：
+
+```
+/**
+ * Registers an arbitrary {@link SelectableChannel}, not necessarily created by Netty, to the {@link Selector}
+ * of this event loop.  Once the specified {@link SelectableChannel} is registered, the specified {@code task} will
+ * be executed by this event loop when the {@link SelectableChannel} is ready.
+ */
+public void register(final SelectableChannel ch, final int interestOps, final NioTask<?> task) {
+    if (ch == null) {
+        throw new NullPointerException("ch");
+    }
+    if (interestOps == 0) {
+        throw new IllegalArgumentException("interestOps must be non-zero.");
+    }
+    if ((interestOps & ~ch.validOps()) != 0) {
+        throw new IllegalArgumentException(
+                "invalid interestOps: " + interestOps + "(validOps: " + ch.validOps() + ')');
+    }
+    if (task == null) {
+        throw new NullPointerException("task");
+    }
+
+    if (isShutdown()) {
+        throw new IllegalStateException("event loop shut down");
+    }
+
+    // <1>
+    try {
+        ch.register(selector, interestOps, task);
+    } catch (Exception e) {
+        throw new EventLoopException("failed to register a channel", e);
+    }
+}
+```
+
+- `<1>` 处，调用 `SelectableChannel#register(Selector sel, int ops, Object att)` 方法，注册 Java NIO Channel 到 Selector 上。这里我们可以看到，`attachment` 为 NioTask 对象，而不是 Netty Channel 对象。
+
+## 8.2 invokeChannelUnregistered
+
+`#invokeChannelUnregistered(NioTask<SelectableChannel> task, SelectionKey k, Throwable cause)` 方法，执行 Channel 取消注册。代码如下：
+
+```
+private static void invokeChannelUnregistered(NioTask<SelectableChannel> task, SelectionKey k, Throwable cause) {
+    try {
+        task.channelUnregistered(k.channel(), cause);
+    } catch (Exception e) {
+        logger.warn("Unexpected exception while running NioTask.channelUnregistered()", e);
+    }
+}
+```
+
+- 在方法内部，调用 `NioTask#channelUnregistered()` 方法，执行 Channel 取消注册。
+
+## 8.3 processSelectedKey
+
+`#processSelectedKey(SelectionKey k, NioTask<SelectableChannel> task)` 方法，使用 NioTask ，自定义实现 Channel 处理 Channel IO 就绪的事件。代码如下：
+
+```
+private static void processSelectedKey(SelectionKey k, NioTask<SelectableChannel> task) {
+    int state = 0; // 未执行
+    try {
+        // 调用 NioTask 的 Channel 就绪事件
+        task.channelReady(k.channel(), k);
+        state = 1; // 执行成功
+    } catch (Exception e) {
+        // SelectionKey 取消
+        k.cancel();
+        // 执行 Channel 取消注册
+        invokeChannelUnregistered(task, k, e);
+        state = 2; // 执行异常
+    } finally {
+        switch (state) {
+        case 0:
+            // SelectionKey 取消
+            k.cancel();
+            // 执行 Channel 取消注册
+            invokeChannelUnregistered(task, k, null);
+            break;
+        case 1:
+            // SelectionKey 不合法，则执行 Channel 取消注册
+            if (!k.isValid()) { // Cancelled by channelReady()
+                invokeChannelUnregistered(task, k, null);
+            }
+            break;
+        }
+    }
+}
+```
+
+- 代码比较简单，胖友自己看中文注释。主要是看懂
+
+   
+
+  ```
+  state
+  ```
+
+   
+
+  有 3 种情况：
+
+  - `0` ：未执行。
+  - `1` ：执行成功。
+  - `2` ：执行异常。
+
+# 666. 彩蛋
+
+简单小文一篇，没什么太大难度的一篇。
+
+如果有不理解的地方，也可以看看下面的文章：
+
+- 闪电侠 [《netty 源码分析之揭开 reactor 线程的面纱（二）》](https://www.jianshu.com/p/467a9b41833e)
+- Hypercube [《自顶向下深入分析 Netty（四）–EventLoop-2》](https://www.jianshu.com/p/d0f06b13e2fb)
+- 杨武兵 [《netty 源码分析系列 —— EventLoop》](https://my.oschina.net/ywbrj042/blog/889748)
+- 占小狼 [《Netty 源码分析之 NioEventLoop》](https://www.jianshu.com/p/9acf36f7e025)
\ No newline at end of file
diff --git a/netty/18-Netty 源码解析-EventLoop（六）之 EventLoop 处理普通任务.assets/01.png b/netty/18-Netty 源码解析-EventLoop（六）之 EventLoop 处理普通任务.assets/01.png
new file mode 100644
index 0000000..a760792
Binary files /dev/null and b/netty/18-Netty 源码解析-EventLoop（六）之 EventLoop 处理普通任务.assets/01.png differ
diff --git a/netty/18-Netty 源码解析-EventLoop（六）之 EventLoop 处理普通任务.md b/netty/18-Netty 源码解析-EventLoop（六）之 EventLoop 处理普通任务.md
new file mode 100644
index 0000000..378d127
--- /dev/null
+++ b/netty/18-Netty 源码解析-EventLoop（六）之 EventLoop 处理普通任务.md	
@@ -0,0 +1,368 @@
+# 精尽 Netty 源码解析 —— EventLoop（六）之 EventLoop 处理普通任务
+
+# 1. 概述
+
+本文我们分享 EventLoop 的**执行任务**相关代码的实现。对应如下图的紫条 **run tasks** 部分：[![run](18-Netty 源码解析-EventLoop（六）之 EventLoop 处理普通任务.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_05_10/01.png)run
+
+EventLoop 执行的任务分成**普通**任务和**定时**任务，考虑到内容切分的更细粒度，本文近仅仅分享【**普通任务**】的部分。
+
+# 2. runAllTasks 带超时
+
+在 `#run()` 方法中，会调用 `#runAllTasks(long timeoutNanos)` 方法，执行所有任务直到完成所有，或者超过执行时间上限。代码如下：
+
+```
+ 1: protected boolean runAllTasks(long timeoutNanos) {
+ 2:     // 从定时任务获得到时间的任务
+ 3:     fetchFromScheduledTaskQueue();
+ 4:     // 获得队头的任务
+ 5:     Runnable task = pollTask();
+ 6:     // 获取不到，结束执行
+ 7:     if (task == null) {
+ 8:         // 执行所有任务完成的后续方法
+ 9:         afterRunningAllTasks();
+10:         return false;
+11:     }
+12: 
+13:     // 计算执行任务截止时间
+14:     final long deadline = ScheduledFutureTask.nanoTime() + timeoutNanos;
+15:     long runTasks = 0; // 执行任务计数
+16:     long lastExecutionTime;
+17:     // 循环执行任务
+18:     for (;;) {
+19:         // 执行任务
+20:         safeExecute(task);
+21: 
+22:         // 计数 +1
+23:         runTasks ++;
+24: 
+25:         // 每隔 64 个任务检查一次时间，因为 nanoTime() 是相对费时的操作
+26:         // 64 这个值当前是硬编码的，无法配置，可能会成为一个问题。
+27:         // Check timeout every 64 tasks because nanoTime() is relatively expensive.
+28:         // XXX: Hard-coded value - will make it configurable if it is really a problem.
+29:         if ((runTasks & 0x3F) == 0) {
+30:             // 重新获得时间
+31:             lastExecutionTime = ScheduledFutureTask.nanoTime();
+32:             // 超过任务截止时间，结束
+33:             if (lastExecutionTime >= deadline) {
+34:                 break;
+35:             }
+36:         }
+37: 
+38:         // 获得队头的任务
+39:         task = pollTask();
+40:         // 获取不到，结束执行
+41:         if (task == null) {
+42:             // 重新获得时间
+43:             lastExecutionTime = ScheduledFutureTask.nanoTime();
+44:             break;
+45:         }
+46:     }
+47: 
+48:     // 执行所有任务完成的后续方法
+49:     afterRunningAllTasks();
+50: 
+51:     // 设置最后执行时间
+52:     this.lastExecutionTime = lastExecutionTime;
+53:     return true;
+54: }
+```
+
+- 方法的返回值，表示是否执行过任务。因为，任务队列可能为空，那么就会返回 `false` ，表示没有执行过任务。
+
+- 第 3 行：调用 `#fetchFromScheduledTaskQueue()` 方法，将定时任务队列 `scheduledTaskQueue` 到达可执行的任务，添加到任务队列 `taskQueue` 中。通过这样的方式，定时任务得以被执行。详细解析，见 [《精尽 Netty 源码解析 —— EventLoop（七）之 EventLoop 处理定时任务》](http://svip.iocoder.cn/Netty/EventLoop-7-EventLoop-handle-schedule-task) 。
+
+- 第 5 行：
+
+  首次
+
+  调用
+
+   
+
+  ```
+  #pollTask()
+  ```
+
+   
+
+  方法，获得队头的任务。详细解析，胖友先跳到
+
+   
+
+  「4. pollTask」
+
+   
+
+  。
+
+  - 第 6 至 11 行：获取不到任务，结束执行，并返回
+
+     
+
+    ```
+    false
+    ```
+
+     
+
+    。
+
+    - 第 9 行：调用 `#afterRunningAllTasks()` 方法，执行所有任务完成的**后续**方法。详细解析，见 [「5. afterRunningAllTasks」](https://svip.iocoder.cn/Netty/EventLoop-6-EventLoop-handle-normal-task/#) 。
+
+- 第 14 行：计算执行任务截止时间。其中，`ScheduledFutureTask#nanoTime()` 方法，我们可以暂时理解成，获取当前的时间，单位为**纳秒**。详细解析，见 [《精尽 Netty 源码解析 —— EventLoop（七）之 EventLoop 处理定时任务》](http://svip.iocoder.cn/Netty/EventLoop-7-EventLoop-handle-schedule-task) 。
+
+- 第 17 至 46 行：
+
+  循环
+
+  执行任务。
+
+  - 第 20 行：【重要】调用 `#safeExecute(Runnable task)` 方法，执行任务。
+
+  - 第 23 行：计算 `runTasks` **加一**。
+
+  - 第 29 至 36 行：每隔
+
+     
+
+    64
+
+     
+
+    个任务检查一次时间，因为
+
+     
+
+    ```
+    System#nanoTime()
+    ```
+
+     
+
+    是
+
+    相对费时
+
+    的操作。也因此，超过执行时间上限是“
+
+    近似的
+
+    ”，而不是绝对准确。
+
+    - 第 31 行：调用 `ScheduledFutureTask#nanoTime()` 方法，获取当前的时间。
+    - 第 32 至 35 行：超过执行时间上限，结束执行。
+
+  - 第 39 行：
+
+    再次
+
+    调用
+
+     
+
+    ```
+    #pollTask()
+    ```
+
+     
+
+    方法，获得队头的任务。
+
+    - 第 41 至 45 行：获取不到，结束执行。
+    - 第 43 行：调用 `ScheduledFutureTask#nanoTime()` 方法，获取当前的时间，作为**最终**的 `.lastExecutionTime` ，即【第 52 行】的代码。
+
+- 第 49 行：调用 `#afterRunningAllTasks()` 方法，执行所有任务完成的**后续**方法。
+
+- 第 53 行：返回 `true` ，表示有执行任务。
+
+# 3. runAllTasks
+
+在 `#run()` 方法中，会调用 `#runAllTasks()` 方法，执行所有任务直到完成所有。代码如下：
+
+```
+ 1: protected boolean runAllTasks() {
+ 2:     assert inEventLoop();
+ 3:     boolean fetchedAll;
+ 4:     boolean ranAtLeastOne = false; // 是否执行过任务
+ 5: 
+ 6:     do {
+ 7:         // 从定时任务获得到时间的任务
+ 8:         fetchedAll = fetchFromScheduledTaskQueue();
+ 9:         // 执行任务队列中的所有任务
+10:         if (runAllTasksFrom(taskQueue)) {
+11:             // 若有任务执行，则标记为 true
+12:             ranAtLeastOne = true;
+13:         }
+14:     } while (!fetchedAll); // keep on processing until we fetched all scheduled tasks.
+15: 
+16:     // 如果执行过任务，则设置最后执行时间
+17:     if (ranAtLeastOne) {
+18:         lastExecutionTime = ScheduledFutureTask.nanoTime();
+19:     }
+20: 
+21:     // 执行所有任务完成的后续方法
+22:     afterRunningAllTasks();
+23:     return ranAtLeastOne;
+24: }
+```
+
+- 第 4 行：`ranAtLeastOne` ，标记是否执行过任务。
+
+- 第 6 至 14 行：调用 `#fetchFromScheduledTaskQueue()` 方法，将定时任务队列 `scheduledTaskQueue` 到达可执行的任务，添加到任务队列 `taskQueue` 中。但是实际上，任务队列 `taskQueue` 是有队列大小上限的，因此使用 `while` 循环，直到没有到达可执行的任务为止。
+
+  - 第 10 行：调用 `#runAllTasksFrom(taskQueue)` 方法，执行任务队列中的所有任务。代码如下：
+
+    ```
+    protected final boolean runAllTasksFrom(Queue<Runnable> taskQueue) {
+        // 获得队头的任务
+        Runnable task = pollTaskFrom(taskQueue);
+        // 获取不到，结束执行，返回 false
+        if (task == null) {
+            return false;
+        }
+        for (;;) {
+            // 执行任务
+            safeExecute(task);
+            // 获得队头的任务
+            task = pollTaskFrom(taskQueue);
+            // 获取不到，结束执行，返回 true
+            if (task == null) {
+                return true;
+            }
+        }
+    }
+    ```
+
+    - 代码比较简单，和 `#runAllTasks(long timeoutNanos))` 方法的代码，大体是相似的。
+
+  - 第 12 行：若有任务被执行，则标记 `ranAtLeastOne` 为 `true` 。
+
+- 第 16 至 19 行：如果执行过任务，则设置最后执行时间。
+
+- 第 22 行：调用 `#afterRunningAllTasks()` 方法，执行所有任务完成的**后续**方法。
+
+- 第 23 行：返回是否执行过任务。和 `#runAllTasks(long timeoutNanos))` 方法的返回是**一致**的。
+
+# 4. pollTask
+
+`#pollTask()` 方法，获得**队头**的任务。代码如下：
+
+```
+protected Runnable pollTask() {
+    assert inEventLoop();
+    return pollTaskFrom(taskQueue);
+}
+
+protected static Runnable pollTaskFrom(Queue<Runnable> taskQueue) {
+    for (;;) { // <2>
+        // 获得并移除队首元素。如果获得不到，返回 null
+        Runnable task = taskQueue.poll(); // <1>
+        // 忽略 WAKEUP_TASK 任务，因为是空任务
+        if (task == WAKEUP_TASK) {
+            continue;
+        }
+        return task;
+    }
+}
+```
+
+- `<1>` 处，调用 `Queue#poll()` 方法，获得并移除队首元素。如果获得不到，返回 null 。**注意**，这个操作是**非阻塞**的。如果胖友不知道，请 Google 重新学习下。
+- `<2>` 处，因为获得的任务可能是 `WAKEUP_TASK` ，所以需要通过循环来跳过。
+
+# 5. afterRunningAllTasks
+
+在 [《精尽 Netty 源码解析 —— EventLoop（三）之 EventLoop 初始化》](http://svip.iocoder.cn/Netty/EventLoop-3-EventLoop-init/) 的 [「9.10 afterRunningAllTasks」](https://svip.iocoder.cn/Netty/EventLoop-6-EventLoop-handle-normal-task/#) 中，`#afterRunningAllTasks()` 方法，执行所有任务完成的**后续**方法。代码如下：
+
+```
+// SingleThreadEventLoop.java
+
+protected void afterRunningAllTasks() {
+    runAllTasksFrom(tailTasks);
+}
+```
+
+- 在方法内部，会调用 `#runAllTasksFrom(tailTasks)` 方法，执行任务队列 `tailTasks` 的任务。
+
+那么，可能很多胖友会和我有一样的疑问，**到底什么样的任务**，适合添加到 `tailTasks` 中呢？笔者请教了自己的好基友，闪电侠，来解答了这个问题。他实现了**批量提交写入**功能的 Handler ，代码如下：
+
+```
+public class BatchFlushHandler extends ChannelOutboundHandlerAdapter {
+
+    private CompositeByteBuf compositeByteBuf;
+    /**
+    * 是否使用 CompositeByteBuf 对象，用于数据写入
+    **/
+    private boolean preferComposite;
+
+    private SingleThreadEventLoop eventLoop;
+
+    private Channel.Unsafe unsafe;
+
+    /**
+    * 是否添加任务到 tailTaskQueue 队列中
+    */
+    private boolean hasAddTailTask = false;
+
+    public BatchFlushHandler() {
+        this(true);
+    }
+
+    public BatchFlushHandler(boolean preferComposite) {
+        this.preferComposite = preferComposite;
+    }
+
+    @Override
+    public void handlerAdded(ChannelHandlerContext ctx) {
+        // 初始化 CompositeByteBuf 对象，如果开启 preferComposite 功能
+        if (preferComposite) {
+            compositeByteBuf = ctx.alloc().compositeBuffer();
+        }
+        eventLoop = (SingleThreadEventLoop) ctx.executor();
+        unsafe = ctx.channel().unsafe();
+    }
+
+    @Override
+    public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) {
+        // 写入到 CompositeByteBuf 对象中
+        if (preferComposite) {
+            compositeByteBuf.addComponent(true, (ByteBuf) msg);
+        // 普通写入
+        } else {
+            ctx.write(msg);
+        }
+    }
+
+    @Override
+    public void flush(ChannelHandlerContext ctx) {
+        // 通过 hasAddTailTask 有且仅有每个 EventLoop 执行循环( run )，只添加一次任务
+        if (!hasAddTailTask) {
+            hasAddTailTask = true;
+
+            // 【重点】添加最终批量提交( flush )的任务
+            // 【重点】添加最终批量提交( flush )的任务
+            // 【重点】添加最终批量提交( flush )的任务
+            eventLoop.executeAfterEventLoopIteration(() -> {
+                if (preferComposite) {
+                    ctx.writeAndFlush(compositeByteBuf).addListener(future -> compositeByteBuf = ctx.alloc()
+                            .compositeBuffer());
+                } else {
+                    unsafe.flush();
+                }
+                
+                // 重置 hasAddTailTask ，从而实现下个 EventLoop 执行循环( run )，可以再添加一次任务
+                hasAddTailTask = false;
+            });
+        }
+    }
+}
+```
+
+- 代码可能略微有一丢丢难懂，不过笔者已经添加中文注释，胖友可以自己理解下。
+
+- 为什么这样做会有好处呢？在 [《蚂蚁通信框架实践》](https://mp.weixin.qq.com/s/JRsbK1Un2av9GKmJ8DK7IQ) 的 [「5. 批量解包与批量提交」 ](https://svip.iocoder.cn/Netty/EventLoop-6-EventLoop-handle-normal-task/#)有相关分享。
+
+  > 如此能减少 `pipeline` 的执行次数，同时提升吞吐量。这个模式在低并发场景，并没有什么优势，而在高并发场景下对提升吞吐量有不小的性能提升。
+
+# 666. 彩蛋
+
+美滋滋，比较简单。又是一个失眠的夜晚。
\ No newline at end of file
diff --git a/netty/19-Netty 源码解析-EventLoop（七）之 EventLoop 处理定时任务.md b/netty/19-Netty 源码解析-EventLoop（七）之 EventLoop 处理定时任务.md
new file mode 100644
index 0000000..45ebf31
--- /dev/null
+++ b/netty/19-Netty 源码解析-EventLoop（七）之 EventLoop 处理定时任务.md	
@@ -0,0 +1,637 @@
+# 精尽 Netty 源码解析 —— EventLoop（七）之 EventLoop 处理定时任务
+
+# 1. 概述
+
+本文接 [《精尽 Netty 源码解析 —— EventLoop（六）之 EventLoop 处理普通任务》](http://svip.iocoder.cn/Netty/EventLoop-6-EventLoop-handle-normal-task) ，分享【处理**定时任务**】的部分。
+
+因为 AbstractScheduledEventExecutor 在 [《精尽 Netty 源码解析 —— EventLoop（三）之 EventLoop 初始化》](https://svip.iocoder.cn/Netty/EventLoop-7-EventLoop-handle-schedule-task/精尽 Netty 源码解析 —— EventLoop（三）之 EventLoop 初始化) 并未分享，并且它是本文的**处理定时任务的前置**，所以本文先写这部分内容。
+
+# 2. ScheduledFutureTask
+
+`io.netty.util.concurrent.ScheduledFutureTask` ，实现 ScheduledFuture、PriorityQueueNode 接口，继承 PromiseTask 抽象类，Netty 定时任务。
+
+> 老艿艿：也有文章喜欢把“定时任务”叫作“调度任务”，意思是相同的，本文统一使用“定时任务”。
+
+## 2.1 静态属性
+
+```
+/**
+ * 任务序号生成器，通过 AtomicLong 实现递增发号
+ */
+private static final AtomicLong nextTaskId = new AtomicLong();
+/**
+ * 定时任务时间起点
+ */
+private static final long START_TIME = System.nanoTime();
+```
+
+- `nextTaskId` 静态属性，任务序号生成器，通过 AtomicLong 实现**递增**发号。
+
+- `START_TIME` 静态属性，定时任务时间**起点**。在 ScheduledFutureTask 中，定时任务的执行时间，都是基于 `START_TIME` 做**相对**时间。😈 至于为什么使用相对时间？笔者暂时没有搞清楚。
+
+  - 笔者也搜索了下和 `System.nanoTime()` 相关的内容，唯一能看的是 [《System.nanoTime() 的隐患》](http://hold-on.iteye.com/blog/1943436) ，但是应该不是这个原因。
+
+  - 和我的大表弟普架交流了一波，他的理解是：
+
+    > 因为是定时调度，我改了系统时间也没关系
+    > 存的是距离下次调度还要多长时间
+    > 不受系统时间影响
+    > 最大的好处
+
+    - 哎哟，牛逼如我大表弟啊！！！
+
+## 2.2 nanoTime
+
+`#nanoTime()` **静态**方法，获得当前时间，这个是相对 `START_TIME` 来算的。代码如下：
+
+```
+static long nanoTime() {
+    return System.nanoTime() - START_TIME;
+}
+```
+
+- 这是个重要的方法，后续很多方法都会调用到它。
+
+## 2.3 deadlineNanos
+
+`#deadlineNanos(long delay)` **静态**方法，获得任务执行时间，这个也是相对 `START_TIME` 来算的。代码如下：
+
+```
+/**
+ * @param delay 延迟时长，单位：纳秒
+ * @return 获得任务执行时间，也是相对 {@link #START_TIME} 来算的。
+ *          实际上，返回的结果，会用于 {@link #deadlineNanos} 字段
+ */
+static long deadlineNanos(long delay) {
+    long deadlineNanos = nanoTime() + delay;
+    // Guard against overflow 防御性编程
+    return deadlineNanos < 0 ? Long.MAX_VALUE : deadlineNanos;
+}
+```
+
+## 2.4 构造方法
+
+```
+/**
+ * 任务编号
+ */
+private final long id = nextTaskId.getAndIncrement();
+/**
+ * 任务执行时间，即到了该时间，该任务就会被执行
+ */
+private long deadlineNanos;
+/**
+ * 任务执行周期
+ *
+ * =0 - 只执行一次
+ * >0 - 按照计划执行时间计算
+ * <0 - 按照实际执行时间计算
+ *
+ * 推荐阅读文章 https://blog.csdn.net/gtuu0123/article/details/6040159
+ */
+/* 0 - no repeat, >0 - repeat at fixed rate, <0 - repeat with fixed delay */
+private final long periodNanos;
+/**
+ * 队列编号
+ */
+private int queueIndex = INDEX_NOT_IN_QUEUE;
+
+ScheduledFutureTask(
+        AbstractScheduledEventExecutor executor,
+        Runnable runnable, V result, long nanoTime) {
+    this(executor, toCallable(runnable, result), nanoTime);
+}
+
+ScheduledFutureTask(
+        AbstractScheduledEventExecutor executor,
+        Callable<V> callable, long nanoTime, long period) {
+    super(executor, callable);
+    if (period == 0) {
+        throw new IllegalArgumentException("period: 0 (expected: != 0)");
+    }
+    deadlineNanos = nanoTime;
+    periodNanos = period;
+}
+
+ScheduledFutureTask(
+        AbstractScheduledEventExecutor executor,
+        Callable<V> callable, long nanoTime) {
+    super(executor, callable);
+    deadlineNanos = nanoTime;
+    periodNanos = 0;
+}
+```
+
+- 每个字段比较简单，胖友看上面的注释。
+
+## 2.5 delayNanos
+
+`#delayNanos(...)` 方法，获得距离指定时间，还要多久可执行。代码如下：
+
+```
+/**
+ * @return 距离当前时间，还要多久可执行。若为负数，直接返回 0
+ */
+public long delayNanos() {
+    return Math.max(0, deadlineNanos() - nanoTime());
+}
+
+/**
+ * @param currentTimeNanos 指定时间
+ * @return 距离指定时间，还要多久可执行。若为负数，直接返回 0
+ */
+public long delayNanos(long currentTimeNanos) {
+    return Math.max(0, deadlineNanos() - (currentTimeNanos - START_TIME));
+}
+
+@Override
+public long getDelay(TimeUnit unit) {
+    return unit.convert(delayNanos(), TimeUnit.NANOSECONDS);
+}
+```
+
+## 2.6 run
+
+`#run()` 方法，执行定时任务。代码如下：
+
+```
+ 1: @Override
+ 2: public void run() {
+ 3:     assert executor().inEventLoop();
+ 4:     try {
+ 5:         if (periodNanos == 0) {
+ 6:             // 设置任务不可取消
+ 7:             if (setUncancellableInternal()) {
+ 8:                 // 执行任务
+ 9:                 V result = task.call();
+10:                 // 通知任务执行成功
+11:                 setSuccessInternal(result);
+12:             }
+13:         } else {
+14:             // 判断任务并未取消
+15:             // check if is done as it may was cancelled
+16:             if (!isCancelled()) {
+17:                 // 执行任务
+18:                 task.call();
+19:                 if (!executor().isShutdown()) {
+20:                     // 计算下次执行时间
+21:                     long p = periodNanos;
+22:                     if (p > 0) {
+23:                         deadlineNanos += p;
+24:                     } else {
+25:                         deadlineNanos = nanoTime() - p;
+26:                     }
+27:                     // 判断任务并未取消
+28:                     if (!isCancelled()) {
+29:                         // 重新添加到任务队列，等待下次定时执行
+30:                         // scheduledTaskQueue can never be null as we lazy init it before submit the task!
+31:                         Queue<ScheduledFutureTask<?>> scheduledTaskQueue =
+32:                                 ((AbstractScheduledEventExecutor) executor()).scheduledTaskQueue;
+33:                         assert scheduledTaskQueue != null;
+34:                         scheduledTaskQueue.add(this);
+35:                     }
+36:                 }
+37:             }
+38:         }
+39:     // 发生异常，通知任务执行失败
+40:     } catch (Throwable cause) {
+41:         setFailureInternal(cause);
+42:     }
+43: }
+```
+
+- 第 3 行：校验，必须在 EventLoop 的线程中。
+
+- 根据不同的任务执行周期 `periodNanos` ，在执行任务会略有不同。当然，大体是相同的。
+
+- 第 5 至 12 行：执行周期为“
+
+  只执行一次
+
+  ”的定时任务。
+
+  - 第 7 行：调用 `PromiseTask#setUncancellableInternal()` 方法，设置任务不可取消。具体的方法实现，我们在后续关于 Promise 的文章中分享。
+  - 第 9 行：【重要】调用 `Callable#call()` 方法，执行任务。
+  - 第 11 行：调用 `PromiseTask#setSuccessInternal(V result)` 方法，回调通知注册在定时任务上的监听器。为什么能这么做呢？因为 ScheduledFutureTask 继承了 PromiseTask 抽象类。
+
+- 第 13 至 38 行：执行周期为“
+
+  固定周期
+
+  ”的定时任务。
+
+  - 第 16 行：调用 `DefaultPromise#isCancelled()` 方法，判断任务是否已经取消。这一点，和【第 7 行】的代码，**是不同的**。具体的方法实现，我们在后续关于 Promise 的文章中分享。
+  - 第 18 行：【重要】调用 `Callable#call()` 方法，执行任务。
+  - 第 19 行：判断 EventExecutor 并未关闭。
+  - 第 20 至 26 行：计算下次定时执行的时间。不同的执行 `fixed` 方式，计算方式不同。其中【第 25 行】的 `- p` 的代码，因为 `p` 是负数，所以通过**负负得正**来计算。另外，这块会修改定时任务的 `deadlineNanos` 属性，从而变成新的定时任务执行时间。
+  - 第 28 行：和【第 16 行】的代码是**一致**的。
+  - 第 29 至 34 行：重新添加到定时任务队列 `scheduledTaskQueue` 中，等待下次定时执行。
+
+- 第 39 至 42 行：发生异常，调用 `PromiseTask#setFailureInternal(Throwable cause)` 方法，回调通知注册在定时任务上的监听器。
+
+## 2.7 cancel
+
+有两个方法，可以取消定时任务。代码如下：
+
+```
+@Override
+public boolean cancel(boolean mayInterruptIfRunning) {
+    boolean canceled = super.cancel(mayInterruptIfRunning);
+    // 取消成功，移除出定时任务队列
+    if (canceled) {
+        ((AbstractScheduledEventExecutor) executor()).removeScheduled(this);
+    }
+    return canceled;
+}
+
+// 移除任务
+boolean cancelWithoutRemove(boolean mayInterruptIfRunning) {
+    return super.cancel(mayInterruptIfRunning);
+}
+```
+
+- 差别在于，是否 调用 `AbstractScheduledEventExecutor#removeScheduled(ScheduledFutureTask)` 方法，从定时任务队列移除自己。
+
+## 2.8 compareTo
+
+`#compareTo(Delayed o)` 方法，用于队列( ScheduledFutureTask 使用 PriorityQueue 作为**优先级队列** )排序。代码如下：
+
+```
+@Override
+public int compareTo(Delayed o) {
+    if (this == o) {
+        return 0;
+    }
+
+    ScheduledFutureTask<?> that = (ScheduledFutureTask<?>) o;
+    long d = deadlineNanos() - that.deadlineNanos();
+    if (d < 0) {
+        return -1;
+    } else if (d > 0) {
+        return 1;
+    } else if (id < that.id) {
+        return -1;
+    } else if (id == that.id) {
+        throw new Error();
+    } else {
+        return 1;
+    }
+}
+```
+
+- 按照 `deadlineNanos`、`id` 属性**升序**排序。
+
+## 2.9 priorityQueueIndex
+
+`#priorityQueueIndex(...)` 方法，获得或设置 `queueIndex` 属性。代码如下：
+
+```
+@Override
+public int priorityQueueIndex(DefaultPriorityQueue<?> queue) { // 获得
+    return queueIndex;
+}
+
+@Override
+public void priorityQueueIndex(DefaultPriorityQueue<?> queue, int i) { // 设置
+    queueIndex = i;
+}
+```
+
+- 因为 ScheduledFutureTask 实现 PriorityQueueNode 接口，所以需要实现这两个方法。
+
+# 3. AbstractScheduledEventExecutor
+
+`io.netty.util.concurrent.AbstractScheduledEventExecutor` ，继承 AbstractEventExecutor 抽象类，**支持定时任务**的 EventExecutor 的抽象类。
+
+## 3.1 构造方法
+
+```
+/**
+ * 定时任务队列
+ */
+PriorityQueue<ScheduledFutureTask<?>> scheduledTaskQueue;
+
+protected AbstractScheduledEventExecutor() {
+}
+
+protected AbstractScheduledEventExecutor(EventExecutorGroup parent) {
+    super(parent);
+}
+```
+
+- `scheduledTaskQueue` 属性，定时任务队列。
+
+## 3.2 scheduledTaskQueue
+
+`#scheduledTaskQueue()` 方法，获得定时任务队列。若未初始化，则进行创建。代码如下：
+
+```
+/**
+ * 定时任务排序器
+ */
+private static final Comparator<ScheduledFutureTask<?>> SCHEDULED_FUTURE_TASK_COMPARATOR =
+        new Comparator<ScheduledFutureTask<?>>() {
+            @Override
+            public int compare(ScheduledFutureTask<?> o1, ScheduledFutureTask<?> o2) {
+                return o1.compareTo(o2); //
+            }
+        };
+
+PriorityQueue<ScheduledFutureTask<?>> scheduledTaskQueue() {
+    if (scheduledTaskQueue == null) {
+        scheduledTaskQueue = new DefaultPriorityQueue<ScheduledFutureTask<?>>(
+                SCHEDULED_FUTURE_TASK_COMPARATOR,
+                // Use same initial capacity as java.util.PriorityQueue
+                11);
+    }
+    return scheduledTaskQueue;
+}
+```
+
+- 创建的队列是 `io.netty.util.internal.DefaultPriorityQueue` 类型。具体的代码实现，本文先不解析。在这里，我们只要知道它是一个**优先级**队列，通过 `SCHEDULED_FUTURE_TASK_COMPARATOR` 来比较排序 ScheduledFutureTask 的任务优先级( 顺序 )。
+- `SCHEDULED_FUTURE_TASK_COMPARATOR` 的具体实现，是调用 [「2.8 compareTo」](https://svip.iocoder.cn/Netty/EventLoop-7-EventLoop-handle-schedule-task/#) 方法来实现，所以队列**首个**任务，就是**第一个**需要执行的定时任务。
+
+## 3.3 nanoTime
+
+`#nanoTime()` **静态**方法，获得当前时间。代码如下：
+
+```
+protected static long nanoTime() {
+    return ScheduledFutureTask.nanoTime();
+}
+```
+
+- 在方法内部，会调用 [「2.2 nanoTime」](https://svip.iocoder.cn/Netty/EventLoop-7-EventLoop-handle-schedule-task/#) 方法。
+
+## 3.4 schedule
+
+`#schedule(final ScheduledFutureTask<V> task)` 方法，提交定时任务。代码如下：
+
+```
+<V> ScheduledFuture<V> schedule(final ScheduledFutureTask<V> task) {
+    if (inEventLoop()) {
+        // 添加到定时任务队列
+        scheduledTaskQueue().add(task);
+    } else {
+        // 通过 EventLoop 的线程，添加到定时任务队列
+        execute(new Runnable() {
+            @Override
+            public void run() {
+                scheduledTaskQueue().add(task);
+            }
+        });
+    }
+    return task;
+}
+```
+
+- 必须在 EventLoop 的线程中，**才能**添加到定时任务到队列中。
+
+在 ScheduledFutureTask 中，有四个方法，会调用 `#schedule(final ScheduledFutureTask<V> task)` 方法，分别创建 **3** 种不同类型的定时任务。代码如下：
+
+```
+@Override
+public <V> ScheduledFuture<V> schedule(Callable<V> callable, long delay, TimeUnit unit) {
+    ObjectUtil.checkNotNull(callable, "callable");
+    ObjectUtil.checkNotNull(unit, "unit");
+    if (delay < 0) {
+        delay = 0;
+    }
+    // 无视，已经废弃
+    validateScheduled0(delay, unit);
+
+    return schedule(new ScheduledFutureTask<V>(
+            this, callable, ScheduledFutureTask.deadlineNanos(unit.toNanos(delay))));
+}
+
+@Override
+public ScheduledFuture<?> scheduleAtFixedRate(Runnable command, long initialDelay, long period, TimeUnit unit) {
+    ObjectUtil.checkNotNull(command, "command");
+    ObjectUtil.checkNotNull(unit, "unit");
+    if (initialDelay < 0) {
+        throw new IllegalArgumentException(
+                String.format("initialDelay: %d (expected: >= 0)", initialDelay));
+    }
+    if (period <= 0) {
+        throw new IllegalArgumentException(
+                String.format("period: %d (expected: > 0)", period));
+    }
+    // 无视，已经废弃
+    validateScheduled0(initialDelay, unit);
+    validateScheduled0(period, unit);
+
+    return schedule(new ScheduledFutureTask<Void>(
+            this, Executors.<Void>callable(command, null), // Runnable => Callable
+            ScheduledFutureTask.deadlineNanos(unit.toNanos(initialDelay)), unit.toNanos(period)));
+}
+
+@Override
+public ScheduledFuture<?> scheduleWithFixedDelay(Runnable command, long initialDelay, long delay, TimeUnit unit) {
+    ObjectUtil.checkNotNull(command, "command");
+    ObjectUtil.checkNotNull(unit, "unit");
+    if (initialDelay < 0) {
+        throw new IllegalArgumentException(
+                String.format("initialDelay: %d (expected: >= 0)", initialDelay));
+    }
+    if (delay <= 0) {
+        throw new IllegalArgumentException(
+                String.format("delay: %d (expected: > 0)", delay));
+    }
+    // 无视，已经废弃
+    validateScheduled0(initialDelay, unit);
+    validateScheduled0(delay, unit);
+
+    return schedule(new ScheduledFutureTask<Void>(
+            this, Executors.<Void>callable(command, null), // Runnable => Callable
+            ScheduledFutureTask.deadlineNanos(unit.toNanos(initialDelay)), -unit.toNanos(delay)));
+}
+```
+
+- 每个方法，前面都是校验参数的代码，重点是在最后对 `#schedule(final ScheduledFutureTask<V> task)` 方法的调用。
+
+## 3.5 removeScheduled
+
+`#removeScheduled(final ScheduledFutureTask<?> task)` 方法，移除出定时任务队列。代码如下：
+
+```
+final void removeScheduled(final ScheduledFutureTask<?> task) {
+    if (inEventLoop()) {
+        // 移除出定时任务队列
+        scheduledTaskQueue().removeTyped(task);
+    } else {
+        // 通过 EventLoop 的线程，移除出定时任务队列
+        execute(new Runnable() {
+            @Override
+            public void run() {
+                removeScheduled(task);
+            }
+        });
+    }
+}
+```
+
+- 必须在 EventLoop 的线程中，**才能**移除出定时任务队列。
+
+## 3.6 hasScheduledTasks
+
+`#hasScheduledTasks()` 方法，判断是否有可执行的定时任务。代码如下：
+
+```
+/**
+ * Returns {@code true} if a scheduled task is ready for processing.
+ */
+protected final boolean hasScheduledTasks() {
+    Queue<ScheduledFutureTask<?>> scheduledTaskQueue = this.scheduledTaskQueue;
+    // 获得队列首个定时任务。不会从队列中，移除该任务
+    ScheduledFutureTask<?> scheduledTask = scheduledTaskQueue == null ? null : scheduledTaskQueue.peek();
+    // 判断该任务是否到达可执行的时间
+    return scheduledTask != null && scheduledTask.deadlineNanos() <= nanoTime();
+}
+```
+
+- 代码比较简单，胖友直接看方法注释。
+
+## 3.7 peekScheduledTask
+
+`#peekScheduledTask()` 方法，获得队列首个定时任务。不会从队列中，移除该任务。代码如下：
+
+```
+final ScheduledFutureTask<?> peekScheduledTask() {
+    Queue<ScheduledFutureTask<?>> scheduledTaskQueue = this.scheduledTaskQueue;
+    if (scheduledTaskQueue == null) {
+        return null;
+    }
+    return scheduledTaskQueue.peek();
+}
+```
+
+## 3.8 nextScheduledTaskNano
+
+`#nextScheduledTaskNano()` 方法，获得定时任务队列，距离当前时间，还要多久可执行。
+
+- 若队列**为空**，则返回 `-1` 。
+- 若队列**非空**，若为负数，直接返回 0 。实际等价，ScheduledFutureTask#delayNanos() 方法。
+
+代码如下：
+
+```
+/**
+ * Return the nanoseconds when the next scheduled task is ready to be run or {@code -1} if no task is scheduled.
+ */
+protected final long nextScheduledTaskNano() {
+    Queue<ScheduledFutureTask<?>> scheduledTaskQueue = this.scheduledTaskQueue;
+    // 获得队列首个定时任务。不会从队列中，移除该任务
+    ScheduledFutureTask<?> scheduledTask = scheduledTaskQueue == null ? null : scheduledTaskQueue.peek();
+    if (scheduledTask == null) {
+        return -1;
+    }
+    // 距离当前时间，还要多久可执行。若为负数，直接返回 0 。实际等价，ScheduledFutureTask#delayNanos() 方法。
+    return Math.max(0, scheduledTask.deadlineNanos() - nanoTime());
+}
+```
+
+- 基本可以等价 [「2.5 delayNanos」](https://svip.iocoder.cn/Netty/EventLoop-7-EventLoop-handle-schedule-task/#) 的方法。
+
+## 3.9 pollScheduledTask
+
+`#pollScheduledTask(...)` 方法，获得指定时间内，定时任务队列**首个**可执行的任务，并且从队列中移除。代码如下：
+
+```
+/**
+ * @see #pollScheduledTask(long)
+ */
+protected final Runnable pollScheduledTask() {
+    return pollScheduledTask(nanoTime()); // 当前时间
+}
+
+/**
+ * Return the {@link Runnable} which is ready to be executed with the given {@code nanoTime}.
+ * You should use {@link #nanoTime()} to retrieve the correct {@code nanoTime}.
+ */
+protected final Runnable pollScheduledTask(long nanoTime) {
+    assert inEventLoop();
+
+    Queue<ScheduledFutureTask<?>> scheduledTaskQueue = this.scheduledTaskQueue;
+    // 获得队列首个定时任务。不会从队列中，移除该任务
+    ScheduledFutureTask<?> scheduledTask = scheduledTaskQueue == null ? null : scheduledTaskQueue.peek();
+    // 直接返回，若获取不到
+    if (scheduledTask == null) {
+        return null;
+    }
+
+    // 在指定时间内，则返回该任务
+    if (scheduledTask.deadlineNanos() <= nanoTime) {
+        scheduledTaskQueue.remove(); // 移除任务
+        return scheduledTask;
+    }
+    return null;
+}
+```
+
+## 3.10 cancelScheduledTasks
+
+`#cancelScheduledTasks()` 方法，取消定时任务队列的所有任务。代码如下：
+
+```
+/**
+ * Cancel all scheduled tasks.
+ * <p>
+ * This method MUST be called only when {@link #inEventLoop()} is {@code true}.
+ */
+protected void cancelScheduledTasks() {
+    assert inEventLoop();
+
+    // 若队列为空，直接返回
+    PriorityQueue<ScheduledFutureTask<?>> scheduledTaskQueue = this.scheduledTaskQueue;
+    if (isNullOrEmpty(scheduledTaskQueue)) {
+        return;
+    }
+
+    // 循环，取消所有任务
+    final ScheduledFutureTask<?>[] scheduledTasks = scheduledTaskQueue.toArray(new ScheduledFutureTask<?>[0]);
+    for (ScheduledFutureTask<?> task : scheduledTasks) {
+        task.cancelWithoutRemove(false);
+    }
+
+    scheduledTaskQueue.clearIgnoringIndexes();
+}
+
+private static boolean isNullOrEmpty(Queue<ScheduledFutureTask<?>> queue) {
+    return queue == null || queue.isEmpty();
+}
+```
+
+- 代码比较简单，胖友自己看注释。
+
+# 4. SingleThreadEventExecutor
+
+在 [《精尽 Netty 源码解析 —— EventLoop（六）之 EventLoop 处理普通任务》](http://svip.iocoder.cn/Netty/EventLoop-6-EventLoop-handle-normal-task?self) 中，有个 `#fetchFromScheduledTaskQueue()` 方法，将定时任务队列 `scheduledTaskQueue` 到达可执行的任务，添加到任务队列 `taskQueue` 中。代码如下：
+
+```
+private boolean fetchFromScheduledTaskQueue() {
+    // 获得当前时间
+    long nanoTime = AbstractScheduledEventExecutor.nanoTime();
+    // 获得指定时间内，定时任务队列**首个**可执行的任务，并且从队列中移除。
+    Runnable scheduledTask  = pollScheduledTask(nanoTime);
+    // 不断从定时任务队列中，获得
+    while (scheduledTask != null) {
+        // 将定时任务添加到 taskQueue 中。若添加失败，则结束循环，返回 false ，表示未获取完所有课执行的定时任务
+        if (!taskQueue.offer(scheduledTask)) {
+            // 将定时任务添加回 scheduledTaskQueue 中
+            // No space left in the task queue add it back to the scheduledTaskQueue so we pick it up again.
+            scheduledTaskQueue().add((ScheduledFutureTask<?>) scheduledTask);
+            return false;
+        }
+        // 获得指定时间内，定时任务队列**首个**可执行的任务，并且从队列中移除。
+        scheduledTask  = pollScheduledTask(nanoTime);
+    }
+    // 返回 true ，表示获取完所有可执行的定时任务
+    return true;
+}
+```
+
+- 代码比较简单，胖友看下笔者的详细代码注释。哈哈哈
+
+# 666. 彩蛋
+
+没有彩蛋，简单水文一篇。
\ No newline at end of file
diff --git a/netty/20-Netty 源码解析-EventLoop（八）之 EventLoop 优雅关闭.md b/netty/20-Netty 源码解析-EventLoop（八）之 EventLoop 优雅关闭.md
new file mode 100644
index 0000000..3bdcadd
--- /dev/null
+++ b/netty/20-Netty 源码解析-EventLoop（八）之 EventLoop 优雅关闭.md	
@@ -0,0 +1,276 @@
+# 精尽 Netty 源码解析 —— EventLoop（八）之 EventLoop 优雅关闭
+
+# 1. 概述
+
+笔者先把 Netty 主要的内容写完，所以关于 EventLoop 的优雅关闭的分享，先放在后续的计划里。
+
+当然，良心如我，还是为对这块感兴趣的胖友，先准备好了两篇不错的文章：
+
+- Hypercube [《自顶向下深入分析 Netty（四）–优雅退出机制》](https://www.jianshu.com/p/088c5017acd6)
+- tomas家的小拨浪鼓 [《Netty 源码解析 ——— Netty 优雅关闭流程》](https://www.jianshu.com/p/e0ba9050aaef)
+
+为避免可能 [《自顶向下深入分析 Netty（四）–优雅退出机制》](https://www.jianshu.com/p/088c5017acd6) 被作者删除，笔者这里先复制一份作为备份。
+
+# 666. Netty优雅退出机制
+
+你也许已经习惯了使用下面的代码，使一个线程池退出：
+
+```
+bossGroup.shutdownGracefully();
+```
+
+那么它是如何工作的呢？由于bossGroup是一个线程池，线程池的关闭要求其中的每一个线程关闭。而线程的实现是在SingleThreadEventExecutor类，所以我们将再次回到这个类，首先看其中的shutdownGracefully()方法，其中的参数quietPeriod为静默时间，timeout为截止时间，此外还有一个相关参数gracefulShutdownStartTime即优雅关闭开始时间，代码如下：
+
+```
+@Override
+public Future<?> shutdownGracefully(long quietPeriod, long timeout, TimeUnit unit) {
+    if (isShuttingDown()) {
+        return terminationFuture(); // 正在关闭阻止其他线程
+    }
+
+    boolean inEventLoop = inEventLoop();
+    boolean wakeup;
+    int oldState;
+    for (;;) {
+        if (isShuttingDown()) {
+            return terminationFuture(); // 正在关闭阻止其他线程
+        }
+        int newState;
+        wakeup = true;
+        oldState = STATE_UPDATER.get(this);
+        if (inEventLoop) {
+            newState = ST_SHUTTING_DOWN;
+        } else {
+            switch (oldState) {
+                case ST_NOT_STARTED:
+                case ST_STARTED:
+                    newState = ST_SHUTTING_DOWN;
+                    break;
+                default: // 一个线程已修改好线程状态，此时这个线程才执行16行代码
+                    newState = oldState;
+                    wakeup = false; // 已经有线程唤醒，所以不用再唤醒
+            }
+        }
+        if (STATE_UPDATER.compareAndSet(this, oldState, newState)) {
+            break;  // 保证只有一个线程将oldState修改为newState
+        }
+        // 隐含STATE_UPDATER已被修改，则在下一次循环返回
+    }
+     // 在default情况下会更新这两个值
+    gracefulShutdownQuietPeriod = unit.toNanos(quietPeriod);
+    gracefulShutdownTimeout = unit.toNanos(timeout);
+
+    if (oldState == ST_NOT_STARTED) {
+        thread.start();
+    }
+    if (wakeup) {
+        wakeup(inEventLoop);
+    }
+    return terminationFuture();
+}
+```
+
+这段代码真是为多线程同时调用关闭的情况操碎了心，我们抓住其中的关键点：该方法只是将线程状态修改为ST_SHUTTING_DOWN并不执行具体的关闭操作（类似的shutdown方法将线程状态修改为ST_SHUTDOWN）。for()循环是为了保证修改state的线程（原生线程或者外部线程）有且只有一个。如果你还没有理解这句话，请查阅compareAndSet()方法的说明然后再看一遍。39-44行代码之所以这样处理，是因为子类的实现中run()方法是一个EventLoop即一个循环。40行代码启动线程可以完整走一遍正常流程并且可以处理添加到队列中的任务以及IO事件。43行唤醒阻塞在阻塞点上的线程，使其从阻塞状态退出。要从一个EventLoop循环中退出，有什么好方法吗？可能你会想到这样处理：设置一个标记，每次循环都检测这个标记，如果标记为真就退出。Netty正是使用这种方法，NioEventLoop的run()方法的循环部分有这样一段代码：
+
+```
+if (isShuttingDown()) { // 检测线程状态
+    closeAll(); // 关闭注册的channel
+    if (confirmShutdown()) {
+        break;
+    }
+}
+```
+
+查询线程状态的方法有三个，实现简单，一并列出：
+
+```
+public boolean isShuttingDown() {
+    return STATE_UPDATER.get(this) >= ST_SHUTTING_DOWN;
+}
+
+public boolean isShutdown() {
+    return STATE_UPDATER.get(this) >= ST_SHUTDOWN;
+}
+
+public boolean isTerminated() {
+    return STATE_UPDATER.get(this) == ST_TERMINATED;
+}
+```
+
+需要注意的是调用shutdownGracefully()方法后线程状态为ST_SHUTTING_DOWN，调用shutdown()方法后线程状态为ST_SHUTDOWN。isShuttingDown()可以一并判断这两种调用方法。closeAll()方法关闭注册到NioEventLoop的所有Channel，代码不再列出。confirmShutdown()方法在SingleThreadEventExecutor类，确定是否可以关闭或者说是否可以从EventLoop循环中跳出。代码如下：
+
+```
+protected boolean confirmShutdown() {
+    if (!isShuttingDown()) {
+        return false;   // 没有调用shutdown相关的方法直接返回
+    }
+    if (!inEventLoop()) {   // 必须是原生线程
+        throw new IllegalStateException("must be invoked from an event loop");
+    }
+
+    cancelScheduledTasks(); // 取消调度任务
+    if (gracefulShutdownStartTime == 0) {   // 优雅关闭开始时间，这也是一个标记
+        gracefulShutdownStartTime = ScheduledFutureTask.nanoTime();
+    }
+    
+    // 执行完普通任务或者没有普通任务时执行完shutdownHook任务
+    if (runAllTasks() || runShutdownHooks()) {
+        if (isShutdown()) {
+            return true;    // 调用shutdown()方法直接退出
+        }
+        if (gracefulShutdownQuietPeriod == 0) {
+            return true;    // 优雅关闭静默时间为0也直接退出
+        }
+        wakeup(true);   // 优雅关闭但有未执行任务，唤醒线程执行
+        return false;
+    }
+
+    final long nanoTime = ScheduledFutureTask.nanoTime();
+    // shutdown()方法调用直接返回，优雅关闭截止时间到也返回
+    if (isShutdown() || nanoTime - gracefulShutdownStartTime > gracefulShutdownTimeout) {
+        return true;
+    }
+    // 在静默期间每100ms唤醒线程执行期间提交的任务
+    if (nanoTime - lastExecutionTime <= gracefulShutdownQuietPeriod) {
+        wakeup(true);
+        try {
+            Thread.sleep(100);
+        } catch (InterruptedException e) {
+            // Ignore
+        }
+        return false;
+    }
+    // 静默时间内没有任务提交，可以优雅关闭，此时若用户又提交任务则不会被执行
+    return true;
+}
+```
+
+我们总结一下，调用shutdown()方法从循环跳出的条件有：
+(1).执行完普通任务
+(2).没有普通任务，执行完shutdownHook任务
+(3).既没有普通任务也没有shutdownHook任务
+调用shutdownGracefully()方法从循环跳出的条件有：
+(1).执行完普通任务且静默时间为0
+(2).没有普通任务，执行完shutdownHook任务且静默时间为0
+(3).静默期间没有任务提交
+(4).优雅关闭截止时间已到
+注意上面所列的条件之间是**或**的关系，也就是说满足任意一条就会从EventLoop循环中跳出。我们可以将静默时间看为一段观察期，在此期间如果没有任务执行，说明可以跳出循环；如果此期间有任务执行，执行完后立即进入下一个观察期继续观察；如果连续多个观察期一直有任务执行，那么截止时间到则跳出循环。我们看一下shutdownGracefully()的默认参数：
+
+```
+public Future<?> shutdownGracefully() {
+    return shutdownGracefully(2, 15, TimeUnit.SECONDS);
+}
+```
+
+可知，Netty默认的shutdownGracefully()机制为：在2秒的静默时间内如果没有任务，则关闭；否则15秒截止时间到达时关闭。换句话说，在15秒时间段内，如果有超过2秒的时间段没有任务则关闭。至此，我们明白了从EvnetLoop循环中跳出的机制，最后，我们抵达终点站：线程结束机制。这一部分的代码实现在线程工厂的生成方法中：
+
+```
+thread = threadFactory.newThread(new Runnable() {
+        @Override
+        public void run() {
+            boolean success = false;
+            updateLastExecutionTime();
+            try {
+                SingleThreadEventExecutor.this.run();   // 模板方法，EventLoop实现
+                success = true;
+            } catch (Throwable t) {
+                logger.warn("Unexpected exception from an event executor: ", t);
+            } finally {
+                for (;;) {
+                    int oldState = STATE_UPDATER.get(SingleThreadEventExecutor.this);
+                    // 用户调用了关闭的方法或者抛出异常
+                    if (oldState >= ST_SHUTTING_DOWN || STATE_UPDATER.compareAndSet(
+                            SingleThreadEventExecutor.this, oldState, ST_SHUTTING_DOWN)) {
+                        break;  // 抛出异常也将状态置为ST_SHUTTING_DOWN
+                    }
+                }
+                if (success && gracefulShutdownStartTime == 0) {
+                    // time=0，说明confirmShutdown()方法没有调用，记录日志
+                }
+
+                try {
+                    for (;;) {
+                        // 抛出异常时，将普通任务和shutdownHook任务执行完毕
+                        // 正常关闭时，结合前述的循环跳出条件
+                        if (confirmShutdown()) {
+                            break;
+                        }
+                    }
+                } finally {
+                    try {
+                        cleanup();
+                    } finally {
+                        // 线程状态设置为ST_TERMINATED，线程终止
+                        STATE_UPDATER.set(SingleThreadEventExecutor.this, ST_TERMINATED);
+                        threadLock.release();
+                        if (!taskQueue.isEmpty()) {
+                            //  关闭时，任务队列中添加了任务，记录日志
+                        }
+                        terminationFuture.setSuccess(null); // 异步结果设置为成功
+                    }
+                }
+            }
+        }
+    });
+```
+
+20-22行代码说明子类在实现模板方法run()时，须调用confirmShutdown()方法，不调用的话会有错误日志。25-31行的for()循环主要是对异常情况的处理，但同时也兼顾了正常调用关闭方法的情况。可以将抛出异常的情况视为静默时间为0的shutdownGracefully()方法，这样便于理解循环跳出条件。34行代码cleanup()的默认实现什么也不做，NioEventLoop覆盖了基类，实现关闭NioEventLoop持有的selector：
+
+```
+protected void cleanup() {
+    try {
+        selector.close();
+    } catch (IOException e) {
+        logger.warn("Failed to close a selector.", e);
+    }
+}
+```
+
+关于Netty优雅关闭的机制，还有最后一点细节，那就是runShutdownHooks()方法：
+
+```
+private boolean runShutdownHooks() {
+    boolean ran = false;
+    while (!shutdownHooks.isEmpty()) {
+        // 使用copy是因为shutdwonHook任务中可以添加或删除shutdwonHook任务
+        List<Runnable> copy = new ArrayList<Runnable>(shutdownHooks);
+        shutdownHooks.clear();
+        for (Runnable task: copy) {
+            try {
+                task.run();
+            } catch (Throwable t) {
+                logger.warn("Shutdown hook raised an exception.", t);
+            } finally {
+                ran = true;
+            }
+        }
+    }
+    if (ran) {
+        lastExecutionTime = ScheduledFutureTask.nanoTime();
+    }
+    return ran;
+}
+```
+
+此外，还有threadLock.release()方法，如果你还记得字段定义，threadLock是一个初始值为0的信号量。一个初值为0的信号量，当线程请求锁时只会阻塞，这有什么用呢？awaitTermination()方法揭晓答案，用来使其他线程阻塞等待原生线程关闭 ：
+
+```
+public boolean awaitTermination(long timeout, TimeUnit unit) throws InterruptedException {
+    // 由于tryAcquire()永远不会成功，所以必定阻塞timeout时间
+    if (threadLock.tryAcquire(timeout, unit)) {
+        threadLock.release();
+    }
+    return isTerminated();
+}
+```
+
+**文章目录**
+
+1. [1. 概述](https://svip.iocoder.cn/Netty/EventLoop-8-EventLoop-shutdown/#1-概述)
+2. [666. Netty优雅退出机制](https://svip.iocoder.cn/Netty/EventLoop-8-EventLoop-shutdown/#666-Netty优雅退出机制)
+
+© 2014 - 2024 芋道源码 | 
+
+总访客数 3353436 次 && 总访问量 6533208 次
+
+[回到首页](https://svip.iocoder.cn/index)
\ No newline at end of file
diff --git a/netty/21-Netty 源码解析-ChannelPipeline（一）之初始化.assets/01.png b/netty/21-Netty 源码解析-ChannelPipeline（一）之初始化.assets/01.png
new file mode 100644
index 0000000..694402c
Binary files /dev/null and b/netty/21-Netty 源码解析-ChannelPipeline（一）之初始化.assets/01.png differ
diff --git a/netty/21-Netty 源码解析-ChannelPipeline（一）之初始化.assets/02.png b/netty/21-Netty 源码解析-ChannelPipeline（一）之初始化.assets/02.png
new file mode 100644
index 0000000..9c6ed4b
Binary files /dev/null and b/netty/21-Netty 源码解析-ChannelPipeline（一）之初始化.assets/02.png differ
diff --git a/netty/21-Netty 源码解析-ChannelPipeline（一）之初始化.assets/03.png b/netty/21-Netty 源码解析-ChannelPipeline（一）之初始化.assets/03.png
new file mode 100644
index 0000000..9ce639f
Binary files /dev/null and b/netty/21-Netty 源码解析-ChannelPipeline（一）之初始化.assets/03.png differ
diff --git a/netty/21-Netty 源码解析-ChannelPipeline（一）之初始化.assets/04.png b/netty/21-Netty 源码解析-ChannelPipeline（一）之初始化.assets/04.png
new file mode 100644
index 0000000..e5bbfec
Binary files /dev/null and b/netty/21-Netty 源码解析-ChannelPipeline（一）之初始化.assets/04.png differ
diff --git a/netty/21-Netty 源码解析-ChannelPipeline（一）之初始化.assets/05.png b/netty/21-Netty 源码解析-ChannelPipeline（一）之初始化.assets/05.png
new file mode 100644
index 0000000..cb8677e
Binary files /dev/null and b/netty/21-Netty 源码解析-ChannelPipeline（一）之初始化.assets/05.png differ
diff --git a/netty/21-Netty 源码解析-ChannelPipeline（一）之初始化.md b/netty/21-Netty 源码解析-ChannelPipeline（一）之初始化.md
new file mode 100644
index 0000000..922a883
--- /dev/null
+++ b/netty/21-Netty 源码解析-ChannelPipeline（一）之初始化.md	
@@ -0,0 +1,812 @@
+# 精尽 Netty 源码解析 —— ChannelPipeline（一）之初始化
+
+# 1. 概述
+
+在 [《精尽 Netty 源码分析 —— Netty 简介（二）之核心组件》](http://svip.iocoder.cn/Netty/intro-2/?self) 中，对 EventLoopGroup 和 EventLoop 做了定义，我们再来回顾下：
+
+> ChannelPipeline 为 ChannelHandler 的**链**，提供了一个容器并定义了用于沿着链传播入站和出站事件流的 API 。一个数据或者事件可能会被多个 Handler 处理，在这个过程中，数据或者事件经流 ChannelPipeline ，由 ChannelHandler 处理。在这个处理过程中，一个 ChannelHandler 接收数据后处理完成后交给下一个 ChannelHandler，或者什么都不做直接交给下一个 ChannelHandler。
+
+因为 ChannelPipeline 涉及的代码量较大，所以笔者会分成好几篇文章分别分享。而本文，我们来分享 ChannelPipeline 的**初始化**。也因此，本文更多是体现 ChannelPipeline 的**整体性**，所以不会过多介绍每个类的具体的**每个方法**的实现。
+
+# 2. ChannelPipeline
+
+`io.netty.channel.ChannelPipeline` ，继承 ChannelInboundInvoker、ChannelOutboundInvoker、Iterable 接口，Channel Pipeline 接口。代码如下：
+
+```
+public interface ChannelPipeline
+        extends ChannelInboundInvoker, ChannelOutboundInvoker, Iterable<Entry<String, ChannelHandler>> {
+
+    // ========== 添加 ChannelHandler 相关 ==========
+    ChannelPipeline addFirst(String name, ChannelHandler handler);
+    ChannelPipeline addFirst(EventExecutorGroup group, String name, ChannelHandler handler);
+    ChannelPipeline addLast(String name, ChannelHandler handler);
+    ChannelPipeline addLast(EventExecutorGroup group, String name, ChannelHandler handler);
+    ChannelPipeline addBefore(String baseName, String name, ChannelHandler handler);
+    ChannelPipeline addBefore(EventExecutorGroup group, String baseName, String name, ChannelHandler handler);
+    ChannelPipeline addAfter(String baseName, String name, ChannelHandler handler);
+    ChannelPipeline addAfter(EventExecutorGroup group, String baseName, String name, ChannelHandler handler);
+    ChannelPipeline addFirst(ChannelHandler... handlers);
+    ChannelPipeline addFirst(EventExecutorGroup group, ChannelHandler... handlers);
+    ChannelPipeline addLast(ChannelHandler... handlers);
+    ChannelPipeline addLast(EventExecutorGroup group, ChannelHandler... handlers);
+
+    // ========== 移除 ChannelHandler 相关 ==========
+    ChannelPipeline remove(ChannelHandler handler);
+    ChannelHandler remove(String name);
+    <T extends ChannelHandler> T remove(Class<T> handlerType);
+    ChannelHandler removeFirst();
+    ChannelHandler removeLast();
+    
+    // ========== 替换 ChannelHandler 相关 ==========
+    ChannelPipeline replace(ChannelHandler oldHandler, String newName, ChannelHandler newHandler);
+    ChannelHandler replace(String oldName, String newName, ChannelHandler newHandler);
+    <T extends ChannelHandler> T replace(Class<T> oldHandlerType, String newName, ChannelHandler newHandler);
+
+    // ========== 查询 ChannelHandler 相关 ==========
+    ChannelHandler first();
+    ChannelHandlerContext firstContext();
+    ChannelHandler last();
+    ChannelHandlerContext lastContext();
+    ChannelHandler get(String name);
+    <T extends ChannelHandler> T get(Class<T> handlerType);
+    ChannelHandlerContext context(ChannelHandler handler);
+    ChannelHandlerContext context(String name);
+    ChannelHandlerContext context(Class<? extends ChannelHandler> handlerType);
+    List<String> names();
+
+    // ========== Channel 相关 ==========
+    Channel channel();
+
+    // ========== ChannelInboundInvoker 相关 ==========    
+    @Override
+    ChannelPipeline fireChannelRegistered();
+    @Override
+    ChannelPipeline fireChannelUnregistered();
+    @Override
+    ChannelPipeline fireChannelActive();
+    @Override
+    ChannelPipeline fireChannelInactive();
+    @Override
+    ChannelPipeline fireExceptionCaught(Throwable cause);
+    @Override
+    ChannelPipeline fireUserEventTriggered(Object event);
+    @Override
+    ChannelPipeline fireChannelRead(Object msg);
+    @Override
+    ChannelPipeline fireChannelReadComplete();
+    @Override
+    ChannelPipeline fireChannelWritabilityChanged();
+
+    // ========== ChannelOutboundInvoker 相关 ==========    
+    @Override
+    ChannelPipeline flush();
+    
+}
+```
+
+虽然接口的方法比较多，笔者做了归类如下：
+
+- ChannelHandler 的增删改查的相关方法。
+- Channel 的相关方法，目前只有一个。
+- 继承自 ChannelInboundInvoker 的相关方法。
+- 继承自 ChannelOutboundInvoker 的相关方法。
+
+有可能会疑惑为什么继承 Iterable 接口？因为 ChannelPipeline 是 ChannelHandler 的**链**。
+
+ChannelPipeline 的类图如下：
+
+[![ChannelPipeline 类图](21-Netty 源码解析-ChannelPipeline（一）之初始化.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_06_01/01.png)ChannelPipeline 类图
+
+## 2.1 ChannelInboundInvoker
+
+`io.netty.channel.ChannelInboundInvoker` ，Channel Inbound Invoker( 调用者 ) 接口。代码如下：
+
+```
+ChannelPipeline fireChannelRegistered();
+ChannelPipeline fireChannelUnregistered();
+ChannelPipeline fireChannelActive();
+ChannelPipeline fireChannelInactive();
+ChannelPipeline fireExceptionCaught(Throwable cause);
+ChannelPipeline fireUserEventTriggered(Object event);
+ChannelPipeline fireChannelRead(Object msg);
+ChannelPipeline fireChannelReadComplete();
+ChannelPipeline fireChannelWritabilityChanged();
+```
+
+- 通知 Channel 事件的接口方法。
+
+## 2.2 ChannelOutboundInvoker
+
+`io.netty.channel.ChannelOutboundInvoker` ，Channel Outbound Invoker( 调用者 ) 接口。代码如下：
+
+```
+// ========== Channel 操作相关 ==========    
+ChannelFuture bind(SocketAddress localAddress);
+ChannelFuture connect(SocketAddress remoteAddress);
+ChannelFuture connect(SocketAddress remoteAddress, SocketAddress localAddress);
+ChannelFuture disconnect();
+ChannelFuture close();
+ChannelFuture deregister();
+ChannelFuture bind(SocketAddress localAddress, ChannelPromise promise);
+ChannelFuture connect(SocketAddress remoteAddress, ChannelPromise promise);
+ChannelFuture connect(SocketAddress remoteAddress, SocketAddress localAddress, ChannelPromise promise);
+ChannelFuture disconnect(ChannelPromise promise);
+ChannelFuture close(ChannelPromise promise);
+ChannelFuture deregister(ChannelPromise promise);
+ChannelOutboundInvoker read();
+ChannelFuture write(Object msg);
+ChannelFuture write(Object msg, ChannelPromise promise);
+ChannelOutboundInvoker flush();
+ChannelFuture writeAndFlush(Object msg, ChannelPromise promise);
+ChannelFuture writeAndFlush(Object msg);
+
+// ========== Promise 相关 ==========    
+ChannelPromise newPromise();
+ChannelProgressivePromise newProgressivePromise();
+ChannelFuture newSucceededFuture();
+ChannelFuture newFailedFuture(Throwable cause);
+ChannelPromise voidPromise();
+```
+
+- 发起 Channel 操作的接口方法。
+- 创建 Promise 对象的接口方法。
+
+## 2.3 Outbound v.s Inbound 事件
+
+在 [《Netty 源码分析之 二 贯穿Netty 的大动脉 ── ChannelPipeline (二)》](https://segmentfault.com/a/1190000007309311) 中，笔者看到一个比较不错的总结：
+
+> 老艿艿：因为要加一些注释，所以暂时不使用引用。
+
+**对于 Outbound 事件**：
+
+- Outbound 事件是【请求】事件(由 Connect 发起一个请求, 并最终由 Unsafe 处理这个请求)
+
+- Outbound 事件的发起者是 Channel
+
+- Outbound 事件的处理者是 Unsafe
+
+- Outbound 事件在 Pipeline 中的传输方向是 `tail` -> `head`
+
+  > 旁白：Outbound 翻译为“出站”，所以从 `tail`( 尾 )到 `head`( 头 )也合理。
+  >
+  > 至于什么是 `head` 和 `tail` ，等看了具体的 ChannelPipeline 实现类 DefaultChannelPipeline 再说。
+
+- 在 ChannelHandler 中处理事件时, 如果这个 Handler 不是最后一个 Handler, 则需要调用 `ctx.xxx` (例如 `ctx.connect` ) 将此事件继续传播下去. 如果不这样做, 那么此事件的传播会提前终止.
+
+- Outbound 事件流: `Context.OUT_EVT` -> `Connect.findContextOutbound` -> `nextContext.invokeOUT_EVT` -> `nextHandler.OUT_EVT` -> `nextContext.OUT_EVT`
+
+**对于 Inbound 事件**：
+
+- Inbound 事件是【通知】事件, 当某件事情已经就绪后, 通知上层.
+
+- Inbound 事件发起者是 Unsafe
+
+- Inbound 事件的处理者是 TailContext, 如果用户没有实现自定义的处理方法, 那么Inbound 事件默认的处理者是 TailContext, 并且其处理方法是空实现.
+
+- Inbound 事件在 Pipeline 中传输方向是 `head`( 头 ) -> `tail`( 尾 )
+
+  > 旁白：Inbound 翻译为“入站”，所以从 `head`( 头 )到 `tail`( 尾 )也合理。
+
+- 在 ChannelHandler 中处理事件时, 如果这个 Handler 不是最后一个 Handler, 则需要调用 `ctx.fireIN_EVT` (例如 `ctx.fireChannelActive` ) 将此事件继续传播下去. 如果不这样做, 那么此事件的传播会提前终止.
+
+- Inbound 事件流: `Context.fireIN_EVT` -> `Connect.findContextInbound` -> `nextContext.invokeIN_EVT` -> `nextHandler.IN_EVT` -> `nextContext.fireIN_EVT`
+
+Outbound 和 Inbound 事件十分的镜像, 并且 Context 与 Handler 直接的调用关系是否容易混淆, 因此读者在阅读这里的源码时, 需要特别的注意。
+
+# 3. DefaultChannelPipeline
+
+`io.netty.channel.DefaultChannelPipeline` ，实现 ChannelPipeline 接口，默认 ChannelPipeline 实现类。😈 实际上，也只有这个实现类。
+
+## 3.1 静态属性
+
+```
+/**
+ * {@link #head} 的名字
+ */
+private static final String HEAD_NAME = generateName0(HeadContext.class);
+/**
+ * {@link #tail} 的名字
+ */
+private static final String TAIL_NAME = generateName0(TailContext.class);
+
+/**
+ * 名字({@link AbstractChannelHandlerContext#name})缓存 ，基于 ThreadLocal ，用于生成在线程中唯一的名字。
+ */
+private static final FastThreadLocal<Map<Class<?>, String>> nameCaches = new FastThreadLocal<Map<Class<?>, String>>() {
+
+    @Override
+    protected Map<Class<?>, String> initialValue() throws Exception {
+        return new WeakHashMap<Class<?>, String>();
+    }
+
+};
+
+/**
+ * {@link #estimatorHandle} 的原子更新器
+ */
+private static final AtomicReferenceFieldUpdater<DefaultChannelPipeline, MessageSizeEstimator.Handle> ESTIMATOR =
+        AtomicReferenceFieldUpdater.newUpdater(
+                DefaultChannelPipeline.class, MessageSizeEstimator.Handle.class, "estimatorHandle");
+```
+
+- `HEAD_NAME` 和 `TAIL_NAME` 静态属性，通过调用 `#generateName0(Class<?> handlerType)` 方法，生成对应的名字。代码如下：
+
+  ```
+  private static String generateName0(Class<?> handlerType) {
+      return StringUtil.simpleClassName(handlerType) + "#0";
+  }
+  ```
+
+  - 即 `HEAD_NAME = "HeadContext#0"`，`TAIL_NAME= "TailContext#0"` 。
+
+- `nameCaches` 静态属性，名字( `AbstractChannelHandlerContext.name` )缓存 ，基于 ThreadLocal ，用于生成**在线程中唯一的名字**。详细解析，见 [《精尽 Netty 源码解析 —— Pipeline（二）之添加 ChannelHandler》](http://svip.iocoder.cn/Netty/Pipeline-2-add-channel-handler) 。
+
+- `ESTIMATOR` 静态属性，`estimatorHandle` 属性的**原子**更新器。
+
+## 3.2 构造方法
+
+```
+/**
+ * Head 节点
+ */
+final AbstractChannelHandlerContext head;
+/**
+ * Tail 节点
+ */
+final AbstractChannelHandlerContext tail;
+
+/**
+ * 所属 Channel 对象
+ */
+private final Channel channel;
+/**
+ * 成功的 Promise 对象
+ */
+private final ChannelFuture succeededFuture;
+/**
+ * 不进行通知的 Promise 对象
+ *
+ * 用于一些方法执行，需要传入 Promise 类型的方法参数，但是不需要进行通知，就传入该值
+ *
+ * @see io.netty.channel.AbstractChannel.AbstractUnsafe#safeSetSuccess(ChannelPromise) 
+ */
+private final VoidChannelPromise voidPromise;
+/**
+ * TODO 1008 DefaultChannelPipeline 字段用途
+ */
+private final boolean touch = ResourceLeakDetector.isEnabled();
+
+/**
+ * 子执行器集合。
+ *
+ * 默认情况下，ChannelHandler 使用 Channel 所在的 EventLoop 作为执行器。
+ * 但是如果有需要，也可以自定义执行器。详细解析，见 {@link #childExecutor(EventExecutorGroup)} 。
+ * 实际情况下，基本不会用到。和基友【闪电侠】沟通过。
+ */
+private Map<EventExecutorGroup, EventExecutor> childExecutors;
+/**
+ * TODO 1008 DefaultChannelPipeline 字段用途
+ */
+private volatile MessageSizeEstimator.Handle estimatorHandle;
+/**
+ * 是否首次注册
+ */
+private boolean firstRegistration = true;
+
+/**
+ * This is the head of a linked list that is processed by {@link #callHandlerAddedForAllHandlers()} and so process
+ * all the pending {@link #callHandlerAdded0(AbstractChannelHandlerContext)}.
+ *
+ * We only keep the head because it is expected that the list is used infrequently and its size is small.
+ * Thus full iterations to do insertions is assumed to be a good compromised to saving memory and tail management
+ * complexity.
+ * 
+ * 准备添加 ChannelHandler 的回调
+ */
+private PendingHandlerCallback pendingHandlerCallbackHead;
+
+/**
+ * Set to {@code true} once the {@link AbstractChannel} is registered.Once set to {@code true} the value will never
+ * change.
+ * Channel 是否已注册
+ */
+private boolean registered;
+
+protected DefaultChannelPipeline(Channel channel) {
+    this.channel = ObjectUtil.checkNotNull(channel, "channel");
+    // succeededFuture 的创建
+    succeededFuture = new SucceededChannelFuture(channel, null);
+    // voidPromise 的创建
+    voidPromise =  new VoidChannelPromise(channel, true);
+
+    // 创建 Tail 及诶点
+    tail = new TailContext(this); // <1>
+    // 创建 Head 节点
+    head = new HeadContext(this); // <2>
+
+    // 相互指向 <3>
+    head.next = tail;
+    tail.prev = head;
+}
+```
+
+- `head` 属性，Head 节点，在构造方法的 `<1>` 处初始化。详细解析，见 [「4.2 HeadContext」](https://svip.iocoder.cn/Netty/ChannelPipeline-1-init/#) 。
+
+- `tail` 节点，Tail 节点，在构造方法的 `<2>` 处初始化。详细解析，见 [「4.3 TailContext」](https://svip.iocoder.cn/Netty/ChannelPipeline-1-init/#) 。
+
+- 在构造方法的 `<3>` 处，`head` 节点向**下**指向 `tail` 节点，`tail` 节点向**上**指向 `head` 节点，从而形成**相互**的指向。即如下图所示：
+
+  > FROM [《netty 源码分析之 pipeline(一)》](https://www.jianshu.com/p/6efa9c5fa702)
+  >
+  > [![pipeline 节点链(默认)](21-Netty 源码解析-ChannelPipeline（一）之初始化.assets/02.png)](http://static.iocoder.cn/images/Netty/2018_06_01/02.png)pipeline 节点链(默认)
+
+  - pipeline 中的节点的数据结构是 ChannelHandlerContext 类。每个 ChannelHandlerContext 包含**一个** ChannelHandler、它的**上下**节点( **从而形成 ChannelHandler 链** )、以及其他上下文。详细解析，见 [「4. ChannelHandlerContext」](https://svip.iocoder.cn/Netty/ChannelPipeline-1-init/#) 。
+
+  - 默认情况下，pipeline 有 `head` 和 `tail` 节点，形成默认的 ChannelHandler 链。而我们可以在它们之间，加入自定义的 ChannelHandler 节点。如下图所示：
+
+    > FROM [《netty 源码分析之 pipeline(一)》](https://www.jianshu.com/p/6efa9c5fa702)
+    >
+    > [![pipeline 节点链(自定义)](21-Netty 源码解析-ChannelPipeline（一）之初始化.assets/03.png)](http://static.iocoder.cn/images/Netty/2018_06_01/03.png)pipeline 节点链(自定义)
+
+- `childExecutors` 属性，子执行器集合。默认情况下，ChannelHandler 使用 Channel 所在的 EventLoop 作为执行器。
+
+  - 但是如果有需要，也可以自定义执行器。详细解析，见 [《精尽 Netty 源码解析 —— Pipeline（二）之添加 ChannelHandler》](http://svip.iocoder.cn/Netty/Pipeline-2-add-channel-handler) 。
+  - 实际情况下，基本不会用到。和基友【闪电侠】沟通过。
+
+- `pendingHandlerCallbackHead` 属性，准备添加 ChannelHandler 的回调。详细解析，见 [《精尽 Netty 源码解析 —— Pipeline（二）之添加 ChannelHandler》](http://svip.iocoder.cn/Netty/Pipeline-2-add-channel-handler) 。
+
+- `registered` 属性，Channel 是否已注册。详细解析，见 [《精尽 Netty 源码解析 —— Pipeline（二）之添加 ChannelHandler》](http://svip.iocoder.cn/Netty/Pipeline-2-add-channel-handler) 。
+
+- `firstRegistration` 属性，是否首次注册。详细解析，见 [《精尽 Netty 源码解析 —— Pipeline（二）之添加 ChannelHandler》](http://svip.iocoder.cn/Netty/Pipeline-2-add-channel-handler) 。
+
+## 3.3 其他方法
+
+DefaultChannelPipeline 中的其他方法，详细解析，见后续的文章。
+
+# 4. ChannelHandlerContext
+
+`io.netty.channel.ChannelHandlerContext` ，继承 ChannelInboundInvoker、ChannelOutboundInvoker、AttributeMap 接口，ChannelHandler Context( 上下文 )接口，作为 ChannelPipeline 中的**节点**。代码如下：
+
+```
+// ========== Context 相关 ==========
+String name();
+Channel channel();
+EventExecutor executor();
+ChannelHandler handler();
+ChannelPipeline pipeline();
+boolean isRemoved(); // 是否已经移除
+
+// ========== ByteBuf 相关 ==========    
+ByteBufAllocator alloc();
+
+// ========== ChannelInboundInvoker 相关 ==========    
+@Override
+ChannelHandlerContext fireChannelRegistered();
+@Override
+ChannelHandlerContext fireChannelUnregistered();
+@Override
+ChannelHandlerContext fireChannelActive();
+@Override
+ChannelHandlerContext fireChannelInactive();
+@Override
+ChannelHandlerContext fireExceptionCaught(Throwable cause);
+@Override
+ChannelHandlerContext fireUserEventTriggered(Object evt);
+@Override
+ChannelHandlerContext fireChannelRead(Object msg);
+@Override
+ChannelHandlerContext fireChannelReadComplete();
+@Override
+ChannelHandlerContext fireChannelWritabilityChanged();
+
+// ========== ChannelOutboundInvoker 相关 ==========
+@Override
+ChannelHandlerContext read();
+@Override
+ChannelHandlerContext flush();
+
+// ========== AttributeMap 相关 ==========
+@Deprecated
+@Override
+<T> Attribute<T> attr(AttributeKey<T> key);
+@Deprecated
+@Override
+<T> boolean hasAttr(AttributeKey<T> key);
+```
+
+虽然接口的方法比较多，笔者做了归类如下：
+
+- Context 相关的接口方法。
+- 继承自 ChannelInboundInvoker 的相关方法，*和 ChannelPipeline 一样*。
+- 继承自 ChannelOutboundInvoker 的相关方法，*和 ChannelPipeline 一样*。
+- 继承自 AttributeMap 的相关方法，实际上已经废弃( `@Deprecated` )了，不再从 ChannelHandlerContext 中获取，而是从 Channel 中获取。
+
+ChannelHandlerContext 的类图如下：
+
+[![ChannelHandlerContext 类图](21-Netty 源码解析-ChannelPipeline（一）之初始化.assets/04.png)](http://static.iocoder.cn/images/Netty/2018_06_01/04.png)ChannelHandlerContext 类图
+
+- 😈 类图中的 AttributeMap 和 DefaultAttributeMap 可以无视。
+
+## 4.1 AbstractChannelHandlerContext
+
+`io.netty.channel.AbstractChannelHandlerContext` ，实现 ChannelHandlerContext、ResourceLeakHint 接口，继承 DefaultAttributeMap 类，ChannelHandlerContext 抽象基类。
+
+### 4.1.1 静态属性
+
+```
+/**
+ * Neither {@link ChannelHandler#handlerAdded(ChannelHandlerContext)}
+ * nor {@link ChannelHandler#handlerRemoved(ChannelHandlerContext)} was called.
+ */
+private static final int INIT = 0; // 初始化
+/**
+ * {@link ChannelHandler#handlerAdded(ChannelHandlerContext)} is about to be called.
+ */
+private static final int ADD_PENDING = 1; // 添加准备中
+/**
+ * {@link ChannelHandler#handlerAdded(ChannelHandlerContext)} was called.
+ */
+private static final int ADD_COMPLETE = 2; // 已添加
+/**
+ * {@link ChannelHandler#handlerRemoved(ChannelHandlerContext)} was called.
+ */
+private static final int REMOVE_COMPLETE = 3; // 已移除
+
+/**
+ * {@link #handlerState} 的原子更新器
+ */
+private static final AtomicIntegerFieldUpdater<AbstractChannelHandlerContext> HANDLER_STATE_UPDATER = AtomicIntegerFieldUpdater.newUpdater(AbstractChannelHandlerContext.class, "handlerState");
+
+// ========== 非静态属性 ==========
+
+/**
+ * 处理器状态
+ */
+private volatile int handlerState = INIT;
+```
+
+- ```
+  handlerState
+  ```
+
+   
+
+  属性(
+
+   
+
+  非静态
+
+  属性，放这里主要是为了统一讲 )，处理器状态。共有
+
+   
+
+  4
+
+   
+
+  种状态。状态变迁如下图：
+
+  ![`handlerState` 变迁](21-Netty 源码解析-ChannelPipeline（一）之初始化.assets/05.png)
+
+  `handlerState` 变迁
+
+  - 详细解析，见 [「4.1.3 setAddComplete」](https://svip.iocoder.cn/Netty/ChannelPipeline-1-init/#)、[「4.1.4 setRemoved」](https://svip.iocoder.cn/Netty/ChannelPipeline-1-init/#)、[「4.1.5 setAddPending」](https://svip.iocoder.cn/Netty/ChannelPipeline-1-init/#) 中。
+
+- `HANDLER_STATE_UPDATER` **静态**属性，`handlerState` 的原子更新器。
+
+### 4.1.2 构造方法
+
+```
+/**
+ * 上一个节点
+ */
+volatile AbstractChannelHandlerContext next;
+/**
+ * 下一个节点
+ */
+volatile AbstractChannelHandlerContext prev;
+/**
+ * 是否为 inbound
+ */
+private final boolean inbound;
+/**
+ * 是否为 outbound
+ */
+private final boolean outbound;
+/**
+ * 所属 pipeline
+ */
+private final DefaultChannelPipeline pipeline;
+/**
+ * 名字
+ */
+private final String name;
+/**
+ * 是否使用有序的 EventExecutor ( {@link #executor} )，即 OrderedEventExecutor
+ */
+private final boolean ordered;
+
+// Will be set to null if no child executor should be used, otherwise it will be set to the
+// child executor.
+/**
+ * EventExecutor 对象
+ */
+final EventExecutor executor;
+/**
+ * 成功的 Promise 对象
+ */
+private ChannelFuture succeededFuture;
+
+// Lazily instantiated tasks used to trigger events to a handler with different executor. 懒加载
+// There is no need to make this volatile as at worse it will just create a few more instances then needed.
+/**
+ * 执行 Channel ReadComplete 事件的任务
+ */
+private Runnable invokeChannelReadCompleteTask;
+/**
+ * 执行 Channel Read 事件的任务
+ */
+private Runnable invokeReadTask;
+/**
+ * 执行 Channel WritableStateChanged 事件的任务
+ */
+private Runnable invokeChannelWritableStateChangedTask;
+/**
+ * 执行 flush 事件的任务
+ */
+private Runnable invokeFlushTask;
+/**
+ * 处理器状态
+ */
+private volatile int handlerState = INIT;
+
+AbstractChannelHandlerContext(DefaultChannelPipeline pipeline, EventExecutor executor, String name,
+                              boolean inbound, boolean outbound) {
+    this.name = ObjectUtil.checkNotNull(name, "name");
+    this.pipeline = pipeline;
+    this.executor = executor;
+    this.inbound = inbound;
+    this.outbound = outbound;
+    // Its ordered if its driven by the EventLoop or the given Executor is an instanceof OrderedEventExecutor.
+    ordered = executor == null || executor instanceof OrderedEventExecutor; // <1>
+}
+```
+
+- `next`、`prev` 属性，分别记录上、下一个节点。
+
+- Handler 相关属性：
+
+  - 在 AbstractChannelHandlerContext 抽象类中，按照我们上文的分享，应该会看到一个类型为 ChannelHandler 的处理器，但是**实际并不是这样**。而是，😈 我们下文 DefaultChannelHandlerContext、TailContext、HeadContext 见。
+  - `inbound`、`outbound` 属性，分别是否为 Inbound、Outbound 处理器。
+  - `name` 属性，处理器名字。
+  - `handlerState` 属性，处理器状态，初始为 `INIT` 。
+
+- ```
+  executor
+  ```
+
+   
+
+  属性，EventExecutor 对象
+
+  - `ordered` 属性，是否使用有序的 `executor`，即 OrderedEventExecutor ，在构造方法的 `<1>` 处理的初始化。
+
+- `pipeline` 属性，所属 DefaultChannelPipeline 对象。
+
+### 4.1.3 setAddComplete
+
+`#setAddComplete()` 方法，设置 ChannelHandler 添加完成。完成后，状态有两种结果：
+
+1. `REMOVE_COMPLETE`
+2. `ADD_COMPLETE`
+
+代码如下：
+
+```
+final void setAddComplete() {
+    for (;;) {
+        int oldState = handlerState;
+        // Ensure we never update when the handlerState is REMOVE_COMPLETE already.
+        // oldState is usually ADD_PENDING but can also be REMOVE_COMPLETE when an EventExecutor is used that is not
+        // exposing ordering guarantees.
+        if (oldState == REMOVE_COMPLETE || HANDLER_STATE_UPDATER.compareAndSet(this, oldState, ADD_COMPLETE)) {
+            return;
+        }
+    }
+}
+```
+
+- 循环 + CAS 保证多线程下的安全变更 `handlerState` 属性。
+
+### 4.1.4 setRemoved
+
+`#setRemoved()` 方法，设置 ChannelHandler 已移除。代码如下：
+
+```
+final void setRemoved() {
+    handlerState = REMOVE_COMPLETE;
+}
+```
+
+### 4.1.5 setAddPending
+
+`#setAddPending()` 方法，设置 ChannelHandler 准备添加中。代码如下：
+
+```
+final void setAddPending() {
+    boolean updated = HANDLER_STATE_UPDATER.compareAndSet(this, INIT, ADD_PENDING);
+    assert updated; // This should always be true as it MUST be called before setAddComplete() or setRemoved().
+}
+```
+
+- 当且仅当 `INIT` 可修改为 `ADD_PENDING` 。理论来说，这是一个绝对会成功的操作，原因见英文注释。
+
+### 4.1.6 其他方法
+
+AbstractChannelHandlerContext 中的其他方法，详细解析，见后续的文章。
+
+## 4.2 HeadContext
+
+HeadContext ，实现 ChannelOutboundHandler、ChannelInboundHandler 接口，继承 AbstractChannelHandlerContext 抽象类，**pipe 头节点** Context 实现类。
+
+> HeadContext 是 DefaultChannelPipeline 的内部类。
+
+### 4.2.1 构造方法
+
+```
+private final Unsafe unsafe;
+
+HeadContext(DefaultChannelPipeline pipeline) {
+    super(pipeline, null, HEAD_NAME, false, true); // <1>
+    unsafe = pipeline.channel().unsafe(); // <2>
+    setAddComplete(); // <3>
+}
+```
+
+- `<1>` 处，调用父 AbstractChannelHandlerContext 的构造方法，设置 `inbound = false`、`outbound = true` 。
+
+- `<2>` 处，使用 Channel 的 Unsafe 作为 `unsafe` 属性。HeadContext 实现 ChannelOutboundHandler 接口的方法，都会调用 Unsafe 对应的方法。代码如下：
+
+  ```
+  @Override
+  public void bind(ChannelHandlerContext ctx, SocketAddress localAddress, ChannelPromise promise) throws Exception {
+      unsafe.bind(localAddress, promise);
+  }
+  
+  @Override
+  public void connect(ChannelHandlerContext ctx, SocketAddress remoteAddress, SocketAddress localAddress, ChannelPromise promise) throws Exception {
+      unsafe.connect(remoteAddress, localAddress, promise);
+  }
+  
+  @Override
+  public void disconnect(ChannelHandlerContext ctx, ChannelPromise promise) throws Exception {
+      unsafe.disconnect(promise);
+  }
+  
+  @Override
+  public void close(ChannelHandlerContext ctx, ChannelPromise promise) throws Exception {
+      unsafe.close(promise);
+  }
+  
+  @Override
+  public void deregister(ChannelHandlerContext ctx, ChannelPromise promise) throws Exception {
+      unsafe.deregister(promise);
+  }
+  
+  @Override
+  public void read(ChannelHandlerContext ctx) {
+      unsafe.beginRead();
+  }
+  
+  @Override
+  public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) throws Exception {
+      unsafe.write(msg, promise);
+  }
+  
+  @Override
+  public void flush(ChannelHandlerContext ctx) throws Exception {
+      unsafe.flush();
+  }
+  ```
+
+  - 这也就是为什么设置 `outbound = true` 的原因。
+
+- `<3>` 处，调用 `#setAddComplete()` 方法，设置 ChannelHandler 添加完成。此时，`handlerStatus` 会变成 `ADD_COMPLETE` 状态。
+
+### 4.2.2 handler
+
+`#handler()` 方法，返回自己作为 Context 的 **ChannelHandler** 。代码如下：
+
+```
+@Override
+public ChannelHandler handler() {
+    return this;
+}
+```
+
+- 因为 HeadContext ，实现 ChannelOutboundHandler、ChannelInboundHandler 接口，而它们本身就是 ChannelHandler 。
+
+### 4.2.3 其他方法
+
+HeadContext 中的其他方法，详细解析，见后续的文章。
+
+## 4.3 TailContext
+
+TailContext ，实现 ChannelInboundHandler 接口，继承 AbstractChannelHandlerContext 抽象类，**pipe 尾节点** Context 实现类。
+
+> TailContext 是 DefaultChannelPipeline 的内部类。
+
+### 4.3.1 构造方法
+
+```
+TailContext(DefaultChannelPipeline pipeline) {
+    super(pipeline, null, TAIL_NAME, true, false); // <1>
+    setAddComplete(); // <2>
+}
+```
+
+- `<1>` 处，调用父 AbstractChannelHandlerContext 的构造方法，设置 `inbound = true`、`outbound = false` ，和 HeadContext **相反**。
+- `<2>` 处，调用 `#setAddComplete()` 方法，设置 ChannelHandler 添加完成。此时，`handlerStatus` 会变成 `ADD_COMPLETE` 状态。
+
+### 4.3.2 handler
+
+`#handler()` 方法，返回自己作为 Context 的 **ChannelHandler** 。代码如下：
+
+```
+@Override
+public ChannelHandler handler() {
+    return this;
+}
+```
+
+- 因为 HeadContext ，实现 ChannelInboundHandler 接口，而它们本身就是 ChannelHandler 。
+
+### 4.3.3 其他方法
+
+TailContext 中的其他方法，详细解析，见后续的文章。
+
+## 4.4 DefaultChannelHandlerContext
+
+`io.netty.channel.DefaultChannelHandlerContext` ，实现 AbstractChannelHandlerContext 抽象类。代码如下：
+
+```
+final class DefaultChannelHandlerContext extends AbstractChannelHandlerContext {
+
+    private final ChannelHandler handler;
+
+    DefaultChannelHandlerContext(
+            DefaultChannelPipeline pipeline, EventExecutor executor, String name, ChannelHandler handler) {
+        super(pipeline, executor, name, isInbound(handler), isOutbound(handler)); // <1>
+        if (handler == null) {
+            throw new NullPointerException("handler");
+        }
+        this.handler = handler; // <2>
+    }
+
+    @Override
+    public ChannelHandler handler() {
+        return handler;
+    }
+
+    private static boolean isInbound(ChannelHandler handler) {
+        return handler instanceof ChannelInboundHandler;
+    }
+
+    private static boolean isOutbound(ChannelHandler handler) {
+        return handler instanceof ChannelOutboundHandler;
+    }
+
+}
+```
+
+- 不同于 HeadContext、TailContext，它们自身就是一个 Context 的同时，也是一个 ChannelHandler 。而 DefaultChannelHandlerContext 是**内嵌** 一个 ChannelHandler 对象，即 `handler` 。这个属性通过构造方法传入，在 `<2>` 处进行赋值。
+- `<1>` 处，调用父 AbstractChannelHandlerContext 的构造方法，通过判断传入的 `handler` 是否为 ChannelInboundHandler 和 ChannelOutboundHandler 来分别判断是否为 `inbound` 和 `outbound` 。
+
+# 666. 彩蛋
+
+推荐阅读如下文章：
+
+- 闪电侠 [《netty 源码分析之 pipeline(一)》](https://www.jianshu.com/p/6efa9c5fa702)
+- 永顺 [《Netty 源码分析之 二 贯穿Netty 的大动脉 ── ChannelPipeline (一)》](https://segmentfault.com/a/1190000007308934)
+- 占小狼 [《Netty 源码分析之 ChannelPipeline》](https://www.jianshu.com/p/3876874306d5)
\ No newline at end of file
diff --git a/netty/22-Netty 源码解析-ChannelPipeline（二）之添加 ChannelHandler.assets/01.png b/netty/22-Netty 源码解析-ChannelPipeline（二）之添加 ChannelHandler.assets/01.png
new file mode 100644
index 0000000..b8e53ec
Binary files /dev/null and b/netty/22-Netty 源码解析-ChannelPipeline（二）之添加 ChannelHandler.assets/01.png differ
diff --git a/netty/22-Netty 源码解析-ChannelPipeline（二）之添加 ChannelHandler.assets/02.png b/netty/22-Netty 源码解析-ChannelPipeline（二）之添加 ChannelHandler.assets/02.png
new file mode 100644
index 0000000..cd16e57
Binary files /dev/null and b/netty/22-Netty 源码解析-ChannelPipeline（二）之添加 ChannelHandler.assets/02.png differ
diff --git a/netty/22-Netty 源码解析-ChannelPipeline（二）之添加 ChannelHandler.assets/03.png b/netty/22-Netty 源码解析-ChannelPipeline（二）之添加 ChannelHandler.assets/03.png
new file mode 100644
index 0000000..4441c51
Binary files /dev/null and b/netty/22-Netty 源码解析-ChannelPipeline（二）之添加 ChannelHandler.assets/03.png differ
diff --git a/netty/22-Netty 源码解析-ChannelPipeline（二）之添加 ChannelHandler.assets/04.png b/netty/22-Netty 源码解析-ChannelPipeline（二）之添加 ChannelHandler.assets/04.png
new file mode 100644
index 0000000..2723b5e
Binary files /dev/null and b/netty/22-Netty 源码解析-ChannelPipeline（二）之添加 ChannelHandler.assets/04.png differ
diff --git a/netty/22-Netty 源码解析-ChannelPipeline（二）之添加 ChannelHandler.md b/netty/22-Netty 源码解析-ChannelPipeline（二）之添加 ChannelHandler.md
new file mode 100644
index 0000000..7fd4b81
--- /dev/null
+++ b/netty/22-Netty 源码解析-ChannelPipeline（二）之添加 ChannelHandler.md	
@@ -0,0 +1,682 @@
+# 精尽 Netty 源码解析 —— ChannelPipeline（二）之添加 ChannelHandler
+
+# 1. 概述
+
+本文我们来分享，**添加** ChannelHandler 到 pipeline 中的代码具体实现。
+
+在 [《精尽 Netty 源码解析 —— ChannelPipeline（一）之初始化》](http://svip.iocoder.cn/Netty/ChannelPipeline-1-init) 中，我们看到 ChannelPipeline 定义了一大堆**添加** ChannelHandler 的接口方法：
+
+```
+ChannelPipeline addFirst(String name, ChannelHandler handler);
+ChannelPipeline addFirst(EventExecutorGroup group, String name, ChannelHandler handler);
+ChannelPipeline addLast(String name, ChannelHandler handler);
+ChannelPipeline addLast(EventExecutorGroup group, String name, ChannelHandler handler);
+ChannelPipeline addBefore(String baseName, String name, ChannelHandler handler);
+ChannelPipeline addBefore(EventExecutorGroup group, String baseName, String name, ChannelHandler handler);
+ChannelPipeline addAfter(String baseName, String name, ChannelHandler handler);
+ChannelPipeline addAfter(EventExecutorGroup group, String baseName, String name, ChannelHandler handler);
+ChannelPipeline addFirst(ChannelHandler... handlers);
+ChannelPipeline addFirst(EventExecutorGroup group, ChannelHandler... handlers);
+ChannelPipeline addLast(ChannelHandler... handlers);
+ChannelPipeline addLast(EventExecutorGroup group, ChannelHandler... handlers);
+```
+
+- 考虑到实际当中，我们使用 `#addLast(ChannelHandler... handlers)` 方法较多，所以本文只分享这个方法的具体实现。
+
+# 2. addLast
+
+`#addLast(ChannelHandler... handlers)` 方法，添加任意数量的 ChannelHandler 对象。代码如下：
+
+```
+@Override
+public final ChannelPipeline addLast(ChannelHandler... handlers) {
+    return addLast(null, handlers);
+}
+
+@Override
+public final ChannelPipeline addLast(EventExecutorGroup executor, ChannelHandler... handlers) {
+    if (handlers == null) {
+        throw new NullPointerException("handlers");
+    }
+
+    for (ChannelHandler h: handlers) {
+        if (h == null) {
+            break;
+        }
+        addLast(executor, null, h); // <1>
+    }
+
+    return this;
+}
+```
+
+- `<1>` 处，调用 `#addLast(EventExecutorGroup group, String name, ChannelHandler handler)` 方法，添加一个 ChannelHandler 对象到 pipeline 中。
+
+`#addLast(EventExecutorGroup group, String name, ChannelHandler handler)` 方法，代码如下：
+
+```
+ 1: @Override
+ 2: @SuppressWarnings("Duplicates")
+ 3: public final ChannelPipeline addLast(EventExecutorGroup group, String name, ChannelHandler handler) {
+ 4:     final AbstractChannelHandlerContext newCtx;
+ 5:     synchronized (this) { // 同步，为了防止多线程并发操作 pipeline 底层的双向链表
+ 6:         // 检查是否有重复 handler
+ 7:         checkMultiplicity(handler);
+ 8: 
+ 9:         // 创建节点名
+10:         // 创建节点
+11:         newCtx = newContext(group, filterName(name, handler), handler);
+12: 
+13:         // 添加节点
+14:         addLast0(newCtx);
+15: 
+16:         // <1> pipeline 暂未注册，添加回调。再注册完成后，执行回调。详细解析，见 {@link #invokeHandlerAddedIfNeeded} 方法。
+17:         // If the registered is false it means that the channel was not registered on an eventloop yet.
+18:         // In this case we add the context to the pipeline and add a task that will call
+19:         // ChannelHandler.handlerAdded(...) once the channel is registered.
+20:         if (!registered) {
+21:             // 设置 AbstractChannelHandlerContext 准备添加中
+22:             newCtx.setAddPending();
+23:             // 添加 PendingHandlerCallback 回调
+24:             callHandlerCallbackLater(newCtx, true);
+25:             return this;
+26:         }
+27: 
+28:         // <2> 不在 EventLoop 的线程中，提交 EventLoop 中，执行回调用户方法
+29:         EventExecutor executor = newCtx.executor();
+30:         if (!executor.inEventLoop()) {
+31:             // 设置 AbstractChannelHandlerContext 准备添加中
+32:             newCtx.setAddPending();
+33:             // 提交 EventLoop 中，执行回调 ChannelHandler added 事件
+34:             executor.execute(new Runnable() {
+35:                 @Override
+36:                 public void run() {
+37:                     callHandlerAdded0(newCtx);
+38:                 }
+39:             });
+40:             return this;
+41:         }
+42:     }
+43: 
+44:     // <3> 回调 ChannelHandler added 事件
+45:     callHandlerAdded0(newCtx);
+46:     return this;
+47: }
+```
+
+- 第 5 行：`synchronized` 同步，为了防止多线程并发操作 pipeline 底层的双向链表。
+- 第 7 行：调用 `#checkMultiplicity(ChannelHandler)` 方法，校验是否重复的 ChannelHandler 。详细解析，见 [「3. checkMultiplicity」](https://svip.iocoder.cn/Netty/Pipeline-2-add-channel-handler/#) 。
+- 第 11 行：调用 `#filterName(String name, ChannelHandler handler)` 方法，获得 ChannelHandler 的名字。详细解析，见 [「4. filterName」](https://svip.iocoder.cn/Netty/Pipeline-2-add-channel-handler/#) 。
+- 第 11 行：调用 `#newContext(EventExecutorGroup group, String name, ChannelHandler handler)` 方法，创建 **DefaultChannelHandlerContext** 节点。详细解析，见 [「5. newContext」](https://svip.iocoder.cn/Netty/Pipeline-2-add-channel-handler/#) 。
+- 第 14 行：`#addLast0(AbstractChannelHandlerContext newCtx)` 方法，添加到最后一个节点。详细解析，见 [「6. addLast0」](https://svip.iocoder.cn/Netty/Pipeline-2-add-channel-handler/#) 。
+- ========== 后续分成 3 种情况 ==========
+- `<1>`
+- 第 20 行：Channel 并未注册。这种情况，发生于 ServerBootstrap 启动的过程中。在 `ServerBootstrap#init(Channel channel)` 方法中，会添加 ChannelInitializer 对象到 pipeline 中，恰好此时 Channel 并未注册。
+- 第 22 行：调用 `AbstractChannelHandlerContext#setAddPending()` 方法，设置 AbstractChannelHandlerContext **准备添加中**。
+- 第 24 行：调用 `#callHandlerCallbackLater(AbstractChannelHandlerContext, added)` 方法，添加 PendingHandlerAddedTask 回调。在 Channel 注册完成后，执行该回调。详细解析，见 [「8. PendingHandlerCallback」](https://svip.iocoder.cn/Netty/Pipeline-2-add-channel-handler/#) 。
+- `<2>`
+- 第 30 行：不在 EventLoop 的线程中。
+- 第 32 行：调用 `AbstractChannelHandlerContext#setAddPending()` 方法，设置 AbstractChannelHandlerContext **准备添加中**。
+- 第 34 至 39 行：提交 EventLoop 中，调用 `#callHandlerAdded0(AbstractChannelHandlerContext)` 方法，执行回调 ChannelHandler 添加完成( added )事件。详细解析，见 [「7. callHandlerAdded0」](https://svip.iocoder.cn/Netty/Pipeline-2-add-channel-handler/#) 。
+- `<3>`
+- 这种情况，是 `<2>` 在 EventLoop 的线程中的版本。也因为此，已经确认在 EventLoop 的线程中，所以不需要在 `synchronized` 中。
+- 第 45 行：和【第 37 行】的代码一样，调用 `#callHandlerAdded0(AbstractChannelHandlerContext)` 方法，执行回调 ChannelHandler 添加完成( added )事件。
+
+# 3. checkMultiplicity
+
+`#checkMultiplicity(ChannelHandler handler)` 方法，校验是否重复的 ChannelHandler 。代码如下：
+
+```
+private static void checkMultiplicity(ChannelHandler handler) {
+    if (handler instanceof ChannelHandlerAdapter) {
+        ChannelHandlerAdapter h = (ChannelHandlerAdapter) handler;
+        // 若已经添加，并且未使用 @Sharable 注解，则抛出异常
+        if (!h.isSharable() && h.added) {
+            throw new ChannelPipelineException(
+                    h.getClass().getName() +
+                    " is not a @Sharable handler, so can't be added or removed multiple times.");
+        }
+        // 标记已经添加
+        h.added = true;
+    }
+}
+```
+
+- 在 pipeline 中，一个创建的 ChannelHandler 对象，如果不使用 Netty `@Sharable` 注解，则只能添加到一个 Channel 的 pipeline 中。所以，如果我们想要重用一个 ChannelHandler 对象( 例如在 Spring 环境中 )，则必须给这个 ChannelHandler 添加 `@Sharable` 注解。
+
+例如，在 Dubbo 的 `com.alibaba.dubbo.remoting.transport.netty.NettyHandler` 处理器，它就使用了 `@Sharable` 注解。
+
+# 4. filterName
+
+`#filterName(String name, ChannelHandler handler)` 方法，获得 ChannelHandler 的名字。代码如下：
+
+```
+private String filterName(String name, ChannelHandler handler) {
+    if (name == null) { // <1>
+        return generateName(handler);
+    }
+    checkDuplicateName(name); // <2>
+    return name;
+}
+```
+
+- `<1>` 处，若**未**传入默认的名字 `name` ，则调用 `#generateName(ChannelHandler)` 方法，根据 ChannelHandler 生成一个**唯一**的名字。详细解析，见 [「4.1 generateName」](https://svip.iocoder.cn/Netty/Pipeline-2-add-channel-handler/#) 。
+- `<2>` 处，若**已**传入默认的名字 `name` ，则调用 `#checkDuplicateName(String name)` 方法，校验名字唯一。详细解析，见 [「4.2 checkDuplicateName」](https://svip.iocoder.cn/Netty/Pipeline-2-add-channel-handler/#) 。
+
+## 4.1 generateName
+
+`#generateName(ChannelHandler)` 方法，根据 ChannelHandler 生成一个**唯一**名字。代码如下：
+
+```
+ 1: private String generateName(ChannelHandler handler) {
+ 2:     // 从缓存中查询，是否已经生成默认名字
+ 3:     Map<Class<?>, String> cache = nameCaches.get();
+ 4:     Class<?> handlerType = handler.getClass();
+ 5:     String name = cache.get(handlerType);
+ 6:     // 若未生成过，进行生成
+ 7:     if (name == null) {
+ 8:         name = generateName0(handlerType);
+ 9:         cache.put(handlerType, name);
+10:     }
+11: 
+12:     // 判断是否存在相同名字的节点
+13:     // It's not very likely for a user to put more than one handler of the same type, but make sure to avoid
+14:     // any name conflicts.  Note that we don't cache the names generated here.
+15:     if (context0(name) != null) {
+16:         // 若存在，则使用基础名字 + 编号，循环生成，直到一个是唯一的
+17:         String baseName = name.substring(0, name.length() - 1); // Strip the trailing '0'.
+18:         for (int i = 1;; i ++) {
+19:             String newName = baseName + i;
+20:             if (context0(newName) == null) { // // 判断是否存在相同名字的节点
+21:                 name = newName;
+22:                 break;
+23:             }
+24:         }
+25:     }
+26:     return name;
+27: }
+```
+
+- 第 2 至 5 行：从缓存
+
+   
+
+  ```
+  nameCaches
+  ```
+
+   
+
+  中，查询是否已经生成
+
+  默认
+
+  名字。
+
+  - 若未生成过，调用 `#generateName0(ChannelHandler)` 方法，进行生成。而后，添加到缓存 `nameCaches` 中。
+
+- 第 15 行：调用 `#context0(String name)` 方法，判断是否存在相同名字的节点。代码如下：
+
+  ```
+  private AbstractChannelHandlerContext context0(String name) {
+      AbstractChannelHandlerContext context = head.next;
+      // 顺序向下遍历节点，判断是否有指定名字的节点。如果有，则返回该节点。
+      while (context != tail) {
+          if (context.name().equals(name)) {
+              return context;
+          }
+          context = context.next;
+      }
+      return null;
+  }
+  ```
+
+  - 顺序向下遍历节点，判断是否有指定名字的节点。如果有，则返回该节点。
+
+- 第 15 至 25 行：若存在相同名字的节点，则使用**基础**名字 + 编号，循环生成，直到一个名字是**唯一**的，然后结束循环。
+
+## 4.2 checkDuplicateName
+
+`#checkDuplicateName(String name)` 方法，校验名字唯一。代码如下：
+
+```
+private void checkDuplicateName(String name) {
+    if (context0(name) != null) {
+        throw new IllegalArgumentException("Duplicate handler name: " + name);
+    }
+}
+```
+
+- 通过调用 `#context0(String name)` 方法，获得指定名字的节点。若存在节点，意味着**不唯一**，抛出 IllegalArgumentException 异常。
+
+# 5. newContext
+
+`#newContext(EventExecutorGroup group, String name, ChannelHandler handler)` 方法，创建 **DefaultChannelHandlerContext** 节点。而这个节点，**内嵌**传入的 ChannelHandler 参数。代码如下：
+
+```
+private AbstractChannelHandlerContext newContext(EventExecutorGroup group, String name, ChannelHandler handler) {
+    return new DefaultChannelHandlerContext(this, childExecutor(group) /** <1> **/, name, handler);
+}
+```
+
+- `<1>` 处，调用 `#childExecutor(EventExecutorGroup group)` 方法，创建**子**执行器。代码如下：
+
+  ```
+  private EventExecutor childExecutor(EventExecutorGroup group) {
+      // <1> 不创建子执行器
+      if (group == null) {
+          return null;
+      }
+      // <2> 根据配置项 SINGLE_EVENTEXECUTOR_PER_GROUP ，每个 Channel 从 EventExecutorGroup 获得不同 EventExecutor 执行器
+      Boolean pinEventExecutor = channel.config().getOption(ChannelOption.SINGLE_EVENTEXECUTOR_PER_GROUP);
+      if (pinEventExecutor != null && !pinEventExecutor) {
+          return group.next();
+      }
+      // <3> 通过 childExecutors 缓存实现，一个 Channel 从 EventExecutorGroup 获得相同 EventExecutor 执行器
+      Map<EventExecutorGroup, EventExecutor> childExecutors = this.childExecutors;
+      if (childExecutors == null) {
+          // Use size of 4 as most people only use one extra EventExecutor.
+          childExecutors = this.childExecutors = new IdentityHashMap<EventExecutorGroup, EventExecutor>(4);
+      }
+      // Pin one of the child executors once and remember it so that the same child executor
+      // is used to fire events for the same channel.
+      EventExecutor childExecutor = childExecutors.get(group);
+      // 缓存不存在，进行 从 EventExecutorGroup 获得 EventExecutor 执行器
+      if (childExecutor == null) {
+          childExecutor = group.next();
+          childExecutors.put(group, childExecutor); // 进行缓存
+      }
+      return childExecutor;
+  }
+  ```
+
+  - 一共有三种情况：
+    - `<1>` ，当**不传入** EventExecutorGroup 时，不创建**子**执行器。即，使用 Channel 所注册的 EventLoop 作为执行器。**对于我们日常使用，基本完全都是这种情况**。所以，下面两种情况，胖友不理解也是没关系的。
+    - `<2>` ，根据配置项 `ChannelOption.SINGLE_EVENTEXECUTOR_PER_GROUP` ，每个 Channel 从 EventExecutorGroup 获得**不同** EventExecutor 执行器。
+    - `<3>` ，通过 `childExecutors` 缓存实现，每个 Channel 从 EventExecutorGroup 获得**相同** EventExecutor 执行器。是否获得相同的 EventExecutor 执行器，这就是 `<2>`、`<3>` 的不同。
+
+- **注意**，创建的是 DefaultChannelHandlerContext 对象。
+
+# 6. addLast0
+
+`#addLast0(AbstractChannelHandlerContext newCtx)` 方法，添加到最后一个节点。**注意**，实际上，是添加到 `tail` 节点**之前**。代码如下：
+
+```
+private void addLast0(AbstractChannelHandlerContext newCtx) {
+    // 获得 tail 节点的前一个节点
+    AbstractChannelHandlerContext prev = tail.prev;
+    // 新节点，指向 prev 和 tail 节点
+    newCtx.prev = prev; // <1>
+    newCtx.next = tail; // <2>
+    // 在 prev 和 tail ，指向新节点
+    prev.next = newCtx; // <3>
+    tail.prev = newCtx; // <4>
+}
+```
+
+> FROM 闪电侠 [《Netty 源码分析之pipeline(一)》](https://www.jianshu.com/p/6efa9c5fa702)
+>
+> - 用下面这幅图可见简单的表示这段过程，说白了，其实就是一个双向链表的插入操作：
+>
+>   [![添加节点过程](22-Netty 源码解析-ChannelPipeline（二）之添加 ChannelHandler.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_06_04/01.png)添加节点过程
+>
+> - 操作完毕，该节点就加入到 pipeline 中：
+>
+>   [![添加节点之后](22-Netty 源码解析-ChannelPipeline（二）之添加 ChannelHandler.assets/02.png)](http://static.iocoder.cn/images/Netty/2018_06_04/02.png)添加节点之后
+
+# 7. callHandlerAdded0
+
+`#callHandlerAdded0(AbstractChannelHandlerContext)` 方法，执行回调 ChannelHandler 添加完成( added )事件。代码如下：
+
+```
+ 1: private void callHandlerAdded0(final AbstractChannelHandlerContext ctx) {
+ 2:     try {
+ 3:         // We must call setAddComplete before calling handlerAdded. Otherwise if the handlerAdded method generates
+ 4:         // any pipeline events ctx.handler() will miss them because the state will not allow it.
+ 5:         // 设置 AbstractChannelHandlerContext 已添加
+ 6:         ctx.setAddComplete();
+ 7:         // 回调 ChannelHandler 添加完成( added )事件
+ 8:         ctx.handler().handlerAdded(ctx);
+ 9:     } catch (Throwable t) {
+10:         // 发生异常，移除该节点
+11:         boolean removed = false;
+12:         try {
+13:             remove0(ctx); // 移除
+14:             try {
+15:                 ctx.handler().handlerRemoved(ctx); // 回调 ChannelHandler 移除完成( removed )事件
+16:             } finally {
+17:                 ctx.setRemoved(); // 标记节点已移除
+18:             }
+19:             removed = true; // 标记移除成功
+20:         } catch (Throwable t2) {
+21:             if (logger.isWarnEnabled()) {
+22:                 logger.warn("Failed to remove a handler: " + ctx.name(), t2);
+23:             }
+24:         }
+25: 
+26:         // 触发异常的传播
+27:         if (removed) {
+28:             fireExceptionCaught(new ChannelPipelineException(
+29:                     ctx.handler().getClass().getName() +
+30:                     ".handlerAdded() has thrown an exception; removed.", t));
+31:         } else {
+32:             fireExceptionCaught(new ChannelPipelineException(
+33:                     ctx.handler().getClass().getName() +
+34:                     ".handlerAdded() has thrown an exception; also failed to remove.", t));
+35:         }
+36:     }
+37: }
+```
+
+- 第 6 行：调用 `AbstractChannelHandlerContext#setAddComplete()` 方法，设置 AbstractChannelHandlerContext 已添加。
+
+- 第 8 行：调用 `ChannelHandler#handlerAdded(AbstractChannelHandlerContext)` 方法，回调 ChannelHandler 添加完成( added )事件。一般来说，通过这个方法，来初始化 ChannelHandler 。**注意**，因为这个方法的执行在 EventLoop 的线程中，所以要尽量避免执行时间过长。
+
+- 第 9 行：发生异常。
+
+  - 第 10 至 24 行：移除该节点( ChannelHandler )。详细解析，见
+
+     
+
+    《精尽 Netty 源码解析 —— ChannelPipeline（三）之移除 ChannelHandler》
+
+     
+
+    。
+
+    - 😈 所以，`ChannelHandler#handlerAdded(AbstractChannelHandlerContext)` 方法的执行**异常**时，将被移除。
+
+  - 第 26 至 35 行：触发异常的传播。详细解析，见 [《精尽 Netty 源码解析 —— ChannelPipeline（六）之异常事件的传播》](http://svip.iocoder.cn/Netty/ChannelPipeline-6-exception) 。
+
+# 8. PendingHandlerCallback
+
+PendingHandlerCallback ，实现 Runnable 接口，等待添加 ChannelHandler 回调抽象类。代码如下：
+
+> PendingHandlerCallback 是 DefaultChannelPipeline 的内部静态类。
+
+```
+private abstract static class PendingHandlerCallback implements Runnable {
+
+    /**
+     * AbstractChannelHandlerContext 节点
+     */
+    final AbstractChannelHandlerContext ctx;
+    /**
+     * 下一个回调 PendingHandlerCallback 对象
+     */
+    PendingHandlerCallback next;
+
+    PendingHandlerCallback(AbstractChannelHandlerContext ctx) {
+        this.ctx = ctx;
+    }
+
+    /**
+     * 执行方法
+     */
+    abstract void execute();
+
+}
+```
+
+- 通过 `ctx` 和 `next` 字段，形成**回调链**。
+- `#execute()` 抽象方法，通过实现它，执行回调逻辑。
+
+------
+
+**为什么会有 PendingHandlerCallback 呢**？
+
+因为 ChannelHandler 添加到 pipeline 中，会触发 ChannelHandler 的添加完成( added )事件，并且该事件需要在 Channel 所属的 EventLoop 中执行。
+
+但是 Channel 并未注册在 EventLoop 上时，需要暂时将“触发 ChannelHandler 的添加完成( added )事件”的逻辑，作为一个 PendingHandlerCallback 进行“缓存”。在 Channel 注册到 EventLoop 上时，进行回调执行。
+
+------
+
+PendingHandlerCallback 有两个实现类：
+
+- PendingHandlerAddedTask
+- PendingHandlerRemovedTask
+
+本文只分享 PendingHandlerAddedTask 的代码实现。
+
+## 8.1 PendingHandlerAddedTask
+
+PendingHandlerAddedTask 实现 PendingHandlerCallback 抽象类，用于回调添加 ChannelHandler 节点。代码如下：
+
+```
+private final class PendingHandlerAddedTask extends PendingHandlerCallback {
+
+    PendingHandlerAddedTask(AbstractChannelHandlerContext ctx) {
+        super(ctx);
+    }
+
+    @Override
+    public void run() {
+        callHandlerAdded0(ctx);
+    }
+
+    @Override
+    void execute() {
+        EventExecutor executor = ctx.executor();
+        // 在 EventLoop 的线程中，回调 ChannelHandler added 事件
+        if (executor.inEventLoop()) {
+            callHandlerAdded0(ctx);
+        } else {
+            // 提交 EventLoop 中，执行回调 ChannelHandler added 事件
+            try {
+                executor.execute(this); // <1>
+            } catch (RejectedExecutionException e) {
+                if (logger.isWarnEnabled()) {
+                    logger.warn(
+                            "Can't invoke handlerAdded() as the EventExecutor {} rejected it, removing handler {}.",
+                            executor, ctx.name(), e);
+                }
+                // 发生异常，进行移除
+                remove0(ctx);
+                // 标记 AbstractChannelHandlerContext 为已移除
+                ctx.setRemoved();
+            }
+        }
+    }
+    
+}
+```
+
+- 在 `#execute()` 实现方法中，我们可以看到，和 `#addLast(EventExecutorGroup group, String name, ChannelHandler handler)` 方法的【第 28 至 45 行】的代码比较类似，目的是，在 EventLoop 的线程中，执行 `#callHandlerAdded0(AbstractChannelHandlerContext)` 方法，回调 ChannelHandler 添加完成( added )事件。
+- `<1>` 处，为什么 PendingHandlerAddedTask 可以直接提交到 EventLoop 中呢？因为 PendingHandlerAddedTask 是个 Runnable ，这也就是为什么 PendingHandlerCallback 实现 Runnable 接口的原因。
+
+> 老艿艿：下面开始分享的方法，属于 DefaultChannelPipeline 类。
+
+## 8.2 callHandlerCallbackLater
+
+`#callHandlerCallbackLater(AbstractChannelHandlerContext ctx, boolean added)` 方法，添加 PendingHandlerCallback 回调。代码如下：
+
+```
+/**
+ * This is the head of a linked list that is processed by {@link #callHandlerAddedForAllHandlers()} and so process
+ * all the pending {@link #callHandlerAdded0(AbstractChannelHandlerContext)}.
+ *
+ * We only keep the head because it is expected that the list is used infrequently and its size is small.
+ * Thus full iterations to do insertions is assumed to be a good compromised to saving memory and tail management
+ * complexity.
+ *
+ * 准备添加 ChannelHandler 的回调
+ *
+ * @see #callHandlerCallbackLater(AbstractChannelHandlerContext, boolean)
+ */
+private PendingHandlerCallback pendingHandlerCallbackHead;
+    
+  1: private void callHandlerCallbackLater(AbstractChannelHandlerContext ctx, boolean added) {
+  2:     assert !registered;
+  3: 
+  4:     // 创建 PendingHandlerCallback 对象
+  5:     PendingHandlerCallback task = added ? new PendingHandlerAddedTask(ctx) : new PendingHandlerRemovedTask(ctx);
+  6:     PendingHandlerCallback pending = pendingHandlerCallbackHead;
+  7:     // 若原 pendingHandlerCallbackHead 不存在，则赋值给它
+  8:     if (pending == null) {
+  9:         pendingHandlerCallbackHead = task;
+ 10:     // 若原 pendingHandlerCallbackHead 已存在，则最后一个回调指向新创建的回调
+ 11:     } else {
+ 12:         // Find the tail of the linked-list.
+ 13:         while (pending.next != null) {
+ 14:             pending = pending.next;
+ 15:         }
+ 16:         pending.next = task;
+ 17:     }
+ 18: }
+```
+
+- `added` 方法参数，表示是否是添加 ChannelHandler 的回调。所以在【第 5 行】的代码，根据 `added` 是否为 `true` ，创建 PendingHandlerAddedTask 或 PendingHandlerRemovedTask 对象。在本文中，当然创建的是 PendingHandlerAddedTask 。
+- 第 7 至 17 行：将创建的 PendingHandlerCallback 对象，“添加”到 `pendingHandlerCallbackHead` 中。
+
+## 8.3 invokeHandlerAddedIfNeeded
+
+`#invokeHandlerAddedIfNeeded()` 方法，执行**在 PendingHandlerCallback 中**的 ChannelHandler 添加完成( added )事件。它被两个方法所调用：
+
+- `AbstractUnsafe#register0(ChannelPromise promise)` 方法
+
+  - 原因是：
+
+    ```
+    // Ensure we call handlerAdded(...) before we actually notify the promise. This is needed as the
+    // user may already fire events through the pipeline in the ChannelFutureListener.
+    ```
+
+    - 例如 ServerBootstrap 通过 ChannelInitializer 注册自定义的 ChannelHandler 到 pipeline 上的情况。
+
+  - 调用栈如下图：[![register0](22-Netty 源码解析-ChannelPipeline（二）之添加 ChannelHandler.assets/03.png)](http://static.iocoder.cn/images/Netty/2018_06_04/03.png)register0
+
+- ```
+  HeadContext#channelRegistered(ChannelHandlerContext ctx)
+  ```
+
+   
+
+  方法。
+
+  - 笔者调试下来，对于 Netty NIO Server 和 NIO Client 貌似没啥作用，因为已经在 `AbstractUnsafe#register0(ChannelPromise promise)` 中触发。胖友也可以自己调试下。
+  - 调用栈如下图：[![channelRegistered](22-Netty 源码解析-ChannelPipeline（二）之添加 ChannelHandler.assets/04.png)](http://static.iocoder.cn/images/Netty/2018_06_04/04.png)channelRegistered
+
+------
+
+`#invokeHandlerAddedIfNeeded()` 方法，代码如下：
+
+```
+/**
+ * 是否首次注册
+ *
+ * {@link #invokeHandlerAddedIfNeeded()}
+ */
+private boolean firstRegistration = true;
+
+final void invokeHandlerAddedIfNeeded() {
+    assert channel.eventLoop().inEventLoop(); // 必须在 EventLoop 的线程中
+    // 仅有首次注册有效 <1>
+    if (firstRegistration) {
+        // 标记非首次注册
+        firstRegistration = false;
+        
+        // 执行在 PendingHandlerCallback 中的 ChannelHandler 添加完成( added )事件 // <2>
+        // We are now registered to the EventLoop. It's time to call the callbacks for the ChannelHandlers,
+        // that were added before the registration was done.
+        callHandlerAddedForAllHandlers();
+    }
+}
+```
+
+- ```
+  <1>
+  ```
+
+   
+
+  处，仅有首次注册有效(
+
+   
+
+  ```
+  firstRegistration = true
+  ```
+
+   
+
+  ) 时。而后，标记
+
+   
+
+  ```
+  firstRegistration = false
+  ```
+
+   
+
+  。
+
+  - 这也就是笔者为什么说，`HeadContext#channelRegistered(ChannelHandlerContext ctx)` 方法对这个方法的调用，是没有效果的。
+
+- `<2>` 处，调用 `#callHandlerAddedForAllHandlers()` 方法，执行**在 PendingHandlerCallback 中**的 ChannelHandler 添加完成( added )事件。代码如下：
+
+  ```
+   1: private void callHandlerAddedForAllHandlers() {
+   2:     final PendingHandlerCallback pendingHandlerCallbackHead;
+   3:     // 获得 pendingHandlerCallbackHead
+   4:     synchronized (this) {
+   5:         assert !registered;
+   6: 
+   7:         // This Channel itself was registered.
+   8:         registered = true; // 标记已注册
+   9: 
+  10:         pendingHandlerCallbackHead = this.pendingHandlerCallbackHead;
+  11:         // Null out so it can be GC'ed.
+  12:         this.pendingHandlerCallbackHead = null; // 置空，help gc
+  13:     }
+  14: 
+  15:     // 顺序向下，执行 PendingHandlerCallback 的回调
+  16:     // This must happen outside of the synchronized(...) block as otherwise handlerAdded(...) may be called while
+  17:     // holding the lock and so produce a deadlock if handlerAdded(...) will try to add another handler from outside
+  18:     // the EventLoop.
+  19:     PendingHandlerCallback task = pendingHandlerCallbackHead;
+  20:     while (task != null) {
+  21:         task.execute();
+  22:         task = task.next;
+  23:     }
+  24: }
+  ```
+
+  - 第 3 至 13 行：获得
+
+     
+
+    ```
+    pendingHandlerCallbackHead
+    ```
+
+     
+
+    变量。
+
+    - 第 8 行：标记 `registered = true` ，表示已注册。
+    - 第 10 至 12 行：置空对象的 `pendingHandlerCallbackHead` 属性，help GC 。
+    - 使用 `synchronized` 的原因，和 `#addLast(EventExecutorGroup group, String name, ChannelHandler handler)` 的【第 16 至 26 行】的代码需要对 `pendingHandlerCallbackHead` 互斥，避免并发修改的问题。
+
+  - 第 15 至 23 行：顺序循环向下，调用
+
+     
+
+    ```
+    PendingHandlerCallback#execute()
+    ```
+
+     
+
+    方法，执行 PendingHandlerCallback 的回调，从而将 ChannelHandler 添加到 pipeline 中。
+
+    - 这里不适用 `synchronized` 的原因，看英文注释哈。
+
+# 666. 彩蛋
+
+**添加** ChannelHandler 到 pipeline 中的代码，大部分的比较简单。比较复杂的可能是，[「8. PendingHandlerCallback」](https://svip.iocoder.cn/Netty/Pipeline-2-add-channel-handler/#) 中，调用的过程涉及**回调**，所以理解上稍微可能困难。胖友可以多多调试进行解决噢。
+
+推荐阅读文章：
+
+- 闪电侠 [《Netty 源码分析之 pipeline(一)》](https://www.jianshu.com/p/6efa9c5fa702)
+- Hypercube [《自顶向下深入分析 Netty（七）–ChannelPipeline 源码实现》](https://www.jianshu.com/p/0e15165714fc)
\ No newline at end of file
diff --git a/netty/23-Netty 源码解析-ChannelPipeline（三）之移除 ChannelHandler.assets/01.png b/netty/23-Netty 源码解析-ChannelPipeline（三）之移除 ChannelHandler.assets/01.png
new file mode 100644
index 0000000..1104d8f
Binary files /dev/null and b/netty/23-Netty 源码解析-ChannelPipeline（三）之移除 ChannelHandler.assets/01.png differ
diff --git a/netty/23-Netty 源码解析-ChannelPipeline（三）之移除 ChannelHandler.assets/02.png b/netty/23-Netty 源码解析-ChannelPipeline（三）之移除 ChannelHandler.assets/02.png
new file mode 100644
index 0000000..9ba1c28
Binary files /dev/null and b/netty/23-Netty 源码解析-ChannelPipeline（三）之移除 ChannelHandler.assets/02.png differ
diff --git a/netty/23-Netty 源码解析-ChannelPipeline（三）之移除 ChannelHandler.md b/netty/23-Netty 源码解析-ChannelPipeline（三）之移除 ChannelHandler.md
new file mode 100644
index 0000000..ee124e9
--- /dev/null
+++ b/netty/23-Netty 源码解析-ChannelPipeline（三）之移除 ChannelHandler.md	
@@ -0,0 +1,225 @@
+# 精尽 Netty 源码解析 —— ChannelPipeline（三）之移除 ChannelHandler
+
+# 1. 概述
+
+本文我们来分享，从 pipeline 中**移除** ChannelHandler 的代码具体实现。
+
+在 [《精尽 Netty 源码解析 —— ChannelPipeline（一）之初始化》](http://svip.iocoder.cn/Netty/ChannelPipeline-1-init) 中，我们看到 ChannelPipeline 定义了一大堆**移除** ChannelHandler 的接口方法：
+
+```
+ChannelPipeline remove(ChannelHandler handler);
+ChannelHandler remove(String name);
+<T extends ChannelHandler> T remove(Class<T> handlerType);
+ChannelHandler removeFirst();
+ChannelHandler removeLast();
+```
+
+- 本文仅分享 `#remove(ChannelHandler handler)` 方法，从 pipeline **移除**指定的 ChannelHandler 对象。
+
+# 2. remove
+
+`#remove(ChannelHandler handler)` 方法，从 pipeline **移除**指定的 ChannelHandler 对象。代码如下：
+
+```
+@Override
+public final ChannelPipeline remove(ChannelHandler handler) {
+    remove(getContextOrDie(handler));
+    return this;
+}
+```
+
+- 调用 `#getContextOrDie(ChannelHandler handler)` 方法，获得对应的 AbstractChannelHandlerContext 节点。代码如下：
+
+  ```
+  private AbstractChannelHandlerContext getContextOrDie(ChannelHandler handler) {
+      AbstractChannelHandlerContext ctx = (AbstractChannelHandlerContext) context(handler);
+      if (ctx == null) { // die
+          throw new NoSuchElementException(handler.getClass().getName());
+      } else {
+          return ctx;
+      }
+  }
+  
+  @Override
+  public final ChannelHandlerContext context(ChannelHandler handler) {
+      if (handler == null) {
+          throw new NullPointerException("handler");
+      }
+      AbstractChannelHandlerContext ctx = head.next;
+      // 循环，获得指定 ChannelHandler 对象的节点
+      for (;;) {
+          if (ctx == null) {
+              return null;
+          }
+          if (ctx.handler() == handler) { // ChannelHandler 相等
+              return ctx;
+          }
+          ctx = ctx.next;
+      }
+  }
+  ```
+
+  - 方法使用 Die 的原因是，获得不到节点的情况下，抛出 NoSuchElementException 异常。
+
+- 调用 `#remove(AbstractChannelHandlerContext ctx)` 方法，移除指定 AbstractChannelHandlerContext 节点。
+
+------
+
+`#remove(AbstractChannelHandlerContext ctx)` 方法，移除指定 AbstractChannelHandlerContext 节点。代码如下：
+
+> 代码的整体结构，和 `#addLast(EventExecutorGroup group, String name, ChannelHandler handler)` 方法是**一致**的。
+
+```
+ 1: private AbstractChannelHandlerContext remove(final AbstractChannelHandlerContext ctx) {
+ 2:     assert ctx != head && ctx != tail;
+ 3: 
+ 4:     synchronized (this) { // 同步，为了防止多线程并发操作 pipeline 底层的双向链表
+ 5:         // 移除节点
+ 6:         remove0(ctx);
+ 7: 
+ 8:         // pipeline 暂未注册，添加回调。再注册完成后，执行回调。详细解析，见 {@link #callHandlerCallbackLater} 方法。
+ 9:         // If the registered is false it means that the channel was not registered on an eventloop yet.
+10:         // In this case we remove the context from the pipeline and add a task that will call
+11:         // ChannelHandler.handlerRemoved(...) once the channel is registered.
+12:         if (!registered) {
+13:             callHandlerCallbackLater(ctx, false);
+14:             return ctx;
+15:         }
+16: 
+17:         // 不在 EventLoop 的线程中，提交 EventLoop 中，执行回调用户方法
+18:         EventExecutor executor = ctx.executor();
+19:         if (!executor.inEventLoop()) {
+20:             // 提交 EventLoop 中，执行回调 ChannelHandler removed 事件
+21:             executor.execute(new Runnable() {
+22:                 @Override
+23:                 public void run() {
+24:                     callHandlerRemoved0(ctx);
+25:                 }
+26:             });
+27:             return ctx;
+28:         }
+29:     }
+30: 
+31:     // 回调 ChannelHandler removed 事件
+32:     callHandlerRemoved0(ctx);
+33:     return ctx;
+34: }
+```
+
+- 第 4 行：`synchronized` 同步，为了防止多线程并发操作 pipeline 底层的双向链表。
+- 第 6 行：调用 `#remove0(AbstractChannelHandlerContext ctx)` 方法，从 pipeline **移除**指定的 AbstractChannelHandlerContext 节点。详细解析，见 [「3. remove0」](https://svip.iocoder.cn/Netty/ChannelPipeline-3-remove-channel-handler/#) 。
+- ========== 后续分成 3 种情况 ==========
+- `<1>`
+- 第 12 行：Channel 并未注册。
+- 第 13 行：调用 `#callHandlerCallbackLater(AbstractChannelHandlerContext, added)` 方法，添加 PendingHandlerRemovedTask 回调。在 Channel 注册完成后，执行该回调。详细解析，见 [「8. PendingHandlerCallback」](https://svip.iocoder.cn/Netty/ChannelPipeline-3-remove-channel-handler/#) 。
+- `<2>`
+- 第 19 行：不在 EventLoop 的线程中。
+- 第 20 至 26 行：提交 EventLoop 中，调用 `#callHandlerRemoved0(AbstractChannelHandlerContext)` 方法，执行回调 ChannelHandler 移除完成( removed )事件。详细解析，见 [「4. callHandlerRemoved0」](https://svip.iocoder.cn/Netty/ChannelPipeline-3-remove-channel-handler/#) 。
+- `<3>`
+- 这种情况，是 `<2>` 在 EventLoop 的线程中的版本。也因为此，已经确认在 EventLoop 的线程中，所以不需要在 `synchronized` 中。
+- 第 32 行：和【第 24 行】的代码一样，调用 `#callHandlerRemoved0(AbstractChannelHandlerContext)` 方法，执行回调 ChannelHandler 移除完成( removed )事件。
+
+# 3. remove0
+
+`#remove0(AbstractChannelHandlerContext ctx)` 方法，从 pipeline **移除**指定的 AbstractChannelHandlerContext 节点。代码如下：
+
+```
+private static void remove0(AbstractChannelHandlerContext ctx) {
+    // 获得移除节点的前后节点
+    AbstractChannelHandlerContext prev = ctx.prev;
+    AbstractChannelHandlerContext next = ctx.next;
+    // 前后节点互相指向
+    prev.next = next;
+    next.prev = prev;
+}
+```
+
+> FROM 闪电侠 [《netty 源码分析之 pipeline(一)》](https://www.jianshu.com/p/6efa9c5fa702)
+>
+> - 经历的过程要比添加节点要简单，可以用下面一幅图来表示
+>
+>   [![删除节点过程](23-Netty 源码解析-ChannelPipeline（三）之移除 ChannelHandler.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_06_07/01.png)删除节点过程
+>
+> - 最后的结果为
+>
+>   [![删除节点之后](23-Netty 源码解析-ChannelPipeline（三）之移除 ChannelHandler.assets/02.png)](http://static.iocoder.cn/images/Netty/2018_06_07/02.png)删除节点之后
+>
+> 结合这两幅图，可以很清晰地了解移除 Handler 的过程，另外，被删除的节点因为没有对象引用到，果过段时间就会被 gc 自动回收。
+
+# 4. callHandlerRemoved0
+
+`#callHandlerRemoved0(AbstractChannelHandlerContext)` 方法，执行回调 ChannelHandler 移除完成( removed )事件。代码如下：
+
+```
+ 1: private void callHandlerRemoved0(final AbstractChannelHandlerContext ctx) {
+ 2:     // Notify the complete removal.
+ 3:     try {
+ 4:         try {
+ 5:             // 回调 ChannelHandler 移除完成( removed )事件
+ 6:             ctx.handler().handlerRemoved(ctx);
+ 7:         } finally {
+ 8:             // 设置 AbstractChannelHandlerContext 已移除
+ 9:             ctx.setRemoved();
+10:         }
+11:     } catch (Throwable t) {
+12:         // 触发异常的传播
+13:         fireExceptionCaught(new ChannelPipelineException(
+14:                 ctx.handler().getClass().getName() + ".handlerRemoved() has thrown an exception.", t));
+15:     }
+16: }
+```
+
+- 第 6 行：调用 `ChannelHandler#handlerRemoved(AbstractChannelHandlerContext)` 方法，回调 ChannelHandler 移除完成( removed )事件。一般来说，通过这个方法，来释放 ChannelHandler 占用的资源。**注意**，因为这个方法的执行在 EventLoop 的线程中，所以要尽量避免执行时间过长。
+- 第 9 行：调用 `AbstractChannelHandlerContext#setRemoved()` 方法，设置 AbstractChannelHandlerContext 已移除。
+- 第 11 至 15 行：发生异常，触发异常的传播。详细解析，见 [《精尽 Netty 源码解析 —— ChannelPipeline（六）之异常事件的传播》](http://svip.iocoder.cn/Netty/ChannelPipeline-6-exception) 。
+
+# 5. PendingHandlerRemovedTask
+
+PendingHandlerRemovedTask 实现 PendingHandlerCallback 抽象类，用于回调移除 ChannelHandler 节点。代码如下：
+
+```
+private final class PendingHandlerRemovedTask extends PendingHandlerCallback {
+
+    PendingHandlerRemovedTask(AbstractChannelHandlerContext ctx) {
+        super(ctx);
+    }
+
+    @Override
+    public void run() {
+        callHandlerRemoved0(ctx);
+    }
+
+    @Override
+    void execute() {
+        EventExecutor executor = ctx.executor();
+        // 在 EventLoop 的线程中，回调 ChannelHandler removed 事件
+        if (executor.inEventLoop()) {
+            callHandlerRemoved0(ctx);
+        } else {
+            // 提交 EventLoop 中，执行回调 ChannelHandler removed 事件
+            try {
+                executor.execute(this); // <1>
+            } catch (RejectedExecutionException e) {
+                if (logger.isWarnEnabled()) {
+                    logger.warn(
+                            "Can't invoke handlerRemoved() as the EventExecutor {} rejected it," +
+                                    " removing handler {}.", executor, ctx.name(), e);
+                }
+                // 标记 AbstractChannelHandlerContext 为已移除
+                // remove0(...) was call before so just call AbstractChannelHandlerContext.setRemoved().
+                ctx.setRemoved();
+            }
+        }
+    }
+    
+}
+```
+
+- 在 `#execute()` 实现方法中，我们可以看到，和 `#remove((AbstractChannelHandlerContext ctx)` 方法的【第 17 至 32 行】的代码比较类似，目的是，在 EventLoop 的线程中，执行 `#callHandlerRemoved0(AbstractChannelHandlerContext)` 方法，回调 ChannelHandler 移除完成( removed )事件。
+- `<1>` 处，为什么 PendingHandlerRemovedTask 可以直接提交到 EventLoop 中呢？因为 PendingHandlerRemovedTask 是个 Runnable ，这也就是为什么 PendingHandlerCallback 实现 Runnable 接口的原因。
+
+# 666. 彩蛋
+
+水文一小篇。推荐阅读文章：
+
+- 闪电侠 [《Netty 源码分析之 pipeline(一)》](https://www.jianshu.com/p/6efa9c5fa702)
\ No newline at end of file
diff --git a/netty/24-Netty 源码解析-ChannelPipeline（四）之 Outbound 事件的传播.assets/01.png b/netty/24-Netty 源码解析-ChannelPipeline（四）之 Outbound 事件的传播.assets/01.png
new file mode 100644
index 0000000..c304e15
Binary files /dev/null and b/netty/24-Netty 源码解析-ChannelPipeline（四）之 Outbound 事件的传播.assets/01.png differ
diff --git a/netty/24-Netty 源码解析-ChannelPipeline（四）之 Outbound 事件的传播.assets/02-17199757354052.png b/netty/24-Netty 源码解析-ChannelPipeline（四）之 Outbound 事件的传播.assets/02-17199757354052.png
new file mode 100644
index 0000000..b58d09a
Binary files /dev/null and b/netty/24-Netty 源码解析-ChannelPipeline（四）之 Outbound 事件的传播.assets/02-17199757354052.png differ
diff --git a/netty/24-Netty 源码解析-ChannelPipeline（四）之 Outbound 事件的传播.md b/netty/24-Netty 源码解析-ChannelPipeline（四）之 Outbound 事件的传播.md
new file mode 100644
index 0000000..9f0a619
--- /dev/null
+++ b/netty/24-Netty 源码解析-ChannelPipeline（四）之 Outbound 事件的传播.md	
@@ -0,0 +1,401 @@
+# 精尽 Netty 源码解析 —— ChannelPipeline（四）之 Outbound 事件的传播
+
+# 1. 概述
+
+本文我们来分享，在 pipeline 中的 **Outbound 事件的传播**。我们先来回顾下 Outbound 事件的定义：
+
+> 老艿艿：A01、A02 等等，是我们每条定义的编号。
+
+- [x] A01：Outbound 事件是【请求】事件(由 Connect 发起一个请求, 并最终由 Unsafe 处理这个请求)
+
+  > 老艿艿：A01 = A02 + A03
+
+- [x] A02：Outbound 事件的发起者是 Channel
+
+- [x] A03：Outbound 事件的处理者是 Unsafe
+
+- [x] A04：Outbound 事件在 Pipeline 中的传输方向是 `tail` -> `head`
+
+- [x] A05：在 ChannelHandler 中处理事件时, 如果这个 Handler 不是最后一个 Handler ，则需要调用 `ctx.xxx` (例如 `ctx.connect` ) 将此事件继续传播下去. 如果不这样做, 那么此事件的传播会提前终止.
+
+- [x] A06：Outbound 事件流: `Context.OUT_EVT` -> `Connect.findContextOutbound` -> `nextContext.invokeOUT_EVT` -> `nextHandler.OUT_EVT` -> `nextContext.OUT_EVT`
+
+下面，我们来跟着代码，理解每条定义。
+
+# 2. ChannelOutboundInvoker
+
+在 `io.netty.channel.ChannelOutboundInvoker` 接口中，定义了所有 Outbound 事件对应的方法：
+
+```
+ChannelFuture bind(SocketAddress localAddress);
+ChannelFuture bind(SocketAddress localAddress, ChannelPromise promise);
+
+ChannelFuture connect(SocketAddress remoteAddress);
+ChannelFuture connect(SocketAddress remoteAddress, SocketAddress localAddress);
+ChannelFuture connect(SocketAddress remoteAddress, ChannelPromise promise);
+ChannelFuture connect(SocketAddress remoteAddress, SocketAddress localAddress, ChannelPromise promise);
+
+ChannelFuture disconnect();
+ChannelFuture disconnect(ChannelPromise promise);
+
+ChannelFuture close();
+ChannelFuture close(ChannelPromise promise);
+
+ChannelFuture deregister();
+ChannelFuture deregister(ChannelPromise promise);
+
+ChannelOutboundInvoker read();
+
+ChannelFuture write(Object msg);
+ChannelFuture write(Object msg, ChannelPromise promise);
+
+ChannelOutboundInvoker flush();
+
+ChannelFuture writeAndFlush(Object msg, ChannelPromise promise);
+ChannelFuture writeAndFlush(Object msg);
+```
+
+而 ChannelOutboundInvoker 的**部分**子类/接口如下图：
+
+[![类图](24-Netty 源码解析-ChannelPipeline（四）之 Outbound 事件的传播.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_06_10/01.png)类图
+
+- 我们可以看到类图，有 Channel、ChannelPipeline、AbstractChannelHandlerContext 都继承/实现了该接口。那这意味着什么呢？我们继续往下看。
+
+在 [《精尽 Netty 源码解析 —— 启动（一）之服务端》](http://svip.iocoder.cn/Netty/bootstrap-1-server/) 中，我们可以看到 Outbound 事件的其中之一 **bind** ，本文就以 **bind** 的过程，作为示例。调用栈如下：
+
+[![调用栈](http://static.iocoder.cn/images/Netty/2018_06_10/02.png)](http://static.iocoder.cn/images/Netty/2018_06_10/02.png)调用栈
+
+- `AbstractChannel#bind(SocketAddress localAddress, ChannelPromise promise)` 方法，代码如下：
+
+  ```
+  @Override
+  public ChannelFuture bind(SocketAddress localAddress, ChannelPromise promise) {
+      return pipeline.bind(localAddress, promise);
+  }
+  ```
+
+  - ```
+    AbstractChannel#bind(SocketAddress localAddress, ChannelPromise promise)
+    ```
+
+     
+
+    方法，实现的自 ChannelOutboundInvoker 接口。
+
+    - Channel 是 **bind** 的发起者，**这符合 Outbound 事件的定义 A02** 。
+
+  - 在方法内部，会调用
+
+     
+
+    ```
+    ChannelPipeline#bind(SocketAddress localAddress, ChannelPromise promise)
+    ```
+
+     
+
+    方法，而这个方法，也是实现的自 ChannelOutboundInvoker 接口。
+
+    从这里可以看出，对于 ChannelOutboundInvoker 接口方法的实现，Channel 对它的实现，会调用 ChannelPipeline 的对应方法
+
+    ( ( 有一点绕，胖友理解下 ) )。
+
+    - 那么接口下，让我们看看 `ChannelPipeline#bind(SocketAddress localAddress, ChannelPromise promise)` 方法的具体实现。
+
+# 3. DefaultChannelPipeline
+
+`DefaultChannelPipeline#bind(SocketAddress localAddress, ChannelPromise promise)` 方法的实现，代码如下：
+
+```
+@Override
+public final ChannelFuture bind(SocketAddress localAddress, ChannelPromise promise) {
+    return tail.bind(localAddress, promise);
+}
+```
+
+- 在方法内部，会调用
+
+   
+
+  ```
+  TailContext#bind(SocketAddress localAddress, ChannelPromise promise)
+  ```
+
+   
+
+  方法。
+
+  这符合 Outbound 事件的定义 A04
+
+   
+
+  。
+
+  - 实际上，TailContext 的该方法，继承自 AbstractChannelHandlerContext 抽象类，而 AbstractChannelHandlerContext 实现了 ChannelOutboundInvoker 接口。*从这里可以看出，对于 ChannelOutboundInvoker 接口方法的实现，ChannelPipeline 对它的实现，会调用 AbstractChannelHandlerContext 的对应方法*( 有一点绕，胖友理解下 )。
+
+# 4. AbstractChannelHandlerContext
+
+`AbstractChannelHandlerContext#bind(SocketAddress localAddress, ChannelPromise promise)` 方法的实现，代码如下：
+
+```
+ 1: @Override
+ 2: public ChannelFuture bind(final SocketAddress localAddress, final ChannelPromise promise) {
+ 3:     if (localAddress == null) {
+ 4:         throw new NullPointerException("localAddress");
+ 5:     }
+ 6:     // 判断是否为合法的 Promise 对象
+ 7:     if (isNotValidPromise(promise, false)) {
+ 8:         // cancelled
+ 9:         return promise;
+10:     }
+11: 
+12:     // 获得下一个 Outbound 节点
+13:     final AbstractChannelHandlerContext next = findContextOutbound();
+14:     // 获得下一个 Outbound 节点的执行器
+15:     EventExecutor executor = next.executor();
+16:     // 调用下一个 Outbound 节点的 bind 方法
+17:     if (executor.inEventLoop()) {
+18:         next.invokeBind(localAddress, promise);
+19:     } else {
+20:         safeExecute(executor, new Runnable() {
+21:             @Override
+22:             public void run() {
+23:                 next.invokeBind(localAddress, promise);
+24:             }
+25:         }, promise, null);
+26:     }
+27:     return promise;
+28: }
+```
+
+- 第 6 至 10 行：判断 `promise` 是否为合法的 Promise 对象。代码如下：
+
+  ```
+  private boolean isNotValidPromise(ChannelPromise promise, boolean allowVoidPromise) {
+      if (promise == null) {
+          throw new NullPointerException("promise");
+      }
+  
+      // Promise 已经完成
+      if (promise.isDone()) {
+          // Check if the promise was cancelled and if so signal that the processing of the operation
+          // should not be performed.
+          //
+          // See https://github.com/netty/netty/issues/2349
+          if (promise.isCancelled()) {
+              return true;
+          }
+          throw new IllegalArgumentException("promise already done: " + promise);
+      }
+  
+      // Channel 不符合
+      if (promise.channel() != channel()) {
+          throw new IllegalArgumentException(String.format(
+                  "promise.channel does not match: %s (expected: %s)", promise.channel(), channel()));
+      }
+  
+      // DefaultChannelPromise 合法 // <1>
+      if (promise.getClass() == DefaultChannelPromise.class) {
+          return false;
+      }
+      // 禁止 VoidChannelPromise 
+      if (!allowVoidPromise && promise instanceof VoidChannelPromise) {
+          throw new IllegalArgumentException(
+                  StringUtil.simpleClassName(VoidChannelPromise.class) + " not allowed for this operation");
+      }
+      // 禁止 CloseFuture
+      if (promise instanceof AbstractChannel.CloseFuture) {
+          throw new IllegalArgumentException(
+                  StringUtil.simpleClassName(AbstractChannel.CloseFuture.class) + " not allowed in a pipeline");
+      }
+      return false;
+  }
+  ```
+
+  - 虽然方法很长，重点是 `<1>` 处，`promise` 的类型为 DefaultChannelPromise 。
+
+- 第 13 行：【重要】调用 `#findContextOutbound()` 方法，获得下一个 Outbound 节点。代码如下：
+
+  ```
+  private AbstractChannelHandlerContext findContextOutbound() {
+      // 循环，向前获得一个 Outbound 节点
+      AbstractChannelHandlerContext ctx = this;
+      do {
+          ctx = ctx.prev;
+      } while (!ctx.outbound);
+      return ctx;
+  }
+  ```
+
+  - 循环，**向前**获得一个 Outbound 节点。
+  - 循环，**向前**获得一个 Outbound 节点。
+  - 循环，**向前**获得一个 Outbound 节点。
+  - 😈 重要的事情说三遍，对于 Outbound 事件的传播，是从 pipeline 的尾巴到头部，**这符合 Outbound 事件的定义 A04** 。
+
+- 第 15 行：调用 `AbstractChannelHandlerContext#executor()` 方法，获得下一个 Outbound 节点的执行器。代码如下：
+
+  ```
+  // Will be set to null if no child executor should be used, otherwise it will be set to the
+  // child executor.
+  /**
+   * EventExecutor 对象
+   */
+  final EventExecutor executor;
+  
+  @Override
+  public EventExecutor executor() {
+      if (executor == null) {
+          return channel().eventLoop();
+      } else {
+          return executor;
+      }
+  }
+  ```
+
+  - 如果未设置**子执行器**，则使用 Channel 的 EventLoop 作为执行器。😈 一般情况下，我们可以忽略**子执行器**的逻辑，也就是说，可以直接认为是使用 **Channel 的 EventLoop 作为执行器**。
+
+- 第 16 至 26 行：**在 EventLoop 的线程中**，调用**下一个节点**的 `AbstractChannelHandlerContext#invokeBind(SocketAddress localAddress, ChannelPromise promise)` 方法，传播 **bind** 事件给**下一个节点**。
+
+  - 第 20 至 25 行：如果不在 EventLoop 的线程中，会调用 `#safeExecute(EventExecutor executor, Runnable runnable, ChannelPromise promise, Object msg)` 方法，提交到 EventLoop 的线程中执行。代码如下：
+
+    ```
+    private static void safeExecute(EventExecutor executor, Runnable runnable, ChannelPromise promise, Object msg) {
+        try {
+            // 提交 EventLoop 的线程中，进行执行任务
+            executor.execute(runnable);
+        } catch (Throwable cause) {
+            try {
+                // 发生异常，回调通知 promise 相关的异常
+                promise.setFailure(cause);
+            } finally {
+                // 释放 msg 相关的资源
+                if (msg != null) {
+                    ReferenceCountUtil.release(msg);
+                }
+            }
+        }
+    }
+    ```
+
+    - x
+
+------
+
+`AbstractChannelHandlerContext#invokeBind(SocketAddress localAddress, ChannelPromise promise)` 方法，代码如下：
+
+```
+ 1: private void invokeBind(SocketAddress localAddress, ChannelPromise promise) {
+ 2:     if (invokeHandler()) { // 判断是否符合的 ChannelHandler
+ 3:         try {
+ 4:             // 调用该 ChannelHandler 的 bind 方法
+ 5:             ((ChannelOutboundHandler) handler()).bind(this, localAddress, promise);
+ 6:         } catch (Throwable t) {
+ 7:             notifyOutboundHandlerException(t, promise); // 通知 Outbound 事件的传播，发生异常
+ 8:         }
+ 9:     } else {
+10:         // 跳过，传播 Outbound 事件给下一个节点
+11:         bind(localAddress, promise);
+12:     }
+13: }
+```
+
+- 第 2 行：调用 `#invokeHandler()` 方法，判断是否符合的 ChannelHandler 。代码如下：
+
+  ```
+  /**
+   * Makes best possible effort to detect if {@link ChannelHandler#handlerAdded(ChannelHandlerContext)} was called
+   * yet. If not return {@code false} and if called or could not detect return {@code true}.
+   *
+   * If this method returns {@code false} we will not invoke the {@link ChannelHandler} but just forward the event.
+   * This is needed as {@link DefaultChannelPipeline} may already put the {@link ChannelHandler} in the linked-list
+   * but not called {@link ChannelHandler#handlerAdded(ChannelHandlerContext)}.
+   */
+  private boolean invokeHandler() {
+      // Store in local variable to reduce volatile reads.
+      int handlerState = this.handlerState;
+      return handlerState == ADD_COMPLETE || (!ordered && handlerState == ADD_PENDING);
+  }
+  ```
+
+  - 对于 `ordered = true` 的节点，必须 ChannelHandler 已经添加完成。
+  - 对于 `ordered = false` 的节点，没有 ChannelHandler 的要求。
+
+- 第 9 至 12 行：若是**不符合**的 ChannelHandler ，则**跳过**该节点，调用 `AbstractChannelHandlerContext#bind(SocketAddress localAddress, ChannelPromise promise)` 方法，传播 Outbound 事件给下一个节点。即，又回到 [「4. AbstractChannelHandlerContext」](https://svip.iocoder.cn/Netty/Pipeline-4-outbound/#) 的开头。
+
+- 第 2 至 8 行：若是**符合**的 ChannelHandler ：
+
+  - 第 5 行：调用 ChannelHandler 的 `#bind(ChannelHandlerContext ctx, SocketAddress localAddress, ChannelPromise promise)` 方法，处理 bind 事件。
+
+    - 😈 实际上，此时节点的数据类型为 DefaultChannelHandlerContext 类。若它被认为是 Outbound 节点，那么他的处理器的类型会是 **ChannelOutboundHandler** 。而 `io.netty.channel.ChannelOutboundHandler` 类似 ChannelOutboundInvoker ，定义了对每个 Outbound 事件的处理。代码如下：
+
+      ```
+      void bind(ChannelHandlerContext ctx, SocketAddress localAddress, ChannelPromise promise) throws Exception;
+      
+      void connect(ChannelHandlerContext ctx, SocketAddress remoteAddress, SocketAddress localAddress, ChannelPromise promise) throws Exception;
+      
+      void disconnect(ChannelHandlerContext ctx, ChannelPromise promise) throws Exception;
+      
+      void close(ChannelHandlerContext ctx, ChannelPromise promise) throws Exception;
+      
+      void deregister(ChannelHandlerContext ctx, ChannelPromise promise) throws Exception;
+      
+      void read(ChannelHandlerContext ctx) throws Exception;
+      
+      void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) throws Exception;
+      
+      void flush(ChannelHandlerContext ctx) throws Exception;
+      ```
+
+      - 胖友自己对比下噢。
+
+    - 如果节点的 `ChannelOutboundHandler#bind(ChannelHandlerContext ctx, SocketAddress localAddress, ChannelPromise promise)` 方法的实现，不调用 `AbstractChannelHandlerContext#bind(SocketAddress localAddress, ChannelPromise promise)` 方法，就不会传播 Outbound 事件给下一个节点。**这就是 Outbound 事件的定义 A05** 。可能有点绕，我们来看下 Netty LoggingHandler 对该方法的实现代码：
+
+      ```
+      final class LoggingHandler implements ChannelInboundHandler, ChannelOutboundHandler {
+      
+          // ... 省略无关方法
+          
+          @Override
+          public void bind(ChannelHandlerContext ctx, SocketAddress localAddress, ChannelPromise promise) throws Exception {
+              // 打印日志
+              log(Event.BIND, "localAddress=" + localAddress);
+              // 传递 bind 事件，给下一个节点
+              ctx.bind(localAddress, promise); // <1>
+          }
+      }
+      ```
+
+      - 如果把 `<1>` 处的代码去掉，bind 事件将不会传播给下一个节点！！！**一定要注意**。
+
+    - 这块的逻辑非常重要，如果胖友觉得很绕，一定要自己多调试 + 调试 + 调试。
+
+  - 第 7 行：如果发生异常，调用 `#notifyOutboundHandlerException(Throwable, Promise)` 方法，通知 Outbound 事件的传播，发生异常。详细解析，见 [《精尽 Netty 源码解析 —— ChannelPipeline（六）之异常事件的传播》](http://svip.iocoder.cn/Netty/ChannelPipeline-6-exception) 。
+
+------
+
+本小节的整个代码实现，**就是 Outbound 事件的定义 A06**的体现。而随着 Outbound 事件在节点不断从 pipeline 的尾部到头部的传播，最终会到达 HeadContext 节点。
+
+# 5. HeadContext
+
+`HeadContext#bind(ChannelHandlerContext ctx, SocketAddress localAddress, ChannelPromise promise)` 方法，代码如下：
+
+```
+@Override
+public void bind(ChannelHandlerContext ctx, SocketAddress localAddress, ChannelPromise promise) throws Exception {
+    unsafe.bind(localAddress, promise);
+}
+```
+
+- 调用 `Unsafe#bind(SocketAddress localAddress, ChannelPromise promise)` 方法，进行 bind 事件的处理。也就是说 Unsafe 是 **bind** 的处理着，**这符合 Outbound 事件的定义 A03** 。
+- 而后续的逻辑，就是 [《精尽 Netty 源码分析 —— 启动（一）之服务端》](http://svip.iocoder.cn/Netty/bootstrap-1-server/) 的 [「3.13.2 doBind0」](https://svip.iocoder.cn/Netty/Pipeline-4-outbound/#) 小节，从 `Unsafe#bind(SocketAddress localAddress, ChannelPromise promise)` 方法，开始。
+- 至此，整个 pipeline 的 Outbound 事件的传播结束。
+
+# 6. 关于其他 Outbound 事件
+
+本文暂时只分享了 **bind** 这个 Outbound 事件。剩余的其他事件，胖友可以自己进行调试和理解。例如：**connect** 事件，并且结合 [《精尽 Netty 源码分析 —— 启动（二）之客户端》](http://svip.iocoder.cn/Netty/bootstrap-2-client/) 一文。
+
+# 666. 彩蛋
+
+*推荐阅读文章：
+
+- 闪电侠 [《netty 源码分析之 pipeline(二)》](https://www.jianshu.com/p/087b7e9a27a2)*
\ No newline at end of file
diff --git a/netty/25-Netty 源码解析-ChannelPipeline（五）之 Inbound 事件的传播.assets/01.png b/netty/25-Netty 源码解析-ChannelPipeline（五）之 Inbound 事件的传播.assets/01.png
new file mode 100644
index 0000000..bd9bc17
Binary files /dev/null and b/netty/25-Netty 源码解析-ChannelPipeline（五）之 Inbound 事件的传播.assets/01.png differ
diff --git a/netty/25-Netty 源码解析-ChannelPipeline（五）之 Inbound 事件的传播.assets/02.png b/netty/25-Netty 源码解析-ChannelPipeline（五）之 Inbound 事件的传播.assets/02.png
new file mode 100644
index 0000000..b4103e7
Binary files /dev/null and b/netty/25-Netty 源码解析-ChannelPipeline（五）之 Inbound 事件的传播.assets/02.png differ
diff --git a/netty/25-Netty 源码解析-ChannelPipeline（五）之 Inbound 事件的传播.md b/netty/25-Netty 源码解析-ChannelPipeline（五）之 Inbound 事件的传播.md
new file mode 100644
index 0000000..38c7de4
--- /dev/null
+++ b/netty/25-Netty 源码解析-ChannelPipeline（五）之 Inbound 事件的传播.md	
@@ -0,0 +1,394 @@
+# 精尽 Netty 源码解析 —— ChannelPipeline（五）之 Inbound 事件的传播
+
+# 1. 概述
+
+本文我们来分享，在 pipeline 中的 **Inbound 事件的传播**。我们先来回顾下 Inbound 事件的定义：
+
+> 老艿艿：B01、B02 等等，是我们每条定义的编号。
+
+- [x] B01：Inbound 事件是【通知】事件, 当某件事情已经就绪后, 通知上层.
+
+  > 老艿艿：B01 = B02 + B03
+
+- [x] B02：Inbound 事件发起者是 Unsafe
+
+- [x] B03：Inbound 事件的处理者是 TailContext, 如果用户没有实现自定义的处理方法, 那么Inbound 事件默认的处理者是 TailContext, 并且其处理方法是空实现.
+
+- [x] B04：Inbound 事件在 Pipeline 中传输方向是 `head`( 头 ) -> `tail`( 尾 )
+
+- [x] B05：在 ChannelHandler 中处理事件时, 如果这个 Handler 不是最后一个 Handler, 则需要调用 `ctx.fireIN_EVT` (例如 `ctx.fireChannelActive` ) 将此事件继续传播下去. 如果不这样做, 那么此事件的传播会提前终止.
+
+- [x] B06：Inbound 事件流: `Context.fireIN_EVT` -> `Connect.findContextInbound` -> `nextContext.invokeIN_EVT` -> `nextHandler.IN_EVT` -> `nextContext.fireIN_EVT`
+
+Outbound 和 Inbound 事件十分的镜像，所以，接下来我们来跟着的代码，和 [《精尽 Netty 源码解析 —— ChannelPipeline（四）之 Outbound 事件的传播》](http://svip.iocoder.cn/Netty/Pipeline-4-inbound) 会非常相似。
+
+# 2. ChannelInboundInvoker
+
+在 `io.netty.channel.ChannelInboundInvoker` 接口中，定义了所有 Inbound 事件对应的方法：
+
+```
+ChannelInboundInvoker fireChannelRegistered();
+ChannelInboundInvoker fireChannelUnregistered();
+
+ChannelInboundInvoker fireChannelActive();
+ChannelInboundInvoker fireChannelInactive();
+
+ChannelInboundInvoker fireExceptionCaught(Throwable cause);
+
+ChannelInboundInvoker fireUserEventTriggered(Object event);
+
+ChannelInboundInvoker fireChannelRead(Object msg);
+ChannelInboundInvoker fireChannelReadComplete();
+
+ChannelInboundInvoker fireChannelWritabilityChanged();
+```
+
+而 ChannelInboundInvoker 的**部分**子类/接口如下图：
+
+[![类图](25-Netty 源码解析-ChannelPipeline（五）之 Inbound 事件的传播.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_06_13/01.png)类图
+
+- 我们可以看到类图，有 ChannelPipeline、AbstractChannelHandlerContext 都继承/实现了该接口。那这意味着什么呢？我们继续往下看。
+- 相比来说，Channel 实现了 ChannelOutboundInvoker 接口，但是**不实现** ChannelInboundInvoker 接口。
+
+在 [《精尽 Netty 源码解析 —— 启动（一）之服务端》](http://svip.iocoder.cn/Netty/bootstrap-1-server/) 中，我们可以看到 Inbound 事件的其中之一 **fireChannelActive** ，本文就以 **fireChannelActive** 的过程，作为示例。调用栈如下：
+
+[![调用栈](25-Netty 源码解析-ChannelPipeline（五）之 Inbound 事件的传播.assets/02.png)](http://static.iocoder.cn/images/Netty/2018_06_13/02.png)调用栈
+
+- `AbstractUnsafe#bind(final SocketAddress localAddress, final ChannelPromise promise)` 方法，代码如下：
+
+  ```
+  @Override
+  public final void bind(final SocketAddress localAddress, final ChannelPromise promise) {
+      // 判断是否在 EventLoop 的线程中。
+      assertEventLoop();
+  
+      // ... 省略部分代码
+     
+      // 记录 Channel 是否激活
+      boolean wasActive = isActive();
+  
+      // 绑定 Channel 的端口
+      doBind(localAddress);
+  
+      // 若 Channel 是新激活的，触发通知 Channel 已激活的事件。 
+      if (!wasActive && isActive()) {
+          invokeLater(new Runnable() {
+              @Override
+              public void run() {
+                  pipeline.fireChannelActive(); // <1>
+              }
+          });
+      }
+  
+      // 回调通知 promise 执行成功
+      safeSetSuccess(promise);
+  }
+  ```
+
+  - 在
+
+     
+
+    ```
+    <1>
+    ```
+
+     
+
+    处，调用
+
+     
+
+    ```
+    ChannelPipeline#fireChannelActive()
+    ```
+
+     
+
+    方法。
+
+    - Unsafe 是 **fireChannelActive** 的发起者，**这符合 Inbound 事件的定义 B02** 。
+    - 那么接口下，让我们看看 `ChannelPipeline#fireChannelActive()` 方法的具体实现。
+
+# 3. DefaultChannelPipeline
+
+`DefaultChannelPipeline#fireChannelActive()` 方法的实现，代码如下：
+
+```
+@Override
+public final ChannelPipeline fireChannelActive() {
+    AbstractChannelHandlerContext.invokeChannelActive(head);
+    return this;
+}
+```
+
+- 在方法内部，会调用
+
+   
+
+  ```
+  AbstractChannelHandlerContext#invokeChannelActive(final AbstractChannelHandlerContext next)
+  ```
+
+   
+
+  方法，而方法参数是
+
+   
+
+  ```
+  head
+  ```
+
+   
+
+  ，
+
+  这符合 Inbound 事件的定义 B04
+
+   
+
+  。
+
+  - 实际上，HeadContext 的该方法，继承自 AbstractChannelHandlerContext 抽象类，而 AbstractChannelHandlerContext 实现了 ChannelInboundInvoker 接口。*从这里可以看出，对于 ChannelInboundInvoker 接口方法的实现，ChannelPipeline 对它的实现，会调用 AbstractChannelHandlerContext 的对应方法*( 有一点绕，胖友理解下 )。
+
+# 4. AbstractChannelHandlerContext#invokeChannelActive
+
+`AbstractChannelHandlerContext#invokeChannelActive(final AbstractChannelHandlerContext next)` **静态**方法，代码如下：
+
+```
+ 1: static void invokeChannelActive(final AbstractChannelHandlerContext next) {
+ 2:     // 获得下一个 Inbound 节点的执行器
+ 3:     EventExecutor executor = next.executor();
+ 4:     // 调用下一个 Inbound 节点的 Channel active 方法
+ 5:     if (executor.inEventLoop()) {
+ 6:         next.invokeChannelActive();
+ 7:     } else {
+ 8:         executor.execute(new Runnable() {
+ 9:             @Override
+10:             public void run() {
+11:                 next.invokeChannelActive();
+12:             }
+13:         });
+14:     }
+15: }
+```
+
+- 方法参数 `next` ，下一个 Inbound 节点。
+
+- 第 3 行：调用 `AbstractChannelHandlerContext#executor()` 方法，获得下一个 Inbound 节点的执行器。
+
+- 第 4 至 14 行：调用 `AbstractChannelHandlerContext#invokeChannelActive()` 方法，调用下一个 Inbound 节点的 Channel active 方法。
+
+  - 在 [「3. DefaultChannelPipeline」](https://svip.iocoder.cn/Netty/Pipeline-5-inbound/#) 中，我们可以看到传递的**第一个** `next` 方法参数为 `head`( HeadContext ) 节点。
+
+  - 代码如下：
+
+    ```
+     1: private void invokeChannelActive() {
+     2:     if (invokeHandler()) { // 判断是否符合的 ChannelHandler
+     3:         try {
+     4:             // 调用该 ChannelHandler 的 Channel active 方法
+     5:             ((ChannelInboundHandler) handler()).channelActive(this);
+     6:         } catch (Throwable t) {
+     7:             notifyHandlerException(t);  // 通知 Inbound 事件的传播，发生异常
+     8:         }
+     9:     } else {
+    10:         // 跳过，传播 Inbound 事件给下一个节点
+    11:         fireChannelActive();
+    12:     }
+    13: }
+    ```
+
+    - 第 2 行：调用 `#invokeHandler()` 方法，判断是否符合的 ChannelHandler 。
+
+    - 第 9 至 12 行：若是**不符合**的 ChannelHandler ，则**跳过**该节点，调用 `AbstractChannelHandlerContext#fireChannelActive(` 方法，传播 Inbound 事件给下一个节点。详细解析，见 [「6. AbstractChannelHandlerContext#fireChannelActive」](https://svip.iocoder.cn/Netty/Pipeline-5-inbound/#) 。
+
+    - 第 2 至 8 行：若是**符合**的 ChannelHandler ：
+
+      - 第 5 行：调用 ChannelHandler 的 `#channelActive(ChannelHandlerContext ctx)` 方法，处理 Channel active 事件。
+
+        - 😈 实际上，此时节点的数据类型为 DefaultChannelHandlerContext 类。若它被认为是 Inbound 节点，那么他的处理器的类型会是 **ChannelInboundHandler** 。而 `io.netty.channel.ChannelInboundHandler` 类似 ChannelInboundInvoker ，定义了对每个 Inbound 事件的处理。代码如下：
+
+          ```
+          void channelRegistered(ChannelHandlerContext ctx) throws Exception;
+          void channelUnregistered(ChannelHandlerContext ctx) throws Exception;
+          
+          void channelActive(ChannelHandlerContext ctx) throws Exception;
+          void channelInactive(ChannelHandlerContext ctx) throws Exception;
+          
+          void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws Exception;
+          
+          void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception;
+          void channelReadComplete(ChannelHandlerContext ctx) throws Exception;
+          
+          void channelWritabilityChanged(ChannelHandlerContext ctx) throws Exception;
+           
+          @Override
+          @SuppressWarnings("deprecation")
+          void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception; // 不属于 Inbound 事件
+          ```
+
+          - 胖友自己对比下噢。
+
+        - 如果节点的 `ChannelInboundHandler#channelActive(ChannelHandlerContext ctx` 方法的实现，不调用 `AbstractChannelHandlerContext#fireChannelActive()` 方法，就不会传播 Inbound 事件给下一个节点。**这就是 Inbound 事件的定义 B05** 。可能有点绕，我们来看下 Netty LoggingHandler 对该方法的实现代码：
+
+          ```
+          final class LoggingHandler implements ChannelInboundHandler, ChannelOutboundHandler {
+          
+              // ... 省略无关方法
+              
+              @Override
+              public void channelActive(ChannelHandlerContext ctx) throws Exception {
+                  // 打印日志
+                  if (logger.isEnabled(internalLevel)) {
+                      logger.log(internalLevel, format(ctx, "ACTIVE"));
+                  }
+                  // 传递 Channel active 事件，给下一个节点
+                  ctx.fireChannelActive(); // <1>
+              }
+          }
+          ```
+
+          - 如果把 `<1>` 处的代码去掉，Channel active 事件 事件将不会传播给下一个节点！！！**一定要注意**。
+
+        - 这块的逻辑非常重要，如果胖友觉得很绕，一定要自己多调试 + 调试 + 调试。
+
+      - 第 7 行：如果发生异常，调用 `#notifyHandlerException(Throwable)` 方法，通知 Inbound 事件的传播，发生异常。详细解析，见 [《精尽 Netty 源码解析 —— ChannelPipeline（六）之异常事件的传播》](http://svip.iocoder.cn/Netty/ChannelPipeline-6-exception) 。
+
+# 5. HeadContext
+
+`HeadContext#invokeChannelActive()` 方法，代码如下：
+
+```
+@Override
+public void channelActive(ChannelHandlerContext ctx) throws Exception {
+    // 传播 Channel active 事件给下一个 Inbound 节点 <1>
+    ctx.fireChannelActive();
+
+    // 执行 read 逻辑 <2>
+    readIfIsAutoRead();
+}
+```
+
+- `<1>` 处，调用 `AbstractChannelHandlerContext#fireChannelActive()` 方法，传播 Channel active 事件给下一个 Inbound 节点。详细解析，见 [「6. AbstractChannelHandlerContext」](https://svip.iocoder.cn/Netty/Pipeline-5-inbound/#) 中。
+
+- `<2>` 处，调用 `HeadContext#readIfIsAutoRead()` 方法，执行 read 逻辑。代码如下：
+
+  ```
+  // HeadContext.java
+  private void readIfIsAutoRead() {
+      if (channel.config().isAutoRead()) { 
+          channel.read();
+      }
+  }
+  
+  // AbstractChannel.java
+  @Override
+  public Channel read() {
+      pipeline.read();
+      return this;
+  }
+  ```
+
+  - 该方法内部，会调用 `Channel#read()` 方法，而后通过 pipeline 传递该 **read** OutBound 事件，最终调用 `HeadContext#read()` 方法，代码如下：
+
+    ```
+    @Override
+    public void read(ChannelHandlerContext ctx) {
+        unsafe.beginRead();
+    }
+    ```
+
+    - 后续的逻辑，便是 [《精尽 Netty 源码分析 —— 启动（一）之服务端》](http://svip.iocoder.cn/Netty/bootstrap-1-server/) 的 [3.13.3 beginRead](https://svip.iocoder.cn/Netty/Pipeline-5-inbound/#) 小节，胖友可以自己再去回顾下。
+
+  - 这里说的是 **OutBound** 事件，不是本文的 InBound 事件。所以，胖友不要搞混哈。只能说是对 [《精尽 Netty 源码分析 —— 启动（一）之服务端》](http://svip.iocoder.cn/Netty/bootstrap-1-server/) 的 [3.13.3 beginRead](https://svip.iocoder.cn/Netty/Pipeline-5-inbound/#) 小节的补充。
+
+# 6. AbstractChannelHandlerContext#fireChannelActive
+
+`AbstractChannelHandlerContext#fireChannelActive()` 方法，代码如下：
+
+```
+@Override
+public ChannelHandlerContext fireChannelActive() {
+    // 获得下一个 Inbound 节点的执行器
+    // 调用下一个 Inbound 节点的 Channel active 方法
+    invokeChannelActive(findContextInbound());
+    return this;
+}
+```
+
+- 【重要】调用 `AbstractChannelHandlerContext#findContextInbound()` 方法，获得下一个 Inbound 节点的执行器。代码如下：
+
+  ```
+  private AbstractChannelHandlerContext findContextInbound() {
+      // 循环，向后获得一个 Inbound 节点
+      AbstractChannelHandlerContext ctx = this;
+      do {
+          ctx = ctx.next;
+      } while (!ctx.inbound);
+      return ctx;
+  }
+  ```
+
+  - 循环，**向后**获得一个 Inbound 节点。
+  - 循环，**向后**获得一个 Inbound 节点。
+  - 循环，**向后**获得一个 Inbound 节点。
+  - 😈 重要的事情说三遍，对于 Inbound 事件的传播，是从 pipeline 的头部到尾部，**这符合 Inbound 事件的定义 B04** 。
+
+- 调用 `AbstractChannelHandlerContext#invokeChannelActive(AbstractChannelHandlerContext)` **静态**方法，调用下一个 Inbound 节点的 Channel active 方法。即，又回到 [「4. AbstractChannelHandlerContext#invokeChannelActive」](https://svip.iocoder.cn/Netty/Pipeline-5-inbound/#) 的开头。
+
+------
+
+本小节的整个代码实现，**就是 Inbound 事件的定义 B06** 的体现。而随着 Inbound 事件在节点不断从 pipeline 的头部到尾部的传播，最终会到达 TailContext 节点。
+
+# 7. TailContext
+
+`TailContext#channelActive(ChannelHandlerContext ctx)` 方法，代码如下：
+
+```
+@Override
+public void channelActive(ChannelHandlerContext ctx) throws Exception {
+    onUnhandledInboundChannelActive();
+}
+```
+
+- 在方法内部，会调用 `DefaultChannelPipeline#onUnhandledInboundChannelActive()` 方法，代码如下：
+
+  ```
+  /**
+   * Called once the {@link ChannelInboundHandler#channelActive(ChannelHandlerContext)}event hit
+   * the end of the {@link ChannelPipeline}.
+   */
+  protected void onUnhandledInboundChannelActive() {
+  }
+  ```
+
+  - 该方法是个**空**方法，**这符合 Inbound 事件的定义 B03** 。
+  - 至此，整个 pipeline 的 Inbound 事件的传播结束。
+
+# 8. 关于其他 Inbound 事件
+
+本文暂时只分享了 **firecChannelActive** 这个 Inbound 事件。剩余的其他事件，胖友可以自己进行调试和理解。例如：**fireChannelRegistered** 事件，并且结合 [《精尽 Netty 源码分析 —— 启动（一）之服务端》](http://svip.iocoder.cn/Netty/bootstrap-1-server/) 一文。
+
+# 666. 彩蛋
+
+推荐阅读文章：
+
+- 闪电侠 [《netty 源码分析之 pipeline(二)》](https://www.jianshu.com/p/087b7e9a27a2)
+
+感觉上来说，Inbound 事件的传播，比起 Outbound 事件的传播，会相对“绕”一点点。简化来说，实际大概是如下：
+
+```
+Unsafe 开始 => DefaultChannelPipeline#fireChannelActive
+
+=> HeadContext#invokeChannelActive => DefaultChannelHandlerContext01#fireChannelActive
+
+=> DefaultChannelHandlerContext01#invokeChannelActive => DefaultChannelHandlerContext02#fireChannelActive
+...
+=> DefaultChannelHandlerContext99#fireChannelActive => TailContext#fireChannelActive
+
+=> TailContext#invokeChannelActive => 结束
+```
+
+笔者觉得可能解释的也有点“绕”，如果不理解或者有地方写的有误解，欢迎来叨叨，以便我们能一起优化这篇文章。
\ No newline at end of file
diff --git a/netty/26-Netty 源码解析-ChannelPipeline（六）之异常事件的传播.assets/01.png b/netty/26-Netty 源码解析-ChannelPipeline（六）之异常事件的传播.assets/01.png
new file mode 100644
index 0000000..328f487
Binary files /dev/null and b/netty/26-Netty 源码解析-ChannelPipeline（六）之异常事件的传播.assets/01.png differ
diff --git a/netty/26-Netty 源码解析-ChannelPipeline（六）之异常事件的传播.assets/02.png b/netty/26-Netty 源码解析-ChannelPipeline（六）之异常事件的传播.assets/02.png
new file mode 100644
index 0000000..e2ff4f9
Binary files /dev/null and b/netty/26-Netty 源码解析-ChannelPipeline（六）之异常事件的传播.assets/02.png differ
diff --git a/netty/26-Netty 源码解析-ChannelPipeline（六）之异常事件的传播.md b/netty/26-Netty 源码解析-ChannelPipeline（六）之异常事件的传播.md
new file mode 100644
index 0000000..3502fd7
--- /dev/null
+++ b/netty/26-Netty 源码解析-ChannelPipeline（六）之异常事件的传播.md	
@@ -0,0 +1,229 @@
+# 精尽 Netty 源码解析 —— ChannelPipeline（六）之异常事件的传播
+
+# 1. 概述
+
+在 [《精尽 Netty 源码解析 —— ChannelPipeline（四）之 Outbound 事件的传播》](http://svip.iocoder.cn/Netty/Pipeline-4-outbound/) 和 [《精尽 Netty 源码解析 —— ChannelPipeline（五）之 Inbound 事件的传播》](http://svip.iocoder.cn/Netty/Pipeline-5-inbound/) 中，我们看到 Outbound 和 Inbound 事件在 pipeline 中的传播逻辑。但是，无可避免，传播的过程中，可能会发生异常，那是怎么处理的呢？
+
+本文，我们就来分享分享这块。
+
+# 2. notifyOutboundHandlerException
+
+我们以 Outbound 事件中的 **bind** 举例子，代码如下：
+
+```
+// AbstractChannelHandlerContext.java
+
+private void invokeBind(SocketAddress localAddress, ChannelPromise promise) {
+    if (invokeHandler()) { // 判断是否符合的 ChannelHandler
+        try {
+            // 调用该 ChannelHandler 的 bind 方法 <1>
+            ((ChannelOutboundHandler) handler()).bind(this, localAddress, promise);
+        } catch (Throwable t) {
+            notifyOutboundHandlerException(t, promise); // 通知 Outbound 事件的传播，发生异常 <2>
+        }
+    } else {
+        // 跳过，传播 Outbound 事件给下一个节点
+        bind(localAddress, promise);
+    }
+}
+```
+
+- 在 `<1>` 处，调用 `ChannelOutboundHandler#bind(ChannelHandlerContext ctx, SocketAddress localAddress, ChannelPromise promise)` 方法**发生异常**时，会在 `<2>` 处调用 `AbstractChannelHandlerContext#notifyOutboundHandlerException(Throwable cause, ChannelPromise promise)` 方法，通知 Outbound 事件的传播，发生异常。
+- 其他 Outbound 事件，大体的代码也是和 `#invokeBind(SocketAddress localAddress, ChannelPromise promise)` 是一致的。如下图所示：[![类图](26-Netty 源码解析-ChannelPipeline（六）之异常事件的传播.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_06_16/01.png)类图
+
+------
+
+`AbstractChannelHandlerContext#notifyOutboundHandlerException(Throwable cause, ChannelPromise promise)` 方法，通知 Outbound 事件的传播，发生异常。代码如下：
+
+```
+private static void notifyOutboundHandlerException(Throwable cause, ChannelPromise promise) {
+    // Only log if the given promise is not of type VoidChannelPromise as tryFailure(...) is expected to return
+    // false.
+    PromiseNotificationUtil.tryFailure(promise, cause, promise instanceof VoidChannelPromise ? null : logger);
+}
+```
+
+- 在方法内部，会调用 `PromiseNotificationUtil#tryFailure(Promise<?> p, Throwable cause, InternalLogger logger)` 方法，通知 bind 事件对应的 Promise 对应的监听者们。代码如下：
+
+  ```
+  public static void tryFailure(Promise<?> p, Throwable cause, InternalLogger logger) {
+      if (!p.tryFailure(cause) && logger != null) {
+          Throwable err = p.cause();
+          if (err == null) {
+              logger.warn("Failed to mark a promise as failure because it has succeeded already: {}", p, cause);
+          } else {
+              logger.warn(
+                      "Failed to mark a promise as failure because it has failed already: {}, unnotified cause: {}",
+                      p, ThrowableUtil.stackTraceToString(err), cause);
+          }
+      }
+  }
+  ```
+
+  - 以 bind 事件来举一个监听器的例子。代码如下：
+
+    ```
+    ChannelFuture f = b.bind(PORT).addListener(new ChannelFutureListener() { // <1> 监听器就是我！
+        @Override
+        public void operationComplete(ChannelFuture future) throws Exception {
+            System.out.println("异常：" + future.casue());
+        }
+    }).sync();
+    ```
+
+    - `<1>` 处的监听器，就是示例。当发生异常时，就会通知该监听器，对该异常做进一步**自定义**的处理。**也就是说，该异常不会在 pipeline 中传播**。
+
+  - 我们再来看看怎么通知监听器的源码实现。调用 `DefaultPromise#tryFailure(Throwable cause)` 方法，通知 Promise 的监听器们，发生了异常。代码如下：
+
+    ```
+    @Override
+    public boolean tryFailure(Throwable cause) {
+        if (setFailure0(cause)) { // 设置 Promise 的结果
+            // 通知监听器
+            notifyListeners();
+            // 返回成功
+            return true;
+        }
+        // 返回失败
+        return false;
+    }
+    ```
+
+    - 若 `DefaultPromise#setFailure0(Throwable cause)` 方法，设置 Promise 的结果为方法传入的异常。但是有可能会传递失败，例如说，Promise 已经被设置了结果。
+    - 如果该方法返回 `false` 通知 Promise 失败，那么 `PromiseNotificationUtil#tryFailure(Promise<?> p, Throwable cause, InternalLogger logger)` 方法的后续，就会使用 `logger` 打印错误日志。
+
+# 3. notifyHandlerException
+
+我们以 Inbound 事件中的 **fireChannelActive** 举例子，代码如下：
+
+```
+private void invokeChannelActive() {
+    if (invokeHandler()) { // 判断是否符合的 ChannelHandler
+        try {
+            // 调用该 ChannelHandler 的 Channel active 方法 <1>
+            ((ChannelInboundHandler) handler()).channelActive(this);
+        } catch (Throwable t) {
+            notifyHandlerException(t);  // 通知 Inbound 事件的传播，发生异常 <2>
+        }
+    } else {
+        // 跳过，传播 Inbound 事件给下一个节点
+        fireChannelActive();
+    }
+}
+```
+
+- 在 `<1>` 处，调用 `ChannelInboundHandler#channelActive(ChannelHandlerContext ctx)` 方法**发生异常**时，会在 `<2>` 处调用 `AbstractChannelHandlerContext#notifyHandlerException(Throwable cause)` 方法，通知 Inbound 事件的传播，发生异常。
+
+- 其他 Inbound 事件，大体的代码也是和
+
+   
+
+  ```
+  #invokeChannelActive()
+  ```
+
+   
+
+  是一致的。如下图所示：
+
+  ![类图](26-Netty 源码解析-ChannelPipeline（六）之异常事件的传播.assets/02.png)
+
+  类图
+
+  - 😈 **注意，笔者在写的时候，突然发现 Outbound 事件中的 read 和 flush 的异常处理方式和 Inbound 事件是一样的**。
+  - 😈 **注意，笔者在写的时候，突然发现 Outbound 事件中的 read 和 flush 的异常处理方式和 Inbound 事件是一样的**。
+  - 😈 **注意，笔者在写的时候，突然发现 Outbound 事件中的 read 和 flush 的异常处理方式和 Inbound 事件是一样的**。
+
+------
+
+`AbstractChannelHandlerContext#notifyHandlerException(Throwable cause)` 方法，通知 Inbound 事件的传播，发生异常。代码如下：
+
+```
+private void notifyHandlerException(Throwable cause) {
+    // <1> 如果是在 `ChannelHandler#exceptionCaught(ChannelHandlerContext ctx, Throwable cause)` 方法中，仅打印错误日志。否则会形成死循环。
+    if (inExceptionCaught(cause)) {
+        if (logger.isWarnEnabled()) {
+            logger.warn(
+                    "An exception was thrown by a user handler " +
+                            "while handling an exceptionCaught event", cause);
+        }
+        return;
+    }
+
+    // <2> 在 pipeline 中，传播 Exception Caught 事件
+    invokeExceptionCaught(cause);
+}
+```
+
+- `<1>` 处，调用 `AbstractChannelHandlerContext#inExceptionCaught(Throwable cause)` 方法，如果是在 `ChannelHandler#exceptionCaught(ChannelHandlerContext ctx, Throwable cause)` 方法中，**发生异常**，仅打印错误日志，**并 `return` 返回** 。否则会形成死循环。代码如下：
+
+  ```
+  private static boolean inExceptionCaught(Throwable cause) {
+      do {
+          StackTraceElement[] trace = cause.getStackTrace();
+          if (trace != null) {
+              for (StackTraceElement t : trace) { // 循环 StackTraceElement
+                  if (t == null) {
+                      break;
+                  }
+                  if ("exceptionCaught".equals(t.getMethodName())) { // 通过方法名判断
+                      return true;
+                  }
+              }
+          }
+          cause = cause.getCause();
+      } while (cause != null); // 循环异常的 cause() ，直到到没有
+      
+      return false;
+  }
+  ```
+
+  - 通过 StackTraceElement 的方法名来判断，是不是 `ChannelHandler#exceptionCaught(ChannelHandlerContext ctx, Throwable cause)` 方法。
+
+- `<2>` 处，调用 `AbstractChannelHandlerContext#invokeExceptionCaught(Throwable cause)` 方法，在 pipeline 中，传递 Exception Caught 事件。在下文中，我们会看到，和 [《精尽 Netty 源码解析 —— ChannelPipeline（五）之 Inbound 事件的传播》](http://svip.iocoder.cn/Netty/Pipeline-5-inbound/) 的逻辑( `AbstractChannelHandlerContext#invokeChannelActive()` )是**一致**的。
+
+  - 比较特殊的是，Exception Caught 事件在 pipeline 的起始节点，不是 `head` 头节点，而是**发生异常的当前节点开始**。怎么理解好呢？对于在 pipeline 上传播的 Inbound **xxx** 事件，在发生异常后，转化成 **Exception Caught** 事件，继续从当前节点，继续向下传播。
+
+  - 如果 **Exception Caught** 事件在 pipeline 中的传播过程中，一直没有处理掉该异常的节点，最终会到达尾节点 `tail` ，它对 `#exceptionCaught(ChannelHandlerContext ctx, Throwable cause)` 方法的实现，代码如下：
+
+    ```
+    @Override
+    public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
+        onUnhandledInboundException(cause);
+    }
+    ```
+
+    - 在方法内部，会调用 `DefaultChannelPipeline#onUnhandledInboundException(Throwable cause)` 方法，代码如下：
+
+      ```
+      /**
+       * Called once a {@link Throwable} hit the end of the {@link ChannelPipeline} without been handled by the user
+       * in {@link ChannelHandler#exceptionCaught(ChannelHandlerContext, Throwable)}.
+       */
+      protected void onUnhandledInboundException(Throwable cause) {
+          try {
+              logger.warn(
+                      "An exceptionCaught() event was fired, and it reached at the tail of the pipeline. " +
+                              "It usually means the last handler in the pipeline did not handle the exception.",
+                      cause);
+          } finally {
+              ReferenceCountUtil.release(cause);
+          }
+      }
+      ```
+
+      - 打印**告警**日志，并调用 `ReferenceCountUtil#release(Throwable)` 方法，释放需要释放的资源。
+
+      - 从英文注释中，我们也可以看到，这种情况出现在**使用者**未定义合适的 ChannelHandler 处理这种异常，所以对于这种情况下，`tail` 节点只好打印**告警**日志。
+
+      - 实际使用时，笔者建议胖友一定要定义 ExceptionHandler ，能够处理掉所有的异常，而不要使用到 `tail` 节点的异常处理。😈
+
+      - 好基友【闪电侠】对尾节点 `tail` 做了很赞的总结
+
+        > 总结一下，tail 节点的作用就是结束事件传播，并且对一些重要的事件做一些善意提醒
+
+# 666. 彩蛋
+
+推荐阅读文章：
+
+- 闪电侠 [《netty 源码分析之 pipeline(二)》](https://www.jianshu.com/p/087b7e9a27a2)
\ No newline at end of file
diff --git a/netty/27-Netty 源码解析-Channel（一）之简介.assets/01-17199757822901.png b/netty/27-Netty 源码解析-Channel（一）之简介.assets/01-17199757822901.png
new file mode 100644
index 0000000..e352697
Binary files /dev/null and b/netty/27-Netty 源码解析-Channel（一）之简介.assets/01-17199757822901.png differ
diff --git a/netty/27-Netty 源码解析-Channel（一）之简介.assets/02-17199757822912.png b/netty/27-Netty 源码解析-Channel（一）之简介.assets/02-17199757822912.png
new file mode 100644
index 0000000..2345e9e
Binary files /dev/null and b/netty/27-Netty 源码解析-Channel（一）之简介.assets/02-17199757822912.png differ
diff --git a/netty/27-Netty 源码解析-Channel（一）之简介.assets/03.png b/netty/27-Netty 源码解析-Channel（一）之简介.assets/03.png
new file mode 100644
index 0000000..cb75d2d
Binary files /dev/null and b/netty/27-Netty 源码解析-Channel（一）之简介.assets/03.png differ
diff --git a/netty/27-Netty 源码解析-Channel（一）之简介.assets/04.png b/netty/27-Netty 源码解析-Channel（一）之简介.assets/04.png
new file mode 100644
index 0000000..e6cde4d
Binary files /dev/null and b/netty/27-Netty 源码解析-Channel（一）之简介.assets/04.png differ
diff --git a/netty/27-Netty 源码解析-Channel（一）之简介.assets/05.png b/netty/27-Netty 源码解析-Channel（一）之简介.assets/05.png
new file mode 100644
index 0000000..8564c57
Binary files /dev/null and b/netty/27-Netty 源码解析-Channel（一）之简介.assets/05.png differ
diff --git a/netty/27-Netty 源码解析-Channel（一）之简介.md b/netty/27-Netty 源码解析-Channel（一）之简介.md
new file mode 100644
index 0000000..afa51cf
--- /dev/null
+++ b/netty/27-Netty 源码解析-Channel（一）之简介.md	
@@ -0,0 +1,545 @@
+# 精尽 Netty 源码解析 —— Channel（一）之简介
+
+# 1. 概述
+
+在前面的文章中，我们已经不断看到 Netty Channel 的身影，例如：
+
+- 在 [《精尽 Netty 源码分析 —— 启动（一）之服务端》](http://svip.iocoder.cn/Netty/bootstrap-1-server/) 中，我们看了服务端 NioServerSocketChannel **对象创建**的过程。
+- 在 [《精尽 Netty 源码分析 —— 启动（二）之客户端》](http://svip.iocoder.cn/Netty/bootstrap-2-client/) 中，我们看了客户端 NioSocketChannel **对象创建**的过程。
+
+但是，考虑到本小节的后续文章，我们还是需要这样一篇文章，整体性的再看一次 Channel 的面貌。
+
+# 2. Channel
+
+`io.netty.channel.Channel` ，实现 AttributeMap、ChannelOutboundInvoker、Comparable 接口，Netty Channel 接口。
+
+在 [《精尽 Netty 源码分析 —— Netty 简介（一）之项目结构》](http://svip.iocoder.cn/Netty/intro-1/) 中，我们对 Channel 的组件定义如下：
+
+> Channel 是 Netty 网络操作抽象类，它除了包括基本的 I/O 操作，如 bind、connect、read、write 之外，还包括了 Netty 框架相关的一些功能，如获取该 Channel 的 EventLoop 。
+>
+> 在传统的网络编程中，作为核心类的 Socket ，它对程序员来说并不是那么友好，直接使用其成本还是稍微高了点。而 Netty 的 Channel 则提供的一系列的 API ，它大大降低了直接与 Socket 进行操作的复杂性。而相对于原生 NIO 的 Channel，Netty 的 Channel 具有如下优势( 摘自《Netty权威指南( 第二版 )》) ：
+>
+> - 在 Channel 接口层，采用 Facade 模式进行统一封装，将网络 I/O 操作、网络 I/O 相关联的其他操作封装起来，统一对外提供。
+> - Channel 接口的定义尽量大而全，为 SocketChannel 和 ServerSocketChannel 提供统一的视图，由不同子类实现不同的功能，公共功能在抽象父类中实现，最大程度地实现功能和接口的重用。
+> - 具体实现采用聚合而非包含的方式，将相关的功能类聚合在 Channel 中，由 Channel 统一负责和调度，功能实现更加灵活。
+
+## 2.1 基础查询
+
+```
+/**
+ * Returns the globally unique identifier of this {@link Channel}.
+ *
+ * Channel 的编号
+ */
+ChannelId id();
+
+/**
+ * Return the {@link EventLoop} this {@link Channel} was registered to.
+ *
+ * Channel 注册到的 EventLoop
+ */
+EventLoop eventLoop();
+
+/**
+ * Returns the parent of this channel.
+ *
+ * 父 Channel 对象
+ *
+ * @return the parent channel.
+ *         {@code null} if this channel does not have a parent channel.
+ */
+Channel parent();
+
+/**
+ * Returns the configuration of this channel.
+ *
+ * Channel 配置参数
+ */
+ChannelConfig config();
+
+/**
+ * Returns an <em>internal-use-only</em> object that provides unsafe operations.
+ *
+ * Unsafe 对象
+ */
+Unsafe unsafe();
+
+/**
+ * Return the assigned {@link ChannelPipeline}.
+ *
+ * ChannelPipeline 对象，用于处理 Inbound 和 Outbound 事件的处理
+ */
+ChannelPipeline pipeline();
+
+/**
+ * Return the assigned {@link ByteBufAllocator} which will be used to allocate {@link ByteBuf}s.
+ *
+ * ByteBuf 分配器
+ */
+ByteBufAllocator alloc();
+
+/**
+ * Returns the local address where this channel is bound to.  The returned
+ * {@link SocketAddress} is supposed to be down-cast into more concrete
+ * type such as {@link InetSocketAddress} to retrieve the detailed
+ * information.
+ *
+ * 本地地址
+ *
+ * @return the local address of this channel.
+ *         {@code null} if this channel is not bound.
+ */
+SocketAddress localAddress();
+/**
+ * Returns the remote address where this channel is connected to.  The
+ * returned {@link SocketAddress} is supposed to be down-cast into more
+ * concrete type such as {@link InetSocketAddress} to retrieve the detailed
+ * information.
+ *
+ * 远端地址
+ *
+ * @return the remote address of this channel.
+ *         {@code null} if this channel is not connected.
+ *         If this channel is not connected but it can receive messages
+ *         from arbitrary remote addresses (e.g. {@link DatagramChannel},
+ *         use {@link DatagramPacket#recipient()} to determine
+ *         the origination of the received message as this method will
+ *         return {@code null}.
+ */
+SocketAddress remoteAddress();
+```
+
+- 自身基本信息有 `#id()`、`#parent()`、`#config()`、`#localAddress()`、`#remoteAddress()` 方法。
+- 每个 Channel 都有的核心组件有 `#eventLoop()`、`#unsafe()`、`#pipeline()`、`#alloc()` 方法。
+
+## 2.2 状态查询
+
+```
+/**
+ * Returns {@code true} if the {@link Channel} is open and may get active later
+ *
+ * Channel 是否打开。
+ *
+ * true 表示 Channel 可用
+ * false 表示 Channel 已关闭，不可用
+ */
+boolean isOpen();
+
+/**
+ * Returns {@code true} if the {@link Channel} is registered with an {@link EventLoop}.
+ *
+ * Channel 是否注册
+ *
+ * true 表示 Channel 已注册到 EventLoop 上
+ * false 表示 Channel 未注册到 EventLoop 上
+ */
+boolean isRegistered();
+
+/**
+ * Return {@code true} if the {@link Channel} is active and so connected.
+ *
+ * Channel 是否激活
+ *
+ * 对于服务端 ServerSocketChannel ，true 表示 Channel 已经绑定到端口上，可提供服务
+ * 对于客户端 SocketChannel ，true 表示 Channel 连接到远程服务器
+ */
+boolean isActive();
+
+/**
+ * Returns {@code true} if and only if the I/O thread will perform the
+ * requested write operation immediately.  Any write requests made when
+ * this method returns {@code false} are queued until the I/O thread is
+ * ready to process the queued write requests.
+ *
+ * Channel 是否可写
+ *
+ * 当 Channel 的写缓存区 outbound 非 null 且可写时，返回 true
+ */
+boolean isWritable();
+/**
+ * 获得距离不可写还有多少字节数
+ * 
+ * Get how many bytes can be written until {@link #isWritable()} returns {@code false}.
+ * This quantity will always be non-negative. If {@link #isWritable()} is {@code false} then 0.
+ */
+long bytesBeforeUnwritable();
+/**
+ * 获得距离可写还要多少字节数
+ * 
+ * Get how many bytes must be drained from underlying buffers until {@link #isWritable()} returns {@code true}.
+ * This quantity will always be non-negative. If {@link #isWritable()} is {@code true} then 0.
+ */
+long bytesBeforeWritable();
+```
+
+一个**正常结束**的 Channel 状态转移有**两**种情况：
+
+- 服务端用于绑定( bind )的 Channel 、或者客户端发起连接( connect )的 Channel 。
+
+  ```
+  REGISTERED -> CONNECT/BIND -> ACTIVE -> CLOSE -> INACTIVE -> UNREGISTERED
+  ```
+
+- 服务端接受( accept )客户端的 Channel 。
+
+  ```
+  REGISTERED -> ACTIVE -> CLOSE -> INACTIVE -> UNREGISTERED
+  ```
+
+一个**异常关闭**的 Channel 状态转移不符合上面的。
+
+## 2.3 IO 操作
+
+```
+@Override
+Channel read();
+
+@Override
+Channel flush();
+```
+
+- 这两个方法，继承自 ChannelOutboundInvoker 接口。实际还有如下几个：
+
+  ```
+  ChannelFuture bind(SocketAddress localAddress);
+  ChannelFuture connect(SocketAddress remoteAddress);
+  ChannelFuture connect(SocketAddress remoteAddress, SocketAddress localAddress);
+  ChannelFuture disconnect();
+  ChannelFuture close();
+  ChannelFuture deregister();
+  ChannelFuture bind(SocketAddress localAddress, ChannelPromise promise);
+  ChannelFuture connect(SocketAddress remoteAddress, ChannelPromise promise);
+  ChannelFuture connect(SocketAddress remoteAddress, SocketAddress localAddress, ChannelPromise promise);
+  ChannelFuture disconnect(ChannelPromise promise);
+  ChannelFuture close(ChannelPromise promise);
+  ChannelFuture deregister(ChannelPromise promise);
+  ChannelOutboundInvoker read();
+  ChannelFuture write(Object msg);
+  ChannelFuture write(Object msg, ChannelPromise promise);
+  ChannelOutboundInvoker flush();
+  ChannelFuture writeAndFlush(Object msg, ChannelPromise promise);
+  ChannelFuture writeAndFlush(Object msg);
+  ```
+
+- 对比下来，我们会发现 Channel 重写 ChannelOutboundInvoker 这两个接口的原因是：将返回值从 ChannelOutboundInvoker 修改成 Channel 。
+
+- 我们看到除了 `#read()` 和 `#flush()` 方法，其它方法的返回值的类型都是 ChannelFuture ，这表明这些操作是**异步** IO 的过程。
+
+## 2.4 异步结果 Future
+
+```
+/**
+ * Returns the {@link ChannelFuture} which will be notified when this
+ * channel is closed.  This method always returns the same future instance.
+ *
+ * Channel 关闭的 Future 对象
+ */
+ChannelFuture closeFuture();
+```
+
+- 除了自定义的 `#closeFuture()` 方法，也从 ChannelOutboundInvoker 接口继承了几个接口方法：
+
+  ```
+  ChannelPromise newPromise();
+  ChannelProgressivePromise newProgressivePromise();
+  
+  ChannelFuture newSucceededFuture();
+  ChannelFuture newFailedFuture(Throwable cause);
+  
+  ChannelPromise voidPromise();
+  ```
+
+  - 通过这些接口方法，可创建或获得和该 Channel 相关的 Future / Promise 对象。
+
+## 2.5 类图
+
+Channel 的子接口和实现类如下图：
+
+[![Channel 的子接口和实现类](http://static.iocoder.cn/images/Netty/2018_07_01/01.png)](http://static.iocoder.cn/images/Netty/2018_07_01/01.png)Channel 的子接口和实现类
+
+- 本图包含了 NIO、OIO、Local、Embedded 四种 Channel 实现类。说明如下：[![Channel 四种 Channel 实现类的说明](http://static.iocoder.cn/images/Netty/2018_07_01/02.png)](http://static.iocoder.cn/images/Netty/2018_07_01/02.png)Channel 四种 Channel 实现类的说明
+- 本系列仅分享 NIO 部分，所以裁剪类图如下：[![NIO Channel 类图](27-Netty 源码解析-Channel（一）之简介.assets/03.png)](http://static.iocoder.cn/images/Netty/2018_07_01/03.png)NIO Channel 类图
+
+# 3. Unsafe
+
+Unsafe **接口**，定义在在 `io.netty.channel.Channel` 内部，和 Channel 的操作**紧密结合**，下文我们将看到。
+
+Unsafe 直译中文为“不安全”，就是告诉我们，**无需**且**不必要**在我们使用 Netty 的代码中，**不能直接**调用 Unsafe 相关的方法。Netty 注释说明如下：
+
+```
+/**
+ * <em>Unsafe</em> operations that should <em>never</em> be called from user-code. 
+ * 
+ * These methods are only provided to implement the actual transport, and must be invoked from an I/O thread except for the
+ * following methods:
+ * <ul>
+ *   <li>{@link #localAddress()}</li>
+ *   <li>{@link #remoteAddress()}</li>
+ *   <li>{@link #closeForcibly()}</li>
+ *   <li>{@link #register(EventLoop, ChannelPromise)}</li>
+ *   <li>{@link #deregister(ChannelPromise)}</li>
+ *   <li>{@link #voidPromise()}</li>
+ * </ul>
+ */
+```
+
+😈 当然，对于我们想要了解 Netty 内部实现的胖友，那必须开扒它的代码实现落。因为它和 Channel 密切相关，所以我们也对它的接口做下分类。
+
+## 3.1 基础查询
+
+```
+/**
+ * Return the assigned {@link RecvByteBufAllocator.Handle} which will be used to allocate {@link ByteBuf}'s when
+ * receiving data.
+ *
+ * ByteBuf 分配器的处理器
+ */
+RecvByteBufAllocator.Handle recvBufAllocHandle();
+
+/**
+ * Return the {@link SocketAddress} to which is bound local or
+ * {@code null} if none.
+ *
+ * 本地地址
+ */
+SocketAddress localAddress();
+
+/**
+ * Return the {@link SocketAddress} to which is bound remote or
+ * {@code null} if none is bound yet.
+ *
+ * 远端地址
+ */
+SocketAddress remoteAddress();
+```
+
+## 3.2 状态查询
+
+无 😈
+
+## 3.3 IO 操作
+
+```
+void register(EventLoop eventLoop, ChannelPromise promise);
+void bind(SocketAddress localAddress, ChannelPromise promise);
+void connect(SocketAddress remoteAddress, SocketAddress localAddress, ChannelPromise promise);
+void disconnect(ChannelPromise promise);
+void close(ChannelPromise promise);
+void closeForcibly();
+void deregister(ChannelPromise promise);
+void beginRead();
+void write(Object msg, ChannelPromise promise);
+void flush();
+
+/**
+ * Returns the {@link ChannelOutboundBuffer} of the {@link Channel} where the pending write requests are stored.
+ */
+ChannelOutboundBuffer outboundBuffer();
+```
+
+## 3.4 异步结果 Future
+
+```
+/**
+ * Return a special ChannelPromise which can be reused and passed to the operations in {@link Unsafe}.
+ * It will never be notified of a success or error and so is only a placeholder for operations
+ * that take a {@link ChannelPromise} as argument but for which you not want to get notified.
+ */
+ChannelPromise voidPromise();
+```
+
+## 3.5 类图
+
+Unsafe 的子接口和实现类如下图：
+
+[![Unsafe 的子接口和实现类](27-Netty 源码解析-Channel（一）之简介.assets/04.png)](http://static.iocoder.cn/images/Netty/2018_07_01/04.png)Unsafe 的子接口和实现类
+
+- 已经经过裁剪，仅保留 NIO Channel 相关的 Unsafe 的子接口和实现类部分。
+- 我们会发现，对于 Channel 和 Unsafe 来说，类名中包含 Byte 是属于客户端的，Message 是属于服务端的。
+
+# 4. ChanelId
+
+`io.netty.channel.ChannelId` 实现 Serializable、Comparable 接口，Channel 编号接口。代码如下：
+
+```
+public interface ChannelId extends Serializable, Comparable<ChannelId> {
+
+    /**
+     * Returns the short but globally non-unique string representation of the {@link ChannelId}.
+     *
+     * 全局非唯一
+     */
+    String asShortText();
+
+    /**
+     * Returns the long yet globally unique string representation of the {@link ChannelId}.
+     *
+     * 全局唯一
+     */
+    String asLongText();
+
+}
+```
+
+- `#asShortText()` 方法，返回的编号，短，但是全局非唯一。
+- `#asLongText()` 方法，返回的编号，长，但是全局唯一。
+
+ChanelId 的**默认**实现类为 `io.netty.channel.DefaultChannelId` ，我们主要看看它是如何生成 Channel 的**两种**编号的。代码如下：
+
+```
+@Override
+public String asShortText() {
+    String shortValue = this.shortValue;
+    if (shortValue == null) {
+        this.shortValue = shortValue = ByteBufUtil.hexDump(data, data.length - RANDOM_LEN, RANDOM_LEN);
+    }
+    return shortValue;
+}
+
+@Override
+public String asLongText() {
+    String longValue = this.longValue;
+    if (longValue == null) {
+        this.longValue = longValue = newLongValue();
+    }
+    return longValue;
+}
+```
+
+- 对于 `#asShortText()` 方法，仅使用最后 4 字节的随机数字，并转换成 16 进制的数字字符串。也因此，短，但是全局非唯一。
+
+- 对于 `#asLongText()` 方法，通过调用 `#newLongValue()` 方法生成。代码如下：
+
+  ```
+  private String newLongValue() {
+      StringBuilder buf = new StringBuilder(2 * data.length + 5); // + 5 的原因是有 5 个 '-'
+      int i = 0;
+      i = appendHexDumpField(buf, i, MACHINE_ID.length); // MAC 地址。
+      i = appendHexDumpField(buf, i, PROCESS_ID_LEN); // 进程 ID 。4 字节。
+      i = appendHexDumpField(buf, i, SEQUENCE_LEN); // 32 位数字，顺序增长。4 字节。
+      i = appendHexDumpField(buf, i, TIMESTAMP_LEN); // 时间戳。8 字节。
+      i = appendHexDumpField(buf, i, RANDOM_LEN); // 32 位数字，随机。4 字节。
+      assert i == data.length;
+      return buf.substring(0, buf.length() - 1);
+  }
+  
+  private int appendHexDumpField(StringBuilder buf, int i, int length) {
+      buf.append(ByteBufUtil.hexDump(data, i, length));
+      buf.append('-');
+      i += length;
+      return i;
+  }
+  ```
+
+  - 具体的生成规则，见代码。最终也是 16 进制的数字。也因此，长，但是全局唯一。
+
+# 5. ChannelConfig
+
+`io.netty.channel.ChannelConfig` ，Channel 配置接口。代码如下：
+
+```
+Map<ChannelOption<?>, Object> getOptions();
+<T> T getOption(ChannelOption<T> option);
+boolean setOptions(Map<ChannelOption<?>, ?> options);
+<T> boolean setOption(ChannelOption<T> option, T value);
+
+int getConnectTimeoutMillis();
+ChannelConfig setConnectTimeoutMillis(int connectTimeoutMillis);
+
+@Deprecated
+int getMaxMessagesPerRead();
+@Deprecated
+ChannelConfig setMaxMessagesPerRead(int maxMessagesPerRead);
+
+int getWriteSpinCount();
+ChannelConfig setWriteSpinCount(int writeSpinCount);
+
+ByteBufAllocator getAllocator();
+ChannelConfig setAllocator(ByteBufAllocator allocator);
+
+<T extends RecvByteBufAllocator> T getRecvByteBufAllocator();
+ChannelConfig setRecvByteBufAllocator(RecvByteBufAllocator allocator);
+
+boolean isAutoRead();
+ChannelConfig setAutoRead(boolean autoRead);
+
+boolean isAutoClose();
+ChannelConfig setAutoClose(boolean autoClose);
+
+int getWriteBufferHighWaterMark();
+ChannelConfig setWriteBufferHighWaterMark(int writeBufferHighWaterMark);
+
+int getWriteBufferLowWaterMark();
+ChannelConfig setWriteBufferLowWaterMark(int writeBufferLowWaterMark);
+
+MessageSizeEstimator getMessageSizeEstimator();
+ChannelConfig setMessageSizeEstimator(MessageSizeEstimator estimator);
+
+WriteBufferWaterMark getWriteBufferWaterMark();
+ChannelConfig setWriteBufferWaterMark(WriteBufferWaterMark writeBufferWaterMark);
+```
+
+- 调用 `#setOption(ChannelOption<T> option, T value)` 方法时，会调用相应的 `#setXXX(...)` 方法。代码如下：
+
+  ```
+  // DefaultChannelConfig.java
+  
+  @Override
+  @SuppressWarnings("deprecation")
+  public <T> boolean setOption(ChannelOption<T> option, T value) {
+      validate(option, value);
+  
+      if (option == CONNECT_TIMEOUT_MILLIS) {
+          setConnectTimeoutMillis((Integer) value);
+      } else if (option == MAX_MESSAGES_PER_READ) {
+          setMaxMessagesPerRead((Integer) value);
+      } else if (option == WRITE_SPIN_COUNT) {
+          setWriteSpinCount((Integer) value);
+      } else if (option == ALLOCATOR) {
+          setAllocator((ByteBufAllocator) value);
+      } else if (option == RCVBUF_ALLOCATOR) {
+          setRecvByteBufAllocator((RecvByteBufAllocator) value);
+      } else if (option == AUTO_READ) {
+          setAutoRead((Boolean) value);
+      } else if (option == AUTO_CLOSE) {
+          setAutoClose((Boolean) value);
+      } else if (option == WRITE_BUFFER_HIGH_WATER_MARK) {
+          setWriteBufferHighWaterMark((Integer) value);
+      } else if (option == WRITE_BUFFER_LOW_WATER_MARK) {
+          setWriteBufferLowWaterMark((Integer) value);
+      } else if (option == WRITE_BUFFER_WATER_MARK) {
+          setWriteBufferWaterMark((WriteBufferWaterMark) value);
+      } else if (option == MESSAGE_SIZE_ESTIMATOR) {
+          setMessageSizeEstimator((MessageSizeEstimator) value);
+      } else if (option == SINGLE_EVENTEXECUTOR_PER_GROUP) {
+          setPinEventExecutorPerGroup((Boolean) value);
+      } else {
+          return false;
+      }
+  }
+  ```
+
+- ChannelConfig 的配置项 `io.netty.channel.ChannelOption` 很多，胖友可以看下 [《Netty：option 和 childOption 参数设置说明》](https://www.jianshu.com/p/0bff7c020af2) ，了解感兴趣的配置项。
+
+## 5.1 类图
+
+ChannelConfig 的子接口和实现类如下图：
+
+[![ChannelConfig 的子接口和实现类](27-Netty 源码解析-Channel（一）之简介.assets/05.png)](http://static.iocoder.cn/images/Netty/2018_07_01/05.png)ChannelConfig 的子接口和实现类
+
+- 已经经过裁剪，仅保留 NIO Channel 相关的 ChannelConfig 的子接口和实现类部分。
+
+# 666. 彩蛋
+
+正如文头所说，在前面的文章中，我们已经不断看到 Netty Channel 的身影，例如：
+
+- 在 [《精尽 Netty 源码分析 —— 启动（一）之服务端》](http://svip.iocoder.cn/Netty/bootstrap-1-server/) 中，我们看了服务端 NioServerSocketChannel **bind** 的过程。
+- 在 [《精尽 Netty 源码分析 —— 启动（二）之客户端》](http://svip.iocoder.cn/Netty/bootstrap-2-client/) 中，我们看了客户端 NioSocketChannel **connect** 的过程。
+
+在后续的文章中，我们会分享 Netty NIO Channel 的其他操作，😈 一篇一个操作。
+
+------
+
+推荐阅读文章：
+
+- Hypercube [《自顶向下深入分析 Netty（六）–Channel总述》](https://www.jianshu.com/p/fffc18d33159)
\ No newline at end of file
diff --git a/netty/28-Netty 源码解析-Channel（三）之 read 操作.md b/netty/28-Netty 源码解析-Channel（三）之 read 操作.md
new file mode 100644
index 0000000..4251b50
--- /dev/null
+++ b/netty/28-Netty 源码解析-Channel（三）之 read 操作.md	
@@ -0,0 +1,486 @@
+# 精尽 Netty 源码解析 —— Channel（三）之 read 操作
+
+# 1. 概述
+
+本文分享 Netty NIO 服务端读取( **read** )来自客户端数据的过程、和 Netty NIO 客户端接收( **read** )来自服务端数据的结果。实际上，这两者的实现逻辑是一致的：
+
+- 客户端就不用说了，自身就使用了 Netty NioSocketChannel 。
+- 服务端在接受客户端连接请求后，会创建客户端对应的 Netty NioSocketChannel 。
+
+因此，我们统一叫做 NioSocketChannel 读取( **read** )对端的数据的过程。
+
+------
+
+NioSocketChannel 读取( **read** )对端的数据的过程，简单来说：
+
+1. NioSocketChannel 所在的 EventLoop 线程轮询是否有新的数据写入。
+2. 当轮询到有新的数据写入，NioSocketChannel 读取数据，并提交到 pipeline 中进行处理。
+
+比较简单，和 [《精尽 Netty 源码解析 —— Channel（二）之 accept 操作》](http://svip.iocoder.cn/Netty/Channel-2-accept) 有几分相似。或者我们可以说：
+
+- NioServerSocketChannel 读取新的连接。
+- NioSocketChannel 读取新的数据。
+
+# 2. NioByteUnsafe#read
+
+NioByteUnsafe ，实现 AbstractNioUnsafe 抽象类，AbstractNioByteChannel 的 Unsafe 实现类。代码如下：
+
+```
+protected class NioByteUnsafe extends AbstractNioUnsafe {
+
+    public final void read() { /** 省略内部实现 **/ }
+
+    private void handleReadException(ChannelPipeline pipeline, ByteBuf byteBuf, Throwable cause, boolean close, RecvByteBufAllocator.Handle allocHandle) { /** 省略内部实现 **/ }
+
+    private void closeOnRead(ChannelPipeline pipeline) { /** 省略内部实现 **/ }
+
+}
+```
+
+- 一共有 3 个方法。但是实现上，入口为 `#read()` 方法，而另外 2 个方法被它所调用。所以，我们赶紧开始 `#read()` 方法的理解吧。
+
+## 2.1 read
+
+在 NioEventLoop 的 `#processSelectedKey(SelectionKey k, AbstractNioChannel ch)` 方法中，我们会看到这样一段代码：
+
+```
+// SelectionKey.OP_READ 或 SelectionKey.OP_ACCEPT 就绪
+// readyOps == 0 是对 JDK Bug 的处理，防止空的死循环
+// Also check for readOps of 0 to workaround possible JDK bug which may otherwise lead
+// to a spin loop
+if ((readyOps & (SelectionKey.OP_READ | SelectionKey.OP_ACCEPT)) != 0 || readyOps == 0) {
+    unsafe.read();
+}
+```
+
+- 当 `(readyOps & SelectionKey.OP_READ) != 0` 时，这就是 NioSocketChannel 所在的 EventLoop 的线程**轮询到**有新的数据写入。
+- 然后，调用 `NioByteUnsafe#read()` 方法，读取新的写入数据。
+
+------
+
+`NioByteUnsafe#read()` 方法，读取新的写入数据。代码如下：
+
+```
+ 1: @Override
+ 2: @SuppressWarnings("Duplicates")
+ 3: public final void read() {
+ 4:     final ChannelConfig config = config();
+ 5:     // 若 inputClosedSeenErrorOnRead = true ，移除对 SelectionKey.OP_READ 事件的感兴趣。
+ 6:     if (shouldBreakReadReady(config)) {
+ 7:         clearReadPending();
+ 8:         return;
+ 9:     }
+10:     final ChannelPipeline pipeline = pipeline();
+11:     final ByteBufAllocator allocator = config.getAllocator();
+12:     // 获得 RecvByteBufAllocator.Handle 对象
+13:     final RecvByteBufAllocator.Handle allocHandle = recvBufAllocHandle();
+14:     // 重置 RecvByteBufAllocator.Handle 对象
+15:     allocHandle.reset(config);
+16: 
+17:     ByteBuf byteBuf = null;
+18:     boolean close = false; // 是否关闭连接
+19:     try {
+20:         do {
+21:             // 申请 ByteBuf 对象
+22:             byteBuf = allocHandle.allocate(allocator);
+23:             // 读取数据
+24:             // 设置最后读取字节数
+25:             allocHandle.lastBytesRead(doReadBytes(byteBuf));
+26:             // <1> 未读取到数据
+27:             if (allocHandle.lastBytesRead() <= 0) {
+28:                 // 释放 ByteBuf 对象
+29:                 // nothing was read. release the buffer.
+30:                 byteBuf.release();
+31:                 // 置空 ByteBuf 对象
+32:                 byteBuf = null;
+33:                 // 如果最后读取的字节为小于 0 ，说明对端已经关闭
+34:                 close = allocHandle.lastBytesRead() < 0;
+35:                 // TODO
+36:                 if (close) {
+37:                     // There is nothing left to read as we received an EOF.
+38:                     readPending = false;
+39:                 }
+40:                 // 结束循环
+41:                 break;
+42:             }
+43: 
+44:             // <2> 读取到数据
+45: 
+46:             // 读取消息数量 + localRead
+47:             allocHandle.incMessagesRead(1);
+48:             // TODO 芋艿 readPending
+49:             readPending = false;
+50:             // 触发 Channel read 事件到 pipeline 中。 TODO
+51:             pipeline.fireChannelRead(byteBuf);
+52:             // 置空 ByteBuf 对象
+53:             byteBuf = null;
+54:         } while (allocHandle.continueReading()); // 循环判断是否继续读取
+55: 
+56:         // 读取完成
+57:         allocHandle.readComplete();
+58:         // 触发 Channel readComplete 事件到 pipeline 中。
+59:         pipeline.fireChannelReadComplete();
+60: 
+61:         // 关闭客户端的连接
+62:         if (close) {
+63:             closeOnRead(pipeline);
+64:         }
+65:     } catch (Throwable t) {
+66:         handleReadException(pipeline, byteBuf, t, close, allocHandle);
+67:     } finally {
+68:         // TODO 芋艿 readPending
+69:         // Check if there is a readPending which was not processed yet.
+70:         // This could be for two reasons:
+71:         // * The user called Channel.read() or ChannelHandlerContext.read() in channelRead(...) method
+72:         // * The user called Channel.read() or ChannelHandlerContext.read() in channelReadComplete(...) method
+73:         //
+74:         // See https://github.com/netty/netty/issues/2254
+75:         if (!readPending && !config.isAutoRead()) {
+76:             removeReadOp();
+77:         }
+78:     }
+79: }
+```
+
+- 第 5 至 9 行：若 inputClosedSeenErrorOnRead = true ，移除对 SelectionKey.OP_READ 事件的感兴趣。详细解析，见 [《精尽 Netty 源码解析 —— Channel（七）之 close 操作》](http://svip.iocoder.cn/Netty/Channel-7-close/) 的 [「5. 服务端处理客户端主动关闭连接」](https://svip.iocoder.cn/Netty/Channel-3-read/#) 小节。
+
+- 第 12 至 15 行：获得 RecvByteBufAllocator.Handle 对象，并重置它。这里的逻辑，和 `NioMessageUnsafe#read()` 方法的【第 14 至 17 行】的代码是一致的。相关的解析，见 [《精尽 Netty 源码解析 —— Channel（二）之 accept 操作》](http://svip.iocoder.cn/Netty/Channel-2-accept) 。
+
+- 第 20 至 64 行：**while 循环** 读取新的写入数据。
+
+  - 第 22 行：调用 `RecvByteBufAllocator.Handle#allocate(ByteBufAllocator allocator)` 方法，申请 ByteBuf 对象。关于它的内容，我们放在 ByteBuf 相关的文章，详细解析。
+
+  - 第 25 行：调用 `AbstractNioByteChannel#doReadBytes(ByteBuf buf)` 方法，读取数据。详细解析，胖友先跳到 [「3. AbstractNioMessageChannel#doReadMessages」](https://svip.iocoder.cn/Netty/Channel-3-read/#) 中，看完记得回到此处。
+
+  - 第 25 行：调用 `RecvByteBufAllocator.Handle#lastBytesRead(int bytes)` 方法，设置**最后**读取字节数。代码如下：
+
+    ```
+    // AdaptiveRecvByteBufAllocator.HandleImpl.java
+    @Override
+    public void lastBytesRead(int bytes) {
+        // If we read as much as we asked for we should check if we need to ramp up the size of our next guess.
+        // This helps adjust more quickly when large amounts of data is pending and can avoid going back to
+        // the selector to check for more data. Going back to the selector can add significant latency for large
+        // data transfers.
+        if (bytes == attemptedBytesRead()) {
+            record(bytes);
+        }
+        super.lastBytesRead(bytes);
+    }
+    
+    // DefaultMaxMessagesRecvByteBufAllocator.MaxMessageHandle.java
+    @Override
+    public void lastBytesRead(int bytes) {
+        lastBytesRead = bytes; // 设置最后一次读取字节数 <1>
+        if (bytes > 0) {
+            totalBytesRead += bytes; // 总共读取字节数
+        }
+    }
+    ```
+
+    - 代码比较多，我们只看重点，当然也不细讲。
+    - 在 `<1>` 处，设置最后一次读取字节数。
+
+  - 读取有，有两种结果，**是**/**否**读取到数据。
+
+  - `<1>` **未**读取到数据，即 `allocHandle.lastBytesRead() <= 0` 。
+
+  - 第 30 行：调用
+
+     
+
+    ```
+    ByteBuf#release()
+    ```
+
+     
+
+    方法，释放 ByteBuf 对象。
+
+    - 第 32 行：置空 ByteBuf 对象。
+
+  - 第 34 行：如果最后读取的字节为小于 0 ，说明对端已经关闭。
+
+  - 第 35 至 39 行：TODO 芋艿 细节
+
+  - 第 41 行：`break` 结束循环。
+
+  - `<2>` **有**读取到数据，即 `allocHandle.lastBytesRead() > 0` 。
+
+  - 第 47 行：调用 `AdaptiveRecvByteBufAllocator.HandleImpl#incMessagesRead(int amt)` 方法，读取消息( 客户端 )数量 + `localRead = 1` 。
+
+  - 第 49 行：TODO 芋艿 readPending
+
+  - 第 51 行：调用 `ChannelPipeline#fireChannelRead(Object msg)` 方法，触发 Channel read 事件到 pipeline 中。
+
+    - **注意**，一般情况下，我们会在自己的 Netty 应用程序中，自定义 ChannelHandler 处理读取到的数据。😈 当然，此时读取的数据，大多数情况下是需要在解码( Decode )。关于这一块，在后续关于 Codec ( 编解码 )的文章中，详细解析。
+
+    - 如果没有自定义 ChannelHandler 进行处理，最终会被 pipeline 中的尾节点 TailContext 所处理。代码如下：
+
+      ```
+      // TailContext.java
+      @Override
+      public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
+          onUnhandledInboundMessage(msg);
+      }
+      
+      // DefaultChannelPipeline.java
+      protected void onUnhandledInboundMessage(Object msg) {
+          try {
+              logger.debug("Discarded inbound message {} that reached at the tail of the pipeline. " + "Please check your pipeline configuration.", msg);
+          } finally {
+              ReferenceCountUtil.release(msg);
+          }
+      }
+      ```
+
+      - 最终也会**释放** ByteBuf 对象。这就是为什么【第 53 行】的代码，只去置空 ByteBuf 对象，而不用再去释放的原因。
+
+  - 第 53 行：置空 ByteBuf 对象。
+
+  - 第 54 行：调用 `AdaptiveRecvByteBufAllocator.HandleImpl#incMessagesRead(int amt)#continueReading()` 方法，判断是否循环是否继续，读取新的数据。代码如下：
+
+    ```
+    // DefaultMaxMessagesRecvByteBufAllocator.MaxMessageHandle.java
+    private final UncheckedBooleanSupplier defaultMaybeMoreSupplier = new UncheckedBooleanSupplier() {
+        @Override
+        public boolean get() {
+            return attemptedBytesRead == lastBytesRead; // 最后读取的字节数，是否等于，最大可写入的字节数
+        }
+    };
+    
+    @Override
+    public boolean continueReading() {
+        return continueReading(defaultMaybeMoreSupplier);
+    }
+    
+    @Override
+    public boolean continueReading(UncheckedBooleanSupplier maybeMoreDataSupplier) {
+        return config.isAutoRead() &&
+               (!respectMaybeMoreData || maybeMoreDataSupplier.get()) && // <1>
+               totalMessages < maxMessagePerRead &&
+               totalBytesRead > 0;
+    }
+    ```
+
+    - 一般情况下，最后读取的字节数，**不等于**最大可写入的字节数，即 `<1>` 处的代码 `UncheckedBooleanSupplier#get()` 返回 `false` ，则不再进行数据读取。因为 😈 也没有数据可以读取啦。
+
+- 第 57 行：调用 `RecvByteBufAllocator.Handle#readComplete()` 方法，读取完成。暂无重要的逻辑，不详细解析。
+
+- 第 59 行：调用 `ChannelPipeline#fireChannelReadComplete()` 方法，触发 Channel readComplete 事件到 pipeline 中。
+
+  - *如果有需要，胖友可以自定义处理器，处理该事件。一般情况下，不需要*。
+
+  - 如果没有自定义 ChannelHandler 进行处理，最终会被 pipeline 中的尾节点 TailContext 所处理。代码如下：
+
+    ```
+    // TailContext.java
+    @Override
+    public void channelReadComplete(ChannelHandlerContext ctx) throws Exception {
+        onUnhandledInboundChannelReadComplete();
+    }
+    
+    // DefaultChannelPipeline.java
+    protected void onUnhandledInboundChannelReadComplete() {
+    }
+    ```
+
+    - 具体的调用是**空方法**。
+
+- 第 61 至 64 行：关闭客户端的连接。详细解析，见 [《精尽 Netty 源码解析 —— Channel（七）之 close 操作》](http://svip.iocoder.cn/Netty/Channel-7-close/) 的 [「5. 服务端处理客户端主动关闭连接」](https://svip.iocoder.cn/Netty/Channel-3-read/#) 小节。
+
+- 第 65 至 66 行：当发生异常时，调用 `#handleReadException(hannelPipeline pipeline, ByteBuf byteBuf, Throwable cause, boolean close, RecvByteBufAllocator.Handle allocHandle)` 方法，处理异常。详细解析，见 [「2.2 handleReadException」](https://svip.iocoder.cn/Netty/Channel-3-read/#) 中。
+
+- 第 67 至 78 行：TODO 芋艿 细节
+
+## 2.2 handleReadException
+
+`#handleReadException(hannelPipeline pipeline, ByteBuf byteBuf, Throwable cause, boolean close, RecvByteBufAllocator.Handle allocHandle)` 方法，处理异常。代码如下：
+
+```
+ 1: private void handleReadException(ChannelPipeline pipeline, ByteBuf byteBuf, Throwable cause, boolean close, RecvByteBufAllocator.Handle allocHandle) {
+ 2:     if (byteBuf != null) {
+ 3:         if (byteBuf.isReadable()) {
+ 4:             // TODO 芋艿 细节
+ 5:             readPending = false;
+ 6:             // 触发 Channel read 事件到 pipeline 中。
+ 7:             pipeline.fireChannelRead(byteBuf);
+ 8:         } else {
+ 9:             // 释放 ByteBuf 对象
+10:             byteBuf.release();
+11:         }
+12:     }
+13:     // 读取完成
+14:     allocHandle.readComplete();
+15:     // 触发 Channel readComplete 事件到 pipeline 中。
+16:     pipeline.fireChannelReadComplete();
+17:     // 触发 exceptionCaught 事件到 pipeline 中。
+18:     pipeline.fireExceptionCaught(cause);
+19:     // // TODO 芋艿 细节
+20:     if (close || cause instanceof IOException) {
+21:         closeOnRead(pipeline);
+22:     }
+23: }
+```
+
+- 第 2 行：`byteBuf` 非空，说明在发生异常之前，至少申请 ByteBuf 对象是**成功**的。
+
+  - 第 3 行：调用 `ByteBuf#isReadable()` 方法，判断 ByteBuf 对象是否可读，即剩余可读的字节数据。
+
+    - 该方法的英文注释如下：
+
+      ```
+      /**
+       * Returns {@code true}
+       * if and only if {@code (this.writerIndex - this.readerIndex)} is greater
+       * than {@code 0}.
+       */
+      public abstract boolean isReadable();
+      ```
+
+      - 即 `this.writerIndex - this.readerIndex > 0` 。
+
+    - 第 5 行：TODO 芋艿 细节
+
+    - 第 7 行：调用 `ChannelPipeline#fireChannelRead(Object msg)` 方法，触发 Channel read 事件到 pipeline 中。
+
+  - 第 8 至 11 行：ByteBuf 对象不可读，所以调用 `ByteBuf#release()` 方法，释放 ByteBuf 对象。
+
+- 第 14 行：调用 `RecvByteBufAllocator.Handle#readComplete()` 方法，读取完成。暂无重要的逻辑，不详细解析。
+
+- 第 16 行：调用 `ChannelPipeline#fireChannelReadComplete()` 方法，触发 Channel readComplete 事件到 pipeline 中。
+
+- 第 18 行：调用 `ChannelPipeline#fireExceptionCaught(Throwable)` 方法，触发 exceptionCaught 事件到 pipeline 中。
+
+  - **注意**，一般情况下，我们会在自己的 Netty 应用程序中，自定义 ChannelHandler 处理异常。
+
+  - 如果没有自定义 ChannelHandler 进行处理，最终会被 pipeline 中的尾节点 TailContext 所处理。代码如下：
+
+    ```
+    // TailContext.java
+    @Override
+    public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
+        onUnhandledInboundException(cause);
+    }
+    
+    // DefaultChannelPipeline.java
+    protected void onUnhandledInboundException(Throwable cause) {
+        try {
+            logger.warn("An exceptionCaught() event was fired, and it reached at the tail of the pipeline. " +
+                            "It usually means the last handler in the pipeline did not handle the exception.",
+                    cause);
+        } finally {
+            ReferenceCountUtil.release(cause);
+        }
+    }
+    ```
+
+    - 打印**告警**日志。
+    - 调用 `ReferenceCountUtil#release(Object msg)` 方法，释放和异常相关的资源。
+
+- 第 19 至 22 行：TODO 芋艿，细节
+
+## 2.3 closeOnRead
+
+TODO 芋艿，细节
+
+# 3. AbstractNioByteChannel#doReadBytes
+
+`doReadBytes(ByteBuf buf)` **抽象**方法，读取写入的数据到方法参数 `buf` 中。它是一个**抽象**方法，定义在 AbstractNioByteChannel 抽象类中。代码如下：
+
+```
+/**
+ * Read bytes into the given {@link ByteBuf} and return the amount.
+ */
+protected abstract int doReadBytes(ByteBuf buf) throws Exception;
+```
+
+- 返回值为读取到的字节数。
+- **当返回值小于 0 时，表示对端已经关闭**。
+
+NioSocketChannel 对该方法的实现代码如下：
+
+```
+1: @Override
+2: protected int doReadBytes(ByteBuf byteBuf) throws Exception {
+3:     // 获得 RecvByteBufAllocator.Handle 对象
+4:     final RecvByteBufAllocator.Handle allocHandle = unsafe().recvBufAllocHandle();
+5:     // 设置最大可读取字节数量。因为 ByteBuf 目前最大写入的大小为 byteBuf.writableBytes()
+6:     allocHandle.attemptedBytesRead(byteBuf.writableBytes());
+7:     // 读取数据到 ByteBuf 中
+8:     return byteBuf.writeBytes(javaChannel(), allocHandle.attemptedBytesRead());
+9: }
+```
+
+- 第 4 行：获得 RecvByteBufAllocator.Handle 对象。
+
+  - 第 6 行：设置最大可读取字节数量。因为 ByteBuf 对象**目前**最大可写入的大小为 `ByteBuf#writableBytes()` 的长度。
+
+- 第 8 行：调用 `ByteBuf#writeBytes(ScatteringByteChannel in, int length)` 方法，读取数据到 ByteBuf 对象中。因为 ByteBuf 有多种实现，我们以默认的 PooledUnsafeDirectByteBuf 举例子。代码如下：
+
+  ```
+  // AbstractByteBuf.java
+  @Override
+  public int writeBytes(ScatteringByteChannel in, int length) throws IOException {
+      ensureWritable(length);
+      int writtenBytes = setBytes(writerIndex, in, length); // <1>
+      if (writtenBytes > 0) { // <3>
+          writerIndex += writtenBytes;
+      }
+      return writtenBytes;
+  }
+  
+  // PooledUnsafeDirectByteBuf.java
+  @Override
+  public int setBytes(int index, ScatteringByteChannel in, int length) throws IOException {
+      checkIndex(index, length);
+      ByteBuffer tmpBuf = internalNioBuffer();
+      index = idx(index);
+      tmpBuf.clear().position(index).limit(index + length);
+      try {
+          return in.read(tmpBuf); // <2>
+      } catch (ClosedChannelException ignored) {
+          return -1;
+      }
+  }
+  ```
+
+  - 代码比较多，我们只看重点，当然也不细讲。还是那句话，关于 ByteBuf 的内容，我们在 ByteBuf 相关的文章详细解析。
+
+  - 在 `<1>` 处，会调用 `#setBytes(int index, ScatteringByteChannel in, int length)` 方法。
+
+  - 在
+
+     
+
+    ```
+    <2>
+    ```
+
+     
+
+    处，会调用 Java NIO 的
+
+     
+
+    ```
+    ScatteringByteChannel#read(ByteBuffer)
+    ```
+
+     
+
+    方法，读取
+
+    数据
+
+    到临时的 Java NIO ByteBuffer 中。
+
+    - 在对端未断开时，返回的是读取数据的**字节数**。
+    - 在对端已断开时，返回 `-1` ，表示断开。这也是为什么 `<3>` 处做了 `writtenBytes > 0` 的判断的原因。
+
+# 666. 彩蛋
+
+推荐阅读文章：
+
+- 闪电侠 [《深入浅出 Netty read》](https://www.jianshu.com/p/6b48196b5043)
+- Hypercube [《自顶向下深入分析Netty（六）– Channel源码实现》](https://www.jianshu.com/p/9258af254e1d)
\ No newline at end of file
diff --git a/netty/29-Netty 源码解析-Channel（二）之 accept 操作.md b/netty/29-Netty 源码解析-Channel（二）之 accept 操作.md
new file mode 100644
index 0000000..92c1005
--- /dev/null
+++ b/netty/29-Netty 源码解析-Channel（二）之 accept 操作.md	
@@ -0,0 +1,678 @@
+# 精尽 Netty 源码解析 —— Channel（二）之 accept 操作
+
+# 1. 概述
+
+本文分享 Netty NIO 服务端 NioServerSocketChannel 接受( **accept** )客户端连接的过程。简单来说：
+
+1. 服务端 NioServerSocketChannel 的 boss EventLoop 线程轮询是否有新的客户端连接接入。
+2. 当轮询到有新的连接接入，封装连入的客户端的 SocketChannel 为 Netty NioSocketChannel 对象。
+3. 选择一个服务端 NioServerSocketChannel 的 worker EventLoop ，将客户端的 NioSocketChannel 注册到其上。并且，注册客户端的 NioSocketChannel 的读事件，开始轮询该客户端是否有数据写入。
+
+下面，让我们来看看具体的代码实现。
+
+# 2. NioMessageUnsafe#read
+
+> 老艿艿：有点不知道怎么取标题好，直接用方法名吧。
+
+在 NioEventLoop 的 `#processSelectedKey(SelectionKey k, AbstractNioChannel ch)` 方法中，我们会看到这样一段代码：
+
+```
+// SelectionKey.OP_READ 或 SelectionKey.OP_ACCEPT 就绪
+// readyOps == 0 是对 JDK Bug 的处理，防止空的死循环
+// Also check for readOps of 0 to workaround possible JDK bug which may otherwise lead
+// to a spin loop
+if ((readyOps & (SelectionKey.OP_READ | SelectionKey.OP_ACCEPT)) != 0 || readyOps == 0) {
+    unsafe.read();
+}
+```
+
+- 当 `(readyOps & SelectionKey.OP_ACCEPT) != 0` 时，这就是服务端 NioServerSocketChannel 的 boss EventLoop 线程**轮询到**有新的客户端连接接入。
+- 然后，调用 `NioMessageUnsafe#read()` 方法，“读取”( 😈 这个抽象很灵性 )新的客户端连接连入。
+
+------
+
+`NioMessageUnsafe#read()` 方法，代码如下：
+
+```
+ 1: private final class NioMessageUnsafe extends AbstractNioUnsafe {
+ 2: 
+ 3:     /**
+ 4:      * 新读取的客户端连接数组
+ 5:      */
+ 6:     private final List<Object> readBuf = new ArrayList<Object>();
+ 7: 
+ 8:     @SuppressWarnings("Duplicates")
+ 9:     @Override
+10:     public void read() {
+11:         assert eventLoop().inEventLoop();
+12:         final ChannelConfig config = config();
+13:         final ChannelPipeline pipeline = pipeline();
+14:         // 获得 RecvByteBufAllocator.Handle 对象
+15:         final RecvByteBufAllocator.Handle allocHandle = unsafe().recvBufAllocHandle();
+16:         // 重置 RecvByteBufAllocator.Handle 对象
+17:         allocHandle.reset(config);
+18: 
+19:         boolean closed = false;
+20:         Throwable exception = null;
+21:         try {
+22:             try {
+23:                 do {
+24:                     // 读取客户端的连接到 readBuf 中
+25:                     int localRead = doReadMessages(readBuf);
+26:                     // 无可读取的客户端的连接，结束
+27:                     if (localRead == 0) {
+28:                         break;
+29:                     }
+30:                     // 读取出错
+31:                     if (localRead < 0) {
+32:                         closed = true; // 标记关闭
+33:                         break;
+34:                     }
+35: 
+36:                     // 读取消息数量 + localRead
+37:                     allocHandle.incMessagesRead(localRead);
+38:                 } while (allocHandle.continueReading()); // 循环判断是否继续读取
+39:             } catch (Throwable t) {
+40:                 // 记录异常
+41:                 exception = t;
+42:             }
+43: 
+44:             // 循环 readBuf 数组，触发 Channel read 事件到 pipeline 中。
+45:             int size = readBuf.size();
+46:             for (int i = 0; i < size; i ++) {
+47:                 // TODO 芋艿
+48:                 readPending = false;
+49:                 // 在内部，会通过 ServerBootstrapAcceptor ，将客户端的 Netty NioSocketChannel 注册到 EventLoop 上
+50:                 pipeline.fireChannelRead(readBuf.get(i));
+51:             }
+52:             // 清空 readBuf 数组
+53:             readBuf.clear();
+54:             // 读取完成
+55:             allocHandle.readComplete();
+56:             // 触发 Channel readComplete 事件到 pipeline 中。
+57:             pipeline.fireChannelReadComplete();
+58: 
+59:             // 发生异常
+60:             if (exception != null) {
+61:                 // 判断是否要关闭 TODO 芋艿
+62:                 closed = closeOnReadError(exception);
+63: 
+64:                 // 触发 exceptionCaught 事件到 pipeline 中。
+65:                 pipeline.fireExceptionCaught(exception);
+66:             }
+67: 
+68:             if (closed) {
+69:                 // TODO 芋艿
+70:                 inputShutdown = true;
+71:                 // TODO 芋艿
+72:                 if (isOpen()) {
+73:                     close(voidPromise());
+74:                 }
+75:             }
+76:         } finally {
+77:             // Check if there is a readPending which was not processed yet.
+78:             // This could be for two reasons:
+79:             // * The user called Channel.read() or ChannelHandlerContext.read() in channelRead(...) method
+80:             // * The user called Channel.read() or ChannelHandlerContext.read() in channelReadComplete(...) method
+81:             //
+82:             // See https://github.com/netty/netty/issues/2254
+83:             // TODO 芋艿
+84:             if (!readPending && !config.isAutoRead()) {
+85:                 removeReadOp();
+86:             }
+87:         }
+88:     }
+89: }
+```
+
+- 😈 NioMessageUnsafe 只有一个 `#read()` 方法，而该方法，“读取”新的客户端连接连入。
+
+- 第 15 行：调用 `Unsafe#recvBufAllocHandle()` 方法，获得 获得 RecvByteBufAllocator.Handle 对象。默认情况下，返回的是 AdaptiveRecvByteBufAllocator.HandleImpl 对象。关于它的内容，我们放在 ByteBuf 相关的文章，详细解析。
+
+  - 第 17 行：调用 `DefaultMaxMessagesRecvByteBufAllocator.MaxMessageHandle#reset(ChannelConfig)` 方法，重置 RecvByteBufAllocator.Handle 对象。代码如下：
+
+    ```
+    @Override
+    public void reset(ChannelConfig config) {
+        this.config = config; // 重置 ChannelConfig 对象
+        maxMessagePerRead = maxMessagesPerRead(); // 重置 maxMessagePerRead 属性
+        totalMessages = totalBytesRead = 0; // 重置 totalMessages 和 totalBytesRead 属性
+    }
+    ```
+
+    - 注意，AdaptiveRecvByteBufAllocator.HandleImpl 继承 DefaultMaxMessagesRecvByteBufAllocator.MaxMessageHandle 抽象类。
+
+- 第 22 至 42 行：**while 循环** “读取”新的客户端连接连入。
+
+  - 第 25 行： 调用 `NioServerSocketChannel#doReadMessages(List<Object> buf)` 方法，读取客户端的连接到 `readBuf` 中。详细解析，胖友先跳到 [「3. AbstractNioMessageChannel#doReadMessages」](https://svip.iocoder.cn/Netty/Channel-2-accept/#) 中，看完记得回到此处。
+
+  - 第 25 至 29 行：无可读取的客户端的连接，结束循环。
+
+  - 第 30 至 34 行：读取出错，**标记关闭服务端**，并结束循环。目前我们看到 `NioServerSocketChannel#doReadMessages(List<Object> buf)` 方法的实现，返回的结果只会存在 0 和 1 ，也就是说不会出现这种情况。笔者又去翻了别的实现类，例如 `NioDatagramChannel#doReadMessages(List<Object> buf)` 方法，在发生异常时，会返回 -1 。
+
+  - 第 37 行：调用 `AdaptiveRecvByteBufAllocator.HandleImpl#incMessagesRead(int amt)` 方法，读取消息( 客户端 )数量 + `localRead` 。代码如下：
+
+    ```
+    @Override
+    public final void incMessagesRead(int amt) {
+        totalMessages += amt;
+    }
+    ```
+
+    - 对于 AdaptiveRecvByteBufAllocator.HandleImpl 来说，考虑到**抽象**的需要，所以统一使用“消息”的说法。
+
+  - 第 38 行：调用 `AdaptiveRecvByteBufAllocator.HandleImpl#incMessagesRead(int amt)#continueReading()` 方法，判断是否循环是否继续，读取( 接受 )新的客户端连接。代码如下：
+
+    ```
+    // AdaptiveRecvByteBufAllocator.HandleImpl.java
+    @Override
+    public boolean continueReading() {
+        return continueReading(defaultMaybeMoreSupplier);
+    }
+    
+    // DefaultMaxMessagesRecvByteBufAllocator.MaxMessageHandle.java
+    @Override
+    public boolean continueReading(UncheckedBooleanSupplier maybeMoreDataSupplier) {
+        return config.isAutoRead() &&
+               (!respectMaybeMoreData || maybeMoreDataSupplier.get()) &&
+               totalMessages < maxMessagePerRead &&
+               totalBytesRead > 0; // <1>
+    }
+    ```
+
+    - 因为 `<1>` 处，此时 `totalBytesRead` 等于 0 ，所以会返回 **false** 。因此，循环会结束。也因此，对于 NioServerSocketChannel 来说，**每次只接受一个新的客户端连接**。😈 当然，因为服务端 NioServerSocketChannel 对 `Selectionkey.OP_ACCEPT` 事件感兴趣，所以**后续的新的客户端连接还是会被接受的**。
+
+  - 第 39 至 42 行：读取过程中发生异常，记录该异常到 `exception` 中，同时结束循环。
+
+- 第 44 至 51 行：循环
+
+   
+
+  ```
+  readBuf
+  ```
+
+   
+
+  数组，触发 Channel read 事件到 pipeline 中。
+
+  - 第 48 行：TODO 芋艿 细节
+
+  - 第 50 行：调用
+
+     
+
+    ```
+    ChannelPipeline#fireChannelRead(Object msg)
+    ```
+
+     
+
+    方法，触发 Channel read 事件到 pipeline 中。
+
+    - **注意**，传入的方法参数是新接受的客户端 NioSocketChannel 连接。
+    - 在内部，会通过 ServerBootstrapAcceptor ，将客户端的 Netty NioSocketChannel 注册到 EventLoop 上。详细解析，胖友先跳到 [「4. ServerBootstrapAcceptor」](https://svip.iocoder.cn/Netty/Channel-2-accept/#) 中，看完记得回到此处。
+
+- 第 53 行：清空 `readBuf` 数组。
+
+- 第 55 行：调用 `RecvByteBufAllocator.Handle#readComplete()` 方法，读取完成。暂无重要的逻辑，不详细解析。
+
+- 第 57 行：调用 `ChannelPipeline#fireChannelReadComplete()` 方法，触发 Channel readComplete 事件到 pipeline 中。
+
+  - *如果有需要，胖友可以自定义处理器，处理该事件。一般情况下，不需要*。
+
+  - 如果没有自定义 ChannelHandler 进行处理，最终会被 pipeline 中的尾节点 TailContext 所处理。代码如下：
+
+    ```
+    // TailContext.java
+    @Override
+    public void channelReadComplete(ChannelHandlerContext ctx) throws Exception {
+        onUnhandledInboundChannelReadComplete();
+    }
+    
+    // DefaultChannelPipeline.java
+    protected void onUnhandledInboundChannelReadComplete() {
+    }
+    ```
+
+    - 具体的调用是**空方法**。
+
+- 第 60 至 66 行：
+
+  ```
+  exception
+  ```
+
+   
+
+  非空，说明在接受连接过程中发生异常。
+
+  - 第 62 行：TODO 芋艿 细节
+
+  - 第 65 行： 调用
+
+     
+
+    ```
+    ChannelPipeline#fireExceptionCaught(Throwable)
+    ```
+
+     
+
+    方法，触发 exceptionCaught 事件到 pipeline 中。
+
+    - 默认情况下，会使用 ServerBootstrapAcceptor 处理该事件。详细解析，见 [「4.3 exceptionCaught」](https://svip.iocoder.cn/Netty/Channel-2-accept/#) 。
+    - *如果有需要，胖友可以自定义处理器，处理该事件。一般情况下，不需要*。
+
+- 第 68 至 75 行：TODO 芋艿 细节
+
+- 第 76 至 87 行：TODO 芋艿 细节
+
+# 3. AbstractNioMessageChannel#doReadMessages
+
+`doReadMessages(List<Object> buf)` **抽象**方法，读取客户端的连接到方法参数 `buf` 中。它是一个**抽象**方法，定义在 AbstractNioMessageChannel 抽象类中。代码如下：
+
+```
+/**
+ * Read messages into the given array and return the amount which was read.
+ */
+protected abstract int doReadMessages(List<Object> buf) throws Exception;
+```
+
+- 返回值为读取到的数量。
+
+NioServerSocketChannel 对该方法的实现代码如下：
+
+```
+  1: @Override
+  2: protected int doReadMessages(List<Object> buf) throws Exception {
+  3:     // 接受客户端连接
+  4:     SocketChannel ch = SocketUtils.accept(javaChannel());
+  5: 
+  6:     try {
+  7:         // 创建 Netty NioSocketChannel 对象
+  8:         if (ch != null) {
+  9:             buf.add(new NioSocketChannel(this, ch));
+ 10:             return 1;
+ 11:         }
+ 12:     } catch (Throwable t) {
+ 13:         logger.warn("Failed to create a new channel from an accepted socket.", t);
+ 14:         // 发生异常，关闭客户端的 SocketChannel 连接
+ 15:         try {
+ 16:             ch.close();
+ 17:         } catch (Throwable t2) {
+ 18:             logger.warn("Failed to close a socket.", t2);
+ 19:         }
+ 20:     }
+ 21: 
+ 22:     return 0;
+ 23: }
+ 
+ @Override
+protected ServerSocketChannel javaChannel() {
+    return (ServerSocketChannel) super.javaChannel();
+}
+```
+
+- 第 4 行：调用 `SocketUtils#accept(ServerSocketChannel serverSocketChannel)` 方法，接受客户端连接。代码如下：
+
+  ```
+  public static SocketChannel accept(final ServerSocketChannel serverSocketChannel) throws IOException {
+      try {
+          return AccessController.doPrivileged(new PrivilegedExceptionAction<SocketChannel>() {
+              @Override
+              public SocketChannel run() throws IOException {
+                  return serverSocketChannel.accept(); // <1>
+              }
+          });
+      } catch (PrivilegedActionException e) {
+          throw (IOException) e.getCause();
+      }
+  }
+  ```
+
+  - 重点是看 `<1>` 处，调用 `ServerSocketChannel#accept()` 方法，接受客户端连接。
+
+- 第 9 行：基于客户端的 NIO ServerSocket ，创建 Netty NioSocketChannel 对象。整个过程，就是
+
+   
+
+  《精尽 Netty 源码分析 —— 启动（二）之客户端》
+
+   
+
+  的
+
+   
+
+  「3.7.1 创建 Channel 对象」
+
+   
+
+  小节。
+
+  - 第 10 行：返回 1 ，表示成功接受了 1 个新的客户端连接。
+
+- 第 12 至 20 行：发生异常，关闭客户端的 SocketChannel 连接，并打印
+
+  告警
+
+  日志。
+
+  - 第 22 行：返回 0 ，表示成功接受 0 个新的客户端连接。
+
+# 4. ServerBootstrapAcceptor
+
+ServerBootstrapAcceptor ，继承 ChannelInboundHandlerAdapter 类，服务器接收器( acceptor )，负责将接受的客户端的 NioSocketChannel 注册到 EventLoop 中。
+
+另外，从继承的是 ChannelInboundHandlerAdapter 类，可以看出它是 Inbound 事件处理器。
+
+## 4.1 构造方法
+
+在服务端的启动过程中，我们看到 ServerBootstrapAcceptor 注册到服务端的 NioServerSocketChannel 的 pipeline 的尾部，代码如下：
+
+```
+// 记录当前的属性
+final EventLoopGroup currentChildGroup = childGroup;
+final ChannelHandler currentChildHandler = childHandler;
+final Entry<ChannelOption<?>, Object>[] currentChildOptions;
+final Entry<AttributeKey<?>, Object>[] currentChildAttrs;
+synchronized (childOptions) {
+    currentChildOptions = childOptions.entrySet().toArray(newOptionArray(0));
+}
+synchronized (childAttrs) {
+    currentChildAttrs = childAttrs.entrySet().toArray(newAttrArray(0));
+}
+
+// 添加 ChannelInitializer 对象到 pipeline 中，用于后续初始化 ChannelHandler 到 pipeline 中。
+p.addLast(new ChannelInitializer<Channel>() {
+
+    @Override
+    public void initChannel(final Channel ch) throws Exception {
+        final ChannelPipeline pipeline = ch.pipeline();
+
+        // 添加配置的 ChannelHandler 到 pipeline 中。
+        ChannelHandler handler = config.handler();
+        if (handler != null) {
+            pipeline.addLast(handler);
+        }
+
+        // 添加 ServerBootstrapAcceptor 到 pipeline 中。
+        // 使用 EventLoop 执行的原因，参见 https://github.com/lightningMan/netty/commit/4638df20628a8987c8709f0f8e5f3679a914ce1a
+        ch.eventLoop().execute(new Runnable() {
+            @Override
+            public void run() {
+                pipeline.addLast(new ServerBootstrapAcceptor(
+                        ch, currentChildGroup, currentChildHandler, currentChildOptions, currentChildAttrs)); // <1>
+            }
+        });
+    }
+
+});
+```
+
+- 即 `<1>` 处。也是在此处，创建了 ServerBootstrapAcceptor 对象。代码如下：
+
+  ```
+  private final EventLoopGroup childGroup;
+  private final ChannelHandler childHandler;
+  private final Entry<ChannelOption<?>, Object>[] childOptions;
+  private final Entry<AttributeKey<?>, Object>[] childAttrs;
+  /**
+   * 自动恢复接受客户端连接的任务
+   */
+  private final Runnable enableAutoReadTask;
+  
+  ServerBootstrapAcceptor(
+          final Channel channel, EventLoopGroup childGroup, ChannelHandler childHandler,
+          Entry<ChannelOption<?>, Object>[] childOptions, Entry<AttributeKey<?>, Object>[] childAttrs) {
+      this.childGroup = childGroup;
+      this.childHandler = childHandler;
+      this.childOptions = childOptions;
+      this.childAttrs = childAttrs;
+  
+      // Task which is scheduled to re-enable auto-read.
+      // It's important to create this Runnable before we try to submit it as otherwise the URLClassLoader may
+      // not be able to load the class because of the file limit it already reached.
+      //
+      // See https://github.com/netty/netty/issues/1328
+      enableAutoReadTask = new Runnable() { // <2>
+          @Override
+          public void run() {
+              channel.config().setAutoRead(true);
+          }
+      };
+  }
+  ```
+
+  - `enableAutoReadTask` 属性，自动恢复接受客户端连接的任务，在 `<2>` 处初始化。具体的使用，我们在 [「4.3 exceptionCaught」](https://svip.iocoder.cn/Netty/Channel-2-accept/#) 中，详细解析。
+
+## 4.2 channelRead
+
+`#channelRead(ChannelHandlerContext ctx, Object msg)` 方法，将接受的客户端的 NioSocketChannel 注册到 EventLoop 中。代码如下：
+
+```
+ 1: @Override
+ 2: public void channelRead(ChannelHandlerContext ctx, Object msg) {
+ 3:     // 老艿艿：如下的注释，先暂时认为是接受的客户端的 NioSocketChannel
+ 4: 
+ 5:     // 接受的客户端的 NioSocketChannel 对象
+ 6:     final Channel child = (Channel) msg;
+ 7:     // 添加 NioSocketChannel 的处理器
+ 8:     child.pipeline().addLast(childHandler);
+ 9:     // 设置 NioSocketChannel 的配置项
+10:     setChannelOptions(child, childOptions, logger);
+11:     // 设置 NioSocketChannel 的属性
+12:     for (Entry<AttributeKey<?>, Object> e: childAttrs) {
+13:         child.attr((AttributeKey<Object>) e.getKey()).set(e.getValue());
+14:     }
+15: 
+16:     try {
+17:         // 注册客户端的 NioSocketChannel 到 work EventLoop 中。
+18:         childGroup.register(child).addListener(new ChannelFutureListener() {
+19: 
+20:             @Override
+21:             public void operationComplete(ChannelFuture future) throws Exception {
+22:                 // 注册失败，关闭客户端的 NioSocketChannel
+23:                 if (!future.isSuccess()) {
+24:                     forceClose(child, future.cause());
+25:                 }
+26:             }
+27: 
+28:         });
+29:     } catch (Throwable t) {
+30:         // 发生异常，强制关闭客户端的 NioSocketChannel
+31:         forceClose(child, t);
+32:     }
+33: }
+```
+
+- 为了方便描述，我们统一认为接受的客户端连接为 NioSocketChannel 对象。
+
+- 第 6 行：接受的客户端的 NioSocketChannel 对象。
+
+  - 第 8 行：调用 `ChannelPipeline#addLast(childHandler)` 方法，将配置的子 Channel 的处理器，添加到 NioSocketChannel 中。
+  - 第 10 至 14 行：设置 NioSocketChannel 的配置项、属性。
+
+- 第 17 至 28 行：调用 `EventLoopGroup#register(Channel channel)` 方法，将客户端的 NioSocketChannel 对象，从 worker EventLoopGroup 中选择一个 EventLoop ，注册到其上。
+
+  - 后续的逻辑，就和 [《精尽 Netty 源码分析 —— 启动（一）之服务端》](http://svip.iocoder.cn/Netty/bootstrap-1-server/) 的注册逻辑**基本一致**( 虽然说，文章写的是 NioServerSocketChannel 的注册逻辑 )。
+
+  - 在注册完成之后，该 worker EventLoop 就会开始轮询该客户端是否有数据写入。
+
+  - 第 18 至 28 行：添加监听器，如果注册失败，则调用 `#forceClose(Channel child, Throwable t)` 方法，强制关闭客户端的 NioSocketChannel 连接。代码如下：
+
+    ```
+    private static void forceClose(Channel child, Throwable t) {
+        child.unsafe().closeForcibly();
+        logger.warn("Failed to register an accepted channel: {}", child, t);
+    }
+    ```
+
+    - 在该方法内部，会调用 `Unsafe#closeForcibly()` 方法，强制关闭客户端的 NioSocketChannel 。
+
+  - 第 29 至 32 行：发生异常，则调用 `#forceClose(Channel child, Throwable t)` 方法，强制关闭客户端的 NioSocketChannel 连接。
+
+## 4.3 exceptionCaught
+
+`#exceptionCaught(ChannelHandlerContext ctx, Throwable cause)` 方法，当捕获到异常时，**暂停 1 秒**，不再接受新的客户端连接；而后，再恢复接受新的客户端连接。代码如下：
+
+```
+ 1: @Override
+ 2: public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
+ 3:     final ChannelConfig config = ctx.channel().config();
+ 4:     if (config.isAutoRead()) {
+ 5:         // 关闭接受新的客户端连接
+ 6:         // stop accept new connections for 1 second to allow the channel to recover
+ 7:         // See https://github.com/netty/netty/issues/1328
+ 8:         config.setAutoRead(false);
+ 9:         // 发起 1 秒的延迟任务，恢复重启开启接受新的客户端连接
+10:         ctx.channel().eventLoop().schedule(enableAutoReadTask, 1, TimeUnit.SECONDS);
+11:     }
+12: 
+13:     // 继续传播 exceptionCaught 给下一个节点
+14:     // still let the exceptionCaught event flow through the pipeline to give the user
+15:     // a chance to do something with it
+16:     ctx.fireExceptionCaught(cause);
+17: }
+```
+
+- 第 8 行：调用 `ChannelConfig#setAutoRead(false)` 方法，关闭接受新的客户端连接。代码如下：
+
+  ```
+  // DefaultChannelConfig.java
+  /**
+   * {@link #autoRead} 的原子更新器
+   */
+  private static final AtomicIntegerFieldUpdater<DefaultChannelConfig> AUTOREAD_UPDATER = AtomicIntegerFieldUpdater.newUpdater(DefaultChannelConfig.class, "autoRead");
+  /**
+   * 是否开启自动读取的开关
+   *
+   * 1 - 开启
+   * 0 - 关闭
+   */
+  @SuppressWarnings("FieldMayBeFinal")
+  private volatile int autoRead = 1;
+  
+  @Override
+  public ChannelConfig setAutoRead(boolean autoRead) {
+      // 原子更新，并且获得更新前的值 <1>
+      boolean oldAutoRead = AUTOREAD_UPDATER.getAndSet(this, autoRead ? 1 : 0) == 1;
+      // 发起读取 <2.1>
+      if (autoRead && !oldAutoRead) {
+          channel.read();
+      // 关闭读取 <2.2>
+      } else if (!autoRead && oldAutoRead) {
+          autoReadCleared();
+      }
+      return this;
+  }
+  ```
+
+  - ```
+    autoRead
+    ```
+
+     
+
+    字段，是否开启自动读取的开关。😈 笔者原本以为是个
+
+     
+
+    ```
+    boolean
+    ```
+
+     
+
+    类型，是不是胖友也是。其中，1 表示开启，0 表示关闭。
+
+    - `AUTOREAD_UPDATER` 静态变量，对 `autoRead` 字段的原子更新器。
+
+  - `<1>` 处，使用 `AUTOREAD_UPDATER` 更新 `autoRead` 字段，并获得更新前的值。为什么需要获取更新前的值呢？在后续的 `<2.1>` 和 `<2.2>` 中，当 `autoRead` 有变化时候，才进行后续的逻辑。
+
+  - 😈 下面的逻辑，我们按照 `channel` 的类型为 NioServerSocketChannel 来分享。
+
+  - `<2.1>` 处，`autoRead && !oldAutoRead` 返回 `true` ，意味着恢复重启开启接受新的客户端连接。所以调用 `NioServerSocketChannel#read()` 方法，后续的逻辑，就是 [《精尽 Netty 源码分析 —— 启动（一）之服务端》](http://svip.iocoder.cn/Netty/bootstrap-1-server/) 的 [「3.13.3 beginRead」](https://svip.iocoder.cn/Netty/Channel-2-accept/#) 的逻辑。
+
+  - `<2.2>` 处，`!autoRead && oldAutoRead` 返回 `false` ，意味着关闭接受新的客户端连接。所以调用 `#autoReadCleared()` 方法，移除对 `SelectionKey.OP_ACCEPT` 事件的感兴趣。
+
+    ```
+    // NioServerSocketChannel.java
+    
+    @Override
+    protected void autoReadCleared() {
+        clearReadPending();
+    }
+    ```
+
+    - 在方法内部，会调用 `#clearReadPending()` 方法，代码如下：
+
+      ```
+      protected final void clearReadPending() {
+          if (isRegistered()) {
+              EventLoop eventLoop = eventLoop();
+              if (eventLoop.inEventLoop()) {
+                  clearReadPending0();
+              } else {
+                  eventLoop.execute(clearReadPendingRunnable);
+              }
+          } else {
+              // Best effort if we are not registered yet clear readPending. This happens during channel initialization.
+              // NB: We only set the boolean field instead of calling clearReadPending0(), because the SelectionKey is
+              // not set yet so it would produce an assertion failure.
+              readPending = false;
+          }
+      }
+      
+      private final Runnable clearReadPendingRunnable = new Runnable() {
+          @Override
+          public void run() {
+              clearReadPending0();
+          }
+      };
+      
+      private void clearReadPending0() {
+          // TODO 芋艿
+          readPending = false;
+          // 移除对“读”事件的感兴趣。
+          ((AbstractNioUnsafe) unsafe()).removeReadOp();
+      }
+      ```
+
+      - 最终的结果，是在 EventLoop 的线程中，调用 `AbstractNioUnsafe#clearReadPending0()` 方法，移除对“**读**”事件的感兴趣( 对于 NioServerSocketChannel 的 “**读**“事件就是 `SelectionKey.OP_ACCEPT` )。代码如下：
+
+        ```
+        // AbstractNioUnsafe.java
+        
+        protected final void removeReadOp() {
+            SelectionKey key = selectionKey();
+            // 忽略，如果 SelectionKey 不合法，例如已经取消
+            // Check first if the key is still valid as it may be canceled as part of the deregistration
+            // from the EventLoop
+            // See https://github.com/netty/netty/issues/2104
+            if (!key.isValid()) {
+                return;
+            }
+            // 移除对“读”事件的感兴趣。
+            int interestOps = key.interestOps();
+            if ((interestOps & readInterestOp) != 0) {
+                // only remove readInterestOp if needed
+                key.interestOps(interestOps & ~readInterestOp);
+            }
+        }
+        ```
+
+        - 通过取反求并，后调用 `SelectionKey#interestOps(interestOps)` 方法，**仅**移除对“读”事件的感兴趣。
+        - 😈 整个过程的调用链，有丢丢长，胖友可以回看，或者多多调试。
+
+- 第 10 行：调用 `EventLoop#schedule(Runnable command, long delay, TimeUnit unit)` 方法，发起 1 秒的延迟任务，恢复重启开启接受新的客户端连接。该定时任务会调用 `ChannelConfig#setAutoRead(true)` 方法，即对应 `<2.1>` 情况。
+
+- 第 16 行：调用 `ChannelHandlerContext#fireExceptionCaught(cause)` 方法，继续传播 exceptionCaught 给下一个节点。具体的原因，可看英文注释。
+
+# 666. 彩蛋
+
+推荐阅读文章：
+
+- 闪电侠 [《netty 源码分析之新连接接入全解析》](https://www.jianshu.com/p/0242b1d4dd21)
+- 占小狼 [《Netty 源码分析之 accept 过程》](https://www.jianshu.com/p/ffc6fd82e32b)
\ No newline at end of file
diff --git a/netty/30-Netty 源码解析-Channel（四）之 write 操作.md b/netty/30-Netty 源码解析-Channel（四）之 write 操作.md
new file mode 100644
index 0000000..6178edf
--- /dev/null
+++ b/netty/30-Netty 源码解析-Channel（四）之 write 操作.md	
@@ -0,0 +1,685 @@
+# 精尽 Netty 源码解析 —— Channel（四）之 write 操作
+
+# 1. 概述
+
+本文分享 Netty NioSocketChannel **写入**对端数据的过程。和**写入**相关的，在 Netty Channel 有三种 API 方法：
+
+```
+ChannelFuture write(Object msg)
+ChannelFuture write(Object msg, ChannelPromise promise);
+
+ChannelOutboundInvoker flush();
+
+ChannelFuture writeAndFlush(Object msg);
+ChannelFuture writeAndFlush(Object msg, ChannelPromise promise);
+```
+
+原生的 Java NIO SocketChannel 只有一种 write 方法，将数据写到对端。而 Netty Channel 竟然有三种方法，我们来一个个看看：
+
+- write 方法：将数据写到
+
+  内存队列
+
+  中。
+
+  - 也就是说，此时数据**并没有**写入到对端。
+
+- flush 方法：刷新
+
+  内存队列
+
+  ，将其中的数据写入到对端。
+
+  - 也就是说，此时数据才**真正**写到对端。
+
+- writeAndFlush 方法：write + flush 的组合，将数据写到内存队列后，立即刷新
+
+  内存队列
+
+  ，又将其中的数据写入到对端。
+
+  - 也就是说，此时数据**已经**写到对端。
+
+严格来说，上述的描述不是完全准确。因为 Netty Channel 的 `#write(Object msg, ...)` 和 `#writeAndFlush(Object msg, ...)` 方法，是**异步写入**的过程，需要通过监听返回的 ChannelFuture 来确实是真正写入。例如：
+
+```
+// 方式一：异步监听
+channel.write(msg).addListener(new ChannelFutureListener() {
+                
+    @Override
+    public void operationComplete(ChannelFuture future) throws Exception {
+        // ... 相关逻辑，例如是否成功？    
+    }
+    
+});
+
+// 方式二：同步异步写入结果
+channel.write(msg).sync();
+```
+
+- 所以，胖友实际在使用时，一定要注意。😈 如果感兴趣，可以看看 Dubbo 和 Motan 等等 RPC 框架是怎么使用这个 API 方法的。
+- 😈 **有一点一定非常肯定要注意**，`#write(Object msg, ...)` 方法返回的 Promise 对象，只有在数据真正被 `#flush()` 方法调用执行完成后，才会被回调通知。如果胖友不理解，请自己测试一下。
+
+------
+
+考虑到 Netty NioSocketChannel **写入**对端数据的代码太多，所以笔者拆成 write 和 flush 相关的两篇文章。所以，本文当然是 write 相关的文章。当然，这两个操作相关性很高，所以本文也会包括 flush 部分的内容。
+
+# 2. AbstractChannel
+
+AbstractChannel 对 `#write(Object msg, ...)` 方法的实现，代码如下：
+
+```
+@Override
+public ChannelFuture write(Object msg) {
+    return pipeline.write(msg);
+}
+
+@Override
+public ChannelFuture write(Object msg, ChannelPromise promise) {
+    return pipeline.write(msg, promise);
+}
+```
+
+- 在方法内部，会调用对应的
+
+   
+
+  ```
+  ChannelPipeline#write(Object msg, ...)
+  ```
+
+   
+
+  方法，将 write 事件在 pipeline 上传播。详细解析，见
+
+   
+
+  「3. DefaultChannelPipeline」
+
+   
+
+  。
+
+  - 最终会传播 write 事件到 `head` 节点，将数据写入到内存队列中。详细解析，见 [「5. HeadContext」](https://svip.iocoder.cn/Netty/Channel-4-write/#) 。
+
+# 3. DefaultChannelPipeline
+
+`DefaultChannelPipeline#write(Object msg, ...)` 方法，代码如下：
+
+```
+@Override
+public final ChannelFuture write(Object msg) {
+    return tail.write(msg);
+}
+
+@Override
+public final ChannelFuture write(Object msg, ChannelPromise promise) {
+    return tail.write(msg, promise);
+}
+```
+
+- 在方法内部，会调用 `TailContext#write(Object msg, ...)` 方法，将 write 事件在 pipeline 中，从尾节点向头节点传播。详细解析，见 [「4. TailContext」](https://svip.iocoder.cn/Netty/Channel-4-write/#) 。
+
+# 4. TailContext
+
+TailContext 对 `TailContext#write(Object msg, ...)` 方法的实现，是从 AbstractChannelHandlerContext 抽象类继承，代码如下：
+
+```
+ 1: @Override
+ 2: public ChannelFuture write(Object msg) {
+ 3:     return write(msg, newPromise());
+ 4: }
+ 5: 
+ 6: @Override
+ 7: public ChannelFuture write(final Object msg, final ChannelPromise promise) {
+ 8:     // 消息( 数据 )为空，抛出异常
+ 9:     if (msg == null) {
+10:         throw new NullPointerException("msg");
+11:     }
+12: 
+13:     try {
+14:         // 判断是否为合法的 Promise 对象
+15:         if (isNotValidPromise(promise, true)) {
+16:             // 释放消息( 数据 )相关的资源
+17:             ReferenceCountUtil.release(msg);
+18:             // cancelled
+19:             return promise;
+20:         }
+21:     } catch (RuntimeException e) {
+22:         // 发生异常，释放消息( 数据 )相关的资源
+23:         ReferenceCountUtil.release(msg);
+24:         throw e;
+25:     }
+26: 
+27:     // 写入消息( 数据 )到内存队列
+28:     write(msg, false, promise);
+29:     return promise;
+30: }
+```
+
+- 在【第 2 行】的代码，我们可以看到，`#write(Object msg)` 方法，会调用 `#write(Object msg, ChannelPromise promise)` 方法。
+
+  - 缺少的 `promise` 方法参数，通过调用 `#newPromise()` 方法，进行创建 Promise 对象，代码如下：
+
+    ```
+    @Override
+    public ChannelPromise newPromise() {
+        return new DefaultChannelPromise(channel(), executor());
+    }
+    ```
+
+    - 返回 DefaultChannelPromise 对象。
+
+  - 在【第 29 行】的代码，返回的结果就是传入的 `promise` 对象。
+
+- 第 8 至 11 行：若消息( 消息 )为空，抛出异常。
+
+- 第 15 行：调用
+
+   
+
+  ```
+  #isNotValidPromise(promise, true)
+  ```
+
+   
+
+  方法，判断是否为
+
+  不合法
+
+  的 Promise 对象。该方法，在
+
+   
+
+  《精尽 Netty 源码解析 —— ChannelPipeline（四）之 Outbound 事件的传播》
+
+   
+
+  中已经详细解析。
+
+  - 第 17 行：调用 `ReferenceCountUtil#release(msg)` 方法，释放释放消息( 数据 )相关的资源。
+  - 第 19 行：返回 `promise` 对象。一般情况下，出现这种情况是 `promise` 已经被取消，所以不再有必要写入数据。或者说，**写入数据的操作被取消**。
+  - 第 21 至 25 行：若发生异常， 调用 `ReferenceCountUtil#release(msg)` 方法，释放释放消息( 数据 )相关的资源。最终，会抛出该异常。
+
+- 第 28 行：调用 `#write(Object msg, boolean flush, ChannelPromise promise)` 方法，写入消息( 数据 )到内存队列。代码如下：
+
+  ```
+   1: private void write(Object msg, boolean flush, ChannelPromise promise) {
+   2:     // 获得下一个 Outbound 节点
+   3:     AbstractChannelHandlerContext next = findContextOutbound();
+   4:     // 记录 Record 记录
+   5:     final Object m = pipeline.touch(msg, next);
+   6:     EventExecutor executor = next.executor();
+   7:     // 在 EventLoop 的线程中
+   8:     if (executor.inEventLoop()) {
+   9:         // 执行 writeAndFlush 事件到下一个节点
+  10:         if (flush) {
+  11:             next.invokeWriteAndFlush(m, promise);
+  12:         // 执行 write 事件到下一个节点
+  13:         } else {
+  14:             next.invokeWrite(m, promise);
+  15:         }
+  16:     } else {
+  17:         AbstractWriteTask task;
+  18:         // 创建 writeAndFlush 任务
+  19:         if (flush) {
+  20:             task = WriteAndFlushTask.newInstance(next, m, promise);
+  21:         // 创建 write 任务
+  22:         }  else {
+  23:             task = WriteTask.newInstance(next, m, promise);
+  24:         }
+  25:         // 提交到 EventLoop 的线程中，执行该任务
+  26:         safeExecute(executor, task, promise, m);
+  27:     }
+  28: }
+  ```
+
+  - 方法参数 `flush` 为 `true` 时，该方法执行的是 write + flush 的组合操作，即将数据写到内存队列后，立即刷新**内存队列**，又将其中的数据写入到对端。
+
+  - 第 3 行：调用 `#findContextOutbound()` 方法，获得**下一个** Outbound 节点。
+
+  - 第 5 行：调用 `DefaultChannelPipeline#touch(Object msg, AbstractChannelHandlerContext next)` 方法，记录 Record 记录。代码如下：
+
+    ```
+    // DefaultChannelPipeline.java
+    final Object touch(Object msg, AbstractChannelHandlerContext next) {
+        return touch ? ReferenceCountUtil.touch(msg, next) : msg;
+    }
+    
+    // ReferenceCountUtil.java
+    /**
+     * Tries to call {@link ReferenceCounted#touch(Object)} if the specified message implements
+     * {@link ReferenceCounted}.  If the specified message doesn't implement {@link ReferenceCounted},
+     * this method does nothing.
+     */
+    @SuppressWarnings("unchecked")
+    public static <T> T touch(T msg, Object hint) {
+        if (msg instanceof ReferenceCounted) {
+            return (T) ((ReferenceCounted) msg).touch(hint);
+        }
+        return msg;
+    }
+    ```
+
+    - 详细解析，见 [《精尽 Netty 源码解析 —— Buffer 之 ByteBuf（三）内存泄露检测》](http://svip.iocoder.cn/Netty/ByteBuf-1-3-ByteBuf-resource-leak-detector/) 。
+
+  - 第 7 行：**在** EventLoop 的线程中。
+
+    - 第 10 至 11 行：如果 `flush = true` 时，调用 `AbstractChannelHandlerContext#invokeWriteAndFlush()` 方法，执行 writeAndFlush 事件到下一个节点。
+    - 第 12 至 15 行：如果 `flush = false` 时，调用 `AbstractChannelHandlerContext#invokeWrite()` 方法，执行 write 事件到下一个节点。
+    - 后续的逻辑，和 [《精尽 Netty 源码解析 —— ChannelPipeline（四）之 Outbound 事件的传播》](http://svip.iocoder.cn/Netty/Pipeline-4-outbound/) 分享的 **bind** 事件在 pipeline 中的传播是**基本一致**的。
+    - 随着 write 或 writeAndFlush **事件**不断的向下一个节点传播，最终会到达 HeadContext 节点。详细解析，见 [「5. HeadContext」](https://svip.iocoder.cn/Netty/Channel-4-write/#) 。
+
+  - 第 16 行：
+
+    不在
+
+     
+
+    EventLoop 的线程中。
+
+    - 第 19 至 20 行：如果 `flush = true` 时，创建 WriteAndFlushTask 任务。
+    - 第 21 至 24 行：如果 `flush = false` 时，创建 WriteTask 任务。
+    - 第 26 行：调用 `#safeExecute(executor, task, promise, m)` 方法，提交到 EventLoop 的线程中，执行该任务。从而实现，**在** EventLoop 的线程中，执行 writeAndFlush 或 write 事件到下一个节点。详细解析，见 [「7. AbstractWriteTask」](https://svip.iocoder.cn/Netty/Channel-4-write/#) 中。
+
+- 第 29 行：返回 `promise` 对象。
+
+# 5. HeadContext
+
+在 pipeline 中，write 事件最终会到达 HeadContext 节点。而 HeadContext 的 `#write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise)` 方法，会处理该事件，代码如下：
+
+```
+@Override
+public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) throws Exception {
+    unsafe.write(msg, promise);
+}
+```
+
+- 在方法内部，会调用 `AbstractUnsafe#write(Object msg, ChannelPromise promise)` 方法，将数据写到**内存队列**中。详细解析，见 [「6. AbstractUnsafe」](https://svip.iocoder.cn/Netty/Channel-4-write/#) 。
+
+# 6. AbstractUnsafe
+
+`AbstractUnsafe#write(Object msg, ChannelPromise promise)` 方法，将数据写到**内存队列**中。代码如下：
+
+```
+/**
+ * 内存队列
+ */
+private volatile ChannelOutboundBuffer outboundBuffer = new ChannelOutboundBuffer(AbstractChannel.this);
+
+  1: @Override
+  2: public final void write(Object msg, ChannelPromise promise) {
+  3:     assertEventLoop();
+  4: 
+  5:     ChannelOutboundBuffer outboundBuffer = this.outboundBuffer;
+  6:     // 内存队列为空
+  7:     if (outboundBuffer == null) {
+  8:         // 内存队列为空，一般是 Channel 已经关闭，所以通知 Promise 异常结果
+  9:         // If the outboundBuffer is null we know the channel was closed and so
+ 10:         // need to fail the future right away. If it is not null the handling of the rest
+ 11:         // will be done in flush0()
+ 12:         // See https://github.com/netty/netty/issues/2362
+ 13:         safeSetFailure(promise, WRITE_CLOSED_CHANNEL_EXCEPTION);
+ 14:         // 释放消息( 对象 )相关的资源
+ 15:         // release message now to prevent resource-leak
+ 16:         ReferenceCountUtil.release(msg);
+ 17:         return;
+ 18:     }
+ 19: 
+ 20:     int size;
+ 21:     try {
+ 22:         // 过滤写入的消息( 数据 )
+ 23:         msg = filterOutboundMessage(msg);
+ 24:         // 计算消息的长度
+ 25:         size = pipeline.estimatorHandle().size(msg);
+ 26:         if (size < 0) {
+ 27:             size = 0;
+ 28:         }
+ 29:     } catch (Throwable t) {
+ 30:         // 通知 Promise 异常结果
+ 31:         safeSetFailure(promise, t);
+ 32:         // 释放消息( 对象 )相关的资源
+ 33:         ReferenceCountUtil.release(msg);
+ 34:         return;
+ 35:     }
+ 36: 
+ 37:     // 写入消息( 数据 )到内存队列
+ 38:     outboundBuffer.addMessage(msg, size, promise);
+ 39: }
+```
+
+- `outboundBuffer` 属性，内存队列，用于缓存写入的数据( 消息 )。
+
+- 第 7 行：内存队列为空，一般是 Channel
+
+   
+
+  已经关闭
+
+  。
+
+  - 调用 `#safeSetFailure(promise, WRITE_CLOSED_CHANNEL_EXCEPTION)` 方法，通知 Promise 异常结果。
+  - 第 16 行：调用 `ReferenceCountUtil#release(msg)` 方法，释放释放消息( 数据 )相关的资源。
+  - 第 17 行：`return` ，结束执行。
+
+- 第 23 行：调用 `AbstractNioByteChannel#filterOutboundMessage(msg)` 方法，过滤写入的消息( 数据 )。代码如下：
+
+  ```
+  // AbstractNioByteChannel.java
+  
+  @Override
+  protected final Object filterOutboundMessage(Object msg) {
+      // <1> ByteBuf 的情况
+      if (msg instanceof ByteBuf) {
+          ByteBuf buf = (ByteBuf) msg;
+          // 已经是内存 ByteBuf
+          if (buf.isDirect()) {
+              return msg;
+          }
+  
+          // 非内存 ByteBuf ，需要进行创建封装
+          return newDirectBuffer(buf);
+      }
+  
+      // <2> FileRegion 的情况
+      if (msg instanceof FileRegion) {
+          return msg;
+      }
+  
+      // <3> 不支持其他类型
+      throw new UnsupportedOperationException("unsupported message type: " + StringUtil.simpleClassName(msg) + EXPECTED_TYPES);
+  }
+  ```
+
+  - `<1>` 处，消息( 数据 )是 ByteBuf 类型，如果是非 Direct ByteBuf 对象，需要调用 `#newDirectBuffer(ByteBuf)` 方法，复制封装成 Direct ByteBuf 对象。原因是：在使用 Socket 传递数据时性能很好，由于数据直接在内存中，不存在从 JVM 拷贝数据到直接缓冲区的过程，性能好。( 来自 [《[netty核心类\]–缓冲区ByteBuf》](https://blog.csdn.net/u010853261/article/details/53690780) )
+  - `<2>` 处，消息( 数据 )是 FileRegion 类型，直接返回。
+  - `<3>` 处，不支持其他数据类型。
+
+- 第 24 至 28 行：计算消息的长度。
+
+- 第 29 行：若发生异常时：
+
+  - 第 31 行：调用 `#safeSetFailure(promise, Throwable t)` 方法，通知 Promise 异常结果。
+  - 第 33 行：调用 `ReferenceCountUtil#release(msg)` 方法，释放释放消息( 数据 )相关的资源。
+  - 第 34 行：`return` ，结束执行。
+
+- 第 38 行：调用 `ChannelOutboundBuffer#addMessage(msg, size, promise)` 方法，写入消息( 数据 )到内存队列。关于 ChannelOutboundBuffer ，我们在 [《精尽 Netty 源码解析 —— Channel（五）之 flush 操作》](http://svip.iocoder.cn/Netty/Channel-5-flush) 中，详细解析。
+
+😈 至此，write 操作，将数据写到**内存队列**中的过程。
+🙂 当然，想要写入数据到对端的过程，还是需要看完 [《精尽 Netty 源码解析 —— Channel（五）之 flush 操作》](http://svip.iocoder.cn/Netty/Channel-5-flush) 一文。
+
+# 7. AbstractWriteTask
+
+AbstractWriteTask ，实现 Runnable 接口，写入任务**抽象类**。它有两个子类实现：
+
+- WriteTask ，write 任务实现类。
+- WriteAndFlushTask ，write + flush 任务实现类。
+
+它们都是 AbstractChannelHandlerContext 的内部静态类。那么让我们先来 AbstractWriteTask 的代码。
+
+## 7.1 构造方法
+
+```
+/**
+ * 提交任务时，是否计算 AbstractWriteTask 对象的自身占用内存大小
+ */
+private static final boolean ESTIMATE_TASK_SIZE_ON_SUBMIT = SystemPropertyUtil.getBoolean("io.netty.transport.estimateSizeOnSubmit", true);
+
+/**
+ * 每个 AbstractWriteTask 对象自身占用内存的大小。
+ */
+// Assuming a 64-bit JVM, 16 bytes object header, 3 reference fields and one int field, plus alignment
+private static final int WRITE_TASK_OVERHEAD = SystemPropertyUtil.getInt("io.netty.transport.writeTaskSizeOverhead", 48);
+
+private final Recycler.Handle<AbstractWriteTask> handle;
+/**
+ * pipeline 中的节点
+ */
+private AbstractChannelHandlerContext ctx;
+/**
+ * 消息( 数据 )
+ */
+private Object msg;
+/**
+ * Promise 对象
+ */
+private ChannelPromise promise;
+/**
+ * 对象大小
+ */
+private int size;
+
+@SuppressWarnings("unchecked")
+private AbstractWriteTask(Recycler.Handle<? extends AbstractWriteTask> handle) {
+    this.handle = (Recycler.Handle<AbstractWriteTask>) handle;
+}
+```
+
+- 每个字段，看代码注释。
+
+- `ESTIMATE_TASK_SIZE_ON_SUBMIT` **静态**字段，提交任务时，是否计算 AbstractWriteTask 对象的自身占用内存大小。
+
+- ```
+  WRITE_TASK_OVERHEAD
+  ```
+
+   
+
+  静态
+
+  字段，每个 AbstractWriteTask 对象自身占用内存的大小。为什么占用的 48 字节呢？
+
+  - `- 16 bytes object header` ，对象头，16 字节。
+  - `- 3 reference fields` ，3 个**对象引用**字段，3 * 8 = 24 字节。
+  - `- 1 int fields` ，1 个 `int` 字段，4 字节。
+  - `padding` ，补齐 8 字节的整数倍，因此 4 字节。
+  - 因此，合计 48 字节( 64 位的 JVM 虚拟机，并且不考虑压缩 )。
+  - 如果不理解的胖友，可以看看 [《JVM中 对象的内存布局 以及 实例分析》](https://www.jianshu.com/p/12a3c97dc2b7) 。
+
+- `handle` 字段，Recycler 处理器。而 Recycler 是 Netty 用来实现对象池的工具类。在网络通信中，写入是非常频繁的操作，因此通过 Recycler 重用 AbstractWriteTask 对象，减少对象的频繁创建，降低 GC 压力，提升性能。
+
+## 7.2 init
+
+`#init(AbstractWriteTask task, AbstractChannelHandlerContext ctx, Object msg, ChannelPromise promise)` 方法，初始化 AbstractWriteTask 对象。代码如下：
+
+```
+protected static void init(AbstractWriteTask task, AbstractChannelHandlerContext ctx, Object msg, ChannelPromise promise) {
+    task.ctx = ctx;
+    task.msg = msg;
+    task.promise = promise;
+    // 计算 AbstractWriteTask 对象大小 <1>
+    if (ESTIMATE_TASK_SIZE_ON_SUBMIT) {
+        task.size = ctx.pipeline.estimatorHandle().size(msg) + WRITE_TASK_OVERHEAD;
+        // 增加 ChannelOutboundBuffer 的 totalPendingSize 属性  <2>
+        ctx.pipeline.incrementPendingOutboundBytes(task.size);
+    } else {
+        task.size = 0;
+    }
+}
+```
+
+- 在下文中，我们会看到 AbstractWriteTask 对象是从 Recycler 中获取，所以获取完成后，需要通过该方法，初始化该对象的属性。
+
+- `<1>` 处，计算 AbstractWriteTask 对象大小。并且在 `<2>` 处，调用 `ChannelPipeline#incrementPendingOutboundBytes(long size)` 方法，增加 ChannelOutboundBuffer 的 `totalPendingSize` 属性。代码如下：
+
+  ```
+  // DefaultChannelPipeline.java
+  @UnstableApi
+  protected void incrementPendingOutboundBytes(long size) {
+      ChannelOutboundBuffer buffer = channel.unsafe().outboundBuffer();
+      if (buffer != null) {
+          buffer.incrementPendingOutboundBytes(size);
+      }
+  }
+  ```
+
+  - 内部，会调用 `ChannelOutboundBuffer#incrementPendingOutboundBytes(long size)` 方法，增加 ChannelOutboundBuffer 的 `totalPendingSize` 属性。详细解析，见 [《精尽 Netty 源码解析 —— Channel（五）之 flush 操作》](http://svip.iocoder.cn/Netty/Channel-5-flush) 的 [「10.1 incrementPendingOutboundBytes」](https://svip.iocoder.cn/Netty/Channel-4-write/#) 小节。
+
+## 7.3 run
+
+`#run()` **实现**方法，
+
+```
+ 1: @Override
+ 2: public final void run() {
+ 3:     try {
+ 4:         // 减少 ChannelOutboundBuffer 的 totalPendingSize 属性 <1>
+ 5:         // Check for null as it may be set to null if the channel is closed already
+ 6:         if (ESTIMATE_TASK_SIZE_ON_SUBMIT) {
+ 7:             ctx.pipeline.decrementPendingOutboundBytes(size);
+ 8:         }
+ 9:         // 执行 write 事件到下一个节点
+10:         write(ctx, msg, promise);
+11:     } finally {
+12:         // 置空，help gc
+13:         // Set to null so the GC can collect them directly
+14:         ctx = null;
+15:         msg = null;
+16:         promise = null;
+17:         // 回收对象
+18:         handle.recycle(this);
+19:     }
+20: }
+```
+
+- 在 `<1>` 处， 调用 `ChannelPipeline#decrementPendingOutboundBytes(long size)` 方法，减少 ChannelOutboundBuffer 的 `totalPendingSize` 属性。代码如下：
+
+  ```
+  @UnstableApi
+  protected void decrementPendingOutboundBytes(long size) {
+      ChannelOutboundBuffer buffer = channel.unsafe().outboundBuffer();
+      if (buffer != null) {
+          buffer.decrementPendingOutboundBytes(size);
+      }
+  }
+  ```
+
+  - 内部，会调用 `ChannelOutboundBuffer#decrementPendingOutboundBytes(long size)` 方法，减少 ChannelOutboundBuffer 的 `totalPendingSize` 属性。详细解析，见 [《精尽 Netty 源码解析 —— Channel（五）之 flush 操作》](http://svip.iocoder.cn/Netty/Channel-5-flush) 的 [「10.2 decrementPendingOutboundBytes」](https://svip.iocoder.cn/Netty/Channel-4-write/#) 小节。
+
+- 第 10 行：调用 `#write(ctx, msg, promise)` 方法，执行 write 事件到下一个节点。代码如下：
+
+  ```
+  protected void write(AbstractChannelHandlerContext ctx, Object msg, ChannelPromise promise) {
+      ctx.invokeWrite(msg, promise);
+  }
+  ```
+
+- 第 11 至 19 行：置空 AbstractWriteTask 对象，并调用 `Recycler.Handle#recycle(this)` 方法，回收该对象。
+
+## 7.4 WriteTask
+
+WriteTask ，实现 SingleThreadEventLoop.NonWakeupRunnable 接口，继承 AbstractWriteTask 抽象类，write 任务实现类。
+
+**为什么会实现 SingleThreadEventLoop.NonWakeupRunnable 接口呢**？write 操作，仅仅将数据写到**内存队列**中，无需唤醒 EventLoop ，从而提升性能。关于 SingleThreadEventLoop.NonWakeupRunnable 接口，在 [《精尽 Netty 源码解析 —— EventLoop（三）之 EventLoop 初始化》](http://svip.iocoder.cn/Netty/EventLoop-3-EventLoop-init) 有详细解析。
+
+### 7.4.1 newInstance
+
+`#newInstance(AbstractChannelHandlerContext ctx, Object msg, ChannelPromise promise)` 方法，创建 WriteTask 对象。代码如下：
+
+```
+private static final Recycler<WriteTask> RECYCLER = new Recycler<WriteTask>() {
+
+    @Override
+    protected WriteTask newObject(Handle<WriteTask> handle) {
+        return new WriteTask(handle); // 创建 WriteTask 对象
+    }
+
+};
+
+private static WriteTask newInstance(AbstractChannelHandlerContext ctx, Object msg, ChannelPromise promise) {
+    // 从 Recycler 的对象池中获得 WriteTask 对象
+    WriteTask task = RECYCLER.get();
+    // 初始化 WriteTask 对象的属性
+    init(task, ctx, msg, promise);
+    return task;
+}
+```
+
+### 7.4.2 构造方法
+
+```
+private WriteTask(Recycler.Handle<WriteTask> handle) {
+    super(handle);
+}
+```
+
+### 7.4.3 write
+
+WriteTask 无需实现 `#write(AbstractChannelHandlerContext ctx, Object msg, ChannelPromise promise)` 方法，直接**重用**父类该方法即可。
+
+## 7.5 WriteAndFlushTask
+
+WriteAndFlushTask ，继承 WriteAndFlushTask 抽象类，write + flush 任务实现类。
+
+### 7.5.1 newInstance
+
+`#newInstance(AbstractChannelHandlerContext ctx, Object msg, ChannelPromise promise)` 方法，创建 WriteAndFlushTask 对象。代码如下：
+
+```
+private static final Recycler<WriteAndFlushTask> RECYCLER = new Recycler<WriteAndFlushTask>() {
+
+    @Override
+    protected WriteAndFlushTask newObject(Handle<WriteAndFlushTask> handle) {
+        return new WriteAndFlushTask(handle); // 创建 WriteAndFlushTask 对象
+    }
+
+};
+
+private static WriteAndFlushTask newInstance(AbstractChannelHandlerContext ctx, Object msg,  ChannelPromise promise) {
+    // 从 Recycler 的对象池中获得 WriteTask 对象
+    WriteAndFlushTask task = RECYCLER.get();
+    // 初始化 WriteTask 对象的属性
+    init(task, ctx, msg, promise);
+    return task;
+}
+```
+
+### 7.5.2 构造方法
+
+```
+private WriteAndFlushTask(Recycler.Handle<WriteAndFlushTask> handle) {
+    super(handle);
+}
+```
+
+### 7.5.3 write
+
+`#write(AbstractChannelHandlerContext ctx, Object msg, ChannelPromise promise)` 方法，在父类的该方法的基础上，增加执行 **flush** 事件到下一个节点。代码如下：
+
+```
+@Override
+public void write(AbstractChannelHandlerContext ctx, Object msg, ChannelPromise promise) {
+    // 执行 write 事件到下一个节点
+    super.write(ctx, msg, promise);
+    // 执行 flush 事件到下一个节点
+    ctx.invokeFlush();
+}
+```
+
+# 666. 彩蛋
+
+最后，我们来看一个真的彩蛋，嘿嘿嘿。
+
+在一些 ChannelHandler 里，我们想要写入数据到对端，可以有两种写法，代码如下：
+
+```
+@Override
+public void channelRead(ChannelHandlerContext ctx, Object msg) {
+    ctx.write(msg); // <1>
+    ctx.channel().write(msg); // <2>
+}
+```
+
+这两者有什么异同呢？
+
+- `<2>` 种，实际就是本文所描述的，将 write 事件，从 pipeline 的 `tail` 节点到 `head` 节点的过程。
+- `<1>` 种，和 `<2>` 种**不同**，将 write 事件，从当前的 `ctx` 节点的**下一个**节点到 `head` 节点的过程。
+- 为什么呢？胖友自己调试理解下。😁😁😁
+
+------
+
+推荐阅读文章：
+
+- 占小狼 [《深入浅出Netty write》](https://www.jianshu.com/p/1ad424c53e80)
+- 闪电侠 [《netty 源码分析之 writeAndFlush 全解析》](https://www.jianshu.com/p/feaeaab2ce56)
\ No newline at end of file
diff --git a/netty/31-Netty 源码解析-Channel（五）之 flush 操作.assets/1f939423f079ff491b90c8300e7ef3ea.png b/netty/31-Netty 源码解析-Channel（五）之 flush 操作.assets/1f939423f079ff491b90c8300e7ef3ea.png
new file mode 100644
index 0000000..48b474c
Binary files /dev/null and b/netty/31-Netty 源码解析-Channel（五）之 flush 操作.assets/1f939423f079ff491b90c8300e7ef3ea.png differ
diff --git a/netty/31-Netty 源码解析-Channel（五）之 flush 操作.assets/1ff7a5d2b08b9e6160dd92e74e68145f.png b/netty/31-Netty 源码解析-Channel（五）之 flush 操作.assets/1ff7a5d2b08b9e6160dd92e74e68145f.png
new file mode 100644
index 0000000..ba95382
Binary files /dev/null and b/netty/31-Netty 源码解析-Channel（五）之 flush 操作.assets/1ff7a5d2b08b9e6160dd92e74e68145f.png differ
diff --git a/netty/31-Netty 源码解析-Channel（五）之 flush 操作.assets/c0077b0dc86ecf1b791a99eeb9664fc3.png b/netty/31-Netty 源码解析-Channel（五）之 flush 操作.assets/c0077b0dc86ecf1b791a99eeb9664fc3.png
new file mode 100644
index 0000000..e997c78
Binary files /dev/null and b/netty/31-Netty 源码解析-Channel（五）之 flush 操作.assets/c0077b0dc86ecf1b791a99eeb9664fc3.png differ
diff --git a/netty/31-Netty 源码解析-Channel（五）之 flush 操作.assets/ecb3df153a3df70464b524838b559232.png b/netty/31-Netty 源码解析-Channel（五）之 flush 操作.assets/ecb3df153a3df70464b524838b559232.png
new file mode 100644
index 0000000..a1dee28
Binary files /dev/null and b/netty/31-Netty 源码解析-Channel（五）之 flush 操作.assets/ecb3df153a3df70464b524838b559232.png differ
diff --git a/netty/31-Netty 源码解析-Channel（五）之 flush 操作.md b/netty/31-Netty 源码解析-Channel（五）之 flush 操作.md
new file mode 100644
index 0000000..412ab9b
--- /dev/null
+++ b/netty/31-Netty 源码解析-Channel（五）之 flush 操作.md	
@@ -0,0 +1,2343 @@
+# 精尽 Netty 源码解析 —— Channel（五）之 flush 操作
+
+# 1. 概述
+
+本文接 [《精尽 Netty 源码解析 —— Channel（四）之 write 操作》](http://svip.iocoder.cn/Netty/Channel-4-write/) ，分享 Netty Channel 的 `#flush()` 方法，刷新**内存队列**，将其中的数据写入到对端。
+
+在本文中，我们会发现，`#flush()` 方法和 `#write(Object msg, ...)` **正常**情况下，经历的流程是**差不多**的，例如在 pipeline 中对事件的传播，从 `tail` 节点传播到 `head` 节点，最终交由 Unsafe 处理，而差异点就是 Unsafe 的处理方式**不同**：
+
+- write 方法：将数据写到**内存队列**中。
+- flush 方法：刷新**内存队列**，将其中的数据写入到对端。
+
+当然，上述描述仅仅指的是**正常**情况下，在**异常**情况下会有所不同。我们知道，Channel 大多数情况下是**可写**的，所以不需要专门去注册 `SelectionKey.OP_WRITE` 事件。所以在 Netty 的实现中，默认 Channel 是**可写**的，当写入失败的时候，再去注册 `SelectionKey.OP_WRITE` 事件。这意味着什么呢？在 `#flush()` 方法中，如果写入数据到 Channel 失败，会通过注册 `SelectionKey.OP_WRITE` 事件，然后在轮询到 Channel **可写** 时，再“回调” `#forceFlush()` 方法。
+
+是不是非常巧妙？！让我直奔代码，大口吃肉，潇洒撸码。
+
+> 下文的 [「2.」](https://svip.iocoder.cn/Netty/Channel-5-flush/#)、[「3.」](https://svip.iocoder.cn/Netty/Channel-5-flush/#)、[「4.」](https://svip.iocoder.cn/Netty/Channel-5-flush/#)、[「5.」](https://svip.iocoder.cn/Netty/Channel-5-flush/#) 和 [《精尽 Netty 源码解析 —— Channel（四）之 write 操作》](http://svip.iocoder.cn/Netty/Channel-4-write) 非常**类似**，所以胖友可以快速浏览。真正的**差异**，从 [「6.」](https://svip.iocoder.cn/Netty/Channel-5-flush/#) 开始。
+
+# 2. AbstractChannel
+
+AbstractChannel 对 `#flush()` 方法的实现，代码如下：
+
+```
+@Override
+public Channel flush() {
+    pipeline.flush();
+    return this;
+}
+```
+
+- 在方法内部，会调用对应的
+
+   
+
+  ```
+  ChannelPipeline#flush()
+  ```
+
+   
+
+  方法，将 flush 事件在 pipeline 上传播。详细解析，见
+
+   
+
+  「3. DefaultChannelPipeline」
+
+   
+
+  。
+
+  - 最终会传播 flush 事件到 `head` 节点，刷新**内存队列**，将其中的数据写入到对端。详细解析，见 [「5. HeadContext」](https://svip.iocoder.cn/Netty/Channel-5-flush/#) 。
+
+# 3. DefaultChannelPipeline
+
+`DefaultChannelPipeline#flush()` 方法，代码如下：
+
+```
+@Override
+public final ChannelPipeline flush() {
+    tail.flush();
+    return this;
+}
+```
+
+- 在方法内部，会调用 `TailContext#flush()` 方法，将 flush 事件在 pipeline 中，从尾节点向头节点传播。详细解析，见 [「4. TailContext」](https://svip.iocoder.cn/Netty/Channel-5-flush/#) 。
+
+# 4. TailContext
+
+TailContext 对 `TailContext#flush()` 方法的实现，是从 AbstractChannelHandlerContext 抽象类继承，代码如下：
+
+```
+ 1: @Override
+ 2: public ChannelHandlerContext flush() {
+ 3:     // 获得下一个 Outbound 节点
+ 4:     final AbstractChannelHandlerContext next = findContextOutbound();
+ 5:     EventExecutor executor = next.executor();
+ 6:     // 在 EventLoop 的线程中
+ 7:     if (executor.inEventLoop()) {
+ 8:         // 执行 flush 事件到下一个节点
+ 9:         next.invokeFlush();
+10:     // 不在 EventLoop 的线程中
+11:     } else {
+12:         // 创建 flush 任务
+13:         Runnable task = next.invokeFlushTask;
+14:         if (task == null) {
+15:             next.invokeFlushTask = task = new Runnable() {
+16:                 @Override
+17:                 public void run() {
+18:                     next.invokeFlush();
+19:                 }
+20:             };
+21:         }
+22:         // 提交到 EventLoop 的线程中，执行该任务
+23:         safeExecute(executor, task, channel().voidPromise(), null);
+24:     }
+25: 
+26:     return this;
+27: }
+```
+
+- 第 4 行：调用 `#findContextOutbound()` 方法，获得**下一个** Outbound 节点。
+
+- 第 7 行：
+
+  在
+
+   
+
+  EventLoop 的线程中。
+
+  - 第 12 至 15 行：调用 `AbstractChannelHandlerContext#invokeFlush()()` 方法，执行 flush 事件到下一个节点。
+  - 后续的逻辑，和 [《精尽 Netty 源码解析 —— ChannelPipeline（四）之 Outbound 事件的传播》](http://svip.iocoder.cn/Netty/Pipeline-4-outbound/) 分享的 **bind** 事件在 pipeline 中的传播是**基本一致**的。
+  - 随着 flush **事件**不断的向下一个节点传播，最终会到达 HeadContext 节点。详细解析，见 [「5. HeadContext」](https://svip.iocoder.cn/Netty/Channel-5-flush/#) 。
+
+- 第 16 行：
+
+  不在
+
+   
+
+  EventLoop 的线程中。
+
+  - 第 12 至 21 行：创建 flush 任务。该任务的内部的调用【第 18 行】的代码，和【第 9 行】的代码是**一致**的。
+  - 第 23 行：调用 `#safeExecute(executor, task, promise, m)` 方法，提交到 EventLoop 的线程中，执行该任务。从而实现，**在** EventLoop 的线程中，执行 flush 事件到下一个节点。
+
+# 5. HeadContext
+
+在 pipeline 中，flush 事件最终会到达 HeadContext 节点。而 HeadContext 的 `#flush()` 方法，会处理该事件，代码如下：
+
+```
+@Override
+public void flush(ChannelHandlerContext ctx) throws Exception {
+    unsafe.flush();
+}
+```
+
+- 在方法内部，会调用 `AbstractUnsafe#flush()` 方法，刷新**内存队列**，将其中的数据写入到对端。详细解析，见 [「6. AbstractUnsafe」](https://svip.iocoder.cn/Netty/Channel-5-flush/#) 。
+
+# 6. AbstractUnsafe
+
+`AbstractUnsafe#flush()` 方法，刷新**内存队列**，将其中的数据写入到对端。代码如下：
+
+```
+ 1: @Override
+ 2: public final void flush() {
+ 3:     assertEventLoop();
+ 4: 
+ 5:     // 内存队列为 null ，一般是 Channel 已经关闭，所以直接返回。
+ 6:     ChannelOutboundBuffer outboundBuffer = this.outboundBuffer;
+ 7:     if (outboundBuffer == null) {
+ 8:         return;
+ 9:     }
+10: 
+11:     // 标记内存队列开始 flush
+12:     outboundBuffer.addFlush();
+13:     // 执行 flush
+14:     flush0();
+15: }
+```
+
+- 第 5 至 9 行：内存队列为 `null` ，一般是 Channel **已经关闭**，所以直接返回。
+
+- 第 12 行：调用 `ChannelOutboundBuffer#addFlush()` 方法，标记内存队列开始 **flush** 。详细解析，见 [「8.4 addFlush」](https://svip.iocoder.cn/Netty/Channel-5-flush/#) 。
+
+- 第 14 行：调用 `#flush0()` 方法，执行 flush 操作。代码如下：
+
+  ```
+  /**
+   * 是否正在 flush 中，即正在调用 {@link #flush0()} 中
+   */
+  private boolean inFlush0;
+  
+    1: @SuppressWarnings("deprecation")
+    2: protected void flush0() {
+    3:     // 正在 flush 中，所以直接返回。
+    4:     if (inFlush0) {
+    5:         // Avoid re-entrance
+    6:         return;
+    7:     }
+    8: 
+    9:     // 内存队列为 null ，一般是 Channel 已经关闭，所以直接返回。
+   10:     // 内存队列为空，无需 flush ，所以直接返回
+   11:     final ChannelOutboundBuffer outboundBuffer = this.outboundBuffer;
+   12:     if (outboundBuffer == null || outboundBuffer.isEmpty()) {
+   13:         return;
+   14:     }
+   15: 
+   16:     // 标记正在 flush 中。
+   17:     inFlush0 = true;
+   18: 
+   19:     // 若未激活，通知 flush 失败
+   20:     // Mark all pending write requests as failure if the channel is inactive.
+   21:     if (!isActive()) {
+   22:         try {
+   23:             if (isOpen()) {
+   24:                 outboundBuffer.failFlushed(FLUSH0_NOT_YET_CONNECTED_EXCEPTION, true);
+   25:             } else {
+   26:                 // Do not trigger channelWritabilityChanged because the channel is closed already.
+   27:                 outboundBuffer.failFlushed(FLUSH0_CLOSED_CHANNEL_EXCEPTION, false);
+   28:             }
+   29:         } finally {
+   30:             // 标记不在 flush 中。
+   31:             inFlush0 = false;
+   32:         }
+   33:         return;
+   34:     }
+   35: 
+   36:     // 执行真正的写入到对端
+   37:     try {
+   38:         doWrite(outboundBuffer);
+   39:     } catch (Throwable t) {
+   40:         // TODO 芋艿 细节
+   41:         if (t instanceof IOException && config().isAutoClose()) {
+   42:             /**
+   43:              * Just call {@link #close(ChannelPromise, Throwable, boolean)} here which will take care of
+   44:              * failing all flushed messages and also ensure the actual close of the underlying transport
+   45:              * will happen before the promises are notified.
+   46:              *
+   47:              * This is needed as otherwise {@link #isActive()} , {@link #isOpen()} and {@link #isWritable()}
+   48:              * may still return {@code true} even if the channel should be closed as result of the exception.
+   49:              */
+   50:             close(voidPromise(), t, FLUSH0_CLOSED_CHANNEL_EXCEPTION, false);
+   51:         } else {
+   52:             try {
+   53:                 shutdownOutput(voidPromise(), t);
+   54:             } catch (Throwable t2) {
+   55:                 close(voidPromise(), t2, FLUSH0_CLOSED_CHANNEL_EXCEPTION, false);
+   56:             }
+   57:         }
+   58:     } finally {
+   59:         // 标记不在 flush 中。
+   60:         inFlush0 = false;
+   61:     }
+   62: }
+  ```
+
+  - `inFlush0` 字段，是否正在 flush 中，即正在调用 `#flush0()` 中。
+
+  - 第 3 至 7 行：正在 flush 中，所以直接返回。
+
+  - 第 9 至 14 行：
+
+    - `outboundBuffer == null` ，内存队列为 `null` ，一般是 Channel 已经**关闭**，所以直接返回。
+    - `outboundBuffer.isEmpty()` ，内存队列为空，无需 flush ，所以直接返回。
+
+  - 第 17 行：设置 `inFlush0` 为 `true` ，表示正在 flush 中。
+
+  - 第 19 至 34 行：调用
+
+     
+
+    ```
+    #isActive()
+    ```
+
+     
+
+    方法，发现 Channel
+
+     
+
+    未激活
+
+    ，在根据 Channel
+
+     
+
+    是否打开
+
+    ，调用
+
+     
+
+    ```
+    ChannelOutboundBuffer#failFlushed(Throwable cause, boolean notify)
+    ```
+
+     
+
+    方法，通知 flush 失败
+
+    异常
+
+    。详细解析，见
+
+     
+
+    「8.6 failFlushed」
+
+     
+
+    。
+
+    - 第 29 至 33 行：最终，设置 `inFlush0` 为 `false` ，表示结束 flush 操作，最后 `return` 返回。
+
+  - 第 38 行：调用
+
+     
+
+    ```
+    AbstractChannel#doWrite(outboundBuffer)
+    ```
+
+     
+
+    方法，
+
+    执行真正的写入到对端
+
+    。详细解析，见
+
+     
+
+    「7. NioSocketChannel」
+
+     
+
+    。
+
+    - 第 39 至 57 行：TODO 芋艿 细节
+    - 第 58 至 61 行：同【第 29 至 33】的代码和目的。
+
+- 实际上，AbstractNioUnsafe **重写**了 `#flush0()` 方法，代码如下：
+
+  ```
+  @Override
+  protected final void flush0() {
+      // Flush immediately only when there's no pending flush.
+      // If there's a pending flush operation, event loop will call forceFlush() later,
+      // and thus there's no need to call it now.
+      if (!isFlushPending()) {
+          super.flush0();
+      }
+  }
+  ```
+
+  - 在执行父类 AbstractUnsafe 的 `#flush0()` 方法时，先调用 `AbstractNioUnsafe#isFlushPending()` 判断，是否已经处于 flush **准备**中。代码如下：
+
+    ```
+    private boolean isFlushPending() {
+        SelectionKey selectionKey = selectionKey();
+        return selectionKey.isValid() // 合法
+                && (selectionKey.interestOps() & SelectionKey.OP_WRITE) != 0; // 对 SelectionKey.OP_WRITE 事件不感兴趣。
+    }
+    ```
+
+    - 是不是有点懵 x ？在文初，我们提到：“所以在 Netty 的实现中，默认 Channel 是**可写**的，当写入失败的时候，再去注册 `SelectionKey.OP_WRITE` 事件。这意味着什么呢？在 `#flush()` 方法中，如果写入数据到 Channel 失败，会通过注册 `SelectionKey.OP_WRITE` 事件，然后在轮询到 Channel **可写** 时，再“回调” `#forceFlush()` 方法”。
+    - 这就是这段代码的目的，如果处于对 `SelectionKey.OP_WRITE` 事件感兴趣，说明 Channel 此时是**不可写**的，那么调用父类 AbstractUnsafe 的 `#flush0()` 方法，**也没有意义**，所以就不调用。
+    - 😈 逻辑上，略微有点复杂，胖友好好理解下。
+
+# 7. NioSocketChannel
+
+`AbstractChannel#doWrite(ChannelOutboundBuffer in)` **抽象**方法，**执行真正的写入到对端**。定义在 AbstractChannel **抽象**类中，代码如下：
+
+```
+/**
+ * Flush the content of the given buffer to the remote peer.
+ */
+protected abstract void doWrite(ChannelOutboundBuffer in) throws Exception;
+```
+
+------
+
+NioSocketChannel 对该**抽象**方法，实现代码如下：
+
+```
+ 1: @Override
+ 2: protected void doWrite(ChannelOutboundBuffer in) throws Exception {
+ 3:     SocketChannel ch = javaChannel();
+ 4:     // 获得自旋写入次数
+ 5:     int writeSpinCount = config().getWriteSpinCount();
+ 6:     do {
+ 7:         // 内存队列为空，结束循环，直接返回
+ 8:         if (in.isEmpty()) {
+ 9:             // 取消对 SelectionKey.OP_WRITE 的感兴趣
+10:             // All written so clear OP_WRITE
+11:             clearOpWrite();
+12:             // Directly return here so incompleteWrite(...) is not called.
+13:             return;
+14:         }
+15: 
+16:         // 获得每次写入的最大字节数
+17:         // Ensure the pending writes are made of ByteBufs only.
+18:         int maxBytesPerGatheringWrite = ((NioSocketChannelConfig) config).getMaxBytesPerGatheringWrite();
+19:         // 从内存队列中，获得要写入的 ByteBuffer 数组
+20:         ByteBuffer[] nioBuffers = in.nioBuffers(1024, maxBytesPerGatheringWrite);
+21:         // 写入的 ByteBuffer 数组的个数
+22:         int nioBufferCnt = in.nioBufferCount();
+23: 
+24:         // 写入 ByteBuffer 数组，到对端
+25:         // Always us nioBuffers() to workaround data-corruption.
+26:         // See https://github.com/netty/netty/issues/2761
+27:         switch (nioBufferCnt) {
+28:             case 0:
+29:                 // 芋艿 TODO 1014 扣 doWrite0 的细节
+30:                 // We have something else beside ByteBuffers to write so fallback to normal writes.
+31:                 writeSpinCount -= doWrite0(in);
+32:                 break;
+33:             case 1: {
+34:                 // Only one ByteBuf so use non-gathering write
+35:                 // Zero length buffers are not added to nioBuffers by ChannelOutboundBuffer, so there is no need
+36:                 // to check if the total size of all the buffers is non-zero.
+37:                 ByteBuffer buffer = nioBuffers[0];
+38:                 int attemptedBytes = buffer.remaining();
+39:                 // 执行 NIO write 调用，写入单个 ByteBuffer 对象到对端
+40:                 final int localWrittenBytes = ch.write(buffer);
+41:                 // 写入字节小于等于 0 ，说明 NIO Channel 不可写，所以注册 SelectionKey.OP_WRITE ，等待 NIO Channel 可写，并返回以结束循环
+42:                 if (localWrittenBytes <= 0) {
+43:                     incompleteWrite(true);
+44:                     return;
+45:                 }
+46:                 // TODO 芋艿 调整每次写入的最大字节数
+47:                 adjustMaxBytesPerGatheringWrite(attemptedBytes, localWrittenBytes, maxBytesPerGatheringWrite);
+48:                 // 从内存队列中，移除已经写入的数据( 消息 )
+49:                 in.removeBytes(localWrittenBytes);
+50:                 // 写入次数减一
+51:                 --writeSpinCount;
+52:                 break;
+53:             }
+54:             default: {
+55:                 // Zero length buffers are not added to nioBuffers by ChannelOutboundBuffer, so there is no need
+56:                 // to check if the total size of all the buffers is non-zero.
+57:                 // We limit the max amount to int above so cast is safe
+58:                 long attemptedBytes = in.nioBufferSize();
+59:                 // 执行 NIO write 调用，写入多个 ByteBuffer 到对端
+60:                 final long localWrittenBytes = ch.write(nioBuffers, 0, nioBufferCnt);
+61:                 // 写入字节小于等于 0 ，说明 NIO Channel 不可写，所以注册 SelectionKey.OP_WRITE ，等待 NIO Channel 可写，并返回以结束循环
+62:                 if (localWrittenBytes <= 0) {
+63:                     incompleteWrite(true);
+64:                     return;
+65:                 }
+66:                 // TODO 芋艿 调整每次写入的最大字节数
+67:                 // Casting to int is safe because we limit the total amount of data in the nioBuffers to int above.
+68:                 adjustMaxBytesPerGatheringWrite((int) attemptedBytes, (int) localWrittenBytes, maxBytesPerGatheringWrite);
+69:                 // 从内存队列中，移除已经写入的数据( 消息 )
+70:                 in.removeBytes(localWrittenBytes);
+71:                 // 写入次数减一
+72:                 --writeSpinCount;
+73:                 break;
+74:             }
+75:         }
+76:     } while (writeSpinCount > 0); // 循环自旋写入
+77: 
+78:     // 内存队列中的数据未完全写入，说明 NIO Channel 不可写，所以注册 SelectionKey.OP_WRITE ，等待 NIO Channel 可写
+79:     incompleteWrite(writeSpinCount < 0);
+80: }
+```
+
+- 第 3 行：调用 `#javaChannel()` 方法，获得 Java NIO **原生** SocketChannel 。
+
+- 第 5 行：调用 `ChannelConfig#getWriteSpinCount()` 方法，获得**自旋**写入次数 N 。在【第 6 至 76 行】的代码，我们可以看到，不断**自旋**写入 N 次，直到完成写入结束。关于该配置项，官方注释如下：
+
+  ```
+  /**
+   * Returns the maximum loop count for a write operation until {@link WritableByteChannel#write(ByteBuffer)} returns a non-zero value.
+   * It is similar to what a spin lock is used for in concurrency programming.
+   * It improves memory utilization and write throughput depending on the platform that JVM runs on.  The default value is {@code 16}.
+   */
+  int getWriteSpinCount();
+  ```
+
+  - 默认值为 `DefaultChannelConfig.writeSpinCount = 16` ，可配置修改，一般不需要。
+
+- 第 6 至 76 行：不断**自旋**写入 N 次，直到完成写入结束。
+
+- 第 8 行：调用 `ChannelOutboundBuffer#isEmpty()` 方法，内存队列为空，结束循环，直接返回。
+
+  - 第 10 行：因为在 Channel **不可写**的时候，会注册 `SelectionKey.OP_WRITE` ，等待 NIO Channel 可写。而后会”回调” `#forceFlush()` 方法，该方法内部也会调用 `#doWrite(ChannelOutboundBuffer in)` 方法。所以在完成内部队列的数据向对端写入时候，需要调用 `#clearOpWrite()` 方法，代码如下：
+
+    ```
+    protected final void clearOpWrite() {
+        final SelectionKey key = selectionKey();
+        // Check first if the key is still valid as it may be canceled as part of the deregistration
+        // from the EventLoop
+        // See https://github.com/netty/netty/issues/2104
+        if (!key.isValid()) { // 合法
+            return;
+        }
+        final int interestOps = key.interestOps();
+        // 若注册了 SelectionKey.OP_WRITE ，则进行取消
+        if ((interestOps & SelectionKey.OP_WRITE) != 0) {
+            key.interestOps(interestOps & ~SelectionKey.OP_WRITE);
+        }
+    }
+    ```
+
+    - 😈 胖友看下代码注释。
+
+- 第 18 行：调用 `NioSocketChannelConfig#getMaxBytesPerGatheringWrite()` 方法，获得每次写入的最大字节数。// TODO 芋艿 调整每次写入的最大字节数
+
+- 第 20 行：调用
+
+   
+
+  ```
+  ChannelOutboundBuffer#nioBuffers(int maxCount, long maxBytes)
+  ```
+
+   
+
+  方法，从内存队列中，获得要写入的 ByteBuffer 数组。
+
+  注意
+
+  ，如果内存队列中数据量很大，可能获得的仅仅是一部分数据。详细解析，见
+
+   
+
+  「8.5 nioBuffers」
+
+   
+
+  。
+
+  - 第 22 行：获得写入的 ByteBuffer 数组的个数。为什么不直接调用数组的 `#length()` 方法呢？因为返回的 ByteBuffer 数组是**预先生成的数组缓存**，存在不断重用的情况，所以不能直接使用 `#length()` 方法，而是要调用 `ChannelOutboundBuffer#nioBufferCount()` 方法，获得写入的 ByteBuffer 数组的个数。详细解析，见 [「8.5 nioBuffers」](https://svip.iocoder.cn/Netty/Channel-5-flush/#) 。
+  - 后续根据 `nioBufferCnt` 的数值，分成**三种**情况。
+
+- **(づ￣3￣)づ╭❤～ 第一种**，`nioBufferCnt = 0` 。
+
+- 芋艿 TODO 1014 扣 doWrite0 的细节，应该是内部的数据为 FileRegion ，可以暂时无视，不影响本文理解。
+
+- **(づ￣3￣)づ╭❤～ 第二种**，`nioBufferCnt = 1` 。
+
+- 第 40 行：调用 Java **原生** `SocketChannel#write(ByteBuffer buffer)` 方法，执行 NIO write 调用，写入**单个** ByteBuffer 对象到对端。
+
+- 第 42 行：写入字节小于等于 0 ，说明 NIO Channel **不可写**，所以注册 `SelectionKey.OP_WRITE` ，等待 NIO Channel **可写**，并返回以结束循环。
+
+  - 第 43 行：调用 `AbstractNioByteChannel#incompleteWrite(true)` 方法，代码如下：
+
+    ```
+    protected final void incompleteWrite(boolean setOpWrite) {
+        // Did not write completely.
+        // true ，注册对 SelectionKey.OP_WRITE 事件感兴趣
+        if (setOpWrite) {
+            setOpWrite();
+        // false ，取消对 SelectionKey.OP_WRITE 事件感兴趣
+        } else {
+            // It is possible that we have set the write OP, woken up by NIO because the socket is writable, and then
+            // use our write quantum. In this case we no longer want to set the write OP because the socket is still
+            // writable (as far as we know). We will find out next time we attempt to write if the socket is writable
+            // and set the write OP if necessary.
+            clearOpWrite();
+    
+            // Schedule flush again later so other tasks can be picked up in the meantime
+            // 立即发起下一次 flush 任务
+            eventLoop().execute(flushTask); // <1>
+        }
+    }
+    ```
+
+    - `setOpWrite` 为 `true` ，调用 `#setOpWrite()` 方法，注册对 `SelectionKey.OP_WRITE` 事件感兴趣。代码如下：
+
+      ```
+      protected final void setOpWrite() {
+          final SelectionKey key = selectionKey();
+          // Check first if the key is still valid as it may be canceled as part of the deregistration
+          // from the EventLoop
+          // See https://github.com/netty/netty/issues/2104
+          if (!key.isValid()) { // 合法
+              return;
+          }
+          final int interestOps = key.interestOps();
+          // 注册 SelectionKey.OP_WRITE 事件的感兴趣
+          if ((interestOps & SelectionKey.OP_WRITE) == 0) {
+              key.interestOps(interestOps | SelectionKey.OP_WRITE);
+          }
+      }
+      ```
+
+      - 【第 43 行】的代码，就是这种情况。
+
+    - `setOpWrite` 为 `false` ，调用 `#clearOpWrite()` 方法，取消对 SelectionKey.OP_WRITE 事件感兴趣。而后，在 `<1>` 处，立即发起下一次 flush 任务。
+
+- 第 47 行：TODO 芋艿 调整每次写入的最大字节数
+
+- 第 49 行：调用 `ChannelOutboundBuffer#removeBytes(long writtenBytes)` 方法啊，从内存队列中，移除已经写入的数据( 消息 )。详细解析，见 [「8.7 removeBytes」](https://svip.iocoder.cn/Netty/Channel-5-flush/#) 。
+
+- 第 51 行：写入次数减一。
+
+- **(づ￣3￣)づ╭❤～ 第三种**，`nioBufferCnt > 1` 。和【第二种】基本相同，差别是在于【第 60 行】的代码，调用 Java **原生** `SocketChannel#write(ByteBuffer[] srcs, int offset, int length)` 方法，执行 NIO write 调用，写入**多个** ByteBuffer 对象到对端。😈 批量一次性写入，提升性能。
+
+- =========== 结束 ===========
+
+- 第 79 行：通过
+
+   
+
+  ```
+  writeSpinCount < 0
+  ```
+
+   
+
+  来判断，内存队列中的数据
+
+  是否
+
+  未完全写入。从目前逻辑看下来，笔者认为只会返回
+
+   
+
+  ```
+  true
+  ```
+
+   
+
+  ，即内存队列中的数据未完全写入，说明 NIO Channel 不可写，所以注册
+
+   
+
+  ```
+  SelectionKey.OP_WRITE
+  ```
+
+   
+
+  ，等待 NIO Channel 可写。因此，调用
+
+   
+
+  ```
+  #incompleteWrite(true)
+  ```
+
+   
+
+  方法。
+
+  - 举个例子，最后一次写入，Channel 的缓冲区还剩下 10 字节可写，内存队列中剩余 90 字节，那么可以成功写入 10 字节，剩余 80 字节。😈 也就说，此时 Channel 不可写落。
+
+## 7.1 乱入
+
+> 老艿艿：临时插入下 AbstractNioByteChannel 和 AbstractNioMessageChannel 实现类对 `#doWrite(ChannelOutboundBuffer in)` 方法的实现。不感兴趣的胖友，可以直接跳过。
+
+**AbstractNioByteChannel**
+
+虽然，AbstractNioByteChannel 实现了 `#doWrite(ChannelOutboundBuffer in)` 方法，但是子类 NioSocketChannel 又覆盖实现了该方法，所以可以忽略 AbstractNioByteChannel 的实现方法了。
+
+那么为什么 AbstractNioByteChannel 会实现了 `#doWrite(ChannelOutboundBuffer in)` 方法呢？因为 NioUdtByteConnectorChannel 和 NioUdtByteRendezvousChannel 会使用到该方法。但是，这两个类已经被**标记废弃**，因为：
+
+```
+transport udt is deprecated and so the user knows it will be removed in the future.
+```
+
+- 来自 Netty 官方提交的注释说明。
+
+**AbstractNioMessageChannel**
+
+虽然，AbstractNioMessageChannel 实现了 `#doWrite(ChannelOutboundBuffer in)` 方法，但是对于 NioServerSocketChannel 来说，暂时没有意义，因为：
+
+```
+@Override
+protected boolean doWriteMessage(Object msg, ChannelOutboundBuffer in) throws Exception {
+    throw new UnsupportedOperationException();
+}
+
+@Override
+protected final Object filterOutboundMessage(Object msg) throws Exception {
+    throw new UnsupportedOperationException();
+}
+```
+
+- 两个方法，都是直接抛出 UnsupportedOperationException 异常。
+
+那么为什么 AbstractNioMessageChannel 会实现了 `#doWrite(ChannelOutboundBuffer in)` 方法呢？因为 NioDatagramChannel 和 NioSctpChannel **等等**会使用到该方法。感兴趣的胖友，可以自己研究下。
+
+# 8. ChannelOutboundBuffer
+
+`io.netty.channel.ChannelOutboundBuffer` ，**内存队列**。
+
+- 在 write 操作时，将数据写到 ChannelOutboundBuffer 中。
+- 在 flush 操作时，将 ChannelOutboundBuffer 的数据写入到对端。
+
+## 8.1 Entry
+
+在 write 操作时，将数据写到 ChannelOutboundBuffer 中，都会产生一个 Entry 对象。代码如下：
+
+```
+/**
+ * Recycler 对象，用于重用 Entry 对象
+ */
+private static final Recycler<Entry> RECYCLER = new Recycler<Entry>() {
+    @Override
+    protected Entry newObject(Handle<Entry> handle) {
+        return new Entry(handle);
+    }
+};
+
+/**
+ * Recycler 处理器
+ */
+private final Handle<Entry> handle;
+/**
+ * 下一条 Entry
+ */
+Entry next;
+/**
+ * 消息（数据）
+ */
+Object msg;
+/**
+ * {@link #msg} 转化的 NIO ByteBuffer 数组
+ */
+ByteBuffer[] bufs;
+/**
+ * {@link #msg} 转化的 NIO ByteBuffer 对象
+ */
+ByteBuffer buf;
+/**
+ * Promise 对象
+ */
+ChannelPromise promise;
+/**
+ * 已写入的字节数
+ */
+long progress;
+/**
+ * 长度，可读字节数数。
+ */
+long total;
+/**
+ * 每个 Entry 预计占用的内存大小，计算方式为消息( {@link #msg} )的字节数 + Entry 对象自身占用内存的大小。
+ */
+int pendingSize;
+/**
+ * {@link #msg} 转化的 NIO ByteBuffer 的数量。
+ *
+ * 当 = 1 时，使用 {@link #buf}
+ * 当 > 1 时，使用 {@link #bufs}
+ */
+int count = -1;
+/**
+ * 是否取消写入对端
+ */
+boolean cancelled;
+
+private Entry(Handle<Entry> handle) {
+    this.handle = handle;
+}
+```
+
+- ```
+  RECYCLER
+  ```
+
+   
+
+  静态
+
+  属性，用于
+
+  重用
+
+   
+
+  Entry 对象。
+
+  - `handle` 属性，Recycler 处理器，用于**回收** Entry 对象。
+
+- `next` 属性，指向**下一条** Entry 。通过它，形成 ChannelOutboundBuffer 内部的链式存储**每条写入数据**的数据结构。
+
+- `msg` 属性，写入的消息( 数据 )。
+
+  - `promise` 属性，Promise 对象。当数据写入成功后，可以通过它回调通知结果。
+
+  - `total` 属性，长度，可读字节数。通过 `#total(Object msg)` 方法来计算。代码如下：
+
+    ```
+    private static long total(Object msg) {
+        if (msg instanceof ByteBuf) {
+            return ((ByteBuf) msg).readableBytes();
+        }
+        if (msg instanceof FileRegion) {
+            return ((FileRegion) msg).count();
+        }
+        if (msg instanceof ByteBufHolder) {
+            return ((ByteBufHolder) msg).content().readableBytes();
+        }
+        return -1;
+    }
+    ```
+
+    - 从这个方法，我们看到，`msg` 的类型，有 ByteBuf、FileRegion、ByteBufHolder 。
+
+  - `process` 属性，已写入的字节数。详细解析，见 [「8.7.1 process」](https://svip.iocoder.cn/Netty/Channel-5-flush/#) 。
+
+- ```
+  count
+  ```
+
+   
+
+  属性，
+
+  ```
+  msg
+  ```
+
+   
+
+  属性转化的 NIO ByteBuffer 的数量。
+
+  - `bufs` 属性，当 `count > 0` 时使用，表示 `msg` 属性转化的 NIO ByteBuffer 数组。
+  - `buf` 属性，当 `count = 0` 时使用，表示 `msg` 属性转化的 NIO ByteBuffer 对象。
+
+- `cancelled` 属性，是否取消写入对端。
+
+- `pendingSize` 属性，每个 Entry 预计占用的内存大小，计算方式为消息( `msg` )的字节数 + Entry 对象自身占用内存的大小。
+
+### 8.1.1 newInstance
+
+`#newInstance(Object msg, int size, long total, ChannelPromise promise)` **静态**方法，创建 Entry 对象。代码如下：
+
+```
+static Entry newInstance(Object msg, int size, long total, ChannelPromise promise) {
+    // 通过 Recycler 重用对象
+    Entry entry = RECYCLER.get();
+    // 初始化属性
+    entry.msg = msg;
+    entry.pendingSize = size + CHANNEL_OUTBOUND_BUFFER_ENTRY_OVERHEAD;
+    entry.total = total;
+    entry.promise = promise;
+    return entry;
+}
+```
+
+- 通过 Recycler 来**重用** Entry 对象。
+
+### 8.1.2 recycle
+
+`#recycle()` 方法，**回收** Entry 对象，以为下次**重用**该对象。代码如下：
+
+```
+void recycle() {
+    // 重置属性
+    next = null;
+    bufs = null;
+    buf = null;
+    msg = null;
+    promise = null;
+    progress = 0;
+    total = 0;
+    pendingSize = 0;
+    count = -1;
+    cancelled = false;
+    // 回收 Entry 对象
+    handle.recycle(this);
+}
+```
+
+### 8.1.3 recycleAndGetNext
+
+`#recycleAndGetNext()` 方法，获得下一个 Entry 对象，并**回收**当前 Entry 对象。代码如下：
+
+```
+Entry recycleAndGetNext() {
+    // 获得下一个 Entry 对象
+    Entry next = this.next;
+    // 回收当前 Entry 对象
+    recycle();
+    // 返回下一个 Entry 对象
+    return next;
+}
+```
+
+### 8.1.4 cancel
+
+`#cancel()` 方法，标记 Entry 对象，取消写入到对端。在 ChannelOutboundBuffer 里，Entry 数组是通过**链式**的方式进行组织，而当某个 Entry 对象( **节点** )如果需要取消写入到对端，是通过设置 `canceled = true` 来**标记删除**。代码如下：
+
+```
+int cancel() {
+    if (!cancelled) {
+        // 标记取消
+        cancelled = true;
+        int pSize = pendingSize;
+
+        // 释放消息( 数据 )相关的资源
+        // release message and replace with an empty buffer
+        ReferenceCountUtil.safeRelease(msg);
+        // 设置为空 ByteBuf
+        msg = Unpooled.EMPTY_BUFFER;
+
+        // 置空属性
+        pendingSize = 0;
+        total = 0;
+        progress = 0;
+        bufs = null;
+        buf = null;
+
+        // 返回 pSize
+        return pSize;
+    }
+    return 0;
+}
+```
+
+## 8.2 构造方法
+
+```
+/**
+ * Entry 对象自身占用内存的大小
+ */
+// Assuming a 64-bit JVM:
+//  - 16 bytes object header
+//  - 8 reference fields
+//  - 2 long fields
+//  - 2 int fields
+//  - 1 boolean field
+//  - padding
+static final int CHANNEL_OUTBOUND_BUFFER_ENTRY_OVERHEAD = SystemPropertyUtil.getInt("io.netty.transport.outboundBufferEntrySizeOverhead", 96);
+
+private static final InternalLogger logger = InternalLoggerFactory.getInstance(ChannelOutboundBuffer.class);
+
+/**
+ * 线程对应的 ByteBuffer 数组缓存
+ * 
+ * 每次调用 {@link #nioBuffers(int, long)} 会重新生成
+ */
+private static final FastThreadLocal<ByteBuffer[]> NIO_BUFFERS = new FastThreadLocal<ByteBuffer[]>() {
+
+    @Override
+    protected ByteBuffer[] initialValue() throws Exception {
+        return new ByteBuffer[1024];
+    }
+
+};
+
+/**
+ * Channel 对象
+ */
+private final Channel channel;
+
+// Entry(flushedEntry) --> ... Entry(unflushedEntry) --> ... Entry(tailEntry)
+//
+/**
+ * 第一个( 开始 ) flush Entry
+ */
+// The Entry that is the first in the linked-list structure that was flushed
+private Entry flushedEntry;
+/**
+ * 第一个未 flush Entry
+ */
+// The Entry which is the first unflushed in the linked-list structure
+private Entry unflushedEntry;
+/**
+ * 尾 Entry
+ */
+// The Entry which represents the tail of the buffer
+private Entry tailEntry;
+/**
+ * 已 flush 但未写入对端的 Entry 数量
+ *
+ * {@link #addFlush()}
+ *
+ * The number of flushed entries that are not written yet
+ */
+private int flushed;
+
+/**
+ * {@link #NIO_BUFFERS} 数组大小
+ */
+private int nioBufferCount;
+/**
+ * {@link #NIO_BUFFERS} 字节数
+ */
+private long nioBufferSize;
+/**
+ * 正在通知 flush 失败中
+ */
+private boolean inFail;
+
+/**
+ * {@link #totalPendingSize} 的原子更新器
+ */
+private static final AtomicLongFieldUpdater<ChannelOutboundBuffer> TOTAL_PENDING_SIZE_UPDATER = AtomicLongFieldUpdater.newUpdater(ChannelOutboundBuffer.class, "totalPendingSize");
+/**
+ * 总共等待 flush 到对端的内存大小，通过 {@link Entry#pendingSize} 来合计。
+ */
+@SuppressWarnings("UnusedDeclaration")
+private volatile long totalPendingSize;
+
+/**
+ * {@link #unwritable} 的原子更新器
+ */
+private static final AtomicIntegerFieldUpdater<ChannelOutboundBuffer> UNWRITABLE_UPDATER = AtomicIntegerFieldUpdater.newUpdater(ChannelOutboundBuffer.class, "unwritable");
+/**
+ * 是否不可写
+ */
+@SuppressWarnings("UnusedDeclaration")
+private volatile int unwritable;
+
+/**
+ * 触发 Channel 可写的改变的任务
+ */
+private volatile Runnable fireChannelWritabilityChangedTask;
+
+ChannelOutboundBuffer(AbstractChannel channel) {
+    this.channel = channel;
+}
+```
+
+- `channel` 属性，所属的 Channel 对象。
+
+- 链式结构
+
+  - `flushedEntry` 属性，第一个( 开始 ) flush Entry 。
+  - `unflushedEntry` 属性，第一个**未** flush Entry 。
+  - `tailEntry` 属性，尾 Entry 。
+  - `flushed` 属性， 已 flush 但未写入对端的 Entry 数量。
+  - 指向关系是 `Entry(flushedEntry) --> ... Entry(unflushedEntry) --> ... Entry(tailEntry)` 。这样看，可能有点抽象，下文源码解析详细理解。
+
+- ```
+  NIO_BUFFERS
+  ```
+
+   
+
+  静态
+
+  属性，线程对应的 NIO ByteBuffer 数组缓存。在
+
+   
+
+  ```
+  AbstractChannel#doWrite(ChannelOutboundBuffer)
+  ```
+
+   
+
+  方法中，会调用
+
+   
+
+  ```
+  ChannelOutbound#nioBuffers(int maxCount, long maxBytes)
+  ```
+
+   
+
+  方法，初始化数组缓存。 详细解析，见
+
+   
+
+  「8.6 nioBuffers」
+
+   
+
+  中。
+
+  - `nioBufferCount` 属性：NIO ByteBuffer 数组的**数组**大小。
+  - `nioBufferSize` 属性：NIO ByteBuffer 数组的字**节**大小。
+
+- `inFail` 属性，正在通知 flush 失败中。详细解析，见 [「8.8 failFlushed」](https://svip.iocoder.cn/Netty/Channel-5-flush/#) 中。
+
+- ChannelOutboundBuffer 写入控制相关。😈 详细解析，见
+
+   
+
+  「10. ChannelOutboundBuffer」
+
+   
+
+  。
+
+  - ```
+    unwritable
+    ```
+
+     
+
+    属性，是否不可写。
+
+    - `UNWRITABLE_UPDATER` 静态属性，`unwritable` 属性的原子更新器。
+
+  - ```
+    totalPendingSize
+    ```
+
+     
+
+    属性，所有 Entry 预计占用的内存大小，通过
+
+     
+
+    ```
+    Entry.pendingSize
+    ```
+
+     
+
+    来合计。
+
+    - `TOTAL_PENDING_SIZE_UPDATER` 静态属性，`totalPendingSize` 属性的原子更新器。
+
+  - `fireChannelWritabilityChangedTask` 属性，触发 Channel 可写的改变的**任务**。
+
+  - ```
+    CHANNEL_OUTBOUND_BUFFER_ENTRY_OVERHEAD
+    ```
+
+     
+
+    静态
+
+    属性，每个 Entry 对象自身占用内存的大小。为什么占用的 96 字节呢？
+
+    - `- 16 bytes object header` ，对象头，16 字节。
+    - `- 8 reference fields` ，实际是 6 个**对象引用**字段，6 * 8 = 48 字节。
+    - `- 2 long fields` ，2 个 `long` 字段，2 * 8 = 16 字节。
+    - `- 2 int fields` ，1 个 `int` 字段，2 * 4 = 8 字节。
+    - `- 1 boolean field` ，1 个 `boolean` 字段，1 字节。
+    - `padding` ，补齐 8 字节的整数倍，因此 7 字节。
+    - 因此，合计 96 字节( 64 位的 JVM 虚拟机，并且不考虑压缩 )。
+    - 如果不理解的胖友，可以看看 [《JVM中 对象的内存布局 以及 实例分析》](https://www.jianshu.com/p/12a3c97dc2b7) 。
+
+## 8.3 addMessage
+
+`#addMessage(Object msg, int size, ChannelPromise promise)` 方法，写入消息( 数据 )到内存队列。**注意**，`promise` 只有在真正完成写入到对端操作，才会进行通知。代码如下：
+
+```
+ 1: /**
+ 2:  * Add given message to this {@link ChannelOutboundBuffer}. The given {@link ChannelPromise} will be notified once
+ 3:  * the message was written.
+ 4:  */
+ 5: public void addMessage(Object msg, int size, ChannelPromise promise) {
+ 6:     // 创建新 Entry 对象
+ 7:     Entry entry = Entry.newInstance(msg, size, total(msg), promise);
+ 8:     // 若 tailEntry 为空，将 flushedEntry 也设置为空。防御型编程，实际不会出现
+ 9:     if (tailEntry == null) {
+10:         flushedEntry = null;
+11:     // 若 tailEntry 非空，将原 tailEntry 指向新 Entry
+12:     } else {
+13:         Entry tail = tailEntry;
+14:         tail.next = entry;
+15:     }
+16:     // 更新 tailEntry 为新 Entry
+17:     tailEntry = entry;
+18:     // 若 unflushedEntry 为空，更新为新 Entry
+19:     if (unflushedEntry == null) {
+20:         unflushedEntry = entry;
+21:     }
+22: 
+23:     // 增加 totalPendingSize 计数
+24:     // increment pending bytes after adding message to the unflushed arrays.
+25:     // See https://github.com/netty/netty/issues/1619
+26:     incrementPendingOutboundBytes(entry.pendingSize, false);
+27: }
+```
+
+- 第 7 行：调用 `#newInstance(Object msg, int size, long total, ChannelPromise promise)` **静态**方法，创建 Entry 对象。
+
+- 第 11 至 17 行：修改
+
+  尾
+
+  节点
+
+   
+
+  ```
+  tailEntry
+  ```
+
+   
+
+  为新的 Entry 节点。
+
+  - 第 8 至 10 行：若 `tailEntry` 为空，将 `flushedEntry` 也设置为空。防御型编程，实际不会出现，胖友可以忽略。😈 当然，原因在 `#removeEntry(Entry e)` 方法。
+  - 第 11 至 15 行：若 `tailEntry` 非空，将原 `tailEntry.next` 指向**新** Entry 。
+  - 第 17 行：更新原 `tailEntry` 为新 Entry 。
+
+- 第 18 至 21 行：若 `unflushedEntry` 为空，则更新为新 Entry ，此时相当于**首**节点。
+
+- 第 23 至 26 行：`#incrementPendingOutboundBytes(long size, ...)` 方法，增加 `totalPendingSize` 计数。详细解析，见 [「10.1 incrementPendingOutboundBytes」](https://svip.iocoder.cn/Netty/Channel-5-flush/#) 。
+
+------
+
+可能有点抽象，我们来看看基友【闪电侠】对这块的解析：
+
+> FROM 闪电侠 [《netty 源码分析之 writeAndFlush 全解析》](https://www.jianshu.com/p/feaeaab2ce56)
+>
+> 初次调用 `addMessage` 之后，各个指针的情况为
+>
+> [![img](31-Netty 源码解析-Channel（五）之 flush 操作.assets/1ff7a5d2b08b9e6160dd92e74e68145f.png)](http://static.iocoder.cn/1ff7a5d2b08b9e6160dd92e74e68145f)
+>
+> `fushedEntry`指向空，`unFushedEntry`和 `tailEntry` 都指向新加入的节点
+>
+> 第二次调用 `addMessage` 之后，各个指针的情况为
+>
+> [![img](31-Netty 源码解析-Channel（五）之 flush 操作.assets/1f939423f079ff491b90c8300e7ef3ea.png)](http://static.iocoder.cn/1f939423f079ff491b90c8300e7ef3ea)
+>
+> 第 n 次调用 `addMessage`之后，各个指针的情况为
+>
+> [![img](31-Netty 源码解析-Channel（五）之 flush 操作.assets/c0077b0dc86ecf1b791a99eeb9664fc3.png)](http://static.iocoder.cn/c0077b0dc86ecf1b791a99eeb9664fc3)
+>
+> 可以看到，调用 n 次 `addMessage` ，`flushedEntry` 指针一直指向 NULL ，表示现在还未有节点需要写出到 Socket 缓冲区，而`unFushedEntry` 之后有 n 个节点，表示当前还有n个节点尚未写出到 Socket 缓冲区中去
+
+## 8.4 addFlush
+
+`#addFlush()` 方法，标记内存队列每个 Entry 对象，开始 **flush** 。代码如下：
+
+> 老艿艿：总觉得这个方法名取的有点奇怪，胖友可以直接看英文注释。😈 我“翻译”不好，哈哈哈。
+
+```
+ 1: public void addFlush() {
+ 2:     // There is no need to process all entries if there was already a flush before and no new messages
+ 3:     // where added in the meantime.
+ 4:     //
+ 5:     // See https://github.com/netty/netty/issues/2577
+ 6:     Entry entry = unflushedEntry;
+ 7:     if (entry != null) {
+ 8:         // 若 flushedEntry 为空，赋值为 unflushedEntry ，用于记录第一个( 开始 ) flush 的 Entry 。
+ 9:         if (flushedEntry == null) {
+10:             // there is no flushedEntry yet, so start with the entry
+11:             flushedEntry = entry;
+12:         }
+13:         // 计算 flush 的数量，并设置每个 Entry 对应的 Promise 不可取消
+14:         do {
+15:             // 增加 flushed
+16:             flushed ++;
+17:             // 设置 Promise 不可取消
+18:             if (!entry.promise.setUncancellable()) { // 设置失败
+19:                 // 减少 totalPending 计数
+20:                 // Was cancelled so make sure we free up memory and notify about the freed bytes
+21:                 int pending = entry.cancel();
+22:                 decrementPendingOutboundBytes(pending, false, true);
+23:             }
+24:             // 获得下一个 Entry
+25:             entry = entry.next;
+26:         } while (entry != null);
+27: 
+28:         // 设置 unflushedEntry 为空，表示所有都 flush
+29:         // All flushed so reset unflushedEntry
+30:         unflushedEntry = null;
+31:     }
+32: }
+```
+
+- 第 6 至 7 行：若 `unflushedEntry` 为空，说明每个 Entry 对象已经“标记” flush 。**注意**，“标记”的方式，不是通过 Entry 对象有一个 `flushed` 字段，而是 `flushedEntry` 属性，指向第一个( 开始 ) flush 的 Entry ，而 `unflushedEntry` 置空。
+
+- 第 8 至 12 行：若 `flushedEntry` 为空，赋值为 `unflushedEntry` ，用于记录第一个( 开始 ) flush 的 Entry 。
+
+- 第 13 至 26 行：计算需要 flush 的 Entry 数量，并设置每个 Entry 对应的 Promise
+
+   
+
+  不可取消
+
+  。
+
+  - 第 18 至 23 行：`#decrementPendingOutboundBytes(long size, ...)` 方法，减少 `totalPendingSize` 计数。
+
+- 第 30 行：设置 `unflushedEntry` 为空。
+
+------
+
+可能有点抽象，我们来看看基友【闪电侠】对这块的解析：
+
+> FROM 闪电侠 [《netty 源码分析之 writeAndFlush 全解析》](https://www.jianshu.com/p/feaeaab2ce56)
+>
+> 可以结合前面的图来看，首先拿到 `unflushedEntry` 指针，然后将 `flushedEntry` 指向 `unflushedEntry` 所指向的节点，调用完毕之后，三个指针的情况如下所示
+>
+> [![img](31-Netty 源码解析-Channel（五）之 flush 操作.assets/ecb3df153a3df70464b524838b559232.png)](http://static.iocoder.cn/ecb3df153a3df70464b524838b559232)
+
+------
+
+> 老艿艿：再次切回到老艿艿的频道，呼呼。
+
+当一次需要从内存队列写到对端的数据量非常大，那么可能写着写着 Channel 的缓存区不够，导致 Channel 此时不可写。但是，这一轮 `#addFlush(...)` 标记的 Entry 对象并没有都写到对端。例如，准备写到对端的 Entry 的数量是 `flush = 10` 个，结果只写了 6 个，那么就剩下 `flush = 4` 。
+
+但是的但是，`#addMessage(...)` 可能又不断写入新的消息( 数据 )到 ChannelOutboundBuffer 中。那会出现什么情况呢？会“分”成两段：
+
+- `<1>` 段：自节点 `flushedEntry` 开始的 `flush` 个 Entry 节点，需要写入到对端。
+- `<2>` 段：自节点 `unFlushedEntry` 开始的 Entry 节点，需要调用 `#addFlush()` 方法，添加到 `<1>` 段中。
+
+这就很好的解释两个事情：
+
+1. 为什么 `#addFlush()` 方法，命名是以 `"add"` 开头。
+2. ChannelOutboundBuffer 的链式结构，为什么不是 `head` 和 `tail` **两个**节点，而是 `flushedEntry`、`unFlushedEntry`、`flushedEntry` **三个**节点。在此处，请允许老艿艿爆个粗口：真他 x 的巧妙啊。
+
+### 8.4.1 size
+
+`#size()` 方法，获得 `flushed` 属性。代码如下：
+
+```
+/**
+ * Returns the number of flushed messages in this {@link ChannelOutboundBuffer}.
+ */
+public int size() {
+    return flushed;
+}
+```
+
+### 8.4.2 isEmpty
+
+`#isEmpty()` 方法，是否为空。代码如下：
+
+```
+/**
+ * Returns {@code true} if there are flushed messages in this {@link ChannelOutboundBuffer} or {@code false}
+ * otherwise.
+ */
+public boolean isEmpty() {
+    return flushed == 0;
+}
+```
+
+## 8.5 current
+
+`#current()` 方法，获得**当前**要写入对端的消息( 数据 )。代码如下：
+
+```
+/**
+ * Return the current message to write or {@code null} if nothing was flushed before and so is ready to be written.
+ */
+public Object current() {
+    Entry entry = flushedEntry;
+    if (entry == null) {
+        return null;
+    }
+
+    return entry.msg;
+}
+```
+
+- 即，返回的是 `flushedEntry` 的消息( 数据 )。
+
+## 8.6 nioBuffers
+
+`#nioBuffers(int maxCount, long maxBytes)` 方法，获得当前要写入到对端的 NIO ByteBuffer 数组，并且获得的数组大小不得超过 `maxCount` ，字节数不得超过 `maxBytes` 。我们知道，在写入数据到 ChannelOutboundBuffer 时，一般使用的是 Netty ByteBuf 对象，但是写到 NIO SocketChannel 时，则必须使用 NIO ByteBuffer 对象，因此才有了这个方法。考虑到性能，这个方法里会使用到“**缓存**”，所以看起来会比较绕一丢丢。OK，开始看代码落：
+
+```
+/**
+ * Returns an array of direct NIO buffers if the currently pending messages are made of {@link ByteBuf} only.
+ * {@link #nioBufferCount()} and {@link #nioBufferSize()} will return the number of NIO buffers in the returned
+ * array and the total number of readable bytes of the NIO buffers respectively.
+ * <p>
+ * Note that the returned array is reused and thus should not escape
+ * {@link AbstractChannel#doWrite(ChannelOutboundBuffer)}.
+ * Refer to {@link NioSocketChannel#doWrite(ChannelOutboundBuffer)} for an example.
+ * </p>
+ * @param maxCount The maximum amount of buffers that will be added to the return value.
+ * @param maxBytes A hint toward the maximum number of bytes to include as part of the return value. Note that this
+ *                 value maybe exceeded because we make a best effort to include at least 1 {@link ByteBuffer}
+ *                 in the return value to ensure write progress is made.
+ */
+     
+  1: public ByteBuffer[] nioBuffers(int maxCount, long maxBytes) {
+  2:     assert maxCount > 0;
+  3:     assert maxBytes > 0;
+  4:     long nioBufferSize = 0;
+  5:     int nioBufferCount = 0;
+  6:     // 获得当前线程的 NIO ByteBuffer 数组缓存。
+  7:     final InternalThreadLocalMap threadLocalMap = InternalThreadLocalMap.get();
+  8:     ByteBuffer[] nioBuffers = NIO_BUFFERS.get(threadLocalMap);
+  9:     // 从 flushedEntry 节点，开始向下遍历
+ 10:     Entry entry = flushedEntry;
+ 11:     while (isFlushedEntry(entry) && entry.msg instanceof ByteBuf) {
+ 12:         // 若 Entry 节点已经取消，忽略。
+ 13:         if (!entry.cancelled) {
+ 14:             ByteBuf buf = (ByteBuf) entry.msg;
+ 15:             // 获得消息( 数据 )开始读取位置
+ 16:             final int readerIndex = buf.readerIndex();
+ 17:             // 获得消息( 数据 )可读取的字节数
+ 18:             final int readableBytes = buf.writerIndex() - readerIndex;
+ 19: 
+ 20:             // 若无可读取的数据，忽略。
+ 21:             if (readableBytes > 0) {
+ 22:                 // 前半段，可读取的字节数，不能超过 maxBytes
+ 23:                 // 后半段，如果第一条数据，就已经超过 maxBytes ，那么只能“强行”读取，否则会出现一直无法读取的情况。
+ 24:                 if (maxBytes - readableBytes < nioBufferSize && nioBufferCount != 0) {
+ 25:                     // If the nioBufferSize + readableBytes will overflow maxBytes, and there is at least one entry
+ 26:                     // we stop populate the ByteBuffer array. This is done for 2 reasons:
+ 27:                     // 1. bsd/osx don't allow to write more bytes then Integer.MAX_VALUE with one writev(...) call
+ 28:                     // and so will return 'EINVAL', which will raise an IOException. On Linux it may work depending
+ 29:                     // on the architecture and kernel but to be safe we also enforce the limit here.
+ 30:                     // 2. There is no sense in putting more data in the array than is likely to be accepted by the
+ 31:                     // OS.
+ 32:                     //
+ 33:                     // See also:
+ 34:                     // - https://www.freebsd.org/cgi/man.cgi?query=write&sektion=2
+ 35:                     // - http://linux.die.net/man/2/writev
+ 36:                     break;
+ 37:                 }
+ 38:                 // 增加 nioBufferSize
+ 39:                 nioBufferSize += readableBytes;
+ 40:                 // 初始 Entry 节点的 NIO ByteBuffer 数量
+ 41:                 int count = entry.count;
+ 42:                 if (count == -1) {
+ 43:                     //noinspection ConstantValueVariableUse
+ 44:                     entry.count = count = buf.nioBufferCount();
+ 45:                 }
+ 46:                 // 如果超过 NIO ByteBuffer 数组的大小，进行扩容。
+ 47:                 int neededSpace = min(maxCount, nioBufferCount + count);
+ 48:                 if (neededSpace > nioBuffers.length) {
+ 49:                     nioBuffers = expandNioBufferArray(nioBuffers, neededSpace, nioBufferCount);
+ 50:                     NIO_BUFFERS.set(threadLocalMap, nioBuffers);
+ 51:                 }
+ 52:                 // 初始化 Entry 节点的 buf / bufs 属性
+ 53:                 if (count == 1) {
+ 54:                     ByteBuffer nioBuf = entry.buf;
+ 55:                     if (nioBuf == null) {
+ 56:                         // cache ByteBuffer as it may need to create a new ByteBuffer instance if its a
+ 57:                         // derived buffer
+ 58:                         entry.buf = nioBuf = buf.internalNioBuffer(readerIndex, readableBytes);
+ 59:                     }
+ 60:                     nioBuffers[nioBufferCount++] = nioBuf;
+ 61:                 } else {
+ 62:                     ByteBuffer[] nioBufs = entry.bufs;
+ 63:                     if (nioBufs == null) {
+ 64:                         // cached ByteBuffers as they may be expensive to create in terms
+ 65:                         // of Object allocation
+ 66:                         entry.bufs = nioBufs = buf.nioBuffers();
+ 67:                     }
+ 68:                     for (int i = 0; i < nioBufs.length && nioBufferCount < maxCount; ++i) {
+ 69:                         ByteBuffer nioBuf = nioBufs[i];
+ 70:                         if (nioBuf == null) {
+ 71:                             break;
+ 72:                         } else if (!nioBuf.hasRemaining()) {
+ 73:                             continue;
+ 74:                         }
+ 75:                         nioBuffers[nioBufferCount++] = nioBuf;
+ 76:                     }
+ 77:                 }
+ 78: 
+ 79:                 // 到达 maxCount 上限，结束循环。老艿艿的想法，这里最好改成 nioBufferCount >= maxCount ，是有可能会超过的
+ 80:                 if (nioBufferCount == maxCount) {
+ 81:                     break;
+ 82:                 }
+ 83:             }
+ 84:         }
+ 85: 
+ 86:         // 下一个 Entry节点
+ 87:         entry = entry.next;
+ 88:     }
+ 89: 
+ 90:     // 设置 nioBufferCount 和 nioBufferSize 属性
+ 91:     this.nioBufferCount = nioBufferCount;
+ 92:     this.nioBufferSize = nioBufferSize;
+ 93: 
+ 94:     return nioBuffers;
+ 95: }
+```
+
+- 第 4 至 5 行：初始 `nioBufferSize`、`nioBufferCount` 计数。
+
+- 第 6 至 8 行：获得当前线程的 NIO ByteBuffer 数组缓存。
+
+  - 关于 InternalThreadLocalMap 和 FastThreadLocal ，胖友可以暂时忽略，后续的文章，详细解析。
+
+- 第 10 至 11 行：从 `flushedEntry` 节点，开始向下遍历。
+
+  - 调用 `#isFlushedEntry(Entry entry)` 方法，判断是否为已经“标记”为 flush 的 Entry 节点。代码如下：
+
+    ```
+    private boolean isFlushedEntry(Entry e) {
+        return e != null && e != unflushedEntry;
+    }
+    ```
+
+    - `e != unflushedEntry` ，就是我们在 [「8.4 addFlush」](https://svip.iocoder.cn/Netty/Channel-5-flush/#) 最后部分讲的，思考下。
+
+  - `entry.msg instanceof ByteBuf` ，消息( 数据 )类型为 ByteBuf 。实际上，`msg` 的类型也可能是 FileRegion 。如果 ChannelOutboundBuffer 里的消息都是 FileRegion 类型，那就会导致这个方法返回为**空** NIO ByteBuffer 数组。
+
+- 第 13 行：若 Entry 节点已经取消，忽略。
+
+- 第 14 至 18 行：获得消息( 数据 )开始读取位置和可读取的字节数。
+
+  - 第 21 行：若无可读取的数据，忽略。
+
+- 第 22 至 37 行：
+
+  - 前半段 `maxBytes - readableBytes < nioBufferSize` ，当前 ByteBuf 可读取的字节数，不能超过 `maxBytes` 。这个比较好理解。
+  - 后半段 `nioBufferCount != 0` ，如果**第一条**数据，就已经超过 `maxBytes` ，那么只能“强行”读取，否则会出现一直无法读取的情况( 因为不能跳过这条 😈 )。
+
+- 第 39 行：增加 `nioBufferSize` 。
+
+- 第 40 至 45 行：调用
+
+   
+
+  ```
+  ByteBuf#nioBufferCount()
+  ```
+
+   
+
+  方法，初始 Entry 节点的
+
+   
+
+  ```
+  count
+  ```
+
+   
+
+  属性( NIO ByteBuffer 数量)。
+
+  - 使用 `count == -1` 的原因是，`Entry.count` 未初始化时，为 `-1` 。
+
+- 第 47 至 51 行：如果超过 NIO ByteBuffer 数组的大小，调用 `#expandNioBufferArray(ByteBuffer[] array, int neededSpace, int size)` 方法，进行扩容。详细解析，见 [「8.6.1 expandNioBufferArray」](https://svip.iocoder.cn/Netty/Channel-5-flush/#) 。
+
+- 第 52 至 77 行：初始 Entry 节点的
+
+   
+
+  ```
+  buf
+  ```
+
+   
+
+  或
+
+   
+
+  ```
+  bufs
+  ```
+
+   
+
+  属性。
+
+  - 当 `count = 1` 时，调用 `ByteBuf#internalNioBuffer(readerIndex, readableBytes)` 方法，获得 NIO ByteBuffer 对象。
+  - 当 `count > 1` 时，调用 `ByteBuf#nioBuffers()` 方法，获得 NIO ByteBuffer 数组。
+  - 通过 `nioBuffers[nioBufferCount++] = nioBuf` ，将 NIO ByteBuffer 赋值到结果数组 `nioBuffers` 中，并增加 `nioBufferCount` 。
+
+- 第 79 至 82 行：到达 `maxCount` 上限，结束循环。老艿艿的想法，这里最好改成 `nioBufferCount >= maxCount` ，是有可能会超过的。
+
+- 第 87 行：**下一个 Entry 节点**。
+
+- 第 90 至 92 行：设置 ChannelOutboundBuffer 的 `nioBufferCount` 和 `nioBufferSize` 属性。
+
+### 8.6.1 expandNioBufferArray
+
+`#expandNioBufferArray(ByteBuffer[] array, int neededSpace, int size)` 方法，进行 NIO ByteBuff 数组的**扩容**。代码如下：
+
+```
+private static ByteBuffer[] expandNioBufferArray(ByteBuffer[] array, int neededSpace, int size) {
+    // 计算扩容后的数组的大小，按照 2 倍计算
+    int newCapacity = array.length;
+    do {
+        // double capacity until it is big enough
+        // See https://github.com/netty/netty/issues/1890
+        newCapacity <<= 1;
+
+        if (newCapacity < 0) {
+            throw new IllegalStateException();
+        }
+
+    } while (neededSpace > newCapacity);
+
+    // 创建新的 ByteBuffer 数组
+    ByteBuffer[] newArray = new ByteBuffer[newCapacity];
+
+    // 复制老的 ByteBuffer 数组到新的 ByteBuffer 数组中
+    System.arraycopy(array, 0, newArray, 0, size);
+
+    return newArray;
+}
+```
+
+- 代码比较简单，胖友自己看下注释。
+
+### 8.6.2 nioBufferCount
+
+`#nioBufferCount()` 方法，返回 `nioBufferCount` 属性。代码如下：
+
+```
+/**
+ * Returns the number of {@link ByteBuffer} that can be written out of the {@link ByteBuffer} array that was
+ * obtained via {@link #nioBuffers()}. This method <strong>MUST</strong> be called after {@link #nioBuffers()}
+ * was called.
+ */
+public int nioBufferCount() {
+    return nioBufferCount;
+}
+```
+
+### 8.6.3 nioBufferSize
+
+`#nioBufferSize()` 方法，返回 `nioBufferSize` 属性。代码如下：
+
+```
+/**
+ * Returns the number of bytes that can be written out of the {@link ByteBuffer} array that was
+ * obtained via {@link #nioBuffers()}. This method <strong>MUST</strong> be called after {@link #nioBuffers()}
+ * was called.
+ */
+public long nioBufferSize() {
+    return nioBufferSize;
+}
+```
+
+## 8.7 removeBytes
+
+`#removeBytes(long writtenBytes)` 方法，移除已经写入 `writtenBytes` 字节对应的 Entry 对象 / 对象们。代码如下：
+
+```
+ 1: public void removeBytes(long writtenBytes) {
+ 2:     // 循环移除
+ 3:     for (;;) {
+ 4:         // 获得当前消息( 数据 )
+ 5:         Object msg = current();
+ 6:         if (!(msg instanceof ByteBuf)) {
+ 7:             assert writtenBytes == 0;
+ 8:             break;
+ 9:         }
+10: 
+11:         final ByteBuf buf = (ByteBuf) msg;
+12:         // 获得消息( 数据 )开始读取位置
+13:         final int readerIndex = buf.readerIndex();
+14:         // 获得消息( 数据 )可读取的字节数
+15:         final int readableBytes = buf.writerIndex() - readerIndex;
+16: 
+17:         // 当前消息( 数据 )已被写完到对端
+18:         if (readableBytes <= writtenBytes) {
+19:             if (writtenBytes != 0) {
+20:                 // 处理当前消息的 Entry 的写入进度
+21:                 progress(readableBytes);
+22:                 // 减小 writtenBytes
+23:                 writtenBytes -= readableBytes;
+24:             }
+25:             // 移除当前消息对应的 Entry
+26:             remove();
+27:         // 当前消息( 数据 )未被写完到对端
+28:         } else { // readableBytes > writtenBytes
+29:             if (writtenBytes != 0) {
+30:                 // 标记当前消息的 ByteBuf 的读取位置
+31:                 buf.readerIndex(readerIndex + (int) writtenBytes);
+32:                 // 处理当前消息的 Entry 的写入进度
+33:                 progress(writtenBytes);
+34:             }
+35:             break;
+36:         }
+37:     }
+38: 
+39:     // 清除 NIO ByteBuff 数组的缓存
+40:     clearNioBuffers();
+41: }
+```
+
+- 第 3 行：
+
+  循环
+
+  ，移除已经写入
+
+   
+
+  ```
+  writtenBytes
+  ```
+
+   
+
+  字节对应的 Entry 对象。
+
+  - 第 5 行：调用 `#current()` 方法，获得当前消息( 数据 )。
+  - 第 12 至 15 行：获得消息( 数据 )开始读取位置和可读取的字节数。
+  - `<1>` 当前消息( 数据 )**已**被写完到对端。
+  - 第 21 行：调用 `#progress(long amount)` 方法，处理当前消息的 Entry 的写入进度。详细解析，见 [「8.7.1 progress」](https://svip.iocoder.cn/Netty/Channel-5-flush/#) 。
+  - 第 23 行：减小 `writtenBytes` 。
+  - 第 26 行：调用 `#remove()` 方法，移除当前消息对应的 Entry 对象。详细解析，见 [「8.7.2 remove」](https://svip.iocoder.cn/Netty/Channel-5-flush/#) 。
+  - `<2》` 当前消息( 数据 )**未**被写完到对端。
+  - 第 31 行：调用 `ByteBuf#readerIndex(readerIndex)` 方法，标记当前消息的 ByteBuf 的**读取位置**。
+  - 第 33 行：调用 `#progress(long amount)` 方法，处理当前消息的 Entry 的写入进度。
+  - 第 35 行：`break` ，结束循环。
+
+- 第 40 行：调用 `#clearNioBuffers()` 方法，**清除** NIO ByteBuff 数组的缓存。详细解析，见 [「8.7.4 clearNioBuffers」](https://svip.iocoder.cn/Netty/Channel-5-flush/#) 。
+
+### 8.7.1 progress
+
+`#progress(long amount)` 方法，处理当前消息的 Entry 的写入进度，主要是**通知** Promise 消息写入的进度。代码如下：
+
+```
+/**
+ * Notify the {@link ChannelPromise} of the current message about writing progress.
+ */
+  1: public void progress(long amount) {
+  2:     Entry e = flushedEntry;
+  3:     assert e != null;
+  4:     ChannelPromise p = e.promise;
+  5:     if (p instanceof ChannelProgressivePromise) {
+  6:         // 设置 Entry 对象的 progress 属性
+  7:         long progress = e.progress + amount;
+  8:         e.progress = progress;
+  9:         // 通知 ChannelProgressivePromise 进度
+ 10:         ((ChannelProgressivePromise) p).tryProgress(progress, e.total);
+ 11:     }
+ 12: }
+```
+
+- 第 5 行：若 `promise` 的类型是 ChannelProgressivePromise 类型。
+- 第 6 至 8 行：设置 Entry 对象的 `progress` 属性。
+- 第 10 行：调用 `ChannelProgressivePromise#tryProgress(progress, total)` 方法，通知 ChannelProgressivePromise 进度。
+
+### 8.7.2 remove
+
+`#remove()` 方法，移除当前消息对应的 Entry 对象，并 Promise 通知成功。代码如下：
+
+```
+ 1: public boolean remove() {
+ 2:     Entry e = flushedEntry;
+ 3:     if (e == null) {
+ 4:         // 清除 NIO ByteBuff 数组的缓存
+ 5:         clearNioBuffers();
+ 6:         return false;
+ 7:     }
+ 8:     Object msg = e.msg;
+ 9: 
+10:     ChannelPromise promise = e.promise;
+11:     int size = e.pendingSize;
+12: 
+13:     // 移除指定 Entry 对象
+14:     removeEntry(e);
+15: 
+16:     if (!e.cancelled) {
+17:         // 释放消息( 数据 )相关的资源
+18:         // only release message, notify and decrement if it was not canceled before.
+19:         ReferenceCountUtil.safeRelease(msg);
+20:         // 通知 Promise 执行成功
+21:         safeSuccess(promise);
+22:         // 减少 totalPending 计数
+23:         decrementPendingOutboundBytes(size, false, true);
+24:     }
+25: 
+26:     // 回收 Entry 对象
+27:     // recycle the entry
+28:     e.recycle();
+29: 
+30:     return true;
+31: }
+```
+
+- 第 14 行：调用 `#removeEntry(Entry e)` 方法，移除**指定** Entry 对象。详细解析，见 [「8.7.3 removeEntry」](https://svip.iocoder.cn/Netty/Channel-5-flush/#) 。
+
+- 第 16 行：若 Entry 已取消，则忽略。
+
+- 第 19 行：`ReferenceCountUtil#safeRelease(msg)` 方法，释放消息( 数据 )相关的资源。
+
+- 第 21 行：【**重要**】调用 `#safeSuccess(promise)` 方法，通知 Promise 执行成功。此处才是，真正触发 `Channel#write(...)` 或 `Channel#writeAndFlush(...)` 方法，返回的 Promise 的通知。`#safeSuccess(promise)` 方法的代码如下：
+
+  ```
+  private static void safeSuccess(ChannelPromise promise) {
+      // Only log if the given promise is not of type VoidChannelPromise as trySuccess(...) is expected to return
+      // false.
+      PromiseNotificationUtil.trySuccess(promise, null, promise instanceof VoidChannelPromise ? null : logger);
+  }
+  ```
+
+- 第 23 行：`#decrementPendingOutboundBytes(long size, ...)` 方法，减少 `totalPendingSize` 计数。
+
+- 第 28 行：调用 `Entry#recycle()` 方法，**回收** Entry 对象。
+
+### 8.7.3 removeEntry
+
+`#removeEntry(Entry e)` 方法，移除**指定** Entry 对象。代码如下：
+
+```
+ 1: private void removeEntry(Entry e) {
+ 2:     // 已移除完已 flush 的 Entry 节点，置空 flushedEntry、tailEntry、unflushedEntry 。
+ 3:     if (-- flushed == 0) {
+ 4:         // processed everything
+ 5:         flushedEntry = null;
+ 6:         if (e == tailEntry) {
+ 7:             tailEntry = null;
+ 8:             unflushedEntry = null;
+ 9:         }
+10:     // 未移除完已 flush 的 Entry 节点，flushedEntry 指向下一个 Entry 对象
+11:     } else {
+12:         flushedEntry = e.next;
+13:     }
+14: }
+```
+
+- 第 3 至 9 行：**已**移除完已 flush 的**所有** Entry 节点，置空 `flushedEntry`、`tailEntry`、`unflushedEntry` 。
+- 第 10 至 13 行：**未**移除完已 flush 的**所有** Entry 节点，`flushedEntry` 指向**下一个** Entry 对象。
+
+### 8.7.4 clearNioBuffers
+
+`#clearNioBuffers()` 方法，**清除** NIO ByteBuff 数组的缓存。代码如下：
+
+```
+// Clear all ByteBuffer from the array so these can be GC'ed.
+// See https://github.com/netty/netty/issues/3837
+private void clearNioBuffers() {
+    int count = nioBufferCount;
+    if (count > 0) {
+        // 归零 nioBufferCount 。老艿艿觉得，应该把 nioBufferSize 也归零
+        nioBufferCount = 0;
+        // 置空 NIO ByteBuf 数组
+        Arrays.fill(NIO_BUFFERS.get(), 0, count, null);
+    }
+}
+```
+
+- 代码比较简单，胖友自己看注释。主要目的是 help gc 。
+
+## 8.8 failFlushed
+
+`#failFlushed(Throwable cause, boolean notify)` 方法，写入数据到对端**失败**，进行后续的处理，详细看代码。代码如下：
+
+```
+ 1: void failFlushed(Throwable cause, boolean notify) {
+ 2:     // 正在通知 flush 失败中，直接返回
+ 3:     // Make sure that this method does not reenter.  A listener added to the current promise can be notified by the
+ 4:     // current thread in the tryFailure() call of the loop below, and the listener can trigger another fail() call
+ 5:     // indirectly (usually by closing the channel.)
+ 6:     //
+ 7:     // See https://github.com/netty/netty/issues/1501
+ 8:     if (inFail) {
+ 9:         return;
+10:     }
+11: 
+12:     try {
+13:         // 标记正在通知 flush 失败中
+14:         inFail = true;
+15:         // 循环，移除所有已 flush 的 Entry 节点们
+16:         for (;;) {
+17:             if (!remove0(cause, notify)) {
+18:                 break;
+19:             }
+20:         }
+21:     } finally {
+22:         // 标记不在通知 flush 失败中
+23:         inFail = false;
+24:     }
+25: }
+```
+
+- 第 2 至 10 行：正在通知 flush 失败中，直接返回。
+- 第 14 行：标记正在通知 flush 失败中，即 `inFail = true` 。
+- 第 15 至 20 行：循环，调用 `#remove0(Throwable cause, boolean notifyWritability)` 方法，移除**所有**已 flush 的 Entry 节点们。详细解析，见 [「8. remove0」](https://svip.iocoder.cn/Netty/Channel-5-flush/#) 中。
+- 第 21 至 24 行：标记不在通知 flush 失败中，即 `inFail = false` 。
+
+### 8.8.1 remove0
+
+`#remove0(Throwable cause, boolean notifyWritability)` 方法，移除当前消息对应的 Entry 对象，并 Promise 通知异常。代码如下：
+
+```
+ 1: private boolean remove0(Throwable cause, boolean notifyWritability) {
+ 2:     Entry e = flushedEntry;
+ 3:     // 所有 flush 的 Entry 节点，都已经写到对端
+ 4:     if (e == null) {
+ 5:         // // 清除 NIO ByteBuff 数组的缓存
+ 6:         clearNioBuffers();
+ 7:         return false; // 没有后续的 flush 的 Entry 节点
+ 8:     }
+ 9:     Object msg = e.msg;
+10: 
+11:     ChannelPromise promise = e.promise;
+12:     int size = e.pendingSize;
+13: 
+14:     removeEntry(e);
+15: 
+16:     if (!e.cancelled) {
+17:         // 释放消息( 数据 )相关的资源
+18:         // only release message, fail and decrement if it was not canceled before.
+19:         ReferenceCountUtil.safeRelease(msg);
+20:         // 通知 Promise 执行失败
+21:         safeFail(promise, cause);
+22:         // 减少 totalPendingSize 计数
+23:         decrementPendingOutboundBytes(size, false, notifyWritability);
+24:     }
+25: 
+26:     // 回收 Entry 对象
+27:     // recycle the entry
+28:     e.recycle();
+29: 
+30:     return true; // 还有后续的 flush 的 Entry 节点
+31: }
+```
+
+- 第 3 至 8 行：若**所有** flush 的 Entry 节点，都已经写到对端，则调用 `#clearNioBuffers()` 方法，清除 NIO ByteBuff 数组的缓存。
+
+- 第 14 行：调用 `#removeEntry(Entry e)` 方法，移除**指定** Entry 对象。详细解析，见 [「8.7.3 removeEntry」](https://svip.iocoder.cn/Netty/Channel-5-flush/#) 。
+
+- 第 16 行：若 Entry 已取消，则忽略。
+
+- 第 19 行：`ReferenceCountUtil#safeRelease(msg)` 方法，释放消息( 数据 )相关的资源。
+
+- 第 21 行：【**重要**】调用 `#safeFail(promise)` 方法，通知 Promise 执行失败。此处才是，真正触发 `Channel#write(...)` 或 `Channel#writeAndFlush(...)` 方法，返回的 Promise 的通知。`#safeFail(promise)` 方法的代码如下：
+
+  ```
+  private static void safeFail(ChannelPromise promise, Throwable cause) {
+      // Only log if the given promise is not of type VoidChannelPromise as tryFailure(...) is expected to return
+      // false.
+      PromiseNotificationUtil.tryFailure(promise, cause, promise instanceof VoidChannelPromise ? null : logger);
+  }
+  ```
+
+- 第 23 行：调用 `#decrementPendingOutboundBytes(long size, ...)` 方法，减少 `totalPendingSize` 计数。
+
+- 第 28 行：调用 `Entry#recycle()` 方法，**回收** Entry 对象。
+
+## 8.9 forEachFlushedMessage
+
+TODO 1015 forEachFlushedMessage 在 `netty-transport-native-poll` 和 `netty-transport-native-kqueue` 中使用，在后续的文章解析。
+
+## 8.10 close
+
+`#close(...)` 方法，关闭 ChannelOutboundBuffer ，进行后续的处理，详细看代码。代码如下：
+
+```
+void close(ClosedChannelException cause) {
+    close(cause, false);
+}
+
+  1: void close(final Throwable cause, final boolean allowChannelOpen) {
+  2:     // 正在通知 flush 失败中
+  3:     if (inFail) {
+  4:         // 提交 EventLoop 的线程中，执行关闭
+  5:         channel.eventLoop().execute(new Runnable() {
+  6:             @Override
+  7:             public void run() {
+  8:                 close(cause, allowChannelOpen);
+  9:             }
+ 10:         });
+ 11:         // 返回
+ 12:         return;
+ 13:     }
+ 14: 
+ 15:     // 标记正在通知 flush 失败中
+ 16:     inFail = true;
+ 17: 
+ 18:     if (!allowChannelOpen && channel.isOpen()) {
+ 19:         throw new IllegalStateException("close() must be invoked after the channel is closed.");
+ 20:     }
+ 21: 
+ 22:     if (!isEmpty()) {
+ 23:         throw new IllegalStateException("close() must be invoked after all flushed writes are handled.");
+ 24:     }
+ 25: 
+ 26:     // Release all unflushed messages.
+ 27:     try {
+ 28:         // 从 unflushedEntry 节点，开始向下遍历
+ 29:         Entry e = unflushedEntry;
+ 30:         while (e != null) {
+ 31:             // 减少 totalPendingSize
+ 32:             // Just decrease; do not trigger any events via decrementPendingOutboundBytes()
+ 33:             int size = e.pendingSize;
+ 34:             TOTAL_PENDING_SIZE_UPDATER.addAndGet(this, -size);
+ 35: 
+ 36:             if (!e.cancelled) {
+ 37:                 // 释放消息( 数据 )相关的资源
+ 38:                 ReferenceCountUtil.safeRelease(e.msg);
+ 39:                 // 通知 Promise 执行失败
+ 40:                 safeFail(e.promise, cause);
+ 41:             }
+ 42:             // 回收当前节点，并获得下一个 Entry 节点
+ 43:             e = e.recycleAndGetNext();
+ 44:         }
+ 45:     } finally {
+ 46:         // 标记在在通知 flush 失败中
+ 47:         inFail = false;
+ 48:     }
+ 49: 
+ 50:     // 清除 NIO ByteBuff 数组的缓存。
+ 51:     clearNioBuffers();
+ 52: }
+```
+
+- 第 3 行：正在通知 flush 失败中：
+
+  - 第 5 至 10 行: 提交 EventLoop 的线程中，执行关闭。
+  - 第 12 行：`return` 返回。
+
+- 第 16 行：标记正在通知 flush 失败中，即 `inFail = true` 。
+
+- 第 28 至 30 行：从
+
+   
+
+  ```
+  unflushedEntry
+  ```
+
+   
+
+  节点，开始向下遍历。
+
+  - 第 31 至 34 行：减少 `totalPendingSize` 计数。
+  - 第 36 行：若 Entry 已取消，则忽略。
+  - 第 38 行：调用 `ReferenceCountUtil#safeRelease(msg)` 方法，释放消息( 数据 )相关的资源。
+  - 第 40 行：【**重要**】调用 `#safeFail(promise)` 方法，通知 Promise 执行失败。此处才是，真正触发 `Channel#write(...)` 或 `Channel#writeAndFlush(...)` 方法，返回的 Promise 的通知。
+  - 第 43 行：调用 `Entry#recycleAndGetNext()` 方法，回收当前节点，并获得下一个 Entry 节点。
+
+- 第 45 至 48 行：标记不在通知 flush 失败中，即 `inFail = false` 。
+
+- 第 51 行：调用 `#clearNioBuffers()` 方法，**清除** NIO ByteBuff 数组的缓存。
+
+# 9. NioEventLoop
+
+在上文 [「7. NioSocketChannel」](https://svip.iocoder.cn/Netty/Channel-5-flush/#) 中，在写入到 Channel 到对端，若 TCP 数据发送缓冲区**已满**，这将导致 Channel **不写可**，此时会注册对该 Channel 的 `SelectionKey.OP_WRITE` 事件感兴趣。从而实现，再在 Channel 可写后，进行**强制** flush 。这块的逻辑，在 `NioEventLoop#processSelectedKey(SelectionKey k, AbstractNioChannel ch)` 中实现，代码如下：
+
+```
+// OP_WRITE 事件就绪
+// Process OP_WRITE first as we may be able to write some queued buffers and so free memory.
+if ((readyOps & SelectionKey.OP_WRITE) != 0) {
+    // Call forceFlush which will also take care of clear the OP_WRITE once there is nothing left to write
+    // 向 Channel 写入数据
+    ch.unsafe().forceFlush();
+}
+```
+
+- 通过 Selector 轮询到 Channel 的 `OP_WRITE` 就绪时，调用 `AbstractNioUnsafe#forceFlush()` 方法，强制 flush 。代码如下：
+
+  ```
+  // AbstractNioUnsafe.java
+  @Override
+  public final void forceFlush() {
+      // directly call super.flush0() to force a flush now
+      super.flush0();
+  }
+  ```
+
+  - 后续的逻辑，又回到 [「6. AbstractUnsafe」](https://svip.iocoder.cn/Netty/Channel-5-flush/#) 小节的 `#flush0()` 流程。
+  - 在完成强制 flush 之后，会取消对 `SelectionKey.OP_WRITE` 事件的感兴趣。
+
+## 9.1 如何模拟
+
+1. 配置服务端 ServerBootstrap 的启动参数如下：
+
+   ```
+   .childOption(ChannelOption.SO_SNDBUF, 5) // Socket 参数，TCP 数据发送缓冲区大小。
+   ```
+
+2. `telnet` 到启动的服务端，发送相对长的命令，例如 `"abcdefghijklmnopqrstuvw11321321321nhdkslk"` 。
+
+# 10. ChannelOutboundBuffer 写入控制
+
+当我们不断调用 `#addMessage(Object msg, int size, ChannelPromise promise)` 方法，添加消息到 ChannelOutboundBuffer 内存队列中，如果**不及时** flush 写到对端( 例如程序一直未调用 `Channel#flush()` 方法，或者对端接收数据比较慢导致 Channel 不可写 )，可能会导致 **OOM 内存溢出**。所以，在 ChannelOutboundBuffer 使用 `totalPendingSize` 属性，存储所有 Entry 预计占用的内存大小( `pendingSize` )。
+
+- 在 `totalPendingSize` 大于高水位阀值时( `ChannelConfig.writeBufferHighWaterMark` ，默认值为 64 KB )，**关闭**写开关( `unwritable` )。详细解析，见 [「10.1 incrementPendingOutboundBytes」](https://svip.iocoder.cn/Netty/Channel-5-flush/#) 。
+- 在 `totalPendingSize` 小于低水位阀值时( `ChannelConfig.writeBufferLowWaterMark` ，默认值为 32 KB )，**打开**写开关( `unwritable` )。详细解析，见 [「10.2 decrementPendingOutboundBytes」](https://svip.iocoder.cn/Netty/Channel-5-flush/#) 。
+
+该功能，对应 Github 提交为 [《Take memory overhead of ChannelOutboundBuffer / PendingWriteQueue into account》](https://github.com/netty/netty/commit/e3cb9935c0b63357e3d51867cffe624129e7e1dd) 。
+
+## 10.1 incrementPendingOutboundBytes
+
+`#incrementPendingOutboundBytes(long size, ...)` 方法，增加 `totalPendingSize` 计数。代码如下：
+
+```
+ 1: /**
+ 2:  * Increment the pending bytes which will be written at some point.
+ 3:  * This method is thread-safe!
+ 4:  */
+ 5: void incrementPendingOutboundBytes(long size) {
+ 6:     incrementPendingOutboundBytes(size, true);
+ 7: }
+ 8: 
+ 9: private void incrementPendingOutboundBytes(long size, boolean invokeLater) {
+10:     if (size == 0) {
+11:         return;
+12:     }
+13: 
+14:     // 增加 totalPendingSize 计数
+15:     long newWriteBufferSize = TOTAL_PENDING_SIZE_UPDATER.addAndGet(this, size);
+16:     // totalPendingSize 大于高水位阀值时，设置为不可写
+17:     if (newWriteBufferSize > channel.config().getWriteBufferHighWaterMark()) {
+18:         setUnwritable(invokeLater);
+19:     }
+20: }
+```
+
+- 第 15 行：增加 `totalPendingSize` 计数。
+
+- 第 16 至 19 行：`totalPendingSize` 大于高水位阀值时，调用 `#setUnwritable(boolean invokeLater)` 方法，设置为不可写。代码如下：
+
+  ```
+   1: private void setUnwritable(boolean invokeLater) {
+   2:     for (;;) {
+   3:         final int oldValue = unwritable;
+   4:         // 或位操作，修改第 0 位 bits 为 1
+   5:         final int newValue = oldValue | 1;
+   6:         // CAS 设置 unwritable 为新值
+   7:         if (UNWRITABLE_UPDATER.compareAndSet(this, oldValue, newValue)) {
+   8:             // 若之前可写，现在不可写，触发 Channel WritabilityChanged 事件到 pipeline 中。
+   9:             if (oldValue == 0 && newValue != 0) {
+  10:                 fireChannelWritabilityChanged(invokeLater);
+  11:             }
+  12:             break;
+  13:         }
+  14:     }
+  15: }
+  ```
+
+  - 第 2 行：`for` 循环，直到 CAS 修改成功
+  - 第 5 行：或位操作，修改第 0 位 bits 为 1 。😈 比较神奇的是，`unwritable` 的类型不是 `boolean` ，而是 `int` 类型。通过每个 bits ，来表示**哪种**类型不可写。感兴趣的胖友，可以看看 `io.netty.handler.traffic.AbstractTrafficShapingHandler` ，使用了第 1、2、3 bits 。
+  - 第 7 行：CAS 设置 `unwritable` 为新值。
+  - 第 8 至 11 行：若之前可写，现在不可写，调用 `#fireChannelWritabilityChanged(boolean invokeLater)` 方法，触发 Channel WritabilityChanged 事件到 pipeline 中。详细解析，见 [「10.3 fireChannelWritabilityChanged」](https://svip.iocoder.cn/Netty/Channel-5-flush/#) 。
+
+### 10.1.1 bytesBeforeUnwritable
+
+`#bytesBeforeUnwritable()` 方法，获得距离**不可写**还有多少字节数。代码如下：
+
+```
+public long bytesBeforeUnwritable() {
+    long bytes = channel.config().getWriteBufferHighWaterMark() - totalPendingSize;
+    // If bytes is negative we know we are not writable, but if bytes is non-negative we have to check writability.
+    // Note that totalPendingSize and isWritable() use different volatile variables that are not synchronized
+    // together. totalPendingSize will be updated before isWritable().
+    if (bytes > 0) {
+        return isWritable() ? bytes : 0; // 判断 #isWritable() 的原因是，可能已经被设置不可写
+    }
+    return 0;
+}
+```
+
+- 基于**高水位**阀值来判断。
+
+## 10.2 decrementPendingOutboundBytes
+
+`#decrementPendingOutboundBytes(long size, ...)` 方法，减少 `totalPendingSize` 计数。代码如下：
+
+```
+ 1: /**
+ 2:  * Decrement the pending bytes which will be written at some point.
+ 3:  * This method is thread-safe!
+ 4:  */
+ 5: void decrementPendingOutboundBytes(long size) {
+ 6:     decrementPendingOutboundBytes(size, true, true);
+ 7: }
+ 8: 
+ 9: private void decrementPendingOutboundBytes(long size, boolean invokeLater, boolean notifyWritability) {
+10:     if (size == 0) {
+11:         return;
+12:     }
+13: 
+14:     // 减少 totalPendingSize 计数
+15:     long newWriteBufferSize = TOTAL_PENDING_SIZE_UPDATER.addAndGet(this, -size);
+16:     // totalPendingSize 小于低水位阀值时，设置为可写
+17:     if (notifyWritability && newWriteBufferSize < channel.config().getWriteBufferLowWaterMark()) {
+18:         setWritable(invokeLater);
+19:     }
+20: }
+```
+
+- 第 15 行：减少 `totalPendingSize` 计数。
+
+- 第 16 至 19 行：`totalPendingSize` 小于低水位阀值时，调用 `#setWritable(boolean invokeLater)` 方法，设置为可写。代码如下：
+
+  ```
+   1: private void setWritable(boolean invokeLater) {
+   2:     for (;;) {
+   3:         final int oldValue = unwritable;
+   4:         // 并位操作，修改第 0 位 bits 为 0
+   5:         final int newValue = oldValue & ~1;
+   6:         // CAS 设置 unwritable 为新值
+   7:         if (UNWRITABLE_UPDATER.compareAndSet(this, oldValue, newValue)) {
+   8:             // 若之前不可写，现在可写，触发 Channel WritabilityChanged 事件到 pipeline 中。
+   9:             if (oldValue != 0 && newValue == 0) {
+  10:                 fireChannelWritabilityChanged(invokeLater);
+  11:             }
+  12:             break;
+  13:         }
+  14:     }
+  15: }
+  ```
+
+  - 第 2 行：`for` 循环，直到 CAS 修改成功
+  - 第 5 行：并位操作，修改第 0 位 bits 为 0 。
+  - 第 7 行：CAS 设置 `unwritable` 为新值。
+  - 第 8 至 11 行：若之前可写，现在不可写，调用 `#fireChannelWritabilityChanged(boolean invokeLater)` 方法，触发 Channel WritabilityChanged 事件到 pipeline 中。详细解析，见 [「10.3 fireChannelWritabilityChanged」](https://svip.iocoder.cn/Netty/Channel-5-flush/#) 。
+
+### 10.2.1 bytesBeforeWritable
+
+`#bytesBeforeWritable()` 方法，获得距离**可写**还要多少字节数。代码如下：
+
+```
+/**
+ * Get how many bytes must be drained from the underlying buffer until {@link #isWritable()} returns {@code true}.
+ * This quantity will always be non-negative. If {@link #isWritable()} is {@code true} then 0.
+ */
+public long bytesBeforeWritable() {
+    long bytes = totalPendingSize - channel.config().getWriteBufferLowWaterMark();
+    // If bytes is negative we know we are writable, but if bytes is non-negative we have to check writability.
+    // Note that totalPendingSize and isWritable() use different volatile variables that are not synchronized
+    // together. totalPendingSize will be updated before isWritable().
+    if (bytes > 0) {
+        return isWritable() ? 0 : bytes; // 判断 #isWritable() 的原因是，可能已经被设置不可写
+    }
+    return 0;
+}
+```
+
+- 基于**低水位**阀值来判断。
+
+## 10.3 fireChannelWritabilityChanged
+
+`#fireChannelWritabilityChanged(boolean invokeLater)` 方法，触发 Channel WritabilityChanged 事件到 pipeline 中。代码如下：
+
+```
+private void fireChannelWritabilityChanged(boolean invokeLater) {
+    final ChannelPipeline pipeline = channel.pipeline();
+    // 延迟执行，即提交 EventLoop 中触发 Channel WritabilityChanged 事件到 pipeline 中
+    if (invokeLater) {
+        Runnable task = fireChannelWritabilityChangedTask;
+        if (task == null) {
+            fireChannelWritabilityChangedTask = task = new Runnable() {
+                @Override
+                public void run() {
+                    pipeline.fireChannelWritabilityChanged();
+                }
+            };
+        }
+        channel.eventLoop().execute(task);
+    // 直接触发 Channel WritabilityChanged 事件到 pipeline 中
+    } else {
+        pipeline.fireChannelWritabilityChanged();
+    }
+}
+```
+
+- 根据 `invokeLater` 的值，分成两种方式，调用 `ChannelPipeline#fireChannelWritabilityChanged()` 方法，触发 Channel WritabilityChanged 事件到 pipeline 中。具体，胖友看下代码注释。
+
+- 后续的流程，就是 [《精尽 Netty 源码解析 —— ChannelPipeline（五）之 Inbound 事件的传播》](http://svip.iocoder.cn/Netty/Pipeline-5-inbound/) 。
+
+- 通过 Channel WritabilityChanged 事件，配合
+
+   
+
+  ```
+  io.netty.handler.stream.ChunkedWriteHandler
+  ```
+
+   
+
+  处理器，实现 ChannelOutboundBuffer 写入的控制，避免 OOM 。ChunkedWriteHandler 的具体代码实现，我们在后续的文章，详细解析。
+
+  - 所以，有一点要注意，ChannelOutboundBuffer 的 `unwritable` 属性，仅仅作为一个是否不可写的**开关**，具体需要配合响应的 ChannelHandler 处理器，才能实现“不可写”的功能。
+
+## 10.4 isWritable
+
+`#isWritable()` 方法，是否可写。代码如下：
+
+```
+/**
+ * Returns {@code true} if and only if {@linkplain #totalPendingWriteBytes() the total number of pending bytes} did
+ * not exceed the write watermark of the {@link Channel} and
+ * no {@linkplain #setUserDefinedWritability(int, boolean) user-defined writability flag} has been set to
+ * {@code false}.
+ */
+public boolean isWritable() {
+    return unwritable == 0;
+}
+```
+
+- 如果 `unwritable` 大于 0 ，则表示不可写。😈 一定要注意！！！
+
+### 10.4.1 getUserDefinedWritability
+
+`#getUserDefinedWritability(int index)` 方法，获得指定 bits 是否可写。代码如下：
+
+```
+/**
+ * Returns {@code true} if and only if the user-defined writability flag at the specified index is set to
+ * {@code true}.
+ */
+public boolean getUserDefinedWritability(int index) {
+    return (unwritable & writabilityMask(index)) == 0;
+}
+
+private static int writabilityMask(int index) {
+    // 不能 < 1 ，因为第 0 bits 为 ChannelOutboundBuffer 自己使用
+    // 不能 > 31 ，因为超过 int 的 bits 范围
+    if (index < 1 || index > 31) {
+        throw new IllegalArgumentException("index: " + index + " (expected: 1~31)");
+    }
+    return 1 << index;
+}
+```
+
+- 为什么方法名字上会带有 `"UserDefined"` 呢？因为 `index` 不能使用 0 ，表示只允许使用用户定义( `"UserDefined"` ) bits 位，即 `[1, 31]` 。
+
+### 10.4.2 setUserDefinedWritability
+
+`#setUserDefinedWritability(int index, boolean writable)` 方法，设置指定 bits 是否可写。代码如下：
+
+```
+/**
+ * Sets a user-defined writability flag at the specified index.
+ */
+public void setUserDefinedWritability(int index, boolean writable) {
+    // 设置可写
+    if (writable) {
+        setUserDefinedWritability(index);
+    // 设置不可写
+    } else {
+        clearUserDefinedWritability(index);
+    }
+}
+
+private void setUserDefinedWritability(int index) {
+    final int mask = ~writabilityMask(index);
+    for (;;) {
+        final int oldValue = unwritable;
+        final int newValue = oldValue & mask;
+        // CAS 设置 unwritable 为新值
+        if (UNWRITABLE_UPDATER.compareAndSet(this, oldValue, newValue)) {
+            // 若之前不可写，现在可写，触发 Channel WritabilityChanged 事件到 pipeline 中。
+            if (oldValue != 0 && newValue == 0) {
+                fireChannelWritabilityChanged(true);
+            }
+            break;
+        }
+    }
+}
+
+private void clearUserDefinedWritability(int index) {
+    final int mask = writabilityMask(index);
+    for (;;) {
+        final int oldValue = unwritable;
+        final int newValue = oldValue | mask;
+        if (UNWRITABLE_UPDATER.compareAndSet(this, oldValue, newValue)) {
+            // 若之前可写，现在不可写，触发 Channel WritabilityChanged 事件到 pipeline 中。
+            if (oldValue == 0 && newValue != 0) {
+                fireChannelWritabilityChanged(true);
+            }
+            break;
+        }
+    }
+}
+```
+
+- 代码比较简单，胖友自己看噢。
+
+# 666. 彩蛋
+
+比想象中，长的多的多的一篇文章。总的来说，绝大部分细节，都已经扣到，美滋滋。如果有解释不够清晰或错误的细节，一起多多沟通呀。
+
+写完这篇，我简直疯了。。。。
+
+推荐阅读文章：
+
+- 莫那一鲁道 [《Netty 出站缓冲区 ChannelOutboundBuffer 源码解析（isWritable 属性的重要性）》](https://www.jianshu.com/p/311425d1c72f)
+- tomas家的小拨浪鼓 [《Netty 源码解析 ——— writeAndFlush流程分析》](https://www.jianshu.com/p/a3443cacd081)
+- 闪电侠 [《netty 源码分析之 writeAndFlush 全解析》](https://www.jianshu.com/p/feaeaab2ce56)
+- 占小狼 [《深入浅出 Netty write》](https://www.jianshu.com/p/1ad424c53e80)
+- Hypercube [《自顶向下深入分析Netty（六）–Channel源码实现》](https://www.jianshu.com/p/9258af254e1d)
\ No newline at end of file
diff --git a/netty/32-Netty 源码解析-Channel（六）之 writeAndFlush 操作.md b/netty/32-Netty 源码解析-Channel（六）之 writeAndFlush 操作.md
new file mode 100644
index 0000000..a685980
--- /dev/null
+++ b/netty/32-Netty 源码解析-Channel（六）之 writeAndFlush 操作.md	
@@ -0,0 +1,130 @@
+# 精尽 Netty 源码解析 —— Channel（六）之 writeAndFlush 操作
+
+# 1. 概述
+
+本文接 [《精尽 Netty 源码解析 —— Channel（五）之 flush 操作》](http://svip.iocoder.cn/Netty/Channel-5-flush/) ，分享 Netty Channel 的 `#writeAndFlush(Object msg, ...)` 方法，write + flush 的组合，将数据写到内存队列后，立即刷新**内存队列**，又将其中的数据写入到对端。
+
+😈 本来是不准备写这篇的，因为内容主要是 [《精尽 Netty 源码解析 —— Channel（四）之 write 操作》](http://svip.iocoder.cn/Netty/Channel-4-write/) 和 [《精尽 Netty 源码解析 —— Channel（五）之 flush 操作》](http://svip.iocoder.cn/Netty/Channel-5-flush/) 的组合。但是，考虑到内容的完整性，于是乎就稍微水更下下。
+
+# 2. AbstractChannel
+
+AbstractChannel 对 `#writeAndFlush(Object msg, ...)` 方法的实现，代码如下：
+
+```
+@Override
+public ChannelFuture writeAndFlush(Object msg) {
+    return pipeline.writeAndFlush(msg);
+}
+
+@Override
+public ChannelFuture writeAndFlush(Object msg, ChannelPromise promise) {
+    return pipeline.writeAndFlush(msg, promise);
+}
+```
+
+- 在方法内部，会调用对应的
+
+   
+
+  ```
+  ChannelPipeline#write(Object msg, ...)
+  ```
+
+   
+
+  方法，将 write 和 flush
+
+   
+
+  两个
+
+  事件在 pipeline 上传播。详细解析，见
+
+   
+
+  「3. DefaultChannelPipeline」
+
+   
+
+  。
+
+  - 最终会传播 write 事件到 `head` 节点，将数据写入到内存队列中。详细解析，见 [「5. HeadContext」](https://svip.iocoder.cn/Netty/Channel-6-writeAndFlush/#) 。
+  - 最终会传播 flush 事件到 `head` 节点，刷新**内存队列**，将其中的数据写入到对端。详细解析，见 [「5. HeadContext」](https://svip.iocoder.cn/Netty/Channel-6-writeAndFlush/#) 。
+
+# 3. DefaultChannelPipeline
+
+`DefaultChannelPipeline#writeAndFlush(Object msg, ...)` 方法，代码如下：
+
+```
+@Override
+public final ChannelFuture write(Object msg) {
+    return tail.writeAndFlush(msg);
+}
+
+@Override
+public final ChannelFuture write(Object msg, ChannelPromise promise) {
+    return tail.writeAndFlush(msg, promise);
+}
+```
+
+- 在方法内部，会调用 `TailContext#writeAndFlush(Object msg, ...)` 方法，将 write 和 flush **两个**事件在 pipeline 中，从尾节点向头节点传播。详细解析，见 [「4. TailContext」](https://svip.iocoder.cn/Netty/Channel-6-writeAndFlush/#) 。
+
+# 4. TailContext
+
+TailContext 对 `TailContext#writeAndFlush(Object msg, ...)` 方法的实现，是从 AbstractChannelHandlerContext 抽象类继承，代码如下：
+
+```
+@Override
+public ChannelFuture writeAndFlush(Object msg, ChannelPromise promise) {
+    if (msg == null) {
+        throw new NullPointerException("msg");
+    }
+
+    // 判断是否为合法的 Promise 对象
+    if (isNotValidPromise(promise, true)) {
+        // 释放消息( 数据 )相关的资源
+        ReferenceCountUtil.release(msg);
+        // cancelled
+        return promise;
+    }
+
+    // 写入消息( 数据 )到内存队列
+    write(msg, true, promise); // <1>
+
+    return promise;
+}
+```
+
+- 这个方法，和我们在 [《精尽 Netty 源码解析 —— Channel（四）之 write 操作》](http://svip.iocoder.cn/Netty/Channel-4-write/) 的 [「4. TailContext」](https://svip.iocoder.cn/Netty/Channel-6-writeAndFlush/#) 的小节，`TailContext#write(Object msg, ...)` 方法，基本类似，差异在于 `<1>` 处，调用 `#write(Object msg, boolean flush, ChannelPromise promise)` 方法，传入的 `flush = true` 方法参数，表示 write 操作的同时，**后续**需要执行 flush 操作。代码如下：
+
+  ```
+  private void write(Object msg, boolean flush, ChannelPromise promise) {
+      // 获得下一个 Outbound 节点
+      AbstractChannelHandlerContext next = findContextOutbound();
+      // 简化代码 😈
+      // 执行 write + flush 操作
+      next.invokeWriteAndFlush(m, promise);
+  }
+  
+  private void invokeWriteAndFlush(Object msg, ChannelPromise promise) {
+      if (invokeHandler()) {
+          // 执行 write 事件到下一个节点
+          invokeWrite0(msg, promise);
+          // 执行 flush 事件到下一个节点
+          invokeFlush0();
+      } else {
+          writeAndFlush(msg, promise);
+      }
+  }
+  ```
+
+  - 在后面，就是 [《精尽 Netty 源码解析 —— Channel（四）之 write 操作》](http://svip.iocoder.cn/Netty/Channel-4-write/) 的 [「5. HeadContext」](https://svip.iocoder.cn/Netty/Channel-6-writeAndFlush/#) 的小节及其后续的小节。
+  - 再在后面，就是 [《精尽 Netty 源码解析 —— Channel（五）之 flush 操作》](http://svip.iocoder.cn/Netty/Channel-5-flush/) 。
+
+# 666. 彩蛋
+
+😈 真的是水更，哈哈哈哈。
+
+推荐阅读文章：
+
+- 闪电侠 [《netty 源码分析之 writeAndFlush 全解析》](https://www.jianshu.com/p/feaeaab2ce56) 的 [「writeAndFlush: 写队列并刷新」](https://svip.iocoder.cn/Netty/Channel-6-writeAndFlush/#) 小节。
\ No newline at end of file
diff --git a/netty/33-Netty 源码解析-Channel（七）之 close 操作.md b/netty/33-Netty 源码解析-Channel（七）之 close 操作.md
new file mode 100644
index 0000000..3b405a8
--- /dev/null
+++ b/netty/33-Netty 源码解析-Channel（七）之 close 操作.md	
@@ -0,0 +1,968 @@
+# 精尽 Netty 源码解析 —— Channel（七）之 close 操作
+
+# 1. 概述
+
+本文分享 Netty NIO Channel 关闭( **close** )操作的过程，分成客户端和服务端 Channel **两种**关闭：
+
+- 客户端 NioSocketChannel
+  - 客户端关闭 NioSocketChannel ，断开和服务端的连接。
+  - 服务端关闭 NioSocketChannel ，断开和客户端的连接。
+- 服务端 NioServerSocketChannel
+  - 服务端关闭 NioServerSocketChannel ，取消端口绑定，关闭服务。
+
+上面的关闭，可能是客户端/服务端主动关闭，也可能是异常关闭。
+
+- 关于 NioSocketChannel 的关闭，在 [「2. NioSocketChannel」](https://svip.iocoder.cn/Netty/Channel-7-close/#) 详细解析。
+- 关于 NioServerSocketChannel 的关闭，在 [「3. NioSocketChannel」](https://svip.iocoder.cn/Netty/Channel-7-close/#) 详细解析。
+
+# 2. NioSocketChannel
+
+通过 `NioSocketChannel#close()` 方法，应用程序里可以主动关闭 NioSocketChannel 通道。代码如下：
+
+```
+// AbstractChannel.java
+@Override
+public ChannelFuture close() {
+    return pipeline.close();
+}
+```
+
+- NioSocketChannel 继承 AbstractChannel 抽象类，所以 `#close()` 方法实际是 AbstractChannel 实现的。
+
+- 在方法内部，会调用对应的 `ChannelPipeline#close()` 方法，将 close 事件在 pipeline 上传播。而 close 事件属于 Outbound 事件，所以会从 `tail` 节点开始，最终传播到 `head` 节点，使用 Unsafe 进行关闭。代码如下：
+
+  ```
+  // DefaultChannelPipeline.java
+  @Override
+  public final ChannelFuture close() {
+      return tail.close();
+  }
+  
+  // TailContext.java
+  @Override // FROM AbstractChannelHandlerContext.java 。因为 TailContext 继承 AbstractChannelHandlerContext 抽象类，该方法是它实现的。
+  public ChannelFuture close() {
+      return close(newPromise());
+  }
+  
+  // HeadContext.java
+  @Override
+  public void close(ChannelHandlerContext ctx, ChannelPromise promise) throws Exception {
+      unsafe.close(promise);
+  }
+  ```
+
+## 2.1 AbstractUnsafe#close
+
+`AbstractUnsafe#close()` 方法，关闭 Channel 。代码如下：
+
+```
+@Override
+public final void close(final ChannelPromise promise) {
+    assertEventLoop();
+
+    // 关闭
+    close(promise, CLOSE_CLOSED_CHANNEL_EXCEPTION, CLOSE_CLOSED_CHANNEL_EXCEPTION, false);
+}
+
+  1: private void close(final ChannelPromise promise, final Throwable cause, final ClosedChannelException closeCause, final boolean notify) {
+  2:     // 设置 Promise 不可取消
+  3:     if (!promise.setUncancellable()) {
+  4:         return;
+  5:     }
+  6: 
+  7:     // 若关闭已经标记初始化
+  8:     if (closeInitiated) {
+  9:         // 关闭已经完成，直接通知 Promise 对象
+ 10:         if (closeFuture.isDone()) {
+ 11:             // Closed already.
+ 12:             safeSetSuccess(promise);
+ 13:         // 关闭未完成，通过监听器通知 Promise 对象
+ 14:         } else if (!(promise instanceof VoidChannelPromise)) { // Only needed if no VoidChannelPromise.
+ 15:             // This means close() was called before so we just register a listener and return
+ 16:             closeFuture.addListener(new ChannelFutureListener() {
+ 17:                 @Override
+ 18:                 public void operationComplete(ChannelFuture future) throws Exception {
+ 19:                     promise.setSuccess();
+ 20:                 }
+ 21:             });
+ 22:         }
+ 23:         return;
+ 24:     }
+ 25: 
+ 26:     // 标记关闭已经初始化
+ 27:     closeInitiated = true;
+ 28: 
+ 29:     // 获得 Channel 是否激活
+ 30:     final boolean wasActive = isActive();
+ 31:     // 标记 outboundBuffer 为空
+ 32:     final ChannelOutboundBuffer outboundBuffer = this.outboundBuffer;
+ 33:     this.outboundBuffer = null; // Disallow adding any messages and flushes to outboundBuffer.
+ 34:     // 执行准备关闭
+ 35:     Executor closeExecutor = prepareToClose();
+ 36:     // 若 closeExecutor 非空
+ 37:     if (closeExecutor != null) {
+ 38:         closeExecutor.execute(new Runnable() {
+ 39:             @Override
+ 40:             public void run() {
+ 41:                 try {
+ 42:                     // 在 closeExecutor 中，执行关闭
+ 43:                     // Execute the close.
+ 44:                     doClose0(promise);
+ 45:                 } finally {
+ 46:                     // 在 EventLoop 中，执行
+ 47:                     // Call invokeLater so closeAndDeregister is executed in the EventLoop again!
+ 48:                     invokeLater(new Runnable() {
+ 49:                         @Override
+ 50:                         public void run() {
+ 51:                             if (outboundBuffer != null) {
+ 52:                                 // 写入数据( 消息 )到对端失败，通知相应数据对应的 Promise 失败。
+ 53:                                 // Fail all the queued messages
+ 54:                                 outboundBuffer.failFlushed(cause, notify);
+ 55:                                 // 关闭内存队列
+ 56:                                 outboundBuffer.close(closeCause);
+ 57:                             }
+ 58:                             // 执行取消注册，并触发 Channel Inactive 事件到 pipeline 中
+ 59:                             fireChannelInactiveAndDeregister(wasActive);
+ 60:                         }
+ 61:                     });
+ 62:                 }
+ 63:             }
+ 64:         });
+ 65:     // 若 closeExecutor 为空
+ 66:     } else {
+ 67:         try {
+ 68:             // 执行关闭
+ 69:             // Close the channel and fail the queued messages in all cases.
+ 70:             doClose0(promise);
+ 71:         } finally {
+ 72:             if (outboundBuffer != null) {
+ 73:                 // 写入数据( 消息 )到对端失败，通知相应数据对应的 Promise 失败。
+ 74:                 // Fail all the queued messages.
+ 75:                 outboundBuffer.failFlushed(cause, notify);
+ 76:                 // 关闭内存队列
+ 77:                 outboundBuffer.close(closeCause);
+ 78:             }
+ 79:         }
+ 80:         // 正在 flush 中，在 EventLoop 中执行执行取消注册，并触发 Channel Inactive 事件到 pipeline 中
+ 81:         if (inFlush0) {
+ 82:             invokeLater(new Runnable() {
+ 83:                 @Override
+ 84:                 public void run() {
+ 85:                     fireChannelInactiveAndDeregister(wasActive);
+ 86:                 }
+ 87:             });
+ 88:         // 不在 flush 中，直接执行执行取消注册，并触发 Channel Inactive 事件到 pipeline 中
+ 89:         } else {
+ 90:             fireChannelInactiveAndDeregister(wasActive);
+ 91:         }
+ 92:     }
+ 93: }
+```
+
+- 方法参数 `cause`、`closeCause` ，关闭的“原因”。对于 **close** 操作来说，无论是正常关闭，还是异常关闭，通过使用 **Exception** 来表示**来源**。在 AbstractChannel 类中，枚举了所有来源：
+
+  ```
+  // AbstractChannel.java
+  private static final ClosedChannelException FLUSH0_CLOSED_CHANNEL_EXCEPTION = ThrowableUtil.unknownStackTrace(
+          new ClosedChannelException(), AbstractUnsafe.class, "flush0()");
+  private static final ClosedChannelException ENSURE_OPEN_CLOSED_CHANNEL_EXCEPTION = ThrowableUtil.unknownStackTrace(
+          new ClosedChannelException(), AbstractUnsafe.class, "ensureOpen(...)");
+  private static final ClosedChannelException CLOSE_CLOSED_CHANNEL_EXCEPTION = ThrowableUtil.unknownStackTrace(
+          new ClosedChannelException(), AbstractUnsafe.class, "close(...)");
+  private static final ClosedChannelException WRITE_CLOSED_CHANNEL_EXCEPTION = ThrowableUtil.unknownStackTrace(
+          new ClosedChannelException(), AbstractUnsafe.class, "write(...)");
+  private static final NotYetConnectedException FLUSH0_NOT_YET_CONNECTED_EXCEPTION = ThrowableUtil.unknownStackTrace(
+          new NotYetConnectedException(), AbstractUnsafe.class, "flush0()");
+  ```
+
+- 第 2 至 5 行：调用 `ChannelPromise#setUncancellable()` 方法，设置 Promise 不可取消。
+
+- 第 8 行：若
+
+   
+
+  ```
+  AbstractChannel.closeInitiated
+  ```
+
+   
+
+  为
+
+   
+
+  ```
+  true
+  ```
+
+   
+
+  时，表示关闭已经标记初始化，此时
+
+  可能
+
+  已经关闭完成。
+
+  - 第 10 至 12 行：关闭**已经**完成，直接通知 Promise 对象。
+  - 第 13 至 22 行：关闭**并未**完成，通过监听器回调通知 Promise 对象。
+  - 第 23 行：`return` 结束。
+  - 第 27 行：标记关闭已经初始化。
+
+- 第 30 行：调用 `#isActive()` 方法， 获得 Channel 是否激活。
+
+- 第 31 至 33 行：标记内存队列 `outboundBuffer` 为空。
+
+- 第 35 行：调用 `#prepareToClose()` 方法，执行准备关闭。详细解析，胖友先跳到 [「2.2 NioSocketChannelUnsafe#prepareToClose」](https://svip.iocoder.cn/Netty/Channel-7-close/#) 中。
+
+- 第 37 行：若
+
+   
+
+  ```
+  closeExecutor
+  ```
+
+   
+
+  非空，在
+
+   
+
+  「2.2 NioSocketChannelUnsafe#prepareToClose」
+
+   
+
+  中，我们已经看到如果开启
+
+   
+
+  ```
+  SO_LINGER
+  ```
+
+   
+
+  功能，会返回
+
+   
+
+  ```
+  GlobalEventExecutor.INSTANCE
+  ```
+
+   
+
+  对象。
+
+  - 第 38 至 44 行：提交任务到 `closeExecutor` 中，**在它的线程中**，执行 `#doClose0(promise)` 方法，执行关闭。为什么要在“在它的线程中”中？回答不出来的胖友，再好好重新看下 [「2.2 NioSocketChannelUnsafe#prepareToClose」](https://svip.iocoder.cn/Netty/Channel-7-close/#) 小节。
+  - 第 46 至 61 行：提交任务到 Channel 所在的 EventLoop 中，执行后续的任务。
+  - 整体的逻辑和代码，和【第 66 至 91 行】的代码是**基本**一致。
+
+- 第 66 行：若
+
+   
+
+  ```
+  closeExecutor
+  ```
+
+   
+
+  为空。
+
+  - 第 70 行：调用 `#doClose0(promise)` 方法，执行**真正的**关闭。详细解析，胖友先跳到 [「2.4 doClose0」](https://svip.iocoder.cn/Netty/Channel-7-close/#) 中。
+
+  - 第 75 行：调用 `ChannelOutboundBuffer#failFlushed(Throwable cause, boolean notify)` 方法，写入数据( 消息 )到对端失败，通知相应数据对应的 Promise 失败。详细解析，见 [《精尽 Netty 源码解析 —— Channel（五）之 flush 操作》](http://svip.iocoder.cn/Netty/Channel-5-flush/) 。
+
+  - 第 77 行：调用 `ChannelOutboundBuffer#close(Throwable cause)` 方法，关闭内存队列。详细解析，见 [《精尽 Netty 源码解析 —— Channel（五）之 flush 操作》](http://svip.iocoder.cn/Netty/Channel-5-flush/) 。
+
+  - 第 81 行：若
+
+     
+
+    ```
+    inFlush0
+    ```
+
+     
+
+    为
+
+     
+
+    ```
+    true
+    ```
+
+     
+
+    ，
+
+    正在
+
+     
+
+    flush 中，
+
+    在 EventLoop 中的线程中
+
+    ，调用
+
+     
+
+    ```
+    #fireChannelInactiveAndDeregister(boolean wasActive)
+    ```
+
+     
+
+    方法，执行取消注册，并触发 Channel Inactive 事件到 pipeline 中。详细解析，见
+
+     
+
+    「2.5 AbstractUnsafe#fireChannelInactiveAndDeregister」
+
+     
+
+    中。
+
+    - 第 90 行：若 `inFlush0` 为 `false` ，**不在** flush 中，**直接**调用 `#fireChannelInactiveAndDeregister(boolean wasActive)` 方法，执行取消注册，并触发 Channel Inactive 事件到 pipeline 中。
+
+## 2.2 NioSocketChannelUnsafe#prepareToClose
+
+`NioSocketChannelUnsafe#prepareToClose()` 方法，执行准备关闭。代码如下：
+
+```
+ 1: @Override
+ 2: protected Executor prepareToClose() {
+ 3:     try {
+ 4:         if (javaChannel().isOpen() && config().getSoLinger() > 0) {
+ 5:             // We need to cancel this key of the channel so we may not end up in a eventloop spin
+ 6:             // because we try to read or write until the actual close happens which may be later due
+ 7:             // SO_LINGER handling.
+ 8:             // See https://github.com/netty/netty/issues/4449
+ 9:             doDeregister();
+10:             // 返回 GlobalEventExecutor 对象
+11:             return GlobalEventExecutor.INSTANCE;
+12:         }
+13:     } catch (Throwable ignore) {
+14:         // Ignore the error as the underlying channel may be closed in the meantime and so
+15:         // getSoLinger() may produce an exception. In this case we just return null.
+16:         // See https://github.com/netty/netty/issues/4449
+17:     }
+18:     return null;
+19: }
+```
+
+- 第 4 行：如果配置 `StandardSocketOptions.SO_LINGER` 大于 0 。让我们先来看下它的定义：
+
+  ```
+  Socket 参数，关闭 Socket 的延迟时间，Netty 默认值为 -1 ，表示禁用该功能。
+  
+  * -1 表示 socket.close() 方法立即返回，但 OS 底层会将发送缓冲区全部发送到对端。
+  * 0 表示 socket.close() 方法立即返回，OS 放弃发送缓冲区的数据直接向对端发送RST包，对端收到复位错误。
+  * 非 0 整数值表示调用 socket.close() 方法的线程被阻塞直到延迟时间到或发送缓冲区中的数据发送完毕，若超时，则对端会收到复位错误。
+  ```
+
+  - 按照这个定义，如果**大于 0**，如果在**真正关闭** Channel ，需要**阻塞**直到延迟时间到或发送缓冲区中的数据发送完毕。
+  - 如果在 EventLoop 中执行**真正关闭** Channel 的操作，那么势必会阻塞 EventLoop 的线程。所以，在【第 11 行】的代码，返回 `GlobalEventExecutor.INSTANCE` 对象，作为执行**真正关闭** Channel 的操作的**执行器**( 它也有一个自己的线程哟 )。
+
+- 第 9 行：调用 `#doDeregister()` 方法，执行取消注册。详细解析，胖友先跳到 [「2.2 AbstractUnsafe#doDeregister」](https://svip.iocoder.cn/Netty/Channel-7-close/#) 中。
+
+- 【来自我表弟普架的牛逼解答，我表示点赞支持】第 9 行的：为什么要调用
+
+   
+
+  ```
+  #doDeregister()
+  ```
+
+   
+
+  方法呢？因为
+
+   
+
+  ```
+  SO_LINGER
+  ```
+
+   
+
+  大于 0 时，
+
+  真正关闭
+
+   
+
+  Channel ，需要
+
+  阻塞
+
+  直到延迟时间到或发送缓冲区中的数据发送完毕。如果不取消该 Channel 的
+
+   
+
+  ```
+  SelectionKey.OP_READ
+  ```
+
+   
+
+  事件的感兴趣，就会不断触发读事件，导致 CPU 空轮询。为什么呢?在 Channel 关闭时，会
+
+  自动
+
+  触发
+
+   
+
+  ```
+  SelectionKey.OP_READ
+  ```
+
+   
+
+  事件。而且，会不断不断不断的触发，如果不进行取消
+
+   
+
+  ```
+  SelectionKey.OP_READ
+  ```
+
+   
+
+  事件的感兴趣。
+
+  - 😈 感叹一句，细思极恐啊，厉害了，Netty 。
+
+- 第 11 行：如果开启 `SO_LINGER` 功能，返回 `GlobalEventExecutor.INSTANCE` 对象。
+
+- 第 18 行：若果关闭 `SO_LINGER` 功能，返回 `null` 对象。
+
+- 😈 胖友，调回 [「2.1 AbstractUnsafe#close」](https://svip.iocoder.cn/Netty/Channel-7-close/#) 继续把。
+
+## 2.3 AbstractUnsafe#doDeregister
+
+`AbstractUnsafe#doDeregister()` 方法，执行取消注册。代码如下：
+
+```
+@Override
+protected void doDeregister() throws Exception {
+    eventLoop().cancel(selectionKey());
+}
+```
+
+- 调用 `EventLoop#cancel(SelectionKey key)` 方法，取消 SelectionKey ，即相当于调用 `SelectionKey#cancel()` 方法。如此，对通道的读写等等 IO 就绪事件不再感兴趣，也不会做出相应的处理。
+
+## 2.4 AbstractUnsafe#doClose0
+
+`AbstractUnsafe#doClose0(ChannelPromise promise)` 方法，执行**真正的**关闭。代码如下：
+
+```
+ 1: private void doClose0(ChannelPromise promise) {
+ 2:     try {
+ 3:         // 执行关闭
+ 4:         doClose();
+ 5:         // 通知 closeFuture 关闭完成
+ 6:         closeFuture.setClosed();
+ 7:         // 通知 Promise 关闭成功
+ 8:         safeSetSuccess(promise);
+ 9:     } catch (Throwable t) {
+10:         // 通知 closeFuture 关闭完成
+11:         closeFuture.setClosed();
+12:         // 通知 Promise 关闭异常
+13:         safeSetFailure(promise, t);
+14:     }
+15: }
+```
+
+- 第 4 行：调用 `#doClose()` 方法，执行关闭。这是一个**抽象**方法，NioSocketChannel 对它的实现，胖友先跳到 [「2.4.1 NioSocketChannel#doClose」 ](https://svip.iocoder.cn/Netty/Channel-7-close/#)中。
+
+- 第 6 行：调用 `CloseFuture#setClosed()` 方法，通知 `closeFuture` 关闭完成。此处就会结束我们在 EchoClient 的阻塞监听客户端关闭。例如：
+
+  ```
+  // Wait until the connection is closed.
+  // 监听客户端关闭，并阻塞等待
+  f.channel().closeFuture().sync();
+  ```
+
+  - 哟哟哟，就要结束阻塞等待了。
+
+- 第 8 行：调用 `#safeSetSuccess(promise)` 方法，通知 通知 Promise 关闭**成功**。此处就会回调我们对 `Channel#close()` 方法的返回的 ChannelFuture 的监听。示例如下：
+
+  ```
+  ctx.channel().close().addListener(new ChannelFutureListener() { // 我是一个萌萌哒监听器
+      @Override
+      public void operationComplete(ChannelFuture future) throws Exception {
+          System.out.println(Thread.currentThread() + "我会被唤醒");
+      }
+  });
+  ```
+
+  - 哟哟哟，要被回调了。
+
+- 若发生异常：
+
+  - 第 11 行：调用 `CloseFuture#setClosed()` 方法，通知 `closeFuture` 关闭完成。
+  - 第 13 行: 调用 `#safeSetFailure(promise, t)` 方法，通知 通知 Promise 关闭**异常**。
+
+### 2.4.1 NioSocketChannel#doClose
+
+`NioSocketChannel#doClose()` 方法，执行 Java 原生 NIO SocketChannel 关闭。代码如下：
+
+```
+1: @Override
+2: protected void doClose() throws Exception {
+3:     // 执行父类关闭方法
+4:     super.doClose();
+5:     // 执行 Java 原生 NIO SocketChannel 关闭
+6:     javaChannel().close();
+7: }
+```
+
+- 第 4 行：调用 `AbstractNioChannel#doClose()` 方法，执行**父类**关闭方法。代码如下：
+
+  ```
+  @Override
+  protected void doClose() throws Exception {
+      // 通知 connectPromise 异常失败
+      ChannelPromise promise = connectPromise;
+      if (promise != null) {
+          // Use tryFailure() instead of setFailure() to avoid the race against cancel().
+          promise.tryFailure(DO_CLOSE_CLOSED_CHANNEL_EXCEPTION);
+          connectPromise = null;
+      }
+  
+      // 取消 connectTimeoutFuture 等待
+      ScheduledFuture<?> future = connectTimeoutFuture;
+      if (future != null) {
+          future.cancel(false);
+          connectTimeoutFuture = null;
+      }
+  }
+  ```
+
+  - 适用于客户端**正在**发起对服务端的连接的阶段。
+
+- 【重要】第 6 行：调用 `SocketChannel#close()` 方法，执行 Java 原生 NIO SocketChannel 关闭。
+
+## 2.5 AbstractUnsafe#fireChannelInactiveAndDeregister
+
+`AbstractUnsafe#fireChannelInactiveAndDeregister(boolean wasActive)` 方法，执行取消注册，并触发 Channel Inactive 事件到 pipeline 中。代码如下：
+
+```
+private void fireChannelInactiveAndDeregister(final boolean wasActive) {
+    deregister(voidPromise() /** <1> **/, wasActive && !isActive() /** <2> **/); 
+}
+
+  1: private void deregister(final ChannelPromise promise, final boolean fireChannelInactive) {
+  2:     // 设置 Promise 不可取消
+  3:     if (!promise.setUncancellable()) {
+  4:         return;
+  5:     }
+  6: 
+  7:     // 不处于已经注册状态，直接通知 Promise 取消注册成功。
+  8:     if (!registered) {
+  9:         safeSetSuccess(promise);
+ 10:         return;
+ 11:     }
+ 12: 
+ 13:     // As a user may call deregister() from within any method while doing processing in the ChannelPipeline,
+ 14:     // we need to ensure we do the actual deregister operation later. This is needed as for example,
+ 15:     // we may be in the ByteToMessageDecoder.callDecode(...) method and so still try to do processing in
+ 16:     // the old EventLoop while the user already registered the Channel to a new EventLoop. Without delay,
+ 17:     // the deregister operation this could lead to have a handler invoked by different EventLoop and so
+ 18:     // threads.
+ 19:     //
+ 20:     // See:
+ 21:     // https://github.com/netty/netty/issues/4435
+ 22:     invokeLater(new Runnable() {
+ 23:         @Override
+ 24:         public void run() {
+ 25:             try {
+ 26:                 // 执行取消注册
+ 27:                 doDeregister();
+ 28:             } catch (Throwable t) {
+ 29:                 logger.warn("Unexpected exception occurred while deregistering a channel.", t);
+ 30:             } finally {
+ 31:                 // 触发 Channel Inactive 事件到 pipeline 中
+ 32:                 if (fireChannelInactive) {
+ 33:                     pipeline.fireChannelInactive();
+ 34:                 }
+ 35: 
+ 36:                 // Some transports like local and AIO does not allow the deregistration of
+ 37:                 // an open channel.  Their doDeregister() calls close(). Consequently,
+ 38:                 // close() calls deregister() again - no need to fire channelUnregistered, so check
+ 39:                 // if it was registered.
+ 40:                 if (registered) {
+ 41:                     // 标记为未注册
+ 42:                     registered = false;
+ 43:                     // 触发 Channel Unregistered 事件到 pipeline 中
+ 44:                     pipeline.fireChannelUnregistered();
+ 45:                 }
+ 46: 
+ 47:                 // 通知 Promise 取消注册成功。
+ 48:                 safeSetSuccess(promise);
+ 49:             }
+ 50:         }
+ 51:     });
+ 52: }
+```
+
+- `<1>` 处，传入 `#deregister(...)` 方法的第一个参数为 `unsafeVoidPromise` ，类型为 VoidChannelPromise **类**，表示需要通知 Promise 。为什么这么说呢？在 `#safeSetSuccess(promise)` 方法中，可以看到：
+
+  ```
+  protected final void safeSetSuccess(ChannelPromise promise) {
+      if (!(promise instanceof VoidChannelPromise) && !promise.trySuccess()) {
+          logger.warn("Failed to mark a promise as success because it is done already: {}", promise);
+      }
+  }
+  ```
+
+  - `!(promise instanceof VoidChannelPromise)` 代码块，表示排除 VoidChannelPromise 类型的 `promise` 。
+
+- `<2>` 处，通过对比新老的 `active` 的值，判断是否 Channel 的状态是否从 Active 变成 Inactive 。
+
+- 第 2 至 5 行：调用 `ChannelPromise#setUncancellable()` 方法，设置 Promise 不可取消。
+
+- 第 7 至 11 行：不处于已经注册状态，直接通知 Promise 取消注册成功，并
+
+   
+
+  ```
+  return
+  ```
+
+   
+
+  返回。
+
+  - 😈 在当前情况下，`registered = true` ，所以不符合条件。
+
+- 第 22 行：调用
+
+   
+
+  ```
+  #invokeLater(Runnable)
+  ```
+
+   
+
+  方法，提交任务到 EventLoop 的线程中执行，以避免
+
+  一个
+
+   
+
+  Channel 的 ChannelHandler 在
+
+  不同
+
+  的 EventLoop 或者线程中执行。详细的说明，可以看下【第 13 至 21 行】的英文说明。
+
+  - 😈 实际从目前该方法的调用看下来，有可能不是从 EventLoop 的线程中调用。
+
+- 第 27 行：调用 `AbstractUnsafe#doDeregister()` 方法，执行取消注册。在 [「2.3 AbstractUnsafe#doDeregister」](https://svip.iocoder.cn/Netty/Channel-7-close/#) 中，已经详细解析。
+
+- 第 31 至 34 行：如果 `fireChannelInactive = true` ，调用 `ChannelPipeline#fireChannelInactive()` 方法，触发 Channel Inactive 事件到 pipeline 中。而 Channel Inactive 事件属于 Inbound 事件，所以会从 `head` 节点开始，最终传播到 `tail` 节点，目前并未执行什么逻辑，感兴趣的胖友，可以自己去看看。如果胖友业务上有需要，可以自己添加 ChannelHandler 进行处理。
+
+- 第 40 至 42 行：标记为未注册。
+
+- 第 44 行：调用
+
+   
+
+  ```
+  ChannelPipeline#fireChannelUnregistered()
+  ```
+
+   
+
+  方法，触发 Channel Unregistered 事件到 pipeline 中。而 Channel Unregistered 事件属于 Inbound 事件，所以会从
+
+   
+
+  ```
+  head
+  ```
+
+   
+
+  节点开始，最终传播到
+
+   
+
+  ```
+  tail
+  ```
+
+   
+
+  节点，目前并未执行什么逻辑，感兴趣的胖友，可以自己去看看。如果胖友业务上有需要，可以自己添加 ChannelHandler 进行处理。
+
+  - 😈 又啰嗦了一遍，【第 31 至 34 行】的代码的逻辑。
+
+- 第 48 行：调用 `#safeSetSuccess(promise)` 方法，通知 Promise 取消注册成功。
+
+# 3. NioServerSocketChannel
+
+通过 `NioServerSocketChannel#close()` 方法，应用程序里可以主动关闭 NioServerSocketChannel 通道。在具体的代码实现上，唯一的差别就是对 `AbstractNioChannel#doClose()` 方法的实现不同( 对应 [「2.4.1 NioSocketChannel#doClose」](https://svip.iocoder.cn/Netty/Channel-7-close/#) )。代码如下：
+
+`NioSocketChannel#doClose()` 方法，执行 Java 原生 NIO SocketServerChannel 关闭。代码如下：
+
+```
+@Override
+protected void doClose() throws Exception {
+    javaChannel().close();
+}
+```
+
+- 调用 `SocketServerChannel#close()` 方法，执行 Java 原生 NIO SocketServerChannel 关闭。
+
+------
+
+那么可能会有胖友有疑惑了，`#close()` 方法的实现，99.99% 都相似，那么 NioSocketChannel 和 NioServerSocketChannel 差异的关闭逻辑怎么实现呢？答案其实很简单，通过给它们配置不同的 ChannelHandler 实现类即可。
+
+# 4. Unsafe#closeForcibly
+
+实际上，在 Unsafe 接口上定义了 `#closeForcibly()` 方法，英文注释如下：
+
+```
+/**
+ * Closes the {@link Channel} immediately without firing any events.  Probably only useful
+ * when registration attempt failed.
+ */
+void closeForcibly();
+```
+
+- 立即关闭 Channel ，并且不触发 pipeline 上的任何事件。
+- 仅仅用于 Channel 注册到 EventLoop 上失败的情况下。😈 这也就是为什么 `without firing any events` 的原因啦。
+
+AbstractUnsafe 对该接口方法，实现代码如下：
+
+```
+@Override
+public final void closeForcibly() {
+    assertEventLoop();
+
+    try {
+        doClose();
+    } catch (Exception e) {
+        logger.warn("Failed to close a channel.", e);
+    }
+}
+```
+
+- 在方法内部，调用 `AbstractNioChannel#doClose()` 方法，执行 Java 原生 NIO SocketServerChannel 或 SocketChannel 关闭。
+- 并且，从代码实现上，我们可以看到，确实并未触发任何 pipeline 上的事件。
+
+# 5. 服务端处理客户端主动关闭连接
+
+在客户端主动关闭时，服务端会收到一个 `SelectionKey.OP_READ` 事件的就绪，在调用客户端对应在服务端的 SocketChannel 的 `#read()` 方法会返回 **-1** ，从而实现在服务端关闭客户端的逻辑。在 Netty 的实现，在 `NioByteUnsafe#read()` 方法中，简化代码如下：
+
+```
+// <1>
+// 读取数据
+// 设置最后读取字节数
+allocHandle.lastBytesRead(doReadBytes(byteBuf));
+// 如果最后读取的字节为小于 0 ，说明对端已经关闭
+close = allocHandle.lastBytesRead() < 0;
+
+// 关闭客户端的连接
+if (close) {
+    closeOnRead(pipeline);
+}
+```
+
+- `<1>` 处，读取客户端的 SocketChannel 返回 **-1** ，说明客户端已经关闭。
+
+- `<2>` 处，调用 `#closeOnRead(ChannelPipeline pipeline)` 方法，关闭客户端的连接。代码如下：
+
+  ```
+   1: private void closeOnRead(ChannelPipeline pipeline) {
+   2:     if (!isInputShutdown0()) {
+   3:         // 开启连接半关闭
+   4:         if (isAllowHalfClosure(config())) {
+   5:             // 关闭 Channel 数据的读取
+   6:             shutdownInput();
+   7:             // 触发 ChannelInputShutdownEvent.INSTANCE 事件到 pipeline 中
+   8:             pipeline.fireUserEventTriggered(ChannelInputShutdownEvent.INSTANCE);
+   9:         } else {
+  10:             close(voidPromise());
+  11:         }
+  12:     } else {
+  13:         // 标记 inputClosedSeenErrorOnRead 为 true
+  14:         inputClosedSeenErrorOnRead = true;
+  15:         // 触发 ChannelInputShutdownEvent.INSTANCE 事件到 pipeline 中
+  16:         pipeline.fireUserEventTriggered(ChannelInputShutdownReadComplete.INSTANCE);
+  17:     }
+  18: }
+  ```
+
+  - 第 2 行：调用 `NioSocketChannel#isInputShutdown0()` 方法，判断是否关闭 Channel 数据的读取。代码如下：
+
+    ```
+    // NioSocketChannel.java
+    @Override
+    protected boolean isInputShutdown0() {
+        return isInputShutdown();
+    }
+    
+    @Override
+    public boolean isInputShutdown() {
+        return javaChannel().socket().isInputShutdown() || !isActive();
+    }
+    
+    // java.net.Socket.java
+    private boolean shutIn = false;
+    /**
+     * Returns whether the read-half of the socket connection is closed.
+     *
+     * @return true if the input of the socket has been shutdown
+     * @since 1.4
+     * @see #shutdownInput
+     */
+    public boolean isInputShutdown() {
+        return shutIn;
+    }
+    ```
+
+    - 😈 注意看下英文注释。
+
+  - `<1>` 第 4 行：调用 `AbstractNioByteChannel#isAllowHalfClosure()` 方法，判断是否开启连接**半关闭**的功能。代码如下：
+
+    ```
+    // AbstractNioByteChannel.java
+    private static boolean isAllowHalfClosure(ChannelConfig config) {
+        return config instanceof SocketChannelConfig &&
+                ((SocketChannelConfig) config).isAllowHalfClosure();
+    }
+    ```
+
+    - 可通过
+
+       
+
+      ```
+      ALLOW_HALF_CLOSURE
+      ```
+
+       
+
+      配置项开启。
+
+      - Netty 参数，一个连接的远端关闭时本地端是否关闭，默认值为 `false` 。
+      - 值为 `false`时，连接自动关闭。
+      - 值为 `true` 时，触发 ChannelInboundHandler 的`#userEventTriggered()` 方法，事件 ChannelInputShutdownEvent 。
+
+    - `<1.1>` 第 6 行：调用 `NioSocketChannel#shutdownInput()` 方法，关闭 Channel 数据的读取。代码如下：
+
+      ```
+      @Override
+      public ChannelFuture shutdownInput() {
+          return shutdownInput(newPromise());
+      }
+      
+      @Override
+      public ChannelFuture shutdownInput(final ChannelPromise promise) {
+          EventLoop loop = eventLoop();
+          if (loop.inEventLoop()) {
+              shutdownInput0(promise);
+          } else {
+              loop.execute(new Runnable() {
+                  @Override
+                  public void run() {
+                      shutdownInput0(promise);
+                  }
+              });
+          }
+          return promise;
+      }
+      
+      private void shutdownInput0(final ChannelPromise promise) {
+          try {
+              // 关闭 Channel 数据的读取
+              shutdownInput0();
+              // 通知 Promise 成功
+              promise.setSuccess();
+          } catch (Throwable t) {
+              // 通知 Promise 失败
+              promise.setFailure(t);
+          }
+      }
+      
+      private void shutdownInput0() throws Exception {
+          // 调用 Java NIO Channel 的 shutdownInput 方法
+          if (PlatformDependent.javaVersion() >= 7) {
+              javaChannel().shutdownInput();
+          } else {
+              javaChannel().socket().shutdownInput();
+          }
+      }
+      ```
+
+      - 核心是，调用 Java NIO Channel 的 shutdownInput 方法。
+
+    - `<1.1>` 第 8 行：调用 `ChannelPipeline#fireUserEventTriggered(Object event)` 方法，触发 `ChannelInputShutdownEvent.INSTANCE` 事件到 pipeline 中。关于这个事件，胖友可以看看 [《netty 处理远程主机强制关闭一个连接》](https://my.oschina.net/chenleijava/blog/484667) 。
+
+    - `<1.2>` 第 9 至 11 行：调用 `#close(Promise)` 方法，关闭客户端的 Channel 。后续的，就是 [「2. NioSocketChannel」](https://svip.iocoder.cn/Netty/Channel-7-close/#) 中。
+
+- 第 12 至 17 行：
+
+  - 第 14 行：标记 `inputClosedSeenErrorOnRead` 为 `true` 。原因如下：
+
+    ```
+    /**
+     * 通道关闭读取，又错误读取的错误的标识
+     *
+     * 详细见 https://github.com/netty/netty/commit/ed0668384b393c3502c2136e3cc412a5c8c9056e 提交
+     */
+    private boolean inputClosedSeenErrorOnRead;
+    ```
+
+    - 如下是提交的说明：
+
+      ```
+      AbstractNioByteChannel will detect that the remote end of the socket has
+      been closed and propagate a user event through the pipeline. However if
+      the user has auto read on, or calls read again, we may propagate the
+      same user events again. If the underlying transport continuously
+      notifies us that there is read activity this will happen in a spin loop
+      which consumes unnecessary CPU.
+      ```
+
+      - 胖友认真看下英文注释。结合 [《NIO read spin event loop spin when half closed #7801》](https://github.com/netty/netty/pull/7801) 提供的示例。
+
+      - 在标记 `inputClosedSeenErrorOnRead = true` 后，在 `NioByteUnsafe#read()` 方法中，会主动对 `SelectionKey.OP_READ` 的感兴趣，避免空轮询。代码如下：
+
+        ```
+        // AbstractNioByteUnsafe.java
+        public final void read() {
+            final ChannelConfig config = config();
+            // 若 inputClosedSeenErrorOnRead = true ，移除对 SelectionKey.OP_READ 事件的感兴趣。
+            if (shouldBreakReadReady(config)) {
+                clearReadPending(); // 移除对 SelectionKey.OP_READ 事件的感兴趣
+                return;
+            }
+            
+            // ... 省略其他代码。
+        }
+        
+        // AbstractNioByteChannel.java
+        final boolean shouldBreakReadReady(ChannelConfig config) {
+            return isInputShutdown0() && (inputClosedSeenErrorOnRead || !isAllowHalfClosure(config));
+        }
+        ```
+
+        - x
+
+  - 第 16 行：调用 `ChannelPipeline#fireUserEventTriggered(Object event)` 方法，触发 `ChannelInputShutdownEvent.INSTANCE` 事件到 pipeline 中。
+
+# 666. 彩蛋
+
+比想象中简单的文章。但是，卡了比较久的时间。主要是针对 [《High CPU usage with SO_LINGER and sudden connection close (4.0.26.Final+) #4449》](https://github.com/netty/netty/issues/4449) 的讨论，中间请教了基友闪电侠和表弟普架。
+
+痛并快乐的过程。如果英文好一点，相信解决的过程，可能更加愉快一些把。
\ No newline at end of file
diff --git a/netty/34-Netty 源码解析-Channel（八）之 disconnect 操作.assets/01.png b/netty/34-Netty 源码解析-Channel（八）之 disconnect 操作.assets/01.png
new file mode 100644
index 0000000..0ebbcd8
Binary files /dev/null and b/netty/34-Netty 源码解析-Channel（八）之 disconnect 操作.assets/01.png differ
diff --git a/netty/34-Netty 源码解析-Channel（八）之 disconnect 操作.assets/02.png b/netty/34-Netty 源码解析-Channel（八）之 disconnect 操作.assets/02.png
new file mode 100644
index 0000000..38a514f
Binary files /dev/null and b/netty/34-Netty 源码解析-Channel（八）之 disconnect 操作.assets/02.png differ
diff --git a/netty/34-Netty 源码解析-Channel（八）之 disconnect 操作.md b/netty/34-Netty 源码解析-Channel（八）之 disconnect 操作.md
new file mode 100644
index 0000000..9b0bf98
--- /dev/null
+++ b/netty/34-Netty 源码解析-Channel（八）之 disconnect 操作.md	
@@ -0,0 +1,146 @@
+# 精尽 Netty 源码解析 —— Channel（八）之 disconnect 操作
+
+# 1. 概述
+
+本文分享 Netty NIO Channel **客户端**断开连接( **disconnect** )操作的过程。
+
+在看 Netty NIO Channel 对 `#disconnect(ChannelPromise promise)` 方法的实现代码之前，我们先来看看 Java **原生** NIO SocketChannel 的 `#disconnect()` 方法。
+
+- 结果，结果，结果，翻了半天，只看到 NIO SocketChannel 的父类 AbstractInterruptibleChannel 中，有 `#close()` 方法，而找不到 `#disconnect()` 方法。这个是啥情况？
+- 我们又去翻了 Java **原生** UDP DatagramSocket 类，结果找到了 `#connect()` 方法。这个又是啥情况？
+
+不卖关子了，直接说结论啦：
+
+- Java **原生** NIO SocketChannel **不存在**，当调用 Netty `NioSocketChannel#disconnect(ChannelPromise promise)` 时，会自动转换成 **close** 操作，即 [《精尽 Netty 源码解析 —— Channel（七）之 close 操作》](http://svip.iocoder.cn/Netty/Channel-7-close/) 。
+- 实际上， `Channel#disconnect(ChannelPromise promise)` 方法，是 Netty 为 UDP 设计的。
+
+# 2. NioSocketChannel
+
+通过 `NioSocketChannel#disconnect()` 方法，应用程序里可以主动关闭 NioSocketChannel 通道。代码如下：
+
+```
+@Override
+public ChannelFuture disconnect() {
+    return pipeline.disconnect();
+}
+```
+
+- NioSocketChannel 继承 AbstractChannel 抽象类，所以 `#disconnect()` 方法实际是 AbstractChannel 实现的。
+- 在方法内部，会调用对应的 `ChannelPipeline#disconnect()` 方法，将 disconnect 事件在 pipeline 上传播。
+
+# 3. DefaultChannelPipeline
+
+`DefaultChannelPipeline#disconnect()` 方法，代码如下：
+
+```
+@Override
+public final ChannelPipeline disconnect() {
+    tail.disconnect();
+    return this;
+}
+```
+
+- 在方法内部，会调用 `TailContext#disconnect()` 方法，将 flush 事件在 pipeline 中，从尾节点向头节点传播。详细解析，见 [「4. TailContext」](https://svip.iocoder.cn/Netty/Channel-8-disconnect/#) 。
+
+# 4. TailContext
+
+TailContext 对 `#flush()` 方法的实现，是从 AbstractChannelHandlerContext 抽象类继承，代码如下：
+
+```
+@Override
+public ChannelFuture disconnect() {
+    return disconnect(newPromise());
+}
+
+@Override
+public ChannelFuture disconnect(final ChannelPromise promise) {
+    // 判断是否为合法的 Promise 对象
+    if (isNotValidPromise(promise, false)) {
+        // cancelled
+        return promise;
+    }
+
+    final AbstractChannelHandlerContext next = findContextOutbound();
+    EventExecutor executor = next.executor();
+    if (executor.inEventLoop()) {
+        // <1> 如果没有 disconnect 操作，则执行 close 事件在 pipeline 上
+        // Translate disconnect to close if the channel has no notion of disconnect-reconnect.
+        // So far, UDP/IP is the only transport that has such behavior.
+        if (!channel().metadata().hasDisconnect()) {
+            next.invokeClose(promise);
+        // 如果有 disconnect 操作，则执行 disconnect 事件在 pipeline 上
+        } else {
+            next.invokeDisconnect(promise);
+        }
+    } else {
+        safeExecute(executor, new Runnable() {
+            @Override
+            public void run() {
+                // <1> 如果没有 disconnect 操作，则执行 close 事件在 pipeline 上
+                if (!channel().metadata().hasDisconnect()) {
+                    next.invokeClose(promise);
+                    // 如果有 disconnect 操作，则执行 disconnect 事件在 pipeline 上
+                } else {
+                    next.invokeDisconnect(promise);
+                }
+            }
+        }, promise, null);
+    }
+    return promise;
+}
+```
+
+- 在
+
+   
+
+  ```
+  <1>
+  ```
+
+   
+
+  处，调用
+
+   
+
+  ```
+  ChannelMetadata#hasDisconnect()
+  ```
+
+   
+
+  方法，判断 Channel
+
+   
+
+  是否支持
+
+   
+
+  disconnect 操作。
+
+  - 如果支持，则**转换**执行 close 事件在 pipeline 上。后续的逻辑，就是 [《精尽 Netty 源码解析 —— Channel（七）之 close 操作》](http://svip.iocoder.cn/Netty/Channel-7-close/) 。
+  - 如果不支持，则**保持**执行 disconnect 事件在 pipeline 上。
+
+- 支持 disconnect 操作的 Netty Channel 实现类有：
+
+  ![支持](34-Netty 源码解析-Channel（八）之 disconnect 操作.assets/01.png)
+
+  支持
+
+  - 和文头，我们提到的，只有 Java **原生** UDP DatagramSocket 支持是一致的。从 `So far, UDP/IP is the only transport that has such behavior.` 的英文注释，也能证实这一点。
+
+- 不支持 disconnect 操作的 Netty Channel 实现类有：
+
+  ![不支持](34-Netty 源码解析-Channel（八）之 disconnect 操作.assets/02.png)
+
+  不支持
+
+  - 和文头，我们提到的，只有 Java **原生** NIO SocketChannel 不支持是一致的。
+
+因为本系列，暂时不分享 UDP 相关的内容，所以对“执行 disconnect 事件在 pipeline 上”就不解析了。
+
+# 666. 彩蛋
+
+水更一篇，本来以为 Netty NIO Channel 的 disconnect 操作是个**骚**操作。
\ No newline at end of file
diff --git a/netty/35-Netty 源码解析-Buffer 之 ByteBuf（一）简介.assets/01.png b/netty/35-Netty 源码解析-Buffer 之 ByteBuf（一）简介.assets/01.png
new file mode 100644
index 0000000..4b6f21a
Binary files /dev/null and b/netty/35-Netty 源码解析-Buffer 之 ByteBuf（一）简介.assets/01.png differ
diff --git a/netty/35-Netty 源码解析-Buffer 之 ByteBuf（一）简介.assets/02.png b/netty/35-Netty 源码解析-Buffer 之 ByteBuf（一）简介.assets/02.png
new file mode 100644
index 0000000..9a83d22
Binary files /dev/null and b/netty/35-Netty 源码解析-Buffer 之 ByteBuf（一）简介.assets/02.png differ
diff --git a/netty/35-Netty 源码解析-Buffer 之 ByteBuf（一）简介.assets/03.png b/netty/35-Netty 源码解析-Buffer 之 ByteBuf（一）简介.assets/03.png
new file mode 100644
index 0000000..fc7ff52
Binary files /dev/null and b/netty/35-Netty 源码解析-Buffer 之 ByteBuf（一）简介.assets/03.png differ
diff --git a/netty/35-Netty 源码解析-Buffer 之 ByteBuf（一）简介.assets/05.png b/netty/35-Netty 源码解析-Buffer 之 ByteBuf（一）简介.assets/05.png
new file mode 100644
index 0000000..2c4765f
Binary files /dev/null and b/netty/35-Netty 源码解析-Buffer 之 ByteBuf（一）简介.assets/05.png differ
diff --git a/netty/35-Netty 源码解析-Buffer 之 ByteBuf（一）简介.assets/06.png b/netty/35-Netty 源码解析-Buffer 之 ByteBuf（一）简介.assets/06.png
new file mode 100644
index 0000000..f17fe27
Binary files /dev/null and b/netty/35-Netty 源码解析-Buffer 之 ByteBuf（一）简介.assets/06.png differ
diff --git a/netty/35-Netty 源码解析-Buffer 之 ByteBuf（一）简介.md b/netty/35-Netty 源码解析-Buffer 之 ByteBuf（一）简介.md
new file mode 100644
index 0000000..b9a1ff2
--- /dev/null
+++ b/netty/35-Netty 源码解析-Buffer 之 ByteBuf（一）简介.md	
@@ -0,0 +1,1462 @@
+# 精尽 Netty 源码解析 —— Buffer 之 ByteBuf（一）简介
+
+# 1. 概述
+
+从本文开始，我们来分享 Netty ByteBuf 相关的内容。它在 `buffer` 模块中实现，在功能定位上，它和 NIO ByteBuffer 是一致的，但是强大非常多。如下是 [《Netty 实战》](https://svip.iocoder.cn/Netty/ByteBuf-1-1-ByteBuf-intro/#) 对它的**优点总**结：
+
+> - A01. 它可以被用户自定义的**缓冲区类型**扩展
+> - A02. 通过内置的符合缓冲区类型实现了透明的**零拷贝**
+> - A03. 容量可以**按需增长**
+> - A04. 在读和写这两种模式之间切换不需要调用 `#flip()` 方法
+> - A05. 读和写使用了**不同的索引**
+> - A06. 支持方法的**链式**调用
+> - A07. 支持引用计数
+> - A08. 支持**池化**
+
+- 特别是第 A04 这点，相信很多胖友都被 NIO ByteBuffer 反人类的读模式和写模式给坑哭了。在 [《精尽 Netty 源码分析 —— NIO 基础（三）之 Buffer》](http://svip.iocoder.cn/Netty/nio-3-buffer/) 中，我们也吐槽过了。😈
+- 当然，可能胖友看着这些优点，会一脸懵逼，不要紧，边读源码边理解落。
+
+------
+
+> 老艿艿，从下文开始，Netty ByteBuf ，我们只打 ByteBuf 。相比 NIO ByteBuffer ，它少 `"fer"` 三个字母。
+
+ByteBuf 的代码实现挺有趣的，但是会略有一点点深度，所以笔者会分成三大块来分享：
+
+- ByteBuf 相关，主要是它的核心 API 和核心子类实现。
+- ByteBufAllocator 相关，用于创建 ByteBuf 对象。
+- Jemalloc 相关，内存管理算法，Netty 基于该算法，实现对内存高效和有效的管理。😈 这块是最最最有趣的。
+
+每一块，我们会分成几篇小的文章。而本文，我们就来对 ByteBuf 有个整体的认识，特别是核心 API 部分。
+
+# 2. ByteBuf
+
+`io.netty.buffer.ByteBuf` ，实现 ReferenceCounted 、Comparable 接口，ByteBuf **抽象类**。注意，ByteBuf 是一个抽象类，而不是一个接口。当然，实际上，它主要定义了**抽象**方法，**很少**实现对应的方法。
+
+关于 `io.netty.util.ReferenceCounted` 接口，对象引用计数器接口。
+
+- 对象的初始引用计数为 1 。
+- 当引用计数器值为 0 时，表示该对象不能再被继续引用，只能被释放。
+- 本文暂时不解析，我们会在 TODO 1011
+
+## 2.1 抽象方法
+
+因为 ByteBuf 的方法非常多，所以笔者对它的方法做了简单的归类。Let’s Go 。
+
+### 2.1.1 基础信息
+
+```
+public abstract int capacity(); // 容量
+public abstract ByteBuf capacity(int newCapacity);
+public abstract int maxCapacity(); // 最大容量
+
+public abstract ByteBufAllocator alloc(); // 分配器，用于创建 ByteBuf 对象。
+
+@Deprecated
+public abstract ByteOrder order(); // 字节序，即大小端。推荐阅读 http://www.ruanyifeng.com/blog/2016/11/byte-order.html
+@Deprecated
+public abstract ByteBuf order(ByteOrder endianness);
+
+public abstract ByteBuf unwrap(); // 获得被包装( wrap )的 ByteBuf 对象。
+
+public abstract boolean isDirect(); // 是否 NIO Direct Buffer
+
+public abstract boolean isReadOnly(); // 是否为只读 Buffer
+public abstract ByteBuf asReadOnly();
+
+public abstract int readerIndex(); // 读取位置
+public abstract ByteBuf readerIndex(int readerIndex);
+public abstract int writerIndex(); // 写入位置
+public abstract ByteBuf writerIndex(int writerIndex);
+public abstract ByteBuf setIndex(int readerIndex, int writerIndex); // 设置读取和写入位置
+public abstract int readableBytes(); // 剩余可读字节数
+public abstract int writableBytes(); // 剩余可写字节数
+public abstract int maxWritableBytes();
+public abstract boolean isReadable();
+public abstract boolean isReadable(int size);
+public abstract boolean isWritable();
+public abstract boolean isWritable(int size);
+public abstract ByteBuf ensureWritable(int minWritableBytes);
+public abstract int ensureWritable(int minWritableBytes, boolean force);
+public abstract ByteBuf markReaderIndex(); // 标记读取位置
+public abstract ByteBuf resetReaderIndex();
+public abstract ByteBuf markWriterIndex(); // 标记写入位置
+public abstract ByteBuf resetWriterIndex();
+```
+
+主要是如下四个属性：
+
+- `readerIndex` ，读索引。
+- `writerIndex` ，写索引。
+- `capacity` ，当前容量。
+- `maxCapacity` ，最大容量。当 `writerIndex` 写入超过 `capacity` 时，可自动扩容。**每次**扩容的大小，为 `capacity` 的 2 倍。当然，前提是不能超过 `maxCapacity` 大小。
+
+所以，ByteBuf 通过 `readerIndex` 和 `writerIndex` 两个索引，解决 ByteBuffer 的读写模式的问题。
+
+四个大小关系很简单：`readerIndex` <= `writerIndex` <= `capacity` <= `maxCapacity` 。如下图所示：[![分段](35-Netty 源码解析-Buffer 之 ByteBuf（一）简介.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_08_01/01.png)分段
+
+- 图中一共有三段，实际是四段，省略了 `capacity` 到 `maxCapacity` 之间的一段。
+- discardable bytes ，废弃段。一般情况下，可以理解成已读的部分。
+- readable bytes ，可读段。可通过 `#readXXX()` 方法，顺序向下读取。
+- writable bytes ，可写段。可通过 `#writeXXX()` 方法，顺序向下写入。
+
+另外，ByteBuf 还有 `markReaderIndex` 和 `markWriterIndex` 两个属性：
+
+- 通过对应的 `#markReaderIndex()` 和 `#markWriterIndex()` 方法，分别标记读取和写入位置。
+- 通过对应的 `#resetReaderIndex()` 和 `#resetWriterIndex()` 方法，分别读取和写入位置到标记处。
+
+### 3.1.2 读取 / 写入操作
+
+```
+// Boolean 1 字节
+public abstract boolean getBoolean(int index);
+public abstract ByteBuf setBoolean(int index, boolean value);
+public abstract boolean readBoolean();
+public abstract ByteBuf writeBoolean(boolean value);
+
+// Byte 1 字节
+public abstract byte  getByte(int index);
+public abstract short getUnsignedByte(int index);
+public abstract ByteBuf setByte(int index, int value);
+public abstract byte  readByte();
+public abstract short readUnsignedByte();
+public abstract ByteBuf writeByte(int value);
+
+// Short 2 字节
+public abstract short getShort(int index);
+public abstract short getShortLE(int index);
+public abstract int getUnsignedShort(int index);
+public abstract int getUnsignedShortLE(int index);
+public abstract ByteBuf setShort(int index, int value);
+public abstract ByteBuf setShortLE(int index, int value);
+public abstract short readShort();
+public abstract short readShortLE();
+public abstract int   readUnsignedShort();
+public abstract int   readUnsignedShortLE();
+public abstract ByteBuf writeShort(int value);
+public abstract ByteBuf writeShortLE(int value);
+
+// 【特殊】Medium 3 字节
+public abstract int   getMedium(int index);
+public abstract int getMediumLE(int index);
+public abstract int   getUnsignedMedium(int index);
+public abstract int   getUnsignedMediumLE(int index);
+public abstract ByteBuf setMedium(int index, int value);
+public abstract ByteBuf setMediumLE(int index, int value);
+public abstract int   readMedium();
+public abstract int   readMediumLE();
+public abstract int   readUnsignedMedium();
+public abstract int   readUnsignedMediumLE();
+public abstract ByteBuf writeMedium(int value);
+public abstract ByteBuf writeMediumLE(int value);
+
+// Int 4 字节
+public abstract int   getInt(int index);
+public abstract int   getIntLE(int index);
+public abstract long  getUnsignedInt(int index);
+public abstract long  getUnsignedIntLE(int index);
+public abstract ByteBuf setInt(int index, int value);
+public abstract ByteBuf setIntLE(int index, int value);
+public abstract int   readInt();
+public abstract int   readIntLE();
+public abstract long  readUnsignedInt();
+public abstract long  readUnsignedIntLE();
+public abstract ByteBuf writeInt(int value);
+public abstract ByteBuf writeIntLE(int value);
+
+// Long 8 字节
+public abstract long  getLong(int index);
+public abstract long  getLongLE(int index);
+public abstract ByteBuf setLong(int index, long value);
+public abstract ByteBuf setLongLE(int index, long value);
+public abstract long  readLong();
+public abstract long  readLongLE();
+public abstract ByteBuf writeLong(long value);
+public abstract ByteBuf writeLongLE(long value);
+
+// Char 2 字节
+public abstract char  getChar(int index);
+public abstract ByteBuf setChar(int index, int value);
+public abstract char  readChar();
+public abstract ByteBuf writeChar(int value);
+
+// Float 4 字节
+public abstract float getFloat(int index);
+public float getFloatLE(int index) {
+    return Float.intBitsToFloat(getIntLE(index));
+}
+public abstract ByteBuf setFloat(int index, float value);
+public ByteBuf setFloatLE(int index, float value) {
+    return setIntLE(index, Float.floatToRawIntBits(value));
+}
+public abstract float readFloat();
+public float readFloatLE() {
+    return Float.intBitsToFloat(readIntLE());
+}
+public abstract ByteBuf writeFloat(float value);
+public ByteBuf writeFloatLE(float value) {
+    return writeIntLE(Float.floatToRawIntBits(value));
+}
+
+// Double 8 字节
+public abstract double getDouble(int index);
+public double getDoubleLE(int index) {
+    return Double.longBitsToDouble(getLongLE(index));
+}
+public abstract ByteBuf setDouble(int index, double value);
+public ByteBuf setDoubleLE(int index, double value) {
+    return setLongLE(index, Double.doubleToRawLongBits(value));
+}
+public abstract double readDouble();
+public double readDoubleLE() {
+    return Double.longBitsToDouble(readLongLE());
+}
+public abstract ByteBuf writeDouble(double value);
+public ByteBuf writeDoubleLE(double value) {
+    return writeLongLE(Double.doubleToRawLongBits(value));
+}
+
+// Byte 数组
+public abstract ByteBuf getBytes(int index, ByteBuf dst);
+public abstract ByteBuf getBytes(int index, ByteBuf dst, int length);
+public abstract ByteBuf getBytes(int index, ByteBuf dst, int dstIndex, int length);
+public abstract ByteBuf getBytes(int index, byte[] dst);
+public abstract ByteBuf getBytes(int index, byte[] dst, int dstIndex, int length);
+public abstract ByteBuf getBytes(int index, ByteBuffer dst);
+public abstract ByteBuf getBytes(int index, OutputStream out, int length) throws IOException;
+public abstract int getBytes(int index, GatheringByteChannel out, int length) throws IOException;
+public abstract int getBytes(int index, FileChannel out, long position, int length) throws IOException;
+public abstract ByteBuf setBytes(int index, ByteBuf src);
+public abstract ByteBuf setBytes(int index, ByteBuf src, int length);
+public abstract ByteBuf setBytes(int index, ByteBuf src, int srcIndex, int length);
+public abstract ByteBuf setBytes(int index, byte[] src);
+public abstract ByteBuf setBytes(int index, byte[] src, int srcIndex, int length);
+public abstract ByteBuf setBytes(int index, ByteBuffer src);
+public abstract int setBytes(int index, InputStream in, int length) throws IOException;
+public abstract int setBytes(int index, ScatteringByteChannel in, int length) throws IOException;
+public abstract int setBytes(int index, FileChannel in, long position, int length) throws IOException;
+public abstract ByteBuf setZero(int index, int length);
+public abstract ByteBuf readBytes(int length);
+public abstract ByteBuf readSlice(int length);
+public abstract ByteBuf readRetainedSlice(int length);
+public abstract ByteBuf readBytes(ByteBuf dst);
+public abstract ByteBuf readBytes(ByteBuf dst, int length);
+public abstract ByteBuf readBytes(ByteBuf dst, int dstIndex, int length);
+public abstract ByteBuf readBytes(byte[] dst);
+public abstract ByteBuf readBytes(byte[] dst, int dstIndex, int length);
+public abstract ByteBuf readBytes(ByteBuffer dst);
+public abstract ByteBuf readBytes(OutputStream out, int length) throws IOException;
+public abstract int readBytes(GatheringByteChannel out, int length) throws IOException;
+public abstract int readBytes(FileChannel out, long position, int length) throws IOException;
+public abstract ByteBuf skipBytes(int length); // 忽略指定长度的字节数
+public abstract ByteBuf writeBytes(ByteBuf src);
+public abstract ByteBuf writeBytes(ByteBuf src, int length);
+public abstract ByteBuf writeBytes(ByteBuf src, int srcIndex, int length);
+public abstract ByteBuf writeBytes(byte[] src);
+public abstract ByteBuf writeBytes(byte[] src, int srcIndex, int length);
+public abstract ByteBuf writeBytes(ByteBuffer src);
+public abstract int  writeBytes(InputStream in, int length) throws IOException;
+public abstract int writeBytes(ScatteringByteChannel in, int length) throws IOException;
+public abstract int writeBytes(FileChannel in, long position, int length) throws IOException;
+public abstract ByteBuf writeZero(int length); // 填充指定长度的 0
+
+// String
+public abstract CharSequence getCharSequence(int index, int length, Charset charset);
+public abstract int setCharSequence(int index, CharSequence sequence, Charset charset);
+public abstract CharSequence readCharSequence(int length, Charset charset);
+public abstract int writeCharSequence(CharSequence sequence, Charset charset);
+```
+
+虽然方法比较多，总结下来是不同数据类型的**四种**读写方法：
+
+- `#getXXX(index)` 方法，读取**指定**位置的数据，不改变 `readerIndex` 索引。
+- `#readXXX()` 方法，读取 `readerIndex` 位置的数据，会改成 `readerIndex` 索引。
+- `#setXXX(index, value)` 方法，写入数据到**指定**位置，不改变 `writeIndex` 索引。
+- `#writeXXX(value)` 方法，写入数据到**指定**位置，会改变 `writeIndex` 索引。
+
+### 2.1.3 查找 / 遍历操作
+
+```
+public abstract int indexOf(int fromIndex, int toIndex, byte value); // 指定值( value ) 在 ByteBuf 中的位置
+public abstract int bytesBefore(byte value);
+public abstract int bytesBefore(int length, byte value);
+public abstract int bytesBefore(int index, int length, byte value);
+
+public abstract int forEachByte(ByteProcessor processor); // 遍历 ByteBuf ，进行自定义处理
+public abstract int forEachByte(int index, int length, ByteProcessor processor);
+public abstract int forEachByteDesc(ByteProcessor processor);
+public abstract int forEachByteDesc(int index, int length, ByteProcessor processor);
+```
+
+### 3.1.4 释放操作
+
+```
+public abstract ByteBuf discardReadBytes(); // 释放已读的字节空间
+public abstract ByteBuf discardSomeReadBytes(); // 释放部分已读的字节空间
+
+public abstract ByteBuf clear(); // 清空字节空间。实际是修改 readerIndex=writerIndex=0，标记清空。
+```
+
+**discardReadBytes**
+
+`#discardReadBytes()` 方法，释放【所有的】**废弃段**的空间内存。
+
+- 优点：达到重用废弃段的空间内存。
+- 缺点：释放的方式，是通过复制**可读段**到 ByteBuf 的头部。所以，频繁释放会导致性能下降。
+- 总结：这是典型的问题：选择空间还是时间。具体的选择，需要看对应的场景。😈 后续的文章，我们会看到对该方法的调用。
+
+整个过程如下图：[![discardReadBytes](35-Netty 源码解析-Buffer 之 ByteBuf（一）简介.assets/02.png)](http://static.iocoder.cn/images/Netty/2018_08_01/02.png)discardReadBytes
+
+**discardSomeReadBytes**
+
+`#discardSomeReadBytes()` 方法，释放【部分的】**废弃段**的空间内存。
+
+这是对 `#discardSomeReadBytes()` 方法的这种方案，具体的实现，见 [「4. AbstractByteBuf」](https://svip.iocoder.cn/Netty/ByteBuf-1-1-ByteBuf-intro/#) 中。
+
+**clear**
+
+`#clear()` 方法，清空字节空间。实际是修改 `readerIndex = writerIndex = 0` ，标记清空。
+
+- 优点：通过标记来实现清空，避免置空 ByteBuf ，提升性能。
+- 缺点：数据实际还存在，如果错误修改 `writerIndex` 时，会导致读到“脏”数据。
+
+整个过程如下图：[![discardReadBytes](35-Netty 源码解析-Buffer 之 ByteBuf（一）简介.assets/03.png)](http://static.iocoder.cn/images/Netty/2018_08_01/03.png)discardReadBytes
+
+### 3.1.5 拷贝操作
+
+```
+public abstract ByteBuf copy(); // 拷贝可读部分的字节数组。独立，互相不影响。
+public abstract ByteBuf copy(int index, int length);
+
+public abstract ByteBuf slice(); // 拷贝可读部分的字节数组。共享，相互影响。
+public abstract ByteBuf slice(int index, int length);
+public abstract ByteBuf retainedSlice();
+
+public abstract ByteBuf duplicate(); // 拷贝整个的字节数组。共享，相互影响。
+public abstract ByteBuf retainedDuplicate();
+```
+
+### 3.1.6 转换 NIO ByteBuffer 操作
+
+```
+// ByteBuf 包含 ByteBuffer 数量。
+// 如果返回 = 1 ，则调用 `#nioBuffer()` 方法，获得 ByteBuf 包含的 ByteBuffer 对象。
+// 如果返回 > 1 ，则调用 `#nioBuffers()` 方法，获得 ByteBuf 包含的 ByteBuffer 数组。
+public abstract int nioBufferCount();
+
+public abstract ByteBuffer nioBuffer();
+public abstract ByteBuffer nioBuffer(int index, int length);
+public abstract ByteBuffer internalNioBuffer(int index, int length);
+
+public abstract ByteBuffer[] nioBuffers();
+public abstract ByteBuffer[] nioBuffers(int index, int length);
+```
+
+### 3.1.7 Heap 相关方法
+
+```
+// 适用于 Heap 类型的 ByteBuf 对象的 byte[] 字节数组
+public abstract boolean hasArray(); // 是否有 byte[] 字节数组
+public abstract byte[] array();
+public abstract int arrayOffset();
+```
+
+- 详细解析，见 [《精尽 Netty 源码解析 —— Buffer 之 ByteBuf（二）核心子类》](http://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl)
+
+### 3.1.8 Unsafe 相关方法
+
+```
+// 适用于 Unsafe 类型的 ByteBuf 对象
+public abstract boolean hasMemoryAddress(); // 是否有内存地址
+public abstract long memoryAddress();
+```
+
+- 详细解析，见 [《精尽 Netty 源码解析 —— Buffer 之 ByteBuf（二）核心子类》](http://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl)
+
+### 3.1.9 Object 相关
+
+```
+@Override
+public abstract String toString();
+public abstract String toString(Charset charset);
+public abstract String toString(int index, int length, Charset charset);
+
+@Override
+public abstract int hashCode();
+
+@Override
+public abstract boolean equals(Object obj);
+
+@Override
+public abstract int compareTo(ByteBuf buffer);
+```
+
+### 3.1.10 引用计数相关
+
+本文暂时不解析，我们会在 TODO 1011 。
+
+来自 ReferenceCounted
+
+https://skyao.gitbooks.io/learning-netty/content/buffer/interface_ReferenceCounted.html 可参考
+
+```
+@Override
+public abstract ByteBuf retain(int increment);
+@Override
+public abstract ByteBuf retain();
+
+@Override
+public abstract ByteBuf touch();
+@Override
+public abstract ByteBuf touch(Object hint);
+```
+
+## 3.2 子类类图
+
+ByteBuf 的子类灰常灰常灰常多，胖友点击 [传送门](http://static.iocoder.cn/images/Netty/2018_08_01/04.png) 可以进行查看。
+
+本文仅分享 ByteBuf 的**五个**直接子类实现，如下图所示：[![传送门](35-Netty 源码解析-Buffer 之 ByteBuf（一）简介.assets/05.png)](http://static.iocoder.cn/images/Netty/2018_08_01/05.png)传送门
+
+- 【重点】AbstractByteBuf ，ByteBuf 抽象实现类，提供 ByteBuf 的默认实现类。可以说，是 ByteBuf 最最最重要的子类。详细解析，见 [「4. AbstractByteBuf」](https://svip.iocoder.cn/Netty/ByteBuf-1-1-ByteBuf-intro/#) 。
+- EmptyByteBuf ，用于构建空 ByteBuf 对象，`capacity` 和 `maxCapacity` 均为 0 。详细解析，见 [「5. EmptyByteBuf」](https://svip.iocoder.cn/Netty/ByteBuf-1-1-ByteBuf-intro/#) 。
+- WrappedByteBuf ，用于装饰 ByteBuf 对象。详细解析，见 [「6. WrappedByteBuf」](https://svip.iocoder.cn/Netty/ByteBuf-1-1-ByteBuf-intro/#) 。
+- SwappedByteBuf ，用于构建具有切换**字节序**功能的 ByteBuf 对象。详细解析，见 [「7. SwappedByteBuf」](https://svip.iocoder.cn/Netty/ByteBuf-1-1-ByteBuf-intro/#) 。
+- ReplayingDecoderByteBuf ，用于构建在 IO 阻塞条件下实现无阻塞解码的特殊 ByteBuf 对象，当要读取的数据还未接收完全时，抛出异常，交由 ReplayingDecoder处理。详细解析，见 [「8. ReplayingDecoderByteBuf」](https://svip.iocoder.cn/Netty/ByteBuf-1-1-ByteBuf-intro/#) 。
+
+# 4. AbstractByteBuf
+
+`io.netty.buffer.AbstractByteBuf` ，实现 ByteBuf 抽象类，ByteBuf 抽象实现类。官方注释如下：
+
+```
+/**
+ * A skeletal implementation of a buffer.
+ */
+```
+
+因为 AbstractByteBuf 实现类 ByteBuf 超级多的方法，所以我们还是按照 ByteBuf 的归类，逐个分析过去。
+
+## 4.1 基础信息
+
+### 4.1.1 构造方法
+
+```
+/**
+ * 读取位置
+ */
+int readerIndex;
+/**
+ * 写入位置
+ */
+int writerIndex;
+/**
+ * {@link #readerIndex} 的标记
+ */
+private int markedReaderIndex;
+/**
+ * {@link #writerIndex} 的标记
+ */
+private int markedWriterIndex;
+/**
+ * 最大容量
+ */
+private int maxCapacity;
+
+protected AbstractByteBuf(int maxCapacity) {
+    if (maxCapacity < 0) {
+        throw new IllegalArgumentException("maxCapacity: " + maxCapacity + " (expected: >= 0)");
+    }
+    this.maxCapacity = maxCapacity;
+}
+```
+
+- `capacity` 属性，在 AbstractByteBuf 未定义，而是由子类来实现。为什么呢？在后面的文章，我们会看到，ByteBuf 根据**内存类型**分成 Heap 和 Direct ，它们获取 `capacity` 的值的方式不同。
+
+- `maxCapacity` 属性，相关的方法：
+
+  ```
+  @Override
+  public int maxCapacity() {
+      return maxCapacity;
+  }
+  
+  protected final void maxCapacity(int maxCapacity) {
+      this.maxCapacity = maxCapacity;
+  }
+  ```
+
+### 4.1.2 读索引相关的方法
+
+**获取和设置读位置**
+
+```
+@Override
+public int readerIndex() {
+    return readerIndex;
+}
+    
+@Override
+public ByteBuf readerIndex(int readerIndex) {
+    if (readerIndex < 0 || readerIndex > writerIndex) {
+        throw new IndexOutOfBoundsException(String.format(
+                "readerIndex: %d (expected: 0 <= readerIndex <= writerIndex(%d))", readerIndex, writerIndex));
+    }
+    this.readerIndex = readerIndex;
+    return this;
+}
+```
+
+------
+
+**是否可读**
+
+```
+@Override
+public boolean isReadable() {
+    return writerIndex > readerIndex;
+}
+@Override
+public boolean isReadable(int numBytes) {
+    return writerIndex - readerIndex >= numBytes;
+}
+
+@Override
+public int readableBytes() {
+    return writerIndex - readerIndex;
+}
+```
+
+------
+
+**标记和重置读位置**
+
+```
+@Override
+public ByteBuf markReaderIndex() {
+    markedReaderIndex = readerIndex;
+    return this;
+}
+
+@Override
+public ByteBuf resetReaderIndex() {
+    readerIndex(markedReaderIndex);
+    return this;
+}
+```
+
+### 4.1.3 写索引相关的方法
+
+**获取和设置写位置**
+
+```
+@Override
+public int writerIndex() {
+    return writerIndex;
+}
+    
+@Override
+public ByteBuf writerIndex(int writerIndex) {
+    if (writerIndex < readerIndex || writerIndex > capacity()) {
+        throw new IndexOutOfBoundsException(String.format(
+                "writerIndex: %d (expected: readerIndex(%d) <= writerIndex <= capacity(%d))",
+                writerIndex, readerIndex, capacity()));
+    }
+    this.writerIndex = writerIndex;
+    return this;
+}
+```
+
+------
+
+**是否可写**
+
+```
+@Override
+public boolean isWritable() {
+    return capacity() > writerIndex;
+}
+@Override
+public boolean isWritable(int numBytes) {
+    return capacity() - writerIndex >= numBytes;
+}
+
+@Override
+public int writableBytes() {
+    return capacity() - writerIndex;
+}
+@Override
+public int maxWritableBytes() {
+    return maxCapacity() - writerIndex;
+}
+```
+
+------
+
+**标记和重置写位置**
+
+```
+@Override
+public ByteBuf markWriterIndex() {
+    markedWriterIndex = writerIndex;
+    return this;
+}
+
+@Override
+public ByteBuf resetWriterIndex() {
+    writerIndex(markedWriterIndex);
+    return this;
+}
+```
+
+------
+
+**保证可写**
+
+`#ensureWritable(int minWritableBytes)` 方法，保证有足够的可写空间。若不够，则进行扩容。代码如下：
+
+```
+ 1: @Override
+ 2: public ByteBuf ensureWritable(int minWritableBytes) {
+ 3:     if (minWritableBytes < 0) {
+ 4:         throw new IllegalArgumentException(String.format(
+ 5:                 "minWritableBytes: %d (expected: >= 0)", minWritableBytes));
+ 6:     }
+ 7:     ensureWritable0(minWritableBytes);
+ 8:     return this;
+ 9: }
+10: 
+11: final void ensureWritable0(int minWritableBytes) {
+12:     // 检查是否可访问
+13:     ensureAccessible();
+14:     // 目前容量可写，直接返回
+15:     if (minWritableBytes <= writableBytes()) {
+16:         return;
+17:     }
+18: 
+19:     // 超过最大上限，抛出 IndexOutOfBoundsException 异常
+20:     if (minWritableBytes > maxCapacity - writerIndex) {
+21:         throw new IndexOutOfBoundsException(String.format(
+22:                 "writerIndex(%d) + minWritableBytes(%d) exceeds maxCapacity(%d): %s",
+23:                 writerIndex, minWritableBytes, maxCapacity, this));
+24:     }
+25: 
+26:     // 计算新的容量。默认情况下，2 倍扩容，并且不超过最大容量上限。
+27:     // Normalize the current capacity to the power of 2.
+28:     int newCapacity = alloc().calculateNewCapacity(writerIndex + minWritableBytes, maxCapacity);
+29: 
+30:     // 设置新的容量大小
+31:     // Adjust to the new capacity.
+32:     capacity(newCapacity);
+33: }
+```
+
+- 第 13 行：调用 `#ensureAccessible()` 方法，检查是否可访问。代码如下：
+
+  ```
+  /**
+   * Should be called by every method that tries to access the buffers content to check
+   * if the buffer was released before.
+   */
+  protected final void ensureAccessible() {
+      if (checkAccessible && refCnt() == 0) { // 若指向为 0 ，说明已经释放，不可继续写入。
+          throw new IllegalReferenceCountException(0);
+      }
+  }
+  
+  private static final String PROP_MODE = "io.netty.buffer.bytebuf.checkAccessible";
+  /**
+   * 是否检查可访问
+   *
+   * @see #ensureAccessible() 
+   */
+  private static final boolean checkAccessible;
+  
+  static {
+      checkAccessible = SystemPropertyUtil.getBoolean(PROP_MODE, true);
+      if (logger.isDebugEnabled()) {
+          logger.debug("-D{}: {}", PROP_MODE, checkAccessible);
+      }
+  }
+  ```
+
+- 第 14 至 17 行：目前容量可写，直接返回。
+
+- 第 19 至 24 行：超过最大上限，抛出 IndexOutOfBoundsException 异常。
+
+- 第 28 行：调用
+
+   
+
+  ```
+  ByteBufAllocator#calculateNewCapacity(int minNewCapacity, int maxCapacity)
+  ```
+
+   
+
+  方法，计算新的容量。默认情况下，2 倍扩容，并且不超过最大容量上限。
+
+  注意
+
+  ，此处仅仅是计算，并没有扩容内存复制等等操作。
+
+  - 第 32 行：调用 `#capacity(newCapacity)` 方法，设置新的容量大小。
+
+`#ensureWritable(int minWritableBytes, boolean force)` 方法，保证有足够的可写空间。若不够，则进行扩容。代码如下：
+
+```
+@Override
+public int ensureWritable(int minWritableBytes, boolean force) {
+    // 检查是否可访问
+    ensureAccessible();
+    if (minWritableBytes < 0) {
+        throw new IllegalArgumentException(String.format(
+                "minWritableBytes: %d (expected: >= 0)", minWritableBytes));
+    }
+
+    // 目前容量可写，直接返回 0
+    if (minWritableBytes <= writableBytes()) {
+        return 0;
+    }
+
+    final int maxCapacity = maxCapacity();
+    final int writerIndex = writerIndex();
+    // 超过最大上限
+    if (minWritableBytes > maxCapacity - writerIndex) {
+        // 不强制设置，或者已经到达最大容量
+        if (!force || capacity() == maxCapacity) {
+            // 返回 1
+            return 1;
+        }
+
+        // 设置为最大容量
+        capacity(maxCapacity);
+        // 返回 3
+        return 3;
+    }
+
+    // 计算新的容量。默认情况下，2 倍扩容，并且不超过最大容量上限。
+    // Normalize the current capacity to the power of 2.
+    int newCapacity = alloc().calculateNewCapacity(writerIndex + minWritableBytes, maxCapacity);
+
+    // 设置新的容量大小
+    // Adjust to the new capacity.
+    capacity(newCapacity);
+
+    // 返回 2
+    return 2;
+}
+```
+
+和 `#ensureWritable(int minWritableBytes)` 方法，有两点不同：
+
+- 超过最大容量的上限时，不会抛出 IndexOutOfBoundsException 异常。
+- 根据执行的过程不同，返回不同的返回值。
+
+比较简单，胖友自己看下代码。
+
+### 4.1.4 setIndex
+
+```
+@Override
+public ByteBuf setIndex(int readerIndex, int writerIndex) {
+    if (readerIndex < 0 || readerIndex > writerIndex || writerIndex > capacity()) {
+        throw new IndexOutOfBoundsException(String.format(
+                "readerIndex: %d, writerIndex: %d (expected: 0 <= readerIndex <= writerIndex <= capacity(%d))",
+                readerIndex, writerIndex, capacity()));
+    }
+    setIndex0(readerIndex, writerIndex);
+    return this;
+}
+
+final void setIndex0(int readerIndex, int writerIndex) {
+    this.readerIndex = readerIndex;
+    this.writerIndex = writerIndex;
+}
+```
+
+### 4.1.5 读索引标记位相关的方法
+
+```
+@Override
+public ByteBuf markReaderIndex() {
+    markedReaderIndex = readerIndex;
+    return this;
+}
+
+@Override
+public ByteBuf resetReaderIndex() {
+    readerIndex(markedReaderIndex);
+    return this;
+}
+```
+
+### 4.1.6 写索引标记位相关的方法
+
+```
+@Override
+public ByteBuf markWriterIndex() {
+    markedWriterIndex = writerIndex;
+    return this;
+}
+
+@Override
+public ByteBuf resetWriterIndex() {
+    writerIndex(markedWriterIndex);
+    return this;
+}
+```
+
+### 4.1.7 是否只读相关
+
+`#isReadOnly()` 方法，返回是否只读。代码如下：
+
+```
+@Override
+public boolean isReadOnly() {
+    return false;
+}
+```
+
+- 默认返回 `false` 。子类可覆写该方法，根据情况返回结果。
+
+------
+
+`#asReadOnly()` 方法，转换成只读 ByteBuf 对象。代码如下：
+
+```
+@SuppressWarnings("deprecation")
+@Override
+public ByteBuf asReadOnly() {
+    // 如果是只读，直接返回
+    if (isReadOnly()) {
+        return this;
+    }
+    // 转化成只读 Buffer 对象
+    return Unpooled.unmodifiableBuffer(this);
+}
+```
+
+- 如果已是只读，直接返回该 ByteBuf 对象。
+
+- 如果不是只读，调用 `Unpooled#unmodifiableBuffer(Bytebuf)` 方法，转化成只读 Buffer 对象。代码如下：
+
+  ```
+  /**
+   * Creates a read-only buffer which disallows any modification operations
+   * on the specified {@code buffer}.  The new buffer has the same
+   * {@code readerIndex} and {@code writerIndex} with the specified
+   * {@code buffer}.
+   *
+   * @deprecated Use {@link ByteBuf#asReadOnly()}.
+   */
+  @Deprecated
+  public static ByteBuf unmodifiableBuffer(ByteBuf buffer) {
+      ByteOrder endianness = buffer.order();
+      // 大端
+      if (endianness == BIG_ENDIAN) {
+          return new ReadOnlyByteBuf(buffer);
+      }
+      // 小端
+      return new ReadOnlyByteBuf(buffer.order(BIG_ENDIAN)).order(LITTLE_ENDIAN);
+  }
+  ```
+
+  - 注意，返回的是**新的** `io.netty.buffer.ReadOnlyByteBuf` 对象。并且，和原 ByteBuf 对象，共享 `readerIndex` 和 `writerIndex` 索引，以及相关的数据。仅仅是说，只读，不能写入。
+
+### 4.1.8 ByteOrder 相关的方法
+
+`#order()` 方法，获得字节序。由子类实现，因为 AbstractByteBuf 的内存类型，不确定是 Heap 还是 Direct 。
+
+------
+
+`#order(ByteOrder endianness)` 方法，设置字节序。代码如下：
+
+```
+@Override
+public ByteBuf order(ByteOrder endianness) {
+    if (endianness == null) {
+        throw new NullPointerException("endianness");
+    }
+    // 未改变，直接返回
+    if (endianness == order()) {
+        return this;
+    }
+    // 创建 SwappedByteBuf 对象
+    return newSwappedByteBuf();
+}
+
+/**
+ * Creates a new {@link SwappedByteBuf} for this {@link ByteBuf} instance.
+ */
+protected SwappedByteBuf newSwappedByteBuf() {
+    return new SwappedByteBuf(this);
+}
+```
+
+- 如果字节序未修改，直接返回该 ByteBuf 对象。
+- 如果字节序有修改，调用 `#newSwappedByteBuf()` 方法，TODO SwappedByteBuf
+
+### 4.1.9 未实现方法
+
+和 [「2.1.1 基础信息」](https://svip.iocoder.cn/Netty/ByteBuf-1-1-ByteBuf-intro/#) 相关的方法，有三个未实现，如下：
+
+```
+public abstract ByteBufAllocator alloc(); // 分配器，用于创建 ByteBuf 对象。
+
+public abstract ByteBuf unwrap(); // 获得被包装( wrap )的 ByteBuf 对象。
+
+public abstract boolean isDirect(); // 是否 NIO Direct Buffer
+```
+
+## 4.2 读取 / 写入操作
+
+我们以 Int 类型为例子，来看看它的读取和写入操作的实现代码。
+
+### 4.2.1 getInt
+
+```
+@Override
+public int getInt(int index) {
+    // 校验读取是否会超过容量
+    checkIndex(index, 4);
+    // 读取 Int 数据
+    return _getInt(index);
+}
+```
+
+- 调用 `#checkIndex(index, fieldLength)` 方法，校验读取是否会超过**容量**。注意，不是超过 `writerIndex` 位置。因为，只是读取指定位置开始的 Int 数据，不会改变 `readerIndex` 。代码如下：
+
+  ```
+  protected final void checkIndex(int index, int fieldLength) {
+      // 校验是否可访问
+      ensureAccessible();
+      // 校验是否会超过容量
+      checkIndex0(index, fieldLength);
+  }
+  final void checkIndex0(int index, int fieldLength) {
+      if (isOutOfBounds(index, fieldLength, capacity())) {
+          throw new IndexOutOfBoundsException(String.format(
+                  "index: %d, length: %d (expected: range(0, %d))", index, fieldLength, capacity()));
+      }
+  }
+  
+  // MathUtil.java
+  /**
+   * Determine if the requested {@code index} and {@code length} will fit within {@code capacity}.
+   * @param index The starting index.
+   * @param length The length which will be utilized (starting from {@code index}).
+   * @param capacity The capacity that {@code index + length} is allowed to be within.
+   * @return {@code true} if the requested {@code index} and {@code length} will fit within {@code capacity}.
+   * {@code false} if this would result in an index out of bounds exception.
+   */
+  public static boolean isOutOfBounds(int index, int length, int capacity) {
+      // 只有有负数，或运算，就会有负数。
+      // 另外，此处的越界，不仅仅有 capacity - (index + length < 0 ，例如 index < 0 ，也是越界
+      return (index | length | (index + length) | (capacity - (index + length))) < 0;
+  }
+  ```
+
+- 调用 `#_getInt(index)` 方法，读取 Int 数据。这是一个**抽象**方法，由子类实现。代码如下：
+
+  ```
+  protected abstract int _getInt(int index);
+  ```
+
+关于 `#getIntLE(int index)` / `getUnsignedInt(int index)` / `getUnsignedIntLE(int index)` 方法的实现，胖友自己去看。
+
+### 4.2.2 readInt
+
+```
+@Override
+public int readInt() {
+    // 校验读取是否会超过可读段
+    checkReadableBytes0(4);
+    // 读取 Int 数据
+    int v = _getInt(readerIndex);
+    // 修改 readerIndex ，加上已读取字节数
+    readerIndex += 4;
+    return v;
+}
+```
+
+- 调用 `#checkReadableBytes0(fieldLength)` 方法，校验读取是否会超过**可读段**。代码如下：
+
+  ```
+  private void checkReadableBytes0(int minimumReadableBytes) {
+      // 是否可访问
+      ensureAccessible();
+      // 是否超过写索引，即超过可读段
+      if (readerIndex > writerIndex - minimumReadableBytes) {
+          throw new IndexOutOfBoundsException(String.format(
+                  "readerIndex(%d) + length(%d) exceeds writerIndex(%d): %s",
+                  readerIndex, minimumReadableBytes, writerIndex, this));
+      }
+  }
+  ```
+
+- 调用 `#_getInt(index)` 方法，读取 Int 数据。
+
+- 读取完成，修改 `readerIndex` 【**重要** 😈】，加上已读取字节数 4 。
+
+关于 `#readIntLE()` / `readUnsignedInt()` / `readUnsignedIntLE()` 方法的实现，胖友自己去看。
+
+### 4.2.3 setInt
+
+```
+@Override
+public ByteBuf setInt(int index, int value) {
+    // 校验写入是否会超过容量
+    checkIndex(index, 4);
+    // 设置 Int 数据
+    _setInt(index, value);
+    return this;
+}
+```
+
+- 调用 `#checkIndex(index, fieldLength)` 方法，校验写入是否会超过**容量**。
+
+- 调用 `#_setInt(index,value )` 方法，写入 Int 数据。这是一个**抽象**方法，由子类实现。代码如下：
+
+  ```
+  protected abstract int _setInt(int index, int value);
+  ```
+
+关于 `#setIntLE(int index, int value)` 方法的实现，胖友自己去看。
+
+public abstract ByteBuf writeInt(int value);
+public abstract ByteBuf writeIntLE(int value);
+
+### 4.2.4 writeInt
+
+```
+@Override
+public ByteBuf writeInt(int value) {
+    // 保证可写入
+    ensureWritable0(4);
+    // 写入 Int 数据
+    _setInt(writerIndex, value);
+    // 修改 writerIndex ，加上已写入字节数
+    writerIndex += 4;
+    return this;
+}
+```
+
+- 调用 `#ensureWritable0(int minWritableBytes)` 方法，保证可写入。
+- 调用 `#_setInt(index, int value)` 方法，写入Int 数据。
+- 写入完成，修改 `writerIndex` 【**重要** 😈】，加上已写入字节数 4 。
+
+### 4.2.5 其它方法
+
+其它类型的读取和写入操作的实现代码，胖友自己研究落。还是有一些有意思的方法，例如：
+
+- `#writeZero(int length)` 方法。原本以为是循环 `length` 次写入 0 字节，结果发现会基于 `long` => `int` => `byte` 的顺序，尽可能合并写入。
+- `#skipBytes((int length)` 方法
+
+## 4.3 查找 / 遍历操作
+
+查找 / 遍历操作相关的方法，实现比较简单。所以，感兴趣的胖友，可以自己去看。
+
+## 4.4 释放操作
+
+### 4.4.1 discardReadBytes
+
+`#discardReadBytes()` 方法，代码如下：
+
+```
+ 1: @Override
+ 2: public ByteBuf discardReadBytes() {
+ 3:     // 校验可访问
+ 4:     ensureAccessible();
+ 5:     // 无废弃段，直接返回
+ 6:     if (readerIndex == 0) {
+ 7:         return this;
+ 8:     }
+ 9: 
+10:     // 未读取完
+11:     if (readerIndex != writerIndex) {
+12:         // 将可读段复制到 ByteBuf 头
+13:         setBytes(0, this, readerIndex, writerIndex - readerIndex);
+14:         // 写索引减小
+15:         writerIndex -= readerIndex;
+16:         // 调整标记位
+17:         adjustMarkers(readerIndex);
+18:         // 读索引重置为 0
+19:         readerIndex = 0;
+20:     // 全部读取完
+21:     } else {
+22:         // 调整标记位
+23:         adjustMarkers(readerIndex);
+24:         // 读写索引都重置为 0
+25:         writerIndex = readerIndex = 0;
+26:     }
+27:     return this;
+28: }
+```
+
+- 第 4 行：调用 `#ensureAccessible()` 方法，检查是否可访问。
+
+- 第 5 至 8 行：无**废弃段**，直接返回。
+
+- 第 10 至 19 行：未读取完，即还有**可读段**。
+
+  - 第 13 行：调用 `#setBytes(int index, ByteBuf src, int srcIndex, int length)` 方法，将可读段复制到 ByteBuf 头开始。如下图所示：[![discardReadBytes](35-Netty 源码解析-Buffer 之 ByteBuf（一）简介.assets/02.png)](http://static.iocoder.cn/images/Netty/2018_08_01/02.png)discardReadBytes
+
+  - 第 15 行：写索引 `writerIndex` 减小。
+
+  - 第 19 行：调用 `#adjustMarkers(int decrement)` 方法，调整标记位。代码如下：
+
+    ```
+    protected final void adjustMarkers(int decrement) {
+        int markedReaderIndex = this.markedReaderIndex;
+        // 读标记位小于减少值(decrement)
+        if (markedReaderIndex <= decrement) {
+            // 重置读标记位为 0
+            this.markedReaderIndex = 0;
+            // 写标记位小于减少值(decrement)
+            int markedWriterIndex = this.markedWriterIndex;
+            if (markedWriterIndex <= decrement) {
+                // 重置写标记位为 0
+                this.markedWriterIndex = 0;
+            // 减小写标记位
+            } else {
+                this.markedWriterIndex = markedWriterIndex - decrement;
+            }
+        // 减小读写标记位
+        } else {
+            this.markedReaderIndex = markedReaderIndex - decrement;
+            this.markedWriterIndex -= decrement;
+        }
+    }
+    ```
+
+    - 代码虽然比较多，但是目的很明确，**减小**读写标记位。并且，通过判断，**最多减小至 0** 。
+
+  - 第 19 行：**仅**读索引重置为 0 。
+
+- 第 20 至 26 行：全部读取完，即无
+
+  可读段
+
+  。
+
+  - 第 23 行：调用 `#adjustMarkers(int decrement)` 方法，调整标记位。
+  - 第 25 行：读写索引**都**重置为 0 。
+
+### 4.4.2 discardSomeReadBytes
+
+`#discardSomeReadBytes()` 方法，代码如下：
+
+```
+@Override
+public ByteBuf discardSomeReadBytes() {
+    // 校验可访问
+    ensureAccessible();
+    // 无废弃段，直接返回
+    if (readerIndex == 0) {
+        return this;
+    }
+
+    // 全部读取完
+    if (readerIndex == writerIndex) {
+        // 调整标记位
+        adjustMarkers(readerIndex);
+        // 读写索引都重置为 0
+        writerIndex = readerIndex = 0;
+        return this;
+    }
+
+    // 读取超过容量的一半，进行释放
+    if (readerIndex >= capacity() >>> 1) {
+        // 将可读段复制到 ByteBuf 头
+        setBytes(0, this, readerIndex, writerIndex - readerIndex);
+        // 写索引减小
+        writerIndex -= readerIndex;
+        // 调整标记位
+        adjustMarkers(readerIndex);
+        // 读索引重置为 0
+        readerIndex = 0;
+    }
+    return this;
+}
+```
+
+整体代码和 `#discardReadBytes()` 方法是**一致的**。差别在于，`readerIndex >= capacity() >>> 1` ，读取超过容量的**一半**时，进行释放。也就是说，在空间和时间之间，做了一个平衡。
+
+😈 后续，我们来看看，Netty 具体在什么时候，调用 `#discardSomeReadBytes()` 和 `#discardReadBytes()` 方法。
+
+### 4.4.3 clear
+
+`#clear()` 方法，代码如下：
+
+```
+@Override
+public ByteBuf clear() {
+    readerIndex = writerIndex = 0;
+    return this;
+}
+```
+
+- 读写索引**都**重置为 0 。
+- 读写标记位**不会**重置。
+
+## 4.5 拷贝操作
+
+### 4.5.1 copy
+
+`#copy()` 方法，拷贝可读部分的字节数组。代码如下：
+
+```
+@Override
+public ByteBuf copy() {
+    return copy(readerIndex, readableBytes());
+}
+```
+
+- 调用 `#readableBytes()` 方法，获得可读的字节数。
+- 调用 `#copy(int index, int length)` 方法，拷贝**指定部分**的字节数组。独立，互相不影响。具体的实现，需要子类中实现，原因是做**深**拷贝，需要根据内存类型是 Heap 和 Direct 会有不同。
+
+### 4.5.2 slice
+
+`#slice()` 方法，拷贝可读部分的字节数组。代码如下：
+
+```
+@Override
+public ByteBuf slice() {
+    return slice(readerIndex, readableBytes());
+}
+```
+
+- 调用 `#readableBytes()` 方法，获得可读的字节数。
+
+- 调用 `#slice(int index, int length)` 方法，拷贝**指定部分**的字节数组。共享，互相影响。代码如下：
+
+  ```
+  @Override
+  public ByteBuf slice(int index, int length) {
+      // 校验可访问
+      ensureAccessible();
+      // 创建 UnpooledSlicedByteBuf 对象
+      return new UnpooledSlicedByteBuf(this, index, length);
+  }
+  ```
+
+  - 返回的是创建的 UnpooledSlicedByteBuf 对象。在它内部，会调用当前 ByteBuf 对象，所以这也是为什么说是**共享**的。或者说，我们可以认为这是一个**浅**拷贝。
+
+------
+
+`#retainedSlice()` 方法，在 `#slice()` 方法的基础上，引用计数加 1 。代码如下：
+
+```
+@Override
+public ByteBuf retainedSlice(int index, int length) {
+    return slice(index, length).retain();
+}
+```
+
+- 调用 `#slice(int index, int length)` 方法，拷贝**指定部分**的字节数组。也就说，返回 UnpooledSlicedByteBuf 对象。
+- 调用 `UnpooledSlicedByteBuf#retain()` 方法，，引用计数加 1 。本文暂时不解析，我们会在 TODO 1011 。
+
+### 4.5.3 duplicate
+
+`#duplicate()` 方法，拷贝**整个**的字节数组。代码如下：
+
+```
+@Override
+public ByteBuf duplicate() {
+    // 校验是否可访问
+    ensureAccessible();
+    return new UnpooledDuplicatedByteBuf(this);
+}
+```
+
+- 创建的 UnpooledDuplicatedByteBuf 对象。在它内部，会调用当前 ByteBuf 对象，所以这也是为什么说是**共享**的。或者说，我们可以认为这是一个**浅**拷贝。
+- 它和 `#slice()` 方法的差别在于，前者是**整个**，后者是**可写段**。
+
+------
+
+`#retainedDuplicate()` 方法，在 `#duplicate()` 方法的基础上，引用计数加 1 。代码如下：
+
+```
+@Override
+public ByteBuf retainedDuplicate() {
+    return duplicate().retain();
+}
+```
+
+- 调用 `#duplicate()` 方法，拷贝**整个**的字节数组。也就说，返回 UnpooledDuplicatedByteBuf 对象。
+- 调用 `UnpooledDuplicatedByteBuf#retain()` 方法，，引用计数加 1 。本文暂时不解析，我们会在 TODO 1011 。
+
+## 4.6 转换 NIO ByteBuffer 操作
+
+### 4.6.1 nioBuffer
+
+`#nioBuffer()` 方法，代码如下：
+
+```
+@Override
+public ByteBuffer nioBuffer() {
+    return nioBuffer(readerIndex, readableBytes());
+}
+```
+
+- 在方法内部，会调用 `#nioBuffer(int index, int length)` 方法。而该方法，由具体的子类实现。
+
+  > FROM [《深入研究Netty框架之ByteBuf功能原理及源码分析》](https://my.oschina.net/7001/blog/742236)
+  >
+  > 将当前 ByteBuf 的可读缓冲区( `readerIndex` 到 `writerIndex` 之间的内容) 转换为 ByteBuffer 对象，两者共享共享缓冲区的内容。对 ByteBuffer 的读写操作不会影响 ByteBuf 的读写索引。
+  >
+  > 注意：ByteBuffer 无法感知 ByteBuf 的动态扩展操作。ByteBuffer 的长度为`readableBytes()` 。
+
+### 4.6.2 nioBuffers
+
+`#nioBuffers()` 方法，代码如下：
+
+```
+@Override
+public ByteBuffer[] nioBuffers() {
+    return nioBuffers(readerIndex, readableBytes());
+}
+```
+
+- 在方法内部，会调用 `#nioBuffers(int index, int length)` 方法。而该方法，由具体的子类实现。
+- 😈 为什么会产生数组的情况呢？例如 CompositeByteBuf 。当然，后续文章，我们也会具体分享。
+
+## 4.7 Heap 相关方法
+
+Heap 相关方法，在子类中实现。详细解析，见 [《精尽 Netty 源码解析 —— Buffer 之 ByteBuf（二）核心子类》](http://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl)
+
+## 4.8 Unsafe 相关方法
+
+Unsafe，在子类中实现。详细解析，见 [《精尽 Netty 源码解析 —— Buffer 之 ByteBuf（二）核心子类》](http://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl)
+
+## 4.9 Object 相关
+
+Object 相关的方法，主要调用 `io.netty.buffer.ByteBufUtil` 进行实现。而 ByteUtil 是一个非常有用的工具类，它提供了一系列静态方法，用于操作 ByteBuf 对象：[![ByteUtil](35-Netty 源码解析-Buffer 之 ByteBuf（一）简介.assets/06.png)](http://static.iocoder.cn/images/Netty/2018_08_01/06.png)ByteUtil
+
+😈 因为 Object 相关的方法，实现比较简单。所以，感兴趣的胖友，可以自己去看。
+
+## 4.10 引用计数相关
+
+本文暂时不解析，我们会在 TODO 1011 。
+
+# 5. EmptyByteBuf
+
+`io.netty.buffer.EmptyByteBuf` ，继承 ByteBuf 抽象类，用于构建空 ByteBuf 对象，`capacity` 和 `maxCapacity` 均为 0 。
+
+😈 代码实现超级简单，感兴趣的胖友，可以自己去看。
+
+# 6. WrappedByteBuf
+
+`io.netty.buffer.WrappedByteBuf` ，继承 ByteBuf 抽象类，用于装饰 ByteBuf 对象。构造方法如下：
+
+```
+/**
+ * 被装饰的 ByteBuf 对象
+ */
+protected final ByteBuf buf;
+
+protected WrappedByteBuf(ByteBuf buf) {
+    if (buf == null) {
+        throw new NullPointerException("buf");
+    }
+    this.buf = buf;
+}
+```
+
+- `buf` 属性，被装饰的 ByteBuf 对象。
+
+- 每个实现方法，是对 `buf` 的对应方法的调用。例如：
+
+  ```
+  @Override
+  public final int capacity() {
+      return buf.capacity();
+  }
+  
+  @Override
+  public ByteBuf capacity(int newCapacity) {
+      buf.capacity(newCapacity);
+      return this;
+  }
+  ```
+
+# 7. SwappedByteBuf
+
+`io.netty.buffer.SwappedByteBuf` ，继承 ByteBuf 抽象类，用于构建具有切换**字节序**功能的 ByteBuf 对象。构造方法如下：
+
+```
+/**
+ * 原 ByteBuf 对象
+ */
+private final ByteBuf buf;
+/**
+ * 字节序
+ */
+private final ByteOrder order;
+
+public SwappedByteBuf(ByteBuf buf) {
+    if (buf == null) {
+        throw new NullPointerException("buf");
+    }
+    this.buf = buf;
+    // 初始化 order 属性
+    if (buf.order() == ByteOrder.BIG_ENDIAN) {
+        order = ByteOrder.LITTLE_ENDIAN;
+    } else {
+        order = ByteOrder.BIG_ENDIAN;
+    }
+}
+```
+
+- `buf` 属性，原 ByteBuf 对象。
+
+- `order` 属性，字节数。
+
+- 实际上，SwappedByteBuf 可以看成一个特殊的 WrappedByteBuf 实现，所以它除了读写操作外的方法，都是对 `buf` 的对应方法的调用。
+
+  - `#capacity()` 方法，代码如下：
+
+    ```
+    @Override
+    public int capacity() {
+        return buf.capacity();
+    }
+    ```
+
+    - 直接调用 `buf` 的对应方法。
+
+  - `#setInt(int index, int value)` 方法，代码如下：
+
+    ```
+    @Override
+    public ByteBuf setInt(int index, int value) {
+        buf.setInt(index, ByteBufUtil.swapInt(value));
+        return this;
+    }
+    
+    // ByteBufUtil.java
+    /**
+     * Toggles the endianness of the specified 32-bit integer.
+     */
+    public static int swapInt(int value) {
+        return Integer.reverseBytes(value);
+    }
+    ```
+
+    - 先调用 `ByteBufUtil#swapInt(int value)` 方法，将 `value` 的值，转换成相反字节序的 Int 值。
+    - 后调用 `buf` 的对应方法。
+
+通过 SwappedByteBuf 类，我们可以很方便的修改原 ByteBuf 对象的字节序，并且无需进行内存复制。但是反过来，一定要注意，这两者是**共享**的。
+
+# 8. ReplayingDecoderByteBuf
+
+`io.netty.handler.codec.ReplayingDecoderByteBuf` ，继承 ByteBuf 抽象类，用于构建在 IO 阻塞条件下实现无阻塞解码的特殊 ByteBuf对 象。当要读取的数据还未接收完全时，抛出异常，交由 ReplayingDecoder 处理。
+
+细心的胖友，会看到 ReplayingDecoderByteBuf 是在 `codec` 模块，配合 ReplayingDecoder 使用。所以，本文暂时不会分享它，而是在 [《TODO 2000 ReplayingDecoderByteBuf》](https://svip.iocoder.cn/Netty/ByteBuf-1-1-ByteBuf-intro/) 中，详细解析。
+
+# 666. 彩蛋
+
+每逢开篇，内容就特别啰嗦，哈哈哈哈。
+
+推荐阅读如下文章：
+
+- AbeJeffrey [《深入研究Netty框架之ByteBuf功能原理及源码分析》](https://my.oschina.net/7001/blog/742236)
+- [《Netty 学习笔记 —— ByteBuf 继承结构》](https://skyao.gitbooks.io/learning-netty/content/buffer/inheritance.html)
\ No newline at end of file
diff --git a/netty/36-Netty 源码解析-Buffer 之 ByteBuf（二）核心子类.assets/01.png b/netty/36-Netty 源码解析-Buffer 之 ByteBuf（二）核心子类.assets/01.png
new file mode 100644
index 0000000..e4f0112
Binary files /dev/null and b/netty/36-Netty 源码解析-Buffer 之 ByteBuf（二）核心子类.assets/01.png differ
diff --git a/netty/36-Netty 源码解析-Buffer 之 ByteBuf（二）核心子类.md b/netty/36-Netty 源码解析-Buffer 之 ByteBuf（二）核心子类.md
new file mode 100644
index 0000000..b2b72c2
--- /dev/null
+++ b/netty/36-Netty 源码解析-Buffer 之 ByteBuf（二）核心子类.md	
@@ -0,0 +1,1870 @@
+# 精尽 Netty 源码解析 —— Buffer 之 ByteBuf（二）核心子类
+
+# 1. 概述
+
+在 [《精尽 Netty 源码解析 —— ByteBuf（一）之简介》](http://svip.iocoder.cn/Netty/ByteBuf-1-1-ByteBuf-intro/) 中，我们对 ByteBuf 有了整体的认识，特别是核心 API 部分。同时，我们也看到，ByteBuf 有非常非常非常多的子类，那么怎么办呢？实际上，**ByteBuf 有 8 个最最最核心的子类实现**。如下图所示：[![核心子类](36-Netty 源码解析-Buffer 之 ByteBuf（二）核心子类.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_08_04/01.png)核心子类
+
+一共可以按照三个维度来看这 8 个核心子类，刚好是 2 x 2 x 2 = 8 ：
+
+- 按照
+
+  内存类型
+
+  分类：
+
+  - ① 堆内存字节缓冲区( **Heap**ByteBuf )：底层为 JVM 堆内的字节数组，其特点是申请和释放效率较高。但是如果要进行 Socket 的 I/O 读写，需要额外多做一次内存复制，需要将堆内存对应的缓冲区复制到内核 Channel 中，性能可能会有一定程度的损耗。
+  - ② 直接内存字节缓冲区( **Direct**ByteBuf )：堆外内存，为操作系统内核空间的字节数组，它由操作系统直接管理和操作，其申请和释放的效率会慢于堆缓冲区。但是将它写入或者从 SocketChannel 中读取时，会少一次内存复制，这样可以大大提高 I/O 效率，实现零拷贝。
+  - 关于这两者的对比，感兴趣的胖友，可以再看看 [《Java NIO direct buffer 的优势在哪儿？》](https://www.zhihu.com/question/60892134) 和 [《JAVA NIO 之 Direct Buffer 与 Heap Buffer的区别？》](http://eyesmore.iteye.com/blog/1133335)
+
+- 按照
+
+   
+
+  对象池
+
+   
+
+  分类：
+
+  - ① 基于对象池( **Pooled**ByteBuf )：基于对象池的 ByteBuf 可以重用 ByteBuf ，也就是说它自己内部维护着一个对象池，当对象释放后会归还给对象池，这样就可以循环地利用创建的 ByteBuf，提升内存的使用率，降低由于高负载导致的频繁 GC。当需要大量且频繁创建缓冲区时，推荐使用该类缓冲区。
+  - ② 不使用对象池( **Unpooled**ByteBuf )：对象池的管理和维护会比较困难，所以在不需要创建大量缓冲区对象时，推荐使用此类缓冲区。
+
+- 按照
+
+   
+
+  Unsafe
+
+   
+
+  分类：
+
+  - ① 使用 Unsafe ：基于 Java `sun.misc.Unsafe.Unsafe` 的 API ，直接访问内存中的数据。
+  - ② 不使用 Unsafe ： 基于 **Heap**ByteBuf 和 **Direct**ByteBuf 的标准 API ，进行访问对应的数据。
+  - 关于 Unsafe ，JVM 大佬 R 大在知乎上有个回答：[《为什么 JUC 中大量使用了 sun.misc.Unsafe 这个类，但官方却不建议开发者使用？》](https://www.zhihu.com/question/29266773) 。关于为什么 Unsafe 的性能会更好：”其中一种是嫌 Java 性能不够好，例如说数组访问的边界检查语义，嫌这个开销太大，觉得用 Unsafe 会更快；”。
+
+默认情况下，使用 PooledUnsafeDirectByteBuf 类型。所以，重点重点重点，看 [「2.4 PooledUnsafeDirectByteBuf」](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 。
+
+# 2. PooledByteBuf
+
+`io.netty.buffer.PooledByteBuf` ，继承 AbstractReferenceCountedByteBuf 抽象类，**对象池化**的 ByteBuf 抽象基类，为基于**对象池**的 ByteBuf 实现类，提供公用的方法。
+
+关于 `io.netty.util.AbstractReferenceCountedByteBuf` 抽象类，对象引用计数器抽象类。本文暂时不解析，我们会在 [《精尽 Netty 源码解析 —— Buffer 之 ByteBuf（三）内存泄露检测》](http://svip.iocoder.cn/Netty/ByteBuf-1-3-ByteBuf-resource-leak-detector/) 详细解析。
+
+## 2.1 内部方法
+
+### 2.1.1 构造方法
+
+```
+/**
+ * Recycler 处理器，用于回收对象
+ */
+private final Recycler.Handle<PooledByteBuf<T>> recyclerHandle;
+
+/**
+ * Chunk 对象
+ */
+protected PoolChunk<T> chunk;
+/**
+ * 从 Chunk 对象中分配的内存块所处的位置
+ */
+protected long handle;
+/**
+ * 内存空间。具体什么样的数据，通过子类设置泛型。
+ */
+protected T memory;
+/**
+ * {@link #memory} 开始位置
+ *
+ * @see #idx(int)
+ */
+protected int offset;
+/**
+ * 容量
+ *
+ * @see #capacity()
+ */
+protected int length;
+/**
+ * 占用 {@link #memory} 的大小
+ */
+int maxLength;
+/**
+ * TODO 1013 Chunk
+ */
+PoolThreadCache cache;
+/**
+ * 临时 ByteBuff 对象
+ *
+ * @see #internalNioBuffer()
+ */
+private ByteBuffer tmpNioBuf;
+/**
+ * ByteBuf 分配器对象
+ */
+private ByteBufAllocator allocator;
+
+@SuppressWarnings("unchecked")
+protected PooledByteBuf(Recycler.Handle<? extends PooledByteBuf<T>> recyclerHandle, int maxCapacity) {
+    super(maxCapacity);
+    this.recyclerHandle = (Handle<PooledByteBuf<T>>) recyclerHandle;
+}
+```
+
+- `recyclerHandle` 属性，Recycler 处理器，用于回收**当前**对象。
+
+- ```
+  chunk
+  ```
+
+   
+
+  属性，PoolChunk 对象。在 Netty 中，使用 Jemalloc 算法管理内存，而 Chunk 是里面的一种
+
+  内存块
+
+  。在这里，我们可以理解
+
+   
+
+  ```
+  memory
+  ```
+
+   
+
+  所属的 PoolChunk 对象。
+
+  - `handle` 属性，从 Chunk 对象中分配的内存块所处的位置。具体的，胖友后面仔细看看 [《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（二）PoolChunk》](http://svip.iocoder.cn/Netty/ByteBuf-3-2-Jemalloc-chunk/) 和 [《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（三）PoolSubpage》](http://svip.iocoder.cn/Netty/ByteBuf-3-3-Jemalloc-subpage/) 。
+
+  - ```
+    memory
+    ```
+
+     
+
+    属性，内存空间。具体什么样的数据，通过子类设置泛型(
+
+     
+
+    ```
+    T
+    ```
+
+     
+
+    )。例如：1) PooledDirectByteBuf 和 PooledUnsafeDirectByteBuf 为
+
+     
+
+    ByteBuffer
+
+     
+
+    ；2) PooledHeapByteBuf 和 PooledUnsafeHeapByteBuf 为
+
+     
+
+    ```
+    byte[]
+    ```
+
+     
+
+    。
+
+    - `offset` 属性，使用 `memory` 的开始位置。
+    - `maxLength` 属性，**最大**使用 `memory` 的长度( 大小 )。
+    - `length` 属性，**目前**使用 `memory` 的长度( 大小 )。
+    - 😈 因为 `memory` 属性，可以被**多个** ByteBuf 使用。**每个** ByteBuf 使用范围为 `[offset, maxLength)` 。
+
+- `cache` 属性，TODO 1013 Chunk
+
+- `tmpNioBuf` 属性，临时 ByteBuff 对象，通过 `#tmpNioBuf()` 方法生成。详细解析，见 [「2.1.9 internalNioBuffer」](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 。
+
+- `allocator` 属性，ByteBuf 分配器。
+
+### 2.1.2 init0
+
+`#init0(PoolChunk<T> chunk, long handle, int offset, int length, int maxLength, PoolThreadCache cache)` 方法，初始化 PooledByteBuf 对象。代码如下：
+
+```
+private void init0(PoolChunk<T> chunk, long handle, int offset, int length, int maxLength, PoolThreadCache cache) {
+    assert handle >= 0;
+    assert chunk != null;
+
+    // From PoolChunk 对象
+    this.chunk = chunk;
+    memory = chunk.memory;
+    allocator = chunk.arena.parent;
+    // 其他
+    this.cache = cache;
+    this.handle = handle;
+    this.offset = offset;
+    this.length = length;
+    this.maxLength = maxLength;
+    tmpNioBuf = null;
+}
+```
+
+仔细的胖友，可能会发现，这是一个 `private` 私有方法。目前它被两个方法调用：
+
+- ① `#init(PoolChunk<T> chunk, long handle, int offset, int length, int maxLength, PoolThreadCache cache)` 方法，一般是基于 **pooled** 的 PoolChunk 对象，初始化 PooledByteBuf 对象。代码如下：
+
+  ```
+  void init(PoolChunk<T> chunk, long handle, int offset, int length, int maxLength, PoolThreadCache cache) {
+      init0(chunk, handle, offset, length, maxLength, cache);
+  }
+  ```
+
+- ② `#initUnpooled(PoolChunk<T> chunk, int length)` 方法，基于 **unPoolooled** 的 PoolChunk 对象，初始化 PooledByteBuf 对象。代码如下：
+
+  ```
+  void initUnpooled(PoolChunk<T> chunk, int length) {
+      init0(chunk, 0, chunk.offset, length, length, null);
+  }
+  ```
+
+  - 例如说 **Huge** 大小的 PoolChunk 对象。
+  - 注意，传入的给 `#init0(...)` 方法的 `length` 和 `maxLength` 方法参数，**都是** `length` 。
+
+可能胖友读到此处会一脸懵逼。其实，这是很正常的。可以在看完 [《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（二）PoolChunk》](http://svip.iocoder.cn/Netty/ByteBuf-3-2-Jemalloc-chunk/) 后，在回过头来，理解理解。
+
+### 2.1.3 reuse
+
+`#reuse(int maxCapacity)` 方法，每次在重用 PooledByteBuf 对象时，需要调用该方法，重置属性。代码如下：
+
+```
+/**
+ * Method must be called before reuse this {@link PooledByteBufAllocator}
+ */
+final void reuse(int maxCapacity) {
+    // 设置最大容量
+    maxCapacity(maxCapacity);
+    // 设置引用数量为 0
+    setRefCnt(1);
+    // 重置读写索引为 0
+    setIndex0(0, 0);
+    // 重置读写标记位为 0
+    discardMarks();
+}
+```
+
+也就是说，该方法在 [「2.1.2 init9」](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) **之前**就调用了。在下文中，我们会看到，该方法的调用。
+
+### 2.1.4 capacity
+
+`#capacity()` 方法，获得容量。代码如下：
+
+```
+@Override
+public final int capacity() {
+    return length;
+}
+```
+
+**当前**容量的值为 `length` 属性。
+但是，要注意的是，`maxLength` 属性，**不是表示最大容量**。`maxCapacity` 属性，才是真正表示最大容量。
+那么，`maxLength` 属性有什么用？表示**占用** `memory` 的最大容量( 而不是 PooledByteBuf 对象的最大容量 )。在写入数据超过 `maxLength` 容量时，会进行扩容，但是容量的上限，为 `maxCapacity` 。
+
+------
+
+`#capacity(int newCapacity)` 方法，调整容量大小。在这个过程中，根据情况，可能对 `memory` 扩容或缩容。代码如下：
+
+```
+ 1: @Override
+ 2: public final ByteBuf capacity(int newCapacity) {
+ 3:     // 校验新的容量，不能超过最大容量
+ 4:     checkNewCapacity(newCapacity);
+ 5: 
+ 6:     // Chunk 内存，非池化
+ 7:     // If the request capacity does not require reallocation, just update the length of the memory.
+ 8:     if (chunk.unpooled) {
+ 9:         if (newCapacity == length) { // 相等，无需扩容 / 缩容
+10:             return this;
+11:         }
+12:     // Chunk 内存，是池化
+13:     } else {
+14:         // 扩容
+15:         if (newCapacity > length) {
+16:             if (newCapacity <= maxLength) {
+17:                 length = newCapacity;
+18:                 return this;
+19:             }
+20:         // 缩容
+21:         } else if (newCapacity < length) {
+22:             // 大于 maxLength 的一半
+23:             if (newCapacity > maxLength >>> 1) {
+24:                 if (maxLength <= 512) {
+25:                     // 因为 Netty SubPage 最小是 16 ，如果小于等 16 ，无法缩容。
+26:                     if (newCapacity > maxLength - 16) {
+27:                         length = newCapacity;
+28:                         // 设置读写索引，避免超过最大容量
+29:                         setIndex(Math.min(readerIndex(), newCapacity), Math.min(writerIndex(), newCapacity));
+30:                         return this;
+31:                     }
+32:                 } else { // > 512 (i.e. >= 1024)
+33:                     length = newCapacity;
+34:                     // 设置读写索引，避免超过最大容量
+35:                     setIndex(Math.min(readerIndex(), newCapacity), Math.min(writerIndex(), newCapacity));
+36:                     return this;
+37:                 }
+38:             }
+39:         // 相等，无需扩容 / 缩容
+40:         } else {
+41:             return this;
+42:         }
+43:     }
+44: 
+45:     // 重新分配新的内存空间，并将数据复制到其中。并且，释放老的内存空间。
+46:     // Reallocation required.
+47:     chunk.arena.reallocate(this, newCapacity, true);
+48:     return this;
+49: }
+```
+
+- 第 4 行：调用 `AbstractByteBuf#checkNewCapacity(int newCapacity)` 方法，校验新的容量，不能超过最大容量。代码如下：
+
+  ```
+  protected final void checkNewCapacity(int newCapacity) {
+      ensureAccessible();
+      if (newCapacity < 0 || newCapacity > maxCapacity()) {
+          throw new IllegalArgumentException("newCapacity: " + newCapacity + " (expected: 0-" + maxCapacity() + ')');
+      }
+  }
+  ```
+
+- 第 6 至 11 行：对于基于 **unPoolooled** 的 PoolChunk 对象，除非容量不变，否则会扩容或缩容，即【第 47 行】的代码。为什么呢？在 `#initUnpooled(PoolChunk<T> chunk, int length)` 方法中，我们可以看到，`maxLength` 和 `length` 是相等的，所以大于或小于时，需要进行扩容或缩容。
+
+- 第 13 行：对于基于
+
+   
+
+  poolooled
+
+   
+
+  的 PoolChunk 对象，需要根据情况：
+
+  - 第 39 至 42 行：容量未变，不进行扩容。类似【第 9 至 11 行】的代码。
+
+  - 第 14 至 19 行：新容量**大于**当前容量，但是小于 `memory` 最大容量，仅仅修改当前容量，无需进行扩容。否则，第【第 47 行】的代码，进行**扩容**。
+
+  - 第 20 至 38 行：新容量
+
+    小于
+
+    当前容量，但是不到
+
+     
+
+    ```
+    memory
+    ```
+
+     
+
+    最大容量的
+
+    一半
+
+    ，因为缩容
+
+    相对
+
+    释放不多，无需进行缩容。否则，第【第 47 行】的代码，进行
+
+    缩容
+
+    。
+
+    - 比较神奇的是【第 26 行】的 `newCapacity > maxLength - 16` 代码块。 笔者的理解是，Netty SubPage **最小**是 16 B ，如果小于等 16 ，无法缩容。
+
+- 第 47 行：调用 `PoolArena#reallocate(PooledByteBuf<T> buf, int newCapacity, boolean freeOldMemory)` 方法，**重新分配**新的内存空间，并将数据**复制**到其中。并且，**释放**老的内存空间。详细解析，见 [《TODO 1013 Chunk》](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 中。
+
+### 2.1.5 order
+
+`#order()` 方法，返回字节序为 `ByteOrder.BIG_ENDIAN` 大端。代码如下：
+
+```
+@Override
+public final ByteOrder order() {
+    return ByteOrder.BIG_ENDIAN;
+}
+```
+
+统一**大端**模式。
+
+> FROM [《深入浅出： 大小端模式》](https://www.bysocket.com/?p=615)
+>
+> 在网络上传输数据时，由于数据传输的两端对应不同的硬件平台，采用的存储字节顺序可能不一致。所以在 TCP/IP 协议规定了在网络上必须采用网络字节顺序，也就是大端模式。
+
+### 2.1.6 unwrap
+
+`#unwrap()` 方法，返回空，因为没有被装饰的 ByteBuffer 对象。代码如下：
+
+```
+@Override
+public final ByteBuf unwrap() {
+    return null;
+}
+```
+
+### 2.1.7 retainedSlice
+
+`#retainedSlice()` 方法，代码如下：
+
+```
+@Override
+public final ByteBuf retainedSlice() {
+    final int index = readerIndex();
+    return retainedSlice(index, writerIndex() - index);
+}
+
+@Override
+public final ByteBuf retainedSlice(int index, int length) {
+    return PooledSlicedByteBuf.newInstance(this, this, index, length);
+}
+```
+
+- 调用 `PooledSlicedByteBuf#newInstance(AbstractByteBuf unwrapped, ByteBuf wrapped, int index, int length)` 方法，创建**池化的** PooledSlicedByteBuf 对象。
+- TODO 1016 派生类
+
+### 2.1.8 retainedDuplicate
+
+`#retainedDuplicate()` 方法，代码如下：
+
+```
+@Override
+public final ByteBuf retainedDuplicate() {
+    return PooledDuplicatedByteBuf.newInstance(this, this, readerIndex(), writerIndex());
+}
+```
+
+- 调用 `PooledSlicedByteBuf#newInstance(AbstractByteBuf unwrapped, ByteBuf wrapped, int readerIndex, int writerIndex)` 方法，创建**池化的** PooledDuplicatedByteBuf.newInstance 对象。
+- TODO 1016 派生类
+
+### 2.1.9 internalNioBuffer
+
+`#internalNioBuffer()` 方法，获得临时 ByteBuf 对象( `tmpNioBuf` ) 。代码如下：
+
+```
+protected final ByteBuffer internalNioBuffer() {
+    ByteBuffer tmpNioBuf = this.tmpNioBuf;
+    // 为空，创建临时 ByteBuf 对象
+    if (tmpNioBuf == null) {
+        this.tmpNioBuf = tmpNioBuf = newInternalNioBuffer(memory);
+    }
+    return tmpNioBuf;
+}
+```
+
+- 当 `tmpNioBuf` 属性为空时，调用 `#newInternalNioBuffer(T memory)` 方法，创建 ByteBuffer 对象。因为 `memory` 的类型不确定，所以该方法定义成**抽象方法**，由子类实现。代码如下：
+
+  ```
+  protected abstract ByteBuffer newInternalNioBuffer(T memory);
+  ```
+
+------
+
+为什么要有 `tmpNioBuf` 这个属性呢？以 PooledDirectByteBuf 举例子，代码如下：
+
+```
+@Override
+public int setBytes(int index, FileChannel in, long position, int length) throws IOException {
+    checkIndex(index, length);
+    // 获得临时 ByteBuf 对象
+    ByteBuffer tmpBuf = internalNioBuffer();
+    index = idx(index);
+    tmpBuf.clear().position(index).limit(index + length);
+    try {
+        // 写入临时 ByteBuf 对象
+        return in.read(tmpBuf, position);
+    } catch (ClosedChannelException ignored) {
+        return -1;
+    }
+}
+
+private int getBytes(int index, FileChannel out, long position, int length, boolean internal) throws IOException {
+    checkIndex(index, length);
+    if (length == 0) {
+        return 0;
+    }
+
+    // 获得临时 ByteBuf 对象
+    ByteBuffer tmpBuf = internal ? internalNioBuffer() : memory.duplicate();
+    index = idx(index);
+    tmpBuf.clear().position(index).limit(index + length);
+    // 写入到 FileChannel 中
+    return out.write(tmpBuf, position);
+}
+```
+
+### 2.1.10 deallocate
+
+`#deallocate()` 方法，当引用计数为 0 时，调用该方法，进行内存回收。代码如下：
+
+```
+@Override
+protected final void deallocate() {
+    if (handle >= 0) {
+        // 重置属性
+        final long handle = this.handle;
+        this.handle = -1;
+        memory = null;
+        tmpNioBuf = null;
+        // 释放内存回 Arena 中
+        chunk.arena.free(chunk, handle, maxLength, cache);
+        chunk = null;
+        // 回收对象
+        recycle();
+    }
+}
+
+private void recycle() {
+    recyclerHandle.recycle(this); // 回收对象
+}
+```
+
+### 2.1.11 idx
+
+`#idx(int index)` 方法，获得指定位置在 `memory` 变量中的位置。代码如下：
+
+```
+protected final int idx(int index) {
+    return offset + index;
+}
+```
+
+## 2.2 PooledDirectByteBuf
+
+`io.netty.buffer.PooledDirectByteBuf` ，实现 PooledByteBuf 抽象类，基于 **ByteBuffer** 的**可重用** ByteBuf 实现类。所以，泛型 `T` 为 ByteBuffer ，即：
+
+```
+final class PooledDirectByteBuf extends PooledByteBuf<ByteBuffer>
+```
+
+### 2.2.1 构造方法
+
+```
+private PooledDirectByteBuf(Recycler.Handle<PooledDirectByteBuf> recyclerHandle, int maxCapacity) {
+    super(recyclerHandle, maxCapacity);
+}
+```
+
+### 2.2.2 newInstance
+
+`#newInstance(int maxCapacity)` **静态**方法，“创建” PooledDirectByteBuf 对象。代码如下：
+
+```
+/**
+ * Recycler 对象
+ */
+private static final Recycler<PooledDirectByteBuf> RECYCLER = new Recycler<PooledDirectByteBuf>() {
+
+    @Override
+    protected PooledDirectByteBuf newObject(Handle<PooledDirectByteBuf> handle) {
+        return new PooledDirectByteBuf(handle, 0); // 真正创建 PooledDirectByteBuf 对象
+    }
+
+};
+
+static PooledDirectByteBuf newInstance(int maxCapacity) {
+    // 从 Recycler 的对象池中获得 PooledDirectByteBuf 对象
+    PooledDirectByteBuf buf = RECYCLER.get();
+    // 重置 PooledDirectByteBuf 的属性
+    buf.reuse(maxCapacity);
+    return buf;
+}
+```
+
+### 2.2.3 newInternalNioBuffer
+
+`#newInternalNioBuffer(ByteBuffer memory)` 方法，获得临时 ByteBuf 对象( `tmpNioBuf` ) 。代码如下：
+
+```
+@Override
+protected ByteBuffer newInternalNioBuffer(ByteBuffer memory) {
+    return memory.duplicate();
+}
+```
+
+- 调用 `ByteBuffer#duplicate()` 方法，复制一个 ByteBuffer 对象，**共享**里面的数据。
+
+### 2.2.4 isDirect
+
+`#isDirect()` 方法，获得内部类型是否为 Direct ，返回 `true` 。代码如下：
+
+```
+@Override
+public boolean isDirect() {
+    return true;
+}
+```
+
+### 2.2.5 读取 / 写入操作
+
+老样子，我们以 Int 类型为例子，来看看它的读取和写入操作的实现代码。代码如下：
+
+```
+@Override
+protected int _getInt(int index) {
+    return memory.getInt(idx(index));
+}
+
+@Override
+protected void _setInt(int index, int value) {
+    memory.putInt(idx(index), value);
+}
+```
+
+### 2.2.6 copy
+
+`#copy(int index, int length)` 方法，复制指定范围的数据到新创建的 Direct ByteBuf 对象。代码如下：
+
+```
+@Override
+public ByteBuf copy(int index, int length) {
+    // 校验索引
+    checkIndex(index, length);
+    // 创建一个 Direct ByteBuf 对象
+    ByteBuf copy = alloc().directBuffer(length, maxCapacity());
+    // 写入数据
+    copy.writeBytes(this, index, length);
+    return copy;
+}
+```
+
+### 2.2.7 转换 NIO ByteBuffer 操作
+
+#### 2.2.7.1 nioBufferCount
+
+`#nioBufferCount()` 方法，返回 ByteBuf 包含 ByteBuffer 数量为 **1** 。代码如下：
+
+```
+@Override
+public int nioBufferCount() {
+    return 1;
+}
+```
+
+#### 2.2.7.2 nioBuffer
+
+`#nioBuffer(int index, int length)` 方法，返回 ByteBuf **指定范围**包含的 ByteBuffer 对象( **共享** )。代码如下：
+
+```
+@Override
+public ByteBuffer nioBuffer(int index, int length) {
+    checkIndex(index, length);
+    // memory 中的开始位置
+    index = idx(index);
+    // duplicate 复制一个 ByteBuffer 对象，共享数据
+    // position + limit 设置位置和大小限制
+    // slice 创建 [position, limit] 子缓冲区，共享数据
+    return ((ByteBuffer) memory.duplicate().position(index).limit(index + length)).slice();
+}
+```
+
+- 代码比较简单，看具体注释。
+
+#### 2.2.7.3 nioBuffers
+
+`#nioBuffers(int index, int length)` 方法，返回 ByteBuf **指定范围**内包含的 ByteBuffer 数组( **共享** )。代码如下：
+
+```
+@Override
+public ByteBuffer[] nioBuffers(int index, int length) {
+    return new ByteBuffer[] { nioBuffer(index, length) };
+}
+```
+
+- 在 `#nioBuffer(int index, int length)` 方法的基础上，创建大小为 1 的 ByteBuffer 数组。
+
+#### 2.2.7.4 internalNioBuffer
+
+`#internalNioBuffer(int index, int length)` 方法，返回 ByteBuf **指定范围**内的 ByteBuffer 对象( **共享** )。代码如下：
+
+```
+@Override
+public ByteBuffer internalNioBuffer(int index, int length) {
+    checkIndex(index, length);
+    // memory 中的开始位置
+    index = idx(index);
+    // clear 标记清空（不会清理数据）
+    // position + limit 设置位置和大小限制
+    return (ByteBuffer) internalNioBuffer().clear().position(index).limit(index + length);
+}
+```
+
+- 代码比较简单，看具体注释。
+- 因为是基于 `tmpNioBuf` 属性实现，所以方法在命名上，以 `"internal"` 打头。
+
+### 2.2.8 Heap 相关方法
+
+不支持 Heap 相关方法。代码如下：
+
+```
+@Override
+public boolean hasArray() {
+    return false;
+}
+
+@Override
+public byte[] array() {
+    throw new UnsupportedOperationException("direct buffer");
+}
+
+@Override
+public int arrayOffset() {
+    throw new UnsupportedOperationException("direct buffer");
+}
+```
+
+### 2.2.9 Unsafe 相关方法
+
+不支持 Unsafe 相关方法。代码如下：
+
+```
+@Override
+public boolean hasMemoryAddress() {
+    return false;
+}
+
+@Override
+public long memoryAddress() {
+    throw new UnsupportedOperationException();
+}
+```
+
+## 2.3 PooledHeapByteBuf
+
+`io.netty.buffer.PooledHeapByteBuf` ，实现 PooledByteBuf 抽象类，基于 **ByteBuffer** 的**可重用** ByteBuf 实现类。所以，泛型 `T` 为 `byte[]` ，即：
+
+```
+class PooledHeapByteBuf extends PooledByteBuf<byte[]> {
+```
+
+### 2.3.1 构造方法
+
+和 [「2.2.1 构造方法」](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 相同。
+
+### 2.3.2 newInstance
+
+和 [「2.2.2 newInstance」](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 相同。
+
+### 2.3.3 newInternalNioBuffer
+
+`#newInternalNioBuffer(byte[] memory)` 方法，获得临时 ByteBuf 对象( `tmpNioBuf` ) 。代码如下：
+
+```
+@Override
+protected final ByteBuffer newInternalNioBuffer(byte[] memory) {
+    return ByteBuffer.wrap(memory);
+}
+```
+
+- 调用 `ByteBuffer#wrap(byte[] array)` 方法，创建 ByteBuffer 对象。注意，返回的是 HeapByteBuffer 对象。
+
+### 2.3.4 isDirect
+
+`#isDirect()` 方法，获得内部类型是否为 Direct ，返回 `false` 。代码如下：
+
+```
+@Override
+public boolean isDirect() {
+    return false;
+}
+```
+
+### 2.3.5 读取 / 写入操作
+
+老样子，我们以 Int 类型为例子，来看看它的读取和写入操作的实现代码。
+
+① **读取**操作：
+
+```
+@Override
+protected int _getInt(int index) {
+    return HeapByteBufUtil.getInt(memory, idx(index));
+}
+
+// HeapByteBufUtil.java
+static int getInt(byte[] memory, int index) {
+    return  (memory[index]     & 0xff) << 24 |
+            (memory[index + 1] & 0xff) << 16 |
+            (memory[index + 2] & 0xff) <<  8 |
+            memory[index + 3] & 0xff;
+}
+```
+
+② **写入**操作：
+
+```
+@Override
+protected void _setInt(int index, int   value) {
+    HeapByteBufUtil.setInt(memory, idx(index), value);
+}
+
+// HeapByteBufUtil.java
+static void setInt(byte[] memory, int index, int value) {
+    memory[index]     = (byte) (value >>> 24);
+    memory[index + 1] = (byte) (value >>> 16);
+    memory[index + 2] = (byte) (value >>> 8);
+    memory[index + 3] = (byte) value;
+}
+```
+
+### 2.3.6 copy
+
+`#copy(int index, int length)` 方法，复制指定范围的数据到新创建的 Heap ByteBuf 对象。代码如下：
+
+```
+@Override
+public ByteBuf copy(int index, int length) {
+    // 校验索引
+    checkIndex(index, length);
+    // 创建一个 Heap ByteBuf 对象
+    ByteBuf copy = alloc().heapBuffer(length, maxCapacity());
+    // 写入数据
+    copy.writeBytes(this, index, length);
+    return copy;
+}
+```
+
+和 PooledDirectByteBuf [「2.2.6 copy」](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 的差异在于，创建的是 **Heap** ByteBuf 对象。
+
+### 2.3.7 转换 NIO ByteBuffer 操作
+
+#### 2.3.7.1 nioBufferCount
+
+和 [「2.2.7.1 nioBufferCount」](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 一致。
+
+#### 2.3.7.2 nioBuffer
+
+`#nioBuffer(int index, int length)` 方法，返回 ByteBuf **指定范围**包含的 ByteBuffer 对象( **共享** )。代码如下：
+
+```
+@Override
+public final ByteBuffer nioBuffer(int index, int length) {
+    checkIndex(index, length);
+    // memory 中的开始位置
+    index = idx(index);
+    // 创建 ByteBuffer 对象
+    ByteBuffer buf =  ByteBuffer.wrap(memory, index, length);
+    // slice 创建 [position, limit] 子缓冲区
+    return buf.slice();
+}
+```
+
+- 代码比较简单，看具体注释。
+
+#### 2.3.7.3 nioBuffers
+
+和 [「2.2.7.3 nioBuffers」](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 一致。
+
+#### 2.3.7.4 internalNioBuffer
+
+和 [「2.2.7.4 nioBuffers」](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 一致。
+
+### 2.3.8 Heap 相关方法
+
+```
+@Override
+public final boolean hasArray() {
+    return true;
+}
+
+@Override
+public final byte[] array() {
+    ensureAccessible();
+    return memory;
+}
+
+@Override
+public final int arrayOffset() {
+    return offset;
+}
+```
+
+### 2.3.8 Unsafe 相关方法
+
+和 [「2.2.9 Unsafe 相关方法」](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 一致。
+
+## 2.4 PooledUnsafeDirectByteBuf
+
+> 老艿艿：它是 [「2.2 PooledDirectByteBuf」](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 对应的基于 Unsafe 版本的实现类。
+
+`io.netty.buffer.PooledUnsafeDirectByteBuf` ，实现 PooledByteBuf 抽象类，基于 **ByteBuffer** + **Unsafe** 的**可重用** ByteBuf 实现类。所以，泛型 `T` 为 `ByteBuffer` ，即：
+
+```
+final class PooledUnsafeDirectByteBuf extends PooledByteBuf<ByteBuffer>
+```
+
+### 2.4.1 构造方法
+
+和 [「2.2.1 构造方法」](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 相同。
+
+### 2.4.2 newInstance
+
+和 [「2.2.2 newInstance」](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 相同。
+
+### 2.4.3 初始化
+
+PooledUnsafeDirectByteBuf 重写了初始化相关的方法，代码如下：
+
+```
+@Override
+void init(PoolChunk<ByteBuffer> chunk, long handle, int offset, int length, int maxLength,
+          PoolThreadCache cache) {
+    // 调用父初始化方法
+    super.init(chunk, handle, offset, length, maxLength, cache);
+    // 初始化内存地址
+    initMemoryAddress(); // <1>
+}
+
+@Override
+void initUnpooled(PoolChunk<ByteBuffer> chunk, int length) {
+    // 调用父初始化方法
+    super.initUnpooled(chunk, length);
+    // 初始化内存地址
+    initMemoryAddress(); // <2>
+}
+```
+
+- 在 `<1>` 处，增加调用 `#initMemoryAddress()` 方法，初始化内存地址。代码如下：
+
+  ```
+  /**
+   * 内存地址
+   */
+  private long memoryAddress;
+  
+  private void initMemoryAddress() {
+      memoryAddress = PlatformDependent.directBufferAddress(memory) + offset; // <2>
+  }
+  ```
+
+  - 调用 `PlatformDependent#directBufferAddress(ByteBuffer buffer)` 方法，获得 ByteBuffer 对象的起始内存地址。代码如下：
+
+    ```
+    // PlatformDependent.java
+    public static long directBufferAddress(ByteBuffer buffer) {
+        return PlatformDependent0.directBufferAddress(buffer);
+    }
+    
+    // PlatformDependent0.java
+    static final Unsafe UNSAFE;
+    
+    static long directBufferAddress(ByteBuffer buffer) {
+        return getLong(buffer, ADDRESS_FIELD_OFFSET);
+    }
+    
+    private static long getLong(Object object, long fieldOffset) {
+        return UNSAFE.getLong(object, fieldOffset);
+    }
+    ```
+
+    - 对于 Unsafe 类不熟悉的胖友，可以看看 [《Java Unsafe 类》](https://blog.csdn.net/zhxdick/article/details/52003123)
+
+  - 注意，`<2>` 处的代码，已经将 `offset` 添加到 `memoryAddress` 中。所以在 `#addr(int index)` 方法中，求指定位置( `index` ) 在内存地址的顺序，不用再添加。代码如下：
+
+    ```
+    private long addr(int index) {
+        return memoryAddress + index;
+    }
+    ```
+
+    - x
+
+### 2.4.4 newInternalNioBuffer
+
+和 [「2.2.3 newInternalNioBuffer」](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 相同。
+
+### 2.4.5 isDirect
+
+和 [「2.2.4 isDirect」](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 相同。
+
+### 2.4.6 读取 / 写入操作
+
+老样子，我们以 Int 类型为例子，来看看它的读取和写入操作的实现代码。
+
+① **读取**操作：
+
+```
+@Override
+protected int _getInt(int index) {
+    return UnsafeByteBufUtil.getInt(addr(index));
+}
+
+// UnsafeByteBufUtil.java
+static int getInt(long address) {
+    if (UNALIGNED) {
+        int v = PlatformDependent.getInt(address);
+        return BIG_ENDIAN_NATIVE_ORDER ? v : Integer.reverseBytes(v);
+    }
+    return PlatformDependent.getByte(address) << 24 |
+           (PlatformDependent.getByte(address + 1) & 0xff) << 16 |
+           (PlatformDependent.getByte(address + 2) & 0xff) <<  8 |
+           PlatformDependent.getByte(address + 3)  & 0xff;
+}
+
+// PlatformDependent.java
+public static int getInt(long address) {
+    return PlatformDependent0.getInt(address);
+}
+
+// PlatformDependent0.java
+static int getInt(long address) {
+    return UNSAFE.getInt(address);
+}
+```
+
+② **写入**操作：
+
+```
+@Override
+protected void _setInt(int index, int value) {
+    UnsafeByteBufUtil.setInt(addr(index), value);
+}
+
+// UnsafeByteBufUtil.java
+static void setInt(long address, int value) {
+    if (UNALIGNED) {
+        PlatformDependent.putInt(address, BIG_ENDIAN_NATIVE_ORDER ? value : Integer.reverseBytes(value));
+    } else {
+        PlatformDependent.putByte(address, (byte) (value >>> 24));
+        PlatformDependent.putByte(address + 1, (byte) (value >>> 16));
+        PlatformDependent.putByte(address + 2, (byte) (value >>> 8));
+        PlatformDependent.putByte(address + 3, (byte) value);
+    }
+}
+
+// PlatformDependent.java
+public static void putInt(long address, int value) {
+    PlatformDependent0.putInt(address, value);
+}
+
+// PlatformDependent0.java
+static void putInt(long address, int value) {
+    UNSAFE.putInt(address, value);
+}
+```
+
+### 2.4.7 copy
+
+`#copy(int index, int length)` 方法，复制指定范围的数据到新创建的 Direct ByteBuf 对象。代码如下：
+
+```
+@Override
+public ByteBuf copy(int index, int length) {
+    return UnsafeByteBufUtil.copy(this, addr(index), index, length);
+}
+
+// UnsafeByteBufUtil.java
+static ByteBuf copy(AbstractByteBuf buf, long addr, int index, int length) {
+    buf.checkIndex(index, length);
+    // 创建 Direct ByteBuffer 对象
+    ByteBuf copy = buf.alloc().directBuffer(length, buf.maxCapacity());
+    if (length != 0) {
+        if (copy.hasMemoryAddress()) {
+            // 使用 Unsafe 操作来复制
+            PlatformDependent.copyMemory(addr, copy.memoryAddress(), length);
+            copy.setIndex(0, length);
+        } else {
+            copy.writeBytes(buf, index, length);
+        }
+    }
+    return copy;
+}
+
+// PlatformDependent.java
+public static void copyMemory(long srcAddr, long dstAddr, long length) {
+    PlatformDependent0.copyMemory(srcAddr, dstAddr, length);
+}
+
+// PlatformDependent0.java
+static void copyMemory(long srcAddr, long dstAddr, long length) {
+    //UNSAFE.copyMemory(srcAddr, dstAddr, length);
+    while (length > 0) {
+        long size = Math.min(length, UNSAFE_COPY_THRESHOLD);
+        UNSAFE.copyMemory(srcAddr, dstAddr, size);
+        length -= size;
+        srcAddr += size;
+        dstAddr += size;
+    }
+}
+```
+
+### 2.4.8 转换 NIO ByteBuffer 操作
+
+#### 2.4.8.1 nioBufferCount
+
+和 [「2.2.7.1 nioBufferCount」](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 一致。
+
+#### 2.4.8.2 nioBuffer
+
+和 [「2.2.7.2 nioBuffer」](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 一致。
+
+#### 2.4.8.3 nioBuffers
+
+和 [「2.2.7.3 nioBuffers」](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 一致。
+
+#### 2.4.8.4 internalNioBuffer
+
+和 [「2.2.7.4 internalNioBuffer」](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 一致。
+
+### 2.4.9 Heap 相关方法
+
+不支持 Heap 相关方法。
+
+### 2.4.10 Unsafe 相关方法。
+
+```
+@Override
+public boolean hasMemoryAddress() {
+    return true;
+}
+
+@Override
+public long memoryAddress() {
+    ensureAccessible();
+    return memoryAddress;
+}
+```
+
+### 2.4.11 newSwappedByteBuf
+
+> `#newSwappedByteBuf()` 方法的**重写**，是 Unsafe 类型独有的。
+
+`#newSwappedByteBuf()` 方法，创建 SwappedByteBuf 对象。代码如下：
+
+```
+@Override
+protected SwappedByteBuf newSwappedByteBuf() {
+    if (PlatformDependent.isUnaligned()) { // 支持
+        // Only use if unaligned access is supported otherwise there is no gain.
+        return new UnsafeDirectSwappedByteBuf(this);
+    }
+    return super.newSwappedByteBuf();
+}
+```
+
+- 对于 Linux 环境下，一般是支持 unaligned access( 对齐访问 )，所以返回的是 UnsafeDirectSwappedByteBuf 对象。详细解析，见 [《TODO 1016 派生类》](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 。
+- 为什么要对齐访问呢？可看 [《什么是字节对齐，为什么要对齐?》](https://www.zhihu.com/question/23791224) 。有趣。
+
+## 2.5 PooledUnsafeHeapByteBuf
+
+`io.netty.buffer.PooledUnsafeHeapByteBuf` ，实现 PooledHeapByteBuf 类，在 [「2.3 PooledHeapByteBuf」](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 的基础上，基于 **Unsafe** 的**可重用** ByteBuf 实现类。所以，泛型 `T` 为 `byte[]` ，即：
+
+```
+final class PooledUnsafeHeapByteBuf extends PooledHeapByteBuf
+```
+
+也因此，PooledUnsafeHeapByteBuf 需要实现的方法，灰常少。
+
+### 2.5.1 构造方法
+
+和 [「2.2.1 构造方法」](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 相同。
+
+### 2.5.2 newInstance
+
+和 [「2.2.2 newInstance」](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 相同。
+
+### 2.5.3 读取 / 写入操作
+
+老样子，我们以 Int 类型为例子，来看看它的读取和写入操作的实现代码。
+
+① **读取**操作：
+
+```
+@Override
+protected int _getInt(int index) {
+    return UnsafeByteBufUtil.getInt(memory, idx(index));
+}
+
+// UnsafeByteBufUtil.java
+static int getInt(byte[] array, int index) {
+    if (UNALIGNED) {
+        int v = PlatformDependent.getInt(array, index);
+        return BIG_ENDIAN_NATIVE_ORDER ? v : Integer.reverseBytes(v);
+    }
+    return PlatformDependent.getByte(array, index) << 24 |
+           (PlatformDependent.getByte(array, index + 1) & 0xff) << 16 |
+           (PlatformDependent.getByte(array, index + 2) & 0xff) <<  8 |
+           PlatformDependent.getByte(array, index + 3) & 0xff;
+}
+
+// PlatformDependent.java
+public static int getInt(byte[] data, int index) {
+    return PlatformDependent0.getInt(data, index);
+}
+
+// PlatformDependent0.java
+static int getInt(byte[] data, int index) {
+    return UNSAFE.getInt(data, BYTE_ARRAY_BASE_OFFSET + index);
+}
+```
+
+- 基于 Unsafe 操作 `byte[]` 数组。
+
+② **写入**操作：
+
+```
+@Override
+protected void _setInt(int index, int value) {
+    UnsafeByteBufUtil.setInt(memory, idx(index), value);
+}
+
+// UnsafeByteBufUtil.java
+static void setInt(byte[] array, int index, int value) {
+    if (UNALIGNED) {
+        PlatformDependent.putInt(array, index, BIG_ENDIAN_NATIVE_ORDER ? value : Integer.reverseBytes(value));
+    } else {
+        PlatformDependent.putByte(array, index, (byte) (value >>> 24));
+        PlatformDependent.putByte(array, index + 1, (byte) (value >>> 16));
+        PlatformDependent.putByte(array, index + 2, (byte) (value >>> 8));
+        PlatformDependent.putByte(array, index + 3, (byte) value);
+    }
+}
+
+// PlatformDependent.java
+public static void putInt(byte[] data, int index, int value) {
+    PlatformDependent0.putInt(data, index, value);
+}
+
+// PlatformDependent0.java
+static void putInt(byte[] data, int index, int value) {
+    UNSAFE.putInt(data, BYTE_ARRAY_BASE_OFFSET + index, value);
+}
+```
+
+### 2.5.4 newSwappedByteBuf
+
+> `#newSwappedByteBuf()` 方法的**重写**，是 Unsafe 类型独有的。
+
+`#newSwappedByteBuf()` 方法，创建 SwappedByteBuf 对象。代码如下：
+
+```
+@Override
+@Deprecated
+protected SwappedByteBuf newSwappedByteBuf() {
+    if (PlatformDependent.isUnaligned()) {
+        // Only use if unaligned access is supported otherwise there is no gain.
+        return new UnsafeHeapSwappedByteBuf(this);
+    }
+    return super.newSwappedByteBuf();
+}
+```
+
+- 对于 Linux 环境下，一般是支持 unaligned access( 对齐访问 )，所以返回的是 UnsafeHeapSwappedByteBuf 对象。详细解析，见 [《TODO 1016 派生类》](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 。
+
+# 3. UnpooledByteBuf
+
+😈 不存在 UnpooledByteBuf 这样一个类，主要是为了**聚合**所有 Unpooled 类型的 ByteBuf 实现类。
+
+## 3.1 UnpooledDirectByteBuf
+
+`io.netty.buffer.UnpooledDirectByteBuf` ，实现 AbstractReferenceCountedByteBuf 抽象类，对应 [「2.2 PooledDirectByteBuf」](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 的**非池化** ByteBuf 实现类。
+
+### 3.1.1 构造方法
+
+```
+/**
+ * ByteBuf 分配器对象
+ */
+private final ByteBufAllocator alloc;
+
+/**
+ * 数据 ByteBuffer 对象
+ */
+private ByteBuffer buffer;
+/**
+ * 临时 ByteBuffer 对象
+ */
+private ByteBuffer tmpNioBuf;
+/**
+ * 容量
+ */
+private int capacity;
+/**
+ * 是否需要释放 <1>
+ *
+ * 如果 {@link #buffer} 从外部传入，则需要进行释放，即 {@link #UnpooledDirectByteBuf(ByteBufAllocator, ByteBuffer, int)} 构造方法。
+ */
+private boolean doNotFree;
+
+public UnpooledDirectByteBuf(ByteBufAllocator alloc, int initialCapacity, int maxCapacity) {
+    // 设置最大容量
+    super(maxCapacity);
+    if (alloc == null) {
+        throw new NullPointerException("alloc");
+    }
+    if (initialCapacity < 0) {
+        throw new IllegalArgumentException("initialCapacity: " + initialCapacity);
+    }
+    if (maxCapacity < 0) {
+        throw new IllegalArgumentException("maxCapacity: " + maxCapacity);
+    }
+    if (initialCapacity > maxCapacity) {
+        throw new IllegalArgumentException(String.format("initialCapacity(%d) > maxCapacity(%d)", initialCapacity, maxCapacity));
+    }
+
+    this.alloc = alloc;
+
+    // 创建 Direct ByteBuffer 对象
+    // 设置数据 ByteBuffer 对象
+    setByteBuffer(ByteBuffer.allocateDirect(initialCapacity));
+}
+
+protected UnpooledDirectByteBuf(ByteBufAllocator alloc, ByteBuffer initialBuffer, int maxCapacity) {
+    // 设置最大容量
+    super(maxCapacity);
+    if (alloc == null) {
+        throw new NullPointerException("alloc");
+    }
+    if (initialBuffer == null) {
+        throw new NullPointerException("initialBuffer");
+    }
+    if (!initialBuffer.isDirect()) { // 必须是 Direct
+        throw new IllegalArgumentException("initialBuffer is not a direct buffer.");
+    }
+    if (initialBuffer.isReadOnly()) { // 必须可写
+        throw new IllegalArgumentException("initialBuffer is a read-only buffer.");
+    }
+
+    // 获得剩余可读字节数，作为初始容量大小 <2>
+    int initialCapacity = initialBuffer.remaining();
+    if (initialCapacity > maxCapacity) {
+        throw new IllegalArgumentException(String.format(
+                "initialCapacity(%d) > maxCapacity(%d)", initialCapacity, maxCapacity));
+    }
+
+    this.alloc = alloc;
+
+    // 标记为 true 。因为 initialBuffer 是从外部传递进来，释放的工作，不交给当前 UnpooledDirectByteBuf 对象。
+    doNotFree = true; <1>
+
+    // slice 切片
+    // 设置数据 ByteBuffer 对象
+    setByteBuffer(initialBuffer.slice().order(ByteOrder.BIG_ENDIAN));
+    // 设置写索引 <2>
+    writerIndex(initialCapacity);
+}
+```
+
+- 代码比较简单，主要要理解下 `<1>` 和 `<2>` 两处。
+
+- 调用 `#allocateDirect(int initialCapacity)` 方法，创建 Direct ByteBuffer 对象。代码如下：
+
+  ```
+  protected ByteBuffer allocateDirect(int initialCapacity) {
+      return ByteBuffer.allocateDirect(initialCapacity);
+  }
+  ```
+
+- 调用 `#setByteBuffer(ByteBuffer buffer)` 方法，设置数据 ByteBuffer 对象。如果有老的**自己的**( 指的是自己创建的 ) `buffer` 对象，需要进行释放。代码如下：
+
+  ```
+  private void setByteBuffer(ByteBuffer buffer) {
+      ByteBuffer oldBuffer = this.buffer;
+      if (oldBuffer != null) {
+          // 标记为 false 。因为设置的 ByteBuffer 对象，是 UnpooledDirectByteBuf 自己创建的
+          if (doNotFree) {
+              doNotFree = false;
+          } else {
+              // 释放老的 buffer 对象
+              freeDirect(oldBuffer); // <3>
+          }
+      }
+  
+      // 设置 buffer
+      this.buffer = buffer;
+      // 重置 tmpNioBuf 为 null
+      tmpNioBuf = null;
+      // 设置容量
+      capacity = buffer.remaining();
+  }
+  ```
+
+  - `<3>` 处，调用 `#freeDirect(ByteBuffer buffer)` 方法，释放**老的** `buffer` 对象。详细解析，见 [「3.1.3 deallocate」](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 。
+
+### 3.1.2 capacity
+
+`#capacity()` 方法，获得容量。代码如下：
+
+```
+@Override
+public int capacity() {
+    return capacity;
+}
+```
+
+------
+
+`#capacity(int newCapacity)` 方法，调整容量大小。在这个过程中，根据情况，可能对 `buffer` 扩容或缩容。代码如下：
+
+```
+@SuppressWarnings("Duplicates")
+@Override
+public ByteBuf capacity(int newCapacity) {
+    // 校验新的容量，不能超过最大容量
+    checkNewCapacity(newCapacity);
+
+    int readerIndex = readerIndex();
+    int writerIndex = writerIndex();
+
+    int oldCapacity = capacity;
+    // 扩容
+    if (newCapacity > oldCapacity) {
+        ByteBuffer oldBuffer = buffer;
+        // 创建新的 Direct ByteBuffer 对象
+        ByteBuffer newBuffer = allocateDirect(newCapacity);
+        // 复制数据到新的 buffer 对象
+        oldBuffer.position(0).limit(oldBuffer.capacity());
+        newBuffer.position(0).limit(oldBuffer.capacity());
+        newBuffer.put(oldBuffer);
+        newBuffer.clear(); // 因为读取和写入，使用 readerIndex 和 writerIndex ，所以没关系。
+        // 设置新的 buffer 对象，并根据条件释放老的 buffer 对象
+        setByteBuffer(newBuffer);
+    // 缩容
+    } else if (newCapacity < oldCapacity) {
+        ByteBuffer oldBuffer = buffer;
+        // 创建新的 Direct ByteBuffer 对象
+        ByteBuffer newBuffer = allocateDirect(newCapacity);
+        if (readerIndex < newCapacity) {
+            // 如果写索引超过新容量，需要重置下，设置为最大容量。否则就越界了。
+            if (writerIndex > newCapacity) {
+                writerIndex(writerIndex = newCapacity);
+            }
+            // 复制数据到新的 buffer 对象
+            oldBuffer.position(readerIndex).limit(writerIndex);
+            newBuffer.position(readerIndex).limit(writerIndex);
+            newBuffer.put(oldBuffer);
+            newBuffer.clear(); // 因为读取和写入，使用 readerIndex 和 writerIndex ，所以没关系。
+        } else {
+            // 因为读索引超过新容量，所以写索引超过新容量
+            // 如果读写索引都超过新容量，需要重置下，都设置为最大容量。否则就越界了。
+            setIndex(newCapacity, newCapacity);
+            // 这里要注意下，老的数据，相当于不进行复制，因为已经读取完了。
+        }
+        // 设置新的 buffer 对象，并根据条件释放老的 buffer 对象
+        setByteBuffer(newBuffer);
+    }
+    return this;
+}
+```
+
+- 虽然代码比较长，实际很简单。胖友自己耐心看下注释进行理解下噢。
+
+### 3.1.3 deallocate
+
+`#deallocate()` 方法，当引用计数为 0 时，调用该方法，进行内存回收。代码如下：
+
+```
+@Override
+protected void deallocate() {
+    ByteBuffer buffer = this.buffer;
+    if (buffer == null) {
+        return;
+    }
+    // 置空 buffer 属性
+    this.buffer = null;
+
+    // 释放 buffer 对象
+    if (!doNotFree) {
+        freeDirect(buffer);
+    }
+}
+```
+
+- `#freeDirect(ByteBuffer buffer)` 方法，释放 `buffer` 对象。代码如下：
+
+  ```
+  protected void freeArray(byte[] array) {
+      PlatformDependent.freeDirectBuffer(buffer);
+  }
+  
+  // PlatformDependent.java
+  private static final Cleaner NOOP = new Cleaner() { ... }
+  
+  public static void freeDirectBuffer(ByteBuffer buffer) {
+      CLEANER.freeDirectBuffer(buffer);
+  }
+  ```
+
+  - 通过调用 `io.netty.util.internal.Cleaner#freeDirectBuffer(ByteBuffer buffer)` 方法，释放 Direct ByteBuffer 对象。因为 Java 的版本不同，调用的方法，所以 Cleaner 有两个 实现类：
+  - `io.netty.util.internal.CleanerJava9` ，适用于 Java9+ 的版本，通过反射调用 DirectByteBuffer 对象的 `#invokeCleaner()` 方法，进行释放。
+  - `io.netty.util.internal.CleanerJava6` ，适用于 Java6+ 的版本，通过反射获得 DirectByteBuffer 对象的 `#cleaner()` 方法，从而调用 `sun.misc.Cleaner#clean()` 方法，进行释放。
+  - 虽然实现略有不同，但是原理是一致的。感兴趣的胖友，自己看下 CleanerJava9 和 CleanerJava6 的实现代码。
+
+### 3.1.4 其它方法
+
+其他方法，和 [「2.2 PooledDirectByteBuf」](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 基本一致。
+
+## 3.2 UnpooledHeapByteBuf
+
+`io.netty.buffer.UnpooledHeapByteBuf` ，实现 AbstractReferenceCountedByteBuf 抽象类，对应 [「2.3 PooledHeapByteBuf」](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 的**非池化** ByteBuf 实现类。
+
+### 3.2.1 构造方法
+
+```
+/**
+ * ByteBuf 分配器对象
+ */
+private final ByteBufAllocator alloc;
+/**
+ * 字节数组
+ */
+byte[] array;
+/**
+ * 临时 ByteBuff 对象
+ */
+private ByteBuffer tmpNioBuf;
+
+public UnpooledHeapByteBuf(ByteBufAllocator alloc, int initialCapacity, int maxCapacity) {
+    // 设置最大容量
+    super(maxCapacity);
+
+    checkNotNull(alloc, "alloc");
+
+    if (initialCapacity > maxCapacity) {
+        throw new IllegalArgumentException(String.format(
+                "initialCapacity(%d) > maxCapacity(%d)", initialCapacity, maxCapacity));
+    }
+
+    this.alloc = alloc;
+
+    // 创建并设置字节数组
+    setArray(allocateArray(initialCapacity));
+
+    // 设置读写索引
+    setIndex(0, 0);
+}
+
+protected UnpooledHeapByteBuf(ByteBufAllocator alloc, byte[] initialArray, int maxCapacity) {
+    // 设置最大容量
+    super(maxCapacity);
+
+    checkNotNull(alloc, "alloc");
+    checkNotNull(initialArray, "initialArray");
+
+    if (initialArray.length > maxCapacity) {
+        throw new IllegalArgumentException(String.format(
+                "initialCapacity(%d) > maxCapacity(%d)", initialArray.length, maxCapacity));
+    }
+
+    this.alloc = alloc;
+
+    // 设置字节数组
+    setArray(initialArray);
+
+    // 设置读写索引
+    setIndex(0, initialArray.length);
+}
+```
+
+- 第一、二个构造方法的区别，后者字节数组是否从方法参数( `initialArray` )传递进来。
+
+- 调用 `#allocateArray(int initialCapacity)` 方法，创建字节数组。
+
+  ```
+  protected byte[] allocateArray(int initialCapacity) {
+      return new byte[initialCapacity];
+  }
+  ```
+
+- 调用 `#setArray(byte[] initialArray)` 方法，设置 `array` 属性。代码如下：
+
+  ```
+      private void setArray(byte[] initialArray) {
+          array = initialArray;
+          tmpNioBuf = null;
+      }
+      ```    
+  
+  ### 3.2.2 capacity
+  
+  `#capacity()` 方法，获得容量。代码如下：
+  
+  ```Java
+  @Override
+  public int capacity() {
+      return array.length;
+  }
+  ```
+
+- 使用字节数组的大小，作为当前容量上限。
+
+------
+
+`#capacity(int newCapacity)` 方法，调整容量大小。在这个过程中，根据情况，可能对 `array` 扩容或缩容。代码如下：
+
+```
+@Override
+public ByteBuf capacity(int newCapacity) {
+    // // 校验新的容量，不能超过最大容量
+    checkNewCapacity(newCapacity);
+
+    int oldCapacity = array.length;
+    byte[] oldArray = array;
+
+    // 扩容
+    if (newCapacity > oldCapacity) {
+        // 创建新数组
+        byte[] newArray = allocateArray(newCapacity);
+        // 复制【全部】数据到新数组
+        System.arraycopy(oldArray, 0, newArray, 0, oldArray.length);
+        // 设置数组
+        setArray(newArray);
+        // 释放老数组
+        freeArray(oldArray);
+    // 缩容
+    } else if (newCapacity < oldCapacity) {
+        // 创建新数组
+        byte[] newArray = allocateArray(newCapacity);
+        int readerIndex = readerIndex();
+        if (readerIndex < newCapacity) {
+            // 如果写索引超过新容量，需要重置下，设置为最大容量。否则就越界了。
+            int writerIndex = writerIndex();
+            if (writerIndex > newCapacity) {
+                writerIndex(writerIndex = newCapacity);
+            }
+            // 只复制【读取段】数据到新数组
+            System.arraycopy(oldArray, readerIndex, newArray, readerIndex, writerIndex - readerIndex);
+        } else {
+            // 因为读索引超过新容量，所以写索引超过新容量
+            // 如果读写索引都超过新容量，需要重置下，都设置为最大容量。否则就越界了。
+            setIndex(newCapacity, newCapacity);
+            // 这里要注意下，老的数据，相当于不进行复制，因为已经读取完了。
+        }
+        // 设置数组
+        setArray(newArray);
+        // 释放老数组
+        freeArray(oldArray);
+    }
+    return this;
+}
+```
+
+- 虽然代码比较长，实际很简单。胖友自己耐心看下注释进行理解下噢。😈 和 [「3.1.2 capacity」](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 基本一直的。
+
+### 3.2.3 deallocate
+
+`#deallocate()` 方法，当引用计数为 0 时，调用该方法，进行内存回收。代码如下：
+
+```
+@Override
+protected void deallocate() {
+    // 释放老数组
+    freeArray(array);
+    // 设置为空字节数组
+    array = EmptyArrays.EMPTY_BYTES;
+}
+```
+
+- `#freeArray(byte[] array)` 方法，释放数组。代码如下：
+
+  ```
+  protected void freeArray(byte[] array) {
+      // NOOP
+  }
+  ```
+
+  - 字节数组，无引用后，自然就会被 GC 回收。
+
+### 3.2.4 其它方法
+
+其它方法，和 [「2.3 PooledHeapByteBuf」](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 基本一致。
+
+## 3.3 UnpooledUnsafeDirectByteBuf
+
+`io.netty.buffer.UnpooledUnsafeDirectByteBuf` ，实现 AbstractReferenceCountedByteBuf 抽象类，对应 `「2.4 PooledUnsafeDirectByteBuf」` 的**非池化** ByteBuf 实现类。
+
+- 构造方法、`#capacity(...)` 方法、`#deallocate()` 方法，和 [「3.1 PooledDirectByteBuf」](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 基本一致。
+- 其它方法，和 [「2.4 PooledUnsafeDirectByteBuf」](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 基本一致。
+
+另外，UnpooledUnsafeDirectByteBuf 有一个子类 UnpooledUnsafeNoCleanerDirectByteBuf ，用于 `netty-microbench` 模块，进行基准测试。感兴趣的胖友，可以自己看看。
+
+## 3.4 UnpooledUnsafeHeapByteBuf
+
+`io.netty.buffer.UnpooledUnsafeHeapByteBuf` ，实现 AbstractReferenceCountedByteBuf 抽象类，对应 `「2.5 PooledUnsafeHeapByteBuf」` 的**非池化** ByteBuf 实现类。
+
+- 构造方法、`#capacity(...)` 方法、`#deallocate()` 方法，和 [「3.2 PooledHeapByteBuf」](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 基本一致。
+- 其它方法，和 [「2.5 PooledUnsafeHeapByteBuf」](https://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/#) 基本一致。
+
+## 3.5 ThreadLocal ByteBuf
+
+> 老艿艿：这是本文的拓展内容。
+
+虽然 UnpooledByteBuf 不基于**对象池**实现，但是考虑到 NIO Direct ByteBuffer 申请的成本是比较高的，所以基于 ThreadLocal + Recycler 实现重用。
+
+`ByteBufUtil#threadLocalDirectBuffer()` 方法，创建 ThreadLocal ByteBuf 对象。代码如下：
+
+```
+private static final int THREAD_LOCAL_BUFFER_SIZE;
+static {
+    THREAD_LOCAL_BUFFER_SIZE = SystemPropertyUtil.getInt("io.netty.threadLocalDirectBufferSize", 0);
+}
+
+/**
+ * Returns a cached thread-local direct buffer, if available.
+ *
+ * @return a cached thread-local direct buffer, if available.  {@code null} otherwise.
+ */
+public static ByteBuf threadLocalDirectBuffer() {
+    if (THREAD_LOCAL_BUFFER_SIZE <= 0) {
+        return null;
+    }
+
+    if (PlatformDependent.hasUnsafe()) {
+        return ThreadLocalUnsafeDirectByteBuf.newInstance();
+    } else {
+        return ThreadLocalDirectByteBuf.newInstance();
+    }
+}
+```
+
+- `THREAD_LOCAL_BUFFER_SIZE` **静态**属性，通过 `"io.netty.threadLocalDirectBufferSize"` 配置，默认为 0 。也就是说，实际 `#threadLocalDirectBuffer()` 方法，返回 `null` ，不开启 ThreadLocal ByteBuf 的功能。
+- 根据是否支持 Unsafe 操作，创建 ThreadLocalUnsafeDirectByteBuf 或 ThreadLocalDirectByteBuf 对象。
+
+### 3.5.1 ThreadLocalUnsafeDirectByteBuf
+
+ThreadLocalUnsafeDirectByteBuf ，在 ByteBufUtil 的**内部静态类**，继承 UnpooledUnsafeDirectByteBuf 类。代码如下：
+
+```
+static final class ThreadLocalUnsafeDirectByteBuf extends UnpooledUnsafeDirectByteBuf {
+
+    /**
+     * Recycler 对象
+     */
+    private static final Recycler<ThreadLocalUnsafeDirectByteBuf> RECYCLER =
+            new Recycler<ThreadLocalUnsafeDirectByteBuf>() {
+                @Override
+                protected ThreadLocalUnsafeDirectByteBuf newObject(Handle<ThreadLocalUnsafeDirectByteBuf> handle) {
+                    return new ThreadLocalUnsafeDirectByteBuf(handle);
+                }
+            };
+
+    static ThreadLocalUnsafeDirectByteBuf newInstance() {
+        // 从 RECYCLER 中，获得 ThreadLocalUnsafeDirectByteBuf 对象
+        ThreadLocalUnsafeDirectByteBuf buf = RECYCLER.get();
+        // 初始化 ref 为 1
+        buf.setRefCnt(1);
+        return buf;
+    }
+
+    /**
+     * Recycler 处理器
+     */
+    private final Handle<ThreadLocalUnsafeDirectByteBuf> handle;
+
+    private ThreadLocalUnsafeDirectByteBuf(Handle<ThreadLocalUnsafeDirectByteBuf> handle) {
+        super(UnpooledByteBufAllocator.DEFAULT, 256, Integer.MAX_VALUE);
+        this.handle = handle;
+    }
+
+    @Override
+    protected void deallocate() {
+        if (capacity() > THREAD_LOCAL_BUFFER_SIZE) { // <1>
+            // 释放
+            super.deallocate();
+        } else {
+            // 清空
+            clear();
+            // 回收对象
+            handle.recycle(this);
+        }
+    }
+}
+```
+
+- 在 `<1>` 处，我们可以看到，只有 ByteBuffer 容量小于 `THREAD_LOCAL_BUFFER_SIZE` 时，才会重用 ByteBuffer 对象。
+
+### 3.5.2 ThreadLocalDirectByteBuf
+
+ThreadLocalUnsafeDirectByteBuf ，在 ByteBufUtil 的**内部静态类**，继承 UnpooledDirectByteBuf 类。代码如下：
+
+```
+static final class ThreadLocalDirectByteBuf extends UnpooledDirectByteBuf {
+
+    /**
+     * Recycler 对象
+     */
+    private static final Recycler<ThreadLocalDirectByteBuf> RECYCLER = new Recycler<ThreadLocalDirectByteBuf>() {
+        @Override
+        protected ThreadLocalDirectByteBuf newObject(Handle<ThreadLocalDirectByteBuf> handle) {
+            return new ThreadLocalDirectByteBuf(handle);
+        }
+    };
+
+    static ThreadLocalDirectByteBuf newInstance() {
+        // 从 RECYCLER 中，获得 ThreadLocalUnsafeDirectByteBuf 对象
+        ThreadLocalDirectByteBuf buf = RECYCLER.get();
+        // 初始化 ref 为 1
+        buf.setRefCnt(1);
+        return buf;
+    }
+
+    /**
+     * Recycler 处理器
+     */
+    private final Handle<ThreadLocalDirectByteBuf> handle;
+
+    private ThreadLocalDirectByteBuf(Handle<ThreadLocalDirectByteBuf> handle) {
+        super(UnpooledByteBufAllocator.DEFAULT, 256, Integer.MAX_VALUE);
+        this.handle = handle;
+    }
+
+    @Override
+    protected void deallocate() {
+        if (capacity() > THREAD_LOCAL_BUFFER_SIZE) {
+            // 释放
+            super.deallocate();
+        } else {
+            // 清理
+            clear();
+            // 回收
+            handle.recycle(this);
+        }
+    }
+}
+```
+
+## 3.6 WrappedUnpooledUnsafeDirectByteBuf
+
+> 老艿艿：这是本文的拓展内容。
+
+`io.netty.buffer.WrappedUnpooledUnsafeDirectByteBuf` ，继承 UnpooledUnsafeDirectByteBuf 类，基于 `memoryAddress` 内存地址，创建 Direct ByteBuf 对象。代码如下：
+
+```
+final class WrappedUnpooledUnsafeDirectByteBuf extends UnpooledUnsafeDirectByteBuf {
+
+    // 基于 memoryAddress 内存地址，创建 Direct ByteBuf 对象
+    WrappedUnpooledUnsafeDirectByteBuf(ByteBufAllocator alloc, long memoryAddress, int size, boolean doFree) {
+        super(alloc, PlatformDependent.directBuffer(memoryAddress, size) /** 创建 Direct ByteBuf 对象 **/, size, doFree);
+    }
+
+    @Override
+    protected void freeDirect(ByteBuffer buffer) {
+        PlatformDependent.freeMemory(memoryAddress);
+    }
+
+}
+```
+
+> FROM [《Netty源码分析（一） ByteBuf》](https://www.jianshu.com/p/b833254908f7)
+>
+> 创建一个指定内存地址的UnpooledUnsafeDirectByteBuf，该内存块可能已被写入数据以减少一步拷贝操作。
+
+# 666. 彩蛋
+
+每次这种 N 多实现类的源码解析，写到 60% 的时候，就特别头疼。不是因为难写，是因为基本是组合排列，不断在啰嗦啰嗦啰嗦的感觉。
+
+嗯嗯，如果有地方写的错乱，烦请指出。默默再 review 几遍。
+
+------
+
+推荐阅读文章：
+
+- HryReal [《PooledByteBuf源码分析》](https://blog.csdn.net/qq_33394088/article/details/72763305)
+- 江南白衣 [《Netty之Java堆外内存扫盲贴》](http://calvin1978.blogcn.com/articles/directbytebuffer.html)
\ No newline at end of file
diff --git a/netty/37-Netty 源码解析-Buffer 之 ByteBuf（三）内存泄露检测.assets/01.png b/netty/37-Netty 源码解析-Buffer 之 ByteBuf（三）内存泄露检测.assets/01.png
new file mode 100644
index 0000000..2239a32
Binary files /dev/null and b/netty/37-Netty 源码解析-Buffer 之 ByteBuf（三）内存泄露检测.assets/01.png differ
diff --git a/netty/37-Netty 源码解析-Buffer 之 ByteBuf（三）内存泄露检测.md b/netty/37-Netty 源码解析-Buffer 之 ByteBuf（三）内存泄露检测.md
new file mode 100644
index 0000000..3664a45
--- /dev/null
+++ b/netty/37-Netty 源码解析-Buffer 之 ByteBuf（三）内存泄露检测.md	
@@ -0,0 +1,1741 @@
+# 精尽 Netty 源码解析 —— Buffer 之 ByteBuf（三）内存泄露检测
+
+# 1. 概述
+
+在本文，我们来分享 Netty 的**内存泄露检测**的实现机制。考虑到胖友更好的理解本文，请先阅读江南白衣大大的 [《Netty 之有效规避内存泄漏》](http://calvin1978.blogcn.com/articles/netty-leak.html) 。
+
+因为江南白衣大大在文章中，已经很清晰的讲解了概念与原理，笔者就不班门弄斧，直接上手，撸源码。
+
+# 2. ReferenceCounted
+
+> FROM [《【Netty官方文档翻译】引用计数对象（reference counted objects）》](http://damacheng009.iteye.com/blog/2013657)
+>
+> 自从 Netty 4 开始，对象的生命周期由它们的引用计数( reference counts )管理，而不是由垃圾收集器( garbage collector )管理了。**ByteBuf 是最值得注意的，它使用了引用计数来改进分配内存和释放内存的性能**。
+
+在 Netty 中，通过 `io.netty.util.ReferenceCounted` **接口**，定义了引用计数相关的一系列操作。代码如下：
+
+```
+public interface ReferenceCounted {
+
+    /**
+     * 获得引用计数
+     *
+     * Returns the reference count of this object.  If {@code 0}, it means this object has been deallocated.
+     */
+    int refCnt();
+
+    /**
+     * 增加引用计数 1
+     *
+     * Increases the reference count by {@code 1}.
+     */
+    ReferenceCounted retain();
+    /**
+     * 增加引用计数 n
+     *
+     * Increases the reference count by the specified {@code increment}.
+     */
+    ReferenceCounted retain(int increment);
+
+    /**
+     * 等价于调用 `#touch(null)` 方法，即 hint 方法参数传递为 null 。
+     *
+     * Records the current access location of this object for debugging purposes.
+     * If this object is determined to be leaked, the information recorded by this operation will be provided to you
+     * via {@link ResourceLeakDetector}.  This method is a shortcut to {@link #touch(Object) touch(null)}.
+     */
+    ReferenceCounted touch();
+    /**
+     * 出于调试目的,用一个额外的任意的(arbitrary)信息记录这个对象的当前访问地址. 如果这个对象被检测到泄露了, 这个操作记录的信息将通过ResourceLeakDetector 提供.
+     *
+     * Records the current access location of this object with an additional arbitrary information for debugging
+     * purposes.  If this object is determined to be leaked, the information recorded by this operation will be
+     * provided to you via {@link ResourceLeakDetector}.
+     */
+    ReferenceCounted touch(Object hint);
+
+    /**
+     * 减少引用计数 1 。
+     * 当引用计数为 0 时，释放
+     *
+     * Decreases the reference count by {@code 1} and deallocates this object if the reference count reaches at
+     * {@code 0}.
+     *
+     * @return {@code true} if and only if the reference count became {@code 0} and this object has been deallocated
+     */
+    boolean release();
+    /**
+     * 减少引用计数 n 。
+     *  当引用计数为 0 时，释放
+     *
+     * Decreases the reference count by the specified {@code decrement} and deallocates this object if the reference
+     * count reaches at {@code 0}.
+     *
+     * @return {@code true} if and only if the reference count became {@code 0} and this object has been deallocated
+     */
+    boolean release(int decrement);
+}
+```
+
+- `#refCnt()`、`#retain(...)`、`#release(...)` 三种方法比较好理解，对引用指数的获取与增减。
+- `#touch(...)` 方法，主动记录一个 `hint` 给 ResourceLeakDetector ，方便我们在发现内存泄露有更多的信息进行排查。详细的，在下文 ResourceLeakDetector 相关的内容，具体来看。
+
+------
+
+ReferenceCounted 的直接子类 / 子接口有两个 ：
+
+- `io.netty.buffer.ByteBuf` 。所以，所有 ByteBuf 实现类，都支持引用计数的操作。
+
+- ```
+  io.netty.util.AbstractReferenceCounted
+  ```
+
+   
+
+  ，ReferenceCounted 的抽象实现类。它的子类实现类，主要是除了 ByteBuf 之外，需要引用计数的操作的类。例如：AbstractHttpData、DefaultFileRegion 等等。
+
+  - AbstractReferenceCounted 不是本文的重点，就不多做介绍。
+  - AbstractReferenceCounted 的具体代码实现，在下文中，我们会看到和 `io.netty.buffer.AbstractReferenceCountedByteBuf` 基本差不多。
+
+# 3. ByteBuf
+
+ByteBuf 虽然继承了 ReferenceCounted 接口，但是并未实现相应的方法。那么真正实现与相关的类，如下图所示：[![类图](37-Netty 源码解析-Buffer 之 ByteBuf（三）内存泄露检测.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_08_07/01.png)类图
+
+- 黄框
+  - AbstractReferenceCountedByteBuf ，实现引用计数的获取与增减的操作。
+- 红框
+  - WrappedByteBuf ，实现对 ByteBuf 的装饰器实现类。
+  - WrappedCompositeByteBuf ，实现对 CompositeByteBuf 的装饰器实现类。
+- 绿框
+  - SimpleLeakAwareByteBuf、SimpleLeakAwareCompositeByteBuf ，实现了 `SIMPLE` 级别的内存泄露检测。
+  - AdvancedLeakAwareByteBuf、AdvancedLeakAwareCompositeByteBuf ，实现了 `ADVANCED` 和 `PARANOID` 级别的内存泄露检测。
+- 蓝筐
+  - UnreleasableByteBuf ，用于阻止他人对装饰的 ByteBuf 的销毁，避免被错误销毁掉。
+
+因为带 `"Composite"` 类的代码实现，和不带的类( 例如 WrappedCompositeByteBuf 和 WrappedByteBuf )，实现代码基本一致，**所以本文只分享不带 `"Composite"` 的类**。
+
+## 3.1 创建 LeakAware ByteBuf 对象
+
+在前面的文章中，我们已经提到，ByteBufAllocator 可用于创建 ByteBuf 对象。创建的过程中，它会调用 `#toLeakAwareBuffer(...)` 方法，将 ByteBuf **装饰**成 LeakAware ( 可检测内存泄露 )的 ByteBuf 对象，代码如下：
+
+```
+// AbstractByteBufAllocator.java
+protected static ByteBuf toLeakAwareBuffer(ByteBuf buf) {
+    ResourceLeakTracker<ByteBuf> leak;
+    switch (ResourceLeakDetector.getLevel()) {
+        case SIMPLE:
+            leak = AbstractByteBuf.leakDetector.track(buf);
+            if (leak != null) {
+                buf = new SimpleLeakAwareByteBuf(buf, leak);
+            }
+            break;
+        case ADVANCED:
+        case PARANOID:
+            leak = AbstractByteBuf.leakDetector.track(buf);
+            if (leak != null) {
+                buf = new AdvancedLeakAwareByteBuf(buf, leak);
+            }
+            break;
+        default:
+            break;
+    }
+    return buf;
+}
+
+protected static CompositeByteBuf toLeakAwareBuffer(CompositeByteBuf buf) {
+    ResourceLeakTracker<ByteBuf> leak;
+    switch (ResourceLeakDetector.getLevel()) {
+        case SIMPLE:
+            leak = AbstractByteBuf.leakDetector.track(buf);
+            if (leak != null) {
+                buf = new SimpleLeakAwareCompositeByteBuf(buf, leak);
+            }
+            break;
+        case ADVANCED:
+        case PARANOID:
+            leak = AbstractByteBuf.leakDetector.track(buf);
+            if (leak != null) {
+                buf = new AdvancedLeakAwareCompositeByteBuf(buf, leak);
+            }
+            break;
+        default:
+            break;
+    }
+    return buf;
+}
+```
+
+- 有两个 `#toLeakAwareBuffer(...)` 方法，分别对应带 `"Composite"` 的 组合 ByteBuf 类，和不带 `Composite` 普通 ByteBuf 类。因为这个不同，所以前者创建的是 SimpleLeakAwareCompositeByteBuf / AdvancedLeakAwareCompositeByteBuf 对象，后者创建的是 SimpleLeakAwareByteBuf / AdvancedLeakAwareByteBuf 对象。
+
+- 当然，从总的逻辑来看，是
+
+  一致
+
+  的：
+
+  - `SIMPLE` 级别，创建 SimpleLeakAwareByteBuf 或 SimpleLeakAwareCompositeByteBuf 对象。
+  - `ADVANCED` 和 `PARANOID` 级别，创建 AdvancedLeakAwareByteBuf 或者 AdvancedLeakAwareCompositeByteBuf 对象。
+
+- 是否需要创建 LeakAware ByteBuf 对象，有一个前提，调用
+
+   
+
+  ```
+  ResourceLeakDetector#track(ByteBuf)
+  ```
+
+   
+
+  方法，返回了 ResourceLeakTracker 对象。
+
+  - 虽然说， `ADVANCED` 和 `PARANOID` 级别，都使用了 AdvancedLeakAwareByteBuf 或 AdvancedLeakAwareCompositeByteBuf 对象，但是它们的差异是：1) `PARANOID` 级别，一定返回 ResourceLeakTracker 对象；2) `ADVANCED` 级别，随机概率( 默认为 `1%` 左右 )返回 ResourceLeakTracker 对象。
+  - 关于 `ResourceLeakDetector#track(ByteBuf)` 方法的实现，下文也会详细解析。
+
+## 3.2 AbstractReferenceCountedByteBuf
+
+`io.netty.buffer.AbstractReferenceCountedByteBuf` ，实现引用计数的获取与增减的操作。
+
+### 3.2.1 构造方法
+
+```
+/**
+ * {@link #refCnt} 的更新器
+ */
+private static final AtomicIntegerFieldUpdater<AbstractReferenceCountedByteBuf> refCntUpdater = AtomicIntegerFieldUpdater.newUpdater(AbstractReferenceCountedByteBuf.class, "refCnt");
+
+/**
+ * 引用计数
+ */
+private volatile int refCnt;
+
+protected AbstractReferenceCountedByteBuf(int maxCapacity) {
+    // 设置最大容量
+    super(maxCapacity);
+    // 初始 refCnt 为 1
+    refCntUpdater.set(this, 1);
+}
+```
+
+- 为什么 `refCnt` 不使用 AtomicInteger 呢？
+
+> 计数器基于 AtomicIntegerFieldUpdater ，为什么不直接用 AtomicInteger ？因为 ByteBuf 对象很多，如果都把 `int` 包一层 AtomicInteger 花销较大，而AtomicIntegerFieldUpdater 只需要一个全局的静态变量。
+
+### 3.2.2 refCnt
+
+```
+@Override
+public int refCnt() {
+    return refCnt;
+}
+```
+
+### 3.2.3 setRefCnt
+
+`#setRefCnt(int refCnt)` 方法，直接修改 `refCnt` 。代码如下：
+
+```
+/**
+ * An unsafe operation intended for use by a subclass that sets the reference count of the buffer directly
+ */
+protected final void setRefCnt(int refCnt) {
+    refCntUpdater.set(this, refCnt);
+}
+```
+
+### 3.2.4 retain
+
+```
+@Override
+public ByteBuf retain(int increment) {
+    return retain0(checkPositive(increment, "increment"));
+}
+
+private ByteBuf retain0(final int increment) {
+    // 增加
+    int oldRef = refCntUpdater.getAndAdd(this, increment);
+    // 原有 refCnt 就是 <= 0 ；或者，increment 为负数
+    if (oldRef <= 0 || oldRef + increment < oldRef) {
+        // Ensure we don't resurrect (which means the refCnt was 0) and also that we encountered an overflow.
+        // 加回去，负负得正。
+        refCntUpdater.getAndAdd(this, -increment);
+        // 抛出 IllegalReferenceCountException 异常
+        throw new IllegalReferenceCountException(oldRef, increment);
+    }
+    return this;
+}
+```
+
+### 3.2.5 release
+
+```
+@Override
+public boolean release() {
+    return release0(1);
+}
+
+@Override
+public boolean release(int decrement) {
+    return release0(checkPositive(decrement, "decrement"));
+}
+
+@SuppressWarnings("Duplicates")
+private boolean release0(int decrement) {
+    // 减少
+    int oldRef = refCntUpdater.getAndAdd(this, -decrement);
+    // 原有 oldRef 等于减少的值
+    if (oldRef == decrement) {
+        // 释放
+        deallocate();
+        return true;
+        // 减少的值得大于 原有 oldRef ，说明“越界”；或者，increment 为负数
+    } else if (oldRef < decrement || oldRef - decrement > oldRef) {
+        // Ensure we don't over-release, and avoid underflow.
+        // 加回去，负负得正。
+        refCntUpdater.getAndAdd(this, decrement);
+        // 抛出 IllegalReferenceCountException 异常
+        throw new IllegalReferenceCountException(oldRef, -decrement);
+    }
+    return false;
+}
+```
+
+- 当释放完成，即 `refCnt` 等于 0 时，调用 `#deallocate()` 方法，进行**真正的释放**。这是个**抽象方法**，需要子类去实现。代码如下：
+
+  ```
+  /**
+   * Called once {@link #refCnt()} is equals 0.
+   */
+  protected abstract void deallocate();
+  ```
+
+  - 在 [《精尽 Netty 源码解析 —— Buffer 之 ByteBuf（二）核心子类》](http://svip.iocoder.cn/Netty/ByteBuf-1-2-ByteBuf-core-impl/) 中，可以看到各种 ByteBuf 对 `#deallocate()` 方法的实现。
+
+### 3.2.6 touch
+
+```
+@Override
+public ByteBuf touch() {
+    return this;
+}
+
+@Override
+public ByteBuf touch(Object hint) {
+    return this;
+}
+```
+
+一脸懵逼？！实际 AbstractReferenceCountedByteBuf **并未**实现 `#touch(...)` 方法。而是在 AdvancedLeakAwareByteBuf 中才实现。
+
+## 3.3 SimpleLeakAwareByteBuf
+
+`io.netty.buffer.SimpleLeakAwareByteBuf` ，继承 WrappedByteBuf 类，`Simple` 级别的 LeakAware ByteBuf 实现类。
+
+### 3.3.1 构造方法
+
+```
+/**
+ * 关联的 ByteBuf 对象
+ *
+ * This object's is associated with the {@link ResourceLeakTracker}. When {@link ResourceLeakTracker#close(Object)}
+ * is called this object will be used as the argument. It is also assumed that this object is used when
+ * {@link ResourceLeakDetector#track(Object)} is called to create {@link #leak}.
+ */
+private final ByteBuf trackedByteBuf;
+/**
+ * ResourceLeakTracker 对象
+ */
+final ResourceLeakTracker<ByteBuf> leak;
+
+SimpleLeakAwareByteBuf(ByteBuf wrapped, ByteBuf trackedByteBuf, ResourceLeakTracker<ByteBuf> leak) { // <2>
+    super(wrapped);
+    this.trackedByteBuf = ObjectUtil.checkNotNull(trackedByteBuf, "trackedByteBuf");
+    this.leak = ObjectUtil.checkNotNull(leak, "leak");
+}
+
+SimpleLeakAwareByteBuf(ByteBuf wrapped, ResourceLeakTracker<ByteBuf> leak) { // <1>
+    this(wrapped, wrapped, leak);
+}
+```
+
+- `leak` 属性，ResourceLeakTracker 对象。
+
+- ```
+  trackedByteBuf
+  ```
+
+   
+
+  属性，
+
+  真正
+
+  关联
+
+   
+
+  ```
+  leak
+  ```
+
+   
+
+  的 ByteBuf 对象。
+
+  - 对于构造方法 `<1>` ，`wrapped` 和 `trackedByteBuf` **相同**。
+  - 对于构造方法 `<2>` ，`wrapped` 和 `trackedByteBuf` **一般不同**。
+  - 有点难理解？继续往下看。
+
+### 3.3.2 slice
+
+```
+@Override
+public ByteBuf slice() {
+    return newSharedLeakAwareByteBuf(super.slice());
+}
+
+@Override
+public ByteBuf slice(int index, int length) {
+    return newSharedLeakAwareByteBuf(super.slice(index, length));
+}
+```
+
+- 首先，调用**父** `#slice(...)` 方法，获得 **slice** ByteBuf 对象。
+
+- 之后，因为 **slice** ByteBuf 对象，并不是一个 LeakAware 的 ByteBuf 对象。所以调用 `#newSharedLeakAwareByteBuf(ByteBuf wrapped)` 方法，装饰成 LeakAware 的 ByteBuf 对象。代码如下：
+
+  ```
+  private SimpleLeakAwareByteBuf newSharedLeakAwareByteBuf(ByteBuf wrapped) {
+      return newLeakAwareByteBuf(wrapped, trackedByteBuf /** <1> **/, leak);
+  }
+  
+  protected SimpleLeakAwareByteBuf newLeakAwareByteBuf(ByteBuf buf, ByteBuf trackedByteBuf, ResourceLeakTracker<ByteBuf> leakTracker) {
+      return new SimpleLeakAwareByteBuf(buf, trackedByteBuf /** <1> **/, leakTracker);
+  }
+  ```
+
+  - 从 `<1>` 处，我们可以看到，`trackedByteBuf` 代表的是**原始的** ByteBuf 对象，它是跟 `leak` 真正进行关联的。而 `wrapped` 则不是。
+
+------
+
+在 SimpleLeakAwareByteBuf 中，还有如下方法，和 `#slice(...)` 方法是**类似**的，在调用完**父**对应的方法后，再调用 `#newSharedLeakAwareByteBuf(ByteBuf wrapped)` 方法，装饰成 LeakAware 的 ByteBuf 对象。整理如下：
+
+```
+@Override
+public ByteBuf duplicate() {
+    return newSharedLeakAwareByteBuf(super.duplicate());
+}
+
+@Override
+public ByteBuf readSlice(int length) {
+    return newSharedLeakAwareByteBuf(super.readSlice(length));
+}
+
+@Override
+public ByteBuf asReadOnly() {
+    return newSharedLeakAwareByteBuf(super.asReadOnly());
+}
+
+@Override
+public ByteBuf order(ByteOrder endianness) {
+    if (order() == endianness) {
+        return this;
+    } else {
+        return newSharedLeakAwareByteBuf(super.order(endianness));
+    }
+}
+```
+
+### 3.3.3 retainedSlice
+
+```
+@Override
+public ByteBuf retainedSlice() {
+    return unwrappedDerived(super.retainedSlice());
+}
+
+@Override
+public ByteBuf retainedSlice(int index, int length) {
+    return unwrappedDerived(super.retainedSlice(index, length));
+}
+```
+
+- 首先，调用**父** `#retainedSlice(...)` 方法，获得 **slice** ByteBuf 对象，引用计数加 1。
+
+- 之后，因为 **slice** ByteBuf 对象，并不是一个 LeakAware 的 ByteBuf 对象。所以调用 `#unwrappedDerived(ByteBuf wrapped)` 方法，装饰成 LeakAware 的 ByteBuf 对象。代码如下：
+
+  ```
+  // TODO 芋艿，看不懂 1017
+  private ByteBuf unwrappedDerived(ByteBuf derived) {
+      // We only need to unwrap SwappedByteBuf implementations as these will be the only ones that may end up in
+      // the AbstractLeakAwareByteBuf implementations beside slices / duplicates and "real" buffers.
+      ByteBuf unwrappedDerived = unwrapSwapped(derived);
+  
+      if (unwrappedDerived instanceof AbstractPooledDerivedByteBuf) {
+          // Update the parent to point to this buffer so we correctly close the ResourceLeakTracker.
+          ((AbstractPooledDerivedByteBuf) unwrappedDerived).parent(this);
+  
+          ResourceLeakTracker<ByteBuf> newLeak = AbstractByteBuf.leakDetector.track(derived);
+          if (newLeak == null) {
+              // No leak detection, just return the derived buffer.
+              return derived;
+          }
+          return newLeakAwareByteBuf(derived, newLeak);
+      }
+      return newSharedLeakAwareByteBuf(derived);
+  }
+  
+  @SuppressWarnings("deprecation")
+  private static ByteBuf unwrapSwapped(ByteBuf buf) {
+      if (buf instanceof SwappedByteBuf) {
+          do {
+              buf = buf.unwrap();
+          } while (buf instanceof SwappedByteBuf);
+  
+          return buf;
+      }
+      return buf;
+  }
+  
+  private SimpleLeakAwareByteBuf newLeakAwareByteBuf(ByteBuf wrapped, ResourceLeakTracker<ByteBuf> leakTracker) {
+      return newLeakAwareByteBuf(wrapped, wrapped, leakTracker);
+  }
+  ```
+
+  - TODO 1017
+
+------
+
+在 SimpleLeakAwareByteBuf 中，还有如下方法，和 `#retainedSlice(...)` 方法是**类似**的，在调用完**父**对应的方法后，再调用 `#unwrappedDerived(ByteBuf derived)` 方法，装饰成 LeakAware 的 ByteBuf 对象。整理如下：
+
+```
+@Override
+public ByteBuf retainedDuplicate() {
+    return unwrappedDerived(super.retainedDuplicate());
+}
+
+@Override
+public ByteBuf readRetainedSlice(int length) {
+    return unwrappedDerived(super.readRetainedSlice(length));
+}
+```
+
+### 3.3.4 release
+
+```
+@Override
+public boolean release() {
+    if (super.release()) { // 释放完成
+        closeLeak();
+        return true;
+    }
+    return false;
+}
+
+@Override
+public boolean release(int decrement) {
+    if (super.release(decrement)) { // 释放完成
+        closeLeak();
+        return true;
+    }
+    return false;
+}
+```
+
+- 在调用**父** `#release(...)` 方法，释放完成后，会调用 `#closeLeak()` 方法，关闭 ResourceLeakTracker 。代码如下：
+
+  ```
+  private void closeLeak() {
+      // Close the ResourceLeakTracker with the tracked ByteBuf as argument. This must be the same that was used when
+      // calling DefaultResourceLeak.track(...).
+      boolean closed = leak.close(trackedByteBuf);
+      assert closed;
+  }
+  ```
+
+```
+* 进一步的详细解析，可以看看 [「5.1.5 close」](#) 。
+```
+
+### 3.3.5 touch
+
+```
+@Override
+public ByteBuf touch() {
+    return this;
+}
+
+@Override
+public ByteBuf touch(Object hint) {
+    return this;
+}
+```
+
+又一脸懵逼？！实际 SimpleLeakAwareByteBuf **也并未**实现 `#touch(...)` 方法。而是在 AdvancedLeakAwareByteBuf 中才实现。
+
+## 3.4 AdvancedLeakAwareByteBuf
+
+`io.netty.buffer.AdvancedLeakAwareByteBuf` ，继承 SimpleLeakAwareByteBuf 类，`ADVANCED` 和 `PARANOID` 级别的 LeakAware ByteBuf 实现类。
+
+### 3.4.1 构造方法
+
+```
+AdvancedLeakAwareByteBuf(ByteBuf buf, ResourceLeakTracker<ByteBuf> leak) {
+    super(buf, leak);
+}
+
+AdvancedLeakAwareByteBuf(ByteBuf wrapped, ByteBuf trackedByteBuf, ResourceLeakTracker<ByteBuf> leak) {
+    super(wrapped, trackedByteBuf, leak);
+}
+```
+
+就是调用父构造方法，没啥特点。
+
+### 3.4.2 retain
+
+```
+@Override
+public ByteBuf retain() {
+    leak.record();
+    return super.retain();
+}
+
+@Override
+public ByteBuf retain(int increment) {
+    leak.record();
+    return super.retain(increment);
+}
+```
+
+- 会调用 `ResourceLeakTracer#record()` 方法，记录信息。
+
+### 3.4.3 release
+
+```
+@Override
+public boolean release() {
+    leak.record();
+    return super.release();
+}
+
+@Override
+public boolean release(int decrement) {
+    leak.record();
+    return super.release(decrement);
+}
+```
+
+- 会调用 `ResourceLeakTracer#record()` 方法，记录信息。
+
+### 3.4.4 touch
+
+```
+@Override
+public ByteBuf touch() {
+    leak.record();
+    return this;
+}
+
+@Override
+public ByteBuf touch(Object hint) {
+    leak.record(hint);
+    return this;
+}
+```
+
+- 会调用 `ResourceLeakTracer#record(...)` 方法，记录信息。
+- 😈 `#touch(...)` 方法，终于实现了，哈哈哈。
+
+### 3.4.5 recordLeakNonRefCountingOperation
+
+`#recordLeakNonRefCountingOperation(ResourceLeakTracker<ByteBuf> leak)` **静态**方法，除了引用计数操作相关( 即 `#retain(...)`/`#release(...)`/`#touch(...)` 方法 )方法外，是否要调用记录信息。代码如下：
+
+```
+private static final String PROP_ACQUIRE_AND_RELEASE_ONLY = "io.netty.leakDetection.acquireAndReleaseOnly";
+/**
+ * 默认为
+ */
+private static final boolean ACQUIRE_AND_RELEASE_ONLY;
+
+static {
+    ACQUIRE_AND_RELEASE_ONLY = SystemPropertyUtil.getBoolean(PROP_ACQUIRE_AND_RELEASE_ONLY, false);
+}
+
+static void recordLeakNonRefCountingOperation(ResourceLeakTracker<ByteBuf> leak) {
+    if (!ACQUIRE_AND_RELEASE_ONLY) {
+        leak.record();
+    }
+}
+```
+
+- 负负得正，所以会调用 `ResourceLeakTracer#record(...)` 方法，记录信息。
+
+- 也就是说，ByteBuf 的所有方法，都会记录信息。例如：
+
+  ```
+  @Override
+  public ByteBuf order(ByteOrder endianness) {
+      recordLeakNonRefCountingOperation(leak);
+      return super.order(endianness);
+  }
+  
+  @Override
+  public int readIntLE() {
+      recordLeakNonRefCountingOperation(leak);
+      return super.readIntLE();
+  }
+  ```
+
+  - 方法比较多，就不一一列举了。
+
+### 3.4.6 newLeakAwareByteBuf
+
+`#newLeakAwareByteBuf(ByteBuf buf, ByteBuf trackedByteBuf, ResourceLeakTracker<ByteBuf> leakTracker)` 方法，覆写父类方法，将原先装饰成 SimpleLeakAwareByteBuf 改成 AdvancedLeakAwareByteBuf 对象。代码如下:
+
+```
+@Override
+protected AdvancedLeakAwareByteBuf newLeakAwareByteBuf(
+        ByteBuf buf, ByteBuf trackedByteBuf, ResourceLeakTracker<ByteBuf> leakTracker) {
+    return new AdvancedLeakAwareByteBuf(buf, trackedByteBuf, leakTracker);
+}
+```
+
+## 3.5 UnreleasableByteBuf
+
+`io.netty.buffer.UnreleasableByteBuf` ，继承 WrappedByteBuf 类，用于阻止他人对装饰的 ByteBuf 的销毁，避免被错误销毁掉。
+
+它的实现方法比较简单，主要是两大点：
+
+- 引用计数操作相关( 即 `#retain(...)`/`#release(...)`/`#touch(...)` 方法 )方法，不进行调用。代码如下：
+
+  ```
+  @Override
+  public ByteBuf retain(int increment) {
+      return this;
+  }
+  @Override
+  public ByteBuf retain() {
+      return this;
+  }
+  
+  @Override
+  public ByteBuf touch() {
+      return this;
+  }
+  @Override
+  public ByteBuf touch(Object hint) {
+      return this;
+  }
+  
+  @Override
+  public boolean release() {
+      return false;
+  }
+  @Override
+  public boolean release(int decrement) {
+      return false;
+  }
+  ```
+
+- 拷贝操作相关方法，都会在包一层 UnreleasableByteBuf 对象。例如：
+
+  ```
+  @Override
+  public ByteBuf slice() {
+      return new UnreleasableByteBuf(buf.slice());
+  }
+  ```
+
+# 4. ResourceLeakDetector
+
+`io.netty.util.ResourceLeakDetector` ，内存泄露检测器。
+
+> 老艿艿：Resource 翻译成“资源”更合理。考虑到标题叫做《内存泄露检测》，包括互联网其他作者在关于这块内容的命名，也是叫做“内存泄露检测”。所以，在下文，Resource 笔者还是继续翻译成“资源”。
+
+ResourceLeakDetector 为了检测内存是否泄漏，使用了 WeakReference( 弱引用 )和 ReferenceQueue( 引用队列 )，过程如下：
+
+1. 根据检测级别和采样率的设置，在需要时为需要检测的 ByteBuf 创建WeakReference 引用。
+2. 当 JVM 回收掉 ByteBuf 对象时，JVM 会将 WeakReference 放入ReferenceQueue 队列中。
+3. 通过对 ReferenceQueue 中 WeakReference 的检查，判断在 GC 前是否有释放ByteBuf 的资源，就可以知道是否有资源释放。
+
+😈 看不太懂？继续往下看代码，在回过头来理解理解。
+
+## 4.1 静态属性
+
+```
+private static final String PROP_LEVEL_OLD = "io.netty.leakDetectionLevel";
+private static final String PROP_LEVEL = "io.netty.leakDetection.level";
+/**
+ * 默认内存检测级别
+ */
+private static final Level DEFAULT_LEVEL = Level.SIMPLE;
+
+private static final String PROP_TARGET_RECORDS = "io.netty.leakDetection.targetRecords";
+private static final int DEFAULT_TARGET_RECORDS = 4;
+
+/**
+ * 每个 DefaultResourceLeak 记录的 Record 数量
+ */
+private static final int TARGET_RECORDS;
+
+/**
+ * 内存检测级别枚举
+ * 
+ * Represents the level of resource leak detection.
+ */
+public enum Level {
+    /**
+     * Disables resource leak detection.
+     */
+    DISABLED,
+    /**
+     * Enables simplistic sampling resource leak detection which reports there is a leak or not,
+     * at the cost of small overhead (default).
+     */
+    SIMPLE,
+    /**
+     * Enables advanced sampling resource leak detection which reports where the leaked object was accessed
+     * recently at the cost of high overhead.
+     */
+    ADVANCED,
+    /**
+     * Enables paranoid resource leak detection which reports where the leaked object was accessed recently,
+     * at the cost of the highest possible overhead (for testing purposes only).
+     */
+    PARANOID;
+
+    /**
+     * Returns level based on string value. Accepts also string that represents ordinal number of enum.
+     *
+     * @param levelStr - level string : DISABLED, SIMPLE, ADVANCED, PARANOID. Ignores case.
+     * @return corresponding level or SIMPLE level in case of no match.
+     */
+    static Level parseLevel(String levelStr) {
+        String trimmedLevelStr = levelStr.trim();
+        for (Level l : values()) {
+            if (trimmedLevelStr.equalsIgnoreCase(l.name()) || trimmedLevelStr.equals(String.valueOf(l.ordinal()))) {
+                return l;
+            }
+        }
+        return DEFAULT_LEVEL;
+    }
+}
+
+/**
+ * 内存泄露检测等级
+ */
+private static Level level;
+
+/**
+ * 默认采集频率
+ */
+// There is a minor performance benefit in TLR if this is a power of 2.
+static final int DEFAULT_SAMPLING_INTERVAL = 128;
+ 
+  1: static {
+  2:     // 获得是否禁用泄露检测
+  3:     final boolean disabled;
+  4:     if (SystemPropertyUtil.get("io.netty.noResourceLeakDetection") != null) {
+  5:         disabled = SystemPropertyUtil.getBoolean("io.netty.noResourceLeakDetection", false);
+  6:         logger.debug("-Dio.netty.noResourceLeakDetection: {}", disabled);
+  7:         logger.warn("-Dio.netty.noResourceLeakDetection is deprecated. Use '-D{}={}' instead.", PROP_LEVEL, DEFAULT_LEVEL.name().toLowerCase());
+  8:     } else {
+  9:         disabled = false;
+ 10:     }
+ 11: 
+ 12:     // 获得默认级别
+ 13:     Level defaultLevel = disabled? Level.DISABLED : DEFAULT_LEVEL;
+ 14:     // 获得配置的级别字符串，从老版本的配置
+ 15:     // First read old property name (兼容老版本）
+ 16:     String levelStr = SystemPropertyUtil.get(PROP_LEVEL_OLD, defaultLevel.name());
+ 17:     // 获得配置的级别字符串，从新版本的配置
+ 18:     // If new property name is present, use it
+ 19:     levelStr = SystemPropertyUtil.get(PROP_LEVEL, levelStr);
+ 20:     // 获得最终的级别
+ 21:     Level level = Level.parseLevel(levelStr);
+ 22:     // 设置最终的级别
+ 23:     ResourceLeakDetector.level = level;
+ 24: 
+ 25:     // 初始化 TARGET_RECORDS
+ 26:     TARGET_RECORDS = SystemPropertyUtil.getInt(PROP_TARGET_RECORDS, DEFAULT_TARGET_RECORDS);
+ 27: 
+ 28:     if (logger.isDebugEnabled()) {
+ 29:         logger.debug("-D{}: {}", PROP_LEVEL, level.name().toLowerCase());
+ 30:         logger.debug("-D{}: {}", PROP_TARGET_RECORDS, TARGET_RECORDS);
+ 31:     }
+ 32: }
+```
+
+- `level` **静态**属性，内存泄露等级。😈 不是说好了，静态变量要统一大写么。
+
+  - 默认级别为 `DEFAULT_LEVEL = Level.SIMPLE` 。
+
+  - 在 Level 中，枚举了四个级别。
+
+    > - 禁用（DISABLED） - 完全禁止泄露检测，省点消耗。
+    > - 简单（SIMPLE） - 默认等级，告诉我们取样的1%的ByteBuf是否发生了泄露，但总共一次只打印一次，看不到就没有了。
+    > - 高级（ADVANCED） - 告诉我们取样的1%的ByteBuf发生泄露的地方。每种类型的泄漏（创建的地方与访问路径一致）只打印一次。对性能有影响。
+    > - 偏执（PARANOID） - 跟高级选项类似，但此选项检测所有ByteBuf，而不仅仅是取样的那1%。对性能有绝大的影响。
+    >   - 看着有点懵逼？下面继续看代码。
+
+  - 在【第 2 至 23 行】的代码进行初始化。
+
+- ```
+  TARGET_RECORDS
+  ```
+
+   
+
+  静态属性，每个 DefaultResourceLeak 记录的 Record 数量。
+
+  - 默认大小为 `DEFAULT_TARGET_RECORDS = 4` 。
+  - 在【第 26 行】的代码进行初始化。
+
+- `DEFAULT_SAMPLING_INTERVAL` 静态属性，默认采集频率，128 。
+
+## 4.2 构造方法
+
+```
+/**
+ * DefaultResourceLeak 集合
+ *
+ * the collection of active resources
+ */
+private final ConcurrentMap<DefaultResourceLeak<?>, LeakEntry> allLeaks = PlatformDependent.newConcurrentHashMap();
+
+/**
+ * 引用队列
+ */
+private final ReferenceQueue<Object> refQueue = new ReferenceQueue<Object>();
+/**
+ * 已汇报的内存泄露的资源类型的集合
+ */
+private final ConcurrentMap<String, Boolean> reportedLeaks = PlatformDependent.newConcurrentHashMap();
+
+/**
+ * 资源类型
+ */
+private final String resourceType;
+/**
+ * 采集评率
+ */
+private final int samplingInterval;
+
+public ResourceLeakDetector(Class<?> resourceType, int samplingInterval) {
+    this(simpleClassName(resourceType) /** <1> **/, samplingInterval, Long.MAX_VALUE);
+}
+```
+
+- ```
+  allLeaks
+  ```
+
+   
+
+  属性，DefaultResourceLeak 集合。因为 Java 没有自带的 ConcurrentSet ，所以只好使用使用 ConcurrentMap 。也就是说，value 属性实际没有任何用途。
+
+  - 关于 LeakEntry ，可以看下 [「6. LeakEntry」](https://svip.iocoder.cn/Netty/ByteBuf-1-3-ByteBuf-resource-leak-detector/#) 。
+
+- `refQueue` 属性，就是我们提到的**引用队列**( ReferenceQueue 队列 )。
+
+- `reportedLeaks` 属性，已汇报的内存泄露的资源类型的集合。
+
+- `resourceType` 属性，资源类型，使用资源类的类名简写，见 `<1>` 处。
+
+- `samplingInterval` 属性，采集频率。
+
+------
+
+在 AbstractByteBuf 类中，我们可以看到创建了所有 ByteBuf 对象统一使用的 ResourceLeakDetector 对象。代码如下：
+
+```
+static final ResourceLeakDetector<ByteBuf> leakDetector = ResourceLeakDetectorFactory.instance().newResourceLeakDetector(ByteBuf.class);
+```
+
+- ResourceLeakDetector 的创建，通过
+
+   
+
+  ```
+  io.netty.util.ResourceLeakDetectorFactory
+  ```
+
+   
+
+  ，基于工厂模式的方式来创建。
+
+  - 关于 ResourceLeakDetectorFactory 的代码比较简单，笔者就不赘述了。
+  - 有一点要注意的是，可以通过 `"io.netty.customResourceLeakDetector"` 来**自定义** ResourceLeakDetector 的实现类。当然，绝大多数场景是完全不需要的。
+
+## 4.3 track
+
+`#track(...)` 方法，给指定资源( 例如 ByteBuf 对象 )创建一个检测它是否泄漏的 ResourceLeakTracker 对象。代码如下：
+
+```
+ 1: public final ResourceLeakTracker<T> track(T obj) {
+ 2:     return track0(obj);
+ 3: }
+ 4: 
+ 5: @SuppressWarnings("unchecked")
+ 6: private DefaultResourceLeak track0(T obj) {
+ 7:     Level level = ResourceLeakDetector.level;
+ 8:     // DISABLED 级别，不创建
+ 9:     if (level == Level.DISABLED) {
+10:         return null;
+11:     }
+12: 
+13:     // SIMPLE 和 ADVANCED
+14:     if (level.ordinal() < Level.PARANOID.ordinal()) {
+15:         // 随机
+16:         if ((PlatformDependent.threadLocalRandom().nextInt(samplingInterval)) == 0) {
+17:             // 汇报内存是否泄漏
+18:             reportLeak();
+19:             // 创建 DefaultResourceLeak 对象
+20:             return new DefaultResourceLeak(obj, refQueue, allLeaks);
+21:         }
+22:         return null;
+23:     }
+24: 
+25:     // PARANOID 级别
+26:     // 汇报内存是否泄漏
+27:     reportLeak();
+28:     // 创建 DefaultResourceLeak 对象
+29:     return new DefaultResourceLeak(obj, refQueue, allLeaks);
+30: }
+```
+
+- 第 8 至 11 行：`DISABLED` 级别时，不创建，直接返回 `null` 。
+- 第 13 至 23 行：`SIMPLE` 和 `ADVANCED` 级别时，随机，概率为 `1 / samplingInterval` ，创建 DefaultResourceLeak 对象。默认情况下 `samplingInterval = 128` ，约等于 `1%` ，这也是就为什么说“告诉我们取样的 1% 的ByteBuf发生泄露的地方”。
+- 第 27 至 29 行：`PARANOID` 级别时，一定创建 DefaultResourceLeak 对象。这也是为什么说“对性能有绝大的影响”。
+- 第 18 至 27 行：笔者原本以为，ResourceLeakDetector 会有一个定时任务，不断检测是否有内存泄露。从这里的代码来看，它是在每次一次创建 DefaultResourceLeak 对象时，调用 `#reportLeak()` 方法，汇报内存是否泄漏。详细解析，见 [「4.4 reportLeak」](https://svip.iocoder.cn/Netty/ByteBuf-1-3-ByteBuf-resource-leak-detector/#) 。
+
+## 4.4 reportLeak
+
+`#reportLeak()` 方法，检测是否有内存泄露。若有，则进行汇报。代码如下：
+
+```
+ 1: private void reportLeak() {
+ 2:     // 如果不允许打印错误日志，则无法汇报，清理队列，并直接结束。
+ 3:     if (!logger.isErrorEnabled()) {
+ 4:         // 清理队列
+ 5:         clearRefQueue();
+ 6:         return;
+ 7:     }
+ 8: 
+ 9:     // 循环引用队列，直到为空
+10:     // Detect and report previous leaks.
+11:     for (;;) {
+12:         @SuppressWarnings("unchecked")
+13:         DefaultResourceLeak ref = (DefaultResourceLeak) refQueue.poll();
+14:         if (ref == null) {
+15:             break;
+16:         }
+17: 
+18:         // 清理，并返回是否内存泄露
+19:         if (!ref.dispose()) {
+20:             continue;
+21:         }
+22: 
+23:         // 获得 Record 日志
+24:         String records = ref.toString();
+25:         // 相同 Record 日志，只汇报一次
+26:         if (reportedLeaks.putIfAbsent(records, Boolean.TRUE) == null) {
+27:             if (records.isEmpty()) {
+28:                 reportUntracedLeak(resourceType);
+29:             } else {
+30:                 reportTracedLeak(resourceType, records);
+31:             }
+32:         }
+33:     }
+34: }
+```
+
+- 第 2 至 7 行：如果不允许打印错误日志，则无法汇报，因此调用 `#clearRefQueue()` 方法，清理队列，并直接结束。详细解析，见 [「4.5 clearRefQueue」](https://svip.iocoder.cn/Netty/ByteBuf-1-3-ByteBuf-resource-leak-detector/#) 。
+
+- 第 9 至 16 行：循环引用队列 `refQueue` ，直到为空。
+
+- 第 18 至 21 行：调用 `DefaultResourceLeak#dispose()` 方法，清理，并返回是否内存泄露。如果未泄露，就直接 `continue` 。详细解析，见 [「5.1.3 dispose」](https://svip.iocoder.cn/Netty/ByteBuf-1-3-ByteBuf-resource-leak-detector/#) 。
+
+- 第 24 行：调用 `DefaultResourceLeak#toString()` 方法，获得 Record 日志。详细解析，见 [「5.1 DefaultResourceLeak」](https://svip.iocoder.cn/Netty/ByteBuf-1-3-ByteBuf-resource-leak-detector/#) 。
+
+- 第 25 至 32 行：相同 Record 日志内容( 即“创建的地方与访问路径一致” )，**只汇报一次**。 代码如下：
+
+  ```
+  /**
+   * This method is called when a traced leak is detected. It can be overridden for tracking how many times leaks
+   * have been detected.
+   */
+  protected void reportTracedLeak(String resourceType, String records) {
+      logger.error(
+              "LEAK: {}.release() was not called before it's garbage-collected. " +
+              "See http://netty.io/wiki/reference-counted-objects.html for more information.{}",
+              resourceType, records);
+  }
+  
+  /**
+   * This method is called when an untraced leak is detected. It can be overridden for tracking how many times leaks
+   * have been detected.
+   */
+  protected void reportUntracedLeak(String resourceType) {
+      logger.error("LEAK: {}.release() was not called before it's garbage-collected. " +
+              "Enable advanced leak reporting to find out where the leak occurred. " +
+              "To enable advanced leak reporting, " +
+              "specify the JVM option '-D{}={}' or call {}.setLevel() " +
+              "See http://netty.io/wiki/reference-counted-objects.html for more information.",
+              resourceType, PROP_LEVEL, Level.ADVANCED.name().toLowerCase(), simpleClassName(this));
+  }
+  ```
+
+😈 这块逻辑的信息量，可能有点大，胖友可以看完 [「5. ResourceLeakTracker」](https://svip.iocoder.cn/Netty/ByteBuf-1-3-ByteBuf-resource-leak-detector/#) ，再回过头理解下。
+
+## 4.5 clearRefQueue
+
+`#clearRefQueue()` 方法，清理队列。代码如下：
+
+```
+private void clearRefQueue() {
+    for (;;) {
+        @SuppressWarnings("unchecked")
+        DefaultResourceLeak ref = (DefaultResourceLeak) refQueue.poll();
+        if (ref == null) {
+            break;
+        }
+        // 清理，并返回是否内存泄露
+        ref.dispose();
+    }
+}
+```
+
+- 实际上，就是 `#reportLeak()` 方法的**不汇报内存泄露**的版本。
+
+# 5. ResourceLeakTracker
+
+`io.netty.util.ResourceLeakTracker` ，内存泄露追踪器接口。从 [「4.3 track」](https://svip.iocoder.cn/Netty/ByteBuf-1-3-ByteBuf-resource-leak-detector/#) 中，我们已经看到，每个资源( 例如：ByteBuf 对象 )，会创建一个追踪它是否内存泄露的 ResourceLeakTracker 对象。
+
+接口方法定义如下：
+
+```
+public interface ResourceLeakTracker<T>  {
+
+    /**
+     * 记录
+     *
+     * Records the caller's current stack trace so that the {@link ResourceLeakDetector} can tell where the leaked
+     * resource was accessed lastly. This method is a shortcut to {@link #record(Object) record(null)}.
+     */
+    void record();
+    /**
+     * 记录
+     *
+     * Records the caller's current stack trace and the specified additional arbitrary information
+     * so that the {@link ResourceLeakDetector} can tell where the leaked resource was accessed lastly.
+     */
+    void record(Object hint);
+
+    /**
+     * 关闭
+     *
+     * Close the leak so that {@link ResourceLeakTracker} does not warn about leaked resources.
+     * After this method is called a leak associated with this ResourceLeakTracker should not be reported.
+     *
+     * @return {@code true} if called first time, {@code false} if called already
+     */
+    boolean close(T trackedObject);
+
+}
+```
+
+- `#record(...)` 方法，出于调试目的，用一个额外的任意的( arbitrary )信息记录这个对象的当前访问地址。如果这个对象被检测到泄露了, 这个操作记录的信息将通过ResourceLeakDetector 提供。实际上，就是 `ReferenceCounted#touch(...)` 方法，会调用 `#record(...)` 方法。
+- `#close(T trackedObject)` 方法，关闭 ResourceLeakTracker 。如果资源( 例如：ByteBuf 对象 )被正确释放，则会调用 `#close(T trackedObject)` 方法，关闭 ResourceLeakTracker ，从而结束追踪。这样，在 `ResourceLeakDetector#reportLeak()` 方法，就不会提示该资源泄露。
+
+## 4.6 addExclusions
+
+`#addExclusions(Class clz, String ... methodNames)` 方法，添加忽略方法的集合。代码如下：
+
+```
+/**
+ * 忽略的方法集合
+ */
+private static final AtomicReference<String[]> excludedMethods = new AtomicReference<String[]>(EmptyArrays.EMPTY_STRINGS);
+
+public static void addExclusions(Class clz, String ... methodNames) {
+    Set<String> nameSet = new HashSet<String>(Arrays.asList(methodNames));
+    // Use loop rather than lookup. This avoids knowing the parameters, and doesn't have to handle
+    // NoSuchMethodException.
+    for (Method method : clz.getDeclaredMethods()) {
+        if (nameSet.remove(method.getName()) && nameSet.isEmpty()) {
+            break;
+        }
+    }
+    if (!nameSet.isEmpty()) {
+        throw new IllegalArgumentException("Can't find '" + nameSet + "' in " + clz.getName());
+    }
+    String[] oldMethods;
+    String[] newMethods;
+    do {
+        oldMethods = excludedMethods.get();
+        newMethods = Arrays.copyOf(oldMethods, oldMethods.length + 2 * methodNames.length);
+        for (int i = 0; i < methodNames.length; i++) {
+            newMethods[oldMethods.length + i * 2] = clz.getName();
+            newMethods[oldMethods.length + i * 2 + 1] = methodNames[i];
+        }
+    } while (!excludedMethods.compareAndSet(oldMethods, newMethods));
+}
+```
+
+- 代码比较简单，胖友自己理解。
+
+- 具体的用途，可参见 [「7. Record」](https://svip.iocoder.cn/Netty/ByteBuf-1-3-ByteBuf-resource-leak-detector/#) 的 `#toString()` 方法。
+
+- 目前调用该静态方法的有如下几处：
+
+  ```
+  // AbstractByteBufAllocator.java
+  static {
+      ResourceLeakDetector.addExclusions(AbstractByteBufAllocator.class, "toLeakAwareBuffer");
+  }
+  
+  // AdvancedLeakAwareByteBuf.java
+  static {
+      ResourceLeakDetector.addExclusions(AdvancedLeakAwareByteBuf.class, "touch", "recordLeakNonRefCountingOperation");
+  }
+  
+  // ReferenceCountUtil.java
+  static {
+      ResourceLeakDetector.addExclusions(ReferenceCountUtil.class, "touch");
+  }
+  ```
+
+## 5.1 DefaultResourceLeak
+
+DefaultResourceLeak ，继承 `java.lang.ref.WeakReference` 类，实现 ResourceLeakTracker 接口，默认 ResourceLeakTracker 实现类。同时，它是 ResourceLeakDetector 内部静态类。即：
+
+```
+// ... 简化无关代码
+public class ResourceLeakDetector<T> {
+
+    private static final class DefaultResourceLeak<T> extends WeakReference<Object> implements ResourceLeakTracker<T>, ResourceLeak {
+    }
+
+}
+```
+
+那么为什么要继承 `java.lang.ref.WeakReference` 类呢？在 [「5.1.1 构造方法」](https://svip.iocoder.cn/Netty/ByteBuf-1-3-ByteBuf-resource-leak-detector/#) 见分晓。
+
+### 5.1.1 构造方法
+
+```
+/**
+ * {@link #head} 的更新器
+ */
+@SuppressWarnings("unchecked") // generics and updaters do not mix.
+private static final AtomicReferenceFieldUpdater<DefaultResourceLeak<?>, Record> headUpdater =
+        (AtomicReferenceFieldUpdater)
+                AtomicReferenceFieldUpdater.newUpdater(DefaultResourceLeak.class, Record.class, "head");
+
+/**
+ * {@link #droppedRecords} 的更新器
+ */
+@SuppressWarnings("unchecked") // generics and updaters do not mix.
+private static final AtomicIntegerFieldUpdater<DefaultResourceLeak<?>> droppedRecordsUpdater =
+        (AtomicIntegerFieldUpdater)
+                AtomicIntegerFieldUpdater.newUpdater(DefaultResourceLeak.class, "droppedRecords");
+
+/**
+ * Record 链的头节点
+ *
+ * 看完 {@link #record()} 方法后，实际上，head 是尾节点，即最后( 新 )的一条 Record 。
+ */
+@SuppressWarnings("unused")
+private volatile Record head;
+/**
+ * 丢弃的 Record 计数
+ */
+@SuppressWarnings("unused")
+private volatile int droppedRecords;
+
+/**
+ * DefaultResourceLeak 集合。来自 {@link ResourceLeakDetector#allLeaks}
+ */
+private final ConcurrentMap<DefaultResourceLeak<?>, LeakEntry> allLeaks;
+/**
+ * hash 值
+ *
+ * 保证 {@link #close(Object)} 传入的对象，就是 {@link #referent} 对象
+ */
+private final int trackedHash;
+
+  1: DefaultResourceLeak(
+  2:         Object referent,
+  3:         ReferenceQueue<Object> refQueue,
+  4:         ConcurrentMap<DefaultResourceLeak<?>, LeakEntry> allLeaks) {
+  5:     // 父构造方法 <1>
+  6:     super(referent, refQueue);
+  7: 
+  8:     assert referent != null;
+  9: 
+ 10:     // Store the hash of the tracked object to later assert it in the close(...) method.
+ 11:     // It's important that we not store a reference to the referent as this would disallow it from
+ 12:     // be collected via the WeakReference.
+ 13:     trackedHash = System.identityHashCode(referent);
+ 14:     allLeaks.put(this, LeakEntry.INSTANCE);
+ 15:     // Create a new Record so we always have the creation stacktrace included.
+ 16:     headUpdater.set(this, new Record(Record.BOTTOM));
+ 17:     this.allLeaks = allLeaks;
+ 18: }
+```
+
+- ```
+  head
+  ```
+
+   
+
+  属性，Record 链的头节点。
+
+  - 为什么说它是链呢？详细解析，胖友可以先跳到 [「7. Record」](https://svip.iocoder.cn/Netty/ByteBuf-1-3-ByteBuf-resource-leak-detector/#) 。
+  - 实际上，`head` 是尾节点，即最后( 新 )的一条 Record 记录。详细解析，见 [「5.1.2 record」](https://svip.iocoder.cn/Netty/ByteBuf-1-3-ByteBuf-resource-leak-detector/#) 。
+  - 在【第 16 行】代码，会默认创建尾节点 `Record.BOTTOM` 。
+
+- `droppedRecords` 属性，丢弃的 Record 计数。详细解析，见 [「5.1.2 record」](https://svip.iocoder.cn/Netty/ByteBuf-1-3-ByteBuf-resource-leak-detector/#) 。
+
+- ```
+  allLeaks
+  ```
+
+   
+
+  属性，DefaultResourceLeak 集合。来自
+
+   
+
+  ```
+  ResourceLeakDetector.allLeaks
+  ```
+
+   
+
+  属性。
+
+  - 在【第 14 行】代码，会将自己添加到 `allLeaks` 中。
+
+- ```
+  trackedHash
+  ```
+
+   
+
+  属性，hash 值。保证在
+
+   
+
+  ```
+  #close(T trackedObject)
+  ```
+
+   
+
+  方法，传入的对象，就是
+
+   
+
+  ```
+  referent
+  ```
+
+   
+
+  属性，即就是 DefaultResourceLeak 指向的资源( 例如：ByteBuf 对象 )。详细解析，见
+
+   
+
+  「5.1.4 close」
+
+   
+
+  。
+
+  - 在【第 10 至 13 行】代码，计算并初始化 `trackedHash` 属性。
+
+- 【重要】在 `<1>` 处，会将 `referent`( 资源，例如：ByteBuf 对象 )和 `refQueue`( 引用队列 )传入父 WeakReference 构造方法。
+
+  > FROM [《译文：理解Java中的弱引用》](https://droidyue.com/blog/2014/10/12/understanding-weakreference-in-java/index.html)
+  >
+  > **引用队列(Reference Queue)**
+  >
+  > 一旦弱引用对象开始返回null，该弱引用指向的对象就被标记成了垃圾。而这个弱引用对象（非其指向的对象）就没有什么用了。通常这时候需要进行一些清理工作。比如WeakHashMap会在这时候移除没用的条目来避免保存无限制增长的没有意义的弱引用。
+  >
+  > 引用队列可以很容易地实现跟踪不需要的引用。当你在构造WeakReference时传入一个ReferenceQueue对象，当该引用指向的对象被标记为垃圾的时候，这个引用对象会自动地加入到引用队列里面。接下来，你就可以在固定的周期，处理传入的引用队列，比如做一些清理工作来处理这些没有用的引用对象。
+
+  - 也就是说，`referent` 被标记为垃圾的时候，它对应的 WeakReference 对象会被添加到 `refQueue` 队列中。**在此处，即将 DefaultResourceLeak 添加到 `referent` 队列中**。
+  - 那又咋样呢？假设 `referent` 为 ByteBuf 对象。如果它被正确的释放，即调用了 [「3.3.4 release」](https://svip.iocoder.cn/Netty/ByteBuf-1-3-ByteBuf-resource-leak-detector/#) 方法，从而调用了 `AbstractReferenceCountedByteBuf#closeLeak()` 方法，最终调用到 `ResourceLeakTracker#close(trackedByteBuf)` 方法，那么该 ByteBuf 对象对应的 ResourceLeakTracker 对象，将从 `ResourceLeakDetector.allLeaks` 中移除。
+  - 那这又意味着什么呢？ 在 `ResourceLeakDetector#reportLeak()` 方法中，即使从 `refQueue` 队列中，获取到该 ByteBuf 对象对应 ResourceLeakTracker 对象，因为在 `ResourceLeakDetector.allLeaks` 中移除了，所以在 `ResourceLeakDetector#reportLeak()` 方法的【第 19 行】代码 `!ref.dispose() = true` ，直接 `continue` 。
+  - 😈 比较绕，胖友再好好理解下。胖友可以在思考下，如果 ByteBuf 对象，没有被正确的释放，是怎么样一个流程。
+
+### 5.1.2 record
+
+`#record(...)` 方法，创建 Record 对象，添加到 `head` 链中。代码如下：
+
+```
+@Override
+public void record() {
+    record0(null);
+}
+@Override
+public void record(Object hint) {
+    record0(hint);
+}
+
+/**
+ * This method works by exponentially backing off as more records are present in the stack. Each record has a
+ * 1 / 2^n chance of dropping the top most record and replacing it with itself. This has a number of convenient
+ * properties:
+ *
+ * <ol>
+ * <li>  The current record is always recorded. This is due to the compare and swap dropping the top most
+ *       record, rather than the to-be-pushed record.
+ * <li>  The very last access will always be recorded. This comes as a property of 1.
+ * <li>  It is possible to retain more records than the target, based upon the probability distribution.
+ * <li>  It is easy to keep a precise record of the number of elements in the stack, since each element has to
+ *     know how tall the stack is.
+ * </ol>
+ *
+ * In this particular implementation, there are also some advantages. A thread local random is used to decide
+ * if something should be recorded. This means that if there is a deterministic access pattern, it is now
+ * possible to see what other accesses occur, rather than always dropping them. Second, after
+ * {@link #TARGET_RECORDS} accesses, backoff occurs. This matches typical access patterns,
+ * where there are either a high number of accesses (i.e. a cached buffer), or low (an ephemeral buffer), but
+ * not many in between.
+ *
+ * The use of atomics avoids serializing a high number of accesses, when most of the records will be thrown
+ * away. High contention only happens when there are very few existing records, which is only likely when the
+ * object isn't shared! If this is a problem, the loop can be aborted and the record dropped, because another
+ * thread won the race.
+ */
+  1: private void record0(Object hint) {
+  2:     // Check TARGET_RECORDS > 0 here to avoid similar check before remove from and add to lastRecords
+  3:     if (TARGET_RECORDS > 0) {
+  4:         Record oldHead;
+  5:         Record prevHead;
+  6:         Record newHead;
+  7:         boolean dropped;
+  8:         do {
+  9:             // 已经关闭，则返回
+ 10:             if ((prevHead = oldHead = headUpdater.get(this)) == null) {
+ 11:                 // already closed.
+ 12:                 return;
+ 13:             }
+ 14:             // 当超过 TARGET_RECORDS 数量时，随机丢到头节点。
+ 15:             final int numElements = oldHead.pos + 1;
+ 16:             if (numElements >= TARGET_RECORDS) {
+ 17:                 final int backOffFactor = Math.min(numElements - TARGET_RECORDS, 30);
+ 18:                 if (dropped = PlatformDependent.threadLocalRandom().nextInt(1 << backOffFactor) != 0) {
+ 19:                     prevHead = oldHead.next;
+ 20:                 }
+ 21:             } else {
+ 22:                 dropped = false;
+ 23:             }
+ 24:             // 创建新的头节点
+ 25:             newHead = hint != null ? new Record(prevHead, hint) : new Record(prevHead);
+ 26:         } while (!headUpdater.compareAndSet(this, oldHead, newHead)); // cas 修改头节点
+ 27:         // 若丢弃，增加 droppedRecordsUpdater 计数
+ 28:         if (dropped) {
+ 29:             droppedRecordsUpdater.incrementAndGet(this);
+ 30:         }
+ 31:     }
+ 32: }
+```
+
+- 第 9 至 13 行：通过 `headUpdater` 获得 `head` 属性，若为 `null` 时，说明 DefaultResourceLeak 已经关闭。为什么呢？详细可见 [「5.1.4 close」](https://svip.iocoder.cn/Netty/ByteBuf-1-3-ByteBuf-resource-leak-detector/#) 和 [5.1.5 toString](https://svip.iocoder.cn/Netty/ByteBuf-1-3-ByteBuf-resource-leak-detector/#) 。
+- 第 14 至 23 行：当当前 DefaultResourceLeak 对象所拥有的 Record 数量超过 `TARGET_RECORDS` 时，随机丢弃当前 `head` 节点的数据。也就是说，尽量保留**老**的 Record 节点。这是为什么呢?越是**老**( 开始 )的 Record 节点，越有利于排查问题。另外，随机丢弃的的概率，按照 `1 - (1 / 2^n）` 几率，越来越**大**。
+- 第 25 行：创建新 Record 对象，作为头节点，指向**原头节点**。这也是为什么说，“实际上，head 是尾节点，即最后( 新 )的一条 Record”。
+- 第 26 行：通过 CAS 的方式，修改新创建的 Record 对象为头节点。
+- 第 27 至 30 行：若丢弃，增加 `droppedRecordsUpdater` 计数。
+
+### 5.1.3 dispose
+
+`#dispose()` 方法， 清理，并返回是否内存泄露。代码如下：
+
+```
+// 清理，并返回是否内存泄露
+boolean dispose() {
+    // 清理 referent 的引用
+    clear();
+    // 移除出 allLeaks 。移除成功，意味着内存泄露。
+    return allLeaks.remove(this, LeakEntry.INSTANCE);
+}
+```
+
+### 5.1.4 close
+
+`#close(T trackedObject)` 方法，关闭 DefaultResourceLeak 对象。代码如下：
+
+```
+ 1: @Override
+ 2: public boolean close(T trackedObject) {
+ 3:     // 校验一致
+ 4:     // Ensure that the object that was tracked is the same as the one that was passed to close(...).
+ 5:     assert trackedHash == System.identityHashCode(trackedObject);
+ 6: 
+ 7:     // 关闭
+ 8:     // We need to actually do the null check of the trackedObject after we close the leak because otherwise
+ 9:     // we may get false-positives reported by the ResourceLeakDetector. This can happen as the JIT / GC may
+10:     // be able to figure out that we do not need the trackedObject anymore and so already enqueue it for
+11:     // collection before we actually get a chance to close the enclosing ResourceLeak.
+12:     return close() && trackedObject != null;
+13: }
+```
+
+- 第 5 行：校验一致性。
+
+- 第 12 行：调用 `#close()` 方法，关闭 DefaultResourceLeak 对象。代码如下：
+
+  ```
+  @Override
+  public boolean close() {
+      // 移除出 allLeaks
+      // Use the ConcurrentMap remove method, which avoids allocating an iterator.
+      if (allLeaks.remove(this, LeakEntry.INSTANCE)) {
+          // 清理 referent 的引用
+          // Call clear so the reference is not even enqueued.
+          clear();
+          // 置空 head
+          headUpdater.set(this, null);
+          return true; // 返回成功
+      }
+      return false; // 返回失败
+  }
+  ```
+
+  - 关闭时，会将 DefaultResourceLeak 对象，从 `allLeaks` 中移除。
+
+### 5.1.5 toString
+
+当 DefaultResourceLeak 追踪到内存泄露，会在 `ResourceLeakDetector#reportLeak()` 方法中，调用 `DefaultResourceLeak#toString()` 方法，拼接提示信息。代码如下：
+
+```
+@Override
+public String toString() {
+    // 获得 head 属性，并置空 <1>
+    Record oldHead = headUpdater.getAndSet(this, null);
+    // 若为空，说明已经关闭。
+    if (oldHead == null) {
+        // Already closed
+        return EMPTY_STRING;
+    }
+
+    final int dropped = droppedRecordsUpdater.get(this);
+    int duped = 0;
+
+    int present = oldHead.pos + 1;
+    // Guess about 2 kilobytes per stack trace
+    StringBuilder buf = new StringBuilder(present * 2048).append(NEWLINE);
+    buf.append("Recent access records: ").append(NEWLINE);
+
+    // 拼接 Record 练
+    int i = 1;
+    Set<String> seen = new HashSet<String>(present);
+    for (; oldHead != Record.BOTTOM; oldHead = oldHead.next) {
+        String s = oldHead.toString();
+        if (seen.add(s)) { // 是否重复
+            if (oldHead.next == Record.BOTTOM) {
+                buf.append("Created at:").append(NEWLINE).append(s);
+            } else {
+                buf.append('#').append(i++).append(':').append(NEWLINE).append(s);
+            }
+        } else {
+            duped++;
+        }
+    }
+
+    // 拼接 duped ( 重复 ) 次数
+    if (duped > 0) {
+        buf.append(": ")
+                .append(dropped)
+                .append(" leak records were discarded because they were duplicates")
+                .append(NEWLINE);
+    }
+
+    // 拼接 dropped (丢弃) 次数
+    if (dropped > 0) {
+        buf.append(": ")
+           .append(dropped)
+           .append(" leak records were discarded because the leak record count is targeted to ")
+           .append(TARGET_RECORDS)
+           .append(". Use system property ")
+           .append(PROP_TARGET_RECORDS)
+           .append(" to increase the limit.")
+           .append(NEWLINE);
+    }
+
+    buf.setLength(buf.length() - NEWLINE.length());
+    return buf.toString();
+}
+```
+
+- 代码比较简单，胖友自己看注释。
+- `<1>` 处，真的是个神坑。如果胖友在 IDEA 调试时，因为默认会调用对应的 `#toString()` 方法，会导致 `head` 属性被错误的重置为 `null` 值。wtf！！！笔者在这里卡了好久好久。
+
+# 6. LeakEntry
+
+LeakEntry ，用于 `ResourceLeakDetector.allLeaks` 属性的 value 值。代码如下：
+
+```
+private static final class LeakEntry {
+
+    /**
+     * 单例
+     */
+    static final LeakEntry INSTANCE = new LeakEntry();
+
+    /**
+     * hash 值，避免重复计算
+     */
+    private static final int HASH = System.identityHashCode(INSTANCE);
+
+    private LeakEntry() { // 禁止创建，仅使用 INSTANCE 单例
+    }
+
+    @Override
+    public int hashCode() {
+        return HASH;
+    }
+
+    @Override
+    public boolean equals(Object obj) {
+        return obj == this;
+    }
+
+}
+```
+
+😈 没有什么功能逻辑。
+
+# 7. Record
+
+Record ，记录。每次调用 `ResourceLeakTracker#touch(...)` 方法后，会产生响应的 Record 对象。代码如下：
+
+```
+private static final class Record extends Throwable {
+
+    private static final long serialVersionUID = 6065153674892850720L;
+
+    /**
+     * 尾节点的单例
+     */
+    private static final Record BOTTOM = new Record();
+
+    /**
+     * hint 字符串
+     */
+    private final String hintString;
+    /**
+     * 下一个节点
+     */
+    private final Record next;
+    /**
+     * 位置
+     */
+    private final int pos;
+
+    // =========== 构造方法 ===========
+
+    Record(Record next, Object hint) {
+        // This needs to be generated even if toString() is never called as it may change later on.
+        hintString = hint instanceof ResourceLeakHint ? ((ResourceLeakHint) hint).toHintString() : hint.toString(); // <1>
+        this.next = next;
+        this.pos = next.pos + 1;
+    }
+
+    Record(Record next) {
+       hintString = null;
+       this.next = next;
+       this.pos = next.pos + 1;
+    }
+
+    // Used to terminate the stack
+    private Record() {
+        hintString = null;
+        next = null;
+        pos = -1;
+    }
+
+    // =========== toString ===========
+
+    @Override
+    public String toString() {
+        StringBuilder buf = new StringBuilder(2048);
+        if (hintString != null) {
+            buf.append("\tHint: ").append(hintString).append(NEWLINE);
+        }
+
+        // Append the stack trace.
+        StackTraceElement[] array = getStackTrace();
+        // Skip the first three elements.
+        out: for (int i = 3; i < array.length; i++) {
+            StackTraceElement element = array[i];
+            // 跳过忽略的方法 <2>
+            // Strip the noisy stack trace elements.
+            String[] exclusions = excludedMethods.get();
+            for (int k = 0; k < exclusions.length; k += 2) {
+                if (exclusions[k].equals(element.getClassName())
+                        && exclusions[k + 1].equals(element.getMethodName())) {
+                    continue out;
+                }
+            }
+
+            buf.append('\t');
+            buf.append(element.toString());
+            buf.append(NEWLINE);
+        }
+        return buf.toString();
+    }
+
+}
+```
+
+- 通过 `next` 属性，我们可以得知，Record 是链式结构。
+- `<1>` 处，如果传入的 `hint` 类型为 ResourceLeakHint 类型，会调用对应的 `#toHintString()` 方法，拼接更友好的字符串提示信息。
+- `<2>` 处，如果调用栈的方法在 `ResourceLeakDetector.exclusions` 属性中，进行忽略。
+
+# 8. ResourceLeakHint
+
+`io.netty.util.ResourceLeakHint` ，接口，提供人类可读( 易懂 )的提示信息，使用在 ResourceLeakDetector 中。代码如下：
+
+```
+/**
+ * A hint object that provides human-readable message for easier resource leak tracking.
+ */
+public interface ResourceLeakHint {
+
+    /**
+     * Returns a human-readable message that potentially enables easier resource leak tracking.
+     */
+    String toHintString();
+
+}
+```
+
+目前它的实现类是 AbstractChannelHandlerContext 。对应的实现方法如下：
+
+```
+/**
+ * 名字
+ */
+private final String name;
+
+@Override
+public String toHintString() {
+    return '\'' + name + "' will handle the message from this point.";
+}
+```
+
+# 666. 彩蛋
+
+比想象中长很多的文章，也比想象中花费了更多时间的文章。主要是 xxx 的 [「5.1.5 toString」](https://svip.iocoder.cn/Netty/ByteBuf-1-3-ByteBuf-resource-leak-detector/#) 中卡了好久啊！！！！
+
+推荐阅读文章：
+
+- [《Netty 学习笔记 —— Reference Count》](https://skyao.gitbooks.io/learning-netty/content/buffer/reference_count.html)
+- 唯有坚持不懈 [《Netty学习之旅—-源码分析Netty内存泄漏检测》](https://blog.csdn.net/prestigeding/article/details/54233327)
+
+上述两篇文章，因为分析的 Netty 不是最新版本，所以代码会有一些差异，例如 `maxActive` 已经被去除。
\ No newline at end of file
diff --git a/netty/38-Netty 源码解析-Buffer 之 ByteBuf（四）其它子类.assets/01.png b/netty/38-Netty 源码解析-Buffer 之 ByteBuf（四）其它子类.assets/01.png
new file mode 100644
index 0000000..2918334
Binary files /dev/null and b/netty/38-Netty 源码解析-Buffer 之 ByteBuf（四）其它子类.assets/01.png differ
diff --git a/netty/38-Netty 源码解析-Buffer 之 ByteBuf（四）其它子类.md b/netty/38-Netty 源码解析-Buffer 之 ByteBuf（四）其它子类.md
new file mode 100644
index 0000000..38d1d3a
--- /dev/null
+++ b/netty/38-Netty 源码解析-Buffer 之 ByteBuf（四）其它子类.md	
@@ -0,0 +1,26 @@
+# 精尽 Netty 源码解析 —— Buffer 之 ByteBuf（四）其它子类
+
+# 1. 概述
+
+在前面三篇文章，我们已经看了 ByteBuf 最最最核心的几个实现类。而剩余的，主要是如下几个类，如[下图](http://static.iocoder.cn/images/Netty/2018_08_10/01.png)所示：
+
+[![类图](38-Netty 源码解析-Buffer 之 ByteBuf（四）其它子类.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_08_10/01.png)类图
+
+整理起来，用途主要是：
+
+- Swap
+- Slice
+- Duplicate
+- ReadOnly
+- Composite
+
+因为老艿艿想要尽快去写 Jemalloc 内存管理相关的内容，所以本文先暂时“省略”。感兴趣的胖友，可以自己去研究下落。
+
+TODO 1016 派生类
+
+# 2. Composite ByteBuf
+
+因为 Composite ByteBuf 是比较重要的内容，胖友一定要自己去研究下。推荐阅读文章：
+
+- 键走偏锋 [《对于 Netty ByteBuf 的零拷贝（Zero Copy）的理解》](https://my.oschina.net/LucasZhu/blog/1617222)
+- [《Netty 学习笔记 —— 类CompositeByteBuf》](https://skyao.gitbooks.io/learning-netty/content/buffer/class_CompositeByteBuf.html)
\ No newline at end of file
diff --git a/netty/39-Netty 源码解析-Buffer 之 ByteBufAllocator（一）简介.assets/01.png b/netty/39-Netty 源码解析-Buffer 之 ByteBufAllocator（一）简介.assets/01.png
new file mode 100644
index 0000000..d6ed6f9
Binary files /dev/null and b/netty/39-Netty 源码解析-Buffer 之 ByteBufAllocator（一）简介.assets/01.png differ
diff --git a/netty/39-Netty 源码解析-Buffer 之 ByteBufAllocator（一）简介.md b/netty/39-Netty 源码解析-Buffer 之 ByteBufAllocator（一）简介.md
new file mode 100644
index 0000000..eb2689b
--- /dev/null
+++ b/netty/39-Netty 源码解析-Buffer 之 ByteBufAllocator（一）简介.md	
@@ -0,0 +1,498 @@
+# 精尽 Netty 源码解析 —— Buffer 之 ByteBufAllocator（一）简介
+
+# 1. 概述
+
+本文，我们来分享 ByteBufAllocator 。它是 ByteBuf 的分配器，负责创建 ByteBuf 对象。它的子类类图如下：[![类图](39-Netty 源码解析-Buffer 之 ByteBufAllocator（一）简介.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_08_20/01.png)类图
+
+主要有三个子类：
+
+- PreferHeapByteBufAllocator ，倾向创建 **Heap** ByteBuf 的分配器。
+- PooledByteBufAllocator ，基于**内存池**的 ByteBuf 的分配器。
+- UnpooledByteBufAllocator ，**普通**的 ByteBuf 的分配器。
+
+本文分享上面类图红框部分，后面两篇文章再分别分享 UnpooledByteBufAllocator 和 PooledByteBufAllocator 。
+
+# 2. ByteBufAllocator
+
+`io.netty.buffer.ByteBufAllocator` ，ByteBuf 分配器**接口**。
+
+还是老样子，我们逐个来看看每个方法。
+
+## 2.1 DEFAULT
+
+```
+ByteBufAllocator DEFAULT = ByteBufUtil.DEFAULT_ALLOCATOR;
+```
+
+- 默认 ByteBufAllocator 对象，通过 `ByteBufUtil.DEFAULT_ALLOCATOR` 中获得。代码如下：
+
+  ```
+  static final ByteBufAllocator DEFAULT_ALLOCATOR;
+  
+  static {
+      // 读取 ByteBufAllocator 配置
+      String allocType = SystemPropertyUtil.get("io.netty.allocator.type", PlatformDependent.isAndroid() ? "unpooled" : "pooled");
+      allocType = allocType.toLowerCase(Locale.US).trim();
+  
+      // 读取 ByteBufAllocator 对象
+      ByteBufAllocator alloc;
+      if ("unpooled".equals(allocType)) {
+          alloc = UnpooledByteBufAllocator.DEFAULT;
+          logger.debug("-Dio.netty.allocator.type: {}", allocType);
+      } else if ("pooled".equals(allocType)) {
+          alloc = PooledByteBufAllocator.DEFAULT;
+          logger.debug("-Dio.netty.allocator.type: {}", allocType);
+      } else {
+          alloc = PooledByteBufAllocator.DEFAULT;
+          logger.debug("-Dio.netty.allocator.type: pooled (unknown: {})", allocType);
+      }
+  
+      DEFAULT_ALLOCATOR = alloc;
+  
+      // ... 省略无关代码
+  }
+  ```
+
+  - 在非 Android 环境下，使用 PooledByteBufAllocator 作为默认 ByteBufAllocator 对象。
+  - 在 Android 环境下，使用 UnpooledByteBufAllocator 作为默认 ByteBufAllocator 对象。因为 Android 客户端的内存相对有限。
+
+## 2.2 buffer
+
+`#buffer(...)` 方法，创建一个 ByteBuf 对象。具体创建的是 Heap ByteBuf 还是 Direct ByteBuf ，由实现类决定。
+
+```
+/**
+ * Allocate a {@link ByteBuf}. If it is a direct or heap buffer
+ * depends on the actual implementation.
+ */
+ByteBuf buffer();
+ByteBuf buffer(int initialCapacity);
+ByteBuf buffer(int initialCapacity, int maxCapacity);
+```
+
+### 2.2.1 ioBuffer
+
+`#ioBuffer(...)` 方法，创建一个用于 IO 操作的 ByteBuf 对象。倾向于 Direct ByteBuf ，因为对于 IO 操作来说，性能更优。
+
+```
+/**
+ * Allocate a {@link ByteBuf}, preferably a direct buffer which is suitable for I/O.
+ */
+ByteBuf ioBuffer();
+ByteBuf ioBuffer(int initialCapacity);
+ByteBuf ioBuffer(int initialCapacity, int maxCapacity);
+```
+
+### 2.2.2 heapBuffer
+
+`#heapBuffer(...)` 方法，创建一个 Heap Buffer 对象。代码如下：
+
+```
+/**
+ * Allocate a heap {@link ByteBuf}.
+ */
+ByteBuf heapBuffer();
+ByteBuf heapBuffer(int initialCapacity);
+ByteBuf heapBuffer(int initialCapacity, int maxCapacity);
+```
+
+### 2.2.3 directBuffer
+
+`#directBuffer(...)` 方法，创建一个 Direct Buffer 对象。代码如下：
+
+```
+/**
+ * Allocate a direct {@link ByteBuf} with the given initial capacity.
+ */
+ByteBuf directBuffer(int initialCapacity);
+ByteBuf directBuffer(int initialCapacity, int maxCapacity);
+CompositeByteBuf compositeBuffer();
+```
+
+## 2.3 compositeBuffer
+
+`#compositeBuffer(...)` 方法，创建一个 Composite ByteBuf 对象。具体创建的是 Heap ByteBuf 还是 Direct ByteBuf ，由实现类决定。
+
+```
+/**
+ * Allocate a {@link CompositeByteBuf}.
+ * If it is a direct or heap buffer depends on the actual implementation.
+ */
+CompositeByteBuf compositeBuffer();
+CompositeByteBuf compositeBuffer(int maxNumComponents);
+```
+
+### 2.3.1 compositeHeapBuffer
+
+`#compositeHeapBuffer(...)` 方法，创建一个 Composite Heap ByteBuf 对象。代码如下：
+
+```
+/**
+ * Allocate a heap {@link CompositeByteBuf}.
+ */
+CompositeByteBuf compositeHeapBuffer();
+CompositeByteBuf compositeHeapBuffer(int maxNumComponents);
+```
+
+### 2.3.2 compositeDirectBuffer
+
+`#compositeDirectBuffer(...)` 方法，创建一个 Composite Direct ByteBuf 对象。代码如下：
+
+```
+/**
+ * Allocate a direct {@link CompositeByteBuf}.
+ */
+CompositeByteBuf compositeDirectBuffer();
+CompositeByteBuf compositeDirectBuffer(int maxNumComponents);
+```
+
+## 2.4 isDirectBufferPooled
+
+`#isDirectBufferPooled()` 方法，是否基于 Direct ByteBuf 对象池。代码如下：
+
+```
+/**
+ * Returns {@code true} if direct {@link ByteBuf}'s are pooled
+ */
+boolean isDirectBufferPooled();
+```
+
+## 2.5 calculateNewCapacity
+
+`#calculateNewCapacity(int minNewCapacity, int maxCapacity)` 方法，在 ByteBuf 扩容时，计算新的容量，该容量的值在 `[minNewCapacity, maxCapacity]` 范围内。代码如下：
+
+```
+/**
+ * Calculate the new capacity of a {@link ByteBuf} that is used when a {@link ByteBuf} needs to expand by the
+ * {@code minNewCapacity} with {@code maxCapacity} as upper-bound.
+ */
+int calculateNewCapacity(int minNewCapacity, int maxCapacity);
+```
+
+# 3. AbstractByteBufAllocator
+
+`io.netty.buffer.AbstractByteBufAllocator` ，实现 ByteBufAllocator 接口，ByteBufAllocator 抽象实现类，为 PooledByteBufAllocator 和 UnpooledByteBufAllocator 提供公共的方法。
+
+## 3.1 构造方法
+
+```
+/**
+ * 是否倾向创建 Direct ByteBuf
+ */
+private final boolean directByDefault;
+/**
+ * 空 ByteBuf 缓存
+ */
+private final ByteBuf emptyBuf;
+
+/**
+ * Instance use heap buffers by default
+ */
+protected AbstractByteBufAllocator() {
+    this(false);
+}
+
+/**
+ * Create new instance
+ *
+ * @param preferDirect {@code true} if {@link #buffer(int)} should try to allocate a direct buffer rather than
+ *                     a heap buffer
+ */
+protected AbstractByteBufAllocator(boolean preferDirect) {
+    directByDefault = preferDirect && PlatformDependent.hasUnsafe(); // 支持 Unsafe
+    emptyBuf = new EmptyByteBuf(this);
+}
+```
+
+- `directByDefault` 属性，是否倾向创建 Direct ByteBuf 。有一个前提是需要支持 Unsafe 操作。
+- `emptyBuf` 属性，空 ByteBuf 缓存对象。用于 `#buffer()` 等方法，创建**空** ByteBuf 对象时。
+
+## 3.2 buffer
+
+```
+@Override
+public ByteBuf buffer() {
+    if (directByDefault) {
+        return directBuffer();
+    }
+    return heapBuffer();
+}
+@Override
+public ByteBuf buffer(int initialCapacity) {
+    if (directByDefault) {
+        return directBuffer(initialCapacity);
+    }
+    return heapBuffer(initialCapacity);
+}
+@Override
+public ByteBuf buffer(int initialCapacity, int maxCapacity) {
+    if (directByDefault) {
+        return directBuffer(initialCapacity, maxCapacity);
+    }
+    return heapBuffer(initialCapacity, maxCapacity);
+}
+```
+
+- 根据 `directByDefault` 的值，调用 `#directBuffer(...)` 方法，还是调用 `#heapBuffer(...)` 方法。
+
+### 3.2.1 ioBuffer
+
+```
+/**
+ * 默认容量大小
+ */
+static final int DEFAULT_INITIAL_CAPACITY = 256;
+
+@Override
+public ByteBuf ioBuffer() {
+    if (PlatformDependent.hasUnsafe()) {
+        return directBuffer(DEFAULT_INITIAL_CAPACITY);
+    }
+    return heapBuffer(DEFAULT_INITIAL_CAPACITY);
+}
+
+@Override
+public ByteBuf ioBuffer(int initialCapacity) {
+    if (PlatformDependent.hasUnsafe()) {
+        return directBuffer(initialCapacity);
+    }
+    return heapBuffer(initialCapacity);
+}
+
+@Override
+public ByteBuf ioBuffer(int initialCapacity, int maxCapacity) {
+    if (PlatformDependent.hasUnsafe()) {
+        return directBuffer(initialCapacity, maxCapacity);
+    }
+    return heapBuffer(initialCapacity, maxCapacity);
+}
+```
+
+- 根据是否支持 Unsafe 操作的情况，调用 `#directBuffer(...)` 方法，还是调用 `#heapBuffer(...)` 方法。
+
+### 3.2.2 heapBuffer
+
+```
+/**
+ * 默认最大容量大小，无限。
+ */
+static final int DEFAULT_MAX_CAPACITY = Integer.MAX_VALUE;
+
+@Override
+public ByteBuf heapBuffer() {
+    return heapBuffer(DEFAULT_INITIAL_CAPACITY, DEFAULT_MAX_CAPACITY);
+}
+
+@Override
+public ByteBuf heapBuffer(int initialCapacity) {
+    return heapBuffer(initialCapacity, DEFAULT_MAX_CAPACITY);
+}
+
+@Override
+public ByteBuf heapBuffer(int initialCapacity, int maxCapacity) {
+    // 空 ByteBuf 对象
+    if (initialCapacity == 0 && maxCapacity == 0) {
+        return emptyBuf;
+    }
+    validate(initialCapacity, maxCapacity); // 校验容量的参数
+    // 创建 Heap ByteBuf 对象
+    return newHeapBuffer(initialCapacity, maxCapacity);
+}
+```
+
+- 最终调用 `#newHeapBuffer(int initialCapacity, int maxCapacity)` **抽象**方法，创建 Heap ByteBuf 对象。代码如下：
+
+  ```
+  /**
+   * Create a heap {@link ByteBuf} with the given initialCapacity and maxCapacity.
+   */
+  protected abstract ByteBuf newHeapBuffer(int initialCapacity, int maxCapacity);
+  ```
+
+  - 因为是否基于对象池的方式，创建 Heap ByteBuf 对象的实现会不同，所以需要抽象。
+
+### 3.2.3 directBuffer
+
+```
+@Override
+public ByteBuf directBuffer() {
+    return directBuffer(DEFAULT_INITIAL_CAPACITY, DEFAULT_MAX_CAPACITY);
+}
+
+@Override
+public ByteBuf directBuffer(int initialCapacity) {
+    return directBuffer(initialCapacity, DEFAULT_MAX_CAPACITY);
+}
+
+@Override
+public ByteBuf directBuffer(int initialCapacity, int maxCapacity) {
+    // 空 ByteBuf 对象
+    if (initialCapacity == 0 && maxCapacity == 0) {
+        return emptyBuf;
+    }
+    validate(initialCapacity, maxCapacity); // 校验容量的参数
+    // 创建 Direct ByteBuf 对象
+    return newDirectBuffer(initialCapacity, maxCapacity);
+}
+```
+
+- 最终调用 `#newDirectBuffer(int initialCapacity, int maxCapacity)` **抽象**方法，创建 Direct ByteBuf 对象。代码如下：
+
+  ```
+  /**
+   * Create a direct {@link ByteBuf} with the given initialCapacity and maxCapacity.
+   */
+  protected abstract ByteBuf newDirectBuffer(int initialCapacity, int maxCapacity);
+  ```
+
+  - 因为是否基于对象池的方式，创建 Direct ByteBuf 对象的实现会不同，所以需要抽象。
+
+## 3.3 compositeBuffer
+
+```
+@Override
+public CompositeByteBuf compositeBuffer() {
+    if (directByDefault) {
+        return compositeDirectBuffer();
+    }
+    return compositeHeapBuffer();
+}
+
+@Override
+public CompositeByteBuf compositeBuffer(int maxNumComponents) {
+    if (directByDefault) {
+        return compositeDirectBuffer(maxNumComponents);
+    }
+    return compositeHeapBuffer(maxNumComponents);
+}
+```
+
+- 根据 `directByDefault` 的值，调用 `#compositeDirectBuffer(...)` 方法，还是调用 `#compositeHeapBuffer(...)` 方法。
+
+### 3.3.1 compositeHeapBuffer
+
+```
+/**
+ * Composite ByteBuf 可包含的 ByteBuf 的最大数量
+ */
+static final int DEFAULT_MAX_COMPONENTS = 16;
+
+@Override
+public CompositeByteBuf compositeHeapBuffer() {
+    return compositeHeapBuffer(DEFAULT_MAX_COMPONENTS);
+}
+
+@Override
+public CompositeByteBuf compositeHeapBuffer(int maxNumComponents) {
+    return toLeakAwareBuffer(new CompositeByteBuf(this, false, maxNumComponents));
+}
+```
+
+- 创建 CompositeByteBuf 对象，并且方法参数 `direct` 为 `false` ，表示 Heap 类型。
+- 调用 `#toLeakAwareBuffer(CompositeByteBuf)` 方法，装饰成 LeakAware 的 ByteBuf 对象。
+
+### 3.3.2 compositeDirectBuffer
+
+```
+@Override
+public CompositeByteBuf compositeDirectBuffer() {
+    return compositeDirectBuffer(DEFAULT_MAX_COMPONENTS);
+}
+
+@Override
+public CompositeByteBuf compositeDirectBuffer(int maxNumComponents) {
+    return toLeakAwareBuffer(new CompositeByteBuf(this, true, maxNumComponents));
+}
+```
+
+- 创建 CompositeByteBuf 对象，并且方法参数 `direct` 为 `true` ，表示 Direct 类型。
+- 调用 `#toLeakAwareBuffer(CompositeByteBuf)` 方法，装饰成 LeakAware 的 ByteBuf 对象。
+
+## 3.4 toLeakAwareBuffer
+
+在 [《精尽 Netty 源码解析 —— Buffer 之 ByteBuf（三）内存泄露检测》](http://svip.iocoder.cn/Netty/ByteBuf-1-3-ByteBuf-resource-leak-detector) 中的 [「3.1 创建 LeakAware ByteBuf 对象」](https://svip.iocoder.cn/Netty/ByteBuf-2-1-ByteBufAllocator-intro/#) 小节，已经详细解析。
+
+## 3.5 calculateNewCapacity
+
+```
+/**
+ * 扩容分界线，4M
+ */
+static final int CALCULATE_THRESHOLD = 1048576 * 4; // 4 MiB page
+
+  1: @Override
+  2: public int calculateNewCapacity(int minNewCapacity, int maxCapacity) {
+  3:     if (minNewCapacity < 0) {
+  4:         throw new IllegalArgumentException("minNewCapacity: " + minNewCapacity + " (expected: 0+)");
+  5:     }
+  6:     if (minNewCapacity > maxCapacity) {
+  7:         throw new IllegalArgumentException(String.format(
+  8:                 "minNewCapacity: %d (expected: not greater than maxCapacity(%d)",
+  9:                 minNewCapacity, maxCapacity));
+ 10:     }
+ 11:     final int threshold = CALCULATE_THRESHOLD; // 4 MiB page
+ 12: 
+ 13:     // <1> 等于 threshold ，直接返回 threshold 。
+ 14:     if (minNewCapacity == threshold) {
+ 15:         return threshold;
+ 16:     }
+ 17: 
+ 18:     // <2> 超过 threshold ，增加 threshold ，不超过 maxCapacity 大小。
+ 19:     // If over threshold, do not double but just increase by threshold.
+ 20:     if (minNewCapacity > threshold) {
+ 21:         int newCapacity = minNewCapacity / threshold * threshold;
+ 22:         if (newCapacity > maxCapacity - threshold) { // 不超过 maxCapacity
+ 23:             newCapacity = maxCapacity;
+ 24:         } else {
+ 25:             newCapacity += threshold;
+ 26:         }
+ 27:         return newCapacity;
+ 28:     }
+ 29: 
+ 30:     // <3> 未超过 threshold ，从 64 开始两倍计算，不超过 4M 大小。
+ 31:     // Not over threshold. Double up to 4 MiB, starting from 64.
+ 32:     int newCapacity = 64;
+ 33:     while (newCapacity < minNewCapacity) {
+ 34:         newCapacity <<= 1;
+ 35:     }
+ 36:     return Math.min(newCapacity, maxCapacity);
+ 37: }
+```
+
+- 按照 `CALCULATE_THRESHOLD` 作为分界线，分成 3 种情况：`<1>`/`<2>`/`<3>` 。代码比较简单，胖友自己看注释。
+
+# 4. PreferHeapByteBufAllocator
+
+`io.netty.channel.PreferHeapByteBufAllocator` ，实现 ByteBufAllocator 接口，**倾向创建 Heap ByteBuf** 的分配器。也就是说，`#buffer(...)` 和 `#ioBuffer(...)` 和 `#compositeBuffer(...)` 方法，创建的都是 Heap ByteBuf 对象。代码如下：
+
+```
+/**
+ * 真正的分配器对象
+ */
+private final ByteBufAllocator allocator;
+
+public PreferHeapByteBufAllocator(ByteBufAllocator allocator) {
+    this.allocator = ObjectUtil.checkNotNull(allocator, "allocator");
+}
+
+@Override
+public ByteBuf buffer() {
+    return allocator.heapBuffer();
+}
+
+@Override
+public ByteBuf ioBuffer() {
+    return allocator.heapBuffer();
+}
+
+@Override
+public CompositeByteBuf compositeBuffer() {
+    return allocator.compositeHeapBuffer();
+}
+```
+
+其它方法，就是调用 `allocator` 的对应的方法。
+
+# 666. 彩蛋
+
+😈 小水文一篇。铺垫铺垫，你懂的。
\ No newline at end of file
diff --git a/netty/40-Netty 源码解析-Buffer 之 ByteBufAllocator（二）UnpooledByteBufAllocator.md b/netty/40-Netty 源码解析-Buffer 之 ByteBufAllocator（二）UnpooledByteBufAllocator.md
new file mode 100644
index 0000000..2617268
--- /dev/null
+++ b/netty/40-Netty 源码解析-Buffer 之 ByteBufAllocator（二）UnpooledByteBufAllocator.md	
@@ -0,0 +1,505 @@
+# 精尽 Netty 源码解析 —— Buffer 之 ByteBufAllocator（二）UnpooledByteBufAllocator
+
+# 1. 概述
+
+本文，我们来分享 UnpooledByteBufAllocator ，**普通**的 ByteBuf 的分配器，**不基于内存池**。
+
+# 2. ByteBufAllocatorMetricProvider
+
+`io.netty.buffer.ByteBufAllocatorMetricProvider` ，ByteBufAllocator Metric 提供者接口，**用于监控 ByteBuf 的 Heap 和 Direct 占用内存的情况**。代码如下：
+
+```
+public interface ByteBufAllocatorMetricProvider {
+
+    /**
+     * Returns a {@link ByteBufAllocatorMetric} for a {@link ByteBufAllocator}.
+     */
+    ByteBufAllocatorMetric metric();
+
+}
+```
+
+ByteBufAllocatorMetricProvider 有两个子类：UnpooledByteBufAllocator 和 PooledByteBufAllocator 。
+
+# 3. ByteBufAllocatorMetric
+
+`io.netty.buffer.ByteBufAllocatorMetric` ，ByteBufAllocator Metric 接口。代码如下：
+
+```
+public interface ByteBufAllocatorMetric {
+
+    /**
+     * Returns the number of bytes of heap memory used by a {@link ByteBufAllocator} or {@code -1} if unknown.
+     *
+     * 已使用 Heap 占用内存大小
+     */
+    long usedHeapMemory();
+
+    /**
+     * Returns the number of bytes of direct memory used by a {@link ByteBufAllocator} or {@code -1} if unknown.
+     *
+     * 已使用 Direct 占用内存大小
+     */
+    long usedDirectMemory();
+
+}
+```
+
+ByteBufAllocatorMetric 有两个子类：UnpooledByteBufAllocatorMetric 和 PooledByteBufAllocatorMetric 。
+
+## 3.1 UnpooledByteBufAllocatorMetric
+
+UnpooledByteBufAllocatorMetric ，在 UnpooledByteBufAllocator 的**内部静态类**，实现 ByteBufAllocatorMetric 接口，UnpooledByteBufAllocator Metric 实现类。代码如下：
+
+```
+/**
+ * Direct ByteBuf 占用内存大小
+ */
+final LongCounter directCounter = PlatformDependent.newLongCounter();
+/**
+ * Heap ByteBuf 占用内存大小
+ */
+final LongCounter heapCounter = PlatformDependent.newLongCounter();
+
+@Override
+public long usedHeapMemory() {
+    return heapCounter.value();
+}
+
+@Override
+public long usedDirectMemory() {
+    return directCounter.value();
+}
+```
+
+- 比较简单，两个计数器。
+
+- `PlatformDependent#newLongCounter()` 方法，获得 LongCounter 对象。代码如下：
+
+  ```
+  /**
+   * Creates a new fastest {@link LongCounter} implementation for the current platform.
+   */
+  public static LongCounter newLongCounter() {
+      if (javaVersion() >= 8) {
+          return new LongAdderCounter();
+      } else {
+          return new AtomicLongCounter();
+      }
+  }
+  ```
+
+  - 也就是说，JDK `>=8` 使用 `java.util.concurrent.atomic.LongAdder` ，JDK `<7` 使用 `java.util.concurrent.atomic.AtomicLong` 。相比来说，Metric 写多读少，所以 LongAdder 比 AtomicLong 更合适。对比的解析，可以看看 [《Java并发计数器探秘》](https://www.cnkirito.moe/java-concurrent-counter/) 。
+
+# 4. UnpooledByteBufAllocator
+
+`io.netty.buffer.UnpooledByteBufAllocator` ，实现 ByteBufAllocatorMetricProvider 接口，继承 AbstractByteBufAllocator 抽象类，**普通**的 ByteBuf 的分配器，**不基于内存池**。
+
+## 4.1 构造方法
+
+```
+/**
+ * Metric
+ */
+private final UnpooledByteBufAllocatorMetric metric = new UnpooledByteBufAllocatorMetric();
+/**
+ * 是否禁用内存泄露检测功能
+ */
+private final boolean disableLeakDetector;
+/**
+ * 不使用 `io.netty.util.internal.Cleaner` 释放 Direct ByteBuf
+ *
+ * @see UnpooledUnsafeNoCleanerDirectByteBuf
+ * @see InstrumentedUnpooledUnsafeNoCleanerDirectByteBuf
+ */
+private final boolean noCleaner;
+
+public UnpooledByteBufAllocator(boolean preferDirect) {
+    this(preferDirect, false);
+}
+
+public UnpooledByteBufAllocator(boolean preferDirect, boolean disableLeakDetector) {
+    this(preferDirect, disableLeakDetector, PlatformDependent.useDirectBufferNoCleaner() /** 返回 true **/ );
+}
+
+/**
+ * Create a new instance
+ *
+ * @param preferDirect {@code true} if {@link #buffer(int)} should try to allocate a direct buffer rather than
+ *                     a heap buffer
+ * @param disableLeakDetector {@code true} if the leak-detection should be disabled completely for this
+ *                            allocator. This can be useful if the user just want to depend on the GC to handle
+ *                            direct buffers when not explicit released.
+ * @param tryNoCleaner {@code true} if we should try to use {@link PlatformDependent#allocateDirectNoCleaner(int)}
+ *                            to allocate direct memory.
+ */
+public UnpooledByteBufAllocator(boolean preferDirect, boolean disableLeakDetector, boolean tryNoCleaner) {
+    super(preferDirect);
+    this.disableLeakDetector = disableLeakDetector;
+    noCleaner = tryNoCleaner && PlatformDependent.hasUnsafe() /** 返回 true **/
+            && PlatformDependent.hasDirectBufferNoCleanerConstructor() /** 返回 true **/ ;
+}
+```
+
+- `metric` 属性，UnpooledByteBufAllocatorMetric 对象。
+
+- ```
+  disableLeakDetector
+  ```
+
+   
+
+  属性，是否禁用内存泄露检测功能。
+
+  - 默认为 `false` 。
+
+- ```
+  noCleaner
+  ```
+
+   
+
+  属性，是否不使用
+
+   
+
+  ```
+  io.netty.util.internal.Cleaner
+  ```
+
+   
+
+  来释放 Direct ByteBuf 。
+
+  - 默认为 `true` 。
+  - 详细解析，见 [「5.5 InstrumentedUnpooledUnsafeNoCleanerDirectByteBuf」](https://svip.iocoder.cn/Netty/ByteBuf-2-2-ByteBufAllocator-unpooled/#) 。
+
+## 4.2 newHeapBuffer
+
+```
+@Override
+protected ByteBuf newHeapBuffer(int initialCapacity, int maxCapacity) {
+    return PlatformDependent.hasUnsafe() ?
+            new InstrumentedUnpooledUnsafeHeapByteBuf(this, initialCapacity, maxCapacity) :
+            new InstrumentedUnpooledHeapByteBuf(this, initialCapacity, maxCapacity);
+}
+```
+
+- 创建的是以 `"Instrumented"` 的 Heap ByteBuf 对象，因为要结合 Metric 。详细解析，见 [「5. Instrumented ByteBuf」](https://svip.iocoder.cn/Netty/ByteBuf-2-2-ByteBufAllocator-unpooled/#) 。
+
+## 4.3 newDirectBuffer
+
+```
+@Override
+protected ByteBuf newDirectBuffer(int initialCapacity, int maxCapacity) {
+    final ByteBuf buf;
+    if (PlatformDependent.hasUnsafe()) {
+        buf = noCleaner ? new InstrumentedUnpooledUnsafeNoCleanerDirectByteBuf(this, initialCapacity, maxCapacity) :
+                new InstrumentedUnpooledUnsafeDirectByteBuf(this, initialCapacity, maxCapacity);
+    } else {
+        buf = new InstrumentedUnpooledDirectByteBuf(this, initialCapacity, maxCapacity);
+    }
+    return disableLeakDetector ? buf : toLeakAwareBuffer(buf);
+}
+```
+
+- 创建的是以 `"Instrumented"` 的 Heap ByteBuf 对象，因为要结合 Metric 。详细解析，见 [「5. Instrumented ByteBuf」](https://svip.iocoder.cn/Netty/ByteBuf-2-2-ByteBufAllocator-unpooled/#) 。
+- 结合了 `disableLeakDetector` 属性。
+
+## 4.4 compositeHeapBuffer
+
+```
+@Override
+public CompositeByteBuf compositeHeapBuffer(int maxNumComponents) {
+    CompositeByteBuf buf = new CompositeByteBuf(this, false, maxNumComponents);
+    return disableLeakDetector ? buf : toLeakAwareBuffer(buf);
+}
+```
+
+- 结合了 `disableLeakDetector` 属性。
+
+## 4.5 compositeDirectBuffer
+
+```
+@Override
+public CompositeByteBuf compositeDirectBuffer(int maxNumComponents) {
+    CompositeByteBuf buf = new CompositeByteBuf(this, true, maxNumComponents);
+    return disableLeakDetector ? buf : toLeakAwareBuffer(buf);
+}
+```
+
+- 结合了 `disableLeakDetector` 属性。
+
+## 4.6 isDirectBufferPooled
+
+```
+@Override
+public boolean isDirectBufferPooled() {
+    return false;
+}
+```
+
+## 4.7 Metric 相关操作方法
+
+```
+@Override
+public ByteBufAllocatorMetric metric() {
+    return metric;
+}
+
+void incrementDirect(int amount) { // 增加 Direct
+    metric.directCounter.add(amount);
+}
+void decrementDirect(int amount) { // 减少 Direct
+    metric.directCounter.add(-amount);
+}
+
+void incrementHeap(int amount) { // 增加 Heap
+    metric.heapCounter.add(amount);
+}
+void decrementHeap(int amount) { // 减少 Heap
+    metric.heapCounter.add(-amount);
+}
+```
+
+# 5. Instrumented ByteBuf
+
+因为要和 Metric 结合，所以通过**继承**的方式，进行增强。
+
+## 5.1 InstrumentedUnpooledUnsafeHeapByteBuf
+
+**Instrumented**UnpooledUnsafeHeapByteBuf ，在 UnpooledByteBufAllocator 的**内部静态类**，继承 UnpooledUnsafeHeapByteBuf 类。代码如下：
+
+```
+private static final class InstrumentedUnpooledUnsafeHeapByteBuf extends UnpooledUnsafeHeapByteBuf {
+
+    InstrumentedUnpooledUnsafeHeapByteBuf(UnpooledByteBufAllocator alloc, int initialCapacity, int maxCapacity) {
+        super(alloc, initialCapacity, maxCapacity);
+    }
+
+    @Override
+    protected byte[] allocateArray(int initialCapacity) {
+        byte[] bytes = super.allocateArray(initialCapacity);
+        // Metric ++
+        ((UnpooledByteBufAllocator) alloc()).incrementHeap(bytes.length);
+        return bytes;
+    }
+
+    @Override
+    protected void freeArray(byte[] array) {
+        int length = array.length;
+        super.freeArray(array);
+        // Metric --
+        ((UnpooledByteBufAllocator) alloc()).decrementHeap(length);
+    }
+
+}
+```
+
+- 在原先的基础上，调用 Metric 相应的增减操作方法，得以记录 Heap 占用内存的大小。
+
+## 5.2 InstrumentedUnpooledHeapByteBuf
+
+**Instrumented**UnpooledHeapByteBuf ，在 UnpooledByteBufAllocator 的**内部静态类**，继承 UnpooledHeapByteBuf 类。代码如下：
+
+```
+private static final class InstrumentedUnpooledHeapByteBuf extends UnpooledHeapByteBuf {
+
+    InstrumentedUnpooledHeapByteBuf(UnpooledByteBufAllocator alloc, int initialCapacity, int maxCapacity) {
+        super(alloc, initialCapacity, maxCapacity);
+    }
+
+    @Override
+    protected byte[] allocateArray(int initialCapacity) {
+        byte[] bytes = super.allocateArray(initialCapacity);
+        // Metric ++
+        ((UnpooledByteBufAllocator) alloc()).incrementHeap(bytes.length);
+        return bytes;
+    }
+
+    @Override
+    protected void freeArray(byte[] array) {
+        int length = array.length;
+        super.freeArray(array);
+        // Metric --
+        ((UnpooledByteBufAllocator) alloc()).decrementHeap(length);
+    }
+
+}
+```
+
+- 在原先的基础上，调用 Metric 相应的增减操作方法，得以记录 Heap 占用内存的大小。
+
+## 5.3 InstrumentedUnpooledUnsafeDirectByteBuf
+
+**Instrumented**UnpooledUnsafeDirectByteBuf ，在 UnpooledByteBufAllocator 的**内部静态类**，继承 UnpooledUnsafeDirectByteBuf 类。代码如下：
+
+```
+private static final class InstrumentedUnpooledUnsafeDirectByteBuf extends UnpooledUnsafeDirectByteBuf {
+    InstrumentedUnpooledUnsafeDirectByteBuf(
+            UnpooledByteBufAllocator alloc, int initialCapacity, int maxCapacity) {
+        super(alloc, initialCapacity, maxCapacity);
+    }
+
+    @Override
+    protected ByteBuffer allocateDirect(int initialCapacity) {
+        ByteBuffer buffer = super.allocateDirect(initialCapacity);
+        // Metric ++
+        ((UnpooledByteBufAllocator) alloc()).incrementDirect(buffer.capacity());
+        return buffer;
+    }
+
+    @Override
+    protected void freeDirect(ByteBuffer buffer) {
+        int capacity = buffer.capacity();
+        super.freeDirect(buffer);
+        // Metric --
+        ((UnpooledByteBufAllocator) alloc()).decrementDirect(capacity);
+    }
+}
+```
+
+- 在原先的基础上，调用 Metric 相应的增减操作方法，得以记录 Direct 占用内存的大小。
+
+## 5.4 InstrumentedUnpooledDirectByteBuf
+
+**Instrumented**UnpooledDirectByteBuf 的**内部静态类**，继承 UnpooledDirectByteBuf 类。代码如下：
+
+```
+private static final class InstrumentedUnpooledDirectByteBuf extends UnpooledDirectByteBuf {
+
+    InstrumentedUnpooledDirectByteBuf(
+            UnpooledByteBufAllocator alloc, int initialCapacity, int maxCapacity) {
+        super(alloc, initialCapacity, maxCapacity);
+    }
+
+    @Override
+    protected ByteBuffer allocateDirect(int initialCapacity) {
+        ByteBuffer buffer = super.allocateDirect(initialCapacity);
+        // Metric ++
+        ((UnpooledByteBufAllocator) alloc()).incrementDirect(buffer.capacity());
+        return buffer;
+    }
+
+    @Override
+    protected void freeDirect(ByteBuffer buffer) {
+        int capacity = buffer.capacity();
+        super.freeDirect(buffer);
+        // Metric --
+        ((UnpooledByteBufAllocator) alloc()).decrementDirect(capacity);
+    }
+
+}
+```
+
+- 在原先的基础上，调用 Metric 相应的增减操作方法，得以记录 Direct 占用内存的大小。
+
+## 5.5 InstrumentedUnpooledUnsafeNoCleanerDirectByteBuf
+
+**Instrumented**UnpooledDirectByteBuf 的**内部静态类**，继承 UnpooledUnsafeNoCleanerDirectByteBuf 类。代码如下：
+
+```
+private static final class InstrumentedUnpooledUnsafeNoCleanerDirectByteBuf
+        extends UnpooledUnsafeNoCleanerDirectByteBuf {
+
+    InstrumentedUnpooledUnsafeNoCleanerDirectByteBuf(
+            UnpooledByteBufAllocator alloc, int initialCapacity, int maxCapacity) {
+        super(alloc, initialCapacity, maxCapacity);
+    }
+
+    @Override
+    protected ByteBuffer allocateDirect(int initialCapacity) {
+        ByteBuffer buffer = super.allocateDirect(initialCapacity);
+        // Metric ++
+        ((UnpooledByteBufAllocator) alloc()).incrementDirect(buffer.capacity());
+        return buffer;
+    }
+
+    @Override
+    ByteBuffer reallocateDirect(ByteBuffer oldBuffer, int initialCapacity) {
+        int capacity = oldBuffer.capacity();
+        ByteBuffer buffer = super.reallocateDirect(oldBuffer, initialCapacity);
+        // Metric ++
+        ((UnpooledByteBufAllocator) alloc()).incrementDirect(buffer.capacity() - capacity);
+        return buffer;
+    }
+
+    @Override
+    protected void freeDirect(ByteBuffer buffer) {
+        int capacity = buffer.capacity();
+        super.freeDirect(buffer);
+        // Metric --
+        ((UnpooledByteBufAllocator) alloc()).decrementDirect(capacity);
+    }
+
+}
+```
+
+- 在原先的基础上，调用 Metric 相应的增减操作方法，得以记录 Heap 占用内存的大小。
+
+### 5.5.1 UnpooledUnsafeNoCleanerDirectByteBuf
+
+`io.netty.buffer.UnpooledUnsafeNoCleanerDirectByteBuf` ，继承 UnpooledUnsafeDirectByteBuf 类。代码如下：
+
+```
+class UnpooledUnsafeNoCleanerDirectByteBuf extends UnpooledUnsafeDirectByteBuf {
+
+    UnpooledUnsafeNoCleanerDirectByteBuf(ByteBufAllocator alloc, int initialCapacity, int maxCapacity) {
+        super(alloc, initialCapacity, maxCapacity);
+    }
+
+    @Override
+    protected ByteBuffer allocateDirect(int initialCapacity) {
+        // 反射，直接创建 ByteBuffer 对象。并且该对象不带 Cleaner 对象
+        return PlatformDependent.allocateDirectNoCleaner(initialCapacity);
+    }
+
+    ByteBuffer reallocateDirect(ByteBuffer oldBuffer, int initialCapacity) {
+        return PlatformDependent.reallocateDirectNoCleaner(oldBuffer, initialCapacity);
+    }
+
+    @Override
+    protected void freeDirect(ByteBuffer buffer) {
+        // 直接释放 ByteBuffer 对象
+        PlatformDependent.freeDirectNoCleaner(buffer);
+    }
+
+    @Override
+    public ByteBuf capacity(int newCapacity) {
+        checkNewCapacity(newCapacity);
+
+        int oldCapacity = capacity();
+        if (newCapacity == oldCapacity) {
+            return this;
+        }
+
+        // 重新分配 ByteBuf 对象
+        ByteBuffer newBuffer = reallocateDirect(buffer, newCapacity);
+
+        if (newCapacity < oldCapacity) {
+            if (readerIndex() < newCapacity) {
+                // 重置 writerIndex 为 newCapacity ，避免越界
+                if (writerIndex() > newCapacity) {
+                    writerIndex(newCapacity);
+                }
+            } else {
+                // 重置 writerIndex 和 readerIndex 为 newCapacity ，避免越界
+                setIndex(newCapacity, newCapacity);
+            }
+        }
+
+        // 设置 ByteBuf 对象
+        setByteBuffer(newBuffer, false);
+        return this;
+    }
+
+}
+```
+
+> FROM [《Netty源码分析（一） ByteBuf》](https://www.jianshu.com/p/b833254908f7)
+>
+> 和 UnpooledUnsafeDirectByteBuf 最大区别在于 UnpooledUnsafeNoCleanerDirectByteBuf 在 allocate的时候通过反射构造函数的方式创建DirectByteBuffer，这样在DirectByteBuffer中没有对应的Cleaner函数(通过ByteBuffer.allocateDirect的方式会自动生成Cleaner函数，Cleaner用于内存回收，具体可以看源码)，内存回收时，UnpooledUnsafeDirectByteBuf通过调用DirectByteBuffer中的Cleaner函数回收，而UnpooledUnsafeNoCleanerDirectByteBuf直接使用UNSAFE.freeMemory(address)释放内存地址。
+
+# 666. 彩蛋
+
+😈 小水文一篇。铺垫铺垫，你懂的。
\ No newline at end of file
diff --git a/netty/41-Netty 源码解析-Buffer 之 ByteBufAllocator（三）PooledByteBufAllocator.md b/netty/41-Netty 源码解析-Buffer 之 ByteBufAllocator（三）PooledByteBufAllocator.md
new file mode 100644
index 0000000..6105ac4
--- /dev/null
+++ b/netty/41-Netty 源码解析-Buffer 之 ByteBufAllocator（三）PooledByteBufAllocator.md	
@@ -0,0 +1,673 @@
+# 精尽 Netty 源码解析 —— Buffer 之 ByteBufAllocator（三）PooledByteBufAllocator
+
+# 1. 概述
+
+本文，我们来分享 PooledByteBufAllocator ，基于**内存池**的 ByteBuf 的分配器。而 PooledByteBufAllocator 的内存池，是基于 **Jemalloc** 算法进行分配管理，所以在看本文之前，胖友先跳到 [《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（一）简介》](http://svip.iocoder.cn/Netty/ByteBuf-3-1-Jemalloc-intro) ，将 Jemalloc 相关的**几篇**文章看完，在回到此处。
+
+# 2. PooledByteBufAllocatorMetric
+
+`io.netty.buffer.PooledByteBufAllocatorMetric` ，实现 ByteBufAllocatorMetric 接口，PooledByteBufAllocator Metric 实现类。代码如下：
+
+```
+public final class PooledByteBufAllocatorMetric implements ByteBufAllocatorMetric {
+
+    /**
+     * PooledByteBufAllocator 对象
+     */
+    private final PooledByteBufAllocator allocator;
+
+    PooledByteBufAllocatorMetric(PooledByteBufAllocator allocator) {
+        this.allocator = allocator;
+    }
+
+    /**
+     * Return the number of heap arenas.
+     */
+    public int numHeapArenas() {
+        return allocator.numHeapArenas();
+    }
+    /**
+     * Return the number of direct arenas.
+     */
+    public int numDirectArenas() {
+        return allocator.numDirectArenas();
+    }
+
+    /**
+     * Return a {@link List} of all heap {@link PoolArenaMetric}s that are provided by this pool.
+     */
+    public List<PoolArenaMetric> heapArenas() {
+        return allocator.heapArenas();
+    }
+    /**
+     * Return a {@link List} of all direct {@link PoolArenaMetric}s that are provided by this pool.
+     */
+    public List<PoolArenaMetric> directArenas() {
+        return allocator.directArenas();
+    }
+
+    /**
+     * Return the number of thread local caches used by this {@link PooledByteBufAllocator}.
+     */
+    public int numThreadLocalCaches() {
+        return allocator.numThreadLocalCaches();
+    }
+
+    /**
+     * Return the size of the tiny cache.
+     */
+    public int tinyCacheSize() {
+        return allocator.tinyCacheSize();
+    }
+    /**
+     * Return the size of the small cache.
+     */
+    public int smallCacheSize() {
+        return allocator.smallCacheSize();
+    }
+    /**
+     * Return the size of the normal cache.
+     */
+    public int normalCacheSize() {
+        return allocator.normalCacheSize();
+    }
+
+    /**
+     * Return the chunk size for an arena.
+     */
+    public int chunkSize() {
+        return allocator.chunkSize();
+    }
+
+    @Override
+    public long usedHeapMemory() {
+        return allocator.usedHeapMemory();
+    }
+    @Override
+    public long usedDirectMemory() {
+        return allocator.usedDirectMemory();
+    }
+
+    @Override
+    public String toString() {
+        StringBuilder sb = new StringBuilder(256);
+        sb.append(StringUtil.simpleClassName(this))
+                .append("(usedHeapMemory: ").append(usedHeapMemory())
+                .append("; usedDirectMemory: ").append(usedDirectMemory())
+                .append("; numHeapArenas: ").append(numHeapArenas())
+                .append("; numDirectArenas: ").append(numDirectArenas())
+                .append("; tinyCacheSize: ").append(tinyCacheSize())
+                .append("; smallCacheSize: ").append(smallCacheSize())
+                .append("; normalCacheSize: ").append(normalCacheSize())
+                .append("; numThreadLocalCaches: ").append(numThreadLocalCaches())
+                .append("; chunkSize: ").append(chunkSize()).append(')');
+        return sb.toString();
+    }
+
+}
+```
+
+- 每个实现方法，都是调用 `allocator` 对应的方法。通过 PooledByteBufAllocatorMetric 的封装，可以统一获得 PooledByteBufAllocator Metric 相关的信息。
+
+# 3. PooledByteBufAllocator
+
+`io.netty.buffer.PooledByteBufAllocator` ，实现 ByteBufAllocatorMetricProvider 接口，实现 AbstractByteBufAllocator 抽象类，基于**内存池**的 ByteBuf 的分配器。
+
+## 3.1 静态属性
+
+```
+/**
+ * 默认 Heap 类型的 Arena 数量
+ */
+private static final int DEFAULT_NUM_HEAP_ARENA;
+/**
+ * 默认 Direct 类型的 Arena 数量
+ */
+private static final int DEFAULT_NUM_DIRECT_ARENA;
+
+/**
+ * 默认 Page 的内存大小，单位：B 。
+ *
+ * 默认配置，8192 B = 8 KB
+ */
+private static final int DEFAULT_PAGE_SIZE;
+/**
+ * {@link PoolChunk} 满二叉树的高度，默认为 11 。
+ */
+private static final int DEFAULT_MAX_ORDER; // 8192 << 11 = 16 MiB per chunk
+/**
+ * 默认 {@link PoolThreadCache} 的 tiny 类型的内存块的缓存数量。默认为 512 。
+ *
+ * @see #tinyCacheSize
+ */
+private static final int DEFAULT_TINY_CACHE_SIZE;
+/**
+ * 默认 {@link PoolThreadCache} 的 small 类型的内存块的缓存数量。默认为 256 。
+ *
+ * @see #smallCacheSize
+ */
+private static final int DEFAULT_SMALL_CACHE_SIZE;
+/**
+ * 默认 {@link PoolThreadCache} 的 normal 类型的内存块的缓存数量。默认为 64 。
+ *
+ * @see #normalCacheSize
+ */
+private static final int DEFAULT_NORMAL_CACHE_SIZE;
+/**
+ * 默认 {@link PoolThreadCache} 缓存的内存块的最大字节数
+ */
+private static final int DEFAULT_MAX_CACHED_BUFFER_CAPACITY;
+/**
+ * 默认 {@link PoolThreadCache}
+ */
+private static final int DEFAULT_CACHE_TRIM_INTERVAL;
+/**
+ * 默认是否使用 {@link PoolThreadCache}
+ */
+private static final boolean DEFAULT_USE_CACHE_FOR_ALL_THREADS;
+
+/**
+ * 默认 Direct 内存对齐基准
+ */
+private static final int DEFAULT_DIRECT_MEMORY_CACHE_ALIGNMENT;
+
+/**
+ * Page 的内存最小值。默认为 4KB = 4096B
+ */
+private static final int MIN_PAGE_SIZE = 4096;
+/**
+ * Chunk 的内存最大值。默认为 1GB
+ */
+private static final int MAX_CHUNK_SIZE = (int) (((long) Integer.MAX_VALUE + 1) / 2);
+
+static {
+    // 初始化 DEFAULT_PAGE_SIZE
+    int defaultPageSize = SystemPropertyUtil.getInt("io.netty.allocator.pageSize", 8192);
+    Throwable pageSizeFallbackCause = null;
+    try {
+        validateAndCalculatePageShifts(defaultPageSize);
+    } catch (Throwable t) {
+        pageSizeFallbackCause = t;
+        defaultPageSize = 8192;
+    }
+    DEFAULT_PAGE_SIZE = defaultPageSize;
+
+    // 初始化 DEFAULT_MAX_ORDER
+    int defaultMaxOrder = SystemPropertyUtil.getInt("io.netty.allocator.maxOrder", 11);
+    Throwable maxOrderFallbackCause = null;
+    try {
+        validateAndCalculateChunkSize(DEFAULT_PAGE_SIZE, defaultMaxOrder);
+    } catch (Throwable t) {
+        maxOrderFallbackCause = t;
+        defaultMaxOrder = 11;
+    }
+    DEFAULT_MAX_ORDER = defaultMaxOrder;
+
+    // Determine reasonable default for nHeapArena and nDirectArena.
+    // Assuming each arena has 3 chunks, the pool should not consume more than 50% of max memory.
+    final Runtime runtime = Runtime.getRuntime();
+
+    /*
+     * We use 2 * available processors by default to reduce contention as we use 2 * available processors for the
+     * number of EventLoops in NIO and EPOLL as well. If we choose a smaller number we will run into hot spots as
+     * allocation and de-allocation needs to be synchronized on the PoolArena.
+     *
+     * See https://github.com/netty/netty/issues/3888.
+     */
+    // 默认最小 Arena 个数。为什么这样计算，见上面的英文注释，大体的思路是，一个 EventLoop 一个 Arena ，避免多线程竞争。
+    final int defaultMinNumArena = NettyRuntime.availableProcessors() * 2;
+    // 初始化默认 Chunk 的内存大小。默认值为 8192 << 11 = 16 MiB per chunk
+    final int defaultChunkSize = DEFAULT_PAGE_SIZE << DEFAULT_MAX_ORDER;
+    // 初始化 DEFAULT_NUM_HEAP_ARENA
+    DEFAULT_NUM_HEAP_ARENA = Math.max(0,
+            SystemPropertyUtil.getInt(
+                    "io.netty.allocator.numHeapArenas",
+                    (int) Math.min(
+                            defaultMinNumArena,
+                            runtime.maxMemory() / defaultChunkSize / 2 / 3))); // `/ 2` 是为了不超过内存的一半，`/ 3` 是为了每个 Arena 有三个 Chunk
+    // 初始化 DEFAULT_NUM_DIRECT_ARENA
+    DEFAULT_NUM_DIRECT_ARENA = Math.max(0,
+            SystemPropertyUtil.getInt(
+                    "io.netty.allocator.numDirectArenas",
+                    (int) Math.min(
+                            defaultMinNumArena,
+                            PlatformDependent.maxDirectMemory() / defaultChunkSize / 2 / 3)));
+
+    // cache sizes
+    // <1> 初始化 DEFAULT_TINY_CACHE_SIZE
+    DEFAULT_TINY_CACHE_SIZE = SystemPropertyUtil.getInt("io.netty.allocator.tinyCacheSize", 512);
+    // 初始化 DEFAULT_SMALL_CACHE_SIZE
+    DEFAULT_SMALL_CACHE_SIZE = SystemPropertyUtil.getInt("io.netty.allocator.smallCacheSize", 256);
+    // 初始化 DEFAULT_NORMAL_CACHE_SIZE
+    DEFAULT_NORMAL_CACHE_SIZE = SystemPropertyUtil.getInt("io.netty.allocator.normalCacheSize", 64);
+
+    // 初始化 DEFAULT_MAX_CACHED_BUFFER_CAPACITY
+    // 32 kb is the default maximum capacity of the cached buffer. Similar to what is explained in
+    // 'Scalable memory allocation using jemalloc'
+    DEFAULT_MAX_CACHED_BUFFER_CAPACITY = SystemPropertyUtil.getInt("io.netty.allocator.maxCachedBufferCapacity", 32 * 1024);
+
+    // 初始化 DEFAULT_CACHE_TRIM_INTERVAL
+    // the number of threshold of allocations when cached entries will be freed up if not frequently used
+    DEFAULT_CACHE_TRIM_INTERVAL = SystemPropertyUtil.getInt("io.netty.allocator.cacheTrimInterval", 8192);
+
+    // 初始化 DEFAULT_USE_CACHE_FOR_ALL_THREADS
+    DEFAULT_USE_CACHE_FOR_ALL_THREADS = SystemPropertyUtil.getBoolean("io.netty.allocator.useCacheForAllThreads", true);
+
+    // 初始化 DEFAULT_DIRECT_MEMORY_CACHE_ALIGNMENT
+    DEFAULT_DIRECT_MEMORY_CACHE_ALIGNMENT = SystemPropertyUtil.getInt("io.netty.allocator.directMemoryCacheAlignment", 0);
+
+    // 打印调试日志( 省略... )
+}
+```
+
+- 静态变量有点多，主要是为 PoolThreadCache 做的**默认**配置项。读过 [《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（六）PoolThreadCache》](https://svip.iocoder.cn/Netty/ByteBuf-2-3-ByteBufAllocator-pooled/精尽 Netty 源码解析 —— Buffer 之 Jemalloc（六）PoolThreadCache) 的胖友，是不是灰常熟悉。
+
+- 比较有意思的是，
+
+  ```
+  DEFAULT_NUM_HEAP_ARENA
+  ```
+
+   
+
+  和
+
+   
+
+  ```
+  DEFAULT_NUM_DIRECT_ARENA
+  ```
+
+   
+
+  变量的初始化，在
+
+   
+
+  ```
+  <1>
+  ```
+
+   
+
+  处。
+
+  - 默认情况下，最小值是 `NettyRuntime.availableProcessors() * 2` ，也就是 CPU 线程数。这样的好处是， 一个 EventLoop 一个 Arena ，**避免多线程竞争**。更多的讨论，胖友可以看看 https://github.com/netty/netty/issues/3888 。
+  - 比较有趣的一段是 `runtime.maxMemory() / defaultChunkSize / 2 / 3` 代码块。其中，`/ 2` 是为了保证 Arena 不超过内存的一半，而 `/ 3` 是为了每个 Arena 有三个 Chunk 。
+  - 当然最终取值是上述两值的最小值。所以在推荐上，尽可能配置的内存，能够保证 `defaultMinNumArena` 。因为**要避免多线程竞争**。
+
+## 3.2 validateAndCalculatePageShifts
+
+`#validateAndCalculatePageShifts(int pageSize)` 方法，校验 `pageSize` 参数，并计算 `pageShift` 值。代码如下：
+
+```
+private static int validateAndCalculatePageShifts(int pageSize) {
+    // 校验
+    if (pageSize < MIN_PAGE_SIZE) {
+        throw new IllegalArgumentException("pageSize: " + pageSize + " (expected: " + MIN_PAGE_SIZE + ")");
+    }
+    // 校验 Page 的内存大小，必须是 2 的指数级
+    if ((pageSize & pageSize - 1) != 0) {
+        throw new IllegalArgumentException("pageSize: " + pageSize + " (expected: power of 2)");
+    }
+
+    // 计算 pageShift
+    // Logarithm base 2. At this point we know that pageSize is a power of two.
+    return Integer.SIZE - 1 - Integer.numberOfLeadingZeros(pageSize);
+}
+```
+
+- 默认情况下，`pageSize = 8KB = 8 * 1024= 8096` ，`pageShift = 8192` 。
+
+## 3.3 validateAndCalculateChunkSize
+
+`#validateAndCalculateChunkSize(int pageSize, int maxOrder)` 方法，校验 `maxOrder` 参数，并计算 `chunkSize` 值。代码如下：
+
+```
+private static int validateAndCalculateChunkSize(int pageSize, int maxOrder) {
+    if (maxOrder > 14) {
+        throw new IllegalArgumentException("maxOrder: " + maxOrder + " (expected: 0-14)");
+    }
+
+    // 计算 chunkSize
+    // Ensure the resulting chunkSize does not overflow.
+    int chunkSize = pageSize;
+    for (int i = maxOrder; i > 0; i --) {
+        if (chunkSize > MAX_CHUNK_SIZE / 2) {
+            throw new IllegalArgumentException(String.format(
+                    "pageSize (%d) << maxOrder (%d) must not exceed %d", pageSize, maxOrder, MAX_CHUNK_SIZE));
+        }
+        chunkSize <<= 1;
+    }
+    return chunkSize;
+}
+```
+
+## 3.4 构造方法
+
+```
+/**
+ * 单例
+ */
+public static final PooledByteBufAllocator DEFAULT = new PooledByteBufAllocator(PlatformDependent.directBufferPreferred());
+
+/**
+ * Heap PoolArena 数组
+ */
+private final PoolArena<byte[]>[] heapArenas;
+/**
+ * Direct PoolArena 数组
+ */
+private final PoolArena<ByteBuffer>[] directArenas;
+/**
+ * {@link PoolThreadCache} 的 tiny 内存块缓存数组的大小
+ */
+private final int tinyCacheSize;
+/**
+ * {@link PoolThreadCache} 的 small 内存块缓存数组的大小
+ */
+private final int smallCacheSize;
+/**
+ * {@link PoolThreadCache} 的 normal 内存块缓存数组的大小
+ */
+private final int normalCacheSize;
+/**
+ * PoolArenaMetric 数组
+ */
+private final List<PoolArenaMetric> heapArenaMetrics;
+/**
+ * PoolArenaMetric 数组
+ */
+private final List<PoolArenaMetric> directArenaMetrics;
+/**
+ * 线程变量，用于获得 PoolThreadCache 对象。
+ */
+private final PoolThreadLocalCache threadCache;
+/**
+ * Chunk 大小
+ */
+private final int chunkSize;
+/**
+ * PooledByteBufAllocatorMetric 对象
+ */
+private final PooledByteBufAllocatorMetric metric;
+
+public PooledByteBufAllocator() {
+    this(false);
+}
+
+@SuppressWarnings("deprecation")
+public PooledByteBufAllocator(boolean preferDirect) {
+    this(preferDirect, DEFAULT_NUM_HEAP_ARENA, DEFAULT_NUM_DIRECT_ARENA, DEFAULT_PAGE_SIZE, DEFAULT_MAX_ORDER);
+}
+
+@SuppressWarnings("deprecation")
+public PooledByteBufAllocator(int nHeapArena, int nDirectArena, int pageSize, int maxOrder) {
+    this(false, nHeapArena, nDirectArena, pageSize, maxOrder);
+}
+
+/**
+ * @deprecated use
+ * {@link PooledByteBufAllocator#PooledByteBufAllocator(boolean, int, int, int, int, int, int, int, boolean)}
+ */
+@Deprecated
+public PooledByteBufAllocator(boolean preferDirect, int nHeapArena, int nDirectArena, int pageSize, int maxOrder) {
+    this(preferDirect, nHeapArena, nDirectArena, pageSize, maxOrder,
+            DEFAULT_TINY_CACHE_SIZE, DEFAULT_SMALL_CACHE_SIZE, DEFAULT_NORMAL_CACHE_SIZE);
+}
+
+/**
+ * @deprecated use
+ * {@link PooledByteBufAllocator#PooledByteBufAllocator(boolean, int, int, int, int, int, int, int, boolean)}
+ */
+@Deprecated
+public PooledByteBufAllocator(boolean preferDirect, int nHeapArena, int nDirectArena, int pageSize, int maxOrder,
+                              int tinyCacheSize, int smallCacheSize, int normalCacheSize) {
+    this(preferDirect, nHeapArena, nDirectArena, pageSize, maxOrder, tinyCacheSize, smallCacheSize,
+            normalCacheSize, DEFAULT_USE_CACHE_FOR_ALL_THREADS, DEFAULT_DIRECT_MEMORY_CACHE_ALIGNMENT);
+}
+
+public PooledByteBufAllocator(boolean preferDirect, int nHeapArena,
+                              int nDirectArena, int pageSize, int maxOrder, int tinyCacheSize,
+                              int smallCacheSize, int normalCacheSize,
+                              boolean useCacheForAllThreads) {
+    this(preferDirect, nHeapArena, nDirectArena, pageSize, maxOrder,
+            tinyCacheSize, smallCacheSize, normalCacheSize,
+            useCacheForAllThreads, DEFAULT_DIRECT_MEMORY_CACHE_ALIGNMENT);
+}
+
+public PooledByteBufAllocator(boolean preferDirect, int nHeapArena, int nDirectArena, int pageSize, int maxOrder,
+                              int tinyCacheSize, int smallCacheSize, int normalCacheSize,
+                              boolean useCacheForAllThreads, int directMemoryCacheAlignment) {
+    super(preferDirect);
+    // 创建 PoolThreadLocalCache 对象
+    threadCache = new PoolThreadLocalCache(useCacheForAllThreads);
+    this.tinyCacheSize = tinyCacheSize;
+    this.smallCacheSize = smallCacheSize;
+    this.normalCacheSize = normalCacheSize;
+    // 计算 chunkSize
+    chunkSize = validateAndCalculateChunkSize(pageSize, maxOrder);
+
+    if (nHeapArena < 0) {
+        throw new IllegalArgumentException("nHeapArena: " + nHeapArena + " (expected: >= 0)");
+    }
+    if (nDirectArena < 0) {
+        throw new IllegalArgumentException("nDirectArea: " + nDirectArena + " (expected: >= 0)");
+    }
+
+    if (directMemoryCacheAlignment < 0) {
+        throw new IllegalArgumentException("directMemoryCacheAlignment: "
+                + directMemoryCacheAlignment + " (expected: >= 0)");
+    }
+    if (directMemoryCacheAlignment > 0 && !isDirectMemoryCacheAlignmentSupported()) {
+        throw new IllegalArgumentException("directMemoryCacheAlignment is not supported");
+    }
+
+    if ((directMemoryCacheAlignment & -directMemoryCacheAlignment) != directMemoryCacheAlignment) {
+        throw new IllegalArgumentException("directMemoryCacheAlignment: "
+                + directMemoryCacheAlignment + " (expected: power of two)");
+    }
+
+    int pageShifts = validateAndCalculatePageShifts(pageSize);
+
+    if (nHeapArena > 0) {
+        // 创建 heapArenas 数组
+        heapArenas = newArenaArray(nHeapArena);
+        // 创建 metrics 数组
+        List<PoolArenaMetric> metrics = new ArrayList<PoolArenaMetric>(heapArenas.length);
+        // 初始化 heapArenas 和  metrics 数组
+        for (int i = 0; i < heapArenas.length; i ++) {
+            // 创建 HeapArena 对象
+            PoolArena.HeapArena arena = new PoolArena.HeapArena(this,
+                    pageSize, maxOrder, pageShifts, chunkSize,
+                    directMemoryCacheAlignment);
+            heapArenas[i] = arena;
+            metrics.add(arena);
+        }
+        heapArenaMetrics = Collections.unmodifiableList(metrics);
+    } else {
+        heapArenas = null;
+        heapArenaMetrics = Collections.emptyList();
+    }
+
+    if (nDirectArena > 0) {
+        directArenas = newArenaArray(nDirectArena);
+        List<PoolArenaMetric> metrics = new ArrayList<PoolArenaMetric>(directArenas.length);
+        for (int i = 0; i < directArenas.length; i ++) {
+            PoolArena.DirectArena arena = new PoolArena.DirectArena(
+                    this, pageSize, maxOrder, pageShifts, chunkSize, directMemoryCacheAlignment);
+            directArenas[i] = arena;
+            metrics.add(arena);
+        }
+        directArenaMetrics = Collections.unmodifiableList(metrics);
+    } else {
+        directArenas = null;
+        directArenaMetrics = Collections.emptyList();
+    }
+    // 创建 PooledByteBufAllocatorMetric
+    metric = new PooledByteBufAllocatorMetric(this);
+}
+```
+
+- orz 代码比较长，主要是构造方法和校验代码比较长。胖友自己耐心看下。笔者下面只重点讲几个属性。
+
+- `DEFAULT` **静态**属性，PooledByteBufAllocator 单例。绝绝绝大多数情况下，我们不需要自己创建 PooledByteBufAllocator 对象，而只要使用该单例即可。
+
+- `threadCache` 属性，**线程变量**，用于获得 PoolThreadCache 对象。通过该属性，不同线程虽然使用**相同**的 `DEFAULT` 单例，但是可以获得**不同**的 PoolThreadCache 对象。关于 PoolThreadLocalCache 的详细解析，见 [「4. PoolThreadLocalCache」](https://svip.iocoder.cn/Netty/ByteBuf-2-3-ByteBufAllocator-pooled/#) 中。
+
+- `#newArenaArray(int size)` 方法，创建 PoolArena 数组。代码如下：
+
+  ```
+  private static <T> PoolArena<T>[] newArenaArray(int size) {
+      return new PoolArena[size];
+  }
+  ```
+
+## 3.5 newHeapBuffer
+
+`#newHeapBuffer(int initialCapacity, int maxCapacity)` 方法，创建 Heap ByteBuf 对象。代码如下：
+
+```
+@Override
+protected ByteBuf newHeapBuffer(int initialCapacity, int maxCapacity) {
+    // <1> 获得线程的 PoolThreadCache 对象
+    PoolThreadCache cache = threadCache.get();
+    PoolArena<byte[]> heapArena = cache.heapArena;
+
+    // <2.1> 从 heapArena 中，分配 Heap PooledByteBuf 对象，基于池化
+    final ByteBuf buf;
+    if (heapArena != null) {
+        buf = heapArena.allocate(cache, initialCapacity, maxCapacity);
+    // <2.2> 直接创建 Heap ByteBuf 对象，基于非池化
+    } else {
+        buf = PlatformDependent.hasUnsafe() ?
+                new UnpooledUnsafeHeapByteBuf(this, initialCapacity, maxCapacity) :
+                new UnpooledHeapByteBuf(this, initialCapacity, maxCapacity);
+    }
+
+    // <3> 将 ByteBuf 装饰成 LeakAware ( 可检测内存泄露 )的 ByteBuf 对象
+    return toLeakAwareBuffer(buf);
+}
+```
+
+- 代码比较易懂，胖友自己看代码注释。
+
+## 3.6 newDirectBuffer
+
+`#newDirectBuffer(int initialCapacity, int maxCapacity)` 方法，创建 Direct ByteBuf 对象。代码如下：
+
+```
+@Override
+protected ByteBuf newDirectBuffer(int initialCapacity, int maxCapacity) {
+    // <1> 获得线程的 PoolThreadCache 对象
+    PoolThreadCache cache = threadCache.get();
+    PoolArena<ByteBuffer> directArena = cache.directArena;
+
+    final ByteBuf buf;
+    // <2.1> 从 directArena 中，分配 Direct PooledByteBuf 对象，基于池化
+    if (directArena != null) {
+        buf = directArena.allocate(cache, initialCapacity, maxCapacity);
+    // <2.2> 直接创建 Direct ByteBuf 对象，基于非池化
+    } else {
+        buf = PlatformDependent.hasUnsafe() ?
+                UnsafeByteBufUtil.newUnsafeDirectByteBuf(this, initialCapacity, maxCapacity) :
+                new UnpooledDirectByteBuf(this, initialCapacity, maxCapacity);
+    }
+
+    // <3> 将 ByteBuf 装饰成 LeakAware ( 可检测内存泄露 )的 ByteBuf 对象
+    return toLeakAwareBuffer(buf);
+}
+```
+
+- 代码比较易懂，胖友自己看代码注释。
+
+## 3.6 其它方法
+
+其它方法，主要是 Metric 相关操作为主。这里就不再多做哔哔啦，胖友自己感兴趣的话，可以翻翻噢。
+
+# 4. PoolThreadLocalCache
+
+PoolThreadLocalCache ，是 PooledByteBufAllocator 的内部类。继承 FastThreadLocal 抽象类，PoolThreadCache **ThreadLocal** 类。
+
+## 4.1 构造方法
+
+```
+/**
+ * 是否使用缓存
+ */
+private final boolean useCacheForAllThreads;
+
+PoolThreadLocalCache(boolean useCacheForAllThreads) {
+    this.useCacheForAllThreads = useCacheForAllThreads;
+}
+```
+
+## 4.2 leastUsedArena
+
+`#leastUsedArena(PoolArena<T>[] arenas)` 方法，从 PoolArena 数组中，获取线程使用最少的 PoolArena 对象，基于 `PoolArena.numThreadCaches` 属性。通过这样的方式，尽可能让 PoolArena 平均分布在不同线程，从而尽肯能避免线程的**同步和竞争**问题。代码如下：
+
+```
+private <T> PoolArena<T> leastUsedArena(PoolArena<T>[] arenas) {
+    // 一个都没有，返回 null
+    if (arenas == null || arenas.length == 0) {
+        return null;
+    }
+
+    // 获得第零个 PoolArena 对象
+    PoolArena<T> minArena = arenas[0];
+    // 比较后面的 PoolArena 对象，选择线程使用最少的
+    for (int i = 1; i < arenas.length; i++) {
+        PoolArena<T> arena = arenas[i];
+        if (arena.numThreadCaches.get() < minArena.numThreadCaches.get()) {
+            minArena = arena;
+        }
+    }
+
+    return minArena;
+}
+```
+
+## 4.3 initialValue
+
+`#initialValue()` 方法，初始化线程的 PoolThreadCache 对象。代码如下：
+
+```
+@Override
+protected synchronized PoolThreadCache initialValue() {
+    // 分别获取线程使用最少的 heapArena 和 directArena 对象，基于 `PoolArena.numThreadCaches` 属性。
+    final PoolArena<byte[]> heapArena = leastUsedArena(heapArenas);
+    final PoolArena<ByteBuffer> directArena = leastUsedArena(directArenas);
+
+    // 创建开启缓存的 PoolThreadCache 对象
+    Thread current = Thread.currentThread();
+    if (useCacheForAllThreads || current instanceof FastThreadLocalThread) {
+        return new PoolThreadCache(
+                heapArena, directArena, tinyCacheSize, smallCacheSize, normalCacheSize,
+                DEFAULT_MAX_CACHED_BUFFER_CAPACITY, DEFAULT_CACHE_TRIM_INTERVAL);
+    }
+
+    // 创建不进行缓存的 PoolThreadCache 对象
+    // No caching so just use 0 as sizes.
+    return new PoolThreadCache(heapArena, directArena, 0, 0, 0, 0, 0);
+}
+```
+
+## 4.4 onRemoval
+
+`#onRemoval(PoolThreadCache threadCache)` 方法，释放 PoolThreadCache 对象的缓存。代码如下：
+
+```
+@Override
+protected void onRemoval(PoolThreadCache threadCache) {
+    // 释放缓存
+    threadCache.free();
+}
+```
+
+# 666. 彩蛋
+
+推荐阅读文章：
+
+- 杨武兵 [《netty源码分析系列——PooledByteBuf&PooledByteBufAllocator》](https://my.oschina.net/ywbrj042/blog/909925)
+- wojiushimogui [《Netty源码分析：PooledByteBufAllocator》](https://blog.csdn.net/u010412719/article/details/78298811)
+- RobertoHuang [《死磕Netty源码之内存分配详解(一)(PooledByteBufAllocator)》](https://blog.csdn.net/RobertoHuang/article/details/81046419)
\ No newline at end of file
diff --git a/netty/42-Netty 源码解析-Buffer 之 Jemalloc（一）简介.md b/netty/42-Netty 源码解析-Buffer 之 Jemalloc（一）简介.md
new file mode 100644
index 0000000..1439be9
--- /dev/null
+++ b/netty/42-Netty 源码解析-Buffer 之 Jemalloc（一）简介.md	
@@ -0,0 +1,74 @@
+# 精尽 Netty 源码解析 —— Buffer 之 Jemalloc（一）简介
+
+# 1. 概述
+
+在看 Netty 对 Jemalloc 内存管理算法的具体代码实现之前，笔者想先通过这篇文章，**简单**阐述三个问题：
+
+- Netty 为什么要实现内存管理？
+- Netty 为什么选择 Jemalloc 算法？
+- Jemalloc 的实现原理？
+
+因为笔者对内存管理的了解程度，处于青铜级别，所以为了更好的让大家理解，本文会以引用牛 x 大佬的文章为主。
+
+# 2. Netty 为什么要实现内存管理
+
+**老艿艿的理解**
+
+在 Netty 中，IO 读写必定是非常频繁的操作，而考虑到更高效的网络传输性能，Direct ByteBuffer 必然是最合适的选择。但是 Direct ByteBuffer 的申请和释放是高成本的操作，那么进行**池化**管理，多次重用是比较有效的方式。但是，不同于一般于我们常见的对象池、连接池等**池化**的案例，ByteBuffer 是有**大小**一说。又但是，申请多大的 Direct ByteBuffer 进行池化又会是一个大问题，太大会浪费内存，太小又会出现频繁的扩容和内存复制！！！所以呢，就需要有一个合适的内存管理算法，解决**高效分配内存**的同时又解决**内存碎片化**的问题。
+
+**官方的说法**
+
+> FROM [《Netty 学习笔记 —— Pooled buffer》](https://skyao.gitbooks.io/learning-netty/content/buffer/pooled_buffer.html)
+>
+> Netty 4.x 增加了 Pooled Buffer，实现了高性能的 buffer 池，分配策略则是结合了 buddy allocation 和 slab allocation 的 **jemalloc** 变种，代码在`io.netty.buffer.PoolArena` 中。
+>
+> 官方说提供了以下优势：
+>
+> - 频繁分配、释放 buffer 时减少了 GC 压力。
+> - 在初始化新 buffer 时减少内存带宽消耗( 初始化时不可避免的要给buffer数组赋初始值 )。
+> - 及时的释放 direct buffer 。
+
+**hushi55 大佬的理解**
+
+> > C/C++ 和 java 中有个围城，城里的想出来，城外的想进去！**
+>
+> 这个围城就是自动内存管理！
+>
+> **Netty 4 buffer 介绍**
+>
+> Netty4 带来一个与众不同的特点是其 ByteBuf 的实现，相比之下，通过维护两个独立的读写指针， 要比 `io.netty.buffer.ByteBuf` 简单不少，也会更高效一些。不过，Netty 的 ByteBuf 带给我们的最大不同，就是他不再基于传统 JVM 的 GC 模式，相反，它采用了类似于 C++ 中的 malloc/free 的机制，需要开发人员来手动管理回收与释放。从手动内存管理上升到GC，是一个历史的巨大进步， 不过，在20年后，居然有曲线的回归到了手动内存管理模式，正印证了马克思哲学观： **社会总是在螺旋式前进的，没有永远的最好。**
+>
+> **① GC 内存管理分析**
+>
+> 的确，就内存管理而言，GC带给我们的价值是不言而喻的，不仅大大的降低了程序员的心智包袱， 而且，也极大的减少了内存管理带来的 Crash 困扰，为函数式编程（大量的临时对象）、脚本语言编程带来了春天。 并且，高效的GC算法也让大部分情况下程序可以有更高的执行效率。 不过，也有很多的情况，可能是手工内存管理更为合适的。譬如：
+>
+> - 对于类似于业务逻辑相对简单，譬如网络路由转发型应用（很多erlang应用其实是这种类型）， 但是 QPS 非常高，比如1M级，在这种情况下，在每次处理中即便产生1K的垃圾，都会导致频繁的GC产生。 在这种模式下，erlang 的按进程回收模式，或者是 C/C++ 的手工回收机制，效率更高。
+> - Cache 型应用，由于对象的存在周期太长，GC 基本上就变得没有价值。
+>
+> 所以，理论上，尴尬的GC实际上比较适合于处理介于这 2 者之间的情况： 对象分配的频繁程度相比数据处理的时间要少得多的，但又是相对短暂的， 典型的，对于OLTP型的服务，处理能力在 1K QPS 量级，每个请求的对象分配在 10K-50K 量级， 能够在 5-10s 的时间内进行一 次younger GC ，每次GC的时间可以控制在 10ms 水平上， 这类的应用，实在是太适合 GC 行的模式了，而且结合 Java 高效的分代 GC ，简直就是一个理想搭配。
+>
+> **② 影响**
+>
+> Netty 4 引入了手工内存的模式，我觉得这是一大创新，这种模式甚至于会延展， 应用到 Cache 应用中。实际上，结合 JVM 的诸多优秀特性，如果用 Java 来实现一个 Redis 型 Cache、 或者 In-memory SQL Engine，或者是一个 Mongo DB，我觉得相比 C/C++ 而言，都要更简单很多。 实际上，JVM 也已经提供了打通这种技术的机制，就是 Direct Memory 和 Unsafe 对象。 基于这个基础，我们可以像 C 语言一样直接操作内存。实际上，Netty4 的 ByteBuf 也是基于这个基础的。
+
+# 3. Netty 为什么选择 Jemalloc 算法
+
+推荐直接阅读
+
+- bhpike65 [《内存优化总结:ptmalloc、tcmalloc 和 jemalloc》](http://www.cnhalo.net/2016/06/13/memory-optimize/)
+
+# 4. Jemalloc 的实现原理
+
+推荐直接阅读
+
+- Hypercube [《自顶向下深入分析Netty（十）–JEMalloc分配算法》](https://www.jianshu.com/p/15304cd63175)
+- 高兴的博客 [《jemalloc和内存管里》](http://www.cnblogs.com/gaoxing/p/4253833.html)
+- 沧行 [《Netty内存池实现》](https://www.jianshu.com/p/8d894e42b6e6) 这篇，有几个图，非常非常非常不错。
+
+# 666. 彩蛋
+
+推荐的博客比较多，如果你和笔者一样对内存管理的理解处于**青铜**级别，可能看完这几篇博文，很大可能还是一脸懵逼+一脸懵逼+一脸懵逼。
+
+这是个比较正常的情况。胖友可以跟着笔者继续看看 Netty 对 Jemalloc 算法的具体实现后，再回过头继续理解下这几篇文章。
+
+另外，后续的文章，会有大量大量大量的**位运算**，所以当胖友看到不熟悉的**位运算**，可以看看 [《Java 位运算(移位、位与、或、异或、非）》](https://blog.csdn.net/xiaochunyong/article/details/7748713) 。
\ No newline at end of file
diff --git a/netty/43-Netty 源码解析-Buffer 之 Jemalloc（二）PoolChunk.assets/01.png b/netty/43-Netty 源码解析-Buffer 之 Jemalloc（二）PoolChunk.assets/01.png
new file mode 100644
index 0000000..f29e756
Binary files /dev/null and b/netty/43-Netty 源码解析-Buffer 之 Jemalloc（二）PoolChunk.assets/01.png differ
diff --git a/netty/43-Netty 源码解析-Buffer 之 Jemalloc（二）PoolChunk.assets/02.png b/netty/43-Netty 源码解析-Buffer 之 Jemalloc（二）PoolChunk.assets/02.png
new file mode 100644
index 0000000..b2fa864
Binary files /dev/null and b/netty/43-Netty 源码解析-Buffer 之 Jemalloc（二）PoolChunk.assets/02.png differ
diff --git a/netty/43-Netty 源码解析-Buffer 之 Jemalloc（二）PoolChunk.assets/03.png b/netty/43-Netty 源码解析-Buffer 之 Jemalloc（二）PoolChunk.assets/03.png
new file mode 100644
index 0000000..957dd20
Binary files /dev/null and b/netty/43-Netty 源码解析-Buffer 之 Jemalloc（二）PoolChunk.assets/03.png differ
diff --git a/netty/43-Netty 源码解析-Buffer 之 Jemalloc（二）PoolChunk.assets/04.png b/netty/43-Netty 源码解析-Buffer 之 Jemalloc（二）PoolChunk.assets/04.png
new file mode 100644
index 0000000..ac2f246
Binary files /dev/null and b/netty/43-Netty 源码解析-Buffer 之 Jemalloc（二）PoolChunk.assets/04.png differ
diff --git a/netty/43-Netty 源码解析-Buffer 之 Jemalloc（二）PoolChunk.md b/netty/43-Netty 源码解析-Buffer 之 Jemalloc（二）PoolChunk.md
new file mode 100644
index 0000000..526f803
--- /dev/null
+++ b/netty/43-Netty 源码解析-Buffer 之 Jemalloc（二）PoolChunk.md	
@@ -0,0 +1,1063 @@
+# 精尽 Netty 源码解析 —— Buffer 之 Jemalloc（二）PoolChunk
+
+# 1. 概述
+
+> 老艿艿：如下阐释的内容，参考 Hypercube [《自顶向下深入分析Netty（十）–JEMalloc分配算法》](https://www.jianshu.com/p/15304cd63175) 。
+
+为了提高内存**分配效率**并减少**内存碎片**，Jemalloc 算法将每个 Arena 切分成多个**小块** Chunk 。但是实际上，每个 Chunk 依然是**相当大**的内存块。因为在 Jemalloc 建议为 4MB ，Netty 默认使用为 16MB 。
+
+为了进一步提供提高内存**分配效率**并减少**内存碎片**，Jemalloc 算法将每个 Chunk 切分成多个**小块** Page 。一个典型的切分是将 Chunk 切分为 2048 块 Page ，Netty 也是如此，因此 Page 的大小为：`16MB / 2048 = 8KB` 。
+
+一个好的内存分配算法，应使得已分配内存块尽可能保持连续，这将大大减少内部碎片，由此 Jemalloc 使用[伙伴分配算法](https://svip.iocoder.cn/Netty/ByteBuf-3-2-Jemalloc-chunk/#)尽可能提高连续性。**伙伴分配算法**的示意图如下：
+
+> 可能很多胖友不了解【伙伴分配算法】，感兴趣的话，可以看看 [《伙伴分配器的一个极简实现》](https://coolshell.cn/articles/10427.html) 了解了解。
+>
+> 当然，Netty PoolChunk 也是基于【伙伴分配算法】实现。
+
+[![满二叉树](43-Netty 源码解析-Buffer 之 Jemalloc（二）PoolChunk.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_09_04/01.png)满二叉树
+
+图中**最底层**表示一个被切分为 2048 个 Page 的 Chunk 块。自底向上，每一层节点作为上一层的子节点构造出一棵[满二叉树](https://baike.baidu.com/item/满二叉树)，然后按层分配满足要求的内存块。以待分配序列 8KB、16KB、8KB 为例分析分配过程( 假设每个 Page 大小 8KB )：
+
+1. 8KB —— 需要一个 Page ，第 11 层满足要求，故分配 *2048* 节点即 **Page0** 。
+2. 16KB —— 需要两个Page ，故需要在第 10 层进行分配，而 *1024* 的子节点 *2048* 已分配，从左到右找到满足要求的 *1025* 节点，故分配节点 *1025* 即**Page2** 和 **Page3** 。
+3. 8KB —— 需要一个 Page ，第 11 层满足要求，但是 *2048* 已分配，从左到右找到 *2049* 节点即 **Page1** 进行分配。
+
+总结来说：
+
+- 分配结束后，已分配连续的 **Page0 - Page3** 。这样的连续内存块，大大减少内部碎片并提高**内存使用率**。
+- 通过使用**满二叉树**这样的树结构，提升检索到可用 Page 的速度，从而提高内存**分配效率**。
+
+# 2. PoolChunk
+
+`io.netty.buffer.PoolChunk` ，实现 PoolChunkMetric 接口，Netty 对 Jemalloc Chunk 的实现类。
+
+## 2.1 构造方法
+
+```
+/**
+ * 所属 Arena 对象
+ */
+final PoolArena<T> arena;
+/**
+ * 内存空间。
+ *
+ * @see PooledByteBuf#memory
+ */
+final T memory;
+/**
+ * 是否非池化
+ *
+ * @see #PoolChunk(PoolArena, Object, int, int) 非池化。当申请的内存大小为 Huge 类型时，创建一整块 Chunk ，并且不拆分成若干 Page
+ * @see #PoolChunk(PoolArena, Object, int, int, int, int, int) 池化
+ */
+final boolean unpooled;
+/**
+ * TODO 芋艿
+ */
+final int offset;
+
+/**
+ * 分配信息满二叉树
+ *
+ * index 为节点编号
+ */
+private final byte[] memoryMap;
+/**
+ * 高度信息满二叉树
+ *
+ * index 为节点编号
+ */
+private final byte[] depthMap;
+/**
+ * PoolSubpage 数组
+ */
+private final PoolSubpage<T>[] subpages;
+/**
+ * 判断分配请求内存是否为 Tiny/Small ，即分配 Subpage 内存块。
+ *
+ * Used to determine if the requested capacity is equal to or greater than pageSize.
+ */
+private final int subpageOverflowMask;
+/**
+ * Page 大小，默认 8KB = 8192B
+ */
+private final int pageSize;
+/**
+ * 从 1 开始左移到 {@link #pageSize} 的位数。默认 13 ，1 << 13 = 8192 。
+ *
+ * 具体用途，见 {@link #allocateRun(int)} 方法，计算指定容量所在满二叉树的层级。
+ */
+private final int pageShifts;
+/**
+ * 满二叉树的高度。默认为 11 。
+ */
+private final int maxOrder;
+/**
+ * Chunk 内存块占用大小。默认为 16M = 16 * 1024  。
+ */
+private final int chunkSize;
+/**
+ * log2 {@link #chunkSize} 的结果。默认为 log2( 16M ) = 24 。
+ */
+private final int log2ChunkSize;
+/**
+ * 可分配 {@link #subpages} 的数量，即数组大小。默认为 1 << maxOrder = 1 << 11 = 2048 。
+ */
+private final int maxSubpageAllocs;
+/**
+ * 标记节点不可用。默认为 maxOrder + 1 = 12 。
+ *
+ * Used to mark memory as unusable
+ */
+private final byte unusable;
+
+/**
+ * 剩余可用字节数
+ */
+private int freeBytes;
+
+/**
+ * 所属 PoolChunkList 对象
+ */
+PoolChunkList<T> parent;
+/**
+ * 上一个 Chunk 对象
+ */
+PoolChunk<T> prev;
+/**
+ * 下一个 Chunk 对象
+ */
+PoolChunk<T> next;
+
+// 构造方法一：
+  1: PoolChunk(PoolArena<T> arena, T memory, int pageSize, int maxOrder, int pageShifts, int chunkSize, int offset) {
+  2:     // 池化
+  3:     unpooled = false;
+  4:     this.arena = arena;
+  5:     this.memory = memory;
+  6:     this.pageSize = pageSize;
+  7:     this.pageShifts = pageShifts;
+  8:     this.maxOrder = maxOrder;
+  9:     this.chunkSize = chunkSize;
+ 10:     this.offset = offset;
+ 11:     unusable = (byte) (maxOrder + 1);
+ 12:     log2ChunkSize = log2(chunkSize);
+ 13:     subpageOverflowMask = ~(pageSize - 1);
+ 14:     freeBytes = chunkSize;
+ 15: 
+ 16:     assert maxOrder < 30 : "maxOrder should be < 30, but is: " + maxOrder;
+ 17:     maxSubpageAllocs = 1 << maxOrder;
+ 18: 
+ 19:     // 初始化 memoryMap 和 depthMap
+ 20:     // Generate the memory map.
+ 21:     memoryMap = new byte[maxSubpageAllocs << 1];
+ 22:     depthMap = new byte[memoryMap.length];
+ 23:     int memoryMapIndex = 1;
+ 24:     for (int d = 0; d <= maxOrder; ++ d) { // move down the tree one level at a time
+ 25:         int depth = 1 << d;
+ 26:         for (int p = 0; p < depth; ++ p) {
+ 27:             // in each level traverse left to right and set value to the depth of subtree
+ 28:             memoryMap[memoryMapIndex] = (byte) d;
+ 29:             depthMap[memoryMapIndex] = (byte) d;
+ 30:             memoryMapIndex ++;
+ 31:         }
+ 32:     }
+ 33: 
+ 34:     // 初始化 subpages
+ 35:     subpages = newSubpageArray(maxSubpageAllocs);
+ 36: }
+
+
+// 构造方法二： 
+ 38: /** Creates a special chunk that is not pooled. */
+ 39: PoolChunk(PoolArena<T> arena, T memory, int size, int offset) {
+ 40:     // 非池化
+ 41:     unpooled = true;
+ 42:     this.arena = arena;
+ 43:     this.memory = memory;
+ 44:     this.offset = offset;
+ 45:     memoryMap = null;
+ 46:     depthMap = null;
+ 47:     subpages = null;
+ 48:     subpageOverflowMask = 0;
+ 49:     pageSize = 0;
+ 50:     pageShifts = 0;
+ 51:     maxOrder = 0;
+ 52:     unusable = (byte) (maxOrder + 1);
+ 53:     chunkSize = size;
+ 54:     log2ChunkSize = log2(chunkSize);
+ 55:     maxSubpageAllocs = 0;
+ 56: }
+```
+
+- ```
+  arena
+  ```
+
+   
+
+  属性，所属 Arena 对象。详细解析，见
+
+   
+
+  《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（五）PoolArena》
+
+   
+
+  。
+
+  - `memory` 属性，内存空间。即**用于** `PooledByteBuf.memory` 属性，有 Direct ByteBuffer 和 `byte[]` 字节数组。
+
+  - ```
+    unpooled
+    ```
+
+     
+
+    属性，是否非池化。
+
+    - `unpooled = false` ，池化，对应构造方法**一**。默认情况下，对于 分配 16M **以内**的内存空间时，Netty 会分配一个 Normal 类型的 Chunk 块。并且，该 Chunk 块在使用完后，进行池化缓存，重复使用。
+    - `unpooled = true` ，非池化，对应构造方法**二**。默认情况下，对于分配 16M **以上**的内存空间时，Netty 会分配一个 Huge 类型的**特殊**的 Chunk 块。并且，由于 Huge 类型的 Chunk 占用内存空间较大，比较特殊，所以该 Chunk 块在使用完后，立即释放，不进行重复使用。
+    - 笔者对 Netty 对 Jemalloc 不同类型的内存块的整理，如下图所示：[![内存块分类](43-Netty 源码解析-Buffer 之 Jemalloc（二）PoolChunk.assets/02.png)](http://static.iocoder.cn/images/Netty/2018_09_04/02.png)内存块分类
+
+- Jemalloc 基于【伙伴分配算法】分配 Chunk 中的 Page 节点。Netty 实现的伙伴分配算法中，构造了**两颗**满二叉树。因为满二叉树非常适合数组存储，Netty 使用两个字节数组 `memoryMap` 和 `depthMap` 来分别表示**分配信息**满二叉树、**高度信息**满二叉树。如下图所示：[![满二叉树](43-Netty 源码解析-Buffer 之 Jemalloc（二）PoolChunk.assets/03.png)](http://static.iocoder.cn/images/Netty/2018_09_04/03.png)满二叉树
+
+  - `maxOrder` 属性，满二叉树的高度。默认为 11 。注意，层高是从 0 开始。
+
+  - `maxSubpageAllocs` 属性，可分配的 Page 的数量。默认为 2048 ，在【第 17 行】的代码进行初始化。在第 11 层，可以看到 Page0 - Page2047 这 2048 个节点，也也符合 `1 << maxOrder = 11 << 11 = 2048` 的计算。
+
+  - 在【第 19 至 32 行】的代码，`memoryMap` 和 `depthMap` 进行满二叉树的初始化。
+
+    - 数组大小为 `maxSubpageAllocs << 1 = 2048 << 1 = 4096` 。
+
+    - 数组下标为**左图**对应的节点编号。在【第 23 行】的代码，从 `memoryMapIndex = 1` 代码可以看出，满二叉树的节点编号是**从 1 开始**。省略 0 是因为这样更容易计算父子关系：子节点加倍，父节点减半，例如：512 的子节点为 1024( `512 * 2` )和 1025( `512 * 2 + 1` )。
+
+    - 初始时，`memoryMap` 和 `depthMap` 相等，值为**节点高度**。例如：
+
+      ```
+      memoryMap[1024] = depthMap[1024] = 10;
+      ```
+
+      - 对应**右图**。
+
+    - 分配节点时，
+
+      ```
+      depthMap
+      ```
+
+       
+
+      的值保持
+
+      不变
+
+      ( 因为，节点的高度没发生变化 )，
+
+      ```
+      memoryMap
+      ```
+
+       
+
+      的值发生
+
+      变化
+
+      ( 因为，节点的分配信息发生变化 )。当一个节点被分配后，该节点的值设为
+
+       
+
+      ```
+      unusable
+      ```
+
+      ( 标记节点不可用。默认为
+
+       
+
+      ```
+      maxOrder + 1 = 12
+      ```
+
+       
+
+      ) 。
+
+      并且，会更新祖先节点的值为其子节点较小的值
+
+      ( 因为，祖先节点共用该节点的 Page 内存；同时，一个父节点有两个子节点，一个节点不可用后，另一个子节点可能可用，所以更新为其子节点
+
+      较小
+
+      的值。 )。举个例子，下图表示随着节点 4 分配而更新祖先节点的过程，其中每个节点的第一个数字表示
+
+      节点编号
+
+      ，第二个数字表示
+
+      节点高度
+
+      ：
+
+      ![例子](43-Netty 源码解析-Buffer 之 Jemalloc（二）PoolChunk.assets/04.png)
+
+      例子
+
+      - 节点 4 被**完全**分配，将高度值设置为 12 表示不可用。
+      - 节点 4 的父节点 2，将高度值更新为两个子节点的较小值。其他祖先节点亦然，直到高度值更新至根节点。
+
+    - ```
+      memoryMap
+      ```
+
+       
+
+      数组的值，总结为 3 种情况：
+
+      - 1、`memoryMap[id] = depthMap[id]` ，该节点没有被分配。
+      - 2、`最大高度 >= memoryMap[id] > depthMap[id]` ，至少有一个子节点被分配，不能再分配该高度满足的内存，但可以根据实际分配较小一些的内存。比如，上图中父节点 2 分配了子节点 4，值从 1 更新为 2，表示该节点不能再分配 8MB 的只能最大分配 4MB 内存，即只剩下节点 5 可用。
+      - 3、`memoryMap[id] = 最大高度 + 1` ，该节点及其子节点已被**完全**分配，没有剩余空间。
+
+- Chunk 相关字段
+
+  - `chunkSize` 属性，Chunk 内存块占用大小。默认为 `16M = 16 * 1024KB` 。
+
+  - `log2ChunkSize` 属性，`log2(chunkSize)` 的结果。默认为 `log2( 16M ) = 24` 。 代码如下：
+
+    ```
+    private static final int INTEGER_SIZE_MINUS_ONE = Integer.SIZE - 1; // 32 - 1 = 31
+    
+    private static int log2(int val) {
+        // compute the (0-based, with lsb = 0) position of highest set bit i.e, log2
+        return INTEGER_SIZE_MINUS_ONE - Integer.numberOfLeadingZeros(val);
+    }
+    ```
+
+    - x
+
+  - `freeBytes` 属性，剩余可用字节数。
+
+- Page 相关字段
+
+  - `pageSize` 属性，每个 Page 的大小。默认为 `8KB = 8192B` 。
+  - `pageShifts` 属性，从 1 开始左移到 `pageSize` 的位数。默认 13 ，`1 << 13 = 8192` 。具体用于计算指定容量所在满二叉树的层级，详细解析，见 [「2.2.1 allocateRun」](https://svip.iocoder.cn/Netty/ByteBuf-3-2-Jemalloc-chunk/#) 。
+
+- SubPage 相关字段
+
+  - 详细解析，见 [《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（三）PoolSubpage》](http://svip.iocoder.cn/Netty/ByteBuf-3-3-Jemalloc-subpage) 。
+
+  - `subpages` 属性，PoolSubpage 数组。每个节点对应一个 PoolSubpage 对象。因为实际上，每个 Page 还是**比较大**的内存块，可以进一步切分成小块 SubPage 。在【第 35 行】的代码，调用 `#newSubpageArray(int size)` 方法，进行初始化。代码如下：
+
+    ```
+    private PoolSubpage<T>[] newSubpageArray(int size) {
+        return new PoolSubpage[size];
+    }
+    ```
+
+    - 默认情况下，数组大小为 `maxSubpageAllocs = 2048` 。
+
+  - `subpageOverflowMask` 属性，判断分配请求内存是否为 **Tiny/Small** ，即分配 Subpage 内存块。默认，-8192 。在【13 行】的代码进行初始化。对于 -8192 的二进制，除了首 bits 为 1 ，其它都为 0 。这样，对于小于 8K 字节的申请，求 `subpageOverflowMask & length` 都等于 0 ；对于大于 8K 字节的申请，求 `subpageOverflowMask & length` 都**不**等于 0 。相当于说，做了 `if ( length < pageSize )` 的计算优化。
+
+- ChunkList 相关字段
+
+  - 详细解析，见 [《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（四）PoolChunkList》](http://svip.iocoder.cn/Netty/ByteBuf-3-4-Jemalloc-chunkList) 。
+  - `parent` 属性，所属 PoolChunkList 对象。
+  - `prev` 属性，上一个 Chunk 对象。
+  - `next` 属性，下一个 Chunk 对象。
+
+内容比较“厚实”( 😈 字比较多 )，建议胖友再读一遍，再看下面的代码具体实现。
+
+## 2.2 allocate
+
+`#allocate(int normCapacity)` 方法，分配内存空间。代码如下：
+
+```
+1: long allocate(int normCapacity) {
+2:     // 大于等于 Page 大小，分配 Page 内存块
+3:     if ((normCapacity & subpageOverflowMask) != 0) { // >= pageSize
+4:         return allocateRun(normCapacity);
+5:     // 小于 Page 大小，分配 Subpage 内存块
+6:     } else {
+7:         return allocateSubpage(normCapacity);
+8:     }
+9: }
+```
+
+- 第 2 至 4 行：当申请的 `normCapacity` 大于等于 Page 大小时，调用 `#allocateRun(int normCapacity)` 方法，分配 Page 内存块。详细解析，见 [「2.2.1 allocateRun」](https://svip.iocoder.cn/Netty/ByteBuf-3-2-Jemalloc-chunk/#) 中。
+- 第 5 至 8 行：调用 `#allocateSubpage(int normCapacity)` 方法，分配 Subpage 内存块。详细解析，见 [「2.2.1 allocateSubpage」](https://svip.iocoder.cn/Netty/ByteBuf-3-2-Jemalloc-chunk/#) 中。
+
+### 2.2.1 allocateRun
+
+`#allocateRun(int normCapacity)` 方法，分配 Page 内存块。代码如下：
+
+```
+   /**
+    * Allocate a run of pages (>=1)
+    *
+    * @param normCapacity normalized capacity
+    * @return index in memoryMap
+    */
+ 1: private long allocateRun(int normCapacity) {
+ 2:     // 获得层级
+ 3:     int d = maxOrder - (log2(normCapacity) - pageShifts);
+ 4:     // 获得节点
+ 5:     int id = allocateNode(d);
+ 6:     // 未获得到节点，直接返回
+ 7:     if (id < 0) {
+ 8:         return id;
+ 9:     }
+10:     // 减少剩余可用字节数
+11:     freeBytes -= runLength(id);
+12:     return id;
+13: }
+```
+
+- 第 3 行：获得层级。
+
+- 第 5 行：调用
+
+   
+
+  ```
+  #allocateNode(int normCapacity)
+  ```
+
+   
+
+  方法，分配节点。详细解析，见
+
+   
+
+  「2.2.3 allocateNode」
+
+   
+
+  中。
+
+  - 第 7 至 9 行：未获得到节点，直接返回。
+
+- 第 11 行：调用 `#runLength(int id)` 方法，计算使用节点的字节数，并减少剩余可用字节数。代码如下：
+
+  ```
+  private int runLength(int id) {
+      // represents the size in #bytes supported by node 'id' in the tree
+      return 1 << log2ChunkSize - depth(id);
+  }
+  
+  private byte depth(int id) {
+      return depthMap[id];
+  }
+  ```
+
+### 2.2.2 allocateSubpage
+
+> 老艿艿：本小节，胖友先看完 [《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（三）PoolSubpage》](http://svip.iocoder.cn/Netty/ByteBuf-3-3-Jemalloc-subpage) 。
+
+`#allocateSubpage(int normCapacity)` 方法，分配 Subpage 内存块。代码如下：
+
+```
+   /**
+    * Create/ initialize a new PoolSubpage of normCapacity
+    * Any PoolSubpage created/ initialized here is added to subpage pool in the PoolArena that owns this PoolChunk
+    *
+    * @param normCapacity normalized capacity
+    * @return index in memoryMap
+    */
+ 1: private long allocateSubpage(int normCapacity) {
+ 2:     // 获得对应内存规格的 Subpage 双向链表的 head 节点
+ 3:     // Obtain the head of the PoolSubPage pool that is owned by the PoolArena and synchronize on it.
+ 4:     // This is need as we may add it back and so alter the linked-list structure.
+ 5:     PoolSubpage<T> head = arena.findSubpagePoolHead(normCapacity);
+ 6:     // 加锁，分配过程会修改双向链表的结构，会存在多线程的情况。
+ 7:     synchronized (head) {
+ 8:         // 获得最底层的一个节点。Subpage 只能使用二叉树的最底层的节点。
+ 9:         int d = maxOrder; // subpages are only be allocated from pages i.e., leaves
+10:         int id = allocateNode(d);
+11:         // 获取失败，直接返回
+12:         if (id < 0) {
+13:             return id;
+14:         }
+15: 
+16:         final PoolSubpage<T>[] subpages = this.subpages;
+17:         final int pageSize = this.pageSize;
+18: 
+19:         // 减少剩余可用字节数
+20:         freeBytes -= pageSize;
+21: 
+22:         // 获得节点对应的 subpages 数组的编号
+23:         int subpageIdx = subpageIdx(id);
+24:         // 获得节点对应的 subpages 数组的 PoolSubpage 对象
+25:         PoolSubpage<T> subpage = subpages[subpageIdx];
+26:         // 初始化 PoolSubpage 对象
+27:         if (subpage == null) { // 不存在，则进行创建 PoolSubpage 对象
+28:             subpage = new PoolSubpage<T>(head, this, id, runOffset(id), pageSize, normCapacity);
+29:             subpages[subpageIdx] = subpage;
+30:         } else { // 存在，则重新初始化 PoolSubpage 对象
+31:             subpage.init(head, normCapacity);
+32:         }
+33:         // 分配 PoolSubpage 内存块
+34:         return subpage.allocate();
+35:     }
+36: }
+```
+
+- 第 5 行：调用 `PoolArena#findSubpagePoolHead(int normCapacity)` 方法，获得对应内存规格的 Subpage 双向链表的 `head` 节点。详细解析，见 [《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（五）PoolArena》](http://svip.iocoder.cn/Netty/ByteBuf-3-5-Jemalloc-Arena) 。
+
+- 第 7 行：`synchronized` 加锁，分配过程会修改双向链表的结构，会存在**多线程**的情况。
+
+- 第 8 至 10 行：调用
+
+   
+
+  ```
+  #allocateNode(int d)
+  ```
+
+   
+
+  方法，获得最底层的一个节点。
+
+  Subpage 只能使用二叉树的最底层的节点
+
+  。
+
+  - 第 11 至 14 行：获取失败，直接返回。
+  - 第 20 行：减少剩余可用字节数。
+
+- 第 23 至 34 行：分配 PoolSubpage 内存块。
+
+  - 第 23 行：调用 `#subpageIdx(int id)` 方法，获得节点对应的 `subpages` 数组的编号。代码如下：
+
+    ```
+    private int subpageIdx(int memoryMapIdx) {
+        return memoryMapIdx ^ maxSubpageAllocs; // remove highest set bit, to get offset
+    }
+    ```
+
+    - 去掉最高位( bit )。例如节点 2048 计算后的结果为 0 。
+
+  - 第 25 行：获得节点对应的 `subpages` 数组的 PoolSubpage 对象。
+
+  - 第 26 至 32 行：初始化 PoolSubpage 对象。
+
+  - 第 34 行：调用 `PoolSubpage#allocate()` 方法，分配 PoolSubpage 内存块。
+
+### 2.2.3 allocateNode
+
+`#allocateNode(int normCapacity)` 方法，分配节点。代码如下：
+
+```
+   /**
+    * Algorithm to allocate an index in memoryMap when we query for a free node
+    * at depth d
+    *
+    * @param d depth
+    * @return index in memoryMap
+    */
+ 1: private int allocateNode(int d) {
+ 2:     int id = 1;
+ 3:     int initial = - (1 << d); // has last d bits = 0 and rest all = 1
+ 4:     // 获得根节点的指值。
+ 5:     // 如果根节点的值，大于 d ，说明，第 d 层没有符合的节点，也就是说 [0, d-1] 层也没有符合的节点。即，当前 Chunk 没有符合的节点。
+ 6:     byte val = value(id);
+ 7:     if (val > d) { // unusable
+ 8:         return -1;
+ 9:     }
+10:     // 获得第 d 层，匹配的节点。
+11:     // id & initial 来保证，高度小于 d 会继续循环
+12:     while (val < d || (id & initial) == 0) { // id & initial == 1 << d for all ids at depth d, for < d it is 0
+13:         // 进入下一层
+14:         // 获得左节点的编号
+15:         id <<= 1;
+16:         // 获得左节点的值
+17:         val = value(id);
+18:         // 如果值大于 d ，说明，以左节点作为根节点形成虚拟的虚拟满二叉树，没有符合的节点。
+19:         if (val > d) {
+20:             // 获得右节点的编号
+21:             id ^= 1;
+22:             // 获得右节点的值
+23:             val = value(id);
+24:         }
+25:     }
+26: 
+27:     // 校验获得的节点值合理
+28:     byte value = value(id);
+29:     assert value == d && (id & initial) == 1 << d : String.format("val = %d, id & initial = %d, d = %d",
+30:             value, id & initial, d);
+31: 
+32:     // 更新获得的节点不可用
+33:     setValue(id, unusable); // mark as unusable
+34:     // 更新获得的节点的祖先都不可用
+35:     updateParentsAlloc(id);
+36: 
+37:     // 返回节点编号
+38:     return id;
+39: }
+```
+
+- 第 3 行：通过 `- (1 << d)` 计算，获得 `initial` 。用于【第 12 行】的代码，`id & initial` ，来保证，高度小于 `d` 会继续**循环**。
+
+- 第 6 行：获得根节点( `id = 1` )的指值。代码如下：
+
+  ```
+  private byte value(int id) {
+      return memoryMap[id];
+  }
+  ```
+
+  - 第 7 至 9 行：如果根节点的值，大于 `d` ，说明，第 `d` 层没有符合的节点，也就是说 `[1, d-1]` 层也没有符合的节点。即，当前 Chunk 没有符合的节点。
+
+- 第 10 至 25 行：获得第
+
+   
+
+  ```
+  d
+  ```
+
+   
+
+  层，匹配的节点。因为
+
+   
+
+  ```
+  val < d
+  ```
+
+   
+
+  难以保证是第
+
+   
+
+  ```
+  d
+  ```
+
+   
+
+  层，
+
+  ```
+  [0, d-1]
+  ```
+
+   
+
+  层也可以满足
+
+   
+
+  ```
+  val < d
+  ```
+
+   
+
+  ，所以才有
+
+   
+
+  ```
+  id & initial
+  ```
+
+   
+
+  来保证，高度小于
+
+   
+
+  ```
+  d
+  ```
+
+   
+
+  会继续循环。
+
+  - ← 第 15 行：`<< 1` 操作，进入下一层。获得**左节点**的编号。
+  - ← 第 17 行：获得左节点的值。
+  - → 第 19 行：如果值大于 `d` ，说明，以左节点作为根节点形成虚拟的虚拟满二叉树，没有符合的节点。此时，需要跳到**右节点**。
+  - → 第 21 行：`^ 1` 操作，获得**右节点**的编号。
+  - → 第 23 行：获得右节点的值。
+  - 【第 17 行】或者【第 23 行】的代码，会通过【第 12 行】的代码，结束循环。也就说，获得第 `d` 层，匹配的节点。
+
+- 第 33 行：调用 `#setValue(int id, byte val)` 方法，设置获得的节点的值为 `unusable` ，表示不可用。代码如下：
+
+  ```
+  private void setValue(int id, byte val) {
+      memoryMap[id] = val;
+  }
+  ```
+
+- 第 35 行：调用 `#updateParentsAlloc(int id)` 方法，更新获得的节点的祖先都不可用。详细解析，见 [「2.4.1 updateParentsAlloc」](https://svip.iocoder.cn/Netty/ByteBuf-3-2-Jemalloc-chunk/#) 。
+
+- 第 38 行：返回节点编号。
+
+## 2.3 free
+
+> 老艿艿：本小节，胖友先看完 [《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（三）PoolSubpage》](http://svip.iocoder.cn/Netty/ByteBuf-3-3-Jemalloc-subpage) 。
+
+`#free(long handle)` 方法，释放指定位置的内存块。根据情况，内存块可能是 SubPage ，也可能是 Page ，也可能是释放 SubPage 并且释放对应的 Page 。代码如下：
+
+```
+   /**
+    * Free a subpage or a run of pages
+    * When a subpage is freed from PoolSubpage, it might be added back to subpage pool of the owning PoolArena
+    * If the subpage pool in PoolArena has at least one other PoolSubpage of given elemSize, we can
+    * completely free the owning Page so it is available for subsequent allocations
+    *
+    * @param handle handle to free
+    */
+ 1: void free(long handle) {
+ 2:     // 获得 memoryMap 数组的编号( 下标 )
+ 3:     int memoryMapIdx = memoryMapIdx(handle);
+ 4:     // 获得 bitmap 数组的编号( 下标 )。注意，此时获得的还不是真正的 bitmapIdx 值，需要经过 `bitmapIdx & 0x3FFFFFFF` 运算。
+ 5:     int bitmapIdx = bitmapIdx(handle);
+ 6: 
+ 7:     // 释放 Subpage begin ~
+ 8: 
+ 9:     if (bitmapIdx != 0) { // free a subpage bitmapIdx 非空，说明释放的是 Subpage
+10:         // 获得 PoolSubpage 对象
+11:         PoolSubpage<T> subpage = subpages[subpageIdx(memoryMapIdx)];
+12:         assert subpage != null && subpage.doNotDestroy;
+13: 
+14:         // 获得对应内存规格的 Subpage 双向链表的 head 节点
+15:         // Obtain the head of the PoolSubPage pool that is owned by the PoolArena and synchronize on it.
+16:         // This is need as we may add it back and so alter the linked-list structure.
+17:         PoolSubpage<T> head = arena.findSubpagePoolHead(subpage.elemSize);
+18:         // 加锁，分配过程会修改双向链表的结构，会存在多线程的情况。
+19:         synchronized (head) {
+20:             // 释放 Subpage 。
+21:             if (subpage.free(head, bitmapIdx & 0x3FFFFFFF)) {
+22:                 return;
+23:             }
+24:             // ↑↑↑ 返回 false ，说明 Page 中无切分正在使用的 Subpage 内存块，所以可以继续向下执行，释放 Page
+25:         }
+26:     }
+27: 
+28:     // 释放 Page begin ~
+29: 
+30:     // 增加剩余可用字节数
+31:     freeBytes += runLength(memoryMapIdx);
+32:     // 设置 Page 对应的节点可用
+33:     setValue(memoryMapIdx, depth(memoryMapIdx));
+34:     // 更新 Page 对应的节点的祖先可用
+35:     updateParentsFree(memoryMapIdx);
+36: }
+```
+
+- 第 3 行：调用 `#memoryMapIdx(handle)` 方法，获得 `memoryMap` 数组的编号( 下标 )。代码如下：
+
+  ```
+  private static int memoryMapIdx(long handle) {
+      return (int) handle;
+  }
+  ```
+
+- 第 5 行：调用 `#bitmapIdx(handle)` 方法，获得 `bitmap` 数组的编号( 下标 )。代码如下：
+
+  ```
+  private static int bitmapIdx(long handle) {
+      return (int) (handle >>> Integer.SIZE);
+  }
+  ```
+
+  - 注意，此时获得的还不是真正的 bitmapIdx 值，需要经过 `bitmapIdx & 0x3FFFFFFF` 运算，即【第 21 行】的代码。
+
+- 第 9 至 26 行：释放 Subpage 内存块。
+
+  - 第 9 行：通过 `bitmapIdx !=0` 判断，说明释放的是 Subpage 内存块。
+
+  - 第 11 行：获得 PoolSubpage 对象。
+
+  - 第 17 行：调用 `PoolArena#findSubpagePoolHead(int normCapacity)` 方法，获得对应内存规格的 Subpage 双向链表的 `head` 节点。详细解析，见 [《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（五）PoolArena》](http://svip.iocoder.cn/Netty/ByteBuf-3-5-Jemalloc-Arena) 。
+
+  - 第 19 行：`synchronized` 加锁，分配过程会修改双向链表的结构，会存在多线程的情况。
+
+  - 第 21 行：调用
+
+     
+
+    ```
+    SubPage#free(PoolSubpage<T> head, int bitmapIdx)
+    ```
+
+     
+
+    方法，释放 Subpage 内存块。
+
+    - 如果返回 `false` ，说明 Page 中**无切分正在使用**的 Subpage 内存块，所以可以继续向下执行，释放 Page 内存块。
+
+- 第 30 至 35 行：释放 Page 内存块。
+
+  - 第 31 行：增加剩余可用字节数。
+  - 第 33 行：调用 `#setValue(int id, byte val)` 方法，设置 Page 对应的节点**可用**。
+  - 第 35 行：调用 `#updateParentsAlloc(int id)` 方法，更新获得的节点的祖先**可用**。
+
+## 2.4 updateParents
+
+### 2.4.1 updateParentsAlloc
+
+`#updateParentsAlloc(int id)` 方法，更新获得的节点的祖先都不可用。代码如下：
+
+```
+   /**
+    * Update method used by allocate
+    * This is triggered only when a successor is allocated and all its predecessors
+    * need to update their state
+    * The minimal depth at which subtree rooted at id has some free space
+    *
+    * @param id id
+    */
+ 1: private void updateParentsAlloc(int id) {
+ 2:     while (id > 1) {
+ 3:         // 获得父节点的编号
+ 4:         int parentId = id >>> 1;
+ 5:         // 获得子节点的值
+ 6:         byte val1 = value(id);
+ 7:         // 获得另外一个子节点的
+ 8:         byte val2 = value(id ^ 1);
+ 9:         // 获得子节点较小值，并设置到父节点
+10:         byte val = val1 < val2 ? val1 : val2;
+11:         setValue(parentId, val);
+12:         // 跳到父节点
+13:         id = parentId;
+14:     }
+15: }
+```
+
+- 😈 注意，调用此方法时，节点 `id` 已经更新为**不可用**。
+- 第 2 行：循环，直到**根**节点。
+- 第 4 行：`>>> 1` 操作，获得父节点的编号。
+- 第 5 至 11 行：获得子节点较小值，并调用 `#setValue(int id, int value)` 方法，设置到父节点。
+- 第 13 行：跳到父节点。
+
+### 2.4.2 updateParentsFree
+
+`#updateParentsAlloc(int id)` 方法，更新获得的节点的祖先可用。代码如下：
+
+```
+   /**
+    * Update method used by free
+    * This needs to handle the special case when both children are completely free
+    * in which case parent be directly allocated on request of size = child-size * 2
+    *
+    * @param id id
+    */
+ 1: private void updateParentsFree(int id) {
+ 2:     // 获得当前节点的子节点的层级
+ 3:     int logChild = depth(id) + 1;
+ 4:     while (id > 1) {
+ 5:         // 获得父节点的编号
+ 6:         int parentId = id >>> 1;
+ 7:         // 获得子节点的值
+ 8:         byte val1 = value(id);
+ 9:         // 获得另外一个子节点的值
+10:         byte val2 = value(id ^ 1);
+11:         // 获得当前节点的层级
+12:         logChild -= 1; // in first iteration equals log, subsequently reduce 1 from logChild as we traverse up
+13: 
+14:         // 两个子节点都可用，则直接设置父节点的层级
+15:         if (val1 == logChild && val2 == logChild) {
+16:             setValue(parentId, (byte) (logChild - 1));
+17:         // 两个子节点任一不可用，则取子节点较小值，并设置到父节点
+18:         } else {
+19:             byte val = val1 < val2 ? val1 : val2;
+20:             setValue(parentId, val);
+21:         }
+22: 
+23:         // 跳到父节点
+24:         id = parentId;
+25:     }
+26: }
+```
+
+- 😈 注意，调用此方法时，节点 `id` 已经更新为可用。
+- 第 3 行：获得当前节点的子节点的层级。
+- 第 4 行：循环，直到**根**节点。
+- 第 6 行：`>>> 1` 操作，获得**父**节点的编号。
+- 第 7 至 10 行：获得两个**子**节点的值。
+- 第 12 行：获得当前节点的层级。
+- 第 14 至 16 行：两个子节点都可用，则调用 `#setValue(id, value)` 方法，直接设置父节点的层级( 注意，是 `logChild - 1` )。
+- 第 17 至 21 行：两个子节点任一不可用，则`#setValue(id, value)` 方法，取子节点较小值，并设置到父节点。
+- 第 24 行：跳到父节点。
+
+## 2.5 initBuf
+
+`#initBuf(PooledByteBuf<T> buf, long handle, int reqCapacity)` 方法，初始化分配的内存块到 PooledByteBuf 中。代码如下：
+
+```
+ 1: void initBuf(PooledByteBuf<T> buf, long handle, int reqCapacity) {
+ 2:     // 获得 memoryMap 数组的编号( 下标 )
+ 3:     int memoryMapIdx = memoryMapIdx(handle);
+ 4:     // 获得 bitmap 数组的编号( 下标 )。注意，此时获得的还不是真正的 bitmapIdx 值，需要经过 `bitmapIdx & 0x3FFFFFFF` 运算。
+ 5:     int bitmapIdx = bitmapIdx(handle);
+ 6:     // 内存块为 Page
+ 7:     if (bitmapIdx == 0) {
+ 8:         byte val = value(memoryMapIdx);
+ 9:         assert val == unusable : String.valueOf(val);
+10:         // 初始化 Page 内存块到 PooledByteBuf 中
+11:         buf.init(this, handle, runOffset(memoryMapIdx) + offset, reqCapacity, runLength(memoryMapIdx), arena.parent.threadCache());
+12:     // 内存块为 SubPage
+13:     } else {
+14:         // 初始化 SubPage 内存块到 PooledByteBuf 中
+15:         initBufWithSubpage(buf, handle, bitmapIdx, reqCapacity);
+16:     }
+17: }
+```
+
+- 第 3 行：调用 `#memoryMapIdx(handle)` 方法，获得 `memoryMap` 数组的编号( 下标 )。
+
+- 第 5 行：调用 `#bitmapIdx(handle)` 方法，获得 `bitmap` 数组的编号( 下标 )。
+
+- 第 6 至 11 行：通过 `bitmapIdx == 0` 判断出，内存块是 Page 。所以，调用 `PooledByteBuf#init(PoolChunk<T> chunk, long handle, int offset, int length, int maxLength, PoolThreadCache cache)` 方法，初始化 Page 内存块到 PooledByteBuf 中。其中，`runOffset(memoryMapIdx) + offset` 代码块，计算 Page 内存块在 `memory` 中的开始位置。`runOffset(int id)` 方法，代码如下：
+
+  ```
+  private int runOffset(int id) {
+      // represents the 0-based offset in #bytes from start of the byte-array chunk
+      int shift = id ^ 1 << depth(id);
+      return shift * runLength(id);
+  }
+      
+  private int runLength(int id) {
+      // represents the size in #bytes supported by node 'id' in the tree
+      return 1 << log2ChunkSize - depth(id);
+  }
+  ```
+
+- 第12 至 16 行：通过 `bitmapIdx != 0` 判断出，内存块是 SubPage 。所以，调用 `#initBufWithSubpage(PooledByteBuf<T> buf, long handle, int reqCapacity)` 方法，初始化 SubPage 内存块到 PooledByteBuf 中。详细解析，见 [「2.5.1 initBufWithSubpage」](https://svip.iocoder.cn/Netty/ByteBuf-3-2-Jemalloc-chunk/#) 。
+
+### 2.5.1 initBufWithSubpage
+
+`#initBufWithSubpage(PooledByteBuf<T> buf, long handle, int reqCapacity)` 方法，初始化 SubPage 内存块到 PooledByteBuf 中。代码如下：
+
+```
+   void initBufWithSubpage(PooledByteBuf<T> buf, long handle, int reqCapacity) {
+       initBufWithSubpage(buf, handle, bitmapIdx(handle), reqCapacity);
+   }
+
+ 1: private void initBufWithSubpage(PooledByteBuf<T> buf, long handle, int bitmapIdx, int reqCapacity) {
+ 2:     assert bitmapIdx != 0;
+ 3: 
+ 4:     // 获得 memoryMap 数组的编号( 下标 )
+ 5:     int memoryMapIdx = memoryMapIdx(handle);
+ 6:     // 获得 SubPage 对象
+ 7:     PoolSubpage<T> subpage = subpages[subpageIdx(memoryMapIdx)];
+ 8:     assert subpage.doNotDestroy;
+ 9:     assert reqCapacity <= subpage.elemSize;
+10: 
+11:     // 初始化 SubPage 内存块到 PooledByteBuf 中
+12:     buf.init(
+13:         this, handle,
+14:         runOffset(memoryMapIdx) + (bitmapIdx & 0x3FFFFFFF) * subpage.elemSize + offset,
+15:             reqCapacity, subpage.elemSize, arena.parent.threadCache());
+16: }
+```
+
+- 第 3 至 7 行：获得 SubPage 对象。
+- 第 11 至于 15 行：调用 `PooledByteBuf#init(PoolChunk<T> chunk, long handle, int offset, int length, int maxLength, PoolThreadCache cache)` 方法，初始化 SubPage 内存块到 PooledByteBuf 中。其中，`runOffset(memoryMapIdx) + (bitmapIdx & 0x3FFFFFFF) * subpage.elemSize + offset` 代码块，计算 SubPage 内存块在 `memory` 中的开始位置。
+
+## 2.6 destroy
+
+`#destroy()` 方法，从 Arena 中销毁当前 Chunk 。代码如下：
+
+```
+void destroy() {
+    arena.destroyChunk(this);
+}
+```
+
+- 详细解析，见 [《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（五）PoolArena》](http://svip.iocoder.cn/Netty/ByteBuf-3-5-Jemalloc-Arena) 。
+
+## 2.7 PoolChunkMetric
+
+`io.netty.buffer.PoolChunkMetric` ，PoolChunk Metric 接口。代码如下：
+
+```
+public interface PoolChunkMetric {
+
+    /**
+     * Return the percentage of the current usage of the chunk.
+     */
+    int usage();
+
+    /**
+     * Return the size of the chunk in bytes, this is the maximum of bytes that can be served out of the chunk.
+     */
+    int chunkSize();
+
+    /**
+     * Return the number of free bytes in the chunk.
+     */
+    int freeBytes();
+
+}
+```
+
+------
+
+PoolChunk 对 PoolChunkMetric 接口的实现，代码如下：
+
+```
+@Override
+public int usage() {
+    final int freeBytes;
+    synchronized (arena) {
+        freeBytes = this.freeBytes;
+    }
+    return usage(freeBytes);
+}
+
+private int usage(int freeBytes) {
+    // 全部使用，100%
+    if (freeBytes == 0) {
+        return 100;
+    }
+
+    // 部分使用，最高 99%
+    int freePercentage = (int) (freeBytes * 100L / chunkSize);
+    if (freePercentage == 0) {
+        return 99;
+    }
+    return 100 - freePercentage;
+}
+
+@Override
+public int chunkSize() {
+    return chunkSize;
+}
+
+@Override
+public int freeBytes() {
+    synchronized (arena) {
+        return freeBytes;
+    }
+}
+```
+
+- `synchronized` 的原因是，保证 `freeBytes` 对其它线程的可见性。对应 Github 提交为 [a7fe6c01539d3ad92d7cd94a25daff9e10851088](https://github.com/netty/netty/commit/a7fe6c01539d3ad92d7cd94a25daff9e10851088) 。
+
+  > **Motivation**:
+  >
+  > As we may access the metrics exposed of PooledByteBufAllocator from another thread then the allocations happen we need to ensure we synchronize on the PoolArena to ensure correct visibility.
+  >
+  > **Modifications**:
+  >
+  > Synchronize on the PoolArena to ensure correct visibility.
+  >
+  > **Result**:
+  >
+  > Fix multi-thread issues on the metrics
+
+# 666. 彩蛋
+
+老艿艿有点二，在 `#allocateNode(int normCapacity)` 方法卡了很久。因为没看到 `memoryMap` 和 `depthMap` 数组，下标是从 1 开始的！！！我恨那。
+
+参考如下文章：
+
+- 占小狼 [《深入浅出Netty内存管理 PoolChunk》](https://www.jianshu.com/p/c4bd37a3555b)
+- Hypercube [《自顶向下深入分析Netty（十）–PoolChunk》](https://www.jianshu.com/p/70181af2972a)
\ No newline at end of file
diff --git a/netty/44-Netty 源码解析-Buffer 之 Jemalloc（三）PoolSubpage.assets/01.png b/netty/44-Netty 源码解析-Buffer 之 Jemalloc（三）PoolSubpage.assets/01.png
new file mode 100644
index 0000000..b700642
Binary files /dev/null and b/netty/44-Netty 源码解析-Buffer 之 Jemalloc（三）PoolSubpage.assets/01.png differ
diff --git a/netty/44-Netty 源码解析-Buffer 之 Jemalloc（三）PoolSubpage.assets/02.png b/netty/44-Netty 源码解析-Buffer 之 Jemalloc（三）PoolSubpage.assets/02.png
new file mode 100644
index 0000000..600d706
Binary files /dev/null and b/netty/44-Netty 源码解析-Buffer 之 Jemalloc（三）PoolSubpage.assets/02.png differ
diff --git a/netty/44-Netty 源码解析-Buffer 之 Jemalloc（三）PoolSubpage.assets/03.png b/netty/44-Netty 源码解析-Buffer 之 Jemalloc（三）PoolSubpage.assets/03.png
new file mode 100644
index 0000000..48fc47d
Binary files /dev/null and b/netty/44-Netty 源码解析-Buffer 之 Jemalloc（三）PoolSubpage.assets/03.png differ
diff --git a/netty/44-Netty 源码解析-Buffer 之 Jemalloc（三）PoolSubpage.md b/netty/44-Netty 源码解析-Buffer 之 Jemalloc（三）PoolSubpage.md
new file mode 100644
index 0000000..0233c4c
--- /dev/null
+++ b/netty/44-Netty 源码解析-Buffer 之 Jemalloc（三）PoolSubpage.md	
@@ -0,0 +1,798 @@
+# 精尽 Netty 源码解析 —— Buffer 之 Jemalloc（三）PoolSubpage
+
+# 1. 概述
+
+在 [《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（一）PoolChunk》](http://svip.iocoder.cn/Netty/ByteBuf-3-2-Jemalloc-chunk) 一文中，我们已经看到，为了进一步提供提高内存**分配效率**并减少**内存碎片**，Jemalloc 算法将每个 Chunk 切分成多个**小块** Page 。
+
+但是实际应用中，Page 也是**比较大**的内存块，如果直接使用，明显是很浪费的。因此，Jemalloc 算法将每个 Page 更进一步的切分为**多个** Subpage 内存块。Page 切分成**多个** Subpage 内存块，并未采用相对复杂的算法和数据结构，而是直接基于**数组**，通过数组来**标记**每个 Subpage 内存块是否已经分配。如下图所示：[![PoolSubpage](44-Netty 源码解析-Buffer 之 Jemalloc（三）PoolSubpage.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_09_07/01.png)PoolSubpage
+
+- 一个 Page ，切分出的**多个** Subpage 内存块**大小均等**。
+
+- 每个 Page 拆分的 Subpage 内存块
+
+  可以不同
+
+  ，以 Page 第一次拆分为 Subpage 内存块时请求分配的内存大小为准。例如：
+
+  - 初始时，申请一个 16B 的内存块，那么 Page0 被拆成成 512( `8KB / 16B` )个 Subpage 块，使用第 0 块。
+  - 然后，申请一个 32B 的内存块，那么 Page1 被拆分成 256( `8KB / 32B` )个 Subpage 块，使用第 0 块。
+  - 最后，申请一个 16B 的内存块，那么重用 Page0 ，使用第 1 块。
+  - 总结来说，申请 Subpage 内存块时，先去找**大小匹配**，且有可分配 Subpage 内存块的 Page ：1）如果有，则使用其中的一块 Subpage ；2）如果没有，则选择一个新的 Page 拆分成多个 Subpage 内存块，使用第 0 块 Subpage 。
+
+- Subpage 的内存规格，分成 Tiny 和 Small 两类，并且每类有多种大小，如下图所示：[![Subpage 内存规格](44-Netty 源码解析-Buffer 之 Jemalloc（三）PoolSubpage.assets/02.png)](http://static.iocoder.cn/images/Netty/2018_09_07/02.png)Subpage 内存规格
+
+- 为了方便描述，下文我们会继续将 `ele` 小块，描述成“Subpage 内存块”，简称“Subpage” 。
+
+# 2. PoolSubpage
+
+`io.netty.buffer.PoolSubpage` ，实现 PoolSubpageMetric 接口，Netty 对 Jemalloc Subpage 的实现类。
+
+虽然，PoolSubpage 类的命名是“Subpage”，实际描述的是，Page 切分为**多个** Subpage 内存块的分配情况。那么为什么不直接叫 PoolPage 呢？在 [《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（一）PoolChunk》](http://svip.iocoder.cn/Netty/ByteBuf-3-2-Jemalloc-chunk) 一文中，我们可以看到，当申请分配的内存规格为 Normal 和 Huge 时，使用的是一块或多块 Page 内存块。如果 PoolSubpage 命名成 PoolPage 后，和这块的分配策略是有所冲突的。或者说，**Subpage ，只是 Page 分配内存的一种形式**。
+
+## 2.1 构造方法
+
+```
+/**
+ * 所属 PoolChunk 对象
+ */
+final PoolChunk<T> chunk;
+/**
+ * 在 {@link PoolChunk#memoryMap} 的节点编号
+ */
+private final int memoryMapIdx;
+/**
+ * 在 Chunk 中，偏移字节量
+ *
+ * @see PoolChunk#runOffset(int) 
+ */
+private final int runOffset;
+/**
+ * Page 大小 {@link PoolChunk#pageSize}
+ */
+private final int pageSize;
+
+/**
+ * Subpage 分配信息数组
+ *
+ * 每个 long 的 bits 位代表一个 Subpage 是否分配。
+ * 因为 PoolSubpage 可能会超过 64 个( long 的 bits 位数 )，所以使用数组。
+ *   例如：Page 默认大小为 8KB ，Subpage 默认最小为 16 B ，所以一个 Page 最多可包含 8 * 1024 / 16 = 512 个 Subpage 。
+ *        因此，bitmap 数组大小为 512 / 64 = 8 。
+ * 另外，bitmap 的数组大小，使用 {@link #bitmapLength} 来标记。或者说，bitmap 数组，默认按照 Subpage 的大小为 16B 来初始化。
+ *    为什么是这样的设定呢？因为 PoolSubpage 可重用，通过 {@link #init(PoolSubpage, int)} 进行重新初始化。
+ */
+private final long[] bitmap;
+
+/**
+ * 双向链表，前一个 PoolSubpage 对象
+ */
+PoolSubpage<T> prev;
+/**
+ * 双向链表，后一个 PoolSubpage 对象
+ */
+PoolSubpage<T> next;
+
+/**
+ * 是否未销毁
+ */
+boolean doNotDestroy;
+/**
+ * 每个 Subpage 的占用内存大小
+ */
+int elemSize;
+/**
+ * 总共 Subpage 的数量
+ */
+private int maxNumElems;
+/**
+ * {@link #bitmap} 长度
+ */
+private int bitmapLength;
+/**
+ * 下一个可分配 Subpage 的数组位置
+ */
+private int nextAvail;
+/**
+ * 剩余可用 Subpage 的数量
+ */
+private int numAvail;
+
+  1: // 【构造方法 1】 双向链表，头节点
+  2: /** Special constructor that creates a linked list head */
+  3: PoolSubpage(int pageSize) {
+  4:     chunk = null;
+  5:     memoryMapIdx = -1;
+  6:     runOffset = -1;
+  7:     elemSize = -1;
+  8:     this.pageSize = pageSize;
+  9:     bitmap = null;
+ 10: }
+ 11: 
+ 12: // 【构造方法 2】 双向链表，Page 节点
+ 13: PoolSubpage(PoolSubpage<T> head, PoolChunk<T> chunk, int memoryMapIdx, int runOffset, int pageSize, int elemSize) {
+ 14:     this.chunk = chunk;
+ 15:     this.memoryMapIdx = memoryMapIdx;
+ 16:     this.runOffset = runOffset;
+ 17:     this.pageSize = pageSize;
+ 18:     // 创建 bitmap 数组
+ 19:     bitmap = new long[pageSize >>> 10]; // pageSize / 16 / 64
+ 20:     // 初始化
+ 21:     init(head, elemSize);
+ 22: }
+```
+
+- Chunk 相关
+
+  - `chunk` 属性，所属 PoolChunk 对象。
+  - `memoryMapIdx` 属性，在 `PoolChunk.memoryMap` 的节点编号，例如节点编号 2048 。
+  - `runOffset` 属性，在 Chunk 中，偏移字节量，通过 `PoolChunk#runOffset(id)` 方法计算。在 PoolSubpage 中，无相关的逻辑，仅用于 `#toString()` 方法，打印信息。
+  - `pageSize` 属性，Page 大小。
+
+- Subpage 相关
+
+  - ```
+    bitmap
+    ```
+
+     
+
+    属性，Subpage
+
+     
+
+    分配信息
+
+    数组。
+
+    - 1、每个 `long` 的 bits 位代表一个 Subpage 是否分配。因为 PoolSubpage 可能会超过 64 个( `long` 的 bits 位数 )，所以使用数组。例如：Page 默认大小为 `8KB` ，Subpage 默认最小为 `16B` ，所以一个 Page 最多可包含 `8 * 1024 / 16` = 512 个 Subpage 。
+
+    - 2、在【第 19 行】的代码，创建
+
+       
+
+      ```
+      bitmap
+      ```
+
+       
+
+      数组。我们可以看到，
+
+      ```
+      bitmap
+      ```
+
+       
+
+      数组的大小为 8(
+
+      ```
+      pageSize >>> 10 = pageSize / 16 / 64 = 512 / 64
+      ```
+
+      ) 个。
+
+      - 为什么是**固定大小**呢？因为 PoolSubpage **可重用**，通过 `#init(PoolSubpage, int)` 进行重新初始化。
+      - 那么数组大小怎么获得？通过 `bitmapLength` 属性来标记**真正**使用的数组大小。
+
+  - `bitmapLength` 属性，`bitmap` 数组的**真正**使用的数组大小。
+
+  - `elemSize` 属性，每个 Subpage 的占用内存大小，例如 `16B`、`32B` 等等。
+
+  - `maxNumElems` 属性，总共 Subpage 的数量。例如 `16B` 为 512 个，`32b` 为 256 个。
+
+  - `numAvail` 属性，剩余可用 Subpage 的数量。
+
+  - `nextAvail` 属性，下一个可分配 Subpage 的数组( `bitmap` )位置。可能会有胖友有疑问，`bitmap` 又是数组，又考虑 bits 位，怎么计算位置呢？在 [「2.6 getNextAvail」](https://svip.iocoder.cn/Netty/ByteBuf-3-3-Jemalloc-subpage/#) 见分晓。
+
+  - `doNotDestroy` 属性，是否未销毁。详细解析，见 [「2.5 free」](https://svip.iocoder.cn/Netty/ByteBuf-3-3-Jemalloc-subpage/#) 中。
+
+- Arena 相关
+
+  - `prev` 属性，双向链表，前一个 PoolSubpage 对象。
+  - `next` 属性，双向链表，后一个 PoolSubpage 对象。
+  - 详细解析，见 [「2.3 双向链表」](https://svip.iocoder.cn/Netty/ByteBuf-3-3-Jemalloc-subpage/#) 。
+
+- 构造方法 **1** ，用于创建双向链表的头( head )节点。
+
+- 构造方法
+
+   
+
+  2
+
+   
+
+  ，用于创建双向链表的 Page 节点。
+
+  - 第 21 行：调用 `#init(PoolSubpage<T> head, int elemSize)` 方法，初始化。详细解析，见 [「2.2 init」](https://svip.iocoder.cn/Netty/ByteBuf-3-3-Jemalloc-subpage/#) 。
+
+## 2.2 init
+
+`#init(PoolSubpage<T> head, int elemSize)` 方法，初始化。代码如下：
+
+```
+ 1: void init(PoolSubpage<T> head, int elemSize) {
+ 2:     // 未销毁
+ 3:     doNotDestroy = true;
+ 4:     // 初始化 elemSize
+ 5:     this.elemSize = elemSize;
+ 6:     if (elemSize != 0) {
+ 7:         // 初始化 maxNumElems
+ 8:         maxNumElems = numAvail = pageSize / elemSize;
+ 9:         // 初始化 nextAvail
+10:         nextAvail = 0;
+11:         // 计算 bitmapLength 的大小
+12:         bitmapLength = maxNumElems >>> 6;
+13:         if ((maxNumElems & 63) != 0) { // 未整除，补 1.
+14:             bitmapLength ++;
+15:         }
+16: 
+17:         // 初始化 bitmap
+18:         for (int i = 0; i < bitmapLength; i ++) {
+19:             bitmap[i] = 0;
+20:         }
+21:     }
+22:     // 添加到 Arena 的双向链表中。
+23:     addToPool(head);
+24: }
+```
+
+- 第 3 行：未销毁。
+
+- 第 5 行：初始化
+
+   
+
+  ```
+  elemSize
+  ```
+
+   
+
+  。
+
+  - 第 8 行：初始化 `maxNumElems` 。
+
+- 第 10 行：初始化 `nextAvail` 。
+
+- 第 11 至 15 行：初始化
+
+   
+
+  ```
+  bitmapLength
+  ```
+
+   
+
+  。
+
+  - 第 17 至 20 行：初始化 `bitmap` 。
+
+- 第 23 行：调用 `#addToPool(PoolSubpage<T> head)` 方法中，添加到 Arena 的双向链表中。详细解析，见 [「2.3.1 addToPool」](https://svip.iocoder.cn/Netty/ByteBuf-3-3-Jemalloc-subpage/#) 中。
+
+## 2.3 双向链表
+
+在每个 Arena 中，有 `tinySubpagePools` 和 `smallSubpagePools` 属性，分别表示 **tiny** 和 **small** 类型的 PoolSubpage 数组。代码如下：
+
+```
+// PoolArena.java
+
+/**
+ * tiny 类型的 PoolSubpage 数组
+ *
+ * 数组的每个元素，都是双向链表
+ */
+private final PoolSubpage<T>[] tinySubpagePools;
+/**
+ * small 类型的 SubpagePools 数组
+ *
+ * 数组的每个元素，都是双向链表
+ */
+private final PoolSubpage<T>[] smallSubpagePools;
+```
+
+- 数组的每个元素，通过 `prev` 和 `next` 属性，形成**双向**链表。并且，每个元素，表示对应的 Subpage 内存规格的**双向**链表，例如：`tinySubpagePools[0]` 表示 `16B` ，`tinySubpagePools[1]` 表示 `32B` 。
+
+- 通过 `tinySubpagePools` 和 `smallSubpagePools` 属性，可以从中查找，是否已经有符合分配内存规格的 Subpage 节点可分配。
+
+- 初始时，每个双向链表，会创建对应的 `head` 节点，代码如下：
+
+  ```
+  // PoolArena.java
+  
+  private PoolSubpage<T> newSubpagePoolHead(int pageSize) {
+      PoolSubpage<T> head = new PoolSubpage<T>(pageSize);
+      head.prev = head;
+      head.next = head;
+      return head;
+  }
+  ```
+
+  - 比较神奇的是，`head` 的上下节点都是**自己**。也就说，这是个双向环形( 循环 )链表。
+
+### 2.3.1 addToPool
+
+`#addToPool(PoolSubpage<T> head)` 方法中，添加到 Arena 的双向链表中。代码如下：
+
+```
+private void addToPool(PoolSubpage<T> head) {
+    assert prev == null && next == null;
+    // 将当前节点，插入到 head 和 head.next 中间
+    prev = head;
+    next = head.next;
+    next.prev = this;
+    head.next = this;
+}
+```
+
+- 将当前节点，插入到
+
+   
+
+  ```
+  head
+  ```
+
+   
+
+  和
+
+   
+
+  ```
+  head.next
+  ```
+
+   
+
+  中间。如下图所示：
+
+  ![插入过程](44-Netty 源码解析-Buffer 之 Jemalloc（三）PoolSubpage.assets/03.png)
+
+  插入过程
+
+  - 注意，是在 `head` 和 `head.next` **中间**插入节点噢。
+
+### 2.3.2 removeFromPool
+
+`#removeFromPool()` 方法中，从双向链表中移除。代码如下：
+
+```
+private void removeFromPool() {
+    assert prev != null && next != null;
+    // 前后节点，互相指向
+    prev.next = next;
+    next.prev = prev;
+    // 当前节点，置空
+    next = null;
+    prev = null;
+}
+```
+
+## 2.4 allocate
+
+`#allocate()` 方法，分配一个 Subpage 内存块，并返回该内存块的位置 `handle` 。代码如下：
+
+> 关于 `handle` 怎么翻译和解释好呢？笔者暂时没想好，官方的定义是 `"Returns the bitmap index of the subpage allocation."` 。
+
+```
+ 1: long allocate() {
+ 2:     // 防御性编程，不存在这种情况。
+ 3:     if (elemSize == 0) {
+ 4:         return toHandle(0);
+ 5:     }
+ 6: 
+ 7:     // 可用数量为 0 ，或者已销毁，返回 -1 ，即不可分配。
+ 8:     if (numAvail == 0 || !doNotDestroy) {
+ 9:         return -1;
+10:     }
+11: 
+12:     // 获得下一个可用的 Subpage 在 bitmap 中的总体位置
+13:     final int bitmapIdx = getNextAvail();
+14:     // 获得下一个可用的 Subpage 在 bitmap 中数组的位置
+15:     int q = bitmapIdx >>> 6;
+16:     // 获得下一个可用的 Subpage 在 bitmap 中数组的位置的第几 bits
+17:     int r = bitmapIdx & 63;
+18:     assert (bitmap[q] >>> r & 1) == 0;
+19:     // 修改 Subpage 在 bitmap 中不可分配。
+20:     bitmap[q] |= 1L << r;
+21: 
+22:     // 可用 Subpage 内存块的计数减一
+23:     if (-- numAvail == 0) { // 无可用 Subpage 内存块
+24:         // 从双向链表中移除
+25:         removeFromPool();
+26:     }
+27: 
+28:     // 计算 handle
+29:     return toHandle(bitmapIdx);
+30: }
+```
+
+- 第 2 至 5 行：防御性编程，不存在这种情况。
+
+- 第 7 至 10 行：可用数量为 0 ，或者已销毁，返回 -1 ，即**不可分配**。
+
+- 第 12 至 20 行：分配一个 Subpage 内存块。
+
+  - 第 13 行：调用 `#getNextAvail()` 方法，获得下一个可用的 Subpage 在 bitmap 中的**总体**位置。详细解析，见 [「2.6 getNextAvail」](https://svip.iocoder.cn/Netty/ByteBuf-3-3-Jemalloc-subpage/#) 。
+  - 第 15 行：`bitmapIdx >>> 6 = bitmapIdx / 64` 操作，获得下一个可用的 Subpage 在 bitmap 中**数组的位置**。
+  - 第 17 行：`bitmapIdx & 63 = bitmapIdx % 64` 操作， 获得下一个可用的 Subpage 在 bitmap 中数组的位置的**第几 bit** 。
+  - 第 20 行：`| (1L << r)` 操作，修改 Subpage 在 bitmap 中不可分配。
+
+- 第 23 行：可用 Subpage 内存块的计数减一。
+
+  - 第 25 行：当 `numAvail == 0` 时，表示无可用 Subpage 内存块。所以，调用 `#removeFromPool()` 方法，从双向链表中移除。详细解析，见 [「2.3.2 removeFromPool」](https://svip.iocoder.cn/Netty/ByteBuf-3-3-Jemalloc-subpage/#) 。
+
+- 第 29 行：调用 `#toHandle(bitmapIdx)` 方法，计算 `handle` 值。代码如下：
+
+  ```
+  private long toHandle(int bitmapIdx) {
+      return 0x4000000000000000L | (long) bitmapIdx << 32 | memoryMapIdx;
+  }
+  ```
+
+  - 低 32 bits ：`memoryMapIdx` ，可以判断所属 Chunk 的哪个 Page 节点，即 `memoryMap[memoryMapIdx]` 。
+
+  - 高 32 bits ：
+
+    ```
+    bitmapIdx
+    ```
+
+     
+
+    ，可以判断 Page 节点中的哪个 Subpage 的内存块，即
+
+     
+
+    ```
+    bitmap[bitmapIdx]
+    ```
+
+     
+
+    。
+
+    - 那么为什么会有
+
+       
+
+      ```
+      0x4000000000000000L
+      ```
+
+       
+
+      呢？因为在
+
+       
+
+      ```
+      PoolChunk#allocate(int normCapacity)
+      ```
+
+       
+
+      中：
+
+      - 如果分配的是 Page 内存块，返回的是 `memoryMapIdx` 。
+      - 如果分配的是 Subpage 内存块，返回的是 `handle` 。**但但但是**，如果说 `bitmapIdx = 0` ，那么没有 `0x4000000000000000L` 情况下，就会和【分配 Page 内存块】冲突。因此，需要有 `0x4000000000000000L` 。
+
+    - 因为有了 `0x4000000000000000L`(最高两位为 `01` ，其它位为 `0` )，所以获取 `bitmapIdx` 时，通过 `handle >>> 32 & 0x3FFFFFFF` 操作。使用 `0x3FFFFFFF`( 最高两位为 `00` ，其它位为 `1` ) 进行消除 `0x4000000000000000L` 带来的影响。
+
+## 2.5 free
+
+`#free(PoolSubpage<T> head, int bitmapIdx)` 方法，释放指定位置的 Subpage 内存块，并返回当前 Page **是否正在使用中**( `true` )。代码如下：
+
+```
+ 1: boolean free(PoolSubpage<T> head, int bitmapIdx) {
+ 2:     // 防御性编程，不存在这种情况。
+ 3:     if (elemSize == 0) {
+ 4:         return true;
+ 5:     }
+ 6:     // 获得 Subpage 在 bitmap 中数组的位置
+ 7:     int q = bitmapIdx >>> 6;
+ 8:     // 获得 Subpage 在 bitmap 中数组的位置的第几 bits
+ 9:     int r = bitmapIdx & 63;
+10:     assert (bitmap[q] >>> r & 1) != 0;
+11:     // 修改 Subpage 在 bitmap 中可分配。
+12:     bitmap[q] ^= 1L << r;
+13: 
+14:     // 设置下一个可用为当前 Subpage
+15:     setNextAvail(bitmapIdx);
+16: 
+17:     // 可用 Subpage 内存块的计数加一
+18:     if (numAvail ++ == 0) {
+19:         // 添加到 Arena 的双向链表中。
+20:         addToPool(head);
+21:         return true;
+22:     }
+23: 
+24:     // 还有 Subpage 在使用
+25:     if (numAvail != maxNumElems) {
+26:         return true;
+27:     // 没有 Subpage 在使用
+28:     } else {
+29:         // 双向链表中，只有该节点，不进行移除
+30:         // Subpage not in use (numAvail == maxNumElems)
+31:         if (prev == next) {
+32:             // Do not remove if this subpage is the only one left in the pool.
+33:             return true;
+34:         }
+35: 
+36:         // 标记为已销毁
+37:         // Remove this subpage from the pool if there are other subpages left in the pool.
+38:         doNotDestroy = false;
+39:         // 从双向链表中移除
+40:         removeFromPool();
+41:         return false;
+42:     }
+43: }
+```
+
+- 第 2 至 5 行：防御性编程，不存在这种情况。
+
+- 第 6 至 12 行：释放指定位置的 Subpage 内存块。
+
+  - 第 7 行：`bitmapIdx >>> 6 = bitmapIdx / 64` 操作，获得下一个可用的 Subpage 在 bitmap 中**数组的位置**。
+  - 第 9 行：`bitmapIdx & 63 = bitmapIdx % 64` 操作， 获得下一个可用的 Subpage 在 bitmap 中数组的位置的**第几 bit** 。
+  - 第 12 行：`^ (1L << r)` 操作，修改 Subpage 在 bitmap 中可分配。
+
+- 第 15 行：调用 `#setNextAvail(int bitmapIdx)` 方法，设置下一个可用为当前 Subpage 的位置。这样，就能避免下次分配 Subpage 时，再去找位置。代码如下：
+
+  ```
+  private void setNextAvail(int bitmapIdx) {
+      nextAvail = bitmapIdx;
+  }
+  ```
+
+- 第 18 行：可用 Subpage 内存块的计数加一。
+
+  - 第 20 行：当之前 `numAvail == 0` 时，表示**又有**可用 Subpage 内存块。所以，调用 `#addToPool(PoolSubpage<T> head)` 方法，添加到 Arena 的双向链表中。详细解析，见 [「2.3.1 addToPool」](https://svip.iocoder.cn/Netty/ByteBuf-3-3-Jemalloc-subpage/#) 。
+  - 第 21 行：返回 `true` ，正在使用中。
+
+- 第 24 至 26 行：返回 `true` ，因为还有其它在使用的 Subpage 内存块。
+
+- 第 27 至 42 行：没有 Subpage 在使用。
+
+  - 第 29 至 34 行：返回 `true` ，因为通过 `prev == next` 可判断，当前节点为双向链表中的唯一节点，不进行移除。也就说，该节点后续，继续使用。
+
+  - 第 36 至 41 行：返回
+
+     
+
+    ```
+    false
+    ```
+
+     
+
+    ，不在使用中。
+
+    - 第 38 行：标记为已销毁。
+    - 第 40 行：调用 `#removeFromPool()` 方法，从双向链表中移除。因为此时双向链表中，还有其它节点可使用，**没必要保持多个相同规格的节点**。
+
+------
+
+关于为什么 `#free(PoolSubpage<T> head, int bitmapIdx)` 方法，需要返回 `true` 或 `false` 呢？胖友再看看 `PoolChunk#free(long handle)` 方法，就能明白。答案是，如果不再使用，可以将该节点( Page )从 Chunk 中释放，标记为可用。😈😈😈
+
+## 2.6 getNextAvail
+
+`#getNextAvail()` 方法，获得下一个可用的 Subpage 在 bitmap 中的**总体**位置。代码如下：
+
+```
+private int getNextAvail() {
+    int nextAvail = this.nextAvail;
+    // <1> nextAvail 大于 0 ，意味着已经“缓存”好下一个可用的位置，直接返回即可。
+    if (nextAvail >= 0) {
+        this.nextAvail = -1;
+        return nextAvail;
+    }
+    // <2> 寻找下一个 nextAvail
+    return findNextAvail();
+}
+```
+
+- ```
+  <1>
+  ```
+
+   
+
+  处，如果
+
+   
+
+  ```
+  nextAvail
+  ```
+
+   
+
+  大于 0 ，意味着已经“缓存”好下一个可用的位置，直接返回即可。
+
+  - 获取好后，会将 `nextAvail` 置为 -1 。意味着，下次需要寻找下一个 `nextAvail` 。
+
+- `<2>` 处，调用 `#findNextAvail()` 方法，寻找下一个 `nextAvail` 。代码如下：
+
+  ```
+  private int findNextAvail() {
+      final long[] bitmap = this.bitmap;
+      final int bitmapLength = this.bitmapLength;
+      // 循环 bitmap
+      for (int i = 0; i < bitmapLength; i ++) {
+          long bits = bitmap[i];
+          // ~ 操作，如果不等于 0 ，说明有可用的 Subpage
+          if (~bits != 0) {
+              // 在这 bits 寻找可用 nextAvail
+              return findNextAvail0(i, bits);
+          }
+      }
+      // 未找到
+      return -1;
+  }
+  ```
+
+  - 代码比较简单，胖友直接看注释。
+
+  - 调用 `#findNextAvail0(int i, long bits)` 方法，在这 bits 寻找可用 `nextAvail` 。代码如下：
+
+    ```
+     1: private int findNextAvail0(int i, long bits) {
+     2:     final int maxNumElems = this.maxNumElems;
+     3:     // 计算基础值，表示在 bitmap 的数组下标
+     4:     final int baseVal = i << 6; // 相当于 * 64
+     5: 
+     6:     // 遍历 64 bits
+     7:     for (int j = 0; j < 64; j ++) {
+     8:         // 计算当前 bit 是否未分配
+     9:         if ((bits & 1) == 0) {
+    10:             // 可能 bitmap 最后一个元素，并没有 64 位，通过 baseVal | j < maxNumElems 来保证不超过上限。
+    11:             int val = baseVal | j;
+    12:             if (val < maxNumElems) {
+    13:                 return val;
+    14:             } else {
+    15:                 break;
+    16:             }
+    17:         }
+    18:         // 去掉当前 bit
+    19:         bits >>>= 1;
+    20:     }
+    21: 
+    22:     // 未找到
+    23:     return -1;
+    24: }
+    ```
+
+    - 第 4 行：计算基础值，表示在 `bitmap` 的数组**下标**。通过 `i << 6 = i * 64` 的计算，我们可以通过 `i >>> 6 = i / 64` 的方式，知道是 `bitmap` 数组的第几个元素。
+
+    - 第 7 行：循环 64 bits 。
+
+      - 第 9 行：
+
+        ```
+        (bits & 1) == 0
+        ```
+
+         
+
+        操作，计算当前 bit 是否
+
+        未分配
+
+        。
+
+        - 第 11 行：`baseVal | j` 操作，使用**低 64 bits** ，表示分配 `bitmap` 数组的元素的**第几 bit** 。
+
+        - 第 12 行：可能
+
+           
+
+          ```
+          bitmap
+          ```
+
+           
+
+          数组的最后一个元素，并没有 64 位，通过
+
+           
+
+          ```
+          baseVal | j < maxNumElems
+          ```
+
+           
+
+          来保证不超过上限。如果
+
+          - 第 13 行：未超过，返回 `val` 。
+          - 第 15 行：超过，结束循环，最终返回 `-1` 。
+
+      - 第 19 行：去掉当前 bit 。这样，下次循环就可以判断下一个 bit 是否**未分配**。
+
+    - 第 23 行：返回 `-1` ，表示未找到。
+
+## 2.6 destroy
+
+`#destroy()` 方法，销毁。代码如下：
+
+```
+void destroy() {
+    if (chunk != null) {
+        chunk.destroy();
+    }
+}
+```
+
+## 2.7 PoolSubpageMetric
+
+`io.netty.buffer.PoolSubpageMetric` ，PoolSubpage Metric 接口。代码如下：
+
+```
+public interface PoolSubpageMetric {
+
+    /**
+     * Return the number of maximal elements that can be allocated out of the sub-page.
+     */
+    int maxNumElements();
+
+    /**
+     * Return the number of available elements to be allocated.
+     */
+    int numAvailable();
+
+    /**
+     * Return the size (in bytes) of the elements that will be allocated.
+     */
+    int elementSize();
+
+    /**
+     * Return the size (in bytes) of this page.
+     */
+    int pageSize();
+}
+```
+
+------
+
+PoolChunk 对 PoolChunkMetric 接口的实现，代码如下：
+
+```
+@Override
+public int maxNumElements() {
+    synchronized (chunk.arena) {
+        return maxNumElems;
+    }
+}
+
+@Override
+public int numAvailable() {
+    synchronized (chunk.arena) {
+        return numAvail;
+    }
+}
+
+@Override
+public int elementSize() {
+    synchronized (chunk.arena) {
+        return elemSize;
+    }
+}
+
+@Override
+public int pageSize() {
+    return pageSize;
+}
+```
+
+# 666. 彩蛋
+
+PoolSubpage 相比 PoolChunk 来说，简单好多。嘿嘿。
+
+参考如下文章：
+
+- 占小狼 [《深入浅出Netty内存管理 PoolSubpage》](https://www.jianshu.com/p/d91060311437)
+- Hypercube [《自顶向下深入分析Netty（十）–PoolSubpage》](https://www.jianshu.com/p/7afd3a801b15)
\ No newline at end of file
diff --git a/netty/45-Netty 源码解析-Buffer 之 Jemalloc（四）PoolChunkList.assets/01.png b/netty/45-Netty 源码解析-Buffer 之 Jemalloc（四）PoolChunkList.assets/01.png
new file mode 100644
index 0000000..4ce5fa9
Binary files /dev/null and b/netty/45-Netty 源码解析-Buffer 之 Jemalloc（四）PoolChunkList.assets/01.png differ
diff --git a/netty/45-Netty 源码解析-Buffer 之 Jemalloc（四）PoolChunkList.assets/02.png b/netty/45-Netty 源码解析-Buffer 之 Jemalloc（四）PoolChunkList.assets/02.png
new file mode 100644
index 0000000..41fab20
Binary files /dev/null and b/netty/45-Netty 源码解析-Buffer 之 Jemalloc（四）PoolChunkList.assets/02.png differ
diff --git a/netty/45-Netty 源码解析-Buffer 之 Jemalloc（四）PoolChunkList.md b/netty/45-Netty 源码解析-Buffer 之 Jemalloc（四）PoolChunkList.md
new file mode 100644
index 0000000..c0f25ee
--- /dev/null
+++ b/netty/45-Netty 源码解析-Buffer 之 Jemalloc（四）PoolChunkList.md	
@@ -0,0 +1,573 @@
+# 精尽 Netty 源码解析 —— Buffer 之 Jemalloc（四）PoolChunkList
+
+# 1. 概述
+
+在 [《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（二）PoolChunk》](http://svip.iocoder.cn/Netty/ByteBuf-3-2-Jemalloc-chunk) ，我们看到 PoolChunk 有如下三个属性：
+
+```
+/**
+ * 所属 PoolChunkList 对象
+ */
+PoolChunkList<T> parent;
+/**
+ * 上一个 Chunk 对象
+ */
+PoolChunk<T> prev;
+/**
+ * 下一个 Chunk 对象
+ */
+PoolChunk<T> next;
+```
+
+- 通过 `prev` 和 `next` 两个属性，形成一个**双向** Chunk 链表 `parent`( PoolChunkList )。
+
+那么为什么需要有 PoolChunkList 这样一个链表呢？直接开始撸代码。
+
+# 2. PoolChunkList
+
+`io.netty.buffer.PoolChunkList` ，实现 PoolChunkListMetric 接口，负责管理多个 Chunk 的生命周期，**在此基础上对内存分配进行进一步的优化**。
+
+## 2.1 构造方法
+
+```
+/**
+ * 所属 PoolArena 对象
+ */
+private final PoolArena<T> arena;
+/**
+ * 下一个 PoolChunkList 对象
+ */
+private final PoolChunkList<T> nextList;
+/**
+ * Chunk 最小内存使用率
+ */
+private final int minUsage;
+/**
+ * Chunk 最大内存使用率
+ */
+private final int maxUsage;
+/**
+ * 每个 Chunk 最大可分配的容量
+ *
+ * @see #calculateMaxCapacity(int, int) 方法
+ */
+private final int maxCapacity;
+/**
+ * PoolChunk 头节点
+ */
+private PoolChunk<T> head;
+
+/**
+ * 前一个 PoolChunkList 对象
+ */
+// This is only update once when create the linked like list of PoolChunkList in PoolArena constructor.
+private PoolChunkList<T> prevList;
+
+// TODO: Test if adding padding helps under contention
+//private long pad0, pad1, pad2, pad3, pad4, pad5, pad6, pad7;
+
+PoolChunkList(PoolArena<T> arena, PoolChunkList<T> nextList, int minUsage, int maxUsage, int chunkSize) {
+    assert minUsage <= maxUsage;
+    this.arena = arena;
+    this.nextList = nextList;
+    this.minUsage = minUsage;
+    this.maxUsage = maxUsage;
+    // 计算 maxUsage 属性
+    maxCapacity = calculateMaxCapacity(minUsage, chunkSize);
+}
+```
+
+- `arena` 属性，所属 PoolArena 对象。
+
+- `prevList` + `nextList` 属性，上一个和下一个 PoolChunkList 对象。也就是说，PoolChunkList 除了**自身**有一条双向链表外，PoolChunkList 和 PoolChunkList **之间**也形成了一条双向链表。如下图所示：
+
+  > FROM [《深入浅出Netty内存管理 PoolChunkList》](https://www.jianshu.com/p/a1debfe4ff02)
+  >
+  > [![双向链表](45-Netty 源码解析-Buffer 之 Jemalloc（四）PoolChunkList.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_09_10/01.png)双向链表
+
+- `head` 属性，PoolChunkList **自身**的双向链表的**头节点**。
+
+- ```
+  minUsage
+  ```
+
+   
+
+  +
+
+   
+
+  ```
+  maxUsage
+  ```
+
+   
+
+  属性，PoolChunkList 管理的 Chunk 们的内存使用率。
+
+  - 当 Chunk 分配的内存率超过 `maxUsage` 时，从当前 PoolChunkList 节点移除，添加到下一个 PoolChunkList 节点( `nextList` )。TODO 详细解析。
+  - 当 Chunk 分配的内存率小于 `minUsage` 时，从当前 PoolChunkList 节点移除，添加到上一个 PoolChunkList 节点( `prevList` )。TODO 详细解析。
+
+- `maxCapacity` 属性，每个 Chunk 最大可分配的容量。通过 `#calculateMaxCapacity(int minUsage, int chunkSize)` 方法，来计算。代码如下：
+
+  ```
+  /**
+   * Calculates the maximum capacity of a buffer that will ever be possible to allocate out of the {@link PoolChunk}s
+   * that belong to the {@link PoolChunkList} with the given {@code minUsage} and {@code maxUsage} settings.
+   */
+  private static int calculateMaxCapacity(int minUsage, int chunkSize) {
+      // 计算 minUsage 值
+      minUsage = minUsage0(minUsage);
+  
+      if (minUsage == 100) {
+          // If the minUsage is 100 we can not allocate anything out of this list.
+          return 0;
+      }
+  
+      // Calculate the maximum amount of bytes that can be allocated from a PoolChunk in this PoolChunkList.
+      //
+      // As an example:
+      // - If a PoolChunkList has minUsage == 25 we are allowed to allocate at most 75% of the chunkSize because
+      //   this is the maximum amount available in any PoolChunk in this PoolChunkList.
+      return  (int) (chunkSize * (100L - minUsage) / 100L);
+  }
+  
+  // 保证最小 >= 1
+  private static int minUsage0(int value) {
+      return max(1, value);
+  }
+  ```
+
+  - 为什么使用 `(int) (chunkSize * (100L - minUsage) / 100L)` 来计算呢？因为 Chunk 进入当前 PoolChunkList 节点，意味着 Chunk 内存已经分配了 `minUsage` 比率，所以 Chunk 剩余的容量是 `chunkSize * (100L - minUsage) / 100L` 。😈 是不是豁然开朗噢？！
+
+## 2.2 allocate
+
+> 随着 Chunk 中 Page 的不断分配和释放，会导致很多碎片内存段，大大增加了之后分配一段连续内存的失败率。针对这种情况，可以把内存使用率较大的 Chunk 放到PoolChunkList 链表更后面。
+
+`#allocate(PooledByteBuf<T> buf, int reqCapacity, int normCapacity)` 方法，给 PooledByteBuf 对象分配内存块，并返回是否分配内存块成功。代码如下：
+
+```
+ 1: boolean allocate(PooledByteBuf<T> buf, int reqCapacity, int normCapacity) {
+ 2:     // 双向链表中无 Chunk
+ 3:     // 申请分配的内存超过 ChunkList 的每个 Chunk 最大可分配的容量
+ 4:     if (head == null || normCapacity > maxCapacity) {
+ 5:         // Either this PoolChunkList is empty or the requested capacity is larger then the capacity which can
+ 6:         // be handled by the PoolChunks that are contained in this PoolChunkList.
+ 7:         return false;
+ 8:     }
+ 9: 
+10:     // 遍历双向链表。注意，遍历的是 ChunkList 的内部双向链表。
+11:     for (PoolChunk<T> cur = head;;) {
+12:         // 分配内存块
+13:         long handle = cur.allocate(normCapacity);
+14:         // 分配失败
+15:         if (handle < 0) {
+16:             // 进入下一节点
+17:             cur = cur.next;
+18:             // 若下一个节点不存在，返回 false ，结束循环
+19:             if (cur == null) {
+20:                 return false; // 分配失败
+21:             }
+22:         // 分配成功
+23:         } else {
+24:             // 初始化内存块到 PooledByteBuf 对象中
+25:             cur.initBuf(buf, handle, reqCapacity);
+26:             // 超过当前 ChunkList 管理的 Chunk 的内存使用率上限
+27:             if (cur.usage() >= maxUsage) {
+28:                 // 从当前 ChunkList 节点移除
+29:                 remove(cur);
+30:                 // 添加到下一个 ChunkList 节点
+31:                 nextList.add(cur); 
+32:             }
+33:             return true; // 分配成功
+34:         }
+35:     }
+36: }
+```
+
+- 第 2 至 8 行：双向链表中无 Chunk，或者申请分配的内存超过 ChunkList 的每个 Chunk 最大可分配的容量，返回 `false` ，分配失败。
+
+- 第 11 行：遍历双向链表。**注意，遍历的是 ChunkList 的内部双向链表**。
+
+- 第 13 行：调用 `PoolChunk#allocate(normCapacity)` 方法，分配内存块。这块，可以结合 [《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（二）PoolChunk》「2.2 allocate」](http://svip.iocoder.cn/Netty/ByteBuf-3-2-Jemalloc-chunk) 在复习下。
+
+- 第 15 至 17 行：分配失败，进入下一个节点。
+
+  - 第 18 至 21 行：若下一个节点不存在，返回 `false` ，分配失败。
+
+- 第 22 至 25 行：分配成功，调用
+
+   
+
+  ```
+  PooledByteBuf##initBuf(PooledByteBuf<T> buf, long handle, int reqCapacity)
+  ```
+
+   
+
+  方法，初始化分配的内存块到 PooledByteBuf 中。这块，可以结合
+
+   
+
+  《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（二）PoolChunk》「2.5 initBuf」
+
+   
+
+  在复习下。
+
+  - 第 26 至 32 行：超过当前 ChunkList 管理的 Chunk 的内存使用率上限，从当前 ChunkList 节点移除，并添加到“
+
+    下
+
+    ”一个 ChunkList 节点。
+
+    - 第 29 行：调用 `#remove(PoolChunk<T> cur)` 方法，解析见 [「2.4.2 remove」](https://svip.iocoder.cn/Netty/ByteBuf-3-4-Jemalloc-chunkList/#) 。
+    - 第 31 行：调用 `#remove(PoolChunk<T> cur)` 方法，解析见 [「2.4.1 add」](https://svip.iocoder.cn/Netty/ByteBuf-3-4-Jemalloc-chunkList/#) 。
+
+  - 第 33 行：返回 `true` ，分配成功。
+
+## 2.3 free
+
+`#free(PoolChunk<T> chunk, long handle)` 方法，释放 PoolChunk 的指定位置( `handle` )的内存块。代码如下：
+
+```
+ 1: boolean free(PoolChunk<T> chunk, long handle) {
+ 2:     // 释放 PoolChunk 的指定位置( handle )的内存块
+ 3:     chunk.free(handle);
+ 4:     // 小于当前 ChunkList 管理的 Chunk 的内存使用率下限
+ 5:     if (chunk.usage() < minUsage) {
+ 6:         // 从当前 ChunkList 节点移除
+ 7:         remove(chunk);
+ 8:         // 添加到上一个 ChunkList 节点
+ 9:         // Move the PoolChunk down the PoolChunkList linked-list.
+10:         return move0(chunk);
+11:     }
+12:     // 释放成功
+13:     return true;
+14: }
+```
+
+- 第 3 行：调用 `PoolChunk#free(long handle)` 方法，释放指定位置的内存块。这块，可以结合 [《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（二）PoolChunk》「2.3 free」](http://svip.iocoder.cn/Netty/ByteBuf-3-2-Jemalloc-chunk) 在复习下。
+- 第 5 行：小于当前 ChunkList 管理的 Chunk 的内存使用率下限：
+  - 第 7 行：调用 `#remove(PoolChunk<T> cur)` 方法，从当前 ChunkList 节点移除。
+  - 第 10 行：调用 `#move(PoolChunk<T> chunk)` 方法， 添加到“上”一个 ChunkList 节点。详细解析，见 [「2.4.3 move」](https://svip.iocoder.cn/Netty/ByteBuf-3-4-Jemalloc-chunkList/#) 。
+- 第 13 行：返回 `true` ，释放成功。
+
+## 2.4 双向链表操作
+
+### 2.4.1 add
+
+`#add(PoolChunk<T> chunk)` 方法，将 PoolChunk 添加到 ChunkList 节点中。代码如下：
+
+```
+1: void add(PoolChunk<T> chunk) {
+2:     // 超过当前 ChunkList 管理的 Chunk 的内存使用率上限，继续递归到下一个 ChunkList 节点进行添加。
+3:     if (chunk.usage() >= maxUsage) {
+4:         nextList.add(chunk);
+5:         return;
+6:     }
+7:     // 执行真正的添加
+8:     add0(chunk);
+9: }
+```
+
+- 第 2 至 6 行：超过当前 ChunkList 管理的 Chunk 的内存使用率上限，调用 `nextList` 的 `#add(PoolChunk<T> chunk)` 方法，继续递归到下一个 ChunkList 节点进行添加。
+
+- 第 8 行：调用 `#add0(PoolChunk<T> chunk)` 方法，执行真正的添加。代码如下：
+
+  ```
+  /**
+   * Adds the {@link PoolChunk} to this {@link PoolChunkList}.
+   */
+  void add0(PoolChunk<T> chunk) {
+      chunk.parent = this;
+      // <1> 无头节点，自己成为头节点
+      if (head == null) {
+          head = chunk;
+          chunk.prev = null;
+          chunk.next = null;
+      // <2> 有头节点，自己成为头节点，原头节点成为自己的下一个节点
+      } else {
+          chunk.prev = null;
+          chunk.next = head;
+          head.prev = chunk;
+          head = chunk;
+      }
+  }
+  ```
+
+  - `<1>` 处，比较好理解，胖友自己看。
+  - `<2>` 处，因为 `chunk` **新**进入下一个 ChunkList 节点，一般来说，内存使用率相对较低，分配内存块成功率相对较高，所以变成新的首节点。
+
+### 2.4.2 remove
+
+`#remove(PoolChunk<T> chunk)` 方法，从当前 ChunkList 节点移除。代码如下：
+
+```
+private void remove(PoolChunk<T> cur) {
+    // 当前节点为首节点，将下一个节点设置为头节点
+    if (cur == head) {
+        head = cur.next;
+        if (head != null) {
+            head.prev = null;
+        }
+    // 当前节点非首节点，将节点的上一个节点指向节点的下一个节点
+    } else {
+        PoolChunk<T> next = cur.next;
+        cur.prev.next = next;
+        if (next != null) {
+            next.prev = cur.prev;
+        }
+    }
+}
+```
+
+- 代码比较简单，胖友自己研究。
+
+### 2.4.3 move
+
+`#move(PoolChunk<T> chunk)` 方法， 添加到“上”一个 ChunkList 节点。代码如下：
+
+```
+   /**
+    * Moves the {@link PoolChunk} down the {@link PoolChunkList} linked-list so it will end up in the right
+    * {@link PoolChunkList} that has the correct minUsage / maxUsage in respect to {@link PoolChunk#usage()}.
+    */
+ 1: private boolean move(PoolChunk<T> chunk) {
+ 2:     assert chunk.usage() < maxUsage;
+ 3: 
+ 4:     // 小于当前 ChunkList 管理的 Chunk 的内存使用率下限，继续递归到上一个 ChunkList 节点进行添加。
+ 5:     if (chunk.usage() < minUsage) {
+ 6:         // Move the PoolChunk down the PoolChunkList linked-list.
+ 7:         return move0(chunk);
+ 8:     }
+ 9: 
+10:     // 执行真正的添加
+11:     // PoolChunk fits into this PoolChunkList, adding it here.
+12:     add0(chunk);
+13:     return true;
+14: }
+```
+
+- 第 4 至 8 行：小于当前 ChunkList 管理的 Chunk 的内存使用率下限，调用 `#move0(PoolChunk<T> chunk)` 方法，继续递归到上一个 ChunkList 节点进行添加。代码如下：
+
+  ```
+  private boolean move(PoolChunk<T> chunk) {
+      assert chunk.usage() < maxUsage;
+  
+      // 小于当前 ChunkList 管理的 Chunk 的内存使用率下限，继续递归到上一个 ChunkList 节点进行添加。
+      if (chunk.usage() < minUsage) {
+          // Move the PoolChunk down the PoolChunkList linked-list.
+          return move0(chunk);
+      }
+  
+      // 执行真正的添加
+      // PoolChunk fits into this PoolChunkList, adding it here.
+      add0(chunk);
+      return true;
+  }
+  ```
+
+- 第 12 行：调用 `#add0(PoolChunk<T> chunk)` 方法，执行真正的添加。
+- 第 13 行：返回 `true` ，移动成功。
+
+## 2.5 iterator
+
+`#iterator()` 方法，创建 Iterator 对象。代码如下：
+
+```
+private static final Iterator<PoolChunkMetric> EMPTY_METRICS = Collections.<PoolChunkMetric>emptyList().iterator();
+
+@Override
+public Iterator<PoolChunkMetric> iterator() {
+    synchronized (arena) {
+        // 空，返回 EMPTY_METRICS
+        if (head == null) {
+            return EMPTY_METRICS;
+        }
+        // 生成数组，后生成 Iterator
+        List<PoolChunkMetric> metrics = new ArrayList<PoolChunkMetric>();
+        for (PoolChunk<T> cur = head;;) {
+            metrics.add(cur);
+            cur = cur.next;
+            if (cur == null) {
+                break;
+            }
+        }
+        return metrics.iterator();
+    }
+}
+```
+
+## 2.6 destroy
+
+`#destroy()` 方法，销毁。代码如下：
+
+```
+void destroy(PoolArena<T> arena) {
+    // 循环，销毁 ChunkList 管理的所有 Chunk
+    PoolChunk<T> chunk = head;
+    while (chunk != null) {
+        arena.destroyChunk(chunk);
+        chunk = chunk.next;
+    }
+    // 置空
+    head = null;
+}
+```
+
+## 2.7 PoolChunkListMetric
+
+`io.netty.buffer.PoolChunkListMetric` ，继承 Iterable 接口，PoolChunkList Metric 接口。代码如下：
+
+```
+public interface PoolChunkListMetric extends Iterable<PoolChunkMetric> {
+
+    /**
+     * Return the minimum usage of the chunk list before which chunks are promoted to the previous list.
+     */
+    int minUsage();
+
+    /**
+     * Return the maximum usage of the chunk list after which chunks are promoted to the next list.
+     */
+    int maxUsage();
+}
+```
+
+------
+
+PoolChunkList 对 PoolChunkMetric 接口的实现，代码如下：
+
+```
+@Override
+public int minUsage() {
+    return minUsage0(minUsage);
+}
+
+@Override
+public int maxUsage() {
+    return min(maxUsage, 100);
+}
+```
+
+# 3. PoolChunkList 初始化
+
+在 PoolChunkArena 中，初始化 PoolChunkList 代码如下：
+
+```
+// PoolChunkList 之间的双向链表
+
+private final PoolChunkList<T> q050;
+private final PoolChunkList<T> q025;
+private final PoolChunkList<T> q000;
+private final PoolChunkList<T> qInit;
+private final PoolChunkList<T> q075;
+private final PoolChunkList<T> q100;
+
+/**
+ * PoolChunkListMetric 数组
+ */
+private final List<PoolChunkListMetric> chunkListMetrics;
+
+  1: protected PoolArena(PooledByteBufAllocator parent, int pageSize,
+  2:       int maxOrder, int pageShifts, int chunkSize, int cacheAlignment) {
+  3:       
+  4:     // ... 省略其它无关代码
+  5:       
+  6:     // PoolChunkList 之间的双向链表，初始化
+  7: 
+  8:     q100 = new PoolChunkList<T>(this, null, 100, Integer.MAX_VALUE, chunkSize);
+  9:     q075 = new PoolChunkList<T>(this, q100, 75, 100, chunkSize);
+ 10:     q050 = new PoolChunkList<T>(this, q075, 50, 100, chunkSize);
+ 11:     q025 = new PoolChunkList<T>(this, q050, 25, 75, chunkSize);
+ 12:     q000 = new PoolChunkList<T>(this, q025, 1, 50, chunkSize);
+ 13:     qInit = new PoolChunkList<T>(this, q000, Integer.MIN_VALUE, 25, chunkSize);
+ 14:     
+ 15:     q100.prevList(q075);
+ 16:     q075.prevList(q050);
+ 17:     q050.prevList(q025);
+ 18:     q025.prevList(q000);
+ 19:     q000.prevList(null); // 无前置节点
+ 20:     qInit.prevList(qInit); // 前置节点为自己
+ 21:     
+ 22:     // 创建 PoolChunkListMetric 数组
+ 23:     List<PoolChunkListMetric> metrics = new ArrayList<PoolChunkListMetric>(6);
+ 24:     metrics.add(qInit);
+ 25:     metrics.add(q000);
+ 26:     metrics.add(q025);
+ 27:     metrics.add(q050);
+ 28:     metrics.add(q075);
+ 29:     metrics.add(q100);
+ 30:     chunkListMetrics = Collections.unmodifiableList(metrics);
+ 31: }
+```
+
+- PoolChunkList 之间的双向链表有 `qInit`、`q000`、`q025`、`q050`、`q075`、`q100` 有 6 个节点，在【第 6 至 20 行】的代码，进行**初始化**。链表如下：
+
+  ```
+  // 正向
+  qInit -> q000 -> q025 -> q050 -> q075 -> q100 -> null
+  
+  // 逆向
+  null <- q000 <- q025 <- q050 <- q075 <- q100
+  qInit <- qInit
+  ```
+
+  - 比较神奇的是，
+
+    ```
+    qInit
+    ```
+
+     
+
+    指向自己？！
+
+    ```
+    qInit
+    ```
+
+     
+
+    用途是，新创建的 Chunk 内存块
+
+     
+
+    ```
+    chunk_new
+    ```
+
+    ( 这只是个代号，方便描述 ) ，添加到
+
+     
+
+    ```
+    qInit
+    ```
+
+     
+
+    后，不会被释放掉。
+
+    - 为什么不会被释放掉？`qInit.minUsage = Integer.MIN_VALUE` ，所以在 `PoolChunkList#move(PoolChunk chunk)` 方法中，`chunk_new` 的内存使用率最小值为 0 ，所以肯定不会被释放。
+    - 那岂不是 `chunk_new` 无法被释放？随着 `chunk_new` 逐渐分配内存，内存使用率到达 25 ( `qInit.maxUsage` )后，会移动到 `q000` 。再随着 `chunk_new` 逐渐释放内存，内存使用率降到 0 (`q000.minUsage`) 后，就可以被释放。
+
+  - 当然，如果新创建的 Chunk 内存块 `chunk_new` **第一次**分配的内存使用率超过 25 ( `qInit.maxUsage` )，不会进入 `qInit` 中，而是进入后面的 PoolChunkList 节点。
+
+- `chunkListMetrics` 属性，PoolChunkListMetric 数组。在【第 22 至 30 行】的代码，进行**初始化**。
+
+# 666. 彩蛋
+
+PoolChunList 相比 PoolSubpage 来说，又又又更加简单啦。
+
+老艿艿整理了下 Arena、ChunkList、Chunk、Page、Subpage 的“操纵”关系如下图：
+
+[![PoolSubpage](45-Netty 源码解析-Buffer 之 Jemalloc（四）PoolChunkList.assets/02.png)](http://static.iocoder.cn/images/Netty/2018_09_10/02.png)PoolSubpage
+
+- 当然，这不是一幅严谨的图，仅仅表达“操纵”的关系。
+
+参考如下文章：
+
+- Hypercube [《自顶向下深入分析Netty（十）–PoolChunkList》](https://www.jianshu.com/p/2b8375df2d1a)
+- 占小狼 [《深入浅出Netty内存管理 PoolChunkList》](https://www.jianshu.com/p/4856bd30dd56)
\ No newline at end of file
diff --git a/netty/46-Netty 源码解析-Buffer 之 Jemalloc（五）PoolArena.assets/01.png b/netty/46-Netty 源码解析-Buffer 之 Jemalloc（五）PoolArena.assets/01.png
new file mode 100644
index 0000000..35f3cf5
Binary files /dev/null and b/netty/46-Netty 源码解析-Buffer 之 Jemalloc（五）PoolArena.assets/01.png differ
diff --git a/netty/46-Netty 源码解析-Buffer 之 Jemalloc（五）PoolArena.assets/02.png b/netty/46-Netty 源码解析-Buffer 之 Jemalloc（五）PoolArena.assets/02.png
new file mode 100644
index 0000000..64340f1
Binary files /dev/null and b/netty/46-Netty 源码解析-Buffer 之 Jemalloc（五）PoolArena.assets/02.png differ
diff --git a/netty/46-Netty 源码解析-Buffer 之 Jemalloc（五）PoolArena.assets/03.png b/netty/46-Netty 源码解析-Buffer 之 Jemalloc（五）PoolArena.assets/03.png
new file mode 100644
index 0000000..4b13736
Binary files /dev/null and b/netty/46-Netty 源码解析-Buffer 之 Jemalloc（五）PoolArena.assets/03.png differ
diff --git a/netty/46-Netty 源码解析-Buffer 之 Jemalloc（五）PoolArena.assets/04.png b/netty/46-Netty 源码解析-Buffer 之 Jemalloc（五）PoolArena.assets/04.png
new file mode 100644
index 0000000..aa53113
Binary files /dev/null and b/netty/46-Netty 源码解析-Buffer 之 Jemalloc（五）PoolArena.assets/04.png differ
diff --git a/netty/46-Netty 源码解析-Buffer 之 Jemalloc（五）PoolArena.md b/netty/46-Netty 源码解析-Buffer 之 Jemalloc（五）PoolArena.md
new file mode 100644
index 0000000..24fd25c
--- /dev/null
+++ b/netty/46-Netty 源码解析-Buffer 之 Jemalloc（五）PoolArena.md	
@@ -0,0 +1,1469 @@
+# 精尽 Netty 源码解析 —— Buffer 之 Jemalloc（五）PoolArena
+
+# 1. 概述
+
+在应用程序里，我们可以使用 PooledByteBufAllocator 来创建 ByteBuf 对象。代码如下：
+
+```
+PooledByteBufAllocator.DEFAULT.buffer(1024);
+```
+
+- 在方法的内部实现，通过 PoolArena 来进行内存分配。
+
+下面，就让我们来看看 PoolArena 具体的代码实现。
+
+> FROM [《自顶向下深入分析Netty（十）–JEMalloc分配算法》](https://www.jianshu.com/p/15304cd63175)
+>
+> 为了提高内存分配效率并减少内部碎片，Jemalloc 算法将 Arena 切分为小块 Chunk，根据每块的内存使用率又将小块组合为以下几种状态：QINIT、Q00、Q25、Q50、Q75、Q100 。Chunk 块可以在这几种状态间随着内存使用率的变化进行转移，从而提高分配效率。
+
+# 2. PoolArena
+
+`io.netty.buffer.PoolArena` ，实现 PoolArenaMetric 接口，Netty 对 Jemalloc Arena 的抽象实现类。
+
+PoolArena 有两个子类实现：
+
+- HeapArena ，对 Heap 类型的内存分配。
+- DirectArena ，对 Direct 类型的内存分配。
+
+## 2.1 构造方法
+
+```
+/**
+ * 是否支持 Unsafe 操作
+ */
+static final boolean HAS_UNSAFE = PlatformDependent.hasUnsafe();
+
+/**
+ * 内存分类
+ */
+enum SizeClass {
+    Tiny,
+    Small,
+    Normal
+
+    // 还有一个隐藏的，Huge
+}
+
+/**
+ * {@link #tinySubpagePools} 数组的大小
+ *
+ * 默认为 32
+ */
+static final int numTinySubpagePools = 512 >>> 4;
+
+/**
+ * 所属 PooledByteBufAllocator 对象
+ */
+final PooledByteBufAllocator parent;
+
+/**
+ * 满二叉树的高度。默认为 11 。
+ */
+private final int maxOrder;
+/**
+ * Page 大小，默认 8KB = 8192B
+ */
+final int pageSize;
+/**
+ * 从 1 开始左移到 {@link #pageSize} 的位数。默认 13 ，1 << 13 = 8192 。
+ */
+final int pageShifts;
+/**
+ * Chunk 内存块占用大小。默认为 16M = 16 * 1024  。
+ */
+final int chunkSize;
+/**
+ * 判断分配请求内存是否为 Tiny/Small ，即分配 Subpage 内存块。
+ *
+ * Used to determine if the requested capacity is equal to or greater than pageSize.
+ */
+final int subpageOverflowMask;
+
+/**
+ * {@link #smallSubpagePools} 数组的大小
+ *
+ * 默认为 23
+ */
+final int numSmallSubpagePools;
+
+/**
+ * 对齐基准
+ */
+final int directMemoryCacheAlignment;
+/**
+ * {@link #directMemoryCacheAlignment} 掩码
+ */
+final int directMemoryCacheAlignmentMask;
+
+/**
+ * tiny 类型的 PoolSubpage 数组
+ *
+ * 数组的每个元素，都是双向链表
+ */
+private final PoolSubpage<T>[] tinySubpagePools;
+/**
+ * small 类型的 SubpagePools 数组
+ *
+ * 数组的每个元素，都是双向链表
+ */
+private final PoolSubpage<T>[] smallSubpagePools;
+
+// PoolChunkList 之间的双向链表
+
+private final PoolChunkList<T> q050;
+private final PoolChunkList<T> q025;
+private final PoolChunkList<T> q000;
+private final PoolChunkList<T> qInit;
+private final PoolChunkList<T> q075;
+private final PoolChunkList<T> q100;
+
+/**
+ * PoolChunkListMetric 数组
+ */
+private final List<PoolChunkListMetric> chunkListMetrics;
+
+// Metrics for allocations and deallocations
+/**
+ * 分配 Normal 内存块的次数
+ */
+private long allocationsNormal;
+// We need to use the LongCounter here as this is not guarded via synchronized block.
+/**
+ * 分配 Tiny 内存块的次数
+ */
+private final LongCounter allocationsTiny = PlatformDependent.newLongCounter();
+/**
+ * 分配 Small 内存块的次数
+ */
+private final LongCounter allocationsSmall = PlatformDependent.newLongCounter();
+/**
+ * 分配 Huge 内存块的次数
+ */
+private final LongCounter allocationsHuge = PlatformDependent.newLongCounter();
+/**
+ * 正在使用中的 Huge 内存块的总共占用字节数
+ */
+private final LongCounter activeBytesHuge = PlatformDependent.newLongCounter();
+
+/**
+ * 释放 Tiny 内存块的次数
+ */
+private long deallocationsTiny;
+/**
+ * 释放 Small 内存块的次数
+ */
+private long deallocationsSmall;
+/**
+ * 释放 Normal 内存块的次数
+ */
+private long deallocationsNormal;
+
+/**
+ * 释放 Huge 内存块的次数
+ */
+// We need to use the LongCounter here as this is not guarded via synchronized block.
+private final LongCounter deallocationsHuge = PlatformDependent.newLongCounter();
+
+/**
+ * 该 PoolArena 被多少线程引用的计数器
+ */
+// Number of thread caches backed by this arena.
+final AtomicInteger numThreadCaches = new AtomicInteger();
+
+  1: protected PoolArena(PooledByteBufAllocator parent, int pageSize,
+  2:       int maxOrder, int pageShifts, int chunkSize, int cacheAlignment) {
+  3:     this.parent = parent;
+  4:     this.pageSize = pageSize;
+  5:     this.maxOrder = maxOrder;
+  6:     this.pageShifts = pageShifts;
+  7:     this.chunkSize = chunkSize;
+  8:     directMemoryCacheAlignment = cacheAlignment;
+  9:     directMemoryCacheAlignmentMask = cacheAlignment - 1;
+ 10:     subpageOverflowMask = ~(pageSize - 1);
+ 11: 
+ 12:     // 初始化 tinySubpagePools 数组
+ 13:     tinySubpagePools = newSubpagePoolArray(numTinySubpagePools);
+ 14:     for (int i = 0; i < tinySubpagePools.length; i ++) {
+ 15:         tinySubpagePools[i] = newSubpagePoolHead(pageSize);
+ 16:     }
+ 17: 
+ 18:     // 初始化 smallSubpagePools 数组
+ 19:     numSmallSubpagePools = pageShifts - 9;
+ 20:     smallSubpagePools = newSubpagePoolArray(numSmallSubpagePools);
+ 21:     for (int i = 0; i < smallSubpagePools.length; i ++) {
+ 22:         smallSubpagePools[i] = newSubpagePoolHead(pageSize);
+ 23:     }
+ 24: 
+ 25:     // PoolChunkList 之间的双向链表，初始化
+ 26: 
+ 27:     q100 = new PoolChunkList<T>(this, null, 100, Integer.MAX_VALUE, chunkSize);
+ 28:     q075 = new PoolChunkList<T>(this, q100, 75, 100, chunkSize);
+ 29:     q050 = new PoolChunkList<T>(this, q075, 50, 100, chunkSize);
+ 30:     q025 = new PoolChunkList<T>(this, q050, 25, 75, chunkSize);
+ 31:     q000 = new PoolChunkList<T>(this, q025, 1, 50, chunkSize);
+ 32:     qInit = new PoolChunkList<T>(this, q000, Integer.MIN_VALUE, 25, chunkSize);
+ 33: 
+ 34:     q100.prevList(q075);
+ 35:     q075.prevList(q050);
+ 36:     q050.prevList(q025);
+ 37:     q025.prevList(q000);
+ 38:     q000.prevList(null); // 无前置节点
+ 39:     qInit.prevList(qInit); // 前置节点为自己
+ 40: 
+ 41:     // 创建 PoolChunkListMetric 数组
+ 42:     List<PoolChunkListMetric> metrics = new ArrayList<PoolChunkListMetric>(6);
+ 43:     metrics.add(qInit);
+ 44:     metrics.add(q000);
+ 45:     metrics.add(q025);
+ 46:     metrics.add(q050);
+ 47:     metrics.add(q075);
+ 48:     metrics.add(q100);
+ 49:     chunkListMetrics = Collections.unmodifiableList(metrics);
+ 50: }
+```
+
+- 虽然属性比较多，但是内部主要还是以 PoolSubpage 和 PoolChunkList 对象为主。如下图所示：
+
+  > FROM [《深入浅出Netty内存管理 PoolArena》](https://www.jianshu.com/p/4856bd30dd56)
+  >
+  > [![大体结构](46-Netty 源码解析-Buffer 之 Jemalloc（五）PoolArena.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_09_13/01.png)大体结构
+
+- SizeClass **枚举类**，内存分类，一共有四种：Tiny、Small、Normal、Huge 。如下图所示：[![内存分配](46-Netty 源码解析-Buffer 之 Jemalloc（五）PoolArena.assets/02.png)](http://static.iocoder.cn/images/Netty/2018_09_13/02.png)内存分配
+
+- `parent` 属性，所属 PooledByteBufAllocator 对象。
+
+- 内存属性相关
+
+  - `HAS_UNSAFE` **静态**属性，是否支持 Unsafe 操作。
+  - `directMemoryCacheAlignment` 属性，对齐基准，默认为 0 。😈 实际可以忽略哈。
+  - `directMemoryCacheAlignmentMask` 属性，`directMemoryCacheAlignment` 的掩码，默认为 -1( 【第 9 行】的代码 `directMemoryCacheAlignment - 1` )。😈 实际可以忽略哈。
+
+- PoolChunk 属性相关，`maxOrder`、`pageSize`、`pageShifts`、`chunkSize`、`subpageOverflowMask` 。已经在 [《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（二）PoolChunk》](http://svip.iocoder.cn/Netty/ByteBuf-3-2-Jemalloc-chunk) 。
+
+- PoolSubpage 属性相关
+
+  - ```
+    tinySubpagePools
+    ```
+
+     
+
+    属性，tiny 类型的 PoolSubpage 数组。数组的每个元素，都是
+
+    双向链表
+
+    。
+
+    - 在【第 12 至 16 行】的代码，进行初始化。
+    - `numTinySubpagePools` **静态**属性，数组大小。默认为 32 。
+
+  - ```
+    smallSubpagePools
+    ```
+
+     
+
+    属性，small 类型的 SubpagePools 数组。数组的每个元素，都是
+
+    双向链表
+
+    。
+
+    - 在【第 18 至 23 行】的代码，进行初始化。
+    - `numSmallSubpagePools` 属性，数组大小。默认为 23( `numTinySubpagePools - 9` )。
+
+- PoolChunkList 属性相关，`qInit`、`q025`、`q050`、`q075`、`q100`、`chunkListMetrics` 。已经在 [《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（四）PoolChunkList》](http://svip.iocoder.cn/Netty/Netty/ByteBuf-3-4-Jemalloc-chunkList) 。
+
+- PoolArenaMetric 属性相关
+
+  - 分配 *XXX* 内存块的次数的属性：`allocationsNormal`、`allocationsTiny`、`allocationsSmall`、`allocationsHuge` 。
+  - 释放 *XXX* 内存块的次数的属性：`deallocationsTiny`、`deallocationsSmall`、`deallocationsNormal`、`deallocationsHuge` 。
+  - ↑↑↑ 上述属性使用 LongCounter 还是 `long` 类型，主要是变量访问时，是否在 `synchronized {}` 代码块中访问，从而保证**内存的可见性**。
+  - `activeBytesHuge` 属性，**正在使用中**的 Huge 内存块的总共占用字节数。
+  - `numThreadCaches` 属性，该 PoolArena 被多少线程引用的计数器。
+
+- 😈 构造方法，简单看看就好，基本上面都已经提到了。
+
+## 2.2 容量相关方法
+
+### 2.2.1 normalizeCapacity
+
+`#normalizeCapacity(int reqCapacity)` 方法，标准化请求分配的内存大小。通过这样的方式，**保证分配的内存块统一**。代码如下：
+
+```
+ 1: int normalizeCapacity(int reqCapacity) {
+ 2:     if (reqCapacity < 0) {
+ 3:         throw new IllegalArgumentException("capacity: " + reqCapacity + " (expected: 0+)");
+ 4:     }
+ 5: 
+ 6:     // Huge 内存类型，直接使用 reqCapacity ，无需进行标准化。
+ 7:     if (reqCapacity >= chunkSize) {
+ 8:         return directMemoryCacheAlignment == 0 ? reqCapacity : alignCapacity(reqCapacity);
+ 9:     }
+10: 
+11:     // 非 tiny 内存类型
+12:     if (!isTiny(reqCapacity)) { // >= 512
+13:         // Doubled
+14:         // 转换成接近于两倍的容量
+15:         int normalizedCapacity = reqCapacity;
+16:         normalizedCapacity --;
+17:         normalizedCapacity |= normalizedCapacity >>>  1;
+18:         normalizedCapacity |= normalizedCapacity >>>  2;
+19:         normalizedCapacity |= normalizedCapacity >>>  4;
+20:         normalizedCapacity |= normalizedCapacity >>>  8;
+21:         normalizedCapacity |= normalizedCapacity >>> 16;
+22:         normalizedCapacity ++;
+23:         if (normalizedCapacity < 0) {
+24:             normalizedCapacity >>>= 1;
+25:         }
+26:         assert directMemoryCacheAlignment == 0 || (normalizedCapacity & directMemoryCacheAlignmentMask) == 0;
+27: 
+28:         return normalizedCapacity;
+29:     }
+30: 
+31:     if (directMemoryCacheAlignment > 0) {
+32:         return alignCapacity(reqCapacity);
+33:     }
+34: 
+35:     // 补齐成 16 的倍数
+36:     // Quantum-spaced
+37:     if ((reqCapacity & 15) == 0) {
+38:         return reqCapacity;
+39:     }
+40:     return (reqCapacity & ~15) + 16;
+41: }
+```
+
+- 第 6 至 9 行：**Huge** 内存类型，直接使用 reqCapacity ，无需进行标准化。
+- 第 11 至 29 行：**Small**、**Normal** 内存类型，转换成接近于**两倍**的容量。
+- 第 35 至 40 行：**Tiny** 内存类型，补齐成 **16** 的倍数。
+
+总结来说，还是下图：[![内存容量](46-Netty 源码解析-Buffer 之 Jemalloc（五）PoolArena.assets/03.png)](http://static.iocoder.cn/images/Netty/2018_09_13/03.png)内存容量
+
+### 2.2.2 alignCapacity
+
+`#alignCapacity(int reqCapacity)` 方法，对齐请求分配的内存大小。代码如下：
+
+```
+int alignCapacity(int reqCapacity) {
+    // 获得 delta
+    int delta = reqCapacity & directMemoryCacheAlignmentMask;
+    // 补齐 directMemoryCacheAlignment ，并减去 delta
+    return delta == 0 ? reqCapacity : reqCapacity + directMemoryCacheAlignment - delta;
+}
+```
+
+### 2.2.3 isTinyOrSmall
+
+`#isTinyOrSmall(int normCapacity)` 方法，判断请求分配的内存类型是否为 tiny 或 small 类型。代码如下：
+
+```
+// capacity < pageSize
+boolean isTinyOrSmall(int normCapacity) {
+    return (normCapacity & subpageOverflowMask) == 0;
+}
+```
+
+### 2.2.4 isTiny
+
+`#isTiny(int normCapacity)` 方法，判断请求分配的内存类型是否为 tiny 类型。代码如下：
+
+```
+// normCapacity < 512
+static boolean isTiny(int normCapacity) {
+    return (normCapacity & 0xFFFFFE00) == 0;
+}
+```
+
+### 2.2.5 tinyIdx
+
+`#tinyIdx(int normCapacity)` **静态**方法，计算请求分配的内存大小在 `tinySubpagePools` 数组的下标。代码如下：
+
+```
+static int tinyIdx(int normCapacity) {
+    return normCapacity >>> 4;
+}
+```
+
+### 2.2.6 smallIdx
+
+`#smallIdx(int normCapacity)` **静态**方法，计算请求分配的内存大小在 `smallSubpagePools` 数组的下标。代码如下：
+
+```
+static int smallIdx(int normCapacity) {
+    int tableIdx = 0;
+    int i = normCapacity >>> 10;
+    while (i != 0) {
+        i >>>= 1;
+        tableIdx ++;
+    }
+    return tableIdx;
+}
+```
+
+### 2.2.7 sizeClass
+
+`#sizeClass(int normCapacity)` 方法，计算请求分配的内存的内存类型。代码如下：
+
+```
+private SizeClass sizeClass(int normCapacity) {
+    if (!isTinyOrSmall(normCapacity)) {
+        return SizeClass.Normal;
+    }
+    return isTiny(normCapacity) ? SizeClass.Tiny : SizeClass.Small;
+}
+```
+
+## 2.3 findSubpagePoolHead
+
+`#findSubpagePoolHead(int elemSize)` 方法，获得请求分配的 Subpage 类型的内存的链表的**头节点**。代码如下：
+
+```
+PoolSubpage<T> findSubpagePoolHead(int elemSize) {
+    int tableIdx;
+    PoolSubpage<T>[] table;
+    if (isTiny(elemSize)) { // < 512
+        // 实际上，就是 `#tinyIdx(int normCapacity)` 方法
+        tableIdx = elemSize >>> 4;
+        // 获得 table
+        table = tinySubpagePools;
+    } else {
+        // 实际上，就是 `#smallIdx(int normCapacity)` 方法
+        tableIdx = 0;
+        elemSize >>>= 10;
+        while (elemSize != 0) {
+            elemSize >>>= 1;
+            tableIdx ++;
+        }
+        // 获得 table
+        table = smallSubpagePools;
+    }
+
+    // 获得 Subpage 链表的头节点
+    return table[tableIdx];
+}
+```
+
+## 2.4 allocate
+
+PoolArena 根据申请分配的内存大小不同，提供了**两种**方式分配内存：
+
+- 1、PoolSubpage ，用于分配
+
+  小于
+
+   
+
+  ```
+  8KB
+  ```
+
+   
+
+  的内存块
+
+  - 1.1 `tinySubpagePools` 属性，用于分配小于 `512B` 的 tiny **Subpage** 内存块。
+  - 1.2 `smallSubpagePools` 属性，用于分配小于 `8KB` 的 small **Subpage** 内存块。
+
+- 2、PoolChunkList ，用于分配
+
+  大于等于
+
+   
+
+  ```
+  8KB
+  ```
+
+   
+
+  的内存块
+
+  - 2.1 小于 `32MB` ，分配 normal 内存块，即一个 Chunk 中的 **Page** 内存块。
+  - 2.2 大于等于 `32MB` ，分配 huge 内存块，即一整个 **Chunk** 内存块。
+
+------
+
+`#allocate(PoolThreadCache cache, int reqCapacity, int maxCapacity)` 方法，创建 PooledByteBuf 对象，并分配内存块给 PooledByteBuf 对象。代码如下：
+
+```
+ 1: private void allocate(PoolThreadCache cache, PooledByteBuf<T> buf, final int reqCapacity) {
+ 2:     // 标准化请求分配的容量
+ 3:     final int normCapacity = normalizeCapacity(reqCapacity);
+ 4:     // PoolSubpage 的情况
+ 5:     if (isTinyOrSmall(normCapacity)) { // capacity < pageSize
+ 6:         int tableIdx;
+ 7:         PoolSubpage<T>[] table;
+ 8:         // 判断是否为 tiny 类型的内存块申请
+ 9:         boolean tiny = isTiny(normCapacity);
+10:         if (tiny) { // < 512 tiny 类型的内存块申请
+11:             // 从 PoolThreadCache 缓存中，分配 tiny 内存块，并初始化到 PooledByteBuf 中。
+12:             if (cache.allocateTiny(this, buf, reqCapacity, normCapacity)) {
+13:                 // was able to allocate out of the cache so move on
+14:                 return;
+15:             }
+16:             // 获得 tableIdx 和 table 属性
+17:             tableIdx = tinyIdx(normCapacity);
+18:             table = tinySubpagePools;
+19:         } else {
+20:             // 从 PoolThreadCache 缓存中，分配 small 内存块，并初始化到 PooledByteBuf 中。
+21:             if (cache.allocateSmall(this, buf, reqCapacity, normCapacity)) {
+22:                 // was able to allocate out of the cache so move on
+23:                 return;
+24:             }
+25:             // 获得 tableIdx 和 table 属性
+26:             tableIdx = smallIdx(normCapacity);
+27:             table = smallSubpagePools;
+28:         }
+29: 
+30:         // 获得 PoolSubpage 链表的头节点
+31:         final PoolSubpage<T> head = table[tableIdx];
+32: 
+33:         // 从 PoolSubpage 链表中，分配 Subpage 内存块
+34:         /**
+35:          * Synchronize on the head. This is needed as {@link PoolChunk#allocateSubpage(int)} and
+36:          * {@link PoolChunk#free(long)} may modify the doubly linked list as well.
+37:          */
+38:         synchronized (head) { // 同步 head ，避免并发问题
+39:             final PoolSubpage<T> s = head.next;
+40:             if (s != head) {
+41:                 assert s.doNotDestroy && s.elemSize == normCapacity;
+42:                 // 分配 Subpage 内存块
+43:                 long handle = s.allocate();
+44:                 assert handle >= 0;
+45:                 // 初始化 Subpage 内存块到 PooledByteBuf 对象中
+46:                 s.chunk.initBufWithSubpage(buf, handle, reqCapacity);
+47:                 // 增加 allocationsTiny 或 allocationsSmall 计数
+48:                 incTinySmallAllocation(tiny);
+49:                 // 返回，因为已经分配成功
+50:                 return;
+51:             }
+52:         }
+53:         // 申请 Normal Page 内存块。实际上，只占用其中一块 Subpage 内存块。
+54:         synchronized (this) { // 同步 arena ，避免并发问题
+55:             allocateNormal(buf, reqCapacity, normCapacity);
+56:         }
+57:         // 增加 allocationsTiny 或 allocationsSmall 计数
+58:         incTinySmallAllocation(tiny);
+59:         // 返回，因为已经分配成功
+60:         return;
+61:     }
+62:     if (normCapacity <= chunkSize) {
+63:         // 从 PoolThreadCache 缓存中，分配 normal 内存块，并初始化到 PooledByteBuf 中。
+64:         if (cache.allocateNormal(this, buf, reqCapacity, normCapacity)) {
+65:             // was able to allocate out of the cache so move on
+66:             return;
+67:         }
+68:         // 申请 Normal Page 内存块
+69:         synchronized (this) { // 同步 arena ，避免并发问题
+70:             allocateNormal(buf, reqCapacity, normCapacity);
+71:             // 增加 allocationsNormal
+72:             ++allocationsNormal;
+73:         }
+74:     } else {
+75:         // 申请 Huge Page 内存块
+76:         // Huge allocations are never served via the cache so just call allocateHuge
+77:         allocateHuge(buf, reqCapacity);
+78:     }
+79: }
+```
+
+- 第 3 行：调用 `#normalizeCapacity(int reqCapacity)` 方法，标准化请求分配的内存大小。
+
+- 第 5 至 61 行：上述“1、PoolSubpage ，用于分配小于 8KB 的内存块”。
+
+  - 第 5 行：调用
+
+     
+
+    ```
+    #isTinyOrSmall(int normCapacity)
+    ```
+
+     
+
+    方法，判断请求分配的内存类型是否为 tiny 或 small 类型。
+
+    - 第 9 行：调用 `#isTiny(int normCapacity)` 方法，判断请求分配的内存类型是否为 tiny 类型。
+
+  - 第 10 至 31 行：获得 PoolSubpage 链表的头节点。从实现上，和
+
+     
+
+    「2.3 findSubpagePoolHead」
+
+     
+
+    功能上是一致的。
+
+    - 第 11 至 15 行：调用 `PoolThreadCache#allocateTiny(this, buf, reqCapacity, normCapacity)` 方法，从 PoolThreadCache 缓存中，分配 tiny 内存块，并初始化到 PooledByteBuf 中。详细解析，见 [《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（六）PoolThreadCache》](http://svip.iocoder.cn/Netty/ByteBuf-3-6-Jemalloc-ThreadCache) 中。
+    - 第 20 至 24 行：调用 `PoolThreadCache#allocateSmall(this, buf, reqCapacity, normCapacity)` 方法，从 PoolThreadCache 缓存中，分配 small 内存块，并初始化到 PooledByteBuf 中。详细解析，见 [《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（六）PoolThreadCache》](http://svip.iocoder.cn/Netty/ByteBuf-3-6-Jemalloc-ThreadCache) 中。
+
+  - 第 33 至 52 行：从 PoolSubpage 链表中，分配 Subpage 内存块。
+
+    - 第 43 行：调用 `head.next` 节点的 `PoolSubpage#allocate()` 方法，分配一个 Subpage 内存块，并返回该内存块的位置 `handle` 。如果遗忘这个过程的胖友，可以看看 [《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（三）PoolSubpage》](http://svip.iocoder.cn/Netty/ByteBuf-3-3-Jemalloc-subpage) 的 [「2.4 allocate」](https://svip.iocoder.cn/Netty/ByteBuf-3-5-Jemalloc-Arena/#) 。
+    - 第 46 行：调用 `PoolChunk#initBufWithSubpage(buf, handle, reqCapacity)` 方法，初始化 Subpage 内存块到 PooledByteBuf 对象中。如果遗忘这个过程的胖友，可以看看 [《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（二）PoolChunk》](http://svip.iocoder.cn/Netty/ByteBuf-3-2-Jemalloc-chunk) 的 [「2.5.1 initBufWithSubpage」](https://svip.iocoder.cn/Netty/ByteBuf-3-5-Jemalloc-Arena/#) 。
+    - 第 48 行：调用 `#incTinySmallAllocation(boolean tiny)` 方法，增加 `allocationsTiny` 或 `allocationsSmall` 计数。详细解析，见 [「2.8.1 incTinySmallAllocation」](https://svip.iocoder.cn/Netty/ByteBuf-3-5-Jemalloc-Arena/#) 。
+    - 第 50 行：`return` 返回，因为已经分配成功。
+
+  - 第 53 至 60 行：在 PoolSubpage 链表中，分配不到 Subpage 内存块，所以申请 Normal Page 内存块。实际上，只占用其中一块 Subpage 内存块。
+
+    - 第 53 至 56 行：调用 `#allocateNormal(PooledByteBuf<T> buf, int reqCapacity, int normCapacity)` 方法，申请 Normal Page 内存块。详细解析，见 [「2.4.1 allocateNormal」](https://svip.iocoder.cn/Netty/ByteBuf-3-5-Jemalloc-Arena/#) 。
+
+- 第 62 至 73 行：上述“2.1 小于 `32MB` ，分配 normal 内存块，即一个 Chunk 中的 **Page** 内存块”。
+
+  - 第 62 行：通过 `normCapacity <= chunkSize` 判断，判断请求分配的内存类型是否为 normal 类型。
+  - 第 63 至 67 行：调用 `PoolThreadCache#allocateNormal(this, buf, reqCapacity, normCapacity)` 方法，从 PoolThreadCache 缓存中，分配 normal 内存块，并初始化到 PooledByteBuf 中。详细解析，见 [《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（六）PoolThreadCache》](http://svip.iocoder.cn/Netty/ByteBuf-3-6-Jemalloc-ThreadCache) 中。
+  - 第 68 至 70 行：同【第 53 至 56 行】的代码。
+  - 第 72 行：增加 `allocationsNormal` 。
+
+- 第 74 至 78 行：上述“2.2 大于等于
+
+   
+
+  ```
+  32MB
+  ```
+
+   
+
+  ，分配 huge 内存块，即一整个
+
+   
+
+  Chunk
+
+   
+
+  内存块。”
+
+  - 第 77 行：调用 `#allocateHuge(PooledByteBuf<T> buf, int reqCapacity)` 方法，申请 Huge 内存块。
+
+### 2.4.1 allocateNormal
+
+`#allocateNormal(PooledByteBuf<T> buf, int reqCapacity, int normCapacity)` 方法，申请 Normal Page 内存块。代码如下：
+
+```
+   // Method must be called inside synchronized(this) { ... } block // 必须在 synchronized(this) { ... } 中执行
+ 1: private void allocateNormal(PooledByteBuf<T> buf, int reqCapacity, int normCapacity) {
+ 2:     // 按照优先级，从多个 ChunkList 中，分配 Normal Page 内存块。如果有一分配成功，返回
+ 3:     if (q050.allocate(buf, reqCapacity, normCapacity) || q025.allocate(buf, reqCapacity, normCapacity) ||
+ 4:         q000.allocate(buf, reqCapacity, normCapacity) || qInit.allocate(buf, reqCapacity, normCapacity) ||
+ 5:         q075.allocate(buf, reqCapacity, normCapacity)) {
+ 6:         return;
+ 7:     }
+ 8: 
+ 9:     // Add a new chunk.
+10:     // 新建 Chunk 内存块
+11:     PoolChunk<T> c = newChunk(pageSize, maxOrder, pageShifts, chunkSize);
+12:     // 申请对应的 Normal Page 内存块。实际上，如果申请分配的内存类型为 tiny 或 small 类型，实际申请的是 Subpage 内存块。
+13:     long handle = c.allocate(normCapacity);
+14:     assert handle > 0;
+15:     // 初始化 Normal Page / Subpage 内存块到 PooledByteBuf 对象中
+16:     c.initBuf(buf, handle, reqCapacity);
+17:     // 添加到 ChunkList 双向链中。
+18:     qInit.add(c);
+19: }
+```
+
+- 按照优先级，从多个 ChunkList 中，调用 `PoolChunkList#allocate(normCapacity)` 方法，分配 Normal Page 内存块。如果有一分配成功，`return` 返回。如果遗忘这个过程的胖友，可以看看 [《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（四）PoolChunkList》](http://svip.iocoder.cn/Netty/ByteBuf-3-4-Jemalloc-chunkList) 的 [「2.2 allocate」](https://svip.iocoder.cn/Netty/ByteBuf-3-5-Jemalloc-Arena/#) 。
+
+  > FROM [《深入浅出Netty内存管理 PoolArena》](https://www.jianshu.com/p/4856bd30dd56)
+  >
+  > 分配内存时，为什么不从内存使用率较低的 `q000` 开始？在 ChunkList 中，我们知道一个 chunk 随着内存的释放，会往当前 ChunkList 的前一个节点移动。
+  >
+  > **`q000` 存在的目的是什么？**
+  >
+  > `q000` 是用来保存内存利用率在 `1%-50%` 的 chunk ，那么这里为什么不包括 `0%` 的chunk？
+  > 直接弄清楚这些，才好理解为什么不从 `q000` 开始分配。`q000 中的chunk，当内存利用率为 0 时，就从链表中删除，直接释放物理内存，避免越来越多的 chunk 导致内存被占满。
+  >
+  > 想象一个场景，当应用在实际运行过程中，碰到访问高峰，这时需要分配的内存是平时的好几倍，当然也需要创建好几倍的 chunk ，如果先从 `q0000` 开始，这些在高峰期创建的 chunk 被回收的概率会大大降低，延缓了内存的回收进度，造成内存使用的浪费。
+  >
+  > **那么为什么选择从 `q050` 开始？**
+  >
+  > - 1、`q050` 保存的是内存利用率 `50%~100%` 的 chunk ，这应该是个折中的选择！这样大部分情况下，chunk 的利用率都会保持在一个较高水平，提高整个应用的内存利用率；
+  > - 2、`qinit` 的 chunk 利用率低，但不会被回收；
+  > - 3、`q075` 和 `q100` 由于内存利用率太高，导致内存分配的成功率大大降低，因此放到最后；
+
+- 第 11 行：调用 `#newChunk(pageSize, maxOrder, pageShifts, chunkSize)` **抽象**方法，新建 Chunk 内存块。需要 PoolArea 子类实现该方法，代码如下：
+
+  ```
+  protected abstract PoolChunk<T> newChunk(int pageSize, int maxOrder, int pageShifts, int chunkSize);
+  ```
+
+  - 第 13 行：调用新申请的 Chunk 内存块的
+
+     
+
+    ```
+    PoolChunk#allocate(normCapacity)
+    ```
+
+     
+
+    方法，申请对应的 Normal Page 内存块。实际上，如果申请分配的内存类型为 tiny 或 small 类型，实际申请的是 Subpage 内存块。如果遗忘这个过程的胖友，可以看看
+
+     
+
+    《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（二）PoolChunk》
+
+     
+
+    的
+
+     
+
+    「2.2 allocate」
+
+     
+
+    。
+
+    - 第 16 行：调用 `PoolChunk#initBuf(buf, handle, reqCapacity)` 方法，初始化 Normal Page / Subpage 内存块到 PooledByteBuf 对象中。
+
+  - 第 18 行：调用 `PoolChunkList#add(PoolChunk)` 方法，添加到 ChunkList 双向链中。
+
+### 2.4.2 allocateHuge
+
+`#allocateHuge(PooledByteBuf<T> buf, int reqCapacity)` 方法，申请 Huge 内存块。
+
+```
+ 1: private void allocateHuge(PooledByteBuf<T> buf, int reqCapacity) {
+ 2:     // 新建 Chunk 内存块，它是 unpooled 的
+ 3:     PoolChunk<T> chunk = newUnpooledChunk(reqCapacity);
+ 4:     // 增加 activeBytesHuge
+ 5:     activeBytesHuge.add(chunk.chunkSize());
+ 6:     // 初始化 Huge 内存块到 PooledByteBuf 对象中
+ 7:     buf.initUnpooled(chunk, reqCapacity);
+ 8:     // 增加 allocationsHuge
+ 9:     allocationsHuge.increment();
+10: }
+```
+
+- 第 3 行：调用 `#newUnpooledChunk(int capacity)` **抽象**方法，新建 **unpooled** Chunk 内存块。需要 PoolArea 子类实现该方法，代码如下：
+
+  ```
+  protected abstract PoolChunk<T> newUnpooledChunk(int capacity); //
+  ```
+
+- 第 7 行：调用 `PoolChunk#initUnpooled(chunk, reqCapacity)` 方法，初始化 Huge 内存块到 PooledByteBuf 对象中。
+
+- 第 5 行：增加 `activeBytesHuge` 计数。
+
+- 第 9 行：增加 `allocationsHuge` 计数。
+
+## 2.5 reallocate
+
+`#reallocate(PooledByteBuf<T> buf, int newCapacity, boolean freeOldMemor)` 方法，因为要扩容或缩容，所以重新分配合适的内存块给 PooledByteBuf 对象。代码如下：
+
+```
+ 1: void reallocate(PooledByteBuf<T> buf, int newCapacity, boolean freeOldMemory) {
+ 2:     if (newCapacity < 0 || newCapacity > buf.maxCapacity()) {
+ 3:         throw new IllegalArgumentException("newCapacity: " + newCapacity);
+ 4:     }
+ 5: 
+ 6:     // 容量大小没有变化，直接返回
+ 7:     int oldCapacity = buf.length;
+ 8:     if (oldCapacity == newCapacity) {
+ 9:         return;
+10:     }
+11: 
+12:     // 记录老的内存块的信息
+13:     PoolChunk<T> oldChunk = buf.chunk;
+14:     long oldHandle = buf.handle;
+15:     T oldMemory = buf.memory;
+16:     int oldOffset = buf.offset;
+17:     int oldMaxLength = buf.maxLength;
+18: 
+19:     // 记录读写索引
+20:     int readerIndex = buf.readerIndex();
+21:     int writerIndex = buf.writerIndex();
+22: 
+23:     // 分配新的内存块给 PooledByteBuf 对象
+24:     allocate(parent.threadCache(), buf, newCapacity);
+25: 
+26:     // 扩容
+27:     if (newCapacity > oldCapacity) {
+28:         // 将老的内存块的数据，复制到新的内存块中
+29:         memoryCopy(
+30:                 oldMemory, oldOffset,
+31:                 buf.memory, buf.offset, oldCapacity);
+32:     // 缩容
+33:     } else {
+34:         // 有部分数据未读取完
+35:         if (readerIndex < newCapacity) {
+36:             // 如果 writerIndex 大于 newCapacity ，重置为 newCapacity ，避免越界
+37:             if (writerIndex > newCapacity) {
+38:                 writerIndex = newCapacity;
+39:             }
+40:             // 将老的内存块的数据，复制到新的内存块中
+41:             memoryCopy(
+42:                     oldMemory, oldOffset + readerIndex,
+43:                     buf.memory, buf.offset + readerIndex, writerIndex - readerIndex);
+44:         // 全部读完，重置 readerIndex 和 writerIndex 为 newCapacity ，避免越界
+45:         } else {
+46:             readerIndex = writerIndex = newCapacity;
+47:         }
+48:     }
+49: 
+50:     // 设置读写索引
+51:     buf.setIndex(readerIndex, writerIndex);
+52: 
+53:     // 释放老的内存块
+54:     if (freeOldMemory) {
+55:         free(oldChunk, oldHandle, oldMaxLength, buf.cache);
+56:     }
+57: }
+```
+
+- 第 2 至 4 行：新的容量( `newCapacity` ) ，不能**超过** PooledByteBuf 对象的可分配的最大容量( `maxCapacity` ) 。
+
+- 第 6 至 10 行：容量大小没有变化，直接返回。
+
+- 第 12 至 17 行：记录
+
+  老的
+
+  内存块的信息。
+
+  - 第 20 至 21 行：记录读写索引。
+
+- 第 26 至 31 行：容量变大，说明是扩容，调用 `#memoryCopy(T src, int srcOffset, T dst, int dstOffset, int length)` **抽象**方法，将老的内存块的数据( 此处的复制，是全部数据 )，**复制到新的内存块中**。需要 PoolArea 子类实现该方法，代码如下：
+
+  ```
+  protected abstract void memoryCopy(T src, int srcOffset, T dst, int dstOffset, int length);
+  ```
+
+- 第 33 至 48 行：容量变小，说明是缩容。
+
+  - 第 34 至 44 行：有
+
+    部分
+
+    数据
+
+    未读取完
+
+    ，调用
+
+     
+
+    ```
+    #memoryCopy(T src, int srcOffset, T dst, int dstOffset, int length)
+    ```
+
+     
+
+    抽象
+
+    方法，将老的内存块的数据( 此处的复制，是全部数据 )，复制到新的内存块中。😈 注意，
+
+    此处复制的只有未读取完的部分数据
+
+    。
+
+    - 第 36 至 39 行：如果 `writerIndex` 大于 `newCapacity` ，重置为 `newCapacity` ，避免越界。
+
+  - 第 44 至 47 行：全部读完，
+
+    无需复制
+
+    。
+
+    - 第 46 行: 全部读完，重置 `readerIndex` 和 `writerIndex` 为 `newCapacity` ，避免越界。
+
+- 第 51 行：设置读写索引。
+
+- 第 53 至 56 行：如果需要释放老的内存块( `freeOldMemory` 为 `true` ) 时，调用 `#free(PoolChunk<T> chunk, long handle, int normCapacity, PoolThreadCache cache)` 方法，进行释放。详细解析，见 [「2.6 free」](https://svip.iocoder.cn/Netty/ByteBuf-3-5-Jemalloc-Arena/#) 。
+
+## 2.6 free
+
+`#free(PoolChunk<T> chunk, long handle, int normCapacity, PoolThreadCache cache)` 方法，释放内存块。代码如下：
+
+```
+ 1: void free(PoolChunk<T> chunk, long handle, int normCapacity, PoolThreadCache cache) {
+ 2:     if (chunk.unpooled) {
+ 3:         int size = chunk.chunkSize();
+ 4:         // 直接销毁 Chunk 内存块，因为占用空间较大
+ 5:         destroyChunk(chunk);
+ 6:         // 减少 activeBytesHuge 计数
+ 7:         activeBytesHuge.add(-size);
+ 8:         // 减少 deallocationsHuge 计数
+ 9:         deallocationsHuge.increment();
+10:     } else {
+11:         // 计算内存的 SizeClass
+12:         SizeClass sizeClass = sizeClass(normCapacity);
+13:         // 添加内存块到 PoolThreadCache 缓存
+14:         if (cache != null && cache.add(this, chunk, handle, normCapacity, sizeClass)) {
+15:             // cached so not free it.
+16:             return;
+17:         }
+18:         // 释放 Page / Subpage 内存块回 Chunk 中
+19:         freeChunk(chunk, handle, sizeClass);
+20:     }
+21: }
+```
+
+- 第 2 至 9 行：
+
+  unpooled
+
+   
+
+  类型的 Chunk 对象，目前是 Huge 内存块。
+
+  - 第 5 行：调用 `#destroyChunk(PoolChunk<T> chunk)` 方法，直接销毁 Chunk 内存块，因为占用空间较大。详细解析，见 [「2.7 finalize」](https://svip.iocoder.cn/Netty/ByteBuf-3-5-Jemalloc-Arena/#) 。
+  - 第 6 至 9 行：减少 `activeBytesHuge`、`deallocationsHuge` 计数。
+
+- 第 10 至 20 行：
+
+  pooled
+
+   
+
+  类型的 Chunk 对象，目前是 Page / Subpage 内存块。
+
+  - 第 12 行：调用 `#size(normCapacity)` 方法，计算内存的 SizeClass 内存类型。
+  - 第 12 行：计算内存的 SizeClass 。
+  - 第 13 至 17 行：调用 `PoolThreadCache#add(PoolArena<?> area, PoolChunk chunk, long handle, int normCapacity, SizeClass sizeClass)` 方法，添加内存块到 PoolThreadCache 的指定 MemoryRegionCache 的队列中，进行缓存。并且，返回是否添加成功。详细解析，见 [《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（六）PoolThreadCache》](http://svip.iocoder.cn/Netty/ByteBuf-3-6-Jemalloc-ThreadCache/) 。
+  - 第 19 行：调用 `#freeChunk(PoolChunk<T> chunk, long handle, SizeClass sizeClass)` 方法，释放指定位置的 Page / Subpage 内存块回 Chunk 中。
+
+### 2.6.1 freeChunk
+
+`#freeChunk(PoolChunk<T> chunk, long handle, SizeClass sizeClass)` 方法，释放指定位置的 Page / Subpage 内存块回 Chunk 中。代码如下：
+
+```
+ 1: void freeChunk(PoolChunk<T> chunk, long handle, SizeClass sizeClass) {
+ 2:     final boolean destroyChunk;
+ 3:     synchronized (this) { // 锁，避免并发
+ 4:         // 减小相应的计数
+ 5:         switch (sizeClass) {
+ 6:         case Normal:
+ 7:             ++deallocationsNormal;
+ 8:             break;
+ 9:         case Small:
+10:             ++deallocationsSmall;
+11:             break;
+12:         case Tiny:
+13:             ++deallocationsTiny;
+14:             break;
+15:         default:
+16:             throw new Error();
+17:         }
+18:         // 释放指定位置的内存块
+19:         destroyChunk = !chunk.parent.free(chunk, handle);
+20:     }
+21:     // 当 destroyChunk 为 true 时，意味着 Chunk 中不存在在使用的 Page / Subpage 内存块。也就是说，内存使用率为 0 ，所以销毁 Chunk
+22:     if (destroyChunk) {
+23:         // destroyChunk not need to be called while holding the synchronized lock.
+24:         destroyChunk(chunk);
+25:     }
+26: }
+```
+
+- 第 4 至 17 行：减小**相应**的计数。
+- 第 19 行：调用 Chunk 对象所在的 ChunList 的 `ChunkList#free(chunk, handle)` 方法，释放指定位置的内存块。如果遗忘这个过程的胖友，可以看看 [《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（四）PoolChunkList》](http://svip.iocoder.cn/Netty/ByteBuf-3-4-Jemalloc-chunkList) 的 [「2.3 free」](https://svip.iocoder.cn/Netty/ByteBuf-3-5-Jemalloc-Arena/#) 。
+- 第 21 至 25 行：当 `destroyChunk` 为 `true` 时，意味着 Chunk 中不存在在使用的 Page / Subpage 内存块。也就是说，内存使用率为 0 ，所以调用 `#destroyChunk(PoolChunk<T> chunk)` 方法，直接销毁 Chunk 内存块，回收对应的空间。详细解析，见 [「2.7 finalize」](https://svip.iocoder.cn/Netty/ByteBuf-3-5-Jemalloc-Arena/#) 。
+
+## 2.7 finalize
+
+在 PoolArena 对象被 GC 回收时，清理其管理的内存。😈 实际上，主要是为了清理对外内存。代码如下：
+
+```
+@Override
+protected final void finalize() throws Throwable {
+    try {
+        // 调用父方法
+        super.finalize();
+    } finally {
+        // 清理 tiny Subpage 们
+        destroyPoolSubPages(smallSubpagePools);
+        // 清理 small Subpage 们
+        destroyPoolSubPages(tinySubpagePools);
+        // 清理 ChunkList 们
+        destroyPoolChunkLists(qInit, q000, q025, q050, q075, q100);
+    }
+}
+
+private static void destroyPoolSubPages(PoolSubpage<?>[] pages) {
+    for (PoolSubpage<?> page : pages) {
+        page.destroy();
+    }
+}
+
+private void destroyPoolChunkLists(PoolChunkList<T>... chunkLists) {
+    for (PoolChunkList<T> chunkList: chunkLists) {
+        chunkList.destroy(this);
+    }
+}
+```
+
+## 2.8 PoolArenaMetric
+
+> 老艿艿：这个小节，主要是读取 Metric 数据的方法，快速浏览或跳过都可以。
+
+`io.netty.buffer.PoolArenaMetric` ，PoolArena Metric 接口。代码如下：
+
+```
+public interface PoolArenaMetric {
+
+    /**
+     * Returns the number of thread caches backed by this arena.
+     */
+    int numThreadCaches();
+
+    /**
+     * Returns the number of tiny sub-pages for the arena.
+     */
+    int numTinySubpages();
+    /**
+     * Returns the number of small sub-pages for the arena.
+     */
+    int numSmallSubpages();
+    /**
+     * Returns the number of chunk lists for the arena.
+     */
+    int numChunkLists();
+
+    /**
+     * Returns an unmodifiable {@link List} which holds {@link PoolSubpageMetric}s for tiny sub-pages.
+     */
+    List<PoolSubpageMetric> tinySubpages();
+    /**
+     * Returns an unmodifiable {@link List} which holds {@link PoolSubpageMetric}s for small sub-pages.
+     */
+    List<PoolSubpageMetric> smallSubpages();
+    /**
+     * Returns an unmodifiable {@link List} which holds {@link PoolChunkListMetric}s.
+     */
+    List<PoolChunkListMetric> chunkLists();
+
+    /**
+     * Return the number of allocations done via the arena. This includes all sizes.
+     */
+    long numAllocations();
+    /**
+     * Return the number of tiny allocations done via the arena.
+     */
+    long numTinyAllocations();
+    /**
+     * Return the number of small allocations done via the arena.
+     */
+    long numSmallAllocations();
+    /**
+     * Return the number of normal allocations done via the arena.
+     */
+    long numNormalAllocations();
+    /**
+     * Return the number of huge allocations done via the arena.
+     */
+    long numHugeAllocations();
+
+    /**
+     * Return the number of deallocations done via the arena. This includes all sizes.
+     */
+    long numDeallocations();
+    /**
+     * Return the number of tiny deallocations done via the arena.
+     */
+    long numTinyDeallocations();
+    /**
+     * Return the number of small deallocations done via the arena.
+     */
+    long numSmallDeallocations();
+    /**
+     * Return the number of normal deallocations done via the arena.
+     */
+    long numNormalDeallocations();
+    /**
+     * Return the number of huge deallocations done via the arena.
+     */
+    long numHugeDeallocations();
+
+    /**
+     * Return the number of currently active allocations.
+     */
+    long numActiveAllocations();
+
+    /**
+     * Return the number of currently active tiny allocations.
+     */
+    long numActiveTinyAllocations();
+    /**
+     * Return the number of currently active small allocations.
+     */
+    long numActiveSmallAllocations();
+    /**
+     * Return the number of currently active normal allocations.
+     */
+    long numActiveNormalAllocations();
+    /**
+     * Return the number of currently active huge allocations.
+     */
+    long numActiveHugeAllocations();
+
+    /**
+     * Return the number of active bytes that are currently allocated by the arena.
+     */
+    long numActiveBytes();
+}
+```
+
+------
+
+PoolArena 对 PoolArenaMetric 接口的实现，代码如下：
+
+```
+@Override
+public int numThreadCaches() {
+    return numThreadCaches.get();
+}
+
+@Override
+public int numTinySubpages() {
+    return tinySubpagePools.length;
+}
+
+@Override
+public int numSmallSubpages() {
+    return smallSubpagePools.length;
+}
+
+@Override
+public int numChunkLists() {
+    return chunkListMetrics.size();
+}
+
+@Override
+public List<PoolSubpageMetric> tinySubpages() {
+    return subPageMetricList(tinySubpagePools);
+}
+
+@Override
+public List<PoolSubpageMetric> smallSubpages() {
+    return subPageMetricList(smallSubpagePools);
+}
+
+@Override
+public List<PoolChunkListMetric> chunkLists() {
+    return chunkListMetrics;
+}
+
+private static List<PoolSubpageMetric> subPageMetricList(PoolSubpage<?>[] pages) {
+    List<PoolSubpageMetric> metrics = new ArrayList<PoolSubpageMetric>();
+    for (PoolSubpage<?> head : pages) {
+        if (head.next == head) {
+            continue;
+        }
+        PoolSubpage<?> s = head.next;
+        for (;;) {
+            metrics.add(s);
+            s = s.next;
+            if (s == head) {
+                break;
+            }
+        }
+    }
+    return metrics;
+}
+
+@Override
+public long numAllocations() {
+    final long allocsNormal;
+    synchronized (this) {
+        allocsNormal = allocationsNormal;
+    }
+    return allocationsTiny.value() + allocationsSmall.value() + allocsNormal + allocationsHuge.value();
+}
+
+@Override
+public long numTinyAllocations() {
+    return allocationsTiny.value();
+}
+
+@Override
+public long numSmallAllocations() {
+    return allocationsSmall.value();
+}
+
+@Override
+public synchronized long numNormalAllocations() {
+    return allocationsNormal;
+}
+
+@Override
+public long numDeallocations() {
+    final long deallocs;
+    synchronized (this) {
+        deallocs = deallocationsTiny + deallocationsSmall + deallocationsNormal;
+    }
+    return deallocs + deallocationsHuge.value();
+}
+
+@Override
+public synchronized long numTinyDeallocations() {
+    return deallocationsTiny;
+}
+
+@Override
+public synchronized long numSmallDeallocations() {
+    return deallocationsSmall;
+}
+
+@Override
+public synchronized long numNormalDeallocations() {
+    return deallocationsNormal;
+}
+
+@Override
+public long numHugeAllocations() {
+    return allocationsHuge.value();
+}
+
+@Override
+public long numHugeDeallocations() {
+    return deallocationsHuge.value();
+}
+
+@Override
+public  long numActiveAllocations() {
+    long val = allocationsTiny.value() + allocationsSmall.value() + allocationsHuge.value()
+            - deallocationsHuge.value();
+    synchronized (this) {
+        val += allocationsNormal - (deallocationsTiny + deallocationsSmall + deallocationsNormal);
+    }
+    return max(val, 0);
+}
+
+@Override
+public long numActiveTinyAllocations() {
+    return max(numTinyAllocations() - numTinyDeallocations(), 0);
+}
+
+@Override
+public long numActiveSmallAllocations() {
+    return max(numSmallAllocations() - numSmallDeallocations(), 0);
+}
+
+@Override
+public long numActiveNormalAllocations() {
+    final long val;
+    synchronized (this) {
+        val = allocationsNormal - deallocationsNormal;
+    }
+    return max(val, 0);
+}
+
+@Override
+public long numActiveHugeAllocations() {
+    return max(numHugeAllocations() - numHugeDeallocations(), 0);
+}
+
+@Override
+public long numActiveBytes() {
+    long val = activeBytesHuge.value();
+    synchronized (this) {
+        for (int i = 0; i < chunkListMetrics.size(); i++) {
+            for (PoolChunkMetric m: chunkListMetrics.get(i)) {
+                val += m.chunkSize();
+            }
+        }
+    }
+    return max(0, val);
+}
+```
+
+### 2.8.1 incTinySmallAllocation
+
+`#incTinySmallAllocation(boolean tiny)` 方法，增加 `allocationsTiny` 或 `allocationsSmall` 计数。代码如下：
+
+```
+private void incTinySmallAllocation(boolean tiny) {
+    if (tiny) {
+        allocationsTiny.increment();
+    } else {
+        allocationsSmall.increment();
+    }
+}
+```
+
+## 2.9 抽象方法
+
+虽然上文中，已经提到了几个抽象方法，这里还是同一整理如下：
+
+```
+abstract boolean isDirect();
+
+protected abstract PoolChunk<T> newChunk(int pageSize, int maxOrder, int pageShifts, int chunkSize); //
+protected abstract PoolChunk<T> newUnpooledChunk(int capacity); //
+
+protected abstract PooledByteBuf<T> newByteBuf(int maxCapacity);
+
+protected abstract void memoryCopy(T src, int srcOffset, T dst, int dstOffset, int length); //
+    
+protected abstract void destroyChunk(PoolChunk<T> chunk);
+```
+
+# 3. HeapArena
+
+HeapArena ，继承 PoolArena 抽象类，对 Heap 类型的内存分配。
+
+> HeapArena 是 PoolArena 的内部静态类。代码比较简单，胖友自己看看就成。
+
+```
+static final class HeapArena extends PoolArena<byte[]> { // 管理 byte[] 数组
+
+    HeapArena(PooledByteBufAllocator parent, int pageSize, int maxOrder, int pageShifts, int chunkSize, int directMemoryCacheAlignment) {
+        super(parent, pageSize, maxOrder, pageShifts, chunkSize, directMemoryCacheAlignment);
+    }
+
+    private static byte[] newByteArray(int size) {
+        return PlatformDependent.allocateUninitializedArray(size); // 创建 byte[] 数组
+    }
+
+    @Override
+    boolean isDirect() {
+        return false;
+    }
+
+    @Override
+    protected PoolChunk<byte[]> newChunk(int pageSize, int maxOrder, int pageShifts, int chunkSize) {
+        return new PoolChunk<byte[]>(this, newByteArray(chunkSize), pageSize, maxOrder, pageShifts, chunkSize, 0);
+    }
+
+    @Override
+    protected PoolChunk<byte[]> newUnpooledChunk(int capacity) {
+        return new PoolChunk<byte[]>(this, newByteArray(capacity), capacity, 0);
+    }
+
+    @Override
+    protected void destroyChunk(PoolChunk<byte[]> chunk) {
+        // Rely on GC. 依赖 GC
+    }
+
+    @Override
+    protected PooledByteBuf<byte[]> newByteBuf(int maxCapacity) {
+        return HAS_UNSAFE ? PooledUnsafeHeapByteBuf.newUnsafeInstance(maxCapacity)
+                : PooledHeapByteBuf.newInstance(maxCapacity);
+    }
+
+    @Override
+    protected void memoryCopy(byte[] src, int srcOffset, byte[] dst, int dstOffset, int length) {
+        if (length == 0) {
+            return;
+        }
+
+        System.arraycopy(src, srcOffset, dst, dstOffset, length);
+    }
+}
+```
+
+# 4. DirectArena
+
+DirectArena ，继承 PoolArena 抽象类，对 Direct 类型的内存分配。
+
+> DirectArena 是 PoolArena 的内部静态类。代码比较简单，胖友自己看看就成。
+
+```
+static final class DirectArena extends PoolArena<ByteBuffer> { // 管理 Direct ByteBuffer 对象
+
+    DirectArena(PooledByteBufAllocator parent, int pageSize, int maxOrder,
+            int pageShifts, int chunkSize, int directMemoryCacheAlignment) {
+        super(parent, pageSize, maxOrder, pageShifts, chunkSize, directMemoryCacheAlignment);
+    }
+
+    @Override
+    boolean isDirect() {
+        return true;
+    }
+
+    private int offsetCacheLine(ByteBuffer memory) {
+        // We can only calculate the offset if Unsafe is present as otherwise directBufferAddress(...) will
+        // throw an NPE.
+        return HAS_UNSAFE ?
+                (int) (PlatformDependent.directBufferAddress(memory) & directMemoryCacheAlignmentMask) : 0;
+    }
+
+    @Override
+    protected PoolChunk<ByteBuffer> newChunk(int pageSize, int maxOrder,
+            int pageShifts, int chunkSize) {
+        if (directMemoryCacheAlignment == 0) {
+            return new PoolChunk<ByteBuffer>(this, allocateDirect(chunkSize), pageSize, maxOrder, pageShifts, chunkSize, 0);
+        }
+        final ByteBuffer memory = allocateDirect(chunkSize + directMemoryCacheAlignment);
+        return new PoolChunk<ByteBuffer>(this, memory, pageSize, maxOrder, pageShifts, chunkSize, offsetCacheLine(memory));
+    }
+
+    @Override
+    protected PoolChunk<ByteBuffer> newUnpooledChunk(int capacity) {
+        if (directMemoryCacheAlignment == 0) {
+            return new PoolChunk<ByteBuffer>(this,
+                    allocateDirect(capacity), capacity, 0);
+        }
+        final ByteBuffer memory = allocateDirect(capacity + directMemoryCacheAlignment);
+        return new PoolChunk<ByteBuffer>(this, memory, capacity, offsetCacheLine(memory));
+    }
+
+    private static ByteBuffer allocateDirect(int capacity) { // 创建 Direct ByteBuffer 对象
+        return PlatformDependent.useDirectBufferNoCleaner() ?
+                PlatformDependent.allocateDirectNoCleaner(capacity) : ByteBuffer.allocateDirect(capacity);
+    }
+
+    @Override
+    protected void destroyChunk(PoolChunk<ByteBuffer> chunk) {
+        if (PlatformDependent.useDirectBufferNoCleaner()) {
+            PlatformDependent.freeDirectNoCleaner(chunk.memory);
+        } else {
+            PlatformDependent.freeDirectBuffer(chunk.memory);
+        }
+    }
+
+    @Override
+    protected PooledByteBuf<ByteBuffer> newByteBuf(int maxCapacity) {
+        if (HAS_UNSAFE) {
+            return PooledUnsafeDirectByteBuf.newInstance(maxCapacity);
+        } else {
+            return PooledDirectByteBuf.newInstance(maxCapacity);
+        }
+    }
+
+    @Override
+    protected void memoryCopy(ByteBuffer src, int srcOffset, ByteBuffer dst, int dstOffset, int length) {
+        if (length == 0) {
+            return;
+        }
+
+        if (HAS_UNSAFE) {
+            PlatformDependent.copyMemory(
+                    PlatformDependent.directBufferAddress(src) + srcOffset,
+                    PlatformDependent.directBufferAddress(dst) + dstOffset, length);
+        } else {
+            // We must duplicate the NIO buffers because they may be accessed by other Netty buffers.
+            src = src.duplicate();
+            dst = dst.duplicate();
+            src.position(srcOffset).limit(srcOffset + length);
+            dst.position(dstOffset);
+            dst.put(src);
+        }
+    }
+}
+```
+
+# 666. 彩蛋
+
+终于看懂 Jemalloc 算法的大体的实现。一开始看，一脸懵逼！！！其实耐下性子，慢慢看，总能看懂的。
+
+当然，如果这个时候让自己手写 Jemalloc 算法，估计还是会泪崩。哈哈哈，相比写代码来说，读懂代码还是容易很多的。
+
+嘿嘿，找了一张厉害的图，胖友在结合这个图，理解理解。
+
+> FROM [《Netty Buffer - 内存管理 PoolArena》](http://www.woowen.com/源码/2016/08/01/Netty buffer - 内存管理 PoolArena/)
+>
+> [![内存分配](46-Netty 源码解析-Buffer 之 Jemalloc（五）PoolArena.assets/04.png)](http://static.iocoder.cn/images/Netty/2018_09_13/04.png)内存分配
+
+------
+
+参考如下文章：
+
+- 占小狼 [《深入浅出Netty内存管理 PoolArena》](https://www.jianshu.com/p/4856bd30dd56)
+- Hypercube [《自顶向下深入分析Netty（十）–PoolArena》](https://www.jianshu.com/p/86fbacdb68bd)
\ No newline at end of file
diff --git a/netty/47-Netty 源码解析-Buffer 之 Jemalloc（六）PoolThreadCache.assets/01.png b/netty/47-Netty 源码解析-Buffer 之 Jemalloc（六）PoolThreadCache.assets/01.png
new file mode 100644
index 0000000..61721ec
Binary files /dev/null and b/netty/47-Netty 源码解析-Buffer 之 Jemalloc（六）PoolThreadCache.assets/01.png differ
diff --git a/netty/47-Netty 源码解析-Buffer 之 Jemalloc（六）PoolThreadCache.assets/02.png b/netty/47-Netty 源码解析-Buffer 之 Jemalloc（六）PoolThreadCache.assets/02.png
new file mode 100644
index 0000000..3def367
Binary files /dev/null and b/netty/47-Netty 源码解析-Buffer 之 Jemalloc（六）PoolThreadCache.assets/02.png differ
diff --git a/netty/47-Netty 源码解析-Buffer 之 Jemalloc（六）PoolThreadCache.md b/netty/47-Netty 源码解析-Buffer 之 Jemalloc（六）PoolThreadCache.md
new file mode 100644
index 0000000..dd0bc58
--- /dev/null
+++ b/netty/47-Netty 源码解析-Buffer 之 Jemalloc（六）PoolThreadCache.md	
@@ -0,0 +1,868 @@
+# 精尽 Netty 源码解析 —— Buffer 之 Jemalloc（六）PoolThreadCache
+
+# 1. 概述
+
+在 [《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（五）PoolArena》](http://svip.iocoder.cn/Netty/ByteBuf-3-5-Jemalloc-Arena) 一文中，我们看到 PoolArena 在分配( `#allocate(...)` )和释放( `#free(...)` )内存的过程中，无可避免会出现 `synchronized` 的身影。虽然锁的粒度不是很大，但是如果一个 PoolArena 如果被**多个**线程引用，带来的线程锁的同步和竞争。并且，如果在锁竞争的过程中，申请 Direct ByteBuffer ，那么带来的线程等待就可能是**几百毫秒**的时间。
+
+那么该如何解决呢？如下图红框所示：
+
+> FROM [《jemalloc源码解析-内存管理》](http://brionas.github.io/2015/01/31/jemalloc源码解析-内存管理/)
+>
+> [![大体结构](47-Netty 源码解析-Buffer 之 Jemalloc（六）PoolThreadCache.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_09_16/01.png)大体结构
+
+给**每个**线程引入其**独有**的 tcache 线程缓存。
+
+- 在释放已分配的内存块时，不放回到 Chunk 中，而是缓存到 tcache 中。
+- 在分配内存块时，优先从 tcache 获取。无法获取到，再从 Chunk 中分配。
+
+通过这样的方式，尽可能的避免多线程的同步和竞争。
+
+# 2. PoolThreadCache
+
+`io.netty.buffer.PoolThreadCache` ，Netty 对 Jemalloc tcache 的实现类，内存分配的线程缓存。
+
+## 2.1 构造方法
+
+```
+/**
+ * 对应的 Heap PoolArena 对象
+ */
+final PoolArena<byte[]> heapArena;
+/**
+ * 对应的 Direct PoolArena 对象
+ */
+final PoolArena<ByteBuffer> directArena;
+
+// Hold the caches for the different size classes, which are tiny, small and normal.
+/**
+ * Heap 类型的 tiny Subpage 内存块缓存数组
+ */
+private final MemoryRegionCache<byte[]>[] tinySubPageHeapCaches;
+/**
+ * Heap 类型的 small Subpage 内存块缓存数组
+ */
+private final MemoryRegionCache<byte[]>[] smallSubPageHeapCaches;
+/**
+ * Heap 类型的 normal 内存块缓存数组
+ */
+private final MemoryRegionCache<byte[]>[] normalHeapCaches;
+/**
+ * Direct 类型的 tiny Subpage 内存块缓存数组
+ */
+private final MemoryRegionCache<ByteBuffer>[] tinySubPageDirectCaches;
+/**
+ * Direct 类型的 small Subpage 内存块缓存数组
+ */
+private final MemoryRegionCache<ByteBuffer>[] smallSubPageDirectCaches;
+/**
+ * Direct 类型的 normal 内存块缓存数组
+ */
+private final MemoryRegionCache<ByteBuffer>[] normalDirectCaches;
+
+// Used for bitshifting when calculate the index of normal caches later
+/**
+ * 用于计算请求分配的 normal 类型的内存块，在 {@link #normalDirectCaches} 数组中的位置
+ *
+ * 默认为 log2(pageSize) = log2(8192) = 13
+ */
+private final int numShiftsNormalDirect;
+/**
+ * 用于计算请求分配的 normal 类型的内存块，在 {@link #normalHeapCaches} 数组中的位置
+ *
+ * 默认为 log2(pageSize) = log2(8192) = 13
+ */
+private final int numShiftsNormalHeap;
+
+/**
+ * 分配次数
+ */
+private int allocations;
+/**
+ * {@link #allocations} 到达该阀值，释放缓存
+ *  
+ * 默认为 8192 次
+ * 
+ * @see #free()
+ */
+private final int freeSweepAllocationThreshold;
+
+  1: PoolThreadCache(PoolArena<byte[]> heapArena, PoolArena<ByteBuffer> directArena,
+  2:                 int tinyCacheSize, int smallCacheSize, int normalCacheSize,
+  3:                 int maxCachedBufferCapacity, int freeSweepAllocationThreshold) {
+  4:     if (maxCachedBufferCapacity < 0) {
+  5:         throw new IllegalArgumentException("maxCachedBufferCapacity: "
+  6:                 + maxCachedBufferCapacity + " (expected: >= 0)");
+  7:     }
+  8:     this.freeSweepAllocationThreshold = freeSweepAllocationThreshold;
+  9:     this.heapArena = heapArena;
+ 10:     this.directArena = directArena;
+ 11: 
+ 12:     // 初始化 Direct 类型的内存块缓存
+ 13:     if (directArena != null) {
+ 14:         // 创建 tinySubPageDirectCaches
+ 15:         tinySubPageDirectCaches = createSubPageCaches(tinyCacheSize, PoolArena.numTinySubpagePools, SizeClass.Tiny);
+ 16:         // 创建 smallSubPageDirectCaches
+ 17:         smallSubPageDirectCaches = createSubPageCaches(smallCacheSize, directArena.numSmallSubpagePools, SizeClass.Small);
+ 18: 
+ 19:         // 计算 numShiftsNormalDirect
+ 20:         numShiftsNormalDirect = log2(directArena.pageSize);
+ 21:         // 创建 normalDirectCaches
+ 22:         normalDirectCaches = createNormalCaches(normalCacheSize, maxCachedBufferCapacity, directArena);
+ 23: 
+ 24:         // 增加 directArena 的线程引用计数
+ 25:         directArena.numThreadCaches.getAndIncrement();
+ 26:     } else {
+ 27:         // No directArea is configured so just null out all caches
+ 28:         tinySubPageDirectCaches = null;
+ 29:         smallSubPageDirectCaches = null;
+ 30:         normalDirectCaches = null;
+ 31:         numShiftsNormalDirect = -1;
+ 32:     }
+ 33:     // 初始化 Heap 类型的内存块缓存。同上面部分。
+ 34:     if (heapArena != null) {
+ 35:         // Create the caches for the heap allocations
+ 36:         tinySubPageHeapCaches = createSubPageCaches(tinyCacheSize, PoolArena.numTinySubpagePools, SizeClass.Tiny);
+ 37:         smallSubPageHeapCaches = createSubPageCaches(smallCacheSize, heapArena.numSmallSubpagePools, SizeClass.Small);
+ 38: 
+ 39:         numShiftsNormalHeap = log2(heapArena.pageSize);
+ 40:         normalHeapCaches = createNormalCaches(normalCacheSize, maxCachedBufferCapacity, heapArena);
+ 41: 
+ 42:         heapArena.numThreadCaches.getAndIncrement();
+ 43:     } else {
+ 44:         // No heapArea is configured so just null out all caches
+ 45:         tinySubPageHeapCaches = null;
+ 46:         smallSubPageHeapCaches = null;
+ 47:         normalHeapCaches = null;
+ 48:         numShiftsNormalHeap = -1;
+ 49:     }
+ 50: 
+ 51:     // 校验参数，保证 PoolThreadCache 可缓存内存块。
+ 52:     // Only check if there are caches in use.
+ 53:     if ((tinySubPageDirectCaches != null || smallSubPageDirectCaches != null || normalDirectCaches != null
+ 54:             || tinySubPageHeapCaches != null || smallSubPageHeapCaches != null || normalHeapCaches != null)
+ 55:             && freeSweepAllocationThreshold < 1) {
+ 56:         throw new IllegalArgumentException("freeSweepAllocationThreshold: " + freeSweepAllocationThreshold + " (expected: > 0)");
+ 57:     }
+ 58: }
+```
+
+- 虽然代码比较多，主要分为 Heap 和 Direct 两种内存。
+
+- Direct 相关
+
+  - `directArena` 属性，对应的 Heap PoolArena 对象。
+
+  - ```
+    tinySubPageDirectCaches
+    ```
+
+     
+
+    属性，Direct 类型的 tiny Subpage 内存块缓存数组。
+
+    - 默认情况下，数组大小为 512 。
+    - 在【第 15 行】的代码，调用 `#createSubPageCaches(int cacheSize, int numCaches, SizeClass sizeClass)` 方法，创建 MemoryRegionCache 数组。详细解析，见 [「2.2 createSubPageCaches」](https://svip.iocoder.cn/Netty/ByteBuf-3-6-Jemalloc-ThreadCache/#) 。
+
+  - ```
+    smallSubPageDirectCaches
+    ```
+
+     
+
+    属性，Direct 类型的 small Subpage 内存块缓存数组。
+
+    - 默认情况下，数组大小为 256 。
+    - 在【第 17 行】的代码，调用 `#createSubPageCaches(int cacheSize, int numCaches, SizeClass sizeClass)` 方法，创建 MemoryRegionCache 数组。详细解析，见 [「2.2 createSubPageCaches」](https://svip.iocoder.cn/Netty/ByteBuf-3-6-Jemalloc-ThreadCache/#) 。
+
+  - ```
+    normalDirectCaches
+    ```
+
+     
+
+    属性，Direct 类型的 normal Page 内存块缓存数组。
+
+    - 默认情况下，数组大小为 64 。
+
+    - 在【第 22 行】的代码，调用 `#createNormalCaches(int cacheSize, int maxCachedBufferCapacity, PoolArena<T> area)` 方法，创建 MemoryRegionCache 数组。详细解析，见 [「2.3 createNormalCaches」](https://svip.iocoder.cn/Netty/ByteBuf-3-6-Jemalloc-ThreadCache/#) 。
+
+    - ```
+      numShiftsNormalDirect
+      ```
+
+       
+
+      属性，用于计算请求分配的 normal 类型的内存块，在
+
+       
+
+      ```
+      normalDirectCaches
+      ```
+
+       
+
+      数组中的位置。
+
+      - 默认情况下，数值为 13 。
+      - 在【第 20 行】的代码，调用 `#log2(int pageSize)` 方法， `log2(pageSize) = log2(8192) = 13` 。
+
+  - 在【第 25 行】的代码，增加 `directArena` 的线程引用计数。通过这样的方式，我们能够知道，一个 PoolArena 对象，被多少线程所引用。
+
+- Heap 相关，和【Direct 相关】基本**类似**。
+
+- ```
+  allocations
+  ```
+
+   
+
+  属性，分配次数计数器。每次分配时，该计数器 + 1 。
+
+  - `freeSweepAllocationThreshold` 属性，当 `allocations` 到达该阀值时，调用 `#free()` 方法，释放缓存。同时，会重置 `allocations` 计数器为 0 。
+
+## 2.2 createSubPageCaches
+
+`#createSubPageCaches(int cacheSize, int numCaches, SizeClass sizeClass)` 方法，创建 Subpage 内存块缓存数组。代码如下：
+
+```
+// tiny 类型，默认 cacheSize = PooledByteBufAllocator.DEFAULT_TINY_CACHE_SIZE = 512 , numCaches = PoolArena.numTinySubpagePools = 512 >>> 4 = 32
+// small 类型，默认 cacheSize = PooledByteBufAllocator.DEFAULT_SMALL_CACHE_SIZE = 256 , numCaches = pageSize - 9 = 13 - 9 = 4
+private static <T> MemoryRegionCache<T>[] createSubPageCaches(int cacheSize, int numCaches, SizeClass sizeClass) {
+    if (cacheSize > 0 && numCaches > 0) {
+        @SuppressWarnings("unchecked")
+        MemoryRegionCache<T>[] cache = new MemoryRegionCache[numCaches];
+        for (int i = 0; i < cache.length; i++) {
+            // TODO: maybe use cacheSize / cache.length
+            cache[i] = new SubPageMemoryRegionCache<T>(cacheSize, sizeClass);
+        }
+        return cache;
+    } else {
+        return null;
+    }
+}
+```
+
+- 创建的 Subpage 内存块缓存数组，实际和
+
+   
+
+  ```
+  PoolArena.tinySubpagePools
+  ```
+
+   
+
+  和
+
+   
+
+  ```
+  PoolArena.smallSubpagePools
+  ```
+
+   
+
+  数组
+
+  大小保持一致
+
+  。从而实现，相同大小的内存，能对应相同的数组下标。
+
+  - `sizeClass` = `tiny` 时， 默认 `cacheSize` = `PooledByteBufAllocator.DEFAULT_TINY_CACHE_SIZE = 512` , `numCaches` = `PoolArena.numTinySubpagePools = 512 >>> 4 = 32` 。
+  - `sizeClass` = `small` 时，默认 `cacheSize` = `PooledByteBufAllocator.DEFAULT_SMALL_CACHE_SIZE = 256` , `numCaches` = `pageSize - 9 = 13 - 9 = 4` 。
+
+- 创建的数组，每个元素的类型为 SubPageMemoryRegionCache 。详细解析，见 [「3.X.1 SubPageMemoryRegionCache」](https://svip.iocoder.cn/Netty/ByteBuf-3-6-Jemalloc-ThreadCache/#) 。
+
+## 2.3 createNormalCaches
+
+`#createSubPageCaches(int cacheSize, int numCaches, SizeClass sizeClass)` 方法，创建 Normal Page 内存块缓存数组。代码如下：
+
+```
+ // normal 类型，默认 cacheSize = PooledByteBufAllocator.DEFAULT_NORMAL_CACHE_SIZE = 64 , maxCachedBufferCapacity = PoolArena.DEFAULT_MAX_CACHED_BUFFER_CAPACITY = 32 * 1024 = 32KB
+private static <T> MemoryRegionCache<T>[] createNormalCaches(int cacheSize, int maxCachedBufferCapacity, PoolArena<T> area) {
+    if (cacheSize > 0 && maxCachedBufferCapacity > 0) {
+        // <1> 计算数组大小
+        int max = Math.min(area.chunkSize, maxCachedBufferCapacity);
+        int arraySize = Math.max(1, log2(max / area.pageSize) + 1);
+
+        @SuppressWarnings("unchecked")
+        MemoryRegionCache<T>[] cache = new MemoryRegionCache[arraySize];
+        for (int i = 0; i < cache.length; i++) {
+            cache[i] = new NormalMemoryRegionCache<T>(cacheSize);
+        }
+        return cache;
+    } else {
+        return null;
+    }
+}
+```
+
+- `maxCachedBufferCapacity` 属性，缓存的 Normal 内存块的最大容量，避免过大的 Normal 内存块被缓存，占用过多通过。默认情况下，`maxCachedBufferCapacity = PoolArena.DEFAULT_MAX_CACHED_BUFFER_CAPACITY = 32 * 1024 = 32KB` 。也就说，在 `<1>` 处，`arraySize` 的计算**数组大小**的结果为 3 。刚好是 `cache[0] = 8KB`、`cache[1] = 16KB`、`cache[2] = 32KB` 。那么，如果申请的 Normal 内存块大小为 `64KB` ，超过了数组大小，所以无法被缓存。😈 是不是和原先自己认为的 `maxCachedBufferCapacity` 实现最大容量的想法，有点不同。
+- 创建的数组，每个元素的类型为 SubPageMemoryRegionCache 。详细解析，见 [「3.X.2 NormalMemoryRegionCache」](https://svip.iocoder.cn/Netty/ByteBuf-3-6-Jemalloc-ThreadCache/#) 。
+
+## 2.4 cache
+
+```
+private MemoryRegionCache<?> cacheForTiny(PoolArena<?> area, int normCapacity) {
+    // 获得数组下标
+    int idx = PoolArena.tinyIdx(normCapacity);
+    if (area.isDirect()) {
+        return cache(tinySubPageDirectCaches, idx);
+    }
+    return cache(tinySubPageHeapCaches, idx);
+}
+
+private MemoryRegionCache<?> cacheForSmall(PoolArena<?> area, int normCapacity) {
+    // 获得数组下标
+    int idx = PoolArena.smallIdx(normCapacity);
+    if (area.isDirect()) {
+        return cache(smallSubPageDirectCaches, idx);
+    }
+    return cache(smallSubPageHeapCaches, idx);
+}
+
+private MemoryRegionCache<?> cacheForNormal(PoolArena<?> area, int normCapacity) {
+    if (area.isDirect()) {
+        // 获得数组下标
+        int idx = log2(normCapacity >> numShiftsNormalDirect);
+        return cache(normalDirectCaches, idx);
+    }
+    // 获得数组下标
+    int idx = log2(normCapacity >> numShiftsNormalHeap);
+    return cache(normalHeapCaches, idx);
+}
+```
+
+- 三个方法，分别获取内存容量对应所在的 MemoryRegionCache 对象。通过调用 `#cache(MemoryRegionCache<T>[] cache, int idx)` 方法，代码如下：
+
+  ```
+  private static <T> MemoryRegionCache<T> cache(MemoryRegionCache<T>[] cache, int idx) {
+      // 不在范围内，说明不缓存该容量的内存块
+      if (cache == null || idx > cache.length - 1) {
+          return null;
+      }
+      // 获得 MemoryRegionCache 对象
+      return cache[idx];
+  }
+  ```
+
+------
+
+当然，考虑到使用便利，封装了 `#cache(PoolArena<?> area, int normCapacity, SizeClass sizeClass)` 方法，支持获取对应内存类型的 MemoryRegionCache 对象。代码如下：
+
+```
+private MemoryRegionCache<?> cache(PoolArena<?> area, int normCapacity, SizeClass sizeClass) {
+    switch (sizeClass) {
+    case Normal:
+        return cacheForNormal(area, normCapacity);
+    case Small:
+        return cacheForSmall(area, normCapacity);
+    case Tiny:
+        return cacheForTiny(area, normCapacity);
+    default:
+        throw new Error();
+    }
+}
+```
+
+## 2.5 add
+
+`#add(PoolArena<?> area, PoolChunk chunk, long handle, int normCapacity, SizeClass sizeClass)` 方法，添加内存块到 PoolThreadCache 的指定 MemoryRegionCache 的队列中，进行缓存。并且，返回是否添加成功。代码如下：
+
+```
+/**
+ * Add {@link PoolChunk} and {@code handle} to the cache if there is enough room.
+ * Returns {@code true} if it fit into the cache {@code false} otherwise.
+ */
+@SuppressWarnings({ "unchecked", "rawtypes" })
+boolean add(PoolArena<?> area, PoolChunk chunk, long handle, int normCapacity, SizeClass sizeClass) {
+    // 获得对应的 MemoryRegionCache 对象
+    MemoryRegionCache<?> cache = cache(area, normCapacity, sizeClass);
+    if (cache == null) {
+        return false;
+    }
+    // 添加到 MemoryRegionCache 内存块中
+    return cache.add(chunk, handle);
+}
+```
+
+- 代码比较简单，胖友自己看注释。
+- 在 `PoolArea#free(PoolChunk<T> chunk, long handle, int normCapacity, PoolThreadCache cache)` 中，调用该方法。所以，可以结合 [《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（五）PoolArena》](http://svip.iocoder.cn/Netty/ByteBuf-3-5-Jemalloc-Arena) 的 [「2.6 free」](https://svip.iocoder.cn/Netty/ByteBuf-3-6-Jemalloc-ThreadCache/#) 一起看看罗。
+
+## 2.6 allocate
+
+```
+/**
+ * Try to allocate a tiny buffer out of the cache. Returns {@code true} if successful {@code false} otherwise
+ */
+boolean allocateTiny(PoolArena<?> area, PooledByteBuf<?> buf, int reqCapacity, int normCapacity) {
+    return allocate(cacheForTiny(area, normCapacity), buf, reqCapacity);
+}
+
+/**
+ * Try to allocate a small buffer out of the cache. Returns {@code true} if successful {@code false} otherwise
+ */
+boolean allocateSmall(PoolArena<?> area, PooledByteBuf<?> buf, int reqCapacity, int normCapacity) {
+    return allocate(cacheForSmall(area, normCapacity), buf, reqCapacity);
+}
+
+/**
+ * Try to allocate a small buffer out of the cache. Returns {@code true} if successful {@code false} otherwise
+ */
+boolean allocateNormal(PoolArena<?> area, PooledByteBuf<?> buf, int reqCapacity, int normCapacity) {
+    return allocate(cacheForNormal(area, normCapacity), buf, reqCapacity);
+}
+```
+
+- 三个方法，从缓存中分别获取不同容量大小的内存块，初始化到 PooledByteBuf 对象中。通过调用 `#allocate(MemoryRegionCache<?> cache, PooledByteBuf buf, int reqCapacity)` 方法，代码如下：
+
+  ```
+   1: private boolean allocate(MemoryRegionCache<?> cache, PooledByteBuf buf, int reqCapacity) {
+   2:     if (cache == null) {
+   3:         // no cache found so just return false here
+   4:         return false;
+   5:     }
+   6:     // 分配内存块，并初始化到 MemoryRegionCache 中
+   7:     boolean allocated = cache.allocate(buf, reqCapacity);
+   8:     // 到达阀值，整理缓存
+   9:     if (++ allocations >= freeSweepAllocationThreshold) {
+  10:         allocations = 0;
+  11:         trim();
+  12:     }
+  13:     // 返回是否分配成功
+  14:     return allocated;
+  15: }
+  ```
+
+  - 第 7 行：调用 `MemoryRegionCache#allocate(buf, reqCapacity)` 方法，从缓存中分配内存块，并初始化到 MemoryRegionCache 中。
+  - 第 8 至 12 行：增加 `allocations` 计数。若到达阀值( `freeSweepAllocationThreshold` )，重置计数，并调用 `#trim()` 方法，整理缓存。详细解析，见 [「2.7 trim」](https://svip.iocoder.cn/Netty/ByteBuf-3-6-Jemalloc-ThreadCache/#) 。
+  - 第 14 行：返回是否分配成功。如果从缓存中分配失败，后续就从 PoolArena 中获取内存块。
+
+## 2.7 free
+
+`#trim()` 方法，整理缓存，释放使用**频度**较少的内存块缓存。代码如下：
+
+```
+private static int free(MemoryRegionCache<?> cache) {
+    if (cache == null) {
+        return 0;
+    }
+    return cache.free();
+}
+
+void trim() {
+    trim(tinySubPageDirectCaches);
+    trim(smallSubPageDirectCaches);
+    trim(normalDirectCaches);
+    trim(tinySubPageHeapCaches);
+    trim(smallSubPageHeapCaches);
+    trim(normalHeapCaches);
+}
+
+private static void trim(MemoryRegionCache<?>[] caches) {
+    if (caches == null) {
+        return;
+    }
+    for (MemoryRegionCache<?> c: caches) {
+        trim(c);
+    }
+}
+
+private static void trim(MemoryRegionCache<?> cache) {
+    if (cache == null) {
+        return;
+    }
+    cache.trim();
+}
+```
+
+- 会调用所有 MemoryRegionCache 的 `#trim()` 方法，整理每个内存块缓存。详细解析，见 [「3.6 trim」](https://svip.iocoder.cn/Netty/ByteBuf-3-6-Jemalloc-ThreadCache/#) 。
+
+## 2.8 finalize
+
+`#finalize()` 方法，对象销毁时，清空缓存等等。代码如下：
+
+```
+/// TODO: In the future when we move to Java9+ we should use java.lang.ref.Cleaner.
+@Override
+protected void finalize() throws Throwable {
+    try {
+        // <1> 调用父 finalize
+        super.finalize();
+    } finally {
+        // 清空缓存
+        free();
+    }
+}
+
+/**
+ *  Should be called if the Thread that uses this cache is about to exist to release resources out of the cache
+ */
+void free() {
+    // <2> 清空缓存
+    int numFreed = free(tinySubPageDirectCaches) +
+            free(smallSubPageDirectCaches) +
+            free(normalDirectCaches) +
+            free(tinySubPageHeapCaches) +
+            free(smallSubPageHeapCaches) +
+            free(normalHeapCaches);
+
+    if (numFreed > 0 && logger.isDebugEnabled()) {
+        logger.debug("Freed {} thread-local buffer(s) from thread: {}", numFreed, Thread.currentThread().getName());
+    }
+
+    // <3.1> 减小 directArena 的线程引用计数
+    if (directArena != null) {
+        directArena.numThreadCaches.getAndDecrement();
+    }
+
+    // <3.2> 减小 heapArena 的线程引用计数
+    if (heapArena != null) {
+        heapArena.numThreadCaches.getAndDecrement();
+    }
+}
+
+private static int free(MemoryRegionCache<?>[] caches) {
+    if (caches == null) {
+        return 0;
+    }
+
+    int numFreed = 0;
+    for (MemoryRegionCache<?> c: caches) {
+        numFreed += free(c);
+    }
+    return numFreed;
+}
+```
+
+- 代码比较简单，胖友自己看。主要是 `<1>`、`<2>`、`<3.1>/<3.2>` 三个点。
+
+# 3. MemoryRegionCache
+
+MemoryRegionCache ，是 PoolThreadCache 的内部静态类，**内存块缓存**。在其内部，有一个**队列**，存储缓存的内存块。如下图所示：[![MemoryRegionCache](47-Netty 源码解析-Buffer 之 Jemalloc（六）PoolThreadCache.assets/02.png)](http://static.iocoder.cn/images/Netty/2018_09_16/02.png)MemoryRegionCache
+
+## 3.1 构造方法
+
+```
+private abstract static class MemoryRegionCache<T> {
+
+    /**
+     * {@link #queue} 队列大小
+     */
+    private final int size;
+    /**
+     * 队列。里面存储内存块
+     */
+    private final Queue<Entry<T>> queue;
+    /**
+     * 内存类型
+     */
+    private final SizeClass sizeClass;
+    /**
+     * 分配次数计数器
+     */
+    private int allocations;
+
+    MemoryRegionCache(int size, SizeClass sizeClass) {
+        this.size = MathUtil.safeFindNextPositivePowerOfTwo(size);
+        queue = PlatformDependent.newFixedMpscQueue(this.size); // <1> MPSC
+        this.sizeClass = sizeClass;
+    }
+    
+    // ... 省略其它方法
+}
+```
+
+- `sizeClass` 属性，内存类型。
+
+- `queue` 属性，队列，里面存储内存块。每个元素为 Entry 对象，对应一个内存块。代码如下：
+
+  ```
+  static final class Entry<T> {
+  
+      /**
+       * Recycler 处理器，用于回收 Entry 对象
+       */
+      final Handle<Entry<?>> recyclerHandle;
+      /**
+       * PoolChunk 对象
+       */
+      PoolChunk<T> chunk;
+      /**
+       * 内存块在 {@link #chunk} 的位置
+       */
+      long handle = -1;
+  
+      Entry(Handle<Entry<?>> recyclerHandle) {
+          this.recyclerHandle = recyclerHandle;
+      }
+  
+      void recycle() {
+          // 置空
+          chunk = null;
+          handle = -1;
+          // 回收 Entry 对象
+          recyclerHandle.recycle(this);
+      }
+  }
+  ```
+
+  - 通过 `chunk` 和 `handle` 属性，可以唯一确认一个内存块。
+  - `recyclerHandle` 属性，用于回收 Entry 对象，用于 `#recycle()` 方法中。
+
+- `size` 属性，队列大小。
+
+- `allocations` 属性，分配次数计数器。
+
+- 在
+
+   
+
+  ```
+  <1>
+  ```
+
+   
+
+  处理，我们可以看到创建的
+
+   
+
+  ```
+  queue
+  ```
+
+   
+
+  属性，类型为 MPSC( Multiple Producer Single Consumer ) 队列，即
+
+  多个
+
+  生产者
+
+  单一
+
+  消费者。为什么使用 MPSC 队列呢?
+
+  - 多个生产者，指的是多个线程，移除( 释放 )内存块出队列。
+  - 单个消费者，指的是单个线程，添加( 缓存 )内存块到队列。
+
+## 3.2 newEntry
+
+`#newEntry(PoolChunk<?> chunk, long handle)` 方法，创建 Entry 对象。代码如下：
+
+```
+@SuppressWarnings("rawtypes")
+private static Entry newEntry(PoolChunk<?> chunk, long handle) {
+    // 从 Recycler 对象中，获得 Entry 对象
+    Entry entry = RECYCLER.get();
+    // 初始化属性
+    entry.chunk = chunk;
+    entry.handle = handle;
+    return entry;
+}
+
+@SuppressWarnings("rawtypes")
+private static final Recycler<Entry> RECYCLER = new Recycler<Entry>() {
+
+    @SuppressWarnings("unchecked")
+    @Override
+    protected Entry newObject(Handle<Entry> handle) {
+        return new Entry(handle); // 创建 Entry 对象
+    }
+
+};
+```
+
+## 3.3 add
+
+`#add(PoolChunk<T> chunk, long handle)` 方法，添加( 缓存 )内存块到队列，并返回是否添加成功。代码如下：
+
+```
+/**
+ * Add to cache if not already full.
+ */
+@SuppressWarnings("unchecked")
+public final boolean add(PoolChunk<T> chunk, long handle) {
+    // 创建 Entry 对象
+    Entry<T> entry = newEntry(chunk, handle);
+    // 添加到队列
+    boolean queued = queue.offer(entry);
+    // 若添加失败，说明队列已满，回收 Entry 对象
+    if (!queued) {
+        // If it was not possible to cache the chunk, immediately recycle the entry
+        entry.recycle();
+    }
+
+    return queued; // 是否添加成功
+}
+```
+
+## 3.4 allocate
+
+`#allocate(PooledByteBuf<T> buf, int reqCapacity)` 方法，从队列中获取缓存的内存块，初始化到 PooledByteBuf 对象中，并返回是否分配成功。代码如下：
+
+```
+/**
+ * Allocate something out of the cache if possible and remove the entry from the cache.
+ */
+public final boolean allocate(PooledByteBuf<T> buf, int reqCapacity) {
+    // 获取并移除队列首个 Entry 对象
+    Entry<T> entry = queue.poll();
+    // 获取失败，返回 false
+    if (entry == null) {
+        return false;
+    }
+    // <1> 初始化内存块到 PooledByteBuf 对象中 
+    initBuf(entry.chunk, entry.handle, buf, reqCapacity);
+    // 回收 Entry 对象
+    entry.recycle();
+
+    // 增加 allocations 计数。因为分配总是在相同线程，所以不需要考虑线程安全的问题
+    // allocations is not thread-safe which is fine as this is only called from the same thread all time.
+    ++ allocations;
+    return true; // 返回 true ，分配成功
+}
+```
+
+- 代码比较简单，胖友自己看注释。
+
+- 在 `<1>` 处，调用 `#initBuf(PoolChunk<T> chunk, long handle, PooledByteBuf<T> buf, int reqCapacity)` **抽象**方法，初始化内存块到 PooledByteBuf 对象中。代码如下：
+
+  ```
+  /**
+   * Init the {@link PooledByteBuf} using the provided chunk and handle with the capacity restrictions.
+   */
+  protected abstract void initBuf(PoolChunk<T> chunk, long handle, PooledByteBuf<T> buf, int reqCapacity);
+  ```
+
+  - 该**抽象**方法需要子类 SubPageMemoryRegionCache 和 NormalMemoryRegionCache 来实现。并且，这也是 MemoryRegionCache 的**唯一**的抽象方法。
+
+## 3.5 free
+
+`#free(...)` 方法，清除队列。代码如下：
+
+```
+/**
+ * 清除队列中的全部
+ *
+ * Clear out this cache and free up all previous cached {@link PoolChunk}s and {@code handle}s.
+ */
+public final int free() {
+    return free(Integer.MAX_VALUE);
+}
+
+// 清除队列中的指定数量元素
+private int free(int max) {
+    int numFreed = 0;
+    for (; numFreed < max; numFreed++) {
+        // 获取并移除首元素
+        Entry<T> entry = queue.poll();
+        if (entry != null) {
+            // 释放缓存的内存块回 Chunk 中
+            freeEntry(entry); <1>
+        } else {
+            // all cleared
+            return numFreed;
+        }
+    }
+    return numFreed;
+}
+```
+
+- 代码比较简单，胖友自己看注释。
+
+- `<1>` 处， 释放缓存的内存块回 Chunk 中。代码如下：
+
+  ```
+  private  void freeEntry(Entry entry) {
+      PoolChunk chunk = entry.chunk;
+      long handle = entry.handle;
+  
+      // 回收 Entry 对象
+      // recycle now so PoolChunk can be GC'ed.
+      entry.recycle();
+  
+      // 释放缓存的内存块回 Chunk 中
+      chunk.arena.freeChunk(chunk, handle, sizeClass);
+  }
+  ```
+
+## 3.6 trim
+
+这块当时没太看懂，后来读了 [《自顶向下深入分析Netty（十）–PoolThreadCache》](https://www.jianshu.com/p/9177b7dabd37) 文章后，看懂了 `#trim()` 方法。引用如下：
+
+> 在分配过程还有一个`trim()`方法，当分配操作达到一定阈值（Netty默认8192）时，没有被分配出去的缓存空间都要被释放，以防止内存泄漏，核心代码如下：
+
+```
+// 内部类MemoryRegionCache
+public final void trim() {
+    // allocations 表示已经重新分配出去的ByteBuf个数
+    int free = size - allocations;  
+    allocations = 0;
+
+    // 在一定阈值内还没被分配出去的空间将被释放
+    if (free > 0) {
+        free(free); // 释放队列中的节点
+    }
+}
+```
+
+> 也就是说，期望一个 MemoryRegionCache **频繁**进行回收-分配，这样 `allocations` > `size` ，将不会释放队列中的任何一个节点表示的内存空间；
+>
+> 但如果长时间没有分配，则应该释放这一部分空间，防止内存占据过多。Tiny请求缓存512 个节点，由此可知当使用率超过 `512 / 8192 = 6.25%` 时就不会释放节点。
+
+## 3.X1 SubPageMemoryRegionCache
+
+SubPageMemoryRegionCache ，是 PoolThreadCache 的内部静态类，继承 MemoryRegionCache 抽象类，**Subpage** MemoryRegionCache 实现类。代码如下：
+
+```
+/**
+ * Cache used for buffers which are backed by TINY or SMALL size.
+ */
+private static final class SubPageMemoryRegionCache<T> extends MemoryRegionCache<T> {
+
+    SubPageMemoryRegionCache(int size, SizeClass sizeClass) {
+        super(size, sizeClass);
+    }
+
+    @Override
+    protected void initBuf(PoolChunk<T> chunk, long handle, PooledByteBuf<T> buf, int reqCapacity) {
+        // 初始化 Subpage 内存块到 PooledByteBuf 对象中
+        chunk.initBufWithSubpage(buf, handle, reqCapacity);
+    }
+
+}
+```
+
+## 3.X2 NormalMemoryRegionCache
+
+NormalMemoryRegionCache ，是 PoolThreadCache 的内部静态类，继承 MemoryRegionCache 抽象类，**Page** MemoryRegionCache 实现类。代码如下：
+
+```
+/**
+ * Cache used for buffers which are backed by NORMAL size.
+ */
+private static final class NormalMemoryRegionCache<T> extends MemoryRegionCache<T> {
+
+    NormalMemoryRegionCache(int size) {
+        super(size, SizeClass.Normal);
+    }
+
+    @Override
+    protected void initBuf(PoolChunk<T> chunk, long handle, PooledByteBuf<T> buf, int reqCapacity) {
+        // 初始化 Page 内存块到 PooledByteBuf 对象中
+        chunk.initBuf(buf, handle, reqCapacity);
+    }
+
+}
+```
+
+# 666. 彩蛋
+
+嘿嘿，比想象中简单蛮多的一篇文章。
+
+推荐阅读文章：
+
+- Hypercube [《自顶向下深入分析Netty（十）–PoolThreadCache》](https://www.jianshu.com/p/9177b7dabd37)
\ No newline at end of file
diff --git a/netty/48-Netty 源码解析-ChannelHandler（一）之简介.assets/01.png b/netty/48-Netty 源码解析-ChannelHandler（一）之简介.assets/01.png
new file mode 100644
index 0000000..fb73a59
Binary files /dev/null and b/netty/48-Netty 源码解析-ChannelHandler（一）之简介.assets/01.png differ
diff --git a/netty/48-Netty 源码解析-ChannelHandler（一）之简介.md b/netty/48-Netty 源码解析-ChannelHandler（一）之简介.md
new file mode 100644
index 0000000..697b25a
--- /dev/null
+++ b/netty/48-Netty 源码解析-ChannelHandler（一）之简介.md	
@@ -0,0 +1,506 @@
+# 精尽 Netty 源码解析 —— ChannelHandler（一）之简介
+
+# 1. 概述
+
+在 [《精尽 Netty 源码分析 —— Netty 简介（二）之核心组件》](http://svip.iocoder.cn/Netty/intro-2/?self) 中，对 ChannelHandler 做了定义，我们再来回顾下：
+
+> ChannelHandler ，连接通道处理器，我们使用 Netty 中**最常用**的组件。ChannelHandler 主要用来处理各种事件，这里的事件很广泛，比如可以是连接、数据接收、异常、数据转换等。
+
+实际上，我们已经在前面的文章看了一遍又一遍 ChannelHandler 的身影，已经是熟悉的老朋友了。当然，我们还是会在这个**专属**于 ChannelHandler 章节里，再更加深入的认识 ChannelHandler 。
+
+`io.netty.channel.ChannelHandler` ，Channel 处理器接口。代码如下：
+
+```
+public interface ChannelHandler {
+
+    /**
+     * Gets called after the {@link ChannelHandler} was added to the actual context and it's ready to handle events.
+     *
+     * ChannelHandler 已经成功被添加到 ChannelPipeline 中，可以进行处理事件。
+     *
+     * 该方法，一般用于 ChannelHandler 的初始化的逻辑
+     */
+    void handlerAdded(ChannelHandlerContext ctx) throws Exception;
+
+    /**
+     * Gets called after the {@link ChannelHandler} was removed from the actual context and it doesn't handle events
+     * anymore.
+     *
+     * ChannelHandler 已经成功从 ChannelPipeline 中被移除，不再进行处理事件。
+     *
+     * 该方法，一般用于 ChannelHandler 的销毁的逻辑
+     */
+    void handlerRemoved(ChannelHandlerContext ctx) throws Exception;
+
+    /**
+     * Gets called if a {@link Throwable} was thrown.
+     *
+     * 抓取到异常。目前被废弃，移到 ChannelInboundHandler 接口中，作为对 Exception Inbound 事件的处理
+     *
+     * @deprecated is part of {@link ChannelInboundHandler}
+     */
+    @Deprecated
+    void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception;
+
+    /**
+     * Indicates that the same instance of the annotated {@link ChannelHandler}
+     * can be added to one or more {@link ChannelPipeline}s multiple times
+     * without a race condition.
+     * <p>
+     * If this annotation is not specified, you have to create a new handler
+     * instance every time you add it to a pipeline because it has unshared
+     * state such as member variables.
+     * <p>
+     * This annotation is provided for documentation purpose, just like
+     * <a href="http://www.javaconcurrencyinpractice.com/annotations/doc/">the JCIP annotations</a>.
+     */
+    @Inherited
+    @Documented
+    @Target(ElementType.TYPE)
+    @Retention(RetentionPolicy.RUNTIME)
+    @interface Sharable {
+        // no value
+    }
+
+}
+```
+
+- 关于 `#handlerAdded(...)`、`#handlerRemoved(...)`、`#exceptionCaught(...)` 方法，胖友看方法上的注释。
+- `@Sharable` 注解，ChannelHandler 是否可共享，即是否可以被**多次**添加。在 [《精尽 Netty 源码解析 —— ChannelPipeline（二）之添加 ChannelHandler》](http://svip.iocoder.cn/Netty/Pipeline-2-add-channel-handler?self) 的 [「3. checkMultiplicity」](https://svip.iocoder.cn/Netty/ChannelHandler-1-intro/#) 小节，已经有详细解析。
+
+# 2. 核心类
+
+ChannelHandler 的**核心类**的类图如下图：
+
+[![核心类图](48-Netty 源码解析-ChannelHandler（一）之简介.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_10_01/01.png)核心类图
+
+- ChannelInboundHandler ，在 [《精尽 Netty 源码解析 —— ChannelPipeline（五）之 Inbound 事件的传播》](http://svip.iocoder.cn/Netty/Pipeline-5-inbound) 有详细解析。
+
+- ChannelOutboundHandler ，在 [《精尽 Netty 源码解析 —— ChannelPipeline（六）之 Outbound 事件的传播》](http://svip.iocoder.cn/Netty/Pipeline-6-outbound) 有详细解析。
+
+- **红框**部分，ChannelHandler Adaptive 实现类，提供默认的骨架( Skeleton )实现。
+
+- **绿框**部分，用于编解码消息的 ChannelHandler 实现类。关于这部分，我们会在 《Codec》专属的章节，而不是在《ChannelHandler》章节。
+
+- 黄框
+
+  部分
+
+  - SimpleChannelInboundHandler ，抽象类，处理**指定类型**的消息。应用程序中，我们可以实现 SimpleChannelInboundHandler 后，实现对**指定类型**的消息的自定义处理。
+  - Simple**UserEvent**ChannelHandler ，和 SimpleChannelInboundHandler 基本一致，差别在于将指定类型的消息，改成了制定类型的事件。
+  - 详细解析，见 [《精尽 Netty 源码解析 —— ChannelHandler（三）之 SimpleChannelInboundHandler》](http://svip.iocoder.cn/Netty/ChannelHandler-3-SimpleChannelInboundHandler) 。
+
+- ChannelInitializer ，一个**特殊**的 ChannelHandler ，用于 Channel 注册到 EventLoop 后，**执行自定义的初始化操作**。一般情况下，初始化自定义的 ChannelHandler 到 Channel 中。详细解析，见 [《精尽 Netty 源码解析 —— ChannelHandler（二）之 ChannelInitializer》](http://svip.iocoder.cn/Netty/ChannelHandler-2-ChannelInitializer) 。
+
+# 3. ChannelHandlerAdaptive
+
+在看看 ChannelHandlerAdaptive 的具体代码实现之前，我们先一起了解 ChannelHandlerAdaptive 的设计思想。在《Netty 权威指南》如是说：
+
+> 对于大多数的 ChannelHandler 会选择性地拦截和处理某个或者某些事件，其他的事件会忽略，由下一个 ChannelHandler 进行拦截和处理。这就会导致一个问题：用户 ChannelHandler 必须要实现 ChannelHandler 的所有接口，包括它不关心的那些事件处理接口，这会导致用户代码的冗余和臃肿，代码的可维护性也会变差。
+>
+> 为了解决这个问题，Netty提供了ChannelHandlerAdapter基类，它的所有接口实现都是事件透传，如果用户ChannelHandler关心某个事件，只需要覆盖ChannelHandlerAdapter对应的方法即可，对于不关心的，可以直接继承使用父类的方法，这样子类的代码就会非常简洁和清晰。
+
+😈 下面，我们看到的其它 Adaptive 实现类，也是这样的设计思想。
+
+------
+
+`io.netty.channel.ChannelHandlerAdapter` ，实现 ChannelHandler 接口，ChannelHandler Adapter 抽象类。
+
+## 3.1 isSharable
+
+```
+// Not using volatile because it's used only for a sanity check.
+/**
+ * 是否已经初始化
+ */
+boolean added;
+
+/**
+ * Throws {@link IllegalStateException} if {@link ChannelHandlerAdapter#isSharable()} returns {@code true}
+ */
+protected void ensureNotSharable() {
+    if (isSharable()) {
+        throw new IllegalStateException("ChannelHandler " + getClass().getName() + " is not allowed to be shared");
+    }
+}
+
+/**
+ * Return {@code true} if the implementation is {@link Sharable} and so can be added
+ * to different {@link ChannelPipeline}s.
+ */
+public boolean isSharable() {
+    /**
+     * Cache the result of {@link Sharable} annotation detection to workaround a condition. We use a
+     * {@link ThreadLocal} and {@link WeakHashMap} to eliminate the volatile write/reads. Using different
+     * {@link WeakHashMap} instances per {@link Thread} is good enough for us and the number of
+     * {@link Thread}s are quite limited anyway.
+     *
+     * See <a href="https://github.com/netty/netty/issues/2289">#2289</a>.
+     */
+    Class<?> clazz = getClass();
+    Map<Class<?>, Boolean> cache = InternalThreadLocalMap.get().handlerSharableCache();
+    Boolean sharable = cache.get(clazz);
+    if (sharable == null) {
+        sharable = clazz.isAnnotationPresent(Sharable.class);
+        cache.put(clazz, sharable);
+    }
+    return sharable;
+}
+```
+
+- 这块内容，和 `@Sharable` 注解相关。在 [《精尽 Netty 源码解析 —— ChannelPipeline（二）之添加 ChannelHandler》](http://svip.iocoder.cn/Netty/Pipeline-2-add-channel-handler?self) 的 [「3. checkMultiplicity」](https://svip.iocoder.cn/Netty/ChannelHandler-1-intro/#) 小节，已经有详细解析。
+
+## 3.2 具体实现
+
+```
+/**
+ * Do nothing by default, sub-classes may override this method.
+ */
+@Override
+public void handlerAdded(ChannelHandlerContext ctx) throws Exception {
+    // NOOP
+}
+
+/**
+ * Do nothing by default, sub-classes may override this method.
+ */
+@Override
+public void handlerRemoved(ChannelHandlerContext ctx) throws Exception {
+    // NOOP
+}
+
+/**
+ * Calls {@link ChannelHandlerContext#fireExceptionCaught(Throwable)} to forward
+ * to the next {@link ChannelHandler} in the {@link ChannelPipeline}.
+ *
+ * Sub-classes may override this method to change behavior.
+ */
+@Override
+public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
+    ctx.fireExceptionCaught(cause);
+}
+```
+
+- 对于 `#handlerAdded(ChannelHandlerContext ctx)` 和 `#handlerRemoved(ChannelHandlerContext ctx)` 方法，默认无任何逻辑。子类如果有自定义的逻辑，可以进行覆写对应的方法。
+- `#exceptionCaught(ChannelHandlerContext ctx, Throwable cause)` 方法，直接转发到下一个节点，**实际上**也是默认无任何逻辑。子类如果有自定义的逻辑，可以进行覆写对应的方法。
+
+# 4. ChannelOutboundHandlerAdapter
+
+`io.netty.channel.ChannelOutboundHandlerAdapter` ，实现 ChannelOutboundHandler 接口，继承 ChannelHandlerAdapter 抽象类，ChannelOutboundHandler Adapter 实现类。代码如下：
+
+```
+public class ChannelOutboundHandlerAdapter extends ChannelHandlerAdapter implements ChannelOutboundHandler {
+
+    /**
+     * Calls {@link ChannelHandlerContext#bind(SocketAddress, ChannelPromise)} to forward
+     * to the next {@link ChannelOutboundHandler} in the {@link ChannelPipeline}.
+     *
+     * Sub-classes may override this method to change behavior.
+     */
+    @Override
+    public void bind(ChannelHandlerContext ctx, SocketAddress localAddress, ChannelPromise promise) throws Exception {
+        ctx.bind(localAddress, promise);
+    }
+
+    /**
+     * Calls {@link ChannelHandlerContext#connect(SocketAddress, SocketAddress, ChannelPromise)} to forward
+     * to the next {@link ChannelOutboundHandler} in the {@link ChannelPipeline}.
+     *
+     * Sub-classes may override this method to change behavior.
+     */
+    @Override
+    public void connect(ChannelHandlerContext ctx, SocketAddress remoteAddress, SocketAddress localAddress, ChannelPromise promise) throws Exception {
+        ctx.connect(remoteAddress, localAddress, promise);
+    }
+
+    /**
+     * Calls {@link ChannelHandlerContext#disconnect(ChannelPromise)} to forward
+     * to the next {@link ChannelOutboundHandler} in the {@link ChannelPipeline}.
+     *
+     * Sub-classes may override this method to change behavior.
+     */
+    @Override
+    public void disconnect(ChannelHandlerContext ctx, ChannelPromise promise) throws Exception {
+        ctx.disconnect(promise);
+    }
+
+    /**
+     * Calls {@link ChannelHandlerContext#close(ChannelPromise)} to forward
+     * to the next {@link ChannelOutboundHandler} in the {@link ChannelPipeline}.
+     *
+     * Sub-classes may override this method to change behavior.
+     */
+    @Override
+    public void close(ChannelHandlerContext ctx, ChannelPromise promise) throws Exception {
+        ctx.close(promise);
+    }
+
+    /**
+     * Calls {@link ChannelHandlerContext#deregister(ChannelPromise)} to forward
+     * to the next {@link ChannelOutboundHandler} in the {@link ChannelPipeline}.
+     *
+     * Sub-classes may override this method to change behavior.
+     */
+    @Override
+    public void deregister(ChannelHandlerContext ctx, ChannelPromise promise) throws Exception {
+        ctx.deregister(promise);
+    }
+
+    /**
+     * Calls {@link ChannelHandlerContext#read()} to forward
+     * to the next {@link ChannelOutboundHandler} in the {@link ChannelPipeline}.
+     *
+     * Sub-classes may override this method to change behavior.
+     */
+    @Override
+    public void read(ChannelHandlerContext ctx) throws Exception {
+        ctx.read();
+    }
+
+    /**
+     * Calls {@link ChannelHandlerContext#write(Object, ChannelPromise)} to forward
+     * to the next {@link ChannelOutboundHandler} in the {@link ChannelPipeline}.
+     *
+     * Sub-classes may override this method to change behavior.
+     */
+    @Override
+    public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) throws Exception {
+        ctx.write(msg, promise);
+    }
+
+    /**
+     * Calls {@link ChannelHandlerContext#flush()} to forward
+     * to the next {@link ChannelOutboundHandler} in the {@link ChannelPipeline}.
+     *
+     * Sub-classes may override this method to change behavior.
+     */
+    @Override
+    public void flush(ChannelHandlerContext ctx) throws Exception {
+        ctx.flush();
+    }
+
+}
+```
+
+- 每个实现方法，直接转发到下一个节点，**实际上**也是默认无任何逻辑。子类如果有自定义的逻辑，可以进行覆写对应的方法。
+
+# 5. ChannelInboundHandlerAdapter
+
+`io.netty.channel.ChannelInboundHandlerAdapter` ，实现 ChannelInboundHandler 接口，继承 ChannelHandlerAdapter 抽象类，ChannelInboundHandler Adapter 实现类。代码如下：
+
+```
+public class ChannelInboundHandlerAdapter extends ChannelHandlerAdapter implements ChannelInboundHandler {
+
+    /**
+     * Calls {@link ChannelHandlerContext#fireChannelRegistered()} to forward
+     * to the next {@link ChannelInboundHandler} in the {@link ChannelPipeline}.
+     *
+     * Sub-classes may override this method to change behavior.
+     */
+    @Override
+    public void channelRegistered(ChannelHandlerContext ctx) throws Exception {
+        ctx.fireChannelRegistered();
+    }
+
+    /**
+     * Calls {@link ChannelHandlerContext#fireChannelUnregistered()} to forward
+     * to the next {@link ChannelInboundHandler} in the {@link ChannelPipeline}.
+     *
+     * Sub-classes may override this method to change behavior.
+     */
+    @Override
+    public void channelUnregistered(ChannelHandlerContext ctx) throws Exception {
+        ctx.fireChannelUnregistered();
+    }
+
+    /**
+     * Calls {@link ChannelHandlerContext#fireChannelActive()} to forward
+     * to the next {@link ChannelInboundHandler} in the {@link ChannelPipeline}.
+     *
+     * Sub-classes may override this method to change behavior.
+     */
+    @Override
+    public void channelActive(ChannelHandlerContext ctx) throws Exception {
+        ctx.fireChannelActive();
+    }
+
+    /**
+     * Calls {@link ChannelHandlerContext#fireChannelInactive()} to forward
+     * to the next {@link ChannelInboundHandler} in the {@link ChannelPipeline}.
+     *
+     * Sub-classes may override this method to change behavior.
+     */
+    @Override
+    public void channelInactive(ChannelHandlerContext ctx) throws Exception {
+        ctx.fireChannelInactive();
+    }
+
+    /**
+     * Calls {@link ChannelHandlerContext#fireChannelRead(Object)} to forward
+     * to the next {@link ChannelInboundHandler} in the {@link ChannelPipeline}.
+     *
+     * Sub-classes may override this method to change behavior.
+     */
+    @Override
+    public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
+        ctx.fireChannelRead(msg);
+    }
+
+    /**
+     * Calls {@link ChannelHandlerContext#fireChannelReadComplete()} to forward
+     * to the next {@link ChannelInboundHandler} in the {@link ChannelPipeline}.
+     *
+     * Sub-classes may override this method to change behavior.
+     */
+    @Override
+    public void channelReadComplete(ChannelHandlerContext ctx) throws Exception {
+        ctx.fireChannelReadComplete();
+    }
+
+    /**
+     * Calls {@link ChannelHandlerContext#fireUserEventTriggered(Object)} to forward
+     * to the next {@link ChannelInboundHandler} in the {@link ChannelPipeline}.
+     *
+     * Sub-classes may override this method to change behavior.
+     */
+    @Override
+    public void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws Exception {
+        ctx.fireUserEventTriggered(evt);
+    }
+
+    /**
+     * Calls {@link ChannelHandlerContext#fireChannelWritabilityChanged()} to forward
+     * to the next {@link ChannelInboundHandler} in the {@link ChannelPipeline}.
+     *
+     * Sub-classes may override this method to change behavior.
+     */
+    @Override
+    public void channelWritabilityChanged(ChannelHandlerContext ctx) throws Exception {
+        ctx.fireChannelWritabilityChanged();
+    }
+
+    /**
+     * Calls {@link ChannelHandlerContext#fireExceptionCaught(Throwable)} to forward
+     * to the next {@link ChannelHandler} in the {@link ChannelPipeline}.
+     *
+     * Sub-classes may override this method to change behavior.
+     */
+    @Override
+    public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
+        ctx.fireExceptionCaught(cause);
+    }
+    
+}
+```
+
+- 每个实现方法，直接转发到下一个节点，**实际上**也是默认无任何逻辑。子类如果有自定义的逻辑，可以进行覆写对应的方法。
+
+# 6. ChannelDuplexHandler
+
+`io.netty.channel.ChannelDuplexHandler` ，实现 ChannelOutboundHandler 接口，继承 ChannelInboundHandlerAdapter 抽象类，Channel Duplex Handler 实现类，支持对 Inbound 和 Outbound 事件的 Adaptive 处理，所以命名上带有“**Duplex**”( 双重 )。代码如下：
+
+```
+public class ChannelDuplexHandler extends ChannelInboundHandlerAdapter implements ChannelOutboundHandler {
+
+    /**
+     * Calls {@link ChannelHandlerContext#bind(SocketAddress, ChannelPromise)} to forward
+     * to the next {@link ChannelOutboundHandler} in the {@link ChannelPipeline}.
+     *
+     * Sub-classes may override this method to change behavior.
+     */
+    @Override
+    public void bind(ChannelHandlerContext ctx, SocketAddress localAddress, ChannelPromise promise) throws Exception {
+        ctx.bind(localAddress, promise);
+    }
+
+    /**
+     * Calls {@link ChannelHandlerContext#connect(SocketAddress, SocketAddress, ChannelPromise)} to forward
+     * to the next {@link ChannelOutboundHandler} in the {@link ChannelPipeline}.
+     *
+     * Sub-classes may override this method to change behavior.
+     */
+    @Override
+    public void connect(ChannelHandlerContext ctx, SocketAddress remoteAddress, SocketAddress localAddress, ChannelPromise promise) throws Exception {
+        ctx.connect(remoteAddress, localAddress, promise);
+    }
+
+    /**
+     * Calls {@link ChannelHandlerContext#disconnect(ChannelPromise)} to forward
+     * to the next {@link ChannelOutboundHandler} in the {@link ChannelPipeline}.
+     *
+     * Sub-classes may override this method to change behavior.
+     */
+    @Override
+    public void disconnect(ChannelHandlerContext ctx, ChannelPromise promise) throws Exception {
+        ctx.disconnect(promise);
+    }
+
+    /**
+     * Calls {@link ChannelHandlerContext#close(ChannelPromise)} to forward
+     * to the next {@link ChannelOutboundHandler} in the {@link ChannelPipeline}.
+     *
+     * Sub-classes may override this method to change behavior.
+     */
+    @Override
+    public void close(ChannelHandlerContext ctx, ChannelPromise promise) throws Exception {
+        ctx.close(promise);
+    }
+
+    /**
+     * Calls {@link ChannelHandlerContext#close(ChannelPromise)} to forward
+     * to the next {@link ChannelOutboundHandler} in the {@link ChannelPipeline}.
+     *
+     * Sub-classes may override this method to change behavior.
+     */
+    @Override
+    public void deregister(ChannelHandlerContext ctx, ChannelPromise promise) throws Exception {
+        ctx.deregister(promise);
+    }
+
+    /**
+     * Calls {@link ChannelHandlerContext#read()} to forward
+     * to the next {@link ChannelOutboundHandler} in the {@link ChannelPipeline}.
+     *
+     * Sub-classes may override this method to change behavior.
+     */
+    @Override
+    public void read(ChannelHandlerContext ctx) throws Exception {
+        ctx.read();
+    }
+
+    /**
+     * Calls {@link ChannelHandlerContext#write(Object, ChannelPromise)} to forward
+     * to the next {@link ChannelOutboundHandler} in the {@link ChannelPipeline}.
+     *
+     * Sub-classes may override this method to change behavior.
+     */
+    @Override
+    public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) throws Exception {
+        ctx.write(msg, promise);
+    }
+
+    /**
+     * Calls {@link ChannelHandlerContext#flush()} to forward
+     * to the next {@link ChannelOutboundHandler} in the {@link ChannelPipeline}.
+     *
+     * Sub-classes may override this method to change behavior.
+     */
+    @Override
+    public void flush(ChannelHandlerContext ctx) throws Exception {
+        ctx.flush();
+    }
+
+}
+```
+
+- 实现代码上，和 [「4. ChannelOutboundHandlerAdapter」](https://svip.iocoder.cn/Netty/ChannelHandler-1-intro/#) 是一致的。因为 Java 不支持**多继承**的特性，所以不得又重新实现一遍。
+
+😈 大多数情况下，我们会实现 ChannelDuplexHandler 类，覆写部分方法，处理对应的事件。
+
+# 666. 彩蛋
+
+小小水文一篇，主要帮胖友梳理下，对 ChannelHandler 有整体的认识。在后续的文章中，我们会看具体的一个一个 ChannelHandler 的带有“业务”的实现类。
+
+推荐阅读如下文章：
+
+- Hypercube [《自顶向下深入分析Netty（八）–ChannelHandler》](https://www.jianshu.com/p/a9bcd89553f5)
\ No newline at end of file
diff --git a/netty/49-Netty 源码解析-ChannelHandler（二）之 ChannelInitializer.assets/02.png b/netty/49-Netty 源码解析-ChannelHandler（二）之 ChannelInitializer.assets/02.png
new file mode 100644
index 0000000..0e28502
Binary files /dev/null and b/netty/49-Netty 源码解析-ChannelHandler（二）之 ChannelInitializer.assets/02.png differ
diff --git a/netty/49-Netty 源码解析-ChannelHandler（二）之 ChannelInitializer.md b/netty/49-Netty 源码解析-ChannelHandler（二）之 ChannelInitializer.md
new file mode 100644
index 0000000..c86cc0e
--- /dev/null
+++ b/netty/49-Netty 源码解析-ChannelHandler（二）之 ChannelInitializer.md	
@@ -0,0 +1,205 @@
+# 精尽 Netty 源码解析 —— ChannelHandler（二）之 ChannelInitializer
+
+# 1. 概述
+
+本文，我们来分享 **ChannelInitializer** 。它是一个**特殊**的ChannelInboundHandler 实现类，用于 Channel 注册到 EventLoop 后，**执行自定义的初始化操作**。一般情况下，初始化自定义的 ChannelHandler 到 Channel 中。例如：
+
+- 在 [《精尽 Netty 源码分析 —— 启动（一）之服务端》](http://svip.iocoder.cn/Netty/bootstrap-1-server) 一文中，ServerBootstrap 初始化时，通过 ChannelInitializer 初始化了用于接受( accept )新连接的 ServerBootstrapAcceptor 。
+- 在有新连接接入时，服务端通过 ChannelInitializer 初始化，为客户端的 Channel 添加自定义的 ChannelHandler ，用于处理该 Channel 的读写( read/write ) 事件。
+
+OK，让我们看看具体的代码实现落。
+
+# 2. ChannelInitializer
+
+`io.netty.channel.ChannelInitializer` ，继承 ChannelInboundHandlerAdapter 类，Channel Initializer **抽象类**。代码如下：
+
+```
+@Sharable
+public abstract class ChannelInitializer<C extends Channel> extends ChannelInboundHandlerAdapter {
+```
+
+- 通过 `@Sharable` 注解，支持共享。
+
+## 2.1 initChannel
+
+`#initChannel(ChannelHandlerContext ctx)` 方法，执行行自定义的初始化操作。代码如下：
+
+```
+// We use a ConcurrentMap as a ChannelInitializer is usually shared between all Channels in a Bootstrap /
+// ServerBootstrap. This way we can reduce the memory usage compared to use Attributes.
+/**
+ * 由于 ChannelInitializer 可以在 Bootstrap/ServerBootstrap 的所有通道中共享，所以我们用一个 ConcurrentMap 作为初始化器。
+ * 这种方式，相对于使用 {@link io.netty.util.Attribute} 方式，减少了内存的使用。
+ */
+private final ConcurrentMap<ChannelHandlerContext, Boolean> initMap = PlatformDependent.newConcurrentHashMap();
+
+  1: private boolean initChannel(ChannelHandlerContext ctx) throws Exception {
+  2:     if (initMap.putIfAbsent(ctx, Boolean.TRUE) == null) { // Guard against re-entrance. 解决并发问题
+  3:         try {
+  4:             // 初始化通道
+  5:             initChannel((C) ctx.channel());
+  6:         } catch (Throwable cause) {
+  7:             // 发生异常时，执行异常处理
+  8:             // Explicitly call exceptionCaught(...) as we removed the handler before calling initChannel(...).
+  9:             // We do so to prevent multiple calls to initChannel(...).
+ 10:             exceptionCaught(ctx, cause);
+ 11:         } finally {
+ 12:             // 从 pipeline 移除 ChannelInitializer
+ 13:             remove(ctx);
+ 14:         }
+ 15:         return true; // 初始化成功
+ 16:     }
+ 17:     return false; // 初始化失败
+ 18: }
+```
+
+- 第 2 行：通过 `initMap` 属性，解决并发问题。对应 Netty Git 提交是 https://github.com/netty/netty/commit/26aa34853a8974d212e12b98e708790606bea5fa 。
+
+- 第 5 行：调用 `#initChannel(C ch)` **抽象**方法，执行行自定义的初始化操作。代码如下：
+
+  ```
+  /**
+   * This method will be called once the {@link Channel} was registered. After the method returns this instance
+   * will be removed from the {@link ChannelPipeline} of the {@link Channel}.
+   *
+   * @param ch            the {@link Channel} which was registered.
+   * @throws Exception    is thrown if an error occurs. In that case it will be handled by
+   *                      {@link #exceptionCaught(ChannelHandlerContext, Throwable)} which will by default close
+   *                      the {@link Channel}.
+   */
+  protected abstract void initChannel(C ch) throws Exception;
+  ```
+
+  - 子类继承 ChannelInitializer 抽象类后，实现该方法，自定义 Channel 的初始化逻辑。
+
+- 第 6 至 10 行：调用 `#exceptionCaught(ChannelHandlerContext ctx, Throwable cause)` 方法，发生异常时，执行异常处理。代码如下：
+
+  ```
+  /**
+   * Handle the {@link Throwable} by logging and closing the {@link Channel}. Sub-classes may override this.
+   */
+  @Override
+  public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
+      if (logger.isWarnEnabled()) {
+          logger.warn("Failed to initialize a channel. Closing: " + ctx.channel(), cause);
+      }
+      ctx.close();
+  }
+  ```
+
+  - 打印**告警**日志。
+  - **关闭** Channel 通道。因为，初始化 Channel 通道发生异常，意味着很大可能，无法正常处理该 Channel 后续的读写事件。
+  - 😈 当然，`#exceptionCaught(...)` 方法，并非使用 `final` 修饰。所以也可以在子类覆写该方法。当然，笔者在实际使用并未这么做过。
+
+- 第 11 至 14 行：最终，调用 `#remove(ChannelHandlerContext ctx)` 方法，从 pipeline 移除 ChannelInitializer。代码如下：
+
+  ```
+  private void remove(ChannelHandlerContext ctx) {
+      try {
+          // 从 pipeline 移除 ChannelInitializer
+          ChannelPipeline pipeline = ctx.pipeline();
+          if (pipeline.context(this) != null) {
+              pipeline.remove(this);
+          }
+      } finally {
+          initMap.remove(ctx); // 从 initMap 移除
+      }
+  }
+  ```
+
+  - 从 pipeline 移除 ChannelInitializer 后，避免重新初始化的问题。
+
+- 第 15 行：返回 `true` ，表示**有**执行初始化。
+
+- 第 17 行：返回 `false` ，表示**未**执行初始化。
+
+## 2.2 channelRegistered
+
+在 Channel 注册到 EventLoop 上后，会触发 Channel Registered 事件。那么 `ChannelInitializer` 的 `#channelRegistered(ChannelHandlerContext ctx)` 方法，就会处理该事件。而 ChannelInitializer 对该事件的处理逻辑是，初始化 Channel 。代码如下：
+
+```
+@Override
+@SuppressWarnings("unchecked")
+public final void channelRegistered(ChannelHandlerContext ctx) throws Exception {
+    // Normally this method will never be called as handlerAdded(...) should call initChannel(...) and remove
+    // the handler.
+    // <1> 初始化 Channel
+    if (initChannel(ctx)) {
+        // we called initChannel(...) so we need to call now pipeline.fireChannelRegistered() to ensure we not
+        // miss an event.
+        // <2.1> 重新触发 Channel Registered 事件
+        ctx.pipeline().fireChannelRegistered();
+    } else {
+        // <2.2> 继续向下一个节点的 Channel Registered 事件
+        // Called initChannel(...) before which is the expected behavior, so just forward the event.
+        ctx.fireChannelRegistered();
+    }
+}
+```
+
+- `<1>` 处，调用 `#initChannel(ChannelHandlerContext ctx)` 方法，初始化 Channel 。
+- `<2.1>` 处，若有初始化，**重新触发** Channel Registered 事件。因为，很有可能添加了新的 ChannelHandler 到 pipeline 中。
+- `<2.2>` 处，若无初始化，**继续向下一个节点**的 Channel Registered 事件。
+
+## 2.3 handlerAdded
+
+`ChannelInitializer#handlerAdded(ChannelHandlerContext ctx)` 方法，代码如下：
+
+```
+@Override
+public void handlerAdded(ChannelHandlerContext ctx) throws Exception {
+    if (ctx.channel().isRegistered()) { // 已注册
+        // This should always be true with our current DefaultChannelPipeline implementation.
+        // The good thing about calling initChannel(...) in handlerAdded(...) is that there will be no ordering
+        // surprises if a ChannelInitializer will add another ChannelInitializer. This is as all handlers
+        // will be added in the expected order.
+        initChannel(ctx);
+    }
+}
+```
+
+- 诶？怎么这里又调用了 `#initChannel(ChannelHandlerContext ctx)` 方法，初始化 Channel 呢？实际上，绝绝绝大多数情况下，因为 Channel Registered 事件触发在 Added **之后**，如果说在 `#handlerAdded(ChannelHandlerContext ctx)` 方法中，初始化 Channel 完成，那么 ChannelInitializer 便会从 pipeline 中移除。也就说，不会执行 `#channelRegistered(ChannelHandlerContext ctx)` 方法。
+
+- ↑↑↑ 上面这段话听起来非常绕噢。简单来说，ChannelInitializer 调用 `#initChannel(ChannelHandlerContext ctx)` 方法，初始化 Channel 的调用来源，是来自 `#handlerAdded(...)` 方法，而不是 `#channelRegistered(...)` 方法。
+
+- 还是不理解？胖友在
+
+   
+
+  ```
+  #handlerAdded(ChannelHandlerContext ctx)
+  ```
+
+   
+
+  方法上打上“
+
+  断点
+
+  ”，并调试启动
+
+   
+
+  ```
+  io.netty.example.echo.EchoServer
+  ```
+
+   
+
+  ，就能触发这种情况。原因是什么呢？如下图所示：
+
+  ![register0](49-Netty 源码解析-ChannelHandler（二）之 ChannelInitializer.assets/02.png)
+
+  register0
+
+  - 😈 红框部分，看到否？明白了哇。
+
+至于说，什么时候使用 ChannelInitializer 调用 `#initChannel(ChannelHandlerContext ctx)` 方法，初始化 Channel 的调用来源，是来自 `#channelRegistered(...)` 方法，笔者暂未发现。如果有知道的胖友，麻烦深刻教育我下。
+
+TODO 1020 ChannelInitializer 对 channelRegistered 的触发
+
+# 666. 彩蛋
+
+小水文一篇。同时也推荐阅读：
+
+- Donald_Draper [《netty 通道初始化器ChannelInitializer》](http://donald-draper.iteye.com/blog/2389352)
\ No newline at end of file
diff --git a/netty/50-Netty 源码解析-ChannelHandler（三）之 SimpleChannelInboundHandler.md b/netty/50-Netty 源码解析-ChannelHandler（三）之 SimpleChannelInboundHandler.md
new file mode 100644
index 0000000..f6bb39b
--- /dev/null
+++ b/netty/50-Netty 源码解析-ChannelHandler（三）之 SimpleChannelInboundHandler.md	
@@ -0,0 +1,291 @@
+# 精尽 Netty 源码解析 —— ChannelHandler（三）之 SimpleChannelInboundHandler
+
+# 1. 概述
+
+在本文，我们来分享 SimpleChannelInboundHandler 处理器。考虑到 Simple**UserEvent**ChannelHandler 和 SimpleChannelInboundHandler 的实现基本一致，所以也会在本文中分享。
+
+如果胖友对 SimpleChannelInboundHandler 的使用不了解，请先看下 [《一起学Netty（三）之 SimpleChannelInboundHandler》](https://blog.csdn.net/linuu/article/details/51307060) ，嘿嘿。
+
+# 2. SimpleChannelInboundHandler
+
+`io.netty.channel.SimpleChannelInboundHandler` ，继承 ChannelInboundHandlerAdapter 类，抽象类，处理**指定类型**的消息。应用程序中，我们可以实现 SimpleChannelInboundHandler 后，实现对**指定类型**的消息的自定义处理。
+
+## 2.1 构造方法
+
+```
+public abstract class SimpleChannelInboundHandler<I> extends ChannelInboundHandlerAdapter {
+
+    /**
+     * 类型匹配器
+     */
+    private final TypeParameterMatcher matcher;
+    /**
+     * 使用完消息，是否自动释放
+     *
+     * @see #channelRead(ChannelHandlerContext, Object)
+     */
+    private final boolean autoRelease;
+
+    /**
+     * see {@link #SimpleChannelInboundHandler(boolean)} with {@code true} as boolean parameter.
+     */
+    protected SimpleChannelInboundHandler() {
+        this(true);
+    }
+
+    /**
+     * Create a new instance which will try to detect the types to match out of the type parameter of the class.
+     *
+     * @param autoRelease   {@code true} if handled messages should be released automatically by passing them to
+     *                      {@link ReferenceCountUtil#release(Object)}.
+     */
+    protected SimpleChannelInboundHandler(boolean autoRelease) {
+        // <1> 获得 matcher
+        matcher = TypeParameterMatcher.find(this, SimpleChannelInboundHandler.class, "I");
+        this.autoRelease = autoRelease;
+    }
+
+    /**
+     * see {@link #SimpleChannelInboundHandler(Class, boolean)} with {@code true} as boolean value.
+     */
+    protected SimpleChannelInboundHandler(Class<? extends I> inboundMessageType) {
+        this(inboundMessageType, true);
+    }
+
+    /**
+     * Create a new instance
+     *
+     * @param inboundMessageType    The type of messages to match
+     * @param autoRelease           {@code true} if handled messages should be released automatically by passing them to
+     *                              {@link ReferenceCountUtil#release(Object)}.
+     */
+    protected SimpleChannelInboundHandler(Class<? extends I> inboundMessageType, boolean autoRelease) {
+        // <2> 获得 matcher
+        matcher = TypeParameterMatcher.get(inboundMessageType);
+        this.autoRelease = autoRelease;
+    }
+    
+    // ... 省略其它方法
+}
+```
+
+- ```
+  matcher
+  ```
+
+   
+
+  属性，有
+
+  两种
+
+  方式赋值。
+
+  - 【常用】`<1>` 处，使用类的 `I` 泛型对应的 TypeParameterMatcher 类型匹配器。
+  - `<2>` 处，使用 `inboundMessageType` 参数对应的 TypeParameterMatcher 类型匹配器。
+  - 在大多数情况下，我们不太需要特别详细的了解 `io.netty.util.internal.TypeParameterMatcher` 的代码实现，感兴趣的胖友可以自己看看 [《netty 简单Inbound通道处理器（SimpleChannelInboundHandler）》](http://donald-draper.iteye.com/blog/2387772) 的 [「TypeParameterMatcher」](https://svip.iocoder.cn/Netty/ChannelHandler-3-SimpleChannelInboundHandler/#) 部分。
+
+- `autoRelease` 属性，使用完消息，是否自动释放。
+
+## 2.2 acceptInboundMessage
+
+`#acceptInboundMessage(Object msg)` 方法，判断消息是否匹配。代码如下：
+
+```
+/**
+ * Returns {@code true} if the given message should be handled. If {@code false} it will be passed to the next
+ * {@link ChannelInboundHandler} in the {@link ChannelPipeline}.
+ */
+public boolean acceptInboundMessage(Object msg) {
+    return matcher.match(msg);
+}
+```
+
+一般情况下，`matcher` 的类型是 ReflectiveMatcher( 它是 TypeParameterMatcher 的内部类 )。代码如下：
+
+```
+private static final class ReflectiveMatcher extends TypeParameterMatcher {
+    
+    /**
+     * 类型
+     */
+    private final Class<?> type;
+    
+    ReflectiveMatcher(Class<?> type) {
+        this.type = type;
+    }
+    
+    @Override
+    public boolean match(Object msg) {
+        return type.isInstance(msg); // <1>
+    }
+    
+}
+```
+
+- 匹配逻辑，看 `<1>` 处，使用 `Class#isInstance(Object obj)` 方法。对于这个方法，如果我们定义的 `I` 泛型是个父类，那可以匹配所有的子类。例如 `I` 设置为 Object 类，那么所有消息，都可以被匹配列。
+
+## 2.3 channelRead
+
+```
+ 1: @Override
+ 2: public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
+ 3:     // 是否要释放消息
+ 4:     boolean release = true;
+ 5:     try {
+ 6:         // 判断是否为匹配的消息
+ 7:         if (acceptInboundMessage(msg)) {
+ 8:             @SuppressWarnings("unchecked")
+ 9:             I imsg = (I) msg;
+10:             // 处理消息
+11:             channelRead0(ctx, imsg);
+12:         } else {
+13:             // 不需要释放消息
+14:             release = false;
+15:             // 触发 Channel Read 到下一个节点
+16:             ctx.fireChannelRead(msg);
+17:         }
+18:     } finally {
+19:         // 判断，是否要释放消息
+20:         if (autoRelease && release) {
+21:             ReferenceCountUtil.release(msg);
+22:         }
+23:     }
+24: }
+```
+
+- 第 4 行：`release` 属性，是否需要释放消息。
+
+- 第 7 行：调用 `#acceptInboundMessage(Object msg)` 方法，判断是否为匹配的消息。
+
+  - ① **匹配**，调用 `#channelRead0(ChannelHandlerContext ctx, I msg)` **抽象**方法，处理消息。代码如下：
+
+    ```
+    /**
+     * <strong>Please keep in mind that this method will be renamed to
+     * {@code messageReceived(ChannelHandlerContext, I)} in 5.0.</strong>
+     *
+     * Is called for each message of type {@link I}.
+     *
+     * @param ctx           the {@link ChannelHandlerContext} which this {@link SimpleChannelInboundHandler}
+     *                      belongs to
+     * @param msg           the message to handle
+     * @throws Exception    is thrown if an error occurred
+     */
+    protected abstract void channelRead0(ChannelHandlerContext ctx, I msg) throws Exception;
+    ```
+
+    - 子类实现 SimpleChannelInboundHandler 类后，实现该方法，就能很方便的处理消息。
+
+  - ② **不匹配**，标记不需要释放消息，并触发 Channel Read 到**下一个节点**。
+
+- 第 18 至 23 行：通过 `release` 变量 + `autoRelease` 属性，判断是否需要释放消息。若需要，调用 `ReferenceCountUtil#release(Object msg)` 方法，释放消息。😈 还是蛮方便的。
+
+# 3. SimpleUserEventChannelHandler
+
+`io.netty.channel.SimpleUserEventChannelHandler` ，继承 ChannelInboundHandlerAdapter 类，抽象类，处理**指定事件**的消息。
+
+SimpleUserEventChannelHandler 和 SimpleChannelInboundHandler 基本一致，差别在于将指定类型的消息，改成了制定类型的事件。😈 所以，笔者就不详细解析了。
+
+代码如下：
+
+```
+public abstract class SimpleUserEventChannelHandler<I> extends ChannelInboundHandlerAdapter {
+
+    /**
+     * 类型匹配器
+     */
+    private final TypeParameterMatcher matcher;
+    /**
+     * 使用完消息，是否自动释放
+     *
+     * @see #channelRead(ChannelHandlerContext, Object)
+     */
+    private final boolean autoRelease;
+
+    /**
+     * see {@link #SimpleUserEventChannelHandler(boolean)} with {@code true} as boolean parameter.
+     */
+    protected SimpleUserEventChannelHandler() {
+        this(true);
+    }
+
+    /**
+     * Create a new instance which will try to detect the types to match out of the type parameter of the class.
+     *
+     * @param autoRelease   {@code true} if handled events should be released automatically by passing them to
+     *                      {@link ReferenceCountUtil#release(Object)}.
+     */
+    protected SimpleUserEventChannelHandler(boolean autoRelease) {
+        matcher = TypeParameterMatcher.find(this, SimpleUserEventChannelHandler.class, "I");
+        this.autoRelease = autoRelease;
+    }
+
+    /**
+     * see {@link #SimpleUserEventChannelHandler(Class, boolean)} with {@code true} as boolean value.
+     */
+    protected SimpleUserEventChannelHandler(Class<? extends I> eventType) {
+        this(eventType, true);
+    }
+
+    /**
+     * Create a new instance
+     *
+     * @param eventType      The type of events to match
+     * @param autoRelease    {@code true} if handled events should be released automatically by passing them to
+     *                       {@link ReferenceCountUtil#release(Object)}.
+     */
+    protected SimpleUserEventChannelHandler(Class<? extends I> eventType, boolean autoRelease) {
+        matcher = TypeParameterMatcher.get(eventType);
+        this.autoRelease = autoRelease;
+    }
+
+    /**
+     * Returns {@code true} if the given user event should be handled. If {@code false} it will be passed to the next
+     * {@link ChannelInboundHandler} in the {@link ChannelPipeline}.
+     */
+    protected boolean acceptEvent(Object evt) throws Exception {
+        return matcher.match(evt);
+    }
+
+    @Override
+    public final void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws Exception {
+        // 是否要释放消息
+        boolean release = true;
+        try {
+            // 判断是否为匹配的消息
+            if (acceptEvent(evt)) {
+                @SuppressWarnings("unchecked")
+                I ievt = (I) evt;
+                // 处理消息
+                eventReceived(ctx, ievt);
+            } else {
+                // 不需要释放消息
+                release = false;
+                // 触发 Channel Read 到下一个节点
+                ctx.fireUserEventTriggered(evt);
+            }
+        } finally {
+            // 判断，是否要释放消息
+            if (autoRelease && release) {
+                ReferenceCountUtil.release(evt);
+            }
+        }
+    }
+
+    /**
+     * Is called for each user event triggered of type {@link I}.
+     *
+     * @param ctx the {@link ChannelHandlerContext} which this {@link SimpleUserEventChannelHandler} belongs to
+     * @param evt the user event to handle
+     *
+     * @throws Exception is thrown if an error occurred
+     */
+    protected abstract void eventReceived(ChannelHandlerContext ctx, I evt) throws Exception;
+
+}
+```
+
+# 666. 彩蛋
+
+木有彩蛋，hoho 。
\ No newline at end of file
diff --git a/netty/51-Netty 源码解析-ChannelHandler（四）之 LoggingHandler.assets/01.png b/netty/51-Netty 源码解析-ChannelHandler（四）之 LoggingHandler.assets/01.png
new file mode 100644
index 0000000..bae765f
Binary files /dev/null and b/netty/51-Netty 源码解析-ChannelHandler（四）之 LoggingHandler.assets/01.png differ
diff --git a/netty/51-Netty 源码解析-ChannelHandler（四）之 LoggingHandler.assets/02.png b/netty/51-Netty 源码解析-ChannelHandler（四）之 LoggingHandler.assets/02.png
new file mode 100644
index 0000000..d658700
Binary files /dev/null and b/netty/51-Netty 源码解析-ChannelHandler（四）之 LoggingHandler.assets/02.png differ
diff --git a/netty/51-Netty 源码解析-ChannelHandler（四）之 LoggingHandler.md b/netty/51-Netty 源码解析-ChannelHandler（四）之 LoggingHandler.md
new file mode 100644
index 0000000..f1fb35d
--- /dev/null
+++ b/netty/51-Netty 源码解析-ChannelHandler（四）之 LoggingHandler.md	
@@ -0,0 +1,480 @@
+# 精尽 Netty 源码解析 —— ChannelHandler（四）之 LoggingHandler
+
+# 1. 概述
+
+在 `netty-handler` 模块中，提供了多种 ChannelHandler 的实现类。如下图所示：[![`netty-handler`](51-Netty 源码解析-ChannelHandler（四）之 LoggingHandler.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_10_10/01.png)`netty-handler`
+
+- 每个 `package` 包，对应一个**功能特性**的 ChannelHandler 实现。
+
+本文，我们来分享 `logger` 包下 `logging` 包的 LoggerHandler 。
+
+# 2. LogLevel
+
+`io.netty.handler.logging.LogLevel` ，日志级别枚举类。代码如下：
+
+```
+/**
+ * Maps the regular {@link LogLevel}s with the {@link InternalLogLevel} ones.
+ */
+public enum LogLevel {
+
+    TRACE(InternalLogLevel.TRACE),
+    DEBUG(InternalLogLevel.DEBUG),
+    INFO(InternalLogLevel.INFO),
+    WARN(InternalLogLevel.WARN),
+    ERROR(InternalLogLevel.ERROR);
+
+    /**
+     * Netty 内部日志级别
+     */
+    private final InternalLogLevel internalLevel;
+
+    LogLevel(InternalLogLevel internalLevel) {
+        this.internalLevel = internalLevel;
+    }
+
+    /**
+     * For internal use only.
+     *
+     * <p/>Converts the specified {@link LogLevel} to its {@link InternalLogLevel} variant.
+     *
+     * @return the converted level.
+     */
+    public InternalLogLevel toInternalLevel() {
+        return internalLevel;
+    }
+
+}
+```
+
+- Netty 提供了一套日志框架，方便接入 slf4j、log4j、jdk logger 等等日志框架。感兴趣的胖友，可以看看 [《Netty4.x Internal Logger机制》](https://segmentfault.com/a/1190000005797595) 。😈 现在，不看也不影响对本文的理解。
+- LogLevel 实现对 `io.netty.util.internal.logging.InternalLogLevel` 的**一一**映射。笔者暂时看不出有什么神奇的用途，难道是为了可以灵活的修改映射关系？！有了解的胖友，可以深刻教育下我噢。
+
+# 3. LoggingHandler
+
+`io.netty.handler.logging.LoggingHandler` ，继承 ChannelDuplexHandler 类，日志处理器，对 Inbound/Outbound 事件进行日志的记录。一般情况下，用于开发测试时的调试之用。
+
+## 3.1 构造方法
+
+```
+@Sharable
+public class LoggingHandler extends ChannelDuplexHandler {
+
+    /**
+     * 默认 {@link #level} 日志级别
+     */
+    private static final LogLevel DEFAULT_LEVEL = LogLevel.DEBUG;
+
+    /**
+     * Netty 内部 Logger 对象
+     */
+    protected final InternalLogger logger;
+    /**
+     * Netty 内部 LogLevel 级别
+     */
+    protected final InternalLogLevel internalLevel;
+
+    /**
+     * 配置的 LogLevel 级别
+     */
+    private final LogLevel level;
+
+    /**
+     * Creates a new instance whose logger name is the fully qualified class
+     * name of the instance with hex dump enabled.
+     */
+    public LoggingHandler() {
+        this(DEFAULT_LEVEL);
+    }
+
+    /**
+     * Creates a new instance whose logger name is the fully qualified class
+     * name of the instance.
+     *
+     * @param level the log level
+     */
+    public LoggingHandler(LogLevel level) {
+        if (level == null) {
+            throw new NullPointerException("level");
+        }
+
+        // 获得 logger
+        logger = InternalLoggerFactory.getInstance(getClass());
+        this.level = level;
+        internalLevel = level.toInternalLevel();
+    }
+
+    /**
+     * Creates a new instance with the specified logger name and with hex dump
+     * enabled.
+     *
+     * @param clazz the class type to generate the logger for
+     */
+    public LoggingHandler(Class<?> clazz) {
+        this(clazz, DEFAULT_LEVEL);
+    }
+
+    /**
+     * Creates a new instance with the specified logger name.
+     *
+     * @param clazz the class type to generate the logger for
+     * @param level the log level
+     */
+    public LoggingHandler(Class<?> clazz, LogLevel level) {
+        if (clazz == null) {
+            throw new NullPointerException("clazz");
+        }
+        if (level == null) {
+            throw new NullPointerException("level");
+        }
+
+        // 获得 logger
+        logger = InternalLoggerFactory.getInstance(clazz);
+        this.level = level;
+        internalLevel = level.toInternalLevel();
+    }
+
+    /**
+     * Creates a new instance with the specified logger name using the default log level.
+     *
+     * @param name the name of the class to use for the logger
+     */
+    public LoggingHandler(String name) {
+        this(name, DEFAULT_LEVEL);
+    }
+
+    /**
+     * Creates a new instance with the specified logger name.
+     *
+     * @param name the name of the class to use for the logger
+     * @param level the log level
+     */
+    public LoggingHandler(String name, LogLevel level) {
+        if (name == null) {
+            throw new NullPointerException("name");
+        }
+        if (level == null) {
+            throw new NullPointerException("level");
+        }
+
+        // 获得 logger
+        logger = InternalLoggerFactory.getInstance(name);
+        this.level = level;
+        internalLevel = level.toInternalLevel();
+    }
+    
+    // ... 省略其他方法
+}
+```
+
+- 通过 `@Sharable` 注解，支持共享。
+
+- ```
+  level
+  ```
+
+   
+
+  属性，配置的 LogLevel 级别。
+
+  - `DEFAULT_LEVEL` **静态**属性，默认的 `level` 级别。构造方法如果未传递 `LogLevel level` 方法参数，则使用默认值。
+  - `internalLevel` 属性，Netty 内部 LogLevel 级别。通过 `LogLevel#toInternalLevel()` 方法，将 `level` 转化成 `internalLevel` 。
+
+- `logger` 属性，Netty 内部 Logger 对象。通过 `Class<?> clazz` 或 `String name` 方法参数，进行获得。
+
+## 3.2 具体实现
+
+```
+@Override
+public void channelRegistered(ChannelHandlerContext ctx) throws Exception {
+    if (logger.isEnabled(internalLevel)) {
+        logger.log(internalLevel, format(ctx, "REGISTERED"));
+    }
+    //
+    ctx.fireChannelRegistered();
+}
+
+@Override
+public void channelUnregistered(ChannelHandlerContext ctx) throws Exception {
+    if (logger.isEnabled(internalLevel)) {
+        logger.log(internalLevel, format(ctx, "UNREGISTERED"));
+    }
+    ctx.fireChannelUnregistered();
+}
+
+@Override
+public void channelActive(ChannelHandlerContext ctx) throws Exception {
+    // 打印日志
+    if (logger.isEnabled(internalLevel)) {
+        logger.log(internalLevel, format(ctx, "ACTIVE"));
+    }
+    // 传递 Channel active 事件，给下一个节点
+    ctx.fireChannelActive();
+}
+
+@Override
+public void channelInactive(ChannelHandlerContext ctx) throws Exception {
+    if (logger.isEnabled(internalLevel)) {
+        logger.log(internalLevel, format(ctx, "INACTIVE"));
+    }
+    ctx.fireChannelInactive();
+}
+
+@Override
+public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
+    if (logger.isEnabled(internalLevel)) {
+        logger.log(internalLevel, format(ctx, "EXCEPTION", cause), cause);
+    }
+    ctx.fireExceptionCaught(cause);
+}
+
+@Override
+public void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws Exception {
+    if (logger.isEnabled(internalLevel)) {
+        logger.log(internalLevel, format(ctx, "USER_EVENT", evt));
+    }
+    ctx.fireUserEventTriggered(evt);
+}
+
+@Override
+public void bind(ChannelHandlerContext ctx, SocketAddress localAddress, ChannelPromise promise) throws Exception {
+    if (logger.isEnabled(internalLevel)) {
+        logger.log(internalLevel, format(ctx, "BIND", localAddress));
+    }
+    ctx.bind(localAddress, promise);
+}
+
+@Override
+public void connect(
+        ChannelHandlerContext ctx,
+        SocketAddress remoteAddress, SocketAddress localAddress, ChannelPromise promise) throws Exception {
+    if (logger.isEnabled(internalLevel)) {
+        logger.log(internalLevel, format(ctx, "CONNECT", remoteAddress, localAddress));
+    }
+    ctx.connect(remoteAddress, localAddress, promise);
+}
+
+@Override
+public void disconnect(ChannelHandlerContext ctx, ChannelPromise promise) throws Exception {
+    if (logger.isEnabled(internalLevel)) {
+        logger.log(internalLevel, format(ctx, "DISCONNECT"));
+    }
+    ctx.disconnect(promise);
+}
+
+@Override
+public void close(ChannelHandlerContext ctx, ChannelPromise promise) throws Exception {
+    if (logger.isEnabled(internalLevel)) {
+        logger.log(internalLevel, format(ctx, "CLOSE"));
+    }
+    ctx.close(promise);
+}
+
+@Override
+public void deregister(ChannelHandlerContext ctx, ChannelPromise promise) throws Exception {
+    if (logger.isEnabled(internalLevel)) {
+        logger.log(internalLevel, format(ctx, "DEREGISTER"));
+    }
+    ctx.deregister(promise);
+}
+
+@Override
+public void channelReadComplete(ChannelHandlerContext ctx) throws Exception {
+    if (logger.isEnabled(internalLevel)) {
+        logger.log(internalLevel, format(ctx, "READ COMPLETE"));
+    }
+    ctx.fireChannelReadComplete();
+}
+
+@Override
+public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
+    if (logger.isEnabled(internalLevel)) {
+        logger.log(internalLevel, format(ctx, "READ", msg));
+    }
+    ctx.fireChannelRead(msg);
+}
+
+@Override
+public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) throws Exception {
+    if (logger.isEnabled(internalLevel)) {
+        logger.log(internalLevel, format(ctx, "WRITE", msg));
+    }
+    ctx.write(msg, promise);
+}
+
+@Override
+public void channelWritabilityChanged(ChannelHandlerContext ctx) throws Exception {
+    if (logger.isEnabled(internalLevel)) {
+        logger.log(internalLevel, format(ctx, "WRITABILITY CHANGED"));
+    }
+    ctx.fireChannelWritabilityChanged();
+}
+
+@Override
+public void flush(ChannelHandlerContext ctx) throws Exception {
+    if (logger.isEnabled(internalLevel)) {
+        logger.log(internalLevel, format(ctx, "FLUSH"));
+    }
+    ctx.flush();
+}
+```
+
+里面的每个方法，都是使用 `logger` 打印日志，并继续传播事件到下一个节点。
+
+而打印的日志的格式，通过 `#format(...)` 方法，进行拼接。
+
+## 3.3 format
+
+`#format(...)` 方法，根据参数的不同，分成三种。
+
+① `#format(ChannelHandlerContext ctx, String eventName)` 方法，代码如下：
+
+```
+/**
+ * Formats an event and returns the formatted message.
+ *
+ * @param eventName the name of the event
+ */
+protected String format(ChannelHandlerContext ctx, String eventName) {
+    String chStr = ctx.channel().toString();
+    return new StringBuilder(chStr.length() + 1 + eventName.length())
+        .append(chStr)
+        .append(' ')
+        .append(eventName)
+        .toString();
+}
+```
+
+② `#format(ChannelHandlerContext ctx, String eventName, Object arg)` 方法，代码如下：
+
+```
+/**
+ * Formats an event and returns the formatted message.
+ *
+ * @param eventName the name of the event
+ * @param arg       the argument of the event
+ */
+protected String format(ChannelHandlerContext ctx, String eventName, Object arg) {
+    if (arg instanceof ByteBuf) {
+        return formatByteBuf(ctx, eventName, (ByteBuf) arg);
+    } else if (arg instanceof ByteBufHolder) {
+        return formatByteBufHolder(ctx, eventName, (ByteBufHolder) arg);
+    } else {
+        return formatSimple(ctx, eventName, arg);
+    }
+}
+```
+
+- 根据参数不同，会调用不同的 format 方法。
+
+③ `#format(ChannelHandlerContext ctx, String eventName, Object firstArg, Object secondArg)` 方法，代码如下：
+
+```
+/**
+ * Formats an event and returns the formatted message.  This method is currently only used for formatting
+ * {@link ChannelOutboundHandler#connect(ChannelHandlerContext, SocketAddress, SocketAddress, ChannelPromise)}.
+ *
+ * @param eventName the name of the event
+ * @param firstArg  the first argument of the event
+ * @param secondArg the second argument of the event
+ */
+protected String format(ChannelHandlerContext ctx, String eventName, Object firstArg, Object secondArg) {
+    if (secondArg == null) {
+        return formatSimple(ctx, eventName, firstArg);
+    }
+
+    String chStr = ctx.channel().toString();
+    String arg1Str = String.valueOf(firstArg);
+    String arg2Str = secondArg.toString();
+    StringBuilder buf = new StringBuilder(
+            chStr.length() + 1 + eventName.length() + 2 + arg1Str.length() + 2 + arg2Str.length());
+    buf.append(chStr).append(' ').append(eventName).append(": ").append(arg1Str).append(", ").append(arg2Str);
+    return buf.toString();
+}
+```
+
+### 3.3.1 formatByteBuf
+
+`#formatByteBuf(ChannelHandlerContext ctx, String eventName, ByteBuf msg)` 方法，代码如下：
+
+```
+/**
+ * Generates the default log message of the specified event whose argument is a {@link ByteBuf}.
+ */
+private static String formatByteBuf(ChannelHandlerContext ctx, String eventName, ByteBuf msg) {
+    String chStr = ctx.channel().toString();
+    int length = msg.readableBytes();
+    if (length == 0) {
+        StringBuilder buf = new StringBuilder(chStr.length() + 1 + eventName.length() + 4);
+        buf.append(chStr).append(' ').append(eventName).append(": 0B");
+        return buf.toString();
+    } else {
+        int rows = length / 16 + (length % 15 == 0? 0 : 1) + 4;
+        StringBuilder buf = new StringBuilder(chStr.length() + 1 + eventName.length() + 2 + 10 + 1 + 2 + rows * 80);
+
+        buf.append(chStr).append(' ').append(eventName).append(": ").append(length).append('B').append(NEWLINE);
+        appendPrettyHexDump(buf, msg); // <1>
+
+        return buf.toString();
+    }
+}
+```
+
+- `<1>` 处的 `appendPrettyHexDump(buf, msg)` ，实际调用的是 `ByteBufUtil#appendPrettyHexDump(StringBuilder dump, ByteBuf buf)` 方法。
+
+如下是一个打印的示例：
+
+> FROM [《自顶向下深入分析Netty（八）–ChannelHandler》](https://www.jianshu.com/p/a9bcd89553f5)
+>
+> [![示例](51-Netty 源码解析-ChannelHandler（四）之 LoggingHandler.assets/02.png)](http://static.iocoder.cn/images/Netty/2018_10_10/02.png)示例
+
+### 3.3.2 formatByteBufHolder
+
+`#formatByteBufHolder(ChannelHandlerContext ctx, String eventName, ByteBufHolder msg)` 方法，代码如下：
+
+```
+/**
+ * Generates the default log message of the specified event whose argument is a {@link ByteBufHolder}.
+ */
+private static String formatByteBufHolder(ChannelHandlerContext ctx, String eventName, ByteBufHolder msg) {
+    String chStr = ctx.channel().toString();
+    String msgStr = msg.toString();
+    ByteBuf content = msg.content();
+    int length = content.readableBytes();
+    if (length == 0) {
+        StringBuilder buf = new StringBuilder(chStr.length() + 1 + eventName.length() + 2 + msgStr.length() + 4);
+        buf.append(chStr).append(' ').append(eventName).append(", ").append(msgStr).append(", 0B");
+        return buf.toString();
+    } else {
+        int rows = length / 16 + (length % 15 == 0? 0 : 1) + 4;
+        StringBuilder buf = new StringBuilder(chStr.length() + 1 + eventName.length() + 2 + msgStr.length() + 2 + 10 + 1 + 2 + rows * 80);
+
+        buf.append(chStr).append(' ').append(eventName).append(": ").append(msgStr).append(", ").append(length).append('B').append(NEWLINE);
+        appendPrettyHexDump(buf, content);
+
+        return buf.toString();
+    }
+}
+```
+
+- 和 `#formatByteBuf(ChannelHandlerContext ctx, String eventName, ByteBuf msg)` 方法，实际打印的效果，非常相似。
+
+### 3.3.3 formatSimple
+
+`#formatSimple(ChannelHandlerContext ctx, String eventName, Object msg)` 方法，代码如下：
+
+```
+/**
+ * Generates the default log message of the specified event whose argument is an arbitrary object.
+ */
+private static String formatSimple(ChannelHandlerContext ctx, String eventName, Object msg) {
+    String chStr = ctx.channel().toString();
+    String msgStr = String.valueOf(msg);
+    StringBuilder buf = new StringBuilder(chStr.length() + 1 + eventName.length() + 2 + msgStr.length());
+    return buf.append(chStr).append(' ').append(eventName).append(": ").append(msgStr).toString();
+}
+```
+
+# 666. 彩蛋
+
+还是没有彩蛋。
\ No newline at end of file
diff --git a/netty/52-Netty 源码解析-ChannelHandler（五）之 IdleStateHandler.assets/01.png b/netty/52-Netty 源码解析-ChannelHandler（五）之 IdleStateHandler.assets/01.png
new file mode 100644
index 0000000..a61fc92
Binary files /dev/null and b/netty/52-Netty 源码解析-ChannelHandler（五）之 IdleStateHandler.assets/01.png differ
diff --git a/netty/52-Netty 源码解析-ChannelHandler（五）之 IdleStateHandler.md b/netty/52-Netty 源码解析-ChannelHandler（五）之 IdleStateHandler.md
new file mode 100644
index 0000000..130cdb3
--- /dev/null
+++ b/netty/52-Netty 源码解析-ChannelHandler（五）之 IdleStateHandler.md	
@@ -0,0 +1,1458 @@
+# 精尽 Netty 源码解析 —— ChannelHandler（五）之 IdleStateHandler
+
+# 1. 概述
+
+在 `netty-handler` 模块的 `timeout` 包，实现 Channel 的读写操作的**空闲**检测。可能有胖友不太了解空闲检测的具体用途。请先研读理解下 [《简易RPC框架-心跳与重连机制》](https://www.cnblogs.com/ASPNET2008/p/7615973.html) 。
+
+# 2. 类
+
+`timeout` 包，包含的类，如下图所示：[![`timeout` 包](52-Netty 源码解析-ChannelHandler（五）之 IdleStateHandler.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_10_13/01.png)`timeout` 包
+
+一共有 3 个 ChannelHandler 实现类：
+
+- IdleStateHandler ，当 Channel 的
+
+  读或者写
+
+  空闲时间太长时，将会触发一个 IdleStateEvent 事件。然后，你可以自定义一个 ChannelInboundHandler ，重写
+
+   
+
+  ```
+  #userEventTriggered(ChannelHandlerContext ctx, Object evt)
+  ```
+
+   
+
+  方法，处理该事件。
+
+  - ReadTimeoutHandler ，继承 IdleStateHandler 类，当 Channel 的**读**空闲时间( 读或者写 )太长时，抛出 ReadTimeoutException 异常，并自动关闭该 Channel 。然后，你可以自定一个 ChannelInboundHandler ，重写 `#exceptionCaught(ChannelHandlerContext ctx, Throwable cause)` 方法，处理该异常。
+
+- WriteTimeoutHandler ，当一个**写**操作不能在指定时间内完成时，抛出 WriteTimeoutException 异常，并自动关闭对应 Channel 。然后，你可以自定一个 ChannelInboundHandler ，重写 `#exceptionCaught(ChannelHandlerContext ctx, Throwable cause)` 方法，处理该异常。
+
+😈 从 WriteTimeoutHandler 可以看出，本文实际不仅仅分享 IdleStateHandler ，更准确的是分享 Timeout 相关的 ChannelHandler 。考虑到大多数胖友对 IdleStateHandler 比较熟悉，也相对常用，所以标题才取了 [《精尽 Netty 源码解析 —— ChannelHandler（五）之 IdleStateHandler》](https://svip.iocoder.cn/Netty/ChannelHandler-5-idle/#) 。
+
+# 3. IdleState
+
+`io.netty.handler.timeout.IdleState` ，空闲状态**枚举**。代码如下：
+
+```
+/**
+ * 空闲状态枚举
+ *
+ * An {@link Enum} that represents the idle state of a {@link Channel}.
+ */
+public enum IdleState {
+
+    /**
+     * No data was received for a while.
+     *
+     * 读空闲
+     */
+    READER_IDLE,
+    /**
+     * No data was sent for a while.
+     *
+     * 写空闲
+     */
+    WRITER_IDLE,
+    /**
+     * No data was either received or sent for a while.
+     *
+     * 读或写任一空闲
+     */
+    ALL_IDLE
+
+}
+```
+
+- 一共有 3 种状态。其中，`ALL_IDLE` 表示的是，读**或**写任一空闲，注意是“或”。
+
+## 3.1 IdleStateEvent
+
+`io.netty.handler.timeout.IdleStateEvent` ，空闲事件。代码如下：
+
+```
+public class IdleStateEvent {
+
+    // READ
+    public static final IdleStateEvent FIRST_READER_IDLE_STATE_EVENT = new IdleStateEvent(IdleState.READER_IDLE, true); // 首次
+    public static final IdleStateEvent READER_IDLE_STATE_EVENT = new IdleStateEvent(IdleState.READER_IDLE, false);
+    // WRITE
+    public static final IdleStateEvent FIRST_WRITER_IDLE_STATE_EVENT = new IdleStateEvent(IdleState.WRITER_IDLE, true); // 首次
+    public static final IdleStateEvent WRITER_IDLE_STATE_EVENT = new IdleStateEvent(IdleState.WRITER_IDLE, false);
+    // ALL
+    public static final IdleStateEvent FIRST_ALL_IDLE_STATE_EVENT = new IdleStateEvent(IdleState.ALL_IDLE, true); // 首次
+    public static final IdleStateEvent ALL_IDLE_STATE_EVENT = new IdleStateEvent(IdleState.ALL_IDLE, false);
+
+    /**
+     * 空闲状态类型
+     */
+    private final IdleState state;
+    /**
+     * 是否首次
+     */
+    private final boolean first;
+
+    /**
+     * Constructor for sub-classes.
+     *
+     * @param state the {@link IdleStateEvent} which triggered the event.
+     * @param first {@code true} if its the first idle event for the {@link IdleStateEvent}.
+     */
+    protected IdleStateEvent(IdleState state, boolean first) {
+        this.state = ObjectUtil.checkNotNull(state, "state");
+        this.first = first;
+    }
+
+    /**
+     * Returns the idle state.
+     */
+    public IdleState state() {
+        return state;
+    }
+
+    /**
+     * Returns {@code true} if this was the first event for the {@link IdleState}
+     */
+    public boolean isFirst() {
+        return first;
+    }
+
+}
+```
+
+- 3 **类**( `state` )空闲事件，再组合上是否首次( `first` )，一共有 6 种空闲事件。
+
+# 4. TimeoutException
+
+`io.netty.handler.timeout.TimeoutException` ，继承 ChannelException 类，超时异常。代码如下：
+
+```
+public class TimeoutException extends ChannelException {
+
+    TimeoutException() { }
+
+    @Override
+    public Throwable fillInStackTrace() {
+        return this;
+    }
+
+}
+```
+
+## 4.1 ReadTimeoutException
+
+`io.netty.handler.timeout.ReadTimeoutException` ，继承 TimeoutException 类，读超时( 空闲 )异常。代码如下：
+
+```
+public final class ReadTimeoutException extends TimeoutException {
+
+    /**
+     * 单例
+     */
+    public static final ReadTimeoutException INSTANCE = new ReadTimeoutException();
+
+    private ReadTimeoutException() { }
+
+}
+```
+
+## 4.2 WriteTimeoutException
+
+`io.netty.handler.timeout.WriteTimeoutException` ，继承 TimeoutException 类，写超时( 空闲 )异常。代码如下：
+
+```
+public final class WriteTimeoutException extends TimeoutException {
+
+    /**
+     * 单例
+     */
+    public static final WriteTimeoutException INSTANCE = new WriteTimeoutException();
+
+    private WriteTimeoutException() { }
+
+}
+```
+
+# 5. IdleStateHandler
+
+`io.netty.handler.timeout.IdleStateHandler` ，继承 ChannelDuplexHandler 类，当 Channel 的**读或者写**空闲时间太长时，将会触发一个 IdleStateEvent 事件。
+
+## 5.1 构造方法
+
+> 老艿艿：高能预警，IdleStateHandler 的属性有点点多。
+
+```
+/**
+ * 最小的超时时间，单位：纳秒
+ */
+private static final long MIN_TIMEOUT_NANOS = TimeUnit.MILLISECONDS.toNanos(1);
+
+/**
+ * 写入任务监听器
+ */
+// Not create a new ChannelFutureListener per write operation to reduce GC pressure.
+private final ChannelFutureListener writeListener = new ChannelFutureListener() {
+
+    @Override
+    public void operationComplete(ChannelFuture future) throws Exception {
+        // 记录最后写时间
+        lastWriteTime = ticksInNanos();
+        // 重置 firstWriterIdleEvent 和 firstAllIdleEvent 为 true
+        firstWriterIdleEvent = firstAllIdleEvent = true;
+    }
+
+};
+
+/**
+ * 是否观察 {@link ChannelOutboundBuffer} 写入队列
+ */
+private final boolean observeOutput;
+/**
+ * 配置的读空闲时间，单位：纳秒
+ */
+private final long readerIdleTimeNanos;
+/**
+ * 配置的写空闲时间，单位：纳秒
+ */
+private final long writerIdleTimeNanos;
+/**
+ * 配置的All( 读或写任一 )，单位：纳秒
+ */
+private final long allIdleTimeNanos;
+
+/**
+ * 读空闲的定时检测任务
+ */
+private ScheduledFuture<?> readerIdleTimeout;
+/**
+ * 最后读时间
+ */
+private long lastReadTime;
+/**
+ * 是否首次读空闲
+ */
+private boolean firstReaderIdleEvent = true;
+
+/**
+ * 写空闲的定时检测任务
+ */
+private ScheduledFuture<?> writerIdleTimeout;
+/**
+ * 最后写时间
+ */
+private long lastWriteTime;
+/**
+ * 是否首次写空闲
+ */
+private boolean firstWriterIdleEvent = true;
+
+/**
+ * All 空闲时间，单位：纳秒
+ */
+private ScheduledFuture<?> allIdleTimeout;
+/**
+ * 是否首次 All 空闲
+ */
+private boolean firstAllIdleEvent = true;
+
+/**
+ * 状态
+ *
+ * 0 - none ，未初始化
+ * 1 - initialized ，已经初始化
+ * 2 - destroyed ，已经销毁
+ */
+private byte state; // 0 - none, 1 - initialized, 2 - destroyed
+/**
+ * 是否正在读取
+ */
+private boolean reading;
+
+/**
+ * 最后检测到 {@link ChannelOutboundBuffer} 发生变化的时间
+ */
+private long lastChangeCheckTimeStamp;
+/**
+ * 第一条准备 flash 到对端的消息( {@link ChannelOutboundBuffer#current()} )的 HashCode
+ */
+private int lastMessageHashCode;
+/**
+ * 总共等待 flush 到对端的内存大小( {@link ChannelOutboundBuffer#totalPendingWriteBytes()} )
+ */
+private long lastPendingWriteBytes;
+
+public IdleStateHandler(int readerIdleTimeSeconds, int writerIdleTimeSeconds, int allIdleTimeSeconds) {
+    this(readerIdleTimeSeconds, writerIdleTimeSeconds, allIdleTimeSeconds, TimeUnit.SECONDS);
+}
+
+public IdleStateHandler(long readerIdleTime, long writerIdleTime, long allIdleTime, TimeUnit unit) {
+    this(false, readerIdleTime, writerIdleTime, allIdleTime, unit);
+}
+
+/**
+ * Creates a new instance firing {@link IdleStateEvent}s.
+ *
+ * @param observeOutput
+ *        whether or not the consumption of {@code bytes} should be taken into
+ *        consideration when assessing write idleness. The default is {@code false}.
+ * @param readerIdleTime
+ *        an {@link IdleStateEvent} whose state is {@link IdleState#READER_IDLE}
+ *        will be triggered when no read was performed for the specified
+ *        period of time.  Specify {@code 0} to disable.
+ * @param writerIdleTime
+ *        an {@link IdleStateEvent} whose state is {@link IdleState#WRITER_IDLE}
+ *        will be triggered when no write was performed for the specified
+ *        period of time.  Specify {@code 0} to disable.
+ * @param allIdleTime
+ *        an {@link IdleStateEvent} whose state is {@link IdleState#ALL_IDLE}
+ *        will be triggered when neither read nor write was performed for
+ *        the specified period of time.  Specify {@code 0} to disable.
+ * @param unit
+ *        the {@link TimeUnit} of {@code readerIdleTime},
+ *        {@code writeIdleTime}, and {@code allIdleTime}
+ */
+public IdleStateHandler(boolean observeOutput, long readerIdleTime, long writerIdleTime, long allIdleTime, TimeUnit unit) {
+    if (unit == null) {
+        throw new NullPointerException("unit");
+    }
+
+    this.observeOutput = observeOutput;
+
+    if (readerIdleTime <= 0) {
+        readerIdleTimeNanos = 0;
+    } else {
+        readerIdleTimeNanos = Math.max(unit.toNanos(readerIdleTime), MIN_TIMEOUT_NANOS); // 保证大于等于 MIN_TIMEOUT_NANOS
+    }
+    if (writerIdleTime <= 0) {
+        writerIdleTimeNanos = 0;
+    } else {
+        writerIdleTimeNanos = Math.max(unit.toNanos(writerIdleTime), MIN_TIMEOUT_NANOS); // 保证大于等于 MIN_TIMEOUT_NANOS
+    }
+    if (allIdleTime <= 0) {
+        allIdleTimeNanos = 0;
+    } else {
+        allIdleTimeNanos = Math.max(unit.toNanos(allIdleTime), MIN_TIMEOUT_NANOS); // 保证大于等于 MIN_TIMEOUT_NANOS
+    }
+}
+```
+
+- 属性比较多，保持耐心和淡定，我们继续来整理一波。
+
+- `MIN_TIMEOUT_NANOS` 静态属性，最小的超时时间为 **1** ，单位：纳秒。因为 IdleStateHandler 创建的，检测定时任务的时间，以纳秒为单位。
+
+- `state` 属性，IdleStateHandler 的状态。一共有三种，见注释。
+
+- Read 空闲相关属性
+
+  - `readerIdleTimeNanos` 属性，配置的读空闲时间，单位：纳秒。
+  - `readerIdleTimeout` 属性，读空闲的定时检测任务。
+  - `lastReadTime` 属性，读空闲的定时检测任务。
+  - `firstReaderIdleEvent` 属性，是否首次读空闲。
+  - 【**独有**】 `reading` 属性，是否正在读取。
+
+- Write 空闲相关属性
+
+  - `writerIdleTimeNanos` 属性，配置的写空闲时间，单位：纳秒。
+
+  - `writerIdleTimeout` 属性，写空闲的定时检测任务。
+
+  - `lastWriteTime` 属性，最后写时间。
+
+  - `writeListener` 属性，写入操作，完成 flush 到对端的回调监听器。初始时，创建好，避免重复创建，从而减轻 GC 压力。
+
+  - 【
+
+    独有
+
+    】ChannelOutboundBuffer 相关属性
+
+    - `observeOutput` 属性， 是否观察 ChannelOutboundBuffer 写入队列。
+    - `lastChangeCheckTimeStamp` 属性，最后检测到 ChannelOutboundBuffer 发生变化的时间。
+    - `lastMessageHashCode` 属性，第一条准备 flash 到对端的消息的 HashCode 。
+    - `lastPendingWriteBytes` 属性，总共等待 flush 到对端的内存大小。
+    - 关于这几个属性，跟着 [「5.7 hasOutputChanged」](https://svip.iocoder.cn/Netty/ChannelHandler-5-idle/#) 一起理解。
+
+- ALL 空闲相关属性
+
+  - 因为 ALL 是 Write 和 Read 任一，所以共用它们的一些属性。
+  - `allIdleTimeNanos` 属性，配置的All( 读或写任一 )，单位：纳秒。
+
+## 5.2 initialize
+
+`#initialize(ChannelHandlerContext ctx)` 方法，初始化 IdleStateHandler 。代码如下：
+
+```
+ 1: private void initialize(ChannelHandlerContext ctx) {
+ 2:     // 校验状态，避免因为 `#destroy()` 方法在 `#initialize(ChannelHandlerContext ctx)` 方法，执行之前
+ 3:     // Avoid the case where destroy() is called before scheduling timeouts.
+ 4:     // See: https://github.com/netty/netty/issues/143
+ 5:     switch (state) {
+ 6:     case 1:
+ 7:     case 2:
+ 8:         return;
+ 9:     }
+10: 
+11:     // 标记为已初始化
+12:     state = 1;
+13:     // 初始化 ChannelOutboundBuffer 相关属性
+14:     initOutputChanged(ctx);
+15: 
+16:     // 初始相应的定时任务
+17:     lastReadTime = lastWriteTime = ticksInNanos();
+18:     if (readerIdleTimeNanos > 0) {
+19:         readerIdleTimeout = schedule(ctx, new ReaderIdleTimeoutTask(ctx), readerIdleTimeNanos, TimeUnit.NANOSECONDS);
+20:     }
+21:     if (writerIdleTimeNanos > 0) {
+22:         writerIdleTimeout = schedule(ctx, new WriterIdleTimeoutTask(ctx), writerIdleTimeNanos, TimeUnit.NANOSECONDS);
+23:     }
+24:     if (allIdleTimeNanos > 0) {
+25:         allIdleTimeout = schedule(ctx, new AllIdleTimeoutTask(ctx), allIdleTimeNanos, TimeUnit.NANOSECONDS);
+26:     }
+27: }
+```
+
+- 第 2 至 9 行：校验状态，避免因为 `#destroy()` 方法在 `#initialize(ChannelHandlerContext ctx)` 方法，执行之前。
+
+- 第 12 行：标记 `state` 为已初始化。
+
+- 第 14 行：调用 `#initOutputChanged(ChannelHandlerContext ctx)` 方法，初始化 ChannelOutboundBuffer 相关属性。代码如下：
+
+  ```
+  private void initOutputChanged(ChannelHandlerContext ctx) {
+      if (observeOutput) {
+          Channel channel = ctx.channel();
+          Unsafe unsafe = channel.unsafe();
+          ChannelOutboundBuffer buf = unsafe.outboundBuffer();
+  
+          if (buf != null) {
+              // 记录第一条准备 flash 到对端的消息的 HashCode
+              lastMessageHashCode = System.identityHashCode(buf.current());
+              // 记录总共等待 flush 到对端的内存大小
+              lastPendingWriteBytes = buf.totalPendingWriteBytes();
+          }
+      }
+  }
+  ```
+
+  - 初始化 `lastMessageHashCode` 和 `lastPendingWriteBytes` 属性。
+
+- 第 17 至 26 行：根据配置，分别调用 `#schedule(hannelHandlerContext ctx, Runnable task, long delay, TimeUnit unit)` 方法，初始相应的定时任务。代码如下：
+
+  ```
+  ScheduledFuture<?> schedule(ChannelHandlerContext ctx, Runnable task, long delay, TimeUnit unit) {
+      return ctx.executor().schedule(task, delay, unit);
+  }
+  ```
+
+- 一共有 ReaderIdleTimeoutTask、WriterIdleTimeoutTask、AllIdleTimeoutTask 三种任务，下文我们详细解析。
+
+------
+
+该方法，会在多个 Channel **事件**中被调用。代码如下：
+
+```
+// <2>
+@Override
+public void handlerAdded(ChannelHandlerContext ctx) throws Exception {
+    if (ctx.channel().isActive() && ctx.channel().isRegistered()) {
+        // 初始化
+        // channelActive() event has been fired already, which means this.channelActive() will
+        // not be invoked. We have to initialize here instead.
+        initialize(ctx);
+    } else {
+        // channelActive() event has not been fired yet.  this.channelActive() will be invoked
+        // and initialization will occur there.
+    }
+}
+
+// <3>
+@Override
+public void channelRegistered(ChannelHandlerContext ctx) throws Exception {
+    // 初始化
+    // Initialize early if channel is active already.
+    if (ctx.channel().isActive()) {
+        initialize(ctx);
+    }
+    // 继续传播 Channel Registered 事件到下一个节点
+    super.channelRegistered(ctx);
+}
+
+// <1>
+@Override
+public void channelActive(ChannelHandlerContext ctx) throws Exception {
+    // 初始化
+    // This method will be invoked only if this handler was added
+    // before channelActive() event is fired.  If a user adds this handler
+    // after the channelActive() event, initialize() will be called by beforeAdd().
+    initialize(ctx);
+    // 继续传播 Channel Registered 事件到下一个节点
+    super.channelActive(ctx);
+}
+```
+
+- `<1>` ：当客户端与服务端成功建立连接后，Channel 被激活，此时 channelActive 方法，的初始化被调用。
+- `<2>` ：当 Channel 被激活后，动态添加此 Handler ，则 handlerAdded 方法的初始化被调用。
+- `<3>` ：当 Channel 被激活后，用户主动切换 Channel 的所在的 EventLoop ，则 channelRegistered 方法的初始化被调用。
+
+## 5.3 destroy
+
+`#destroy()` 方法，销毁 IdleStateHandler 。代码如下：
+
+```
+private void destroy() {
+    // 标记为销毁
+    state = 2;
+
+    // 销毁相应的定时任务
+    if (readerIdleTimeout != null) {
+        readerIdleTimeout.cancel(false);
+        readerIdleTimeout = null;
+    }
+    if (writerIdleTimeout != null) {
+        writerIdleTimeout.cancel(false);
+        writerIdleTimeout = null;
+    }
+    if (allIdleTimeout != null) {
+        allIdleTimeout.cancel(false);
+        allIdleTimeout = null;
+    }
+}
+```
+
+- 标记 `state` 为已销毁。
+- 销毁响应的定时任务。
+
+------
+
+该方法，会在多个 Channel **事件**中被调用。代码如下：
+
+```
+@Override
+public void handlerRemoved(ChannelHandlerContext ctx) throws Exception {
+    // 销毁
+    destroy();
+}
+
+@Override
+public void channelInactive(ChannelHandlerContext ctx) throws Exception {
+    // 销毁
+    destroy();
+    // 继续传播 Channel Incative 事件到下一个节点
+    super.channelInactive(ctx);
+}
+```
+
+## 5.4 channelIdle
+
+在定时任务中，如果检测到**空闲**：
+
+① 首先，调用 `#newIdleStateEvent(IdleState state, boolean first)` 方法，创建对应的空闲事件。代码如下：
+
+```
+protected IdleStateEvent newIdleStateEvent(IdleState state, boolean first) {
+    switch (state) {
+        case ALL_IDLE:
+            return first ? IdleStateEvent.FIRST_ALL_IDLE_STATE_EVENT : IdleStateEvent.ALL_IDLE_STATE_EVENT;
+        case READER_IDLE:
+            return first ? IdleStateEvent.FIRST_READER_IDLE_STATE_EVENT : IdleStateEvent.READER_IDLE_STATE_EVENT;
+        case WRITER_IDLE:
+            return first ? IdleStateEvent.FIRST_WRITER_IDLE_STATE_EVENT : IdleStateEvent.WRITER_IDLE_STATE_EVENT;
+        default:
+            throw new IllegalArgumentException("Unhandled: state=" + state + ", first=" + first);
+    }
+}
+```
+
+② 然后，调用 `#channelIdle(ChannelHandlerContext ctx, IdleStateEvent evt)` 方法，在 pipeline 中，触发 UserEvent 事件。代码如下：
+
+```
+/**
+ * Is called when an {@link IdleStateEvent} should be fired. This implementation calls
+ * {@link ChannelHandlerContext#fireUserEventTriggered(Object)}.
+ */
+protected void channelIdle(ChannelHandlerContext ctx, IdleStateEvent evt) throws Exception {
+    ctx.fireUserEventTriggered(evt);
+}
+```
+
+## 5.5 channelRead
+
+`#channelRead(ChannelHandlerContext ctx, Object msg)` 方法，代码如下：
+
+```
+@Override
+public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
+    // 开启了 read 或 all 的空闲检测
+    if (readerIdleTimeNanos > 0 || allIdleTimeNanos > 0) {
+        // 标记正在读取
+        reading = true;
+        // 重置 firstWriterIdleEvent 和 firstAllIdleEvent 为 true
+        firstReaderIdleEvent = firstAllIdleEvent = true;
+    }
+    // 继续传播 Channel Read 事件到下一个节点
+    ctx.fireChannelRead(msg);
+}
+```
+
+在开启 read 或 all 的空闲检测的情况下，在【继续传播 Channel Read 事件到下一个节点】**之前**，会：
+
+- 标记 `reading` 为正在读取。
+- 重置 `firstWriterIdleEvent` 和 `firstAllIdleEvent` 为 `true` ，即又变成**首次**。
+
+------
+
+那么什么时候记录 `lastReadTime` 最后读取时间呢？答案在 `#channelReadComplete(ChannelHandlerContext ctx)` 方法中。代码如下：
+
+```
+@Override
+public void channelReadComplete(ChannelHandlerContext ctx) throws Exception {
+    // 开启了 read 或 all 的空闲检测
+    if ((readerIdleTimeNanos > 0 || allIdleTimeNanos > 0) && reading) {
+        // 记录最后读时间
+        lastReadTime = ticksInNanos();
+        // 标记不在读取
+        reading = false;
+    }
+    // 继续传播 Channel ReadComplete 事件到下一个节点
+    ctx.fireChannelReadComplete();
+}
+```
+
+在开启 read 或 all 的空闲检测的情况下，在【继续传播 Channel ReadComplete 事件到下一个节点】**之前**，会：
+
+- 记录 `lastReadTime` 最后读取时间为 `#ticksInNanos()` 方法，代码如下：
+
+  ```
+  long ticksInNanos() {
+      return System.nanoTime();
+  }
+  ```
+
+  - 当前时间，单位：纳秒。
+
+- 标记 `reading` 为不在读取。
+
+## 5.6 write
+
+`#write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise)` 方法，代码如下：
+
+```
+@Override
+public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) throws Exception {
+    // 开启了 write 或 all 的空闲检测
+    // Allow writing with void promise if handler is only configured for read timeout events.
+    if (writerIdleTimeNanos > 0 || allIdleTimeNanos > 0) {
+        // 写入，并添加写入监听器
+        ctx.write(msg, promise.unvoid()).addListener(writeListener);
+    } else {
+        // 写入，不添加监听器
+        ctx.write(msg, promise);
+    }
+}
+```
+
+在开启 write 或 all 的空闲检测的情况下，写入的时候，会添加写入监听器 `writeListener` 。该监听器会在消息( 数据 ) flush 到对端后，**回调**，修改最后写入时间 `lastWriteTime` 为 `#ticksInNanos()` 。代码如下：
+
+```
+// Not create a new ChannelFutureListener per write operation to reduce GC pressure.
+private final ChannelFutureListener writeListener = new ChannelFutureListener() {
+
+    @Override
+    public void operationComplete(ChannelFuture future) throws Exception {
+        // 记录最后写时间
+        lastWriteTime = ticksInNanos();
+        // 重置 firstWriterIdleEvent 和 firstAllIdleEvent 为 true
+        firstWriterIdleEvent = firstAllIdleEvent = true;
+    }
+
+}
+```
+
+## 5.7 hasOutputChanged
+
+> 老艿艿：关于这个方法，看完 [「5.8.2 WriterIdelTimeoutTask」](https://svip.iocoder.cn/Netty/ChannelHandler-5-idle/#) 后，再回过头理解。
+
+`#hasOutputChanged(ChannelHandlerContext ctx, boolean first)` 方法，判断 ChannelOutboundBuffer 是否发生变化。代码如下：
+
+```
+   /**
+    * Returns {@code true} if and only if the {@link IdleStateHandler} was constructed
+    * with {@link #observeOutput} enabled and there has been an observed change in the
+    * {@link ChannelOutboundBuffer} between two consecutive calls of this method.
+    *
+    * https://github.com/netty/netty/issues/6150
+    */
+ 1: private boolean hasOutputChanged(ChannelHandlerContext ctx, boolean first) {
+ 2:     // 开启观察 ChannelOutboundBuffer 队列
+ 3:     if (observeOutput) {
+ 4: 
+ 5:         // We can take this shortcut if the ChannelPromises that got passed into write()
+ 6:         // appear to complete. It indicates "change" on message level and we simply assume
+ 7:         // that there's change happening on byte level. If the user doesn't observe channel
+ 8:         // writability events then they'll eventually OOME and there's clearly a different
+ 9:         // problem and idleness is least of their concerns.
+10:         // 如果 lastChangeCheckTimeStamp 和 lastWriteTime 不一样，说明写操作进行过了，则更新此值
+11:         if (lastChangeCheckTimeStamp != lastWriteTime) {
+12:             lastChangeCheckTimeStamp = lastWriteTime;
+13: 
+14:             // But this applies only if it's the non-first call.
+15:             if (!first) { // 非首次
+16:                 return true;
+17:             }
+18:         }
+19: 
+20:         Channel channel = ctx.channel();
+21:         Unsafe unsafe = channel.unsafe();
+22:         ChannelOutboundBuffer buf = unsafe.outboundBuffer();
+23: 
+24:         if (buf != null) {
+25:             // 获得新的 messageHashCode 和 pendingWriteBytes
+26:             int messageHashCode = System.identityHashCode(buf.current());
+27:             long pendingWriteBytes = buf.totalPendingWriteBytes();
+28: 
+29:             // 发生了变化
+30:             if (messageHashCode != lastMessageHashCode || pendingWriteBytes != lastPendingWriteBytes) {
+31:                 // 修改最后一次的 lastMessageHashCode 和 lastPendingWriteBytes
+32:                 lastMessageHashCode = messageHashCode;
+33:                 lastPendingWriteBytes = pendingWriteBytes;
+34: 
+35:                 if (!first) { // 非首次
+36:                     return true;
+37:                 }
+38:             }
+39:         }
+40:     }
+41: 
+42:     return false;
+43: }
+```
+
+- 第 3 行：判断开启观察 ChannelOutboundBuffer 队列。
+
+  - 如果 `lastChangeCheckTimeStamp` 和 `lastWriteTime` 不一样，说明写操作进行过了，则更新此值。
+  - 第 14 至 17 行：这段逻辑，理论来说不会发生。因为 `lastWriteTime` 属性，只会在 `writeListener` 回调中修改，那么如果发生 `lastChangeCheckTimeStamp` 和 `lastWriteTime` 不相等，`first` 必然为 `true` 。因为，Channel 相关的事件逻辑，都在它所在的 EventLoop 中，不会出现并发的情况。关于这一块，基友【莫那一鲁道】在 https://github.com/netty/netty/issues/8251 已经进行提问，坐等结果。
+
+- 第 25 至 27 行：获得新的 `messageHashCode` 和 `pendingWriteBytes` 的。
+
+- 第 29 至 33 行：若发生了变化，则修改最后一次的
+
+   
+
+  ```
+  lastMessageHashCode
+  ```
+
+   
+
+  和
+
+   
+
+  ```
+  lastPendingWriteBytes
+  ```
+
+   
+
+  。
+
+  - `messageHashCode != lastMessageHashCode` 成立，① 有可能对端接收数据比较慢，导致一个消息发送了一部分；② 又或者，发送的消息**非常非常非常大**，导致一个消息发送了一部分，就将发送缓存区写满。如果是这种情况下，可以使用 ChunkedWriteHandler ，一条大消息，拆成多条小消息。
+  - `pendingWriteBytes != lastPendingWriteBytes` 成立，① 有新的消息，写到 ChannelOutboundBuffer 内存队列中；② 有几条消息成功写到对端。这种情况，此处不会发生。
+
+- 第 35 至 37 行：当且仅当
+
+   
+
+  ```
+  first
+  ```
+
+   
+
+  为
+
+   
+
+  ```
+  true
+  ```
+
+   
+
+  时，即非首次，才返回
+
+   
+
+  ```
+  true
+  ```
+
+   
+
+  ，表示 ChannelOutboundBuffer 发生变化。
+
+  - 这是一个有点“神奇”的设定，笔者表示不太理解。理论来说，ChannelOutboundBuffer 是否发生变化，只需要考虑【第 30 行】代码的判断。如果加了 `!first` 的判断，导致的结果是在 WriterIdleTimeoutTask 和 AllIdleTimeoutTask 任务中，ChannelOutboundBuffer 即使发生了变化，在**首次**还是会触发 write 和 all 空闲事件，在**非首次**不会触发 write 和 all 空闲事件。
+  - 关于上述的困惑，[《Netty 那些事儿 ——— 关于 “Netty 发送大数据包时 触发写空闲超时” 的一些思考》](https://www.jianshu.com/p/8fe70d313d78) 一文的作者，也表达了相同的困惑。后续，找闪电侠面基沟通下。
+  - 关于上述的困惑，[《Netty 心跳服务之 IdleStateHandler 源码分析》](https://www.jianshu.com/p/f2ed73cf4df8) 一文的作者，表达了自己的理解。感兴趣的胖友，可以看看。
+  - 当然，这块如果不理解的胖友，也不要方。从笔者目前了解下来，`observeOutput` 都是设置为 `false` 。也就说，不会触发这个方法的执行。
+
+- 第 42 行：返回 `false` ，表示 ChannelOutboundBuffer 未发生变化。
+
+## 5.8 AbstractIdleTask
+
+AbstractIdleTask ，实现 Runnable 接口，空闲任务抽象类。代码如下：
+
+> AbstractIdleTask 是 IdleStateHandler 的内部静态类。
+
+```
+private abstract static class AbstractIdleTask implements Runnable {
+
+    private final ChannelHandlerContext ctx;
+
+    AbstractIdleTask(ChannelHandlerContext ctx) {
+        this.ctx = ctx;
+    }
+
+    @Override
+    public void run() {
+        // <1> 忽略未打开的 Channel
+        if (!ctx.channel().isOpen()) {
+            return;
+        }
+
+        // <2> 执行任务
+        run(ctx);
+    }
+
+    protected abstract void run(ChannelHandlerContext ctx);
+
+}
+```
+
+- `<1>` 处，忽略未打开的 Channel 。
+- `<2>` 处，子类实现 `#run()` **抽象**方法，实现自定义的空闲检测逻辑。
+
+### 5.8.1 ReaderIdleTimeoutTask
+
+ReaderIdleTimeoutTask ，继承 AbstractIdleTask 抽象类，检测 Read 空闲超时**定时**任务。代码如下：
+
+> ReaderIdleTimeoutTask 是 IdleStateHandler 的内部静态类。
+
+```
+ 1: private final class ReaderIdleTimeoutTask extends AbstractIdleTask {
+ 2: 
+ 3:     ReaderIdleTimeoutTask(ChannelHandlerContext ctx) {
+ 4:         super(ctx);
+ 5:     }
+ 6: 
+ 7:     @Override
+ 8:     protected void run(ChannelHandlerContext ctx) {
+ 9:         // 计算下一次检测的定时任务的延迟
+10:         long nextDelay = readerIdleTimeNanos;
+11:         if (!reading) {
+12:             nextDelay -= ticksInNanos() - lastReadTime;
+13:         }
+14: 
+15:         // 如果小于等于 0 ，说明检测到读空闲
+16:         if (nextDelay <= 0) {
+17:             // 延迟时间为 readerIdleTimeNanos ，即再次检测
+18:             // Reader is idle - set a new timeout and notify the callback.
+19:             readerIdleTimeout = schedule(ctx, this, readerIdleTimeNanos, TimeUnit.NANOSECONDS);
+20: 
+21:             // 获得当前是否首次检测到读空闲
+22:             boolean first = firstReaderIdleEvent;
+23:             // 标记 firstReaderIdleEvent 为 false 。也就说，下次检测到空闲，就非首次了。
+24:             firstReaderIdleEvent = false;
+25: 
+26:             try {
+27:                 // 创建读空闲事件
+28:                 IdleStateEvent event = newIdleStateEvent(IdleState.READER_IDLE, first);
+29:                 // 通知通道空闲事件
+30:                 channelIdle(ctx, event);
+31:             } catch (Throwable t) {
+32:                 // 触发 Exception Caught 到下一个节点
+33:                 ctx.fireExceptionCaught(t);
+34:             }
+35:         // 如果大于 0 ，说明未检测到读空闲
+36:         } else {
+37:             // 延迟时间为 nextDelay ，即按照最后一次读的时间作为开始计数
+38:             // Read occurred before the timeout - set a new timeout with shorter delay.
+39:             readerIdleTimeout = schedule(ctx, this, nextDelay, TimeUnit.NANOSECONDS);
+40:         }
+41:     }
+42: }
+```
+
+- 第 9 至 13 行：计算下一次检测的定时任务的
+
+  延迟
+
+  。
+
+  - `reading` 为 `true` 时，意味着正在读取，**不会**被检测为读空闲。
+  - `reading` 为 `false` 时，实际 `nextDelay` 的计算为 `readerIdleTimeNanos - (ticksInNanos() - lastReadTime)` 。如果小于等于 0 ，意味着 `ticksInNanos() - lastReadTime >= readerIdleTimeNanos` ，超时。
+
+- ① 第 35 至 40 行：如果
+
+  大于
+
+   
+
+  0 ，说明未检测到读空闲。
+
+  - 第 39 行：调用 `#schedule(ChannelHandlerContext ctx, Runnable task, long delay, TimeUnit unit)` 方法，初始**下一次**的 ReaderIdleTimeoutTask 定时任务。其中，延迟时间为 `nextDelay` ，即按照最后一次读的时间作为开始计数。
+
+- ② 第 15 至 34 行：如果
+
+  小于等于
+
+   
+
+  0 ，说明检测到读空闲。
+
+  - 第 19 行：调用 `#schedule(ChannelHandlerContext ctx, Runnable task, long delay, TimeUnit unit)` 方法，初始**下一次**的 ReaderIdleTimeoutTask 定时任务。其中，延迟时间为 `readerIdleTimeNanos` ，即重新计数。
+
+  - 第 21 行：获得当前是否首次检测到读空闲。
+
+    - 第 24 行：标记 `firstReaderIdleEvent` 为 `false` 。也就说，下次检测到空闲，就**非首次**了。
+
+  - 第 28 行：调用
+
+     
+
+    ```
+    #newIdleStateEvent(IdleState state, boolean first)
+    ```
+
+     
+
+    方法，创建创建
+
+    读
+
+    空闲事件。
+
+    - 第 30 行： 调用 `#channelIdle(ChannelHandlerContext ctx, IdleStateEvent evt)` 方法，在 pipeline 中，触发 UserEvent 事件。
+
+  - 第 31 至 34 行：如果**发生异常**，触发 Exception Caught 事件到下一个节点，处理异常。
+
+### 5.8.2 WriterIdleTimeoutTask
+
+WriterIdleTimeoutTask ，继承 AbstractIdleTask 抽象类，检测 Write 空闲超时**定时**任务。代码如下：
+
+> WriterIdleTimeoutTask 是 IdleStateHandler 的内部静态类。
+
+```
+ 1: private final class WriterIdleTimeoutTask extends AbstractIdleTask {
+ 2: 
+ 3:     WriterIdleTimeoutTask(ChannelHandlerContext ctx) {
+ 4:         super(ctx);
+ 5:     }
+ 6: 
+ 7:     @Override
+ 8:     protected void run(ChannelHandlerContext ctx) {
+ 9:         // 计算下一次检测的定时任务的延迟
+10:         long lastWriteTime = IdleStateHandler.this.lastWriteTime;
+11:         long nextDelay = writerIdleTimeNanos - (ticksInNanos() - lastWriteTime);
+12: 
+13:         // 如果小于等于 0 ，说明检测到写空闲
+14:         if (nextDelay <= 0) {
+15:             // 延迟时间为 writerIdleTimeout ，即再次检测
+16:             // Writer is idle - set a new timeout and notify the callback.
+17:             writerIdleTimeout = schedule(ctx, this, writerIdleTimeNanos, TimeUnit.NANOSECONDS);
+18: 
+19:             // 获得当前是否首次检测到写空闲
+20:             boolean first = firstWriterIdleEvent;
+21:             // 标记 firstWriterIdleEvent 为 false 。也就说，下次检测到空闲，就非首次了。
+22:             firstWriterIdleEvent = false;
+23: 
+24:             try {
+25:                 // 判断 ChannelOutboundBuffer 是否发生变化
+26:                 if (hasOutputChanged(ctx, first)) {
+27:                     return;
+28:                 }
+29: 
+30:                 // 创建写空闲事件
+31:                 IdleStateEvent event = newIdleStateEvent(IdleState.WRITER_IDLE, first);
+32:                 // 通知通道空闲事件
+33:                 channelIdle(ctx, event);
+34:             } catch (Throwable t) {
+35:                 // 触发 Exception Caught 到下一个节点
+36:                 ctx.fireExceptionCaught(t);
+37:             }
+38:         // 如果大于 0 ，说明未检测到读空闲
+39:         } else {
+40:             // Write occurred before the timeout - set a new timeout with shorter delay.
+41:             writerIdleTimeout = schedule(ctx, this, nextDelay, TimeUnit.NANOSECONDS);
+42:         }
+43:     }
+44: }
+```
+
+- 第 9 至 11 行：计算下一次检测的定时任务的**延迟**。
+
+- ① 第 38 至 42 行：如果
+
+  大于
+
+   
+
+  0 ，说明未检测到写空闲。
+
+  - 第 39 行：调用 `#schedule(ChannelHandlerContext ctx, Runnable task, long delay, TimeUnit unit)` 方法，初始**下一次**的 WriterIdleTimeoutTask 定时任务。其中，延迟时间为 `nextDelay` ，即按照最后一次写的时间作为开始计数。
+
+- ② 第 13 至 37 行：如果
+
+  小于等于
+
+   
+
+  0 ，说明检测到写空闲。
+
+  - 第 17 行：调用 `#schedule(ChannelHandlerContext ctx, Runnable task, long delay, TimeUnit unit)` 方法，初始**下一次**的 WriterIdleTimeoutTask 定时任务。其中，延迟时间为 `readerIdleTimeNanos` ，即重新计数。
+
+  - 第 20 行：获得当前是否首次检测到写空闲。
+
+    - 第 22 行：标记 `firstWriterIdleEvent` 为 `false` 。也就说，下次检测到空闲，就**非首次**了。
+
+  - 第 25 至 28 行：判断 ChannelOutboundBuffer 是否发生变化。如果有变化，不触发写空闲时间。
+
+  - 第 31 行：调用
+
+     
+
+    ```
+    #newIdleStateEvent(IdleState state, boolean first)
+    ```
+
+     
+
+    方法，创建创建
+
+    写
+
+    空闲事件。
+
+    - 第 33 行： 调用 `#channelIdle(ChannelHandlerContext ctx, IdleStateEvent evt)` 方法，在 pipeline 中，触发 UserEvent 事件。
+
+  - 第 34 至 37 行：如果**发生异常**，触发 Exception Caught 事件到下一个节点，处理异常。
+
+### 5.8.3 AllIdleTimeoutTask
+
+AllIdleTimeoutTask ，继承 AbstractIdleTask 抽象类，检测 All 空闲超时**定时**任务。代码如下：
+
+> AllIdleTimeoutTask 是 IdleStateHandler 的内部静态类。
+
+```
+private final class AllIdleTimeoutTask extends AbstractIdleTask {
+
+    AllIdleTimeoutTask(ChannelHandlerContext ctx) {
+        super(ctx);
+    }
+
+    @Override
+    protected void run(ChannelHandlerContext ctx) {
+        // 计算下一次检测的定时任务的延迟
+        long nextDelay = allIdleTimeNanos;
+        if (!reading) {
+            nextDelay -= ticksInNanos() - Math.max(lastReadTime, lastWriteTime); // <1> 取大值
+        }
+
+        // 如果小于等于 0 ，说明检测到 all 空闲
+        if (nextDelay <= 0) {
+            // 延迟时间为 allIdleTimeNanos ，即再次检测
+            // Both reader and writer are idle - set a new timeout and
+            // notify the callback.
+            allIdleTimeout = schedule(ctx, this, allIdleTimeNanos, TimeUnit.NANOSECONDS);
+
+            // 获得当前是否首次检测到 all 空闲
+            boolean first = firstAllIdleEvent;
+            // 标记 firstAllIdleEvent 为 false 。也就说，下次检测到空闲，就非首次了。
+            firstAllIdleEvent = false;
+
+            try {
+                // 判断 ChannelOutboundBuffer 是否发生变化
+                if (hasOutputChanged(ctx, first)) {
+                    return;
+                }
+
+                // 创建 all 空闲事件
+                IdleStateEvent event = newIdleStateEvent(IdleState.ALL_IDLE, first);
+                // 通知通道空闲事件
+                channelIdle(ctx, event);
+            } catch (Throwable t) {
+                ctx.fireExceptionCaught(t);
+            }
+        // 如果大于 0 ，说明未检测到 all 空闲
+        } else {
+            // Either read or write occurred before the timeout - set a new
+            // timeout with shorter delay.
+            allIdleTimeout = schedule(ctx, this, nextDelay, TimeUnit.NANOSECONDS);
+        }
+    }
+}
+```
+
+- 因为 All 是 Write 和 Read **任一**一种空闲即可，所以 AllIdleTimeoutTask 是 ReaderIdleTimeoutTask 和 WriterIdleTimeoutTask 的**综合**。
+- `<1>` 处，取 `lastReadTime` 和 `lastWriteTime` 中的**大**值，从而来判断，是否有 Write 和 Read **任一**一种空闲。
+- WriterIdleTimeoutTask 就不详细解析，胖友自己读读代码即可。
+
+# 6. ReadTimeoutHandler
+
+`io.netty.handler.timeout.ReadTimeoutHandler` ，继承 IdleStateHandler 类，当 Channel 的**读**空闲时间( 读或者写 )太长时，抛出 ReadTimeoutException 异常，并自动关闭该 Channel 。
+
+## 6.1 构造方法
+
+```
+/**
+ * Channel 是否关闭
+ */
+private boolean closed;
+
+public ReadTimeoutHandler(int timeoutSeconds) {
+    this(timeoutSeconds, TimeUnit.SECONDS);
+}
+
+public ReadTimeoutHandler(long timeout, TimeUnit unit) {
+    // 禁用 Write / All 的空闲检测
+    super(timeout, 0, 0, unit); // <1>
+}
+```
+
+- `closed` 属性，Channel 是否关闭。
+- `<1>` 处，禁用 Write / All 的空闲检测，只根据 `timeout` 方法参数，开启 Read 的空闲检测。
+
+## 6.2 channelIdle
+
+`#channelIdle(ChannelHandlerContext ctx, IdleStateEvent evt)` 方法，覆写父类方法，代码如下：
+
+```
+@Override
+protected final void channelIdle(ChannelHandlerContext ctx, IdleStateEvent evt) throws Exception {
+    assert evt.state() == IdleState.READER_IDLE;
+    readTimedOut(ctx);
+}
+
+/**
+ * Is called when a read timeout was detected.
+ */
+protected void readTimedOut(ChannelHandlerContext ctx) throws Exception {
+    if (!closed) {
+        // <1> 触发 Exception Caught 事件到 pipeline 中，异常为 ReadTimeoutException
+        ctx.fireExceptionCaught(ReadTimeoutException.INSTANCE);
+        // <2> 关闭 Channel 通道
+        ctx.close();
+        // <3> 标记 Channel 为已关闭
+        closed = true;
+    }
+}
+```
+
+- `<1>` 处，触发 Exception Caught 事件到 pipeline 中，异常为 ReadTimeoutException 。
+- `<2>` 处，关闭 Channel 通道。
+- `<3>` 处，标记 Channel 为已关闭。
+
+# 7. WriteTimeoutHandler
+
+`io.netty.handler.timeout.WriteTimeoutHandler` ，继承 ChannelOutboundHandlerAdapter 类，当一个**写**操作不能在指定时间内完成时，抛出 WriteTimeoutException 异常，并自动关闭对应 Channel 。
+
+😈 **注意，这里写入，指的是 flush 到对端 Channel ，而不仅仅是写到 ChannelOutboundBuffer 队列**。
+
+## 7.1 构造方法
+
+```
+/**
+ * 最小的超时时间，单位：纳秒
+ */
+private static final long MIN_TIMEOUT_NANOS = TimeUnit.MILLISECONDS.toNanos(1);
+
+/**
+ * 超时时间，单位：纳秒
+ */
+private final long timeoutNanos;
+
+/**
+ * WriteTimeoutTask 双向链表。
+ *
+ * lastTask 为链表的尾节点
+ *
+ * A doubly-linked list to track all WriteTimeoutTasks
+ */
+private WriteTimeoutTask lastTask;
+
+/**
+ * Channel 是否关闭
+ */
+private boolean closed;
+
+public WriteTimeoutHandler(int timeoutSeconds) {
+    this(timeoutSeconds, TimeUnit.SECONDS);
+}
+
+public WriteTimeoutHandler(long timeout, TimeUnit unit) {
+    if (unit == null) {
+        throw new NullPointerException("unit");
+    }
+
+    if (timeout <= 0) {
+        timeoutNanos = 0;
+    } else {
+        timeoutNanos = Math.max(unit.toNanos(timeout), MIN_TIMEOUT_NANOS); // 保证大于等于 MIN_TIMEOUT_NANOS
+    }
+}
+```
+
+- ```
+  timeoutNanos
+  ```
+
+   
+
+  属性，写入超时时间，单位：纳秒。
+
+  - `MIN_TIMEOUT_NANOS` 属性，最小的超时时间，单位：纳秒。
+
+- `lastTask` 属性，WriteTimeoutTask 双向链表。其中，`lastTask` 为链表的**尾节点**。
+
+- `closed` 属性，Channel 是否关闭。
+
+## 7.2 handlerRemoved
+
+`#handlerRemoved(ChannelHandlerContext ctx)` 方法，移除所有 WriteTimeoutTask 任务，并取消。代码如下：
+
+```
+@Override
+public void handlerRemoved(ChannelHandlerContext ctx) throws Exception {
+    WriteTimeoutTask task = lastTask;
+    // 置空 lastTask
+    lastTask = null;
+    // 循环移除，知道为空
+    while (task != null) {
+        // 取消当前任务的定时任务
+        task.scheduledFuture.cancel(false);
+        // 记录前一个任务
+        WriteTimeoutTask prev = task.prev;
+        // 置空当前任务的前后节点
+        task.prev = null;
+        task.next = null;
+        // 跳到前一个任务
+        task = prev;
+    }
+}
+```
+
+- 代码比较简单，胖友自己看注释。
+
+## 7.3 write
+
+`#write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise)` 方法，代码如下：
+
+```
+@Override
+public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) throws Exception {
+    if (timeoutNanos > 0) {
+        // 如果 promise 是 VoidPromise ，则包装成非 VoidPromise ，为了后续的回调。
+        promise = promise.unvoid(); <1》
+        // 创建定时任务
+        scheduleTimeout(ctx, promise);
+    }
+    // 写入
+    ctx.write(msg, promise);
+}
+```
+
+- `<1>` 处，如果 `promise` 类型是 VoidPromise ，则包装成非 VoidPromise ，为了后续的回调。因为 VoidPromise 无法接收到回调。
+- `<2>` 处，调用 `#scheduleTimeout(final ChannelHandlerContext ctx, final ChannelPromise promise)` 方法，创建定时任务。详细解析，见 [「7.4 scheduleTimeout」](https://svip.iocoder.cn/Netty/ChannelHandler-5-idle/#) 。
+
+## 7.4 scheduleTimeout
+
+`#scheduleTimeout(final ChannelHandlerContext ctx, final ChannelPromise promise)` 方法，创建定时任务。代码如下：
+
+```
+ 1: private void scheduleTimeout(final ChannelHandlerContext ctx, final ChannelPromise promise) {
+ 2:     // Schedule a timeout.
+ 3:     // 创建 WriteTimeoutTask 任务
+ 4:     final WriteTimeoutTask task = new WriteTimeoutTask(ctx, promise);
+ 5:     // 定时任务
+ 6:     task.scheduledFuture = ctx.executor().schedule(task, timeoutNanos, TimeUnit.NANOSECONDS);
+ 7: 
+ 8:     if (!task.scheduledFuture.isDone()) {
+ 9:         // 添加到链表
+10:         addWriteTimeoutTask(task);
+11: 
+12:         // Cancel the scheduled timeout if the flush promise is complete.
+13:         // 将 task 作为监听器，添加到 promise 中。在写入完成后，可以移除该定时任务
+14:         promise.addListener(task);
+15:     }
+16: }
+```
+
+- 第 2 至 6 行：创建 WriteTimeoutTask 任务，并发起**定时任务**。
+- 第 8 行：如果定时任务**已经执行完成**，则不需要进行监听。否则，需要执行【第 10 至 14 行】的代码逻辑。
+- 第 10 行：调用 `#addWriteTimeoutTask(WriteTimeoutTask task)` 方法，添加到链表。详细解析，见 [「7.5 addWriteTimeoutTask」](https://svip.iocoder.cn/Netty/ChannelHandler-5-idle/#) 。
+- 第 14 行：将 `task` 作为监听器，添加到 `promise` 中。在写入完成后，可以移除该定时任务。也就说，调用链是 `flush => 回调 => promise => 回调 => task` 。
+
+## 7.5 addWriteTimeoutTask
+
+`#addWriteTimeoutTask(WriteTimeoutTask task)` 方法，添加到链表。代码如下：
+
+```
+private void addWriteTimeoutTask(WriteTimeoutTask task) {
+    // 添加到链表的尾节点
+    if (lastTask != null) {
+        lastTask.next = task;
+        task.prev = lastTask;
+    }
+    // 修改 lastTask 为当前任务
+    lastTask = task;
+}
+```
+
+添加到链表的尾节点，并修改 `lastTask` 为**当前**任务。
+
+## 7.6 removeWriteTimeoutTask
+
+`#removeWriteTimeoutTask(WriteTimeoutTask task)` 方法，移除出链表。代码如下：
+
+```
+private void removeWriteTimeoutTask(WriteTimeoutTask task) {
+    // 从双向链表中，移除自己
+    if (task == lastTask) { // 尾节点
+        // task is the tail of list
+        assert task.next == null;
+        lastTask = lastTask.prev;
+        if (lastTask != null) {
+            lastTask.next = null;
+        }
+    } else if (task.prev == null && task.next == null) { // 已经被移除
+        // Since task is not lastTask, then it has been removed or not been added.
+        return;
+    } else if (task.prev == null) { // 头节点
+        // task is the head of list and the list has at least 2 nodes
+        task.next.prev = null;
+    } else { // 中间的节点
+        task.prev.next = task.next;
+        task.next.prev = task.prev;
+    }
+    // 重置 task 前后节点为空
+    task.prev = null;
+    task.next = null;
+}
+```
+
+该方法的调用，在 [「7.8 WriteTimeoutTask」](https://svip.iocoder.cn/Netty/ChannelHandler-5-idle/#) 会看到。
+
+## 7.7 writeTimedOut
+
+`#writeTimedOut(ChannelHandlerContext ctx)` 方法，写入超时，关闭 Channel 通道。代码如下：
+
+```
+/**
+ * Is called when a write timeout was detected
+ */
+protected void writeTimedOut(ChannelHandlerContext ctx) throws Exception {
+    if (!closed) {
+        // 触发 Exception Caught 事件到 pipeline 中，异常为 WriteTimeoutException
+        ctx.fireExceptionCaught(WriteTimeoutException.INSTANCE);
+        // 关闭 Channel 通道
+        ctx.close();
+        // 标记 Channel 为已关闭
+        closed = true;
+    }
+}
+```
+
+- 和 `ReadTimeoutHandler#readTimeout(ChannelHandlerContext ctx)` 方法，基本类似。
+
+该方法的调用，在 [「7.8 WriteTimeoutTask」](https://svip.iocoder.cn/Netty/ChannelHandler-5-idle/#) 会看到。
+
+## 7.8 WriteTimeoutTask
+
+WriteTimeoutTask ，实现 Runnable 和 ChannelFutureListener 接口，写入超时任务。
+
+> WriteTimeoutTask 是 WriteTimeoutHandler 的内部类。
+
+### 7.8.1 构造方法
+
+```
+private final ChannelHandlerContext ctx;
+/**
+ * 写入任务的 Promise 对象
+ */
+private final ChannelPromise promise;
+
+// WriteTimeoutTask is also a node of a doubly-linked list
+/**
+ * 前一个 task
+ */
+WriteTimeoutTask prev;
+/**
+ * 后一个 task
+ */
+WriteTimeoutTask next;
+/**
+ * 定时任务
+ */
+ScheduledFuture<?> scheduledFuture;
+
+WriteTimeoutTask(ChannelHandlerContext ctx, ChannelPromise promise) {
+    this.ctx = ctx;
+    this.promise = promise;
+}
+```
+
+### 7.8.2 run
+
+当定时任务执行，说明写入任务执行超时。代码如下：
+
+```
+@Override
+public void run() {
+    // Was not written yet so issue a write timeout
+    // The promise itself will be failed with a ClosedChannelException once the close() was issued
+    // See https://github.com/netty/netty/issues/2159
+    if (!promise.isDone()) { // 未完成，说明写入超时
+        try {
+            // <1> 写入超时，关闭 Channel 通道
+            writeTimedOut(ctx);
+        } catch (Throwable t) {
+            // 触发 Exception Caught 事件到 pipeline 中
+            ctx.fireExceptionCaught(t);
+        }
+    }
+    // <2> 移除出链表
+    removeWriteTimeoutTask(this);
+}
+```
+
+- `<1>` 处，调用 `#writeTimedOut(ChannelHandlerContext ctx)` 方法，写入超时，关闭 Channel 通道。
+- `<2>` 处，调用 `#removeWriteTimeoutTask(WriteTimeoutTask task)` 方法，移除出链表。
+
+### 7.8.3 operationComplete
+
+当回调方法执行，说明写入任务执行完成。代码如下：
+
+```
+@Override
+public void operationComplete(ChannelFuture future) throws Exception {
+    // scheduledFuture has already be set when reaching here
+    // <1> 取消定时任务
+    scheduledFuture.cancel(false);
+    // <2> 移除出链表
+    removeWriteTimeoutTask(this);
+}
+```
+
+- `<1>` 处，取消定时任务。
+- `<2>` 处，调用 `#removeWriteTimeoutTask(WriteTimeoutTask task)` 方法，移除出链表。
+
+# 666. 彩蛋
+
+和 「5.7 hasOutputChanged」(#) 小节，这个方法较真了好久。感谢中间，基友【莫那一鲁道】的沟通。
+
+推荐阅读文章：
+
+- 莫那一鲁道 [《Netty 心跳服务之 IdleStateHandler 源码分析》](https://www.jianshu.com/p/f2ed73cf4df8)
+- Hypercube [自顶向下深入分析Netty（八）–ChannelHandler](https://www.jianshu.com/p/a9bcd89553f5)
\ No newline at end of file
diff --git a/netty/53-Netty 源码解析-ChannelHandler（六）之 AbstractTrafficShapingHandler.assets/jpeg.webp b/netty/53-Netty 源码解析-ChannelHandler（六）之 AbstractTrafficShapingHandler.assets/jpeg.webp
new file mode 100644
index 0000000..cf5c803
Binary files /dev/null and b/netty/53-Netty 源码解析-ChannelHandler（六）之 AbstractTrafficShapingHandler.assets/jpeg.webp differ
diff --git a/netty/53-Netty 源码解析-ChannelHandler（六）之 AbstractTrafficShapingHandler.md b/netty/53-Netty 源码解析-ChannelHandler（六）之 AbstractTrafficShapingHandler.md
new file mode 100644
index 0000000..1605d34
--- /dev/null
+++ b/netty/53-Netty 源码解析-ChannelHandler（六）之 AbstractTrafficShapingHandler.md	
@@ -0,0 +1,494 @@
+# 精尽 Netty 源码解析 —— ChannelHandler（六）之 AbstractTrafficShapingHandler
+
+笔者先把 Netty 主要的内容写完，所以关于 AbstractTrafficShapingHandler 的分享，先放在后续的计划里。
+
+当然，良心如我，还是为对这块感兴趣的胖友，先准备好了一篇不错的文章：
+
+- tomas家的小拨浪鼓 [《Netty 那些事儿 ——— Netty实现“流量整形”原理分析及实战》](https://www.jianshu.com/p/bea1b4ea8402)
+
+为避免可能 [《Netty 那些事儿 ——— Netty实现“流量整形”原理分析及实战》](https://www.jianshu.com/p/bea1b4ea8402) 被作者删除，笔者这里先复制一份作为备份。
+
+# 666. 备份
+
+> 本文是Netty文集中“Netty 那些事儿”系列的文章。主要结合在开发实战中，我们遇到的一些“奇奇怪怪”的问题，以及如何正确且更好的使用Netty框架，并会对Netty中涉及的重要设计理念进行介绍。
+
+### Netty实现“流量整形”原理分析
+
+##### 流量整形
+
+流量整形（Traffic Shaping）是一种主动调整流量输出速率的措施。流量整形与流量监管的主要区别在于，流量整形对流量监管中需要丢弃的报文进行缓存——通常是将它们放入缓冲区或队列内，也称流量整形（Traffic Shaping，简称TS）。当报文的发送速度过快时，首先在缓冲区进行缓存；再通过流量计量算法的控制下“均匀”地发送这些被缓冲的报文。流量整形与流量监管的另一区别是，整形可能会增加延迟，而监管几乎不引入额外的延迟。
+
+Netty提供了GlobalTrafficShapingHandler、ChannelTrafficShapingHandler、GlobalChannelTrafficShapingHandler三个类来实现流量整形，他们都是AbstractTrafficShapingHandler抽象类的实现类，下面我们就对其进行介绍，让我们来了解Netty是如何实现流量整形的。
+
+##### 核心类分析
+
+###### AbstractTrafficShapingHandler
+
+AbstractTrafficShapingHandler允许限制全局的带宽（见GlobalTrafficShapingHandler）或者每个session的带宽（见ChannelTrafficShapingHandler）作为流量整形。
+它允许你使用TrafficCounter来实现几乎实时的带宽监控，TrafficCounter会在每个检测间期（checkInterval）调用这个处理器的doAccounting方法。
+
+如果你有任何特别的原因想要停止监控（计数）或者改变读写的限制或者改变检测间期（checkInterval），可以使用如下方法：
+① configure：允许你改变读或写的限制，或者检测间期（checkInterval）；
+② getTrafficCounter：允许你获得TrafficCounter，并可以停止或启动监控，直接改变检测间期（checkInterval），或去访问它的值。
+
+**TrafficCounter**：对读和写的字节进行计数以用于限制流量。
+它会根据给定的检测间期周期性的计算统计入站和出站的流量，并会回调AbstractTrafficShapingHandler的doAccounting方法。
+如果检测间期（checkInterval）是0，将不会进行计数并且统计只会在每次读或写操作时进行计算。
+
+- configure
+
+```
+public void configure(long newWriteLimit, long newReadLimit,
+        long newCheckInterval) {
+    configure(newWriteLimit, newReadLimit);
+    configure(newCheckInterval);
+}
+```
+
+配置新的写限制、读限制、检测间期。该方法会尽最大努力进行此更改，这意味着已经被延迟进行的流量将不会使用新的配置，它仅用于新的流量中。
+
+- ReopenReadTimerTask
+
+```
+static final class ReopenReadTimerTask implements Runnable {
+    final ChannelHandlerContext ctx;
+    ReopenReadTimerTask(ChannelHandlerContext ctx) {
+        this.ctx = ctx;
+    }
+
+    @Override
+    public void run() {
+        ChannelConfig config = ctx.channel().config();
+        if (!config.isAutoRead() && isHandlerActive(ctx)) {
+            // If AutoRead is False and Active is True, user make a direct setAutoRead(false)
+            // Then Just reset the status
+            if (logger.isDebugEnabled()) {
+                logger.debug("Not unsuspend: " + config.isAutoRead() + ':' +
+                        isHandlerActive(ctx));
+            }
+            ctx.attr(READ_SUSPENDED).set(false);
+        } else {
+            // Anything else allows the handler to reset the AutoRead
+            if (logger.isDebugEnabled()) {
+                if (config.isAutoRead() && !isHandlerActive(ctx)) {
+                    logger.debug("Unsuspend: " + config.isAutoRead() + ':' +
+                            isHandlerActive(ctx));
+                } else {
+                    logger.debug("Normal unsuspend: " + config.isAutoRead() + ':'
+                            + isHandlerActive(ctx));
+                }
+            }
+            ctx.attr(READ_SUSPENDED).set(false);
+            config.setAutoRead(true);
+            ctx.channel().read();
+        }
+        if (logger.isDebugEnabled()) {
+            logger.debug("Unsuspend final status => " + config.isAutoRead() + ':'
+                    + isHandlerActive(ctx));
+        }
+    }
+}
+```
+
+重启读操作的定时任务。该定时任务总会实现：
+a) 如果Channel的autoRead为false，并且AbstractTrafficShapingHandler的READ_SUSPENDED属性设置为null或false（说明读暂停未启用或开启），则直接将READ_SUSPENDED属性设置为false。
+b) 否则，如果Channel的autoRead为true，或者READ_SUSPENDED属性的值为true（说明读暂停开启了），则将READ_SUSPENDED属性设置为false，并将Channel的autoRead标识为true（该操作底层会将该Channel的OP_READ事件重新注册为感兴趣的事件，这样Selector就会监听该Channel的读就绪事件了），最后触发一次Channel的read操作。
+也就说，若“读操作”为“开启”状态（READ_SUSPENDED为null或false）的情况下，Channel的autoRead是保持Channel原有的配置，此时并不会做什么操作。但当“读操作”从“暂停”状态（READ_SUSPENDED为true）转为“开启”状态（READ_SUSPENDED为false）时，则会将Channel的autoRead标志为true，并将“读操作”设置为“开启”状态（READ_SUSPENDED为false）。
+
+- channelRead
+
+```
+public void channelRead(final ChannelHandlerContext ctx, final Object msg) throws Exception {
+    long size = calculateSize(msg);
+    long now = TrafficCounter.milliSecondFromNano();
+    if (size > 0) {
+        // compute the number of ms to wait before reopening the channel
+        long wait = trafficCounter.readTimeToWait(size, readLimit, maxTime, now);
+        wait = checkWaitReadTime(ctx, wait, now);
+        if (wait >= MINIMAL_WAIT) { // At least 10ms seems a minimal
+            // time in order to try to limit the traffic
+            // Only AutoRead AND HandlerActive True means Context Active
+            ChannelConfig config = ctx.channel().config();
+            if (logger.isDebugEnabled()) {
+                logger.debug("Read suspend: " + wait + ':' + config.isAutoRead() + ':'
+                        + isHandlerActive(ctx));
+            }
+            if (config.isAutoRead() && isHandlerActive(ctx)) {
+                config.setAutoRead(false);
+                ctx.attr(READ_SUSPENDED).set(true);
+                // Create a Runnable to reactive the read if needed. If one was create before it will just be
+                // reused to limit object creation
+                Attribute<Runnable> attr = ctx.attr(REOPEN_TASK);
+                Runnable reopenTask = attr.get();
+                if (reopenTask == null) {
+                    reopenTask = new ReopenReadTimerTask(ctx);
+                    attr.set(reopenTask);
+                }
+                ctx.executor().schedule(reopenTask, wait, TimeUnit.MILLISECONDS);
+                if (logger.isDebugEnabled()) {
+                    logger.debug("Suspend final status => " + config.isAutoRead() + ':'
+                            + isHandlerActive(ctx) + " will reopened at: " + wait);
+                }
+            }
+        }
+    }
+    informReadOperation(ctx, now);
+    ctx.fireChannelRead(msg);
+}
+```
+
+① 『long size = calculateSize(msg);』计算本次读取到的消息的字节数。
+② 如果读取到的字节数大于0，则根据数据的大小、设定的readLimit、最大延迟时间等计算（『long wait = trafficCounter.readTimeToWait(size, readLimit, maxTime, now);』）得到下一次开启读操作需要的延迟时间（距当前时间而言）wait(毫秒)。
+③ 如果a）wait >= MINIMAL_WAIT(10毫秒)。并且b）当前Channel为自动读取（即，autoRead为true）以及c）当前的READ_SUSPENDED标识为null或false（即，读操作未被暂停），那么将Channel的autoRead设置为false（该操作底层会将该Channel的OP_READ事件从感兴趣的事件中移除，这样Selector就不会监听该Channel的读就绪事件了），并且将READ_SUSPENDED标识为true（说明，接下来的读操作会被暂停），并将“重新开启读操作“封装为一个任务，让入Channel所注册NioEventLoop的定时任务队列中（延迟wait时间后执行）。
+也就说，只有当计算出的下一次读操作的时间大于了MINIMAL_WAIT(10毫秒)，并且当前Channel是自动读取的，且“读操作”处于“开启”状态时，才会去暂停读操作，而暂停读操作主要需要完成三件事：[1]将Channel的autoRead标识设置为false，这使得OP_READ会从感兴趣的事件中移除，这样Selector就会不会监听这个Channel的读就绪事件了；[2]将“读操作”状态设置为“暂停”（READ_SUSPENDED为true）；[3]将重启开启“读操作”的操作封装为一个task，在延迟wait时间后执行。
+当你将得Channel的autoRead都会被设置为false时，Netty底层就不会再去执行读操作了，也就是说，这时如果有数据过来，会先放入到内核的接收缓冲区，只有我们执行读操作的时候数据才会从内核缓冲区读取到用户缓冲区中。而对于TCP协议来说，你不要担心一次内核缓冲区会溢出。因为如果应用进程一直没有读取，接收缓冲区满了之后，发生的动作是：通知对端TCP协议中的窗口关闭。这个便是滑动窗口的实现。保证TCP套接口接收缓冲区不会溢出，从而保证了TCP是可靠传输。因为对方不允许发出超过所通告窗口大小的数据。 这就是TCP的流量控制，如果对方无视窗口大小而发出了超过窗口大小的数据，则接收方TCP将丢弃它。
+④ 将当前的消息发送给ChannelPipeline中的下一个ChannelInboundHandler。
+
+- write
+
+```
+public void write(final ChannelHandlerContext ctx, final Object msg, final ChannelPromise promise)
+        throws Exception {
+    long size = calculateSize(msg);
+    long now = TrafficCounter.milliSecondFromNano();
+    if (size > 0) {
+        // compute the number of ms to wait before continue with the channel
+        long wait = trafficCounter.writeTimeToWait(size, writeLimit, maxTime, now);
+        if (wait >= MINIMAL_WAIT) {
+            if (logger.isDebugEnabled()) {
+                logger.debug("Write suspend: " + wait + ':' + ctx.channel().config().isAutoRead() + ':'
+                        + isHandlerActive(ctx));
+            }
+            submitWrite(ctx, msg, size, wait, now, promise);
+            return;
+        }
+    }
+    // to maintain order of write
+    submitWrite(ctx, msg, size, 0, now, promise);
+}
+```
+
+① 『long size = calculateSize(msg);』计算待写出的数据大小
+② 如果待写出数据的字节数大于0，则根据数据大小、设置的writeLimit、最大延迟时间等计算（『long wait = trafficCounter.writeTimeToWait(size, writeLimit, maxTime, now);』）得到本次写操作需要的延迟时间（距当前时间而言）wait(毫秒)。
+③ 如果wait >= MINIMAL_WAIT（10毫秒），则调用『submitWrite(ctx, msg, size, wait, now, promise);』wait即为延迟时间，该方法的具体实现由子类完成；否则，若wait < MINIMAL_WAIT（10毫秒），则调用『submitWrite(ctx, msg, size, 0, now, promise);』注意这里传递的延迟时间为0了。
+
+###### GlobalTrafficShapingHandler
+
+这实现了AbstractTrafficShapingHandler的全局流量整形，也就是说它限制了全局的带宽，无论开启了几个channel。
+注意『 OutboundBuffer.setUserDefinedWritability(index, boolean)』中索引使用’2’。
+
+一般用途如下：
+创建一个唯一的GlobalTrafficShapingHandler
+
+```
+GlobalTrafficShapingHandler myHandler = new GlobalTrafficShapingHandler(executor);
+pipeline.addLast(myHandler);
+```
+
+executor可以是底层的IO工作池
+
+注意，这个处理器是覆盖所有管道的，这意味着只有一个处理器对象会被创建并且作为所有channel间共享的计数器，它必须于所有的channel共享。
+所有你可以见到，该类的定义上面有个`@Sharable`注解。
+
+在你的处理器中，你需要考虑使用『channel.isWritable()』和『channelWritabilityChanged(ctx)』来处理可写性，或通过在ctx.write()返回的future上注册listener来实现。
+
+你还需要考虑读或写操作对象的大小需要和你要求的带宽相对应：比如，你将一个10M大小的对象用于10KB/s的带宽将会导致爆发效果，若你将100KB大小的对象用于在1M/s带宽那么将会被流量整形处理器平滑处理。
+
+一旦不在需要这个处理器时请确保调用『release()』以释放所有内部的资源。这不会关闭EventExecutor，因为它可能是共享的，所以这需要你自己做。
+
+GlobalTrafficShapingHandler中持有一个Channel的哈希表，用于存储当前应用所有的Channel：
+
+```
+private final ConcurrentMap<Integer, PerChannel> channelQueues = PlatformDependent.newConcurrentHashMap();
+```
+
+key为Channel的hashCode；value是一个PerChannel对象。
+PerChannel对象中维护有该Channel的待发送数据的消息队列（ArrayDeque messagesQueue）。
+
+- submitWrite
+
+```
+void submitWrite(final ChannelHandlerContext ctx, final Object msg,
+        final long size, final long writedelay, final long now,
+        final ChannelPromise promise) {
+    Channel channel = ctx.channel();
+    Integer key = channel.hashCode();
+    PerChannel perChannel = channelQueues.get(key);
+    if (perChannel == null) {
+        // in case write occurs before handlerAdded is raised for this handler
+        // imply a synchronized only if needed
+        perChannel = getOrSetPerChannel(ctx);
+    }
+    final ToSend newToSend;
+    long delay = writedelay;
+    boolean globalSizeExceeded = false;
+    // write operations need synchronization
+    synchronized (perChannel) {
+        if (writedelay == 0 && perChannel.messagesQueue.isEmpty()) {
+            trafficCounter.bytesRealWriteFlowControl(size);
+            ctx.write(msg, promise);
+            perChannel.lastWriteTimestamp = now;
+            return;
+        }
+        if (delay > maxTime && now + delay - perChannel.lastWriteTimestamp > maxTime) {
+            delay = maxTime;
+        }
+        newToSend = new ToSend(delay + now, msg, size, promise);
+        perChannel.messagesQueue.addLast(newToSend);
+        perChannel.queueSize += size;
+        queuesSize.addAndGet(size);
+        checkWriteSuspend(ctx, delay, perChannel.queueSize);
+        if (queuesSize.get() > maxGlobalWriteSize) {
+            globalSizeExceeded = true;
+        }
+    }
+    if (globalSizeExceeded) {
+        setUserDefinedWritability(ctx, false);
+    }
+    final long futureNow = newToSend.relativeTimeAction;
+    final PerChannel forSchedule = perChannel;
+    ctx.executor().schedule(new Runnable() {
+        @Override
+        public void run() {
+            sendAllValid(ctx, forSchedule, futureNow);
+        }
+    }, delay, TimeUnit.MILLISECONDS);
+}
+```
+
+写操作提交上来的数据。
+① 如果写延迟为0，且当前该Channel的messagesQueue为空（说明，在此消息前没有待发送的消息了），那么直接发送该消息包。并返回，否则到下一步。
+② 『newToSend = new ToSend(delay + now, msg, size, promise);
+perChannel.messagesQueue.addLast(newToSend);』
+将待发送的数据封装成ToSend对象放入PerChannel的消息队列中（messagesQueue）。注意，这里的messagesQueue是一个ArrayDeque队列，我们总是从队列尾部插入。然后从队列的头获取消息来依次发送，这就保证了消息的有序性。但是，如果一个大数据包前于一个小数据包发送的话，小数据包也会因为大数据包的延迟发送而被延迟到大数据包发送后才会发送。
+ToSend 对象中持有带发送的数据对象、发送的相对延迟时间（即，根据数据包大小以及设置的写流量限制值（writeLimit）等计算出来的延迟操作的时间）、消息数据的大小、异步写操作的promise。
+③ 『checkWriteSuspend(ctx, delay, perChannel.queueSize);』
+检查单个Channel待发送的数据包是否超过了maxWriteSize（默认4M），或者延迟时间是否超过了maxWriteDelay（默认4s）。如果是的话，则调用『setUserDefinedWritability(ctx, false);』该方法会将ChannelOutboundBuffer中的unwritable属性值的相应标志位置位（unwritable关系到isWritable方法是否会返回true。以及会在unwritable从0到非0间变化时触发ChannelWritabilityChanged事件）。
+④ 如果所有待发送的数据大小（这里指所有Channel累积的待发送的数据大小）大于了maxGlobalWriteSize（默认400M），则标识globalSizeExceeded为true，并且调用『setUserDefinedWritability(ctx, false)』将ChannelOutboundBuffer中的unwritable属性值相应的标志位置位。
+⑤ 根据指定的延迟时间（一个 >= 0 且 <= maxTime 的值，maxTime默认15s）delay，将『sendAllValid(ctx, forSchedule, futureNow);』操作封装成一个任务提交至executor的定时周期任务队列中。
+sendAllValid操作会遍历该Channel中待发送的消息队列messagesQueue，依次取出perChannel.messagesQueue中的消息包，将满足发送条件（即，延迟发送的时间已经到了）的消息发送给到ChannelPipeline中的下一个ChannelOutboundHandler（ctx.write(newToSend.toSend, newToSend.promise);），并且将perChannel.queueSize（当前Channel待发送的总数据大小）和queuesSize（所有Channel待发送的总数据大小）减小相应的值（即，被发送出去的这个数据包的大小）。循环遍历前面的操作直到当前的消息不满足发送条件则退出遍历。并且如果该Channel的消息队列中的消息全部都发送出去的话（即，messagesQueue.isEmpty()为true），则会通过调用『releaseWriteSuspended(ctx);』来释放写暂停。而该方法底层会将ChannelOutboundBuffer中的unwritable属性值相应的标志位重置。
+
+###### ChannelTrafficShapingHandler
+
+ChannelTrafficShapingHandler是针对单个Channel的流量整形，和GlobalTrafficShapingHandler的思想是一样的。只是实现中没有对全局概念的检测，仅检测了当前这个Channel的数据。
+这里就不再赘述了。
+
+###### GlobalChannelTrafficShapingHandler
+
+相比于GlobalTrafficShapingHandler增加了一个误差概念，以平衡各个Channel间的读/写操作。也就是说，使得各个Channel间的读/写操作尽量均衡。比如，尽量避免不同Channel的大数据包都延迟近乎一样的是时间再操作，以及如果小数据包在一个大数据包后才发送，则减少该小数据包的延迟发送时间等。。
+
+### “流量整形”实战
+
+这里仅展示服务端和客户端中使用“流量整形”功能涉及的关键代码，完整demo可见[github](https://link.jianshu.com/?t=https%3A%2F%2Fgithub.com%2Flinling1%2Fnetty_module_function%2Ftree%2Fmaster%2Fsrc%2Fmain%2Fjava%2Fcom%2Flinling%2Fnetty%2Ftrafficshaping)
+**服务端**
+使用GlobalTrafficShapingHandler来实现服务端的“流量整形”，每当有客户端连接至服务端时服务端就会开始往这个客户端发送26M的数据包。我们将GlobalTrafficShapingHandler的writeLimit设置为10M/S。并使用了ChunkedWriteHandler来实现大数据包拆分成小数据包发送的功能。
+
+MyServerInitializer实现：在ChannelPipeline中注册了GlobalTrafficShapingHandler
+
+```
+public class MyServerInitializer extends ChannelInitializer<SocketChannel> {
+
+    Charset utf8 = Charset.forName("utf-8");
+    final int M = 1024 * 1024;
+
+    @Override
+    protected void initChannel(SocketChannel ch) throws Exception {
+
+        GlobalTrafficShapingHandler globalTrafficShapingHandler = new GlobalTrafficShapingHandler(ch.eventLoop().parent(), 10 * M, 50 * M);
+//        globalTrafficShapingHandler.setMaxGlobalWriteSize(50 * M);
+//        globalTrafficShapingHandler.setMaxWriteSize(5 * M);
+
+        ch.pipeline()
+                .addLast("LengthFieldBasedFrameDecoder", new LengthFieldBasedFrameDecoder(Integer.MAX_VALUE, 0, 4, 0, 4, true))
+                .addLast("LengthFieldPrepender", new LengthFieldPrepender(4, 0))
+                .addLast("GlobalTrafficShapingHandler", globalTrafficShapingHandler)
+                .addLast("chunkedWriteHandler", new ChunkedWriteHandler())
+                .addLast("myServerChunkHandler", new MyServerChunkHandler())
+                .addLast("StringDecoder", new StringDecoder(utf8))
+                .addLast("StringEncoder", new StringEncoder(utf8))
+                .addLast("myServerHandler", new MyServerHandlerForPlain());
+    }
+}
+```
+
+ServerHandler：当有客户端连接上了后就开始给客户端发送消息。并且通过『Channel#isWritable』方法以及『channelWritabilityChanged』事件来监控可写性，以判断啥时需要停止数据的写出，啥时可以开始继续写出数据。同时写了一个简易的task来计算每秒数据的发送速率（并非精确的计算）。
+
+```
+public class MyServerHandlerForPlain extends MyServerCommonHandler {
+
+    @Override
+    protected void sentData(ChannelHandlerContext ctx) {
+        sentFlag = true;
+        ctx.writeAndFlush(tempStr, getChannelProgressivePromise(ctx, future -> {
+            if(ctx.channel().isWritable() && !sentFlag) {
+                sentData(ctx);
+            }
+        }));
+    }
+
+    @Override
+    public void channelWritabilityChanged(ChannelHandlerContext ctx) throws Exception {
+        if(ctx.channel().isWritable() && !sentFlag) {
+//            System.out.println(" ###### 重新开始写数据 ######");
+            sentData(ctx);
+        } else {
+//            System.out.println(" ===== 写暂停 =====");
+        }
+    }
+}
+
+public abstract class MyServerCommonHandler extends SimpleChannelInboundHandler<String> {
+
+    protected final int M = 1024 * 1024;
+    protected String tempStr;
+    protected AtomicLong consumeMsgLength;
+    protected Runnable counterTask;
+    private long priorProgress;
+    protected boolean sentFlag;
+
+    @Override
+    public void handlerAdded(ChannelHandlerContext ctx) throws Exception {
+        consumeMsgLength = new AtomicLong();
+        counterTask = () -> {
+          while (true) {
+              try {
+                  Thread.sleep(1000);
+              } catch (InterruptedException e) {
+
+              }
+
+              long length = consumeMsgLength.getAndSet(0);
+              System.out.println("*** " + ctx.channel().remoteAddress() + " rate（M/S）：" + (length / M));
+          }
+        };
+        StringBuilder builder = new StringBuilder();
+        for (int i = 0; i < M; i++) {
+            builder.append("abcdefghijklmnopqrstuvwxyz");
+        }
+        tempStr = builder.toString();
+        super.handlerAdded(ctx);
+    }
+
+    @Override
+    public void channelActive(ChannelHandlerContext ctx) throws Exception {
+        sentData(ctx);
+        new Thread(counterTask).start();
+    }
+
+    protected ChannelProgressivePromise getChannelProgressivePromise(ChannelHandlerContext ctx, Consumer<ChannelProgressiveFuture> completedAction) {
+        ChannelProgressivePromise channelProgressivePromise = ctx.newProgressivePromise();
+        channelProgressivePromise.addListener(new ChannelProgressiveFutureListener(){
+            @Override
+            public void operationProgressed(ChannelProgressiveFuture future, long progress, long total) throws Exception {
+                consumeMsgLength.addAndGet(progress - priorProgress);
+                priorProgress = progress;
+            }
+
+            @Override
+            public void operationComplete(ChannelProgressiveFuture future) throws Exception {
+                sentFlag = false;
+                if(future.isSuccess()){
+                    System.out.println("成功发送完成！");
+                    priorProgress -= 26 * M;
+                    Optional.ofNullable(completedAction).ifPresent(action -> action.accept(future));
+                } else {
+                    System.out.println("发送失败！！！！！");
+                    future.cause().printStackTrace();
+                }
+            }
+        });
+        return channelProgressivePromise;
+    }
+
+    protected abstract void sentData(ChannelHandlerContext ctx);
+
+    @Override
+    protected void channelRead0(ChannelHandlerContext ctx, String msg) throws Exception {
+        System.out.println("===== receive client msg : " + msg);
+    }
+
+    @Override
+    public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
+        cause.printStackTrace();
+        ctx.channel().close();
+    }
+
+}
+```
+
+**客户端**
+客户端比较简单了，使用ChannelTrafficShapingHandler来实现“流量整形”，并将readLimit设置为1M/S。
+
+```
+public class MyClientInitializer extends ChannelInitializer<SocketChannel> {
+
+    Charset utf8 = Charset.forName("utf-8");
+
+    final int M = 1024 * 1024;
+
+    @Override
+    protected void initChannel(SocketChannel ch) throws Exception {
+        ChannelTrafficShapingHandler channelTrafficShapingHandler = new ChannelTrafficShapingHandler(10 * M, 1 * M);
+        ch.pipeline()
+                .addLast("channelTrafficShapingHandler",channelTrafficShapingHandler)
+                .addLast("lengthFieldBasedFrameDecoder", new LengthFieldBasedFrameDecoder(Integer.MAX_VALUE, 0, 4, 0, 4, true))
+                .addLast("lengthFieldPrepender", new LengthFieldPrepender(4, 0))
+                .addLast("stringDecoder", new StringDecoder(utf8))
+                .addLast("stringEncoder", new StringEncoder(utf8))
+                .addLast("myClientHandler", new MyClientHandler());
+    }
+}
+```
+
+##### 注意事项
+
+① 注意，trafficShaping是通过程序来达到控制流量的作用，并不是网络层真实的传输流量大小的控制。TrafficShapingHandler仅仅是根据消息大小（待发送出去的数据包大小）和设定的流量限制来得出延迟发送该包的时间，即同一时刻不会发送过大的数据导致带宽负荷不了。但是并没有对大数据包进行拆分的作用，这会使在发送这个大数据包时同样可能会导致带宽爆掉的情况。所以你需要注意一次发送数据包的大小，不要大于你设置限定的写带宽大小(writeLimit)。你可以通过在业务handler中自己控制的方式，或者考虑使用ChunkedWriteHandler，如果它能满足你的要求的话。同时注意，不要将writeLimit和readLimit设置的过小，这是没有意义的，只会导致读/写操作的不断停顿。。
+② 注意，不要在非NioEventLoop线程中不停歇的发送非ByteBuf、ByteBufHolder或者FileRegion对象的大数据包，如：
+
+```
+new Thread(() -> {
+        while (true) {
+            if(ctx.channel().isWritable()) {
+                ctx.writeAndFlush(tempStr, getChannelProgressivePromise(ctx, null));
+            }
+        }
+    }).start();
+```
+
+因为写操作是一个I/O操作，当你在非NioEventLoop线程上执行了Channel的I/O操作的话，该操作会封装为一个task 被提交至NioEventLoop的任务队列中，以使得I/O操作最终是NioEventLoop线程上得到执行。
+而提交这个任务的流程，仅会对ByteBuf、ByteBufHolder或者FileRegion对象进行真实数据大小的估计（其他情况默认估计大小为8 bytes），并将估计后的数据大小值对该ChannelOutboundBuffer的totalPendingSize属性值进行累加。而totalPendingSize同WriteBufferWaterMark一起来控制着Channel的unwritable。所以，如果你在一个非NioEventLoop线程中不断地发送一个非ByteBuf、ByteBufHolder或者FileRegion对象的大数据包时，最终就会导致提交大量的任务到NioEventLoop线程的任务队列中，而当NioEventLoop线程在真实执行这些task时可能发生OOM。
+
+### 扩展
+
+##### 关于 “OP_WRITE” 与 “Channel#isWritable()”
+
+首先，我们需要明确的一点是，“OP_WRITE” 与 “Channel#isWritable()” 虽然都是的对数据的可写性进行检测，但是它们是分别针对不同层面的可写性的。
+
+- “OP_WRITE”是当内核的发送缓冲区满的时候，我们程序执行write操作（这里是真实写操作了，将数据通过TCP协议进行网络传输）无法将数据写出，这时我们需要注册OP_WRITE事件。这样当发送缓冲区空闲时就OP_WRITE事件就会触发，我们就可以继续write未写完的数据了。这可以看做是对系统层面的可写性的一种检测。
+- 而“Channel#isWritable()”则是检测程序中的缓存的待写出的数据大小超过了我们设定的相关最大写数据大小，如果超过了isWritable()方法将返回false，说明这时我们不应该再继续进行write操作了（这里写操作一般为通过ChannelHandlerContext或Channel进行的写操作）。
+  关于“OP_WRITE”前面的[NIO文章](https://www.jianshu.com/p/1af407c043cb)及前面Netty系列文章已经进行过不少介绍了，这里不再赘述。下面我们来看看“Channel#isWritable()”是如果检测可写性的。
+
+```
+public boolean isWritable() {
+    return unwritable == 0;
+}
+```
+
+ChannelOutboundBuffer 的 unwritable属性为0时，Channel的isWritable()方法将返回true；否之，返回false；
+unwritable可以看做是一个二进制的开关属性值。它的二进制的不同位表示的不同状态的开关。如：
+
+[![img](53-Netty 源码解析-ChannelHandler（六）之 AbstractTrafficShapingHandler.assets/jpeg.webp)](https://upload-images.jianshu.io/upload_images/4235178-5291c64aba1bbaac.jpg?imageMogr2/auto-orient/strip|imageView2/2/w/972/format/jpeg)img
+
+ChannelOutboundBuffer有四个方法会对unwritable属性值进行修改：clearUserDefinedWritability、setUnwritable、setUserDefinedWritability、setWritable。并且，当unwritable从0到非0间改变时还会触发ChannelWritabilityChanged事件，以通知ChannelPipeline中的各个ChannelHandler当前Channel可写性发生了改变。
+
+其中setUnwritable、setWritable这对方法是由于待写数据大小高于或低于了WriteBufferWaterMark的水位线而导致的unwritable属性值的改变。
+我们所执行的『ChannelHandlerContext#write』和『Channel#write』操作会先将待发送的数据包放到Channel的输出缓冲区（ChannelOutboundBuffer）中，然后在执行flush操作的时候，会从ChannelOutboundBuffer中依次出去数据包进行真实的网络数据传输。而WriteBufferWaterMark控制的就是ChannelOutboundBuffer中待发送的数据总大小（即，totalPendingSize：包含一个个ByteBuf中待发送的数据大小，以及数据包对象占用的大小）。如果totalPendingSize的大小超过了WriteBufferWaterMark高水位（默认为64KB），则会unwritable属性的’WriteBufferWaterMark状态位’置位1；随着数据不断写出（每写完一个ByteBuf后，就会将totalPendingSize减少相应的值），当totalPendingSize的大小小于WriteBufferWaterMark低水位（默认为32KB）时，则会将unwritable属性的’WriteBufferWaterMark状态位’置位0。
+
+而本文的主题“流量整形”则是使用了clearUserDefinedWritability、setUserDefinedWritability这对方法来控制unwritable相应的状态位。
+当数据write到GlobalTrafficShapingHandler的时候，估计的数据大小大于0，且通过trafficCounter计算出的延迟时间大于最小延迟时间（MINIMAL_WAIT，默认为10ms）时，满足如下任意条件会使得unwritable的’GlobalTrafficShaping状态位’置为1：
+
+- 当perChannel.queueSize（单个Channel中待写出的总数据大小）设定的最大写数据大小时（默认为4M）
+- 当queuesSize（所有Channel的待写出的总数据大小）超过设定的最大写数据大小时（默认为400M）
+- 对于Channel发送的单个数据包如果太大，以至于计算出的延迟发送时间大于了最大延迟发送时间（maxWriteDelay，默认为4s）时
+
+随着写延迟时间的到达GlobalTrafficShaping中积压的数据不断被写出，当某个Channel中所有待写出的数据都写出后（注意，这里指将数据写到ChannelPipeline中的下一个ChannelOutboundBuffer中）会将unwritable的’GlobalTrafficShaping状态位’置为0。
\ No newline at end of file
diff --git a/netty/54-Netty 源码解析-Codec 之 ByteToMessageDecoder（一）Cumulator.assets/01-17199761752731.png b/netty/54-Netty 源码解析-Codec 之 ByteToMessageDecoder（一）Cumulator.assets/01-17199761752731.png
new file mode 100644
index 0000000..dff97bb
Binary files /dev/null and b/netty/54-Netty 源码解析-Codec 之 ByteToMessageDecoder（一）Cumulator.assets/01-17199761752731.png differ
diff --git a/netty/54-Netty 源码解析-Codec 之 ByteToMessageDecoder（一）Cumulator.assets/01.png b/netty/54-Netty 源码解析-Codec 之 ByteToMessageDecoder（一）Cumulator.assets/01.png
new file mode 100644
index 0000000..fb73a59
Binary files /dev/null and b/netty/54-Netty 源码解析-Codec 之 ByteToMessageDecoder（一）Cumulator.assets/01.png differ
diff --git a/netty/54-Netty 源码解析-Codec 之 ByteToMessageDecoder（一）Cumulator.md b/netty/54-Netty 源码解析-Codec 之 ByteToMessageDecoder（一）Cumulator.md
new file mode 100644
index 0000000..055a7e5
--- /dev/null
+++ b/netty/54-Netty 源码解析-Codec 之 ByteToMessageDecoder（一）Cumulator.md	
@@ -0,0 +1,1146 @@
+# 精尽 Netty 源码解析 —— Codec 之 ByteToMessageDecoder（一）Cumulator
+
+# 1. 概述
+
+在 [《精尽 Netty 源码解析 —— ChannelHandler（一）之简介》](http://svip.iocoder.cn/Netty/ChannelHandler-1-intro) 中，我们看了 ChannelHandler 的核心类图，如下：[![核心类图](54-Netty 源码解析-Codec 之 ByteToMessageDecoder（一）Cumulator.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_10_01/01.png)核心类图
+
+- **绿框**部分，我们可以看到，Netty 基于 ChannelHandler 实现了读写的数据( 消息 )的编解码。
+
+  > Codec( 编解码 ) = Encode( 编码 ) + Decode( 解码 )。
+
+- 图中有五个和 Codec 相关的类，整理如下：
+
+  - 😈 ，实际应该是六个，漏画了 MessageToMessageDecoder 类。
+
+  - ByteToMessageCodec ，ByteToMessageDecoder + MessageByteEncoder 的
+
+    组合
+
+    。
+
+    - ByteToMessageDecoder ，将字节**解码**成消息。
+    - MessageByteEncoder ，将消息**编码**成字节。
+
+  - MessageToMessageCodec ，MessageToMessageDecoder + MessageToMessageEncoder 的
+
+    组合
+
+    。
+
+    - MessageToMessageDecoder ，将消息**解码**成另一种消息。
+    - MessageToMessageEncoder ，将消息**编码**成另一种消息。
+
+------
+
+而本文，我们来分享 ByteToMessageDecoder 部分的内容。
+
+# 2. ByteToMessageDecoder 核心类图
+
+[![核心类图](54-Netty 源码解析-Codec 之 ByteToMessageDecoder（一）Cumulator.assets/01-17199761752731.png)](http://static.iocoder.cn/images/Netty/2018_12_01/01.png)核心类图
+
+ByteToMessageDecoder 本身是个**抽象**类，其下有多个子类，笔者简单整理成三类，可能不全哈：
+
+- **绿框**部分 FrameDecoder ：消息帧( Frame )解码器。也就是说该类解码器，用于处理 TCP 的**粘包**现象，将网络发送的字节流解码为具有确定含义的消息帧。之后的解码器再将消息帧解码为实际的 POJO 对象。 如下图所示：[decode](http://static.iocoder.cn/images/Netty/2018_12_01/02.png)
+
+- 黄框
+
+  部分，将字节流使用
+
+  指定序列化方式
+
+  反序列化成
+
+  消息
+
+  ，例如：XML、JSON 等等。
+
+  - 对于该类解码器，不处理 TCP 的**粘包**现象，所以需要搭配 FrameDecoder 一起使用。
+
+- 蓝框
+
+  部分，将字节流
+
+  解压
+
+  ，主要涉及相关压缩算法，例如：GZip、BZip 等等。
+
+  - 对于该类解码器，不处理 TCP 的**粘包**现象，所以需要搭配 FrameDecoder 一起使用。
+
+# 3. 为什么要粘包拆包
+
+😈 因为有些朋友不了解粘包和拆包的概念和原理，这里引用笔者的基友【闪电侠】在 [《netty 源码分析之拆包器的奥秘》](https://www.jianshu.com/p/dc26e944da95) 对这块的描述。
+
+## 3.1 为什么要粘包
+
+> 首先你得了解一下 TCP/IP 协议，在用户数据量非常小的情况下，极端情况下，一个字节，该 TCP 数据包的有效载荷非常低，传递 100 字节的数据，需要 100 次TCP传送， 100 次ACK，在应用及时性要求不高的情况下，将这 100 个有效数据拼接成一个数据包，那会缩短到一个TCP数据包，以及一个 ack ，有效载荷提高了，带宽也节省了。
+>
+> 非极端情况，有可能**两个**数据包拼接成一个数据包，也有可能**一个半**的数据包拼接成一个数据包，也有可能**两个半**的数据包拼接成一个数据包。
+
+## 3.2 为什么要拆包
+
+> 拆包和粘包是相对的，一端粘了包，另外一端就需要将粘过的包拆开。举个栗子，发送端将三个数据包粘成两个TCP数据包发送到接收端，接收端就需要根据应用协议将两个数据包重新组装成三个数据包。
+>
+> 还有一种情况就是用户数据包超过了 mss(最大报文长度)，那么这个数据包在发送的时候必须拆分成几个数据包，接收端收到之后需要将这些数据包粘合起来之后，再拆开。
+
+## 3.3 拆包的原理
+
+> 数据，每次读取完都需要判断是否是一个完整的数据包：
+>
+> 1. 如果当前读取的数据不足以拼接成一个完整的业务数据包，那就保留该数据，继续从tcp缓冲区中读取，直到得到一个完整的数据包。
+> 2. 如果当前读到的数据加上已经读取的数据足够拼接成一个数据包，那就将已经读取的数据拼接上本次读取的数据，够成一个完整的业务数据包传递到业务逻辑，多余的数据仍然保留，以便和下次读到的数据尝试拼接。
+
+# 4. Cumulator
+
+Cumulator ，是 ByteToMessageDecoder 的**内部**接口。中文翻译为“累加器”，用于将读取到的数据进行累加到一起，然后再尝试**解码**，从而实现**拆包**。
+
+也是因为 Cumulator 的累加，所以能将不完整的包累加到一起，从而完整。当然，累加的过程，没准又进入了一个不完整的包。所以，这是一个不断累加，不断解码拆包的过程。
+
+------
+
+Cumulator 接口，代码如下：
+
+```
+/**
+ * ByteBuf 累积器接口
+ *
+ * Cumulate {@link ByteBuf}s.
+ */
+public interface Cumulator {
+
+    /**
+     * Cumulate the given {@link ByteBuf}s and return the {@link ByteBuf} that holds the cumulated bytes.
+     * The implementation is responsible to correctly handle the life-cycle of the given {@link ByteBuf}s and so
+     * call {@link ByteBuf#release()} if a {@link ByteBuf} is fully consumed.
+     *
+     * @param alloc ByteBuf 分配器
+     * @param cumulation ByteBuf 当前累积结果
+     * @param in 当前读取( 输入 ) ByteBuf
+     * @return ByteBuf 新的累积结果
+     */
+    ByteBuf cumulate(ByteBufAllocator alloc, ByteBuf cumulation, ByteBuf in);
+
+}
+```
+
+- 对于 `Cumulator#cumulate(ByteBufAllocator alloc, ByteBuf cumulation, ByteBuf in)` 方法，将**原有** `cumulation` 累加上**新的** `in` ，返回“新”的 ByteBuf 对象。
+- 如果 `in` 过大，超过 `cumulation` 的空间上限，使用 `alloc` 进行扩容后再累加。
+
+------
+
+Cumulator 有两个实现类，代码如下：
+
+```
+public static final Cumulator MERGE_CUMULATOR = new Cumulator() {
+    // ... 省略代码
+}
+
+public static final Cumulator COMPOSITE_CUMULATOR = new Cumulator() {
+    // ... 省略代码
+}
+```
+
+两者的累加方式不同，我们来详细解析。
+
+## 4.1 MERGE_CUMULATOR
+
+`MERGE_CUMULATOR` 思路是，不断使用**老的** ByteBuf 累积。如果空间不够，扩容出**新的** ByteBuf ，再继续进行累积。代码如下：
+
+```
+// ByteToMessageDecoder.java
+
+    /**
+     * Cumulate {@link ByteBuf}s by merge them into one {@link ByteBuf}'s, using memory copies.
+     */
+  1: public static final Cumulator MERGE_CUMULATOR = new Cumulator() {
+  2: 
+  3:     @Override
+  4:     public ByteBuf cumulate(ByteBufAllocator alloc, ByteBuf cumulation, ByteBuf in) {
+  5:         final ByteBuf buffer;
+  6:         if (cumulation.writerIndex() > cumulation.maxCapacity() - in.readableBytes() // 超过空间大小，需要扩容
+  7:                 || cumulation.refCnt() > 1 // 引用大于 1 ，说明用户使用了 slice().retain() 或 duplicate().retain() 使refCnt增加并且大于 1 ，
+  8:                                            // 此时扩容返回一个新的累积区ByteBuf，方便用户对老的累积区ByteBuf进行后续处理。
+  9:                 || cumulation.isReadOnly()) { // 只读，不可累加，所以需要改成可写
+ 10:             // Expand cumulation (by replace it) when either there is not more room in the buffer
+ 11:             // or if the refCnt is greater then 1 which may happen when the user use slice().retain() or
+ 12:             // duplicate().retain() or if its read-only.
+ 13:             //
+ 14:             // See:
+ 15:             // - https://github.com/netty/netty/issues/2327
+ 16:             // - https://github.com/netty/netty/issues/1764
+ 17:             // 扩容，返回新的 buffer
+ 18:             buffer = expandCumulation(alloc, cumulation, in.readableBytes());
+ 19:         } else {
+ 20:             // 使用老的 buffer
+ 21:             buffer = cumulation;
+ 22:         }
+ 23:         // 写入 in 到 buffer 中
+ 24:         buffer.writeBytes(in);
+ 25:         // 释放输入 in
+ 26:         in.release();
+ 27:         // 返回 buffer
+ 28:         return buffer;
+ 29:     }
+ 30: 
+ 31: };
+```
+
+- 获取 `buffer` 对象。
+
+  - 第 6 至 9 行：如下三个条件，满足任意，需要进行扩容。
+
+    - ① 第 6 行：
+
+      ```
+      cumulation.writerIndex() > cumulation.maxCapacity() - in.readableBytes()
+      ```
+
+       
+
+      ，超过空间大小，需要扩容。
+
+      - 这个比较好理解。
+
+    - ② 第 7 行：
+
+      ```
+      cumulation.refCnt() > 1
+      ```
+
+       
+
+      ，引用大于 1 ，说明用户使用了
+
+       
+
+      ```
+      ByteBuf#slice()#retain()
+      ```
+
+       
+
+      或
+
+       
+
+      ```
+      ByteBuf#duplicate()#retain()
+      ```
+
+       
+
+      方法，使
+
+       
+
+      ```
+      refCnt
+      ```
+
+       
+
+      增加并且大于 1 。
+
+      - 关于这块，在【第 11 行】的英文注释，也相应的提到。
+
+    - ③ 第 9 行：只读，不可累加，所以需要改成可写。
+
+      - 这个比较好理解。
+
+  - 【需要扩容】第 18 行：调用 `ByteToMessageDecoder#expandCumulation(ByteBufAllocator alloc, ByteBuf cumulation, int readable)` **静态**方法，扩容，并返回新的，并赋值给 `buffer` 。代码如下：
+
+    ```
+    static ByteBuf expandCumulation(ByteBufAllocator alloc, ByteBuf cumulation, int readable) {
+        // 记录老的 ByteBuf 对象
+        ByteBuf oldCumulation = cumulation;
+        // 分配新的 ByteBuf 对象
+        cumulation = alloc.buffer(oldCumulation.readableBytes() + readable);
+        // 将老的数据，写入到新的 ByteBuf 对象
+        cumulation.writeBytes(oldCumulation);
+        // 释放老的 ByteBuf 对象
+        oldCumulation.release();
+        // 返回新的 ByteBuf 对象
+        return cumulation;
+    }
+    ```
+
+    - 标准的扩容，并复制老数据的过程。胖友自己看下注释噢。
+
+  - 【无需扩容】第 21 行：`buffer` 直接使用的 `cumulation` 对象。
+
+- 第 24 行：写入
+
+   
+
+  ```
+  in
+  ```
+
+   
+
+  到
+
+   
+
+  ```
+  buffer
+  ```
+
+   
+
+  中，进行累积。
+
+  - 第 26 行：释放 `in` 。
+
+- 第 28 行：返回 `buffer` 。
+
+## 4.2 COMPOSITE_CUMULATOR
+
+`COMPOSITE_CUMULATOR` 思路是，使用 CompositeByteBuf ，组合新输入的 ByteBuf 对象，从而避免内存拷贝。代码如下：
+
+```
+// ByteToMessageDecoder.java
+
+    /**
+     * Cumulate {@link ByteBuf}s by add them to a {@link CompositeByteBuf} and so do no memory copy whenever possible.
+     * Be aware that {@link CompositeByteBuf} use a more complex indexing implementation so depending on your use-case
+     * and the decoder implementation this may be slower then just use the {@link #MERGE_CUMULATOR}.
+     *
+     * 相比 MERGE_CUMULATOR 来说：
+     *
+     * 好处是，内存零拷贝
+     * 坏处是，因为维护复杂索引，所以某些使用场景下，慢于 MERGE_CUMULATOR
+     */
+  1: public static final Cumulator COMPOSITE_CUMULATOR = new Cumulator() {
+  2: 
+  3:     @Override
+  4:     public ByteBuf cumulate(ByteBufAllocator alloc, ByteBuf cumulation, ByteBuf in) {
+  5:         ByteBuf buffer;
+  6:         // 和 MERGE_CUMULATOR 的情况类似
+  7:         if (cumulation.refCnt() > 1) {
+  8:             // Expand cumulation (by replace it) when the refCnt is greater then 1 which may happen when the user
+  9:             // use slice().retain() or duplicate().retain().
+ 10:             //
+ 11:             // See:
+ 12:             // - https://github.com/netty/netty/issues/2327
+ 13:             // - https://github.com/netty/netty/issues/1764
+ 14:             buffer = expandCumulation(alloc, cumulation, in.readableBytes());
+ 15:             buffer.writeBytes(in);
+ 16:             in.release();
+ 17:         } else {
+ 18:             CompositeByteBuf composite;
+ 19:             // 原来是 CompositeByteBuf 类型，直接使用
+ 20:             if (cumulation instanceof CompositeByteBuf) {
+ 21:                 composite = (CompositeByteBuf) cumulation;
+ 22:             // 原来不是 CompositeByteBuf 类型，创建，并添加到其中
+ 23:             } else {
+ 24:                 composite = alloc.compositeBuffer(Integer.MAX_VALUE);
+ 25:                 composite.addComponent(true, cumulation);
+ 26:             }
+ 27:             // 添加 in 到 composite 中
+ 28:             composite.addComponent(true, in);
+ 29:             // 赋值给 buffer
+ 30:             buffer = composite;
+ 31:         }
+ 32:         // 返回 buffer
+ 33:         return buffer;
+ 34:     }
+ 35: 
+ 36: };
+```
+
+- 第 7 至 16 行：`cumulation.refCnt() > 1` 成立，和 `MERGE_CUMULATOR` 的情况一致，创建一个新的 ByteBuf 对象。这样，再下一次 `#cumulate(...)` 时，就会走【第 22 至 26 行】的情况。
+
+- 获得
+
+   
+
+  ```
+  composite
+  ```
+
+   
+
+  对象
+
+  - 第 19 至 21 行：如果原来**就是** CompositeByteBuf 类型，直接使用。
+  - 第 22 至 26 行：如果原来**不是** CompositeByteBuf 类型，创建 CompositeByteBuf 对象，并添加 `cumulation` 到其中。
+
+- 第 28 行：添加 `in` 到 `composite` 中，避免内存拷贝。
+
+## 4.3 对比
+
+关于 `MERGE_CUMULATOR` 和 `COMPOSITE_CUMULATOR` 的对比，已经写在 `COMPOSITE_CUMULATOR` 的**头上**的注释。
+
+默认情况下，ByteToMessageDecoder 使用 `MERGE_CUMULATOR` 作为累加器。
+
+# 5. ByteToMessageDecoder
+
+`io.netty.handler.codec.ByteToMessageDecoder` ，继承 ChannelInboundHandlerAdapter 类，**抽象基类**，负责将 Byte 解码成 Message 。
+
+> 老艿艿：ByteToMessageDecoder 的细节比较多，建议胖友理解如下小节即可：
+>
+> - [5.1 构造方法](https://svip.iocoder.cn/Netty/Codec-1-1-ByteToMessageDecoder-core-impl/#)
+> - [5.2 channelRead](https://svip.iocoder.cn/Netty/Codec-1-1-ByteToMessageDecoder-core-impl/#)
+> - [5.3 callDecode](https://svip.iocoder.cn/Netty/Codec-1-1-ByteToMessageDecoder-core-impl/#)
+> - [5.4 channelReadComplete](https://svip.iocoder.cn/Netty/Codec-1-1-ByteToMessageDecoder-core-impl/#)
+
+## 5.1 构造方法
+
+```
+private static final byte STATE_INIT = 0;
+private static final byte STATE_CALLING_CHILD_DECODE = 1;
+private static final byte STATE_HANDLER_REMOVED_PENDING = 2;
+
+/**
+ * 已累积的 ByteBuf 对象
+ */
+ByteBuf cumulation;
+/**
+ * 累计器
+ */
+private Cumulator cumulator = MERGE_CUMULATOR;
+/**
+ * 是否每次只解码一条消息，默认为 false 。
+ *
+ * 部分解码器为 true ，例如：Socks4ClientDecoder
+ *
+ * @see #callDecode(ChannelHandlerContext, ByteBuf, List)
+ */
+private boolean singleDecode;
+/**
+ * 是否解码到消息。
+ *
+ * WasNull ，说明就是没解码到消息
+ *
+ * @see #channelReadComplete(ChannelHandlerContext)
+ */
+private boolean decodeWasNull;
+/**
+ * 是否首次读取，即 {@link #cumulation} 为空
+ */
+private boolean first;
+/**
+ * A bitmask where the bits are defined as
+ * <ul>
+ *     <li>{@link #STATE_INIT}</li>
+ *     <li>{@link #STATE_CALLING_CHILD_DECODE}</li>
+ *     <li>{@link #STATE_HANDLER_REMOVED_PENDING}</li>
+ * </ul>
+ *
+ * 解码状态
+ *
+ * 0 - 初始化
+ * 1 - 调用 {@link #decode(ChannelHandlerContext, ByteBuf, List)} 方法中，正在进行解码
+ * 2 - 准备移除
+ */
+private byte decodeState = STATE_INIT;
+/**
+ * 读取释放阀值
+ */
+private int discardAfterReads = 16;
+/**
+ * 已读取次数。
+ *
+ * 再读取 {@link #discardAfterReads} 次数据后，如果无法全部解码完，则进行释放，避免 OOM
+ */
+private int numReads;
+
+protected ByteToMessageDecoder() {
+    // 校验，不可共享
+    ensureNotSharable();
+}
+```
+
+属性比较简单，胖友自己看注释。
+
+## 5.2 channelRead
+
+`#channelRead(ChannelHandlerContext ctx, Object msg)` 方法，读取到新的数据，进行解码。代码如下：
+
+```
+ 1: @Override
+ 2: public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
+ 3:     if (msg instanceof ByteBuf) {
+ 4:         // 创建 CodecOutputList 对象
+ 5:         CodecOutputList out = CodecOutputList.newInstance();
+ 6:         try {
+ 7:             ByteBuf data = (ByteBuf) msg;
+ 8:             // 判断是否首次
+ 9:             first = cumulation == null;
+10:             // 若首次，直接使用读取的 data
+11:             if (first) {
+12:                 cumulation = data;
+13:             // 若非首次，将读取的 data ，累积到 cumulation 中
+14:             } else {
+15:                 cumulation = cumulator.cumulate(ctx.alloc(), cumulation, data);
+16:             }
+17:             // 执行解码
+18:             callDecode(ctx, cumulation, out);
+19:         } catch (DecoderException e) {
+20:             throw e; // 抛出异常
+21:         } catch (Exception e) {
+22:             throw new DecoderException(e); // 封装成 DecoderException 异常，抛出
+23:         } finally {
+24:             // cumulation 中所有数据被读取完，直接释放全部
+25:             if (cumulation != null && !cumulation.isReadable()) {
+26:                 numReads = 0; // 重置 numReads 次数
+27:                 cumulation.release(); // 释放 cumulation
+28:                 cumulation = null; // 置空 cumulation
+29:             // 读取次数到达 discardAfterReads 上限，释放部分的已读
+30:             } else if (++ numReads >= discardAfterReads) {
+31:                 // We did enough reads already try to discard some bytes so we not risk to see a OOME.
+32:                 // See https://github.com/netty/netty/issues/4275
+33:                 numReads = 0; // 重置 numReads 次数
+34:                 discardSomeReadBytes(); // 释放部分的已读
+35:             }
+36: 
+37:             // 解码消息的数量
+38:             int size = out.size();
+39:             // 是否解码到消息
+40:             decodeWasNull = !out.insertSinceRecycled();
+41: 
+42:             // 触发 Channel Read 事件。可能是多条消息
+43:             fireChannelRead(ctx, out, size);
+44: 
+45:             // 回收 CodecOutputList 对象
+46:             out.recycle();
+47:         }
+48:     } else {
+49:         // 触发 Channel Read 事件到下一个节点
+50:         ctx.fireChannelRead(msg);
+51:     }
+52: }
+```
+
+- 第 48 至 51 行：消息的类型**不是** ByteBuf 类，直接触发 Channel Read 事件到下一个节点。也就说，不进行解码。
+
+- 第 3 行：消息的类型**是** ByteBuf 类，开始解码。
+
+- 第 5 行：创建 CodecOutputList 对象。CodecOutputList 的简化代码如下：
+
+  ```
+  /**
+   * Special {@link AbstractList} implementation which is used within our codec base classes.
+   */
+  final class CodecOutputList extends AbstractList<Object> implements RandomAccess {
+  
+      // ... 省略代码
+  }
+  ```
+
+  - 如下内容，引用自 [《自顶向下深入分析Netty（八）–CodecHandler》](https://www.jianshu.com/p/7c439cc7b01c)
+
+    > 解码结果列表 CodecOutputList 是 Netty 定制的一个特殊列表，该列表在线程中被缓存，可循环使用来存储解码结果，减少不必要的列表实例创建，从而提升性能。由于解码结果需要频繁存储，普通的 ArrayList 难以满足该需求，故定制化了一个特殊列表，由此可见 Netty 对优化的极致追求。
+
+  - 第 7 至 9 行：通过
+
+     
+
+    ```
+    cumulation
+    ```
+
+     
+
+    是否为
+
+     
+
+    ```
+    null
+    ```
+
+     
+
+    来判断，是否为首次
+
+     
+
+    ```
+    first
+    ```
+
+     
+
+    。
+
+    - 若**是**首次，直接使用读取的 `data` ( `ByteBuf data = (ByteBuf) msg` )。
+    - 若**非**首次，将读取的 `data` ，累积到 `cumulation` 中。在 [「4. Cumulator」](https://svip.iocoder.cn/Netty/Codec-1-1-ByteToMessageDecoder-core-impl/#) 中，我们已经详细解析。
+
+- 第 18 行：调用 `#callDecode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out)` 方法，执行解码。而解码的结果，会添加到 `out` 数组中。详细解析，见 [「5.3 callDecode」](https://svip.iocoder.cn/Netty/Codec-1-1-ByteToMessageDecoder-core-impl/#) 。
+
+- 第 19 至 22 行：若发生异常，抛出 DecoderException 异常。
+
+- 第 24 至 35 行：根据 `cumulation` 的情况，释放 `cumulation` 。
+
+  - 第 24 至 28 行：`cumulation` 中所有数据被读取完，直接**释放全部**。
+
+  - 第 29 至 35 行：读取次数( `numReads` )到达 `discardAfterReads` 上限，重置计数，并调用 `#discardSomeReadBytes()` 方法，释放部分的已读。😈 如果一直不去释放，等到满足【第 24 至 28 行】的条件，很有可能会出现 OOM 的情况。代码如下：
+
+    ```
+    protected final void discardSomeReadBytes() {
+        if (cumulation != null && !first
+                && cumulation.refCnt() == 1) { // <1> 如果用户使用了 slice().retain() 和 duplicate().retain() 使 refCnt > 1 ，表明该累积区还在被用户使用，丢弃数据可能导致用户的困惑，所以须确定用户不再使用该累积区的已读数据，此时才丢弃。
+            // discard some bytes if possible to make more room in the
+            // buffer but only if the refCnt == 1  as otherwise the user may have
+            // used slice().retain() or duplicate().retain().
+            //
+            // See:
+            // - https://github.com/netty/netty/issues/2327
+            // - https://github.com/netty/netty/issues/1764
+            // <2> 释放部分
+            cumulation.discardSomeReadBytes();
+        }
+    }
+    ```
+
+    - `<1>` 处，原因见中文注释。
+    - `<2>` 处，释放**部分**已读字节区。注意，是“部分”，而不是“全部”，避免一次性释放全部，时间过长。并且，能够读取到这么“大”，往往字节数容量不小。如果直接释放掉“全部”，那么后续还需要再重复扩容，反倒不好。
+
+- 第 38 行：获得解码消息的数量。
+
+  - 第 40 行：是否解码到消息。为什么不直接使用
+
+     
+
+    ```
+    size
+    ```
+
+     
+
+    来判断呢？因为如果添加了消息，然后又移除该消息，此时
+
+     
+
+    ```
+    size
+    ```
+
+     
+
+    为 0 ，但是
+
+     
+
+    ```
+    !out.insertSinceRecycled()
+    ```
+
+     
+
+    为
+
+     
+
+    ```
+    true
+    ```
+
+     
+
+    。
+
+    - 另外，我们在 [「5.3 callDecode」](https://svip.iocoder.cn/Netty/Codec-1-1-ByteToMessageDecoder-core-impl/#) 中，将会看到一个 `out` 的清理操作，到时会更加明白。
+
+- 第 43 行：调用 `#fireChannelRead(ChannelHandlerContext ctx, List<Object> msgs, int numElements)` **静态**方法，触发 Channel Read 事件。可能是多条消息。代码如下：
+
+  ```
+  /**
+   * Get {@code numElements} out of the {@link List} and forward these through the pipeline.
+   */
+  static void fireChannelRead(ChannelHandlerContext ctx, List<Object> msgs, int numElements) {
+      if (msgs instanceof CodecOutputList) { // 如果是 CodecOutputList 类型，特殊优化
+          fireChannelRead(ctx, (CodecOutputList) msgs, numElements);
+      } else {
+          for (int i = 0; i < numElements; i++) {
+              ctx.fireChannelRead(msgs.get(i));
+          }
+      }
+  }
+  
+  /**
+   * Get {@code numElements} out of the {@link CodecOutputList} and forward these through the pipeline.
+   */
+  static void fireChannelRead(ChannelHandlerContext ctx, CodecOutputList msgs, int numElements) {
+      for (int i = 0; i < numElements; i ++) {
+          ctx.fireChannelRead(msgs.getUnsafe(i)); // getUnsafe 是自定义的方法，减少越界判断，效率更高
+      }
+  }
+  ```
+
+  - 遍历 `msgs` 数组，每条消息触发一次 Channel Read 事件。
+
+- 第 46 行：回收 CodecOutputList 对象。
+
+## 5.3 callDecode
+
+`#callDecode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out)` 方法，执行解码。而解码的结果，会添加到 `out` 数组中。代码如下：
+
+```
+ 1: protected void callDecode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) {
+ 2:     try {
+ 3:         // 循环读取，直到不可读
+ 4:         while (in.isReadable()) {
+ 5:             // 记录
+ 6:             int outSize = out.size();
+ 7:             // out 非空，说明上一次解码有解码到消息
+ 8:             if (outSize > 0) {
+ 9:                 // 触发 Channel Read 事件。可能是多条消息
+10:                 fireChannelRead(ctx, out, outSize);
+11:                 // 清空
+12:                 out.clear();
+13: 
+14:                 // 用户主动删除该 Handler ，继续操作 in 是不安全的
+15:                 // Check if this handler was removed before continuing with decoding.
+16:                 // If it was removed, it is not safe to continue to operate on the buffer.
+17:                 //
+18:                 // See:
+19:                 // - https://github.com/netty/netty/issues/4635
+20:                 if (ctx.isRemoved()) {
+21:                     break;
+22:                 }
+23:                 outSize = 0;
+24:             }
+25: 
+26:             // 记录当前可读字节数
+27:             int oldInputLength = in.readableBytes();
+28: 
+29:             // 执行解码。如果 Handler 准备移除，在解码完成后，进行移除。
+30:             decodeRemovalReentryProtection(ctx, in, out);
+31: 
+32:             // 用户主动删除该 Handler ，继续操作 in 是不安全的
+33:             // Check if this handler was removed before continuing the loop.
+34:             // If it was removed, it is not safe to continue to operate on the buffer.
+35:             //
+36:             // See https://github.com/netty/netty/issues/1664
+37:             if (ctx.isRemoved()) {
+38:                 break;
+39:             }
+40: 
+41:             // 整列判断 `out.size() == 0` 比较合适。因为，如果 `outSize > 0` 那段，已经清理了 out 。
+42:             if (outSize == out.size()) {
+43:                 // 如果未读取任何字节，结束循环
+44:                 if (oldInputLength == in.readableBytes()) {
+45:                     break;
+46:                 // 如果可读字节发生变化，继续读取
+47:                 } else {
+48:                     continue;
+49:                 }
+50:             }
+51: 
+52:             // 如果解码了消息，但是可读字节数未变，抛出 DecoderException 异常。说明，有问题。
+53:             if (oldInputLength == in.readableBytes()) {
+54:                 throw new DecoderException(StringUtil.simpleClassName(getClass()) + ".decode() did not read anything but decoded a message.");
+55:             }
+56: 
+57:             // 如果开启 singleDecode ，表示只解析一次，结束循环
+58:             if (isSingleDecode()) {
+59:                 break;
+60:             }
+61:         }
+62:     } catch (DecoderException e) {
+63:         throw e;
+64:     } catch (Exception cause) {
+65:         throw new DecoderException(cause);
+66:     }
+67: }
+```
+
+- 第 4 行：循环读取 `in` ，直到不可读。
+
+- 第 5 行：记录
+
+   
+
+  ```
+  out
+  ```
+
+   
+
+  的大小。
+
+  - 第 8 行：如果 `out` 非空，说明上一次解码有解码到消息。
+  - 第 10 行：调用 `#fireChannelRead(ChannelHandlerContext ctx, List<Object> msgs, int numElements)` **静态**方法，触发 Channel Read 事件。可能是多条消息。😈 关于该方法，上文已经详细解析。
+  - 第 12 行：清空 `out` 。所以，有可能会出现 `#channelRead(ChannelHandlerContext ctx, Object msg)` 方法的【第 40 行】的情况。
+  - 第 14 至 22 行：用户主动删除该 Handler ，继续操作 `in` 是不安全的，所以结束循环。
+  - 第 23 行：记录 `out` 的大小为**零**。所以，实际上，`outSize` 没有必要记录。因为，一定是为**零**。
+
+- 第 27 行：记录当前可读字节数。
+
+- 第 30 行：调用 `#decodeRemovalReentryProtection(ChannelHandlerContext ctx, ByteBuf in, List<Object> out)` 方法，执行解码。如果 Handler 准备移除，在解码完成后，进行移除。详细解析，见 [「5.3.1 decodeRemovalReentryProtection」](https://svip.iocoder.cn/Netty/Codec-1-1-ByteToMessageDecoder-core-impl/#) 中。
+
+- 第 32 至 39 行：用户主动删除该 Handler ，继续操作 `in` 是不安全的，所以结束循环。
+
+- 第 42 行：直接判断
+
+   
+
+  ```
+  out.size() == 0
+  ```
+
+   
+
+  比较合适。因为【第 8 至 24 行】的代码，能够保证
+
+   
+
+  ```
+  outSize
+  ```
+
+   
+
+  等于
+
+  零
+
+  。
+
+  - 第 43 至 45 行：如果**未读取**任何字节，`break` 结束循环。
+  - 第 46 至 49 行：如果可读字节**发生变化**，`continue` 重新开始循环，即继续读取。
+
+- 第 52 至 55 行：如果解码了消息，但是可读字节数未变，抛出 DecoderException 异常。说明，有问题。
+
+- 第 57 至 60 行：如果开启 `singleDecode` ，表示只解析一次，`break` 结束循环。
+
+- 第 62 至 66 行：如果发生异常，抛出 DecoderException 异常。
+
+😈 代码有一些长，胖友保持耐心看完哈。其实，蛮简单的。
+
+### 5.3.1 decodeRemovalReentryProtection
+
+`#decodeRemovalReentryProtection(ChannelHandlerContext ctx, ByteBuf in, List<Object> out)` 方法，执行解码。如果 Handler 准备移除，在解码完成后，进行移除。代码如下：
+
+```
+ 1: final void decodeRemovalReentryProtection(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception {
+ 2:     // 设置状态为 STATE_CALLING_CHILD_DECODE
+ 3:     decodeState = STATE_CALLING_CHILD_DECODE;
+ 4:     try {
+ 5:         // 执行解码
+ 6:         decode(ctx, in, out);
+ 7:     } finally {
+ 8:         // 判断是否准备移除
+ 9:         boolean removePending = decodeState == STATE_HANDLER_REMOVED_PENDING;
+10:         // 设置状态为 STATE_INIT
+11:         decodeState = STATE_INIT;
+12:         // 移除当前 Handler
+13:         if (removePending) {
+14:             handlerRemoved(ctx);
+15:         }
+16:     }
+17: }
+```
+
+- 第 3 行：设置状态(`decodeState`) 为 `STATE_CALLING_CHILD_DECODE` 。
+
+- 第 6 行：调用 `#decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out)` 方法，执行解码。代码如下：
+
+  ```
+  /**
+   * Decode the from one {@link ByteBuf} to an other. This method will be called till either the input
+   * {@link ByteBuf} has nothing to read when return from this method or till nothing was read from the input
+   * {@link ByteBuf}.
+   *
+   * @param ctx           the {@link ChannelHandlerContext} which this {@link ByteToMessageDecoder} belongs to
+   * @param in            the {@link ByteBuf} from which to read data
+   * @param out           the {@link List} to which decoded messages should be added
+   * @throws Exception    is thrown if an error occurs
+   */
+  protected abstract void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception;
+  ```
+
+  - 子类实现该方法，就可以愉快的解码消息了，**并且，也只需要实现该方法**。其它的逻辑，ByteToMessageDecoder 已经全部帮忙实现了。
+
+- 第 9 行：判断是否准备移除。那么什么情况下，会出现
+
+   
+
+  ```
+  decodeState == STATE_HANDLER_REMOVED_PENDING
+  ```
+
+   
+
+  成立呢？详细解析，见
+
+   
+
+  「5.7 handlerRemoved」
+
+   
+
+  。
+
+  - 第 11 行：设置状态(`decodeState`) 为 `STATE_HANDLER_REMOVED_PENDING` 。
+  - 第 12 至 15 行：如果准备移除，则调用 `#handlerRemoved(ChannelHandlerContext ctx)` 方法，移除当前 Handler 。详细解析，见 [「5.7 handlerRemoved」](https://svip.iocoder.cn/Netty/Codec-1-1-ByteToMessageDecoder-core-impl/#) 。
+
+## 5.4 channelReadComplete
+
+`#channelReadComplete(ChannelHandlerContext ctx)` 方法，代码如下：
+
+```
+ 1: @Override
+ 2: public void channelReadComplete(ChannelHandlerContext ctx) throws Exception {
+ 3:     // 重置 numReads
+ 4:     numReads = 0;
+ 5:     // 释放部分的已读
+ 6:     discardSomeReadBytes();
+ 7:     // 未解码到消息，并且未开启自动读取，则再次发起读取，期望读取到更多数据，以便解码到消息
+ 8:     if (decodeWasNull) {
+ 9:         decodeWasNull = false; // 重置 decodeWasNull
+10:         if (!ctx.channel().config().isAutoRead()) {
+11:             ctx.read();
+12:         }
+13:     }
+14:     // 触发 Channel ReadComplete 事件到下一个节点
+15:     ctx.fireChannelReadComplete();
+16: }
+```
+
+- 第 4 行：重置 `numReads` 。
+- 第 6 行：调用 `#discardSomeReadBytes()` 方法，释放部分的已读。
+- 第 7 至 13 行：未解码到消息( `decodeWasNull == true` )，并且未开启自动读取( `ctx.channel().config().isAutoRead() == false` )，则再次发起读取，期望读取到更多数据，以便解码到消息。
+- 第 15 行：触发 Channel ReadComplete 事件到下一个节点。
+
+## 5.5 channelInactive
+
+`#channelInactive(ChannelHandlerContext ctx)` 方法，通道处于未激活( Inactive )，解码完剩余的消息，并释放相关资源。代码如下：
+
+```
+@Override
+public void channelInactive(ChannelHandlerContext ctx) throws Exception {
+    channelInputClosed(ctx, true);
+}
+```
+
+- 调用 `#channelInputClosed(ChannelHandlerContext ctx, boolean callChannelInactive)` 方法，执行 Channel 读取关闭的逻辑。代码如下：
+
+  ```
+   1: private void channelInputClosed(ChannelHandlerContext ctx, boolean callChannelInactive) throws Exception {
+   2:     // 创建 CodecOutputList 对象
+   3:     CodecOutputList out = CodecOutputList.newInstance();
+   4:     try {
+   5:         // 当 Channel 读取关闭时，执行解码剩余消息的逻辑
+   6:         channelInputClosed(ctx, out);
+   7:     } catch (DecoderException e) {
+   8:         throw e;
+   9:     } catch (Exception e) {
+  10:         throw new DecoderException(e);
+  11:     } finally {
+  12:         try {
+  13:             // 释放 cumulation
+  14:             if (cumulation != null) {
+  15:                 cumulation.release();
+  16:                 cumulation = null;
+  17:             }
+  18:             int size = out.size();
+  19:             // 触发 Channel Read 事件到下一个节点。可能是多条消息
+  20:             fireChannelRead(ctx, out, size);
+  21:             // 如果有解码到消息，则触发 Channel ReadComplete 事件到下一个节点。
+  22:             if (size > 0) {
+  23:                 // Something was read, call fireChannelReadComplete()
+  24:                 ctx.fireChannelReadComplete();
+  25:             }
+  26:             // 如果方法调用来源是 `#channelInactive(...)` ，则触发 Channel Inactive 事件到下一个节点
+  27:             if (callChannelInactive) {
+  28:                 ctx.fireChannelInactive();
+  29:             }
+  30:         } finally {
+  31:             // 回收 CodecOutputList 对象
+  32:             // Recycle in all cases
+  33:             out.recycle();
+  34:         }
+  35:     }
+  36: }
+  ```
+
+  - 第 3 行：创建 CodecOutputList 对象。
+
+    - 第 6 行：调用 `#channelInputClosed(ChannelHandlerContext ctx, List<Object> out)` 方法，当 Channel 读取关闭时，执行解码剩余消息的逻辑。代码如下：
+
+      ```
+      /**
+       * Called when the input of the channel was closed which may be because it changed to inactive or because of
+       * {@link ChannelInputShutdownEvent}.
+       */
+      void channelInputClosed(ChannelHandlerContext ctx, List<Object> out) throws Exception {
+          if (cumulation != null) {
+              // 执行解码
+              callDecode(ctx, cumulation, out);
+              // 最后一次，执行解码
+              decodeLast(ctx, cumulation, out);
+          } else {
+              // 最后一次，执行解码
+              decodeLast(ctx, Unpooled.EMPTY_BUFFER, out);
+          }
+      }
+      
+      /**
+       * Is called one last time when the {@link ChannelHandlerContext} goes in-active. Which means the
+       * {@link #channelInactive(ChannelHandlerContext)} was triggered.
+       *
+       * By default this will just call {@link #decode(ChannelHandlerContext, ByteBuf, List)} but sub-classes may
+       * override this for some special cleanup operation.
+       */
+      protected void decodeLast(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception {
+          if (in.isReadable()) {
+              // Only call decode() if there is something left in the buffer to decode.
+              // See https://github.com/netty/netty/issues/4386
+              decodeRemovalReentryProtection(ctx, in, out);
+          }
+      }
+      ```
+
+      - 其中，`#decodeLast(ChannelHandlerContext ctx, ByteBuf in, List<Object> out)` 方法，是可以被重写的。例如，HttpObjectDecoder 就重写了该方法。
+
+    - 第 7 至 10 行：如果发生异常，就抛出 DecoderException 异常。
+
+  - 第 13 至 17 行：释放 `cumulation` 。
+
+  - 第 20 行：调用 `#fireChannelRead(ChannelHandlerContext ctx, List<Object> msgs, int numElements)` **静态**方法，触发 Channel Read 事件。可能是多条消息。
+
+  - 第 21 至 25 行：如果有解码到消息( `size > 0` )，则触发 Channel ReadComplete 事件到下一个节点。
+
+  - 第 26 至 29 行：如果方法调用来源是 `#channelInactive(...)` ，则触发 Channel Inactive 事件到下一个节点。
+
+  - 第 30 至 35 行：回收 CodecOutputList 对象。
+
+😈 对于该方法的目的，笔者的理解是，尽可能在解码一次剩余的 `cumulation` ，在 Channel 变成未激活时。细节好多呀！！！
+
+## 5.6 userEventTriggered
+
+`#userEventTriggered(ChannelHandlerContext ctx, Object evt)` 方法，处理 ChannelInputShutdownEvent 事件，即 Channel 关闭读取。代码如下：
+
+```
+@Override
+public void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws Exception {
+    if (evt instanceof ChannelInputShutdownEvent) {
+        // The decodeLast method is invoked when a channelInactive event is encountered.
+        // This method is responsible for ending requests in some situations and must be called
+        // when the input has been shutdown.
+        channelInputClosed(ctx, false);
+    }
+    // 继续传播 evt 到下一个节点
+    super.userEventTriggered(ctx, evt);
+}
+```
+
+- 调用 `#channelInputClosed(ChannelHandlerContext ctx, boolean callChannelInactive)` 方法，执行 Channel 读取关闭的逻辑。
+- 继续传播 `evt` 到下一个节点。
+
+😈 对于该方法的目的，笔者的理解是，尽可能在解码一次剩余的 `cumulation` ，在 Channel 关闭读取。细节好多呀！！！
+
+## 5.7 handlerRemoved
+
+`#handlerRemoved(ChannelHandlerContext ctx)` 方法，代码如下：
+
+```
+ 1: @Override
+ 2: public final void handlerRemoved(ChannelHandlerContext ctx) throws Exception {
+ 3:     // 状态处于 STATE_CALLING_CHILD_DECODE 时，标记状态为 STATE_HANDLER_REMOVED_PENDING
+ 4:     if (decodeState == STATE_CALLING_CHILD_DECODE) {
+ 5:         decodeState = STATE_HANDLER_REMOVED_PENDING;
+ 6:         return; // 返回！！！！结合 `#decodeRemovalReentryProtection(...)` 方法，一起看。
+ 7:     }
+ 8:     ByteBuf buf = cumulation;
+ 9:     if (buf != null) {
+10:         // 置空 cumulation
+11:         // Directly set this to null so we are sure we not access it in any other method here anymore.
+12:         cumulation = null;
+13: 
+14:         int readable = buf.readableBytes();
+15:         // 有可读字节
+16:         if (readable > 0) {
+17:             // 读取剩余字节，并释放 buf
+18:             ByteBuf bytes = buf.readBytes(readable);
+19:             buf.release();
+20:             // 触发 Channel Read 到下一个节点
+21:             ctx.fireChannelRead(bytes);
+22:         // 无可读字节
+23:         } else {
+24:             // 释放 buf
+25:             buf.release();
+26:         }
+27: 
+28:         // 置空 numReads
+29:         numReads = 0;
+30:         // 触发 Channel ReadComplete 到下一个节点
+31:         ctx.fireChannelReadComplete();
+32:     }
+33:     // 执行移除逻辑
+34:     handlerRemoved0(ctx);
+35: }
+```
+
+- 第 3 至 7 行：如果状态( `decodeState` )处于 `STATE_CALLING_CHILD_DECODE` 时，说明正在执行 `#decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out)` 方法中。如果此时，直接往下执行，`cumulation` 将被直接释放，而 `#decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out)` 方法可能正在解码中，很大可能性造成影响，导致错误。所以，此处仅仅标记状态( `decodeState` )为 `STATE_HANDLER_REMOVED_PENDING` 。等到 `#decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out)` 方法执行完成后，在进行移除。胖友，此时可以再跳回 [「5.3.1 decodeRemovalReentryProtection」](https://svip.iocoder.cn/Netty/Codec-1-1-ByteToMessageDecoder-core-impl/#) ，进行再次理解。
+
+- 【有可读字节】第 15 至 21 行：读取剩余字节，并释放 `buf` 。然后，触发 Channel Read 到下一个节点。通过这样的方式，避免 `cumulation` 中，有字节被“丢失”，即使当前可能无法解码成一个数据包。
+
+- 【无可读字节】第 22 至 26 行：直接释放 `buf` 。
+
+- 第 29 行：置空 `numReads` 。
+
+- 第 34 行：调用 `#handlerRemoved0(ChannelHandlerContext ctx)` 方法，执行移除逻辑。代码如下：
+
+  ```
+  /**
+   * Gets called after the {@link ByteToMessageDecoder} was removed from the actual context and it doesn't handle
+   * events anymore.
+   */
+  protected void handlerRemoved0(ChannelHandlerContext ctx) throws Exception { }
+  ```
+
+  - 默认情况下，该方法实现为空。目前可重写该方法，实现自定义的资源释放。目前重写该方法的类，例如：Http2ConnectionHandler、SslHandler 等等。
+
+## 5.8 internalBuffer
+
+`#internalBuffer()` 方法，获得 ByteBuf 对象。代码如下：
+
+```
+/**
+ * Returns the internal cumulative buffer of this decoder. You usually
+ * do not need to access the internal buffer directly to write a decoder.
+ * Use it only when you must use it at your own risk.
+ */
+protected ByteBuf internalBuffer() {
+    if (cumulation != null) {
+        return cumulation;
+    } else {
+        return Unpooled.EMPTY_BUFFER;
+    }
+}
+```
+
+## 5.9 actualReadableBytes
+
+`#actualReadableBytes()` 方法，获得可读字节数。代码如下：
+
+```
+/**
+ * Returns the actual number of readable bytes in the internal cumulative
+ * buffer of this decoder. You usually do not need to rely on this value
+ * to write a decoder. Use it only when you must use it at your own risk.
+ * This method is a shortcut to {@link #internalBuffer() internalBuffer().readableBytes()}.
+ */
+protected int actualReadableBytes() {
+    return internalBuffer().readableBytes();
+}
+```
+
+# 666. 彩蛋
+
+细节有点多，可能对如下小节理解不够到位。如有错误，烦请胖友教育。
+
+- [「5.5 channelInactive」](https://svip.iocoder.cn/Netty/Codec-1-1-ByteToMessageDecoder-core-impl/#)
+- [「5.6 userEventTriggered」](https://svip.iocoder.cn/Netty/Codec-1-1-ByteToMessageDecoder-core-impl/#)
+- [「5.7 handlerRemoved」](https://svip.iocoder.cn/Netty/Codec-1-1-ByteToMessageDecoder-core-impl/#)
+
+------
+
+本文参考如下文章：
+
+- 简书闪电侠 [《netty源码分析之拆包器的奥秘》](https://www.jianshu.com/p/dc26e944da95)
+- Hypercube [《自顶向下深入分析Netty（八）–CodecHandler》](https://www.jianshu.com/p/7c439cc7b01c)
\ No newline at end of file
diff --git a/netty/55-Netty 源码解析-Codec 之 ByteToMessageDecoder（二）FrameDecoder.assets/01.png b/netty/55-Netty 源码解析-Codec 之 ByteToMessageDecoder（二）FrameDecoder.assets/01.png
new file mode 100644
index 0000000..fb73a59
Binary files /dev/null and b/netty/55-Netty 源码解析-Codec 之 ByteToMessageDecoder（二）FrameDecoder.assets/01.png differ
diff --git a/netty/55-Netty 源码解析-Codec 之 ByteToMessageDecoder（二）FrameDecoder.assets/02.png b/netty/55-Netty 源码解析-Codec 之 ByteToMessageDecoder（二）FrameDecoder.assets/02.png
new file mode 100644
index 0000000..1bd062d
Binary files /dev/null and b/netty/55-Netty 源码解析-Codec 之 ByteToMessageDecoder（二）FrameDecoder.assets/02.png differ
diff --git a/netty/55-Netty 源码解析-Codec 之 ByteToMessageDecoder（二）FrameDecoder.md b/netty/55-Netty 源码解析-Codec 之 ByteToMessageDecoder（二）FrameDecoder.md
new file mode 100644
index 0000000..c0b56bc
--- /dev/null
+++ b/netty/55-Netty 源码解析-Codec 之 ByteToMessageDecoder（二）FrameDecoder.md	
@@ -0,0 +1,600 @@
+# 精尽 Netty 源码解析 —— Codec 之 ByteToMessageDecoder（二）FrameDecoder
+
+# 1. 概述
+
+在 [《精尽 Netty 源码解析 —— Codec 之 ByteToMessageDecoder（一）》](http://svip.iocoder.cn/Netty/Codec-1-1-ByteToMessageDecoder-core-impl) 中，我们看到 ByteToMessageDecoder 有四个 FrameDecoder 实现类：
+
+- ① FixedLengthFrameDecoder ，基于**固定长度**消息进行粘包拆包处理的。
+- ② LengthFieldBasedFrameDecoder ，基于**消息头指定消息长度**进行粘包拆包处理的。
+- ③ LineBasedFrameDecoder ，基于**换行**来进行消息粘包拆包处理的。
+- ④ DelimiterBasedFrameDecoder ，基于**指定消息边界方式**进行粘包拆包处理的。
+
+实际上，上述四个 FrameDecoder 实现可以进行规整：
+
+- ① 是 ② 的特例，**固定长度**是**消息头指定消息长度**的一种形式。
+- ③ 是 ④ 的特例，**换行**是于**指定消息边界方式**的一种形式。
+
+本文，笔者只分享 ① 和 ③ 。对于 ② 和 ④ ，会提供相关的文章。
+
+# 2. FixedLengthFrameDecoder
+
+`io.netty.handler.codec.FixedLengthFrameDecoder` ，继承 ByteToMessageDecoder 抽象类，基于**固定长度**消息进行粘包拆包处理的。
+
+如果下是固定长度为 3 的数据流解码：
+
+```
++---+----+------+----+      +-----+-----+-----+
+| A | BC | DEFG | HI |  ->  | ABC | DEF | GHI |
++---+----+------+----+      +-----+-----+-----+
+```
+
+## 2.1 构造方法
+
+```
+/**
+ * 固定长度
+ */
+private final int frameLength;
+
+/**
+ * Creates a new instance.
+ *
+ * @param frameLength the length of the frame
+ */
+public FixedLengthFrameDecoder(int frameLength) {
+    if (frameLength <= 0) {
+        throw new IllegalArgumentException("frameLength must be a positive integer: " + frameLength);
+    }
+    this.frameLength = frameLength;
+}
+```
+
+- `frameLength` 属性，固定长度。
+
+## 2.2 decode
+
+`#decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out)` 方法，执行解码。代码如下：
+
+```
+1: @Override
+2: protected final void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception {
+3:     // 解码消息
+4:     Object decoded = decode(ctx, in);
+5:     // 添加到 out 结果中
+6:     if (decoded != null) {
+7:         out.add(decoded);
+8:     }
+9: }
+```
+
+- 第 4 行：调用 `#decode(ChannelHandlerContext ctx, ByteBuf in)` 方法，解码消息。代码如下：
+
+  ```
+  /**
+   * Create a frame out of the {@link ByteBuf} and return it.
+   *
+   * @param   ctx             the {@link ChannelHandlerContext} which this {@link ByteToMessageDecoder} belongs to
+   * @param   in              the {@link ByteBuf} from which to read data
+   * @return  frame           the {@link ByteBuf} which represent the frame or {@code null} if no frame could
+   *                          be created.
+   */
+  protected Object decode(@SuppressWarnings("UnusedParameters") ChannelHandlerContext ctx, ByteBuf in) throws Exception {
+      // 可读字节不够 frameLength 长度，无法解码出消息。
+      if (in.readableBytes() < frameLength) {
+          return null;
+      // 可读字节足够 frameLength 长度，解码出一条消息。
+      } else {
+          return in.readRetainedSlice(frameLength);
+      }
+  }
+  ```
+
+  - 当可读字节足够 `frameLength` 长度时，调用 `ByteBuf#readRetainedSlice(int length)` 方法，读取一个 Slice ByteBuf 对象，并增加引用计数。并且该 Slice ByteBuf 作为解码的一条消息。另外，`ByteBuf#readRetainedSlice(int length)` 的过程，因为是共享原有 ByteBuf `in` 数组，所以不存在数据拷贝。
+
+- 第 5 至 8 行：若解码到消息，添加到 `out` 结果中。
+
+# 3. LineBasedFrameDecoder
+
+`io.netty.handler.codec.LineBasedFrameDecoder` ，继承 ByteToMessageDecoder 抽象类，基于**换行**来进行消息粘包拆包处理的。
+
+它会处理 `"\n"` 和 `"\r\n"` 两种换行符。
+
+## 3.1 构造方法
+
+```
+/**
+ * 一条消息的最大长度
+ *
+ * Maximum length of a frame we're willing to decode.
+ */
+private final int maxLength;
+/**
+ * 是否快速失败
+ *
+ * 当 true 时，未找到消息，但是超过最大长度，则马上触发 Exception 到下一个节点
+ * 当 false 时，未找到消息，但是超过最大长度，需要匹配到一条消息后，再触发 Exception 到下一个节点
+ *
+ * Whether or not to throw an exception as soon as we exceed maxLength.
+ */
+private final boolean failFast;
+/**
+ * 是否过滤掉换行分隔符。
+ *
+ * 如果为 true ，解码的消息不包含换行符。
+ */
+private final boolean stripDelimiter;
+
+/**
+ * 是否处于废弃模式
+ *
+ * 如果为 true ，说明解析超过最大长度( maxLength )，结果还是找不到换行符
+ *
+ * True if we're discarding input because we're already over maxLength.
+ */
+private boolean discarding;
+/**
+ * 废弃的字节数
+ */
+private int discardedBytes;
+
+/**
+ * 最后扫描的位置
+ *
+ * Last scan position.
+ */
+private int offset;
+
+/**
+ * Creates a new decoder.
+ * @param maxLength  the maximum length of the decoded frame.
+ *                   A {@link TooLongFrameException} is thrown if
+ *                   the length of the frame exceeds this value.
+ */
+public LineBasedFrameDecoder(final int maxLength) {
+    this(maxLength, true, false);
+}
+
+/**
+ * Creates a new decoder.
+ * @param maxLength  the maximum length of the decoded frame.
+ *                   A {@link TooLongFrameException} is thrown if
+ *                   the length of the frame exceeds this value.
+ * @param stripDelimiter  whether the decoded frame should strip out the
+ *                        delimiter or not
+ * @param failFast  If <tt>true</tt>, a {@link TooLongFrameException} is
+ *                  thrown as soon as the decoder notices the length of the
+ *                  frame will exceed <tt>maxFrameLength</tt> regardless of
+ *                  whether the entire frame has been read.
+ *                  If <tt>false</tt>, a {@link TooLongFrameException} is
+ *                  thrown after the entire frame that exceeds
+ *                  <tt>maxFrameLength</tt> has been read.
+ */
+public LineBasedFrameDecoder(final int maxLength, final boolean stripDelimiter, final boolean failFast) {
+    this.maxLength = maxLength;
+    this.failFast = failFast;
+    this.stripDelimiter = stripDelimiter;
+}
+```
+
+- ```
+  maxLength
+  ```
+
+   
+
+  属性，一条消息的最大长度。原本以为 LineBasedFrameDecoder 会比较简单，但是因为多了
+
+   
+
+  ```
+  maxLength
+  ```
+
+   
+
+  复杂很多。为什么这么说呢？
+
+  - 假设 `maxLength = 2` ，接收到的数据为 `"abcd\nEF\n"`( 直接以字符串举例，为了可阅读性 )，那么 `"abcd"` 是不符合条件的消息，因为长度为 4 ，超过最大长度 `maxLength` 。
+  - 但是考虑到拆粘包的情况，可能初始化接收到的是 `"abc"` ，那么无法匹配到 `\n` 换行符。但是呢，`"abc"` 的长度为 3，超过最大长度 `maxLength` ，需要等待读取到 `"d\n"` 部分，然后抛弃 `"abcd"` 整条。再之后，继续读取符合条件的 `"EF"` 段。
+  - 😈 比较绕，胖友好好理解下。
+
+- ```
+  failFast
+  ```
+
+   
+
+  属性，是否快速失败。
+
+  - `true` 时，未找到消息，但是超过最大长度，则马上触发 Exception 到下一个节点。
+  - 当 `false` 时，未找到消息，但是超过最大长度，需要匹配到一条消息后，再触发 Exception 到下一个节点。
+  - 😈 也有点绕，等下结合代码具体理解。
+
+- `stripDelimiter` 属性，是否过滤掉换行分隔符。如果为 `true` ，解码的消息不包含换行符。
+
+- ```
+  discarding
+  ```
+
+   
+
+  属性，是否处于废弃模式。如果为
+
+   
+
+  ```
+  true
+  ```
+
+   
+
+  ，说明解析超过最大长度(
+
+   
+
+  ```
+  maxLength
+  ```
+
+   
+
+  )，结果还是找不到换行符。
+
+  - 😈 也有点绕，等下结合代码具体理解。
+  - `discardedBytes` 属性，废弃的字节数。
+  - `offset` 属性，最后扫描的位置。
+
+## 3.2 decode
+
+`#decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out)` 方法，执行解码。代码如下：
+
+```
+@Override
+protected final void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception {
+    Object decoded = decode(ctx, in);
+    if (decoded != null) {
+        out.add(decoded);
+    }
+}
+```
+
+- 这段代码，和 `FixedLengthFrameDecoder#decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out)` 方法，是一样的。
+
+------
+
+`#decode(ChannelHandlerContext ctx, ByteBuf buffer)` 方法，执行解码。代码如下：
+
+```
+ 1: protected Object decode(ChannelHandlerContext ctx, ByteBuf buffer) throws Exception {
+ 2:     // 获得换行符的位置
+ 3:     final int eol = findEndOfLine(buffer);
+ 4:     if (!discarding) { // 未处于废弃模式
+ 5:         if (eol >= 0) { // 找到
+ 6:             final ByteBuf frame;
+ 7:             final int length = eol - buffer.readerIndex(); // 读取长度
+ 8:             final int delimLength = buffer.getByte(eol) == '\r' ? 2 : 1; // 分隔符的长度。2 为 `\r\n` ，1 为 `\n`
+ 9: 
+10:             // 超过最大长度
+11:             if (length > maxLength) {
+12:                 // 设置新的读取位置
+13:                 buffer.readerIndex(eol + delimLength);
+14:                 // 触发 Exception 到下一个节点
+15:                 fail(ctx, length);
+16:                 // 返回 null ，即未解码到消息
+17:                 return null;
+18:             }
+19: 
+20:             // 解码出一条消息。
+21:             if (stripDelimiter) {
+22:                 frame = buffer.readRetainedSlice(length);
+23:                 buffer.skipBytes(delimLength); // 忽略换行符
+24:             } else {
+25:                 frame = buffer.readRetainedSlice(length + delimLength);
+26:             }
+27: 
+28:             // 返回解码的消息
+29:             return frame;
+30:         } else { // 未找到
+31:             final int length = buffer.readableBytes();
+32:             // 超过最大长度
+33:             if (length > maxLength) {
+34:                 // 记录 discardedBytes
+35:                 discardedBytes = length;
+36:                 // 跳到写入位置
+37:                 buffer.readerIndex(buffer.writerIndex());
+38:                 // 标记 discarding 为废弃模式
+39:                 discarding = true;
+40:                 // 重置 offset
+41:                 offset = 0;
+42:                 // 如果快速失败，则触发 Exception 到下一个节点
+43:                 if (failFast) {
+44:                     fail(ctx, "over " + discardedBytes);
+45:                 }
+46:             }
+47:             return null;
+48:         }
+49:     } else { // 处于废弃模式
+50:         if (eol >= 0) { // 找到
+51:             final int length = discardedBytes + eol - buffer.readerIndex(); // 读取长度
+52:             final int delimLength = buffer.getByte(eol) == '\r' ? 2 : 1; // 分隔符的长度。2 为 `\r\n` ，1 为 `\n`
+53:             // 设置新的读取位置
+54:             buffer.readerIndex(eol + delimLength);
+55:             // 重置 discardedBytes
+56:             discardedBytes = 0;
+57:             // 设置 discarding 不为废弃模式
+58:             discarding = false;
+59:             // 如果不为快速失败，则触发 Exception 到下一个节点
+60:             if (!failFast) {
+61:                 fail(ctx, length);
+62:             }
+63:         } else { // 未找到
+64:             // 增加 discardedBytes
+65:             discardedBytes += buffer.readableBytes();
+66:             // 跳到写入位置
+67:             buffer.readerIndex(buffer.writerIndex());
+68:         }
+69:         return null;
+70:     }
+71: }
+```
+
+- 第 3 行：调用 `#findEndOfLine(final ByteBuf buffer)` 方法，获得换行符的位置。详细解析，这里胖友先跳到 [「3.3 findEndOfLine」](https://svip.iocoder.cn/Netty/Codec-1-2-ByteToMessageDecoder-FrameDecoder/#) 中。
+
+- =============== 未处于 `discarding` 模式 ===============
+
+- 根据是否找到换行符，分成 ① ② 两种情况。
+
+- ① 第 5 行：**找到**换行符。
+
+- 第 7 至 8 行：获得读取消息的长度、换行符的长度。
+
+- 第 11 行：读取消息的长度，超过最大长度，则
+
+  丢弃
+
+  该消息。
+
+  - 第 13 行：`buffer` 设置新的读取位置。
+  - 第 15 行：调用 `#fail(...)` 方法，触发 Exception 到下一个节点。详细解析，见 [「3.4 fail」](https://svip.iocoder.cn/Netty/Codec-1-2-ByteToMessageDecoder-FrameDecoder/#) 。😈 注意，此处和 `failFast` 没有关系。
+  - 【失败】第 17 行：返回 `null` ，即未解码到消息。
+
+- 【成功】第 20 至 26 行：解码出一条消息。调用 `ByteBuf#readRetainedSlice(int length)` 方法，读取一个 Slice ByteBuf 对象，并增加引用计数。并且该 Slice ByteBuf 作为解码的一条消息。另外，`ByteBuf#readRetainedSlice(int length)` 的过程，因为是共享原有 ByteBuf `in` 数组，所以不存在数据拷贝。
+
+- ② 第 30 行：**未找到**换行符，说明当前 `buffer` **不存在**完整的消息。需要继续读取新的数据，再次解码拆包。
+
+- 第 33 行：可读字节，超过最大长度，那么即使后续找到换行符，消息也**一定**超过最大长度。
+
+- 第 35 行：记录 `discardedBytes` 。因为【第 37 行】的代码，`buffer` 跳到写入位置，也就是抛弃了 `discardedBytes` 字节数。
+
+- 第 39 行：标记
+
+   
+
+  ```
+  discarding
+  ```
+
+   
+
+  为
+
+   
+
+  ```
+  true
+  ```
+
+   
+
+  ，进入废弃模式。那么，后续就会执行【第 49 至 70 行】的代码逻辑，寻找到换行符，解码拆包出该消息，并
+
+  抛弃
+
+  它。
+
+  - 😈 这段，好好理解下。
+
+- 第 41 行：重置 `offset` 为 0 。
+
+- 第 42 至 45 行：如果快速失败( `failFast = true` )，调用 `#fail(...)` 方法，触发 Exception 到下一个节点。那么，不快速失败( `failFast = false` )呢？继续往下走，答案在【第 59 至 61 行】的代码，见分晓。
+
+- 第 47 行：【失败】第 17 行：返回 `null` ，即未解码到消息。
+
+- =============== 正处于 `discarding` 模式 ===============
+
+- `discarding` 模式是什么呢？在【第 33 至 46 行】的代码，如果已读取的字节数，超过最大长度，那么进入 `discarding` 模式，继续寻找到换行符，解码拆包出该消息，并**抛弃**它。😈 实际上，它的效果是【第 30 至 48 行】+【第 49 至 69 行】和【第 10 至 18 行】的代码的效果是**等价的**，只是说【第 30 至 48 行】的代码，因为数据包是**不完整**( 找不到换行符 )的，所以进入【第 49 至 69 行】的代码。
+
+- 根据是否找到换行符，分成 ① ② 两种情况。
+
+- ① 第 50 行：**找到**换行符。
+
+- 第 51 行：读取长度。此处的长度，算上了
+
+   
+
+  ```
+  discardedBytes
+  ```
+
+   
+
+  的部分。
+
+  - 第 52 行：获得换行符的长度。
+
+- 第 54 行：设置新的读取位置。因为，**找到**换行符。
+
+- 第 56 行：重置 `discardedBytes` 为 0 。因为，**找到**换行符。
+
+- 第 58 行：重置 `offset` 为 0 。因为，**找到**换行符。
+
+- 第 59 至 62 行：如果不为快速失败(
+
+   
+
+  ```
+  failFast = false
+  ```
+
+   
+
+  )，调用
+
+   
+
+  ```
+  #fail(...)
+  ```
+
+   
+
+  方法，触发 Exception 到下一个节点。
+
+  - 和【第 42 至 45 行】的代码，相对。
+  - 也就说，`failFast = false` 的情况下，只有在解析到完整的消息，**才**触发 Exception 到下一个节点。😈 是不是很绕，哈哈哈哈。
+
+- 【失败】第 69 行：返回 `null` ，虽然解码到消息，但是因为消息长度超过最大长度，所以进行**丢失**。和【第 17 行】的代码，是一个目的。
+
+- ② 第 63 行：**未找到**换行符，说明当前 `buffer` **不存在**完整的消息。需要继续读取新的数据，再次解码拆包。
+
+- 第 65 行：增加 `discardedBytes` 。
+
+- 第 67 行：`buffer` 跳到写入位置。
+
+- 第 69 行：返回 `null` ，即未解码到消息。
+
+😈 整体逻辑，有点绕，不过很有趣。
+
+## 3.3 findEndOfLine
+
+`#findEndOfLine(final ByteBuf buffer)` 方法，获得换行符的位置。代码如下：
+
+```
+   /**
+    * Returns the index in the buffer of the end of line found.
+    * Returns -1 if no end of line was found in the buffer.
+    */
+ 1: private int findEndOfLine(final ByteBuf buffer) {
+ 2:     int totalLength = buffer.readableBytes();
+ 3:     int i = buffer.forEachByte(buffer.readerIndex() + offset, totalLength - offset, ByteProcessor.FIND_LF);
+ 4:     // 找到
+ 5:     if (i >= 0) {
+ 6:         // 重置 offset
+ 7:         offset = 0;
+ 8:         // 如果前一个字节位 `\r` ，说明找到的是 `\n` ，所以需要 -1 ，因为寻找的是首个换行符的位置
+ 9:         if (i > 0 && buffer.getByte(i - 1) == '\r') {
+10:             i--;
+11:         }
+12:     // 未找到，记录 offset
+13:     } else {
+14:         offset = totalLength;
+15:     }
+16:     return i;
+17: }
+```
+
+- 关于 `offset` 的逻辑，笔者觉得有点问题。在这里，胖友先无视掉它。稍后，我们在统一分享。
+- 第 3 行：在 `buffer` 的 `[readerIndex, readerIndex + readableBytes)` 位置范围内，查找 `\n` 换行符的位置。😈 在忽略 `offset` 的前提下。
+- 【有找到】
+  - 第 7 行：重置 `offset` 。
+  - 第 8 至 11 行：如果前一个字节位 `\r` ，说明找到的是 `\n` ，所以需要 -1 ，因为寻找的是首个换行符的位置。
+- 【没找到】
+  - 第 14 行：记录 `offset` 。
+- 第 16 行：返回位置 `i` 。
+
+## 3.4 fail
+
+`#fail(...)` 方法，触发 Exception 到下一个节点。代码如下：
+
+```
+private void fail(final ChannelHandlerContext ctx, int length) {
+    fail(ctx, String.valueOf(length));
+}
+
+private void fail(final ChannelHandlerContext ctx, String length) {
+    ctx.fireExceptionCaught(new TooLongFrameException("frame length (" + length + ") exceeds the allowed maximum (" + maxLength + ')'));
+}
+```
+
+## 3.5 可能是 offset 的一个 bug
+
+这里，只能说是 `offset` 的一个 bug ，也是笔者的一个推测。下面，我们来推导下。
+
+[![代码图](55-Netty 源码解析-Codec 之 ByteToMessageDecoder（二）FrameDecoder.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_10_01/01.png)代码图
+
+- 第一根红线，在 `discarding` 模式下，如果读取不到换行符，每次 `buffer` 的读取位置，都会跳到写入位置。
+- 第三根红线，`offset` 记录**上一次**读取的字节数。
+- 第二根红线，如果查找的范围 `+ offset` ，但是 `buffer` 的读取位置已经跳到写入位置，岂不是和 `offset` 的重复了？？
+
+所以，笔者认为，应该去掉 `offset` 的相关逻辑。
+
+------
+
+下面，我们以一个实际情况，举个例子。如下图所示：
+
+[![例子](55-Netty 源码解析-Codec 之 ByteToMessageDecoder（二）FrameDecoder.assets/02.png)](http://static.iocoder.cn/images/Netty/2018_12_04/02.png)例子
+
+- 假设 `maxLength` 等于 1 。
+- 第一次接收到数据 `"012"` ，未找到换行符，但是超过最大长度，所以进入 `discarding` 模式。
+- 第二次接收到数据 `"34"` ，未找到换行符，`r = w = 4` ，并且 `offset = 2` 。
+- 第三次接收到数据 `"\n"` ，但是查找范围是 `buffer.readerIndex() + offset = 4 + 2 > 5` ，超过范围。
+
+因此，笔者觉得，这个可能是 offset 的一个 bug 。
+
+# 4. LengthFieldBasedFrameDecoder
+
+`io.netty.handler.codec.LengthFieldBasedFrameDecoder` ，继承 ByteToMessageDecoder 抽象类，基于**消息头指定消息长度**进行粘包拆包处理的。
+
+详细解析，见基友【闪电侠】的 [《netty源码分析之LengthFieldBasedFrameDecoder》](https://www.jianshu.com/p/a0a51fd79f62) 一文。
+
+或者，【Hypercube】的 [《自顶向下深入分析Netty（八）– LengthFieldBasedFrameDecoder》](https://www.jianshu.com/p/c3fbd6113dd6) 一文。
+
+# 5. DelimiterBasedFrameDecoder
+
+`io.netty.handler.codec.DelimiterBasedFrameDecoder` ，继承 ByteToMessageDecoder 抽象类，基于**指定消息边界方式**进行粘包拆包处理的。
+
+> FROM [《自顶向下深入分析Netty（八）–CodecHandler》](https://www.jianshu.com/p/7c439cc7b01c) 的 [「8.1.2 DelimiterBasedFrameDecoder」](https://svip.iocoder.cn/Netty/Codec-1-2-ByteToMessageDecoder-FrameDecoder/#) 小节。
+>
+> 如下内容，因为排版，所以未使用引用语法。
+
+该解码器是更通用的分隔符解码器，可支持多个分隔符，每个分隔符可为一个或多个字符。如果定义了多个分隔符，并且可解码出多个消息帧，则选择产生最小帧长的结果。例如，使用行分隔符`\r\n`和`\n`分隔：
+
+```
++--------------+
+| ABC\nDEF\r\n |
++--------------+
+```
+
+可有两种结果：
+
+```
++-----+-----+              +----------+   
+| ABC | DEF |  (√)   和    | ABC\nDEF |  (×)
++-----+-----+              +----------+
+```
+
+该编码器可配置的变量与`LineBasedFrameDecoder`类似，只是多了一个`ByteBuf[] delimiters`用于配置具体的分隔符。
+Netty在`Delimiters`类中定义了两种默认的分隔符，分别是NULL分隔符和行分隔符：
+
+```
+public static ByteBuf[] nulDelimiter() {
+    return new ByteBuf[] {
+            Unpooled.wrappedBuffer(new byte[] { 0 }) };
+}
+
+public static ByteBuf[] lineDelimiter() {
+    return new ByteBuf[] {
+            Unpooled.wrappedBuffer(new byte[] { '\r', '\n' }),
+            Unpooled.wrappedBuffer(new byte[] { '\n' }),
+    };
+}
+```
+
+# 666. 彩蛋
+
+在 FixedLengthFrameDecoder 那里，卡了好长时间，Netty 在细节这块，扣的真给力啊！！！
+
+本文参考如下文章：
+
+- 简书闪电侠 [《netty源码分析之LengthFieldBasedFrameDecoder》](https://www.jianshu.com/p/a0a51fd79f62)
+- Hypercube [《自顶向下深入分析Netty（八）–CodecHandler》](https://www.jianshu.com/p/7c439cc7b01c)
\ No newline at end of file
diff --git a/netty/56-Netty 源码解析-Codec 之 MessageToByteEncoder.assets/01.png b/netty/56-Netty 源码解析-Codec 之 MessageToByteEncoder.assets/01.png
new file mode 100644
index 0000000..9730d91
Binary files /dev/null and b/netty/56-Netty 源码解析-Codec 之 MessageToByteEncoder.assets/01.png differ
diff --git a/netty/56-Netty 源码解析-Codec 之 MessageToByteEncoder.md b/netty/56-Netty 源码解析-Codec 之 MessageToByteEncoder.md
new file mode 100644
index 0000000..196ea1a
--- /dev/null
+++ b/netty/56-Netty 源码解析-Codec 之 MessageToByteEncoder.md	
@@ -0,0 +1,312 @@
+# 精尽 Netty 源码解析 —— Codec 之 MessageToByteEncoder
+
+# 1. 概述
+
+本文，我们来分享 MessageToByteEncoder 部分的内容。
+
+MessageToByteEncoder 负责将消息**编码**成字节。核心类图如下：
+
+[![核心类图](56-Netty 源码解析-Codec 之 MessageToByteEncoder.assets/01.png)](http://static.iocoder.cn/images/Netty/2018_12_18/01.png)核心类图
+
+ByteToMessageDecoder 本身是个**抽象**类，其下有多个子类，笔者简单整理成两类，可能不全哈：
+
+- 蓝框
+
+  部分，将消息
+
+  压缩
+
+  ，主要涉及相关压缩算法，例如：GZip、BZip 等等。
+
+  - 它要求消息类型是 ByteBuf ，将已经转化好的字节流，进一步压缩。
+
+- 黄框
+
+  部分，将消息使用
+
+  指定序列化方式
+
+  序列化成字节。例如：JSON、XML 等等。
+
+  - 因为 Netty 没有内置的 JSON、XML 等相关的类库，所以不好提供类似 JSONEncoder 或 XMLEncoder ，所以图中笔者就使用 `netty-example` 提供的 NumberEncoder 。
+
+在 [《精尽 Netty 源码解析 —— Codec 之 ByteToMessageDecoder（一）Cumulator》](http://svip.iocoder.cn/Netty/Codec-1-1-ByteToMessageDecoder-core-impl) 中，我们提到**粘包拆包**的现象，所以在实际使用 Netty 编码消息时，还需要有为了解决**粘包拆包**的 Encoder 实现类，例如：换行、定长等等方式。关于这块内容，胖友可以看看 [《netty使用MessageToByteEncoder 自定义协议》](https://www.codetd.com/article/1539061) 。
+
+# 2. MessageToByteEncoder
+
+`io.netty.handler.codec.MessageToByteEncoder` ，继承 ChannelOutboundHandlerAdapter 类，负责将消息**编码**成字节，支持**匹配指定类型**的消息。
+
+## 2.1 构造方法
+
+```
+public abstract class MessageToByteEncoder<I> extends ChannelOutboundHandlerAdapter {
+
+    /**
+     * 类型匹配器
+     */
+    private final TypeParameterMatcher matcher;
+    /**
+     * 是否偏向使用 Direct 内存
+     */
+    private final boolean preferDirect;
+
+    protected MessageToByteEncoder() {
+        this(true);
+    }
+
+    protected MessageToByteEncoder(Class<? extends I> outboundMessageType) {
+        this(outboundMessageType, true);
+    }
+
+    protected MessageToByteEncoder(boolean preferDirect) {
+        // <1> 获得 matcher
+        matcher = TypeParameterMatcher.find(this, MessageToByteEncoder.class, "I");
+        this.preferDirect = preferDirect;
+    }
+
+    protected MessageToByteEncoder(Class<? extends I> outboundMessageType, boolean preferDirect) {
+        // <2> 获得 matcher
+        matcher = TypeParameterMatcher.get(outboundMessageType);
+        this.preferDirect = preferDirect;
+    }
+    
+    // ... 省略其他无关代码
+}
+```
+
+- ```
+  matcher
+  ```
+
+   
+
+  属性，有
+
+  两种
+
+  方式赋值。
+
+  - 【常用】`<1>` 处，使用类的 `I` 泛型对应的 TypeParameterMatcher 类型匹配器。
+  - `<2>` 处，使用 `inboundMessageType` 参数对应的 TypeParameterMatcher 类型匹配器。
+  - 在大多数情况下，我们不太需要特别详细的了解 `io.netty.util.internal.TypeParameterMatcher` 的代码实现，感兴趣的胖友可以自己看看 [《netty 简单Inbound通道处理器（SimpleChannelInboundHandler）》](http://donald-draper.iteye.com/blog/2387772) 的 [「TypeParameterMatcher」](https://svip.iocoder.cn/Netty/Codec-2-1-MessageToByteEncoder-core-impl/#) 部分。
+
+- `preferDirect` 属性，是否偏向使用 Direct 内存。默认为 `true` 。
+
+## 2.2 acceptInboundMessage
+
+`#acceptInboundMessage(Object msg)` 方法，判断消息是否匹配。代码如下：
+
+```
+/**
+ * Returns {@code true} if the given message should be handled. If {@code false} it will be passed to the next
+ * {@link ChannelInboundHandler} in the {@link ChannelPipeline}.
+ */
+public boolean acceptInboundMessage(Object msg) {
+    return matcher.match(msg);
+}
+```
+
+一般情况下，`matcher` 的类型是 ReflectiveMatcher( 它是 TypeParameterMatcher 的内部类 )。代码如下：
+
+```
+private static final class ReflectiveMatcher extends TypeParameterMatcher {
+    
+    /**
+     * 类型
+     */
+    private final Class<?> type;
+    
+    ReflectiveMatcher(Class<?> type) {
+        this.type = type;
+    }
+    
+    @Override
+    public boolean match(Object msg) {
+        return type.isInstance(msg); // <1>
+    }
+    
+}
+```
+
+- 匹配逻辑，看 `<1>` 处，使用 `Class#isInstance(Object obj)` 方法。对于这个方法，如果我们定义的 `I` 泛型是个父类，那可以匹配所有的子类。例如 `I` 设置为 Object 类，那么所有消息，都可以被匹配列。
+
+## 2.3 write
+
+`#write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise)` 方法，匹配指定的消息类型，编码消息成 ByteBuf 对象，继续写到下一个节点。代码如下：
+
+```
+ 1: @Override
+ 2: public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) throws Exception {
+ 3:     ByteBuf buf = null;
+ 4:     try {
+ 5:         // 判断是否为匹配的消息
+ 6:         if (acceptOutboundMessage(msg)) {
+ 7:             @SuppressWarnings("unchecked")
+ 8:             I cast = (I) msg;
+ 9:             // 申请 buf
+10:             buf = allocateBuffer(ctx, cast, preferDirect);
+11:             // 编码
+12:             try {
+13:                 encode(ctx, cast, buf);
+14:             } finally {
+15:                 // 释放 msg
+16:                 ReferenceCountUtil.release(cast);
+17:             }
+18: 
+19:             // buf 可读，说明有编码到数据
+20:             if (buf.isReadable()) {
+21:                 // 写入 buf 到下一个节点
+22:                 ctx.write(buf, promise);
+23:             } else {
+24:                 // 释放 buf
+25:                 buf.release();
+26:                 // 写入 EMPTY_BUFFER 到下一个节点，为了 promise 的回调
+27:                 ctx.write(Unpooled.EMPTY_BUFFER, promise);
+28:             }
+29: 
+30:             // 置空 buf
+31:             buf = null;
+32:         } else {
+33:             // 提交 write 事件给下一个节点
+34:             ctx.write(msg, promise);
+35:         }
+36:     } catch (EncoderException e) {
+37:         throw e;
+38:     } catch (Throwable e) {
+39:         throw new EncoderException(e);
+40:     } finally {
+41:         // 释放 buf
+42:         if (buf != null) {
+43:             buf.release();
+44:         }
+45:     }
+46: }
+```
+
+- 第 6 行：调用 `#acceptInboundMessage(Object msg)` 方法，判断是否为匹配的消息。
+
+- ① 第 6 行：**匹配**。
+
+  - 第 8 行：对象类型转化为 `I` 类型的消息。
+
+  - 第 10 行：调用 `#allocateBuffer(ChannelHandlerContext ctx, I msg, boolean preferDirect)` 方法，申请 `buf` 。代码如下：
+
+    ```
+    /**
+     * Allocate a {@link ByteBuf} which will be used as argument of {@link #encode(ChannelHandlerContext, I, ByteBuf)}.
+     * Sub-classes may override this method to return {@link ByteBuf} with a perfect matching {@code initialCapacity}.
+     */
+    protected ByteBuf allocateBuffer(ChannelHandlerContext ctx, @SuppressWarnings("unused") I msg, boolean preferDirect) throws Exception {
+        if (preferDirect) {
+            return ctx.alloc().ioBuffer();
+        } else {
+            return ctx.alloc().heapBuffer();
+        }
+    }
+    ```
+
+    - x
+
+  - 第 13 行：调用 `#encode(ChannelHandlerContext ctx, I msg, ByteBuf out)` 方法，编码。代码如下：
+
+    ```
+    /**
+     * Encode a message into a {@link ByteBuf}. This method will be called for each written message that can be handled
+     * by this encoder.
+     *
+     * @param ctx           the {@link ChannelHandlerContext} which this {@link MessageToByteEncoder} belongs to
+     * @param msg           the message to encode
+     * @param out           the {@link ByteBuf} into which the encoded message will be written
+     * @throws Exception    is thrown if an error occurs
+     */
+    protected abstract void encode(ChannelHandlerContext ctx, I msg, ByteBuf out) throws Exception;
+    ```
+
+    - 子类可以实现该方法，实现自定义的编码功能。
+
+  - 第 16 行：调用 `ReferenceCountUtil#release(Object msg)` 方法，释放 `msg` 。
+
+  - 第 19 至 22 行：`buf` 可读，说明编码消息到 `buf` 中了，所以写入 `buf` 到下一个节点。😈 因为 `buf` 需要继续被下一个节点使用，所以不进行释放。
+
+  - 第 23 至 28 行：`buf` 不可读，说明无法编码，所以释放 `buf` ，并写入 `EMPTY_BUFFER` 到下一个节点，为了 promise 的回调。
+
+  - 第 31 行：置空 `buf` 为空。这里是为了防止【第 41 至 44 行】的代码，释放 `buf` 。
+
+- ② 第 32 行：
+
+  不匹配
+
+  。
+
+  - 提交 write 事件给下一个节点。
+
+- 第 36 至 39 行：发生异常，抛出 EncoderException 异常。
+
+- 第 40 至 45 行：如果中间发生异常，导致 `buf` 不为空，所以此处释放 `buf` 。
+
+# 3. NumberEncoder
+
+`io.netty.example.factorial.NumberEncoder` ，继承 MessageToByteEncoder 抽象类，Number 类型的消息的 Encoder 实现类。代码如下：
+
+> NumberEncoder 是 `netty-example` 模块提供的示例类，实际使用时，需要做调整。
+
+```
+public class NumberEncoder extends MessageToByteEncoder<Number> {
+
+    @Override
+    protected void encode(ChannelHandlerContext ctx, Number msg, ByteBuf out) {
+        // <1> 转化成 BigInteger 对象
+        // Convert to a BigInteger first for easier implementation.
+        BigInteger v;
+        if (msg instanceof BigInteger) {
+            v = (BigInteger) msg;
+        } else {
+            v = new BigInteger(String.valueOf(msg));
+        }
+
+        // <2> 转换为字节数组
+        // Convert the number into a byte array.
+        byte[] data = v.toByteArray();
+        int dataLength = data.length;
+
+        // <3> Write a message.
+        out.writeByte((byte) 'F'); // magic number
+        out.writeInt(dataLength);  // data length
+        out.writeBytes(data);      // data
+    }
+
+}
+```
+
+- `<1>` 处，转化消息类型为 BigInteger 对象，方便统一处理。
+
+- `<2>` 处，转化为字节数组。
+
+- ```
+  <3>
+  ```
+
+   
+
+  处
+
+  - 首位，写入 magic number ，方便区分**不同类型**的消息。例如说，后面如果有 Double 类型，可以使用 `D` ；String 类型，可以使用 `S` 。
+  - 后两位，写入 data length + data 。如果没有 data length ，那么数组内容，是无法读取的。
+
+实际一般不采用 NumberEncoder 的方式，因为 POJO 类型不好支持。关于这一块，可以参看下：
+
+- Dubbo
+- Motan
+- Sofa-RPC
+
+对 Encoder 和 Codec 真正实战。hoho
+
+# 666. 彩蛋
+
+MessageToByteEncoder 相比 ByteToMessageDecoder 来说，简单好多。
+
+推荐阅读文章：
+
+- Hypercube [《自顶向下深入分析Netty（八）–CodecHandler》](https://www.jianshu.com/p/7c439cc7b01c)
+
+另外，可能很多胖友，看完 Encoder 和 Decoder ，还是一脸懵逼，不知道实际如何使用。可以在网络上，再 Google 一些资料，不要方，不要怕。
\ No newline at end of file
diff --git a/netty/57-Netty 源码解析-Codec 之 ByteToMessageCodec.md b/netty/57-Netty 源码解析-Codec 之 ByteToMessageCodec.md
new file mode 100644
index 0000000..c64c1b7
--- /dev/null
+++ b/netty/57-Netty 源码解析-Codec 之 ByteToMessageCodec.md	
@@ -0,0 +1,180 @@
+# 精尽 Netty 源码解析 —— Codec 之 ByteToMessageCodec
+
+# 1. 概述
+
+本文，我们来分享 ByteToMessageCodec 部分的内容。
+
+在网络通信中，编解码是成对出现的，所以 Netty 提供了 ByteToMessageCodec 类，支持 Encoder 和 Decoder 两个功能。
+
+# 2. ByteToMessageCodec
+
+`io.netty.handler.codec.ByteToMessageCodec` ，继承 ChannelDuplexHandler 类，通过**组合** MessageToByteEncoder 和 ByteToMessageDecoder 的功能，从而实现编解码的 Codec **抽象类**。
+
+## 2.1 构造方法
+
+```
+public abstract class ByteToMessageCodec<I> extends ChannelDuplexHandler {
+
+    /**
+     * 类型匹配器
+     */
+    private final TypeParameterMatcher outboundMsgMatcher;
+    /**
+     * Encoder 对象
+     */
+    private final MessageToByteEncoder<I> encoder;
+    /**
+     * Decoder 对象
+     */
+    private final ByteToMessageDecoder decoder = new ByteToMessageDecoder() {
+    
+        @Override
+        public void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception {
+            ByteToMessageCodec.this.decode(ctx, in, out);
+        }
+    
+        @Override
+        protected void decodeLast(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception {
+            ByteToMessageCodec.this.decodeLast(ctx, in, out);
+        }
+    
+    };
+    
+    protected ByteToMessageCodec() {
+        this(true);
+    }
+    
+    protected ByteToMessageCodec(Class<? extends I> outboundMessageType) {
+        this(outboundMessageType, true);
+    }
+    
+    protected ByteToMessageCodec(boolean preferDirect) {
+        // 禁止共享
+        ensureNotSharable();
+        // <1> 获得 matcher
+        outboundMsgMatcher = TypeParameterMatcher.find(this, ByteToMessageCodec.class, "I");
+        // 创建 Encoder 对象
+        encoder = new Encoder(preferDirect);
+    }
+    
+    protected ByteToMessageCodec(Class<? extends I> outboundMessageType, boolean preferDirect) {
+        // 禁止共享
+        ensureNotSharable();
+        // <2> 获得 matcher
+        outboundMsgMatcher = TypeParameterMatcher.get(outboundMessageType);
+        // 创建 Encoder 对象
+        encoder = new Encoder(preferDirect);
+    }
+    
+    // ... 省略其他无关代码
+    
+    private final class Encoder extends MessageToByteEncoder<I> {
+
+        Encoder(boolean preferDirect) {
+            super(preferDirect);
+        }
+
+        @Override
+        public boolean acceptOutboundMessage(Object msg) throws Exception {
+            return ByteToMessageCodec.this.acceptOutboundMessage(msg);
+        }
+
+        @Override
+        protected void encode(ChannelHandlerContext ctx, I msg, ByteBuf out) throws Exception {
+            ByteToMessageCodec.this.encode(ctx, msg, out);
+        }
+
+    }
+    
+}
+```
+
+- MessageToByteEncoder 部分
+  - `encoder` 属性，Encoder 对象，继承自 MessageToByteEncoder 抽象类。只能在构造方法中创建，因为他依赖构造方法的 `preferDirect` 方法参数，所以不能像 `decoder` 直接使用属性赋值。
+  - `outboundMsgMatcher` 属性，类型匹配器，在 `<1>` / `<2>` 处初始化。
+- ByteToMessageDecoder 部分
+  - `decoder` 属性，Decoder 对象，继承自 ByteToMessageDecoder 抽象类。
+
+## 2.2 ChannelHandler 相关方法
+
+```
+@Override
+public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
+    decoder.channelRead(ctx, msg);
+}
+
+@Override
+public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) throws Exception {
+    encoder.write(ctx, msg, promise);
+}
+
+@Override
+public void channelReadComplete(ChannelHandlerContext ctx) throws Exception {
+    decoder.channelReadComplete(ctx);
+}
+
+@Override
+public void channelInactive(ChannelHandlerContext ctx) throws Exception {
+    decoder.channelInactive(ctx);
+}
+
+@Override
+public void handlerAdded(ChannelHandlerContext ctx) throws Exception {
+    try {
+        decoder.handlerAdded(ctx);
+    } finally {
+        encoder.handlerAdded(ctx);
+    }
+}
+
+@Override
+public void handlerRemoved(ChannelHandlerContext ctx) throws Exception {
+    try {
+        decoder.handlerRemoved(ctx);
+    } finally {
+        encoder.handlerRemoved(ctx);
+    }
+}
+``` 
+
+## 2.3 MessageToByteEncoder 相关方法
+
+```Java
+/**
+ * @see ByteToMessageDecoder#decode(ChannelHandlerContext, ByteBuf, List)
+ */
+protected abstract void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception;
+
+/**
+ * @see ByteToMessageDecoder#decodeLast(ChannelHandlerContext, ByteBuf, List)
+ */
+protected void decodeLast(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception {
+    if (in.isReadable()) {
+        // Only call decode() if there is something left in the buffer to decode.
+        // See https://github.com/netty/netty/issues/4386
+        decode(ctx, in, out);
+    }
+}
+```
+
+## 2.4 MessageToByteEncoder 相关方法
+
+```
+/**
+ * Returns {@code true} if and only if the specified message can be encoded by this codec.
+ *
+ * @param msg the message
+ */
+public boolean acceptOutboundMessage(Object msg) throws Exception {
+    return outboundMsgMatcher.match(msg);
+}
+
+/**
+ * @see MessageToByteEncoder#encode(ChannelHandlerContext, Object, ByteBuf)
+ */
+protected abstract void encode(ChannelHandlerContext ctx, I msg, ByteBuf out) throws Exception;
+```
+
+# 666. 彩蛋
+
+小小的水文一篇，嘿嘿。
\ No newline at end of file
diff --git a/netty/58-Netty 源码解析-Codec 之 MessageToMessageCodec.md b/netty/58-Netty 源码解析-Codec 之 MessageToMessageCodec.md
new file mode 100644
index 0000000..946c74a
--- /dev/null
+++ b/netty/58-Netty 源码解析-Codec 之 MessageToMessageCodec.md	
@@ -0,0 +1,375 @@
+# 精尽 Netty 源码解析 —— Codec 之 MessageToMessageCodec
+
+# 1. 概述
+
+本文，我们来分享 MessageToMessageCodec 部分的内容。
+
+MessageToMessageCodec 负责消息和消息**之间**的编解码，主要由两部分构造：
+
+- MessageToMessageEncoder ，将消息**编码**成另一种消息。
+- MessageToMessageDecoder ，将消息**解码**成另一种消息。
+
+所以，我们先来看 MessageToMessageDecoder 的代码实现，再看 MessageToMessageEncoder 的代码实现，最后看 MessageToMessageCodec 的代码实现。
+
+> 老艿艿：因为笔者平时比较少用这三个类，所以本文会分享的比较简单噢。
+
+# 2. MessageToMessageEncoder
+
+`io.netty.handler.codec.MessageToMessageEncoder` ，继承 ChannelOutboundHandlerAdapter 抽象类，将消息**编码**成另一种消息。
+
+## 2.1 构造方法
+
+```
+/**
+ * 类型匹配器
+ */
+private final TypeParameterMatcher matcher;
+
+protected MessageToMessageEncoder() {
+    matcher = TypeParameterMatcher.find(this, MessageToMessageEncoder.class, "I");
+}
+
+protected MessageToMessageEncoder(Class<? extends I> outboundMessageType) {
+    matcher = TypeParameterMatcher.get(outboundMessageType);
+}
+```
+
+## 2.2 acceptOutboundMessage
+
+```
+/**
+ * Returns {@code true} if the given message should be handled. If {@code false} it will be passed to the next
+ * {@link ChannelOutboundHandler} in the {@link ChannelPipeline}.
+ */
+public boolean acceptOutboundMessage(Object msg) throws Exception {
+    return matcher.match(msg);
+}
+```
+
+## 2.3 write
+
+```
+@Override
+public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) throws Exception {
+    CodecOutputList out = null;
+    try {
+        // 判断是否为匹配的消息
+        if (acceptOutboundMessage(msg)) {
+            // 创建 CodecOutputList 对象
+            out = CodecOutputList.newInstance();
+            // 转化消息类型
+            @SuppressWarnings("unchecked")
+            I cast = (I) msg;
+            try {
+                // 将消息编码成另外一个消息
+                encode(ctx, cast, out);
+            } finally {
+                // 释放 cast 原消息
+                ReferenceCountUtil.release(cast);
+            }
+
+            // 如果未编码出消息，抛出异常
+            if (out.isEmpty()) {
+                // 回收 CodecOutputList 对象
+                out.recycle();
+                out = null;
+                // 抛出异常
+                throw new EncoderException(StringUtil.simpleClassName(this) + " must produce at least one message.");
+            }
+        } else {
+            // 直接下一个节点
+            ctx.write(msg, promise);
+        }
+    } catch (EncoderException e) {
+        throw e;
+    } catch (Throwable t) {
+        throw new EncoderException(t);
+    } finally {
+        if (out != null) {
+            final int sizeMinusOne = out.size() - 1;
+            // 只编码出一条消息
+            if (sizeMinusOne == 0) {
+                // 直接写入新消息到下一个节点
+                ctx.write(out.get(0), promise);
+            // 编码出多条消息
+            } else if (sizeMinusOne > 0) {
+                // 第 [0, n-1) 条消息，写入下一个节点，使用 voidPromise ，即不需要回调
+                // Check if we can use a voidPromise for our extra writes to reduce GC-Pressure
+                // See https://github.com/netty/netty/issues/2525
+                ChannelPromise voidPromise = ctx.voidPromise();
+                boolean isVoidPromise = promise == voidPromise;
+                for (int i = 0; i < sizeMinusOne; i ++) {
+                    ChannelPromise p;
+                    if (isVoidPromise) {
+                        p = voidPromise;
+                    } else {
+                        p = ctx.newPromise();
+                    }
+                    ctx.write(out.getUnsafe(i), p);
+                }
+                // 第 n-1 条消息，写入下一个节点，使用 promise ，即需要回调
+                ctx.write(out.getUnsafe(sizeMinusOne), promise);
+            }
+            // 回收 CodecOutputList 对象
+            out.recycle();
+        }
+    }
+}
+```
+
+- 代码比较简单，胖友自己看注释。
+
+## 2.4 encode
+
+```
+/**
+ * Encode from one message to an other. This method will be called for each written message that can be handled
+ * by this encoder.
+ *
+ * @param ctx           the {@link ChannelHandlerContext} which this {@link MessageToMessageEncoder} belongs to
+ * @param msg           the message to encode to an other one
+ * @param out           the {@link List} into which the encoded msg should be added
+ *                      needs to do some kind of aggregation
+ * @throws Exception    is thrown if an error occurs
+ */
+protected abstract void encode(ChannelHandlerContext ctx, I msg, List<Object> out) throws Exception;
+```
+
+## 2.5 子类
+
+MessageToMessageEncoder 子类比较多，感兴趣的胖友，可以看看负责实现 FrameEncoder 的两个类：
+
+- ```
+  io.netty.handler.codec.string.LineEncoder
+  ```
+
+   
+
+  ，基于
+
+  指定行分隔符
+
+  的 FrameEncoder 实现类。
+
+  - 代码比较简单，胖友可以直接撸。
+
+- ```
+  io.netty.handler.codec.LengthFieldPrepender
+  ```
+
+   
+
+  ，基于基于
+
+  消息头指定消息长度
+
+  的 FrameEncoder 实现类。
+
+  - 相对复杂一些，胖友可以结合 [《Netty源码分析-7-MessageToByteEncoder》](https://liuzhengyang.github.io/2018/08/03/netty-7-messagetobyteencoder/) 一起撸。
+
+# 3. MessageToMessageDecoder
+
+`io.netty.handler.codec.MessageToMessageDecoder` ，继承 ChannelInboundHandlerAdapter 类，将消息**解码**成另一种消息。
+
+## 3.1 构造方法
+
+```
+/**
+ * 类型匹配器
+ */
+private final TypeParameterMatcher matcher;
+
+protected MessageToMessageDecoder() {
+    matcher = TypeParameterMatcher.find(this, MessageToMessageDecoder.class, "I");
+}
+
+protected MessageToMessageDecoder(Class<? extends I> inboundMessageType) {
+    matcher = TypeParameterMatcher.get(inboundMessageType);
+}
+```
+
+## 3.2 acceptInboundMessage
+
+```
+public boolean acceptInboundMessage(Object msg) throws Exception {
+    return matcher.match(msg);
+}
+```
+
+## 3.3 channelRead
+
+```
+@Override
+public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
+    // 创建 CodecOutputList 对象
+    CodecOutputList out = CodecOutputList.newInstance();
+    try {
+        // 判断是否为匹配的消息
+        if (acceptInboundMessage(msg)) {
+            // 转化消息类型
+            @SuppressWarnings("unchecked")
+            I cast = (I) msg;
+            try {
+                // 将消息解码成另外一个消息
+                decode(ctx, cast, out);
+            } finally {
+                // 释放 cast 原消息
+                ReferenceCountUtil.release(cast);
+            }
+        } else {
+            // 不匹配，添加到 out
+            out.add(msg);
+        }
+    } catch (DecoderException e) {
+        throw e;
+    } catch (Exception e) {
+        throw new DecoderException(e);
+    } finally {
+        // 遍历 out ，触发 Channel Read 事件到 pipeline 中
+        int size = out.size();
+        for (int i = 0; i < size; i ++) {
+            ctx.fireChannelRead(out.getUnsafe(i));
+        }
+        // 回收 CodecOutputList 对象
+        out.recycle();
+    }
+}
+```
+
+## 3.4 decode
+
+```
+/**
+ * Decode from one message to an other. This method will be called for each written message that can be handled
+ * by this encoder.
+ *
+ * @param ctx           the {@link ChannelHandlerContext} which this {@link MessageToMessageDecoder} belongs to
+ * @param msg           the message to decode to an other one
+ * @param out           the {@link List} to which decoded messages should be added
+ * @throws Exception    is thrown if an error occurs
+ */
+protected abstract void decode(ChannelHandlerContext ctx, I msg, List<Object> out) throws Exception;
+```
+
+# 4. MessageToMessageCodec
+
+`io.netty.handler.codec.MessageToMessageCodec` ，继承 ChannelDuplexHandler 类，通过**组合** MessageToMessageEncoder 和 MessageToMessageDecoder 的功能，从而实现编解码的 Codec **抽象类**。
+
+> 老艿艿：从实现的方式上，和 ByteToMessageCodec 非常相似。
+
+## 4.1 构造方法
+
+```
+public abstract class MessageToMessageCodec<INBOUND_IN, OUTBOUND_IN> extends ChannelDuplexHandler {
+
+    /**
+     * Encoder 对象
+     */
+    private final MessageToMessageEncoder<Object> encoder = new MessageToMessageEncoder<Object>() {
+
+        @Override
+        public boolean acceptOutboundMessage(Object msg) throws Exception {
+            return MessageToMessageCodec.this.acceptOutboundMessage(msg);
+        }
+
+        @Override
+        @SuppressWarnings("unchecked")
+        protected void encode(ChannelHandlerContext ctx, Object msg, List<Object> out) throws Exception {
+            MessageToMessageCodec.this.encode(ctx, (OUTBOUND_IN) msg, out);
+        }
+    };
+
+    /**
+     * Decoder 对象
+     */
+    private final MessageToMessageDecoder<Object> decoder = new MessageToMessageDecoder<Object>() {
+
+        @Override
+        public boolean acceptInboundMessage(Object msg) throws Exception {
+            return MessageToMessageCodec.this.acceptInboundMessage(msg);
+        }
+
+        @Override
+        @SuppressWarnings("unchecked")
+        protected void decode(ChannelHandlerContext ctx, Object msg, List<Object> out) throws Exception {
+            MessageToMessageCodec.this.decode(ctx, (INBOUND_IN) msg, out);
+        }
+    };
+
+    /**
+     * Decoder 的类型匹配器
+     */
+    private final TypeParameterMatcher inboundMsgMatcher;
+    /**
+     * Encoder 的类型匹配器
+     */
+    private final TypeParameterMatcher outboundMsgMatcher;
+
+    protected MessageToMessageCodec() {
+        inboundMsgMatcher = TypeParameterMatcher.find(this, MessageToMessageCodec.class, "INBOUND_IN");
+        outboundMsgMatcher = TypeParameterMatcher.find(this, MessageToMessageCodec.class, "OUTBOUND_IN");
+    }
+
+    protected MessageToMessageCodec(Class<? extends INBOUND_IN> inboundMessageType, Class<? extends OUTBOUND_IN> outboundMessageType) {
+        inboundMsgMatcher = TypeParameterMatcher.get(inboundMessageType);
+        outboundMsgMatcher = TypeParameterMatcher.get(outboundMessageType);
+    }
+    
+    // ...  省略非构造方法相关
+}
+```
+
+## 4.2 MessageToMessageEncoder 相关方法
+
+```
+@Override
+public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) throws Exception {
+    encoder.write(ctx, msg, promise);
+}
+
+/**
+ * Returns {@code true} if and only if the specified message can be decoded by this codec.
+ *
+ * @param msg the message
+ */
+public boolean acceptInboundMessage(Object msg) throws Exception {
+    return inboundMsgMatcher.match(msg);
+}
+
+/**
+ * @see MessageToMessageEncoder#encode(ChannelHandlerContext, Object, List)
+ */
+protected abstract void encode(ChannelHandlerContext ctx, OUTBOUND_IN msg, List<Object> out) throws Exception;
+```
+
+## 4.3 MessageToMessageDecoder 相关方法
+
+```
+@Override
+public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
+    decoder.channelRead(ctx, msg);
+}
+
+/**
+ * Returns {@code true} if and only if the specified message can be encoded by this codec.
+ *
+ * @param msg the message
+ */
+public boolean acceptOutboundMessage(Object msg) throws Exception {
+    return outboundMsgMatcher.match(msg);
+}
+
+/**
+ * @see MessageToMessageDecoder#decode(ChannelHandlerContext, Object, List)
+ */
+protected abstract void decode(ChannelHandlerContext ctx, INBOUND_IN msg, List<Object> out) throws Exception;
+```
+
+# 666. 彩蛋
+
+还是一篇小水文。嘿嘿。
+
+推荐阅读文章：
+
+- wade&luffy [《ChannelHandler》](https://www.cnblogs.com/wade-luffy/p/6222960.html)
+- 堆码时刻 [《Netty In Action中文版 - 第八章：附带的ChannelHandler和Codec》](https://blog.csdn.net/abc_key/article/details/38061079)
\ No newline at end of file
diff --git a/netty/59-Netty 源码解析-Util 之 Future.assets/01.png b/netty/59-Netty 源码解析-Util 之 Future.assets/01.png
new file mode 100644
index 0000000..65c9317
Binary files /dev/null and b/netty/59-Netty 源码解析-Util 之 Future.assets/01.png differ
diff --git a/netty/59-Netty 源码解析-Util 之 Future.md b/netty/59-Netty 源码解析-Util 之 Future.md
new file mode 100644
index 0000000..c535c65
--- /dev/null
+++ b/netty/59-Netty 源码解析-Util 之 Future.md	
@@ -0,0 +1,504 @@
+# 精尽 Netty 源码解析 —— Util 之 Future
+
+笔者先把 Netty 主要的内容写完，所以关于 Future 的分享，先放在后续的计划里。
+
+> 老艿艿：其实是因为，自己想去研究下 Service Mesh ，所以先简单收个小尾。
+
+当然，良心如我，还是为对这块感兴趣的胖友，先准备好了一篇不错的文章：
+
+- Hypercube [《自顶向下深入分析Netty（五）–Future》](https://www.jianshu.com/p/a06da3256f0c)
+
+为避免可能 [《自顶向下深入分析Netty（五）–Future》](https://www.jianshu.com/p/a06da3256f0c) 被作者删除，笔者这里先复制一份作为备份。
+
+# 666. 备份
+
+再次回顾这幅图，在上一章中，我们分析了Reactor的完整实现。由于Java NIO事件驱动的模型，要求Netty的事件处理采用异步的方式，异步处理则需要表示异步操作的结果。Future正是用来表示异步操作结果的对象，Future的类签名为：
+
+```
+public interface Future<V>;
+```
+
+其中的泛型参数V即表示异步结果的类型。
+
+### 5.1 总述
+
+也许你已经使用过JDK的Future对象，该接口的方法如下：
+
+```
+// 取消异步操作
+boolean cancel(boolean mayInterruptIfRunning);
+// 异步操作是否取消
+boolean isCancelled();
+// 异步操作是否完成，正常终止、异常、取消都是完成
+boolean isDone();
+// 阻塞直到取得异步操作结果
+V get() throws InterruptedException, ExecutionException;
+// 同上，但最长阻塞时间为timeout
+V get(long timeout, TimeUnit unit)
+    throws InterruptedException, ExecutionException, TimeoutException;
+```
+
+我们的第一印象会觉得这样的设计并不坏，但仔细思考，便会发现问题：
+(1).接口中只有isDone()方法判断一个异步操作是否完成，但是对于完成的定义过于模糊，JDK文档指出正常终止、抛出异常、用户取消都会使isDone()方法返回真。在我们的使用中，我们极有可能是对这三种情况分别处理，而JDK这样的设计不能满足我们的需求。
+(2).对于一个异步操作，我们更关心的是这个异步操作触发或者结束后能否再执行一系列动作。比如说，我们浏览网页时点击一个按钮后实现用户登录。在javascript中，处理代码如下：
+
+```
+$("#login").click(function(){
+    login();
+});
+```
+
+可见在这样的情况下，JDK中的Future便不能处理，所以，Netty扩展了JDK的Future接口，使其能解决上面的两个问题。扩展的方法如下（类似方法只列出一个）：
+
+```
+// 异步操作完成且正常终止
+boolean isSuccess();
+// 异步操作是否可以取消
+boolean isCancellable();
+// 异步操作失败的原因
+Throwable cause();
+// 添加一个监听者，异步操作完成时回调，类比javascript的回调函数
+Future<V> addListener(GenericFutureListener<? extends Future<? super V>> listener);
+Future<V> removeListener(GenericFutureListener<? extends Future<? super V>> listener);
+// 阻塞直到异步操作完成
+Future<V> await() throws InterruptedException;
+// 同上，但异步操作失败时抛出异常
+Future<V> sync() throws InterruptedException;
+// 非阻塞地返回异步结果，如果尚未完成返回null
+V getNow();
+```
+
+如果你对Future的状态还有疑问，放上代码注释中的ascii图打消你的疑虑：
+
+```
+*                                      +---------------------------+
+*                                      | Completed successfully    |
+*                                      +---------------------------+
+*                                 +---->      isDone() = true      |
+* +--------------------------+    |    |   isSuccess() = true      |
+* |        Uncompleted       |    |    +===========================+
+* +--------------------------+    |    | Completed with failure    |
+* |      isDone() = false    |    |    +---------------------------+
+* |   isSuccess() = false    |----+---->      isDone() = true      |
+* | isCancelled() = false    |    |    |       cause() = non-null  |
+* |       cause() = null     |    |    +===========================+
+* +--------------------------+    |    | Completed by cancellation |
+*                                 |    +---------------------------+
+*                                 +---->      isDone() = true      |
+*                                      | isCancelled() = true      |
+*                                      +---------------------------+
+```
+
+可知，Future对象有两种状态尚未完成和已完成，其中已完成又有三种状态：成功、失败、用户取消。各状态的状态断言请在此图中查找。
+仔细看完上面的图并联系Future接口中的方法，你是不是也会和我有相同的疑问：Future接口中的方法都是getter方法而没有setter方法，也就是说这样实现的Future子类的状态是不可变的，如果我们想要变化，那该怎么办呢？Netty提供的解决方法是：使用可写的Future即Promise。Promise接口扩展的方法如下：
+
+```
+ // 标记异步操作结果为成功，如果已被设置（不管成功还是失败）则抛出异常IllegalStateException
+ Promise<V> setSuccess(V result);
+ // 同上，只是结果已被设置时返回False
+ boolean trySuccess(V result);
+
+ Promise<V> setFailure(Throwable cause);
+ boolean tryFailure(Throwable cause);
+
+// 设置结果为不可取消，结果已被取消返回False
+ boolean setUncancellable();
+```
+
+需要注意的是：Promise接口继承自Future接口，它提供的setter方法与常见的setter方法大为不同。Promise从Uncompleted–>Completed的状态转变**有且只能有一次**，也就是说setSuccess和setFailure方法最多只会成功一个，此外，在setSuccess和setFailure方法中会通知注册到其上的监听者。为了加深对Future和Promise的理解，我们可以将Future类比于定额发票，Promise类比于机打发票。当商户拿到税务局的发票时，如果是定额发票，则已经确定好金额是100还是50或其他，商户再也不能更改；如果是机打发票，商户相当于拿到了一个发票模板，需要多少金额按实际情况填到模板指定处。显然，不能两次使用同一张机打发票打印，这会使发票失效，而Promise做的更好，它使第二次调用setter方法失败。
+至此，我们从总体上了解了Future和Promise的原理。我们再看一下类图：
+
+[![Future类图](59-Netty 源码解析-Util 之 Future.assets/01.png)](http://static.iocoder.cn/images/Netty/2019_02_01/01.png)Future类图
+
+类图给我们的第一印象是：繁杂。我们抓住关键点：Future和Promise两条分支，分而治之。我们使用自顶向下的方法分析其实现细节，使用两条线索：
+
+```
+AbstractFuture<--CompleteFuture<--CompleteChannelFuture<--Succeeded/FailedChannelFuture
+
+DefaultPromise<--DefaultChannelPromise
+```
+
+### 5.2 Future
+
+#### 5.2.1 AbstractFuture
+
+AbstractFuture主要实现Future的get()方法，取得Future关联的异步操作结果：
+
+```
+@Override
+public V get() throws InterruptedException, ExecutionException {
+    await();    // 阻塞直到异步操作完成
+
+    Throwable cause = cause();
+    if (cause == null) {
+        return getNow();    // 成功则返回关联结果
+    }
+    if (cause instanceof CancellationException) {
+        throw (CancellationException) cause;    // 由用户取消
+    }
+    throw new ExecutionException(cause);    // 失败抛出异常
+}
+```
+
+其中的实现简单明了，但关键调用方法的具体实现并没有，我们将在子类实现中分析。对应的加入超时时间的get(long timeout, TimeUnit unit)实现也类似，不再列出。
+
+#### 5.2.2 CompleteFuture
+
+Complete表示操作已完成，所以CompleteFuture表示一个异步操作已完成的结果，由此可推知：该类的实例在异步操作完成时创建，返回给用户，用户则使用addListener()方法定义一个异步操作。如果你熟悉javascript，将Listener类比于回调函数callback()可方便理解。
+我们首先看其中的字段和构造方法：
+
+```
+// 执行器，执行Listener中定义的操作
+private final EventExecutor executor;
+
+// 这有一个构造方法，可知executor是必须的
+protected CompleteFuture(EventExecutor executor) {
+    this.executor = executor;
+}
+```
+
+CompleteFuture类定义了一个EventExecutor，可视为一个线程，用于执行Listener中的操作。我们再看addListener()和removeListener()方法：
+
+```
+public Future<V> addListener(GenericFutureListener<? extends Future<? super V>> listener) {
+    // 由于这是一个已完成的Future，所以立即通知Listener执行
+    DefaultPromise.notifyListener(executor(), this, listener);
+    return this;
+}
+
+public Future<V> removeListener(GenericFutureListener<? extends Future<? super V>> listener) {
+    // 由于已完成，Listener中的操作已完成，没有需要删除的Listener
+    return this;
+}
+```
+
+其中的实现也很简单，我们看一下GenericFutureListener接口，其中只定义了一个方法：
+
+```
+// 异步操作完成是调用
+void operationComplete(F future) throws Exception;
+```
+
+关于Listener我们再关注一下ChannelFutureListener，它并没有扩展GenericFutureListener接口，所以类似于一个标记接口。我们看其中实现的三个通用ChannelFutureListener：
+
+```
+ChannelFutureListener CLOSE = (future) --> {
+    future.channel().close();   //操作完成时关闭Channel
+};
+
+ChannelFutureListener CLOSE_ON_FAILURE = (future) --> {
+    if (!future.isSuccess()) {
+        future.channel().close();   // 操作失败时关闭Channel
+    }
+};
+
+ChannelFutureListener FIRE_EXCEPTION_ON_FAILURE = (future) --> {
+    if (!future.isSuccess()) {
+        // 操作失败时触发一个ExceptionCaught事件
+        future.channel().pipeline().fireExceptionCaught(future.cause());
+    }
+};
+```
+
+这三个Listener对象定义了对Channel处理时常用的操作，如果符合需求，可以直接使用。
+由于CompleteFuture表示一个已完成的异步操作，所以可推知sync()和await()方法都将立即返回。此外，可推知线程的状态如下，不再列出代码：
+
+```
+isDone() = true; isCancelled() = false;
+```
+
+#### 5.2.3 CompleteChannelFuture
+
+CompleteChannelFuture的类签名如下：
+
+```
+abstract class CompleteChannelFuture extends CompleteFuture<Void> implements ChannelFuture
+```
+
+ChannelFuture是不是觉得很亲切？你肯定已经使用过ChannelFuture。ChannelFuture接口相比于Future只扩展了一个方法channel()用于取得关联的Channel对象。CompleteChannelFuture还继承了CompleteFuture，尖括号中的泛型表示Future关联的结果，此结果为Void，意味着CompleteChannelFuture不关心这个特定结果即get()相关方法返回null。也就是说，我们可以将CompleteChannelFuture纯粹的视为一种回调函数机制。
+CompleteChannelFuture的字段只有一个：
+
+```
+private final Channel channel; // 关联的Channel对象
+```
+
+CompleteChannelFuture的大部分方法实现中，只是将方法返回的Future覆盖为ChannelFuture对象（ChannelFuture接口的要求），代码不在列出。我们看一下executor()方法：
+
+```
+@Override
+protected EventExecutor executor() {
+    EventExecutor e = super.executor(); // 构造方法指定
+    if (e == null) {
+        return channel().eventLoop();   // 构造方法未指定使用channel注册到的eventLoop
+    } else {
+        return e;
+    }
+}
+```
+
+#### 5.2.4 Succeeded/FailedChannelFuture
+
+Succeeded/FailedChannelFuture为特定的两个异步操作结果，回忆总述中关于Future状态的讲解，成功意味着
+
+```
+Succeeded: isSuccess() == true, cause() == null;
+Failed:    isSuccess() == false, cause() == non-null
+```
+
+代码中的实现也很简单，不再列出。需要注意的是，其中的构造方法不建议用户调用，一般使用Channel对象的方法newSucceededFuture()和newFailedFuture(Throwable)代替。
+
+### 5.3 Promise
+
+#### 5.3.1 DefaultPromise
+
+我们首先看其中的static字段：
+
+```
+// 可以嵌套的Listener的最大层数，可见最大值为8
+private static final int MAX_LISTENER_STACK_DEPTH = Math.min(8,
+        SystemPropertyUtil.getInt("io.netty.defaultPromise.maxListenerStackDepth", 8));
+// result字段由使用RESULT_UPDATER更新
+private static final AtomicReferenceFieldUpdater<DefaultPromise, Object> RESULT_UPDATER;
+// 此处的Signal是Netty定义的类，继承自Error，异步操作成功且结果为null时设置为改值
+private static final Signal SUCCESS = Signal.valueOf(DefaultPromise.class.getName() + ".SUCCESS");
+// 异步操作不可取消
+private static final Signal UNCANCELLABLE = Signal.valueOf(...);
+// 异步操作失败时保存异常原因
+private static final CauseHolder CANCELLATION_CAUSE_HOLDER = new CauseHolder(...);
+```
+
+嵌套的Listener，是指在listener的operationComplete方法中，可以再次使用future.addListener()继续添加listener，Netty限制的最大层数是8，用户可使用系统变量io.netty.defaultPromise.maxListenerStackDepth设置。
+再看其中的私有字段：
+
+```
+// 异步操作结果
+private volatile Object result;
+// 执行listener操作的执行器
+private final EventExecutor executor;
+// 监听者
+private Object listeners;
+// 阻塞等待该结果的线程数
+private short waiters;
+// 通知正在进行标识
+private boolean notifyingListeners;
+```
+
+也许你已经注意到，listeners是一个Object类型。这似乎不合常理，一般情况下我们会使用一个集合或者一个数组。Netty之所以这样设计，是因为大多数情况下listener只有一个，用集合和数组都会造成浪费。当只有一个listener时，该字段为一个GenericFutureListener对象；当多余一个listener时，该字段为DefaultFutureListeners，可以储存多个listener。明白了这些，我们分析关键方法addListener()：
+
+```
+@Override
+public Promise<V> addListener(GenericFutureListener<? extends Future<? super V>> listener) {
+    synchronized (this) {
+        addListener0(listener); // 保证多线程情况下只有一个线程执行添加操作
+    }
+
+    if (isDone()) {
+        notifyListeners();  // 异步操作已经完成通知监听者
+    }
+    return this;
+}
+
+private void addListener0(GenericFutureListener<? extends Future<? super V>> listener) {
+    if (listeners == null) {
+        listeners = listener;   // 只有一个
+    } else if (listeners instanceof DefaultFutureListeners) {
+        ((DefaultFutureListeners) listeners).add(listener); // 大于两个
+    } else {
+        // 从一个扩展为两个
+        listeners = new DefaultFutureListeners((GenericFutureListener<? extends Future<V>>) listeners, listener);   
+    }
+}
+```
+
+从代码中可以看出，在添加Listener时，如果异步操作已经完成，则会notifyListeners()：
+
+```
+private void notifyListeners() {
+    EventExecutor executor = executor();
+    if (executor.inEventLoop()) {   //执行线程为指定线程
+        final InternalThreadLocalMap threadLocals = InternalThreadLocalMap.get();
+        final int stackDepth = threadLocals.futureListenerStackDepth(); // 嵌套层数
+        if (stackDepth < MAX_LISTENER_STACK_DEPTH) {
+            // 执行前增加嵌套层数
+            threadLocals.setFutureListenerStackDepth(stackDepth + 1);   
+            try {
+                notifyListenersNow();
+            } finally {
+                // 执行完毕，无论如何都要回滚嵌套层数
+                threadLocals.setFutureListenerStackDepth(stackDepth);
+            }
+            return;
+        }
+    }
+    // 外部线程则提交任务给执行线程
+    safeExecute(executor, () -> { notifyListenersNow(); });
+}
+
+private static void safeExecute(EventExecutor executor, Runnable task) {
+    try {
+        executor.execute(task);
+    } catch (Throwable t) {
+        rejectedExecutionLogger.error("Failed to submit a listener notification task. Event loop shut down?", t);
+    }
+}
+```
+
+所以，外部线程不能执行监听者Listener中定义的操作，只能提交任务到指定Executor，其中的操作最终由指定Executor执行。我们再看notifyListenersNow()方法：
+
+```
+private void notifyListenersNow() {
+    Object listeners;
+    // 此时外部线程可能会执行添加Listener操作，所以需要同步
+    synchronized (this) { 
+        if (notifyingListeners || this.listeners == null) {
+            // 正在通知或已没有监听者（外部线程删除）直接返回
+            return; 
+        }
+        notifyingListeners = true;  
+        listeners = this.listeners;
+        this.listeners = null;
+    }
+    for (;;) {
+        if (listeners instanceof DefaultFutureListeners) { // 通知单个
+            notifyListeners0((DefaultFutureListeners) listeners);
+        } else { // 通知多个（遍历集合调用单个）
+            notifyListener0(this, (GenericFutureListener<? extends Future<V>>) listeners);
+        }
+        synchronized (this) {
+            // 执行完毕且外部线程没有再添加监听者
+            if (this.listeners == null) {
+                notifyingListeners = false; 
+                return; 
+            }
+            // 外部线程添加了监听者继续执行
+            listeners = this.listeners; 
+            this.listeners = null;
+        }
+    }
+}
+
+private static void notifyListener0(Future future, GenericFutureListener l) {
+    try {
+        l.operationComplete(future);
+    } catch (Throwable t) {
+        logger.warn("An exception was thrown by " + l.getClass().getName() + ".operationComplete()", t);
+    }
+}
+```
+
+到此为止，我们分析完了Promise最重要的addListener()和notifyListener()方法。在源码中还有static的notifyListener()方法，这些方法是CompleteFuture使用的，对于CompleteFuture，添加监听者的操作不需要缓存，直接执行Listener中的方法即可，执行线程为调用线程，相关代码可回顾CompleteFuture。addListener()相对的removeListener()方法实现简单，我们不再分析。
+回忆result字段，修饰符有volatile，所以使用RESULT_UPDATER更新，保证更新操作为原子操作。Promise不携带特定的结果（即携带Void）时，成功时设置为静态字段的Signal对象SUCCESS；如果携带泛型参数结果，则设置为泛型一致的结果。对于Promise，设置成功、设置失败、取消操作，**三个操作至多只能调用一个且同一个方法至多生效一次**，再次调用会抛出异常（set）或返回失败（try）。这些设置方法原理相同，我们以setSuccess()为例分析:
+
+```
+public Promise<V> setSuccess(V result) {
+    if (setSuccess0(result)) {
+        notifyListeners();  // 可以设置结果说明异步操作已完成，故通知监听者
+        return this;
+    }
+    throw new IllegalStateException("complete already: " + this);
+}
+
+private boolean setSuccess0(V result) {
+    // 为空设置为Signal对象Success
+    return setValue0(result == null ? SUCCESS : result);
+}
+
+private boolean setValue0(Object objResult) {
+    // 只有结果为null或者UNCANCELLABLE时才可设置且只可以设置一次
+    if (RESULT_UPDATER.compareAndSet(this, null, objResult) ||
+        RESULT_UPDATER.compareAndSet(this, UNCANCELLABLE, objResult)) {
+        checkNotifyWaiters();   // 通知等待的线程
+        return true;
+    }
+    return false;
+}
+```
+
+checkNotifyWaiters()方法唤醒调用await()和sync()方法等待该异步操作结果的线程，代码如下：
+
+```
+private synchronized void checkNotifyWaiters() {
+    // 确实有等待的线程才notifyAll
+    if (waiters > 0) {  
+        notifyAll();    // JDK方法
+    }
+}
+```
+
+有了唤醒操作，那么sync()和await()的实现是怎么样的呢？我们首先看sync()的代码：
+
+```
+public Promise<V> sync() throws InterruptedException {
+    await();
+    rethrowIfFailed();  // 异步操作失败抛出异常
+    return this;
+}
+```
+
+可见，sync()和await()很类似，区别只是sync()调用，如果异步操作失败，则会抛出异常。我们接着看await()的实现：
+
+```
+public Promise<V> await() throws InterruptedException {
+    // 异步操作已经完成，直接返回
+    if (isDone()) {
+        return this;    
+    }
+    if (Thread.interrupted()) {
+        throw new InterruptedException(toString());
+    }
+    // 死锁检测
+    checkDeadLock();
+    // 同步使修改waiters的线程只有一个
+    synchronized (this) {
+        while (!isDone()) { // 等待直到异步操作完成
+            incWaiters();   // ++waiters;
+            try {
+                wait(); // JDK方法
+            } finally {
+                decWaiters(); // --waiters
+            }
+        }
+    }
+    return this;
+}
+```
+
+其中的实现简单明了，其他await()方法也类似，不再分析。我们注意其中的checkDeadLock()方法用来进行死锁检测：
+
+```
+protected void checkDeadLock() {
+    EventExecutor e = executor();
+    if (e != null && e.inEventLoop()) {
+        throw new BlockingOperationException(toString());
+    }
+}
+```
+
+也就是说，**不能在同一个线程中调用await()相关的方法**。为了更好的理解这句话，我们使用代码注释中的例子来解释。Handler中的channelRead()方法是由Channel注册到的eventLoop执行的，其中的Future的Executor也是这个eventLoop，所以不能在channelRead()方法中调用await这一类（包括sync）方法。
+
+```
+// 错误的例子
+public void channelRead(ChannelHandlerContext ctx, Object msg) {
+    ChannelFuture future = ctx.channel().close();
+    future.awaitUninterruptibly();
+    // ...
+}
+
+// 正确的做法
+public void channelRead(ChannelHandlerContext ctx, Object msg) {
+    ChannelFuture future = ctx.channel().close();
+    future.addListener(new ChannelFutureListener() {
+        public void operationComplete(ChannelFuture future) {
+            // ... 使用异步操作
+        }
+    });
+}
+```
+
+到了这里，我们已经分析完Future和Promise的主要实现。剩下的DefaultChannelPromise、VoidChannelPromise实现都很简单，我们不再分析。ProgressivePromise表示异步的进度结果，也不再进行分析。
+
+# 666. 彩蛋
+
+一条有趣的评论：
+
+> 其实Netty在实现Future接口的cancel和isDone方法时违反了Java的约定规则，请参见文章：https://www.jianshu.com/p/6a87ceb7f70a
\ No newline at end of file
diff --git a/netty/60-Netty 源码解析-Util 之 FastThreadLocal.assets/jpeg-17199762768541.webp b/netty/60-Netty 源码解析-Util 之 FastThreadLocal.assets/jpeg-17199762768541.webp
new file mode 100644
index 0000000..ae7af26
Binary files /dev/null and b/netty/60-Netty 源码解析-Util 之 FastThreadLocal.assets/jpeg-17199762768541.webp differ
diff --git a/netty/60-Netty 源码解析-Util 之 FastThreadLocal.assets/jpeg-17199762768552.webp b/netty/60-Netty 源码解析-Util 之 FastThreadLocal.assets/jpeg-17199762768552.webp
new file mode 100644
index 0000000..595fe26
Binary files /dev/null and b/netty/60-Netty 源码解析-Util 之 FastThreadLocal.assets/jpeg-17199762768552.webp differ
diff --git a/netty/60-Netty 源码解析-Util 之 FastThreadLocal.assets/jpeg-17199762768553.webp b/netty/60-Netty 源码解析-Util 之 FastThreadLocal.assets/jpeg-17199762768553.webp
new file mode 100644
index 0000000..cf8c0b1
Binary files /dev/null and b/netty/60-Netty 源码解析-Util 之 FastThreadLocal.assets/jpeg-17199762768553.webp differ
diff --git a/netty/60-Netty 源码解析-Util 之 FastThreadLocal.assets/jpeg-17199762768554.webp b/netty/60-Netty 源码解析-Util 之 FastThreadLocal.assets/jpeg-17199762768554.webp
new file mode 100644
index 0000000..fa2542a
Binary files /dev/null and b/netty/60-Netty 源码解析-Util 之 FastThreadLocal.assets/jpeg-17199762768554.webp differ
diff --git a/netty/60-Netty 源码解析-Util 之 FastThreadLocal.assets/jpeg-17199762768555.webp b/netty/60-Netty 源码解析-Util 之 FastThreadLocal.assets/jpeg-17199762768555.webp
new file mode 100644
index 0000000..2b4faa0
Binary files /dev/null and b/netty/60-Netty 源码解析-Util 之 FastThreadLocal.assets/jpeg-17199762768555.webp differ
diff --git a/netty/60-Netty 源码解析-Util 之 FastThreadLocal.assets/jpeg-17199762768556.webp b/netty/60-Netty 源码解析-Util 之 FastThreadLocal.assets/jpeg-17199762768556.webp
new file mode 100644
index 0000000..de5e638
Binary files /dev/null and b/netty/60-Netty 源码解析-Util 之 FastThreadLocal.assets/jpeg-17199762768556.webp differ
diff --git a/netty/60-Netty 源码解析-Util 之 FastThreadLocal.assets/jpeg.webp b/netty/60-Netty 源码解析-Util 之 FastThreadLocal.assets/jpeg.webp
new file mode 100644
index 0000000..deae9ef
Binary files /dev/null and b/netty/60-Netty 源码解析-Util 之 FastThreadLocal.assets/jpeg.webp differ
diff --git a/netty/60-Netty 源码解析-Util 之 FastThreadLocal.md b/netty/60-Netty 源码解析-Util 之 FastThreadLocal.md
new file mode 100644
index 0000000..3c3c0fe
--- /dev/null
+++ b/netty/60-Netty 源码解析-Util 之 FastThreadLocal.md	
@@ -0,0 +1,476 @@
+# 精尽 Netty 源码解析 —— Util 之 FastThreadLocal
+
+笔者先把 Netty 主要的内容写完，所以关于 FastThreadLocal 的分享，先放在后续的计划里。
+
+> 老艿艿：其实是因为，自己想去研究下 Service Mesh ，所以先简单收个小尾。
+
+当然，良心如我，还是为对这块感兴趣的胖友，先准备好了一篇不错的文章：
+
+- 莫那一鲁道
+
+   
+
+  《Netty 高性能之道 FastThreadLocal 源码分析（快且安全）》
+
+  - 😈 我的好基友，可以关注下他的简书。
+
+- 暗夜君王 [《【源起Netty 外传】FastThreadLocal怎么Fast？》](https://segmentfault.com/a/1190000012926809)
+
+为避免可能 [《Netty 高性能之道 FastThreadLocal 源码分析（快且安全）》](https://www.jianshu.com/p/3fc2fbac4bb7) 被作者删除，笔者这里先复制一份作为备份。
+
+# 666. 备份
+
+## 前言
+
+Netty 作为高性能框架，对 JDK 中的很多类都进行了封装了和优化，例如 Thread 类，Netty 使用了 FastThreadLocalRunnable 对所有 DefaultThreadFactory 创建出来的 Runnable 都进行了包装。包装的目的是 run 方法的不同，看代码：
+
+```
+public void run() {
+    try {
+        runnable.run();
+    } finally {
+        FastThreadLocal.removeAll();
+    }
+}
+```
+
+可以看到，多了一行 FastThreadLocal.removeAll()，众所周知，JDK 中自带的 ThreadLocal 在线程池使用环境中，有内存泄漏的风险，很明显，Netty 为了避免这个 bug，重新进行了封装，而且这个封装线程的名字叫做 FastThreadLocalRunnable，语义很明显：快速的 ThreadLocal！意思说 JDK 自带的慢喽？那我们今天就来看看到底快在哪里？对 ThreadLocal 内存泄漏不清楚或者对 ThreadLoca 不清楚的可以移步 [并发编程之 ThreadLocal 源码剖析](https://www.jianshu.com/p/80284438bb97)。
+
+## 1. 如何使用？
+
+[![img](60-Netty 源码解析-Util 之 FastThreadLocal.assets/jpeg.webp)](https://upload-images.jianshu.io/upload_images/4236553-12c253f98742f4b2.png?imageMogr2/auto-orient/strip|imageView2/2/w/648/format/jpeg)img
+
+测试用例
+
+[![img](60-Netty 源码解析-Util 之 FastThreadLocal.assets/jpeg-17199762768541.webp)](https://upload-images.jianshu.io/upload_images/4236553-7ec7f64c3cbf86f8.png?imageMogr2/auto-orient/strip|imageView2/2/w/454/format/jpeg)img
+
+运行结果
+
+## 2. 构造方法解析
+
+[![img](60-Netty 源码解析-Util 之 FastThreadLocal.assets/jpeg-17199762768552.webp)](https://upload-images.jianshu.io/upload_images/4236553-852af1ffc45a7a99.png?imageMogr2/auto-orient/strip|imageView2/2/w/563/format/jpeg)img
+
+构造方法
+
+构造方法中定义了两个变量。 index 和 cleanerFlagIndex，这两个变量且都是 int final 的。且都是通过
+InternalThreadLocalMap.nextVariableIndex() 方法而来。
+
+[![img](60-Netty 源码解析-Util 之 FastThreadLocal.assets/jpeg-17199762768553.webp)](https://upload-images.jianshu.io/upload_images/4236553-266a99ac72429da7.png?imageMogr2/auto-orient/strip|imageView2/2/w/719/format/jpeg)img
+
+InternalThreadLocalMap.nextVariableIndex() 方法
+
+[![img](60-Netty 源码解析-Util 之 FastThreadLocal.assets/jpeg-17199762768554.webp)](https://upload-images.jianshu.io/upload_images/4236553-5cdca30965ae3c19.png?imageMogr2/auto-orient/strip|imageView2/2/w/552/format/jpeg)img
+
+nextIndex 变量
+
+该方法通过一个原子 int 变量自增得到。也就是说，cleanerFlagIndex 变量比 index 大1，这两个变量的作用稍后我们会看到他们如何使用。这里暂且不表。
+
+## 3. set 方法解析
+
+[![img](60-Netty 源码解析-Util 之 FastThreadLocal.assets/jpeg-17199762768555.webp)](https://upload-images.jianshu.io/upload_images/4236553-30ec041c29b4c55d.png?imageMogr2/auto-orient/strip|imageView2/2/w/698/format/jpeg)img
+
+set（） 方法
+
+该方法步骤如下：
+
+1. 判断设置的 value 值是否是缺省值，如果是，则调用 remove 方法。
+2. 如果不是，则获取道当前线程的 InternalThreadLocalMap。然后将该 FastThreadLocal 对应的 index 下标的 value 替换成新的 value。老的 value 设置成缺省值。
+
+**小小的一个 set 方法，内部可是非常的复杂，非战斗人员请尽快撤离！**
+
+实际上，这里调用了4个方法：
+
+1. InternalThreadLocalMap.get()；
+2. setKnownNotUnset(threadLocalMap, value);
+3. registerCleaner(threadLocalMap);
+4. remove();
+
+让我们慢慢说道说道。
+
+#### 1. InternalThreadLocalMap.get()；
+
+代码如下：
+
+```
+public static InternalThreadLocalMap get() {
+    Thread thread = Thread.currentThread();
+    if (thread instanceof FastThreadLocalThread) {
+        return fastGet((FastThreadLocalThread) thread);
+    } else {
+        return slowGet();
+    }
+}
+```
+
+首先是 InternalThreadLocalMap 的静态方法，方法逻辑很简单，主要是根据当前线程是否是 Netty 的 FastThreadLocalThread 来调用不同的方法，一个是 fast 的，一个 是 slow 的（不是 Netty 的线程就是 slow 的）。哈哈哈，Netty 的作者命名还真是犀利。那我们就看看 fastGet 方法是什么？
+
+```
+private static InternalThreadLocalMap fastGet(FastThreadLocalThread thread) {
+    InternalThreadLocalMap threadLocalMap = thread.threadLocalMap();
+    if (threadLocalMap == null) {
+        thread.setThreadLocalMap(threadLocalMap = new InternalThreadLocalMap());
+    }
+    return threadLocalMap;
+}
+```
+
+逻辑很简单，获取当前线程的 InternalThreadLocalMap，如果没有，就创建一个。我们看看他的构造方法。
+
+```
+public static final Object UNSET = new Object();
+
+private InternalThreadLocalMap() {
+    super(newIndexedVariableTable());
+}
+
+private static Object[] newIndexedVariableTable() {
+    Object[] array = new Object[32];
+    Arrays.fill(array, UNSET);
+    return array;
+}
+
+UnpaddedInternalThreadLocalMap(Object[] indexedVariables) {
+    this.indexedVariables = indexedVariables;
+}
+```
+
+楼主将 3 个关联的方法都放在一起了，方便查看，首先，InternalThreadLocalMap 调用的父类 UnpaddedInternalThreadLocalMap 的构造方法，并传入了一个数组，而这个数组默认大小是 32，里面填充32 个空对象的引用。
+
+那 slowGet 方法又是什么样子的呢？代码如下：
+
+```
+static final ThreadLocal<InternalThreadLocalMap> slowThreadLocalMap = new ThreadLocal<InternalThreadLocalMap>();
+
+private static InternalThreadLocalMap slowGet() {
+    ThreadLocal<InternalThreadLocalMap> slowThreadLocalMap = UnpaddedInternalThreadLocalMap.slowThreadLocalMap;
+    InternalThreadLocalMap ret = slowThreadLocalMap.get();
+    if (ret == null) {
+        ret = new InternalThreadLocalMap();
+        slowThreadLocalMap.set(ret);
+    }
+    return ret;
+}
+```
+
+代码还是很简单的，我们分析一下：首先使用 JDK 的 ThreadLocal 获取一个 Netty 的 InternalThreadLocalMap，如果没有就创建一个，并将这个 InternalThreadLocalMap 设置到 JDK 的 ThreadLocal 中，然后返回这个 InternalThreadLocalMap。从这里可以看出，为了提高性能，Netty 还是避免使用了JDK 的 threadLocalMap，他的方式是曲线救国：在JDK 的 threadLocal 中设置 Netty 的 InternalThreadLocalMap ，然后，这个 InternalThreadLocalMap 中设置 Netty 的 FastThreadLcoal。
+
+好，到这里，我们的 InternalThreadLocalMap.get() 方法就看完了，主要是获取当前线程的 InternalThreadLocalMap，如果没有，就创建一个，这个 Map 内部维护的是一个数组，和 JDK 不同，JDK
+维护的是一个使用线性探测法的 Map，可见，从底层数据结构上，JDK 就已经输了，他们的读取速度相差很大，特别是当数据量很大的时候，Netty 的数据结构速度依然不变，而 JDK 由于使用线性探测法，速度会相应的下降。
+
+#### 2. setKnownNotUnset(threadLocalMap, value);
+
+当 InternalThreadLocalMap.get() 返回了 一个 InternalThreadLocalMap，这个时候调用 setKnownNotUnset(threadLocalMap, value); 方法进行操作。代码如下：
+
+```
+private boolean setKnownNotUnset(InternalThreadLocalMap threadLocalMap, V value) {
+    if (threadLocalMap.setIndexedVariable(index, value)) {
+        addToVariablesToRemove(threadLocalMap, this);
+        return true;
+    }
+    return false;
+}
+```
+
+看方法名称，是设置一个值，但不是 unset，也就是那个空对象。通过 threadLocalMap.setIndexedVariable(index, value) 进行设置。如果返回 true，则调用 addToVariablesToRemove(threadLocalMap, this) 。这两个方法，我们一起看看。先看第一个：
+
+setIndexedVariable 方法
+
+```
+public boolean setIndexedVariable(int index, Object value) {
+    Object[] lookup = indexedVariables;
+    if (index < lookup.length) {
+        Object oldValue = lookup[index];
+        lookup[index] = value;
+        return oldValue == UNSET;
+    } else {
+        expandIndexedVariableTableAndSet(index, value);
+        return true;
+    }
+}
+```
+
+首先，拿到那个 32 长度的数组，如果 FastThreadLocal 的 index 属性小于数组长度，则将值设定到指定槽位。将原来槽位的值设置为空对象。如果原来的对象也是空对象，则返回 true，否则返回 false。
+
+如果不够呢？调用 expandIndexedVariableTableAndSet(index, value) 方法。进入该方法查看。看方法名称是扩大索引并设置值。
+
+```
+private void expandIndexedVariableTableAndSet(int index, Object value) {
+    Object[] oldArray = indexedVariables;
+    final int oldCapacity = oldArray.length;
+    int newCapacity = index;
+    newCapacity |= newCapacity >>>  1;
+    newCapacity |= newCapacity >>>  2;
+    newCapacity |= newCapacity >>>  4;
+    newCapacity |= newCapacity >>>  8;
+    newCapacity |= newCapacity >>> 16;
+    newCapacity ++;
+
+    Object[] newArray = Arrays.copyOf(oldArray, newCapacity);
+    Arrays.fill(newArray, oldCapacity, newArray.length, UNSET);
+    newArray[index] = value;
+    indexedVariables = newArray;
+}
+```
+
+这里代码很熟悉，HashMap 中也有这样的代码，我们去看看：
+
+[![img](60-Netty 源码解析-Util 之 FastThreadLocal.assets/jpeg-17199762768556.webp)](https://upload-images.jianshu.io/upload_images/4236553-bb4c10b59073c4f7.png?imageMogr2/auto-orient/strip|imageView2/2/w/647/format/jpeg)img
+
+HashMap 中的 tableSizeFor 方法
+
+这段代码的作用就是按原来的容量扩容2倍。并且保证结果是2的幂次方。这里 Netty 的做法和 HashMap 一样，按照原来的容量扩容到最近的 2 的幂次方大小，比如原来32，就扩容到64，然后，将原来数组的内容填充到新数组中，剩余的填充`空对象`，然后将新数组赋值给成员变量 indexedVariables。完成了一次扩容。
+
+回到 setKnownNotUnset 方法中，setIndexedVariable 方法什么情况下会返回 ture 呢？扩容了，或者没扩容，但插入的对象没有替换掉别的对象，也就是原槽位是空对象。换句话说，只有更新了对象才会返回 false。
+
+也就是说，当新增了对象的时候，会调用 addToVariablesToRemove 方法，如同方法名，添加变量然后删除。我们看看 addToVariablesToRemove(threadLocalMap, this) 方法逻辑：
+
+```
+private static void addToVariablesToRemove(InternalThreadLocalMap threadLocalMap, FastThreadLocal<?> variable) {
+    // 该变量是 static final 的，因此通常是 0
+    Object v = threadLocalMap.indexedVariable(variablesToRemoveIndex);
+    Set<FastThreadLocal<?>> variablesToRemove;
+    if (v == InternalThreadLocalMap.UNSET || v == null) {
+        // 创建一个基于 IdentityHashMap 的 Set，泛型是 FastThreadLocal
+        variablesToRemove = Collections.newSetFromMap(new IdentityHashMap<FastThreadLocal<?>, Boolean>());
+        // 将这个 Set 放到这个 Map 数组的下标 0 处
+        threadLocalMap.setIndexedVariable(variablesToRemoveIndex, variablesToRemove);
+    } else {
+        // 如果拿到的不是 UNSET ，说明这是第二次操作了，因此可以强转为 Set
+        variablesToRemove = (Set<FastThreadLocal<?>>) v;
+    }
+
+    // 最后的目的就是将 FastThreadLocal 放置到 Set 中
+    variablesToRemove.add(variable);
+}
+```
+
+这个方法的目的是将 FastThreadLocal 对象保存到一个 Set 中，因为 Netty 的 Map 只是一个数组，没有键，所以保存到一个 Set 中，这样就可以判断是否 set 过这个 map，例如 Netty 的 isSet 方法就是根据这个判断的。
+
+说完了 setKnownNotUnset 方法，我们再说说 registerCleaner 方法。
+
+#### 3. registerCleaner(threadLocalMap);
+
+这个方法可以说有点复杂了，请耐住性子，这里是 ftl（FastThreadLocal） 的精髓。
+
+首先说下该方法的作用：将这个 ftl 注册到一个 `清理线程` 中，当 thread 对象被 gc 的时候，则会自动清理掉 ftl，防止 JDK 的内存泄漏问题。
+
+让我们进入该方法查看：
+
+```
+private void registerCleaner(final InternalThreadLocalMap threadLocalMap) {
+    Thread current = Thread.currentThread();
+    if (FastThreadLocalThread.willCleanupFastThreadLocals(current) ||
+        threadLocalMap.indexedVariable(cleanerFlagIndex) != InternalThreadLocalMap.UNSET) {
+        return;
+    }
+    threadLocalMap.setIndexedVariable(cleanerFlagIndex, Boolean.TRUE);
+    ObjectCleaner.register(current, new Runnable() {
+        public void run() {
+            remove(threadLocalMap);
+        }
+    });
+}
+```
+
+楼主删除了源码中的注释，我们来好好说说这个方法：
+
+1. 获取当前线程，如果当前线程是 FastThreadLocalThread 类型 且 cleanupFastThreadLocals 是 true，则返回 true，直接return。也就是说，Netty 线程池里面创建的线程都符合这条件，只有用户自定义的线程池不符合。
+   当然还有一个条件：如果这个 ftl 的 index + 1 在 map 中的值不是空对象，则已经注册过了，也直接 return，不再重复注册。
+2. 当不符合上面的条件的时候，将 Map 中对应的 ftl 的 index + 1 位置的值设置为 TRUE。根据上面的判断，防止重复注册。
+3. 调用 ObjectCleaner 的 register 方法，注册一个任务，任务的内容就是调用 remove 方法，删除 ftl 在 map 中的对象和相应的内容。
+
+问题来了，怎么注册的呢？为什么还带着一个 current 当前线程呢？
+
+我们看看源码：
+
+```
+public static void register(Object object, Runnable cleanupTask) {
+    AutomaticCleanerReference reference = new AutomaticCleanerReference(object,
+            ObjectUtil.checkNotNull(cleanupTask, "cleanupTask"));
+    LIVE_SET.add(reference);
+
+    // Check if there is already a cleaner running.
+    if (CLEANER_RUNNING.compareAndSet(false, true)) {
+        final Thread cleanupThread = new FastThreadLocalThread(CLEANER_TASK);
+        cleanupThread.setPriority(Thread.MIN_PRIORITY);
+        AccessController.doPrivileged(new PrivilegedAction<Void>() {
+            public Void run() {
+                cleanupThread.setContextClassLoader(null);
+                return null;
+            }
+        });
+        cleanupThread.setName(CLEANER_THREAD_NAME);
+        cleanupThread.setDaemon(true);
+        cleanupThread.start();
+    }
+}
+```
+
+首先创建一个 AutomaticCleanerReference 自动清洁对象，继承了 WeakReference，先不看他的构造方法，先看下面，将这个构造好的实例放入到 LIVE_SET 中，实际上，这是一个 Netty 封装的 ConcurrentSet，然后判断清除线程是否在运行。如果没有，并且CAS改状态成功。就创建一个线程，任务是 定义好的 CLEANER_TASK，线程优先级是最低，上下位类加载器是null，名字是 objectCleanerThread，并且是后台线程。然后启动这个线程。运行 CLEANER_TASK。
+
+一步一步来看看。
+
+首先 AutomaticCleanerReference 的构造方法如下：
+
+```
+private static final ReferenceQueue<Object> REFERENCE_QUEUE = new ReferenceQueue<Object>();
+
+AutomaticCleanerReference(Object referent, Runnable cleanupTask) {
+    super(referent, REFERENCE_QUEUE);
+    this.cleanupTask = cleanupTask;
+}   
+
+void cleanup() {
+   cleanupTask.run();
+}
+```
+
+ReferenceQueue 的作用是，当对象被回收的时候，会将这个对象添加进这个队列，就可以跟踪这个对象。设置可以复活这个对象。也就是说，当这个 Thread 对象被回收的时候，会将这个对象放进这个引用队列，放进入干嘛呢？什么时候取出来呢？我们看看什么时候取出来：
+
+代码如下：
+
+```
+private static final Runnable CLEANER_TASK = new Runnable() {
+    @Override
+    public void run() {
+        for (;;) {
+            while (!LIVE_SET.isEmpty()) {
+                final AutomaticCleanerReference reference = (AutomaticCleanerReference) REFERENCE_QUEUE.remove(REFERENCE_QUEUE_POLL_TIMEOUT_MS);
+               
+                if (reference != null) {
+                    try {
+                        reference.cleanup();
+                    } catch (Throwable ignored) {
+                    }
+                    LIVE_SET.remove(reference);
+                }
+            }
+            CLEANER_RUNNING.set(false);
+            if (LIVE_SET.isEmpty() || !CLEANER_RUNNING.compareAndSet(false, true)) {
+                break;
+            }
+        }
+    }
+};
+```
+
+巧了 ！！！！正是 CLEANER_TASK 在使用这个 ReferenceQueue！！！！别激动，我们还是慢慢看看这个任务到底是做什么的：
+
+1. 死循环，如果 ConcurrentSet 不是空（还记得我们将 AutomaticCleanerReference 放进这里吗），尝试从 REFERENCE_QUEUE 中取出 AutomaticCleanerReference，也就是我们刚刚放进入的。这是标准的跟踪 GC 对象的做法。因为当一个对象被 GC 时，会将保证这个对象的 Reference 放进指定的引用队列，这是 JVM 做的。
+2. 如果不是空，就调用应用的 cleanUp 方法，也就是我们传进去的任务，什么任务？就是那个调用 ftl 的 remove 方法的任务。随后从 Set 中删除这个引用。
+3. 如果 Set 是空的话，将清理线程状态（原子变量） 设置成 fasle。
+4. 继续判断，如果Set 还是空，或者 Set 不是空 且 设置 CAS 设置状态为true 失败（说明其他线程改了这个状态）则跳出循环，结束线程。
+
+有点懵？那我们就好好总结这里为什么这么做：
+
+> 当我们在一个非 Netty 线程池创建的线程中使用 ftl 的时候，Netty 会注册一个垃圾清理线程（因为 Netty 线程池创建的线程最终都会执行 removeAll 方法，不会出现内存泄漏） ，用于清理这个线程这个 ftl 变量，从上面的代码中，我们知道，非 Netty 线程如果使用 ftl，Netty 仍然会借助 JDK 的 ThreadLocal，只是只借用一个槽位，放置 Netty 的 Map， Map 中再放置 Netty 的 ftl 。所以，在使用线程池的情况下可能会出现内存泄漏。**Netty 为了解决这个问题，在每次使用新的 ftl 的时候，都将这个 ftl 注册到和线程对象绑定到一个 GC 引用上， 当这个线程对象被回收的时候，也会顺便清理掉他的 Map 中的 所有 ftl，解决了该问题，就像解决 JDK Nio bug 一样。**
+
+好，到这里，Netty 的 FastThreadLocal 的精华我们基本就全部吸取了。ftl 不仅快，而且安全。快在使用数组代替线性探测法的 Map，安全在每次线程回收的时候都清理 ftl，不用担心内存泄漏。
+
+剩下的方法都是很简单的。我们一起看完吧
+
+#### 4. remove();
+
+每次 Set 一个空对象的时候，就是调用remove 方法，我们看看该方法，源码如下：
+
+```
+public final void remove() {
+     remove(InternalThreadLocalMap.getIfSet());
+ }
+
+ public static InternalThreadLocalMap getIfSet() {
+     Thread thread = Thread.currentThread();
+     if (thread instanceof FastThreadLocalThread) {
+         return ((FastThreadLocalThread) thread).threadLocalMap();
+     }
+     return slowThreadLocalMap.get();
+
+ }
+
+ public final void remove(InternalThreadLocalMap threadLocalMap) {
+     if (threadLocalMap == null) {
+         return;
+     }
+     // 删除并返回 Map 数组中当前 ThreadLocal index 对应的 value
+     Object v = threadLocalMap.removeIndexedVariable(index);
+     // 从 Map 数组下标 0 的位置取出 Set ，并删除当前的 ThreadLocal
+     removeFromVariablesToRemove(threadLocalMap, this);
+
+     if (v != InternalThreadLocalMap.UNSET) {
+         try {
+             // 默认啥也不做，用户可以继承 FastThreadLocal 重定义这个方法。
+             onRemoval((V) v);
+         } catch (Exception e) {
+             PlatformDependent.throwException(e);
+         }
+     }
+ }
+```
+
+楼主将这3个方法都合并在一起了，首先获取当前线程的 threadLocalMap，然后就像注释中写的：删除 ftl 对应下标中 map 的 value，然后删除 map 下标0 处 Set 中的 ftl。防止 isSet 方法误判。最后，如果用户重写了 onRemoval 方法，就调用，默认是个空方法。用户可以重写 onRemoval 方法和 initialize 方法。
+
+## 4. get 方法解析
+
+get 方法就更简单了，代码如下：
+
+```
+public final V get() {
+    InternalThreadLocalMap threadLocalMap = InternalThreadLocalMap.get();
+    Object v = threadLocalMap.indexedVariable(index);
+    if (v != InternalThreadLocalMap.UNSET) {
+        return (V) v;
+    }
+
+    V value = initialize(threadLocalMap);
+    registerCleaner(threadLocalMap);
+    return value;
+}
+```
+
+首先获取当前线程的map，然后根据 ftl 的 index 获取 value，然后返回，如果是空对象，也就是没有设置，则通过 initialize 返回，initialize 方法会将返回值设置到 map 的槽位中，并放进 Set 中。最后，尝试注册一个清洁器。
+
+## 5. remove All方法解析
+
+这个方法在 Netty 的默认线程的 finally 块中调用。代码如下：
+
+```
+public static void removeAll() {
+    InternalThreadLocalMap threadLocalMap = InternalThreadLocalMap.getIfSet();
+    if (threadLocalMap == null) {
+        return;
+    }
+
+    try {
+        Object v = threadLocalMap.indexedVariable(variablesToRemoveIndex);
+        if (v != null && v != InternalThreadLocalMap.UNSET) {
+            @SuppressWarnings("unchecked")
+            Set<FastThreadLocal<?>> variablesToRemove = (Set<FastThreadLocal<?>>) v;
+            FastThreadLocal<?>[] variablesToRemoveArray =
+                    variablesToRemove.toArray(new FastThreadLocal[variablesToRemove.size()]);
+            for (FastThreadLocal<?> tlv: variablesToRemoveArray) {
+                tlv.remove(threadLocalMap);
+            }
+        }
+    } finally {
+        InternalThreadLocalMap.remove();
+    }
+}
+```
+
+非常简单，首先获取当前线程map，然后获取 Set，将 Set 转成数组，遍历数组，调用 ftl 的 remove 方法。最后，删除线程中 的 map 属性。
+
+## 总结
+
+现在我们来总结一下 FastThreadLocal 。
+
+之所以称之为 Fast，因为没有使用 JDK 的使用线性探测法的 Map，如果你使用的是Netty 线程池工厂创建的线程，搭配 Netty 的 ftl，性能非常好，如果你使用自定义的线程，搭配 ftl，性能也会比 JDK 的好，注意： ftl 没有 JDK 的内存泄露的风险。
+
+但做到这些不是没有代价的，由于每一个 ftl 都是一个唯一的下标，而这个下标是每次创建一个 ftl 对象都是递增 2，当你的下标很大，你的线程中的 Map 相应的也要增大，可以想象，如果创建了海量的 ftl 对象，这个数组的浪费是非常客观的。很明显，这是一种空间换时间的做法。
+
+通常，ftl 都是静态对象，所以不会有我们假设的那么多。如果使用不当，确实会浪费大量内存。
+
+但这个风险带来的好处是明显的，在楼主的机器上测试，ftl 的读取性能是 JDK 的 5 倍左右，写入的速度也要快 20% 左右。
+
+FastThreadLocal 人如其名，快且安全！
+
+今天就到这里，good luck！！！！
\ No newline at end of file
diff --git a/netty/61-Netty 源码解析-Util 之 Recycler.assets/jpeg-17199762893821.webp b/netty/61-Netty 源码解析-Util 之 Recycler.assets/jpeg-17199762893821.webp
new file mode 100644
index 0000000..8f2b32b
Binary files /dev/null and b/netty/61-Netty 源码解析-Util 之 Recycler.assets/jpeg-17199762893821.webp differ
diff --git a/netty/61-Netty 源码解析-Util 之 Recycler.assets/jpeg.webp b/netty/61-Netty 源码解析-Util 之 Recycler.assets/jpeg.webp
new file mode 100644
index 0000000..75d9bde
Binary files /dev/null and b/netty/61-Netty 源码解析-Util 之 Recycler.assets/jpeg.webp differ
diff --git a/netty/61-Netty 源码解析-Util 之 Recycler.md b/netty/61-Netty 源码解析-Util 之 Recycler.md
new file mode 100644
index 0000000..1284507
--- /dev/null
+++ b/netty/61-Netty 源码解析-Util 之 Recycler.md	
@@ -0,0 +1,394 @@
+# 精尽 Netty 源码解析 —— Util 之 Recycler
+
+笔者先把 Netty 主要的内容写完，所以关于 Recycler 的分享，先放在后续的计划里。
+
+> 老艿艿：其实是因为，自己想去研究下 Service Mesh ，所以先简单收个小尾。
+
+当然，良心如我，还是为对这块感兴趣的胖友，先准备好了一篇不错的文章：
+
+- 沧行 [《Netty之Recycler》](https://www.jianshu.com/p/4eab8450560c)
+
+为避免可能 [《Netty之Recycler》](https://www.jianshu.com/p/4eab8450560c) 被作者删除，笔者这里先复制一份作为备份。
+
+# 666. 备份
+
+Recycler用来实现对象池，其中对应堆内存和直接内存的池化实现分别是PooledHeapByteBuf和PooledDirectByteBuf。Recycler主要提供了3个方法：
+
+- get():获取一个对象。
+- recycle(T, Handle):回收一个对象，T为对象泛型。
+- newObject(Handle):当没有可用对象时创建对象的实现方法。
+
+Recycler的UML图如下：
+
+[![img](61-Netty 源码解析-Util 之 Recycler.assets/jpeg.webp)](https://upload-images.jianshu.io/upload_images/3751588-916c6baab07fa863.png?imageMogr2/auto-orient/strip|imageView2/2/w/1000/format/jpeg)img
+
+Recycler.png
+
+Recycler关联了4个核心类：
+
+- DefaultHandle:对象的包装类，在Recycler中缓存的对象都会包装成DefaultHandle类。
+- Stack:存储本线程回收的对象。对象的获取和回收对应Stack的pop和push，即获取对象时从Stack中pop出1个DefaultHandle，回收对象时将对象包装成DefaultHandle push到Stack中。Stack会与线程绑定，即每个用到Recycler的线程都会拥有1个Stack，在该线程中获取对象都是在该线程的Stack中pop出一个可用对象。
+- WeakOrderQueue:存储其它线程回收到本线程stack的对象，当某个线程从Stack中获取不到对象时会从WeakOrderQueue中获取对象。每个线程的Stack拥有1个WeakOrderQueue链表，链表每个节点对应1个其它线程的WeakOrderQueue，其它线程回收到该Stack的对象就存储在这个WeakOrderQueue里。
+- Link: WeakOrderQueue中包含1个Link链表，回收对象存储在链表某个Link节点里，当Link节点存储的回收对象满了时会新建1个Link放在Link链表尾。
+
+整个Recycler回收对象存储结构如下图所示：
+
+[![img](61-Netty 源码解析-Util 之 Recycler.assets/jpeg-17199762893821.webp)](https://upload-images.jianshu.io/upload_images/3751588-63236f0c4e59328d.png?imageMogr2/auto-orient/strip|imageView2/2/w/799/format/jpeg)img
+
+Recycler.png
+
+下面分析下源码，首先看下Recycler.recycle(T, Handle)方法，用于回收1个对象：
+
+```
+public final boolean recycle(T o, Handle handle) {
+    if (handle == NOOP_HANDLE) {
+        return false;
+    }
+
+    DefaultHandle h = (DefaultHandle) handle;
+    if (h.stack.parent != this) {
+        return false;
+    }
+    if (o != h.value) {
+        throw new IllegalArgumentException("o does not belong to handle");
+    }
+    h.recycle();
+    return true;
+}
+```
+
+回收1个对象会调用该对象DefaultHandle.recycle()方法，如下：
+
+```
+public void recycle() {
+   stack.push(this);
+}
+```
+
+回收1个对象（DefaultHandle）就是把该对象push到stack中。
+
+```
+void push(DefaultHandle item) {
+        Thread currentThread = Thread.currentThread();
+        if (thread == currentThread) {
+            // The current Thread is the thread that belongs to the Stack, we can try to push the object now.
+            /**
+             * 如果该stack就是本线程的stack，那么直接把DefaultHandle放到该stack的数组里
+             */
+            pushNow(item);
+        } else {
+            // The current Thread is not the one that belongs to the Stack, we need to signal that the push
+            // happens later.
+            /**
+             * 如果该stack不是本线程的stack，那么把该DefaultHandle放到该stack的WeakOrderQueue中
+             */
+            pushLater(item, currentThread);
+        }
+    }
+```
+
+这里分为两种情况，当stack是当前线程对应的stack时，执行pushNow(item)方法，直接把对象放到该stack的DefaultHandle数组中，如下：
+
+```
+/**
+ * 直接把DefaultHandle放到stack的数组里，如果数组满了那么扩展该数组为当前2倍大小
+ * @param item
+ */
+private void pushNow(DefaultHandle item) {
+    if ((item.recycleId | item.lastRecycledId) != 0) {
+        throw new IllegalStateException("recycled already");
+    }
+    item.recycleId = item.lastRecycledId = OWN_THREAD_ID;
+
+    int size = this.size;
+    if (size >= maxCapacity || dropHandle(item)) {
+        // Hit the maximum capacity or should drop - drop the possibly youngest object.
+        return;
+    }
+    if (size == elements.length) {
+        elements = Arrays.copyOf(elements, min(size << 1, maxCapacity));
+    }
+
+    elements[size] = item;
+    this.size = size + 1;
+}
+```
+
+当stack是其它线程的stack时，执行pushLater(item, currentThread)方法，将对象放到WeakOrderQueue中，如下：
+
+```
+private void pushLater(DefaultHandle item, Thread thread) {
+       /** 
+        * Recycler有1个stack->WeakOrderQueue映射，每个stack会映射到1个WeakOrderQueue，这个WeakOrderQueue是该stack关联的其它线程WeakOrderQueue链表的head WeakOrderQueue。
+        * 当其它线程回收对象到该stack时会创建1个WeakOrderQueue中并加到stack的WeakOrderQueue链表中。 
+        */
+        Map<Stack<?>, WeakOrderQueue> delayedRecycled = DELAYED_RECYCLED.get();
+        WeakOrderQueue queue = delayedRecycled.get(this);
+        if (queue == null) {
+            /**
+             * 如果delayedRecycled满了那么将1个伪造的WeakOrderQueue（DUMMY）放到delayedRecycled中，并丢弃该对象（DefaultHandle）
+             */
+            if (delayedRecycled.size() >= maxDelayedQueues) {
+                // Add a dummy queue so we know we should drop the object
+                delayedRecycled.put(this, WeakOrderQueue.DUMMY);
+                return;
+            }
+            // Check if we already reached the maximum number of delayed queues and if we can allocate at all.
+            /**
+             * 创建1个WeakOrderQueue
+             */
+            if ((queue = WeakOrderQueue.allocate(this, thread)) == null) {
+                // drop object
+                return;
+            }
+            delayedRecycled.put(this, queue);
+        } else if (queue == WeakOrderQueue.DUMMY) {
+            // drop object
+            return;
+        }
+
+        /**
+         * 将对象放入到该stack对应的WeakOrderQueue中
+         */
+        queue.add(item);
+    }
+
+
+static WeakOrderQueue allocate(Stack<?> stack, Thread thread) {
+        // We allocated a Link so reserve the space
+        /**
+         * 如果该stack的可用共享空间还能再容下1个WeakOrderQueue，那么创建1个WeakOrderQueue，否则返回null
+         */
+        return reserveSpace(stack.availableSharedCapacity, LINK_CAPACITY)
+                ? new WeakOrderQueue(stack, thread) : null;
+    }
+```
+
+WeakOrderQueue的构造函数如下，WeakOrderQueue实现了多线程环境下回收对象的机制，当由其它线程回收对象到stack时会为该stack创建1个WeakOrderQueue，这些由其它线程创建的WeakOrderQueue会在该stack中按链表形式串联起来，每次创建1个WeakOrderQueue会把该WeakOrderQueue作为该stack的head WeakOrderQueue：
+
+```
+private WeakOrderQueue(Stack<?> stack, Thread thread) {
+        head = tail = new Link();
+        owner = new WeakReference<Thread>(thread);
+        /**
+         * 每次创建WeakOrderQueue时会更新WeakOrderQueue所属的stack的head为当前WeakOrderQueue， 当前WeakOrderQueue的next为stack的之前head，
+         * 这样把该stack的WeakOrderQueue通过链表串起来了，当下次stack中没有可用对象需要从WeakOrderQueue中转移对象时从WeakOrderQueue链表的head进行scavenge转移到stack的对DefaultHandle数组。
+         */
+        synchronized (stack) {
+            next = stack.head;
+            stack.head = this;
+        }
+        availableSharedCapacity = stack.availableSharedCapacity;
+    }
+```
+
+下面再看Recycler.get()方法：
+
+```
+public final T get() {
+    if (maxCapacity == 0) {
+        return newObject(NOOP_HANDLE);
+    }
+    Stack<T> stack = threadLocal.get();
+    DefaultHandle handle = stack.pop();
+    if (handle == null) {
+        handle = stack.newHandle();
+        handle.value = newObject(handle);
+    }
+    return (T) handle.value;
+}
+```
+
+取出该线程对应的stack，从stack中pop出1个DefaultHandle，返回该DefaultHandle的真正对象。
+下面看stack.pop()方法：
+
+```
+DefaultHandle pop() {
+        int size = this.size;
+        if (size == 0) {
+            if (!scavenge()) {
+                return null;
+            }
+            size = this.size;
+        }
+        size --;
+        DefaultHandle ret = elements[size];
+        elements[size] = null;
+        if (ret.lastRecycledId != ret.recycleId) {
+            throw new IllegalStateException("recycled multiple times");
+        }
+        ret.recycleId = 0;
+        ret.lastRecycledId = 0;
+        this.size = size;
+        return ret;
+    }
+```
+
+如果该stack的DefaultHandle数组中还有对象可用，那么从该DefaultHandle数组中取出1个可用对象返回，如果该DefaultHandle数组没有可用的对象了，那么执行scavenge()方法，将head WeakOrderQueue中的head Link中的DefaultHandle数组转移到stack的DefaultHandle数组，scavenge方法如下：
+
+```
+boolean scavenge() {
+        // continue an existing scavenge, if any
+        if (scavengeSome()) {
+            return true;
+        }
+
+        // reset our scavenge cursor
+        prev = null;
+        cursor = head;
+        return false;
+    }
+```
+
+具体执行了scavengeSome()方法，清理WeakOrderQueue中部分DefaultHandle到stack，每次尽可能清理head WeakOrderQueue的head Link的全部DefaultHandle，如下：
+
+```
+boolean scavengeSome() {
+        WeakOrderQueue cursor = this.cursor;
+        if (cursor == null) {
+            cursor = head;
+            if (cursor == null) {
+                return false;
+            }
+        }
+
+        boolean success = false;
+        WeakOrderQueue prev = this.prev;
+        do {
+            /**
+             * 将当前WeakOrderQueue的head Link的DefaultHandle数组转移到stack的DefaultHandle数组中
+             */
+            if (cursor.transfer(this)) {
+                success = true;
+                break;
+            }
+
+            WeakOrderQueue next = cursor.next;
+            if (cursor.owner.get() == null) {
+                if (cursor.hasFinalData()) {
+                    for (;;) {
+                        if (cursor.transfer(this)) {
+                            success = true;
+                        } else {
+                            break;
+                        }
+                    }
+                }
+                if (prev != null) {
+                    prev.next = next;
+                }
+            } else {
+                prev = cursor;
+            }
+
+            cursor = next;
+
+        } while (cursor != null && !success);
+
+        this.prev = prev;
+        this.cursor = cursor;
+        return success;
+    }
+```
+
+WeakOrderQueue.transfer()方法如下，将WeakOrderQueue的head Link中的DefaultHandle数组迁移到stack中：
+
+```
+boolean transfer(Stack<?> dst) {
+        Link head = this.head;
+        if (head == null) {
+            return false;
+        }
+
+        /**
+         * 如果head Link的readIndex到达了Link的容量LINK_CAPACITY，说明该Link已经被scavengge完了。
+         * 这时需要把下一个Link作为新的head Link。
+         */
+        if (head.readIndex == LINK_CAPACITY) {
+            if (head.next == null) {
+                return false;
+            }
+            this.head = head = head.next;
+        }
+
+        final int srcStart = head.readIndex;
+        /**
+         * head Link的回收对象数组的最大位置
+         */
+        int srcEnd = head.get();
+        /**
+         * head Link可以scavenge的DefaultHandle的数量
+         */
+        final int srcSize = srcEnd - srcStart;
+        if (srcSize == 0) {
+            return false;
+        }
+
+        final int dstSize = dst.size;
+
+        /**
+         * 每次会尽可能scavenge整个head Link，如果head Link的DefaultHandle数组能全部迁移到stack中，stack的DefaultHandle数组预期容量
+         */
+        final int expectedCapacity = dstSize + srcSize;
+        /**
+         * 如果预期容量大于stack的DefaultHandle数组最大长度，说明本次无法将head Link的DefaultHandle数组全部迁移到stack中
+         */
+        if (expectedCapacity > dst.elements.length) {
+            final int actualCapacity = dst.increaseCapacity(expectedCapacity);
+            srcEnd = min(srcStart + actualCapacity - dstSize, srcEnd);
+        }
+
+        if (srcStart != srcEnd) {
+            /**
+             * head Link的DefaultHandle数组
+             */
+            final DefaultHandle[] srcElems = head.elements;
+            /**
+             * stack的DefaultHandle数组
+             */
+            final DefaultHandle[] dstElems = dst.elements;
+            int newDstSize = dstSize;
+            /**
+             * 迁移head Link的DefaultHandle数组到stack的DefaultHandle数组
+             */
+            for (int i = srcStart; i < srcEnd; i++) {
+                DefaultHandle element = srcElems[i];
+                if (element.recycleId == 0) {
+                    element.recycleId = element.lastRecycledId;
+                } else if (element.recycleId != element.lastRecycledId) {
+                    throw new IllegalStateException("recycled already");
+                }
+                srcElems[i] = null;
+
+                if (dst.dropHandle(element)) {
+                    // Drop the object.
+                    continue;
+                }
+                element.stack = dst;
+                dstElems[newDstSize ++] = element;
+            }
+
+            /**
+             * 当head节点的对象全都转移给stack后，取head下一个节点作为head，下次转移的时候再从新的head转移回收的对象
+             */
+            if (srcEnd == LINK_CAPACITY && head.next != null) {
+                // Add capacity back as the Link is GCed.
+                reclaimSpace(LINK_CAPACITY);
+
+                this.head = head.next;
+            }
+            /**
+             * 迁移完成后更新原始head Link的readIndex
+             */
+            head.readIndex = srcEnd;
+            if (dst.size == newDstSize) {
+                return false;
+            }
+            dst.size = newDstSize;
+            return true;
+        } else {
+            // The destination stack is full already.
+            return false;
+        }
+    }
+```
\ No newline at end of file
diff --git a/netty/62-Netty 源码解析-Util 之 HashedWheelTimer.assets/89a84b18103e57fc95e596a47daa49c5.jpeg b/netty/62-Netty 源码解析-Util 之 HashedWheelTimer.assets/89a84b18103e57fc95e596a47daa49c5.jpeg
new file mode 100644
index 0000000..52b52c5
Binary files /dev/null and b/netty/62-Netty 源码解析-Util 之 HashedWheelTimer.assets/89a84b18103e57fc95e596a47daa49c5.jpeg differ
diff --git a/netty/62-Netty 源码解析-Util 之 HashedWheelTimer.assets/f3172a69ecb37b8c26871a2553bdeb2e.jpeg b/netty/62-Netty 源码解析-Util 之 HashedWheelTimer.assets/f3172a69ecb37b8c26871a2553bdeb2e.jpeg
new file mode 100644
index 0000000..152385f
Binary files /dev/null and b/netty/62-Netty 源码解析-Util 之 HashedWheelTimer.assets/f3172a69ecb37b8c26871a2553bdeb2e.jpeg differ
diff --git a/netty/62-Netty 源码解析-Util 之 HashedWheelTimer.md b/netty/62-Netty 源码解析-Util 之 HashedWheelTimer.md
new file mode 100644
index 0000000..38531a1
--- /dev/null
+++ b/netty/62-Netty 源码解析-Util 之 HashedWheelTimer.md	
@@ -0,0 +1,740 @@
+# 精尽 Netty 源码解析 —— Util 之 HashedWheelTimer
+
+笔者先把 Netty 主要的内容写完，所以关于 HashedWheelTimer 的分享，先放在后续的计划里。
+
+> 老艿艿：其实是因为，自己想去研究下 Service Mesh ，所以先简单收个小尾。
+
+当然，良心如我，还是为对这块感兴趣的胖友，先准备好了一篇不错的文章：
+
+- 德胜 [《Netty工具类HashedWheelTimer源码走读(一)》](https://my.oschina.net/haogrgr/blog/489320)
+- 德胜 [《Netty工具类HashedWheelTimer源码走读(二)》](https://my.oschina.net/haogrgr/blog/490266)
+- 德胜 [《Netty工具类HashedWheelTimer源码走读(三)》](https://my.oschina.net/haogrgr/blog/490348)
+- Zacard [《netty源码解读之时间轮算法实现-HashedWheelTimer》](https://zacard.net/2016/12/02/netty-hashedwheeltimer/)
+
+为避免可能 [《netty源码解读之时间轮算法实现-HashedWheelTimer》](https://zacard.net/2016/12/02/netty-hashedwheeltimer/) 被作者删除，笔者这里先复制一份作为备份。
+
+# 666. 备份
+
+## 前因
+
+由于netty动辄管理100w+的连接，每一个连接都会有很多超时任务。比如发送超时、心跳检测间隔等，如果每一个定时任务都启动一个`Timer`,不仅低效，而且会消耗大量的资源。
+
+## 解决方案
+
+根据George Varghese 和 Tony Lauck 1996 年的论文：[Hashed and Hierarchical Timing Wheels: data structures to efficiently implement a timer facility](http://static.iocoder.cn/62dc58eaa06cbd6f431dc616c375b717)。提出了一种定时轮的方式来管理和维护大量的`Timer`调度.
+
+## 原理
+
+时间轮其实就是一种环形的数据结构，可以想象成时钟，分成很多格子，一个格子代码一段时间（这个时间越短，`Timer`的精度越高）。并用一个链表报错在该格子上的到期任务，同时一个指针随着时间一格一格转动，并执行相应格子中的到期任务。任务通过`取摸`决定放入那个格子。如下图所示：
+
+[![img](62-Netty 源码解析-Util 之 HashedWheelTimer.assets/89a84b18103e57fc95e596a47daa49c5.jpeg)](http://static.iocoder.cn/89a84b18103e57fc95e596a47daa49c5)img
+
+以上图为例，假设一个格子是1秒，则整个wheel能表示的时间段为8s，假如当前指针指向2，此时需要调度一个3s后执行的任务，显然应该加入到(2+3=5)的方格中，指针再走3次就可以执行了；如果任务要在10s后执行，应该等指针走完一个round零2格再执行，因此应放入4，同时将round（1）保存到任务中。检查到期任务时应当只执行round为0的，格子上其他任务的round应减1。
+
+是不是很像java中的`Hashmap`。其实就是`HashMap`的哈希拉链算法，只不过多了指针转动与一些定时处理的逻辑。所以其相关的操作和`HashMap`也一致：
+
+- 添加任务：O(1)
+- 删除/取消任务：O(1)
+- 过期/执行任务：最差情况为O(n)->也就是当`HashMap`里面的元素全部hash冲突，退化为一条链表的情况。平均O(1)->显然，格子越多，每个格子上的链表就越短，这里需要权衡时间与空间。
+
+### 多层时间轮
+
+如果任务的时间跨度很大，数量很大，单层的时间轮会造成任务的`round`很大，单个格子的链表很长。这时候可以将时间轮分层，类似于时钟的时分秒3层。如下图所示：
+
+[![img](62-Netty 源码解析-Util 之 HashedWheelTimer.assets/f3172a69ecb37b8c26871a2553bdeb2e.jpeg)](http://static.iocoder.cn/f3172a69ecb37b8c26871a2553bdeb2e)img
+
+但是个人认为，多层的时间轮造成的算法复杂度的进一步提升。单层时间轮只需增加每一轮的格子就能解决链表过长的问题。因此，更倾向使用单层的时间轮，netty4中时间轮的实现也是单层的。
+
+## netty时间轮的实现-HashedWheelTimer
+
+### 简单使用示例
+
+1.引入netty依赖
+
+```
+<dependency>
+    <groupId>io.netty</groupId>
+    <artifactId>netty-all</artifactId>
+    <version>4.1.4.Final</version>
+</dependency>
+```
+
+2.示例代码
+
+示例1：
+
+```
+@Test
+public void test1() throws Exception {
+    DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss");
+    HashedWheelTimer hashedWheelTimer = new HashedWheelTimer(100, TimeUnit.MILLISECONDS);
+
+    System.out.println("start:" + LocalDateTime.now().format(formatter));
+
+    hashedWheelTimer.newTimeout(timeout -> {
+        System.out.println("task :" + LocalDateTime.now().format(formatter));
+    }, 3, TimeUnit.SECONDS);
+    Thread.sleep(5000);
+}
+```
+
+输出为：
+
+> start:2016-11-30 05:56:35
+>
+> task :2016-11-30 05:56:38
+
+示例2：
+
+```
+@Test
+public void test2() throws Exception {
+    DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss");
+    HashedWheelTimer hashedWheelTimer = new HashedWheelTimer(100, TimeUnit.MILLISECONDS);
+
+    System.out.println("start:" + LocalDateTime.now().format(formatter));
+
+    hashedWheelTimer.newTimeout(timeout -> {
+        Thread.sleep(3000);
+        System.out.println("task1:" + LocalDateTime.now().format(formatter));
+    }, 3, TimeUnit.SECONDS);
+
+    hashedWheelTimer.newTimeout(timeout -> System.out.println("task2:" + LocalDateTime.now().format(
+            formatter)), 4, TimeUnit.SECONDS);
+
+    Thread.sleep(10000);
+}
+```
+
+输出：
+
+> start:2016-12-01 08:32:37
+>
+> task1:2016-12-01 08:32:43
+>
+> task2:2016-12-01 08:32:43
+
+可以看到，当前一个任务执行时间过长的时候，会影响后续任务的到期执行时间的。也就是说其中的任务是串行执行的。所以，要求里面的任务都要短平快。
+
+### HashedWheelTimer源码之构造函数
+
+```
+  public HashedWheelTimer(
+          ThreadFactory threadFactory, // 用来创建worker线程
+          long tickDuration, // tick的时长，也就是指针多久转一格
+          TimeUnit unit, // tickDuration的时间单位
+          int ticksPerWheel, // 一圈有几格
+          boolean leakDetection // 是否开启内存泄露检测
+          ) {
+
+      // 一些参数校验
+      if (threadFactory == null) {
+          throw new NullPointerException("threadFactory");
+      }
+      if (unit == null) {
+          throw new NullPointerException("unit");
+      }
+      if (tickDuration <= 0) {
+          throw new IllegalArgumentException("tickDuration must be greater than 0: " + tickDuration);
+      }
+      if (ticksPerWheel <= 0) {
+          throw new IllegalArgumentException("ticksPerWheel must be greater than 0: " + ticksPerWheel);
+      }
+
+      // 创建时间轮基本的数据结构，一个数组。长度为不小于ticksPerWheel的最小2的n次方
+      wheel = createWheel(ticksPerWheel);
+      // 这是一个标示符，用来快速计算任务应该呆的格子。
+      // 我们知道，给定一个deadline的定时任务，其应该呆的格子=deadline%wheel.length.但是%操作是个相对耗时的操作，所以使用一种变通的位运算代替：
+      // 因为一圈的长度为2的n次方，mask = 2^n-1后低位将全部是1，然后deadline&mast == deadline%wheel.length
+      // java中的HashMap也是使用这种处理方法
+      mask = wheel.length - 1;
+
+      // 转换成纳秒处理
+      this.tickDuration = unit.toNanos(tickDuration);
+
+      // 校验是否存在溢出。即指针转动的时间间隔不能太长而导致tickDuration*wheel.length>Long.MAX_VALUE
+      if (this.tickDuration >= Long.MAX_VALUE / wheel.length) {
+          throw new IllegalArgumentException(String.format(
+                  "tickDuration: %d (expected: 0 < tickDuration in nanos < %d",
+                  tickDuration, Long.MAX_VALUE / wheel.length));
+      }
+      // 创建worker线程
+      workerThread = threadFactory.newThread(worker);
+
+// 这里默认是启动内存泄露检测：当HashedWheelTimer实例超过当前cpu可用核数*4的时候，将发出警告
+      leak = leakDetection || !workerThread.isDaemon() ? leakDetector.open(this) : null;
+  }
+```
+
+再来看下`createWheel`的代码：
+
+```
+  private static HashedWheelBucket[] createWheel(int ticksPerWheel) {
+      // 一些参数校验
+if (ticksPerWheel <= 0) {
+          throw new IllegalArgumentException(
+                  "ticksPerWheel must be greater than 0: " + ticksPerWheel);
+      }
+      if (ticksPerWheel > 1073741824) {
+          throw new IllegalArgumentException(
+                  "ticksPerWheel may not be greater than 2^30: " + ticksPerWheel);
+      }
+
+// 初始化ticksPerWheel的值为不小于ticksPerWheel的最小2的n次方
+      ticksPerWheel = normalizeTicksPerWheel(ticksPerWheel);
+// 初始化wheel数组
+      HashedWheelBucket[] wheel = new HashedWheelBucket[ticksPerWheel];
+      for (int i = 0; i < wheel.length; i ++) {
+          wheel[i] = new HashedWheelBucket();
+      }
+      return wheel;
+  }
+```
+
+`normalizeTicksPerWheel()`的代码：
+
+```
+// 初始化ticksPerWheel的值为不小于ticksPerWheel的最小2的n次方
+   private static int normalizeTicksPerWheel(int ticksPerWheel) {
+       int normalizedTicksPerWheel = 1;
+       while (normalizedTicksPerWheel < ticksPerWheel) {
+           normalizedTicksPerWheel <<= 1;
+       }
+       return normalizedTicksPerWheel;
+   }
+```
+
+这里其实不建议使用这种方式，因为当ticksPerWheel的值很大的时候，这个方法会循环很多次，方法执行时间不稳定，效率也不够。推荐使用java8 HashMap的做法：
+
+```
+private int normalizeTicksPerWheel(int ticksPerWheel) {
+    // 这里参考java8 hashmap的算法，使推算的过程固定
+    int n = ticksPerWheel - 1;
+    n |= n >>> 1;
+    n |= n >>> 2;
+    n |= n >>> 4;
+    n |= n >>> 8;
+    n |= n >>> 16;
+    // 这里1073741824 = 2^30,防止溢出
+    return (n < 0) ? 1 : (n >= 1073741824) ? 1073741824 : n + 1;
+}
+```
+
+### HashedWheelTimer源码之启动、停止与添加任务
+
+`start()`启动时间轮的方法：
+
+```
+// 启动时间轮。这个方法其实不需要显示的主动调用，因为在添加定时任务（newTimeout()方法）的时候会自动调用此方法。
+// 这个是合理的设计，因为如果时间轮里根本没有定时任务，启动时间轮也是空耗资源
+public void start() {
+    // 判断当前时间轮的状态，如果是初始化，则启动worker线程，启动整个时间轮；如果已经启动则略过；如果是已经停止，则报错
+    // 这里是一个Lock Free的设计。因为可能有多个线程调用启动方法，这里使用AtomicIntegerFieldUpdater原子的更新时间轮的状态
+    switch (WORKER_STATE_UPDATER.get(this)) {
+        case WORKER_STATE_INIT:
+            if (WORKER_STATE_UPDATER.compareAndSet(this, WORKER_STATE_INIT, WORKER_STATE_STARTED)) {
+                workerThread.start();
+            }
+            break;
+        case WORKER_STATE_STARTED:
+            break;
+        case WORKER_STATE_SHUTDOWN:
+            throw new IllegalStateException("cannot be started once stopped");
+        default:
+            throw new Error("Invalid WorkerState");
+    }
+
+    // 等待worker线程初始化时间轮的启动时间
+    while (startTime == 0) {
+        try {
+            startTimeInitialized.await();
+        } catch (InterruptedException ignore) {
+            // Ignore - it will be ready very soon.
+        }
+    }
+}
+```
+
+AtomicIntegerFieldUpdater是JUC里面的类，原理是利用反射进行原子操作。有比AtomicInteger更好的性能和更低得内存占用。跟踪这个类的github 提交记录，可以看到更详细的[原因](http://static.iocoder.cn/894e662550de6d9f418324da5b2469d5)
+
+`stop()`停止时间轮的方法：
+
+```
+public Set<Timeout> stop() {
+    // worker线程不能停止时间轮，也就是加入的定时任务，不能调用这个方法。
+    // 不然会有恶意的定时任务调用这个方法而造成大量定时任务失效
+    if (Thread.currentThread() == workerThread) {
+        throw new IllegalStateException(
+                HashedWheelTimer.class.getSimpleName() +
+                        ".stop() cannot be called from " +
+                        TimerTask.class.getSimpleName());
+    }
+    // 尝试CAS替换当前状态为“停止：2”。如果失败，则当前时间轮的状态只能是“初始化：0”或者“停止：2”。直接将当前状态设置为“停止：2“
+    if (!WORKER_STATE_UPDATER.compareAndSet(this, WORKER_STATE_STARTED, WORKER_STATE_SHUTDOWN)) {
+        // workerState can be 0 or 2 at this moment - let it always be 2.
+        WORKER_STATE_UPDATER.set(this, WORKER_STATE_SHUTDOWN);
+
+        if (leak != null) {
+            leak.close();
+        }
+
+        return Collections.emptySet();
+    }
+
+    // 终端worker线程
+    boolean interrupted = false;
+    while (workerThread.isAlive()) {
+        workerThread.interrupt();
+        try {
+            workerThread.join(100);
+        } catch (InterruptedException ignored) {
+            interrupted = true;
+        }
+    }
+
+    // 从中断中恢复
+    if (interrupted) {
+        Thread.currentThread().interrupt();
+    }
+
+    if (leak != null) {
+        leak.close();
+    }
+    // 返回未处理的任务
+    return worker.unprocessedTimeouts();
+}
+```
+
+`newTimeout()`添加定时任务：
+
+```
+public Timeout newTimeout(TimerTask task, long delay, TimeUnit unit) {
+    // 参数校验
+    if (task == null) {
+        throw new NullPointerException("task");
+    }
+    if (unit == null) {
+        throw new NullPointerException("unit");
+    }
+    // 如果时间轮没有启动，则启动
+    start();
+
+    // Add the timeout to the timeout queue which will be processed on the next tick.
+    // During processing all the queued HashedWheelTimeouts will be added to the correct HashedWheelBucket.
+    // 计算任务的deadline
+    long deadline = System.nanoTime() + unit.toNanos(delay) - startTime;
+    // 这里定时任务不是直接加到对应的格子中，而是先加入到一个队列里，然后等到下一个tick的时候，会从队列里取出最多100000个任务加入到指定的格子中
+    HashedWheelTimeout timeout = new HashedWheelTimeout(this, task, deadline);
+    timeouts.add(timeout);
+    return timeout;
+}
+```
+
+这里使用的Queue不是普通java自带的Queue的实现，而是使用[JCTool](http://static.iocoder.cn/752997222ee0591298f89db49439b894)–一个高性能的的并发Queue实现包。
+
+### HashedWheelTimer源码之HashedWheelTimeout
+
+`HashedWheelTimeout`是一个定时任务的内部包装类，双向链表结构。会保存定时任务到期执行的任务、deadline、round等信息。
+
+```
+private static final class HashedWheelTimeout implements Timeout {
+
+    // 定义定时任务的3个状态：初始化、取消、过期
+    private static final int ST_INIT = 0;
+    private static final int ST_CANCELLED = 1;
+    private static final int ST_EXPIRED = 2;
+    // 用来CAS方式更新定时任务状态
+    private static final AtomicIntegerFieldUpdater<HashedWheelTimeout> STATE_UPDATER;
+
+    static {
+        AtomicIntegerFieldUpdater<HashedWheelTimeout> updater =
+                PlatformDependent.newAtomicIntegerFieldUpdater(HashedWheelTimeout.class, "state");
+        if (updater == null) {
+            updater = AtomicIntegerFieldUpdater.newUpdater(HashedWheelTimeout.class, "state");
+        }
+        STATE_UPDATER = updater;
+    }
+
+    // 时间轮引用
+    private final HashedWheelTimer timer;
+    // 具体到期需要执行的任务
+    private final TimerTask task;
+    private final long deadline;
+
+    @SuppressWarnings({"unused", "FieldMayBeFinal", "RedundantFieldInitialization" })
+    private volatile int state = ST_INIT;
+
+    // 离任务执行的轮数，当将次任务加入到格子中是计算该值，每过一轮，该值减一。
+    long remainingRounds;
+
+    // 双向链表结构，由于只有worker线程会访问，这里不需要synchronization / volatile
+    HashedWheelTimeout next;
+    HashedWheelTimeout prev;
+
+    // 定时任务所在的格子
+    HashedWheelBucket bucket;
+
+    HashedWheelTimeout(HashedWheelTimer timer, TimerTask task, long deadline) {
+        this.timer = timer;
+        this.task = task;
+        this.deadline = deadline;
+    }
+
+    @Override
+    public Timer timer() {
+        return timer;
+    }
+
+    @Override
+    public TimerTask task() {
+        return task;
+    }
+
+    @Override
+    public boolean cancel() {
+        // 这里只是修改状态为ST_CANCELLED，会在下次tick时，在格子中移除
+        if (!compareAndSetState(ST_INIT, ST_CANCELLED)) {
+            return false;
+        }
+        // 加入到时间轮的待取消队列，并在每次tick的时候，从相应格子中移除。
+        timer.cancelledTimeouts.add(this);
+        return true;
+    }
+
+    // 从格子中移除自身
+    void remove() {
+        HashedWheelBucket bucket = this.bucket;
+        if (bucket != null) {
+            bucket.remove(this);
+        }
+    }
+
+    public boolean compareAndSetState(int expected, int state) {
+        return STATE_UPDATER.compareAndSet(this, expected, state);
+    }
+
+    public int state() {
+        return state;
+    }
+
+    @Override
+    public boolean isCancelled() {
+        return state() == ST_CANCELLED;
+    }
+
+    @Override
+    public boolean isExpired() {
+        return state() == ST_EXPIRED;
+    }
+
+    // 过期并执行任务
+    public void expire() {
+        if (!compareAndSetState(ST_INIT, ST_EXPIRED)) {
+            return;
+        }
+
+        try {
+            task.run(this);
+        } catch (Throwable t) {
+            if (logger.isWarnEnabled()) {
+                logger.warn("An exception was thrown by " + TimerTask.class.getSimpleName() + '.', t);
+            }
+        }
+    }
+
+    // 略过toString()
+}
+```
+
+### HashedWheelTimer源码之HashedWheelBucket
+
+`HashedWheelBucket`用来存放HashedWheelTimeout，结构类似于LinkedList。提供了`expireTimeouts(long deadline)`方法来过期并执行格子中的定时任务
+
+```
+private static final class HashedWheelBucket {
+    // 指向格子中任务的首尾
+    private HashedWheelTimeout head;
+    private HashedWheelTimeout tail;
+
+    // 基础的链表添加操作
+    public void addTimeout(HashedWheelTimeout timeout) {
+        assert timeout.bucket == null;
+        timeout.bucket = this;
+        if (head == null) {
+            head = tail = timeout;
+        } else {
+            tail.next = timeout;
+            timeout.prev = tail;
+            tail = timeout;
+        }
+    }
+
+    // 过期并执行格子中的到期任务，tick到该格子的时候，worker线程会调用这个方法，根据deadline和remainingRounds判断任务是否过期
+    public void expireTimeouts(long deadline) {
+        HashedWheelTimeout timeout = head;
+
+        // 遍历格子中的所有定时任务
+        while (timeout != null) {
+            boolean remove = false;
+            if (timeout.remainingRounds <= 0) { // 定时任务到期
+                if (timeout.deadline <= deadline) {
+                    timeout.expire();
+                } else {
+                    // 如果round数已经为0，deadline却>当前格子的deadline，说放错格子了，这种情况应该不会出现
+                    throw new IllegalStateException(String.format(
+                            "timeout.deadline (%d) > deadline (%d)", timeout.deadline, deadline));
+                }
+                remove = true;
+            } else if (timeout.isCancelled()) {
+                remove = true;
+            } else { //没有到期，轮数-1
+                timeout.remainingRounds --;
+            }
+            // 先保存next，因为移除后next将被设置为null
+            HashedWheelTimeout next = timeout.next;
+            if (remove) {
+                remove(timeout);
+            }
+            timeout = next;
+        }
+    }
+
+    // 基础的链表移除node操作
+    public void remove(HashedWheelTimeout timeout) {
+        HashedWheelTimeout next = timeout.next;
+        // remove timeout that was either processed or cancelled by updating the linked-list
+        if (timeout.prev != null) {
+            timeout.prev.next = next;
+        }
+        if (timeout.next != null) {
+            timeout.next.prev = timeout.prev;
+        }
+
+        if (timeout == head) {
+            // if timeout is also the tail we need to adjust the entry too
+            if (timeout == tail) {
+                tail = null;
+                head = null;
+            } else {
+                head = next;
+            }
+        } else if (timeout == tail) {
+            // if the timeout is the tail modify the tail to be the prev node.
+            tail = timeout.prev;
+        }
+        // null out prev, next and bucket to allow for GC.
+        timeout.prev = null;
+        timeout.next = null;
+        timeout.bucket = null;
+    }
+
+    /**
+     * Clear this bucket and return all not expired / cancelled {@link Timeout}s.
+     */
+    public void clearTimeouts(Set<Timeout> set) {
+        for (;;) {
+            HashedWheelTimeout timeout = pollTimeout();
+            if (timeout == null) {
+                return;
+            }
+            if (timeout.isExpired() || timeout.isCancelled()) {
+                continue;
+            }
+            set.add(timeout);
+        }
+    }
+
+    // 链表的poll操作
+    private HashedWheelTimeout pollTimeout() {
+        HashedWheelTimeout head = this.head;
+        if (head == null) {
+            return null;
+        }
+        HashedWheelTimeout next = head.next;
+        if (next == null) {
+            tail = this.head =  null;
+        } else {
+            this.head = next;
+            next.prev = null;
+        }
+
+        // null out prev and next to allow for GC.
+        head.next = null;
+        head.prev = null;
+        head.bucket = null;
+        return head;
+    }
+}
+```
+
+### HashedWheelTimer源码之Worker
+
+`Worker`是时间轮的核心线程类。tick的转动，过期任务的处理都是在这个线程中处理的。
+
+```
+private final class Worker implements Runnable {
+    private final Set<Timeout> unprocessedTimeouts = new HashSet<Timeout>();
+
+    private long tick;
+
+    @Override
+    public void run() {
+        // 初始化startTime.只有所有任务的的deadline都是想对于这个时间点
+        startTime = System.nanoTime();
+        // 由于System.nanoTime()可能返回0，甚至负数。并且0是一个标示符，用来判断startTime是否被初始化，所以当startTime=0的时候，重新赋值为1
+        if (startTime == 0) {
+            startTime = 1;
+        }
+
+        // 唤醒阻塞在start()的线程
+        startTimeInitialized.countDown();
+
+        // 只要时间轮的状态为WORKER_STATE_STARTED，就循环的“转动”tick，循环判断响应格子中的到期任务
+        do {
+            // waitForNextTick方法主要是计算下次tick的时间, 然后sleep到下次tick
+            // 返回值就是System.nanoTime() - startTime, 也就是Timer启动后到这次tick, 所过去的时间
+            final long deadline = waitForNextTick();
+            if (deadline > 0) { // 可能溢出或者被中断的时候会返回负数, 所以小于等于0不管
+                // 获取tick对应的格子索引
+                int idx = (int) (tick & mask);
+                // 移除被取消的任务
+                processCancelledTasks();
+                HashedWheelBucket bucket =
+                        wheel[idx];
+                // 从任务队列中取出任务加入到对应的格子中
+                transferTimeoutsToBuckets();
+                // 过期执行格子中的任务
+                bucket.expireTimeouts(deadline);
+                tick++;
+            }
+        } while (WORKER_STATE_UPDATER.get(HashedWheelTimer.this) == WORKER_STATE_STARTED);
+
+        // 这里应该是时间轮停止了，清除所有格子中的任务，并加入到未处理任务列表，以供stop()方法返回
+        for (HashedWheelBucket bucket: wheel) {
+            bucket.clearTimeouts(unprocessedTimeouts);
+        }
+        // 将还没有加入到格子中的待处理定时任务队列中的任务取出，如果是未取消的任务，则加入到未处理任务队列中，以供stop()方法返回
+        for (;;) {
+            HashedWheelTimeout timeout = timeouts.poll();
+            if (timeout == null) {
+                break;
+            }
+            if (!timeout.isCancelled()) {
+                unprocessedTimeouts.add(timeout);
+            }
+        }
+        // 处理取消的任务
+        processCancelledTasks();
+    }
+
+    // 将newTimeout()方法中加入到待处理定时任务队列中的任务加入到指定的格子中
+    private void transferTimeoutsToBuckets() {
+        // 每次tick只处理10w个任务，以免阻塞worker线程
+        for (int i = 0; i < 100000; i++) {
+            HashedWheelTimeout timeout = timeouts.poll();
+            // 如果没有任务了，直接跳出循环
+            if (timeout == null) {
+                break;
+            }
+            // 还没有放入到格子中就取消了，直接略过
+            if (timeout.state() == HashedWheelTimeout.ST_CANCELLED) {
+                continue;
+            }
+
+            // 计算任务需要经过多少个tick
+            long calculated = timeout.deadline / tickDuration;
+            // 计算任务的轮数
+            timeout.remainingRounds = (calculated - tick) / wheel.length;
+
+            //如果任务在timeouts队列里面放久了, 以至于已经过了执行时间, 这个时候就使用当前tick, 也就是放到当前bucket, 此方法调用完后就会被执行.
+            final long ticks = Math.max(calculated, tick); // Ensure we don't schedule for past.
+            int stopIndex = (int) (ticks & mask);
+
+            // 将任务加入到响应的格子中
+            HashedWheelBucket bucket = wheel[stopIndex];
+            bucket.addTimeout(timeout);
+        }
+    }
+
+    // 将取消的任务取出，并从格子中移除
+    private void processCancelledTasks() {
+        for (;;) {
+            HashedWheelTimeout timeout = cancelledTimeouts.poll();
+            if (timeout == null) {
+                // all processed
+                break;
+            }
+            try {
+                timeout.remove();
+            } catch (Throwable t) {
+                if (logger.isWarnEnabled()) {
+                    logger.warn("An exception was thrown while process a cancellation task", t);
+                }
+            }
+        }
+    }
+
+    /**
+     * calculate goal nanoTime from startTime and current tick number,
+     * then wait until that goal has been reached.
+     * @return Long.MIN_VALUE if received a shutdown request,
+     * current time otherwise (with Long.MIN_VALUE changed by +1)
+     */
+    //sleep, 直到下次tick到来, 然后返回该次tick和启动时间之间的时长
+    private long waitForNextTick() {
+        //下次tick的时间点, 用于计算需要sleep的时间
+        long deadline = tickDuration * (tick + 1);
+
+        for (;;) {
+            // 计算需要sleep的时间, 之所以加999999后再除10000000, 是为了保证足够的sleep时间
+            // 例如：当deadline - currentTime=2000002的时候，如果不加999999，则只睡了2ms，
+            // 而2ms其实是未到达deadline这个时间点的，所有为了使上述情况能sleep足够的时间，加上999999后，会多睡1ms
+            final long currentTime = System.nanoTime() - startTime;
+            long sleepTimeMs = (deadline - currentTime + 999999) / 1000000;
+
+            if (sleepTimeMs <= 0) {
+	// 以下为个人理解：（如有错误，欢迎大家指正）
+                // 这里的意思应该是从时间轮启动到现在经过太长的时间(跨度大于292年...)，以至于让long装不下，都溢出了...对于netty的严谨，我服！
+                if (currentTime == Long.MIN_VALUE) {
+                    return -Long.MAX_VALUE;
+                } else {
+                    return currentTime;
+                }
+            }
+
+            // Check if we run on windows, as if thats the case we will need
+            // to round the sleepTime as workaround for a bug that only affect
+            // the JVM if it runs on windows.
+            //
+            // See https://github.com/netty/netty/issues/356
+            if (PlatformDependent.isWindows()) { // 这里是因为windows平台的定时调度最小单位为10ms，如果不是10ms的倍数，可能会引起sleep时间不准确
+                sleepTimeMs = sleepTimeMs / 10 * 10;
+            }
+
+            try {
+                Thread.sleep(sleepTimeMs);
+            } catch (InterruptedException ignored) {
+	// 调用HashedWheelTimer.stop()时优雅退出
+                if (WORKER_STATE_UPDATER.get(HashedWheelTimer.this) == WORKER_STATE_SHUTDOWN) {
+                    return Long.MIN_VALUE;
+                }
+            }
+        }
+    }
+
+    public Set<Timeout> unprocessedTimeouts() {
+        return Collections.unmodifiableSet(unprocessedTimeouts);
+    }
+}
+```
+
+## 总结
+
+通过阅读源码，学到了很多之前不知道的知识点和注意事项。比如：
+
+1. 操作数字型要考虑溢出问题
+2. System.nanoTime(）返回值
+3. Atomic*FieldUpdater类的运用
+4. 一些代码设计方式
+5. 不断优化性能，Lock Less代替Lock；Lock Free代替Lock Less
+6. JCTool高性能队列的使用
\ No newline at end of file
diff --git a/netty/63-Netty 源码解析-Util 之 MpscUnboundedArrayQueue.md b/netty/63-Netty 源码解析-Util 之 MpscUnboundedArrayQueue.md
new file mode 100644
index 0000000..1d152ed
--- /dev/null
+++ b/netty/63-Netty 源码解析-Util 之 MpscUnboundedArrayQueue.md	
@@ -0,0 +1,824 @@
+# 精尽 Netty 源码解析 —— Util 之 MpscUnboundedArrayQueue
+
+笔者先把 Netty 主要的内容写完，所以关于 MpscUnboundedArrayQueue 的分享，先放在后续的计划里。
+
+> 老艿艿：其实是因为，自己想去研究下 Service Mesh ，所以先简单收个小尾。
+
+当然，良心如我，还是为对这块感兴趣的胖友，先准备好了一篇不错的文章：
+
+- HMILYYLIMH [《原理剖析（第 012 篇）Netty之无锁队列MpscUnboundedArrayQueue原理分析》](https://www.jianshu.com/p/119a03332619)
+
+为避免可能 [《原理剖析（第 012 篇）Netty之无锁队列MpscUnboundedArrayQueue原理分析》](https://www.jianshu.com/p/119a03332619) 被作者删除，笔者这里先复制一份作为备份。
+
+# 666. 备份
+
+## 一、大致介绍
+
+```
+1、了解过netty原理的童鞋，其实应该知道工作线程组的每个子线程都维护了一个任务队列；
+2、细心的童鞋会发现netty的队列是重写了队列的实现方法，覆盖了父类中的LinkedBlockingQueue队列，但是如今却换成了JCTools的一些并发队列，因为JCTools是一款对jdk并发数据结构进行增强的并发工具；
+3、那么问题就来了，现在的netty要用新的队列呢？难道是新的队列确实很高效么？
+4、那么本章节就来和大家分享分析一下Netty新采用的队列之一MpscUnboundedArrayQueue，分析Netty的源码版本为：netty-netty-4.1.22.Final；
+```
+
+## 二、回顾预习
+
+### 2.1 构造队列
+
+```
+1、源码：
+    // NioEventLoop.java
+    @Override
+    protected Queue<Runnable> newTaskQueue(int maxPendingTasks) {
+        // This event loop never calls takeTask()
+        // 由于默认是没有配置io.netty.eventLoop.maxPendingTasks属性值的，所以maxPendingTasks默认值为Integer.MAX_VALUE；
+        // 那么最后配备的任务队列的大小也就自然使用无参构造队列方法
+        return maxPendingTasks == Integer.MAX_VALUE ? PlatformDependent.<Runnable>newMpscQueue()
+                                                    : PlatformDependent.<Runnable>newMpscQueue(maxPendingTasks);
+    }
+
+    // PlatformDependent.java
+    /**
+     * Create a new {@link Queue} which is safe to use for multiple producers (different threads) and a single
+     * consumer (one thread!).
+     * @return A MPSC queue which may be unbounded.
+     */
+    public static <T> Queue<T> newMpscQueue() {
+        return Mpsc.newMpscQueue();
+    }
+
+    // Mpsc.java
+    static <T> Queue<T> newMpscQueue() {
+        return USE_MPSC_CHUNKED_ARRAY_QUEUE ? new MpscUnboundedArrayQueue<T>(MPSC_CHUNK_SIZE)
+                                            : new MpscUnboundedAtomicArrayQueue<T>(MPSC_CHUNK_SIZE);
+    }
+
+2、通过源码回顾，想必大家已经隐约回忆起之前分析过这段代码，我们在构建工作线程管理组的时候，还需要实例化子线程数组children[]，所以自然就会碰到这段代码；
+
+3、这段代码其实就是为了实现一个无锁方式的线程安全队列，总之一句话，效率相当相当的高；
+```
+
+### 2.2 何为JCTools？
+
+```
+1、JCTools是服务虚拟机并发开发的工具，提供一些JDK没有的并发数据结构辅助开发。
+
+2、是一个聚合四种 SPSC/MPSC/SPMC/MPMC 数据变量的并发队列：
+    • SPSC：单个生产者对单个消费者（无等待、有界和无界都有实现）
+    • MPSC：多个生产者对单个消费者（无锁、有界和无界都有实现）
+    • SPMC：单生产者对多个消费者（无锁 有界）
+    • MPMC：多生产者对多个消费者（无锁、有界）
+
+3、SPSC/MPSC 提供了一个在性能，分配和分配规则之间的平衡的关联数组队列；
+```
+
+### 2.3 常用重要的成员属性及方法
+
+```
+1、private volatile long producerLimit;
+   // 数据链表所分配或者扩展后的容量值
+
+2、protected long producerIndex;
+   // 生产者指针，每添加一个数据，指针加2
+
+3、protected long consumerIndex;
+   // 消费者指针，每移除一个数据，指针加2
+
+4、private static final int RETRY = 1; // 重新尝试，有可能是因为并发原因，CAS操作指针失败，所以需要重新尝试添加动作
+   private static final int QUEUE_FULL = 2; // 队列已满，直接返回false操作
+   private static final int QUEUE_RESIZE = 3; // 需要扩容处理，扩容的后的容量值producerLimit一般都是mask的N倍
+   // 添加数据时，根据offerSlowPath返回的状态值来做各种处理
+
+5、protected E[] producerBuffer;
+   // 数据缓冲区，需要添加的数据放在此
+
+6、protected long producerMask;
+   // 生产者扩充容量值，一般producerMask与consumerMask是一致的，而且需要扩容的数值一般和此值一样
+
+7、public boolean offer(final E e)
+   // 添加元素
+
+8、public E poll()
+   // 移除元素
+```
+
+### 2.4 数据结构
+
+```
+1、如果chunkSize初始化大小为4，则最后显示的数据结构如下：
+   E1，E2，。。。，EN：表示具体的元素；
+   NBP：表示下一个缓冲区的指针，我采用的是英文的缩写( Next Buffer Pointer)；
+
+   而且你看着我是拆分开写的，其实每一个NBP指向的就是下面一组缓冲区；
+   Buffer1中的NBP其实就是Buffer2的指针引用；
+   Buffer2中的NBP其实就是Buffer3的指针引用；
+   以此类推。。。
++------+------+------+------+------+
+|      |      |      |      |      |
+|  E1  |  E2  |  E3  | JUMP |  NBP |    Buffer1
+|      |      |      |      |      |
++------+------+------+------+------+
+
++------+------+------+------+------+
+|      |      |      |      |      |
+|  E5  |  E6  | JUMP |  E4  |  NBP |    Buffer2
+|      |      |      |      |      |
++------+------+------+------+------+
+
++------+------+------+------+------+
+|      |      |      |      |      |
+|  E9  | JUMP |  E7  |  E8  |  NBP |    Buffer3
+|      |      |      |      |      |
++------+------+------+------+------+
+
++------+------+------+------+------+
+|      |      |      |      |      |
+| JUMP |  E10 |  E11 |  E12 |  NBP |    Buffer4
+|      |      |      |      |      |
++------+------+------+------+------+
+
++------+------+------+------+------+
+|      |      |      |      |      |
+|  E13 |  E14 |  E15 | JUMP |  NBP |    Buffer5
+|      |      |      |      |      |
++------+------+------+------+------+
+
+2、这个数据结构和我们通常所认知的链表是不是有点异样，其实大体还是雷同的，这种数据结构其实也是指针的单项指引罢了；
+```
+
+## 三、源码分析MpscUnboundedArrayQueue
+
+### 3.1、MpscUnboundedArrayQueue(int)
+
+```
+1、源码：
+    // MpscUnboundedArrayQueue.java
+    public MpscUnboundedArrayQueue(int chunkSize)
+    {
+        super(chunkSize); // 调用父类的含参构造方法
+    }
+
+    // BaseMpscLinkedArrayQueue.java
+    /**
+     * @param initialCapacity the queue initial capacity. If chunk size is fixed this will be the chunk size.
+     *                        Must be 2 or more.
+     */
+    public BaseMpscLinkedArrayQueue(final int initialCapacity)
+    {
+        // 校验队列容量值，大小必须不小于2
+        RangeUtil.checkGreaterThanOrEqual(initialCapacity, 2, "initialCapacity");
+
+        // 通过传入的参数通过Pow2算法获取大于initialCapacity最近的一个2的n次方的值
+        int p2capacity = Pow2.roundToPowerOfTwo(initialCapacity);
+        // leave lower bit of mask clear
+        long mask = (p2capacity - 1) << 1; // 通过p2capacity计算获得mask值，该值后续将用作扩容的值
+        // need extra element to point at next array
+        E[] buffer = allocate(p2capacity + 1); // 默认分配一个 p2capacity + 1 大小的数据缓冲区
+        producerBuffer = buffer;
+        producerMask = mask;
+        consumerBuffer = buffer;
+        consumerMask = mask;
+        // 同时用mask作为初始化队列的Limit值，当生产者指针producerIndex超过该Limit值时就需要做扩容处理
+        soProducerLimit(mask); // we know it's all empty to start with
+    }
+
+    // RangeUtil.java
+    public static int checkGreaterThanOrEqual(int n, int expected, String name)
+    {
+        // 要求队列的容量值必须不小于 expected 值，这个 expected 值由上层决定，但是对 MpscUnboundedArrayQueue 而言，expected 为 2；
+        // 那么就是说 MpscUnboundedArrayQueue 的值必须不小于 2；
+        if (n < expected)
+        {
+            throw new IllegalArgumentException(name + ": " + n + " (expected: >= " + expected + ')');
+        }
+
+        return n;
+    }
+
+2、通过调用父类的构造方法，分配了一个数据缓冲区，初始化容量大小，并且容量值不小于2，差不多就这样队列的实例化操作已经完成了；
+```
+
+### 3.2、offer(E)
+
+```
+1、源码：
+    // BaseMpscLinkedArrayQueue.java
+    @Override
+    public boolean offer(final E e)
+    {
+        if (null == e) // 待添加的元素e不允许为空，否则抛空指针异常
+        {
+            throw new NullPointerException();
+        }
+
+        long mask;
+        E[] buffer;
+        long pIndex;
+
+        while (true)
+        {
+            long producerLimit = lvProducerLimit(); // 获取当前数据Limit的阈值
+            pIndex = lvProducerIndex(); // 获取当前生产者指针位置
+            // lower bit is indicative of resize, if we see it we spin until it's cleared
+            if ((pIndex & 1) == 1)
+            {
+                continue;
+            }
+            // pIndex is even (lower bit is 0) -> actual index is (pIndex >> 1)
+
+            // mask/buffer may get changed by resizing -> only use for array access after successful CAS.
+            mask = this.producerMask;
+            buffer = this.producerBuffer;
+            // a successful CAS ties the ordering, lv(pIndex) - [mask/buffer] -> cas(pIndex)
+
+            // assumption behind this optimization is that queue is almost always empty or near empty
+            if (producerLimit <= pIndex) // 当阈值小于等于生产者指针位置时，则需要扩容，否则直接通过CAS操作对pIndex做加2处理
+            {
+                // 通过offerSlowPath返回状态值，来查看怎么来处理这个待添加的元素
+                int result = offerSlowPath(mask, pIndex, producerLimit);
+                switch (result)
+                {
+                    case CONTINUE_TO_P_INDEX_CAS:
+                        break;
+                    case RETRY: // 可能由于并发原因导致CAS失败，那么则再次重新尝试添加元素
+                        continue;
+                    case QUEUE_FULL: // 队列已满，直接返回false操作
+                        return false;
+                    case QUEUE_RESIZE: // 队列需要扩容操作
+                        resize(mask, buffer, pIndex, e); // 对队列进行直接扩容操作
+                        return true;
+                }
+            }
+
+            // 能走到这里，则说明当前的生产者指针位置还没有超过阈值，因此直接通过CAS操作做加2处理
+            if (casProducerIndex(pIndex, pIndex + 2))
+            {
+                break;
+            }
+        }
+        // INDEX visible before ELEMENT
+        // 获取计算需要添加元素的位置
+        final long offset = modifiedCalcElementOffset(pIndex, mask);
+        // 在buffer的offset位置添加e元素
+        soElement(buffer, offset, e); // release element e
+        return true;
+    }
+
+    // BaseMpscLinkedArrayQueueProducerFields.java
+    @Override
+    public final long lvProducerIndex()
+    {
+        // 通过Unsafe对象调用native方法，获取生产者指针位置
+        return UNSAFE.getLongVolatile(this, P_INDEX_OFFSET);
+    }
+
+    // UnsafeRefArrayAccess.java
+    /**
+     * An ordered store(store + StoreStore barrier) of an element to a given offset
+     *
+     * @param buffer this.buffer
+     * @param offset computed via {@link UnsafeRefArrayAccess#calcElementOffset}
+     * @param e      an orderly kitty
+     */
+    public static <E> void soElement(E[] buffer, long offset, E e)
+    {
+        // 通过Unsafe对象调用native方法，将元素e设置到buffer缓冲区的offset位置
+        UNSAFE.putOrderedObject(buffer, offset, e);
+    }
+
+2、此方法为添加新的元素对象，当pIndex指针超过阈值producerLimit时则扩容处理，否则直接通过CAS操作添加记录pIndex位置；
+```
+
+### 3.3、offerSlowPath(long, long, long)
+
+```
+1、源码：
+    // BaseMpscLinkedArrayQueue.java
+    /**
+     * We do not inline resize into this method because we do not resize on fill.
+     */
+    private int offerSlowPath(long mask, long pIndex, long producerLimit)
+    {
+        // 获取消费者指针
+        final long cIndex = lvConsumerIndex();
+        // 获取当前缓冲区的容量值，getCurrentBufferCapacity方法由子类MpscUnboundedArrayQueue实现，默认返回mask值
+        long bufferCapacity = getCurrentBufferCapacity(mask);
+
+        // 如果消费指针加上容量值如果超过了生产指针，那么则会尝试进行扩容处理
+        if (cIndex + bufferCapacity > pIndex)
+        {
+            if (!casProducerLimit(producerLimit, cIndex + bufferCapacity))
+            {
+                // retry from top
+                return RETRY;
+            }
+            else
+            {
+                // continue to pIndex CAS
+                return CONTINUE_TO_P_INDEX_CAS;
+            }
+        }
+        // full and cannot grow 子类MpscUnboundedArrayQueue默认返回Integer.MAX_VALUE值，所以不会进入此分支
+        else if (availableInQueue(pIndex, cIndex) <= 0)
+        {
+            // offer should return false;
+            return QUEUE_FULL;
+        }
+        // grab index for resize -> set lower bit 尝试扩容队列
+        else if (casProducerIndex(pIndex, pIndex + 1))
+        {
+            // trigger a resize
+            return QUEUE_RESIZE;
+        }
+        else
+        {
+            // failed resize attempt, retry from top
+            return RETRY;
+        }
+    }
+
+    // MpscUnboundedArrayQueue.java
+    @Override
+    protected long getCurrentBufferCapacity(long mask)
+    {
+        // 获取当前缓冲区的容量值
+        return mask;
+    }
+
+    // BaseMpscLinkedArrayQueue.java
+    final boolean casProducerLimit(long expect, long newValue)
+    {
+        // 通过CAS尝试对阈值进行修改扩容处理
+        return UNSAFE.compareAndSwapLong(this, P_LIMIT_OFFSET, expect, newValue);
+    }
+
+    // MpscUnboundedArrayQueue.java
+    @Override
+    protected long availableInQueue(long pIndex, long cIndex)
+    {
+        // 获取可用容量值
+        return Integer.MAX_VALUE;
+    }
+
+    // BaseMpscLinkedArrayQueueProducerFields.java
+    final boolean casProducerIndex(long expect, long newValue)
+    {
+        // 通过CAS操作更新生产者指针
+        return UNSAFE.compareAndSwapLong(this, P_INDEX_OFFSET, expect, newValue);
+    }
+
+2、该方法主要通过一系列的if...else判断，并结合子类MpscUnboundedArrayQueue的一些重写方法来判断针对该新添加的元素要做何种状态处理；
+```
+
+### 3.4、resize(long, E[], long, E)
+
+```
+1、源码：
+    // BaseMpscLinkedArrayQueue.java
+    private void resize(long oldMask, E[] oldBuffer, long pIndex, E e)
+    {
+        // 获取oldBuffer的长度值
+        int newBufferLength = getNextBufferSize(oldBuffer);
+        // 重新创建新的缓冲区
+        final E[] newBuffer = allocate(newBufferLength);
+
+        producerBuffer = newBuffer; // 将新创建的缓冲区赋值到生产者缓冲区对象上
+        final int newMask = (newBufferLength - 2) << 1;
+        producerMask = newMask;
+
+        // 根据oldMask获取偏移位置值
+        final long offsetInOld = modifiedCalcElementOffset(pIndex, oldMask);
+        // 根据newMask获取偏移位置值
+        final long offsetInNew = modifiedCalcElementOffset(pIndex, newMask);
+
+        // 将元素e设置到新的缓冲区newBuffer的offsetInNew位置处
+        soElement(newBuffer, offsetInNew, e);// element in new array
+
+        // 通过nextArrayOffset(oldMask)计算新的缓冲区将要放置旧的缓冲区的哪个位置
+        // 将新的缓冲区newBuffer设置到旧的缓冲区oldBuffer的nextArrayOffset(oldMask)位置处
+        // 主要是将oldBuffer中最后一个元素的位置指向新的缓冲区newBuffer
+        // 这样就构成了一个单向链表指向的关系
+        soElement(oldBuffer, nextArrayOffset(oldMask), newBuffer);// buffer linked
+
+        // ASSERT code
+        final long cIndex = lvConsumerIndex();
+        final long availableInQueue = availableInQueue(pIndex, cIndex);
+        RangeUtil.checkPositive(availableInQueue, "availableInQueue");
+
+        // Invalidate racing CASs
+        // We never set the limit beyond the bounds of a buffer
+        // 重新扩容阈值，因为availableInQueue反正都是Integer.MAX_VALUE值，所以自然就取mask值啦
+        // 因此针对MpscUnboundedArrayQueue来说，扩容的值其实就是mask的值的大小
+        soProducerLimit(pIndex + Math.min(newMask, availableInQueue));
+
+        // make resize visible to the other producers
+        // 设置生产者指针加2处理
+        soProducerIndex(pIndex + 2);
+
+        // INDEX visible before ELEMENT, consistent with consumer expectation
+
+        // make resize visible to consumer
+        // 用一个空对象来衔接新老缓冲区，凡是在缓冲区中碰到JUMP对象的话，那么就得琢磨着准备着获取下一个缓冲区的数据元素了
+        soElement(oldBuffer, offsetInOld, JUMP);
+    }
+
+    // MpscUnboundedArrayQueue.java
+    @Override
+    protected int getNextBufferSize(E[] buffer)
+    {
+        // 获取buffer缓冲区的长度
+        return length(buffer);
+    }
+
+    // LinkedArrayQueueUtil.java
+    static int length(Object[] buf)
+    {
+        // 直接通过length属性来获取数组的长度
+        return buf.length;
+    }
+
+    // CircularArrayOffsetCalculator.java
+    @SuppressWarnings("unchecked")
+    public static <E> E[] allocate(int capacity)
+    {
+        // 根据容量值创建数组
+        return (E[]) new Object[capacity];
+    }
+
+2、该方法主要完成新的元素的放置，同时也完成了扩容操作，采用单向链表指针关系，将原缓冲区和新创建的缓冲区衔接起来；
+```
+
+### 3.5、poll()
+
+```
+1、源码：
+    // BaseMpscLinkedArrayQueue.java
+    /**
+     * {@inheritDoc}
+     * <p>
+     * This implementation is correct for single consumer thread use only.
+     */
+    @SuppressWarnings("unchecked")
+    @Override
+    public E poll()
+    {
+        final E[] buffer = consumerBuffer; // 获取缓冲区的数据
+        final long index = consumerIndex;
+        final long mask = consumerMask;
+
+        // 根据消费指针与mask来获取当前需要从哪个位置开始来移除元素
+        final long offset = modifiedCalcElementOffset(index, mask);
+        // 从buffer缓冲区的offset位置获取元素内容
+        Object e = lvElement(buffer, offset);// LoadLoad
+        if (e == null) // 如果元素为null的话
+        {
+            // 则再探讨看看消费指针是不是和生产指针是不是相同
+            if (index != lvProducerIndex())
+            {
+                // poll() == null iff queue is empty, null element is not strong enough indicator, so we must
+                // check the producer index. If the queue is indeed not empty we spin until element is
+                // visible.
+                // 若不相同的话，则先尝试从buffer缓冲区的offset位置获取元素先，若获取元素为null则结束while处理
+                do
+                {
+                    e = lvElement(buffer, offset);
+                }
+                while (e == null);
+            }
+            // 说明消费指针是不是和生产指针是相等的，那么则缓冲区的数据已经被消费完了，直接返回null即可
+            else
+            {
+                return null;
+            }
+        }
+
+        // 如果元素为JUMP空对象的话，那么意味着我们就得获取下一缓冲区进行读取数据了
+        if (e == JUMP)
+        {
+            //
+            final E[] nextBuffer = getNextBuffer(buffer, mask);
+            //
+            return newBufferPoll(nextBuffer, index);
+        }
+
+        // 能执行到这里，说明需要移除的元素既不是空的，也不是JUMP空对象，那么则就按照正常处理置空即可
+        // 移除元素时，则将buffer缓冲区的offset位置的元素置为空即可
+        soElement(buffer, offset, null); // release element null
+        // 同时也通过CAS操作增加消费指针的关系，加2操作
+        soConsumerIndex(index + 2); // release cIndex
+        return (E) e;
+    }
+
+    // BaseMpscLinkedArrayQueueProducerFields.java
+    @Override
+    public final long lvProducerIndex()
+    {
+        // 通过Unsafe对象调用native方法，获取当前生产者指针值
+        return UNSAFE.getLongVolatile(this, P_INDEX_OFFSET);
+    }
+
+    // UnsafeRefArrayAccess.java
+    /**
+     * A volatile load (load + LoadLoad barrier) of an element from a given offset.
+     *
+     * @param buffer this.buffer
+     * @param offset computed via {@link UnsafeRefArrayAccess#calcElementOffset(long)}
+     * @return the element at the offset
+     */
+    @SuppressWarnings("unchecked")
+    public static <E> E lvElement(E[] buffer, long offset)
+    {
+        // 通过Unsafe对象调用native方法，获取buffer缓冲区offset位置的元素
+        return (E) UNSAFE.getObjectVolatile(buffer, offset);
+    }
+
+    // BaseMpscLinkedArrayQueue.java
+    @SuppressWarnings("unchecked")
+    private E[] getNextBuffer(final E[] buffer, final long mask)
+    {
+        // 获取下一个缓冲区的偏移位置值
+        final long offset = nextArrayOffset(mask);
+        // 从buffer缓冲区的offset位置获取下一个缓冲区数组
+        final E[] nextBuffer = (E[]) lvElement(buffer, offset);
+        // 获取出来后，同时将buffer缓冲区的offset位置置为空，代表指针已经被取出，原来位置没用了，清空即可
+        soElement(buffer, offset, null);
+        return nextBuffer;
+    }
+
+    // BaseMpscLinkedArrayQueue.java
+    private E newBufferPoll(E[] nextBuffer, long index)
+    {
+        // 从下一个新的缓冲区中找到需要移除数据的指针位置
+        final long offset = newBufferAndOffset(nextBuffer, index);
+        // 从newBuffer新的缓冲区中offset位置取出元素
+        final E n = lvElement(nextBuffer, offset);// LoadLoad
+        if (n == null) // 若取出的元素为空，则直接抛出异常
+        {
+            throw new IllegalStateException("new buffer must have at least one element");
+        }
+        // 如果取出的元素不为空，那么先将这个元素原先的位置内容先清空掉
+        soElement(nextBuffer, offset, null);// StoreStore
+        // 然后通过Unsafe对象调用native方法，修改消费指针的数值偏移加2处理
+        soConsumerIndex(index + 2);
+        return n;
+    }
+
+2、该方法主要阐述了该队列是如何的移除数据的；取出的数据如果为JUMP空对象的话，那么则准备从下一个缓冲区获取数据元素，否则还是从当前的缓冲区对象中移除元素，并且更新消费指针；
+```
+
+### 3.6、size()
+
+```
+1、源码：
+    // BaseMpscLinkedArrayQueue.java
+    @Override
+    public final int size()
+    {
+        // NOTE: because indices are on even numbers we cannot use the size util.
+
+        /*
+         * It is possible for a thread to be interrupted or reschedule between the read of the producer and
+         * consumer indices, therefore protection is required to ensure size is within valid range. In the
+         * event of concurrent polls/offers to this method the size is OVER estimated as we read consumer
+         * index BEFORE the producer index.
+         */
+        long after = lvConsumerIndex(); // 获取消费指针
+        long size;
+        while (true) // 为了防止在获取大小的时候指针发生变化，那么则死循环自旋方式获取大小数值
+        {
+            final long before = after;
+            final long currentProducerIndex = lvProducerIndex(); // 获取生产者指针
+            after = lvConsumerIndex(); // 获取消费指针
+
+            // 如果后获取的消费指针after和之前获取的消费指针before相等的话，那么说明此刻还没有指针变化
+            if (before == after)
+            {
+                // 那么则直接通过生产指针直接减去消费指针，然后向偏移一位，即除以2，得出最后size大小
+                size = ((currentProducerIndex - after) >> 1);
+
+                // 计算完了之后则直接break中断处理
+                break;
+            }
+
+            // 若消费指针前后不一致，那么可以说是由于并发原因导致了指针发生了变化；
+            // 那么则进行下一次循环继续获取最新的指针值再次进行判断
+        }
+        // Long overflow is impossible, so size is always positive. Integer overflow is possible for the unbounded
+        // indexed queues.
+        if (size > Integer.MAX_VALUE)
+        {
+            return Integer.MAX_VALUE;
+        }
+        else
+        {
+            return (int) size;
+        }
+    }
+
+2、获取缓冲区数据大小其实很简单，就是拿着生产指针减去消费指针，但是为了防止并发操作计算错，才用了死循环的方式计算zise值；
+```
+
+### 3.7、isEmpty()
+
+```
+1、源码：
+    // BaseMpscLinkedArrayQueue.java
+    @Override
+    public final boolean isEmpty()
+    {
+        // Order matters!
+        // Loading consumer before producer allows for producer increments after consumer index is read.
+        // This ensures this method is conservative in it's estimate. Note that as this is an MPMC there is
+        // nothing we can do to make this an exact method.
+        // 这个就简单了，直接判断消费指针和生产指针是不是相等就知道了
+        return (this.lvConsumerIndex() == this.lvProducerIndex());
+    }
+
+2、通过前面我们已经知道了，添加数据的话生产指针在不停的累加操作，而做移除数据的时候消费指针也在不停的累加操作；
+
+3、那么这种指针总会有一天会碰面的吧，碰面的那个时候则是数据已经空空如也的时刻；
+```
+
+## 四、性能测试
+
+```
+1、测试Demo：
+/**
+ * 比较队列的消耗情况。
+ *
+ * @author hmilyylimh
+ * ^_^
+ * @version 0.0.1
+ * ^_^
+ * @date 2018/3/30
+ */
+public class CompareQueueCosts {
+
+    /** 生产者数量 */
+    private static int COUNT_OF_PRODUCER = 2;
+
+    /** 消费者数量 */
+    private static final int COUNT_OF_CONSUMER = 1;
+
+    /** 准备添加的任务数量值 */
+    private static final int COUNT_OF_TASK = 1 << 20;
+
+    /** 线程池对象 */
+    private static ExecutorService executorService;
+
+    public static void main(String[] args) throws Exception {
+
+        for (int j = 1; j < 7; j++) {
+            COUNT_OF_PRODUCER = (int) Math.pow(2, j);
+            executorService = Executors.newFixedThreadPool(COUNT_OF_PRODUCER * 2);
+
+            int basePow = 8;
+            int capacity = 0;
+            for (int i = 1; i <= 3; i++) {
+                capacity = 1 << (basePow + i);
+                System.out.print("Producers: " + COUNT_OF_PRODUCER + "\t\t");
+                System.out.print("Consumers: " + COUNT_OF_CONSUMER + "\t\t");
+                System.out.print("Capacity: " + capacity + "\t\t");
+                System.out.print("LinkedBlockingQueue: " + testQueue(new LinkedBlockingQueue<Integer>(capacity), COUNT_OF_TASK) + "s" + "\t\t");
+                // System.out.print("ArrayList: " + testQueue(new ArrayList<Integer>(capacity), COUNT_OF_TASK) + "s" + "\t\t");
+                // System.out.print("LinkedList: " + testQueue(new LinkedList<Integer>(), COUNT_OF_TASK) + "s" + "\t\t");
+                System.out.print("MpscUnboundedArrayQueue: " + testQueue(new MpscUnboundedArrayQueue<Integer>(capacity), COUNT_OF_TASK) + "s" + "\t\t");
+                System.out.print("MpscChunkedArrayQueue: " + testQueue(new MpscChunkedArrayQueue<Integer>(capacity), COUNT_OF_TASK) + "s" + "\t\t");
+                System.out.println();
+            }
+            System.out.println();
+
+            executorService.shutdown();
+        }
+    }
+
+    private static Double testQueue(final Collection<Integer> queue, final int taskCount) throws Exception {
+        CompletionService<Long> completionService = new ExecutorCompletionService<Long>(executorService);
+
+        long start = System.currentTimeMillis();
+        for (int i = 0; i < COUNT_OF_PRODUCER; i++) {
+            executorService.submit(new Producer(queue, taskCount / COUNT_OF_PRODUCER));
+        }
+        for (int i = 0; i < COUNT_OF_CONSUMER; i++) {
+            completionService.submit((new Consumer(queue, taskCount / COUNT_OF_CONSUMER)));
+        }
+
+        for (int i = 0; i < COUNT_OF_CONSUMER; i++) {
+            completionService.take().get();
+        }
+
+        long end = System.currentTimeMillis();
+        return Double.parseDouble("" + (end - start)) / 1000;
+    }
+
+    private static class Producer implements Runnable {
+        private Collection<Integer> queue;
+        private int taskCount;
+
+        public Producer(Collection<Integer> queue, int taskCount) {
+            this.queue = queue;
+            this.taskCount = taskCount;
+        }
+
+        @Override
+        public void run() {
+            // Queue队列
+            if (this.queue instanceof Queue) {
+                Queue<Integer> tempQueue = (Queue<Integer>) this.queue;
+                while (this.taskCount > 0) {
+                    if (tempQueue.offer(this.taskCount)) {
+                        this.taskCount--;
+                    } else {
+                        // System.out.println("Producer offer failed.");
+                    }
+                }
+            }
+            // List列表
+            else if (this.queue instanceof List) {
+                List<Integer> tempList = (List<Integer>) this.queue;
+                while (this.taskCount > 0) {
+                    if (tempList.add(this.taskCount)) {
+                        this.taskCount--;
+                    } else {
+                        // System.out.println("Producer offer failed.");
+                    }
+                }
+            }
+        }
+    }
+
+    private static class Consumer implements Callable<Long> {
+        private Collection<Integer> queue;
+        private int taskCount;
+
+        public Consumer(Collection<Integer> queue, int taskCount) {
+            this.queue = queue;
+            this.taskCount = taskCount;
+        }
+
+        @Override
+        public Long call() {
+            // Queue队列
+            if (this.queue instanceof Queue) {
+                Queue<Integer> tempQueue = (Queue<Integer>) this.queue;
+                while (this.taskCount > 0) {
+                    if ((tempQueue.poll()) != null) {
+                        this.taskCount--;
+                    }
+                }
+            }
+            // List列表
+            else if (this.queue instanceof List) {
+                List<Integer> tempList = (List<Integer>) this.queue;
+                while (this.taskCount > 0) {
+                    if (!tempList.isEmpty() && (tempList.remove(0)) != null) {
+                        this.taskCount--;
+                    }
+                }
+            }
+            return 0L;
+        }
+    }
+}
+
+2、指标结果：
+Producers: 2        Consumers: 1        Capacity: 512       LinkedBlockingQueue: 1.399s     MpscUnboundedArrayQueue: 0.109s     MpscChunkedArrayQueue: 0.09s
+Producers: 2        Consumers: 1        Capacity: 1024      LinkedBlockingQueue: 1.462s     MpscUnboundedArrayQueue: 0.041s     MpscChunkedArrayQueue: 0.048s
+Producers: 2        Consumers: 1        Capacity: 2048      LinkedBlockingQueue: 0.281s     MpscUnboundedArrayQueue: 0.037s     MpscChunkedArrayQueue: 0.082s
+
+Producers: 4        Consumers: 1        Capacity: 512       LinkedBlockingQueue: 0.681s     MpscUnboundedArrayQueue: 0.085s     MpscChunkedArrayQueue: 0.133s
+Producers: 4        Consumers: 1        Capacity: 1024      LinkedBlockingQueue: 0.405s     MpscUnboundedArrayQueue: 0.094s     MpscChunkedArrayQueue: 0.172s
+Producers: 4        Consumers: 1        Capacity: 2048      LinkedBlockingQueue: 0.248s     MpscUnboundedArrayQueue: 0.107s     MpscChunkedArrayQueue: 0.153s
+
+Producers: 8        Consumers: 1        Capacity: 512       LinkedBlockingQueue: 1.523s     MpscUnboundedArrayQueue: 0.093s     MpscChunkedArrayQueue: 0.172s
+Producers: 8        Consumers: 1        Capacity: 1024      LinkedBlockingQueue: 0.668s     MpscUnboundedArrayQueue: 0.094s     MpscChunkedArrayQueue: 0.281s
+Producers: 8        Consumers: 1        Capacity: 2048      LinkedBlockingQueue: 0.555s     MpscUnboundedArrayQueue: 0.078s     MpscChunkedArrayQueue: 0.455s
+
+Producers: 16       Consumers: 1        Capacity: 512       LinkedBlockingQueue: 2.676s     MpscUnboundedArrayQueue: 0.093s     MpscChunkedArrayQueue: 0.753s
+Producers: 16       Consumers: 1        Capacity: 1024      LinkedBlockingQueue: 2.135s     MpscUnboundedArrayQueue: 0.093s     MpscChunkedArrayQueue: 0.792s
+Producers: 16       Consumers: 1        Capacity: 2048      LinkedBlockingQueue: 0.944s     MpscUnboundedArrayQueue: 0.098s     MpscChunkedArrayQueue: 0.64s
+
+Producers: 32       Consumers: 1        Capacity: 512       LinkedBlockingQueue: 6.647s     MpscUnboundedArrayQueue: 0.078s     MpscChunkedArrayQueue: 2.109s
+Producers: 32       Consumers: 1        Capacity: 1024      LinkedBlockingQueue: 3.893s     MpscUnboundedArrayQueue: 0.095s     MpscChunkedArrayQueue: 1.797s
+Producers: 32       Consumers: 1        Capacity: 2048      LinkedBlockingQueue: 2.019s     MpscUnboundedArrayQueue: 0.109s     MpscChunkedArrayQueue: 2.427s
+
+Producers: 64       Consumers: 1        Capacity: 512       LinkedBlockingQueue: 26.59s     MpscUnboundedArrayQueue: 0.078s     MpscChunkedArrayQueue: 3.627s
+Producers: 64       Consumers: 1        Capacity: 1024      LinkedBlockingQueue: 22.566s    MpscUnboundedArrayQueue: 0.093s     MpscChunkedArrayQueue: 3.047s
+Producers: 64       Consumers: 1        Capacity: 2048      LinkedBlockingQueue: 1.719s     MpscUnboundedArrayQueue: 0.093s     MpscChunkedArrayQueue: 2.549s
+
+3、结果分析(一)：
+通过结果打印耗时可以明显看到MpscUnboundedArrayQueue耗时几乎大多数都是不超过0.1s的，这添加、删除的操作效率不是一般的高，这也难怪人家netty要舍弃自己写的队列框架了；
+
+4、结果分析(二)：
+CompareQueueCosts代码里面我将ArrayList、LinkedList注释掉了，那是因为队列数量太大，List的操作太慢，效率低下，所以在大量并发的场景下，大家还是能避免则尽量避免，否则就遭殃了；
+```
+
+## 五、总结
+
+```
+1、通过底层无锁的Unsafe操作方式实现了多生产者同时访问队列的线程安全模型；
+
+2、由于使用锁会造成的线程切换，特别消耗资源，因此使用无锁而是采用CAS的操作方式，虽然会在一定程度上造成CPU使用率过高，但是整体上将效率还是听可观的；
+
+3、队列的数据结构是一种单向链表式的结构，通过生产、消费指针来标识添加、移除元素的指针位置，缓冲区与缓冲区之间通过指针指向，避免的数组的复制，较少了大量内存的占用情况；
+```
\ No newline at end of file
diff --git a/netty/file-create.py b/netty/file-create.py
new file mode 100644
index 0000000..a412975
--- /dev/null
+++ b/netty/file-create.py
@@ -0,0 +1,27 @@
+import os
+import pyperclip
+
+# 获取当前脚本的路径
+script_dir = os.path.dirname(os.path.abspath(__file__))
+
+# 从剪贴板获取文件名列表，假设每行一个文件名
+file_names = pyperclip.paste().strip().split('\n')
+
+# 遍历文件名列表，为每个文件名添加排序前缀并创建文件
+for index, file_name in enumerate(file_names, start=1):
+    # 去除文件名两端的空白字符
+    file_name = file_name.strip()
+    
+    # 添加排序前缀和.md后缀
+    file_name_with_prefix = f"{index:02d}-{file_name}.md"  # 这里使用3位数的排序前缀，可以根据需要调整
+    
+    # 构建文件的完整路径
+    file_path = os.path.join(script_dir, file_name_with_prefix)
+    
+    # 创建文件
+    with open(file_path, 'w') as file:
+        # 如果需要写入初始内容，可以在这里添加
+        # 例如：file.write("This is the content of the file.")
+        pass  # 如果不需要写入内容，则使用pass
+
+print(f"Files created successfully in {script_dir}")
\ No newline at end of file
diff --git a/netty/tmp.txt b/netty/tmp.txt
new file mode 100644
index 0000000..bd0a9e7
--- /dev/null
+++ b/netty/tmp.txt
@@ -0,0 +1,63 @@
+Netty 面试题
+Netty 学习指南
+Netty 源码分析-调试环境搭建
+Netty 源码分析-NIO 基础（一）之简介
+Netty 源码分析-NIO 基础（二）之 Channel
+Netty 源码分析-NIO 基础（三）之 Buffer
+Netty 源码分析-NIO 基础（四）之 Selector
+Netty 源码分析-NIO 基础（五）之示例
+Netty 源码分析-Netty 简介（一）之项目结构
+Netty 源码分析-Netty 简介（二）之核心组件
+Netty 源码分析-启动（一）之服务端
+Netty 源码分析-启动（二）之客户端
+Netty 源码解析-EventLoop（一）之 Reactor 模型
+Netty 源码解析-EventLoop（二）之 EventLoopGroup
+Netty 源码解析-EventLoop（三）之 EventLoop 初始化
+Netty 源码解析-EventLoop（四）之 EventLoop 运行
+Netty 源码解析-EventLoop（五）之 EventLoop 处理 IO 事件
+Netty 源码解析-EventLoop（六）之 EventLoop 处理普通任务
+Netty 源码解析-EventLoop（七）之 EventLoop 处理定时任务
+Netty 源码解析-EventLoop（八）之 EventLoop 优雅关闭
+Netty 源码解析-ChannelPipeline（一）之初始化
+Netty 源码解析-ChannelPipeline（二）之添加 ChannelHandler
+Netty 源码解析-ChannelPipeline（三）之移除 ChannelHandler
+Netty 源码解析-ChannelPipeline（四）之 Outbound 事件的传播
+Netty 源码解析-ChannelPipeline（五）之 Inbound 事件的传播
+Netty 源码解析-ChannelPipeline（六）之异常事件的传播
+Netty 源码解析-Channel（一）之简介
+Netty 源码解析-Channel（三）之 read 操作
+Netty 源码解析-Channel（二）之 accept 操作
+Netty 源码解析-Channel（四）之 write 操作
+Netty 源码解析-Channel（五）之 flush 操作
+Netty 源码解析-Channel（六）之 writeAndFlush 操作
+Netty 源码解析-Channel（七）之 close 操作
+Netty 源码解析-Channel（八）之 disconnect 操作
+Netty 源码解析-Buffer 之 ByteBuf（一）简介
+Netty 源码解析-Buffer 之 ByteBuf（二）核心子类
+Netty 源码解析-Buffer 之 ByteBuf（三）内存泄露检测
+Netty 源码解析-Buffer 之 ByteBuf（四）其它子类
+Netty 源码解析-Buffer 之 ByteBufAllocator（一）简介
+Netty 源码解析-Buffer 之 ByteBufAllocator（二）UnpooledByteBufAllocator
+Netty 源码解析-Buffer 之 ByteBufAllocator（三）PooledByteBufAllocator
+Netty 源码解析-Buffer 之 Jemalloc（一）简介
+Netty 源码解析-Buffer 之 Jemalloc（二）PoolChunk
+Netty 源码解析-Buffer 之 Jemalloc（三）PoolSubpage
+Netty 源码解析-Buffer 之 Jemalloc（四）PoolChunkList
+Netty 源码解析-Buffer 之 Jemalloc（五）PoolArena
+Netty 源码解析-Buffer 之 Jemalloc（六）PoolThreadCache
+Netty 源码解析-ChannelHandler（一）之简介
+Netty 源码解析-ChannelHandler（二）之 ChannelInitializer
+Netty 源码解析-ChannelHandler（三）之 SimpleChannelInboundHandler
+Netty 源码解析-ChannelHandler（四）之 LoggingHandler
+Netty 源码解析-ChannelHandler（五）之 IdleStateHandler
+Netty 源码解析-ChannelHandler（六）之 AbstractTrafficShapingHandler
+Netty 源码解析-Codec 之 ByteToMessageDecoder（一）Cumulator
+Netty 源码解析-Codec 之 ByteToMessageDecoder（二）FrameDecoder
+Netty 源码解析-Codec 之 MessageToByteEncoder
+Netty 源码解析-Codec 之 ByteToMessageCodec
+Netty 源码解析-Codec 之 MessageToMessageCodec
+Netty 源码解析-Util 之 Future
+Netty 源码解析-Util 之 FastThreadLocal
+Netty 源码解析-Util 之 Recycler
+Netty 源码解析-Util 之 HashedWheelTimer
+Netty 源码解析-Util 之 MpscUnboundedArrayQueue
\ No newline at end of file
diff --git a/other/file-create.py b/other/file-create.py
new file mode 100644
index 0000000..96306ed
--- /dev/null
+++ b/other/file-create.py
@@ -0,0 +1,29 @@
+import os
+import sys
+import pyperclip  # 如果你使用的是Windows或macOS，需要安装这个库
+
+# 获取当前脚本的路径
+script_dir = os.path.dirname(os.path.abspath(__file__))
+
+# 从剪贴板获取文件名列表
+# 假设剪贴板中的文本是每行一个文件名
+file_names = pyperclip.paste().strip().split('\n')
+
+# 遍历文件名列表
+for file_name in file_names:
+    # 去除文件名两端的空白字符
+    file_name = file_name.strip()
+    
+    # 添加.md后缀
+    file_name_with_extension = f"{file_name}.md"
+    
+    # 构建文件的完整路径
+    file_path = os.path.join(script_dir, file_name_with_extension)
+    
+    # 创建文件
+    with open(file_path, 'w') as file:
+        # 如果你想在文件中写入一些初始内容，可以在这里写入
+        # 例如：file.write("This is the content of the file.")
+        pass  # 如果不需要写入内容，使用pass语句或者省略with块内的内容
+
+print(f"Files created successfully in {script_dir}")
\ No newline at end of file
diff --git a/other/tmp.txt b/other/tmp.txt
new file mode 100644
index 0000000..812c0ad
--- /dev/null
+++ b/other/tmp.txt
@@ -0,0 +1,5 @@
+精尽 Redis 源码分析 —— 调试环境搭建（Redis 6.X 版本）
+精尽 Redisson 源码分析 —— 调试环境搭建
+精尽 Redisson 源码分析 —— 限流器 RateLimiter
+精尽 Redisson 源码分析 —— 可重入分布式锁 ReentrantLock
+精尽 Redisson 源码分析 —— 可靠分布式锁 RedLock
\ No newline at end of file
diff --git a/redis/01-Redis 源码分析-调试环境搭建（Redis 6.X 版本）.md b/redis/01-Redis 源码分析-调试环境搭建（Redis 6.X 版本）.md
new file mode 100644
index 0000000..bce0b0b
--- /dev/null
+++ b/redis/01-Redis 源码分析-调试环境搭建（Redis 6.X 版本）.md	
@@ -0,0 +1,131 @@
+# 精尽 Redis 源码分析 —— 调试环境搭建（Redis 6.X 版本）
+
+> 艿艿是 MacOS ， 胖友如果是 Windows 的话，可以参考本文，略作修改。
+
+今儿，我们来搭建一个 Redis 调试环境，目标是：
+
+- 启动 Redis Server ，成功断点调试 Server 的启动过程。
+- 使用 `redis-cli` 启动一个 Client 连接上 Server，并使用 `get key` 指令，发起一次 key 的读取。
+
+视频可见 B 站：https://www.bilibili.com/video/BV12X4y1c79z
+
+😝 艿艿比较腼腆，大家给个三连支持一下，感恩 1024~
+
+# 1. 依赖工具
+
+## 1.1 CLion
+
+下载地址：https://www.jetbrains.com/clion
+
+CLion 是 Jetbrains 团队提供的 C/C++ 开发工具。所以，所以和我们平时使用的 [IDEA](https://www.iocoder.cn/IDEA/idea-2020-reset-eval/) 差别不大。
+
+这里，艿艿使用的是 CLion 版本是 **2021.1.3** 。
+
+## ~~1.2 CMake~~
+
+从 CLion [2020.2](https://blog.jetbrains.com/zh-hans/2020/07/08/clion-makefile/) 版本开始，可以支持 Makefile 类型的项目，而 Redis 就是使用 Makefile 构建的项目，所以我们**无需**再安装 CMake 啦！！！
+
+可能胖友对 Makefile 或是 CMake 不太了解？！没关系，这个小节主要是给，之前尝试搭建 Redis 调试环境，结果被 CMake 的胖友。
+
+**不影响后续的内容的学习**！
+
+# 2. 源码拉取
+
+使用 CLion 从官方仓库 https://github.com/antirez/redis 克隆项目。操作如下图所示：
+
+> 友情提示：如果网络不是很好的胖友，可以选择和艿艿一样，使用 Gitee 提供的镜像仓库 https://gitee.com/mirrors/redis.git
+
+[![克隆 Redis 仓库](https://www.iocoder.cn/images/Redis/2019_09_20/redis-clone.gif)](https://www.iocoder.cn/images/Redis/2019_09_20/redis-clone.gif)克隆 Redis 仓库
+
+这里，我们使用的 Redis 版本是 **6.2.5**。
+
+> 友情提示：胖友可以考虑 Fork 下[官方仓库](https://github.com/antirez/redis)，为什么呢？
+>
+> 既然开始阅读、调试源码，我们可能会写一些注释，有了自己的仓库，可以进行自由的提交。😜
+
+# 3. 导入项目
+
+克隆完项目后，CLion 会进行 Importing 导入项目，耐心等待一下。如下图所示：
+
+[![导入项目](https://www.iocoder.cn/images/Redis/2019_09_20/redis-importing.png)](https://www.iocoder.cn/images/Redis/2019_09_20/redis-importing.png)导入项目
+
+# 4. 编译项目
+
+导入完成后，打开 Makefile 文件，点击 `default:all` 绿色箭头，开始项目的编译。如下图所示：
+
+[![编译项目](https://www.iocoder.cn/images/Redis/2019_09_20/redis-build.png)](https://www.iocoder.cn/images/Redis/2019_09_20/redis-build.png)编译项目
+
+# 5. 运行 Redis Server
+
+① 配置 Redis Server 的启动项，操作如下图所示：
+
+[![配置 Redis Server 启动项](https://www.iocoder.cn/images/Redis/2019_09_20/redis-server.png)](https://www.iocoder.cn/images/Redis/2019_09_20/redis-server.png)配置 Redis Server 启动项
+
+[![配置 Redis Server 启动项](https://www.iocoder.cn/images/Redis/2019_09_20/redis-server2.png)](https://www.iocoder.cn/images/Redis/2019_09_20/redis-server2.png)配置 Redis Server 启动项
+
+② 打开 `server.c` 文件，在 `#main(...)` 方法上，添加一个**方法断点**，它是 Redis Server 的启动入口。如下图所示：
+
+[![设置 Redis Server main 断点](https://www.iocoder.cn/images/Redis/2019_09_20/redis-server-main.png)](https://www.iocoder.cn/images/Redis/2019_09_20/redis-server-main.png)设置 Redis Server main 断点
+
+③ **Debug** 右上方的 redis-server 启动项，成功进入 `#main(...)` 方法的断点。如下图所示：
+
+[![进入 Redis Server main 断点](https://www.iocoder.cn/images/Redis/2019_09_20/redis-server-main2.png)](https://www.iocoder.cn/images/Redis/2019_09_20/redis-server-main2.png)进入 Redis Server main 断点
+
+------
+
+至此，我们已经完成了我们的第一个小目标“*启动 Redis Server ，成功断点调试 Server 的启动过程*”。
+
+点击左下方的**绿色**小箭头，恢复 Redis Server 的启动，不然等会 Redis Client 都连接不上来。在 CLion 的控制台，我们会看到 Redis Server 启动成功的日志如下：
+
+```
+22315:M 28 Jul 2021 01:23:37.535 # Server initialized
+22315:M 28 Jul 2021 01:23:37.535 * Ready to accept connections
+```
+
+# 6. 运行 Redis Client
+
+① 打开 `ae.c` 文件，在 `#aeProcessEvents(...)` 方法的如图处，打上一个**端点**，用于调试 Redis Server 处理各种来自 Redis Client 的 IO 事件。如下图所示：
+
+[![设置 Redis Server ae 断点](https://www.iocoder.cn/images/Redis/2019_09_20/redis-server-ae.png)](https://www.iocoder.cn/images/Redis/2019_09_20/redis-server-ae.png)设置 Redis Server ae 断点
+
+② 打开 IDE Terminal，运行 `redis-cli` 启动一个 Redis Client，连接上 Redis Server。如下图所示：
+
+[![启动 Redis Client](https://www.iocoder.cn/images/Redis/2019_09_20/redis-cli.png)](https://www.iocoder.cn/images/Redis/2019_09_20/redis-cli.png)启动 Redis Client
+
+此时，我们在 `ae.c` 的 `#aeProcessEvents(...)` 的断点成功进入，Redis Server 收到 Redis Client 的**连接事件**。
+
+打开 Debug 窗口，点击左下方的**绿色**小箭头，恢复 Redis Server 的执行。
+
+③ 回到 `redis-cli` 命令行，输入 `get key` 指令，向 Redis Server 发起一次 `get` 请求。效果如下图所示：
+
+[![Redis Client 读取 key](https://www.iocoder.cn/images/Redis/2019_09_20/redis-cli-get-key.png)](https://www.iocoder.cn/images/Redis/2019_09_20/redis-cli-get-key.png)Redis Client 读取 key
+
+此时，我们在 `ae.c` 的 `#aeProcessEvents(...)` 的断点又一次进入，Redis Server 收到 Redis Client 的 `get` 请求。
+
+------
+
+至此，我们已经完成了我们的第二个小目标“*使用 `redis-cli` 启动一个 Client 连接上 Server，并使用 `get key` 指令，发起一次 key 的读取*”。
+
+# 7. 源码解析
+
+Redis 源码是使用 C 实现的，对于 Java 程序员的我们来说，还是有一定“门槛”的，所以最好借助下市面上 Redis 相关的书籍。
+
+① [《Redis 设计与实现》](https://github.com/YunaiV/books)，针对 Redis 3.X 版本，豆瓣评分 8.6 分，对应详细注释的 Redis 仓库 https://github.com/YunaiV/redis-3.0-annotated.git 。
+
+这本书艿艿和蛮多朋友都看过，虽然针对的 Redis 版本比较老，考虑到 Redis 核心代码变动其实不多，还是非常不错的选择。
+
+② [《Redis5设计与源码分析》](https://github.com/YunaiV/books)，针对 Redis 5.X 版本，豆瓣评分 6.8 分。
+
+主要优点是针对 Redis 5.X 版本，比较新。具体内容如何，艿艿也不是很确定。可以备一本，在看到源码卡壳的时候，作为字典查一查，也是不错的选择哈~
+
+③ [《Redis源码剖析与实战》](https://static001.geekbang.org/misc/posters/1044546/184d59981e2b62d539ae6e4732a8badb.jpg)，针对 Redis 版本不详，极客时间 2021 年出的，可能是 Redis 6.X 版本。
+
+这个专栏，目前还在更新，艿艿准备养肥之后，花 1-2 周撸一撸，嘿嘿！作者（蒋德钧）之前出的[《Redis核心技术与实战》](https://static001.geekbang.org/misc/posters/1044546/bc2c20a873b8d016029fb615f96fcd1e.jpg) 非常不错，我大飞哥好评连连！
+
+------
+
+**END~**
+
+我是艿艿，一个正在某厂做 Web IDE 的死胖子，干掉本地 IDEA 和 VSCode！
+
+欢迎添加我的微信号 **naiziguo**，一起网上冲浪 🌊 …
\ No newline at end of file
diff --git a/redis/02-Redisson 源码分析-调试环境搭建.md b/redis/02-Redisson 源码分析-调试环境搭建.md
new file mode 100644
index 0000000..a3b5f6b
--- /dev/null
+++ b/redis/02-Redisson 源码分析-调试环境搭建.md	
@@ -0,0 +1,83 @@
+# 精尽 Redisson 源码分析 —— 调试环境搭建
+
+> 本文基于 Redisson `3.11.4-SNAPSHOT` 版本，望知悉。
+>
+> 可能有些胖友不是很了解 Redisson ，可以看看 [Redis 客户端 Redisson](https://www.oschina.net/p/redisson) 。
+
+# 1. 依赖工具
+
+- Maven
+- Git
+- JDK
+- IntelliJ IDEA
+
+另外，胖友需要启动一个 Redis 节点。例如说，艿艿使用默认配置，在 127.0.0.1:6379 启动了一个。
+
+# 2. 源码拉取
+
+从官方仓库 https://github.com/redisson/redisson Fork 出属于自己的仓库。
+
+- 为什么要 Fork ？既然开始阅读、调试源码，我们可能会写一些注释，有了自己的仓库，可以进行自由的提交。😈
+
+在拉取项目的过程中，我们来看看每个 Redisson 的子项目：
+
+- [redisson](https://github.com/redisson/redisson/tree/master/redisson) ：Redisson 实现。
+
+- [redisson-tomcat](https://github.com/redisson/redisson/tree/master/redisson-tomcat) ：Redisson 集成到 Tomcat 中，实现分布式 Session 功能。
+
+- [redisson-spring-data](https://github.com/redisson/redisson) ：Redisson 集成到 Spring Data Redis 中。
+
+  > 不了解 Spring Data Redis 的胖友，可以看看艿艿写的 [《芋道 Spring Boot Redis 入门》](http://www.iocoder.cn/Spring-Boot/Redis/?vip) 。
+
+- [redisson-spring-boot-starter](https://github.com/redisson/redisson/tree/master/redisson-spring-boot-starter) ：Redisson 实现的 Spring Boot Starter ，方便我们在使用 Spring Boot 的项目中，自动化配置 Redisson 。
+
+- [redisson-hibernate](https://github.com/redisson/redisson) ：Redisson 集成到 Hibernate 中，提供二级缓存的功能。
+
+😈 Redisson 团队，还是很勤劳的，**主动**集成了这么多框架。当然，也是因为 Redisson 出的比较晚，前有 Jedis 后有 Lettuce ，不努力点可能无法被开发者所接受。
+
+# 3. 测试运行
+
+在测试目录下，创建 [YunaiDebugDemo](https://github.com/YunaiV/redisson/blob/master/redisson/src/test/java/org/redisson/yunai/YunaiDebugDemo.java) 类，编写代码如下：
+
+```
+public class YunaiDebugDemo {
+
+    public static void main(String[] args) throws InterruptedException {
+        // 创建 RedissonClient 对象
+        RedissonClient client = Redisson.create();
+
+        // 创建 RRateLimiter 对象
+        RRateLimiter rateLimiter = client.getRateLimiter("myRateLimiter");
+        // 初始化：最大流速 = 每 1 分钟产生 2 个令牌
+        rateLimiter.trySetRate(RateType.OVERALL, 2, 1, RateIntervalUnit.SECONDS);
+
+        SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
+        for (int i = 0; i < 5; i++) {
+            System.out.println(String.format("%s：获得锁结果(%s)", simpleDateFormat.format(new Date()),
+                    rateLimiter.tryAcquire()));
+            Thread.sleep(250L);
+        }
+    }
+
+}
+```
+
+在参考 [《Redisson 文档 —— 限流器（RateLimiter）》](https://github.com/redisson/redisson/wiki/6.-分布式对象#612-限流器ratelimiter) ，艿艿编写了一个简单的限流，进行测试。点击运行，输出结果如下：
+
+```
+2019-10-02 10:48:00：获得锁结果(true)
+2019-10-02 10:48:01：获得锁结果(true)
+2019-10-02 10:48:01：获得锁结果(false)
+2019-10-02 10:48:01：获得锁结果(false)
+2019-10-02 10:48:02：获得锁结果(true)
+```
+
+后续，胖友自己 Debug 运行即可，想调哪个调哪个。
+
+# 666. 彩蛋
+
+Redisson 的源码解析，会更新的比较随缘。艿艿自己项目中，还是只使用 Jedis 哈。不过考虑在 [onemall](https://github.com/YunaiV/onemall) 中，尝试使用下 Redisson ，嘿嘿。
+
+如果胖友想看 Redisson 功能的源码解析，可以在星球给我留言。
+
+😈 本文有点水更，大家 2019-10-02 国庆快乐。
\ No newline at end of file
diff --git a/redis/03-Redisson 源码分析-限流器 RateLimiter.assets/01.jpg b/redis/03-Redisson 源码分析-限流器 RateLimiter.assets/01.jpg
new file mode 100644
index 0000000..0f6b8d2
Binary files /dev/null and b/redis/03-Redisson 源码分析-限流器 RateLimiter.assets/01.jpg differ
diff --git a/redis/03-Redisson 源码分析-限流器 RateLimiter.md b/redis/03-Redisson 源码分析-限流器 RateLimiter.md
new file mode 100644
index 0000000..9594f38
--- /dev/null
+++ b/redis/03-Redisson 源码分析-限流器 RateLimiter.md	
@@ -0,0 +1,502 @@
+# 精尽 Redisson 源码分析 —— 限流器 RateLimiter
+
+# 1. 概述
+
+在开始本文之前，先推荐看一篇干货 [《你应该如何正确健壮后端服务？》](http://www.iocoder.cn/Fight/How-do-you-robust-back-end-services/?vip) 。
+
+限流，无论在系统层面，还是在业务层面，使用都非常广泛。例如说：
+
+- 【业务】为了避免恶意的灌水机或者用户，限制每分钟至允许回复 10 个帖子。
+- 【系统】为了避免服务系统被大规模调用，超过极限，限制每个调用方只允许每秒调用 100 次。
+
+限流算法，常用的分成四种：
+
+> 每一种的概念，推荐看看 [《计数器、滑动窗口、漏桶、令牌算法比较和伪代码实现》](https://www.iphpt.com/detail/106) 文章。
+
+- 计数器
+
+  > 比较简单，每**固定单位**一个计数器即可实现。
+
+- 滑动窗口
+
+  > Redisson 提供的是基于**滑动窗口** RateLimiter 的实现。相比**计数器**的实现，它的起点不是固定的，而是以开始计数的那个时刻开始为一个窗口。
+  >
+  > 所以，我们可以把**计数器**理解成一个滑动窗口的特例，以**固定单位**为一个窗口。
+
+- 令牌桶算法
+
+  > [《Eureka 源码解析 —— 基于令牌桶算法的 RateLimiter》](http://www.iocoder.cn/Eureka/rate-limiter/?vip) ，单机并发场景下的 RateLimiter 实现。
+  >
+  > [《Spring-Cloud-Gateway 源码解析 —— 过滤器 (4.10) 之 RequestRateLimiterGatewayFilterFactory 请求限流》](http://www.iocoder.cn/Spring-Cloud-Gateway/filter-request-rate-limiter/?vip) ，基于 Redis 实现的令牌桶算法的 RateLimiter 实现。
+
+- 漏桶算法
+
+  > 漏桶算法，一直没搞明白和令牌桶算法的区别。现在的理解是：
+  >
+  > - 令牌桶算法，桶里装的是令牌。每次能拿取到令牌，就可以进行访问。并且，令牌会按照速率不断恢复放到令牌桶中直到桶满。
+  > - 漏桶算法，桶里装的是请求。当桶满了，请求就进不来。例如说，Hystrix 使用线程池或者 Semaphore 信号量，只有在请求未满的时候，才可以进行执行。
+
+上面哔哔了非常多的字，只看本文的话，就那一句话：“**Redisson 提供的是基于滑动窗口 RateLimiter 的实现。**”。
+
+# 2. 整体一览
+
+在 Redisson 中，提供了四个 RateLimiter 相关的接口，如下图：
+
+[![RateLimiter 接口](03-Redisson 源码分析-限流器 RateLimiter.assets/01.jpg)](http://www.iocoder.cn/images/Redis/2019_10_02/01.jpg)RateLimiter 接口
+
+- [`org.redisson.api.RRateLimiterAsync`](https://github.com/YunaiV/redisson/blob/master/redisson/src/main/java/org/redisson/api/RRateLimiterAsync.java) ，定义了异步操作的接口。
+- [`org.redisson.api.RRateLimiter`](https://github.com/YunaiV/redisson/blob/master/redisson/src/main/java/org/redisson/api/RRateLimiter.java) ，继承 RRateLimiterAsync 的基础上，定义了同步操作的接口。
+- [`org.redisson.api.RRateLimiterReactive`](https://github.com/YunaiV/redisson/blob/master/redisson/src/main/java/org/redisson/api/RRateLimiterReactive.java) ，定义基于 [Reactor](https://github.com/reactor/reactor) 操作的接口。
+- [`org.redisson.api.RRateLimiterReactive`](https://github.com/YunaiV/redisson/blob/master/redisson/src/main/java/org/redisson/api/RRateLimiterRx.java) ，定义基于 [RxJava](https://github.com/ReactiveX/RxJava) 操作的接口。
+
+目前，Redisson 暂时只实现了 RRateLimiterAsync 和 RRateLimiter 接口的方法，即 [`org.redisson.RedissonRateLimiter`](https://github.com/YunaiV/redisson/blob/master/redisson/src/main/java/org/redisson/RedissonRateLimiter.java) 。
+
+RRateLimiterAsync 和 RRateLimiter 定义的接口，差别就在于同步和异步，所以我们就只看看 RRateLimiter 接口。代码如下：
+
+```
+boolean trySetRate(RateType mode, long rate, long rateInterval, RateIntervalUnit rateIntervalUnit);
+RateLimiterConfig getConfig();
+
+boolean tryAcquire();
+boolean tryAcquire(long permits);
+boolean tryAcquire(long timeout, TimeUnit unit);
+boolean tryAcquire(long permits, long timeout, TimeUnit unit);
+
+void acquire();
+void acquire(long permits);
+```
+
+- `#trySetRate(RateType mode, long rate, long rateInterval, RateIntervalUnit rateIntervalUnit)` 方法，设置限流器的配置。
+- `#getConfig()` 方法，获得限流器的配置。
+- `#tryAcquire(...)` 方法，尝试在指定时间内，获得指定数量的令牌，并返回是否成功。
+- `#acquire(...)` 方法，在指定时间内，获得指定数量的令牌，直到成功。
+
+总的来说，一共两类方法，一类是设置或获取配置，一类是获取令牌。下面，我们来逐个方法的源码，来瞅瞅。
+
+# 3. trySetRate
+
+在 [《精尽 Redisson 源码分析 —— 调试环境搭建》](http://svip.iocoder.cn/Redisson/build-debugging-environment/?self) 中，我们搭建了一个限流器的示例。在示例的开始，我们会调用 `RRateLimiter#trySetRateAsync(RateType type, long rate, long rateInterval, RateIntervalUnit unit)` 方法，设置限流器的配置。代码如下：
+
+```
+// RedissonRateLimiter.java
+
+@Override
+public boolean trySetRate(RateType type, long rate, long rateInterval, RateIntervalUnit unit) {
+    return get(trySetRateAsync(type, rate, rateInterval, unit));
+}
+
+@Override
+public RFuture<Boolean> trySetRateAsync(RateType type, long rate, long rateInterval, RateIntervalUnit unit) {
+    return commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, RedisCommands.EVAL_BOOLEAN,
+            "redis.call('hsetnx', KEYS[1], 'rate', ARGV[1]);"
+          + "redis.call('hsetnx', KEYS[1], 'interval', ARGV[2]);"
+          + "return redis.call('hsetnx', KEYS[1], 'type', ARGV[3]);",
+            Collections.<Object>singletonList(getName()), // keys [分布锁名]
+            rate, unit.toMillis(rateInterval), type.ordinal()); // values [速度、速度单位、限流类型]
+}
+```
+
+- 将限流器的配置写入到 Redis 中。这个和我们看到的很多分布式限流器的实现不同，它们只提供获取令牌的功能，而 Redisson 多了持久化配置限流器的配置到 Redis 中，相当于说，Redis 起到了一个**配置中心**的功能，分布式下的相同限流器（“相同”指的是**相同名字**的限流器）使用同一的配置。
+
+- 参数
+
+   
+
+  ```
+  type
+  ```
+
+   
+
+  ：类型是
+
+   
+
+  `org.redisson.api.RateType`
+
+   
+
+  ，限流类型。目前有两种：
+
+  - `OVERALL` ：相同名字的所有 RateLimiter 实例。
+  - `PER_CLIENT` ：**相同 JVM 进程**的所有相同名字的所有 RateLimiter 实例。😢 有点莫名，为啥还会有 `PER_CLIENT` 级别的。目前能够想象的，一个是 Redis 可以统一配置，一个是 Redis 上可以看到限流的情况。
+
+- 参数 `rate` + `rateInterval` + `unit` ：形成指定时间内，允许执行的频率。
+
+整个的逻辑实现，通过 Redis Lua 脚本，保证整个配置的存储设置的原子性。并且，通过 [HSETNX](http://redis.cn/commands/hsetnx.html) 我们可以看到两点：
+
+- 配置的存储，使用 Redis Hash 数据结构。如下是个示例：
+
+  ```
+  127.0.0.1:6379> HGETALL myRateLimiter
+  1) "rate" # 速度
+  2) "50"
+  3) "interval" # 频率
+  4) "60000"
+  5) "type" # 限流类型
+  6) "0"
+  ```
+
+- 使用 HSETNX 指令，如果 Redis 该 KEY 已经被使用（例如说，已经初始化过限流器的配置），则**不进行覆盖**。这点，一定要注意哈。
+
+整段代码比较简单，可能不了解 Redisson 源码的胖友，会对此处的 `#get(RFuture<V> future)` 方法，有一点点疑惑。
+
+```
+// RedissonObject.java
+
+protected final CommandAsyncExecutor commandExecutor;
+
+protected final <V> V get(RFuture<V> future) {
+    return commandExecutor.get(future);
+}
+```
+
+- RedissonRateLimiter 继承了 RedissonObject 类。
+- `future` 参数，是 [`org.redisson.api.RFuture`](https://github.com/YunaiV/redisson/blob/master/redisson/src/main/java/org/redisson/api/RFuture.java) 接口类型，是 Redisson 对 Future 功能的增强，支持回调等功能。😈 下面，我们就会看到 RedissonRateLimiter 会使用到回调的功能。
+- 通过调用 `#get(RFuture<V> future)` 方法，将 `#trySetRateAsync(RateType type, long rate, long rateInterval, RateIntervalUnit unit)` 方法的 RFuture 结果，同步返回。
+
+另外，在 `#trySetRateAsync(RateType type, long rate, long rateInterval, RateIntervalUnit unit)` 方法，会调用 `#getName()` 方法，获得限流器的名字。代码如下：
+
+```
+// RedissonObject.java
+
+private String name;
+
+@Override
+public String getName() {
+    return name;
+}
+```
+
+- 这个属性，就是我们在 `RedissonClient#getRateLimiter(String name)` 方法，创建 RedissonRateLimiter 对象时所设置的。同时，`name` 也就成了我们在 Redis 所看到的**分布式限流器的名字**。
+
+# 4. getConfig
+
+`#getConfig()` 方法，从 Redis 中加载 [`org.redisson.apiRateLimiterConfig`](https://github.com/YunaiV/redisson/blob/master/redisson/src/main/java/org/redisson/api/RateLimiterConfig.java) 限流器配置。代码如下：
+
+```
+// RateLimiterConfig.java
+
+private static final RedisCommand HGETALL = new RedisCommand("HGETALL", new MultiDecoder<RateLimiterConfig>() {
+    @Override
+    public Decoder<Object> getDecoder(int paramNum, State state) {
+        return null;
+    }
+
+    @Override
+    public RateLimiterConfig decode(List<Object> parts, State state) {
+        Map<String, String> map = new HashMap<>(parts.size()/2);
+        for (int i = 0; i < parts.size(); i++) {
+            if (i % 2 != 0) {
+                map.put(parts.get(i-1).toString(), parts.get(i).toString());
+            }
+        }
+
+        // 创建 RateType 对象
+        RateType type = RateType.values()[Integer.valueOf(map.get("type"))];
+        Long rateInterval = Long.valueOf(map.get("interval"));
+        Long rate = Long.valueOf(map.get("rate"));
+        return new RateLimiterConfig(type, rateInterval, rate);
+    }
+
+}, ValueType.MAP);
+
+@Override
+public RateLimiterConfig getConfig() {
+    return get(getConfigAsync());
+}
+
+@Override
+public RFuture<RateLimiterConfig> getConfigAsync() {
+    return commandExecutor.readAsync(getName(), StringCodec.INSTANCE, HGETALL, getName());
+}
+```
+
+# 5. tryAcquire
+
+在看 `#tryAcquire(...)` 方法之前，我们先来看它是如何调用 Redis 实现限流算法的。代码如下：
+
+```
+// RedissonRateLimiter.java
+
+  1: private <T> RFuture<T> tryAcquireAsync(RedisCommand<T> command, Long value) {
+  2:     return commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, command,
+  3:             "local rate = redis.call('hget', KEYS[1], 'rate');"
+  4:           + "local interval = redis.call('hget', KEYS[1], 'interval');"
+  5:           + "local type = redis.call('hget', KEYS[1], 'type');"
+  6:           + "assert(rate ~= false and interval ~= false and type ~= false, 'RateLimiter is not initialized')"
+  7:
+  8:           + "local valueName = KEYS[2];"
+  9:           + "if type == '1' then "
+ 10:               + "valueName = KEYS[3];"
+ 11:           + "end;"
+ 12:
+ 13:           + "local currentValue = redis.call('get', valueName); "
+ 14:           + "if currentValue ~= false then "
+ 15:                  + "if tonumber(currentValue) < tonumber(ARGV[1]) then "
+ 16:                      + "return redis.call('pttl', valueName); "
+ 17:                  + "else "
+ 18:                      + "redis.call('decrby', valueName, ARGV[1]); "
+ 19:                      + "return nil; "
+ 20:                  + "end; "
+ 21:           + "else "
+ 22:                  + "assert(tonumber(rate) >= tonumber(ARGV[1]), 'Requested permits amount could not exceed defined rate'); "
+ 23:                  + "redis.call('set', valueName, rate, 'px', interval); "
+ 24:                  + "redis.call('decrby', valueName, ARGV[1]); "
+ 25:                  + "return nil; "
+ 26:           + "end;",
+ 27:             Arrays.<Object>asList(getName(), getValueName(), getClientValueName()), // KEYS [限流器的名字，限流器的值的名字，Client 编号的名字]
+ 28:             value, commandExecutor.getConnectionManager().getId()); // ARGS [需要获取令牌的数量，Client 编号]
+ 29: }
+```
+
+- 还是熟悉的配方，通过 Lua 脚本实现。具体传入的参数，朋友看下第 27 和 28 行的代码，对应的 `KEYS` 和 `ARGS` 。可能有几个值胖友会有点懵逼，我们先来看看。
+
+  - `KEYS[1]` ：调用 `#getName()` 方法获得限流器的名字。这个，我们在上面已经看到了。
+
+  - `KEYS[2]` ：调用 `#getValueName()` 方法，获得限流器的**值**的名字。该名字，就是在 Redis 存储**限流值**的 KEY 。代码如下：
+
+    ```
+    // RedissonObject.java
+    public static String suffixName(String name, String suffix) {
+        if (name.contains("{")) {
+            return name + ":" + suffix;
+        }
+        return "{" + name + "}:" + suffix;
+    }
+    
+    // RedissonRateLimiter.java
+    String getValueName() {
+        return suffixName(getName(), "value");
+    }
+    ```
+
+    - 例如说，`"myRateLimiter"` 对应的是
+
+      `"{myRateLimiter}:value"` 。示例如下：
+
+      ```
+      127.0.0.1:6379> scan 0
+      1) "0"
+      2) 1) "{myRateLimiter}:value"
+         2) "myRateLimiter"
+      ```
+
+      - 要注意，因为 `"{myRateLimiter}:value"` 设置了自动过期时间，所以如果要看，将限流器的配置的限流频率修改成分钟。
+
+  - `KEYS[3]` ：调用 `#getClientValueName()` 方法，获得使用 `PER_CLIENT` 限流类型时，每个 Client 所对应的**值**的名字。代码如下：
+
+    ```
+    // RedissonRateLimiter.java
+    String getClientValueName() {
+        return suffixName(getValueName(), commandExecutor.getConnectionManager().getId());
+    }
+    ```
+
+    - 例如说，艿艿启动了使用了 `"myRateLimiter"` 的多个 Client ，示例如下：
+
+      ```
+      127.0.0.1:6379> scan 0
+      1) "0"
+      2) 1) "{myRateLimiter}:value:f6059588-7693-4b6f-9413-edc24182252b"
+         2) "myRateLimiter"
+         3) "{myRateLimiter}:value:d751d219-c7c6-4ec1-98c2-bc1794dffd70"
+      ```
+
+      - 如果理解起来有点绕，不用方，下面我们还会继续看代码的。
+
+  - `ARGS[1]` ：需要获得令牌的数量。
+
+  - `ARGS[2]` ：忽略，实际脚本未使用到。
+
+- 第 3 至 6 行：获得限流器的配置。
+
+- 第 8 至 11 行：根据 `type`（限流类型），获得对应的**值** KEY 。在结合下 `KEYS[2]` 和 `KEYS[3]` ，是不是就清晰多了。
+
+- 第 13 行：获得限流对应的值。😈 **上面一直忘记说了，该值表示剩余可以获取的令牌数**。后续，会分成两种情况处理。
+
+- 第 14 至 20 行：情况一，获取的到值。
+
+  - 第 15 至 16 行：剩余的令牌数不够获取，则通过 [PTTL](http://redis.cn/commands/pttl.html) 指令，获得 KEY 剩余的过期时间，并返回。因为剩余令牌不够了，所以返回给应用，令牌刷新还需要多久时间（即过期就刷新啦）。**注意**，我们注意下所有返回值，实际上当返回 `null` 的时候，代表获取令牌成功；返回非 `null` 的时，就是令牌刷新还需要多久时间，表示获取令牌失败。
+  - 第 17 至 20 行：令牌足够，扣除令牌，并返回成功 `null` 。
+
+- 第 21 至 26 行：情况二，获取不到值，说明令牌是
+
+  满
+
+  的。
+
+  - 第 23 行：通过 [SET](http://redis.cn/commands/set.html) 指令，设置令牌为 `valueName` 满的，并设置过期时间为 `interval` 。
+  - 第 24 行：调用 [DECRBY](http://redis.cn/commands/decrby.html) 指令，扣除需要的令牌数。😈 不造为啥 Redisson 把 23 和 24 行使用一条指令解决。
+  - 第 25 行：返回成功 `null` 。
+
+下面，我们来看看 `#tryAcquireAsync(long permits, RPromise<Boolean> promise, long timeoutInMillis)` 方法，是怎么和上述方法结合的。代码如下：
+
+```
+// RedissonRateLimiter.java
+
+private void tryAcquireAsync(long permits, RPromise<Boolean> promise, long timeoutInMillis) {
+    // 获得当前时间
+    long s = System.currentTimeMillis();
+    // 执行获得令牌
+    RFuture<Long> future = tryAcquireAsync(RedisCommands.EVAL_LONG, permits);
+    // 通过 future 回调处理执行结果
+    future.onComplete((delay, e) -> {
+        // 发生异常，则 return 并通过 promise 处理异常
+        if (e != null) {
+            promise.tryFailure(e);
+            return;
+        }
+
+        // 如果未返回 delay ，而是空，说明获取锁成功了，则 return 并通过 promise 返回获得锁成功。
+        if (delay == null) {
+            promise.trySuccess(true);
+            return;
+        }
+
+        // 如果 timeoutInMillis 为 -1 ，表示持续获得到锁，直到成功。
+        if (timeoutInMillis == -1) {
+            // 通过定时任务，实现延迟 delay 毫秒，再次执行获得令牌。
+            commandExecutor.getConnectionManager().getGroup().schedule(() -> {
+                tryAcquireAsync(permits, promise, timeoutInMillis);
+            }, delay, TimeUnit.MILLISECONDS);
+            return;
+        }
+
+        // 计算剩余可获取令牌的时间
+        long el = System.currentTimeMillis() - s;
+        long remains = timeoutInMillis - el;
+        // 如果无剩余时间，则 return 并通过 promise 返回获得锁失败。
+        if (remains <= 0) {
+            promise.trySuccess(false);
+            return;
+        }
+        // 剩余时间小于锁刷新时间，则最后还是尝试一次延迟 remains 毫秒，再次执行获得锁
+        if (remains < delay) {
+            commandExecutor.getConnectionManager().getGroup().schedule(() -> {
+                promise.trySuccess(false);
+            }, remains, TimeUnit.MILLISECONDS);
+        } else {
+            // 剩余时间大于锁刷新时间，则延迟 delay 毫秒，再次执行获得锁
+            long start = System.currentTimeMillis();
+            commandExecutor.getConnectionManager().getGroup().schedule(() -> {
+                // 因为定时器是延迟 delay 毫秒，实际可能超过 remains 毫秒，此处判断兜底，避免无效重试。
+                long elapsed = System.currentTimeMillis() - start;
+                if (remains <= elapsed) {
+                    promise.trySuccess(false);
+                    return;
+                }
+
+                tryAcquireAsync(permits, promise, remains - elapsed);
+            }, delay, TimeUnit.MILLISECONDS);
+        }
+    });
+}
+```
+
+- 虽然逻辑比较长，实际逻辑比较简单。首先，调用 `#tryAcquireAsync(RedisCommand<T> command, Long value)` 方法，执行获得令牌。然后，通过设置返回的 RFuture 的 `#onComplete(BiConsumer<? super V, ? super Throwable> action)` 方法，回调处理执行令牌的返回结果。
+- 在回调中，如果获取令牌成功，则 `return` 并通过 `promise` 返回成功；如果获取令牌失败，则根据是否有足够的时间，去延迟调用 `#tryAcquireAsync(RedisCommand<T> command, Long value)` 方法，执行获得令牌，直到成功或超时或异常。
+- 整体逻辑，胖友自己瞅瞅，哈哈哈，感觉满巧妙的。😈 一开始，以为 Redisson 是基于令牌桶算法，实现限流算法，所以卡了莫名的久，被自己给蠢哭了。
+
+下面，我们来看看 `##tryAcquire(...)` 方法们的实现，就灰常简单。代码如下：
+
+```
+// RedissonRateLimiter.java
+
+@Override
+public boolean tryAcquire() {
+    return tryAcquire(1);
+}
+
+@Override
+public RFuture<Boolean> tryAcquireAsync() {
+    return tryAcquireAsync(1L);
+}
+
+@Override
+public boolean tryAcquire(long permits) {
+    return get(tryAcquireAsync(RedisCommands.EVAL_NULL_BOOLEAN, permits));
+}
+
+@Override
+public RFuture<Boolean> tryAcquireAsync(long permits) {
+    return tryAcquireAsync(RedisCommands.EVAL_NULL_BOOLEAN, permits);
+}
+
+@Override
+public boolean tryAcquire(long timeout, TimeUnit unit) {
+    return get(tryAcquireAsync(timeout, unit));
+}
+
+@Override
+public RFuture<Boolean> tryAcquireAsync(long timeout, TimeUnit unit) {
+    return tryAcquireAsync(1, timeout, unit);
+}
+
+@Override
+public boolean tryAcquire(long permits, long timeout, TimeUnit unit) {
+    return get(tryAcquireAsync(permits, timeout, unit));
+}
+
+@Override
+public RFuture<Boolean> tryAcquireAsync(long permits, long timeout, TimeUnit unit) {
+    // 创建 RPromise 对象
+    RPromise<Boolean> promise = new RedissonPromise<Boolean>();
+    // 计算 timeoutInMillis
+    long timeoutInMillis = -1;
+    if (timeout >= 0) {
+        timeoutInMillis = unit.toMillis(timeout);
+    }
+    // 执行获取令牌
+    tryAcquireAsync(permits, promise, timeoutInMillis);
+    return promise;
+}
+```
+
+# 6. acquire
+
+`acquire(...)` 方法们的实现，也灰常简单。代码如下：
+
+```
+// RedissonRateLimiter.java
+
+@Override
+public void acquire(long permits) {
+    get(acquireAsync(permits));
+}
+
+@Override
+public RFuture<Void> acquireAsync(long permits) {
+    // 创建 RPromise 对象
+    RPromise<Void> promise = new RedissonPromise<Void>();
+    // 执行获得令牌。通过 -1 ，表示重试到成功为止
+    tryAcquireAsync(permits, -1, null).onComplete((res, e) -> {
+        // 处理异常
+        if (e != null) {
+            promise.tryFailure(e);
+            return;
+        }
+
+        // 成功
+        promise.trySuccess(null);
+    });
+    return promise;
+}
+```
+
+# 666. 彩蛋
+
+行至文末，有一点要纠正一下。Redisson 提供的限流器不是**严格且完整**的滑动窗口的限流器实现。举个例子，我们创建了一个每分钟允许 3 次操作的限流器。整个执行过程如下：
+
+```
+00:00:00 获得锁，剩余令牌 2 。
+00:00:20 获得锁，剩余令牌 1 。
+00:00:40 获得锁，剩余令牌 0 。
+```
+
+- 那么，00:01:00 时，锁的数量会恢复，按照 Redisson 的限流器来说。
+- 如果是**严格且完整**的滑动窗口的限流器，此时在 00:01:00 剩余可获得的令牌数为 1 ，也就是说，起始点应该变成 00:00:20 。
+
+如果基于 Redis **严格且完整**的滑动窗口的限流器，可以看看艿艿在 [《精尽 Redis 面试题》](http://svip.iocoder.cn/Redis/Interview/?self) 的 [「如何使用 Redis 实现分布式限流？」](https://svip.iocoder.cn/Redisson/RateLimiter/#) ，提供基于 Redis [Zset](http://redis.cn/commands.html#sorted_set) 实现。
+
+勉勉强强，在 2019-10-02 的 22:32 写完了这篇博客，美滋滋。T T 今天的 Leetcode 忘记刷了，赶紧去刷下。
\ No newline at end of file
diff --git a/redis/04-Redisson 源码分析-可重入分布式锁 ReentrantLock.assets/01.png b/redis/04-Redisson 源码分析-可重入分布式锁 ReentrantLock.assets/01.png
new file mode 100644
index 0000000..c4ba871
Binary files /dev/null and b/redis/04-Redisson 源码分析-可重入分布式锁 ReentrantLock.assets/01.png differ
diff --git a/redis/04-Redisson 源码分析-可重入分布式锁 ReentrantLock.assets/02.png b/redis/04-Redisson 源码分析-可重入分布式锁 ReentrantLock.assets/02.png
new file mode 100644
index 0000000..6d422c7
Binary files /dev/null and b/redis/04-Redisson 源码分析-可重入分布式锁 ReentrantLock.assets/02.png differ
diff --git a/redis/04-Redisson 源码分析-可重入分布式锁 ReentrantLock.assets/a1ecddbd0ffc0da7e4f85ba6637c72ee.png b/redis/04-Redisson 源码分析-可重入分布式锁 ReentrantLock.assets/a1ecddbd0ffc0da7e4f85ba6637c72ee.png
new file mode 100644
index 0000000..047294a
Binary files /dev/null and b/redis/04-Redisson 源码分析-可重入分布式锁 ReentrantLock.assets/a1ecddbd0ffc0da7e4f85ba6637c72ee.png differ
diff --git a/redis/04-Redisson 源码分析-可重入分布式锁 ReentrantLock.assets/bbc6ac47cd74c5cd2641486415438cf5.png b/redis/04-Redisson 源码分析-可重入分布式锁 ReentrantLock.assets/bbc6ac47cd74c5cd2641486415438cf5.png
new file mode 100644
index 0000000..2f1d10d
Binary files /dev/null and b/redis/04-Redisson 源码分析-可重入分布式锁 ReentrantLock.assets/bbc6ac47cd74c5cd2641486415438cf5.png differ
diff --git a/redis/04-Redisson 源码分析-可重入分布式锁 ReentrantLock.md b/redis/04-Redisson 源码分析-可重入分布式锁 ReentrantLock.md
new file mode 100644
index 0000000..c088cce
--- /dev/null
+++ b/redis/04-Redisson 源码分析-可重入分布式锁 ReentrantLock.md	
@@ -0,0 +1,1728 @@
+# 精尽 Redisson 源码分析 —— 可重入分布式锁 ReentrantLock
+
+# 1. 概述
+
+在 Redisson 中，提供了 8 种分布锁的实现，具体我们可以在 [《Redisson 文档 —— 分布式锁和同步器》](https://github.com/redisson/redisson/wiki/8.-分布式锁和同步器) 中看到。绝大数情况下，我们使用可重入锁（Reentrant Lock）就够了，对应到就是 [`org.redisson.RedissonLock`](https://github.com/YunaiV/redisson/blob/master/redisson/src/main/java/org/redisson/RedissonLock.java) 类，具体的使用示例可以看看 [《芋道 Spring Boot Redis 入门》](http://www.iocoder.cn/Spring-Boot/Redis/?vip) 的「6.2 Redis 分布式锁」小节 。
+
+在 [《精尽 Redis 面试题》](http://svip.iocoder.cn/Redis/Interview/?self) 的问题中，我们在聊到**“如何使用 Redis 实现分布式锁？”**这个题目中，提到了需要考虑的 7 个方面，这里我们再来重复看下：
+
+- 1、正确的获得锁
+
+  > set 指令附带 nx 参数，保证有且只有一个进程获得到。
+
+- 2、正确的释放锁
+
+  > 使用 Lua 脚本，比对锁持有的是不是自己。如果是，则进行删除来释放。
+
+- 3、超时的自动释放锁
+
+  > set 指令附带 expire 参数，通过过期机制来实现超时释放。
+
+- 4、未获得到锁的等待机制
+
+  > sleep 或者基于 Redis 的订阅 Pub/Sub 机制。
+  >
+  > 一些业务场景，可能需要支持获得不到锁，直接返回 false ，不等待。
+
+- 5、【可选】锁的重入性
+
+  > 通过 ThreadLocal 记录是第几次获得相同的锁。
+  >
+  > 1）有且第一次计数为 1 && 获得锁时，才向 Redis 发起获得锁的操作。
+  > 2）有且计数为 0 && 释放锁时，才向 Redis 发起释放锁的操作。
+
+- 6、锁超时的处理
+
+  > 一般情况下，可以考虑告警 + 后台线程自动续锁的超时时间。通过这样的机制，保证有且仅有一个线程，正在持有锁。
+
+- 7、Redis 分布式锁丢失问题
+
+  > 具体看「方案二：Redlock」。
+
+RedissonLock 实现了前 6 点，而第 7 点需要通过 [`org.redisson.RedissonRedLock`](https://github.com/YunaiV/redisson/blob/master/redisson/src/main/java/org/redisson/RedissonRedLock.java) 来实现，这个话题，我们后面在聊。
+
+在开始阅读源码之前，胖友可以先看看艿艿画的 Redisson 实现分布式锁的整体流程图，以便更好的阅读源码。[猛击传送门](https://www.processon.com/view/link/5f4c871d079129356ec6f4d7)
+
+# 2. 整体一览
+
+我们来看看 Redisson 锁相关的整体类图，如下：
+
+[![RLock 接口](04-Redisson 源码分析-可重入分布式锁 ReentrantLock.assets/01.png)](http://www.iocoder.cn/images/Redis/2019_10_04/01.png)RLock 接口
+
+- [`org.redisson.api.RLockAsync`](https://github.com/YunaiV/redisson/blob/master/redisson/src/main/java/org/redisson/api/RLockAsync.java) ，定义了异步操作的接口。
+- [`org.redisson.api.RLock`](https://github.com/YunaiV/redisson/blob/master/redisson/src/main/java/org/redisson/api/RLock.java) ，继承 RLockAsync 的基础上，定义了同步操作的接口。比较有意思的是，RLock 同时实现继承 JDK 的 `java.util.concurrent.locks.Lock` 接口，从而符合 Java 的 Lock 的标准。
+- 本文的主角 RedissonLock ，实现 RLock 接口，提供可重入的分布式锁实现。
+- 其它的 RLock 实现的关系，胖友自己看图哈。
+
+RLockAsync 和 RLock 定义的接口，差别就在于同步和异步，所以我们就只看看 RLock 接口。代码如下：
+
+```
+String getName();
+
+// 锁定相关的接口方法，还有部分在 Lock 接口上
+void lockInterruptibly(long leaseTime, TimeUnit unit) throws InterruptedException;
+void lock(long leaseTime, TimeUnit unit);
+boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException;
+
+// 解锁相关的接口方法，还有部分在 Lock 接口上
+boolean forceUnlock();
+
+// 其它非关键方法
+boolean isLocked();
+boolean isHeldByThread(long threadId);
+boolean isHeldByCurrentThread();
+int getHoldCount();
+long remainTimeToLive();
+```
+
+# 3. Lua 脚本
+
+在我们看具体的代码实现，我们先来看核心的使用到的 Lua 脚本，方便我们后续更好的理解 RedissonLock 的实现。
+
+## 3.1 tryLockInnerAsync
+
+`#tryLockInnerAsync(long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command)` 方法，实现**加锁**逻辑，并且支持**可重入性**。代码如下：
+
+> FROM [《慢谈 Redis 实现分布式锁 以及 Redisson 源码解析》](https://crazyfzw.github.io/2019/04/15/distributed-locks-with-redis/)
+>
+> [![加锁流程图](04-Redisson 源码分析-可重入分布式锁 ReentrantLock.assets/a1ecddbd0ffc0da7e4f85ba6637c72ee.png)](http://static.iocoder.cn/a1ecddbd0ffc0da7e4f85ba6637c72ee)加锁流程图
+
+```
+// RedissonLock.java
+
+  1: <T> RFuture<T> tryLockInnerAsync(long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {
+  2:     internalLockLeaseTime = unit.toMillis(leaseTime);
+  3:
+  4:     return commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, command,
+  5:               "if (redis.call('exists', KEYS[1]) == 0) then " + // 情况一，当前分布式锁被未被获得
+  6:                   "redis.call('hset', KEYS[1], ARGV[2], 1); " + // 写入分布锁被 ARGV[2] 获取到了，设置数量为 1 。
+  7:                   "redis.call('pexpire', KEYS[1], ARGV[1]); " + // 设置分布式的过期时间为 ARGV[1]
+  8:                   "return nil; " + // 返回 null ，表示成功
+  9:               "end; " +
+ 10:               "if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " + // 情况二，如果当前分布锁已经被 ARGV[2] 持有
+ 11:                   "redis.call('hincrby', KEYS[1], ARGV[2], 1); " + // 写入持有计数字 + 1 。
+ 12:                   "redis.call('pexpire', KEYS[1], ARGV[1]); " + //  设置分布式的过期时间为 ARGV[1]
+ 13:                   "return nil; " + // 返回 null ，表示成功
+ 14:               "end; " +
+ 15:               "return redis.call('pttl', KEYS[1]);", // 情况三，获取不到分布式锁，则返回锁的过期时间。
+ 16:                 Collections.<Object>singletonList(getName()), // KEYS[分布式锁名]
+ 17:             internalLockLeaseTime, getLockName(threadId)); // ARGV[锁超时时间，获得的锁名]
+ 18: }
+```
+
+- `<2>` 处，根据传入的 `leaseTime` + `unit` 参数，设置到 `internalLockLeaseTime` 属性上，表示锁的时长。代码如下：
+
+  ```
+  // RedissonLock.java
+  
+  /**
+   * 锁的时长
+   */
+  protected long internalLockLeaseTime;
+  
+  public RedissonLock(CommandAsyncExecutor commandExecutor, String name) {
+      // ... 省略其它代码
+      this.internalLockLeaseTime = commandExecutor.getConnectionManager().getCfg().getLockWatchdogTimeout();
+  }
+  ```
+
+  - 默认情况下，`internalLockLeaseTime` 属性，使用 Lock 的 WatchDog 的超时时长 `30 * 1000` 毫秒。默认的值，当且仅当我们未**显示**传入锁的时长时，才有用。例如说，稍后我们会看到的 `#lock()` 等等方法中。
+  - 有一点，我们要特别注意，`internalLockLeaseTime` 是 RedissonLock 的**成员**变量，并且也未声明 `volatile` 修饰，所以跨线程使用同一个 RedissonLock 对象，可能会存在 `internalLockLeaseTime` 读取不到最新值的情况。
+
+- 还是熟悉的配方，通过 Lua 脚本实现。具体传入的参数，朋友看下第 16 和 17 行的代码，对应的 `KEYS` 和 `ARGV` 。可能有几个值胖友会有点懵逼，我们先来看看。
+
+  - `KEYS[1]` ：调用 `#getName()` 方法获得分布式锁的名字。稍后，我们会看到分布式锁在 Redis 使用是以 `KEYS[1]` 分布式锁为 KEY ，VALUE 为 HASH 类型。
+
+  - `ARGV[1]` ：锁的时长。
+
+  - `ARGV[2]` ：调用 `#getLockName(threadId)` 方法，获得的锁名。该名字，用于表示该分布式锁正在被哪个进程的线程所持有。代码如下：
+
+    ```
+    // RedissonLock.java
+    /**
+     * ID ，就是 {@link ConnectionManager#getId()}
+     */
+    final String id;
+    
+    protected String getLockName(long threadId) {
+        return id + ":" + threadId;
+    }
+    ```
+
+    - 可能描述看起来不是很好理解，我们来看一个获取到分布式锁的示例：[![分布式锁的示例](04-Redisson 源码分析-可重入分布式锁 ReentrantLock.assets/02.png)](http://www.iocoder.cn/images/Redis/2019_10_04/02.png)分布式锁的示例
+
+- 第 4 至 15 行：Lua 脚本，一共分成 3 种情况，胖友认真仔细看看，艿艿已经添加了完整的注释。
+
+不同于我们在市面上看到的 Redis 通过 SET 命令带上 NX 和 EXPIRE 的方式实现获得分布式锁，RedissonLock 提供重入性，所以需要 Lua 脚本来实现。当然，实际上，也可以通过 ThreadLocal 来实现重入性的技术，胖友可以思考一波，不懂的话星球来给艿艿留言。
+
+## 3.2 unlockInnerAsync
+
+`#unlockInnerAsync(long threadId)` 方法，实现**解锁**逻辑，并且支持**可重入性**。代码如下：
+
+> FROM [《慢谈 Redis 实现分布式锁 以及 Redisson 源码解析》](https://crazyfzw.github.io/2019/04/15/distributed-locks-with-redis/)
+>
+> [![解锁流程图](04-Redisson 源码分析-可重入分布式锁 ReentrantLock.assets/bbc6ac47cd74c5cd2641486415438cf5.png)](http://static.iocoder.cn/bbc6ac47cd74c5cd2641486415438cf5)解锁流程图
+
+```
+// RedissonLock.java
+
+  1: protected RFuture<Boolean> unlockInnerAsync(long threadId) {
+  2:     return commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, RedisCommands.EVAL_BOOLEAN,
+  3:             "if (redis.call('hexists', KEYS[1], ARGV[3]) == 0) then " + // 情况一，分布式锁未被 ARGV[3] 持有，则直接返回 null ，表示解锁失败。
+  4:                 "return nil;" +
+  5:             "end; " +
+  6:             "local counter = redis.call('hincrby', KEYS[1], ARGV[3], -1); " + // 持有锁的数量减 1 。
+  7:             "if (counter > 0) then " + // 情况二，如果后还有剩余的持有锁数量，则返回 0 ，表示解锁未完成
+  8:                 "redis.call('pexpire', KEYS[1], ARGV[2]); " + // 重新设置过期时间为 ARGV[2]
+  9:                 "return 0; " +
+ 10:             "else " + // 情况三，不存在剩余的锁数量，则返回 1 ，表示解锁成功
+ 11:                 "redis.call('del', KEYS[1]); " + // 删除对应的分布式锁对应的 KEYS[1]
+ 12:                 "redis.call('publish', KEYS[2], ARGV[1]); " + // 发布解锁事件到 KEYS[2] ，通知气他可能要获取锁的线程
+ 13:                 "return 1; "+
+ 14:             "end; " +
+ 15:             "return nil;", // 不存在这个情况。
+ 16:             Arrays.<Object>asList(getName(), getChannelName()), // KEYS[分布式锁名, 该分布式锁对应的 Channel 名]
+ 17:             LockPubSub.UNLOCK_MESSAGE, internalLockLeaseTime, getLockName(threadId)); // ARGV[解锁消息，锁超时时间，获得的锁名]
+ 18: }
+```
+
+- 具体传入的参数，朋友看下第 16 和 17 行的代码，对应的 `KEYS` 和 `ARGV` 。
+
+  - `KEYS[1]` ：调用 `#getName()` 方法获得分布式锁的名字。
+
+  - `KEYS[2]` ：调用 `#getChannelName()` 方法，该分布式锁对应的 Channel 名。因为 RedissonLock 释放锁时，会通过该 Channel 来 Publish 一条消息，通知其它可能在阻塞等待这条消息的客户端。代码如下：
+
+    ```
+    // RedissonLock.java
+    
+    String getChannelName() {
+        return prefixName("redisson_lock__channel", getName());
+    }
+    ```
+
+    - 通过 [Redis Pub/Sub](http://redis.cn/topics/pubsub.html) 机制，实现**未获得到锁的等待机制**。
+    - 每个分布式锁，对应一个其独有的 Channel 。
+
+  - `ARGV[1]` ：解锁消息 [`LockPubSub.UNLOCK_MESSAGE`](https://github.com/YunaiV/redisson/blob/master/redisson/src/main/java/org/redisson/pubsub/LockPubSub.java) 。通过收到这条消息，其它等待锁的客户端，会重新发起获得锁的请求。具体的，我们在下文来一起瞅瞅。
+
+  - `ARGV[2]` ：锁的时长。
+
+  - `ARGV[3]` ：调用 `#getLockName(threadId)` 方法，获得的锁名。
+
+- 第 3 至 15 行：Lua 脚本，还是分成 3 种情况，胖友认真仔细看看，艿艿已经添加了完整的注释。
+
+不同于我们在市面上看到的 Redis 通过 Lua 脚本的方式实现释放分布式锁，一共有 2 点：
+
+- 1、要实现**可重入性**，所以只有在计数为 0 时，才会真正释放锁。
+- 2、要实现客户端的**等待通知**，所以在释放锁时，Publish 一条释放锁的消息。
+
+## 3.3 forceUnlockAsync
+
+`#forceUnlockAsync()` 方法，实现**强制解锁**逻辑。代码如下：
+
+```
+// RedissonLock.java
+
+@Override
+public RFuture<Boolean> forceUnlockAsync() {
+    cancelExpirationRenewal(null);
+    return commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, RedisCommands.EVAL_BOOLEAN,
+            "if (redis.call('del', KEYS[1]) == 1) then " // 情况一，释放锁成功，则通过 Publish 发布释放锁的消息，并返回 1
+            + "redis.call('publish', KEYS[2], ARGV[1]); "
+            + "return 1 "
+            + "else " // 情况二，释放锁失败，因为不存在这个 KEY ，所以返回 0
+            + "return 0 "
+            + "end",
+            Arrays.<Object>asList(getName(), getChannelName()),
+            LockPubSub.UNLOCK_MESSAGE);
+}
+```
+
+- 比较简单，分成 2 种情况。胖友认真仔细看看，艿艿已经添加了完整的注释。
+
+代码处理的比较细致，Redis DEL 成功，才 PUBLISH 发布释放锁的消息，避免错误通知客户端。
+
+## 3.4 renewExpirationAsync
+
+`#renewExpirationAsync(long threadId)` 方法，实现**续锁**逻辑。可能胖友有点懵逼，至少艿艿看到这段逻辑，完全不知道为何意啊。
+
+我们先来看下 [《Redisson 文档 —— 分布式锁和同步器》](https://github.com/redisson/redisson/wiki/8.-分布式锁和同步器) ，有一段奇怪的说明：
+
+```
+RLock lock = redisson.getLock("anyLock");
+// 最常见的使用方法
+lock.lock();
+```
+
+> 大家都知道，如果负责储存这个分布式锁的Redisson节点宕机以后，而且这个锁正好处于锁住的状态时，这个锁会出现锁死的状态。为了避免这种情况的发生，Redisson内部提供了一个监控锁的看门狗，它的作用是在Redisson实例被关闭前，不断的延长锁的有效期。默认情况下，看门狗的检查锁的超时时间是30秒钟，也可以通过修改 [Config.lockWatchdogTimeout](https://github.com/redisson/redisson/wiki/2.-配置方法#lockwatchdogtimeout监控锁的看门狗超时单位毫秒) 来另行指定。
+
+在使用 `RedissonLock#lock()` 方法，我们要求**持续**持有锁，直到**手动**释放。但是实际上，我们有一个隐藏条件，如果 Java 进程挂掉时，需要**自动**释放。那么，如果实现 `RedissonLock#lock()` 时，设置过期 Redis 为无限大，或者不过期都不合适。那么 RedissonLock 是怎么实现的呢？RedissonLock 先获得一个 `internalLockLeaseTime` 的分布式锁，然后每 `internalLockLeaseTime / 3` 时间，定时调用 `#renewExpirationAsync(long threadId)` 方法，进行续租。这样，在 Java 进程异常 Crash 掉后，能够保证最多 `internalLockLeaseTime` 时间后，分布式锁自动释放。
+
+略骚略巧妙~不过为了实现这样的功能，RedissonLock 的整体逻辑，又复杂了一丢丢。
+
+下面，还是先让我们看下具体的 `#renewExpirationAsync(long threadId)` 方法的代码，如下：
+
+```
+// RedissonLock.java
+
+protected RFuture<Boolean> renewExpirationAsync(long threadId) {
+    return commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, RedisCommands.EVAL_BOOLEAN,
+            "if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " + // 情况一，如果持有锁，则重新设置过期时间为 ARGV[1] internalLockLeaseTime ，并返回 1 续租成功。
+                "redis.call('pexpire', KEYS[1], ARGV[1]); " +
+                "return 1; " +
+            "end; " +
+            "return 0;", // 情况二，未吃货有，返回 0 续租失败。
+        Collections.<Object>singletonList(getName()),
+        internalLockLeaseTime, getLockName(threadId));
+}
+```
+
+- 比较简单，分成 2 种情况。胖友认真仔细看看，艿艿已经添加了完整的注释。
+
+------
+
+至此，我们看完了 Lua 脚本部分，其实基本也大体知道 RedissonLock 是如何实现加锁、接锁的逻辑。但是，复杂的逻辑，还在下面，胖友请保持好耐心，开启我们的高能时刻。
+
+> 艿艿：T T RedissonLock 好多重载的方法，文章小标题，都不造杂取了。最关键的是，可能胖友会被绕进去。
+
+# 4. LockPubSub
+
+在开始研究真正的加锁和解锁的调用之前，我们先看看和其相关的客户端订阅解锁消息，从而实现在持有锁的客户端释放锁时，等待锁的客户端能够快速的去调用加锁逻辑。
+
+> 艿艿：😭 整个调用栈太深的，艿艿只好先写它，就当卖了一个关子，哈哈哈。
+
+[`org.redisson.pubsub.LockPubSub`](https://github.com/YunaiV/redisson/blob/master/redisson/src/main/java/org/redisson/pubsub/LockPubSub.java) ，继承 PublishSubscribe 抽象类，实现 Lock 相关消息的订阅。代码如下：
+
+```
+// LockPubSub.java
+
+public class LockPubSub extends PublishSubscribe<RedissonLockEntry> {
+
+    /**
+     * 锁释放的消息
+     */
+    public static final Long UNLOCK_MESSAGE = 0L;
+    /**
+     * 读锁释放的消息
+     */
+    public static final Long READ_UNLOCK_MESSAGE = 1L;
+
+    public LockPubSub(PublishSubscribeService service) {
+        super(service);
+    }
+
+    @Override
+    protected RedissonLockEntry createEntry(RPromise<RedissonLockEntry> newPromise) {
+        return new RedissonLockEntry(newPromise);
+    }
+
+    @Override
+    protected void onMessage(RedissonLockEntry value, Long message) {
+        if (message.equals(UNLOCK_MESSAGE)) {
+            // 回调监听器
+            Runnable runnableToExecute = value.getListeners().poll();
+            if (runnableToExecute != null) {
+                runnableToExecute.run();
+            }
+
+            // 通过信号量，通知阻塞等待的线程
+            value.getLatch().release();
+        } else if (message.equals(READ_UNLOCK_MESSAGE)) {
+            while (true) {
+                Runnable runnableToExecute = value.getListeners().poll();
+                if (runnableToExecute == null) {
+                    break;
+                }
+                runnableToExecute.run();
+            }
+
+            value.getLatch().release(value.getLatch().getQueueLength());
+        }
+    }
+
+}
+```
+
+- 在 `#createEntry(RPromise<RedissonLockEntry> newPromise)` 方法，会创建 [`org.redisson.RedissonLockEntry`](https://github.com/YunaiV/redisson/blob/master/redisson/src/main/java/org/redisson/RedissonLockEntry.java) 对象。代码如下：
+
+  ```
+  // RedissonLockEntry.java
+  
+  public class RedissonLockEntry implements PubSubEntry<RedissonLockEntry> {
+  
+      /**
+       * 计数器
+       *
+       * 每次发起订阅，则计数器 + 1
+       * 每次取消订阅，则计数器 - 1 。当减少到 0 时，才正常取消订阅。
+       */
+      private int counter;
+  
+      /**
+       * 信号量，用于实现 RedissonLock 阻塞等待的通知
+       */
+      private final Semaphore latch;
+      private final RPromise<RedissonLockEntry> promise;
+      /**
+       * 监听器们
+       */
+      private final ConcurrentLinkedQueue<Runnable> listeners = new ConcurrentLinkedQueue<Runnable>();
+  
+      public RedissonLockEntry(RPromise<RedissonLockEntry> promise) {
+          super();
+          this.latch = new Semaphore(0);
+          this.promise = promise;
+      }
+  
+      @Override
+      public void aquire() {
+          counter++;
+      }
+  
+      @Override
+      public int release() {
+          return --counter;
+      }
+  
+      @Override
+      public RPromise<RedissonLockEntry> getPromise() {
+          return promise;
+      }
+  
+      public void addListener(Runnable listener) {
+          listeners.add(listener);
+      }
+  
+      public boolean removeListener(Runnable listener) {
+          return listeners.remove(listener);
+      }
+  
+      public ConcurrentLinkedQueue<Runnable> getListeners() {
+          return listeners;
+      }
+  
+      public Semaphore getLatch() {
+          return latch;
+      }
+  
+  }
+  ```
+
+  - 虽然代码比较多，我们重点来看 `latch` 和 `listeners` 属性。
+  - `latch` 属性：信号量，用于实现 RedissonLock 阻塞等待的通知。在我们下面看到**同步**加锁的逻辑，会看到通过它来实现阻塞等待。
+  - `listeners` 属性：监听器，实现订阅到锁的释放消息，从而再次发起获得锁。当然，这里的 Runnable 对象肯定无法体现，具体我们后面看看 `#tryLockAsync(AtomicLong time, long leaseTime, TimeUnit unit, RFuture<RedissonLockEntry> subscribeFuture, RPromise<Boolean> result, long currentThreadId)` 或者 `#lockAsync(long leaseTime, TimeUnit unit, RFuture<RedissonLockEntry> subscribeFuture, RPromise<Void> result, long currentThreadId)` 方法，就可以看到方法内部会创建具体的 Runnable 实现类，实现再次发起获得锁的逻辑。
+
+- 在 `#onMessage(RedissonLockEntry value, Long message)` 方法中，在接收到释放锁的消息后，会执行 `listeners` 的回调，以及 `latch` 的时候放。
+
+当然，单单看 LockPubSub 类，胖友可能会感到懵逼，保持耐心，继续向下。LockPubSub 更多的是实现了锁释放消息的监听，以及回调监听器，释放信号量。**真正的逻辑，还是要看监听器的逻辑，以及 RedissonLock 是怎么实现信号量的**。
+
+另外，在 RedissonLock 中，提供如下几个方法，发起和取消订阅。代码如下：
+
+```
+// RedissonLock.java
+
+/**
+ * Sub Entry 名字
+ */
+final String entryName;
+
+protected final LockPubSub pubSub;
+
+public RedissonLock(CommandAsyncExecutor commandExecutor, String name) {
+    // ... 省略其他无关
+    this.entryName = id + ":" + name;
+    this.pubSub = commandExecutor.getConnectionManager().getSubscribeService().getLockPubSub();
+}
+
+/**
+ * 获得线程对应的 RedissonLockEntry 对象
+ *
+ * @param threadId 线程编号
+ * @return RedissonLockEntry 对象
+ */
+protected RedissonLockEntry getEntry(long threadId) {
+    return pubSub.getEntry(getEntryName());
+}
+
+/**
+ * 异步发起订阅
+ *
+ * @param threadId 线程编号
+ * @return RFuture 对象
+ */
+protected RFuture<RedissonLockEntry> subscribe(long threadId) {
+    return pubSub.subscribe(getEntryName(), getChannelName());
+}
+
+/**
+ * 异步取消订阅
+ *
+ * @param future RFuture 对象
+ * @param threadId 线程编号
+ */
+protected void unsubscribe(RFuture<RedissonLockEntry> future, long threadId) {
+    pubSub.unsubscribe(future.getNow(), getEntryName(), getChannelName());
+}
+```
+
+# 5. tryLockAsync
+
+> 艿艿：重点开始了，打起精神。
+
+`#tryLockAsync(long waitTime, TimeUnit unit)` 方法，异步加锁，并返回是否成功。代码如下：
+
+```
+// RedissonLock.java
+
+@Override
+public RFuture<Boolean> tryLockAsync(long waitTime, TimeUnit unit) {
+    return tryLockAsync(waitTime, -1, unit);
+}
+
+@Override
+public RFuture<Boolean> tryLockAsync(long waitTime, long leaseTime, TimeUnit unit) {
+    // 获得线程编号
+    long currentThreadId = Thread.currentThread().getId();
+    // 执行锁
+    return tryLockAsync(waitTime, leaseTime, unit, currentThreadId);
+}
+```
+
+- 最终都调用 `#tryLockAsync(long waitTime, long leaseTime, TimeUnit unit, long currentThreadId)` 方法，真正实现异步加锁的逻辑。
+
+`#tryLockAsync(long waitTime, long leaseTime, TimeUnit unit, long currentThreadId)` 方法，代码如下：
+
+```
+// RedissonLock.java
+
+  1: @Override
+  2: public RFuture<Boolean> tryLockAsync(long waitTime, long leaseTime, TimeUnit unit, long currentThreadId) {
+  3:     // 创建 RPromise 对象，用于通知结果
+  4:     RPromise<Boolean> result = new RedissonPromise<Boolean>();
+  5:
+  6:     // 表示剩余的等待获得锁的时间
+  7:     AtomicLong time = new AtomicLong(unit.toMillis(waitTime));
+  8:     // 记录当前时间
+  9:     long currentTime = System.currentTimeMillis();
+ 10:     // 执行异步获得锁
+ 11:     RFuture<Long> ttlFuture = tryAcquireAsync(leaseTime, unit, currentThreadId);
+ 12:     ttlFuture.onComplete((ttl, e) -> {
+ 13:         // 如果发生异常，则通过 result 通知异常
+ 14:         if (e != null) {
+ 15:             result.tryFailure(e);
+ 16:             return;
+ 17:         }
+ 18:
+ 19:         // lock acquired
+ 20:         // 如果获得到锁，则通过 result 通知获得锁成功
+ 21:         if (ttl == null) {
+ 22:             if (!result.trySuccess(true)) { // 如果处理 result 通知对结果返回 false ，意味着需要异常释放锁
+ 23:                 unlockAsync(currentThreadId);
+ 24:             }
+ 25:             return;
+ 26:         }
+ 27:
+ 28:         // 减掉已经等待的时间
+ 29:         long el = System.currentTimeMillis() - currentTime;
+ 30:         time.addAndGet(-el);
+ 31:
+ 32:         // 如果无剩余等待的时间，则通过 result 通知获得锁失败
+ 33:         if (time.get() <= 0) {
+ 34:             trySuccessFalse(currentThreadId, result);
+ 35:             return;
+ 36:         }
+ 37:
+ 38:         // 记录新的当前时间
+ 39:         long current = System.currentTimeMillis();
+ 40:         // 记录下面的 future 的指向
+ 41:         AtomicReference<Timeout> futureRef = new AtomicReference<Timeout>();
+ 42:
+ 43:         // 创建 SUBSCRIBE 订阅的 Future
+ 44:         RFuture<RedissonLockEntry> subscribeFuture = subscribe(currentThreadId);
+ 45:         subscribeFuture.onComplete((r, ex) -> {
+ 46:             // 如果发生异常，则通过 result 通知异常
+ 47:             if (ex != null) {
+ 48:                 result.tryFailure(ex);
+ 49:                 return;
+ 50:             }
+ 51:
+ 52:             // 如果创建定时任务 Future scheduledFuture，则进行取消
+ 53:             if (futureRef.get() != null) {
+ 54:                 futureRef.get().cancel();
+ 55:             }
+ 56:
+ 57:             // 减掉已经等待的时间
+ 58:             long elapsed = System.currentTimeMillis() - current;
+ 59:             time.addAndGet(-elapsed);
+ 60:
+ 61:             // 再次执行异步获得锁
+ 62:             tryLockAsync(time, leaseTime, unit, subscribeFuture, result, currentThreadId);
+ 63:         });
+ 64:
+ 65:         // 如果创建 SUBSCRIBE 订阅的 Future 未完成，创建定时任务 Future scheduledFuture 。
+ 66:         if (!subscribeFuture.isDone()) {
+ 67:             Timeout scheduledFuture = commandExecutor.getConnectionManager().newTimeout(new TimerTask() {
+ 68:                 @Override
+ 69:                 public void run(Timeout timeout) throws Exception {
+ 70:                     // 如果创建 SUBSCRIBE 订阅的 Future 未完成
+ 71:                     if (!subscribeFuture.isDone()) {
+ 72:                         // 进行取消 subscribeFuture
+ 73:                         subscribeFuture.cancel(false);
+ 74:                         // 通过 result 通知获得锁失败
+ 75:                         trySuccessFalse(currentThreadId, result);
+ 76:                     }
+ 77:                 }
+ 78:             }, time.get(), TimeUnit.MILLISECONDS); // 延迟 time 秒后执行
+ 79:             // 记录 futureRef 执行 scheduledFuture
+ 80:             futureRef.set(scheduledFuture);
+ 81:         }
+ 82:     });
+ 83:
+ 84:     return result;
+ 85: }
+```
+
+- 整体逻辑是，获得分布锁。如果获取失败，则发起 Redis Pub/Sub 订阅，等待释放锁的消息，从而再次发起获得分布式锁。
+
+- 第 11 行：调用 `#tryAcquireAsync(long leaseTime, TimeUnit unit, long threadId)` 方法，执行异步获得锁。详细解析，胖友先跳到 [「5.1 tryAcquireAsync」](https://svip.iocoder.cn/Redisson/ReentrantLock/#) 中。
+
+- 继续开始我们“漫长”的回调之旅。其实也比较容易懂，走起~
+
+- 第 13 至 17 行：如果发生异常，则通过 `result` 通知异常。
+
+- 第 19 至 26 行：如果 `ttl` 为空，说明获得到锁了，则通过 `result` 通知获得锁成功。这里，在第 23 至 24 行有个小细节，胖友自己看下注释。
+
+- 第 41 行：声明 `futureRef` 变量，用于设置第 65 至 81 行创建的定时任务。
+
+- 第 65 至 82 行：如果创建 SUBSCRIBE 订阅的 Future `subscribeFuture` 未完成，创建定时任务 Future `scheduledFuture` 。因为 `subscribeFuture` 是异步的，而存在一个情况，可能 `subscribeFuture` 未完成时，等待获得锁已经超时，所以通过 `scheduledFuture` 来实现超时通知。
+
+  - 第 80 行：记录 `futureRef` 为 `scheduledFuture` 。
+
+  - 第 71 行：兜底判断 `subscribeFuture` 未完成。
+
+  - 第 73 行：进行取消 `subscribeFuture` 。
+
+  - 第 75 行：调用 `#trySuccessFalse(long currentThreadId, RPromise<Boolean> result)` 方法，通知获得锁失败。代码如下：
+
+    ```
+    // RedissonLock.java
+    
+    protected RFuture<Void> acquireFailedAsync(long threadId) {
+        return RedissonPromise.newSucceededFuture(null);
+    }
+    
+    private void trySuccessFalse(long currentThreadId, RPromise<Boolean> result) {
+        acquireFailedAsync(currentThreadId).onComplete((res, e) -> {
+            if (e == null) { // 通知获得锁失败
+                result.trySuccess(false);
+            } else { // 通知异常
+                result.tryFailure(e);
+            }
+        });
+    }
+    ```
+
+    - x
+
+- 第 43 至 63 行：创建 SUBSCRIBE 订阅的 Future `subscribeFuture` 。通过订阅释放锁的消息，从而实现等待锁释放的客户端，快速抢占加锁。
+
+  - 第 46 至 50 行：如果发生异常，则通过 `result` 通知异常。
+
+  - 第 52 至 55 行：如果创建定时任务 Future `scheduledFuture`，则进行取消。
+
+  - 第 57 至 59 行：减掉已经等待的时间。
+
+  - 第 62 行：调用 `#tryLockAsync(AtomicLong time, long leaseTime, TimeUnit unit, RFuture<RedissonLockEntry> subscribeFuture, RPromise<Boolean> result, long currentThreadId` 方法，再次执行异步获得锁。详细解析，见 [「5.2 更强的 tryLockAsync」](https://svip.iocoder.cn/Redisson/ReentrantLock/#) 小节。
+
+    > 艿艿：特喵的，又是一个 tryLockAsync 重载的方法，我已经瞎取标题了。深呼吸，继续！
+
+感叹，想要写好全异步的代码，实际是非常困难的，所以艿艿的感受，Spring Webflux 反应式框架，想要推广在编写业务逻辑，基本可能性是为零。当然，Webflux 乃至反应式编程，更加适合推广在基础组件中。
+
+## 5.1 tryAcquireAsync
+
+> 艿艿：看完这个方法，就跳回去哈。MMP 整个调用链，真长，大几百行代码。
+
+`#tryAcquireAsync(long leaseTime, TimeUnit unit, long threadId)` 方法，执行异步获得锁。代码如下：
+
+```
+// RedissonLock.java
+
+private <T> RFuture<Long> tryAcquireAsync(long leaseTime, TimeUnit unit, long threadId) {
+    // <1> 情况一，如果锁有时长，则直接获得分布式锁
+    if (leaseTime != -1) {
+        return tryLockInnerAsync(leaseTime, unit, threadId, RedisCommands.EVAL_LONG);
+    }
+
+    // <2> 情况二，如果锁无时长，则先获得 Lock WatchDog 的锁超时时长
+    RFuture<Long> ttlRemainingFuture = tryLockInnerAsync(commandExecutor.getConnectionManager().getCfg().getLockWatchdogTimeout(), TimeUnit.MILLISECONDS, threadId, RedisCommands.EVAL_LONG);
+    ttlRemainingFuture.onComplete((ttlRemaining, e) -> {
+        // 如果发生异常，则直接返回
+        if (e != null) {
+            return;
+        }
+
+        // lock acquired
+        // 如果获得到锁，则创建定时任务，定时续锁
+        if (ttlRemaining == null) {
+            scheduleExpirationRenewal(threadId);
+        }
+    });
+    return ttlRemainingFuture;
+}
+```
+
+- 一共分成两种情况，是否锁有时长。
+- `<1>` 处，`leaseTime != -1` ，意味着锁设置了时长，则调用 [「3.1 `#tryLockInnerAsync(long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand command)`」](https://svip.iocoder.cn/Redisson/ReentrantLock/#) 方法，直接获得分布式锁。
+- `<2>` 处，锁未设置了时长，所以先调用 [「3.1 `#tryLockInnerAsync(long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand command)`」](https://svip.iocoder.cn/Redisson/ReentrantLock/#) 方法，获得 **Lock WatchDog 的锁超时时长**的分布式锁，然后在回调中，再调用 `#scheduleExpirationRenewal(long threadId)` 方法，创建定时任务，定时调用 [「3.4 renewExpirationAsync」](https://svip.iocoder.cn/Redisson/ReentrantLock/#) **续锁**。详细解析，见 TODO 。
+
+## 5.2 更强的 tryLockAsync
+
+`#tryLockAsync(AtomicLong time, long leaseTime, TimeUnit unit, RFuture<RedissonLockEntry> subscribeFuture, RPromise<Boolean> result, long currentThreadId)` 方法，**更强**的异步加锁。主要强在 2 点：
+
+- 1、增加监听锁释放的消息的监听器，从而实现等待锁的客户端快速抢占锁的逻辑。
+- 2、增加锁超时自动释放，没有锁释放消息的处理。
+
+整体代码如下：
+
+```
+// RedissonLock.java
+
+  1: private void tryLockAsync(AtomicLong time, long leaseTime, TimeUnit unit, RFuture<RedissonLockEntry> subscribeFuture, RPromise<Boolean> result, long currentThreadId) {
+  2:     // 如果 result 已经完成，则直接返回，并取消订阅
+  3:     if (result.isDone()) {
+  4:         unsubscribe(subscribeFuture, currentThreadId);
+  5:         return;
+  6:     }
+  7:
+  8:     // 如果剩余时间 time 小于 0 ，说明等待超时，则取消订阅，并通过 result 通知失败
+  9:     if (time.get() <= 0) {
+ 10:         unsubscribe(subscribeFuture, currentThreadId);
+ 11:         trySuccessFalse(currentThreadId, result);
+ 12:         return;
+ 13:     }
+ 14:
+ 15:     // 记录当前时间
+ 16:     long curr = System.currentTimeMillis();
+ 17:     // 获得分布式锁
+ 18:     RFuture<Long> ttlFuture = tryAcquireAsync(leaseTime, unit, currentThreadId);
+ 19:     ttlFuture.onComplete((ttl, e) -> {
+ 20:             // 如果发生异常，则取消订阅，并通过 result 通知异常
+ 21:             if (e != null) {
+ 22:                 unsubscribe(subscribeFuture, currentThreadId);
+ 23:                 result.tryFailure(e);
+ 24:                 return;
+ 25:             }
+ 26:
+ 27:             // lock acquired
+ 28:             // 如果获得到锁，则取消订阅，并通过 result 通知获得锁成功
+ 29:             if (ttl == null) {
+ 30:                 unsubscribe(subscribeFuture, currentThreadId);
+ 31:                 if (!result.trySuccess(true)) {
+ 32:                     unlockAsync(currentThreadId);
+ 33:                 }
+ 34:                 return;
+ 35:             }
+ 36:
+ 37:             // 减掉已经等待的时间
+ 38:             long el = System.currentTimeMillis() - curr;
+ 39:             time.addAndGet(-el);
+ 40:
+ 41:             // 如果无剩余等待的时间，则取消订阅，并通过 result 通知获得锁失败
+ 42:             if (time.get() <= 0) {
+ 43:                 unsubscribe(subscribeFuture, currentThreadId);
+ 44:                 trySuccessFalse(currentThreadId, result);
+ 45:                 return;
+ 46:             }
+ 47:
+ 48:             // waiting for message
+ 49:             // 记录新的当前时间
+ 50:             long current = System.currentTimeMillis();
+ 51:             // 获得当前线程对应的 RedissonLockEntry 对象
+ 52:             RedissonLockEntry entry = getEntry(currentThreadId);
+ 53:             // 尝试获得 entry 中的信号量，如果获得成功，说明 SUBSCRIBE 已经收到释放锁的消息，则直接立马再次去获得锁。
+ 54:             if (entry.getLatch().tryAcquire()) {
+ 55:                 tryLockAsync(time, leaseTime, unit, subscribeFuture, result, currentThreadId);
+ 56:             } else {
+ 57:                 // 创建 AtomicBoolean 变量 executed ，用于标记下面创建的 listener 是否执行。
+ 58:                 AtomicBoolean executed = new AtomicBoolean();
+ 59:                 // 创建 AtomicReference 对象，用于指向定时任务
+ 60:                 AtomicReference<Timeout> futureRef = new AtomicReference<Timeout>();
+ 61:
+ 62:                 // 创建监听器 listener ，用于在 RedissonLockEntry 的回调，就是我们看到的 PublishSubscribe 监听到释放锁的消息，进行回调。
+ 63:                 Runnable listener = () -> {
+ 64:                     // 标记已经执行
+ 65:                     executed.set(true);
+ 66:                     // 如果有定时任务的 Future ，则进行取消
+ 67:                     if (futureRef.get() != null) {
+ 68:                         futureRef.get().cancel();
+ 69:                     }
+ 70:
+ 71:                     // 减掉已经等待的时间
+ 72:                     long elapsed = System.currentTimeMillis() - current;
+ 73:                     time.addAndGet(-elapsed);
+ 74:
+ 75:                     // 再次获得分布式锁
+ 76:                     tryLockAsync(time, leaseTime, unit, subscribeFuture, result, currentThreadId);
+ 77:                 };
+ 78:                 // 添加 listener 到 RedissonLockEntry 中
+ 79:                 entry.addListener(listener);
+ 80:
+ 81:                 // 下面，会创建一个定时任务。因为极端情况下，可能不存在释放锁的消息，例如说锁自动超时释放，所以需要改定时任务，在获得到锁的超时后，主动去抢下。
+ 82:                 long t = time.get();
+ 83:                 if (ttl >= 0 && ttl < time.get()) { // 如果剩余时间小于锁的超时时间，则使用剩余时间。
+ 84:                     t = ttl;
+ 85:                 }
+ 86:                 // 如果 listener 未执行
+ 87:                 if (!executed.get()) {
+ 88:                     Timeout scheduledFuture = commandExecutor.getConnectionManager().newTimeout(new TimerTask() {
+ 89:                         @Override
+ 90:                         public void run(Timeout timeout) throws Exception {
+ 91:                             // 移除 listener 从 RedissonLockEntry 中
+ 92:                             if (entry.removeListener(listener)) {
+ 93:                                 // 减掉已经等待的时间
+ 94:                                 long elapsed = System.currentTimeMillis() - current;
+ 95:                                 time.addAndGet(-elapsed);
+ 96:
+ 97:                                 // 再次获得分布式锁
+ 98:                                 tryLockAsync(time, leaseTime, unit, subscribeFuture, result, currentThreadId);
+ 99:                             }
+100:                         }
+101:                     }, t, TimeUnit.MILLISECONDS);
+102:                     // 记录 futureRef 执行 scheduledFuture
+103:                     futureRef.set(scheduledFuture);
+104:                 }
+105:             }
+106:     });
+107: }
+```
+
+- 第 2 至 46 行：和 [「5. tryLockAsync」](https://svip.iocoder.cn/Redisson/ReentrantLock/#) 基本一致，就不重复哔哔了。
+
+- 第 52 行：调用 `#getEntry(long threadId)` 方法，获得当前线程对应的 RedissonLockEntry 对象。此处有点“失忆”的胖友，看看 [「4. LockPubSub」](https://svip.iocoder.cn/Redisson/ReentrantLock/#) 的结尾。
+
+- 第 53 至 55 行：尝试获得 `entry` 中的信号量，如果获得成功，说明 SUBSCRIBE 已经收到释放锁的消息，则调用 [「5.2 `##tryLockAsync(AtomicLong time, long leaseTime, TimeUnit unit, RFuture subscribeFuture, RPromise result, long currentThreadId)`」](https://svip.iocoder.cn/Redisson/ReentrantLock/#) 方法，直接立马再次去获得锁。
+
+- 第 58 行：创建 AtomicBoolean 变量 `executed` ，用于标记下面创建的 `listener` 是否执行。
+
+- 第 60 行：声明
+
+   
+
+  ```
+  futureRef
+  ```
+
+   
+
+  变量，用于设置第 87 至 104 行创建的定时任务。
+
+  因为极端情况下，可能不存在释放锁的消息，例如说锁自动超时释放，所以需要改定时任务，在获得到锁的超时后，主动去抢下。
+
+  - 第 82 至 85 行：计算定时任务的延迟时间时间。如果剩余时间小于锁的超时时间，则使用剩余时间。
+  - 第 87 行：通过 `executed` 变量，判断 `listener` 未执行。
+  - 第 103 行： 记录 `futureRef` 为 `scheduledFuture` 。
+  - 第 92 行：移除 `listener` 从 RedissonLockEntry 中。避免，可能存在的并发执行。
+  - 第 98 行：调用 [「5.2 `##tryLockAsync(AtomicLong time, long leaseTime, TimeUnit unit, RFuture subscribeFuture, RPromise result, long currentThreadId)`」](https://svip.iocoder.cn/Redisson/ReentrantLock/#) 方法，再次去获得锁。
+  - 这个定时任务，真的处理的是细节中的细节。之前思考获得分布式失败客户端的等待通知，只考虑了 Redis Pub/Sub 机制来实现，没有想到如果没有 PUBLISH 消息的场景。这块的逻辑，算是看 RedissonLock 最大的收获吧。
+
+- 第 62 至 79 行：创建监听器
+
+   
+
+  ```
+  listener
+  ```
+
+   
+
+  ，用于在 RedissonLockEntry 的回调，就是我们看到的 PublishSubscribe 监听到释放锁的消息，进行回调。
+
+  - 第 79 行：添加 `listener` 到 RedissonLockEntry 中。😈 如果胖友又“失忆”了，调回到 [「4. LockPubSub」](https://svip.iocoder.cn/Redisson/ReentrantLock/#) 再瞅瞅。
+  - 第 65 行：通过 `executed` 标记已经执行。
+  - 第 66 至 69 行：如果有定时任务的 Future ，则进行取消。
+  - 第 71 至 74 行：减掉已经等待的时间。
+  - 第 76 行：调用 [「5.2 `##tryLockAsync(AtomicLong time, long leaseTime, TimeUnit unit, RFuture subscribeFuture, RPromise result, long currentThreadId)`」](https://svip.iocoder.cn/Redisson/ReentrantLock/#) 方法，再次去获得锁。
+
+------
+
+至此，RedissonLock 加锁的逻辑我们已经全部看完。如果觉得略感迷糊的胖友，可以多多调试下。因为艿艿有点偷懒，未画一些图来辅助胖友理解，所以胖友可以自己画一画，嘿嘿。
+
+## 5.3 遗漏的 tryLockAsync
+
+还有两个重载的 `#tryLockAsync(...)` 方法，它们是未设置锁定时长的两个。代码如下：
+
+```
+// RedissonLock.java
+
+@Override
+public RFuture<Boolean> tryLockAsync() {
+    return tryLockAsync(Thread.currentThread().getId());
+}
+
+@Override
+public RFuture<Boolean> tryLockAsync(long threadId) {
+    return tryAcquireOnceAsync(-1, null, threadId);
+}
+```
+
+- 最终都调用 `#tryAcquireOnceAsync(long leaseTime, TimeUnit unit, long threadId)` 方法，真正实现异步加锁的逻辑。
+
+`#tryAcquireOnceAsync(long leaseTime, TimeUnit unit, long threadId)` 方法，真正实现异步加锁的逻辑。代码如下：
+
+```
+// RedissonLock.java
+
+private RFuture<Boolean> tryAcquireOnceAsync(long leaseTime, TimeUnit unit, long threadId) {
+    // 情况一，如果锁有时长，则直接获得分布式锁
+    if (leaseTime != -1) {
+        return tryLockInnerAsync(leaseTime, unit, threadId, RedisCommands.EVAL_NULL_BOOLEAN);
+    }
+
+    // 情况二，如果锁无时长，则先获得 Lock WatchDog 的锁超时时长
+    RFuture<Boolean> ttlRemainingFuture = tryLockInnerAsync(commandExecutor.getConnectionManager().getCfg().getLockWatchdogTimeout(), TimeUnit.MILLISECONDS, threadId, RedisCommands.EVAL_NULL_BOOLEAN);
+    ttlRemainingFuture.onComplete((ttlRemaining, e) -> {
+        // 如果发生异常，则直接返回
+        if (e != null) {
+            return;
+        }
+
+        // lock acquired
+        // 如果获得到锁，则创建定时任务，定时续锁
+        if (ttlRemaining) {
+            scheduleExpirationRenewal(threadId);
+        }
+    });
+    return ttlRemainingFuture;
+}
+```
+
+- 看到这个方法，是不是发现很熟悉，和 [「5.1 tryAcquireAsync」](https://svip.iocoder.cn/Redisson/ReentrantLock/#) 基本一模一样。差别在于它的返回的结果是 `RFuture<Boolean>` 。
+- 有一点要特别注意，因为本小节我们看到的两个 `#tryLockAsync(...)` 方法，是尝试去加锁。如果加锁失败，则返回 `false` 即可，所以不会像我们在 [「5.1 tryLockAsync」](https://svip.iocoder.cn/Redisson/ReentrantLock/#) 方法，无限重试直到等待超时（超过 `waitTime`）。
+
+# 6. tryLock
+
+> 艿艿：本小节和 [「5. tryLockAsync」](https://svip.iocoder.cn/Redisson/ReentrantLock/#) 相对，为**同步**加锁。扶你起来，胖友还可以继续怼源码。
+
+`#tryLock(long waitTime, long leaseTime, TimeUnit unit)` 方法，同步加锁，并返回是否成功。。代码如下：
+
+```
+// RedissonLock.java
+
+    @Override
+    public boolean tryLock(long waitTime, TimeUnit unit) throws InterruptedException {
+        return tryLock(waitTime, -1, unit);
+    }
+
+  1: @Override
+  2: public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException {
+  3:     long time = unit.toMillis(waitTime);
+  4:     long current = System.currentTimeMillis();
+  5:     long threadId = Thread.currentThread().getId();
+  6:     // 同步获加锁
+  7:     Long ttl = tryAcquire(leaseTime, unit, threadId);
+  8:     // lock acquired
+  9:     // 加锁成功，直接返回 true 加锁成功
+ 10:     if (ttl == null) {
+ 11:         return true;
+ 12:     }
+ 13:
+ 14:     // 减掉已经等待的时间
+ 15:     time -= System.currentTimeMillis() - current;
+ 16:     // 如果无剩余等待的时间，则返回 false 加锁失败
+ 17:     if (time <= 0) {
+ 18:         acquireFailed(threadId);
+ 19:         return false;
+ 20:     }
+ 21:
+ 22:     // 记录新的当前时间
+ 23:     current = System.currentTimeMillis();
+ 24:     // 创建 SUBSCRIBE 订阅的 Future
+ 25:     RFuture<RedissonLockEntry> subscribeFuture = subscribe(threadId);
+ 26:     // 阻塞等待订阅发起成功
+ 27:     if (!await(subscribeFuture, time, TimeUnit.MILLISECONDS)) {
+ 28:         // 进入到此处，说明阻塞等待发起订阅超时
+ 29:         // 取消 SUBSCRIBE 订阅
+ 30:         if (!subscribeFuture.cancel(false)) {
+ 31:             // 进入到此处，说明取消发起订阅失败，则通过设置回调，在启发订阅完成后，回调取消 SUBSCRIBE 订阅
+ 32:             subscribeFuture.onComplete((res, e) -> {
+ 33:                 if (e == null) {
+ 34:                     unsubscribe(subscribeFuture, threadId);
+ 35:                 }
+ 36:             });
+ 37:         }
+ 38:         // 等待超时，则返回 false 加锁失败
+ 39:         acquireFailed(threadId);
+ 40:         return false;
+ 41:     }
+ 42:
+ 43:     try {
+ 44:         // 减掉已经等待的时间
+ 45:         time -= System.currentTimeMillis() - current;
+ 46:         // 如果无剩余等待的时间，则返回 false 加锁失败
+ 47:         if (time <= 0) {
+ 48:             acquireFailed(threadId);
+ 49:             return false;
+ 50:         }
+ 51:
+ 52:         while (true) {
+ 53:             // 记录新的当前时间
+ 54:             long currentTime = System.currentTimeMillis();
+ 55:             // 同步获加锁
+ 56:             ttl = tryAcquire(leaseTime, unit, threadId);
+ 57:             // lock acquired
+ 58:             // 加锁成功，直接返回 true 加锁成功
+ 59:             if (ttl == null) {
+ 60:                 return true;
+ 61:             }
+ 62:
+ 63:             // 减掉已经等待的时间
+ 64:             time -= System.currentTimeMillis() - currentTime;
+ 65:             // 如果无剩余等待的时间，则返回 false 加锁失败
+ 66:             if (time <= 0) {
+ 67:                 acquireFailed(threadId);
+ 68:                 return false;
+ 69:             }
+ 70:
+ 71:             // waiting for message
+ 72:             // 记录新的当前时间
+ 73:             currentTime = System.currentTimeMillis();
+ 74:
+ 75:             // 通过 RedissonLockEntry 的信号量，阻塞等待锁的释放消息，或者 ttl/time 超时（例如说，锁的自动超时释放）
+ 76:             if (ttl >= 0 && ttl < time) {
+ 77:                 getEntry(threadId).getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS);
+ 78:             } else {
+ 79:                 getEntry(threadId).getLatch().tryAcquire(time, TimeUnit.MILLISECONDS);
+ 80:             }
+ 81:
+ 82:             // 减掉已经等待的时间
+ 83:             time -= System.currentTimeMillis() - currentTime;
+ 84:             // 如果无剩余等待的时间，则返回 false 加锁失败
+ 85:             if (time <= 0) {
+ 86:                 acquireFailed(threadId);
+ 87:                 return false;
+ 88:             }
+ 89:         }
+ 90:     } finally {
+ 91:         // 小细节，需要最终取消 SUBSCRIBE 订阅
+ 92:         unsubscribe(subscribeFuture, threadId);
+ 93:     }
+ 94: //    return get(tryLockAsync(waitTime, leaseTime, unit));
+ 95: }
+```
+
+- 第 7 行：调用 `#tryAcquire(long leaseTime, TimeUnit unit, long threadId)` 方法，同步加锁。代码如下：
+
+  ```
+  // RedissonLock.java
+  
+  private Long tryAcquire(long leaseTime, TimeUnit unit, long threadId) {
+      return get(tryAcquireAsync(leaseTime, unit, threadId));
+  }
+  ```
+
+  - 该方法内部，调用的就是 [「5.1 `#tryAcquireAsync(long leaseTime, TimeUnit unit, long threadId)`」](https://svip.iocoder.cn/Redisson/ReentrantLock/#) 方法。
+
+- 第 8 至 12 行：加锁成功，直接返回 `true` 加锁成功。
+
+- 第 15 行：减掉已经等待的时间。
+
+- 第 17 至 20 行：如果无剩余等待的时间，则返回 `false` 加锁失败。
+
+- 第 25 行：调用 `#subscribe(long threadId)` 方法，创建 SUBSCRIBE 订阅的 Future `subscribeFuture` 。
+
+- 【重要差异点】第 27 至 41 行：调用 `#await(subscribeFuture, time, TimeUnit.MILLISECONDS)` 方法，阻塞等待订阅发起成功，因为 `subscribeFuture` 是异步的，需要这一步转同步。如果发生超时，则就会进入第 28 至 37 行的取消逻辑，并在第 38 至 40 行返回 `false` 加锁失败。
+
+- 第 52 至 89 行：反复重试，直到成功加锁返回
+
+   
+
+  ```
+  true
+  ```
+
+   
+
+  ，或者超时返回
+
+   
+
+  ```
+  false
+  ```
+
+   
+
+  。
+
+  - 第 54 至 73 行：重试一波第 6 至 20 行的逻辑。
+
+  - 【重要差异点】第 75 至 80 行：通过 RedissonLockEntry 的信号量，阻塞等待锁的释放消息，或者
+
+     
+
+    ```
+    ttl
+    ```
+
+    /
+
+    ```
+    time
+    ```
+
+     
+
+    超时（例如说，锁的自动超时释放）。
+
+    - 相比 [「5.2 `#tryLockAsync(AtomicLong time, long leaseTime, TimeUnit unit, RFuture subscribeFuture, RPromise result, long currentThreadId)`」](https://svip.iocoder.cn/Redisson/ReentrantLock/#) 方法，它把信号量的等待和定时任务的等待融合在一起了。
+    - 等待完成后，如果无剩余时间，在第 82 至 88 行的逻辑中，返回 `false` 加锁失败。
+    - 等待完成后，如果有剩余时间，在第 56 行：获得重新同步获得锁。
+
+- 第 92 行：调用 `#unsubscribe(RFuture<RedissonLockEntry> future, long threadId)` 方法，小细节，需要最终取消 SUBSCRIBE 订阅。
+
+# 7. lockAsync
+
+> 艿艿：本小节和 [「5. tryLockAsync」](https://svip.iocoder.cn/Redisson/ReentrantLock/#) 相似，为**异步**加锁。继续扶你起来，胖友还可以继续怼源码。
+
+`#lockAsync(long leaseTime, TimeUnit unit, long currentThreadId)` 方法，异步加锁，无需返回是否成功。代码如下：
+
+```
+// RedissonLock.java
+
+    @Override
+    public RFuture<Void> lockAsync() {
+        return lockAsync(-1, null);
+    }
+
+    @Override
+    public RFuture<Void> lockAsync(long leaseTime, TimeUnit unit) {
+        // 获得线程编号
+        long currentThreadId = Thread.currentThread().getId();
+        // 异步锁
+        return lockAsync(leaseTime, unit, currentThreadId);
+    }
+
+    @Override
+    public RFuture<Void> lockAsync(long currentThreadId) {
+        return lockAsync(-1, null, currentThreadId);
+    }
+
+  1: @Override
+  2: public RFuture<Void> lockAsync(long leaseTime, TimeUnit unit, long currentThreadId) {
+  3:     // 创建 RPromise 对象，用于异步回调
+  4:     RPromise<Void> result = new RedissonPromise<Void>();
+  5:     // 异步加锁
+  6:     RFuture<Long> ttlFuture = tryAcquireAsync(leaseTime, unit, currentThreadId);
+  7:     ttlFuture.onComplete((ttl, e) -> {
+  8:         // 如果发生异常，则通过 result 通知异常
+  9:         if (e != null) {
+ 10:             result.tryFailure(e);
+ 11:             return;
+ 12:         }
+ 13:
+ 14:         // lock acquired
+ 15:         // 如果获得到锁，则通过 result 通知获得锁成功
+ 16:         if (ttl == null) {
+ 17:             if (!result.trySuccess(null)) { // 如果处理 result 通知对结果返回 false ，意味着需要异常释放锁
+ 18:                 unlockAsync(currentThreadId);
+ 19:             }
+ 20:             return;
+ 21:         }
+ 22:
+ 23:         // 创建 SUBSCRIBE 订阅的 Future
+ 24:         RFuture<RedissonLockEntry> subscribeFuture = subscribe(currentThreadId);
+ 25:         subscribeFuture.onComplete((res, ex) -> {
+ 26:             // 如果发生异常，则通过 result 通知异常
+ 27:             if (ex != null) {
+ 28:                 result.tryFailure(ex);
+ 29:                 return;
+ 30:             }
+ 31:
+ 32:             // 异步加锁
+ 33:             lockAsync(leaseTime, unit, subscribeFuture, result, currentThreadId);
+ 34:         });
+ 35:     });
+ 36:
+ 37:     return result;
+ 38: }
+```
+
+- 第 6 行：调用 [「5.1 `#tryAcquireAsync(long leaseTime, TimeUnit unit, long threadId)`」](https://svip.iocoder.cn/Redisson/ReentrantLock/#) 方法，执行异步获得锁。
+- 第 7 至 35 行：又是熟悉的配方，在回调中，处理响应的加锁结果。差异就在第 34 行，见 [「7.1 更强的 lockAsync」](https://svip.iocoder.cn/Redisson/ReentrantLock/#) 的详细解析。
+
+## 7.1 更强的 lockAsync
+
+实际上，`#lockAsync(long leaseTime, TimeUnit unit, RFuture<RedissonLockEntry> subscribeFuture, RPromise<Void> result, long currentThreadId)` 方法，和 [「5.2 更强的 tryLockAsync」](https://svip.iocoder.cn/Redisson/ReentrantLock/#) 是**基本一致**的。那么为什么不直接重用呢？注意，这个方法**不需要考虑等待超时**，有一种“劳资有钱，必须拿到锁”。
+
+代码如下：
+
+```
+// RedissonLock.java
+
+private void lockAsync(long leaseTime, TimeUnit unit, RFuture<RedissonLockEntry> subscribeFuture, RPromise<Void> result, long currentThreadId) {
+    // 获得分布式锁
+    RFuture<Long> ttlFuture = tryAcquireAsync(leaseTime, unit, currentThreadId);
+    ttlFuture.onComplete((ttl, e) -> {
+        // 如果发生异常，则取消订阅，并通过 result 通知异常
+        if (e != null) {
+            unsubscribe(subscribeFuture, currentThreadId);
+            result.tryFailure(e);
+            return;
+        }
+
+        // lock acquired
+        // 如果获得到锁，则取消订阅，并通过 result 通知获得锁成功
+        if (ttl == null) {
+            unsubscribe(subscribeFuture, currentThreadId);
+            if (!result.trySuccess(null)) {
+                unlockAsync(currentThreadId);
+            }
+            return;
+        }
+
+        // 获得当前线程对应的 RedissonLockEntry 对象
+        RedissonLockEntry entry = getEntry(currentThreadId);
+        // 尝试获得 entry 中的信号量，如果获得成功，说明 SUBSCRIBE 已经收到释放锁的消息，则直接立马再次去获得锁。
+        if (entry.getLatch().tryAcquire()) {
+            lockAsync(leaseTime, unit, subscribeFuture, result, currentThreadId);
+        } else {
+            // waiting for message
+            // 创建 AtomicReference 对象，用于指向定时任务
+            AtomicReference<Timeout> futureRef = new AtomicReference<Timeout>();
+            // 创建监听器 listener ，用于在 RedissonLockEntry 的回调，就是我们看到的 PublishSubscribe 监听到释放锁的消息，进行回调。
+            Runnable listener = () -> {
+                // 如果有定时任务的 Future ，则进行取消
+                if (futureRef.get() != null) {
+                    futureRef.get().cancel();
+                }
+                // 再次获得分布式锁
+                lockAsync(leaseTime, unit, subscribeFuture, result, currentThreadId);
+            };
+            // 添加 listener 到 RedissonLockEntry 中
+            entry.addListener(listener);
+
+            // 下面，会创建一个定时任务。因为极端情况下，可能不存在释放锁的消息，例如说锁自动超时释放，所以需要改定时任务，在获得到锁的超时后，主动去抢下。
+            if (ttl >= 0) {
+                Timeout scheduledFuture = commandExecutor.getConnectionManager().newTimeout(new TimerTask() {
+                    @Override
+                    public void run(Timeout timeout) throws Exception {
+                        // 移除 listener 从 RedissonLockEntry 中
+                        if (entry.removeListener(listener)) {
+                            // 再次获得分布式锁
+                            lockAsync(leaseTime, unit, subscribeFuture, result, currentThreadId);
+                        }
+                    }
+                }, ttl, TimeUnit.MILLISECONDS);
+                // 记录 futureRef 执行 scheduledFuture
+                futureRef.set(scheduledFuture);
+            }
+        }
+    });
+}
+```
+
+- 更加熟悉的配方，全程无需处理等待锁超时的逻辑。胖友自己瞅瞅，哈哈哈。
+
+# 8. lock
+
+> 艿艿：本小节和 [「6. tryLoc」](https://svip.iocoder.cn/Redisson/ReentrantLock/#) 相对，为**同步**加锁。再次扶你起来，胖友还可以继续怼源码。
+
+`#tryLock(long waitTime, long leaseTime, TimeUnit unit)` 方法，同步加锁，无需返回是否成功。代码如下：
+
+```
+// RedissonLock.java
+
+@Override
+public void lock() {
+    try {
+        lock(-1, null, false);
+    } catch (InterruptedException e) {
+        throw new IllegalStateException();
+    }
+}
+
+@Override
+public void lock(long leaseTime, TimeUnit unit) {
+    try {
+        lock(leaseTime, unit, false);
+    } catch (InterruptedException e) {
+        throw new IllegalStateException();
+    }
+}
+
+@Override
+public void lockInterruptibly() throws InterruptedException {
+    lock(-1, null, true);
+}
+
+@Override
+public void lockInterruptibly(long leaseTime, TimeUnit unit) throws InterruptedException {
+    lock(leaseTime, unit, true);
+}
+
+  1: private void lock(long leaseTime, TimeUnit unit, boolean interruptibly) throws InterruptedException {
+  2:     long threadId = Thread.currentThread().getId();
+  3:     // 同步获加锁
+  4:     Long ttl = tryAcquire(leaseTime, unit, threadId);
+  5:     // lock acquired
+  6:     // 加锁成功，直接返回
+  7:     if (ttl == null) {
+  8:         return;
+  9:     }
+ 10:
+ 11:     // 创建 SUBSCRIBE 订阅的 Future
+ 12:     RFuture<RedissonLockEntry> future = subscribe(threadId);
+ 13:     // 阻塞等待订阅发起成功
+ 14:     commandExecutor.syncSubscription(future);
+ 15:
+ 16:     try {
+ 17:         while (true) {
+ 18:             // 同步获加锁
+ 19:             ttl = tryAcquire(leaseTime, unit, threadId);
+ 20:             // lock acquired
+ 21:             // 加锁成功，直接返回
+ 22:             if (ttl == null) {
+ 23:                 break;
+ 24:             }
+ 25:
+ 26:             // waiting for message
+ 27:             // 通过 RedissonLockEntry 的信号量，阻塞等待锁的释放消息，或者 ttl/time 超时（例如说，锁的自动超时释放）
+ 28:             if (ttl >= 0) {
+ 29:                 try {
+ 30:                     getEntry(threadId).getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS);
+ 31:                 } catch (InterruptedException e) {
+ 32:                     // 如果允许打断，则抛出 e
+ 33:                     if (interruptibly) {
+ 34:                         throw e;
+ 35:                     }
+ 36:                     // 如果不允许打断，则继续
+ 37:                     getEntry(threadId).getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS);
+ 38:                 }
+ 39:             } else {
+ 40:                 if (interruptibly) {
+ 41:                     getEntry(threadId).getLatch().acquire();
+ 42:                 } else {
+ 43:                     getEntry(threadId).getLatch().acquireUninterruptibly();
+ 44:                 }
+ 45:             }
+ 46:         }
+ 47:     } finally {
+ 48:         // 小细节，需要最终取消 SUBSCRIBE 订阅
+ 49:         unsubscribe(future, threadId);
+ 50:     }
+ 51: //    get(lockAsync(leaseTime, unit));
+ 52: }
+ 53:
+ 54: private Long tryAcquire(long leaseTime, TimeUnit unit, long threadId) {
+ 55:     return get(tryAcquireAsync(leaseTime, unit, threadId));
+ 56: }
+```
+
+- 太过熟悉，就不哔哔了。
+
+------
+
+至此，加锁的几种组合排列，我们就已经看完了。😈 是不是有一种加锁的 Lua 脚本蛮简单的，调用 Lua 脚本实现阻塞等待的逻辑，细节还是蛮多的。如果让艿艿自己来实现这块的逻辑，估计会有一些细节处理不到位。嘿嘿。
+
+# 9. unlockAsync
+
+`#unlockAsync(long threadId)` 方法，异步解锁。代码如下：
+
+```
+// RedissonLock.java
+
+    @Override
+    public RFuture<Void> unlockAsync() {
+        // 获得线程编号
+        long threadId = Thread.currentThread().getId();
+        // 执行解锁
+        return unlockAsync(threadId);
+    }
+
+  1: @Override
+  2: public RFuture<Void> unlockAsync(long threadId) {
+  3:     // 创建 RPromise 对象，用于异步回调
+  4:     RPromise<Void> result = new RedissonPromise<Void>();
+  5:
+  6:     // 解锁逻辑
+  7:     RFuture<Boolean> future = unlockInnerAsync(threadId);
+  8:
+  9:     future.onComplete((opStatus, e) -> {
+ 10:         // 如果发生异常，并通过 result 通知异常
+ 11:         if (e != null) {
+ 12:             cancelExpirationRenewal(threadId);
+ 13:             result.tryFailure(e);
+ 14:             return;
+ 15:         }
+ 16:
+ 17:         // 解锁的线程不对，则创建 IllegalMonitorStateException 异常，并通过 result 通知异常
+ 18:         if (opStatus == null) {
+ 19:             IllegalMonitorStateException cause = new IllegalMonitorStateException("attempt to unlock lock, not locked by current thread by node id: "
+ 20:                     + id + " thread-id: " + threadId);
+ 21:             result.tryFailure(cause);
+ 22:             return;
+ 23:         }
+ 24:
+ 25:         // 取消定时过期
+ 26:         cancelExpirationRenewal(threadId);
+ 27:
+ 28:         // 通知 result 解锁成功
+ 29:         result.trySuccess(null);
+ 30:     });
+ 31:
+ 32:     return result;
+ 33: }
+```
+
+- 第 7 行：调用 [3.2 `#unlockAsync(long threadId)`](https://svip.iocoder.cn/Redisson/ReentrantLock/#) 方法，执行解锁逻辑。
+- 第 10 至 15 行：如果发生异常，并通过 `result` 通知异常。
+- 第 17 至 23 行：解锁的线程不对，则创建 IllegalMonitorStateException 异常，并通过 `result` 通知异常。😈 这里，仔细回忆下解锁 Lua 脚本的返回值。嘿嘿。
+- 第 26 行：调用 `#cancelExpirationRenewal(long threadId)` 方法，取消定期过期。TODO
+- 第 29 行：通知 `result` 解锁成功。
+
+# 10. unlock
+
+`#unlock()` 方法，同步解锁。代码如下：
+
+```
+// RedissonLock.java
+
+@Override
+public void unlock() {
+    try {
+        get(unlockAsync(Thread.currentThread().getId()));
+    } catch (RedisException e) {
+        if (e.getCause() instanceof IllegalMonitorStateException) {
+            throw (IllegalMonitorStateException) e.getCause();
+        } else {
+            throw e;
+        }
+    }
+}
+```
+
+- 简单，基于 [「9. `#unlockAsync(long threadId)`」](https://svip.iocoder.cn/Redisson/ReentrantLock/#) 方法实现。
+
+# 11. forceUnlock
+
+`#forceUnlock()` 方法，强制解锁。代码如下：
+
+```
+// RedissonLock.java
+
+@Override
+public boolean forceUnlock() { // 同步
+    return get(forceUnlockAsync());
+}
+
+@Override
+public RFuture<Boolean> deleteAsync() { // 异步
+    return forceUnlockAsync();
+}
+```
+
+- 无论是同步还是异步的强制解锁，都是基于 [「3.3 `#forceUnlockAsync()`」](https://svip.iocoder.cn/Redisson/ReentrantLock/#) 方法实现。
+
+# 12. ExpirationEntry
+
+本小节，我们来看看在 [「3.4 renewExpirationAsync」](https://svip.iocoder.cn/Redisson/ReentrantLock/#) 中，提到的**续锁**的功能。
+
+首先，我们来看看 ExpirationEntry 类。它是 RedissonLock 的内部类，记录**续租**任务的信息。代码如下：
+
+```
+// RedissonLock.java
+
+public static class ExpirationEntry {
+
+    /**
+     * 线程与计数器的映射
+     *
+     * KEY：线程编号
+     * VALUE：计数
+     */
+    private final Map<Long, Integer> threadIds = new LinkedHashMap<>();
+    /**
+     * 定时任务
+     */
+    private volatile Timeout timeout;
+
+    public ExpirationEntry() {
+        super();
+    }
+
+    /**
+     * 增加线程的计数
+     *
+     * @param threadId 线程编号
+     */
+    public void addThreadId(long threadId) {
+        Integer counter = threadIds.get(threadId);
+        if (counter == null) {
+            counter = 1;
+        } else {
+            counter++;
+        }
+        threadIds.put(threadId, counter);
+    }
+
+    public boolean hasNoThreads() {
+        return threadIds.isEmpty();
+    }
+
+    public Long getFirstThreadId() {
+        if (threadIds.isEmpty()) {
+            return null;
+        }
+        return threadIds.keySet().iterator().next();
+    }
+
+    /**
+     * 减少线程的技术
+     *
+     * @param threadId 线程编号
+     */
+    public void removeThreadId(long threadId) {
+        Integer counter = threadIds.get(threadId);
+        if (counter == null) {
+            return;
+        }
+        counter--;
+        if (counter == 0) {
+            threadIds.remove(threadId);
+        } else {
+            threadIds.put(threadId, counter);
+        }
+    }
+
+    public void setTimeout(Timeout timeout) {
+        this.timeout = timeout;
+    }
+
+    public Timeout getTimeout() {
+        return timeout;
+    }
+
+}
+```
+
+- 可能粗略这么一看，有种然并卵的感觉，不要着急。我们下面接着看。
+
+- 在 RedissonLock 的类中，有个
+
+   
+
+  ```
+  EXPIRATION_RENEWAL_MAP
+  ```
+
+   
+
+  静态属性，如下：
+
+  ```
+  // RedissonLock.java
+  
+  /**
+   * ExpirationEntry 的映射
+   *
+   * key ：{@link #entryName}
+   */
+  private static final ConcurrentMap<String, ExpirationEntry> EXPIRATION_RENEWAL_MAP = new ConcurrentHashMap<>();
+  ```
+
+## 12.1 scheduleExpirationRenewal
+
+`#scheduleExpirationRenewal()` 方法，发起**续锁**的定时任务。代码如下：
+
+```
+// RedissonLock.java
+
+  1: private void scheduleExpirationRenewal(long threadId) {
+  2:     // 创建 ExpirationEntry 对象
+  3:     ExpirationEntry entry = new ExpirationEntry();
+  4:     // 添加到 EXPIRATION_RENEWAL_MAP 中
+  5:     ExpirationEntry oldEntry = EXPIRATION_RENEWAL_MAP.putIfAbsent(getEntryName(), entry);
+  6:     // 添加线程编号到 ExpirationEntry 中
+  7:     if (oldEntry != null) {
+  8:         oldEntry.addThreadId(threadId);
+  9:     } else {
+ 10:         entry.addThreadId(threadId);
+ 11:         // 创建定时任务，用于续锁
+ 12:         renewExpiration();
+ 13:     }
+ 14: }
+ 15:
+ 16: private void renewExpiration() {
+ 17:     // 获得 ExpirationEntry 队形，从 EXPIRATION_RENEWAL_MAP 中
+ 18:     ExpirationEntry ee = EXPIRATION_RENEWAL_MAP.get(getEntryName());
+ 19:     if (ee == null) { // 如果不存在，返回
+ 20:         return;
+ 21:     }
+ 22:
+ 23:     // 创建 Timeout 定时任务，实现定时续锁
+ 24:     Timeout task = commandExecutor.getConnectionManager().newTimeout(new TimerTask() {
+ 25:
+ 26:         @Override
+ 27:         public void run(Timeout timeout) throws Exception {
+ 28:             // 获得 ExpirationEntry 对象
+ 29:             ExpirationEntry ent = EXPIRATION_RENEWAL_MAP.get(getEntryName());
+ 30:             if (ent == null) { // 如果不存在，返回
+ 31:                 return;
+ 32:             }
+ 33:             // 获得 threadId 编号
+ 34:             Long threadId = ent.getFirstThreadId();
+ 35:             if (threadId == null) { // 如果不存在，则返回
+ 36:                 return;
+ 37:             }
+ 38:
+ 39:             // 执行续锁
+ 40:             RFuture<Boolean> future = renewExpirationAsync(threadId);
+ 41:             future.onComplete((res, e) -> {
+ 42:                 // 如果发生异常，则打印异常日志，并返回。此时，就不会在定时续租了
+ 43:                 if (e != null) {
+ 44:                     log.error("Can't update lock " + getName() + " expiration", e);
+ 45:                     return;
+ 46:                 }
+ 47:
+ 48:                 // 续锁成功，则重新发起定时任务
+ 49:                 if (res) {
+ 50:                     // reschedule itself
+ 51:                     renewExpiration();
+ 52:                 }
+ 53:             });
+ 54:         }
+ 55:
+ 56:     }, internalLockLeaseTime / 3, TimeUnit.MILLISECONDS); // 定时，每 internalLockLeaseTime / 3 秒执行一次。
+ 57:
+ 58:     // 设置定时任务到 ExpirationEntry 中
+ 59:     ee.setTimeout(task);
+ 60: }
+```
+
+- 第 2 至 10 行：创建 ExpirationEntry 对象，并添加到 `EXPIRATION_RENEWAL_MAP` 中，之后添加线程编号到 ExpirationEntry 中。
+
+- 第 12 行：当且仅当
+
+   
+
+  ```
+  entryName
+  ```
+
+   
+
+  对应的 ExpirationEntry 对象
+
+  首次
+
+  创建时，才会调用
+
+   
+
+  ```
+  #renewExpiration()
+  ```
+
+   
+
+  方法，创建定时任务，用于续锁。
+
+  - 【重要】第 23 至 56 行：创建 Timeout 定时任务，定时每 `internalLockLeaseTime / 3` 秒执行一次**续锁**。
+  - 第 40 行：会调用 [「3.4 `#renewExpirationAsync(long threadId)` 方法」](https://svip.iocoder.cn/Redisson/ReentrantLock/#) 方法，执行续锁。
+  - 第 42 至 46 行：如果发生异常，则打印异常日志，并返回。此时，就不会在定时续租了。
+  - 【重要】第 48 至 52 行：如果续锁成功，则调用 `#renewExpiration()` 方法，重新发起定时任务。
+
+- 第 59 行：设置定时任务到 ExpirationEntry 中。
+
+## 12.2 cancelExpirationRenewal
+
+`#cancelExpirationRenewal(Long threadId)` 方法，取消定时任务。代码如下：
+
+```
+// RedissonLock.java
+
+void cancelExpirationRenewal(Long threadId) {
+    // 获得 ExpirationEntry 对象
+    ExpirationEntry task = EXPIRATION_RENEWAL_MAP.get(getEntryName());
+    if (task == null) { // 如果不存在，返回
+        return;
+    }
+
+    // 从 ExpirationEntry 中，移除线程编号
+    if (threadId != null) {
+        task.removeThreadId(threadId);
+    }
+
+    // 如果 ExpirationEntry 的所有线程被清空
+    if (threadId == null || task.hasNoThreads()) {
+        // 取消定时任务
+        task.getTimeout().cancel();
+        // 从 EXPIRATION_RENEWAL_MAP 中移除
+        EXPIRATION_RENEWAL_MAP.remove(getEntryName());
+    }
+}
+```
+
+- 当且仅当 `entryName` 对应的 `EXPIRATION_RENEWAL_MAP` 的 ExpirationEntry 对象，所有线程都被移除后，会取消定时任务。
+- 整体逻辑比较简单，胖友自己瞅瞅。
+
+# 13. 其它方法
+
+其它方法，比较简单，胖友自己瞅瞅即可。代码如下：
+
+```
+// RedissonLock.java
+
+@Override
+public Condition newCondition() {
+    // TODO implement
+    throw new UnsupportedOperationException();
+}
+
+@Override
+public boolean isLocked() {
+    return isExists();
+}
+
+@Override
+public RFuture<Boolean> isLockedAsync() {
+    return isExistsAsync();
+}
+
+@Override
+public RFuture<Boolean> isExistsAsync() {
+    return commandExecutor.writeAsync(getName(), codec, RedisCommands.EXISTS, getName());
+}
+
+@Override
+public boolean isHeldByCurrentThread() {
+    return isHeldByThread(Thread.currentThread().getId());
+}
+
+@Override
+public boolean isHeldByThread(long threadId) {
+    RFuture<Boolean> future = commandExecutor.writeAsync(getName(), LongCodec.INSTANCE, RedisCommands.HEXISTS, getName(), getLockName(threadId));
+    return get(future);
+}
+
+private static final RedisCommand<Integer> HGET = new RedisCommand<Integer>("HGET", ValueType.MAP_VALUE, new IntegerReplayConvertor(0));
+
+public RFuture<Integer> getHoldCountAsync() {
+    return commandExecutor.writeAsync(getName(), LongCodec.INSTANCE, HGET, getName(), getLockName(Thread.currentThread().getId()));
+}
+
+@Override
+public int getHoldCount() {
+    return get(getHoldCountAsync());
+}
+```
+
+# 666. 彩蛋
+
+细节比想象中的多，代码也比想象中的多，整篇博客差不多写了 1.5 天左右。
+
+胖友看完之后，如果还有一些细节不清晰，建议可以多多调试。总的来说，如果项目中，想要使用 Redis 分布式锁，可以考虑直接使用 Redisson 提供的 Redisson 可重入锁。可能有些胖友项目中，已经使用了 Jedis 作为 Redis 的客户端，那么可以单独使用 Redisson 来做分布式锁。
+
+之前也和一些朋友聊过，他们项目也是采用 Jedis + Redisson 的组合，妥妥的，没问题。
+
+满足，在 2019-10-04 的 18:59 写完了这篇博客，美滋滋。
\ No newline at end of file
diff --git a/redis/05-Redisson 源码分析-可靠分布式锁 RedLock.assets/834b021723e3d41e09763ce83f6e8cf4.png b/redis/05-Redisson 源码分析-可靠分布式锁 RedLock.assets/834b021723e3d41e09763ce83f6e8cf4.png
new file mode 100644
index 0000000..7a39607
Binary files /dev/null and b/redis/05-Redisson 源码分析-可靠分布式锁 RedLock.assets/834b021723e3d41e09763ce83f6e8cf4.png differ
diff --git a/redis/05-Redisson 源码分析-可靠分布式锁 RedLock.md b/redis/05-Redisson 源码分析-可靠分布式锁 RedLock.md
new file mode 100644
index 0000000..51c4f2f
--- /dev/null
+++ b/redis/05-Redisson 源码分析-可靠分布式锁 RedLock.md	
@@ -0,0 +1,906 @@
+# 精尽 Redisson 源码分析 —— 可靠分布式锁 RedLock
+
+# 1. 概述
+
+在 [《精尽 Redisson 源码分析 —— 可重入分布式锁 ReentrantLock》](http://svip.iocoder.cn/Redisson/ReentrantLock/?self) 中，艿艿臭长臭长的分享了 Redisson 是如何实现可重入的 ReentrantLock 锁，一切看起来很完美，我们能够正确的加锁，也能正确的释放锁。但是，我们来看一个 Redis 主从结构下的示例，Redis 分布式锁是如何失效的：
+
+- 1、客户端 A 从 Redis Master 获得到锁 `anylock` 。
+- 2、在 Redis Master 同步 `anylock` 到 Redis Slave 之前，Master 挂了。
+- 3、Redis Slave 晋升为**新的** Redis Master 。
+- 4、客户端 B 从**新的** Redis Master 获得到锁 `anylock` 。
+
+此时，客户端 A 和 B 同时持有 `anylock` 锁，已经失效。当然，这个情况是极小概率事件。主要看胖友业务对分布式锁可靠性的诉求。
+
+在 Redis 分布式锁存在失效的问题，Redis 的作者 Antirez 大神提出了红锁 RedLock 的想法。我们来看看它的描述。
+
+> FROM [《Redis 文档 —— Redis 分布式锁》](http://redis.cn/topics/distlock.html)
+>
+> 在 Redis 的分布式环境中，我们假设有 N 个 Redis master 。这些节点完全互相独立，不存在主从复制或者其他集群协调机制。之前我们已经描述了在 Redis 单实例下怎么安全地获取和释放锁。我们确保将在每 N 个实例上使用此方法获取和释放锁。在这个样例中，我们假设有 5 个Redis master 节点，这是一个比较合理的设置，所以我们需要在 5 台机器上面或者 5 台虚拟机上面运行这些实例，这样保证他们不会同时都宕掉。
+>
+> 为了取到锁，客户端应该执行以下操作:
+>
+> - 1、获取当前 Unix 时间，以毫秒为单位。
+> - 2、依次尝试从 N 个实例，使用相同的 key 和随机值获取锁。在步骤 2 ，当向 Redis 设置锁时，客户端应该设置一个网络连接和响应超时时间，这个超时时间应该小于锁的失效时间。例如你的锁自动失效时间为 10 秒，则超时时间应该在 5-50 毫秒之间。这样可以避免服务器端 Redis 已经挂掉的情况下，客户端还在死死地等待响应结果。如果服务器端没有在规定时间内响应，客户端应该尽快尝试另外一个 Redis 实例。
+> - 3、客户端使用当前时间减去开始获取锁时间（步骤 1 记录的时间）就得到获取锁使用的时间。当且仅当从大多数（这里是 3 个节点）的 Redis 节点都取到锁，并且使用的时间小于锁失效时间时，锁才算获取成功。
+> - 4、如果取到了锁，key 的真正有效时间等于有效时间减去获取锁所使用的时间（步骤 3 计算的结果）。
+> - 5、如果因为某些原因，获取锁失败（没有在至少 `N/2 + 1` 个 Redis 实例取到锁或者取锁时间已经超过了有效时间），客户端应该在所有的 Redis 实例上进行解锁（即便某些Redis实例根本就没有加锁成功）。
+>
+> 释放锁：
+>
+> - 1、释放锁比较简单，向所有的 Redis 实例发送释放锁命令即可，不用关心之前有没有从Redis实例成功获取到锁.
+
+可能一看内容这么长，略微有点懵逼。**重点理解，需要至少在 `N/2 + 1` Redis 节点获得锁成功。**这样，即使出现某个 Redis Master 未同步锁信息到 Redis Slave 节点之前，突然挂了，也不**容易**出现多个客户端获得相同锁，因为**需要至少在 `N/2 + 1` Redis 节点获得锁成功。**。
+
+当然，极端情况下也有。我们以 3 个 Redis Master 节点举例子：
+
+- 1、客户端 A 从 3 个 Redis Master 获得到锁 `anylock` 。
+- 2、**2 个** Redis Master 同步 anylock 到 Redis Slave 之前，Master 都挂了。
+- 3、**2 个** Redis Slave 晋升为**新的** Redis Master 。
+- 4、客户端 B 从**新的** Redis Master 获得到锁 `anylock` 。
+
+理论来说，出现 **2 个** Redis Master 都挂了，并且数据都未同步到 Redis Slave 的情况，已经是小概率的事件。当然，哈哈哈哈，我们就是可爱的“杠精”，就是要扣一扣这个边界情况。
+
+同时，我们也可以发现，在时候用 RedLock 的时候，Redis Master 越多，集群的可靠性就越高，性能也会越低。😈 架构设计中，从来没有银弹。我们想要得到更高的可靠性，往往需要失去一定的性能。
+
+对了，有一点要注意，N 个 Redis Master 要**毫无关联**的。例如说，任一一个 Redis Master 都不能在同一个 Redis Cluster 中。再如下图，就是一个符合条件的：
+
+> FROM [《慢谈 Redis 实现分布式锁 以及 Redisson 源码解析》](https://crazyfzw.github.io/2019/04/15/distributed-locks-with-redis/)
+>
+> [![Redis Master 示例](05-Redisson 源码分析-可靠分布式锁 RedLock.assets/834b021723e3d41e09763ce83f6e8cf4.png)](http://static.iocoder.cn/834b021723e3d41e09763ce83f6e8cf4)Redis Master 示例
+>
+> 当然，推荐 N 是奇数个，因为 `N / 2 + 1` 嘛，哈哈。
+
+推荐胖友阅读如下三篇文章，更进一步了解 RedLock ：
+
+- [《Redis 文档 —— Redis 分布式锁》](http://redis.cn/topics/distlock.html)
+- [《How to do distributed locking》](http://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html)
+- [《Is Redlock safe?》](http://antirez.com/news/101) 简直神仙打架，强烈推荐。
+
+# 2. RedissonRedLock
+
+[`org.redisson.RedissonRedLock`](https://github.com/YunaiV/redisson/blob/master/redisson/src/main/java/org/redisson/RedissonRedLock.java) ，继承自联锁 RedissonMultiLock ，Redisson 对 RedLock 的实现类。代码如下：
+
+```
+// RedissonRedLock.java
+
+public class RedissonRedLock extends RedissonMultiLock {
+
+    /**
+     * Creates instance with multiple {@link RLock} objects.
+     * Each RLock object could be created by own Redisson instance.
+     *
+     * @param locks - array of locks
+     */
+    public RedissonRedLock(RLock... locks) {
+        super(locks);
+    }
+
+    @Override
+    protected int failedLocksLimit() {
+        return locks.size() - minLocksAmount(locks);
+    }
+
+    protected int minLocksAmount(final List<RLock> locks) {
+        return locks.size()/2 + 1;
+    }
+
+    @Override
+    protected long calcLockWaitTime(long remainTime) {
+        return Math.max(remainTime / locks.size(), 1);
+    }
+
+    @Override
+    public void unlock() {
+        unlockInner(locks);
+    }
+
+}
+```
+
+- RedissonMultiLock ，联锁，正如其名字“**联**”，可以将多个 RLock 锁关联成一个联锁。使用示例如下：
+
+  ```
+  RedissonMultiLock lock = new RedissonMultiLock(lock1, lock2, lock3);
+  // 给lock1，lock2，lock3加锁，如果没有手动解开的话，10秒钟后将会自动解开
+  lock.lock(10, TimeUnit.SECONDS);
+  
+  // 为加锁等待100秒时间，并在加锁成功10秒钟后自动解开
+  boolean res = lock.tryLock(100, 10, TimeUnit.SECONDS);
+  ...
+  lock.unlock();
+  ```
+
+- RedissonRedLock ，是一个**特殊**的联锁，加锁时无需所有的 RLock 都成功，只需要满足 `N / 2 + 1` 个 RLock 即可。使用示例如下：
+
+  ```
+  RLock lock1 = redissonInstance1.getLock("lock1");
+  RLock lock2 = redissonInstance2.getLock("lock2");
+  RLock lock3 = redissonInstance3.getLock("lock3");
+  
+  RedissonRedLock lock = new RedissonRedLock(lock1, lock2, lock3);
+  // 同时加锁：lock1 lock2 lock3
+  // 红锁在大部分节点上加锁成功就算成功。
+  lock.lock();
+  ...
+  lock.unlock();
+  ```
+
+- RedissonRedLock 构造方法，创建时，传入多个 RLock 对象。一般来说，每个 RLock 对应到一个 Redis Master 节点上。
+
+- `#failedLocksLimit()` 方法，允许失败加锁的数量。从 `#minLocksAmount(final List<RLock> locks)` 方法上，我们已经看到 `N / 2 + 1` 的要求。
+
+- `#calcLockWaitTime(long remainTime)` 方法，计算每次获得 RLock 的锁的等待时长。目前的计算规则是，总的等待时间 `remainTime` 平均分配到每个 RLock 上。
+
+- `#unlock()` 方法，解锁时，需要所有 RLock 都进行解锁。
+
+# 3. RedissonMultiLock
+
+[`org.redisson.RedissonMultiLock`](https://github.com/YunaiV/redisson/blob/master/redisson/src/main/java/org/redisson/RedissonMultiLock.java) ，实现 RLock 接口，Redisson 对联锁 MultiLock 的实现类。
+
+## 3.1 构造方法
+
+```
+// RedissonMultiLock.java
+
+/**
+ * RLock 数组
+ */
+final List<RLock> locks = new ArrayList<>();
+
+/**
+ * Creates instance with multiple {@link RLock} objects.
+ * Each RLock object could be created by own Redisson instance.
+ *
+ * @param locks - array of locks
+ */
+public RedissonMultiLock(RLock... locks) {
+    if (locks.length == 0) {
+        throw new IllegalArgumentException("Lock objects are not defined");
+    }
+    this.locks.addAll(Arrays.asList(locks));
+}
+```
+
+## 3.2 failedLocksLimit
+
+`#failedLocksLimit()` 方法，允许失败加锁的数量。代码如下：
+
+```
+// RedissonMultiLock.java
+
+protected int failedLocksLimit() {
+    return 0;
+}
+```
+
+默认返回值是 0 ，也就是必须所有 RLock 都加锁成功。
+
+在 RedissonRedLock 中，会重写该方法。
+
+```
+// RedissonRedLock.java
+
+@Override
+protected int failedLocksLimit() {
+    return locks.size() - minLocksAmount(locks);
+}
+
+protected int minLocksAmount(final List<RLock> locks) {
+    return locks.size() / 2 + 1;
+}
+```
+
+## 3.3 calcLockWaitTime
+
+`#failedLocksLimit(long remainTime)` 方法，计算每次获得 RLock 的锁的等待时长。代码如下：
+
+```
+// RedissonMultiLock.java
+
+protected long calcLockWaitTime(long remainTime) {
+    return remainTime;
+}
+```
+
+默认直接返回 `remainTime` ，也就是说，每次获得 RLock 的锁的等待时长都是 `remainTime` 。
+
+在 RedissonRedLock 中，会重写该方法。
+
+## 3.4 tryLock
+
+`#tryLock(long waitTime, long leaseTime, TimeUnit unit)` 方法，同步**加锁**，并返回加锁是否成功。代码如下：
+
+```
+// RedissonMultiLock.java
+
+    @Override
+    public boolean tryLock() {
+        try {
+            // 同步获得锁
+            return tryLock(-1, -1, null);
+        } catch (InterruptedException e) {
+            Thread.currentThread().interrupt();
+            return false;
+        }
+    }
+
+    @Override
+    public boolean tryLock(long waitTime, TimeUnit unit) throws InterruptedException {
+        return tryLock(waitTime, -1, unit);
+    }
+
+  1: @Override
+  2: public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException {
+  3:     // 计算新的锁的时长 newLeaseTime
+  4:     long newLeaseTime = -1;
+  5:     if (leaseTime != -1) {
+  6:         if (waitTime == -1) { // 如果无限等待，则直接使用 leaseTime 即可。
+  7:             newLeaseTime = unit.toMillis(leaseTime);
+  8:         } else { // 如果设置了等待时长，则为等待时间 waitTime * 2 。不知道为什么要 * 2 ？例如说，先获得到了第一个锁，然后在获得第二个锁的时候，阻塞等待了 waitTime ，那么可能第一个锁就已经自动过期，所以 * 2 避免这个情况。
+  9:             newLeaseTime = unit.toMillis(waitTime) * 2;
+ 10:         }
+ 11:     }
+ 12:
+ 13:     long time = System.currentTimeMillis();
+ 14:     // 计算剩余等待锁的时间 remainTime
+ 15:     long remainTime = -1;
+ 16:     if (waitTime != -1) {
+ 17:         remainTime = unit.toMillis(waitTime);
+ 18:     }
+ 19:     // 计算每个锁的等待时间
+ 20:     long lockWaitTime = calcLockWaitTime(remainTime);
+ 21:
+ 22:     // 允许获得锁失败的次数
+ 23:     int failedLocksLimit = failedLocksLimit();
+ 24:     // 已经获得到锁的数组
+ 25:     List<RLock> acquiredLocks = new ArrayList<>(locks.size());
+ 26:     // 遍历 RLock 数组，逐个获得锁
+ 27:     for (ListIterator<RLock> iterator = locks.listIterator(); iterator.hasNext();) {
+ 28:         // 当前 RLock
+ 29:         RLock lock = iterator.next();
+ 30:         boolean lockAcquired; // 标记是否获得到锁
+ 31:         try {
+ 32:             // 如果等待时间 waitTime 为 -1（不限制），并且锁时长为 -1（不限制），则使用 #tryLock() 方法。
+ 33:             if (waitTime == -1 && leaseTime == -1) {
+ 34:                 lockAcquired = lock.tryLock();
+ 35:             // 如果任一不为 -1 时，则计算新的等待时间 awaitTime ，然后调用 #tryLock(long waitTime, long leaseTime, TimeUnit unit) 方法。
+ 36:             } else {
+ 37:                 long awaitTime = Math.min(lockWaitTime, remainTime);
+ 38:                 lockAcquired = lock.tryLock(awaitTime, newLeaseTime, TimeUnit.MILLISECONDS);
+ 39:             }
+ 40:         } catch (RedisResponseTimeoutException e) {
+ 41:             // 发生响应超时。因为无法确定实际是否获得到锁，所以直接释放当前 RLock
+ 42:             unlockInner(Collections.singletonList(lock));
+ 43:             // 标记未获得锁
+ 44:             lockAcquired = false;
+ 45:         } catch (Exception e) {
+ 46:             // 标记未获得锁
+ 47:             lockAcquired = false;
+ 48:         }
+ 49:
+ 50:         // 如果获得成功，则添加到 acquiredLocks 数组中
+ 51:         if (lockAcquired) {
+ 52:             acquiredLocks.add(lock);
+ 53:         } else {
+ 54:             // 如果已经到达最少需要获得锁的数量，则直接 break 。例如说，RedLock 只需要获得 N / 2 + 1 把。
+ 55:             if (locks.size() - acquiredLocks.size() == failedLocksLimit()) {
+ 56:                 break;
+ 57:             }
+ 58:
+ 59:             // 当已经没有允许失败的数量，则进行相应的处理
+ 60:             if (failedLocksLimit == 0) {
+ 61:                 // 释放所有的锁
+ 62:                 unlockInner(acquiredLocks);
+ 63:                 // 如果未设置阻塞时间，直接返回 false ，表示失败。因为是 tryLock ，只是尝试加锁一次，不会无限重试。
+ 64:                 if (waitTime == -1) {
+ 65:                     return false;
+ 66:                 }
+ 67:                 // 重置整个获得锁的过程，在剩余的时间里，重新来一遍
+ 68:                 // 重置 failedLocksLimit 变量
+ 69:                 failedLocksLimit = failedLocksLimit();
+ 70:                 // 重置 acquiredLocks 为空
+ 71:                 acquiredLocks.clear();
+ 72:                 // reset iterator
+ 73:                 // 重置 iterator 设置回迭代器的头
+ 74:                 while (iterator.hasPrevious()) {
+ 75:                     iterator.previous();
+ 76:                 }
+ 77:             // failedLocksLimit 减一
+ 78:             } else {
+ 79:                 failedLocksLimit--;
+ 80:             }
+ 81:         }
+ 82:
+ 83:         // 计算剩余时间 remainTime
+ 84:         if (remainTime != -1) {
+ 85:             remainTime -= System.currentTimeMillis() - time;
+ 86:             // 记录新的当前时间
+ 87:             time = System.currentTimeMillis();
+ 88:             // 如果没有剩余时间，意味着已经超时，释放所有加载成功的锁，并返回 false
+ 89:             if (remainTime <= 0) {
+ 90:                 unlockInner(acquiredLocks);
+ 91:                 return false;
+ 92:             }
+ 93:         }
+ 94:     }
+ 95:
+ 96:     // 如果设置了锁的过期时间 leaseTime ，则重新设置每个锁的过期时间
+ 97:     if (leaseTime != -1) {
+ 98:         // 遍历 acquiredLocks 数组，创建异步设置过期时间的 Future
+ 99:         List<RFuture<Boolean>> futures = new ArrayList<>(acquiredLocks.size());
+100:         for (RLock rLock : acquiredLocks) {
+101:             RFuture<Boolean> future = ((RedissonLock) rLock).expireAsync(unit.toMillis(leaseTime), TimeUnit.MILLISECONDS);
+102:             futures.add(future);
+103:         }
+104:
+105:         // 阻塞等待所有 futures 完成
+106:         for (RFuture<Boolean> rFuture : futures) {
+107:             rFuture.syncUninterruptibly();
+108:         }
+109:     }
+110:
+111:     // 返回 true ，表示加锁成功
+112:     return true;
+113: }
+```
+
+- 超 100 行代码，是不是有点慌？！核心逻辑是，首先从 `locks` 数组中逐个获得锁（第 27 至 94 行），然后统一设置每个锁的过期时间（第 96 至 10 9 行）。当然，还是有很多细节，我们一点点来看。
+- 第 3 至 11 行：计算新的锁的时长 `newLeaseTime` 。注意，`newLeaseTime` 是用于遍历 `locks` 数组来获得锁设置的锁时长，最终在第 96 至 109 行的代码中，会设置真正的 `leaseTime` 锁的时长。整个的计算规则，看下艿艿添加的注释。
+- 第 14 至 18 行：计算剩余等待锁的时间 `remainTime` 。
+- 第 20 行：调用 `#calcLockWaitTime(long remainTime)` 方法，计算获得每个锁的等待时间。在 [「2. RedissonRedLock」](https://svip.iocoder.cn/Redisson/RedLock/#) 中，我们已经看到，是 `remainTime` 进行平均分配。
+- 第 25 行：已经获得到锁的数组 `acquiredLocks` 。
+- 下面，我们分成阶段一（加锁）和阶段二（设置锁过期时间）来抽丝剥茧。
+- **【阶段一】**第 26 至 94 行：遍历 RLock 数组，逐个获得锁。
+- 第 32 至 39 行：根据条件，调用对应的 `RLock#tryLock(...)` 方法，获得锁。一般情况下，RedissonRedLock 搭配 RedissonLock 使用，这块我们已经在 [《精尽 Redisson 源码分析 —— 可重入分布式锁 ReentrantLock》](http://svip.iocoder.cn/Redisson/ReentrantLock/?self) 有个详细的解析了。
+- 第 40 至 44 行：如果发生响应 RedisResponseTimeoutException 超时异常时，因为无法确定实际是否获得到锁，所以直接调用 `#unlockInner(Collection<RLock> locks)` 方法，释放当前 RLock 。
+- 第 50 至 52 行：如果获得成功，则添加到 `acquiredLocks` 数组中。
+- 【重要】第 54 至 57 行：如果已经到达最少需要获得锁的数量，则直接 break 。例如说，RedLock 只需要获得 `N / 2 + 1` 把。
+- 第 77 至 80 行：`failedLocksLimit` 减一。
+- 第 59 至 76 行：当已经没有允许失败的数量，则进行相应的处理。
+  - 第 62 行：因为已经失败了，所以调用 `#unlockInner(Collection<RLock> locks)` 方法，释放所有已经获得到的锁们。
+  - 第 63 至 66 行：如果*未设置*阻塞时间，直接返回 `false` 加锁失败。因为是 tryLock 方法，只是尝试加锁一次，不会无限重试。
+  - 第 67 至 76 行：重置整个获得锁的过程，在剩余的时间里，重新来一遍。因为*已设置*了阻塞时间，必须得用完！
+- 第 84 至 93 行：计算剩余时间 `remainTime` 。如果没有剩余的时间，意味着已经超时，则 调用 `#unlockInner(Collection<RLock> locks)` 方法，释放所有加载成功的锁，并返回 `false` 加锁失败。
+- **【阶段二】**第 96 至 109 行：如果设置了锁的过期时间 `leaseTime` ，则重新设置每个锁的过期时间。
+- 第 98 至 103 行：遍历 `acquiredLocks` 数组，创建异步设置过期时间的 Future 。
+- 第 105 至 108 行：阻塞等待所有 `futures` 完成。如果任一一个 Future 执行失败，则会抛出异常。
+
+## 3.5 tryLockAsync
+
+`#tryLockAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId)` 方法，异步**加锁**，并返回加锁是否成功。代码如下：
+
+```
+// RedissonMultiLock.java
+
+@Override
+public RFuture<Boolean> tryLockAsync(long waitTime, long leaseTime, TimeUnit unit) {
+    return tryLockAsync(waitTime, leaseTime, unit, Thread.currentThread().getId());
+}
+
+@Override
+public RFuture<Boolean> tryLockAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId) {
+    // 创建 RPromise 对象，用于通知结果
+    RPromise<Boolean> result = new RedissonPromise<Boolean>();
+    // 创建 LockState 对象
+    LockState state = new LockState(waitTime, leaseTime, unit, threadId);
+    // <X> 发起异步加锁
+    state.tryAcquireLockAsync(locks.listIterator(), result);
+    // 返回结果
+    return result;
+}
+```
+
+- 这个的逻辑在 `<X>` 处，调用 `LockState#tryAcquireLockAsync(ListIterator<RLock> iterator, RPromise<Boolean> result)` 方法，发起异步加锁。
+
+🔥 LockState 是 RedissonMultiLock 的内部类，实现异步加锁的逻辑。构造方法如下：
+
+```
+// RedissonMultiLock.LockState.java
+
+class LockState {
+
+    private final long newLeaseTime;
+    private final long lockWaitTime;
+    private final List<RLock> acquiredLocks;
+    private final long waitTime;
+    private final long threadId;
+    private final long leaseTime;
+    private final TimeUnit unit;
+
+    private long remainTime;
+    private long time = System.currentTimeMillis();
+    private int failedLocksLimit;
+
+    LockState(long waitTime, long leaseTime, TimeUnit unit, long threadId) {
+        this.waitTime = waitTime;
+        this.leaseTime = leaseTime;
+        this.unit = unit;
+        this.threadId = threadId;
+
+        // 计算新的锁的时长 newLeaseTime
+        if (leaseTime != -1) {
+            if (waitTime == -1) {
+                newLeaseTime = unit.toMillis(leaseTime);
+            } else {
+                newLeaseTime = unit.toMillis(waitTime) * 2;
+            }
+        } else {
+            newLeaseTime = -1;
+        }
+
+        // 计算剩余等待锁的时间 remainTime
+        remainTime = -1;
+        if (waitTime != -1) {
+            remainTime = unit.toMillis(waitTime);
+        }
+        // 计算每个锁的等待时间
+        lockWaitTime = calcLockWaitTime(remainTime);
+
+        // 允许获得锁失败的次数
+        failedLocksLimit = failedLocksLimit();
+        // 已经获得到锁的数组
+        acquiredLocks = new ArrayList<>(locks.size());
+    }
+
+    // ... 省略其它方法
+}
+```
+
+- 构造方法的逻辑，和 [「3.4 tryLock(long waitTime, long leaseTime, TimeUnit unit)」](https://svip.iocoder.cn/Redisson/RedLock/#) 的第 3 至 25 行的代码是一致的。所以，我们可以理解成构造方法，相当于做了一遍变量的初始化。
+
+🔥 `LockState#tryAcquireLockAsync(ListIterator<RLock> iterator, RPromise<Boolean> result)` 方法，发起异步加锁。代码如下：
+
+> 整体逻辑，和 [「3.4 tryLock(long waitTime, long leaseTime, TimeUnit unit)」](https://svip.iocoder.cn/Redisson/RedLock/#) 方法的逻辑基本一致，所以艿艿就不啰嗦详细说，而是告诉它们的对等关系。
+
+```
+// RedissonMultiLock.LockState.java
+
+  1: void tryAcquireLockAsync(ListIterator<RLock> iterator, RPromise<Boolean> result) {
+  2:     // 如果迭代 iterator 的尾部，则重新设置每个锁的过期时间
+  3:     if (!iterator.hasNext()) {
+  4:         checkLeaseTimeAsync(result);
+  5:         return;
+  6:     }
+  7:
+  8:     // 获得下一个 RLock 对象
+  9:     RLock lock = iterator.next();
+ 10:     // 创建 RPromise 对象
+ 11:     RPromise<Boolean> lockAcquiredFuture = new RedissonPromise<Boolean>();
+ 12:     // 如果等待时间 waitTime 为 -1（不限制），并且锁时长为 -1（不限制），则使用 #tryLock() 方法。
+ 13:     if (waitTime == -1 && leaseTime == -1) {
+ 14:         lock.tryLockAsync(threadId)
+ 15:             .onComplete(new TransferListener<Boolean>(lockAcquiredFuture));
+ 16:     // 如果任一不为 -1 时，则计算新的等待时间 awaitTime ，然后调用 #tryLock(long waitTime, long leaseTime, TimeUnit unit) 方法。
+ 17:     } else {
+ 18:         long awaitTime = Math.min(lockWaitTime, remainTime);
+ 19:         lock.tryLockAsync(awaitTime, newLeaseTime, TimeUnit.MILLISECONDS, threadId)
+ 20:             .onComplete(new TransferListener<Boolean>(lockAcquiredFuture));
+ 21:     }
+ 22:
+ 23:     lockAcquiredFuture.onComplete((res, e) -> {
+ 24:         // 如果 res 非空，设置 lockAcquired 是否获得到锁
+ 25:         boolean lockAcquired = false;
+ 26:         if (res != null) {
+ 27:             lockAcquired = res;
+ 28:         }
+ 29:
+ 30:         // 发生响应超时。因为无法确定实际是否获得到锁，所以直接释放当前 RLock
+ 31:         if (e instanceof RedisResponseTimeoutException) {
+ 32:             unlockInnerAsync(Collections.singletonList(lock), threadId);
+ 33:         }
+ 34:
+ 35:         // 如果获得成功，则添加到 acquiredLocks 数组中
+ 36:         if (lockAcquired) {
+ 37:             acquiredLocks.add(lock);
+ 38:         } else {
+ 39:             // 如果已经到达最少需要获得锁的数量，则直接 break 。例如说，RedLock 只需要获得 N / 2 + 1 把。
+ 40:             if (locks.size() - acquiredLocks.size() == failedLocksLimit()) {
+ 41:                 checkLeaseTimeAsync(result);
+ 42:                 return;
+ 43:             }
+ 44:
+ 45:             // 当已经没有允许失败的数量，则进行相应的处理
+ 46:             if (failedLocksLimit == 0) {
+ 47:                 // 创建释放所有的锁的 Future
+ 48:                 unlockInnerAsync(acquiredLocks, threadId).onComplete((r, ex) -> {
+ 49:                     // 如果发生异常，则通过 result 回调异常
+ 50:                     if (ex != null) {
+ 51:                         result.tryFailure(ex);
+ 52:                         return;
+ 53:                     }
+ 54:
+ 55:                     // 如果未设置阻塞时间，直接通知 result 失败。因为是 tryLock ，只是尝试加锁一次，不会无限重试。
+ 56:                     if (waitTime == -1) {
+ 57:                         result.trySuccess(false);
+ 58:                         return;
+ 59:                     }
+ 60:
+ 61:                     // 重置整个获得锁的过程，在剩余的时间里，重新来一遍
+ 62:                     // 重置 failedLocksLimit 变量
+ 63:                     failedLocksLimit = failedLocksLimit();
+ 64:                     // 重置 acquiredLocks 为空
+ 65:                     acquiredLocks.clear();
+ 66:                     // reset iterator
+ 67:                     // 重置 iterator 设置回迭代器的头
+ 68:                     while (iterator.hasPrevious()) {
+ 69:                         iterator.previous();
+ 70:                     }
+ 71:
+ 72:                     // 校验剩余时间是否足够
+ 73:                     checkRemainTimeAsync(iterator, result);
+ 74:                 });
+ 75:                 return;
+ 76:             } else {
+ 77:                 failedLocksLimit--;
+ 78:             }
+ 79:         }
+ 80:
+ 81:         // 校验剩余时间是否足够
+ 82:         checkRemainTimeAsync(iterator, result);
+ 83:     });
+ 84: }
+```
+
+- 第 2 至 6 行：如果迭代 `iterator` 的尾部，则调用 `#checkLeaseTimeAsync(RPromise<Boolean> result)` 方法，重新设置每个锁的过期时间。代码如下：
+
+  ```
+  // RedissonMultiLock.LockState.java
+  
+  private void checkLeaseTimeAsync(RPromise<Boolean> result) {
+      // 如果设置了锁的过期时间 leaseTime ，则重新设置每个锁的过期时间
+      if (leaseTime != -1) {
+          // 创建 AtomicInteger 计数器，用于回调逻辑的计数，从而判断是不是所有回调都执行完了
+          AtomicInteger counter = new AtomicInteger(acquiredLocks.size());
+          // 遍历 acquiredLocks 数组，逐个设置过期时间
+          for (RLock rLock : acquiredLocks) {
+              // 创建异步设置过期时间的 RFuture
+              RFuture<Boolean> future = ((RedissonLock) rLock).expireAsync(unit.toMillis(leaseTime), TimeUnit.MILLISECONDS);
+              future.onComplete((res, e) -> {
+                  // 如果发生异常，则通过 result 回调异常
+                  if (e != null) {
+                      result.tryFailure(e);
+                      return;
+                  }
+  
+                  // 如果全部成功，则通过 result 回调加锁成功
+                  if (counter.decrementAndGet() == 0) {
+                      result.trySuccess(true);
+                  }
+              });
+          }
+          return;
+      }
+  
+      // 如果未设置了锁的过期时间 leaseTime ，则通过 result 回调加锁成功
+      result.trySuccess(true);
+  }
+  ```
+
+  - 对标到 [「3.4 tryLock(long waitTime, long leaseTime, TimeUnit unit)」](https://svip.iocoder.cn/Redisson/RedLock/#) 的第 96 至 109 行。
+
+- 第 8 至 79 行：对标到 [「3.4 tryLock(long waitTime, long leaseTime, TimeUnit unit)」](https://svip.iocoder.cn/Redisson/RedLock/#) 的第 28 至 81 行。
+
+- 第 73 和 82 行：调用 `#checkRemainTimeAsync(ListIterator<RLock> iterator, RPromise<Boolean> result)` 方法，校验剩余时间是否足够。代码如下：
+
+  ```
+  // RedissonMultiLock.LockState.java
+  
+  private void checkRemainTimeAsync(ListIterator<RLock> iterator, RPromise<Boolean> result) {
+      // 如果设置了等待超时时间，计算剩余时间 remainTime
+      if (remainTime != -1) {
+          remainTime += -(System.currentTimeMillis() - time);
+          // 记录新的当前时间
+          time = System.currentTimeMillis();
+          // 如果没有剩余时间，意味着已经超时，释放所有加载成功的锁
+          if (remainTime <= 0) {
+              // 创建释放所有已获得到锁们的 Future
+              unlockInnerAsync(acquiredLocks, threadId).onComplete((res, e) -> {
+                  // 如果发生异常，则通过 result 回调异常
+                  if (e != null) {
+                      result.tryFailure(e);
+                      return;
+                  }
+  
+                  // 如果全部成功，则通过 result 回调加锁成功
+                  result.trySuccess(false);
+              });
+              // return 返回结束
+              return;
+          }
+      }
+  
+      // <Y> 如果未设置等待超时时间，则继续加锁下一个 RLock
+      tryAcquireLockAsync(iterator, result);
+  }
+  ```
+
+  - 对标到 [「3.4 tryLock(long waitTime, long leaseTime, TimeUnit unit)」](https://svip.iocoder.cn/Redisson/RedLock/#) 的第 83 至 93 行。
+  - 注意，`<Y>` 处，会递归调用 `#tryAcquireLockAsync(ListIterator<RLock> iterator, RPromise<Boolean> result)` 方法，继续加锁下一个 RLock 。
+
+😈 总的来说，还是蛮简单的不是，哈哈哈哈。
+
+## 3.6 lock
+
+`#lockInterruptibly(long leaseTime, TimeUnit unit)` 方法，同步**加锁**，不返回加锁是否成功。代码如下：
+
+```
+// RedissonMultiLock.java
+
+@Override
+public void lock() {
+    try {
+        lockInterruptibly();
+    } catch (InterruptedException e) {
+        Thread.currentThread().interrupt();
+    }
+}
+
+@Override
+public void lock(long leaseTime, TimeUnit unit) {
+    try {
+        lockInterruptibly(leaseTime, unit);
+    } catch (InterruptedException e) {
+        Thread.currentThread().interrupt();
+    }
+}
+
+@Override
+public void lockInterruptibly() throws InterruptedException {
+    lockInterruptibly(-1, null);
+}
+
+  1: @Override
+  2: public void lockInterruptibly(long leaseTime, TimeUnit unit) throws InterruptedException {
+  3:     // 计算 waitTime 时间
+  4:     long baseWaitTime = locks.size() * 1500;
+  5:     long waitTime = -1;
+  6:     if (leaseTime == -1) { // 如果未设置超时时间，则直接使用 baseWaitTime
+  7:         waitTime = baseWaitTime;
+  8:     } else {
+  9:         leaseTime = unit.toMillis(leaseTime);
+ 10:         waitTime = leaseTime;
+ 11:         if (waitTime <= 2000) { // 保证最小 waitTime 时间是 2000
+ 12:             waitTime = 2000;
+ 13:         } else if (waitTime <= baseWaitTime) { // 在 [waitTime / 2, waitTime) 之间随机
+ 14:             waitTime = ThreadLocalRandom.current().nextLong(waitTime / 2, waitTime);
+ 15:         } else { // 在 [baseWaitTime, waitTime) 之间随机
+ 16:             waitTime = ThreadLocalRandom.current().nextLong(baseWaitTime, waitTime);
+ 17:         }
+ 18:     }
+ 19:
+ 20:     // 死循环，直到加锁成功
+ 21:     while (true) {
+ 22:         if (tryLock(waitTime, leaseTime, TimeUnit.MILLISECONDS)) {
+ 23:             return;
+ 24:         }
+ 25:     }
+ 26: }
+```
+
+- 第 2 至 18 行：计算 `waitTime` 时间。😈 我也没弄懂，为啥是这么设计，难道是因为经验值？后面去细细的翻查下原因。
+- 第 20 至 25 行：死循环，调用 [3.4 `#tryLock(long waitTime, long leaseTime, TimeUnit unit)`](https://svip.iocoder.cn/Redisson/RedLock/#) 方法，直到加锁成功。
+
+## 3.7 lockAsync
+
+`#lockAsync(long leaseTime, TimeUnit unit, long threadId)` 方法，异步**加锁**，不返回加锁是否成功。代码如下：
+
+```
+// RedissonMultiLock.java
+
+@Override
+public RFuture<Void> lockAsync(long leaseTime, TimeUnit unit) {
+    return lockAsync(leaseTime, unit, Thread.currentThread().getId());
+}
+
+  1: @Override
+  2: public RFuture<Void> lockAsync(long leaseTime, TimeUnit unit, long threadId) {
+  3:     // 计算 waitTime 时间
+  4:     long baseWaitTime = locks.size() * 1500;
+  5:     long waitTime;
+  6:     if (leaseTime == -1) { // 如果未设置超时时间，则直接使用 baseWaitTime
+  7:         waitTime = baseWaitTime;
+  8:     } else {
+  9:         leaseTime = unit.toMillis(leaseTime);
+ 10:         waitTime = leaseTime;
+ 11:         if (waitTime <= 2000) { // 保证最小 waitTime 时间是 2000
+ 12:             waitTime = 2000;
+ 13:         } else if (waitTime <= baseWaitTime) { // 在 [waitTime / 2, waitTime) 之间随机
+ 14:             waitTime = ThreadLocalRandom.current().nextLong(waitTime / 2, waitTime);
+ 15:         } else { // 在 [baseWaitTime, waitTime) 之间随机
+ 16:             waitTime = ThreadLocalRandom.current().nextLong(baseWaitTime, waitTime);
+ 17:         }
+ 18:     }
+ 19:
+ 20:     // 创建 RPromise 对象
+ 21:     RPromise<Void> result = new RedissonPromise<Void>();
+ 22:     // 执行异步加锁
+ 23:     tryLockAsync(threadId, leaseTime, TimeUnit.MILLISECONDS, waitTime, result);
+ 24:     return result;
+ 25: }
+```
+
+- 第 3 至 18 行：计算 `waitTime` 时间。和 `#lockInterruptibly(long leaseTime, TimeUnit unit)` 方法，看到的逻辑是一致的。
+
+- 第 23 行：调用 `#tryLockAsync(long threadId, long leaseTime, TimeUnit unit, long waitTime, RPromise<Void> result)` 方法，执行异步加锁。代码如下：
+
+  ```
+  // RedissonMultiLock.java
+  
+  protected void tryLockAsync(long threadId, long leaseTime, TimeUnit unit, long waitTime, RPromise<Void> result) {
+      // <X1> 执行异步加锁锁
+      tryLockAsync(waitTime, leaseTime, unit, threadId).onComplete((res, e) -> {
+          // 如果发生异常，则通过 result 回调异常
+          if (e != null) {
+              result.tryFailure(e);
+              return;
+          }
+  
+          // <X2> 如果加锁成功，则通知 result 成功
+          if (res) {
+              result.trySuccess(null);
+          // <X3> 如果加锁失败，则递归调用 tryLockAsync 方法
+          } else {
+              tryLockAsync(threadId, leaseTime, unit, waitTime, result);
+          }
+      });
+  }
+  ```
+
+  - `<X1>` 处，调用 [3.5 `#tryLockAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId)`](https://svip.iocoder.cn/Redisson/RedLock/#) 方法，执行异步加锁锁。
+  - `<X2>` 处，如果加锁成功，则通知 `result` 成功。
+  - `<X3>` 处，如果加锁失败，则递归调用 `#lockAsync(long leaseTime, TimeUnit unit, long threadId)`（自己）方法，继续执行异步加锁。
+
+## 3.8 unlock
+
+`#unlock()` 方法，同步**解锁**。代码如下：
+
+```
+// RedissonMultiLock.java
+
+@Override
+public void unlock() {
+    // 创建 RFuture 数组
+    List<RFuture<Void>> futures = new ArrayList<>(locks.size());
+
+    // 逐个创建异步解锁 Future，并添加到 futures 数组中
+    for (RLock lock : locks) {
+        futures.add(lock.unlockAsync());
+    }
+
+    // 同步阻塞 futures ，全部释放完成
+    for (RFuture<Void> future : futures) {
+        future.syncUninterruptibly();
+    }
+}
+```
+
+在 RedissonMultiLock 类中，存在一个 `#unlockInner(Collection<RLock> locks)` 方法，同步**解锁**指定 RLock 数组。代码如下：
+
+```
+// RedissonMultiLock.java
+
+protected void unlockInner(Collection<RLock> locks) {
+    // 创建 RFuture 数组
+    List<RFuture<Void>> futures = new ArrayList<>(locks.size());
+
+    // 逐个创建异步解锁 Future，并添加到 futures 数组中
+    for (RLock lock : locks) {
+        futures.add(lock.unlockAsync());
+    }
+
+    // 同步阻塞 futures ，全部释放完成
+    for (RFuture<Void> unlockFuture : futures) {
+        unlockFuture.awaitUninterruptibly();
+    }
+}
+```
+
+在 RedissonMultiLock 类中，存在一个 `#unlockInner(Collection<RLock> locks)` 方法，异步**解锁**指定 RLock 数组。代码如下：
+
+```
+// RedissonMultiLock.java
+
+protected RFuture<Void> unlockInnerAsync(Collection<RLock> locks, long threadId) {
+    // 如果 locks 为空，直接返回成功的 RFuture
+    if (locks.isEmpty()) {
+        return RedissonPromise.newSucceededFuture(null);
+    }
+
+    // 创建 RPromise 对象
+    RPromise<Void> result = new RedissonPromise<Void>();
+    // 创建 AtomicInteger 计数器，用于回调逻辑的计数，从而判断是不是所有回调都执行完了
+    AtomicInteger counter = new AtomicInteger(locks.size());
+    // 遍历 acquiredLocks 数组，逐个解锁
+    for (RLock lock : locks) {
+        lock.unlockAsync(threadId).onComplete((res, e) -> {
+            // 如果发生异常，则通过 result 回调异常
+            if (e != null) {
+                result.tryFailure(e);
+                return;
+            }
+
+            // 如果全部成功，则通过 result 回调解锁成功
+            if (counter.decrementAndGet() == 0) {
+                result.trySuccess(null);
+            }
+        });
+    }
+    return result;
+}
+```
+
+## 3.9 未实现的方法
+
+在 RedissonMultiLock 中，因为一些方法暂时没必要实现，所以就都未提供。如下：
+
+```
+// RedissonMultiLock.java
+
+@Override
+public Condition newCondition() {
+    throw new UnsupportedOperationException();
+}
+
+@Override
+public RFuture<Boolean> forceUnlockAsync() {
+    throw new UnsupportedOperationException();
+}
+
+@Override
+public RFuture<Integer> getHoldCountAsync() {
+    throw new UnsupportedOperationException();
+}
+
+@Override
+public String getName() {
+    throw new UnsupportedOperationException();
+}
+
+@Override
+public boolean forceUnlock() {
+    throw new UnsupportedOperationException();
+}
+
+@Override
+public boolean isLocked() {
+    throw new UnsupportedOperationException();
+}
+
+@Override
+public RFuture<Boolean> isLockedAsync() {
+    throw new UnsupportedOperationException();
+}
+
+@Override
+public boolean isHeldByThread(long threadId) {
+    throw new UnsupportedOperationException();
+}
+
+@Override
+public boolean isHeldByCurrentThread() {
+    throw new UnsupportedOperationException();
+}
+
+@Override
+public int getHoldCount() {
+    throw new UnsupportedOperationException();
+}
+
+@Override
+public RFuture<Long> remainTimeToLiveAsync() {
+    throw new UnsupportedOperationException();
+}
+
+@Override
+public long remainTimeToLive() {
+    throw new UnsupportedOperationException();
+}
+```
+
+# 666. 彩蛋
+
+一开始，以为 RedLock 红锁的代码会比较复杂，所以在撸这块的源码时，有点懵逼。一度计划，准备花小 1 天的时间来研究和输出这篇博客。结果发现，竟然是个纸老虎，哈哈哈。
+
+😈 所以把，碰到任何源码，都不要怂。该肝就肝！
+
+爽，在 2019-10-05 的 01:30 写完了这篇博客，美滋滋。
\ No newline at end of file
diff --git a/redis/file-create.py b/redis/file-create.py
new file mode 100644
index 0000000..a412975
--- /dev/null
+++ b/redis/file-create.py
@@ -0,0 +1,27 @@
+import os
+import pyperclip
+
+# 获取当前脚本的路径
+script_dir = os.path.dirname(os.path.abspath(__file__))
+
+# 从剪贴板获取文件名列表，假设每行一个文件名
+file_names = pyperclip.paste().strip().split('\n')
+
+# 遍历文件名列表，为每个文件名添加排序前缀并创建文件
+for index, file_name in enumerate(file_names, start=1):
+    # 去除文件名两端的空白字符
+    file_name = file_name.strip()
+    
+    # 添加排序前缀和.md后缀
+    file_name_with_prefix = f"{index:02d}-{file_name}.md"  # 这里使用3位数的排序前缀，可以根据需要调整
+    
+    # 构建文件的完整路径
+    file_path = os.path.join(script_dir, file_name_with_prefix)
+    
+    # 创建文件
+    with open(file_path, 'w') as file:
+        # 如果需要写入初始内容，可以在这里添加
+        # 例如：file.write("This is the content of the file.")
+        pass  # 如果不需要写入内容，则使用pass
+
+print(f"Files created successfully in {script_dir}")
\ No newline at end of file
diff --git a/redis/tmp.txt b/redis/tmp.txt
new file mode 100644
index 0000000..6ef0cef
--- /dev/null
+++ b/redis/tmp.txt
@@ -0,0 +1,5 @@
+Redis 源码分析-调试环境搭建（Redis 6.X 版本）
+Redisson 源码分析-调试环境搭建
+Redisson 源码分析-限流器 RateLimiter
+Redisson 源码分析-可重入分布式锁 ReentrantLock
+Redisson 源码分析-可靠分布式锁 RedLock
\ No newline at end of file
diff --git a/spring/01-精尽 Spring 面试题.assets/01.jpg b/spring/01-精尽 Spring 面试题.assets/01.jpg
new file mode 100644
index 0000000..3a54ee5
Binary files /dev/null and b/spring/01-精尽 Spring 面试题.assets/01.jpg differ
diff --git a/spring/01-精尽 Spring 面试题.assets/02.jpg b/spring/01-精尽 Spring 面试题.assets/02.jpg
new file mode 100644
index 0000000..82e742d
Binary files /dev/null and b/spring/01-精尽 Spring 面试题.assets/02.jpg differ
diff --git a/spring/01-精尽 Spring 面试题.assets/03.jpg b/spring/01-精尽 Spring 面试题.assets/03.jpg
new file mode 100644
index 0000000..0ce47a2
Binary files /dev/null and b/spring/01-精尽 Spring 面试题.assets/03.jpg differ
diff --git a/spring/01-精尽 Spring 面试题.assets/04.jpg b/spring/01-精尽 Spring 面试题.assets/04.jpg
new file mode 100644
index 0000000..4c8765f
Binary files /dev/null and b/spring/01-精尽 Spring 面试题.assets/04.jpg differ
diff --git a/spring/01-精尽 Spring 面试题.assets/05.jpg b/spring/01-精尽 Spring 面试题.assets/05.jpg
new file mode 100644
index 0000000..91677da
Binary files /dev/null and b/spring/01-精尽 Spring 面试题.assets/05.jpg differ
diff --git a/spring/01-精尽 Spring 面试题.assets/06.png b/spring/01-精尽 Spring 面试题.assets/06.png
new file mode 100644
index 0000000..c4bf9c9
Binary files /dev/null and b/spring/01-精尽 Spring 面试题.assets/06.png differ
diff --git a/spring/01-精尽 Spring 面试题.assets/07.png b/spring/01-精尽 Spring 面试题.assets/07.png
new file mode 100644
index 0000000..21dcece
Binary files /dev/null and b/spring/01-精尽 Spring 面试题.assets/07.png differ
diff --git a/spring/01-精尽 Spring 面试题.assets/08.png b/spring/01-精尽 Spring 面试题.assets/08.png
new file mode 100644
index 0000000..2a8fa1a
Binary files /dev/null and b/spring/01-精尽 Spring 面试题.assets/08.png differ
diff --git a/spring/01-精尽 Spring 面试题.assets/09.jpg b/spring/01-精尽 Spring 面试题.assets/09.jpg
new file mode 100644
index 0000000..2acfa46
Binary files /dev/null and b/spring/01-精尽 Spring 面试题.assets/09.jpg differ
diff --git a/spring/01-精尽 Spring 面试题.md b/spring/01-精尽 Spring 面试题.md
new file mode 100644
index 0000000..d6afeb5
--- /dev/null
+++ b/spring/01-精尽 Spring 面试题.md	
@@ -0,0 +1,1416 @@
+# 精尽 Spring 面试题「最新更新时间：2024-02」
+
+以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。
+
+如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的 Spring 面试题的大保健。
+
+而题目的难度，艿艿尽量按照从容易到困难的顺序，逐步下去。
+
+> 注意 1 ，这个面试题，暂时不包括 Spring MVC 部分。主要以 Spring IoC、Spring AOP、Spring Transaction 为主。
+>
+> 注意 2 ，T T Spring 怎么会有这么多问题，艿艿自己面试很多都不太问，跟背书一样。所以整理的过程，真的是痛苦万分。
+
+Spring 是一个很庞大的技术体系，可以说包容一切，所以本文我们按照下面的顺序，罗列各种面试题：
+
+- Spring **整体**相关的面试
+- Spring **IoC** 相关的面试题
+- Spring **AOP** 相关的面试题
+- Spring **Transaction** 相关的面试题
+- Spring **Data Access** 相关的面试题
+
+# Spring 整体
+
+## 什么是 Spring Framework？
+
+Spring 是一个开源应用框架，旨在降低应用程序开发的复杂度。
+
+- 它是轻量级、松散耦合的。
+
+  > 它的轻量级主要是相对于 EJB 。随着 Spring 的体系越来越庞大，大家被 Spring 的配置搞懵逼了，所以后来出了 Spring Boot 。
+
+- 它具有分层体系结构，允许用户选择组件，同时还为 J2EE 应用程序开发提供了一个有凝聚力的框架。
+
+- 它可以集成其他框架，如 Spring MVC、Hibernate、MyBatis 等，所以又称为框架的框架( 粘合剂、脚手架 )。
+
+## Spring Framework 中有多少个模块，它们分别是什么？
+
+如下是一张比较早期版本的 Spring Framework 的模块图：
+
+> 艿艿：因为它的配色比较好看，哈哈哈哈。所以，没自己画一个最新的。
+
+[![Spring Framework](01-精尽 Spring 面试题.assets/01.jpg)](http://static.iocoder.cn/images/Spring/2018-12-24/01.jpg)Spring Framework
+
+我们按照一个一个分块来说。
+
+**Spring 核心容器**
+
+> 对应图中，Core Container 。
+
+该层基本上是 Spring Framework 的核心。它包含以下模块：
+
+- Spring Core
+
+- Spring Bean
+
+  > 核心容器提供 Spring 框架的基本功能。核心容器的主要组件是 BeanFactory，它是工厂模式的实现。BeanFactory 使用控制反转 （IOC）模式将应用程序的配置和依赖性规范与实际的应用程序代码分开。
+
+- Spring Context
+
+  > Spring 上下文是一个配置文件，向 Spring 框架提供上下文信息。Spring 上下文包括企业服务，例如 JNDI、EJB、电子邮件、国际化、事件机制、校验和调度功能。
+
+- SpEL (Spring Expression Language)
+
+  > Spring 表达式语言全称为 “Spring Expression Language”，缩写为 “SpEL” ，类似于 Struts2 中使用的 OGNL 表达式语言，能在运行时构建复杂表达式、存取对象图属性、对象方法调用等等，并且能与 Spring 功能完美整合，如能用来配置 Bean 定义。
+
+或者说，这块就是 Spring IoC 。
+
+**数据访问**
+
+> 对应图中，Data Access 。
+
+该层提供与数据库交互的支持。它包含以下模块：
+
+- JDBC (Java DataBase Connectivity)
+
+  > Spring 对 JDBC 的封装模块，提供了对关系数据库的访问。
+
+- ORM (Object Relational Mapping)
+
+  > Spring ORM 模块，提供了对 hibernate5 和 JPA 的集成。
+  >
+  > - hibernate5 是一个 ORM 框架。
+  > - JPA 是一个 Java 持久化 API 。
+
+- OXM (Object XML Mappers)
+
+  > Spring 提供了一套类似 ORM 的映射机制，用来将 Java 对象和 XML 文件进行映射。这就是 Spring 的对象 XML 映射功能，有时候也成为 XML 的序列化和反序列化。
+  >
+  > 用的比较少，胖友了解下即可。
+
+- Transaction
+
+  > Spring 简单而强大的事务管理功能，包括声明式事务和编程式事务。
+
+**Web**
+
+该层提供了创建 Web 应用程序的支持。它包含以下模块：
+
+- WebMVC
+
+  > MVC 框架是一个全功能的构建 Web 应用程序的 MVC 实现。通过策略接口，MVC 框架变成为高度可配置的，MVC 容纳了大量视图技术，其中包括 JSP、Velocity、Tiles、iText 和 POI。
+
+- WebFlux
+
+  > 基于 Reactive 库的响应式的 Web 开发框架
+  >
+  > 不了解的胖友，可以看看 [《使用 Spring 5 的 WebFlux 开发反应式 Web 应用》](https://www.ibm.com/developerworks/cn/java/spring5-webflux-reactive/index.html)
+
+- WebSocket
+
+  > Spring 4.0 的一个最大更新是增加了对 Websocket 的支持。
+  >
+  > Websocket 提供了一个在 Web 应用中实现高效、双向通讯，需考虑客户端(浏览器)和服务端之间高频和低延时消息交换的机制。
+  >
+  > 一般的应用场景有：在线交易、网页聊天、游戏、协作、数据可视化等。
+
+- ~~Portlet~~ 已经废弃
+
+**AOP**
+
+该层支持面向切面编程。它包含以下模块：
+
+- AOP
+
+  > 通过配置管理特性，Spring AOP 模块直接将面向方面的编程功能集成到了 Spring 框架中。所以，可以很容易地使 Spring 框架管理的任何对象支持 AOP。
+  >
+  > Spring AOP 模块为基于 Spring 的应用程序中的对象提供了事务管理服务。通过使用 Spring AOP，不用依赖 EJB 组件，就可以将声明性事务管理集成到应用程序中。
+
+- Aspects
+
+  > 该模块为与 AspectJ 的集成提供支持。
+
+- Instrumentation
+
+  > 该层为类检测和类加载器实现提供支持。
+  >
+  > 用的比较少，胖友了解下即可。
+
+**其它**
+
+- JMS (Java Messaging Service)
+
+  > 提供了一个 JMS 集成框架，简化了 JMS API 的使用。
+  >
+  > 可能有胖友不太了解 JMS ，可以看看 [《JMS(Java消息服务)入门教程》](https://www.cnblogs.com/chenpi/p/5559349.html) 。
+
+- Test
+
+  > 该模块为使用 JUnit 和 TestNG 进行测试提供支持。
+
+- Messaging
+
+  > 该模块为 STOMP 提供支持。它还支持注解编程模型，该模型用于从 WebSocket 客户端路由和处理 STOMP 消息。
+
+## 使用 Spring 框架能带来哪些好处？
+
+下面列举了一些使用 Spring 框架带来的主要好处：
+
+> 艿艿：注意，下文中加粗的内容，这是本句话的关键。
+
+- **DI** ：**[Dependency Injection(DI)](http://howtodoinjava.com/2013/03/19/inversion-of-control-ioc-and-dependency-injection-di-patterns-in-spring-framework-and-related-interview-questions/)** 方法，使得构造器和 JavaBean、properties 文件中的依赖关系一目了然。
+- **轻量级**：与 EJB 容器相比较，IoC 容器更加趋向于**轻量级**。这样一来 IoC 容器在有限的内存和 CPU 资源的情况下，进行应用程序的开发和发布就变得十分有利。
+- **面向切面编程(AOP)**： Spring 支持面向**切面编程**，同时把应用的业务逻辑与系统的服务分离开来。
+- **集成主流框架**：Spring 并没有闭门造车，Spring **集成**了已有的技术栈，比如 ORM 框架、Logging 日期框架、J2EE、Quartz 和 JDK Timer ，以及其他视图技术。
+- 模块化：Spring 框架是按照**模块**的形式来组织的。由包和类的命名，就可以看出其所属的模块，开发者仅仅需要选用他们需要的模块即可。
+- **便捷的测试**：要 [测试一项用Spring开发的应用程序](http://howtodoinjava.com/2013/04/19/how-to-unit-test-spring-security-authentication-with-junit/) 十分简单，因为**测试**相关的环境代码都已经囊括在框架中了。更加简单的是，利用 JavaBean 形式的 POJO 类，可以很方便的利用依赖注入来写入测试数据。
+- **Web 框架**：Spring 的 **Web 框架**亦是一个精心设计的 Web MVC 框架，为开发者们在 Web 框架的选择上提供了一个除了主流框架比如 Struts 、过度设计的、不流行 Web 框架的以外的有力选项。
+- **事务管理**：Spring 提供了一个便捷的**事务管理**接口，适用于小型的本地事物处理（比如在单 DB 的环境下）和复杂的共同事物处理（比如利用 JTA 的复杂 DB 环境）。
+- **异常处理**：Spring 提供一个方便的 API ，将特定技术的异常(由JDBC, Hibernate, 或 JDO 抛出)转化为一致的、Unchecked 异常。
+
+当然，Spring 代码优点的同时，一定会带来相应的缺点：
+
+- 每个框架都有的问题，调试阶段不直观，后期的 bug 对应阶段，不容易判断问题所在。要花一定的时间去理解它。
+
+- 把很多 JavaEE 的东西封装了，在满足快速开发高质量程序的同时，隐藏了实现细节。
+
+  > 这就导致，很多工程师，离开了 Spring 之后，就不知道怎么工作了。从 Java 工程师，变成了 Spring 工程师。对于有追求的我们，还是需要知其然，知其所以然。
+
+## Spring 框架中都用到了哪些设计模式？
+
+Spring 框架中使用到了大量的设计模式，下面列举了比较有代表性的：
+
+- 代理模式 — 在 AOP 和 remoting 中被用的比较多。
+- 单例模式 — 在 Spring 配置文件中定义的 Bean 默认为单例模式。
+- 模板方法 — 用来解决代码重复的问题。比如 [RestTemplate](http://howtodoinjava.com/2015/02/20/spring-restful-client-resttemplate-example/)、JmsTemplate、JdbcTemplate 。
+- 前端控制器 — Spring提供了 DispatcherServlet 来对请求进行分发。
+- 视图帮助(View Helper) — Spring 提供了一系列的 JSP 标签，高效宏来辅助将分散的代码整合在视图里。
+- 依赖注入 — 贯穿于 BeanFactory / ApplicationContext 接口的核心理念。
+- 工厂模式 — BeanFactory 用来创建对象的实例。
+
+当然，感兴趣的胖友，觉得不过瘾，可以看看艿艿基友知秋写的几篇文章：
+
+- [《Spring 框架中的设计模式(一)》](http://www.iocoder.cn/Spring/DesignPattern-1)
+- [《Spring 框架中的设计模式(二)》](http://www.iocoder.cn/Spring/DesignPattern-2)
+- [《Spring 框架中的设计模式(三)》](http://www.iocoder.cn/Spring/DesignPattern-3)
+- [《Spring 框架中的设计模式(四)》](http://www.iocoder.cn/Spring/DesignPattern-4)
+- [《Spring 框架中的设计模式(五)》](http://www.iocoder.cn/Spring/DesignPattern-5)
+
+# Spring IoC
+
+> 下面，我们会将分成 IoC 和 Bean 两部分来分享 Spring 容器的内容。
+>
+> - IoC ，侧重在于容器。
+> - Bean ，侧重在于被容器管理的 Bean 。
+
+## 什么是 Spring IoC 容器？
+
+> 注意，正确的拼写是 IoC 。
+
+Spring 框架的核心是 Spring IoC 容器。容器创建 Bean 对象，将它们装配在一起，配置它们并管理它们的完整生命周期。
+
+- Spring 容器使用**依赖注入**来管理组成应用程序的 Bean 对象。
+- 容器通过读取提供的**配置元数据** Bean Definition 来接收对象进行实例化，配置和组装的指令。
+- 该配置元数据 Bean Definition 可以通过 XML，Java 注解或 Java Config 代码**提供**。
+
+> 艿艿，注意上面三段段话的**加粗**部分的内容。
+
+[![Spring IoC](01-精尽 Spring 面试题.assets/02.jpg)](http://static.iocoder.cn/images/Spring/2018-12-24/02.jpg)Spring IoC
+
+## 什么是依赖注入？
+
+在依赖注入中，你不必主动、手动创建对象，但必须描述如何创建它们。
+
+- 你不是直接在代码中将组件和服务连接在一起，而是描述配置文件中哪些组件需要哪些服务。
+- 然后，再由 IoC 容器将它们装配在一起。
+
+另外，依赖注入的英文缩写是 Dependency Injection ，简称 DI 。
+
+## IoC 和 DI 有什么区别？
+
+> 艿艿的吐槽，最怕这种概念题。下面引用知乎上的一个讨论：[《IoC 和DI 有什么区别？》](https://www.zhihu.com/question/25392984)
+
+IoC 是个更宽泛的概念，DI 是更具体的。引用郑烨的一篇博客，引用郑烨的一篇博客，[我眼中的Spring](https://link.zhihu.com/?target=http%3A//dreamhead.blogbus.com/logs/125334.html)
+
+> **Dependency Injection**
+> 原来，它叫 IoC 。
+> Martin Flower 发话了，是个框架都有 IoC ，这不足以新生容器反转的“如何定位插件的具体实现”，于是，它有了个新名字，Dependency Injection 。
+>
+> 其实，它就是一种将调用者与被调用者分离的思想，Uncle Bob 管它叫DIP（Dependency Inversion Principle），并把它归入OO设计原则。
+> 同 Spring 相比，它更早进入我的大脑。一切都是那么朦胧，直至 Spring 出现。
+>
+> 慢慢的，我知道了它还分为三种：
+>
+> - Interface Injection（type 1）
+> - Setter Injection（type 2）
+> - Constructor Injection（type 3）。
+>
+> Martin Flower那篇为它更名的大作让我心目关于它的一切趋于完整。
+>
+> 在 Spring 中，它是一切的基础。Spring 的种种优势随之而来。
+> 于我而言，它为我带来更多的是思维方式的转变，恐怕以后我再也无法写出那种一大块的全功能程序了。
+
+## 可以通过多少种方式完成依赖注入？
+
+通常，依赖注入可以通过**三种**方式完成，即：
+
+> 上面一个问题的三种方式的英文，下面是三种方式的中文。
+
+- 接口注入
+- 构造函数注入
+- setter 注入
+
+目前，在 Spring Framework 中，仅使用构造函数和 setter 注入这**两种**方式。
+
+那么这两种方式各有什么优缺点呢？胖友可以简单阅读 [《Spring两种依赖注入方式的比较》](https://my.oschina.net/itblog/blog/203746)，不用太较真。综述来说：
+
+| 构造函数注入               | setter 注入                |
+| :------------------------- | :------------------------- |
+| 没有部分注入               | 有部分注入                 |
+| 不会覆盖 setter 属性       | 会覆盖 setter 属性         |
+| 任意修改都会创建一个新实例 | 任意修改不会创建一个新实例 |
+| 适用于设置很多属性         | 适用于设置少量属性         |
+
+- 实际场景下，setting 注入使用的更多。
+
+## Spring 中有多少种 IoC 容器？
+
+Spring 提供了两种( 不是“个” ) IoC 容器，分别是 BeanFactory、ApplicationContext 。
+
+**BeanFactory**
+
+> BeanFactory 在 `spring-beans` 项目提供。
+
+BeanFactory ，就像一个包含 Bean 集合的工厂类。它会在客户端要求时实例化 Bean 对象。
+
+**ApplicationContext**
+
+> ApplicationContext 在 `spring-context` 项目提供。
+
+ApplicationContext 接口扩展了 BeanFactory 接口，它在 BeanFactory 基础上提供了一些额外的功能。内置如下功能：
+
+- MessageSource ：管理 message ，实现国际化等功能。
+- ApplicationEventPublisher ：事件发布。
+- ResourcePatternResolver ：多资源加载。
+- EnvironmentCapable ：系统 Environment（profile + Properties）相关。
+- Lifecycle ：管理生命周期。
+- Closable ：关闭，释放资源
+- InitializingBean：自定义初始化。
+- BeanNameAware：设置 beanName 的 Aware 接口。
+
+另外，ApplicationContext 会自动初始化非懒加载的 Bean 对象们。
+
+详细的内容，感兴趣的胖友，可以看看 [《【死磕 Spring】—— ApplicationContext 相关接口架构分析》](http://svip.iocoder.cn/Spring/ApplicationContext/) 一文。源码之前无秘密。简单总结下 BeanFactory 与 ApplicationContext 两者的差异：
+
+> 艿艿：可能很多胖友没看过源码，所以会比较难。
+
+| BeanFactory                | ApplicationContext       |
+| :------------------------- | :----------------------- |
+| 它使用懒加载               | 它使用即时加载           |
+| 它使用语法显式提供资源对象 | 它自己创建和管理资源对象 |
+| 不支持国际化               | 支持国际化               |
+| 不支持基于依赖的注解       | 支持基于依赖的注解       |
+
+另外，BeanFactory 也被称为**低级**容器，而 ApplicationContext 被称为**高级**容器。
+
+## 请介绍下常用的 BeanFactory 容器？
+
+BeanFactory 最常用的是 XmlBeanFactory 。它可以根据 XML 文件中定义的内容，创建相应的 Bean。
+
+## 请介绍下常用的 ApplicationContext 容器？
+
+以下是三种较常见的 ApplicationContext 实现方式：
+
+- 1、ClassPathXmlApplicationContext ：从 ClassPath 的 XML 配置文件中读取上下文，并生成上下文定义。应用程序上下文从程序环境变量中取得。示例代码如下：
+
+  ```
+  ApplicationContext context = new ClassPathXmlApplicationContext(“bean.xml”);
+  ```
+
+- 2、FileSystemXmlApplicationContext ：由文件系统中的XML配置文件读取上下文。示例代码如下：
+
+  ```
+  ApplicationContext context = new FileSystemXmlApplicationContext(“bean.xml”);
+  ```
+
+- 3、XmlWebApplicationContext ：由 Web 应用的XML文件读取上下文。例如我们在 Spring MVC 使用的情况。
+
+当然，目前我们更多的是使用 Spring Boot 为主，所以使用的是第四种 ApplicationContext 容器，ConfigServletWebServerApplicationContext 。
+
+## 列举一些 IoC 的一些好处？
+
+- 它将最小化应用程序中的代码量。
+- 它以最小的影响和最少的侵入机制促进松耦合。
+- 它支持即时的实例化和延迟加载 Bean 对象。
+- 它将使您的应用程序易于测试，因为它不需要单元测试用例中的任何单例或 JNDI 查找机制。
+
+## 简述 Spring IoC 的实现机制？
+
+简单来说，Spring 中的 IoC 的实现原理，就是**工厂模式**加**反射机制**。代码如下：
+
+```
+interface Fruit {
+
+     public abstract void eat();
+     
+}
+class Apple implements Fruit {
+
+    public void eat(){
+        System.out.println("Apple");
+    }
+    
+}
+class Orange implements Fruit {
+    public void eat(){
+        System.out.println("Orange");
+    }
+}
+
+class Factory {
+
+    public static Fruit getInstance(String className) {
+        Fruit f = null;
+        try {
+            f = (Fruit) Class.forName(className).newInstance();
+        } catch (Exception e) {
+            e.printStackTrace();
+        }
+        return f;
+    }
+    
+}
+
+class Client {
+
+    public static void main(String[] args) {
+        Fruit f = Factory.getInstance("io.github.dunwu.spring.Apple");
+        if(f != null){
+            f.eat();
+        }
+    }
+    
+}
+```
+
+- Fruit 接口，有 Apple 和 Orange 两个实现类。
+- Factory 工厂，通过反射机制，创建 `className` 对应的 Fruit 对象。
+- Client 通过 Factory 工厂，获得对应的 Fruit 对象。
+- 😈 实际情况下，Spring IoC 比这个复杂很多很多，例如单例 Bean 对象，Bean 的属性注入，相互依赖的 Bean 的处理，以及等等。
+
+在基友 [《面试问烂的 Spring IoC 过程》](http://www.iocoder.cn/Fight/Interview-poorly-asked-Spring-IOC-process-1/) 的文章中，把 Spring IoC 相关的内容，讲的非常不错。
+
+## Spring 框架中有哪些不同类型的事件？
+
+Spring 的 ApplicationContext 提供了支持事件和代码中监听器的功能。
+
+我们可以创建 Bean 用来监听在 ApplicationContext 中发布的事件。如果一个 Bean 实现了 ApplicationListener 接口，当一个ApplicationEvent 被发布以后，Bean 会自动被通知。示例代码如下：
+
+```
+public class AllApplicationEventListener implements ApplicationListener<ApplicationEvent> {  
+    
+    @Override  
+    public void onApplicationEvent(ApplicationEvent applicationEvent) {  
+        // process event  
+    }
+    
+}
+```
+
+Spring 提供了以下五种标准的事件：
+
+1. 上下文更新事件（ContextRefreshedEvent）：该事件会在ApplicationContext 被初始化或者更新时发布。也可以在调用ConfigurableApplicationContext 接口中的 `#refresh()` 方法时被触发。
+2. 上下文开始事件（ContextStartedEvent）：当容器调用ConfigurableApplicationContext 的 `#start()` 方法开始/重新开始容器时触发该事件。
+3. 上下文停止事件（ContextStoppedEvent）：当容器调用 ConfigurableApplicationContext 的 `#stop()` 方法停止容器时触发该事件。
+4. 上下文关闭事件（ContextClosedEvent）：当ApplicationContext 被关闭时触发该事件。容器被关闭时，其管理的所有单例 Bean 都被销毁。
+5. 请求处理事件（RequestHandledEvent）：在 We b应用中，当一个HTTP 请求（request）结束触发该事件。
+
+------
+
+除了上面介绍的事件以外，还可以通过扩展 ApplicationEvent 类来开发**自定义**的事件。
+
+① 示例自定义的事件的类，代码如下：
+
+```
+public class CustomApplicationEvent extends ApplicationEvent{  
+
+    public CustomApplicationEvent(Object source, final String msg) {  
+        super(source);
+    }  
+
+}
+```
+
+② 为了监听这个事件，还需要创建一个监听器。示例代码如下：
+
+```
+public class CustomEventListener implements ApplicationListener<CustomApplicationEvent> {
+
+    @Override  
+    public void onApplicationEvent(CustomApplicationEvent applicationEvent) {  
+        // handle event  
+    }
+    
+}
+```
+
+③ 之后通过 ApplicationContext 接口的 `#publishEvent(Object event)` 方法，来发布自定义事件。示例代码如下：
+
+```
+// 创建 CustomApplicationEvent 事件
+CustomApplicationEvent customEvent = new CustomApplicationEvent(applicationContext, "Test message");
+// 发布事件
+applicationContext.publishEvent(customEvent);
+```
+
+# Spring Bean
+
+## 什么是 Spring Bean ？
+
+- Bean 由 Spring IoC 容器实例化，配置，装配和管理。
+- Bean 是基于用户提供给 IoC 容器的配置元数据 Bean Definition 创建。
+
+这个问题，胖友可以在回过头看 [「什么是 Spring IoC 容器？」](https://svip.iocoder.cn/Spring/Interview/#) 问题，相互对照。
+
+## Spring 有哪些配置方式
+
+单纯从 Spring Framework 提供的方式，一共有三种：
+
+- 1、XML 配置文件。
+
+  Bean 所需的依赖项和服务在 XML 格式的配置文件中指定。这些配置文件通常包含许多 bean 定义和特定于应用程序的配置选项。它们通常以 bean 标签开头。例如：
+
+  ```
+  <bean id="studentBean" class="org.edureka.firstSpring.StudentBean">
+      <property name="name" value="Edureka"></property>
+  </bean>
+  ```
+
+- 2、注解配置。
+
+  您可以通过在相关的类，方法或字段声明上使用注解，将 Bean 配置为组件类本身，而不是使用 XML 来描述 Bean 装配。默认情况下，Spring 容器中未打开注解装配。因此，您需要在使用它之前在 Spring 配置文件中启用它。例如：
+
+  ```
+  <beans>
+  <context:annotation-config/>
+  <!-- bean definitions go here -->
+  </beans>
+  ```
+
+- 3、Java Config 配置。
+
+  Spring 的 Java 配置是通过使用 @Bean 和 @Configuration 来实现。
+
+  - `@Bean` 注解扮演与 `<bean />` 元素相同的角色。
+
+  - `@Configuration` 类允许通过简单地调用同一个类中的其他 `@Bean` 方法来定义 Bean 间依赖关系。
+
+  - 例如：
+
+    ```
+    @Configuration
+    public class StudentConfig {
+        
+        @Bean
+        public StudentBean myStudent() {
+            return new StudentBean();
+        }
+        
+    }
+    ```
+
+    - 是不是很熟悉 😈
+
+目前主要使用 **Java Config** 配置为主。当然，三种配置方式是可以混合使用的。例如说：
+
+- Dubbo 服务的配置，艿艿喜欢使用 XML 。
+- Spring MVC 请求的配置，艿艿喜欢使用 `@RequestMapping` 注解。
+- Spring MVC 拦截器的配置，艿艿喜欢 Java Config 配置。
+
+------
+
+另外，现在已经是 Spring Boot 的天下，所以更加是 **Java Config** 配置为主。
+
+## Spring 支持几种 Bean Scope ？
+
+> 艿艿，这个是一个比较小众的题目，简单了解即可。
+
+Spring Bean 支持 5 种 Scope ，分别如下：
+
+- Singleton - 每个 Spring IoC 容器仅有一个单 Bean 实例。**默认**
+- Prototype - 每次请求都会产生一个新的实例。
+- Request - 每一次 HTTP 请求都会产生一个新的 Bean 实例，并且该 Bean 仅在当前 HTTP 请求内有效。
+- Session - 每一个的 Session 都会产生一个新的 Bean 实例，同时该 Bean 仅在当前 HTTP Session 内有效。
+- Application - 每一个 Web Application 都会产生一个新的 Bean ，同时该 Bean 仅在当前 Web Application 内有效。
+
+> 另外，网络上很多文章说有 Global-session 级别，它是 Portlet 模块独有，目前已经废弃，在 Spring5 中是找不到的。
+
+仅当用户使用支持 Web 的 ApplicationContext 时，**最后三个才可用**。
+
+再补充一点，开发者是可以**自定义** Bean Scope ，具体可参见 [《Spring（10）—— Bean 作用范围（二）—— 自定义 Scope》](https://blog.csdn.net/elim168/article/details/75581670) 。
+
+不错呢，还是那句话，这个题目简单了解下即可，实际常用的只有 Singleton 和 Prototype 两种级别，甚至说，只有 Singleton 级别。😈
+
+## Spring Bean 在容器的生命周期是什么样的？
+
+> 艿艿说：这是一个比较高级的 Spring 的面试题，非常常见，并且答对比较加分。当然，如果实际真正弄懂，需要对 Spring Bean 的源码，有比较好的理解，所以 [《精尽 Spring 源码》](http://svip.iocoder.cn/categories/Spring/) 系列，该读还是读吧。
+
+> 艿艿：要注意下面每段话，艿艿进行加粗的地方。
+
+Spring Bean 的**初始化**流程如下：
+
+- 实例化 Bean 对象
+
+  - Spring 容器根据配置中的 Bean Definition(定义)中**实例化** Bean 对象。
+
+    > Bean Definition 可以通过 XML，Java 注解或 Java Config 代码提供。
+
+  - Spring 使用依赖注入**填充**所有属性，如 Bean 中所定义的配置。
+
+- Aware 相关的属性，注入到 Bean 对象
+
+  - 如果 Bean 实现 **BeanNameAware** 接口，则工厂通过传递 Bean 的 beanName 来调用 `#setBeanName(String name)` 方法。
+  - 如果 Bean 实现 **BeanFactoryAware** 接口，工厂通过传递自身的实例来调用 `#setBeanFactory(BeanFactory beanFactory)` 方法。
+
+- 调用相应的方法，进一步初始化 Bean 对象
+
+  - 如果存在与 Bean 关联的任何 **BeanPostProcessor** 们，则调用 `#preProcessBeforeInitialization(Object bean, String beanName)` 方法。
+  - 如果 Bean 实现 **InitializingBean** 接口，则会调用 `#afterPropertiesSet()` 方法。
+  - 如果为 Bean 指定了 **init** 方法（例如 `<bean />` 的 `init-method` 属性），那么将调用该方法。
+  - 如果存在与 Bean 关联的任何 **BeanPostProcessor** 们，则将调用 `#postProcessAfterInitialization(Object bean, String beanName)` 方法。
+
+Spring Bean 的**销毁**流程如下：
+
+- 如果 Bean 实现 **DisposableBean** 接口，当 spring 容器关闭时，会调用 `#destroy()` 方法。
+- 如果为 bean 指定了 **destroy** 方法（例如 `<bean />` 的 `destroy-method` 属性），那么将调用该方法。
+
+整体如下图：[![流程图](01-精尽 Spring 面试题.assets/03.jpg)](http://static.iocoder.cn/images/Spring/2018-12-24/03.jpg)流程图
+
+无意中，艿艿又翻到一张有趣的整体图，如下图：
+
+[![流程图](01-精尽 Spring 面试题.assets/08.png)](http://static.iocoder.cn/images/Spring/2018-12-24/08.png)流程图
+
+## 什么是 Spring 的内部 bean？
+
+只有将 Bean **仅**用作另一个 Bean 的属性时，才能将 Bean 声明为内部 Bean。
+
+- 为了定义 Bean，Spring 提供基于 XML 的配置元数据在 `<property>`或 `<constructor-arg>` 中提供了 `<bean>`元素的使用。
+- 内部 Bean 总是**匿名**的，并且它们总是作为**原型 Prototype** 。
+
+例如，假设我们有一个 Student 类，其中引用了 Person 类。这里我们将只创建一个 Person 类实例并在 Student 中使用它。示例代码如下：
+
+```
+// Student.java
+
+public class Student {
+
+    private Person person;
+    
+    // ... Setters and Getters
+}
+
+// Person.java
+
+public class Person {
+
+    private String name;
+    private String address;
+    
+    // ... Setters and Getters
+}
+<!-- bean.xml -->
+
+<bean id=“StudentBean" class="com.edureka.Student">
+    <property name="person">
+        <!--This is inner bean -->
+        <bean class="com.edureka.Person">
+            <property name="name" value=“Scott"></property>
+            <property name="address" value=“Bangalore"></property>
+        </bean>
+    </property>
+</bean>
+```
+
+## 什么是 Spring 装配？
+
+当 Bean 在 Spring 容器中组合在一起时，它被称为**装配**或 **Bean 装配**。Spring 容器需要知道需要什么 Bean 以及容器应该如何使用依赖注入来将 Bean 绑定在一起，同时装配 Bean 。
+
+> 装配，和上文提到的 DI 依赖注入，实际是一个东西。
+
+**自动装配有哪些方式？**
+
+Spring 容器能够自动装配 Bean 。也就是说，可以通过检查 BeanFactory 的内容让 Spring 自动解析 Bean 的协作者。
+
+自动装配的不同模式：
+
+- no - 这是默认设置，表示没有自动装配。应使用显式 Bean 引用进行装配。
+- byName - 它根据 Bean 的名称注入对象依赖项。它匹配并装配其属性与 XML 文件中由相同名称定义的 Bean 。
+- 【最常用】**byType** - 它根据类型注入对象依赖项。如果属性的类型与 XML 文件中的一个 Bean 类型匹配，则匹配并装配属性。
+- 构造函数 - 它通过调用类的构造函数来注入依赖项。它有大量的参数。
+- autodetect - 首先容器尝试通过构造函数使用 autowire 装配，如果不能，则尝试通过 byType 自动装配。
+
+**自动装配有什么局限？**
+
+> 艿艿：这个题目，了解下即可，也不是很准确。
+
+- 覆盖的可能性 - 您始终可以使用 `<constructor-arg>` 和 `<property>` 设置指定依赖项，这将覆盖自动装配。
+
+- 基本元数据类型 - 简单属性（如原数据类型，字符串和类）无法自动装配。
+
+  > 这种，严格来说，也不能称为局限。因为可以通过配置文件来解决。
+
+- 令人困惑的性质 - 总是喜欢使用明确的装配，因为自动装配不太精确。
+
+## 解释什么叫延迟加载？
+
+默认情况下，容器启动之后会将所有作用域为**单例**的 Bean 都创建好，但是有的业务场景我们并不需要它提前都创建好。此时，我们可以在Bean 中设置 `lzay-init = "true"` 。
+
+- 这样，当容器启动之后，作用域为单例的 Bean ，就不在创建。
+- 而是在获得该 Bean 时，才真正在创建加载。
+
+## Spring 框架中的单例 Bean 是线程安全的么？
+
+Spring 框架并没有对[单例](http://howtodoinjava.com/2012/10/22/singleton-design-pattern-in-java/) Bean 进行任何多线程的封装处理。
+
+- 关于单例 Bean 的[线程安全](http://howtodoinjava.com/2014/06/02/what-is-thread-safety/)和并发问题，需要开发者自行去搞定。
+- 并且，单例的线程安全问题，也不是 Spring 应该去关心的。Spring 应该做的是，提供根据配置，创建单例 Bean 或多例 Bean 的功能。
+
+当然，但实际上，大部分的 Spring Bean 并没有可变的状态(比如Serview 类和 DAO 类)，所以在某种程度上说 Spring 的单例 Bean 是线程安全的。
+
+如果你的 Bean 有多种状态的话，就需要自行保证线程安全。最浅显的解决办法，就是将多态 Bean 的作用域( Scope )由 Singleton 变更为 Prototype 。
+
+## Spring Bean 怎么解决循环依赖的问题？
+
+> 艿艿说：能回答出这个问题的，一般是比较厉害的。
+
+这是个比较复杂的问题，有能力的胖友，建议看下 [《【死磕 Spring】—— IoC 之加载 Bean：创建 Bean（五）之循环依赖处理》](http://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-5/)
+
+感觉，不通过源码，很难解释清楚这个问题。如果看不懂的胖友，可以在认真看完，在星球里，我们一起多交流下。好玩的。
+
+# Spring 注解
+
+这块内容，实际写在 [「Spring Bean」](https://svip.iocoder.cn/Spring/Interview/#) 中比较合适，考虑到后续的问题，都是关于注解的，所以单独起一个大的章节。
+
+## 什么是基于注解的容器配置？
+
+不使用 XML 来描述 Bean 装配，开发人员通过在相关的类，方法或字段声明上使用**注解**将配置移动到组件类本身。它可以作为 XML 设置的替代方案。例如：
+
+Spring 的 Java 配置是通过使用 `@Bean` 和 `@Configuration` 来实现。
+
+- `@Bean` 注解，扮演与 `<bean />` 元素相同的角色。
+- `@Configuration` 注解的类，允许通过简单地调用同一个类中的其他 `@Bean` 方法来定义 Bean 间依赖关系。
+
+示例如下：
+
+```
+@Configuration
+public class StudentConfig {
+
+    @Bean
+    public StudentBean myStudent() {
+        return new StudentBean();
+    }
+    
+}
+```
+
+## 如何在 Spring 中启动注解装配？
+
+默认情况下，Spring 容器中未打开注解装配。因此，要使用基于注解装配，我们必须通过配置 `<context：annotation-config />` 元素在 Spring 配置文件中启用它。
+
+当然，如果胖友是使用 Spring Boot ，默认情况下已经开启。
+
+## @Component, @Controller, @Repository, @Service 有何区别？
+
+- `@Component` ：它将 Java 类标记为 Bean 。它是任何 Spring 管理组件的**通用**构造型。
+- `@Controller` ：它将一个类标记为 Spring Web MVC **控制器**。
+- `@Service` ：此注解是组件注解的特化。它不会对 `@Component` 注解提供任何其他行为。您可以在**服务层**类中使用 @Service 而不是 `@Component` ，因为它以更好的方式指定了意图。
+- `@Repository` ：这个注解是具有类似用途和功能的 `@Component` 注解的特化。它为 **DAO** 提供了额外的好处。它将 DAO 导入 IoC 容器，并使未经检查的异常有资格转换为 Spring DataAccessException 。
+
+## @Required 注解有什么用？
+
+`@Required` 注解，应用于 Bean 属性 setter 方法。
+
+- 此注解仅指示必须在配置时使用 Bean 定义中的显式属性值或使用自动装配填充受影响的 Bean 属性。
+- 如果尚未填充受影响的 Bean 属性，则容器将抛出 BeanInitializationException 异常。
+
+示例代码如下：
+
+```
+public class Employee {
+
+    private String name;
+    
+    @Required
+    public void setName(String name){
+        this.name=name;
+    }
+    
+    public string getName(){
+        return name;
+    }
+    
+}
+```
+
+- T T 貌似平时很少用这个注解噢。
+
+## @Autowired 注解有什么用？
+
+`@Autowired` 注解，可以更准确地控制应该在何处以及如何进行自动装配。
+
+- 此注解用于在 setter 方法，构造函数，具有任意名称或多个参数的属性或方法上自动装配 Bean。
+- 默认情况下，它是类型驱动的注入。
+
+示例代码如下：
+
+```
+public class EmpAccount {
+    
+    @Autowired
+    private Employee emp;
+    
+}
+```
+
+## @Qualifier 注解有什么用？
+
+当你创建多个**相同类型**的 Bean ，并希望仅使用属性装配**其中一个** Bean 时，您可以使用 `@Qualifier` 注解和 `@Autowired` 通过指定 ID 应该装配哪个**确切的** Bean 来消除歧义。
+
+例如，应用中有两个类型为 Employee 的 Bean ID 为 `"emp1"` 和 `"emp2"` ，此处，我们希望 EmployeeAccount Bean 注入 `"emp1"` 对应的 Bean 对象。代码如下：
+
+```
+public class EmployeeAccount {
+
+    @Autowired
+    @Qualifier(emp1)
+    private Employee emp;
+
+}
+```
+
+# Spring AOP
+
+> Spring AOP 的面试题中，大多数都是概念题，主要是对切面的理解。概念点主要有：
+>
+> - AOP
+> - Aspect
+> - JoinPoint
+> - PointCut
+> - Advice
+> - Target
+> - AOP Proxy
+> - Weaving
+
+- 在阅读完 [「Spring AOP」](https://svip.iocoder.cn/Spring/Interview/#) 的面试题后，在回过头思考下这些概念点，到底理解了多少。注意，不是背，理解！
+
+非常推荐阅读如下两篇文章：
+
+- [《彻底征服 Spring AOP 之理论篇》](https://segmentfault.com/a/1190000007469968)
+- [《彻底征服 Spring AOP 之实战篇》](https://segmentfault.com/a/1190000007469982)
+
+## 什么是 AOP ？
+
+AOP(Aspect-Oriented Programming)，即**面向切面编程**, 它与 OOP( Object-Oriented Programming, 面向对象编程) 相辅相成， 提供了与 OOP 不同的抽象软件结构的视角。
+
+- 在 OOP 中，以类( Class )作为基本单元
+- 在 AOP 中，以**切面( Aspect )**作为基本单元。
+
+## 什么是 Aspect ？
+
+Aspect 由 **PointCut** 和 **Advice** 组成。
+
+- 它既包含了横切逻辑的定义，也包括了连接点的定义。
+- Spring AOP 就是负责实施切面的框架，它将切面所定义的横切逻辑编织到切面所指定的连接点中。
+
+AOP 的工作重心在于如何将增强编织目标对象的连接点上, 这里包含两个工作:
+
+1. 如何通过 PointCut 和 Advice 定位到特定的 **JoinPoint** 上。
+2. 如何在 Advice 中编写切面代码。
+
+**可以简单地认为, 使用 @Aspect 注解的类就是切面**
+
+[![流程图](01-精尽 Spring 面试题.assets/04.jpg)](http://static.iocoder.cn/images/Spring/2018-12-24/04.jpg)流程图
+
+## 什么是 JoinPoint ?
+
+JoinPoint ，**切点**，程序运行中的一些时间点, 例如：
+
+- 一个方法的执行。
+- 或者是一个异常的处理。
+
+在 Spring AOP 中，JoinPoint 总是方法的执行点。
+
+## 什么是 PointCut ？
+
+PointCut ，**匹配** JoinPoint 的谓词(a predicate that matches join points)。
+
+> 简单来说，PointCut 是匹配 JoinPoint 的条件。
+
+- Advice 是和特定的 PointCut 关联的，并且在 PointCut 相匹配的 JoinPoint 中执行。即 `Advice => PointCut => JoinPoint` 。
+- 在 Spring 中, 所有的方法都可以认为是 JoinPoint ，但是我们并不希望在所有的方法上都添加 Advice 。**而 PointCut 的作用**，就是提供一组规则(使用 AspectJ PointCut expression language 来描述) 来匹配 JoinPoint ，给满足规则的 JoinPoint 添加 Advice 。
+
+😈 是不是觉得有点绕，实际场景下，其实也不会弄的这么清楚~~
+
+## 关于 JoinPoint 和 PointCut 的区别
+
+JoinPoint 和 PointCut 本质上就是**两个不同纬度上**的东西。
+
+- 在 Spring AOP 中，所有的方法执行都是 JoinPoint 。而 PointCut 是一个描述信息，它修饰的是 JoinPoint ，通过 PointCut ，我们就可以确定哪些 JoinPoint 可以被织入 Advice 。
+- Advice 是在 JoinPoint 上执行的，而 PointCut 规定了哪些 JoinPoint 可以执行哪些 Advice 。
+
+或者，我们在换一种说法：
+
+1. 首先，Advice 通过 PointCut 查询需要被织入的 JoinPoint 。
+2. 然后，Advice 在查询到 JoinPoint 上执行逻辑。
+
+## 什么是 Advice ？
+
+Advice ，**通知**。
+
+- 特定 JoinPoint 处的 Aspect 所采取的动作称为 Advice 。
+- Spring AOP 使用一个 Advice 作为拦截器，在 JoinPoint “周围”维护一系列的**拦截器**。
+
+**有哪些类型的 Advice？**
+
+- Before - 这些类型的 Advice 在 JoinPoint 方法之前执行，并使用 `@Before` 注解标记进行配置。
+- After Returning - 这些类型的 Advice 在连接点方法正常执行后执行，并使用 `@AfterReturning` 注解标记进行配置。
+- After Throwing - 这些类型的 Advice 仅在 JoinPoint 方法通过抛出异常退出并使用 `@AfterThrowing` 注解标记配置时执行。
+- After Finally - 这些类型的 Advice 在连接点方法之后执行，无论方法退出是正常还是异常返回，并使用 `@After` 注解标记进行配置。
+- Around - 这些类型的 Advice 在连接点之前和之后执行，并使用 `@Around` 注解标记进行配置。
+
+😈 看起来，是不是和拦截器的执行时间，有几分相似。实际上，用于拦截效果的各种实现，大体都是类似的。
+
+## 什么是 Target ？
+
+Target ，织入 Advice 的**目标对象**。目标对象也被称为 **Advised Object** 。
+
+- 因为 Spring AOP 使用运行时代理的方式来实现 Aspect ，因此 Advised Object 总是一个代理对象(Proxied Object) 。
+- **注意, Advised Object 指的不是原来的对象，而是织入 Advice 后所产生的代理对象**。
+- Advice + Target Object = Advised Object = Proxy 。
+
+## AOP 有哪些实现方式？
+
+实现 AOP 的技术，主要分为两大类：
+
+- ① **静态代理** - 指使用 AOP 框架提供的命令进行编译，从而在编译阶段就可生成 AOP 代理类，因此也称为编译时增强。
+
+  - 编译时编织（特殊编译器实现）
+
+  - 类加载时编织（特殊的类加载器实现）。
+
+    > 例如，SkyWalking 基于 Java Agent 机制，配置上 ByteBuddy 库，实现类加载时编织时增强，从而实现链路追踪的透明埋点。
+    >
+    > 感兴趣的胖友，可以看看 [《SkyWalking 源码分析之 JavaAgent 工具 ByteBuddy 的应用》](http://www.kailing.pub/article/index/arcid/178.html) 。
+
+- ② **动态代理** - 在运行时在内存中“临时”生成 AOP 动态代理类，因此也被称为运行时增强。目前 Spring 中使用了两种动态代理库：
+
+  - JDK 动态代理
+  - CGLIB
+
+那么 Spring 什么时候使用 JDK 动态代理，什么时候使用 CGLIB 呢？
+
+```
+// From 《Spring 源码深度解析》P172
+// Spring AOP 部分使用 JDK 动态代理或者 CGLIB 来为目标对象创建代理。（建议尽量使用 JDK 的动态代理）
+// 如果被代理的目标对象实现了至少一个接口，则会使用 JDK 动态代理。所有该目标类型实现的接口都讲被代理。
+// 若该目标对象没有实现任何接口，则创建一个 CGLIB 代理。
+// 如果你希望强制使用 CGLIB 代理，（例如希望代理目标对象的所有方法，而不只是实现自接口的方法）那也可以。但是需要考虑以下两个方法：
+//      1> 无法通知(advise) Final 方法，因为它们不能被覆盖。
+//      2> 你需要将 CGLIB 二进制发型包放在 classpath 下面。
+// 为什么 Spring 默认使用 JDK 的动态代理呢？笔者猜测原因如下：
+//      1> 使用 JDK 原生支持，减少三方依赖
+//      2> JDK8 开始后，JDK 代理的性能差距 CGLIB 的性能不会太多。可参见：https://www.cnblogs.com/haiq/p/4304615.html
+```
+
+- 实际上，Spring AOP 的代码量不大，与其在窗户外面不清不楚，不如捅破它！感兴趣的胖友，可以撸一撸 [《精尽 Spring 源码分析 —— AOP 源码简单导读》](http://svip.iocoder.cn/Spring/aop-simple-intro/) 。
+
+或者，我们来换一个解答答案：
+
+Spring AOP 中的动态代理主要有两种方式，
+
+- JDK 动态代理
+
+  JDK 动态代理通过反射来接收被代理的类，并且要求被代理的类必须实现一个接口。JDK动态代理的核心是 InvocationHandler 接口和 Proxy 类。
+
+- CGLIB 动态代理
+
+  如果目标类没有实现接口，那么 Spring AOP 会选择使用 CGLIB 来动态代理目标类。当然，Spring 也支持配置，**强制**使用 CGLIB 动态代理。
+  CGLIB（Code Generation Library），是一个代码生成的类库，可以在运行时动态的生成某个类的子类，注意，CGLIB 是通过继承的方式做的动态代理，因此如果某个类被标记为 `final` ，那么它是无法使用 CGLIB 做动态代理的。
+
+## Spring AOP and AspectJ AOP 有什么区别？
+
+- 代理方式不同
+  - Spring AOP 基于动态代理方式实现。
+  - AspectJ AOP 基于静态代理方式实现。
+- PointCut 支持力度不同
+  - Spring AOP **仅**支持方法级别的 PointCut 。
+  - AspectJ AOP 提供了完全的 AOP 支持，它还支持属性级别的 PointCut 。
+
+## 什么是编织（Weaving）？
+
+Weaving ，**编织**。
+
+- 为了创建一个 Advice 对象而链接一个 Aspect 和其它应用类型或对象，称为编织（Weaving）。
+- 在 Spring AOP 中，编织在运行时执行，即动态代理。请参考下图：[![Proxy](01-精尽 Spring 面试题.assets/05.jpg)](http://static.iocoder.cn/images/Spring/2018-12-24/05.jpg)Proxy
+
+## Spring 如何使用 AOP 切面？
+
+在 Spring AOP 中，有两种方式配置 AOP 切面：
+
+- 基于 **XML** 方式的切面实现。
+- 基于 **注解** 方式的切面实现。
+
+目前，主流喜欢使用 **注解** 方式。胖友可以看看 [《彻底征服 Spring AOP 之实战篇》](https://segmentfault.com/a/1190000007469982) 。
+
+# Spring Transaction
+
+非常推荐阅读如下文章：
+
+- [《可能是最漂亮的 Spring 事务管理详解》](https://mp.weixin.qq.com/s?__biz=MzUzMTA2NTU2Ng==&mid=2247484702&idx=1&sn=c04261d63929db09ff6df7cadc7cca21&chksm=fa497aafcd3ef3b94082da7bca841b5b7b528eb2a52dbc4eb647b97be63a9a1cf38a9e71bf90&token=165108535&lang=zh_CN#rd)
+
+## 什么是事务？
+
+事务就是对一系列的数据库操作（比如插入多条数据）进行统一的提交或回滚操作，如果插入成功，那么一起成功，如果中间有一条出现异常，那么回滚之前的所有操作。
+
+这样可以防止出现脏数据，防止数据库数据出现问题。
+
+## 事务的特性指的是？
+
+指的是 **ACID** ，如下图所示：
+
+[![事务的特性](01-精尽 Spring 面试题.assets/06.png)](http://static.iocoder.cn/images/Spring/2018-12-24/06.png)事务的特性
+
+1. **原子性** Atomicity ：一个事务（transaction）中的所有操作，或者全部完成，或者全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被恢复（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。即，事务不可分割、不可约简。
+2. **一致性** Consistency ：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设[约束](https://zh.wikipedia.org/wiki/数据完整性)、[触发器](https://zh.wikipedia.org/wiki/触发器_(数据库))、[级联回滚](https://zh.wikipedia.org/w/index.php?title=级联回滚&action=edit&redlink=1)等。
+3. **隔离性** Isolation ：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。
+4. **持久性** Durability ：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。
+
+## 列举 Spring 支持的事务管理类型？
+
+目前 Spring 提供两种类型的事务管理：
+
+- **声明式**事务：通过使用注解或基于 XML 的配置事务，从而事务管理与业务代码分离。
+- **编程式**事务：通过编码的方式实现事务管理，需要在代码中显式的调用事务的获得、提交、回滚。它为您提供极大的灵活性，但维护起来非常困难。
+
+实际场景下，我们一般使用 Spring Boot + 注解的**声明式**事务。具体的示例，胖友可以看看 [《Spring Boot 事务注解详解》](https://www.jianshu.com/p/cddeca2c9245) 。
+
+另外，也推荐看看 [《Spring 事务管理 － 编程式事务、声明式事务》](https://blog.csdn.net/xktxoo/article/details/77919508) 一文。
+
+## Spring 事务如何和不同的数据持久层框架做集成？
+
+① 首先，我们先明确下，这里数据持久层框架，指的是 Spring JDBC、Hibernate、Spring JPA、MyBatis 等等。
+
+② 然后，Spring 事务的管理，是通过 `org.springframework.transaction.PlatformTransactionManager` 进行管理，定义如下：
+
+```
+// PlatformTransactionManager.java
+
+public interface PlatformTransactionManager {
+
+    // 根据事务定义 TransactionDefinition ，获得 TransactionStatus 。 
+    TransactionStatus getTransaction(@Nullable TransactionDefinition definition) throws TransactionException;
+
+    // 根据情况，提交事务
+    void commit(TransactionStatus status) throws TransactionException;
+    
+    // 根据情况，回滚事务
+    void rollback(TransactionStatus status) throws TransactionException;
+    
+}
+```
+
+- PlatformTransactionManager 是负责事务管理的接口，一共有三个接口方法，分别负责事务的获得、提交、回滚。
+
+- ```
+  #getTransaction(TransactionDefinition definition)
+  ```
+
+   
+
+  方法，根据事务定义 TransactionDefinition ，获得 TransactionStatus 。
+
+  - 为什么不是创建事务呢？因为如果当前如果已经有事务，则不会进行创建，一般来说会跟当前线程进行绑定。如果不存在事务，则进行创建。
+  - 为什么返回的是 TransactionStatus 对象？在 TransactionStatus 中，不仅仅包含事务属性，还包含事务的其它信息，例如是否只读、是否为新创建的事务等等。😈 下面，也会详细解析 TransactionStatus 。
+  - 事务 TransactionDefinition 是什么？😈 下面，也会详细解析 TransactionStatus 。
+
+- ```
+  #commit(TransactionStatus status)
+  ```
+
+   
+
+  方法，根据 TransactionStatus 情况，提交事务。
+
+  - 为什么根据 TransactionStatus 情况，进行提交？例如说，带
+
+    ```
+    @Transactional
+    ```
+
+     
+
+    注解的的 A 方法，会调用
+
+     
+
+    ```
+    @Transactional
+    ```
+
+     
+
+    注解的的 B 方法。
+
+    - 在 B 方法结束调用后，会执行 `PlatformTransactionManager#commit(TransactionStatus status)` 方法，此处事务**是不能**、**也不会**提交的。
+    - 而是在 A 方法结束调用后，执行 `PlatformTransactionManager#commit(TransactionStatus status)` 方法，提交事务。
+
+- ```
+  #rollback(TransactionStatus status)
+  ```
+
+   
+
+  方法，根据 TransactionStatus 情况，回滚事务。
+
+  - 为什么根据 TransactionStatus 情况，进行回滚？原因同 `#commit(TransactionStatus status)` 方法。
+
+③ 再之后，PlatformTransactionManager 有**抽象子**类 `org.springframework.transaction.support.AbstractPlatformTransactionManager` ，基于 [模板方法模式](https://blog.csdn.net/carson_ho/article/details/54910518) ，实现事务整体逻辑的骨架，而抽象 `#doCommit(DefaultTransactionStatus status)`、`#doRollback(DefaultTransactionStatus status)` 等等方法，交由子类类来实现。
+
+> 前方高能，即将进入关键的 ④ 步骤。
+
+④ 最后，不同的数据持久层框架，会有其对应的 PlatformTransactionManager 实现类，如下图所示：[![事务的特性](01-精尽 Spring 面试题.assets/07.png)](http://static.iocoder.cn/images/Spring/2018-12-24/07.png)事务的特性
+
+- 所有的实现类，都基于 AbstractPlatformTransactionManager 这个骨架类。
+- HibernateTransactionManager ，和 Hibernate5 的事务管理做集成。
+- DataSourceTransactionManager ，和 JDBC 的事务管理做集成。所以，它也适用于 MyBatis、Spring JDBC 等等。
+- JpaTransactionManager ，和 JPA 的事务管理做集成。
+
+如下，是一个比较常见的 XML 方式来配置的事务管理器，使用的是 DataSourceTransactionManager 。代码如下：
+
+```
+<!-- 事务管理器 -->
+<bean id="transactionManager"
+class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
+    <!-- 数据源 -->
+    <property name="dataSource" ref="dataSource" />
+</bean>
+```
+
+- 正如上文所说，它适用于 MyBatis、Spring JDBC 等等。
+
+------
+
+😈 是不是很有趣，更多详细的解析，可见如下几篇文章：
+
+- [《精尽 Spring 源码分析 —— Transaction 源码简单导读》](http://svip.iocoder.cn/categories/Spring/)
+- [《精尽 MyBatis 源码分析 —— 事务模块》](http://svip.iocoder.cn/MyBatis/transaction-package/)
+- [《精尽 MyBatis 源码解析 —— Spring 集成（四）之事务》](http://svip.iocoder.cn/MyBatis/Spring-Integration-4/)
+
+## 为什么在 Spring 事务中不能切换数据源？
+
+做过 Spring 多数据源的胖友，都会有个惨痛的经历，为什么在开启事务的 Service 层的方法中，无法切换数据源呢？因为，在 Spring 的事务管理中，**所使用的数据库连接会和当前线程所绑定**，即使我们设置了另外一个数据源，使用的还是当前的数据源连接。
+
+另外，多个数据源且需要事务的场景，本身会带来**多事务一致性**的问题，暂时没有特别好的解决方案。
+
+所以一般一个应用，推荐除非了读写分离所带来的多数据源，其它情况下，建议只有一个数据源。并且，随着微服务日益身形，一个服务对应一个 DB 是比较常见的架构选择。
+
+## @Transactional 注解有哪些属性？如何使用？
+
+`@Transactional` 注解的**属性**如下：
+
+| 属性                   | 类型                               | 描述                                   |
+| :--------------------- | :--------------------------------- | :------------------------------------- |
+| value                  | String                             | 可选的限定描述符，指定使用的事务管理器 |
+| propagation            | enum: Propagation                  | 可选的事务传播行为设置                 |
+| isolation              | enum: Isolation                    | 可选的事务隔离级别设置                 |
+| readOnly               | boolean                            | 读写或只读事务，默认读写               |
+| timeout                | int (in seconds granularity)       | 事务超时时间设置                       |
+| rollbackFor            | Class对象数组，必须继承自Throwable | 导致事务回滚的异常类数组               |
+| rollbackForClassName   | 类名数组，必须继承自Throwable      | 导致事务回滚的异常类名字数组           |
+| noRollbackFor          | Class对象数组，必须继承自Throwable | 不会导致事务回滚的异常类数组           |
+| noRollbackForClassName | 类名数组，必须继承自Throwable      | 不会导致事务回滚的异常类名字数组       |
+
+- 一般情况下，我们直接使用 `@Transactional` 的所有属性默认值即可。
+
+具体**用法**如下：
+
+- `@Transactional` 可以作用于接口、接口方法、类以及类方法上。当作用于类上时，该类的所有 `public` 方法将都具有该类型的事务属性，同时，我们也可以在方法级别使用该标注来覆盖类级别的定义。
+- 虽然 `@Transactional` 注解可以作用于接口、接口方法、类以及类方法上，但是 Spring 建议不要在接口或者接口方法上使用该注解，因为这只有在使用基于接口的代理时它才会生效。另外， **`@Transactional` 注解应该只被应用到 `public` 方法上，这是由 Spring AOP 的本质决定的**。如果你在 `protected`、`private` 或者默认可见性的方法上使用 `@Transactional` 注解，这将被忽略，也不会抛出任何异常。**这一点，非常需要注意**。
+
+------
+
+下面，我们来简单说下**源码**相关的东西。
+
+`@Transactional` 注解的属性，会解析成 `org.springframework.transaction.TransactionDefinition` 对象，即事务定义。TransactionDefinition 代码如下：
+
+```
+public interface TransactionDefinition {
+
+	int getPropagationBehavior(); // 事务的传播行为
+	int getIsolationLevel(); // 事务的隔离级别
+	int getTimeout(); // 事务的超时时间
+	boolean isReadOnly(); // 事务是否只读
+	@Nullable
+	String getName(); // 事务的名字
+
+}
+```
+
+- 可能会胖友有以后，`@Transactional` 注解的 `rollbackFor`、`rollbackForClassName`、`noRollbackFor`、`noRollbackForClassName` 属性貌似没体现出来？它们提现在 TransactionDefinition 的实现类 RuleBasedTransactionAttribute 中。
+- `#getPropagationBehavior()` 方法，返回事务的**传播行为**，该值是个枚举，在下面来说。
+- `#getIsolationLevel()` 方法，返回事务的**隔离级别**，该值是个枚举，在下面来说。
+
+## 什么是事务的隔离级别？分成哪些隔离级别？
+
+关于这个问题，涉及的内容会比较多，胖友直接看如下两篇文章：
+
+- [《数据库四大特性以及事务隔离级别》](https://zhuanlan.zhihu.com/p/25419593)
+- [《五分钟搞清楚 MySQL 事务隔离级别》](https://www.jianshu.com/p/4e3edbedb9a8)
+
+另外，有一点非常重要，不同数据库对四个隔离级别的支持和实现略有不同。因为我们目前互联网主要使用 MySQL 为主，所以至少要搞懂 MySQL 对隔离级别的支持和实现情况。
+
+在 TransactionDefinition 接口中，定义了“**四种**”的隔离级别枚举。代码如下：
+
+```
+// TransactionDefinition.java
+
+/**
+ * 【Spring 独有】使用后端数据库默认的隔离级别
+ *
+ * MySQL 默认采用的 REPEATABLE_READ隔离级别
+ * Oracle 默认采用的 READ_COMMITTED隔离级别
+ */
+int ISOLATION_DEFAULT = -1;
+
+/**
+ * 最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读
+ */
+int ISOLATION_READ_UNCOMMITTED = Connection.TRANSACTION_READ_UNCOMMITTED;
+
+/**
+ * 允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生
+ */
+int ISOLATION_READ_COMMITTED = Connection.TRANSACTION_READ_COMMITTED;
+/**
+ * 对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。
+ */
+int ISOLATION_REPEATABLE_READ = Connection.TRANSACTION_REPEATABLE_READ;
+/**
+ * 最高的隔离级别，完全服从ACID的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。
+ *
+ * 但是这将严重影响程序的性能。通常情况下也不会用到该级别。
+ */
+int ISOLATION_SERIALIZABLE = Connection.TRANSACTION_SERIALIZABLE;
+```
+
+## 什么是事务的传播级别？分成哪些传播级别？
+
+事务的**传播行为**，指的是当前带有事务配置的方法，需要怎么处理事务。
+
+- 例如：方法可能继续在现有事务中运行，也可能开启一个新事务，并在自己的事务中运行。
+
+- 有一点需要注意，事务的传播级别，并不是数据库事务规范中的名词，**而是 Spring 自身所定义的**。通过事务的传播级别，Spring 才知道如何处理事务，是创建一个新事务呢，还是继续使用当前的事务。
+
+  > 艿艿的自我吐槽：是不是有种背概念背的想哭
+
+在 TransactionDefinition 接口中，定义了**三类七种**传播级别。代码如下：
+
+```
+// TransactionDefinition.java
+
+// ========== 支持当前事务的情况 ========== 
+
+/**
+ * 如果当前存在事务，则使用该事务。
+ * 如果当前没有事务，则创建一个新的事务。
+ */
+int PROPAGATION_REQUIRED = 0;
+/**
+ * 如果当前存在事务，则使用该事务。
+ * 如果当前没有事务，则以非事务的方式继续运行。
+ */
+int PROPAGATION_SUPPORTS = 1;
+/**
+ * 如果当前存在事务，则使用该事务。
+ * 如果当前没有事务，则抛出异常。
+ */
+int PROPAGATION_MANDATORY = 2;
+
+// ========== 不支持当前事务的情况 ========== 
+
+/**
+ * 创建一个新的事务。
+ * 如果当前存在事务，则把当前事务挂起。
+ */
+int PROPAGATION_REQUIRES_NEW = 3;
+/**
+ * 以非事务方式运行。
+ * 如果当前存在事务，则把当前事务挂起。
+ */
+int PROPAGATION_NOT_SUPPORTED = 4;
+/**
+ * 以非事务方式运行。
+ * 如果当前存在事务，则抛出异常。
+ */
+int PROPAGATION_NEVER = 5;
+
+// ========== 其他情况 ========== 
+
+/**
+ * 如果当前存在事务，则创建一个事务作为当前事务的嵌套事务来运行。
+ * 如果当前没有事务，则等价于 {@link TransactionDefinition#PROPAGATION_REQUIRED}
+ */
+int PROPAGATION_NESTED = 6;
+```
+
+- 分类之后，其实还是比较好记的。当然，绝大数场景，我们只用 `PROPAGATION_REQUIRED` 传播级别。
+
+- 这里需要指出的是，前面的六种事务传播行为是 Spring 从 EJB 中引入的，他们共享相同的概念。而
+
+   
+
+  ```
+  PROPAGATION_NESTED
+  ```
+
+   
+
+  是 Spring 所特有的。
+
+  - 以 `PROPAGATION_NESTED` 启动的事务内嵌于外部事务中（如果存在外部事务的话），此时，内嵌事务并不是一个独立的事务，它依赖于外部事务的存在，只有通过外部的事务提交，才能引起内部事务的提交，嵌套的子事务不能单独提交。如果熟悉 JDBC 中的保存点（SavePoint）的概念，那嵌套事务就很容易理解了，其实嵌套的子事务就是保存点的一个应用，一个事务中可以包括多个保存点，每一个嵌套子事务。另外，外部事务的回滚也会导致嵌套子事务的回滚。
+  - 😈 当然，虽然上面 `PROPAGATION_NESTED` 文字很长，实际我们基本没用过。或者说，去掉基本，我们根本没用过。
+
+## 什么是事务的超时属性？
+
+所谓事务超时，就是指一个事务所允许执行的最长时间，如果超过该时间限制但事务还没有完成，则自动回滚事务。
+
+在 TransactionDefinition 中以 `int` 的值来表示超时时间，其单位是秒。
+
+当然，这个属性，貌似我们基本也没用过。
+
+## 什么是事务的只读属性？
+
+事务的只读属性是指，对事务性资源进行只读操作或者是读写操作。
+
+- 所谓事务性资源就是指那些被事务管理的资源，比如数据源、JMS 资源，以及自定义的事务性资源等等。
+- 如果确定只对事务性资源进行只读操作，那么我们可以将事务标志为只读的，以提高事务处理的性能。感兴趣的胖友，可以看看 [《不使用事务和使用只读事务的区别 》](https://my.oschina.net/uniquejava/blog/80954) 。
+
+在 TransactionDefinition 中以 `boolean` 类型来表示该事务是否只读。
+
+## 什么是事务的回滚规则？
+
+回滚规则，定义了哪些异常会导致事务回滚而哪些不会。
+
+- 默认情况下，事务只有遇到运行期异常时才会回滚，而在遇到检查型异常时不会回滚（这一行为与EJB的回滚行为是一致的）。
+- 但是你可以声明事务在遇到特定的检查型异常时像遇到运行期异常那样回滚。同样，你还可以声明事务遇到特定的异常不回滚，即使这些异常是运行期异常。
+
+注意，事务的回滚规则，并不是数据库事务规范中的名词，**而是 Spring 自身所定义的**。
+
+## 简单介绍 TransactionStatus ？
+
+> 艿艿：这个可能不是一个面试题，主要满足下大家的好奇心。
+
+TransactionStatus 接口，记录事务的状态，不仅仅包含事务本身，还包含事务的其它信息。代码如下：
+
+```
+// TransactionStatus.java
+
+public interface TransactionStatus extends SavepointManager, Flushable {
+
+    /**
+     * 是否是新创建的事务
+     */
+    boolean isNewTransaction();
+
+    /**
+     * 是否有 Savepoint
+     *
+     * 在 {@link TransactionDefinition#PROPAGATION_NESTED} 传播级别使用。
+     */
+    boolean hasSavepoint();
+
+    /**
+     * 设置为只回滚
+     */
+    void setRollbackOnly();
+    /**
+     * 是否为只回滚
+     */
+    boolean isRollbackOnly();
+
+    /**
+     * 执行 flush 操作
+     */
+    @Override
+    void flush();
+
+    /**
+     * 是否事务已经完成
+     */
+    boolean isCompleted();
+
+}
+```
+
+- 为什么没有事务对象呢？在 TransactionStatus 的实现类 DefaultTransactionStatus 中，有个 `Object transaction` 属性，表示事务对象。
+- `#isNewTransaction()` 方法，表示是否是新创建的事务。有什么用呢？答案结合 [「Spring 事务如何和不同的数据持久层框架做集成？」](https://svip.iocoder.cn/Spring/Interview/#) 问题，我们对 `#commit(TransactionStatus status)` 方法的解释。通过该方法，我们可以判断，当前事务是否当前方法所创建的，只有创建事务的方法，**才能且应该真正的提交事务**。
+
+## 使用 Spring 事务有什么优点？
+
+1. 通过 PlatformTransactionManager ，为不同的数据层持久框架提供统一的 API ，无需关心到底是原生 JDBC、Spring JDBC、JPA、Hibernate 还是 MyBatis 。
+2. 通过使用声明式事务，使业务代码和事务管理的逻辑分离，更加清晰。
+
+从倾向上来说，艿艿比较喜欢**注解** + 声明式事务。
+
+# Spring Data Access
+
+> 艿艿：这块的问题，感觉面试问的不多，至少我很少问。哈哈哈。就当做下了解，万一问了呢。
+
+## Spring 支持哪些 ORM 框架？
+
+- Hibernate
+- JPA
+- MyBatis
+- [JDO](https://docs.spring.io/spring/docs/3.0.0.M4/reference/html/ch13s04.html)
+- [OJB](https://db.apache.org/ojb/docu/howtos/howto-use-spring.html)
+
+可能会有胖友说，不是应该还有 Spring JDBC 吗。注意，Spring JDBC 不是 ORM 框架。
+
+## 在 Spring 框架中如何更有效地使用 JDBC ？
+
+Spring 提供了 Spring JDBC 框架，方便我们使用 JDBC 。
+
+对于开发者，只需要使用 JdbcTemplate 类，它提供了很多便利的方法解决诸如把数据库数据转变成基本数据类型或对象，执行写好的或可调用的数据库操作语句，提供自定义的数据错误处理。
+
+没有使用过的胖友，可以看看 [《Spring JDBC 访问关系型数据库》](https://www.tianmaying.com/tutorial/spring-jdbc-data-accessing) 文章。
+
+## Spring 数据数据访问层有哪些异常？
+
+通过使用 Spring 数据数据访问层，它统一了各个数据持久层框架的不同异常，统一进行提供 `org.springframework.dao.DataAccessException` 异常及其子类。如下图所示：
+
+[![流程图](01-精尽 Spring 面试题.assets/09.jpg)](http://static.iocoder.cn/images/Spring/2018-12-24/09.jpg)流程图
+
+## 使用 Spring 访问 Hibernate 的方法有哪些？
+
+> 艿艿：这个问题很灵异，因为艿艿已经好久不使用 Hibernate 了，所以答案是直接复制的。
+
+我们可以通过两种方式使用 Spring 访问 Hibernate：
+
+- 使用 Hibernate 模板和回调进行控制反转。
+- 扩展 HibernateDAOSupport 并应用 AOP 拦截器节点。
+
+> 艿艿：不过我记得，12 年我用过 Spring JPA 的方式，操作 Hibernate 。具体可参考 [《一起来学 SpringBoot 2.x | 第六篇：整合 Spring Data JPA》](http://www.iocoder.cn/Spring-Boot/battcn/v2-orm-jpa/) 。
+
+当然，我们可以再来看一道 [《JPA 规范与 ORM 框架之间的关系是怎样的呢？》](https://www.cnblogs.com/xiaoheike/p/5150553.html) 。这个问题，我倒是问过面试的候选人，哈哈哈哈。
+
+# 666. 彩蛋
+
+整理 Spring 面试题的过程中，又把 Spring 的知识点又复习了一遍。我突然有点想念，那本被我翻烂的 [《Spring 实战》](https://book.douban.com/subject/26767354/) 。😈 我要买一本原版的！！！
+
+参考与推荐如下文章：
+
+- Java 架构 [《Spring 面试题》](https://yq.aliyun.com/articles/669702)
+- 永顺 [《彻底征服 Spring AOP 之理论篇》](https://segmentfault.com/a/1190000007469968)
+- 陌上桑花开花 [《Java 面试题集（七）– Spring常见面试问题》](https://blog.csdn.net/u014079773/article/details/52453002)
+- 一人浅醉 [《Spring 的 @Transactional 注解详细用法》](https://www.cnblogs.com/yepei/p/4716112.html)
+- dalaoyang [《Spring 面试题》](https://juejin.im/post/5b065000f265da0de45235e6)
\ No newline at end of file
diff --git a/spring/02-精尽 Spring 学习指南.md b/spring/02-精尽 Spring 学习指南.md
new file mode 100644
index 0000000..de4c234
--- /dev/null
+++ b/spring/02-精尽 Spring 学习指南.md	
@@ -0,0 +1,69 @@
+# 精尽 Spring 学习指南
+
+# 1. 视频
+
+😈 记得艿艿当年学习 Spring ，还是看的马士兵老师的。有握爪的同学么？嘻嘻。
+
+- [《Spring XML 视频教程全集》](https://www.bilibili.com/video/av59570922/?pikaqiu) 一共有 36P 。
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 虽然版本是 Spring4 ，和 Spring5 实际差距没这么大。
+  >
+  > 和《尚硅谷 Spring MVC 视频教程》是同一个讲师。
+
+- [《Spring 注解视频教程全集》](https://www.bilibili.com/video/av59569306/?pikaqiu) 一共有 61P 。
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 和《尚硅谷 Spring MVC 视频教程》是同一个讲师。
+
+- [《SSM 整合视频教程全集》](https://www.bilibili.com/video/av59585780/?pikaqiu) 一共有 35P 。
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 和《尚硅谷 Spring 视频教程》是同一个讲师。
+
+- 布丁狼 [《Java 大神之路（第八季 Spring5）》](https://www.bilibili.com/video/av33077509) 一共有 57P 。声音有点小…
+
+- 传智播客 [《Spring3 框架》](https://www.imooc.com/learn/498) 一共有 87P 。
+
+- moocer [《Spring 入门篇》](http://www.imooc.com/learn/196) 一共 7 小时，侧重 Spring IoC 和 AOP 。
+
+- apollo_0001 [《探秘 Spring AOP》](http://www.imooc.com/learn/869) 一共 2 小时 30 分钟，侧重 Spring AOP 。
+
+- 慕_神 [《Spring 事务管理》](http://www.imooc.com/learn/478) 一共 2 小时，侧重 Spring Transaction 。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+虽然现在 Spring Boot 给我们带来了非常便利的搭建开发环境的方式，但是艿艿的态度，希望大家能对 Spring 本身能够有比较深入的理解。知其然，知其所以然。这是技术的态度，也是让我们能够走的更远的基础。
+
+# 2. 书籍
+
+[《Spring 书单整理》](http://www.iocoder.cn/Books/Netty-Spring-recommended)
+
+- [《Spring 实战（第4版）》](https://item.jd.com/11899370.html) 豆瓣评分：8.3 ，艿艿当年入门 Spring 的书，翻烂了。
+- [《Spring 揭秘》](https://union-click.jd.com/jdc?d=kYry5g) 豆瓣评分：9.0 ，zhisheng 学习 Spring 的书，虽然 Spring 版本比较老，但是不妨碍我们理解 Spring 。
+- 陈雄华/林开雄/文建国 [《精通Spring 4.x》](https://book.douban.com/subject/26952826/) 豆瓣评分 8.2 分，很厚，799 页。
+- [《Spring 源码深度解析》](https://item.jd.com/11311737.html) 豆瓣评分：6.6 ，艿艿当时撸 Spring 源码，翻了好几遍，认为评分低了，还是很值得推荐的。
+- [《Spring 技术内幕》](https://item.jd.com/1027598917.html) 豆瓣评分 5.8 ，也是 Spring 源码相关，艿艿当年也买过，没读完~
+
+# 3. 文章
+
+- [《Spring 框架的设计理念与设计模式分析》](https://www.ibm.com/developerworks/cn/java/j-lo-spring-principle/index.html)
+
+- [《超全面 Spring 复习总结笔记》](https://www.jianshu.com/p/15a0f94b4063)
+
+  > 艿艿说：推荐这篇文章的原因不是这篇文章写的多好，而是希望我们，在每次之后，我们要去整理总结，即使是简单的笔记，也值得输出。
+  >
+  > 生活的节奏很快，学习之后，总会淡忘。通过文字，能让我们更快的回忆起来。
+
+- [《彻底征服 Spring AOP 之理论篇》](https://segmentfault.com/a/1190000007469968)
+
+- [《彻底征服 Spring AOP 之实战篇》](https://segmentfault.com/a/1190000007469982)
+
+- [《可能是最漂亮的 Spring 事务管理详解》](https://mp.weixin.qq.com/s?__biz=MzUzMTA2NTU2Ng==&mid=2247484702&idx=1&sn=c04261d63929db09ff6df7cadc7cca21&chksm=fa497aafcd3ef3b94082da7bca841b5b7b528eb2a52dbc4eb647b97be63a9a1cf38a9e71bf90&token=165108535&lang=zh_CN#rd)
+
+- [《Spring 事务管理 － 编程式事务、声明式事务》](https://blog.csdn.net/xktxoo/article/details/77919508)
+
+如果胖友有看到合适的文章，也可以推荐给我哟。
\ No newline at end of file
diff --git a/spring/03-精尽 Spring 源码分析-调试环境搭建（Spring 5.1.1 版本）.assets/01.png b/spring/03-精尽 Spring 源码分析-调试环境搭建（Spring 5.1.1 版本）.assets/01.png
new file mode 100644
index 0000000..08059f1
Binary files /dev/null and b/spring/03-精尽 Spring 源码分析-调试环境搭建（Spring 5.1.1 版本）.assets/01.png differ
diff --git a/spring/03-精尽 Spring 源码分析-调试环境搭建（Spring 5.1.1 版本）.md b/spring/03-精尽 Spring 源码分析-调试环境搭建（Spring 5.1.1 版本）.md
new file mode 100644
index 0000000..73aef86
--- /dev/null
+++ b/spring/03-精尽 Spring 源码分析-调试环境搭建（Spring 5.1.1 版本）.md	
@@ -0,0 +1,128 @@
+# 精尽 Spring 源码分析 —— 调试环境搭建（Spring 5.1.1 版本）
+
+# 1. 依赖工具
+
+- Gradle
+- Git
+- JDK1.8+
+- IntelliJ IDEA
+
+笔者目前使用的系统版本是 macOS Mojave 10.14 。所以，如果胖友是 Windows 环境，胖到一些问题，请在星球给我留言。
+
+> 懵逼的艿艿：根据现在收到的信息，貌似主要是 Windows 环境会搭建失败。如果胖友真的搭建不起来，建议可以先新建一个项目，搭建一个 Spring Demo 来调试。
+>
+> 😈 总之，我们的目的是，一定一定一定要调试。酱紫，才能更好的阅读 Spring 的代码。
+
+另外，本文参考官方提供的文档 [《import-into-idea》](https://github.com/spring-projects/spring-framework/blob/master/import-into-idea.md) 。
+
+补充说明 1 ：IntelliJ IDEA 请使用 2018 版本，之前有胖友反馈搭建不起来，因为 IDEA 版本过低。
+
+# 2. 源码拉取
+
+从官方仓库 https://github.com/spring-projects/spring-framework `Fork` 出属于自己的仓库。
+
+- 为什么要 `Fork` ？既然开始阅读、调试源码，我们可能会写一些注释，有了自己的仓库，可以进行自由的提交。😈
+- 本文使用的 Spring 版本为 `5.1.1.BUILD-SNAPSHOT` 。
+- 使用 `IntelliJ IDEA` 从 `Fork` 出来的仓库拉取代码。因为 Spring 项目比较大，从仓库中拉取代码的时间会比较长。
+
+拉取完成后，Gradle 会开始自动 **Build** 项目。因为 Build 的过程中，会下载非常多的依赖，请耐心等待。
+
+- 😈 不过笔者有点不太确定，Gradle 是否会自动 **Build** 项目，反正我的会。如果此处碰到问题，请给我留言。
+
+# 3. 预编译 `spring-oxm` 项目
+
+打开 IDEA Terminal ，输入如下命令，预编译 `spring-oxm` 项目：
+
+```
+./gradlew :spring-oxm:compileTestJava
+```
+
+当看到 `BUILD SUCCESSFUL` ，说明编译成功。
+
+~~😈 另外，笔者有点不确定，Gradle 在上面已经自动 **Build** 项目，这个步骤是否还需要。但是笔者不熟悉 Gradle 的机制，官方文档又要求这么做，所以做下也没什么影响。哈哈哈哈~~。
+
+> 感谢【蝴蝶落于指尖】同学，经过测试，这个是必须的操作。
+
+# 4. 运行示例
+
+在 `spring-context` 项目中的 `src/test/java/example` 目录下，已经提供了一些示例。
+
+① 解析 XML 配置文件成对应的 BeanDefinition 们的流程
+
+可调试 `org.springframework.beans.factory.xml.XmlBeanDefinitionReaderTests` 的 `#withFreshInputStream()` 和 `#withImport()` 这两个单元测试。
+
+相比来说，后者比前者多了一个 `<import />` 标签的解析。当然，XmlBeanDefinitionReaderTests 类中，其它方法也可以简单调试下。看胖友的兴趣哈。
+
+- `#factorySingleton()` 方法，单例的 FactoryBean 的单元测试。
+
+② 加载 Bean 的流程
+
+可调试 `org.springframework.beans.factory.xml.AbstractBeanFactoryTests` 这个单元测试类里的方法。
+
+实际上，AbstractBeanFactoryTests 是一个**抽象**类，所以在运行时，需要选择对应的子类，例如 XmlListableBeanFactoryTests 类。
+
+③ ClassPathXmlApplicationContext 的流程
+
+可调试 `org.springframework.context.support.ClassPathXmlApplicationContextTests` 这个单元测试类里的方法。例如 `#testResourceAndInputStream()` 方法。
+
+④ 解析 Properties 配置文件成对应的 BeanDefinition 们的流程
+
+> 选读，实际使用非常少。主要目的是为了更深入的理解 BeanDefinitionReader 的设计。
+
+**可调试** `org.springframework.beans.factory.support.PropertiesBeanDefinitionReaderTests` 这个单元测试里的方法。
+
+另外，也推荐阅读下 [《spring beans源码解读之 – BeanDefinition 解析器》](https://www.bbsmax.com/A/KE5QLe8PJL/) 一文。
+
+⑤ 调试 Spring AOP 相关的流程
+
+参见 [《精尽 Spring 源码分析 —— AOP 源码简单导读》](http://svip.iocoder.cn/Spring/aop-simple-intro)
+
+⑥ 调试 Spring Transaction 相关的流程
+
+参见 [《精尽 Spring 源码分析 —— Transaction 源码简单导读》](http://svip.iocoder.cn/Spring/transaction-simple-intro)
+
+⑦ 调试 Spring MVC 相关的流程
+
+参见 [《精尽 Spring MVC 源码分析 —— 调试环境搭建》](http://svip.iocoder.cn/Spring-MVC/build-debugging-environment)
+
+⑧ TODO 芋艿，补充一些推荐阅读的示例
+
+# 5. 可能碰到的问题
+
+## 5.1 报 InstrumentationSavingAgent 不存在的错误
+
+例如说，在运行 `spring-context` 项目中的单元测试时，会报 InstrumentationSavingAgent 存在的错误。此时，我们将 `spring-context.gradle` 修改如下：
+
+[![`spring-context.gradle` 修改图](03-精尽 Spring 源码分析-调试环境搭建（Spring 5.1.1 版本）.assets/01.png)](http://static.iocoder.cn/images/Spring/2019-01-01/01.png)`spring-context.gradle` 修改图
+
+修改完成后，Gradle 又会自动 **Build** 项目，下载相关依赖。完成后，再次运行 `spring-context` 项目中的单元测试，顺利通过。
+
+> 根据胖友【Tomy_Rich】测试的说法，凡是报 XXX 不存在的，就和 InstrumentationSavingAgent 的处理方式一样就可以了。
+
+## 5.2 报 ‘io.spring.dependency-management’ 插件不存在
+
+可参考 [《Plugin [id: ‘io.spring.dependency-management’, version: ‘1.0.5.RELEASE’, apply: false\] was not found in any of the following sources:》](https://stackoverflow.com/questions/53587243/plugin-id-io-spring-dependency-management-version-1-0-5-release-apply) 一文进行解决。
+
+来自胖友【贾鹤鸣】的提供。
+
+## 5.3 找不到符号，变量 CoroutinessUtils
+
+可参考 [传送门](https://t.zsxq.com/neaqVJQ) 疑问进行解决。
+
+## 5.4 其它
+
+如果胖友你在搭建调试环境的过程中，如果碰到任何问题，可以在星球给我留言。
+
+# 666. 彩蛋
+
+笔者开始更新 Spring 源码解析系列，让我们在 2019 一起**精尽** Spring 。
+
+另外，笔者的好基友小明哥，已经在死磕 Spring 源码，并更新相应的文章。所以对于这个系列，如果小明哥已经写了，会直接进行引用。感谢小明哥的文章授权。美滋滋。
+
+那么，就开始干吧。
+
+------
+
+> 重要的友情提示一：
+
+《Spring 源码深度解析》，基于 Spring 3 版本的源码解析。虽然版本有点老，但是内容的流畅性很不错，特别是 Spring IoC 部分。艿艿自己也阅读了一遍，点赞。
\ No newline at end of file
diff --git a/spring/04-精尽 Spring 源码分析-调试环境搭建（Spring 5.3.1 版本）.assets/ClassPathXmlApplicationContextTests 类-17199891457615.png b/spring/04-精尽 Spring 源码分析-调试环境搭建（Spring 5.3.1 版本）.assets/ClassPathXmlApplicationContextTests 类-17199891457615.png
new file mode 100644
index 0000000..23b1667
Binary files /dev/null and b/spring/04-精尽 Spring 源码分析-调试环境搭建（Spring 5.3.1 版本）.assets/ClassPathXmlApplicationContextTests 类-17199891457615.png differ
diff --git a/spring/04-精尽 Spring 源码分析-调试环境搭建（Spring 5.3.1 版本）.assets/Spring 调试小技巧.png b/spring/04-精尽 Spring 源码分析-调试环境搭建（Spring 5.3.1 版本）.assets/Spring 调试小技巧.png
new file mode 100644
index 0000000..25c9e5f
Binary files /dev/null and b/spring/04-精尽 Spring 源码分析-调试环境搭建（Spring 5.3.1 版本）.assets/Spring 调试小技巧.png differ
diff --git a/spring/04-精尽 Spring 源码分析-调试环境搭建（Spring 5.3.1 版本）.assets/XmlBeanDefinitionReaderTests 类.png b/spring/04-精尽 Spring 源码分析-调试环境搭建（Spring 5.3.1 版本）.assets/XmlBeanDefinitionReaderTests 类.png
new file mode 100644
index 0000000..b6b1706
Binary files /dev/null and b/spring/04-精尽 Spring 源码分析-调试环境搭建（Spring 5.3.1 版本）.assets/XmlBeanDefinitionReaderTests 类.png differ
diff --git a/spring/04-精尽 Spring 源码分析-调试环境搭建（Spring 5.3.1 版本）.assets/下载 Gradle 工具.png b/spring/04-精尽 Spring 源码分析-调试环境搭建（Spring 5.3.1 版本）.assets/下载 Gradle 工具.png
new file mode 100644
index 0000000..fd342c0
Binary files /dev/null and b/spring/04-精尽 Spring 源码分析-调试环境搭建（Spring 5.3.1 版本）.assets/下载 Gradle 工具.png differ
diff --git a/spring/04-精尽 Spring 源码分析-调试环境搭建（Spring 5.3.1 版本）.assets/下载依赖.png b/spring/04-精尽 Spring 源码分析-调试环境搭建（Spring 5.3.1 版本）.assets/下载依赖.png
new file mode 100644
index 0000000..8f7543f
Binary files /dev/null and b/spring/04-精尽 Spring 源码分析-调试环境搭建（Spring 5.3.1 版本）.assets/下载依赖.png differ
diff --git a/spring/04-精尽 Spring 源码分析-调试环境搭建（Spring 5.3.1 版本）.md b/spring/04-精尽 Spring 源码分析-调试环境搭建（Spring 5.3.1 版本）.md
new file mode 100644
index 0000000..4ddbe46
--- /dev/null
+++ b/spring/04-精尽 Spring 源码分析-调试环境搭建（Spring 5.3.1 版本）.md	
@@ -0,0 +1,116 @@
+# 精尽 Spring 源码分析 —— 调试环境搭建（Spring 5.3.1 版本）
+
+今儿，我们来搭建一个 Spring 调试环境，目标是：**启动 Spring 容器，解析 XML 配置，创建 Bean 对象**。
+
+> 为什么是 XML 配置，而不是注解呢？
+>
+> 使用 XML 配置来声明 Bean 的逻辑比较清晰，理解起来相对容易一些。
+
+视频可见 B 站：https://www.bilibili.com/video/BV1yh411q7jb/
+
+😝 艿艿比较腼腆，大家给个三连支持一下，感恩 1024~
+
+# 1. 依赖工具
+
+## 1.1 IDEA
+
+当然是 Jetbrains 出品的 IDEA 工具，相信绝大多数胖友都使用的它。
+
+艿艿使用的是 **2020.3** 版本，胖友尽量保证不低于该版本哈。
+
+> 友情提示：如果不知道怎么激活 IDEA 的胖友，可以访问 [《IDEA 激活指南》](https://www.iocoder.cn/IDEA/idea-2020-reset-eval/) 地址，花 5 分钟学习！支持所有版本~
+
+## 1.2 JDK
+
+需要使用 JDK 编译 Spring 的代码，这里艿艿使用的是 JDK **1.8** 版本
+
+```
+$ java -version
+java version "1.8.0_144"
+Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
+Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
+```
+
+# 2. 源码拉取
+
+使用 IDEA 从官方仓库 https://github.com/spring-projects/spring-framework 克隆项目。
+
+> 友情提示：如果网络不是很好的胖友，可以选择和艿艿一样，使用 Gitee 提供的镜像仓库 https://gitee.com/mirrors/Spring-Framework.git
+>
+> 即使使用 Gitee 的镜像，克隆也要好几分钟，代码有 100M 左右！！！
+
+这里，我们使用的 Spring 版本是 [**5.3.10-SNAPSHOT**](https://github.com/spring-projects/spring-framework/blob/main/gradle.properties#L1)。
+
+> 友情提示：胖友可以考虑 Fork 下[官方仓库](https://github.com/spring-projects/spring-framework)，为什么呢？
+>
+> 既然开始阅读、调试源码，我们可能会写一些注释，有了自己的仓库，可以进行自由的提交。😜
+
+# 3. 下载依赖
+
+① 克隆完成 Spring 项目之后，IDEA 会自动下载需要的 Gradle 工具。如下图所示：
+
+[![下载 Gradle 工具](04-精尽 Spring 源码分析-调试环境搭建（Spring 5.3.1 版本）.assets/下载 Gradle 工具.png)](https://www.iocoder.cn/images/Spring/2019-01-03/下载 Gradle 工具.png)下载 Gradle 工具
+
+这里，我们使用的 Gradle 版本是 **6.8.3**。
+
+> 友情提示：由于是从国外的网址下载，所以需要耐心等待一会，艿艿花费了 2 分多钟。
+
+② 下载完 Gradle 工具之后，IDEA 就会使用它自动下载相关的依赖库。如下图所示：
+
+[![下载依赖](04-精尽 Spring 源码分析-调试环境搭建（Spring 5.3.1 版本）.assets/下载依赖.png)](https://www.iocoder.cn/images/Spring/2019-01-03/下载依赖.png)下载依赖
+
+因为 Gradle 支持使用 Maven 依赖，所以我们可以使用阿里云的 Maven 镜像 `https://maven.aliyun.com/nexus/content/groups/public/`**。修改 `build.gradle` 文件，如下图所示：
+
+[![下载依赖](https://www.iocoder.cn/images/Spring/2019-01-03/%E4%B8%8B%E8%BD%BD%E4%BE%9D%E8%B5%962.png)](https://www.iocoder.cn/images/Spring/2019-01-03/下载依赖2.png)下载依赖
+
+效果非常不错，不过艿艿还是花了 10 分钟才下载完了依赖。主要原因是，Spring 对很多框架进行集成，导致引入了非常多的依赖。
+
+ps：如果中间下载失败，点击【绿色刷新】按钮，继续下载依赖即可。
+
+# 4. 调试 Spring 示例
+
+依赖下载完，我们就可以调试 Spring 的源码。虽然说 Spring 并没有直接提供 example 使用示例项目，但是我们通过调试 Spring 提供的**单元测试**类，了解 Spring 的执行流程。
+
+例如说：
+
+① 通过 Debug 运行 XmlBeanDefinitionReaderTests 类的 `#withFreshInputStream()` 的方法，调试 Spring 解析 XML 配合，获得 Bean 的**定义**。如下图所示：
+
+[![调试 XmlBeanDefinitionReaderTests 类](04-精尽 Spring 源码分析-调试环境搭建（Spring 5.3.1 版本）.assets/XmlBeanDefinitionReaderTests 类.png)](https://www.iocoder.cn/images/Spring/2019-01-03/XmlBeanDefinitionReaderTests 类.png)调试 XmlBeanDefinitionReaderTests 类
+
+后续，胖友可以通过调试 XmlBeanDefinitionReader 类的源码，了解更多。
+
+> 友情提示：Spring 是先解析到 Bean 的定义，然后创建 Bean 对象。🙂
+
+② 通过 Debug 运行 ClassPathXmlApplicationContextTests 类的 `#testSingleConfigLocation()` 的方法，调试 Spring 容器的初始化过程，包括 Bean 的**创建**。如下图所示：
+
+[![调试 ClassPathXmlApplicationContextTests 类](https://www.iocoder.cn/images/Spring/2019-01-03/ClassPathXmlApplicationContextTests%20%E7%B1%BB.png)](https://www.iocoder.cn/images/Spring/2019-01-03/ClassPathXmlApplicationContextTests 类.png)调试 ClassPathXmlApplicationContextTests 类
+
+后续，胖友可以通过调试 ClassPathXmlApplicationContext 类的源码，了解更多。
+
+------
+
+再额外分享一个小技巧，如果在阅读 Spring 源码的时候，发现一个逻辑的分支走不到，我们在该处打上断点，然后执行整个目录的单元测试。如下图所示：
+
+[![Spring 调试小技巧](04-精尽 Spring 源码分析-调试环境搭建（Spring 5.3.1 版本）.assets/Spring 调试小技巧.png)](https://www.iocoder.cn/images/Spring/2019-01-03/Spring 调试小技巧.png)Spring 调试小技巧
+
+# 5. 源码解析
+
+Spring 的代码量，非常庞大，目前已经有 70W 行左右，自己直接死磕的话，基本在 3 天热情之后，就会选择放弃。
+
+所以这里，艿艿来推荐下 Spring 相关的源码解析的书籍，帮助大家更好的阅读。
+
+① 艿艿修改的 [《死磕 Spring 源码解析》](http://svip.iocoder.cn/categories/Spring)，针对 Spring 5.1.1 版本。
+
+如果大家在阅读中有碰到什么问题，欢迎星球给艿艿提问哈，大胆的，自己人！
+
+② [《Spring源码深度解析（第 2 版）》](https://github.com/YunaiV/books)，针对 Spring 5.X 版本，豆瓣评分 6.5 分，个人觉得分数有点偏低，7.5 分还是有的。
+
+> 链接: https://pan.baidu.com/s/1rxB3p5iR3JZFlwf92py9-w 提取码: 81b1 复制这段内容后打开百度网盘手机App，操作更方便哦
+
+写的还不错，艿艿最早读 Spring 源码也是看了这本书。当时还是第 1 版，现在都是第 2 版，真的是时光匆匆！哈哈哈，现在的书架上，还放了一本。
+
+③ [《Spring 技术内幕（第 2 版）》](https://github.com/YunaiV/books)，出版时间是 2012 年，针对的 Spring 版本可能相对老一点，豆瓣评分 6.5 分。
+
+> 链接: https://pan.baidu.com/s/1ad9BkvnpvAoIU2DI3Dv5gg 提取码: svyn 复制这段内容后打开百度网盘手机App，操作更方便哦
+
+艿艿暂时没看过，胖友可以作为字典，在哪一块卡壳的时候，查一查有没讲到那块的源码。
\ No newline at end of file
diff --git a/spring/05-Spring-IoC 之深入理解 Spring IoC.assets/0e80d7996e6a8642b66873b0f0a31680.png b/spring/05-Spring-IoC 之深入理解 Spring IoC.assets/0e80d7996e6a8642b66873b0f0a31680.png
new file mode 100644
index 0000000..daf0894
Binary files /dev/null and b/spring/05-Spring-IoC 之深入理解 Spring IoC.assets/0e80d7996e6a8642b66873b0f0a31680.png differ
diff --git a/spring/05-Spring-IoC 之深入理解 Spring IoC.assets/143162657d5f8c7cb7712d0996bf2a38.jpeg b/spring/05-Spring-IoC 之深入理解 Spring IoC.assets/143162657d5f8c7cb7712d0996bf2a38.jpeg
new file mode 100644
index 0000000..e6726e6
Binary files /dev/null and b/spring/05-Spring-IoC 之深入理解 Spring IoC.assets/143162657d5f8c7cb7712d0996bf2a38.jpeg differ
diff --git a/spring/05-Spring-IoC 之深入理解 Spring IoC.assets/2446cc9fba90605b691ea250cf340ebb.png b/spring/05-Spring-IoC 之深入理解 Spring IoC.assets/2446cc9fba90605b691ea250cf340ebb.png
new file mode 100644
index 0000000..1023139
Binary files /dev/null and b/spring/05-Spring-IoC 之深入理解 Spring IoC.assets/2446cc9fba90605b691ea250cf340ebb.png differ
diff --git a/spring/05-Spring-IoC 之深入理解 Spring IoC.assets/4a0a9d810fad631a5f0263bc411e6606.png b/spring/05-Spring-IoC 之深入理解 Spring IoC.assets/4a0a9d810fad631a5f0263bc411e6606.png
new file mode 100644
index 0000000..47377a8
Binary files /dev/null and b/spring/05-Spring-IoC 之深入理解 Spring IoC.assets/4a0a9d810fad631a5f0263bc411e6606.png differ
diff --git a/spring/05-Spring-IoC 之深入理解 Spring IoC.assets/8560e3437ba97621cffb794d629d4928.png b/spring/05-Spring-IoC 之深入理解 Spring IoC.assets/8560e3437ba97621cffb794d629d4928.png
new file mode 100644
index 0000000..4189d15
Binary files /dev/null and b/spring/05-Spring-IoC 之深入理解 Spring IoC.assets/8560e3437ba97621cffb794d629d4928.png differ
diff --git a/spring/05-Spring-IoC 之深入理解 Spring IoC.assets/a9c6a574b85de4723729b674cb51436f.png b/spring/05-Spring-IoC 之深入理解 Spring IoC.assets/a9c6a574b85de4723729b674cb51436f.png
new file mode 100644
index 0000000..4b608ed
Binary files /dev/null and b/spring/05-Spring-IoC 之深入理解 Spring IoC.assets/a9c6a574b85de4723729b674cb51436f.png differ
diff --git a/spring/05-Spring-IoC 之深入理解 Spring IoC.assets/b12d2b0775b788c80247c9a7363011b6.jpeg b/spring/05-Spring-IoC 之深入理解 Spring IoC.assets/b12d2b0775b788c80247c9a7363011b6.jpeg
new file mode 100644
index 0000000..f4e4737
Binary files /dev/null and b/spring/05-Spring-IoC 之深入理解 Spring IoC.assets/b12d2b0775b788c80247c9a7363011b6.jpeg differ
diff --git a/spring/05-Spring-IoC 之深入理解 Spring IoC.assets/bfdcd6b07c6f5434ba01895efd174cdc.png b/spring/05-Spring-IoC 之深入理解 Spring IoC.assets/bfdcd6b07c6f5434ba01895efd174cdc.png
new file mode 100644
index 0000000..dbc905c
Binary files /dev/null and b/spring/05-Spring-IoC 之深入理解 Spring IoC.assets/bfdcd6b07c6f5434ba01895efd174cdc.png differ
diff --git a/spring/05-Spring-IoC 之深入理解 Spring IoC.md b/spring/05-Spring-IoC 之深入理解 Spring IoC.md
new file mode 100644
index 0000000..4430df8
--- /dev/null
+++ b/spring/05-Spring-IoC 之深入理解 Spring IoC.md	
@@ -0,0 +1,215 @@
+# 【死磕 Spring】—— IoC 之深入理解 Spring IoC
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=2652 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+在一开始学习 Spring 的时候，我们就接触 IoC 了，作为 Spring 第一个最核心的概念，我们在解读它源码之前势必需要对其有深入的认识，本篇为【死磕 Spring】系列博客的第一篇博文，主要介绍 IoC 基本概念和各个组件。
+
+# 1. IoC 理论
+
+IoC 全称为 `Inversion of Control`，翻译为 “控制反转”，它还有一个别名为 DI（`Dependency Injection`）,即依赖注入。
+
+如何理解“控制反转”好呢？理解好它的关键在于我们需要回答如下四个问题：
+
+1. 谁控制谁
+2. 控制什么
+3. 为何是反转
+4. 哪些方面反转了
+
+在回答这四个问题之前，我们先看 IoC 的定义：
+
+> **所谓 IoC ，就是由 Spring IoC 容器来负责对象的生命周期和对象之间的关系**
+
+上面这句话是整个 IoC 理论的核心。如何来理解这句话？我们引用一个例子来走阐述（看完该例子上面四个问题也就不是问题了）。
+
+找女朋友，一般情况下我们是如何来找女朋友的呢？首先我们需要根据自己的需求（漂亮、身材好、性格好）找一个妹子，然后到处打听她的兴趣爱好、微信、电话号码，然后各种投其所好送其所要，最后追到手。如下：
+
+```
+/**
+ * 年轻小伙子
+ */
+public class YoungMan {
+
+    private BeautifulGirl beautifulGirl;
+
+    YoungMan(){
+
+        // 可能你比较牛逼，指腹为婚
+
+        // beautifulGirl = new BeautifulGirl();
+
+    }
+
+    public void setBeautifulGirl(BeautifulGirl beautifulGirl) {
+
+        this.beautifulGirl = beautifulGirl;
+
+    }
+
+    public static void main(String[] args){
+
+        YoungMan you = new YoungMan();
+
+        BeautifulGirl beautifulGirl = new BeautifulGirl("你的各种条件");
+
+        beautifulGirl.setxxx("各种投其所好");
+
+        // 然后你有女票了
+
+        you.setBeautifulGirl(beautifulGirl);
+
+    }
+
+}
+```
+
+这就是我们通常做事的方式，如果我们需要某个对象，一般都是采用这种直接创建的方式(`new BeautifulGirl()`)，这个过程复杂而又繁琐，而且我们必须要面对每个环节，而且使用完成之后我们还要复杂销毁它，这种情况下我们的对象与它所依赖的对象耦合在一起。
+
+其实我们需要思考一个问题？我们每次用到自己依赖的对象真的需要自己去创建吗？我们知道，我们依赖对象其实并不是依赖该对象本身，而是依赖它所提供的服务，只要在我们需要它的时候，它能够及时提供服务即可，至于它是我们主动去创建的还是别人送给我们的，其实并不是那么重要。再说了，相比于自己千辛万苦去创建它还要管理善后而言，直接有人送过来是不是显得更加好呢？
+
+这个给我们送东西的“人” 就是 IoC，在上面的例子中，它就相当于一个婚介公司，作为一个婚介公司它管理着很多男男女女的资料，当我们需要一个女朋友的时候，直接跟婚介公司提出我们的需求，婚介公司则会根据我们的需求提供一个妹子给我们，我们只需要负责谈恋爱，生猴子就行了。你看，这样是不是很简单明了。
+
+诚然，作为婚介公司的 IoC 帮我们省略了找女朋友的繁杂过程，将原来的主动寻找变成了现在的被动接受，更加简洁轻便。你想啊，原来你还得鞍马前后，各种巴结，什么东西都需要自己去亲力亲为，现在好了，直接有人把现成的送过来，多么美妙的事情啊。所以，简单点说，IoC 的理念就是**让别人为你服务**，如下图（摘自Spring揭秘）：
+
+[![201805071001](05-Spring-IoC 之深入理解 Spring IoC.assets/a9c6a574b85de4723729b674cb51436f.png)](http://static.iocoder.cn/a9c6a574b85de4723729b674cb51436f)201805071001
+
+在没有引入 IoC 的时候，被注入的对象直接依赖于被依赖的对象，有了 IoC 后，两者及其他们的关系都是通过 Ioc Service Provider 来统一管理维护的。被注入的对象需要什么，直接跟 IoC Service Provider 打声招呼，后者就会把相应的被依赖对象注入到被注入的对象中，从而达到 IoC Service Provider 为被注入对象服务的目的。**所以 IoC 就是这么简单！原来是需要什么东西自己去拿，现在是需要什么东西让别人（IoC Service Provider）送过来**
+
+现在在看上面那四个问题，答案就显得非常明显了:
+
+1. **谁控制谁**：在传统的开发模式下，我们都是采用直接 new 一个对象的方式来创建对象，也就是说你依赖的对象直接由你自己控制，但是有了 IoC 容器后，则直接由 IoC 容器来控制。所以“谁控制谁”，当然是 IoC 容器控制对象
+2. **控制什么**：控制对象。
+3. **为何是反转**：没有 IoC 的时候我们都是在自己对象中主动去创建被依赖的对象，这是正转。但是有了 IoC 后，所依赖的对象直接由 IoC 容器创建后注入到被注入的对象中，依赖的对象由原来的主动获取变成被动接受，所以是反转。
+4. **哪些方面反转了**：所依赖对象的获取被反转了。
+
+妹子有了，但是如何拥有妹子呢？这也是一门学问。
+
+1. 可能你比较牛逼，刚刚出生的时候就指腹为婚了。
+2. 大多数情况我们还是会考虑自己想要什么样的妹子，所以还是需要向婚介公司打招呼的。
+3. 还有一种情况就是，你根本就不知道自己想要什么样的妹子，直接跟婚介公司说，我就要一个这样的妹子。
+
+## 1.1 注入形式
+
+所以，IoC Service Provider 为被注入对象提供被依赖对象也有如下几种方式：构造方法注入、stter方法注入、接口注入。
+
+**① 构造器注入**
+
+构造器注入，顾名思义就是被注入的对象通过在其构造方法中声明依赖对象的参数列表，让外部知道它需要哪些依赖对象。
+
+```
+YoungMan(BeautifulGirl beautifulGirl) {
+    this.beautifulGirl = beautifulGirl;
+}
+```
+
+构造器注入方式比较直观，对象构造完毕后就可以直接使用，这就好比你出生你家里就给你指定了你媳妇。
+
+**② setter 方法注入**
+
+对于 JavaBean 对象而言，我们一般都是通过 getter 和 setter 方法来访问和设置对象的属性。所以，当前对象只需要为其所依赖的对象提供相对应的 setter 方法，就可以通过该方法将相应的依赖对象设置到被注入对象中。如下：
+
+```
+public class YoungMan {
+
+    private BeautifulGirl beautifulGirl;
+
+    public void setBeautifulGirl(BeautifulGirl beautifulGirl) {
+        this.beautifulGirl = beautifulGirl;
+    }
+
+}
+```
+
+相比于构造器注入，setter 方式注入会显得比较宽松灵活些，它可以在任何时候进行注入（当然是在使用依赖对象之前），这就好比你可以先把自己想要的妹子想好了，然后再跟婚介公司打招呼，你可以要林志玲款式的，赵丽颖款式的，甚至凤姐哪款的，随意性较强。
+
+**③ 接口方式注入**
+
+接口方式注入显得比较霸道，因为它需要被依赖的对象实现不必要的接口，带有侵入性。一般都不推荐这种方式。
+
+感兴趣的胖友，可以看看 [《依赖注入的三种实现形式 —— 接口注入（Interface Injection）》](http://wiki.jikexueyuan.com/project/spring-ioc/iocordi-1.html#6e5dfcd838f3a79e9129641785cf736f)
+
+## 1.2 推荐文章
+
+关于 IoC 理论部分，笔者不在阐述，这里推荐几篇博客阅读：
+
+- [《谈谈对 Spring IoC 的理解》](http://www.cnblogs.com/xdp-gacl/p/4249939.html)
+- [《Spring 的 IoC 原理[通俗解释一下\]》](https://blog.csdn.net/m13666368773/article/details/7802126)
+- [《Spring IoC 原理（看完后大家可以自己写一个spring）》](https://blog.csdn.net/it_man/article/details/4402245)
+
+# 2. 各个组件
+
+先看下图（摘自:http://singleant.iteye.com/blog/1177358）
+
+[![组件类图](05-Spring-IoC 之深入理解 Spring IoC.assets/b12d2b0775b788c80247c9a7363011b6.jpeg)](http://static.iocoder.cn/b12d2b0775b788c80247c9a7363011b6)组件类图
+
+该图为 ClassPathXmlApplicationContext 的类继承体系结构，虽然只有一部分，但是它基本上包含了 IoC 体系中大部分的核心类和接口。
+
+下面我们就针对这个图进行简单的拆分和补充说明。
+
+## 2.1 Resource 体系
+
+`org.springframework.core.io.Resource`，对资源的抽象。它的每一个实现类都代表了一种资源的访问策略，如 ClassPathResource、RLResource、FileSystemResource 等。
+
+[![Resource 类图](05-Spring-IoC 之深入理解 Spring IoC.assets/143162657d5f8c7cb7712d0996bf2a38.jpeg)](http://static.iocoder.cn/143162657d5f8c7cb7712d0996bf2a38)Resource 类图
+
+### 2.1.2 ResourceLoader 体系
+
+有了资源，就应该有资源加载，Spring 利用 `org.springframework.core.io.ResourceLoader` 来进行统一资源加载，类图如下：
+
+[![ResourceLoader 类图](05-Spring-IoC 之深入理解 Spring IoC.assets/2446cc9fba90605b691ea250cf340ebb.png)](http://static.iocoder.cn/2446cc9fba90605b691ea250cf340ebb)ResourceLoader 类图
+
+> 关于 Resource 和 ResourceLoader 的源码解析，见 [《【死磕 Spring】—— IoC 之 Spring 统一资源加载策略》](http://svip.iocoder.cn/Spring/IoC-load-Resource) 。
+
+## 2.2 BeanFactory 体系
+
+`org.springframework.beans.factory.BeanFactory`，是一个非常纯粹的 bean 容器，它是 IoC 必备的数据结构，其中 BeanDefinition 是它的基本结构。BeanFactory 内部维护着一个BeanDefinition map ，并可根据 BeanDefinition 的描述进行 bean 的创建和管理。
+
+[![BeanFactory 类图](05-Spring-IoC 之深入理解 Spring IoC.assets/4a0a9d810fad631a5f0263bc411e6606.png)](http://static.iocoder.cn/4a0a9d810fad631a5f0263bc411e6606)BeanFactory 类图
+
+- BeanFactory 有三个直接子类 ListableBeanFactory、HierarchicalBeanFactory 和 AutowireCapableBeanFactory 。
+- DefaultListableBeanFactory 为最终默认实现，它实现了所有接口。
+
+## 2.3 BeanDefinition 体系
+
+`org.springframework.beans.factory.config.BeanDefinition` ，用来描述 Spring 中的 Bean 对象。
+
+[![BeanDefinition 类图](05-Spring-IoC 之深入理解 Spring IoC.assets/0e80d7996e6a8642b66873b0f0a31680.png)](http://static.iocoder.cn/0e80d7996e6a8642b66873b0f0a31680)BeanDefinition 类图
+
+## 2.4 BeanDefinitionReader 体系
+
+`org.springframework.beans.factory.support.BeanDefinitionReader` 的作用是读取 Spring 的配置文件的内容，并将其转换成 Ioc 容器内部的数据结构 ：BeanDefinition 。
+
+[![BeanDefinitionReader 类图](05-Spring-IoC 之深入理解 Spring IoC.assets/8560e3437ba97621cffb794d629d4928.png)](http://static.iocoder.cn/8560e3437ba97621cffb794d629d4928)BeanDefinitionReader 类图
+
+> 关于 BeanDefinitionReader 的源码解析，见如下文章：
+>
+> - [《【死磕 Spring】—— IoC 之加载 Definitions》](http://svip.iocoder.cn/Spring/IoC-load-BeanDefinitions)
+> - [《【死磕 Spring】—— IoC 之获取验证模型》](http://svip.iocoder.cn/Spring/IoC-Validation-Mode-For-Resource)
+> - [《【死磕 Spring】—— IoC 之获取 Document 对象》](http://svip.iocoder.cn/Spring/IoC-load-Document)
+> - [《【死磕 Spring】—— IoC 之注册 BeanDefinitions》](http://svip.iocoder.cn/Spring/IoC-register-BeanDefinitions)
+
+## 2.5 ApplicationContext 体系
+
+`org.springframework.context.ApplicationContext` ，这个就是大名鼎鼎的 Spring 容器，它叫做应用上下文，与我们应用息息相关。它继承 BeanFactory ，所以它是 BeanFactory 的扩展升级版，如果BeanFactory 是屌丝的话，那么 ApplicationContext 则是名副其实的高富帅。由于 ApplicationContext 的结构就决定了它与 BeanFactory 的不同，其主要区别有：
+
+1. 继承 `org.springframework.context.MessageSource` 接口，提供国际化的标准访问策略。
+2. 继承 `org.springframework.context.ApplicationEventPublisher` 接口，提供强大的**事件**机制。
+3. 扩展 ResourceLoader ，可以用来加载多种 Resource ，可以灵活访问不同的资源。
+4. 对 Web 应用的支持。
+
+下图来源：https://blog.csdn.net/yujin753/article/details/47043143
+
+[![ApplicationContext 类图](05-Spring-IoC 之深入理解 Spring IoC.assets/bfdcd6b07c6f5434ba01895efd174cdc.png)](http://static.iocoder.cn/bfdcd6b07c6f5434ba01895efd174cdc)ApplicationContext 类图
+
+## 2.6 小结
+
+上面五个体系可以说是 Spring IoC 中最核心的部分，后面博文也是针对这五个部分进行源码分析。其实 IoC 咋一看还是挺简单的，无非就是将配置文件（暂且认为是 xml 文件）进行解析（分析 xml 谁不会啊），然后放到一个 Map 里面就差不多了，初看有道理，其实要面临的问题还是有很多的，下面就劳烦各位看客跟着 LZ 博客来一步一步揭开 Spring IoC 的神秘面纱。
+
+> **此系列博文为 LZ 学习、研究 Spring 机制和源码的学习笔记，会涉及参考别人的博文和书籍内容，如有雷同，纯属借鉴，当然 LZ 会标明参考来源。同时由于知识面和能力的问题，文章中难免会出现错误之处，如有，望各位大佬指出，不胜感激**。
+
+另外，通过上面五个体系，我们可以看出，IoC 主要由 `spring-beans` 和 `spring-context` 项目，进行实现。
\ No newline at end of file
diff --git a/spring/06-Spring-IoC 之 Spring 统一资源加载策略.assets/143162657d5f8c7cb7712d0996bf2a38.jpeg b/spring/06-Spring-IoC 之 Spring 统一资源加载策略.assets/143162657d5f8c7cb7712d0996bf2a38.jpeg
new file mode 100644
index 0000000..e6726e6
Binary files /dev/null and b/spring/06-Spring-IoC 之 Spring 统一资源加载策略.assets/143162657d5f8c7cb7712d0996bf2a38.jpeg differ
diff --git a/spring/06-Spring-IoC 之 Spring 统一资源加载策略.assets/2446cc9fba90605b691ea250cf340ebb.png b/spring/06-Spring-IoC 之 Spring 统一资源加载策略.assets/2446cc9fba90605b691ea250cf340ebb.png
new file mode 100644
index 0000000..1023139
Binary files /dev/null and b/spring/06-Spring-IoC 之 Spring 统一资源加载策略.assets/2446cc9fba90605b691ea250cf340ebb.png differ
diff --git a/spring/06-Spring-IoC 之 Spring 统一资源加载策略.assets/bbb679d9d2be10643fd7e20ca88d3f2b b/spring/06-Spring-IoC 之 Spring 统一资源加载策略.assets/bbb679d9d2be10643fd7e20ca88d3f2b
new file mode 100644
index 0000000..ed6cddb
--- /dev/null
+++ b/spring/06-Spring-IoC 之 Spring 统一资源加载策略.assets/bbb679d9d2be10643fd7e20ca88d3f2b	
@@ -0,0 +1,1846 @@
+<!DOCTYPE html>
+<html lang='zh-CN'>
+<link href="https://assets.gitee.com/assets/projects/application-341193674e6501b79839790a1aa65ac8.css" media="screen" rel="stylesheet" type="text/css" />
+<head>
+<title>image/201811/87106504.jpg · chenssy/blog-home - 码云 Gitee.com</title>
+<link href="https://assets.gitee.com/assets/favicon-e87ded4710611ed62adc859698277663.ico" rel="shortcut icon" type="image/vnd.microsoft.icon" />
+<meta content='gitee.com/chenssy/blog-home git https://gitee.com/chenssy/blog-home.git' name='go-import'>
+<meta charset='utf-8'>
+<meta content='always' name='referrer'>
+<meta content='码云' property='og:site_name'>
+<meta content='Object' property='og:type'>
+<meta content='http://gitee.com/chenssy/blog-home/blob/master/image/201811/87106504.jpg' property='og:url'>
+<meta content='https://gitee.com/logo_themecolor.png' itemprop='image' property='og:image'>
+<meta content='image/201811/87106504.jpg · chenssy/blog-home - 码云 Gitee.com' itemprop='name' property='og:title'>
+<meta content='码云(gitee.com)是 OSCHINA.NET 推出的代码托管平台，支持 Git 和 SVN，提供免费的私有仓库托管。目前已有超过 350 万的开发者选择码云。' property='og:description'>
+<meta content='码云,代码托管,git,Git@OSC,gitee.com,开源,项目管理,版本控制,开源代码,代码分享,项目协作,开源项目托管,免费代码托管,Git代码托管,Git托管服务' name='Keywords'>
+<meta content='记录自己写的博客和收录的优秀博客' itemprop='description' name='Description'>
+
+<meta content="IE=edge" http-equiv="X-UA-Compatible" />
+<meta content="authenticity_token" name="csrf-param" />
+<meta content="geuYNLP2QrbxhaHKj7HfP8aci71H5LilwELPCIiZLJs=" name="csrf-token" />
+
+<link href="https://assets.gitee.com/assets/application-3ca3e439a5350caa95b8b157c8fa4d1a.css" media="screen" rel="stylesheet" type="text/css" />
+<script type="text/javascript">
+//<![CDATA[
+window.gon = {};gon.locale="zh-CN";gon.tour_env={"current_user":null,"controller_path":"blob","action_name":"show","original_url":"http://gitee.com/chenssy/blog-home/blob/master/image/201811/87106504.jpg"};gon.http_clone="https://gitee.com/chenssy/blog-home.git";gon.user_project="chenssy/blog-home";gon.manage_branch="管理分支";gon.manage_tag="管理标签";gon.enterprise_id=0;gon.ref="master";
+//]]>
+</script>
+<script src="https://assets.gitee.com/assets/application-e60c8f0041afe12a35e1b792bbd5719c.js" type="text/javascript"></script>
+<script src="https://assets.gitee.com/assets/lib/jquery.timeago.zh-CN-bcd91c2c27a815fa9a395595874b592b.js" type="text/javascript"></script>
+
+
+<script src="//res.wx.qq.com/open/js/jweixin-1.2.0.js" type="text/javascript"></script>
+<script>
+  var title = document.title.replace(/( - Gitee| - 码云)$/, '')
+      imgUrl = '';
+  
+  document.addEventListener('DOMContentLoaded', function(event) {
+    var imgUrlEl = document.querySelector('.readme-box .markdown-body > img, .readme-box .markdown-body :not(a) > img');
+    imgUrl = imgUrlEl && imgUrlEl.getAttribute('src');
+  
+    if (!imgUrl) {
+      imgUrlEl = document.querySelector('meta[itemprop=image]');
+      imgUrl = imgUrlEl && imgUrlEl.getAttribute('content'); 
+      imgUrl = imgUrl || "https://gitee.com/logo_themecolor.png";
+    }
+  
+    wx.config({
+      debug: false,
+      appId: "wxff219d611a159737",
+      timestamp: "1562385536",
+      nonceStr: "ed38457f8451e9f959cee766f1c7047c",
+      signature: "12e9454ca527e06077351daf42c68b16ffe12975",
+      jsApiList: [
+        'onMenuShareTimeline',
+        'onMenuShareAppMessage'
+      ]
+    });
+  
+    wx.ready(function () {
+      wx.onMenuShareTimeline({
+        title: title, // 分享标题
+        link: "https://gitee.com/chenssy/blog-home/blob/master/image/201811/87106504.jpg", // 分享链接，该链接域名或路径必须与当前页面对应的公众号JS安全域名一致
+        imgUrl: imgUrl // 分享图标
+      });
+      wx.onMenuShareAppMessage({
+        title: title, // 分享标题
+        link: "https://gitee.com/chenssy/blog-home/blob/master/image/201811/87106504.jpg", // 分享链接，该链接域名或路径必须与当前页面对应的公众号JS安全域名一致
+        desc: document.querySelector('meta[name=Description]').getAttribute('content'),
+        imgUrl: imgUrl // 分享图标
+      });
+    });
+    wx.error(function(res){
+      console.error('err', res)
+    });
+  })
+</script>
+
+<script type='text/x-mathjax-config'>
+MathJax.Hub.Config({
+  tex2jax: {
+    inlineMath: [['$','$'], ['\\(','\\)']],
+    displayMath: [["$$","$$"],["\\[","\\]"]],
+    processEscapes: true,
+    skipTags: ['script', 'noscript', 'style', 'textarea', 'pre', 'code'],
+    ignoreClass: "container|files",
+    processClass: "markdown-body"
+  }
+});
+</script>
+<script src="https://gitee.com/uploads/resources/MathJax-2.7.2/MathJax.js?config=TeX-AMS-MML_HTMLorMML" type="text/javascript"></script>
+
+<script>
+  var messages = {
+    'zh-CN': {
+      addResult: '增加 <b>{term}</b>',
+      count: '已选择 {count}',
+      maxSelections: '最多 {maxCount} 个选择',
+      noResults: '未找到结果',
+      serverError: '连接服务器时发生错误'
+    },
+    'zh-TW': {
+      addResult: '增加 <b>{term}</b>',
+      count: '已選擇 {count}',
+      maxSelections: '最多 {maxCount} 個選擇',
+      noResults: '未找到結果',
+      serverError: '連接服務器時發生錯誤'
+    }
+  }
+  
+  if (messages[gon.locale]) {
+    $.fn.dropdown.settings.message = messages[gon.locale]
+  }
+</script>
+
+<!--[if lt IE 10]>
+<script>
+    window.location.href = "/incompatible.html";
+</script>
+<![endif]-->
+</head>
+
+<body class='git-project lang-zh-CN'>
+<script src="https://assets.gitee.com/assets/projects/app-07d5c52c6dbb2fdb0c24573cd5192d16.js" type="text/javascript"></script>
+<header class='common-header fixed noborder' id='git-header-nav'>
+<div class='ui container'>
+<div class='ui menu header-menu'>
+<div class='git-nav-expand-bar'>
+<i class='iconfont icon-mode-table'></i>
+</div>
+<div class='gitee-nav__sidebar'>
+<div class='gitee-nav__sidebar-container'>
+<div class='gitee-nav__sidebar-top'>
+<div class='gitee-nav__avatar-box'></div>
+<div class='gitee-nav__buttons-box'>
+<a href="/login" class="ui button small fluid orange">登录</a>
+<a href="/signup" class="ui button small fluid basic is-register">注册</a>
+</div>
+</div>
+<div class='gitee-nav__sidebar-middle'>
+<div class='gitee-nav__sidebar-list'>
+<ul>
+<li class='gitee-nav__sidebar-item'>
+<a href="/explore"><i class='iconfont icon-ic-discover'></i>
+<span class='gitee-nav__sidebar-name'>开源软件</span>
+</a></li>
+<li class='gitee-nav__sidebar-item'>
+<a href="/gists"><i class='iconfont icon-ic-gists1'></i>
+<span class='gitee-nav__sidebar-name'>代码片段</span>
+</a></li>
+<li class='gitee-nav__sidebar-item'>
+<a href="/enterprises"><i class='iconfont icon-ic-enterprise'></i>
+<span class='gitee-nav__sidebar-name'>企业版</span>
+</a></li>
+<li class='gitee-nav__sidebar-item'>
+<a href="/education"><i class='iconfont icon-ic-education'></i>
+<span class='gitee-nav__sidebar-name'>高校版</span>
+</a></li>
+<li class='gitee-nav__sidebar-item split-line'></li>
+<li class='gitee-nav__sidebar-item'>
+<a href="/search"><i class='iconfont icon-ic-search'></i>
+<span class='gitee-nav__sidebar-name'>搜索</span>
+</a></li>
+<li class='gitee-nav__sidebar-item'>
+<a href="/help"><i class='iconfont icon-help-circle'></i>
+<span class='gitee-nav__sidebar-name'>帮助中心</span>
+</a></li>
+<li class='gitee-nav__sidebar-item'>
+<a href="/terms"><i class='iconfont icon-file'></i>
+<span class='gitee-nav__sidebar-name'>使用条款</span>
+</a></li>
+<li class='gitee-nav__sidebar-item'>
+<a href="/about_us"><i class='iconfont icon-issuepx'></i>
+<span class='gitee-nav__sidebar-name'>关于我们</span>
+</a></li>
+</ul>
+</div>
+</div>
+<div class='gitee-nav__sidebar-bottom'>
+<div class='gitee-nav__sidebar-close-button'>
+<i class='fa fa-angle-double-left'></i>
+</div>
+</div>
+</div>
+</div>
+
+<div class='item gitosc-logo'>
+<a href="/"><img class='ui inline image' height='28' src='/logo.svg?20171024' width='95'>
+<img class='ui inline black image' height='28' src='/logo-black.svg?20171024' width='95'>
+</a></div>
+<a href="/explore" class="item " title="开源软件">开源软件
+</a><a href="/enterprises" class="item " title="企业版">企业版
+<sup class='ui red label'>
+特惠
+</sup>
+</a><a href="/education" class="item " title="高校版">高校版
+</a><a href="https://blog.gitee.com/" class="item" id="gitee-blog" target="_blank" title="博客">博客
+</a><div class='center responsive-logo'>
+<a href="/"><img class='ui inline image' height='24' src='/logo.svg?20171024' width='85'>
+<img class='ui inline black image' height='24' src='/logo-black.svg?20171024' width='85'>
+</a></div>
+<div class='right menu userbar' id='git-nav-user-bar'>
+<div class='item git-nav-search-item'>
+<form accept-charset="UTF-8" action="/search" autocomplete="on" data-text-filter="搜索格式不正确" data-text-require="搜索关键字不能少于1个" id="navbar-search-form" method="get"><div style="margin:0;padding:0;display:inline"><input name="utf8" type="hidden" value="&#x2713;" /></div>
+<div class='ui mini fluid input'>
+<input id="navbar-search-input" name="q" placeholder="搜索项目、代码片段..." type="text" value="" />
+<input id="navbar-search-type" name="type" type="hidden" />
+</div>
+</form>
+
+
+</div>
+<a href="/signup" class="item git-nav-user__register-item">注册
+</a><a href="/login" class="item git-nav-user__login-item">登录
+</a><script>
+  $('.destroy-user-session').click(function() {
+    $.cookie('access_token', null, { path: '/' });
+  })
+</script>
+
+</div>
+</div>
+</div>
+</header>
+<script>
+  Gitee.initNavbar()
+  Gitee.initRepoRemoteWay()
+</script>
+
+<!--[if lt IE 10]>
+<script>
+  window.location.href = "/incompatible.html"
+</script>
+<![endif]-->
+
+<div class='fixed-notice-infos'>
+<div class='all-messages'>
+<div class='ui info message' id='git-bulletin'>
+<a href=https://gitee.com/oschina/gitee_best_practices target='_blank'>码云「最佳实践」征文大赛获奖文章公布
+</a>
+<i class='icon remove' id='remove-bulletin'></i>
+</div>
+</div>
+<div class='ui container'>
+<div class='flash-messages' id='messages-container'></div>
+</div>
+<script>
+  (function() {
+    $(function() {
+      var $error_box, alertTip, notify_content, notify_options, template;
+  
+      template = '<div data-notify="container" class="ui {0} message" role="alert">' + '<i data-notify="dismiss" class="close icon"></i>' + '<span data-notify="message">{2}</span>' + '</div>';
+      notify_content = null;
+      notify_options = {};
+      alertTip = '';
+      $error_box = $(".flash_error.flash_error_box");
+      if (notify_options.type === 'error' && $error_box.length > 0 && !$.isEmptyObject(notify_content.message)) {
+        if (notify_content.message === 'captcha_fail') {
+          alertTip = "验证码不正确";
+        } else if (notify_content.message === 'captcha_expired') {
+          alertTip = "验证码已过期，请点击刷新";
+        } else if (notify_content.message === 'not_found_in_database') {
+          alertTip = "帐号或者密码错误";
+        } else if (notify_content.message === 'not_found_and_show_captcha') {
+          alertTip = "帐号或者密码错误";
+        } else if (notify_content.message === 'phone_captcha_fail') {
+          alertTip = "手机验证码不通过";
+        } else {
+          alertTip = notify_content.message;
+        }
+        return $error_box.html(alertTip).show();
+      } else if (notify_content) {
+        notify_options.delay = 3000;
+        notify_options.template = template;
+        notify_options.offset = {
+          x: 10,
+          y: 30
+        };
+        notify_options.element = '#messages-container';
+        return $.notify(notify_content, notify_options);
+      }
+    });
+  
+  }).call(this);
+</script>
+
+</div>
+<script>
+  (function() {
+    $(function() {
+      var setCookie;
+  
+      setCookie = function(name, value) {
+        $.cookie(name, value, {
+          path: '/',
+          expires: 365
+        });
+      };
+      $('#remove-bulletin').on('click', function() {
+        setCookie('remove_bulletin', "gitee-maintain-1562120552");
+        $('#git-bulletin').hide();
+      });
+      $('#remove-member-bulletin').on('click', function() {
+        setCookie('remove_member_bulletin', "gitee_member_bulletin");
+        $(this).parent().hide();
+      });
+      return $('#remove-gift-bulletin').on('click', function() {
+        setCookie('remove_gift_bulletin', "gitee-gift-bulletin");
+        $(this).parent().hide();
+      });
+    });
+  
+  }).call(this);
+</script>
+
+<div class='site-content'>
+<div class='git-project-header'>
+<div class='fixed-notice-infos'>
+<div class='ui info icon floating message green' id='fetch-ok' style='display: none'>
+<div class='content'>
+<div class='header status-title'>
+<i class='info icon status-icon'></i>
+代码拉取完成，页面将自动刷新
+</div>
+</div>
+</div>
+<div class='ui info icon floating message error' id='fetch-error' style='display: none'>
+<div class='content'>
+<div class='header status-title'>
+<i class='info icon status-icon'></i>
+<span class='error_msg'></span>
+</div>
+</div>
+</div>
+</div>
+<div class='ui container'>
+
+<div class='git-project-header-details'>
+<div class='git-project-header-container'>
+<div class='git-project-header-actions'>
+<div class='ui tiny modal project-donate-modal' id='project-donate-modal'>
+<i class='iconfont icon-close close'></i>
+<div class='header'>捐赠</div>
+<div class='content'>
+该仓库未开启捐赠功能，可发送私信通知作者开启
+</div>
+<div class='actions'>
+<a class='ui blank button cancel'>取消</a>
+<a class='ui orange ok button' href='/notifications/messages/1559622'>发送私信</a>
+</div>
+</div>
+<div class='ui small modal wepay-qrcode'>
+<i class='iconfont icon-close close'></i>
+<div class='header'>
+扫描微信二维码支付
+<span class='wepay-cash'></span>
+</div>
+<div class='content weqcode-center'>
+<img id='wepay-qrcode' src=''>
+</div>
+<div class='actions'>
+<div class='ui cancel blank button'>取消</div>
+<div class='ui ok orange button'>
+支付完成
+</div>
+</div>
+</div>
+<div class='ui mini modal' id='confirm-alipay-modal'>
+<div class='header'>支付提示</div>
+<div class='content'>
+将跳转至支付宝完成支付
+</div>
+<div class='actions'>
+<div class='ui approve orange button'>
+确定
+</div>
+<div class='ui blank cancel button'>
+取消
+</div>
+</div>
+</div>
+
+<span class='ui basic buttons watch-container'>
+<a href="/login" class="ui button watch" title="登录以Watch"><i class='iconfont icon-watch'></i>
+Watch
+</a><a href="/chenssy/blog-home/watchers" class="ui button action-social-count" title="4">4
+</a></span>
+<span class='ui basic buttons star-container'>
+<a href="/login" class="ui button star" title="你必须登录后才可以star一个仓库"><i class='iconfont icon-star'></i>
+Star
+</a><a href="/chenssy/blog-home/stargazers" class="ui button action-social-count" title="11">11
+</a></span>
+<span class='ui basic buttons fork-container' data-content='无权 Fork 此仓库'>
+<a href="/login" class="ui button fork "><i class='iconfont icon-fork'></i>
+Fork
+</a><a href="/chenssy/blog-home/members" class="ui button action-social-count" title="10">10
+</a></span>
+</div>
+<h2 class='git-project-title'>
+<span class="project-title"><i class="project-icon iconfont icon-project-public" title="这是一个公开仓库"></i> <a href="/chenssy" class="author" title="chenssy">chenssy</a> / <a href="/chenssy/blog-home" class="repository" style="padding-bottom: 0px" target="" title="blog-home">blog-home</a></span><span class="project-badges"><a href="/explore/all?lang=Java" class="ui small label proj-language" target="_blank" title="主要编程语言">Java</a><a href="/chenssy/blog-home/blob/master/LICENSE" class="ui small license label" title="开源许可协议">Apache-2.0</a></span>
+
+<input id="project_title" name="project_title" type="hidden" value="chenssy/blog-home" />
+</h2>
+</div>
+</div>
+</div>
+<div class='row' id='import-result-message' style='padding-top: 0px; display: none'>
+<div class='sixteen wide column'>
+<div class='ui icon yellow message status-color'>
+<i class='info icon status-icon' style='width:60px;padding-right:12px;'></i>
+<i class='close icon'></i>
+<div class='header status-title'>
+同步状态
+</div>
+<span class='status-message'></span>
+</div>
+</div>
+</div>
+<div class='ui small modal' id='modal-fork-project'>
+<i class='icon-close iconfont close'></i>
+<div class='header'>
+Fork 仓库
+</div>
+<div class='content'>
+<div class='fork-info-content'>
+<div class='ui segment fork_project_loader'>
+<div class='ui active inverted dimmer'>
+<div class='ui text loader'>加载中</div>
+</div>
+</div>
+</div>
+</div>
+<div class='actions fork-action hide'>
+<a class='cancel'>&emsp;取消&emsp;</a>
+<div class='ui large button orange ok'>&emsp;确认&emsp;</div>
+</div>
+</div>
+<script>
+  (function() {
+    $('.fork-container').popup({
+      inline: true,
+      hoverable: true,
+      position: 'bottom left'
+    });
+  
+  }).call(this);
+</script>
+<script>
+  (function() {
+    $('#modal-fork-project').modal({
+      transition: 'fade'
+    });
+  
+    $('.checkbox.sync-wiki').checkbox();
+  
+  }).call(this);
+</script>
+<style>
+  i.loading{-webkit-animation:icon-loading 1.2s linear infinite;animation:icon-loading 1.2s linear infinite}.qrcode_cs{float:left}.check-sync-wiki{float:left;height:28px;line-height:28px}.check-sync-wiki .sync-wiki-warn{color:#e28560}
+</style>
+<script>
+  $('.metrics-radar').dropdown({ action: 'nothing' });
+</script>
+
+<div class='git-project-nav'>
+<div class='ui container'>
+<div class='ui secondary pointing menu'>
+<a href="/chenssy/blog-home" class="item active"><i class='iconfont icon-code'></i>
+代码
+</a><a href="/chenssy/blog-home/issues" class="item "><i class='iconfont icon-issue'></i>
+Issues
+<span class='ui mini circular label'>
+0
+</span>
+</a><a href="/chenssy/blog-home/pulls" class="item "><i class='iconfont icon-pull-request'></i>
+Pull Requests
+<span class='ui mini circular label'>
+0
+</span>
+</a><a href="/chenssy/blog-home/attach_files" class="item "><i class='iconfont icon-annex'></i>
+附件
+<span class='ui mini circular label'>0</span>
+</a><a href="/chenssy/blog-home/wikis" class="item "><i class='iconfont icon-wiki'></i>
+Wiki
+<span class='ui mini circular label'>
+0
+</span>
+</a><a href="/chenssy/blog-home/graph/master" class="item  "><i class='iconfont icon-statistics'></i>
+统计
+</a><div class='item project-devops-item'>
+<div class='ui pointing top right dropdown project-devops-dropdown'>
+<div class='text'>
+<i class='iconfont icon-devops'></i>
+DevOps
+</div>
+<i class='dropdown icon'></i>
+<div class='menu' style='display:none'>
+<a href="https://gitee.com/help/articles/4193" class="item" target="_blank"><img alt="Jenkins_for_gitee" src="https://assets.gitee.com/assets/jenkins_for_gitee-a079e18b0276e2d1230294a470364e7b.png" />
+<div class='item-title'>
+Jenkins for Gitee
+</div>
+</a><a href="/chenssy/blog-home/paas/code_pipeline" class="item"><img alt="Code_pipeline" src="https://assets.gitee.com/assets/code_pipeline-502dbffc863fcc0b6867628c9e8e163e.svg" />
+<div class='item-title'>
+阿里云 CodePipeline
+</div>
+</a><a href="/chenssy/blog-home/paas/huaweicloud_swr" class="item"><img alt="Huaweirqy" src="https://assets.gitee.com/assets/huaweirqy-c24d1adc35c0ecb2bc1e39f6e033835c.png" />
+<div class='item-title'>
+华为容器云
+</div>
+</a><a href="/chenssy/blog-home/paas/huaweicloud_cse" class="item"><img alt="Hauweiwfw" src="https://assets.gitee.com/assets/hauweiwfw-9edbcf60ca0a5d0de81d2fc804efa9ac.png" />
+<div class='item-title'>
+华为微服务平台
+</div>
+</a><a href="/chenssy/blog-home/paas/tencent_hub" class="item"><img alt="Tencent_hub" src="https://assets.gitee.com/assets/tencent_hub-e263083dfb38e2149d8a9eca5347f4d5.png" />
+<div class='item-title'>
+Tencent Hub
+</div>
+</a><a href="/chenssy/blog-home/paas/select_platform" class="item"><img alt="Mopaas_mini" src="https://assets.gitee.com/assets/mopaas_mini-72f0d5aeae31630ae89f624dfb0c23ca.png" />
+<div class='item-title'>
+MoPaaS V3
+</div>
+</a></div>
+</div>
+</div>
+<div class='item'>
+<div class='ui pointing top right dropdown git-project-service'>
+<div class='text'>
+<i class='iconfont icon-service'></i>
+服务
+</div>
+<i class='dropdown icon'></i>
+<div class='menu' style='display:none'>
+<a href="/chenssy/blog-home/pages" class="item"><img alt="Gitee" src="https://assets.gitee.com/assets/gitee-d6fb391be28450a587df71dda0325f60.png" />
+<div class='item-title'>
+Gitee Pages
+</div>
+</a><a href="/chenssy/blog-home/javadoc" class="item"><img alt="Maven" src="https://assets.gitee.com/assets/maven-aea8b4f12e957c8c67de9c6fc83d27e6.png" />
+<div class='item-title'>
+JavaDoc
+</div>
+</a><a href="/chenssy/blog-home/quality_analyses?platform=sonar_qube" class="item"><img alt="Sonar_mini" src="https://assets.gitee.com/assets/sonar_mini-6270e37950512a0bf0a05ac5b9b11243.png" />
+<div class='item-title'>
+质量分析
+</div>
+</a><button class='ui orange basic button quit-button' id='quiting-button'>
+我知道了，不再自动展开
+</button>
+</div>
+</div>
+</div>
+</div>
+</div>
+</div>
+<script>
+  $('.git-project-nav .ui.dropdown').dropdown({ action: 'nothing' });
+</script>
+<style>
+  .git-project-nav i.checkmark.icon {
+    color: green;
+  }
+  #quiting-button {
+    display: none;
+  }
+</style>
+<script>
+  isSignIn = false
+  isClickGuide = false
+  $('#git-versions.dropdown').dropdown();
+  $.ajax({
+    url:"/chenssy/blog-home/access/add_access_log",
+    type:"GET"
+  });
+  $('#quiting-button').on('click',function() {
+    $('.git-project-service').click();
+    if (isSignIn) {
+      $.post("/projects/set_service_guide")
+    }
+    $.cookie("Serve_State", true, { expires: 3650, path: '/'})
+    $('#quiting-button').hide();
+  });
+  if (!(isClickGuide || $.cookie("Serve_State") == 'true')) {
+    $('.git-project-service').click()
+    $('#quiting-button').show()
+  }
+</script>
+
+</div>
+<div class='ui container'>
+<div class='register-guide'>
+<div class='register-container'>
+<div class='regist'>
+加入码云
+</div>
+<div class='description'>
+与超过 300 万 开发者一起发现、参与优秀开源项目，私有仓库也完全免费 ：）
+</div>
+<a href="/signup?from=project-guide" class="ui orange button free-registion">免费加入</a>
+<div class='login'>
+已有帐号？
+<a href="/login?from=project-guide">立即登录</a>
+</div>
+</div>
+</div>
+
+<div class='git-project-content-wrapper'>
+<div class='git-project-content' id='git-project-content'>
+<div class='row'>
+<div class='git-project-desc-wrapper'>
+<div class='git-project-desc'>
+<div class='project-introduce'>
+<span class='git-project-desc-text'>
+记录自己写的博客和收录的优秀博客
+</span>
+<a class='hide spread' href='javascript:void(0);'>
+展开
+<i class='caret down icon'></i>
+</a>
+<a class='retract hide' href='javascript:void(0);'>
+收起
+<i class='caret up icon'></i>
+</a>
+<p class='git-project-homepage'>
+</p>
+</div>
+</div>
+<div class='git-project-desc-edit flex'>
+<div class='sixty-percent ui small input'>
+<input name='project[description]' placeholder='描述' type='text' value='记录自己写的博客和收录的优秀博客'>
+</div>
+<div class='twenty-percent ui small input'>
+<input data-regex-value='(^$)|(^(http|https):\/\/(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5]).*)|(^(http|https):\/\/[a-zA-Z0-9]+([_\-\.]{1}[a-zA-Z0-9]+)*\.[a-zA-Z]{2,10}(:[0-9]{1,10})?(\/.*)?$)' name='project[homepage]' placeholder='主页(eg: https://gitee.com)' type='text'>
+</div>
+<div class='zero-percent'>
+<button class='ui orange button btn-save'>
+保存更改
+</button>
+<button class='ui button btn-cancel-edit'>
+取消
+</button>
+</div>
+</div>
+<script>
+  $(function () {
+    new ProjectInfoEditor({
+      el: '.git-project-desc-wrapper',
+      homepage: null,
+      description: "记录自己写的博客和收录的优秀博客",
+      url: "/chenssy/blog-home/update_description",
+      modalHelper: Gitee.modalHelper
+    })
+  })
+</script>
+</div>
+
+</div>
+<div class='git-project-summary' id='git-project-summary'>
+<div class='summary-viewer'>
+<div class='viewer-wrapper'>
+<ul>
+<li>
+<a href="/chenssy/blog-home/commits/master"><i class='iconfont icon-commit'></i>
+<b>225</b>
+次提交
+</a></li>
+<li>
+<a href="/chenssy/blog-home/branches"><i class='iconfont icon-branches'></i>
+<b>1</b>
+个分支
+</a></li>
+<li>
+<a href="/chenssy/blog-home/tags"><i class='iconfont icon-tag'></i>
+<b>0</b>
+个标签
+</a></li>
+<li>
+<a href="/chenssy/blog-home/releases"><i class='iconfont icon-release'></i>
+<b>0</b>
+个发行版
+</a></li>
+<li>
+<a href="/chenssy/blog-home/contributors?ref=master"><i class='iconfont icon-collaborators'></i>
+<b class='contributor-count' data-url='/chenssy/blog-home/contributors_count?ref=master'></b>
+<span class='contributor-text'>
+正在获取贡献者
+</span>
+</a></li>
+</ul>
+<ul>
+</ul>
+</div>
+</div>
+<div class='summary-languages' title='点击查看语言占比'>
+</div>
+
+</div>
+<div class='git-project-bread' id='git-project-bread'>
+<div class='git-project-right-actions float-right'>
+<div class='d-inline-block' id='git-project-tree-actions'>
+<script>
+  $('.disabled-upload-readonly').popup({
+    content: "只读目录不允许上传文件",
+    className: {
+      popup: 'ui popup',
+    },
+    position: 'bottom center',
+  })
+  $('.disabled-create-folder').popup({
+    content: "只读目录不允许创建目录",
+    className: {
+      popup: 'ui popup',
+    },
+    position: 'bottom center',
+  })
+  $('.disabled-create-file').popup({
+    content: "只读目录不允许创建文件",
+    className: {
+      popup: 'ui popup',
+    },
+    position: 'bottom center',
+  })
+  $('.disabled-upload-readonly').click(() => {
+    return false
+  })
+  $('.disabled-create-folder').click(() => {
+    return false
+  })
+  $('.disabled-create-file').click(() => {
+    return false
+  })
+</script>
+<style>
+  .disabled-upload-readonly,.disabled-create-file,.disabled-create-folder{background-color:#dcddde !important;color:rgba(0,0,0,0.4) !important;opacity:0.3 !important;background-image:none !important;-webkit-box-shadow:none !important;box-shadow:none !important}
+</style>
+
+</div>
+<div class='ui orange button' id='btn-dl-or-clone'>
+克隆/下载
+<i class='dropdown icon'></i>
+<div class='git-project-download-panel for-project ui bottom right popup'>
+<div class='ui small secondary pointing menu'>
+<a class='item active' data-type='http' data-url='https://gitee.com/chenssy/blog-home.git'>HTTPS</a>
+<a class='item' data-type='ssh' data-url='git@gitee.com:chenssy/blog-home.git'>SSH</a>
+</div>
+<div class='ui fluid right labeled small input'>
+<input id="project_clone_url" name="project_clone_url" onclick="focus();select()" readonly="readonly" type="text" value="https://gitee.com/chenssy/blog-home.git" />
+<div class='ui basic label'>
+<div class='ui small basic orange button' data-clipboard-target='#project_clone_url' id='btn-copy-clone-url'>
+复制
+</div>
+</div>
+</div>
+<hr>
+<a href="javascript:void(0);" class="ui fluid download link button"><i class='icon download'></i>
+下载ZIP
+</a><div class='download_repository_zip form modal tiny ui' id='unlanding-complaint-modal'>
+<i class='iconfont icon-close close'></i>
+<div class='header'>
+登录提示
+</div>
+<div class='container actions'>
+<div class='content'>
+该操作需登录码云帐号，请先登录后再操作。
+</div>
+<div class='ui orange icon large button ok'>
+立即登录
+</div>
+<div class='ui button blank cancel'>
+没有账号，去注册
+</div>
+</div>
+</div>
+<script>
+  var $elm = $('.download');
+  
+  $elm.on('click', function() {
+    var modals = $("#unlanding-complaint-modal.download_repository_zip");
+    if (modals.length > 1) {
+      modals.eq(0).modal('show');
+    } else {
+      modals.modal('show');
+    }
+  })
+  $("#unlanding-complaint-modal.download_repository_zip").modal({
+    onDeny: function() {
+      window.location.href = "/signup?from=download_repository_zip";
+    },
+    onApprove: function() {
+      window.location.href = "/login?from=download_repository_zip";
+    }
+  })
+</script>
+
+<hr>
+
+</div>
+<script>
+  (function() {
+    var $btnCopy, $input, $item, $panel, clipboard, remoteWay;
+  
+    $input = $('#project_clone_url');
+  
+    remoteWay = '';
+  
+    clipboard = new Clipboard('#btn-copy-clone-url');
+  
+    $panel = $('.git-project-download-panel');
+  
+    $btnCopy = $('#btn-copy-clone-url');
+  
+    $panel.find('.menu > .item').on('click', function() {
+      var $item;
+  
+      $item = $(this).addClass('active');
+      $item.siblings().removeClass('active');
+      $input.val($item.attr('data-url'));
+      return $.cookie('remote_way', $item.attr('data-type'), {
+        expires: 365,
+        path: '/'
+      });
+    });
+  
+    $('body').on('click', '#btn-dl-or-clone', function(e) {
+      e.stopImmediatePropagation();
+      if ($(e.target)[0] === $panel[0] || $(e.target).closest($panel).length) {
+        return;
+      }
+      return $panel.transition('fade up');
+    });
+  
+    $('body').on('click', function() {
+      if ($panel.transition('is visible')) {
+        return $panel.transition('fade up');
+      }
+    });
+  
+    $item = null;
+  
+    if (remoteWay) {
+      $item = $panel.find('.item[data-type="' + remoteWay + '"]');
+    }
+  
+    if (!$item || $item.length < 1) {
+      $item = $panel.find('.ui.menu .item').eq(0);
+    }
+  
+    $item.addClass('active').siblings().removeClass('active');
+  
+    $input.val($item.attr('data-url'));
+  
+    clipboard.on('success', function() {
+      $btnCopy.popup({
+        content: '已复制',
+        position: 'right center',
+        onHidden: function() {
+          return $btnCopy.popup('destroy');
+        }
+      });
+      return $btnCopy.popup('show');
+    });
+  
+    clipboard.on('error', function() {
+      $btnCopy.popup({
+        content: '复制失败，请手动复制',
+        position: 'right center',
+        onHidden: function() {
+          return $btnCopy.popup('destroy');
+        }
+      });
+      return $btnCopy.popup('show');
+    });
+  
+  }).call(this);
+</script>
+
+</div>
+</div>
+<div class='ui horizontal list'>
+<div class='item git-project-branch-item'>
+<input id="path" name="path" type="hidden" value="image/201811/87106504.jpg" />
+<div class='ui top left pointing dropdown gradient button dropdown-has-tabs' id='git-project-branch'>
+<input id="ref" name="ref" type="hidden" value="master" />
+<div class='default text'>
+master
+</div>
+<i class='dropdown icon'></i>
+<div class='menu'>
+<div class='ui left icon search input'>
+<i class='iconfont icon-search'></i>
+<input placeholder='搜索分支' type='text'>
+</div>
+<div class='tab-menu'>
+<div class='tab-menu-action' data-tab='branches'>
+<a href="/chenssy/blog-home/branches" class="ui link button">管理</a>
+</div>
+<div class='tab-menu-action' data-tab='tags'>
+<a href="/chenssy/blog-home/tags" class="ui link button">管理</a>
+</div>
+<div class='tab-menu-item' data-placeholder='搜索分支' data-tab='branches'>
+分支 (1)
+</div>
+</div>
+<div class='tab scrolling menu' data-tab='branches'>
+<div class='item' data-value='master'>master</div>
+</div>
+</div>
+</div>
+
+<script>
+  $(function () {
+    Gitee.initTabsInDropdown($('#git-project-branch').dropdown({
+      fullTextSearch: true,
+      onChange: function (value, text) {
+        var path = $('#path').val();
+        var href = ['/chenssy/blog-home/tree', encodeURIComponent(value), path].join('/');
+        window.location.href = href;
+      }
+    }));
+  })
+</script>
+
+</div>
+<div class='item' id='git-project-root-actions'>
+<div class='repo-index repo-none-index' style='margin-left:0px;'>
+<div class='ui horizontal list repo-action-list'>
+<div class='item'>
+<div class='ui pointing right top dropdown gradient button' id='git-project-file'>
+<div class='text'>文件</div>
+<i class='dropdown icon'></i>
+<div class='menu'>
+<div class='disabled item'>新建文件</div>
+<div class='disabled item'>上传文件</div>
+<a class='item repo-action' id='search-files'>
+搜索文件
+</a>
+</div>
+</div>
+</div>
+<div class='item'>
+<a href="/-/ide/project/chenssy/blog-home/edit/master" class="ui gradient button webide" target="_blank">Web IDE</a>
+</div>
+<div class='item'>
+<a href="/chenssy/blog-home/widget" class="ui gradient button repo-action"><i class='iconfont icon-widget icon-orange'></i>
+挂件
+</a></div>
+</div>
+<script>
+  $('#git-project-file').dropdown({ action: 'hide' });
+</script>
+</div>
+
+</div>
+<div class='item breadcrumb_path path-breadcrumb-contrainer' id='git-project-breadcrumb'>
+<div class='ui breadcrumb path project-path-breadcrumb' id='path-breadcrumb'>
+<a href="/chenssy/blog-home/tree/master" class="section repo-name" data-direction="back" style="font-weight: bold">blog-home
+</a><div class='divider'>
+/
+</div>
+<strong>
+<a href="/chenssy/blog-home/tree/master/image" class="section" data-direction="back"><span class='cblue'>
+image
+</span>
+</a></strong>
+<div class='divider'>
+/
+</div>
+<strong>
+<a href="/chenssy/blog-home/tree/master/image/201811" class="section" data-direction="back"><span class='cblue'>
+201811
+</span>
+</a></strong>
+<div class='divider'>
+/
+</div>
+<strong>
+87106504.jpg
+</strong>
+</div>
+
+
+</div>
+</div>
+</div>
+
+<style>
+  .ui.dropdown .menu>.header{text-transform:none}
+</style>
+<script>
+  $(document).ready(function () {
+    var $gitProjectSummary = $('#git-project-summary');
+    var $gitProjectLanguages = $gitProjectSummary.find('.summary-languages');
+    var $statsSwitcherWrapper = $gitProjectSummary.find('.viewer-wrapper');
+    var $contributorCount = $gitProjectSummary.find('.contributor-count');
+    var $contributorText = $gitProjectSummary.find('.contributor-text');
+    var contributorsCountUrl = $contributorCount.data('url');
+  
+    $gitProjectLanguages.on('click', function() {
+      $statsSwitcherWrapper.toggleClass('js-lang');
+    });
+  
+    $.ajax({
+      url: contributorsCountUrl,
+      method: 'GET',
+      success: function(data) {
+        if (data.status === 1) {
+          $contributorCount.text(data.contributors_count);
+          $contributorText.text('位贡献者')
+        } else {
+          $contributorText.text('获取失败')
+        }
+      }
+    });
+    var $tip = $('#apk-download-tip');
+    if (!$tip.length) {
+      return;
+    }
+    $tip.find('.btn-close').on('click', function () {
+      $tip.slideUp();
+    });
+  });
+  (function(){
+    function pathAutoRender() {
+      var $parent = $('#git-project-bread'),
+          $child = $('#git-project-bread').children('.ui.horizontal.list'),
+          mainWidth = 0;
+      $child.each(function (i,item) {
+        mainWidth += $(item).width()
+        });
+      $('.breadcrumb.path.fork-path').remove();
+      if (mainWidth > 995) {
+        $('#path-breadcrumb').hide();
+        $parent.append('<div class="ui breadcrumb path fork-path">' + $('#path-breadcrumb').html() + '<div/>')
+      } else {
+        $('#path-breadcrumb').show();
+      }
+    }
+    window.pathAutoRender = pathAutoRender;
+    pathAutoRender();
+  })();
+</script>
+
+<div class='row column tree-holder' id='tree-holder'>
+
+<div class='tree-content-holder' id='tree-content-holder'>
+<div class='file_holder'>
+<div class='file_title'>
+<div class='blob-header-title'>
+<div class='blob-description'>
+<i class='iconfont icon-readme'></i>
+<span class='file_name' title='87106504.jpg'>
+87106504.jpg
+</span>
+<small>40.91 KB</small>
+</div>
+<div class='options'><div class='ui mini buttons basic'>
+<a href="/chenssy/blog-home/raw/master/image/201811/87106504.jpg" class="ui button edit-raw" target="_blank">原始数据</a>
+<a href="/chenssy/blog-home/commits/master/image/201811/87106504.jpg" class="ui button edit-history">历史</a>
+</div>
+<script>
+  "use strict";
+  try {
+    if((gon.wait_fork!=undefined && gon.wait_fork==true) || (gon.wait_fetch!=undefined && gon.wait_fetch==true)){
+      $('.edit-blob').popup({content:"当前仓库正在后台处理中,暂时无法编辑", on: 'hover', delay: { show: 200, hide: 200 }});
+      $('.edit-blob').click(function(e){
+        e.preventDefault();
+      })
+    }
+  
+    var setUrl = function() {
+      var params = window.location.search
+      if (params==undefined || $.trim(params).length==0) return;
+      $('span.options').children('.basic').find('a').each(function(index,ele){
+        var origin_href = $(ele).attr('href');
+        if (origin_href!="#" && origin_href.indexOf('?') == -1){
+          $(ele).attr('href',origin_href+params);
+        }
+      });
+    }
+  
+    setUrl();
+  
+    var clipboard = null,
+        $btncopy  = $("#copy-text");
+  
+    clipboard = new Clipboard("#copy-text", {
+      text: function(trigger) {
+        return $("#blob_raw").val();
+      }
+    })
+  
+    clipboard.on('success', function(e) {
+      $btncopy.popup('hide');
+      $btncopy.popup('destroy');
+      $btncopy.popup({content: '已复制', position: 'bottom center'});
+      $btncopy.popup('show');
+    })
+  
+    clipboard.on('error', function(e) {
+      var giteeModal = new GiteeModalHelper({okText: '确定'});
+      giteeModal.alert("一键复制", '复制失败，请手动复制');
+    })
+  
+    $(function() {
+      $btncopy.popup({
+        content: '点击复制',
+        position: 'bottom center'
+      })
+    })
+  
+  } catch (error) {
+    console.log('blob/action error:' + error);
+  }
+  
+  $('.disabled-edit-readonly').popup({
+    content: "只读文件不可编辑",
+    className: {
+      popup: 'ui popup',
+    },
+    position: 'bottom center',
+  })
+  $('.disabled-edit-readonly').click(() => {
+    return false
+  })
+</script>
+<style>
+  .disabled-edit-readonly{background-color:#dcddde !important;color:rgba(0,0,0,0.4) !important;opacity:0.3 !important;background-image:none !important;-webkit-box-shadow:none !important;box-shadow:none !important}
+</style>
+</div>
+</div>
+<div class='contributor-description'><span class='recent-commit' style='margin-top: 0.7rem'>
+<a href="/chenssy" class="commit-author-link">chenssy</a>
+<span>提交于</span>
+<span class='timeago commit-date' title='2018-12-01 15:51:45 +0800'>
+2018-12-01 15:51
+</span>
+.
+<a href="/chenssy/blog-home/commit/3d0a650d8e676aa3370baad59da824348828bcda">add image</a>
+</span>
+</div>
+</div>
+<div class='clearfix'></div>
+<div class='file_content image_file'>
+<img src='data:image/jpeg;base64,iVBORw0KGgoAAAANSUhEUgAAA0AAAAHECAYAAAAQ3UqlAAAgAElEQVR4Xuy9&#x000A;B7hdVbW/PemdxGBA5UKCIig1iBQFpSMKGoICSgsRBAWkqoCIAYVLFClRKcIV&#x000A;gjQBwSBdpQQVFfSSUBSlJYKgIJgA0iHf8877n+db2dnnnL332WWVdz7PeXKy&#x000A;z1qzvGPuNddvjTHHWmDu3Llzg0UCEpCABApLYPbs2WHy5Mlh880379gYbrvt&#x000A;tvnqnj59eqDt2jJz5szAz1DK8OHDw5gxY/qqqP0/f+hvvJttttlQmm77uTCa&#x000A;MWNGrDdxbJRRKzYdP358GD16dNvHYYUSkIAEykJgAQVQWUzpOCQggaoSOO64&#x000A;48Lxxx9f1eF3ZdwIimZFRX8CsdMdHjt2bJg6dWqnm7F+CUhAAoUloAAqrOns&#x000A;uAQkIIH/I5AE0KhRo5q+SW+UYT1PBB4aPDO1pRWxUFtHrYcELwqCIlvqeaX4&#x000A;+7Rp0xodVleOGzZsWJ83KzFrhFG9MQ/UYZhdcMEFAQ9Yf2y6MmAbkYAEJJBz&#x000A;AgqgnBvI7klAAhIYjEASQBMnToxiyNJ+Ao2GrGVb7k8gtr93/1cjomeLLbZQ&#x000A;AHUKsPVKQAKlIaAAKo0pHYgEJFBVAgqgqlp+3nErgJwHEpCABBojoABqjJNH&#x000A;SUACEsgtAQVQbk3T1Y4pgLqK28YkIIECE1AAFdh4dl0CEpAABBRAzgMIKICc&#x000A;BxKQgAQaI6AAaoyTR0lAAhLILQEFUG5N09WOKYC6itvGJCCBAhNQABXYeHZd&#x000A;AhKQgB4g50AioAByLkhAAhJojIACqDFOHiUBCUggtwT0AOXWNF3t2JQpU8KE&#x000A;CROC7wHqKnYbk4AECkhAAVRAo9llCUhAAlkCCiDng55A54AEJCCBxgkogBpn&#x000A;5ZESkIAEcklAAZRLs3S9U86DriO3QQlIoKAEFEAFNZzdloAEJJAIeOPrXNAD&#x000A;5ByQgAQk0DgBBVDjrDxSAhKQQC4JKIByaZaud8p50HXkNigBCRSUgAKooIaz&#x000A;2xKQgAT0ADkHsgQUQM4HCUhAAo0RUAA1xsmjJCABCeSWgDe+uTVNVzt26KGH&#x000A;hsmTJ4fTTjst8LtFAhKQgATqE1AAOTMkIAEJFJyAAqjgBmxT9zfffPMwbdq0&#x000A;cOuttwZ+t0hAAhKQgALIOSABCUiglASaFUAzZ84Mq6yySmTx2c9+Npx77rlh&#x000A;wQUX7Dibe++9N7az5pprztfWyy+/HDbaaKOw3377hQMPPHDIfXnxxRfD9OnT&#x000A;w9y5c/vqWnHFFcPo0aMbqvvpp58O9913X9hiiy3mO/71118Pv/jFL8JWW20V&#x000A;Fl100Ybq68ZBCqBuULYNCUigDAT0AJXBio5BAhKoNIFmBdC///3vcP3114ff&#x000A;/OY34fHHHw9Tp07tigD6zGc+E9Zff/3wpS99aT57IVR++MMfhjXWWCN88IMf&#x000A;HLI9H3zwwbDaaqvNV8+ZZ54ZvvCFLwxa/09+8pPwzW9+M4qoBRZYYJ7jEZDr&#x000A;rLNOZLfssssOWle3DlAAdYu07UhAAkUnoAAqugXtvwQkUHkCzQqgBOzqq68O&#x000A;p59+erj55pvnEUC///3vw0knnRT4+z777BOOPvro8K53vSue9q9//St85zvf&#x000A;Cd/61rfCRz7ykTBs2LCw1157he233z786Ec/CgiHa665Jnz0ox8NX/va16KY&#x000A;QdyceOKJ4dhjj43CAU/PnDlzAoJoxx13DE8++WT0+rznPe8Jb3/72+PvWY9U&#x000A;f/257bbbwllnnRX79Z///Cfcdddd4Zxzzgljx46Nnz3wwANhs802C/fff394&#x000A;61vfGq644opw1FFHhRkzZoS77747nH322eGXv/xleNvb3hY///SnPx3FDoJw&#x000A;3LhxYZlllgm77LJLeOmll2LfGM9f/vKXONZHHnkk/o3x0/YPfvCDsPTSS4c/&#x000A;/elPkd1FF10UPvnJT4bDDz88MnjllVfCF7/4xfD888+HXXfdNfzud78LiDF+&#x000A;EC4HH3xwWGSRRWK/b7jhhii+EGrNeJgUQJW/FAhAAhJokIACqEFQHiYBCUgg&#x000A;rwRaFUAIAm7AswIIYfC+970vihsEATfiL7zwQhQNw4cPDx/+8IejsEAAPfro&#x000A;o+Hkk08O3//+98MBBxwQvv71r4fnnnsurLfeetHDxDmIj4UWWiicccYZUQBQ&#x000A;N3UgGhA/H/vYx6IAOuGEE+LxI0aMCD/96U/jOZSB+jNr1qyw8cYbx+O+/OUv&#x000A;xzovvPDC8PDDD4eRI0cGvEB4nP76179GTw3JAc4777wY2nbttdeGG2+8MWy4&#x000A;4Ybh73//exSCHIcY+vnPfx723HPPKHwmTJgQXn311fDe97439p+6P/e5zwXE&#x000A;F+IQkUT4HqLwiSeeiF6nnXfeOYqcW265JfJlXHi24IOX66mnngrLL7982G23&#x000A;3SIn2vvEJz4R7rnnnii86DNii/08sGq0KIAaJeVxEpBA1QkogKo+Axy/BCRQ&#x000A;eALtFEB4Iv75z3+GSy65JIoQBM0HPvCBKDAQGwgBvB9pDxGek1VXXTXsu+++&#x000A;AU8NQgdB8Nhjj8XjEEtvectbIuP9998/vP/9748Col656qqrwve+9715BNlA&#x000A;/dl7771jnSuvvHI45phjYrvsL7rssstiO/XC4PBO7bDDDjF8jbYQaJTrrrsu&#x000A;epA4j5L6goipFwKHFwsBuOSSS/YNBS/Q5z//+chqrbXWimLpG9/4Rjj11FPD&#x000A;YYcdFo9jPHC5+OKLo/coFbxtX/3qV6NYWnjhhaOA2nTTTaPoarQogBol5XES&#x000A;kEDVCSiAqj4DHL8EJFB4Aq0KoNqbfELVECfveMc74o07hc+23HLL8KlPfSps&#x000A;u+228aacG/illlpqHm7JU4P3Y5ttton7i/AsETKWRAIiCeEwmABKomOw/hAq&#x000A;lxVVr732WhgzZkwUb+uuu25IyR4YJx6Xd77znTHEDlH37ne/O4waNSomgcAD&#x000A;hAeK/T6cR0nesXoCCGEFh4ceeih6gFLBw0TIG94zQtcWX3zx6DUj+QLhf4T1&#x000A;EfaHWEMgZQsC6Pzzz4/eLwTXYGKx3qQ1DXbhv8oOQAIS6BIBBVCXQNuMBCQg&#x000A;gU4RaFYA/e///m8UB4Rx4S3Ba7PEEkuE7bbbLno+2NvCZ3gUCCmbNGlS+OMf&#x000A;/xhFxEorrRTD3cjWhocITwZih//zOSFdb7zxRnwfDTfz1I8o4qYebxFhXuyR&#x000A;IcvakUceGUPSOL6V/uApQVDg9WHvD94chAlZ7fic8LOvfOUrcQxkf9tkk01i&#x000A;P/BK4cliz9Laa68dBROhfISo4YVZbLHF4jgIf4MHYoa6yAjHfqckrC699NLY&#x000A;Nt4jRCF/+9CHPhQ9PrAk2cTtt98e9w/RNrwRWvClfcQRdeJxI+TtpptuiuFw&#x000A;iCpEFB432qU/jZRm50EjdXqMBCQggTISUACV0aqOSQISqBSBZm98CcMi/Ctb&#x000A;8I4QfoVnhxv4bKY2RAB7Uyi8YwaPULYgcriR33rrraPAobDnhYQA1MueGwQW&#x000A;abBJgpAKN/nsiWE/USv9QVBxLoU2SDyAWGMfDskYsm1l+0Eaa8LU2PeTLQgP&#x000A;PFkkfEC8IADTeBB/cEDI4JmCD5xSQWTtscceUWwhhLLlxz/+cQwZxPuVLfST&#x000A;fpP0ICVuQIwRGkeihWx/GpnQzc6DRur0GAlIQAJlJKAAKqNVHZMEJFApAtzI&#x000A;s8dk/PjxYcqUKW0ZO+/RYU8NyQPwtGQLHhuyuFFq//7ss89GjwkZ0eoVEgqQ&#x000A;VIHwsOz+mcE6PVB/Bju3v78jcghLy+7FqT12oGMIpUMM1Z5PxjcSMjA+xtmt&#x000A;ogDqFmnbkYAEik5AAVR0C9p/CUig8gS88a38FIgAnAfOAwlIQAKNEVAANcbJ&#x000A;oyQgAQnkloA3vrk1TVc75jzoKm4bk4AECkxAAVRg49l1CUhAAj75dw4kAgog&#x000A;54IEJCCBxggogBrj5FESkIAEckvAG9/cmqarHXMedBW3jUlAAgUmoAAqsPHs&#x000A;ugQkIAE9QM4BPUDOAQlIQALNEVAANcfLoyUgAQnkjoAvwMydSXrSIT1APcFu&#x000A;oxKQQAEJKIAKaDS7LAEJSCBLgPfVTJs2Lb6jh98t1SSgAKqm3R21BCTQPAEF&#x000A;UPPMPEMCEpBArggogHJljp51RgHUM/Q2LAEJFIyAAqhgBrO7EpCABGoJKICc&#x000A;ExBQADkPJCABCTRGQAHUGCePkoAEJJBbAt745tY0Xe2Y86CruG1MAhIoMAEF&#x000A;UIGNZ9clIAEJ+OTfOZAIKICcCxKQgAQaI6AAaoyTR0lAAhLILQFvfHNrmq52&#x000A;zHnQVdw2JgEJFJiAAqjAxrPrEpCABPQAOQf0ADkHJCABCTRHQAHUHC+PloAE&#x000A;JJA7Aqeffno47LDDwiGHHBL4vQpl9uzZYcaMGQ0Ndd111w3Dhw9v6Ng8HjRz&#x000A;5swwa9asvq71Nx49QHm0nn2SgATySEABlEer2CcJSEACTRC47bbbwhZbbBFG&#x000A;jx4d9t5774bP5Hh+KKNGjer7vV4F2ZtwfucnW6ZPnx4QJY2UMWPG1BUkiBT6&#x000A;Q12pMLZUmmmjXj/IlkcbtJ/GXk9M0M6cOXPiGLM/jI+/pf5n+aX3Lw0mtlLd&#x000A;/bFL401tNcKz9piJEyfGjHAWCUhAAhKoT0AB5MyQgAQkUHAC6cl/u4aRRMJQ&#x000A;BUe7+lOvnmHDhkUhki14SRBytaWe6Kg9BgHTzvHCsFFBOBin2rEONp7TTjst&#x000A;HHrooYNV698lIAEJVJaAAqiypnfgEpBAWQhwoz1lypSmb7izN/y1YVa1bLIe&#x000A;oiSQssf059Wpx7g/oZG8HsmbwrnZegdrY4EFFghz587t16x4V5JHJ/Vh2rRp&#x000A;8x2fxpo8PGm8tcIw1ZX11tSrL9tAPQ9Rdlxp7PUYDzZf0zzAC1jkkL/Bxunf&#x000A;JSABCQyVgAJoqAQ9XwISkEDJCNSGehVleIMJoP7G0YnxIo5SeGFR+NlPCUhA&#x000A;AlUhoACqiqUdpwQkIIGSE2hVAJUci8OTgAQkIIEaAgogp4QEJCABCZSCgAKo&#x000A;FGZ0EBKQgAQ6TkAB1HHENiABCUhAAt0goADqBmXbkIAEJFB8Agqg4tvQEUhA&#x000A;AhKQQAhBAeQ0kIAEJCCBRggogBqh5DESkIAEJJB7Agqg3JvIDkpAAhLIBQEF&#x000A;UC7MYCckIAEJSGCoBBRAQyXo+RKQgASqQUABVA07O0oJSEACpSegACq9iR2g&#x000A;BCQggbYQUAC1BaOVSEACEpBArwkogHptAduXgAQkUAwCCqBi2MleSkACEpDA&#x000A;IAQUQE4RCUhAAhJohIACqBFKHiMBCUhAArknoADKvYnsoAQkIIFcEFAA5cIM&#x000A;dkICEpCABIZKQAE0VIKeLwEJSKAaBBRA1bCzo5SABCRQegIKoNKb2AFKQAIS&#x000A;aAsBBVBbMFqJBCQgAQn0moACqNcWsH0JSEACxSCgACqGneylBCQgAQkMQkAB&#x000A;5BSRgAQkIIFGCCiAGqHkMRKQgAQkkHsCCqDcm8gOSkACEsgFAQVQLsxgJyQg&#x000A;AQlIYKgEFEBDJej5EpCABKpBQAFUDTs7SglIQAKlJ6AAKr2JHaAEJCCBthBQ&#x000A;ALUFo5VIQAISkECvCSiAem0B25eABCRQDAIKoGLYyV5KQAISkMAgBBRAThEJ&#x000A;SEACEmiEgAKoEUoeIwEJSEACuSegAMq9ieygBCQggVwQUADlwgx2QgISkIAE&#x000A;hkpAATRUgp4vAQlIoBoEFEDVsLOjlIAEJFB6AmUSQC+99FJYYoklSm+zXgzw&#x000A;xRdfDEsuuWQvmrZNCUggJwQUQDkxhN2QgAQkIIGhEWi3ALrrrrvCFVdcMV+n&#x000A;uHleeeWVw9577x0WXHDB+Pebb745PPvss4E+UBZZZJH4t1deeaXvfD7bYYcd&#x000A;wkILLRRuueWW8Oabb4att956vvo5Z5NNNol1Dhs2bGhQSnT2q6++Gu69994+&#x000A;5vWG9vrrr4d3vetdYcSIEX1/fvDBB8Pyyy8fWSJ+dt111zB16tRoB4sEJFBN&#x000A;AgqgatrdUUtAAhIoHYF2C6DLL788PP/882GzzTYL3FhTuGnmhvrUU08NN910&#x000A;U99NNGLlySefjAJo6aWXDuecc06YPn16PG7hhRcOL7/8cqxj5513jt6Hq666&#x000A;Kjz11FNhr732CmeddVY46KCDwmKLLRbbQAAhjK699tqGBRDnbLfdduGMM84I&#x000A;a6yxRk9tyzjvv//+sOaaa4Y33nij37EgAF977bXw1a9+NXz7298eVJA89thj&#x000A;4fjjjw/Dhw8Pl156afjIRz4S3vrWt8axXnzxxVE0InS+8pWvRIGayrnnnhuO&#x000A;O+648MMf/jB86EMfCkcccUTkpADq6TSxcQn0lIACqKf4bVwCEpCABNpFoN0C&#x000A;6LrrrguHH3542HDDDefpIt6bbbbZJpx33nl1vRH33Xdf2H333cNhhx0W1lln&#x000A;nbDCCiuEFVdccZ46EEBPP/102G+//cKXv/zlsPjii4dvfvObUUC1KoC22GKL&#x000A;KKbWXXfddiFtqR4E0KhRo8IDDzwQFl100SiAEIu1YWdw3HPPPWMbCJmf/exn&#x000A;8bzBCvUz1mydBxxwQDjwwAOj6EqF4/74xz+G97///eGZZ54J3/3ud8ORRx4Z&#x000A;eSuABqPs3yVQbgIKoHLb19FJQAISqAyBdgsgwt/wUGy00UbxX0p/HiD+hreI&#x000A;G2u8ExtssEHYdNNNw6qrrhpDriZOnBj23XffPsGUBND+++8fCO362Mc+Fm/M&#x000A;8Wr87W9/C+PHjw+//OUv63op8Bwde+yx0UO0+eabR6/ISiutFEVBEkB33HFH&#x000A;+NKXvhRmzZoVPv7xj8djEGIvvPBC+M53vhPwiiA68IogEPr7/Ne//nX485//&#x000A;HPuE4MNTdeihh8b9STNnzgwnnHBCuOGGG8KYMWPCiSeeGNZaa60oGq+88srw&#x000A;vve9L56zyy67hC9+8YuxXfrzox/9KGy11VZh7ty5gfEjNM8888wwduzY6CU7&#x000A;5ZRT4jmrrLJK3bmbBND1118flllmmXhMPQGEPfj8zjvvDJdddlnsI+ISO0yZ&#x000A;MkUPUGWuDA5UAvMTUAA5KyQgAQlIoBQE2i2ACGFjrwjemdqC4MDLQyH07aKL&#x000A;Lgqnn356OOqoo+JN94033hgef/zxeIOPuOCzhx56KIoW9qdkBRB1PProo2HH&#x000A;HXcM7Du65557wtVXXx09QrWFG/jtt98+eqWo+/zzzw/Tpk2LIgJPCwLo7W9/&#x000A;e1hvvfWiqFh//fXD//zP/8RwO8QZn7GPBgH1hz/8IfaL9n784x/X/fx3v/td&#x000A;9FKdfPLJsc3Pfe5zUbwQtoawSp8hlAhju+2222L4G96Yb33rW2HjjTeOwgZv&#x000A;F2LrkUceiULp9ttvD0sttVT04lAHfaDeFMoHy1pP1l//+te4hwcxiohBUDFW&#x000A;hBTjQUQSBodIfc973tOHjpDFY445JlxyySXhH//4RxRwiNu0X6sUk99BSEAC&#x000A;TRFQADWFy4MlIAEJSCCvBNolgBALCAn2kyy77LLRs0MoF3t0+D0Vjtttt92i&#x000A;oEHYsL8nZW5DwJAUYcKECX3H4xniJp96awUQB82ZMyfu+UE4rL322vGGvrZw&#x000A;M/+pT30q/OY3v4l7jTgHjwnhdggj+v3Od74z7j9CDOAt+clPfhJ/uOlnLwyC&#x000A;7Oijj479+NOf/hTD8xAT9T6/9dZbA94k+gTfFN7H53iGCPFjzIgqkkIkYYM3&#x000A;Cg8N3NibRB/xCNEfwgdb2av0gx/8INx9991xT9UvfvGLKMBSEgqEFN4nxoI9&#x000A;2AeEEEOEEnqHaKL/2AwGkydPjvXQH/r/4Q9/WEGU1y+2/ZJABwgogDoA1Sol&#x000A;IAEJSKD7BNolgJ577rl4o8+/3MTj6cFDg3cDz0ZKiIBgIOHAcsstF70QhILh&#x000A;oeDGmrArPByrr756BIEQQKCkjfe1AohkAfwN0YT4IQEDAqa2cB57ZWr3H+E5&#x000A;SSFw733ve6PAQNSkkvYsIQg++9nPRvFCITSOcDu8WPU+v+aaa8Ls2bPj3yjJ&#x000A;U4XQgQcepFQIqeNzPGYpiUP6HU8anLL9bHWvEl6cPfbYI4qg5MWpFwKH6Pv7&#x000A;3//el1yCfuJVwwM0cuTIQKpxhBGCCRvrEer+d9YWJdArAgqgXpG3XQlIQAIS&#x000A;aCuBdgmg1Knk/SB8ir0rhFmRtY1CW+y/SYIG4cNNP14QPDMIHgr7e7jpnzRp&#x000A;UhRFKa01guCf//xn+OQnPxn3zCBe8BbRxm9/+9sYMoaYqE2D/atf/SqGn9E3&#x000A;hBYeKcQS9eAxwgOEyCHMjH0vhOoRVnfSSSdFLxB/w/NDn0gQQBICwucQAfU+&#x000A;Z58P+38OPvjgOB7+jweKfTyIKsZBuB2eqC233HIeAZQ8QNmMdu0QQDCADXZJ&#x000A;5fOf/3zgh30+/RXGzn6uT3/603Hvku9ZauvXz8okUCgCCqBCmcvOSkACEpBA&#x000A;fwTaKYDw8rB3hbA3QseeeOKJ6O3YZ599ogcIYTNu3Li+m+iUuY102En8pH6S&#x000A;7nnbbbeNiQGSoEFAEIZGIVX2TjvtFM4+++woZhA37MlhX0wKPUt1JQ8Rm/gJ&#x000A;pyOZAfuP2HOEIEEAPfzww+G0006LSRTwUiHa8HhwLAINocI48IAQRsb+HrxF&#x000A;tZ/zGR4UBBohfmRoI1EDTNgXRHpwxNrb3va2uP+JVNR4ZRCAiB72/BCO14wA&#x000A;gm1KklAvI1yyC+xIMtGoACJ0jncwwQ2vD3uZLrjggrrvYfIbJgEJlJ+AAqj8&#x000A;NnaEEpCABCpBoJ0CCLFAGmdC3EgywD4WxAdZ0FJBQCQvQtq8j5BJIXEcR5/w&#x000A;0pB8IOvRIbSMF6MiYripJ0scaaEREG95y1viZ7SJp4JEAtlCPZ/5zGfiR4Sd&#x000A;ITze/e53970HiPPxCOG1ovDeG/bgEP6FtwYhkAoCiP0w7AWq9zkiCrGTCu3h&#x000A;9WGvDVnmEHUUEjIg3Ggb8UaSgt///vcBbw19Se80Gux9RclDBK9abw5M8KSR&#x000A;TAJxlX2PT38eILxsiELsSRIERBuFkD/2b7EvCW9ZvUQXlfjSOEgJVJSAAqii&#x000A;hnfYEpCABMpGoF0CiBdu4t1BkJAEAQGEF4gbbzb7Zws3/auttlrc+4OngzA2&#x000A;9v6wJygJILxFeGTqhbRxDPt18PbgcUlpnfkc7wr1IpJqC+ILsYBHqd7eFfYU&#x000A;sXeH+vBI8SJWQub4oT+ErPE7giWVep+z54i9UHiO/vWvf0Vxl22PNhByjBnP&#x000A;Ct6u9EJX6qv1hg1lzhGqhwDC20V72cL7fUhCQUrvVMh+h7DkHDLsZdlyDILq&#x000A;61//ehRS9TLuDaWvnisBCeSbgAIo3/axdxKQgAQk0CCBdgmgBpub7zA8PbU3&#x000A;2emggf7WanvdOI+QPJIOpD1A3WizvzZSooh6f6/3Nz5DiCL0LBKQgASyBBRA&#x000A;zgcJSEACEigFgV4LoFJArBkEXi88OYQCWiQgAQmUhYACqCyWdBwSkIAEKk5A&#x000A;AVTxCeDwJSABCTRIQAHUICgPk4AEJCCBfBNQAOXbPvZOAhKQQF4IKIDyYgn7&#x000A;IQEJSEACQyKgABoSPk+WgAQkUBkCCqDKmNqBSkACEig3AQVQue3r6CQgAQm0&#x000A;i4ACqF0krUcCEpCABHpKQAHUU/w2LgEJSKAwBBRAhTGVHZWABCQggYEIKICc&#x000A;HxKQgAQk0AgBBVAjlDxGAhKQgARyT0ABlHsT2UEJSEACuSCgAMqFGeyEBCQg&#x000A;AQkMlYACaKgEPV8CEpBANQgogKphZ0cpAQlIoPQEFEClN7EDlIAEJNAWAgqg&#x000A;tmC0EglIQAIS6DUBBVCvLWD7EpCABIpBQAFUDDvZSwlIQAISGISAAsgpIgEJ&#x000A;SEACjRBQADVCyWMkIAEJSCD3BBRAuTeRHZSABCSQCwIKoFyYwU5IQAISkMBQ&#x000A;CSiAhkrQ8yUgAQlUg4ACqBp2dpQSkIAESk9AAVR6EztACUhAAm0hoABqC0Yr&#x000A;kYAEJCCBXhNQAPXaArYvAQlIoBgEFEDFsJO9lIAEJCCBQQgogJwiEpCABCTQ&#x000A;CAEFUCOUPEYCEpCABHJPQAGUexPZQQlIQAK5IKAAyoUZ7IQEJCABCQyVgAJo&#x000A;qAQ9XwISkEA1CCiAqmFnRykBCUig9AQUQKU3sQOUgAQk0BYCCqC2YLQSCUhA&#x000A;AhLoNQEFUK8tYPsSkIAEikFAAVQMO9lLCUhAAhIYhIACyCkiAQlIQAKNEFAA&#x000A;NULJYyQgAQlIIPcEFEC5N5EdlIAEJJALAgqgXJjBTkhAAhKQwFAJKICGStDz&#x000A;JSABCVSDgAKoGnZ2lBKQgARKT0ABVHoTO0AJSEACbSGgAGoLRiuRgAQkIIFu&#x000A;E9hvv/3ChRdeGCZNmhQOOeSQkATQ5MmTw1FHHRX23HPPcM4553S7W7YnAQlI&#x000A;QAI5J6AAyrmB7J4EJCABCdQn8Pzzz4flllsuLLzwwmGJJZYIzz77bBgxYkR4&#x000A;6aWXwuuvvx6eeeaZsMwyy4hPAhKQgAQkMA8BBZATQgISkIAECkvg6KOPDqee&#x000A;emp49dVX+8aw6KKLhsMPPzycdNJJhR2XHZeABCQggc4RUAB1jq01S0ACEpBA&#x000A;hwngBRo5cmR45ZVX+lpabLHFwtNPP633p8PsrV4CEpBAUQkogIpqOfstAQlI&#x000A;QAKRQNYLpPfHSSEBCUhAAoMRUAANRsi/S0ACEpBArglkvUB6f3JtKjsnAQlI&#x000A;IBcEFEC5MIOdkIAEJCCBoRDAC3TKKaeEI444wr0/QwHpuRKQgAQqQEABVAEj&#x000A;O0QJSEACZSdw//33h/XWWy888sgj4b/+67/KPlzHJwEJSEACQyCgABoCPE+V&#x000A;gAQkIIHeEpg+fXrgvT9TpkyJHRk9enQ47rjjwvjx43vbMVuXgAQkIIHcElAA&#x000A;5dY0dkwCEpCABPojcNttt4Xjjz8+8G8qo0aNCrNmzVIIOW0kIAEJSGBAAgog&#x000A;J4gEJCABCRSGQK3wGTZsWDj00EPD3nvvHb0/eILwACmECmNSOyoBCUig6wQU&#x000A;QF1HboMSkIAEJNAsgQsuuCCcfvrpgZA3ShI+iJ/hw4fPV51CqFnCHi8BCUig&#x000A;OgQUQNWxtSOVgAQkUDgCM2fODBMmTOgLdSPMDW9Pf8KndoC1QmjMmDHh/FTT&#x000A;+jwAACAASURBVPPPD/xrkYAEJCCBahJQAFXT7o5aApUgcNddd4UrrrhivrEu&#x000A;ueSSYeWVV4430gsuuGAlWBRxkCQ3IJxt9uzZ0eODBwibtVJqhRD1Tpw4sZWq&#x000A;PGcIBG6++ebw7LPPhgUWWCDWssgii8Tv4CuvvNJXK5/tsMMOYaGFFhpCS54q&#x000A;AQlIoH8CCiBnhwQkUFoCl19+eeAlmZtttll4/fXX4zi5qXrwwQfDqaeeGm66&#x000A;6SZvsnJo/Vqvz9ixY+Pennqhbs10HyGF8EFYUfQGNUOvPccigJ588skogJZe&#x000A;eulwzjnnxLBGvo8LL7xwePnll+N3deeddw48qLBIQAIS6AQBBVAnqFqnBCSQ&#x000A;CwLXXXddOPzww8OGG244T39uueWWsM0224TzzjtPD1AuLPX/d2Lq1Kkx5C15&#x000A;fRA+O+64Y1t7SSIFPEkpUYLeoLbibbiy++67L+y+++7hsMMOC+uss05YYYUV&#x000A;woorrtjw+R4oAQlIoFUCCqBWyXmeBCSQewKEv7322mtho402iv9S9ADl02wI&#x000A;HoQPAojSLq9Pf6OlPULqSKVNwRt02mmnhc033zyfgErUK7yyZ5xxRrj00kvD&#x000A;BhtsEDbddNOw6qqrhl133TWGJe67774+mCiRvR2KBPJIQAGUR6vYJwlIoC0E&#x000A;CK3hhnrxxRefr76VVlopPn229J5ArddnKHt9mh0NcwRv0IwZM+KpJFfgJnyo&#x000A;4XbN9qMKxxP6dtFFF0XhedRRR4UDDjgg3HjjjeHxxx8P+++/f3jhhRfiZw89&#x000A;9FC49tprw4gRI6qAxTFKQAI9IKAA6gF0m5SABDpL4KmnngpnnXVWWH755cOy&#x000A;yy4b9wEtuuiiYbHFFou/p8Jxu+22W3z6bOk+gVqvD3u1CHnjfT7dLoTBJW8Q&#x000A;4oeb9PHjx3e7G6Vuj+QHCBv29yyxxBJxrFdffXVMioD3LxU8Q1tttVX8/lok&#x000A;IAEJdIKAAqgTVK1TAhLoKYHnnnsusL+Af6+//vro6Xn00UdjKuUDDzywLyEC&#x000A;T5zXWGONsNxyy/W0v1VsvNbrgwDB+9LLgjeIPkybNi12AyFGvxRC7bPK3Llz&#x000A;ww033BBefPHFmPTgzjvvDEsttVRYffXVYyM8qNh+++1NTtI+5NYkAQnUIaAA&#x000A;clpIQAKlJXDrrbeGO+64IxxzzDFxw/uxxx4b9tprrzheslCx38NUu901f568&#x000A;Pv2NHKGM8FEItX9uIHy23nrrGHZIFjgED+XVV1+NqbAnTZoURRFpzy0SkIAE&#x000A;OkVAAdQpstYrAQn0lACpdNlIT9gbyRCeeOKJuL9gn332iR4gbrjGjRvXF4rT&#x000A;085WpPE8en0GQk9/8QilbHF6hIY+URE5CCDSYSfxk2p98803w7bbbhuuvPJK&#x000A;BdDQUVuDBCQwAAEFkNNDAhIoJYFzzz03PPDAAzHEjSf52223XdxrcNBBB/WN&#x000A;96WXXlIAdcH6RfD6DISh9iWqZoxrfdIggPgu7rTTTjH0lJA4Ch5Z9uedeeaZ&#x000A;4fbbb1cAtY7YMyUggQYIKIAagOQhEpBAsQg89thj0bvD+35IgoAAwgtEdql7&#x000A;7713nsEQJrfaaqsVa4AF6u0FF1wQvSjpvT552OvTKr5aIWTGuOZJphA4kh6w&#x000A;9ycrgPDKkopcAdQ8V8+QgASaI6AAao6XR0tAAhKQQAMEZs6cGTN7sZ+G0ssM&#x000A;bw10t+FDat8fRFgcN+3tfllrwx0q4IF4epZZZpm6PR/obwUcql2WgARySkAB&#x000A;lFPD2C0JSEACRSUwefLkmEQgeX3wnJRNINRmjGN8559/vu8PKuqktd8SkECl&#x000A;CCiAKmVuBysBCUigcwQQBYcddlif14ckFIifMr9UlPcFIfbmzJkTx8nvhxxy&#x000A;SOcgW7MEJCABCQyZgAJoyAitQAISkIAEeIkoN/+UUaNGxReJls3r05+VCfdj&#x000A;PxAv9aSQXp2wOJIlWCQgAQlIIH8EFED5s4k9koAEJFAYAuzxweuD94eC9wMh&#x000A;VGavT3/GIW0277fBG0QxSUJhprEdlYAEKkZAAVQxgztcCUhAAu0ggNcD4cNN&#x000A;PwWvD+FueD+qXNj3hABkHxQFIYg3bPz48VXG4tglIAEJ5IqAAihX5rAzEpCA&#x000A;BPJNgBv8lOSAng4bNix6OlL4W757373e1SZJMCyue+xtSQISkMBgBBRAgxHy&#x000A;7xKQgAQkEAlk3+nD//Fq4N2oYrhbo1MCrxgC0bC4Rol5nAQkIIHOE1AAdZ6x&#x000A;LUhAAhIoLAFC3GbNmhXD29I+H97pg/Bxk39jZq0XFkfK7KokiWiMkkdJQAIS&#x000A;6B4BBVD3WNuSBIZMYIEFFhhyHVYggVYJsM+HUDc2+luaJ4CAhN2MGTOaP9kz&#x000A;JNBlAnPnzu1yizYnge4RUAB1j7UtSWDIBBBALkpDxmgFTRAgfCtt6Oc0BNDE&#x000A;iRObqMFDIVBv7xSCaPTo0QKSQO4IuNbkziR2qM0EFEBtBmp1EugkARelTtK1&#x000A;7v4IcPOOEGIPEIWbdkK4qp7xrdEZ496pRkl5XF4IuNbkxRL2o1MEFECdImu9&#x000A;EugAARelDkC1yoYJ8M4fQrjYE0Thd174aRKE+gjhxQti+Zfi3qmGp5oH9piA&#x000A;a02PDWDzHSegAOo4YhuQQPsIuCi1j6U1tU6AMDhu7Cm+52Z+jnjMeEcSiSMo&#x000A;7p1qfa55Zm8IuNb0hrutdo+AAqh7rG1JAkMm4KI0ZIRW0CYCvAgVD9C0adNi&#x000A;jYTDsTeoymFxMEEYkjkPEUSBCeGDesnaNPGspisEXGu6gtlGekhAAdRD+DYt&#x000A;gWYJuCg1S8zjO02g9j03iCJu+qu0uf/qq6+OacFTqBvMx44dGz+rEodOzzXr&#x000A;7x4B15rusbal3hBQAPWGu61KoCUCLkotYfOkDhPA28HNfgqLoznC5A455JDS&#x000A;ej4YM8kNGDeeH8qwYcPiu30Yu8Knw5PO6jtKwLWmo3itPAcEFEA5MIJdkECj&#x000A;BFyUGiXlcb0ggBDg5j9liyvj/qB6YW7s8SHMDe+XoW69mHm22W4CrjXtJmp9&#x000A;eSOgAMqbReyPBAYg4KLk9CgCAULBEEJpf1AZ0mbXJjbADmR1Q/jg9bFIoEwE&#x000A;XGvKZE3HUo+AAsh5IYECEXBRKpCx7GpMBoBASGmzEQqkzS5aeBihfYS6pcQG&#x000A;48ePN8zN+V1qAq41pTavgwshKICcBhIoEAEXpQIZy672EUA84BGaM2dODBFD&#x000A;FJEoIe8FAUc667THx8QGebeY/WsXAdeadpG0nrwSUADl1TL2SwJ1CLgoOS2K&#x000A;SgDvCcIn7Q/Kc1jc9OnTo/BJWd3WXXfd6AGqcorvos47+90aAdea1rh5VnEI&#x000A;KICKYyt7KoHgouQkKDoBRAVCaMaMGXEoiIrzzz8/F2FxiLQU7kbfyOqG54r+&#x000A;WiRQJQKuNVWydjXHqgCqpt0ddUEJuCgV1HB2ez4C2bA4/tjrtNl4fbbYYou+&#x000A;fT6k8KZPZnVz8laRgGtNFa1erTErgKplb0dbcAIuSgU3oN2fh0C9sDhEB0kG&#x000A;ull4mSshb/SHzG78v2iJGrrJy7bKT8C1pvw2rvoIFUBVnwGOv1AEXJQKZS47&#x000A;2yCBemFxJEnoxp6byZMn94W4IbwQPxYJVJ2Aa03VZ0D5x68AKr+NHWGJCLgo&#x000A;lciYDmU+AogPPEApbTYvFkUIdcobM2HChD7BQ3pu9/o4KSXwfwRca5wJZSeg&#x000A;ACq7hR1fqQi4KJXKnA6mDgHC0NgfxA9psynt3h9EG+PGjYtZ3kh0QFuILYsE&#x000A;JKAAcg5Ug4ACqBp2dpQlIaAAKokhHcagBHj3DsInpc0mGQFCZaj7g0h2gOeH&#x000A;fxE/iKAxY8YM2h8PkECVCLjWVMna1RyrAqiadnfUBSXgolRQw9ntlgkgUBBC&#x000A;06ZNi3WwL6jV/UGIKcLc8ADxbh/qNstby6bxxBITcK0psXEdWiSgAHIiSKBA&#x000A;BFyUCmQsu9pWAvX2B7FvZzABg9i5+uqro4jCq0QZO3Zs3Psz2LltHYCVSaBA&#x000A;BFxrCmQsu9oSAQVQS9g8SQK9IeCi1BvutpoPAml/EC8rpSBg0v6g2h5yLBne&#x000A;CJvjd8qoUaPi8e73yYc97UV+CbjW5Nc29qw9BBRA7eFoLRLoCgEXpa5gtpGc&#x000A;E8CTg4hJYXHs4cEbRHgcfyPULSt8eLcPoW877rhjzkdm9ySQDwKuNfmwg73o&#x000A;HAEFUOfYWrME2k7ARantSK2wwASmTp0ahU1Km40AYl9PKggfPD7deJ9QgTHa&#x000A;dQnMR8C1xklRdgIKoLJb2PGVioCLUqnM6WDaQKA2LI4qyRSHMDK7WxsAW0Ul&#x000A;CbjWVNLslRq0AqhS5nawRSfgolR0C9r/ThEg9I3EBoTGderFqZ3qu/VKIG8E&#x000A;XGvyZhH7024CCqB2E7U+CXSQgItSB+FatQQkIAEJRAKuNU6EshNQAJXdwo6v&#x000A;VARclEplTgcjAQlIIJcEXGtyaRY71UYCCqA2wrQqCXSagItSpwlbvwQkIAEJ&#x000A;uNY4B8pOQAFUdgs7vlIRcFEqlTkdjAQkIIFcEnCtyaVZ7FQbCSiA2gjTqiTQ&#x000A;aQIuSp0mbP0SkIAEJOBa4xwoOwEFUNkt7PhKRcBFqVTmdDASkIAEcknAtSaX&#x000A;ZrFTbSSgAGojTKuSQKcJuCh1mrD1S0ACEpCAa41zoOwEFEBlt7DjKxUBF6VS&#x000A;mdPBSEACEsglAdeaXJrFTrWRgAKojTCtSgKdJuCi1GnC1i8BCUhAAq41zoGy&#x000A;E1AAld3Cjq9UBFyUSmVOByMBCUgglwRca3JpFjvVRgIKoDbCtCoJdJqAi1Kn&#x000A;CVu/BCQgAQm41jgHyk5AAVR2Czu+UhFwUSqVOR2MBCQggVwScK3JpVnsVBsJ&#x000A;KIDaCNOqJNBpAi5KnSZs/RKQgAQk4FrjHCg7AQVQ2S3s+EpFwEWpVOZ0MBKQ&#x000A;gARyScC1JpdmsVNtJKAAaiNMq5JApwm4KHWasPVLQAISkIBrjXOg7AQUQGW3&#x000A;sOMrFQEXpVKZ08FIQAISyCUB15pcmsVOtZGAAqiNMK1KAp0m4KLUacLWLwEJ&#x000A;SEACrjXOgbITUACV3cKOr1QEXJRKZU4HIwEJSCCXBFxrcmkWO9VGAgqgNsK0&#x000A;Kgl0moCLUqcJW78EJCABCbjWOAfKTkABVHYLO75SEXBRKpU5HYwEJCCBXBJw&#x000A;rcmlWexUGwkogNoI06ok0G4C++23X7jwwgvDpEmTwiGHHBLSojR58uRw1FFH&#x000A;hT333DOcc8457W7W+iQgAQlIoEIEXGsqZGyHGgkogJwIEsgxgeeffz4st9xy&#x000A;YeGFFw5LLLFEePbZZ8OIESPCSy+9FF5//fXwzDPPhGWWWSbHI7BrEpCABCSQ&#x000A;dwKuNXm3kP1rNwEFULuJWp8E2kzg6KOPDqeeemp49dVX+2pedNFFw+GHHx5O&#x000A;OumkNrdmdRKQgAQkUEUCrjVVtHp1x6wAqq7tHXlBCPBkbuTIkeGVV17p6/Fi&#x000A;iy0Wnn76ab0/BbGh3ZSABCSQdwKuNXm3kP1rJwEFUDtpWpcEOkQg+2RO70+H&#x000A;IFutBCQggYoTcK2p+ASo0PAVQBUytkMtLoHskzm9P8W1oz2XgAQkkGcCrjV5&#x000A;to59aycBBVA7aVpXpQlMmzYtjBo1KowePbojHHgyd8opp4Qjjjiio3t/GMdm&#x000A;m23WkTFYqQQkIAEJtEZg9uzZYcaMGR2/PrPWfOc73wm77LJLIDtcKp1c31oj&#x000A;4lkSaJ2AAqh1dp7ZRQJc+C+44IIoLqZPn97X8m233db3O59zXCpjxowJw4cP&#x000A;jz/8TkmfDRs2rO+zRoZB3XPmzAkzZ86c54f2sv3pr67Ubn9/b7Qezl9nnXVi&#x000A;Jrh6ZfPNN5/n49r/88c0Bn5P/LKfZStI/YY7P1mWrYqktIjTTjPjzvaLlOD0&#x000A;xSIBCUhgMAJc344//vh47RuopOvgYNfr2utq9rqY6q93feThUrbUrlm118NG&#x000A;ro+1badr9UDtZK/9g7Gr9/fa9aDeugDLWbNm1a2+3rgGY9FfP+uxrz02ay+O&#x000A;Hz9+vOtHK4Yv2TkKoJIZtKzDOe644+ICluey7rrrxhv6/i76ee57tm8s3LUL&#x000A;dTN9r7cgNbKQN9PG+eefH/bee+9mTvFYCUigogSKsH40apqhXp8baae/B4Tp&#x000A;QWAjdeT5GNePPFune31TAHWPtS0NgUBawBAZO+64Y19N2Sc7tU/t0hOl7M13&#x000A;1uPRjFChXW7s63lC6nlZaoda+3Sr9u+NPMVK5wxUV9YjxvG1/+ezeh6xek8N&#x000A;OTa1lf5NT0izXpxmzZpdXJsZN+1MmTIlCsxbb701NMK92b55vAQkUD4Caf3g&#x000A;yf9AD07SdXCw63XtdbXeA556D5FqvUK1193a62Ej18fatuv1vZ5HayjXz/4i&#x000A;IbLrwkBRFvXGNRiL/mZlIw/Xkr3SQ9R///vfeoDK9zVvekQKoKaReUIvCKQF&#x000A;bOLEiYHfLfklUG9BamQhb2RELNrcWCiAGqHlMRKQAARcP5wHEHD9cB5kCSiA&#x000A;nA+FIOACVggzdbyTLmAdR2wDEigdAdeP0pm0pQG5frSErbQnKYBKa9pyDcwF&#x000A;rFz2bHU0LmCtkvM8CVSXgOtHdW2fHbnrh/NAD5BzoHAEXMAKZ7KOdNgFrCNY&#x000A;rVQCpSbg+lFq8zY8uEMPPTRMnjw5nHbaaYHfLdUmoAeo2vYvzOhdwApjqo52&#x000A;dJVVVompbO++++6m0ph3tFNWLgEJ5JqA60euzdO1zjkPuoa6EA0pgAphJjtJ&#x000A;5rerr746/PSnP50nC5xkqkVggQUWiAOeO3dutQbuaCUggZYJeOPbMrpSneg8&#x000A;KJU5hzwYBdCQEVpBNwgY+tQNyvlvQwGUfxvZQwnkjQDp8ydMmBB4gfLpp5+e&#x000A;t+7Zny4RSPOAdOj8bqk2AQVQte1fmNErgApjqo52VAHUUbxWLoFSEuA9MFts&#x000A;sUXgPTz13o1WykE7qPkIOA+cFFkCCiDnQyEIKIAKYaaOd1IB1HHENiCB0hGY&#x000A;OnVqGDdunAKodJZtbkAKoOZ4lf1oBVDZLVyS8Zm9pSSGHOIwFEBDBOjpEqgg&#x000A;Afd+VNDodYasAHIe6AFyDhSOgAtY4UzWkQ7rCewIViuVQKkJuH6U2rwNDy7N&#x000A;A/eCNYys1AfqASq1ecszOBew8thyKCNRAA2FnudKoJoE9t5773DBBRf4/pdq&#x000A;mr9v1N5HVHwC1AxfAeR8KAQBs7cUwkwd72QSQKZD7zhqG5BAaQg08+DkjTfe&#x000A;iGn2F1544b7x//vf/w6E3w4fPrxpJq+88kpYbLHF5jvvwQcfDG9729tiO089&#x000A;9VQYNWpUw3X/7ne/C295y1vC6quv3vA53Tzwz3/+c3jppZfC+973vrrNwuSP&#x000A;f/xj2HjjjcOCCy44pK49//zz8fxllllm0HpSKP3EiRMDYshSbQIKoGrbvzCj&#x000A;N3a3MKbqaEd9gtdRvFYugVISaEYAIUxWW221cNNNN4Vtt9028uAB3EknnRRm&#x000A;zJgRFl988fgZN96vvfZaWHLJJcNFF10UP+PcDTbYIAoebuyffPLJ8LnPfS78&#x000A;6le/Cptuuuk8bHfYYYcoEHbffffwnve8J/z1r38N7373uwfl/5///Cess846&#x000A;Yc011wwkdxiqgBi0wQYOYJxvf/vb+47cddddwx/+8Idw3333hSWWWKLv8+ee&#x000A;ey78/e9/DzfccEM44ogjwu233x7WWmutKCzT/s7a5m699dYoEBdddNH4g3ii&#x000A;LLLIInHsX/3qV8MLL7wwX1v1ut3MPGhg2B5ScAIKoIIbsCrdVwBVxdIDj1MB&#x000A;5DyQgASaJYC3ZPbs2eHRRx8No0ePHvD0adOmhc9+9rPz3FBffPHFAS/QQQcd&#x000A;1Hcux/3lL38J+++/f/jhD38Yb8yPPPLIMH369PjSbkQBe00+/OEPh1/84hfh&#x000A;ne98Z9+5eJg+/vGPh0mTJkXPxZ577hnTcyMILrnkkvC9732vrteICl5++eWw&#x000A;0UYbRdF06aWX9lwAwQFhwbjXXXfdOMaDDz44XHbZZeGBBx6InqpUUiRHrQEY&#x000A;x6c//em6doEj4uhPf/pT2GqrraLnCBv+4Ac/CA8//HA4+eSToxAdOXJkvyIq&#x000A;VawAavabU+7jFUDltm9pRsfFdb311gtjxowJd999d2nG5UCaI8BLDA877DBf&#x000A;aNgcNo+WQKUJNJM98uyzz457hRA1iBu8LKw/eGiOOeaYeThy440HA88Q3om1&#x000A;1147XHHFFdF7hGDaa6+9wiabbBKFwEILLRSOPvroMGzYsPj7CSecENcyvB94&#x000A;dL72ta9FEYVQ23fffcN73/ve2Narr74aw8k4rxUBxPl4SGgz1ZHqzX7+r3/9&#x000A;K7a96qqrNjxX8Ojg6UGY/OxnP4tjHTFiRBRAhCkjWlL4X/LeMG5+UkFU8mBr&#x000A;ueWWC//4xz/CL3/5y7DTTjtFz1q2PPTQQ7F+vGzLLrtsFH9PPPFE9CQ1WlZZ&#x000A;ZZUwc+bMyJ17CUu1CSiAqm3/Qo2+mUWsUAOzsw0T0BPYMCoPlIAE/h+BRtcO&#x000A;BA032XhmEAd77LFHuP/+++MN89ixY8P48ePDf//3f4d3vOMdsWbC0QhjQzDh&#x000A;yfn85z8fTj311OjJQUx88pOfDJ/5zGfm84RwLl6fww8/PHpIJkyYEAj1QugQ&#x000A;Ypf6+/vf/z7uk6HQDuIMkVXrAbryyivDAQccEEPFdtlll9hHPCJ4oPC6pIL3&#x000A;BIFT73M8Kuecc07Ycssto/eLf88999yw9NJLhxdffDGcccYZ4Stf+UqsCk8X&#x000A;+2nw+NBmtvz2t7/t82LRl8svvzz+mc8RHfT9nnvuif3kb1//+tfD8ccfH485&#x000A;//zzo/ftN7/5TfjgBz84T70IF87Fi4c4Ysx4hxBQN954Y9hmm22iyBuoNDoP&#x000A;/OJUg4ACqBp2LsUovXiVwoxDGoQCaEj4PFkClSOQoge4Wef3gcq9994bPvax&#x000A;j8WbbI798pe/HG655Zbw4x//OOAhwZvy7W9/O+CN+N///d94E064GkIH7wXe&#x000A;CX6uu+668Mgjj0TBgIcoJS3gxv6xxx6LXhG8HmSmwwPEjT3ebbxAJEXAo8QN&#x000A;P16g//qv/4qCDFGz/fbbh2984xvzCCD+j4D4yEc+Ej70oQ/FOr7zne/EpAo7&#x000A;77xz2GeffeIPQgGBgSer3ufsYyKcLIktxsd5Z555Zty/dNddd8U63nzzzfjZ&#x000A;r3/96/Dss89GDxB9YO/TscceGwUkY4MLBWH2k5/8JAqe7373u1HoEcJGSCDe&#x000A;Mgr9ocDw+uuvD5/61Keil+eOO+6ILBGJ/O2UU06Jggmxyd8ef/zxOGZEJ2Mj&#x000A;258CqHJf8ZYHrABqGZ0ndpuAAqjbxPPXngIofzaxRxLIM4Fmrhlf/OIXw1JL&#x000A;LRUTF+B9QQgR9pb2ABGahreGm208NSkEDrHAZn+8MyQ1IOSNH7w87IVh0z83&#x000A;7YTFIaIQOQgCbugRQIgXPCQpXIw+ILTwtLDPiKQMqWT3ACFE1lhjjSiIrrrq&#x000A;qphgAHGBWCHcjfNoF1GENwvPVUryUPv5gQceGIUKYo06ECV4d+jHBz7wgSgy&#x000A;CD8m1A0+aX8PQo3QMrxF8KEQAocAYuyIGcLXEWSExQ3mpcnOJVghuOBFZjn2&#x000A;CcGacDrEI+PFPq+//nr0mg1Ud+on9bMHyyIBBZBzoDAEBhNAuOmzccP8n0w9&#x000A;K6ywQtNj5MLLRbbZwoWYGOYNN9wwxkLnsZCR6F3veldfGEdtH3nSxsJHXPpQ&#x000A;CyEK8O8vU1FKh8qNQyNpTJu5mRlq3z1fAhIoPoF0zRhs/yiiAbGBGCGkDU8N&#x000A;ooAQNAQQ18Xa/SaIETxLiBdu0PGGEF6GGMFjlELbUja5LE1C4/AQpRA4PE2s&#x000A;cYgkRBEiA28NHpPsjX1WAJHOmWxwSXykm3zG8v73vz/2gaQK9IlCaBvH1/uc&#x000A;EDgECgxYRxk7oWUIDDxB6dxaAZQE1fe///14ThJAiB/+xjq6/vrrR0/YYEkb&#x000A;8OrgQSLsEGGXLSSWQDAmHq3sARrsHqL4s90RNENAAdQMLY/tKYGBLl4sClzY&#x000A;eQLFRlMKCxIXUUIReEJF4YabuG0u8MRDX3PNNXGx4X0MPDHjyRux34Q+fOlL&#x000A;Xwpf+MIXmhozT8UIW8guBk1V0IGDsylKUwrVLbbYIi6a2dSjhBMQg87YWdDh&#x000A;A6f+hBxiL6VhJSUpdSEcKXCkLUJDeKpK6EMqbBAm3SshEMluu+22W/jmN785&#x000A;6OgVQIMi8gAJSKCGQCM3vkl4cOrWW28dQ9C4nnNt6+9mGw9R2qODhwWP0Mor&#x000A;rxw9RCuuuGJcV7jecdO+0korRY8IXh7q5HqHsGL9IYwLAcLeGNYvxBDnfetb&#x000A;3wr/8z//EzO+8S/7cfgMjwweFbwgCB0SCBBCR1gaXiPCxPC6IOIQXz/60Y9i&#x000A;CB3/8qCp3ueIJrw27PWhIGYQPnhzEHmEvxFidtZZZ8UEEXi1tttuuz6PUlrz&#x000A;8K6wj+eZZ56JgoqHX/yfB4MkRRjoQVcSQKw/iWsyJWF2rDn8S+lPlA40+RuZ&#x000A;B355qkNAAVQdWxd+pANdvHg6x3sISIuZ0o2yeCFg0pM1ABC7zSJBrDM35ywS&#x000A;ZJy5+eab46KEgMJDQtwyG15JVdpMqfc0rJnz231sbYrS9PSwXjgC76Ug3rq2&#x000A;1IZgZP/+t7/9LYZ+sLASjgFrQkMIVeAJJjHrLFos0Kmw+LJok5KUxZTFn8Ws&#x000A;kaw8CqB2zxDrk0D5CTRz48sDI/a88OAMMUAoGOsFYWasGakcddRRUYwQGsZ6&#x000A;kX3ZaXaDPmFarE0IA0QB4Vx4dHhXDu8WwgOE1wmBgFhgHUrRBzwYQmikcuGF&#x000A;F8aQMjwqZF7jwRIPocaNGzePEZdffvlA/0iykArr4p133hkTD9Df2s/ZR5T2&#x000A;7fA36uAhGEIOQZXN3MbfWRtpmzWXULskgLjek5AA8Yf3CfaIFljWpsWuN/Oe&#x000A;fvrpyCT7Ilq8T0QJZNeiVgQQoX2zZs1qKB16+b8VjlAB5BwoDIGBFjGy9JAl&#x000A;B3Fz4oknxqdXPDX7xCc+ETeUZi+mDJjwA1z7uOVJdcqNOhddBBBP64jjZtHj&#x000A;Rn2gQpgdMco8maM09lgQMQAAIABJREFUK4D6S1FKvYgVPDAIinalKKU+FnI8&#x000A;YywgeLt4IgdbFh4WUjbqpsKiBRMW5IFSlLKZFQGEkGQRhy+LLxtjswUPE4KJ&#x000A;p62E2PHUkcWfhRIP3mBFATQYIf8uAQnUEsDLMmfOnL7wsv4Ice0n2xvXGc4h&#x000A;qxvv8KFwLeOaxfUSjwgChGs03mwerBH+ll7WybWQNYEHQckLPnny5Hk87tkQ&#x000A;ONpkDasXKowQY40hlDh5T7h+ch1NL2Xl///85z+j6KAPiDjCnLmmI7o4Fs9U&#x000A;WkPrfZ7e3cN48eBzPGIsFVJOsy6RlIEMdxTaoxBtgbhILz194403ouBL6y6h&#x000A;6AhB1uRmS3q4ycM1IhdSYf3CS1ebmnyg+n0PULP0y328Aqjc9i3V6AYSQIQN&#x000A;8IQLwYJbntAALraEvnHBxhWfFTMsPiw6/A3vBYsbF32y2PB/NnuyiA0kgAgD&#x000A;SJs+2dBK3DhhX9mnYfXSh/Lmakq9VKQIFOpMIoSncDw142lefylKCV2j36Q7&#x000A;ZYHkqSCLLulOa1OU4hEiJI3QDV7Qh8cHBggRFnN40SY8+FsKc6C/A6UoJT6b&#x000A;EIzkbUsCkz4QzpAWLhZ57EO4B8IHm3IzQftk/RmsKIAGI+TfJSCBWgKN3PgS&#x000A;fsWeGx5+ZW/8EQuEbrEvhSxx7FEh3C1buMHnWp/OQ8hwbUMIpP072XfwcC7X&#x000A;YX4QLHiC8Ib3t1eyGxZNSRDSe3a60eZgbSDk2CfF3h/WpWzBy4bXjciFRksj&#x000A;86DRujyu+AQUQMW3YWVG0J8A4mVsLC48DeKpHQKEp2Y8OULI8GQLlzxudI4j&#x000A;Fpr4ao7FE0L6T27MeWKHKCIOmwWungcjwcbjgeghTI5wCcK9EAs8dUsCaL/9&#x000A;9ouLZW36UAQBoqVeKlLivAlDIJwAMUL/ebJIvHi9FKVsguVJHYVx/fznP4+L&#x000A;NWMlm09titIkEBkjYolNuggmsv989KMfjU8+GQ9CjNAOuBEmSKlNUQo3OHMs&#x000A;/AjhYN8UhTSs8OGpH+Iz+5bwtFGXcAyyEuG5ayQ0gnoVQJX5ujtQCbSNgDe+&#x000A;g6PkgRzpvhu9Fg9eY/6O4N1FeOJ4WMnvlmoTUABV2/6FGn1/AojwKVJjspeE&#x000A;MKokYvBy4Anh5pwnbWTwSfuD8FCwWZR9J1z4CY9gXwwXRsQGmW4QBvXCsghH&#x000A;IPyB/S8IDdz+6UlfNgSOTHD81EsfSkhbvRSlCBGEEaIAAcb+JOrvL0UpceRs&#x000A;TuXFe4wfsYfASOlGa1OUpj1AsEEc4fXCA9RK0gYSSlBSSlJCJPDEwYKnqPQZ&#x000A;LxMx4YRCIFT5neMJs8A7RJgEggv7ESfP59gJcZTdN5QmqgKoUF9ZOyuBXBDY&#x000A;cccdA17qRt4Vk4sO96AThLXxYI6w8LIW3k/EXiceHPK7pdoEFEDVtn+hRl9P&#x000A;ABH7zDsO8JqQ8GD11VePN9XcRPMkC4FQL7Y67VHh5p/zCckihnqvvfaK+1jY&#x000A;3Mkmz3rvFSDMDWFDZpvatKhZAcSeIoRAf+lD+0tRShgGniA8Pgg2vCfEOddL&#x000A;UUo2IMLaUurSWgFUuycpmwSBGwLOI2td9h0O/U2KgVKUso8KQZd41NsDRP8J&#x000A;J8GOxK4TLsJxiFQ29rIfKQkqxFHtm8D1ABXq62pnJZAbAt74hnjtJQEN+5hq&#x000A;98TmxlAd7ojzoMOAC1a9AqhgBqtyd+sJIOKuiZvmhvrss8+OIgivB94cNqZy&#x000A;c413IStk8EQgdBAAxBfz1IswrxTGxcZVQgEQVYRx1ZYkIggJ44ki/SL0i304&#x000A;ZOdJIXB4P1hs6qUPpY7aVKTsW2LPDn3nKRzhdYTPEXvO2OqlKCXEDiFGsgL2&#x000A;0hB2R72ILkLjagVQEm/sMyK8DhaIKFKOIoIGikHvL0UpHjHGypM1PGMUhCdM&#x000A;apMgZFnSdgqvIz0s7LJpuevNdT1AVb4COHYJtEagije+eOh5jw9rxFvf+tb4&#x000A;QJCHXdl9na3RLO5Zrh/FtV0neq4A6gRV6+wIgYGSIBBahRcBUYPg4OYbQYM3&#x000A;J5va8/rrr48Z33ifAXtmCLtKhfSYfE4mIELiCNVKWW1qB8RmWN4VkZIMsEGT&#x000A;hYWN/GQFIpSN8LX+0oeSCCC9NI668fSwZ4e9RIwhFcQNyQ8QK/VSlNIe/UAo&#x000A;ZUsKaasVQCmjTgoFgRvx8Qif2hfu1TNivRSlZONhnCkcsBEBhOeOJAj8kBQC&#x000A;LxyhgiRSQMT29xJaF7COfLWsVAKlJlBFAYRByYpKaDTrAXs8ediVpyQH3Z50&#x000A;rh/dJp7v9hRA+baPvcsQ6E8AsZ+FTDBkSuNf9vCwl4eCB4ZscGy254WeiA4W&#x000A;AFJBk7kHscEmfsKx8BSR+Q3BwU05XprsTX2tMUhhTduEE+C1SWEFiKKRI0f2&#x000A;eTP6Sx/aX4pSPDh4akhSwDsYKIOlKCUZAV4uvD54vgjtS+KtNkVpSkWdxkOm&#x000A;HfbtcE6zhfA7vGS8LyJ7Ph4g9lbVhrHhsTvvvPPinixC4ojNT4WkCnvuuWfM&#x000A;Glf7Erx0jAtYsxbyeAlIoIoCiGstaxsPx8gy9+1vfztm4xzsZaRlni2uH2W2&#x000A;bvNjUwA1z8wzekSgngDi5p30z+xBQeCkQngV+1v4YQ8NAodFMPuyOrwf7PvJ&#x000A;enkQEdnUpXhYBgvL6gaOPKYoRfzgNUIs1npsEKO8RRxvWCq8gA9bsLcKgVOP&#x000A;K0kU2BeEcK1X8BDhDUNc8btFAhKQwGAEqiiAeKBEIh/Co8n+yQtLiShABPQy&#x000A;3fZgturk39M8cP3oJOXi1K0AKo6tKt3TlM2MNNbpJWxVAlKFFKWN2LOKNzKN&#x000A;cPEYCUigfwIp/XHVsn+lkG8SzPCONsKM08uqqzhfXD+qaPX+x6wAcj4UgkDV&#x000A;XddVSFHayER0AWuEksdIQAJZAlV7DxB7LMmGSkQDniAS+7BHlfBwQozxALEH&#x000A;lnBoPOn1sp2WcQa5fpTRqq2PSQHUOjvP7CKBqgugLqLOdVMuYLk2j52TQC4J&#x000A;VEkAEdp91llnxcyoFPaSPvPMMzE5EJlKefk3+18JW37ttdfiy67Zw1qFkuZB&#x000A;7f7TKozdMc5PQAHkrCgEAQVQIczU8U66gHUcsQ1IoHQEqiSA6hmPvZe8coAs&#x000A;p4ig9ELw0hl6kAFVfR5Uzd6DjVcBNBgh/54LAgqgXJih551wAeu5CeyABApH&#x000A;gJdSE0ZMaNjw4cML1/+hdJgsoHh92A9EMgRem0D20gsvvDCMHTt2KFUX7lzX&#x000A;j8KZrKMdVgB1FK+Vt4uAAqhdJItdjwtYse1n7yXQCwIDvUOuF/3pRptkSJ00&#x000A;aVK46qqrws9+9rO+l06zN4hwOAQQ775DHFalVFkIV8XGzYxTAdQMLY/tGQEF&#x000A;UM/Q56phBVCuzGFnJFAIAlUSQOwBQvjwygc8PKutttp8NuIdd7w4/NJLL417&#x000A;hKpSqjQPqmLToYxTATQUep7bNQIKoK6hznVDLmC5No+dk0AuCXjdyKVZut4p&#x000A;50HXkee6QQVQrs1j5xIBBZBzAQJjxowJM2bMCHfffXf83SIBCUhgMALe+A5G&#x000A;qBp/dx5Uw86NjlIB1Cgpj+spAQVQT/HnpnFD4HJjCjsigcIQ8Ma3MKbqaEed&#x000A;Bx3FW7jKFUCFM1k1O6wAqqbda0etAHIeSEACzRLwxrdZYuU8ngyAc+bMqWQ2&#x000A;wHJadGijUgANjZ9nd4mAAqhLoHPejAIo5wayexLIIQEFUA6N0oMuuX70AHqO&#x000A;m1QA5dg4du3/J6AAcjZAwAXMeSABCTRLQAHULLFyHu/6UU67tjoqBVCr5Dyv&#x000A;qwQUQF3FndvGXMByaxo7JoHcEjB5Sm5N09WOuX50FXfuG1MA5d5EdhACCiDn&#x000A;AQT23nvvcMEFF4Tzzz8//m6RgAQkMBgBb3wHI1SNvzsPqmHnRkepAGqUlMf1&#x000A;lIACqKf4c9P4cccdF44//vgwceLEwO8WCUhAAoMR8MZ3MELV+Puhhx4aJk+e&#x000A;HE477bTA75ZqE1AAVdv+hRn9zJkzwyqrrBL7O3Xq1EA2F8qwYcMGfB/MtGnT&#x000A;wuzZs8P06dP7/qUufmrL6NGjAz+pEDaR2kmf8f9W3j/TX5tDMcBgfRk1atQ8&#x000A;4xlKW/2dy7hmzZoV/5wdY2I+1Da5cckWhDA/CqChkvV8CVSHQBJAeI2z1/h2&#x000A;E6hdQ4Za/2abbTZgFY1cf2uvoanC/j4fap85P6232boGWgPrrWW1/atdU7Jt&#x000A;NLLeJLvTD9ePdli5+HUogIpvw0qMID35H2ywSbRwk2wpLwGf4JXXto5MAu0m&#x000A;sOOOO4arr7663dVaX0EJuH4U1HBt7rYCqM1Ara4zBHjCM2XKlHm8ObTE5zNm&#x000A;zOi30XXXXTd6cXialJ4y9ec5qX1qVe8pViNPmup1pl1PBlP4V2pjIKGXfTrY&#x000A;GauEkPUyZbkO5p1qtD/1xkfdPMmt9c41WqfHSUAC1SLAtZD1o9Ol3Z5+IhgG&#x000A;Ko1cf7PX0Oz60cmHhPWiJwZaA+utq7X9q11Tsm00st4k27Cuu350+ptQjPoV&#x000A;QMWwk71skEASLfUuwA1WkevDSOc6d+7cXPfRzklAAhKQQGcIIBZaffjj+tEZ&#x000A;m1hrMQkogIppN3tdUQIuYBU1vMOWgAQkMEQCrh9DBOjppSKgACqVOR1M2Qm4&#x000A;gJXdwo5PAhKQQGcIuH50hqu1FpOAAqiYdrPXFSXgAlZRwztsCUhAAkMk4Pox&#x000A;RICeXioCCqBSmdPBlJ2AC1jZLez4JCABCXSGgOtHZ7haazEJKICKaTd7XVEC&#x000A;LmAVNbzDloAEJDBEAq4fQwTo6aUioAAqlTkdTNkJuICV3cKOTwISkEBnCLh+&#x000A;dIartRaTgAKomHaz1xUl4AJWUcM7bAlIQAJDJOD6MUSAnl4qAgqgUpnTwZSd&#x000A;gAtY2S3s+CQgAQl0hoDrR2e4WmsxCSiAimk3e11RAi5gFTW8w5aABCQwRAKu&#x000A;H0ME6OmlIqAAKpU5HUzZCbiAld3Cjk8CEpBAZwi4fnSGq7UWk4ACqJh2s9cV&#x000A;JeACVlHDO2wJSEACQyTg+jFEgJ5eKgIKoFKZ08GUnUC7F7AXX3wxLLnkkv1i&#x000A;e/3118PCCy/cMNYXXnghLLLIImGxxRZr+Jy8HPj888+HJZZYYp7xzpkzJwwb&#x000A;NiwvXbQfEpCABFom0O71o+WOeKIEckBAAZQDI9gFCTRKoJUF7NVXXw0XXXRR&#x000A;eO6552IzK664YvjUpz4VZs2aFf/9xS9+ERZffPGw4IILziNcfvvb34Yf/vCH&#x000A;4eSTTw4/+clPolBCEPHva6+9Fnbcccd5xNPcuXPDzjvvHL785S+HjTbaqNEh&#x000A;BYTHpz/96fDvf/87XHfddeEtb3nLPOfS5uGHHx5/Ro8eHc4555zwt7/9LSy9&#x000A;9NLh5Zdfjn2GC0Jl//33D/fcc0+YNm1aWG655WI/E7OVV145PPTQQ2HRRReN&#x000A;9fP3j3/84/HvtLHNNtvE8b7zne+Mf0ccvvvd7w73339/GD58eMPj8UAJSEAC&#x000A;eSTQyvqRx3HYJwm0g4ACqB0UrUMCXSLQygLGjfzWW28djj322OidOfvss8MV&#x000A;V1wRBcXll1/e1/Ovfe1r4Qtf+EL8P56PD3/4w+GnP/1pFCTXX399FBqInx//&#x000A;+MfhT3/6UxQZSy21VN/5CCYEFcJklVVWmYfIv/71r/DNb34zfPSjH53n85kz&#x000A;Z4axY8eG448/PgqRr3zlK+Hqq68O73nPe+Y57vbbbw+f+cxnolh761vfGgUQ&#x000A;511yySVRoJx44olxTB/84AfDgw8+GP7+97+HSZMmhW233TZMnz49HHjggbH/&#x000A;nIdHCyacyzkLLbRQ+NWvfhVFWCr8jsDLfsbf4LDuuut2ydo2IwEJSKB9BFpZ&#x000A;P9rXujVJIF8EFED5soe9kcCABFpZwF555ZUogH75y19GAXTAAQeED33oQ1Fs&#x000A;XHXVVWGDDTaIQuG73/1uWGONNaL4+eQnPxn222+/sMsuu8zTH7w148aNi4Jl&#x000A;k0026fsbn3/kIx8JkydPjuIHjwrljTfeCG+++Wb0vCCaECKUl156KQopRNe5&#x000A;554b/vKXv4Q999wzPProo1F4HHXUUWHvvfcOyyyzzDwCC2/WhhtuGAUOXqnv&#x000A;fe978e8/+tGPwjrrrBNGjhwZ///AAw+E//7v/47jpG7azYoy+jdhwoQwZcqU&#x000A;MHv27LDllltGMYh4oi5E4g477BA9QvT1oIMOquudcrpKQAISKAqBVtaPoozN&#x000A;fkqgWQIKoGaJebwEekiglQUMb8cHPvCBGJ627LLLhm9961vhc5/7XBQ3hIyt&#x000A;vfbaMezrS1/6UhzZz3/+8xget88++8QQMYQKQuTJJ5+Mwoi/nXXWWeETn/hE&#x000A;n5hBvCAevv/970fBkwphZwiPW265Jf6d9vid4/E2HXLIIbHuO++8Mxx66KEB&#x000A;Tw9ha9R/yimnhDPPPDN6erIFoYKXaNNNN41ChbEwRsQK9SDyEHyrrrpqeOKJ&#x000A;J8K73vWu8PTTT/d5e6grK4Do15///Ocolo477rgovFZfffVw7bXXRq8Tx371&#x000A;q1+NgqqZ/VA9nCY2LQEJSGA+Aq2sH2KUQFkJKIDKalnHVUoCrSxg3MA//PDD&#x000A;YcaMGeHmm28ORx55ZBQ8zz77bBRB3PwjKrIeHeCddtpp4T//+U8UJjfccEP8&#x000A;F4/JmDFjouhATOE1ok94TZZffvkYooaHhv1AeGFo54tf/GL0NCFCEEB4mPAM&#x000A;ITzuvvvuaCfC0/iduvkdAcL+GwrnbbbZZvF3xBNj+cMf/hC22mqr6HHaY489&#x000A;oujBa4SA4vdjjjkmCiC8QogWBBN7k9hjRMgbyRpuuummeUTR17/+9dj+Tjvt&#x000A;FAUVe4XwOMEAUUS43EAJI0o54RyUBCRQGgKtrB+lGbwDkUANAQWQU0ICBSLQ&#x000A;6gJ2xx13xJt3hMNnP/vZ8IMf/CCccMIJ4YILLogiBW8PnhL2BREGd+WVV4Zv&#x000A;fOMb4de//nW48MILYxgYIXHZkDS8Pe973/vivhsKAmHNNdeM51Mef/zxKDwI&#x000A;P5s6dWr45z//GQVQKggehAZjopCBjXC1I444IgqmlEgBsUQYH6KLfUyPPPJI&#x000A;3PdDu+wr4nPGlhVAeGzYi4QHC9H31FNPxX6MHz8+hv4hCklsgIiiffYJ8bcb&#x000A;b7wxeqcQhfUKAgqRZJGABCRQNAKtrh9FG6f9lUAjBBRAjVDyGAnkhEArCxje&#x000A;GMLbCF8jDI6CcHn7298e9/4gLp555pkYQoYgYj8PCQQQHogaxA+CAk9KyrxG&#x000A;GByCCIGRCgkTbrvttiiCkgeIZAaIHrLQ4XE6+OCD+46nHbwxqZAFDhFCaB0i&#x000A;jbayhb1LnP/YY49FTxTJCBBWiBjC5vBS4QEiox1eKIQMXivEHoKGcDsSN+y7&#x000A;777z1Mv+JDxMJFdA8MEYwbjFFlvE/uEBou3zzz/fELicfA/shgQk0DyBVtaP&#x000A;5lvxDAkUg4ACqBh2spcSiARaWcAQI3hOSFLAjT2hYHhjtttuuxjmxk3+X//6&#x000A;1xg6RqgXgofwL0TP0UcfHUPSSE7AZ4gIPC5rrbVW9Lq84x3vmEcAIU7wkNAm&#x000A;hQxyZ5xxRtxPw896660XP0+Z6RBS9QpiBDGTfQdPEkB4gAhN23jjjaPXB48R&#x000A;7ZA8AW8PAoixIYwIpSPcjSxvjIUQPeqh4PXBo4UQo794qxBMCK/ddtstZqwj&#x000A;UQJ9RcQhurKCzSkpAQlIoEgEWlk/ijQ++yqBZggogJqh5bES6DGBVhcwsq1t&#x000A;v/32cR/Q7rvvHhMZEOKW0mBnw9UYIoIAocR52XfgIB4IJcPLU1vwFq222mrz&#x000A;pYnGu4S4IpQOjxN7e1JmOhIuEPqWLXieNt988yiYkgAiZI0U2/SHcLYVVlgh&#x000A;rL/++uHzn/987A/eqz/+8Y/h1ltvjeKIfTzsAyIhAwIG7xB7kfBQIeAoeKzw&#x000A;OuFtouAlS+NNAg2vD6GBKWOcAqjHXwCbl4AEWibQ6vrRcoOeKIEcE1AA5dg4&#x000A;dk0CtQRaWcAQBAgFxASCh9A3sqchhEhigMcEDxB1p/CwJIDwsCAi+OFFqaSD&#x000A;JjMaGdiol5eJcj6FumkDz0s2Exx/Q8DgVcEbxItYEUB4aRBUI0aM6PMY0QdC&#x000A;zvBYJQ8QfWFvEskTEDm77rprFDhkmEPI8S4iRBFt8xmF8DX2NdE33kGE8MMD&#x000A;hAhL2e4mTpwYw+QIB6wn+P7xj39E8Ud/8ABddtlleoD8SkqgAwR44DBQghGu&#x000A;H81kYMTry0MXvNdFK3ikeSiUHS/Xvqw3vNUxtbJ+tNqW50kg7wQUQHm3kP2T&#x000A;QIZAKwsYXha8OXhAeLkpHhiEAyFxhHwhbHgh6ejRo/uSFCAISFNNZjQ8JoSL&#x000A;UTgfYZIKIWUp6UHty0RrDcd+IRInpBeRkpobAZLd68P4Xn755Zj+mpTWLPr0&#x000A;DQ8M7zHCm4Rou+aaa6KwqS2EqZHNDm8XIopxILYQZ6SxxouUwu4QPhdffHHM&#x000A;ZsdxiERShCePF+2mzHi0T8KFlLDBSSkBCTRHgAcm7AV87rnn4ok8CEnfR/7l&#x000A;WsIDC65HWeHCC5bx8J588snx3V8IJQQR/7L3j9DXrHjiu8xeR655KZFKIz1F&#x000A;ePDiY7zCJDshrDZbaJMHMfxwrTznnHPii5XTvkj6zPWBaxYPTO65556455CH&#x000A;RPQzXbt5SMO+Q0KKKfydayN/p41tttkmjpfkNBTEIddsEr9kvfGNjKn2mFbW&#x000A;j1ba8RwJFIGAAqgIVrKPEvh/BNq1gBFmhtDAe5IKe3+y4WiDPZUdqlEQMyz+&#x000A;9Urt35p9Alzb90bGUjv+lH2O/pn+eqjW9vyqE0hhpTyYwDuDF5qwWQRFCsWF&#x000A;EWGoPHyh4PngoQvhqgiS66+/Poojvo+8n4yXKyMystcxBBOCCmGSffkx9fHQ&#x000A;hAcZ7O/LFh528L4xXvDMNZZMkewJJIlLtvDwBw84Yo19igggzrvkkkuiQDnx&#x000A;xBPjmMhQSZp/XthMQhlCf3mIRLgu/ee89CCIczmH8Nrah0gIMgQe/2YLHEgC&#x000A;02xp1/rRbLseL4E8ElAA5dEq9kkC/RBwAXNqSEACRSSQ9v3hyUUAEf7Ky4cR&#x000A;G6S932CDDaJQwMOLVxnxQ+ZKsk3yvrJswVszbty4KFiy7y/jczzbvB8M8cOD&#x000A;EwoPMwjLxfOCaEKIUHjogZBCdJ177rkxDT9eaZK+IDwIASYxTDb9PwILbxaZ&#x000A;JhE4eKW+973vxfp4HxrvHhs5cmT8P+9Cw/PMOKmbdrOiLPtC5tmzZ4ctt9wy&#x000A;ikHEE3UhEnfYYYfoEaKvhCDX8041Oh9cPxol5XFVIKAAqoKVHWNpCLiAlcaU&#x000A;DkQClSKAB4iwV8LTCDsl3JTwWsQNIWNrr712DPtKe/QI3SVclb18hIghVBAi&#x000A;Tz75ZBRG/O2ss86KafOTmEG8IB4Itc3uQyTsDOHBi5T5O+3xO8fjbSK7JXUT&#x000A;dktYMJ4ewtao/5RTTokhuXh6sgWhgpeI/ZAIFcbCGBEr1IPI23rrreMLmZ94&#x000A;4omYTIWXOidvD3VlBRD9Il0/Yum4446LwossliSDwevEsWTmRFA1sx8q22fX&#x000A;j0p95RzsIAQUQE4RCRSIgAtYgYxlVyUggT4C3MA//PDDMSEJ6eqPPPLIKHh4&#x000A;PxgiiJt/REXWo8PJpOonEQnChGyO/MteP9LtIzoQU3iNuDbiNVl++eVjiBoe&#x000A;mvQ+MtphDySeJkQIAggPE54hhAcvZaYQnsbv1M3vCBD231A4j/eFURBPjIUX&#x000A;S5P0BY/THnvsEUVP9oXMZKJEAOEVQrQgmNibhBeHkDeSNdx0003ziCL2XdI+&#x000A;iV4QVOwVwuMEA0QRAqrVkFzXD7+QEvj/CSiAnA0SKBABF7ACGcuuSkAC8xDg&#x000A;PWTcvCMcSD/PS4pPOOGE+AJmRAreHjwl7AsiDO7KK6+M6fp5QTEZHAkDIyQu&#x000A;G5KGt4eEJuy7oSAQSNOfkrNkU/zz4mTegYYASgXBg9BICU7YB0m4Gu8XQzCl&#x000A;RAppTyCii31MvI+MfT+0y74iPmdsWQGEx4a9SHiwEH1kqyQMjhc+E/qHKCSx&#x000A;ASKK9tknxN9uvPHG6J1CFNYrCChEUrPF9aNZYh5fZgIKoDJb17GVjoALWOlM&#x000A;6oAkUAkCeGMIbyN8jTA4CsKFtPzs/WGPEMlPCCFDELGfhwQCCA9EDeIHQYEn&#x000A;JWVeIwwOQYTASIWECbzvCxGUPEAkM0D0kIUOj9PBBx/cdzztZN/vRRY4RAih&#x000A;dYi0bJZKTkovZOalz3iiSEaAsELEEDaHl4oQOjLa4YVCyOC1QuwhaAi3I3FD&#x000A;euVA6gj7k/AwkVwBwce1HsFISn/6hweItnk3mSFwlfjKOMgOE1AAdRiw1Uug&#x000A;nQQUQO2kaV0SkEC3CCBG8JyQpIAbe0LB8MbwPjDC3LjJ531khJER6oXgIfwL&#x000A;0cM7vAhJIzkBnyEi8ListdZa0evyjne8Yx4BhDjBQ0KbFDLI8Q4y9tPws956&#x000A;68XPU2a6lBq/lgViJL2PLP0tCSA8QISmbbzxxtHrg8eIdkiegLcHAcTYEEaE&#x000A;0hHuRpY3xkKIHvVQ8Prg0UKI0V/C5BBMCC/enUbGOtLw01dEHKKr1Rcyu350&#x000A;a7bbThEIKICKYCX7KIH/R8AFzKkgAQkUlQDZ1nhHF/uAeBEzwoMQt5QGOxuu&#x000A;xhjrvaCYzxEPhJLh5akteItWW221+dJE411CXBFKh8eJvT0pMx0JF7KvAKBO&#x000A;PE+bb755FEzpJaSErJFim3EQzrbCCiuE9ddfP75DjP7gveJlzbfeemsUR+zj&#x000A;YR8QCRkQMHiH2IuEhwoBR8FjhdcJbxMFLxn1ExqXBBpeH0IDEUIKoKLOfvud&#x000A;NwIKoLxZxP5IYAACCiCnhwQkUEQCCAKEAmICwUPoG9nTEEIkMcBjggeIa1wK&#x000A;D0sCCA8LIoIfXpRKOmgyo5GBjXp5nxjnU6ibNvC8ZDPB8TcEDF4VvEG8iBUB&#x000A;hJcGQTVixIg+jxF9IOQMj1XyANEX9iaRPAGRs+uuu0aBQ4Y5hBzvIkIU0Taf&#x000A;UQhfY18TfeMdRAg/PECIsJTtbuLEiTFMjnAunk4cAAAgAElEQVTAeoLvH//4&#x000A;RxRD9AcP0GWXXaYHqIhfAPucOwIKoNyZxA5JoH8CCiBnhwQkUEQCeFkIe8MD&#x000A;wstN8cAgHAiJI+QLYcMLSUePHt2XpABBQJpqMqPhMSFcjML5CJNUCClLSQ9q&#x000A;XyZay4r9QiROSC8iJTU3AiS714frLC+KJv01Ka0RNfQNDwzvMcKbhGi75ppr&#x000A;orCpLXhpyGaHtwsRxTgQW4gz0ljjRUphdwifiy++OGaz4zhEIinCET0U2k2Z&#x000A;8WifhAspYUOz88D1o1liHl9mAgqgMlvXsZWOgAtY6UzqgCRQWQKEmSE08J6k&#x000A;wt6fbDgaYWCtpn1uBCxiBg9SvVL7NzxIzSQgqO17I2OpHX/KPkf/hsrB9aOR&#x000A;GeExVSGgAKqKpR1nKQi4gJXCjA5CAhKQQNcJuH50HbkN5piAAijHxrFrEqgl&#x000A;4ALmnJCABCQggVYIuH60Qs1zykpAAVRWyzquUhJwASulWR2UBCQggY4TcP3o&#x000A;OGIbKBABBVCBjGVXJeAC5hyQgAQkIIFWCLh+tELNc8pKQAFUVss6rlIScAEr&#x000A;pVkdlAQkIIGOE3D96DhiGygQAQVQgYxlVyXgAuYckIAEJCCBVgi4frRCzXPK&#x000A;SkABVFbLOq5SEnABK6VZHZQEJCCBjhNw/eg4YhsoEAEFUIGMZVcl4ALmHJCA&#x000A;BCQggVYIuH60Qs1zykpAAVRWyzquUhJwASulWR2UBCQggY4TcP3oOGIbKBAB&#x000A;BVCBjGVXJeAC5hyQgAQkIIFWCLh+tELNc8pKQAFUVss6rlIQ2G+//cKFF14Y&#x000A;Jk2aFA455JCQFrDJkyeHo446Kuy5557hnHPOKcVYHYQEJCABCbSPgOtH+1ha&#x000A;U/kIKIDKZ1NHVCICzz//fFhuueXCwgsvHJZYYonw7LPPhhEjRoSXXnopvP76&#x000A;6+GZZ54JyyyzTIlG7FAkIAEJSKAdBFw/2kHROspKQAFUVss6rtIQOProo8Op&#x000A;p54aXn311b4xLbroouHwww8PJ510UmnG6UAkIAEJSKC9BFw/2svT2spDQAFU&#x000A;HlvmbiQ333xz9FgQtkVZZJFFwoILLhheeeWVvr7y2Q477BAWWmih3PU/Lx3i&#x000A;Kd7IkSPn4bbYYouFp59+Wu/PIEa66667whVXXDHfUUsuuWRYeeWVw9577x3n&#x000A;pEUCEigGAb/TzdmpyuuH9yDNzZWqHa0AqprFuzheLj5PPvlkFEBLL7103Ksy&#x000A;ffr06M0gpOvll1+OYVw777xz4IbU0j+B7FM8vT+Nz5TLL788cAOw2WabxblG&#x000A;QWw/+OCDcR7edNNNiu/GcXqkBHpOwO908yao6vrhPUjzc6VKZyiAqmTtHo71&#x000A;vvvuC7vvvns47LDDwjrrrBNWWGGFsOKKK/awR8VqOvsUT+9P47a77rrrYqjg&#x000A;hhtuOM9Jt9xyS9hmm23CeeedpweocZweKYGeE/A73bwJXD9C8B6k+XlT9jMU&#x000A;QGW3cI/Hx4X3jDPOCJdeemnYYIMNwqabbhpWXXXVsOuuu4aJEyeGfffd1xvQ&#x000A;Bm3EU7xTTjklHHHEEe79aZAZ4W+vvfZa2GijjeK/eoAaBOdhEsgpAb/TrRmm&#x000A;quuH9yCtzZcqnKUAqoKVezBGQt8uuuiicPrpp8d0zQcccEC48cYbw+OPPx72&#x000A;33//8MILL8TPHnrooXDttdfGzGaWgQn85je/CVtssUW4++67w5prrimuBggQ&#x000A;cjl16tSw+OKLz3f0SiutFL2SFglIoDgE/E63Zqv7778/rLfeeuHWW28Nm2yy&#x000A;SWuVFOgs70EKZKwedVUB1CPwZW+W5AcIG/b3kL6ZcvXVV8ekCBMmTOgbPp6h&#x000A;rbbaKiy//PJlR9LS+GbOnBm5IST5PZXNN988HHrooWHs2LEt1Vv2k5566qlw&#x000A;1llnxXm17LLLxn1A7J0ifJDfU+G43XbbLXolLRKQQH4J+J1uzTa33XZb4L1x&#x000A;PAjKrh8kgBk/fnxrlRbgLO9BCmCkHndRAdRjA5S5+blz54YbbrghvPjiizHp&#x000A;wZ133hmWWmqpsPrqq8dhc0O6/fbbuwm9ZhLMnj07ip4pU6YEFq9Uhg0bFhA+&#x000A;fDZnzpz48ejRo2MmM16SOnz48DJPp6bG9txzz8WYb/69/vrro6fn0UcfjewO&#x000A;PPDAvoQIeCLXWGON+K4liwQkkF8Cfqebs80FF1wQH5zhMaMMtH4ghFhLyla8&#x000A;BymbRds7HgVQe3laW4YAwmfrrbeON+hkgUPwUHifDamwJ02aFEURF2ZLiAsV&#x000A;T+oQPtnC4rTjjjvGHwoCiWNY3GbNmtV3aHqih0iy/B8Bwj3uuOOOcMwxx0RW&#x000A;xx57bNhrr73i38hOCCtTsDtbJFAcAn6n+7cVa0NaQ1LEAOsr0QL88JCMY/AG&#x000A;HXfccaVfP7wHKc73uhc9VQD1gnpF2kTkIIBIRZnETxr6m2++Gbbddttw5ZVX&#x000A;Vl4ApRC3rLeHtM0IGkTPQJ4dzkEIUUcqPMljsUM4VdkrRNprQgQJe2Pj9BNP&#x000A;PBH3ne2zzz7RA4QQHzduXF+IZkW+lg5TAoUl4Hd6ftOlMGnWgmyY26hRo6LI&#x000A;YR3pr3AOD9PwFmXXD9YdogqK7hXyHqSwX/WudFwB1BXM1WyEi892220Xdtpp&#x000A;pxhihDs6PXlnH8aZZ54Zbr/99koKIJ7CpRCF7JM6FivES7MLD3WwkPGT9Qqx&#x000A;kFFnFfcKnXvuueGBBx6IIW7Tpk2Lc5G48IMOOqjvC/nSSy8pgKp5eXLUBSTg&#x000A;d/r/jEa0ANc0rvcpxC2Zk2s9a0gzkQD9rR9jxozp22taxIdp3oMU8EvexS4r&#x000A;gLoIu2pNJfczSQ/Y+5MVQDx9P+200yongFhoUogCIoiSntQN5u1pdP7wFJCF&#x000A;sdYrlELkmhVXjbabp+Mee+yx6N3hfT8kQeBmAS8QWQfvvffeebpKSM1qq62W&#x000A;p+7bFwlIoIZA1b/T9cLbQJT29qQw6aEKleQVYh1Je01pJ3mFmhFWvZ7E3oP0&#x000A;2gL5bl8BlG/7FL53eHqWWWaZuuMY6G+FH3hmAMnbU/u0jjA3ntSlvT3tHjNi&#x000A;i0Wsdq9QWijLnAGo3SytTwISkEAvCCThw3U8PTRD9KTreKfWD8bKmsUaUvsw&#x000A;jdC6oqwf3oP0YtYWo00FUDHsZC8LSCBlcsvGZaeFC+FDeEG3Sr1Yb54Upgxy&#x000A;VfAKdYu17UhAAhIYKoF60QI8NEN8dNsLg/BCgGVDrFk/WMfMQDpUS3t+rwgo&#x000A;gHpF3nZLSYBF6/jjj49PzdLTOgZKXHbaj9PLgacMQCxmM2bM6OtK0WO9e8nU&#x000A;tiUgAQm0i0BaQ7LZQHslfOqNKWUgza4f6UFaNx/qtYu39VSXgAKourZ35G0k&#x000A;gIeFpAbZRWvdddeNHhZ+hhqX3cau9lXF5lmEUDbWW69QJ0hbpwQkIIH+CaRM&#x000A;brVh0oSZ4fHJo4e+XgZSBFBKupPHPjsHJZAloAByPkhgCARYBPD4ZFNYs2h1&#x000A;O8RtCEOIp6YMciQLSIUwi7K/LXyo3DxfAhKQQCsE+hM9KUw6r8KndqyMI4XH&#x000A;ZZMmpPWD6Ic8PgBsxWaeUy4CCqBy2dPRdIkA3h4WqNqXzSEYivzkq55XiPFU&#x000A;KYNcl6aQzUhAAhUjQAhyeu9bNn11t5IadBo30QT8ZN8rRJtVfh1Dp5lbf+sE&#x000A;FECts/PMChFIC1d62Vw2hXV6d0+ZnnL197ZwM8hVaNI7VAlIoC0EEDu8/iC7&#x000A;N7QsoqceoLR+1Msg50u62zKlrKQNBBRAbYBoFeUkkERPeqqVHSX7e7iQD/SW&#x000A;7bJQMYNcWSzpOCQggW4R6M/bQ0KDtDe0W33pZTv9vY7BxAm9tIptQ0AB5DyQ&#x000A;QB0Chx12WIxrrhU9XLTxghQ5zK1Vg/eXQY5Yb1KhdvJ9FK322fMkIAEJdJsA&#x000A;+0Jr39uTIgWquHYk/vVe0k3ihIkTJ7p+dHuS2p4CqChzYIEFFihKV0vXT0Lb&#x000A;2O/DTb7l/wiwkE2YMGGeVN+ykcBgBObOnTvYIf69SwRcU7oDGsHz05/+tKvv&#x000A;fevOyFpvhZDAcePG9e2hbb0mz2yVgNdiPUCtzp2un8di5YTtHnZu8HmCl82K&#x000A;llJEk+Wtiu876C9rEVZBHNZ6zLpnLVsqAgGvYfmykvbonD3qrR8Ioarvf6n3&#x000A;cnDXj87Nw/5q9rv/f2QMgev+3GupRSdsS9iGfFJ/8cvpfQeIoTIlP6gHjIw+&#x000A;iJts1iKOSy93JfSt7AyGPJGsIHgNy9ck0B6dt0dKEY0gmjVrVl+DVcqKVi8B&#x000A;hOtH5+feQC343VcA9XYGNtm6E7ZJYB04nAt5el9Oet8BN/4sZnhAyuQVYr8P&#x000A;WYsYb0r17aLVgUlVoSq9huXL2Nqju/aot/+lzF6hlO47+4689HLwqu6j7e6M&#x000A;6781v/sKoLzMxYb64YRtCFPXDqoX4lCGF4cidtjAm03XOmrUqLgHSk9P16ZX&#x000A;KRvyGpYvs2qP3tiDh0s8WMKrnvUKpXetsY4UtTC2FDGQfUeeCSDyZVG/+wqg&#x000A;fM3IQXrjhM2nueq9BTvtFcIrVJSMPzylY+FiYU6FdK0InyIvyPmcNdXsldew&#x000A;fNlde/TeHv1lRWOvECHGRQktZh1MEQPZd+T54Kz3c6xeD/zuK4DyOTP76ZUT&#x000A;Nt/mGihFdFrM8jaCtGixCGfD3NjXxMJVFPGWN672pz4Br2H5mhnaIz/24Pqb&#x000A;vELZ8Or0rpw8XovTe47odzbMjQdnrHm+FiE/86u2J373FUD5nZ11euaELY65&#x000A;2CtEeAMelVRYwFKIQy8XsxSiwKKVTWpAmFsKUyjKU8fizAh7CgGvYfmaB9oj&#x000A;X/ZIvUn7TLMZSPHC5+VBWooWyIZJDxs2LAoe+limvbD5nCFD75XffQXQ0GdR&#x000A;F2twwnYRdpua6i/WOyVN6GZoGYsWIQosWqmkRQvh082+tAmv1RSMgNewfBlM&#x000A;e+TLHrW9wSuEJ55rdvIKpQdphFd380EVfUkh0tloAbw96eXg3exPvi2X/975&#x000A;3VcA5X+WZnrohC2UuebrLAKEJ3u1XiEWOELOOlVojzbqZXJj4bJIoFsEvIZ1&#x000A;i3Rj7WiPxjj1+qheJU1IIW61r0BI0QKsH72MZui1XYrcvt99BVCh5q8TtlDm&#x000A;6rezLCosKIihlAGIJ2eEDrTrqV69FNaGuJVj/hR5FF7D8mU97ZEvezTSGx6k&#x000A;sX6QYjoVQs7amTSh3stKjRZoxDrFOcbvvgKoOLPV+PlC2arRzqZNrzNmzOg7&#x000A;JW16bSWOeqBMPHp7GrWKx3WKgItup8i2Vq/2aI1bHs5KSRNqH6QRXj1x4sSm&#x000A;PTP1Xn/AOH3ZdR6s3f4++N1XALV/VnWwRidsB+H2uOqhPNXrL0zBFNY9NqrN&#x000A;z0fAa1i+JoX2yJc9Wu1Nf0kTUtKdger1ZaWtUi/2eX73FUCFmsFO2EKZq6XO&#x000A;1nunEBWlTaY8jUuFhSu9QyJ9lsIUTGHdEn5P6jABr2EdBtxk9dqjSWA5P7xe&#x000A;0oR676Tr72WlZnHLuYHb2D2/+wqgNk6nzlflhO084zy1wFM9BE421psNp2Rr&#x000A;y6Yfpc+GKeTJcvalPwJew/I1N7RHvuzRrt4M9E461pDs+sHeUPYP8ZDNLG7t&#x000A;skD+6/G7rwDK/yzN9NAJWyhzta2z9WK9qTwtXDy1MxNP23BbUQcJeA3rINwW&#x000A;qtYeLUAr2CnpnXTZVNoMwZeVFsyQbe6u330FUJunVGerc8J2lm8RamevED+I&#x000A;nlaSJBRhjPaxvAS8huXLttojX/boZG+SV4jIAkKkfe9bJ2nnv26/+wqg/M9S&#x000A;PUCFspGdlYAE+ifgopuv2aE98mUPeyOBbhHwu68A6tZca0s7Tti2YLQSCUig&#x000A;RwS8hvUIfD/Nao982cPeSKBbBPzuK4C6Ndfa0o4Tti0YrUQCEugRAa9hPQKv&#x000A;AMoXeHsjgR4T8FqsAOrxFGyueSdsc7w8WgISyBcBr2HaI18E7I0EqknAa7EC&#x000A;qFAz3wlbKHPZWQlIoIaA17B8TQntkS972BsJdIuA330FULfmWlvaccK2BaOV&#x000A;SEACPSLgNaxH4PtpVnvkyx72RgLdIuB3XwHUrbnWlnacsG3BaCUSkECPCHgN&#x000A;6xF4BVC+wNsbCfSYgNdiBVCPp2BzzTthm+Pl0RKQQL4IeA3THvkiYG8kUE0C&#x000A;XosVQIWa+U7YQpnLzkpAAjUEvIbla0poj3zZw95IoFsE/O4rgLo119rSjhO2&#x000A;LRitRAIS6BEBr2E9At9Ps9ojX/awNxLoFgG/+wqgbs21trTjhG0LRiuRgAR6&#x000A;RMBrWI/AK4DyBd7eSKDHBLwWK4B6PAWba94J2xwvj5aABPJFwGuY9sgXAXsj&#x000A;gWoS8FqsACrUzHfCFspcdlYCEqgh4DUsX1NCe+TLHvZGAt0i4HdfAdStudaW&#x000A;dpywbcFoJRKQQI8IeA3rEfh+mtUe+bKHvZFAtwj43VcAdWuutaUdJ2xbMFqJ&#x000A;BCTQIwJew3oEXgGUL/D2RgI9JuC1WAHU4ynYXPNO2OZ4ebQEJJAvAl7DtEe+&#x000A;CNgbCVSTgNdiBVChZr4TtlDmsrMSkEANAa9h+ZoS2iNf9rA3EugWAb/7CqBu&#x000A;zbW2tOOEbQtGK5GABHpEwGtYj8D306z2yJc97I0EukXA774CqFtzrS3tOGHb&#x000A;gtFKJCCBHhHwGtYj8AqgfIG3NxLoMQGvxQqgHk/B5pp3wjbHy6MlIIF8EfAa&#x000A;pj3yRcDeSKCaBLwWK4AKNfOdsIUyl52VgARqCHgNy9eU0B75soe9kUC3CPjd&#x000A;VwB1a661pR0nbFswWokEJNAjAl7DegS+n2a1R77sYW8k0C0CfvcVQN2aa21p&#x000A;xwnbFoxWIgEJ9IiA17AegVcA5Qu8vZFAjwl4LVYA9XgKNte8E7Y5Xh4tAQnk&#x000A;i4DXMO2RLwL2RgLVJOC1WAFUqJnvhC2UueysBCRQQ8BrWL6mhPbIlz3sjQS6&#x000A;RcDvvgKoW3OtLe04YduC0UokIIEeEfAa1iPw/TSrPfJlD3sjgW4R8LuvAOrW&#x000A;XGtLO07YtmC0EglIoEcEvIb1CLwCKF/g7Y0EekzAa7ECqMdTsLnmnbDN8fJo&#x000A;CUjg/2vvTKDtKKo1XHliIiImgIhzguA8IAgoKsagIIIKwQEUA4gaQcVLEmRU&#x000A;r6ICyiwiEIYYUQRERQVFpogicUAj4AQOIeCABhIiKoLIfeur9/ah0uk+p/vc&#x000A;Pt3Vp/9a66577j3VVbv+qt61/9pVu+JCQDpM/REXApJGCLQTAeliEaBGjXwN&#x000A;2EZ1l4QVAkIggYB0WFxDQv0RV39IGiFQFQJ690WAqhprpdSjAVsKjCpECAiB&#x000A;mhCQDqsJ+Ixq1R9x9YekEQJVIaB3XwSoqrFWSj0asKXAqEKEgBCoCQHpsJqA&#x000A;FwGKC3hJIwRqRkC6WASo5iFYrHoN2GJ4KbcQEAJxISAdpv6ICwFJIwTaiYB0&#x000A;sQhQo0a+BmyjukvCCgEhkEBAOiyuIaH+iKs/JI0QqAoBvfsiQFWNtVLq0YAt&#x000A;BUYVIgSEQE0ISIfVBHxGteqPuPpD0giBqhDQuy8CVNVYK6UeDdhSYFQhQkAI&#x000A;1ISAdFhNwIsAxQW8pBECNSMgXSwCVPMQLFa9BmwxvJRbCAiBuBCQDlN/xIWA&#x000A;pBEC7URAulgEqFEjXwO2Ud0lYYWAEEggIB0W15BQf8TVH5JGCFSFgN59EaCq&#x000A;xlop9WjAlgKjChECQqAmBKTDagI+o1r1R1z9IWmEQFUI6N0XAapqrJVSjwZs&#x000A;KTCqECEgBGpCQDqsJuBFgOICXtIIgZoRkC4WAap5CBarXgO2GF7KLQSEQFwI&#x000A;SIepP+JCQNIIgXYiIF0sAtSoka8B26jukrBCQAgkEJAOi2tIqD/i6g9JIwSq&#x000A;QkDvvghQVWOtlHo0YEuBUYUIASFQEwLSYTUBn1Gt+iOu/pA0QqAqBPTuiwBV&#x000A;NdZKqUcDthQYVYgQEAI1ISAdVhPwIkBxAS9phEDNCEgXiwDVPASLVa8BWwwv&#x000A;5RYCQiAuBKTD1B9xISBphEA7EZAuFgFq1MjXgG1Ud0lYISAEEghIh8U1JNQf&#x000A;cfWHpBECVSGgd18EqKqxVko9GrClwKhChIAQqAkB6bCagM+oVv0RV39IGiFQ&#x000A;FQJ690WAqhprpdSjAVsKjCpECAiBmhCQDqsJeBGguICXNEKgZgSki0WAah6C&#x000A;xarXgC2Gl3ILASEQFwLSYeqPuBCQNEKgnQhIF4sANWrka8A2qrskrBAQAgkE&#x000A;pMPiGhLqj7j6Q9IIgaoQ0LsvAlTVWCulHg3YUmBUIUJACNSEgHRYTcBnVKv+&#x000A;iKs/JI0QqAoBvfsiQFWNtVLq0YAtBUYVIgSEQE0ISIfVBLwIUFzASxohUDMC&#x000A;0sUiQDUPwWLVa8AWw0u5hYAQiAsB6TD1R1wISBoh0E4EpItFgBo18jVgG9Vd&#x000A;ElYICIEEAtJhcQ0J9Udc/SFphEBVCOjdFwGqaqyVUo8GbCkwqhAhIARqQkA6&#x000A;rCbgM6pVf8TVH5JGCFSFgN59EaCqxlop9WjAlgKjChECQqAmBKTDagJeBCgu&#x000A;4CWNEKgZAeliEaCah2Cx6jVgi+Gl3EJACMSFgHSY+iMuBCSNEGgHArNnz3bn&#x000A;nnuuO+aYY9zIyIgzXXzyySe7Qw891M2aNcvNnz+/HWAErZwwNjY21rpWN7DB&#x000A;Mh4a2GkSWQgIgQ4C0mFxDQb1R1z9IWmEwKAQuOeee9wGG2zg1lprLbf22mu7&#x000A;FStWuPXXX9/de++97oEHHnB33XWXW3fddQdVfbTligBF2zWrC6bJqiEdJTGF&#x000A;gBBIRUA6LK6Bof6Iqz8kjRAYJAKHHXaYO+GEE9z999/fqWbixIlu7ty57uij&#x000A;jx5k1dGWLQIUbdeIADWkaySmEBACORCQwZ0DpAqzqD8qBFtVCYGaEcALtOGG&#x000A;G7r77ruvI8mkSZPc8uXLW+n9AQQRoJoHZd7qNVnlRUr5hIAQiBEB6bC4ekX9&#x000A;EVd/SBohMGgEQi9Q270/IkCDHm0llq/JqkQwVZQQEAKVIyAdVjnkXStUf8TV&#x000A;H5JGCAwagdAL1HbvjwjQoEdbieVrsioRTBUlBIRA5QhIh1UOuQhQXJBLGiFQ&#x000A;OwJ4gY4//ng3b9681p79sU7QFrjah2M+AWQ85MNJuYSAEIgTAemwuPpF/RFX&#x000A;f0iawSNw9913O0I/v+IVr1ijsqlTp7pp06Z1/k/eG264wf996623+h/Sd7/7&#x000A;Xf+b73/+85938luZL3jBC9yUKVOc/U6WO/hWZteAzIsXL3a77bab++hHP+qj&#x000A;wCXbUUQ+ayPPgJ3hF1Obke2aa65ZrV+t30SAivR2jXk1WdUIvqoWAkJg3AhI&#x000A;h40bwlILUH+UCqcKawACH/nIR7zhX2dKI1+DlgeDH6ITUwoJUxqhLCJrSMSS&#x000A;hLVbOSJARVCuMa8mqxrBV9VCQAiMGwHpsHFDWGoB6o9S4VRhDUDACFCahwIP&#x000A;z7JlyzqtmDx5svfikEJj3Yxt8/IkjXfzEBnpSJZbN0zTp0/3IqS1o6hsIbEK&#x000A;P8fW5s0228x75Uj8hgziFRIBKtrjFeXXzb0VAa1qhIAQGAgC0mEDgbXvQtUf&#x000A;fUOnB4cEASNAo6Ojjs91JCNIVdad9LZUWXdWXeG2QiMmRjiLypf0cPVqr40D&#x000A;EaCiSFeUXzf3VgS0qhECQmAgCEiHDQTWvgtVf/QNnR4cEgROOukkN2fOHDcy&#x000A;MuL4rNROBESAGtDvurm3AZ0kEYWAEMhEQDosrsGh/oirPyRNtQjgfZkxY4Zj&#x000A;G1gdnphqW6vashAQAWrA2NDNvQ3oJIkoBIRAJgLSYXENDvVHXP0haapFQASo&#x000A;WrxjrU0EKNaeScilm3sb0lESUwgIgVQEpMPiGhjqj7j6Q9JUh4AIUHVYx1yT&#x000A;CFDMvRPIppt7G9JRElMICIFUBKTD4hoY6o+4+kPSVIeACFB1WMdc06677uq+&#x000A;/vWvKwpcVifZxUkxXOiUdnOvyWchDWMbbBYGMQw/GJuMkkcItBEBIub0G22n&#x000A;X7yK3D4eXlqXpz7pmDworZ6nSH8UL11PCIE4ERABirNfqpaKu5h8GOyVK1eO&#x000A;Zd2Ma0KFJIDJc9WqVR15k+Hnwr/TLnzqFZ5uPEAUvdE2lLXXsxYznTZZ/Pei&#x000A;5CgZGz0ZBjD5N1jkucDK5DFsTdY0w8D6L4xRb/XaTcdhv4Wfk5dNWRkhdlny&#x000A;Jm9HzrolOWn8ZJWXHEdlGEHhzc82DoselCS6jMWbH89Y1rNCAAQuvvhiN3Pm&#x000A;zFQwku9jmCmP3rD84X0W/C/5N/9Lq6vIO4fX4XGPe5y744473F133eXv2zAZ&#x000A;7XfRdy3vCEmTPa2NyfKy5oSQQKbdD0I5412YCufZZF92m6vsu25jg7Y/61nP&#x000A;cscdd5w76KCD3KRJk9bo8/AOlBCXpH7O6rNe82la33Xr/zS7IWyj9G7et6Hd&#x000A;+XiXNt98c6/PlixZ0m4wWtz6DgEaHR0dq/tm3Bj7wSawJOFLk9VWU8lbVTL5&#x000A;8qyW0tlFDKIy2mATaB78yqgvTxll3jycVd+CBQvcPvvsk0cc5RECPREYxM3l&#x000A;EJcbbrihZ91lZkAHpS3wpNVRlDzEpGN6YdaNmAyKAPaSaRi+r/Nel2HAr01t&#x000A;4AJg0tjYWJuarbYGCKxBgLp5M8KV8WS+pFEZ/p2m0PNOgv30Vp5VvbDcUNZe&#x000A;z9IWW9UKPSbhzcG9ZC6CnZXVbcK0PEm5jOykkSOTwdqe/E2ZYb+Fn5MkKu0m&#x000A;4Sx5k6u94d+hRzFp/GSVlxxHZRlByfrTvJhp/WyLCCtXrpQHqNeLoO9zI9Dt&#x000A;4r5uixp59EZSf2T9zf/T6sqz+JLW0KQOSnqHc4OTM2PaPJTHQ5E1JyCvLXaF&#x000A;eijEqF9srEmhdy05x3abq+y7bmMjbQ5O/i/NG45sefVjr/k0reu66dqs3RF4&#x000A;SMFaBCjny9DybNoC1/IB8P/N7xCgvffee2zhwoVOK9f9DwybDKveV59H4jxb&#x000A;IvKUMwx5yrx5OImHVpWGYYTE14ZhubgPw6Mfozi+HhmfRN0WAPMutoxPguF6&#x000A;2g4zf+1rX3N8VhIC3RAQAdL4AIEOAZo+ffoYKyiLFi3y/1QSAkKgODx6MFQA&#x000A;ACAASURBVAIiQMUx0xO9EdCE3Rsj5WgvAmbIyH5p7xgo0nLp0yJoDW9eEaDh&#x000A;7Vu1rAYERIBqAL0FVWrCbkEnq4l9IyAC1Dd0rXzQgsrssssuPsBMMv3+9793&#x000A;G220kXvUox7VEx/OEEG8Caqw3nrr9cyfluG+++7zQUiGId1///1u4sSJA2kK&#x000A;WF977bWOrcGPfvSjx10H/cXuqAnyAI0bSxUgBDouVa1EajCUiYAIUJloqqxh&#x000A;Q0AEaNh6dLDt6Xam8p///Kd76lOf6r70pS+5bbfd1u23335up5128gTltttu&#x000A;c5zzRR8TQZFk+blP5klPepJ705ve5N797ne7//mf//FE4LrrrnM/+9nP3BVX&#x000A;XOHWXnvtNRp2zjnnuHe84x3+/695zWvcAQcc4H83MXH2+ZnPfKb7xCc+4d75&#x000A;zneW3oTf/va37ulPf7pbvHixe/GLXzzu8m3BesK0adPG2Je8dOlSx2FLJSEg&#x000A;BIojoIm4OGZ6ojcCCtvaGyPlaC8C0rvt7ft+Wt6NAP3nP//x4bHxNEBYnvOc&#x000A;57hvfvOb7olPfKL79a9/7bbZZhuHhwiSRCL/c5/7XPeTn/zE/e1vf3M777yz&#x000A;+/GPf+zWWmstT5o+//nPu9/85jfuU5/61Bqi4tF417ve5c4+++zVvtt3333d&#x000A;GWec4ctoUqKdEMPPfOYz7r3vfW/pohsBAustt9xy3OV3CBDRAClNIQHHjakK&#x000A;aDECmohb3PkDbrq2Vw4YYBXfWASkdxvbdbUInkWA2LmBF+MDH/iA+8Mf/uDe&#x000A;8573uCuvvNLtv//+/v4yPkOGMPTZPnX11Ve75cuXu/e///2+HRAgvEDHHnus&#x000A;YyvYOuus48nNS1/6UnfEEUektpVnL7jgAnfTTTe5FStWuN13393deOON7swz&#x000A;z8zlRfnvf//r/v73v3vbff311++KJ22zbXo8d++9966xze9f//qXJ34231Ag&#x000A;5UPmem3TM4JSNgHi/rgHH3zQe+Ce//zne7KZlwCltcdAEgGq5fVTpcOKgCbi&#x000A;Ye3Z+tslAlR/H0iCOBGQ3o2zX2KVijv60qIeQ2B+9KMfuT333NPfkQaBeeEL&#x000A;X+i3sT32sY91v/zlL/32NCNAf/7znz05ICz89ddf70Oxz58/31111VXumGOO&#x000A;8Yb6vHnzPAxZ95oZAYI8cK7FtpG96EUvckQ1fOCBBxyEjfJIe+yxhzv55JPd&#x000A;hhtu6E499VS/Zc6SkSY8UHPnznU/+MEPHN4kCBkXT7N9zMjDN77xDe99op1v&#x000A;fOMb/RkmriI599xz/fYyyN3DH/5wTwaJQkpChgMPPNB/TpOJ56kjiwBB9Ggv&#x000A;OH/yk5/02DzsYQ9zkBTacvDBB/uyDznkEHf44Ye7Rz7ykb7OD33oQ6sNJWsD&#x000A;7dtrr708WYUYQTI51/XKV74ytT3JLYgiQLG+oZKrkQhoIm5ktzVCaBGgRnST&#x000A;hKwBAendGkBvcJXdxotdOcAWN7avzZ4923uCnva0p/mzPCeeeKIzsgIEtmWO&#x000A;rV8QBsgHBOirX/2qP2A/c+ZMT1q+973v+cAKyWQECO8SXg7OHkEOICenn366&#x000A;r//CCy90hx12mDvrrLO8sQ/BwMinzq222srLRB7IGmdwIE/rrruue/Ob3+w9&#x000A;UG9961t9eHj+NvIAseA52rTDDju4X/3qV26LLbZwz372s93ll1/ut/tBck45&#x000A;5RR31FFHeQ8TBIOjMh/72MdSZaKcLAIEaYM8UcfjH/94d+mll7rPfe5zXjY8&#x000A;ZMj1vve9z2Pw2c9+1p/z4QciBwHadNNNPRmDPJEXcoqsnLl6xjOe4T7+8Y97&#x000A;kprVHiOtIf4iQA1+iSV6fAhoIo6vT4ZFIhGgYelJtaNsBCyaky6gLhvZ4Swv&#x000A;a57+97//7UnEnXfe6T0rt9xyi/eQQIowrNmexvcEPDAvCUTihz/8ofvpT3/q&#x000A;PRYvf/nL3fnnn+/OO+88R3Q3ggGw3ewxj3mM23jjjVMJECQjTARF4MwQ3iV7&#x000A;BnnIB7HhfNImm2zitt56a09cIFEQJc4rQVpOOOEE78mCIFE/W/sI3jBr1qwO&#x000A;AeKMzkUXXeTlfvWrX+3rweMEuYDwnHbaaX6bGaTp05/+tN8SRztuv/32TJnw&#x000A;sKQRIEjijBkz3F/+8hf3i1/8wpcFjtttt52XCcKGzHPmzHGhZwq5IDlgyTP8&#x000A;Jg9kBpLIz/bbb+89SHiDIEhchgwuyfZ8+ctfXiMIhQjQcL7falVNCIgA1QR8&#x000A;C6oVAWpBJ6uJfSHAoXUM1SVLlvgD7EpCoBsCWfP0t7/9bU8uLrnkEved73zH&#x000A;eyMwsIn6hvcDwxqPBN4MttHxG88OxjcBxPAMQR7w0GDIs0WOup7whCd4wpKW&#x000A;IC9JAoQhD5HhzItFm2PrHXWzlQ5PEwmCxZkktozhGcKj8v3vf9/LfvPNN3tC&#x000A;BtG57LLL3PHHH++9UQTUIYy0eZ54b/AmQSzCyG0W0CAZcc3+T/1JmQgOgacG&#x000A;7xd1WSJSHtixTQ0PlxFNCBBE8m1ve5snRhA4I0DmySGP4QNhw+NDXrxXeLcg&#x000A;hB/84AfdW97yFvfkJz+5U3ayPWnYiwBJTwiBEhEQASoRTBW1GgIiQBoQQiAd&#x000A;AeldjYwiCKSdAcIo5yzMF77wBU8yIDYQCCK8QRIwwtmChvFtBIQ6eQ4PBkSB&#x000A;rVts7cIrg9eIUNhHHnmkJxh4UdISBAWjn2fwPPE3RIxgCmyLw6PEti/O5uDV&#x000A;QAbO87ANjede97rXeY8IBADPER4TztYcffTR/pwQpAZCxZY6vDNs50MePC4Q&#x000A;NiNA/D+M3MZWN+rDC/PhD3+4ExTiW9/6lnvDG96QKhP1IC9EjC2DeKG+8pWv&#x000A;uMmTJ/tw4ZAaMOIsFZ4z5CfqNMSI7W/0C54niA318CyfIYNscxsZGelsgYPo&#x000A;QQghYcj3u9/9znuTIKO0NdkeEaAib4jyCoE+ENBE3AdoeiQXAiJAuWBSphYi&#x000A;IL3bwk4fR5PTosCx3YzIbRjrkB62tXFAH68El6Xi7YGEQDLw8nDehGRngPC6&#x000A;cACfbVncg8O2MxJ3AmHgZ4WFxhPD1jMIEN4MztpAEiAEbMGD/Oy2227+tyXy&#x000A;41WCeIWJ7WycAWLbGkSMxFkmziVxqeuOO+7ovVmW7MwMpAXCYAEb7Hu7MNb+&#x000A;hmxAEDkflCYT5XGeJ5nAGy/PS17ykk47qA9SCEmEwHCGJ0wQO85gcUYIQhgm&#x000A;SBuEiHNReIIs4R3C04U+SGtPUq6OB2izzTYbo1Bd4DiOt0qPth4BTcStHwID&#x000A;A0AEaGDQquCGIyC92/AOrFj8bvcA4dHBe4GRj8cCbxDeGAjRX//6V392hQTh&#x000A;gSxhoP/jH//wnhYIBl4TtmJRBwSKA/zHHXfcGuTCmgzp4geCEibO2/A8ic/U&#x000A;zd9TpkzphKOGtHGuhjR16lT3iEc8olMEW+IgU095ylNW81ixrY5y7DwPpAQP&#x000A;Et4iziklE+fqqBv5wMFSmkxErCMSHmdyOJfH3UkEPDC5CLvNtkBScksg/+c5&#x000A;6iB4BInQ4yTaCFHaYIMNfB6i5VlCPvDDK2dhwOm7rPaE7esQoOnTp48huAhQ&#x000A;xW+iqhsqBFB+ulB4qLo0isbYdgQmOT4rCQEh8BACIkAaDUUQ6EWACECAdwFi&#x000A;w1Y2SIxdSvqnP/3JG+B4a0iQBzwUkB620LGt7JxzzvFb0EgcvsejZGd5isip&#x000A;vINFQARosPiq9JYhoFX6lnV4Rc1l2wJRdFiNDLcwVFS9qhECUSMgAhR190Qn&#x000A;nG3tkj6NrmsqFUgEqFK4VdmwIyACNOw9XE/7RIDqwV21NgMBEaBm9FMsUkqf&#x000A;xtIT9cpBAIZly5a5CaOjo2PECSeGNu5BJSEgBIojIAJUHDM90RsBTdi9MVKO&#x000A;9iIgAtTevu+n5U3TpwRI4CxP8pxQVts5i0OgBAISECyBbXicyXnVq1612iOc&#x000A;rZk4caI/W0OysNo777zzGnfm8D3nfgj6wJkezvNw708ycYyG4AxE0Is9md4Q&#x000A;AYq9pyRfIxAQAWpENzVOyKZN2I0DWAI3GgERoEZ3X+XCcxfO5ptv7u+M4u6o&#x000A;mBPho4nkRojpgw46KJeo9gxR1CA4nEni8ta3v/3tPtQ0bScRLICw2TfeeKNb&#x000A;vnx5594jQky/7GUvc6tWrfIXoxI2G9uGoAvbbLONPxNFIpQ2UfE4KzVp0iSf&#x000A;nzt5CLdNULUwKEMuwSvOJAJUMeCqbrgREAEa7v6tq3UiQHUhr3qbgIAIUBN6&#x000A;KS4ZmzJXW5ht7sQhQhqEhnDcBMQh5DUhrvHMEICBaG1EnCP6G+Tk0EMP9XcG&#x000A;nXnmme7CCy/0Ud4I580ZKEuUCzE677zz/N083KNDIogDF5pCgLhs9bWvfa3/&#x000A;P0F48PBwP9Dznvc8d+CBB/qLX9dZZx03e/ZsH+WNcNgWNCKuXl9dmtIJ0NVX&#x000A;X+0vISIEHze8nnHGGT4GOunggw/2ETMAn5B2RRPPH3vssf4m2T322MOz1xUr&#x000A;VvhiCH8XRtmwqEl8t++++/oBYHUS5pC453QszPr666/37sEwEfLwpptu8mH4&#x000A;GHT8Jpwf8cq5gIpkN+oWbUeR/IT8ox4GtCVCC7J3MU+iDbSbWPaW7LZe2k7Z&#x000A;Fs3EvgcPXKGWktjmqbeteZqiVNvaP01tdz8EqEpdnNQZRElicsyT2K5xxRVX&#x000A;+FVGJndLpu+Z7LlDwhK6kAv27AJC24aBDKxEcst5Up8n5WC1kwsNCSyRN2XJ&#x000A;Ez7P3Ma9H8xzvWTIU690cR6UnL/3Q1Fs82GlXM4Hkok9qAx6jvuE8OZATA44&#x000A;4AB31VVXua233tqHsSbiLCGs58+f7+655x530UUXOWw7PDHYb9ttt52/aBTb&#x000A;9fWvf73/4Z6c7bff3tuxkBVsYAgLv7Hz2GYH4dp7773dtdde6y+DhRxRBvqW&#x000A;O472228/T7TQswsWLPB1cofP/vvv77fS8bkK27iMcVwqATK3G+BtueWW/rZX&#x000A;bow1AnT55Zd7wrL77rt7d1rRxCVPkBk6jkmGzqfjSBjzTGg2GRIbnJtkYbN/&#x000A;/OMfVyNdTLh8R37YcDhZMeiog5tswwThgiFTHvkhedRNOweZCKmIOzGZuCiL&#x000A;AdcrcTswcetD1yluTJ7nAiluzw0JEIMcsgSBDROY8KJZXPpe9bb1e2L04wZe&#x000A;unRpbpLaVqzU7vwIFJ2wq9TFbIFI0xlcxvfFL36x50ogi1XMEejp8H4HtmEw&#x000A;2c6ZM8ffsWEJ8mKXELKwxXfhgheGAPNOt0QeFrKYqPPORVnyhPWwKMf9IMg9&#x000A;3u0f0sX53w8RoPxYKWczCJD1E3oAssGdRNhxbNtjyxp6j61seHA4y4NNyv+x&#x000A;QbCR8QrhMEAn3X777e6OO+7wdjNnc5gf2PrGgg0XrhLqG48S5AmbFl3Hxa38&#x000A;P1wkuvLKKz2Bmjt3ri8HwoQNiRcInYztA8m67LLLVrt7KNYxVxoBYkUOhslt&#x000A;tRjLG220kQcUwCEc7F9kdY9OIciCHeZiYj/ttNM8PnQKpAJDmxt1SXgw2G/I&#x000A;aiZ7C5lQ6Vy7VRdmTLx2EuwY1hsm9j3SiXyX9DqZKy8kQDBmVhshOqxgQogY&#x000A;WBz44gZcJktzSS5cuHA1AsSgOf300x2DBMaM+xHixDOUQ34mXdqO6xJysuuu&#x000A;u3pxwQFWzoTMAOKWWzDjWeQjXCOEEhcmB9oomz2WuCiZzHFRcksvGEEMbfUA&#x000A;7DAucFkyOK1OMxj4jhcDvHF5wuDpB/5/wQUX+PaBBftBIUWsOnAgj7zggaHB&#x000A;y0CdJF4GVgBoK+1gFZSbeWkz3qxTTjnFu2bBB8Nmr7328isQ3IbMmOE79q3S&#x000A;38TOpz3E3edWX57h9uGzzjrLEwzKot4777zTu31ZncAty+VklMtBvm6ysmpC&#x000A;fZBBFAkXZx1++OHjiteviThWVddsuYoQoDp0sekMdAJ7xG1vOTqLiZJ7Ndhr&#x000A;z99M4vzwf3Qb7ym6BcLEu0tZ7BxAZ4yMjPjbwtFt6AEC9aAz0XnoFxa+qIvF&#x000A;HHQit4czqaOzsnSxhcBl4Yc60e3oY3QN+hadgS7GsOB7VlPRL5tuummmPIwu&#x000A;5jFkYZ7DOKFMEsQO/cZFfSTuDGEeYAGLvOhFdCR1ok/RQ8yT6DbaKF3c+92V&#x000A;3u2NkXI8hIDpAOyecDtYjBixYM0CEwv26DgjQJzl2WqrrbxNjA03b948b0di&#x000A;Q6P7ICToE+zRHXbYwS8u0V7sNbasoWvJjy193XXXeT3L/1nAoQ50+axZszwk&#x000A;hxxyiNdPOBggTDgyKAvbC5sfXY7tiK7E0dHvLq+q8QdDbNVxB0FgHyLAMvGw&#x000A;IoiyB0RjokSXY5LDsA0JB5M1W+VIGPxMfmx5wK2Gwc6NvBi1GL4Y84BNJ9Fp&#x000A;NulCmGC+uMAhBCHRgSxg4KYRILwrGPahPEykbDswsoNcdDKkhy1wJFuZM4Jg&#x000A;nUZdMF9clEzWEK9bbrnFG+7GnJlk2b521FFHeaOeQQt7J1IHkzyGO3s1qZNo&#x000A;GnhckBMvDmUxiJGRQ22QQ4gILwgGPF4tSBFGBs+deuqp3m26xRZb+C1/4IXx&#x000A;sNNOO/ky8SzxHR47XK1s8UAe2kd99CeTL/hRNjghF88xMePJoz/5nnpZUWAi&#x000A;omyIBf9jcPEcqxI8g1HBZM9NvxgBfIaU0Z+MHZ6FhDJeeOmJZEKfQ3Ipi8R4&#x000A;4IXDIDnyyCN926gDAgQxYtWDMcJLnyUr7bLL0MCJNtP2xYsXd8ZjPy8j+EK6&#x000A;cQ3zcikJgTIQKEKA6tDFpjMgAUQeQl+wIHbzzTf7SfGII47w7yleEXQS+pAt&#x000A;byyYsMBE+5g3ICWUBeFgTznEgYUOmxsgPhgC6Hr0CYl5ASPASBRbpNEzWbqY&#x000A;CZqJHeLD9g5uEWf7NHIREpVFHgwL9DO6CB1k3v4seSAtzFssguGVCncHYJyg&#x000A;s5ijZs6c6XUr8wBt2HbbbTs7DtBZzD22++D888/3RoZ0ce83iIU25hR2fjDX&#x000A;KAmBbgh0uwg1NuSwbSAy6A8W57HLWARmkSVJgJAd8gEBwg5FR7KQjC5Br2KX&#x000A;Yy+jG7GhsLfQzdiuJHQwCecFegidij2DbWoLODyLLckZH/QlCzx77rmnvwiW&#x000A;9w+50O9N2C1k42DcBAjQzKOCEZoWAi/N48JzeIlwpdERIblgMsDYZ8IDfCYS&#x000A;XIEwUQxmIxVMkHQCBjDEiVXBkJTkJUDm7eF5PAFZKYsAIQOyQEBIl156aWci&#x000A;pA14lHAf8nPbbbf5wYxnxiJrQC6YdBk4nDsyAzptG5wdSoNAmgGPm5MBGxI6&#x000A;sMWLg5ERJiNV4MXkzQvDFj9IF2QPuXjhLGEIsLrKyizbOzBIeLF4HhIC4cEN&#x000A;atsH+QyOjAVWf3lRICz0KRM6CZIJsWHFlYN61GmyQ2TB0oired0wXKjbXi7y&#x000A;Y7yYd4pyWSWhLlZRs2TF+2QrHMjMuEI22oGXrd/UJMXabxv1XPUIFCFAdehi&#x000A;O48T6gwWMfiBaDBhM3FCcFjgsUWsXrIymZo+Rk+yIIZeZS6hHBZd8AphCLB4&#x000A;BPFBZ+BVztLF1Gn6hQWccAscRAp9hiee1U70DoQOUoOOyJLHtkJn7Q7AiGBO&#x000A;YVEIw4HFIxbfWHyiTSzu7Ljjjt5zj9FiYWwhj9LFvd83nb3sjZFyPIRAk+Zp&#x000A;FrqxFfGgQzRYqMZeSyNA2Mgs1NsWYfQLugXdg01GYlEqPFbx4IMPetsU3Ymd&#x000A;zcIxdhWLPSyQm+3I1mP0ILuu+B5dif7FbmJBGScFC/vMBSxKNSEIQi0EKEmQ&#x000A;QiPdJhCMcVbyAJoVOBQcwMJM8VbAVJkoMOSZdJlYmbAwfjFuLWVNdFkTr02A&#x000A;kBjrQCYjDHS2aJFCGZkUSTY5Ix8GNR6g8DAYgwfXIl4tSAurhbQBNk55DD62&#x000A;QkAGkIHtHxagwLar0RYGNgYBg5wXggFqB9vwoDD5M8CNgPKSMIEmCZCRUTsD&#x000A;ZFsFMQhoL947DAjcpEzuuD05L8UPKxCsaLJ9gxVdVtwIzMCgh5TyEtIvfCaY&#x000A;BOQPwsKKhHnEwAy3Kyui5lnCIDB5WJEAI3OlghGEKxla0bx4ECBWjMMEee4m&#x000A;K30MhhBXZMGwsgAb/U4WeP0Yf2zd4bOSECgDgUERoDJ0MTrGdKLpGw7UsgXM&#x000A;DHq8Lng90AMsiKDD7VyPvcPJ84jgljU3GAFi0YuVRxYz0I1MwOgMJvgsXUy5&#x000A;tjMgSYCy/m99mCWPzQNpcwPPmlfY5jIrB48xcoeeZ7xSzDfkxTiRLu79BokA&#x000A;9cZIOR5CwLY+NWGnBjoOmwwHAbtljACxhRbdgO2IPmQHC/mwM/Fis2ANWYHU&#x000A;WJQ4POsQIbw75u0x7z07mrClsbGoEx3FQjILzpbY4ks0OOxUFpzYyoy9A57Y&#x000A;TthoLEZB1PKeraxzXJZGgJjEMNxZQcdIxhhlCxM/GJgY56zKYZCeffbZPuIE&#x000A;h6vwDNCp5IMMYJRiCMM0mcBgo6wesh+a7Q94f9gyhycALxDGP88R/QejHC8K&#x000A;HclWMQYFhgN/4yWBILHKxpazLHn4Do8CLkcGFNvpWGFETox5VjEZTBi4eBeY&#x000A;+BiEto2C8yuwaQgcW7GQF/bNoL3kkku8UU/bGYiQATwuGN4wfJ5lAFEH28Mg&#x000A;BhxKQ3ae51m2z7EiyeACb14CtpsgE7gzadJecCEPhJBBzVY5SBh7OfGIsVWD&#x000A;gW37PZGRz/yYy5U6aTsrEJAXjAvIEH1CP4MlLk8ihWDsgAMvHoY/2+wwaPjN&#x000A;5A4mlMG4oD0QQV4Stszx4oAFuFM/fchLBQmkn9jawLYeFACrs5TBGSmwZ2xh&#x000A;AOE5Y7slBha48BzyssUkTVbOHdAWxhUYstLKSwx5pd/7TUUN1X7r0XPtQyCv&#x000A;kVe1LsY7jD5BZ0JsmADR4ehb26bMdxj2RHtDd6LDISosKtkCD3qAeQB9yIIG&#x000A;7zMrmOhEdBb6l8mXyZm5hIkfXYJuQWfgnUZ/MLlz4V+WLkanojORh0UlFnIo&#x000A;n/kIbzg6i8UT9BzyM88w36B3+Z2Uh228LDBlzQ0sRkH+kA0iyGIdcxUY4Akz&#x000A;XYneZrEIw4OzR8whECewky7u/r7nfTfapzXU4jQEmnJmDP3DIje6BXuYbcPo&#x000A;G7w6LJxgA6FHOQKBvkRHWWAw2o1OwWZE10FasG8w+tFFtgBldaBv0M2Ug45j&#x000A;UQm7lPotYdOhj1hoRxZ2M2H7Ys+i97F/sOfxanOmKHYS1CFACxYsGAMkJpxk&#x000A;BLQ8r5Cttod5Mf4xoO3AWbIcyA6TFBMaCeUP6LBWVvBYneesC3uzLdHpnAnB&#x000A;0Gb1kkSnYEAzkZDoZCYdJpcw4TmB3eKZwPOQJg8uPYxtOtEioVEnW84gLnRs&#x000A;MjFwIBwQiuSqP5Md7YAE2IEynuf/TL5M1BAMi5RnZYMnLki2mIXuyjDaHYSG&#x000A;523bCbIzyMM8ybKZeOl0DiqT8OwwiC3oBIYAuFEOyfay838MAfqIaCSw/zCx&#x000A;x5R9opRrz/I9qwxGiOkn6rHvwYwzAxyew/tFHHsOCIcJ4wqSA8FJG1v8DxKZ&#x000A;DH7Bi48RAWlMk5XvKBNXsiVeYPqSVY9+kxGgJlyw1m8b9Vw9COQ18qrWxRjp&#x000A;eH/D7W/hNovwMG2IHASGbRN4iVhJZKHCEu8t5bGIREJ/koeFDc5U4mUmoetY&#x000A;sGGBh+12JOYMns3SxZtssolfuMEIMpnR8ehjFkTQdehFS3yHAQJBS5OH7crM&#x000A;D3a5YNhG9AkLNqZf+RuvOgswNjdAyPg7lAWvPfWxaCRd3Pt9y/tu9C5JOdqA&#x000A;QFMIEIv76DtsQAJhsZ0YO4pFWnQK9h96Di8PC8ToQnblsJCDLmMRGC8XC+qU&#x000A;w6Ivdi36msVkS9jS2OssBmGTYVNhH2FjYtMYCbIjByz44KTgGXYj4SBA72KH&#x000A;40Rg4d283TGPJ+MmExYtWjQWa1x0jGPcdHh1qtxXyLY2JmcmrLyJiRWvUdYz&#x000A;3doCk8aTBXkrEkKViBwMXIusl5TVyqXMtLNZedsW5sNjwspBmqy4YYmwhjcm&#x000A;DGtrz+P9YcJK+w78WDku0n7KxQNGuaTkOOkmK/npZ2SG4JaRNBmXgaLKSCIQ&#x000A;w7jqVxejD9gexmH1rFXBfvRtt1HSSxfzbFYeayd5ytILvUY0C3sYMqzCYqyw&#x000A;VTBPki52nTEV3peXBzvlaScCpoNiDpph17fYYgzb9NGhECF2UbFogp5gQZpF&#x000A;lPCuR/PqQErwCllCD0OYcHKwmI33nbLIz0KxLYyTH5sIksT5fPMWYUuyQA4R&#x000A;4392LISFZBZqWMTCRscea0IQBFuwjpoAtfMVVaubikAMhmpTsZPc2QhoXA3n&#x000A;6OCcD9tJmIwthcFihrPV5bZK70a5eA57aRov/9fDEJrw8ulh7/dk+zoEaLxb&#x000A;4NoGnNorBLIQkHLV2BgEAhpXg0A1jjJZxeUcE4mzkJxrVMqPgN6N/FgppzyG&#x000A;GgP/h0CHAI2Ojo5xXod91JwRURICQqA/BDQZ94ebnspGgIiQnDHh0CuflYSA&#x000A;EHgIAelcjYYiCGi8FEFrePOKAA1v36plNSEg5VoT8ENcraILDnHnqmnjRoCg&#x000A;MwQ44vA2B9yVhEA3BDRHa3zIA6QxIAQGgIBNxkT/47OSEBgvAiJA40VQzw8z&#x000A;Ak2J6jXMfdCktokANam3BierPECDw1YltxQBTcYt7fgBNlsEaIDgqujGIyCd&#x000A;2/gurLQBIkCVwh1tZUTD4/qfCToDFG0fSbCGIaDJuGEd1gBx7cI2ndFsQGdJ&#x000A;xMoR4HZ77pvT+1E59I2sUASokd1WutCdi1BFgErHVgW2FAERoJZ2/ACbLQI0&#x000A;QHBVdOMR0PvR+C6stAEiQJXCHW1lIkDRdo0EayoCIkBN7bl45ZaBF2/fSLL6&#x000A;EdD7UX8fNEkCEaAm9dbgZBUBGhy2KrmlCIgAtbTjB9jsffbZxy1cuNCdeOKJ&#x000A;ju0+SkJACDyEwMUXX+xmzpzppk+fvtqFssJICKQhYASo15UvU6ZMSQ1kxHUE&#x000A;fNdPuvvuu33EQhJXGvA3P3a9gf0vWXaaLGHEw/AiZZ699dZb/U9aSpZFsKas&#x000A;9qSVY3VNmzbNb3QdggAAAzBJREFU8WMplCf5XdjGsO18tu+Sz/BdMqpjWh7y&#x000A;TZ48OTPo1DXXXLMaDIYx7eBHZ4D6Gcl6RgikICACpGFRNgIaU2UjqvKGCQEF&#x000A;CRmm3hx8WzD2V61aVWpFkAjd0VYqpJUVJgJUGdSqaNgR4MJKFKHupBj2nq6u&#x000A;fSJA1WGtmpqHgAhQ8/qsTolt5b+XDEmvheVnfu+XQIWeCvO8hB6ZLG9MN09M&#x000A;EU9J6HEJ20Nb01Kax8VkTMoUeqGSnqxuXif7LvlMGv5Znq3Qs5ZsB57hMCUx&#x000A;FgHq9SboeyGQEwHtL84JlLLlRkAEKDdUythCBESAWtjpkTUZ4133/kXWKTnF&#x000A;mbBgwYIx4mHvsssujv20SkJACPSHgAhQf7jpqWwERIA0OoRANgIiQBodQkAI&#x000A;9IvAhEWLFo3NmDFDhwj7RVDPCYH/R0AESEOhbAREgMpGVOUNEwIiQMPUm2qL&#x000A;EKgWARGgavFWbUOKAG5wzgARJUYHIoe0k2tolp0rW7JkibZZ1IC/qowbgZNO&#x000A;OsnNmTPHjYyMOD4rCQEhIATyIjBh6dKlYxtvvLEPhbdy5cq8zymfEBACAQJa&#x000A;idRwGAQC8ioOAlWVOSwI6B6gYelJtUMIVI/AhLGxsTFNstUDrxqHCwERoOHq&#x000A;z1haI90cS09IjhgREAGKsVckkxBoBgIiQM3oJ0kZOQJ2IZ+CiUTeUQ0TTwSo&#x000A;YR0mcStFQASoUrhVmRAYKgQmrFy5cmy99dbzjUrejpsWlzzPra5ZCHW7ddae&#x000A;Sd7+2g3tbjfe5umlsK5QtqlTp652y22essrIQ3uWLVtWqKhk/PTkrcDh30ls&#x000A;e/1tgtSFRzcgkjf85gUt2ZYwhnw4npKf7dZjw8x+283Qmojz9oDyFUEg7eby&#x000A;rFvKi5Qb5k3eldBvOb2eC/Vb2k3o49Xnvern+6z5Jc/c1O15vut2Iznf96uz&#x000A;0toV6vWsz3nwKDtP2v0mhnnaPJKc83rNZ8ibdkfI6OjoGvZL2W1TeUJACAwX&#x000A;Ap17gIarWXG2BiMahT/sKe0CrbxtrsIIyitLP/k0EfeDmp7JQsAIUJUIpRGs&#x000A;rIsBq5RLdQmBLASkdzU2hIAQKIrA/wLZY1Dxm8RSYgAAAABJRU5ErkJggg=='>
+</div>
+
+</div>
+</div>
+<div class='tree_progress'></div>
+<div class='ui small modal' id='modal-linejump'>
+<div class='ui custom form content'>
+<div class='field'>
+<div class='ui right action input'>
+<input placeholder='跳转至某一行...' type='number'>
+<div class='ui orange button'>
+跳转
+</div>
+</div>
+</div>
+</div>
+</div>
+
+<div class='row column inner-comment' id='blob-comment'>
+<input id="comment_path" name="comment_path" type="hidden" value="image/201811/87106504.jpg" />
+<div class='tree-comments'>
+<h3 id='tree_comm_title'>
+评论
+(
+<span class='comments-count'>
+0
+</span>
+)
+</h3>
+<div class='ui threaded comments middle aligned' id='notes-list'></div>
+<input id="ajax_add_note_id" name="ajax_add_note_id" type="hidden" />
+<div class='text-center'>
+<div class='tip-loading' style='display: none'>
+<div class='ui active mini inline loader'></div>
+正在加载...
+</div>
+</div>
+</div>
+<script>
+  "use strict";
+  $(function(){
+    var page = 1
+    var commentsCount = 0
+    var $container = $('.tree-comments')
+    var $comments = $container.find('.ui.comments')
+    var $tipLoading = $container.find('.tip-loading')
+    var $btnLoad = $container.find('.btn-load-more')
+    var noteAnchor = new Gitee.NoteAnchor({ defaultAnchor: '#tree_comm_title' })
+  
+    if (commentsCount < 1) {
+      return;
+    }
+  
+    var path;
+    if ($('#comment_path').val() === '') {
+      path = '/';
+    } else {
+      path = $('#comment_path').val();
+    }
+  
+    function loadComments () {
+      $btnLoad.hide();
+      $tipLoading.show();
+      $.ajax({
+        url: '/chenssy/blog-home/comment_list',
+        data: {
+          page: page,
+          path: path
+        },
+        success: function(data) {
+          var err;
+          try {
+            $tipLoading.hide();
+            $btnLoad.show();
+            if (data.status !== 0) {
+              $btnLoad.text('无更多评论')
+              return $btnLoad.prop('disabled', true).addClass('disabled');
+            } else {
+              TreeComment.CommentListHandler(data);
+              page += 1;
+              if (data.comments_count < 10) {
+                $('#ajax_add_note_id').val('');
+                $btnLoad.text('无更多评论')
+                $btnLoad.prop('disabled', true).addClass('disabled');
+              }
+              // osctree can not load script
+              $comments.find('.timeago').timeago();
+              $comments.find('.commenter-role-label').popup();
+              noteAnchor.locate();
+              toMathMlCode('', 'comments');
+              return $('.markdown-body pre code').each(function(i, block) {
+                return hljs.highlightBlock(block);
+              });
+            }
+          } catch (error) {
+            err = error;
+            return console.log('loadComments error:' + err);
+          }
+        }
+      });
+    };
+  
+  
+    function checkLoad () {
+      var listTop, top;
+      top = $(window).scrollTop();
+      listTop = $container.offset().top;
+      if (listTop >= top && listTop < top + $(window).height()) {
+        $(window).off('scroll', checkLoad);
+        return loadComments();
+      }
+    };
+  
+    $btnLoad.on('click', loadComments);
+    loadComments()
+  })
+</script>
+
+</div>
+<div class='inner-comment-box' id='comment-box'>
+<p>
+你可以在<a href="/login">登录</a>后，发表评论
+</p>
+
+</div>
+
+<div class='complaint'>
+<div class='ui modal small form' id='landing-comments-complaint-modal'>
+<i class='iconfont icon-close close'></i>
+<div class='header'>
+举报
+</div>
+<div class='content'>
+<div class='appeal-success-tip hide'>
+<i class='iconfont icon-ic_msg_success'></i>
+<div class='appeal-success-text'>
+举报成功
+</div>
+<span>
+我们将于2个工作日内通过站内信反馈结果给你！
+</span>
+</div>
+<div class='appeal-tip'>
+请认真填写举报原因，尽可能描述详细。
+</div>
+<div class='ui form appeal-form'>
+<div class='inline field'>
+<label class='left-part appeal-type-wrap'>
+举报类型
+</label>
+<div class='ui dropdown selection' id='appeal-comments-types'>
+<div class='text default'>
+请选择举报类型
+</div>
+<i class='dropdown icon'></i>
+<div class='menu'></div>
+</div>
+</div>
+<div class='inline field'>
+<label class='left-part'>
+举报原因
+</label>
+<textarea class='appeal-reason' id='appeal-comment-reason' name='msg' placeholder='请说明举报原因' rows='3'></textarea>
+</div>
+<div class='ui message callback-msg hide'></div>
+<div class='ui small error text message exceeded-size-tip'></div>
+</div>
+</div>
+<div class='actions'>
+<div class='ui button blank cancel'>
+取消
+</div>
+<div class='ui orange icon button disabled ok' id='complaint-comment-confirm'>
+发送
+</div>
+</div>
+</div>
+<script>
+  var $complaintCommentsModal = $('#landing-comments-complaint-modal'),
+      $complainCommentType = $complaintCommentsModal.find('#appeal-comments-types'),
+      $complaintModalTip = $complaintCommentsModal.find('.callback-msg'),
+      $complaintCommentsContent = $complaintCommentsModal.find('.appeal-reason'),
+      $complaintCommentBtn = $complaintCommentsModal.find('#complaint-comment-confirm'),
+      complaintSending = false,
+      appealType = 0,
+      initedCommentsType = false;
+  
+  function initCommentsTypeList() {
+    if (!initedCommentsType) {
+      $.ajax({
+        url: "/appeals/fetch_types",
+        method: 'get',
+        data: {'type': 'comment'},
+        success: function (data) {
+          var result = '';
+          for (var i = 0; i < data.length; i++) {
+            result = result + "<div class='item' data-value='" + data[i].id + "'>" + data[i].name + "</div>";
+          }
+          $complainCommentType.find('.menu').html(result);
+        }
+      });
+      $complainCommentType.dropdown({showOnFocus: false});
+      initedCommentsType = true;
+    }
+  }
+  $complainCommentType.on('click', function() {
+    $complaintCommentsModal.modal({
+      autofocus: false,
+      onApprove: function() {
+        return false;
+      },
+      onHidden: function() {
+        restoreCommonentDefault();
+      }
+    }).modal('show');
+  });
+  
+  $complaintCommentsContent.on('change keyup', function(e) {
+    var content = $(this).val();
+    if ($.trim(content).length > 0 && appealType > 0 ) {
+      $complaintCommentBtn.removeClass('disabled');
+      return;
+    }
+    $complaintCommentBtn.addClass('disabled');
+  });
+  
+  
+  $complainCommentType.dropdown({
+    showOnFocus: false,
+    onChange: function(value, text, $selectedItem) {
+      appealType = value;
+      if (value.length > 0 && $.trim($complaintCommentsContent.val()).length > 0) {
+        $complaintCommentBtn.removeClass('disabled');
+        return
+      }
+      $complaintCommentBtn.addClass('disabled');
+    }
+  });
+  
+  function restoreCommonentDefault() {
+    $complainCommentType.dropdown('restore defaults');
+    $complaintCommentsContent.val('');
+    $('.exceeded-size-tip').text('').hide();
+    $complaintModalTip.text('').hide();
+    setTimeout(function() {
+      setCommentSendTip(false);
+    }, 1500);
+  }
+  
+  $complaintCommentBtn.on('click',function(e){
+    var reason = $complaintCommentsContent.val();
+    var appealableId = $('#landing-comments-complaint-modal').attr('data-id');
+    if (complaintSending) {
+      return;
+    }
+    var formData = new FormData();
+    formData.append('type', appealType);
+    formData.append('reason', reason);
+    formData.append('appealType','Note');
+    formData.append('project_id',appealableId);
+    $.ajax({
+      type: 'POST',
+      url: "/appeals",
+      cache: false,
+      contentType: false,
+      processData: false,
+      data: formData,
+      beforeSend: function() {
+        setCommentSendStatus(true);
+      },
+      success: function(res) {
+        if (res.status == 200) {
+          setCommentSendTip(true);
+          setTimeout(function() {
+            $complaintCommentsModal.modal('hide');
+            restoreCommonentDefault();
+          }, 3000);
+        }
+        setCommentSendStatus(false);
+      },
+      error: function(err) {
+        showCommonTips(err.responseJSON.message, 'error');
+        setCommentSendStatus(false);
+      }
+    })
+  });
+  
+  function showCommonTips(text, type) {
+    $complaintModalTip.text(text).show();
+    if (type == 'error') {
+      $complaintModalTip.removeClass('success').addClass('error');
+    } else {
+      $complaintModalTip.removeClass('error').addClass('success');
+    }
+  }
+  
+  function setCommentSendStatus(value) {
+    complaintSending = value;
+    if (complaintSending) {
+      $complaintCommentBtn.addClass('loading');
+      $complaintCommentsContent.attr('readonly', true);
+      $complainCommentType.attr('readonly', true);
+    } else {
+      $complaintCommentBtn.removeClass('loading');
+      $complaintCommentsContent.attr('readonly', false);
+      $complainCommentType.attr('readonly', false);
+    }
+  }
+  
+  function setCommentSendTip(value) {
+    if (value) {
+      $('.appeal-success-tip').removeClass('hide');
+      $('.appeal-tip').addClass('hide');
+      $('.appeal-form').addClass('hide');
+      $('#landing-comments-complaint-modal .actions').addClass('hide');
+    } else {
+      $('.appeal-success-tip').addClass('hide');
+      $('.appeal-tip').removeClass('hide');
+      $('.appeal-form').removeClass('hide');
+      $('#landing-comments-complaint-modal .actions').removeClass('hide');
+    }
+  }
+</script>
+
+</div>
+<script>
+  "use strict";
+  $('.js-check-star').checkbox('set unchecked')
+</script>
+
+</div>
+</div>
+</div>
+<script>
+  (function() {
+    $(function() {
+      Tree.init();
+      return TreeCommentActions.init();
+    });
+  
+  }).call(this);
+</script>
+
+</div>
+</div>
+<script>
+  (function() {
+    var donateModal;
+  
+    Gitee.modalHelper = new GiteeModalHelper({
+      alertText: '提示',
+      okText: '确定'
+    });
+  
+    donateModal = new ProjectDonateModal({
+      el: '#project-donate-modal',
+      alipayUrl: '/chenssy/blog-home/alipay',
+      wepayUrl: '/chenssy/blog-home/wepay',
+      nameIsBlank: '名称不能为空',
+      nameTooLong: '名称过长（最多为 36 个字符）',
+      modalHelper: Gitee.modalHelper
+    });
+  
+    if ("" === 'true') {
+      donateModal.show();
+    }
+  
+    $('#project-donate').on('click', function() {
+      return donateModal.show();
+    });
+  
+  }).call(this);
+</script>
+<script>
+  Tree.initHighlightTheme('white')
+</script>
+
+<script>
+  $(function() {
+    GitLab.GfmAutoComplete.dataSource = "/chenssy/blog-home/autocomplete_sources"
+    GitLab.GfmAutoComplete.Emoji.assetBase = 'https://assets.gitee.com/assets/emoji'
+    GitLab.GfmAutoComplete.setup();
+  });
+</script>
+
+<footer id='git-footer-main'>
+<div class='ui container'>
+<div class='ui two column grid'>
+<div class='column git-footer-left'>
+<p><a href="https://gitee.com/" target="_blank">© Gitee.com  </a></p>
+<div class='ui three column grid' id='footer-left'>
+<div class='column'>
+<div class='ui link list'>
+<div class='item'>
+<a href="/about_us" class="item">关于我们</a>
+</div>
+<div class='item'>
+<a href="/terms" class="item">使用条款</a>
+</div>
+<div class='item'>
+<a href="/oschina/git-osc/issues" class="item">意见建议</a>
+</div>
+<div class='item'>
+<a href="/links.html" class="item">合作伙伴</a>
+</div>
+</div>
+</div>
+<div class='column'>
+<div class='ui link list'>
+<div class='item'>
+<a href="/api/v5/swagger" class="item">OpenAPI</a>
+</div>
+<div class='item'>
+<a href="/all-about-git" class="item">Git 大全</a>
+</div>
+<div class='item'>
+<a href="https://copycat.gitee.com/" class="item">代码克隆检测</a>
+</div>
+<div class='item'>
+<a href="/appclient" class="item">APP与插件下载</a>
+</div>
+</div>
+</div>
+<div class='column'>
+<div class='ui link list'>
+<div class='item'>
+<a href="https://gitee.com/help" class="item">帮助文档</a>
+</div>
+<div class='item'>
+<a href="https://gitee.com/git-osc/" class="item">更新日志</a>
+</div>
+<div class='item'>
+<a href="/gists" class="item">代码片段</a>
+</div>
+<div class='item'>
+<a href="/gitee-stars" class="item">码云封面人物</a>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class='column right aligned followus git-footer-right'>
+<div class='qrcode weixin'>
+<img alt="Qrcode-weixin" src="https://assets.gitee.com/assets/qrcode-weixin-8ab7378f5545710bdb3ad5c9d17fedfe.jpg" />
+<p class='weixin-text'>微信服务号</p>
+</div>
+<div class='phone-and-qq column'>
+<div class='ui list official-support-container'>
+<div class='item'>
+<a href="//shang.qq.com/wpa/qunwpa?idkey=0d6c2fc0b5b71ac33405dd575bb490bf1a50e3c9a9f694e8a689cb59ee7dacc3" class="icon-popup" title="点击加入码云官方群"><i class='iconfont icon-logo-qq'></i>
+<span>
+官方技术支持QQ群：515965326
+</span>
+</a></div>
+<div class='item mail-and-zhihu'>
+<a href="mailto: git@oschina.cn"><i class='iconfont icon-ic-mail'></i>
+<span id='git-footer-email'>
+git#oschina.cn
+</span>
+</a><a href="https://www.zhihu.com/org/ma-yun-osc/ " target="_blank"><i class='iconfont icon-zhihu'></i>
+<span>
+码云Gitee
+</span>
+</a></div>
+<div class='item'>
+企业版售前及售后使用咨询：400-606-0201
+</div>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class='bottombar'>
+<div class='ui container'>
+<div class='ui grid'>
+<div class='five wide column partner'>
+本站带宽由 <a href="https://www.anchnet.com/" target="_blank" title="anchnet"><img alt="51idc" src="/51idc.png" /></a> 提供
+</div>
+<div class='eleven wide column right aligned'>
+<div class='copyright'>
+<a href="http://www.beian.miit.gov.cn/">粤ICP备12009483号-8</a>
+开源中国出品
+</div>
+<i class='icon world'></i>
+<a href="/language/zh-CN">简 体
+</a>/
+<a href="/language/zh-TW">繁 體
+</a>/
+<a href="/language/en">English
+</a></div>
+</div>
+</div>
+</div>
+</footer>
+<script>
+  var officialEmail = $('#git-footer-email').text()
+  $('#git-footer-main .icon-popup').popup({ position: 'bottom center' })
+  $('#git-footer-email').text(officialEmail.replace('#', '@'))
+</script>
+
+
+<div class='side-toolbar'>
+<div class='button toolbar-help'>
+<i class='iconfont icon-help'></i>
+</div>
+<div class='ui popup left center dark'>点此查找更多帮助</div>
+<div class='toolbar-help-dialog'>
+<div class='toolbar-dialog-header'>
+<h3 class='toolbar-dialog-title'>搜索帮助</h3>
+<form accept-charset="UTF-8" action="/help/load_keywords_data" class="toolbar-help-search-form" method="get"><div style="margin:0;padding:0;display:inline"><input name="utf8" type="hidden" value="&#x2713;" /></div>
+<div class='ui icon input fluid toolbar-help-search'>
+<input name='keywords' placeholder='请输入产品名称或问题' type='text'>
+<i class='icon search'></i>
+</div>
+</form>
+
+<i class='iconfont icon-close toolbar-dialog-close-icon'></i>
+</div>
+<div class='toolbar-dialog-content'>
+<div class='toolbar-help-hot-search'>
+<div class='toolbar-list'>
+<div class='toolbar-list-item'>
+<a href="/help/articles/4114">Git 仓库基础操作</a>
+</div>
+<div class='toolbar-list-item'>
+<a href="/help/articles/4166">企业版和个人版功能对比</a>
+</div>
+<div class='toolbar-list-item'>
+<a href="/help/articles/4191">SSH 公钥设置</a>
+</div>
+<div class='toolbar-list-item'>
+<a href="/help/articles/4194">如何处理代码冲突</a>
+</div>
+<div class='toolbar-list-item'>
+<a href="/help/articles/4202">在小程序Web开发工具中使用Git做版本管理</a>
+</div>
+<div class='toolbar-list-item'>
+<a href="/help/articles/4232">仓库体积过大，如何减小？</a>
+</div>
+<div class='toolbar-list-item'>
+<a href="/help/articles/4233">组织私有成员超额，如何处理？</a>
+</div>
+<div class='toolbar-list-item'>
+<a href="/help/articles/4234">个人私有成员超过5人，怎么办？</a>
+</div>
+<div class='toolbar-list-item'>
+<a href="/help/articles/4235">Git LFS 操作指南</a>
+</div>
+</div>
+</div>
+<div class='toolbar-help-search-reseult'>
+<div class='toolbar-help-flex-column'>
+<div class='ui centered inline loader toolbar-help-loader'></div>
+<div class='toolbar-list'></div>
+<div class='toolbar-help-link-to-help'>
+<a href="" target="_blank">查看更多搜索结果</a>
+</div>
+</div>
+</div>
+</div>
+</div>
+<script>
+  var opt = { position: 'left center' };
+  var $helpSideToolbar = $(".button.toolbar-help");
+  
+  $(function() {
+    if (false) {
+      $helpSideToolbar.popup(opt);
+    } else {
+      $helpSideToolbar.popup('show', opt);
+      setTimeout(function() {
+        $helpSideToolbar.popup('hide', opt);
+      }, 3000);
+    }
+  })
+</script>
+
+<div class='button share-link'>
+<i class='iconfont icon-share'></i>
+</div>
+<div class='ui popup dark'>
+<div class='header'>
+分享到
+</div>
+<div class='bdsharebuttonbox' style='display: flex'>
+<a class='iconfont icon-home-service-wechat' data-cmd='weixin' title='分享到微信'></a>
+<a class='iconfont icon-weibo' data-cmd='tsina' title='分享到新浪微博'></a>
+<a class='iconfont icon-qq' data-cmd='sqq' title='分享到QQ好友'></a>
+<a class='iconfont icon-qzone' data-cmd='qzone' title='分享到QQ空间'></a>
+</div>
+</div>
+<div class='popup button' id='home-comment'>
+<i class='iconfont icon-comment'></i>
+</div>
+<div class='ui popup dark'>评论</div>
+<div class='toolbar-appeal popup button'>
+<i class='iconfont icon-report'></i>
+</div>
+<div class='ui popup dark'>
+仓库举报
+</div>
+<script>
+  $('.toolbar-appeal').popup({ position: 'left center' });
+</script>
+
+<div class='button gotop popup' id='gotop'>
+<i class='iconfont icon-top'></i>
+</div>
+<div class='ui popup dark'>回到顶部</div>
+</div>
+<div class='form modal normal-modal tiny ui' id='unlanding-complaint-modal'>
+<i class='iconfont icon-close close'></i>
+<div class='header'>
+登录提示
+</div>
+<div class='container actions'>
+<div class='content'>
+该操作需登录码云帐号，请先登录后再操作。
+</div>
+<div class='ui orange icon large button ok'>
+立即登录
+</div>
+<div class='ui button blank cancel'>
+没有账号，去注册
+</div>
+</div>
+</div>
+<script>
+  var $elm = $('.toolbar-appeal');
+  
+  $elm.on('click', function() {
+    var modals = $("#unlanding-complaint-modal.normal-modal");
+    if (modals.length > 1) {
+      modals.eq(0).modal('show');
+    } else {
+      modals.modal('show');
+    }
+  })
+  $("#unlanding-complaint-modal.normal-modal").modal({
+    onDeny: function() {
+      window.location.href = "/signup?from=";
+    },
+    onApprove: function() {
+      window.location.href = "/login?from=";
+    }
+  })
+</script>
+
+<style>
+  .side-toolbar .bdsharebuttonbox a {
+    font-size: 24px;
+    color: white !important;
+    opacity: 0.9;
+    margin: 6px 6px 0px 6px;
+    background-image: none;
+    text-indent: 0;
+    height: auto;
+    width: auto;
+  }
+</style>
+<script>
+  (function() {
+    $('#project-user-message').popup({
+      position: 'left center'
+    });
+  
+  }).call(this);
+</script>
+<script>
+  Gitee.initSideToolbar({
+    hasComment: true,
+    commentUrl: '/chenssy/blog-home#tree_comm_title'
+  })
+</script>
+<script>
+  window._bd_share_config = {
+    "common": {
+      "bdSnsKey": {},
+      "bdText": document.title,
+      "bdMini": "1",
+      "bdMiniList": ["bdxc","tqf","douban","bdhome","sqq","thx","ibaidu","meilishuo","mogujie","diandian","huaban","duitang","hx","fx","youdao","sdo","qingbiji","people","xinhua","mail","isohu","yaolan","wealink","ty","iguba","fbook","twi","linkedin","h163","evernotecn","copy","print"],
+      "bdPic": "",
+      "bdStyle": "1",
+      "bdSize": "32"
+    },
+    "share": {}
+  }
+</script>
+<script src="/bd_share/static/api/js/share.js" type="text/javascript"></script>
+
+
+
+<script>
+  (function() {
+    this.__gac = {
+      domain: 'www.oschina.net'
+    };
+  
+  }).call(this);
+</script>
+<script defer src='//www.oschina.net/public/javascripts/cjl/ga.js?t=20160926' type='text/javascript'></script>
+
+</body>
+</html>
diff --git a/spring/06-Spring-IoC 之 Spring 统一资源加载策略.md b/spring/06-Spring-IoC 之 Spring 统一资源加载策略.md
new file mode 100644
index 0000000..17e06c0
--- /dev/null
+++ b/spring/06-Spring-IoC 之 Spring 统一资源加载策略.md	
@@ -0,0 +1,874 @@
+# 【死磕 Spring】—— IoC 之 Spring 统一资源加载策略
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=2656 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+在学 Java SE 的时候，我们学习了一个标准类 `java.net.URL`，该类在 Java SE 中的定位为统一资源定位器（Uniform Resource Locator），但是我们知道它的实现基本只限于网络形式发布的资源的查找和定位。然而，实际上资源的定义比较广泛，除了网络形式的资源，还有以二进制形式存在的、以文件形式存在的、以字节流形式存在的等等。而且它可以存在于任何场所，比如网络、文件系统、应用程序中。所以 `java.net.URL` 的局限性迫使 Spring 必须实现自己的资源加载策略，该资源加载策略需要满足如下要求：
+
+1. 职能划分清楚。资源的定义和资源的加载应该要有一个清晰的**界限**；
+2. 统一的抽象。统一的资源**定义**和资源加载**策略**。资源加载后要返回统一的抽象给客户端，客户端要对资源进行怎样的处理，应该由抽象资源接口来界定。
+
+# 1. 统一资源：Resource
+
+`org.springframework.core.io.Resource` 为 Spring 框架所有资源的抽象和访问接口，它继承 `org.springframework.core.io.InputStreamSource`接口。作为所有资源的统一抽象，Resource 定义了一些通用的方法，由子类 `AbstractResource` 提供统一的默认实现。定义如下：
+
+```
+public interface Resource extends InputStreamSource {
+
+	/**
+	 * 资源是否存在
+	 */
+	boolean exists();
+
+	/**
+	 * 资源是否可读
+	 */
+	default boolean isReadable() {
+		return true;
+	}
+
+	/**
+	 * 资源所代表的句柄是否被一个 stream 打开了
+	 */
+	default boolean isOpen() {
+		return false;
+	}
+
+	/**
+	 * 是否为 File
+	 */
+	default boolean isFile() {
+		return false;
+	}
+
+	/**
+	 * 返回资源的 URL 的句柄
+	 */
+	URL getURL() throws IOException;
+
+	/**
+	 * 返回资源的 URI 的句柄
+	 */
+	URI getURI() throws IOException;
+
+	/**
+	 * 返回资源的 File 的句柄
+	 */
+	File getFile() throws IOException;
+
+	/**
+	 * 返回 ReadableByteChannel
+	 */
+	default ReadableByteChannel readableChannel() throws IOException {
+		return java.nio.channels.Channels.newChannel(getInputStream());
+	}
+
+	/**
+	 * 资源内容的长度
+	 */
+	long contentLength() throws IOException;
+
+	/**
+	 * 资源最后的修改时间
+	 */
+	long lastModified() throws IOException;
+
+	/**
+	 * 根据资源的相对路径创建新资源
+	 */
+	Resource createRelative(String relativePath) throws IOException;
+
+	/**
+	 * 资源的文件名
+	 */
+	@Nullable
+	String getFilename();
+
+	/**
+	 * 资源的描述
+	 */
+	String getDescription();
+
+}
+```
+
+## 1.1 子类结构
+
+类结构图如下：
+
+[![Resource 类图](06-Spring-IoC 之 Spring 统一资源加载策略.assets/143162657d5f8c7cb7712d0996bf2a38.jpeg)](http://static.iocoder.cn/143162657d5f8c7cb7712d0996bf2a38)Resource 类图
+
+从上图可以看到，Resource 根据资源的不同类型提供不同的具体实现，如下：
+
+- FileSystemResource ：对 `java.io.File` 类型资源的封装，只要是跟 File 打交道的，基本上与 FileSystemResource 也可以打交道。支持文件和 URL 的形式，实现 WritableResource 接口，且从 Spring Framework 5.0 开始，FileSystemResource 使用 NIO2 API进行读/写交互。
+- ByteArrayResource ：对字节数组提供的数据的封装。如果通过 InputStream 形式访问该类型的资源，该实现会根据字节数组的数据构造一个相应的 ByteArrayInputStream。
+- UrlResource ：对 `java.net.URL`类型资源的封装。内部委派 URL 进行具体的资源操作。
+- ClassPathResource ：class path 类型资源的实现。使用给定的 ClassLoader 或者给定的 Class 来加载资源。
+- InputStreamResource ：将给定的 InputStream 作为一种资源的 Resource 的实现类。
+
+## 1.2 AbstractResource
+
+`org.springframework.core.io.AbstractResource` ，为 Resource 接口的默认**抽象**实现。它实现了 Resource 接口的**大部分的公共实现**，作为 Resource 接口中的重中之重，其定义如下：
+
+```
+public abstract class AbstractResource implements Resource {
+
+	/**
+	 * 判断文件是否存在，若判断过程产生异常（因为会调用SecurityManager来判断），就关闭对应的流
+	 */
+	@Override
+	public boolean exists() {
+		try {
+		  // 基于 File 进行判断
+			return getFile().exists();
+		}
+		catch (IOException ex) {
+			// Fall back to stream existence: can we open the stream?
+			// 基于 InputStream 进行判断
+			try {
+				InputStream is = getInputStream();
+				is.close();
+				return true;
+			} catch (Throwable isEx) {
+				return false;
+			}
+		}
+	}
+
+	/**
+	 * 直接返回true，表示可读
+	 */
+	@Override
+	public boolean isReadable() {
+		return true;
+	}
+
+	/**
+	 * 直接返回 false，表示未被打开
+	 */
+	@Override
+	public boolean isOpen() {
+		return false;
+	}
+
+	/**
+	 * 直接返回false，表示不为 File
+	 */
+	@Override
+	public boolean isFile() {
+		return false;
+	}
+
+	/**
+	 * 抛出 FileNotFoundException 异常，交给子类实现
+	 */
+	@Override
+	public URL getURL() throws IOException {
+		throw new FileNotFoundException(getDescription() + " cannot be resolved to URL");
+
+	}
+
+	/**
+	 * 基于 getURL() 返回的 URL 构建 URI
+	 */
+	@Override
+	public URI getURI() throws IOException {
+		URL url = getURL();
+		try {
+			return ResourceUtils.toURI(url);
+		} catch (URISyntaxException ex) {
+			throw new NestedIOException("Invalid URI [" + url + "]", ex);
+		}
+	}
+
+	/**
+	 * 抛出 FileNotFoundException 异常，交给子类实现
+	 */
+	@Override
+	public File getFile() throws IOException {
+		throw new FileNotFoundException(getDescription() + " cannot be resolved to absolute file path");
+	}
+
+	/**
+	 * 根据 getInputStream() 的返回结果构建 ReadableByteChannel
+	 */
+	@Override
+	public ReadableByteChannel readableChannel() throws IOException {
+		return Channels.newChannel(getInputStream());
+	}
+
+	/**
+	 * 获取资源的长度
+	 *
+	 * 这个资源内容长度实际就是资源的字节长度，通过全部读取一遍来判断
+	 */
+	@Override
+	public long contentLength() throws IOException {
+		InputStream is = getInputStream();
+		try {
+			long size = 0;
+			byte[] buf = new byte[255]; // 每次最多读取 255 字节
+			int read;
+			while ((read = is.read(buf)) != -1) {
+				size += read;
+			}
+			return size;
+		} finally {
+			try {
+				is.close();
+			} catch (IOException ex) {
+			}
+		}
+	}
+
+	/**
+	 * 返回资源最后的修改时间
+	 */
+	@Override
+	public long lastModified() throws IOException {
+		long lastModified = getFileForLastModifiedCheck().lastModified();
+		if (lastModified == 0L) {
+			throw new FileNotFoundException(getDescription() +
+					" cannot be resolved in the file system for resolving its last-modified timestamp");
+		}
+		return lastModified;
+	}
+
+	protected File getFileForLastModifiedCheck() throws IOException {
+		return getFile();
+	}
+
+	/**
+	 * 抛出 FileNotFoundException 异常，交给子类实现
+	 */
+	@Override
+	public Resource createRelative(String relativePath) throws IOException {
+		throw new FileNotFoundException("Cannot create a relative resource for " + getDescription());
+	}
+
+	/**
+	 * 获取资源名称，默认返回 null ，交给子类实现
+	 */
+	@Override
+	@Nullable
+	public String getFilename() {
+		return null;
+	}
+
+	/**
+	 * 返回资源的描述
+	 */
+	@Override
+	public String toString() {
+		return getDescription();
+	}
+
+	@Override
+	public boolean equals(Object obj) {
+		return (obj == this ||
+			(obj instanceof Resource && ((Resource) obj).getDescription().equals(getDescription())));
+	}
+
+	@Override
+	public int hashCode() {
+		return getDescription().hashCode();
+	}
+
+}
+```
+
+如果我们想要实现自定义的 Resource ，记住不要实现 Resource 接口，而应该继承 AbstractResource 抽象类，然后根据当前的具体资源特性覆盖相应的方法即可。
+
+## 1.3 其他子类
+
+> 来自艿艿
+
+Resource 的子类，例如 FileSystemResource、ByteArrayResource 等等的代码非常简单。感兴趣的胖友，自己去研究。
+
+# 2. 统一资源定位：ResourceLoader
+
+一开始就说了 Spring 将资源的定义和资源的加载区分开了，Resource 定义了统一的资源，**那资源的加载则由 ResourceLoader 来统一定义**。
+
+`org.springframework.core.io.ResourceLoader` 为 Spring 资源加载的统一抽象，具体的资源加载则由相应的实现类来完成，所以我们可以将 ResourceLoader 称作为统一资源定位器。其定义如下：
+
+> FROM 《Spring 源码深度解析》P16 页
+>
+> ResourceLoader，定义资源加载器，主要应用于根据给定的资源文件地址，返回对应的 Resource 。
+
+```
+public interface ResourceLoader {
+
+	String CLASSPATH_URL_PREFIX = ResourceUtils.CLASSPATH_URL_PREFIX; // CLASSPATH URL 前缀。默认为："classpath:"
+
+	Resource getResource(String location);
+
+	ClassLoader getClassLoader();
+
+}
+```
+
+- ```
+  #getResource(String location)
+  ```
+
+   
+
+  方法，根据所提供资源的路径 location 返回 Resource 实例，但是它不确保该 Resource 一定存在，需要调用
+
+   
+
+  ```
+  Resource#exist()
+  ```
+
+   
+
+  方法来判断。
+
+  - 该方法支持以下模式的资源加载：
+    - URL位置资源，如 `"file:C:/test.dat"` 。
+    - ClassPath位置资源，如 `"classpath:test.dat` 。
+    - 相对路径资源，如 `"WEB-INF/test.dat"` ，此时返回的Resource 实例，根据实现不同而不同。
+  - 该方法的主要实现是在其子类 DefaultResourceLoader 中实现，具体过程我们在分析 DefaultResourceLoader 时做详细说明。
+
+- `#getClassLoader()` 方法，返回 ClassLoader 实例，对于想要获取 ResourceLoader 使用的 ClassLoader 用户来说，可以直接调用该方法来获取。在分析 Resource 时，提到了一个类 ClassPathResource ，这个类是可以根据指定的 ClassLoader 来加载资源的。
+
+## 2.1 子类结构
+
+作为 Spring 统一的资源加载器，它提供了统一的抽象，具体的实现则由相应的子类来负责实现，其类的类结构图如下：
+
+[![ResourceLoader 类图](06-Spring-IoC 之 Spring 统一资源加载策略.assets/2446cc9fba90605b691ea250cf340ebb.png)](http://static.iocoder.cn/2446cc9fba90605b691ea250cf340ebb)ResourceLoader 类图
+
+## 2.1 DefaultResourceLoader
+
+与 AbstractResource 相似，`org.springframework.core.io.DefaultResourceLoader` 是 ResourceLoader 的默认实现。
+
+### 2.1.1 构造函数
+
+它接收 ClassLoader 作为构造函数的参数，或者使用不带参数的构造函数。
+
+- 在使用**不带**参数的构造函数时，使用的 ClassLoader 为默认的 ClassLoader（一般 `Thread.currentThread()#getContextClassLoader()` ）。
+- 在使用**带**参数的构造函数时，可以通过 `ClassUtils#getDefaultClassLoader()`获取。
+
+代码如下：
+
+```
+@Nullable
+private ClassLoader classLoader;
+
+public DefaultResourceLoader() { // 无参构造函数
+	this.classLoader = ClassUtils.getDefaultClassLoader();
+}
+
+public DefaultResourceLoader(@Nullable ClassLoader classLoader) { // 带 ClassLoader 参数的构造函数
+	this.classLoader = classLoader;
+}
+
+public void setClassLoader(@Nullable ClassLoader classLoader) {
+	this.classLoader = classLoader;
+}
+
+@Override
+@Nullable
+public ClassLoader getClassLoader() {
+	return (this.classLoader != null ? this.classLoader : ClassUtils.getDefaultClassLoader());
+}
+```
+
+- 另外，也可以调用 `#setClassLoader()` 方法进行后续设置。
+
+### 2.1.2 getResource 方法
+
+ResourceLoader 中最核心的方法为 `#getResource(String location)` ，它根据提供的 location 返回相应的 Resource 。而 DefaultResourceLoader 对该方法提供了**核心实现**（因为，它的两个子类都没有提供覆盖该方法，所以可以断定 ResourceLoader 的资源加载策略就封装在 DefaultResourceLoader 中)，代码如下：
+
+```
+// DefaultResourceLoader.java
+
+@Override
+public Resource getResource(String location) {
+    Assert.notNull(location, "Location must not be null");
+
+    // 首先，通过 ProtocolResolver 来加载资源
+    for (ProtocolResolver protocolResolver : this.protocolResolvers) {
+        Resource resource = protocolResolver.resolve(location, this);
+        if (resource != null) {
+            return resource;
+        }
+    }
+    // 其次，以 / 开头，返回 ClassPathContextResource 类型的资源
+    if (location.startsWith("/")) {
+        return getResourceByPath(location);
+    // 再次，以 classpath: 开头，返回 ClassPathResource 类型的资源
+    } else if (location.startsWith(CLASSPATH_URL_PREFIX)) {
+        return new ClassPathResource(location.substring(CLASSPATH_URL_PREFIX.length()), getClassLoader());
+    // 然后，根据是否为文件 URL ，是则返回 FileUrlResource 类型的资源，否则返回 UrlResource 类型的资源
+    } else {
+        try {
+            // Try to parse the location as a URL...
+            URL url = new URL(location);
+            return (ResourceUtils.isFileURL(url) ? new FileUrlResource(url) : new UrlResource(url));
+        } catch (MalformedURLException ex) {
+            // 最后，返回 ClassPathContextResource 类型的资源
+            // No URL -> resolve as resource path.
+            return getResourceByPath(location);
+        }
+    }
+}
+```
+
+- 首先，通过 ProtocolResolver 来加载资源，成功返回 Resource 。
+
+- 其次，若 `location` 以 `"/"` 开头，则调用 `#getResourceByPath()` 方法，构造 ClassPathContextResource 类型资源并返回。代码如下：
+
+  ```
+  protected Resource getResourceByPath(String path) {
+  	return new ClassPathContextResource(path, getClassLoader());
+  }
+  ```
+
+- 再次，若 `location` 以 `"classpath:"` 开头，则构造 ClassPathResource 类型资源并返回。在构造该资源时，通过 `#getClassLoader()` 获取当前的 ClassLoader。
+- 然后，构造 URL ，尝试通过它进行资源定位，若没有抛出 MalformedURLException 异常，则判断是否为 FileURL , 如果是则构造 FileUrlResource 类型的资源，否则构造 UrlResource 类型的资源。
+- 最后，若在加载过程中抛出 MalformedURLException 异常，则委派 `#getResourceByPath()` 方法，实现资源定位加载。😈 实际上，和【其次】相同落。
+
+### 2.1.3 ProtocolResolver
+
+`org.springframework.core.io.ProtocolResolver` ，用户自定义协议资源解决策略，作为 DefaultResourceLoader 的 **SPI**：它允许用户自定义资源加载协议，而不需要继承 ResourceLoader 的子类。
+在介绍 Resource 时，提到如果要实现自定义 Resource，我们只需要继承 AbstractResource 即可，但是有了 ProtocolResolver 后，我们不需要直接继承 DefaultResourceLoader，改为实现 ProtocolResolver 接口也可以实现自定义的 ResourceLoader。
+
+ProtocolResolver 接口，仅有一个方法 `Resource resolve(String location, ResourceLoader resourceLoader)` 。代码如下：
+
+```
+/**
+ * 使用指定的 ResourceLoader ，解析指定的 location 。
+ * 若成功，则返回对应的 Resource 。
+ *
+ * Resolve the given location against the given resource loader
+ * if this implementation's protocol matches.
+ * @param location the user-specified resource location 资源路径
+ * @param resourceLoader the associated resource loader 指定的加载器 ResourceLoader
+ * @return a corresponding {@code Resource} handle if the given location
+ * matches this resolver's protocol, or {@code null} otherwise 返回为相应的 Resource
+ */
+@Nullable
+Resource resolve(String location, ResourceLoader resourceLoader);
+```
+
+------
+
+在 Spring 中你会发现该接口并没有实现类，它需要用户自定义，自定义的 Resolver 如何加入 Spring 体系呢？调用 `DefaultResourceLoader#addProtocolResolver(ProtocolResolver)` 方法即可。代码如下：
+
+```
+/**
+ * ProtocolResolver 集合
+ */
+private final Set<ProtocolResolver> protocolResolvers = new LinkedHashSet<>(4);
+
+public void addProtocolResolver(ProtocolResolver resolver) {
+	Assert.notNull(resolver, "ProtocolResolver must not be null");
+	this.protocolResolvers.add(resolver);
+}
+```
+
+### 2.1.4 示例
+
+下面示例是演示 DefaultResourceLoader 加载资源的具体策略，代码如下（该示例参考[《Spring 揭秘》](https://item.jd.com/10062476670.html?jd_pop=1b9f1d77-f489-4473-b2f0-f22036d20060&abt=0) P89）：
+
+```
+ResourceLoader resourceLoader = new DefaultResourceLoader();
+
+Resource fileResource1 = resourceLoader.getResource("D:/Users/chenming673/Documents/spark.txt");
+System.out.println("fileResource1 is FileSystemResource:" + (fileResource1 instanceof FileSystemResource));
+
+Resource fileResource2 = resourceLoader.getResource("/Users/chenming673/Documents/spark.txt");
+System.out.println("fileResource2 is ClassPathResource:" + (fileResource2 instanceof ClassPathResource));
+
+Resource urlResource1 = resourceLoader.getResource("file:/Users/chenming673/Documents/spark.txt");
+System.out.println("urlResource1 is UrlResource:" + (urlResource1 instanceof UrlResource));
+
+Resource urlResource2 = resourceLoader.getResource("http://www.baidu.com");
+System.out.println("urlResource1 is urlResource:" + (urlResource2 instanceof  UrlResource));
+```
+
+运行结果：
+
+```
+fileResource1 is FileSystemResource:false
+fileResource2 is ClassPathResource:true
+urlResource1 is UrlResource:true
+urlResource1 is urlResource:true
+```
+
+- 其实对于 `fileResource1` ，我们更加希望是 FileSystemResource 资源类型。但是，事与愿违，它是 ClassPathResource 类型。为什么呢？在 `DefaultResourceLoader#getResource()` 方法的资源加载策略中，我们知道 `"D:/Users/chenming673/Documents/spark.txt"` 地址，其实在该方法中没有相应的资源类型，那么它就会在抛出 MalformedURLException 异常时，通过 `DefaultResourceLoader#getResourceByPath(...)` 方法，构造一个 ClassPathResource 类型的资源。
+- 而 `urlResource1` 和 `urlResource2` ，指定有协议前缀的资源路径，则通过 URL 就可以定义，所以返回的都是 UrlResource 类型。
+
+## 2.2 FileSystemResourceLoader
+
+从上面的示例，我们看到，其实 DefaultResourceLoader 对`#getResourceByPath(String)` 方法处理其实不是很恰当，这个时候我们可以使用 `org.springframework.core.io.FileSystemResourceLoader` 。它继承 DefaultResourceLoader ，且覆写了 `#getResourceByPath(String)` 方法，使之从文件系统加载资源并以 FileSystemResource 类型返回，这样我们就可以得到想要的资源类型。代码如下：
+
+```
+@Override
+protected Resource getResourceByPath(String path) {
+	// 截取首 /
+	if (path.startsWith("/")) {
+		path = path.substring(1);
+	}
+	// 创建 FileSystemContextResource 类型的资源
+	return new FileSystemContextResource(path);
+}
+```
+
+### 2.2.1 FileSystemContextResource
+
+FileSystemContextResource ，为 FileSystemResourceLoader 的内部类，它继承 FileSystemResource 类，实现 ContextResource 接口。代码如下：
+
+```
+/**
+ * FileSystemResource that explicitly expresses a context-relative path
+ * through implementing the ContextResource interface.
+ */
+private static class FileSystemContextResource extends FileSystemResource implements ContextResource {
+
+	public FileSystemContextResource(String path) {
+		super(path);
+	}
+
+	@Override
+	public String getPathWithinContext() {
+		return getPath();
+	}
+}
+```
+
+- 在构造器中，也是调用 FileSystemResource 的构造函数来构造 FileSystemResource 的。
+- 为什么要有 FileSystemContextResource 类的原因是，实现 ContextResource 接口，并实现对应的 `#getPathWithinContext()` 接口方法。
+
+### 2.2.2 示例
+
+😈 在回过头看 [「2.1.4 示例」](https://svip.iocoder.cn/Spring/IoC-load-Resource/#) ，如果将 DefaultResourceLoader 改为 FileSystemResourceLoader ，则 `fileResource1` 则为 FileSystemResource 类型的资源。
+
+## 2.3 ClassRelativeResourceLoader
+
+`org.springframework.core.io.ClassRelativeResourceLoader` ，是 DefaultResourceLoader 的另一个子类的实现。和 FileSystemResourceLoader 类似，在实现代码的结构上类似，也是覆写 `#getResourceByPath(String path)` 方法，并返回其对应的 ClassRelativeContextResource 的资源类型。
+
+感兴趣的胖友，可以看看 [《Spring5：就这一次，搞定资源加载器之ClassRelativeResourceLoader》](https://blog.csdn.net/seasonsbin/article/details/80914911) 文章。
+
+> ClassRelativeResourceLoader 扩展的功能是，可以根据给定的`class` 所在包或者所在包的子包下加载资源。
+
+## 2.4 ResourcePatternResolver
+
+ResourceLoader 的 `Resource getResource(String location)` 方法，每次只能根据 location 返回**一个** Resource 。当需要加载多个资源时，我们除了多次调用 `#getResource(String location)` 方法外，别无他法。`org.springframework.core.io.support.ResourcePatternResolver` 是 ResourceLoader 的扩展，它支持根据指定的资源路径匹配模式每次返回**多个** Resource 实例，其定义如下：
+
+```
+public interface ResourcePatternResolver extends ResourceLoader {
+
+	String CLASSPATH_ALL_URL_PREFIX = "classpath*:";
+
+	Resource[] getResources(String locationPattern) throws IOException;
+
+}
+```
+
+- ResourcePatternResolver 在 ResourceLoader 的基础上增加了 `#getResources(String locationPattern)` 方法，以支持根据路径匹配模式返回**多个** Resource 实例。
+- 同时，也新增了一种**新的协议**前缀 `"classpath*:"`，该协议前缀由其子类负责实现。
+
+## 2.5 PathMatchingResourcePatternResolver
+
+`org.springframework.core.io.support.PathMatchingResourcePatternResolver` ，为 ResourcePatternResolver 最常用的子类，它除了支持 ResourceLoader 和 ResourcePatternResolver 新增的 `"classpath*:"` 前缀外，**还支持 Ant 风格的路径匹配模式**（类似于 `"**/*.xml"`）。
+
+### 2.5.1 构造函数
+
+PathMatchingResourcePatternResolver 提供了三个构造函数，如下：
+
+```
+/**
+ * 内置的 ResourceLoader 资源定位器
+ */
+private final ResourceLoader resourceLoader;
+/**
+ * Ant 路径匹配器
+ */
+private PathMatcher pathMatcher = new AntPathMatcher();
+
+public PathMatchingResourcePatternResolver() {
+	this.resourceLoader = new DefaultResourceLoader();
+}
+
+public PathMatchingResourcePatternResolver(ResourceLoader resourceLoader) {
+	Assert.notNull(resourceLoader, "ResourceLoader must not be null");
+	this.resourceLoader = resourceLoader;
+}
+
+public PathMatchingResourcePatternResolver(@Nullable ClassLoader classLoader) {
+	this.resourceLoader = new DefaultResourceLoader(classLoader);
+}
+```
+
+- PathMatchingResourcePatternResolver 在实例化的时候，可以指定一个 ResourceLoader，如果不指定的话，它会在内部构造一个 DefaultResourceLoader 。
+- `pathMatcher` 属性，默认为 AntPathMatcher 对象，用于支持 Ant 类型的路径匹配。
+
+### 2.5.2 getResource
+
+```
+@Override
+public Resource getResource(String location) {
+	return getResourceLoader().getResource(location);
+}
+
+public ResourceLoader getResourceLoader() {
+	return this.resourceLoader;
+}
+```
+
+该方法，直接委托给相应的 ResourceLoader 来实现。所以，如果我们在实例化的 PathMatchingResourcePatternResolver 的时候，如果未指定 ResourceLoader 参数的情况下，那么在加载资源时，其实就是 DefaultResourceLoader 的过程。
+
+其实在下面介绍的 `Resource[] getResources(String locationPattern)` 方法也相同，只不过返回的资源是**多个**而已。
+
+### 2.5.3 getResources
+
+```
+@Override
+public Resource[] getResources(String locationPattern) throws IOException {
+    Assert.notNull(locationPattern, "Location pattern must not be null");
+    // 以 "classpath*:" 开头
+    if (locationPattern.startsWith(CLASSPATH_ALL_URL_PREFIX)) {
+        // 路径包含通配符
+        // a class path resource (multiple resources for same name possible)
+        if (getPathMatcher().isPattern(locationPattern.substring(CLASSPATH_ALL_URL_PREFIX.length()))) {
+            // a class path resource pattern
+            return findPathMatchingResources(locationPattern);
+        // 路径不包含通配符
+        } else {
+            // all class path resources with the given name
+            return findAllClassPathResources(locationPattern.substring(CLASSPATH_ALL_URL_PREFIX.length()));
+        }
+    // 不以 "classpath*:" 开头
+    } else {
+        // Generally only look for a pattern after a prefix here, // 通常只在这里的前缀后面查找模式
+        // and on Tomcat only after the "*/" separator for its "war:" protocol. 而在 Tomcat 上只有在 “*/ ”分隔符之后才为其 “war:” 协议
+        int prefixEnd = (locationPattern.startsWith("war:") ? locationPattern.indexOf("*/") + 1 :
+                locationPattern.indexOf(':') + 1);
+        // 路径包含通配符
+        if (getPathMatcher().isPattern(locationPattern.substring(prefixEnd))) {
+            // a file pattern
+            return findPathMatchingResources(locationPattern);
+        // 路径不包含通配符
+        } else {
+            // a single resource with the given name
+            return new Resource[] {getResourceLoader().getResource(locationPattern)};
+        }
+    }
+}
+```
+
+处理逻辑如下图：
+
+[![img](06-Spring-IoC 之 Spring 统一资源加载策略.assets/bbb679d9d2be10643fd7e20ca88d3f2b)](http://static.iocoder.cn/bbb679d9d2be10643fd7e20ca88d3f2b)
+
+- **非** `"classpath*:"` 开头，且路径**不包含**通配符，直接委托给相应的 ResourceLoader 来实现。
+- 其他情况，调用 `#findAllClassPathResources(...)`、或 `#findPathMatchingResources(...)` 方法，返回多个 Resource 。下面，我们来详细分析。
+
+### 2.5.4 findAllClassPathResources
+
+当 `locationPattern` 以 `"classpath*:"` 开头但是不包含通配符，则调用 `#findAllClassPathResources(...)` 方法加载资源。该方法返回 classes 路径下和所有 jar 包中的所有相匹配的资源。
+
+```
+protected Resource[] findAllClassPathResources(String location) throws IOException {
+	String path = location;
+	// 去除首个 /
+	if (path.startsWith("/")) {
+		path = path.substring(1);
+	}
+	// 真正执行加载所有 classpath 资源
+	Set<Resource> result = doFindAllClassPathResources(path);
+	if (logger.isTraceEnabled()) {
+		logger.trace("Resolved classpath location [" + location + "] to resources " + result);
+	}
+	// 转换成 Resource 数组返回
+	return result.toArray(new Resource[0]);
+}
+```
+
+真正执行加载的是在 `#doFindAllClassPathResources(...)` 方法，代码如下：
+
+```
+protected Set<Resource> doFindAllClassPathResources(String path) throws IOException {
+	Set<Resource> result = new LinkedHashSet<>(16);
+	ClassLoader cl = getClassLoader();
+	// <1> 根据 ClassLoader 加载路径下的所有资源
+	Enumeration<URL> resourceUrls = (cl != null ? cl.getResources(path) : ClassLoader.getSystemResources(path));
+	// <2>
+	while (resourceUrls.hasMoreElements()) {
+		URL url = resourceUrls.nextElement();
+		// 将 URL 转换成 UrlResource
+		result.add(convertClassLoaderURL(url));
+	}
+	// <3> 加载路径下得所有 jar 包
+	if ("".equals(path)) {
+		// The above result is likely to be incomplete, i.e. only containing file system references.
+		// We need to have pointers to each of the jar files on the classpath as well...
+		addAllClassLoaderJarRoots(cl, result);
+	}
+	return result;
+}
+```
+
+- `<1>` 处，根据 ClassLoader 加载路径下的所有资源。在加载资源过程时，如果在构造 PathMatchingResourcePatternResolver 实例的时候如果传入了 ClassLoader，则调用该 ClassLoader 的 `#getResources()` 方法，否则调用 `ClassLoader#getSystemResources(path)` 方法。另外，`ClassLoader#getResources()` 方法，代码如下:
+
+  ```
+  // java.lang.ClassLoader.java
+  public Enumeration<URL> getResources(String name) throws IOException {
+      @SuppressWarnings("unchecked")
+      Enumeration<URL>[] tmp = (Enumeration<URL>[]) new Enumeration<?>[2];
+      if (parent != null) {
+          tmp[0] = parent.getResources(name);
+      } else {
+          tmp[0] = getBootstrapResources(name);
+      }
+      tmp[1] = findResources(name);
+  
+      return new CompoundEnumeration<>(tmp);
+  }
+  ```
+
+  - 看到这里是不是就已经一目了然了？如果当前父类加载器不为 `null` ，则通过父类向上迭代获取资源，否则调用 `#getBootstrapResources()` 。这里是不是特别熟悉，(*^▽^*)。
+
+- `<2>` 处，遍历 URL 集合，调用 `#convertClassLoaderURL(URL url)` 方法，将 URL 转换成 UrlResource 对象。代码如下：
+
+  ```
+  protected Resource convertClassLoaderURL(URL url) {
+  	return new UrlResource(url);
+  }
+  ```
+
+- `<3>` 处，若 `path` 为空（`“”`）时，则调用 `#addAllClassLoaderJarRoots(...)`方法。该方法主要是加载路径下得所有 jar 包，方法较长也没有什么实际意义就不贴出来了。感兴趣的胖友，自己可以去看看。😈 当然，可能代码也比较长哈。
+
+通过上面的分析，我们知道 `#findAllClassPathResources(...)` 方法，其实就是利用 ClassLoader 来加载指定路径下的资源，不论它是在 class 路径下还是在 jar 包中。如果我们传入的路径为空或者 `/`，则会调用 `#addAllClassLoaderJarRoots(...)` 方法，加载所有的 jar 包。
+
+### 2.5.5 findPathMatchingResources
+
+当 `locationPattern` 中包含了**通配符**，则调用该方法进行资源加载。代码如下：
+
+```
+protected Resource[] findPathMatchingResources(String locationPattern) throws IOException {
+    // 确定根路径、子路径
+    String rootDirPath = determineRootDir(locationPattern);
+    String subPattern = locationPattern.substring(rootDirPath.length());
+    // 获取根据路径下的资源
+    Resource[] rootDirResources = getResources(rootDirPath);
+    // 遍历，迭代
+    Set<Resource> result = new LinkedHashSet<>(16);
+    for (Resource rootDirResource : rootDirResources) {
+        rootDirResource = resolveRootDirResource(rootDirResource);
+        URL rootDirUrl = rootDirResource.getURL();
+        // bundle 资源类型
+        if (equinoxResolveMethod != null && rootDirUrl.getProtocol().startsWith("bundle")) {
+            URL resolvedUrl = (URL) ReflectionUtils.invokeMethod(equinoxResolveMethod, null, rootDirUrl);
+            if (resolvedUrl != null) {
+                rootDirUrl = resolvedUrl;
+            }
+            rootDirResource = new UrlResource(rootDirUrl);
+        }
+        // vfs 资源类型
+        if (rootDirUrl.getProtocol().startsWith(ResourceUtils.URL_PROTOCOL_VFS)) {
+            result.addAll(VfsResourceMatchingDelegate.findMatchingResources(rootDirUrl, subPattern, getPathMatcher()));
+        // jar 资源类型
+        } else if (ResourceUtils.isJarURL(rootDirUrl) || isJarResource(rootDirResource)) {
+            result.addAll(doFindPathMatchingJarResources(rootDirResource, rootDirUrl, subPattern));
+        // 其它资源类型
+        } else {
+            result.addAll(doFindPathMatchingFileResources(rootDirResource, subPattern));
+        }
+    }
+    if (logger.isTraceEnabled()) {
+        logger.trace("Resolved location pattern [" + locationPattern + "] to resources " + result);
+    }
+    // 转换成 Resource 数组返回
+    return result.toArray(new Resource[0]);
+}
+```
+
+方法有点儿长，但是思路还是很清晰的，主要分两步：
+
+1. 确定目录，获取该目录下得所有资源。
+2. 在所获得的所有资源后，进行迭代匹配获取我们想要的资源。
+
+------
+
+在这个方法里面，我们要关注两个方法，一个是 `#determineRootDir(String location)` 方法，一个是 `#doFindPathMatchingXXXResources(...)` 等方法。
+
+#### 2.5.5.1 determineRootDir
+
+`determineRootDir(String location)` 方法，主要是用于确定根路径。代码如下：
+
+```
+/**
+ * Determine the root directory for the given location.
+ * <p>Used for determining the starting point for file matching,
+ * resolving the root directory location to a {@code java.io.File}
+ * and passing it into {@code retrieveMatchingFiles}, with the
+ * remainder of the location as pattern.
+ * <p>Will return "/WEB-INF/" for the pattern "/WEB-INF/*.xml",
+ * for example.
+ * @param location the location to check
+ * @return the part of the location that denotes the root directory
+ * @see #retrieveMatchingFiles
+ */
+protected String determineRootDir(String location) {
+	// 找到冒号的后一位
+	int prefixEnd = location.indexOf(':') + 1;
+	// 根目录结束位置
+	int rootDirEnd = location.length();
+	// 在从冒号开始到最后的字符串中，循环判断是否包含通配符，如果包含，则截断最后一个由”/”分割的部分。
+	// 例如：在我们路径中，就是最后的ap?-context.xml这一段。再循环判断剩下的部分，直到剩下的路径中都不包含通配符。
+	while (rootDirEnd > prefixEnd && getPathMatcher().isPattern(location.substring(prefixEnd, rootDirEnd))) {
+		rootDirEnd = location.lastIndexOf('/', rootDirEnd - 2) + 1;
+	}
+	// 如果查找完成后，rootDirEnd = 0 了，则将之前赋值的 prefixEnd 的值赋给 rootDirEnd ，也就是冒号的后一位
+	if (rootDirEnd == 0) {
+		rootDirEnd = prefixEnd;
+	}
+	// 截取根目录
+	return location.substring(0, rootDirEnd);
+}
+```
+
+方法比较绕，效果如下示例：
+
+|               原路径               |      确定根路径       |
+| :--------------------------------: | :-------------------: |
+| `classpath*:test/cc*/spring-*.xml` |  `classpath*:test/`   |
+| `classpath*:test/aa/spring-*.xml`  | `classpath*:test/aa/` |
+
+#### 2.5.5.2 doFindPathMatchingXXXResources
+
+> 来自艿艿
+
+`#doFindPathMatchingXXXResources(...)` 方法，是个泛指，一共对应三个方法：
+
+- `#doFindPathMatchingJarResources(rootDirResource, rootDirUrl, subPatter)` 方法
+- `#doFindPathMatchingFileResources(rootDirResource, subPattern)` 方法
+- `VfsResourceMatchingDelegate#findMatchingResources(rootDirUrl, subPattern, pathMatcher)` 方法
+
+因为本文重在分析 Spring 统一资源加载策略的整体**流程**。相对来说，上面几个方法的代码量会比较多。所以本文不再追溯，感兴趣的胖友，推荐阅读如下文章：
+
+- [《Spring源码情操陶冶-PathMatchingResourcePatternResolver路径资源匹配溶解器》](https://www.cnblogs.com/question-sky/p/6959493.html) ，主要针对 `#doFindPathMatchingJarResources(rootDirResource, rootDirUrl, subPatter)` 方法。
+- [《深入 Spring IoC 源码之 ResourceLoader》](http://www.blogjava.net/DLevin/archive/2012/12/01/392337.html) ，主要针对 `#doFindPathMatchingFileResources(rootDirResource, subPattern)` 方法。
+- [《Spring 源码学习 —— 含有通配符路径解析（上）》](http://www.coderli.com/spring-wildpath-parse/) 😈 貌似没有下
+
+# 3. 小结
+
+至此 Spring 整个资源记载过程已经分析完毕。下面简要总结下：
+
+- Spring 提供了 Resource 和 ResourceLoader 来统一抽象整个资源及其定位。使得资源与资源的定位有了一个更加清晰的界限，并且提供了合适的 Default 类，使得自定义实现更加方便和清晰。
+- AbstractResource 为 Resource 的默认抽象实现，它对 Resource 接口做了一个统一的实现，子类继承该类后只需要覆盖相应的方法即可，同时对于自定义的 Resource 我们也是继承该类。
+- DefaultResourceLoader 同样也是 ResourceLoader 的默认实现，在自定 ResourceLoader 的时候我们除了可以继承该类外还可以实现 ProtocolResolver 接口来实现自定资源加载协议。
+- DefaultResourceLoader 每次只能返回单一的资源，所以 Spring 针对这个提供了另外一个接口 ResourcePatternResolver ，该接口提供了根据指定的 locationPattern 返回多个资源的策略。其子类 PathMatchingResourcePatternResolver 是一个集大成者的 ResourceLoader ，因为它即实现了 `Resource getResource(String location)` 方法，也实现了 `Resource[] getResources(String locationPattern)` 方法。
+
+另外，如果胖友认真的看了本文的包结构，我们可以发现，Resource 和 ResourceLoader 核心是在，`spring-core` 项目中。
+
+如果想要调试本小节的相关内容，可以直接使用 Resource 和 ResourceLoader 相关的 API ，进行操作调试。
\ No newline at end of file
diff --git a/spring/07-Spring-IoC 之加载 BeanDefinition.assets/1e395ffbda4fe58a49897854a7d72ce9.png b/spring/07-Spring-IoC 之加载 BeanDefinition.assets/1e395ffbda4fe58a49897854a7d72ce9.png
new file mode 100644
index 0000000..fee62e7
Binary files /dev/null and b/spring/07-Spring-IoC 之加载 BeanDefinition.assets/1e395ffbda4fe58a49897854a7d72ce9.png differ
diff --git a/spring/07-Spring-IoC 之加载 BeanDefinition.md b/spring/07-Spring-IoC 之加载 BeanDefinition.md
new file mode 100644
index 0000000..742aad5
--- /dev/null
+++ b/spring/07-Spring-IoC 之加载 BeanDefinition.md	
@@ -0,0 +1,233 @@
+# 死磕 Spring】—— IoC 之加载 BeanDefinition
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=2658 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+先看一段熟悉的代码：
+
+```
+ClassPathResource resource = new ClassPathResource("bean.xml"); // <1>
+DefaultListableBeanFactory factory = new DefaultListableBeanFactory(); // <2>
+XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(factory); // <3>
+reader.loadBeanDefinitions(resource); // <4>
+```
+
+这段代码是 Spring 中编程式使用 IoC 容器，通过这四段简单的代码，我们可以初步判断 IoC 容器的使用过程。
+
+1. 获取资源
+2. 获取 BeanFactory
+3. 根据新建的 BeanFactory 创建一个 BeanDefinitionReader 对象，该 Reader 对象为资源的**解析器**
+4. 装载资源
+
+整个过程就分为三个步骤：资源定位、装载、注册，如下：
+
+[![整体步骤](07-Spring-IoC 之加载 BeanDefinition.assets/1e395ffbda4fe58a49897854a7d72ce9.png)](http://static.iocoder.cn/1e395ffbda4fe58a49897854a7d72ce9)整体步骤
+
+- **资源定位**。我们一般用外部资源来描述 Bean 对象，所以在初始化 IoC 容器的第一步就是需要定位这个外部资源。在上一篇博客（[《【死磕 Spring】—— IoC 之 Spring 统一资源加载策略》](http://svip.iocoder.cn/Spring/IoC-load-Resource)）已经详细说明了资源加载的过程。
+
+- **装载**。装载就是 BeanDefinition 的载入。BeanDefinitionReader 读取、解析 Resource 资源，也就是将用户定义的 Bean 表示成 IoC 容器的内部数据结构：BeanDefinition 。
+
+  - 在 IoC 容器内部维护着一个 BeanDefinition Map 的数据结构
+
+  - 在配置文件中每一个 `<bean>` 都对应着一个 BeanDefinition 对象。
+
+  - 😈 本文，我们分享的就是**装载**这个步骤。
+
+    > FROM 《Spring 源码深度解析》P16 页
+    > BeanDefinitionReader ，主要定义资源文件读取并转换为 BeanDefinition 的各个功能。
+
+- **注册**。向 IoC 容器注册在第二步解析好的 BeanDefinition，这个过程是通过 BeanDefinitionRegistry 接口来实现的。在 IoC 容器内部其实是将第二个过程解析得到的 BeanDefinition 注入到一个 HashMap 容器中，IoC 容器就是通过这个 HashMap 来维护这些 BeanDefinition 的。
+
+  - 在这里需要注意的一点是这个过程并没有完成依赖注入（Bean 创建），Bean 创建是发生在应用第一次调用 `#getBean(...)` 方法，向容器索要 Bean 时。
+  - 当然我们可以通过设置预处理，即对某个 Bean 设置 `lazyinit = false` 属性，那么这个 Bean 的依赖注入就会在容器初始化的时候完成。
+
+> FROM 老艿艿
+>
+> 简单的说，上面步骤的结果是，XML Resource => XML Document => Bean Definition 。
+
+# 1. loadBeanDefinitions
+
+资源定位在前面已经分析了，下面我们直接分析**加载**，上面看到的 `reader.loadBeanDefinitions(resource)` 代码，才是加载资源的真正实现，所以我们直接从该方法入手。代码如下：
+
+```
+// XmlBeanDefinitionReader.java
+@Override
+public int loadBeanDefinitions(Resource resource) throws BeanDefinitionStoreException {
+	return loadBeanDefinitions(new EncodedResource(resource));
+}
+```
+
+- 从指定的 xml 文件加载 Bean Definition ，这里会先对 Resource 资源封装成 `org.springframework.core.io.support.EncodedResource` 对象。这里为什么需要将 Resource 封装成 EncodedResource 呢？主要是为了对 Resource 进行编码，保证内容读取的正确性。
+- 然后，再调用 `#loadBeanDefinitions(EncodedResource encodedResource)` 方法，执行真正的逻辑实现。
+
+```
+/**
+ * 当前线程，正在加载的 EncodedResource 集合。
+ */
+private final ThreadLocal<Set<EncodedResource>> resourcesCurrentlyBeingLoaded = new NamedThreadLocal<>("XML bean definition resources currently being loaded");
+
+public int loadBeanDefinitions(EncodedResource encodedResource) throws BeanDefinitionStoreException {
+	Assert.notNull(encodedResource, "EncodedResource must not be null");
+	if (logger.isTraceEnabled()) {
+		logger.trace("Loading XML bean definitions from " + encodedResource);
+	}
+
+	// <1> 获取已经加载过的资源
+	Set<EncodedResource> currentResources = this.resourcesCurrentlyBeingLoaded.get();
+	if (currentResources == null) {
+		currentResources = new HashSet<>(4);
+		this.resourcesCurrentlyBeingLoaded.set(currentResources);
+	}
+	if (!currentResources.add(encodedResource)) { // 将当前资源加入记录中。如果已存在，抛出异常
+		throw new BeanDefinitionStoreException("Detected cyclic loading of " + encodedResource + " - check your import definitions!");
+	}
+	try {
+		// <2> 从 EncodedResource 获取封装的 Resource ，并从 Resource 中获取其中的 InputStream
+		InputStream inputStream = encodedResource.getResource().getInputStream();
+		try {
+			InputSource inputSource = new InputSource(inputStream);
+			if (encodedResource.getEncoding() != null) { // 设置编码
+				inputSource.setEncoding(encodedResource.getEncoding());
+			}
+			// 核心逻辑部分，执行加载 BeanDefinition
+			return doLoadBeanDefinitions(inputSource, encodedResource.getResource());
+		} finally {
+			inputStream.close();
+		}
+	} catch (IOException ex) {
+		throw new BeanDefinitionStoreException("IOException parsing XML document from " + encodedResource.getResource(), ex);
+	} finally {
+		// 从缓存中剔除该资源 <3>
+		currentResources.remove(encodedResource);
+		if (currentResources.isEmpty()) {
+			this.resourcesCurrentlyBeingLoaded.remove();
+		}
+	}
+}
+```
+
+- ```
+  <1>
+  ```
+
+   
+
+  处，通过
+
+   
+
+  ```
+  resourcesCurrentlyBeingLoaded.get()
+  ```
+
+   
+
+  代码，来获取已经加载过的资源，然后将
+
+   
+
+  ```
+  encodedResource
+  ```
+
+   
+
+  加入其中，如果
+
+   
+
+  ```
+  resourcesCurrentlyBeingLoaded
+  ```
+
+   
+
+  中已经存在该资源，则抛出 BeanDefinitionStoreException 异常。
+
+  - 为什么需要这么做呢？答案在 `"Detected cyclic loading"` ，避免一个 EncodedResource 在加载时，还没加载完成，又加载自身，从而导致**死循环**。
+  - 也因此，在 `<3>` 处，当一个 EncodedResource 加载完成后，需要从缓存中剔除。
+
+- `<2>` 处理，从 `encodedResource` 获取封装的 Resource 资源，并从 Resource 中获取相应的 InputStream ，然后将 InputStream 封装为 InputSource ，最后调用 `#doLoadBeanDefinitions(InputSource inputSource, Resource resource)` 方法，执行加载 Bean Definition 的真正逻辑。
+
+# 2. doLoadBeanDefinitions
+
+```
+/**
+ * Actually load bean definitions from the specified XML file.
+ * @param inputSource the SAX InputSource to read from
+ * @param resource the resource descriptor for the XML file
+ * @return the number of bean definitions found
+ * @throws BeanDefinitionStoreException in case of loading or parsing errors
+ * @see #doLoadDocument
+ * @see #registerBeanDefinitions
+ */
+protected int doLoadBeanDefinitions(InputSource inputSource, Resource resource)
+		throws BeanDefinitionStoreException {
+	try {
+		// <1> 获取 XML Document 实例
+		Document doc = doLoadDocument(inputSource, resource);
+		// <2> 根据 Document 实例，注册 Bean 信息
+		int count = registerBeanDefinitions(doc, resource);
+		if (logger.isDebugEnabled()) {
+			logger.debug("Loaded " + count + " bean definitions from " + resource);
+		}
+		return count;
+	} catch (BeanDefinitionStoreException ex) {
+		throw ex;
+	} catch (SAXParseException ex) {
+		throw new XmlBeanDefinitionStoreException(resource.getDescription(),
+                "Line " + ex.getLineNumber() + " in XML document from " + resource + " is invalid", ex);
+	} catch (SAXException ex) {
+		throw new XmlBeanDefinitionStoreException(resource.getDescription(),
+				"XML document from " + resource + " is invalid", ex);
+	} catch (ParserConfigurationException ex) {
+		throw new BeanDefinitionStoreException(resource.getDescription(),
+				"Parser configuration exception parsing XML from " + resource, ex);
+	} catch (IOException ex) {
+		throw new BeanDefinitionStoreException(resource.getDescription(),
+				"IOException parsing XML document from " + resource, ex);
+	} catch (Throwable ex) {
+		throw new BeanDefinitionStoreException(resource.getDescription(),
+				"Unexpected exception parsing XML document from " + resource, ex);
+	}
+}
+```
+
+- 在 `<1>` 处，调用 `#doLoadDocument(InputSource inputSource, Resource resource)` 方法，根据 xml 文件，获取 Document 实例。
+- 在 `<2>` 处，调用 `#registerBeanDefinitions(Document doc, Resource resource)` 方法，根据获取的 Document 实例，注册 Bean 信息。
+
+## 2.1 doLoadDocument
+
+```
+/**
+ * 获取 XML Document 实例
+ *
+ * Actually load the specified document using the configured DocumentLoader.
+ * @param inputSource the SAX InputSource to read from
+ * @param resource the resource descriptor for the XML file
+ * @return the DOM Document
+ * @throws Exception when thrown from the DocumentLoader
+ * @see #setDocumentLoader
+ * @see DocumentLoader#loadDocument
+ */
+protected Document doLoadDocument(InputSource inputSource, Resource resource) throws Exception {
+	return this.documentLoader.loadDocument(inputSource, getEntityResolver(), this.errorHandler,
+			getValidationModeForResource(resource), isNamespaceAware());
+}
+```
+
+1. 调用 `#getValidationModeForResource(Resource resource)` 方法，获取指定资源（xml）的**验证模式**。详细解析，见 [《【死磕 Spring】—— IoC 之获取验证模型》](http://svip.iocoder.cn/Spring/IoC-Validation-Mode-For-Resource) 。
+2. 调用 `DocumentLoader#loadDocument(InputSource inputSource, EntityResolver entityResolver, ErrorHandler errorHandler, int validationMode, boolean namespaceAware)` 方法，获取 XML Document 实例。详细解析，见 [《【死磕 Spring】—— IoC 之获取 Document 对象》](http://svip.iocoder.cn/Spring/IoC-load-Document) 。
+
+## 2.2 registerBeanDefinitions
+
+该方法的详细解析，见 [《【死磕 Spring】—— IoC 之注册 BeanDefinition》](http://svip.iocoder.cn/Spring/IoC-register-BeanDefinitions) 。
+
+# 666. 彩蛋
+
+本文未完，需要继续阅读后续几篇文章。
\ No newline at end of file
diff --git a/spring/08-Spring-IoC 之获取验证模型.md b/spring/08-Spring-IoC 之获取验证模型.md
new file mode 100644
index 0000000..80cf5dd
--- /dev/null
+++ b/spring/08-Spring-IoC 之获取验证模型.md	
@@ -0,0 +1,305 @@
+# 【死磕 Spring】—— IoC 之获取验证模型
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=2688 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+在上篇博客[【死磕 Spring】—— IoC 之加载 Definitions](http://svip.iocoder.cn/Spring/IoC-load-BeanDefinitions) 中提到，在核心逻辑方法 `#doLoadBeanDefinitions(InputSource inputSource, Resource resource)` 方法中，中主要是做三件事情：
+
+1. 调用 `#getValidationModeForResource(Resource resource)` 方法，获取指定资源（xml）的**验证模式**。
+2. 调用 `DocumentLoader#loadDocument(InputSource inputSource, EntityResolver entityResolver,ErrorHandler errorHandler, int validationMode, boolean namespaceAware)` 方法，获取 XML Document 实例。
+3. 调用 `#registerBeanDefinitions(Document doc, Resource resource)` 方法，根据获取的 Document 实例，注册 Bean 信息。
+
+这篇博客主要**第 1 步**，分析获取 xml 文件的验证模式。为什么需要获取验证模式呢？原因如下：
+
+> XML 文件的验证模式保证了 XML 文件的正确性。
+
+# 1. DTD 与 XSD 的区别
+
+## 1.1 DTD
+
+> 老艿艿：因为一些胖友，可能没了解过 DTD 和 XSD ，所以本小节先做一个科普。
+
+DTD(Document Type Definition)，即文档类型定义，为 XML 文件的验证机制，属于 XML 文件中组成的一部分。DTD 是一种保证 XML 文档格式正确的有效验证方式，它定义了相关 XML 文档的元素、属性、排列方式、元素的内容类型以及元素的层次结构。其实 DTD 就相当于 XML 中的 “词汇”和“语法”，我们可以通过比较 XML 文件和 DTD 文件 来看文档是否符合规范，元素和标签使用是否正确。
+
+要在 Spring 中使用 DTD，需要在 Spring XML 文件头部声明：
+
+```
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE beans PUBLIC  "-//SPRING//DTD BEAN//EN"  "http://www.springframework.org/dtd/spring-beans.dtd">
+```
+
+DTD 在一定的阶段推动了 XML 的发展，但是它本身存在着一些**缺陷**：
+
+1. 它没有使用 XML 格式，而是自己定义了一套格式，相对解析器的重用性较差；而且 DTD 的构建和访问没有标准的编程接口，因而解析器很难简单的解析 DTD 文档。
+2. DTD 对元素的类型限制较少；同时其他的约束力也叫弱。
+3. DTD 扩展能力较差。
+4. 基于正则表达式的 DTD 文档的描述能力有限。
+
+## 1.2 XSD
+
+针对 DTD 的缺陷，W3C 在 2001 年推出 XSD。XSD（XML Schemas Definition）即 XML Schema 语言。XML Schema 本身就是一个 XML文档，使用的是 XML 语法，因此可以很方便的解析 XSD 文档。相对于 DTD，XSD 具有如下**优势**：
+
+1. XML Schema 基于 XML ，没有专门的语法。
+2. XML Schema 可以象其他 XML 文件一样解析和处理。
+3. XML Schema 比 DTD 提供了更丰富的数据类型。
+4. XML Schema 提供可扩充的数据模型。
+5. XML Schema 支持综合命名空间。
+6. XML Schema 支持属性组。
+
+# 2. getValidationModeForResource
+
+```
+// XmlBeanDefinitionReader.java
+
+// 禁用验证模式
+public static final int VALIDATION_NONE = XmlValidationModeDetector.VALIDATION_NONE;
+// 自动获取验证模式
+public static final int VALIDATION_AUTO = XmlValidationModeDetector.VALIDATION_AUTO;
+// DTD 验证模式
+public static final int VALIDATION_DTD = XmlValidationModeDetector.VALIDATION_DTD;
+// XSD 验证模式
+public static final int VALIDATION_XSD = XmlValidationModeDetector.VALIDATION_XSD;
+	
+/**
+ * 验证模式。默认为自动模式。
+ */
+private int validationMode = VALIDATION_AUTO;
+	
+protected int getValidationModeForResource(Resource resource) {
+	// <1> 获取指定的验证模式
+	int validationModeToUse = getValidationMode();
+	// 首先，如果手动指定，则直接返回
+	if (validationModeToUse != VALIDATION_AUTO) {
+		return validationModeToUse;
+	}
+	// 其次，自动获取验证模式
+	int detectedMode = detectValidationMode(resource);
+	if (detectedMode != VALIDATION_AUTO) {
+		return detectedMode;
+	}
+	// 最后，使用 VALIDATION_XSD 做为默认
+	// Hmm, we didn't get a clear indication... Let's assume XSD,
+	// since apparently no DTD declaration has been found up until
+	// detection stopped (before finding the document's root tag).
+	return VALIDATION_XSD;
+}
+```
+
+- `<1>` 处，调用 `#getValidationMode()` 方法，获取指定的验证模式( `validationMode` )。如果有手动指定，则直接返回。另外，对对于 `validationMode` 属性的设置和获得的代码，代码如下：
+
+  ```
+  public void setValidationMode(int validationMode) {
+  	this.validationMode = validationMode;
+  }
+  
+  public int getValidationMode() {
+  	return this.validationMode;
+  }
+  ```
+
+- `<2>` 处，调用 `#detectValidationMode(Resource resource)` 方法，自动获取验证模式。代码如下：
+
+  ```
+    /**
+     * XML 验证模式探测器
+     */
+    private final XmlValidationModeDetector validationModeDetector = new XmlValidationModeDetector();
+  	
+    protected int detectValidationMode(Resource resource) {
+  // 不可读，抛出 BeanDefinitionStoreException 异常
+    	if (resource.isOpen()) {
+    		throw new BeanDefinitionStoreException(
+    				"Passed-in Resource [" + resource + "] contains an open stream: " +
+    				"cannot determine validation mode automatically. Either pass in a Resource " +
+    				"that is able to create fresh streams, or explicitly specify the validationMode " +
+    				"on your XmlBeanDefinitionReader instance.");
+    	}
+    
+    	// 打开 InputStream 流
+    	InputStream inputStream;
+    	try {
+    		inputStream = resource.getInputStream();
+    	} catch (IOException ex) {
+    		throw new BeanDefinitionStoreException(
+    				"Unable to determine validation mode for [" + resource + "]: cannot open InputStream. " +
+    				"Did you attempt to load directly from a SAX InputSource without specifying the " +
+    				"validationMode on your XmlBeanDefinitionReader instance?", ex);
+    	}
+    
+    	// <x> 获取相应的验证模式
+    	try {
+    		return this.validationModeDetector.detectValidationMode(inputStream);
+    	} catch (IOException ex) {
+    		throw new BeanDefinitionStoreException("Unable to determine validation mode for [" +
+    				resource + "]: an error occurred whilst reading from the InputStream.", ex);
+    	}
+    }
+  ```
+
+  - 核心在于 `<x>` 处，调用 `XmlValidationModeDetector#detectValidationMode(InputStream inputStream)` 方法，获取相应的验证模式。详细解析，见 [「3. XmlValidationModeDetector」](https://svip.iocoder.cn/Spring/IoC-Validation-Mode-For-Resource/#) 中。
+
+- `<3>` 处，使用 `VALIDATION_XSD` 做为默认。
+
+# 3. XmlValidationModeDetector
+
+`org.springframework.util.xml.XmlValidationModeDetector` ，XML 验证模式探测器。
+
+```
+public int detectValidationMode(InputStream inputStream) throws IOException {
+    // Peek into the file to look for DOCTYPE.
+    BufferedReader reader = new BufferedReader(new InputStreamReader(inputStream));
+    try {
+        // 是否为 DTD 校验模式。默认为，非 DTD 模式，即 XSD 模式
+        boolean isDtdValidated = false;
+        String content;
+        // <0> 循环，逐行读取 XML 文件的内容
+        while ((content = reader.readLine()) != null) {
+            content = consumeCommentTokens(content);
+            // 跳过，如果是注释，或者
+            if (this.inComment || !StringUtils.hasText(content)) {
+                continue;
+            }
+            // <1> 包含 DOCTYPE 为 DTD 模式
+            if (hasDoctype(content)) {
+                isDtdValidated = true;
+                break;
+            }
+            // <2>  hasOpeningTag 方法会校验，如果这一行有 < ，并且 < 后面跟着的是字母，则返回 true 。
+            if (hasOpeningTag(content)) {
+                // End of meaningful data...
+                break;
+            }
+        }
+        // 返回 VALIDATION_DTD or VALIDATION_XSD 模式
+        return (isDtdValidated ? VALIDATION_DTD : VALIDATION_XSD);
+    } catch (CharConversionException ex) {
+           
+        // <3> 返回 VALIDATION_AUTO 模式
+        // Choked on some character encoding...
+        // Leave the decision up to the caller.
+        return VALIDATION_AUTO;
+    } finally {
+        reader.close();
+    }
+}
+```
+
+- `<0`> 处，从代码中看，主要是通过读取 XML 文件的内容，来进行自动判断。
+
+- `<1>` 处，调用 `#hasDoctype(String content)` 方法，判断内容中如果包含有 `"DOCTYPE`“ ，则为 DTD 验证模式。代码如下：
+
+  ```
+  /**
+   * The token in a XML document that declares the DTD to use for validation
+   * and thus that DTD validation is being used.
+   */
+  private static final String DOCTYPE = "DOCTYPE";
+  
+  private boolean hasDoctype(String content) {
+  	return content.contains(DOCTYPE);
+  }
+  ```
+
+- `<2>` 处，调用 `#hasOpeningTag(String content)` 方法，判断如果这一行包含 `<` ，并且 `<` 紧跟着的是字幕，则为 XSD 验证模式。代码如下：
+
+  ```
+  /**
+   * Does the supplied content contain an XML opening tag. If the parse state is currently
+   * in an XML comment then this method always returns false. It is expected that all comment
+   * tokens will have consumed for the supplied content before passing the remainder to this method.
+   */
+  private boolean hasOpeningTag(String content) {
+  	if (this.inComment) {
+  		return false;
+  	}
+  	int openTagIndex = content.indexOf('<');
+  	return (openTagIndex > -1 // < 存在
+              && (content.length() > openTagIndex + 1) // < 后面还有内容
+              && Character.isLetter(content.charAt(openTagIndex + 1))); // < 后面的内容是字幕
+  }
+  ```
+
+- `<3>` 处，如果发生 CharConversionException 异常，则为 `VALIDATION_AUTO` 模式。
+
+- 关于 `#consumeCommentTokens(String content)` 方法，代码比较复杂。感兴趣的胖友可以看看。代码如下：
+
+  ```
+  /**
+   * The token that indicates the start of an XML comment.
+   */
+  private static final String START_COMMENT = "<!--";
+  
+  /**
+   * The token that indicates the end of an XML comment.
+   */
+  private static final String END_COMMENT = "-->";
+  
+  /**
+   * Consumes all the leading comment data in the given String and returns the remaining content, which
+   * may be empty since the supplied content might be all comment data. For our purposes it is only important
+   * to strip leading comment content on a line since the first piece of non comment content will be either
+   * the DOCTYPE declaration or the root element of the document.
+   */
+  @Nullable
+  private String consumeCommentTokens(String line) {
+  	// 非注释
+  	if (!line.contains(START_COMMENT) && !line.contains(END_COMMENT)) {
+  		return line;
+  	}
+  	String currLine = line;
+  	while ((currLine = consume(currLine)) != null) {
+  		if (!this.inComment && !currLine.trim().startsWith(START_COMMENT)) {
+  			return currLine;
+  		}
+  	}
+  	return null;
+  }
+  
+  /**
+   * Consume the next comment token, update the "inComment" flag
+   * and return the remaining content.
+   */
+  @Nullable
+  private String consume(String line) {
+  	int index = (this.inComment ? endComment(line) : startComment(line));
+  	return (index == -1 ? null : line.substring(index));
+  }
+  
+  /**
+   * Try to consume the {@link #START_COMMENT} token.
+   * @see #commentToken(String, String, boolean)
+   */
+  private int startComment(String line) {
+  	return commentToken(line, START_COMMENT, true);
+  }
+  
+  private int endComment(String line) {
+  	return commentToken(line, END_COMMENT, false);
+  }
+  
+  /**
+   * Try to consume the supplied token against the supplied content and update the
+   * in comment parse state to the supplied value. Returns the index into the content
+   * which is after the token or -1 if the token is not found.
+   */
+  private int commentToken(String line, String token, boolean inCommentIfPresent) {
+  	int index = line.indexOf(token);
+  	if (index > - 1) {
+  		this.inComment = inCommentIfPresent;
+  	}
+  	return (index == -1 ? index : index + token.length());
+  }
+  ```
+
+  - 😈 反正老艿艿没细看。哈哈哈哈。如果真看，如下两篇文章，有一定的辅助：
+    - [《spring源码（六）–XmlValidationModeDetector（获取xml文档校验模式）》](https://blog.csdn.net/ljz2016/article/details/82686884)
+    - [《XmlValidationModeDetector》](https://my.oschina.net/u/3579120/blog/1532852)
+
+# 666. 彩蛋
+
+好了，XML 文件的验证模式分析完毕。下篇，我们来分析 `#doLoadBeanDefinitions(InputSource inputSource, Resource resource)` 方法的**第 2 个**步骤：获取 Document 实例。
\ No newline at end of file
diff --git a/spring/09-Spring-IoC 之获取 Document 对象.assets/08e5f8a505505def17e84becd4f0dbf9.png b/spring/09-Spring-IoC 之获取 Document 对象.assets/08e5f8a505505def17e84becd4f0dbf9.png
new file mode 100644
index 0000000..e5e07f7
Binary files /dev/null and b/spring/09-Spring-IoC 之获取 Document 对象.assets/08e5f8a505505def17e84becd4f0dbf9.png differ
diff --git a/spring/09-Spring-IoC 之获取 Document 对象.assets/4dba22abb6ce4bc1a7721afb2cb53567.png b/spring/09-Spring-IoC 之获取 Document 对象.assets/4dba22abb6ce4bc1a7721afb2cb53567.png
new file mode 100644
index 0000000..7d189b3
Binary files /dev/null and b/spring/09-Spring-IoC 之获取 Document 对象.assets/4dba22abb6ce4bc1a7721afb2cb53567.png differ
diff --git a/spring/09-Spring-IoC 之获取 Document 对象.assets/741da1d13906154d36f02fa5113432fd.png b/spring/09-Spring-IoC 之获取 Document 对象.assets/741da1d13906154d36f02fa5113432fd.png
new file mode 100644
index 0000000..9c12826
Binary files /dev/null and b/spring/09-Spring-IoC 之获取 Document 对象.assets/741da1d13906154d36f02fa5113432fd.png differ
diff --git a/spring/09-Spring-IoC 之获取 Document 对象.assets/882e730ac463e3007c5f3c5cde8380bc.png b/spring/09-Spring-IoC 之获取 Document 对象.assets/882e730ac463e3007c5f3c5cde8380bc.png
new file mode 100644
index 0000000..30ddddb
Binary files /dev/null and b/spring/09-Spring-IoC 之获取 Document 对象.assets/882e730ac463e3007c5f3c5cde8380bc.png differ
diff --git a/spring/09-Spring-IoC 之获取 Document 对象.assets/8f77d23019c10f4ac026968ce19067ef.png b/spring/09-Spring-IoC 之获取 Document 对象.assets/8f77d23019c10f4ac026968ce19067ef.png
new file mode 100644
index 0000000..db3d6d8
Binary files /dev/null and b/spring/09-Spring-IoC 之获取 Document 对象.assets/8f77d23019c10f4ac026968ce19067ef.png differ
diff --git a/spring/09-Spring-IoC 之获取 Document 对象.md b/spring/09-Spring-IoC 之获取 Document 对象.md
new file mode 100644
index 0000000..27e491d
--- /dev/null
+++ b/spring/09-Spring-IoC 之获取 Document 对象.md	
@@ -0,0 +1,576 @@
+# 【死磕 Spring】—— IoC 之获取 Document 对象
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=2695 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+在 `XmlBeanDefinitionReader#doLoadDocument(InputSource inputSource, Resource resource)` 方法，中做了两件事情：
+
+- 调用
+
+   
+
+  ```
+  #getValidationModeForResource(Resource resource)
+  ```
+
+   
+
+  方法，获取指定资源（xml）的
+
+  验证模式
+
+  。
+
+  - 上篇博客，我们已经详细解析。
+
+- 调用
+
+   
+
+  ```
+  DocumentLoader#loadDocument(InputSource inputSource, EntityResolver entityResolver, ErrorHandler errorHandler, int validationMode, boolean namespaceAware)
+  ```
+
+   
+
+  方法，获取 XML Document 实例。
+
+  - 本篇博客，我们来详细解析。
+
+# 1. DocumentLoader
+
+获取 Document 的策略，由接口 `org.springframework.beans.factory.xml.DocumentLoader` 定义。代码如下：
+
+> FROM 《Spring 源码深度解析》P16 页
+>
+> 定义从资源文件加载到转换为 Document 的功能。
+
+```
+public interface DocumentLoader {
+
+	Document loadDocument(
+			InputSource inputSource, EntityResolver entityResolver,
+			ErrorHandler errorHandler, int validationMode, boolean namespaceAware)
+			throws Exception;
+
+}
+```
+
+- `inputSource` 方法参数，加载 Document 的 Resource 资源。
+- `entityResolver` 方法参数，解析文件的解析器。
+- `errorHandler` 方法参数，处理加载 Document 对象的过程的错误。
+- `validationMode` 方法参数，验证模式。
+- `namespaceAware` 方法参数，命名空间支持。如果要提供对 XML 名称空间的支持，则需要值为 `true` 。
+
+## 1.1 DefaultDocumentLoader
+
+该方法由 DocumentLoader 的默认实现类 `org.springframework.beans.factory.xml.DefaultDocumentLoader` 实现。代码如下：
+
+```
+/**
+ * Load the {@link Document} at the supplied {@link InputSource} using the standard JAXP-configured
+ * XML parser.
+ */
+@Override
+public Document loadDocument(InputSource inputSource, EntityResolver entityResolver,
+		ErrorHandler errorHandler, int validationMode, boolean namespaceAware) throws Exception {
+	// <1> 创建 DocumentBuilderFactory
+	DocumentBuilderFactory factory = createDocumentBuilderFactory(validationMode, namespaceAware);
+	if (logger.isTraceEnabled()) {
+		logger.trace("Using JAXP provider [" + factory.getClass().getName() + "]");
+	}
+	// <2> 创建 DocumentBuilder
+	DocumentBuilder builder = createDocumentBuilder(factory, entityResolver, errorHandler);
+	// <3> 解析 XML InputSource 返回 Document 对象
+	return builder.parse(inputSource);
+}
+```
+
+- 首先，调用 #`createDocumentBuilderFactory(...)` 方法，创建 `javax.xml.parsers.DocumentBuilderFactory` 对象。代码如下：
+
+  ```
+  /**
+   * JAXP attribute used to configure the schema language for validation.
+   */
+  private static final String SCHEMA_LANGUAGE_ATTRIBUTE = "http://java.sun.com/xml/jaxp/properties/schemaLanguage";
+  /**
+   * JAXP attribute value indicating the XSD schema language.
+   */
+  private static final String XSD_SCHEMA_LANGUAGE = "http://www.w3.org/2001/XMLSchema";
+  protected DocumentBuilderFactory createDocumentBuilderFactory(int validationMode, boolean namespaceAware)
+          throws ParserConfigurationException {
+      // 创建 DocumentBuilderFactory
+      DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
+      factory.setNamespaceAware(namespaceAware); // 设置命名空间支持
+      if (validationMode != XmlValidationModeDetector.VALIDATION_NONE) {
+          factory.setValidating(true); // 开启校验
+          // XSD 模式下，设置 factory 的属性
+          if (validationMode == XmlValidationModeDetector.VALIDATION_XSD) {
+              // Enforce namespace aware for XSD...
+              factory.setNamespaceAware(true); // XSD 模式下，强制设置命名空间支持
+              // 设置 SCHEMA_LANGUAGE_ATTRIBUTE
+              try {
+                  factory.setAttribute(SCHEMA_LANGUAGE_ATTRIBUTE, XSD_SCHEMA_LANGUAGE);
+              } catch (IllegalArgumentException ex) {
+                  ParserConfigurationException pcex = new ParserConfigurationException(
+                          "Unable to validate using XSD: Your JAXP provider [" + factory +
+                          "] does not support XML Schema. Are you running on Java 1.4 with Apache Crimson? " +
+                          "Upgrade to Apache Xerces (or Java 1.5) for full XSD support.");
+                  pcex.initCause(ex);
+                  throw pcex;
+              }
+          }
+      }
+      return factory;
+  }
+  ```
+
+- 然后，调用 `#createDocumentBuilder(DocumentBuilderFactory factory, EntityResolver entityResolver,ErrorHandler errorHandler)` 方法，创建 `javax.xml.parsers.DocumentBuilder` 对象。代码如下：
+
+  ```
+  protected DocumentBuilder createDocumentBuilder(DocumentBuilderFactory factory,
+  		@Nullable EntityResolver entityResolver, @Nullable ErrorHandler errorHandler)
+  		throws ParserConfigurationException {
+  	// 创建 DocumentBuilder 对象
+  	DocumentBuilder docBuilder = factory.newDocumentBuilder();
+  	// <x> 设置 EntityResolver 属性
+  	if (entityResolver != null) {
+  		docBuilder.setEntityResolver(entityResolver);
+  	}
+  	// 设置 ErrorHandler 属性
+  	if (errorHandler != null) {
+  		docBuilder.setErrorHandler(errorHandler);
+  	}
+  	return docBuilder;
+  }
+  ```
+
+  - 在 `<x>` 处，设置 DocumentBuilder 的 **EntityResolver** 属性。关于它，在 [「2. EntityResolver」](https://svip.iocoder.cn/Spring/IoC-load-Document/#) 会详细解析。
+
+- 最后，调用 `DocumentBuilder#parse(InputSource)` 方法，解析 InputSource ，返回 Document 对象。
+
+# 2. EntityResolver
+
+通过 `DocumentLoader#loadDocument(...)` 方法来获取 Document 对象时，有一个方法参数 `entityResolver` 。该参数是通过 `XmlBeanDefinitionReader#getEntityResolver()` 方法来获取的。代码如下：
+
+> `#getEntityResolver()` 方法，返回指定的解析器，如果没有指定，则构造一个未指定的默认解析器。
+
+```
+// XmlBeanDefinitionReader.java
+
+/**
+ * EntityResolver 解析器
+ */
+@Nullable
+private EntityResolver entityResolver;
+
+protected EntityResolver getEntityResolver() {
+	if (this.entityResolver == null) {
+		// Determine default EntityResolver to use.
+		ResourceLoader resourceLoader = getResourceLoader();
+		if (resourceLoader != null) {
+			this.entityResolver = new ResourceEntityResolver(resourceLoader);
+		} else {
+			this.entityResolver = new DelegatingEntityResolver(getBeanClassLoader());
+		}
+	}
+	return this.entityResolver;
+}
+```
+
+- 如果 ResourceLoader 不为 `null`，则根据指定的 ResourceLoader 创建一个 ResourceEntityResolver 对象。
+- 如果 ResourceLoader 为 `null` ，则创建 一个 DelegatingEntityResolver 对象。该 Resolver 委托给默认的 BeansDtdResolver 和 PluggableSchemaResolver 。
+
+## 2.1 子类
+
+上面的方法，一共涉及**四个** EntityResolver 的子类：
+
+- `org.springframework.beans.factory.xm.BeansDtdResolver` ：实现 EntityResolver 接口，Spring Bean dtd 解码器，用来从 classpath 或者 jar 文件中加载 dtd 。部分代码如下：
+
+  ```
+  private static final String DTD_EXTENSION = ".dtd";
+  
+  private static final String DTD_NAME = "spring-beans";
+  ```
+
+- `org.springframework.beans.factory.xml.PluggableSchemaResolver` ，实现 EntityResolver 接口，读取 classpath 下的所有 `"META-INF/spring.schemas"` 成一个 namespaceURI 与 Schema 文件地址的 map 。代码如下：
+
+  ```
+  /**
+   * The location of the file that defines schema mappings.
+   * Can be present in multiple JAR files.
+   *
+   * 默认 {@link #schemaMappingsLocation} 地址
+   */
+  public static final String DEFAULT_SCHEMA_MAPPINGS_LOCATION = "META-INF/spring.schemas";
+  
+  @Nullable
+  private final ClassLoader classLoader;
+  
+  /**
+   * Schema 文件地址
+   */
+  private final String schemaMappingsLocation;
+  
+  /** Stores the mapping of schema URL -> local schema path. */
+  @Nullable
+  private volatile Map<String, String> schemaMappings; // namespaceURI 与 Schema 文件地址的映射集合
+  ```
+
+- `org.springframework.beans.factory.xml.DelegatingEntityResolver` ：实现 EntityResolver 接口，分别代理 dtd 的 BeansDtdResolver 和 xml schemas 的 PluggableSchemaResolver 。代码如下：
+
+  ```
+  /** Suffix for DTD files. */
+  public static final String DTD_SUFFIX = ".dtd";
+  
+  /** Suffix for schema definition files. */
+  public static final String XSD_SUFFIX = ".xsd";
+  
+  private final EntityResolver dtdResolver;
+  
+  private final EntityResolver schemaResolver;
+  
+  // 默认
+  public DelegatingEntityResolver(@Nullable ClassLoader classLoader) {
+  	this.dtdResolver = new BeansDtdResolver();
+  	this.schemaResolver = new PluggableSchemaResolver(classLoader);
+  }
+  
+  // 自定义
+  public DelegatingEntityResolver(EntityResolver dtdResolver, EntityResolver schemaResolver) {
+  	Assert.notNull(dtdResolver, "'dtdResolver' is required");
+  	Assert.notNull(schemaResolver, "'schemaResolver' is required");
+  	this.dtdResolver = dtdResolver;
+  	this.schemaResolver = schemaResolver;
+  }
+  ```
+
+- `org.springframework.beans.factory.xml.ResourceEntityResolver` ：继承自 DelegatingEntityResolver 类，通过 ResourceLoader 来解析实体的引用。代码如下：
+
+  ```
+  private final ResourceLoader resourceLoader;
+  
+  public ResourceEntityResolver(ResourceLoader resourceLoader) {
+  	super(resourceLoader.getClassLoader());
+  	this.resourceLoader = resourceLoader;
+  }
+  ```
+
+## 2.2 作用
+
+> EntityResolver 的作用就是，通过实现它，应用可以自定义如何**寻找**【验证文件】的逻辑。
+
+------
+
+> FROM 《Spring 源码深度解析》
+>
+> 在 loadDocument 方法中涉及一个参数 EntityResolver ，何为EntityResolver？官网这样解释：如果 SAX 应用程序需要实现自定义处理外部实体，则必须实现此接口并使用 setEntityResolver 方法向SAX 驱动器注册一个实例。也就是说，对于解析一个XML，SAX 首先读取该 XML 文档上的声明，根据声明去寻找相应的 DTD 定义，以便对文档进行一个验证。默认的寻找规则，即通过网络（实现上就是声明的DTD的URI地址）来下载相应的DTD声明，并进行认证。下载的过程是一个漫长的过程，而且当网络中断或不可用时，这里会报错，就是因为相应的DTD声明没有被找到的原因。
+>
+> EntityResolver 的作用是项目本身就可以提供一个如何寻找 DTD 声明的方法，即由程序来实现寻找 DTD 声明的过程，比如我们将 DTD 文件放到项目中某处，在实现时直接将此文档读取并返回给 SAX 即可。这样就避免了通过网络来寻找相应的声明。
+
+`org.xml.sax.EntityResolver` 接口，代码如下：
+
+```
+public interface EntityResolver {
+
+    public abstract InputSource resolveEntity (String publicId, String systemId)
+        throws SAXException, IOException;
+
+}
+```
+
+接口方法接收两个参数 `publicId` 和 `systemId` ，并返回 InputSource 对象。两个参数声明如下：
+
+- `publicId` ：被引用的外部实体的公共标识符，如果没有提供，则返回 `null` 。
+- `systemId` ：被引用的外部实体的系统标识符。
+
+这两个参数的实际内容和具体的验证模式的关系如下：
+
+- XSD 验证模式
+  - publicId：null
+  - systemId：http://www.springframework.org/schema/beans/spring-beans.xsd
+  - [![XSD 验证模式](09-Spring-IoC 之获取 Document 对象.assets/08e5f8a505505def17e84becd4f0dbf9.png)](http://static.iocoder.cn/08e5f8a505505def17e84becd4f0dbf9)XSD 验证模式
+- DTD 验证模式
+  - publicId：-//SPRING//DTD BEAN 2.0//EN
+  - systemId：http://www.springframework.org/dtd/spring-beans.dtd
+  - [![DTD 验证模式](09-Spring-IoC 之获取 Document 对象.assets/8f77d23019c10f4ac026968ce19067ef.png)](http://static.iocoder.cn/8f77d23019c10f4ac026968ce19067ef)DTD 验证模式
+
+## 2.3 DelegatingEntityResolver
+
+我们知道在 Spring 中使用 DelegatingEntityResolver 为 EntityResolver 的实现类。`#resolveEntity(String publicId, String systemId)` 方法，实现如下：
+
+```
+@Override
+@Nullable
+public InputSource resolveEntity(String publicId, @Nullable String systemId) throws SAXException, IOException {
+	if (systemId != null) {
+		// DTD 模式
+		if (systemId.endsWith(DTD_SUFFIX)) {
+			return this.dtdResolver.resolveEntity(publicId, systemId);
+		// XSD 模式
+		} else if (systemId.endsWith(XSD_SUFFIX)) {
+			return this.schemaResolver.resolveEntity(publicId, systemId);
+		}
+	}
+	return null;
+}
+```
+
+- 如果是 DTD 验证模式，则使用 BeansDtdResolver 来进行解析
+- 如果是 XSD 验证模式，则使用 PluggableSchemaResolver 来进行解析。
+
+## 2.4 BeansDtdResolver
+
+BeansDtdResolver 的解析过程，代码如下：
+
+```
+/**
+ * DTD 文件的后缀
+ */
+private static final String DTD_EXTENSION = ".dtd";
+/**
+ * Spring Bean DTD 的文件名
+ */
+private static final String DTD_NAME = "spring-beans";
+
+@Override
+@Nullable
+public InputSource resolveEntity(String publicId, @Nullable String systemId) throws IOException {
+    if (logger.isTraceEnabled()) {
+        logger.trace("Trying to resolve XML entity with public ID [" + publicId +
+                "] and system ID [" + systemId + "]");
+    }
+    // 必须以 .dtd 结尾
+    if (systemId != null && systemId.endsWith(DTD_EXTENSION)) {
+        // 获取最后一个 / 的位置
+        int lastPathSeparator = systemId.lastIndexOf('/');
+        // 获取 spring-beans 的位置
+        int dtdNameStart = systemId.indexOf(DTD_NAME, lastPathSeparator);
+        if (dtdNameStart != -1) { // 找到
+            String dtdFile = DTD_NAME + DTD_EXTENSION;
+            if (logger.isTraceEnabled()) {
+                logger.trace("Trying to locate [" + dtdFile + "] in Spring jar on classpath");
+            }
+            try {
+                // 创建 ClassPathResource 对象
+                Resource resource = new ClassPathResource(dtdFile, getClass());
+                // 创建 InputSource 对象，并设置 publicId、systemId 属性
+                InputSource source = new InputSource(resource.getInputStream());
+                source.setPublicId(publicId);
+                source.setSystemId(systemId);
+                if (logger.isTraceEnabled()) {
+                    logger.trace("Found beans DTD [" + systemId + "] in classpath: " + dtdFile);
+                }
+                return source;
+            }
+            catch (IOException ex) {
+                if (logger.isDebugEnabled()) {
+                    logger.debug("Could not resolve beans DTD [" + systemId + "]: not found in classpath", ex);
+                }
+            }
+        }
+    }
+
+    // 使用默认行为，从网络上下载
+    // Use the default behavior -> download from website or wherever.
+    return null;
+}
+```
+
+从上面的代码中，我们可以看到，加载 DTD 类型的 `BeansDtdResolver#resolveEntity(...)` 过程，只是对 `systemId` 进行了简单的校验（从最后一个 / 开始，内容中是否包含 `spring-beans`），然后构造一个 InputSource 对象，并设置 `publicId`、`systemId` 属性，然后返回。
+
+## 2.5 PluggableSchemaResolver
+
+PluggableSchemaResolver 的解析过程，代码如下:
+
+```
+@Nullable
+private final ClassLoader classLoader;
+
+/**
+ * Schema 文件地址
+ */
+private final String schemaMappingsLocation;
+
+/** Stores the mapping of schema URL -> local schema path. */
+@Nullable
+private volatile Map<String, String> schemaMappings; // namespaceURI 与 Schema 文件地址的映射集合
+
+@Override
+@Nullable
+public InputSource resolveEntity(String publicId, @Nullable String systemId) throws IOException {
+    if (logger.isTraceEnabled()) {
+        logger.trace("Trying to resolve XML entity with public id [" + publicId +
+                "] and system id [" + systemId + "]");
+    }
+
+    if (systemId != null) {
+        // 获得 Resource 所在位置
+        String resourceLocation = getSchemaMappings().get(systemId);
+        if (resourceLocation != null) {
+            // 创建 ClassPathResource
+            Resource resource = new ClassPathResource(resourceLocation, this.classLoader);
+            try {
+                // 创建 InputSource 对象，并设置 publicId、systemId 属性
+                InputSource source = new InputSource(resource.getInputStream());
+                source.setPublicId(publicId);
+                source.setSystemId(systemId);
+                if (logger.isTraceEnabled()) {
+                    logger.trace("Found XML schema [" + systemId + "] in classpath: " + resourceLocation);
+                }
+                return source;
+            }
+            catch (FileNotFoundException ex) {
+                if (logger.isDebugEnabled()) {
+                    logger.debug("Could not find XML schema [" + systemId + "]: " + resource, ex);
+                }
+            }
+        }
+    }
+    return null;
+}
+```
+
+- 首先调用 `#getSchemaMappings()` 方法，获取一个映射表(systemId 与其在本地的对照关系)。代码如下：
+
+  ```
+  private Map<String, String> getSchemaMappings() {
+      Map<String, String> schemaMappings = this.schemaMappings;
+      // 双重检查锁，实现 schemaMappings 单例
+      if (schemaMappings == null) {
+          synchronized (this) {
+              schemaMappings = this.schemaMappings;
+              if (schemaMappings == null) {
+                  if (logger.isTraceEnabled()) {
+                      logger.trace("Loading schema mappings from [" + this.schemaMappingsLocation + "]");
+                  }
+                  try {
+                      // 以 Properties 的方式，读取 schemaMappingsLocation
+                      Properties mappings = PropertiesLoaderUtils.loadAllProperties(this.schemaMappingsLocation, this.classLoader);
+                      if (logger.isTraceEnabled()) {
+                          logger.trace("Loaded schema mappings: " + mappings);
+                      }
+                      // 将 mappings 初始化到 schemaMappings 中
+                      schemaMappings = new ConcurrentHashMap<>(mappings.size());
+                      CollectionUtils.mergePropertiesIntoMap(mappings, schemaMappings);
+                      this.schemaMappings = schemaMappings;
+                  } catch (IOException ex) {
+                      throw new IllegalStateException(
+                              "Unable to load schema mappings from location [" + this.schemaMappingsLocation + "]", ex);
+                  }
+              }
+          }
+      }
+      return schemaMappings;
+  }
+  ```
+
+  - 映射表如下（**部分**）:[![映射表](09-Spring-IoC 之获取 Document 对象.assets/4dba22abb6ce4bc1a7721afb2cb53567.png)](http://static.iocoder.cn/4dba22abb6ce4bc1a7721afb2cb53567)映射表
+
+- 然后，根据传入的 `systemId` 获取该 `systemId` 在本地的路径 `resourceLocation` 。
+
+- 最后，根据 `resourceLocation` ，构造 InputSource 对象。
+
+## 2.6 ResourceEntityResolver
+
+ResourceEntityResolver 的解析过程，代码如下:
+
+```
+private final ResourceLoader resourceLoader;
+
+@Override
+@Nullable
+public InputSource resolveEntity(String publicId, @Nullable String systemId) throws SAXException, IOException {
+    // 调用父类的方法，进行解析
+    InputSource source = super.resolveEntity(publicId, systemId);
+    // 解析失败，resourceLoader 进行解析
+    if (source == null && systemId != null) {
+        // 获得 resourcePath ，即 Resource 资源地址
+        String resourcePath = null;
+        try {
+            String decodedSystemId = URLDecoder.decode(systemId, "UTF-8"); // 使用 UTF-8 ，解码 systemId
+            String givenUrl = new URL(decodedSystemId).toString(); // 转换成 URL 字符串
+            // 解析文件资源的相对路径（相对于系统根路径）
+            String systemRootUrl = new File("").toURI().toURL().toString();
+            // Try relative to resource base if currently in system root.
+            if (givenUrl.startsWith(systemRootUrl)) {
+                resourcePath = givenUrl.substring(systemRootUrl.length());
+            }
+        } catch (Exception ex) {
+            // Typically a MalformedURLException or AccessControlException.
+            if (logger.isDebugEnabled()) {
+                logger.debug("Could not resolve XML entity [" + systemId + "] against system root URL", ex);
+            }
+            // No URL (or no resolvable URL) -> try relative to resource base.
+            resourcePath = systemId;
+        }
+        if (resourcePath != null) {
+            if (logger.isTraceEnabled()) {
+                logger.trace("Trying to locate XML entity [" + systemId + "] as resource [" + resourcePath + "]");
+            }
+            // 获得 Resource 资源
+            Resource resource = this.resourceLoader.getResource(resourcePath);
+            // 创建 InputSource 对象
+            source = new InputSource(resource.getInputStream());
+            // 设置 publicId 和 systemId 属性
+            source.setPublicId(publicId);
+            source.setSystemId(systemId);
+            if (logger.isDebugEnabled()) {
+                logger.debug("Found XML entity [" + systemId + "]: " + resource);
+            }
+        }
+    }
+    return source;
+}
+```
+
+- 首先，调用**父类**的方法，进行解析。
+- 如果失败，使用 `resourceLoader` ，尝试读取 `systemId` 对应的 Resource 资源。
+
+## 2.7 自定义 EntityResolver
+
+> 老艿艿：本小节，为**选读**内容。
+
+`#getEntityResolver()` 方法返回 EntityResolver 对象。那么怎么进行自定义 EntityResolver 呢?
+
+> If a SAX application needs to implement customized handling for external entities, it must implement this interface and register an instance with the SAX driver using the setEntityResolver method.
+>
+> 就是说：如果 SAX 应用程序需要实现自定义处理外部实体，则必须实现此接口，并使用 `#setEntityResolver(EntityResolver entityResolver)` 方法，向 SAX 驱动器注册一个 EntityResolver 实例。
+
+示例如下：
+
+```
+public class MyResolver implements EntityResolver {
+
+    @Override
+    public InputSource resolveEntity(String publicId, String systemId) {
+        if (systemId.equals("http://www.myhost.com/today")) {
+            MyReader reader = new MyReader();
+            return new InputSource(reader);
+        } else {
+            // use the default behaviour
+            return null;
+        }
+    }
+
+}
+```
+
+我们首先将 `"spring-student.xml"` 文件中的 XSD 声明的地址改掉，如下：
+
+[![spring-student.xml](09-Spring-IoC 之获取 Document 对象.assets/882e730ac463e3007c5f3c5cde8380bc.png)](http://static.iocoder.cn/882e730ac463e3007c5f3c5cde8380bc)spring-student.xml
+
+如果我们再次运行，则会报如下错误：
+
+[![报错](09-Spring-IoC 之获取 Document 对象.assets/741da1d13906154d36f02fa5113432fd.png)](http://static.iocoder.cn/741da1d13906154d36f02fa5113432fd)报错
+
+从上面的错误可以看到，是在进行文档验证时，无法根据声明找到 XSD 验证文件而导致无法进行 XML 文件验证。在 [《【死磕 Spring】—— IoC 之获取验证模型》](http://svip.iocoder.cn/Spring/IoC-Validation-Mode-For-Resource) 中讲到，如果要解析一个 XML 文件，SAX 首先会读取该 XML 文档上的声明，然后根据声明去寻找相应的 DTD 定义，以便对文档进行验证。**默认的加载规则是通过网络方式下载验证文件**，而在实际生产环境中我们会遇到网络中断或者不可用状态，那么就应用就会因为无法下载验证文件而报错。
+
+# 666. 彩蛋
+
+是不是看到此处，有点懵逼，不是说好了分享**获取 Document 对象**，结果内容主要是 EntityResolver 呢？因为，从 XML 中获取 Document 对象，已经有 `javax.xml` 库进行解析。而 EntityResolver 的重点，是在于如何获取【验证文件】，从而验证用户写的 XML 是否通过验证。
\ No newline at end of file
diff --git a/spring/10-Spring-IoC 之注册 BeanDefinitions.assets/01.jpg b/spring/10-Spring-IoC 之注册 BeanDefinitions.assets/01.jpg
new file mode 100644
index 0000000..e24c407
Binary files /dev/null and b/spring/10-Spring-IoC 之注册 BeanDefinitions.assets/01.jpg differ
diff --git a/spring/10-Spring-IoC 之注册 BeanDefinitions.md b/spring/10-Spring-IoC 之注册 BeanDefinitions.md
new file mode 100644
index 0000000..584b3c9
--- /dev/null
+++ b/spring/10-Spring-IoC 之注册 BeanDefinitions.md	
@@ -0,0 +1,295 @@
+# 【死磕 Spring】—— IoC 之注册 BeanDefinitions
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=2697 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+获取 XML Document 对象后，会根据该对象和 Resource 资源对象调用 `XmlBeanDefinitionReader#registerBeanDefinitions(Document doc, Resource resource)` 方法，开始注册 BeanDefinitions 之旅。代码如下：
+
+```
+// AbstractBeanDefinitionReader.java
+private final BeanDefinitionRegistry registry;
+
+// XmlBeanDefinitionReader.java
+public int registerBeanDefinitions(Document doc, Resource resource) throws BeanDefinitionStoreException {
+	// <1> 创建 BeanDefinitionDocumentReader 对象
+	BeanDefinitionDocumentReader documentReader = createBeanDefinitionDocumentReader();
+	// <2> 获取已注册的 BeanDefinition 数量
+	int countBefore = getRegistry().getBeanDefinitionCount();
+	// <3> 创建 XmlReaderContext 对象
+	// <4> 注册 BeanDefinition
+	documentReader.registerBeanDefinitions(doc, createReaderContext(resource));
+	// 计算新注册的 BeanDefinition 数量
+	return getRegistry().getBeanDefinitionCount() - countBefore;
+}
+```
+
+- `<1>` 处，调用 `#createBeanDefinitionDocumentReader()` 方法，实例化 BeanDefinitionDocumentReader 对象。
+
+> FROM 《Spring 源码深度解析》P16 页
+>
+> 定义读取 Document 并注册 BeanDefinition 功能
+
+- `<2>` 处，调用 `BeanDefinitionRegistry#getBeanDefinitionCount()` 方法，获取**已注册**的 BeanDefinition 数量。
+- `<3>` 处，调用 `#createReaderContext(Resource resource)` 方法，创建 XmlReaderContext 对象。
+- `<4>` 处，调用 `BeanDefinitionDocumentReader#registerBeanDefinitions(Document doc, XmlReaderContext readerContext)` 方法，读取 XML 元素，注册 BeanDefinition 们。
+- `<5>` 处，计**算新注册**的 BeanDefinition 数量。
+
+# 1. createBeanDefinitionDocumentReader
+
+`#createBeanDefinitionDocumentReader()`，实例化 BeanDefinitionDocumentReader 对象。代码如下：
+
+```
+/**
+ * documentReader 的类
+ *
+ * @see #createBeanDefinitionDocumentReader() 
+ */
+private Class<? extends BeanDefinitionDocumentReader> documentReaderClass = DefaultBeanDefinitionDocumentReader.class;
+
+protected BeanDefinitionDocumentReader createBeanDefinitionDocumentReader() {
+	return BeanUtils.instantiateClass(this.documentReaderClass);
+}
+```
+
+- `documentReaderClass` 的默认值为 `DefaultBeanDefinitionDocumentReader.class` 。关于它，我们在后续的文章，详细解析。
+
+# 2. registerBeanDefinitions
+
+`BeanDefinitionDocumentReader#registerBeanDefinitions(Document doc, XmlReaderContext readerContext)` 方法，注册 BeanDefinition ，在接口 BeanDefinitionDocumentReader 中定义。代码如下：
+
+```
+public interface BeanDefinitionDocumentReader {
+
+	/**
+	 * Read bean definitions from the given DOM document and
+	 * register them with the registry in the given reader context.
+	 * @param doc the DOM document
+	 * @param readerContext the current context of the reader
+	 * (includes the target registry and the resource being parsed)
+	 * @throws BeanDefinitionStoreException in case of parsing errors
+	 */
+	void registerBeanDefinitions(Document doc, XmlReaderContext readerContext)
+			throws BeanDefinitionStoreException;
+
+}
+```
+
+**从给定的 Document 对象中解析定义的 BeanDefinition 并将他们注册到注册表中**。方法接收两个参数：
+
+- `doc` 方法参数：待解析的 Document 对象。
+- `readerContext` 方法，解析器的当前上下文，包括目标注册表和被解析的资源。它是根据 Resource 来创建的，见 [「3. createReaderContext」](https://svip.iocoder.cn/Spring/IoC-register-BeanDefinitions/#) 。
+
+## 2.1 DefaultBeanDefinitionDocumentReader
+
+BeanDefinitionDocumentReader 有且只有一个默认实现类 DefaultBeanDefinitionDocumentReader 。它对 `#registerBeanDefinitions(...)` 方法的实现代码如下：
+
+DefaultBeanDefinitionDocumentReader 对该方法提供了实现：
+
+```
+@Nullable
+private XmlReaderContext readerContext;
+
+@Nullable
+private BeanDefinitionParserDelegate delegate;
+    
+/**
+ * This implementation parses bean definitions according to the "spring-beans" XSD
+ * (or DTD, historically).
+ * <p>Opens a DOM Document; then initializes the default settings
+ * specified at the {@code <beans/>} level; then parses the contained bean definitions.
+ */
+@Override
+public void registerBeanDefinitions(Document doc, XmlReaderContext readerContext) {
+    this.readerContext = readerContext;
+    // 获得 XML Document Root Element
+    // 执行注册 BeanDefinition
+    doRegisterBeanDefinitions(doc.getDocumentElement());
+}
+
+/**
+ * Register each bean definition within the given root {@code <beans/>} element.
+ */
+@SuppressWarnings("deprecation")  // for Environment.acceptsProfiles(String...)
+protected void doRegisterBeanDefinitions(Element root) {
+    // Any nested <beans> elements will cause recursion in this method. In
+    // order to propagate and preserve <beans> default-* attributes correctly,
+    // keep track of the current (parent) delegate, which may be null. Create
+    // the new (child) delegate with a reference to the parent for fallback purposes,
+    // then ultimately reset this.delegate back to its original (parent) reference.
+    // this behavior emulates a stack of delegates without actually necessitating one.
+    // 记录老的 BeanDefinitionParserDelegate 对象
+    BeanDefinitionParserDelegate parent = this.delegate;
+    // <1> 创建 BeanDefinitionParserDelegate 对象，并进行设置到 delegate
+    this.delegate = createDelegate(getReaderContext(), root, parent);
+    // <2> 检查 <beans /> 根标签的命名空间是否为空，或者是 http://www.springframework.org/schema/beans
+    if (this.delegate.isDefaultNamespace(root)) {
+        // <2.1> 处理 profile 属性。可参见《Spring3自定义环境配置 <beans profile="">》http://nassir.iteye.com/blog/1535799
+        String profileSpec = root.getAttribute(PROFILE_ATTRIBUTE);
+        if (StringUtils.hasText(profileSpec)) {
+            // <2.2> 使用分隔符切分，可能有多个 profile 。
+            String[] specifiedProfiles = StringUtils.tokenizeToStringArray(
+                    profileSpec, BeanDefinitionParserDelegate.MULTI_VALUE_ATTRIBUTE_DELIMITERS);
+            // <2.3> 如果所有 profile 都无效，则不进行注册
+            // We cannot use Profiles.of(...) since profile expressions are not supported
+            // in XML config. See SPR-12458 for details.
+            if (!getReaderContext().getEnvironment().acceptsProfiles(specifiedProfiles)) {
+                if (logger.isDebugEnabled()) {
+                    logger.debug("Skipped XML bean definition file due to specified profiles [" + profileSpec +
+                            "] not matching: " + getReaderContext().getResource());
+                }
+                return;
+            }
+        }
+    }
+
+    // <3> 解析前处理
+    preProcessXml(root);
+    // <4> 解析
+    parseBeanDefinitions(root, this.delegate);
+    // <5> 解析后处理
+    postProcessXml(root);
+
+    // 设置 delegate 回老的 BeanDefinitionParserDelegate 对象
+    this.delegate = parent;
+}
+```
+
+- `<1>` 处，创建 BeanDefinitionParserDelegate 对象，并进行设置到 `delegate` 。BeanDefinitionParserDelegate 是一个重要的类，它负责**解析 BeanDefinition**。代码如下：
+
+  > FROM 《Spring 源码深度解析》P16
+  >
+  > 定义解析 XML Element 的各种方法
+
+  ```
+  protected BeanDefinitionParserDelegate createDelegate(
+          XmlReaderContext readerContext, Element root, @Nullable BeanDefinitionParserDelegate parentDelegate) {
+      // 创建 BeanDefinitionParserDelegate 对象
+      BeanDefinitionParserDelegate delegate = new BeanDefinitionParserDelegate(readerContext);
+      // 初始化默认
+      delegate.initDefaults(root, parentDelegate);
+      return delegate;
+  }
+  ```
+
+- `<2>` 处，检查 `<beans />` **根**标签的命名空间是否为空，或者是 http://www.springframework.org/schema/beans 。
+
+  - `<2.1>` 处，判断是否 `<beans />` 上配置了 `profile` 属性。不了解这块的胖友，可以看下 [《《Spring3自定义环境配置 》》](http://nassir.iteye.com/blog/1535799) 。
+  - `<2.2>` 处，使用分隔符切分，可能有**多个** profile 。
+  - `<2.3>` 处，判断，如果所有 profile 都无效，则 `return` 不进行注册。
+
+- `<4>` 处，调用 `#parseBeanDefinitions(Element root, BeanDefinitionParserDelegate delegate)` 方法，进行解析逻辑。详细解析，见 [「3.1 parseBeanDefinitions」](https://svip.iocoder.cn/Spring/IoC-register-BeanDefinitions/#) 。
+
+- `<3>` / `<5>` 处，解析**前后**的处理，目前这两个方法都是空实现，交由子类来实现。代码如下：
+
+  ```
+  protected void preProcessXml(Element root) {}
+  
+  protected void postProcessXml(Element root) {}
+  ```
+
+### 2.1.1 parseBeanDefinitions
+
+`#parseBeanDefinitions(Element root, BeanDefinitionParserDelegate delegate)` 方法，进行解析逻辑。代码如下：
+
+```
+/**
+ * Parse the elements at the root level in the document:
+ * "import", "alias", "bean".
+ * @param root the DOM root element of the document
+ */
+protected void parseBeanDefinitions(Element root, BeanDefinitionParserDelegate delegate) {
+    // <1> 如果根节点使用默认命名空间，执行默认解析
+    if (delegate.isDefaultNamespace(root)) {
+        // 遍历子节点
+        NodeList nl = root.getChildNodes();
+        for (int i = 0; i < nl.getLength(); i++) {
+            Node node = nl.item(i);
+            if (node instanceof Element) {
+                Element ele = (Element) node;
+                // <1> 如果该节点使用默认命名空间，执行默认解析
+                if (delegate.isDefaultNamespace(ele)) {
+                    parseDefaultElement(ele, delegate);
+                // 如果该节点非默认命名空间，执行自定义解析
+                } else {
+                    delegate.parseCustomElement(ele);
+                }
+            }
+        }
+    // <2> 如果根节点非默认命名空间，执行自定义解析
+    } else {
+        delegate.parseCustomElement(root);
+    }
+}
+```
+
+- Spring 有
+
+  两种
+
+   
+
+  Bean 声明方式：
+
+  - 配置文件式声明：`<bean id="studentService" class="org.springframework.core.StudentService" />` 。对应 `<1>` 处。
+  - 自定义注解方式：`<tx:annotation-driven>` 。对应 `<2>` 处。
+
+- `<1>` 处，如果**根**节点或**子**节点**使用**默认命名空间，调用 `#parseDefaultElement(Element ele, BeanDefinitionParserDelegate delegate)` 方法，执行默认解析。代码如下：
+
+  ```
+  private void parseDefaultElement(Element ele, BeanDefinitionParserDelegate delegate) {
+  	if (delegate.nodeNameEquals(ele, IMPORT_ELEMENT)) { // import
+  		importBeanDefinitionResource(ele);
+  	} else if (delegate.nodeNameEquals(ele, ALIAS_ELEMENT)) { // alias
+  		processAliasRegistration(ele);
+  	} else if (delegate.nodeNameEquals(ele, BEAN_ELEMENT)) { // bean
+  		processBeanDefinition(ele, delegate);
+  	} else if (delegate.nodeNameEquals(ele, NESTED_BEANS_ELEMENT)) { // beans
+  		// recurse
+  		doRegisterBeanDefinitions(ele);
+  	}
+  }
+  ```
+
+  - 详细的解析，见后续文章。
+
+- `<2>` 处，如果**根**节点或**子**节点**不使用**默认命名空间，调用 `BeanDefinitionParserDelegate#parseCustomElement(Element ele)` 方法，执行**自定义**解析。详细的解析，见后续文章。
+
+# 3. createReaderContext
+
+`#createReaderContext(Resource resource)` 方法，创建 XmlReaderContext 对象。代码如下：
+
+```
+private ProblemReporter problemReporter = new FailFastProblemReporter();
+
+private ReaderEventListener eventListener = new EmptyReaderEventListener();
+
+private SourceExtractor sourceExtractor = new NullSourceExtractor();
+
+@Nullable
+private NamespaceHandlerResolver namespaceHandlerResolver;
+
+/**
+ * Create the {@link XmlReaderContext} to pass over to the document reader.
+ */
+public XmlReaderContext createReaderContext(Resource resource) {
+	return new XmlReaderContext(resource, this.problemReporter, this.eventListener,
+			this.sourceExtractor, this, getNamespaceHandlerResolver());
+}
+```
+
+关于 XmlReaderContext 的详细解析，见后续文章。
+
+# 4. 小结
+
+至此，`XmlBeanDefinitionReader#doLoadBeanDefinitions(InputSource inputSource, Resource resource)` 方法中，做的三件事情已经全部分析完毕，下面将对 **BeanDefinition 的解析过程**做详细分析说明。
+
+另外，`XmlBeanDefinitionReader#doLoadBeanDefinitions(InputSource inputSource, Resource resource)` 方法，整体时序图如下：
+
+[![时序图](10-Spring-IoC 之注册 BeanDefinitions.assets/01.jpg)](http://static.iocoder.cn/images/Spring/2019-02-16/01.jpg)时序图
+
+- 红框部分，就是 **BeanDefinition 的解析过程**。
\ No newline at end of file
diff --git a/spring/11-Spring-IoC 之解析Bean：解析 import 标签.md b/spring/11-Spring-IoC 之解析Bean：解析 import 标签.md
new file mode 100644
index 0000000..2e626ff
--- /dev/null
+++ b/spring/11-Spring-IoC 之解析Bean：解析 import 标签.md	
@@ -0,0 +1,305 @@
+# 【死磕 Spring】—— IoC 之解析Bean：解析 import 标签
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=2724 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+在博客 [【死磕 Spring】—— IoC 之注册 BeanDefinitions](http://svip.iocoder.cn/Spring/IoC-register-BeanDefinitions) 中分析到，Spring 中有两种解析 Bean 的方式：
+
+- 如果根节点或者子节点采用默认命名空间的话，则调用 `#parseDefaultElement(...)` 方法，进行**默认**标签解析
+- 否则，调用 `BeanDefinitionParserDelegate#parseCustomElement(...)` 方法，进行**自定义**解析。
+
+所以，以下博客就这两个方法进行详细分析说明。而本文，先从**默认标签**解析过程开始。代码如下：
+
+```
+// DefaultBeanDefinitionDocumentReader.java
+
+public static final String IMPORT_ELEMENT = "import";
+public static final String ALIAS_ATTRIBUTE = "alias";
+public static final String BEAN_ELEMENT = BeanDefinitionParserDelegate.BEAN_ELEMENT;
+public static final String NESTED_BEANS_ELEMENT = "beans";
+
+private void parseDefaultElement(Element ele, BeanDefinitionParserDelegate delegate) {
+	if (delegate.nodeNameEquals(ele, IMPORT_ELEMENT)) { // import
+		importBeanDefinitionResource(ele);
+	} else if (delegate.nodeNameEquals(ele, ALIAS_ELEMENT)) { // alias
+		processAliasRegistration(ele);
+	} else if (delegate.nodeNameEquals(ele, BEAN_ELEMENT)) { // bean
+		processBeanDefinition(ele, delegate);
+	} else if (delegate.nodeNameEquals(ele, NESTED_BEANS_ELEMENT)) { // beans
+		// recurse
+		doRegisterBeanDefinitions(ele);
+	}
+}
+```
+
+该方法的功能一目了然，分别是对四种不同的标签进行解析，分别是 `import`、`alias`、`bean`、`beans` 。咱门从第一个标签 `import` 开始。
+
+# 1. import 示例
+
+经历过 Spring 配置文件的小伙伴都知道，如果工程比较大，配置文件的维护会让人觉得恐怖，文件太多了，想象将所有的配置都放在一个 `spring.xml` 配置文件中，哪种后怕感是不是很明显？
+
+所有针对这种情况 Spring 提供了一个分模块的思路，利用 `import` 标签，例如我们可以构造一个这样的 `spring.xml` 。
+
+```
+<?xml version="1.0" encoding="UTF-8"?>
+<beans xmlns="http://www.springframework.org/schema/beans"
+       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+       xsi:schemaLocation="http://www.springframework.org/schema/beans
+       http://www.springframework.org/schema/beans/spring-beans.xsd">
+
+    <import resource="spring-student.xml"/>
+
+    <import resource="spring-student-dtd.xml"/>
+
+</beans>
+```
+
+`spring.xml` 配置文件中，使用 `import` 标签的方式导入其他模块的配置文件。
+
+- 如果有配置需要修改直接修改相应配置文件即可。
+- 若有新的模块需要引入直接增加 `import` 即可。
+
+这样大大简化了配置后期维护的复杂度，同时也易于管理。
+
+# 2. importBeanDefinitionResource
+
+Spring 使用 `#importBeanDefinitionResource(Element ele)` 方法，完成对 `import` 标签的解析。
+
+```
+// DefaultBeanDefinitionDocumentReader.java
+
+/**
+ * Parse an "import" element and load the bean definitions
+ * from the given resource into the bean factory.
+ */
+protected void importBeanDefinitionResource(Element ele) {
+    // <1> 获取 resource 的属性值
+    String location = ele.getAttribute(RESOURCE_ATTRIBUTE);
+    // 为空，直接退出
+    if (!StringUtils.hasText(location)) {
+        getReaderContext().error("Resource location must not be empty", ele); // 使用 problemReporter 报错
+        return;
+    }
+
+    // <2> 解析系统属性，格式如 ："${user.dir}"
+    // Resolve system properties: e.g. "${user.dir}"
+    location = getReaderContext().getEnvironment().resolveRequiredPlaceholders(location);
+
+    // 实际 Resource 集合，即 import 的地址，有哪些 Resource 资源
+    Set<Resource> actualResources = new LinkedHashSet<>(4);
+
+    // <3> 判断 location 是相对路径还是绝对路径
+    // Discover whether the location is an absolute or relative URI
+    boolean absoluteLocation = false;
+    try {
+        absoluteLocation = ResourcePatternUtils.isUrl(location) || ResourceUtils.toURI(location).isAbsolute();
+    } catch (URISyntaxException ex) {
+        // cannot convert to an URI, considering the location relative
+        // unless it is the well-known Spring prefix "classpath*:"
+    }
+
+    // Absolute or relative?
+    // <4> 绝对路径
+    if (absoluteLocation) {
+        try {
+            // 添加配置文件地址的 Resource 到 actualResources 中，并加载相应的 BeanDefinition 们
+            int importCount = getReaderContext().getReader().loadBeanDefinitions(location, actualResources);
+            if (logger.isTraceEnabled()) {
+                logger.trace("Imported " + importCount + " bean definitions from URL location [" + location + "]");
+            }
+        } catch (BeanDefinitionStoreException ex) {
+            getReaderContext().error(
+                    "Failed to import bean definitions from URL location [" + location + "]", ele, ex);
+        }
+    // <5> 相对路径
+    } else {
+        // No URL -> considering resource location as relative to the current file.
+        try {
+            int importCount;
+            // 创建相对地址的 Resource
+            Resource relativeResource = getReaderContext().getResource().createRelative(location);
+            // 存在
+            if (relativeResource.exists()) {
+                // 加载 relativeResource 中的 BeanDefinition 们
+                importCount = getReaderContext().getReader().loadBeanDefinitions(relativeResource);
+                // 添加到 actualResources 中
+                actualResources.add(relativeResource);
+            // 不存在
+            } else {
+                // 获得根路径地址
+                String baseLocation = getReaderContext().getResource().getURL().toString();
+                // 添加配置文件地址的 Resource 到 actualResources 中，并加载相应的 BeanDefinition 们
+                importCount = getReaderContext().getReader().loadBeanDefinitions(
+                        StringUtils.applyRelativePath(baseLocation, location) /* 计算绝对路径 */, actualResources);
+            }
+            if (logger.isTraceEnabled()) {
+                logger.trace("Imported " + importCount + " bean definitions from relative location [" + location + "]");
+            }
+        } catch (IOException ex) {
+            getReaderContext().error("Failed to resolve current resource location", ele, ex);
+        } catch (BeanDefinitionStoreException ex) {
+            getReaderContext().error(
+                    "Failed to import bean definitions from relative location [" + location + "]", ele, ex);
+        }
+    }
+    // <6> 解析成功后，进行监听器激活处理
+    Resource[] actResArray = actualResources.toArray(new Resource[0]);
+    getReaderContext().fireImportProcessed(location, actResArray, extractSource(ele));
+}
+```
+
+解析 `import` 标签的过程较为清晰，整个过程如下：
+
+- ```
+  <1>
+  ```
+
+   
+
+  处，获取
+
+   
+
+  ```
+  source
+  ```
+
+   
+
+  属性的值，该值表示资源的路径。
+
+  - `<2>` 处，解析路径中的系统属性，如 `"${user.dir}"` 。
+
+- ```
+  <3>
+  ```
+
+   
+
+  处，判断资源路径
+
+   
+
+  ```
+  location
+  ```
+
+   
+
+  是绝对路径还是相对路径。详细解析，见
+
+   
+
+  「2.1 判断路径」
+
+   
+
+  。
+
+  - `<4>` 处，如果是绝对路径，则调递归调用 Bean 的解析过程，进行另一次的解析。详细解析，见 [「2.2 处理绝对路径」](https://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-for-import/#) 。
+  - `<5>` 处，如果是相对路径，则先计算出绝对路径得到 Resource，然后进行解析。详细解析，见 [「2.3 处理相对路径」](https://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-for-import/#) 。
+
+- `<6>` 处，通知监听器，完成解析。
+
+## 2.1 判断路径
+
+通过以下代码，来判断 `location` 是为相对路径还是绝对路径：
+
+```
+absoluteLocation = ResourcePatternUtils.isUrl(location) // <1>
+    || ResourceUtils.toURI(location).isAbsolute(); // <2>
+```
+
+判断绝对路径的规则如下：
+
+- `<1>` 以 `classpath*:` 或者 `classpath:` 开头的为绝对路径。
+- `<1>` 能够通过该 `location` 构建出 `java.net.URL` 为绝对路径。
+- `<2>` 根据 `location` 构造 `java.net.URI` 判断调用 `#isAbsolute()` 方法，判断是否为绝对路径。
+
+## 2.2 处理绝对路径
+
+如果 `location` 为绝对路径，则调用 `#loadBeanDefinitions(String location, Set<Resource> actualResources)`， 方法。该方法在 `org.springframework.beans.factory.support.AbstractBeanDefinitionReader` 中定义，代码如下：
+
+```
+/**
+ * Load bean definitions from the specified resource location.
+ * <p>The location can also be a location pattern, provided that the
+ * ResourceLoader of this bean definition reader is a ResourcePatternResolver.
+ * @param location the resource location, to be loaded with the ResourceLoader
+ * (or ResourcePatternResolver) of this bean definition reader
+ * @param actualResources a Set to be filled with the actual Resource objects
+ * that have been resolved during the loading process. May be {@code null}
+ * to indicate that the caller is not interested in those Resource objects.
+ * @return the number of bean definitions found
+ * @throws BeanDefinitionStoreException in case of loading or parsing errors
+ * @see #getResourceLoader()
+ * @see #loadBeanDefinitions(org.springframework.core.io.Resource)
+ * @see #loadBeanDefinitions(org.springframework.core.io.Resource[])
+ */
+public int loadBeanDefinitions(String location, @Nullable Set<Resource> actualResources) throws BeanDefinitionStoreException {
+    // 获得 ResourceLoader 对象
+    ResourceLoader resourceLoader = getResourceLoader();
+    if (resourceLoader == null) {
+        throw new BeanDefinitionStoreException(
+                "Cannot load bean definitions from location [" + location + "]: no ResourceLoader available");
+    }
+
+    if (resourceLoader instanceof ResourcePatternResolver) {
+        // Resource pattern matching available.
+        try {
+            // 获得 Resource 数组，因为 Pattern 模式匹配下，可能有多个 Resource 。例如说，Ant 风格的 location
+            Resource[] resources = ((ResourcePatternResolver) resourceLoader).getResources(location);
+            // 加载 BeanDefinition 们
+            int count = loadBeanDefinitions(resources);
+            // 添加到 actualResources 中
+            if (actualResources != null) {
+                Collections.addAll(actualResources, resources);
+            }
+            if (logger.isTraceEnabled()) {
+                logger.trace("Loaded " + count + " bean definitions from location pattern [" + location + "]");
+            }
+            return count;
+        } catch (IOException ex) {
+            throw new BeanDefinitionStoreException(
+                    "Could not resolve bean definition resource pattern [" + location + "]", ex);
+        }
+    } else {
+        // Can only load single resources by absolute URL.
+        // 获得 Resource 对象，
+        Resource resource = resourceLoader.getResource(location);
+        // 加载 BeanDefinition 们
+        int count = loadBeanDefinitions(resource);
+        // 添加到 actualResources 中
+        if (actualResources != null) {
+            actualResources.add(resource);
+        }
+        if (logger.isTraceEnabled()) {
+            logger.trace("Loaded " + count + " bean definitions from location [" + location + "]");
+        }
+        return count;
+    }
+}
+```
+
+整个逻辑比较简单：
+
+- 首先，获取 ResourceLoader 对象。
+- 然后，根据不同的 ResourceLoader 执行不同的逻辑，主要是可能存在多个 Resource 。
+- 最终，都会回归到 `XmlBeanDefinitionReader#loadBeanDefinitions(Resource... resources)` 方法，所以这是一个递归的过程。
+- 另外，获得到的 Resource 的对象或数组，都会添加到 `actualResources` 中。
+
+## 2.3 处理相对路径
+
+如果 `location` 是相对路径，则会根据相应的 Resource 计算出相应的相对路径的 Resource 对象 ，然后：
+
+- 若该 Resource 存在，则调用 `XmlBeanDefinitionReader#loadBeanDefinitions()` 方法，进行 BeanDefinition 加载。
+- 否则，构造一个绝对 `location`( 即 `StringUtils.applyRelativePath(baseLocation, location)` 处的代码)，并调用 `#loadBeanDefinitions(String location, Set<Resource> actualResources)` 方法，**与绝对路径过程一样**。
+
+# 3. 小结
+
+至此，`import` 标签解析完毕，整个过程比较清晰明了：**获取 source 属性值，得到正确的资源路径，然后调用 `XmlBeanDefinitionReader#loadBeanDefinitions(Resource... resources)` 方法，进行递归的 BeanDefinition 加载**。
\ No newline at end of file
diff --git a/spring/12-Spring-IoC 之解析bean标签：开启解析进程.md b/spring/12-Spring-IoC 之解析bean标签：开启解析进程.md
new file mode 100644
index 0000000..89e0f75
--- /dev/null
+++ b/spring/12-Spring-IoC 之解析bean标签：开启解析进程.md	
@@ -0,0 +1,329 @@
+# 【死磕 Spring】—— IoC 之解析 <bean> 标签：开启解析进程
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=2731 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+`import` 标签解析完毕了，我们一起来看看 Spring 中**最复杂也是最重要**的标签 `bean` 标签的解析过程。
+
+# 1. processBeanDefinition
+
+在方法 `#parseDefaultElement(...)` 方法中，如果遇到标签为 `bean` 时，则调用 `#processBeanDefinition(Element ele, BeanDefinitionParserDelegate delegate)` 方法，进行 `bean` 标签的解析。代码如下：
+
+```
+// DefaultBeanDefinitionDocumentReader.java
+
+/**
+ * Process the given bean element, parsing the bean definition
+ * and registering it with the registry.
+ */
+protected void processBeanDefinition(Element ele, BeanDefinitionParserDelegate delegate) {
+    // 进行 bean 元素解析。
+    // <1> 如果解析成功，则返回 BeanDefinitionHolder 对象。而 BeanDefinitionHolder 为 name 和 alias 的 BeanDefinition 对象
+    // 如果解析失败，则返回 null 。
+    BeanDefinitionHolder bdHolder = delegate.parseBeanDefinitionElement(ele);
+    if (bdHolder != null) {
+        // <2> 进行自定义标签处理
+        bdHolder = delegate.decorateBeanDefinitionIfRequired(ele, bdHolder);
+        try {
+            // <3> 进行 BeanDefinition 的注册
+            // Register the final decorated instance.
+            BeanDefinitionReaderUtils.registerBeanDefinition(bdHolder, getReaderContext().getRegistry());
+        } catch (BeanDefinitionStoreException ex) {
+            getReaderContext().error("Failed to register bean definition with name '" +
+                    bdHolder.getBeanName() + "'", ele, ex);
+        }
+        // <4> 发出响应事件，通知相关的监听器，已完成该 Bean 标签的解析。
+        // Send registration event.
+        getReaderContext().fireComponentRegistered(new BeanComponentDefinition(bdHolder));
+    }
+}
+```
+
+整个过程分为四个步骤：
+
+1. 调用
+
+    
+
+   ```
+   BeanDefinitionParserDelegate#parseBeanDefinitionElement(Element ele, BeanDefinitionParserDelegate delegate)
+   ```
+
+    
+
+   方法，进行元素解析。
+
+   - 如果解析**失败**，则返回 `null`，错误由 ProblemReporter 处理。
+   - 如果解析**成功**，则返回 BeanDefinitionHolder 实例 `bdHolder` 。BeanDefinitionHolder 为持有 `name` 和 `alias` 的 BeanDefinition。
+   - 详细解析，见 [「2. parseBeanDefinitionElement」](https://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-in-processBeanDefinition/#) 。
+
+2. 若实例 `bdHolder` 不为空，则调用 `BeanDefinitionParserDelegate#decorateBeanDefinitionIfRequired(Element ele, BeanDefinitionHolder bdHolder)` 方法，进行自定义标签处理。
+
+3. 解析完成后，则调用 `BeanDefinitionReaderUtils#registerBeanDefinition(BeanDefinitionHolder definitionHolder, BeanDefinitionRegistry registry)` 方法，对 `bdHolder` 进行 BeanDefinition 的注册。
+
+4. 发出响应事件，通知相关的监听器，完成 Bean 标签解析。
+
+# 2. parseBeanDefinitionElement
+
+`BeanDefinitionParserDelegate#parseBeanDefinitionElement(Element ele, BeanDefinitionParserDelegate delegate)` 方法，进行 `<bean>` 元素解析。代码如下：
+
+```
+// BeanDefinitionParserDelegate.java
+
+/**
+ * Parses the supplied {@code <bean>} element. May return {@code null}
+ * if there were errors during parse. Errors are reported to the
+ * {@link org.springframework.beans.factory.parsing.ProblemReporter}.
+ */
+@Nullable
+public BeanDefinitionHolder parseBeanDefinitionElement(Element ele) {
+    return parseBeanDefinitionElement(ele, null);
+}
+
+/**
+ * Parses the supplied {@code <bean>} element. May return {@code null}
+ * if there were errors during parse. Errors are reported to the
+ * {@link org.springframework.beans.factory.parsing.ProblemReporter}.
+ *
+ * @param containingBean TODO 芋艿，需要进一步确认
+ */
+@Nullable
+public BeanDefinitionHolder parseBeanDefinitionElement(Element ele, @Nullable BeanDefinition containingBean) {
+    // <1> 解析 id 和 name 属性
+    String id = ele.getAttribute(ID_ATTRIBUTE);
+    String nameAttr = ele.getAttribute(NAME_ATTRIBUTE);
+
+    // <1> 计算别名集合
+    List<String> aliases = new ArrayList<>();
+    if (StringUtils.hasLength(nameAttr)) {
+        String[] nameArr = StringUtils.tokenizeToStringArray(nameAttr, MULTI_VALUE_ATTRIBUTE_DELIMITERS);
+        aliases.addAll(Arrays.asList(nameArr));
+    }
+
+    // <3.1> beanName ，优先，使用 id
+    String beanName = id;
+    // <3.2> beanName ，其次，使用 aliases 的第一个
+    if (!StringUtils.hasText(beanName) && !aliases.isEmpty()) {
+        beanName = aliases.remove(0); // 移除出别名集合
+        if (logger.isTraceEnabled()) {
+            logger.trace("No XML 'id' specified - using '" + beanName +
+                    "' as bean name and " + aliases + " as aliases");
+        }
+    }
+
+    // <2> 检查 beanName 的唯一性
+    if (containingBean == null) {
+        checkNameUniqueness(beanName, aliases, ele);
+    }
+
+    // <4> 解析属性，构造 AbstractBeanDefinition 对象
+    AbstractBeanDefinition beanDefinition = parseBeanDefinitionElement(ele, beanName, containingBean);
+    if (beanDefinition != null) {
+        // <3.3> beanName ，再次，使用 beanName 生成规则
+        if (!StringUtils.hasText(beanName)) {
+            try {
+                if (containingBean != null) {
+                    // <3.3> 生成唯一的 beanName
+                    beanName = BeanDefinitionReaderUtils.generateBeanName(
+                            beanDefinition, this.readerContext.getRegistry(), true);
+                } else {
+                    // <3.3> 生成唯一的 beanName
+                    beanName = this.readerContext.generateBeanName(beanDefinition);
+                    // TODO 芋艿，需要进一步确认
+                    // Register an alias for the plain bean class name, if still possible,
+                    // if the generator returned the class name plus a suffix.
+                    // This is expected for Spring 1.2/2.0 backwards compatibility.
+                    String beanClassName = beanDefinition.getBeanClassName();
+                    if (beanClassName != null &&
+                            beanName.startsWith(beanClassName) && beanName.length() > beanClassName.length() &&
+                            !this.readerContext.getRegistry().isBeanNameInUse(beanClassName)) {
+                        aliases.add(beanClassName);
+                    }
+                }
+                if (logger.isTraceEnabled()) {
+                    logger.trace("Neither XML 'id' nor 'name' specified - " +
+                            "using generated bean name [" + beanName + "]");
+                }
+            } catch (Exception ex) {
+                error(ex.getMessage(), ele);
+                return null;
+            }
+        }
+        // <5> 创建 BeanDefinitionHolder 对象
+        String[] aliasesArray = StringUtils.toStringArray(aliases);
+        return new BeanDefinitionHolder(beanDefinition, beanName, aliasesArray);
+    }
+    return null;
+}
+```
+
+这个方法还没有对 `bean` 标签进行解析，只是在解析动作之前做了一些功能架构，主要的工作有：
+
+- `<1>` 处，解析 `id`、`name` 属性，确定 `aliases` 集合
+
+- `<2>` 处，检测 `beanName` 是否唯一。代码如下：
+
+  ```
+  /**
+   * 已使用 Bean 名字的集合
+   *
+   * Stores all used bean names so we can enforce uniqueness on a per
+   * beans-element basis. Duplicate bean ids/names may not exist within the
+   * same level of beans element nesting, but may be duplicated across levels.
+   */
+  private final Set<String> usedNames = new HashSet<>();
+  
+  /**
+   * Validate that the specified bean name and aliases have not been used already
+   * within the current level of beans element nesting.
+   */
+  protected void checkNameUniqueness(String beanName, List<String> aliases, Element beanElement) {
+  	// 寻找是否 beanName 已经使用
+      String foundName = null;
+  	if (StringUtils.hasText(beanName) && this.usedNames.contains(beanName)) {
+  		foundName = beanName;
+  	}
+  	if (foundName == null) {
+  		foundName = CollectionUtils.findFirstMatch(this.usedNames, aliases);
+  	}
+  	// 若已使用，使用 problemReporter 提示错误
+  	if (foundName != null) {
+  		error("Bean name '" + foundName + "' is already used in this <beans> element", beanElement);
+  	}
+  
+  	// 添加到 usedNames 集合
+  	this.usedNames.add(beanName);
+  	this.usedNames.addAll(aliases);
+  }
+  ```
+
+- 这里有必要说下 `beanName` 的命名规则：
+
+  - `<3.1>` 处，如果 `id` 不为空，则 `beanName = id` 。
+  - `<3.2>` 处，如果 `id` 为空，但是 `aliases` 不空，则 `beanName` 为 `aliases` 的**第一个**元素
+  - `<3.3>` 处，如果两者都为空，则根据**默认规则**来设置 beanName 。因为**默认规则**不是本文的重点，所以暂时省略。感兴趣的胖友，自己研究下哈。
+
+- `<4>` 处，调用 `#parseBeanDefinitionElement(Element ele, String beanName, BeanDefinition containingBean)` 方法，对属性进行解析并封装成 AbstractBeanDefinition 实例 `beanDefinition` 。详细解析，见 [「2.1 parseBeanDefinitionElement」](https://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-in-processBeanDefinition/#) 。
+
+- `<5>` 处，根据所获取的信息（`beanName`、`aliases`、`beanDefinition`）构造 BeanDefinitionHolder 实例对象并返回。其中，BeanDefinitionHolder 的简化代码如下：
+
+  ```
+  /**
+   * BeanDefinition 对象
+   */
+  private final BeanDefinition beanDefinition;
+  /**
+   * Bean 名字
+   */
+  private final String beanName;
+  /**
+   * 别名集合
+   */
+  @Nullable
+  private final String[] aliases;
+  ```
+
+> TODO 芋艿，需要进一步确认，未来参考下 [《Spring专题之IOC源码分析》](https://segmentfault.com/a/1190000016261917) ，进行细化。
+
+## 2.1 parseBeanDefinitionElement
+
+`#parseBeanDefinitionElement(Element ele, String beanName, BeanDefinition containingBean)` 方法，对属性进行解析并封装成 AbstractBeanDefinition 实例，代码如下：
+
+```
+/**
+ * Parse the bean definition itself, without regard to name or aliases. May return
+ * {@code null} if problems occurred during the parsing of the bean definition.
+ */
+@Nullable
+public AbstractBeanDefinition parseBeanDefinitionElement(
+        Element ele, String beanName, @Nullable BeanDefinition containingBean) {
+
+    this.parseState.push(new BeanEntry(beanName));
+
+    // 解析 class 属性
+    String className = null;
+    if (ele.hasAttribute(CLASS_ATTRIBUTE)) {
+        className = ele.getAttribute(CLASS_ATTRIBUTE).trim();
+    }
+    // 解析 parent 属性
+    String parent = null;
+    if (ele.hasAttribute(PARENT_ATTRIBUTE)) {
+        parent = ele.getAttribute(PARENT_ATTRIBUTE);
+    }
+
+    try {
+        // 创建用于承载属性的 AbstractBeanDefinition 实例
+        AbstractBeanDefinition bd = createBeanDefinition(className, parent);
+
+        // 解析默认 bean 的各种属性
+        parseBeanDefinitionAttributes(ele, beanName, containingBean, bd);
+        // 提取 description
+        bd.setDescription(DomUtils.getChildElementValueByTagName(ele, DESCRIPTION_ELEMENT));
+
+        // tips：
+        // 下面的一堆是解析 <bean>......</bean> 内部的子元素，
+        // 解析出来以后的信息都放到 bd 的属性中
+
+        // 解析元数据 <meta />
+        parseMetaElements(ele, bd);
+        // 解析 lookup-method 属性 <lookup-method />
+        parseLookupOverrideSubElements(ele, bd.getMethodOverrides());
+        // 解析 replaced-method 属性 <replaced-method />
+        parseReplacedMethodSubElements(ele, bd.getMethodOverrides());
+
+        // 解析构造函数参数 <constructor-arg />
+        parseConstructorArgElements(ele, bd);
+        // 解析 property 子元素 <property />
+        parsePropertyElements(ele, bd);
+        // 解析 qualifier 子元素 <qualifier />
+        parseQualifierElements(ele, bd);
+
+        bd.setResource(this.readerContext.getResource());
+        bd.setSource(extractSource(ele));
+
+        return bd;
+    } catch (ClassNotFoundException ex) {
+        error("Bean class [" + className + "] not found", ele, ex);
+    } catch (NoClassDefFoundError err) {
+        error("Class that bean class [" + className + "] depends on not found", ele, err);
+    } catch (Throwable ex) {
+        error("Unexpected failure during bean definition parsing", ele, ex);
+    } finally {
+        this.parseState.pop();
+    }
+
+    return null;
+}
+```
+
+到这里，`bean` 标签的所有属性我们都可以看到其解析的过程，也就说到这里我们已经解析一个基本可用的 BeanDefinition 。
+
+## 2.2 createBeanDefinition
+
+`#createBeanDefinition(String className, String parentName)` 方法，创建 AbstractBeanDefinition 对象。代码如下：
+
+```
+/**
+ * Create a bean definition for the given class name and parent name.
+ * @param className the name of the bean class
+ * @param parentName the name of the bean's parent bean
+ * @return the newly created bean definition
+ * @throws ClassNotFoundException if bean class resolution was attempted but failed
+ */
+protected AbstractBeanDefinition createBeanDefinition(@Nullable String className, @Nullable String parentName)
+		throws ClassNotFoundException {
+	return BeanDefinitionReaderUtils.createBeanDefinition(
+			parentName, className, this.readerContext.getBeanClassLoader());
+}
+```
+
+# 3. 小节
+
+由于解析过程 `bean` 标签的**属性**较为漫长，篇幅较大，为了更好的观看体验，将这篇博文进行**拆分**。
+
+下篇博客主要介绍 BeanDefinition ，以及解析默认 `bean` 标签的各种属性的过程，即 `#parseBeanDefinitionAttributes(Element ele, String beanName, BeanDefinition containingBean, AbstractBeanDefinition bd)` 方法。
\ No newline at end of file
diff --git a/spring/13-Spring-IoC 之解析bean标签：BeanDefinition.assets/6abb56b3651c0eee105c510bb9fc6473.png b/spring/13-Spring-IoC 之解析bean标签：BeanDefinition.assets/6abb56b3651c0eee105c510bb9fc6473.png
new file mode 100644
index 0000000..befa311
Binary files /dev/null and b/spring/13-Spring-IoC 之解析bean标签：BeanDefinition.assets/6abb56b3651c0eee105c510bb9fc6473.png differ
diff --git a/spring/13-Spring-IoC 之解析bean标签：BeanDefinition.md b/spring/13-Spring-IoC 之解析bean标签：BeanDefinition.md
new file mode 100644
index 0000000..8c5465b
--- /dev/null
+++ b/spring/13-Spring-IoC 之解析bean标签：BeanDefinition.md	
@@ -0,0 +1,283 @@
+# 【死磕 Spring】—— IoC 之解析 <bean> 标签：BeanDefinition
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=2734 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+前面历经千辛万苦终于到达解析 `bean` 标签步骤来了，解析 bean 标签的过程其实就是构造一个 BeanDefinition 对象的过程。`<bean>` 元素标签拥有的配置属性，BeanDefinition 均提供了相应的属性，与之一一对应。所以，我们有必要对 BeanDefinition **先**有一个整体的认识。
+
+# 1. BeanDefinition
+
+`org.springframework.beans.factory.config.BeanDefinition` ，是一个接口，它描述了一个 Bean 实例的**定义**，包括属性值、构造方法值和继承自它的类的更多信息。代码如下：
+
+```
+String SCOPE_SINGLETON = ConfigurableBeanFactory.SCOPE_SINGLETON;
+String SCOPE_PROTOTYPE = ConfigurableBeanFactory.SCOPE_PROTOTYPE;
+
+
+int ROLE_APPLICATION = 0;
+int ROLE_SUPPORT = 1;
+int ROLE_INFRASTRUCTURE = 2;
+
+void setParentName(@Nullable String parentName);
+@Nullable
+String getParentName();
+
+void setBeanClassName(@Nullable String beanClassName);
+@Nullable
+String getBeanClassName();
+
+void setScope(@Nullable String scope);
+@Nullable
+String getScope();
+
+void setLazyInit(boolean lazyInit);
+boolean isLazyInit();
+
+void setDependsOn(@Nullable String... dependsOn);
+@Nullable
+String[] getDependsOn();
+
+void setAutowireCandidate(boolean autowireCandidate);
+boolean isAutowireCandidate();
+
+void setPrimary(boolean primary);
+boolean isPrimary();
+
+void setFactoryBeanName(@Nullable String factoryBeanName);
+@Nullable
+String getFactoryBeanName();
+
+void setFactoryMethodName(@Nullable String factoryMethodName);
+@Nullable
+String getFactoryMethodName();
+
+ConstructorArgumentValues getConstructorArgumentValues();
+default boolean hasConstructorArgumentValues() {
+	return !getConstructorArgumentValues().isEmpty();
+}
+
+MutablePropertyValues getPropertyValues();
+default boolean hasPropertyValues() {
+	return !getPropertyValues().isEmpty();
+}
+
+void setInitMethodName(@Nullable String initMethodName);
+@Nullable
+String getInitMethodName();
+
+void setDestroyMethodName(@Nullable String destroyMethodName);
+@Nullable
+String getDestroyMethodName();
+
+void setRole(int role);
+int getRole();
+
+void setDescription(@Nullable String description);
+@Nullable
+String getDescription();
+
+boolean isSingleton();
+
+boolean isPrototype();
+
+boolean isAbstract();
+
+@Nullable
+String getResourceDescription();
+
+@Nullable
+BeanDefinition getOriginatingBeanDefinition();
+```
+
+虽然接口方法比较多，但是是不是一下子和我们平时使用 `<bean>` 标签的属性，能够对应上落。
+
+## 1.1 BeanDefinition 的父关系
+
+BeanDefinition 继承 AttributeAccessor 和 BeanMetadataElement 接口。两个接口定义如下：
+
+- `org.springframework.cor.AttributeAccessor` 接口，定义了与其它对象的（元数据）进行连接和访问的约定，即对属性的修改，包括获取、设置、删除。代码如下：
+
+  ```
+  public interface AttributeAccessor {
+  
+  	void setAttribute(String name, @Nullable Object value);
+  
+  	@Nullable
+  	Object getAttribute(String name);
+  
+  	@Nullable
+  	Object removeAttribute(String name);
+  
+  	boolean hasAttribute(String name);
+  
+  	String[] attributeNames();
+  
+  }
+  ```
+
+- `org.springframework.beans.BeanMetadataElement` 接口，Bean 元对象持有的配置元素可以通过 `#getSource()` 方法来获取。代码如下：
+
+  ```
+  public interface BeanMetadataElement {
+  
+  	@Nullable
+  	Object getSource();
+  
+  }
+  ```
+
+## 1.2 BeanDefinition 的子关系
+
+BeanDefinition 子关系，结构如下图：
+
+[![类图](13-Spring-IoC 之解析bean标签：BeanDefinition.assets/6abb56b3651c0eee105c510bb9fc6473.png)](http://static.iocoder.cn/6abb56b3651c0eee105c510bb9fc6473)类图
+
+我们常用的三个实现类有：
+
+- `org.springframework.beans.factory.support.ChildBeanDefinition`
+- `org.springframework.beans.factory.support.RootBeanDefinition`
+- `org.springframework.beans.factory.support.GenericBeanDefinition`
+- ChildBeanDefinition、RootBeanDefinition、GenericBeanDefinition 三者都继承 AbstractBeanDefinition 抽象类，即 AbstractBeanDefinition 对三个子类的共同的类信息进行抽象。
+- 如果配置文件中定义了父 `<bean>` 和 子 `<bean>` ，则父 `<bean>` 用 RootBeanDefinition 表示，子 `<bean>` 用 ChildBeanDefinition 表示，而没有父 `<bean>` 的就使用RootBeanDefinition 表示。
+- GenericBeanDefinition 为一站式服务类。😈 这个解释一脸懵逼？没事，继续往下看。
+
+# 2. 解析 Bean 标签
+
+在 `BeanDefinitionParserDelegate#parseBeanDefinitionElement(Element ele, String beanName, BeanDefinition containingBean)` 方法中，完成解析后，返回的是一个已经完成对 `<bean>` 标签解析的 BeanDefinition 实例。
+
+## 2.1 createBeanDefinition
+
+在该方法内部，首先调用 `#createBeanDefinition(String className, String parentName)` 方法，创建 AbstractBeanDefinition 对象。代码如下：
+
+```
+protected AbstractBeanDefinition createBeanDefinition(@Nullable String className, @Nullable String parentName)
+		throws ClassNotFoundException {
+	return BeanDefinitionReaderUtils.createBeanDefinition(
+			parentName, className, this.readerContext.getBeanClassLoader());
+}
+```
+
+- 委托 BeanDefinitionReaderUtils 创建，代码如下：
+
+  ```
+  // BeanDefinitionReaderUtils.java
+  
+  public static AbstractBeanDefinition createBeanDefinition(
+          @Nullable String parentName, @Nullable String className, @Nullable ClassLoader classLoader) throws ClassNotFoundException {
+      // 创建 GenericBeanDefinition 对象
+      GenericBeanDefinition bd = new GenericBeanDefinition();
+      // 设置 parentName
+      bd.setParentName(parentName);
+      if (className != null) {
+          // 设置 beanClass
+          if (classLoader != null) {
+              bd.setBeanClass(ClassUtils.forName(className, classLoader));
+          // 设置 beanClassName
+          } else {
+              bd.setBeanClassName(className);
+          }
+      }
+      return bd;
+  }
+  ```
+
+  - 该方法主要是，创建 GenericBeanDefinition 对象，并设置 `parentName`、`className`、`beanClass` 属性。
+
+## 2.2 parseBeanDefinitionAttributes
+
+创建完 GenericBeanDefinition 实例后，再调用 `#parseBeanDefinitionAttributes(Element ele, String beanName, BeanDefinition containingBean, AbstractBeanDefinition bd)` 方法，该方法将创建好的 GenericBeanDefinition 实例当做参数，对 `bean` 标签的所有属性进行解析，如下：
+
+```
+// BeanDefinitionParserDelegate.java
+
+public AbstractBeanDefinition parseBeanDefinitionAttributes(Element ele, String beanName,
+        @Nullable BeanDefinition containingBean, AbstractBeanDefinition bd) {
+    // 解析 scope 属性
+    if (ele.hasAttribute(SINGLETON_ATTRIBUTE)) {
+        error("Old 1.x 'singleton' attribute in use - upgrade to 'scope' declaration", ele);
+    } else if (ele.hasAttribute(SCOPE_ATTRIBUTE)) {
+        bd.setScope(ele.getAttribute(SCOPE_ATTRIBUTE));
+    } else if (containingBean != null) {
+        // Take default from containing bean in case of an inner bean definition.
+        bd.setScope(containingBean.getScope());
+    }
+
+    // 解析 abstract 属性
+    if (ele.hasAttribute(ABSTRACT_ATTRIBUTE)) {
+        bd.setAbstract(TRUE_VALUE.equals(ele.getAttribute(ABSTRACT_ATTRIBUTE)));
+    }
+
+    // 解析 lazy-init 属性
+    String lazyInit = ele.getAttribute(LAZY_INIT_ATTRIBUTE);
+    if (DEFAULT_VALUE.equals(lazyInit)) {
+        lazyInit = this.defaults.getLazyInit();
+    }
+    bd.setLazyInit(TRUE_VALUE.equals(lazyInit));
+
+    // 解析 autowire 属性
+    String autowire = ele.getAttribute(AUTOWIRE_ATTRIBUTE);
+    bd.setAutowireMode(getAutowireMode(autowire));
+
+    // 解析 depends-on 属性
+    if (ele.hasAttribute(DEPENDS_ON_ATTRIBUTE)) {
+        String dependsOn = ele.getAttribute(DEPENDS_ON_ATTRIBUTE);
+        bd.setDependsOn(StringUtils.tokenizeToStringArray(dependsOn, MULTI_VALUE_ATTRIBUTE_DELIMITERS));
+    }
+
+    // 解析 autowire-candidate 属性
+    String autowireCandidate = ele.getAttribute(AUTOWIRE_CANDIDATE_ATTRIBUTE);
+    if ("".equals(autowireCandidate) || DEFAULT_VALUE.equals(autowireCandidate)) {
+        String candidatePattern = this.defaults.getAutowireCandidates();
+        if (candidatePattern != null) {
+            String[] patterns = StringUtils.commaDelimitedListToStringArray(candidatePattern);
+            bd.setAutowireCandidate(PatternMatchUtils.simpleMatch(patterns, beanName));
+        }
+    } else {
+        bd.setAutowireCandidate(TRUE_VALUE.equals(autowireCandidate));
+    }
+
+    // 解析 primary 标签
+    if (ele.hasAttribute(PRIMARY_ATTRIBUTE)) {
+        bd.setPrimary(TRUE_VALUE.equals(ele.getAttribute(PRIMARY_ATTRIBUTE)));
+    }
+
+    // 解析 init-method 属性
+    if (ele.hasAttribute(INIT_METHOD_ATTRIBUTE)) {
+        String initMethodName = ele.getAttribute(INIT_METHOD_ATTRIBUTE);
+        bd.setInitMethodName(initMethodName);
+    } else if (this.defaults.getInitMethod() != null) {
+        bd.setInitMethodName(this.defaults.getInitMethod());
+        bd.setEnforceInitMethod(false);
+    }
+
+    // 解析 destroy-method 属性
+    if (ele.hasAttribute(DESTROY_METHOD_ATTRIBUTE)) {
+        String destroyMethodName = ele.getAttribute(DESTROY_METHOD_ATTRIBUTE);
+        bd.setDestroyMethodName(destroyMethodName);
+    } else if (this.defaults.getDestroyMethod() != null) {
+        bd.setDestroyMethodName(this.defaults.getDestroyMethod());
+        bd.setEnforceDestroyMethod(false);
+    }
+
+    // 解析 factory-method 属性
+    if (ele.hasAttribute(FACTORY_METHOD_ATTRIBUTE)) {
+        bd.setFactoryMethodName(ele.getAttribute(FACTORY_METHOD_ATTRIBUTE));
+    }
+    if (ele.hasAttribute(FACTORY_BEAN_ATTRIBUTE)) {
+        bd.setFactoryBeanName(ele.getAttribute(FACTORY_BEAN_ATTRIBUTE));
+    }
+
+    return bd;
+}
+```
+
+从上面代码我们可以清晰地看到对 `bean` 标签属性的解析，这些属性我们在工作中都或多或少用到过。
+
+# 3. 下文预告
+
+完成 `bean` 标签的基本属性解析后，会依次调用 BeanDefinitionParserDelegate 的 `#parseMetaElements(lement ele, BeanMetadataAttributeAccessor attributeAccessor)`、`#parseLookupOverrideSubElements(Element beanEle, MethodOverrides overrides)`、`#parseReplacedMethodSubElements(Element beanEle, MethodOverrides overrides)` 方法，分别对子元素 `meta`、`lookup-method`、`replace-method` 元素完成解析。下篇博文将会对这三个子元素进行详细说明。
\ No newline at end of file
diff --git a/spring/14-Spring-IoC 之解析bean标签：meta、lookup-method、replace-method.md b/spring/14-Spring-IoC 之解析bean标签：meta、lookup-method、replace-method.md
new file mode 100644
index 0000000..0920621
--- /dev/null
+++ b/spring/14-Spring-IoC 之解析bean标签：meta、lookup-method、replace-method.md	
@@ -0,0 +1,317 @@
+# 【死磕 Spring】—— IoC 之解析 <bean> 标签：meta、lookup-method、replace-method
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=2736 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+在上篇博客[【死磕 Spring】—— IoC 之解析 标签：BeanDefinition](http://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-for-BeanDefinition) 中，已经完成了对 `<bean>` 标签属性的解析工作。这篇博文开始，分析**子元素**的解析。
+
+完成 `bean` 标签的基本属性解析后，会依次调用 BeanDefinitionParserDelegate 的 `#parseMetaElements(lement ele, BeanMetadataAttributeAccessor attributeAccessor)`、`#parseLookupOverrideSubElements(Element beanEle, MethodOverrides overrides)`、`#parseReplacedMethodSubElements(Element beanEle, MethodOverrides overrides)` 方法，分别对子元素 `meta`、`lookup-method`、`replace-method` 元素完成解析。三个子元素的作用如下：
+
+- `<meta>` ：元数据。
+- `<lookup-method>` ：Spring 动态改变 bean 里方法的实现。方法执行返回的对象，使用 Spring 内原有的这类对象替换，通过改变方法返回值来动态改变方法。内部实现为使用 cglib 方法，重新生成子类，重写配置的方法和返回对象，达到动态改变的效果。
+
+- `<replace-method>` ：Spring 动态改变 bean 里方法的实现。需要改变的方法，使用 Spring 内原有其他类（需要继承接口`org.springframework.beans.factory.support.MethodReplacer`）的逻辑，替换这个方法。通过改变方法执行逻辑来动态改变方法。
+
+# 1. meta 子元素
+
+> **meta** ：元数据。当需要使用里面的信息时可以通过 key 获取。
+
+meta 所声明的 key 并不会在 Bean 中体现，只是一个额外的声明，当我们需要使用里面的信息时，通过调用 BeanDefinition 的 `#getAttribute(String name)` 方法来获取。该子元素的解析过程，代码如下：
+
+```
+// BeanDefinitionParserDelegate.java
+
+public void parseMetaElements(Element ele, BeanMetadataAttributeAccessor attributeAccessor) {
+    NodeList nl = ele.getChildNodes();
+    // 遍历子节点
+    for (int i = 0; i < nl.getLength(); i++) {
+        Node node = nl.item(i);
+        // <meta key="special-data" value="sprecial stragey" />
+        if (isCandidateElement(node) && nodeNameEquals(node, META_ELEMENT)) { // 标签名为 meta
+            Element metaElement = (Element) node;
+            String key = metaElement.getAttribute(KEY_ATTRIBUTE); // key
+            String value = metaElement.getAttribute(VALUE_ATTRIBUTE); // value
+            // 创建 BeanMetadataAttribute 对象
+            BeanMetadataAttribute attribute = new BeanMetadataAttribute(key, value);
+            attribute.setSource(extractSource(metaElement));
+            // 添加到 BeanMetadataAttributeAccessor 中
+            attributeAccessor.addMetadataAttribute(attribute);
+        }
+    }
+}
+```
+
+- 解析过程较为简单，获取相应的 key - value 构建 BeanMetadataAttribute 对象，然后调用 `BeanMetadataAttributeAccessor#addMetadataAttribute(BeanMetadataAttribute)` 方法，添加 BeanMetadataAttribute 加入到 AbstractBeanDefinition 中。
+
+  > 友情提示：
+  >
+  > AbstractBeanDefinition 继承 BeanMetadataAttributeAccessor 类
+  > BeanMetadataAttributeAccessor 继承 AttributeAccessorSupport 类。
+
+## 1.1 addMetadataAttribute
+
+调用 `BeanMetadataAttributeAccessor#addMetadataAttribute(BeanMetadataAttribute)` 方法，添加 BeanMetadataAttribute 加入到 AbstractBeanDefinition 中。代码如下：
+
+```
+// BeanMetadataAttributeAccessor.java
+
+public void addMetadataAttribute(BeanMetadataAttribute attribute) {
+	super.setAttribute(attribute.getName(), attribute);
+}
+```
+
+- 委托 AttributeAccessorSupport 实现，如下：
+
+```
+// AttributeAccessorSupport.java
+
+/** Map with String keys and Object values. */
+private final Map<String, Object> attributes = new LinkedHashMap<>();
+
+@Override
+public void setAttribute(String name, @Nullable Object value) {
+	Assert.notNull(name, "Name must not be null");
+	if (value != null) {
+		this.attributes.put(name, value);
+	} else {
+		removeAttribute(name);
+	}
+}
+```
+
+`org.springframework.core.AttributeAccessorSupport` ，是接口 AttributeAccessor 的实现者。 AttributeAccessor 接口定义了与其他对象的元数据进行连接和访问的约定，可以通过该接口对属性进行获取、设置、删除操作。
+
+## 1.2 getAttribute
+
+设置元数据后，则可以通过调用 BeanDefinition 的 `#getAttribute(String name)` 方法来获取属性。代码如下：
+
+```
+// AttributeAccessorSupport.java
+
+/** Map with String keys and Object values. */
+private final Map<String, Object> attributes = new LinkedHashMap<>();
+
+@Override
+@Nullable
+public Object getAttribute(String name) {
+	Assert.notNull(name, "Name must not be null");
+	return this.attributes.get(name);
+}
+```
+
+# 2. lookup-method 子元素
+
+> **lookup-method** ：获取器注入，是把一个方法声明为返回某种类型的 bean 但实际要返回的 bean 是在配置文件里面配置的。该方法可以用于设计一些可插拔的功能上，解除程序依赖。
+
+## 2.1 示例
+
+直接上例子：
+
+```
+public interface Car {
+
+    void display();
+
+}
+
+public class Bmw implements Car{
+
+    @Override
+    public void display() {
+        System.out.println("我是 BMW");
+    }
+
+}
+
+public class Hongqi implements Car{
+
+    @Override
+    public void display() {
+        System.out.println("我是 hongqi");
+    }
+
+}
+
+public abstract class Display {
+
+    public void display(){
+        getCar().display();
+    }
+    
+    public abstract Car getCar();
+
+}
+
+public static void main(String[] args) {
+    ApplicationContext context = new ClassPathXmlApplicationContext("classpath:spring.xml");
+    Display display = (Display) context.getBean("display");
+    display.display();
+}
+```
+
+XML 配置内容如下：
+
+```
+<bean id="display" class="org.springframework.core.test1.Display">
+    <lookup-method name="getCar" bean="hongqi"/>
+</bean>
+```
+
+运行结果为：
+
+```
+我是 hongqi
+```
+
+如果将 `bean="hognqi"` 替换为 `bean="bmw"`，则运行结果变成：
+
+```
+我是 BMW
+```
+
+## 2.2 parseLookupOverrideSubElements
+
+看了这个示例，我们初步了解了 `looku-method` 子元素提供的功能了。其解析通过 `#parseLookupOverrideSubElements(Element beanEle, MethodOverrides overrides)` 方法，代码如下：
+
+```
+// BeanDefinitionParserDelegate.java
+
+public void parseLookupOverrideSubElements(Element beanEle, MethodOverrides overrides) {
+    NodeList nl = beanEle.getChildNodes();
+    // 遍历子节点
+    for (int i = 0; i < nl.getLength(); i++) {
+        Node node = nl.item(i);
+        if (isCandidateElement(node) && nodeNameEquals(node, LOOKUP_METHOD_ELEMENT)) { // 标签名为 lookup-method
+            Element ele = (Element) node;
+            String methodName = ele.getAttribute(NAME_ATTRIBUTE); // name
+            String beanRef = ele.getAttribute(BEAN_ELEMENT); // bean
+            // 创建 LookupOverride 对象
+            LookupOverride override = new LookupOverride(methodName, beanRef);
+            override.setSource(extractSource(ele));
+            // 添加到 MethodOverrides 中
+            overrides.addOverride(override);
+        }
+    }
+}
+```
+
+解析过程和 `meta` 子元素没有多大区别，同样是解析 methodName、beanRef 构造一个 LookupOverride 对象，然后记录到 AbstractBeanDefinition 中的 `methodOverrides` 属性中。
+
+在实例化 Bean 的时候，再详细阐述具体的实现过程，这里仅仅只是一个**标记**作用。
+
+# 3. replace-method 子元素
+
+> **replaced-method** ：可以在运行时调用新的方法替换现有的方法，还能动态的更新原有方法的逻辑。
+
+## 3.1 示例
+
+该标签使用方法和 `lookup-method` 标签差不多，只不过替代方法的类需要实现 `org.springframework.beans.factory.support.MethodReplacer` 接口。如下:
+
+```
+public class Method {
+
+    public void display(){
+        System.out.println("我是原始方法");
+    }
+
+}
+
+public class MethodReplace implements MethodReplacer {
+
+    @Override
+    public Object reimplement(Object obj, Method method, Object[] args) throws Throwable {
+        System.out.println("我是替换方法");
+        return null;
+    }
+
+}
+
+public static void main(String[] args) {
+    ApplicationContext context = new ClassPathXmlApplicationContext("classpath:spring.xml");
+    Method method = (Method) context.getBean("method");
+    method.display();
+}
+```
+
+如果 `spring.xml` 文件如下：
+
+```
+<bean id="methodReplace" class="org.springframework.core.test1.MethodReplace"/>
+
+<bean id="method" class="org.springframework.core.test1.Method"/>
+```
+
+则运行结果为：
+
+```
+我是原始方法
+```
+
+增加 `replaced-method` 子元素：
+
+```
+<bean id="methodReplace" class="org.springframework.core.test1.MethodReplace"/>
+
+<bean id="method" class="org.springframework.core.test1.Method">
+
+    <replaced-method name="display" replacer="methodReplace"/>
+
+</bean>
+```
+
+运行结果为：
+
+```
+我是替换方法
+```
+
+## 3.2 parseReplacedMethodSubElements
+
+上面代码演示了 `replaced-method` 子元素的用法，其解析通过 `#parseReplacedMethodSubElements(Element beanEle, MethodOverrides overrides)` 方法，代码如下：
+
+```
+/**
+ * Parse replaced-method sub-elements of the given bean element.
+ */
+public void parseReplacedMethodSubElements(Element beanEle, MethodOverrides overrides) {
+    NodeList nl = beanEle.getChildNodes();
+    // 遍历子节点
+    for (int i = 0; i < nl.getLength(); i++) {
+        Node node = nl.item(i);
+        if (isCandidateElement(node) && nodeNameEquals(node, REPLACED_METHOD_ELEMENT)) { // 标签名为 replace-method
+            Element replacedMethodEle = (Element) node;
+            String name = replacedMethodEle.getAttribute(NAME_ATTRIBUTE); // name
+            String callback = replacedMethodEle.getAttribute(REPLACER_ATTRIBUTE); // replacer
+            // 创建 ReplaceOverride 对象
+            ReplaceOverride replaceOverride = new ReplaceOverride(name, callback);
+            // Look for arg-type match elements. 参见 《spring bean中lookup-method属性 replaced-method属性》 http://linql2010-126-com.iteye.com/blog/2018385
+            List<Element> argTypeEles = DomUtils.getChildElementsByTagName(replacedMethodEle, ARG_TYPE_ELEMENT); // arg-type 子标签
+            for (Element argTypeEle : argTypeEles) {
+                String match = argTypeEle.getAttribute(ARG_TYPE_MATCH_ATTRIBUTE); // arg-type 子标签的 match 属性
+                match = (StringUtils.hasText(match) ? match : DomUtils.getTextValue(argTypeEle));
+                if (StringUtils.hasText(match)) {
+                    replaceOverride.addTypeIdentifier(match);
+                }
+            }
+            replaceOverride.setSource(extractSource(replacedMethodEle));
+            // 添加到 MethodOverrides 中
+            overrides.addOverride(replaceOverride);
+        }
+    }
+}
+```
+
+该子元素和 `lookup-method` 标签的解析过程差不多，同样是提取 `name` 和 `replacer` 属性构建 ReplaceOverride 对象，然后记录到 AbstractBeanDefinition 中的 `methodOverrides` 属性中。
+
+在实例化 Bean 的时候，再详细阐述具体的实现过程，这里仅仅只是一个**标记**作用。
+
+# 4. 小结
+
+对于 `lookup-method` 和 `replaced-method` 两个子元素是如何使用以完成他们所提供的功能，在后续实例化 Bean 的时候会做详细说明。
+
+> 老艿艿：貌似，实际 Spring 使用场景中，也很少用这两个标签。
\ No newline at end of file
diff --git a/spring/15-Spring-IoC 之解析bean标签：constructor-arg、property、qualifier.md b/spring/15-Spring-IoC 之解析bean标签：constructor-arg、property、qualifier.md
new file mode 100644
index 0000000..4afe172
--- /dev/null
+++ b/spring/15-Spring-IoC 之解析bean标签：constructor-arg、property、qualifier.md	
@@ -0,0 +1,477 @@
+# 【死磕 Spring】—— IoC 之解析 <bean> 标签：constructor-arg、property、qualifier
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=2754 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+
+上篇博客 [《【死磕 Spring】—— IoC 之解析 标签：meta、lookup-method、replace-method》](http://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-for-meta-and-look-method-and-replace-method) 分析了 `meta`、`lookup-method`、`replace-method` 三个子元素。这篇博客，我们来分析 `constructor-arg`、`property`、`<qualifier>` 三个子元素。
+
+# 1. constructor-arg 子元素
+
+## 1.1 示例
+
+举个小栗子，代码如下：
+
+```
+public class StudentService {
+
+    private String name;
+
+    private Integer age;
+
+    private BookService bookService;
+
+    StudentService(String name, Integer age, BookService bookService){
+
+        this.name = name;
+
+        this.age = age;
+
+        this.bookService = bookService;
+
+    }
+
+}
+<bean id="bookService" class="org.springframework.core.service.BookService"/>
+
+<bean id="studentService" class="org.springframework.core.service.StudentService">
+    <constructor-arg index="0" value="chenssy"/>
+    <constructor-arg name="age" value="100"/>
+    <constructor-arg name="bookService" ref="bookService"/>
+</bean>
+```
+
+StudentService 定义一个构造函数，配置文件中使用 `constructor-arg` 元素对其配置，该元素可以实现对 StudentService 自动寻找对应的构造函数，并在初始化的时候将值当做参数进行设置。
+
+## 1.2 parseConstructorArgElements
+
+`#parseConstructorArgElements(Element beanEle, BeanDefinition bd)` 方法，完成 `constructor-arg` 子元素的解析。代码如下：
+
+```
+// BeanDefinitionParserDelegate.java
+
+public void parseConstructorArgElements(Element beanEle, BeanDefinition bd) {
+	NodeList nl = beanEle.getChildNodes();
+	for (int i = 0; i < nl.getLength(); i++) {
+		Node node = nl.item(i);
+		if (isCandidateElement(node) && nodeNameEquals(node, CONSTRUCTOR_ARG_ELEMENT)) { // 标签名为 constructor-arg
+			parseConstructorArgElement((Element) node, bd);
+		}
+	}
+}
+```
+
+遍历所有子元素，如果为 `constructor-arg` 标签，则调用 `#parseConstructorArgElement(Element ele, BeanDefinition bd)` 方法，进行解析。
+
+## 1.3 parseConstructorArgElement
+
+```
+// BeanDefinitionParserDelegate.java
+
+public void parseConstructorArgElement(Element ele, BeanDefinition bd) {
+    // 提取 index、type、name 属性值
+    String indexAttr = ele.getAttribute(INDEX_ATTRIBUTE);
+    String typeAttr = ele.getAttribute(TYPE_ATTRIBUTE);
+    String nameAttr = ele.getAttribute(NAME_ATTRIBUTE);
+    if (StringUtils.hasLength(indexAttr)) {
+        try {
+            // 如果有 index
+            int index = Integer.parseInt(indexAttr);
+            if (index < 0) {
+                error("'index' cannot be lower than 0", ele);
+            } else {
+                try {
+                    // <1>
+                    this.parseState.push(new ConstructorArgumentEntry(index));
+                    // <2> 解析 ele 对应属性元素
+                    Object value = parsePropertyValue(ele, bd, null);
+                    // <3> 根据解析的属性元素构造一个 ValueHolder 对象
+                    ConstructorArgumentValues.ValueHolder valueHolder = new ConstructorArgumentValues.ValueHolder(value);
+                    if (StringUtils.hasLength(typeAttr)) {
+                        valueHolder.setType(typeAttr);
+                    }
+                    if (StringUtils.hasLength(nameAttr)) {
+                        valueHolder.setName(nameAttr);
+                    }
+                    valueHolder.setSource(extractSource(ele));
+                    // 不允许重复指定相同参数
+                    if (bd.getConstructorArgumentValues().hasIndexedArgumentValue(index)) {
+                        error("Ambiguous constructor-arg entries for index " + index, ele);
+                    } else {
+                        // <4> 加入到 indexedArgumentValues 中
+                        bd.getConstructorArgumentValues().addIndexedArgumentValue(index, valueHolder);
+                    }
+                } finally {
+                    this.parseState.pop();
+                }
+            }
+        } catch (NumberFormatException ex) {
+            error("Attribute 'index' of tag 'constructor-arg' must be an integer", ele);
+        }
+    } else {
+        try {
+            this.parseState.push(new ConstructorArgumentEntry());
+            // 解析 ele 对应属性元素
+            Object value = parsePropertyValue(ele, bd, null);
+            // 根据解析的属性元素构造一个 ValueHolder 对象
+            ConstructorArgumentValues.ValueHolder valueHolder = new ConstructorArgumentValues.ValueHolder(value);
+            if (StringUtils.hasLength(typeAttr)) {
+                valueHolder.setType(typeAttr);
+            }
+            if (StringUtils.hasLength(nameAttr)) {
+                valueHolder.setName(nameAttr);
+            }
+            valueHolder.setSource(extractSource(ele));
+            // 加入到 indexedArgumentValues 中
+            bd.getConstructorArgumentValues().addGenericArgumentValue(valueHolder);
+        } finally {
+            this.parseState.pop();
+        }
+    }
+}
+```
+
+首先获取 `index`、`type`、`name` 三个属性值，然后根据是否存在 `index` 来区分，执行后续逻辑。其实两者逻辑都**差不多**，总共分为如下几个步骤（以有 `index` 为例）：
+
+1. 在 `<1>` 处，构造 ConstructorArgumentEntry 对象并将其加入到 ParseState 队列中。ConstructorArgumentEntry 表示构造函数的参数。
+2. 在 `<2>` 处，调用 `#parsePropertyValue(Element ele, BeanDefinition bd, String propertyName)` 方法，解析 `constructor-arg` 子元素，返回结果值。详细解析，见 [「1.4 parsePropertyValue」](https://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-for-constructor-arg-and-property-and-qualifier/#) 。
+3. 在 `<3>` 处，根据解析的结果值，构造ConstructorArgumentValues.ValueHolder 实例对象，并将 `type`、`name` 设置到 ValueHolder 中
+4. 在 `<4>` 处，最后，将 ValueHolder 实例对象添加到 `indexedArgumentValues` 集合中。
+
+无 `index` 的处理逻辑差不多，只有几点不同：
+
+- 构造 ConstructorArgumentEntry 对象时是调用**无参**构造函数
+- 最后是将 ValueHolder 实例添加到 `genericArgumentValues` 集合中。
+
+## 1.4 parsePropertyValue
+
+调用 `#parsePropertyValue(Element ele, BeanDefinition bd, String propertyName)` 方法，解析 `constructor-arg` 子元素，返回结果值。代码如下：
+
+```
+/**
+ * Get the value of a property element. May be a list etc.
+ * Also used for constructor arguments, "propertyName" being null in this case.
+ */
+@Nullable
+public Object parsePropertyValue(Element ele, BeanDefinition bd, @Nullable String propertyName) {
+    String elementName = (propertyName != null ?
+            "<property> element for property '" + propertyName + "'" :
+            "<constructor-arg> element");
+
+    // <1> 查找子节点中，是否有 ref、value、list 等元素
+    // Should only have one child element: ref, value, list, etc.
+    NodeList nl = ele.getChildNodes();
+    Element subElement = null;
+    for (int i = 0; i < nl.getLength(); i++) {
+        Node node = nl.item(i);
+        // meta 、description 不处理
+        if (node instanceof Element && !nodeNameEquals(node, DESCRIPTION_ELEMENT) &&
+                !nodeNameEquals(node, META_ELEMENT)) {
+            // Child element is what we're looking for.
+            if (subElement != null) {
+                error(elementName + " must not contain more than one sub-element", ele);
+            } else {
+                subElement = (Element) node;
+            }
+        }
+    }
+
+    // <1> 是否有 ref 属性
+    boolean hasRefAttribute = ele.hasAttribute(REF_ATTRIBUTE);
+    // <1> 是否有 value 属性
+    boolean hasValueAttribute = ele.hasAttribute(VALUE_ATTRIBUTE);
+    // <1> 多个元素存在，报错，存在冲突。
+    if ((hasRefAttribute && hasValueAttribute) || // 1. ref 和 value 都存在
+            ((hasRefAttribute || hasValueAttribute) && subElement != null)) { // 2. ref he value 存在一，并且 subElement 存在
+        error(elementName +
+                " is only allowed to contain either 'ref' attribute OR 'value' attribute OR sub-element", ele);
+    }
+
+    // <2> 将 ref 属性值，构造为 RuntimeBeanReference 实例对象
+    if (hasRefAttribute) {
+        String refName = ele.getAttribute(REF_ATTRIBUTE);
+        if (!StringUtils.hasText(refName)) {
+            error(elementName + " contains empty 'ref' attribute", ele);
+        }
+        RuntimeBeanReference ref = new RuntimeBeanReference(refName);
+        ref.setSource(extractSource(ele));
+        return ref;
+    // <3> 将 value 属性值，构造为 TypedStringValue 实例对象
+    } else if (hasValueAttribute) {
+        TypedStringValue valueHolder = new TypedStringValue(ele.getAttribute(VALUE_ATTRIBUTE));
+        valueHolder.setSource(extractSource(ele));
+        return valueHolder;
+    // <4> 解析子元素
+    } else if (subElement != null) {
+        return parsePropertySubElement(subElement, bd);
+    } else {
+        // Neither child element nor "ref" or "value" attribute found.
+        error(elementName + " must specify a ref or value", ele);
+        return null;
+    }
+}
+```
+
+1. 在
+
+    
+
+   ```
+   <1>
+   ```
+
+    
+
+   处，提取
+
+    
+
+   ```
+   constructor-arg
+   ```
+
+    
+
+   的子元素、
+
+   ```
+   ref
+   ```
+
+    
+
+   属性值和
+
+    
+
+   ```
+   value
+   ```
+
+    
+
+   属性值，对其进行判断。以下两种情况是不允许存在的：
+
+   1. `ref` 和 `value` 属性同时存在 。
+   2. 存在 `ref` 或者 `value` 且又有子元素。
+
+2. 在 `<2>` 处，若存在 `ref` 属性，则获取其值并将其封装进 `org.springframework.beans.factory.config.RuntimeBeanReference` 实例对象中。
+
+3. 在 `<3>` 处，若存在 `value` 属性，则获取其值并将其封装进 `org.springframework.beans.factory.config.TypedStringValue` 实例对象中。
+
+4. 在 `<4>` 处，如果子元素不为空，则调用 `#parsePropertySubElement(Element ele, BeanDefinition bd)` 方法，对子元素进一步解析。详细解析，见 [「1.5 parsePropertySubElement」](https://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-for-constructor-arg-and-property-and-qualifier/#) 中。
+
+## 1.5 parsePropertySubElement
+
+对于 `constructor-arg` 子元素的嵌套子元素，需要调用 `#parsePropertySubElement(Element ele, BeanDefinition bd)` 方法，进一步处理。
+
+```
+/**
+ * Parse a value, ref or collection sub-element of a property or
+ * constructor-arg element.
+ * @param ele subelement of property element; we don't know which yet
+ * @param defaultValueType the default type (class name) for any
+ * {@code <value>} tag that might be created
+ */
+@Nullable
+public Object parsePropertySubElement(Element ele, @Nullable BeanDefinition bd, @Nullable String defaultValueType) {
+	if (!isDefaultNamespace(ele)) {
+		return parseNestedCustomElement(ele, bd);
+	} else if (nodeNameEquals(ele, BEAN_ELEMENT)) { // bean 标签
+		BeanDefinitionHolder nestedBd = parseBeanDefinitionElement(ele, bd);
+		if (nestedBd != null) {
+			nestedBd = decorateBeanDefinitionIfRequired(ele, nestedBd, bd);
+		}
+		return nestedBd;
+	} else if (nodeNameEquals(ele, REF_ELEMENT)) { // ref 标签
+		// A generic reference to any name of any bean.
+		String refName = ele.getAttribute(BEAN_REF_ATTRIBUTE);
+		boolean toParent = false;
+		if (!StringUtils.hasLength(refName)) {
+			// A reference to the id of another bean in a parent context.
+			refName = ele.getAttribute(PARENT_REF_ATTRIBUTE);
+			toParent = true;
+			if (!StringUtils.hasLength(refName)) {
+				error("'bean' or 'parent' is required for <ref> element", ele);
+				return null;
+			}
+		}
+		if (!StringUtils.hasText(refName)) {
+			error("<ref> element contains empty target attribute", ele);
+			return null;
+		}
+		RuntimeBeanReference ref = new RuntimeBeanReference(refName, toParent);
+		ref.setSource(extractSource(ele));
+		return ref;
+	} else if (nodeNameEquals(ele, IDREF_ELEMENT)) { // idref 标签
+		return parseIdRefElement(ele);
+	} else if (nodeNameEquals(ele, VALUE_ELEMENT)) { // value 标签
+		return parseValueElement(ele, defaultValueType);
+	} else if (nodeNameEquals(ele, NULL_ELEMENT)) { // null 标签
+		// It's a distinguished null value. Let's wrap it in a TypedStringValue
+		// object in order to preserve the source location.
+		TypedStringValue nullHolder = new TypedStringValue(null);
+		nullHolder.setSource(extractSource(ele));
+		return nullHolder;
+	} else if (nodeNameEquals(ele, ARRAY_ELEMENT)) { // array 标签
+		return parseArrayElement(ele, bd);
+	} else if (nodeNameEquals(ele, LIST_ELEMENT)) { // list 标签
+		return parseListElement(ele, bd);
+	} else if (nodeNameEquals(ele, SET_ELEMENT)) { // set 标签
+		return parseSetElement(ele, bd);
+	} else if (nodeNameEquals(ele, MAP_ELEMENT)) { // map 标签
+		return parseMapElement(ele, bd);
+	} else if (nodeNameEquals(ele, PROPS_ELEMENT)) { // props 标签
+		return parsePropsElement(ele);
+	} else { // 未知标签
+		error("Unknown property sub-element: [" + ele.getNodeName() + "]", ele);
+		return null;
+	}
+}
+```
+
+上面对各个子类进行分类处理，详细情况，如果各位有兴趣，可以移步源码进行深一步的探究。本文，暂时不做深入分析。
+
+# 2. property 子元素
+
+## 2.1 示例
+
+我们一般使用如下方式，来使用 `property` 子元素。
+
+```
+<bean id="studentService" class="org.springframework.core.service.StudentService">
+    <property name="name" value="chenssy"/>
+    <property name="age" value="18"/>
+</bean>
+```
+
+## 2.2 parsePropertyElements
+
+对于 property 子元素的解析，Spring 调用 `parsePropertyElements(Element beanEle, BeanDefinition bd)` 方法。代码如下：
+
+```
+/**
+ * Parse property sub-elements of the given bean element.
+ */
+public void parsePropertyElements(Element beanEle, BeanDefinition bd) {
+	NodeList nl = beanEle.getChildNodes();
+	for (int i = 0; i < nl.getLength(); i++) {
+		Node node = nl.item(i);
+		if (isCandidateElement(node) && nodeNameEquals(node, PROPERTY_ELEMENT)) { // property 标签
+			parsePropertyElement((Element) node, bd);
+		}
+	}
+}
+```
+
+和 `constructor-arg` 子元素差不多，同样是“提取”( 遍历 )所有的 `property` 的子元素，然后调用 `#parsePropertyElement((Element ele, BeanDefinition b)` 进行解析。
+
+## 2.3 parsePropertyElement
+
+```
+/**
+ * Parse a property element.
+ */
+public void parsePropertyElement(Element ele, BeanDefinition bd) {
+    // 获取 name 属性
+    String propertyName = ele.getAttribute(NAME_ATTRIBUTE);
+    if (!StringUtils.hasLength(propertyName)) {
+        error("Tag 'property' must have a 'name' attribute", ele);
+        return;
+    }
+    this.parseState.push(new PropertyEntry(propertyName));
+    try {
+        // 如果存在相同的 name ，报错
+        if (bd.getPropertyValues().contains(propertyName)) {
+            error("Multiple 'property' definitions for property '" + propertyName + "'", ele);
+            return;
+        }
+        // 解析属性值
+        Object val = parsePropertyValue(ele, bd, propertyName);
+        // 创建 PropertyValue 对象
+        PropertyValue pv = new PropertyValue(propertyName, val);
+        parseMetaElements(ele, pv);
+        pv.setSource(extractSource(ele));
+        // 添加到 PropertyValue 集合中
+        bd.getPropertyValues().addPropertyValue(pv);
+    } finally {
+        this.parseState.pop();
+    }
+}
+```
+
+与解析 `constructor-arg` 子元素步骤差不多：
+
+- 调用 `#parsePropertyElement((Element ele, BeanDefinition b)` 方法， 解析子元素属性值。
+- 然后，根据该值构造 PropertyValue 实例对象。
+- 最后，将 PropertyValue 添加到 BeanDefinition 中的 MutablePropertyValues 中。
+
+# 3. qualifier 子元素
+
+> 老艿艿：小明哥貌似忘记写 `<qualifier>` 标签的解析，不过实际情况下也用的比较少，所以老艿艿，在这里稍微简单写下。
+>
+> 不感兴趣的胖友，可以直接跳过这块内容。
+
+## 3.1 示例
+
+见 [《Spring 注解实现Bean依赖注入之 @Qualifier》](http://www.voidcn.com/article/p-vdgrbkrm-bqu.html) 文章。
+
+## 3.2 parseQualifierElement
+
+`#parseQualifierElement(Element ele, AbstractBeanDefinition bd)` 方法，完成 `qualifier` 子元素的解析。代码如下：
+
+```
+/**
+ * Parse a qualifier element.
+ */
+public void parseQualifierElement(Element ele, AbstractBeanDefinition bd) {
+    // 解析 type 属性
+    String typeName = ele.getAttribute(TYPE_ATTRIBUTE);
+    if (!StringUtils.hasLength(typeName)) { // 必须有 type
+        error("Tag 'qualifier' must have a 'type' attribute", ele);
+        return;
+    }
+    this.parseState.push(new QualifierEntry(typeName));
+    try {
+        // 创建 AutowireCandidateQualifier 对象
+        AutowireCandidateQualifier qualifier = new AutowireCandidateQualifier(typeName);
+        qualifier.setSource(extractSource(ele));
+        // 解析 value 属性，并设置到 AutowireCandidateQualifier 中
+        String value = ele.getAttribute(VALUE_ATTRIBUTE);
+        if (StringUtils.hasLength(value)) {
+            qualifier.setAttribute(AutowireCandidateQualifier.VALUE_KEY, value);
+        }
+        // 遍历子节点
+        NodeList nl = ele.getChildNodes();
+        for (int i = 0; i < nl.getLength(); i++) {
+            Node node = nl.item(i);
+            if (isCandidateElement(node) && nodeNameEquals(node, QUALIFIER_ATTRIBUTE_ELEMENT)) { // attribute 标签
+                Element attributeEle = (Element) node;
+                String attributeName = attributeEle.getAttribute(KEY_ATTRIBUTE); // attribute 标签的 key 属性
+                String attributeValue = attributeEle.getAttribute(VALUE_ATTRIBUTE); // attribute 标签的 value 属性
+                if (StringUtils.hasLength(attributeName) && StringUtils.hasLength(attributeValue)) {
+                    // 创建 BeanMetadataAttribute 对象
+                    BeanMetadataAttribute attribute = new BeanMetadataAttribute(attributeName, attributeValue);
+                    attribute.setSource(extractSource(attributeEle));
+                    // 添加到 attributes 中
+                    qualifier.addMetadataAttribute(attribute);
+                } else {
+                    error("Qualifier 'attribute' tag must have a 'name' and 'value'", attributeEle);
+                    return;
+                }
+            }
+        }
+        // 添加到 qualifiers 中
+        bd.addQualifier(qualifier);
+    } finally {
+        this.parseState.pop();
+    }
+}
+```
+
+代码比较简单，胖友自己研究下哈。
\ No newline at end of file
diff --git a/spring/16-Spring-IoC 之解析bean标签：解析自定义标签.md b/spring/16-Spring-IoC 之解析bean标签：解析自定义标签.md
new file mode 100644
index 0000000..18301fe
--- /dev/null
+++ b/spring/16-Spring-IoC 之解析bean标签：解析自定义标签.md	
@@ -0,0 +1,109 @@
+# 【死磕 Spring】—— IoC 之解析 <bean> 标签：解析自定义标签
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=2754 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+前面四篇文章都是分析 Bean 默认标签的解析过程，包括 [基本属性](https://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-for-decorateBeanDefinitionIfRequired/#)、六个子元素（[`meta`](https://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-for-decorateBeanDefinitionIfRequired/#)、[`lookup-method`](https://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-for-decorateBeanDefinitionIfRequired/#)、[`replaced-method`](https://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-for-decorateBeanDefinitionIfRequired/#)、[`constructor-arg`](https://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-for-decorateBeanDefinitionIfRequired/#)、[`property`](https://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-for-decorateBeanDefinitionIfRequired/#)、[`qualifier`](https://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-for-decorateBeanDefinitionIfRequired/#)），涉及内容较多，拆分成了四篇文章，导致我们已经忘记从哪里出发的了。所以，我们先来**回顾**下。
+
+DefaultBeanDefinitionDocumentReader 的 `#processBeanDefinition(Element ele, BeanDefinitionParserDelegate delegate)` 方法，负责 `<bean>` 标签的解析：
+
+- 在解析过程中，首先调用 `BeanDefinitionParserDelegate#parseBeanDefinitionElement(Element ele)` 方法，完成**默认标签**的解析。
+- 如果解析成功（返回的 `bdHolder != null` ），则调用 `BeanDefinitionParserDelegate#decorateBeanDefinitionIfRequired(Element ele, BeanDefinitionHolder definitionHolder)` 方法，完成**自定义标签**元素的解析。
+
+# 1. decorateBeanDefinitionIfRequired
+
+前面四篇文章已经分析了默认标签的解析，**所以这篇文章分析自定义标签的解析**。代码如下：
+
+```
+// BeanDefinitionParserDelegate.java
+
+public BeanDefinitionHolder decorateBeanDefinitionIfRequired(
+        Element ele, BeanDefinitionHolder definitionHolder, @Nullable BeanDefinition containingBd) {
+
+    BeanDefinitionHolder finalDefinition = definitionHolder;
+
+    // <1> 遍历属性，查看是否有适用于装饰的【属性】
+    // Decorate based on custom attributes first.
+    NamedNodeMap attributes = ele.getAttributes();
+    for (int i = 0; i < attributes.getLength(); i++) {
+        Node node = attributes.item(i);
+        finalDefinition = decorateIfRequired(node, finalDefinition, containingBd);
+    }
+
+    // <2> 遍历子节点，查看是否有适用于修饰的【子节点】
+    // Decorate based on custom nested elements.
+    NodeList children = ele.getChildNodes();
+    for (int i = 0; i < children.getLength(); i++) {
+        Node node = children.item(i);
+        if (node.getNodeType() == Node.ELEMENT_NODE) {
+            finalDefinition = decorateIfRequired(node, finalDefinition, containingBd);
+        }
+    }
+    return finalDefinition;
+}
+```
+
+- `<1>` 和 `<2>` 处，都是遍历，前者遍历的是属性( `attributes` )，后者遍历的是子节点( `childNodes` )，最终调用的都是 `#decorateIfRequired(Node node, BeanDefinitionHolder originalDef, BeanDefinition containingBd)` 方法，装饰对应的节点( Node )。详细解析，见 [「2. decorateIfRequired」](https://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-for-decorateBeanDefinitionIfRequired/#) 。
+
+# 2. decorateIfRequired
+
+`#decorateIfRequired(Node node, BeanDefinitionHolder originalDef, BeanDefinition containingBd)` 方法，装饰对应的节点( Node )。代码如下：
+
+```
+// BeanDefinitionParserDelegate.java
+
+public BeanDefinitionHolder decorateIfRequired(
+        Node node, BeanDefinitionHolder originalDef, @Nullable BeanDefinition containingBd) {
+    // <1> 获取自定义标签的命名空间
+    String namespaceUri = getNamespaceURI(node);
+    // <2> 过滤掉默认命名标签
+    if (namespaceUri != null && !isDefaultNamespace(namespaceUri)) {
+        // <2> 获取相应的处理器
+        NamespaceHandler handler = this.readerContext.getNamespaceHandlerResolver().resolve(namespaceUri);
+        if (handler != null) {
+            // <3> 进行装饰处理
+            BeanDefinitionHolder decorated =
+                    handler.decorate(node, originalDef, new ParserContext(this.readerContext, this, containingBd));
+            if (decorated != null) {
+                return decorated;
+            }
+        } else if (namespaceUri.startsWith("http://www.springframework.org/")) {
+            error("Unable to locate Spring NamespaceHandler for XML schema namespace [" + namespaceUri + "]", node);
+        } else {
+            // A custom namespace, not to be handled by Spring - maybe "xml:...".
+            if (logger.isDebugEnabled()) {
+                logger.debug("No Spring NamespaceHandler found for XML schema namespace [" + namespaceUri + "]");
+            }
+        }
+    }
+    return originalDef;
+}
+```
+
+- 在 `<1>` 处，首先获取自定义标签的命名空间。
+- 在 `<2>` 处，如果**不是默认的命名空间**，则根据该命名空间获取相应的处理器。
+- 在 `<3>` 处，如果处理器存在，则进行装饰处理。
+
+上述过程的详细解析，见 [《【死磕 Spring】—— IoC 之解析 标签：解析自定义标签》](http://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-in-parseCustomElement) 一文。
+
+# 3. 小结
+
+至此，BeanDefinition 的解析过程已经全部完成了，下面做一个简要的总结：
+
+解析 BeanDefinition 的入口在 DefaultBeanDefinitionDocumentReader 的`#parseBeanDefinitions(Element root, BeanDefinitionParserDelegate delegate)` 方法。该方法会根据命令空间来判断标签是默认标签还是自定义标签，其中：
+
+- 默认标签，由 `#parseDefaultElement(Element ele, BeanDefinitionParserDelegate delegate)` 方法来实现
+- 自定义标签，由 BeanDefinitionParserDelegate 的 `#parseCustomElement(Element ele, @Nullable BeanDefinition containingBd)` 方法来实现。
+
+在默认标签解析中，会根据标签名称的不同进行 `import`、`alias`、`bean`、`beans` 四大标签进行处理。其中 `bean` 标签的解析为核心，它由 `processBeanDefinition(Element ele, BeanDefinitionParserDelegate delegate)` 方法实现。
+
+`processBeanDefinition(Element ele, BeanDefinitionParserDelegate delegate)` 方法，开始进入解析核心工作，分为三步：
+
+1. 解析默认标签的**默认**标签：`BeanDefinitionParserDelegate#parseBeanDefinitionElement(Element ele, ...)` 方法。该方法会依次解析 `<bean>` 标签的属性、各个子元素，解析完成后返回一个 GenericBeanDefinition 实例对象。
+2. 解析默认标签下的**自定义**标签：`BeanDefinitionParserDelegate#decorateBeanDefinitionIfRequired(Element ele, BeanDefinitionHolder definitionHolder)` 方法。
+3. 注册解析的 BeanDefinition：`BeanDefinitionReaderUtils#registerBeanDefinition(BeanDefinitionHolder definitionHolder, BeanDefinitionRegistry registry)` 方法。
\ No newline at end of file
diff --git a/spring/17-Spring-IoC 之解析自定义标签.assets/64a6aa7283cd9e6ae5070162ae007872.png b/spring/17-Spring-IoC 之解析自定义标签.assets/64a6aa7283cd9e6ae5070162ae007872.png
new file mode 100644
index 0000000..7f31463
Binary files /dev/null and b/spring/17-Spring-IoC 之解析自定义标签.assets/64a6aa7283cd9e6ae5070162ae007872.png differ
diff --git a/spring/17-Spring-IoC 之解析自定义标签.assets/b53b2484800ee0e35be4510d9ebe2891.png b/spring/17-Spring-IoC 之解析自定义标签.assets/b53b2484800ee0e35be4510d9ebe2891.png
new file mode 100644
index 0000000..a789db2
Binary files /dev/null and b/spring/17-Spring-IoC 之解析自定义标签.assets/b53b2484800ee0e35be4510d9ebe2891.png differ
diff --git a/spring/17-Spring-IoC 之解析自定义标签.md b/spring/17-Spring-IoC 之解析自定义标签.md
new file mode 100644
index 0000000..9471d25
--- /dev/null
+++ b/spring/17-Spring-IoC 之解析自定义标签.md	
@@ -0,0 +1,595 @@
+# 【死磕 Spring】—— IoC 之解析自定义标签
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=TODO 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+在分析自定义标签的解析之前，我们有必要了解自定义标签的使用。
+
+# 1. 使用自定义标签
+
+扩展 Spring 自定义标签配置一般需要以下几个步骤：
+
+1. 创建一个需要扩展的组件。
+2. 定义一个 XSD 文件，用于描述组件内容。
+3. 创建一个实现 `org.springframework.beans.factory.xml.AbstractSingleBeanDefinitionParser` 接口的类，用来解析 XSD 文件中的定义和组件定义。
+4. 创建一个 Handler，继承 `org.springframework.beans.factory.xml.NamespaceHandlerSupport` 抽象类 ，用于将组件注册到 Spring 容器。
+5. 编写 `spring.handlers` 和 `Spring.schemas` 文件。
+
+下面就按照上面的步骤来实现一个自定义标签组件。
+
+## 1.1 创建组件
+
+该组件就是一个普通的 Java Bean，没有任何特别之处。代码如下：
+
+```
+public class User {
+
+    private String id;
+    private String userName;
+    private String email;
+
+}
+```
+
+## 1.2 定义 XSD 文件
+
+```
+<?xml version="1.0" encoding="UTF-8"?>
+<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.cmsblogs.com/schema/user" targetNamespace="http://www.cmsblogs.com/schema/user" elementFormDefault="qualified">
+
+    <xsd:element name="user">
+        <xsd:complexType>
+            <xsd:attribute name="id" type="xsd:string" />
+            <xsd:attribute name="userName" type="xsd:string" />
+            <xsd:attribute name="email" type="xsd:string" />
+        </xsd:complexType>
+    </xsd:element>
+
+</xsd:schema>
+```
+
+上面除了对 User 这个 Java Bean 进行了描述外，还定义了 `xmlns="http://www.cmsblogs.com/schema/user"` 和 `targetNamespace="http://www.cmsblogs.com/schema/user"` 这两个值，这两个值在后面是有大作用的。
+
+## 1.3 定义 Parser 类
+
+定义一个 Parser 类，该类继承 AbstractSingleBeanDefinitionParser ，并实现 `#getBeanClass(Element element)` 和 `#doParse(Element element, BeanDefinitionBuilder builder)` 两个方法。主要是用于解析 XSD 文件中的定义和组件定义。
+
+```
+public class UserDefinitionParser extends AbstractSingleBeanDefinitionParser {
+
+    @Override
+    protected Class<?> getBeanClass(Element element) {
+        return User.class;
+    }
+
+    @Override
+    protected void doParse(Element element, BeanDefinitionBuilder builder) {
+        String id = element.getAttribute("id");
+        String userName = element.getAttribute("userName");
+        String email = element.getAttribute("email");
+
+        if (StringUtils.hasText(id)) {
+            builder.addPropertyValue("id", id);
+        }
+
+        if (StringUtils.hasText(userName)) {
+            builder.addPropertyValue("userName", userName);
+        }
+
+        if (StringUtils.hasText(email)) {
+            builder.addPropertyValue("email", email);
+        }
+    }
+
+}
+```
+
+## 1.4 定义 NamespaceHandler 类
+
+定义 NamespaceHandler 类，继承 NamespaceHandlerSupport ,主要目的是将组件注册到 Spring 容器中。
+
+```
+public class UserNamespaceHandler extends NamespaceHandlerSupport {
+
+    @Override
+    public void init() {
+        registerBeanDefinitionParser("user", new UserDefinitionParser());
+    }
+
+}
+```
+
+## 1.5 定义 spring.handlers 文件
+
+```
+http\://www.cmsblogs.com/schema/user=org.springframework.core.customelement.UserNamespaceHandler
+```
+
+## 1.6 定义 Spring.schemas 文件
+
+```
+http\://www.cmsblogs.com/schema/user.xsd=user.xsd
+```
+
+## 1.7 运行
+
+经过上面几个步骤，就可以使用自定义的标签了。在 xml 配置文件中使用如下：
+
+```
+<?xml version="1.0" encoding="UTF-8"?>
+<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+       xmlns:myTag="http://www.cmsblogs.com/schema/user"
+       xsi:schemaLocation="http://www.springframework.org/schema/beans
+       http://www.springframework.org/schema/beans/spring-beans.xsd
+        http://www.cmsblogs.com/schema/user http://www.cmsblogs.com/schema/user.xsd">
+
+    <myTag:user id="user" email="12233445566@qq.com" userName="chenssy" />
+
+</beans>
+```
+
+运行测试：
+
+```
+public static void main(String[] args){
+    ApplicationContext context = new ClassPathXmlApplicationContext("spring.xml");
+    User user = (User) context.getBean("user");
+    System.out.println(user.getUserName() + "----" + user.getEmail());
+}
+```
+
+运行结果如下图：
+
+[![运行结果](17-Spring-IoC 之解析自定义标签.assets/64a6aa7283cd9e6ae5070162ae007872.png)](http://static.iocoder.cn/64a6aa7283cd9e6ae5070162ae007872)运行结果
+
+# 2. 解析自定义标签
+
+上面已经演示了 Spring 自定义标签的使用，下面就来分析自定义标签的解析过程。
+
+## 2.1 parseCustomElement
+
+DefaultBeanDefinitionDocumentReader 的`#parseBeanDefinitions(Element root, BeanDefinitionParserDelegate delegate)` 方法，负责标签的解析工作，根据命名空间的不同进行不同标签的解析。其中，**自定义标签**由 BeanDefinitionParserDelegate 的 `#parseCustomElement(Element ele, BeanDefinition containingBd)` 方法来实现。代码如下：
+
+```
+@Nullable
+public BeanDefinition parseCustomElement(Element ele) {
+    return parseCustomElement(ele, null);
+}
+
+@Nullable
+public BeanDefinition parseCustomElement(Element ele, @Nullable BeanDefinition containingBd) {
+    // <1> 获取 namespaceUri
+    String namespaceUri = getNamespaceURI(ele);
+    if (namespaceUri == null) {
+        return null;
+    }
+    // <2> 根据 namespaceUri 获取相应的 Handler
+    NamespaceHandler handler = this.readerContext.getNamespaceHandlerResolver().resolve(namespaceUri);
+    if (handler == null) {
+        error("Unable to locate Spring NamespaceHandler for XML schema namespace [" + namespaceUri + "]", ele);
+        return null;
+    }
+    // 调用自定义的 Handler 处理
+    return handler.parse(ele, new ParserContext(this.readerContext, this, containingBd));
+}
+```
+
+处理过程分为三步：
+
+1. 调用 `#getNamespaceURI((Node node)` 方法，获取 `namespaceUri` 。代码如下：
+
+   ```
+   @Nullable
+   public String getNamespaceURI(Node node) {
+   	return node.getNamespaceURI();
+   }
+   ```
+
+2. 调用 `XmlReaderContext#getNamespaceHandlerResolver()` 方法，获得命名空间的解析器。详细解析，见 [「2.2 getNamespaceHandlerResolver」](https://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-in-parseCustomElement/#) 。
+
+3. 调用 `NamespaceHandlerResolver#resolve(String namespaceUri)` 方法，根据 `namespaceUri` 获取相应的 Handler 对象。这个映射关系我们在 `spring.handlers` 中已经定义了，所以只需要找到该类，然后初始化返回。详细解析，见 [「2.3 resolve」](https://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-in-parseCustomElement/#) 。
+
+4. 调用 `NamespaceHandler#parse(Element element, ParserContext parserContext)` 方法，调用自定义的 Handler 处理。详细解析，见 [「2.4 parse」](https://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-in-parseCustomElement/#) 。
+
+## 2.2 getNamespaceHandlerResolver
+
+调用 XmlReaderContext 的 `#getNamespaceHandlerResolver()` 方法，返回的命名空间的解析器，代码如下：
+
+```
+/**
+ * NamespaceHandler 解析器
+ */
+private final NamespaceHandlerResolver namespaceHandlerResolver;
+
+public final NamespaceHandlerResolver getNamespaceHandlerResolver() {
+	return this.namespaceHandlerResolver;
+}
+```
+
+### 2.2.1 NamespaceHandlerResolver 的初始化
+
+那么，NamespaceHandlerResolver 是什么时候进行初始化的呢？
+
+这里需要回退到博文 [《【死磕 Spring】—— IoC 之注册 BeanDefinitions》](http://svip.iocoder.cn/Spring/IoC-register-BeanDefinitions) ，在这篇博客中提到在注册 BeanDefinition 时：
+
+- 首先，是通过 XmlBeanDefinitionReader 的 `#createBeanDefinitionDocumentReader()` 方法，获取 Document 解析器 BeanDefinitionDocumentReader 实例。
+- 然后，调用 BeanDefinitionDocumentReader 实例的 `#registerBeanDefinitions(Document doc, XmlReaderContext readerContext)` 方法，进行注册。而该方法需要提供两个参数，一个是 Document 实例 `doc`，一个是 XmlReaderContext 实例 `readerContext` 。
+
+`readerContext` 实例对象由 XmlBeanDefinitionReader 的 `#createReaderContext(Resource resource)` 方法创建。`namespaceHandlerResolver` 实例对象就是在这个时候初始化的，代码如下：
+
+```
+// XmlBeanDefinitionReader.java
+public XmlReaderContext createReaderContext(Resource resource) {
+	return new XmlReaderContext(resource, this.problemReporter, this.eventListener,
+			this.sourceExtractor, this, getNamespaceHandlerResolver());
+}
+```
+
+- XmlReaderContext 构造函数中最后一个参数就是 NamespaceHandlerResolver 对象，该对象由 `getNamespaceHandlerResolver()` 提供，如下：
+
+  ```
+  // XmlBeanDefinitionReader.java
+  
+  public NamespaceHandlerResolver getNamespaceHandlerResolver() {
+  	if (this.namespaceHandlerResolver == null) {
+  		this.namespaceHandlerResolver = createDefaultNamespaceHandlerResolver();
+  	}
+  	return this.namespaceHandlerResolver;
+  }
+  
+  protected NamespaceHandlerResolver createDefaultNamespaceHandlerResolver() {
+  	ClassLoader cl = (getResourceLoader() != null ? getResourceLoader().getClassLoader() : getBeanClassLoader());
+  	return new DefaultNamespaceHandlerResolver(cl); // <x>
+  }
+  ```
+
+  - 从 `<x>` 处，我们可以看到，NamespaceHandlerResolver 对象的**最终类型**是 `org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver` 。
+
+## 2.3 resolve
+
+所以， `getNamespaceHandlerResolver().resolve(namespaceUri)` 调用的就是 DefaultNamespaceHandlerResolver 的 `#resolve(String namespaceUri)` 方法。代码如下：
+
+```
+@Override
+@Nullable
+public NamespaceHandler resolve(String namespaceUri) {
+    // <1> 获取所有已经配置的 Handler 映射
+    Map<String, Object> handlerMappings = getHandlerMappings();
+    // <2> 根据 namespaceUri 获取 handler 的信息
+    Object handlerOrClassName = handlerMappings.get(namespaceUri);
+    // <3.1> 不存在
+    if (handlerOrClassName == null) {
+        return null;
+    // <3.2> 已经初始化
+    } else if (handlerOrClassName instanceof NamespaceHandler) {
+        return (NamespaceHandler) handlerOrClassName;
+    // <3.3> 需要进行初始化
+    } else {
+        String className = (String) handlerOrClassName;
+        try {
+            // 获得类，并创建 NamespaceHandler 对象
+            Class<?> handlerClass = ClassUtils.forName(className, this.classLoader);
+            if (!NamespaceHandler.class.isAssignableFrom(handlerClass)) {
+                throw new FatalBeanException("Class [" + className + "] for namespace [" + namespaceUri +
+                        "] does not implement the [" + NamespaceHandler.class.getName() + "] interface");
+            }
+            NamespaceHandler namespaceHandler = (NamespaceHandler) BeanUtils.instantiateClass(handlerClass);
+            // 初始化 NamespaceHandler 对象
+            namespaceHandler.init();
+            // 添加到缓存
+            handlerMappings.put(namespaceUri, namespaceHandler);
+            return namespaceHandler;
+        } catch (ClassNotFoundException ex) {
+            throw new FatalBeanException("Could not find NamespaceHandler class [" + className +
+                    "] for namespace [" + namespaceUri + "]", ex);
+        } catch (LinkageError err) {
+            throw new FatalBeanException("Unresolvable class definition for NamespaceHandler class [" +
+                    className + "] for namespace [" + namespaceUri + "]", err);
+        }
+    }
+}
+```
+
+- `<1>` 处，首先，调用 `#getHandlerMappings()` 方法，获取所有配置文件中的映射关系 `handlerMappings` 。详细解析，胖友先跳到 [「2.3.1 getHandlerMappings」](https://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-in-parseCustomElement/#) ，看完就回到此处，继续往下走。
+
+- `<2>` 处，然后，根据 `namespaceUri` 获取 handler 的信息。
+
+- `<3.1>` 处，`handlerOrClassName` 不存在，则返回 `null` 空。
+
+- `<3.2>` 处，`handlerOrClassName` 已经初始化成 NamespaceHandler 对象，直接返回它。
+
+- ```
+  <3.3>
+  ```
+
+   
+
+  处，
+
+  ```
+  handlerOrClassName
+  ```
+
+   
+
+  还是类路径，则创建 NamespaceHandler 对象，并调用
+
+   
+
+  ```
+  NamespaceHandler#init()
+  ```
+
+   
+
+  方法，初始化 NamespaceHandler 对象。详细解析，见
+
+   
+
+  「2.3.2 init」
+
+   
+
+  。
+
+  - 另外，创建的 NamespaceHandler 对象，会添加到 `handlerMappings` 中，进行缓存。
+
+### 2.3.1 getHandlerMappings
+
+```
+/** ClassLoader to use for NamespaceHandler classes. */
+@Nullable
+private final ClassLoader classLoader;
+
+/**
+ * NamespaceHandler 映射配置文件地址
+ *
+ * Resource location to search for.
+ */
+private final String handlerMappingsLocation;
+
+/**
+ * Stores the mappings from namespace URI to NamespaceHandler class name / instance.
+ *
+ * NamespaceHandler 映射。
+ *
+ * key：命名空间
+ * value：分成两种情况：1）未初始化时，对应的 NamespaceHandler 的类路径；2）已初始化，对应的 NamespaceHandler 对象
+ */
+@Nullable
+private volatile Map<String, Object> handlerMappings;
+
+/**
+ * Load the specified NamespaceHandler mappings lazily.
+ */
+private Map<String, Object> getHandlerMappings() {
+	// 双重检查锁，延迟加载
+	Map<String, Object> handlerMappings = this.handlerMappings;
+	if (handlerMappings == null) {
+		synchronized (this) {
+			handlerMappings = this.handlerMappings;
+			if (handlerMappings == null) {
+				if (logger.isTraceEnabled()) {
+					logger.trace("Loading NamespaceHandler mappings from [" + this.handlerMappingsLocation + "]");
+				}
+				try {
+					// 读取 handlerMappingsLocation
+					Properties mappings = PropertiesLoaderUtils.loadAllProperties(this.handlerMappingsLocation, this.classLoader);
+					if (logger.isTraceEnabled()) {
+						logger.trace("Loaded NamespaceHandler mappings: " + mappings);
+					}
+					// 初始化到 handlerMappings 中
+					handlerMappings = new ConcurrentHashMap<>(mappings.size());
+					CollectionUtils.mergePropertiesIntoMap(mappings, handlerMappings);
+					this.handlerMappings = handlerMappings;
+				} catch (IOException ex) {
+					throw new IllegalStateException(
+							"Unable to load NamespaceHandler mappings from location [" + this.handlerMappingsLocation + "]", ex);
+				}
+			}
+		}
+	}
+	return handlerMappings;
+}
+```
+
+- 虽然代码比较长，但是逻辑实际很简单。
+- 通过延迟加载( lazy-init )的方式，加载 `handlerMappingsLocation` 中配置的 NamespaceHandler 的映射，到 `handlerMappings` 中。
+- `handlerMappings` 的**值属性**有 2 种情况，胖友仔细看下注释。
+
+### 2.3.2 init
+
+实现 NamespaceHandler 的 `#init()` 方法，主要是将自定义标签解析器进行注册。例如，我们自定义 UserNamespaceHandler 的 `#init()` 方法，代码如下：
+
+```
+// UserNamespaceHandler.java
+
+@Override
+public void init() {
+    registerBeanDefinitionParser("user",new UserDefinitionParser());
+}
+```
+
+- 直接调用父类 NamespaceHandlerSupport 的 `#registerBeanDefinitionParser(String elementName, BeanDefinitionParser parser)` 方法，注册指定元素的 BeanDefinitionParser 解析器。
+
+#### 2.3.2.1 registerBeanDefinitionParser
+
+NamespaceHandlerSupport 的 `#registerBeanDefinitionParser(String elementName, BeanDefinitionParser parser)` 方法，注册指定元素的 BeanDefinitionParser 解析器。代码如下：
+
+```
+// NamespaceHandlerSupport.java
+/**
+ * Stores the {@link BeanDefinitionParser} implementations keyed by the
+ * local name of the {@link Element Elements} they handle.
+ *
+ * key：元素名
+ * value：对应 BeanDefinitionParser 的解析器
+ */
+private final Map<String, BeanDefinitionParser> parsers = new HashMap<>();
+
+protected final void registerBeanDefinitionParser(String elementName, BeanDefinitionParser parser) {
+	this.parsers.put(elementName, parser);
+}
+```
+
+- 其实就是将映射关系放在一个 Map 结构的 `parsers` 对象中。
+
+## 2.4 parse
+
+完成后返回 NamespaceHandler 对象，然后调用其 `#parse(Element element, ParserContext parserContext)` 方法开始自定义标签的解析。代码如下：
+
+```
+// NamespaceHandlerSupport.java
+@Override
+@Nullable
+public BeanDefinition parse(Element element, ParserContext parserContext) {
+	// <1> 获得元素对应的 BeanDefinitionParser 对象
+	BeanDefinitionParser parser = findParserForElement(element, parserContext);
+	// <2> 执行解析
+	return (parser != null ? parser.parse(element, parserContext) : null);
+}
+```
+
+- `<1>` 处，调用 `#findParserForElement(Element element, ParserContext parserContext)` 方法，获取对应的 BeanDefinitionParser 实例。实际上，其实就是获取在 NamespaceHandlerSupport 的 `#registerBeanDefinitionParser()` 方法里面注册的实例对象。代码如下：
+
+  ```
+    /**
+     * Locates the {@link BeanDefinitionParser} from the register implementations using
+     * the local name of the supplied {@link Element}.
+     */
+    @Nullable
+    private BeanDefinitionParser findParserForElement(Element element, ParserContext parserContext) {
+  // 获得元素名
+    	String localName = parserContext.getDelegate().getLocalName(element);
+    	// 获得 BeanDefinitionParser 对象
+    	BeanDefinitionParser parser = this.parsers.get(localName);
+    	if (parser == null) {
+    		parserContext.getReaderContext().fatal(
+    				"Cannot locate BeanDefinitionParser for element [" + localName + "]", element);
+    	}
+    	return parser;
+    }
+  ```
+
+  - 首先，获取 `localName`，在上面的例子中就是：`"user` 。
+  - 然后，从 Map 实例 `parsers` 中获取 BeanDefinitionParser 对象。在上面的例子中就是：UserBeanDefinitionParser 对象。
+
+- `<2>` 处，返回 BeanDefinitionParser 对象后，调用其 `#parse(Element element, ParserContext parserContext)` 方法。该方法在 AbstractBeanDefinitionParser 中实现，代码如下：
+
+  ```
+    // AbstractBeanDefinitionParser.java
+  
+    @Override
+    @Nullable
+    public final BeanDefinition parse(Element element, ParserContext parserContext) {
+  // <1> 内部解析，返回 AbstractBeanDefinition 对象
+    	AbstractBeanDefinition definition = parseInternal(element, parserContext);
+    	if (definition != null && !parserContext.isNested()) {
+    		try {
+    		    // 解析 id 属性
+    			String id = resolveId(element, definition, parserContext);
+    			if (!StringUtils.hasText(id)) {
+    				parserContext.getReaderContext().error(
+    						"Id is required for element '" + parserContext.getDelegate().getLocalName(element)
+    								+ "' when used as a top-level tag", element);
+    			}
+    			// 解析 aliases 属性
+    			String[] aliases = null;
+    			if (shouldParseNameAsAliases()) {
+    				String name = element.getAttribute(NAME_ATTRIBUTE);
+    				if (StringUtils.hasLength(name)) {
+    					aliases = StringUtils.trimArrayElements(StringUtils.commaDelimitedListToStringArray(name));
+    				}
+    			}
+    			// 创建 BeanDefinitionHolder 对象
+    			BeanDefinitionHolder holder = new BeanDefinitionHolder(definition, id, aliases);
+    			// 注册 BeanDefinition
+    			registerBeanDefinition(holder, parserContext.getRegistry());
+    			// 触发事件
+    			if (shouldFireEvents()) {
+    				BeanComponentDefinition componentDefinition = new BeanComponentDefinition(holder);
+    				postProcessComponentDefinition(componentDefinition);
+    				parserContext.registerComponent(componentDefinition);
+    			}
+    		} catch (BeanDefinitionStoreException ex) {
+    			String msg = ex.getMessage();
+    			parserContext.getReaderContext().error((msg != null ? msg : ex.toString()), element);
+    			return null;
+    		}
+    	}
+    	return definition;
+    }
+  ```
+
+  - 核心在 `<1>` 处 `#parseInternal(Element element, ParserContext parserContext)` 方法。为什么这么说？因为该方法返回的是 AbstractBeanDefinition 对象。从前面**默认标签**的解析过程来看，我们就可以判断该方法就是将标签解析为 AbstractBeanDefinition ，且后续代码都是将 AbstractBeanDefinition 转换为 BeanDefinitionHolder 对象。所以真正的解析工作都交由 `#parseInternal(Element element, ParserContext parserContext)` 方法来实现。关于该方法，详细解析，见 [「2.4.1 parseInternal」](https://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-in-parseCustomElement/#) 。
+  - 其它逻辑，例如 `#resolveId(Element element, AbstractBeanDefinition definition, ParserContext parserContext)` 方法，都比较简单，感兴趣的胖友，可以自己去看。
+
+### 2.4.1 parseInternal
+
+`#parseInternal(Element element, ParserContext parserContext)` 方法，解析 XML 元素为 AbstractBeanDefinition 对象。代码如下：
+
+```
+// AbstractSingleBeanDefinitionParser.java
+
+@Override
+protected final AbstractBeanDefinition parseInternal(Element element, ParserContext parserContext) {
+    // 创建 BeanDefinitionBuilder 对象
+    BeanDefinitionBuilder builder = BeanDefinitionBuilder.genericBeanDefinition();
+    // 获取父类元素
+    String parentName = getParentName(element);
+    if (parentName != null) {
+        builder.getRawBeanDefinition().setParentName(parentName);
+    }
+    // 获取自定义标签中的 class，这个时候会去调用自定义解析中的 getBeanClass()
+    Class<?> beanClass = getBeanClass(element);
+    if (beanClass != null) {
+        builder.getRawBeanDefinition().setBeanClass(beanClass);
+    } else {
+        // beanClass 为 null，意味着子类并没有重写 getBeanClass() 方法，则尝试去判断是否重写了 getBeanClassName()
+        String beanClassName = getBeanClassName(element);
+        if (beanClassName != null) {
+            builder.getRawBeanDefinition().setBeanClassName(beanClassName);
+        }
+    }
+    // 设置 source 属性
+    builder.getRawBeanDefinition().setSource(parserContext.extractSource(element));
+    // 设置 scope 属性
+    BeanDefinition containingBd = parserContext.getContainingBeanDefinition();
+    if (containingBd != null) {
+        // Inner bean definition must receive same scope as containing bean.
+        builder.setScope(containingBd.getScope());
+    }
+    // 设置 lazy-init 属性
+    if (parserContext.isDefaultLazyInit()) {
+        // Default-lazy-init applies to custom bean definitions as well.
+        builder.setLazyInit(true);
+    }
+    // 调用子类的 doParse() 进行解析
+    doParse(element, parserContext, builder);
+    return builder.getBeanDefinition();
+}
+```
+
+- 在该方法中我们主要关注两个方法：`#getBeanClass((Element element)` 、`#doParse(Element element, BeanDefinitionBuilder builder)`。
+- 对于 `getBeanClass()` 方法，AbstractSingleBeanDefinitionParser 类并没有提供具体实现，而是直接返回 `null` ，**意味着它希望子类能够重写该方法**。当然，如果没有重写该方法，这会去调用 `#getBeanClassName()` ，判断子类是否已经重写了该方法。
+- 对于 `#doParse(Element element, BeanDefinitionBuilder builder)` 方法，则是直接**空实现**。
+
+😈 所以对于 `#parseInternal(Element element, ParserContext parserContext)` 方法 而言，它总是期待它的子类能够实现 `#getBeanClass((Element element)` 、`#doParse(Element element, BeanDefinitionBuilder builder)` 方法。其中，`#doParse(Element element, BeanDefinitionBuilder builder)` **方法尤为重要**！如果，你不提供该方法的实现，怎么来解析自定义标签呢？此时，胖友可以回过头，再看一眼在 [「1.3 定义 Parser 类」](https://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-in-parseCustomElement/#) 的 UserDefinitionParser 实现类，是不是已经能够很好理解咧。
+
+# 3. 小结
+
+至此，自定义标签的解析过程已经分析完成了。其实整个过程还是较为简单：
+
+- 首先，会加载 `spring.handlers` 文件，将其中内容进行一个解析，形成 `<namespaceUri, 类路径>` 这样的一个映射。
+- 然后，根据获取的 `namespaceUri` 就可以得到相应的类路径，对其进行初始化等到相应的 NamespaceHandler 对象。
+- 之后，调用该 NamespaceHandler 的 `#parse(...)` 方法，在该方法中根据标签的 `localName` 得到相应的 BeanDefinitionParser 实例对象。
+- 最后，调用该 BeanDefinitionParser 的 `#parse(...)` 方法。该方法定义在 AbstractBeanDefinitionParser 抽象类中，核心逻辑封装在其 `#parseInternal(...)` 方法中，该方法返回一个 AbstractBeanDefinition 实例对象，其主要是在 AbstractSingleBeanDefinitionParser 中实现。对于自定义的 Parser 类，其需要实现 `#getBeanClass()` 或者 `#getBeanClassName()` 任一方法，和 `#doParse(...)` 方法。
+
+整体流程如[下图](https://gitee.com/chenssy/blog-home/raw/master/image/201811/spring-201807151001.png)：
+
+[![spring-201807151001](17-Spring-IoC 之解析自定义标签.assets/b53b2484800ee0e35be4510d9ebe2891.png)](http://static.iocoder.cn/b53b2484800ee0e35be4510d9ebe2891)spring-201807151001
\ No newline at end of file
diff --git a/spring/18-Spring-IoC 之注册解析的 BeanDefinitions.md b/spring/18-Spring-IoC 之注册解析的 BeanDefinitions.md
new file mode 100644
index 0000000..c27e1b1
--- /dev/null
+++ b/spring/18-Spring-IoC 之注册解析的 BeanDefinitions.md	
@@ -0,0 +1,312 @@
+# 【死磕 Spring】—— IoC 之注册解析的 BeanDefinitions
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=2763 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+DefaultBeanDefinitionDocumentReader 的 `#processBeanDefinition()` 方法，完成 Bean 标签解析的核心工作。代码如下：
+
+```
+// DefaultBeanDefinitionDocumentReader.java
+
+protected void processBeanDefinition(Element ele, BeanDefinitionParserDelegate delegate) {
+    // 进行 bean 元素解析。
+    // 如果解析成功，则返回 BeanDefinitionHolder 对象。而 BeanDefinitionHolder 为 name 和 alias 的 BeanDefinition 对象
+    // 如果解析失败，则返回 null 。
+    BeanDefinitionHolder bdHolder = delegate.parseBeanDefinitionElement(ele);
+    if (bdHolder != null) {
+        // 进行自定义标签处理
+        bdHolder = delegate.decorateBeanDefinitionIfRequired(ele, bdHolder);
+        try {
+            // 进行 BeanDefinition 的注册
+            // Register the final decorated instance.
+            BeanDefinitionReaderUtils.registerBeanDefinition(bdHolder, getReaderContext().getRegistry());
+        } catch (BeanDefinitionStoreException ex) {
+            getReaderContext().error("Failed to register bean definition with name '" +
+                    bdHolder.getBeanName() + "'", ele, ex);
+        }
+        // 发出响应事件，通知相关的监听器，已完成该 Bean 标签的解析。
+        // Send registration event.
+        getReaderContext().fireComponentRegistered(new BeanComponentDefinition(bdHolder));
+    }
+}
+```
+
+- 解析工作分为三步：
+  - 1、解析默认标签。
+  - 2、解析默认标签后下得自定义标签。
+  - 3、注册解析后的 BeanDefinition 。
+- 经过前面两个步骤的解析，这时的 BeanDefinition 已经可以满足后续的使用要求了，**那么接下来的工作就是将这些 BeanDefinition 进行注册，也就是完成第三步**。
+
+# 1. BeanDefinitionReaderUtils
+
+注册 BeanDefinition ，由 `BeanDefinitionReaderUtils.registerBeanDefinition()` 完成。代码如下：
+
+```
+// BeanDefinitionReaderUtils.java
+ 
+public static void registerBeanDefinition(
+        BeanDefinitionHolder definitionHolder, BeanDefinitionRegistry registry)
+        throws BeanDefinitionStoreException {
+
+    // 注册 beanName
+    // Register bean definition under primary name.
+    String beanName = definitionHolder.getBeanName();
+    registry.registerBeanDefinition(beanName, definitionHolder.getBeanDefinition());
+
+    // 注册 alias
+    // Register aliases for bean name, if any.
+    String[] aliases = definitionHolder.getAliases();
+    if (aliases != null) {
+        for (String alias : aliases) {
+            registry.registerAlias(beanName, alias);
+        }
+    }
+}
+```
+
+- 首先，通过 `beanName` 注册 BeanDefinition 。详细解析，见 [2.1 通过 beanName 注册](https://svip.iocoder.cn/Spring/IoC-register-BeanDefinitions-really/#) 。
+- 然后，再通过注册别名 `alias` 和 `beanName` 的映射。详细解析，见 [2.2 注册 alias 和 beanName 的映射](https://svip.iocoder.cn/Spring/IoC-register-BeanDefinitions-really/#) 。
+
+# 2. BeanDefinitionRegistry
+
+BeanDefinition 的注册，由接口 `org.springframework.beans.factory.support.BeanDefinitionRegistry` 定义。
+
+## 2.1 通过 beanName 注册
+
+调用 BeanDefinitionRegistry 的 `#registerBeanDefinition(String beanName, BeanDefinition beanDefinition)` 方法，实现通过 `beanName` 注册 BeanDefinition 。代码如下：
+
+```
+// DefaultListableBeanFactory.java
+
+/** Whether to allow re-registration of a different definition with the same name. */
+private boolean allowBeanDefinitionOverriding = true;
+
+/** Map of bean definition objects, keyed by bean name. */
+private final Map<String, BeanDefinition> beanDefinitionMap = new ConcurrentHashMap<>(256);
+/** List of bean definition names, in registration order. */
+private volatile List<String> beanDefinitionNames = new ArrayList<>(256);
+/** List of names of manually registered singletons, in registration order. */
+private volatile Set<String> manualSingletonNames = new LinkedHashSet<>(16);
+/** Cached array of bean definition names in case of frozen configuration. */
+@Nullable
+private volatile String[] frozenBeanDefinitionNames;
+
+@Override
+public void registerBeanDefinition(String beanName, BeanDefinition beanDefinition)
+        throws BeanDefinitionStoreException {
+
+    // 校验 beanName 与 beanDefinition 非空
+    Assert.hasText(beanName, "Bean name must not be empty");
+    Assert.notNull(beanDefinition, "BeanDefinition must not be null");
+
+    // <1> 校验 BeanDefinition 。
+    // 这是注册前的最后一次校验了，主要是对属性 methodOverrides 进行校验。
+    if (beanDefinition instanceof AbstractBeanDefinition) {
+        try {
+            ((AbstractBeanDefinition) beanDefinition).validate();
+        } catch (BeanDefinitionValidationException ex) {
+            throw new BeanDefinitionStoreException(beanDefinition.getResourceDescription(), beanName,
+                    "Validation of bean definition failed", ex);
+        }
+    }
+
+    // <2> 从缓存中获取指定 beanName 的 BeanDefinition
+    BeanDefinition existingDefinition = this.beanDefinitionMap.get(beanName);
+    // <3> 如果已经存在
+    if (existingDefinition != null) {
+        // 如果存在但是不允许覆盖，抛出异常
+        if (!isAllowBeanDefinitionOverriding()) {
+            throw new BeanDefinitionOverrideException(beanName, beanDefinition, existingDefinition);
+        // 覆盖 beanDefinition 大于 被覆盖的 beanDefinition 的 ROLE ，打印 info 日志
+        } else if (existingDefinition.getRole() < beanDefinition.getRole()) {
+            // e.g. was ROLE_APPLICATION, now overriding with ROLE_SUPPORT or ROLE_INFRASTRUCTURE
+            if (logger.isInfoEnabled()) {
+                logger.info("Overriding user-defined bean definition for bean '" + beanName +
+                        "' with a framework-generated bean definition: replacing [" +
+                        existingDefinition + "] with [" + beanDefinition + "]");
+            }
+        // 覆盖 beanDefinition 与 被覆盖的 beanDefinition 不相同，打印 debug 日志
+        } else if (!beanDefinition.equals(existingDefinition)) {
+            if (logger.isDebugEnabled()) {
+                logger.debug("Overriding bean definition for bean '" + beanName +
+                        "' with a different definition: replacing [" + existingDefinition +
+                        "] with [" + beanDefinition + "]");
+            }
+        // 其它，打印 debug 日志
+        } else {
+            if (logger.isTraceEnabled()) {
+                logger.trace("Overriding bean definition for bean '" + beanName +
+                        "' with an equivalent definition: replacing [" + existingDefinition +
+                        "] with [" + beanDefinition + "]");
+            }
+        }
+        // 允许覆盖，直接覆盖原有的 BeanDefinition 到 beanDefinitionMap 中。
+        this.beanDefinitionMap.put(beanName, beanDefinition);
+    // <4> 如果未存在
+    } else {
+        // 检测创建 Bean 阶段是否已经开启，如果开启了则需要对 beanDefinitionMap 进行并发控制
+        if (hasBeanCreationStarted()) {
+            // beanDefinitionMap 为全局变量，避免并发情况
+            // Cannot modify startup-time collection elements anymore (for stable iteration)
+            synchronized (this.beanDefinitionMap) {
+                // 添加到 BeanDefinition 到 beanDefinitionMap 中。
+                this.beanDefinitionMap.put(beanName, beanDefinition);
+                // 添加 beanName 到 beanDefinitionNames 中
+                List<String> updatedDefinitions = new ArrayList<>(this.beanDefinitionNames.size() + 1);
+                updatedDefinitions.addAll(this.beanDefinitionNames);
+                updatedDefinitions.add(beanName);
+                this.beanDefinitionNames = updatedDefinitions;
+                // 从 manualSingletonNames 移除 beanName
+                if (this.manualSingletonNames.contains(beanName)) {
+                    Set<String> updatedSingletons = new LinkedHashSet<>(this.manualSingletonNames);
+                    updatedSingletons.remove(beanName);
+                    this.manualSingletonNames = updatedSingletons;
+                }
+            }
+        } else {
+            // Still in startup registration phase
+            // 添加到 BeanDefinition 到 beanDefinitionMap 中。
+            this.beanDefinitionMap.put(beanName, beanDefinition);
+            // 添加 beanName 到 beanDefinitionNames 中
+            this.beanDefinitionNames.add(beanName);
+            // 从 manualSingletonNames 移除 beanName
+            this.manualSingletonNames.remove(beanName);
+        }
+        
+        this.frozenBeanDefinitionNames = null;
+    }
+
+    // <5> 重新设置 beanName 对应的缓存
+    if (existingDefinition != null || containsSingleton(beanName)) {
+        resetBeanDefinition(beanName);
+    }
+}
+```
+
+处理过程如下：
+
+- `<1>` 对 BeanDefinition 进行校验，该校验也是注册过程中的最后一次校验了，主要是对 AbstractBeanDefinition 的 `methodOverrides` 属性进行校验。
+
+- `<2>` 根据 `beanName` 从缓存中获取 BeanDefinition 对象。
+
+- `<3>` 如果缓存中存在，则根据 `allowBeanDefinitionOverriding` 标志来判断是否允许覆盖。如果允许则直接覆盖。否则，抛出 BeanDefinitionStoreException 异常。
+
+- ```
+  <4>
+  ```
+
+   
+
+  若缓存中没有指定
+
+   
+
+  ```
+  beanName
+  ```
+
+   
+
+  的 BeanDefinition，则判断当前阶段是否已经开始了 Bean 的创建阶段？如果是，则需要对 beanDefinitionMap 进行加锁控制并发问题，否则直接设置即可。
+
+  - 对于 `#hasBeanCreationStarted()` 方法，后续做详细介绍，这里不过多阐述。
+
+- `<5>` 若缓存中存在该 `beanName` 或者单例 bean 集合中存在该 `beanName` ，则调用 `#resetBeanDefinition(String beanName)` 方法，重置 BeanDefinition 缓存。
+
+😈 其实整段代码的核心就在于 `this.beanDefinitionMap.put(beanName, beanDefinition);` 代码块。而 BeanDefinition 的缓存也不是神奇的东西，就是定义一个 Map ：
+
+- `key` 为 `beanName` 。
+- `value` 为 BeanDefinition 对象。
+
+## 2.2 注册 alias 和 beanName 的映射
+
+调用 BeanDefinitionRegistry 的 `#registerAlias(String name, String alias)` 方法，注册 `alias` 和 `beanName` 的映射关系。代码如下：
+
+```
+// SimpleAliasRegistry.java
+
+/** Map from alias to canonical name. */
+// key: alias
+// value: beanName
+private final Map<String, String> aliasMap = new ConcurrentHashMap<>(16);
+
+@Override
+public void registerAlias(String name, String alias) {
+    // 校验 name 、 alias
+    Assert.hasText(name, "'name' must not be empty");
+    Assert.hasText(alias, "'alias' must not be empty");
+    synchronized (this.aliasMap) {
+        // name == alias 则去掉alias
+        if (alias.equals(name)) {
+            this.aliasMap.remove(alias);
+            if (logger.isDebugEnabled()) {
+                logger.debug("Alias definition '" + alias + "' ignored since it points to same name");
+            }
+        } else {
+            // 获取 alias 已注册的 beanName
+            String registeredName = this.aliasMap.get(alias);
+            // 已存在
+            if (registeredName != null) {
+                // 相同，则 return ，无需重复注册
+                if (registeredName.equals(name)) {
+                    // An existing alias - no need to re-register
+                    return;
+                }
+                // 不允许覆盖，则抛出 IllegalStateException 异常
+                if (!allowAliasOverriding()) {
+                    throw new IllegalStateException("Cannot define alias '" + alias + "' for name '" +
+                            name + "': It is already registered for name '" + registeredName + "'.");
+                }
+                if (logger.isDebugEnabled()) {
+                    logger.debug("Overriding alias '" + alias + "' definition for registered name '" +
+                            registeredName + "' with new target name '" + name + "'");
+                }
+            }
+            // 校验，是否存在循环指向
+            checkForAliasCircle(name, alias);
+            // 注册 alias
+            this.aliasMap.put(alias, name);
+            if (logger.isTraceEnabled()) {
+                logger.trace("Alias definition '" + alias + "' registered for name '" + name + "'");
+            }
+        }
+    }
+}
+```
+
+- 注册 `alias` 和注册 BeanDefinition 的过程差不多。
+
+- 在最后，调用了 `#checkForAliasCircle()` 来对别名进行了**循环**检测。代码如下：
+
+  ```
+  protected void checkForAliasCircle(String name, String alias) {
+      if (hasAlias(alias, name)) {
+          throw new IllegalStateException("Cannot register alias '" + alias +
+                  "' for name '" + name + "': Circular reference - '" +
+                  name + "' is a direct or indirect alias for '" + alias + "' already");
+      }
+  }
+  public boolean hasAlias(String name, String alias) {
+      for (Map.Entry<String, String> entry : this.aliasMap.entrySet()) {
+          String registeredName = entry.getValue();
+          if (registeredName.equals(name)) {
+              String registeredAlias = entry.getKey();
+              if (registeredAlias.equals(alias) || hasAlias(registeredAlias, alias)) {
+                  return true;
+              }
+          }
+      }
+      return false;
+  }
+  ```
+
+  - 如果 `name`、`alias` 分别为 1 和 3 ，则构成 `（1,3）` 的映射。加入，此时集合中存在`（A,1）`、`（3,A）` 的映射，意味着出现循环指向的情况，则抛出 IllegalStateException 异常。
+
+# 3. 小结
+
+到这里 BeanDefinition 基于 `beanName` 和 `alias` 的维度，都已经注入到缓存中，下一步则是等待初始化使用了。我们，后续的文章，继续搞起来。
\ No newline at end of file
diff --git a/spring/19-Spring-IoC 之装载 BeanDefinitions 总结.assets/1e395ffbda4fe58a49897854a7d72ce9.png b/spring/19-Spring-IoC 之装载 BeanDefinitions 总结.assets/1e395ffbda4fe58a49897854a7d72ce9.png
new file mode 100644
index 0000000..fee62e7
Binary files /dev/null and b/spring/19-Spring-IoC 之装载 BeanDefinitions 总结.assets/1e395ffbda4fe58a49897854a7d72ce9.png differ
diff --git a/spring/19-Spring-IoC 之装载 BeanDefinitions 总结.assets/38419d23d29c83a4758f73f85281e076.png b/spring/19-Spring-IoC 之装载 BeanDefinitions 总结.assets/38419d23d29c83a4758f73f85281e076.png
new file mode 100644
index 0000000..7cb9a11
Binary files /dev/null and b/spring/19-Spring-IoC 之装载 BeanDefinitions 总结.assets/38419d23d29c83a4758f73f85281e076.png differ
diff --git a/spring/19-Spring-IoC 之装载 BeanDefinitions 总结.md b/spring/19-Spring-IoC 之装载 BeanDefinitions 总结.md
new file mode 100644
index 0000000..dd00376
--- /dev/null
+++ b/spring/19-Spring-IoC 之装载 BeanDefinitions 总结.md	
@@ -0,0 +1,447 @@
+# 【死磕 Spring】—— IoC 之装载 BeanDefinitions 总结
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=todo 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+前面 13 篇博文从源码层次，分析了 IoC BeanDefinition 装载的整个过程，这篇就这些内容做一个总结将其连贯起来。
+
+在前文提过，IoC 容器的初始化过程分为三步骤：Resource 定位、BeanDefinition 的载入和解析，BeanDefinition 注册。
+
+[![整体步骤](19-Spring-IoC 之装载 BeanDefinitions 总结.assets/1e395ffbda4fe58a49897854a7d72ce9.png)](http://static.iocoder.cn/1e395ffbda4fe58a49897854a7d72ce9)整体步骤
+
+- **Resource 定位**。我们一般用外部资源来描述 Bean 对象，所以在初始化 IoC 容器的第一步就是需要定位这个外部资源。在上一篇博客（[《【死磕 Spring】—— IoC 之 Spring 统一资源加载策略》](http://svip.iocoder.cn/Spring/IoC-load-Resource)）已经详细说明了资源加载的过程。
+
+- BeanDefinition 的装载和解析
+
+  。装载就是 BeanDefinition 的载入。BeanDefinitionReader 读取、解析 Resource 资源，也就是将用户定义的 Bean 表示成 IoC 容器的内部数据结构：BeanDefinition 。
+
+  - 在 IoC 容器内部维护着一个 BeanDefinition Map 的数据结构
+  - 在配置文件中每一个 `<bean>` 都对应着一个 BeanDefinition 对象。
+
+- BeanDefinition 注册
+
+  。向 IoC 容器注册在第二步解析好的 BeanDefinition，这个过程是通过 BeanDefinitionRegistry 接口来实现的。在 IoC 容器内部其实是将第二个过程解析得到的 BeanDefinition 注入到一个 HashMap 容器中，IoC 容器就是通过这个 HashMap 来维护这些 BeanDefinition 的。
+
+  - 在这里需要注意的一点是这个过程并没有完成依赖注入（Bean 创建），Bean 创建是发生在应用第一次调用 `#getBean(...)` 方法，向容器索要 Bean 时。
+  - 当然我们可以通过设置预处理，即对某个 Bean 设置 `lazyinit = false` 属性，那么这个 Bean 的依赖注入就会在容器初始化的时候完成。
+
+还记得在博客 [《【死磕 Spring】—— IoC 之加载 BeanDefinition》](http://svip.iocoder.cn/Spring/IoC-load-BeanDefinitions) 中提供的一段代码吗？这里我们同样也以这段代码作为我们研究 IoC 初始化过程的开端，如下：
+
+```
+ClassPathResource resource = new ClassPathResource("bean.xml");
+DefaultListableBeanFactory factory = new DefaultListableBeanFactory();
+XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(factory);
+reader.loadBeanDefinitions(resource);
+```
+
+刚刚开始的时候可能对上面这几行代码不知道什么意思，现在应该就一目了然了：
+
+- `ClassPathResource resource = new ClassPathResource("bean.xml");` ： 根据 Xml 配置文件创建 Resource 资源对象。ClassPathResource 是 Resource 接口的子类，`bean.xml` 文件中的内容是我们定义的 Bean 信息。
+- `DefaultListableBeanFactory factory = new DefaultListableBeanFactory();` ：创建一个 BeanFactory 。DefaultListableBeanFactory 是 BeanFactory 的一个子类，BeanFactory 作为一个接口，其实它本身是不具有独立使用的功能的，而 DefaultListableBeanFactory 则是真正可以独立使用的 IoC 容器，它是整个 Spring IoC 的始祖，在后续会有专门的文章来分析它。
+- `XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(factory);` ：创建 XmlBeanDefinitionReader 读取器，用于载入 BeanDefinition 。
+- `reader.loadBeanDefinitions(resource);`：开始 BeanDefinition 的载入和注册进程，完成后的 BeanDefinition 放置在 IoC 容器中。
+
+# 1. Resource 定位
+
+Spring 为了解决资源定位的问题，提供了两个接口：Resource、ResourceLoader，其中：
+
+- Resource 接口是 Spring 统一资源的抽象接口
+- ResourceLoader 则是 Spring 资源加载的统一抽象。
+- 关于Resource、ResourceLoader 的更多知识请关注 [《【死磕 Spring】—— IoC 之 Spring 统一资源加载策略》](http://svip.iocoder.cn/Spring/IoC-load-Resource)
+
+Resource 资源的定位需要 Resource 和 ResourceLoader 两个接口互相配合，在上面那段代码中 `new ClassPathResource("bean.xml")` 为我们定义了资源，那么 ResourceLoader 则是在什么时候初始化的呢？看 XmlBeanDefinitionReader 构造方法：
+
+```
+// XmlBeanDefinitionReader.java
+public XmlBeanDefinitionReader(BeanDefinitionRegistry registry) {
+	super(registry);
+}
+```
+
+- 直接调用父类 AbstractBeanDefinitionReader 构造方法，代码如下：
+
+  ```
+  // AbstractBeanDefinitionReader.java
+  
+  protected AbstractBeanDefinitionReader(BeanDefinitionRegistry registry) {
+  	Assert.notNull(registry, "BeanDefinitionRegistry must not be null");
+  	this.registry = registry;
+  	// Determine ResourceLoader to use.
+  	if (this.registry instanceof ResourceLoader) {
+  		this.resourceLoader = (ResourceLoader) this.registry;
+  	}	else {
+  		this.resourceLoader = new PathMatchingResourcePatternResolver();
+  	}
+  
+  	// Inherit Environment if possible
+  	if (this.registry instanceof EnvironmentCapable) {
+  		this.environment = ((EnvironmentCapable) this.registry).getEnvironment();
+  	} else {
+  		this.environment = new StandardEnvironment();
+  	}
+  }
+  ```
+
+  - 核心在于设置 resourceLoader 这段，如果设置了 ResourceLoader 则用设置的，否则使用 PathMatchingResourcePatternResolver ，该类是一个集大成者的 ResourceLoader。
+
+# 2. BeanDefinition 的载入和解析
+
+`reader.loadBeanDefinitions(resource);` 代码段，开启 BeanDefinition 的解析过程。如下：
+
+```
+// XmlBeanDefinitionReader.java
+@Override
+public int loadBeanDefinitions(Resource resource) throws BeanDefinitionStoreException {
+	return loadBeanDefinitions(new EncodedResource(resource));
+}
+```
+
+- 在这个方法会将资源 resource 包装成一个 EncodedResource 实例对象，然后调用 `#loadBeanDefinitions(EncodedResource encodedResource)` 方法。而将 Resource 封装成 EncodedResource 主要是为了对 Resource 进行编码，保证内容读取的正确性。代码如下：
+
+  ```
+  // XmlBeanDefinitionReader.java
+  
+  public int loadBeanDefinitions(EncodedResource encodedResource) throws BeanDefinitionStoreException {
+  	// ... 省略一些代码
+  	try {
+  		// 将资源文件转为 InputStream 的 IO 流
+  		InputStream inputStream = encodedResource.getResource().getInputStream();
+  		try {
+  			// 从 InputStream 中得到 XML 的解析源
+  			InputSource inputSource = new InputSource(inputStream);
+  			if (encodedResource.getEncoding() != null) {
+  				inputSource.setEncoding(encodedResource.getEncoding());
+  			}
+  			// ... 具体的读取过程
+  			return doLoadBeanDefinitions(inputSource, encodedResource.getResource());
+  		}
+  		finally {
+  			inputStream.close();
+  		}
+  	}
+  	// 省略一些代码
+  }
+  ```
+
+  - 从 `encodedResource` 源中获取 xml 的解析源，然后调用 `#doLoadBeanDefinitions(InputSource inputSource, Resource resource)` 方法，执行具体的解析过程。
+
+    ```
+    // XmlBeanDefinitionReader.java
+    
+    protected int doLoadBeanDefinitions(InputSource inputSource, Resource resource)
+    			throws BeanDefinitionStoreException {
+    	try {
+    		// 获取 XML Document 实例
+    		Document doc = doLoadDocument(inputSource, resource);
+    		// 根据 Document 实例，注册 Bean 信息
+    		int count = registerBeanDefinitions(doc, resource);
+    		return count;
+    	}
+    	// ... 省略一堆配置
+    }
+    ```
+
+    - 在该方法中主要做两件事：
+    - 1、根据 xml 解析源获取相应的 Document 对象。详细解析，见 [「2.1 转换为 Document 对象」](https://svip.iocoder.cn/Spring/IoC-load-BeanDefinitions-summary/#) 。
+    - 2、调用 `#registerBeanDefinitions(Document doc, Resource resource)` 方法，开启 BeanDefinition 的解析注册过程。详细解析，见 [「2.2 注册 BeanDefinition」](https://svip.iocoder.cn/Spring/IoC-load-BeanDefinitions-summary/#) 。
+
+## 2.1 转换为 Document 对象
+
+调用 `#doLoadDocument(InputSource inputSource, Resource resource)` 方法，会将 Bean 定义的资源转换为 Document 对象。代码如下：
+
+```
+// XmlBeanDefinitionReader.java
+
+protected Document doLoadDocument(InputSource inputSource, Resource resource) throws Exception {
+	return this.documentLoader.loadDocument(inputSource, getEntityResolver(), this.errorHandler,
+			getValidationModeForResource(resource), isNamespaceAware());
+}
+```
+
+该方法接受五个参数：
+
+- `inputSource` ：加载 Document 的 Resource 源。
+
+- ```
+  entityResolver
+  ```
+
+   
+
+  ：解析文件的解析器。
+
+  - 【重要】详细解析，见 [《【死磕 Spring】—— IoC 之获取 Document 对象》](http://svip.iocoder.cn/Spring/IoC-load-Document) 。
+
+- `errorHandler` ：处理加载 Document 对象的过程的错误。
+
+- ```
+  validationMode
+  ```
+
+   
+
+  ：验证模式。
+
+  - 【重要】详细解析，见 [《【死磕 Spring】—— IoC 之获取验证模型》](http://svip.iocoder.cn/Spring/IoC-Validation-Mode-For-Resource) 。
+
+- `namespaceAware` ：命名空间支持。如果要提供对 XML 名称空间的支持，则为 `true` 。
+
+------
+
+`#loadDocument(InputSource inputSource, EntityResolver entityResolver, ErrorHandler errorHandler, int validationMode, boolean namespaceAware)` 方法，在类 DefaultDocumentLoader 中提供了实现。代码如下：
+
+```
+// DefaultDocumentLoader.java
+
+@Override
+public Document loadDocument(InputSource inputSource, EntityResolver entityResolver,
+		ErrorHandler errorHandler, int validationMode, boolean namespaceAware) throws Exception {
+	// 创建 DocumentBuilderFactory
+	DocumentBuilderFactory factory = createDocumentBuilderFactory(validationMode, namespaceAware);
+	// 创建 DocumentBuilder
+	DocumentBuilder builder = createDocumentBuilder(factory, entityResolver, errorHandler);
+	// 解析 XML InputSource 返回 Document 对象
+	return builder.parse(inputSource);
+}
+```
+
+## 2.2 注册 BeanDefinition 流程
+
+这到这里，就已经将定义的 Bean 资源文件，载入并转换为 Document 对象了。那么，下一步就是如何将其解析为 SpringIoC 管理的 BeanDefinition 对象，并将其注册到容器中。这个过程由方法 `#registerBeanDefinitions(Document doc, Resource resource)` 方法来实现。代码如下：
+
+```
+// XmlBeanDefinitionReader.java
+
+public int registerBeanDefinitions(Document doc, Resource resource) throws BeanDefinitionStoreException {
+	// 创建 BeanDefinitionDocumentReader 对象
+	BeanDefinitionDocumentReader documentReader = createBeanDefinitionDocumentReader();
+	// 获取已注册的 BeanDefinition 数量
+	int countBefore = getRegistry().getBeanDefinitionCount();
+	// 创建 XmlReaderContext 对象
+	// 注册 BeanDefinition
+	documentReader.registerBeanDefinitions(doc, createReaderContext(resource));
+	// 计算新注册的 BeanDefinition 数量
+	return getRegistry().getBeanDefinitionCount() - countBefore;
+}
+```
+
+- 首先，创建 BeanDefinition 的解析器 BeanDefinitionDocumentReader 。
+
+- 然后，调用该 BeanDefinitionDocumentReader 的 `#registerBeanDefinitions(Document doc, XmlReaderContext readerContext)` 方法，开启解析过程，这里使用的是委派模式，具体的实现由子类 DefaultBeanDefinitionDocumentReader 完成。代码如下：
+
+  ```
+  // DefaultBeanDefinitionDocumentReader.java
+  
+  @Override
+  public void registerBeanDefinitions(Document doc, XmlReaderContext readerContext) {
+      this.readerContext = readerContext;
+      // 获得 XML Document Root Element
+      // 执行注册 BeanDefinition
+      doRegisterBeanDefinitions(doc.getDocumentElement());
+  }
+  ```
+
+### 2.2.1 对 Document 对象的解析
+
+从 Document 对象中获取根元素 root，然后调用 ``#doRegisterBeanDefinitions(Element root)` 方法，开启真正的解析过程。代码如下：
+
+```
+// DefaultBeanDefinitionDocumentReader.java
+
+protected void doRegisterBeanDefinitions(Element root) {
+    // ... 省略部分代码（非核心）
+    this.delegate = createDelegate(getReaderContext(), root, parent);
+
+    // 解析前处理
+    preProcessXml(root);
+    // 解析
+    parseBeanDefinitions(root, this.delegate);
+    // 解析后处理
+    postProcessXml(root);
+
+}
+```
+
+- `#preProcessXml(Element root)`、`#postProcessXml(Element root)` 为前置、后置增强处理，目前 Spring 中都是空实现。
+
+- `#parseBeanDefinitions(Element root, BeanDefinitionParserDelegate delegate)` 是对根元素 root 的解析注册过程。代码如下：
+
+  ```
+  // DefaultBeanDefinitionDocumentReader.java
+  
+  protected void parseBeanDefinitions(Element root, BeanDefinitionParserDelegate delegate) {
+      // 如果根节点使用默认命名空间，执行默认解析
+      if (delegate.isDefaultNamespace(root)) {
+          // 遍历子节点
+          NodeList nl = root.getChildNodes();
+          for (int i = 0; i < nl.getLength(); i++) {
+              Node node = nl.item(i);
+              if (node instanceof Element) {
+                  Element ele = (Element) node;
+                  // 如果该节点使用默认命名空间，执行默认解析
+                  if (delegate.isDefaultNamespace(ele)) {
+                      parseDefaultElement(ele, delegate);
+                  // 如果该节点非默认命名空间，执行自定义解析
+                  } else {
+                      delegate.parseCustomElement(ele);
+                  }
+              }
+          }
+      // 如果根节点非默认命名空间，执行自定义解析
+      } else {
+          delegate.parseCustomElement(root);
+      }
+  }
+  ```
+
+  - 迭代 root 元素的所有子节点，对其进行判断：
+    - 若节点为默认命名空间，则调用 `#parseDefaultElement(Element ele, BeanDefinitionParserDelegate delegate)` 方法，开启默认标签的解析注册过程。详细解析，见 [「2.2.1.1 默认标签解析」](https://svip.iocoder.cn/Spring/IoC-load-BeanDefinitions-summary/#) 。
+    - 否则，调用 `BeanDefinitionParserDelegate#parseCustomElement(Element ele)` 方法，开启自定义标签的解析注册过程。详细解析，见 [「2.2.1.2 自定义标签解析」](https://svip.iocoder.cn/Spring/IoC-load-BeanDefinitions-summary/#) 。
+
+#### 2.2.1.1 默认标签解析
+
+若定义的元素节点使用的是 Spring 默认命名空间，则调用 `#parseDefaultElement(Element ele, BeanDefinitionParserDelegate delegate)` 方法，进行默认标签解析。代码如下：
+
+```
+// DefaultBeanDefinitionDocumentReader.java
+
+private void parseDefaultElement(Element ele, BeanDefinitionParserDelegate delegate) {
+	if (delegate.nodeNameEquals(ele, IMPORT_ELEMENT)) { // import
+		importBeanDefinitionResource(ele);
+	} else if (delegate.nodeNameEquals(ele, ALIAS_ELEMENT)) { // alias
+		processAliasRegistration(ele);
+	} else if (delegate.nodeNameEquals(ele, BEAN_ELEMENT)) { // bean
+		processBeanDefinition(ele, delegate);
+	} else if (delegate.nodeNameEquals(ele, NESTED_BEANS_ELEMENT)) { // beans
+		// recurse
+		doRegisterBeanDefinitions(ele);
+	}
+}
+```
+
+对四大标签：`<import>`、`<alias>`、`<bean>`、`<beans>` 进行解析。**其中 `<bean>` 标签的解析为核心工作**。关于各个标签的解析过程，见如下文章：
+
+- [《【死磕 Spring】—— IoC 之解析 标签》](http://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-for-import)
+- [《【死磕 Spring】—— IoC 之解析 标签：开启解析进程》](http://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-in-processBeanDefinition)
+- [《【死磕 Spring】—— IoC 之解析 标签：BeanDefinition》](http://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-for-BeanDefinition)
+- [《【死磕 Spring】—— IoC 之解析 标签：meta、lookup-method、replace-method》](http://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-for-meta-and-look-method-and-replace-method)
+- [《【死磕 Spring】—— IoC 之解析 标签：constructor-arg、property、qualifier》](http://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-for-constructor-arg-and-property-and-qualifier)
+- [《【死磕 Spring】—— IoC 之解析 标签：解析自定义标签》](http://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-for-decorateBeanDefinitionIfRequired)
+
+#### 2.2.1.2 自定义标签解析
+
+对于默认标签则由 `parseCustomElement(Element ele)` 方法，负责解析。代码如下：
+
+```
+// BeanDefinitionParserDelegate.java
+
+@Nullable
+public BeanDefinition parseCustomElement(Element ele) {
+    return parseCustomElement(ele, null);
+}
+
+@Nullable
+public BeanDefinition parseCustomElement(Element ele, @Nullable BeanDefinition containingBd) {
+    // 获取 namespaceUri
+    String namespaceUri = getNamespaceURI(ele);
+    if (namespaceUri == null) {
+        return null;
+    }
+    // 根据 namespaceUri 获取相应的 Handler
+    NamespaceHandler handler = this.readerContext.getNamespaceHandlerResolver().resolve(namespaceUri);
+    if (handler == null) {
+        error("Unable to locate Spring NamespaceHandler for XML schema namespace [" + namespaceUri + "]", ele);
+        return null;
+    }
+    // 调用自定义的 Handler 处理
+    return handler.parse(ele, new ParserContext(this.readerContext, this, containingBd));
+}
+```
+
+获取节点的 `namespaceUri`，然后根据该 `namespaceUri` 获取相对应的 NamespaceHandler，最后调用 NamespaceHandler 的 `#parse(Element element, ParserContext parserContext)` 方法，即完成自定义标签的解析和注入。
+
+想了解更多，可参考：[《【死磕 Spring】—— IoC 之解析自定义标签》](http://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-in-parseCustomElement) 。
+
+### 2.2.2 注册 BeanDefinition
+
+经过上面的解析，则将 Document 对象里面的 Bean 标签解析成了一个个的 BeanDefinition ，下一步则是将这些 BeanDefinition 注册到 IoC 容器中。动作的触发是在解析 Bean 标签完成后，代码如下：
+
+```
+// DefaultBeanDefinitionDocumentReader.java
+
+protected void processBeanDefinition(Element ele, BeanDefinitionParserDelegate delegate) {
+    // 进行 bean 元素解析。
+    // 如果解析成功，则返回 BeanDefinitionHolder 对象。而 BeanDefinitionHolder 为 name 和 alias 的 BeanDefinition 对象
+    // 如果解析失败，则返回 null 。
+    BeanDefinitionHolder bdHolder = delegate.parseBeanDefinitionElement(ele);
+    if (bdHolder != null) {
+        // 进行自定义标签处理
+        bdHolder = delegate.decorateBeanDefinitionIfRequired(ele, bdHolder);
+        try {
+            // 进行 BeanDefinition 的注册
+            // Register the final decorated instance.
+            BeanDefinitionReaderUtils.registerBeanDefinition(bdHolder, getReaderContext().getRegistry());
+        } catch (BeanDefinitionStoreException ex) {
+            getReaderContext().error("Failed to register bean definition with name '" +
+                    bdHolder.getBeanName() + "'", ele, ex);
+        }
+        // 发出响应事件，通知相关的监听器，已完成该 Bean 标签的解析。
+        // Send registration event.
+        getReaderContext().fireComponentRegistered(new BeanComponentDefinition(bdHolder));
+    }
+}
+```
+
+- 调用 `BeanDefinitionReaderUtils.registerBeanDefinition()` 方法，来注册。其实，这里面也是调用 BeanDefinitionRegistry 的 `#registerBeanDefinition(String beanName, BeanDefinition beanDefinition)` 方法，来注册 BeanDefinition 。不过，最终的实现是在 DefaultListableBeanFactory 中实现，代码如下：
+
+  ```
+  // DefaultListableBeanFactory.java
+  @Override
+  public void registerBeanDefinition(String beanName, BeanDefinition beanDefinition)
+          throws BeanDefinitionStoreException {
+      // ...省略校验相关的代码
+      // 从缓存中获取指定 beanName 的 BeanDefinition
+      BeanDefinition existingDefinition = this.beanDefinitionMap.get(beanName);
+      // 如果已经存在
+      if (existingDefinition != null) {
+          // 如果存在但是不允许覆盖，抛出异常
+          if (!isAllowBeanDefinitionOverriding()) {
+               throw new BeanDefinitionOverrideException(beanName, beanDefinition, existingDefinition);
+          } else {
+             // ...省略 logger 打印日志相关的代码
+          }
+          // 【重点】允许覆盖，直接覆盖原有的 BeanDefinition 到 beanDefinitionMap 中。
+          this.beanDefinitionMap.put(beanName, beanDefinition);
+      // 如果未存在
+      } else {
+          // ... 省略非核心的代码
+          // 【重点】添加到 BeanDefinition 到 beanDefinitionMap 中。
+          this.beanDefinitionMap.put(beanName, beanDefinition);
+      }
+      // 重新设置 beanName 对应的缓存
+      if (existingDefinition != null || containsSingleton(beanName)) {
+          resetBeanDefinition(beanName);
+      }
+  }
+  ```
+
+  - 这段代码最核心的部分是这句 `this.beanDefinitionMap.put(beanName, beanDefinition)` 代码段。所以，注册过程也不是那么的高大上，就是利用一个 Map 的集合对象来存放：`key` 是 `beanName` ，`value` 是 BeanDefinition 对象。
+
+想了解更多，可参考：[《【死磕 Spring】—— IoC 之注册解析的 BeanDefinitions》](http://svip.iocoder.cn/Spring/IoC-register-BeanDefinitions-really) 。
+
+# 3. 小结
+
+至此，整个 IoC 的初始化过程就已经完成了，从 Bean 资源的定位，转换为 Document 对象，接着对其进行解析，最后注册到 IoC 容器中，都已经完美地完成了。现在 IoC 容器中已经建立了整个 Bean 的配置信息，这些 Bean 可以被检索、使用、维护，他们是控制反转的基础，是后面注入 Bean 的依赖。最后用一张流程图来结束这篇总结之文。
+
+[![整体流程](19-Spring-IoC 之装载 BeanDefinitions 总结.assets/38419d23d29c83a4758f73f85281e076.png)](http://static.iocoder.cn/38419d23d29c83a4758f73f85281e076)整体流程
+
+另外，艿艿推荐几篇不错的 Srping IoC 容器相关的博客：
+
+- JavaDoop [《Spring IOC 容器源码分析》](https://javadoop.com/post/spring-ioc)
+- Yikun [《Spring IOC 核心源码学习》](https://yikun.github.io/2015/05/29/Spring-IOC核心源码学习/)
+- DearBelinda [《Spring专题之 IOC 源码分析》](https://segmentfault.com/a/1190000016261917)
\ No newline at end of file
diff --git a/spring/20-Spring-IoC 之开启 Bean 的加载.assets/181705b2eb48364c7626b59397e2af1c.jpeg b/spring/20-Spring-IoC 之开启 Bean 的加载.assets/181705b2eb48364c7626b59397e2af1c.jpeg
new file mode 100644
index 0000000..0a52f6c
Binary files /dev/null and b/spring/20-Spring-IoC 之开启 Bean 的加载.assets/181705b2eb48364c7626b59397e2af1c.jpeg differ
diff --git a/spring/20-Spring-IoC 之开启 Bean 的加载.md b/spring/20-Spring-IoC 之开启 Bean 的加载.md
new file mode 100644
index 0000000..38d5e64
--- /dev/null
+++ b/spring/20-Spring-IoC 之开启 Bean 的加载.md	
@@ -0,0 +1,606 @@
+# 【死磕 Spring】—— IoC 之开启 Bean 的加载
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=2806 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+[![Spring IoC 作用](20-Spring-IoC 之开启 Bean 的加载.assets/181705b2eb48364c7626b59397e2af1c.jpeg)](http://static.iocoder.cn/181705b2eb48364c7626b59397e2af1c)Spring IoC 作用
+
+(此图参考《Spring 揭秘》)
+
+Spring IoC 容器所起的作用如上图所示，它会以某种方式加载 Configuration Metadata，将其解析注册到容器内部，然后回根据这些信息绑定整个系统的对象，最终组装成一个可用的基于轻量级容器的应用系统。
+
+Spring 在实现上述功能中，将整个流程分为两个阶段：容器初始化阶段和加载bean 阶段。分别如下：
+
+1. 容器初始化阶段
+
+   ：
+
+   - 首先，通过某种方式加载 Configuration Metadata (主要是依据 Resource、ResourceLoader 两个体系) 。
+   - 然后，容器会对加载的 Configuration MetaData 进行解析和分析，并将分析的信息组装成 BeanDefinition 。
+   - 最后，将 BeanDefinition 保存注册到相应的 BeanDefinitionRegistry 中。
+   - 至此，Spring IoC 的初始化工作完成。
+
+2. 加载 Bean 阶段
+
+   ：
+
+   - 经过容器初始化阶段后，应用程序中定义的 bean 信息已经全部加载到系统中了，当我们显示或者隐式地调用 `BeanFactory#getBean(...)` 方法时，则会触发加载 Bean 阶段。
+   - 在这阶段，容器会首先检查所请求的对象是否已经初始化完成了，如果没有，则会根据注册的 Bean 信息实例化请求的对象，并为其注册依赖，然后将其返回给请求方。
+   - 至此第二个阶段也已经完成。
+
+第一个阶段前面已经用了 10 多篇博客深入分析了（总结参考 [《【死磕 Spring】—— IoC 之装载 BeanDefinitions 总结》](http://svip.iocoder.cn/Spring/IoC-load-BeanDefinitions-summary)）。所以从这篇开始分析第二个阶段：加载 Bean 阶段。
+
+# 1. getBean
+
+当我们显示或者隐式地调用 `BeanFactory#getBean(String name)` 方法时，则会触发加载 Bean 阶段。代码如下：
+
+```
+// AbstractBeanFactory.java
+
+@Override
+public Object getBean(String name) throws BeansException {
+	return doGetBean(name, null, null, false);
+}
+```
+
+- 内部调用 `doGetBean(String name, final Class<T> requiredType, Object[] args, boolean typeCheckOnly)` 方法，其接受四个方法参数：
+  - `name` ：要获取 Bean 的名字
+  - `requiredType` ：要获取 bean 的类型
+  - `args` ：创建 Bean 时传递的参数。这个参数仅限于创建 Bean 时使用。
+  - `typeCheckOnly` ：是否为类型检查。
+
+# 2. doGetBean
+
+`#doGetBean(String name, final Class<T> requiredType, Object[] args, boolean typeCheckOnly)` 方法，代码比较长，各位耐心看下。代码如下：
+
+```
+// AbstractBeanFactory.java
+
+protected <T> T doGetBean(final String name, @Nullable final Class<T> requiredType,
+        @Nullable final Object[] args, boolean typeCheckOnly) throws BeansException {
+    // <1> 返回 bean 名称，剥离工厂引用前缀。
+    // 如果 name 是 alias ，则获取对应映射的 beanName 。
+    final String beanName = transformedBeanName(name);
+    Object bean;
+
+    // 从缓存中或者实例工厂中获取 Bean 对象
+    // Eagerly check singleton cache for manually registered singletons.
+    Object sharedInstance = getSingleton(beanName);
+    if (sharedInstance != null && args == null) {
+        if (logger.isTraceEnabled()) {
+            if (isSingletonCurrentlyInCreation(beanName)) {
+                logger.trace("Returning eagerly cached instance of singleton bean '" + beanName +
+                        "' that is not fully initialized yet - a consequence of a circular reference");
+            } else {
+                logger.trace("Returning cached instance of singleton bean '" + beanName + "'");
+            }
+        }
+        // <2> 完成 FactoryBean 的相关处理，并用来获取 FactoryBean 的处理结果
+        bean = getObjectForBeanInstance(sharedInstance, name, beanName, null);
+    } else {
+        // Fail if we're already creating this bean instance:
+        // We're assumably within a circular reference.
+        // <3> 因为 Spring 只解决单例模式下得循环依赖，在原型模式下如果存在循环依赖则会抛出异常。
+        if (isPrototypeCurrentlyInCreation(beanName)) {
+            throw new BeanCurrentlyInCreationException(beanName);
+        }
+
+        // <4> 如果容器中没有找到，则从父类容器中加载
+        // Check if bean definition exists in this factory.
+        BeanFactory parentBeanFactory = getParentBeanFactory();
+        if (parentBeanFactory != null && !containsBeanDefinition(beanName)) {
+            // Not found -> check parent.
+            String nameToLookup = originalBeanName(name);
+            if (parentBeanFactory instanceof AbstractBeanFactory) {
+                return ((AbstractBeanFactory) parentBeanFactory).doGetBean(
+                        nameToLookup, requiredType, args, typeCheckOnly);
+            } else if (args != null) {
+                // Delegation to parent with explicit args.
+                return (T) parentBeanFactory.getBean(nameToLookup, args);
+            } else if (requiredType != null) {
+                // No args -> delegate to standard getBean method.
+                return parentBeanFactory.getBean(nameToLookup, requiredType);
+            } else {
+                return (T) parentBeanFactory.getBean(nameToLookup);
+            }
+        }
+
+        // <5> 如果不是仅仅做类型检查则是创建bean，这里需要记录
+        if (!typeCheckOnly) {
+            markBeanAsCreated(beanName);
+        }
+
+        try {
+            // <6> 从容器中获取 beanName 相应的 GenericBeanDefinition 对象，并将其转换为 RootBeanDefinition 对象
+            final RootBeanDefinition mbd = getMergedLocalBeanDefinition(beanName);
+            // 检查给定的合并的 BeanDefinition
+            checkMergedBeanDefinition(mbd, beanName, args);
+
+            // Guarantee initialization of beans that the current bean depends on.
+            // <7> 处理所依赖的 bean
+            String[] dependsOn = mbd.getDependsOn();
+            if (dependsOn != null) {
+                for (String dep : dependsOn) {
+                    // 若给定的依赖 bean 已经注册为依赖给定的 bean
+                    // 循环依赖的情况
+                    if (isDependent(beanName, dep)) {
+                        throw new BeanCreationException(mbd.getResourceDescription(), beanName,
+                                "Circular depends-on relationship between '" + beanName + "' and '" + dep + "'");
+                    }
+                    // 缓存依赖调用 TODO 芋艿
+                    registerDependentBean(dep, beanName);
+                    try {
+                        getBean(dep);
+                    } catch (NoSuchBeanDefinitionException ex) {
+                        throw new BeanCreationException(mbd.getResourceDescription(), beanName,
+                                "'" + beanName + "' depends on missing bean '" + dep + "'", ex);
+                    }
+                }
+            }
+
+            // <8> bean 实例化
+            // Create bean instance.
+            if (mbd.isSingleton()) { // 单例模式
+                sharedInstance = getSingleton(beanName, () -> {
+                    try {
+                        return createBean(beanName, mbd, args);
+                    }
+                    catch (BeansException ex) {
+                        // Explicitly remove instance from singleton cache: It might have been put there
+                        // eagerly by the creation process, to allow for circular reference resolution.
+                        // Also remove any beans that received a temporary reference to the bean.
+                        // 显式从单例缓存中删除 Bean 实例
+                        // 因为单例模式下为了解决循环依赖，可能他已经存在了，所以销毁它。 TODO 芋艿
+                        destroySingleton(beanName);
+                        throw ex;
+                    }
+                });
+                bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
+            } else if (mbd.isPrototype()) { // 原型模式
+                // It's a prototype -> create a new instance.
+                Object prototypeInstance;
+                try {
+                    beforePrototypeCreation(beanName);
+                    prototypeInstance = createBean(beanName, mbd, args);
+                } finally {
+                    afterPrototypeCreation(beanName);
+                }
+                bean = getObjectForBeanInstance(prototypeInstance, name, beanName, mbd);
+            } else {
+                // 从指定的 scope 下创建 bean
+                String scopeName = mbd.getScope();
+                final Scope scope = this.scopes.get(scopeName);
+                if (scope == null) {
+                    throw new IllegalStateException("No Scope registered for scope name '" + scopeName + "'");
+                }try {
+                    Object scopedInstance = scope.get(beanName, () -> {
+                        beforePrototypeCreation(beanName);
+                        try {
+                            return createBean(beanName, mbd, args);
+                        } finally {
+                            afterPrototypeCreation(beanName);
+                        }
+                    });
+                    bean = getObjectForBeanInstance(scopedInstance, name, beanName, mbd);
+                } catch (IllegalStateException ex) {
+                    throw new BeanCreationException(beanName,
+                            "Scope '" + scopeName + "' is not active for the current thread; consider " +
+                            "defining a scoped proxy for this bean if you intend to refer to it from a singleton",
+                            ex);
+                }
+            }
+        } catch (BeansException ex) {
+            cleanupAfterBeanCreationFailure(beanName);
+            throw ex;
+        }
+    }
+
+    // <9> 检查需要的类型是否符合 bean 的实际类型
+    // Check if required type matches the type of the actual bean instance.
+    if (requiredType != null && !requiredType.isInstance(bean)) {
+        try {
+            T convertedBean = getTypeConverter().convertIfNecessary(bean, requiredType);
+            if (convertedBean == null) {
+                throw new BeanNotOfRequiredTypeException(name, requiredType, bean.getClass());
+            }
+            return convertedBean;
+        } catch (TypeMismatchException ex) {
+            if (logger.isTraceEnabled()) {
+                logger.trace("Failed to convert bean '" + name + "' to required type '" +
+                        ClassUtils.getQualifiedName(requiredType) + "'", ex);
+            }
+            throw new BeanNotOfRequiredTypeException(name, requiredType, bean.getClass());
+        }
+    }
+    return (T) bean;
+}
+```
+
+代码是相当长，处理逻辑也是相当复杂，下面将其进行拆分阐述。
+
+- `<1>` 处，详细解析，见 [「2.1 获取 beanName」](https://svip.iocoder.cn/Spring/IoC-get-Bean-begin/#) 。
+- `<2>` 处，详细解析，见 [「2.2 从单例 Bean 缓存中获取 Bean」](https://svip.iocoder.cn/Spring/IoC-get-Bean-begin/#) 。
+- `<3>` 处，详细解析，见 [「2.3 原型模式依赖检查」](https://svip.iocoder.cn/Spring/IoC-get-Bean-begin/#) 。
+- `<4>` 处，详细解析，见 [「2.4 从 parentBeanFactory 获取 Bean」](https://svip.iocoder.cn/Spring/IoC-get-Bean-begin/#) 。
+- `<5>` 处，详细解析，见 [「2.5 指定的 Bean 标记为已经创建或即将创建」](https://svip.iocoder.cn/Spring/IoC-get-Bean-begin/#) 。
+- `<6>` 处，详细解析，见 [「2.6 获取 BeanDefinition」](https://svip.iocoder.cn/Spring/IoC-get-Bean-begin/#) 。
+- `<7>` 处，详细解析，见 [「2.7 依赖 Bean 处理」](https://svip.iocoder.cn/Spring/IoC-get-Bean-begin/#) 。
+- `<8>` 处，详细解析，见 [「2.8 不同作用域的 Bean 实例化」](https://svip.iocoder.cn/Spring/IoC-get-Bean-begin/#) 。
+- `<9>` 处，详细解析，见 [「2.9 类型转换」](https://svip.iocoder.cn/Spring/IoC-get-Bean-begin/#) 。
+
+## 2.1 获取 beanName
+
+对应代码段如下：
+
+```
+// AbstractBeanFactory.java
+
+final String beanName = transformedBeanName(name);
+```
+
+- 这里传递的是 `name` 方法，不一定就是 beanName，可能是 aliasName ，也有可能是 FactoryBean ，所以这里需要调用 `#transformedBeanName(String name)` 方法，对 `name` 进行一番转换。代码如下：
+
+  ```
+  // AbstractBeanFactory.java
+  
+  protected String transformedBeanName(String name) {
+  	return canonicalName(BeanFactoryUtils.transformedBeanName(name));
+  }
+  ```
+
+  - 调用 `BeanFactoryUtils#transformedBeanName(String name)` 方法，去除 FactoryBean 的修饰符。代码如下：
+
+    ```
+    // BeanFactoryUtils.java
+    
+    /**
+     * Cache from name with factory bean prefix to stripped name without dereference.
+     *
+     * 缓存 {@link #transformedBeanName(String)} 已经转换好的结果。
+     *
+     * @since 5.1
+     * @see BeanFactory#FACTORY_BEAN_PREFIX
+     */
+    private static final Map<String, String> transformedBeanNameCache = new ConcurrentHashMap<>();
+    /**
+     * 去除 FactoryBean 的修饰符 &
+     *
+     * 如果 name 以 “&” 为前缀，那么会去掉该 "&" 。
+     * 例如，name = "&studentService" ，则会是 name = "studentService"。
+     *
+     * Return the actual bean name, stripping out the factory dereference
+     * prefix (if any, also stripping repeated factory prefixes if found).
+     * @param name the name of the bean
+     * @return the transformed name
+     * @see BeanFactory#FACTORY_BEAN_PREFIX
+     */
+    public static String transformedBeanName(String name) {
+        Assert.notNull(name, "'name' must not be null");
+        if (!name.startsWith(BeanFactory.FACTORY_BEAN_PREFIX)) { // BeanFactory.FACTORY_BEAN_PREFIX = $
+            return name;
+        }
+        // computeIfAbsent 方法，分成两种情况：
+        //      1. 未存在，则进行计算执行，并将结果添加到缓存、
+        //      2. 已存在，则直接返回，无需计算。
+        return transformedBeanNameCache.computeIfAbsent(name, beanName -> {
+            do {
+                beanName = beanName.substring(BeanFactory.FACTORY_BEAN_PREFIX.length());
+            } while (beanName.startsWith(BeanFactory.FACTORY_BEAN_PREFIX));
+            return beanName;
+        });
+    }
+    ```
+
+    - 实际上，逻辑比较简单，就是去除传入 `name` 参数的 `"&"` 的前缀。
+
+      > 小知识补充。假设配置了一个 FactoryBean 的名字为 `"abc"` ，那么获取 FactoryBean 创建的 Bean 时，使用 `"abc"` ，如果获取 FactoryBean 本身，使用 `"$abc"` 。另外，`&`定义在 `BeanFactory.FACTORY_BEAN_PREFIX = "&"` 上。
+
+    - `transformedBeanNameCache` 集合的存在，是为了缓存转换后的结果。下次再获取相同的 `name` 时，直接返回缓存中的结果即可。
+
+  - 调用 `#canonicalName(String name)` 方法，取指定的 `alias` 所表示的最终 beanName 。
+
+    ```
+    // SimpleAliasRegistry.java
+    
+    /** Map from alias to canonical name. */
+    // key: alias
+    // value: beanName
+    private final Map<String, String> aliasMap = new ConcurrentHashMap<>(16);
+    
+    public String canonicalName(String name) {
+    	String canonicalName = name;
+    	// Handle aliasing...
+    	String resolvedName;
+    	// 循环，从 aliasMap 中，获取到最终的 beanName
+    	do {
+    		resolvedName = this.aliasMap.get(canonicalName);
+    		if (resolvedName != null) {
+    			canonicalName = resolvedName;
+    		}
+    	} while (resolvedName != null);
+    	return canonicalName;
+    }
+    ```
+
+    - 主要是一个循环获取 beanName 的过程，例如，别名 A 指向名称为 B 的 bean 则返回 B，若 别名 A 指向别名 B，别名 B 指向名称为 C 的 bean，则返回 C。
+
+## 2.2 从单例 Bean 缓存中获取 Bean
+
+对应代码段如下：
+
+```
+// AbstractBeanFactory.java
+
+// 从缓存中或者实例工厂中获取 Bean 对象
+// Eagerly check singleton cache for manually registered singletons.
+Object sharedInstance = getSingleton(beanName);
+if (sharedInstance != null && args == null) {
+	if (logger.isTraceEnabled()) {
+		if (isSingletonCurrentlyInCreation(beanName)) {
+			logger.trace("Returning eagerly cached instance of singleton bean '" + beanName +
+					"' that is not fully initialized yet - a consequence of a circular reference");
+		} else {
+			logger.trace("Returning cached instance of singleton bean '" + beanName + "'");
+		}
+	}
+	// <x> 完成 FactoryBean 的相关处理，并用来获取 FactoryBean 的处理结果
+	bean = getObjectForBeanInstance(sharedInstance, name, beanName, null);
+}
+```
+
+- 我们知道单例模式的 Bean 在整个过程中只会被创建一次。第一次创建后会将该 Bean 加载到缓存中。后面，在获取 Bean 就会直接从单例缓存中获取。
+
+- `<x>` 处，如果从缓存中得到了 Bean 对象，则需要调用 `#getObjectForBeanInstance(Object beanInstance, String name, String beanName, RootBeanDefinition mbd)` 方法，对 Bean 进行实例化处理。因为，缓存中记录的是最原始的 Bean 状态，我们得到的不一定是我们**最终**想要的 Bean 。另外，FactoryBean 的用途如下：
+
+  > From 《Spring 源码深度解析》P83 页
+  >
+  > 一般情况下，Spring 通过反射机制利用 bean 的 class 属性指定实现类来实例化 bean 。某些情况下，实例化 bean 过程比较复杂，如果按照传统的方式，则需要在 中提供大量的配置信息，配置方式的灵活性是受限的，这时采用编码的方式可能会得到一个简单的方案。Spring 为此提供了一个 FactoryBean 的工厂类接口，用户可以通过实现该接口定制实例化 bean 的逻辑。
+  >
+  > FactoryBean 接口对于 Spring 框架来说战友重要的地址，Spring 自身就提供了 70 多个 FactoryBean 的实现。它们隐藏了实例化一些复杂 bean 的细节，给上层应用带来了便利。
+
+详细解析，见 [《【死磕 Spring】—— IoC 之加载 Bean：从单例缓存中获取单》](http://svip.iocoder.cn/Spring/IoC-get-Bean-getSingleton) 。
+
+## 2.3 原型模式依赖检查
+
+对应代码段如下：
+
+```
+// AbstractBeanFactory.java
+
+// Fail if we're already creating this bean instance:
+// We're assumably within a circular reference.
+// 因为 Spring 只解决单例模式下得循环依赖，在原型模式下如果存在循环依赖则会抛出异常。
+if (isPrototypeCurrentlyInCreation(beanName)) {
+	throw new BeanCurrentlyInCreationException(beanName);
+}
+```
+
+Spring 只处理单例模式下得循环依赖，对于原型模式的循环依赖直接抛出异常。主要原因还是在于，**和 Spring 解决循环依赖的策略有关**。
+
+- 对于**单例( Singleton )模式**， Spring 在创建 Bean 的时候并不是等 Bean 完全创建完成后才会将 Bean 添加至缓存中，而是不等 Bean 创建完成就会将创建 Bean 的 ObjectFactory 提早加入到缓存中，这样一旦下一个 Bean 创建的时候需要依赖 bean 时则直接使用 ObjectFactroy 。
+- 但是**原型( Prototype )模式**，我们知道是没法使用缓存的，所以 Spring 对原型模式的循环依赖处理策略则是不处理。
+
+详细解析，见 [《【死磕 Spring】—— IoC 之加载 Bean：parentBeanFactory 与依赖处理》](http://svip.iocoder.cn/Spring/IoC-get-Bean-parentBeanFactory-and-depend-on) 。
+
+## 2.4 从 parentBeanFactory 获取 Bean
+
+对应代码段如下：
+
+```
+// AbstractBeanFactory.java
+
+// 如果当前容器中没有找到，则从父类容器中加载
+// Check if bean definition exists in this factory.
+BeanFactory parentBeanFactory = getParentBeanFactory();
+if (parentBeanFactory != null && !containsBeanDefinition(beanName)) {
+    // Not found -> check parent.
+    String nameToLookup = originalBeanName(name);
+    // 如果，父类容器为 AbstractBeanFactory ，直接递归查找
+    if (parentBeanFactory instanceof AbstractBeanFactory) {
+        return ((AbstractBeanFactory) parentBeanFactory).doGetBean(
+                nameToLookup, requiredType, args, typeCheckOnly);
+    // 用明确的 args 从 parentBeanFactory 中，获取 Bean 对象
+    } else if (args != null) {
+        // Delegation to parent with explicit args.
+        return (T) parentBeanFactory.getBean(nameToLookup, args);
+    // 用明确的 requiredType 从 parentBeanFactory 中，获取 Bean 对象
+    } else if (requiredType != null) {
+        // No args -> delegate to standard getBean method.
+        return parentBeanFactory.getBean(nameToLookup, requiredType);
+    // 直接使用 nameToLookup 从 parentBeanFactory 获取 Bean 对象
+    } else {
+        return (T) parentBeanFactory.getBean(nameToLookup);
+    }
+}
+```
+
+- 如果**当前**容器缓存中没有相对应的 BeanDefinition 对象，则会尝试从父类工厂（`parentBeanFactory`）中加载，然后再去递归调用 `#getBean(...)` 方法。
+
+详细解析，见 [《【死磕 Spring】—— IoC 之加载 Bean：parentBeanFactory 与依赖处理》](http://svip.iocoder.cn/Spring/IoC-get-Bean-parentBeanFactory-and-depend-on) 。
+
+## 2.5 指定的 Bean 标记为已经创建或即将创建
+
+对应代码段如下：
+
+```
+// AbstractBeanFactory.java
+
+// 如果不是仅仅做类型检查则是创建bean，这里需要记录
+if (!typeCheckOnly) {
+	markBeanAsCreated(beanName);
+}
+```
+
+详细解析，见 [《【死磕 Spring】—— IoC 之加载 Bean：parentBeanFactory 与依赖处理》](http://svip.iocoder.cn/Spring/IoC-get-Bean-parentBeanFactory-and-depend-on) 。
+
+## 2.6 获取 BeanDefinition
+
+对应代码段如下：
+
+```
+// AbstractBeanFactory.java
+
+// 从容器中获取 beanName 相应的 GenericBeanDefinition 对象，并将其转换为 RootBeanDefinition 对象
+final RootBeanDefinition mbd = getMergedLocalBeanDefinition(beanName);
+// 检查给定的合并的 BeanDefinition
+checkMergedBeanDefinition(mbd, beanName, args);
+```
+
+> 因为从 XML 配置文件中读取到的 Bean 信息是存储在GenericBeanDefinition 中的。但是，所有的 Bean 后续处理都是针对于 RootBeanDefinition 的，所以这里需要进行一个转换。
+>
+> 转换的同时，如果父类 bean 不为空的话，则会一并合并父类的属性。
+
+详细解析，见 [《【死磕 Spring】—— IoC 之加载 Bean：parentBeanFactory 与依赖处理》](http://svip.iocoder.cn/Spring/IoC-get-Bean-parentBeanFactory-and-depend-on) 。
+
+## 2.7 依赖 Bean 处理
+
+对应代码段如下：
+
+```
+// AbstractBeanFactory.java
+
+// Guarantee initialization of beans that the current bean depends on.
+// 处理所依赖的 bean
+String[] dependsOn = mbd.getDependsOn();
+if (dependsOn != null) {
+    for (String dep : dependsOn) {
+        // 若给定的依赖 bean 已经注册为依赖给定的 bean
+        // 即循环依赖的情况，抛出 BeanCreationException 异常
+        if (isDependent(beanName, dep)) {
+            throw new BeanCreationException(mbd.getResourceDescription(), beanName,
+                    "Circular depends-on relationship between '" + beanName + "' and '" + dep + "'");
+        }
+        // 缓存依赖调用 TODO 芋艿
+        registerDependentBean(dep, beanName);
+        try {
+            // 递归处理依赖 Bean
+            getBean(dep);
+        } catch (NoSuchBeanDefinitionException ex) {
+            throw new BeanCreationException(mbd.getResourceDescription(), beanName,
+                    "'" + beanName + "' depends on missing bean '" + dep + "'", ex);
+        }
+    }
+}
+```
+
+- 每个 Bean 都不是单独工作的，它会依赖其他 Bean，其他 Bean 也会依赖它。
+- 对于依赖的 Bean ，它会优先加载，所以，在 Spring 的加载顺序中，在初始化某一个 Bean 的时候，首先会初始化这个 Bean 的依赖。
+
+详细解析，见 [《【死磕 Spring】—— IoC 之加载 Bean：parentBeanFactory 与依赖处理》](http://svip.iocoder.cn/Spring/IoC-get-Bean-parentBeanFactory-and-depend-on) 。
+
+## 2.8 不同作用域的 Bean 实例化
+
+对应代码段如下：
+
+```
+// AbstractBeanFactory.java
+
+// bean 实例化
+// Create bean instance.
+if (mbd.isSingleton()) { // 单例模式
+    sharedInstance = getSingleton(beanName, () -> {
+        try {
+            return createBean(beanName, mbd, args);
+        }
+        catch (BeansException ex) {
+            // Explicitly remove instance from singleton cache: It might have been put there
+            // eagerly by the creation process, to allow for circular reference resolution.
+            // Also remove any beans that received a temporary reference to the bean.
+            // 显式从单例缓存中删除 Bean 实例
+            // 因为单例模式下为了解决循环依赖，可能他已经存在了，所以销毁它。 TODO 芋艿
+            destroySingleton(beanName);
+            throw ex;
+        }
+    });
+    bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
+} else if (mbd.isPrototype()) { // 原型模式
+    // It's a prototype -> create a new instance.
+    Object prototypeInstance;
+    try {
+        beforePrototypeCreation(beanName);
+        prototypeInstance = createBean(beanName, mbd, args);
+    } finally {
+        afterPrototypeCreation(beanName);
+    }
+    bean = getObjectForBeanInstance(prototypeInstance, name, beanName, mbd);
+} else {
+    // 从指定的 scope 下创建 bean
+    String scopeName = mbd.getScope();
+    final Scope scope = this.scopes.get(scopeName);
+    if (scope == null) {
+        throw new IllegalStateException("No Scope registered for scope name '" + scopeName + "'");
+    }try {
+        Object scopedInstance = scope.get(beanName, () -> {
+            beforePrototypeCreation(beanName);
+            try {
+                return createBean(beanName, mbd, args);
+            } finally {
+                afterPrototypeCreation(beanName);
+            }
+        });
+        bean = getObjectForBeanInstance(scopedInstance, name, beanName, mbd);
+    } catch (IllegalStateException ex) {
+        throw new BeanCreationException(beanName,
+                "Scope '" + scopeName + "' is not active for the current thread; consider " +
+                "defining a scoped proxy for this bean if you intend to refer to it from a singleton",
+                ex);
+    }
+}
+```
+
+- Spring Bean 的作用域默认为 singleton 。当然，还有其他作用域，如 prototype、request、session 等。
+- 不同的作用域会有不同的初始化策略。
+
+详细解析，见 [《【死磕 Spring】—— IoC 之加载 Bean：分析各 scope 的 Bean 创建》](http://svip.iocoder.cn/Spring/IoC-get-Bean-different-scope) 。
+
+## 2.9 类型转换
+
+对应代码段如下：
+
+```
+// AbstractBeanFactory.java
+
+// 检查需要的类型是否符合 bean 的实际类型
+// Check if required type matches the type of the actual bean instance.
+if (requiredType != null && !requiredType.isInstance(bean)) {
+    try {
+        // 执行转换
+        T convertedBean = getTypeConverter().convertIfNecessary(bean, requiredType);
+        // 转换失败，抛出 BeanNotOfRequiredTypeException 异常
+        if (convertedBean == null) {
+            throw new BeanNotOfRequiredTypeException(name, requiredType, bean.getClass());
+        }
+        return convertedBean;
+    } catch (TypeMismatchException ex) {
+        if (logger.isTraceEnabled()) {
+            logger.trace("Failed to convert bean '" + name + "' to required type '" +
+                    ClassUtils.getQualifiedName(requiredType) + "'", ex);
+        }
+        throw new BeanNotOfRequiredTypeException(name, requiredType, bean.getClass());
+    }
+}
+```
+
+- 在调用 `#doGetBean(...)` 方法时，`有一个 requiredTyp`e 参数。该参数的功能就是将返回的 Bean 转换为 `requiredType` 类型。
+- 当然就一般而言，我们是不需要进行类型转换的，也就是 `requiredType` 为空（比如 `#getBean(String name)` 方法）。但有，可能会存在这种情况，比如我们返回的 Bean 类型为 String ，我们在使用的时候需要将其转换为 Integer，那么这个时候 `requiredType` 就有用武之地了。**当然我们一般是不需要这样做的**。
+
+详细解析，见 TODO
+
+# 3. 小结
+
+至此 `BeanFactory#getBean(...)` 方法的过程讲解完了。后续将会对该过程进行拆分，更加详细的说明，弄清楚其中的来龙去脉，所以这篇博客只能算是 Spring Bean 加载过程的一个概览。拆分主要是分为三个部分：
+
+1. 分析从缓存中获取单例 Bean ，以及对 Bean 的实例中获取对象。
+2. 如果从单例缓存中获取 Bean ，Spring 是怎么加载的呢？所以第二部分是分析 Bean 加载，以及 Bean 的依赖处理。
+3. Bean 已经加载了，依赖也处理完毕了，第三部分则分析各个作用域的 Bean 初始化过程。
+
+> 老艿艿：再推荐几篇不错的 Spring Bean 加载的过程，写的不错的文章：
+>
+> - zhanglbjames [《Spring-IoC-getBean源码解析》](https://www.jianshu.com/p/a6acfceb42fb)
+> - glmapper [《Spring源码系列：依赖注入（一）getBean》](https://juejin.im/post/5a7532746fb9a0633a70d57f)
+> - 是Guava不是瓜娃 [《Spring原理与源码分析系列（五）- Spring IoC源码分析（下）》](https://blog.csdn.net/noaman_wgs/article/details/79138883)
\ No newline at end of file
diff --git a/spring/21-Spring-IoC 之加载 Bean：从单例缓存中获取单例 Bean.md b/spring/21-Spring-IoC 之加载 Bean：从单例缓存中获取单例 Bean.md
new file mode 100644
index 0000000..fd4a153
--- /dev/null
+++ b/spring/21-Spring-IoC 之加载 Bean：从单例缓存中获取单例 Bean.md	
@@ -0,0 +1,485 @@
+# 【死磕 Spring】—— IoC 之加载 Bean：从单例缓存中获取单例 Bean
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=todo 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+从这篇博客开始我们开始加载 Bean 的第一个步骤，从缓存中获取 Bean 。代码片段如下：
+
+```
+// AbstractBeanFactory.java
+
+// 从缓存中或者实例工厂中获取 Bean 对象
+// Eagerly check singleton cache for manually registered singletons.
+Object sharedInstance = getSingleton(beanName);
+if (sharedInstance != null && args == null) {
+	if (logger.isTraceEnabled()) {
+		if (isSingletonCurrentlyInCreation(beanName)) {
+			logger.trace("Returning eagerly cached instance of singleton bean '" + beanName +
+					"' that is not fully initialized yet - a consequence of a circular reference");
+		} else {
+			logger.trace("Returning cached instance of singleton bean '" + beanName + "'");
+		}
+	}
+	// 完成 FactoryBean 的相关处理，并用来获取 FactoryBean 的处理结果
+	bean = getObjectForBeanInstance(sharedInstance, name, beanName, null);
+}
+```
+
+调用 `#getSingleton(String beanName)` 方法，从缓存中获取 Bean 。
+
+# 1. getSingleton
+
+在上篇博客 [《【死磕 Spring】—— IoC 之开启 Bean 的加载》](http://svip.iocoder.cn/Spring/IoC-get-Bean-begin) 中提到过，Spring 对单例模式的 bean 只会创建一次。后续，如果再获取该 Bean ，则是直接从单例缓存中获取，该过程就体现在 `#getSingleton(String beanName)` 方法中。代码如下：
+
+```
+// DefaultSingletonBeanRegistry.java
+
+@Override
+@Nullable
+public Object getSingleton(String beanName) {
+    return getSingleton(beanName, true);
+}
+
+@Nullable
+protected Object getSingleton(String beanName, boolean allowEarlyReference) {
+    // 从单例缓冲中加载 bean
+    Object singletonObject = this.singletonObjects.get(beanName);
+    // 缓存中的 bean 为空，且当前 bean 正在创建
+    if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
+        // 加锁
+        synchronized (this.singletonObjects) {
+            // 从 earlySingletonObjects 获取
+            singletonObject = this.earlySingletonObjects.get(beanName);
+            // earlySingletonObjects 中没有，且允许提前创建
+            if (singletonObject == null && allowEarlyReference) {
+                // 从 singletonFactories 中获取对应的 ObjectFactory
+                ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
+                if (singletonFactory != null) {
+                    // 获得 bean
+                    singletonObject = singletonFactory.getObject();
+                    // 添加 bean 到 earlySingletonObjects 中
+                    this.earlySingletonObjects.put(beanName, singletonObject);
+                    // 从 singletonFactories 中移除对应的 ObjectFactory
+                    this.singletonFactories.remove(beanName);
+                }
+            }
+        }
+    }
+    return singletonObject;
+}
+```
+
+这段代码非常简单，保持淡定，过程如下：
+
+- 第一步，从 `singletonObjects` 中，获取 Bean 对象。
+
+- 第二步，若为空且当前 bean 正在创建中，则从 `earlySingletonObjects` 中获取 Bean 对象。
+
+- 第三步，若为空且允许提前创建，则从 `singletonFactories` 中获取相应的 ObjectFactory 对象。若不为空，则调用其 `ObjectFactory#getObject(String name)` 方法，创建 Bean 对象，然后将其加入到 `earlySingletonObjects` ，然后从 `singletonFactories` 删除。
+
+- 总体逻辑，就是根据 `beanName` 依次检测这三个 Map，若为空，从下一个，否则返回。这三个 Map 存放的都有各自的功能，代码如下：
+
+  ```
+  // DefaultSingletonBeanRegistry.java
+  
+  /**
+   * Cache of singleton objects: bean name to bean instance.
+   *
+   * 存放的是单例 bean 的映射。
+   *
+   * 对应关系为 bean name --> bean instance
+   */
+  private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);
+  
+  /**
+   * Cache of singleton factories: bean name to ObjectFactory.
+   *
+   * 存放的是 ObjectFactory，可以理解为创建单例 bean 的 factory 。
+   *
+   * 对应关系是 bean name --> ObjectFactory
+   **/
+  private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16);
+  
+  /**
+   * Cache of early singleton objects: bean name to bean instance.
+   *
+   * 存放的是早期的 bean，对应关系也是 bean name --> bean instance。
+   *
+   * 它与 {@link #singletonFactories} 区别在于 earlySingletonObjects 中存放的 bean 不一定是完整。
+   *
+   * 从 {@link #getSingleton(String)} 方法中，我们可以了解，bean 在创建过程中就已经加入到 earlySingletonObjects 中了。
+   * 所以当在 bean 的创建过程中，就可以通过 getBean() 方法获取。
+   *
+   * 这个 Map 也是【循环依赖】的关键所在。
+   */
+  private final Map<String, Object> earlySingletonObjects = new HashMap<>(16);
+  ```
+
+## 1.1 isSingletonCurrentlyInCreation
+
+在上面代码中，还有一个非常重要的检测方法 `#isSingletonCurrentlyInCreation(String beanName)` 方法，该方法用于判断该 `beanName` 对应的 Bean **是否在创建过程**中，注意这个过程讲的是整个工厂中。代码如下：
+
+```
+// DefaultSingletonBeanRegistry.java
+
+/**
+ * Names of beans that are currently in creation.
+ *
+ * 正在创建中的单例 Bean 的名字的集合
+ */
+private final Set<String> singletonsCurrentlyInCreation =
+		Collections.newSetFromMap(new ConcurrentHashMap<>(16));
+```
+
+从这段代码中，我们可以预测，在 Bean 创建过程中都会将其加入到 `singletonsCurrentlyInCreation` 集合中。具体是在什么时候加的，我们后面分析。
+
+# 2. getObjectForBeanInstance
+
+到这里从缓存中获取 bean 的过程已经分析完毕了，我们再看开篇的代码段，从缓存中获取 Bean 后，若其不为 `null` 且 `args` 为空，则会调用 `#getObjectForBeanInstance(Object beanInstance, String name, String beanName,RootBeanDefinition mbd)` 方法，进行处理。
+
+- 为什么会有这么一段呢？因为我们从缓存中获取的 bean 是**最原始**的 Bean ，并不一定使我们最终想要的 Bean 。
+- 怎么办呢？调用 `#getObjectForBeanInstance(...)` 方法，进行处理，该方法的定义为获取给定 Bean 实例的对象，该对象要么是 bean 实例本身，要么就是 FactoryBean 创建的 Bean 对象。
+
+代码如下：
+
+```
+// AbstractBeanFactory.java
+
+protected Object getObjectForBeanInstance(
+        Object beanInstance, String name, String beanName, @Nullable RootBeanDefinition mbd) {
+    // <1> 若为工厂类引用（name 以 & 开头）
+    // Don't let calling code try to dereference the factory if the bean isn't a factory.
+    if (BeanFactoryUtils.isFactoryDereference(name)) {
+        // 如果是 NullBean，则直接返回
+        if (beanInstance instanceof NullBean) {
+            return beanInstance;
+        }
+        // 如果 beanInstance 不是 FactoryBean 类型，则抛出异常
+        if (!(beanInstance instanceof FactoryBean)) {
+            throw new BeanIsNotAFactoryException(transformedBeanName(name), beanInstance.getClass());
+        }
+    }
+
+    // 到这里我们就有了一个 Bean 实例，当然该实例可能是会是是一个正常的 bean 又或者是一个 FactoryBean
+    // 如果是 FactoryBean，我我们则创建该 Bean
+    // 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, unless the
+    // caller actually wants a reference to the factory.
+    if (!(beanInstance instanceof FactoryBean) || BeanFactoryUtils.isFactoryDereference(name)) {
+        return beanInstance;
+    }
+
+    Object object = null;
+    // <3> 若 BeanDefinition 为 null，则从缓存中加载 Bean 对象
+    if (mbd == null) {
+        object = getCachedObjectForFactoryBean(beanName);
+    }
+    // 若 object 依然为空，则可以确认，beanInstance 一定是 FactoryBean 。从而，使用 FactoryBean 获得 Bean 对象
+    if (object == null) {
+        // Return bean instance from factory.
+        FactoryBean<?> factory = (FactoryBean<?>) beanInstance;
+        // containsBeanDefinition 检测 beanDefinitionMap 中也就是在所有已经加载的类中
+        // 检测是否定义 beanName
+        // Caches object obtained from FactoryBean if it is a singleton.
+        if (mbd == null && containsBeanDefinition(beanName)) {
+            // 将存储 XML 配置文件的 GenericBeanDefinition 转换为 RootBeanDefinition，
+            // 如果指定 BeanName 是子 Bean 的话同时会合并父类的相关属性
+            mbd = getMergedLocalBeanDefinition(beanName);
+        }
+        // 是否是用户定义的，而不是应用程序本身定义的
+        boolean synthetic = (mbd != null && mbd.isSynthetic());
+        // 核心处理方法，使用 FactoryBean 获得 Bean 对象
+        object = getObjectFromFactoryBean(factory, beanName, !synthetic);
+    }
+    return object;
+}
+```
+
+该方法主要是进行检测工作的，主要如下：
+
+- `<1>` 处，若 `name` 为工厂相关的（以 & 开头），且 `beanInstance` 为 NullBean 类型则直接返回，如果 `beanInstance` 不为 FactoryBean 类型则抛出 BeanIsNotAFactoryException 异常。这里主要是**校验** `beanInstance` 的**正确性**。
+
+- `<2>` 处，如果 `beanInstance` 不为 FactoryBean 类型或者 `name` 也不是与工厂相关的，则直接返回 `beanInstance` 这个 Bean 对象。**这里主要是对非 FactoryBean 类型处理**。
+
+- `<3>` 处，如果 BeanDefinition 为空，则从 `factoryBeanObjectCache` 中加载 Bean 对象。如果还是空，则可以断定 `beanInstance` 一定是 FactoryBean 类型，则委托 `#getObjectFromFactoryBean(FactoryBean<?> factory, String beanName, boolean shouldPostProcess)` 方法，进行处理，**使用 FactoryBean 获得 Bean 对象**。
+
+  > 老艿艿：所以实际上，`#getObjectForBeanInstance(...)` 方法的**重心**，就是使用 FactoryBean 对象，获得( 或者创建 )其 Bean 对象，即调用 `#getObjectFromFactoryBean(...)` 方法。
+
+## 2.1 getObjectFromFactoryBean
+
+从上面可以看出， `#getObjectForBeanInstance(Object beanInstance, String name, String beanName,RootBeanDefinition mbd)` 方法，分成两种情况：
+
+- 第一种，当该实例对象为**非 FactoryBean 类型**，**直接**返回给定的 Bean 实例对象 `beanInstance` 。
+- 第二种，当该实例对象为**FactoryBean 类型**，从 FactoryBean ( `beanInstance` ) 中，获取 Bean 实例对象。
+
+第二种，通过 `#getObjectFromFactoryBean(FactoryBean<?> factory, String beanName, boolean shouldPostProcess)` 方法来实现。代码如下：
+
+```
+// FactoryBeanRegistrySupport.java
+
+/**
+ * Cache of singleton objects created by FactoryBeans: FactoryBean name to object.
+ *
+ * 缓存 FactoryBean 创建的单例 Bean 对象的映射
+ * beanName ===> Bean 对象
+ */
+private final Map<String, Object> factoryBeanObjectCache = new ConcurrentHashMap<>(16);
+
+protected Object getObjectFromFactoryBean(FactoryBean<?> factory, String beanName, boolean shouldPostProcess) {
+    // <1> 为单例模式且缓存中存在
+    if (factory.isSingleton() && containsSingleton(beanName)) {
+        synchronized (getSingletonMutex()) { // <1.1> 单例锁
+            // <1.2> 从缓存中获取指定的 factoryBean
+            Object object = this.factoryBeanObjectCache.get(beanName);
+            if (object == null) {
+                // 为空，则从 FactoryBean 中获取对象
+                object = doGetObjectFromFactoryBean(factory, beanName);
+                // 从缓存中获取
+                // TODO 芋艿，具体原因
+                // Only post-process and store if not put there already during getObject() call above
+                // (e.g. because of circular reference processing triggered by custom getBean calls)
+                Object alreadyThere = this.factoryBeanObjectCache.get(beanName);
+                if (alreadyThere != null) {
+                    object = alreadyThere;
+                } else {
+                    // <1.3> 需要后续处理
+                    if (shouldPostProcess) {
+                        // 若该 Bean 处于创建中，则返回非处理对象，而不是存储它
+                        if (isSingletonCurrentlyInCreation(beanName)) {
+                            // Temporarily return non-post-processed object, not storing it yet..
+                            return object;
+                        }
+                        // 单例 Bean 的前置处理
+                        beforeSingletonCreation(beanName);
+                        try {
+                            // 对从 FactoryBean 获取的对象进行后处理
+                            // 生成的对象将暴露给 bean 引用
+                            object = postProcessObjectFromFactoryBean(object, beanName);
+                        } catch (Throwable ex) {
+                            throw new BeanCreationException(beanName,
+                                    "Post-processing of FactoryBean's singleton object failed", ex);
+                        } finally {
+                            // 单例 Bean 的后置处理
+                            afterSingletonCreation(beanName);
+                        }
+                    }
+                    // <1.4> 添加到 factoryBeanObjectCache 中，进行缓存
+                    if (containsSingleton(beanName)) {
+                        this.factoryBeanObjectCache.put(beanName, object);
+                    }
+                }
+            }
+            return object;
+        }
+    // <2>
+    } else {
+        // 为空，则从 FactoryBean 中获取对象
+        Object object = doGetObjectFromFactoryBean(factory, beanName);
+        // 需要后续处理
+        if (shouldPostProcess) {
+            try {
+                // 对从 FactoryBean 获取的对象进行后处理
+                // 生成的对象将暴露给 bean 引用
+                object = postProcessObjectFromFactoryBean(object, beanName);
+            }
+            catch (Throwable ex) {
+                throw new BeanCreationException(beanName, "Post-processing of FactoryBean's object failed", ex);
+            }
+        }
+        return object;
+    }
+}
+```
+
+主要流程如下：
+
+- 若为单例且单例 Bean 缓存中存在 `beanName` ，则 `<1>` 进行后续处理（跳转到下一步），否则，则 `<2>` 从 FactoryBean 中获取 Bean 实例对象。
+
+- `<1.1>` 首先，获取锁。其实我们在前面篇幅中发现了大量的同步锁，锁住的对象都是 `this.singletonObjects`，主要是因为在单例模式中必须要**保证全局唯一**。代码如下：
+
+  ```
+  // DefaultSingletonBeanRegistry.java
+  
+  /**
+   * Cache of singleton objects: bean name to bean instance.
+   *
+   * 存放的是单例 bean 的映射。
+   *
+   * 对应关系为 bean name --> bean instance
+   */
+  private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);
+  
+  public final Object getSingletonMutex() {
+  	return this.singletonObjects;
+  }
+  ```
+
+- `<1.2>` 然后，从 `factoryBeanObjectCache` 缓存中获取实例对象 `object` 。若 `object` 为空，则调用 `#doGetObjectFromFactoryBean(FactoryBean<?> factory, String beanName)` 方法，从 FactoryBean 获取对象，其实内部就是调用 `FactoryBean#getObject()` 方法。代码如下：
+
+  ```
+  private Object doGetObjectFromFactoryBean(final FactoryBean<?> factory, final String beanName)
+      throws BeanCreationException {
+      Object object;
+      try {
+          // 需要权限验证
+          if (System.getSecurityManager() != null) {
+              AccessControlContext acc = getAccessControlContext();
+              try {
+                  // <x> 从 FactoryBean 中，获得 Bean 对象
+                  object = AccessController.doPrivileged((PrivilegedExceptionAction<Object>) factory::getObject, acc);
+              } catch (PrivilegedActionException pae) {
+                  throw pae.getException();
+              }
+          } else {
+              // <x> 从 FactoryBean 中，获得 Bean 对象
+              object = factory.getObject();
+          }
+      } catch (FactoryBeanNotInitializedException ex) {
+          throw new BeanCurrentlyInCreationException(beanName, ex.toString());
+      } catch (Throwable ex) {
+          throw new BeanCreationException(beanName, "FactoryBean threw exception on object creation", ex);
+      }
+      // Do not accept a null value for a FactoryBean that's not fully
+      // initialized yet: Many FactoryBeans just return null then.
+      if (object == null) {
+          if (isSingletonCurrentlyInCreation(beanName)) {
+              throw new BeanCurrentlyInCreationException(
+                      beanName, "FactoryBean which is currently in creation returned null from getObject");
+          }
+          object = new NullBean();
+      }
+      return object;
+  }
+  ```
+
+  - 在 `<x>` 处，可以看到，调用 `FactoryBean#getObject()` 方法，获取 Bean 对象。
+
+- `<1.3>` 如果需要后续处理( `shouldPostProcess = true` )，则进行进一步处理，步骤如下：
+
+  - 若该 Bean 处于创建中（`#isSingletonCurrentlyInCreation(String beanName)` 方法返回 `true` ），则返回**非处理的 Bean 对象**，而不是存储它。
+  - 调用 `#beforeSingletonCreation(String beanName)` 方法，进行创建之前的处理。默认实现将该 Bean 标志为当前创建的。
+  - 调用 `#postProcessObjectFromFactoryBean(Object object, String beanName)` 方法，对从 FactoryBean 获取的 Bean 实例对象进行后置处理。详细解析，见 [「2.3 postProcessObjectFromFactoryBean」](https://svip.iocoder.cn/Spring/IoC-get-Bean-getSingleton/#) 。
+  - 调用 `#afterSingletonCreation(String beanName)` 方法，进行创建 Bean 之后的处理，默认实现是将该 bean 标记为不再在创建中。
+
+- `<1.4>` 最后，加入到 `factoryBeanObjectCache` 缓存中。
+
+该方法应该就是创建 Bean 实例对象中的核心方法之一了。这里我们关注三个方法：
+
+- `#beforeSingletonCreation(String beanName)`
+- `#afterSingletonCreation(String beanName)`
+- `#postProcessObjectFromFactoryBean(Object object, String beanName)`
+
+## 2.2 isSingletonCurrentlyInCreation
+
+可能有小伙伴觉得前面两个方法不是很重要，LZ 可以肯定告诉你，这两方法是非常重要的操作，因为**他们记录着 Bean 的加载状态，是检测当前 Bean 是否处于创建中的关键之处，对解决 Bean 循环依赖起着关键作用**。
+
+- `#beforeSingletonCreation(String beanName)` 方法，用于添加标志，当前 bean **正处于**创建中
+- `#afterSingletonCreation(String beanName)` 方法，用于移除标记，当前 Bean **不处于**创建中。
+
+其实在这篇博客刚刚开始就已经提到了， `#isSingletonCurrentlyInCreation(String beanName)` 方法，是用于检测当前 Bean 是否处于创建之中。代码如下：
+
+```
+// DefaultSingletonBeanRegistry.java
+
+/**
+ * Names of beans that are currently in creation.
+ *
+ * 正在创建中的单例 Bean 的名字的集合
+ */
+private final Set<String> singletonsCurrentlyInCreation =
+        Collections.newSetFromMap(new ConcurrentHashMap<>(16));
+```
+
+- 是根据 `singletonsCurrentlyInCreation` 集合中是否包含了 `beanName` 。
+
+### 2.2.1 beforeSingletonCreation
+
+集合的元素，则一定是在 `#beforeSingletonCreation(String beanName)` 方法中添加的。代码如下：
+
+```
+// DefaultSingletonBeanRegistry.java
+
+protected void beforeSingletonCreation(String beanName) {
+	if (!this.inCreationCheckExclusions.contains(beanName)
+            && !this.singletonsCurrentlyInCreation.add(beanName)) { // 添加
+		throw new BeanCurrentlyInCreationException(beanName); // 如果添加失败，则抛出 BeanCurrentlyInCreationException 异常。
+	}
+}
+```
+
+### 2.2.2 afterSingletonCreation
+
+`#afterSingletonCreation(String beanName)` 方法，为移除，则一定就是对 `singletonsCurrentlyInCreation` 集合 remove 了。代码如下：
+
+```
+// DefaultSingletonBeanRegistry.java
+
+protected void afterSingletonCreation(String beanName) {
+	if (!this.inCreationCheckExclusions.contains(beanName) &&
+            !this.singletonsCurrentlyInCreation.remove(beanName)) { // 移除
+	    // 如果移除失败，则抛出 IllegalStateException 异常
+		throw new IllegalStateException("Singleton '" + beanName + "' isn't currently in creation");
+	}
+}
+```
+
+## 2.3 postProcessObjectFromFactoryBean
+
+`postProcessObjectFromFactoryBean(Object object, String beanName)` 方法，对从 FactoryBean 处获取的 Bean 实例对象进行后置处理。其默认实现是直接返回 object 对象，不做任何处理。代码如下：
+
+```
+// DefaultSingletonBeanRegistry.java
+
+protected Object postProcessObjectFromFactoryBean(Object object, String beanName) throws BeansException {
+	return object;
+}
+```
+
+### 2.3.1
+
+当然，子类可以重写，例如应用后处理器。`org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory` 抽象类，对其提供了实现，代码如下：
+
+```
+// AbstractAutowireCapableBeanFactory.java
+
+protected Object postProcessObjectFromFactoryBean(Object object, String beanName) {
+	return applyBeanPostProcessorsAfterInitialization(object, beanName);
+}
+```
+
+- 该方法的定义为：对所有的 `{@code postProcessAfterInitialization}` 进行回调注册 BeanPostProcessors ，让他们能够后期处理从 FactoryBean 中获取的对象。下面是具体实现：
+
+  ```
+  // AbstractAutowireCapableBeanFactory.java
+  
+  @Override
+  public Object applyBeanPostProcessorsAfterInitialization(Object existingBean, String beanName)
+          throws BeansException {
+      Object result = existingBean;
+      // 遍历 BeanPostProcessor
+      for (BeanPostProcessor processor : getBeanPostProcessors()) {
+          // 处理
+          Object current = processor.postProcessAfterInitialization(result, beanName);
+          // 返回空，则返回 result
+          if (current == null) {
+              return result;
+          }
+          // 修改 result
+          result = current;
+      }
+      return result;
+  }
+  ```
+
+  - 对于后置处理器，这里我们不做过多阐述，后面会专门的博文进行详细介绍，这里我们只需要记住一点：尽可能保证所有 bean 初始化后都会调用注册的 `BeanPostProcessor#postProcessAfterInitialization(Object bean, String beanName)` 方法进行处理，在实际开发过程中大可以针对此特性设计自己的业务逻辑。
+
+# 3. 小结
+
+至此，从缓存中获取 Bean 对象过程已经分析完毕了。
+
+下面两篇博客分析，如果从单例缓存中没有获取到单例 Bean ，则 Spring 是如何处理的。
\ No newline at end of file
diff --git a/spring/22-Spring-IoC 之加载 Bean：parentBeanFactory 与依赖处理.md b/spring/22-Spring-IoC 之加载 Bean：parentBeanFactory 与依赖处理.md
new file mode 100644
index 0000000..6c243ac
--- /dev/null
+++ b/spring/22-Spring-IoC 之加载 Bean：parentBeanFactory 与依赖处理.md	
@@ -0,0 +1,475 @@
+# 【死磕 Spring】—— IoC 之加载 Bean：parentBeanFactory 与依赖处理
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=todo 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+如果从单例缓存中没有获取到单例 Bean 对象，则说明两种两种情况：
+
+1. 该 Bean 的 scope 不是 singleton
+2. 该 Bean 的 scope 是 singleton ，但是没有初始化完成。
+
+针对这两种情况，Spring 是如何处理的呢？统一加载并完成初始化！这部分内容的篇幅较长，拆分为两部分：
+
+- 第一部分，主要是一些检测、parentBeanFactory 以及依赖处理。
+- 第二部分则是各个 scope 的初始化。
+
+代码如下：
+
+```
+// AbstractBeanFactory.java
+//protected <T> T doGetBean(final String name, final Class<T> requiredType, final Object[] args, boolean typeCheckOnly)
+
+// ... 省略很多代码
+
+// Fail if we're already creating this bean instance:
+// We're assumably within a circular reference.
+// <3> 因为 Spring 只解决单例模式下得循环依赖，在原型模式下如果存在循环依赖则会抛出异常。
+if (isPrototypeCurrentlyInCreation(beanName)) {
+    throw new BeanCurrentlyInCreationException(beanName);
+}
+
+// <4> 如果容器中没有找到，则从父类容器中加载
+// Check if bean definition exists in this factory.
+BeanFactory parentBeanFactory = getParentBeanFactory();
+if (parentBeanFactory != null && !containsBeanDefinition(beanName)) {
+    // Not found -> check parent.
+    String nameToLookup = originalBeanName(name);
+    if (parentBeanFactory instanceof AbstractBeanFactory) {
+        return ((AbstractBeanFactory) parentBeanFactory).doGetBean(
+                nameToLookup, requiredType, args, typeCheckOnly);
+    } else if (args != null) {
+        // Delegation to parent with explicit args.
+        return (T) parentBeanFactory.getBean(nameToLookup, args);
+    } else if (requiredType != null) {
+        // No args -> delegate to standard getBean method.
+        return parentBeanFactory.getBean(nameToLookup, requiredType);
+    } else {
+        return (T) parentBeanFactory.getBean(nameToLookup);
+    }
+}
+
+// <5> 如果不是仅仅做类型检查则是创建bean，这里需要记录
+if (!typeCheckOnly) {
+    markBeanAsCreated(beanName);
+}
+
+try {
+    // <6> 从容器中获取 beanName 相应的 GenericBeanDefinition 对象，并将其转换为 RootBeanDefinition 对象
+    final RootBeanDefinition mbd = getMergedLocalBeanDefinition(beanName);
+    // 检查给定的合并的 BeanDefinition
+    checkMergedBeanDefinition(mbd, beanName, args);
+
+    // Guarantee initialization of beans that the current bean depends on.
+    // <7> 处理所依赖的 bean
+    String[] dependsOn = mbd.getDependsOn();
+    if (dependsOn != null) {
+        for (String dep : dependsOn) {
+            // 若给定的依赖 bean 已经注册为依赖给定的 bean
+            // 循环依赖的情况
+            if (isDependent(beanName, dep)) {
+                throw new BeanCreationException(mbd.getResourceDescription(), beanName,
+                        "Circular depends-on relationship between '" + beanName + "' and '" + dep + "'");
+            }
+            // 缓存依赖调用
+            registerDependentBean(dep, beanName);
+            try {
+                getBean(dep);
+            } catch (NoSuchBeanDefinitionException ex) {
+                throw new BeanCreationException(mbd.getResourceDescription(), beanName,
+                        "'" + beanName + "' depends on missing bean '" + dep + "'", ex);
+            }
+        }
+    }
+}
+
+// ... 省略很多代码
+```
+
+这段代码主要处理如下几个部分：
+
+- ```
+  <3>
+  ```
+
+   
+
+  处，检测。若当前 Bean 在创建，则抛出 BeanCurrentlyInCreationException 异常。
+
+  - 详细解析，见 [「1. 检测」](https://svip.iocoder.cn/Spring/IoC-get-Bean-parentBeanFactory-and-depend-on/#) 。
+
+- ```
+  <4>
+  ```
+
+   
+
+  处，如果 beanDefinitionMap 中不存在 beanName 的 BeanDefinition（即在 Spring bean 初始化过程中没有加载），则尝试从 parentBeanFactory 中加载。
+
+  - 详细解析，见 [「2. 检查父类 BeanFactory」](https://svip.iocoder.cn/Spring/IoC-get-Bean-parentBeanFactory-and-depend-on/#) 。
+
+- ```
+  <5>
+  ```
+
+   
+
+  处，判断是否为类型检查。
+
+  - 详细解析，见 [「3. 类型检查」](https://svip.iocoder.cn/Spring/IoC-get-Bean-parentBeanFactory-and-depend-on/#) 。
+
+- ```
+  <6>
+  ```
+
+   
+
+  处，从
+
+   
+
+  ```
+  mergedBeanDefinitions
+  ```
+
+   
+
+  中获取
+
+   
+
+  ```
+  beanName
+  ```
+
+   
+
+  对应的 RootBeanDefinition 对象。如果这个 BeanDefinition 是子 Bean 的话，则会合并父类的相关属性。
+
+  - 详细解析，见 [「4. 获取 RootBeanDefinition」](https://svip.iocoder.cn/Spring/IoC-get-Bean-parentBeanFactory-and-depend-on/#) 。
+
+- ```
+  <7>
+  ```
+
+   
+
+  处，依赖处理。
+
+  - 详细解析，见 [「5. 处理依赖」](https://svip.iocoder.cn/Spring/IoC-get-Bean-parentBeanFactory-and-depend-on/#) 。
+
+# 1. 检测
+
+在前面就提过，Spring 只解决单例模式下的循环依赖，对于原型模式的循环依赖则是抛出 BeanCurrentlyInCreationException 异常，所以首先检查该 `beanName` 是否处于原型模式下的循环依赖。如下：
+
+```
+// AbstractBeanFactory.java
+
+if (isPrototypeCurrentlyInCreation(beanName)) {
+    throw new BeanCurrentlyInCreationException(beanName);
+}
+```
+
+- 调用 `#isPrototypeCurrentlyInCreation(String beanName)` 方法，判断当前 Bean 是否正在创建。代码如下：
+
+  ```
+  // AbstractBeanFactory.java
+  
+  protected boolean isPrototypeCurrentlyInCreation(String beanName) {
+  	Object curVal = this.prototypesCurrentlyInCreation.get();
+  	return (curVal != null &&
+  			(curVal.equals(beanName)  // 相等
+                      || (curVal instanceof Set && ((Set<?>) curVal).contains(beanName)))); // 包含
+  }
+  ```
+
+  - 其实检测逻辑和单例模式一样，一个“集合”存放着正在创建的 Bean ，从该集合中进行判断即可，只不过单例模式的“集合”为 Set ，而原型模式的则是 ThreadLocal 。`prototypesCurrentlyInCreation` 定义如下：
+
+    ```
+    // AbstractBeanFactory.java
+    
+    /** Names of beans that are currently in creation. */
+    private final ThreadLocal<Object> prototypesCurrentlyInCreation =
+    		new NamedThreadLocal<>("Prototype beans currently in creation");
+    ```
+
+# 2. 检查父类 BeanFactory
+
+若 `#containsBeanDefinition(String beanName)` 方法中不存在 `beanName` 相对应的 BeanDefinition 对象时，则从 `parentBeanFactory` 中获取。代码如下：
+
+```
+// AbstractBeanFactory.java
+
+// 获取 parentBeanFactory
+BeanFactory parentBeanFactory = getParentBeanFactory();
+// parentBeanFactory 不为空且 beanDefinitionMap 中不存该 name 的 BeanDefinition
+if (parentBeanFactory != null && !containsBeanDefinition(beanName)) {
+    // 确定原始 beanName
+    String nameToLookup = originalBeanName(name);
+    // 若为 AbstractBeanFactory 类型，委托父类处理
+    if (parentBeanFactory instanceof AbstractBeanFactory) {
+        return ((AbstractBeanFactory) parentBeanFactory).doGetBean(
+                nameToLookup, requiredType, args, typeCheckOnly);
+    } else if (args != null) {
+        // 委托给构造函数 getBean() 处理
+        return (T) parentBeanFactory.getBean(nameToLookup, args);
+    } else {
+        // 没有 args，委托给标准的 getBean() 处理
+        return parentBeanFactory.getBean(nameToLookup, requiredType);
+    }
+}
+```
+
+- 整个过程较为简单，都是委托 `parentBeanFactory` 的 `#getBean(...)` 方法来进行处理，只不过在获取之前对 `breanName` 进行简单的处理，主要是想获取原始的 `beanName` 。代码如下：
+
+  ```
+  // AbstractBeanFactory.java
+  
+  protected String originalBeanName(String name) {
+  	String beanName = transformedBeanName(name); // <1>
+  	if (name.startsWith(FACTORY_BEAN_PREFIX)) { // <2>
+  		beanName = FACTORY_BEAN_PREFIX + beanName;
+  	}
+  	return beanName;
+  }
+  ```
+
+  - `<1>` 处，`#transformedBeanName(String name)` 方法，是对 `name` 进行转换，获取真正的 beanName 。在 [《【死磕 Spring】—— IoC 之开启 Bean 的加载》](http://svip.iocoder.cn/Spring/IoC-get-Bean-begin) 中，已经有详细解析。
+  - `<2>` 处，如果 `name` 是以 `“&”` 开头的，则加上 `“&”` ，因为在 `#transformedBeanName(String name)` 方法，将 `“&”` 去掉了，这里**补上**。
+
+# 3. 类型检查
+
+方法参数 `typeCheckOnly` ，是用来判断调用 `#getBean(...)` 方法时，表示是否为**仅仅**进行类型检查获取 Bean 对象。如果不是仅仅做类型检查，而是创建 Bean 对象，则需要调用 `#markBeanAsCreated(String beanName)` 方法，进行记录。代码如下：
+
+```
+// AbstractBeanFactory.java
+
+/**
+ *  Names of beans that have already been created at least once.
+ *
+ *  已创建 Bean 的名字集合
+ */
+private final Set<String> alreadyCreated = Collections.newSetFromMap(new ConcurrentHashMap<>(256));
+
+protected void markBeanAsCreated(String beanName) {
+    // 没有创建
+    if (!this.alreadyCreated.contains(beanName)) {
+        // 加上全局锁
+        synchronized (this.mergedBeanDefinitions) {
+            // 再次检查一次：DCL 双检查模式
+            if (!this.alreadyCreated.contains(beanName)) {
+                // Let the bean definition get re-merged now that we're actually creating
+                // the bean... just in case some of its metadata changed in the meantime.
+                // 从 mergedBeanDefinitions 中删除 beanName，并在下次访问时重新创建它。
+                clearMergedBeanDefinition(beanName);
+                // 添加到已创建 bean 集合中
+                this.alreadyCreated.add(beanName);
+            }
+        }
+    }
+}
+
+protected void clearMergedBeanDefinition(String beanName) {
+    this.mergedBeanDefinitions.remove(beanName);
+}
+```
+
+# 4. 获取 RootBeanDefinition
+
+```
+// AbstractBeanFactory.java
+
+// 从容器中获取 beanName 相应的 GenericBeanDefinition 对象，并将其转换为 RootBeanDefinition 对象
+final RootBeanDefinition mbd = getMergedLocalBeanDefinition(beanName);
+// 检查给定的合并的 BeanDefinition
+checkMergedBeanDefinition(mbd, beanName, args);
+```
+
+- 调用 `#getMergedLocalBeanDefinition(String beanName)` 方法，获取相对应的 BeanDefinition 对象。代码如下：
+
+  ```
+  // AbstractBeanFactory.java
+  
+  /** Map from bean name to merged RootBeanDefinition. */
+  private final Map<String, RootBeanDefinition> mergedBeanDefinitions = new ConcurrentHashMap<>(256);
+  
+  protected RootBeanDefinition getMergedLocalBeanDefinition(String beanName) throws BeansException {
+      // Quick check on the concurrent map first, with minimal locking.
+      // 快速从缓存中获取，如果不为空，则直接返回
+      RootBeanDefinition mbd = this.mergedBeanDefinitions.get(beanName);
+      if (mbd != null) {
+          return mbd;
+      }
+      // 获取 RootBeanDefinition，
+      // 如果返回的 BeanDefinition 是子类 bean 的话，则合并父类相关属性
+      return getMergedBeanDefinition(beanName, getBeanDefinition(beanName));
+  }
+  ```
+
+  - 首先，直接从 `mergedBeanDefinitions` 缓存中获取相应的 RootBeanDefinition 对象，如果存在则直接返回。
+  - 否则，调用 `#getMergedBeanDefinition(String beanName, BeanDefinition bd)` 方法，获取 RootBeanDefinition 对象。若获取的 BeanDefinition 为**子** BeanDefinition，则需要合并**父类**的相关属性。关于该方法的源码，本文不做详细解析。感兴趣的胖友，可以自己研究。
+
+- 调用 `#checkMergedBeanDefinition()` 方法，检查给定的合并的 BeanDefinition 对象。代码如下：
+
+  ```
+  // AbstractBeanFactory.java
+  
+  protected void checkMergedBeanDefinition(RootBeanDefinition mbd, String beanName, @Nullable Object[] args)
+  		throws BeanDefinitionStoreException {
+  	if (mbd.isAbstract()) {
+  		throw new BeanIsAbstractException(beanName);
+  	}
+  }
+  ```
+
+# 5. 处理依赖
+
+如果一个 Bean 有依赖 Bean 的话，那么在初始化该 Bean 时是需要先初始化它所依赖的 Bean 。代码如下：
+
+```
+// AbstractBeanFactory.java
+
+// Guarantee initialization of beans that the current bean depends on.
+// 处理所依赖的 bean
+String[] dependsOn = mbd.getDependsOn();
+if (dependsOn != null) {
+    for (String dep : dependsOn) {
+        // <1> 若给定的依赖 bean 已经注册为依赖给定的 bean
+        // 即循环依赖的情况，抛出 BeanCreationException 异常
+        if (isDependent(beanName, dep)) {
+            throw new BeanCreationException(mbd.getResourceDescription(), beanName,
+                    "Circular depends-on relationship between '" + beanName + "' and '" + dep + "'");
+        }
+        // <2> 缓存依赖调用 TODO 芋艿
+        registerDependentBean(dep, beanName);
+        try {
+            // <3> 递归处理依赖 Bean
+            getBean(dep);
+        } catch (NoSuchBeanDefinitionException ex) {
+            throw new BeanCreationException(mbd.getResourceDescription(), beanName,
+                    "'" + beanName + "' depends on missing bean '" + dep + "'", ex);
+        }
+    }
+}
+```
+
+- 这段代码逻辑是：通过迭代的方式依次对依赖 bean 进行检测、校验。如果通过，则调用 `#getBean(String beanName)` 方法，实例化**依赖**的 Bean 对象。
+
+## 5.1 isDependent
+
+`<1>` 处，调用 `#isDependent(String beanName, String dependentBeanName)` 方法，是校验该依赖是否已经注册给当前 Bean 。代码如下：
+
+```
+// DefaultSingletonBeanRegistry.java
+
+/**
+ * Map between dependent bean names: bean name to Set of dependent bean names.
+ *
+ * 保存的是依赖 beanName 之间的映射关系：beanName - > 依赖 beanName 的集合
+ */
+private final Map<String, Set<String>> dependentBeanMap = new ConcurrentHashMap<>(64);
+
+protected boolean isDependent(String beanName, String dependentBeanName) {
+	synchronized (this.dependentBeanMap) {
+		return isDependent(beanName, dependentBeanName, null);
+	}
+}
+```
+
+- `dependentBeanMap` 对象保存的是依赖 `beanName` 之间的映射关系：`beanName` - > 依赖 `beanName` 的集合。
+
+- 同步加锁给 `dependentBeanMap` 对象，然后调用 `#isDependent(String beanName, String dependentBeanName, Set<String> alreadySeen)` 方法，进行校验。代码如下：
+
+  ```
+  // DefaultSingletonBeanRegistry.java
+  
+  private boolean isDependent(String beanName, String dependentBeanName, @Nullable Set<String> alreadySeen) {
+      // alreadySeen 已经检测的依赖 bean
+      if (alreadySeen != null && alreadySeen.contains(beanName)) {
+          return false;
+      }
+      // 获取原始 beanName
+      String canonicalName = canonicalName(beanName);
+      // 获取当前 beanName 的依赖集合
+      Set<String> dependentBeans = this.dependentBeanMap.get(canonicalName);
+      if (dependentBeans == null) {
+          return false;
+      }
+      // 存在，则证明存在已经注册的依赖
+      if (dependentBeans.contains(dependentBeanName)) {
+          return true;
+      }
+      // 递归检测依赖
+      for (String transitiveDependency : dependentBeans) {
+          if (alreadySeen == null) {
+              alreadySeen = new HashSet<>();
+          }
+          // 添加到 alreadySeen 中
+          alreadySeen.add(beanName);
+          // 递推
+          if (isDependent(transitiveDependency, dependentBeanName, alreadySeen)) {
+              return true;
+          }
+      }
+      return false;
+  }
+  ```
+
+  - 代码比较长，当然也有点绕。感兴趣的胖友，可以调试下。
+
+## 5.2 registerDependentBean
+
+`<2>` 处，如果校验成功，则调用 `#registerDependentBean(String beanName, String dependentBeanName)` 方法，将该依赖进行注册，便于在销毁 Bean 之前对其进行销毁。代码如下：
+
+```
+// DefaultSingletonBeanRegistry.java
+
+/**
+ * Map between dependent bean names: bean name to Set of dependent bean names.
+ *
+ * 保存的是依赖 beanName 之间的映射关系：beanName - > 依赖 beanName 的集合
+ */
+private final Map<String, Set<String>> dependentBeanMap = new ConcurrentHashMap<>(64);
+
+/**
+ * Map between depending bean names: bean name to Set of bean names for the bean's dependencies.
+ *
+ * 保存的是依赖 beanName 之间的映射关系：依赖 beanName - > beanName 的集合
+ */
+private final Map<String, Set<String>> dependenciesForBeanMap = new ConcurrentHashMap<>(64);
+
+public void registerDependentBean(String beanName, String dependentBeanName) {
+    // 获取 beanName
+    String canonicalName = canonicalName(beanName);
+
+    // 添加 <canonicalName, <dependentBeanName>> 到 dependentBeanMap 中
+    synchronized (this.dependentBeanMap) {
+        Set<String> dependentBeans =
+                this.dependentBeanMap.computeIfAbsent(canonicalName, k -> new LinkedHashSet<>(8));
+        if (!dependentBeans.add(dependentBeanName)) {
+            return;
+        }
+    }
+
+    // 添加 <dependentBeanName, <canonicalName>> 到 dependenciesForBeanMap 中
+    synchronized (this.dependenciesForBeanMap) {
+        Set<String> dependenciesForBean =
+                this.dependenciesForBeanMap.computeIfAbsent(dependentBeanName, k -> new LinkedHashSet<>(8));
+        dependenciesForBean.add(canonicalName);
+    }
+}
+```
+
+- 其实将就是该映射关系保存到两个集合中：`dependentBeanMap`、`dependenciesForBeanMap` 。
+
+## 5.3 getBean
+
+`<3>` 处，最后调用 `#getBean(String beanName)` 方法，实例化依赖 Bean 对象。
+
+# 6. 小结
+
+至此，加载 bean 的第二个部分也分析完毕了，下篇开始分析第三个部分：各大作用域 bean 的处理。
\ No newline at end of file
diff --git a/spring/23-Spring-IoC 之加载 Bean：分析各 scope 的 Bean 创建.md b/spring/23-Spring-IoC 之加载 Bean：分析各 scope 的 Bean 创建.md
new file mode 100644
index 0000000..bd294c4
--- /dev/null
+++ b/spring/23-Spring-IoC 之加载 Bean：分析各 scope 的 Bean 创建.md	
@@ -0,0 +1,330 @@
+# 【死磕 Spring】—— IoC 之加载 Bean：分析各 scope 的 Bean 创建
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=todo 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+在 Spring 中存在着不同的 scope，默认是 singleton ，还有 prototype、request 等等其他的 scope 。他们的初始化步骤是怎样的呢？这个答案在这篇博客中给出。
+
+# 1. singleton
+
+Spring 的 scope 默认为 singleton ，其初始化的代码如下：
+
+```
+// AbstractBeanFactory.java
+
+if (mbd.isSingleton()) { // 单例模式
+    sharedInstance = getSingleton(beanName, () -> {
+        try {
+            return createBean(beanName, mbd, args);
+        }
+        catch (BeansException ex) {
+            // Explicitly remove instance from singleton cache: It might have been put there
+            // eagerly by the creation process, to allow for circular reference resolution.
+            // Also remove any beans that received a temporary reference to the bean.
+            // 显式从单例缓存中删除 Bean 实例
+            // 因为单例模式下为了解决循环依赖，可能他已经存在了，所以销毁它。 TODO 芋艿
+            destroySingleton(beanName);
+            throw ex;
+        }
+    });
+    // <x>
+    bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
+}
+```
+
+- 在 [《【死磕 Spring】—— IoC 之加载 Bean：从单例缓存中获取单》](http://svip.iocoder.cn/Spring/IoC-get-Bean-getSingleton) 中，已经分析了从缓存中获取单例模式的 bean 。但是如果缓存中**不存在**呢？则需要从头开始加载 Bean ，这个过程由 `#getSingleton(String beanName, ObjectFactory<?> singletonFactory)` 方法来实现。代码如下：
+
+  ```
+  // DefaultSingletonBeanRegistry.java
+  
+  public Object getSingleton(String beanName, ObjectFactory<?> singletonFactory) {
+      Assert.notNull(beanName, "Bean name must not be null");
+      // 全局加锁
+      synchronized (this.singletonObjects) {
+          // <1> 从缓存中检查一遍
+          // 因为 singleton 模式其实就是复用已经创建的 bean 所以这步骤必须检查
+          Object singletonObject = this.singletonObjects.get(beanName);
+          //  为空，开始加载过程
+          if (singletonObject == null) {
+              if (this.singletonsCurrentlyInDestruction) {
+                  throw new BeanCreationNotAllowedException(beanName,
+                          "Singleton bean creation not allowed while singletons of this factory are in destruction " +
+                          "(Do not request a bean from a BeanFactory in a destroy method implementation!)");
+              }
+              if (logger.isDebugEnabled()) {
+                  logger.debug("Creating shared instance of singleton bean '" + beanName + "'");
+              }
+              // <2> 加载前置处理
+              beforeSingletonCreation(beanName);
+              boolean newSingleton = false;
+              boolean recordSuppressedExceptions = (this.suppressedExceptions == null);
+              if (recordSuppressedExceptions) {
+                  this.suppressedExceptions = new LinkedHashSet<>();
+              }
+              try {
+                  // <3> 初始化 bean
+                  // 这个过程其实是调用 createBean() 方法
+                  singletonObject = singletonFactory.getObject();
+                  newSingleton = true;
+              } catch (IllegalStateException ex) {
+                  // Has the singleton object implicitly appeared in the meantime ->
+                  // if yes, proceed with it since the exception indicates that state.
+                  singletonObject = this.singletonObjects.get(beanName);
+                  if (singletonObject == null) {
+                      throw ex;
+                  }
+              } catch (BeanCreationException ex) {
+                  if (recordSuppressedExceptions) {
+                      for (Exception suppressedException : this.suppressedExceptions) {
+                          ex.addRelatedCause(suppressedException);
+                      }
+                  }
+                  throw ex;
+              } finally {
+                  if (recordSuppressedExceptions) {
+                      this.suppressedExceptions = null;
+                  }
+                  // <4> 后置处理
+                  afterSingletonCreation(beanName);
+              }
+              // <5> 加入缓存中
+              if (newSingleton) {
+                  addSingleton(beanName, singletonObject);
+              }
+          }
+          return singletonObject;
+      }
+  }
+  ```
+
+  - 其实，这个过程并没有真正创建 Bean 对象，仅仅只是做了一部分准备和预处理步骤。真正获取单例 bean 的方法，其实是由 `<3>` 处的 `singletonFactory.getObject()` 这部分代码块来实现，而 `singletonFactory` 由回调方法产生。
+  - 那么这个方法做了哪些准备呢？
+    - `<1>` 处，再次检查缓存是否已经加载过，如果已经加载了则直接返回，否则开始加载过程。
+    - `<2>` 处，调用 `#beforeSingletonCreation(String beanName)` 方法，记录加载单例 bean 之前的加载状态，即前置处理。在 [《【死磕 Spring】—— IoC 之加载 Bean：从单例缓存中获取单例 Bean》](http://svip.iocoder.cn/Spring/IoC-get-Bean-getSingleton) 中，已经详细解析。
+    - `<3>` 处，调用参数传递的 ObjectFactory 的 `#getObject()` 方法，实例化 bean 。【重要】后续文章，详细解析。
+    - `<4>` 处，调用 `#afterSingletonCreation(String beanName)` 方法，进行加载单例后的后置处理。在 [《【死磕 Spring】—— IoC 之加载 Bean：从单例缓存中获取单例 Bean》](http://svip.iocoder.cn/Spring/IoC-get-Bean-getSingleton) 中，已经详细解析。
+    - `<5>` 处，调用 `#addSingleton(String beanName, Object singletonObject)` 方法，将结果记录并加入值缓存中，同时删除加载 bean 过程中所记录的一些辅助状态。详细解析，见 [「1.1 addSingleton」](https://svip.iocoder.cn/Spring/IoC-get-Bean-different-scope/#) 。
+
+- 在 `<x>` 处，加载了单例 bean 后，调用 `#getObjectForBeanInstance(Object beanInstance, String name, String beanName, RootBeanDefinition mbd)` 方法，从 bean 实例中获取对象。该方法已经在 [《【死磕 Spring】—— IoC 之加载 Bean：从单例缓存中获取单例 Bean》](http://svip.iocoder.cn/Spring/IoC-get-Bean-getSingleton) 中，详细分析了。
+
+## 1.1 addSingleton
+
+```
+// DefaultSingletonBeanRegistry.java
+
+/**
+ * Cache of singleton objects: bean name to bean instance.
+ *
+ * 存放的是单例 bean 的映射。
+ *
+ * 对应关系为 bean name --> bean instance
+ */
+private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);
+
+/**
+ * Cache of singleton factories: bean name to ObjectFactory.
+ *
+ * 存放的是【早期】的单例 bean 的映射。
+ *
+ * 对应关系也是 bean name --> bean instance。
+ *
+ * 它与 {@link #singletonObjects} 的区别区别在，于 earlySingletonObjects 中存放的 bean 不一定是完整的。
+ *
+ * 从 {@link #getSingleton(String)} 方法中，中我们可以了解，bean 在创建过程中就已经加入到 earlySingletonObjects 中了，
+ * 所以当在 bean 的创建过程中就可以通过 getBean() 方法获取。
+ * 这个 Map 也是解决【循环依赖】的关键所在。
+ **/
+private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16);
+
+/**
+ * Cache of early singleton objects: bean name to bean instance.
+ *
+ * 存放的是 ObjectFactory 的映射，可以理解为创建单例 bean 的 factory 。
+ *
+ * 对应关系是 bean name --> ObjectFactory
+ */
+private final Map<String, Object> earlySingletonObjects = new HashMap<>(16);
+
+/** Set of registered singletons, containing the bean names in registration order. */
+private final Set<String> registeredSingletons = new LinkedHashSet<>(256);
+
+protected void addSingleton(String beanName, Object singletonObject) {
+	synchronized (this.singletonObjects) {
+		this.singletonObjects.put(beanName, singletonObject);
+		this.singletonFactories.remove(beanName);
+		this.earlySingletonObjects.remove(beanName);
+		this.registeredSingletons.add(beanName);
+	}
+}
+```
+
+- 一个 put、一个 add、两个 remove 操作。
+- 【put】`singletonObjects` 属性，单例 bean 的缓存。
+- 【remove】`singletonFactories` 属性，单例 bean Factory 的缓存。
+- 【remove】`earlySingletonObjects` 属性，“早期”创建的单例 bean 的缓存。
+- 【add】`registeredSingletons` 属性，已经注册的单例缓存。
+
+# 2. 原型模式
+
+```
+// AbstractBeanFactory.java
+
+else if (mbd.isPrototype()) {
+    Object prototypeInstance = null;
+    try {
+       // <1> 加载前置处理
+        beforePrototypeCreation(beanName);
+        // <2> 创建 Bean 对象
+        prototypeInstance = createBean(beanName, mbd, args);
+    } finally {
+       // <3> 加载后缀处理
+        afterPrototypeCreation(beanName);
+    }
+    // <4> 从 Bean 实例中获取对象
+    bean = getObjectForBeanInstance(prototypeInstance, name, beanName, mbd);
+}
+```
+
+原型模式的初始化过程很简单：直接创建一个**新**的 Bean 的实例就可以了。过程如下：
+
+- 在 `<1>` 处，调用 `#beforePrototypeCreation(String beanName)` 方法，记录加载原型模式 bean 之前的加载状态，即前置处理。详细解析，见 [「2.1 beforePrototypeCreation」](https://svip.iocoder.cn/Spring/IoC-get-Bean-different-scope/#) 。
+- 在 `<2>` 处，调用 `#createBean(String beanName)` 方法，创建一个 bean 实例对象。【重要】后续文章，详细解析。
+- 在 `<3>` 处，调用 `#afterSingletonCreation(String beanName)` 方法，进行加载原型模式 bean 后的后置处理。详细解析，见 [「2.3 afterSingletonCreation」](https://svip.iocoder.cn/Spring/IoC-get-Bean-different-scope/#) 。
+- 在 `<4>` 处，加载了单例 bean 后，调用 `#getObjectForBeanInstance(Object beanInstance, String name, String beanName, RootBeanDefinition mbd)` 方法，从 bean 实例中获取对象。该方法已经在 [《【死磕 Spring】—— IoC 之加载 Bean：从单例缓存中获取单例 Bean》](http://svip.iocoder.cn/Spring/IoC-get-Bean-getSingleton) 中，详细分析了。
+
+## 2.1 beforePrototypeCreation
+
+```
+// AbstractBeanFactory.java
+
+/** Names of beans that are currently in creation. */
+private final ThreadLocal<Object> prototypesCurrentlyInCreation =
+		new NamedThreadLocal<>("Prototype beans currently in creation");
+		
+protected void beforePrototypeCreation(String beanName) {
+	Object curVal = this.prototypesCurrentlyInCreation.get();
+	if (curVal == null) { // String
+		this.prototypesCurrentlyInCreation.set(beanName);
+	} else if (curVal instanceof String) { // String => Set
+		Set<String> beanNameSet = new HashSet<>(2);
+		beanNameSet.add((String) curVal);
+		beanNameSet.add(beanName);
+		this.prototypesCurrentlyInCreation.set(beanNameSet);
+	} else { // Set
+		Set<String> beanNameSet = (Set<String>) curVal;
+		beanNameSet.add(beanName);
+	}
+}
+```
+
+## 2.2 afterSingletonCreation
+
+```
+// AbstractBeanFactory.java
+
+protected void afterPrototypeCreation(String beanName) {
+	Object curVal = this.prototypesCurrentlyInCreation.get();
+	if (curVal instanceof String) { // String => null
+		this.prototypesCurrentlyInCreation.remove();
+	} else if (curVal instanceof Set) { // Set
+		Set<String> beanNameSet = (Set<String>) curVal;
+		beanNameSet.remove(beanName);
+		if (beanNameSet.isEmpty()) { // Set => null
+			this.prototypesCurrentlyInCreation.remove();
+		}
+	}
+}
+```
+
+# 3. 其它作用域
+
+```
+// AbstractBeanFactory.java
+
+else {
+    // 获得 scopeName 对应的 Scope 对象
+    String scopeName = mbd.getScope();
+    final Scope scope = this.scopes.get(scopeName);
+    if (scope == null) {
+        throw new IllegalStateException("No Scope registered for scope name '" + scopeName + "'");
+    }
+    try {
+        // 从指定的 scope 下创建 bean
+        Object scopedInstance = scope.get(beanName, () -> {
+            // 加载前置处理
+            beforePrototypeCreation(beanName);
+            try {
+                // 创建 Bean 对象
+                return createBean(beanName, mbd, args);
+            } finally {
+                // 加载后缀处理
+                afterPrototypeCreation(beanName);
+            }
+        });
+        // 从 Bean 实例中获取对象
+        bean = getObjectForBeanInstance(scopedInstance, name, beanName, mbd);
+    } catch (IllegalStateException ex) {
+        throw new BeanCreationException(beanName,
+                "Scope '" + scopeName + "' is not active for the current thread; consider " +
+                "defining a scoped proxy for this bean if you intend to refer to it from a singleton",
+                ex);
+    }
+}
+```
+
+- **核心流程和原型模式一样**，只不过获取 bean 实例是由 `Scope#get(String name, ObjectFactory<?> objectFactory)` 方法来实现。代码如下：
+
+  ```
+  // SimpleThreadScope.java
+  
+  private final ThreadLocal<Map<String, Object>> threadScope =
+      new NamedThreadLocal<Map<String, Object>>("SimpleThreadScope") {
+          @Override
+          protected Map<String, Object> initialValue() {
+              return new HashMap<>();
+          }
+      };
+  
+  @Override
+  public Object get(String name, ObjectFactory<?> objectFactory) {
+      // 获取 scope 缓存
+      Map<String, Object> scope = this.threadScope.get();
+      Object scopedObject = scope.get(name);
+      if (scopedObject == null) {
+          scopedObject = objectFactory.getObject();
+          // 加入缓存
+          scope.put(name, scopedObject);
+      }
+      return scopedObject;
+  }
+  ```
+
+  - `org.springframework.beans.factory.config.Scope` 接口，有**多种**实现类。其他的 Scope 实现类，感兴趣的胖友，可以单独去看。
+
+# 4. 小结
+
+对于上面三个模块，其中最重要的有两个方法：
+
+- 一个是 `#createBean(String beanName, RootBeanDefinition mbd, Object[] args)` 方法。
+- 一个是 `#getObjectForBeanInstance(Object beanInstance, String name, String beanName, RootBeanDefinition mbd)` 方法。
+
+这两个方法在上面三个模块都有调用。
+
+- `#createBean(String beanName, RootBeanDefinition mbd, Object[] args)` 方法，后续详细说明。
+
+- `#getObjectForBeanInstance(Object beanInstance, String name, String beanName, RootBeanDefinition mbd)` 方法，在博客 [《【死磕 Spring】—— IoC 之加载 Bean：从单例缓存中获取单》](http://svip.iooder.cn/Spring/IoC-get-Bean-getSingleton) 中有详细讲解。这里再次阐述下（此段内容来自《**Spring 源码深度解析**》）：
+
+  > 这个方法主要是验证以下我们得到的 bean 的正确性，其实就是检测当前 bean 是否是 FactoryBean 类型的 bean 。
+  >
+  > 如果是，那么需要调用该 bean 对应的 FactoryBean 实例的 `#getObject()` 方法，作为返回值。
+  >
+  > 无论是从缓存中获得到的 bean 还是通过不同的 scope 策略加载的 bean 都只是最原始的 bean 状态，并不一定就是我们最终想要的 bean。
+  >
+  > 举个例子，加入我们需要对工厂 bean 进行处理，那么这里得到的其实是工厂 bean 的初始状态，但是我们真正需要的是工厂 bean 中定义 `factory-method` 方法中返回的 bean，而 `#getObjectForBeanInstance(Object beanInstance, String name, String beanName, RootBeanDefinition mbd)` 方法，就是完成这个工作的。
+
+至此，Spring 加载 bean 的三个部分（LZ自己划分的）已经分析完毕了。
\ No newline at end of file
diff --git a/spring/24-Spring-IoC 之加载 Bean：创建 Bean（一）之主流程.md b/spring/24-Spring-IoC 之加载 Bean：创建 Bean（一）之主流程.md
new file mode 100644
index 0000000..e606043
--- /dev/null
+++ b/spring/24-Spring-IoC 之加载 Bean：创建 Bean（一）之主流程.md	
@@ -0,0 +1,473 @@
+# 【死磕 Spring】—— IoC 之加载 Bean：创建 Bean（一）之主流程
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=todo 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+# 1. createBean 抽象方法
+
+在上篇博客 [《【死磕 Spring】—— IoC 之加载 Bean：分析各 scope 的 Bean 创建》](http://svip.iocoder.cn/Spring/IoC-get-Bean-different-scope) 中，有一个核心方法没有讲到， `#createBean(String beanName, RootBeanDefinition mbd, Object[] args)` 方法，代码如下：
+
+```
+// AbstractBeanFactory.java
+
+protected abstract Object createBean(String beanName, RootBeanDefinition mbd, @Nullable Object[] args)
+		throws BeanCreationException;
+```
+
+- 该方法定义在 AbstractBeanFactory 中，其含义是根据给定的 BeanDefinition 和 `args` 实例化一个 Bean 对象。
+- 如果该 BeanDefinition 存在父类，则该 BeanDefinition 已经合并了父类的属性。
+- 所有 Bean 实例的创建，都会委托给该方法实现。
+- 该方法接受三个方法参数：
+  - `beanName` ：bean 的名字。
+  - `mbd` ：已经合并了父类属性的（如果有的话）BeanDefinition 对象。
+  - `args` ：用于构造函数或者工厂方法创建 Bean 实例对象的参数。
+
+# 2. createBean 默认实现
+
+该抽象方法的默认实现是在类 AbstractAutowireCapableBeanFactory 中实现，代码如下：
+
+```
+// AbstractAutowireCapableBeanFactory.java
+
+@Override
+protected Object createBean(String beanName, RootBeanDefinition mbd, @Nullable Object[] args)
+        throws BeanCreationException {
+
+    if (logger.isTraceEnabled()) {
+        logger.trace("Creating instance of bean '" + beanName + "'");
+    }
+    RootBeanDefinition mbdToUse = mbd;
+
+    // Make sure bean class is actually resolved at this point, and
+    // clone the bean definition in case of a dynamically resolved Class
+    // which cannot be stored in the shared merged bean definition.
+    // <1> 确保此时的 bean 已经被解析了
+    // 如果获取的class 属性不为null，则克隆该 BeanDefinition
+    // 主要是因为该动态解析的 class 无法保存到到共享的 BeanDefinition
+    Class<?> resolvedClass = resolveBeanClass(mbd, beanName);
+    if (resolvedClass != null && !mbd.hasBeanClass() && mbd.getBeanClassName() != null) {
+        mbdToUse = new RootBeanDefinition(mbd);
+        mbdToUse.setBeanClass(resolvedClass);
+    }
+
+    // Prepare method overrides.
+    try {
+        // <2> 验证和准备覆盖方法
+        mbdToUse.prepareMethodOverrides();
+    } catch (BeanDefinitionValidationException ex) {
+        throw new BeanDefinitionStoreException(mbdToUse.getResourceDescription(),
+                beanName, "Validation of method overrides failed", ex);
+    }
+
+    try {
+        // Give BeanPostProcessors a chance to return a proxy instead of the target bean instance.
+        // <3> 实例化的前置处理
+        // 给 BeanPostProcessors 一个机会用来返回一个代理类而不是真正的类实例
+        // AOP 的功能就是基于这个地方
+        Object bean = resolveBeforeInstantiation(beanName, mbdToUse);
+        if (bean != null) {
+            return bean;
+        }
+    } catch (Throwable ex) {
+        throw new BeanCreationException(mbdToUse.getResourceDescription(), beanName,
+                "BeanPostProcessor before instantiation of bean failed", ex);
+    }
+
+    try {
+        // <4> 创建 Bean 对象
+        Object beanInstance = doCreateBean(beanName, mbdToUse, args);
+        if (logger.isTraceEnabled()) {
+            logger.trace("Finished creating instance of bean '" + beanName + "'");
+        }
+        return beanInstance;
+    } catch (BeanCreationException | ImplicitlyAppearedSingletonException ex) {
+        // A previously detected exception with proper bean creation context already,
+        // or illegal singleton state to be communicated up to DefaultSingletonBeanRegistry.
+        throw ex;
+    } catch (Throwable ex) {
+        throw new BeanCreationException(
+                mbdToUse.getResourceDescription(), beanName, "Unexpected exception during bean creation", ex);
+    }
+}
+```
+
+过程如下：
+
+- `<1>` 处，解析指定 BeanDefinition 的 class 属性。
+- `<2>` 处，处理 `override` 属性。
+- `<3>` 处，实例化的前置处理。
+- `<4>` 处，创建 Bean 对象。
+
+详细解析，每 `<x>` 处，对应下面的 [「2.x」](https://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-1/#) 。
+
+## 2.1 解析指定 BeanDefinition 的 class
+
+```
+// AbstractAutowireCapableBeanFactory.java
+
+Class<?> resolvedClass = resolveBeanClass(mbd, beanName);
+if (resolvedClass != null && !mbd.hasBeanClass() && mbd.getBeanClassName() != null) {
+    mbdToUse = new RootBeanDefinition(mbd);
+    mbdToUse.setBeanClass(resolvedClass);
+}
+```
+
+- `#resolveBeanClass(final RootBeanDefinition mbd, String beanName, final Class<?>... typesToMatch)` 方法，主要是解析 bean definition 的 class 类，并将已经解析的 Class 存储在 bean definition 中以供后面使用。
+- 如果解析的 class 不为空，则会将该 BeanDefinition 进行设置到 `mbdToUse` 中。这样做的主要目的是，以为动态解析的 class 是无法保存到共享的 BeanDefinition 中。
+
+详细解析，见 TODO
+
+## 2.2 处理 override 属性
+
+大家还记得 `lookup-method` 和 `replace-method` 这两个配置功能？在博客 [《【死磕 Spring】—— IoC 之解析 标签：meta、lookup-method、replace-method》](http://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-for-meta-and-look-method-and-replace-method) 中，已经详细分析了这两个标签的用法和解析过程，知道解析过程其实就是讲这两个配置存放在 BeanDefinition 中的 `methodOverrides` 属性中。
+
+我们知道在 bean 实例化的过程中如果检测到存在 `methodOverrides` ，则会动态地位为当前 bean 生成代理并使用对应的拦截器为 bean 做**增强处理**。具体的实现我们后续分析，现在先看 `mbdToUse.prepareMethodOverrides()` 代码块，都干了些什么事，代码如下：
+
+```
+// AbstractBeanDefinition.java
+
+public void prepareMethodOverrides() throws BeanDefinitionValidationException {
+    // Check that lookup methods exists.
+    if (hasMethodOverrides()) {
+        Set<MethodOverride> overrides = getMethodOverrides().getOverrides();
+        synchronized (overrides) { // 同步
+            // 循环，执行 prepareMethodOverride
+            for (MethodOverride mo : overrides) {
+                prepareMethodOverride(mo);
+            }
+        }
+    }
+}
+```
+
+- 如果存在 `methodOverrides` ，则获取所有的 override method ，然后通过迭代的方法一次调用 `#prepareMethodOverride(MethodOverride mo)` 方法。代码如下：
+
+  ```
+  // AbstractBeanDefinition.java
+  
+  protected void prepareMethodOverride(MethodOverride mo) throws BeanDefinitionValidationException {
+  	int count = ClassUtils.getMethodCountForName(getBeanClass(), mo.getMethodName());
+  	if (count == 0) {
+  		throw new BeanDefinitionValidationException(
+  				"Invalid method override: no method with name '" + mo.getMethodName() +
+  				"' on class [" + getBeanClassName() + "]");
+  	} else if (count == 1) {
+  		// Mark override as not overloaded, to avoid the overhead of arg type checking.
+  		mo.setOverloaded(false);
+  	}
+  }
+  ```
+
+  - 根据方法名称，从 class 中获取该方法名的个数：
+    - 如果个数为 0 ，则抛出 BeanDefinitionValidationException 异常。
+    - 如果个数为 1 ，则设置该重载方法**没有被重载**。
+  - 若一个类中存在**多个**重载方法，则在方法调用的时候还需要根据参数类型来判断到底重载的是哪个方法。在设置重载的时候其实这里做了一个**小小优化**，那就是当 `count == 1` 时，设置 `overloaded = false` ，这样表示该方法没有重载。这样，在后续调用的时候，便可以直接找到方法而不需要进行方法参数的校验。
+
+诚然，其实 `mbdToUse.prepareMethodOverrides()` 代码块，并没有做什么实质性的工作，只是对 `methodOverrides` 属性做了一些简单的校验而已。
+
+## 2.3 实例化的前置处理
+
+`#resolveBeforeInstantiation(String beanName, RootBeanDefinition mbd)` 方法的作用，是给 BeanPostProcessors 后置处理器返回一个**代理对象**的机会。其，实在调用该方法之前 Spring 一直都没有创建 bean ，那么这里返回一个 bean 的代理类有什么作用呢？作用体现在后面的 `if` 判断，代码如下：
+
+```
+// AbstractBeanDefinition.java
+
+Object bean = resolveBeforeInstantiation(beanName, mbdToUse);
+// ↓↓↓ 
+if (bean != null) {
+	return bean;
+}
+```
+
+- 如果代理对象不为空，则直接返回代理对象，这一步骤有非常重要的作用，Spring 后续实现 AOP 就是基于这个地方判断的。
+
+- `#resolveBeforeInstantiation(String beanName, RootBeanDefinition mbd)` 方法，代码如下：
+
+  ```
+  // AbstractAutowireCapableBeanFactory.java
+  
+  @Nullable
+  protected Object resolveBeforeInstantiation(String beanName, RootBeanDefinition mbd) {
+      Object bean = null;
+      if (!Boolean.FALSE.equals(mbd.beforeInstantiationResolved)) {
+          // Make sure bean class is actually resolved at this point.
+          if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
+              Class<?> targetType = determineTargetType(beanName, mbd);
+              if (targetType != null) {
+                  // 前置
+                  bean = applyBeanPostProcessorsBeforeInstantiation(targetType, beanName);
+                  if (bean != null) {
+                      // 后置
+                      bean = applyBeanPostProcessorsAfterInitialization(bean, beanName);
+                  }
+              }
+          }
+          mbd.beforeInstantiationResolved = (bean != null);
+      }
+      return bean;
+  }
+  ```
+
+  - 这个方法核心就在于 `applyBeanPostProcessorsBeforeInstantiation()` 和 `applyBeanPostProcessorsAfterInitialization()` 两个方法，before 为实例化前的后处理器应用，after 为实例化后的后处理器应用。
+  - 由于本文的主题是创建 bean ，关于 Bean 的增强处理后续 LZ 会单独出博文来做详细说明。
+
+详细解析，见 TODO
+
+## 2.4 创建 Bean
+
+如果没有代理对象，就只能走常规的路线进行 bean 的创建了，该过程有 `#doCreateBean(final String beanName, final RootBeanDefinition mbd, final @Nullable Object[] args)` 方法来实现。代码如下：
+
+```
+// AbstractAutowireCapableBeanFactory.java
+
+protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final @Nullable Object[] args)
+        throws BeanCreationException {
+
+    // Instantiate the bean.
+    // BeanWrapper 是对 Bean 的包装，其接口中所定义的功能很简单包括设置获取被包装的对象，获取被包装 bean 的属性描述器
+    BeanWrapper instanceWrapper = null;
+    // <1> 单例模型，则从未完成的 FactoryBean 缓存中删除
+    if (mbd.isSingleton()) {
+        instanceWrapper = this.factoryBeanInstanceCache.remove(beanName);
+    }
+    // <2> 使用合适的实例化策略来创建新的实例：工厂方法、构造函数自动注入、简单初始化
+    if (instanceWrapper == null) {
+        instanceWrapper = createBeanInstance(beanName, mbd, args);
+    }
+    // 包装的实例对象
+    final Object bean = instanceWrapper.getWrappedInstance();
+    // 包装的实例对象的类型
+    Class<?> beanType = instanceWrapper.getWrappedClass();
+    if (beanType != NullBean.class) {
+        mbd.resolvedTargetType = beanType;
+    }
+
+    // Allow post-processors to modify the merged bean definition.
+    // <3> 判断是否有后置处理
+    // 如果有后置处理，则允许后置处理修改 BeanDefinition
+    synchronized (mbd.postProcessingLock) {
+        if (!mbd.postProcessed) {
+            try {
+                // 后置处理修改 BeanDefinition
+                applyMergedBeanDefinitionPostProcessors(mbd, beanType, beanName);
+            } catch (Throwable ex) {
+                throw new BeanCreationException(mbd.getResourceDescription(), beanName,
+                        "Post-processing of merged bean definition failed", ex);
+            }
+            mbd.postProcessed = true;
+        }
+    }
+
+    // Eagerly cache singletons to be able to resolve circular references
+    // even when triggered by lifecycle interfaces like BeanFactoryAware.
+    // <4> 解决单例模式的循环依赖
+    boolean earlySingletonExposure = (mbd.isSingleton() // 单例模式
+            && this.allowCircularReferences // 运行循环依赖
+            && isSingletonCurrentlyInCreation(beanName)); // 当前单例 bean 是否正在被创建
+    if (earlySingletonExposure) {
+        if (logger.isTraceEnabled()) {
+            logger.trace("Eagerly caching bean '" + beanName +
+                    "' to allow for resolving potential circular references");
+        }
+        // 提前将创建的 bean 实例加入到 singletonFactories 中
+        // 这里是为了后期避免循环依赖
+        addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
+    }
+
+    // Initialize the bean instance.
+    // 开始初始化 bean 实例对象
+    Object exposedObject = bean;
+    try {
+        // <5> 对 bean 进行填充，将各个属性值注入，其中，可能存在依赖于其他 bean 的属性
+        // 则会递归初始依赖 bean
+        populateBean(beanName, mbd, instanceWrapper);
+        // <6> 调用初始化方法
+        exposedObject = initializeBean(beanName, exposedObject, mbd);
+    } catch (Throwable ex) {
+        if (ex instanceof BeanCreationException && beanName.equals(((BeanCreationException) ex).getBeanName())) {
+            throw (BeanCreationException) ex;
+        } else {
+            throw new BeanCreationException(
+                    mbd.getResourceDescription(), beanName, "Initialization of bean failed", ex);
+        }
+    }
+
+    // <7> 循环依赖处理
+    if (earlySingletonExposure) {
+        // 获取 earlySingletonReference
+        Object earlySingletonReference = getSingleton(beanName, false);
+        // 只有在存在循环依赖的情况下，earlySingletonReference 才不会为空
+        if (earlySingletonReference != null) {
+            // 如果 exposedObject 没有在初始化方法中被改变，也就是没有被增强
+            if (exposedObject == bean) {
+                exposedObject = earlySingletonReference;
+            // 处理依赖
+            } else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
+                String[] dependentBeans = getDependentBeans(beanName);
+                Set<String> actualDependentBeans = new LinkedHashSet<>(dependentBeans.length);
+                for (String dependentBean : dependentBeans) {
+                    if (!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 " +
+                            "'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.");
+                }
+            }
+        }
+    }
+
+    // Register bean as disposable.
+    // <8> 注册 bean
+    try {
+        registerDisposableBeanIfNecessary(beanName, bean, mbd);
+    } catch (BeanDefinitionValidationException ex) {
+        throw new BeanCreationException(
+                mbd.getResourceDescription(), beanName, "Invalid destruction signature", ex);
+    }
+
+    return exposedObject;
+}
+```
+
+整体的思路：
+
+- ```
+  <1>
+  ```
+
+   
+
+  处，如果是单例模式，则清除缓存。
+
+  - 详细解析，见 TODO
+
+- ```
+  <2>
+  ```
+
+   
+
+  处，调用
+
+   
+
+  ```
+  #createBeanInstance(String beanName, RootBeanDefinition mbd, Object[] args)
+  ```
+
+   
+
+  方法，实例化 bean ，主要是将 BeanDefinition 转换为
+
+   
+
+  ```
+  org.springframework.beans.BeanWrapper
+  ```
+
+   
+
+  对象。
+
+  - 详细解析，见 [《【死磕 Spring】—— IoC 之加载 Bean：创建 Bean（二）》](http://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-2) 和 [《【死磕 Spring】—— IoC 之加载 Bean：创建 Bean（三）》](http://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-3) 中。
+
+- ```
+  <3>
+  ```
+
+   
+
+  处，MergedBeanDefinitionPostProcessor 的应用。
+
+  - 详细解析，见 TODO
+
+- ```
+  <4>
+  ```
+
+   
+
+  处，单例模式的循环依赖处理。
+
+  - 详细解析，见 [《【死磕 Spring】—— IoC 之加载 Bean：创建 Bean（五）之循环依赖处理》](http://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-5) 。
+
+- ```
+  <5>
+  ```
+
+   
+
+  处，调用
+
+   
+
+  ```
+  #populateBean(String beanName, RootBeanDefinition mbd, BeanWrapper bw)
+  ```
+
+   
+
+  方法，进行属性填充。将所有属性填充至 bean 的实例中。
+
+  - 详细解析，见 [《【死磕 Spring】—— IoC 之加载 bean：创建 Bean（四）之属性填充》](http://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-4) 。
+
+- ```
+  <6>
+  ```
+
+   
+
+  处，调用
+
+   
+
+  ```
+  #initializeBean(final String beanName, final Object bean, RootBeanDefinition mbd)
+  ```
+
+   
+
+  方法，初始化 bean 。
+
+  - 详细解析，见 [《死磕 Spring】—— IoC 之加载 Bean：创建 Bean（六）之初始化 Bean 对象》](http://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-6) 。
+
+- ```
+  <7>
+  ```
+
+   
+
+  处，依赖检查。
+
+  - 详细解析，见 TODO
+
+- ```
+  <8>
+  ```
+
+   
+
+  处，注册 DisposableBean 。
+
+  - 详细解析，见 TODO
+
+# 3. 小结
+
+`#doCreateBean(...)` 方法，完成 bean 的创建和初始化工作，内容太多，这里就只列出整体思路。**下文开始**，将该方法进行拆分进行详细讲解，分布从以下几个方面进行阐述：
+
+- `#createBeanInstance(String beanName, RootBeanDefinition mbd, Object[] args)` 方法，实例化 bean 。
+- 循环依赖的处理。
+- `#populateBean(String beanName, RootBeanDefinition mbd, BeanWrapper bw)` 方法，进行属性填充。
+- `#initializeBean(final String beanName, final Object bean, RootBeanDefinition mbd)` 方法，初始化 Bean 。
\ No newline at end of file
diff --git a/spring/25-Spring-IoC 之加载 Bean：创建 Bean（二）之实例化 Bean 对象(1).md b/spring/25-Spring-IoC 之加载 Bean：创建 Bean（二）之实例化 Bean 对象(1).md
new file mode 100644
index 0000000..d4cb188
--- /dev/null
+++ b/spring/25-Spring-IoC 之加载 Bean：创建 Bean（二）之实例化 Bean 对象(1).md	
@@ -0,0 +1,929 @@
+# 【死磕 Spring】—— IoC 之加载 Bean：创建 Bean（二）之实例化 Bean 对象(1)
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=todo 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+# 1. createBeanInstance
+
+这篇我们关注创建 bean 过程中的**第一个**步骤：实例化 bean，对应的方法为 `#createBeanInstance(String beanName, RootBeanDefinition mbd, Object[] args)` 。代码如下：
+
+```
+// AbstractAutowireCapableBeanFactory.java
+
+protected BeanWrapper createBeanInstance(String beanName, RootBeanDefinition mbd, @Nullable Object[] args) {
+    // Make sure bean class is actually resolved at this point.
+    // 解析 bean ，将 bean 类名解析为 class 引用。
+    Class<?> beanClass = resolveBeanClass(mbd, beanName);
+
+    if (beanClass != null && !Modifier.isPublic(beanClass.getModifiers()) && !mbd.isNonPublicAccessAllowed()) { // 校验
+        throw new BeanCreationException(mbd.getResourceDescription(), beanName,
+                "Bean class isn't public, and non-public access not allowed: " + beanClass.getName());
+    }
+
+    // <1> 如果存在 Supplier 回调，则使用给定的回调方法初始化策略
+    Supplier<?> instanceSupplier = mbd.getInstanceSupplier();
+    if (instanceSupplier != null) {
+        return obtainFromSupplier(instanceSupplier, beanName);
+    }
+
+    // <2> 使用 FactoryBean 的 factory-method 来创建，支持静态工厂和实例工厂
+    if (mbd.getFactoryMethodName() != null)  {
+        return instantiateUsingFactoryMethod(beanName, mbd, args);
+    }
+
+    // <3> Shortcut when re-creating the same bean...
+    boolean resolved = false;
+    boolean autowireNecessary = false;
+    if (args == null) {
+        // constructorArgumentLock 构造函数的常用锁
+        synchronized (mbd.constructorArgumentLock) {
+            // 如果已缓存的解析的构造函数或者工厂方法不为空，则可以利用构造函数解析
+            // 因为需要根据参数确认到底使用哪个构造函数，该过程比较消耗性能，所有采用缓存机制
+            if (mbd.resolvedConstructorOrFactoryMethod != null) {
+                resolved = true;
+                autowireNecessary = mbd.constructorArgumentsResolved;
+            }
+        }
+    }
+    // 已经解析好了，直接注入即可
+    if (resolved) {
+        // <3.1> autowire 自动注入，调用构造函数自动注入
+        if (autowireNecessary) {
+            return autowireConstructor(beanName, mbd, null, null);
+        } else {
+            // <3.2> 使用默认构造函数构造
+            return instantiateBean(beanName, mbd);
+        }
+    }
+
+    // Candidate constructors for autowiring?
+    // <4> 确定解析的构造函数
+    // 主要是检查已经注册的 SmartInstantiationAwareBeanPostProcessor
+    Constructor<?>[] ctors = determineConstructorsFromBeanPostProcessors(beanClass, beanName);
+    // <4.1> 有参数情况时，创建 Bean 。先利用参数个数，类型等，确定最精确匹配的构造方法。
+    if (ctors != null || mbd.getResolvedAutowireMode() == AUTOWIRE_CONSTRUCTOR ||
+            mbd.hasConstructorArgumentValues() || !ObjectUtils.isEmpty(args))  {
+        return autowireConstructor(beanName, mbd, ctors, args);
+    }
+
+    // Preferred constructors for default construction?
+    // <4.1> 选择构造方法，创建 Bean 。
+    ctors = mbd.getPreferredConstructors();
+    if (ctors != null) {
+        return autowireConstructor(beanName, mbd, ctors, null); // args = null
+    }
+
+    // No special handling: simply use no-arg constructor.
+    // <4.2> 有参数时，又没获取到构造方法，则只能调用无参构造方法来创建实例了(兜底方法)
+    return instantiateBean(beanName, mbd);
+}
+```
+
+实例化 Bean 对象，是一个**复杂**的过程，其主要的逻辑为：
+
+- ```
+  <1>
+  ```
+
+   
+
+  处，如果存在 Supplier 回调，则调用
+
+   
+
+  ```
+  #obtainFromSupplier(Supplier<?> instanceSupplier, String beanName)
+  ```
+
+   
+
+  方法，进行初始化。
+
+  - 详细解析，见 [「1.1 obtainFromSupplier」](https://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-2/#) 。
+
+- ```
+  <2>
+  ```
+
+   
+
+  处，如果存在工厂方法，则使用工厂方法进行初始化。
+
+  - 详细解析，见 [「1.2 instantiateUsingFactoryMethod」](https://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-2/#) 。
+
+- ```
+  <3>
+  ```
+
+   
+
+  处，首先判断缓存，如果
+
+  缓存中存在
+
+  ，即已经解析过了，则直接使用已经解析了的。根据
+
+   
+
+  ```
+  constructorArgumentsResolved
+  ```
+
+   
+
+  参数来判断：
+
+  - ```
+    <3.1>
+    ```
+
+     
+
+    处，是使用构造函数自动注入，即调用
+
+     
+
+    ```
+    #autowireConstructor(String beanName, RootBeanDefinition mbd, Constructor<?>[] ctors, Object[] explicitArgs)
+    ```
+
+     
+
+    方法。
+
+    - 详细解析，[《【死磕 Spring】—— IoC 之加载 Bean：创建 Bean（三）之实例化 Bean 对象(2)》](http://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-3) 。
+
+  - ```
+    <3.2>
+    ```
+
+     
+
+    处，还是默认构造函数，即调用
+
+     
+
+    ```
+    #instantiateBean(final String beanName, final RootBeanDefinition mbd)
+    ```
+
+     
+
+    方法。
+
+    - 详细解析，[《【死磕 Spring】—— IoC 之加载 Bean：创建 Bean（三）之实例化 Bean 对象(2)》](http://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-3) 。
+
+- ```
+  <4>
+  ```
+
+   
+
+  处，如果
+
+  缓存中没有
+
+  ，则需要先确定到底使用哪个构造函数来完成解析工作，因为一个类有多个构造函数，每个构造函数都有不同的构造参数，所以需要根据参数来锁定构造函数并完成初始化。
+
+  - ```
+    <4.1>
+    ```
+
+     
+
+    处，如果存在参数，则使用相应的带有参数的构造函数，即调用
+
+     
+
+    ```
+    #autowireConstructor(String beanName, RootBeanDefinition mbd, Constructor<?>[] ctors, Object[] explicitArgs)
+    ```
+
+     
+
+    方法。
+
+    - 详细解析，[《【死磕 Spring】—— IoC 之加载 Bean：创建 Bean（三）之实例化 Bean 对象(2)》](http://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-3) 。
+
+  - ```
+    <4.2>
+    ```
+
+     
+
+    处，否则，使用默认构造函数，即调用
+
+     
+
+    ```
+    #instantiateBean(final String beanName, final RootBeanDefinition mbd)
+    ```
+
+     
+
+    方法。
+
+    - 详细解析，[《【死磕 Spring】—— IoC 之加载 Bean：创建 Bean（三）之实例化 Bean 对象(2)》](http://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-3) 。
+
+😈 下面就上面四种情况做分别说明。
+
+## 1.1 obtainFromSupplier
+
+调用对应代码块如下：
+
+```
+// AbstractAutowireCapableBeanFactory.java
+// protected BeanWrapper createBeanInstance(String beanName, RootBeanDefinition mbd, @Nullable Object[] args) {}
+
+Supplier<?> instanceSupplier = mbd.getInstanceSupplier();
+if (instanceSupplier != null) {
+    return obtainFromSupplier(instanceSupplier, beanName);
+}
+```
+
+- 首先,从 BeanDefinition 中获取 Supplier 对象。如果不为空，则调用 `#obtainFromSupplier(final String beanName, final RootBeanDefinition mbd)` 方法。
+
+### 1.1.1 Supplier
+
+那么 Supplier 是什么呢？在这之前也没有提到过这个字段。`java.util.function.Supplier` 接口，代码如下：
+
+```
+public interface Supplier<T> {
+
+    T get();
+    
+}
+```
+
+- Supplier 接口仅有一个功能性的 `#get()` 方法，该方法会返回一个 `<T>` 类型的对象，有点儿类似工厂方法。
+- 这个接口有什么作用？用于指定创建 bean 的回调。如果我们设置了这样的回调，那么其他的构造器或者工厂方法都会没有用。
+
+在什么设置该 Supplier 参数呢？Spring 提供了相应的 setter 方法，如下：
+
+```
+// AbstractBeanDefinition.java
+
+/**
+ * 创建 Bean 的 Supplier 对象
+ */
+@Nullable
+private Supplier<?> instanceSupplier;
+
+public void setInstanceSupplier(@Nullable Supplier<?> instanceSupplier) {
+	this.instanceSupplier = instanceSupplier;
+}
+```
+
+- 在构造 BeanDefinition 对象的时候，设置了 `instanceSupplier` 该值，代码如下（以 RootBeanDefinition 为例）：
+
+  ```
+  // RootBeanDefinition.java
+  
+  public <T> RootBeanDefinition(@Nullable Class<T> beanClass, String scope, @Nullable Supplier<T> instanceSupplier) {
+  	super();
+  	setBeanClass(beanClass);
+  	setScope(scope);
+  	// 设置 instanceSupplier 属性
+  	setInstanceSupplier(instanceSupplier);
+  }
+  ```
+
+### 1.1.2 obtainFromSupplier
+
+如果设置了 `instanceSupplier` 属性，则可以调用 `#obtainFromSupplier(Supplier<?> instanceSupplier, String beanName)` 方法，完成 Bean 的初始化。代码如下：
+
+```
+// AbstractAutowireCapableBeanFactory.java
+
+/**
+ * 当前线程，正在创建的 Bean 对象的名字
+ *
+ * The name of the currently created bean, for implicit dependency registration
+ * on getBean etc invocations triggered from a user-specified Supplier callback.
+ */
+private final NamedThreadLocal<String> currentlyCreatedBean = new NamedThreadLocal<>("Currently created bean");
+
+protected BeanWrapper obtainFromSupplier(Supplier<?> instanceSupplier, String beanName) {
+    Object instance;
+    // 获得原创建的 Bean 的对象名
+    String outerBean = this.currentlyCreatedBean.get();
+    // 设置新的 Bean 的对象名，到 currentlyCreatedBean 中
+    this.currentlyCreatedBean.set(beanName);
+    try {
+        // <1> 调用 Supplier 的 get()，返回一个 Bean 对象
+        instance = instanceSupplier.get();
+    } finally {
+        // 设置原创建的 Bean 的对象名，到 currentlyCreatedBean 中
+        if (outerBean != null) {
+            this.currentlyCreatedBean.set(outerBean);
+        } else {
+            this.currentlyCreatedBean.remove();
+        }
+    }
+
+    // 未创建 Bean 对象，则创建 NullBean 对象
+    if (instance == null) {
+        instance = new NullBean();
+    }
+    // <2> 创建 BeanWrapper 对象
+    BeanWrapper bw = new BeanWrapperImpl(instance);
+    // <3> 初始化 BeanWrapper 对象
+    initBeanWrapper(bw);
+    return bw;
+}
+```
+
+代码很简单，流程如下：
+
+- `<1>` 首先，调用 Supplier 的 `get()` 方法，获得一个 Bean 实例对象。
+- `<2>` 然后，根据该实例对象构造一个 BeanWrapper 对象 `bw` 。
+- `<3>` 最后，初始化该对象。
+
+有关于 BeanWrapper ，后面专门出文讲解。
+
+## 1.2 instantiateUsingFactoryMethod()
+
+如果存在工厂方法，则调用 `#instantiateUsingFactoryMethod(String beanName, RootBeanDefinition mbd, @Nullable Object[] explicitArgs)` 方法完成 bean 的初始化工作（方法实现比较长，细节比较复杂，**各位就硬着头皮看吧**）。代码如下：
+
+```
+// AbstractAutowireCapableBeanFactory.java
+
+protected BeanWrapper instantiateUsingFactoryMethod(String beanName, RootBeanDefinition mbd, @Nullable Object[] explicitArgs) {
+	return new ConstructorResolver(this).instantiateUsingFactoryMethod(beanName, mbd, explicitArgs);
+}
+```
+
+- 构造一个 ConstructorResolver 对象，然后调用其 `#instantiateUsingFactoryMethod(EvaluationContext context, String typeName, List<TypeDescriptor> argumentTypes)` 方法。
+
+### 1.2.1 ConstructorResolver
+
+`org.springframework.expression.ConstructorResolver` 是构造方法或者工厂类初始化 bean 的委托类。代码如下：
+
+```
+// ConstructorResolver.java
+
+public BeanWrapper instantiateUsingFactoryMethod(
+        String beanName, RootBeanDefinition mbd, @Nullable Object[] explicitArgs) {
+    // 构造 BeanWrapperImpl 对象
+    BeanWrapperImpl bw = new BeanWrapperImpl();
+    // 初始化 BeanWrapperImpl
+    // 向BeanWrapper对象中添加 ConversionService 对象和属性编辑器 PropertyEditor 对象
+    this.beanFactory.initBeanWrapper(bw);
+
+    // <1> 获得 factoryBean、factoryClass、isStatic、factoryBeanName 属性
+    Object factoryBean;
+    Class<?> factoryClass;
+    boolean isStatic;
+    String factoryBeanName = mbd.getFactoryBeanName();
+
+    // 工厂名不为空
+    if (factoryBeanName != null) {
+        if (factoryBeanName.equals(beanName)) { // 抛出 BeanDefinitionStoreException 异常
+            throw new BeanDefinitionStoreException(mbd.getResourceDescription(), beanName,
+                    "factory-bean reference points back to the same bean definition");
+        }
+        // 获取工厂实例
+        factoryBean = this.beanFactory.getBean(factoryBeanName);
+        if (mbd.isSingleton() && this.beanFactory.containsSingleton(beanName)) { // 抛出 ImplicitlyAppearedSingletonException 异常
+            throw new ImplicitlyAppearedSingletonException();
+        }
+        factoryClass = factoryBean.getClass();
+        isStatic = false;
+    } else {
+        // 工厂名为空，则其可能是一个静态工厂
+        // 静态工厂创建bean，必须要提供工厂的全类名
+        // It's a static factory method on the bean class.
+        if (!mbd.hasBeanClass()) {
+            throw new BeanDefinitionStoreException(mbd.getResourceDescription(), beanName,
+                    "bean definition declares neither a bean class nor a factory-bean reference");
+        }
+        factoryBean = null;
+        factoryClass = mbd.getBeanClass();
+        isStatic = true;
+    }
+
+    // <2> 获得 factoryMethodToUse、argsHolderToUse、argsToUse 属性
+    Method factoryMethodToUse = null;  // 工厂方法
+    ArgumentsHolder argsHolderToUse = null;
+    Object[] argsToUse = null; // 参数
+
+    // <2.1> 如果指定了构造参数则直接使用
+    // 在调用 getBean 方法的时候指定了方法参数
+    if (explicitArgs != null) {
+        argsToUse = explicitArgs;
+    } else {
+        // 没有指定，则尝试从配置文件中解析
+        Object[] argsToResolve = null;
+        // <2.2> 首先尝试从缓存中获取
+        synchronized (mbd.constructorArgumentLock) {
+            // 获取缓存中的构造函数或者工厂方法
+            factoryMethodToUse = (Method) mbd.resolvedConstructorOrFactoryMethod;
+            if (factoryMethodToUse != null && mbd.constructorArgumentsResolved) {
+                // Found a cached factory method...
+                // 获取缓存中的构造参数
+                argsToUse = mbd.resolvedConstructorArguments;
+                if (argsToUse == null) {
+                    // 获取缓存中的构造函数参数的包可见字段
+                    argsToResolve = mbd.preparedConstructorArguments;
+                }
+            }
+        }
+        // 缓存中存在,则解析存储在 BeanDefinition 中的参数
+        // 如给定方法的构造函数 A(int ,int )，则通过此方法后就会把配置文件中的("1","1")转换为 (1,1)
+        // 缓存中的值可能是原始值也有可能是最终值
+        if (argsToResolve != null) {
+            argsToUse = resolvePreparedArguments(beanName, mbd, bw, factoryMethodToUse, argsToResolve, true);
+        }
+    }
+
+    // <3> 
+    if (factoryMethodToUse == null || argsToUse == null) {
+        // Need to determine the factory method...
+        // Try all methods with this name to see if they match the given arguments.
+        // 获取工厂方法的类全名称
+        factoryClass = ClassUtils.getUserClass(factoryClass);
+
+        // 获取所有待定方法
+        Method[] rawCandidates = getCandidateMethods(factoryClass, mbd);
+        // 检索所有方法，这里是对方法进行过滤
+        List<Method> candidateList = new ArrayList<>();
+        for (Method candidate : rawCandidates) {
+            // 如果有static 且为工厂方法，则添加到 candidateSet 中
+            if (Modifier.isStatic(candidate.getModifiers()) == isStatic && mbd.isFactoryMethod(candidate)) {
+                candidateList.add(candidate);
+            }
+        }
+
+        // TODO 芋艿 创建 Bean
+        if (candidateList.size() == 1 && explicitArgs == null && !mbd.hasConstructorArgumentValues()) {
+            Method uniqueCandidate = candidateList.get(0);
+            if (uniqueCandidate.getParameterCount() == 0) {
+                synchronized (mbd.constructorArgumentLock) {
+                    mbd.resolvedConstructorOrFactoryMethod = uniqueCandidate;
+                    mbd.constructorArgumentsResolved = true;
+                    mbd.resolvedConstructorArguments = EMPTY_ARGS;
+                }
+                bw.setBeanInstance(instantiate(beanName, mbd, factoryBean, uniqueCandidate, EMPTY_ARGS));
+                return bw;
+            }
+        }
+
+        Method[] candidates = candidateList.toArray(new Method[0]);
+        // 排序构造函数
+        // public 构造函数优先参数数量降序，非 public 构造函数参数数量降序
+        AutowireUtils.sortFactoryMethods(candidates);
+
+        // 用于承载解析后的构造函数参数的值
+        ConstructorArgumentValues resolvedValues = null;
+        boolean autowiring = (mbd.getResolvedAutowireMode() == AutowireCapableBeanFactory.AUTOWIRE_CONSTRUCTOR);
+        int minTypeDiffWeight = Integer.MAX_VALUE;
+        Set<Method> ambiguousFactoryMethods = null;
+
+        int minNrOfArgs;
+        if (explicitArgs != null) {
+            minNrOfArgs = explicitArgs.length;
+        } else {
+            // We don't have arguments passed in programmatically, so we need to resolve the
+            // arguments specified in the constructor arguments held in the bean definition.
+            // <2.3> getBean() 没有传递参数，则需要解析保存在 BeanDefinition 构造函数中指定的参数
+            if (mbd.hasConstructorArgumentValues()) {
+                // 构造函数的参数
+                ConstructorArgumentValues cargs = mbd.getConstructorArgumentValues();
+                resolvedValues = new ConstructorArgumentValues();
+                // 解析构造函数的参数
+                // 将该 bean 的构造函数参数解析为 resolvedValues 对象，其中会涉及到其他 bean
+                minNrOfArgs = resolveConstructorArguments(beanName, mbd, bw, cargs, resolvedValues);
+            } else {
+                minNrOfArgs = 0;
+            }
+        }
+
+        LinkedList<UnsatisfiedDependencyException> causes = null; // 记录 UnsatisfiedDependencyException 异常的集合
+        // 遍历 candidates 数组
+        for (Method candidate : candidates) {
+            // 方法体的参数
+            Class<?>[] paramTypes = candidate.getParameterTypes();
+
+            if (paramTypes.length >= minNrOfArgs) {
+                // 保存参数的对象
+                ArgumentsHolder argsHolder;
+
+                // #getBean(...) 传递了参数
+                if (explicitArgs != null) {
+                    // Explicit arguments given -> arguments length must match exactly.
+                    // 显示给定参数，参数长度必须完全匹配
+                    if (paramTypes.length != explicitArgs.length) {
+                        continue;
+                    }
+                    // 根据参数创建参数持有者 ArgumentsHolder 对象
+                    argsHolder = new ArgumentsHolder(explicitArgs);
+                } else {
+                    // Resolved constructor arguments: type conversion and/or autowiring necessary.
+                    // 为提供参数，解析构造参数
+                    try {
+                        String[] paramNames = null;
+                        // 获取 ParameterNameDiscoverer 对象
+                        // ParameterNameDiscoverer 是用于解析方法和构造函数的参数名称的接口，为参数名称探测器
+                        ParameterNameDiscoverer pnd = this.beanFactory.getParameterNameDiscoverer();
+                        // 获取指定构造函数的参数名称
+                        if (pnd != null) {
+                            paramNames = pnd.getParameterNames(candidate);
+                        }
+                        // 在已经解析的构造函数参数值的情况下，创建一个参数持有者 ArgumentsHolder 对象
+                        argsHolder = createArgumentArray(beanName, mbd, resolvedValues, bw,
+                                paramTypes, paramNames, candidate, autowiring, candidates.length == 1);
+                    } catch (UnsatisfiedDependencyException ex) {
+                        // 若发生 UnsatisfiedDependencyException 异常，添加到 causes 中。
+                        if (logger.isTraceEnabled()) {
+                            logger.trace("Ignoring factory method [" + candidate + "] of bean '" + beanName + "': " + ex);
+                        }
+                        // Swallow and try next overloaded factory method.
+                        if (causes == null) {
+                            causes = new LinkedList<>();
+                        }
+                        causes.add(ex);
+                        continue; // continue ，继续执行
+                    }
+                }
+
+                // isLenientConstructorResolution 判断解析构造函数的时候是否以宽松模式还是严格模式
+                // 严格模式：解析构造函数时，必须所有的都需要匹配，否则抛出异常
+                // 宽松模式：使用具有"最接近的模式"进行匹配
+                // typeDiffWeight：类型差异权重
+                int typeDiffWeight = (mbd.isLenientConstructorResolution() ?
+                        argsHolder.getTypeDifferenceWeight(paramTypes) : argsHolder.getAssignabilityWeight(paramTypes));
+                // Choose this factory method if it represents the closest match.
+                // 代表最接近的类型匹配，则选择作为构造函数
+                if (typeDiffWeight < minTypeDiffWeight) {
+                    factoryMethodToUse = candidate;
+                    argsHolderToUse = argsHolder;
+                    argsToUse = argsHolder.arguments;
+                    minTypeDiffWeight = typeDiffWeight;
+                    ambiguousFactoryMethods = null;
+                }
+                // Find out about ambiguity: In case of the same type difference weight
+                // for methods with the same number of parameters, collect such candidates
+                // and eventually raise an ambiguity exception.
+                // However, only perform that check in non-lenient constructor resolution mode,
+                // and explicitly ignore overridden methods (with the same parameter signature).
+                // 如果具有相同参数数量的方法具有相同的类型差异权重，则收集此类型选项
+                // 但是，仅在非宽松构造函数解析模式下执行该检查，并显式忽略重写方法（具有相同的参数签名）
+                else if (factoryMethodToUse != null && typeDiffWeight == minTypeDiffWeight &&
+                        !mbd.isLenientConstructorResolution() &&
+                        paramTypes.length == factoryMethodToUse.getParameterCount() &&
+                        !Arrays.equals(paramTypes, factoryMethodToUse.getParameterTypes())) {
+                    // 查找到多个可匹配的方法
+                    if (ambiguousFactoryMethods == null) {
+                        ambiguousFactoryMethods = new LinkedHashSet<>();
+                        ambiguousFactoryMethods.add(factoryMethodToUse);
+                    }
+                    ambiguousFactoryMethods.add(candidate);
+                }
+            }
+        }
+
+        // 没有可执行的工厂方法，抛出异常
+        if (factoryMethodToUse == null) {
+            if (causes != null) {
+                UnsatisfiedDependencyException ex = causes.removeLast();
+                for (Exception cause : causes) {
+                    this.beanFactory.onSuppressedException(cause);
+                }
+                throw ex;
+            }
+            List<String> argTypes = new ArrayList<>(minNrOfArgs);
+            if (explicitArgs != null) {
+                for (Object arg : explicitArgs) {
+                    argTypes.add(arg != null ? arg.getClass().getSimpleName() : "null");
+                }
+            } else if (resolvedValues != null) {
+                Set<ValueHolder> valueHolders = new LinkedHashSet<>(resolvedValues.getArgumentCount());
+                valueHolders.addAll(resolvedValues.getIndexedArgumentValues().values());
+                valueHolders.addAll(resolvedValues.getGenericArgumentValues());
+                for (ValueHolder value : valueHolders) {
+                    String argType = (value.getType() != null ? ClassUtils.getShortName(value.getType()) :
+                            (value.getValue() != null ? value.getValue().getClass().getSimpleName() : "null"));
+                    argTypes.add(argType);
+                }
+            }
+            String argDesc = StringUtils.collectionToCommaDelimitedString(argTypes);
+            throw new BeanCreationException(mbd.getResourceDescription(), beanName,
+                    "No matching factory method found: " +
+                    (mbd.getFactoryBeanName() != null ?
+                        "factory bean '" + mbd.getFactoryBeanName() + "'; " : "") +
+                    "factory method '" + mbd.getFactoryMethodName() + "(" + argDesc + ")'. " +
+                    "Check that a method with the specified name " +
+                    (minNrOfArgs > 0 ? "and arguments " : "") +
+                    "exists and that it is " +
+                    (isStatic ? "static" : "non-static") + ".");
+        } else if (void.class == factoryMethodToUse.getReturnType()) {
+            throw new BeanCreationException(mbd.getResourceDescription(), beanName,
+                    "Invalid factory method '" + mbd.getFactoryMethodName() +
+                    "': needs to have a non-void return type!");
+        } else if (ambiguousFactoryMethods != null) {
+            throw new BeanCreationException(mbd.getResourceDescription(), beanName,
+                    "Ambiguous factory method matches found in bean '" + beanName + "' " +
+                    "(hint: specify index/type/name arguments for simple parameters to avoid type ambiguities): " +
+                    ambiguousFactoryMethods);
+        }
+
+        if (explicitArgs == null && argsHolderToUse != null) {
+            // 将解析的构造函数加入缓存
+            argsHolderToUse.storeCache(mbd, factoryMethodToUse);
+        }
+    }
+
+    // 创建 Bean 对象，并设置到 bw 中
+    bw.setBeanInstance(instantiate(beanName, mbd, factoryBean, factoryMethodToUse, argsToUse));
+    return bw;
+}
+
+private Object instantiate(
+        String beanName, RootBeanDefinition mbd, Constructor constructorToUse, Object[] argsToUse) {
+
+    try {
+        InstantiationStrategy strategy = this.beanFactory.getInstantiationStrategy();
+        if (System.getSecurityManager() != null) {
+            return AccessController.doPrivileged((PrivilegedAction<Object>) () ->
+                    strategy.instantiate(mbd, beanName, this.beanFactory, constructorToUse, argsToUse),
+                    this.beanFactory.getAccessControlContext());
+        } else {
+            return strategy.instantiate(mbd, beanName, this.beanFactory, constructorToUse, argsToUse);
+        }
+    } catch (Throwable ex) {
+        throw new BeanCreationException(mbd.getResourceDescription(), beanName,
+                "Bean instantiation via constructor failed", ex);
+    }
+}
+```
+
+- `#instantiateUsingFactoryMethod(...)` 方法，实在是**太大**了，处理细节感觉很复杂，LZ是硬着头皮看完的，中间断断续续的。吐槽这里的代码风格，完全不符合我们前面看的 Spring 代码风格。Spring 的一贯做法是将一个复杂逻辑进行拆分，分为多个细小的模块进行嵌套，每个模块负责一部分功能，模块与模块之间层层嵌套，上一层一般都是对下一层的总结和概括，这样就会使得每一层的逻辑变得清晰易懂。
+- 回归到上面的方法体，虽然代码体量大，但是总体我们还是可看清楚这个方法要做的事情。**一句话概括就是**：确定工厂对象，然后获取构造函数和构造参数，最后调用 InstantiationStrategy 对象的 `#instantiate(RootBeanDefinition bd, String beanName, BeanFactory owner, Constructor<?> ctor, Object... args)` 方法，**来创建 Bean 实例**。
+
+下面我们就这个句概括的话进行拆分并详细说明。
+
+#### 1.2.1.1 确定工厂对象
+
+> 对应 `<1>` 处。
+
+首先获取工厂方法名：
+
+- 若工厂方法名不为空，则调用 `AbstractAutowireCapableBeanFactory#getBean(String name)` 方法，获取工厂对象，
+- 若为空，则可能为一个静态工厂，对于静态工厂则必须提供工厂类的全类名，同时设置 `factoryBean = null` 。
+
+#### 1.2.1.2 构造参数确认
+
+> 对应 `<2>` 处。
+
+工厂对象确定后，则是确认构造参数。构造参数的确认主要分为**三种**情况：
+
+- `explicitArgs` 参数
+- 缓存中获取
+- 配置文件中解析
+
+##### 1.2.1.2.1 explicitArgs 参数
+
+> 对应 `<2.1>` 处。
+
+`explicitArgs` 参数，是我们调用 `#getBean(...)` 方法时传递进来的。一般该参数，该参数就是用于初始化 Bean 时所传递的参数。如果该参数不为空，则可以确定构造函数的参数就是它了。
+
+##### 1.2.1.2.2 缓存中获取
+
+> 对应 `<2.2>` 处。
+
+在该方法的最后，我们会发现这样一段 `argsHolderToUse.storeCache(mbd, factoryMethodToUse)` 代码。这段代码主要是将构造函数、构造参数保存到缓存中，代码如下：
+
+```
+// ConstructorResolver.ArgumentsHolder.java
+
+public void storeCache(RootBeanDefinition mbd, Executable constructorOrFactoryMethod) {
+	synchronized (mbd.constructorArgumentLock) {
+		mbd.resolvedConstructorOrFactoryMethod = constructorOrFactoryMethod;
+		mbd.constructorArgumentsResolved = true;
+		if (this.resolveNecessary) {
+			mbd.preparedConstructorArguments = this.preparedArguments;
+		} else {
+			mbd.resolvedConstructorArguments = this.arguments;
+		}
+	}
+}
+
+// RootBeanDefinition.java
+
+/** Common lock for the four constructor fields below. */
+final Object constructorArgumentLock = new Object(); // 构造函数的缓存锁
+
+/** Package-visible field for caching the resolved constructor or factory method. */
+@Nullable
+Executable resolvedConstructorOrFactoryMethod; // 缓存已经解析的构造函数或者工厂方法
+
+/** Package-visible field that marks the constructor arguments as resolved. */
+boolean constructorArgumentsResolved = false; // 标记字段，标记构造函数、参数已经解析了。默认为 `false` 。
+
+/** Package-visible field for caching fully resolved constructor arguments. */
+@Nullable
+Object[] resolvedConstructorArguments; // 缓存已经解析的构造函数参数，包可见字段。
+
+/** Package-visible field for caching partly prepared constructor arguments. */
+@Nullable
+Object[] preparedConstructorArguments;
+```
+
+其中涉及到的几个参数，都是跟构造函数、构造函数缓存有关的。如下：
+
+- `constructorArgumentLock` ：构造函数的缓存锁。
+- `resolvedConstructorOrFactoryMethod` ：缓存已经解析的构造函数或者工厂方法。
+- `constructorArgumentsResolved` ：标记字段，标记构造函数、参数已经解析了。默认为 `false` 。
+- `resolvedConstructorArguments` ：缓存已经解析的构造函数参数，包可见字段 。
+- `preparedConstructorArguments`
+
+------
+
+所以，从缓存中获取就是提取这几个参数的值。代码如下：
+
+```
+// ConstructorResolver.java
+
+// 没有指定，则尝试从配置文件中解析
+Object[] argsToResolve = null;
+// <2.2> 首先尝试从缓存中获取
+synchronized (mbd.constructorArgumentLock) {
+    // 获取缓存中的构造函数或者工厂方法
+    factoryMethodToUse = (Method) mbd.resolvedConstructorOrFactoryMethod;
+    if (factoryMethodToUse != null && mbd.constructorArgumentsResolved) {
+        // Found a cached factory method...
+        // 获取缓存中的构造参数
+        argsToUse = mbd.resolvedConstructorArguments;
+        if (argsToUse == null) {
+            // 获取缓存中的构造函数参数的包可见字段
+            argsToResolve = mbd.preparedConstructorArguments;
+        }
+    }
+}
+// 缓存中存在,则解析存储在 BeanDefinition 中的参数
+// 如给定方法的构造函数 A(int ,int )，则通过此方法后就会把配置文件中的("1","1")转换为 (1,1)
+// 缓存中的值可能是原始值也有可能是最终值
+if (argsToResolve != null) {
+    argsToUse = resolvePreparedArguments(beanName, mbd, bw, factoryMethodToUse, argsToResolve, true);
+}
+```
+
+- 如果缓存中存在构造参数，则需要调用
+
+   
+
+  ```
+  #resolvePreparedArguments(String beanName, RootBeanDefinition mbd, BeanWrapper bw, Executable executable, Object[] argsToResolve, boolean fallback)
+  ```
+
+   
+
+  方法，进行转换。
+
+  - 本文不详细解析该方法，感兴趣的胖友，可以自己查看。
+
+- 因为缓存中的值有可能是最终值，**也有可能不是最终值**。比如我们构造函数中的类型为 Integer 类型的 1 ，但是原始的参数类型有可能是 String 类型的 `"1"` ，所以即便是从缓存中得到了构造参数，也**需要经过一番的类型转换确保参数类型完全对应**。
+
+##### 1.2.1.2.3 配置文件中解析
+
+> 对应 `<2.3>` 处。
+
+即没有通过传递参数的方式传递构造参数，缓存中也没有，那就只能通过解析配置文件获取构造参数了。
+
+在 bean 解析类的博文中我们了解了，配置文件中的信息都会转换到 BeanDefinition 实例对象中，所以配置文件中的参数可以直接通过 BeanDefinition 对象获取。代码如下：
+
+```
+// AbstractAutowireCapableBeanFactory.java
+
+// <2.3> getBean() 没有传递参数，则需要解析保存在 BeanDefinition 构造函数中指定的参数
+if (mbd.hasConstructorArgumentValues()) {
+    // <2.3.1> 构造函数的参数
+    ConstructorArgumentValues cargs = mbd.getConstructorArgumentValues();
+    resolvedValues = new ConstructorArgumentValues();
+    // <2.3.2> 解析构造函数的参数
+    // 将该 bean 的构造函数参数解析为 resolvedValues 对象，其中会涉及到其他 bean
+    minNrOfArgs = resolveConstructorArguments(beanName, mbd, bw, cargs, resolvedValues);
+}
+```
+
+- `<2.3.1>` ，通过 BeanDefinition 的 `#getConstructorArgumentValues()` 方法，就可以获取构造信息了。
+- `<2.3.2>` ，有了构造信息就可以获取相关的参数值信息了，获取的参数信息包括直接值和引用，这一步骤的处理交由 `#resolveConstructorArguments(String beanName, RootBeanDefinition mbd, BeanWrapper bw, ConstructorArgumentValues cargs, ConstructorArgumentValues resolvedValues)` 方法来完成。该方法会将构造参数信息解析为 `resolvedValues` 对象 并返回解析到的参数个数 `minNrOfArgs` 。
+
+#### 1.2.1.3 构造函数
+
+> 对应 `<3>` 处。
+
+确定构造参数后，下一步则是确定构造函数。
+
+- 第一步，是通过 `#getCandidateMethods()` 方法，获取所有的构造方法，同时对构造方法进行刷选。
+- 然后，在对其进行排序处理（`AutowireUtils.sortFactoryMethods(candidates)`）。排序的主要目的，是为了能够**更加方便的**找到匹配的构造函数，因为构造函数的确认是根据参数个数确认的。排序的规则是：先按照 `public` / 非 `public` 构造函数**升序**，再按照构造参数数量**降序**。
+
+通过迭代 `candidates`（包含了所有要匹配的构造函数）的方式，依次比较其参数：
+
+- 如果显示提供了参数（`explicitArgs != null`），则直接比较两者**长度**是否相等，如果相等则表示找到了，否则继续比较。
+- 如果没有显示提供参数，则需要获取 `org.springframework.core.ParameterNameDiscoverer` 对象。该对象为参数名称探测器，主要用于发现方法和构造函数的参数名称。
+
+将参数包装成 `ConstructorResolver.ArgumentsHolder` 对象。该对象用于保存参数，我们称之为参数持有者。当将对象包装成 ArgumentsHolder 对象后，我们就可以通过它来进行构造函数**匹配**。匹配分为严格模式和宽松模式：
+
+- 严格模式：解析构造函数时，必须所有参数都需要匹配，否则抛出异常。
+- 宽松模式：使用具有”最接近的模式”进行匹配。
+
+判断的依据是根据 BeanDefinition 的 `isLenientConstructorResolution` 属性（该参数是我们在构造 AbstractBeanDefinition 对象是传递的）来获取类型差异权重（`typeDiffWeight`） 的。
+
+- 如果 `typeDiffWeight < minTypeDiffWeight` ，则代表“最接近的模式”，选择其作为构造函数。
+- 否则，只有两者具有相同的参数数量，且类型差异权重相等才会纳入考虑范围。
+
+至此，构造函数已经确认了。
+
+#### 1.2.1.4 创建 bean 实例
+
+> 对应 `<4>` 处。
+
+工厂对象、构造函数、构造参数都已经确认了，则最后一步就是调用 `org.springframework.beans.factory.support.InstantiationStrategy` 对象的 `#instantiate(RootBeanDefinition bd, String beanName, BeanFactory owner, Object factoryBean, final Method factoryMethod, @Nullable Object... args)` 方法，来创建 bean 实例。代码如下：
+
+```
+// SimpleInstantiationStrategy.java
+
+/**
+ * 线程变量，正在创建 Bean 的 Method 对象
+ */
+private static final ThreadLocal<Method> currentlyInvokedFactoryMethod = new ThreadLocal<>();
+
+@Override
+public Object instantiate(RootBeanDefinition bd, @Nullable String beanName, BeanFactory owner,
+        @Nullable Object factoryBean, final Method factoryMethod, Object... args) {
+    try {
+        // 设置 Method 可访问
+        if (System.getSecurityManager() != null) {
+            AccessController.doPrivileged((PrivilegedAction<Object>) () -> {
+                ReflectionUtils.makeAccessible(factoryMethod);
+                return null;
+            });
+        } else {
+            ReflectionUtils.makeAccessible(factoryMethod);
+        }
+
+        // 获得原 Method 对象
+        Method priorInvokedFactoryMethod = currentlyInvokedFactoryMethod.get();
+        try {
+            // 设置新的 Method 对象，到 currentlyInvokedFactoryMethod 中
+            currentlyInvokedFactoryMethod.set(factoryMethod);
+            // <x> 创建 Bean 对象
+            Object result = factoryMethod.invoke(factoryBean, args);
+            // 未创建，则创建 NullBean 对象
+            if (result == null) {
+                result = new NullBean();
+            }
+            return result;
+        } finally {
+            // 设置老的 Method 对象，到 currentlyInvokedFactoryMethod 中
+            if (priorInvokedFactoryMethod != null) {
+                currentlyInvokedFactoryMethod.set(priorInvokedFactoryMethod);
+            } else {
+                currentlyInvokedFactoryMethod.remove();
+            }
+        }
+    } catch (IllegalArgumentException ex) {
+        throw new BeanInstantiationException(factoryMethod,
+                "Illegal arguments to factory method '" + factoryMethod.getName() + "'; " +
+                "args: " + StringUtils.arrayToCommaDelimitedString(args), ex);
+    } catch (IllegalAccessException ex) {
+        throw new BeanInstantiationException(factoryMethod,
+                "Cannot access factory method '" + factoryMethod.getName() + "'; is it public?", ex);
+    } catch (InvocationTargetException ex) {
+        String msg = "Factory method '" + factoryMethod.getName() + "' threw exception";
+        if (bd.getFactoryBeanName() != null && owner instanceof ConfigurableBeanFactory &&
+                ((ConfigurableBeanFactory) owner).isCurrentlyInCreation(bd.getFactoryBeanName())) {
+            msg = "Circular reference involving containing bean '" + bd.getFactoryBeanName() + "' - consider " +
+                    "declaring the factory method as static for independence from its containing instance. " + msg;
+        }
+        throw new BeanInstantiationException(factoryMethod, msg, ex.getTargetException());
+    }
+}
+```
+
+- 核心的部分，在于 `<x>` 处，利用 Java 反射执行工厂方法并返回创建好的实例，也就是这段代码：
+
+  ```
+  // SimpleInstantiationStrategy.java
+  
+  Object result = factoryMethod.invoke(factoryBean, args);
+  ```
+
+## 1.2.2 独白
+
+到这里 `#instantiateUsingFactoryMethod(...)` 方法，已经分析完毕了。这里， LZ 有些题外话需要说下，**看源码真心是一个痛苦的过程，尤其是复杂的源码，比如这个方法我看了三天才弄清楚点皮毛，当然这里跟 LZ 的智商有些关系（智商捉急 ┭┮﹏┭┮），写这篇博客也花了五天时间才写完（最后截稿日为：2018.08.10 01:23:49），所以每一个坚持写博客的都是折翼的天使，值得各位尊敬**
+
+# 2. 小结
+
+`#createBeanInstance(...)` 方法中，还有两个重要方法：
+
+- `autowireConstructor(...)` 方法
+- `#instantiateBean(...)` 方法
+
+由于篇幅问题，所以将这两个方法放在下篇博客分析。敬请期待！！！
\ No newline at end of file
diff --git a/spring/26-Spring-IoC 之加载 Bean：创建 Bean（三）之实例化 Bean 对象(2).md b/spring/26-Spring-IoC 之加载 Bean：创建 Bean（三）之实例化 Bean 对象(2).md
new file mode 100644
index 0000000..9345dcd
--- /dev/null
+++ b/spring/26-Spring-IoC 之加载 Bean：创建 Bean（三）之实例化 Bean 对象(2).md	
@@ -0,0 +1,482 @@
+# 【死磕 Spring】—— IoC 之加载 Bean：创建 Bean（三）之实例化 Bean 对象(2)
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=todo 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+`#createBeanInstance(String beanName, RootBeanDefinition mbd, Object[] args)` 方法，用于实例化 Bean 对象。它会根据不同情况，选择不同的实例化策略来完成 Bean 的初始化，主要包括：
+
+- Supplier 回调：`#obtainFromSupplier(final String beanName, final RootBeanDefinition mbd)` 方法。
+- 工厂方法初始化：`#instantiateUsingFactoryMethod(String beanName, RootBeanDefinition mbd, @Nullable Object[] explicitArgs)` 方法。
+- 构造函数自动注入初始化：`#autowireConstructor(final String beanName, final RootBeanDefinition mbd, Constructor<?>[] chosenCtors, final Object[] explicitArgs)` 方法。
+- 默认构造函数注入：`#instantiateBean(final String beanName, final RootBeanDefinition mbd)` 方法。
+
+在上篇博客([《【死磕 Spring】—— IoC 之加载 bean：创建 bean（二）》](http://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-2)) 中，分析了**前两种** Supplier 回调和工厂方法初始化。这篇博文，分析**后两种**构造函数注入。
+
+# 1. autowireConstructor
+
+这个初始化方法，我们可以简单理解为是**带有参数的构造方法**，来初始化 Bean 对象。代码段如下：
+
+```
+// AbstractAutowireCapableBeanFactory.java
+
+protected BeanWrapper autowireConstructor(String beanName, RootBeanDefinition mbd, @Nullable Constructor<?>[] ctors, @Nullable Object[] explicitArgs) {
+    return new ConstructorResolver(this).autowireConstructor(beanName, mbd, ctors, explicitArgs);
+}
+
+// ConstructorResolver.java
+
+public BeanWrapper autowireConstructor(String beanName, RootBeanDefinition mbd,
+        @Nullable Constructor<?>[] chosenCtors, @Nullable Object[] explicitArgs) {
+    // 封装 BeanWrapperImpl 对象，并完成初始化
+    BeanWrapperImpl bw = new BeanWrapperImpl();
+    this.beanFactory.initBeanWrapper(bw);
+
+    // 获得 constructorToUse、argsHolderToUse、argsToUse
+    Constructor<?> constructorToUse = null; // 构造函数
+    ArgumentsHolder argsHolderToUse = null; // 构造参数
+    Object[] argsToUse = null; // 构造参数
+
+    // 确定构造参数
+    // 如果 getBean() 已经传递，则直接使用
+    if (explicitArgs != null) {
+        argsToUse = explicitArgs;
+    } else {
+        // 尝试从缓存中获取
+        Object[] argsToResolve = null;
+        synchronized (mbd.constructorArgumentLock) {
+            // 缓存中的构造函数或者工厂方法
+            constructorToUse = (Constructor<?>) mbd.resolvedConstructorOrFactoryMethod;
+            if (constructorToUse != null && mbd.constructorArgumentsResolved) {
+                // Found a cached constructor...
+                // 缓存中的构造参数
+                argsToUse = mbd.resolvedConstructorArguments;
+                if (argsToUse == null) {
+                    argsToResolve = mbd.preparedConstructorArguments;
+                }
+            }
+        }
+        // 缓存中存在,则解析存储在 BeanDefinition 中的参数
+        // 如给定方法的构造函数 A(int ,int )，则通过此方法后就会把配置文件中的("1","1")转换为 (1,1)
+        // 缓存中的值可能是原始值也有可能是最终值
+        if (argsToResolve != null) {
+            argsToUse = resolvePreparedArguments(beanName, mbd, bw, constructorToUse, argsToResolve, true);
+        }
+    }
+
+    // 没有缓存，则尝试从配置文件中获取参数
+    if (constructorToUse == null || argsToUse == null) {
+        // Take specified constructors, if any.
+        // 如果 chosenCtors 未传入，则获取构造方法们
+        Constructor<?>[] candidates = chosenCtors;
+        if (candidates == null) {
+            Class<?> beanClass = mbd.getBeanClass();
+            try {
+                candidates = (mbd.isNonPublicAccessAllowed() ?
+                        beanClass.getDeclaredConstructors() : beanClass.getConstructors());
+            } catch (Throwable ex) {
+                throw new BeanCreationException(mbd.getResourceDescription(), beanName,
+                        "Resolution of declared constructors on bean Class [" + beanClass.getName() +
+                        "] from ClassLoader [" + beanClass.getClassLoader() + "] failed", ex);
+            }
+        }
+
+        // TODO 芋艿 创建 Bean
+        if (candidates.length == 1 && explicitArgs == null && !mbd.hasConstructorArgumentValues()) {
+            Constructor<?> uniqueCandidate = candidates[0];
+            if (uniqueCandidate.getParameterCount() == 0) {
+                synchronized (mbd.constructorArgumentLock) {
+                    mbd.resolvedConstructorOrFactoryMethod = uniqueCandidate;
+                    mbd.constructorArgumentsResolved = true;
+                    mbd.resolvedConstructorArguments = EMPTY_ARGS;
+                }
+                bw.setBeanInstance(instantiate(beanName, mbd, uniqueCandidate, EMPTY_ARGS));
+                return bw;
+            }
+        }
+
+        // 是否需要解析构造器
+        // Need to resolve the constructor.
+        boolean autowiring = (chosenCtors != null ||
+                mbd.getResolvedAutowireMode() == AutowireCapableBeanFactory.AUTOWIRE_CONSTRUCTOR);
+        // 用于承载解析后的构造函数参数的值
+        ConstructorArgumentValues resolvedValues = null;
+        int minNrOfArgs;
+        if (explicitArgs != null) {
+            minNrOfArgs = explicitArgs.length;
+        } else {
+            // 从 BeanDefinition 中获取构造参数，也就是从配置文件中提取构造参数
+            ConstructorArgumentValues cargs = mbd.getConstructorArgumentValues();
+            resolvedValues = new ConstructorArgumentValues();
+            // 解析构造函数的参数
+            // 将该 bean 的构造函数参数解析为 resolvedValues 对象，其中会涉及到其他 bean
+            minNrOfArgs = resolveConstructorArguments(beanName, mbd, bw, cargs, resolvedValues);
+        }
+
+        // 对构造函数进行排序处理
+        // public 构造函数优先参数数量降序，非public 构造函数参数数量降序
+        AutowireUtils.sortConstructors(candidates);
+
+        // 最小参数类型权重
+        int minTypeDiffWeight = Integer.MAX_VALUE;
+        Set<Constructor<?>> ambiguousConstructors = null;
+        LinkedList<UnsatisfiedDependencyException> causes = null;
+
+        // 迭代所有构造函数
+        for (Constructor<?> candidate : candidates) {
+            // 获取该构造函数的参数类型
+            Class<?>[] paramTypes = candidate.getParameterTypes();
+
+            // 如果已经找到选用的构造函数或者需要的参数个数小于当前的构造函数参数个数，则终止。
+            // 因为，已经按照参数个数降序排列了
+            if (constructorToUse != null && argsToUse.length > paramTypes.length) {
+                // Already found greedy constructor that can be satisfied ->
+                // do not look any further, there are only less greedy constructors left.
+                break;
+            }
+            // 参数个数不等，继续
+            if (paramTypes.length < minNrOfArgs) {
+                continue;
+            }
+
+            // 参数持有者 ArgumentsHolder 对象
+            ArgumentsHolder argsHolder;
+            if (resolvedValues != null) {
+                try {
+                    // 注释上获取参数名称
+                    String[] paramNames = ConstructorPropertiesChecker.evaluate(candidate, paramTypes.length);
+                    if (paramNames == null) {
+                        // 获取构造函数、方法参数的探测器
+                        ParameterNameDiscoverer pnd = this.beanFactory.getParameterNameDiscoverer();
+                        if (pnd != null) {
+                            // 通过探测器获取构造函数的参数名称
+                            paramNames = pnd.getParameterNames(candidate);
+                        }
+                    }
+                    // 根据构造函数和构造参数，创建参数持有者 ArgumentsHolder 对象
+                    argsHolder = createArgumentArray(beanName, mbd, resolvedValues, bw, paramTypes, paramNames,
+                            getUserDeclaredConstructor(candidate), autowiring, candidates.length == 1);
+                } catch (UnsatisfiedDependencyException ex) {
+                    // 若发生 UnsatisfiedDependencyException 异常，添加到 causes 中。
+                    if (logger.isTraceEnabled()) {
+                        logger.trace("Ignoring constructor [" + candidate + "] of bean '" + beanName + "': " + ex);
+                    }
+                    // Swallow and try next constructor.
+                    if (causes == null) {
+                        causes = new LinkedList<>();
+                    }
+                    causes.add(ex);
+                    continue; // continue ，继续执行
+                }
+            } else {
+                // continue 构造函数没有参数
+                // Explicit arguments given -> arguments length must match exactly.
+                if (paramTypes.length != explicitArgs.length) {
+                    continue;
+                }
+                // 根据 explicitArgs ，创建 ArgumentsHolder 对象
+                argsHolder = new ArgumentsHolder(explicitArgs);
+            }
+
+            // isLenientConstructorResolution 判断解析构造函数的时候是否以宽松模式还是严格模式
+            // 严格模式：解析构造函数时，必须所有的都需要匹配，否则抛出异常
+            // 宽松模式：使用具有"最接近的模式"进行匹配
+            // typeDiffWeight：类型差异权重
+            int typeDiffWeight = (mbd.isLenientConstructorResolution() ?
+                    argsHolder.getTypeDifferenceWeight(paramTypes) : argsHolder.getAssignabilityWeight(paramTypes));
+            // Choose this constructor if it represents the closest match.
+            // 如果它代表着当前最接近的匹配则选择其作为构造函数
+            if (typeDiffWeight < minTypeDiffWeight) {
+                constructorToUse = candidate;
+                argsHolderToUse = argsHolder;
+                argsToUse = argsHolder.arguments;
+                minTypeDiffWeight = typeDiffWeight;
+                ambiguousConstructors = null;
+            } else if (constructorToUse != null && typeDiffWeight == minTypeDiffWeight) {
+                if (ambiguousConstructors == null) {
+                    ambiguousConstructors = new LinkedHashSet<>();
+                    ambiguousConstructors.add(constructorToUse);
+                }
+                ambiguousConstructors.add(candidate);
+            }
+        }
+
+        // 没有可执行的工厂方法，抛出异常
+        if (constructorToUse == null) {
+            if (causes != null) {
+                UnsatisfiedDependencyException ex = causes.removeLast();
+                for (Exception cause : causes) {
+                    this.beanFactory.onSuppressedException(cause);
+                }
+                throw ex;
+            }
+            throw new BeanCreationException(mbd.getResourceDescription(), beanName,
+                    "Could not resolve matching constructor " +
+                    "(hint: specify index/type/name arguments for simple parameters to avoid type ambiguities)");
+        } else if (ambiguousConstructors != null && !mbd.isLenientConstructorResolution()) {
+            throw new BeanCreationException(mbd.getResourceDescription(), beanName,
+                    "Ambiguous constructor matches found in bean '" + beanName + "' " +
+                    "(hint: specify index/type/name arguments for simple parameters to avoid type ambiguities): " +
+                    ambiguousConstructors);
+        }
+
+        if (explicitArgs == null) {
+            // 将解析的构造函数加入缓存
+            argsHolderToUse.storeCache(mbd, constructorToUse);
+        }
+    }
+
+    // 创建 Bean 对象，并设置到 bw 中
+    bw.setBeanInstance(instantiate(beanName, mbd, constructorToUse, argsToUse));
+    return bw;
+}
+```
+
+- 代码与 `#instantiateUsingFactoryMethod(String beanName, RootBeanDefinition mbd, @Nullable Object[] explicitArgs)` 方法，一样，又长又难懂。但是如果理解了 `#instantiateUsingFactoryMethod(...)` 方法的初始化 bean 的过程，那么 `#autowireConstructor(...)` 方法，**也不存在什么难的地方了**。
+- 一句话概括：首先确定构造函数参数、构造函数，然后调用相应的初始化策略进行 bean 的初始化。关于如何确定构造函数、构造参数，该部分逻辑和 `#instantiateUsingFactoryMethod(...)` 方法，基本一致。所以这里不再重复阐述了，具体过程请移步[【死磕 Spring】—— IoC 之加载 bean：创建 bean（二）](http://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-2)，这里我们重点分析初始化策略。
+
+## 1.1 instantiate
+
+```
+// BeanUtils.java
+
+public static <T> T instantiateClass(Constructor<T> ctor, Object... args) throws BeanInstantiationException {
+    Assert.notNull(ctor, "Constructor must not be null");
+    try {
+        // 设置构造方法，可访问
+        ReflectionUtils.makeAccessible(ctor);
+        // 使用构造方法，创建对象
+        return (KotlinDetector.isKotlinReflectPresent() && KotlinDetector.isKotlinType(ctor.getDeclaringClass()) ?
+                KotlinDelegate.instantiateClass(ctor, args) : ctor.newInstance(args));
+    // 各种异常的翻译，最终统一抛出 BeanInstantiationException 异常
+    } catch (InstantiationException ex) {
+        throw new BeanInstantiationException(ctor, "Is it an abstract class?", ex);
+    } catch (IllegalAccessException ex) {
+        throw new BeanInstantiationException(ctor, "Is the constructor accessible?", ex);
+    } catch (IllegalArgumentException ex) {
+        throw new BeanInstantiationException(ctor, "Illegal arguments for constructor", ex);
+    } catch (InvocationTargetException ex) {
+        throw new BeanInstantiationException(ctor, "Constructor threw exception", ex.getTargetException());
+    }
+}
+```
+
+- `<1>` 首先，是获取实例化 Bean 的策略 InstantiationStrategy 对象。
+
+- `<2>` 然后，调用其 `#instantiate(RootBeanDefinition bd, String beanName, BeanFactory owner, Constructor<?> ctor, Object... args)` 方法，该方法在 SimpleInstantiationStrategy 中实现。代码如下：
+
+  ```
+  // SimpleInstantiationStrategy.java
+  
+  @Override
+  public Object instantiate(RootBeanDefinition bd, @Nullable String beanName, BeanFactory owner,
+          final Constructor<?> ctor, Object... args) {
+      // <x1> 没有覆盖，直接使用反射实例化即可
+      if (!bd.hasMethodOverrides()) {
+          if (System.getSecurityManager() != null) {
+              // 设置构造方法，可访问
+              // use own privileged to change accessibility (when security is on)
+              AccessController.doPrivileged((PrivilegedAction<Object>) () -> {
+                  ReflectionUtils.makeAccessible(ctor);
+                  return null;
+              });
+          }
+          // 通过 BeanUtils 直接使用构造器对象实例化 Bean 对象
+          return BeanUtils.instantiateClass(ctor, args);
+      } else {
+          // <x2> 生成 CGLIB 创建的子类对象
+          return instantiateWithMethodInjection(bd, beanName, owner, ctor, args);
+      }
+  }
+  ```
+
+  - `<x1>` 如果该 bean 没有配置 `lookup-method`、`replaced-method` 标签或者 `@Lookup` 注解，则直接通过**反射**的方式实例化 Bean 对象即可，方便快捷。详细解析，见 [「1.1.1 反射创建 Bean 对象」](https://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-3/#) 中。
+  - `<x2>` 但是，如果存在需要覆盖的方法或者动态替换的方法时，则需要使用 CGLIB 进行动态代理，因为可以在创建代理的同时将动态方法织入类中。详细解析，见 [「1.1.2 CGLIB 创建 Bean 对象」](https://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-3/#) 中。
+
+### 1.1.1 反射创建 Bean 对象
+
+调用工具类 BeanUtils 的 `#instantiateClass(Constructor<T> ctor, Object... args)` 方法，完成反射工作，创建对象。代码如下：
+
+```
+// BeanUtils.java
+
+public static <T> T instantiateClass(Constructor<T> ctor, Object... args) throws BeanInstantiationException {
+    Assert.notNull(ctor, "Constructor must not be null");
+    try {
+        // 设置构造方法，可访问
+        ReflectionUtils.makeAccessible(ctor);
+        // 使用构造方法，创建对象
+        return (KotlinDetector.isKotlinReflectPresent() && KotlinDetector.isKotlinType(ctor.getDeclaringClass()) ?
+                KotlinDelegate.instantiateClass(ctor, args) : ctor.newInstance(args));
+    // 各种异常的翻译，最终统一抛出 BeanInstantiationException 异常
+    } catch (InstantiationException ex) {
+        throw new BeanInstantiationException(ctor, "Is it an abstract class?", ex);
+    } catch (IllegalAccessException ex) {
+        throw new BeanInstantiationException(ctor, "Is the constructor accessible?", ex);
+    } catch (IllegalArgumentException ex) {
+        throw new BeanInstantiationException(ctor, "Illegal arguments for constructor", ex);
+    } catch (InvocationTargetException ex) {
+        throw new BeanInstantiationException(ctor, "Constructor threw exception", ex.getTargetException());
+    }
+}
+```
+
+### 1.1.2 CGLIB 创建 Bean 对象
+
+```
+// SimpleInstantiationStrategy.java
+
+protected Object instantiateWithMethodInjection(RootBeanDefinition bd, @Nullable String beanName, BeanFactory owner) {
+	throw new UnsupportedOperationException("Method Injection not supported in SimpleInstantiationStrategy");
+}
+```
+
+- 方法默认是**没有实现**的，具体过程由其子类 `org.springframework.beans.factory.support.CglibSubclassingInstantiationStrategy` 来实现。代码如下：
+
+  ```
+  // CglibSubclassingInstantiationStrategy.java
+  
+  @Override
+  protected Object instantiateWithMethodInjection(RootBeanDefinition bd, @Nullable String beanName, BeanFactory owner) {
+      return instantiateWithMethodInjection(bd, beanName, owner, null);
+  }
+  @Override
+  protected Object instantiateWithMethodInjection(RootBeanDefinition bd, @Nullable String beanName, BeanFactory owner, @Nullable Constructor<?> ctor, Object... args) {
+      // Must generate CGLIB subclass...
+      // 通过CGLIB生成一个子类对象
+      return new CglibSubclassCreator(bd, owner).instantiate(ctor, args);
+  }
+  ```
+
+  - 创建一个 CglibSubclassCreator 对象，后调用其 `#instantiate(Constructor<?> ctor, Object... args)` 方法，生成其子类对象。代码如下：
+
+    ```
+    // CglibSubclassingInstantiationStrategy.java
+    
+    public Object instantiate(@Nullable Constructor<?> ctor, Object... args) {
+        // 通过 Cglib 创建一个代理类
+        Class<?> subclass = createEnhancedSubclass(this.beanDefinition);
+        Object instance;
+        // 没有构造器，通过 BeanUtils 使用默认构造器创建一个bean实例
+        if (ctor == null) {
+            instance = BeanUtils.instantiateClass(subclass);
+        } else {
+            try {
+                // 获取代理类对应的构造器对象，并实例化 bean
+                Constructor<?> enhancedSubclassConstructor = subclass.getConstructor(ctor.getParameterTypes());
+                instance = enhancedSubclassConstructor.newInstance(args);
+            } catch (Exception ex) {
+                throw new BeanInstantiationException(this.beanDefinition.getBeanClass(),
+                        "Failed to invoke constructor for CGLIB enhanced subclass [" + subclass.getName() + "]", ex);
+            }
+        }
+        // SPR-10785: set callbacks directly on the instance instead of in the
+        // enhanced class (via the Enhancer) in order to avoid memory leaks.
+        // 为了避免 memory leaks 异常，直接在 bean 实例上设置回调对象
+        Factory factory = (Factory) instance;
+        factory.setCallbacks(new Callback[] {NoOp.INSTANCE,
+                new LookupOverrideMethodInterceptor(this.beanDefinition, this.owner),
+                new ReplaceOverrideMethodInterceptor(this.beanDefinition, this.owner)});
+        return instance;
+    }
+    ```
+
+    - 到这类 CGLIB 的方式分析完毕了，当然这里还没有具体分析 CGLIB 生成子类的详细过程，具体的过程等后续分析 AOP 的时候再详细地介绍。
+
+# 2. instantiateBean
+
+```
+// AbstractAutowireCapableBeanFactory.java
+
+protected BeanWrapper instantiateBean(final String beanName, final RootBeanDefinition mbd) {
+    try {
+        Object beanInstance;
+        final BeanFactory parent = this;
+        // 安全模式
+        if (System.getSecurityManager() != null) {
+            beanInstance = AccessController.doPrivileged((PrivilegedAction<Object>) () ->
+                    // 获得 InstantiationStrategy 对象，并使用它，创建 Bean 对象
+                    getInstantiationStrategy().instantiate(mbd, beanName, parent),
+                    getAccessControlContext());
+        } else {
+            // 获得 InstantiationStrategy 对象，并使用它，创建 Bean 对象
+            beanInstance = getInstantiationStrategy().instantiate(mbd, beanName, parent);
+        }
+        // 封装 BeanWrapperImpl  并完成初始化
+        BeanWrapper bw = new BeanWrapperImpl(beanInstance);
+        initBeanWrapper(bw);
+        return bw;
+    } catch (Throwable ex) {
+        throw new BeanCreationException(
+                mbd.getResourceDescription(), beanName, "Instantiation of bean failed", ex);
+    }
+}
+```
+
+- 这个方法,相比于 `#instantiateUsingFactoryMethod(...)` 、 `#autowireConstructor(...)` 方法，**实在是太简单了**，因为，它没有参数，所以不需要确认经过复杂的过来来确定构造器、构造参数，所以这里就不过多阐述了。
+
+## 2.1 instantiate
+
+```
+// SimpleInstantiationStrategy.java
+
+@Override
+public Object instantiate(RootBeanDefinition bd, @Nullable String beanName, BeanFactory owner) {
+    // Don't override the class with CGLIB if no overrides.
+    // 没有覆盖，直接使用反射实例化即可
+    if (!bd.hasMethodOverrides()) {
+        Constructor<?> constructorToUse;
+        synchronized (bd.constructorArgumentLock) {
+            // 获得构造方法 constructorToUse
+            constructorToUse = (Constructor<?>) bd.resolvedConstructorOrFactoryMethod;
+            if (constructorToUse == null) {
+                final Class<?> clazz = bd.getBeanClass();
+                // 如果是接口，抛出 BeanInstantiationException 异常
+                if (clazz.isInterface()) {
+                    throw new BeanInstantiationException(clazz, "Specified class is an interface");
+                }
+                try {
+                    // 从 clazz 中，获得构造方法
+                    if (System.getSecurityManager() != null) { // 安全模式
+                        constructorToUse = AccessController.doPrivileged(
+                                (PrivilegedExceptionAction<Constructor<?>>) clazz::getDeclaredConstructor);
+                    } else {
+                        constructorToUse =  clazz.getDeclaredConstructor();
+                    }
+                    // 标记 resolvedConstructorOrFactoryMethod 属性
+                    bd.resolvedConstructorOrFactoryMethod = constructorToUse;
+                } catch (Throwable ex) {
+                    throw new BeanInstantiationException(clazz, "No default constructor found", ex);
+                }
+            }
+        }
+        // 通过 BeanUtils 直接使用构造器对象实例化 Bean 对象
+        return BeanUtils.instantiateClass(constructorToUse);
+    } else {
+        // Must generate CGLIB subclass.
+        // 生成 CGLIB 创建的子类对象
+        return instantiateWithMethodInjection(bd, beanName, owner);
+    }
+}
+```
+
+# 3. 小结
+
+对于 `#createBeanInstance(...)` 方法而言，他就是**选择合适实例化策略**来为 bean 创建实例对象，具体的策略有：
+
+- Supplier 回调方式
+- 工厂方法初始化
+- 构造函数自动注入初始化
+- 默认构造函数注入。
+
+其中，工厂方法初始化和构造函数自动注入初始化两种方式**最为复杂**，主要是因为构造函数和构造参数的不确定性，Spring 需要花大量的精力来确定构造函数和构造参数，如果确定了则好办，直接选择实例化策略即可。
+
+当然，在实例化的时候会根据是否有需要覆盖或者动态替换掉的方法，因为存在覆盖或者织入的话需要创建动态代理将方法织入，这个时候就只能选择 CGLIB 的方式来实例化，否则直接利用反射的方式即可，方便快捷。
+
+------
+
+到这里 `#createBeanInstance(...)` 的过程就已经分析完毕了，下篇介绍 `#doCreateBean(...)` 方法中的第二个过程：**循环依赖的处理**。其实，在整个 bean 的加载过程中都涉及到了循环依赖的处理，所以下面分析并不是仅仅只针对 `#doCreateBean(...)` 方法中的循环依赖处理，**而是 Spring 在整个 IoC 体系中是如何解决循环依赖的**。
\ No newline at end of file
diff --git a/spring/27-Spring-IoC 之加载 Bean：创建 Bean（四）之属性填充.md b/spring/27-Spring-IoC 之加载 Bean：创建 Bean（四）之属性填充.md
new file mode 100644
index 0000000..80356c6
--- /dev/null
+++ b/spring/27-Spring-IoC 之加载 Bean：创建 Bean（四）之属性填充.md	
@@ -0,0 +1,638 @@
+# 【死磕 Spring】—— IoC 之加载 Bean：创建 Bean（四）之属性填充
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=todo 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+`#doCreateBean(...)` 方法，主要用于完成 bean 的创建和初始化工作，我们可以将其分为四个过程：
+
+- `#createBeanInstance(String beanName, RootBeanDefinition mbd, Object[] args)` 方法，实例化 bean 。
+- 循环依赖的处理。
+- `#populateBean(String beanName, RootBeanDefinition mbd, BeanWrapper bw)` 方法，进行属性填充。
+- `#initializeBean(final String beanName, final Object bean, RootBeanDefinition mbd)` 方法，初始化 Bean 。
+
+第一个过程，实例化 bean 已经在前面两篇博客分析完毕了。
+这篇博客开始，分析属性填充，也就是 `#populateBean(...)` 方法。该函数的作用是将 BeanDefinition 中的属性值赋值给 BeanWrapper 实例对象(对于 BeanWrapper ，我们后续专门写文分析)。
+
+# 1. populateBean
+
+```
+// AbstractAutowireCapableBeanFactory.java
+
+protected void populateBean(String beanName, RootBeanDefinition mbd, @Nullable BeanWrapper bw) {
+    // 没有实例化对象
+    if (bw == null) {
+        // 有属性，则抛出 BeanCreationException 异常
+        if (mbd.hasPropertyValues()) {
+            throw new BeanCreationException(
+                    mbd.getResourceDescription(), beanName, "Cannot apply property values to null instance");
+            // 没有属性，直接 return 返回
+        } else {
+            // Skip property population phase for null instance.
+            return;
+        }
+    }
+
+    // <1> 在设置属性之前给 InstantiationAwareBeanPostProcessors 最后一次改变 bean 的机会
+    // 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.
+    boolean continueWithPropertyPopulation = true;
+    if (!mbd.isSynthetic()  // bean 不是"合成"的，即未由应用程序本身定义
+            && hasInstantiationAwareBeanPostProcessors()) { // 是否持有 InstantiationAwareBeanPostProcessor
+        // 迭代所有的 BeanPostProcessors
+        for (BeanPostProcessor bp : getBeanPostProcessors()) {
+            if (bp instanceof InstantiationAwareBeanPostProcessor) { // 如果为 InstantiationAwareBeanPostProcessor
+                InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp;
+                // 返回值为是否继续填充 bean
+                // postProcessAfterInstantiation：如果应该在 bean上面设置属性则返回 true，否则返回 false
+                // 一般情况下，应该是返回true 。
+                // 返回 false 的话，将会阻止在此 Bean 实例上调用任何后续的 InstantiationAwareBeanPostProcessor 实例。
+                if (!ibp.postProcessAfterInstantiation(bw.getWrappedInstance(), beanName)) {
+                    continueWithPropertyPopulation = false;
+                    break;
+                }
+            }
+        }
+    }
+    // 如果后续处理器发出停止填充命令，则终止后续操作
+    if (!continueWithPropertyPopulation) {
+        return;
+    }
+
+    // bean 的属性值
+    PropertyValues pvs = (mbd.hasPropertyValues() ? mbd.getPropertyValues() : null);
+
+    // <2> 自动注入
+    if (mbd.getResolvedAutowireMode() == AUTOWIRE_BY_NAME || mbd.getResolvedAutowireMode() == AUTOWIRE_BY_TYPE) {
+        // 将 PropertyValues 封装成 MutablePropertyValues 对象
+        // MutablePropertyValues 允许对属性进行简单的操作，并提供构造函数以支持Map的深度复制和构造。
+        MutablePropertyValues newPvs = new MutablePropertyValues(pvs);
+        // Add property values based on autowire by name if applicable.
+        // 根据名称自动注入
+        if (mbd.getResolvedAutowireMode() == AUTOWIRE_BY_NAME) {
+            autowireByName(beanName, mbd, bw, newPvs);
+        }
+        // Add property values based on autowire by type if applicable.
+        // 根据类型自动注入
+        if (mbd.getResolvedAutowireMode() == AUTOWIRE_BY_TYPE) {
+            autowireByType(beanName, mbd, bw, newPvs);
+        }
+        pvs = newPvs;
+    }
+
+    // 是否已经注册了 InstantiationAwareBeanPostProcessors
+    boolean hasInstAwareBpps = hasInstantiationAwareBeanPostProcessors();
+    // 是否需要进行【依赖检查】
+    boolean needsDepCheck = (mbd.getDependencyCheck() != AbstractBeanDefinition.DEPENDENCY_CHECK_NONE);
+
+    // <3> BeanPostProcessor 处理
+    PropertyDescriptor[] filteredPds = null;
+    if (hasInstAwareBpps) {
+        if (pvs == null) {
+            pvs = mbd.getPropertyValues();
+        }
+        // 遍历 BeanPostProcessor 数组
+        for (BeanPostProcessor bp : getBeanPostProcessors()) {
+            if (bp instanceof InstantiationAwareBeanPostProcessor) {
+                InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp;
+                // 对所有需要依赖检查的属性进行后处理
+                PropertyValues pvsToUse = ibp.postProcessProperties(pvs, bw.getWrappedInstance(), beanName);
+                if (pvsToUse == null) {
+                    // 从 bw 对象中提取 PropertyDescriptor 结果集
+                    // PropertyDescriptor：可以通过一对存取方法提取一个属性
+                    if (filteredPds == null) {
+                        filteredPds = filterPropertyDescriptorsForDependencyCheck(bw, mbd.allowCaching);
+                    }
+                    pvsToUse = ibp.postProcessPropertyValues(pvs, filteredPds, bw.getWrappedInstance(), beanName);
+                    if (pvsToUse == null) {
+                        return;
+                    }
+                }
+                pvs = pvsToUse;
+            }
+        }
+    }
+    
+    // <4> 依赖检查
+    if (needsDepCheck) {
+        if (filteredPds == null) {
+            filteredPds = filterPropertyDescriptorsForDependencyCheck(bw, mbd.allowCaching);
+        }
+        // 依赖检查，对应 depends-on 属性
+        checkDependencies(beanName, mbd, filteredPds, pvs);
+    }
+
+    // <5> 将属性应用到 bean 中
+    if (pvs != null) {
+        applyPropertyValues(beanName, mbd, bw, pvs);
+    }
+}
+```
+
+处理流程如下：
+
+- `<1>` ，根据 `hasInstantiationAwareBeanPostProcessors` 属性来判断，是否需要在注入属性之前给 InstantiationAwareBeanPostProcessors 最后一次改变 bean 的机会。**此过程可以控制 Spring 是否继续进行属性填充**。
+
+- 统一存入到 PropertyValues 中，PropertyValues 用于描述 bean 的属性。
+
+  - ```
+    <2>
+    ```
+
+     
+
+    ，根据注入类型(
+
+     
+
+    ```
+    AbstractBeanDefinition#getResolvedAutowireMode()
+    ```
+
+     
+
+    方法的返回值 )的不同来判断：
+
+    - 是根据名称来自动注入（`#autowireByName(...)`）
+    - 还是根据类型来自动注入（`#autowireByType(...)`）
+    - 详细解析，见 [「1.1 自动注入」](https://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-4/#) 。
+
+  - `<3>` ，进行 BeanPostProcessor 处理。
+
+  - `<4>` ，依赖检测。
+
+- `<5>` ，将所有 PropertyValues 中的属性，填充到 BeanWrapper 中。
+
+## 1.1 自动注入
+
+Spring 会根据注入类型（ `byName` / `byType` ）的不同，调用不同的方法来注入属性值。代码如下：
+
+```
+// AbstractBeanDefinition.java
+
+/**
+ * 注入模式
+ */
+private int autowireMode = AUTOWIRE_NO;
+
+public int getResolvedAutowireMode() {
+	if (this.autowireMode == AUTOWIRE_AUTODETECT) { // 自动检测模式，获得对应的检测模式
+		// Work out whether to apply setter autowiring or constructor autowiring.
+		// If it has a no-arg constructor it's deemed to be setter autowiring,
+		// otherwise we'll try constructor autowiring.
+		Constructor<?>[] constructors = getBeanClass().getConstructors();
+		for (Constructor<?> constructor : constructors) {
+			if (constructor.getParameterCount() == 0) {
+				return AUTOWIRE_BY_TYPE;
+			}
+		}
+		return AUTOWIRE_CONSTRUCTOR;
+	} else {
+		return this.autowireMode;
+	}
+}
+```
+
+### 1.1.1 autowireByName
+
+`#autowireByName(String beanName, AbstractBeanDefinition mbd, BeanWrapper bw, MutablePropertyValues pvs)` 方法，是根据**属性名称**，完成自动依赖注入的。代码如下：
+
+```
+// AbstractAutowireCapableBeanFactory.java
+
+protected void autowireByName(String beanName, AbstractBeanDefinition mbd, BeanWrapper bw, MutablePropertyValues pvs) {
+    // <1> 对 Bean 对象中非简单属性
+    String[] propertyNames = unsatisfiedNonSimpleProperties(mbd, bw);
+    // 遍历 propertyName 数组
+    for (String propertyName : propertyNames) {
+        // 如果容器中包含指定名称的 bean，则将该 bean 注入到 bean中
+        if (containsBean(propertyName)) {
+            // 递归初始化相关 bean
+            Object bean = getBean(propertyName);
+            // 为指定名称的属性赋予属性值
+            pvs.add(propertyName, bean);
+            // 属性依赖注入
+            registerDependentBean(propertyName, beanName);
+            if (logger.isTraceEnabled()) {
+                logger.trace("Added autowiring by name from bean name '" + beanName +
+                        "' via property '" + propertyName + "' to bean named '" + propertyName + "'");
+            }
+        } else {
+            if (logger.isTraceEnabled()) {
+                logger.trace("Not autowiring property '" + propertyName + "' of bean '" + beanName +
+                        "' by name: no matching bean found");
+            }
+        }
+    }
+}
+```
+
+- `<1>` 处，该方法逻辑很简单，获取该 bean 的非简单属性。**什么叫做非简单属性呢**？就是类型为对象类型的属性，但是这里并不是将所有的对象类型都都会找到，比如 8 个原始类型，String 类型 ，Number类型、Date类型、URL类型、URI类型等都会被忽略。代码如下：
+
+  ```
+  // AbstractAutowireCapableBeanFactory.java
+  
+  protected String[] unsatisfiedNonSimpleProperties(AbstractBeanDefinition mbd, BeanWrapper bw) {
+      // 创建 result 集合
+      Set<String> result = new TreeSet<>();
+      PropertyValues pvs = mbd.getPropertyValues();
+      // 遍历 PropertyDescriptor 数组
+      PropertyDescriptor[] pds = bw.getPropertyDescriptors();
+      for (PropertyDescriptor pd : pds) {
+          if (pd.getWriteMethod() != null // 有可写方法
+                  && !isExcludedFromDependencyCheck(pd) // 依赖检测中没有被忽略
+                  && !pvs.contains(pd.getName()) // pvs 不包含该属性名
+                  && !BeanUtils.isSimpleProperty(pd.getPropertyType())) { // 不是简单属性类型
+              result.add(pd.getName()); // 添加到 result 中
+          }
+      }
+      return StringUtils.toStringArray(result);
+  }
+  ```
+
+  - 过滤**条件**为：有可写方法、依赖检测中没有被忽略、不是简单属性类型。
+  - 过滤**结果**为：其实这里获取的就是需要依赖注入的属性。
+
+- 获取需要依赖注入的属性后，通过迭代、递归的方式初始化相关的 bean ，然后调用 `#registerDependentBean(String beanName, String dependentBeanName)` 方法，完成注册依赖。代码如下：
+
+  ```
+  // DefaultSingletonBeanRegistry.java
+  
+  /**
+   * Map between dependent bean names: bean name to Set of dependent bean names.
+   *
+   * 保存的是依赖 beanName 之间的映射关系：beanName - > 依赖 beanName 的集合
+   */
+  private final Map<String, Set<String>> dependentBeanMap = new ConcurrentHashMap<>(64);
+  
+  /**
+   * Map between depending bean names: bean name to Set of bean names for the bean's dependencies.
+   *
+   * 保存的是依赖 beanName 之间的映射关系：依赖 beanName - > beanName 的集合
+   */
+  private final Map<String, Set<String>> dependenciesForBeanMap = new ConcurrentHashMap<>(64);
+  
+  public void registerDependentBean(String beanName, String dependentBeanName) {
+      // 获取 beanName
+      String canonicalName = canonicalName(beanName);
+      // 添加 <canonicalName, <dependentBeanName>> 到 dependentBeanMap 中
+      synchronized (this.dependentBeanMap) {
+          Set<String> dependentBeans =
+                  this.dependentBeanMap.computeIfAbsent(canonicalName, k -> new LinkedHashSet<>(8));
+          if (!dependentBeans.add(dependentBeanName)) {
+              return;
+          }
+      }
+      // 添加 <dependentBeanName, <canonicalName>> 到 dependenciesForBeanMap 中
+      synchronized (this.dependenciesForBeanMap) {
+          Set<String> dependenciesForBean =
+                  this.dependenciesForBeanMap.computeIfAbsent(dependentBeanName, k -> new LinkedHashSet<>(8));
+          dependenciesForBean.add(canonicalName);
+      }
+  }
+  ```
+
+### 1.1.2 autowireByType
+
+`#autowireByType(String beanName, AbstractBeanDefinition mbd, BeanWrapper bw, MutablePropertyValues pvs)` 方法，是根据**属性类型**，完成自动依赖注入的。代码如下：
+
+```
+// AbstractAutowireCapableBeanFactory.java
+
+protected void autowireByType(String beanName, AbstractBeanDefinition mbd, BeanWrapper bw, MutablePropertyValues pvs) {
+
+    // 获取 TypeConverter 实例
+    // 使用自定义的 TypeConverter，用于取代默认的 PropertyEditor 机制
+    TypeConverter converter = getCustomTypeConverter();
+    if (converter == null) {
+        converter = bw;
+    }
+
+    Set<String> autowiredBeanNames = new LinkedHashSet<>(4);
+    // 获取非简单属性
+    String[] propertyNames = unsatisfiedNonSimpleProperties(mbd, bw);
+    // 遍历 propertyName 数组
+    for (String propertyName : propertyNames) {
+        try {
+            // 获取 PropertyDescriptor 实例
+            PropertyDescriptor pd = bw.getPropertyDescriptor(propertyName);
+            // Don't try autowiring by type for type Object: never makes sense,
+            // even if it technically is a unsatisfied, non-simple property.
+            // 不要尝试按类型
+            if (Object.class != pd.getPropertyType()) {
+                // 探测指定属性的 set 方法
+                MethodParameter methodParam = BeanUtils.getWriteMethodParameter(pd);
+                // Do not allow eager init for type matching in case of a prioritized post-processor.
+                boolean eager = !PriorityOrdered.class.isInstance(bw.getWrappedInstance());
+                DependencyDescriptor desc = new AutowireByTypeDependencyDescriptor(methodParam, eager);
+                // 解析指定 beanName 的属性所匹配的值，并把解析到的属性名称存储在 autowiredBeanNames 中
+                // 当属性存在过个封装 bean 时将会找到所有匹配的 bean 并将其注入
+                Object autowiredArgument = resolveDependency(desc, beanName, autowiredBeanNames, converter);
+                if (autowiredArgument != null) {
+                    pvs.add(propertyName, autowiredArgument);
+                }
+                // 遍历 autowiredBeanName 数组
+                for (String autowiredBeanName : autowiredBeanNames) {
+                    // 属性依赖注入
+                    registerDependentBean(autowiredBeanName, beanName);
+                    if (logger.isTraceEnabled()) {
+                        logger.trace("Autowiring by type from bean name '" + beanName + "' via property '" +
+                                propertyName + "' to bean named '" + autowiredBeanName + "'");
+                    }
+                }
+                // 清空 autowiredBeanName 数组
+                autowiredBeanNames.clear();
+            }
+        } catch (BeansException ex) {
+            throw new UnsatisfiedDependencyException(mbd.getResourceDescription(), beanName, propertyName, ex);
+        }
+    }
+}
+```
+
+- 其实主要过程和根据名称自动注入**差不多**，都是找到需要依赖注入的属性，然后通过迭代的方式寻找所匹配的 bean，最后调用 `#registerDependentBean(...)` 方法，来注册依赖。不过相对于 `#autowireByName(...)` 方法而言，根据类型寻找相匹配的 bean 过程**比较复杂**。
+
+#### 1.1.2.1 resolveDependency
+
+下面我们就分析这个复杂的过程，代码如下：
+
+```
+// DefaultListableBeanFactory.java
+
+@Nullable
+private static Class<?> javaxInjectProviderClass;
+
+static {
+	try {
+		javaxInjectProviderClass = ClassUtils.forName("javax.inject.Provider", DefaultListableBeanFactory.class.getClassLoader());
+	} catch (ClassNotFoundException ex) {
+		// JSR-330 API not available - Provider interface simply not supported then.
+		javaxInjectProviderClass = null;
+	}
+}
+
+@Override
+@Nullable
+public Object resolveDependency(DependencyDescriptor descriptor, @Nullable String requestingBeanName,
+        @Nullable Set<String> autowiredBeanNames, @Nullable TypeConverter typeConverter) throws BeansException {
+    // 初始化参数名称发现器，该方法并不会在这个时候尝试检索参数名称
+    // getParameterNameDiscoverer 返回 parameterNameDiscoverer 实例，parameterNameDiscoverer 方法参数名称的解析器
+    descriptor.initParameterNameDiscovery(getParameterNameDiscoverer());
+    // 依赖类型为 Optional 类型
+    if (Optional.class == descriptor.getDependencyType()) {
+        return createOptionalDependency(descriptor, requestingBeanName);
+    // 依赖类型为ObjectFactory、ObjectProvider
+    } else if (ObjectFactory.class == descriptor.getDependencyType() ||
+            ObjectProvider.class == descriptor.getDependencyType()) {
+        return new DependencyObjectProvider(descriptor, requestingBeanName);
+    // javaxInjectProviderClass 类注入的特殊处理
+    } else if (javaxInjectProviderClass == descriptor.getDependencyType()) {
+        return new Jsr330Factory().createDependencyProvider(descriptor, requestingBeanName);
+    } else {
+        // 为实际依赖关系目标的延迟解析构建代理
+        // 默认实现返回 null
+        Object result = getAutowireCandidateResolver().getLazyResolutionProxyIfNecessary(descriptor, requestingBeanName);
+        if (result == null) {
+            // 通用处理逻辑
+            result = doResolveDependency(descriptor, requestingBeanName, autowiredBeanNames, typeConverter);
+        }
+        return result;
+    }
+}
+```
+
+- 这里我们关注**通用处理逻辑** `#doResolveDependency(DependencyDescriptor descriptor, @Nullable String beanName, Set<String> autowiredBeanNames, TypeConverter typeConverter)` 方法，代码如下：
+
+  ```
+  // DefaultListableBeanFactory.java
+  
+  @Nullable
+  public Object doResolveDependency(DependencyDescriptor descriptor, @Nullable String beanName,
+      @Nullable Set<String> autowiredBeanNames, @Nullable TypeConverter typeConverter) throws BeansException {
+      // 注入点
+      InjectionPoint previousInjectionPoint = ConstructorResolver.setCurrentInjectionPoint(descriptor);
+      try {
+          // 针对给定的工厂给定一个快捷实现的方式，例如考虑一些预先解析的信息
+          // 在进入所有bean的常规类型匹配算法之前，解析算法将首先尝试通过此方法解析快捷方式。
+          // 子类可以覆盖此方法
+          Object shortcut = descriptor.resolveShortcut(this);
+          if (shortcut != null) {
+              // 返回快捷的解析信息
+              return shortcut;
+          }
+          // 依赖的类型
+          Class<?> type = descriptor.getDependencyType();
+          // 支持 Spring 的注解 @value
+          Object value = getAutowireCandidateResolver().getSuggestedValue(descriptor);
+          if (value != null) {
+              if (value instanceof String) {
+                  String strVal = resolveEmbeddedValue((String) value);
+                  BeanDefinition bd = (beanName != null && containsBean(beanName) ? getMergedBeanDefinition(beanName) : null);
+                  value = evaluateBeanDefinitionString(strVal, bd);
+              }
+              TypeConverter converter = (typeConverter != null ? typeConverter : getTypeConverter());
+              return (descriptor.getField() != null ?
+                      converter.convertIfNecessary(value, type, descriptor.getField()) :
+                      converter.convertIfNecessary(value, type, descriptor.getMethodParameter()));
+          }
+          // 解析复合 bean，其实就是对 bean 的属性进行解析
+          // 包括：数组、Collection 、Map 类型
+          Object multipleBeans = resolveMultipleBeans(descriptor, beanName, autowiredBeanNames, typeConverter);
+          if (multipleBeans != null) {
+              return multipleBeans;
+          }
+          // 查找与类型相匹配的 bean
+          // 返回值构成为：key = 匹配的 beanName，value = beanName 对应的实例化 bean
+          Map<String, Object> matchingBeans = findAutowireCandidates(beanName, type, descriptor);
+          // 没有找到，检验 @autowire  的 require 是否为 true
+          if (matchingBeans.isEmpty()) {
+              // 如果 @autowire 的 require 属性为 true ，但是没有找到相应的匹配项，则抛出异常
+              if (isRequired(descriptor)) {
+                  raiseNoMatchingBeanFound(type, descriptor.getResolvableType(), descriptor);
+              }
+              return null;
+          }
+          String autowiredBeanName;
+          Object instanceCandidate;
+          if (matchingBeans.size() > 1) {
+              // 确认给定 bean autowire 的候选者
+              // 按照 @Primary 和 @Priority 的顺序
+              autowiredBeanName = determineAutowireCandidate(matchingBeans, descriptor);
+              if (autowiredBeanName == null) {
+                  if (isRequired(descriptor) || !indicatesMultipleBeans(type)) {
+                      // 唯一性处理
+                      return descriptor.resolveNotUnique(descriptor.getResolvableType(), matchingBeans);
+                  }
+                  else {
+                      // In case of an optional Collection/Map, silently ignore a non-unique case:
+                      // possibly it was meant to be an empty collection of multiple regular beans
+                      // (before 4.3 in particular when we didn't even look for collection beans).
+                      // 在可选的Collection / Map的情况下，默默地忽略一个非唯一的情况：可能它是一个多个常规bean的空集合
+                      return null;
+                  }
+              }
+              instanceCandidate = matchingBeans.get(autowiredBeanName);
+          } else {
+              // We have exactly one match.
+              Map.Entry<String, Object> entry = matchingBeans.entrySet().iterator().next();
+              autowiredBeanName = entry.getKey();
+              instanceCandidate = entry.getValue();
+          }
+          if (autowiredBeanNames != null) {
+              autowiredBeanNames.add(autowiredBeanName);
+          }
+          if (instanceCandidate instanceof Class) {
+              instanceCandidate = descriptor.resolveCandidate(autowiredBeanName, type, this);
+          }
+          Object result = instanceCandidate;
+          if (result instanceof NullBean) {
+              if (isRequired(descriptor)) {
+                  raiseNoMatchingBeanFound(type, descriptor.getResolvableType(), descriptor);
+              }
+              result = null;
+          }
+          if (!ClassUtils.isAssignableValue(type, result)) {
+              throw new BeanNotOfRequiredTypeException(autowiredBeanName, type, instanceCandidate.getClass());
+          }
+          return result;
+      } finally {
+          ConstructorResolver.setCurrentInjectionPoint(previousInjectionPoint);
+      }
+  }
+  ```
+
+  - 代码比较多，胖友调试看看。看懂大体逻辑即可。
+
+------
+
+到这里就已经完成了所有属性的注入了。`populateBean()` 该方法就已经完成了一大半工作了：
+
+- 下一步，则是对依赖 bean 的依赖检测和 PostProcessor 处理，**这个我们后面分析**。
+- 下面，分析该方法的最后一步：`#applyPropertyValues(String beanName, BeanDefinition mbd, BeanWrapper bw, PropertyValues pvs)` 方法。
+
+## 1.2 applyPropertyValues
+
+其实，上面只是完成了所有注入属性的获取，将获取的属性封装在 PropertyValues 的实例对象 `pvs` 中，并没有应用到已经实例化的 bean 中。而 `#applyPropertyValues(String beanName, BeanDefinition mbd, BeanWrapper bw, PropertyValues pvs)` 方法，则是完成这一步骤的。代码如下：
+
+```
+// AbstractAutowireCapableBeanFactory.java
+
+protected void applyPropertyValues(String beanName, BeanDefinition mbd, BeanWrapper bw, PropertyValues pvs) {
+    if (pvs.isEmpty()) {
+        return;
+    }
+
+    // 设置 BeanWrapperImpl 的 SecurityContext 属性
+    if (System.getSecurityManager() != null && bw instanceof BeanWrapperImpl) {
+        ((BeanWrapperImpl) bw).setSecurityContext(getAccessControlContext());
+    }
+
+    // MutablePropertyValues 类型属性
+    MutablePropertyValues mpvs = null;
+
+    // 原始类型
+    List<PropertyValue> original;
+    // 获得 original
+    if (pvs instanceof MutablePropertyValues) {
+        mpvs = (MutablePropertyValues) pvs;
+        // 属性值已经转换
+        if (mpvs.isConverted()) {
+            // Shortcut: use the pre-converted values as-is.
+            try {
+                // 为实例化对象设置属性值 ，依赖注入真真正正地实现在此！！！！！
+                bw.setPropertyValues(mpvs);
+                return;
+            } catch (BeansException ex) {
+                throw new BeanCreationException(
+                        mbd.getResourceDescription(), beanName, "Error setting property values", ex);
+            }
+        }
+        original = mpvs.getPropertyValueList();
+    } else {
+        // 如果 pvs 不是 MutablePropertyValues 类型，则直接使用原始类型
+        original = Arrays.asList(pvs.getPropertyValues());
+    }
+
+    // 获取 TypeConverter = 获取用户自定义的类型转换
+    TypeConverter converter = getCustomTypeConverter();
+    if (converter == null) {
+        converter = bw;
+    }
+
+    // 获取对应的解析器
+    BeanDefinitionValueResolver valueResolver = new BeanDefinitionValueResolver(this, beanName, mbd, converter);
+
+    // Create a deep copy, resolving any references for values.
+    List<PropertyValue> deepCopy = new ArrayList<>(original.size());
+    boolean resolveNecessary = false;
+    // 遍历属性，将属性转换为对应类的对应属性的类型
+    for (PropertyValue pv : original) {
+        // 属性值不需要转换
+        if (pv.isConverted()) {
+            deepCopy.add(pv);
+        // 属性值需要转换
+        } else {
+            String propertyName = pv.getName();
+            Object originalValue = pv.getValue(); // 原始的属性值，即转换之前的属性值
+            Object resolvedValue = valueResolver.resolveValueIfNecessary(pv, originalValue); // 转换属性值，例如将引用转换为IoC容器中实例化对象引用 ！！！！！ 对属性值的解析！！
+            Object convertedValue = resolvedValue; // 转换之后的属性值
+            boolean convertible = bw.isWritableProperty(propertyName) &&
+                    !PropertyAccessorUtils.isNestedOrIndexedProperty(propertyName);  // 属性值是否可以转换
+            // 使用用户自定义的类型转换器转换属性值
+            if (convertible) {
+                convertedValue = convertForProperty(resolvedValue, propertyName, bw, converter);
+            }
+            // Possibly store converted value in merged bean definition,
+            // in order to avoid re-conversion for every created bean instance.
+            // 存储转换后的属性值，避免每次属性注入时的转换工作
+            if (resolvedValue == originalValue) {
+                if (convertible) {
+                    // 设置属性转换之后的值
+                    pv.setConvertedValue(convertedValue);
+                }
+                deepCopy.add(pv);
+            // 属性是可转换的，且属性原始值是字符串类型，且属性的原始类型值不是
+            // 动态生成的字符串，且属性的原始值不是集合或者数组类型
+            } else if (convertible && originalValue instanceof TypedStringValue &&
+                    !((TypedStringValue) originalValue).isDynamic() &&
+                    !(convertedValue instanceof Collection || ObjectUtils.isArray(convertedValue))) {
+                pv.setConvertedValue(convertedValue);
+                deepCopy.add(pv);
+            } else {
+                resolveNecessary = true;
+                // 重新封装属性的值
+                deepCopy.add(new PropertyValue(pv, convertedValue));
+            }
+        }
+    }
+    // 标记属性值已经转换过
+    if (mpvs != null && !resolveNecessary) {
+        mpvs.setConverted();
+    }
+
+    // Set our (possibly massaged) deep copy.
+    // 进行属性依赖注入，依赖注入的真真正正实现依赖的注入方法在此！！！
+    try {
+        bw.setPropertyValues(new MutablePropertyValues(deepCopy));
+    } catch (BeansException ex) {
+        throw new BeanCreationException(
+                mbd.getResourceDescription(), beanName, "Error setting property values", ex);
+    }
+}
+```
+
+总结 `#applyPropertyValues(...)` 方法（完成属性转换）：
+
+- 属性值类型**不需要**转换时，不需要解析属性值，直接准备进行依赖注入。
+- 属性值**需要**进行类型转换时，如对其他对象的引用等，首先需要解析属性值，然后对解析后的属性值进行依赖注入。
+
+而且，我们看到调用了 `#resolveValueIfNecessary(...)`方法对属性值的解析。详细解析，可见 [《Spring应用、原理以及粗读源码系列（一）–框架总述、以Bean为核心的机制（IoC容器初始化以及依赖注入）》](https://blog.csdn.net/Jack__Frost/article/details/70229593) 的 [「7. 追踪 resolveValueIfNecessary ，发现是在 BeanDefinitionValueResolver 类」](https://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-4/#) 。
+
+# 2. 小结
+
+至此，`#doCreateBean(...)` 方法的第二个过程：**属性填充**已经分析完成了，下篇分析第三个过程：**循环依赖的处理**。其实，循环依赖并不仅仅只是在 `#doCreateBean(...)` 方法中处理，在整个加载 bean 的过程中都有涉及。所以下篇内容并不仅仅只局限于 `#doCreateBean(...)` 方法。
\ No newline at end of file
diff --git a/spring/28-Spring-IoC 之加载 Bean：创建 Bean（五）之循环依赖处理.assets/01.png b/spring/28-Spring-IoC 之加载 Bean：创建 Bean（五）之循环依赖处理.assets/01.png
new file mode 100644
index 0000000..1458674
Binary files /dev/null and b/spring/28-Spring-IoC 之加载 Bean：创建 Bean（五）之循环依赖处理.assets/01.png differ
diff --git a/spring/28-Spring-IoC 之加载 Bean：创建 Bean（五）之循环依赖处理.assets/20170912082357749.jpeg b/spring/28-Spring-IoC 之加载 Bean：创建 Bean（五）之循环依赖处理.assets/20170912082357749.jpeg
new file mode 100644
index 0000000..55907a6
Binary files /dev/null and b/spring/28-Spring-IoC 之加载 Bean：创建 Bean（五）之循环依赖处理.assets/20170912082357749.jpeg differ
diff --git a/spring/28-Spring-IoC 之加载 Bean：创建 Bean（五）之循环依赖处理.assets/20170912091609918.jpeg b/spring/28-Spring-IoC 之加载 Bean：创建 Bean（五）之循环依赖处理.assets/20170912091609918.jpeg
new file mode 100644
index 0000000..d86e627
Binary files /dev/null and b/spring/28-Spring-IoC 之加载 Bean：创建 Bean（五）之循环依赖处理.assets/20170912091609918.jpeg differ
diff --git a/spring/28-Spring-IoC 之加载 Bean：创建 Bean（五）之循环依赖处理.md b/spring/28-Spring-IoC 之加载 Bean：创建 Bean（五）之循环依赖处理.md
new file mode 100644
index 0000000..379593f
--- /dev/null
+++ b/spring/28-Spring-IoC 之加载 Bean：创建 Bean（五）之循环依赖处理.md	
@@ -0,0 +1,321 @@
+# 【死磕 Spring】—— IoC 之加载 Bean：创建 Bean（五）之循环依赖处理
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=todo 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+> 友情提示：本文建议重点阅读，因为 Spring 如何解决循环依赖，是 Spring IOC 相关的面试题中最高频的面试题之一。
+>
+> 需要搞懂两个点：为什么需要二级缓存？为什么需要三级缓存？
+
+这篇分析 `#doCreateBean(...)` 方法的**第三个**过程：**循环依赖处理**。其实，循环依赖并不仅仅只是在 `#doCreateBean(...)` 方法中处理，而是在整个加载 bean 的过程中都有涉及。所以，本文内容并不仅仅只局限于 `#doCreateBean(...)` 方法，而是从整个 Bean 的加载过程进行分析。
+
+# 1. 什么是循环依赖
+
+循环依赖，其实就是循环引用，就是两个或者两个以上的 bean 互相引用对方，最终形成一个闭环，如 A 依赖 B，B 依赖 C，C 依赖 A。如下图所示：
+
+[![循环依赖](28-Spring-IoC 之加载 Bean：创建 Bean（五）之循环依赖处理.assets/20170912082357749.jpeg)](http://static.iocoder.cn/20170912082357749.jpeg)循环依赖
+
+循环依赖，其实就是一个**死循环**的过程，在初始化 A 的时候发现引用了 B，这时就会去初始化 B，然后又发现 B 引用 C，跑去初始化 C，初始化 C 的时候发现引用了 A，则又会去初始化 A，依次循环永不退出，除非有**终结条件**。
+
+Spring 循环依赖的**场景**有两种：
+
+1. 构造器的循环依赖。
+2. field 属性的循环依赖。
+
+对于构造器的循环依赖，Spring 是无法解决的，只能抛出 BeanCurrentlyInCreationException 异常表示循环依赖，**所以下面我们分析的都是基于 field 属性的循环依赖**。
+
+在博客 [《【【死磕 Spring】—— IoC 之开启 Bean 的加载》](http://svip.iocoder.cn/Spring/IoC-get-Bean-begin) 中提到，Spring 只解决 scope 为 singleton 的循环依赖。对于scope 为 prototype 的 bean ，Spring 无法解决，直接抛出 BeanCurrentlyInCreationException 异常。
+
+为什么 Spring 不处理 prototype bean 呢？其实如果理解 Spring 是如何解决 singleton bean 的循环依赖就明白了。这里先卖一个关子，我们先来关注 Spring 是如何解决 singleton bean 的循环依赖的。
+
+# 2. 解决循环依赖
+
+## 2.1 getSingleton
+
+我们先从加载 bean 最初始的方法 AbstractBeanFactory 的 `#doGetBean(final String name, final Class<T> requiredType, final Object[] args, boolean typeCheckOnly)` 方法开始。
+
+在 `#doGetBean(...)` 方法中，首先会根据 `beanName` 从单例 bean 缓存中获取，**如果不为空则直接返回**。代码如下：
+
+```
+// AbstractBeanFactory.java
+
+Object sharedInstance = getSingleton(beanName);
+```
+
+- 调用 `#getSingleton(String beanName, boolean allowEarlyReference)` 方法，从单例缓存中获取。代码如下：
+
+  ```
+  // DefaultSingletonBeanRegistry.java
+  
+  @Nullable
+  protected Object getSingleton(String beanName, boolean allowEarlyReference) {
+      // 从单例缓冲中加载 bean
+      Object singletonObject = this.singletonObjects.get(beanName);
+      // 缓存中的 bean 为空，且当前 bean 正在创建
+      if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
+          // 加锁
+          synchronized (this.singletonObjects) {
+              // 从 earlySingletonObjects 获取
+              singletonObject = this.earlySingletonObjects.get(beanName);
+              // earlySingletonObjects 中没有，且允许提前创建
+              if (singletonObject == null && allowEarlyReference) {
+                  // 从 singletonFactories 中获取对应的 ObjectFactory
+                  ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
+                  if (singletonFactory != null) {
+                      // 获得 bean
+                      singletonObject = singletonFactory.getObject();
+                      // 添加 bean 到 earlySingletonObjects 中
+                      this.earlySingletonObjects.put(beanName, singletonObject);
+                      // 从 singletonFactories 中移除对应的 ObjectFactory
+                      this.singletonFactories.remove(beanName);
+                  }
+              }
+          }
+      }
+      return singletonObject;
+  }
+  ```
+
+  - 这个方法主要是从三个缓存中获取，分别是：`singletonObjects`、`earlySingletonObjects`、`singletonFactories` 。三者定义如下：
+
+    ```
+    // DefaultSingletonBeanRegistry.java
+            
+    /**
+     * Cache of singleton objects: bean name to bean instance.
+     *
+     * 一级缓存，存放的是单例 bean 的映射。
+     *
+     * 注意，这里的 bean 是已经创建完成的。
+     *
+     * 对应关系为 bean name --> bean instance
+     */
+    private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);
+        
+    /**
+     * Cache of early singleton objects: bean name to bean instance.
+     *
+     * 二级缓存，存放的是早期半成品（未初始化完）的 bean，对应关系也是 bean name --> bean instance。
+     *
+     * 它与 {@link #singletonObjects} 区别在于， 它自己存放的 bean 不一定是完整。
+     *
+     * 这个 Map 也是【循环依赖】的关键所在。
+     */
+    private final Map<String, Object> earlySingletonObjects = new HashMap<>(16);
+        
+    /**
+     * Cache of singleton factories: bean name to ObjectFactory.
+     *
+     * 三级缓存，存放的是 ObjectFactory，可以理解为创建早期半成品（未初始化完）的 bean 的 factory ，最终添加到二级缓存 {@link #earlySingletonObjects} 中
+     *
+     * 对应关系是 bean name --> ObjectFactory
+     *
+     * 这个 Map 也是【循环依赖】的关键所在。
+     */
+    private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16);
+    ```
+
+    - `singletonObjects` ：单例对象的 Cache 。
+    - `earlySingletonObjects` ：**提前曝光**的单例对象的 Cache 。
+    - `singletonFactories` ： 单例对象工厂的 Cache 。
+
+它们三，就是 Spring 解决 singleton bean 的关键因素所在，我称他们为**三级缓存**：
+
+- 第一级为 `singletonObjects`
+- 第二级为 `earlySingletonObjects`
+- 第三级为 `singletonFactories`
+
+这里，我们已经通过 `#getSingleton(String beanName, boolean allowEarlyReference)` 方法，看到他们是如何配合的。详细分析该方法之前，提下其中的 `#isSingletonCurrentlyInCreation(String beanName)` 方法和 `allowEarlyReference` 变量：
+
+- `#isSingletonCurrentlyInCreation(String beanName)` 方法：判断当前 singleton bean 是否处于创建中。bean 处于创建中，也就是说 bean 在初始化但是没有完成初始化，有一个这样的过程其实和 Spring 解决 bean 循环依赖的理念相辅相成。**因为 Spring 解决 singleton bean 的核心就在于提前曝光 bean** 。
+- `allowEarlyReference` 变量：从字面意思上面理解就是允许提前拿到引用。其实真正的意思是，是否允许从 `singletonFactories` 缓存中通过 `#getObject()` 方法，拿到对象。为什么会有这样一个字段呢？**原因就在于 `singletonFactories` 才是 Spring 解决 singleton bean 的诀窍所在**，这个我们后续分析。
+
+------
+
+`#getSingleton(String beanName, boolean allowEarlyReference)` 方法，整个过程如下：
+
+- 首先，从一级缓存 `singletonObjects` 获取。
+
+- 如果，没有且当前指定的 `beanName` 正在创建，就再从二级缓存 `earlySingletonObjects` 中获取。
+
+- 如果，还是没有获取到且允许 `singletonFactories` 通过 `#getObject()` 获取，则从三级缓存 `singletonFactories` 获取。如果获取到，则通过其 `#getObject()` 方法，获取对象，并将其加入到二级缓存 `earlySingletonObjects` 中，并从三级缓存 `singletonFactories` 删除。代码如下：
+
+  ```
+  // DefaultSingletonBeanRegistry.java
+  
+  singletonObject = singletonFactory.getObject();
+  this.earlySingletonObjects.put(beanName, singletonObject);
+  this.singletonFactories.remove(beanName);
+  ```
+
+  - 这样，就从三级缓存**升级**到二级缓存了。
+  - 😈 所以，二级缓存存在的**意义**，就是缓存三级缓存中的 ObjectFactory 的 `#getObject()` 方法的执行结果，提早曝光的**单例** Bean 对象。
+
+## 2.2 addSingletonFactory
+
+上面是从缓存中获取，但是缓存中的数据从哪里添加进来的呢？一直往下跟会发现在 AbstractAutowireCapableBeanFactory 的 `#doCreateBean(final String beanName, final RootBeanDefinition mbd, final Object[] args)` 方法中，有这么一段代码：
+
+```
+// AbstractAutowireCapableBeanFactory.java
+
+boolean earlySingletonExposure = (mbd.isSingleton() // 单例模式
+        && this.allowCircularReferences // 运行循环依赖
+        && isSingletonCurrentlyInCreation(beanName)); // 当前单例 bean 是否正在被创建
+if (earlySingletonExposure) {
+    if (logger.isTraceEnabled()) {
+        logger.trace("Eagerly caching bean '" + beanName +
+                "' to allow for resolving potential circular references");
+    }
+    // 提前将创建的 bean 实例加入到 singletonFactories 中
+    // <X> 这里是为了后期避免循环依赖
+    addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
+}
+```
+
+- 当一个 Bean 满足三个条件时，则调用
+
+   
+
+  ```
+  #addSingletonFactory(...)
+  ```
+
+   
+
+  方法，将它添加到缓存中。三个条件如下：
+
+  - 单例
+  - 运行提前暴露 bean
+  - 当前 bean 正在创建中
+
+- `#addSingletonFactory(String beanName, ObjectFactory<?> singletonFactory)` 方法，代码如下：
+
+  ```
+  // DefaultSingletonBeanRegistry.java
+  
+  protected void addSingletonFactory(String beanName, ObjectFactory<?> singletonFactory) {
+  	Assert.notNull(singletonFactory, "Singleton factory must not be null");
+  	synchronized (this.singletonObjects) {
+  		if (!this.singletonObjects.containsKey(beanName)) {
+  			this.singletonFactories.put(beanName, singletonFactory);
+  			this.earlySingletonObjects.remove(beanName);
+  			this.registeredSingletons.add(beanName);
+  		}
+  	}
+  }
+  ```
+
+  - 从这段代码我们可以看出，`singletonFactories` 这个三级缓存才是解决 Spring Bean 循环依赖的诀窍所在。同时这段代码发生在 `#createBeanInstance(...)` 方法之后，也就是说这个 bean 其实已经被创建出来了，**但是它还不是很完美（没有进行属性填充和初始化），但是对于其他依赖它的对象而言已经足够了（可以根据对象引用定位到堆中对象），能够被认出来了**。所以 Spring 在这个时候，选择将该对象提前曝光出来让大家认识认识。
+
+另外，`<X>` 处的 `#getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean)` 方法也**非常重要**，这里会创建早期初始化 Bean 可能存在的 AOP 代理等等。代码如下：
+
+```
+// AbstractAutowireCapableBeanFactory.java
+
+/**
+ * 对创建的早期半成品（未初始化）的 Bean 处理引用
+ *
+ * 例如说，AOP 就是在这里动态织入，创建其代理 Bean 返回
+ *
+ * Obtain a reference for early access to the specified bean,
+ * typically for the purpose of resolving a circular reference.
+ * @param beanName the name of the bean (for error handling purposes)
+ * @param mbd the merged bean definition for the bean
+ * @param bean the raw bean instance
+ * @return the object to expose as bean reference
+ */
+protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
+	Object exposedObject = bean;
+	if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
+		for (BeanPostProcessor bp : getBeanPostProcessors()) {
+			if (bp instanceof SmartInstantiationAwareBeanPostProcessor) {
+				SmartInstantiationAwareBeanPostProcessor ibp = (SmartInstantiationAwareBeanPostProcessor) bp;
+				exposedObject = ibp.getEarlyBeanReference(exposedObject, beanName);
+			}
+		}
+	}
+	return exposedObject;
+}
+```
+
+- 这也是为什么 Spring 需要额外增加 `singletonFactories` 三级缓存的原因，解决 Spring 循环依赖情况下的 Bean 存在动态代理等情况，不然循环注入到别人的 Bean 就是原始的，而不是经过动态代理的！
+- 另外，这里在推荐一篇[《Spring循环依赖三级缓存是否可以减少为二级缓存？》](https://segmentfault.com/a/1190000023647227)文章，解释的也非常不错。
+
+## 2.3 addSingleton
+
+介绍到这里我们发现三级缓存 `singletonFactories` 和 二级缓存 `earlySingletonObjects` 中的值都有出处了，那一级缓存在哪里设置的呢？在类 DefaultSingletonBeanRegistry 中，可以发现这个 `#addSingleton(String beanName, Object singletonObject)` 方法，代码如下：
+
+```
+// DefaultSingletonBeanRegistry.java
+
+protected void addSingleton(String beanName, Object singletonObject) {
+	synchronized (this.singletonObjects) {
+		this.singletonObjects.put(beanName, singletonObject);
+		this.singletonFactories.remove(beanName);
+		this.earlySingletonObjects.remove(beanName);
+		this.registeredSingletons.add(beanName);
+	}
+}
+```
+
+- 添加至一级缓存，同时从二级、三级缓存中删除。
+
+- 这个方法在我们创建 bean 的链路中有哪个地方引用呢？其实在前面博客 LZ 已经提到过了，在 `#doGetBean(...)` 方法中，处理不同 scope 时，如果是 singleton，则调用 `#getSingleton(...)` 方法，如下图所示：
+
+  [![getSingleton](28-Spring-IoC 之加载 Bean：创建 Bean（五）之循环依赖处理.assets/20170912091609918.jpeg)](http://static.iocoder.cn/20170912091609918.jpeg)getSingleton
+
+- 前面几篇博客已经分析了 `#createBean(...)` 方法，这里就不再阐述了，我们关注 `#getSingleton(String beanName, ObjectFactory<?> singletonFactory)` 方法，代码如下：
+
+  ```
+  // AbstractBeanFactory.java
+  
+  public Object getSingleton(String beanName, ObjectFactory<?> singletonFactory) {
+      Assert.notNull(beanName, "Bean name must not be null");
+      synchronized (this.singletonObjects) {
+          Object singletonObject = this.singletonObjects.get(beanName);
+          if (singletonObject == null) {
+              //....
+              try {
+                  singletonObject = singletonFactory.getObject();
+                  newSingleton = true;
+              }
+              //.....
+              if (newSingleton) {
+                  addSingleton(beanName, singletonObject);
+              }
+          }
+          return singletonObject;
+      }
+  }
+  ```
+
+  - 😈 注意，此处的 `#getSingleton(String beanName, ObjectFactory<?> singletonFactory)` 方法，在 AbstractBeanFactory 类中实现，和 [「2.1 getSingleton」](https://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-5/#) **不同**。
+
+# 3. 小结
+
+至此，Spring 关于 singleton bean 循环依赖已经分析完毕了。所以我们基本上可以确定 Spring 解决循环依赖的方案了：
+
+- Spring 在创建 bean 的时候并不是等它完全完成，而是在创建过程中将创建中的 bean 的 ObjectFactory 提前曝光（即加入到 `singletonFactories` 缓存中）。
+- 这样，一旦下一个 bean 创建的时候需要依赖 bean ，则直接使用 ObjectFactory 的 `#getObject()` 方法来获取了，也就是 [「2.1 getSingleton」](https://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-5/#) 小结中的方法中的代码片段了。
+
+到这里，关于 Spring 解决 bean 循环依赖就已经分析完毕了。最后来描述下就上面那个循环依赖 Spring 解决的过程：
+
+- 首先 A 完成初始化第一步并将自己提前曝光出来（通过 ObjectFactory 将自己提前曝光），在初始化的时候，发现自己依赖对象 B，此时就会去尝试 get(B)，这个时候发现 B 还没有被创建出来
+- 然后 B 就走创建流程，在 B 初始化的时候，同样发现自己依赖 C，C 也没有被创建出来
+- 这个时候 C 又开始初始化进程，但是在初始化的过程中发现自己依赖 A，于是尝试 get(A)，这个时候由于 A 已经添加至缓存中（一般都是添加至三级缓存 `singletonFactories` ），通过 ObjectFactory 提前曝光，所以可以通过 `ObjectFactory#getObject()` 方法来拿到 A 对象，C 拿到 A 对象后顺利完成初始化，然后将自己添加到一级缓存中
+- 回到 B ，B 也可以拿到 C 对象，完成初始化，A 可以顺利拿到 B 完成初始化。到这里整个链路就已经完成了初始化过程了
+
+> 老艿艿的建议
+>
+> 可能逻辑干看比较绕，胖友可以拿出一个草稿纸，画一画上面提到的 A、B、C 初始化的过程。
+>
+> 相信，胖友会很快明白了。
+>
+> 如下是《Spring 源码深度解析》P114 页的一张图，非常有助于理解。
+>
+> [![处理依赖循环](28-Spring-IoC 之加载 Bean：创建 Bean（五）之循环依赖处理.assets/01.png)](http://static.iocoder.cn/images/Spring/2019-06-13/01.png)处理依赖循环
\ No newline at end of file
diff --git a/spring/29-Spring-IoC 之加载 Bean：创建 Bean（六）之初始化 Bean 对象.md b/spring/29-Spring-IoC 之加载 Bean：创建 Bean（六）之初始化 Bean 对象.md
new file mode 100644
index 0000000..3a27cc4
--- /dev/null
+++ b/spring/29-Spring-IoC 之加载 Bean：创建 Bean（六）之初始化 Bean 对象.md	
@@ -0,0 +1,220 @@
+# 【死磕 Spring】—— IoC 之加载 Bean：创建 Bean（六）之初始化 Bean 对象
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=todo 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+一个 bean 经历了 `#createBeanInstance(String beanName, RootBeanDefinition mbd, Object[] args)` 方法，被创建出来，然后又经过一番属性注入，依赖处理，历经千辛万苦，千锤百炼，终于有点儿 bean 实例的样子，能堪大任了，只需要经历最后一步就破茧成蝶了。
+
+这**最后一步**就是初始化，也就是 `#initializeBean(final String beanName, final Object bean, RootBeanDefinition mbd)` 方法。所以，这篇文章我们分析 `#doCreateBean(...)` 方法的中最后一步：初始化 bean 对象。
+
+# 1. initializeBean
+
+```
+// AbstractAutowireCapableBeanFactory.java
+
+protected Object initializeBean(final String beanName, final Object bean, @Nullable RootBeanDefinition mbd) {
+    if (System.getSecurityManager() != null) { // 安全模式
+        AccessController.doPrivileged((PrivilegedAction<Object>) () -> {
+            // <1> 激活 Aware 方法，对特殊的 bean 处理：Aware、BeanClassLoaderAware、BeanFactoryAware
+            invokeAwareMethods(beanName, bean);
+            return null;
+        }, getAccessControlContext());
+    } else {
+        // <1> 激活 Aware 方法，对特殊的 bean 处理：Aware、BeanClassLoaderAware、BeanFactoryAware
+        invokeAwareMethods(beanName, bean);
+    }
+
+    // <2> 后处理器，before
+    Object wrappedBean = bean;
+    if (mbd == null || !mbd.isSynthetic()) {
+        wrappedBean = applyBeanPostProcessorsBeforeInitialization(wrappedBean, beanName);
+    }
+
+    // <3> 激活用户自定义的 init 方法
+    try {
+        invokeInitMethods(beanName, wrappedBean, mbd);
+    } catch (Throwable ex) {
+        throw new BeanCreationException(
+                (mbd != null ? mbd.getResourceDescription() : null),
+                beanName, "Invocation of init method failed", ex);
+    }
+
+    // <2> 后处理器，after
+    if (mbd == null || !mbd.isSynthetic()) {
+        wrappedBean = applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName);
+    }
+
+    return wrappedBean;
+}
+```
+
+初始化 bean 的方法其实就是三个步骤的处理，而这三个步骤主要还是根据**用户设定**的来进行初始化，这三个过程为：
+
+- `<1>` 激活 Aware 方法。
+- `<3>` 后置处理器的应用。
+- `<2>` 激活自定义的 init 方法。
+
+## 1.1 激活 Aware 方法
+
+Aware ，英文翻译是意识到的，感知的。Spring 提供了诸多 Aware 接口，用于辅助 Spring Bean 以编程的方式调用 Spring 容器，通过实现这些接口，可以增强 Spring Bean 的功能。
+
+Spring 提供了如下系列的 Aware 接口：
+
+- LoadTimeWeaverAware：加载Spring Bean时织入第三方模块，如AspectJ
+- BeanClassLoaderAware：加载Spring Bean的类加载器
+- BootstrapContextAware：资源适配器BootstrapContext，如JCA,CCI
+- ResourceLoaderAware：底层访问资源的加载器
+- BeanFactoryAware：声明BeanFactory
+- PortletConfigAware：PortletConfig
+- PortletContextAware：PortletContext
+- ServletConfigAware：ServletConfig
+- ServletContextAware：ServletContext
+- MessageSourceAware：国际化
+- ApplicationEventPublisherAware：应用事件
+- NotificationPublisherAware：JMX通知
+- BeanNameAware：声明Spring Bean的名字
+
+------
+
+`#invokeAwareMethods(final String beanName, final Object bean)` 方法，代码如下：
+
+```
+// AbstractAutowireCapableBeanFactory.java
+
+private void invokeAwareMethods(final String beanName, final Object bean) {
+    if (bean instanceof Aware) {
+        // BeanNameAware
+        if (bean instanceof BeanNameAware) {
+            ((BeanNameAware) bean).setBeanName(beanName);
+        }
+        // BeanClassLoaderAware
+        if (bean instanceof BeanClassLoaderAware) {
+            ClassLoader bcl = getBeanClassLoader();
+            if (bcl != null) {
+                ((BeanClassLoaderAware) bean).setBeanClassLoader(bcl);
+            }
+        }
+        // BeanFactoryAware
+        if (bean instanceof BeanFactoryAware) {
+            ((BeanFactoryAware) bean).setBeanFactory(AbstractAutowireCapableBeanFactory.this);
+        }
+    }
+}
+```
+
+这里代码就没有什么好说的，主要是处理 BeanNameAware、BeanClassLoaderAware、BeanFactoryAware 。
+
+关于 Aware 接口，后面会专门出篇文章对其进行详细分析说明的。
+
+## 1.2 后置处理器的应用
+
+BeanPostProcessor 在前面介绍 bean 加载的过程曾多次遇到，相信各位不陌生，这是 Spring 中开放式框架中必不可少的一个亮点。
+
+BeanPostProcessor 的作用是：如果我们想要在 Spring 容器完成 Bean 的实例化，配置和其他的初始化后添加一些自己的逻辑处理，那么请使用该接口，这个接口给与了用户充足的权限去更改或者扩展 Spring，是我们对 Spring 进行扩展和增强处理一个必不可少的接口。
+
+- `#applyBeanPostProcessorsBeforeInitialization(...)` 方法，代码如下：
+
+  ```
+  // AbstractAutowireCapableBeanFactory.java
+  
+  @Override
+  public Object applyBeanPostProcessorsBeforeInitialization(Object existingBean, String beanName)
+          throws BeansException {
+      Object result = existingBean;
+      // 遍历 BeanPostProcessor 数组
+      for (BeanPostProcessor processor : getBeanPostProcessors()) {
+          // 处理
+          Object current = processor.postProcessBeforeInitialization(result, beanName);
+          // 返回空，则返回 result
+          if (current == null) {
+              return result;
+          }
+          // 修改 result
+          result = current;
+      }
+      return result;
+  }
+  ```
+
+- `#applyBeanPostProcessorsAfterInitialization(...)` 方法，代码如下：
+
+  ```
+  // AbstractAutowireCapableBeanFactory.java
+  
+  @Override
+  public Object applyBeanPostProcessorsAfterInitialization(Object existingBean, String beanName)
+          throws BeansException {
+      Object result = existingBean;
+      // 遍历 BeanPostProcessor
+      for (BeanPostProcessor processor : getBeanPostProcessors()) {
+          // 处理
+          Object current = processor.postProcessAfterInitialization(result, beanName);
+          // 返回空，则返回 result
+          if (current == null) {
+              return result;
+          }
+          // 修改 result
+          result = current;
+      }
+      return result;
+  }
+  ```
+
+其实，逻辑就是通过 `#getBeanPostProcessors()` 方法，获取定义的 BeanPostProcessor ，然后分别调用其 `#postProcessBeforeInitialization(...)`、`#postProcessAfterInitialization(...)` 方法，进行**自定义**的业务处理。
+
+## 1.3 激活自定义的 init 方法
+
+如果熟悉 `<bean>` 标签的配置，一定不会忘记 `init-method` 方法，该方法的执行就是在这里执行的。代码如下：
+
+```
+// AbstractAutowireCapableBeanFactory.java
+
+protected void invokeInitMethods(String beanName, final Object bean, @Nullable RootBeanDefinition mbd)
+        throws Throwable {
+    // 首先会检查是否是 InitializingBean ，如果是的话需要调用 afterPropertiesSet()
+    boolean isInitializingBean = (bean instanceof InitializingBean);
+    if (isInitializingBean && (mbd == null || !mbd.isExternallyManagedInitMethod("afterPropertiesSet"))) {
+        if (logger.isTraceEnabled()) {
+            logger.trace("Invoking afterPropertiesSet() on bean with name '" + beanName + "'");
+        }
+        if (System.getSecurityManager() != null) { // 安全模式
+            try {
+                AccessController.doPrivileged((PrivilegedExceptionAction<Object>) () -> {
+                    // <1> 属性初始化的处理
+                    ((InitializingBean) bean).afterPropertiesSet();
+                    return null;
+                }, getAccessControlContext());
+            } catch (PrivilegedActionException pae) {
+                throw pae.getException();
+            }
+        } else {
+            // <1> 属性初始化的处理
+            ((InitializingBean) bean).afterPropertiesSet();
+        }
+    }
+
+    if (mbd != null && bean.getClass() != NullBean.class) {
+        String initMethodName = mbd.getInitMethodName();
+        if (StringUtils.hasLength(initMethodName) &&
+                !(isInitializingBean && "afterPropertiesSet".equals(initMethodName)) &&
+                !mbd.isExternallyManagedInitMethod(initMethodName)) {
+            // <2> 激活用户自定义的初始化方法
+            invokeCustomInitMethod(beanName, bean, mbd);
+        }
+    }
+}
+```
+
+- 首先，检查是否为 InitializingBean 。如果**是**的话，需要执行 `#afterPropertiesSet()` 方法，因为我们除了可以使用 `init-method` 来自定初始化方法外，还可以实现 InitializingBean 接口。接口仅有一个 `#afterPropertiesSet()` 方法。
+- 两者的执行先后顺序是先 `<1>` 的 `#afterPropertiesSet()` 方法，后 `<2>` 的 `init-method` 对应的方法。
+
+# 2. 小结
+
+关于这篇博客的三个方法，LZ 后面会单独写博客来进行分析说明。
+
+经过六篇博客终于把 Spring 创建 bean 的过程进行详细说明了，过程是艰辛的，但是收获很大，关键还是要耐着性子看。
\ No newline at end of file
diff --git a/spring/30-Spring-IoC 之加载 Bean：总结.md b/spring/30-Spring-IoC 之加载 Bean：总结.md
new file mode 100644
index 0000000..29416a3
--- /dev/null
+++ b/spring/30-Spring-IoC 之加载 Bean：总结.md	
@@ -0,0 +1,883 @@
+# 【死磕 Spring】—— IoC 之加载 Bean：总结
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=todo 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+在 【死磕 Spring】 Spring bean 解析篇深入分析了一个配置文件经历了哪些过程转变成了 BeanDefinition，但是这个 BeanDefinition 并不是我们真正想要的想要的 bean，因为它还仅仅只是承载了我们需要的目标 bean 的信息。
+
+从 BeanDefinition 到我们需要的目标还需要一个漫长的 bean 的初始化阶段，在 【死磕 Spring】 Spring bean 加载阶段已经详细分析了初始化 bean 的过程，**所以这里做一个概括性的总结**。
+
+bean 的初始化节点，由第一次(显式或者隐式)调用 `#getBean(...)` 方法来开启，所以我们从这个方法开始。代码如下：
+
+```
+// AbstractBeanFactory.java
+
+public Object getBean(String name) throws BeansException {
+    return doGetBean(name, null, null, false);
+}
+
+protected <T> T doGetBean(final String name, @Nullable final Class<T> requiredType,
+        @Nullable final Object[] args, boolean typeCheckOnly) throws BeansException {
+    // <1> 返回 bean 名称，剥离工厂引用前缀。
+    // 如果 name 是 alias ，则获取对应映射的 beanName 。
+    final String beanName = transformedBeanName(name);
+    Object bean;
+
+    // 从缓存中或者实例工厂中获取 Bean 对象
+    // Eagerly check singleton cache for manually registered singletons.
+    Object sharedInstance = getSingleton(beanName);
+    if (sharedInstance != null && args == null) {
+        if (logger.isTraceEnabled()) {
+            if (isSingletonCurrentlyInCreation(beanName)) {
+                logger.trace("Returning eagerly cached instance of singleton bean '" + beanName +
+                        "' that is not fully initialized yet - a consequence of a circular reference");
+            } else {
+                logger.trace("Returning cached instance of singleton bean '" + beanName + "'");
+            }
+        }
+        // <2> 完成 FactoryBean 的相关处理，并用来获取 FactoryBean 的处理结果
+        bean = getObjectForBeanInstance(sharedInstance, name, beanName, null);
+    } else {
+        // Fail if we're already creating this bean instance:
+        // We're assumably within a circular reference.
+        // <3> 因为 Spring 只解决单例模式下得循环依赖，在原型模式下如果存在循环依赖则会抛出异常。
+        if (isPrototypeCurrentlyInCreation(beanName)) {
+            throw new BeanCurrentlyInCreationException(beanName);
+        }
+
+        // <4> 如果容器中没有找到，则从父类容器中加载
+        // Check if bean definition exists in this factory.
+        BeanFactory parentBeanFactory = getParentBeanFactory();
+        if (parentBeanFactory != null && !containsBeanDefinition(beanName)) {
+            // Not found -> check parent.
+            String nameToLookup = originalBeanName(name);
+            if (parentBeanFactory instanceof AbstractBeanFactory) {
+                return ((AbstractBeanFactory) parentBeanFactory).doGetBean(
+                        nameToLookup, requiredType, args, typeCheckOnly);
+            } else if (args != null) {
+                // Delegation to parent with explicit args.
+                return (T) parentBeanFactory.getBean(nameToLookup, args);
+            } else if (requiredType != null) {
+                // No args -> delegate to standard getBean method.
+                return parentBeanFactory.getBean(nameToLookup, requiredType);
+            } else {
+                return (T) parentBeanFactory.getBean(nameToLookup);
+            }
+        }
+
+        // <5> 如果不是仅仅做类型检查则是创建bean，这里需要记录 
+        if (!typeCheckOnly) {
+            markBeanAsCreated(beanName);
+        }
+
+        try {
+            // <6> 从容器中获取 beanName 相应的 GenericBeanDefinition 对象，并将其转换为 RootBeanDefinition 对象
+            final RootBeanDefinition mbd = getMergedLocalBeanDefinition(beanName);
+            // 检查给定的合并的 BeanDefinition
+            checkMergedBeanDefinition(mbd, beanName, args);
+
+            // Guarantee initialization of beans that the current bean depends on.
+            // <7> 处理所依赖的 bean
+            String[] dependsOn = mbd.getDependsOn();
+            if (dependsOn != null) {
+                for (String dep : dependsOn) {
+                    // 若给定的依赖 bean 已经注册为依赖给定的 bean
+                    // 循环依赖的情况
+                    if (isDependent(beanName, dep)) {
+                        throw new BeanCreationException(mbd.getResourceDescription(), beanName,
+                                "Circular depends-on relationship between '" + beanName + "' and '" + dep + "'");
+                    }
+                    // 缓存依赖调用 TODO 芋艿
+                    registerDependentBean(dep, beanName);
+                    try {
+                        getBean(dep);
+                    } catch (NoSuchBeanDefinitionException ex) {
+                        throw new BeanCreationException(mbd.getResourceDescription(), beanName,
+                                "'" + beanName + "' depends on missing bean '" + dep + "'", ex);
+                    }
+                }
+            }
+
+            // <8> bean 实例化
+            // Create bean instance.
+            if (mbd.isSingleton()) { // 单例模式
+                sharedInstance = getSingleton(beanName, () -> {
+                    try {
+                        return createBean(beanName, mbd, args);
+                    }
+                    catch (BeansException ex) {
+                        // Explicitly remove instance from singleton cache: It might have been put there
+                        // eagerly by the creation process, to allow for circular reference resolution.
+                        // Also remove any beans that received a temporary reference to the bean.
+                        // 显式从单例缓存中删除 Bean 实例
+                        // 因为单例模式下为了解决循环依赖，可能他已经存在了，所以销毁它。 TODO 芋艿
+                        destroySingleton(beanName);
+                        throw ex;
+                    }
+                });
+                bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
+            } else if (mbd.isPrototype()) { // 原型模式
+                // It's a prototype -> create a new instance.
+                Object prototypeInstance;
+                try {
+                    beforePrototypeCreation(beanName);
+                    prototypeInstance = createBean(beanName, mbd, args);
+                } finally {
+                    afterPrototypeCreation(beanName);
+                }
+                bean = getObjectForBeanInstance(prototypeInstance, name, beanName, mbd);
+            } else {
+                // 从指定的 scope 下创建 bean
+                String scopeName = mbd.getScope();
+                final Scope scope = this.scopes.get(scopeName);
+                if (scope == null) {
+                    throw new IllegalStateException("No Scope registered for scope name '" + scopeName + "'");
+                }try {
+                    Object scopedInstance = scope.get(beanName, () -> {
+                        beforePrototypeCreation(beanName);
+                        try {
+                            return createBean(beanName, mbd, args);
+                        } finally {
+                            afterPrototypeCreation(beanName);
+                        }
+                    });
+                    bean = getObjectForBeanInstance(scopedInstance, name, beanName, mbd);
+                } catch (IllegalStateException ex) {
+                    throw new BeanCreationException(beanName,
+                            "Scope '" + scopeName + "' is not active for the current thread; consider " +
+                            "defining a scoped proxy for this bean if you intend to refer to it from a singleton",
+                            ex);
+                }
+            }
+        } catch (BeansException ex) {
+            cleanupAfterBeanCreationFailure(beanName);
+            throw ex;
+        }
+    }
+
+    // <9> 检查需要的类型是否符合 bean 的实际类型
+    // Check if required type matches the type of the actual bean instance.
+    if (requiredType != null && !requiredType.isInstance(bean)) {
+        try {
+            T convertedBean = getTypeConverter().convertIfNecessary(bean, requiredType);
+            if (convertedBean == null) {
+                throw new BeanNotOfRequiredTypeException(name, requiredType, bean.getClass());
+            }
+            return convertedBean;
+        } catch (TypeMismatchException ex) {
+            if (logger.isTraceEnabled()) {
+                logger.trace("Failed to convert bean '" + name + "' to required type '" +
+                        ClassUtils.getQualifiedName(requiredType) + "'", ex);
+            }
+            throw new BeanNotOfRequiredTypeException(name, requiredType, bean.getClass());
+        }
+    }
+    return (T) bean;
+}
+```
+
+内部调用 `#doGetBean(...)` 方法。`#doGetBean(...)` 方法的代码量比较多，从这里就可以看出 bean 的加载过程是一个非常复杂的过程，会涉及到各种各样的情况处理。
+
+`#doGetBean(...)` 方法，可以分为以下几个过程：
+
+1. 转换 beanName 。因为我们调用 `#getBean(...)` 方法传入的 `name` 并不一定就是 beanName，可以传入 aliasName，FactoryBean，所以这里需要进行简单的转换过程。
+2. 尝试从缓存中加载单例 bean 。
+3. bean 的实例化。
+4. 原型模式的依赖检查。因为 Spring 只会解决单例模式的循环依赖，对于原型模式的循环依赖都是直接抛出 BeanCurrentlyInCreationException 异常。
+5. 尝试从 parentBeanFactory 获取 bean 实例。如果 `parentBeanFactory != null && !containsBeanDefinition(beanName)` 则尝试从 parentBeanFactory 中获取 bean 实例对象，因为 `!containsBeanDefinition(beanName)` 就意味着定义的 xml 文件中没有 beanName 相应的配置，这个时候就只能从 `parentBeanFactory` 中获取。
+6. 获取 RootBeanDefinition，并对其进行合并检查。从缓存中获取已经解析的 RootBeanDefinition 。同时，如果父类不为 `null` 的话，则会合并父类的属性。
+7. 依赖检查。某个 bean 依赖其他 bean ，则需要先加载依赖的 bean。
+8. 对不同的 scope 进行处理。
+9. 类型转换处理。如果传递的 `requiredType` 不为 `null`，则需要检测所得到 bean 的类型是否与该 `requiredType` 一致。如果不一致则尝试转换，当然也要能够转换成功，否则抛出 BeanNotOfRequiredTypeException 异常。
+
+下面就以下几个方面进行阐述，说明 Spring bean 的加载过程。
+
+1. 从缓存中获取 bean
+2. 创建 bean 实例对象
+3. 从 bean 实例中获取对象
+
+# 1. 从缓存中获取 bean
+
+Spring 中根据 scope 可以将 bean 分为以下几类：singleton、prototype 和 其他，这样分的原因在于 Spring 在对不同 scope 处理的时候是这么处理的：
+
+- singleton ：在 Spring 的 IoC 容器中只存在一个对象实例，所有该对象的引用都共享这个实例。Spring 容器只会创建该 bean 定义的唯一实例，这个实例会被保存到缓存中，并且对该bean的所有后续请求和引用都将返回该缓存中的对象实例。
+- prototype ：每次对该bean的请求都会创建一个新的实例
+- 其他 ：
+  - request：每次 http 请求将会有各自的 bean 实例。
+  - session：在一个 http session 中，一个 bean 定义对应一个 bean 实例。
+  - global session：在一个全局的 http session 中，一个 bean 定义对应一个 bean 实例。
+
+所以，从缓存中获取的 bean 一定是 singleton bean，这也是 **Spring 为何只解决 singleton bean 的循环依赖**。调用 `#getSingleton(String beanName)` 方法，从缓存中获取 singleton bean。代码如下：
+
+```
+// DefaultSingletonBeanRegistry.java
+
+public Object getSingleton(String beanName) {
+    return getSingleton(beanName, true);
+}
+
+@Nullable
+protected Object getSingleton(String beanName, boolean allowEarlyReference) {
+    // 从单例缓冲中加载 bean
+    Object singletonObject = this.singletonObjects.get(beanName);
+    // 缓存中的 bean 为空，且当前 bean 正在创建
+    if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
+        // 加锁
+        synchronized (this.singletonObjects) {
+            // 从 earlySingletonObjects 获取
+            singletonObject = this.earlySingletonObjects.get(beanName);
+            // earlySingletonObjects 中没有，且允许提前创建
+            if (singletonObject == null && allowEarlyReference) {
+                // 从 singletonFactories 中获取对应的 ObjectFactory
+                ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
+                if (singletonFactory != null) {
+                    // 获得 bean
+                    singletonObject = singletonFactory.getObject();
+                    // 添加 bean 到 earlySingletonObjects 中
+                    this.earlySingletonObjects.put(beanName, singletonObject);
+                    // 从 singletonFactories 中移除对应的 ObjectFactory
+                    this.singletonFactories.remove(beanName);
+                }
+            }
+        }
+    }
+    return singletonObject;
+}
+```
+
+- 该方法就是从
+
+   
+
+  ```
+  singletonObjects
+  ```
+
+  、
+
+  ```
+  earlySingletonObjects
+  ```
+
+  、
+
+   
+
+  ```
+  singletonFactories
+  ```
+
+   
+
+  三个缓存中获取，这里也是 Spring 解决 bean 循环依赖的关键之处。详细内容请查看如下内容：
+
+  - [【死磕 Spring】—— IoC 之加载 bean：从单例缓存中获取单例 bean](http://svip.iocoder.cn/Spring/IoC-get-Bean-getSingleton)
+  - [【死磕 Spring】—— IoC 之加载 bean：创建 bean（五）之循环依赖处理](http://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-5)
+
+# 2. 创建 bean 实例对象
+
+如果缓存中没有，也没有 `parentBeanFactory` ，则会调用 `#createBean(String beanName, RootBeanDefinition mbd, Object[] args)` 方法，创建 bean 实例。该方法主要是在处理不同 scope 的 bean 的时候进行调用。代码如下：
+
+```
+// AbstractBeanFactory.java
+
+protected abstract Object createBean(String beanName, RootBeanDefinition mbd, @Nullable Object[] args)
+            throws BeanCreationException;
+```
+
+- 该方法是定义在 AbstractBeanFactory 中的**抽象**方法，其含义是根据给定的 BeanDefinition 和 `args` 实例化一个 bean 对象。如果该 BeanDefinition 存在父类，则该 BeanDefinition 已经合并了父类的属性。所有 Bean 实例的创建都会委托给该方法实现。
+- 方法接受三个参数：
+  - `beanName` ：bean 的名字。
+  - `mbd` ：已经合并了父类属性的（如果有的话）BeanDefinition 。
+  - `args` ：用于构造函数或者工厂方法创建 bean 实例对象的参数 。
+
+------
+
+该抽象方法的**默认实现**是在类 AbstractAutowireCapableBeanFactory 中实现，该方法其实只是做一些检查和验证工作，真正的初始化工作是由 `#doCreateBean(final String beanName, final RootBeanDefinition mbd, final Object[] args)` 方法来实现。代码如下：
+
+```
+// AbstractAutowireCapableBeanFactory.java
+
+protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final @Nullable Object[] args)
+        throws BeanCreationException {
+
+    // Instantiate the bean.
+    // BeanWrapper 是对 Bean 的包装，其接口中所定义的功能很简单包括设置获取被包装的对象，获取被包装 bean 的属性描述器
+    BeanWrapper instanceWrapper = null;
+    // <1> 单例模型，则从未完成的 FactoryBean 缓存中删除
+    if (mbd.isSingleton()) {
+        instanceWrapper = this.factoryBeanInstanceCache.remove(beanName);
+    }
+    // <2> 使用合适的实例化策略来创建新的实例：工厂方法、构造函数自动注入、简单初始化
+    if (instanceWrapper == null) {
+        instanceWrapper = createBeanInstance(beanName, mbd, args);
+    }
+    // 包装的实例对象
+    final Object bean = instanceWrapper.getWrappedInstance();
+    // 包装的实例对象的类型
+    Class<?> beanType = instanceWrapper.getWrappedClass();
+    if (beanType != NullBean.class) {
+        mbd.resolvedTargetType = beanType;
+    }
+
+    // Allow post-processors to modify the merged bean definition.
+    // <3> 判断是否有后置处理
+    // 如果有后置处理，则允许后置处理修改 BeanDefinition
+    synchronized (mbd.postProcessingLock) {
+        if (!mbd.postProcessed) {
+            try {
+                // 后置处理修改 BeanDefinition
+                applyMergedBeanDefinitionPostProcessors(mbd, beanType, beanName);
+            } catch (Throwable ex) {
+                throw new BeanCreationException(mbd.getResourceDescription(), beanName,
+                        "Post-processing of merged bean definition failed", ex);
+            }
+            mbd.postProcessed = true;
+        }
+    }
+
+    // Eagerly cache singletons to be able to resolve circular references
+    // even when triggered by lifecycle interfaces like BeanFactoryAware.
+    // <4> 解决单例模式的循环依赖
+    boolean earlySingletonExposure = (mbd.isSingleton() // 单例模式
+            && this.allowCircularReferences // 运行循环依赖
+            && isSingletonCurrentlyInCreation(beanName)); // 当前单例 bean 是否正在被创建
+    if (earlySingletonExposure) {
+        if (logger.isTraceEnabled()) {
+            logger.trace("Eagerly caching bean '" + beanName +
+                    "' to allow for resolving potential circular references");
+        }
+        // 提前将创建的 bean 实例加入到 singletonFactories 中
+        // 这里是为了后期避免循环依赖
+        addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
+    }
+
+    // Initialize the bean instance.
+    // 开始初始化 bean 实例对象
+    Object exposedObject = bean;
+    try {
+        // <5> 对 bean 进行填充，将各个属性值注入，其中，可能存在依赖于其他 bean 的属性
+        // 则会递归初始依赖 bean
+        populateBean(beanName, mbd, instanceWrapper);
+        // <6> 调用初始化方法
+        exposedObject = initializeBean(beanName, exposedObject, mbd);
+    } catch (Throwable ex) {
+        if (ex instanceof BeanCreationException && beanName.equals(((BeanCreationException) ex).getBeanName())) {
+            throw (BeanCreationException) ex;
+        } else {
+            throw new BeanCreationException(
+                    mbd.getResourceDescription(), beanName, "Initialization of bean failed", ex);
+        }
+    }
+
+    // <7> 循环依赖处理
+    if (earlySingletonExposure) {
+        // 获取 earlySingletonReference
+        Object earlySingletonReference = getSingleton(beanName, false);
+        // 只有在存在循环依赖的情况下，earlySingletonReference 才不会为空
+        if (earlySingletonReference != null) {
+            // 如果 exposedObject 没有在初始化方法中被改变，也就是没有被增强
+            if (exposedObject == bean) {
+                exposedObject = earlySingletonReference;
+            // 处理依赖
+            } else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
+                String[] dependentBeans = getDependentBeans(beanName);
+                Set<String> actualDependentBeans = new LinkedHashSet<>(dependentBeans.length);
+                for (String dependentBean : dependentBeans) {
+                    if (!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 " +
+                            "'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.");
+                }
+            }
+        }
+    }
+
+    // Register bean as disposable.
+    // <8> 注册 bean
+    try {
+        registerDisposableBeanIfNecessary(beanName, bean, mbd);
+    } catch (BeanDefinitionValidationException ex) {
+        throw new BeanCreationException(
+                mbd.getResourceDescription(), beanName, "Invalid destruction signature", ex);
+    }
+
+    return exposedObject;
+}
+```
+
+`#doCreateBean(...)` 方法，是创建 bean 实例的核心方法，它的整体思路是：
+
+- `<1>` 处，如果是单例模式，则清除 `factoryBeanInstanceCache 缓存`，同时返回 BeanWrapper 实例对象，当然如果存在。
+- `<2>` 处，如果缓存中没有 BeanWrapper 或者不是单例模式，则调用 `#createBeanInstance(...)` 方法，实例化 bean，主要是将 BeanDefinition 转换为 BeanWrapper 。
+- `<3>` 处，MergedBeanDefinitionPostProcessor 的应用。
+- `<4>` 处，单例模式的循环依赖处理。
+- `<5>` 处，调用 `#populateBean(String beanName, RootBeanDefinition mbd, BeanWrapper bw)` 方法，进行属性填充。将所有属性填充至 bean 的实例中。
+- `<6>` 处，调用 `#initializeBean(final String beanName, final Object bean, RootBeanDefinition mbd)` 方法，初始化 bean 。
+- `<7>` 处，依赖检查。
+- `<8>` 处，注册 DisposableBean 。
+
+## 2.1 实例化 bean
+
+如果缓存中没有 BeanWrapper 实例对象或者该 bean 不是 singleton，则调用 `#createBeanInstance(...)` 方法。创建 bean 实例。该方法主要是根据参数 BeanDefinition、`args[]` 来调用构造函数实例化 bean 对象。**过程较为复杂**，代码如下：
+
+```
+// AbstractAutowireCapableBeanFactory.java
+
+protected BeanWrapper createBeanInstance(String beanName, RootBeanDefinition mbd, @Nullable Object[] args) {
+    // Make sure bean class is actually resolved at this point.
+    // 解析 bean ，将 bean 类名解析为 class 引用。
+    Class<?> beanClass = resolveBeanClass(mbd, beanName);
+
+    if (beanClass != null && !Modifier.isPublic(beanClass.getModifiers()) && !mbd.isNonPublicAccessAllowed()) { // 校验
+        throw new BeanCreationException(mbd.getResourceDescription(), beanName,
+                "Bean class isn't public, and non-public access not allowed: " + beanClass.getName());
+    }
+
+    // <1> 如果存在 Supplier 回调，则使用给定的回调方法初始化策略
+    Supplier<?> instanceSupplier = mbd.getInstanceSupplier();
+    if (instanceSupplier != null) {
+        return obtainFromSupplier(instanceSupplier, beanName);
+    }
+
+    // <2> 使用 FactoryBean 的 factory-method 来创建，支持静态工厂和实例工厂
+    if (mbd.getFactoryMethodName() != null)  {
+        return instantiateUsingFactoryMethod(beanName, mbd, args);
+    }
+
+    // <3> Shortcut when re-creating the same bean...
+    boolean resolved = false;
+    boolean autowireNecessary = false;
+    if (args == null) {
+        // constructorArgumentLock 构造函数的常用锁
+        synchronized (mbd.constructorArgumentLock) {
+            // 如果已缓存的解析的构造函数或者工厂方法不为空，则可以利用构造函数解析
+            // 因为需要根据参数确认到底使用哪个构造函数，该过程比较消耗性能，所有采用缓存机制
+            if (mbd.resolvedConstructorOrFactoryMethod != null) {
+                resolved = true;
+                autowireNecessary = mbd.constructorArgumentsResolved;
+            }
+        }
+    }
+    // 已经解析好了，直接注入即可
+    if (resolved) {
+        // <3.1> autowire 自动注入，调用构造函数自动注入
+        if (autowireNecessary) {
+            return autowireConstructor(beanName, mbd, null, null);
+        } else {
+            // <3.2> 使用默认构造函数构造
+            return instantiateBean(beanName, mbd);
+        }
+    }
+
+    // Candidate constructors for autowiring?
+    // <4> 确定解析的构造函数
+    // 主要是检查已经注册的 SmartInstantiationAwareBeanPostProcessor
+    Constructor<?>[] ctors = determineConstructorsFromBeanPostProcessors(beanClass, beanName);
+    // <4.1> 有参数情况时，创建 Bean 。先利用参数个数，类型等，确定最精确匹配的构造方法。
+    if (ctors != null || mbd.getResolvedAutowireMode() == AUTOWIRE_CONSTRUCTOR ||
+            mbd.hasConstructorArgumentValues() || !ObjectUtils.isEmpty(args))  {
+        return autowireConstructor(beanName, mbd, ctors, args);
+    }
+
+    // Preferred constructors for default construction?
+    // <4.1> 选择构造方法，创建 Bean 。
+    ctors = mbd.getPreferredConstructors();
+    if (ctors != null) {
+        return autowireConstructor(beanName, mbd, ctors, null); // args = null
+    }
+
+    // No special handling: simply use no-arg constructor.
+    // <4.2> 有参数时，又没获取到构造方法，则只能调用无参构造方法来创建实例了(兜底方法)
+    return instantiateBean(beanName, mbd);
+}
+```
+
+实例化 Bean 对象，是一个**复杂**的过程，其主要的逻辑为：
+
+- `<1>` 处，如果存在 Supplier 回调，则调用 `#obtainFromSupplier(Supplier<?> instanceSupplier, String beanName)` 方法，进行初始化。
+
+- `<2>` 处，如果存在工厂方法，则使用工厂方法进行初始化。
+
+- ```
+  <3>
+  ```
+
+   
+
+  处，首先判断缓存，如果
+
+  缓存中存在
+
+  ，即已经解析过了，则直接使用已经解析了的。根据
+
+   
+
+  ```
+  constructorArgumentsResolved
+  ```
+
+   
+
+  参数来判断：
+
+  - `<3.1>` 处，是使用构造函数自动注入，即调用 `#autowireConstructor(String beanName, RootBeanDefinition mbd, Constructor<?>[] ctors, Object[] explicitArgs)` 方法。
+  - `<3.2>` 处，还是默认构造函数，即调用 `#instantiateBean(final String beanName, final RootBeanDefinition mbd)` 方法。
+
+- ```
+  <4>
+  ```
+
+   
+
+  处，如果
+
+  缓存中没有
+
+  ，则需要先确定到底使用哪个构造函数来完成解析工作，因为一个类有多个构造函数，每个构造函数都有不同的构造参数，所以需要根据参数来锁定构造函数并完成初始化。
+
+  - `<4.1>` 处，如果存在参数，则使用相应的带有参数的构造函数，即调用 `#autowireConstructor(String beanName, RootBeanDefinition mbd, Constructor<?>[] ctors, Object[] explicitArgs)` 方法。
+  - `<4.2>` 处，否则，使用默认构造函数，即调用 `#instantiateBean(final String beanName, final RootBeanDefinition mbd)` 方法。
+
+其实核心思想还是在于根据不同的情况执行不同的实例化策略，主要是包括如下四种策略：
+
+1. Supplier 回调
+2. `#instantiateUsingFactoryMethod(...)` 方法，工厂方法初始化
+3. `#autowireConstructor(...)` 方法，构造函数自动注入初始化
+4. `#instantiateBean(...)` 方法，默认构造函数注入
+
+其实无论哪种策略，他们的实现逻辑都差不多：确定构造函数和构造方法，然后实例化。只不过相对于 Supplier 回调和默认构造函数注入而言，工厂方法初始化和构造函数自动注入初始化会比较复杂，因为他们构造函数和构造参数的不确定性，Spring 需要花大量的精力来确定构造函数和构造参数，如果确定了则好办，直接选择实例化策略即可。当然在实例化的时候会根据是否有需要覆盖或者动态替换掉的方法，因为存在覆盖或者织入的话需要创建动态代理将方法织入，这个时候就只能选择 CGLIB 的方式来实例化，否则直接利用反射的方式即可。
+
+## 2.2 属性填充
+
+属性填充其实就是将 BeanDefinition 的属性值赋值给 BeanWrapper 实例对象的过程。在填充的过程需要根据注入的类型不同来区分是根据类型注入还是名字注入，当然在这个过程还会涉及循环依赖的问题的。代码如下：
+
+```
+// AbstractAutowireCapableBeanFactory.java
+
+protected void populateBean(String beanName, RootBeanDefinition mbd, @Nullable BeanWrapper bw) {
+    // 没有实例化对象
+    if (bw == null) {
+        // 有属性，则抛出 BeanCreationException 异常
+        if (mbd.hasPropertyValues()) {
+            throw new BeanCreationException(
+                    mbd.getResourceDescription(), beanName, "Cannot apply property values to null instance");
+            // 没有属性，直接 return 返回
+        } else {
+            // Skip property population phase for null instance.
+            return;
+        }
+    }
+
+    // <1> 在设置属性之前给 InstantiationAwareBeanPostProcessors 最后一次改变 bean 的机会
+    // 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.
+    boolean continueWithPropertyPopulation = true;
+    if (!mbd.isSynthetic()  // bean 不是"合成"的，即未由应用程序本身定义
+            && hasInstantiationAwareBeanPostProcessors()) { // 是否持有 InstantiationAwareBeanPostProcessor
+        // 迭代所有的 BeanPostProcessors
+        for (BeanPostProcessor bp : getBeanPostProcessors()) {
+            if (bp instanceof InstantiationAwareBeanPostProcessor) { // 如果为 InstantiationAwareBeanPostProcessor
+                InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp;
+                // 返回值为是否继续填充 bean
+                // postProcessAfterInstantiation：如果应该在 bean上面设置属性则返回 true，否则返回 false
+                // 一般情况下，应该是返回true 。
+                // 返回 false 的话，将会阻止在此 Bean 实例上调用任何后续的 InstantiationAwareBeanPostProcessor 实例。
+                if (!ibp.postProcessAfterInstantiation(bw.getWrappedInstance(), beanName)) {
+                    continueWithPropertyPopulation = false;
+                    break;
+                }
+            }
+        }
+    }
+    // 如果后续处理器发出停止填充命令，则终止后续操作
+    if (!continueWithPropertyPopulation) {
+        return;
+    }
+
+    // bean 的属性值
+    PropertyValues pvs = (mbd.hasPropertyValues() ? mbd.getPropertyValues() : null);
+
+    // <2> 自动注入
+    if (mbd.getResolvedAutowireMode() == AUTOWIRE_BY_NAME || mbd.getResolvedAutowireMode() == AUTOWIRE_BY_TYPE) {
+        // 将 PropertyValues 封装成 MutablePropertyValues 对象
+        // MutablePropertyValues 允许对属性进行简单的操作，并提供构造函数以支持Map的深度复制和构造。
+        MutablePropertyValues newPvs = new MutablePropertyValues(pvs);
+        // Add property values based on autowire by name if applicable.
+        // 根据名称自动注入
+        if (mbd.getResolvedAutowireMode() == AUTOWIRE_BY_NAME) {
+            autowireByName(beanName, mbd, bw, newPvs);
+        }
+        // Add property values based on autowire by type if applicable.
+        // 根据类型自动注入
+        if (mbd.getResolvedAutowireMode() == AUTOWIRE_BY_TYPE) {
+            autowireByType(beanName, mbd, bw, newPvs);
+        }
+        pvs = newPvs;
+    }
+
+    // 是否已经注册了 InstantiationAwareBeanPostProcessors
+    boolean hasInstAwareBpps = hasInstantiationAwareBeanPostProcessors();
+    // 是否需要进行【依赖检查】
+    boolean needsDepCheck = (mbd.getDependencyCheck() != AbstractBeanDefinition.DEPENDENCY_CHECK_NONE);
+
+    // <3> BeanPostProcessor 处理
+    PropertyDescriptor[] filteredPds = null;
+    if (hasInstAwareBpps) {
+        if (pvs == null) {
+            pvs = mbd.getPropertyValues();
+        }
+        // 遍历 BeanPostProcessor 数组
+        for (BeanPostProcessor bp : getBeanPostProcessors()) {
+            if (bp instanceof InstantiationAwareBeanPostProcessor) {
+                InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp;
+                // 对所有需要依赖检查的属性进行后处理
+                PropertyValues pvsToUse = ibp.postProcessProperties(pvs, bw.getWrappedInstance(), beanName);
+                if (pvsToUse == null) {
+                    // 从 bw 对象中提取 PropertyDescriptor 结果集
+                    // PropertyDescriptor：可以通过一对存取方法提取一个属性
+                    if (filteredPds == null) {
+                        filteredPds = filterPropertyDescriptorsForDependencyCheck(bw, mbd.allowCaching);
+                    }
+                    pvsToUse = ibp.postProcessPropertyValues(pvs, filteredPds, bw.getWrappedInstance(), beanName);
+                    if (pvsToUse == null) {
+                        return;
+                    }
+                }
+                pvs = pvsToUse;
+            }
+        }
+    }
+    
+    // <4> 依赖检查
+    if (needsDepCheck) {
+        if (filteredPds == null) {
+            filteredPds = filterPropertyDescriptorsForDependencyCheck(bw, mbd.allowCaching);
+        }
+        // 依赖检查，对应 depends-on 属性
+        checkDependencies(beanName, mbd, filteredPds, pvs);
+    }
+
+    // <5> 将属性应用到 bean 中
+    if (pvs != null) {
+        applyPropertyValues(beanName, mbd, bw, pvs);
+    }
+}
+```
+
+处理流程如下：
+
+- `<1>` ，根据 `hasInstantiationAwareBeanPostProcessors` 属性来判断，是否需要在注入属性之前给 InstantiationAwareBeanPostProcessors 最后一次改变 bean 的机会。**此过程可以控制 Spring 是否继续进行属性填充**。
+
+- 统一存入到 PropertyValues 中，PropertyValues 用于描述 bean 的属性。
+
+  - ```
+    <2>
+    ```
+
+     
+
+    ，根据注入类型(
+
+     
+
+    ```
+    AbstractBeanDefinition#getResolvedAutowireMode()
+    ```
+
+     
+
+    方法的返回值 )的不同来判断：
+
+    - 是根据名称来自动注入（`#autowireByName(...)`）
+    - 还是根据类型来自动注入（`#autowireByType(...)`）
+
+  - `<3>` ，进行 BeanPostProcessor 处理。
+
+  - `<4>` ，依赖检测。
+
+- `<5>` ，将所有 PropertyValues 中的属性，填充到 BeanWrapper 中。
+
+## 2.3 初始化 bean
+
+初始化 bean 为 `#createBean(...)` 方法的最后一个过程，代码如下：
+
+```
+// AbstractAutowireCapableBeanFactory.java
+
+protected Object initializeBean(final String beanName, final Object bean, @Nullable RootBeanDefinition mbd) {
+    if (System.getSecurityManager() != null) { // 安全模式
+        AccessController.doPrivileged((PrivilegedAction<Object>) () -> {
+            // <1> 激活 Aware 方法，对特殊的 bean 处理：Aware、BeanClassLoaderAware、BeanFactoryAware
+            invokeAwareMethods(beanName, bean);
+            return null;
+        }, getAccessControlContext());
+    } else {
+        // <1> 激活 Aware 方法，对特殊的 bean 处理：Aware、BeanClassLoaderAware、BeanFactoryAware
+        invokeAwareMethods(beanName, bean);
+    }
+
+    // <2> 后处理器，before
+    Object wrappedBean = bean;
+    if (mbd == null || !mbd.isSynthetic()) {
+        wrappedBean = applyBeanPostProcessorsBeforeInitialization(wrappedBean, beanName);
+    }
+
+    // <3> 激活用户自定义的 init 方法
+    try {
+        invokeInitMethods(beanName, wrappedBean, mbd);
+    } catch (Throwable ex) {
+        throw new BeanCreationException(
+                (mbd != null ? mbd.getResourceDescription() : null),
+                beanName, "Invocation of init method failed", ex);
+    }
+
+    // <2> 后处理器，after
+    if (mbd == null || !mbd.isSynthetic()) {
+        wrappedBean = applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName);
+    }
+
+    return wrappedBean;
+}
+```
+
+初始化 bean 的方法其实就是三个步骤的处理，而这三个步骤主要还是根据**用户设定**的来进行初始化，这三个过程为：
+
+- `<1>` 激活 Aware 方法。
+- `<3>` 后置处理器的应用。
+- `<2>` 激活自定义的 init 方法。
+
+# 3. 从 bean 实例中获取对象
+
+无论是从单例缓存中获取的 bean 实例 还是通过 `#createBean(...)` 方法来创建的 bean 实例，最终都会调用 `#getObjectForBeanInstance(...)` 方法来根据传入的 bean 实例获取对象，按照 Spring 的传统，该方法也只是做一些检测工作，真正的实现逻辑是委托给 `#getObjectFromFactoryBean(...)` 方法来实现。代码如下：
+
+```
+protected Object getObjectFromFactoryBean(FactoryBean<?> factory, String beanName, boolean shouldPostProcess) {
+    // <1> 为单例模式且缓存中存在
+    if (factory.isSingleton() && containsSingleton(beanName)) {
+        synchronized (getSingletonMutex()) { // <1.1> 单例锁
+            // <1.2> 从缓存中获取指定的 factoryBean
+            Object object = this.factoryBeanObjectCache.get(beanName);
+            if (object == null) {
+                // 为空，则从 FactoryBean 中获取对象
+                object = doGetObjectFromFactoryBean(factory, beanName);
+                // 从缓存中获取
+                // TODO 芋艿，具体原因
+                // Only post-process and store if not put there already during getObject() call above
+                // (e.g. because of circular reference processing triggered by custom getBean calls)
+                Object alreadyThere = this.factoryBeanObjectCache.get(beanName);
+                if (alreadyThere != null) {
+                    object = alreadyThere;
+                } else {
+                    // <1.3> 需要后续处理
+                    if (shouldPostProcess) {
+                        // 若该 Bean 处于创建中，则返回非处理对象，而不是存储它
+                        if (isSingletonCurrentlyInCreation(beanName)) {
+                            // Temporarily return non-post-processed object, not storing it yet..
+                            return object;
+                        }
+                        // 单例 Bean 的前置处理
+                        beforeSingletonCreation(beanName);
+                        try {
+                            // 对从 FactoryBean 获取的对象进行后处理
+                            // 生成的对象将暴露给 bean 引用
+                            object = postProcessObjectFromFactoryBean(object, beanName);
+                        } catch (Throwable ex) {
+                            throw new BeanCreationException(beanName,
+                                    "Post-processing of FactoryBean's singleton object failed", ex);
+                        } finally {
+                            // 单例 Bean 的后置处理
+                            afterSingletonCreation(beanName);
+                        }
+                    }
+                    // <1.4> 添加到 factoryBeanObjectCache 中，进行缓存
+                    if (containsSingleton(beanName)) {
+                        this.factoryBeanObjectCache.put(beanName, object);
+                    }
+                }
+            }
+            return object;
+        }
+    // <2>
+    } else {
+        // 为空，则从 FactoryBean 中获取对象
+        Object object = doGetObjectFromFactoryBean(factory, beanName);
+        // 需要后续处理
+        if (shouldPostProcess) {
+            try {
+                // 对从 FactoryBean 获取的对象进行后处理
+                // 生成的对象将暴露给 bean 引用
+                object = postProcessObjectFromFactoryBean(object, beanName);
+            }
+            catch (Throwable ex) {
+                throw new BeanCreationException(beanName, "Post-processing of FactoryBean's object failed", ex);
+            }
+        }
+        return object;
+    }
+}
+```
+
+主要流程如下：
+
+- 若为单例且单例 Bean 缓存中存在 `beanName` ，则 `<1>` 进行后续处理（跳转到下一步），否则，则 `<2>` 从 FactoryBean 中获取 Bean 实例对象。
+
+- `<1.1>` 首先，获取锁。其实我们在前面篇幅中发现了大量的同步锁，锁住的对象都是 `this.singletonObjects`，主要是因为在单例模式中必须要**保证全局唯一**。
+
+- `<1.2>` 然后，从 `factoryBeanObjectCache` 缓存中获取实例对象 `object` 。若 `object` 为空，则调用 `#doGetObjectFromFactoryBean(FactoryBean<?> factory, String beanName)` 方法，从 FactoryBean 获取对象，其实内部就是调用 `FactoryBean#getObject()` 方法。
+
+- ```
+  <1.3>
+  ```
+
+   
+
+  如果需要后续处理(
+
+   
+
+  ```
+  shouldPostProcess = true
+  ```
+
+   
+
+  )，则进行进一步处理，步骤如下：
+
+  - 若该 Bean 处于创建中（`#isSingletonCurrentlyInCreation(String beanName)` 方法返回 `true` ），则返回**非处理的 Bean 对象**，而不是存储它。
+  - 调用 `#beforeSingletonCreation(String beanName)` 方法，进行创建之前的处理。默认实现将该 Bean 标志为当前创建的。
+  - 调用 `#postProcessObjectFromFactoryBean(Object object, String beanName)` 方法，对从 FactoryBean 获取的 Bean 实例对象进行后置处理。
+  - 调用 `#afterSingletonCreation(String beanName)` 方法，进行创建 Bean 之后的处理，默认实现是将该 bean 标记为不再在创建中。
+
+- `<1.4>` 最后，加入到 `factoryBeanObjectCache` 缓存中。
+
+# 3. 小结
+
+End!!!
+
+到这里，Spring 加载 bean 的整体过程都已经分析完毕了，详情请给位移步到以下链接：
+
+1. [【死磕 Spring】—— IoC 之加载 bean：开启 bean 的加载](http://svip.iocoder.cn/Spring/IoC-get-Bean-begin)
+2. [【死磕 Spring】—— IoC 之加载 bean：从单例缓存中获取单例 bean](http://svip.iocoder.cn/Spring/IoC-get-Bean-getSingleton)
+3. [【死磕 Spring】—— IoC 之加载 bean：parentBeanFactory 与依赖处理](http://svip.iocoder.cn/Spring/IoC-get-Bean-parentBeanFactory-and-depend-on)
+4. [【死磕 Spring】—— IoC 之加载 bean：分析各 scope 的 bean 创建](http://svip.iocoder.cn/Spring/IoC-get-Bean-different-scope)
+5. [【死磕 Spring】—— IoC 之加载 bean：创建 bean（一）之主流程](http://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-1)
+6. [【死磕 Spring】—— IoC 之加载 bean：创建 bean（二）之实例化 Bean 对象(1)](http://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-2)
+7. [【死磕 Spring】—— IoC 之加载 bean：创建 bean（三）之实例化 Bean 对象(2)](http://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-3)
+8. [【死磕 Spring】—— IoC 之加载 bean：创建 bean（四）之属性填充](http://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-4)
+9. [【死磕 Spring】—— IoC 之加载 bean：创建 bean（五）之循环依赖处理](http://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-5)
+10. [【死磕 Spring】—— IoC 之加载 bean：创建 bean（六）之初始化 Bean 对象](http://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-6)
\ No newline at end of file
diff --git a/spring/31-Spring-IoC 之深入分析 Aware 接口.assets/242d5c99b48d717a4e1ce7782cb57bab.png b/spring/31-Spring-IoC 之深入分析 Aware 接口.assets/242d5c99b48d717a4e1ce7782cb57bab.png
new file mode 100644
index 0000000..33583f7
Binary files /dev/null and b/spring/31-Spring-IoC 之深入分析 Aware 接口.assets/242d5c99b48d717a4e1ce7782cb57bab.png differ
diff --git a/spring/31-Spring-IoC 之深入分析 Aware 接口.assets/cf1b7d54fc734e654a88c4611c6a5c34.png b/spring/31-Spring-IoC 之深入分析 Aware 接口.assets/cf1b7d54fc734e654a88c4611c6a5c34.png
new file mode 100644
index 0000000..6c52121
Binary files /dev/null and b/spring/31-Spring-IoC 之深入分析 Aware 接口.assets/cf1b7d54fc734e654a88c4611c6a5c34.png differ
diff --git a/spring/31-Spring-IoC 之深入分析 Aware 接口.md b/spring/31-Spring-IoC 之深入分析 Aware 接口.md
new file mode 100644
index 0000000..fe54364
--- /dev/null
+++ b/spring/31-Spring-IoC 之深入分析 Aware 接口.md	
@@ -0,0 +1,234 @@
+# 【死磕 Spring】—— IoC 之深入分析 Aware 接口
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=3335 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+AbstractAutowireCapableBeanFactory 的 `#doCreateBean(final String beanName, final RootBeanDefinition mbd, final Object[] args)` 方法，主要干三件事情：
+
+1. 实例化 bean 对象：`#createBeanInstance(String beanName, RootBeanDefinition mbd, Object[] args)` 方法。
+2. 属性注入：`#populateBean(String beanName, RootBeanDefinition mbd, BeanWrapper bw)` 方法。
+3. 初始化 bean 对象：`#initializeBean(final String beanName, final Object bean, RootBeanDefinition mbd)` 方法。
+
+而初始化 bean 对象时，也是干了三件事情：
+
+1. 激活 Aware 方法
+2. 后置处理器的应用
+3. 激活自定义的 init 方法
+
+接下来三篇文章将会详细分析这三件事情，这篇主要分析 Aware 接口。
+
+# 1. Aware 接口
+
+`org.springframework.beans.factory.Aware` 接口，定义如下：
+
+```
+/**
+ * Marker superinterface indicating that a bean is eligible to be
+ * notified by the Spring container of a particular framework object
+ * through a callback-style method. Actual method signature is
+ * determined by individual subinterfaces, but should typically
+ * consist of just one void-returning method that accepts a single
+ * argument.
+ *
+ * <p>Note that merely implementing {@link Aware} provides no default
+ * functionality. Rather, processing must be done explicitly, for example
+ * in a {@link org.springframework.beans.factory.config.BeanPostProcessor BeanPostProcessor}.
+ * Refer to {@link org.springframework.context.support.ApplicationContextAwareProcessor}
+ * and {@link org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory}
+ * for examples of processing {@code *Aware} interface callbacks.
+ *
+ * @author Chris Beams
+ * @since 3.1
+ */
+public interface Aware {
+
+}
+```
+
+Aware 接口为 Spring 容器的核心接口，是一个具有标识作用的超级接口，实现了该接口的 bean 是具有被 Spring 容器通知的能力，通知的方式是采用**回调**的方式。
+
+Aware 接口是一个空接口，实际的方法签名由各个子接口来确定，且该接口通常只会有一个接收单参数的 set 方法，该 set 方法的命名方式为 set + 去掉接口名中的 Aware 后缀，即 XxxAware 接口，则方法定义为 setXxx()，例如 BeanNameAware（setBeanName），ApplicationContextAware（setApplicationContext）。
+
+Aware 的子接口需要提供一个 `setXxx` 方法，我们知道 set 是设置属性值的方法，即 Aware 类接口的 `setXxx` 方法其实就是设置 xxx 属性值的。 Aware 的含义是感知的、感应的，那么在 Spring 容器中是如何实现感知并设置属性值得呢？我们可以从初始化 bean 中的激活 Aware 的方法 `#invokeAwareMethods(final String beanName, final Object bean)` 中看到一点点，代码如下：
+
+```
+// AbstractAutowireCapableBeanFactory.java
+
+private void invokeAwareMethods(final String beanName, final Object bean) {
+	if (bean instanceof Aware) {
+	    // BeanNameAware
+		if (bean instanceof BeanNameAware) {
+			((BeanNameAware) bean).setBeanName(beanName);
+		}
+		// BeanClassLoaderAware
+		if (bean instanceof BeanClassLoaderAware) {
+			ClassLoader bcl = getBeanClassLoader();
+			if (bcl != null) {
+				((BeanClassLoaderAware) bean).setBeanClassLoader(bcl);
+			}
+		}
+		// BeanFactoryAware
+		if (bean instanceof BeanFactoryAware) {
+			((BeanFactoryAware) bean).setBeanFactory(AbstractAutowireCapableBeanFactory.this);
+		}
+	}
+}
+```
+
+- 首先，判断 bean 实例是否属于 Aware 接口的范畴，如果是的话，则调用实例的 `setXxx()` 方法给实例设置 xxx 属性值，在 `#invokeAwareMethods(...)` 方法，主要是设置 beanName，beanClassLoader、BeanFactory 中三个属性值。
+
+# 2. Aware 子类
+
+Spring 提供了一系列的 Aware 接口，如下图（部分）：
+
+[![201808210001](31-Spring-IoC 之深入分析 Aware 接口.assets/242d5c99b48d717a4e1ce7782cb57bab.png)](http://static.iocoder.cn/242d5c99b48d717a4e1ce7782cb57bab)201808210001
+
+上面只是一部分子类，从这里我们可以看到 Spring 提供的 Aware 接口是是何其多。同时从上图我们也看到了几个比较熟悉的接口，如 BeanClassLoaderAware、BeanFactoryAware、BeanNameAware，下面就这三个接口来做一个简单的演示，先看各自的定义：
+
+```
+public interface BeanClassLoaderAware extends Aware {
+
+    /**
+    * 将 BeanClassLoader 提供给 bean 实例回调
+    * 在 bean 属性填充之后、初始化回调之前回调，
+    * 例如InitializingBean的InitializingBean.afterPropertiesSet（）方法或自定义init方法
+    */
+    void setBeanClassLoader(ClassLoader classLoader);
+
+}
+
+
+public interface BeanFactoryAware extends Aware {
+    /**
+    * 将 BeanFactory 提供给 bean 实例回调
+    * 调用时机和 setBeanClassLoader 一样
+    */
+    void setBeanFactory(BeanFactory beanFactory) throws BeansException;
+
+}
+
+
+public interface BeanNameAware extends Aware {
+
+    /**
+    * 在创建此 bean 的 bean工厂中设置 beanName
+    */
+    void setBeanName(String name);
+
+}
+
+
+public interface ApplicationContextAware extends Aware {
+
+    /**
+     * 设置此 bean 对象的 ApplicationContext，通常，该方法用于初始化对象
+     */
+    void setApplicationContext(ApplicationContext applicationContext)
+        throws BeansException;
+
+}
+```
+
+## 2.1 示例
+
+下面简单演示下上面四个接口的使用方法：
+
+```
+public class MyApplicationAware implements BeanNameAware,BeanFactoryAware,BeanClassLoaderAware,ApplicationContextAware{
+
+    private String beanName;
+
+    private BeanFactory beanFactory;
+
+    private ClassLoader classLoader;
+
+    private ApplicationContext applicationContext;
+
+    @Override
+    public void setBeanClassLoader(ClassLoader classLoader) {
+        System.out.println("调用了 BeanClassLoaderAware 的 setBeanClassLoader 方法");
+        this.classLoader = classLoader;
+    }
+
+    @Override
+    public void setBeanFactory(BeanFactory beanFactory) throws BeansException {
+        System.out.println("调用了 BeanFactoryAware 的 setBeanFactory 方法");
+        this.beanFactory = beanFactory;
+    }
+
+    @Override
+    public void setBeanName(String name) {
+        System.out.println("调用了 BeanNameAware 的 setBeanName 方法");
+        this.beanName = name;
+    }
+
+    @Override
+    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
+        System.out.println("调用了 ApplicationContextAware 的 setApplicationContext 方法");
+        this.applicationContext = applicationContext;
+    }
+
+    public void display(){
+        System.out.println("beanName:" + beanName);
+        System.out.println("是否为单例：" + beanFactory.isSingleton(beanName));
+        System.out.println("系统环境为：" + applicationContext.getEnvironment());
+    }
+}
+```
+
+测试方法如下:
+
+```
+public static void main(String[] args) {
+    ClassPathResource resource = new ClassPathResource("spring.xml");
+    DefaultListableBeanFactory factory = new DefaultListableBeanFactory();
+    XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(factory);
+    reader.loadBeanDefinitions(resource);
+
+    MyApplicationAware applicationAware = (MyApplicationAware) factory.getBean("myApplicationAware");
+    applicationAware.display();
+}
+```
+
+运行结果：
+
+[![201808210002](31-Spring-IoC 之深入分析 Aware 接口.assets/cf1b7d54fc734e654a88c4611c6a5c34.png)](http://static.iocoder.cn/cf1b7d54fc734e654a88c4611c6a5c34)201808210002
+
+从该运行结果可以看出，这里只执行了三个 Aware 接口的 set 方法，原因就是通过 `#getBean(...)` 方法调用时，在激活 Aware 接口时只检测了 BeanNameAware、BeanClassLoaderAware、BeanFactoryAware 三个 Aware 接口。如果将测试方法调整为下面：
+
+```
+public static void main(String[] args) {
+    ApplicationContext applicationContext = new ClassPathXmlApplicationContext("spring.xml");
+    MyApplicationAware applicationAware = (MyApplicationAware) applicationContext.getBean("myApplicationAware");
+    applicationAware.display();
+}
+```
+
+则运行结果如下：
+
+[![201808210003](31-Spring-IoC 之深入分析 Aware 接口.assets/cf1b7d54fc734e654a88c4611c6a5c34.png)](http://static.iocoder.cn/cf1b7d54fc734e654a88c4611c6a5c34)201808210003
+
+# 3. 小结
+
+从这了我们基本上就可以 Aware 真正的含义是什么了？感知，其实是 Spring 容器在初始化主动检测当前 bean 是否实现了 Aware 接口，如果实现了则回调其 set 方法将相应的参数设置给该 bean ，这个时候该 bean 就从 Spring 容器中取得相应的资源。
+
+最后文章末尾列出部分常用的 Aware 子接口，便于日后查询：
+
+- LoadTimeWeaverAware：加载Spring Bean时织入第三方模块，如AspectJ
+- BeanClassLoaderAware：加载Spring Bean的类加载器
+- BootstrapContextAware：资源适配器BootstrapContext，如JCA,CCI
+- ResourceLoaderAware：底层访问资源的加载器
+- BeanFactoryAware：声明BeanFactory
+- PortletConfigAware：PortletConfig
+- PortletContextAware：PortletContext
+- ServletConfigAware：ServletConfig
+- ServletContextAware：ServletContext
+- MessageSourceAware：国际化
+- ApplicationEventPublisherAware：应用事件
+- NotificationPublisherAware：JMX通知
+- BeanNameAware：声明Spring Bean的名字
\ No newline at end of file
diff --git a/spring/32-Spring-IoC 之深入分析 BeanPostProcessor.md b/spring/32-Spring-IoC 之深入分析 BeanPostProcessor.md
new file mode 100644
index 0000000..072b6e1
--- /dev/null
+++ b/spring/32-Spring-IoC 之深入分析 BeanPostProcessor.md	
@@ -0,0 +1,343 @@
+# 【死磕 Spring】—— IoC 之深入分析 BeanPostProcessor
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=3338 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+# 1. BeanPostProcessor 接口
+
+Spring 作为优秀的开源框架，它为我们提供了丰富的可扩展点，除了前面提到的 Aware 接口，还包括其他部分，其中一个很重要的就是 BeanPostProcessor。这篇文章主要介绍 BeanPostProcessor 的使用以及其实现原理。我们先看 BeanPostProcessor 的定位：
+
+> BeanPostProcessor 的作用：在 Bean 完成实例化后，如果我们需要对其进行一些配置、增加一些自己的处理逻辑，那么请使用 BeanPostProcessor。
+
+# 2. BeanPostProcessor 示例
+
+首先定义一个类，该类实现 BeanPostProcessor 接口，代码如下：
+
+```
+public class BeanPostProcessorTest implements BeanPostProcessor{
+
+    @Override
+    public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
+        System.out.println("Bean [" + beanName + "] 开始初始化");
+        // 这里一定要返回 bean，不能返回 null
+        return bean;
+    }
+
+    @Override
+    public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
+        System.out.println("Bean [" + beanName + "] 完成初始化");
+        return bean;
+    }
+
+    public void display(){
+        System.out.println("hello BeanPostProcessor!!!");
+    }
+}
+```
+
+测试方法如下：
+
+```
+ClassPathResource resource = new ClassPathResource("spring.xml");
+DefaultListableBeanFactory factory = new DefaultListableBeanFactory();
+XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(factory);
+reader.loadBeanDefinitions(resource);
+
+BeanPostProcessorTest test = (BeanPostProcessorTest) factory.getBean("beanPostProcessorTest");
+test.display();
+```
+
+运行结果：
+
+[![201808221005](http://static.iocoder.cn/162fab73d857b39db8e6198d5182c5d1)](http://static.iocoder.cn/162fab73d857b39db8e6198d5182c5d1)201808221005
+
+运行结果比较奇怪，为什么没有执行 `#postProcessBeforeInitialization(...)` 和 `#postProcessAfterInitialization(...)` 方法呢？
+
+我们 debug 跟踪下代码，这两个方法在 AbstractAutowireCapableBeanFactory 的 `#initializeBean(final String beanName, final Object bean, RootBeanDefinition mbd)` 方法处调用下，如下：
+
+[![201808221006](http://static.iocoder.cn/8d2ae41f84bfb1928845428dae1b26c1)](http://static.iocoder.cn/8d2ae41f84bfb1928845428dae1b26c1)201808221006
+
+debug，在 `#postProcessBeforeInitialization(...)`方法中，结果如下：
+
+[![img](http://static.iocoder.cn/cc20356e408146eba311266ebc20de95)](http://static.iocoder.cn/cc20356e408146eba311266ebc20de95)
+
+这段代码是通过迭代 `#getBeanPostProcessors()` 方法返回的结果集来调用 BeanPostProcessor 的 `#postProcessBeforeInitialization(Object bean, String beanName)` 方法，但是在这里我们看到该方法返回的结果集为空，所以肯定不会执行相应的 `#postProcessBeforeInitialization(Object bean, String beanName)` 方法咯。怎么办？答案不言而喻：只需要 `#getBeanPostProcessors()` 方法，返回的结果集中存在至少一个元素即可，该方法定义如下：
+
+```
+// AbstractBeanFactory.java
+
+/** BeanPostProcessors to apply in createBean. */
+private final List<BeanPostProcessor> beanPostProcessors = new CopyOnWriteArrayList<>();
+
+public List<BeanPostProcessor> getBeanPostProcessors() {
+    return this.beanPostProcessors;
+}
+```
+
+- 返回的 `beanPostProcessors` 是一个 `private` 的 List ，也就是说只要该类中存在 `beanPostProcessors.add(BeanPostProcessor beanPostProcessor)` 的调用，我们就找到了入口，在类 AbstractBeanFactory 中找到了如下代码：
+
+  ```
+  // AbstractBeanFactory.java
+  
+  @Override
+  public void addBeanPostProcessor(BeanPostProcessor beanPostProcessor) {
+  	Assert.notNull(beanPostProcessor, "BeanPostProcessor must not be null");
+  	// Remove from old position, if any
+  	this.beanPostProcessors.remove(beanPostProcessor);
+  	// Track whether it is instantiation/destruction aware
+  	if (beanPostProcessor instanceof InstantiationAwareBeanPostProcessor) {
+  		this.hasInstantiationAwareBeanPostProcessors = true;
+  	}
+  	if (beanPostProcessor instanceof DestructionAwareBeanPostProcessor) {
+  		this.hasDestructionAwareBeanPostProcessors = true;
+  	}
+  	// Add to end of list
+  	this.beanPostProcessors.add(beanPostProcessor);
+  }
+  ```
+
+  - 该方法是由 AbstractBeanFactory 的父类 `org.springframework.beans.factory.config.ConfigurableBeanFactory` 接口定义，它的核心意思就是将指定 BeanPostProcessor 注册到该 BeanFactory 创建的 bean 中，同时它是**按照插入的顺序进行注册的**，完全忽略 Ordered 接口所表达任何排序语义（在 BeanPostProcessor 中我们提供一个 Ordered 顺序，这个后面讲解）。
+
+到这里应该就比较熟悉了，其实只需要显示调用 `#addBeanPostProcessor(BeanPostProcessor beanPostProcessor)` 方法就可以了。加入如下代码：
+
+```
+BeanPostProcessorTest beanPostProcessorTest = new BeanPostProcessorTest();
+factory.addBeanPostProcessor(beanPostProcessorTest);
+```
+
+运行结果：
+
+[![img](http://static.iocoder.cn/162fab73d857b39db8e6198d5182c5d1)](http://static.iocoder.cn/162fab73d857b39db8e6198d5182c5d1)
+
+其实还有一种更加简单的方法，这个我们后面再说，先看 BeanPostProcessor 的原理。
+
+# 3. BeanPostProcessor 基本原理
+
+`org.springframework.beans.factory.config.BeanPostProcessor` 接口，代码如下：
+
+```
+public interface BeanPostProcessor {
+
+	@Nullable
+	default Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
+		return bean;
+	}
+
+	@Nullable
+	default Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
+		return bean;
+	}
+
+}
+```
+
+BeanPostProcessor 可以理解为是 Spring 的一个工厂钩子（其实 Spring 提供一系列的钩子，如 Aware 、InitializingBean、DisposableBean），它是 Spring 提供的对象实例化阶段强有力的扩展点，允许 Spring 在实例化 bean 阶段对其进行定制化修改，比较常见的使用场景是处理标记接口实现类或者为当前对象提供代理实现（例如 AOP）。
+
+一般普通的 BeanFactory 是不支持自动注册 BeanPostProcessor 的，需要我们手动调用 `#addBeanPostProcessor(BeanPostProcessor beanPostProcessor)` 方法进行注册。注册后的 BeanPostProcessor 适用于所有该 BeanFactory 创建的 bean，但是 **ApplicationContext 可以在其 bean 定义中自动检测所有的 BeanPostProcessor 并自动完成注册，同时将他们应用到随后创建的任何 Bean 中**。
+
+`#postProcessBeforeInitialization(Object bean, String beanName)` 和 `#postProcessAfterInitialization(Object bean, String beanName)` 两个方法，都接收一个 Object 类型的 `bean` ，一个 String 类型的 `beanName` ，其中 `bean` 是已经实例化了的 `instanceBean` ，能拿到这个你是不是可以对它为所欲为了？ 这两个方法是初始化 `bean` 的前后置处理器，他们应用 `#invokeInitMethods(String beanName, final Object bean, RootBeanDefinition mbd)` 方法的前后。如下图：
+
+[![201808231001](http://static.iocoder.cn/7e25251ee94e4697b5acbaf2acb754d7)](http://static.iocoder.cn/7e25251ee94e4697b5acbaf2acb754d7)201808231001
+
+代码层次上面已经贴出来，这里再贴一次：
+
+[![201808221006](http://static.iocoder.cn/8d2ae41f84bfb1928845428dae1b26c1)](http://static.iocoder.cn/8d2ae41f84bfb1928845428dae1b26c1)201808221006
+
+两者源码如下：
+
+```
+// AbstractAutowireCapableBeanFactory.java
+
+@Override
+public Object applyBeanPostProcessorsBeforeInitialization(Object existingBean, String beanName)
+		throws BeansException {
+	Object result = existingBean;
+	// 遍历 BeanPostProcessor 数组
+	for (BeanPostProcessor processor : getBeanPostProcessors()) {
+	    // 处理
+		Object current = processor.postProcessBeforeInitialization(result, beanName);
+        // 返回空，则返回 result
+		if (current == null) {
+			return result;
+		}
+		// 修改 result
+		result = current;
+	}
+	return result;
+}
+
+@Override
+public Object applyBeanPostProcessorsAfterInitialization(Object existingBean, String beanName)
+		throws BeansException {
+	Object result = existingBean;
+	// 遍历 BeanPostProcessor
+	for (BeanPostProcessor processor : getBeanPostProcessors()) {
+	    // 处理
+		Object current = processor.postProcessAfterInitialization(result, beanName);
+		// 返回空，则返回 result
+		if (current == null) {
+			return result;
+		}
+		// 修改 result
+		result = current;
+	}
+	return result;
+}
+```
+
+## 3.1 自动检测并注册
+
+`#getBeanPostProcessors()` 方法，返回的是 `beanPostProcessors` 集合，该集合里面存放就是我们自定义的 BeanPostProcessor ，如果该集合中存在元素则调用相应的方法，否则就直接返回 bean 了。这也是为什么使用 BeanFactory 容器是无法输出自定义 BeanPostProcessor 里面的内容，因为在 `BeanFactory#getBean(...)` 方法的过程中根本就没有将我们自定义的 BeanPostProcessor 注入进来，所以要想 BeanFactory 容器 的 BeanPostProcessor 生效我们必须手动调用 `#addBeanPostProcessor(BeanPostProcessor beanPostProcessor)` 方法，将定义的 BeanPostProcessor 注册到相应的 BeanFactory 中。**但是 ApplicationContext 不需要手动，因为 ApplicationContext 会自动检测并完成注册**。
+
+ApplicationContext 实现自动注册的原因，在于我们构造一个 ApplicationContext 实例对象的时候会调用 `#registerBeanPostProcessors(ConfigurableListableBeanFactory beanFactory)` 方法，将检测到的 BeanPostProcessor 注入到 ApplicationContext 容器中，同时应用到该容器创建的 bean 中。代码如下：
+
+```
+// AbstractApplicationContext.java
+
+/**
+ * 实例化并调用已经注入的 BeanPostProcessor
+ * 必须在应用中 bean 实例化之前调用
+ */
+protected void registerBeanPostProcessors(ConfigurableListableBeanFactory beanFactory) {
+    PostProcessorRegistrationDelegate.registerBeanPostProcessors(beanFactory, this);
+}
+
+// PostProcessorRegistrationDelegate.java
+
+public static void registerBeanPostProcessors(
+		ConfigurableListableBeanFactory beanFactory, AbstractApplicationContext applicationContext) {
+
+    // 获取所有的 BeanPostProcessor 的 beanName
+    // 这些 beanName 都已经全部加载到容器中去，但是没有实例化
+	String[] postProcessorNames = beanFactory.getBeanNamesForType(BeanPostProcessor.class, true, false);
+
+	// Register BeanPostProcessorChecker that logs an info message when
+	// a bean is created during BeanPostProcessor instantiation, i.e. when
+	// a bean is not eligible for getting processed by all BeanPostProcessors.
+    // 记录所有的beanProcessor数量
+	int beanProcessorTargetCount = beanFactory.getBeanPostProcessorCount() + 1 + postProcessorNames.length;
+	// 注册 BeanPostProcessorChecker，它主要是用于在 BeanPostProcessor 实例化期间记录日志
+    // 当 Spring 中高配置的后置处理器还没有注册就已经开始了 bean 的实例化过程，这个时候便会打印 BeanPostProcessorChecker 中的内容
+	beanFactory.addBeanPostProcessor(new BeanPostProcessorChecker(beanFactory, beanProcessorTargetCount));
+
+	// Separate between BeanPostProcessors that implement PriorityOrdered,
+	// Ordered, and the rest.
+    // PriorityOrdered 保证顺序
+	List<BeanPostProcessor> priorityOrderedPostProcessors = new ArrayList<>();
+    // MergedBeanDefinitionPostProcessor
+	List<BeanPostProcessor> internalPostProcessors = new ArrayList<>();
+    // 使用 Ordered 保证顺序
+	List<String> orderedPostProcessorNames = new ArrayList<>();
+    // 没有顺序
+	List<String> nonOrderedPostProcessorNames = new ArrayList<>();
+	for (String ppName : postProcessorNames) {
+        // PriorityOrdered
+        if (beanFactory.isTypeMatch(ppName, PriorityOrdered.class)) {
+            // 调用 getBean 获取 bean 实例对象
+			BeanPostProcessor pp = beanFactory.getBean(ppName, BeanPostProcessor.class);
+			priorityOrderedPostProcessors.add(pp);
+			if (pp instanceof MergedBeanDefinitionPostProcessor) {
+				internalPostProcessors.add(pp);
+			}
+		} else if (beanFactory.isTypeMatch(ppName, Ordered.class)) {
+            // 有序 Ordered
+			orderedPostProcessorNames.add(ppName);
+		} else {
+            // 无序
+			nonOrderedPostProcessorNames.add(ppName);
+		}
+	}
+
+	// First, register the BeanPostProcessors that implement PriorityOrdered.
+    // 第一步，注册所有实现了 PriorityOrdered 的 BeanPostProcessor
+    // 先排序
+	sortPostProcessors(priorityOrderedPostProcessors, beanFactory);
+    // 后注册
+	registerBeanPostProcessors(beanFactory, priorityOrderedPostProcessors);
+
+	// Next, register the BeanPostProcessors that implement Ordered.
+    // 第二步，注册所有实现了 Ordered 的 BeanPostProcessor
+	List<BeanPostProcessor> orderedPostProcessors = new ArrayList<>();
+	for (String ppName : orderedPostProcessorNames) {
+		BeanPostProcessor pp = beanFactory.getBean(ppName, BeanPostProcessor.class);
+		orderedPostProcessors.add(pp);
+		if (pp instanceof MergedBeanDefinitionPostProcessor) {
+			internalPostProcessors.add(pp);
+		}
+	}
+    // 先排序
+	sortPostProcessors(orderedPostProcessors, beanFactory);
+    // 后注册
+	registerBeanPostProcessors(beanFactory, orderedPostProcessors);
+
+	// Now, register all regular BeanPostProcessors.
+    // 第三步注册所有无序的 BeanPostProcessor
+	List<BeanPostProcessor> nonOrderedPostProcessors = new ArrayList<>();
+	for (String ppName : nonOrderedPostProcessorNames) {
+		BeanPostProcessor pp = beanFactory.getBean(ppName, BeanPostProcessor.class);
+		nonOrderedPostProcessors.add(pp);
+		if (pp instanceof MergedBeanDefinitionPostProcessor) {
+			internalPostProcessors.add(pp);
+		}
+	}
+	// 注册，无需排序
+	registerBeanPostProcessors(beanFactory, nonOrderedPostProcessors);
+
+	// Finally, re-register all internal BeanPostProcessors.
+    // 最后，注册所有的 MergedBeanDefinitionPostProcessor 类型的 BeanPostProcessor
+	sortPostProcessors(internalPostProcessors, beanFactory);
+	registerBeanPostProcessors(beanFactory, internalPostProcessors);
+
+	// Re-register post-processor for detecting inner beans as ApplicationListeners,
+	// moving it to the end of the processor chain (for picking up proxies etc).
+    // 加入ApplicationListenerDetector（探测器）
+    // 重新注册 BeanPostProcessor 以检测内部 bean，因为 ApplicationListeners 将其移动到处理器链的末尾
+	beanFactory.addBeanPostProcessor(new ApplicationListenerDetector(applicationContext));
+}
+```
+
+- 方法首先 `beanFactory` 获取注册到该 BeanFactory 中所有 BeanPostProcessor 类型的 `beanName` 数组，其实就是找所有实现了 BeanPostProcessor 接口的 bean ，然后迭代这些 bean ，将其按照 PriorityOrdered、Ordered、无序的顺序，添加至相应的 List 集合中，最后依次调用 `#sortPostProcessors(List<?> postProcessors, ConfigurableListableBeanFactory beanFactory)` 方法来进行排序处理、 `#registerBeanPostProcessors(ConfigurableListableBeanFactory beanFactory, List<BeanPostProcessor> postProcessors)` 方法来完成注册。
+
+- 【**排序**】很简单，如果 `beanFactory` 为 DefaultListableBeanFactory ，则返回 BeanFactory 所依赖的比较器，否则反正默认的比较器(OrderComparator)，然后调用 `List#sort(Comparator<? super E> c)` 方法即可。代码如下：
+
+  ```
+  // PostProcessorRegistrationDelegate.java
+  private static void sortPostProcessors(List<?> postProcessors, ConfigurableListableBeanFactory beanFactory) {
+  	// 获得 Comparator 对象
+      Comparator<Object> comparatorToUse = null;
+  	if (beanFactory instanceof DefaultListableBeanFactory) { // 依赖的 Comparator 对象
+  		comparatorToUse = ((DefaultListableBeanFactory) beanFactory).getDependencyComparator();
+  	}
+  	if (comparatorToUse == null) { // 默认 Comparator 对象
+  		comparatorToUse = OrderComparator.INSTANCE;
+  	}
+  	// 排序
+  	postProcessors.sort(comparatorToUse);
+  }
+  ```
+
+- 而对于【**注册**】，同样是调用 `AbstractBeanFactory#addBeanPostProcessor(BeanPostProcessor beanPostProcessor)` 方法完成注册。代码如下：
+
+  ```
+  // PostProcessorRegistrationDelegate.java
+  
+  private static void registerBeanPostProcessors(ConfigurableListableBeanFactory beanFactory, List<BeanPostProcessor> postProcessors) {
+      // 遍历 BeanPostProcessor 数组，注册
+  	for (BeanPostProcessor postProcessor : postProcessors) {
+  		beanFactory.addBeanPostProcessor(postProcessor);
+  	}
+  }
+  ```
+
+# 4. 小结
+
+至此，BeanPostProcessor 已经分析完毕了，这里简单总结下：
+
+1. BeanPostProcessor 的作用域是容器级别的，它只和所在的容器相关 ，当 BeanPostProcessor 完成注册后，它会应用于所有跟它在同一个容器内的 bean 。
+2. BeanFactory 和 ApplicationContext 对 BeanPostProcessor 的处理不同，ApplicationContext 会自动检测所有实现了 BeanPostProcessor 接口的 bean，并完成注册，但是使用 BeanFactory 容器时则需要手动调用 `AbstractBeanFactory#addBeanPostProcessor(BeanPostProcessor beanPostProcessor)` 方法来完成注册
+3. ApplicationContext 的 BeanPostProcessor 支持 Ordered，而 BeanFactory 的 BeanPostProcessor 是不支持的，原因在于ApplicationContext 会对 BeanPostProcessor 进行 Ordered 检测并完成排序，而 BeanFactory 中的 BeanPostProcessor 只跟注册的顺序有关。
\ No newline at end of file
diff --git a/spring/33-Spring-IoC 之深入分析 InitializingBean 和 init-method.assets/4b96bfb7f25ce1550985b7463d232121.jpeg b/spring/33-Spring-IoC 之深入分析 InitializingBean 和 init-method.assets/4b96bfb7f25ce1550985b7463d232121.jpeg
new file mode 100644
index 0000000..24b06c1
Binary files /dev/null and b/spring/33-Spring-IoC 之深入分析 InitializingBean 和 init-method.assets/4b96bfb7f25ce1550985b7463d232121.jpeg differ
diff --git a/spring/33-Spring-IoC 之深入分析 InitializingBean 和 init-method.assets/69314ca6b0b46ace994636da2ff473a9.jpeg b/spring/33-Spring-IoC 之深入分析 InitializingBean 和 init-method.assets/69314ca6b0b46ace994636da2ff473a9.jpeg
new file mode 100644
index 0000000..723ff88
Binary files /dev/null and b/spring/33-Spring-IoC 之深入分析 InitializingBean 和 init-method.assets/69314ca6b0b46ace994636da2ff473a9.jpeg differ
diff --git a/spring/33-Spring-IoC 之深入分析 InitializingBean 和 init-method.assets/b42014ec9266892912cfe7da7eddca73.jpeg b/spring/33-Spring-IoC 之深入分析 InitializingBean 和 init-method.assets/b42014ec9266892912cfe7da7eddca73.jpeg
new file mode 100644
index 0000000..3c21e37
Binary files /dev/null and b/spring/33-Spring-IoC 之深入分析 InitializingBean 和 init-method.assets/b42014ec9266892912cfe7da7eddca73.jpeg differ
diff --git a/spring/33-Spring-IoC 之深入分析 InitializingBean 和 init-method.md b/spring/33-Spring-IoC 之深入分析 InitializingBean 和 init-method.md
new file mode 100644
index 0000000..08c1995
--- /dev/null
+++ b/spring/33-Spring-IoC 之深入分析 InitializingBean 和 init-method.md	
@@ -0,0 +1,180 @@
+# 【死磕 Spring】—— IoC 之深入分析 InitializingBean 和 init-method
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=3340 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+Spring 在 bean 初始化时进行三个检测扩展，也就是说我们可以对 bean 进行三个不同的定制化处理，前面两篇博客 [《【死磕 Spring】—— IoC 之深入分析 Aware 接口》](http://svip.iocoder.cn/Spring/IoC-Aware-interface) 和 [《【死磕 Spring】—— IoC 之深入分析 BeanPostProcessor》](http://svip.iocoder.cn/Spring/IoC-BeanPostProcessor) 已经分析了 Aware 接口族和 BeanPostProcessor 接口，这篇分析 InitializingBean 接口和 `init-method` 方法。
+
+# 1. InitializingBean
+
+Spring 的 `org.springframework.beans.factory.InitializingBean` 接口，为 bean 提供了定义初始化方法的方式，它仅包含了一个方法：`#afterPropertiesSet()` 。代码如下：
+
+```
+public interface InitializingBean {
+
+    /**
+     * 该方法在 BeanFactory 设置完了所有属性之后被调用
+     * 该方法允许 bean 实例设置了所有 bean 属性时执行初始化工作，如果该过程出现了错误则需要抛出异常
+     *
+     * Invoked by the containing {@code BeanFactory} after it has set all bean properties
+     * and satisfied {@link BeanFactoryAware}, {@code ApplicationContextAware} etc.
+     * <p>This method allows the bean instance to perform validation of its overall
+     * configuration and final initialization when all bean properties have been set.
+     * @throws Exception in the event of misconfiguration (such as failure to set an
+     * essential property) or if initialization fails for any other reason
+     */
+    void afterPropertiesSet() throws Exception;
+
+}
+```
+
+Spring 在完成实例化后，设置完所有属性，进行 “Aware 接口” 和 “BeanPostProcessor 前置处理”之后，会接着检测当前 bean 对象是否实现了 InitializingBean 接口。如果是，则会调用其 `#afterPropertiesSet()` 方法，进一步调整 bean 实例对象的状态。
+
+## 1.1 示例
+
+```
+public class InitializingBeanTest implements InitializingBean {
+
+    private String name;
+
+    @Override
+    public void afterPropertiesSet() throws Exception {
+        System.out.println("InitializingBeanTest initializing...");
+        this.name = "chenssy 2 号";
+    }
+
+    public String getName() {
+        return name;
+    }
+
+    public void setName(String name) {
+        this.name = name;
+    }
+}
+```
+
+配置项如下：
+
+```
+<bean id="initializingBeanTest" class="org.springframework.core.test.InitializingBeanTest">
+    <property name="name" value="chenssy 1 号"/>
+</bean>
+```
+
+测试代码如下：
+
+```
+InitializingBeanTest test = (InitializingBeanTest) factory.getBean("initializingBeanTest");
+System.out.println("name ：" + test.getName());
+```
+
+执行结果如下：
+
+[![img](33-Spring-IoC 之深入分析 InitializingBean 和 init-method.assets/4b96bfb7f25ce1550985b7463d232121.jpeg)](http://static.iocoder.cn/4b96bfb7f25ce1550985b7463d232121)
+
+在这个示例中，改变了 InitializingBeanTest 示例的 `name` 属性，也就是说 在 `#afterPropertiesSet()` 方法中，我们是可以改变 bean 的属性的，这相当于 Spring 容器又给我们提供了一种可以改变 bean 实例对象的方法。
+
+## 1.2 invokeInitMethods
+
+上面提到 bean 初始化阶段（ `#initializeBean(final String beanName, final Object bean, RootBeanDefinition mbd)` 方法）， Spring 容器会主动检查当前 bean 是否已经实现了 InitializingBean 接口，如果实现了，则会掉用其 `#afterPropertiesSet()` 方法。这个主动检查、调用的动作是由 `#invokeInitMethods(String beanName, final Object bean, @Nullable RootBeanDefinition mbd)` 方法来完成的。代码如下：
+
+```
+// AbstractAutowireCapableBeanFactory.java
+
+protected void invokeInitMethods(String beanName, final Object bean, @Nullable RootBeanDefinition mbd)
+        throws Throwable {
+    // 首先会检查是否是 InitializingBean ，如果是的话需要调用 afterPropertiesSet()
+    boolean isInitializingBean = (bean instanceof InitializingBean);
+    if (isInitializingBean && (mbd == null || !mbd.isExternallyManagedInitMethod("afterPropertiesSet"))) {
+        if (logger.isTraceEnabled()) {
+            logger.trace("Invoking afterPropertiesSet() on bean with name '" + beanName + "'");
+        }
+        if (System.getSecurityManager() != null) { // 安全模式
+            try {
+                AccessController.doPrivileged((PrivilegedExceptionAction<Object>) () -> {
+                    // 属性初始化的处理
+                    ((InitializingBean) bean).afterPropertiesSet();
+                    return null;
+                }, getAccessControlContext());
+            } catch (PrivilegedActionException pae) {
+                throw pae.getException();
+            }
+        } else {
+            // 属性初始化的处理
+            ((InitializingBean) bean).afterPropertiesSet();
+        }
+    }
+
+    if (mbd != null && bean.getClass() != NullBean.class) {
+        // 判断是否指定了 init-method()，
+        // 如果指定了 init-method()，则再调用制定的init-method
+        String initMethodName = mbd.getInitMethodName();
+        if (StringUtils.hasLength(initMethodName) &&
+                !(isInitializingBean && "afterPropertiesSet".equals(initMethodName)) &&
+                !mbd.isExternallyManagedInitMethod(initMethodName)) {
+            // 激活用户自定义的初始化方法
+            // 利用反射机制执行
+            invokeCustomInitMethod(beanName, bean, mbd);
+        }
+    }
+}
+```
+
+- 首先，检测当前 bean 是否实现了 InitializingBean 接口，如果实现了则调用其 `#afterPropertiesSet()` 方法。
+- 然后，再检查是否也指定了 `init-method`，如果指定了则通过反射机制调用指定的 `init-method` 方法。
+
+虽然该接口为 Spring 容器的扩展性立下了汗马功劳，但是如果真的让我们的业务对象来实现这个接口就显得不是那么的友好了，Spring 的一个核心理念就是无侵入性，但是如果我们业务类实现这个接口就显得 Spring 容器具有侵入性了。所以 Spring 还提供了另外一种实现的方式：`init-method` 方法
+
+# 2. init-method
+
+在分析分析 `<bean>` 标签解析过程中，我们提到了有关于 `init-method` 属性 ([《【死磕 Spring】—— IoC 之解析 标签：BeanDefinition》](http://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-for-BeanDefinition))，该属性用于在 bean 初始化时指定执行方法，可以用来替代实现 InitializingBean 接口。
+
+## 2.1 示例
+
+```
+public class InitializingBeanTest {
+
+    private String name;
+
+    public String getName() {
+        return name;
+    }
+
+    public void setName(String name) {
+        this.name = name;
+    }
+
+    public void setOtherName(){
+        System.out.println("InitializingBeanTest setOtherName...");
+        this.name = "chenssy 3 号";
+    }
+}
+```
+
+配置文件如下：
+
+```
+<bean id="initializingBeanTest" class="org.springframework.core.test.InitializingBeanTest"
+        init-method="setOtherName">
+    <property name="name" value="chenssy 1 号"/>
+</bean>
+```
+
+执行结果:
+
+[![img](33-Spring-IoC 之深入分析 InitializingBean 和 init-method.assets/b42014ec9266892912cfe7da7eddca73.jpeg)](http://static.iocoder.cn/b42014ec9266892912cfe7da7eddca73)
+
+完全可以达到和 InitializingBean 一样的效果，而且在代码中我们没有看到丝毫 Spring 侵入的现象。所以通过 `init-method` 我们可以使用业务对象中定义的任何方法来实现 bean 实例对象的初始化定制化，而不再受制于 InitializingBean的 `#afterPropertiesSet()` 方法。同时我们可以使用 `<beans>` 标签的 `default-init-method` 属性来统一指定初始化方法，这样就省了需要在每个 `<bean>` 标签中都设置 `init-method` 这样的繁琐工作了。比如在 `default-init-method` 规定所有初始化操作全部以 `initBean()` 命名。如下：
+
+[![img](33-Spring-IoC 之深入分析 InitializingBean 和 init-method.assets/69314ca6b0b46ace994636da2ff473a9.jpeg)](http://static.iocoder.cn/69314ca6b0b46ace994636da2ff473a9)
+
+# 3. 小结
+
+从 `#invokeInitMethods(...)` 方法中，我们知道 `init-method` 指定的方法会在 `#afterPropertiesSet()` 方法之后执行，如果 `#afterPropertiesSet()` 方法的执行的过程中出现了异常，则 `init-method` 是不会执行的，而且由于 `init-method` 采用的是反射执行的方式，所以 `#afterPropertiesSet()` 方法的执行效率一般会高些，但是并不能排除我们要优先使用 `init-method`，主要是因为它消除了 bean 对 Spring 的依赖，Spring 没有侵入到我们业务代码，这样会更加符合 Spring 的理念。诚然，`init-method` 是基于 xml 配置文件的，就目前而言，我们的工程几乎都摒弃了配置，而采用注释的方式，那么 `@PreDestory` 可能适合你，当然这个注解我们后面分析。
+
+至此，InitializingBean 和 init-method 已经分析完毕了，对于DisposableBean 和 `destroy-method` ，他们和 init 相似，这里就不做阐述了。
\ No newline at end of file
diff --git a/spring/34-Spring-IoC 之深入分析 Bean 的生命周期.assets/2a90a57e3bb96cc6ffa2619babe72bc4.jpeg b/spring/34-Spring-IoC 之深入分析 Bean 的生命周期.assets/2a90a57e3bb96cc6ffa2619babe72bc4.jpeg
new file mode 100644
index 0000000..18c63c3
Binary files /dev/null and b/spring/34-Spring-IoC 之深入分析 Bean 的生命周期.assets/2a90a57e3bb96cc6ffa2619babe72bc4.jpeg differ
diff --git a/spring/34-Spring-IoC 之深入分析 Bean 的生命周期.md b/spring/34-Spring-IoC 之深入分析 Bean 的生命周期.md
new file mode 100644
index 0000000..801bb5a
--- /dev/null
+++ b/spring/34-Spring-IoC 之深入分析 Bean 的生命周期.md	
@@ -0,0 +1,313 @@
+# 【死磕 Spring】—— IoC 之深入分析 Bean 的生命周期
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=todo 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+在分析 Spring Bean 实例化过程中提到 Spring 并不是一启动容器就开启 bean 的实例化进程，只有当客户端通过显示或者隐式的方式调用 BeanFactory 的 `#getBean(...)` 方法来请求某个实例对象的时候，它才会触发相应 bean 的实例化进程。当然，也可以选择直接使用 ApplicationContext 容器，因为该容器启动的时候会立刻调用注册到该容器所有 bean 定义的实例化方法。当然，对于 BeanFactory 容器而言，并不是所有的 `#getBean(...)` 方法都会触发实例化进程，比如 singleton 类型的 bean，该类型的 bean 只会在第一次调用 `getBean()` 的时候才会触发，而后续的调用则会直接返回容器缓存中的实例对象。
+
+`#getBean(...)` 方法，只是 bean 实例化进程的入口，真正的实现逻辑其实是在 AbstractAutowireCapableBeanFactory 的 `#doCreateBean(...)` 中实现，实例化过程如下图：
+
+[![img](34-Spring-IoC 之深入分析 Bean 的生命周期.assets/2a90a57e3bb96cc6ffa2619babe72bc4.jpeg)](http://static.iocoder.cn/2a90a57e3bb96cc6ffa2619babe72bc4)
+
+原来我们采用 new 的方式创建一个对象，用完该对象在其脱离作用域后就会被回收，对于后续操作我们无权也没法干涉，但是采用 Spring 容器后，我们完全摆脱了这种命运，Spring 容器将会对其所有管理的 Bean 对象全部给予一个**统一的生命周期管理**，同时在这个阶段我们也可以对其进行干涉（比如对 bean 进行增强处理，对 bean 进行篡改），如上图。
+
+# 1. bean 实例化
+
+在 `#doCreateBean(...)` 方法中，首先进行 bean 实例化工作，主要由 `#createBeanInstance(...)` 方法实现，该方法返回一个 BeanWrapper 对象。BeanWrapper 对象是 Spring 的一个低级 Bean 基础结构的核心接口，为什么说是**低级**呢？因为这个时候的 Bean 还不能够被我们使用，连最基本的属性都没有设置。而且在我们实际开发过程中，一般都不会直接使用该类，而是通过 BeanFactory 隐式使用。
+
+BeanWrapper 接口有一个默认实现类 BeanWrapperImpl，其主要作用是对 Bean 进行“包裹”，然后对这个包裹的 bean 进行操作，比如后续注入 bean 属性。
+
+在实例化 bean 过程中，Spring 采用“策略模式”来决定采用哪种方式来实例化 bean，一般有反射和 CGLIB 动态字节码两种方式。
+
+InstantiationStrategy 定义了 Bean 实例化策略的抽象接口，其子类 SimpleInstantiationStrategy 提供了基于反射来实例化对象的功能，但是不支持方法注入方式的对象实例化。CglibSubclassingInstantiationStrategy 继承 SimpleInstantiationStrategy，他除了拥有父类以反射实例化对象的功能外，还提供了通过 CGLIB 的动态字节码的功能进而支持方法注入所需的对象实例化需求。默认情况下，Spring 采用 CglibSubclassingInstantiationStrategy。
+
+关于 Bean 实例化的详细过程，请参考以下几篇文章：
+
+1. [【死磕 Spring】—— IoC 之加载 bean：创建 bean（一）之主流程](http://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-1)
+2. [【死磕 Spring】—— IoC 之加载 bean：创建 bean（二）之实例化 Bean 对象(1)](http://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-2)
+3. [【死磕 Spring】—— IoC 之加载 bean：创建 bean（三）之实例化 Bean 对象(2)](http://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-3)
+4. [【死磕 Spring】—— IoC 之加载 bean：创建 bean（四）之属性填充](http://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-4)
+5. [【死磕 Spring】—— IoC 之加载 bean：创建 bean（五）之循环依赖处理](http://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-5)
+6. [【死磕 Spring】—— IoC 之加载 bean：创建 bean（六）之初始化 Bean 对象](http://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-6)
+
+对于 BeanWrapper 和 具体的实例化策略，LZ 在后面会专门写文章来进行详细说明。
+
+# 2. 激活 Aware
+
+当 Spring 完成 bean 对象实例化并且设置完相关属性和依赖后，则会开始 bean 的初始化进程（ `#initializeBean(...)` ），初始化第一个阶段是检查当前 bean 对象是否实现了一系列以 Aware 结尾的的接口。
+
+Aware 接口为 Spring 容器的核心接口，是一个具有标识作用的超级接口，实现了该接口的 bean 是具有被 Spring 容器通知的能力，通知的方式是采用回调的方式。
+
+在初始化阶段主要是感知 BeanNameAware、BeanClassLoaderAware、BeanFactoryAware 。代码如下：
+
+```
+// AbstractAutowireCapableBeanFactory.java
+
+private void invokeAwareMethods(final String beanName, final Object bean) {
+	if (bean instanceof Aware) {
+	    // BeanNameAware
+		if (bean instanceof BeanNameAware) {
+			((BeanNameAware) bean).setBeanName(beanName);
+		}
+		// BeanClassLoaderAware
+		if (bean instanceof BeanClassLoaderAware) {
+			ClassLoader bcl = getBeanClassLoader();
+			if (bcl != null) {
+				((BeanClassLoaderAware) bean).setBeanClassLoader(bcl);
+			}
+		}
+		// BeanFactoryAware
+		if (bean instanceof BeanFactoryAware) {
+			((BeanFactoryAware) bean).setBeanFactory(AbstractAutowireCapableBeanFactory.this);
+		}
+	}
+}
+```
+
+- BeanNameAware：对该 bean 对象定义的 beanName 设置到当前对象实例中
+- BeanClassLoaderAware：将当前 bean 对象相应的 ClassLoader 注入到当前对象实例中
+- BeanFactoryAware：BeanFactory 容器会将自身注入到当前对象实例中，这样当前对象就会拥有一个 BeanFactory 容器的引用。
+
+当然，Spring 不仅仅只是提供了上面三个 Aware 接口，而是一系列：
+
+- LoadTimeWeaverAware：加载Spring Bean时织入第三方模块，如AspectJ
+- BootstrapContextAware：资源适配器BootstrapContext，如JCA,CCI
+- ResourceLoaderAware：底层访问资源的加载器
+- PortletConfigAware：PortletConfig
+- PortletContextAware：PortletContext
+- ServletConfigAware：ServletConfig
+- ServletContextAware：ServletContext
+- MessageSourceAware：国际化
+- ApplicationEventPublisherAware：应用事件
+- NotificationPublisherAware：JMX通知
+
+更多关于 Aware 的请关注：[《【死磕 Spring】—— IoC 之深入分析 Aware 接口》](http://svip.iocoder.cn/Spring/IoC-Aware-interface) 。
+
+# 3. BeanPostProcessor
+
+初始化第二个阶段则是 BeanPostProcessor 增强处理，在该阶段 BeanPostProcessor 会处理当前容器内所有符合条件的实例化后的 bean 对象。它主要是对 Spring 容器提供的 bean 实例对象进行有效的扩展，允许 Spring 在初始化 bean 阶段对其进行定制化修改，如处理标记接口或者为其提供代理实现。
+
+BeanPostProcessor 接口提供了两个方法，在不同的时机执行，分别对应上图的前置处理和后置处理。代码如下：
+
+```
+public interface BeanPostProcessor {
+
+	@Nullable
+	default Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
+		return bean;
+	}
+
+	@Nullable
+	default Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
+		return bean;
+	}
+
+}
+```
+
+更多关于 BeanPostProcessor 的请关注：[《【死磕 Spring】—— IoC 之深入分析 BeanPostProcessor》](http://svip.iocoder.cn/Spring/IoC-BeanPostProcessor) 。
+
+# 4. InitializingBean 和 init-method
+
+InitializingBean 是一个接口，它为 Spring Bean 的初始化提供了一种方式，它有一个 `#afterPropertiesSet()` 方法，在 bean 的初始化进程中会判断当前 bean 是否实现了 InitializingBean，如果实现了则调用 `#afterPropertiesSet()` 方法，进行初始化工作。然后再检查是否也指定了 `init-method` ，如果指定了则通过反射机制调用指定的 `init-method` 方法。代码如下：
+
+```
+// AbstractAutowireCapableBeanFactory.java
+
+protected void invokeInitMethods(String beanName, final Object bean, @Nullable RootBeanDefinition mbd)
+		throws Throwable {
+    // 首先会检查是否是 InitializingBean ，如果是的话需要调用 afterPropertiesSet()
+	boolean isInitializingBean = (bean instanceof InitializingBean);
+	if (isInitializingBean && (mbd == null || !mbd.isExternallyManagedInitMethod("afterPropertiesSet"))) {
+		if (logger.isTraceEnabled()) {
+			logger.trace("Invoking afterPropertiesSet() on bean with name '" + beanName + "'");
+		}
+		if (System.getSecurityManager() != null) { // 安全模式
+			try {
+				AccessController.doPrivileged((PrivilegedExceptionAction<Object>) () -> {
+                    // 属性初始化的处理
+					((InitializingBean) bean).afterPropertiesSet();
+					return null;
+				}, getAccessControlContext());
+			} catch (PrivilegedActionException pae) {
+				throw pae.getException();
+			}
+		} else {
+            // 属性初始化的处理
+			((InitializingBean) bean).afterPropertiesSet();
+		}
+	}
+
+	if (mbd != null && bean.getClass() != NullBean.class) {
+        // 判断是否指定了 init-method()，
+        // 如果指定了 init-method()，则再调用制定的init-method
+		String initMethodName = mbd.getInitMethodName();
+		if (StringUtils.hasLength(initMethodName) &&
+				!(isInitializingBean && "afterPropertiesSet".equals(initMethodName)) &&
+				!mbd.isExternallyManagedInitMethod(initMethodName)) {
+            // 激活用户自定义的初始化方法
+            // 利用反射机制执行
+			invokeCustomInitMethod(beanName, bean, mbd);
+		}
+	}
+}
+```
+
+对于 Spring 而言，虽然上面两种方式都可以实现初始化定制化，但是更加推崇 `init-method` 方式，因为对于 InitializingBean 接口而言，他需要 bean 去实现接口，这样就会污染我们的应用程序，显得 Spring 具有一定的侵入性。但是由于 `init-method` 是采用反射的方式，所以执行效率上相对于 InitializingBean 接口回调的方式可能会低一些。
+
+更多关于 init 的请关注：[《【死磕 Spring】—— IoC 之 深入分析 InitializingBean 和 init-method》](http://svip.iocoder.cn/Spring/IoC-InitializingBean-and-init-method)
+
+# 5. DisposableBean 和 destroy-method
+
+与 InitializingBean 和 `init-method` 用于对象的自定义初始化工作相似，DisposableBean和 `destroy-method` 则用于对象的自定义销毁工作。
+
+当一个 bean 对象经历了实例化、设置属性、初始化阶段，那么该 bean 对象就可以供容器使用了（调用的过程）。当完成调用后，如果是 singleton 类型的 bean ，则会看当前 bean 是否应实现了 DisposableBean 接口或者配置了 `destroy-method` 属性，如果是的话，则会为该实例注册一个用于对象销毁的回调方法，便于在这些 singleton 类型的 bean 对象销毁之前执行销毁逻辑。
+
+但是，并不是对象完成调用后就会立刻执行销毁方法，因为这个时候 Spring 容器还处于运行阶段，只有当 Spring 容器关闭的时候才会去调用。但是， Spring 容器不会这么聪明会自动去调用这些销毁方法，而是需要我们主动去告知 Spring 容器。
+
+- 对于 BeanFactory 容器而言，我们需要主动调用 `#destroySingletons()` 方法，通知 BeanFactory 容器去执行相应的销毁方法。
+- 对于 ApplicationContext 容器而言，调用 `#registerShutdownHook()` 方法。
+
+# 6. 实践验证
+
+下面用一个实例来真实看看看上面执行的逻辑，毕竟理论是不能缺少实践的：
+
+```
+public class LifeCycleBean implements BeanNameAware,BeanFactoryAware,BeanClassLoaderAware,BeanPostProcessor,
+        InitializingBean,DisposableBean {
+
+    private String test;
+
+    public String getTest() {
+        return test;
+    }
+
+    public void setTest(String test) {
+        System.out.println("属性注入....");
+        this.test = test;
+    }
+
+    public LifeCycleBean(){ // 构造方法
+        System.out.println("构造函数调用...");
+    }
+
+    public void display(){
+        System.out.println("方法调用...");
+    }
+
+    @Override
+    public void setBeanFactory(BeanFactory beanFactory) throws BeansException {
+        System.out.println("BeanFactoryAware 被调用...");
+    }
+
+    @Override
+    public void setBeanName(String name) {
+        System.out.println("BeanNameAware 被调用...");
+    }
+
+    @Override
+    public void setBeanClassLoader(ClassLoader classLoader) {
+        System.out.println("BeanClassLoaderAware 被调用...");
+    }
+
+    @Override
+    public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
+        System.out.println("BeanPostProcessor postProcessBeforeInitialization 被调用...");
+        return bean;
+    }
+
+    @Override
+    public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
+        System.out.println("BeanPostProcessor postProcessAfterInitialization 被调用...");
+        return bean;
+    }
+
+    @Override
+    public void destroy() throws Exception {
+        System.out.println("DisposableBean destroy 被调动...");
+    }
+
+    @Override
+    public void afterPropertiesSet() throws Exception {
+        System.out.println("InitializingBean afterPropertiesSet 被调动...");
+    }
+
+    public void initMethod(){
+        System.out.println("init-method 被调用...");
+    }
+
+    public void destroyMethdo(){
+        System.out.println("destroy-method 被调用...");
+    }
+
+}
+```
+
+- LifeCycleBean 继承了 `BeanNameAware` , `BeanFactoryAware` , `BeanClassLoaderAware` , `BeanPostProcessor` , `InitializingBean` , `DisposableBean` 六个接口，同时定义了一个 `test` 属性用于验证属性注入和提供一个 `#display()` 方法用于模拟调用。
+
+配置如下：
+
+```
+<bean id="lifeCycle" class="org.springframework.core.test.lifeCycleBean"
+        init-method="initMethod" destroy-method="destroyMethdo">
+    <property name="test" value="test"/>
+</bean>
+```
+
+- 配置 `init-method` 和 `destroy-method`。
+
+测试方法如下：
+
+```
+// BeanFactory 容器一定要调用该方法进行 BeanPostProcessor 注册
+factory.addBeanPostProcessor(new LifeCycleBean()); // <1>
+
+LifeCycleBean lifeCycleBean = (LifeCycleBean) factory.getBean("lifeCycle");
+lifeCycleBean.display();
+
+System.out.println("方法调用完成，容器开始关闭....");
+// 关闭容器
+factory.destroySingletons();
+```
+
+运行结果：
+
+```
+构造函数调用...
+构造函数调用...
+属性注入....
+BeanNameAware 被调用...
+BeanClassLoaderAware 被调用...
+BeanFactoryAware 被调用...
+BeanPostProcessor postProcessBeforeInitialization 被调用...
+InitializingBean afterPropertiesSet 被调动...
+init-method 被调用...
+BeanPostProcessor postProcessAfterInitialization 被调用...
+方法调用...
+方法调用完成，容器开始关闭....
+DisposableBean destroy 被调动...
+destroy-method 被调用...
+```
+
+- 有两个构造函数调用，是因为要 `<1>` 处注入一个 BeanPostProcessor（你也可以另外提供一个 BeanPostProcessor 实例）。
+
+根据执行的结果已经上面的分析，我们就可以对 Spring Bean 的声明周期过程如下（方法级别）：
+
+1. Spring 容器根据实例化策略对 Bean 进行实例化。
+2. 实例化完成后，如果该 bean 设置了一些属性的话，则利用 set 方法设置一些属性。
+3. 如果该 Bean 实现了 BeanNameAware 接口，则调用 `#setBeanName(String beanName)` 方法。
+4. 如果该 bean 实现了 BeanClassLoaderAware 接口，则调用 `setBeanClassLoader(ClassLoader classLoader)` 方法。
+5. 如果该 bean 实现了 BeanFactoryAware接口，则调用 `setBeanFactory(BeanFactory beanFactory)` 方法。
+6. 如果该容器注册了 BeanPostProcessor，则会调用`#postProcessBeforeInitialization(Object bean, String beanName)` 方法,完成 bean 前置处理
+7. 如果该 bean 实现了 InitializingBean 接口，则调用`#afterPropertiesSet()` 方法。
+8. 如果该 bean 配置了 `init-method` 方法，则调用其指定的方法。
+9. 初始化完成后，如果该容器注册了 BeanPostProcessor 则会调用 `#postProcessAfterInitialization(Object bean, String beanName)` 方法,完成 bean 的后置处理。
+10. 对象完成初始化，开始方法调用。
+11. 在容器进行关闭之前，如果该 bean 实现了 DisposableBean 接口，则调用 `#destroy()` 方法。
+12. 在容器进行关闭之前，如果该 bean 配置了 `destroy-method` ，则调用其指定的方法。
+13. 到这里一个 bean 也就完成了它的一生。
\ No newline at end of file
diff --git a/spring/35-Spring-IoC 之深入分析 BeanFactoryPostProcessor.md b/spring/35-Spring-IoC 之深入分析 BeanFactoryPostProcessor.md
new file mode 100644
index 0000000..0cafe65
--- /dev/null
+++ b/spring/35-Spring-IoC 之深入分析 BeanFactoryPostProcessor.md	
@@ -0,0 +1,142 @@
+# 【死磕 Spring】—— IoC 之深入分析 BeanFactoryPostProcessor
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=todo 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+在博客 [《【死磕 Spring】—— IoC 之 深入分析 BeanPostProcessor》](http://svip.iocoder.cn/Spring/IoC-BeanPostProcessor) 中，深入介绍了 BeanPostProcessor 的实现机制。在这篇文章中提到 BeanPostProcessor 是 Spring 提供一种扩展机制，该机制允许我们在 Bean 实例化之后初始化之际对 Bean 进行增强处理（前、后置处理）。
+
+同样在 Spring 容器启动阶段，Spring 也提供了一种容器扩展机制：**BeanFactoryPostProcessor**，该机制作用于容器启动阶段，允许我们在容器实例化 Bean 之前对注册到该容器的 BeanDefinition 做出修改。
+
+# 1. BeanFactoryPostProcessor
+
+BeanFactoryPostProcessor 的机制，就相当于给了我们在 Bean 实例化之前最后一次修改 BeanDefinition 的机会，我们可以利用这个机会对 BeanDefinition 来进行一些额外的操作，比如更改某些 bean 的一些属性，给某些 Bean 增加一些其他的信息等等操作。
+
+`org.springframework.beans.factory.config.BeanFactoryPostProcessor` 接口，定义如下：
+
+```
+public interface BeanFactoryPostProcessor {
+
+ /**
+  * 1、Modify the application context's internal bean factory after its standard initialization.
+  *
+  * 2、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.
+  *
+  * @param beanFactory the bean factory used by the application context
+  * @throws org.springframework.beans.BeansException in case of errors
+  */
+ void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException;
+
+}
+```
+
+BeanFactoryPostProcessor 接口仅有一个 `#postProcessBeanFactory(...)` 方法，该方法接收一个 ConfigurableListableBeanFactory 类型的 `beanFactory` 参数。上面有两行注释：
+
+- 1、表示了该方法的**作用**：在 standard initialization（实在是不知道这个怎么翻译：标准的初始化？） 之后（已经就是已经完成了 BeanDefinition 的加载）对 bean factory 容器进行修改。其中参数 `beanFactory` 应该就是已经完成了 standard initialization 的 BeanFactory 。
+- 2、表示作用**时机**：所有的 BeanDefinition 已经完成了加载即加载至 BeanFactory 中，但是还没有完成初始化。
+
+所以这里总结一句话，就是：`#postProcessBeanFactory(...)` 方法，工作于 BeanDefinition 加载完成之后，Bean 实例化之前，其主要作用是对加载 BeanDefinition 进行修改。有一点需要需要**注意**的是在 `#postProcessBeanFactory(...)` 方法中，千万不能进行 Bean 的实例化工作，因为这样会导致 Bean 过早实例化，会产生严重后果，**我们始终需要注意的是 BeanFactoryPostProcessor 是与 BeanDefinition 打交道的，如果想要与 Bean 打交道，请使用 BeanPostProcessor** 。
+
+与 BeanPostProcessor 一样，BeanFactoryPostProcessor 同样支持**排序**，一个容器可以同时拥有多个 BeanFactoryPostProcessor ，这个时候如果我们比较在乎他们的顺序的话，可以实现 Ordered 接口。
+
+如果要自定义 BeanFactoryPostProcessor ，直接实现该接口即可。
+
+# 2. 示例
+
+```
+public class BeanFactoryPostProcessor_1 implements BeanFactoryPostProcessor,Ordered {
+
+    @Override
+    public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
+        System.out.println("调用 BeanFactoryPostProcessor_1 ...");
+
+        System.out.println("容器中有 BeanDefinition 的个数：" + beanFactory.getBeanDefinitionCount());
+
+        // 获取指定的 BeanDefinition
+        BeanDefinition bd = beanFactory.getBeanDefinition("studentService");
+
+        MutablePropertyValues pvs = bd.getPropertyValues();
+
+        pvs.addPropertyValue("name","chenssy1");
+        pvs.addPropertyValue("age",15);
+    }
+
+    @Override
+    public int getOrder() {
+        return 1;
+    }
+}
+
+public class BeanFactoryPostProcessor_2 implements BeanFactoryPostProcessor , Ordered {
+
+    @Override
+    public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
+        System.out.println("调用 BeanFactoryPostProcessor_2 ...");
+
+        // 获取指定的 BeanDefinition
+        BeanDefinition bd = beanFactory.getBeanDefinition("studentService");
+
+        MutablePropertyValues pvs = bd.getPropertyValues();
+
+        pvs.addPropertyValue("age",18);
+    }
+
+    @Override
+    public int getOrder() {
+        return 2;
+    }
+}
+```
+
+- 提供了两个自定义的 BeanFactoryPostProcessor ，都继承 BeanFactoryPostProcessor 和 Ordered，其中 BeanFactoryPostProcessor_1 改变 `name` 和 `age` 的值，BeanFactoryPostProcessor_2 该变 `age` 的值。Ordered 分别为 1 和 2 。
+
+XML 配置如下：
+
+```
+<bean id="studentService" class="org.springframework.core.service.StudentService">
+    <property name="name" value="chenssy"/>
+    <property name="age" value="10"/>
+</bean>
+
+<bean class="org.springframework.core.test.BeanFactoryPostProcessor_1"/>
+<bean class="org.springframework.core.test.BeanFactoryPostProcessor_2"/>
+```
+
+- `studentService` 设置 `name` 和 `age` 分别为 `"chenss"` 和 10 。
+
+运行代码：
+
+```
+ApplicationContext context = new ClassPathXmlApplicationContext("spring.xml");
+
+StudentService studentService = (StudentService) context.getBean("studentService");
+System.out.println("student name:" + studentService.getName() + "-- age:" + studentService.getAge());
+```
+
+运行结果：
+
+```
+调用 BeanFactoryPostProcessor_1 ...
+容器中有 BeanDefinition 的个数：3
+调用 BeanFactoryPostProcessor_2 ...
+student name:chenssy1-- age:18
+```
+
+- 看到运行结果，其实对上面的运行流程就已经一清二楚了。这里就不过多阐述了。
+
+# 3. 原理
+
+在上面测试方法中，我们使用的是 ApplicationContext ，对于 ApplicationContext 来说，使用 BeanFactoryPostProcessor 非常方便，因为他会自动识别配置文件中的 BeanFactoryPostProcessor 并且完成注册和调用，我们只需要简单的配置声明即可。而对于 BeanFactory 容器来说则不行，他和 BeanPostProcessor 一样需要容器主动去进行注册调用，方法如下：
+
+```
+BeanFactoryPostProcessor_1 beanFactoryPostProcessor1 = new BeanFactoryPostProcessor_1();
+beanFactoryPostProcessor1.postProcessBeanFactory(factory);
+```
+
+**至于 ApplicationContext 是如何自动识别和调用，这个我们后续在分析 ApplicationContext 时会做详细说明的，当然，如果有兴趣的同学可以提前看**。
+
+诚然，一般情况下我们是不会主动去自定义 BeanFactoryPostProcessor ，其实 Spring 为我们提供了几个常用的 BeanFactoryPostProcessor，他们是PropertyPlaceholderConfigurer 和 PropertyOverrideConfigurer ，其中 PropertyPlaceholderConfigurer 允许我们在 XML 配置文件中使用占位符并将这些占位符所代表的资源单独配置到简单的 properties 文件中来加载，PropertyOverrideConfigurer 则允许我们使用占位符来明确表明bean 定义中的 property 与 properties 文件中的各配置项之间的对应关系，这两个类在我们大型项目中有非常重要的作用，后续两篇文章将对其进行详细说明分析。
\ No newline at end of file
diff --git a/spring/36-Spring-IoC 之深入分析 PropertyPlaceholderConfigurer.assets/201809161001.png b/spring/36-Spring-IoC 之深入分析 PropertyPlaceholderConfigurer.assets/201809161001.png
new file mode 100644
index 0000000..9b25a9e
Binary files /dev/null and b/spring/36-Spring-IoC 之深入分析 PropertyPlaceholderConfigurer.assets/201809161001.png differ
diff --git a/spring/36-Spring-IoC 之深入分析 PropertyPlaceholderConfigurer.md b/spring/36-Spring-IoC 之深入分析 PropertyPlaceholderConfigurer.md
new file mode 100644
index 0000000..766e867
--- /dev/null
+++ b/spring/36-Spring-IoC 之深入分析 PropertyPlaceholderConfigurer.md	
@@ -0,0 +1,408 @@
+# 【死磕 Spring】—— IoC 之深入分析 PropertyPlaceholderConfigurer
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=todo 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+在上文 [《【死磕 Spring】—— IoC 之深入分析 BeanFactoryPostProcessor》](http://svip.iocoder.cn/Spring/IoC-BeanFactoryPostProcessor) 中，介绍了 BeanFactoryPostProcessor，知道 BeanFactoryPostProcessor 作用域容器启动阶段，可以对解析好的 BeanDefinition 进行定制化处理，而其中 **PropertyPlaceholderConfigurer** 是其一个非常重要的应用，也是其**子类**，介绍如下：
+
+> PropertyPlaceholderConfigurer 允许我们用 Properties 文件中的属性，来定义应用上下文（配置文件或者注解）。
+
+什么意思，就是说我们在 XML 配置文件（或者其他方式，如注解方式）中使用**占位符**的方式来定义一些资源，并将这些占位符所代表的资源配置到 Properties 中，这样只需要对 Properties 文件进行修改即可，这个特性非常，在后面来介绍一种我们在项目中经常用到场景。
+
+# 1. PropertyResourceConfigurer
+
+[![201809161001](36-Spring-IoC 之深入分析 PropertyPlaceholderConfigurer.assets/201809161001.png)](http://static.iocoder.cn/201809161001.png)201809161001
+
+从 PropertyPlaceholderConfigurer 的结构图可以看出，它间接实现了 Aware 和 BeanFactoryPostProcessor 两大扩展接口，这里只需要关注 BeanFactoryPostProcessor 即可。我们知道 BeanFactoryPostProcessor 提供了 `#postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory)` 接口方法，在这个体系中该方法的是在 **PropertyResourceConfigurer** 中实现，该类为属性资源的配置类，它实现了 BeanFactoryPostProcessor 接口，代码如下：
+
+```
+// PropertyResourceConfigurer.java
+// extends PropertiesLoaderSupport
+// implements BeanFactoryPostProcessor, PriorityOrdered
+
+@Override
+public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
+    try {
+        // <1> 返回合并的 Properties 实例
+        Properties mergedProps = mergeProperties();
+
+        // Convert the merged properties, if necessary.
+        // <2> 转换合并属性
+        convertProperties(mergedProps);
+
+        // Let the subclass process the properties.
+        // <3> 子类处理
+        processProperties(beanFactory, mergedProps);
+    } catch (IOException ex) {
+        throw new BeanInitializationException("Could not load properties", ex);
+    }
+}
+```
+
+- `<1>` 处，调用 `#mergeProperties()` 方法，返回合并的 Properties 实例。Properties 实例维护这**一组** `key-value` ，其实就是 Properties 配置文件中的内容。
+
+- `<2>` 处，调用 `#convertProperties(Properties props)` 方法，转换合并的值，其实就是将原始值替换为真正的值。
+
+- `<3>` 处，调用 `#processProperties(ConfigurableListableBeanFactory beanFactory, Properties props)` 方法，前面两个步骤已经将配置文件中的值进行了处理，那么该方法就是真正的替换过程，该方法**由子类实现**。代码如下：
+
+  ```
+  // PropertyResourceConfigurer.java
+  
+  protected abstract void processProperties(ConfigurableListableBeanFactory beanFactory, Properties props)
+  		throws BeansException;
+  ```
+
+# 2. PropertyPlaceholderConfigurer
+
+在 PropertyPlaceholderConfigurer 中，重写 `#processProperties(ConfigurableListableBeanFactory beanFactory, Properties props)` 方法，代码如下：
+
+```
+// PropertyPlaceholderConfigurer.java
+
+@Override
+protected void processProperties(ConfigurableListableBeanFactory beanFactoryToProcess, Properties props)
+        throws BeansException {
+    // <1> 创建 StringValueResolver 对象
+    StringValueResolver valueResolver = new PlaceholderResolvingStringValueResolver(props);
+    // <2> 处理
+    doProcessProperties(beanFactoryToProcess, valueResolver);
+}
+```
+
+## 2.1 PlaceholderResolvingStringValueResolver
+
+> 对应 `#processProperties(ConfigurableListableBeanFactory beanFactoryToProcess, Properties props)` 方法的 `<1>` 处。
+
+首先，构造一个 PlaceholderResolvingStringValueResolver 类型的 StringValueResolver 实例。StringValueResolver 为一个解析 String 类型值的策略接口，该接口提供了 `#resolveStringValue(String strVal)` 方法，用于解析 String 值。PlaceholderResolvingStringValueResolver 为其一个解析策略，构造方法如下：
+
+```
+// PropertyPlaceholderConfigurer.java
+    
+private class PlaceholderResolvingStringValueResolver implements StringValueResolver {
+    
+	private final PropertyPlaceholderHelper helper;
+    
+	private final PlaceholderResolver resolver;
+    
+	public PlaceholderResolvingStringValueResolver(Properties props) {
+		this.helper = new PropertyPlaceholderHelper(
+				placeholderPrefix, placeholderSuffix, valueSeparator, ignoreUnresolvablePlaceholders);
+		this.resolver = new PropertyPlaceholderConfigurerResolver(props);
+	}
+	
+	// ... 省略 resolveStringValue 方法
+}
+```
+
+- 在构造 String 值解析器 StringValueResolver 时，将已经解析的 Properties 实例对象封装在 PlaceholderResolver 实例 `resolver` 中。PlaceholderResolver 是一个用于解析字符串中包含占位符的替换值的策略接口，该接口有一个 `#resolvePlaceholder(String strVa)` 方法，用于返回占位符的替换值。
+- 还有一个 PropertyPlaceholderHelper 工具 `helper` ，从名字上面看应该是进行替换的工具类。
+
+## 2.2 doProcessProperties
+
+> 对应 `#processProperties(ConfigurableListableBeanFactory beanFactoryToProcess, Properties props)` 方法的 `<2>` 处。
+
+然后，得到 String 解析器的实例 `valueResolver` 后，则会调用 `#doProcessProperties(ConfigurableListableBeanFactory beanFactoryToProcess, StringValueResolver valueResolver)` 方法，来进行真值的替换操作。该方法在父类 PlaceholderConfigurerSupport 中实现，代码如下：
+
+```
+// PlaceholderConfigurerSupport.java
+    
+protected void doProcessProperties(ConfigurableListableBeanFactory beanFactoryToProcess,
+        StringValueResolver valueResolver) {
+    // <2.1> 创建 BeanDefinitionVisitor 对象
+    BeanDefinitionVisitor visitor = new BeanDefinitionVisitor(valueResolver);
+    
+    String[] beanNames = beanFactoryToProcess.getBeanDefinitionNames();
+    for (String curName : beanNames) {
+        // 校验
+        // Check that we're not parsing our own bean definition,
+        // to avoid failing on unresolvable placeholders in properties file locations.
+        if (!(curName.equals(this.beanName) // 1. 当前实例 PlaceholderConfigurerSupport 不在解析范围内
+                && beanFactoryToProcess.equals(this.beanFactory))) { // 2. 同一个 Spring 容器
+            BeanDefinition bd = beanFactoryToProcess.getBeanDefinition(curName);
+            try {
+                visitor.visitBeanDefinition(bd);
+            } catch (Exception ex) {
+                throw new BeanDefinitionStoreException(bd.getResourceDescription(), curName, ex.getMessage(), ex);
+            }
+        }
+    }
+    
+    // New in Spring 2.5: resolve placeholders in alias target names and aliases as well.
+    // <2.3> 别名的占位符
+    beanFactoryToProcess.resolveAliases(valueResolver);
+    
+    // New in Spring 3.0: resolve placeholders in embedded values such as annotation attributes.
+    // <2.4> 解析嵌入值的占位符，例如注释属性
+    beanFactoryToProcess.addEmbeddedValueResolver(valueResolver);
+}
+```
+
+- `<2.1`> 处，根据 String 值解析策略 `valueResolver` 得到 BeanDefinitionVisitor 实例。BeanDefinitionVisitor 是 BeanDefinition 的访问者，我们通过它可以实现对 BeanDefinition 内容的进行访问，内容很多，例如 Scope、PropertyValues、FactoryMethodName 等等。
+- `<2.2`> 处，得到该容器的所有 BeanName，然后对其进行访问（ `#visitBeanDefinition(BeanDefinition beanDefinition)` 方法）。
+- `<2.3`> 处，解析别名的占位符。
+- `<2.4`> 处，解析嵌入值的占位符，例如注释属性。
+
+### 2.2.1 visitBeanDefinition
+
+这个方法的**核心**在于 `#visitBeanDefinition(BeanDefinition beanDefinition)` 方法的调用，代码如下：
+
+```
+// BeanDefinitionVisitor.java
+
+public void visitBeanDefinition(BeanDefinition beanDefinition) {
+	visitParentName(beanDefinition);
+	visitBeanClassName(beanDefinition);
+	visitFactoryBeanName(beanDefinition);
+	visitFactoryMethodName(beanDefinition);
+	visitScope(beanDefinition);
+	if (beanDefinition.hasPropertyValues()) {
+		visitPropertyValues(beanDefinition.getPropertyValues());
+	}
+	if (beanDefinition.hasConstructorArgumentValues()) {
+		ConstructorArgumentValues cas = beanDefinition.getConstructorArgumentValues();
+		visitIndexedArgumentValues(cas.getIndexedArgumentValues());
+		visitGenericArgumentValues(cas.getGenericArgumentValues());
+	}
+}
+```
+
+- 我们可以看到该方法基本访问了 BeanDefinition 中所有值得访问的东西了，包括 parent 、class 、factory-bean 、factory-method 、scope 、property 、constructor-arg 。
+
+### 2.2.2 visitPropertyValues
+
+本篇文章的主题是 **property** ，所以关注 `#visitPropertyValues(MutablePropertyValues pvs)` 方法即可。代码如下：
+
+```
+// BeanDefinitionVisitor.java
+
+protected void visitPropertyValues(MutablePropertyValues pvs) {
+    PropertyValue[] pvArray = pvs.getPropertyValues();
+    // 遍历 PropertyValue 数组
+    for (PropertyValue pv : pvArray) {
+        // 解析真值
+        Object newVal = resolveValue(pv.getValue());
+        if (!ObjectUtils.nullSafeEquals(newVal, pv.getValue())) {
+            // 设置到 PropertyValue 中
+            pvs.add(pv.getName(), newVal);
+        }
+    }
+}
+```
+
+- 过程就是对属性数组进行遍历，调用 `#resolveValue(Object value)`方法，对属性进行解析获取最新值，如果新值和旧值不等，则用新值替换旧值。
+
+#### 2.2.2.1 resolveValue
+
+`#resolveValue(Object value)` 方法，代码如下：
+
+```
+// BeanDefinitionVisitor.java
+
+@Nullable
+protected Object resolveValue(@Nullable Object value) {
+	if (value instanceof BeanDefinition) {
+		visitBeanDefinition((BeanDefinition) value);
+	} else if (value instanceof BeanDefinitionHolder) {
+		visitBeanDefinition(((BeanDefinitionHolder) value).getBeanDefinition());
+	} else if (value instanceof RuntimeBeanReference) {
+		RuntimeBeanReference ref = (RuntimeBeanReference) value;
+		String newBeanName = resolveStringValue(ref.getBeanName());
+		if (newBeanName == null) {
+			return null;
+		}
+		if (!newBeanName.equals(ref.getBeanName())) {
+			return new RuntimeBeanReference(newBeanName);
+		}
+	} else if (value instanceof RuntimeBeanNameReference) {
+		RuntimeBeanNameReference ref = (RuntimeBeanNameReference) value;
+		String newBeanName = resolveStringValue(ref.getBeanName());
+		if (newBeanName == null) {
+			return null;
+		}
+		if (!newBeanName.equals(ref.getBeanName())) {
+			return new RuntimeBeanNameReference(newBeanName);
+		}
+	} else if (value instanceof Object[]) {
+		visitArray((Object[]) value);
+	} else if (value instanceof List) {
+		visitList((List) value);
+	} else if (value instanceof Set) {
+		visitSet((Set) value);
+	} else if (value instanceof Map) {
+		visitMap((Map) value);
+	} else if (value instanceof TypedStringValue) {
+		TypedStringValue typedStringValue = (TypedStringValue) value;
+		String stringValue = typedStringValue.getValue();
+		if (stringValue != null) {
+			String visitedString = resolveStringValue(stringValue);
+			typedStringValue.setValue(visitedString);
+		}
+	// 由于 Properties 中的是 String，所以重点在此处
+	} else if (value instanceof String) {
+		return resolveStringValue((String) value);
+	}
+	return value;
+}
+```
+
+- 由于配置的是 String 类型，所以只需要看 String 相关的。
+
+#### 2.2.2.2 resolveStringValue
+
+`#resolveStringValue(String strVal)` 方法，代码如下：
+
+```
+// BeanDefinitionVisitor.java
+
+@Nullable
+protected String resolveStringValue(String strVal) {
+	if (this.valueResolver == null) {
+		throw new IllegalStateException("No StringValueResolver specified - pass a resolver " +
+				"object into the constructor or override the 'resolveStringValue' method");
+	}
+	// 解析真值
+	String resolvedValue = this.valueResolver.resolveStringValue(strVal);
+	// Return original String if not modified.
+	return (strVal.equals(resolvedValue) ? strVal : resolvedValue);
+}
+```
+
+- `valueResolver` 是我们在构造 BeanDefinitionVisitor 实例时传入的 String 类型解析器 PlaceholderResolvingStringValueResolver，调用其 `#resolveStringValue(String strVal)` 方法，代码如下：
+
+```
+// PropertyPlaceholderConfigurer.java
+// 内部类 PlaceholderResolvingStringValueResolver.java
+
+@Override
+@Nullable
+public String resolveStringValue(String strVal) throws BeansException {
+    // 解析真值
+	String resolved = this.helper.replacePlaceholders(strVal, this.resolver);
+	// trim
+	if (trimValues) {
+		resolved = resolved.trim();
+	}
+	// 返回真值
+	return (resolved.equals(nullValue) ? null : resolved);
+}
+```
+
+- `helper` 为 PropertyPlaceholderHelper 实例对象，而 PropertyPlaceholderHelper 则是处理应用程序中包含占位符的字符串工具类。在构造 `helper` 实例对象时需要传入了几个参数：`placeholderPrefix`、`placeholderSuffix`、`valueSeparator`，这些值在 PlaceholderConfigurerSupport 中定义如下：
+
+  ```
+  // PlaceholderConfigurerSupport.java
+  	
+  /** Default placeholder prefix: {@value}. */
+  public static final String DEFAULT_PLACEHOLDER_PREFIX = "${";
+  /** Default placeholder suffix: {@value}. */
+  public static final String DEFAULT_PLACEHOLDER_SUFFIX = "}";
+  /** Default value separator: {@value}. */
+  public static final String DEFAULT_VALUE_SEPARATOR = ":";
+  
+  
+  /** Defaults to {@value #DEFAULT_PLACEHOLDER_PREFIX}. */
+  protected String placeholderPrefix = DEFAULT_PLACEHOLDER_PREFIX;
+  /** Defaults to {@value #DEFAULT_PLACEHOLDER_SUFFIX}. */
+  protected String placeholderSuffix = DEFAULT_PLACEHOLDER_SUFFIX;
+  /** Defaults to {@value #DEFAULT_VALUE_SEPARATOR}. */
+  @Nullable
+  protected String valueSeparator = DEFAULT_VALUE_SEPARATOR;
+  ```
+
+#### 2.2.2.3 replacePlaceholders
+
+调用 PropertyPlaceholderHelper 的 `#replacePlaceholders(String value, PlaceholderResolver placeholderResolver)` 方法，进行占位符替换，代码如下：
+
+```
+public String replacePlaceholders(String value, PlaceholderResolver placeholderResolver) {
+	Assert.notNull(value, "'value' must not be null");
+	return parseStringValue(value, placeholderResolver, new HashSet<>());
+}
+```
+
+- 调用 `#parseStringValue(String value, PlaceholderResolver placeholderResolver, Set<String> visitedPlaceholders)` 方法，**这个方法是这篇博客最核心的地方**，`${}` 占位符的替换。代码如下：
+
+  ```
+  // PropertyPlaceholderHelper.java
+  
+  protected String parseStringValue(String value, PlaceholderResolver placeholderResolver, Set<String> visitedPlaceholders) {
+      StringBuilder result = new StringBuilder(value);
+      // 获取前缀 "${" 的索引位置
+      int startIndex = value.indexOf(this.placeholderPrefix);
+      while (startIndex != -1) {
+          // 获取 后缀 "}" 的索引位置
+          int endIndex = findPlaceholderEndIndex(result, startIndex);
+          if (endIndex != -1) {
+              // 截取 "${" 和 "}" 中间的内容，这也就是我们在配置文件中对应的值
+              String placeholder = result.substring(startIndex + this.placeholderPrefix.length(), endIndex);
+              String originalPlaceholder = placeholder;
+              if (!visitedPlaceholders.add(originalPlaceholder)) {
+                  throw new IllegalArgumentException(
+                          "Circular placeholder reference '" + originalPlaceholder + "' in property definitions");
+              }
+              // Recursive invocation, parsing placeholders contained in the placeholder key.
+              // 解析占位符键中包含的占位符，真正的值
+              placeholder = parseStringValue(placeholder, placeholderResolver, visitedPlaceholders);
+              // Now obtain the value for the fully resolved key...
+              // 从 Properties 中获取 placeHolder 对应的值 propVal
+              String propVal = placeholderResolver.resolvePlaceholder(placeholder);
+              // 如果不存在
+              if (propVal == null && this.valueSeparator != null) {
+                  // 查询 : 的位置
+                  int separatorIndex = placeholder.indexOf(this.valueSeparator);
+                  // 如果存在 :
+                  if (separatorIndex != -1) {
+                      // 获取 : 前面部分 actualPlaceholder
+                      String actualPlaceholder = placeholder.substring(0, separatorIndex);
+                      // 获取 : 后面部分 defaultValue
+                      String defaultValue = placeholder.substring(separatorIndex + this.valueSeparator.length());
+                      // 从 Properties 中获取 actualPlaceholder 对应的值
+                      propVal = placeholderResolver.resolvePlaceholder(actualPlaceholder);
+                      // 如果不存在 则返回 defaultValue
+                      if (propVal == null) {
+                          propVal = defaultValue;
+                      }
+                  }
+              }
+              if (propVal != null) {
+                  // Recursive invocation, parsing placeholders contained in the
+                  // previously resolved placeholder value.
+                  propVal = parseStringValue(propVal, placeholderResolver, visitedPlaceholders);
+                  result.replace(startIndex, endIndex + this.placeholderSuffix.length(), propVal);
+                  if (logger.isTraceEnabled()) {
+                      logger.trace("Resolved placeholder '" + placeholder + "'");
+                  }
+                  startIndex = result.indexOf(this.placeholderPrefix, startIndex + propVal.length());
+              } else if (this.ignoreUnresolvablePlaceholders) {
+                  // Proceed with unprocessed value.
+                  // 忽略值
+                  startIndex = result.indexOf(this.placeholderPrefix, endIndex + this.placeholderSuffix.length());
+              } else {
+                  throw new IllegalArgumentException("Could not resolve placeholder '" +
+                          placeholder + "'" + " in value \"" + value + "\"");
+              }
+              visitedPlaceholders.remove(originalPlaceholder);
+          } else {
+              startIndex = -1;
+          }
+      }
+      // 返回propVal，就是替换之后的值
+      return result.toString();
+  }
+  ```
+
+  1. 获取占位符前缀 `"${"` 的索引位置 `startIndex` 。
+  2. 如果前缀 `"${"` 存在，则从 `“{”` 后面开始获取占位符后缀 “}” 的索引位置 `endIndex` 。
+  3. 如果前缀 `“${”` 和后缀 `"}"` 都存在，则截取中间部分 `placeholder` 。
+  4. 从 Properties 中获取 `placeHolder` 对应的值 `propVal` 。
+  5. 如果 `propVal` 为空，则判断占位符中是否存在 `":"`，如果存在则对占位符进行分割处理，全面部分为 `actualPlaceholder`，后面部分 `defaultValue`，尝试从 Properties 中获取 `actualPlaceholder` 对应的值 `propVal`，如果不存在，则将 `defaultValue` 的值赋值给 `propVal`
+  6. 返回 `propVal`，也就是 Properties 中对应的值。
+
+# 3. 小结
+
+到这里占位符的解析就结束了，下篇我们将利用 PropertyPlaceholderConfigurer 来实现动态加载配置文件，这个场景也是非常常见的。
\ No newline at end of file
diff --git a/spring/37-Spring-IoC 之 PropertyPlaceholderConfigurer 的应用.assets/15374242055683.jpg b/spring/37-Spring-IoC 之 PropertyPlaceholderConfigurer 的应用.assets/15374242055683.jpg
new file mode 100644
index 0000000..2ad1f2e
Binary files /dev/null and b/spring/37-Spring-IoC 之 PropertyPlaceholderConfigurer 的应用.assets/15374242055683.jpg differ
diff --git a/spring/37-Spring-IoC 之 PropertyPlaceholderConfigurer 的应用.md b/spring/37-Spring-IoC 之 PropertyPlaceholderConfigurer 的应用.md
new file mode 100644
index 0000000..9745e1a
--- /dev/null
+++ b/spring/37-Spring-IoC 之 PropertyPlaceholderConfigurer 的应用.md	
@@ -0,0 +1,140 @@
+# 【死磕 Spring】—— IoC 之 PropertyPlaceholderConfigurer 的应用
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=todo 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+在博客 [《【死磕 Spring】—— IoC 之深入分析 PropertyPlaceholderConfigurer》](http://svip.iocoder.cn/Spring/IoC-PropertyPlaceholderConfigurer) 中了解了 PropertyPlaceholderConfigurer 内部实现原理，它**允许我们在 XML 配置文件中使用占位符并将这些占位符所代表的资源单独配置到简单的 properties 文件中来加载**。这个特性非常重要，因为它我们对 Bean 实例属性的配置变得非常容易控制了，主要使用场景有：
+
+1. 动态加载配置文件，多环境切换
+2. 属性加解密
+
+下面我们就第一个应用场景来做说明。
+
+# 1. 多环境切换
+
+在我们项目开发过程中，都会存在多个环境，如 dev 、test 、prod 等等，各个环境的配置都会不一样，在传统的开发过程中我们都是在进行打包的时候进行人工干预，或者将配置文件放在系统外部，加载的时候指定加载目录，这种方式容易出错，那么有没有一种比较好的方式来解决这种情况呢？有，**利用 PropertyPlaceholderConfigurer 的特性来动态加载配置文件，实现多环境切换**。
+
+首先我们定义四个 Properties 文件，如下：
+
+[![img](37-Spring-IoC 之 PropertyPlaceholderConfigurer 的应用.assets/15374242055683.jpg)](http://static.iocoder.cn/15374242055683.jpg)
+
+配置内容如下：
+
+- `application-dev.properties` 文件，如下：
+
+  ```
+  student.name=chenssy-dev
+  ```
+
+- `application-test.properties` 文件，如下：
+
+  ```
+  student.name=chenssy-test
+  ```
+
+- `application-prod.properties` 文件，如下：
+
+  ```
+  student.name=chenssy-prod
+  ```
+
+然后实现一个类，该类继承 PropertyPlaceholderConfigurer，实现 `#loadProperties(Properties props)` 方法，根据环境的不同加载不同的配置文件，代码如下：
+
+```
+public class CustomPropertyConfig extends PropertyPlaceholderConfigurer {
+
+    private Resource[] locations;
+
+    private PropertiesPersister propertiesPersister = new DefaultPropertiesPersister();
+
+    @Override
+    public void setLocations(Resource[] locations) {
+        this.locations = locations;
+    }
+
+    @Override
+    public void setLocalOverride(boolean localOverride) {
+        this.localOverride = localOverride;
+    }
+
+    /**
+     * 覆盖这个方法，根据启动参数，动态读取配置文件
+     * @param props
+     * @throws IOException
+     */
+    @Override
+    protected void loadProperties(Properties props) throws IOException {
+        if (locations != null) {
+            // locations 里面就已经包含了那三个定义的文件
+            for (Resource location : this.locations) {
+                InputStream is = null;
+                try {
+                    String filename = location.getFilename();
+                    String env = "application-" + System.getProperty("spring.profiles.active", "dev") + ".properties";
+
+                    // 找到我们需要的文件，加载
+                    if (filename.contains(env)) {
+                        logger.info("Loading properties file from " + location);
+                        is = location.getInputStream();
+                        this.propertiesPersister.load(props, is);
+
+                    }
+                } catch (IOException ex) {
+                    logger.info("读取配置文件失败.....");
+                    throw ex;
+                } finally {
+                    if (is != null) {
+                        is.close();
+                    }
+                }
+            }
+        }
+    }
+}
+```
+
+配置文件：
+
+```
+<bean id="PropertyPlaceholderConfigurer" class="org.springframework.core.custom.CustomPropertyConfig">
+    <property name="locations">
+        <list>
+            <value>classpath:config/application-dev.properties</value>
+            <value>classpath:config/application-test.properties</value>
+            <value>classpath:config/application-prod.properties</value>
+        </list>
+    </property>
+</bean>
+
+<bean id="studentService" class="org.springframework.core.service.StudentService">
+    <property name="name" value="${student.name}"/>
+</bean>
+```
+
+在 idea 的 VM options 里面增加 `-Dspring.profiles.active=dev`，标志当前环境为 dev 环境。测试代码如下：
+
+```
+ApplicationContext context = new ClassPathXmlApplicationContext("spring.xml");
+
+StudentService studentService = (StudentService) context.getBean("studentService");
+System.out.println("student name:" + studentService.getName());
+```
+
+运行结果：
+
+```
+student name:chenssy-dev
+```
+
+当将 `-Dspring.profiles.active` 调整为 test，则打印结果则是 chenssy-test，这样就完全实现了根据不同的环境加载不同的配置。
+
+如果各位用过 Spring Boot 的话，这个就完全是 Spring Boot 里面的 `spring.profiles.active` ，可参见 `org.springframework.core.envAbstractEnvironment` 类，对应博客为 [《Spring boot源码分析-profiles环境（4）》](https://blog.csdn.net/jamet/article/details/77508182) 。
+
+# 2. 小结
+
+PropertyPlaceholderConfigurer 对于属性的配置非常灵活，就看怎么玩了。
\ No newline at end of file
diff --git a/spring/38-Spring-IoC 之深入分析 PropertyOverrideConfigurer.assets/15377119278769.jpg b/spring/38-Spring-IoC 之深入分析 PropertyOverrideConfigurer.assets/15377119278769.jpg
new file mode 100644
index 0000000..675ad91
Binary files /dev/null and b/spring/38-Spring-IoC 之深入分析 PropertyOverrideConfigurer.assets/15377119278769.jpg differ
diff --git a/spring/38-Spring-IoC 之深入分析 PropertyOverrideConfigurer.assets/15377127284347.jpg b/spring/38-Spring-IoC 之深入分析 PropertyOverrideConfigurer.assets/15377127284347.jpg
new file mode 100644
index 0000000..233d5fe
Binary files /dev/null and b/spring/38-Spring-IoC 之深入分析 PropertyOverrideConfigurer.assets/15377127284347.jpg differ
diff --git a/spring/38-Spring-IoC 之深入分析 PropertyOverrideConfigurer.assets/spring-201809231001.png b/spring/38-Spring-IoC 之深入分析 PropertyOverrideConfigurer.assets/spring-201809231001.png
new file mode 100644
index 0000000..9cc6311
Binary files /dev/null and b/spring/38-Spring-IoC 之深入分析 PropertyOverrideConfigurer.assets/spring-201809231001.png differ
diff --git a/spring/38-Spring-IoC 之深入分析 PropertyOverrideConfigurer.assets/spring-201809231002.png b/spring/38-Spring-IoC 之深入分析 PropertyOverrideConfigurer.assets/spring-201809231002.png
new file mode 100644
index 0000000..42b9e68
Binary files /dev/null and b/spring/38-Spring-IoC 之深入分析 PropertyOverrideConfigurer.assets/spring-201809231002.png differ
diff --git a/spring/38-Spring-IoC 之深入分析 PropertyOverrideConfigurer.md b/spring/38-Spring-IoC 之深入分析 PropertyOverrideConfigurer.md
new file mode 100644
index 0000000..74816ea
--- /dev/null
+++ b/spring/38-Spring-IoC 之深入分析 PropertyOverrideConfigurer.md	
@@ -0,0 +1,232 @@
+# 【死磕 Spring】—— IoC 之深入分析 PropertyOverrideConfigurer
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=todo 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+在文章 [《【死磕 Spring】—— IoC 之深入分析 BeanFactoryPostProcessor》](http://svip.iocoder.cn/Spring/IoC-BeanFactoryPostProcessor) 中提到，BeanFactoryPostProcessor 作用与 BeanDefinition 完成加载之后与 Bean 实例化之前，是 Spring 提供的一种强大的扩展机制。它有两个重要的子类，一个是 PropertyPlaceholderConfigurer，另一个是 PropertyOverrideConfigurer ，其中 PropertyPlaceholderConfigurer 允许我们通过配置 Properties 的方式来取代 Bean 中定义的占位符，而 **PropertyOverrideConfigurer** 呢？正是我们这篇博客介绍的。
+
+> PropertyOverrideConfigurer 允许我们对 Spring 容器中配置的任何我们想处理的 bean 定义的 property 信息进行覆盖替换。
+
+这个定义听起来有点儿玄乎，通俗点说，就是我们可以通过 PropertyOverrideConfigurer 来覆盖任何 bean 中的任何属性，只要我们想。
+
+# 1. 使用
+
+PropertyOverrideConfigurer 的使用规则是 `beanName.propertyName=value`，这里需要注意的是 `beanName.propertyName` 则是该 bean 中存在的属性。
+
+## 1.1 示例一
+
+依然使用以前的例子，`Student.class`，我们只需要修改下配置文件，声明下 PropertyOverrideConfigurer 以及其加载的配置文件。如下：
+
+```
+<bean class="org.springframework.beans.factory.config.PropertyOverrideConfigurer">
+    <property name="locations">
+        <list>
+            <value>classpath:application.properties</value>
+        </list>
+    </property>
+</bean>
+
+<bean id="student" class="org.springframework.core.service.StudentService">
+    <property name="name" value="chenssy"/>
+</bean>
+```
+
+- 指定 student 的 `name` 属性值为 `"chenssy"` 。
+
+- 声明 PropertyOverrideConfigurer 加载的文件为 `application.properties`，内容如下：
+
+  ```
+  student.name = chenssy-PropertyOverrideConfigurer
+  ```
+
+  - 指定 beanName 为 `student` 的 bean 的 `name` 属性值为 `"chenssy-PropertyOverrideConfigurer"` 。
+
+测试打印 `student` 中的 `name` 属性值，代码如下：
+
+```
+ApplicationContext context = new ClassPathXmlApplicationContext("spring.xml");
+
+StudentService studentService = (StudentService) context.getBean("student");
+System.out.println("student name:" + studentService.getName());
+```
+
+运行结果为：
+
+[![img](38-Spring-IoC 之深入分析 PropertyOverrideConfigurer.assets/15377119278769.jpg)](http://static.iocoder.cn/15377119278769.jpg)
+
+从中可以看出 PropertyOverrideConfigurer 定义的文件取代了 bean 中默认的值。
+
+## 1.2 示例二
+
+下面我们看一个有趣的例子，如果我们一个 bean 中 PropertyPlaceholderConfigurer 和 PropertyOverrideConfigurer 都使用呢？那是显示谁定义的值呢？这里先简单分析下：如果PropertyOverrideConfigurer 先作用，那么 PropertyPlaceholderConfigurer 在匹配占位符的时候就找不到了，**如果 PropertyOverrideConfigurer 后作用，也会直接取代 PropertyPlaceholderConfigurer 定义的值，所以无论如何都会显示 PropertyOverrideConfigurer 定义的值**。是不是这样呢？看如下例子：
+
+xml 配置文件调整如下：
+
+```
+<bean class="org.springframework.beans.factory.config.PropertyOverrideConfigurer">
+    <property name="locations">
+        <list>
+            <value>classpath:application1.properties</value>
+        </list>
+    </property>
+</bean>
+
+<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
+    <property name="locations">
+        <list>
+            <value>classpath:application2.properties</value>
+        </list>
+    </property>
+</bean>
+
+<bean id="student" class="org.springframework.core.service.StudentService">
+    <property name="name" value="${studentService.name}"/>
+</bean>
+```
+
+- 指定 .PropertyOverrideConfigurer 加载文件为 `application1.properties` 。配置文件如下：
+
+  ```
+  student.name = chenssy-PropertyOverrideConfigurer
+  ```
+
+- PropertyPlaceholderConfigurer 加载文件为 `application2.properties` 。配置文件如下：
+
+  ```
+  studentService.name = chenssy-PropertyPlaceholderConfigurer
+  ```
+
+- `student` 的 `name` 属性使用占位符 `${studentService.name}`。
+
+测试程序依然是打印 name 属性值，运行结果如下：
+
+[![img](38-Spring-IoC 之深入分析 PropertyOverrideConfigurer.assets/15377127284347.jpg)](http://static.iocoder.cn/15377127284347.jpg)
+
+所以，上面的分析没有错。下面我们来分析 **PropertyOverrideConfigurer 实现原理**。
+其实如果了解 PropertyPlaceholderConfigurer 的实现机制的话，那么 PropertyOverrideConfigurer 也不难猜测：加载指定 Properties，迭代其中的属性值，依据 `“.”` 来得到 `beanName`（`split(".")[0]`），从容器中获取指定的 BeanDefinition，然后得到 `name` 属性，进行替换即可。
+
+# 2. 实现原理
+
+UML 结构图如下：
+
+[![spring-201809231001](38-Spring-IoC 之深入分析 PropertyOverrideConfigurer.assets/spring-201809231001.png)](http://static.iocoder.cn/spring-201809231001.png)spring-201809231001
+
+与 PropertyPlaceholderConfigurer 一样，也是继承 PropertyResourceConfigurer，我们知道 PropertyResourceConfigurer 对 BeanFactoryPostProcessor 的 `#postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory)` 方法提供了实现，在该实现中它会去读取指定配置文件中的内容，然后调用 `#processProperties(ConfigurableListableBeanFactory beanFactoryToProcess, Properties props)` 方法。该方法是一个抽象方法，具体的实现由子类来实现，所以这里我们只需要看 PropertyOverrideConfigurer 中 `#processProperties(ConfigurableListableBeanFactory beanFactoryToProcess, Properties props)` 方法的具体实现，代码如下：
+
+```
+// PropertyOverrideConfigurer.java
+
+@Override
+protected void processProperties(ConfigurableListableBeanFactory beanFactory, Properties props)
+        throws BeansException {
+    // 迭代配置文件中的内容
+    for (Enumeration<?> names = props.propertyNames(); names.hasMoreElements();) {
+        String key = (String) names.nextElement();
+        try {
+            processKey(beanFactory, key, props.getProperty(key));
+        } catch (BeansException ex) {
+            String msg = "Could not process key '" + key + "' in PropertyOverrideConfigurer";
+            if (!this.ignoreInvalidKeys) {
+                throw new BeanInitializationException(msg, ex);
+            }
+            if (logger.isDebugEnabled()) {
+                logger.debug(msg, ex);
+            }
+        }
+    }
+}
+```
+
+- 迭代 `props` 数组，依次调用 `#processKey(ConfigurableListableBeanFactory factory, String key, String value)` 方法，代码如下:
+
+  ```
+  // PropertyOverrideConfigurer.java
+  
+  /**
+   * The default bean name separator.
+   */
+  public static final String DEFAULT_BEAN_NAME_SEPARATOR = ".";
+  /**
+   * Bean 名字的分隔符
+   */
+  private String beanNameSeparator = DEFAULT_BEAN_NAME_SEPARATOR;
+  /**
+   * Contains names of beans that have overrides.
+   */
+  private final Set<String> beanNames = Collections.newSetFromMap(new ConcurrentHashMap<>(16));
+  protected void processKey(ConfigurableListableBeanFactory factory, String key, String value)
+          throws BeansException {
+      // 判断是否存在 "."，即获取其索引位置
+      int separatorIndex = key.indexOf(this.beanNameSeparator);
+      if (separatorIndex == -1) {
+          throw new BeanInitializationException("Invalid key '" + key +
+                  "': expected 'beanName" + this.beanNameSeparator + "property'");
+      }
+      // 得到 beanName
+      String beanName = key.substring(0, separatorIndex);
+      // 得到属性值
+      String beanProperty = key.substring(separatorIndex+1);
+      this.beanNames.add(beanName);
+      // 替换
+      applyPropertyValue(factory, beanName, beanProperty, value);
+      if (logger.isDebugEnabled()) {
+          logger.debug("Property '" + key + "' set to value [" + value + "]");
+      }
+  }
+  ```
+
+  - 获取分割符 `“.”` 的索引位置，得到 `beanName` 以及相应的属性，然后调用 `#applyPropertyValue(ConfigurableListableBeanFactory factory, String beanName, String property, String value)` 方法，代码如下：
+
+    ```
+    // PropertyOverrideConfigurer.java
+    
+    protected void applyPropertyValue(ConfigurableListableBeanFactory factory, String beanName, String property, String value) {
+        // 获得 BeanDefinition 对象
+        BeanDefinition bd = factory.getBeanDefinition(beanName);
+        BeanDefinition bdToUse = bd;
+        while (bd != null) {
+            bdToUse = bd;
+            bd = bd.getOriginatingBeanDefinition();
+        }
+        // 设置 PropertyValue 到 BeanDefinition 中
+        PropertyValue pv = new PropertyValue(property, value);
+        pv.setOptional(this.ignoreInvalidKeys);
+        bdToUse.getPropertyValues().addPropertyValue(pv);
+    }
+    ```
+
+    - 从容器中获取 BeanDefinition ，然后根据属性 `property` 和其值 `value` 构造成一个 PropertyValue 对象，最后调用 `#addPropertyValue(PropertyValue pv )` 方法。PropertyValue 是用于保存一组bean属性的信息和值的对像。代码如下：
+
+      ```
+      // MutablePropertyValues.java
+      
+      public MutablePropertyValues addPropertyValue(PropertyValue pv) {
+          for (int i = 0; i < this.propertyValueList.size(); i++) {
+              PropertyValue currentPv = this.propertyValueList.get(i);
+              // 匹配
+              if (currentPv.getName().equals(pv.getName())) {
+                  // 合并属性
+                  pv = mergeIfRequired(pv, currentPv);
+                  // 覆盖属性
+                  setPropertyValueAt(pv, i);
+                  return this;
+              }
+          }
+          // 未匹配到，添加到 propertyValueList 中
+          this.propertyValueList.add(pv);
+          return this;
+      }
+      ```
+
+      - 添加 PropertyValue 对象，替换或者合并相同的属性值。整个过程其实与上面猜测相差不是很大。
+
+# 3. 小结
+
+至此，PropertyOverrideConfigurer 到这里也就分析完毕了。最后看下 PropertyPlaceholderConfigurer 和 PropertyOverrideConfigurer 整体的结构图：
+
+[![spring-201809231002](38-Spring-IoC 之深入分析 PropertyOverrideConfigurer.assets/spring-201809231002.png)](http://static.iocoder.cn/spring-201809231002.png)spring-201809231002
\ No newline at end of file
diff --git a/spring/39-Spring-IoC 之深入分析 Bean 的类型转换体系.assets/5dae2df55357fdf3f3e5a3c7470e5c6b.jpeg b/spring/39-Spring-IoC 之深入分析 Bean 的类型转换体系.assets/5dae2df55357fdf3f3e5a3c7470e5c6b.jpeg
new file mode 100644
index 0000000..9e203f1
Binary files /dev/null and b/spring/39-Spring-IoC 之深入分析 Bean 的类型转换体系.assets/5dae2df55357fdf3f3e5a3c7470e5c6b.jpeg differ
diff --git a/spring/39-Spring-IoC 之深入分析 Bean 的类型转换体系.md b/spring/39-Spring-IoC 之深入分析 Bean 的类型转换体系.md
new file mode 100644
index 0000000..ebaed37
--- /dev/null
+++ b/spring/39-Spring-IoC 之深入分析 Bean 的类型转换体系.md	
@@ -0,0 +1,713 @@
+# 【死磕 Spring】—— IoC 之深入分析 Bean 的类型转换体系
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=todo 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+我们知道不管 Bean 对象里面的属性时什么类型，他们都是通过 XML 、Properties 或者其他方式来配置这些**属性**对象类型的。在 Spring 容器加载过程中，这些属性都是以 String 类型加载进容器的，但是最终都需要将这些 String 类型的属性转换 Bean 对象属性所对应真正的类型，要想完成这种由字符串到具体对象的转换，就需要这种转换规则相关的信息，而这些信息以及转换过程由 **Spring 类型转换体系**来完成。
+
+------
+
+我们依然以 xml 为例，在 Spring 容器加载阶段，容器将 xml 文件中定义的 `<bean>` 解析为 BeanDefinition，BeanDefinition 中存储着我们定义一个 bean 需要的所有信息，包括属性，这些属性是以 String 类型的存储的。当用户触发 Bean 实例化阶段时，Spring 容器会将这些属性转换为这些属性真正对应的类型。我们知道在 Bean 实例化阶段，属性的注入是在实例化 Bean 阶段的属性注入阶段，即 AbstractAutowireCapableBeanFactory 的 `#populateBean(String beanName, RootBeanDefinition mbd, BeanWrapper bw)` 方法。
+
+在 `#populateBean(String beanName, RootBeanDefinition mbd, BeanWrapper bw)` 方法中，会将 BeanDefinition 中定义的属性值翻译为 PropertyValue ，然后调用 `#applyPropertyValues(String beanName, BeanDefinition mbd, BeanWrapper bw, PropertyValues pvs)` 方法，进行属性应用。其中 PropertyValue 用于保存单个 bean 属性的信息和值的对象。
+
+------
+
+在 `#applyPropertyValues(String beanName, BeanDefinition mbd, BeanWrapper bw, PropertyValues pvs)` 方法中，会调用 `#convertForProperty(Object value, String propertyName, BeanWrapper bw, TypeConverter converter)` 进行属性转换，代码如下：
+
+```
+// AbstractAutowireCapableBeanFactory。java
+
+@Nullable
+private Object convertForProperty(
+        @Nullable Object value, String propertyName, BeanWrapper bw, TypeConverter converter) {
+    // 若 TypeConverter 为 BeanWrapperImpl 类型，则使用 BeanWrapperImpl 来进行类型转换
+    // 这里主要是因为 BeanWrapperImpl 实现了 PropertyEditorRegistry 接口
+    if (converter instanceof BeanWrapperImpl) {
+        return ((BeanWrapperImpl) converter).convertForProperty(value, propertyName);
+    } else {
+        // 获得属性对应的 PropertyDescriptor 对象
+        PropertyDescriptor pd = bw.getPropertyDescriptor(propertyName);
+        // 获得属性对应的 setting MethodParameter 对象
+        MethodParameter methodParam = BeanUtils.getWriteMethodParameter(pd);
+        // 执行转换
+        return converter.convertIfNecessary(value, pd.getPropertyType(), methodParam);
+    }
+}
+```
+
+- 若 TypeConverter 为 BeanWrapperImpl 类型，则使用 BeanWrapperImpl 来进行类型转换，这里主要是因为 BeanWrapperImpl 实现了 PropertyEditorRegistry 接口。
+- 否则，调用 TypeConverter 的 `#convertIfNecessary(Object value, Class<T> requiredType, MethodParameter methodParam)` 方法，进行类型转换。TypeConverter 是定义类型转换方法的接口，通常情况下与 PropertyEditorRegistry 配合使用实现类型转换。
+- 关于 BeanWrapperImpl 小编后续专门出文分析它。
+
+------
+
+`#convertIfNecessary(Object value, Class<T> requiredType, MethodParameter methodParam)` 方法的实现者有两个：DataBinder 和 TypeConverterSupport 类。
+
+- DataBinder 主要用于参数绑定（熟悉 Spring MVC 的都应该知道这个类）
+- TypeConverterSupport 则是 TypeConverter 的基本实现，使用的是 `typeConverterDelegate` 委托者。
+
+所以这里我们只需要关注 TypeConverterSupport 的 `#convertIfNecessary(Object value, Class<T> requiredType, MethodParameter methodParam)` 方法，代码如下：
+
+```
+// TypeConverterSupport.java
+
+@Override
+@Nullable
+public <T> T convertIfNecessary(@Nullable Object value, @Nullable Class<T> requiredType, @Nullable Field field)
+        throws TypeMismatchException {
+    return doConvert(value, requiredType, null, field);
+}
+
+@Nullable
+private <T> T doConvert(@Nullable Object value,@Nullable Class<T> requiredType,
+        @Nullable MethodParameter methodParam, @Nullable Field field) throws TypeMismatchException {
+    Assert.state(this.typeConverterDelegate != null, "No TypeConverterDelegate");
+    try {
+        if (field != null) { // field
+            return this.typeConverterDelegate.convertIfNecessary(value, requiredType, field);
+        } else { // methodParam
+            return this.typeConverterDelegate.convertIfNecessary(value, requiredType, methodParam);
+        }
+    } catch (ConverterNotFoundException | IllegalStateException ex) {
+        throw new ConversionNotSupportedException(value, requiredType, ex);
+    } catch (ConversionException | IllegalArgumentException ex) {
+        throw new TypeMismatchException(value, requiredType, ex);
+    }
+}
+```
+
+我们一直往下跟会跟踪到 TypeConverterDelegate 的 `#convertIfNecessary(Object newValue, @Nullable Class<T> requiredType, ...)` 方法，会发现如下代码段：
+
+```
+// TypeConverterDelegate.java
+
+@Nullable
+public <T> T convertIfNecessary(@Nullable String propertyName, @Nullable Object oldValue, @Nullable Object newValue,
+        @Nullable Class<T> requiredType, @Nullable TypeDescriptor typeDescriptor) throws IllegalArgumentException {
+
+        // ... 省略暂时非关键的代码
+
+        // No custom editor but custom ConversionService specified?
+        ConversionService conversionService = this.propertyEditorRegistry.getConversionService();
+        if (editor == null && conversionService != null && newValue != null && typeDescriptor != null) {
+            TypeDescriptor sourceTypeDesc = TypeDescriptor.forObject(newValue);
+            if (conversionService.canConvert(sourceTypeDesc, typeDescriptor)) {
+                try {
+                    return (T) conversionService.convert(newValue, sourceTypeDesc, typeDescriptor);
+                } catch (ConversionFailedException ex) {
+                    // fallback to default conversion logic below
+                    conversionAttemptEx = ex;
+                }
+            }
+        }
+
+        // ... 省略暂时非关键的代码
+}
+```
+
+- 如果没有自定义的编辑器则使用 ConversionService 。
+
+------
+
+ConversionService 是字 Spring 3 后推出来用来替代 PropertyEditor 转换模式的转换体系，接口定义如下：
+
+```
+// ConversionService.java
+
+public interface ConversionService {
+
+    boolean canConvert(@Nullable Class<?> sourceType, Class<?> targetType);
+
+    boolean canConvert(@Nullable TypeDescriptor sourceType, TypeDescriptor targetType);
+
+    @Nullable
+    <T> T convert(@Nullable Object source, Class<T> targetType);
+
+    @Nullable
+    Object convert(@Nullable Object source, @Nullable TypeDescriptor sourceType, TypeDescriptor targetType);
+
+}
+```
+
+其 UML 类图如下：
+
+[![ConversionService 类图](39-Spring-IoC 之深入分析 Bean 的类型转换体系.assets/5dae2df55357fdf3f3e5a3c7470e5c6b.jpeg)](http://static.iocoder.cn/5dae2df55357fdf3f3e5a3c7470e5c6b)ConversionService 类图
+
+- **ConfigurableConversionService**：ConversionService 的配置接口，继承 ConversionService 和 ConverterRegistry 两个接口，用于合并他们两者的操作，以便于通过 add 和 remove 的方式添加和删除转换器。
+- **GenericConversionService**：ConversionService 接口的基础实现，适用于大部分条件下的转换工作，通过 ConfigurableConversionService 接口间接地将 ConverterRegistry 实现为注册 API 。
+- **DefaultConversionService**：ConversionService 接口的默认实现，适用于大部分条件下的转换工作。
+
+------
+
+回归到 TypeConverterDelegate 的 `#convertIfNecessary(String propertyName, Object oldValue, @Nullable Object newValue, Class<T> requiredType, TypeDescriptor typeDescriptor)` 方法，在该方法中，如果没有自定义的属性编辑器，则调用 ConversionService 接口的 `#convert(...)`，方法定义如下：
+
+```
+// ConversionService.java
+
+Object convert(@Nullable Object source, @Nullable TypeDescriptor sourceType, TypeDescriptor targetType);
+```
+
+- `source` ：要转换的源对象，可以为 `null` 。
+- `sourceType`：`source` 的类型的上下文，如果 `source` 为 `null` ，则可以为 `null` 。
+- `targetType` ：`source` 要转换的类型的上下文。
+
+`#convert(...)` 方法，将给定的源对象 `source` 转换为指定的 `targetType` 。TypeDescriptors 提供有关发生转换的源位置和目标位置的附加上下文，通常是对象字段或属性位置。该方法由子类 GenericConversionService 实现：
+
+```
+// GenericConversionService.java
+
+@Override
+@Nullable
+public Object convert(@Nullable Object source, @Nullable TypeDescriptor sourceType, TypeDescriptor targetType) {
+    Assert.notNull(targetType, "Target type to convert to cannot be null");
+    // <1> 如果 sourceType 为空，则直接处理结果
+    if (sourceType == null) {
+        Assert.isTrue(source == null, "Source must be [null] if source type == [null]");
+        return handleResult(null, targetType, convertNullSource(null, targetType));
+    }
+    // <2> 如果类型不对，抛出 IllegalArgumentException 异常
+    if (source != null && !sourceType.getObjectType().isInstance(source)) {
+        throw new IllegalArgumentException("Source to convert from must be an instance of [" +
+                sourceType + "]; instead it was a [" + source.getClass().getName() + "]");
+    }
+    // <3> 获得对应的 GenericConverter 对象
+    GenericConverter converter = getConverter(sourceType, targetType);
+    // <4> 如果 converter 非空，则进行转换，然后再处理结果
+    if (converter != null) {
+        // <4.1> 执行转换
+        Object result = ConversionUtils.invokeConverter(converter, source, sourceType, targetType);
+        // <4.2> 处理器结果
+        return handleResult(sourceType, targetType, result);
+    }
+    // <5> 处理 converter 为空的情况
+    return handleConverterNotFound(source, sourceType, targetType);
+}
+```
+
+- `<1>` 处，如果 `sourceType` 为空，则直接处理结果。
+
+- `<2>` 处，如果类型不对，抛出 IllegalArgumentException 异常。
+
+- `<3>` 处，调用 `#getConverter(TypeDescriptor sourceType, TypeDescriptor targetType)` 方法，获取 GenericConverter 对象 `converter` 。
+
+- `<4>` 处，如果 `converter` 非空，则进行转换，然后再处理结果。
+
+  - `<4.1>` 处，调用 `ConversionUtils#invokeConverter(GenericConverter converter, Object source, TypeDescriptor sourceType, TypeDescriptor targetType)` 方法，执行转换。代码如下：
+
+    ```
+    // ConversionUtils.java
+    
+    @Nullable
+    public static Object invokeConverter(GenericConverter converter, @Nullable Object source,
+            TypeDescriptor sourceType, TypeDescriptor targetType) {
+        try {
+            // 执行转换
+            return converter.convert(source, sourceType, targetType);
+        } catch (ConversionFailedException ex) {
+            throw ex;
+        } catch (Throwable ex) {
+            throw new ConversionFailedException(sourceType, targetType, source, ex);
+        }
+    }
+    ```
+
+    - 【重要】在这里，我们看到执行转换。
+
+  - `<4.2>` 处，调用 `#handleResult(TypeDescriptor sourceType, TypeDescriptor targetType, Object result)` 方法，处理结果。代码如下：
+
+    ```
+    // GenericConversionService.java
+    
+    @Nullable
+    private Object handleResult(@Nullable TypeDescriptor sourceType, TypeDescriptor targetType, @Nullable Object result) {
+    	if (result == null) {
+    		assertNotPrimitiveTargetType(sourceType, targetType);
+    	}
+    	return result;
+    }
+    
+    private void assertNotPrimitiveTargetType(@Nullable TypeDescriptor sourceType, TypeDescriptor targetType) {
+    	if (targetType.isPrimitive()) {
+    		throw new ConversionFailedException(sourceType, targetType, null,
+    				new IllegalArgumentException("A null value cannot be assigned to a primitive type"));
+    	}
+    }
+    ```
+
+    - 实际上，是**校验**结果。
+
+- `<5>` 处，调用 `#handleConverterNotFound(Object source, TypeDescriptor sourceType, TypeDescriptor targetType)` 方法，处理 `converter` 为空的情况。代码如下：
+
+  ```
+  // GenericConversionService.java
+  
+  @Nullable
+  private Object handleConverterNotFound(
+          @Nullable Object source, @Nullable TypeDescriptor sourceType, TypeDescriptor targetType) {
+      // 情况一，如果 source 为空，则返回空
+      if (source == null) {
+          assertNotPrimitiveTargetType(sourceType, targetType);
+          return null;
+      }
+      // 情况二，如果 sourceType 为空，或者 targetType 是 sourceType 的子类，则返回 source
+      if ((sourceType == null || sourceType.isAssignableTo(targetType)) &&
+              targetType.getObjectType().isInstance(source)) {
+          return source;
+      }
+      // 抛出 ConverterNotFoundException 异常
+      throw new ConverterNotFoundException(sourceType, targetType);
+  }
+  ```
+
+------
+
+😈 逻辑有点点长，我们先从 `#getConverter(TypeDescriptor sourceType, TypeDescriptor targetType)` 方法，获取 GenericConverter 对象 `converter` 。代码如下：
+
+```
+// GenericConversionService.java
+
+@Nullable
+protected GenericConverter getConverter(TypeDescriptor sourceType, TypeDescriptor targetType) {
+    // 创建 ConverterCacheKey 对象
+    ConverterCacheKey key = new ConverterCacheKey(sourceType, targetType);
+    // 从 converterCache 缓存中，获得 GenericConverter 对象 converter
+    GenericConverter converter = this.converterCache.get(key);
+    // 如果获得到，则返回 converter
+    if (converter != null) {
+        return (converter != NO_MATCH ? converter : null);
+    }
+
+    // 如果获取不到，则从 converters 中查找
+    converter = this.converters.find(sourceType, targetType);
+    // 如果查找不到，则获得默认的 Converter 对象
+    if (converter == null) {
+        converter = getDefaultConverter(sourceType, targetType);
+    }
+
+    // 如果找到 converter ，则添加 converter 到 converterCache 中，并返回 converter
+    if (converter != null) {
+        this.converterCache.put(key, converter);
+        return converter;
+    }
+
+    // 如果找不到 converter ，则添加 NO_MATCH 占位符到 converterCache 中，并返回 null
+    this.converterCache.put(key, NO_MATCH);
+    return null;
+}
+```
+
+- 这段代码意图非常明确，从 `converterCache` 缓存中获取，如果存在返回，否则从 `converters` 中获取，然后加入到 `converterCache` 缓存中。
+
+- `converterCache` 和 `converters` 是 GenericConversionService 维护的两个很重要的对象，代码如下：
+
+  ```
+  // GenericConversionService.java
+  
+  /**
+   * 所有 Converter 集合的封装对象
+   */
+  private final Converters converters = new Converters();
+  
+  /**
+   * GenericConverter 缓存
+   */
+  private final Map<ConverterCacheKey, GenericConverter> converterCache = new ConcurrentReferenceHashMap<>(64);
+  ```
+
+------
+
+Converters 是 GenericConversionService 内部类，用于管理所有注册的转换器，其内部维护一个 Set 和 Map 的数据结构用于管理转换器，代码如下：
+
+```
+// GenericConversionService.java#Converters
+
+private final Set<GenericConverter> globalConverters = new LinkedHashSet<>();
+
+private final Map<ConvertiblePair, ConvertersForPair> converters = new LinkedHashMap<>(36);
+```
+
+- 同时提供了相应的方法（如 add、remove）操作这两个集合。
+
+在 `#getConverter(TypeDescriptor sourceType, TypeDescriptor targetType)` 方法中，如果缓存 `converterCache` 中不存在，则调用 Converters 对象的 `#find(TypeDescriptor sourceType, TypeDescriptor targetType)` 方法，查找相应的 GenericConverter，如下：
+
+```
+// GenericConversionService.java#Converters
+
+@Nullable
+public GenericConverter find(TypeDescriptor sourceType, TypeDescriptor targetType) {
+    // Search the full type hierarchy
+    List<Class<?>> sourceCandidates = getClassHierarchy(sourceType.getType());
+    List<Class<?>> targetCandidates = getClassHierarchy(targetType.getType());
+    // 遍历 sourceCandidates 数组
+    for (Class<?> sourceCandidate : sourceCandidates) {
+        // 遍历 targetCandidates 数组
+        for (Class<?> targetCandidate : targetCandidates) {
+            // 创建 ConvertiblePair 对象
+            ConvertiblePair convertiblePair = new ConvertiblePair(sourceCandidate, targetCandidate);
+            // 获得 GenericConverter 对象
+            GenericConverter converter = getRegisteredConverter(sourceType, targetType, convertiblePair);
+            if (converter != null) {
+                return converter;
+            }
+        }
+    }
+    return null;
+}
+
+@Nullable
+private GenericConverter getRegisteredConverter(TypeDescriptor sourceType,
+        TypeDescriptor targetType, ConvertiblePair convertiblePair) {
+    // Check specifically registered converters
+    // 从 converters 中，获得 converter
+    ConvertersForPair convertersForPair = this.converters.get(convertiblePair);
+    if (convertersForPair != null) {
+        GenericConverter converter = convertersForPair.getConverter(sourceType, targetType);
+        if (converter != null) {
+            return converter;
+        }
+    }
+    // Check ConditionalConverters for a dynamic match
+    // 从 globalConverters 中，获得 globalConverter
+    for (GenericConverter globalConverter : this.globalConverters) {
+        if (((ConditionalConverter) globalConverter).matches(sourceType, targetType)) {
+            return globalConverter;
+        }
+    }
+    return null;
+}
+```
+
+- 在 `#find(TypeDescriptor sourceType, TypeDescriptor targetT)` 方法中，会根据 `sourceType` 和 `targetType` 去查询 Converters 中维护的 Map 中是否包括支持的注册类型。如果存在返回 GenericConverter ，如果没有存在返回 `null` 。
+
+------
+
+当得到 GenericConverter 后，则调用其 `#convert(Object source, TypeDescriptor sourceType, TypeDescriptor targetType)` 方法，进行类型转换。代码如下：
+
+```
+// GenericConverter.java
+
+Object convert(@Nullable Object source, TypeDescriptor sourceType, TypeDescriptor targetType);
+```
+
+到这里我们就可以得到 Bean 属性定义的真正类型了。
+
+**GenericConverter 接口**
+
+GenericConverter 是一个转换接口，一个用于在两种或更多种类型之间转换的通用型转换器接口。它是 Converter SPI 体系中最灵活的，也是最复杂的接口，灵活性在于 GenericConverter 可以支持在多个源/目标类型对之间进行转换，同时也可以在类型转换过程中访问源/目标字段上下文。由于该接口足够复杂，所有当更简单的 Converter 或 ConverterFactory 接口足够使用时，通常不应使用此接口。其定义如下：
+
+```
+// GenericConverter.java
+
+public interface GenericConverter {
+
+    @Nullable
+    Set<ConvertiblePair> getConvertibleTypes();
+
+    @Nullable
+    Object convert(@Nullable Object source, TypeDescriptor sourceType, TypeDescriptor targetType);
+
+}
+```
+
+GenericConverter 的子类有这么多（看类名就知道是干嘛的了）：
+
+[![GenericConverter 子类](http://static.iocoder.cn/ae851c788e7011fd6e325056cab2f797)](http://static.iocoder.cn/ae851c788e7011fd6e325056cab2f797)GenericConverter 子类
+
+我们看一个子类的实现 StringToArrayConverter，该子类将逗号分隔的 String 转换为 Array 。代码如下：
+
+```
+// StringToArrayConverter.java
+
+final class StringToArrayConverter implements ConditionalGenericConverter {
+
+	private final ConversionService conversionService;
+
+	public StringToArrayConverter(ConversionService conversionService) {
+		this.conversionService = conversionService;
+	}
+
+	@Override
+	public Set<ConvertiblePair> getConvertibleTypes() {
+		return Collections.singleton(new ConvertiblePair(String.class, Object[].class));
+	}
+
+	@Override
+	public boolean matches(TypeDescriptor sourceType, TypeDescriptor targetType) {
+		return ConversionUtils.canConvertElements(sourceType, targetType.getElementTypeDescriptor(),
+				this.conversionService);
+	}
+
+	@Override
+	@Nullable
+	public Object convert(@Nullable Object source, TypeDescriptor sourceType, TypeDescriptor targetType) {
+		if (source == null) {
+			return null;
+		}
+		// 按照 , 分隔成字符串数组
+		String string = (String) source;
+		String[] fields = StringUtils.commaDelimitedListToStringArray(string);
+		// 获得 TypeDescriptor 对象
+		TypeDescriptor targetElementType = targetType.getElementTypeDescriptor();
+		Assert.state(targetElementType != null, "No target element type");
+		// 创建目标数组
+		Object target = Array.newInstance(targetElementType.getType(), fields.length);
+		// 遍历 fields 数组，逐个转换
+		for (int i = 0; i < fields.length; i++) {
+			String sourceElement = fields[i];
+			// 执行转换
+			Object targetElement = this.conversionService.convert(sourceElement.trim(), sourceType, targetElementType);
+			// 设置到 target 中
+			Array.set(target, i, targetElement);
+		}
+		return target;
+	}
+
+}
+```
+
+在类型转换体系中，Spring 提供了非常多的类型转换器，除了上面的 GenericConverter，还有 Converter、ConditionalConverter、ConverterFactory。
+
+------
+
+**Converter**
+
+Converter 是一个将 `<S>` 类型的源对象转换为 `<T>` 类型的目标对象的转换器。该接口是线程安全的，所以可以共享。代码如下:
+
+```
+// Converter.java
+
+public interface Converter<S, T> {
+
+    @Nullable
+    T convert(S source);
+
+}
+```
+
+子类如下：
+
+[![Converter 类图](http://static.iocoder.cn/7846fde6784243ff50c21366a438dab6)](http://static.iocoder.cn/7846fde6784243ff50c21366a438dab6)Converter 类图
+
+------
+
+**ConditionalConverter**
+
+ConditionalConverter 接口用于表示有条件的类型转换，通过转入的`sourceType` 与 `targetType` 判断转换能否匹配，只有可匹配的转换才会调用convert 方法进行转换。代码如下：
+
+```
+// ConditionalConverter.java
+
+public interface ConditionalConverter {
+
+    boolean matches(TypeDescriptor sourceType, TypeDescriptor targetType);
+
+}
+```
+
+ConditionalConverter 的子类如下：
+
+[![ConditionalConverter 类图](http://static.iocoder.cn/8a7276c5d8bcdd7a724e69147655a710)](http://static.iocoder.cn/8a7276c5d8bcdd7a724e69147655a710)ConditionalConverter 类图
+
+------
+
+**ConverterFactory**
+
+一个用于“远程”转换的转换工厂，可以将对象从 `<S>` 转换为 `<R>` 的子类型。代码如下：
+
+```
+// ConverterFactory.java
+
+public interface ConverterFactory<S, R> {
+
+    <T extends R> Converter<S, T> getConverter(Class<T> targetType);
+
+}
+```
+
+子类如下：
+
+[![ConverterFactory 类图](http://static.iocoder.cn/63de40b54f1bc3a032275065d43916a1)](http://static.iocoder.cn/63de40b54f1bc3a032275065d43916a1)ConverterFactory 类图
+
+------
+
+四种不同的转换器承载着不同的转换过程：
+
+- Converter：用于 `1:1` 的 `source -> target` 类型转换。
+- ConverterFactory：用于 `1:N` 的 `source -> target` 类型转换。
+- GenericConverter用于 `N:N` 的 `source -> target` 类型转换。
+- ConditionalConverter：有条件的 `source -> target` 类型转换。
+
+------
+
+**GenericConversionService**
+
+转换器介绍完了，我们再次回归到 ConversionService 接口中去，该接口定义了两类方法：
+
+- `canConvert(sourceType, targetType)` 方法，用于判 `sourceType` 能否转成 `targetType` 。
+- `convert(source, targetType)` 方法，用于将 `source` 转成转入的 TargetType 类型实例。
+
+这两类方法都是在 GenericConversionService 中实现。
+类 GenericConversionService 实现 ConfigurableConversionService 接口，而 ConfigurableConversionService 接口继承 ConversionService 和 ConverterRegistry。
+ConverterRegistry 提供了类型转换器的管理功能，他提供了四个 add 和一个 remove 方法，支持注册/删除相应的类型转换器。
+
+GenericConversionService 作为一个基础实现类，它即支持了不同类型之间的转换，也对各类型转换器进行管理，主要是通过一个 Map 类型的 `converterCache` 和一个内部类 Converters 。在上面已经分析了 GenericConversionService 执行类型转换的过程 `#cover(...)` 方法。下面我们就一个 `addConverter(Converter<?, ?> converter)` 方法，来看看它是如何完成转换器的注入的工作的。代码如下：
+
+```
+// GenericConversionService.java
+
+@Override
+public void addConverter(Converter<?, ?> converter) {
+    // <1> 获取 ResolvableType 对象，基于 converter.getClass() 类
+    ResolvableType[] typeInfo = getRequiredTypeInfo(converter.getClass(), Converter.class);
+    // <1> 如果获取不到，并且 converter 是 DecoratingProxy 类型，则基于 ((DecoratingProxy) converter).getDecoratedClass() 类
+    if (typeInfo == null && converter instanceof DecoratingProxy) {
+        typeInfo = getRequiredTypeInfo(((DecoratingProxy) converter).getDecoratedClass(), Converter.class);
+    }
+    // 如果获取不到，抛出 IllegalArgumentException 异常
+    if (typeInfo == null) {
+        throw new IllegalArgumentException("Unable to determine source type <S> and target type <T> for your " +
+                "Converter [" + converter.getClass().getName() + "]; does the class parameterize those types?");
+    }
+    // <2> 封装成 ConverterAdapter 对象，添加到 converters 中
+    addConverter(new ConverterAdapter(converter, typeInfo[0], typeInfo[1]));
+}
+```
+
+- `<1>` 首先，根据 `converter` 获取 ResolvableType 数组。
+- `<2>` 然后，将其与 `converter` 封装成一个 ConverterAdapter 实例。
+- `<2>` 最后，调用 `#addConverter(GenericConverter converter)` 方法，添加到 `converters` 中。
+- ResolvableType 用于封装 Java 的 [Type](https://juejin.im/post/5adefaba518825670e5cb44d) 类型。
+- ConverterAdapter 则是 Converter 的一个适配器， 它实现了 GenericConverter 和 ConditionalConverter 两个类型转换器。
+
+其中，`#addConverter(GenericConverter converter)` 方法，代码如下：
+
+```
+// GenericConversionService.java
+
+@Override
+public void addConverter(GenericConverter converter) {
+    // 添加到 converters 中
+    this.converters.add(converter);
+    // 过期缓存
+    invalidateCache();
+}
+```
+
+直接调用内部类 Converters 的 `#add(GenericConverter converter)` 方法，代码如下：
+
+```
+// GenericConversionService.java
+
+public void add(GenericConverter converter) {
+    // 获得 ConvertiblePair 集合
+    Set<ConvertiblePair> convertibleTypes = converter.getConvertibleTypes();
+    // 如果为空，并且 converter 是 ConditionalConverter 类型，则添加到 【globalConverters】 中
+    if (convertibleTypes == null) {
+        Assert.state(converter instanceof ConditionalConverter,
+                "Only conditional converters may return null convertible types");
+        this.globalConverters.add(converter);
+    } else {
+        // 通过迭代的方式依次添加【converters】中
+        for (ConvertiblePair convertiblePair : convertibleTypes) {
+            // 从 converters 中，获得 ConvertersForPair 对象
+            ConvertersForPair convertersForPair = getMatchableConverters(convertiblePair);
+            // 添加 converter 到 ConvertersForPair 中
+            convertersForPair.add(converter);
+        }
+    }
+}
+```
+
+- 首先调用 GenericConverter 的 `#getConvertibleTypes()` 方法，获取 ConvertiblePair 集合。如果为空，则加入到 `globalConverters` 集合中，否则通过迭代的方式依次添加 `converters` 中。
+
+- ConvertiblePair 为 source-to-target 的持有者，它持有 `source` 和 `target` 的 class 类型，代码如下：
+
+  ```
+  // GenericConverter.java#ConvertiblePair
+  
+  final class ConvertiblePair {
+  
+      private final Class<?> sourceType;
+      private final Class<?> targetType;
+  
+      // 省略其他代码
+  }
+  ```
+
+在迭代过程中会根据 ConvertiblePair 获取相应的 ConvertersForPair 对象，然后添加 `converter` 转换器加入其中。ConvertiblePair 用于管理使用特定GenericConverter.ConvertiblePair 注册的转换器。代码如下：
+
+```
+// GenericConversionService.java#ConvertersForPair
+
+private static class ConvertersForPair {
+
+   private final LinkedList<GenericConverter> converters = new LinkedList<>();
+
+    public void add(GenericConverter converter) {
+        this.converters.addFirst(converter);
+    }
+
+    @Nullable
+    public GenericConverter getConverter(TypeDescriptor sourceType, TypeDescriptor targetType) {
+        for (GenericConverter converter : this.converters) {
+            if (!(converter instanceof ConditionalGenericConverter) ||
+                    ((ConditionalGenericConverter) converter).matches(sourceType, targetType)) {
+                return converter;
+            }
+        }
+        return null;
+    }
+
+}
+```
+
+- 其实内部就是维护一个 LinkedList 集合。他内部有两个方法：`#add(GenericConverter converter)` 和 `getConverter(TypeDescriptor sourceType, TypeDescriptor targetType)`，实现较为简单，这里就不多介绍了。
+
+------
+
+**DefaultConversionService**
+
+DefaultConversionService 是 ConversionService 的默认实现，它继承 GenericConversionService，GenericConversionService 主要用于转换器的注册和调用，DefaultConversionService 则是为 ConversionService 体系提供一些默认的转换器。
+
+在 DefaultConversionService 构造方法中就会添加默认的 Converter ，代码如下：
+
+```
+// DefaultConversionService.java
+
+public DefaultConversionService() {
+    addDefaultConverters(this);
+}
+
+public static void addDefaultConverters(ConverterRegistry converterRegistry) {
+    addScalarConverters(converterRegistry);
+    addCollectionConverters(converterRegistry);
+
+    converterRegistry.addConverter(new ByteBufferConverter((ConversionService) converterRegistry));
+    converterRegistry.addConverter(new StringToTimeZoneConverter());
+    converterRegistry.addConverter(new ZoneIdToTimeZoneConverter());
+    converterRegistry.addConverter(new ZonedDateTimeToCalendarConverter());
+
+    converterRegistry.addConverter(new ObjectToObjectConverter());
+    converterRegistry.addConverter(new IdToEntityConverter((ConversionService) converterRegistry));
+    converterRegistry.addConverter(new FallbackObjectToStringConverter());
+    converterRegistry.addConverter(new ObjectToOptionalConverter((ConversionService) converterRegistry));
+}
+```
+
+当然它还提供了一些其他的方法如 `#addCollectionConverters(ConverterRegistry converterRegistry)`、`addScalarConverters(ConverterRegistry converterRegistry)` 方法，用于注册其他类型的转换器。
+
+------
+
+至此，从 Bean 属性的转换，到 Spring ConversionService 体系的转换器 Converter 以及转换器的管理都介绍完毕了，下篇我们将分析如何利用 ConversionService 实现**自定义类型**转换器。
+
+> 艿艿：因为本文是基于调用的过程，进行解析。所以胖友可以自己在总结整理下。
+>
+> 实际上，大体的调用流是如下：
+>
+> TypeConverterSupport => ConversionService => Converter
\ No newline at end of file
diff --git a/spring/40-Spring-IoC 之自定义类型转换器.md b/spring/40-Spring-IoC 之自定义类型转换器.md
new file mode 100644
index 0000000..645e773
--- /dev/null
+++ b/spring/40-Spring-IoC 之自定义类型转换器.md	
@@ -0,0 +1,124 @@
+# 【死磕 Spring】—— IoC 之自定义类型转换器
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=todo 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+在上篇文章中小编分析了 Spring ConversionService 类型转换体系，相信各位都对其有了一个清晰的认识，这篇博客将利用 ConversionService 体系来实现自己的类型转换器。
+
+ConversionService 是 Spring 类型转换器体系中的核心接口，它定义了是否可以完成转换（`#canConvert(...)`） 与类型转换（`#convert(...)`） 两类接口方法。
+
+ConversionService 有三个子类，每个子类针对不同的类型转换：
+
+- Converter<S,T>: 将 S 类型对象转为 T 类型对象。
+- GenericConverter: 会根据源类对象及目标类对象所在的宿主类中的上下文信息进行类型转换。
+- ConverterFactory: 将相同系列多个 “同质” Converter 封装在一起。如果希望将一种类型的对象转换为另一种类型及其子类的对象(例如将 String 转换为 Number 及 Number 子类(Integer、Long、Double 等)对象)可使用该转换器工厂类。
+
+# ConversionServiceFactoryBean
+
+那么如何自定义类型转换器？分两步走：
+
+1. 实现 Converter / GenericConverter / ConverterFactory 接口
+2. 将该类注册到 ConversionServiceFactoryBean 中。
+
+ConversionServiceFactoryBean 实现了 InitializingBean 接口实现 `#afterPropertiesSet()` 方法，我们知道在 Bean 实例化 Bean 阶段，Spring 容器会检查当前 Bean 是否实现了 InitializingBean 接口，如果是则执行相应的初始化方法。（关于 InitializingBean 详情请参考：[【死磕 Spring】—– IOC 之 深入分析 InitializingBean 和 init-method](https://svip.iocoder.cn/Spring/IoC-TypeConverter-custom/)）。`#afterPropertiesSet()` 方法，代码如下：
+
+```
+// ConversionServiceFactoryBean.java
+
+@Override
+public void afterPropertiesSet() {
+    // 创建 DefaultConversionService 对象
+    this.conversionService = createConversionService();
+    // 注册到 ConversionServiceFactory 中
+    ConversionServiceFactory.registerConverters(this.converters, this.conversionService);
+}
+```
+
+- 首先调用 `#createConversionService()` 方法，初始化 `conversionService`。代码如下：
+
+  ```
+  // ConversionServiceFactoryBean.java
+  
+  protected GenericConversionService createConversionService() {
+  	return new DefaultConversionService();
+  }
+  ```
+
+- 然后调用 `ConversionServiceFactory#registerConverters(Set<?> converters, ConverterRegistry registry)` 方法，将定义的 `converters` 注入到类型转换体系中。代码如下：
+
+  ```
+  // ConverterRegistry.java
+  
+  public static void registerConverters(@Nullable Set<?> converters, ConverterRegistry registry) {
+  	if (converters != null) {
+  	    // 遍历 converters 数组，逐个注解
+  		for (Object converter : converters) {
+  			if (converter instanceof GenericConverter) {
+  				registry.addConverter((GenericConverter) converter);
+  			} else if (converter instanceof Converter<?, ?>) {
+  				registry.addConverter((Converter<?, ?>) converter);
+  			} else if (converter instanceof ConverterFactory<?, ?>) {
+  				registry.addConverterFactory((ConverterFactory<?, ?>) converter);
+  			} else {
+  				throw new IllegalArgumentException("Each converter object must implement one of the " +
+  						"Converter, ConverterFactory, or GenericConverter interfaces");
+  			}
+  		}
+  	}
+  }
+  ```
+
+  - 我们知道 ConverterRegistry 是一个 Converter 注册器，他定义了一系列注册方法。
+  - 通过调用 ConverterRegistry 的 `#addConverter(...)` 方法将转换器注册到容器中。所以在我们使用 Spring 容器的时候，Spring 将会自动识别出 IOC 容器中注册的 ConversionService 并且在 Bean 属性注入阶段使用自定义的转换器完成属性的转换了。
+
+# 示例
+
+定义 StudentConversionService 转换器：
+
+```
+public class StudentConversionService implements Converter<String, StudentService>{
+
+    @Override
+    public StudentService convert(String source) {
+        if(StringUtils.hasLength(source)){
+            String[] sources = source.split("#");
+
+            StudentService studentService = new StudentService();
+            studentService.setAge(Integer.parseInt(sources[0]));
+            studentService.setName(sources[1]);
+
+            return studentService;
+        }
+        return null;
+    }
+    
+}
+```
+
+配置：
+
+```
+<bean id="conversionService"
+          class="org.springframework.context.support.ConversionServiceFactoryBean">
+    <property name="converters">
+        <set>
+            <ref bean="studentConversionService"/>
+        </set>
+     </property>
+ </bean>
+
+<bean id="studentConversionService" class="org.springframework.core.conversion.StudentConversionService"/>
+
+<bean id="student" class="org.springframework.core.conversion.Student">
+    <property name="studentService" value="18#chenssy"/>
+</bean>
+```
+
+运行结果：
+
+> 脑补一下~哈哈哈哈
\ No newline at end of file
diff --git a/spring/41-Spring-IoC 之分析 BeanWrapper.assets/3a5c719e69c1113dcc8cdc7ff124929d.jpeg b/spring/41-Spring-IoC 之分析 BeanWrapper.assets/3a5c719e69c1113dcc8cdc7ff124929d.jpeg
new file mode 100644
index 0000000..c86d425
Binary files /dev/null and b/spring/41-Spring-IoC 之分析 BeanWrapper.assets/3a5c719e69c1113dcc8cdc7ff124929d.jpeg differ
diff --git a/spring/41-Spring-IoC 之分析 BeanWrapper.assets/dfd73f60540dd579297a1f9df9f95fe8.jpeg b/spring/41-Spring-IoC 之分析 BeanWrapper.assets/dfd73f60540dd579297a1f9df9f95fe8.jpeg
new file mode 100644
index 0000000..70854bf
Binary files /dev/null and b/spring/41-Spring-IoC 之分析 BeanWrapper.assets/dfd73f60540dd579297a1f9df9f95fe8.jpeg differ
diff --git a/spring/41-Spring-IoC 之分析 BeanWrapper.assets/fea787ac555caf4dab31fb3bc889dc8d.png b/spring/41-Spring-IoC 之分析 BeanWrapper.assets/fea787ac555caf4dab31fb3bc889dc8d.png
new file mode 100644
index 0000000..a5ff76b
Binary files /dev/null and b/spring/41-Spring-IoC 之分析 BeanWrapper.assets/fea787ac555caf4dab31fb3bc889dc8d.png differ
diff --git a/spring/41-Spring-IoC 之分析 BeanWrapper.md b/spring/41-Spring-IoC 之分析 BeanWrapper.md
new file mode 100644
index 0000000..1d66628
--- /dev/null
+++ b/spring/41-Spring-IoC 之分析 BeanWrapper.md	
@@ -0,0 +1,199 @@
+# 【死磕 Spring】—— IoC 之分析 BeanWrapper
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=todo 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+在实例化 Bean 阶段，我们从 BeanDefinition 得到的并不是我们最终想要的 Bean 实例，而是 BeanWrapper 实例，如下：
+
+[![img](41-Spring-IoC 之分析 BeanWrapper.assets/dfd73f60540dd579297a1f9df9f95fe8.jpeg)](http://static.iocoder.cn/dfd73f60540dd579297a1f9df9f95fe8)
+
+所以这里 BeanWrapper 是一个从 BeanDefinition 到 Bean 直接的**中间产物**，我们可以称它为”低级 bean“。在一般情况下，我们不会在实际项目中用到它。BeanWrapper 是 Spring 框架中重要的组件类，它就相当于一个代理类，Spring 委托 BeanWrapper 完成 Bean 属性的填充工作。在 Bean 实例被 InstantiationStrategy 创建出来后，Spring 容器会将 Bean 实例通过 BeanWrapper 包裹起来，是通过如如下代码实现：
+
+[![img](41-Spring-IoC 之分析 BeanWrapper.assets/3a5c719e69c1113dcc8cdc7ff124929d.jpeg)](http://static.iocoder.cn/3a5c719e69c1113dcc8cdc7ff124929d)
+
+- `beanInstance` 就是我们实例出来的 bean 实例，通过构造一个 BeanWrapper 实例对象进行包裹，如下：
+
+  ```
+  // BeanWrapperImpl.java
+  
+  public BeanWrapperImpl(Object object) {
+      super(object);
+  }
+  
+  protected AbstractNestablePropertyAccessor(Object object) {
+      registerDefaultEditors();
+      setWrappedInstance(object);
+  }
+  ```
+
+------
+
+下面小编就 BeanWrapper 来进行分析说明，先看整体的结构：
+
+[![2018101210001](41-Spring-IoC 之分析 BeanWrapper.assets/fea787ac555caf4dab31fb3bc889dc8d.png)](http://static.iocoder.cn/fea787ac555caf4dab31fb3bc889dc8d)2018101210001
+
+从上图可以看出 BeanWrapper 主要继承三个核心接口：PropertyAccessor、PropertyEditorRegistry、TypeConverter。
+
+**PropertyAccessor**
+
+> 可以访问属性的通用型接口（例如对象的 bean 属性或者对象中的字段），作为 BeanWrapper 的基础接口。
+
+```
+// PropertyAccessor.java
+
+public interface PropertyAccessor {
+
+    String NESTED_PROPERTY_SEPARATOR = ".";
+    char NESTED_PROPERTY_SEPARATOR_CHAR = '.';
+
+    String PROPERTY_KEY_PREFIX = "[";
+    char PROPERTY_KEY_PREFIX_CHAR = '[';
+
+    String PROPERTY_KEY_SUFFIX = "]";
+    char PROPERTY_KEY_SUFFIX_CHAR = ']';
+
+    boolean isReadableProperty(String propertyName);
+
+    boolean isWritableProperty(String propertyName);
+
+    Class<?> getPropertyType(String propertyName) throws BeansException;
+    TypeDescriptor getPropertyTypeDescriptor(String propertyName) throws BeansException;
+    Object getPropertyValue(String propertyName) throws BeansException;
+
+    void setPropertyValue(String propertyName, @Nullable Object value) throws BeansException;
+    void setPropertyValue(PropertyValue pv) throws BeansException;
+    void setPropertyValues(Map<?, ?> map) throws BeansException;
+    void setPropertyValues(PropertyValues pvs) throws BeansException;
+    void setPropertyValues(PropertyValues pvs, boolean ignoreUnknown)
+    throws BeansException;
+    void setPropertyValues(PropertyValues pvs, boolean ignoreUnknown, boolean ignoreInvalid)
+    throws BeansException;
+
+}
+```
+
+就上面的源码我们可以分解为四类方法：
+
+- `#isReadableProperty(String propertyName)` 方法：判断指定 property 是否可读，是否包含 getter 方法。
+- `#isWritableProperty(String propertyName)` 方法：判断指定 property 是否可写,是否包含 setter 方法。
+- `#getPropertyType(...)` 方法：获取指定 propertyName 的类型
+- `#setPropertyValue(...)` 方法：设置指定 propertyValue 。
+
+------
+
+**PropertyEditorRegistry**
+
+> 用于注册 JavaBean 的 PropertyEditors，对 PropertyEditorRegistrar 起核心作用的中心接口。由 BeanWrapper 扩展，BeanWrapperImpl 和 DataBinder 实现。
+
+```
+// PropertyEditorRegistry.java
+
+public interface PropertyEditorRegistry {
+
+    void registerCustomEditor(Class<?> requiredType, PropertyEditor propertyEditor);
+
+    void registerCustomEditor(@Nullable Class<?> requiredType, @Nullable String propertyPath, PropertyEditor propertyEditor);
+
+    @Nullable
+    PropertyEditor findCustomEditor(@Nullable Class<?> requiredType, @Nullable String propertyPath);
+
+}
+```
+
+根据接口提供的方法，PropertyEditorRegistry 就是用于 PropertyEditor 的注册和发现，而 PropertyEditor 是 Java 内省里面的接口，用于改变指定 property 属性的类型。
+
+------
+
+**TypeConverter**
+
+> 定义类型转换的接口，通常与 PropertyEditorRegistry 接口一起实现（但不是必须），但由于 TypeConverter 是基于线程不安全的 PropertyEditors ，因此 TypeConverters 本身也不被视为线程安全。
+> 这里小编解释下，在 Spring 3 后，不在采用 PropertyEditors 类作为 Spring 默认的类型转换接口，而是采用 ConversionService 体系，但 ConversionService 是线程安全的，所以在 Spring 3 后，如果你所选择的类型转换器是 ConversionService 而不是 PropertyEditors 那么 TypeConverters 则是线程安全的。
+
+```
+public interface TypeConverter {
+
+    <T> T convertIfNecessary(Object value, Class<T> requiredType) throws TypeMismatchException;
+    <T> T convertIfNecessary(Object value, Class<T> requiredType, MethodParameter methodParam)
+            throws TypeMismatchException;
+    <T> T convertIfNecessary(Object value, Class<T> requiredType, Field field)
+            throws TypeMismatchException;
+
+}
+```
+
+------
+
+BeanWrapper 继承上述三个接口，那么它就具有三重身份：
+
+- 属性编辑器
+- 属性编辑器注册表
+- 类型转换器
+
+BeanWrapper 继承 ConfigurablePropertyAccessor 接口，该接口除了继承上面介绍的三个接口外还集成了 Spring 的 ConversionService 类型转换体系。
+
+```
+// ConfigurablePropertyAccessor.java
+
+public interface ConfigurablePropertyAccessor extends PropertyAccessor, PropertyEditorRegistry, TypeConverter {
+
+    void setConversionService(@Nullable ConversionService conversionService);
+
+    @Nullable
+    ConversionService getConversionService();
+
+    void setExtractOldValueForEditor(boolean extractOldValueForEditor);
+
+    boolean isExtractOldValueForEditor();
+
+    void setAutoGrowNestedPaths(boolean autoGrowNestedPaths);
+
+    boolean isAutoGrowNestedPaths();
+
+}
+```
+
+`#setConversionService(ConversionService conversionService)` 和 `#getConversionService()` 方法，则是用于集成 Spring 的 ConversionService 类型转换体系。
+
+**BeanWrapper**
+
+> Spring 的 低级 JavaBean 基础结构的接口，一般不会直接使用，而是通过 BeanFactory 或者 DataBinder 隐式使用。它提供分析和操作标准 JavaBeans 的操作：获取和设置属性值、获取属性描述符以及查询属性的可读性/可写性的能力。
+
+```
+// BeanWrapper.java
+public interface BeanWrapper extends ConfigurablePropertyAccessor {
+
+    void setAutoGrowCollectionLimit(int autoGrowCollectionLimit);
+    int getAutoGrowCollectionLimit();
+
+    Object getWrappedInstance();
+    Class<?> getWrappedClass();
+
+    PropertyDescriptor[] getPropertyDescriptors();
+    PropertyDescriptor getPropertyDescriptor(String propertyName) throws InvalidPropertyException;
+
+}
+```
+
+下面几个方法比较重要：
+
+- `#getWrappedInstance()` 方法：获取包装对象的实例。
+- `#getWrappedClass()` 方法：获取包装对象的类型。
+- `#getPropertyDescriptors()` 方法：获取包装对象所有属性的 PropertyDescriptor 就是这个属性的上下文。
+- `#getPropertyDescriptor(String propertyName)` 方法：获取包装对象指定属性的上下文。
+
+------
+
+**BeanWrapperImpl**
+
+> BeanWrapper 接口的默认实现，用于对Bean的包装，实现上面接口所定义的功能很简单包括设置获取被包装的对象，获取被包装bean的属性描述器
+
+------
+
+**小结**
+
+BeanWrapper 体系相比于 Spring 中其他体系是比较简单的，它作为 BeanDefinition 向 Bean 转换过程中的中间产物，承载了 Bean 实例的包装、类型转换、属性的设置以及访问等重要作用。
\ No newline at end of file
diff --git a/spring/42-Spring-IoC 之 Bean 的实例化策略：InstantiationStrategy.assets/4cdb7d0fafb164c00feb74680948e785.jpeg b/spring/42-Spring-IoC 之 Bean 的实例化策略：InstantiationStrategy.assets/4cdb7d0fafb164c00feb74680948e785.jpeg
new file mode 100644
index 0000000..ce68bd6
Binary files /dev/null and b/spring/42-Spring-IoC 之 Bean 的实例化策略：InstantiationStrategy.assets/4cdb7d0fafb164c00feb74680948e785.jpeg differ
diff --git a/spring/42-Spring-IoC 之 Bean 的实例化策略：InstantiationStrategy.md b/spring/42-Spring-IoC 之 Bean 的实例化策略：InstantiationStrategy.md
new file mode 100644
index 0000000..760f188
--- /dev/null
+++ b/spring/42-Spring-IoC 之 Bean 的实例化策略：InstantiationStrategy.md	
@@ -0,0 +1,400 @@
+# 【死磕 Spring】—— IoC 之 Bean 的实例化策略：InstantiationStrategy
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=todo 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+在开始分析 InstantiationStrategy 之前，我们先来简单回顾下 Bean 的实例化过程：
+
+1. Bean 的创建，主要是 `AbstractAutowireCapableBeanFactory#doCreateBean(...)` 方法。在这个方法中有 Bean 的实例化、属性注入和初始化过程，对于 Bean 的实例化过程这是根据 Bean 的类型来判断的，如果是单例模式，则直接从 `factoryBeanInstanceCache` 缓存中获取，否则调用 `#createBeanInstance(...)` 方法来创建。
+2. 在 `#createBeanInstance(...)` 方法中，如果 Supplier 不为空，则调用 `#obtainFromSupplier(...)` 实例化 bean。如果 `factory` 不为空，则调用 `#instantiateUsingFactoryMethod(...)` 方法来实例化 Bean 。如果都不是，则调用 `#instantiateBean(...)` 方法来实例化 Bean 。但是无论是 `#instantiateUsingFactoryMethod(...)` 方法，还是 `#instantiateBean()` 方法，最后都一定会调用到 InstantiationStrategy 接口的 `#instantiate(...)` 方法。
+
+# 1. InstantiationStrategy
+
+InstantiationStrategy 接口定义了 Spring Bean 实例化的策略，根据创建对象情况的不同，提供了三种策略：无参构造方法、有参构造方法、工厂方法。代码如下：
+
+```
+public interface InstantiationStrategy {
+
+    /**
+    * 默认构造方法
+    */
+    Object instantiate(RootBeanDefinition bd, @Nullable String beanName, BeanFactory owner)
+    throws BeansException;
+
+    /**
+    * 指定构造方法
+    */
+    Object instantiate(RootBeanDefinition bd, @Nullable String beanName, BeanFactory owner,
+    Constructor<?> ctor, @Nullable Object... args) throws BeansException;
+
+    /**
+    * 工厂方法
+    */
+    Object instantiate(RootBeanDefinition bd, @Nullable String beanName, BeanFactory owner,
+    @Nullable Object factoryBean, Method factoryMethod, @Nullable Object... args)
+    throws BeansException;
+
+}
+```
+
+# 2. SimpleInstantiationStrategy
+
+InstantiationStrategy 接口有两个实现类：SimpleInstantiationStrategy 和 CglibSubclassingInstantiationStrategy。
+
+SimpleInstantiationStrategy 对以上三个方法都做了简单的实现。
+
+① 如果是工厂方法实例化，则直接使用反射创建对象，如下：
+
+```
+// SimpleInstantiationStrategy.java
+
+@Override
+public Object instantiate(RootBeanDefinition bd, @Nullable String beanName, BeanFactory owner,
+        @Nullable Object factoryBean, final Method factoryMethod, Object... args) {
+    try {
+        // 设置 Method 可访问
+        if (System.getSecurityManager() != null) {
+            AccessController.doPrivileged((PrivilegedAction<Object>) () -> {
+                ReflectionUtils.makeAccessible(factoryMethod);
+                return null;
+            });
+        } else {
+            ReflectionUtils.makeAccessible(factoryMethod);
+        }
+
+        // 获得原 Method 对象
+        Method priorInvokedFactoryMethod = currentlyInvokedFactoryMethod.get();
+        try {
+            // 设置新的 Method 对象，到 currentlyInvokedFactoryMethod 中
+            currentlyInvokedFactoryMethod.set(factoryMethod);
+            // 创建 Bean 对象
+            Object result = factoryMethod.invoke(factoryBean, args);
+            // 未创建，则创建 NullBean 对象
+            if (result == null) {
+                result = new NullBean();
+            }
+            return result;
+        } finally {
+            // 设置老的 Method 对象，到 currentlyInvokedFactoryMethod 中
+            if (priorInvokedFactoryMethod != null) {
+                currentlyInvokedFactoryMethod.set(priorInvokedFactoryMethod);
+            } else {
+                currentlyInvokedFactoryMethod.remove();
+            }
+        }
+    // 一大堆 catch 异常
+    } catch (IllegalArgumentException ex) {
+        throw new BeanInstantiationException(factoryMethod,
+                "Illegal arguments to factory method '" + factoryMethod.getName() + "'; " +
+                "args: " + StringUtils.arrayToCommaDelimitedString(args), ex);
+    } catch (IllegalAccessException ex) {
+        throw new BeanInstantiationException(factoryMethod,
+                "Cannot access factory method '" + factoryMethod.getName() + "'; is it public?", ex);
+    } catch (InvocationTargetException ex) {
+        String msg = "Factory method '" + factoryMethod.getName() + "' threw exception";
+        if (bd.getFactoryBeanName() != null && owner instanceof ConfigurableBeanFactory &&
+                ((ConfigurableBeanFactory) owner).isCurrentlyInCreation(bd.getFactoryBeanName())) {
+            msg = "Circular reference involving containing bean '" + bd.getFactoryBeanName() + "' - consider " +
+                    "declaring the factory method as static for independence from its containing instance. " + msg;
+        }
+        throw new BeanInstantiationException(factoryMethod, msg, ex.getTargetException());
+    }
+}
+```
+
+② 如果是构造方法实例化，则是先判断是否有 MethodOverrides，如果没有则是直接使用反射，如果有则就需要 CGLIB 实例化对象。如下：
+
+```
+// SimpleInstantiationStrategy.java
+
+// 默认构造方法
+@Override
+public Object instantiate(RootBeanDefinition bd, @Nullable String beanName, BeanFactory owner) {
+	// Don't override the class with CGLIB if no overrides.
+    // 没有覆盖，直接使用反射实例化即可
+    if (!bd.hasMethodOverrides()) {
+		Constructor<?> constructorToUse;
+		synchronized (bd.constructorArgumentLock) {
+		    // 获得构造方法 constructorToUse
+			constructorToUse = (Constructor<?>) bd.resolvedConstructorOrFactoryMethod;
+			if (constructorToUse == null) {
+				final Class<?> clazz = bd.getBeanClass();
+				// 如果是接口，抛出 BeanInstantiationException 异常
+				if (clazz.isInterface()) {
+					throw new BeanInstantiationException(clazz, "Specified class is an interface");
+				}
+				try {
+				    // 从 clazz 中，获得构造方法
+					if (System.getSecurityManager() != null) { // 安全模式
+						constructorToUse = AccessController.doPrivileged(
+								(PrivilegedExceptionAction<Constructor<?>>) clazz::getDeclaredConstructor);
+					} else {
+						constructorToUse =	clazz.getDeclaredConstructor();
+					}
+					// 标记 resolvedConstructorOrFactoryMethod 属性
+					bd.resolvedConstructorOrFactoryMethod = constructorToUse;
+				} catch (Throwable ex) {
+					throw new BeanInstantiationException(clazz, "No default constructor found", ex);
+				}
+			}
+		}
+        // 通过 BeanUtils 直接使用构造器对象实例化 Bean 对象
+        return BeanUtils.instantiateClass(constructorToUse);
+	} else {
+		// Must generate CGLIB subclass.
+        // 生成 CGLIB 创建的子类对象
+        return instantiateWithMethodInjection(bd, beanName, owner);
+	}
+}
+
+// 指定构造方法
+@Override
+public Object instantiate(RootBeanDefinition bd, @Nullable String beanName, BeanFactory owner,
+		final Constructor<?> ctor, Object... args) {
+    // 没有覆盖，直接使用反射实例化即可
+	if (!bd.hasMethodOverrides()) {
+		if (System.getSecurityManager() != null) {
+		    // 设置构造方法，可访问
+			// use own privileged to change accessibility (when security is on)
+			AccessController.doPrivileged((PrivilegedAction<Object>) () -> {
+				ReflectionUtils.makeAccessible(ctor);
+				return null;
+			});
+		}
+        // 通过 BeanUtils 直接使用构造器对象实例化 Bean 对象
+		return BeanUtils.instantiateClass(ctor, args);
+	} else {
+        // 生成 CGLIB 创建的子类对象
+		return instantiateWithMethodInjection(bd, beanName, owner, ctor, args);
+	}
+}
+```
+
+- SimpleInstantiationStrategy 对 `#instantiateWithMethodInjection(RootBeanDefinition bd, String beanName, BeanFactory owner, Constructor<?> ctor, Object... args)` 的实现任务交给了子类 CglibSubclassingInstantiationStrategy 。
+
+# 3. MethodOverrides
+
+对于 MethodOverrides，如果读者是跟着小编文章一路跟过来的话一定不会陌生，在 BeanDefinitionParserDelegate 类解析 `<bean/>` 的时候是否还记得这两个方法：`#parseLookupOverrideSubElements(...)` 和 `#parseReplacedMethodSubElements(...)` 这两个方法分别用于解析 `lookup-method` 和 `replaced-method` 属性。
+
+其中，`#parseLookupOverrideSubElements(...)` 源码如下：
+
+[![parseLookupOverrideSubElements](42-Spring-IoC 之 Bean 的实例化策略：InstantiationStrategy.assets/4cdb7d0fafb164c00feb74680948e785.jpeg)](http://static.iocoder.cn/4cdb7d0fafb164c00feb74680948e785)parseLookupOverrideSubElements
+
+更多关于 `lookup-method` 和 `replaced-method` 请看：[【死磕 Spring】—– IoC 之解析 bean 标签：meta、lookup-method、replace-method](http://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-for-meta-and-look-method-and-replace-method)
+
+# 4. CglibSubclassingInstantiationStrategy
+
+类 CglibSubclassingInstantiationStrategy 为 Spring 实例化 Bean 的默认实例化策略，其主要功能还是对父类功能进行补充：其父类将 CGLIB 的实例化策略委托其实现。
+
+```
+// SimpleInstantiationStrategy.java
+
+protected Object instantiateWithMethodInjection(RootBeanDefinition bd, @Nullable String beanName, BeanFactory owner) {
+	throw new UnsupportedOperationException("Method Injection not supported in SimpleInstantiationStrategy");
+}
+
+// CglibSubclassingInstantiationStrategy.java
+
+@Override
+protected Object instantiateWithMethodInjection(RootBeanDefinition bd, @Nullable String beanName, BeanFactory owner) {
+	return instantiateWithMethodInjection(bd, beanName, owner, null);
+}
+```
+
+- CglibSubclassingInstantiationStrategy 实例化 Bean 策略，是通过其内部类 **CglibSubclassCreator** 来实现的。代码如下：
+
+  ```
+  // CglibSubclassingInstantiationStrategy.java
+  
+  @Override
+  protected Object instantiateWithMethodInjection(RootBeanDefinition bd, @Nullable String beanName, BeanFactory owner, @Nullable Constructor<?> ctor, Object... args) {
+  	// Must generate CGLIB subclass...
+      // 通过CGLIB生成一个子类对象
+  	return new CglibSubclassCreator(bd, owner).instantiate(ctor, args);
+  }
+  ```
+
+- 创建 CglibSubclassCreator 实例，然后调用其 `#instantiate(Constructor<?> ctor, Object... args)` 方法，该方法用于动态创建子类实例，同时实现所需要的 lookups（`lookup-method`、`replace-method`）。
+
+  ```
+  // CglibSubclassingInstantiationStrategy.java#CglibSubclassCreator
+  
+  public Object instantiate(@Nullable Constructor<?> ctor, Object... args) {
+      // <x> 通过 Cglib 创建一个代理类
+      Class<?> subclass = createEnhancedSubclass(this.beanDefinition);
+      Object instance;
+      // <y> 没有构造器，通过 BeanUtils 使用默认构造器创建一个bean实例
+      if (ctor == null) {
+          instance = BeanUtils.instantiateClass(subclass);
+      } else {
+          try {
+              // 获取代理类对应的构造器对象，并实例化 bean
+              Constructor<?> enhancedSubclassConstructor = subclass.getConstructor(ctor.getParameterTypes());
+              instance = enhancedSubclassConstructor.newInstance(args);
+          } catch (Exception ex) {
+              throw new BeanInstantiationException(this.beanDefinition.getBeanClass(),
+                      "Failed to invoke constructor for CGLIB enhanced subclass [" + subclass.getName() + "]", ex);
+          }
+      }
+      // SPR-10785: set callbacks directly on the instance instead of in the
+      // enhanced class (via the Enhancer) in order to avoid memory leaks.
+      // 为了避免 memory leaks 异常，直接在 bean 实例上设置回调对象
+      Factory factory = (Factory) instance;
+      factory.setCallbacks(new Callback[] {NoOp.INSTANCE,
+              new LookupOverrideMethodInterceptor(this.beanDefinition, this.owner),
+              new ReplaceOverrideMethodInterceptor(this.beanDefinition, this.owner)});
+      return instance;
+  }
+  ```
+
+  - 在 `<x>` 处，调用 `#createEnhancedSubclass(RootBeanDefinition beanDefinition)` 方法，为提供的 BeanDefinition 创建 bean 类的增强子类。代码如下：
+
+    ```
+    // CglibSubclassingInstantiationStrategy.java#CglibSubclassCreator
+    
+    private Class<?> createEnhancedSubclass(RootBeanDefinition beanDefinition) {
+        // 创建 Enhancer 对象
+        Enhancer enhancer = new Enhancer();
+        // 设置 Bean 类
+        enhancer.setSuperclass(beanDefinition.getBeanClass());
+        // 设置 Spring 的命名策略
+        enhancer.setNamingPolicy(SpringNamingPolicy.INSTANCE);
+        // 设置生成策略
+        if (this.owner instanceof ConfigurableBeanFactory) {
+            ClassLoader cl = ((ConfigurableBeanFactory) this.owner).getBeanClassLoader();
+            enhancer.setStrategy(new ClassLoaderAwareGeneratorStrategy(cl));
+        }
+        // 过滤，自定义逻辑来指定调用的callback下标
+        enhancer.setCallbackFilter(new MethodOverrideCallbackFilter(beanDefinition));
+        enhancer.setCallbackTypes(CALLBACK_TYPES);
+        return enhancer.createClass();
+    }
+    ```
+
+    - CGLIB 的标准 API 的使用。
+
+  - `<y>` 处，获取子类增强 `subclass` 后，如果 Constructor 实例 `ctr` 为空，则调用默认构造函数（`BeanUtils#instantiateClass(subclass)`）来实例化类，否则则根据构造函数类型获取具体的构造器，调用 `Constructor#newInstance(args)` 方法来实例化类。
+
+## 4.1 MethodOverrideCallbackFilter
+
+在 `<x>` 处调用的 `#createEnhancedSubclass(RootBeanDefinition beanDefinition)` 方法，我们注意两行代码：
+
+```
+// CglibSubclassingInstantiationStrategy.java#CglibSubclassCreator
+
+enhancer.setCallbackFilter(new MethodOverrideCallbackFilter(beanDefinition));
+enhancer.setCallbackTypes(CALLBACK_TYPES);
+```
+
+- 通过 MethodOverrideCallbackFilter 来定义调用 callback 类型。
+
+MethodOverrideCallbackFilter 是用来定义 CGLIB 回调过滤方法的拦截器行为，它继承 CglibIdentitySupport 实现 CallbackFilter 接口。
+
+- CallbackFilter 是 CGLIB 的一个回调过滤器。
+- CglibIdentitySupport 则为 CGLIB 提供 `#hashCode()` 和 `#equals(Object o)` 方法，以确保 CGLIB 不会为每个 Bean 生成不同的类。
+
+MethodOverrideCallbackFilter 实现 CallbackFilter 的 `#accept(Method method)` 方法，代码如下：
+
+```
+// CglibSubclassingInstantiationStrategy.java#MethodOverrideCallbackFilter
+
+@Override
+public int accept(Method method) {
+	MethodOverride methodOverride = getBeanDefinition().getMethodOverrides().getOverride(method);
+	if (logger.isTraceEnabled()) {
+		logger.trace("Override for '" + method.getName() + "' is [" + methodOverride + "]");
+	}
+	if (methodOverride == null) {
+		return PASSTHROUGH;
+	} else if (methodOverride instanceof LookupOverride) {
+		return LOOKUP_OVERRIDE;
+	} else if (methodOverride instanceof ReplaceOverride) {
+		return METHOD_REPLACER;
+	}
+	throw new UnsupportedOperationException("Unexpected MethodOverride subclass: " +
+			methodOverride.getClass().getName());
+}
+```
+
+- 根据 BeanDefinition 中定义的 MethodOverride 不同，返回不同的值， 这里返回的 `PASSTHROUGH` 、`LOOKUP_OVERRIDE`、`METHOD_REPLACER` 都是 Callback 数组的**下标**，这里对应的数组为 `CALLBACK_TYPES` 数组，如下：
+
+  ```
+  // CglibSubclassingInstantiationStrategy.java#CglibSubclassCreator
+  
+  private static final Class<?>[] CALLBACK_TYPES = new Class<?>[] {
+      NoOp.class,
+      LookupOverrideMethodInterceptor.class,
+      ReplaceOverrideMethodInterceptor.class
+  };
+  ```
+
+  - 这里又定义了两个熟悉的拦截器 ：LookupOverrideMethodInterceptor 和 ReplaceOverrideMethodInterceptor，两个拦截器分别对应两个不同的 callback 业务。详细解析，见 [「4.2 LookupOverrideMethodInterceptor」](https://svip.iocoder.cn/Spring/IoC-InstantiationStrategy/#) 和 [「4.3 ReplaceOverrideMethodInterceptor」](https://svip.iocoder.cn/Spring/IoC-InstantiationStrategy/#) 中。
+
+## 4.2 LookupOverrideMethodInterceptor
+
+```
+// CglibSubclassingInstantiationStrategy.java#LookupOverrideMethodInterceptor
+
+private static class LookupOverrideMethodInterceptor extends CglibIdentitySupport implements MethodInterceptor {
+
+    private final BeanFactory owner;
+
+    public LookupOverrideMethodInterceptor(RootBeanDefinition beanDefinition, BeanFactory owner) {
+        super(beanDefinition);
+        this.owner = owner;
+    }
+
+    @Override
+    public Object intercept(Object obj, Method method, Object[] args, MethodProxy mp) throws Throwable {
+        // Cast is safe, as CallbackFilter filters are used selectively.
+        // 获得 method 对应的 LookupOverride 对象
+        LookupOverride lo = (LookupOverride) getBeanDefinition().getMethodOverrides().getOverride(method);
+        Assert.state(lo != null, "LookupOverride not found");
+        // 获得参数
+        Object[] argsToUse = (args.length > 0 ? args : null);  // if no-arg, don't insist on args at all
+        // 获得 Bean
+        if (StringUtils.hasText(lo.getBeanName())) { // Bean 的名字
+            return (argsToUse != null ? this.owner.getBean(lo.getBeanName(), argsToUse) :
+                    this.owner.getBean(lo.getBeanName()));
+        } else { // Bean 的类型
+            return (argsToUse != null ? this.owner.getBean(method.getReturnType(), argsToUse) :
+                    this.owner.getBean(method.getReturnType()));
+        }
+    }
+}
+```
+
+## 4.3 ReplaceOverrideMethodInterceptor
+
+```
+// CglibSubclassingInstantiationStrategy.java#ReplaceOverrideMethodInterceptor
+
+private static class ReplaceOverrideMethodInterceptor extends CglibIdentitySupport implements MethodInterceptor {
+
+    private final BeanFactory owner;
+
+    public ReplaceOverrideMethodInterceptor(RootBeanDefinition beanDefinition, BeanFactory owner) {
+        super(beanDefinition);
+        this.owner = owner;
+    }
+
+    @Override
+    public Object intercept(Object obj, Method method, Object[] args, MethodProxy mp) throws Throwable {
+        // 获得 method 对应的 LookupOverride 对象
+        ReplaceOverride ro = (ReplaceOverride) getBeanDefinition().getMethodOverrides().getOverride(method);
+        Assert.state(ro != null, "ReplaceOverride not found");
+        // TODO could cache if a singleton for minor performance optimization
+        // 获得 MethodReplacer 对象
+        MethodReplacer mr = this.owner.getBean(ro.getMethodReplacerBeanName(), MethodReplacer.class);
+        // 执行替换
+        return mr.reimplement(obj, method, args);
+    }
+}
+```
+
+通过这两个拦截器，再加上这篇博客：[【死磕 Spring】—— IoC 之解析 bean 标签：meta、lookup-method、replace-method](http://svip.iocoder.cn/Spring/IoC-parse-BeanDefinitions-for-meta-and-look-method-and-replace-method)，是不是一道绝佳的美食。
\ No newline at end of file
diff --git a/spring/43-Spring-IoC 之 BeanDefinition 注册表：BeanDefinitionRegistry.assets/c91d5c1d310f4257bb0edae3444e7cd9.jpeg b/spring/43-Spring-IoC 之 BeanDefinition 注册表：BeanDefinitionRegistry.assets/c91d5c1d310f4257bb0edae3444e7cd9.jpeg
new file mode 100644
index 0000000..b50adc6
Binary files /dev/null and b/spring/43-Spring-IoC 之 BeanDefinition 注册表：BeanDefinitionRegistry.assets/c91d5c1d310f4257bb0edae3444e7cd9.jpeg differ
diff --git a/spring/43-Spring-IoC 之 BeanDefinition 注册表：BeanDefinitionRegistry.md b/spring/43-Spring-IoC 之 BeanDefinition 注册表：BeanDefinitionRegistry.md
new file mode 100644
index 0000000..40afa88
--- /dev/null
+++ b/spring/43-Spring-IoC 之 BeanDefinition 注册表：BeanDefinitionRegistry.md	
@@ -0,0 +1,224 @@
+# 【死磕 Spring】—— IoC 之 BeanDefinition 注册表：BeanDefinitionRegistry
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=todo 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+将定义 Bean 的资源文件解析成 BeanDefinition 后需要将其注入容器中，这个过程由 BeanDefinitionRegistry 来完成。
+
+**BeanDefinitionRegistry：向注册表中注册 BeanDefinition 实例，完成注册的过程。**
+
+下图是 BeanDefinitionRegistry 类结构图：
+
+[![BeanDefinitionRegistry 类图](43-Spring-IoC 之 BeanDefinition 注册表：BeanDefinitionRegistry.assets/c91d5c1d310f4257bb0edae3444e7cd9.jpeg)](http://static.iocoder.cn/c91d5c1d310f4257bb0edae3444e7cd9)BeanDefinitionRegistry 类图
+
+BeanDefinitionRegistry 继承了 AliasRegistry 接口，其核心子类有三个：SimpleBeanDefinitionRegistry、DefaultListableBeanFactory、GenericApplicationContext 。
+
+# 1. AliasRegistry
+
+**用于别名管理的通用型接口，作为 BeanDefinitionRegistry 的顶层接口。** AliasRegistry 定义了一些别名管理的方法。
+
+```
+// AliasRegistry.java
+
+public interface AliasRegistry {
+
+    void registerAlias(String name, String alias);
+    void removeAlias(String alias);
+
+    boolean isAlias(String name);
+    String[] getAliases(String name);
+
+}
+```
+
+# 2. BeanDefinitionRegistry
+
+**BeanDefinition 的注册接口，如 RootBeanDefinition 和 ChildBeanDefinition。它通常由 BeanFactories 实现，在 Spring 中已知的实现者为：DefaultListableBeanFactory 和 GenericApplicationContext。BeanDefinitionRegistry 是 Spring 的 Bean 工厂包中唯一封装 BeanDefinition 注册的接口。**
+
+BeanDefinitionRegistry 接口定义了关于 BeanDefinition 注册、注销、查询等一系列的操作。
+
+```
+// BeanDefinitionRegistry.java
+
+    public interface BeanDefinitionRegistry extends AliasRegistry {
+
+    // 往注册表中注册一个新的 BeanDefinition 实例
+    void registerBeanDefinition(String beanName, BeanDefinition beanDefinition) throws BeanDefinitionStoreException;
+
+    // 移除注册表中已注册的 BeanDefinition 实例
+    void removeBeanDefinition(String beanName) throws NoSuchBeanDefinitionException;
+
+    // 从注册中取得指定的 BeanDefinition 实例
+    BeanDefinition getBeanDefinition(String beanName) throws NoSuchBeanDefinitionException;
+
+    // 判断 BeanDefinition 实例是否在注册表中（是否注册）
+    boolean containsBeanDefinition(String beanName);
+
+    // 取得注册表中所有 BeanDefinition 实例的 beanName（标识）
+    String[] getBeanDefinitionNames();
+
+    // 返回注册表中 BeanDefinition 实例的数量
+    int getBeanDefinitionCount();
+
+    // beanName（标识）是否被占用
+    boolean isBeanNameInUse(String beanName);
+
+}
+```
+
+# 3. SimpleBeanDefinitionRegistry
+
+**SimpleBeanDefinitionRegistry 是 BeanDefinitionRegistry 一个简单的实现，它还继承 SimpleAliasRegistry（ AliasRegistry 的简单实现），它仅仅只提供注册表功能，无工厂功能**。
+
+SimpleBeanDefinitionRegistry 使用 ConcurrentHashMap 来存储注册的 BeanDefinition。
+
+```
+// SimpleBeanDefinitionRegistry.java
+
+private final Map<String, BeanDefinition> beanDefinitionMap = new ConcurrentHashMap<>(64);
+```
+
+他对注册其中的 BeanDefinition 都是基于 `beanDefinitionMap` 这个集合来实现的，如下：
+
+```
+// SimpleBeanDefinitionRegistry.java
+
+@Override
+public void registerBeanDefinition(String beanName, BeanDefinition beanDefinition)
+   throws BeanDefinitionStoreException {
+	Assert.hasText(beanName, "'beanName' must not be empty");
+	Assert.notNull(beanDefinition, "BeanDefinition must not be null");
+	this.beanDefinitionMap.put(beanName, beanDefinition);
+}
+
+@Override
+public void removeBeanDefinition(String beanName) throws NoSuchBeanDefinitionException {
+	if (this.beanDefinitionMap.remove(beanName) == null) {
+		throw new NoSuchBeanDefinitionException(beanName);
+	}
+}
+
+@Override
+public BeanDefinition getBeanDefinition(String beanName) throws NoSuchBeanDefinitionException {
+	BeanDefinition bd = this.beanDefinitionMap.get(beanName);
+	if (bd == null) {
+		throw new NoSuchBeanDefinitionException(beanName);
+	}
+	return bd;
+}
+```
+
+实现简单、粗暴。
+
+# 4. DefaultListableBeanFactory
+
+**DefaultListableBeanFactory，ConfigurableListableBeanFactory（其实就是 BeanFactory ） 和 BeanDefinitionRegistry 接口的默认实现：一个基于 BeanDefinition 元数据的完整 bean 工厂**。所以相对于 SimpleBeanDefinitionRegistry 而言，DefaultListableBeanFactory 则是一个具有注册功能的完整 Bean 工厂。它同样是用 ConcurrentHashMap 数据结构来存储注册的 BeanDefinition 。
+
+```
+// DefaultListableBeanFactory.java
+
+// 注册表，由 BeanDefinition 的标识 （beanName） 与其实例组成
+private final Map<String, BeanDefinition> beanDefinitionMap = new ConcurrentHashMap<String, bean>(64);
+
+// 标识（beanName）集合
+private final List<String> beanDefinitionNames = new ArrayList<String>(64);
+```
+
+## 4.1 registerBeanDefinition
+
+在看看 `#registerBeanDefinition(String beanName, BeanDefinition beanDefinition)` 方法，代码如下：
+
+```
+// DefaultListableBeanFactory.java
+
+public void registerBeanDefinition(String beanName, BeanDefinition beanDefinition)
+   throws BeanDefinitionStoreException {
+
+    // ... 省略其他代码
+
+    // 如果未存在
+    } else {
+        // 检测创建 Bean 阶段是否已经开启，如果开启了则需要对 beanDefinitionMap 进行并发控制
+        if (hasBeanCreationStarted()) {
+            // beanDefinitionMap 为全局变量，避免并发情况
+            // Cannot modify startup-time collection elements anymore (for stable iteration)
+            synchronized (this.beanDefinitionMap) {
+                // <x> 添加到 BeanDefinition 到 beanDefinitionMap 中。
+                this.beanDefinitionMap.put(beanName, beanDefinition);
+                // 添加 beanName 到 beanDefinitionNames 中
+                List<String> updatedDefinitions = new ArrayList<>(this.beanDefinitionNames.size() + 1);
+                updatedDefinitions.addAll(this.beanDefinitionNames);
+                updatedDefinitions.add(beanName);
+                this.beanDefinitionNames = updatedDefinitions;
+                // 从 manualSingletonNames 移除 beanName
+                if (this.manualSingletonNames.contains(beanName)) {
+                    Set<String> updatedSingletons = new LinkedHashSet<>(this.manualSingletonNames);
+                    updatedSingletons.remove(beanName);
+                    this.manualSingletonNames = updatedSingletons;
+                }
+            }
+        } else {
+            // Still in startup registration phase
+            // <x> 添加到 BeanDefinition 到 beanDefinitionMap 中。
+            this.beanDefinitionMap.put(beanName, beanDefinition);
+            // 添加 beanName 到 beanDefinitionNames 中
+            this.beanDefinitionNames.add(beanName);
+            // 从 manualSingletonNames 移除 beanName
+            this.manualSingletonNames.remove(beanName);
+        }
+
+        this.frozenBeanDefinitionNames = null;
+    }
+
+    // 重新设置 beanName 对应的缓存
+    if (existingDefinition != null || containsSingleton(beanName)) {
+        resetBeanDefinition(beanName);
+    }
+
+}
+```
+
+- 其实上面一堆代码最重要就只有一句，就是 `<x>` 处：
+
+  ```
+  // DefaultListableBeanFactory.java
+  
+  this.beanDefinitionMap.put(beanName, beanDefinition);
+  ```
+
+## 4.2 removeBeanDefinition
+
+在看看 `#removeBeanDefinition(String beanName)` 方法，其实也是调用 `beanDefinitionMap.remove(beanName)` 的逻辑。
+
+# 5. GenericApplicationContext
+
+对于类 GenericApplicationContext ，查看源码你会发现他实现注册、注销功能都是委托 DefaultListableBeanFactory 实现的。简化代码如下：
+
+```
+// GenericApplicationContext.java
+
+private final DefaultListableBeanFactory beanFactory;
+
+@Override
+public void registerBeanDefinition(String beanName, BeanDefinition beanDefinition)
+		throws BeanDefinitionStoreException {
+
+	this.beanFactory.registerBeanDefinition(beanName, beanDefinition);
+}
+
+@Override
+public void removeBeanDefinition(String beanName) throws NoSuchBeanDefinitionException {
+	this.beanFactory.removeBeanDefinition(beanName);
+}
+
+// ... 省略其它 N 多方法
+```
+
+# 6. 小结
+
+> 所以 BeanDefinition 注册并不是非常高大上的功能，内部就是用一个 Map 实现 ，并不是多么高大上的骚操作，所以有时候我们会潜意识地认为某些技术很高大上就觉得他很深奥，如果试着去一探究竟你会发现，原来这么简单。虽然 BeanDefinitionRegistry 实现简单，但是它作为 Spring IOC 容器的核心接口，其地位还是很重的.
\ No newline at end of file
diff --git a/spring/44-Spring-环境 & 属性：PropertySource、Environment、Profile.assets/0f22156c0d3d902cf4cf196c2b94aaa5.jpeg b/spring/44-Spring-环境 & 属性：PropertySource、Environment、Profile.assets/0f22156c0d3d902cf4cf196c2b94aaa5.jpeg
new file mode 100644
index 0000000..b95144c
Binary files /dev/null and b/spring/44-Spring-环境 & 属性：PropertySource、Environment、Profile.assets/0f22156c0d3d902cf4cf196c2b94aaa5.jpeg differ
diff --git a/spring/44-Spring-环境 & 属性：PropertySource、Environment、Profile.assets/ab5f2dc7cf389534866cc96f1dcf7048.jpeg b/spring/44-Spring-环境 & 属性：PropertySource、Environment、Profile.assets/ab5f2dc7cf389534866cc96f1dcf7048.jpeg
new file mode 100644
index 0000000..94b5ad1
Binary files /dev/null and b/spring/44-Spring-环境 & 属性：PropertySource、Environment、Profile.assets/ab5f2dc7cf389534866cc96f1dcf7048.jpeg differ
diff --git a/spring/44-Spring-环境 & 属性：PropertySource、Environment、Profile.md b/spring/44-Spring-环境 & 属性：PropertySource、Environment、Profile.md
new file mode 100644
index 0000000..37b612c
--- /dev/null
+++ b/spring/44-Spring-环境 & 属性：PropertySource、Environment、Profile.md	
@@ -0,0 +1,662 @@
+# 【死磕 Spring】—— 环境 & 属性：PropertySource、Environment、Profile
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=todo 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+`spring.profiles.active` 和 `@Profile` 这两个我相信各位都熟悉吧，主要功能是可以实现不同环境下（开发、测试、生产）参数配置的切换。其实关于环境的切换，小编在博客 [【死磕Spring】—— IoC 之 PropertyPlaceholderConfigurer 的应用](http://svip.iocoder.cn/Spring/IoC-PropertyPlaceholderConfigurer-demo) 中，已经介绍了利用 PropertyPlaceholderConfigurer 来实现动态切换配置环境，当然这种方法需要我们自己实现，有点儿麻烦。但是对于这种非常实际的需求，Spring 怎么可能没有提供呢？下面小编就问题来对 Spring 的**环境 & 属性**来做一个分析说明。
+
+# 1. 概括
+
+Spring 环境 & 属性由四个部分组成：PropertySource、PropertyResolver、Profile 和 Environment。
+
+- PropertySource：属性**源**，key-value 属性对抽象，用于配置数据。
+- PropertyResolver：属性**解析器**，用于解析属性配置
+- Profile：剖面，只有激活的剖面的组件/配置才会注册到 Spring 容器，类似于 Spring Boot 中的 profile 。
+- Environment：环境，Profile 和 PropertyResolver 的组合。
+
+下面是整个体系的结构图：
+
+[![整体类图](44-Spring-环境 & 属性：PropertySource、Environment、Profile.assets/0f22156c0d3d902cf4cf196c2b94aaa5.jpeg)](http://static.iocoder.cn/0f22156c0d3d902cf4cf196c2b94aaa5)整体类图
+
+下面就针对上面结构图对 Spring 的 Properties & Environment 做一个详细的分析。
+
+# 2. Properties
+
+## 2.1 PropertyResolver
+
+> 属性解析器，用于解析任何基础源的属性的接口
+
+```
+// PropertyResolver.java
+
+public interface PropertyResolver {
+
+    // 是否包含某个属性
+    boolean containsProperty(String key);
+
+    // 获取属性值 如果找不到返回null
+    @Nullable
+    String getProperty(String key);
+    // 获取属性值，如果找不到返回默认值
+    String getProperty(String key, String defaultValue);
+    // 获取指定类型的属性值，找不到返回null
+    @Nullable
+    <T> T getProperty(String key, Class<T> targetType);
+    // 获取指定类型的属性值，找不到返回默认值
+    <T> T getProperty(String key, Class<T> targetType, T defaultValue);
+
+    // 获取属性值，找不到抛出异常IllegalStateException
+    String getRequiredProperty(String key) throws IllegalStateException;
+    // 获取指定类型的属性值，找不到抛出异常IllegalStateException
+    <T> T getRequiredProperty(String key, Class<T> targetType) throws IllegalStateException;
+
+    // 替换文本中的占位符（${key}）到属性值，找不到不解析
+    String resolvePlaceholders(String text);
+    // 替换文本中的占位符（${key}）到属性值，找不到抛出异常IllegalArgumentException
+    String resolveRequiredPlaceholders(String text) throws IllegalArgumentException;
+
+}
+```
+
+从 API 上面我们就知道属性解析器 PropertyResolver 的作用了。下面是一个简单的运用。
+
+```
+PropertyResolver propertyResolver = new PropertySourcesPropertyResolver(propertySources);
+
+System.out.println(propertyResolver.getProperty("name"));
+System.out.println(propertyResolver.getProperty("name", "chenssy"));
+System.out.println(propertyResolver.resolvePlaceholders("my name is  ${name}"));
+```
+
+下图是 PropertyResolver 体系结构图：
+
+[PropertyResolver 体系结构图](https://gitee.com/chenssy/blog-home/raw/master/image/201811/201810241001.png)
+
+- ConfigurablePropertyResolver：供属性类型转换的功能
+- AbstractPropertyResolver：解析属性文件的抽象基类
+- PropertySourcesPropertyResolver：PropertyResolver 的实现者，他对一组 PropertySources 提供属性解析服务
+
+## 2.2 ConfigurablePropertyResolver
+
+> 提供属性类型转换的功能
+
+通俗点说就是 ConfigurablePropertyResolver 提供属性值类型转换所需要的 ConversionService。代码如下：
+
+```
+// ConfigurablePropertyResolver.java
+
+public interface ConfigurablePropertyResolver extends PropertyResolver {
+
+    // 返回执行类型转换时使用的 ConfigurableConversionService
+    ConfigurableConversionService getConversionService();
+    // 设置 ConfigurableConversionService
+    void setConversionService(ConfigurableConversionService conversionService);
+
+    // 设置占位符前缀
+    void setPlaceholderPrefix(String placeholderPrefix);
+    // 设置占位符后缀
+    void setPlaceholderSuffix(String placeholderSuffix);
+    // 设置占位符与默认值之间的分隔符
+    void setValueSeparator(@Nullable String valueSeparator);
+
+    // 设置当遇到嵌套在给定属性值内的不可解析的占位符时是否抛出异常
+    // 当属性值包含不可解析的占位符时，getProperty(String)及其变体的实现必须检查此处设置的值以确定正确的行为。
+    void setIgnoreUnresolvableNestedPlaceholders(boolean ignoreUnresolvableNestedPlaceholders);
+
+    // 指定必须存在哪些属性，以便由validateRequiredProperties（）验证
+    void setRequiredProperties(String... requiredProperties);
+
+    // 验证setRequiredProperties指定的每个属性是否存在并解析为非null值
+    void validateRequiredProperties() throws MissingRequiredPropertiesException;
+
+}
+```
+
+- 从 ConfigurablePropertyResolver 所提供的方法来看，除了访问和设置 ConversionService 外，主要还提供了一些解析规则之类的方法。
+
+就 Properties 体系而言，PropertyResolver 定义了访问 Properties 属性值的方法，而 ConfigurablePropertyResolver 则定义了解析 Properties 一些相关的规则和值进行类型转换所需要的 Service。
+
+该体系有两个实现者：AbstractPropertyResolver 和 PropertySourcesPropertyResolver，其中 AbstractPropertyResolver 为实现的抽象基类，PropertySourcesPropertyResolver 为真正的实现者。
+
+## 2.3 AbstractPropertyResolver
+
+> 解析属性文件的抽象基类
+
+AbstractPropertyResolver 作为基类它仅仅只是设置了一些解析属性文件所需要配置或者转换器，如 `#setConversionService(...)`、`#setPlaceholderPrefix(...)`、`#setValueSeparator(...)` 。其实这些方法的实现都比较简单，都是设置或者获取 AbstractPropertyResolver 所提供的属性，代码如下：
+
+```
+// AbstractPropertyResolver.java
+
+// 类型转换去
+private volatile ConfigurableConversionService conversionService;
+// 占位符
+private PropertyPlaceholderHelper nonStrictHelper;
+//
+private PropertyPlaceholderHelper strictHelper;
+// 设置是否抛出异常
+private boolean ignoreUnresolvableNestedPlaceholders = false;
+// 占位符前缀
+private String placeholderPrefix = SystemPropertyUtils.PLACEHOLDER_PREFIX;
+// 占位符后缀
+private String placeholderSuffix = SystemPropertyUtils.PLACEHOLDER_SUFFIX;
+// 与默认值的分割
+private String valueSeparator = SystemPropertyUtils.VALUE_SEPARATOR;
+// 必须要有的字段值
+private final Set<String> requiredProperties = new LinkedHashSet<>();
+```
+
+这些属性都是 ConfigurablePropertyResolver 接口所提供方法需要的属性，他所提供的方法都是设置和读取这些值，如下几个方法：
+
+```
+// AbstractPropertyResolver.java
+
+public ConfigurableConversionService getConversionService() {
+    // 需要提供独立的DefaultConversionService，而不是PropertySourcesPropertyResolver 使用的共享DefaultConversionService。
+    ConfigurableConversionService cs = this.conversionService;
+    if (cs == null) {
+        synchronized (this) {
+            cs = this.conversionService;
+            if (cs == null) {
+                cs = new DefaultConversionService();
+                this.conversionService = cs;
+            }
+        }
+    }
+    return cs;
+}
+
+@Override
+public void setConversionService(ConfigurableConversionService conversionService) {
+    Assert.notNull(conversionService, "ConversionService must not be null");
+    this.conversionService = conversionService;
+}
+
+public void setPlaceholderPrefix(String placeholderPrefix) {
+    Assert.notNull(placeholderPrefix, "'placeholderPrefix' must not be null");
+    this.placeholderPrefix = placeholderPrefix;
+}
+
+public void setPlaceholderSuffix(String placeholderSuffix) {
+    Assert.notNull(placeholderSuffix, "'placeholderSuffix' must not be null");
+    this.placeholderSuffix = placeholderSuffix;
+}
+```
+
+而对属性的访问，则委托给子类 PropertySourcesPropertyResolver 实现。
+
+```
+// AbstractPropertyResolver.java
+
+public String getProperty(String key) {
+    return getProperty(key, String.class);
+}
+
+public String getProperty(String key, String defaultValue) {
+    String value = getProperty(key);
+    return (value != null ? value : defaultValue);
+}
+
+public <T> T getProperty(String key, Class<T> targetType, T defaultValue) {
+    T value = getProperty(key, targetType);
+    return (value != null ? value : defaultValue);
+}
+
+public String getRequiredProperty(String key) throws IllegalStateException {
+    String value = getProperty(key);
+    if (value == null) {
+        throw new IllegalStateException("Required key '" + key + "' not found");
+    }
+    return value;
+}
+
+public <T> T getRequiredProperty(String key, Class<T> valueType) throws IllegalStateException {
+    T value = getProperty(key, valueType);
+    if (value == null) {
+        throw new IllegalStateException("Required key '" + key + "' not found");
+    }
+    return value;
+}
+```
+
+## 2.4 PropertySourcesPropertyResolver
+
+> PropertyResolver 的实现者，他对一组 PropertySources 提供属性解析服务
+
+它仅有一个成员变量：PropertySources 。该成员变量内部存储着一组 PropertySource，表示 key-value 键值对的源的抽象基类，即一个 PropertySource 对象则是一个 key-value 键值对。PropertySource 的代码如下：
+
+```
+// PropertySource.java
+
+public abstract class PropertySource<T> {
+
+    protected final Log logger = LogFactory.getLog(getClass());
+
+    protected final String name;
+    protected final T source;
+
+    // ...
+
+}
+```
+
+------
+
+PropertySourcesPropertyResolver 对外公开的 `#getProperty(...)` 方法，都是委托给 `#getProperty(String key, Class<T> targetValueType, boolean resolveNestedPlaceholders)` 方法实现，他有三个参数，分别表示为：
+
+- `key` ：获取的 key 。
+- `targetValueType` ： 目标 value 的类型。
+- `resolveNestedPlaceholders` ：是否解决嵌套占位符。
+
+源码如下：
+
+```
+// PropertySourcesPropertyResolver.java
+
+@Nullable
+protected <T> T getProperty(String key, Class<T> targetValueType, boolean resolveNestedPlaceholders) {
+    if (this.propertySources != null) {
+        // 遍历 propertySources 数组
+        for (PropertySource<?> propertySource : this.propertySources) {
+            if (logger.isTraceEnabled()) {
+                logger.trace("Searching for key '" + key + "' in PropertySource '" +
+                        propertySource.getName() + "'");
+            }
+            // 获得 key 对应的 value 值
+            Object value = propertySource.getProperty(key);
+            if (value != null) {
+                // 如果解决嵌套占位符，解析占位符
+                if (resolveNestedPlaceholders && value instanceof String) {
+                    value = resolveNestedPlaceholders((String) value);
+                }
+                // 如果未找到 key 对应的值，则打印日志
+                logKeyFound(key, propertySource, value);
+                // value 的类型转换
+                return convertValueIfNecessary(value, targetValueType);
+            }
+        }
+    }
+    if (logger.isTraceEnabled()) {
+        logger.trace("Could not find key '" + key + "' in any property source");
+    }
+    return null;
+}
+```
+
+- 首先，从 `propertySource` 中，获取指定 `key` 的 `value` 值。
+- 然后，判断是否需要进行嵌套占位符解析，如果需要则调用 `#resolveNestedPlaceholders(String value)` 方法，进行嵌套占位符解析。详细解析，见 [「2.4.1 resolveNestedPlaceholders」](https://svip.iocoder.cn/Spring/PropertySource-and-Environment-and-Profile/#) 。
+- 最后，调用 `#convertValueIfNecessary(Object value, Class<T> targetType)` 方法，进行类型转换。详细解析，见 [「2.4.2 convertValueIfNecessary」](https://svip.iocoder.cn/Spring/PropertySource-and-Environment-and-Profile/#) 。
+
+### 2.4.1 resolveNestedPlaceholders
+
+`#resolveNestedPlaceholders(String value)` 方法，用于解析给定字符串中的占位符，同时根据 `ignoreUnresolvableNestedPlaceholders` 的值，来确定是否对不可解析的占位符的处理方法：是忽略还是抛出异常（该值由 `#setIgnoreUnresolvableNestedPlaceholders(boolean ignoreUnresolvableNestedPlaceholders)` 方法来设置）。代码如下：
+
+```
+// AbstractPropertyResolver.java
+
+protected String resolveNestedPlaceholders(String value) {
+    return (this.ignoreUnresolvableNestedPlaceholders ?
+            resolvePlaceholders(value) : resolveRequiredPlaceholders(value));
+}
+```
+
+- 如果 `this.ignoreUnresolvableNestedPlaceholders` 为 `true` ，则调用 `#resolvePlaceholders(String text)` 方法，否则调用 `#resolveRequiredPlaceholders(String text)` 方法，但是无论是哪个方法，最终都会到 `#doResolvePlaceholders(String text, PropertyPlaceholderHelper helper)` 方法。该方法接收两个参数：
+
+  ```
+  // AbstractPropertyResolver.java
+  
+  // String 类型的 text：待解析的字符串
+  // PropertyPlaceholderHelper 类型的 helper：用于解析占位符的工具类。
+  private String doResolvePlaceholders(String text, PropertyPlaceholderHelper helper) {
+      return helper.replacePlaceholders(text, this::getPropertyAsRawString);
+  }
+  ```
+
+------
+
+PropertyPlaceholderHelper 是用于处理包含占位符值的字符串，构造该实例需要四个参数：
+
+- `placeholderPrefix`：占位符前缀。
+
+- `placeholderSuffix`：占位符后缀。
+
+- `valueSeparator`：占位符变量与关联的默认值之间的分隔符。
+
+- `ignoreUnresolvablePlaceholders`：指示是否忽略不可解析的占位符（`true`）或抛出异常（`false`）。
+
+- 构造函数如下：
+
+  ```
+  // PropertyPlaceholderHelper.java
+  
+  public PropertyPlaceholderHelper(String placeholderPrefix, String placeholderSuffix,
+          @Nullable String valueSeparator, boolean ignoreUnresolvablePlaceholders) {
+  
+      Assert.notNull(placeholderPrefix, "'placeholderPrefix' must not be null");
+      Assert.notNull(placeholderSuffix, "'placeholderSuffix' must not be null");
+      this.placeholderPrefix = placeholderPrefix;
+      this.placeholderSuffix = placeholderSuffix;
+      String simplePrefixForSuffix = wellKnownSimplePrefixes.get(this.placeholderSuffix);
+      if (simplePrefixForSuffix != null && this.placeholderPrefix.endsWith(simplePrefixForSuffix)) {
+          this.simplePrefix = simplePrefixForSuffix;
+      } else {
+          this.simplePrefix = this.placeholderPrefix;
+      }
+      this.valueSeparator = valueSeparator;
+      this.ignoreUnresolvablePlaceholders = ignoreUnresolvablePlaceholders;
+  }
+  ```
+
+就 PropertySourcesPropertyResolver 而言，其父类 AbstractPropertyResolver 已经对上述四个值做了定义：
+
+- `placeholderPrefix` 为 `${` 。
+- `placeholderSuffix` 为 `}` 。
+- `valueSeparator` 为 `:` 。
+- `ignoreUnresolvablePlaceholders` ，默认为 `false` ，当然我们也可以使用相应的 setter 方法自定义。
+
+调用 PropertyPlaceholderHelper 的 `#replacePlaceholders(String value, PlaceholderResolver placeholderResolver)` 方法，对占位符进行处理，该方法接收两个参数，一个是待解析的字符串 `value` ，一个是 PlaceholderResolver 类型的 `placeholderResolver` ，他是定义占位符解析的策略类。代码如下：
+
+```
+// PropertyPlaceholderHelper.java
+
+public String replacePlaceholders(String value, PlaceholderResolver placeholderResolver) {
+    Assert.notNull(value, "'value' must not be null");
+    return parseStringValue(value, placeholderResolver, new HashSet<>());
+}
+
+protected String parseStringValue(String value, PlaceholderResolver placeholderResolver, Set<String> visitedPlaceholders) {
+    StringBuilder result = new StringBuilder(value);
+
+    // 获取前缀 "${" 的索引位置
+    int startIndex = value.indexOf(this.placeholderPrefix);
+    while (startIndex != -1) {
+        // 获取 后缀 "}" 的索引位置
+        int endIndex = findPlaceholderEndIndex(result, startIndex);
+        if (endIndex != -1) {
+            // 截取 "${" 和 "}" 中间的内容，这也就是我们在配置文件中对应的值
+            String placeholder = result.substring(startIndex + this.placeholderPrefix.length(), endIndex);
+            String originalPlaceholder = placeholder;
+            if (!visitedPlaceholders.add(originalPlaceholder)) {
+                throw new IllegalArgumentException(
+                        "Circular placeholder reference '" + originalPlaceholder + "' in property definitions");
+            }
+            // Recursive invocation, parsing placeholders contained in the placeholder key.
+            // 解析占位符键中包含的占位符，真正的值
+            placeholder = parseStringValue(placeholder, placeholderResolver, visitedPlaceholders);
+            // Now obtain the value for the fully resolved key...
+            // 从 Properties 中获取 placeHolder 对应的值 propVal
+            String propVal = placeholderResolver.resolvePlaceholder(placeholder);
+            // 如果不存在
+            if (propVal == null && this.valueSeparator != null) {
+                // 查询 : 的位置
+                int separatorIndex = placeholder.indexOf(this.valueSeparator);
+                // 如果存在 :
+                if (separatorIndex != -1) {
+                    // 获取 : 前面部分 actualPlaceholder
+                    String actualPlaceholder = placeholder.substring(0, separatorIndex);
+                    // 获取 : 后面部分 defaultValue
+                    String defaultValue = placeholder.substring(separatorIndex + this.valueSeparator.length());
+                    // 从 Properties 中获取 actualPlaceholder 对应的值
+                    propVal = placeholderResolver.resolvePlaceholder(actualPlaceholder);
+                    // 如果不存在 则返回 defaultValue
+                    if (propVal == null) {
+                        propVal = defaultValue;
+                    }
+                }
+            }
+            if (propVal != null) {
+                // Recursive invocation, parsing placeholders contained in the
+                // previously resolved placeholder value.
+                propVal = parseStringValue(propVal, placeholderResolver, visitedPlaceholders);
+                result.replace(startIndex, endIndex + this.placeholderSuffix.length(), propVal);
+                if (logger.isTraceEnabled()) {
+                    logger.trace("Resolved placeholder '" + placeholder + "'");
+                }
+                startIndex = result.indexOf(this.placeholderPrefix, startIndex + propVal.length());
+            } else if (this.ignoreUnresolvablePlaceholders) {
+                // Proceed with unprocessed value.
+                // 忽略值
+                startIndex = result.indexOf(this.placeholderPrefix, endIndex + this.placeholderSuffix.length());
+            } else {
+                throw new IllegalArgumentException("Could not resolve placeholder '" +
+                        placeholder + "'" + " in value \"" + value + "\"");
+            }
+            visitedPlaceholders.remove(originalPlaceholder);
+        } else {
+            startIndex = -1;
+        }
+    }
+
+    // 返回propVal，就是替换之后的值
+    return result.toString();
+}
+```
+
+- 其实就是获取占位符 `${}` 中间的值，这里面会涉及到一个递归的过程，因为可能会存在这种情况 `${${name}}`。
+
+## 2.5 convertValueIfNecessary
+
+`#convertValueIfNecessary(Object value, Class<T> targetType)` 方法，是不是感觉到非常的熟悉，该方法就是完成类型转换的。代码如下：
+
+```
+// AbstractPropertyResolver.java
+
+@Nullable
+protected <T> T convertValueIfNecessary(Object value, @Nullable Class<T> targetType) {
+	if (targetType == null) {
+		return (T) value;
+	}
+	ConversionService conversionServiceToUse = this.conversionService;
+	if (conversionServiceToUse == null) {
+		// Avoid initialization of shared DefaultConversionService if
+		// no standard type conversion is needed in the first place...
+		if (ClassUtils.isAssignableValue(targetType, value)) {
+			return (T) value;
+		}
+		conversionServiceToUse = DefaultConversionService.getSharedInstance();
+	}
+	// 执行转换
+	return conversionServiceToUse.convert(value, targetType);
+}
+```
+
+- 首先，获取类型转换服务 `conversionService` 。若为空，则判断是否可以通过反射来设置，如果可以则直接强转返回，否则构造一个 DefaultConversionService 实例。
+- 最后调用其 `#convert(Object source, Class<T> targetType)` 方法，完成类型转换。后续就是 Spring 类型转换体系的事情了，如果对其不了解，可以参考小编这篇博客：[【死磕 Spring】—— IoC 之深入分析 Bean 的类型转换体系](http://svip.iocoder.cn/Spring/IoC-TypeConverter)
+
+# 3. Environment
+
+> 表示当前应用程序正在运行的环境
+
+应用程序的环境有两个关键方面：profile 和 properties。
+
+- properties 的方法由 PropertyResolver 定义。
+- profile 则表示当前的运行环境，对于应用程序中的 properties 而言，并不是所有的都会加载到系统中，只有其属性与 profile 一直才会被激活加载，
+
+所以 Environment 对象的作用，是确定哪些配置文件（如果有）当前处于活动状态，以及默认情况下哪些配置文件（如果有）应处于活动状态。properties 在几乎所有应用程序中都发挥着重要作用，并且有多种来源：属性文件，JVM 系统属性，系统环境变量，JNDI，servlet 上下文参数，ad-hoc 属性对象，映射等。同时它继承 PropertyResolver 接口，所以与属性相关的 Environment 对象其主要是为用户提供方便的服务接口，用于配置属性源和从中属性源中解析属性。
+
+代码如下：
+
+```
+// Environment.java
+
+public interface Environment extends PropertyResolver {
+
+    // 返回此环境下激活的配置文件集
+    String[] getActiveProfiles();
+
+    // 如果未设置激活配置文件，则返回默认的激活的配置文件集
+    String[] getDefaultProfiles();
+
+    boolean acceptsProfiles(String... profiles);
+}
+```
+
+Environment 体系结构图如下：
+
+[![Environment 类图](44-Spring-环境 & 属性：PropertySource、Environment、Profile.assets/ab5f2dc7cf389534866cc96f1dcf7048.jpeg)](http://static.iocoder.cn/ab5f2dc7cf389534866cc96f1dcf7048)Environment 类图
+
+- PropertyResolver：提供属性访问功能
+- Environment：提供访问和判断 profiles 的功能
+- ConfigurableEnvironment：提供设置激活的 profile 和默认的 profile 的功能以及操作 Properties 的工具
+- ConfigurableWebEnvironment：提供配置 Servlet 上下文和 Servlet 参数的功能
+- AbstractEnvironment：实现了 ConfigurableEnvironment 接口，默认属性和存储容器的定义，并且实现了 ConfigurableEnvironment 的方法，并且为子类预留可覆盖了扩展方法
+- StandardEnvironment：继承自 AbstractEnvironment ，非 Servlet(Web) 环境下的标准 Environment 实现
+- StandardServletEnvironment：继承自 StandardEnvironment ，Servlet(Web) 环境下的标准 Environment 实现
+
+## 3.1 ConfigurableEnvironment
+
+> 提供设置激活的 profile 和默认的 profile 的功能以及操作 Properties 的工具
+
+该类除了继承 Environment 接口外还继承了 ConfigurablePropertyResolver 接口，所以它即具备了设置 profile 的功能也具备了操作 Properties 的功能。同时还允许客户端通过它设置和验证所需要的属性，自定义转换服务等功能。如下：
+
+```
+// ConfigurableEnvironment.java
+
+public interface ConfigurableEnvironment extends Environment, ConfigurablePropertyResolver {
+
+    // 指定该环境下的 profile 集
+    void setActiveProfiles(String... profiles);
+    // 增加此环境的 profile
+    void addActiveProfile(String profile);
+    // 设置默认的 profile
+    void setDefaultProfiles(String... profiles);
+
+    // 返回此环境的 PropertySources
+    MutablePropertySources getPropertySources();
+   // 尝试返回 System.getenv() 的值，若失败则返回通过 System.getenv(string) 的来访问各个键的映射
+    Map<String, Object> getSystemEnvironment();
+    // 尝试返回 System.getProperties() 的值，若失败则返回通过 System.getProperties(string) 的来访问各个键的映射
+    Map<String, Object> getSystemProperties();
+
+    void merge(ConfigurableEnvironment parent);
+}
+```
+
+## 3.2 AbstractEnvironment
+
+> Environment 的基础实现
+
+允许通过设置 `ACTIVE_PROFILES_PROPERTY_NAME` 和`DEFAULT_PROFILES_PROPERTY_NAME` 属性指定活动和默认配置文件。子类的主要区别在于它们默认添加的 PropertySource 对象。而 AbstractEnvironment 则没有添加任何内容。
+
+- 子类应该通过受保护的 `#customizePropertySources(MutablePropertySources)` 钩子提供属性源。方法的代码如下：
+
+  ```
+  // AbstractEnvironment.java
+  
+  public AbstractEnvironment() {
+  	customizePropertySources(this.propertySources);
+  }
+  
+  protected void customizePropertySources(MutablePropertySources propertySources) {
+  }
+  ```
+
+- 而客户端应该使用`AbstractEnvironment#getPropertySources()` 方法，进行自定义并对 MutablePropertySources API 进行操作。方法的代码如下：
+
+  ```
+  // AbstractEnvironment.java
+  
+  @Override
+  public MutablePropertySources getPropertySources() {
+  	return this.propertySources;
+  }
+  ```
+
+在 AbstractEnvironment 有两对变量，这两对变量维护着激活和默认配置 profile。如下：
+
+```
+// AbstractEnvironment.java
+
+public static final String ACTIVE_PROFILES_PROPERTY_NAME = "spring.profiles.active";
+private final Set<String> activeProfiles = new LinkedHashSet<>();
+
+public static final String DEFAULT_PROFILES_PROPERTY_NAME = "spring.profiles.default";
+private final Set<String> defaultProfiles = new LinkedHashSet<>(getReservedDefaultProfiles());
+```
+
+- 由于实现方法较多，这里只关注两个方法：`#setActiveProfiles(String... profiles)` 和 `#getActiveProfiles()` 。
+
+### 3.2.1 setActiveProfiles
+
+```
+// AbstractEnvironment.java
+
+@Override
+public void setActiveProfiles(String... profiles) {
+    Assert.notNull(profiles, "Profile array must not be null");
+    if (logger.isDebugEnabled()) {
+        logger.debug("Activating profiles " + Arrays.asList(profiles));
+    }
+    synchronized (this.activeProfiles) {
+        // 清空 activeProfiles
+        this.activeProfiles.clear();
+        // 遍历 profiles 数组，添加到 activeProfiles 中
+        for (String profile : profiles) {
+            // 校验
+            validateProfile(profile);
+            this.activeProfiles.add(profile);
+        }
+    }
+}
+```
+
+- 该方法其实就是操作 `activeProfiles` 集合，在每次设置之前都会将该集合清空重新添加，添加之前调用 `#validateProfile(String profile)` 方法，对添加的 profile 进行校验，如下：
+
+  ```
+  // AbstractEnvironment.java
+  
+  protected void validateProfile(String profile) {
+      if (!StringUtils.hasText(profile)) {
+          throw new IllegalArgumentException("Invalid profile [" + profile + "]: must contain text");
+      }
+      if (profile.charAt(0) == '!') {
+          throw new IllegalArgumentException("Invalid profile [" + profile + "]: must not begin with ! operator");
+      }
+  }
+  ```
+
+  - 这个校验过程比较弱，子类可以提供更加严格的校验规则。
+
+### 3.2.2 getActiveProfile
+
+从 `getActiveProfiles()` 方法，中我们可以猜出这个方法实现的逻辑：获取 `activeProfiles` 集合即可。代码如下：
+
+```
+// AbstractEnvironment.java
+
+public String[] getActiveProfiles() {
+    return StringUtils.toStringArray(doGetActiveProfiles());
+}
+```
+
+- 委托给 `#doGetActiveProfiles()` 方法，代码实现：
+
+  ```
+  // AbstractEnvironment.java
+  
+  protected Set<String> doGetActiveProfiles() {
+      synchronized (this.activeProfiles) {
+          // 如果 activeProfiles 为空，则进行初始化
+          if (this.activeProfiles.isEmpty()) {
+              // 获得 ACTIVE_PROFILES_PROPERTY_NAME 对应的 profiles 属性值
+              String profiles = getProperty(ACTIVE_PROFILES_PROPERTY_NAME);
+              if (StringUtils.hasText(profiles)) {
+                  // 设置到 activeProfiles 中
+                  setActiveProfiles(StringUtils.commaDelimitedListToStringArray(
+                          StringUtils.trimAllWhitespace(profiles)));
+              }
+          }
+          return this.activeProfiles;
+      }
+  }
+  ```
+
+  - 如果 `activeProfiles` 为空，则从 Properties 中获取 `spring.profiles.active` 配置，如果不为空，则调用 `#setActiveProfiles(String... profiles)` 方法，设置 profile，最后返回。
+
+# 4. 小结
+
+到这里整个环境&属性已经分析完毕了，至于在后面他是如何与应用上下文结合的，我们后面分析。
\ No newline at end of file
diff --git a/spring/45-Spring-ApplicationContext 相关接口架构分析.assets/3a0321713096156d42661f2df11a93c2.jpeg b/spring/45-Spring-ApplicationContext 相关接口架构分析.assets/3a0321713096156d42661f2df11a93c2.jpeg
new file mode 100644
index 0000000..7481b76
Binary files /dev/null and b/spring/45-Spring-ApplicationContext 相关接口架构分析.assets/3a0321713096156d42661f2df11a93c2.jpeg differ
diff --git a/spring/45-Spring-ApplicationContext 相关接口架构分析.assets/dde0bf4ae9014ec73c80f4c45045850a.jpeg b/spring/45-Spring-ApplicationContext 相关接口架构分析.assets/dde0bf4ae9014ec73c80f4c45045850a.jpeg
new file mode 100644
index 0000000..5e0e0b7
Binary files /dev/null and b/spring/45-Spring-ApplicationContext 相关接口架构分析.assets/dde0bf4ae9014ec73c80f4c45045850a.jpeg differ
diff --git a/spring/45-Spring-ApplicationContext 相关接口架构分析.md b/spring/45-Spring-ApplicationContext 相关接口架构分析.md
new file mode 100644
index 0000000..0c48261
--- /dev/null
+++ b/spring/45-Spring-ApplicationContext 相关接口架构分析.md	
@@ -0,0 +1,430 @@
+# 【死磕 Spring】—— ApplicationContext 相关接口架构分析
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=todo 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+在前面 40 篇博客中都是基于 BeanFactory 这个容器来进行分析的，BeanFactory 容器有点儿简单，它并不适用于我们生产环境，在生产环境我们通常会选择 ApplicationContext ，相对于大多数人而言，它才是正规军，相比于 BeanFactory 这个杂牌军而言，它由如下几个区别：
+
+1. 继承 MessageSource，提供国际化的标准访问策略。
+2. 继承 ApplicationEventPublisher ，提供强大的事件机制。
+3. 扩展 ResourceLoader，可以用来加载多个 Resource，可以灵活访问不同的资源。
+4. 对 Web 应用的支持。
+
+# 1. ApplicationContext
+
+下图是 ApplicationContext 结构类图：
+
+[![ApplicationContext 结构类图](45-Spring-ApplicationContext 相关接口架构分析.assets/3a0321713096156d42661f2df11a93c2.jpeg)](http://static.iocoder.cn/3a0321713096156d42661f2df11a93c2)ApplicationContext 结构类图
+
+- **BeanFactory**：Spring 管理 Bean 的顶层接口，我们可以认为他是一个简易版的 Spring 容器。ApplicationContext 继承 BeanFactory 的两个子类：HierarchicalBeanFactory 和 ListableBeanFactory。HierarchicalBeanFactory 是一个具有层级关系的 BeanFactory，拥有属性 `parentBeanFactory` 。ListableBeanFactory 实现了枚举方法可以列举出当前 BeanFactory 中所有的 bean 对象而不必根据 name 一个一个的获取。
+- **ApplicationEventPublisher**：用于封装事件发布功能的接口，向事件监听器（Listener）发送事件消息。
+- **ResourceLoader**：Spring 加载资源的顶层接口，用于从一个源加载资源文件。ApplicationContext 继承 ResourceLoader 的子类 ResourcePatternResolver，该接口是将 location 解析为 Resource 对象的策略接口。
+- **MessageSource**：解析 message 的策略接口，用不支撑国际化等功能。
+- **EnvironmentCapable**：用于获取 Environment 的接口。
+
+# 2. ApplicationContext 的子接口
+
+ApplicationContext 有两个直接子类：WebApplicationContext 和 ConfigurableApplicationContext 。
+
+## 2.1 WebApplicationContext
+
+```
+// WebApplicationContext.java
+
+public interface WebApplicationContext extends ApplicationContext {
+
+    ServletContext getServletContext();
+
+}
+```
+
+该接口只有一个 `#getServletContext()` 方法，用于给 Servlet 提供上下文信息。
+
+## 2.2 ConfigurableApplicationContext
+
+```
+// ConfigurableApplicationContext.java
+
+public interface ConfigurableApplicationContext extends ApplicationContext, Lifecycle, Closeable {
+
+    // 为 ApplicationContext 设置唯一 ID
+    void setId(String id);
+
+    // 为 ApplicationContext 设置 parent
+    // 父类不应该被修改：如果创建的对象不可用时，则应该在构造函数外部设置它
+    void setParent(@Nullable ApplicationContext parent);
+
+    // 设置 Environment
+    void setEnvironment(ConfigurableEnvironment environment);
+
+    // 获取 Environment
+    @Override
+    ConfigurableEnvironment getEnvironment();
+
+    // 添加 BeanFactoryPostProcessor
+    void addBeanFactoryPostProcessor(BeanFactoryPostProcessor postProcessor);
+
+    // 添加 ApplicationListener
+    void addApplicationListener(ApplicationListener<?> listener);
+
+    // 添加 ProtocolResolver
+    void addProtocolResolver(ProtocolResolver resolver);
+
+    // 加载或者刷新配置
+    // 这是一个非常重要的方法
+    void refresh() throws BeansException, IllegalStateException;
+
+    // 注册 shutdown hook
+    void registerShutdownHook();
+
+    // 关闭 ApplicationContext
+    @Override
+    void close();
+
+    // ApplicationContext 是否处于激活状态
+    boolean isActive();
+
+    // 获取当前上下文的 BeanFactory
+    ConfigurableListableBeanFactory getBeanFactory() throws IllegalStateException;
+
+}
+```
+
+从上面代码可以看到 ConfigurableApplicationContext 接口提供的方法都是对 ApplicationContext 进行配置的，例如 `#setEnvironment(ConfigurableEnvironment environment)`、`#addBeanFactoryPostProcessor(BeanFactoryPostProcessor postProcessor)`，同时它还继承了如下两个接口：
+
+- Lifecycle：对 context 生命周期的管理，它提供 `#start()` 和 `#stop()` 方法启动和暂停组件。
+- Closeable：标准 JDK 所提供的一个接口，用于最后关闭组件释放资源等。
+
+## 2.3 ConfigurableWebApplicationContext
+
+WebApplicationContext 接口和 ConfigurableApplicationContext 接口有一个共同的子类接口 ConfigurableWebApplicationContext，该接口将这两个接口进行合并，提供了一个可配置、可管理、可关闭的 WebApplicationContext ，同时该接口还增加了 `#setServletContext(ServletContext servletContext)`，`setServletConfig(ServletConfig servletConfig)` 等方法，用于装配 WebApplicationContext 。代码如下：
+
+```
+// ConfigurableWebApplicationContext.java
+
+public interface ConfigurableWebApplicationContext extends WebApplicationContext, ConfigurableApplicationContext {
+
+    void setServletContext(@Nullable ServletContext servletContext);
+
+    void setServletConfig(@Nullable ServletConfig servletConfig);
+    ServletConfig getServletConfig();
+
+    void setNamespace(@Nullable String namespace);
+    String getNamespace();
+
+    void setConfigLocation(String configLocation);
+    void setConfigLocations(String... configLocations);
+    String[] getConfigLocations();
+
+}
+```
+
+上面三个接口就可以构成一个比较完整的 Spring 容器，整个 Spring 容器体系涉及的接口较多，所以下面小编就一个具体的实现类来看看 ApplicationContext 的实现（其实在前面一系列的文章中，小编对涉及的大部分接口都已经分析了其原理），当然不可能每个方法都涉及到，但小编会把其中最为重要的实现方法贴出来分析。ApplicationContext 的实现类较多，**就以 ClassPathXmlApplicationContext 来分析 ApplicationContext**。
+
+# 3. ClassPathXmlApplicationContext
+
+ClassPathXmlApplicationContext 是我们在学习 Spring 过程中用的非常多的一个类，很多人第一个接触的 Spring 容器就是它，包括小编自己，下面代码我想很多人依然还记得吧。
+
+```
+// 示例
+ApplicationContext ac = new ClassPathXmlApplicationContext("applicationContext.xml");
+StudentService studentService = (StudentService)ac.getBean("studentService");
+```
+
+下图是 ClassPathXmlApplicationContext 的结构类图：
+
+[![ClassPathXmlApplicationContext 的类图](45-Spring-ApplicationContext 相关接口架构分析.assets/dde0bf4ae9014ec73c80f4c45045850a.jpeg)](http://static.iocoder.cn/dde0bf4ae9014ec73c80f4c45045850a)ClassPathXmlApplicationContext 的类图
+
+主要的的类层级关系如下：
+
+```
+org.springframework.context.support.AbstractApplicationContext
+      org.springframework.context.support.AbstractRefreshableApplicationContext
+            org.springframework.context.support.AbstractRefreshableConfigApplicationContext
+                  org.springframework.context.support.AbstractXmlApplicationContext
+                        org.springframework.context.support.ClassPathXmlApplicationContext
+```
+
+这种设计是模板方法模式典型的应用，AbstractApplicationContext 实现了 ConfigurableApplicationContext 这个全家桶接口，其子类 AbstractRefreshableConfigApplicationContext 又实现了 BeanNameAware 和 InitializingBean 接口。所以 ClassPathXmlApplicationContext 设计的顶级接口有：
+
+```
+BeanFactory：Spring 容器 Bean 的管理
+MessageSource：管理 message ，实现国际化等功能
+ApplicationEventPublisher：事件发布
+ResourcePatternResolver：资源加载
+EnvironmentCapable：系统 Environment（profile + Properties） 相关
+Lifecycle：管理生命周期
+Closable：关闭，释放资源
+InitializingBean：自定义初始化
+BeanNameAware：设置 beanName 的 Aware 接口
+```
+
+下面就这些接口来一一分析。
+
+## 3.1 MessageSource
+
+MessageSource 定义了获取 message 的策略方法 `#getMessage(...)` 。
+在 ApplicationContext 体系中，该方法由 AbstractApplicationContext 实现。
+在 AbstractApplicationContext 中，它持有一个 MessageSource 实例，将 `#getMessage(...)` 方法委托给该实例来实现，代码如下：
+
+```
+// AbstractApplicationContext.java
+
+private MessageSource messageSource;
+
+// 实现 getMessage()
+public String getMessage(String code, @Nullable Object[] args, @Nullable String defaultMessage, Locale locale) {
+    // 委托给 messageSource 实现
+    return getMessageSource().getMessage(code, args, defaultMessage, locale);
+}
+
+private MessageSource getMessageSource() throws IllegalStateException {
+    if (this.messageSource == null) {
+        throw new IllegalStateException("MessageSource not initialized - " + "call 'refresh' before accessing messages via the context: " + this);
+    }
+    return this.messageSource;
+}
+```
+
+- 真正实现逻辑，是在 AbstractMessageSource 中，代码如下：
+
+  ```
+  // AbstractMessageSource.java
+  
+  public final String getMessage(String code, @Nullable Object[] args, @Nullable String defaultMessage, Locale locale) {
+      String msg = getMessageInternal(code, args, locale);
+      if (msg != null) {
+          return msg;
+      }
+      if (defaultMessage == null) {
+          return getDefaultMessage(code);
+      }
+      return renderDefaultMessage(defaultMessage, args, locale);
+  }
+  ```
+
+  - 具体的实现这里就不分析了，有兴趣的小伙伴可以自己去深入研究。
+
+## 3.2 ApplicationEventPublisher
+
+ApplicationEventPublisher ，用于封装事件发布功能的接口，向事件监听器（Listener）发送事件消息。
+
+该接口提供了一个 `#publishEvent(Object event, ...)` 方法，用于通知在此应用程序中注册的所有的监听器。该方法在 AbstractApplicationContext 中实现。
+
+```
+// AbstractApplicationContext.java
+
+@Override
+public void publishEvent(ApplicationEvent event) {
+    publishEvent(event, null);
+}
+
+@Override
+public void publishEvent(Object event) {
+    publishEvent(event, null);
+}
+
+protected void publishEvent(Object event, @Nullable ResolvableType eventType) {
+    Assert.notNull(event, "Event must not be null");
+
+    // Decorate event as an ApplicationEvent if necessary
+    ApplicationEvent applicationEvent;
+    if (event instanceof ApplicationEvent) {
+        applicationEvent = (ApplicationEvent) event;
+    } else {
+        applicationEvent = new PayloadApplicationEvent<>(this, event);
+        if (eventType == null) {
+            eventType = ((PayloadApplicationEvent) applicationEvent).getResolvableType();
+        }
+    }
+
+    // Multicast right now if possible - or lazily once the multicaster is initialized
+    if (this.earlyApplicationEvents != null) {
+        this.earlyApplicationEvents.add(applicationEvent);
+    } else {
+        getApplicationEventMulticaster().multicastEvent(applicationEvent, eventType);
+    }
+
+    // Publish event via parent context as well...
+    if (this.parent != null) {
+        if (this.parent instanceof AbstractApplicationContext) {
+            ((AbstractApplicationContext) this.parent).publishEvent(event, eventType);
+        } else {
+            this.parent.publishEvent(event);
+        }
+    }
+}
+```
+
+- 如果指定的事件不是 ApplicationEvent，则它将包装在PayloadApplicationEvent 中。
+- 如果存在父级 ApplicationContext ，则同样要将 event 发布给父级 ApplicationContext 。
+
+## 3.3 ResourcePatternResolver
+
+ResourcePatternResolver 接口继承 ResourceLoader 接口，为将 location 解析为 Resource 对象的策略接口。他提供的 `#getResources(String locationPattern)` 方法，在 AbstractApplicationContext 中实现，在 AbstractApplicationContext 中他持有一个 ResourcePatternResolver 的实例对象。代码如下：
+
+```
+// AbstractApplicationContext.java
+
+/** ResourcePatternResolver used by this context. */
+private ResourcePatternResolver resourcePatternResolver;
+
+public Resource[] getResources(String locationPattern) throws IOException {
+    return this.resourcePatternResolver.getResources(locationPattern);
+}
+```
+
+- 如果小伙伴对 Spring 的 ResourceLoader 比较熟悉的话，你会发现最终是在 PathMatchingResourcePatternResolver 中实现，该类是 ResourcePatternResolver 接口的实现者。
+
+## 3.4 EnvironmentCapable
+
+提供当前系统环境 Environment 组件。提供了一个 `#getEnvironment()` 方法，用于返回 Environment 实例对象。该方法在 AbstractApplicationContext 实现。代码如下：
+
+```
+// AbstractApplicationContext.java
+public ConfigurableEnvironment getEnvironment() {
+    if (this.environment == null) {
+        this.environment = createEnvironment();
+    }
+    return this.environment;
+}
+```
+
+- 如果持有的 `environment` 实例对象为空，则调用 `#createEnvironment()` 方法，创建一个。代码如下：
+
+  ```
+  // AbstractApplicationContext.java
+  
+  protected ConfigurableEnvironment createEnvironment() {
+      return new StandardEnvironment();
+  }
+  ```
+
+  - StandardEnvironment 是一个适用于非 WEB 应用的 Environment。
+
+## 3.5 Lifecycle
+
+Lifecycle ，一个用于管理声明周期的接口。
+
+在 AbstractApplicationContext 中存在一个 LifecycleProcessor 类型的实例对象 `lifecycleProcessor` ，AbstractApplicationContext 中关于 Lifecycle 接口的实现都是委托给 `lifecycleProcessor` 实现的。代码如下：
+
+```
+// AbstractApplicationContext.java
+
+/** LifecycleProcessor for managing the lifecycle of beans within this context. */
+@Nullable
+private LifecycleProcessor lifecycleProcessor;
+
+@Override
+public void start() {
+    getLifecycleProcessor().start();
+    publishEvent(new ContextStartedEvent(this));
+}
+
+@Override
+public void stop() {
+    getLifecycleProcessor().stop();
+    publishEvent(new ContextStoppedEvent(this));
+}
+
+@Override
+public boolean isRunning() {
+    return (this.lifecycleProcessor != null && this.lifecycleProcessor.isRunning());
+}
+```
+
+- 在启动、停止的时候会分别发布 ContextStartedEvent 和 ContextStoppedEvent 事件。
+
+## 3.6 Closable
+
+Closable 接口用于关闭和释放资源，提供了 `#close()` 方法，以释放对象所持有的资源。在 ApplicationContext 体系中由AbstractApplicationContext 实现，用于关闭 ApplicationContext 销毁所有 Bean ，此外如果注册有 JVM shutdown hook ，同样要将其移除。代码如下：
+
+```
+// AbstractApplicationContext.java
+
+public void close() {
+    synchronized (this.startupShutdownMonitor) {
+        doClose();
+        // If we registered a JVM shutdown hook, we don't need it anymore now:
+        // We've already explicitly closed the context.
+        if (this.shutdownHook != null) {
+            try {
+                Runtime.getRuntime().removeShutdownHook(this.shutdownHook);
+            } catch (IllegalStateException ex) {
+             // ignore - VM is already shutting down
+            }
+        }
+    }
+}
+```
+
+- 调用 `#doClose()` 方法，发布 ContextClosedEvent 事件，销毁所有 Bean（单例），关闭 BeanFactory 。代码如下：
+
+  ```
+  // AbstractApplicationContext.java
+  
+  protected void doClose() {
+      // ... 省略部分代码
+      try {
+          // Publish shutdown event.
+          publishEvent(new ContextClosedEvent(this));
+      } catch (Throwable ex) {
+          logger.warn("Exception thrown from ApplicationListener handling ContextClosedEvent", ex);
+      }
+  
+      // ... 省略部分代码
+      destroyBeans();
+      closeBeanFactory();
+      onClose();
+  
+      this.active.set(false);
+  
+  }
+  ```
+
+## 3.7 InitializingBean
+
+InitializingBean 为 Bean 提供了初始化方法的方式，它提供的 `#afterPropertiesSet()` 方法，用于执行初始化动作。在 ApplicationContext 体系中，该方法由 AbstractRefreshableConfigApplicationContext 实现，代码如下：
+
+```
+// AbstractRefreshableConfigApplicationContext.java
+public void afterPropertiesSet() {
+    if (!isActive()) {
+        refresh();
+    }
+}
+```
+
+- 执行 `refresh()` 方法，该方法在 AbstractApplicationContext 中执行，执行整个 Spring 容器的初始化过程。**该方法将在下篇文章进行详细分析说明**。
+
+## 3.8 BeanNameAware
+
+BeanNameAware ，设置 Bean Name 的接口。接口在 AbstractRefreshableConfigApplicationContext 中实现。
+
+```
+// AbstractRefreshableConfigApplicationContext.java
+public void setBeanName(String name) {
+    if (!this.setIdCalled) {
+        super.setId(name);
+        setDisplayName("ApplicationContext '" + name + "'");
+    }
+}
+```
+
+# 4. 小结
+
+由于篇幅问题，再加上大部分接口小编都已经在前面文章进行了详细的阐述，所以本文主要是以 Spring Framework 的 ApplicationContext 为中心，对其结构和功能的实现进行了简要的说明。
+
+这里不得不说 Spring 真的是一个非常优秀的框架，具有良好的结构设计和接口抽象，它的每一个接口职能单一，且都是具体功能到各个模块的高度抽象，且几乎每套接口都提供了一个默认的实现（defaultXXX）。
+
+对于 ApplicationContext 体系而言，他继承 Spring 中众多的核心接口，能够为客户端提供一个相对完整的 Spring 容器，接口 ConfigurableApplicationContext 对 ApplicationContext 接口再次进行扩展，提供了生命周期的管理功能。
+抽象类 ApplicationContext 对整套接口提供了大部分的默认实现，将其中“不易变动”的部分进行了封装，通过“组合”的方式将“容易变动”的功能委托给其他类来实现，同时利用模板方法模式将一些方法的实现开放出去由子类实现，从而实现“**对扩展开放，对修改封闭**”的设计原则。
+
+最后我们再来领略下图的风采：
+
+[![ClassPathXmlApplicationContext 的类图](45-Spring-ApplicationContext 相关接口架构分析.assets/dde0bf4ae9014ec73c80f4c45045850a.jpeg)](http://static.iocoder.cn/dde0bf4ae9014ec73c80f4c45045850a)ClassPathXmlApplicationContext 的类图
\ No newline at end of file
diff --git a/spring/46-Spring-深入分析 ApplicationContext 的 refresh().md b/spring/46-Spring-深入分析 ApplicationContext 的 refresh().md
new file mode 100644
index 0000000..68d9fe5
--- /dev/null
+++ b/spring/46-Spring-深入分析 ApplicationContext 的 refresh().md	
@@ -0,0 +1,758 @@
+# 【死磕 Spring】—— 深入分析 ApplicationContext 的 refresh()
+
+**本文主要基于 Spring 5.0.6.RELEASE**
+
+摘要: 原创出处 http://cmsblogs.com/?p=todo 「小明哥」，谢谢！
+
+作为「小明哥」的忠实读者，「老艿艿」略作修改，记录在理解过程中，参考的资料。
+
+------
+
+上篇博客只是对 ApplicationContext 相关的接口做了一个简单的介绍，作为一个高富帅级别的 Spring 容器，它涉及的方法实在是太多了，全部介绍是不可能的，而且大部分功能都已经在前面系列博客中做了详细的介绍，所以这篇博问介绍 ApplicationContext 最重要的方法（小编认为的） ：`#refresh()` 方法。
+
+> 艿艿：我也这么认为，`#refresh()` 方法是关键的关键！
+
+`#refresh()` 方法，是定义在 ConfigurableApplicationContext 类中的，如下：
+
+```
+// ConfigurableApplicationContext.java
+
+/**
+ * Load or refresh the persistent representation of the configuration,
+ * which might an XML file, properties file, or relational database schema.
+ * As this is a startup method, it should destroy already created singletons
+ * if it fails, to avoid dangling resources. In other words, after invocation
+ * of that method, either all or no singletons at all should be instantiated.
+ * @throws BeansException if the bean factory could not be initialized
+ * @throws IllegalStateException if already initialized and multiple refresh
+ * attempts are not supported
+ */
+void refresh() throws BeansException, IllegalStateException;
+```
+
+- 作用就是：**刷新 Spring 的应用上下文**。
+
+其实现是在 AbstractApplicationContext 中实现。如下：
+
+```
+// AbstractApplicationContext.java
+
+@Override
+public void refresh() throws BeansException, IllegalStateException {
+	synchronized (this.startupShutdownMonitor) {
+		// 准备刷新上下文环境
+		prepareRefresh();
+
+		// 创建并初始化 BeanFactory
+		ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();
+
+		// 填充BeanFactory功能
+		prepareBeanFactory(beanFactory);
+
+		try {
+			// 提供子类覆盖的额外处理，即子类处理自定义的BeanFactoryPostProcess
+			postProcessBeanFactory(beanFactory);
+
+			// 激活各种BeanFactory处理器
+			invokeBeanFactoryPostProcessors(beanFactory);
+
+			// 注册拦截Bean创建的Bean处理器，即注册 BeanPostProcessor
+			registerBeanPostProcessors(beanFactory);
+
+			// 初始化上下文中的资源文件，如国际化文件的处理等
+			initMessageSource();
+
+			// 初始化上下文事件广播器
+			initApplicationEventMulticaster();
+
+			// 给子类扩展初始化其他Bean
+			onRefresh();
+
+			// 在所有bean中查找listener bean，然后注册到广播器中
+			registerListeners();
+
+			// 初始化剩下的单例Bean(非延迟加载的)
+			finishBeanFactoryInitialization(beanFactory);
+
+			// 完成刷新过程,通知生命周期处理器lifecycleProcessor刷新过程,同时发出ContextRefreshEvent通知别人
+			finishRefresh();
+		} catch (BeansException ex) {
+			if (logger.isWarnEnabled()) {
+				logger.warn("Exception encountered during context initialization - " +
+						"cancelling refresh attempt: " + ex);
+			}
+
+			//  销毁已经创建的Bean
+			destroyBeans();
+
+			// 重置容器激活标签
+			cancelRefresh(ex);
+
+			// 抛出异常
+			throw ex;
+		} finally {
+			// Reset common introspection caches in Spring's core, since we
+			// might not ever need metadata for singleton beans anymore...
+			resetCommonCaches();
+		}
+	}
+}
+```
+
+这里每一个方法都非常重要，需要一个一个地解释说明。
+
+# 1. prepareRefresh()
+
+> 初始化上下文环境，对系统的环境变量或者系统属性进行准备和校验,如环境变量中必须设置某个值才能运行，否则不能运行，这个时候可以在这里加这个校验，重写 initPropertySources 方法就好了
+
+```
+// AbstractApplicationContext.java
+
+protected void prepareRefresh() {
+   // 设置启动日期
+	this.startupDate = System.currentTimeMillis();
+	// 设置 context 当前状态
+	this.closed.set(false);
+	this.active.set(true);
+
+	if (logger.isInfoEnabled()) {
+		logger.info("Refreshing " + this);
+	}
+
+	// 初始化context environment（上下文环境）中的占位符属性来源
+	initPropertySources();
+
+	// 对属性进行必要的验证
+	getEnvironment().validateRequiredProperties();
+
+	this.earlyApplicationEvents = new LinkedHashSet<>();
+}
+```
+
+该方法主要是做一些准备工作，如：
+
+1. 设置 context 启动时间
+2. 设置 context 的当前状态
+3. 初始化 context environment 中占位符
+4. 对属性进行必要的验证
+
+# 2. obtainFreshBeanFactory()
+
+> 创建并初始化 BeanFactory
+
+```
+// AbstractApplicationContext.java
+
+protected ConfigurableListableBeanFactory obtainFreshBeanFactory() {
+   // 刷新 BeanFactory
+	refreshBeanFactory();
+	// 获取 BeanFactory
+	ConfigurableListableBeanFactory beanFactory = getBeanFactory();
+	if (logger.isDebugEnabled()) {
+		logger.debug("Bean factory for " + getDisplayName() + ": " + beanFactory);
+	}
+	return beanFactory;
+}
+```
+
+核心方法就在 `#refreshBeanFactory()` 方法，该方法的核心任务就是创建 BeanFactory 并对其就行一番初始化。如下：
+
+```
+// AbstractRefreshableApplicationContext.java
+
+@Override
+protected final void refreshBeanFactory() throws BeansException {
+    // 若已有 BeanFactory ，销毁它的 Bean 们，并销毁 BeanFactory
+    if (hasBeanFactory()) {
+        destroyBeans();
+        closeBeanFactory();
+    }
+    try {
+        // 创建 BeanFactory 对象
+        DefaultListableBeanFactory beanFactory = createBeanFactory();
+        // 指定序列化编号
+        beanFactory.setSerializationId(getId());
+        // 定制 BeanFactory 设置相关属性
+        customizeBeanFactory(beanFactory);
+        // 加载 BeanDefinition 们
+        loadBeanDefinitions(beanFactory);
+        // 设置 Context 的 BeanFactory
+        synchronized (this.beanFactoryMonitor) {
+            this.beanFactory = beanFactory;
+        }
+    } catch (IOException ex) {
+        throw new ApplicationContextException("I/O error parsing bean definition source for " + getDisplayName(), ex);
+    }
+}
+```
+
+1. 判断当前容器是否存在一个 BeanFactory，如果存在则对其进行销毁和关闭
+2. 调用 `#createBeanFactory()` 方法，创建一个 BeanFactory 实例，其实就是 DefaultListableBeanFactory 。
+3. 自定义 BeanFactory
+4. 加载 BeanDefinition 。
+5. 将创建好的 bean 工厂的引用交给的 context 来管理
+
+上面 5 个步骤，都是比较简单的，但是有必要讲解下第 4 步：加载 BeanDefinition。如果各位看过 【死磕 Spring】系列的话，在刚刚开始分析源码的时候，小编就是以 `BeanDefinitionReader#loadBeanDefinitions(Resource resource)` 方法，作为入口来分析的，示例如下：
+
+```
+// 示例代码
+
+ClassPathResource resource = new ClassPathResource("bean.xml");
+DefaultListableBeanFactory factory = new DefaultListableBeanFactory();
+XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(factory);
+reader.loadBeanDefinitions(resource);
+```
+
+只不过这段代码的 `BeanDefinitionReader#loadBeanDefinitions(Resource)` 方法，是定义在 BeanDefinitionReader 中，而此处的 `#loadBeanDefinitions(DefaultListableBeanFactory beanFactory)` 则是定义在 AbstractRefreshableApplicationContext 中，如下：
+
+```
+// AbstractRefreshableApplicationContext.java
+
+protected abstract void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws BeansException, IOException
+```
+
+由具体的子类实现，我们以 AbstractXmlApplicationContext 为例，实现如下：
+
+```
+// AbstractXmlApplicationContext.java
+
+@Override
+protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws BeansException, IOException {
+    // Create a new XmlBeanDefinitionReader for the given BeanFactory.
+    // 创建 XmlBeanDefinitionReader 对象
+    XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReader(beanFactory);
+
+    // Configure the bean definition reader with this context's
+    // resource loading environment.
+    // 对 XmlBeanDefinitionReader 进行环境变量的设置
+    beanDefinitionReader.setEnvironment(this.getEnvironment());
+    beanDefinitionReader.setResourceLoader(this);
+    beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this));
+
+    // Allow a subclass to provide custom initialization of the reader,
+    // then proceed with actually loading the bean definitions.
+    // 对 XmlBeanDefinitionReader 进行设置，可以进行覆盖
+    initBeanDefinitionReader(beanDefinitionReader);
+
+    // 从 Resource 们中，加载 BeanDefinition 们
+    loadBeanDefinitions(beanDefinitionReader);
+}
+```
+
+- 新建 XmlBeanDefinitionReader 实例对象 beanDefinitionReader，调用 `initBeanDefinitionReader()` 对其进行初始化，然后调用 `loadBeanDefinitions()` 加载 BeanDefinition。代码如下：
+
+  ```
+  // AbstractXmlApplicationContext.java
+  
+  protected void loadBeanDefinitions(XmlBeanDefinitionReader reader) throws BeansException, IOException {
+      // 从配置文件 Resource 中，加载 BeanDefinition 们
+      Resource[] configResources = getConfigResources();
+      if (configResources != null) {
+          reader.loadBeanDefinitions(configResources);
+      }
+      // 从配置文件地址中，加载 BeanDefinition 们
+      String[] configLocations = getConfigLocations();
+      if (configLocations != null) {
+          reader.loadBeanDefinitions(configLocations);
+      }
+  }
+  ```
+
+  - 到这里我们发现，其实内部依然是调用 `BeanDefinitionReader#loadBeanDefinitionn()` 进行 BeanDefinition 的加载进程。
+
+# 3. prepareBeanFactory(beanFactory)
+
+> 填充 BeanFactory 功能
+
+上面获取获取的 BeanFactory 除了加载了一些 BeanDefinition 就没有其他任何东西了，这个时候其实还不能投入生产，因为还少配置了一些东西，比如 context的 ClassLoader 和 后置处理器等等。
+
+```
+// AbstractApplicationContext.java
+
+protected void prepareBeanFactory(ConfigurableListableBeanFactory beanFactory) {
+	// 设置beanFactory的classLoader
+	beanFactory.setBeanClassLoader(getClassLoader());
+
+	// 设置beanFactory的表达式语言处理器,Spring3开始增加了对语言表达式的支持,默认可以使用#{bean.xxx}的形式来调用相关属性值
+	beanFactory.setBeanExpressionResolver(new StandardBeanExpressionResolver(beanFactory.getBeanClassLoader()));
+	// 为beanFactory增加一个默认的propertyEditor
+	beanFactory.addPropertyEditorRegistrar(new ResourceEditorRegistrar(this, getEnvironment()));
+
+	// 添加ApplicationContextAwareProcessor
+	beanFactory.addBeanPostProcessor(new ApplicationContextAwareProcessor(this));
+	// 设置忽略自动装配的接口
+    beanFactory.ignoreDependencyInterface(EnvironmentAware.class);
+	beanFactory.ignoreDependencyInterface(EmbeddedValueResolverAware.class);
+	beanFactory.ignoreDependencyInterface(ResourceLoaderAware.class);
+	beanFactory.ignoreDependencyInterface(ApplicationEventPublisherAware.class);
+	beanFactory.ignoreDependencyInterface(MessageSourceAware.class);
+	beanFactory.ignoreDependencyInterface(ApplicationContextAware.class);
+
+	// 设置几个自动装配的特殊规则
+	beanFactory.registerResolvableDependency(BeanFactory.class, beanFactory);
+	beanFactory.registerResolvableDependency(ResourceLoader.class, this);
+	beanFactory.registerResolvableDependency(ApplicationEventPublisher.class, this);
+	beanFactory.registerResolvableDependency(ApplicationContext.class, this);
+
+	// Register early post-processor for detecting inner beans as ApplicationListeners.
+	beanFactory.addBeanPostProcessor(new ApplicationListenerDetector(this));
+
+	// 增加对AspectJ的支持
+	if (beanFactory.containsBean(LOAD_TIME_WEAVER_BEAN_NAME)) {
+		beanFactory.addBeanPostProcessor(new LoadTimeWeaverAwareProcessor(beanFactory));
+		// Set a temporary ClassLoader for type matching.
+		beanFactory.setTempClassLoader(new ContextTypeMatchClassLoader(beanFactory.getBeanClassLoader()));
+	}
+
+	// 注册默认的系统环境bean
+	if (!beanFactory.containsLocalBean(ENVIRONMENT_BEAN_NAME)) {
+		beanFactory.registerSingleton(ENVIRONMENT_BEAN_NAME, getEnvironment());
+	}
+	if (!beanFactory.containsLocalBean(SYSTEM_PROPERTIES_BEAN_NAME)) {
+		beanFactory.registerSingleton(SYSTEM_PROPERTIES_BEAN_NAME, getEnvironment().getSystemProperties());
+	}
+	if (!beanFactory.containsLocalBean(SYSTEM_ENVIRONMENT_BEAN_NAME)) {
+		beanFactory.registerSingleton(SYSTEM_ENVIRONMENT_BEAN_NAME, getEnvironment().getSystemEnvironment());
+	}
+}
+```
+
+看上面的源码知道这个就是对 BeanFactory 设置各种各种的功能。
+
+# 4. postProcessBeanFactory()
+
+> 提供子类覆盖的额外处理，即子类处理自定义的BeanFactoryPostProcess
+
+```
+// AbstractApplicationContext.java
+
+protected void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) {
+	beanFactory.addBeanPostProcessor(new ServletContextAwareProcessor(this.servletContext, this.servletConfig));
+	beanFactory.ignoreDependencyInterface(ServletContextAware.class);
+	beanFactory.ignoreDependencyInterface(ServletConfigAware.class);
+
+	WebApplicationContextUtils.registerWebApplicationScopes(beanFactory, this.servletContext);
+	WebApplicationContextUtils.registerEnvironmentBeans(beanFactory, this.servletContext, this.servletConfig);
+}
+```
+
+1. 添加 ServletContextAwareProcessor 到 BeanFactory 容器中，该 processor 实现 BeanPostProcessor 接口，主要用于将ServletContext 传递给实现了 ServletContextAware 接口的 bean
+2. 忽略 ServletContextAware、ServletConfigAware
+3. 注册 WEB 应用特定的域（scope）到 beanFactory 中，以便 WebApplicationContext 可以使用它们。比如 “request” , “session” , “globalSession” , “application”
+4. 注册 WEB 应用特定的 Environment bean 到 beanFactory 中，以便WebApplicationContext 可以使用它们。如：”contextParameters”, “contextAttributes”
+
+# 5. invokeBeanFactoryPostProcessors()
+
+> 激活各种BeanFactory处理器
+
+```
+// AbstractApplicationContext.java
+
+public static void invokeBeanFactoryPostProcessors(
+		ConfigurableListableBeanFactory beanFactory, List<BeanFactoryPostProcessor> beanFactoryPostProcessors) {
+
+	// 定义一个 set 保存所有的 BeanFactoryPostProcessors
+	Set<String> processedBeans = new HashSet<>();
+
+	// 如果当前 BeanFactory 为 BeanDefinitionRegistry
+	if (beanFactory instanceof BeanDefinitionRegistry) {
+		BeanDefinitionRegistry registry = (BeanDefinitionRegistry) beanFactory;
+		// BeanFactoryPostProcessor 集合
+		List<BeanFactoryPostProcessor> regularPostProcessors = new ArrayList<>();
+		// BeanDefinitionRegistryPostProcessor 集合
+		List<BeanDefinitionRegistryPostProcessor> registryProcessors = new ArrayList<>();
+
+		// 迭代注册的 beanFactoryPostProcessors
+		for (BeanFactoryPostProcessor postProcessor : beanFactoryPostProcessors) {
+			// 如果是 BeanDefinitionRegistryPostProcessor，则调用 postProcessBeanDefinitionRegistry 进行注册，
+			// 同时加入到 registryProcessors 集合中
+			if (postProcessor instanceof BeanDefinitionRegistryPostProcessor) {
+				BeanDefinitionRegistryPostProcessor registryProcessor =
+						(BeanDefinitionRegistryPostProcessor) postProcessor;
+				registryProcessor.postProcessBeanDefinitionRegistry(registry);
+				registryProcessors.add(registryProcessor);
+			}
+			else {
+				// 否则当做普通的 BeanFactoryPostProcessor 处理
+				// 添加到 regularPostProcessors 集合中即可，便于后面做后续处理
+				regularPostProcessors.add(postProcessor);
+			}
+		}
+
+		// 用于保存当前处理的 BeanDefinitionRegistryPostProcessor
+		List<BeanDefinitionRegistryPostProcessor> currentRegistryProcessors = new ArrayList<>();
+
+		// 首先处理实现了 PriorityOrdered (有限排序接口)的 BeanDefinitionRegistryPostProcessor
+		String[] postProcessorNames =
+				beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false);
+		for (String ppName : postProcessorNames) {
+			if (beanFactory.isTypeMatch(ppName, PriorityOrdered.class)) {
+				currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));
+				processedBeans.add(ppName);
+			}
+		}
+
+		// 排序
+		sortPostProcessors(currentRegistryProcessors, beanFactory);
+
+		// 加入registryProcessors集合
+		registryProcessors.addAll(currentRegistryProcessors);
+
+		// 调用所有实现了 PriorityOrdered 的 BeanDefinitionRegistryPostProcessors 的 postProcessBeanDefinitionRegistry()
+		invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry);
+
+		// 清空，以备下次使用
+		currentRegistryProcessors.clear();
+
+		// 其次，调用是实现了 Ordered（普通排序接口）的 BeanDefinitionRegistryPostProcessors
+		// 逻辑和 上面一样
+		postProcessorNames = beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false);
+		for (String ppName : postProcessorNames) {
+			if (!processedBeans.contains(ppName) && beanFactory.isTypeMatch(ppName, Ordered.class)) {
+				currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));
+				processedBeans.add(ppName);
+			}
+		}
+		sortPostProcessors(currentRegistryProcessors, beanFactory);
+		registryProcessors.addAll(currentRegistryProcessors);
+		invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry);
+		currentRegistryProcessors.clear();
+
+		// 最后调用其他的 BeanDefinitionRegistryPostProcessors
+		boolean reiterate = true;
+		while (reiterate) {
+			reiterate = false;
+			// 获取 BeanDefinitionRegistryPostProcessor
+			postProcessorNames = beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false);
+			for (String ppName : postProcessorNames) {
+
+				// 没有包含在 processedBeans 中的（因为包含了的都已经处理了）
+				if (!processedBeans.contains(ppName)) {
+					currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));
+					processedBeans.add(ppName);
+					reiterate = true;
+				}
+			}
+
+			// 与上面处理逻辑一致
+			sortPostProcessors(currentRegistryProcessors, beanFactory);
+			registryProcessors.addAll(currentRegistryProcessors);
+			invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry);
+			currentRegistryProcessors.clear();
+		}
+
+		// 调用所有 BeanDefinitionRegistryPostProcessor (包括手动注册和通过配置文件注册)
+		// 和 BeanFactoryPostProcessor(只有手动注册)的回调函数(postProcessBeanFactory())
+		invokeBeanFactoryPostProcessors(registryProcessors, beanFactory);
+		invokeBeanFactoryPostProcessors(regularPostProcessors, beanFactory);
+	}
+
+	else {
+		// 如果不是 BeanDefinitionRegistry 只需要调用其回调函数（postProcessBeanFactory()）即可
+		invokeBeanFactoryPostProcessors(beanFactoryPostProcessors, beanFactory);
+	}
+
+	//
+	String[] postProcessorNames =
+			beanFactory.getBeanNamesForType(BeanFactoryPostProcessor.class, true, false);
+
+	// 这里同样需要区分 PriorityOrdered 、Ordered 和 no Ordered
+	List<BeanFactoryPostProcessor> priorityOrderedPostProcessors = new ArrayList<>();
+	List<String> orderedPostProcessorNames = new ArrayList<>();
+	List<String> nonOrderedPostProcessorNames = new ArrayList<>();
+	for (String ppName : postProcessorNames) {
+		// 已经处理过了的，跳过
+		if (processedBeans.contains(ppName)) {
+			// skip - already processed in first phase above
+		}
+		// PriorityOrdered
+		else if (beanFactory.isTypeMatch(ppName, PriorityOrdered.class)) {
+			priorityOrderedPostProcessors.add(beanFactory.getBean(ppName, BeanFactoryPostProcessor.class));
+		}
+		// Ordered
+		else if (beanFactory.isTypeMatch(ppName, Ordered.class)) {
+			orderedPostProcessorNames.add(ppName);
+		}
+		// no Ordered
+		else {
+			nonOrderedPostProcessorNames.add(ppName);
+		}
+	}
+
+	// First, PriorityOrdered 接口
+	sortPostProcessors(priorityOrderedPostProcessors, beanFactory);
+	invokeBeanFactoryPostProcessors(priorityOrderedPostProcessors, beanFactory);
+
+	// Next, Ordered 接口
+	List<BeanFactoryPostProcessor> orderedPostProcessors = new ArrayList<>();
+	for (String postProcessorName : orderedPostProcessorNames) {
+		orderedPostProcessors.add(beanFactory.getBean(postProcessorName, BeanFactoryPostProcessor.class));
+	}
+	sortPostProcessors(orderedPostProcessors, beanFactory);
+	invokeBeanFactoryPostProcessors(orderedPostProcessors, beanFactory);
+
+	// Finally, no ordered
+	List<BeanFactoryPostProcessor> nonOrderedPostProcessors = new ArrayList<>();
+	for (String postProcessorName : nonOrderedPostProcessorNames) {
+		nonOrderedPostProcessors.add(beanFactory.getBean(postProcessorName, BeanFactoryPostProcessor.class));
+	}
+	invokeBeanFactoryPostProcessors(nonOrderedPostProcessors, beanFactory);
+
+	// Clear cached merged bean definitions since the post-processors might have
+	// modified the original metadata, e.g. replacing placeholders in values...
+	beanFactory.clearMetadataCache();
+}
+```
+
+上述代码较长，但是处理逻辑较为单一，就是对所有的 BeanDefinitionRegistryPostProcessors 、手动注册的 BeanFactoryPostProcessor 以及通过配置文件方式的 BeanFactoryPostProcessor 按照 PriorityOrdered 、 Ordered、no ordered 三种方式分开处理、调用。
+
+# 6. registerBeanPostProcessors
+
+> 注册拦截Bean创建的Bean处理器，即注册 BeanPostProcessor
+
+与 BeanFactoryPostProcessor 一样，也是委托给 PostProcessorRegistrationDelegate 来实现的。
+
+```
+// AbstractApplicationContext.java
+
+public static void registerBeanPostProcessors(
+		ConfigurableListableBeanFactory beanFactory, AbstractApplicationContext applicationContext) {
+
+	// 所有的 BeanPostProcessors
+	String[] postProcessorNames = beanFactory.getBeanNamesForType(BeanPostProcessor.class, true, false);
+
+	// 注册 BeanPostProcessorChecker
+	// 主要用于记录一些 bean 的信息，这些 bean 不符合所有 BeanPostProcessors 处理的资格时
+	int beanProcessorTargetCount = beanFactory.getBeanPostProcessorCount() + 1 + postProcessorNames.length;
+	beanFactory.addBeanPostProcessor(new BeanPostProcessorChecker(beanFactory, beanProcessorTargetCount));
+
+	// 区分 PriorityOrdered、Ordered 、 no ordered
+	List<BeanPostProcessor> priorityOrderedPostProcessors = new ArrayList<>();
+	List<String> orderedPostProcessorNames = new ArrayList<>();
+	List<String> nonOrderedPostProcessorNames = new ArrayList<>();
+	// MergedBeanDefinition
+	List<BeanPostProcessor> internalPostProcessors = new ArrayList<>();
+	for (String ppName : postProcessorNames) {
+		if (beanFactory.isTypeMatch(ppName, PriorityOrdered.class)) {
+			BeanPostProcessor pp = beanFactory.getBean(ppName, BeanPostProcessor.class);
+			priorityOrderedPostProcessors.add(pp);
+			if (pp instanceof MergedBeanDefinitionPostProcessor) {
+				internalPostProcessors.add(pp);
+			}
+		}
+		else if (beanFactory.isTypeMatch(ppName, Ordered.class)) {
+			orderedPostProcessorNames.add(ppName);
+		}
+		else {
+			nonOrderedPostProcessorNames.add(ppName);
+		}
+	}
+
+	// First, PriorityOrdered
+	sortPostProcessors(priorityOrderedPostProcessors, beanFactory);
+	registerBeanPostProcessors(beanFactory, priorityOrderedPostProcessors);
+
+	// Next, Ordered
+	List<BeanPostProcessor> orderedPostProcessors = new ArrayList<>();
+	for (String ppName : orderedPostProcessorNames) {
+		BeanPostProcessor pp = beanFactory.getBean(ppName, BeanPostProcessor.class);
+		orderedPostProcessors.add(pp);
+		if (pp instanceof MergedBeanDefinitionPostProcessor) {
+			internalPostProcessors.add(pp);
+		}
+	}
+	sortPostProcessors(orderedPostProcessors, beanFactory);
+	registerBeanPostProcessors(beanFactory, orderedPostProcessors);
+
+	// onOrdered
+	List<BeanPostProcessor> nonOrderedPostProcessors = new ArrayList<>();
+	for (String ppName : nonOrderedPostProcessorNames) {
+		BeanPostProcessor pp = beanFactory.getBean(ppName, BeanPostProcessor.class);
+		nonOrderedPostProcessors.add(pp);
+		if (pp instanceof MergedBeanDefinitionPostProcessor) {
+			internalPostProcessors.add(pp);
+		}
+	}
+	registerBeanPostProcessors(beanFactory, nonOrderedPostProcessors);
+
+	// Finally, all internal BeanPostProcessors.
+	sortPostProcessors(internalPostProcessors, beanFactory);
+	registerBeanPostProcessors(beanFactory, internalPostProcessors);
+
+	// 重新注册用来自动探测内部ApplicationListener的post-processor，这样可以将他们移到处理器链条的末尾
+	beanFactory.addBeanPostProcessor(new ApplicationListenerDetector(applicationContext));
+}
+```
+
+# 7. initMessageSource
+
+> 初始化上下文中的资源文件，如国际化文件的处理等
+
+其实该方法就是初始化一个 MessageSource 接口的实现类，主要用于国际化/i18n。
+
+```
+// AbstractApplicationContext.java
+
+protected void initMessageSource() {
+	ConfigurableListableBeanFactory beanFactory = getBeanFactory();
+	// 包含 “messageSource” bean
+	if (beanFactory.containsLocalBean(MESSAGE_SOURCE_BEAN_NAME)) {
+		this.messageSource = beanFactory.getBean(MESSAGE_SOURCE_BEAN_NAME, MessageSource.class);
+		// 如果有父类
+		// HierarchicalMessageSource 分级处理的 MessageSource
+		if (this.parent != null && this.messageSource instanceof HierarchicalMessageSource) {
+			HierarchicalMessageSource hms = (HierarchicalMessageSource) this.messageSource;
+			if (hms.getParentMessageSource() == null) {
+				// 如果没有注册父 MessageSource，则设置为父类上下文的的 MessageSource
+				hms.setParentMessageSource(getInternalParentMessageSource());
+			}
+		}
+		if (logger.isDebugEnabled()) {
+			logger.debug("Using MessageSource [" + this.messageSource + "]");
+		}
+	}
+	else {
+		// 使用 空 MessageSource
+		DelegatingMessageSource dms = new DelegatingMessageSource();
+		dms.setParentMessageSource(getInternalParentMessageSource());
+		this.messageSource = dms;
+		beanFactory.registerSingleton(MESSAGE_SOURCE_BEAN_NAME, this.messageSource);
+		if (logger.isDebugEnabled()) {
+			logger.debug("Unable to locate MessageSource with name '" + MESSAGE_SOURCE_BEAN_NAME +
+					"': using default [" + this.messageSource + "]");
+		}
+	}
+}
+```
+
+# 8. initApplicationEventMulticaster
+
+> 初始化上下文事件广播器
+
+```
+// AbstractApplicationContext.java
+
+protected void initApplicationEventMulticaster() {
+	ConfigurableListableBeanFactory beanFactory = getBeanFactory();
+
+	// 如果存在 applicationEventMulticaster bean，则获取赋值
+	if (beanFactory.containsLocalBean(APPLICATION_EVENT_MULTICASTER_BEAN_NAME)) {
+		this.applicationEventMulticaster =
+				beanFactory.getBean(APPLICATION_EVENT_MULTICASTER_BEAN_NAME, ApplicationEventMulticaster.class);
+		if (logger.isDebugEnabled()) {
+			logger.debug("Using ApplicationEventMulticaster [" + this.applicationEventMulticaster + "]");
+		}
+	}
+	else {
+		// 没有则新建 SimpleApplicationEventMulticaster，并完成 bean 的注册
+		this.applicationEventMulticaster = new SimpleApplicationEventMulticaster(beanFactory);
+		beanFactory.registerSingleton(APPLICATION_EVENT_MULTICASTER_BEAN_NAME, this.applicationEventMulticaster);
+		if (logger.isDebugEnabled()) {
+			logger.debug("Unable to locate ApplicationEventMulticaster with name '" +
+					APPLICATION_EVENT_MULTICASTER_BEAN_NAME +
+					"': using default [" + this.applicationEventMulticaster + "]");
+		}
+	}
+}
+```
+
+如果当前容器中存在 applicationEventMulticaster 的 bean，则对 applicationEventMulticaster 赋值，否则新建一个 SimpleApplicationEventMulticaster 的对象（默认的），并完成注册。
+
+# 9. onRefresh
+
+> 给子类扩展初始化其他Bean
+
+预留给 AbstractApplicationContext 的子类用于初始化其他特殊的 bean，该方法需要在所有单例 bean 初始化之前调用。
+
+# 10. registerListeners
+
+> 在所有 bean 中查找 listener bean，然后注册到广播器中
+
+```
+// AbstractApplicationContext.java
+
+protected void registerListeners() {
+	// 注册静态 监听器
+	for (ApplicationListener<?> listener : getApplicationListeners()) {
+		getApplicationEventMulticaster().addApplicationListener(listener);
+	}
+
+	String[] listenerBeanNames = getBeanNamesForType(ApplicationListener.class, true, false);
+	for (String listenerBeanName : listenerBeanNames) {
+		getApplicationEventMulticaster().addApplicationListenerBean(listenerBeanName);
+	}
+
+	// 至此，已经完成将监听器注册到ApplicationEventMulticaster中，下面将发布前期的事件给监听器。
+	Set<ApplicationEvent> earlyEventsToProcess = this.earlyApplicationEvents;
+	this.earlyApplicationEvents = null;
+	if (earlyEventsToProcess != null) {
+		for (ApplicationEvent earlyEvent : earlyEventsToProcess) {
+			getApplicationEventMulticaster().multicastEvent(earlyEvent);
+		}
+	}
+}
+```
+
+# 10. finishBeanFactoryInitialization
+
+> 初始化剩下的单例Bean(非延迟加载的)
+
+```
+// AbstractApplicationContext.java
+
+protected void finishBeanFactoryInitialization(ConfigurableListableBeanFactory beanFactory) {
+	// 初始化转换器
+	if (beanFactory.containsBean(CONVERSION_SERVICE_BEAN_NAME) &&
+			beanFactory.isTypeMatch(CONVERSION_SERVICE_BEAN_NAME, ConversionService.class)) {
+		beanFactory.setConversionService(
+				beanFactory.getBean(CONVERSION_SERVICE_BEAN_NAME, ConversionService.class));
+	}
+
+	// 如果之前没有注册 bean 后置处理器（例如PropertyPlaceholderConfigurer），则注册默认的解析器
+	if (!beanFactory.hasEmbeddedValueResolver()) {
+		beanFactory.addEmbeddedValueResolver(strVal -> getEnvironment().resolvePlaceholders(strVal));
+	}
+
+	// 初始化 Initialize LoadTimeWeaverAware beans early to allow for registering their transformers early.
+	String[] weaverAwareNames = beanFactory.getBeanNamesForType(LoadTimeWeaverAware.class, false, false);
+	for (String weaverAwareName : weaverAwareNames) {
+		getBean(weaverAwareName);
+	}
+
+	// 停止使用临时的 ClassLoader
+	beanFactory.setTempClassLoader(null);
+
+	//
+	beanFactory.freezeConfiguration();
+
+	// 初始化所有剩余的单例（非延迟初始化）
+	beanFactory.preInstantiateSingletons();
+}
+```
+
+# 11. finishRefresh
+
+> 完成刷新过程,通知生命周期处理器 lifecycleProcessor 刷新过程,同时发出 ContextRefreshEvent 通知别人
+
+主要是调用 `LifecycleProcessor#onRefresh()` ，并且发布事件（ContextRefreshedEvent）。
+
+```
+// AbstractApplicationContext.java
+	
+protected void finishRefresh() {
+	// Clear context-level resource caches (such as ASM metadata from scanning).
+	clearResourceCaches();
+
+	// Initialize lifecycle processor for this context.
+	initLifecycleProcessor();
+
+	// Propagate refresh to lifecycle processor first.
+	getLifecycleProcessor().onRefresh();
+
+	// Publish the final event.
+	publishEvent(new ContextRefreshedEvent(this));
+
+	// Participate in LiveBeansView MBean, if active.
+	LiveBeansView.registerApplicationContext(this);
+}
+```
\ No newline at end of file
diff --git a/spring/47-Spring-4 张图带你读懂 Spring IoC 的世界.assets/365d4142eb23822dcaddba6d1f59ccbc.jpeg b/spring/47-Spring-4 张图带你读懂 Spring IoC 的世界.assets/365d4142eb23822dcaddba6d1f59ccbc.jpeg
new file mode 100644
index 0000000..66da104
Binary files /dev/null and b/spring/47-Spring-4 张图带你读懂 Spring IoC 的世界.assets/365d4142eb23822dcaddba6d1f59ccbc.jpeg differ
diff --git a/spring/47-Spring-4 张图带你读懂 Spring IoC 的世界.assets/38419d23d29c83a4758f73f85281e076.png b/spring/47-Spring-4 张图带你读懂 Spring IoC 的世界.assets/38419d23d29c83a4758f73f85281e076.png
new file mode 100644
index 0000000..7cb9a11
Binary files /dev/null and b/spring/47-Spring-4 张图带你读懂 Spring IoC 的世界.assets/38419d23d29c83a4758f73f85281e076.png differ
diff --git a/spring/47-Spring-4 张图带你读懂 Spring IoC 的世界.assets/3a5b28a2d3bd435ca94ea5c8752609d5.png b/spring/47-Spring-4 张图带你读懂 Spring IoC 的世界.assets/3a5b28a2d3bd435ca94ea5c8752609d5.png
new file mode 100644
index 0000000..e731bd0
Binary files /dev/null and b/spring/47-Spring-4 张图带你读懂 Spring IoC 的世界.assets/3a5b28a2d3bd435ca94ea5c8752609d5.png differ
diff --git a/spring/47-Spring-4 张图带你读懂 Spring IoC 的世界.assets/dde0bf4ae9014ec73c80f4c45045850a.jpeg b/spring/47-Spring-4 张图带你读懂 Spring IoC 的世界.assets/dde0bf4ae9014ec73c80f4c45045850a.jpeg
new file mode 100644
index 0000000..5e0e0b7
Binary files /dev/null and b/spring/47-Spring-4 张图带你读懂 Spring IoC 的世界.assets/dde0bf4ae9014ec73c80f4c45045850a.jpeg differ
diff --git a/spring/47-Spring-4 张图带你读懂 Spring IoC 的世界.md b/spring/47-Spring-4 张图带你读懂 Spring IoC 的世界.md
new file mode 100644
index 0000000..2590606
--- /dev/null
+++ b/spring/47-Spring-4 张图带你读懂 Spring IoC 的世界.md	
@@ -0,0 +1,19 @@
+# 【死磕 Spring】—— 4 张图带你读懂 Spring IoC 的世界
+
+# 1. Bean 的转换过程
+
+下面这张图演示了一个可用的 bean 是如何从 xml 配置文件中演变过来的。
+
+[![img](47-Spring-4 张图带你读懂 Spring IoC 的世界.assets/365d4142eb23822dcaddba6d1f59ccbc.jpeg)](http://static.iocoder.cn/365d4142eb23822dcaddba6d1f59ccbc)
+
+# 2. ApplicationContext 的架构图
+
+[![img](47-Spring-4 张图带你读懂 Spring IoC 的世界.assets/dde0bf4ae9014ec73c80f4c45045850a.jpeg)](http://static.iocoder.cn/dde0bf4ae9014ec73c80f4c45045850a)
+
+# 3. load BeanDefinition 的全流程
+
+[![img](47-Spring-4 张图带你读懂 Spring IoC 的世界.assets/38419d23d29c83a4758f73f85281e076.png)](http://static.iocoder.cn/38419d23d29c83a4758f73f85281e076)
+
+# 4. get Bean 的全流程
+
+[![img](47-Spring-4 张图带你读懂 Spring IoC 的世界.assets/3a5b28a2d3bd435ca94ea5c8752609d5.png)](http://static.iocoder.cn/3a5b28a2d3bd435ca94ea5c8752609d5)
\ No newline at end of file
diff --git a/spring/48-Spring 源码分析-AOP 源码简单导读.assets/01.png b/spring/48-Spring 源码分析-AOP 源码简单导读.assets/01.png
new file mode 100644
index 0000000..7fb02fb
Binary files /dev/null and b/spring/48-Spring 源码分析-AOP 源码简单导读.assets/01.png differ
diff --git a/spring/48-Spring 源码分析-AOP 源码简单导读.assets/02.png b/spring/48-Spring 源码分析-AOP 源码简单导读.assets/02.png
new file mode 100644
index 0000000..a6e9d96
Binary files /dev/null and b/spring/48-Spring 源码分析-AOP 源码简单导读.assets/02.png differ
diff --git a/spring/48-Spring 源码分析-AOP 源码简单导读.md b/spring/48-Spring 源码分析-AOP 源码简单导读.md
new file mode 100644
index 0000000..2be3c2e
--- /dev/null
+++ b/spring/48-Spring 源码分析-AOP 源码简单导读.md	
@@ -0,0 +1,198 @@
+# 精尽 Spring 源码分析 —— AOP 源码简单导读
+
+# 1. 前置内容
+
+Spring AOP 是基于 Spring IoC 机制来实现的，所以建议对 IoC 的源码有一定的了解。
+
+当然，一般情况下，也是先看完 IoC 相关的源码，在来看 AOP 的源码。
+
+# 2. 如何调试
+
+① 调试基于 `@Aspect` 注解的 AOP 的流程
+
+可调试 `org.springframework.aop.aspectj.autoproxy.AspectJAutoProxyCreatorTests` 这个单元测试里的方法。
+
+# 3. 推荐资料
+
+【必读】首先，推荐的是《Spring 源码深度解析》的 [「第7章　AOP」](https://svip.iocoder.cn/Spring/aop-simple-intro/#) 章节。
+因为 Spring 静态 AOP 实际场景下，使用较少，胖友可以选择性看看。感兴趣的话，可以对 Java Instrumentation 机制做一定的了解。目前主流的链路追踪系统的 Java Agent 都是基于它来实现的。
+
+然后，也推荐看看五月的仓颉关于 AOP 的两篇文章：
+
+- [《【Spring源码分析】AOP源码解析（上篇）》](https://www.cnblogs.com/xrq730/p/6753160.html) ，对 Spring AOP XML 配置的方式进行源码解析。
+- [《【Spring源码分析】AOP源码解析（下篇）》](https://www.cnblogs.com/xrq730/p/6757608.html) ，内容上，和《Spring 源码深度解析》的 [「第7章　AOP」](https://svip.iocoder.cn/Spring/aop-simple-intro/#) 章节，作为互为补充噶。
+
+再然后，也非常推荐田小波关于 AOP 的四篇文章，非常**细致**，特别是对 AOP 的概念解释以及流程的拆分上：
+
+- [《Spring AOP 源码分析系列文章导读》](https://www.tianxiaobo.com/2018/06/17/Spring-AOP-源码分析系列文章导读/)
+- [《Spring AOP 源码分析 - 筛选合适的通知器》](https://www.tianxiaobo.com/2018/06/22/Spring-AOP-源码分析-拦截器链的执行过程/)
+- [《Spring AOP 源码分析 - 创建代理对象》](https://www.tianxiaobo.com/2018/06/20/Spring-AOP-源码分析-创建代理对象/)
+- [《Spring AOP 源码分析 - 拦截器链的执行过程》](https://www.tianxiaobo.com/2018/06/22/Spring-AOP-源码分析-拦截器链的执行过程/)
+
+再再然后，还会灰常推荐 JavaDoop 关于 AOP 的一篇文章，看着大气：
+
+- [《Spring AOP 源码解析》](https://www.javadoop.com/post/spring-aop-source)
+
+最后，推荐一些和 AOP 相关的有趣的文章：
+
+- [《Spring AOP,AspectJ, CGLIB 有点晕》](https://www.jianshu.com/p/fe8d1e8bd63e)
+- [《Cglib 与 JDK 动态代理的运行性能比较》](https://www.cnblogs.com/haiq/p/4304615.html)
+- [《Spring AOP 源码解析》](https://www.javadoop.com/post/spring-aop-source)
+
+# 4. 后置内容
+
+看完 Spring AOP 之后，当然是看 Spring Transaction 啦。
+
+哈哈哈哈，和我们日常开发，息息相关。
+
+# 5. 重要的类
+
+> 老艿艿：本小节，就是艿艿简单的笔记，可以忽略。嘿嘿。后面，在找时间完善下。
+
+核心流程如下图：
+
+> FROM 《Spring 源码深度解析》
+>
+> [![核心流程](48-Spring 源码分析-AOP 源码简单导读.assets/02.png)](http://static.iocoder.cn/images/Spring/2020-01-01/02.png)核心流程
+
+## 5.1 aopalliance
+
+对应 `org.aopalliance` 包。
+
+Spring 对 AOP 联盟接口的变种。
+
+- Advice
+
+  - Interceptor
+    - MethodInterceptor
+
+- Joinpoint ，连接点接口。每个方法，都对应一个 Joinpoint 对象。
+
+  - Invocation ，调用接口。
+
+    - MethodInvocation ，方法调用接口。
+
+      - ProxyMethodInvocation ，代理方法调用接口。在根目录的包里。
+
+        - ReflectiveMethodInvocation ，反射方法调用实现类。在
+
+           
+
+          ```
+          framework
+          ```
+
+           
+
+          包里。
+
+          - CglibMethodInvocation ，基于 CGLIB 方法调用实现类。在 `framework` 包里。
+
+- Advice ，定义的横切逻辑。在如下几个时机，可以进行执行：
+
+  - Before ：在目标方便调用前执行通知。
+  - After ：在目标方法完成后执行通知。
+  - After Returning ： 在目标方法执行成功后，调用通知。
+  - After Throwing ：在目标方法抛出异常后，执行通知。
+  - Around ：在目标方法调用前后均可执行自定义逻。
+
+## 5.2 config
+
+对应 `org.springframework.aop.config` 包。
+
+AopNamespaceHandler ，对 `<aop:/>` 命名空间的处理器。
+
+- AspectJAutoProxyBeanDefinitionParser ，将 `<aop:aspectj-autoproxy/>` 标签，解析成 BeanDefinition 的解析器。
+- ScopedProxyBeanDefinitionDecorator
+- ConfigBeanDefinitionParser
+- SpringConfiguredBeanDefinitionParser
+
+## 5.3 framework
+
+对应 `org.springframework.aop.framework` 包。
+
+AutoProxyCreator 整体类图如下：
+
+[![AutoProxyCreator 类图](48-Spring 源码分析-AOP 源码简单导读.assets/01.png)](http://static.iocoder.cn/images/Spring/2020-01-01/01.png)AutoProxyCreator 类图
+
+- AbstractAutoProxyCreator ，自动代理构造器抽象类。
+  - `#wrapIfNecessary(Object bean, String beanName, Object cacheKey)` 方法，如果需要，将制定 Bean 对象包装成 **Proxy 代理**对象。
+  - `#createProxy(Class<?> beanClass, String beanName, Object[] specificInterceptors, TargetSource targetSource)` 方法，创建 **Proxy 代理**对象。
+- AbstractAdvisorAutoProxyCreator ，基于 Advisor 的 自动代理构造器抽象类。
+  - `#findAdvisorsThatCanApply(List<Advisor> candidateAdvisors, Class<?> beanClass, String beanName)` 方法，获得 Bean 对象**可使用**的 Advisor 集合，是从 `candidateAdvisors` 参数中筛选出来的。
+  - `#getAdvicesAndAdvisorsForBean(Class<?> beanClass, String beanName, TargetSource targetSource)` 方法，获得 Bean 对象**可使用**的 Advisor 集合。
+- AnnotationAwareAspectJAutoProxyCreator ，支持 AOP 注解的，基于 AspectJ 的代理自动构造器。
+- ProxyFactory ，创建 Proxy 的工厂类。
+  - DefaultAopProxyFactory ，默认 ProxyFactory 实现类。
+- AopProxy ，AOP 代理接口，创建对应的代理对象。
+  - 它有两个子类：
+    - JdkDynamicAopProxy ，基于 JDK 的 AOP 代理实现类。
+      - `#invoke(Object proxy, Method method, Object[] args)` 方法，实现 InvocationHandler 的接口方法，执行代理的调用。【重要】
+    - ObjenesisCglibAopProxy ，基于 CGLIB 的 AOP 的代理实现类。
+  - `#getProxy(ClassLoader classLoader)` 方法，创建对应的代理对象。
+- AopContext ，AOP 上下文，基于 ThreadLocal 实现。
+- AdvisorChainFactory ，Advisor 调用链工厂接口，用于获取每个方法调用时的调用链。
+  - `#getInterceptorsAndDynamicInterceptionAdvice(Advised config, Method method, Class<?> targetClass)` 方法，获得指定方法拦截的拦截器链。
+  - DefaultAdvisorChainFactory ，默认实现类。
+- ProxyMethodInvocation ，代理方法调用接口。
+  - ReflectiveMethodInvocation ，基于反射的方式，代理方法调用实现类。
+    - `#proceed()` 方法，执行方法。基于递归的方式，调用每个拦截器链中的拦截器，最后调用真正的方法。
+    - `#invokeJoinpoint()` 方法，执行真正的方法，即切点的方法。
+    - CglibMethodInvocation ，基于 CGLIB 的方式，进一步优化调用的实现类。
+- 各种情况下，调用：
+  - MethodBeforeAdviceInterceptor
+  - AfterReturningAdviceInterceptor
+  - AspectJAroundAdvice
+  - AspectJAfterAdvice
+  - AspectJAfterThrowingAdvice
+  - ThrowsAdviceInterceptor
+
+## 5.4 aspectj
+
+对应 `org.springframework.aop.aspectj` 包。
+
+- ReflectiveAspectJAdvisorFactory
+- BeanFactoryAspectJAdvisorsBuilder
+  - `#buildAspectJAdvisors()` 方法，构建**所有** @Aspect 注解类的增强方法对应的 Advisor 对象。
+- AnnotationAwareAspectJAutoProxyCreator
+  - `#findCandidateAdvisors()` 方法，获得**所有**增强方法对应的 Advisor 对象。
+- InstantiationModelAwarePointcutAdvisorImpl
+- AbstractAspectJAdvice ，基于 AspectJ ，实现 Advice 接口的 Advice 抽象类。
+  - 有如下几个子类：
+    - AspectJAroundAdvice
+    - AspectJMethodBeforeAdvice
+    - AspectJAfterAdvice
+    - AspectJAfterReturningAdvice
+    - AspectJAfterThrowingAdvice
+  - 通过 `ReflectiveAspectJAdvisorFactory#getAdvice(...)` 方法，构建 AbstractAspectJAdvice 对象。
+  - 通过 `#invokeAdviceMethodWithGivenArgs(Object[] args)` 方法，执行增强 Advice 的方法。【重要】
+
+## 5.5 interceptor
+
+对应 `org.springframework.aop.interceptor` 包。
+
+- ExposeInvocationInterceptor
+
+## 5.6 scope
+
+对应 `org.springframework.aop.scope` 包。
+
+## 5.7 support
+
+对应 `org.springframework.aop.support` 包。
+
+## 5.8 target
+
+对应 `org.springframework.aop.target` 包。
+
+提供多种 TargetSource 的实现类，而 TargetSource 可以理解成 Target 的数据源，可以根据每次方法调用，返回相同或不同的 Target 对象。可以选择性看看，感兴趣的胖友，可以看看 [《spring-aop组件详解——TargetSource目标源》](https://my.oschina.net/lixin91/blog/688188) 。
+
+## 5.9 根目录
+
+对应 `org.springframework.aop` 包的根目录。
+
+- Pointcut ，切点接口，用于选择连接点。
+  - 其定义了两个接口方法，分别返回：
+    - ClassFilter ，匹配哪些类。
+    - MethodMatcher ，匹配哪些方法。
+  - AspectJExpressionPointcut ，AspectJ 的切点表达式。
\ No newline at end of file
diff --git a/spring/49-Spring 源码分析-Transaction 源码简单导读.md b/spring/49-Spring 源码分析-Transaction 源码简单导读.md
new file mode 100644
index 0000000..908535b
--- /dev/null
+++ b/spring/49-Spring 源码分析-Transaction 源码简单导读.md	
@@ -0,0 +1,332 @@
+# 精尽 Spring 源码分析 —— Transaction 源码简单导读
+
+> 对应 Maven 模块为 `spring-tx` 。
+>
+> 为什么是 tx 缩写呢？因为 Transaction 的发音，和 tx 比较接近。
+
+# 1. 前置内容
+
+Spring Transaction 主要基于 Spring AOP 机制来实现的，所以建议对 AOP 的源码有一定的了解。
+
+当然，一般情况下，也是先看完 AOP 相关的源码，在来看 Transaction 的源码。
+
+😈 如果胖友头铁，直接开始看 Transaction 的源码，也未尝不可。
+
+# 2. 如何调试
+
+① 调试 `<tx:advice />` 标签的解析的流程
+
+可调试 `org.springframework.transaction.TxNamespaceHandlerTests` 这个单元测试里的方法。
+
+另外，如果你想调试事务的提交和回滚，可以调试如下两个单元测试方法：
+
+- `#invokeTransactional()` 方法，提交事务。
+- `#rollbackRules()` 方法，回滚事务。
+
+当然，这两个方法，是不包含 DB 相关的，只能了解大体的事务执行过程。
+
+② 调试 `@Transactional` 注解的解析的流程
+
+使用的还是 `org.springframework.transaction.TxNamespaceHandlerTests` 这个单元测试里的方法。下面，艿艿列下做出调整的地方。
+
+1、增加 TestBean2 类。如下：
+
+```
+package org.springframework.transaction.yunai; // <1>
+
+import org.springframework.tests.sample.beans.TestBean;
+import org.springframework.transaction.annotation.Transactional;
+
+public class TestBean2 extends TestBean {
+
+    @Override
+    @Transactional // <2>
+    public Object returnsThis() {
+        return super.returnsThis();
+    }
+
+}
+```
+
+- `<1>` 处，因为 TestBean 在 `spring-beans` 项目里，不好加上 `@Transactional` 注解。
+- `<2>` 处，增加 `@Transactional` 注解。
+
+2、修改 `txNamespaceHandlerTests.xml` 配置文件。如下：
+
+```
+<?xml version="1.0" encoding="UTF-8"?>
+<beans xmlns="http://www.springframework.org/schema/beans"
+		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+		xmlns:aop="http://www.springframework.org/schema/aop"
+		xmlns:tx="http://www.springframework.org/schema/tx"
+		xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
+				http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.5.xsd
+				http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.5.xsd">
+
+    <!-- add by 芋艿：用于触发 AnnotationDrivenBeanDefinitionParser 的调试 -->
+    <tx:annotation-driven proxy-target-class="true" order="0" />
+
+    <aop:config>
+        <!-- modify by 芋艿：增加 order="1" -->
+		<aop:advisor pointcut="execution(* *..ITestBean.*(..))" advice-ref="txAdvice" order="1" />
+	</aop:config>
+
+	<tx:advice id="txAdvice"> <!-- 创建 TransactionInterceptor -->
+		<tx:attributes>
+			<tx:method name="get*" read-only="true"/>
+			<tx:method name="set*"/>
+			<tx:method name="exceptional"/>
+		</tx:attributes>
+	</tx:advice>
+
+	<tx:advice id="txRollbackAdvice"> <!-- 创建 TransactionInterceptor -->
+		<tx:attributes>
+			<tx:method name="get*" rollback-for="java.lang.Exception"/>
+			<tx:method name="set*" no-rollback-for="java.lang.RuntimeException"/>
+		</tx:attributes>
+	</tx:advice>
+
+	<bean id="transactionManager" class="org.springframework.tests.transaction.CallCountingTransactionManager"/>
+
+	<bean id="testBean" class="org.springframework.tests.sample.beans.TestBean"/>
+
+    <bean id="testBean2" class="org.springframework.transaction.yunai.TestBean2" /> <!-- add by 芋艿：增加 TestBean2 的声明  -->
+
+</beans>
+```
+
+- 有 `<!-- add by 芋艿 -->` 和 `<!-- modify by 芋艿 -->` 的部分，就是艿艿修改过的地方。
+
+3、在 TxNamespaceHandlerTests 类中，增加新的单元测试方法。代码如下：
+
+```
+// TxNamespaceHandlerTests.java
+
+// add by 芋艿
+@Test
+public void invokeTransactional2() {
+    ITestBean bean = getTestBean2();
+    bean.returnsThis(); // 测试，我们对 @Transactional 注解的效果
+//        bean.getAge(); // 测试，原有 xml 配置的事务的效果
+}
+
+// add by 芋艿
+private ITestBean getTestBean2() {
+    return (ITestBean) context.getBean("testBean2");
+}
+```
+
+- 愉快的运行吧。
+
+③ 基于 DB 的事务管理器 DataSourceTransactionManager 的事务的流程
+
+可调试 `org.springframework.transaction.TxNamespaceHandlerTests` 这个单元测试里的方法。里面的测试用例非常多，胖友可以挑选自己需要的。当然，如果胖友想测试不同事务传播级别的组合，也可以自己写单元测试，示例如下：
+
+```
+@Test
+public void test01() throws SQLException {
+    given(con.getAutoCommit()).willReturn(true);
+
+    final TransactionTemplate tt01 = new TransactionTemplate(tm);
+    tt01.setPropagationBehavior(TransactionTemplate.PROPAGATION_REQUIRES_NEW);
+
+    final TransactionTemplate tt02 = new TransactionTemplate(tm);
+    tt02.setPropagationBehavior(TransactionTemplate.PROPAGATION_NOT_SUPPORTED);
+
+    // 首先，PROPAGATION_REQUIRES_NEW
+    tt01.execute(new TransactionCallbackWithoutResult() {
+
+        @Override
+        protected void doInTransactionWithoutResult(TransactionStatus status) {
+
+            // 然后，PROPAGATION_NOT_SUPPORTED
+            tt02.execute(new TransactionCallbackWithoutResult() {
+
+                @Override
+                protected void doInTransactionWithoutResult(TransactionStatus status) {
+                    System.out.println("滴滴滴");
+
+                    // 最后，PROPAGATION_REQUIRES_NEW
+                    tt01.execute(new TransactionCallbackWithoutResult() {
+                        @Override
+                        protected void doInTransactionWithoutResult(TransactionStatus status) {
+                            System.out.println("滴滴滴");
+                        }
+                    });
+
+                }
+
+            });
+        }
+
+    });
+}
+```
+
+- 使用 `org.springframework.transaction.support.TransactionTemplate` 类，很方便的，胖友直接上手写两个。
+
+# 3. 推荐资料
+
+【必读】首先，推荐的是《Spring 源码深度解析》的 [「第10章　事务」](https://svip.iocoder.cn/Spring/transaction-simple-intro/#) 章节。因为事务内嵌 `PROPAGATION_NESTED` 的传播级别是 Spring 独有，且实际场景下非常少( 和一群基佬沟通了下，都没用到 )，所以艿艿自己也没研究。也就说，想要偷懒的胖友，请放心偷懒，哈哈哈哈。
+
+然后，推荐的源码解析文章是
+
+- 张强的 [《原创 Spring 源码解析之事务篇》](http://www.linkedkeeper.com/1045.html)
+- Bww [《Spring-事务的源码分析（七）》](http://www.baowenwei.com/post/spring/spring-shi-wu-de-yuan-ma-fen-xi-qi)
+
+最后，推荐一些和 Transaction 相关的有趣的文章：
+
+- [《可能是最漂亮的 Spring 事务管理详解》](https://juejin.im/post/5b00c52ef265da0b95276091)
+
+# 4. 后置内容
+
+看完 Spring AOP 之后，可以考虑看看 Spring MVC 啦。
+
+虽然说，MVC 和 AOP 没什么必然的联系，但是距离我们日常开发特别接近，并且拓展的空间也会更多。
+
+# 5. 重要的类
+
+> 老艿艿：本小节，就是艿艿简单的笔记，可以忽略。嘿嘿。后面，在找时间完善下。
+
+- 事务定义
+
+  - ```
+    org.springframework.transaction.TransactionDefinition
+    ```
+
+     
+
+    接口，事务定义接口。
+
+    - ```
+      org.springframework.transaction.interceptor.TransactionAttribute
+      ```
+
+       
+
+      接口，支持定义返回异常回滚的事务定义接口。
+
+      - `org.springframework.transaction.interceptor.RuleBasedTransactionAttribute` 类，基于 `{@link RollbackRuleAttribute}` 的事务定义实现类。
+
+    - ps：因为我们看到，即有 Definition( 定义 )，又有 Attribute( 属性 )的两种结尾，考虑到好理解，统一下面叫属性，即事务属性。
+
+    - 每个 `@Transactional` 注解的方法，都会被解析成一个 RuleBasedTransactionAttribute 对象。
+
+    - 每个 `<tx:method />` XML 的配置，也会被解析成一个 RuleBasedTransactionAttribute 对象。
+
+- 事务属性**源**
+
+  - ```
+    org.springframework.transaction.interceptor.TransactionAttributeSource
+    ```
+
+     
+
+    接口，事务属性
+
+    源
+
+    ，可以理解成 TransactionAttribute 的 Map 。
+
+    - ```
+      org.springframework.transaction.interceptor.AbstractFallbackTransactionAttributeSource
+      ```
+
+       
+
+      抽象类，支持按照【实现方法的事务属性 > 实现类的事务属性 > 接口的事务属性 > 接口的事务属性】的优先级，获取 TransactionAttribute 的 TransactionAttributeSource 抽象类。重点在
+
+       
+
+      ```
+      #computeTransactionAttribute(Method method, Class<?> targetClass)
+      ```
+
+       
+
+      方法的实现。
+
+      - 【用于注解配置】`org.springframework.transaction.annotation.AnnotationTransactionAttributeSource` 类，基于 `{@link Transactional}` 注解的事务的 TransactionAttributeSource 实现类。
+
+    - 【用于 XML 配置】`org.springframework.transaction.interceptor.NameMatchTransactionAttributeSource` ，基于方法名**模式匹配**的 TransactionAttributeSource 实现类。
+
+- 解析器相关
+
+  - `org.springframework.transaction.config.TxNamespaceHandler` 类，Transaction 自定义标签的 NamespaceHandler 实现类。
+  - `org.springframework.transaction.annotation.SpringTransactionAnnotationParser` 类，解析 `@Transactional` 注解的解析器。
+  - `org.springframework.transaction.config.TxAdviceBeanDefinitionParser` 类，解析 `<tx:method />` XML 配置的解析器。
+
+- AOP 相关
+
+  - `org.springframework.transaction.interceptor.TransactionInterceptor` 类，AOP 事务拦截器。重点在其父类 TransactionAspectSupport 的 `#invokeWithinTransaction(Method method, Class<?> targetClass, final InvocationCallback invocation)` 方法。
+  - `org.springframework.transaction.interceptor.TransactionAttributeSourceAdvisor` ，事务属性源 Advisor 实现类。
+  - `org.springframework.transaction.interceptor.TransactionAttributeSourcePointcut` ，事务属性源 Pointcut 实现类。
+
+- 事务管理器
+
+  - ```
+    org.springframework.transaction.TransactionStatus
+    ```
+
+     
+
+    接口，事务状态接口。
+
+    - ```
+      org.springframework.transaction.support.AbstractTransactionStatus
+      ```
+
+       
+
+      抽象类，事务状态抽象类。
+
+      - `org.springframework.transaction.support.DefaultTransactionStatus` 类，默认事务状态实现类。
+
+  - ```
+    org.springframework.transaction.PlatformTransactionManager
+    ```
+
+     
+
+    接口，事务管理器接口。定义了
+
+     
+
+    ```
+    #getTransaction(TransactionDefinition definition)
+    ```
+
+    、
+
+    ```
+    #commit(TransactionStatus status)
+    ```
+
+    、
+
+    ```
+    #rollback(TransactionStatus status)
+    ```
+
+     
+
+    事务操作的三个
+
+    关键
+
+    方法。
+
+    - 【重要】
+
+      ```
+      org.springframework.transaction.support.AbstractPlatformTransactionManager
+      ```
+
+       
+
+      抽象类，事务管理器抽象类，实现事务管理的核心流程。
+
+      - 【重要】`org.springframework.jdbc.datasource.DataSourceTransactionManager` 类，JDBC DataSource 事务管理器。另外，该类在 `spring-jdbc` 模块中实现。
+      - `org.springframework.orm.hibernate5.HibernateTransactionManager` 类，Hibernate 事务管理器。另外，该类在 `spring-hibernate` 模块中实现。😈 感兴趣的胖友，可以自己研究。我…没有研究，哈哈哈哈。
+
+  - `org.springframework.transaction.support.TransactionSynchronizationManager` ，基于 ThreadLocal ，记录当前线程的事务的一些信息。例如：1）事务的隔离级别、；2）在 DataSourceTransactionManager 事物管理器中，会存储当前的数据库连接信息。
\ No newline at end of file
diff --git a/spring/file-create.py b/spring/file-create.py
new file mode 100644
index 0000000..a412975
--- /dev/null
+++ b/spring/file-create.py
@@ -0,0 +1,27 @@
+import os
+import pyperclip
+
+# 获取当前脚本的路径
+script_dir = os.path.dirname(os.path.abspath(__file__))
+
+# 从剪贴板获取文件名列表，假设每行一个文件名
+file_names = pyperclip.paste().strip().split('\n')
+
+# 遍历文件名列表，为每个文件名添加排序前缀并创建文件
+for index, file_name in enumerate(file_names, start=1):
+    # 去除文件名两端的空白字符
+    file_name = file_name.strip()
+    
+    # 添加排序前缀和.md后缀
+    file_name_with_prefix = f"{index:02d}-{file_name}.md"  # 这里使用3位数的排序前缀，可以根据需要调整
+    
+    # 构建文件的完整路径
+    file_path = os.path.join(script_dir, file_name_with_prefix)
+    
+    # 创建文件
+    with open(file_path, 'w') as file:
+        # 如果需要写入初始内容，可以在这里添加
+        # 例如：file.write("This is the content of the file.")
+        pass  # 如果不需要写入内容，则使用pass
+
+print(f"Files created successfully in {script_dir}")
\ No newline at end of file
diff --git a/spring/tmp.txt b/spring/tmp.txt
new file mode 100644
index 0000000..4d1199a
--- /dev/null
+++ b/spring/tmp.txt
@@ -0,0 +1,49 @@
+精尽 Spring 面试题
+精尽 Spring 学习指南
+精尽 Spring 源码分析-调试环境搭建（Spring 5.1.1 版本）
+精尽 Spring 源码分析-调试环境搭建（Spring 5.3.1 版本）
+Spring-IoC 之深入理解 Spring IoC
+Spring-IoC 之 Spring 统一资源加载策略
+Spring-IoC 之加载 BeanDefinition
+Spring-IoC 之获取验证模型
+Spring-IoC 之获取 Document 对象
+Spring-IoC 之注册 BeanDefinitions
+Spring-IoC 之解析Bean：解析 import 标签
+Spring-IoC 之解析bean标签：开启解析进程
+Spring-IoC 之解析bean标签：BeanDefinition
+Spring-IoC 之解析bean标签：meta、lookup-method、replace-method
+Spring-IoC 之解析bean标签：constructor-arg、property、qualifier
+Spring-IoC 之解析bean标签：解析自定义标签
+Spring-IoC 之解析自定义标签
+Spring-IoC 之注册解析的 BeanDefinitions
+Spring-IoC 之装载 BeanDefinitions 总结
+Spring-IoC 之开启 Bean 的加载
+Spring-IoC 之加载 Bean：从单例缓存中获取单例 Bean
+Spring-IoC 之加载 Bean：parentBeanFactory 与依赖处理
+Spring-IoC 之加载 Bean：分析各 scope 的 Bean 创建
+Spring-IoC 之加载 Bean：创建 Bean（一）之主流程
+Spring-IoC 之加载 Bean：创建 Bean（二）之实例化 Bean 对象(1)
+Spring-IoC 之加载 Bean：创建 Bean（三）之实例化 Bean 对象(2)
+Spring-IoC 之加载 Bean：创建 Bean（四）之属性填充
+Spring-IoC 之加载 Bean：创建 Bean（五）之循环依赖处理
+Spring-IoC 之加载 Bean：创建 Bean（六）之初始化 Bean 对象
+Spring-IoC 之加载 Bean：总结
+Spring-IoC 之深入分析 Aware 接口
+Spring-IoC 之深入分析 BeanPostProcessor
+Spring-IoC 之深入分析 InitializingBean 和 init-method
+Spring-IoC 之深入分析 Bean 的生命周期
+Spring-IoC 之深入分析 BeanFactoryPostProcessor
+Spring-IoC 之深入分析 PropertyPlaceholderConfigurer
+Spring-IoC 之 PropertyPlaceholderConfigurer 的应用
+Spring-IoC 之深入分析 PropertyOverrideConfigurer
+Spring-IoC 之深入分析 Bean 的类型转换体系
+Spring-IoC 之自定义类型转换器
+Spring-IoC 之分析 BeanWrapper
+Spring-IoC 之 Bean 的实例化策略：InstantiationStrategy
+Spring-IoC 之 BeanDefinition 注册表：BeanDefinitionRegistry
+Spring-环境 & 属性：PropertySource、Environment、Profile
+Spring-ApplicationContext 相关接口架构分析
+Spring-深入分析 ApplicationContext 的 refresh()
+Spring-4 张图带你读懂 Spring IoC 的世界
+Spring 源码分析-AOP 源码简单导读
+Spring 源码分析-Transaction 源码简单导读
\ No newline at end of file
diff --git a/springboot/01-Spring Boot 面试题.assets/01.png b/springboot/01-Spring Boot 面试题.assets/01.png
new file mode 100644
index 0000000..14571b7
Binary files /dev/null and b/springboot/01-Spring Boot 面试题.assets/01.png differ
diff --git a/springboot/01-Spring Boot 面试题.assets/02.png b/springboot/01-Spring Boot 面试题.assets/02.png
new file mode 100644
index 0000000..a0f11f3
Binary files /dev/null and b/springboot/01-Spring Boot 面试题.assets/02.png differ
diff --git a/springboot/01-Spring Boot 面试题.assets/03.png b/springboot/01-Spring Boot 面试题.assets/03.png
new file mode 100644
index 0000000..183b0cc
Binary files /dev/null and b/springboot/01-Spring Boot 面试题.assets/03.png differ
diff --git a/springboot/01-Spring Boot 面试题.assets/04.png b/springboot/01-Spring Boot 面试题.assets/04.png
new file mode 100644
index 0000000..927878f
Binary files /dev/null and b/springboot/01-Spring Boot 面试题.assets/04.png differ
diff --git a/springboot/01-Spring Boot 面试题.assets/05.png b/springboot/01-Spring Boot 面试题.assets/05.png
new file mode 100644
index 0000000..02c04df
Binary files /dev/null and b/springboot/01-Spring Boot 面试题.assets/05.png differ
diff --git a/springboot/01-Spring Boot 面试题.md b/springboot/01-Spring Boot 面试题.md
new file mode 100644
index 0000000..be51c5d
--- /dev/null
+++ b/springboot/01-Spring Boot 面试题.md	
@@ -0,0 +1,802 @@
+# 精尽 Spring Boot 面试题「最新更新时间：2024-02」
+
+以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。
+
+如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的 Spring Boot 面试题的大保健。
+
+而题目的难度，艿艿尽量按照从容易到困难的顺序，逐步下去。
+
+在内容上，我们会分成两大块：
+
+- 核心技术篇，分享 Spring Boot 的核心技术相关的内容。
+- 整合篇，分享 Spring Boot 整合一些框架的面试题，例如 JPA 如何集成到 Spring Boot 中。
+
+# 核心技术篇
+
+## Spring Boot 是什么？
+
+[Spring Boot](https://github.com/spring-projects/spring-boot) 是 Spring 的**子项目**，正如其名字，提供 Spring 的引导( **Boot** )的功能。
+
+通过 Spring Boot ，我们开发者可以快速配置 Spring 项目，引入各种 Spring MVC、Spring Transaction、Spring AOP、MyBatis 等等框架，而无需不断重复编写繁重的 Spring 配置，降低了 Spring 的使用成本。
+
+> 艿艿：犹记当年，Spring XML 为主的时代，大晚上各种搜索 Spring 的配置，苦不堪言。现在有了 Spring Boot 之后，生活真美好。
+
+Spring Boot 提供了各种 Starter 启动器，提供标准化的默认配置。例如：
+
+- [`spring-boot-starter-web`](https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-web/2.1.1.RELEASE) 启动器，可以快速配置 Spring MVC 。
+- [`mybatis-spring-boot-starter`](https://mvnrepository.com/artifact/org.mybatis.spring.boot/mybatis-spring-boot-starter/1.3.2) 启动器，可以快速配置 MyBatis 。
+
+并且，Spring Boot 基本已经一统 Java 项目的开发，大量的开源项目都实现了其的 Starter 启动器。例如：
+
+- [`incubator-dubbo-spring-boot-project`](https://github.com/apache/incubator-dubbo-spring-boot-project) 启动器，可以快速配置 Dubbo 。
+- [`rocketmq-spring-boot-starter`](https://github.com/maihaoche/rocketmq-spring-boot-starter) 启动器，可以快速配置 RocketMQ 。
+
+## Spring Boot 提供了哪些核心功能？
+
+- 1、独立运行 Spring 项目
+
+  Spring Boot 可以以 jar 包形式独立运行，运行一个 Spring Boot 项目只需要通过 `java -jar xx.jar` 来运行。
+
+- 2、内嵌 Servlet 容器
+
+  Spring Boot 可以选择内嵌 Tomcat、Jetty 或者 Undertow，这样我们无须以 war 包形式部署项目。
+
+  > 第 2 点是对第 1 点的补充，在 Spring Boot 未出来的时候，大多数 Web 项目，是打包成 war 包，部署到 Tomcat、Jetty 等容器。
+
+- 3、提供 Starter 简化 Maven 配置
+
+  Spring 提供了一系列的 starter pom 来简化 Maven 的依赖加载。例如，当你使用了 `spring-boot-starter-web` ，会自动加入如下依赖：[![`spring-boot-starter-web` 的 pom 文件](01-Spring Boot 面试题.assets/01.png)](http://static.iocoder.cn/images/Spring/2018-12-26/01.png)`spring-boot-starter-web` 的 pom 文件
+
+- 4、[自动配置 Spring Bean](https://www.jianshu.com/p/ddb6e32e3faf)
+
+  Spring Boot 检测到特定类的存在，就会针对这个应用做一定的配置，进行自动配置 Bean ，这样会极大地减少我们要使用的配置。
+
+  当然，Spring Boot 只考虑大多数的开发场景，并不是所有的场景，若在实际开发中我们需要配置Bean ，而 Spring Boot 没有提供支持，则可以自定义自动配置进行解决。
+
+- 5、[准生产的应用监控](https://blog.csdn.net/wangshuang1631/article/details/72810412)
+
+  Spring Boot 提供基于 HTTP、JMX、SSH 对运行时的项目进行监控。
+
+- 6、无代码生成和 XML 配置
+
+  Spring Boot 没有引入任何形式的代码生成，它是使用的 Spring 4.0 的条件 `@Condition` 注解以实现根据条件进行配置。同时使用了 Maven /Gradle 的**依赖传递解析机制**来实现 Spring 应用里面的自动配置。
+
+  > 第 6 点是第 3 点的补充。
+
+## Spring Boot 有什么优缺点？
+
+> 艿艿：任何技术栈，有优点必有缺点，没有银弹。
+>
+> 另外，这个问题的回答，我们是基于 [《Spring Boot浅谈(是什么/能干什么/优点和不足)》](https://blog.csdn.net/fly_zhyu/article/details/76407830) 整理，所以胖友主要看下这篇文章。
+
+**Spring Boot 的优点**
+
+> 艿艿：优点和 [「Spring Boot 提供了哪些核心功能？」](https://svip.iocoder.cn/Spring-Boot/Interview/#) 问题的答案，是比较重叠的。
+
+- 1、使【编码】变简单。
+- 2、使【配置】变简单。
+- 3、使【部署】变简单。
+- 4、使【监控】变简单。
+
+**Spring Boot 的缺点**
+
+> 艿艿：如下的缺点，基于 [《Spring Boot浅谈(是什么/能干什么/优点和不足)》](https://blog.csdn.net/fly_zhyu/article/details/76407830)，考虑的出发点是把 Spring Boot 作为微服务的框架的选型的角度进行考虑。
+
+- 1、没有提供相应的【服务发现和注册】的配套功能。
+
+  > 艿艿：当然，实际上 Spring Boot 本身是不需要提供这样的功能。服务发现和注册的功能，是在 Spring Cloud 中进行提供。
+
+- 2、自身的 acturator 所提供的【监控功能】，也需要与现有的监控对接。
+
+- 3、没有配套的【安全管控】方案。
+
+  > 艿艿：关于这一点，艿艿也有点迷糊，Spring Security 是可以比较方便的集成到 Spring Boot 中，所以不晓得这里的【安全管控】的定义是什么。所以这一点，面试的时候回答，可以暂时先省略。
+
+- 4、对于 REST 的落地，还需要自行结合实际进行 URI 的规范化工作
+
+  > 艿艿：这个严格来说，不算缺点。本身，是规范的范畴。
+
+所以，上面的缺点，严格来说可能不太适合在面试中回答。艿艿认为，Spring Boot 的缺点主要是，因为自动配置 Spring Bean 的功能，我们可能无法知道，哪些 Bean 被进行创建了。这个时候，如果我们想要自定义一些 Bean ，可能存在冲突，或者不知道实际注入的情况。
+
+## Spring Boot、Spring MVC 和 Spring 有什么区别？
+
+Spring 的完整名字，应该是 Spring Framework 。它提供了多个模块，Spring IoC、Spring AOP、Spring MVC 等等。所以，Spring MVC 是 Spring Framework 众多模块中的一个。
+
+而 Spring Boot 是构造在 Spring Framework 之上的 Boot 启动器，旨在更容易的配置一个 Spring 项目。
+
+总结说来，如下图所示：[![Spring Boot 对比 Spring MVC 对比 Spring ？](01-Spring Boot 面试题.assets/02.png)](http://static.iocoder.cn/images/Spring/2018-12-26/02.png)Spring Boot 对比 Spring MVC 对比 Spring ？
+
+## Spring Boot 中的 Starter 是什么？
+
+比较**通俗**的说法：
+
+> FROM [《Spring Boot 中 Starter 是什么》](https://www.cnblogs.com/EasonJim/p/7615801.html)
+>
+> 比如我们要在 Spring Boot 中引入 Web MVC 的支持时，我们通常会引入这个模块 `spring-boot-starter-web` ，而这个模块如果解压包出来会发现里面什么都没有，只定义了一些 **POM** 依赖。如下图所示：[![`spring-boot-starter-web`](01-Spring Boot 面试题.assets/03.png)](http://static.iocoder.cn/images/Spring/2018-12-26/03.png)`spring-boot-starter-web`
+>
+> 经过研究，Starter 主要用来简化依赖用的。比如我们之前做MVC时要引入日志组件，那么需要去找到log4j的版本，然后引入，现在有了Starter之后，直接用这个之后，log4j就自动引入了，也不用关心版本这些问题。
+
+比较**书名**的说法：
+
+> FROM [《Spring Boot Starter 介绍》](http://www.importnew.com/27101.html)
+>
+> 依赖管理是任何复杂项目的关键部分。以手动的方式来实现依赖管理不太现实，你得花更多时间，同时你在项目的其他重要方面能付出的时间就会变得越少。
+>
+> Spring Boot Starter 就是为了解决这个问题而诞生的。Starter **POM** 是一组方便的依赖描述符，您可以将其包含在应用程序中。您可以获得所需的所有 Spring 和相关技术的一站式服务，无需通过示例代码搜索和复制粘贴依赖。
+
+## Spring Boot 常用的 Starter 有哪些？
+
+- `spring-boot-starter-web` ：提供 Spring MVC + 内嵌的 Tomcat 。
+- `spring-boot-starter-data-jpa` ：提供 Spring JPA + Hibernate 。
+- `spring-boot-starter-data-redis` ：提供 Redis 。
+- `mybatis-spring-boot-starter` ：提供 MyBatis 。
+
+## 创建一个 Spring Boot Project 的最简单的方法是什么？
+
+Spring Initializr 是创建 Spring Boot Projects 的一个很好的工具。打开 `"https://start.spring.io/"` 网站，我们可以看到 Spring Initializr 工具，如下图所示：
+
+[![Spring Initializr](01-Spring Boot 面试题.assets/04.png)](http://static.iocoder.cn/images/Spring/2018-12-26/04.png)Spring Initializr
+
+- 图中的每一个**红线**，都可以填写相应的配置。相信胖友都很熟悉，就不哔哔了。
+- 点击生 GenerateProject ，生成 Spring Boot Project 。
+- 将项目导入 IDEA ，记得选择现有的 Maven 项目。
+
+------
+
+当然，我们以前使用 IDEA 创建 Spring 项目的方式，也一样能创建 Spring Boot Project 。Spring Initializr 更多的是，提供一个便捷的工具。
+
+## 如何统一引入 Spring Boot 版本？
+
+**目前有两种方式**。
+
+① 方式一：继承 `spring-boot-starter-parent` 项目。配置代码如下：
+
+```
+<parent>
+    <groupId>org.springframework.boot</groupId>
+    <artifactId>spring-boot-starter-parent</artifactId>
+    <version>1.5.1.RELEASE</version>
+</parent>
+```
+
+② 方式二：导入 spring-boot-dependencies 项目依赖。配置代码如下：
+
+```
+<dependencyManagement>
+    <dependencies>
+        <dependency>
+            <groupId>org.springframework.boot</groupId>
+            <artifactId>spring-boot-dependencies</artifactId>
+            <version>1.5.1.RELEASE</version>
+            <type>pom</type>
+            <scope>import</scope>
+        </dependency>
+    </dependencies>
+</dependencyManagement>
+```
+
+**如何选择？**
+
+因为一般我们的项目中，都有项目自己的 Maven parent 项目，所以【方式一】显然会存在冲突。所以实际场景下，推荐使用【方式二】。
+
+详细的，推荐阅读 [《Spring Boot 不使用默认的 parent，改用自己的项目的 parent》](https://blog.csdn.net/rainbow702/article/details/55046298) 文章。
+
+另外，在使用 Spring Cloud 的时候，也可以使用这样的方式。
+
+## 运行 Spring Boot 有哪几种方式？
+
+- 1、打包成 Fat Jar ，直接使用 `java -jar` 运行。目前主流的做法，推荐。
+- 2、在 IDEA 或 Eclipse 中，直接运行应用的 Spring Boot 启动类的 `#main(String[] args)` 启动。适用于开发调试场景。
+- 3、如果是 Web 项目，可以打包成 War 包，使用外部 Tomcat 或 Jetty 等容器。
+
+## 如何打包 Spring Boot 项目？
+
+通过引入 `spring-boot-maven-plugin` 插件，执行 `mvn clean package` 命令，将 Spring Boot 项目打成一个 Fat Jar 。后续，我们就可以直接使用 `java -jar` 运行。
+
+关于 `spring-boot-maven-plugin` 插件，更多详细的可以看看 [《创建可执行 jar》](https://qbgbook.gitbooks.io/spring-boot-reference-guide-zh/II. Getting started/11.5. Creating an executable jar.html) 。
+
+## 如果更改内嵌 Tomcat 的端口？
+
+- 方式一，修改 `application.properties` 配置文件的 `server.port` 属性。
+
+  ```
+  server.port=9090
+  ```
+
+- 方式二，通过启动命令增加 `server.port` 参数进行修改。
+
+  ```
+  java -jar xxx.jar --server.port=9090
+  ```
+
+当然，以上的方式，不仅仅适用于 Tomcat ，也适用于 Jetty、Undertow 等服务器。
+
+## 如何重新加载 Spring Boot 上的更改，而无需重新启动服务器？
+
+一共有三种方式，可以实现效果：
+
+- 【推荐】`spring-boot-devtools` 插件。注意，这个工具需要配置 IDEA 的自动编译。
+
+- Spring Loaded 插件。
+
+  > Spring Boot 2.X 后，官方宣布不再支持 Spring Loaded 插件 的更新，所以基本可以无视它了。
+
+- [JRebel](https://www.jianshu.com/p/bab43eaa4e14) 插件，需要付费。
+
+关于如何使用 `spring-boot-devtools` 和 Spring Loaded 插件，胖友可以看看 [《Spring Boot 学习笔记：Spring Boot Developer Tools 与热部署》](https://segmentfault.com/a/1190000014488100) 。
+
+## Spring Boot 的配置文件有哪几种格式？
+
+Spring Boot 目前支持两种格式的配置文件：
+
+- `.properties` 格式。示例如下：
+
+  ```
+  server.port = 9090
+  ```
+
+- `.yaml` 格式。示例如下：
+
+  ```
+  server:
+      port: 9090
+  ```
+
+------
+
+可能有胖友不了解 **YAML 格式**？
+
+YAML 是一种人类可读的数据序列化语言，它通常用于配置文件。
+
+- 与 Properties 文件相比，如果我们想要在配置文件中添加复杂的属性 YAML 文件就更加**结构化**。从上面的示例，我们可以看出 YAML 具有**分层**配置数据。
+
+- 当然 YAML 在 Spring 会存在一个缺陷，
+
+  `@PropertySource`
+
+   
+
+  注解不支持读取 YAML 配置文件，仅支持 Properties 配置文件。
+
+  - 不过这个问题也不大，可以麻烦一点使用 [`@Value`](https://blog.csdn.net/lafengwnagzi/article/details/74178374) 注解，来读取 YAML 配置项。
+
+实际场景下，艿艿相对比较喜欢使用 Properties 配置文件。个人喜欢~当然，YAML 已经越来越流行了。
+
+## Spring Boot 默认配置文件是什么？
+
+对于 Spring Boot 应用，默认的配置文件根目录下的 **application** 配置文件，当然可以是 Properties 格式，也可以是 YAML 格式。
+
+可能有胖友说，我在网上看到面试题中，说还有一个根目录下的 **bootstrap** 配置文件。这个是 Spring Cloud 新增的启动配置文件，[需要引入 `spring-cloud-context` 依赖后，才会进行加载](https://my.oschina.net/freeskyjs/blog/1843048)。它的特点和用途主要是：
+
+> 参考 [《Spring Cloud 中配置文件名 bootstrap.yml 和 application.yml 区别》](https://my.oschina.net/neverforget/blog/1525947) 文章。
+
+- 【特点】因为 bootstrap 由父 ApplicationContext 加载，比 application 优先加载。
+- 【特点】因为 bootstrap 优先于 application 加载，所以不会被它覆盖。
+- 【用途】使用配置中心 Spring Cloud Config 时，需要在 bootstrap 中配置配置中心的地址，从而实现父 ApplicationContext 加载时，从配置中心拉取相应的配置到应用中。
+
+另外，[《Appendix A. Common application properties》](https://docs.spring.io/spring-boot/docs/current/reference/html/common-application-properties.html) 中，有 application 配置文件的通用属性列表。
+
+## Spring Boot 如何定义多套不同环境配置？
+
+可以参考 [《Spring Boot 教程 - Spring Boot Profiles 实现多环境下配置切换》](https://blog.csdn.net/top_code/article/details/78570047) 一文。
+
+但是，需要考虑一个问题，生产环境的配置文件的安全性，显然我们不能且不应该把生产的配置放到项目的 Git 仓库中进行管理。那么应该怎么办呢？
+
+- 方案一，生产环境的配置文件放在生产环境的服务器中，以 `java -jar myproject.jar --spring.config.location=/xxx/yyy/application-prod.properties` 命令，设置 参数 `spring.config.location` 指向配置文件。
+- 方案二，使用 Jenkins 在执行打包，配置上 Maven Profile 功能，使用服务器上的配置文件。😈 整体来说，和【方案一】的差异是，将配置文件打包进了 Jar 包中。
+- 方案三，使用配置中心。
+
+## Spring Boot 配置加载顺序？
+
+在 Spring Boot 中，除了我们常用的 application 配置文件之外，还有：
+
+- 系统环境变量
+- 命令行参数
+- 等等…
+
+参考 [《Externalized Configuration》](https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html) 文档，我们整理顺序如下：
+
+1. ```
+   spring-boot-devtools
+   ```
+
+    
+
+   依赖的
+
+    
+
+   ```
+   spring-boot-devtools.properties
+   ```
+
+    
+
+   配置文件。
+
+   > 这个灰常小众，具体说明可以看看 [《Spring Boot参考文档（12）开发者工具》](https://blog.csdn.net/u011499747/article/details/71746325) ，建议无视。
+
+2. 单元测试上的
+
+    
+
+   ```
+   @TestPropertySource
+   ```
+
+    
+
+   和
+
+    
+
+   ```
+   @SpringBootTest
+   ```
+
+    
+
+   注解指定的参数。
+
+   > 前者的优先级高于后者。可以看看 [《Spring、Spring Boot 和TestNG 测试指南 - @TestPropertySource》](https://segmentfault.com/a/1190000010854607) 一文。
+
+3. 命令行指定的参数。例如 `java -jar springboot.jar --server.port=9090` 。
+
+4. 命令行中的 `spring.application.json` 指定参数。例如 `java -Dspring.application.json='{"name":"Java"}' -jar springboot.jar` 。
+
+5. ServletConfig 初始化参数。
+
+6. ServletContext 初始化参数。
+
+7. JNDI 参数。例如 `java:comp/env` 。
+
+8. Java 系统变量，即 `System#getProperties()` 方法对应的。
+
+9. 操作系统环境变量。
+
+10. RandomValuePropertySource 配置的 `random.*` 属性对应的值。
+
+11. Jar **外部**的带指定 profile 的 application 配置文件。例如 `application-{profile}.yaml` 。
+
+12. Jar **内部**的带指定 profile 的 application 配置文件。例如 `application-{profile}.yaml` 。
+
+13. Jar **外部** application 配置文件。例如 `application.yaml` 。
+
+14. Jar **内部** application 配置文件。例如 `application.yaml` 。
+
+15. 在自定义的 `@Configuration` 类中定于的 `@PropertySource` 。
+
+16. 启动的 main 方法中，定义的默认配置。即通过 `SpringApplication#setDefaultProperties(Map<String, Object> defaultProperties)` 方法进行设置。
+
+嘿嘿，是不是很多很长，不用真的去记住。
+
+- 一般来说，面试官不会因为这个题目回答的不好，对你扣分。
+- 实际使用时，做下测试即可。
+- 每一种配置方式的详细说明，可以看看 [《Spring Boot 参考指南（外部化配置）》](https://segmentfault.com/a/1190000015069140) 。
+
+## Spring Boot 有哪些配置方式？
+
+和 Spring 一样，一共提供了三种方式。
+
+- 1、XML 配置文件。
+
+  Bean 所需的依赖项和服务在 XML 格式的配置文件中指定。这些配置文件通常包含许多 bean 定义和特定于应用程序的配置选项。它们通常以 bean 标签开头。例如：
+
+  ```
+  <bean id="studentBean" class="org.edureka.firstSpring.StudentBean">
+      <property name="name" value="Edureka"></property>
+  </bean>
+  ```
+
+- 2、注解配置。
+
+  您可以通过在相关的类，方法或字段声明上使用注解，将 Bean 配置为组件类本身，而不是使用 XML 来描述 Bean 装配。默认情况下，Spring 容器中未打开注解装配。因此，您需要在使用它之前在 Spring 配置文件中启用它。例如：
+
+  ```
+  <beans>
+  <context:annotation-config/>
+  <!-- bean definitions go here -->
+  </beans>
+  ```
+
+- 3、Java Config 配置。
+
+  Spring 的 Java 配置是通过使用 @Bean 和 @Configuration 来实现。
+
+  - `@Bean` 注解扮演与 `<bean />` 元素相同的角色。
+
+  - `@Configuration` 类允许通过简单地调用同一个类中的其他 `@Bean` 方法来定义 Bean 间依赖关系。
+
+  - 例如：
+
+    ```
+    @Configuration
+    public class StudentConfig {
+        
+        @Bean
+        public StudentBean myStudent() {
+            return new StudentBean();
+        }
+        
+    }
+    ```
+
+    - 是不是很熟悉 😈
+
+目前主要使用 **Java Config** 配置为主。当然，三种配置方式是可以混合使用的。例如说：
+
+- Dubbo 服务的配置，艿艿喜欢使用 XML 。
+- Spring MVC 请求的配置，艿艿喜欢使用 `@RequestMapping` 注解。
+- Spring MVC 拦截器的配置，艿艿喜欢 Java Config 配置。
+
+------
+
+另外，现在已经是 Spring Boot 的天下，所以更加是 **Java Config** 配置为主。
+
+## Spring Boot 的核心注解是哪个？
+
+```
+package cn.iocoder.skywalking.web01;
+
+import org.springframework.boot.SpringApplication;
+import org.springframework.boot.autoconfigure.SpringBootApplication;
+
+@SpringBootApplication
+public class Web01Application {
+
+    public static void main(String[] args) {
+        SpringApplication.run(Web01Application.class, args);
+    }
+
+}
+```
+
+- `@SpringBootApplication` 注解，就是 Spring Boot 的核心注解。
+
+`org.springframework.boot.autoconfigure.@SpringBootApplication` 注解的代码如下：
+
+```
+// SpringBootApplication.java
+
+@Target({ElementType.TYPE})
+@Retention(RetentionPolicy.RUNTIME)
+@Documented
+@Inherited
+@SpringBootConfiguration
+@EnableAutoConfiguration
+@ComponentScan(
+    excludeFilters = {@Filter(
+    type = FilterType.CUSTOM,
+    classes = {TypeExcludeFilter.class}
+), @Filter(
+    type = FilterType.CUSTOM,
+    classes = {AutoConfigurationExcludeFilter.class}
+)}
+)
+public @interface SpringBootApplication {
+    @AliasFor(
+        annotation = EnableAutoConfiguration.class
+    )
+    Class<?>[] exclude() default {};
+
+    @AliasFor(
+        annotation = EnableAutoConfiguration.class
+    )
+    String[] excludeName() default {};
+
+    @AliasFor(
+        annotation = ComponentScan.class,
+        attribute = "basePackages"
+    )
+    String[] scanBasePackages() default {};
+
+    @AliasFor(
+        annotation = ComponentScan.class,
+        attribute = "basePackageClasses"
+    )
+    Class<?>[] scanBasePackageClasses() default {};
+}
+```
+
+- 它组合了 3 个注解，详细说明，胖友看看 [《Spring Boot 系列：@SpringBootApplication 注解》](https://blog.csdn.net/claram/article/details/75125749) 。
+
+- `@Configuration` 注解，指定类是 **Bean 定义**的配置类。
+
+  > `@Configuration` 注解，来自 `spring-context` 项目，用于 Java Config ，不是 Spring Boot 新带来的。
+
+- `#ComponentScan` 注解，扫描指定包下的 Bean 们。
+
+  > `@ComponentScan` 注解，来自 `spring-context` 项目，用于 Java Config ，不是 Spring Boot 新带来的。
+
+- `@EnableAutoConfiguration` 注解，打开自动配置的功能。如果我们想要关闭某个类的自动配置，可以设置注解的 `exclude` 或 `excludeName` 属性。
+
+  > `@EnableAutoConfiguration` 注解，来自 `spring-boot-autoconfigure` 项目，**它才是 Spring Boot 新带来的**。
+
+## 什么是 Spring Boot 自动配置？
+
+在 [「Spring Boot 的核心注解是哪个？」](https://svip.iocoder.cn/Spring-Boot/Interview/#) 中，我们已经看到，使用 `@@EnableAutoConfiguration` 注解，打开 Spring Boot 自动配置的功能。具体如何实现的，可以看看如下两篇文章：
+
+- [《@EnableAutoConfiguration 注解的工作原理》](https://www.jianshu.com/p/464d04c36fb1) 。
+- [《一个面试题引起的 Spring Boot 启动解析》](https://juejin.im/post/5b679fbc5188251aad213110)
+- 建议，能一边调试，一边看这篇文章。调试很简单，任一搭建一个 Spring Boot 项目即可。
+
+如下是一个比较简单的总结：
+
+1. Spring Boot 在启动时扫描项目所依赖的 jar 包，寻找包含`spring.factories` 文件的 jar 包。
+2. 根据 `spring.factories` 配置加载 AutoConfigure 类。
+3. 根据 [`@Conditional` 等条件注解](https://svip.iocoder.cn/Spring-Boot/Interview/Spring Boot 条件注解) 的条件，进行自动配置并将 Bean 注入 Spring IoC 中。
+
+## Spring Boot 有哪几种读取配置的方式？
+
+Spring Boot 目前支持 **2** 种读取配置：
+
+1. `@Value` 注解，读取配置到属性。最最最常用。
+
+   > 另外，支持和 `@PropertySource` 注解一起使用，指定使用的配置文件。
+
+2. `@ConfigurationProperties` 注解，读取配置到类上。
+
+   > 另外，支持和 `@PropertySource` 注解一起使用，指定使用的配置文件。
+
+详细的使用方式，可以参考 [《Spring Boot 读取配置的几种方式》](https://aoyouzi.iteye.com/blog/2422837) 。
+
+## 使用 Spring Boot 后，项目结构是怎么样的呢？
+
+我们先来说说项目的分层。一般来说，主流的有两种方式：
+
+- 方式一，`controller`、`service`、`dao` 三个包，每个包下面添加相应的 XXXController、YYYService、ZZZDAO 。
+- 方式二，按照业务模块分包，每个包里面放 Controller、Service、DAO 类。例如，业务模块分成 `user`、`order`、`item` 等等包，在 `user` 包里放 UserController、UserService、UserDAO 类。
+
+那么，使用 Spring Boot 的项目怎么分层呢？艿艿自己的想法
+
+- 现在项目都会进行服务化分拆，每个项目不会特别复杂，所以建议使用【方式一】。
+- 以前的项目，大多是单体的项目，动则项目几万到几十万的代码，当时多采用【方式二】。
+
+下面是一个简单的 Spring Boot 项目的 Demo ，如下所示：[![Spring Boot 项目的 Demo](01-Spring Boot 面试题.assets/05.png)](http://static.iocoder.cn/images/Spring/2018-12-26/05.png)Spring Boot 项目的 Demo
+
+## 如何在 Spring Boot 启动的时候运行一些特殊的代码？
+
+如果需要在 SpringApplication 启动后执行一些特殊的代码，你可以实现 ApplicationRunner 或 CommandLineRunner 接口，这两个接口工作方式相同，都只提供单一的 run 方法，该方法仅在 `SpringApplication#run(...)` 方法**完成之前调用**。
+
+一般情况下，我们不太会使用该功能。如果真需要，胖友可以详细看看 [《使用 ApplicationRunner 或 CommandLineRunner 》](https://qbgbook.gitbooks.io/spring-boot-reference-guide-zh/IV. Spring Boot features/23.8 Using the ApplicationRunner or CommandLineRunner.html) 。
+
+## Spring Boot 2.X 有什么新特性？
+
+1. 起步 JDK 8 和支持 JDK 9
+2. 第三方库的升级
+3. Reactive Spring
+4. HTTP/2 支持
+5. 配置属性的绑定
+6. Gradle 插件
+7. Actuator 改进
+8. 数据支持的改进
+9. Web 的改进
+10. 支持 Quartz 自动配置
+11. 测试的改进
+12. 其它…
+
+详细的说明，可以看看 [《Spring Boot 2.0系列文章(二)：Spring Boot 2.0 新特性详解》](http://www.54tianzhisheng.cn/2018/03/06/SpringBoot2-new-features) 。
+
+# 整合篇
+
+## 如何将内嵌服务器换成 Jetty ？
+
+默认情况下，`spring-boot-starter-web` 模块使用 Tomcat 作为内嵌的服务器。所以需要去除对 `spring-boot-starter-tomcat` 模块的引用，添加 `spring-boot-starter-jetty` 模块的引用。代码如下：
+
+```
+<dependency>
+    <groupId>org.springframework.boot</groupId>
+    <artifactId>spring-boot-starter-web</artifactId>
+    <exclusions>
+        <exclusion> <!-- 去除 Tomcat -->
+            <groupId>org.springframework.boot</groupId>
+            <artifactId>spring-boot-starter-tomcat</artifactId>
+        </exclusion>
+    </exclusions>
+</dependency>
+<dependency> <!-- 引入 Jetty -->
+    <groupId>org.springframework.boot</groupId>
+    <artifactId>spring-boot-starter-jetty</artifactId>
+</dependency>
+```
+
+## Spring Boot 中的监视器 Actuator 是什么？
+
+`spring-boot-actuator` 提供 Spring Boot 的监视器功能，可帮助我们访问生产环境中正在运行的应用程序的**当前状态**。
+
+- 关于 Spring Boot Actuator 的教程，可以看看 [《Spring Boot Actuator 使用》](https://www.jianshu.com/p/af9738634a21) 。
+- 上述教程是基于 Spring Boot 1.X 的版本，如果胖友使用 Spring Boot 2.X 的版本，你将会发现 `/beans` 等 Endpoint 是不存在的，参考 [《Spring boot 2 - Actuator endpoint, where is /beans endpoint》](https://stackoverflow.com/questions/49174700/spring-boot-2-actuator-endpoint-where-is-beans-endpoint) 问题来解决。
+
+**安全性**
+
+Spring Boot 2.X 默认情况下，`spring-boot-actuator` 产生的 Endpoint 是没有安全保护的，但是 Actuator 可能暴露敏感信息。
+
+所以一般的做法是，引入 `spring-boot-start-security` 依赖，使用 Spring Security 对它们进行安全保护。
+
+## 如何集成 Spring Boot 和 Spring MVC ？
+
+1. 引入 `spring-boot-starter-web` 的依赖。
+
+2. 实现 WebMvcConfigurer 接口，可添加自定义的 Spring MVC 配置。
+
+   > 因为 Spring Boot 2 基于 JDK 8 的版本，而 JDK 8 提供 `default` 方法，所以 Spring Boot 2 废弃了 WebMvcConfigurerAdapter 适配类，直接使用 WebMvcConfigurer 即可。
+
+   ```
+   // WebMvcConfigurer.java
+   public interface WebMvcConfigurer {
+   
+       /** 配置路径匹配器 **/
+       default void configurePathMatch(PathMatchConfigurer configurer) {}
+       
+       /** 配置内容裁决的一些选项 **/
+       default void configureContentNegotiation(ContentNegotiationConfigurer configurer) { }
+   
+       /** 异步相关的配置 **/
+       default void configureAsyncSupport(AsyncSupportConfigurer configurer) { }
+   
+       default void configureDefaultServletHandling(DefaultServletHandlerConfigurer configurer) { }
+   
+       default void addFormatters(FormatterRegistry registry) {
+       }
+   
+       /** 添加拦截器 **/
+       default void addInterceptors(InterceptorRegistry registry) { }
+   
+       /** 静态资源处理 **/
+       default void addResourceHandlers(ResourceHandlerRegistry registry) { }
+   
+       /** 解决跨域问题 **/
+       default void addCorsMappings(CorsRegistry registry) { }
+   
+       default void addViewControllers(ViewControllerRegistry registry) { }
+   
+       /** 配置视图解析器 **/
+       default void configureViewResolvers(ViewResolverRegistry registry) { }
+   
+       /** 添加参数解析器 **/
+       default void addArgumentResolvers(List<HandlerMethodArgumentResolver> resolvers) {
+       }
+   
+       /** 添加返回值处理器 **/
+       default void addReturnValueHandlers(List<HandlerMethodReturnValueHandler> handlers) { }
+   
+       /** 这里配置视图解析器 **/
+       default void configureMessageConverters(List<HttpMessageConverter<?>> converters) { }
+   
+       /** 配置消息转换器 **/
+       default void extendMessageConverters(List<HttpMessageConverter<?>> converters) { }
+   
+      /** 配置异常处理器 **/
+       default void configureHandlerExceptionResolvers(List<HandlerExceptionResolver> resolvers) { }
+   
+       default void extendHandlerExceptionResolvers(List<HandlerExceptionResolver> resolvers) { }
+   
+       @Nullable
+       default Validator getValidator() { return null; }
+   
+       @Nullable
+       default MessageCodesResolver getMessageCodesResolver() {  return null; }
+   
+   }
+   ```
+
+------
+
+在使用 Spring MVC 时，我们一般会做如下几件事情：
+
+1. 实现自己项目需要的拦截器，并在 WebMvcConfigurer 实现类中配置。可参见 [MVCConfiguration](https://github.com/YunaiV/oceans/blob/2a2d3746905f1349e260e88049e7e28346c7648f/bff/webapp-bff/src/main/java/cn/iocoder/oceans/webapp/bff/config/MVCConfiguration.java) 类。
+2. 配置 `@ControllerAdvice` + `@ExceptionHandler` 注解，实现全局异常处理。可参见 [GlobalExceptionHandler](https://github.com/YunaiV/oceans/blob/2a2d3746905f1349e260e88049e7e28346c7648f/bff/webapp-bff/src/main/java/cn/iocoder/oceans/webapp/bff/config/GlobalExceptionHandler.java) 类。
+3. 配置 `@ControllerAdvice` ，实现 ResponseBodyAdvice 接口，实现全局统一返回。可参见 [GlobalResponseBodyAdvice](https://github.com/YunaiV/oceans/blob/2a2d3746905f1349e260e88049e7e28346c7648f/bff/webapp-bff/src/main/java/cn/iocoder/oceans/webapp/bff/config/GlobalResponseBodyAdvice.java) 。
+
+当然，有一点需要注意，WebMvcConfigurer、ResponseBodyAdvice、`@ControllerAdvice`、`@ExceptionHandler` 接口，都是 Spring MVC 框架自身已经有的东西。
+
+- `spring-boot-starter-web` 的依赖，帮我们解决的是 Spring MVC 的依赖以及相关的 Tomcat 等组件。
+
+## 如何集成 Spring Boot 和 Spring Security ？
+
+目前比较主流的安全框架有两个：
+
+1. Spring Security
+2. Apache Shiro
+
+对于任何项目来说，安全认证总是少不了，同样适用于使用 Spring Boot 的项目。相对来说，Spring Security 现在会比 Apache Shiro 更流行。
+
+Spring Boot 和 Spring Security 的配置方式比较简单：
+
+1. 引入 `spring-boot-starter-security` 的依赖。
+2. 继承 WebSecurityConfigurerAdapter ，添加**自定义**的安全配置。
+
+当然，每个项目的安全配置是不同的，需要胖友自己选择。更多详细的使用，建议认真阅读如下文章：
+
+- [《Spring Boot中 使用 Spring Security 进行安全控制》](http://blog.didispace.com/springbootsecurity/) ，快速上手。
+- [《Spring Security 实现原理与源码解析系统 —— 精品合集》](http://www.iocoder.cn/Spring-Security/good-collection/) ，深入源码。
+
+另外，安全是一个很大的话题，感兴趣的胖友，可以看看 [《Spring Boot 十种安全措施》](https://www.jdon.com/49653) 一文。
+
+## 如何集成 Spring Boot 和 Spring Security OAuth2 ？
+
+参见 [《Spring Security OAuth2 入门》](http://www.iocoder.cn/Spring-Security/OAuth2-learning/) 文章，内容有点多。
+
+## 如何集成 Spring Boot 和 JPA ？
+
+1. 引入 `spring-boot-starter-data-jpa` 的依赖。
+2. 在 application 配置文件中，加入 JPA 相关的少量配置。当然，数据库的配置也要添加进去。
+3. 具体编码。
+
+详细的使用，胖友可以参考：
+
+- [《一起来学 SpringBoot 2.x | 第六篇：整合 Spring Data JPA》](http://www.iocoder.cn/Spring-Boot/battcn/v2-orm-jpa/)
+
+有两点需要注意：
+
+- Spring Boot 2 默认使用的数据库连接池是 [HikariCP](https://github.com/brettwooldridge/HikariCP) ，目前最好的性能的数据库连接池的实现。
+- `spring-boot-starter-data-jpa` 的依赖，使用的默认 JPA 实现是 Hibernate 5.X 。
+
+## 如何集成 Spring Boot 和 MyBatis ？
+
+1. 引入 `mybatis-spring-boot-starter` 的依赖。
+2. 在 application 配置文件中，加入 MyBatis 相关的少量配置。当然，数据库的配置也要添加进去。
+3. 具体编码。
+
+详细的使用，胖友可以参考：
+
+- [《一起来学 SpringBoot 2.x | 第七篇：整合 Mybatis》](http://www.iocoder.cn/Spring-Boot/battcn/v2-orm-mybatis/)
+
+## 如何集成 Spring Boot 和 RabbitMQ ？
+
+1. 引入 `spring-boot-starter-amqp` 的依赖
+2. 在 application 配置文件中，加入 RabbitMQ 相关的少量配置。
+3. 具体编码。
+
+详细的使用，胖友可以参考：
+
+- [《一起来学 SpringBoot 2.x | 第十二篇：初探 RabbitMQ 消息队列》](http://www.iocoder.cn/Spring-Boot/battcn/v2-queue-rabbitmq/)
+- [《一起来学 SpringBoot 2.x | 第十三篇：RabbitMQ 延迟队列》](http://www.iocoder.cn/Spring-Boot/battcn/v2-queue-rabbitmq-delay/)
+
+## 如何集成 Spring Boot 和 Kafka ？
+
+1. 引入 `spring-kafka` 的依赖。
+2. 在 application 配置文件中，加入 Kafka 相关的少量配置。
+3. 具体编码。
+
+详细的使用，胖友可以参考：
+
+- [《Spring Boot系列文章（一）：SpringBoot Kafka 整合使用》](http://www.54tianzhisheng.cn/2018/01/05/SpringBoot-Kafka/)
+
+## 如何集成 Spring Boot 和 RocketMQ ？
+
+1. 引入 `rocketmq-spring-boot` 的依赖。
+2. 在 application 配置文件中，加入 RocketMQ 相关的少量配置。
+3. 具体编码。
+
+详细的使用，胖友可以参考：
+
+- [《我用这种方法在 Spring 中实现消息的发送和消费》](http://www.iocoder.cn/RocketMQ/start/spring-boot-example)
+
+## Spring Boot 支持哪些日志框架？
+
+Spring Boot 支持的日志框架有：
+
+- Logback
+- Log4j2
+- Log4j
+- Java Util Logging
+
+默认使用的是 Logback 日志框架，也是目前较为推荐的，具体配置，可以参见 [《一起来学 SpringBoot 2.x | 第三篇：SpringBoot 日志配置》](http://www.iocoder.cn/Spring-Boot/battcn/v2-config-logs/) 。
+
+因为 Log4j2 的性能更加优秀，也有人在生产上使用，可以参考 [《Spring Boot Log4j2 日志性能之巅》](https://www.jianshu.com/p/f18a9cff351d) 配置。
+
+# 666. 彩蛋
+
+😈 看完之后，复习复习 Spring Boot 美滋滋。有一种奇怪的感觉，把面试题写成了 Spring 的学习指南。
+
+当然，如果胖友有新的面试题，欢迎在星球一起探讨补充。
+
+参考和推荐如下文章：
+
+- 我有面试宝典 [《[经验分享\] Spring Boot面试题总结》](http://www.wityx.com/post/242_1_1.html)
+- Java 知音 [《Spring Boot 面试题精华》](https://cloud.tencent.com/developer/article/1348086)
+- 祖大帅 [《一个面试题引起的 Spring Boot 启动解析》](https://juejin.im/post/5b679fbc5188251aad213110)
+- 大胡子叔叔_ [《Spring Boot + Spring Cloud 相关面试题》](https://blog.csdn.net/panhaigang123/article/details/79587612)
+- 墨斗鱼博客 [《20 道 Spring Boot 面试题》](https://www.mudouyu.com/article/26)
+- 夕阳雨晴 [《Spring Boot Starter 的面试题》](https://blog.csdn.net/sun1021873926/article/details/78176354)
\ No newline at end of file
diff --git a/springboot/02-Spring Boot 学习指南.md b/springboot/02-Spring Boot 学习指南.md
new file mode 100644
index 0000000..e59077f
--- /dev/null
+++ b/springboot/02-Spring Boot 学习指南.md	
@@ -0,0 +1,172 @@
+# 精尽 Spring Boot 学习指南
+
+# 1. 视频
+
+- [《Spring Boot 视频教程全集》](https://www.bilibili.com/video/av59572480/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 本视频分成 A/B 两部分。
+  >
+  > - A 部分（核心技术篇） P01-P72
+  >
+  >   着重介绍SpringBoot的使用和内部原理；内容包含微服务概念、配置文件、日志框架的使用、web开发、Thymeleaf模板引擎、Docker容器技术、MyBatis、Spring Data JPA、自定义starter等；
+  >
+  > - B 部分（整合篇） P73-P112
+  >
+  >   着重介绍SpringBoot的与各大场景的整合使用，内容包括：缓存（整合Redis），消息中间件（整合RabbitMQ），检索（整合ElasticSearch），任务（异步任务，定时任务，邮件任务），安全（整合SpringSecurity），分布式（Zookeeper/dubbo，整合SpringCloud），SpringBoot应用监管；
+
+- 龙虾三少 [《Spring Boot 构建电商基础秒杀项目》](https://www.imooc.com/learn/1079) 6 小时，貌似还没录制完，优点在于相对项目实战。
+
+- 风间影月 [《Spring Boot 微信小程序 – 微信登录功能实战》](https://www.imooc.com/learn/1059) 54 分钟，现在大部分互联网公司都有小程序，不然都不好意思出来混了。
+
+- 风间影月 [《Spring Boot 开发常用技术整合》](https://www.imooc.com/learn/956) 2 小时 45 分钟，虽然不长，覆盖了Spring Boot 最常用的部分。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+不过艿艿还是要提醒下大家，Spring Boot 给大家便捷的开发方式，但是也可能带走大家对 Spring 深入了解的机会。当然，如果真的是这样，错的不是工具，而是我们。我们在获得便捷的同时，需要把这部分节省的时间，用心继续去学习~
+
+# 2. 书籍
+
+[《Spring Boot 书单整理》](http://www.iocoder.cn/Books/Spring-Boot-books-recommended)
+
+看了一圈市面上的 Spring Boot 相关的书籍，貌似评价暂时没有特别合适的书籍推荐。目前感觉下来，还是 [《Spring Boot 揭秘》](https://union-click.jd.com/jdc?d=Ym8Bu8) 不错一些。
+
+# 3. 文章
+
+## 打好基础
+
+- [《芋道 Spring Boot 快速入门》](http://www.iocoder.cn/Spring-Boot/quick-start/?vip)
+- [《芋道 Spring Boot 自动配置原理》](http://www.iocoder.cn/Spring-Boot/autoconfigure/?vip) 对应 [lab-47](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-47)
+- [《芋道 Spring Boot Jar 启动原理》](http://www.iocoder.cn/Spring-Boot/jar/?vip)
+
+## 开发工具
+
+- [《芋道 Spring Boot 热部署入门》](http://www.iocoder.cn/Spring-Boot/hot-swap/?vip) 对应 [lab-48-hot-swap](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-48-hot-swap)
+- [《芋道 Spring Boot 消除冗余代码 Lombok 入门》](http://www.iocoder.cn/Spring-Boot/Lombok/?vip) 对应 [lab-49](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-49)
+- [《芋道 Spring Boot 对象转换 MapStruct 入门》](http://www.iocoder.cn/Spring-Boot/MapStruct/?vip) 对应 [lab-55](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-55)
+
+## Web 开发
+
+- [《芋道 Spring Boot SpringMVC 入门》](http://www.iocoder.cn/Spring-Boot/SpringMVC/?vip) 对应 [lab-23](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-23)
+- [《芋道 Spring Boot WebFlux 入门》](http://www.iocoder.cn/Spring-Boot/WebFlux/?vip) 对应 [lab-27](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-27)
+- [《芋道 Spring Boot 分布式 Session 入门》](http://www.iocoder.cn/Spring-Boot/Distributed-Session/?vip) 对应 [lab-26](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-26)
+- [《芋道 Spring Boot API 接口文档 Swagger 入门》](http://www.iocoder.cn/Spring-Boot/Swagger/?vip) 对应 [lab-24](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-24)
+- [《芋道 Spring Boot API 接口文档 Swagger Starter 入门》](http://www.iocoder.cn/Spring-Boot/Swagger-Starter/?vip) 对应 [lab-24](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-24)
+- [《芋道 Spring Boot 参数校验 Validation 入门》](http://www.iocoder.cn/Spring-Boot/Validation/?vip) 对应 [lab-22](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-22)
+- [《芋道 Spring Boot WebSocket 入门》](http://www.iocoder.cn/Spring-Boot/WebSocket/?vip) 对应 [lab-25](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-25)
+- [《芋道 Spring Boot API 接口文档 JApiDocs 入门》](http://www.iocoder.cn/Spring-Boot/JApiDocs/?vip) 对应 [lab-24](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-24)
+- [《芋道 Spring Boot API 接口文档 ShowDoc 入门》](http://www.iocoder.cn/Spring-Boot/ShowDoc/?vip) 对应 [lab-24](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-24)
+- [《芋道 Spring Boot API 接口调试 IDEA HTTP Client》](http://www.iocoder.cn/Spring-Boot/IDEA-HTTP-Client/?vip) 对应 [lab-71-http-debug](https://github.com/YunaiV/SpringBoot-Labs/blob/master/lab-71-http-debug/)
+
+## 文件存储
+
+- [《芋道 Spring Boot 对象存储 MinIO 入门》](https://www.iocoder.cn/Spring-Boot/MinIO/?vip) 对应 [lab-72-minio](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-72-minio)
+
+## 数据访问
+
+**关系数据库**
+
+- [《芋道 Spring Boot 数据库连接池入门》](http://www.iocoder.cn/Spring-Boot/datasource-pool/?vip) 对应 [lab-19](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-19)
+- [《芋道 Spring Boot MyBatis 入门》](http://www.iocoder.cn/Spring-Boot/MyBatis/?vip) 对应 [lab-12-mybatis](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-12-mybatis)
+- [《芋道 Spring Boot JPA 入门》](http://www.iocoder.cn/Spring-Boot/JPA/?vip) 对应 [lab-13-spring-data-jpa](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-13-spring-data-jpa)
+- [《芋道 Spring Boot JdbcTemplate 入门》](http://www.iocoder.cn/Spring-Boot/JdbcTemplate/?vip) 对应 [lab-14-spring-jdbc-template](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-14-spring-jdbc-template)
+- [《芋道 Spring Boot 多数据源（读写分离）入门》](http://www.iocoder.cn/Spring-Boot/dynamic-datasource/?vip) 对应 [lab-17](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-17)
+- [《芋道 Spring Boot 分库分表入门》](http://www.iocoder.cn/Spring-Boot/sharding-datasource/?vip) 对应 [lab-18](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-18)
+- [《芋道 Spring Boot 数据库版本管理入门》](http://www.iocoder.cn/Spring-Boot/database-version-control/?vip) 对应 [lab-20](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-20)
+- [《芋道 Spring Boot 数据表结构文档》](http://www.iocoder.cn/Spring-Boot/DB-Doc-screw/?vip) 对应 [lab-70-db-doc](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-70-db-doc)
+
+**非关系数据库**
+
+- [《芋道 Spring Boot Redis 入门》](http://www.iocoder.cn/Spring-Boot/Redis/?vip) 对应 [lab-11-spring-data-redis](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-11-spring-data-redis)
+- [《芋道 Spring Boot 缓存 Cache 入门》](http://www.iocoder.cn/Spring-Boot/Cache/?vip) 对应 [lab-21](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-21)
+- [《芋道 Spring Boot MongoDB 入门》](http://www.iocoder.cn/Spring-Boot/MongoDB/?vip) 对应 [lab-16-spring-data-mongo](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-16-spring-data-mongo)
+- [《芋道 Spring Boot Elasticsearch 入门》](http://www.iocoder.cn/Spring-Boot/Elasticsearch/?vip) 对应 [lab-15](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-15)
+- [《芋道 Spring Boot Solr 入门》](http://www.iocoder.cn/Spring-Boot/Solr/?vip) 对应 [lab-66](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-66)
+
+## 事务管理
+
+- [《芋道 Spring Boot 分布式事务 Seata 入门》](http://www.iocoder.cn/Spring-Boot/Seata/?vip) 对应 [lab-52](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-52)
+
+## RPC 开发
+
+- [《芋道 Spring Boot Netty 入门》](http://www.iocoder.cn/Spring-Boot/Netty/?vip) 对应 [lab-67](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-67)
+- [《芋道 Spring Boot Dubbo 入门》](http://www.iocoder.cn/Spring-Boot/Dubbo/?vip) 对应 [lab-30](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-30)
+- [《芋道 Spring Boot 声明式调用 Feign 入门》](http://www.iocoder.cn/Spring-Boot/Feign/?vip) 对应 [lab-58](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-58)
+- [《芋道 Spring Boot gRPC 入门》](http://www.iocoder.cn/Spring-Boot/gRPC/?vip) 对应 [lab-64](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-64)
+- [《芋道 Spring Boot Web Services 入门》](http://www.iocoder.cn/Spring-Boot/Web-Services/?vip) 对应 [lab-65](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-65)
+- [《芋道 Spring Boot SOFARPC 入门》](http://www.iocoder.cn/Spring-Boot/SOFARPC/?vip) 对应 [lab-62](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-62)
+- [《芋道 Spring Boot Motan 入门》](http://www.iocoder.cn/Spring-Boot/Motan/?vip) 对应 [lab-63](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-63)
+- 《芋道 Spring Boot RSocket 入门》计划中…
+
+## 安全控制
+
+- [《芋道 Spring Boot 安全框架 Spring Security 入门》](http://www.iocoder.cn/Spring-Boot/Spring-Security/?vip) 对应 [lab-01-spring-security](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-01-spring-security)
+- [《芋道 Spring Boot 安全框架 Shiro 入门》](http://www.iocoder.cn/Spring-Boot/Shiro/?vip) 对应 [lab-33](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-33)
+
+**OAuth 2.0**
+
+- [《芋道 Spring Security OAuth2 入门》](http://www.iocoder.cn/Spring-Security/OAuth2-learning/?vip) 对应 [lab-68-spring-security-oauth](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-68-spring-security-oauth)
+- [《芋道 Spring Security OAuth2 存储器》](http://www.iocoder.cn/Spring-Security/OAuth2-learning-store/?vip) 对应 [lab-68-spring-security-oauth](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-68-spring-security-oauth)
+- [《芋道 Spring Security OAuth2 单点登陆》](http://www.iocoder.cn/Spring-Security/OAuth2-learning-sso/?vip) 对应 [lab-68-spring-security-oauth](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-68-spring-security-oauth)
+
+## 定时任务与异步任务
+
+- [《芋道 Spring Boot 定时任务入门》](http://www.iocoder.cn/Spring-Boot/Job/?vip) 对应 [lab-28](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-28)
+- [《芋道 Spring Boot 异步任务入门》](http://www.iocoder.cn/Spring-Boot/Async-Job/?vip) 对应 [lab-29](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-29)
+
+## 消息队列
+
+- [《芋道 Spring Boot 消息队列 RocketMQ 入门》](http://www.iocoder.cn/Spring-Boot/RocketMQ/?vip) 对应 [lab-31](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-31)
+- [《芋道 Spring Boot 消息队列 Kafka 入门》](http://www.iocoder.cn/Spring-Boot/Kafka/?vip) 对应 [lab-03-kafka](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-03-kafka)
+- [《芋道 Spring Boot 消息队列 RabbitMQ 入门》](http://www.iocoder.cn/Spring-Boot/RabbitMQ/?vip) 对应 [lab-04-rabbitmq](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-04-rabbitmq)
+- [《芋道 Spring Boot 消息队列 ActiveMQ 入门》](http://www.iocoder.cn/Spring-Boot/ActiveMQ/?vip) 对应 [lab-32](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-32)
+- [《芋道 Spring Boot 事件机制 Event 入门》](http://www.iocoder.cn/Spring-Boot/Event/?vip) 对应 对应 [lab-54](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-54)
+
+## 配置中心
+
+- [《芋道 Spring Boot 配置文件入门》](http://www.iocoder.cn/Spring-Boot/config-file/?vip) 对应 [lab-43](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-43)
+- [《芋道 Spring Boot 配置中心 Apollo 入门》](http://www.iocoder.cn/Spring-Boot/config-apollo/?vip) 对应 [lab-45](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-45)
+- [《芋道 Spring Boot 配置中心 Nacos 入门》](http://www.iocoder.cn/Spring-Boot/config-nacos/?vip) 对应 [lab-44](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-44)
+
+## 注册中心
+
+- [《芋道 Spring Boot 注册中心 Nacos 入门》](http://www.iocoder.cn/Spring-Boot/registry-nacos/?vip) 对应 [lab-44](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-44)
+
+## 持续交付
+
+- [《芋道 Spring Boot 持续交付 Jenkins 入门》](http://www.iocoder.cn/Spring-Boot/Jenkins/?vip) 对应 [lab-41](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-41)
+- [《芋道 Spring Boot 单元测试 Test 入门》](http://www.iocoder.cn/Spring-Boot/Unit-Test/?vip) 对应 [lab-42](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-42)
+- 《芋道 Spring Boot 容器 Docker 入门》计划中…
+
+## 服务容错
+
+- [《芋道 Spring Boot 服务容错 Sentinel 入门》](http://www.iocoder.cn/Spring-Boot/Sentinel/?vip) 对应 [lab-46](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-46)
+- [《芋道 Spring Boot 服务容错 Hystrix 入门》](http://www.iocoder.cn/Spring-Boot/Hystrix/?vip) 对应 [lab-57](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-57)
+- [《芋道 Spring Boot 服务容错 Resilience4j 入门》](http://www.iocoder.cn/Spring-Boot/Resilience4j/?vip) 对应 [lab-59](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-59)
+
+## 监控管理
+
+- [《芋道 Spring Boot 监控端点 Actuator 入门》](http://www.iocoder.cn/Spring-Boot/Actuator/?vip) 对应 [lab-34](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-34)
+- [《芋道 Spring Boot 监控工具 Admin 入门》](http://www.iocoder.cn/Spring-Boot/Admin/?vip) 对应 [lab-35](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-35)
+- [《芋道 Spring Boot 监控平台 Prometheus + Grafana 入门》](http://www.iocoder.cn/Spring-Boot/Prometheus-and-Grafana/?vip) 对应 [lab-36](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-36)
+- [《芋道 Spring Boot 监控平台 CAT 入门》](http://www.iocoder.cn/Spring-Boot/CAT/?vip) 对应 [lab-61](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-61)
+
+## 日志管理
+
+- [《芋道 Spring Boot 日志集成 Logging 入门》](http://www.iocoder.cn/Spring-Boot/Logging/?vip) 对应 [lab-37](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-37)
+- [《芋道 Spring Boot 日志平台 ELK + Filebeat 入门》](http://www.iocoder.cn/Spring-Boot/ELK/?vip) 对应 [lab-38](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-38)
+
+## 链路追踪
+
+- [《芋道 Spring Boot 链路追踪 SkyWalking 入门》](http://www.iocoder.cn/Spring-Boot/SkyWalking/?vip) 对应 [lab-39](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-39)
+- [《芋道 Spring Boot 链路追踪 Zipkin 入门》](http://www.iocoder.cn/Spring-Boot/Zipkin/?vip) 对应 [lab-40](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-40)
+- 《芋道 Spring Boot 链路追踪 Pinpoint 入门》计划中…
+- 《芋道 Spring Boot 链路追踪 Elastic APM 入门》计划中…
+
+## 其它
+
+- [《Spring Boot 2.x 精品教程》](http://www.iocoder.cn/Spring-Boot/good-collection/)
+- [《给你一份 Spring Boot 知识清单》](http://www.iocoder.cn/Fight/Give-you-a-list-of-Spring-Boot-knowledge)
+
+如果胖友有看到合适的文章，也可以推荐给我哟。
\ No newline at end of file
diff --git a/springboot/03-Spring Boot 源码分析-调试环境搭建（Spring Boot 2.2.0 版本）.md b/springboot/03-Spring Boot 源码分析-调试环境搭建（Spring Boot 2.2.0 版本）.md
new file mode 100644
index 0000000..ee7b071
--- /dev/null
+++ b/springboot/03-Spring Boot 源码分析-调试环境搭建（Spring Boot 2.2.0 版本）.md	
@@ -0,0 +1,88 @@
+# 精尽 Spring Boot 源码分析 —— 调试环境搭建（Spring Boot 2.2.0 版本）
+
+# 1. 依赖工具
+
+- Maven
+
+  > 终于不用是 Spring 所使用的 Gradle 构建工具了。痛苦了一堆人。哈哈哈哈。
+
+- Git
+
+- JDK8+
+
+  > 艿艿自己使用的是 JDK11 。
+
+- IntelliJ IDEA
+
+- Kotlin
+
+  > 这个 IDEA 自带插件。有点记不清楚了。先无视，继续往下跑。如果碰到什么问题，星球给艿艿留言。
+
+笔者目前使用的系统版本是 macOS Mojave 10.14 。所以，如果胖友是 Windows 环境，胖到一些问题，请在星球给我留言。
+
+> 如果胖友真的搭建不起来，建议可以先新建一个项目，搭建一个 Spring Boot Demo 来调试。
+>
+> 😈 总之，我们的目的是，一定一定一定要调试。酱紫，才能更好的阅读 Spring Boot 的代码。
+
+# 2. 源码拉取
+
+从官方仓库 https://github.com/spring-projects/spring-boot `Fork` 出属于自己的仓库。
+
+- 为什么要 `Fork` ？既然开始阅读、调试源码，我们可能会写一些注释，有了自己的仓库，可以进行自由的提交。😈
+- 本文使用的 Spring 版本为 `2.2.0.BUILD-SNAPSHOT` 。
+- 使用 `IntelliJ IDEA` 从 `Fork` 出来的仓库拉取代码。因为 Spring 项目比较大，从仓库中拉取代码的时间会比较长。
+
+拉取完成后，Maven 会开始自动 **Build** 项目。因为 Build 的过程中，会下载非常多的依赖，请耐心等待。
+
+> 艿艿：这个时间，真的有点久啊。建议做两件事情：
+>
+> - 1、IDEA 的 Maven 使用自己本地装的 Maven 。
+> - 2、Maven 记得使用阿里云的 Maven 仓库。
+
+# 3. 直接运行
+
+没错！正如标题所说，无需任何配置，就直接开始调试 Spring Boot 项目。开心不开心🙂 。我们来打开 `spring-boot-hibernate52-tests` 项目的 Hibernate52Application 类，直接右键 Debug 运行 `#main(String[] args)` 方法即可。
+
+# 4. 拓展阅读
+
+实际上，截止 [「3. 直接运行」](https://svip.iocoder.cn/Spring-Boot/build-debugging-environment/#) 小节，我们已经能够愉快的调试。但是，我们是一个热爱折腾的人，所以又做了点点事情。
+
+## 4.1 解决 pom 的报错
+
+在根目录的 `pom.xml` 中，会看到 `${disable.checks}` 报错。它是用来配置，是否开启 Maven 代码检查的插件。因为，我们目的是为了调试代码，所以自然是去禁用它。仅仅需要在 `pom.xml` 配置如下：
+
+```
+<properties>
+	<revision>2.2.0.BUILD-SNAPSHOT</revision>
+	<main.basedir>${basedir}</main.basedir>
+	<disable.checks>true</disable.checks> <!--我是被新增的-->
+</properties>
+```
+
+## 4.2 搭建 Spring Boot MVC 调试环境
+
+搭建一个 Spring Boot MVC 环境，想必胖友已经炉火纯青。所以呢，艿艿就不装比献丑了。
+
+> 旁白君：不要脸，其实想偷懒。
+
+如下是艿艿搭建的代码，胖友可以简单瞅瞅 [Spring Boot MVC 调试示例](https://github.com/YunaiV/spring-boot/blob/74690873857801615f1bf404c229a29986b96238/spring-boot-tests/spring-boot-yunai-tests/spring-boot-yunai-mvc-tests/pom.xml) 。
+
+## 4.3 更多示例
+
+在 `spring-boot-samples` 项目下，提供了大量的 Spring Boot 和各种框架集成的示例。默认情况下，根 `pom.xml` 并未包含它们。如果我们想将它引入，只需在 IDEA 里，将 Maven Profile 增加 `m2e` 选项即可。
+
+但是，因为 `spring-boot-samples` 提供的示例实在实在太多，会导致我们的 Maven 报 GC overhead limit exceeded ，并且 Maven 解决依赖时间巨长。所以呢，我们可以在 `spring-boot-samples-invoker` 项目下，引入自己感兴趣的项目。例如：
+
+```
+<modules>
+    <module>../spring-boot-samples/spring-boot-sample-undertow</module>
+</modules>
+```
+
+# 666. 彩蛋
+
+笔者开始更新 Spring Boot 源码解析系列，让我们在 2019 一起**精尽** Spring Boot 。
+
+啥也不唠了，撸起袖子。
+
+以德服人，不服就干。
\ No newline at end of file
diff --git a/springboot/04-Spring Boot 源码分析-调试环境搭建（Spring Boot 2.6.0 版本）.assets/Spring Boot 示例.png b/springboot/04-Spring Boot 源码分析-调试环境搭建（Spring Boot 2.6.0 版本）.assets/Spring Boot 示例.png
new file mode 100644
index 0000000..e22c593
Binary files /dev/null and b/springboot/04-Spring Boot 源码分析-调试环境搭建（Spring Boot 2.6.0 版本）.assets/Spring Boot 示例.png differ
diff --git a/springboot/04-Spring Boot 源码分析-调试环境搭建（Spring Boot 2.6.0 版本）.assets/下载 Gradle 工具.png b/springboot/04-Spring Boot 源码分析-调试环境搭建（Spring Boot 2.6.0 版本）.assets/下载 Gradle 工具.png
new file mode 100644
index 0000000..02fc2da
Binary files /dev/null and b/springboot/04-Spring Boot 源码分析-调试环境搭建（Spring Boot 2.6.0 版本）.assets/下载 Gradle 工具.png differ
diff --git a/springboot/04-Spring Boot 源码分析-调试环境搭建（Spring Boot 2.6.0 版本）.assets/下载依赖.png b/springboot/04-Spring Boot 源码分析-调试环境搭建（Spring Boot 2.6.0 版本）.assets/下载依赖.png
new file mode 100644
index 0000000..298e70b
Binary files /dev/null and b/springboot/04-Spring Boot 源码分析-调试环境搭建（Spring Boot 2.6.0 版本）.assets/下载依赖.png differ
diff --git a/springboot/04-Spring Boot 源码分析-调试环境搭建（Spring Boot 2.6.0 版本）.assets/下载依赖2.png b/springboot/04-Spring Boot 源码分析-调试环境搭建（Spring Boot 2.6.0 版本）.assets/下载依赖2.png
new file mode 100644
index 0000000..49087da
Binary files /dev/null and b/springboot/04-Spring Boot 源码分析-调试环境搭建（Spring Boot 2.6.0 版本）.assets/下载依赖2.png differ
diff --git a/springboot/04-Spring Boot 源码分析-调试环境搭建（Spring Boot 2.6.0 版本）.assets/打上断点.png b/springboot/04-Spring Boot 源码分析-调试环境搭建（Spring Boot 2.6.0 版本）.assets/打上断点.png
new file mode 100644
index 0000000..e22c593
Binary files /dev/null and b/springboot/04-Spring Boot 源码分析-调试环境搭建（Spring Boot 2.6.0 版本）.assets/打上断点.png differ
diff --git a/springboot/04-Spring Boot 源码分析-调试环境搭建（Spring Boot 2.6.0 版本）.assets/调试 Spring Boot.gif b/springboot/04-Spring Boot 源码分析-调试环境搭建（Spring Boot 2.6.0 版本）.assets/调试 Spring Boot.gif
new file mode 100644
index 0000000..26f7e80
Binary files /dev/null and b/springboot/04-Spring Boot 源码分析-调试环境搭建（Spring Boot 2.6.0 版本）.assets/调试 Spring Boot.gif differ
diff --git a/springboot/04-Spring Boot 源码分析-调试环境搭建（Spring Boot 2.6.0 版本）.md b/springboot/04-Spring Boot 源码分析-调试环境搭建（Spring Boot 2.6.0 版本）.md
new file mode 100644
index 0000000..80fe17e
--- /dev/null
+++ b/springboot/04-Spring Boot 源码分析-调试环境搭建（Spring Boot 2.6.0 版本）.md	
@@ -0,0 +1,100 @@
+# 精尽 Spring Boot 源码分析 —— 调试环境搭建（Spring Boot 2.6.0 版本）
+
+> 友情提示：如果胖友对 Spring Boot 的使用不是很了解，可以看看艿艿写的 https://github.com/YunaiV/SpringBoot-Labs 系列文章，大概有 **100+** 个 Spring Boot 使用案例。
+
+今儿，我们来搭建一个 Spring Boot 调试环境，目标是：**启动 Spring Boot，成功调试它的启动过程**。
+
+视频可见 B 站：https://www.bilibili.com/video/BV1WA411P7Pz/
+
+😝 艿艿比较腼腆，大家给个三连支持一下，感恩 1024~
+
+# 1. 依赖工具
+
+## 1.1 IDEA
+
+当然是 Jetbrains 出品的 IDEA 工具，相信绝大多数胖友都使用的它。
+
+艿艿使用的是 **2020.3** 版本，胖友尽量保证不低于该版本哈。
+
+> 友情提示：如果不知道怎么激活 IDEA 的胖友，可以访问 [《IDEA 激活指南》](https://www.iocoder.cn/IDEA/idea-2020-reset-eval/) 地址，花 5 分钟学习！支持所有版本~
+
+## 1.2 JDK
+
+需要使用 JDK 编译 Spring Boot 的代码，这里艿艿使用的是 JDK **1.8** 版本
+
+```
+$ java -version
+java version "1.8.0_144"
+Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
+Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
+```
+
+# 2. 源码拉取
+
+使用 IDEA 从官方仓库 https://github.com/spring-projects/spring-boot 克隆项目。
+
+> 友情提示：如果网络不是很好的胖友，可以选择和艿艿一样，使用 Gitee 提供的镜像仓库 https://gitee.com/mirrors/spring-boot
+
+这里，我们使用的 Spring Boot 版本是 [**2.6.0-SNAPSHOT**](https://github.com/spring-projects/spring-boot/blob/main/gradle.properties#L1)。
+
+> 友情提示：胖友可以考虑 Fork 下[官方仓库](https://github.com/spring-projects/spring-boot)，为什么呢？
+>
+> 既然开始阅读、调试源码，我们可能会写一些注释，有了自己的仓库，可以进行自由的提交。😜
+
+# 3. 下载依赖
+
+① 克隆完成 Spring Boot 项目之后，IDEA 会自动下载需要的 Gradle 工具。如下图所示：
+
+[![下载 Gradle 工具](04-Spring Boot 源码分析-调试环境搭建（Spring Boot 2.6.0 版本）.assets/下载 Gradle 工具.png)](https://www.iocoder.cn/images/Spring-Boot/2021-01-02/下载 Gradle 工具.png)下载 Gradle 工具
+
+这里，我们使用的 Gradle 版本是 **6.9**。
+
+> 友情提示：由于是从国外的网址下载，所以需要耐心等待一会，艿艿花费了 2 分多钟。
+
+② 下载完 Gradle 工具之后，IDEA 就会使用它自动下载相关的依赖库。如下图所示：
+
+[![下载依赖](04-Spring Boot 源码分析-调试环境搭建（Spring Boot 2.6.0 版本）.assets/下载依赖.png)](https://www.iocoder.cn/images/Spring-Boot/2021-01-02/下载依赖.png)下载依赖
+
+因为 Gradle 支持使用 Maven 依赖，所以我们可以使用阿里云的 Maven 镜像 `https://maven.aliyun.com/nexus/content/groups/public/`**。修改 `build.gradle` 文件，如下图所示：
+
+[![下载依赖](04-Spring Boot 源码分析-调试环境搭建（Spring Boot 2.6.0 版本）.assets/下载依赖2.png)](https://www.iocoder.cn/images/Spring-Boot/2021-01-02/下载依赖2.png)下载依赖
+
+效果非常不错，不过艿艿还是花了 20 分钟才下载完了依赖。主要原因是，Spring Boot 内置了 50+ 个 Starter 的实现，导致引入了非常多的依赖。
+
+ps：如果中间下载失败，点击【绿色刷新】按钮，继续下载依赖即可。
+
+# 4. 调试 Spring Boot 示例
+
+依赖下载完后，我们通过调试 Spring Boot 提供的示例，了解 Spring Boot 的**启动过程**。在 `spring-boot-smoke-tests` 项目下，我们可以看到大量的示例，如下图所示：
+
+[![Spring Boot 示例](04-Spring Boot 源码分析-调试环境搭建（Spring Boot 2.6.0 版本）.assets/Spring Boot 示例.png)](https://www.iocoder.cn/images/Spring-Boot/2021-01-02/Spring Boot 示例.png)Spring Boot 示例
+
+这里，我们使用 `spring-boot-smoke-test-tomcat` 项目，最为熟悉的 Spring MVC + Tomcat 的组合。
+
+① 在 SampleTomcatApplication 和 SpringApplication 分别打上断点，如下图所示：
+
+[![打上断点](04-Spring Boot 源码分析-调试环境搭建（Spring Boot 2.6.0 版本）.assets/打上断点.png)](https://www.iocoder.cn/images/Spring-Boot/2021-01-02/打上断点.png)打上断点
+
+② Debug 运行 SampleTomcatApplication 类，首次构建会需要几秒钟，成功进入断点，可以愉快的调试 Spring Boot **启动过程**。如下图所示：
+
+[![调试 Spring Boot](04-Spring Boot 源码分析-调试环境搭建（Spring Boot 2.6.0 版本）.assets/调试 Spring Boot.gif)](https://www.iocoder.cn/images/Spring-Boot/2021-01-02/调试 Spring Boot.gif)调试 Spring Boot
+
+# 5. 源码解析
+
+Spring Boot 的代码量，目前有 35w 行左右，不过绝大多数情况下，我们只要搞懂 Spring Boot 的启动流程，如何实现自动配置的原理，足够满足工作与面试了。
+
+这里，艿艿来推荐下 Spring Boot 相关的源码解析的书籍，帮助大家更好的阅读。
+
+① 艿艿写的 [《精尽 Spring Boot 源码解析》](http://svip.iocoder.cn/categories/Spring-Boot/)，针对 Spring Boot 2.2.X 版本，工作中使用的主流版本。
+
+如果大家在阅读中有碰到什么问题，欢迎星球给艿艿提问哈，大胆的，自己人！
+
+② [《SpringBoot 源码解读与原理分析》](https://github.com/YunaiV/books)，针对 Spring Boot 2.1.9 版本。
+
+写的还行，内容也讲了一些 Spring IOC 和 AOP 相关的源码，细节上不够详细，可以选择看看。
+
+③ [《Spring Boot 技术内幕》](https://github.com/YunaiV/books)，针对 Spring Boot 2.X 版本，豆瓣暂无评分，预计评分在 6.5 左右。
+
+> 链接: https://pan.baidu.com/s/19O9ShDQcbmFopr-Vym-OFQ 提取码: zay7 复制这段内容后打开百度网盘手机App，操作更方便哦
+
+这本书出的太晚，艿艿暂时还没细看，后续有时间准备瞅瞅~
\ No newline at end of file
diff --git a/springboot/05-Spring Boot 源码分析-项目结构一览.assets/01.jpg b/springboot/05-Spring Boot 源码分析-项目结构一览.assets/01.jpg
new file mode 100644
index 0000000..30a3d33
Binary files /dev/null and b/springboot/05-Spring Boot 源码分析-项目结构一览.assets/01.jpg differ
diff --git a/springboot/05-Spring Boot 源码分析-项目结构一览.assets/02.jpg b/springboot/05-Spring Boot 源码分析-项目结构一览.assets/02.jpg
new file mode 100644
index 0000000..aba1b2d
Binary files /dev/null and b/springboot/05-Spring Boot 源码分析-项目结构一览.assets/02.jpg differ
diff --git a/springboot/05-Spring Boot 源码分析-项目结构一览.assets/03.jpg b/springboot/05-Spring Boot 源码分析-项目结构一览.assets/03.jpg
new file mode 100644
index 0000000..ec72b04
Binary files /dev/null and b/springboot/05-Spring Boot 源码分析-项目结构一览.assets/03.jpg differ
diff --git a/springboot/05-Spring Boot 源码分析-项目结构一览.md b/springboot/05-Spring Boot 源码分析-项目结构一览.md
new file mode 100644
index 0000000..e1d8c7b
--- /dev/null
+++ b/springboot/05-Spring Boot 源码分析-项目结构一览.md	
@@ -0,0 +1,170 @@
+# 精尽 Spring Boot 源码分析 —— 项目结构一览
+
+# 1. 概述
+
+本文主要分享 **Spring Boot 的项目结构**。
+希望通过本文能让胖友对 Spring Boot 的整体项目有个简单的了解。
+
+[![Spring Boot 项目结构](05-Spring Boot 源码分析-项目结构一览.assets/01.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-01-04/01.jpg)Spring Boot 项目结构
+
+# 2. 代码统计
+
+这里先分享一个小技巧。笔者在开始源码学习时，会首先了解项目的代码量。
+
+**第一种方式**，使用 [IDEA Statistic](https://plugins.jetbrains.com/plugin/4509-statistic) 插件，统计整体代码量。
+
+[![Statistic 统计代码量](05-Spring Boot 源码分析-项目结构一览.assets/02.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-01-04/02.jpg)Statistic 统计代码量
+
+我们可以粗略的看到，总的代码量在 268485 行。这其中还包括单元测试，示例等等代码。
+所以，不慌。特别是 Spring 项目的代码，单元测试覆盖是超级全面的。
+
+**第二种方式**，使用 [Shell 脚本命令逐个 Maven 模块统计](http://blog.csdn.net/yhhwatl/article/details/52623879) 。
+
+一般情况下，笔者使用 `find . -name "*.java"|xargs cat|grep -v -e ^$ -e ^\s*\/\/.*$|wc -l` 。这个命令只过滤了**部分注释**，所以相比 [IDEA Statistic](https://plugins.jetbrains.com/plugin/4509-statistic) 会**偏多**。
+
+当然，考虑到准确性，胖友需要手动 `cd` 到每个 Maven 项目的 `src/main/java` 目录下，以达到排除单元测试的代码量。
+
+[![Shell 脚本统计代码量](05-Spring Boot 源码分析-项目结构一览.assets/03.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-01-04/03.jpg)Shell 脚本统计代码量
+
+统计完后，艿艿有点慌。哈哈哈哈。
+
+# 3. spring-boot-project 项目
+
+`spring-boot-project` 项目，Spring Boot 的代码实现，大概在 20W 代码左右。当然，实际上我们并不需要看完全部。艿艿自己的话，也只会选择关注部分的看看，并且写成源码解析。所以啊，尾随艿艿，不要方。
+
+## 3.1 spring-boot 模块
+
+`spring-boot` 模块，Spring Boot 的核心实现，大概在 4W 代码左右。提供了如下功能：
+
+- 在 `org.springframework.boot.SpringApplication` 类，提供了大量的静态方法，可以很容易运行一个独立的 Spring 应用程序。
+
+  > 是不是超级熟悉。
+
+- 带有可选容器的嵌入式 Web 应用程序（Tomcat、Jetty、Undertow） 的支持。
+
+  > 在 `org.springframework.boot.web` 包下实现。
+
+- 边界的外部配置支持。
+
+- … 省略其它。
+
+  > 感兴趣的胖友，可以自己先简单翻翻每个 `package` 包，基本每个包下，都是对每个功能的支持。例如说，`web` 支持 Web 服务器，`jdbc` 支持 JDBC 功能，`task` 支持调度任务，以及等等。
+
+## 3.2 spring-boot-autoconfigure 模块
+
+`spring-boot-actuator-autoconfigure` 模块，大概 4W代码左右。`spring-boot-autoconfigure` 可以根据类路径的内容，自动配置大部分常用应用程序。通过使用 `org.springframework.boot.autoconfigure.@EnableAutoConfiguration` 注解，会触发 Spring 上下文的自动配置。
+
+> 这里的大部分，指的是常用的框架。例如说，Spring MVC、Quartz 等等。也就是说，如果 `spring-boot-actuator-autoconfigure` 模块，暂未提供的框架，需要我们自己去实现对应框架的自动装配。
+
+这个模块的代码，必须要看，没得商量。
+
+所以到此处为止，我们已经看到对我们来研究 Spring Boot 最最最中航要的两个模块：`spring-boot` 和 `spring-boot-autoconfigure` ，一共是 9W 行代码左右。
+
+## 3.3 spring-boot-actuator 模块
+
+`spring-boot-actuator` 模块，大概 2W 行代码左右。正如其模块的英文 actuator ，它完全是一个用于暴露应用自身信息的模块：
+
+- 提供了一个监控和管理生产环境的模块，可以使用 http、jmx、ssh、telnet 等管理和监控应用。
+- 审计（Auditing）、 健康（health）、数据采集（metrics gathering）会自动加入到应用里面。
+
+> 一般情况下，我们可以不看这块代码的代码。
+
+如果没有使用过 `spring-boot-actuator` 的胖友，可以看看下面两篇文章：
+
+- [《一起来学 SpringBoot 2.x | 第十四篇：强大的 Actuator 服务监控与管理》](http://www.iocoder.cn/Spring-Boot/battcn/v2-actuator-introduce/?vip)
+- [《一起来学 SpringBoot 2.x | 第十五篇：actuator 与 spring-boot-admin 可以说的秘密》](http://www.iocoder.cn/Spring-Boot/battcn/v2-actuator-monitor/?vip)
+
+## 3.4 spring-boot-actuator-autoconfigure 模块
+
+`spring-boot-actuator-autoconfigure` 模块，大概 1W7 行代码左右。它提供了 `spring-boot-actuator` 的自动配置功能。
+
+> 一般情况下，我们可以不看这块代码的代码。
+
+## 3.5 spring-boot-starters 模块
+
+`spring-boot-starters` 模块，它不存在任何的代码，而是提供我们常用框架的 Starter 模块。例如：
+
+- `spring-boot-starter-web` 模块，提供了对 Spring MVC 的 Starter 模块。
+- `spring-boot-starter-data-jpa` 模块，提供了对 Spring Data JPA 的 Starter 模块。
+
+而每个 Starter 模块，里面只存在一个 `pom` 文件，这是为什么呢？简单来说，Spring Boot 可以根据项目中是否存在指定类，并且是否未生成对应的 Bean 对象，那么就自动创建 Bean 对象。因为有这样的机制，我们只需要使用 `pom` 文件，配置需要引入的框架，就可以实现该框架的使用所需要的类的自动装配。
+
+> 当然，正如我们在 [「spring-boot-autoconfigure 模块」](https://svip.iocoder.cn/Spring-Boot/intro/#) 所提到的，如果不支持的框架，需要自己实现对应的 autoconfigure 功能。举个例子，Dubbo 框架并未在 `spring-boot-autoconfigure` 模块实现自动装配，所以 Dubbo 团队提供了 [`dubbo-spring-boot-project`](https://github.com/apache/incubator-dubbo-spring-boot-project) 。
+
+😈 如果觉得神奇的胖友，不烦可以跟着 [《快速开发一个自定义Spring Boot Starter》](https://www.jianshu.com/p/45538b44e04e) 文章，来干一个自己的 Starter 模块。
+
+## 3.6 spring-boot-cli 模块
+
+`spring-boot-cli` 模块，大概 1W 行代码左右。它提供了 Spring 项目相关的命令行功能。它是 Spring Boot 的命令行界面。
+
+- 它可以用来快速启动 Spring 。
+- 它可以运行 Groovy 脚本，开发人员不需要编写很多样板代码，只需要关注业务逻辑。
+- Spring Boot CLI 是创建基于Spring的应用程序的最快方法。
+
+想要详细了解的胖友，可以看看 [《Spring Boot 文档 —— Part VII. Spring Boot CLI》](https://docs.spring.io/spring-boot/docs/1.5.2.RELEASE/reference/htmlsingle/#cli) 文档。
+
+> 一般情况下，我们可以不看这块代码的代码。
+
+## 3.7 spring-boot-test 模块
+
+`spring-boot-test` 模块，大概 1W 行代码左右。Spring Boot 提供测试方面的支持，例如说：
+
+- SpringBootTestRandomPortEnvironmentPostProcessor 类，提供随机端口。
+- `org.springframework.boot.test.mock.mockito` 包，提供 Mockito 的增强。
+
+> 一般情况下，我们可以不看这块代码的代码。
+
+## 3.8 spring-boot-test-autoconfigure 模块
+
+`spring-boot-test-autoconfigure` 模块，大概 1W 行代码不到。它提供了 `spring-boot-test` 的自动配置功能。
+
+> 一般情况下，我们可以不看这块代码的代码。
+
+## 3.9 spring-boot-devtools 模块
+
+`spring-boot-devtools` 模块，大概 8000 行代码左右。通过它，来使 Spring Boot 应用支持热部署，提高开发者的开发效率，无需手动重启 Spring Boot 应用。
+
+没有使用过的胖友，赶紧开始用啦。具体杂用，可以看看 [《Spring Boot 项目中使用 spring-boot-devtools 模块进行代码热部署，避免重新启动 web 项目》](https://blog.csdn.net/yaomingyang/article/details/78241988) 文章。
+
+> 一般情况下，我们可以不看这块代码的代码。
+
+## 3.10 spring-boot-tools 模块
+
+`spring-boot-tools` 模块，大概 3W 行代码左右。它是 Spring Boot 提供的工具箱，所以在其内有多个子 Maven 项目。
+
+注意哟，我们这里说的工具箱，并不是我们在 Java 里的工具类。困惑？我们来举个例子：`spring-boot-maven-plugin` 模块：提供 Maven 打包 Spring Boot 项目的插件。
+
+关于 `spring-boot-tools` 模块的其它子模块，我们就暂时不多做介绍落。
+
+> 一般情况下，我们可以不看这块代码的代码。
+
+## 3.11 其它
+
+`spring-boot-project` 项目的其它子模块如下：
+
+- `spring-boot-properties-migrator` 模块：500 行代码左右，帮助开发者从 Spring Boot 1 迁移到 Spring Boot 2 。
+- `spring-boot-dependencies` 模块：无代码，只有所有依赖和插件的版本号信息。
+- `spring-boot-parent` 模块：无代码，该模块是其他项目的 parent，该模块的父模块是 `spring-boot-dependencies` 。
+- `spring-boot-docs` 模块：1000 行代码左右，貌似是提供 Spring Boot 文档里的一些示例。不太确定，也并不重要。
+
+# 4. spring-boot-samples 项目
+
+`spring-boot-samples` 项目，2W 行代码左右。丧心病狂，提供了超级多的示例，简直良心无敌啊。
+
+> 一般情况下，我们可以不看这块代码的代码。如果真的需要某个 Spring Boot 对某个框架的示例，大多数情况下，我们还是 Google 检索文章居多。
+
+# 5. spring-boot-samples-invoker 项目
+
+`spring-boot-samples-invoker` 项目，无代码，有点不造用户。当然，也并不重要。
+
+# 6. spring-boot-tests
+
+`spring-boot-tests` 项目，3000 行代码，主要是 Spring Boot 的集成测试、部署测试。
+
+> 一般情况下，我们可以不看这块代码的代码。
+
+# 666. 彩蛋
+
+并没有什么实质性内容的一篇文章。感谢老田 [《Spring Boot 2.0系列文章(五)：Spring Boot 2.0 项目源码结构预览》](http://www.54tianzhisheng.cn/2018/04/18/spring_boot2_project/#spring-boot-tests) 文章，让自己更加方便的了解 Spring Boot 2 的项目结构。
+
+😈 继续怼。有点偷懒的一个周六。
\ No newline at end of file
diff --git a/springboot/06-Spring Boot 源码解析-Jar 启动实现.assets/01.png b/springboot/06-Spring Boot 源码解析-Jar 启动实现.assets/01.png
new file mode 100644
index 0000000..b3aff00
Binary files /dev/null and b/springboot/06-Spring Boot 源码解析-Jar 启动实现.assets/01.png differ
diff --git a/springboot/06-Spring Boot 源码解析-Jar 启动实现.assets/11.png b/springboot/06-Spring Boot 源码解析-Jar 启动实现.assets/11.png
new file mode 100644
index 0000000..adc79f2
Binary files /dev/null and b/springboot/06-Spring Boot 源码解析-Jar 启动实现.assets/11.png differ
diff --git a/springboot/06-Spring Boot 源码解析-Jar 启动实现.assets/13.png b/springboot/06-Spring Boot 源码解析-Jar 启动实现.assets/13.png
new file mode 100644
index 0000000..3b95dca
Binary files /dev/null and b/springboot/06-Spring Boot 源码解析-Jar 启动实现.assets/13.png differ
diff --git a/springboot/06-Spring Boot 源码解析-Jar 启动实现.assets/14.png b/springboot/06-Spring Boot 源码解析-Jar 启动实现.assets/14.png
new file mode 100644
index 0000000..0f1458a
Binary files /dev/null and b/springboot/06-Spring Boot 源码解析-Jar 启动实现.assets/14.png differ
diff --git a/springboot/06-Spring Boot 源码解析-Jar 启动实现.assets/30.png b/springboot/06-Spring Boot 源码解析-Jar 启动实现.assets/30.png
new file mode 100644
index 0000000..d64b2db
Binary files /dev/null and b/springboot/06-Spring Boot 源码解析-Jar 启动实现.assets/30.png differ
diff --git a/springboot/06-Spring Boot 源码解析-Jar 启动实现.md b/springboot/06-Spring Boot 源码解析-Jar 启动实现.md
new file mode 100644
index 0000000..0531cf6
--- /dev/null
+++ b/springboot/06-Spring Boot 源码解析-Jar 启动实现.md	
@@ -0,0 +1,601 @@
+# 精尽 Spring Boot 源码解析 —— Jar 启动实现
+
+# 1. 概述
+
+Spring Boot 提供了 Maven 插件 [`spring-boot-maven-plugin`](https://docs.spring.io/spring-boot/docs/current/reference/html/build-tool-plugins.html#build-tool-plugins-maven-plugin)，可以方便的将 Spring Boot 项目打成 `jar` 包或者 `war` 包。
+
+考虑到部署的便利性，我们绝大多数 99.99% 的场景下，我们会选择打成 `jar` 包。这样，我们就无需在部署项目的服务器上，配置相应的 Tomcat、Jetty 等 Servlet 容器。
+
+那么，`jar` 包是如何运行，并启动 Spring Boot 项目的呢？这个就是本文的目的，一起弄懂 Spring Boot `jar` 包的**运行原理**。
+
+下面，我们来打开一个 Spring Boot `jar` 包，看看其里面的结构。如下图所示，一共分成四部分：
+
+[![Spring Boot `jar` 包](06-Spring Boot 源码解析-Jar 启动实现.assets/01.png)](http://www.iocoder.cn/images/Spring-Boot/2019-01-07/01.png)Spring Boot `jar` 包
+
+- ① `META-INF` 目录：通过 `MANIFEST.MF` 文件提供 `jar` 包的**元数据**，声明了 `jar` 的启动类。
+
+- ② `org` 目录：为 Spring Boot 提供的 [`spring-boot-loader`](https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-tools/spring-boot-loader/) 项目，它是 `java -jar` 启动 Spring Boot 项目的秘密所在，也是稍后我们将深入了解的部分。
+
+  > Spring Boot Loader provides the secret sauce that allows you to build a single jar file that can be launched using `java -jar`. Generally you will not need to use `spring-boot-loader` directly, but instead work with the [Gradle](https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin) or [Maven](https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-tools/spring-boot-maven-plugin) plugin.
+
+- ③ `BOOT-INF/lib` 目录：我们 Spring Boot 项目中引入的**依赖**的 `jar` 包们。`spring-boot-loader` 项目很大的一个作用，就是**解决 `jar` 包里嵌套 `jar` 的情况**，如何加载到其中的类。
+
+- ④ `BOOT-INF/classes` 目录：我们在 Spring Boot 项目中 Java 类所编译的 `.class`、配置文件等等。
+
+先简单剧透下，`spring-boot-loader` 项目需要解决两个问题：
+
+- 第一，如何引导执行我们创建的 Spring Boot 应用的启动类，例如上述图中的 Application 类。
+- 第二，如何加载 `BOOT-INF/class` 目录下的类，以及 `BOOT-INF/lib` 目录下内嵌的 `jar` 包中的类。
+
+下面，尾随艿艿，一起来抽丝剥茧！
+
+# 2. MANIFEST.MF
+
+我们来查看 `META-INF/MANIFEST.MF` 文件，里面的内容如下：
+
+```
+Manifest-Version: 1.0
+Implementation-Title: lab-39-demo
+Implementation-Version: 2.2.2.RELEASE
+Start-Class: cn.iocoder.springboot.lab39.skywalkingdemo.Application
+Spring-Boot-Classes: BOOT-INF/classes/
+Spring-Boot-Lib: BOOT-INF/lib/
+Build-Jdk-Spec: 1.8
+Spring-Boot-Version: 2.2.2.RELEASE
+Created-By: Maven Archiver 3.4.0
+Main-Class: org.springframework.boot.loader.JarLauncher
+```
+
+它实际是一个 **Properties** 配置文件，每一行都是一个配置项目。重点来看看两个配置项：
+
+- `Main-Class` 配置项：Java 规定的 `jar` 包的启动类，这里设置为 `spring-boot-loader` 项目的 [JarLauncher](https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-tools/spring-boot-loader/src/main/java/org/springframework/boot/loader/JarLauncher.java) 类，进行 Spring Boot 应用的启动。
+- `Start-Class` 配置项：Spring Boot 规定的**主**启动类，这里设置为我们定义的 Application 类。
+
+> 小知识补充：为什么会有 `Main-Class`/`Start-Class` 配置项呢？因为我们是通过 Spring Boot 提供的 Maven 插件 [`spring-boot-maven-plugin`](https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/) 进行打包，该插件将该配置项写入到 `MANIFEST.MF` 中，从而能让 `spring-boot-loader` 能够引导启动 Spring Boot 应用。
+
+可能胖友会有疑惑，`Start-Class` 对应的 Application 类自带了 `#main(String[] args)` 方法，为什么我们不能直接运行会如何呢？我们来简单尝试一下哈，控制台执行如下：
+
+```
+$ java -classpath lab-39-demo-2.2.2.RELEASE.jar cn.iocoder.springboot.lab39.skywalkingdemo.Application
+错误: 找不到或无法加载主类 cn.iocoder.springboot.lab39.skywalkingdemo.Application
+```
+
+直接找不到 Application 类，因为它在 `BOOT-INF/classes` 目录下，不符合 Java 默认的 `jar` 包的加载规则。因此，需要通过 JarLauncher 启动加载。
+
+当然实际还有一个更重要的原因，Java 规定可执行器的 `jar` 包禁止嵌套其它 `jar` 包。但是我们可以看到 `BOOT-INF/lib` 目录下，实际有 Spring Boot 应用依赖的所有 `jar` 包。因此，`spring-boot-loader` 项目自定义实现了 ClassLoader 实现类 [LaunchedURLClassLoader](https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-tools/spring-boot-loader/src/main/java/org/springframework/boot/loader/LaunchedURLClassLoader.java)，支持加载 `BOOT-INF/classes` 目录下的 `.class` 文件，以及 `BOOT-INF/lib` 目录下的 `jar` 包。
+
+# 3. JarLauncher
+
+[JarLauncher](https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-tools/spring-boot-loader/src/main/java/org/springframework/boot/loader/JarLauncher.java) 类是针对 Spring Boot `jar` 包的启动类，整体类图如下所示：
+
+[![JarLauncher 类图](06-Spring Boot 源码解析-Jar 启动实现.assets/11.png)](http://www.iocoder.cn/images/Spring-Boot/2019-01-07/11.png)JarLauncher 类图
+
+> 友情提示：[WarLauncher](https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-tools/spring-boot-loader/src/main/java/org/springframework/boot/loader/WarLauncher.java) 类，是针对 Spring Boot `war` 包的启动类，后续胖友可以自己瞅瞅，差别并不大哈~
+
+JarLauncher 的源码比较简单，如下图所示：
+
+```
+public class JarLauncher extends ExecutableArchiveLauncher {
+
+	static final String BOOT_INF_CLASSES = "BOOT-INF/classes/";
+
+	static final String BOOT_INF_LIB = "BOOT-INF/lib/";
+
+	public JarLauncher() {
+	}
+
+	protected JarLauncher(Archive archive) {
+		super(archive);
+	}
+
+	@Override
+	protected boolean isNestedArchive(Archive.Entry entry) {
+		if (entry.isDirectory()) {
+			return entry.getName().equals(BOOT_INF_CLASSES);
+		}
+		return entry.getName().startsWith(BOOT_INF_LIB);
+	}
+
+	public static void main(String[] args) throws Exception {
+		new JarLauncher().launch(args);
+	}
+
+}
+```
+
+通过 `#main(String[] args)` 方法，创建 JarLauncher 对象，并调用其 `#launch(String[] args)` 方法进行启动。整体的启动逻辑，其实是由父类 [Launcher](https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-tools/spring-boot-loader/src/main/java/org/springframework/boot/loader/Launcher.java) 所提供，如下图所示：
+
+[![Launcher 启动过程](http://www.iocoder.cn/images/Spring-Boot/2019-01-07/12.png)](http://www.iocoder.cn/images/Spring-Boot/2019-01-07/12.png)Launcher 启动过程
+
+父类 Launcher 的 `#launch(String[] args)` 方法，代码如下：
+
+```
+// Launcher.java
+
+protected void launch(String[] args) throws Exception {
+	// <1> 注册 URL 协议的处理器
+	JarFile.registerUrlProtocolHandler();
+	// <2> 创建类加载器
+	ClassLoader classLoader = createClassLoader(getClassPathArchives());
+	// <3> 执行启动类的 main 方法
+	launch(args, getMainClass(), classLoader);
+}
+```
+
+- `<1>` 处，调用 JarFile 的 `#registerUrlProtocolHandler()` 方法，注册 Spring Boot 自定义的 [URLStreamHandler](https://github.com/openjdk-mirror/jdk7u-jdk/blob/master/src/share/classes/java/net/URLStreamHandler.java) 实现类，用于 `jar` 包的加载读取。
+- `<2>` 处，调用自身的 `#createClassLoader(List<Archive> archives)` 方法，创建自定义的 [ClassLoader](https://github.com/openjdk-mirror/jdk7u-jdk/blob/master/src/share/classes/java/lang/ClassLoader.java) 实现类，用于从 `jar` 包中加载类。
+- `<3>` 处，执行我们声明的 Spring Boot 启动类，进行 Spring Boot 应用的启动。
+
+简单来说，就是整一个可以读取 `jar` 包中类的加载器，保证 `BOOT-INF/lib` 目录下的类和 `BOOT-classes` 内嵌的 `jar` 中的类能够被正常加载到，之后执行 Spring Boot 应用的启动。
+
+下面，我们逐行代码来看看噢。即将代码多多，保持淡定，嘿嘿~
+
+## 3.1 registerUrlProtocolHandler
+
+> 友情提示：对应 `JarFile.registerUrlProtocolHandler();` 代码段，不要迷路。
+
+[JarFile](https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-tools/spring-boot-loader/src/main/java/org/springframework/boot/loader/jar/JarFile.java) 是 [`java.util.jar.JarFile`](https://github.com/openjdk-mirror/jdk7u-jdk/blob/master/src/share/classes/java/util/jar/JarFile.java) 的子类，如下所示：
+
+```
+public class JarFile extends java.util.jar.JarFile {
+
+    // ... 省略其它代码
+
+}
+```
+
+JarFile 主要增强支持对内嵌的 `jar` 包的获取。如下图所示：
+
+[![读取内嵌的 `jar` 包的演示](06-Spring Boot 源码解析-Jar 启动实现.assets/13.png)](http://www.iocoder.cn/images/Spring-Boot/2019-01-07/13.png)读取内嵌的 `jar` 包的演示
+
+OK，介绍完之后，让我们回到 JarFile 的 `#registerUrlProtocolHandler()` 方法，注册 Spring Boot 自定义的 URL 协议的处理器。代码如下：
+
+```
+// JarFile.java
+
+private static final String PROTOCOL_HANDLER = "java.protocol.handler.pkgs";
+
+private static final String HANDLERS_PACKAGE = "org.springframework.boot.loader";
+
+/**
+ * Register a {@literal 'java.protocol.handler.pkgs'} property so that a
+ * {@link URLStreamHandler} will be located to deal with jar URLs.
+ */
+public static void registerUrlProtocolHandler() {
+    // 获得 URLStreamHandler 的路径
+	String handlers = System.getProperty(PROTOCOL_HANDLER, "");
+	// 将 Spring Boot 自定义的 HANDLERS_PACKAGE(org.springframework.boot.loader) 补充上去
+	System.setProperty(PROTOCOL_HANDLER, ("".equals(handlers) ? HANDLERS_PACKAGE
+			: handlers + "|" + HANDLERS_PACKAGE));
+	// 重置已缓存的 URLStreamHandler 处理器们
+	resetCachedUrlHandlers();
+}
+
+/**
+ * Reset any cached handlers just in case a jar protocol has already been used.
+ * We reset the handler by trying to set a null {@link URLStreamHandlerFactory} which
+ * should have no effect other than clearing the handlers cache.
+ *
+ * 重置 URL 中的 URLStreamHandler 的缓存，防止 `jar://` 协议对应的 URLStreamHandler 已经创建
+ * 我们通过设置 URLStreamHandlerFactory 为 null 的方式，清空 URL 中的该缓存。
+ */
+private static void resetCachedUrlHandlers() {
+	try {
+		URL.setURLStreamHandlerFactory(null);
+	} catch (Error ex) {
+		// Ignore
+	}
+}
+```
+
+- 胖友先跟着注释，自己阅读下如上的代码~
+
+目的很明确，通过将 `org.springframework.boot.loader` 包设置到 `"java.protocol.handler.pkgs"` 环境变量，从而使用到自定义的 URLStreamHandler 实现类 [Handler](https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-tools/spring-boot-loader/src/main/java/org/springframework/boot/loader/jar/Handler.java)，处理 `jar:` 协议的 URL。
+
+> 友情提示：这里我们暂时不深入 Handler 的源码，避免直接走的太深，丢失了主干。后续胖友可结合[《Java URL 协议扩展实现》](https://www.iteye.com/blog/mercyblitz-735529)文章，进行 Handler 的实现理解。
+>
+> 另外，[HandlerTests](https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-tools/spring-boot-loader/src/test/java/org/springframework/boot/loader/jar/HandlerTests.java) 提供的单元测试，也是非常有帮助的~
+
+## 3.2 createClassLoader
+
+> 友情提示：对应 `ClassLoader classLoader = createClassLoader(getClassPathArchives())` 代码段，不要迷路。
+
+### 3.2.1 getClassPathArchives
+
+首先，我们先来看看 `#getClassPathArchives()` 方法，它是由 ExecutableArchiveLauncher 所实现，代码如下：
+
+```
+// ExecutableArchiveLauncher.java
+
+private final Archive archive;
+
+@Override
+protected List<Archive> getClassPathArchives() throws Exception {
+	// <1> 获得所有 Archive
+	List<Archive> archives = new ArrayList<>(
+			this.archive.getNestedArchives(this::isNestedArchive));
+	// <2> 后续处理
+	postProcessClassPathArchives(archives);
+	return archives;
+}
+
+protected abstract boolean isNestedArchive(Archive.Entry entry);
+
+protected void postProcessClassPathArchives(List<Archive> archives) throws Exception {
+}
+```
+
+> 友情提示：这里我们会看到一个 [Archive](https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-tools/spring-boot-loader/src/main/java/org/springframework/boot/loader/archive/Archive.java) 对象，先可以暂时理解成一个一个的**档案**，稍后会清晰认识的~
+
+`<1>` 处，`this::isNestedArchive` 代码段，创建了 [EntryFilter](https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-tools/spring-boot-loader/src/main/java/org/springframework/boot/loader/archive/Archive.java#L130-L143) 匿名实现类，用于过滤 `jar` 包不需要的目录。
+
+```
+// Archive.java
+
+/**
+ * Represents a single entry in the archive.
+ */
+interface Entry {
+
+	/**
+	 * Returns {@code true} if the entry represents a directory.
+	 * @return if the entry is a directory
+	 */
+	boolean isDirectory();
+
+	/**
+	 * Returns the name of the entry.
+	 * @return the name of the entry
+	 */
+	String getName();
+
+}
+
+/**
+ * Strategy interface to filter {@link Entry Entries}.
+ */
+interface EntryFilter {
+
+	/**
+	 * Apply the jar entry filter.
+	 * @param entry the entry to filter
+	 * @return {@code true} if the filter matches
+	 */
+	boolean matches(Entry entry);
+
+}
+```
+
+这里在它的内部，调用了 `#isNestedArchive(Archive.Entry entry)` 方法，它是由 JarLauncher 所实现，代码如下：
+
+```
+// JarLauncher.java
+
+static final String BOOT_INF_CLASSES = "BOOT-INF/classes/";
+
+static final String BOOT_INF_LIB = "BOOT-INF/lib/";
+
+@Override
+protected boolean isNestedArchive(Archive.Entry entry) {
+    // 如果是目录的情况，只要 BOOT-INF/classes/ 目录
+	if (entry.isDirectory()) {
+		return entry.getName().equals(BOOT_INF_CLASSES);
+	}
+	// 如果是文件的情况，只要 BOOT-INF/lib/ 目录下的 `jar` 包
+	return entry.getName().startsWith(BOOT_INF_LIB);
+}
+```
+
+- 目的就是过滤获得，`BOOT-INF/classes/` 目录下的类，以及 `BOOT-INF/lib/` 的内嵌 `jar` 包。
+
+`<1>` 处，`this.archive.getNestedArchives` 代码段，调用 Archive 的 `#getNestedArchives(EntryFilter filter)` 方法，获得 `archive` 内嵌的 Archive 集合。代码如下：
+
+```
+// Archive.java
+
+/**
+ * Returns nested {@link Archive}s for entries that match the specified filter.
+ * @param filter the filter used to limit entries
+ * @return nested archives
+ * @throws IOException if nested archives cannot be read
+ */
+List<Archive> getNestedArchives(EntryFilter filter) throws IOException;
+```
+
+[Archive](https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-tools/spring-boot-loader/src/main/java/org/springframework/boot/loader/archive/Archive.java) 接口，是 `spring-boot-loader` 项目定义的**档案**抽象，其子类如下图所示：
+
+[![Archive 类图](06-Spring Boot 源码解析-Jar 启动实现.assets/14.png)](http://www.iocoder.cn/images/Spring-Boot/2019-01-07/14.png)Archive 类图
+
+- ExplodedArchive 是针对**目录**的 Archive 实现类。
+- JarFileArchive 是针对 **`jar` 包**的 Archive 实现类。
+
+> 友情提示：这块可能有一丢丢复杂，胖友吃耐心哈~
+
+那么，我们在 ExecutableArchiveLauncher 的 `archive` 属性是怎么来的呢？答案在 ExecutableArchiveLauncher 的构造方法中，代码如下：
+
+```
+// ExecutableArchiveLauncher.java
+
+public abstract class ExecutableArchiveLauncher extends Launcher {
+
+	private final Archive archive;
+
+	public ExecutableArchiveLauncher() {
+		try {
+			this.archive = createArchive();
+		} catch (Exception ex) {
+			throw new IllegalStateException(ex);
+		}
+	}
+
+	protected ExecutableArchiveLauncher(Archive archive) {
+		this.archive = archive;
+	}
+
+	// ... 省略其它
+}
+
+// Launcher.java
+public abstract class Launcher {
+
+	protected final Archive createArchive() throws Exception {
+	    // 获得 jar 所在的绝对路径
+		ProtectionDomain protectionDomain = getClass().getProtectionDomain();
+		CodeSource codeSource = protectionDomain.getCodeSource();
+		URI location = (codeSource != null) ? codeSource.getLocation().toURI() : null;
+		String path = (location != null) ? location.getSchemeSpecificPart() : null;
+		if (path == null) {
+			throw new IllegalStateException("Unable to determine code source archive");
+		}
+		File root = new File(path);
+		if (!root.exists()) {
+			throw new IllegalStateException(
+					"Unable to determine code source archive from " + root);
+		}
+		// 如果是目录，则使用 ExplodedArchive 进行展开
+        // 如果不是目录，则使用 JarFileArchive
+		return (root.isDirectory() ? new ExplodedArchive(root)
+				: new JarFileArchive(root));
+	}
+
+}
+```
+
+根据根路径**是否为目录**的情况，创建 ExplodedArchive 或 JarFileArchive 对象。那么问题就来了，这里的 `root` 是什么呢？艿艿一波骚操作，终于输出了答案，如下图所示：
+
+[![`root` 是什么！](http://www.iocoder.cn/images/Spring-Boot/2019-01-07/15.png)](http://www.iocoder.cn/images/Spring-Boot/2019-01-07/15.png)`root` 是什么！
+
+`root` 路径为 `jar` 包的绝对地址，也就是说创建 JarFileArchive 对象。原因是，Launcher 所在包为 `org` 下，它的根目录当然是 `jar` 包的绝对路径哈！
+
+😈 现在是不是对 Archive 稍微有点感觉落？继续附加如下代码，打印 JarFileArchive 的 `#getNestedArchives(EntryFilter filter)` 方法的执行结果。
+
+```
+// ========== 附加代码：
+// 创建 Archive 对象
+Archive archive = new JarFileArchive(root);
+// 创建 EntryFilter 对象
+Archive.EntryFilter filter = new Archive.EntryFilter() {
+
+    static final String BOOT_INF_CLASSES = "BOOT-INF/classes/";
+
+    static final String BOOT_INF_LIB = "BOOT-INF/lib/";
+
+    @Override
+    public boolean matches(Archive.Entry entry) {
+        // 如果是目录的情况，只要 BOOT-INF/classes/ 目录
+        if (entry.isDirectory()) {
+            return entry.getName().equals(BOOT_INF_CLASSES);
+        }
+        // 如果是文件的情况，只要 BOOT-INF/lib/ 目录下的 `jar` 包
+        return entry.getName().startsWith(BOOT_INF_LIB);
+    }
+
+};
+// 执行读取
+for (Archive item : archive.getNestedArchives(filter)) {
+    System.out.println(item.getUrl());
+}
+
+// ========== 执行结果：
+jar:file:/Users/yunai/Java/SpringBoot-Labs/lab-39/lab-39-demo/target/lab-39-demo-2.2.2.RELEASE.jar!/BOOT-INF/classes!/
+jar:file:/Users/yunai/Java/SpringBoot-Labs/lab-39/lab-39-demo/target/lab-39-demo-2.2.2.RELEASE.jar!/BOOT-INF/lib/spring-boot-starter-web-2.2.2.RELEASE.jar!/
+jar:file:/Users/yunai/Java/SpringBoot-Labs/lab-39/lab-39-demo/target/lab-39-demo-2.2.2.RELEASE.jar!/BOOT-INF/lib/spring-boot-starter-2.2.2.RELEASE.jar!/
+jar:file:/Users/yunai/Java/SpringBoot-Labs/lab-39/lab-39-demo/target/lab-39-demo-2.2.2.RELEASE.jar!/BOOT-INF/lib/spring-boot-2.2.2.RELEASE.jar!/
+... 省略其他 jar 包
+```
+
+从执行结果可以看出，`BOOT-INF/classes/` 目录被归类为**一个** Archive 对象，而 `BOOT-INF/lib/` 目录下的**每个**内嵌 `jar` 包都对应**一个** Archive 对象。
+
+来来来，回过头来看看 JarFileArchive 的 `#getNestedArchives(EntryFilter filter)` 方法的源码，如下图所示：
+
+[![JarFileArchive 的 `#getNestedArchives(EntryFilter filter)` 方法](http://www.iocoder.cn/images/Spring-Boot/2019-01-07/16.png)](http://www.iocoder.cn/images/Spring-Boot/2019-01-07/16.png)JarFileArchive 的 `#getNestedArchives(EntryFilter filter)` 方法
+
+现在是不是明白了噢！良心如我，哈哈哈！
+
+> 友情提示：上述的测试代码，可以访问 [lab-39-demo](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-39/lab-39-demo) 项目查看。
+
+### 3.2.2 createClassLoader
+
+然后，我再来看看 `#createClassLoader(List<Archive> archives)` 方法，它是由 ExecutableArchiveLauncher 所实现，代码如下：
+
+```
+// ExecutableArchiveLauncher.java
+
+protected ClassLoader createClassLoader(List<Archive> archives) throws Exception {
+	// 获得所有 Archive 的 URL 地址
+    List<URL> urls = new ArrayList<>(archives.size());
+	for (Archive archive : archives) {
+		urls.add(archive.getUrl());
+	}
+	// 创建加载这些 URL 的 ClassLoader
+	return createClassLoader(urls.toArray(new URL[0]));
+}
+
+protected ClassLoader createClassLoader(URL[] urls) throws Exception {
+	return new LaunchedURLClassLoader(urls, getClass().getClassLoader());
+}
+```
+
+基于获得的 Archive 数组，创建自定义 ClassLoader 实现类 [LaunchedURLClassLoader](https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-tools/spring-boot-loader/src/main/java/org/springframework/boot/loader/LaunchedURLClassLoader.java)，通过它来加载 `BOOT-INF/classes` 目录下的类，以及 `BOOT-INF/lib` 目录下的 `jar` 包中的类。
+
+进一步的解析，我们在[「5. LaunchedURLClassLoader」](https://svip.iocoder.cn/Spring-Boot/Jar/#)小节中，进行分享哈！
+
+## 3.3 launch
+
+> 友情提示：对应 `launch(args, getMainClass(), classLoader)` 代码段，不要迷路。
+
+### 3.3.1 getMainClass
+
+首先，我们先来看看`#getMainClass()` 方法，它是由 ExecutableArchiveLauncher 所实现，代码如下：
+
+```
+// ExecutableArchiveLauncher.java
+
+@Override
+protected String getMainClass() throws Exception {
+    // 获得启动的类的全名
+	Manifest manifest = this.archive.getManifest();
+	String mainClass = null;
+	if (manifest != null) {
+		mainClass = manifest.getMainAttributes().getValue("Start-Class");
+	}
+	if (mainClass == null) {
+		throw new IllegalStateException(
+				"No 'Start-Class' manifest entry specified in " + this);
+	}
+	return mainClass;
+}
+```
+
+从 `jar` 包的 `MANIFEST.MF` 文件的 `Start-Class` 配置项，，获得我们设置的 Spring Boot 的**主**启动类。
+
+### 3.3.2 createMainMethodRunner
+
+然后，我们再来看看 `#launch()` 方法，它是由 Launcher 所实现，代码如下：
+
+```
+protected void launch(String[] args, String mainClass, ClassLoader classLoader)
+		throws Exception {
+    // <1> 设置 LaunchedURLClassLoader 作为类加载器
+	Thread.currentThread().setContextClassLoader(classLoader);
+	// <2> 创建 MainMethodRunner 对象，并执行 run 方法，启动 Spring Boot 应用
+	createMainMethodRunner(mainClass, args, classLoader).run();
+}
+```
+
+该方法负责最终的 Spring Boot 应用真正的**启动**。
+
+- `<1>` 处：设置[「3.2.2 createClassLoader」](https://svip.iocoder.cn/Spring-Boot/Jar/#)创建的 LaunchedURLClassLoader 作为类加载器，从而保证能够从 `jar` 加载到相应的类。
+- `<2>` 处，调用 `#createMainMethodRunner(String mainClass, String[] args, ClassLoader classLoader)` 方法，创建 [MainMethodRunner](https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-tools/spring-boot-loader/src/main/java/org/springframework/boot/loader/MainMethodRunner.java) 对象，并执行其 `#run()` 方法来启动 Spring Boot 应用。
+
+下面，我们来看看 **MainMethodRunner** 类，负责 Spring Boot 应用的启动。代码如下：
+
+```
+public class MainMethodRunner {
+
+	private final String mainClassName;
+
+	private final String[] args;
+
+	/**
+	 * Create a new {@link MainMethodRunner} instance.
+	 * @param mainClass the main class
+	 * @param args incoming arguments
+	 */
+	public MainMethodRunner(String mainClass, String[] args) {
+		this.mainClassName = mainClass;
+		this.args = (args != null) ? args.clone() : null;
+	}
+
+	public void run() throws Exception {
+	    // <1> 加载 Spring Boot
+		Class<?> mainClass = Thread.currentThread().getContextClassLoader().loadClass(this.mainClassName);
+		// <2> 反射调用 main 方法
+		Method mainMethod = mainClass.getDeclaredMethod("main", String[].class);
+		mainMethod.invoke(null, new Object[] { this.args });
+	}
+
+}
+```
+
+- `<1>` 处：通过 LaunchedURLClassLoader 类加载器，加载到我们设置的 Spring Boot 的主启动类。
+- `<2>` 处：通过**反射**调用主启动类的 `#main(String[] args)` 方法，启动 Spring Boot 应用。这里也告诉了我们答案，为什么我们通过编写一个带有 `#main(String[] args)` 方法的类，就能够启动 Spring Boot 应用。
+
+# 4. LaunchedURLClassLoader
+
+[LaunchedURLClassLoader](https://github.com/DarLiner/spring-boot/blob/master/spring-boot-project/spring-boot-tools/spring-boot-loader/src/main/java/org/springframework/boot/loader/LaunchedURLClassLoader.java) 是 `spring-boot-loader` 项目自定义的**类加载器**，实现对 `jar` 包中 `META-INF/classes` 目录下的**类**和 `META-INF/lib` 内嵌的 `jar` 包中的**类**的**加载**。
+
+> FROM [《维基百科 —— Java 类加载器》](https://zh.wikipedia.org/wiki/Java类加载器)
+>
+> Java 类加载器是 Java 运行时环境的一个部件，负责动态加载 Java 类到 Java 虚拟机的内存空间中。类通常是按需加载，即第一次使用该类时才加载。
+>
+> 由于有了类加载器，Java 运行时系统不需要知道文件与文件系统。对学习类加载器而言，掌握 Java 的委派概念是很重要的。每个 Java 类必须由某个类加载器装入到内存。
+
+在[「3.2.2 createClassLoader」](https://svip.iocoder.cn/Spring-Boot/Jar/#)小节中，我们可以看到 LaunchedURLClassLoader 的创建代码如下：
+
+```
+// ExecutableArchiveLauncher.java
+
+protected ClassLoader createClassLoader(List<Archive> archives) throws Exception {
+    // 获得所有 Archive 的 URL 地址
+    List<URL> urls = new ArrayList<>(archives.size());
+    for (Archive archive : archives) {
+        urls.add(archive.getUrl());
+    }
+    // 创建加载这些 URL 的 ClassLoader
+    return createClassLoader(urls.toArray(new URL[0]));
+}
+
+protected ClassLoader createClassLoader(URL[] urls) throws Exception {
+	return new LaunchedURLClassLoader(urls, getClass().getClassLoader());
+}
+
+// LaunchedURLClassLoader.java
+
+public class LaunchedURLClassLoader extends URLClassLoader {
+
+	public LaunchedURLClassLoader(URL[] urls, ClassLoader parent) {
+		super(urls, parent);
+	}
+	
+}
+```
+
+- 第一个参数 `urls`，使用的是 Archive 集合对应的 URL 地址们，从而告诉 LaunchedURLClassLoader 读取 `jar` 的**地址**。
+- 第二个参数 `parent`，设置 LaunchedURLClassLoader 的**父**加载器。这里后续胖友可以理解下，类加载器的**双亲委派模型**，这里就拓展开了。
+
+LaunchedURLClassLoader 的实现代码并不多，我们主要来看看它是如何从 `jar` 包中加载类的。核心如下图所示：
+
+[![img](http://www.iocoder.cn/images/Spring-Boot/2019-01-07/21.png)](http://www.iocoder.cn/images/Spring-Boot/2019-01-07/21.png)
+
+- `<1>` 处，在通过**父类**的 `#getPackage(String name)` 方法获取不到指定类所在的包时，**会通过遍历 `urls` 数组，从 `jar` 包中加载类所在的包**。当找到包时，会调用 `#definePackage(String name, Manifest man, URL url)` 方法，设置包所在的 **Archive** 对应的 `url`。
+- `<2>` 处，调用**父类**的 `#loadClass(String name, boolean resolve)` 方法，加载对应的类。
+
+如此，我们就实现了通过 LaunchedURLClassLoader 加载 `jar` 包中内嵌的类。
+
+# 666. 彩蛋
+
+总体来说，Spring Boot `jar` 启动的原理是非常清晰的，整体如下图所示：
+
+[![Spring Boot `jar` 启动原理](06-Spring Boot 源码解析-Jar 启动实现.assets/30.png)](http://www.iocoder.cn/images/Spring-Boot/2019-01-07/30.png)Spring Boot `jar` 启动原理
+
+**红色**部分，解决 `jar` 包中的**类加载**问题：
+
+- 通过 [Archive](https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-tools/spring-boot-loader/src/main/java/org/springframework/boot/loader/archive/Archive.java)，实现 `jar` 包的**遍历**，将 `META-INF/classes` 目录和 `META-INF/lib` 的每一个内嵌的 `jar` 解析成一个 Archive 对象。
+- 通过 [Handler](https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-tools/spring-boot-loader/src/main/java/org/springframework/boot/loader/jar/Handler.java)，处理 `jar:` 协议的 URL 的资源**读取**，也就是读取了每个 Archive 里的内容。
+- 通过 [LaunchedURLClassLoader](https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-tools/spring-boot-loader/src/main/java/org/springframework/boot/loader/LaunchedURLClassLoader.java)，实现 `META-INF/classes` 目录下的类和 `META-INF/classes` 目录下内嵌的 `jar` 包中的类的加载。具体的 URL 来源，是通过 Archive 提供；具体 URL 的读取，是通过 Handler 提供。
+
+**橘色**部分，解决 Spring Boot 应用的**启动**问题：
+
+- 通过 [MainMethodRunner](https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-tools/spring-boot-loader/src/main/java/org/springframework/boot/loader/MainMethodRunner.java) ，实现 Spring Boot 应用的启动类的执行。
+
+当然，上述的一切都是通过 [Launcher](https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-tools/spring-boot-loader/src/main/java/org/springframework/boot/loader/Launcher.java) 来完成引导和启动，通过 `MANIFEST.MF` 进行具体配置。
+
+😈 生活如此美好，本文就此结束！
+
+------
+
+另外，本文有两个部分，胖友可以自己再去撸一撸，玩一玩：
+
+- [WarLauncher](https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-tools/spring-boot-loader/src/main/java/org/springframework/boot/loader/WarLauncher.java) 类：实现 Spring Boot `war` 包的启动。
+- [`org.springframework.boot.loader.jar`](https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-tools/spring-boot-loader/src/main/java/org/springframework/boot/loader/jar/) 包：具体读取 `jar` 的逻辑。
\ No newline at end of file
diff --git a/springboot/07-Spring Boot 源码分析-SpringApplication.assets/01.jpg b/springboot/07-Spring Boot 源码分析-SpringApplication.assets/01.jpg
new file mode 100644
index 0000000..0807529
Binary files /dev/null and b/springboot/07-Spring Boot 源码分析-SpringApplication.assets/01.jpg differ
diff --git a/springboot/07-Spring Boot 源码分析-SpringApplication.assets/02.jpg b/springboot/07-Spring Boot 源码分析-SpringApplication.assets/02.jpg
new file mode 100644
index 0000000..3d019af
Binary files /dev/null and b/springboot/07-Spring Boot 源码分析-SpringApplication.assets/02.jpg differ
diff --git a/springboot/07-Spring Boot 源码分析-SpringApplication.assets/03.jpg b/springboot/07-Spring Boot 源码分析-SpringApplication.assets/03.jpg
new file mode 100644
index 0000000..a0c4904
Binary files /dev/null and b/springboot/07-Spring Boot 源码分析-SpringApplication.assets/03.jpg differ
diff --git a/springboot/07-Spring Boot 源码分析-SpringApplication.assets/04.jpg b/springboot/07-Spring Boot 源码分析-SpringApplication.assets/04.jpg
new file mode 100644
index 0000000..5f7c3e7
Binary files /dev/null and b/springboot/07-Spring Boot 源码分析-SpringApplication.assets/04.jpg differ
diff --git a/springboot/07-Spring Boot 源码分析-SpringApplication.md b/springboot/07-Spring Boot 源码分析-SpringApplication.md
new file mode 100644
index 0000000..8f31627
--- /dev/null
+++ b/springboot/07-Spring Boot 源码分析-SpringApplication.md	
@@ -0,0 +1,1243 @@
+# 精尽 Spring Boot 源码分析 —— SpringApplication
+
+# 1. 概述
+
+```
+import org.springframework.boot.SpringApplication;
+import org.springframework.boot.autoconfigure.SpringBootApplication;
+
+@SpringBootApplication // <1>
+public class MVCApplication {
+
+    public static void main(String[] args) {
+        SpringApplication.run(MVCApplication.class, args); // <2>
+    }
+
+}
+```
+
+- `<1>` 处，使用 `@SpringBootApplication` 注解，标明是 Spring Boot 应用。通过它，可以开启自动配置的功能。
+- `<2>` 处，调用 `SpringApplication#run(Class<?>... primarySources)` 方法，启动 Spring Boot 应用。
+
+上述的代码，是我们使用 Spring Boot 时，最最最常用的代码。而本文，我们先来分析 Spring Boot 应用的**启动过程**。
+
+> 关于 `@SpringApplication` 注解，我们会后面单独开文章，详细解析。
+
+# 2. SpringApplication
+
+`org.springframework.boot.SpringApplication` ，Spring 应用启动器。正如其代码上所添加的注释，它来提供启动 Spring 应用的功能。
+
+```
+Class that can be used to bootstrap and launch a Spring application from a Java main method.
+```
+
+大多数情况下，我们都是使用它提供的**静态**方法：
+
+```
+// SpringApplication.java
+
+public static void main(String[] args) throws Exception {
+	SpringApplication.run(new Class<?>[0], args);
+}
+
+public static ConfigurableApplicationContext run(Class<?> primarySource, String... args) {
+	return run(new Class<?>[] { primarySource }, args);
+}
+
+public static ConfigurableApplicationContext run(Class<?>[] primarySources, String[] args) {
+	// 创建 SpringApplication 对象，并执行运行。
+	return new SpringApplication(primarySources).run(args);
+}
+```
+
+- 前两个静态方法，最终调用的是第 3 个静态方法。而第 3 个静态方法，实现的逻辑就是：
+  - 首先，创建一个 SpringApplication 对象。详细的解析，见 [「2.1 构造方法」](https://svip.iocoder.cn/Spring-Boot/SpringApplication/#) 。
+  - 然后，调用 `SpringApplication#run(Class<?> primarySource, String... args)` 方法，运行 Spring 应用。详细解析，见 [「2.2 run」](https://svip.iocoder.cn/Spring-Boot/SpringApplication/#) 。
+
+## 2.1 构造方法
+
+```
+// SpringApplication.java
+
+/**
+ * 资源加载器
+ */
+private ResourceLoader resourceLoader;
+/**
+ * 主要的 Java Config 类的数组
+ */
+private Set<Class<?>> primarySources;
+/**
+ * Web 应用类型
+ */
+private WebApplicationType webApplicationType;
+
+/**
+ * ApplicationContextInitializer 数组
+ */
+private List<ApplicationContextInitializer<?>> initializers;
+/**
+ * ApplicationListener 数组
+ */
+private List<ApplicationListener<?>> listeners;
+
+public SpringApplication(Class<?>... primarySources) {
+    this(null, primarySources);
+}
+
+public SpringApplication(ResourceLoader resourceLoader, Class<?>... primarySources) {
+    this.resourceLoader = resourceLoader;
+    Assert.notNull(primarySources, "PrimarySources must not be null");
+    this.primarySources = new LinkedHashSet<>(Arrays.asList(primarySources));
+    this.webApplicationType = WebApplicationType.deduceFromClasspath();
+    // 初始化 initializers 属性
+    setInitializers((Collection) getSpringFactoriesInstances(ApplicationContextInitializer.class));
+    // 初始化 listeners 属性
+    setListeners((Collection) getSpringFactoriesInstances(ApplicationListener.class));
+    this.mainApplicationClass = deduceMainApplicationClass();
+}
+```
+
+- SpringApplication 的变量比较多，我们先只看构造方法提到的几个。
+
+- `resourceLoader` 属性，资源加载器。可以暂时不理解，感兴趣的胖友，可以看看 [《【死磕 Spring】—— IoC 之 Spring 统一资源加载策略》](http://svip.iocoder.cn/Spring/IoC-load-Resource/?vip) 文章。
+
+- `primarySources` 属性，主要的 Java Config 类的数组。在文初提供的示例，就是 MVCApplication 类。
+
+- ```
+  webApplicationType
+  ```
+
+   
+
+  属性，调用
+
+   
+
+  ```
+  WebApplicationType#deduceFromClasspath()
+  ```
+
+   
+
+  方法，通过 classpath ，判断 Web 应用类型。
+
+  - 具体的原理是，是否存在指定的类，艿艿已经在 [WebApplicationType](https://github.com/YunaiV/spring-boot/blob/master/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/WebApplicationType.java) 上的方法添加了注释，直接瞅一眼就明白了。
+  - 这个属性，在下面的 `#createApplicationContext()` 方法，将根据它的值（类型），创建不同类型的 ApplicationContext 对象，即 Spring 容器的类型不同。
+
+- ```
+  initializers
+  ```
+
+   
+
+  属性，ApplicationContextInitializer 数组。
+
+  - 通过 `#getSpringFactoriesInstances(Class<T> type)` 方法，进行获得 ApplicationContextInitializer 类型的对象数组，详细的解析，见 [「2.1.1 getSpringFactoriesInstances」](https://svip.iocoder.cn/Spring-Boot/SpringApplication/#) 方法。
+  - 假设只在 Spring MVC 的环境下，`initializers` 属性的结果如下图：[![`initializers` 属性](07-Spring Boot 源码分析-SpringApplication.assets/01.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-01-07/01.jpg)`initializers` 属性
+
+- ```
+  listeners
+  ```
+
+   
+
+  属性，ApplicationListener 数组。
+
+  - 也是通过 `#getSpringFactoriesInstances(Class<T> type)` 方法，进行获得 ApplicationListener 类型的对象数组。
+  - 假设只在 Spring MVC 的环境下，`listeners` 属性的结果如下图：[![`listeners` 属性](07-Spring Boot 源码分析-SpringApplication.assets/02.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-01-07/02.jpg)`listeners` 属性
+
+- `mainApplicationClass` 属性，调用 `#deduceMainApplicationClass()` 方法，获得是调用了哪个 `#main(String[] args)` 方法，代码如下：
+
+  ```
+  // SpringApplication.java
+  
+  private Class<?> deduceMainApplicationClass() {
+  	try {
+  		// 获得当前 StackTraceElement 数组
+  		StackTraceElement[] stackTrace = new RuntimeException().getStackTrace();
+  		// 判断哪个执行了 main 方法
+  		for (StackTraceElement stackTraceElement : stackTrace) {
+  			if ("main".equals(stackTraceElement.getMethodName())) {
+  				return Class.forName(stackTraceElement.getClassName());
+  			}
+  		}
+  	} catch (ClassNotFoundException ex) {
+  		// Swallow and continue
+  	}
+  	return null;
+  }
+  ```
+
+  - 在文初的例子中，就是 MVCApplication 类。
+  - 这个 `mainApplicationClass` 属性，没有什么逻辑上的用途，主要就是用来打印下日志，说明是通过这个类启动 Spring 应用的。
+
+### 2.1.1 getSpringFactoriesInstances
+
+`#getSpringFactoriesInstances(Class<T> type)` 方法，获得指定类类对应的对象们。代码如下：
+
+```
+// SpringApplication.java
+
+private <T> Collection<T> getSpringFactoriesInstances(Class<T> type) {
+    return getSpringFactoriesInstances(type, new Class<?>[] {});
+}
+
+private <T> Collection<T> getSpringFactoriesInstances(Class<T> type,
+        Class<?>[] parameterTypes, Object... args) {
+    ClassLoader classLoader = getClassLoader();
+    // Use names and ensure unique to protect against duplicates
+    // <1> 加载指定类型对应的，在 `META-INF/spring.factories` 里的类名的数组
+    Set<String> names = new LinkedHashSet<>(
+            SpringFactoriesLoader.loadFactoryNames(type, classLoader));
+    // <2> 创建对象们
+    List<T> instances = createSpringFactoriesInstances(type, parameterTypes,
+            classLoader, args, names);
+    // <3> 排序对象们
+    AnnotationAwareOrderComparator.sort(instances);
+    return instances;
+}
+```
+
+- ```
+  <1>
+  ```
+
+   
+
+  处，调用
+
+   
+
+  ```
+  SpringFactoriesLoader#loadFactoryNames(Class<?> factoryClass, ClassLoader classLoader)
+  ```
+
+   
+
+  方法，加载指定类型对应的，在
+
+   
+
+  ```
+  META-INF/spring.factories
+  ```
+
+   
+
+  里的类名的数组。
+
+  - 在 [`META-INF/spring.factories`](https://github.com/YunaiV/spring-boot/blob/master/spring-boot-project/spring-boot-autoconfigure/src/main/resources/META-INF/spring.factories) 文件中，会以 KEY-VALUE 的格式，配置每个类对应的实现类们。
+  - 关于 SpringFactoriesLoader 的该方法，我们就不去细看了。😈 很多时候，我们看源码的时候，不需要陷入到每个方法的细节中。非关键的方法，猜测到具体的用途后，跳过也是没问题的。
+
+- `<2>` 处，调用 `#createSpringFactoriesInstances(Class<T> type, Class<?>[] parameterTypes, ClassLoader classLoader, Object[] args, Set<String> names)` 方法，创建对象们。代码如下：
+
+  ```
+  // SpringApplication.java
+  
+  /**
+   * 创建对象的数组
+   *
+   * @param type 父类
+   * @param parameterTypes 构造方法的参数类型
+   * @param classLoader 类加载器
+   * @param args 参数
+   * @param names 类名的数组
+   * @param <T> 泛型
+   * @return 对象的数组
+   */
+  private <T> List<T> createSpringFactoriesInstances(Class<T> type,
+  		Class<?>[] parameterTypes, ClassLoader classLoader, Object[] args,
+  		Set<String> names) {
+  	List<T> instances = new ArrayList<>(names.size()); // 数组大小，细节~
+  	// 遍历 names 数组
+  	for (String name : names) {
+  		try {
+  			// 获得 name 对应的类
+  			Class<?> instanceClass = ClassUtils.forName(name, classLoader);
+  			// 判断类是否实现自 type 类
+  			Assert.isAssignable(type, instanceClass);
+  			// 获得构造方法
+  			Constructor<?> constructor = instanceClass.getDeclaredConstructor(parameterTypes);
+  			// 创建对象
+  			T instance = (T) BeanUtils.instantiateClass(constructor, args);
+  			instances.add(instance);
+  		} catch (Throwable ex) {
+  			throw new IllegalArgumentException("Cannot instantiate " + type + " : " + name, ex);
+  		}
+  	}
+  	return instances;
+  }
+  ```
+
+  - 比较简单，就不多做解释了。
+
+- `<3>` 处，调用 `AnnotationAwareOrderComparator#sort(List<?> list)` 方法，排序对象们。例如说，类上有 [`@Order`](https://www.jianshu.com/p/8442d21222ef) 注解。
+
+## 2.2 run
+
+`#run(String... args)` 方法，运行 Spring 应用。代码如下：
+
+> 艿艿：这是一个饱满的方法，所以逻辑比较多哈。
+
+```
+// SpringApplication.java
+
+public ConfigurableApplicationContext run(String... args) {
+    // <1> 创建 StopWatch 对象，并启动。StopWatch 主要用于简单统计 run 启动过程的时长。
+    StopWatch stopWatch = new StopWatch();
+    stopWatch.start();
+    //
+    ConfigurableApplicationContext context = null;
+    Collection<SpringBootExceptionReporter> exceptionReporters = new ArrayList<>();
+    // <2> 配置 headless 属性
+    configureHeadlessProperty();
+    // 获得 SpringApplicationRunListener 的数组，并启动监听
+    SpringApplicationRunListeners listeners = getRunListeners(args);
+    listeners.starting();
+    try {
+        // <3> 创建  ApplicationArguments 对象
+        ApplicationArguments applicationArguments = new DefaultApplicationArguments(args);
+        // <4> 加载属性配置。执行完成后，所有的 environment 的属性都会加载进来，包括 application.properties 和外部的属性配置。
+        ConfigurableEnvironment environment = prepareEnvironment(listeners, applicationArguments);
+        configureIgnoreBeanInfo(environment);
+        // <5> 打印 Spring Banner
+        Banner printedBanner = printBanner(environment);
+        // <6> 创建 Spring 容器。
+        context = createApplicationContext();
+        // <7> 异常报告器
+        exceptionReporters = getSpringFactoriesInstances(
+                SpringBootExceptionReporter.class,
+                new Class[] { ConfigurableApplicationContext.class }, context);
+        // <8> 主要是调用所有初始化类的 initialize 方法
+        prepareContext(context, environment, listeners, applicationArguments,
+                printedBanner);
+        // <9> 初始化 Spring 容器。
+        refreshContext(context);
+        // <10> 执行 Spring 容器的初始化的后置逻辑。默认实现为空。
+        afterRefresh(context, applicationArguments);
+        // <11> 停止 StopWatch 统计时长
+        stopWatch.stop();
+        // <12> 打印 Spring Boot 启动的时长日志。
+        if (this.logStartupInfo) {
+            new StartupInfoLogger(this.mainApplicationClass).logStarted(getApplicationLog(), stopWatch);
+        }
+        // <13> 通知 SpringApplicationRunListener 的数组，Spring 容器启动完成。
+        listeners.started(context);
+        // <14> 调用 ApplicationRunner 或者 CommandLineRunner 的运行方法。
+        callRunners(context, applicationArguments);
+    } catch (Throwable ex) {
+        // <14.1> 如果发生异常，则进行处理，并抛出 IllegalStateException 异常
+        handleRunFailure(context, ex, exceptionReporters, listeners);
+        throw new IllegalStateException(ex);
+    }
+
+    // <15> 通知 SpringApplicationRunListener 的数组，Spring 容器运行中。
+    try {
+        listeners.running(context);
+    } catch (Throwable ex) {
+        // <15.1> 如果发生异常，则进行处理，并抛出 IllegalStateException 异常
+        handleRunFailure(context, ex, exceptionReporters, null);
+        throw new IllegalStateException(ex);
+    }
+    return context;
+}
+```
+
+- `<1>` 处，创建 StopWatch 对象，并调用 `StopWatch#run()` 方法来启动。StopWatch 主要用于简单统计 run 启动过程的时长。
+
+- `<2>` 处，配置 headless 属性。这个逻辑，可以无视，和 AWT 相关。
+
+- `<3>` 处，调用 `#getRunListeners(String[] args)` 方法，获得 SpringApplicationRunListener 数组，并启动监听。代码如下：
+
+  ```
+  // SpringApplication.java
+  
+  private SpringApplicationRunListeners getRunListeners(String[] args) {
+  	Class<?>[] types = new Class<?>[] { SpringApplication.class, String[].class };
+  	return new SpringApplicationRunListeners(logger, getSpringFactoriesInstances(
+  			SpringApplicationRunListener.class, types, this, args));
+  }
+  ```
+
+  - 此处的 `listeners` 变量，如下图所示：[![`listeners` 属性](07-Spring Boot 源码分析-SpringApplication.assets/03.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-01-07/03.jpg)`listeners` 属性
+  - 注意噢，此时是 SpringApplication**Run**Listener ，而不是我们看到 `listeners` 的 ApplicationListener 类型。详细的，我们在 [「3. SpringApplicationRunListeners」](https://svip.iocoder.cn/Spring-Boot/SpringApplication/#) 中，在详细解析。
+
+- `<4>` 处，调用 `#prepareEnvironment(SpringApplicationRunListeners listeners, ApplicationArguments applicationArguments)` 方法，加载属性配置。执行完成后，所有的 environment 的属性都会加载进来，包括 `application.properties` 和外部的属性配置。详细的，胖友先一起跳到 [「2.2.1 prepareEnvironment」](https://svip.iocoder.cn/Spring-Boot/SpringApplication/#) 中。
+
+- `<5>` 处，调用 `#printBanner(ConfigurableEnvironment environment)` 方法，打印 Spring Banner 。效果如下：
+
+  ```
+    .   ____          _            __ _ _
+   /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
+  ( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
+   \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
+    '  |____| .__|_| |_|_| |_\__, | / / / /
+   =========|_|==============|___/=/_/_/_/
+   :: Spring Boot ::
+  ```
+
+  - 具体的代码实现，就先不分析了。感兴趣的胖友，自己去瞅瞅。
+
+- `<6>` 处，调用 `#createApplicationContext()` 方法，创建 Spring 容器。详细解析，见 [「2.2.2 createApplicationContext」](https://svip.iocoder.cn/Spring-Boot/SpringApplication/#) 。
+
+- ```
+  <7>
+  ```
+
+   
+
+  处，通过
+
+   
+
+  ```
+  #getSpringFactoriesInstances(Class<T> type)
+  ```
+
+   
+
+  方法，进行获得 SpringBootExceptionReporter 类型的对象数组。SpringBootExceptionReporter ，记录启动过程中的异常信息。
+
+  - 此处，`exceptionReporters` 属性的结果如下图：[![`listeners` 属性](07-Spring Boot 源码分析-SpringApplication.assets/04.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-01-07/04.jpg)`listeners` 属性
+  - 关于 SpringBootExceptionReporter ，感兴趣的胖友，自己研究先。
+
+- `<8>` 处，调用 `#prepareContext(...)` 方法，主要是调用所有初始化类的 `#initialize(...)` 方法。详细解析，见 [「2.2.3 prepareContext」](https://svip.iocoder.cn/Spring-Boot/SpringApplication/#) 。
+
+- `<9>` 处，调用 ``#refreshContext(ConfigurableApplicationContext context)` 方法，启动（刷新） Spring 容器。详细解析，见 [「2.2.4 refreshContext」](https://svip.iocoder.cn/Spring-Boot/SpringApplication/#) 。
+
+- `<10>` 处，调用 `#afterRefresh(ConfigurableApplicationContext context, ApplicationArguments args)` 方法，执行 Spring 容器的初始化的后置逻辑。**默认实现为空**。代码如下：
+
+  ```
+  // SpringApplication.java
+  
+  protected void afterRefresh(ConfigurableApplicationContext context, ApplicationArguments args) {
+  }
+  ```
+
+- `<11>` 处，停止 StopWatch 统计时长。
+
+- `<12>` 处，打印 Spring Boot 启动的时长日志。效果如下：
+
+  ```
+  2019-01-28 20:42:03.338  INFO 53001 --- [           main] c.iocoder.springboot.mvc.MVCApplication  : Started MVCApplication in 20.893 seconds (JVM running for 23.536)
+  ```
+
+- `<13>` 处，调用 `SpringApplicationRunListeners#started(ConfigurableApplicationContext context)` 方法，通知 SpringApplicationRunListener 的数组，Spring 容器启动完成。
+
+- ```
+  <14>
+  ```
+
+   
+
+  处，调用
+
+   
+
+  ```
+  #callRunners(ApplicationContext context, ApplicationArguments args)
+  ```
+
+   
+
+  方法，调用 ApplicationRunner 或者 CommandLineRunner 的运行方法。详细解析，见
+
+   
+
+  「2.2.5 callRunners」
+
+   
+
+  。
+
+  - `<14.1>` 处，如果发生异常，则调用 `#handleRunFailure(...)` 方法，交给 SpringBootExceptionReporter 进行处理，并抛出 IllegalStateException 异常。
+
+- ```
+  <15>
+  ```
+
+   
+
+  处，调用
+
+   
+
+  ```
+  SpringApplicationRunListeners#running(ConfigurableApplicationContext context)
+  ```
+
+   
+
+  方法，通知 SpringApplicationRunListener 的数组，Spring 容器运行中。
+
+  - `<15.1>` 处，如果发生异常，则调用 `#handleRunFailure(...)` 方法，交给 SpringBootExceptionReporter 进行处理，并抛出 IllegalStateException 异常。
+
+### 2.2.1 prepareEnvironment
+
+> 艿艿：这个方法，大体看下即可。
+
+`#prepareEnvironment(SpringApplicationRunListeners listeners, ApplicationArguments applicationArguments)` 方法，加载属性配置。代码如下：
+
+```
+// SpringApplication.java
+
+private ConfigurableEnvironment prepareEnvironment(SpringApplicationRunListeners listeners, ApplicationArguments applicationArguments) {
+	// Create and configure the environment
+	// <1> 创建 ConfigurableEnvironment 对象，并进行配置
+	ConfigurableEnvironment environment = getOrCreateEnvironment();
+	configureEnvironment(environment, applicationArguments.getSourceArgs());
+	// <2> 通知 SpringApplicationRunListener 的数组，环境变量已经准备完成。
+	listeners.environmentPrepared(environment);
+	// <3> 绑定 environment 到 SpringApplication 上
+	bindToSpringApplication(environment);
+	// <4> 如果非自定义 environment ，则根据条件转换
+	if (!this.isCustomEnvironment) {
+		environment = new EnvironmentConverter(getClassLoader()).convertEnvironmentIfNecessary(environment, deduceEnvironmentClass());
+	}
+	// <5> 如果有 attach 到 environment 上的 MutablePropertySources ，则添加到 environment 的 PropertySource 中。
+	ConfigurationPropertySources.attach(environment);
+	return environment;
+}
+```
+
+- `<1>` 处，调用 `#getOrCreateEnvironment()` 方法，创建 ConfigurableEnvironment 对象。代码如下：
+
+  ```
+  // SpringApplication.java
+  
+  private ConfigurableEnvironment getOrCreateEnvironment() {
+  	// 已经存在，则进行返回
+  	if (this.environment != null) {
+  		return this.environment;
+  	}
+  	// 不存在，则根据 webApplicationType 类型，进行创建。
+  	switch (this.webApplicationType) {
+          case SERVLET:
+              return new StandardServletEnvironment();
+          case REACTIVE:
+              return new StandardReactiveWebEnvironment();
+          default:
+              return new StandardEnvironment();
+  	}
+  }
+  ```
+
+  - 根据 `webApplicationType` 类型，会创建不同类型的 ConfigurableEnvironment 对象。
+  - 例如说，Servlet 需要考虑 `<servletContextInitParams />` 和 `<servletConfigInitParams />` 等配置参数。
+
+- `<1>` 处，调用 `#configureEnvironment(ConfigurableEnvironment environment, String[] args)` 方法，配置 `environment` 变量。代码如下：
+
+  ```
+     // SpringApplication.java
+     
+     /**
+      * 是否添加共享的 ConversionService
+      */
+  private boolean addConversionService = true;
+     
+     protected void configureEnvironment(ConfigurableEnvironment environment, String[] args) {
+     	// <1.1> 设置 environment 的 conversionService 属性
+     	if (this.addConversionService) {
+     		ConversionService conversionService = ApplicationConversionService.getSharedInstance();
+     		environment.setConversionService((ConfigurableConversionService) conversionService);
+     	}
+     	// <1.2> 增加 environment 的 PropertySource 属性源
+     	configurePropertySources(environment, args);
+     	// <1.3> 配置 environment 的 activeProfiles 属性
+     	configureProfiles(environment, args);
+     }
+  ```
+
+  - `<1.1>` 处，设置 `environment` 的 `conversionService` 属性。可以暂时无视。感兴趣的胖友，可以看看 [《【死磕 Spring】—— 环境 & 属性：PropertySource、Environment、Profile》](http://svip.iocoder.cn/Spring/PropertySource-and-Environment-and-Profile/)
+
+  - `<1.2>` 处，增加 `environment` 的 PropertySource 属性源。代码如下：
+
+    ```
+       // SpringApplication.java
+       
+       /**
+        * 是否添加 JVM 启动参数
+        */
+       private boolean addCommandLineProperties = true;
+       /**
+        * 默认的属性集合
+        */
+    private Map<String, Object> defaultProperties;
+       
+       protected void configurePropertySources(ConfigurableEnvironment environment,
+       		String[] args) {
+       	MutablePropertySources sources = environment.getPropertySources();
+       	// 配置的 defaultProperties
+       	if (this.defaultProperties != null && !this.defaultProperties.isEmpty()) {
+       		sources.addLast(new MapPropertySource("defaultProperties", this.defaultProperties));
+       	}
+       	// 来自启动参数的
+       	if (this.addCommandLineProperties && args.length > 0) {
+       		String name = CommandLinePropertySource.COMMAND_LINE_PROPERTY_SOURCE_NAME;
+       		if (sources.contains(name)) { // 已存在，就进行替换
+       			PropertySource<?> source = sources.get(name);
+       			CompositePropertySource composite = new CompositePropertySource(name);
+       			composite.addPropertySource(new SimpleCommandLinePropertySource(
+       					"springApplicationCommandLineArgs", args));
+       			composite.addPropertySource(source);
+       			sources.replace(name, composite);
+       		} else { // 不存在，就进行添加
+       			sources.addFirst(new SimpleCommandLinePropertySource(args));
+       		}
+       	}
+       }
+    ```
+
+    - 代码上可以看出，可以根据配置的 `defaultProperties`、或者 JVM 启动参数，作为附加的 PropertySource 属性源。
+
+  - `<1.3>` 处，配置 `environment` 的 `activeProfiles` 属性。代码如下：
+
+    ```
+    // SpringApplication.java
+    
+    /**
+     * 附加的 profiles 的数组
+     */
+    private Set<String> additionalProfiles = new HashSet<>();
+    
+    protected void configureProfiles(ConfigurableEnvironment environment, String[] args) {
+    	environment.getActiveProfiles(); // ensure they are initialized 保证已经被初始化
+    	// But these ones should go first (last wins in a property key clash)
+    	Set<String> profiles = new LinkedHashSet<>(this.additionalProfiles);
+    	profiles.addAll(Arrays.asList(environment.getActiveProfiles()));
+    	// 设置 activeProfiles
+    	environment.setActiveProfiles(StringUtils.toStringArray(profiles));
+    }
+    ```
+
+    - 不了解 Profile 的胖友，可以看看 [《Spring Boot 激活 profile 的几种方式》](https://my.oschina.net/u/1469495/blog/1522784) 文章。
+
+- `<2>` 处，调用 `SpringApplicationRunListeners#environmentPrepared(ConfigurableEnvironment environment)` 方法，通知 SpringApplicationRunListener 的数组，环境变量已经准备完成。
+
+- `<3>` 处，调用 `#bindToSpringApplication(ConfigurableEnvironment environment)` 方法，绑定 `environment` 到 SpringApplication 上。暂时不太知道用途。
+
+- `<4>` 处，如果非自定义 `environment` ，则根据条件转换。默认情况下，`isCustomEnvironment` 为 `false` ，所以会执行这块逻辑。但是，一般情况下，返回的还是 `environment` 自身，所以可以无视这块逻辑先。
+
+- `<5>` 处，调用 `ConfigurationPropertySources#attach(Environment environment)` **静态**方法，如果有 attach 到 `environment`上的 MutablePropertySources ，则添加到 `environment` 的 PropertySource 中。这块逻辑，也可以先无视。
+
+### 2.2.2 createApplicationContext
+
+`#createApplicationContext()` 方法，创建 Spring 容器。代码如下：
+
+```
+// SpringApplication.java
+
+/**
+ * The class name of application context that will be used by default for non-web
+ * environments.
+ */
+public static final String DEFAULT_CONTEXT_CLASS = "org.springframework.context."
+		+ "annotation.AnnotationConfigApplicationContext";
+
+/**
+ * The class name of application context that will be used by default for web
+ * environments.
+ */
+public static final String DEFAULT_SERVLET_WEB_CONTEXT_CLASS = "org.springframework.boot."
+		+ "web.servlet.context.AnnotationConfigServletWebServerApplicationContext";
+
+/**
+ * The class name of application context that will be used by default for reactive web
+ * environments.
+ */
+public static final String DEFAULT_REACTIVE_WEB_CONTEXT_CLASS = "org.springframework."
+		+ "boot.web.reactive.context.AnnotationConfigReactiveWebServerApplicationContext";
+
+protected ConfigurableApplicationContext createApplicationContext() {
+    // 根据 webApplicationType 类型，获得 ApplicationContext 类型
+	Class<?> contextClass = this.applicationContextClass;
+	if (contextClass == null) {
+		try {
+			switch (this.webApplicationType) {
+			case SERVLET:
+				contextClass = Class.forName(DEFAULT_SERVLET_WEB_CONTEXT_CLASS);
+				break;
+			case REACTIVE:
+				contextClass = Class.forName(DEFAULT_REACTIVE_WEB_CONTEXT_CLASS);
+				break;
+			default:
+				contextClass = Class.forName(DEFAULT_CONTEXT_CLASS);
+			}
+		} catch (ClassNotFoundException ex) {
+			throw new IllegalStateException("Unable create a default ApplicationContext, " + "please specify an ApplicationContextClass", ex);
+		}
+	}
+	// 创建 ApplicationContext 对象
+	return (ConfigurableApplicationContext) BeanUtils.instantiateClass(contextClass);
+}
+```
+
+- 根据 `webApplicationType` 类型，获得对应的 ApplicationContext 对象。
+
+### 2.2.3 prepareContext
+
+`#prepareContext(ConfigurableApplicationContext context, ConfigurableEnvironment environment, SpringApplicationRunListeners listeners, ApplicationArguments applicationArguments, Banner printedBanner)` 方法，准备 ApplicationContext 对象，主要是初始化它的一些属性。代码如下：
+
+```
+// SpringApplication.java
+
+private void prepareContext(ConfigurableApplicationContext context,
+        ConfigurableEnvironment environment, SpringApplicationRunListeners listeners,
+        ApplicationArguments applicationArguments, Banner printedBanner) {
+    // <1> 设置 context 的 environment 属性
+    context.setEnvironment(environment);
+    // <2> 设置 context 的一些属性
+    postProcessApplicationContext(context);
+    // <3> 初始化 ApplicationContextInitializer
+    applyInitializers(context);
+    // <4> 通知 SpringApplicationRunListener 的数组，Spring 容器准备完成。
+    listeners.contextPrepared(context);
+    // <5> 打印日志
+    if (this.logStartupInfo) {
+        logStartupInfo(context.getParent() == null);
+        logStartupProfileInfo(context);
+    }
+    // Add boot specific singleton beans
+    // <6> 设置 beanFactory 的属性
+    ConfigurableListableBeanFactory beanFactory = context.getBeanFactory();
+    beanFactory.registerSingleton("springApplicationArguments", applicationArguments);
+    if (printedBanner != null) {
+        beanFactory.registerSingleton("springBootBanner", printedBanner);
+    }
+    if (beanFactory instanceof DefaultListableBeanFactory) {
+        ((DefaultListableBeanFactory) beanFactory).setAllowBeanDefinitionOverriding(this.allowBeanDefinitionOverriding);
+    }
+    // Load the sources
+    // <7> 加载 BeanDefinition 们
+    Set<Object> sources = getAllSources();
+    Assert.notEmpty(sources, "Sources must not be empty");
+    load(context, sources.toArray(new Object[0]));
+    // <8> 通知 SpringApplicationRunListener 的数组，Spring 容器加载完成。
+    listeners.contextLoaded(context);
+}
+```
+
+- 这个方法，还是蛮长的，主要是给 `context` 的属性做赋值，以及 ApplicationContextInitializer 的初始化。
+
+- `<1>` 处，设置 `context` 的 `environment` 属性。
+
+- `<2>` 处，调用 `#postProcessApplicationContext(ConfigurableApplicationContext context)` 方法，设置 `context` 的一些属性。代码如下：
+
+  ```
+  // SpringApplication.java
+  
+  protected void postProcessApplicationContext(ConfigurableApplicationContext context) {
+  	if (this.beanNameGenerator != null) {
+  		context.getBeanFactory().registerSingleton(AnnotationConfigUtils.CONFIGURATION_BEAN_NAME_GENERATOR, this.beanNameGenerator);
+  	}
+  	if (this.resourceLoader != null) {
+  		if (context instanceof GenericApplicationContext) {
+  			((GenericApplicationContext) context).setResourceLoader(this.resourceLoader);
+  		}
+  		if (context instanceof DefaultResourceLoader) {
+  			((DefaultResourceLoader) context).setClassLoader(this.resourceLoader.getClassLoader());
+  		}
+  	}
+  	if (this.addConversionService) {
+  		context.getBeanFactory().setConversionService(ApplicationConversionService.getSharedInstance());
+  	}
+  }
+  ```
+
+- `<3>` 处，调用 `#applyInitializers(ConfigurableApplicationContext context)` 方法，初始化 ApplicationContextInitializer 。代码如下：
+
+  ```
+  // SpringApplication.java
+  
+  protected void applyInitializers(ConfigurableApplicationContext context) {
+  	// 遍历 ApplicationContextInitializer 数组
+  	for (ApplicationContextInitializer initializer : getInitializers()) {
+  	    // 校验 ApplicationContextInitializer 的泛型非空
+  		Class<?> requiredType = GenericTypeResolver.resolveTypeArgument(
+  				initializer.getClass(), ApplicationContextInitializer.class);
+  		Assert.isInstanceOf(requiredType, context, "Unable to call initializer.");
+  		// 初始化 ApplicationContextInitializer
+  		initializer.initialize(context);
+  	}
+  }
+  ```
+
+  - 遍历 ApplicationContextInitializer 数组，逐个调用 `ApplicationContextInitializer#initialize(context)` 方法，进行初始化。
+
+- `<4>` 处，调用 `SpringApplicationRunListeners#contextPrepared(ConfigurableApplicationContext context)` 方法，通知 SpringApplicationRunListener 的数组，Spring 容器准备完成。
+
+- `<5>` 处，打印日志。效果如下：
+
+  ```
+  2019-01-28 17:53:31.600  INFO 21846 --- [           main] c.iocoder.springboot.mvc.MVCApplication  : Starting MVCApplication on MacBook-Pro-5.local with PID 21846 (/Users/yunai/Java/spring-boot/spring-boot-tests/spring-boot-yunai-tests/spring-boot-yunai-mvc-tests/target/classes started by yunai in /Users/yunai/Java/spring-boot)
+  2019-01-28 17:53:40.028  INFO 21846 --- [           main] c.iocoder.springboot.mvc.MVCApplication  : The following profiles are active: prod
+  ```
+
+  - 具体的方法逻辑，胖友自己瞅瞅哈。
+
+- `<6>` 处，设置 `beanFactory` 的属性。
+
+- `<7>` 处，调用 `#load(ApplicationContext context, Object[] sources)` 方法，加载 BeanDefinition 们。代码如下：
+
+  ```
+  // SpringApplication.java
+  
+  protected void load(ApplicationContext context, Object[] sources) {
+  	if (logger.isDebugEnabled()) {
+  		logger.debug("Loading source " + StringUtils.arrayToCommaDelimitedString(sources));
+  	}
+  	// <1> 创建 BeanDefinitionLoader 对象
+  	BeanDefinitionLoader loader = createBeanDefinitionLoader(getBeanDefinitionRegistry(context), sources);
+  	// <2> 设置 loader 的属性
+  	if (this.beanNameGenerator != null) {
+  		loader.setBeanNameGenerator(this.beanNameGenerator);
+  	}
+  	if (this.resourceLoader != null) {
+  		loader.setResourceLoader(this.resourceLoader);
+  	}
+  	if (this.environment != null) {
+  		loader.setEnvironment(this.environment);
+  	}
+  	// <3> 执行 BeanDefinition 加载
+  	loader.load();
+  }
+  ```
+
+  - `<1>` 处，调用 `#getBeanDefinitionRegistry(ApplicationContext context)` 方法，创建 BeanDefinitionRegistry 对象。代码如下：
+
+    ```
+    // SpringApplication.java
+    
+    private BeanDefinitionRegistry getBeanDefinitionRegistry(ApplicationContext context) {
+    	if (context instanceof BeanDefinitionRegistry) {
+    		return (BeanDefinitionRegistry) context;
+    	}
+    	if (context instanceof AbstractApplicationContext) {
+    		return (BeanDefinitionRegistry) ((AbstractApplicationContext) context)
+    				.getBeanFactory();
+    	}
+    	throw new IllegalStateException("Could not locate BeanDefinitionRegistry");
+    }
+    ```
+
+    - 关于 BeanDefinitionRegistry 类，暂时不需要深入了解。感兴趣的胖友，可以看看 [《【死磕 Spring】—— IoC 之 BeanDefinition 注册表：BeanDefinitionRegistry》](http://svip.iocoder.cn/Spring/IoC-BeanDefinitionRegistry/) 文章。
+
+  - `<1>` 处，调用 `#createBeanDefinitionLoader(BeanDefinitionRegistry registry, Object[] sources)` 方法，创建 `org.springframework.boot.BeanDefinitionLoader` 对象。关于它，后续的文章，详细解析。
+
+  - `<2>` 处，设置 `loader` 的属性。
+
+  - `<3>` 处，调用 `BeanDefinitionLoader#load()` 方法，执行 BeanDefinition 加载。关于这一块，胖友感兴趣，先简单看看 [《【死磕 Spring】—— IoC 之加载 BeanDefinition》](http://svip.iocoder.cn/Spring/IoC-load-BeanDefinitions/) 文章。
+
+- `<8>` 处，调用 `SpringApplicationRunListeners#contextLoaded(ConfigurableApplicationContext context)` 方法，通知 SpringApplicationRunListener 的数组，Spring 容器加载完成。
+
+### 2.2.4 refreshContext
+
+`#refreshContext(ConfigurableApplicationContext context)` 方法，启动（刷新） Spring 容器。代码如下：
+
+```
+// SpringApplication.java
+
+/**
+ * 是否注册 ShutdownHook 钩子
+ */
+private boolean registerShutdownHook = true;
+
+private void refreshContext(ConfigurableApplicationContext context) {
+	// <1> 开启（刷新）Spring 容器
+	refresh(context);
+	// <2> 注册 ShutdownHook 钩子
+	if (this.registerShutdownHook) {
+		try {
+			context.registerShutdownHook();
+		} catch (AccessControlException ex) {
+			// Not allowed in some environments.
+		}
+	}
+}
+```
+
+- `<1>` 处，调用 `#refresh(ApplicationContext applicationContext)` 方法，开启（刷新）Spring 容器。代码如下：
+
+  ```
+  // SpringApplication.java
+  
+  protected void refresh(ApplicationContext applicationContext) {
+  	// 断言，判断 applicationContext 是 AbstractApplicationContext 的子类
+  	Assert.isInstanceOf(AbstractApplicationContext.class, applicationContext);
+  	// 启动（刷新） AbstractApplicationContext
+  	((AbstractApplicationContext) applicationContext).refresh();
+  }
+  ```
+
+  - 调用
+
+     
+
+    ```
+    AbstractApplicationContext#refresh()
+    ```
+
+     
+
+    方法，启动（刷新）Spring 容器。
+
+    - `AbstractApplicationContext#refresh()` 方法，胖友可以看看 [《【死磕 Spring】—— ApplicationContext 相关接口架构分析》](http://svip.iocoder.cn/Spring/ApplicationContext/) 文章。
+    - 这里，可以触发 Spring Boot 的自动配置的功能。关于这一块，我们会在下一篇文章，详细解析。
+
+- `<2>` 处，调用 `ConfigurableApplicationContext#registerShutdownHook()` 方法，注册 ShutdownHook 钩子。这个钩子，主要用于 Spring 应用的关闭时，销毁相应的 Bean 们。
+
+### 2.2.5 callRunners
+
+`#callRunners(ApplicationContext context, ApplicationArguments args)` 方法，调用 ApplicationRunner 或者 CommandLineRunner 的运行方法。代码如下：
+
+```
+// SpringApplication.java
+
+private void callRunners(ApplicationContext context, ApplicationArguments args) {
+    // <1> 获得所有 Runner 们
+    List<Object> runners = new ArrayList<>();
+    // <1.1> 获得所有 ApplicationRunner Bean 们
+    runners.addAll(context.getBeansOfType(ApplicationRunner.class).values());
+    // <1.2> 获得所有 CommandLineRunner Bean 们
+    runners.addAll(context.getBeansOfType(CommandLineRunner.class).values());
+    // <1.3> 排序 runners
+    AnnotationAwareOrderComparator.sort(runners);
+    // <2> 遍历 Runner 数组，执行逻辑
+    for (Object runner : new LinkedHashSet<>(runners)) {
+        if (runner instanceof ApplicationRunner) {
+            callRunner((ApplicationRunner) runner, args);
+        }
+        if (runner instanceof CommandLineRunner) {
+            callRunner((CommandLineRunner) runner, args);
+        }
+    }
+}
+```
+
+- `<1>` 处，获得所有 Runner 们，并进行排序。
+
+- `<2>` 处，遍历 Runner 数组，执行逻辑。代码如下：
+
+  ```
+  // SpringApplication.java
+  
+  private void callRunner(ApplicationRunner runner, ApplicationArguments args) {
+  	try {
+  		(runner).run(args);
+  	} catch (Exception ex) {
+  		throw new IllegalStateException("Failed to execute ApplicationRunner", ex);
+  	}
+  }
+  
+  private void callRunner(CommandLineRunner runner, ApplicationArguments args) {
+  	try {
+  		(runner).run(args.getSourceArgs());
+  	} catch (Exception ex) {
+  		throw new IllegalStateException("Failed to execute CommandLineRunner", ex);
+  	}
+  }
+  ```
+
+关于 Runner 功能的使用，可以看看 [《ApplicationRunner 接口》](https://www.kancloud.cn/letiantian/learn-spring-boot/697172) 和 [《CommandLineRunner 接口》](https://www.kancloud.cn/letiantian/learn-spring-boot/696203) 文档。
+
+# 3. SpringApplicationRunListeners
+
+`org.springframework.boot.SpringApplicationRunListeners` ，SpringApplicationRunListener 数组的封装。代码如下：
+
+```
+// SpringApplicationRunListeners.java
+
+class SpringApplicationRunListeners {
+
+    private final Log log;
+
+    /**
+     * SpringApplicationRunListener 数组
+     */
+    private final List<SpringApplicationRunListener> listeners;
+
+    SpringApplicationRunListeners(Log log,
+            Collection<? extends SpringApplicationRunListener> listeners) {
+        this.log = log;
+        this.listeners = new ArrayList<>(listeners);
+    }
+
+    public void starting() {
+        for (SpringApplicationRunListener listener : this.listeners) {
+            listener.starting();
+        }
+    }
+
+    public void environmentPrepared(ConfigurableEnvironment environment) {
+        for (SpringApplicationRunListener listener : this.listeners) {
+            listener.environmentPrepared(environment);
+        }
+    }
+
+    public void contextPrepared(ConfigurableApplicationContext context) {
+        for (SpringApplicationRunListener listener : this.listeners) {
+            listener.contextPrepared(context);
+        }
+    }
+
+    public void contextLoaded(ConfigurableApplicationContext context) {
+        for (SpringApplicationRunListener listener : this.listeners) {
+            listener.contextLoaded(context);
+        }
+    }
+
+    public void started(ConfigurableApplicationContext context) {
+        for (SpringApplicationRunListener listener : this.listeners) {
+            listener.started(context);
+        }
+    }
+
+    public void running(ConfigurableApplicationContext context) {
+        for (SpringApplicationRunListener listener : this.listeners) {
+            listener.running(context);
+        }
+    }
+
+    public void failed(ConfigurableApplicationContext context, Throwable exception) {
+        for (SpringApplicationRunListener listener : this.listeners) {
+            callFailedListener(listener, context, exception);
+        }
+    }
+
+    private void callFailedListener(SpringApplicationRunListener listener, ConfigurableApplicationContext context, Throwable exception) {
+        try {
+            listener.failed(context, exception);
+        } catch (Throwable ex) {
+            if (exception == null) {
+                ReflectionUtils.rethrowRuntimeException(ex);
+            }
+            if (this.log.isDebugEnabled()) {
+                this.log.error("Error handling failed", ex);
+            } else {
+                String message = ex.getMessage();
+                message = (message != null) ? message : "no error message";
+                this.log.warn("Error handling failed (" + message + ")");
+            }
+        }
+    }
+
+}
+```
+
+## 3.1 SpringApplicationRunListener
+
+`org.springframework.boot.SpringApplicationRunListener` ，SpringApplication 运行的监听器接口。代码如下：
+
+```
+// SpringApplicationRunListener.java
+
+public interface SpringApplicationRunListener {
+
+	/**
+	 * Called immediately when the run method has first started. Can be used for very
+	 * early initialization.
+	 */
+	void starting();
+
+	/**
+	 * Called once the environment has been prepared, but before the
+	 * {@link ApplicationContext} has been created.
+	 * @param environment the environment
+	 */
+	void environmentPrepared(ConfigurableEnvironment environment);
+
+	/**
+	 * Called once the {@link ApplicationContext} has been created and prepared, but
+	 * before sources have been loaded.
+	 * @param context the application context
+	 */
+	void contextPrepared(ConfigurableApplicationContext context);
+
+	/**
+	 * Called once the application context has been loaded but before it has been
+	 * refreshed.
+	 * @param context the application context
+	 */
+	void contextLoaded(ConfigurableApplicationContext context);
+
+	/**
+	 * The context has been refreshed and the application has started but
+	 * {@link CommandLineRunner CommandLineRunners} and {@link ApplicationRunner
+	 * ApplicationRunners} have not been called.
+	 * @param context the application context.
+	 * @since 2.0.0
+	 */
+	void started(ConfigurableApplicationContext context);
+
+	/**
+	 * Called immediately before the run method finishes, when the application context has
+	 * been refreshed and all {@link CommandLineRunner CommandLineRunners} and
+	 * {@link ApplicationRunner ApplicationRunners} have been called.
+	 * @param context the application context.
+	 * @since 2.0.0
+	 */
+	void running(ConfigurableApplicationContext context);
+
+	/**
+	 * Called when a failure occurs when running the application.
+	 * @param context the application context or {@code null} if a failure occurred before
+	 * the context was created
+	 * @param exception the failure
+	 * @since 2.0.0
+	 */
+	void failed(ConfigurableApplicationContext context, Throwable exception);
+
+}
+```
+
+目前，SpringApplicationRunListener 的实现类，只有 EventPublishingRunListener 类。
+
+## 3.2 EventPublishingRunListener
+
+`org.springframework.boot.context.event.EventPublishingRunListener` ，实现 SpringApplicationRunListener、Ordered 接口，将 SpringApplicationRunListener 监听到的事件，转换成对应的 SpringApplicationEvent 事件，发布到监听器们。
+
+代码如下：
+
+```
+// EventPublishingRunListener.java
+
+public class EventPublishingRunListener implements SpringApplicationRunListener, Ordered {
+
+    /**
+     * Spring 应用
+     */
+    private final SpringApplication application;
+    /**
+     * 参数集合
+     */
+    private final String[] args;
+    /**
+     * 事件广播器
+     */
+    private final SimpleApplicationEventMulticaster initialMulticaster;
+
+    public EventPublishingRunListener(SpringApplication application, String[] args) {
+        this.application = application;
+        this.args = args;
+        // 创建 SimpleApplicationEventMulticaster 对象
+        this.initialMulticaster = new SimpleApplicationEventMulticaster();
+        // 添加应用的监听器们，到 initialMulticaster 中
+        for (ApplicationListener<?> listener : application.getListeners()) {
+            this.initialMulticaster.addApplicationListener(listener);
+        }
+    }
+
+    @Override
+    public int getOrder() {
+        return 0;
+    }
+
+    @Override
+    public void starting() {
+        this.initialMulticaster.multicastEvent(new ApplicationStartingEvent(this.application, this.args));
+    }
+
+    @Override // ApplicationEnvironmentPreparedEvent
+    public void environmentPrepared(ConfigurableEnvironment environment) {
+        this.initialMulticaster.multicastEvent(new ApplicationEnvironmentPreparedEvent(this.application, this.args, environment));
+    }
+
+    @Override // ApplicationContextInitializedEvent
+    public void contextPrepared(ConfigurableApplicationContext context) {
+        this.initialMulticaster.multicastEvent(new ApplicationContextInitializedEvent(this.application, this.args, context));
+    }
+
+    @Override // ApplicationPreparedEvent
+    public void contextLoaded(ConfigurableApplicationContext context) {
+        for (ApplicationListener<?> listener : this.application.getListeners()) {
+            if (listener instanceof ApplicationContextAware) {
+                ((ApplicationContextAware) listener).setApplicationContext(context);
+            }
+            context.addApplicationListener(listener);
+        }
+        this.initialMulticaster.multicastEvent(new ApplicationPreparedEvent(this.application, this.args, context));
+    }
+
+    @Override // ApplicationStartedEvent
+    public void started(ConfigurableApplicationContext context) {
+        context.publishEvent(new ApplicationStartedEvent(this.application, this.args, context));
+    }
+
+    @Override
+    public void running(ConfigurableApplicationContext context) {
+        context.publishEvent(new ApplicationReadyEvent(this.application, this.args, context));
+    }
+
+    @Override // ApplicationFailedEvent
+    public void failed(ConfigurableApplicationContext context, Throwable exception) {
+        ApplicationFailedEvent event = new ApplicationFailedEvent(this.application, this.args, context, exception);
+        if (context != null && context.isActive()) {
+            // Listeners have been registered to the application context so we should
+            // use it at this point if we can
+            context.publishEvent(event);
+        } else {
+            // An inactive context may not have a multicaster so we use our multicaster to
+            // call all of the context's listeners instead
+            if (context instanceof AbstractApplicationContext) {
+                for (ApplicationListener<?> listener : ((AbstractApplicationContext) context)
+                        .getApplicationListeners()) {
+                    this.initialMulticaster.addApplicationListener(listener);
+                }
+            }
+            this.initialMulticaster.setErrorHandler(new LoggingErrorHandler());
+            this.initialMulticaster.multicastEvent(event);
+        }
+    }
+
+    private static class LoggingErrorHandler implements ErrorHandler {
+
+        private static Log logger = LogFactory.getLog(EventPublishingRunListener.class);
+
+        @Override
+        public void handleError(Throwable throwable) {
+            logger.warn("Error calling ApplicationEventListener", throwable);
+        }
+
+    }
+
+}
+```
+
+- 代码比较简单，胖友自己瞅瞅就明白了。
+- 通过这样的方式，可以很方便的将 SpringApplication 启动的各种事件，方便的修改成对应的 SpringApplicationEvent 事件。这样，我们就可以不需要修改 SpringApplication 的代码。或者说，我们认为 EventPublishingRunListener 是一个“**转换器**”。
+
+关于 Spring Boot 的事件，可以看看 [《事件监听与发布》](https://www.kancloud.cn/letiantian/learn-spring-boot/712108) 文章。
+
+# 666. 彩蛋
+
+整块代码略微有点长，胖友一定一定一定自己调试下。总的来说，逻辑并不复杂，是吧？是吧！
+
+参考和推荐如下文章：
+
+- 快乐崇拜 [《Spring Boot 源码深入分析》](https://gitbook.cn/books/5a445f030173cb29d2041d61/index.html)
+
+  > 需要付费 3 块钱。你看，艿艿为了写好源码解析，还是去学习了下别人的博客。
+
+- 老田 [《Spring Boot 2.0 系列文章(七)：SpringApplication 深入探索》](http://www.54tianzhisheng.cn/2018/04/30/springboot_SpringApplication/)
+
+- oldflame-Jm [《Spring boot源码分析-SpringApplication启动（1）》](https://blog.csdn.net/jamet/article/details/77413189)
+
+- dm_vincent
+
+  - [《[Spring Boot\] 1. Spring Boot 启动过程源码分析》](https://blog.csdn.net/dm_vincent/article/details/76735888)
+  - [《[Spring Boot\] 2. Spring Boot 启动过程定制化》](https://blog.csdn.net/dm_vincent/article/details/77151122)
+
+- 一个努力的码农
+
+  > 设计 Spring Framework 的部分，他也写了一些~
+  >
+  > - [《spring boot 源码解析2-SpringApplication初始化》](https://blog.csdn.net/qq_26000415/article/details/78914752)
+  > - [《spring boot 源码解析3-SpringApplication#run》](https://blog.csdn.net/qq_26000415/article/details/78914803)
+  > - [《spring boot 源码解析4-SpringApplication#run第4步》](https://blog.csdn.net/qq_26000415/article/details/78914944)
+  > - [《spring boot 源码解析5-SpringApplication#run第5步》](https://blog.csdn.net/qq_26000415/article/details/78915135)
+  > - [《spring boot 源码解析6-SpringApplication#run第6步》](https://blog.csdn.net/qq_26000415/article/details/78915181)
+  > - [《spring boot 源码解析7-SpringApplication#run第7步》](https://blog.csdn.net/qq_26000415/article/details/78915189)
+  > - [《spring boot 源码解析8-SpringApplication#run第8步》](https://blog.csdn.net/qq_26000415/article/details/78915211)
+  > - [《spring boot 源码解析9-SpringApplication#run第9步》](https://blog.csdn.net/qq_26000415/article/details/78915221)
+  > - [《spring boot 源码解析10-SpringApplication#run第10-13步》](https://blog.csdn.net/qq_26000415/article/details/78915234)
\ No newline at end of file
diff --git a/springboot/08-Spring Boot 源码分析-自动配置.assets/01.jpg b/springboot/08-Spring Boot 源码分析-自动配置.assets/01.jpg
new file mode 100644
index 0000000..e8cf39f
Binary files /dev/null and b/springboot/08-Spring Boot 源码分析-自动配置.assets/01.jpg differ
diff --git a/springboot/08-Spring Boot 源码分析-自动配置.assets/02.jpg b/springboot/08-Spring Boot 源码分析-自动配置.assets/02.jpg
new file mode 100644
index 0000000..384dc3e
Binary files /dev/null and b/springboot/08-Spring Boot 源码分析-自动配置.assets/02.jpg differ
diff --git a/springboot/08-Spring Boot 源码分析-自动配置.assets/03.jpg b/springboot/08-Spring Boot 源码分析-自动配置.assets/03.jpg
new file mode 100644
index 0000000..6e80b59
Binary files /dev/null and b/springboot/08-Spring Boot 源码分析-自动配置.assets/03.jpg differ
diff --git a/springboot/08-Spring Boot 源码分析-自动配置.assets/04.jpg b/springboot/08-Spring Boot 源码分析-自动配置.assets/04.jpg
new file mode 100644
index 0000000..00f5ba1
Binary files /dev/null and b/springboot/08-Spring Boot 源码分析-自动配置.assets/04.jpg differ
diff --git a/springboot/08-Spring Boot 源码分析-自动配置.assets/05.jpg b/springboot/08-Spring Boot 源码分析-自动配置.assets/05.jpg
new file mode 100644
index 0000000..e39e2b4
Binary files /dev/null and b/springboot/08-Spring Boot 源码分析-自动配置.assets/05.jpg differ
diff --git a/springboot/08-Spring Boot 源码分析-自动配置.assets/06.jpg b/springboot/08-Spring Boot 源码分析-自动配置.assets/06.jpg
new file mode 100644
index 0000000..98002f9
Binary files /dev/null and b/springboot/08-Spring Boot 源码分析-自动配置.assets/06.jpg differ
diff --git a/springboot/08-Spring Boot 源码分析-自动配置.assets/07.jpg b/springboot/08-Spring Boot 源码分析-自动配置.assets/07.jpg
new file mode 100644
index 0000000..c58a565
Binary files /dev/null and b/springboot/08-Spring Boot 源码分析-自动配置.assets/07.jpg differ
diff --git a/springboot/08-Spring Boot 源码分析-自动配置.assets/08.jpg b/springboot/08-Spring Boot 源码分析-自动配置.assets/08.jpg
new file mode 100644
index 0000000..3b326eb
Binary files /dev/null and b/springboot/08-Spring Boot 源码分析-自动配置.assets/08.jpg differ
diff --git a/springboot/08-Spring Boot 源码分析-自动配置.assets/09.jpg b/springboot/08-Spring Boot 源码分析-自动配置.assets/09.jpg
new file mode 100644
index 0000000..97b139e
Binary files /dev/null and b/springboot/08-Spring Boot 源码分析-自动配置.assets/09.jpg differ
diff --git a/springboot/08-Spring Boot 源码分析-自动配置.assets/10.jpg b/springboot/08-Spring Boot 源码分析-自动配置.assets/10.jpg
new file mode 100644
index 0000000..fc100c7
Binary files /dev/null and b/springboot/08-Spring Boot 源码分析-自动配置.assets/10.jpg differ
diff --git a/springboot/08-Spring Boot 源码分析-自动配置.md b/springboot/08-Spring Boot 源码分析-自动配置.md
new file mode 100644
index 0000000..cf81033
--- /dev/null
+++ b/springboot/08-Spring Boot 源码分析-自动配置.md	
@@ -0,0 +1,983 @@
+# 精尽 Spring Boot 源码分析 —— 自动配置
+
+# 1. 概述
+
+本文，我们来分享 Spring Boot 自动配置的实现源码。在故事的开始，我们先来说两个事情：
+
+- 自动配置和自动装配的区别？
+- Spring Boot 配置的原理
+
+# 2. 自动配置 V.S 自动装配
+
+在这篇文章的开始，艿艿是有点混淆自动配置和自动装配的概念，后来经过 Google 之后，发现两者是截然不如同的：
+
+- 自动配置：是 Spring Boot 提供的，实现通过 jar 包的依赖，能够自动配置应用程序。例如说：我们引入 `spring-boot-starter-web` 之后，就自动引入了 Spring MVC 相关的 jar 包，从而自动配置 Spring MVC 。
+- 自动装配：是 Spring 提供的 IoC 注入方式，具体看看 [《Spring 教程 —— Beans 自动装配》](http://wiki.jikexueyuan.com/project/spring/beans-autowiring.html) 文档。
+
+所以，不要和艿艿一样愚蠢的搞错落。
+
+# 3. 自动装配原理
+
+胖友可以直接看 [《详解 Spring Boot 自动配置机制》](http://www.iocoder.cn/Spring-Boot/autoconfigure/?vip) 文章的 [「二、Spring Boot 自动配置」](https://svip.iocoder.cn/Spring-Boot/AutoConfiguration/#) 小节，艿艿觉得写的挺清晰的。
+
+> 下面，我们即开始正式撸具体的代码实现了。
+
+# 4. @SpringBootApplication
+
+`org.springframework.boot.autoconfigure.@SpringBootApplication` 注解，基本我们的 Spring Boot 应用，一定会去有这样一个注解。并且，通过使用它，不仅仅能标记这是一个 Spring Boot 应用，而且能够开启自动配置的功能。这是为什么呢？
+
+> 😈 `@SpringBootApplication` 注解，它在 `spring-boot-autoconfigure` 模块中。所以，我们使用 Spring Boot 项目时，如果不想使用自动配置功能，就不用引入它。当然，我们貌似不太会存在这样的需求，是吧~
+
+`@SpringBootApplication` 是一个**组合**注解。代码如下：
+
+```
+// SpringBootApplication.java
+
+@Target(ElementType.TYPE)
+@Retention(RetentionPolicy.RUNTIME)
+@Documented
+@Inherited
+@SpringBootConfiguration
+@EnableAutoConfiguration
+@ComponentScan(excludeFilters = {
+		@Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class),
+		@Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) })
+public @interface SpringBootApplication {
+
+	/**
+	 * Exclude specific auto-configuration classes such that they will never be applied.
+	 * @return the classes to exclude
+	 */
+	@AliasFor(annotation = EnableAutoConfiguration.class)
+	Class<?>[] exclude() default {};
+
+	/**
+	 * Exclude specific auto-configuration class names such that they will never be
+	 * applied.
+	 * @return the class names to exclude
+	 * @since 1.3.0
+	 */
+	@AliasFor(annotation = EnableAutoConfiguration.class)
+	String[] excludeName() default {};
+
+	/**
+	 * Base packages to scan for annotated components. Use {@link #scanBasePackageClasses}
+	 * for a type-safe alternative to String-based package names.
+	 * @return base packages to scan
+	 * @since 1.3.0
+	 */
+	@AliasFor(annotation = ComponentScan.class, attribute = "basePackages")
+	String[] scanBasePackages() default {};
+
+	/**
+	 * Type-safe alternative to {@link #scanBasePackages} for specifying the packages to
+	 * scan for annotated components. The package of each class specified will be scanned.
+	 * <p>
+	 * Consider creating a special no-op marker class or interface in each package that
+	 * serves no purpose other than being referenced by this attribute.
+	 * @return base packages to scan
+	 * @since 1.3.0
+	 */
+	@AliasFor(annotation = ComponentScan.class, attribute = "basePackageClasses")
+	Class<?>[] scanBasePackageClasses() default {};
+
+}
+```
+
+下面，我们来逐个看 `@SpringBootApplication` 上的每个注解。
+
+## 4.1 @Inherited
+
+> Java 自带的注解。
+
+`java.lang.annotation.@Inherited` 注解，使用此注解声明出来的自定义注解，在使用**此**自定义注解时，如果注解在类上面时，子类会自动继承此注解，否则的话，子类不会继承此注解。
+
+这里一定要记住，使用 `@Inherited` 声明出来的注解，只有在类上使用时才会有效，对方法，属性等其他无效。
+
+不了解的胖友，可以看看 [《关于 Java 注解中元注解 Inherited 的使用详解》](https://blog.csdn.net/snow_crazy/article/details/39381695) 文章。
+
+## 4.2 @SpringBootConfiguration
+
+> Spring Boot 自定义的注解
+
+`org.springframework.boot.@SpringBootConfiguration` 注解，标记这是一个 Spring Boot 配置类。代码如下：
+
+```
+// SpringBootConfiguration.java
+
+@Target(ElementType.TYPE)
+@Retention(RetentionPolicy.RUNTIME)
+@Documented
+@Configuration
+public @interface SpringBootConfiguration {
+
+}
+```
+
+- 可以看到，它上面继承自 `@Configuration` 注解，所以两者功能也一致，可以将当前类内声明的一个或多个以 `@Bean` 注解标记的方法的实例纳入到 Srping 容器中，并且实例名就是方法名。
+
+## 4.3 @ComponentScan
+
+> Spring 自定义的注解
+
+`org.springframework.context.annotation.@ComponentScan` 注解，扫描指定路径下的 Component（`@Componment`、`@Configuration`、`@Service` 等等）。
+
+不了解的胖友，可以看看 [《Spring：@ComponentScan 使用》](https://shihlei.iteye.com/blog/2405675) 文章。
+
+## 4.4 @EnableAutoConfiguration
+
+> Spring Boot 自定义的注解
+
+`org.springframework.boot.autoconfigure.@EnableAutoConfiguration` 注解，用于开启自动配置功能，是 `spring-boot-autoconfigure` 项目最核心的注解。代码如下：
+
+```
+// EnableAutoConfiguration.java
+
+@Target(ElementType.TYPE)
+@Retention(RetentionPolicy.RUNTIME)
+@Documented
+@Inherited
+@AutoConfigurationPackage
+@Import(AutoConfigurationImportSelector.class)
+public @interface EnableAutoConfiguration {
+
+	String ENABLED_OVERRIDE_PROPERTY = "spring.boot.enableautoconfiguration";
+
+	/**
+	 * Exclude specific auto-configuration classes such that they will never be applied.
+	 * @return the classes to exclude
+	 */
+	Class<?>[] exclude() default {};
+
+	/**
+	 * Exclude specific auto-configuration class names such that they will never be
+	 * applied.
+	 * @return the class names to exclude
+	 * @since 1.3.0
+	 */
+	String[] excludeName() default {};
+
+}
+```
+
+- `org.springframework.boot.autoconfigure.@AutoConfigurationPackage` 注解，主要功能自动配置包，它会获取主程序类所在的包路径，并将包路径（包括子包）下的所有组件注册到 Spring IOC 容器中。代码如下：
+
+  ```
+  // AutoConfigurationPackage.java
+  
+  @Target(ElementType.TYPE)
+  @Retention(RetentionPolicy.RUNTIME)
+  @Documented
+  @Inherited
+  @Import(AutoConfigurationPackages.Registrar.class)
+  public @interface AutoConfigurationPackage {
+  
+  }
+  ```
+
+  - `org.springframework.context.annotation.@Import` 注解，可用于资源的导入。情况比较多，可以看看 [《6、@Import 注解——导入资源》](https://blog.csdn.net/u010502101/article/details/78760032) 文章。
+  - AutoConfigurationPackages.Registrar ，有点神奇，这里先不说。胖友最后去看 [「6. AutoConfigurationPackages」](https://svip.iocoder.cn/Spring-Boot/AutoConfiguration/#) 小节。
+
+- `@Import(AutoConfigurationImportSelector.class)` 注解部分，是重头戏的开始。
+
+  - `org.springframework.context.annotation.@Import` 注解，可用于资源的导入。情况比较多，可以看看 [《6、@Import 注解——导入资源》](https://blog.csdn.net/u010502101/article/details/78760032) 文章。
+  - AutoConfigurationImportSelector ，导入自动配置相关的资源。详细解析，见 [「5. AutoConfigurationImportSelector」](https://svip.iocoder.cn/Spring-Boot/AutoConfiguration/#) 小节。
+
+# 5. AutoConfigurationImportSelector
+
+`org.springframework.boot.autoconfigure.AutoConfigurationImportSelector` ，实现 DeferredImportSelector、BeanClassLoaderAware、ResourceLoaderAware、BeanFactoryAware、EnvironmentAware、Ordered 接口，处理 `@EnableAutoConfiguration` 注解的资源导入。
+
+## 5.1 getCandidateConfigurations
+
+`#getCandidateConfigurations(AnnotationMetadata metadata, AnnotationAttributes attributes)` 方法，获得符合条件的配置类的数组。代码如下：
+
+```
+// AutoConfigurationImportSelector.java
+
+protected List<String> getCandidateConfigurations(AnnotationMetadata metadata, AnnotationAttributes attributes) {
+    // <1> 加载指定类型 EnableAutoConfiguration 对应的，在 `META-INF/spring.factories` 里的类名的数组
+	List<String> configurations = SpringFactoriesLoader.loadFactoryNames(getSpringFactoriesLoaderFactoryClass(), getBeanClassLoader());
+	// 断言，非空
+	Assert.notEmpty(configurations, "No auto configuration classes found in META-INF/spring.factories. If you " + "are using a custom packaging, make sure that file is correct.");
+	return configurations;
+}
+```
+
+- `<1>` 处，调用 `#getSpringFactoriesLoaderFactoryClass()` 方法，获得要从 `META-INF/spring.factories` 加载的指定类型为 EnableAutoConfiguration 类。代码如下：
+
+  ```
+  // AutoConfigurationImportSelector.java
+  
+  protected Class<?> getSpringFactoriesLoaderFactoryClass() {
+  	return EnableAutoConfiguration.class;
+  }
+  ```
+
+- `<1>` 处，调用 `SpringFactoriesLoader#loadFactoryNames(Class<?> factoryClass, ClassLoader classLoader)` 方法，加载指定类型 EnableAutoConfiguration 对应的，在 `META-INF/spring.factories` 里的类名的数组。看看下图，胖友相信就明白了：[![`configurations`](08-Spring Boot 源码分析-自动配置.assets/01.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-02-01/01.jpg)`configurations`
+
+一般来说，和网络上 Spring Boot 敢于这块的源码解析，我们就可以结束了。如果单纯是为了了解原理 Spring Boot 自动配置的原理，这里结束也是没问题的。因为，拿到 Configuration 配置类后，后面的就是 Spring Java Config 的事情了。不了解的胖友，可以看看 [《Spring 教程 —— 基于 Java 的配置》](http://wiki.jikexueyuan.com/project/spring/java-based-configuration.html) 文章。
+
+😜 但是（“但是”同学，你赶紧坐下），具有倒腾精神的艿艿，觉得还是继续瞅瞅 `#getCandidateConfigurations(AnnotationMetadata metadata, AnnotationAttributes attributes)` 方法是怎么被调用的。所以，我们来看看调用它的方法调用链，如下图所示：[![调用链](08-Spring Boot 源码分析-自动配置.assets/02.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-02-01/02.jpg)调用链
+
+- ① 处，refresh 方法的调用，我们在 [《精尽 Spring Boot 源码分析 —— SpringApplication》](http://svip.iocoder.cn/Spring-Boot/SpringApplication) 中，SpringApplication 启动时，会调用到该方法。
+
+- ② 处，`#getCandidateConfigurations(AnnotationMetadata metadata, AnnotationAttributes attributes)` 方法被调用。
+
+- ③ 处，那么此处，就是问题的关键。代码如下：
+
+  > 艿艿：因为我还没特别完整的撸完 Spring Java Annotations 相关的源码，所以下面的部分，我们更多是看整个调用过程。😈 恰好，胖友也没看过，哈哈哈哈。
+
+  ```
+  // ConfigurationClassParser#DeferredImportSelectorGroupingHandler.java
+  
+  private final DeferredImportSelector.Group group;
+  
+  public Iterable<Group.Entry> getImports() {
+  	for (DeferredImportSelectorHolder deferredImport : this.deferredImports) {
+  		this.group.process(deferredImport.getConfigurationClass().getMetadata(),
+  				deferredImport.getImportSelector()); // <1>
+  	}
+  	return this.group.selectImports(); // <2>
+  }
+  ```
+
+  - `<1>` 处，调用 `DeferredImportSelector.Group#process(AnnotationMetadata metadata, DeferredImportSelector selector)` 方法，处理被 `@Import` 注解的注解。
+
+  - ```
+    <2>
+    ```
+
+     
+
+    处，调用
+
+     
+
+    ```
+    DeferredImportSelector.Group#this.group.selectImports()
+    ```
+
+     
+
+    方法，选择需要导入的。例如：
+
+    ![selectImports](08-Spring Boot 源码分析-自动配置.assets/03.jpg)
+
+    selectImports
+
+    - 这里，我们可以看到需要导入的 Configuration 配置类。
+
+  - 具体 `<1>` 和 `<2>` 处，在 [「5.3 AutoConfigurationGroup」](https://svip.iocoder.cn/Spring-Boot/AutoConfiguration/#) 详细解析。
+
+## 5.2 getImportGroup
+
+`#getImportGroup()` 方法，获得对应的 Group 实现类。代码如下：
+
+```
+// AutoConfigurationImportSelector.java
+
+@Override // 实现自 DeferredImportSelector 接口
+public Class<? extends Group> getImportGroup() {
+	return AutoConfigurationGroup.class;
+}
+```
+
+- 关于 AutoConfigurationGroup 类，在 [「5.3 AutoConfigurationGroup」](https://svip.iocoder.cn/Spring-Boot/AutoConfiguration/#) 详细解析。
+
+## 5.3 AutoConfigurationGroup
+
+> 艿艿：注意，从这里开始后，东西会比较难。因为，涉及的东西会比较多。
+
+AutoConfigurationGroup ，是 AutoConfigurationImportSelector 的内部类，实现 DeferredImportSelector.Group、BeanClassLoaderAware、BeanFactoryAware、ResourceLoaderAware 接口，自动配置的 Group 实现类。
+
+### 5.3.1 属性
+
+```
+// AutoConfigurationImportSelector#AutoConfigurationGroup.java
+
+/**
+ * AnnotationMetadata 的映射
+ *
+ * KEY：配置类的全类名
+ */
+private final Map<String, AnnotationMetadata> entries = new LinkedHashMap<>();
+/**
+ * AutoConfigurationEntry 的数组
+ */
+private final List<AutoConfigurationEntry> autoConfigurationEntries = new ArrayList<>();
+
+private ClassLoader beanClassLoader;
+private BeanFactory beanFactory;
+private ResourceLoader resourceLoader;
+
+/**
+ * 自动配置的元数据
+ */
+private AutoConfigurationMetadata autoConfigurationMetadata;
+```
+
+- `entries` 属性，AnnotationMetadata 的映射。其中，KEY 为 配置类的全类名。在后续我们将看到的 `AutoConfigurationGroup#process(...)` 方法中，被进行赋值。例如：[![`entries`](08-Spring Boot 源码分析-自动配置.assets/04.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-02-01/04.jpg)`entries`
+
+- `autoConfigurationEntries` 属性，AutoConfigurationEntry 的数组。
+
+  - 其中，AutoConfigurationEntry 是 AutoConfigurationImportSelector 的内部类，自动配置的条目。代码如下：
+
+    ```
+    // AutoConfigurationImportSelector#AutoConfigurationEntry.java
+    
+    protected static class AutoConfigurationEntry {
+    
+        /**
+         * 配置类的全类名的数组
+         */
+        private final List<String> configurations;
+        /**
+         * 排除的配置类的全类名的数组 
+         */
+        private final Set<String> exclusions;
+        
+        // 省略构造方法和 setting/getting 方法
+        
+    }
+    ```
+
+    - 属性比较简单。
+
+  - 在后续我们将看到的 `AutoConfigurationGroup#process(...)` 方法中，被进行赋值。例如：[![`autoConfigurationEntries`](08-Spring Boot 源码分析-自动配置.assets/05.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-02-01/05.jpg)`autoConfigurationEntries`
+
+- `autoConfigurationMetadata` 属性，自动配置的元数据（Metadata）。
+
+  - 通过 `#getAutoConfigurationMetadata()` 方法，会初始化该属性。代码如下：
+
+    ```
+    // AutoConfigurationImportSelector#AutoConfigurationGroup.java
+    
+    private AutoConfigurationMetadata getAutoConfigurationMetadata() {
+        // 不存在，则进行加载
+    	if (this.autoConfigurationMetadata == null) {
+    		this.autoConfigurationMetadata = AutoConfigurationMetadataLoader.loadMetadata(this.beanClassLoader);
+    	}
+    	// 存在，则直接返回
+    	return this.autoConfigurationMetadata;
+    }
+    ```
+
+    - 关于 AutoConfigurationMetadataLoader 类，我们先不去愁。避免，我们调试的太过深入。TODO 后续在补充下。
+
+    - 返回的类型是 PropertiesAutoConfigurationMetadata ，比较简单，胖友点击 [传送门](https://github.com/YunaiV/spring-boot/blob/master/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/AutoConfigurationMetadataLoader.java#L67-L119) 瞅一眼即可。
+
+    - 如下是一个返回值的示例：
+
+      ![`autoConfigurationEntries`](08-Spring Boot 源码分析-自动配置.assets/06.jpg)
+
+      `autoConfigurationEntries`
+
+      - 可能胖友会有点懵逼，这么多，并且 KEY / VALUE 结果看不懂？不要方，我们简单来说下 [CouchbaseReactiveRepositoriesAutoConfiguration](https://github.com/YunaiV/spring-boot/blob/master/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/data/couchbase/CouchbaseReactiveRepositoriesAutoConfiguration.java) 配置类。如果它生效，需要 classpath 下有 Bucket、ReactiveCouchbaseRepository、Flux 三个类，所以红线那个条目，对应的就是 CouchbaseReactiveRepositoriesAutoConfiguration 类上的 `@ConditionalOnClass({ Bucket.class, ReactiveCouchbaseRepository.class, Flux.class })` 注解部分。
+
+  - 所以，`autoConfigurationMetadata` 属性，用途就是制定配置类（Configuration）的生效条件（Condition）。
+
+### 5.3.2 process
+
+`#process(AnnotationMetadata annotationMetadata, DeferredImportSelector deferredImportSelector)` 方法，进行处理。代码如下：
+
+```
+// AutoConfigurationImportSelector#AutoConfigurationGroup.java
+
+@Override
+public void process(AnnotationMetadata annotationMetadata, DeferredImportSelector deferredImportSelector) {
+    // 断言
+    Assert.state(
+            deferredImportSelector instanceof AutoConfigurationImportSelector,
+            () -> String.format("Only %s implementations are supported, got %s",
+                    AutoConfigurationImportSelector.class.getSimpleName(),
+                    deferredImportSelector.getClass().getName()));
+    // <1> 获得 AutoConfigurationEntry 对象 
+    AutoConfigurationEntry autoConfigurationEntry = ((AutoConfigurationImportSelector) deferredImportSelector)
+            .getAutoConfigurationEntry(getAutoConfigurationMetadata(), annotationMetadata);
+    // <2> 添加到 autoConfigurationEntries 中
+    this.autoConfigurationEntries.add(autoConfigurationEntry);
+    // <3> 添加到 entries 中
+    for (String importClassName : autoConfigurationEntry.getConfigurations()) {
+        this.entries.putIfAbsent(importClassName, annotationMetadata);
+    }
+}
+```
+
+- `annotationMetadata` 参数，一般来说是被 `@SpringBootApplication` 注解的元数据。因为，`@SpringBootApplication` 组合了 `@EnableAutoConfiguration` 注解。
+- `deferredImportSelector` 参数，`@EnableAutoConfiguration` 注解的定义的 `@Import` 的类，即 AutoConfigurationImportSelector 对象。
+- `<1>` 处，调用 `AutoConfigurationImportSelector#getAutoConfigurationEntry(AutoConfigurationMetadata autoConfigurationMetadata, AnnotationMetadata annotationMetadata)` 方法，获得 AutoConfigurationEntry 对象。详细解析，见 [「5.4 AutoConfigurationEntry」](https://svip.iocoder.cn/Spring-Boot/AutoConfiguration/#) 。因为这块比较重要，所以先跳过去瞅瞅。
+- `<2>` 处，添加到 `autoConfigurationEntries` 中。
+- `<3>` 处，添加到 `entries` 中。
+
+### 5.3.3 selectImports
+
+`#selectImports()` 方法，获得要引入的配置类。代码如下：
+
+```
+// AutoConfigurationImportSelector#AutoConfigurationGroup.java
+
+@Override
+public Iterable<Entry> selectImports() {
+    // <1> 如果为空，则返回空数组
+    if (this.autoConfigurationEntries.isEmpty()) {
+        return Collections.emptyList();
+    }
+    // <2.1> 获得 allExclusions
+    Set<String> allExclusions = this.autoConfigurationEntries.stream()
+            .map(AutoConfigurationEntry::getExclusions)
+            .flatMap(Collection::stream).collect(Collectors.toSet());
+    // <2.2> 获得 processedConfigurations
+    Set<String> processedConfigurations = this.autoConfigurationEntries.stream()
+            .map(AutoConfigurationEntry::getConfigurations)
+            .flatMap(Collection::stream)
+            .collect(Collectors.toCollection(LinkedHashSet::new));
+    // <2.3> 从 processedConfigurations 中，移除排除的
+    processedConfigurations.removeAll(allExclusions);
+    // <3> 处理，返回结果
+    return sortAutoConfigurations(processedConfigurations, getAutoConfigurationMetadata()) // <3.1> 排序
+                .stream()
+                .map((importClassName) -> new Entry(this.entries.get(importClassName), importClassName)) // <3.2> 创建 Entry 对象
+                .collect(Collectors.toList()); // <3.3> 转换成 List
+}
+```
+
+- `<1>` 处，如果为空，则返回空数组。
+
+- `<2.1>`、`<2.2>`、`<2.3>` 处，获得要引入的配置类集合。😈 比较奇怪的是，上面已经做过一次移除的处理，这里又做一次。不过，没多大关系，可以先无视。
+
+- `<3>` 处，处理，返回结果。
+
+  - `<3.1>` 处，调用 `#sortAutoConfigurations(Set<String> configurations, AutoConfigurationMetadata autoConfigurationMetadata)` 方法，排序。代码如下：
+
+    ```
+    // AutoConfigurationImportSelector#AutoConfigurationGroup.java
+    
+    private List<String> sortAutoConfigurations(Set<String> configurations, AutoConfigurationMetadata autoConfigurationMetadata) {
+    	return new AutoConfigurationSorter(getMetadataReaderFactory(), autoConfigurationMetadata).getInPriorityOrder(configurations);
+    }
+    ```
+
+    - 具体的排序逻辑，胖友自己看。实际上，还是涉及哪些，例如说 `@Order` 注解。
+
+  - `<3.2>` 处，创建 Entry 对象。
+
+  - `<3.3>` 处，转换成 List 。结果如下图：[![结果](08-Spring Boot 源码分析-自动配置.assets/09.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-02-01/09.jpg)结果
+
+> 艿艿：略微有点艰难的过程。不过回过头来，其实也没啥特别复杂的逻辑。是不，胖友~
+
+## 5.4 getAutoConfigurationEntry
+
+> 艿艿：这是一个关键方法。因为会调用到，我们会在 [「5.1 getCandidateConfigurations」](https://svip.iocoder.cn/Spring-Boot/AutoConfiguration/#) 的方法。
+
+`#getAutoConfigurationEntry(AutoConfigurationMetadata autoConfigurationMetadata, AnnotationMetadata annotationMetadata)` 方法，获得 AutoConfigurationEntry 对象。代码如下：
+
+```
+// AutoConfigurationImportSelector.java
+
+protected AutoConfigurationEntry getAutoConfigurationEntry(AutoConfigurationMetadata autoConfigurationMetadata, AnnotationMetadata annotationMetadata) {
+    // <1> 判断是否开启。如未开启，返回空数组。
+    if (!isEnabled(annotationMetadata)) {
+        return EMPTY_ENTRY;
+    }
+    // <2> 获得注解的属性
+    AnnotationAttributes attributes = getAttributes(annotationMetadata);
+    // <3> 获得符合条件的配置类的数组
+    List<String> configurations = getCandidateConfigurations(annotationMetadata, attributes);
+    // <3.1> 移除重复的配置类
+    configurations = removeDuplicates(configurations);
+    // <4> 获得需要排除的配置类
+    Set<String> exclusions = getExclusions(annotationMetadata, attributes);
+    // <4.1> 校验排除的配置类是否合法
+    checkExcludedClasses(configurations, exclusions);
+    // <4.2> 从 configurations 中，移除需要排除的配置类
+    configurations.removeAll(exclusions);
+    // <5> 根据条件（Condition），过滤掉不符合条件的配置类
+    configurations = filter(configurations, autoConfigurationMetadata);
+    // <6> 触发自动配置类引入完成的事件
+    fireAutoConfigurationImportEvents(configurations, exclusions);
+    // <7> 创建 AutoConfigurationEntry 对象
+    return new AutoConfigurationEntry(configurations, exclusions);
+}
+```
+
+> 这里每一步都是细节的方法，所以会每一个方法，都会是引导到对应的小节的方法。
+>
+> 虽然有点长，但是很不复杂。简单的来说，加载符合条件的配置类们，然后移除需要排除（exclusion）的。
+
+- `<1>` 处，调用 `#isEnabled(AnnotationMetadata metadata)` 方法，判断是否开启。如未开启，返回空数组。详细解析，见 [「5.4.1 isEnabled」](https://svip.iocoder.cn/Spring-Boot/AutoConfiguration/#) 。
+
+- `<2>` 处，调用 `#getAttributes(AnnotationMetadata metadata)` 方法，获得注解的属性。详细解析，见 [「5.4.2 getAttributes」](https://svip.iocoder.cn/Spring-Boot/AutoConfiguration/#) 。
+
+- 【重要】`<3>` 处，调用 `#getCandidateConfigurations(AnnotationMetadata metadata, AnnotationAttributes attributes)` 方法，获得符合条件的配置类的数组。
+
+  > 嘻嘻，到达此书之后，整个细节是不是就串起来了!
+
+  - `<3.1>` 处，调用 `#removeDuplicates(List<T> list)` 方法，移除重复的配置类。代码如下：
+
+    ```
+    // AutoConfigurationImportSelector.java
+    
+    protected final <T> List<T> removeDuplicates(List<T> list) {
+    	return new ArrayList<>(new LinkedHashSet<>(list));
+    }
+    ```
+
+    - 简单粗暴
+
+- `<4>` 处，调用 `#getExclusions(AnnotationMetadata metadata, AnnotationAttributes attributes)` 方法，获得需要排除的配置类。详细解析，见 [「5.4.3 getExclusions」](https://svip.iocoder.cn/Spring-Boot/AutoConfiguration/#) 。
+
+  - `<4.1>` 处，调用 `#checkExcludedClasses(List<String> configurations, Set<String> exclusions)` 方法，校验排除的配置类是否合法。详细解析，见 [「5.4.4 checkExcludedClasses」](https://svip.iocoder.cn/Spring-Boot/AutoConfiguration/#) 。
+  - `<4.2>` 处，从 `configurations` 中，移除需要排除的配置类。
+
+- `<5>` 处，调用 `#filter(List<String> configurations, AutoConfigurationMetadata autoConfigurationMetadata)` 方法，根据条件（Condition），过滤掉不符合条件的配置类。详细解析，见 [《精尽 Spring Boot 源码分析 —— Condition》](http://svip.iocoder.cn/Spring-Boot/Condition/) 文章。
+
+- `<6>` 处，调用 `#fireAutoConfigurationImportEvents(List<String> configurations, Set<String> exclusions)` 方法，触发自动配置类引入完成的事件。详细解析，见 [「5.4.5 fireAutoConfigurationImportEvents」](https://svip.iocoder.cn/Spring-Boot/AutoConfiguration/#) 。
+
+- `<7>` 处，创建 AutoConfigurationEntry 对象。
+
+> 整个 [「5.4 getAutoConfigurationEntry」](https://svip.iocoder.cn/Spring-Boot/AutoConfiguration/#) 看完后，胖友请跳回 [「5.3.3 selectImports」](https://svip.iocoder.cn/Spring-Boot/AutoConfiguration/#) 。
+
+### 5.4.1 isEnabled
+
+`#isEnabled(AnnotationMetadata metadata)` 方法，判断是否开启自动配置。代码如下：
+
+```
+// AutoConfigurationImportSelector.java
+
+protected boolean isEnabled(AnnotationMetadata metadata) {
+    // 判断 "spring.boot.enableautoconfiguration" 配置判断，是否开启自动配置。
+    // 默认情况下（未配置），开启自动配置。
+	if (getClass() == AutoConfigurationImportSelector.class) {
+		return getEnvironment().getProperty(EnableAutoConfiguration.ENABLED_OVERRIDE_PROPERTY, Boolean.class, true);
+	}
+	return true;
+}
+```
+
+### 5.4.2 getAttributes
+
+`#getAttributes(AnnotationMetadata metadata)` 方法，获得注解的属性。代码如下：
+
+```
+// AutoConfigurationImportSelector.java
+
+protected AnnotationAttributes getAttributes(AnnotationMetadata metadata) {
+	String name = getAnnotationClass().getName();
+	// 获得注解的属性
+	AnnotationAttributes attributes = AnnotationAttributes.fromMap(metadata.getAnnotationAttributes(name, true));
+	// 断言
+	Assert.notNull(attributes,
+			() -> "No auto-configuration attributes found. Is "
+					+ metadata.getClassName() + " annotated with "
+					+ ClassUtils.getShortName(name) + "?");
+	return attributes;
+}
+```
+
+- 注意，此处 `getAnnotationClass().getName()` 返回的是 `@EnableAutoConfiguration` 注解，所以这里返回的注解属性，只能是 `exclude` 和 `excludeName` 这两个。
+
+- 举个例子，假设 Spring 应用上的注解如下：
+
+  ```
+  @SpringBootApplication(exclude = {SpringApplicationAdminJmxAutoConfiguration.class},
+      scanBasePackages = "cn.iocoder")
+  ```
+
+  - 返回的结果，如下图：[![`attributes`](08-Spring Boot 源码分析-自动配置.assets/07.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-02-01/07.jpg)`attributes`
+
+### 5.4.3 getExclusions
+
+`#getExclusions(AnnotationMetadata metadata, AnnotationAttributes attributes)` 方法，获得需要排除的配置类。代码如下：
+
+```
+// AutoConfigurationImportSelector.java
+
+protected Set<String> getExclusions(AnnotationMetadata metadata, AnnotationAttributes attributes) {
+	Set<String> excluded = new LinkedHashSet<>();
+	// 注解上的 exclude 属性
+	excluded.addAll(asList(attributes, "exclude"));
+	// 注解上的 excludeName 属性
+	excluded.addAll(Arrays.asList(attributes.getStringArray("excludeName")));
+	// 配置文件的 spring.autoconfigure.exclude 属性
+	excluded.addAll(getExcludeAutoConfigurationsProperty());
+	return excluded;
+}
+```
+
+- 一共有三种方式，配置排除属性。
+
+- 该方法会调用如下的方法，比较简单，胖友自己瞅瞅。
+
+  ```
+  // AutoConfigurationImportSelector.java
+  
+  private List<String> getExcludeAutoConfigurationsProperty() {
+      // 一般来说，会走这块的逻辑
+  	if (getEnvironment() instanceof ConfigurableEnvironment) {
+  		Binder binder = Binder.get(getEnvironment());
+  		return binder.bind(PROPERTY_NAME_AUTOCONFIGURE_EXCLUDE, String[].class).map(Arrays::asList).orElse(Collections.emptyList());
+  	}
+  	String[] excludes = getEnvironment().getProperty(PROPERTY_NAME_AUTOCONFIGURE_EXCLUDE, String[].class);
+  	return (excludes != null) ? Arrays.asList(excludes) : Collections.emptyList();
+  }
+  
+  protected final List<String> asList(AnnotationAttributes attributes, String name) {
+  	String[] value = attributes.getStringArray(name);
+  	return Arrays.asList(value);
+  }
+  ```
+
+### 5.4.4 checkExcludedClasses
+
+`#checkExcludedClasses(List<String> configurations, Set<String> exclusions)` 方法，校验排除的配置类是否合法。代码如下：
+
+```
+// AutoConfigurationImportSelector.java
+
+private void checkExcludedClasses(List<String> configurations, Set<String> exclusions) {
+    // 获得 exclusions 不在 invalidExcludes 的集合，添加到 invalidExcludes 中
+    List<String> invalidExcludes = new ArrayList<>(exclusions.size());
+    for (String exclusion : exclusions) {
+        if (ClassUtils.isPresent(exclusion, getClass().getClassLoader()) // classpath 存在该类
+                && !configurations.contains(exclusion)) { // configurations 不存在该类
+            invalidExcludes.add(exclusion);
+        }
+    }
+    // 如果 invalidExcludes 非空，抛出 IllegalStateException 异常
+    if (!invalidExcludes.isEmpty()) {
+        handleInvalidExcludes(invalidExcludes);
+    }
+}
+
+/**
+ * Handle any invalid excludes that have been specified.
+ * @param invalidExcludes the list of invalid excludes (will always have at least one
+ * element)
+ */
+protected void handleInvalidExcludes(List<String> invalidExcludes) {
+    StringBuilder message = new StringBuilder();
+    for (String exclude : invalidExcludes) {
+        message.append("\t- ").append(exclude).append(String.format("%n"));
+    }
+    throw new IllegalStateException(String.format("The following classes could not be excluded because they are"
+                    + " not auto-configuration classes:%n%s", message));
+}
+```
+
+- 不合法的定义，`exclusions` 存在于 classpath 中，但是不存在 `configurations` 。这样做的目的是，如果不存在的，就不要去排除啦！
+- 代码比较简单，胖友自己瞅瞅即可。
+
+### 5.4.5 fireAutoConfigurationImportEvents
+
+`#fireAutoConfigurationImportEvents(List<String> configurations, Set<String> exclusions)` 方法，触发自动配置类引入完成的事件。代码如下：
+
+```
+// AutoConfigurationImportSelector.java
+
+private void fireAutoConfigurationImportEvents(List<String> configurations, Set<String> exclusions) {
+    // <1> 加载指定类型 AutoConfigurationImportListener 对应的，在 `META-INF/spring.factories` 里的类名的数组。
+	List<AutoConfigurationImportListener> listeners = getAutoConfigurationImportListeners();
+	if (!listeners.isEmpty()) {
+	    // <2> 创建 AutoConfigurationImportEvent 事件
+		AutoConfigurationImportEvent event = new AutoConfigurationImportEvent(this, configurations, exclusions);
+		// <3> 遍历 AutoConfigurationImportListener 监听器们，逐个通知
+		for (AutoConfigurationImportListener listener : listeners) {
+		    // <3.1> 设置 AutoConfigurationImportListener 的属性
+			invokeAwareMethods(listener);
+			// <3.2> 通知
+			listener.onAutoConfigurationImportEvent(event);
+		}
+	}
+}
+```
+
+- `<1>` 处，调用 `#getAutoConfigurationImportListeners()` 方法，加载指定类型 AutoConfigurationImportListener 对应的，在 `META-INF/spring.factories` 里的类名的数组。例如：[![`listeners`](08-Spring Boot 源码分析-自动配置.assets/08.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-02-01/08.jpg)`listeners`
+
+- `<2>` 处，创建 AutoConfigurationImportEvent 事件。
+
+- `<3>` 处，遍历 AutoConfigurationImportListener 监听器们，逐个通知。
+
+  - `<3.1>` 处，调用 `#invokeAwareMethods(Object instance)` 方法，设置 AutoConfigurationImportListener 的属性。代码如下：
+
+    ```
+    // AutoConfigurationImportSelector.java
+    
+    private void invokeAwareMethods(Object instance) {
+        // 各种 Aware 属性的注入
+    	if (instance instanceof Aware) {
+    		if (instance instanceof BeanClassLoaderAware) {
+    			((BeanClassLoaderAware) instance).setBeanClassLoader(this.beanClassLoader);
+    		}
+    		if (instance instanceof BeanFactoryAware) {
+    			((BeanFactoryAware) instance).setBeanFactory(this.beanFactory);
+    		}
+    		if (instance instanceof EnvironmentAware) {
+    			((EnvironmentAware) instance).setEnvironment(this.environment);
+    		}
+    		if (instance instanceof ResourceLoaderAware) {
+    			((ResourceLoaderAware) instance).setResourceLoader(this.resourceLoader);
+    		}
+    	}
+    }
+    ```
+
+    - 各种 Aware 属性的注入。
+
+  - `<3.2>` 处，调用 `AutoConfigurationImportListener#onAutoConfigurationImportEvent(event)` 方法，通知监听器。目前只有一个 ConditionEvaluationReportAutoConfigurationImportListener 监听器，没啥逻辑，有兴趣自己看哈。
+
+# 6. AutoConfigurationPackages
+
+`org.springframework.boot.autoconfigure.AutoConfigurationPackages` ，自动配置所在的包名。可能这么解释有点怪怪的，我们来看下官方注释：
+
+```
+Class for storing auto-configuration packages for reference later (e.g. by JPA entity scanner).
+```
+
+- 简单来说，就是将使用 `@AutoConfigurationPackage` 注解的类所在的包（`package`），注册成一个 Spring IoC 容器中的 Bean 。酱紫，后续有其它模块需要使用，就可以通过获得该 Bean ，从而获得所在的包。例如说，JPA 模块，需要使用到。
+
+是不是有点神奇，艿艿也觉得。
+
+## 6.1 Registrar
+
+Registrar ，是 AutoConfigurationPackages 的内部类，实现 ImportBeanDefinitionRegistrar、DeterminableImports 接口，注册器，用于处理 `@AutoConfigurationPackage` 注解。代码如下：
+
+```
+// AutoConfigurationPackages#Registrar.java
+
+static class Registrar implements ImportBeanDefinitionRegistrar, DeterminableImports {
+
+	@Override
+	public void registerBeanDefinitions(AnnotationMetadata metadata, BeanDefinitionRegistry registry) {
+		register(registry, new PackageImport(metadata).getPackageName()); // <X>
+	}
+
+	@Override
+	public Set<Object> determineImports(AnnotationMetadata metadata) {
+		return Collections.singleton(new PackageImport(metadata));
+	}
+
+}
+```
+
+- PackageImport 是 AutoConfigurationPackages 的内部类，用于获得包名。代码如下：
+
+  ```
+  // AutoConfigurationPackages#Registrar.java
+  
+  private static final class PackageImport {
+  
+      /**
+       * 包名
+       */
+      private final String packageName;
+  
+      PackageImport(AnnotationMetadata metadata) {
+          this.packageName = ClassUtils.getPackageName(metadata.getClassName());
+      }
+  
+      public String getPackageName() {
+          return this.packageName;
+      }
+  
+      @Override
+      public boolean equals(Object obj) {
+          if (obj == null || getClass() != obj.getClass()) {
+              return false;
+          }
+          return this.packageName.equals(((PackageImport) obj).packageName);
+      }
+  
+      @Override
+      public int hashCode() {
+          return this.packageName.hashCode();
+      }
+  
+      @Override
+      public String toString() {
+          return "Package Import " + this.packageName;
+      }
+  
+  }
+  ```
+
+  - 如下是一个示例：[![PackageImport](08-Spring Boot 源码分析-自动配置.assets/10.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-02-01/10.jpg)PackageImport
+
+- `<X>` 处，调用 `#register(BeanDefinitionRegistry registry, String... packageNames)` 方法，注册一个用于存储报名（`package`）的 Bean 到 Spring IoC 容器中。详细解析，见 [「6.2 register」](https://svip.iocoder.cn/Spring-Boot/AutoConfiguration/#) 。
+
+## 6.2 register
+
+`#register(BeanDefinitionRegistry registry, String... packageNames)` 方法，注册一个用于存储报名（`package`）的 Bean 到 Spring IoC 容器中。代码如下：
+
+```
+// AutoConfigurationPackages.java
+
+private static final String BEAN = AutoConfigurationPackages.class.getName();
+
+public static void register(BeanDefinitionRegistry registry, String... packageNames) {
+    // <1> 如果已经存在该 BEAN ，则修改其包（package）属性
+	if (registry.containsBeanDefinition(BEAN)) {
+		BeanDefinition beanDefinition = registry.getBeanDefinition(BEAN);
+		ConstructorArgumentValues constructorArguments = beanDefinition.getConstructorArgumentValues();
+		constructorArguments.addIndexedArgumentValue(0, addBasePackages(constructorArguments, packageNames));
+    // <2> 如果不存在该 BEAN ，则创建一个 Bean ，并进行注册
+    } else { GenericBeanDefinition beanDefinition = new GenericBeanDefinition();
+		beanDefinition.setBeanClass(BasePackages.class);
+		beanDefinition.getConstructorArgumentValues().addIndexedArgumentValue(0, packageNames);
+		beanDefinition.setRole(BeanDefinition.ROLE_INFRASTRUCTURE);
+		registry.registerBeanDefinition(BEAN, beanDefinition);
+	}
+}
+```
+
+- 注册的 `BEAN` 的类型，为 BasePackages 类型。它是 AutoConfigurationPackages 的内部类。代码如下：
+
+  ```
+  // AutoConfigurationPackages#BasePackages.java
+  
+  static final class BasePackages {
+  
+  	private final List<String> packages;
+  
+  	private boolean loggedBasePackageInfo;
+  
+  	BasePackages(String... names) {
+  		List<String> packages = new ArrayList<>();
+  		for (String name : names) {
+  			if (StringUtils.hasText(name)) {
+  				packages.add(name);
+  			}
+  		}
+  		this.packages = packages;
+  	}
+  
+  	public List<String> get() {
+  		if (!this.loggedBasePackageInfo) {
+  			if (this.packages.isEmpty()) {
+  				if (logger.isWarnEnabled()) {
+  					logger.warn("@EnableAutoConfiguration was declared on a class "
+  							+ "in the default package. Automatic @Repository and "
+  							+ "@Entity scanning is not enabled.");
+  				}
+  			} else {
+  				if (logger.isDebugEnabled()) {
+  					String packageNames = StringUtils
+  							.collectionToCommaDelimitedString(this.packages);
+  					logger.debug("@EnableAutoConfiguration was declared on a class "
+  							+ "in the package '" + packageNames
+  							+ "'. Automatic @Repository and @Entity scanning is "
+  							+ "enabled.");
+  				}
+  			}
+  			this.loggedBasePackageInfo = true;
+  		}
+  		return this.packages;
+  	}
+  
+  }
+  ```
+
+  - 就是一个有 `packages` 属性的封装类。
+
+- ```
+  <1>
+  ```
+
+   
+
+  处，如果已经存在该
+
+   
+
+  ```
+  BEAN
+  ```
+
+   
+
+  ，则修改其包（
+
+  ```
+  package
+  ```
+
+  ）属性。而合并
+
+   
+
+  ```
+  package
+  ```
+
+   
+
+  的逻辑，通过
+
+   
+
+  ```
+  #addBasePackages(ConstructorArgumentValues constructorArguments, String[] packageNames)
+  ```
+
+   
+
+  方法，进行实现。代码如下：
+
+  ```
+  // AutoConfigurationPackages.java
+  
+  private static String[] addBasePackages(ConstructorArgumentValues constructorArguments, String[] packageNames) {
+  	// 获得已存在的
+      String[] existing = (String[]) constructorArguments.getIndexedArgumentValue(0, String[].class).getValue();
+  	// 进行合并
+      Set<String> merged = new LinkedHashSet<>();
+  	merged.addAll(Arrays.asList(existing));
+  	merged.addAll(Arrays.asList(packageNames));
+  	return StringUtils.toStringArray(merged);
+  }
+  ```
+
+- `<2>` 处，如果不存在该 `BEAN` ，则创建一个 `Bean` ，并进行注册。
+
+## 6.3 has
+
+`#has(BeanFactory beanFactory)` 方法，判断是否存在该 `BEAN` 在传入的容器中。代码如下：
+
+```
+// AutoConfigurationPackages.java
+
+public static boolean has(BeanFactory beanFactory) {
+	return beanFactory.containsBean(BEAN) && !get(beanFactory).isEmpty();
+}
+```
+
+## 6.4 get
+
+`#get(BeanFactory beanFactory)` 方法，获得 `BEAN` 。代码如下：
+
+```
+// AutoConfigurationPackages.java
+
+public static List<String> get(BeanFactory beanFactory) {
+	try {
+		return beanFactory.getBean(BEAN, BasePackages.class).get();
+	} catch (NoSuchBeanDefinitionException ex) {
+		throw new IllegalStateException("Unable to retrieve @EnableAutoConfiguration base packages");
+	}
+}
+```
+
+# 666. 彩蛋
+
+比想象中长的一篇文章。虽然中间有些地方复杂了一点，但是觉得还是蛮有趣的。
+
+撸完有点不清晰的胖友，再调试两遍。还有疑惑，星球留言走一波哟。
+
+参考和推荐如下文章：
+
+- 快乐崇拜 [《Spring Boot 源码深入分析》](https://gitbook.cn/books/5a445f030173cb29d2041d61/index.html)
+
+  > 有木发现，艿艿写的比他详细很多很多。
+
+- 老田 [《Spring Boot 2.0 系列文章(六)：Spring Boot 2.0 中SpringBootApplication注解详解》](http://www.54tianzhisheng.cn/2018/04/19/SpringBootApplication-annotation/)
+
+- dm_vincent [《[Spring Boot\] 4. Spring Boot实现自动配置的原理》](https://blog.csdn.net/dm_vincent/article/details/77619752)
\ No newline at end of file
diff --git a/springboot/09-Spring Boot 源码分析-Condition.assets/01.jpg b/springboot/09-Spring Boot 源码分析-Condition.assets/01.jpg
new file mode 100644
index 0000000..adb555d
Binary files /dev/null and b/springboot/09-Spring Boot 源码分析-Condition.assets/01.jpg differ
diff --git a/springboot/09-Spring Boot 源码分析-Condition.assets/02.jpg b/springboot/09-Spring Boot 源码分析-Condition.assets/02.jpg
new file mode 100644
index 0000000..b3a4abe
Binary files /dev/null and b/springboot/09-Spring Boot 源码分析-Condition.assets/02.jpg differ
diff --git a/springboot/09-Spring Boot 源码分析-Condition.assets/03.jpg b/springboot/09-Spring Boot 源码分析-Condition.assets/03.jpg
new file mode 100644
index 0000000..a63385b
Binary files /dev/null and b/springboot/09-Spring Boot 源码分析-Condition.assets/03.jpg differ
diff --git a/springboot/09-Spring Boot 源码分析-Condition.assets/04.jpg b/springboot/09-Spring Boot 源码分析-Condition.assets/04.jpg
new file mode 100644
index 0000000..8b6e3cd
Binary files /dev/null and b/springboot/09-Spring Boot 源码分析-Condition.assets/04.jpg differ
diff --git a/springboot/09-Spring Boot 源码分析-Condition.assets/05.jpg b/springboot/09-Spring Boot 源码分析-Condition.assets/05.jpg
new file mode 100644
index 0000000..c811533
Binary files /dev/null and b/springboot/09-Spring Boot 源码分析-Condition.assets/05.jpg differ
diff --git a/springboot/09-Spring Boot 源码分析-Condition.assets/06.jpg b/springboot/09-Spring Boot 源码分析-Condition.assets/06.jpg
new file mode 100644
index 0000000..b72a49d
Binary files /dev/null and b/springboot/09-Spring Boot 源码分析-Condition.assets/06.jpg differ
diff --git a/springboot/09-Spring Boot 源码分析-Condition.assets/07.jpg b/springboot/09-Spring Boot 源码分析-Condition.assets/07.jpg
new file mode 100644
index 0000000..84c0896
Binary files /dev/null and b/springboot/09-Spring Boot 源码分析-Condition.assets/07.jpg differ
diff --git a/springboot/09-Spring Boot 源码分析-Condition.assets/08.jpg b/springboot/09-Spring Boot 源码分析-Condition.assets/08.jpg
new file mode 100644
index 0000000..724c054
Binary files /dev/null and b/springboot/09-Spring Boot 源码分析-Condition.assets/08.jpg differ
diff --git a/springboot/09-Spring Boot 源码分析-Condition.assets/09.jpg b/springboot/09-Spring Boot 源码分析-Condition.assets/09.jpg
new file mode 100644
index 0000000..7081138
Binary files /dev/null and b/springboot/09-Spring Boot 源码分析-Condition.assets/09.jpg differ
diff --git a/springboot/09-Spring Boot 源码分析-Condition.assets/10.jpg b/springboot/09-Spring Boot 源码分析-Condition.assets/10.jpg
new file mode 100644
index 0000000..08f5b2a
Binary files /dev/null and b/springboot/09-Spring Boot 源码分析-Condition.assets/10.jpg differ
diff --git a/springboot/09-Spring Boot 源码分析-Condition.md b/springboot/09-Spring Boot 源码分析-Condition.md
new file mode 100644
index 0000000..21389f3
--- /dev/null
+++ b/springboot/09-Spring Boot 源码分析-Condition.md	
@@ -0,0 +1,1545 @@
+# 精尽 Spring Boot 源码分析 —— Condition
+
+# 1. 概述
+
+在前面的文章，我们已经看过 Spring Boot 如何实现**自动配置**的功能，但是，实际场景下，这显然不够。为什么呢？因为每个框架的**配置**，需要满足一定的**条件**，才应该进行**自动配置**。这时候，我们很自然就可以想到 Spring Boot 的 **Condition** 功能。不过呢，Condition 功能并不是 Spring Boot 所独有，而是在 Spring Framework 中就已经提供了。那么，究竟是什么样的关系呢，我们在 [「2. Condition 演进史」](https://svip.iocoder.cn/Spring-Boot/Condition/#) 来瞅瞅。
+
+# 2. Condition 演进史
+
+## 2.1 Profile 的出场
+
+在 Spring3.1 的版本，为了满足不同环境注册不同的 Bean ，引入了 `@Profile` 注解。例如：
+
+```
+@Configuration
+public class DataSourceConfiguration {
+
+    @Bean
+    @Profile("DEV")
+    public DataSource devDataSource() {
+        // ... 单机 MySQL
+    }
+
+    @Bean
+    @Profile("PROD")
+    public DataSource prodDataSource() {
+        // ... 集群 MySQL
+    }
+    
+}
+```
+
+- 在测试环境下，我们注册单机 MySQL 的 DataSource Bean 。
+- 在生产环境下，我们注册集群 MySQL 的 DataSource Bean 。
+
+------
+
+`org.springframework.context.annotation.@Profile` ，代码如下：
+
+```
+// Profile.java
+
+@Target({ElementType.TYPE, ElementType.METHOD})
+@Retention(RetentionPolicy.RUNTIME)
+@Documented
+@Conditional(ProfileCondition.class)
+public @interface Profile {
+
+	/**
+	 * The set of profiles for which the annotated component should be registered.
+	 */
+	String[] value();
+
+}
+```
+
+- 这是 Spring5 版本的 `@Profile` 注解的代码。它已经是经过 Condition 改造的实现。详细的，我们放在 [「2.2 Condition」](https://svip.iocoder.cn/Spring-Boot/Condition/#) 。
+
+- 让我们在来看一眼 Spring3 版本的 `@Profile` 注解的代码。如下：
+
+  ```
+  // Profile.java
+  
+  @Retention(RetentionPolicy.RUNTIME)
+  @Target({
+  	ANNOTATION_TYPE, // @Profile may be used as a meta-annotation
+  	TYPE             // In conjunction with @Component and its derivatives
+  })
+  public @interface Profile {
+  
+  	static final String CANDIDATE_PROFILES_ATTRIB_NAME = "value";
+  
+  	String[] value();
+  }
+  ```
+
+  - 可以大体猜出，此时并没有将 Profile 作为 Condition 的一种情况。
+
+## 2.2 Condition 的出现
+
+在 Spring4 的版本，正式出现 Condition 功能，体现在 `org.springframework.context.annotation.Condition` 接口，代码如下：
+
+```
+// Condition.java
+
+@FunctionalInterface
+public interface Condition {
+
+	boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata);
+
+}
+```
+
+- 很简洁的一个接口，只有一个 `#matches(...)` 方法，用于判断是佛匹配。从参数中就可以看出，它是和注解配合，而这个注解便是 `@Conditional` 。
+
+`org.springframework.context.annotation.@Conditional` 注解，也是在 Spring4 的版本，一起出现。代码如下：
+
+```
+// Conditional.java
+
+@Target({ElementType.TYPE, ElementType.METHOD})
+@Retention(RetentionPolicy.RUNTIME)
+@Documented
+public @interface Conditional {
+
+	Class<? extends Condition>[] value();
+
+}
+```
+
+- 可以注解在**方法**、或者在**类**上，表示需要满足的条件（Condition）。
+
+- 在 [「2.1 Profile 的出现」](https://svip.iocoder.cn/Spring-Boot/Condition/#) 小节中，我们已经看到 `@Profile` 上，有 `@Conditional(ProfileCondition.class)` 的注解，表示使用 `org.springframework.context.annotation.ProfileCondition` 作为条件。
+
+- 当然，我们也可以直接在 Configuration 类上使用。例如：
+
+  ```
+  @Configuration
+  public class TestConfiguration {
+  
+      @Bean
+      @Conditional(XXXCondition.class)
+      public Object xxxObject() {
+          return new Object();
+      }
+      
+  }
+  ```
+
+  - 即，创建 `#xxxObject()` 方法对应的 Bean 对象，需要满足 XXXCondition 条件。
+
+在 Spring5 中，艿艿整理了下目前提供的 Condition 实现类，如下图：[![Condition 实现类](09-Spring Boot 源码分析-Condition.assets/01.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-02-15/01.jpg)Condition 实现类
+
+- 显然，默认提供的 Condition 实现类非常少。
+
+## 2.3 SpringBootCondition 的进击
+
+为了满足更加丰富的 Condition（条件）的需要，Spring Boot 进一步拓展了更多的实现类，如下图所示：
+
+[![Spring Boot Condition 实现类](09-Spring Boot 源码分析-Condition.assets/02.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-02-15/02.jpg)Spring Boot Condition 实现类
+
+- `org.springframework.boot.autoconfigure.condition.SpringBootCondition` ，是 Spring Boot 实现 Condition 的抽象类，且是 Spring Boot 所有 Condition 实现类的基类。
+- 分别对应如下注解：
+  - `@ConditionalOnBean`：当容器里有指定 Bean 的条件下。
+  - `@ConditionalOnMissingBean`：当容器里没有指定 Bean 的情况下。
+  - `@ConditionalOnSingleCandidate`：当指定 Bean 在容器中只有一个，或者虽然有多个但是指定首选 Bean 。
+  - `@ConditionalOnClass`：当类路径下有指定类的条件下。
+  - `@ConditionalOnMissingClass`：当类路径下没有指定类的条件下。
+  - `@ConditionalOnProperty`：指定的属性是否有指定的值
+  - `@ConditionalOnResource`：类路径是否有指定的值
+  - `@ConditionalOnExpression`：基于 SpEL 表达式作为判断条件。
+  - `@ConditionalOnJava`：基于 Java 版本作为判断条件
+  - `@ConditionalOnJndi`：在 JNDI 存在的条件下差在指定的位置
+  - `@ConditionalOnNotWebApplication`：当前项目不是 Web 项目的条件下
+  - `@ConditionalOnWebApplication`：当前项目是 Web项 目的条件下。
+
+## 2.4 小结
+
+到了此处，我们基本算是理清了 Condition 的整个演进构成：
+
+- `@Profile` 注解，在 Spring3.1 提出，可以作为是 Condition 的雏形。
+- Condition 接口，在 Spring4 提出，是 Condition 的正式出现。
+- SpringCondition 抽象类，在 Spring Boot 实现，是对 Condition 进一步拓展。
+
+下面，我们就正式开始撸 Condition 相关的源码落。
+
+# 3. Condition 如何生效？
+
+在上面的文章中，我们已经看到，`@Conditional` 注解，可以添加：
+
+- 类级别上
+- 方法级别上
+
+> 添加到注解上，相当于添加到类级别或者方法级别上。
+
+并且，一般情况下我们和配置类（Configuration）一起使用，但是实际上，我们也可以添加到普通的 Bean 类上。例如：
+
+```
+// DemoController.java
+
+@Controller
+@RequestMapping("/demo")
+@Conditional(TestCondition.class)
+public class DemoController {
+
+    @ResponseBody
+    @RequestMapping("/hello")
+    public String hello() {
+        return "world";
+    }
+
+}
+```
+
+那么，究竟 Condition 是如何生效的呢？分成两种情况：
+
+- 方式一，**配置类**。添加到配置类（Configuration）上面。
+
+- 方式二，**创建 Bean 对象**。添加到配置类（Configuration）、或者 Bean Class 的上面。
+
+  > 本质上，方式二上的两种，都是创建 Bean 对象，所以统一处理方式即可。
+
+假设，我们在 TestConfiguration 这个示例下进行测试，看看具体的调用链。代码如下：
+
+```
+// TestConfiguration.java
+
+@Configuration
+@Conditional(TestCondition.class) // 艿艿自己编写的 Condition 实现类，方式测试调试
+public class TestConfiguration {
+
+    @Bean
+    @Conditional(TestCondition.class)
+    public Object testObject() {
+        return new Object();
+    }
+
+}
+
+// TestCondition.java
+public class TestCondition implements Condition {
+
+    @Override
+    public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
+        return true;
+    }
+
+}
+```
+
+> 本小节，不会讲特别细的源码。
+
+## 3.1 方式一：配置类
+
+在 TestCondition 的 `#matches(...)` 方法中，打个断点。看看**方式一**情况下的具体的表现。如下图所示：[![调用栈](09-Spring Boot 源码分析-Condition.assets/03.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-02-15/03.jpg)调用栈
+
+- 通过调用 `Condition#matches(...)` 方法，判断该是否匹配。如果不匹配，内部所有方法，都无法创建 Bean 对象。
+
+## 3.2 方式二：创建 Bean 对象
+
+在 TestCondition 的 `#matches(...)` 方法中，打个断点。看看**方式二**情况下的具体的表现。如下图所示：[![调用栈](09-Spring Boot 源码分析-Condition.assets/04.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-02-15/04.jpg)调用栈
+
+- 通过调用 `Condition#matches(...)` 方法，判断是否匹配。如果吧匹配，则不从该方法加载 BeanDefinition 。这样，就不会创建对应的 Bean 对象了。
+
+## 3.3 小结
+
+至此，我们已经看到 Condition 如何生效。还是相对比较简单的。
+
+下面，我们一起来看看 SpringBootCondition 如何实现它的进击。
+
+# 4. ProfileCondition
+
+> 艿艿：先插播下 ProfileCondition 的实现代码。
+
+`org.springframework.context.annotation.ProfileCondition` ，实现 Condition 接口，给 `@Profile` 使用的 Condition 实现类。代码如下：
+
+```
+// ProfileCondition.java
+
+class ProfileCondition implements Condition {
+
+    @Override
+    public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
+        // 获得 @Profile 注解的属性
+        MultiValueMap<String, Object> attrs = metadata.getAllAnnotationAttributes(Profile.class.getName());
+        // 如果非空，进行判断
+        if (attrs != null) {
+            // 遍历所有 @Profile 的 value 属性
+            for (Object value : attrs.get("value")) {
+                // 判断 environment 有符合的 Profile ，则返回 true ，表示匹配
+                if (context.getEnvironment().acceptsProfiles(Profiles.of((String[]) value))) {
+                    return true;
+                }
+            }
+            // 如果没有，则返回 false
+            return false;
+        }
+        // 如果为空，就表示满足条件
+        return true;
+    }
+
+}
+```
+
+- 核心逻辑，获得 `@Profile` 的 `value` 属性，和 `environment` 是否有匹配的。如果有，则表示匹配。
+
+# 5. SpringBootCondition
+
+`org.springframework.boot.autoconfigure.condition.SpringBootCondition` ，实现 Condition 接口，Spring Boot Condition 的**抽象基类**，主要用于提供相应的日志，帮助开发者判断哪些被进行加载。如下是其上的类注释：
+
+```
+/**
+ * Base of all {@link Condition} implementations used with Spring Boot. Provides sensible
+ * logging to help the user diagnose what classes are loaded.
+ */
+```
+
+## 5.1 matches
+
+实现 `#matches(ConditionContext context, AnnotatedTypeMetadata metadata)` 方法，实现匹配逻辑。代码如下：
+
+```
+// SpringBootCondition.java
+
+@Override
+public final boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
+    // <1> 获得注解的是方法名还是类名
+    String classOrMethodName = getClassOrMethodName(metadata);
+    try {
+        // <2> 条件匹配结果
+        ConditionOutcome outcome = getMatchOutcome(context, metadata);
+        // <3> 打印结果
+        logOutcome(classOrMethodName, outcome);
+        // <4> 记录
+        recordEvaluation(context, classOrMethodName, outcome);
+        // <5> 返回是否匹配
+        return outcome.isMatch();
+    } catch (NoClassDefFoundError ex) {
+        throw new IllegalStateException(
+                "Could not evaluate condition on " + classOrMethodName + " due to "
+                        + ex.getMessage() + " not "
+                        + "found. Make sure your own configuration does not rely on "
+                        + "that class. This can also happen if you are "
+                        + "@ComponentScanning a springframework package (e.g. if you "
+                        + "put a @ComponentScan in the default package by mistake)",
+                ex);
+    } catch (RuntimeException ex) {
+        throw new IllegalStateException("Error processing condition on " + getName(metadata), ex);
+    }
+}
+```
+
+- ```
+  <1>
+  ```
+
+   
+
+  处，调用
+
+   
+
+  ```
+  #getClassOrMethodName(AnnotatedTypeMetadata metadata)
+  ```
+
+   
+
+  方法，获得注解的是方法名还是类名。代码如下：
+
+  ```
+  // SpringBootCondition.java
+  
+  private static String getClassOrMethodName(AnnotatedTypeMetadata metadata) {
+  	// 类
+  	if (metadata instanceof ClassMetadata) {
+  		ClassMetadata classMetadata = (ClassMetadata) metadata;
+  		return classMetadata.getClassName();
+  	}
+  	// 方法
+  	MethodMetadata methodMetadata = (MethodMetadata) metadata;
+  	return methodMetadata.getDeclaringClassName() + "#" + methodMetadata.getMethodName();
+  }
+  ```
+
+- ```
+  <2>
+  ```
+
+   
+
+  处，调用
+
+   
+
+  ```
+  #getMatchOutcome(ConditionContext context, AnnotatedTypeMetadata metadata)
+  ```
+
+   
+
+  抽象
+
+  方法，执行匹配，返回匹配结果。这是一个
+
+  抽象
+
+  方法，由子类进行实现。
+
+  - [`org.springframework.boot.autoconfigure.condition.ConditionOutcome`](https://github.com/YunaiV/spring-boot/blob/master/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/condition/ConditionOutcome.java) ，匹配结果。
+  - [`org.springframework.boot.autoconfigure.condition.ConditionMessage`](https://github.com/YunaiV/spring-boot/blob/master/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/condition/ConditionMessage.java) ，匹配消息。
+  - 以上的类，自己瞅瞅。简单~
+
+- `<3>` 处，调用 `#logOutcome(String classOrMethodName, ConditionOutcome outcome)` 方法，打印结果日志。代码如下：
+
+  ```
+  // SpringBootCondition.java
+      
+  protected final void logOutcome(String classOrMethodName, ConditionOutcome outcome) {
+  	if (this.logger.isTraceEnabled()) {
+  		this.logger.trace(getLogMessage(classOrMethodName, outcome));
+  	}
+  }
+  
+  private StringBuilder getLogMessage(String classOrMethodName, ConditionOutcome outcome) {
+  	StringBuilder message = new StringBuilder();
+  	message.append("Condition ");
+  	message.append(ClassUtils.getShortName(getClass()));
+  	message.append(" on ");
+  	message.append(classOrMethodName);
+  	message.append(outcome.isMatch() ? " matched" : " did not match");
+  	if (StringUtils.hasLength(outcome.getMessage())) {
+  		message.append(" due to ");
+  		message.append(outcome.getMessage());
+  	}
+  	return message;
+  }
+  ```
+
+- `<4>` 处，调用 `#recordEvaluation(ConditionContext context, String classOrMethodName, ConditionOutcome outcome)` 方法，记录到 ConditionEvaluationReport 。代码如下：
+
+  ```
+  // SpringBootCondition.java
+  
+  private void recordEvaluation(ConditionContext context, String classOrMethodName, ConditionOutcome outcome) {
+  	if (context.getBeanFactory() != null) {
+  		ConditionEvaluationReport.get(context.getBeanFactory()).recordConditionEvaluation(classOrMethodName, this, outcome);
+  	}
+  }
+  ```
+
+  - 关于 [org.springframework.boot.autoconfigure.condition.ConditionEvaluationReport](https://github.com/YunaiV/spring-boot/blob/master/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/condition/ConditionEvaluationReport.java) 类，先不详细看，避免研究过深。
+
+- `<5>` 处，返回是否匹配。
+
+## 5.2 anyMatches
+
+`#anyMatches(ConditionContext context, AnnotatedTypeMetadata metadata, Condition... conditions)` 方法，判断是否匹配指定的 Condition 们中的任一一个。代码如下：
+
+> 艿艿：总感觉这个方法，应该是个静态方法才合适。所以，胖友即酱油看看即可。
+
+```
+// SpringBootCondition.java
+    
+protected final boolean anyMatches(ConditionContext context, AnnotatedTypeMetadata metadata, Condition... conditions) {
+    // 遍历 Condition
+    for (Condition condition : conditions) {
+        // 执行匹配
+        if (matches(context, metadata, condition)) {
+            return true;
+        }
+    }
+    return false;
+}
+```
+
+- 遍历
+
+   
+
+  ```
+  conditions
+  ```
+
+   
+
+  数组，调用
+
+   
+
+  ```
+  #matches(ConditionContext context, AnnotatedTypeMetadata metadata, Condition condition)
+  ```
+
+   
+
+  方法，执行匹配。代码如下：
+
+  ```
+  // SpringBootCondition.java
+  
+  protected final boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata, Condition condition) {
+  	// 如果是 SpringBootCondition 类型，执行 SpringBootCondition 的直接匹配方法（无需日志）
+  	if (condition instanceof SpringBootCondition) {
+  		return ((SpringBootCondition) condition).getMatchOutcome(context, metadata).isMatch();
+  	}
+  	return condition.matches(context, metadata);
+  }
+  ```
+
+总的来说，SpringBootCondition 这个类，没啥好说，重点还是在子类。
+
+# 6. SpringBootCondition 的实现类
+
+我们在回忆下，SpringBootCondition 的实现类，主要如下图：[![Spring Boot Condition 实现类](09-Spring Boot 源码分析-Condition.assets/02.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-02-15/02.jpg)Spring Boot Condition 实现类
+
+显然，我们不会去看每一个类的 SpringBootCondition 的实现类。所以呢，艿艿也不会每个类都写。
+
+> 旁白君：偷懒都偷的如此猥琐，哈哈哈哈。
+
+## 6.1 OnPropertyCondition
+
+> 艿艿：来来来，先看一个容易的（捏个软柿子）。
+
+`org.springframework.boot.autoconfigure.condition.OnPropertyCondition` ，继承 SpringBootCondition 抽象类，给 `@ConditionalOnProperty` 使用的 Condition 实现类。
+
+如果胖友不熟悉 `@ConditionalOnProperty` 注解，赶紧打开 [《@ConditionalOnProperty 来控制 Configuration 是否生效》](https://www.jianshu.com/p/68a75c093023) 学习 3 分钟~不能再多了。
+
+### 6.1.1 getMatchOutcome
+
+`#getMatchOutcome(ConditionContext context, AnnotatedTypeMetadata metadata)` 方法，获得匹配结果。代码如下：
+
+```
+// OnPropertyCondition.java
+
+@Override
+public ConditionOutcome getMatchOutcome(ConditionContext context, AnnotatedTypeMetadata metadata) {
+	// <1> 获得 @ConditionalOnProperty 注解的属性
+	List<AnnotationAttributes> allAnnotationAttributes = annotationAttributesFromMultiValueMap(
+			metadata.getAllAnnotationAttributes(ConditionalOnProperty.class.getName()));
+	// <2> 存储匹配和不匹配的结果消息结果
+	List<ConditionMessage> noMatch = new ArrayList<>();
+	List<ConditionMessage> match = new ArrayList<>();
+	// <3> 遍历 annotationAttributes 属性数组，逐个判断是否匹配，并添加到结果
+	for (AnnotationAttributes annotationAttributes : allAnnotationAttributes) {
+		ConditionOutcome outcome = determineOutcome(annotationAttributes, context.getEnvironment());
+		(outcome.isMatch() ? match : noMatch).add(outcome.getConditionMessage());
+	}
+	// <4.1> 如果有不匹配的，则返回不匹配
+	if (!noMatch.isEmpty()) {
+		return ConditionOutcome.noMatch(ConditionMessage.of(noMatch));
+	}
+	// <4.2> 如果都匹配，则返回匹配
+	return ConditionOutcome.match(ConditionMessage.of(match));
+}
+```
+
+- `<1>` 处，调用 `#annotationAttributesFromMultiValueMap(MultiValueMap<String, Object> multiValueMap)` 方法，获得 `@ConditionalOnProperty` 注解的属性。代码如下：
+
+  ```
+  // OnPropertyCondition.java
+  
+  private List<AnnotationAttributes> annotationAttributesFromMultiValueMap(MultiValueMap<String, Object> multiValueMap) {
+  	List<Map<String, Object>> maps = new ArrayList<>();
+  	multiValueMap.forEach((key, value) -> {
+  		for (int i = 0; i < value.size(); i++) {
+  			Map<String, Object> map;
+  			if (i < maps.size()) {
+  				map = maps.get(i);
+  			} else {
+  				map = new HashMap<>();
+  				maps.add(map);
+  			}
+  			map.put(key, value.get(i));
+  		}
+  	});
+  	List<AnnotationAttributes> annotationAttributes = new ArrayList<>(maps.size());
+  	for (Map<String, Object> map : maps) {
+  		annotationAttributes.add(AnnotationAttributes.fromMap(map));
+  	}
+  	return annotationAttributes;
+  }
+  ```
+
+  - 懒的看整个代码实现的过程，可以直接看最终执行的结果图：[![`annotationAttributes`](09-Spring Boot 源码分析-Condition.assets/05.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-02-15/05.jpg)`annotationAttributes`
+
+- `<2>` 处，存储匹配和不匹配的结果消息结果。
+
+- `<3>` 处，遍历 `annotationAttributes` 属性数组，逐个调用 `#determineOutcome(AnnotationAttributes annotationAttributes, PropertyResolver resolver)` 方法，判断是否匹配，并添加到结果。详细解析，见 [「6.1.2 determineOutcome」](https://svip.iocoder.cn/Spring-Boot/Condition/#) 。
+
+- `<4.1>` 处，如果有不匹配的，则返回不匹配。返回结果示例如下：[![不匹配](09-Spring Boot 源码分析-Condition.assets/06.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-02-15/06.jpg)不匹配
+
+- `<4.2>` 处，如果都匹配，则返回匹配。返回结果示例如下：[![匹配](09-Spring Boot 源码分析-Condition.assets/07.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-02-15/07.jpg)匹配
+
+### 6.1.2 determineOutcome
+
+`#determineOutcome(AnnotationAttributes annotationAttributes, PropertyResolver resolver)` 方法，判断是否匹配。代码如下：
+
+```
+// OnPropertyCondition.java
+
+private ConditionOutcome determineOutcome(AnnotationAttributes annotationAttributes, PropertyResolver resolver) {
+    // <1> 解析成 Spec 对象
+    Spec spec = new Spec(annotationAttributes);
+    // <2> 创建结果数组
+    List<String> missingProperties = new ArrayList<>();
+    List<String> nonMatchingProperties = new ArrayList<>();
+    // <3> 收集是否不匹配的信息，到 missingProperties、nonMatchingProperties 中
+    spec.collectProperties(resolver, missingProperties, nonMatchingProperties);
+    // <4.1> 如果有属性缺失，则返回不匹配
+    if (!missingProperties.isEmpty()) {
+        return ConditionOutcome.noMatch(ConditionMessage.forCondition(ConditionalOnProperty.class, spec)
+                        .didNotFind("property", "properties").items(Style.QUOTE, missingProperties));
+    }
+    // <4.2> 如果有属性不匹配，则返回不匹配
+    if (!nonMatchingProperties.isEmpty()) {
+        return ConditionOutcome.noMatch(ConditionMessage.forCondition(ConditionalOnProperty.class, spec)
+                        .found("different value in property", "different value in properties").items(Style.QUOTE, nonMatchingProperties));
+    }
+    // <4.3> 返回匹配
+    return ConditionOutcome.match(ConditionMessage.forCondition(ConditionalOnProperty.class, spec).because("matched"));
+}
+```
+
+- `<1>` 处，解析成 Spec 对象。Spec 是 OnPropertyCondition 的内部静态类。代码如下：
+
+  ```
+  // OnPropertyCondition#Spec.java
+  
+  private static class Spec {
+  
+  	/**
+  	 * 属性前缀
+  	*/
+  	private final String prefix;
+  	/**
+  	 * 是否有指定值
+  	*/
+  	private final String havingValue;
+  	/**
+  	 * 属性名
+  	*/
+  	private final String[] names;
+  	/**
+  	 * 如果属性不存在，是否认为是匹配的。
+  	 *
+  	 * 如果为 false 时，就认为属性丢失，即不匹配。
+  	*/
+  	private final boolean matchIfMissing;
+  
+  	Spec(AnnotationAttributes annotationAttributes) {
+  		String prefix = annotationAttributes.getString("prefix").trim();
+  		if (StringUtils.hasText(prefix) && !prefix.endsWith(".")) {
+  			prefix = prefix + ".";
+  		}
+  		this.prefix = prefix;
+  		this.havingValue = annotationAttributes.getString("havingValue");
+  		this.names = getNames(annotationAttributes);
+  		this.matchIfMissing = annotationAttributes.getBoolean("matchIfMissing");
+  	}
+  
+  	// 从 value 或者 name 属性种，获得值
+  	private String[] getNames(Map<String, Object> annotationAttributes) {
+  		String[] value = (String[]) annotationAttributes.get("value");
+  		String[] name = (String[]) annotationAttributes.get("name");
+  		Assert.state(value.length > 0 || name.length > 0, "The name or value attribute of @ConditionalOnProperty must be specified");
+  		Assert.state(value.length == 0 || name.length == 0, "The name and value attributes of @ConditionalOnProperty are exclusive");
+  		return (value.length > 0) ? value : name;
+  	}
+  	
+  	// ... 省略其它方法先~
+  }
+  ```
+
+- `<2>` 处，创建结果数组。
+
+- `<3>` 处，调用 `Spec#collectProperties(PropertyResolver resolver, List<String> missing, List<String> nonMatching)` 方法，收集是否不匹配的信息，到 `missingProperties`、`nonMatchingProperties` 中。代码如下：
+
+  ```
+  // OnPropertyCondition#Spec.java
+  private void collectProperties(PropertyResolver resolver, List<String> missing, List<String> nonMatching) {
+  	// 遍历 names 数组
+  	for (String name : this.names) {
+  		// 获得完整的 key
+  		String key = this.prefix + name;
+  		// 如果存在指定属性
+  		if (resolver.containsProperty(key)) {
+  			// 匹配值是否匹配
+  			if (!isMatch(resolver.getProperty(key), this.havingValue)) {
+  				nonMatching.add(name);
+  			}
+  		// 如果不存在指定属性
+  		} else {
+  			// 如果属性为空，并且 matchIfMissing 为 false ，则添加到 missing 中
+  			if (!this.matchIfMissing) {
+  				missing.add(name);
+  			}
+  		}
+  	}
+  }
+      
+  private boolean isMatch(String value, String requiredValue) {
+  	// 如果 requiredValue 非空，则进行匹配
+  	if (StringUtils.hasLength(requiredValue)) {
+  		return requiredValue.equalsIgnoreCase(value);
+  	}
+  	// 如果 requiredValue 为空，要求值不为 false
+  	return !"false".equalsIgnoreCase(value);
+  }
+  ```
+
+  - 匹配的逻辑，胖友自己瞅瞅。可能比较绕的逻辑是，`matchIfMissing` 那块，也就看两眼就明白。
+
+- `<4.1>` 处，如果有属性缺失，则返回不匹配。
+
+- `<4.2>` 处，如果有属性不匹配，则返回不匹配。
+
+- `<4.3>` 处，返回匹配。
+
+## 6.2 其它实现类
+
+SpringBootCondition 的其它实现类，胖友可以自己去瞅瞅啦。当然，有部分实现类，我们会在 [「8. FilteringSpringBootCondition」](https://svip.iocoder.cn/Spring-Boot/Condition/#) 分享。
+
+# 7. AutoConfigurationImportFilter
+
+在 [《精尽 Spring Boot 源码分析 —— 自动配置》](http://svip.iocoder.cn/Spring-Boot/AutoConfiguration/) 一文中，我们埋了一个 `AutoConfigurationImportSelector#filter(List<String> configurations, AutoConfigurationMetadata autoConfigurationMetadata)` 方法的坑，没有进行详细解析。所以呢，这一节我们将填掉这个坑。
+
+`org.springframework.boot.autoconfigure.AutoConfigurationImportFilter` 接口，用于过滤掉无需自动引入的自动配置类（Configuration）。正如其类上的注释：
+
+```
+// AutoConfigurationImportFilter.java
+
+/**
+ * Filter that can be registered in {@code spring.factories} to limit the
+ * auto-configuration classes considered. This interface is designed to allow fast removal
+ * of auto-configuration classes before their bytecode is even read.
+ * @since 1.5.0
+ */
+```
+
+- 重点是 `"fast removal of auto-configuration classes before their bytecode is even read"` 。因为自动配置类可能会很多，如果无需使用，而将字节码读取到内存中，这个是一种浪费。
+
+AutoConfigurationImportFilter 的代码如下：
+
+```
+// AutoConfigurationImportFilter.java
+
+@FunctionalInterface
+public interface AutoConfigurationImportFilter {
+
+	/**
+	 * Apply the filter to the given auto-configuration class candidates.
+	 * @param autoConfigurationClasses the auto-configuration classes being considered.
+	 * This array may contain {@code null} elements. Implementations should not change the
+	 * values in this array.
+	 * @param autoConfigurationMetadata access to the meta-data generated by the
+	 * auto-configure annotation processor
+	 * @return a boolean array indicating which of the auto-configuration classes should
+	 * be imported. The returned array must be the same size as the incoming
+	 * {@code autoConfigurationClasses} parameter. Entries containing {@code false} will
+	 * not be imported.
+	 */
+	boolean[] match(String[] autoConfigurationClasses, AutoConfigurationMetadata autoConfigurationMetadata);
+
+}
+```
+
+- 将传入的 `autoConfigurationClasses` 配置类们，根据 `autoConfigurationMetadata` 的元数据（主要是注解信息），进行匹配，判断是否需要引入，然后返回的 `boolean[]` 结果。
+- 并且，`boolean[]` 结果和 `autoConfigurationClasses` 配置类们是一一对应的关系噢。假设 `autoConfigurationClasses[0]` 对应的 `boolean[0]` 为 `false` ，表示无需引入，反之则需要引入。
+
+## 7.1 AutoConfigurationImportFilter 类图
+
+AutoConfigurationImportFilter 的子类如下图所示：[![AutoConfigurationImportFilter 类图](09-Spring Boot 源码分析-Condition.assets/08.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-02-15/08.jpg)AutoConfigurationImportFilter 类图
+
+- 从图中，我们很容易就看出，AutoConfigurationImportFilter 的最终实现类，都是构建在 SpringBootCondition 之上。😈 不过这也很正常，因为 Condition 本身提供的一个功能，就是作为配置类（Configuration）是否能够符合条件被引入。
+
+## 7.2 FilteringSpringBootCondition
+
+`org.springframework.boot.autoconfigure.condition.FilteringSpringBootCondition` ，继承 SpringBootCondition 抽象类，实现 AutoConfigurationImportFilter、BeanFactoryAware、BeanClassLoaderAware 接口，作为**具有 AutoConfigurationImportFilter 功能**的 SpringBootCondition 的抽象基类。
+
+> 注意，上面特意加黑的“具有 AutoConfigurationImportFilter 功能”。
+
+FilteringSpringBootCondition 的基本属性，如下：
+
+```
+// FilteringSpringBootCondition.java
+
+private BeanFactory beanFactory;
+private ClassLoader beanClassLoader;
+```
+
+- 通过 Spring Aware 机制，进行注入。
+
+### 7.2.1 match
+
+实现 `#match(String[] autoConfigurationClasses, AutoConfigurationMetadata autoConfigurationMetadata)` 方法，执行批量的匹配，并返回匹配结果。代码如下：
+
+```
+// FilteringSpringBootCondition.java
+
+@Override // 来自 AutoConfigurationImportFilter 接口
+public boolean[] match(String[] autoConfigurationClasses, AutoConfigurationMetadata autoConfigurationMetadata) {
+    // <1> 获得 ConditionEvaluationReport 对象
+    ConditionEvaluationReport report = ConditionEvaluationReport.find(this.beanFactory);
+    // <2> 执行批量的匹配，并返回匹配结果
+    ConditionOutcome[] outcomes = getOutcomes(autoConfigurationClasses, autoConfigurationMetadata);
+    // <3.1> 创建 match 数组
+    boolean[] match = new boolean[outcomes.length];
+    // <3.2> 遍历 outcomes 结果数组
+    for (int i = 0; i < outcomes.length; i++) {
+        // <3.2.1> 赋值 match 数组
+        match[i] = (outcomes[i] == null || outcomes[i].isMatch()); // 如果返回结果结果为空，也认为匹配
+        // <3.2.2> 如果不匹配，打印日志和记录。
+        if (!match[i] && outcomes[i] != null) {
+            // 打印日志
+            logOutcome(autoConfigurationClasses[i], outcomes[i]);
+            // 记录
+            if (report != null) {
+                report.recordConditionEvaluation(autoConfigurationClasses[i], this, outcomes[i]);
+            }
+        }
+    }
+    // <3.3> 返回 match 数组
+    return match;
+}
+```
+
+- 从实现上，这个方法和 `SpringBootCondition#match(ConditionContext context, AnnotatedTypeMetadata metadata)` 方法，基本是一致的。或者说，是它的批量版本。
+
+- `<1>` 处，获得 ConditionEvaluationReport 对象。
+
+- `<2>` 处，调用 `#getOutcomes(String[] autoConfigurationClasses, AutoConfigurationMetadata autoConfigurationMetadata)` **抽象**方法，执行批量的匹配，并返回匹配结果。这是一个抽象方法，由子类进行实现。
+
+- `<3.1>` 处，创建 `match` 数组。
+
+- ```
+  <3.2>
+  ```
+
+   
+
+  处，遍历
+
+   
+
+  ```
+  outcomes
+  ```
+
+   
+
+  结果数组。
+
+  - `<3.2.1>` 处，赋值 `match` 数组的当前元素。
+  - `<3.2.2>` 处，如果不匹配，打印日志和记录。其中，`#logOutcome(...)` 方法，就是调用父类 SpringBootCondition 的方法。
+
+- `<3.3>` 处，返回 `match` 数组。
+
+### 7.2.2 ClassNameFilter
+
+ClassNameFilter ，是 FilteringSpringBootCondition 的内部类，提供判断类是否存在的功能。代码如下：
+
+```
+// FilteringSpringBootCondition#ClassNameFilter.java
+
+protected enum ClassNameFilter {
+
+    /**
+     * 指定类存在
+     */
+    PRESENT {
+
+        @Override
+        public boolean matches(String className, ClassLoader classLoader) {
+            return isPresent(className, classLoader);
+        }
+
+    },
+
+    /**
+     * 指定类不存在
+     */
+    MISSING {
+
+        @Override
+        public boolean matches(String className, ClassLoader classLoader) {
+            return !isPresent(className, classLoader);
+        }
+
+    };
+
+    public abstract boolean matches(String className, ClassLoader classLoader);
+
+    // 判断是否存在
+    public static boolean isPresent(String className, ClassLoader classLoader) {
+        if (classLoader == null) {
+            classLoader = ClassUtils.getDefaultClassLoader();
+        }
+        try {
+            forName(className, classLoader);
+            return true;
+        } catch (Throwable ex) {
+            return false;
+        }
+    }
+
+    // 加载指定类
+    private static Class<?> forName(String className, ClassLoader classLoader) throws ClassNotFoundException {
+        if (classLoader != null) {
+            return classLoader.loadClass(className);
+        }
+        return Class.forName(className);
+    }
+
+}
+```
+
+- 里面提供了两个实现类，且是单例。
+- 代码比较简单，胖友 5 秒看懂。
+
+### 7.2.3 filter
+
+> 该方法，提供给子类使用。
+
+`#filter(Collection<String> classNames, ClassNameFilter classNameFilter, ClassLoader classLoader)` 方法，通过使用 ClassNameFilter 类，过滤出符合条件的类名的数组。代码如下：
+
+```
+// FilteringSpringBootCondition.java
+
+protected List<String> filter(Collection<String> classNames, ClassNameFilter classNameFilter, ClassLoader classLoader) {
+    // 如果为空，则返回空结果
+    if (CollectionUtils.isEmpty(classNames)) {
+        return Collections.emptyList();
+    }
+    // 创建 matches 数组
+    List<String> matches = new ArrayList<>(classNames.size());
+    // 遍历 classNames 数组，使用 ClassNameFilter 进行判断，是否匹配。
+    for (String candidate : classNames) {
+        if (classNameFilter.matches(candidate, classLoader)) {
+            matches.add(candidate);
+        }
+    }
+    // 返回
+    return matches;
+}
+```
+
+## 7.2.3 AutoConfigurationImportFilter 的使用
+
+在 `AutoConfigurationImportSelector#filter(List<String> configurations, AutoConfigurationMetadata autoConfigurationMetadata)` 方法中，我们可以看到 AutoConfigurationImportFilter 的使用，过滤可以忽略的配置类。代码如下：
+
+```
+// AutoConfigurationImportSelector.java
+
+private List<String> filter(List<String> configurations, AutoConfigurationMetadata autoConfigurationMetadata) {
+//      // <0> 这里是艿艿乱加的。
+//      if (true) {
+//          return configurations;
+//        }
+    // <1> 声明需要用到的变量
+    long startTime = System.nanoTime(); // 记录开始时间，用于下面统计消耗的时间
+    String[] candidates = StringUtils.toStringArray(configurations); // 配置类的数组
+    boolean[] skip = new boolean[candidates.length]; // 每个配置类是否需要忽略的数组，通过下标互相索引
+    boolean skipped = false; // 是否有需要忽略的
+    // <2> 遍历 AutoConfigurationImportFilter 数组，逐个匹配
+    for (AutoConfigurationImportFilter filter : getAutoConfigurationImportFilters()) {
+        // <2.1> 设置 AutoConfigurationImportFilter 的属性们
+        invokeAwareMethods(filter);
+        // <2.2> 执行批量匹配，并返回匹配结果
+        boolean[] match = filter.match(candidates, autoConfigurationMetadata);
+        // <2.3> 遍历匹配结果，判断哪些需要忽略
+        for (int i = 0; i < match.length; i++) {
+            if (!match[i]) { // 如果有不匹配的
+                skip[i] = true;
+                candidates[i] = null; // 标记为空，循环的下一次，就无需匹配它了。
+                skipped = true; // 标记存在不匹配的
+            }
+        }
+    }
+    // <3.1> 如果没有需要忽略的，直接返回 configurations 即可
+    if (!skipped) {
+        return configurations;
+    }
+    // <3.2> 如果存在需要忽略的，构建新的数组，排除掉忽略的
+    List<String> result = new ArrayList<>(candidates.length);
+    for (int i = 0; i < candidates.length; i++) {
+        if (!skip[i]) {
+            result.add(candidates[i]);
+        }
+    }
+    // 打印，消耗的时间，已经排除的数量
+    if (logger.isTraceEnabled()) {
+        int numberFiltered = configurations.size() - result.size();
+        logger.trace("Filtered " + numberFiltered + " auto configuration class in "
+                + TimeUnit.NANOSECONDS.toMillis(System.nanoTime() - startTime)
+                + " ms");
+    }
+    // 返回
+    return new ArrayList<>(result);
+}
+```
+
+- `<0>` 处，这里是艿艿调皮加的。用于测试，如果去掉这块逻辑，是否需有影响。答案当然是，**没有影响**。这里就先不说原因，胖友自己思考下。实际上，本文也已经提及为什么了。
+
+- `<1>` 处，声明需要用到的变量。每个变量，已经添加其对应的注释，不再赘述。
+
+- `<2>` 处，调用 `#getAutoConfigurationImportFilters()` 方法，加载指定类型 AutoConfigurationImportFilter 对应的，在 `META-INF/spring.factories` 里的类名的数组。代码如下：
+
+  ```
+  // AutoConfigurationImportSelector.java
+  protected List<AutoConfigurationImportFilter> getAutoConfigurationImportFilters() {
+  	return SpringFactoriesLoader.loadFactories(AutoConfigurationImportFilter.class, this.beanClassLoader);
+  }
+  ```
+
+  - 例如：[![`filters`](09-Spring Boot 源码分析-Condition.assets/09.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-02-15/09.jpg)`filters`
+  - 就是我们看到的 AutoConfigurationImportFilter 的三个最终实现类。
+
+- `<2.1>`、`<2.3>`、`<2.3>` 处，就是对 `AutoConfigurationImportFilter#filter(String[] autoConfigurationClasses, AutoConfigurationMetadata autoConfigurationMetadata)` 方法的调用，妥妥的。是不是有点顺畅了。
+
+- `<3.1>` 处，如果没有需要忽略的，直接返回 `configurations` 即可。
+
+- `<3.2>` 处，如果存在需要忽略的，构建新的数组，排除掉忽略的。
+
+当然，加载到的自动化配置类（Configuration）也会存在使用 `@ConditionalOnProperty` 等其它条件注解，但是不会在此处被过滤掉。艿艿猜测的原因，可能配置会从外部加载，此时暂时不太好判断。😈 不一定正确，可以星球讨论一波哟。
+
+# 8. FilteringSpringBootCondition 的实现类
+
+## 8.1 OnClassCondition
+
+`org.springframework.boot.autoconfigure.condition.OnClassCondition` ，继承 FilteringSpringBootCondition 抽象类，给 `@ConditionalOnClass`、`@ConditionalOnMissingClass` 使用的 Condition 实现类。
+
+### 8.1.1 getOutcomes
+
+实现 `#getOutcomes(String[] autoConfigurationClasses, AutoConfigurationMetadata autoConfigurationMetadata)` 方法，代码如下：
+
+```
+// OnClassCondition.java
+
+@Override // 来自 FilteringSpringBootCondition 抽象类
+protected final ConditionOutcome[] getOutcomes(String[] autoConfigurationClasses, AutoConfigurationMetadata autoConfigurationMetadata) {
+    // Split the work and perform half in a background thread. Using a single
+    // additional thread seems to offer the best performance. More threads make
+    // things worse
+    // <1> 在后台线程中将工作一分为二。原因是：
+    // * 使用单一附加线程，似乎提供了最好的性能。
+    // * 多个线程，使事情变得更糟
+    int split = autoConfigurationClasses.length / 2;
+    // <2.1> 将前一半，创建一个 OutcomesResolver 对象（新线程）
+    OutcomesResolver firstHalfResolver = createOutcomesResolver(autoConfigurationClasses, 0, split, autoConfigurationMetadata);
+    // <2.2> 将后一半，创建一个 OutcomesResolver 对象
+    OutcomesResolver secondHalfResolver = new StandardOutcomesResolver(autoConfigurationClasses, split, autoConfigurationClasses.length, autoConfigurationMetadata, getBeanClassLoader());
+    // 执行解析（匹配）
+    ConditionOutcome[] secondHalf = secondHalfResolver.resolveOutcomes(); // <3.1>
+    ConditionOutcome[] firstHalf =  firstHalfResolver.resolveOutcomes(); // <3.2>
+    // <4> 创建 outcomes 结果数组，然后合并结果，最后返回
+    ConditionOutcome[] outcomes = new ConditionOutcome[autoConfigurationClasses.length];
+    System.arraycopy(firstHalf, 0, outcomes, 0, firstHalf.length);
+    System.arraycopy(secondHalf, 0, outcomes, split, secondHalf.length);
+    return outcomes;
+}
+```
+
+- `<1>` 处，考虑到配置类（Configuration）配置的 `@ConditionalOnClass`、`@ConditionalOnMissingClass` 注解中的类可能比较多，所以采用多线程提升效率。但是经过测试，分成两个线程，效率是最好的，所以这里才出现了 `autoConfigurationClasses.length / 2` 代码。
+
+- `<2.1>` 处，调用 `#createOutcomesResolver(String[] autoConfigurationClasses, int start, int end, AutoConfigurationMetadata autoConfigurationMetadata)` 方法，创建一个 OutcomesResolver 对象。代码如下：
+
+  ```
+  // OnClassCondition.java
+  
+  private OutcomesResolver createOutcomesResolver(String[] autoConfigurationClasses, int start, int end, AutoConfigurationMetadata autoConfigurationMetadata) {
+  	OutcomesResolver outcomesResolver = new StandardOutcomesResolver(autoConfigurationClasses, start, end, autoConfigurationMetadata, getBeanClassLoader());
+  	try {
+  		return new ThreadedOutcomesResolver(outcomesResolver);
+  	} catch (AccessControlException ex) {
+  		return outcomesResolver;
+  	}
+  }
+  ```
+
+  - 首先，创建了一个 StandardOutcomesResolver 对象 `outcomesResolver` 。
+  - 然后，创建了 ThreadedOutcomesResolver 对象，将 `outcomesResolver` 包装在其中。注意噢，下文我们会看到，ThreadedOutcomesResolver 是启动了一个新线程，执行 StandardOutcomesResolver 的逻辑。
+
+- `<2.2>` 处，将后一半，创建一个 StandardOutcomesResolver 对象。
+
+- 😈 注意哟，创建的 StandardOutcomesResolver、ThreadedOutcomesResolver 对象，都是 OutcomesResolver 的子类。
+
+- `<3.1>` 处，调用后一半的 `StandardOutcomesResolver#resolveOutcomes()` 方法，执行解析（匹配）。
+
+- `<3.2>` 处，调用前一半的 `ThreadedOutcomesResolver#resolveOutcomes()` 方法，执行解析（匹配）。在 ThreadedOutcomesResolver 的实现里，会使用 `Thread#join()` 方法，保证新起的线程，能完成它的任务。这也是为什么，ThreadedOutcomesResolver 后执行的原因。
+
+- `<4>` 处，创建 `outcomes` 结果数组，然后合并结果，最后返回。
+
+### 8.1.2 OutcomesResolver
+
+OutcomesResolver ，是 OnClassCondition 的内部接口，结果解析器接口。代码如下：
+
+```
+// OnClassCondition#OutcomesResolver.java
+
+private interface OutcomesResolver {
+
+    /**
+     * 执行解析
+     *
+     * @return 解析结果
+     */
+	ConditionOutcome[] resolveOutcomes();
+
+}
+```
+
+它的实现类有：
+
+- [「8.1.3 ThreadedOutcomesResolver」](https://svip.iocoder.cn/Spring-Boot/Condition/#)
+- [「8.1.4 StandardOutcomesResolver」](https://svip.iocoder.cn/Spring-Boot/Condition/#)
+
+### 8.1.3 ThreadedOutcomesResolver
+
+ThreadedOutcomesResolver ，是 OnClassCondition 的内部类，实现 OutcomesResolver 接口，开启线程，执行 OutcomesResolver 的逻辑。代码如下：
+
+```
+// OnClassCondition#ThreadedOutcomesResolver.java
+
+private static final class ThreadedOutcomesResolver implements OutcomesResolver {
+
+    /**
+     * 新起的线程
+     */
+    private final Thread thread;
+    /**
+     * 条件匹配结果
+     */
+    private volatile ConditionOutcome[] outcomes;
+
+    private ThreadedOutcomesResolver(OutcomesResolver outcomesResolver) {
+        // <1.1> 创建线程
+        this.thread = new Thread(
+                () -> this.outcomes = outcomesResolver.resolveOutcomes());
+        // <1.2> 启动线程
+        this.thread.start();
+    }
+
+    @Override
+    public ConditionOutcome[] resolveOutcomes() {
+        // <2.1> 等待线程执行结束
+        try {
+            this.thread.join();
+        } catch (InterruptedException ex) {
+            Thread.currentThread().interrupt();
+        }
+        // <2.2> 返回结果
+        return this.outcomes;
+    }
+
+}
+```
+
+- `<1.1>`、`<1.2>` 处，在构建方法中，创建新的线程，并启动线程，从而调用 `OutcomesResolver#resolveOutcomes()` 方法，执行匹配逻辑。
+- `<2.1>` 处，等待线程执行结束。
+- `<2.2>` 处，返回结果。
+- 😈 是不是这里一看，就明白 [「8.1.1 getOutcomes」](https://svip.iocoder.cn/Spring-Boot/Condition/#) 中，是这样的调用顺序了。
+
+### 8.1.4 StandardOutcomesResolver
+
+StandardOutcomesResolver ，是 OnClassCondition 的内部类，实现 OutcomesResolver 接口，**标准的** StandardOutcomesResolver 实现类。
+
+#### 8.1.4.1 构造方法
+
+```
+// OnClassCondition#StandardOutcomesResolver.java
+
+private final class StandardOutcomesResolver implements OutcomesResolver {
+
+    /**
+     * 所有的配置类的数组
+     */
+    private final String[] autoConfigurationClasses;
+    /**
+     * 匹配的 {@link #autoConfigurationClasses} 开始位置
+     */
+    private final int start;
+    /**
+     * 匹配的 {@link #autoConfigurationClasses} 结束位置
+     */
+    private final int end;
+
+    private final AutoConfigurationMetadata autoConfigurationMetadata;
+
+    private final ClassLoader beanClassLoader;
+
+    private StandardOutcomesResolver(String[] autoConfigurationClasses, int start, int end, AutoConfigurationMetadata autoConfigurationMetadata, ClassLoader beanClassLoader) {
+        this.autoConfigurationClasses = autoConfigurationClasses;
+        this.start = start;
+        this.end = end;
+        this.autoConfigurationMetadata = autoConfigurationMetadata;
+        this.beanClassLoader = beanClassLoader;
+    }
+    
+    // ... 省略无关的方法先
+}
+```
+
+#### 8.1.4.2 resolveOutcomes
+
+`#resolveOutcomes()` 方法，执行批量匹配，并返回结果。代码如下：
+
+```
+// OnClassCondition#StandardOutcomesResolver.java
+
+@Override
+public ConditionOutcome[] resolveOutcomes() {
+    return getOutcomes(this.autoConfigurationClasses, this.start, this.end, this.autoConfigurationMetadata);
+}
+
+private ConditionOutcome[] getOutcomes(String[] autoConfigurationClasses, int start, int end, AutoConfigurationMetadata autoConfigurationMetadata) {
+    // 创建 ConditionOutcome 结构数组
+    ConditionOutcome[] outcomes = new ConditionOutcome[end - start];
+    // 遍历 autoConfigurationClasses 数组，从 start 到 end
+    for (int i = start; i < end; i++) {
+        String autoConfigurationClass = autoConfigurationClasses[i];
+        if (autoConfigurationClass != null) {
+            // <1> 获得指定自动配置类的 @ConditionalOnClass 注解的要求类
+            String candidates = autoConfigurationMetadata.get(autoConfigurationClass, "ConditionalOnClass");
+            if (candidates != null) {
+                // 执行匹配
+                outcomes[i - start] = getOutcome(candidates);
+            }
+        }
+    }
+    return outcomes;
+}
+```
+
+- `<1>` 处，获得指定自动配置类的 `@ConditionalOnClass` 注解的要求类。例如下图：[![`candidates` 示例](09-Spring Boot 源码分析-Condition.assets/10.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-02-15/10.jpg)`candidates` 示例
+
+- `<2>` 处，调用 `#getOutcome(String candidates)` 方法，执行匹配。代码如下：
+
+  ```
+  // OnClassCondition#StandardOutcomesResolver.java
+  
+  private ConditionOutcome getOutcome(String candidates) {
+      try {
+          // 如果没有 , ，说明只有一个，直接匹配即可
+          if (!candidates.contains(",")) {
+              return getOutcome(candidates, this.beanClassLoader); // <3>
+          }
+          // 如果有 , ，说明有多个，逐个匹配
+          for (String candidate : StringUtils.commaDelimitedListToStringArray(candidates)) {
+              // 执行匹配
+              ConditionOutcome outcome = getOutcome(candidate, this.beanClassLoader); // <3>
+              // 如果存在不匹配，则返回该结果
+              if (outcome != null) {
+                  return outcome;
+              }
+          }
+      } catch (Exception ex) {
+          // We'll get another chance later
+      }
+      return null;
+  }
+  ```
+
+  - `<3>` 处，调用 `#getOutcome(String className, ClassLoader classLoader)` 方法，执行匹配。代码如下：
+
+    ```
+    // OnClassCondition#StandardOutcomesResolver.java
+    
+    private ConditionOutcome getOutcome(String className, ClassLoader classLoader) {
+    	if (ClassNameFilter.MISSING.matches(className, classLoader)) {
+    		return ConditionOutcome.noMatch(ConditionMessage
+    				.forCondition(ConditionalOnClass.class).didNotFind("required class").items(Style.QUOTE, className));
+    	}
+    	return null;
+    }
+    ```
+
+    - 通过使用 `ClassNameFilter.MISSING` 来，进行匹配类是否不存在。
+
+看到此处，我们会发现 [「8.1.1 getOutcomes」](https://svip.iocoder.cn/Spring-Boot/Condition/#) 的整个逻辑，暂时只做了 `@ConditionalOnClass` 注解的条件匹配，还有一个 `@ConditionalOnMissingClass` 注解呢？答案在 [「8.1.5 getMatchOutcome」](https://svip.iocoder.cn/Spring-Boot/Condition/#) 。
+
+### 8.1.5 getMatchOutcome
+
+`#getMatchOutcome(ConditionContext context, AnnotatedTypeMetadata metadata)` 方法，执行 `@ConditionalOnClass` 和 `@ConditionalOnMissingClass` 注解的匹配。代码如下：
+
+```
+// OnClassCondition.java
+
+@Override // 来自 SpringBootCondition 抽象类
+public ConditionOutcome getMatchOutcome(ConditionContext context, AnnotatedTypeMetadata metadata) {
+    // <1> 声明变量
+    ClassLoader classLoader = context.getClassLoader();
+    ConditionMessage matchMessage = ConditionMessage.empty(); // 匹配的信息
+    // <2> 获得 `@ConditionalOnClass` 注解的属性
+    List<String> onClasses = getCandidates(metadata, ConditionalOnClass.class);
+    if (onClasses != null) {
+        // 执行匹配，看看是否有缺失的
+        List<String> missing = filter(onClasses, ClassNameFilter.MISSING, classLoader);
+        // 如果有不匹配的，返回不匹配信息
+        if (!missing.isEmpty()) {
+            return ConditionOutcome.noMatch(ConditionMessage.forCondition(ConditionalOnClass.class)
+                    .didNotFind("required class", "required classes").items(Style.QUOTE, missing));
+        }
+        // 如果匹配，添加到 matchMessage 中
+        matchMessage = matchMessage.andCondition(ConditionalOnClass.class)
+                .found("required class", "required classes").items(Style.QUOTE, filter(onClasses, ClassNameFilter.PRESENT, classLoader));
+    }
+    // <3> 获得 `@ConditionalOnMissingClass` 注解的属性
+    List<String> onMissingClasses = getCandidates(metadata, ConditionalOnMissingClass.class);
+    if (onMissingClasses != null) {
+        // 执行匹配，看看是有多余的
+        List<String> present = filter(onMissingClasses, ClassNameFilter.PRESENT, classLoader);
+        // 如果有不匹配的，返回不匹配信息
+        if (!present.isEmpty()) {
+            return ConditionOutcome.noMatch(ConditionMessage.forCondition(ConditionalOnMissingClass.class)
+                    .found("unwanted class", "unwanted classes").items(Style.QUOTE, present));
+        }
+        // 如果匹配，添加到 matchMessage 中
+        matchMessage = matchMessage.andCondition(ConditionalOnMissingClass.class)
+                .didNotFind("unwanted class", "unwanted classes").items(Style.QUOTE, filter(onMissingClasses, ClassNameFilter.MISSING, classLoader));
+    }
+    // <4> 返回匹配的结果
+    return ConditionOutcome.match(matchMessage);
+}
+```
+
+- `<1>` 处，声明变量。
+- `<2>` 处，获得 `@ConditionalOnClass` 注解的属性。后续的，通过使用 [「7.2.3 filter」](https://svip.iocoder.cn/Spring-Boot/Condition/#) 方法，看看是否有缺失的类。
+- `<3>` 处，获得 `@ConditionalOnMissingClass` 注解的属性。后续的，通过使用 [「7.2.3 filter」](https://svip.iocoder.cn/Spring-Boot/Condition/#) 方法，看看是否有多余的类。
+- `<4>` 处，返回匹配的结果。
+
+## 8.2 OnWebApplicationCondition
+
+`org.springframework.boot.autoconfigure.condition.OnWebApplicationCondition` ，继承 FilteringSpringBootCondition 抽象类，给 `@ConditionalOnWebApplication` 和 `@ConditionalOnNotWebApplication` 使用的 Condition 实现类。
+
+### 8.2.1 getOutcomes
+
+`#getOutcomes(String[] autoConfigurationClasses, AutoConfigurationMetadata autoConfigurationMetadata)` 方法，代码如下：
+
+```
+// OnWebApplicationCondition.java
+
+@Override // 来自 FilteringSpringBootCondition 抽象类
+protected ConditionOutcome[] getOutcomes(String[] autoConfigurationClasses, AutoConfigurationMetadata autoConfigurationMetadata) {
+    // <1> 创建 outcomes 结果数组
+    ConditionOutcome[] outcomes = new ConditionOutcome[autoConfigurationClasses.length];
+    // <2> 遍历 autoConfigurationClasses 数组，执行匹配
+    for (int i = 0; i < outcomes.length; i++) {
+        // 获得配置类
+        String autoConfigurationClass = autoConfigurationClasses[i];
+        if (autoConfigurationClass != null) {
+            // 执行匹配
+            outcomes[i] = getOutcome(autoConfigurationMetadata.get(autoConfigurationClass,  "ConditionalOnWebApplication")); // 获得 @ConditionalOnWebApplication 注解
+        }
+    }
+    return outcomes;
+}
+```
+
+- `<1>` 处，创建 `outcomes` 结果数组。
+
+- `<2>` 处，遍历 `autoConfigurationClasses` 数组，调用 `#getOutcome(String type)` 方法，执行匹配。代码如下：
+
+  ```
+  // OnWebApplicationCondition.java
+  
+  private static final String SERVLET_WEB_APPLICATION_CLASS = "org.springframework.web.context.support.GenericWebApplicationContext";
+  private static final String REACTIVE_WEB_APPLICATION_CLASS = "org.springframework.web.reactive.HandlerResult";  
+  
+  private ConditionOutcome getOutcome(String type) {
+      if (type == null) {
+          return null;
+      }
+      ConditionMessage.Builder message = ConditionMessage.forCondition(ConditionalOnWebApplication.class);
+      // <2.1> 如果要求 SERVLET 类型，结果不存在 SERVLET_WEB_APPLICATION_CLASS 类，返回不匹配
+      if (ConditionalOnWebApplication.Type.SERVLET.name().equals(type)) {
+          if (!ClassNameFilter.isPresent(SERVLET_WEB_APPLICATION_CLASS, getBeanClassLoader())) {
+              return ConditionOutcome.noMatch(message.didNotFind("servlet web application classes").atAll());
+          }
+      }
+      // <2.2> 如果要求 REACTIVE 类型，结果不存在 REACTIVE_WEB_APPLICATION_CLASS 类，返回不匹配
+      if (ConditionalOnWebApplication.Type.REACTIVE.name().equals(type)) {
+          if (!ClassNameFilter.isPresent(REACTIVE_WEB_APPLICATION_CLASS, getBeanClassLoader())) {
+              return ConditionOutcome.noMatch(message.didNotFind("reactive web application classes").atAll());
+          }
+      }
+      // <2.3> 如果 SERVLET_WEB_APPLICATION_CLASS 和 REACTIVE_WEB_APPLICATION_CLASS 都不存在，返回不匹配
+      if (!ClassNameFilter.isPresent(SERVLET_WEB_APPLICATION_CLASS, getBeanClassLoader())
+              && !ClassUtils.isPresent(REACTIVE_WEB_APPLICATION_CLASS, getBeanClassLoader())) {
+          return ConditionOutcome.noMatch(message.didNotFind("reactive or servlet web application classes").atAll());
+      }
+      return null;
+  }
+  ```
+
+  - `<2.1>` 处，如果要求 `SERVLET` 类型，结果不存在 `SERVLET_WEB_APPLICATION_CLASS` 类，返回不匹配。
+  - `<2.2>` 处，如果要求 `REACTIVE` 类型，结果不存在 `REACTIVE_WEB_APPLICATION_CLASS` 类，返回不匹配。
+  - `<2.3>` 处，如果 `SERVLET_WEB_APPLICATION_CLASS` 和 `REACTIVE_WEB_APPLICATION_CLASS` 都不存在，返回不匹配。
+
+### 8.2.2 getMatchOutcome
+
+`#getMatchOutcome(ConditionContext context, AnnotatedTypeMetadata metadata)` 方法，代码如下：
+
+```
+// OnWebApplicationCondition.java
+
+@Override // 来自 SpringBootCondition 抽象类
+public ConditionOutcome getMatchOutcome(ConditionContext context, AnnotatedTypeMetadata metadata) {
+    // <1> 通过是否有 @ConditionalOnWebApplication 注解，判断是否要求在 Web 环境下
+    boolean required = metadata.isAnnotated(ConditionalOnWebApplication.class.getName());
+    // <2> 判断是否匹配 Web 环境
+    ConditionOutcome outcome = isWebApplication(context, metadata, required);
+    // <3.1> 如果要求，结果不匹配 Web 环境，返回最终不匹配
+    if (required && !outcome.isMatch()) {
+        return ConditionOutcome.noMatch(outcome.getConditionMessage());
+    }
+    // <3.2> 如果不要求，结果匹配 Web 环境，返回最终不匹配
+    if (!required && outcome.isMatch()) {
+        return ConditionOutcome.noMatch(outcome.getConditionMessage());
+    }
+    // <3.3> 返回匹配
+    return ConditionOutcome.match(outcome.getConditionMessage());
+}
+```
+
+- `<1>` 处，通过是否有 `@ConditionalOnWebApplication` 注解，判断是否要求在 Web 环境下。为什么能这么判断呢？因为 `@ConditionalOnNotWebApplication` 注解，也能走进这个方法，但是如果没有 `@ConditionalOnWebApplication` 注解，就意味着有 `@ConditionalOnNotWebApplication` 注解，也就是不要求 Web 环境。😈 是不是有点绕~
+- `<2>` 处，调用 `#isWebApplication(ConditionContext context, AnnotatedTypeMetadata metadata, boolean required)` 方法，判断是否匹配 Web 环境。详细解析，见 [「8.2.3 isWebApplication」](https://svip.iocoder.cn/Spring-Boot/Condition/#) 。
+- `<3.1>` 处，如果要求，结果不匹配 Web 环境，返回最终不匹配。
+- `<3.2>` 处，如果不要求，结果匹配 Web 环境，返回最终不匹配。
+- `<3.3>` 处，返回匹配。
+
+### 8.2.3 isWebApplication
+
+`#isWebApplication(ConditionContext context, AnnotatedTypeMetadata metadata, boolean required)` 方法，判断是否匹配 Web 环境。代码如下：
+
+```
+// OnWebApplicationCondition.java
+
+private ConditionOutcome isWebApplication(ConditionContext context, AnnotatedTypeMetadata metadata, boolean required) {
+	switch (deduceType(metadata)) { // <1> 获得要求的 Web 类型
+        case SERVLET:
+            return isServletWebApplication(context); // <2.1> 判断是否 Servlet Web 环境
+        case REACTIVE:
+            return isReactiveWebApplication(context); // <2.2> 判断是否 Reactive Web 环境
+        default:
+            return isAnyWebApplication(context, required); // <2.3> 判断是否为任意 Web 环境
+	}
+}
+```
+
+- `<1>` 处，调用 `#deduceType(AnnotatedTypeMetadata metadata)` 方法，获得要求的 Web 类型。代码如下：
+
+  ```
+  // OnWebApplicationCondition.java
+  
+  private Type deduceType(AnnotatedTypeMetadata metadata) {
+  	Map<String, Object> attributes = metadata.getAnnotationAttributes(ConditionalOnWebApplication.class.getName());
+  	if (attributes != null) {
+  		return (Type) attributes.get("type");
+  	}
+  	return Type.ANY;
+  }
+  ```
+
+- `<2.1>` 处，调用 `#isServletWebApplication(context)` 方法，判断是否 Servlet Web 环境。代码如下：
+
+  ```
+  // OnWebApplicationCondition.java
+  
+  private ConditionOutcome isServletWebApplication(ConditionContext context) {
+      ConditionMessage.Builder message = ConditionMessage.forCondition("");
+      // 如果不存在 SERVLET_WEB_APPLICATION_CLASS 类，返回不匹配
+      if (!ClassNameFilter.isPresent(SERVLET_WEB_APPLICATION_CLASS, context.getClassLoader())) {
+          return ConditionOutcome.noMatch(message.didNotFind("servlet web application classes").atAll());
+      }
+      if (context.getBeanFactory() != null) {
+          // 如果不存在 session scope ，返回不匹配
+          String[] scopes = context.getBeanFactory().getRegisteredScopeNames();
+          if (ObjectUtils.containsElement(scopes, "session")) {
+              return ConditionOutcome.match(message.foundExactly("'session' scope"));
+          }
+      }
+      // 如果 environment 是 ConfigurableWebEnvironment 类型，返回匹配！！！
+      if (context.getEnvironment() instanceof ConfigurableWebEnvironment) {
+          return ConditionOutcome.match(message.foundExactly("ConfigurableWebEnvironment"));
+      }
+      // 如果 resourceLoader 是 WebApplicationContext 类型，返回匹配！！！
+      if (context.getResourceLoader() instanceof WebApplicationContext) {
+          return ConditionOutcome.match(message.foundExactly("WebApplicationContext"));
+      }
+      // 如果 resourceLoader 不是 WebApplicationContext 类型，返回不匹配
+      return ConditionOutcome.noMatch(message.because("not a servlet web application"));
+  }
+  ```
+
+- `<2.2>` 处，调用 `#isReactiveWebApplication(ConditionContext context)` 方法，代码如下：
+
+  ```
+  // OnWebApplicationCondition.java
+  
+  private ConditionOutcome isReactiveWebApplication(ConditionContext context) {
+  	ConditionMessage.Builder message = ConditionMessage.forCondition("");
+  	// 如果不存在 REACTIVE_WEB_APPLICATION_CLASS 类，返回不匹配
+  	if (!ClassNameFilter.isPresent(REACTIVE_WEB_APPLICATION_CLASS, context.getClassLoader())) {
+  		return ConditionOutcome.noMatch(message.didNotFind("reactive web application classes").atAll());
+  	}
+  	// 如果 environment 是 ConfigurableReactiveWebEnvironment 类型，返回匹配
+  	if (context.getEnvironment() instanceof ConfigurableReactiveWebEnvironment) {
+  		return ConditionOutcome.match(message.foundExactly("ConfigurableReactiveWebEnvironment"));
+  	}
+  	// 如果 resourceLoader 是 ConfigurableReactiveWebEnvironment 类型，返回匹配
+  	if (context.getResourceLoader() instanceof ReactiveWebApplicationContext) {
+  		return ConditionOutcome.match(message.foundExactly("ReactiveWebApplicationContext"));
+  	}
+  	// 返回不匹配
+  	return ConditionOutcome.noMatch(message.because("not a reactive web application"));
+  }
+  ```
+
+- `<2.3>` 处，调用 `#isAnyWebApplication(ConditionContext context, boolean required)` 方法，代码如下：
+
+  ```
+  // OnWebApplicationCondition.java
+  
+  private ConditionOutcome isAnyWebApplication(ConditionContext context, boolean required) {
+  	ConditionMessage.Builder message = ConditionMessage.forCondition(ConditionalOnWebApplication.class, required ? "(required)" : "");
+  	// 如果是 Servlet 环境，并且要求 WEB 环境，返回匹配
+  	ConditionOutcome servletOutcome = isServletWebApplication(context);
+  	if (servletOutcome.isMatch() && required) {
+  		return new ConditionOutcome(servletOutcome.isMatch(), message.because(servletOutcome.getMessage()));
+  	}
+  	// 如果是 Reactive 环境，并且要求 WEB 环境，返回匹配
+  	ConditionOutcome reactiveOutcome = isReactiveWebApplication(context);
+  	if (reactiveOutcome.isMatch() && required) {
+  		return new ConditionOutcome(reactiveOutcome.isMatch(), message.because(reactiveOutcome.getMessage()));
+  	}
+  	// 根据情况，返回是否匹配
+  	return new ConditionOutcome(servletOutcome.isMatch() || reactiveOutcome.isMatch(), // 要求 Servlet 环境 or Reactive 环境，其中有一个匹配
+  			message.because(servletOutcome.getMessage()).append("and").append(reactiveOutcome.getMessage()));
+  }
+  ```
+
+## 8.3 OnBeanCondition
+
+`org.springframework.boot.autoconfigure.condition.OnBeanCondition` ，继承 FilteringSpringBootCondition 抽象类，给 `@ConditionalOnBean`、`@ConditionalOnMissingBean`、`@ConditionalOnSingleCandidate` 使用的 Condition 实现类。
+
+艿艿就暂时先不写了，因为这个类有点复杂，我想偷懒，哈哈哈。当然，感兴趣的胖友，可以看看 [《SpringBoot @ConditionalOnBean、@ConditionalOnMissingBean 注解源码分析与示例》](https://blog.csdn.net/xcy1193068639/article/details/81517456) 一文。
+
+# 666. 彩蛋
+
+本文以为是一篇半天就能解决的博客，结果写了一天半。希望尽可能覆盖到大多数细节。😈
+
+参考和推荐如下文章：
+
+- dm_vincent
+
+  - [《[Spring Boot\] 3. Spring Boot实现自动配置的基础》](https://blog.csdn.net/dm_vincent/article/details/77435515)
+  - [《[Spring Boot\] 4. Spring Boot实现自动配置的原理》](https://blog.csdn.net/dm_vincent/article/details/77619752)
+
+- oldflame-Jm [《Spring boot源码分析-Conditional（12）》](https://blog.csdn.net/jamet/article/details/78505708)
+
+- 一个努力的码农 [《spring boot 源码解析19-@Conditional注解详解》](https://blog.csdn.net/qq_26000415/article/details/79008745)
+
+- 快乐崇拜 [《Spring Boot 源码深入分析》](https://gitbook.cn/books/5a445f030173cb29d2041d61/index.html)
+
+  > 有木发现，艿艿写的比他详细很多很多。
\ No newline at end of file
diff --git a/springboot/10-Spring Boot 源码分析-ServletWebServerApplicationContext.assets/01.jpg b/springboot/10-Spring Boot 源码分析-ServletWebServerApplicationContext.assets/01.jpg
new file mode 100644
index 0000000..30a2220
Binary files /dev/null and b/springboot/10-Spring Boot 源码分析-ServletWebServerApplicationContext.assets/01.jpg differ
diff --git a/springboot/10-Spring Boot 源码分析-ServletWebServerApplicationContext.md b/springboot/10-Spring Boot 源码分析-ServletWebServerApplicationContext.md
new file mode 100644
index 0000000..752903a
--- /dev/null
+++ b/springboot/10-Spring Boot 源码分析-ServletWebServerApplicationContext.md	
@@ -0,0 +1,794 @@
+# 精尽 Spring Boot 源码分析 —— ServletWebServerApplicationContext
+
+# 1. 概述
+
+在 [《精尽 Spring Boot 源码分析 —— SpringApplication》](http://svip.iocoder.cn/Spring-Boot/SpringApplication/) 一文中，我们看到 `SpringApplication#createApplicationContext()` 方法，根据不同的 Web 应用类型，创建不同的 Spring 容器。代码如下：
+
+```
+// SpringApplication.java
+
+/**
+ * The class name of application context that will be used by default for non-web
+ * environments.
+ */
+public static final String DEFAULT_CONTEXT_CLASS = "org.springframework.context."
+		+ "annotation.AnnotationConfigApplicationContext";
+
+/**
+ * The class name of application context that will be used by default for web
+ * environments.
+ */
+public static final String DEFAULT_SERVLET_WEB_CONTEXT_CLASS = "org.springframework.boot."
+		+ "web.servlet.context.AnnotationConfigServletWebServerApplicationContext";
+
+/**
+ * The class name of application context that will be used by default for reactive web
+ * environments.
+ */
+public static final String DEFAULT_REACTIVE_WEB_CONTEXT_CLASS = "org.springframework."
+		+ "boot.web.reactive.context.AnnotationConfigReactiveWebServerApplicationContext";
+
+protected ConfigurableApplicationContext createApplicationContext() {
+    // 根据 webApplicationType 类型，获得 ApplicationContext 类型
+	Class<?> contextClass = this.applicationContextClass;
+	if (contextClass == null) {
+		try {
+			switch (this.webApplicationType) {
+			case SERVLET:
+				contextClass = Class.forName(DEFAULT_SERVLET_WEB_CONTEXT_CLASS);
+				break;
+			case REACTIVE:
+				contextClass = Class.forName(DEFAULT_REACTIVE_WEB_CONTEXT_CLASS);
+				break;
+			default:
+				contextClass = Class.forName(DEFAULT_CONTEXT_CLASS);
+			}
+		} catch (ClassNotFoundException ex) {
+			throw new IllegalStateException("Unable create a default ApplicationContext, " + "please specify an ApplicationContextClass", ex);
+		}
+	}
+	// 创建 ApplicationContext 对象
+	return (ConfigurableApplicationContext) BeanUtils.instantiateClass(contextClass);
+}
+```
+
+- 本文，我们要分享的就是，`SERVLET` 类型对应的 Spring 容器类型 **AnnotationConfigServletWebServerApplicationContext** 类。
+
+AnnotationConfigServletWebServerApplicationContext 的类图关系如下：[![类图](10-Spring Boot 源码分析-ServletWebServerApplicationContext.assets/01.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-01-16/01.jpg)类图
+
+- 本文，我们只重点看 ServletWebServerApplicationContext 和 AnnotationConfigServletWebServerApplicationContext 类。
+
+- 为了阅读的友好性，艿艿希望胖友阅读过 [《精尽 Spring MVC 源码分析 —— 容器的初始化（三）之 Servlet 3.0 集成》](http://svip.iocoder.cn/Spring-MVC/context-init-integration-with-Servlet-3.0/) 和 [《精尽 Spring MVC 源码分析 —— 容器的初始化（四）之 Spring Boot 集成》](http://svip.iocoder.cn/Spring-MVC/context-init-integration-with-SpringBoot/) 两文。
+
+  > 艿艿：厚着脸皮说，上面两篇文章提到的内容，基本就不再赘述。
+  > 旁白君：真不要脸！
+
+# 2. ServletWebServerApplicationContext
+
+`org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext` ，实现 ConfigurableWebServerApplicationContext 接口，继承 GenericWebApplicationContext 类，Spring Boot 使用 Servlet Web 服务器的 ApplicationContext 实现类。
+
+- `org.springframework.boot.web.servlet.context.ConfigurableWebServerApplicationContext` 接口，实现它后，可以获得管理 WebServer 的能力。代码如下：
+
+  ```
+  // ConfigurableWebServerApplicationContext.java
+  
+  public interface ConfigurableWebServerApplicationContext extends ConfigurableApplicationContext, WebServerApplicationContext {
+  
+  	/**
+  	 * Set the server namespace of the context.
+  	 * @param serverNamespace the server namespace
+  	 * @see #getServerNamespace()
+  	 */
+  	void setServerNamespace(String serverNamespace);
+  
+  }
+  ```
+
+  - [`org.springframework.context.ConfigurableApplicationContext`](https://github.com/YunaiV/spring-framework/blob/master/spring-context/src/main/java/org/springframework/context/ConfigurableApplicationContext.java) ，是 Spring Framework 提供的类，就不细看了。
+
+  - `org.springframework.boot.web.context.WebServerApplicationContext` ，继承 ApplicationContext 接口，WebServer ApplicationContext 接口。代码如下：
+
+    ```
+    // WebServerApplicationContext.java
+    
+    public interface WebServerApplicationContext extends ApplicationContext {
+    
+    	/**
+    	 * Returns the {@link WebServer} that was created by the context or {@code null} if
+    	 * the server has not yet been created.
+    	 * @return the web server
+    	 */
+    	WebServer getWebServer();
+    
+    	/**
+    	 * Returns the namespace of the web server application context or {@code null} if no
+    	 * namespace has been set. Used for disambiguation when multiple web servers are
+    	 * running in the same application (for example a management context running on a
+    	 * different port).
+    	 * @return the server namespace
+    	 */
+    	String getServerNamespace();
+    
+    }
+    ```
+
+    - 重点是，可以获得 WebServer 的方法。😈 因为获得它，可以做各种 WebServer 的管理。
+
+- [`org.springframework.web.context.support.GenericWebApplicationContext`](https://github.com/YunaiV/spring-framework/blob/master/spring-web/src/main/java/org/springframework/web/context/support/GenericWebApplicationContext.java) ，是 Spring Framework 提供的类，就不细看啦。
+
+## 2.1 构造方法
+
+```
+// ServletWebServerApplicationContext.java
+
+/**
+ * Constant value for the DispatcherServlet bean name. A Servlet bean with this name
+ * is deemed to be the "main" servlet and is automatically given a mapping of "/" by
+ * default. To change the default behavior you can use a
+ * {@link ServletRegistrationBean} or a different bean name.
+ */
+public static final String DISPATCHER_SERVLET_NAME = "dispatcherServlet";
+
+/**
+ * Spring  WebServer 对象
+ */
+private volatile WebServer webServer;
+/**
+ * Servlet ServletConfig 对象
+ */
+private ServletConfig servletConfig;
+/**
+ * 通过 {@link #setServerNamespace(String)} 注入。
+ *
+ * 不过貌似，一直没被注入过，可以暂时先无视
+ */
+private String serverNamespace;
+
+public ServletWebServerApplicationContext() {
+}
+
+public ServletWebServerApplicationContext(DefaultListableBeanFactory beanFactory) {
+	super(beanFactory);
+}
+```
+
+- 简单看看即可。
+
+因为后续的逻辑，涉及到 Spring 容器的初始化的生命周期，所以我们来简单看看 `AbstractApplicationContext#refresh()` 的方法。代码如下：
+
+```
+// AbstractApplicationContext.java
+// `#refresh()` 方法
+
+// ... 简化版代码
+
+// Allows post-processing of the bean factory in context subclasses.
+postProcessBeanFactory(beanFactory); // <1>
+
+// Invoke factory processors registered as beans in the context.
+invokeBeanFactoryPostProcessors(beanFactory);
+
+// Register bean processors that intercept bean creation.
+registerBeanPostProcessors(beanFactory);
+
+// Initialize message source for this context.
+initMessageSource();
+
+// Initialize event multicaster for this context.
+initApplicationEventMulticaster();
+
+// Initialize other special beans in specific context subclasses.
+onRefresh(); // <2>
+
+// Check for listener beans and register them.
+registerListeners();
+
+// Instantiate all remaining (non-lazy-init) singletons.
+finishBeanFactoryInitialization(beanFactory);
+
+// Last step: publish corresponding event.
+finishRefresh(); // <3>
+```
+
+- 这个方法，会被覆写。具体可以看 [「2.2 refresh」](https://svip.iocoder.cn/Spring-Boot/ServletWebServerApplicationContext/#) 小节。但是，即使覆写了，还是会调用该方法。
+
+- `<1>` 处，调用 `#postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory)` 方法，具体可以看 [「2.3 postProcessBeanFactory」](https://svip.iocoder.cn/Spring-Boot/ServletWebServerApplicationContext/#) 小节。
+
+  > 对 Spring BeanFactoryPostProcessor 的机制，可以看看 [《【死磕 Spring】—— IoC 之深入分析 BeanFactoryPostProcessor》](http://svip.iocoder.cn/Spring/IoC-BeanFactoryPostProcessor)
+
+- `<2>` 处，调用 `#onRefresh()` 方法，具体可以看 [「2.4 onRefresh」](https://svip.iocoder.cn/Spring-Boot/ServletWebServerApplicationContext/#) 小节。
+
+- `<3>` 处，调用 `#finishRefresh()` 方法，具体可以看 [「2.5 finishRefresh」](https://svip.iocoder.cn/Spring-Boot/ServletWebServerApplicationContext/#) 小节。
+
+## 2.2 refresh
+
+覆写 `#refresh()` 方法，初始化 Spring 容器。代码如下：
+
+```
+// ServletWebServerApplicationContext.java
+
+@Override
+public final void refresh() throws BeansException, IllegalStateException {
+	try {
+		super.refresh();
+	} catch (RuntimeException ex) {
+		// <X> 如果发生异常，停止 WebServer
+		stopAndReleaseWebServer();
+		throw ex;
+	}
+}
+```
+
+- 主要是 `<X>` 处，如果发生异常，则调用 `#stopAndReleaseWebServer()` 方法，停止 WebServer。详细解析，见 [「2.2.1 stopAndReleaseWebServer」](https://svip.iocoder.cn/Spring-Boot/ServletWebServerApplicationContext/#) 。
+
+### 2.2.1 stopAndReleaseWebServer
+
+`#stopAndReleaseWebServer()` 方法，停止 WebServer。代码如下：
+
+```
+// ServletWebServerApplicationContext.java
+    
+private void stopAndReleaseWebServer() {
+    // 获得 WebServer 对象，避免被多线程修改了
+    WebServer webServer = this.webServer;
+    if (webServer != null) {
+        try {
+            // 停止 WebServer 对象
+            webServer.stop();
+            // 置空 webServer
+            this.webServer = null;
+        } catch (Exception ex) {
+            throw new IllegalStateException(ex);
+        }
+    }
+}
+```
+
+## 2.3 postProcessBeanFactory
+
+覆写 `#postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory)` 方法，代码如下：
+
+```
+// ServletWebServerApplicationContext.java
+
+@Override
+protected void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) {
+	// <1.1> 注册 WebApplicationContextServletContextAwareProcessor
+	beanFactory.addBeanPostProcessor(new WebApplicationContextServletContextAwareProcessor(this));
+	// <1.2> 忽略 ServletContextAware 接口。
+	beanFactory.ignoreDependencyInterface(ServletContextAware.class);
+
+	// <2> 注册 ExistingWebApplicationScopes
+	registerWebApplicationScopes();
+}
+```
+
+- `<1.1>` 处，注册 WebApplicationContextServletContextAwareProcessor 。WebApplicationContextServletContextAwareProcessor 的作用，主要是处理实现 ServletContextAware 接口的 Bean 。在这个处理类，初始化这个 Bean 中的 ServletContext 属性，这样在实现 ServletContextAware 接口的 Bean 中就可以拿到 ServletContext 对象了，Spring 中 Aware 接口就是这样实现的。代码如下：
+
+  ```
+  // WebApplicationContextServletContextAwareProcessor.java
+  
+  public class WebApplicationContextServletContextAwareProcessor extends ServletContextAwareProcessor {
+  
+  	private final ConfigurableWebApplicationContext webApplicationContext;
+  
+  	public WebApplicationContextServletContextAwareProcessor(ConfigurableWebApplicationContext webApplicationContext) {
+  		Assert.notNull(webApplicationContext, "WebApplicationContext must not be null");
+  		this.webApplicationContext = webApplicationContext;
+  	}
+  
+  	@Override
+  	protected ServletContext getServletContext() {
+  		ServletContext servletContext = this.webApplicationContext.getServletContext();
+  		return (servletContext != null) ? servletContext : super.getServletContext();
+  	}
+  
+  	@Override
+  	protected ServletConfig getServletConfig() {
+  		ServletConfig servletConfig = this.webApplicationContext.getServletConfig();
+  		return (servletConfig != null) ? servletConfig : super.getServletConfig();
+  	}
+  
+  }
+  ```
+
+  - 这样，就可以从 `webApplicationContext` 中，获得 ServletContext 和 ServletConfig 属性。
+
+- `<1.2>` 处，忽略 ServletContextAware 接口，因为实现 ServletContextAware 接口的 Bean 在 `<1.1>` 中的 WebApplicationContextServletContextAwareProcessor 中已经处理了。
+
+- 关于 `<1.1>` 和 `<1.2>` 处的说明，参考 [《Spring Boot 源码3 —— refresh ApplicationContext》](https://www.jianshu.com/p/58974c12cd6a) 文章。
+
+  > 艿艿：当读源码碰到困难时，也要善用搜索引擎，去寻找答案。😈 毕竟，有时候脑子不一定能快速想的明白。哈哈哈哈~
+
+- `<2>` 处，调用 `#registerWebApplicationScopes()` 方法，注册 ExistingWebApplicationScopes 。代码如下：
+
+  ```
+  // ServletWebServerApplicationContext.java
+  
+  private void registerWebApplicationScopes() {
+      // 创建 ExistingWebApplicationScopes 对象
+      ExistingWebApplicationScopes existingScopes = new ExistingWebApplicationScopes(getBeanFactory());
+      // 注册 ExistingWebApplicationScopes 到 WebApplicationContext 中
+      WebApplicationContextUtils.registerWebApplicationScopes(getBeanFactory());
+      // 恢复
+      existingScopes.restore();
+  }
+  ```
+
+  - 可以先不细研究~
+
+## 2.4 onRefresh
+
+覆写 `#onRefresh()` 方法，在容器初始化时，完成 WebServer 的创建（不包括启动）。代码如下：
+
+```
+// ServletWebServerApplicationContext.java
+
+@Override
+protected void onRefresh() {
+    // <1> 调用父方法
+    super.onRefresh();
+    try {
+        // 创建 WebServer
+        createWebServer();
+    } catch (Throwable ex) {
+        throw new ApplicationContextException("Unable to start web server", ex);
+    }
+}
+```
+
+- `<1>` 处，调用父 `#onRefresh()` 方法，执行父逻辑。这块，暂时不用了解。
+- `<2>` 处，调用 `#createWebServer()` 方法，创建 WebServer 对象。详细解析，见 [「2.4.1 createWebServer」](https://svip.iocoder.cn/Spring-Boot/ServletWebServerApplicationContext/#) 。
+
+### 2.4.1 createWebServer
+
+`#createWebServer()` 方法，创建 WebServer 对象。
+
+```
+// ServletWebServerApplicationContext.java
+    
+private void createWebServer() {
+    WebServer webServer = this.webServer;
+    ServletContext servletContext = getServletContext();
+    // <1> 如果 webServer 为空，说明未初始化
+    if (webServer == null && servletContext == null) {
+        // <1.1> 获得 ServletWebServerFactory 对象
+        ServletWebServerFactory factory = getWebServerFactory();
+        // <1.2> 获得 ServletContextInitializer 对象
+        // <1.3> 创建（获得） WebServer 对象
+        this.webServer = factory.getWebServer(getSelfInitializer());
+    // TODO 1002 芋艿这个情况是？
+    } else if (servletContext != null) {
+        try {
+            getSelfInitializer().onStartup(servletContext);
+        } catch (ServletException ex) {
+            throw new ApplicationContextException("Cannot initialize servlet context", ex);
+        }
+    }
+    // <3> 初始化 PropertySource
+    initPropertySources();
+}
+```
+
+- `<1>` 处，如果 webServer 为空，说明未初始化。
+
+  - `<1.1>` 处，调用 `#getWebServerFactory()` 方法，获得 ServletWebServerFactory 对象。代码如下：
+
+    ```
+    // ServletWebServerApplicationContext.java
+    
+    protected ServletWebServerFactory getWebServerFactory() {
+        // Use bean names so that we don't consider the hierarchy
+        // 获得 ServletWebServerFactory 类型对应的 Bean 的名字们
+        String[] beanNames = getBeanFactory().getBeanNamesForType(ServletWebServerFactory.class);
+        // 如果是 0 个，抛出 ApplicationContextException 异常，因为至少要一个
+        if (beanNames.length == 0) {
+            throw new ApplicationContextException("Unable to start ServletWebServerApplicationContext due to missing " + "ServletWebServerFactory bean.");
+        }
+        // 如果是 > 1 个，抛出 ApplicationContextException 异常，因为不知道初始化哪个
+        if (beanNames.length > 1) {
+            throw new ApplicationContextException("Unable to start ServletWebServerApplicationContext due to multiple " + "ServletWebServerFactory beans : " + StringUtils.arrayToCommaDelimitedString(beanNames));
+        }
+        // 获得 ServletWebServerFactory 类型对应的 Bean 对象
+        return getBeanFactory().getBean(beanNames[0], ServletWebServerFactory.class);
+    }
+    ```
+
+    - 默认情况下，此处返回的会是 `org.springframework.boot.web.embedded.tomcat.TomcatServletWebServerFactory` 对象。
+    - 在我们引入 `spring-boot-starter-web` 依赖时，默认会引入 `spring-boot-starter-tomcat` 依赖。此时，`org.springframework.boot.autoconfigure.web.servlet.ServletWebServerFactoryConfiguration` 在自动配置时，会配置出 TomcatServletWebServerFactory Bean 对象。因此，此时会获得 TomcatServletWebServerFactory 对象。
+
+  - `<1.2>` 处，调用 `#getSelfInitializer()` 方法，获得 ServletContextInitializer 对象。代码如下：
+
+    ```
+    // ServletWebServerApplicationContext.java
+    
+    private org.springframework.boot.web.servlet.ServletContextInitializer getSelfInitializer() {
+    	return this::selfInitialize; // 和下面等价
+    //        return new ServletContextInitializer() {
+    //
+    //            @Override
+    //            public void onStartup(ServletContext servletContext) throws ServletException {
+    //                selfInitialize(servletContext);
+    //            }
+    //
+    //        };
+    }
+    ```
+
+    - 嘻嘻，返回的是 ServletContextInitializer 匿名对象，内部会调用 `#selfInitialize(servletContext)` 方法。该方法会在 WebServer 创建后，进行初始化。详细解析，见 [「2.4.2 finishRefresh」](https://svip.iocoder.cn/Spring-Boot/ServletWebServerApplicationContext/#) 小节。
+
+  - `<1.3>` 处，调用 `ServletWebServerFactory#getWebServer(ServletContextInitializer)` 方法，创建（获得） WebServer 对象。在这个过程中，会调用 [「2.4.2 selfInitialize」](https://svip.iocoder.cn/Spring-Boot/ServletWebServerApplicationContext/#) 方法。
+
+- 至此，和 [《精尽 Spring MVC 源码分析 —— 容器的初始化（四）之 Spring Boot 集成》](http://svip.iocoder.cn/Spring-MVC/context-init-integration-with-SpringBoot) 文章，基本是能穿起来了。
+
+- `<2>` 处，TODO 1002 不知道原因。有知道的胖友，星球里告知下哟。
+
+- `<3>` 处，调用父 `#initPropertySources()` 方法，初始化 PropertySource 。
+
+### 2.4.2 selfInitialize
+
+`#selfInitialize()` 方法，初始化 WebServer 。代码如下：
+
+```
+// ServletWebServerApplicationContext.java
+
+private void selfInitialize(ServletContext servletContext) throws ServletException {
+    // <1> 添加 Spring 容器到 servletContext 属性中。
+    prepareWebApplicationContext(servletContext);
+    // <2> 注册 ServletContextScope
+    registerApplicationScope(servletContext);
+    // <3> 注册 web-specific environment beans ("contextParameters", "contextAttributes")
+    WebApplicationContextUtils.registerEnvironmentBeans(getBeanFactory(), servletContext);
+    // <4> 获得所有 ServletContextInitializer ，并逐个进行启动
+    for (ServletContextInitializer beans : getServletContextInitializerBeans()) {
+        beans.onStartup(servletContext);
+    }
+}
+```
+
+- `<1>` 处，调用 `#prepareWebApplicationContext(ServletContext servletContext)` 方法，添加 Spring 容器到 servletContext 属性中。代码如下：
+
+  ```
+  // ServletWebServerApplicationContext.java
+  
+  protected void prepareWebApplicationContext(ServletContext servletContext) {
+      // 如果已经在 ServletContext 中，则根据情况进行判断。
+      Object rootContext = servletContext.getAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE);
+      if (rootContext != null) {
+          // 如果是相同容器，抛出 IllegalStateException 异常。说明可能有重复的 ServletContextInitializers 。
+          if (rootContext == this) {
+              throw new IllegalStateException("Cannot initialize context because there is already a root application context present - " + "check whether you have multiple ServletContextInitializers!");
+          }
+          // 如果不同容器，则直接返回。
+          return;
+      }
+      Log logger = LogFactory.getLog(ContextLoader.class);
+      servletContext.log("Initializing Spring embedded WebApplicationContext");
+      try {
+          // <X> 设置当前 Spring 容器到 ServletContext 中
+          servletContext.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE, this);
+          // 打印日志
+          if (logger.isDebugEnabled()) {
+              logger.debug("Published root WebApplicationContext as ServletContext attribute with name [" + WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE + "]");
+          }
+          // <Y> 设置到 `servletContext` 属性中。
+          setServletContext(servletContext);
+          // 打印日志
+          if (logger.isInfoEnabled()) {
+              long elapsedTime = System.currentTimeMillis() - getStartupDate();
+              logger.info("Root WebApplicationContext: initialization completed in " + elapsedTime + " ms");
+          }
+      } catch (RuntimeException | Error ex) {
+          logger.error("Context initialization failed", ex);
+          servletContext.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE, ex);
+          throw ex;
+      }
+  }
+  ```
+
+  - 虽然代码非常长，但是核心在 `<X>` 和 `<Y>` 处。
+  - 通过 `<X>` 处，从 `servletContext` 的属性种，可以拿到其拥有的 Spring 容器。
+  - 通过 `<Y>` 处，Spring 容器的 `servletContext` 属性，可以拿到 ServletContext 对象。
+
+- `<2>` 处，调用 `#registerApplicationScope(ServletContext servletContext)` 方法，注册 ServletContextScope 。代码如下：
+
+  ```
+  // ServletWebServerApplicationContext.java
+  
+  private void registerApplicationScope(ServletContext servletContext) {
+  	ServletContextScope appScope = new ServletContextScope(servletContext);
+  	getBeanFactory().registerScope(WebApplicationContext.SCOPE_APPLICATION, appScope);
+  	// Register as ServletContext attribute, for ContextCleanupListener to detect it.
+  	servletContext.setAttribute(ServletContextScope.class.getName(), appScope);
+  }
+  ```
+
+  - 不用细了解。
+
+- `<3>` 处，调用 `WebApplicationContextUtils#registerEnvironmentBeans(ConfigurableListableBeanFactory bf, ServletContext sc)` 方法，注册 web-specific environment beans `("contextParameters", "contextAttributes")` 。这样，从 BeanFactory 中，也可以获得到 `servletContext` 。当然，也可以暂时不用细了解。
+
+- `<4>` 处，获得所有 ServletContextInitializer ，并逐个进行启动。关于这块的解析，我们在 [《精尽 Spring MVC 源码分析 —— 容器的初始化（四）之 Spring Boot 集成》](http://svip.iocoder.cn/Spring-MVC/context-init-integration-with-SpringBoot) 中，已经详细写到。😈
+
+- 至此，内嵌的 Servlet Web 服务器，已经能够被请求了。
+
+## 2.5 finishRefresh
+
+覆写 `#finishRefresh()` 方法，在容器初始化完成时，启动 WebServer 。代码如下：
+
+```
+// ServletWebServerApplicationContext.java
+
+@Override
+protected void finishRefresh() {
+    // <1> 调用父方法
+    super.finishRefresh();
+    // <2> 启动 WebServer
+    WebServer webServer = startWebServer();
+    // <3> 如果创建 WebServer 成功，发布 ServletWebServerInitializedEvent 事件
+    if (webServer != null) {
+        publishEvent(new ServletWebServerInitializedEvent(webServer, this));
+    }
+}
+```
+
+- `<1>` 处，调用 `#finishRefresh()` 方法，执行父逻辑。这块，暂时不用了解。
+- `<2>` 处，调用 `#startWebServer()` 方法，启动 WebServer 。详细解析，见 [「2.5.1 startWebServer」](https://svip.iocoder.cn/Spring-Boot/ServletWebServerApplicationContext/#) 。
+- `<3>` 处，如果创建 WebServer 成功，发布 ServletWebServerInitializedEvent 事件。
+
+### 2.5.1 startWebServer
+
+`#startWebServer()` 方法，启动 WebServer 。代码如下：
+
+```
+// ServletWebServerApplicationContext.java
+
+private WebServer startWebServer() {
+	WebServer webServer = this.webServer;
+	if (webServer != null) {
+		webServer.start();
+	}
+	return webServer;
+}
+```
+
+## 2.6 onClose
+
+覆写 `#onClose()` 方法，在 Spring 容器被关闭时，关闭 WebServer 。代码如下：
+
+```
+// ServletWebServerApplicationContext.java
+
+@Override
+protected void onClose() {
+    // 调用父方法
+    super.onClose();
+    // 停止 WebServer
+    stopAndReleaseWebServer();
+}
+```
+
+# 3. AnnotationConfigServletWebServerApplicationContext
+
+`org.springframework.boot.web.servlet.context.AnnotationConfigServletWebServerApplicationContext` ，继承 ServletWebServerApplicationContext 类，实现 AnnotationConfigRegistry 接口，进一步提供了两个功能：
+
+> 艿艿：不过一般情况下，我们用不到这两个功能。简单看了下，更多的是单元测试，需要使用到这两个功能。
+
+- 从指定的 `basePackages` 包中，扫描 BeanDefinition 们。
+- 从指定的 `annotatedClasses` 注解的配置类（Configuration）中，读取 BeanDefinition 们。
+
+> 所以啊，这类，简单看看就成啦。
+
+## 3.1 构造方法
+
+```
+// AnnotationConfigServletWebServerApplicationContext.java
+
+private final AnnotatedBeanDefinitionReader reader;
+
+private final ClassPathBeanDefinitionScanner scanner;
+
+/**
+ * 需要被 {@link #reader} 读取的注册类们
+ */
+private final Set<Class<?>> annotatedClasses = new LinkedHashSet<>();
+
+/**
+ * 需要被 {@link #scanner} 扫描的包
+ */
+private String[] basePackages;
+
+public AnnotationConfigServletWebServerApplicationContext() {
+    this.reader = new AnnotatedBeanDefinitionReader(this);
+    this.scanner = new ClassPathBeanDefinitionScanner(this);
+}
+
+public AnnotationConfigServletWebServerApplicationContext(DefaultListableBeanFactory beanFactory) {
+    super(beanFactory);
+    this.reader = new AnnotatedBeanDefinitionReader(this);
+    this.scanner = new ClassPathBeanDefinitionScanner(this);
+}
+
+public AnnotationConfigServletWebServerApplicationContext(Class<?>... annotatedClasses) {
+    this();
+    // <1> 注册指定的注解的类们
+    register(annotatedClasses);
+    // 初始化 Spring 容器
+    refresh();
+}
+
+public AnnotationConfigServletWebServerApplicationContext(String... basePackages) {
+    this();
+    // <2> 扫描指定包
+    scan(basePackages);
+    // 初始化 Spring 容器
+    refresh();
+}
+```
+
+- ```
+  <1>
+  ```
+
+   
+
+  处，如果已经传入
+
+   
+
+  ```
+  annotatedClasses
+  ```
+
+   
+
+  参数，则调用
+
+   
+
+  ```
+  #register(Class<?>... annotatedClasses)
+  ```
+
+   
+
+  方法，设置到
+
+   
+
+  ```
+  annotatedClasses
+  ```
+
+   
+
+  中。然后，调用
+
+   
+
+  ```
+  #refresh()
+  ```
+
+   
+
+  方法，初始化 Spring 容器。代码如下：
+
+  ```
+  // AnnotationConfigServletWebServerApplicationContext.java
+  
+  @Override // 实现自 AnnotationConfigRegistry 接口
+  public final void register(Class<?>... annotatedClasses) {
+  	Assert.notEmpty(annotatedClasses, "At least one annotated class must be specified");
+  	this.annotatedClasses.addAll(Arrays.asList(annotatedClasses));
+  }
+  ```
+
+- ```
+  <2>
+  ```
+
+   
+
+  处，如果已经传入
+
+   
+
+  ```
+  basePackages
+  ```
+
+   
+
+  参数，则调用
+
+   
+
+  ```
+  #scan(String... basePackages)
+  ```
+
+   
+
+  方法，设置到
+
+   
+
+  ```
+  annotatedClasses
+  ```
+
+   
+
+  中。然后，调用
+
+   
+
+  ```
+  #refresh()
+  ```
+
+   
+
+  方法，初始化 Spring 容器。代码如下：
+
+  ```
+  // AnnotationConfigServletWebServerApplicationContext.java
+  
+  @Override
+  public final void scan(String... basePackages) {
+  	Assert.notEmpty(basePackages, "At least one base package must be specified");
+  	this.basePackages = basePackages;
+  }
+  ```
+
+## 3.2 prepareRefresh
+
+覆写 `#prepareRefresh()` 方法，代码如下：
+
+```
+// AnnotationConfigServletWebServerApplicationContext.java
+
+@Override // 实现自 AbstractApplicationContext 抽象类
+protected void prepareRefresh() {
+    // 清空 scanner 的缓存
+    this.scanner.clearCache();
+    // 调用父类
+    super.prepareRefresh();
+}
+```
+
+- 在 Spring 容器初始化前，需要清空 `scanner` 的缓存。
+
+## 3.3 postProcessBeanFactory
+
+覆写 `#postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory)` 方法，执行 BeanDefinition 的读取。代码如下：
+
+```
+// AnnotationConfigServletWebServerApplicationContext.java
+
+@Override
+protected void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) {
+    // 调用父类
+    super.postProcessBeanFactory(beanFactory);
+    // 扫描指定的包
+    if (this.basePackages != null && this.basePackages.length > 0) {
+        this.scanner.scan(this.basePackages);
+    }
+    // 注册指定的注解的类们定的
+    if (!this.annotatedClasses.isEmpty()) {
+        this.reader.register(ClassUtils.toClassArray(this.annotatedClasses));
+    }
+}
+```
+
+- 实际场景下，`this.basePackages` 和 `annotatedClasses` 都是空的。所以呢，哈哈哈哈，AnnotationConfigServletWebServerApplicationContext 基本没啥子用~
+
+# 666. 彩蛋
+
+简单小文一篇~很妥~
+
+参考和推荐如下文章：
+
+- oldflame-Jm
+  - [《Spring boot 源码分析-AnnotationConfigApplicationContext 非 web 环境下的启动容器（2）》](https://blog.csdn.net/jamet/article/details/77417997)
+  - [《Spring boot 源码分析-AnnotationConfigEmbeddedWebApplicationContext 默认 web 环境下的启动容器（3）》](https://blog.csdn.net/jamet/article/details/77428946)
\ No newline at end of file
diff --git a/springboot/11-Spring Boot 源码分析-ReactiveWebServerApplicationContext.assets/01.jpg b/springboot/11-Spring Boot 源码分析-ReactiveWebServerApplicationContext.assets/01.jpg
new file mode 100644
index 0000000..6e267e4
Binary files /dev/null and b/springboot/11-Spring Boot 源码分析-ReactiveWebServerApplicationContext.assets/01.jpg differ
diff --git a/springboot/11-Spring Boot 源码分析-ReactiveWebServerApplicationContext.assets/02.jpg b/springboot/11-Spring Boot 源码分析-ReactiveWebServerApplicationContext.assets/02.jpg
new file mode 100644
index 0000000..b1886f7
Binary files /dev/null and b/springboot/11-Spring Boot 源码分析-ReactiveWebServerApplicationContext.assets/02.jpg differ
diff --git a/springboot/11-Spring Boot 源码分析-ReactiveWebServerApplicationContext.md b/springboot/11-Spring Boot 源码分析-ReactiveWebServerApplicationContext.md
new file mode 100644
index 0000000..2c49abf
--- /dev/null
+++ b/springboot/11-Spring Boot 源码分析-ReactiveWebServerApplicationContext.md	
@@ -0,0 +1,426 @@
+# 精尽 Spring Boot 源码分析 —— ReactiveWebServerApplicationContext
+
+# 1. 概述
+
+本文接 [《精尽 Spring Boot 源码分析 —— ServletWebServerApplicationContext》](http://svip.iocoder.cn/Spring-Boot/ServletWebServerApplicationContext) 一文，我们来分享 ReactiveWebServerApplicationContext 类，它提供 Reactive Web 环境的 Spring 容器。
+
+AnnotationConfigReactiveWebServerApplicationContext 的类图关系如下：[![类图](11-Spring Boot 源码分析-ReactiveWebServerApplicationContext.assets/01.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-01-19/01.jpg)类图
+
+- 相比来说，ReactiveWebServerApplicationContext 比 ServletWebServerApplicationContext 有更多的层级关系。不过没事，我们一点一点来看。
+
+> 艿艿：Spring Webflux ，我自己目前没太使用过。看这块，就单纯好奇下，哈哈哈。
+
+# 2. ReactiveWebApplicationContext
+
+`org.springframework.boot.web.reactive.context.ReactiveWebApplicationContext` ，继承 ApplicationContext 接口，Reactive Web ApplicationContext 接口。代码如下：
+
+```
+// ReactiveWebApplicationContext.java
+
+public interface ReactiveWebApplicationContext extends ApplicationContext {
+}
+```
+
+# 3. ConfigurableReactiveWebApplicationContext
+
+`org.springframework.boot.web.reactive.context.ConfigurableReactiveWebApplicationContext` ，继承 ConfigurableApplicationContext、[「2. ReactiveWebApplicationContext」](https://svip.iocoder.cn/Spring-Boot/ReactiveWebServerApplicationContext/#) 接口，可配置的 ReactiveWebApplicationContext 接口。代码如下：
+
+```
+// ReactiveWebApplicationContext.java
+
+public interface ConfigurableReactiveWebApplicationContext extends ConfigurableApplicationContext, ReactiveWebApplicationContext {
+}
+```
+
+# 4. GenericReactiveWebApplicationContext
+
+`org.springframework.boot.web.reactive.context.GenericReactiveWebApplicationContext` ，实现 [「3. ConfigurableReactiveWebApplicationContext」](https://svip.iocoder.cn/Spring-Boot/ReactiveWebServerApplicationContext/#) 接口，继承 GenericApplicationContext 类，通用的 Reactive Web ApplicationContext 实现类。代码如下：
+
+```
+// GenericReactiveWebApplicationContext.java
+
+public class GenericReactiveWebApplicationContext extends GenericApplicationContext
+        implements ConfigurableReactiveWebApplicationContext {
+
+    public GenericReactiveWebApplicationContext() {
+    }
+
+    public GenericReactiveWebApplicationContext(DefaultListableBeanFactory beanFactory) {
+        super(beanFactory);
+    }
+
+    @Override // 覆写 AbstractApplicationContext 方法
+    protected ConfigurableEnvironment createEnvironment() {
+        return new StandardReactiveWebEnvironment(); // <X>
+    }
+
+    @Override // 覆写 AbstractApplicationContext 方法
+    protected Resource getResourceByPath(String path) {
+        // We must be careful not to expose classpath resources
+        return new FilteredReactiveWebContextResource(path); // <Y>
+    }
+
+}
+```
+
+- 重点在 `<X>` 和 `<Y>` 处，覆写了方法，分别返回了 StandardReactiveWebEnvironment 和 FilteredReactiveWebContextResource 对象。不过看了下这两个对象，暂时也没什么特殊的方法。所以，可暂时忽略~
+
+# 5. ReactiveWebServerApplicationContext
+
+> 艿艿：正戏开始~
+
+`org.springframework.boot.web.reactive.context.ReactiveWebServerApplicationContext` ，实现 ConfigurableWebServerApplicationContext 接口，继承 GenericReactiveWebApplicationContext 类，Spring Boot 使用 Reactive Web 服务器的 ApplicationContext 实现类。
+
+## 5.1 构造方法
+
+```
+// ReactiveWebServerApplicationContext.java
+
+/**
+ * ServerManager 对象
+ */
+private volatile ServerManager serverManager;
+/**
+ * 通过 {@link #setServerNamespace(String)} 注入。
+ *
+ * 不过貌似，一直没被注入过，可以暂时先无视
+ */
+private String serverNamespace;
+
+public ReactiveWebServerApplicationContext() {
+}
+
+public ReactiveWebServerApplicationContext(DefaultListableBeanFactory beanFactory) {
+    super(beanFactory);
+}
+```
+
+- `serverManager` 属性，ServerManager 对象。详细解析，见 [「5.2 ServerManager」](https://svip.iocoder.cn/Spring-Boot/ReactiveWebServerApplicationContext/#) 。
+
+## 5.2 ServerManager
+
+ServerManager 是 ReactiveWebServerApplicationContext 的内部静态类，实现 `org.springframework.http.server.reactive.HttpHandler` 接口，内含 Server 的管理器。
+
+### 5.2.1 构造方法
+
+```
+// ReactiveWebServerApplicationContext#ServerManager.java
+
+/**
+ * WebServer 对象
+ */
+private final WebServer server;
+/**
+ * HttpHandler 对象，具体在 {@link #handle(ServerHttpRequest, ServerHttpResponse)} 方法中使用。
+ */
+private volatile HttpHandler handler;
+
+private ServerManager(ReactiveWebServerFactory factory) {
+    this.handler = this::handleUninitialized; // <1> 同下面
+//          this.handler = new HttpHandler() {
+//                @Override
+//                public Mono<Void> handle(ServerHttpRequest request, ServerHttpResponse response) {
+//                    return handleUninitialized(request, response);
+//                }
+//            };
+    this.server = factory.getWebServer(this); // <2>
+}
+
+private Mono<Void> handleUninitialized(ServerHttpRequest request, ServerHttpResponse response) {
+    throw new IllegalStateException("The HttpHandler has not yet been initialized");
+}
+```
+
+- `<1>` 处，创建的 `handler` 对象，内部实现调用了 `#handleUninitialized(ServerHttpRequest request, ServerHttpResponse response)` 方法，会抛出 IllegalStateException 异常。表示，此时该 `server` 还不可用。因为，`server` 都还没启动。😈
+- `<2>` 处，调用 `ReactiveWebServerFactory#getWebServer(HttpHandler handler)` 方法，创建 WebServer 对象。其中，方法参数 `handler` 传递是 `this` 自己，因为后面的请求处理的 `#handle(ServerHttpRequest request, ServerHttpResponse)` 方法，需要调用自己哟。
+
+### 5.2.2 handle
+
+实现 `#handle(ServerHttpRequest request, ServerHttpResponse)` 方法，处理请求。代码如下：
+
+```
+// ReactiveWebServerApplicationContext#ServerManager.java
+
+@Override
+public Mono<Void> handle(ServerHttpRequest request, ServerHttpResponse response) {
+	return this.handler.handle(request, response);
+}
+```
+
+- 委托给 `handler` 属性，对应的方法，处理请求。
+
+### 5.2.3 get
+
+`#get(ReactiveWebServerFactory factory)` **静态**方法，创建一个 ServerManager 对象。代码如下：
+
+```
+// ReactiveWebServerApplicationContext#ServerManager.java
+
+public static ServerManager get(ReactiveWebServerFactory factory) {
+	return new ServerManager(factory);
+}
+```
+
+### 5.2.4 getWebServer
+
+`#getWebServer(ServerManager manager)` **静态**方法，获得 `manager` 的 WebServer 对象。代码如下：
+
+```
+// ReactiveWebServerApplicationContext#ServerManager.java
+
+public static WebServer getWebServer(ServerManager manager) {
+	return (manager != null) ? manager.server : null;
+}
+```
+
+### 5.2.5 start
+
+`#start(ServerManager manager, Supplier<HttpHandler> handlerSupplier)` **静态**方法，启动。代码如下：
+
+```
+// ReactiveWebServerApplicationContext#ServerManager.java
+
+public static void start(ServerManager manager, Supplier<HttpHandler> handlerSupplier) {
+    if (manager != null && manager.server != null) {
+        // <1> 赋值 handler
+        manager.handler = handlerSupplier.get();
+        // <2> 启动 server
+        manager.server.start();
+    }
+}
+```
+
+- `<1>` 处，将 `handlerSupplier` 赋值给 `manager.handler` 。
+- `<2>` 处，调用 `WebServer#start()` 方法，启动 Server 。
+
+### 5.2.6 stop
+
+`#stop(ServerManager manager)` **静态**方法，停止。代码如下：
+
+```
+// ReactiveWebServerApplicationContext#ServerManager.java
+
+public static void stop(ServerManager manager) {
+	if (manager != null && manager.server != null) {
+		try {
+			manager.server.stop();
+		} catch (Exception ex) {
+			throw new IllegalStateException(ex);
+		}
+	}
+}
+```
+
+- 调用 `ServerManager#stop()` 方法，停止 Server 。
+
+> 😈 到此时，可能胖友有点懵逼。没事，我们下面看看 ReactiveWebServerApplicationContext 怎么使用它。
+
+## 5.3 refresh
+
+覆写 `#refresh()` 方法，初始化 Spring 容器。代码如下：
+
+```
+// ReactiveWebServerApplicationContext.java
+
+@Override
+public final void refresh() throws BeansException, IllegalStateException {
+    try {
+        // 调用父方法
+        super.refresh();
+    } catch (RuntimeException ex) {
+        // <X> 停止 Reactive WebServer
+        stopAndReleaseReactiveWebServer();
+        throw ex;
+    }
+}
+```
+
+- 主要是 `<X>` 处，如果发生异常，则调用 `#stopAndReleaseWebServer()` 方法，停止 WebServer。详细解析，见 [「5.3.1 stopAndReleaseWebServer」](https://svip.iocoder.cn/Spring-Boot/ReactiveWebServerApplicationContext/#) 。
+
+### 5.3.1 stopAndReleaseWebServer
+
+`#stopAndReleaseWebServer()` 方法，停止 WebServer。代码如下：
+
+```
+// ReactiveWebServerApplicationContext.java
+
+private void stopAndReleaseReactiveWebServer() {
+	ServerManager serverManager = this.serverManager;
+	try {
+		ServerManager.stop(serverManager); // <Y>
+	} finally {
+		this.serverManager = null;
+	}
+}
+```
+
+- `<Y>` 处，调用 `ServerManager#stop(serverManager)` 方法，停止 WebServer 。
+
+## 5.4 onRefresh
+
+覆写 `#onRefresh()` 方法，在容器初始化时，完成 WebServer 的创建（不包括启动）。代码如下：
+
+```
+// ReactiveWebServerApplicationContext.java
+
+@Override
+protected void onRefresh() {
+    // <1> 调用父方法
+    super.onRefresh();
+    try {
+        // <2> 创建 WebServer
+        createWebServer();
+    } catch (Throwable ex) {
+        throw new ApplicationContextException("Unable to start reactive web server", ex);
+    }
+}
+```
+
+- `<1>` 处，调用父 `#onRefresh()` 方法，执行父逻辑。这块，暂时不用了解。
+- `<2>` 处，调用 `#createWebServer()` 方法，创建 WebServer 对象。详细解析，见 [「5.4.1 createWebServer」](https://svip.iocoder.cn/Spring-Boot/ReactiveWebServerApplicationContext/#) 。
+
+### 5.4.1 createWebServer
+
+`#createWebServer()` 方法，创建 WebServer 对象。代码如下：
+
+```
+// ReactiveWebServerApplicationContext.java
+
+private void createWebServer() {
+	// 获得 ServerManager 对象。
+	ServerManager serverManager = this.serverManager;
+	// 如果不存在，则进行初始化
+	if (serverManager == null) {
+		this.serverManager = ServerManager.get(getWebServerFactory()); // <1>
+	}
+	// <2> 初始化 PropertySource
+	initPropertySources();
+}
+```
+
+- `<1>` 处，调用 `#getWebServerFactory()` 方法，获得 ReactiveWebServerFactory 对象。代码如下：
+
+  ```
+  // ReactiveWebServerApplicationContext.java
+  
+  protected ReactiveWebServerFactory getWebServerFactory() {
+      // Use bean names so that we don't consider the hierarchy
+      // 获得 ServletWebServerFactory 类型对应的 Bean 的名字们
+      String[] beanNames = getBeanFactory().getBeanNamesForType(ReactiveWebServerFactory.class);
+      // 如果是 0 个，抛出 ApplicationContextException 异常，因为至少要一个
+      if (beanNames.length == 0) {
+          throw new ApplicationContextException("Unable to start ReactiveWebApplicationContext due to missing " + "ReactiveWebServerFactory bean.");
+      }
+      // 如果是 > 1 个，抛出 ApplicationContextException 异常，因为不知道初始化哪个
+      if (beanNames.length > 1) {
+          throw new ApplicationContextException("Unable to start ReactiveWebApplicationContext due to multiple "
+                          + "ReactiveWebServerFactory beans : " + StringUtils.arrayToCommaDelimitedString(beanNames));
+      }
+      // 获得 ReactiveWebServerFactory 类型对应的 Bean 对象
+      return getBeanFactory().getBean(beanNames[0], ReactiveWebServerFactory.class);
+  }
+  ```
+
+  - 默认情况下，此处返回的会是 `org.springframework.boot.web.embedded.netty.NettyReactiveWebServerFactory` 对象。
+  - 在我们引入 `spring-boot-starter-webflux` 依赖时，`org.springframework.boot.autoconfigure.web.reactive.ReactiveWebServerFactoryConfiguration` 在自动配置时，会配置出 NettyReactiveWebServerFactory Bean 对象。因此，此时会获得 NettyReactiveWebServerFactory 对象。
+
+- `<1>` 处，调用 `ServerManager#get(ReactiveWebServerFactory)` **静态**方法，创建 ServerManager 对象。
+
+- `<2>` 处，调用父 `#initPropertySources()` 方法，初始化 PropertySource 。
+
+## 5.5 finishRefresh
+
+覆写 `#finishRefresh()` 方法，在容器初始化完成时，启动 WebServer 。代码如下：
+
+```
+// ReactiveWebServerApplicationContext.java
+
+@Override
+protected void finishRefresh() {
+    // <1> 调用父方法
+    super.finishRefresh();
+    // <2> 启动 WebServer
+    WebServer webServer = startReactiveWebServer();
+    // <3> 如果创建 WebServer 成功，发布 ReactiveWebServerInitializedEvent 事件
+    if (webServer != null) {
+        publishEvent(new ReactiveWebServerInitializedEvent(webServer, this));
+    }
+}
+```
+
+- `<1>` 处，调用 `#finishRefresh()` 方法，执行父逻辑。这块，暂时不用了解。
+- `<2>` 处，调用 `#startReactiveWebServer()` 方法，启动 WebServer 。详细解析，见 [「5.5.1 startReactiveWebServer」](https://svip.iocoder.cn/Spring-Boot/ReactiveWebServerApplicationContext/#) 。
+- `<3>` 处，如果创建 WebServer 成功，发布 ReactiveWebServerInitializedEvent 事件。
+
+### 5.5.1 startReactiveWebServer
+
+`#startReactiveWebServer()` 方法，启动 WebServer 。代码如下：
+
+```
+// ReactiveWebServerApplicationContext.java
+
+private WebServer startReactiveWebServer() {
+    ServerManager serverManager = this.serverManager;
+    // <1> 获得 HttpHandler
+    // <2> 启动 WebServer
+    ServerManager.start(serverManager, this::getHttpHandler);
+    // <3> 获得 WebServer
+    return ServerManager.getWebServer(serverManager);
+}
+```
+
+- `<1>` 处，调用 `#getHttpHandler()` 方法，获得 HttpHandler 对象。代码如下：
+
+  ```
+  // ReactiveWebServerApplicationContext.java
+  
+  protected HttpHandler getHttpHandler() {
+      // Use bean names so that we don't consider the hierarchy
+      // 获得 HttpHandler 类型对应的 Bean 的名字们
+      String[] beanNames = getBeanFactory().getBeanNamesForType(HttpHandler.class);
+      // 如果是 0 个，抛出 ApplicationContextException 异常，因为至少要一个
+      if (beanNames.length == 0) {
+          throw new ApplicationContextException("Unable to start ReactiveWebApplicationContext due to missing HttpHandler bean.");
+      }
+      // 如果是 > 1 个，抛出 ApplicationContextException 异常，因为不知道初始化哪个
+      if (beanNames.length > 1) {
+          throw new ApplicationContextException("Unable to start ReactiveWebApplicationContext due to multiple HttpHandler beans : "
+                          + StringUtils.arrayToCommaDelimitedString(beanNames));
+      }
+      // 获得 HttpHandler 类型对应的 Bean 对象
+      return getBeanFactory().getBean(beanNames[0], HttpHandler.class);
+  }
+  ```
+
+  - 默认情况下，返回的结果，如下图所示：[![示例](11-Spring Boot 源码分析-ReactiveWebServerApplicationContext.assets/02.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-01-19/02.jpg)示例
+  - 该 HttpHandler Bean 对象，是在 `org.springframework.boot.autoconfigure.web.reactive.HttpHandlerAutoConfiguration` 配置类上，被初始化出来。
+
+- `<2>` 处，调用 `ServerManager#start(ServerManager manager, Supplier<HttpHandler> handlerSupplier)` **静态**方法，启动 WebServer 。
+
+- `<3>` 处，调用 `ServerManager#getWebServer(serverManager)` **静态**方法，获得 WebServer 对象。
+
+## 5.6 onClose
+
+覆写 `#onClose()` 方法，在 Spring 容器被关闭时，关闭 WebServer 。代码如下：
+
+```
+// ReactiveWebServerApplicationContext.java
+
+@Override
+protected void onClose() {
+	// 调用父类方法
+	super.onClose();
+	// 关闭 WebServer
+	stopAndReleaseReactiveWebServer();
+}
+```
+
+# 6. AnnotationConfigReactiveWebServerApplicationContext
+
+`org.springframework.boot.web.reactive.context.AnnotationConfigReactiveWebServerApplicationContext` ，继承 ReactiveWebServerApplicationContext 类，实现 AnnotationConfigRegistry 接口，作用和 AnnotationConfigServletWebServerApplicationContext 相同，就不重复赘述了。
+
+如果真要看的胖友，参考 [《精尽 Spring Boot 源码分析 —— ServletWebServerApplicationContext》](http://svip.iocoder.cn/Spring-Boot/ServletWebServerApplicationContext/) 的 [「3. AnnotationConfigServletWebServerApplicationContext」](https://svip.iocoder.cn/Spring-Boot/ReactiveWebServerApplicationContext/#) 即可。
+
+# 666. 彩蛋
+
+水更一篇，无可“狡辩”。嘻嘻。
\ No newline at end of file
diff --git a/springboot/12-Spring Boot 源码分析-ApplicationContextInitializer.assets/01-17199767902571.jpg b/springboot/12-Spring Boot 源码分析-ApplicationContextInitializer.assets/01-17199767902571.jpg
new file mode 100644
index 0000000..3cab22e
Binary files /dev/null and b/springboot/12-Spring Boot 源码分析-ApplicationContextInitializer.assets/01-17199767902571.jpg differ
diff --git a/springboot/12-Spring Boot 源码分析-ApplicationContextInitializer.assets/01.jpg b/springboot/12-Spring Boot 源码分析-ApplicationContextInitializer.assets/01.jpg
new file mode 100644
index 0000000..0807529
Binary files /dev/null and b/springboot/12-Spring Boot 源码分析-ApplicationContextInitializer.assets/01.jpg differ
diff --git a/springboot/12-Spring Boot 源码分析-ApplicationContextInitializer.md b/springboot/12-Spring Boot 源码分析-ApplicationContextInitializer.md
new file mode 100644
index 0000000..bc781f8
--- /dev/null
+++ b/springboot/12-Spring Boot 源码分析-ApplicationContextInitializer.md	
@@ -0,0 +1,789 @@
+# 精尽 Spring Boot 源码分析 —— ApplicationContextInitializer
+
+# 1. 概述
+
+本文，我们来补充 [《精尽 Spring Boot 源码分析 —— SpringApplication》](http://svip.iocoder.cn/Spring-Boot/SpringApplication) 文章，并未详细解析的 ApplicationContextInitializer 。
+
+# 2. ApplicationContextInitializer
+
+`org.springframework.context.ApplicationContextInitializer` ，ApplicationContext 初始化接口。代码如下：
+
+```
+/**
+ * Callback interface for initializing a Spring {@link ConfigurableApplicationContext}
+ * prior to being {@linkplain ConfigurableApplicationContext#refresh() refreshed}.
+ *
+ * <p>Typically used within web applications that require some programmatic initialization
+ * of the application context. For example, registering property sources or activating
+ * profiles against the {@linkplain ConfigurableApplicationContext#getEnvironment()
+ * context's environment}. See {@code ContextLoader} and {@code FrameworkServlet} support
+ * for declaring a "contextInitializerClasses" context-param and init-param, respectively.
+ *
+ * <p>{@code ApplicationContextInitializer} processors are encouraged to detect
+ * whether Spring's {@link org.springframework.core.Ordered Ordered} interface has been
+ * implemented or if the @{@link org.springframework.core.annotation.Order Order}
+ * annotation is present and to sort instances accordingly if so prior to invocation.
+ *
+ * @author Chris Beams
+ * @since 3.1
+ * @param <C> the application context type
+ * @see org.springframework.web.context.ContextLoader#customizeContext
+ * @see org.springframework.web.context.ContextLoader#CONTEXT_INITIALIZER_CLASSES_PARAM
+ * @see org.springframework.web.servlet.FrameworkServlet#setContextInitializerClasses
+ * @see org.springframework.web.servlet.FrameworkServlet#applyInitializers
+ */
+public interface ApplicationContextInitializer<C extends ConfigurableApplicationContext> {
+
+	/**
+	 * Initialize the given application context.
+	 * @param applicationContext the application to configure
+	 */
+	void initialize(C applicationContext);
+
+}
+```
+
+- 1、ApplicationContextInitializer 是 Spring Framework 3.1 版本开始提供的接口。而本文，我们是来分享 Spring Boot 中，几个 ApplicationContextInitializer 实现类。
+- 2、【作用】ApplicationContextInitializer 是一个回调接口，用于 Spring ConfigurableApplicationContext 容器执行 `#refresh()` 方法进行初始化之前，提前走一些自定义的初始化逻辑。
+- 3、【场景】它的使用场景，例如说 Web 应用中需要注册属性，或者激活 Profiles 。
+- 4、【排序】它支持 Spring 的 Ordered 接口、`@Order` 注解，来对多个 ApplicationContextInitializer 实例进行排序，从而实现，ApplicationContextInitializer 按照顺序调用 `#initialize(C applicationContext)` 方法，进行初始化。
+
+# 3. SpringApplication 中的使用
+
+## 3.1 初始化 ApplicationContextInitializer 集合
+
+在 SpringApplication 构造方法中，会调用 `#getSpringFactoriesInstances(Class<T> type)` 方法，获得 ApplicationContextInitializer 集合。代码如下：
+
+```
+// SpringApplication.java
+
+private <T> Collection<T> getSpringFactoriesInstances(Class<T> type) {
+    return getSpringFactoriesInstances(type, new Class<?>[] {});
+}
+
+private <T> Collection<T> getSpringFactoriesInstances(Class<T> type,
+        Class<?>[] parameterTypes, Object... args) {
+    ClassLoader classLoader = getClassLoader();
+    // Use names and ensure unique to protect against duplicates
+    // <1> 加载指定类型对应的，在 `META-INF/spring.factories` 里的类名的数组
+    Set<String> names = new LinkedHashSet<>(SpringFactoriesLoader.loadFactoryNames(type, classLoader));
+    // <2> 创建对象们
+    List<T> instances = createSpringFactoriesInstances(type, parameterTypes, classLoader, args, names);
+    // <3> 排序对象们
+    AnnotationAwareOrderComparator.sort(instances);
+    return instances;
+}
+```
+
+- ```
+  <1>
+  ```
+
+   
+
+  处，加载指定 ApplicationContextInitializer 类型对应的，在
+
+   
+
+  ```
+  META-INF/spring.factories
+  ```
+
+   
+
+  里的类名的数组。
+
+  - 假设只在 Spring MVC 的环境下，`initializers` 属性的结果如下图：[![`initializers` 属性](12-Spring Boot 源码分析-ApplicationContextInitializer.assets/01.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-01-07/01.jpg)`initializers` 属性
+  - 艿艿整理了 Spring Boot 中，ApplicationContextInitializer 的实现类们，如下图所示：[![Spring Boot ApplicationContextInitializer 的实现类](12-Spring Boot 源码分析-ApplicationContextInitializer.assets/01-17199767902571.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-01-22/01.jpg)Spring Boot ApplicationContextInitializer 的实现类
+
+- `<2>` 处，创建对象们。
+
+- `<3>` 处，排序对象们。这个就是在 [「2. ApplicationContextInitializer」](https://svip.iocoder.cn/Spring-Boot/ApplicationContextInitializer/#) 提到的【排序】。
+
+## 3.2 prepareContext
+
+在 `#prepareContext(...)` 方法中，即在 Spring IoC 容器初始化之前，会调用 `#applyInitializers()` 方法，逐个调用 ApplicationContextInitializer 的初始化方法。代码如下：
+
+```
+// SpringApplication.java
+
+protected void applyInitializers(ConfigurableApplicationContext context) {
+    // 遍历 ApplicationContextInitializer 数组
+    for (ApplicationContextInitializer initializer : getInitializers()) {
+        // 校验 ApplicationContextInitializer 的泛型非空
+        Class<?> requiredType = GenericTypeResolver.resolveTypeArgument(initializer.getClass(), ApplicationContextInitializer.class);
+        Assert.isInstanceOf(requiredType, context, "Unable to call initializer.");
+        // 初始化 ApplicationContextInitializer
+        initializer.initialize(context);
+    }
+}
+```
+
+- 比较简单，就是调用 `ApplicationContextInitializer#initialize(context)` 方法，进行初始化。
+
+下面，我们来逐个看看 Spring Boot 对 ApplicationContextInitializer 的实现类们。
+
+# 4. DelegatingApplicationContextInitializer
+
+`org.springframework.boot.context.config.DelegatingApplicationContextInitializer` ，实现 ApplicationContextInitializer、Ordered 接口，根据环境变量配置的 `context.initializer.classes` 配置的 ApplicationContextInitializer 类们，交给它们进行初始化。
+
+## 4.1 构造方法
+
+```
+// DelegatingApplicationContextInitializer.java
+
+/**
+ * 环境变量配置的属性
+ */
+private static final String PROPERTY_NAME = "context.initializer.classes";
+
+/**
+ * 默认优先级
+ */
+private int order = 0;
+
+// ... 构造方法为空
+
+@Override
+public int getOrder() {
+	return this.order;
+}
+```
+
+- 优先级为 0 ，在 Spring Boot 默认的 ApplicationContextInitializer 实现类中，是排在最前面的。
+
+## 4.2 initialize
+
+实现 `#initialize(ConfigurableApplicationContext context)` 方法，代码如下：
+
+```
+// DelegatingApplicationContextInitializer.java
+
+@Override
+public void initialize(ConfigurableApplicationContext context) {
+    // <1> 获得环境变量配置的 ApplicationContextInitializer 集合们
+    ConfigurableEnvironment environment = context.getEnvironment();
+    List<Class<?>> initializerClasses = getInitializerClasses(environment);
+    // 如果非空，则进行初始化
+    if (!initializerClasses.isEmpty()) {
+        applyInitializerClasses(context, initializerClasses);
+    }
+}
+```
+
+- ```
+  <1>
+  ```
+
+   
+
+  处，调用
+
+   
+
+  ```
+  #getInitializerClasses(ConfigurableEnvironment env)
+  ```
+
+   
+
+  方法，获得环境变量配置的 ApplicationContextInitializer 集合们。代码如下：
+
+  ```
+  // DelegatingApplicationContextInitializer.java
+  
+  private List<Class<?>> getInitializerClasses(ConfigurableEnvironment env) {
+      // 获得环境变量配置的属性
+      String classNames = env.getProperty(PROPERTY_NAME);
+      // 拼装成数组，按照 ，分隔
+      List<Class<?>> classes = new ArrayList<>();
+      if (StringUtils.hasLength(classNames)) {
+          for (String className : StringUtils.tokenizeToStringArray(classNames, ",")) {
+              classes.add(getInitializerClass(className));
+          }
+      }
+      return classes;
+  }
+  
+  private Class<?> getInitializerClass(String className) throws LinkageError {
+  	try {
+  		// 获得全类名，对应的类
+  		Class<?> initializerClass = ClassUtils.forName(className, ClassUtils.getDefaultClassLoader());
+  		Assert.isAssignable(ApplicationContextInitializer.class, initializerClass);
+  		return initializerClass;
+  	} catch (ClassNotFoundException ex) {
+  		throw new ApplicationContextException("Failed to load context initializer class [" + className + "]", ex);
+  	}
+  }
+  ```
+
+- `<2>` 处，调用 `#applyInitializerClasses(ConfigurableApplicationContext context, List<Class<?>> initializerClasses)` 方法，执行初始化。代码如下：
+
+  ```
+  // DelegatingApplicationContextInitializer.java
+  
+  private void applyInitializerClasses(ConfigurableApplicationContext context, List<Class<?>> initializerClasses) {
+      Class<?> contextClass = context.getClass();
+      // 遍历 initializerClasses 数组，创建对应的 ApplicationContextInitializer 对象们 ①
+      List<ApplicationContextInitializer<?>> initializers = new ArrayList<>();
+      for (Class<?> initializerClass : initializerClasses) {
+          initializers.add(instantiateInitializer(contextClass, initializerClass));
+      }
+      // 执行 ApplicationContextInitializer 们的初始化逻辑 ②
+      applyInitializers(context, initializers);
+  }
+  
+  // 被 ① 处调用
+  private ApplicationContextInitializer<?> instantiateInitializer(Class<?> contextClass, Class<?> initializerClass) {
+      // 断言校验
+      Class<?> requireContextClass = GenericTypeResolver.resolveTypeArgument(initializerClass, ApplicationContextInitializer.class);
+      Assert.isAssignable(requireContextClass, contextClass, String.format(
+                      "Could not add context initializer [%s]"
+                              + " as its generic parameter [%s] is not assignable "
+                              + "from the type of application context used by this "
+                              + "context loader [%s]: ",
+                      initializerClass.getName(), requireContextClass.getName(), contextClass.getName()));
+      // 创建 ApplicationContextInitializer 对象
+      return (ApplicationContextInitializer<?>) BeanUtils.instantiateClass(initializerClass);
+  }
+  
+  // 被 ② 处调用
+  @SuppressWarnings({ "unchecked", "rawtypes" })
+  private void applyInitializers(ConfigurableApplicationContext context, List<ApplicationContextInitializer<?>> initializers) {
+      // 排序，无处不在的排序！
+      initializers.sort(new AnnotationAwareOrderComparator());
+      // 执行初始化逻辑
+      for (ApplicationContextInitializer initializer : initializers) {
+          initializer.initialize(context);
+      }
+  }
+  ```
+
+  - 虽然代码有点长，但是简单的。
+
+# 5. SharedMetadataReaderFactoryContextInitializer
+
+`org.springframework.boot.autoconfigure.SharedMetadataReaderFactoryContextInitializer` ，实现 ApplicationContextInitializer、Ordered 接口，它会创建一个用于在 ConfigurationClassPostProcessor 和 Spring Boot 间共享的 CachingMetadataReaderFactory Bean 对象。
+
+简化代码如下：
+
+```
+/**
+ * {@link ApplicationContextInitializer} to create a shared
+ * {@link CachingMetadataReaderFactory} between the
+ * {@link ConfigurationClassPostProcessor} and Spring Boot.
+ *
+ * @author Phillip Webb
+ * @since 1.4.0
+ */
+ 
+/**
+ * 创建的 CachingMetadataReaderFactory 的 Bean 名字
+ */
+public static final String BEAN_NAME = "org.springframework.boot.autoconfigure."
+        + "internalCachingMetadataReaderFactory";
+
+@Override
+public void initialize(ConfigurableApplicationContext applicationContext) {
+    applicationContext.addBeanFactoryPostProcessor(new CachingMetadataReaderFactoryPostProcessor());
+}
+
+@Override
+public int getOrder() {
+    return 0;
+}
+
+// ... 省略 CachingMetadataReaderFactoryPostProcessor 内部类
+```
+
+- 看不懂这个类的具体用途，暂时先不去深究。😈 等真的需要它时，咱们在细细的撸它。
+
+# 6. ContextIdApplicationContextInitializer
+
+`org.springframework.boot.context.ContextIdApplicationContextInitializer` ，实现 ApplicationContextInitializer、Ordered 接口，负责生成 Spring 容器的编号。
+
+## 6.1 构造方法
+
+```
+// ContextIdApplicationContextInitializer.java
+
+/**
+ * 优先级
+ */
+private int order = Ordered.LOWEST_PRECEDENCE - 10;
+
+@Override
+public int getOrder() {
+	return this.order;
+}
+```
+
+## 6.2 initialize
+
+实现 `#initialize(ConfigurableApplicationContext context)` 方法，代码如下：
+
+```
+// ContextIdApplicationContextInitializer.java
+
+@Override
+public void initialize(ConfigurableApplicationContext applicationContext) {
+    // <1> 获得（创建） ContextId 对象
+    ContextId contextId = getContextId(applicationContext);
+    // <2> 设置到 applicationContext 中
+    applicationContext.setId(contextId.getId());
+    // <3> 注册到 contextId 到 Spring 容器中
+    applicationContext.getBeanFactory().registerSingleton(ContextId.class.getName(), contextId);
+}
+```
+
+- ContextId ，是 ContextIdApplicationContextInitializer 的内部类，Spring 容器编号的封装。代码如下：
+
+  ```
+  // ContextIdApplicationContextInitializer#ContextId.java
+  
+  class ContextId {
+  
+      /**
+       * 递增序列
+       */
+  	private final AtomicLong children = new AtomicLong(0);
+  
+      /**
+       * 编号
+       */
+  	private final String id;
+  
+  	ContextId(String id) {
+  		this.id = id;
+  	}
+  
+      /**
+       * @return 创建子 Context 的编号
+       */
+  	ContextId createChildId() {
+  		return new ContextId(this.id + "-" + this.children.incrementAndGet());
+  	}
+  
+  	String getId() {
+  		return this.id;
+  	}
+  
+  }
+  ```
+
+- `<1>` 处，调用 `#getContextId(ConfigurableApplicationContext applicationContext)` 方法，获得（创建） ContextId 对象。代码如下：
+
+  ```
+  // ContextIdApplicationContextInitializer.java
+  
+  private ContextId getContextId(ConfigurableApplicationContext applicationContext) {
+      // 获得父 ApplicationContext 对象
+      ApplicationContext parent = applicationContext.getParent();
+      // 情况一，如果父 ApplicationContext 存在，且有对应的 ContextId 对象，则使用它生成当前容器的 ContextId 对象
+      if (parent != null && parent.containsBean(ContextId.class.getName())) {
+          return parent.getBean(ContextId.class).createChildId();
+      }
+      // 情况二，创建 ContextId 对象
+      return new ContextId(getApplicationId(applicationContext.getEnvironment()));
+  }
+  
+  private String getApplicationId(ConfigurableEnvironment environment) {
+      String name = environment.getProperty("spring.application.name");
+      return StringUtils.hasText(name) ? name : "application";
+  }
+  ```
+
+  - 一般情况下，使用 `"spring.application.name"` 环境变量，作为 ContextId 对象的 `id` 属性。
+
+- `<2>` 处，设置到 `applicationContext.id` 中。
+
+- `<3>` 处，注册到 `contextId` 到 Spring 容器中。这样，后续就可以拿到了。
+
+# 7. ConfigurationWarningsApplicationContextInitializer
+
+> 艿艿：对于这个类，选择性了解即可。
+
+`org.springframework.boot.context.ConfigurationWarningsApplicationContextInitializer` ，实现 ApplicationContextInitializer 接口，用于检查配置，报告错误的配置。如下是其类上的注释：
+
+```
+/**
+ * {@link ApplicationContextInitializer} to report warnings for common misconfiguration mistakes.
+ */
+```
+
+## 7.1 initialize
+
+实现 `#initialize(ConfigurableApplicationContext applicationContext)` 方法，代码如下：
+
+```
+// ConfigurationWarningsApplicationContextInitializer.java
+
+@Override
+public void initialize(ConfigurableApplicationContext context) {
+	// 注册 ConfigurationWarningsPostProcessor 到 Spring 容器中
+	context.addBeanFactoryPostProcessor(new ConfigurationWarningsPostProcessor(getChecks()));
+}
+```
+
+- 注册 ConfigurationWarningsPostProcessor 到 Spring 容器中。关于 ConfigurationWarningsPostProcessor 类，在 [「7.2 ConfigurationWarningsPostProcessor」](https://svip.iocoder.cn/Spring-Boot/ApplicationContextInitializer/#) 中，详细解析。
+
+- 其中，`#getChecks()` 方法，返回 Check 数组。代码如下：
+
+  ```
+  // ConfigurationWarningsApplicationContextInitializer.java
+  
+  protected Check[] getChecks() {
+  	return new Check[] { new ComponentScanPackageCheck() };
+  }
+  ```
+
+  - 返回的数组，只有一个 ComponentScanPackageCheck 对象。
+
+- Check ，是 ConfigurationWarningsApplicationContextInitializer 的内部接口，校验器。代码如下：
+
+  ```
+  // ConfigurationWarningsApplicationContextInitializer.java
+  
+  @FunctionalInterface
+  protected interface Check {
+  
+  	/**
+  	 * Returns a warning if the check fails or {@code null} if there are no problems.
+  	 * @param registry the {@link BeanDefinitionRegistry}
+  	 * @return a warning message or {@code null}
+  	 */
+  	String getWarning(BeanDefinitionRegistry registry);
+  
+  }
+  ```
+
+- 看到此处，胖友可能有点懵逼，不着急。在 [「7.2 ConfigurationWarningsPostProcessor」](https://svip.iocoder.cn/Spring-Boot/ApplicationContextInitializer/#) 中，会串起来滴。
+
+## 7.2 ConfigurationWarningsPostProcessor
+
+ConfigurationWarningsPostProcessor ，是 ConfigurationWarningsApplicationContextInitializer 的内部静态类，实现 PriorityOrdered、BeanDefinitionRegistryPostProcessor 接口，代码如下：
+
+```
+// ConfigurationWarningsPostProcessor#ConfigurationWarningsPostProcessor.java
+
+protected static final class ConfigurationWarningsPostProcessor
+        implements PriorityOrdered, BeanDefinitionRegistryPostProcessor {
+
+    /**
+     * Check 数组
+     */
+    private Check[] checks;
+
+    public ConfigurationWarningsPostProcessor(Check[] checks) {
+        this.checks = checks;
+    }
+
+    @Override
+    public int getOrder() {
+        return Ordered.LOWEST_PRECEDENCE - 1;
+    }
+
+    @Override
+    public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {}
+
+    @Override
+    public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) throws BeansException {
+        // 遍历 Check 数组，执行校验。若有错，则打印 warn 日志
+        for (Check check : this.checks) {
+            String message = check.getWarning(registry);
+            if (StringUtils.hasLength(message)) {
+                warn(message);
+            }
+        }
+
+    }
+
+    private void warn(String message) {
+        if (logger.isWarnEnabled()) {
+            logger.warn(String.format("%n%n** WARNING ** : %s%n%n", message));
+        }
+    }
+
+}
+```
+
+- 核心就是 `#postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry)` 方法。在其内部，遍历 Check 数组，执行校验。若有错，则打印 warn 日志。在上文中，我们看到目前 `checks` 只有一个 ComponentScanPackageCheck 元素。关于它，我们在 [「7.3 ComponentScanPackageCheck」](https://svip.iocoder.cn/Spring-Boot/ApplicationContextInitializer/#) 详细解析。
+
+## 7.3 ComponentScanPackageCheck
+
+ComponentScanPackageCheck ，实现 Check 接口，检查是否使用了 `@ComponentScan` 注解，扫描了指定扫描的包。
+
+### 7.3.1 构造方法
+
+```
+// ConfigurationWarningsPostProcessor#ComponentScanPackageCheck.java
+
+/**
+ * 有问题的包的集合。
+ *
+ * 即禁止使用 @ComponentScan 注解扫描这个集合中的包
+ */
+private static final Set<String> PROBLEM_PACKAGES;
+
+static {
+    Set<String> packages = new HashSet<>();
+    packages.add("org.springframework");
+    packages.add("org");
+    PROBLEM_PACKAGES = Collections.unmodifiableSet(packages);
+}
+```
+
+- 即禁止扫描 `"org.springframework"` 和 `"org"` 包。因为 `"org.springframework"` 包下，有非常多的 Bean ，这样扫描，会错误的注入很多 Bean 。
+
+### 7.3.2 getWarning
+
+实现 `#getWarning(BeanDefinitionRegistry registry)` 方法，代码如下：
+
+```
+// ConfigurationWarningsPostProcessor#ComponentScanPackageCheck.java
+
+@Override
+public String getWarning(BeanDefinitionRegistry registry) {
+    // <1> 获得要扫描的包
+    Set<String> scannedPackages = getComponentScanningPackages(registry);
+    // <2> 获得要扫描的包中，有问题的包
+    List<String> problematicPackages = getProblematicPackages(scannedPackages);
+    // <3.1> 如果 problematicPackages 为空，说明不存在问题
+    if (problematicPackages.isEmpty()) {
+        return null;
+    }
+    // <3.2> 如果 problematicPackages 非空，说明有问题，返回错误提示
+    return "Your ApplicationContext is unlikely to "
+            + "start due to a @ComponentScan of "
+            + StringUtils.collectionToDelimitedString(problematicPackages, ", ")
+            + ".";
+}
+```
+
+- `<1>` 处，调用 `#getComponentScanningPackages(BeanDefinitionRegistry registry)` 方法，获得要扫描的包。代码如下：
+
+  ```
+  // ConfigurationWarningsPostProcessor#ComponentScanPackageCheck.java
+  
+  protected Set<String> getComponentScanningPackages(BeanDefinitionRegistry registry) {
+      // 扫描的包的集合
+      Set<String> packages = new LinkedHashSet<>();
+      // 获得所有 BeanDefinition 的名字们
+      String[] names = registry.getBeanDefinitionNames();
+      for (String name : names) {
+          // 如果是 AnnotatedBeanDefinition
+          BeanDefinition definition = registry.getBeanDefinition(name);
+          if (definition instanceof AnnotatedBeanDefinition) {
+              AnnotatedBeanDefinition annotatedDefinition = (AnnotatedBeanDefinition) definition;
+              // 如果有 @ComponentScan 注解，则添加到 packages 中
+              addComponentScanningPackages(packages, annotatedDefinition.getMetadata());
+          }
+      }
+      return packages;
+  }
+  
+  private void addComponentScanningPackages(Set<String> packages, AnnotationMetadata metadata) {
+      // 获得 @ComponentScan 注解
+      AnnotationAttributes attributes = AnnotationAttributes.fromMap(metadata.getAnnotationAttributes(ComponentScan.class.getName(), true));
+      // 如果存在，则添加到 packages 中
+      if (attributes != null) {
+          addPackages(packages, attributes.getStringArray("value"));
+          addPackages(packages, attributes.getStringArray("basePackages"));
+          addClasses(packages, attributes.getStringArray("basePackageClasses"));
+          if (packages.isEmpty()) {
+              packages.add(ClassUtils.getPackageName(metadata.getClassName()));
+          }
+      }
+  }
+  
+  private void addPackages(Set<String> packages, String[] values) {
+      if (values != null) {
+          Collections.addAll(packages, values);
+      }
+  }
+  
+  private void addClasses(Set<String> packages, String[] values) {
+      if (values != null) {
+          for (String value : values) {
+              packages.add(ClassUtils.getPackageName(value));
+          }
+      }
+  }
+  ```
+
+  - 虽然很长，但是比较简单。就是找 `@ComponentScan` 注解所扫描的包。
+
+- `<2>` 处，调用 `#getProblematicPackages(Set<String> scannedPackages)` 方法，获得要扫描的包中，有问题的包。代码如下：
+
+  ```
+  // ConfigurationWarningsPostProcessor#ComponentScanPackageCheck.java
+  
+  private List<String> getProblematicPackages(Set<String> scannedPackages) {
+      // 有问题的包的集合
+      List<String> problematicPackages = new ArrayList<>();
+      for (String scannedPackage : scannedPackages) {
+          // 判断是否在 PROBLEM_PACKAGES 中。如果是，则添加到 problematicPackages 中
+          if (isProblematicPackage(scannedPackage)) {
+              problematicPackages.add(getDisplayName(scannedPackage));
+          }
+      }
+      return problematicPackages;
+  }
+  
+  private boolean isProblematicPackage(String scannedPackage) {
+      if (scannedPackage == null || scannedPackage.isEmpty()) {
+          return true;
+      }
+      return PROBLEM_PACKAGES.contains(scannedPackage);
+  }
+  
+  private String getDisplayName(String scannedPackage) {
+      if (scannedPackage == null || scannedPackage.isEmpty()) {
+          return "the default package";
+      }
+      return "'" + scannedPackage + "'";
+  }
+  ```
+
+  - 😈 就是判断 `scannedPackages` 哪些在 `PROBLEM_PACKAGES` 中。
+
+- `<3.1>` 处，如果 `problematicPackages` 为空，说明不存在问题。
+
+- `<3.2>` 处，如果 `problematicPackages` 非空，说明有问题，返回错误提示。
+
+# 8. ServerPortInfoApplicationContextInitializer
+
+`org.springframework.boot.web.context.ServerPortInfoApplicationContextInitializer` ，实现 ApplicationContextInitializer、ApplicationListener 接口，监听 EmbeddedServletContainerInitializedEvent 类型的事件，然后将内嵌的 Web 服务器使用的端口给设置到 ApplicationContext 中。
+
+## 8.1 initialize
+
+实现 `#initialize(ConfigurableApplicationContext applicationContext)` 方法，代码如下：
+
+```
+// ServerPortInfoApplicationContextInitializer.java
+
+@Override
+public void initialize(ConfigurableApplicationContext applicationContext) {
+	applicationContext.addApplicationListener(this);
+}
+```
+
+- 将自身作为一个 ApplicationListener 监听器，添加到 Spring 容器中。
+
+## 8.2 onApplicationEvent
+
+实现 `#onApplicationEvent(WebServerInitializedEvent event)` 方法，当监听到 WebServerInitializedEvent 事件，进行触发。代码如下：
+
+```
+// ServerPortInfoApplicationContextInitializer.java
+
+@Override
+public void onApplicationEvent(WebServerInitializedEvent event) {
+    // <1> 获得属性名
+    String propertyName = "local." + getName(event.getApplicationContext()) + ".port";
+    // <2> 设置端口到 environment 的 propertyName 中
+    setPortProperty(event.getApplicationContext(), propertyName, event.getWebServer().getPort());
+}
+```
+
+- `<1>` 处，获得属性名。其中，`#getName(WebServerApplicationContext context)` 方法，获得 WebServer 的名字。代码如下：
+
+  ```
+  // ServerPortInfoApplicationContextInitializer.java
+  
+  private String getName(WebServerApplicationContext context) {
+  	String name = context.getServerNamespace();
+  	return StringUtils.hasText(name) ? name : "server";
+  }
+  ```
+
+- `<2>` 处，调用 `#setPortProperty(ApplicationContext context, String propertyName, int port)` 方法，设置端口到 `environment` 的 `propertyName` 中。代码如下：
+
+  ```
+  // ServerPortInfoApplicationContextInitializer.java
+  
+  private void setPortProperty(ApplicationContext context, String propertyName, int port) {
+      // 设置端口到 environment 的 propertyName 中
+      if (context instanceof ConfigurableApplicationContext) {
+          setPortProperty(((ConfigurableApplicationContext) context).getEnvironment(), propertyName, port);
+      }
+      // 如果有父容器，则继续设置
+      if (context.getParent() != null) {
+          setPortProperty(context.getParent(), propertyName, port);
+      }
+  }
+  
+  @SuppressWarnings("unchecked")
+  private void setPortProperty(ConfigurableEnvironment environment, String propertyName, int port) {
+      MutablePropertySources sources = environment.getPropertySources();
+      // 获得 "server.ports" 属性对应的值
+      PropertySource<?> source = sources.get("server.ports");
+      if (source == null) {
+          source = new MapPropertySource("server.ports", new HashMap<>());
+          sources.addFirst(source);
+      }
+      // 添加到 source 中
+      ((Map<String, Object>) source.getSource()).put(propertyName, port);
+  }
+  ```
+
+  - 注意噢，设置的属性结果是，`"server.ports"` 中，的 KEY 为 `propertyName` ，VALUE 为 `port` 。😈
+
+# 9. 其他 ApplicationContextInitializer 实现类
+
+ApplicationContextInitializer 还有一些其它实现类，不是很重要，可以选择不看。
+
+- ```
+  spring-boot-test
+  ```
+
+   
+
+  模块
+
+  - `org.springframework.boot.test.context.ConfigFileApplicationContextInitializer` 类
+  - `org.springframework.boot.test.context.SpringBootContextLoader` 中的 ParentContextApplicationContextInitializer 类
+
+- ```
+  spring-boot-devtools
+  ```
+
+   
+
+  模块
+
+  - `org.springframework.boot.devtools.restart.RestartScopeInitializer` 类
+
+- ```
+  spring-boot-autoconfigure
+  ```
+
+   
+
+  模块
+
+  - `org.springframework.boot.autoconfigure.logging.ConditionEvaluationReportLoggingListener` 类
+
+- ```
+  spring-boot
+  ```
+
+   
+
+  模块
+
+  - `org.springframework.boot.web.servlet.support.ServletContextApplicationContextInitializer` 类
+  - `org.springframework.boot.builder.ParentContextApplicationContextInitializer` 类
+
+😈 貌似还是蛮多的。
+
+# 666. 彩蛋
+
+小更一下，算是水文~感觉比较有收获的 ApplicationContextInitializer 的实现类是：
+
+- [「6. ContextIdApplicationContextInitializer」](https://svip.iocoder.cn/Spring-Boot/ApplicationContextInitializer/#)
+- [「8. ServerPortInfoApplicationContextInitializer」](https://svip.iocoder.cn/Spring-Boot/ApplicationContextInitializer/#)
+
+参考和推荐如下文章：
+
+- dm_vincent [《[Spring Boot\] 5. Spring Boot 中的ApplicationContext - 执行 ApplicationContextInitializer 初始化器》](https://blog.csdn.net/dm_vincent/article/details/77619780)
\ No newline at end of file
diff --git a/springboot/13-Spring Boot 源码分析-ApplicationListener.assets/02.jpg b/springboot/13-Spring Boot 源码分析-ApplicationListener.assets/02.jpg
new file mode 100644
index 0000000..3d019af
Binary files /dev/null and b/springboot/13-Spring Boot 源码分析-ApplicationListener.assets/02.jpg differ
diff --git a/springboot/13-Spring Boot 源码分析-ApplicationListener.md b/springboot/13-Spring Boot 源码分析-ApplicationListener.md
new file mode 100644
index 0000000..cd4be6e
--- /dev/null
+++ b/springboot/13-Spring Boot 源码分析-ApplicationListener.md	
@@ -0,0 +1,772 @@
+# 精尽 Spring Boot 源码分析 —— ApplicationListener
+
+# 1. 概述
+
+本文，我们来补充 [《精尽 Spring Boot 源码分析 —— SpringApplication》](http://svip.iocoder.cn/Spring-Boot/SpringApplication) 文章，并未详细解析的 ApplicationListener 。
+
+# 2. ApplicationListener
+
+`org.springframework.context.ApplicationListener` ，应用事件监听器接口。代码如下：
+
+```
+// ApplicationListener.java
+
+/**
+ * Interface to be implemented by application event listeners.
+ * Based on the standard {@code java.util.EventListener} interface
+ * for the Observer design pattern.
+ *
+ * <p>As of Spring 3.0, an ApplicationListener can generically declare the event type
+ * that it is interested in. When registered with a Spring ApplicationContext, events
+ * will be filtered accordingly, with the listener getting invoked for matching event
+ * objects only.
+ *
+ * @author Rod Johnson
+ * @author Juergen Hoeller
+ * @param <E> the specific ApplicationEvent subclass to listen to
+ * @see org.springframework.context.event.ApplicationEventMulticaster
+ */
+@FunctionalInterface
+public interface ApplicationListener<E extends ApplicationEvent> extends EventListener {
+
+	/**
+	 * Handle an application event.
+	 * @param event the event to respond to
+	 */
+	void onApplicationEvent(E event);
+
+}
+```
+
+- 如果对这块不了解的胖友，可以看看 [《Spring 5 源码解析 —— Spring 框架中的事件和监听器》](http://www.iocoder.cn/Spring/ApplicationContextEvent/?vip) 文章。
+
+## 2.1 SmartApplicationListener
+
+`org.springframework.context.event.SmartApplicationListener` 接口，实现 ApplicationListener、Ordered 接口，是 Spring3.0 新增的接口，提供了事件类型和来源的判断接口方法。代码如下：
+
+```
+// SmartApplicationListener.java
+
+/**
+ * Extended variant of the standard {@link ApplicationListener} interface,
+ * exposing further metadata such as the supported event and source type.
+ *
+ * <p>For full introspection of generic event types, consider implementing
+ * the {@link GenericApplicationListener} interface instead.
+ *
+ * @author Juergen Hoeller
+ * @since 3.0
+ * @see GenericApplicationListener
+ * @see GenericApplicationListenerAdapter
+ */
+public interface SmartApplicationListener extends ApplicationListener<ApplicationEvent>, Ordered {
+
+	/**
+	 * 事件类型
+	 * Determine whether this listener actually supports the given event type.
+	 * @param eventType the event type (never {@code null})
+	 */
+	boolean supportsEventType(Class<? extends ApplicationEvent> eventType);
+
+	/**
+	 * 事件来源
+	 * Determine whether this listener actually supports the given source type.
+	 * <p>The default implementation always returns {@code true}.
+	 * @param sourceType the source type, or {@code null} if no source
+	 */
+	default boolean supportsSourceType(@Nullable Class<?> sourceType) {
+		return true;
+	}
+
+	/**
+	 * Determine this listener's order in a set of listeners for the same event.
+	 * <p>The default implementation returns {@link #LOWEST_PRECEDENCE}.
+	 */
+	@Override
+	default int getOrder() {
+		return LOWEST_PRECEDENCE;
+	}
+
+}
+```
+
+## 2.1 GenericApplicationListener
+
+`org.springframework.context.event.GenericApplicationListener` ，继承 ApplicationListener、Ordered 接口，是 Spring4.2 新增的接口，它增强了对泛型的支持，`#supportsEventType(ResolvableType)` 方法的参数采用的是可解析类型 ResolvableType 。代码如下：
+
+> ResolvableType是 Spring4 提供的泛型操作支持类，通过它可以很容易地获得泛型的实际类型信息，比如类级、字段级等等泛型信息。在 Spring4 的框架中，很多核心类内部涉及的泛型操作大都使用 ResolvableType 类进行处理。
+
+```
+// GenericApplicationListener.java
+
+/**
+ * Extended variant of the standard {@link ApplicationListener} interface,
+ * exposing further metadata such as the supported event and source type.
+ *
+ * <p>As of Spring Framework 4.2, this interface supersedes the Class-based
+ * {@link SmartApplicationListener} with full handling of generic event types.
+ *
+ * @author Stephane Nicoll
+ * @since 4.2
+ * @see SmartApplicationListener
+ * @see GenericApplicationListenerAdapter
+ */
+public interface GenericApplicationListener extends ApplicationListener<ApplicationEvent>, Ordered {
+
+	/**
+	 * 事件类型【有变动】
+	 * Determine whether this listener actually supports the given event type.
+	 * @param eventType the event type (never {@code null})
+	 */
+	boolean supportsEventType(ResolvableType eventType);
+
+	/**
+	 * 事件来源
+	 * Determine whether this listener actually supports the given source type.
+	 * <p>The default implementation always returns {@code true}.
+	 * @param sourceType the source type, or {@code null} if no source
+	 */
+	default boolean supportsSourceType(@Nullable Class<?> sourceType) {
+		return true;
+	}
+
+	/**
+	 * Determine this listener's order in a set of listeners for the same event.
+	 * <p>The default implementation returns {@link #LOWEST_PRECEDENCE}.
+	 */
+	@Override
+	default int getOrder() {
+		return LOWEST_PRECEDENCE;
+	}
+
+}
+```
+
+# 3. SpringApplication 中的使用
+
+在 SpringApplication 构造方法中，会调用 `#getSpringFactoriesInstances(Class<T> type)` 方法，获得 ApplicationListener 集合。代码如下：
+
+```
+// SpringApplication.java
+
+private <T> Collection<T> getSpringFactoriesInstances(Class<T> type) {
+    return getSpringFactoriesInstances(type, new Class<?>[] {});
+}
+
+private <T> Collection<T> getSpringFactoriesInstances(Class<T> type,
+        Class<?>[] parameterTypes, Object... args) {
+    ClassLoader classLoader = getClassLoader();
+    // Use names and ensure unique to protect against duplicates
+    // <1> 加载指定类型对应的，在 `META-INF/spring.factories` 里的类名的数组
+    Set<String> names = new LinkedHashSet<>(SpringFactoriesLoader.loadFactoryNames(type, classLoader));
+    // <2> 创建对象们
+    List<T> instances = createSpringFactoriesInstances(type, parameterTypes, classLoader, args, names);
+    // <3> 排序对象们
+    AnnotationAwareOrderComparator.sort(instances);
+    return instances;
+}
+```
+
+- ```
+  <1>
+  ```
+
+   
+
+  处，加载指定 ApplicationListener 类型对应的，在
+
+   
+
+  ```
+  META-INF/spring.factories
+  ```
+
+   
+
+  里的类名的数组。
+
+  - 假设只在 Spring MVC 的环境下，`listeners` 属性的结果如下图：[![`listeners` 属性](13-Spring Boot 源码分析-ApplicationListener.assets/02.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-01-07/02.jpg)`listeners` 属性
+  - 艿艿整理了 Spring Boot 中，ApplicationContextInitializer 的实现类们，非常多。本文，我们就分享上述的 10 个。
+
+- `<2>` 处，创建对象们。
+
+- `<3>` 处，排序对象们。
+
+# 4. ConfigFileApplicationListener
+
+`org.springframework.boot.context.config.ConfigFileApplicationListener` ，实现 SmartApplicationListener、Ordered、EnvironmentPostProcessor 接口，实现 Spring Boot 配置文件的加载。
+
+考虑到它非常重要，且复杂，我们单独在 [《精尽 Spring Boot 源码分析 —— 配置加载》](http://svip.iocoder.cn/Spring-Boot/properties-load) 详细解析。
+
+# 5. AnsiOutputApplicationListener
+
+`org.springframework.boot.context.config.AnsiOutputApplicationListener` ，实现 ApplicationListener、Ordered 接口，在 Spring Boot 环境变量(`environment`)准备完成以后运行，
+如果你的终端支持 ANSI ，设置彩色输出会让日志更具可读性。
+
+> 不了解“彩色输出”的胖友，可以看看 [《Spring Boot日志管理》](http://blog.didispace.com/springbootlog/) 文章。
+
+代码如下：
+
+```
+// ConfigFileApplicationListener.java
+
+public class AnsiOutputApplicationListener
+		implements ApplicationListener<ApplicationEnvironmentPreparedEvent>, Ordered {
+
+	@Override
+	public void onApplicationEvent(ApplicationEnvironmentPreparedEvent event) { // <1>
+//	    if (true) { 
+//	        return; // <X>
+//        }
+		ConfigurableEnvironment environment = event.getEnvironment();
+		// <2> 根据环境变量 spring.output.ansi.enabled 的值，设置 AnsiOutput.enabled 属性
+		Binder.get(environment).bind("spring.output.ansi.enabled", AnsiOutput.Enabled.class)
+                .ifBound(AnsiOutput::setEnabled);
+		// <3> 根据环境变量 "spring.output.ansi.console-available 的值，设置 AnsiOutput.consoleAvailable 属性
+		AnsiOutput.setConsoleAvailable(environment.getProperty("spring.output.ansi.console-available", Boolean.class));
+	}
+
+	@Override
+	public int getOrder() {
+		// Apply after ConfigFileApplicationListener has called EnvironmentPostProcessors
+		return ConfigFileApplicationListener.DEFAULT_ORDER + 1;
+	}
+
+}
+```
+
+- `<1>` 处，我们可以知道，监听的是 ApplicationEnvironmentPreparedEvent 事件。
+
+- `<2>` 处，根据环境变量 `"spring.output.ansi.enabled"` 的值，设置 `AnsiOutput.enabled` 属性。这块的逻辑，卡了艿艿很久，一点一点来说。
+
+  - 首先，因为艿艿并没有细看 Binder 的实现代码，所以这块就卡了一会。简单来说，`Binder.get(environment).bind("spring.output.ansi.enabled", AnsiOutput.Enabled.class)` 代码块的意思是，从 `environment` 读取 `"spring.output.ansi.enabled"` 对应的值，并转换成 AnsiOutput.Enabled 类型。其中，AnsiOutput.Enabled 的枚举值如下：
+
+    ```
+    // AnsiOutput#Enabled.java
+    
+    public enum Enabled {
+    
+    	/**
+         * 自动探测，根据是否支持 ANSI 的功能，来判断是否要彩色输出
+         *
+         * 【默认值】
+         *
+    	 * Try to detect whether ANSI coloring capabilities are available. The default
+    	 * value for {@link AnsiOutput}.
+    	 */
+    	DETECT,
+    
+    	/**
+         * 总是开启 ANSI 彩色输出
+         *
+    	 * Enable ANSI-colored output.
+    	 */
+    	ALWAYS,
+    
+    	/**
+         * 禁用 ANSI 彩色输出
+         *
+    	 * Disable ANSI-colored output.
+    	 */
+    	NEVER
+    
+    }
+    ```
+
+    - 貌似也没什么问题。但是，让艿艿闷逼的是，为什么结果会是 `AnsiOutput.Enabled.ALWAYS` ，在 IDEA 环境中。后来，在 `environment` 中，一个名字是 `"systemProperties"` 的 MapPropertySource 属性源，里面提供了 `"spring.output.ansi.enabled=always"` 的配置。
+
+      - 各种全文检索代码，貌似除了测试用例里，没有地方强制赋值了 `"spring.output.ansi.enabled"` 。
+
+      - 后来发现，
+
+        ```
+        "systemProperties"
+        ```
+
+         
+
+        这个 MapPropertySource 属性源，读取的是
+
+         
+
+        ```
+        System#getProperties()
+        ```
+
+         
+
+        方法，但是为啥里面会有
+
+         
+
+        ```
+        "spring.output.ansi.enabled=always"
+        ```
+
+         
+
+        呢？目前的猜测是，IDEA 判断在 Spring Boot 环境下，自动添加进去的！
+
+        - 然后，
+
+          ```
+          .ifBound(AnsiOutput::setEnabled)
+          ```
+
+           
+
+          代码段，应该翻译成如下的代码，可能比较易懂：
+
+          ```
+          Binder.get(environment).bind("spring.output.ansi.enabled", AnsiOutput.Enabled.class)
+          .ifBound(new Consumer<Enabled>() {
+              @Override
+              public void accept(Enabled enabled) {
+                  AnsiOutput.setEnabled(enabled);
+              }
+          });
+          ```
+
+    - 即，`Binder.get(environment).bind("spring.output.ansi.enabled", AnsiOutput.Enabled.class)` 返回的是 BindResult 对象，然后调用 `BindResult#ifBound(Consumer)` 方法，将解析到的属性值，赋值到 `AnsiOutput.enabled` 属性。
+
+      - 😈 真的是有点绕噢。
+
+- `<3>` 处，根据环境变量 `"spring.output.ansi.console-available"` 的值，设置 `AnsiOutput.consoleAvailable` 属性。
+
+通过这样的方式，后续在 IDEA 中，我们就可以发现日志打印出来的，是带有彩色输出的。如果胖友是个调皮的人，可以尝试打开 `<X>` 处的三行注释，然后重新运行，就神奇的发现，彩色输出不见了，嘿嘿嘿。
+
+# 6. LoggingApplicationListener
+
+`org.springframework.boot.context.logging.LoggingApplicationListener` ，实现 GenericApplicationListener 接口，实现根据配置初始化日志系统 Logger 。
+
+考虑到它非常重要，且复杂，我们单独在 [《精尽 Spring Boot 源码分析 —— 日志系统》](http://svip.iocoder.cn/Spring-Boot/logger-system) 详细解析。
+
+# 7. ClasspathLoggingApplicationListener
+
+`org.springframework.boot.context.logging.ClasspathLoggingApplicationListener` ，实现 GenericApplicationListener 接口，程序启动时，将 classpath 打印到 debug 日志，启动失败时 classpath 打印到 debug 日志。代码如下：
+
+```
+// ClasspathLoggingApplicationListener.java
+
+public final class ClasspathLoggingApplicationListener implements GenericApplicationListener {
+
+    /**
+     * 顺序
+     */
+	private static final int ORDER = LoggingApplicationListener.DEFAULT_ORDER + 1;
+
+	private static final Log logger = LogFactory.getLog(ClasspathLoggingApplicationListener.class);
+
+	@Override
+	public void onApplicationEvent(ApplicationEvent event) {
+		if (logger.isDebugEnabled()) {
+		    // 如果是 ApplicationEnvironmentPreparedEvent 事件，说明启动成功，打印成功到 debug 日志中
+			if (event instanceof ApplicationEnvironmentPreparedEvent) {
+				logger.debug("Application started with classpath: " + getClasspath());
+            // 如果是 ApplicationFailedEvent 事件，说明启动失败，打印失败到 debug 日志中
+			} else if (event instanceof ApplicationFailedEvent) {
+				logger.debug("Application failed to start with classpath: " + getClasspath());
+			}
+		}
+	}
+
+	@Override
+	public int getOrder() {
+		return ORDER;
+	}
+
+	@Override
+	public boolean supportsEventType(ResolvableType resolvableType) {
+		Class<?> type = resolvableType.getRawClass(); // 使用 ResolvableType 类，可以解析当前传入的参数的泛型，从而后的事件类型
+		if (type == null) {
+			return false;
+		}
+		// 判断是否需为 ApplicationEnvironmentPreparedEvent 或者 ApplicationFailedEvent 事件
+		return ApplicationEnvironmentPreparedEvent.class.isAssignableFrom(type)
+				|| ApplicationFailedEvent.class.isAssignableFrom(type);
+	}
+
+    /**
+     * @return 获得 classpath
+     */
+	private String getClasspath() {
+		ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
+		if (classLoader instanceof URLClassLoader) {
+			return Arrays.toString(((URLClassLoader) classLoader).getURLs());
+		}
+		return "unknown";
+	}
+
+}
+```
+
+# 8. BackgroundPreinitializer
+
+`org.springframework.boot.autoconfigure.BackgroundPreinitializer` ，实现 ApplicationListener 接口，实现后台提前执行耗时的初始化任务。代码如下：
+
+```
+// BackgroundPreinitializer.java
+
+@Order(LoggingApplicationListener.DEFAULT_ORDER + 1)
+public class BackgroundPreinitializer implements ApplicationListener<SpringApplicationEvent> {
+
+    /**
+     * System property that instructs Spring Boot how to run pre initialization. When the
+     * property is set to {@code true}, no pre-initialization happens and each item is
+     * initialized in the foreground as it needs to. When the property is {@code false}
+     * (default), pre initialization runs in a separate thread in the background.
+     * @since 2.1.0
+     */
+    public static final String IGNORE_BACKGROUNDPREINITIALIZER_PROPERTY_NAME = "spring.backgroundpreinitializer.ignore";
+
+    /**
+     * 预初始化任务是否已启动
+     */
+    private static final AtomicBoolean preinitializationStarted = new AtomicBoolean(false);
+
+    /**
+     * 预初始化任务的 CountDownLatch 对象，用于实现等待预初始化任务是否完成
+     */
+    private static final CountDownLatch preinitializationComplete = new CountDownLatch(1);
+
+    @Override
+    public void onApplicationEvent(SpringApplicationEvent event) {
+        // <1> 如果是开启后台预初始化任务，默认情况下开启
+        // 并且，是 ApplicationStartingEvent 事件，说明应用正在启动中
+        // 并且，是多核环境
+        // 并且，预初始化任务未启动
+        if (!Boolean.getBoolean(IGNORE_BACKGROUNDPREINITIALIZER_PROPERTY_NAME)
+                && event instanceof ApplicationStartingEvent
+                && multipleProcessors()
+                && preinitializationStarted.compareAndSet(false, true)) {
+            // 启动
+            performPreinitialization();
+        }
+        // <2> 如果是 ApplicationReadyEvent 或 ApplicationFailedEvent 事件，说明应用启动成功后失败，则等待预初始化任务完成
+        if ((event instanceof ApplicationReadyEvent
+                || event instanceof ApplicationFailedEvent)
+                && preinitializationStarted.get()) { // 判断预初始化任务已经启动
+            // 通过 CountDownLatch 实现，预初始化任务执行完成。
+            try {
+                preinitializationComplete.await();
+            } catch (InterruptedException ex) {
+                Thread.currentThread().interrupt();
+            }
+        }
+    }
+
+    /**
+     * @return 判断是否多核环境
+     */
+    private boolean multipleProcessors() {
+        return Runtime.getRuntime().availableProcessors() > 1;
+    }
+    
+    // ... 省略部分代码
+}
+```
+
+- 几个变量，胖友直接看代码注释。
+- `<1>` 处，满足如下的四个条件（每一行注释，对应一个条件），调用 `#performPreinitialization()` 方法，启动线程，后台执行预初始化任务。关于 `#performPreinitialization()` 方法，在 [「8.1 performPreinitialization」](https://svip.iocoder.cn/Spring-Boot/ApplicationListener/#) 详细解析。
+- `<2>` 处，如果是 ApplicationReadyEvent 或 ApplicationFailedEvent 事件，说明应用启动成功后失败，则等待预初始化任务完成。
+- 总结来说，`<1>` 处，启动后台任务，`<2>` 处，保证后台任务执行完成。
+
+## 8.1 performPreinitialization
+
+`#performPreinitialization()` 方法，启动线程，后台执行预初始化任务。代码如下：
+
+```
+// BackgroundPreinitializer.java
+
+private void performPreinitialization() {
+    try {
+        // <1> 创建线程
+        Thread thread = new Thread(new Runnable() {
+
+            @Override
+            public void run() {
+                // 安全运行每个初始化任务
+                runSafely(new ConversionServiceInitializer());
+                runSafely(new ValidationInitializer());
+                runSafely(new MessageConverterInitializer());
+                runSafely(new MBeanFactoryInitializer());
+                runSafely(new JacksonInitializer());
+                runSafely(new CharsetInitializer());
+                // <3> 标记 preinitializationComplete 完成
+                preinitializationComplete.countDown();
+            }
+
+            public void runSafely(Runnable runnable) {
+                try {
+                    runnable.run();
+                } catch (Throwable ex) {
+                    // Ignore
+                }
+            }
+
+        }, "background-preinit");
+        // <2> 启动线程
+        thread.start();
+    } catch (Exception ex) {
+        // This will fail on GAE where creating threads is prohibited. We can safely
+        // continue but startup will be slightly slower as the initialization will now
+        // happen on the main thread.
+        // 标记 preinitializationComplete 完成
+        preinitializationComplete.countDown();
+    }
+}
+```
+
+- `<1>` 处，创建一个线程，用于后台调用 `#runSafely(Runnable runnable)` 方法，“安全”（即发生异常，不进行抛出去）执行每个初始化任务。
+- `<2>` 处，启动线程。
+- `<3>` 处，在所有初始化任务都执行完成后，通过标记 `preinitializationComplete` 完成，从而实现在 `#onApplicationEvent(SpringApplicationEvent even)` 的 `<2>` 处的阻塞等待被通知完成。
+
+## 8.2 初始化任务
+
+- [ConversionServiceInitializer](https://github.com/YunaiV/spring-boot/blob/master/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/BackgroundPreinitializer.java#L180)
+- [ValidationInitializer](https://github.com/YunaiV/spring-boot/blob/master/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/BackgroundPreinitializer.java#L155)
+- [MessageConverterInitializer](https://github.com/YunaiV/spring-boot/blob/master/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/BackgroundPreinitializer.java#L131)
+- [MBeanFactoryInitializer](https://github.com/YunaiV/spring-boot/blob/master/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/BackgroundPreinitializer.java#L143)
+- [JacksonInitializer](https://github.com/YunaiV/spring-boot/blob/master/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/BackgroundPreinitializer.java#L168)
+- [CharsetInitializer](https://github.com/YunaiV/spring-boot/blob/master/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/BackgroundPreinitializer.java#L189)
+
+# 9. DelegatingApplicationListener
+
+`org.springframework.boot.context.config.DelegatingApplicationListener` ，实现 ApplicationListener、Ordered 接口，和 [「DelegatingApplicationContextInitializer」](http://svip.iocoder.cn/Spring-Boot/ApplicationContextInitializer) 是类似的，只是读取的是环境变量 `"context.listener.classes"` 对应的 ApplicationContextInitializer 实现类们。
+
+# 10. ParentContextCloserApplicationListener
+
+`org.springframework.boot.builder.ParentContextCloserApplicationListener` ，实现 ApplicationListener、ApplicationContextAware、Ordered 接口，容器关闭时发出通知，如果父容器关闭，那么自容器也一起关闭。代码如下：
+
+```
+// ParentContextCloserApplicationListener.java
+
+public class ParentContextCloserApplicationListener implements ApplicationListener<ParentContextAvailableEvent>, ApplicationContextAware, Ordered {
+
+    /**
+     * 顺序
+     */
+	private int order = Ordered.LOWEST_PRECEDENCE - 10;
+
+	private ApplicationContext context;
+
+	@Override
+	public int getOrder() {
+		return this.order;
+	}
+
+	@Override
+	public void setApplicationContext(ApplicationContext context) throws BeansException {
+		this.context = context;
+	}
+
+	@Override
+	public void onApplicationEvent(ParentContextAvailableEvent event) {
+		maybeInstallListenerInParent(event.getApplicationContext()); // <1>
+	}
+	
+	// ... 省略其它方法
+}
+```
+
+- 在 `<1>` 处，我们可以看到当接收到 ParentContextAvailableEvent 事件后，会调用 `#maybeInstallListenerInParent(ConfigurableApplicationContext child)` 方法，向父容器添加监听器，监听父容器的关闭事件。详细解析，见 [「10.1 maybeInstallListenerInParent」](https://svip.iocoder.cn/Spring-Boot/ApplicationListener/#) 。
+- ParentContextAvailableEvent 事件的发布，依赖 [`org.springframework.boot.builder.ParentContextApplicationContextInitializer`](https://github.com/YunaiV/spring-boot/blob/master/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/builder/ParentContextApplicationContextInitializer.java) 初始化类。默认情况下，ParentContextApplicationContextInitializer 类并未使用，所以吧，😈 ParentContextCloserApplicationListener 基本无法生效列。
+
+## 10.1 maybeInstallListenerInParent
+
+`#maybeInstallListenerInParent(ConfigurableApplicationContext child)` 方法，向父容器添加监听器，监听父容器的关闭事件。代码如下：
+
+```
+// ParentContextCloserApplicationListener.java
+
+private void maybeInstallListenerInParent(ConfigurableApplicationContext child) {
+    // 如果 child 是当前容器
+    if (child == this.context
+            // 并且父容器是 ConfigurableApplicationContext 类型
+            && child.getParent() instanceof ConfigurableApplicationContext) {
+        // 向父容器添加监听器，监听父容器的关闭事件
+        ConfigurableApplicationContext parent = (ConfigurableApplicationContext) child.getParent();
+        parent.addApplicationListener(createContextCloserListener(child)); // <1>
+    }
+}
+```
+
+- 在 `<1>` 处，会调用 `#createContextCloserListener(ConfigurableApplicationContext child)` 方法，创建 ContextCloserListener 对象。代码如下：
+
+  ```
+  // ParentContextCloserApplicationListener.java
+  
+  protected ContextCloserListener createContextCloserListener(ConfigurableApplicationContext child) {
+  	return new ContextCloserListener(child);
+  }
+  ```
+
+  - 关于 ContextCloserListener 类，在 [「10.2 ContextCloserListener」](https://svip.iocoder.cn/Spring-Boot/ApplicationListener/#) 中，详细解析。
+
+- `<1>` 处，创建后的 ContextCloserListener 对象，向父容器 `parent` 中注册。
+
+## 10.2 ContextCloserListener
+
+ContextCloserListener ，是 ParentContextCloserApplicationListener 的内部类，实现 ApplicationListener 接口，监听父容器关闭时，关闭自己（容器）。代码如下：
+
+```
+// ParentContextCloserApplicationListener#ContextCloserListener.java
+
+protected static class ContextCloserListener implements ApplicationListener<ContextClosedEvent> {
+
+    private WeakReference<ConfigurableApplicationContext> childContext;
+
+    public ContextCloserListener(ConfigurableApplicationContext childContext) {
+        this.childContext = new WeakReference<>(childContext);
+    }
+
+    @Override
+    public void onApplicationEvent(ContextClosedEvent event) {
+        ConfigurableApplicationContext context = this.childContext.get();
+        if ((context != null)
+                && (event.getApplicationContext() == context.getParent()) // 如果是父容器
+                && context.isActive()) { // 并且当前容器是启动状态
+            // 关闭当前容器
+            context.close();
+        }
+    }
+}
+```
+
+# 11. ClearCachesApplicationListener
+
+`org.springframework.boot.ClearCachesApplicationListener` ，实现 ApplicationListener 接口，实现 ReflectionUtils 的缓存、ClassLoader 的缓存。代码如下：
+
+```
+// ClearCachesApplicationListener.java
+
+class ClearCachesApplicationListener implements ApplicationListener<ContextRefreshedEvent> {
+
+    @Override
+    public void onApplicationEvent(ContextRefreshedEvent event) {
+        // 清空 ReflectionUtils 缓存
+        ReflectionUtils.clearCache();
+        // 清空类加载器的缓存
+        clearClassLoaderCaches(Thread.currentThread().getContextClassLoader());
+    }
+
+    private void clearClassLoaderCaches(ClassLoader classLoader) {
+        if (classLoader == null) {
+            return;
+        }
+        // 同构反射调用 ClassLoader 类的 clearCache 方法，清空它的缓存
+        try {
+            Method clearCacheMethod = classLoader.getClass().getDeclaredMethod("clearCache");
+            clearCacheMethod.invoke(classLoader);
+        } catch (Exception ex) {
+            // Ignore
+        }
+        // 如果有父加载器，则父加载器清空缓存
+        clearClassLoaderCaches(classLoader.getParent());
+    }
+
+}
+```
+
+- 在接收到容器初始化 ContextRefreshedEvent 事件，触发 ClearCachesApplicationListener 监听器，进行清空缓存。
+
+# 12. FileEncodingApplicationListener
+
+`org.springframework.boot.context.FileEncodingApplicationListener` ，实现 ApplicationListener、Ordered 接口，在Spring Boot 环境准备完成以后运行，获取环境中的系统环境参数，检测当前系统环境的 `file.encoding` 和 `spring.mandatory-file-encoding` 设置的值是否一样，如果不一样则抛出异常；
+如果不配置 `spring.mandatory-file-encoding` 则不检查。代码如下：
+
+```
+// FileEncodingApplicationListener.java
+
+public class FileEncodingApplicationListener implements ApplicationListener<ApplicationEnvironmentPreparedEvent>, Ordered {
+
+    private static final Log logger = LogFactory.getLog(FileEncodingApplicationListener.class);
+
+    @Override
+    public int getOrder() {
+        return Ordered.LOWEST_PRECEDENCE;
+    }
+
+    @Override
+    public void onApplicationEvent(ApplicationEnvironmentPreparedEvent event) {
+        ConfigurableEnvironment environment = event.getEnvironment();
+        // 如果未配置，则不进行检查
+        if (!environment.containsProperty("spring.mandatory-file-encoding")) {
+            return;
+        }
+        // 比对系统变量的 `file.encoding` ，和环境变量的 `spring.mandatory-file-encoding` 。
+        // 如果不一致，抛出 IllegalStateException 异常
+        String encoding = System.getProperty("file.encoding");
+        String desired = environment.getProperty("spring.mandatory-file-encoding");
+        if (encoding != null && !desired.equalsIgnoreCase(encoding)) {
+            logger.error("System property 'file.encoding' is currently '" + encoding
+                    + "'. It should be '" + desired
+                    + "' (as defined in 'spring.mandatoryFileEncoding').");
+            logger.error("Environment variable LANG is '" + System.getenv("LANG")
+                    + "'. You could use a locale setting that matches encoding='"
+                    + desired + "'.");
+            logger.error("Environment variable LC_ALL is '" + System.getenv("LC_ALL")
+                    + "'. You could use a locale setting that matches encoding='"
+                    + desired + "'.");
+            // 抛出 IllegalStateException 异常
+            throw new IllegalStateException(
+                    "The Java Virtual Machine has not been configured to use the "
+                            + "desired default character encoding (" + desired + ").");
+        }
+    }
+
+}
+```
+
+# 13. LiquibaseServiceLocatorApplicationListener
+
+`org.springframework.boot.liquibase.LiquibaseServiceLocatorApplicationListener` ，实现 ApplicationListener 接口，初始化 Liquibase 的 ServiceLocator 对象。代码如下：
+
+> 如果不了解 Liquibase 的胖友，可以看看 [《一起来学 SpringBoot 2.x | 第二十四篇：数据库管理与迁移（Liquibase）》](http://www.iocoder.cn/Spring-Boot/battcn/v2-other-liquibase/?vip) 文章。
+
+```
+// LiquibaseServiceLocatorApplicationListener.java
+
+public class LiquibaseServiceLocatorApplicationListener implements ApplicationListener<ApplicationStartingEvent> {
+
+    private static final Log logger = LogFactory.getLog(LiquibaseServiceLocatorApplicationListener.class);
+
+    @Override
+    public void onApplicationEvent(ApplicationStartingEvent event) {
+        // <1> 如果存在 CustomResolverServiceLocator 类
+        if (ClassUtils.isPresent("liquibase.servicelocator.CustomResolverServiceLocator",
+                event.getSpringApplication().getClassLoader())) {
+            new LiquibasePresent().replaceServiceLocator();
+        }
+    }
+
+    /**
+     * Inner class to prevent class not found issues.
+     */
+    private static class LiquibasePresent {
+
+        public void replaceServiceLocator() {
+            // <2> 创建 CustomResolverServiceLocator 对象
+            CustomResolverServiceLocator customResolverServiceLocator = new CustomResolverServiceLocator(new SpringPackageScanClassResolver(logger));
+            // 设置 ServiceLocator 的 `instance` 属性
+            ServiceLocator.setInstance(customResolverServiceLocator);
+        }
+
+    }
+
+}
+```
+
+- `<1>` 处，判断是否存在 `liquibase.servicelocator.CustomResolverServiceLocator` 类。通过该判断，可以知道是否引入了 `liquibase-core` 包，需要使初始化 Liquibase 功能。
+- `<2>` 处，创建 CustomResolverServiceLocator 对象。当然，如果没有自定义的话，这个对象，返回的就是默认的 Liquibase ServiceLocator 对象。
+- `<3>` 处，设置到 ServiceLocator 的 `instance` 属性。
+
+当然，以上的逻辑，胖友选择性了解即可。哈哈哈哈~
+
+# 666. 彩蛋
+
+严格来说，本文并没有写太多具体的内容。更多的是，为了后面的内容做一个铺垫，同时也让胖友知道，Spring Boot 默认提供的 ApplicationListener 实现类。
+
+参考和推荐如下文章：
+
+- oldflame-Jm [《Spring Boot 源码分析 - ApplicationListener 应用环境（5）》](https://blog.csdn.net/jamet/article/details/78042486)
\ No newline at end of file
diff --git a/springboot/14-Spring Boot 源码分析-配置加载.assets/01.jpg b/springboot/14-Spring Boot 源码分析-配置加载.assets/01.jpg
new file mode 100644
index 0000000..fe25418
Binary files /dev/null and b/springboot/14-Spring Boot 源码分析-配置加载.assets/01.jpg differ
diff --git a/springboot/14-Spring Boot 源码分析-配置加载.assets/02.jpg b/springboot/14-Spring Boot 源码分析-配置加载.assets/02.jpg
new file mode 100644
index 0000000..854c068
Binary files /dev/null and b/springboot/14-Spring Boot 源码分析-配置加载.assets/02.jpg differ
diff --git a/springboot/14-Spring Boot 源码分析-配置加载.md b/springboot/14-Spring Boot 源码分析-配置加载.md
new file mode 100644
index 0000000..57590e9
--- /dev/null
+++ b/springboot/14-Spring Boot 源码分析-配置加载.md	
@@ -0,0 +1,2043 @@
+# 精尽 Spring Boot 源码分析 —— 配置加载
+
+# 1. 概述
+
+在使用 Spring Boot 时，我们可以很方便的在 `application.properties` 或 `application.yml` 配置文件中，添加相应的应用所需的配置。那么，究竟 Spring Boot 是如何实现该功能的呢，今儿我们就通过 Spring Boot 的源码，一探究竟！
+
+> 艿艿的高能提示：这篇会非常长，建议胖友保持耐心。另外，最好边调试边看~
+
+# 2. Profiles
+
+在讲配置加载之前，不得不先提下 Spring Profiles 功能。
+
+- 如果不熟悉的胖友，先看看 [《详解 Spring 中的 Profile》](https://www.jianshu.com/p/948c303b2253) 文章。
+- 关于这一块，之前在 [《【死磕 Spring】—— 环境 & 属性：PropertySource、Environment、Profile》](http://svip.iocoder.cn/Spring/PropertySource-and-Environment-and-Profile/) 中，已经有详细的源码解析。
+
+😈 Spring Boot 在 Spring Framework 的基础之上，可以手动附加新的 Profile 。在 [《精尽 Spring Boot 源码分析 —— SpringApplication》](http://svip.iocoder.cn/Spring-Boot/SpringApplication/) 的 `#` 。代码如下：
+
+```
+// SpringApplication.java
+
+/**
+ * 附加的 profiles 的数组
+ */
+private Set<String> additionalProfiles = new HashSet<>();
+
+protected void configureProfiles(ConfigurableEnvironment environment, String[] args) {
+    environment.getActiveProfiles(); // ensure they are initialized 保证已经被初始化
+    // But these ones should go first (last wins in a property key clash)
+    Set<String> profiles = new LinkedHashSet<>(this.additionalProfiles);
+    profiles.addAll(Arrays.asList(environment.getActiveProfiles())); // <X>
+    // 设置 activeProfiles
+    environment.setActiveProfiles(StringUtils.toStringArray(profiles));
+}
+```
+
+- `additionalProfiles` 属性，可以设置创建的 SpringApplication 可以附加的 `additionalProfiles` 属性。
+- `<X>` 处，在原有 Spring Framework 中设置的 String Profiles 的基础上，又附加上了 `SpringApplication.additionalProfiles` 配置的。
+
+> 艿艿：这个小节，讲的有点绕，胖友辛苦理解下~
+
+# 3. ConfigFileApplicationListener
+
+Spring Boot 实现 `application.properties` 或 `application.yml` 配置文件的加载，关键在于 ConfigFileApplicationListener 类。在 [《精尽 Spring Boot 源码分析 —— ApplicationListener》](http://svip.iocoder.cn/Spring-Boot/ApplicationListener/) 中，我们已经简单介绍过它：
+
+> `org.springframework.boot.context.config.ConfigFileApplicationListener` ，实现 SmartApplicationListener、Ordered、EnvironmentPostProcessor 接口，实现 Spring Boot 配置文件的加载。
+
+- 注意哟，ConfigFileApplicationListener 即是一个 SmartApplicationListener 实现类，又是一个 EnvironmentPostProcessor 实现类。
+
+## 3.1 onApplicationEvent
+
+实现 `#onApplicationEvent(ApplicationEvent event)` 方法，分别对 ApplicationEnvironmentPreparedEvent、ApplicationPreparedEvent 事件进行处理。代码如下：
+
+```
+// ConfigFileApplicationListener.java
+
+@Override
+public boolean supportsEventType(Class<? extends ApplicationEvent> eventType) {
+    return ApplicationEnvironmentPreparedEvent.class.isAssignableFrom(eventType)
+            || ApplicationPreparedEvent.class.isAssignableFrom(eventType);
+}
+
+@Override
+public void onApplicationEvent(ApplicationEvent event) {
+    // <1> 如果是 ApplicationEnvironmentPreparedEvent 事件，说明 Spring 环境准备好了，则执行相应的处理
+    if (event instanceof ApplicationEnvironmentPreparedEvent) {
+        onApplicationEnvironmentPreparedEvent((ApplicationEnvironmentPreparedEvent) event);
+    }
+    // <2> 如果是 ApplicationPreparedEvent 事件，说明 Spring 容器初始化好了，则进行相应的处理。
+    if (event instanceof ApplicationPreparedEvent) {
+        onApplicationPreparedEvent(event);
+    }
+}
+```
+
+- `<1>` 处，如果是 ApplicationEnvironmentPreparedEvent 事件，说明 Spring 环境准备好了，则调用 `#onApplicationEnvironmentPreparedEvent(ApplicationEnvironmentPreparedEvent)` 方法，执行相应的处理。详细解析，见 [「3.2 onApplicationEnvironmentPreparedEvent」](https://svip.iocoder.cn/Spring-Boot/properties-load/#) 。
+- `<2>` 处，如果是 ApplicationPreparedEvent 事件，说明 Spring 容器初始化好了，则调用 `#onApplicationPreparedEvent(ApplicationPreparedEvent)` 方法，进行相应的处理。详细解析，见 [「3.3 onApplicationPreparedEvent」](https://svip.iocoder.cn/Spring-Boot/properties-load/#) 。
+
+## 3.2 onApplicationEnvironmentPreparedEvent
+
+`#onApplicationEnvironmentPreparedEvent(ApplicationEnvironmentPreparedEvent)` 方法，处理 ApplicationEnvironmentPreparedEvent 事件。代码如下：
+
+```
+// ConfigFileApplicationListener.java
+
+private void onApplicationEnvironmentPreparedEvent(ApplicationEnvironmentPreparedEvent event) {
+    // <1.1> 加载指定类型 EnvironmentPostProcessor 对应的，在 `META-INF/spring.factories` 里的类名的数组
+    List<EnvironmentPostProcessor> postProcessors = loadPostProcessors();
+    // 加入自己
+    postProcessors.add(this);
+    // 排序 postProcessors 数组
+    AnnotationAwareOrderComparator.sort(postProcessors);
+    // 遍历 postProcessors 数组，逐个执行。
+    for (EnvironmentPostProcessor postProcessor : postProcessors) {
+        postProcessor.postProcessEnvironment(event.getEnvironment(), event.getSpringApplication());
+    }
+}
+```
+
+- `<1.1>` 处，调用 `#loadPostProcessors()` 方法，加载指定类型 EnvironmentPostProcessor 对应的，在 `META-INF/spring.factories` 里的类名的数组。代码如下：
+
+  ```
+  // ConfigFileApplicationListener.java
+  
+  List<EnvironmentPostProcessor> loadPostProcessors() {
+  	return SpringFactoriesLoader.loadFactories(EnvironmentPostProcessor.class, getClass().getClassLoader());
+  }
+  ```
+
+  - 默认情况下，返回的是 SystemEnvironmentPropertySourceEnvironmentPostProcessor、SpringApplicationJsonEnvironmentPostProcessor、CloudFoundryVcapEnvironmentPostProcessor 类。
+
+- `<1.2>` 处，加入自己，到 `postProcessors` 数组中。因为自己也是一个 EnvironmentPostProcessor 实现类。
+
+- `<2>` 处，排序 `postProcessors` 数组。
+
+- `<3>` 处，遍历 `postProcessors` 数组，调用 `EnvironmentPostProcessor#postProcessEnvironment(ConfigurableEnvironment environment, SpringApplication application)` 方法，逐个执行。
+
+那么，我们开始来逐个看看每个 EnvironmentPostProcessor 实现类。考虑到 EnvironmentPostProcessor 应有的独立性（尊严!），我们单独开了 [「4. EnvironmentPostProcessor」](https://svip.iocoder.cn/Spring-Boot/properties-load/#) 小节，所以胖友先一起跳过来看看。
+
+> 艿艿：这块涉及的逻辑非常多。本文的 4、5、6、7 小节，都和 [「3.2 onApplicationEnvironmentPreparedEvent」](https://svip.iocoder.cn/Spring-Boot/properties-load/#) 有关。
+
+## 3.3 onApplicationPreparedEvent
+
+`#onApplicationPreparedEvent(ApplicationEvent event)` 方法，处理 ApplicationPreparedEvent 事件。代码如下：
+
+```
+// ConfigFileApplicationListener.java
+
+private void onApplicationPreparedEvent(ApplicationEvent event) {
+    // 修改 logger 文件，暂时可以无视。
+    this.logger.switchTo(ConfigFileApplicationListener.class);
+    // 添加 PropertySourceOrderingPostProcessor 处理器
+    addPostProcessors(((ApplicationPreparedEvent) event).getApplicationContext());
+}
+
+protected void addPostProcessors(ConfigurableApplicationContext context) {
+    context.addBeanFactoryPostProcessor(new PropertySourceOrderingPostProcessor(context));
+}
+```
+
+- 添加 PropertySourceOrderingPostProcessor 处理器。关于 PropertySourceOrderingPostProcessor 类，见 [「3.3.1 PropertySourceOrderingPostProcessor」](https://svip.iocoder.cn/Spring-Boot/properties-load/#) 中。
+
+### 3.3.1 PropertySourceOrderingPostProcessor
+
+PropertySourceOrderingPostProcessor ，是 ConfigFileApplicationListener 内部类，实现 BeanFactoryPostProcessor、Ordered 接口，将 `DEFAULT_PROPERTIES` 的 PropertySource 属性源，添加到 `environment` 的尾部。代码如下：
+
+```
+// ConfigFileApplicationListener.java
+private static final String DEFAULT_PROPERTIES = "defaultProperties";
+
+// ConfigFileApplicationListener#PropertySourceOrderingPostProcessor.java
+
+private class PropertySourceOrderingPostProcessor implements BeanFactoryPostProcessor, Ordered {
+
+    private ConfigurableApplicationContext context;
+
+    PropertySourceOrderingPostProcessor(ConfigurableApplicationContext context) {
+        this.context = context;
+    }
+
+    @Override
+    public int getOrder() {
+        return Ordered.HIGHEST_PRECEDENCE;
+    }
+
+    @Override
+    public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
+        reorderSources(this.context.getEnvironment());
+    }
+
+    private void reorderSources(ConfigurableEnvironment environment) {
+        // 移除 DEFAULT_PROPERTIES 的属性源
+        PropertySource<?> defaultProperties = environment.getPropertySources().remove(DEFAULT_PROPERTIES);
+        // 添加到 environment 尾部
+        if (defaultProperties != null) {
+            environment.getPropertySources().addLast(defaultProperties);
+        }
+    }
+
+}
+```
+
+- 那么 `DEFAULT_PROPERTIES` 对应的 PropertySource 属性源，究竟是哪里来的呢？答案见 `SpringApplication.defaultProperties` 相关，代码如下：
+
+```
+// SpringApplication.java 
+
+/**
+ * 默认的属性集合
+ */
+private Map<String, Object> defaultProperties;
+
+protected void configurePropertySources(ConfigurableEnvironment environment, String[] args) {
+	MutablePropertySources sources = environment.getPropertySources();
+	// 配置的 defaultProperties
+	if (this.defaultProperties != null && !this.defaultProperties.isEmpty()) {
+		sources.addLast(new MapPropertySource("defaultProperties", this.defaultProperties));
+	}
+	
+	// ... 省略无关代码
+}
+```
+
+# 4. EnvironmentPostProcessor
+
+`org.springframework.boot.context.config.EnvironmentPostProcessor` 接口，在 Environment 加载完成之后，如果我们需要对其进行一些配置、增加一些自己的处理逻辑，那么请使用 EnvironmentPostProcessor 。代码如下：
+
+```
+// EnvironmentPostProcessor.java
+
+/**
+ * Allows for customization of the application's {@link Environment} prior to the
+ * application context being refreshed.
+ * <p>
+ * EnvironmentPostProcessor implementations have to be registered in
+ * {@code META-INF/spring.factories}, using the fully qualified name of this class as the
+ * key.
+ * <p>
+ * {@code EnvironmentPostProcessor} processors are encouraged to detect whether Spring's
+ * {@link org.springframework.core.Ordered Ordered} interface has been implemented or if
+ * the {@link org.springframework.core.annotation.Order @Order} annotation is present and
+ * to sort instances accordingly if so prior to invocation.
+ *
+ * @author Andy Wilkinson
+ * @author Stephane Nicoll
+ * @since 1.3.0
+ */
+@FunctionalInterface
+public interface EnvironmentPostProcessor {
+
+	/**
+	 * Post-process the given {@code environment}.
+	 * @param environment the environment to post-process
+	 * @param application the application to which the environment belongs
+	 */
+	void postProcessEnvironment(ConfigurableEnvironment environment, SpringApplication application);
+
+}
+```
+
+从实现上和作用上来说，和 [《【死磕 Spring】—— IoC 之深入分析 BeanPostProcessor》](http://svip.iocoder.cn/Spring/IoC-BeanPostProcessor/) 都是非常类似的。
+
+EnvironmentPostProcessor 的实现类，如下图所示：[![EnvironmentPostProcessor 实现类](14-Spring Boot 源码分析-配置加载.assets/01.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-01-28/01.jpg)EnvironmentPostProcessor 实现类
+
+## 4.1 CloudFoundryVcapEnvironmentPostProcessor
+
+`org.springframework.boot.cloud.CloudFoundryVcapEnvironmentPostProcessor` ，实现 EnvironmentPostProcessor、Ordered 接口，实现对 [Cloud Foundry](https://www.cloudfoundry.org/) 的支持。因为我们不使用 Cloud Foundry ，所以可以跳过对 CloudFoundryVcapEnvironmentPostProcessor 源码的了解。感兴趣的胖友，可以结合 [《Spring Boot 参考指南（部署到云）》](https://segmentfault.com/a/1190000015088555) 文章，对源码进行研究。
+
+## 4.2 SystemEnvironmentPropertySourceEnvironmentPostProcessor
+
+> 艿艿：选看~
+
+`org.springframework.boot.env.SystemEnvironmentPropertySourceEnvironmentPostProcessor` ，实现 EnvironmentPostProcessor、Ordered 接口，实现将 `environment` 中的 `systemEnvironment` 对应的 PropertySource 属性源对象，替换成 OriginAwareSystemEnvironmentPropertySource 对象。代码如下：
+
+```
+// SystemEnvironmentPropertySourceEnvironmentPostProcessor.java
+
+@Override
+public void postProcessEnvironment(ConfigurableEnvironment environment, SpringApplication application) {
+    // <1> 获得 systemEnvironment 对应的 PropertySource 属性源
+    String sourceName = StandardEnvironment.SYSTEM_ENVIRONMENT_PROPERTY_SOURCE_NAME;
+    PropertySource<?> propertySource = environment.getPropertySources().get(sourceName);
+    // <2> 将原始的 PropertySource 对象，替换成 OriginAwareSystemEnvironmentPropertySource 对象
+    if (propertySource != null) {
+        replacePropertySource(environment, sourceName, propertySource);
+    }
+}
+
+@SuppressWarnings("unchecked")
+private void replacePropertySource(ConfigurableEnvironment environment, String sourceName, PropertySource<?> propertySource) {
+    Map<String, Object> originalSource = (Map<String, Object>) propertySource.getSource();
+    // 创建 SystemEnvironmentPropertySource 对象
+    SystemEnvironmentPropertySource source = new OriginAwareSystemEnvironmentPropertySource(sourceName, originalSource);
+    // 进行替换
+    environment.getPropertySources().replace(sourceName, source);
+}
+```
+
+- `<1>` 处，获得 `systemEnvironment` 对应的 PropertySource 属性源。
+
+- `<2>` 处，调用 `#replacePropertySource(...)` 方法，将原始的 PropertySource 对象，替换成 OriginAwareSystemEnvironmentPropertySource 对象。
+
+- 其中，OriginAwareSystemEnvironmentPropertySource 是 SystemEnvironmentPropertySourceEnvironmentPostProcessor 内部类，继承 SystemEnvironmentPropertySource 类，实现 OriginLookup 接口，代码如下：
+
+  ```
+  // SystemEnvironmentPropertySourceEnvironmentPostProcessor#OriginAwareSystemEnvironmentPropertySource.java
+  protected static class OriginAwareSystemEnvironmentPropertySource
+  		extends SystemEnvironmentPropertySource implements OriginLookup<String> {
+  
+  	OriginAwareSystemEnvironmentPropertySource(String name, Map<String, Object> source) {
+  		super(name, source);
+  	}
+  
+  	@Override
+  	public Origin getOrigin(String key) {
+  	    // 解析 key 对应的 property
+  		String property = resolvePropertyName(key);
+  		// 判断是否存在 property 对应的值。如果存在，则返回 SystemEnvironmentOrigin 对象
+  		if (super.containsProperty(property)) {
+  			return new SystemEnvironmentOrigin(property);
+  		}
+  		// 不存在，则返回 null
+  		return null;
+  	}
+  
+  }
+  ```
+
+  - 重心是对 [`org.springframework.boot.origin.OriginLookup`](https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/origin/OriginLookup.java) 接口的 `#getOrigin(String key)` 方法的实现，实现查找 `key` 对应的真正的 `property` 。难道两者还会不同，答案是的。例如说：传入的 `key=foo.bar.baz` ，返回的是 `property=FOO_BAR_BAZ` 。
+
+  - 答案见 `SystemEnvironmentPropertySource#checkPropertyName(String name)` 方法，内部会进行各种灵活的替换“查找”。代码如下：
+
+    ```
+    // SystemEnvironmentPropertySource.java
+    
+    @Nullable
+    private String checkPropertyName(String name) {
+    	// Check name as-is
+    	if (containsKey(name)) {
+    		return name;
+    	}
+    	// Check name with just dots replaced
+    	String noDotName = name.replace('.', '_');
+    	if (!name.equals(noDotName) && containsKey(noDotName)) {
+    		return noDotName;
+    	}
+    	// Check name with just hyphens replaced
+    	String noHyphenName = name.replace('-', '_');
+    	if (!name.equals(noHyphenName) && containsKey(noHyphenName)) {
+    		return noHyphenName;
+    	}
+    	// Check name with dots and hyphens replaced
+    	String noDotNoHyphenName = noDotName.replace('-', '_');
+    	if (!noDotName.equals(noDotNoHyphenName) && containsKey(noDotNoHyphenName)) {
+    		return noDotNoHyphenName;
+    	}
+    	// Give up
+    	return null;
+    }
+    ```
+
+    - 各种符号，转成 `_` 来查找对应的属性。
+
+😈 那么具体有什么样的逻辑上的需要呢？暂时还没怎么看到，嘿嘿。所以，知道就好，暂时先不去深究。
+
+## 4.3 SpringApplicationJsonEnvironmentPostProcessor
+
+> 艿艿：选看~
+
+`org.springframework.boot.env.SpringApplicationJsonEnvironmentPostProcessor` ，实现 EnvironmentPostProcessor、Ordered 接口，解析 `environment` 中的 `spring.application.json` 或 `SPRING_APPLICATION_JSON` 对应的 JSON 格式的属性值，创建新的 PropertySource 对象，添加到其中。代码如下：
+
+```
+// SpringApplicationJsonEnvironmentPostProcessor.java
+
+/**
+ * 默认的 {@link #order} 的值
+ *
+ * The default order for the processor.
+ */
+public static final int DEFAULT_ORDER = Ordered.HIGHEST_PRECEDENCE + 5;
+
+/**
+ * 顺序
+ */
+private int order = DEFAULT_ORDER;
+
+@Override
+public void postProcessEnvironment(ConfigurableEnvironment environment, SpringApplication application) {
+	MutablePropertySources propertySources = environment.getPropertySources();
+	propertySources.stream().map(JsonPropertyValue::get).filter(Objects::nonNull)
+			.findFirst().ifPresent((v) -> processJson(environment, v));
+}
+```
+
+- `map(JsonPropertyValue::get).filter(Objects::nonNull)` 代码段，调用 `JsonPropertyValue#get(PropertySource<?> propertySource)` 方法，`environment` 中的 `spring.application.json` 或 `SPRING_APPLICATION_JSON` 对应的 JSON 格式的属性值。代码如下：
+
+  ```
+  // SpringApplicationJsonEnvironmentPostProcessor.java
+  
+  public static final String SPRING_APPLICATION_JSON_PROPERTY = "spring.application.json";
+  public static final String SPRING_APPLICATION_JSON_ENVIRONMENT_VARIABLE = "SPRING_APPLICATION_JSON";
+  
+  private static class JsonPropertyValue {
+  
+      private static final String[] CANDIDATES = { SPRING_APPLICATION_JSON_PROPERTY, SPRING_APPLICATION_JSON_ENVIRONMENT_VARIABLE };
+  
+      private final PropertySource<?> propertySource;
+  
+      private final String propertyName;
+  
+      private final String json;
+  
+      JsonPropertyValue(PropertySource<?> propertySource, String propertyName, String json) {
+          this.propertySource = propertySource;
+          this.propertyName = propertyName;
+          this.json = json;
+      }
+  
+      public String getJson() {
+          return this.json;
+      }
+  
+      public Origin getOrigin() {
+          return PropertySourceOrigin.get(this.propertySource, this.propertyName);
+      }
+  
+      public static JsonPropertyValue get(PropertySource<?> propertySource) {
+          // 遍历 CANDIDATES 数组
+          for (String candidate : CANDIDATES) {
+              // 获得 candidate 对应的属性值
+              Object value = propertySource.getProperty(candidate);
+              if (value instanceof String
+                      && StringUtils.hasLength((String) value)) {
+                  // 创建 JsonPropertyValue 对象，然后返回
+                  return new JsonPropertyValue(propertySource, candidate, (String) value);
+              }
+          }
+          return null;
+      }
+  
+  }
+  ```
+
+  - 比较简单，胖友看下就明白列。
+
+- 调用 `#processJson(ConfigurableEnvironment environment, JsonPropertyValue propertyValue)` 方法，执行处理 JSON 字符串。详细解析，见 [「4.3.1 processJson」](https://svip.iocoder.cn/Spring-Boot/properties-load/#) 。
+
+### 4.3.1 processJson
+
+`#processJson(ConfigurableEnvironment environment, JsonPropertyValue propertyValue)` 方法，执行处理 JSON 字符串。代码如下：
+
+```
+// SpringApplicationJsonEnvironmentPostProcessor.java
+
+private void processJson(ConfigurableEnvironment environment, JsonPropertyValue propertyValue) {
+    // <1> 解析 json 字符串，成 Map 对象
+    JsonParser parser = JsonParserFactory.getJsonParser();
+    Map<String, Object> map = parser.parseMap(propertyValue.getJson());
+    // <2> 创建 JsonPropertySource 对象，添加到 environment 中
+    if (!map.isEmpty()) {
+        // <2.2>
+        addJsonPropertySource(environment, new JsonPropertySource(propertyValue, flatten(map))); // <2.1>
+    }
+}
+```
+
+- `<1>` 处，解析 json 字符串，成 Map 对象。
+
+- `<2>` 处，创建 JsonPropertySource 对象，添加到 `environment` 中。其中，JsonPropertySource 继承 MapPropertySource 类，实现 OriginLookup 接口，代码如下：
+
+  ```
+  // SpringApplicationJsonEnvironmentPostProcessor#JsonPropertySource.java
+  
+  private static class JsonPropertySource extends MapPropertySource
+  		implements OriginLookup<String> {
+  
+  	private final JsonPropertyValue propertyValue;
+  
+  	JsonPropertySource(JsonPropertyValue propertyValue, Map<String, Object> source) {
+  		super(SPRING_APPLICATION_JSON_PROPERTY, source);
+  		this.propertyValue = propertyValue;
+  	}
+  
+  	@Override
+  	public Origin getOrigin(String key) {
+  		return this.propertyValue.getOrigin();
+  	}
+  
+  }
+  ```
+
+  - 使用的 `name` 为 `SPRING_APPLICATION_JSON_PROPERTY=spring.application.json` 。
+
+- `<2.1>` 处，调用 `#flatten(String prefix, Map<String, Object> result, Map<String, Object> map)` 方法，将 JSON 解析后的 Map 可能存在的内嵌的 Map 对象，转换成多条 KV 格式的配置对。代码如下：
+
+  ```
+  // SpringApplicationJsonEnvironmentPostProcessor.java
+  
+  private Map<String, Object> flatten(Map<String, Object> map) {
+      Map<String, Object> result = new LinkedHashMap<>();
+      flatten(null, result, map);
+      return result;
+  }
+  
+  private void flatten(String prefix, Map<String, Object> result, Map<String, Object> map) {
+      String namePrefix = (prefix != null) ? prefix + "." : "";
+      map.forEach((key, value) -> extract(namePrefix + key, result, value));
+  }
+  
+  @SuppressWarnings("unchecked")
+  private void extract(String name, Map<String, Object> result, Object value) {
+      if (value instanceof Map) { // 内嵌的 Map 格式
+          flatten(name, result, (Map<String, Object>) value);
+      } else if (value instanceof Collection) { // 内嵌的 Collection
+          int index = 0;
+          for (Object object : (Collection<Object>) value) {
+              extract(name + "[" + index + "]", result, object);
+              index++;
+          }
+      } else { // 普通格式，添加到 result 中
+          result.put(name, value);
+      }
+  }
+  ```
+
+- `<2.2>` 处，调用 `#addJsonPropertySource(ConfigurableEnvironment environment, PropertySource<?> source)` 方法，添加到 `environment` 中。代码如下：
+
+  ```
+  // SpringApplicationJsonEnvironmentPostProcessor.java
+  
+  private void addJsonPropertySource(ConfigurableEnvironment environment, PropertySource<?> source) {
+      MutablePropertySources sources = environment.getPropertySources();
+      // 获得需要添加到 source 所在的 PropertySource 之前的名字
+      String name = findPropertySource(sources);
+      // 添加到 environment 的 sources 中。
+      // 这么做的效果是，source 高于 SYSTEM_PROPERTIES_PROPERTY_SOURCE_NAME && JNDI_PROPERTY_SOURCE_NAME 之前
+      if (sources.contains(name)) {
+          sources.addBefore(name, source);
+      } else {
+          sources.addFirst(source);
+      }
+  }
+  
+  private String findPropertySource(MutablePropertySources sources) {
+      // 在 Servlet 环境下，且有 JNDI_PROPERTY_SOURCE_NAME 属性，则返回 StandardServletEnvironment.JNDI_PROPERTY_SOURCE_NAME
+      if (ClassUtils.isPresent(SERVLET_ENVIRONMENT_CLASS, null)
+              && sources.contains(StandardServletEnvironment.JNDI_PROPERTY_SOURCE_NAME)) {
+          return StandardServletEnvironment.JNDI_PROPERTY_SOURCE_NAME;
+  
+      }
+      // 否则，返回 SYSTEM_PROPERTIES_PROPERTY_SOURCE_NAME 属性
+      return StandardEnvironment.SYSTEM_PROPERTIES_PROPERTY_SOURCE_NAME;
+  }
+  ```
+
+😈 当然，因为绝大多数情况下，我们并不会去使用 `spring.application.json` 或 `SPRING_APPLICATION_JSON` 去进行配置。所以呢，这块逻辑等胖友真的有需要，再来瞅瞅落。
+
+## 4.4 ConfigFileApplicationListener
+
+> 艿艿：真正的重头戏~
+
+实现 `#addPropertySources(ConfigurableEnvironment environment,ResourceLoader resourceLoader)` 方法，代码如下：
+
+```
+// ConfigFileApplicationListener.java
+
+protected void addPropertySources(ConfigurableEnvironment environment,ResourceLoader resourceLoader) {
+    // <1> 添加 RandomValuePropertySource 到 environment 中
+    RandomValuePropertySource.addToEnvironment(environment);
+    // <2> 创建 Loader 对象，进行加载
+    new Loader(environment, resourceLoader).load();
+}
+```
+
+- `<1>` 处，添加 RandomValuePropertySource 到 `environment` 中。详细解析，见 [「5. RandomValuePropertySource」](https://svip.iocoder.cn/Spring-Boot/properties-load/#) 中。
+- `<2>` 处，创建 Loader 对象，并调用 `Loader#load()` 方法，进行加载。详细解析，见 [「4.4.1 Loader」](https://svip.iocoder.cn/Spring-Boot/properties-load/#) 中。
+
+### 4.4.1 Loader
+
+> 艿艿：高能预警，关于这一块，内容会比较扎实（很多）！
+
+Loader 是 ConfigFileApplicationListener 的内部类，负责加载指定的配置文件。构造方法如下：
+
+```
+// ConfigFileApplicationListener.java
+
+private class Loader {
+
+    private final Log logger = ConfigFileApplicationListener.this.logger;
+
+    private final ConfigurableEnvironment environment;
+
+    private final PropertySourcesPlaceholdersResolver placeholdersResolver;
+
+    private final ResourceLoader resourceLoader;
+
+    private final List<PropertySourceLoader> propertySourceLoaders;
+
+    private Deque<Profile> profiles;
+
+    private List<Profile> processedProfiles;
+
+    private boolean activatedProfiles;
+
+    private Map<Profile, MutablePropertySources> loaded;
+
+    private Map<DocumentsCacheKey, List<Document>> loadDocumentsCache = new HashMap<>();
+
+    Loader(ConfigurableEnvironment environment, ResourceLoader resourceLoader) {
+        this.environment = environment;
+        // <1> 创建 PropertySourcesPlaceholdersResolver 对象
+        this.placeholdersResolver = new PropertySourcesPlaceholdersResolver(this.environment);
+        // <2> 创建 DefaultResourceLoader 对象
+        this.resourceLoader = (resourceLoader != null) ? resourceLoader : new DefaultResourceLoader();
+        // <3> 加载指定类型 PropertySourceLoader 对应的，在 `META-INF/spring.factories` 里的类名的数组
+        this.propertySourceLoaders = SpringFactoriesLoader.loadFactories(PropertySourceLoader.class, getClass().getClassLoader());
+    }
+    
+    // ... 省略其它方法
+}
+```
+
+- `<1>` 处，创建 PropertySourcesPlaceholdersResolver 对象。详细解析，胖友可以跳到 [「6. PropertySourcesPlaceholdersResolver」](https://svip.iocoder.cn/Spring-Boot/properties-load/#) 中，瞅一眼，然后继续回到此处。
+
+- `<2>` 处，创建 DefaultResourceLoader 对象。这个是 Spring Framework 中的类，用于资源的加载。当然，这不是本文的重点，暂时先忽略。
+
+- ```
+  <3>
+  ```
+
+   
+
+  处，加载指定类型 PropertySourceLoader 对应的，在
+
+   
+
+  ```
+  META-INF/spring.factories
+  ```
+
+   
+
+  里的类名的数组。
+
+  - 默认情况下，返回的是 PropertiesPropertySourceLoader、YamlPropertySourceLoader 类。详细解析，见 [「7. PropertySourceLoader」](https://svip.iocoder.cn/Spring-Boot/properties-load/#) 。
+
+#### 4.4.1.1 load
+
+`#load()` 方法，加载配置。代码如下：
+
+```
+// ConfigFileApplicationListener#Loader.java
+
+public void load() {
+    // <1> 初始化变量
+    this.profiles = new LinkedList<>(); // 未处理的 Profile 集合
+    this.processedProfiles = new LinkedList<>(); // 已处理的 Profile 集合
+    this.activatedProfiles = false;
+    this.loaded = new LinkedHashMap<>();
+    // <2> 初始化 Spring Profiles 相关
+    initializeProfiles();
+    // <3> 遍历 profiles 数组
+    while (!this.profiles.isEmpty()) {
+        // 获得 Profile 对象
+        Profile profile = this.profiles.poll();
+        // <3.1> 添加 Profile 到 environment 中
+        if (profile != null && !profile.isDefaultProfile()) {
+            addProfileToEnvironment(profile.getName());
+        }
+        // <3.2> 加载配置
+        load(profile, this::getPositiveProfileFilter,
+                addToLoaded(MutablePropertySources::addLast, false));
+        // <3.3> 添加到 processedProfiles 中，表示已处理
+        this.processedProfiles.add(profile);
+    }
+    // <4> 获得真正加载的 Profile 们，添加到 environment 中。
+    resetEnvironmentProfiles(this.processedProfiles);
+    // <5> 加载配置
+    load(null, this::getNegativeProfileFilter,
+            addToLoaded(MutablePropertySources::addFirst, true));
+    // <6> 将加载的配置对应的 MutablePropertySources 到 environment 中
+    addLoadedPropertySources();
+}
+```
+
+- `<1>` 处，初始化变量。每个变量的意思，看代码中的注释。
+
+- `<2>` 处，初始化 Spring Profiles 相关。详细解析，见 [「4.4.1.1 initializeProfiles」](https://svip.iocoder.cn/Spring-Boot/properties-load/#) 中。胖友可以先跳过去看一眼，然后回来。
+
+- `<3>` 处，遍历 `profiles` 数组，逐个加载对应的配置文件。
+
+  - `<3.1>` 处，调用 `#addProfileToEnvironment(String profile)` 方法，添加到 `environment.activeProfiles` 中。代码如下：
+
+    ```
+    // ConfigFileApplicationListener#Loader.java
+    
+    private void addProfileToEnvironment(String profile) {
+        // 如果已经在 activeProfiles 中，则返回
+        for (String activeProfile : this.environment.getActiveProfiles()) {
+            if (activeProfile.equals(profile)) {
+                return;
+            }
+        }
+        // 如果不在，则添加到 environment 中
+        this.environment.addActiveProfile(profile);
+    }
+    ```
+
+    - ~
+
+  - `<3.2>` 处，调用 `#load(Profile profile, DocumentFilterFactory filterFactory, DocumentConsumer consumer)` 方法，加载配置。这块会比较复杂，晚点再求看 [「4.4.1.1.2 load」](https://svip.iocoder.cn/Spring-Boot/properties-load/#) 。
+
+  - `<3.3>` 处，添加到 `processedProfiles` 中，表示已处理。
+
+- `<4>` 处，调用 `#resetEnvironmentProfiles(List<Profile> processedProfiles)` 方法，获得真正加载的 Profile 们，添加到 environment 中。代码如下：
+
+  ```
+  // ConfigFileApplicationListener#Loader.java
+  
+  private void resetEnvironmentProfiles(List<Profile> processedProfiles) {
+      // 获得真正加载的 Profile 们，添加到 environment 中。
+      String[] names = processedProfiles.stream()
+              .filter((profile) -> profile != null && !profile.isDefaultProfile())
+              .map(Profile::getName).toArray(String[]::new);
+      this.environment.setActiveProfiles(names);
+  }
+  ```
+
+  - 因为每个 Profile 可能不存在对应的配置文件，只有真正加载到配置文件的 Profile 们，才会设置到 `environment.activeProfiles` 属性中。
+
+- `<5>` 处，调用 `#load(Profile profile, DocumentFilterFactory filterFactory, DocumentConsumer consumer)` 方法，加载配置。这块会比较复杂，晚点再求看 [「4.4.1.1.2 load」](https://svip.iocoder.cn/Spring-Boot/properties-load/#) 。
+
+  - 和 `<3.2>` 处，有一些不同，主要差别在于传入的方法参数。
+  - 在补充一点，有点不造怎么解释了。😈 `<5>` 处的作用是，将 `profile=null` 的情况中，将配置文件里有配置文件 `spring.profiles` 内容，且属于基于的 Profile ，也添加到 `profile=null` 在 `Loader.loaded` 的映射中。具体的，可以看 [「666. 彩蛋」](https://svip.iocoder.cn/Spring-Boot/properties-load/#) 提供的示例。😈 真的是，好绕啊！！！！
+
+- `<6>` 处，调用 `#addLoadedPropertySources()` 方法，将加载的配置对应的 MutablePropertySources 到 `environment` 中。代码如下：
+
+  ```
+  // ConfigFileApplicationListener.java
+  
+  private static final String DEFAULT_PROPERTIES = "defaultProperties";
+  
+  // ConfigFileApplicationListener#Loader.java
+  
+  private void addLoadedPropertySources() {
+      MutablePropertySources destination = this.environment.getPropertySources();
+      // 获得当前加载的 MutablePropertySources 集合
+      List<MutablePropertySources> loaded = new ArrayList<>(this.loaded.values());
+      Collections.reverse(loaded); // <Z>
+      // 声明变量
+      String lastAdded = null; // 下面循环，最后找到的 MutablePropertySources 的名字
+      Set<String> added = new HashSet<>(); // 已添加到 destination 中的 MutablePropertySources 的名字的集合
+      // <X> 遍历 loaded 数组
+      for (MutablePropertySources sources : loaded) {
+          // <Y> 遍历 sources 数组
+          for (PropertySource<?> source : sources) {
+              // 添加到 destination 中
+              if (added.add(source.getName())) {
+                  addLoadedPropertySource(destination, lastAdded, source);
+                  lastAdded = source.getName();
+              }
+          }
+      }
+  }
+  
+  private void addLoadedPropertySource(MutablePropertySources destination, String lastAdded, PropertySource<?> source) {
+      if (lastAdded == null) {
+          if (destination.contains(DEFAULT_PROPERTIES)) {
+              destination.addBefore(DEFAULT_PROPERTIES, source);
+          } else {
+              destination.addLast(source);
+          }
+      } else {
+          destination.addAfter(lastAdded, source);
+      }
+  }
+  ```
+
+  - `<X>` 和 `<Y>` 处，为什么是两层遍历呢？因为一个 Profile 可以对应多个配置文件。例如说，Profile 为 `prod` ，对应 `applicaion-prod.properties` 和 `application-prod.yml` 两个配置文件。
+  - 这样，我们就可以从 `environment` 中，读取加载到的配置文件。
+  - `<Z>` 处，为什么要反转一下呢？因为，配置在越后面的 Profile ，优先级越高，所以需要进行反转。举个例子 `spring.profiles.active=prod,dev` ，那么 Profile 的优先级是 `dev > prod > null` 。
+
+下面，我们就可以跳到 [「4.4.1.1.2 load」](https://svip.iocoder.cn/Spring-Boot/properties-load/#) 小节，看看这个关键的逻辑。
+
+> 艿艿：逻辑真的有点复杂！目的简单，过程中的逻辑细节比较多。和我一起，保持耐心！！！
+
+##### 4.4.1.1.1 initializeProfiles
+
+在 `#initializeProfiles()` 方法之前，我们先来看 Profile 类。它是 ConfigFileApplicationListener 的内部类，是 Spring Profiles 的封装对象。代码如下：
+
+```
+// ConfigFileApplicationListener#Profile.java
+
+/**
+ * A Spring Profile that can be loaded.
+ */
+private static class Profile {
+
+    /**
+     * Profile 名字
+     */
+	private final String name;
+    /**
+     * 是否为默认的 Profile
+     */
+	private final boolean defaultProfile;
+
+    // ... 省略构造方法、getting 方法、toString 和 hashCode 方法
+
+}
+```
+
+然后，继续来看 `#initializeProfiles()` 方法，初始化 Spring Profiles 相关。代码如下：
+
+```
+// ConfigFileApplicationListener#Loader.java
+
+private void initializeProfiles() {
+    // The default profile for these purposes is represented as null. We add it
+    // first so that it is processed first and has lowest priority.
+    // <1> 添加 null 到 profiles 中。用于加载默认的配置文件。优先添加到 profiles 中，因为希望默认的配置文件先被处理。
+    this.profiles.add(null);
+    // <2.1> 获得激活的 Profile 们（从配置中）
+    Set<Profile> activatedViaProperty = getProfilesActivatedViaProperty();
+    // <2.2> 先添加激活的 Profile 们（不在配置中）
+    this.profiles.addAll(getOtherActiveProfiles(activatedViaProperty));
+    // Any pre-existing active profiles set via property sources (e.g.
+    // System properties) take precedence over those added in config files.
+    // <2.3> 再添加激活的 Profile 们（在配置中）
+    addActiveProfiles(activatedViaProperty);
+    // <3> 如果没有激活的 Profile 们，则添加默认的 Profile
+    if (this.profiles.size() == 1) { // only has null profile
+        for (String defaultProfileName : this.environment.getDefaultProfiles()) {
+            Profile defaultProfile = new Profile(defaultProfileName, true);
+            this.profiles.add(defaultProfile);
+        }
+    }
+}
+```
+
+- `<1>` 处，添加 `null` 到 `profiles` 中。用于加载默认的配置文件。优先添加到 `profiles` 中，因为希望默认的配置文件先被处理。
+
+- `<2.1>` 处，调用 `#getProfilesActivatedViaProperty()` 方法，获得激活的 Profile 们（从配置中）。代码如下：
+
+  ```
+  // ConfigFileApplicationListener#Loader.java
+  
+  private Set<Profile> getProfilesActivatedViaProperty() {
+  	if (!this.environment.containsProperty(ACTIVE_PROFILES_PROPERTY)
+  			&& !this.environment.containsProperty(INCLUDE_PROFILES_PROPERTY)) {
+  		return Collections.emptySet();
+  	}
+  	Binder binder = Binder.get(this.environment);
+  	Set<Profile> activeProfiles = new LinkedHashSet<>();
+  	activeProfiles.addAll(getProfiles(binder, INCLUDE_PROFILES_PROPERTY)); // spring.profiles.include
+  	activeProfiles.addAll(getProfiles(binder, ACTIVE_PROFILES_PROPERTY)); // spring.profiles.active
+  	return activeProfiles;
+  }
+  ```
+
+  - 读取 `"spring.profiles.include"` 和 `"spring.profiles.active"` 对应的 Profile 们。
+
+- `<2.2>` 处，调用 `#getOtherActiveProfiles(Set<Profile> activatedViaProperty)` 方法，先添加激活的 Profile 们（**不在配置中**）到 `profiles` 中。代码如下：
+
+  ```
+  // ConfigFileApplicationListener#Loader.java
+  
+  private List<Profile> getOtherActiveProfiles(Set<Profile> activatedViaProperty) {
+  	return Arrays.stream(this.environment.getActiveProfiles()).map(Profile::new)
+  			.filter((profile) -> !activatedViaProperty.contains(profile))
+  			.collect(Collectors.toList());
+  }
+  ```
+
+  - “**不在配置中**”，例如说：`SpringApplication.additionalProfiles` 。
+
+- `<2.3>` 处，调用 `#addActiveProfiles(Set<Profile> profiles)` 方法，再添加激活的 Profile 们（在配置中）到 `profiles` 中。代码如下：
+
+  ```
+  // ConfigFileApplicationListener#Loader.java
+  
+  void addActiveProfiles(Set<Profile> profiles) {
+      if (profiles.isEmpty()) {
+          return;
+      }
+      // 如果已经标记 activatedProfiles 为 true ，则直接返回
+      if (this.activatedProfiles) {
+          if (this.logger.isDebugEnabled()) {
+              this.logger.debug("Profiles already activated, '" + profiles + "' will not be applied");
+          }
+          return;
+      }
+      // 添加到 profiles 中
+      this.profiles.addAll(profiles);
+      if (this.logger.isDebugEnabled()) {
+          this.logger.debug("Activated activeProfiles " + StringUtils.collectionToCommaDelimitedString(profiles));
+      }
+      // 标记 activatedProfiles 为 true 。
+      this.activatedProfiles = true;
+      // 移除 profiles 中，默认的配置们。
+      removeUnprocessedDefaultProfiles();
+  }
+  
+  private void removeUnprocessedDefaultProfiles() {
+      this.profiles.removeIf(
+              (profile) -> (profile != null && profile.isDefaultProfile()));
+  }
+  ```
+
+- `<3>` 处，如果没有激活的 Profile 们，则添加默认的 Profile 。此处的“默认”是，指的是配置文件中的 `"spring.profiles.default"` 对应的值。
+
+- 这块比较绕，胖友最好自己调试下。例如说，我们在 JVM 启动增加 `--spring.profiles.active=prod` ，则结果如下图：[![`profiles`](14-Spring Boot 源码分析-配置加载.assets/02.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-01-28/02.jpg)`profiles`
+
+##### 4.4.1.1.2 load
+
+`#load(Profile profile, DocumentFilterFactory filterFactory, DocumentConsumer consumer)` 方法，加载指定 Profile 的配置文件。代码如下：
+
+```
+// ConfigFileApplicationListener#Loader.java
+
+private void load(Profile profile, DocumentFilterFactory filterFactory, DocumentConsumer consumer) {
+    // <1> 获得要检索配置的路径
+    getSearchLocations().forEach((location) -> {
+        // 判断是否为文件夹
+        boolean isFolder = location.endsWith("/");
+        // <2> 获得要检索配置的文件名集合
+        Set<String> names = isFolder ? getSearchNames() : NO_SEARCH_NAMES;
+        // <3> 遍历文件名集合，逐个加载配置文件
+        names.forEach(
+                (name) -> load(location, name, profile, filterFactory, consumer));
+    });
+}
+```
+
+- `<1>` 处，调用 `#getSearchLocations()` 方法，获得要检索配置的路径们。代码如下：
+
+  ```
+  // ConfigFileApplicationListener.java
+  
+  // Note the order is from least to most specific (last one wins)
+  private static final String DEFAULT_SEARCH_LOCATIONS = "classpath:/,classpath:/config/,file:./,file:./config/";
+  
+  /**
+   * The "config location" property name.
+   */
+  public static final String CONFIG_LOCATION_PROPERTY = "spring.config.location";
+  /**
+   * The "config additional location" property name.
+   */
+  public static final String CONFIG_ADDITIONAL_LOCATION_PROPERTY = "spring.config.additional-location";
+  
+  // ConfigFileApplicationListener#Loader.java
+  
+  private Set<String> getSearchLocations() {
+      // 获得 `"spring.config.location"` 对应的配置的值
+      if (this.environment.containsProperty(CONFIG_LOCATION_PROPERTY)) {
+          return getSearchLocations(CONFIG_LOCATION_PROPERTY);
+      }
+      // 获得 `"spring.config.additional-location"` 对应的配置的值
+      Set<String> locations = getSearchLocations(CONFIG_ADDITIONAL_LOCATION_PROPERTY);
+      // 添加 searchLocations 到 locations 中
+      locations.addAll(asResolvedSet(ConfigFileApplicationListener.this.searchLocations, DEFAULT_SEARCH_LOCATIONS));
+      return locations;
+  }
+  
+  private Set<String> getSearchLocations(String propertyName) {
+      Set<String> locations = new LinkedHashSet<>();
+      // 如果 environment 中存在 propertyName 对应的值
+      if (this.environment.containsProperty(propertyName)) {
+          // 读取属性值，进行分割后，然后遍历
+          for (String path : asResolvedSet(this.environment.getProperty(propertyName), null)) {
+              // 处理 path
+              if (!path.contains("$")) {
+                  path = StringUtils.cleanPath(path);
+                  if (!ResourceUtils.isUrl(path)) {
+                      path = ResourceUtils.FILE_URL_PREFIX + path;
+                  }
+              }
+              // 添加到 path 中
+              locations.add(path);
+          }
+      }
+      return locations;
+  }
+  
+  // 优先使用 value 。如果 value 为空，则使用 fallback
+  private Set<String> asResolvedSet(String value, String fallback) {
+      List<String> list = Arrays.asList(StringUtils.trimArrayElements(
+              StringUtils.commaDelimitedListToStringArray((value != null)
+                      ? this.environment.resolvePlaceholders(value) : fallback)));
+      Collections.reverse(list);
+      return new LinkedHashSet<>(list);
+  }
+  ```
+
+  - 看似比较长，逻辑并不复杂。
+  - 如果配置了 `"spring.config.location"` ，则使用它的值，作为要检索配置的路径。
+  - 如果配置了 `"spring.config.additional-location"` ，则使用它作为**附加**要检索配置的路径。当然，还是会添加默认的 `DEFAULT_SEARCH_LOCATIONS` 路径。
+  - 默认情况下，返回的值是 `DEFAULT_SEARCH_LOCATIONS` 。因为，绝大数情况，我们并不会做相应的配置。😈 所以，胖友如果懒的看逻辑，就记得这个结论就可以了。
+
+- `<2>` 处，调用 `#getSearchNames()` 方法，获得要检索配置的文件名集合。代码如下：
+
+  ```
+  // ConfigFileApplicationListener.java
+  
+  private static final String DEFAULT_NAMES = "application";
+  
+  private static final Set<String> NO_SEARCH_NAMES = Collections.singleton(null);
+  
+  public static final String CONFIG_NAME_PROPERTY = "spring.config.name";
+  
+  // ConfigFileApplicationListener#Loader.java
+  
+  private Set<String> getSearchNames() {
+      // 获得 `"spring.config.name"` 对应的配置的值
+      if (this.environment.containsProperty(CONFIG_NAME_PROPERTY)) {
+          String property = this.environment.getProperty(CONFIG_NAME_PROPERTY);
+          return asResolvedSet(property, null);
+      }
+      // 添加 names or DEFAULT_NAMES 到 locations 中
+      return asResolvedSet(ConfigFileApplicationListener.this.names, DEFAULT_NAMES);
+  }
+  ```
+
+  - 通过 `DEFAULT_NAMES` 静态属性，我们可以知道，默认都去的配置文件名（不考虑后缀）为 `"application"` 。
+  - 剩余的逻辑，胖友简单看看即可。
+  - 默认情况下，返回的值是 `DEFAULT_NAMES` 。因为，绝大数情况，我们并不会做相应的配置。😈 所以，胖友如果懒的看逻辑，就记得这个结论就可以了。
+
+- `<3>` 处，遍历 `names` 数组，逐个调用 `#load(String location, String name, Profile profile, DocumentFilterFactory filterFactory, DocumentConsumer consumer)` 方法，逐个加载 Profile 指定的配置文件。详细解析，见 [「4.4.1.1.3 load」](https://svip.iocoder.cn/Spring-Boot/properties-load/#) 。
+
+##### 4.4.1.1.3 load
+
+`#load(String location, String name, Profile profile, DocumentFilterFactory filterFactory, DocumentConsumer consumer)` 方法，逐个加载 Profile 指定的配置文件。代码如下：
+
+```
+// ConfigFileApplicationListener#Loader.java
+
+private void load(String location, String name, Profile profile, DocumentFilterFactory filterFactory, DocumentConsumer consumer) {
+    // <1> 这块逻辑先无视，因为我们不会配置 name 为空。
+    // 默认情况下，name 为 DEFAULT_NAMES=application
+    if (!StringUtils.hasText(name)) {
+        for (PropertySourceLoader loader : this.propertySourceLoaders) {
+            if (canLoadFileExtension(loader, location)) {
+                load(loader, location, profile, filterFactory.getDocumentFilter(profile), consumer);
+                return;
+            }
+        }
+    }
+    Set<String> processed = new HashSet<>(); // 已处理的文件后缀集合
+    // <2> 遍历 propertySourceLoaders 数组，逐个使用 PropertySourceLoader 读取配置
+    for (PropertySourceLoader loader : this.propertySourceLoaders) {
+        // <3> 遍历每个 PropertySourceLoader 可处理的文件后缀集合
+        for (String fileExtension : loader.getFileExtensions()) {
+            // <4> 添加到 processed 中，一个文件后缀，有且仅能被一个 PropertySourceLoader 所处理
+            if (processed.add(fileExtension)) {
+                // 加载 Profile 指定的配置文件（带后缀）
+                loadForFileExtension(loader, location + name, "." + fileExtension,
+                        profile, filterFactory, consumer);
+            }
+        }
+    }
+}
+```
+
+- `<1>` 处的逻辑，可以无视。具体的原因，见我添加的注释。
+- `<2>` 处，遍历 `propertySourceLoaders` 数组，逐个使用 PropertySourceLoader 读取配置。
+- `<3>` 处，遍历每个 PropertySourceLoader 可处理的文件后缀集合。例如说，PropertiesPropertySourceLoader 可处理 `.properties` 和 `.xml` 后缀，YamlPropertySourceLoader 可处理 `.yml` 和 `.yaml` 后置。
+- `<4>` 处，添加到 `processed` 中。一个文件后缀，有且仅能被一个 PropertySourceLoader 所处理。
+- `<5>` 处，调用 `#loadForFileExtension(PropertySourceLoader loader, String prefix, String fileExtension, Profile profile, DocumentFilterFactory filterFactory, DocumentConsumer consumer)` 方法，加载 Profile 指定的配置文件（带后缀）。详细解析，见 [「4.4.1.1.7 loadForFileExtension」](https://svip.iocoder.cn/Spring-Boot/properties-load/#) 。
+
+##### 4.4.1.1.4 Document
+
+> 因为稍后在讲解 `#loadForFileExtension(...)` 方法需要用到，所以插播下。
+
+Document ，是 ConfigFileApplicationListener 的内部类，用于封装 PropertySourceLoader 加载配置文件后。代码如下：
+
+```
+// ConfigFileApplicationListener#Document.java
+
+private static class Document {
+
+    private final PropertySource<?> propertySource;
+
+    /**
+     * 对应 `spring.profiles` 属性值
+     */
+    private String[] profiles;
+
+    /**
+     * 对应 `spring.profiles.active` 属性值
+     */
+    private final Set<Profile> activeProfiles;
+
+    /**
+     * 对应 `spring.profiles.include` 属性值
+     */
+    private final Set<Profile> includeProfiles;
+}
+```
+
+###### 4.4.1.1.4.1 DocumentsCacheKey
+
+DocumentsCacheKey ，是 ConfigFileApplicationListener 的内部类，用于表示加载 Documents 的缓存 KEY 。代码如下：
+
+```
+// ConfigFileApplicationListener#DocumentsCacheKey.java
+
+/**
+ * Cache key used to save loading the same document multiple times.
+ */
+private static class DocumentsCacheKey {
+
+	private final PropertySourceLoader loader;
+
+	private final Resource resource;
+
+	DocumentsCacheKey(PropertySourceLoader loader, Resource resource) {
+		this.loader = loader;
+		this.resource = resource;
+	}
+
+	@Override
+	public boolean equals(Object obj) {
+		if (this == obj) {
+			return true;
+		}
+		if (obj == null || getClass() != obj.getClass()) {
+			return false;
+		}
+		DocumentsCacheKey other = (DocumentsCacheKey) obj;
+		return this.loader.equals(other.loader)
+				&& this.resource.equals(other.resource);
+	}
+
+	@Override
+	public int hashCode() {
+		return this.loader.hashCode() * 31 + this.resource.hashCode();
+	}
+
+}
+```
+
+- 因为一个配置文件在 [「4.4.1.1.7 loadForFileExtension」](https://svip.iocoder.cn/Spring-Boot/properties-load/#) 方法中，我们会看到可能存在重复加载的情况，所以通过缓存，避免重新读取~
+
+##### 4.4.1.1.5 DocumentFilterFactory
+
+> 因为稍后在讲解 `#loadForFileExtension(...)` 方法需要用到，所以插播下。
+
+DocumentFilterFactory ，是 ConfigFileApplicationListener 的内部接口，用于创建 DocumentFilter 对象。代码如下：
+
+```
+// ConfigFileApplicationListener#DocumentFilterFactory.java
+
+@FunctionalInterface
+private interface DocumentFilterFactory {
+
+	DocumentFilter getDocumentFilter(Profile profile);
+
+}
+```
+
+在 [「4.4.1.1 load」](https://svip.iocoder.cn/Spring-Boot/properties-load/#) 中，我们在该方法中，已经看到它的两个匿名实现类，如下：
+
+```
+// ConfigFileApplicationListener#Loader.java
+
+第一个：this::getPositiveProfileFilter
+第二个：this::getNegativeProfileFilter
+```
+
+- 它们分别调用对应的方法，创建 DocumentFilter 对象。
+
+###### 4.4.1.1.5.1 DocumentFilter
+
+DocumentFilter ，是 ConfigFileApplicationListener 的内部接口，用于匹配配置加载后的 Document 对象。代码如下：
+
+```
+// ConfigFileApplicationListener#DocumentFilter.java
+
+@FunctionalInterface
+private interface DocumentFilter {
+
+	boolean match(Document document);
+
+}
+```
+
+- 在下面的文章中，我们会看到，加载的配置文件后，返回的是 Document 对象。但是，返回的 Document 对象，需要和 Profile 进行匹配。
+
+###### 4.4.1.1.5.2 getPositiveProfileFilter
+
+`#getPositiveProfileFilter(Profile profile)` 方法，代码如下：
+
+```
+// ConfigFileApplicationListener#Loader.java
+
+private DocumentFilter getPositiveProfileFilter(Profile profile) {
+    return (Document document) -> {
+        // <1> 当 profile 为空时，document.profiles 也要为空
+        if (profile == null) {
+            return ObjectUtils.isEmpty(document.getProfiles());
+        }
+        // <2> 要求 document.profiles 包含 profile
+        // 并且，environment.activeProfiles 包含 document.profiles
+        // 总结来说，environment.activeProfiles 包含 document.profiles 包含 profile
+        return ObjectUtils.containsElement(document.getProfiles(), profile.getName())
+                && this.environment.acceptsProfiles(Profiles.of(document.getProfiles()));
+    };
+}
+```
+
+- `<1>` 处，当传入的 `profile` 为空时，要求 `document.profiles` 也要为空。
+- `<2>` 处，当传入的 `profile` 非空时，要求 `environment.activeProfiles` 包含 `document.profiles` 包含 `profile` 。
+
+可能比较绕，胖友先看 [《Spring-boot动态profiles的实践》](https://spldeolin.com/posts/spring-boot-active-profiles/) 文章的 [「Spring Boot的Profiles属性」](https://svip.iocoder.cn/Spring-Boot/properties-load/#) 部分。
+
+- 什么意思呢？假设一个 `application-prod.properties` 的配置文件，一般我们的理解是对应 Profile 为 `prod` 的情况，对吧？！但是，如果说我们在配置文件中增加了 `spring.profiles=dev` ，那它实际是属于 Profile 为 `dev` 的情况。
+
+  > 艿艿：第一次知道还有这样的设定！！！
+
+- 当然，我们绝大都数情况，并不会去定义 `spring.profiles` 属性。所以呢，分成两种情况：
+
+  > 艿艿：仔细理解，我也懵逼了好多小时！！！！
+
+  - `profile` 为 `null` 的情况，处理默认情况，即我们未定义 `spring.profiles` 属性。
+  - `profile` 非 `null` 的情况，处理配置文件中定义了 `spring.profiles` 属性，则需要使用 `profile` 和 `spring.profiles` 匹配，并且它要属于 `environment.activeProfiles` 中已经激活的。
+
+😈 所以呢，我们在 [「4.4.1.1 load」](https://svip.iocoder.cn/Spring-Boot/properties-load/#) 中，看到它是在加载指定 Profile 的配置文件所使用。
+
+###### 4.4.1.1.5.3 getPositiveProfileFilter
+
+`#getPositiveProfileFilter(Profile profile)` 方法，代码如下：
+
+```
+// ConfigFileApplicationListener#Loader.java
+
+private DocumentFilter getNegativeProfileFilter(Profile profile) {
+    return (Document document) -> (profile == null // <1>
+            && !ObjectUtils.isEmpty(document.getProfiles()) // <2> 非空
+            // environment.activeProfiles 包含 document.profiles
+            && this.environment.acceptsProfiles(Profiles.of(document.getProfiles()))); // <3>
+}
+```
+
+- `<1>` 处，要求传入的 `profile` 为空。因为呢，[「4.4.1.1 load」](https://svip.iocoder.cn/Spring-Boot/properties-load/#) 中，看到它是在加载**无 Profile** 的配置文件所使用。
+- `<2>` 处，要求 `document.profiles` 非空。一般情况下，我们在 `application.properties` 中，也并不会填写 `spring.profiles` 属性值。这就是说，这个方法默认基本返回 `false` 。
+- `<3>` 处，`environment.activeProfiles` 包含 `document.profiles` 。
+
+##### 4.4.1.1.6 DocumentConsumer
+
+> 因为稍后在讲解 `#loadForFileExtension(...)` 方法需要用到，所以插播下。
+
+DocumentConsumer ，是 ConfigFileApplicationListener 的内部接口，用于处理传入的 Document 。代码如下：
+
+```
+// ConfigFileApplicationListener#DocumentConsumer.java
+
+/**
+ * Consumer used to handle a loaded {@link Document}.
+ */
+@FunctionalInterface
+private interface DocumentConsumer {
+
+	void accept(Profile profile, Document document);
+
+}
+```
+
+在 [「4.4.1.1 load」](https://svip.iocoder.cn/Spring-Boot/properties-load/#) 中，我们在该方法中，已经看到它的一个匿名实现类，如下：
+
+```
+// ConfigFileApplicationListener#Loader.java
+
+第一个：addToLoaded(MutablePropertySources::addLast, false))
+第二个：addToLoaded(MutablePropertySources::addFirst, true))
+```
+
+- 差别在于传入的
+
+   
+
+  ```
+  #addToLoaded(BiConsumer<MutablePropertySources, PropertySource<?>> addMethod, boolean checkForExisting)
+  ```
+
+   
+
+  方法的
+
+   
+
+  ```
+  addMethod
+  ```
+
+   
+
+  参数不同。为什么呢？
+
+  - 对于有 Profile 的情况，使用前者 `MutablePropertySources::addLast` ，将 Document 的 PropertySource 添加到尾部。
+  - 对于无 Profile 的情况，使用后者 `MutablePropertySources::addFirst` ，将 Document 的 PropertySource 添加到头部。
+  - 最终，我们看到 `#addLoadedPropertySources()` 方法中，会执行 `Collections.reverse(loaded)` 代码段，进行颠倒。为什么呢？这样，就能很巧妙的实现 `application-prod.properties` 的优先级，高于 `application.properties` ，从而实现相同属性时，覆盖读取~，即读取的是 `application-prod.properties` 的属性配置。
+
+###### 4.4.1.1.6.1 addToLoaded
+
+`#addToLoaded(BiConsumer<MutablePropertySources, PropertySource<?>> addMethod, boolean checkForExisting)` 方法，将 Document 的 PropertySource ，添加到 `Loader.loaded` 中。代码如下：
+
+```
+// ConfigFileApplicationListener#Loader.java
+
+private DocumentConsumer addToLoaded(BiConsumer<MutablePropertySources, PropertySource<?>> addMethod, boolean checkForExisting) {
+    // 创建 DocumentConsumer 对象
+    return (profile, document) -> {
+        // 如果要校验已经存在的情况，则如果已经存在，则直接 return
+        if (checkForExisting) {
+            for (MutablePropertySources merged : this.loaded.values()) {
+                if (merged.contains(document.getPropertySource().getName())) {
+                    return;
+                }
+            }
+        }
+        // 获得 profile 对应的 MutablePropertySources 对象
+        MutablePropertySources merged = this.loaded.computeIfAbsent(profile,
+                (k) -> new MutablePropertySources());
+        // 将加载的 document 合并到 merged 中
+        addMethod.accept(merged, document.getPropertySource());
+    };
+}
+```
+
+- 创建了一个 DocumentConsumer 对象。而其内部的逻辑，很简单，胖友自己瞅瞅即可。
+
+##### 4.4.1.1.7 loadForFileExtension
+
+`#loadForFileExtension(PropertySourceLoader loader, String prefix, String fileExtension, Profile profile, DocumentFilterFactory filterFactory, DocumentConsumer consumer)` 方法，加载 Profile 指定的配置文件（带后缀）。代码如下：
+
+```
+// ConfigFileApplicationListener#Loader.java
+
+private void loadForFileExtension(PropertySourceLoader loader, String prefix,
+        String fileExtension, Profile profile,
+        DocumentFilterFactory filterFactory, DocumentConsumer consumer) {
+    // <1> 获得 DocumentFilter 对象
+    DocumentFilter defaultFilter = filterFactory.getDocumentFilter(null);
+    DocumentFilter profileFilter = filterFactory.getDocumentFilter(profile);
+    // <2> 加载 Profile 指定的配置文件（带后缀）。
+    if (profile != null) {
+        // Try profile-specific file & profile section in profile file (gh-340)
+        // 加载 Profile 指定的配置文件（带后缀）。
+        String profileSpecificFile = prefix + "-" + profile + fileExtension;
+        load(loader, profileSpecificFile, profile, defaultFilter, consumer); // <2.1> 情况一，未配置 spring.profile 属性
+        load(loader, profileSpecificFile, profile, profileFilter, consumer); // <2.2> 情况二，有配置 spring.profile 属性
+        // Try profile specific sections in files we've already processed
+        // <2.3》 特殊情况，之前读取 Profile 对应的配置文件，也可被当前 Profile 所读取。
+        // 举个例子，假设之前读取了 Profile 为 common 对应配置文件是 application-common.properties ，里面配置了 spring.profile=dev,prod
+        //         那么，此时如果读取的 Profile 为 dev 时，也能读取 application-common.properties 这个配置文件
+        for (Profile processedProfile : this.processedProfiles) {
+            if (processedProfile != null) {
+                String previouslyLoaded = prefix + "-" + processedProfile + fileExtension; // 拼接之前的配置文件名
+                load(loader, previouslyLoaded, profile, profileFilter, consumer); // 注意噢，传入的 profile 是当前的 profile
+            }
+        }
+    }
+    // Also try the profile-specific section (if any) of the normal file
+    // <3> 加载（无需带 Profile）指定的配置文件（带后缀）。
+    load(loader, prefix + fileExtension, profile, profileFilter, consumer);
+}
+```
+
+- `<1>` 处，获得两个 DocumentFilter 对象。为什么是两个呢？胖友思考下。实际上，我们在 [「4.4.1.1.5.2 getPositiveProfileFilter」](https://svip.iocoder.cn/Spring-Boot/properties-load/#) 中，已经说明了答案。
+- `<2>` 处，加载 Profile 指定的配置文件（带后缀）。有三种情况，胖友认真看 `<2.1>`、`<2.2>`、`<2.3>` 处的代码注释。
+- `<3>` 处，加载（无需带 Profile）指定的配置文件（带后缀）。
+- 关于 `#load(PropertySourceLoader loader, String location, Profile profile, DocumentFilter filter, DocumentConsumer consumer)` 方法，真正加载 Profile 指定的配置文件（带后缀）。详细解析，见 [「4.4.1.1.8 load」](https://svip.iocoder.cn/Spring-Boot/properties-load/#) 。
+
+##### 4.4.1.1.8 load
+
+`#load(PropertySourceLoader loader, String location, Profile profile, DocumentFilter filter, DocumentConsumer consumer)` 方法，真正加载 Profile 指定的配置文件（带后缀）。代码如下：
+
+```
+// ConfigFileApplicationListener#Loader.java
+
+private void load(PropertySourceLoader loader, String location, Profile profile, DocumentFilter filter, DocumentConsumer consumer) {
+    try {
+        // <1.1> 判断指定的配置文件是否存在。若不存在，则直接返回
+        Resource resource = this.resourceLoader.getResource(location);
+        if (!resource.exists()) {
+            if (this.logger.isTraceEnabled()) {
+                StringBuilder description = getDescription("Skipped missing config ", location, resource, profile);
+                this.logger.trace(description);
+            }
+            return;
+        }
+        // <1.2> 如果没有文件后缀的配置文件，则忽略，不进行读取
+        if (!StringUtils.hasText(StringUtils.getFilenameExtension(resource.getFilename()))) {
+            if (this.logger.isTraceEnabled()) {
+                StringBuilder description = getDescription("Skipped empty config extension ", location, resource, profile);
+                this.logger.trace(description);
+            }
+            return;
+        }
+        // <1.3> 加载配置文件，返回 Document 数组
+        String name = "applicationConfig: [" + location + "]";
+        List<Document> documents = loadDocuments(loader, name, resource);
+        // <1.4> 如果没加载到，则直接返回
+        if (CollectionUtils.isEmpty(documents)) {
+            if (this.logger.isTraceEnabled()) {
+                StringBuilder description = getDescription(
+                        "Skipped unloaded config ", location, resource, profile);
+                this.logger.trace(description);
+            }
+            return;
+        }
+        // <2> 使用 DocumentFilter 过滤匹配的 Document ，添加到 loaded 数组中。
+        List<Document> loaded = new ArrayList<>();
+        for (Document document : documents) {
+            if (filter.match(document)) { // 匹配
+                addActiveProfiles(document.getActiveProfiles()); // <2.1>
+                addIncludedProfiles(document.getIncludeProfiles()); // <2.2>
+                loaded.add(document);
+            }
+        }
+        Collections.reverse(loaded);
+        // <3> 使用 DocumentConsumer 进行消费 Document ，添加到本地的 loaded 中。
+        if (!loaded.isEmpty()) {
+            loaded.forEach((document) -> consumer.accept(profile, document));
+            if (this.logger.isDebugEnabled()) {
+                StringBuilder description = getDescription("Loaded config file ", location, resource, profile);
+                this.logger.debug(description);
+            }
+        }
+    } catch (Exception ex) {
+        throw new IllegalStateException("Failed to load property "
+                + "source from location '" + location + "'", ex);
+    }
+}
+```
+
+- `<1.1>` 处，判断指定的配置文件是否存在。若不存在，则直接返回。
+
+- `<1.2>` 处，如果没有文件后缀的配置文件，则忽略，不进行读取。
+
+- `<1.3>` 处，调用 `#loadDocuments(PropertySourceLoader loader, String name, Resource resource)` 方法，加载配置文件，并返回 Document 数组。详细解析，见 [「4.4.1.1.8.1 loadDocuments」](https://svip.iocoder.cn/Spring-Boot/properties-load/#) 小节。
+
+- `<1.4>` 处，如果没加载到，则直接返回。
+
+- `<2>` 处，遍历加载到 `documents` 数组，逐个调用 `DocumentFilter#match(Document document)` 方法，进行匹配。若匹配成功，则添加到 `loaded` 中。
+
+  - `<2.1>` 处，`#addActiveProfiles(Set<Profile> profiles)` 方法，已经在 [「4.4.1.1.1 initializeProfiles」](https://svip.iocoder.cn/Spring-Boot/properties-load/#) 中，详细解析。
+
+  - `<2.2>` 处，`#addIncludedProfiles(Set<Profile> profiles)` 方法，代码如下：
+
+    ```
+    // ConfigFileApplicationListener#Loader.java
+    
+    private void addIncludedProfiles(Set<Profile> includeProfiles) {
+        // 整体逻辑是 includeProfiles - processedProfiles + profiles
+    	LinkedList<Profile> existingProfiles = new LinkedList<>(this.profiles);
+    	this.profiles.clear();
+    	this.profiles.addAll(includeProfiles);
+    	this.profiles.removeAll(this.processedProfiles);
+    	this.profiles.addAll(existingProfiles);
+    }
+    ```
+
+    - ~
+
+  - `<3>` 处，遍历 `loaded` 数组，调用 `DocumentConsumer#accept(Profile profile, Document document)` 方法，添加到本地的 `Loader.loaded` 中。此处，在结合 [「4.4.1.1.6 DocumentConsumer」](https://svip.iocoder.cn/Spring-Boot/properties-load/#) 一起看。
+
+😈 至此，Spring Boot 加载配置的功能，基本是完成了。总的来说，理解大体的流程，还是相对比较容易的。但是，想要扣懂这个过程的每一个细节，需要多多的调试。
+
+> 艿艿：可能有些细节写的不到位，或者解释的不到位，又或者讲的不正确。所以，有任何疑惑，请立刻马上赶紧给我星球留言提问哈。
+
+###### 4.4.1.1.8.1 loadDocuments
+
+`#loadDocuments(PropertySourceLoader loader, String name, Resource resource)` 方法，加载配置文件，并返回 Document 数组。代码如下：
+
+```
+// ConfigFileApplicationListener#Loader.java
+
+private List<Document> loadDocuments(PropertySourceLoader loader, String name, Resource resource) throws IOException {
+    // <1> 创建 DocumentsCacheKey 对象，从 loadDocumentsCache 缓存中加载 Document 数组
+    DocumentsCacheKey cacheKey = new DocumentsCacheKey(loader, resource);
+    List<Document> documents = this.loadDocumentsCache.get(cacheKey);
+    // <2.1> 如果不存在，则使用 PropertySourceLoader 加载指定配置文件
+    if (documents == null) {
+        List<PropertySource<?>> loaded = loader.load(name, resource);
+        // <2.2> 将返回的 PropertySource 数组，封装成 Document 数组
+        documents = asDocuments(loaded);
+        // <2.3> 添加到 loadDocumentsCache 缓存中
+        this.loadDocumentsCache.put(cacheKey, documents);
+    }
+    return documents;
+}
+```
+
+- `<1>` 处，创建 DocumentsCacheKey 对象，从 `loadDocumentsCache` 缓存中加载 Document 数组。
+
+- `<2.1>` 处，如果不存在，则调用 `PropertySourceLoader#load(String name, Resource resource)` 方法，加载指定配置文件。详细的解析，见 [「7. PropertySourceLoader」](https://svip.iocoder.cn/Spring-Boot/properties-load/#) 中。
+
+- `<2.2>` 处，调用 `#asDocuments(List<PropertySource<?>> loaded)` 方法，将返回的 PropertySource 数组，封装成 Document 数组。代码如下：
+
+  ```
+  // ConfigFileApplicationListener#Loader.java
+  
+  private List<Document> asDocuments(List<PropertySource<?>> loaded) {
+      if (loaded == null) {
+          return Collections.emptyList();
+      }
+      return loaded.stream().map((propertySource) -> {
+          // 创建 Binder 对象
+          Binder binder = new Binder(
+                  ConfigurationPropertySources.from(propertySource),
+                  this.placeholdersResolver);
+          return new Document(propertySource,
+                  binder.bind("spring.profiles", STRING_ARRAY).orElse(null), // 读取 "spring.profiles" 配置
+                  getProfiles(binder, ACTIVE_PROFILES_PROPERTY), // 读取 "spring.profiles.active" 配置
+                  getProfiles(binder, INCLUDE_PROFILES_PROPERTY)); // 读取 "spring.profiles.include" 配置
+      }).collect(Collectors.toList());
+  }
+  
+  private Set<Profile> getProfiles(Binder binder, String name) {
+  	return binder.bind(name, STRING_ARRAY).map(this::asProfileSet).orElse(Collections.emptySet());
+  }
+  
+  private Set<Profile> asProfileSet(String[] profileNames) {
+  	List<Profile> profiles = new ArrayList<>();
+  	for (String profileName : profileNames) {
+  		profiles.add(new Profile(profileName));
+  	}
+  	return new LinkedHashSet<>(profiles);
+  }
+  ```
+
+- `<2.3>` 处，添加到 `loadDocumentsCache` 缓存中。
+
+# 5. RandomValuePropertySource
+
+`org.springframework.boot.env.RandomValuePropertySource` ，继承 PropertySource 类，提供随机值的 PropertySource 实现类。
+
+不了解 Spring Boot 从配置文件中获取随机数，可以看看 [《Spring Boot学习–从配置文件中获取随机数》](https://blog.csdn.net/qq_35981283/article/details/77853069) 文章。
+
+## 5.1 addToEnvironment
+
+`#addToEnvironment(ConfigurableEnvironment environment)` **静态**方法，创建 RandomValuePropertySource 对象，添加到 `environment` 中。代码如下：
+
+```
+// RandomValuePropertySource.java
+
+/**
+ * Name of the random {@link PropertySource}.
+ */
+public static final String RANDOM_PROPERTY_SOURCE_NAME = "random";
+
+public static void addToEnvironment(ConfigurableEnvironment environment) {
+	environment.getPropertySources().addAfter(StandardEnvironment.SYSTEM_ENVIRONMENT_PROPERTY_SOURCE_NAME, new RandomValuePropertySource(RANDOM_PROPERTY_SOURCE_NAME));
+	logger.trace("RandomValuePropertySource add to Environment");
+}
+```
+
+## 5.2 getProperty
+
+实现 `#getProperty(String name)` 方法，获得 `name` 对应的随机值。代码如下：
+
+```
+// RandomValuePropertySource.java
+
+private static final String PREFIX = "random.";
+
+@Override
+public Object getProperty(String name) {
+    // <1> 必须以 random. 前缀
+    if (!name.startsWith(PREFIX)) {
+        return null;
+    }
+    if (logger.isTraceEnabled()) {
+        logger.trace("Generating random property for '" + name + "'");
+    }
+    // <2> 根据类型，获得随机值
+    return getRandomValue(name.substring(PREFIX.length()));
+}
+```
+
+- `<1>` 处，必须以 `"random."` 前缀。在获取属性值，`name` 前后的 `${}` 已经被去掉。
+
+- `<2>` 处，调用 `#getRandomValue(String type)` 方法，根据类型，获得随机值。代码如下：
+
+  ```
+  // RandomValuePropertySource.java
+  
+  private Object getRandomValue(String type) {
+      // int
+      if (type.equals("int")) {
+          return getSource().nextInt();
+      }
+      // long
+      if (type.equals("long")) {
+          return getSource().nextLong();
+      }
+      // int 范围
+      String range = getRange(type, "int");
+      if (range != null) {
+          return getNextIntInRange(range);
+      }
+      // long 范围
+      range = getRange(type, "long");
+      if (range != null) {
+          return getNextLongInRange(range);
+      }
+      // uuid
+      if (type.equals("uuid")) {
+          return UUID.randomUUID().toString();
+      }
+      // md5
+      return getRandomBytes();
+  }
+  
+  private String getRange(String type, String prefix) {
+      if (type.startsWith(prefix)) {
+          int startIndex = prefix.length() + 1;
+          if (type.length() > startIndex) {
+              return type.substring(startIndex, type.length() - 1);
+          }
+      }
+      return null;
+  }
+  
+  private int getNextIntInRange(String range) {
+      String[] tokens = StringUtils.commaDelimitedListToStringArray(range);
+      int start = Integer.parseInt(tokens[0]);
+      if (tokens.length == 1) {
+          return getSource().nextInt(start);
+      }
+      return start + getSource().nextInt(Integer.parseInt(tokens[1]) - start);
+  }
+  
+  private long getNextLongInRange(String range) {
+      String[] tokens = StringUtils.commaDelimitedListToStringArray(range);
+      if (tokens.length == 1) {
+          return Math.abs(getSource().nextLong() % Long.parseLong(tokens[0]));
+      }
+      long lowerBound = Long.parseLong(tokens[0]);
+      long upperBound = Long.parseLong(tokens[1]) - lowerBound;
+      return lowerBound + Math.abs(getSource().nextLong() % upperBound);
+  }
+  
+  private Object getRandomBytes() {
+      byte[] bytes = new byte[32];
+      getSource().nextBytes(bytes);
+      return DigestUtils.md5DigestAsHex(bytes);
+  }
+  ```
+
+  - 比较简单，瞅瞅即明白。
+
+😈 这个谜题，是不是被揭晓了~
+
+# 6. PropertySourcesPlaceholdersResolver
+
+`org.springframework.boot.context.properties.bind.PropertySourcesPlaceholdersResolver` ，实现 PropertySource 对应的值是占位符的解析器 。
+
+## 6.1 构造方法
+
+```
+// PropertySourcesPlaceholdersResolver.java
+
+private final Iterable<PropertySource<?>> sources;
+
+private final PropertyPlaceholderHelper helper;
+
+public PropertySourcesPlaceholdersResolver(Environment environment) {
+	this(getSources(environment), null);
+}
+
+public PropertySourcesPlaceholdersResolver(Iterable<PropertySource<?>> sources) {
+	this(sources, null);
+}
+
+public PropertySourcesPlaceholdersResolver(Iterable<PropertySource<?>> sources,
+		PropertyPlaceholderHelper helper) {
+	this.sources = sources;
+	this.helper = (helper != null) ? helper
+			: new PropertyPlaceholderHelper(SystemPropertyUtils.PLACEHOLDER_PREFIX, // ${
+					SystemPropertyUtils.PLACEHOLDER_SUFFIX, // }
+					SystemPropertyUtils.VALUE_SEPARATOR, true);
+}
+
+// 获得 PropertySources 们
+private static PropertySources getSources(Environment environment) {
+	Assert.notNull(environment, "Environment must not be null");
+	Assert.isInstanceOf(ConfigurableEnvironment.class, environment, "Environment must be a ConfigurableEnvironment");
+	return ((ConfigurableEnvironment) environment).getPropertySources();
+}
+```
+
+- 其中，创建的 `helper` 属性，为 PropertyPlaceholderHelper 对象。其中 `SystemPropertyUtils.PLACEHOLDER_PREFIX` 为 `${` ， `SystemPropertyUtils.PLACEHOLDER_SUFFIX` 为 `}` 。这样，例如说 RandomValuePropertySource 的 `${random.int}` 等等，就可以被 PropertySourcesPlaceholdersResolver 所处理。
+
+## 6.2 resolvePlaceholders
+
+实现 `#resolvePlaceholders(Object value)` 方法，解析占位符。代码如下：
+
+```
+// PropertySourcesPlaceholdersResolver.java
+
+@Override
+public Object resolvePlaceholders(Object value) {
+    // 如果 value 是 String 类型，才是占位符
+    if (value instanceof String) {
+        return this.helper.replacePlaceholders((String) value, this::resolvePlaceholder);
+    }
+    return value;
+}
+```
+
+- 如果 `value` 是 String 类型，才**可能**是占位符。满足时，调用 `PropertyPlaceholderHelper#replacePlaceholders(String value, PlaceholderResolver placeholderResolver)` 方法，解析出占位符里面的内容。
+
+  - 例如说：PropertySourcesPlaceholdersResolver 中，占位符是 `${}` ，那么 `${random.int}` 被解析后的内容是 `random.int` 。
+
+  - 解析到占位符后，则回调 `#resolvePlaceholder(String placeholder)` 方法，获得占位符对应的值。代码如下：
+
+    ```
+    // PropertySourcesPlaceholdersResolver.java
+    
+    protected String resolvePlaceholder(String placeholder) {
+        if (this.sources != null) {
+            // 遍历 sources 数组，逐个获得属性值。若获取到，则进行返回
+            for (PropertySource<?> source : this.sources) {
+                Object value = source.getProperty(placeholder);
+                if (value != null) {
+                    return String.valueOf(value);
+                }
+            }
+        }
+        return null;
+    }
+    ```
+
+    - 这样，😈 RandomValuePropertySource 是不是就被串起来喽。
+
+# 7. PropertySourceLoader
+
+`org.springframework.boot.env.PropertySourceLoader` 接口，加载指定配置文件，返回 PropertySource 数组。代码如下：
+
+```
+// PropertySourceLoader.java
+
+public interface PropertySourceLoader {
+
+	/**
+     * 获得可以处理的配置文件的后缀
+     *
+	 * Returns the file extensions that the loader supports (excluding the '.').
+	 * @return the file extensions
+	 */
+	String[] getFileExtensions();
+
+	/**
+     * 加载指定配置文件，返回 PropertySource 数组
+     *
+	 * Load the resource into one or more property sources. Implementations may either
+	 * return a list containing a single source, or in the case of a multi-document format
+	 * such as yaml a source for each document in the resource.
+	 * @param name the root name of the property source. If multiple documents are loaded
+	 * an additional suffix should be added to the name for each source loaded.
+     *             PropertySource 的名字
+	 * @param resource the resource to load
+     *             配置文件的 Resource 对象
+	 * @return a list property sources
+	 * @throws IOException if the source cannot be loaded
+	 */
+	List<PropertySource<?>> load(String name, Resource resource) throws IOException;
+
+}
+```
+
+- 可能胖友，和我开始一样，为什么一个配置文件，加载后会存在多个 PropertySource 对象呢？下面，我们来见分晓~
+
+## 7.1 PropertiesPropertySourceLoader
+
+`org.springframework.boot.env.PropertiesPropertySourceLoader` ，实现 PropertySourceLoader 接口，加载 `.xml` 和 `.properties` 类型的配置文件。代码如下：
+
+```
+// PropertiesPropertySourceLoader.java
+
+public class PropertiesPropertySourceLoader implements PropertySourceLoader {
+
+    private static final String XML_FILE_EXTENSION = ".xml";
+
+    @Override
+    public String[] getFileExtensions() {
+        return new String[] { "properties", "xml" }; // <1>
+    }
+
+    @Override
+    public List<PropertySource<?>> load(String name, Resource resource)
+            throws IOException {
+        // <2.1> 读取指定配置文件，返回 Map 对象
+        Map<String, ?> properties = loadProperties(resource);
+        // <2.2> 如果 Map 为空，返回空数组
+        if (properties.isEmpty()) {
+            return Collections.emptyList();
+        }
+        // <2.3> 将 Map 封装成 OriginTrackedMapPropertySource 对象，然后返回单元素的数组
+        return Collections.singletonList(new OriginTrackedMapPropertySource(name, properties));
+    }
+
+}
+```
+
+- `<1>` 处，返回可处理的文件类型，为 `properties` 和 `xml` 。
+
+- `<2.1>` 处，调用 `#loadProperties(Resource resource)` 方法，读取指定配置文件，返回 Map 对象。代码如下：
+
+  ```
+  // PropertiesPropertySourceLoader.java
+  
+  private Map<String, ?> loadProperties(Resource resource) throws IOException {
+      String filename = resource.getFilename();
+      // 读取 XML 后缀的配置文件
+      if (filename != null && filename.endsWith(XML_FILE_EXTENSION)) {
+          return (Map) PropertiesLoaderUtils.loadProperties(resource);
+      }
+      // 读取 Properties 后缀的配置文件
+      return new OriginTrackedPropertiesLoader(resource).load();
+  }
+  ```
+
+  - 根据 `.xml` 和 `.properties` 后缀，使用不同的读取方法。至于读取配置的逻辑，暂时不在本文的范畴，hoho 。感兴趣的胖友，自己去瞅瞅。
+
+- `<2.2>` 处，如果 Map 为空，返回空数组。
+
+- ```
+  <2.3>
+  ```
+
+   
+
+  处，将 Map 封装成 OriginTrackedMapPropertySource 对象，然后返回单元素的数组。
+
+  ```
+  org.springframework.boot.env.OriginTrackedMapPropertySource
+  ```
+
+   
+
+  ，继承 MapPropertySource 类，实现 OriginLookup 接口，代码如下：
+
+  ```
+  // OriginTrackedMapPropertySource.java
+  
+  public final class OriginTrackedMapPropertySource extends MapPropertySource
+  		implements OriginLookup<String> {
+  
+  	@SuppressWarnings({ "unchecked", "rawtypes" })
+  	public OriginTrackedMapPropertySource(String name, Map source) {
+  		super(name, source);
+  	}
+  
+  	@Override
+  	public Object getProperty(String name) {
+  	    // 获得属性值
+  		Object value = super.getProperty(name);
+  		// 如果是 OriginTrackedValue 封装类型，则返回其真实的值
+  		if (value instanceof OriginTrackedValue) {
+  			return ((OriginTrackedValue) value).getValue();
+  		}
+  		return value;
+  	}
+  
+  	@Override
+  	public Origin getOrigin(String name) {
+          // 获得属性值
+          Object value = super.getProperty(name);
+          // 如果是 OriginTrackedValue 封装类型，则返回其 Origin
+  		if (value instanceof OriginTrackedValue) {
+  			return ((OriginTrackedValue) value).getOrigin();
+  		}
+  		return null;
+  	}
+  
+  }
+  ```
+
+## 7.2 YamlPropertySourceLoader
+
+`org.springframework.boot.env.YamlPropertySourceLoader` ，实现 PropertySourceLoader 接口，加载 `.yaml` 和 `.yml` 类型的配置文件。代码如下：
+
+```
+// YamlPropertySourceLoader.java
+
+public class YamlPropertySourceLoader implements PropertySourceLoader {
+
+    @Override
+    public String[] getFileExtensions() {
+        return new String[] { "yml", "yaml" }; // <1>
+    }
+
+    @Override
+    public List<PropertySource<?>> load(String name, Resource resource) throws IOException {
+        // <2> 如果不存在 org.yaml.snakeyaml.Yaml 类，说明没有引入 snakeyaml 依赖
+        if (!ClassUtils.isPresent("org.yaml.snakeyaml.Yaml", null)) {
+            throw new IllegalStateException("Attempted to load " + name
+                    + " but snakeyaml was not found on the classpath");
+        }
+        // <3.1> 加载配置，返回 Map 数组
+        List<Map<String, Object>> loaded = new OriginTrackedYamlLoader(resource).load();
+        // <3.2> 如果数组为空，返回空数组
+        if (loaded.isEmpty()) {
+            return Collections.emptyList();
+        }
+        // <3.3> 将 Map 数组，封装成 OriginTrackedMapPropertySource 数组，返回
+        List<PropertySource<?>> propertySources = new ArrayList<>(loaded.size());
+        for (int i = 0; i < loaded.size(); i++) {
+            String documentNumber = (loaded.size() != 1) ? " (document #" + i + ")" : "";
+            propertySources.add(new OriginTrackedMapPropertySource(name + documentNumber, loaded.get(i)));
+        }
+        return propertySources;
+    }
+
+}
+```
+
+- `<1>` 处，返回可处理的文件类型，为 `yaml` 和 `yml` 。
+- `<2>` 处，如果不存在 `org.yaml.snakeyaml.Yaml` 类，说明没有引入 snakeyaml 依赖，则抛出 IllegalStateException 异常。
+- `<3.1>` 处，调用 `OriginTrackedYamlLoader#load()` 方法，加载配置，返回 Map 数组。😈 哎哟，此处就是我们的好奇了，返回的是 Map 数组列！我们先来看看 [《Spring Boot 使用 YML 文件配置多环境》](https://blog.csdn.net/yy756127197/article/details/78193398) 的 [「1 一个yml文件」](https://svip.iocoder.cn/Spring-Boot/properties-load/#) ，每个 `----` 分割线，会解析成一个对应的 `Map<String, Object>` 对象。
+- `<3.2>` 处，如果 Map 数组为空，返回空数组。
+- `<3.3>` 处，将 Map 数组，封装成 OriginTrackedMapPropertySource 数组，然后返回。
+
+# 666. 彩蛋
+
+卧槽，真心是内心无比卧槽。比我预先的，长太太太多了。
+
+如果有解释不到位的地方，麻烦胖友在星球提出下哟。hoho ，春节期间初二，在老家写完~
+
+参考和推荐如下文章：
+
+- oldflame-Jm [《Spring boot源码分析-profiles环境（4）》](https://blog.csdn.net/jamet/article/details/77508182)
+- oldflame-Jm [《Spring boot源码分析-ApplicationListener应用环境（5）》](https://blog.csdn.net/jamet/article/details/78042486)
+- youzhibing2904 [《spring-boot-2.0.3不一样系列之源码篇 - run方法（二）之prepareEnvironment，绝对有值得你看的地方》](https://www.cnblogs.com/youzhibing/p/9622441.html)
+
+------
+
+如下内容，是艿艿的草稿，胖友可以先不去了解。
+
+假设 Profile 为 `prod,dev` 。读取结果如下：
+
+> 如下过程，省略读取不到配置文件的情况。
+
+- getPositiveProfileFilter 的情况
+
+  - ```
+    profile=null
+    ```
+
+     
+
+    部分
+
+    - 读取 `classpath:/application.properties` ，匹配成功。
+    - 读取 `classpath:/application.yaml` ，匹配成功。
+
+  - ```
+    profile=prod
+    ```
+
+    - 读取 `classpath:/application-prod.properties` ，匹配成功（基于 `defaultFilter`）。
+    - 读取 `classpath:/application-prod.properties` ，匹配失败（基于 `profileFilter`）。
+    - 读取 `classpath:/application-prod.properties` ，匹配失败（基于 `profileFilter`）。
+    - 读取 `classpath:/application.yaml` ，匹配失败（基于 `profileFilter`）。【匹配上 prod 那部分】
+
+  - ```
+    profile=dev
+    ```
+
+    - 读取 `classpath:/application-dev.properties` ，匹配成功（基于 `defaultFilter`）。
+    - 读取 `classpath:/application-dev.properties` ，匹配失败（基于 `profileFilter`）。
+    - 读取 `classpath:/application-dev.properties` ，匹配失败（基于 `profileFilter`）。
+    - 读取 `classpath:/application.yaml` ，匹配失败（基于 `profileFilter`）。【匹配上 dev 那部分】
+
+- getNegativeProfileFilter 的情况
+
+  - ```
+    profile=null
+    ```
+
+     
+
+    部分
+
+    - 读取 `classpath:/application.properties` ，匹配失败。
+
+    - 🙂🙂🙂 读取
+
+       
+
+      ```
+      classpath:/application.yaml
+      ```
+
+       
+
+      ，匹配成功【匹配上 prod、dev 那部分】。比较有意思 😈 ，用于解决
+
+       
+
+      ```
+      profile=null
+      ```
+
+       
+
+      的情况，可以把激活的 Profile ，也匹配上。但是在目前这个情况下，即使匹配上，在
+
+       
+
+      ```
+      #addToLoaded(...)
+      ```
+
+       
+
+      方法中的 DocumentConsumer 的逻辑时，会在
+
+       
+
+      ```
+      checkForExisting
+      ```
+
+       
+
+      那块的逻辑，如果要校验已经存在的情况，则如果已经存在，则直接
+
+       
+
+      ```
+      return
+      ```
+
+       
+
+      被排除掉。因为在
+
+       
+
+      ```
+      profile=prod
+      ```
+
+       
+
+      和
+
+       
+
+      ```
+      profile=dev
+      ```
+
+       
+
+      部分，已经匹配上该部分的配置。
+
+      - = =~当然，实在搞不懂这个逻辑，也不用纠结这个。重点是搞懂 Spring Boot 加载配置的核心逻辑。也就是，ConfigFileApplicationListener 整体的逻辑。
+      - 艿艿又思考了下，貌似突然也有点想不通，什么情况下，这块逻辑会成功加载到 Profile 不匹配的配置文件，即在在 `#addToLoaded(...)` 方法中的 DocumentConsumer 的逻辑时，会在 `checkForExisting` 那块的逻辑，如果要校验已经存在的情况，则如果不存在。
\ No newline at end of file
diff --git a/springboot/15-Spring Boot 源码分析-日志系统.assets/01.jpg b/springboot/15-Spring Boot 源码分析-日志系统.assets/01.jpg
new file mode 100644
index 0000000..bd58233
Binary files /dev/null and b/springboot/15-Spring Boot 源码分析-日志系统.assets/01.jpg differ
diff --git a/springboot/15-Spring Boot 源码分析-日志系统.md b/springboot/15-Spring Boot 源码分析-日志系统.md
new file mode 100644
index 0000000..1df6f41
--- /dev/null
+++ b/springboot/15-Spring Boot 源码分析-日志系统.md	
@@ -0,0 +1,2224 @@
+# 精尽 Spring Boot 源码分析 —— 日志系统
+
+# 1. 概述
+
+在使用 Spring Boot 时，默认就已经提供了日志功能，使用 Logback 作为默认的日志框架。本文，我们就来一起研究下，Spring Boot 是如何自动初始化好日志系统的。
+
+不了解 Spring Boot 日志功能的胖友，可以先看看 [《一起来学 SpringBoot 2.x | 第三篇：SpringBoot 日志配置》](http://www.iocoder.cn/Spring-Boot/battcn/v2-config-logs/?vip) 文章。
+
+# 2. LoggingApplicationListener
+
+Spring Boot 提供日志功能，关键在于 LoggingApplicationListener 类。在 [《精尽 Spring Boot 源码分析 —— ApplicationListener》](http://svip.iocoder.cn/Spring-Boot/ApplicationListener/) 中，我们已经简单介绍过它：
+
+> `org.springframework.boot.context.logging.LoggingApplicationListener` ，实现 GenericApplicationListener 接口，实现根据配置初始化日志系统 Logger 。
+
+## 2.1 supportsEventType
+
+实现 `#supportsEventType(ResolvableType resolvableType)` 方法，判断是否是支持的事件类型。代码如下：
+
+```
+// LoggingApplicationListener.java
+
+private static final Class<?>[] EVENT_TYPES = { ApplicationStartingEvent.class,
+		ApplicationEnvironmentPreparedEvent.class, ApplicationPreparedEvent.class,
+		ContextClosedEvent.class, ApplicationFailedEvent.class };
+		
+@Override
+public boolean supportsEventType(ResolvableType resolvableType) {
+	return isAssignableFrom(resolvableType.getRawClass(), EVENT_TYPES);
+}
+
+private boolean isAssignableFrom(Class<?> type, Class<?>... supportedTypes) {
+	if (type != null) {
+		for (Class<?> supportedType : supportedTypes) {
+			if (supportedType.isAssignableFrom(type)) {
+				return true;
+			}
+		}
+	}
+	return false;
+}
+```
+
+## 2.2 supportsSourceType
+
+实现 `#supportsSourceType(Class<?> sourceType)` 方法，判断是否是支持的事件来源。代码如下：
+
+```
+// LoggingApplicationListener.java
+
+private static final Class<?>[] SOURCE_TYPES = { SpringApplication.class,
+		ApplicationContext.class };
+		
+@Override
+public boolean supportsSourceType(Class<?> sourceType) {
+	return isAssignableFrom(sourceType, SOURCE_TYPES);
+}
+```
+
+## 2.3 onApplicationEvent
+
+实现 `#onApplicationEvent(ApplicationEvent event)` 方法，处理事件。代码如下：
+
+```
+// LoggingApplicationListener.java
+
+@Override
+public void onApplicationEvent(ApplicationEvent event) {
+    // 在 Spring Boot 应用启动的时候
+	if (event instanceof ApplicationStartingEvent) {
+		onApplicationStartingEvent((ApplicationStartingEvent) event);
+    // 在 Spring Boot 的 Environment 环境准备完成的时候
+	} else if (event instanceof ApplicationEnvironmentPreparedEvent) {
+		onApplicationEnvironmentPreparedEvent((ApplicationEnvironmentPreparedEvent) event);
+    // 在 Spring Boot 容器的准备工作已经完成（并未启动）的时候
+	} else if (event instanceof ApplicationPreparedEvent) {
+		onApplicationPreparedEvent((ApplicationPreparedEvent) event);
+    // 在 Spring Boot 容器关闭的时候
+	} else if (event instanceof ContextClosedEvent
+            && ((ContextClosedEvent) event).getApplicationContext().getParent() == null) {
+		onContextClosedEvent();
+	// 在 Spring Boot 容器启动失败的时候
+	} else if (event instanceof ApplicationFailedEvent) {
+		onApplicationFailedEvent();
+	}
+}
+```
+
+- 不同的事件，对应不同的处理方法。下文，我们一一来看。
+
+## 2.4 onApplicationStartingEvent
+
+`#onApplicationStartingEvent(ApplicationStartingEvent event)` 方法，代码如下：
+
+```
+// LoggingApplicationListener.java
+
+private LoggingSystem loggingSystem;
+
+private void onApplicationStartingEvent(ApplicationStartingEvent event) {
+    // <1> 创建 LoggingSystem 对象
+	this.loggingSystem = LoggingSystem.get(event.getSpringApplication().getClassLoader());
+	// <2> LoggingSystem 的初始化的前置处理
+	this.loggingSystem.beforeInitialize();
+}
+```
+
+- ```
+  <1>
+  ```
+
+   
+
+  处，调用
+
+   
+
+  ```
+  LoggingSystem#get(ClassLoader classLoader)
+  ```
+
+   
+
+  方法，创建（获得） LoggingSystem 对象。关于这个，可以先看看
+
+   
+
+  「3.1 get」
+
+   
+
+  小节。
+
+  - 通过 LoggingSystem 的抽象，对应不同日志框架对应的 LoggingSystem 实现，达到方便透明的接入不同的日志框架~
+
+- `<2>` 处，调用 `LoggingSystem#beforeInitialize()` 方法，执行 LoggingSystem 的初始化的前置处理。关于这个，可以先看看 [「3.2 beforeInitialize」](https://svip.iocoder.cn/Spring-Boot/logger-system/#) 小节。
+
+## 2.5 onApplicationEnvironmentPreparedEvent
+
+`#onApplicationEnvironmentPreparedEvent(ApplicationEnvironmentPreparedEvent event)` 方法，代码如下：
+
+```
+// LoggingApplicationListener.java
+
+private void onApplicationEnvironmentPreparedEvent(ApplicationEnvironmentPreparedEvent event) {
+	if (this.loggingSystem == null) {
+		this.loggingSystem = LoggingSystem.get(event.getSpringApplication().getClassLoader());
+	}
+	// 初始化
+	initialize(event.getEnvironment(), event.getSpringApplication().getClassLoader());
+}
+
+protected void initialize(ConfigurableEnvironment environment, ClassLoader classLoader) {
+    // <1> 初始化 LoggingSystemProperties 配置
+    new LoggingSystemProperties(environment).apply();
+    // <2> 初始化 LogFile
+    LogFile logFile = LogFile.get(environment);
+    if (logFile != null) {
+        logFile.applyToSystemProperties(); // <2.1>
+    }
+    // <3> 初始化早期的 Spring Boot Logging 级别
+    initializeEarlyLoggingLevel(environment);
+    // <4> 初始化 LoggingSystem 日志系统
+    initializeSystem(environment, this.loggingSystem, logFile);
+    // <5> 初始化最终的 Spring Boot Logging 级别
+    initializeFinalLoggingLevels(environment, this.loggingSystem);
+    // <6>  
+    registerShutdownHookIfNecessary(environment, this.loggingSystem);
+}
+```
+
+- `<1>` 处，调用 `LoggingSystemProperties#apply()` 方法，初始化 LoggingSystemProperties 配置。关于这个，可以先看看 [「4. LoggingSystemProperties」](https://svip.iocoder.cn/Spring-Boot/logger-system/#) 小节。
+
+- ```
+  <2>
+  ```
+
+   
+
+  处，调用
+
+   
+
+  ```
+  LogFile#get(environment)
+  ```
+
+   
+
+  方法，创建（获得）LogFile 。关于这个，可以先看看
+
+   
+
+  「5. LogFile」
+
+   
+
+  小节。
+
+  - `<2.1>` 处，调用 `LogFile#applyToSystemProperties()` 方法，应用 `LogFile.path` 和 `LogFile.file` 到系统属性中。
+
+- `<3>` 处，调用 `#initializeEarlyLoggingLevel(ConfigurableEnvironment environment)` 方法，初始化早期的 Spring Boot Logging 级别。详细解析，见 [「2.5.1 initializeEarlyLoggingLevel」](https://svip.iocoder.cn/Spring-Boot/logger-system/#) 中。
+
+- `<4>` 处，调用 `#initializeSystem(ConfigurableEnvironment environment, LoggingSystem system, LogFile logFile)` 方法，初始化 LoggingSystem 日志系统。详细解析，见 [「2.5.2 initializeSystem」](https://svip.iocoder.cn/Spring-Boot/logger-system/#) 中。
+
+- `<5>` 处，调用 `#initializeFinalLoggingLevels(ConfigurableEnvironment environment, LoggingSystem system)` 方法，初始化最终的 Spring Boot Logging 级别。详细解析，见 [「2.5.3 initializeFinalLoggingLevels」](https://svip.iocoder.cn/Spring-Boot/logger-system/#) 中。
+
+- `<6>` 处，调用 `#registerShutdownHookIfNecessary(Environment environment, LoggingSystem loggingSystem)` 方法，注册 ShutdownHook 。详细解析，见 [「2.5.4」](https://svip.iocoder.cn/Spring-Boot/logger-system/#) 中。
+
+### 2.5.1 initializeEarlyLoggingLevel
+
+`#initializeEarlyLoggingLevel(ConfigurableEnvironment environment)` 方法，初始化早期的 Spring Boot Logging 级别。代码如下：
+
+```
+// LoggingApplicationListener.java
+    
+private boolean parseArgs = true;
+    
+private LogLevel springBootLogging = null;
+    
+private void initializeEarlyLoggingLevel(ConfigurableEnvironment environment) {
+	if (this.parseArgs && this.springBootLogging == null) {
+		if (isSet(environment, "debug")) {
+			this.springBootLogging = LogLevel.DEBUG;
+		}
+		if (isSet(environment, "trace")) {
+			this.springBootLogging = LogLevel.TRACE;
+		}
+	}
+}
+    
+private boolean isSet(ConfigurableEnvironment environment, String property) {
+	String value = environment.getProperty(property);
+	return (value != null && !value.equals("false"));
+}
+```
+
+- 可以通过在启动 jar 的时候，跟上 `--debug` 或 `--trace` 。
+- 也可以在配置文件中，添加 `debug=true` 或 `trace=true` 。
+- 关于日志级别，可以先看看 [「6. LogLevel」](https://svip.iocoder.cn/Spring-Boot/logger-system/#) 。
+
+### 2.5.2 initializeSystem
+
+`#initializeSystem(ConfigurableEnvironment environment, LoggingSystem system, LogFile logFile)` 方法，初始化 LoggingSystem 日志系统。代码如下：
+
+```
+// LoggingApplicationListener.java
+    
+public static final String CONFIG_PROPERTY = "logging.config";
+
+private void initializeSystem(ConfigurableEnvironment environment, LoggingSystem system, LogFile logFile) {
+    // <1> 创建 LoggingInitializationContext 对象
+    LoggingInitializationContext initializationContext = new LoggingInitializationContext(environment);
+    // <2> 获得日志组件的配置文件
+    String logConfig = environment.getProperty(CONFIG_PROPERTY);
+    // <3> 如果没配置，则直接初始化 LoggingSystem
+    if (ignoreLogConfig(logConfig)) {
+        system.initialize(initializationContext, null, logFile);
+    // <3> 如果有配置，先尝试加载指定配置文件，然后在初始化 LoggingSystem
+    } else {
+        try {
+            ResourceUtils.getURL(logConfig).openStream().close();
+            system.initialize(initializationContext, logConfig, logFile); // <X>
+        } catch (Exception ex) {
+            // NOTE: We can't use the logger here to report the problem
+            System.err.println("Logging system failed to initialize " + "using configuration from '" + logConfig + "'");
+            ex.printStackTrace(System.err);
+            throw new IllegalStateException(ex);
+        }
+    }
+}
+```
+
+- `<1>` 处，创建 LoggingInitializationContext 对象。其中，`org.springframework.boot.logging.LoggingInitializationContext` ，LoggingSystem 初始化时的 Context 。代码如下：
+
+  ```
+  // LoggingInitializationContext.java
+  
+  public class LoggingInitializationContext {
+  
+  	private final ConfigurableEnvironment environment;
+  
+  	public LoggingInitializationContext(ConfigurableEnvironment environment) {
+  		this.environment = environment;
+  	}
+  
+  	public Environment getEnvironment() {
+  		return this.environment;
+  	}
+  
+  }
+  ```
+
+  - 虽然目前只有 `environment` 属性。但是未来可以在后面增加新的参数，而无需改动 `LoggingSystem#initialize(LoggingInitializationContext initializationContext, String configLocation, LogFile logFile)` 方法。
+
+- `<2>` 处，从 `environment` 中获得 `"logging.config"` ，即获得日志组件的配置文件。一般情况下，我们无需配置。因为根据不同的日志系统，Spring Boot 按如下“约定规则”组织配置文件名加载日志配置文件：
+
+| 日志框架                | 配置文件                                                     |
+| :---------------------- | :----------------------------------------------------------- |
+| Logback                 | logback-spring.xml, logback-spring.groovy, logback.xml, logback.groovy |
+| Log4j                   | log4j-spring.properties, log4j-spring.xml, log4j.properties, log4j.xml |
+| Log4j2                  | log4j2-spring.xml, log4j2.xml                                |
+| JDK (Java Util Logging) | logging.properties                                           |
+
+- `<3>` 和 `<4>` 处，调用 `LoggingSystem#initialize(LoggingInitializationContext initializationContext, String configLocation, LogFile logFile)` 方法，初始化 LoggingSystem 日志系统。详细解析，可以先看看 [「3.3 initialize」](https://svip.iocoder.cn/Spring-Boot/logger-system/#) 。
+- `<3>` 和 `<4>` 处，差异点在于后者多了 `ResourceUtils.getURL(logConfig).openStream().close()` 代码块，看着有点奇怪哟？它的作用是，尝试去加载 `logConfig` 对应的配置文件，看看是否真的存在~
+
+### 2.5.3 initializeFinalLoggingLevels
+
+`#initializeFinalLoggingLevels(ConfigurableEnvironment environment, LoggingSystem system)` 方法，初始化最终的 Spring Boot Logging 级别。代码如下：
+
+```
+// LoggingApplicationListener.java
+
+private void initializeFinalLoggingLevels(ConfigurableEnvironment environment, LoggingSystem system) {
+    // <1> 如果 springBootLogging 非空，则设置到日志级别
+    if (this.springBootLogging != null) {
+        initializeLogLevel(system, this.springBootLogging);
+    }
+    // <2> 设置 environment 中配置的日志级别
+    setLogLevels(system, environment);
+}
+```
+
+- `<1>` 处，如果 `springBootLogging` 非空，则调用 `#initializeLogLevel(LoggingSystem system, LogLevel level)` 方法，设置日志级别。代码如下：
+
+  ```
+  // LoggingApplicationListener.java
+  
+  private static final Map<LogLevel, List<String>> LOG_LEVEL_LOGGERS;
+  
+  static {
+  	MultiValueMap<LogLevel, String> loggers = new LinkedMultiValueMap<>();
+  	loggers.add(LogLevel.DEBUG, "sql");
+  	loggers.add(LogLevel.DEBUG, "web");
+  	loggers.add(LogLevel.DEBUG, "org.springframework.boot");
+  	loggers.add(LogLevel.TRACE, "org.springframework");
+  	loggers.add(LogLevel.TRACE, "org.apache.tomcat");
+  	loggers.add(LogLevel.TRACE, "org.apache.catalina");
+  	loggers.add(LogLevel.TRACE, "org.eclipse.jetty");
+  	loggers.add(LogLevel.TRACE, "org.hibernate.tool.hbm2ddl");
+  	LOG_LEVEL_LOGGERS = Collections.unmodifiableMap(loggers);
+  }
+  
+  protected void initializeLogLevel(LoggingSystem system, LogLevel level) {
+  	List<String> loggers = LOG_LEVEL_LOGGERS.get(level);
+  	if (loggers != null) {
+  		for (String logger : loggers) {
+  			system.setLogLevel(logger, level);
+  		}
+  	}
+  }
+  ```
+
+  - 遍历的 `loggers` ，是 `LOG_LEVEL_LOGGERS` 中对应的 `level` 的值。
+  - 调用 `LoggingSystem#setLogLevel(String loggerName, LogLevel level)` 方法，设置指定 `loggerName` 的日志级别。详细解析，见 [「3.4 setLogLevel」](https://svip.iocoder.cn/Spring-Boot/logger-system/#) 。
+
+- `<2>` 处，调用 `#setLogLevels(LoggingSystem system, Environment environment)` 方法，设置 environment 中配置的日志级别。代码如下：
+
+  ```
+  // LoggingApplicationListener.java
+  
+  private static final ConfigurationPropertyName LOGGING_LEVEL = ConfigurationPropertyName.of("logging.level");
+  private static final ConfigurationPropertyName LOGGING_GROUP = ConfigurationPropertyName.of("logging.group");
+  
+  private static final Bindable<Map<String, String>> STRING_STRING_MAP = Bindable.mapOf(String.class, String.class);
+  private static final Bindable<Map<String, String[]>> STRING_STRINGS_MAP = Bindable.mapOf(String.class, String[].class);
+  
+  protected void setLogLevels(LoggingSystem system, Environment environment) {
+      if (!(environment instanceof ConfigurableEnvironment)) {
+          return;
+      }
+      // 创建 Binder 对象
+      Binder binder = Binder.get(environment);
+      // <1> 获得日志分组的集合
+      Map<String, String[]> groups = getGroups(); // <1.1>
+      binder.bind(LOGGING_GROUP, STRING_STRINGS_MAP.withExistingValue(groups)); // <1.2>
+      // <2> 获得日志级别的集合
+      Map<String, String> levels = binder.bind(LOGGING_LEVEL, STRING_STRING_MAP).orElseGet(Collections::emptyMap);
+      // <3> 遍历 levels 集合，逐个设置日志级别
+      levels.forEach((name, level) -> {
+          String[] groupedNames = groups.get(name);
+          if (ObjectUtils.isEmpty(groupedNames)) {
+              setLogLevel(system, name, level);
+          } else {
+              setLogLevel(system, groupedNames, level);
+          }
+      });
+  }
+  ```
+
+  - `<1>` 处，获得日志分组的集合。
+
+    - `<1.1>` 处，调用 `#getGroups()` 方法，获得默认的日志分组集合。代码如下：
+
+      ```
+      // LoggingApplicationListener.java
+      
+      private static final Map<String, List<String>> DEFAULT_GROUP_LOGGERS;
+      static {
+      	MultiValueMap<String, String> loggers = new LinkedMultiValueMap<>();
+      	loggers.add("web", "org.springframework.core.codec");
+      	loggers.add("web", "org.springframework.http");
+      	loggers.add("web", "org.springframework.web");
+      	loggers.add("web", "org.springframework.boot.actuate.endpoint.web");
+      	loggers.add("web", "org.springframework.boot.web.servlet.ServletContextInitializerBeans");
+      	loggers.add("sql", "org.springframework.jdbc.core");
+      	loggers.add("sql", "org.hibernate.SQL");
+      	DEFAULT_GROUP_LOGGERS = Collections.unmodifiableMap(loggers);
+      }
+      
+      private Map<String, String[]> getGroups() {
+      	Map<String, String[]> groups = new LinkedHashMap<>();
+      	DEFAULT_GROUP_LOGGERS.forEach(
+      			(name, loggers) -> groups.put(name, StringUtils.toStringArray(loggers)));
+      	return groups;
+      }
+      ```
+
+      - 实际上，就是把我们日常配置的 `loggerName` 进行了分组。默认情况下，内置了 `sql`、`web` 分组。
+
+    - `<1.2>` 处，从 `environment` 中读取 `logging.group` 配置的日志分组。举个例子，在配置文件里增加 `logging.group.demo=xxx.Dog,yyy.Cat` 。
+
+  - `<2>` 处，从 `environment` 中读取 `logging.level` 配置的日志分组。举两个例子，在配置文件里添加：
+
+    - `logging.level.web=INFO`
+    - `logging.level.xxx.Dog=INFO`
+
+  - `<3>` 处，遍历 `levels` 集合，逐个设置日志级别。涉及的方法，代码如下：
+
+    ```
+    // LoggingApplicationListener.java
+    
+    private void setLogLevel(LoggingSystem system, String[] names, String level) {
+        // 遍历 names 数组
+        for (String name : names) {
+            setLogLevel(system, name, level);
+        }
+    }
+    
+    private void setLogLevel(LoggingSystem system, String name, String level) {
+        try {
+            // 获得 loggerName
+            name = name.equalsIgnoreCase(LoggingSystem.ROOT_LOGGER_NAME) ? null : name;
+            // 设置日志级别
+            system.setLogLevel(name, coerceLogLevel(level));
+        } catch (RuntimeException ex) {
+            this.logger.error("Cannot set level '" + level + "' for '" + name + "'");
+        }
+    }
+    
+    /**
+     * @param level 日志级别字符串
+     * @return 将字符串转换成 {@link LogLevel}
+     */
+    private LogLevel coerceLogLevel(String level) {
+        String trimmedLevel = level.trim();
+        if ("false".equalsIgnoreCase(trimmedLevel)) { // false => OFF
+            return LogLevel.OFF;
+        }
+        return LogLevel.valueOf(trimmedLevel.toUpperCase(Locale.ENGLISH));
+    }
+    ```
+
+    - 比较简单，胖友瞅瞅~
+
+### 2.5.4 registerShutdownHookIfNecessary
+
+`#registerShutdownHookIfNecessary(Environment environment, LoggingSystem loggingSystem)` 方法，注册 ShutdownHook 。代码如下：
+
+```
+// LoggingApplicationListener.java
+
+/**
+ * The name of the Spring property that controls the registration of a shutdown hook
+ * to shut down the logging system when the JVM exits.
+ * @see LoggingSystem#getShutdownHandler
+ */
+public static final String REGISTER_SHUTDOWN_HOOK_PROPERTY = "logging.register-shutdown-hook";
+
+private void registerShutdownHookIfNecessary(Environment environment, LoggingSystem loggingSystem) {
+    // 获得 logging.register-shutdown-hook 对应的配置值
+    boolean registerShutdownHook = environment.getProperty(REGISTER_SHUTDOWN_HOOK_PROPERTY, Boolean.class, false);
+    // 如果开启
+    if (registerShutdownHook) {
+        // <x> 获得 shutdownHandler 钩子
+        Runnable shutdownHandler = loggingSystem.getShutdownHandler();
+        // 注册 ShutdownHook(
+        if (shutdownHandler != null
+                && shutdownHookRegistered.compareAndSet(false, true)) {
+            registerShutdownHook(new Thread(shutdownHandler));
+        }
+    }
+}
+
+void registerShutdownHook(Thread shutdownHook) {
+    Runtime.getRuntime().addShutdownHook(shutdownHook);
+}
+```
+
+- `<X>` 处，所注册的 ShutdownHook ，通过调用 `LoggingSystem#getShutdownHandler()` 方法，进行获得。详细解析，见 [「3.5 getShutdownHandler」](https://svip.iocoder.cn/Spring-Boot/logger-system/#)。
+
+## 2.6 onApplicationPreparedEvent
+
+`#onApplicationPreparedEvent(ApplicationPreparedEvent event)` 方法，代码如下：
+
+```
+// LoggingApplicationListener.java
+
+/**
+ * The name of the {@link LoggingSystem} bean.
+ */
+public static final String LOGGING_SYSTEM_BEAN_NAME = "springBootLoggingSystem";
+
+private void onApplicationPreparedEvent(ApplicationPreparedEvent event) {
+	ConfigurableListableBeanFactory beanFactory = event.getApplicationContext().getBeanFactory();
+	if (!beanFactory.containsBean(LOGGING_SYSTEM_BEAN_NAME)) {
+		beanFactory.registerSingleton(LOGGING_SYSTEM_BEAN_NAME, this.loggingSystem);
+	}
+}
+```
+
+- 将创建的 LoggingSystem 对象，注册到 Spring 容器中。
+
+## 2.7 onContextClosedEvent
+
+`#onContextClosedEvent()` 方法，代码如下：
+
+```
+// LoggingApplicationListener.java
+
+private void onContextClosedEvent() {
+	if (this.loggingSystem != null) {
+		this.loggingSystem.cleanUp();
+	}
+}
+```
+
+- 调用 `LoggingSystem#cleanUp()` 方法，执行清理。详细解析，见 [「3.6 cleanUp」](https://svip.iocoder.cn/Spring-Boot/logger-system/#) 中。
+
+## 2.8 onApplicationFailedEvent
+
+`#onApplicationFailedEvent()` 方法，代码如下：
+
+```
+// LoggingApplicationListener.java
+
+private void onApplicationFailedEvent() {
+	if (this.loggingSystem != null) {
+		this.loggingSystem.cleanUp();
+	}
+}
+```
+
+> 至此，我们需要来看看 LoggingSystem 的实现类。具体的，可以跳到 [「7. LoggingSystem 的实现类」](https://svip.iocoder.cn/Spring-Boot/logger-system/#) 中。
+
+# 3. LoggingSystem
+
+`org.springframework.boot.logging.LoggingSystem` ，日志系统抽象类。每个日志框架，都会对应一个实现类。如下图所示：[![LoggingSystem 实现类](15-Spring Boot 源码分析-日志系统.assets/01.jpg)](http://static.iocoder.cn/images/Spring-Boot/2021-02-01-new/01.jpg)LoggingSystem 实现类
+
+## 3.1 get
+
+`#get(ClassLoader classLoader)` 方法，创建（获得） LoggingSystem 对象。代码如下：
+
+```
+// LoggingApplicationListener.java
+
+/**
+ * A System property that can be used to indicate the {@link LoggingSystem} to use.
+ */
+public static final String SYSTEM_PROPERTY = LoggingSystem.class.getName();
+
+/**
+ * The value of the {@link #SYSTEM_PROPERTY} that can be used to indicate that no
+ * {@link LoggingSystem} should be used.
+ */
+public static final String NONE = "none";
+
+private static final Map<String, String> SYSTEMS;
+
+static {
+	Map<String, String> systems = new LinkedHashMap<>();
+	systems.put("ch.qos.logback.core.Appender", "org.springframework.boot.logging.logback.LogbackLoggingSystem");
+	systems.put("org.apache.logging.log4j.core.impl.Log4jContextFactory", "org.springframework.boot.logging.log4j2.Log4J2LoggingSystem");
+	systems.put("java.util.logging.LogManager", "org.springframework.boot.logging.java.JavaLoggingSystem");
+	SYSTEMS = Collections.unmodifiableMap(systems);
+}
+
+public static LoggingSystem get(ClassLoader classLoader) {
+    // <1> 从系统参数 org.springframework.boot.logging.LoggingSystem 获得 loggingSystem 类型
+    String loggingSystem = System.getProperty(SYSTEM_PROPERTY);
+    // <2> 如果非空，说明配置了
+    if (StringUtils.hasLength(loggingSystem)) {
+        // <2.1> 如果是 none ，则创建 NoOpLoggingSystem 对象
+        if (NONE.equals(loggingSystem)) {
+            return new NoOpLoggingSystem();
+        }
+        // <2.2> 获得 loggingSystem 对应的 LoggingSystem 类，进行创建对象
+        return get(classLoader, loggingSystem);
+    }
+    // <3> 如果为空，说明未配置，则顺序查找 SYSTEMS 中的类。如果存在指定类，则创建该类。
+    return SYSTEMS.entrySet().stream()
+            .filter((entry) -> ClassUtils.isPresent(entry.getKey(), classLoader))
+            .map((entry) -> get(classLoader, entry.getValue())).findFirst()
+            .orElseThrow(() -> new IllegalStateException("No suitable logging system located"));
+}
+```
+
+- `<1>` 处，从系统参数 `org.springframework.boot.logging.LoggingSystem` 获得 loggingSystem 类型。
+
+- `<2>` 处，如果非空，说明配置了。
+
+  - `<2.1>` 处，如果是 `none` ，则创建 NoOpLoggingSystem 对象。
+
+  - `<2.2>` 处，调用 `#get(ClassLoader classLoader, String loggingSystemClass)` 方法，获得 `loggingSystem` 对应的 LoggingSystem 类，进行创建对象。代码如下：
+
+    ```
+    // LoggingSystem.java
+    
+    private static LoggingSystem get(ClassLoader classLoader, String loggingSystemClass) {
+    	try {
+    		Class<?> systemClass = ClassUtils.forName(loggingSystemClass, classLoader);
+    		return (LoggingSystem) systemClass.getConstructor(ClassLoader.class).newInstance(classLoader);
+    	} catch (Exception ex) {
+    		throw new IllegalStateException(ex);
+    	}
+    }
+    ```
+
+    - `systemClass` 中的 VALUES ，就是 `loggingSystem` 对应的类。
+
+- `<3>` 处，如果为空，说明未配置，则顺序查找 `SYSTEMS` 中的类。如果存在指定类，则创建该类。
+
+## 3.2 beforeInitialize
+
+`#beforeInitialize()` **抽象**方法，初始化的前置方法。代码如下：
+
+```
+// LoggingSystem.java
+
+/**
+ * Reset the logging system to be limit output. This method may be called before
+ * {@link #initialize(LoggingInitializationContext, String, LogFile)} to reduce
+ * logging noise until the system has been fully initialized.
+ */
+public abstract void beforeInitialize();
+```
+
+## 3.3 initialize
+
+`#initialize()` 方法，初始化。代码如下：
+
+```
+// LoggingSystem.java
+
+/**
+ * Fully initialize the logging system.
+ * @param initializationContext the logging initialization context
+ * @param configLocation a log configuration location or {@code null} if default
+ * initialization is required
+ * @param logFile the log output file that should be written or {@code null} for
+ * console only output
+ */
+public void initialize(LoggingInitializationContext initializationContext, String configLocation, LogFile logFile) {
+}
+```
+
+- 目前是个空方法，需要子类来实现。
+- 我们先不着急看子类的实现，等后面继续看。
+
+## 3.4 setLogLevel
+
+`#setLogLevel(String loggerName, LogLevel level)` 方法，设置指定 `loggerName` 的日志级别。代码如下：
+
+```
+// LoggingSystem.java
+
+/**
+ * Sets the logging level for a given logger.
+ * @param loggerName the name of the logger to set ({@code null} can be used for the
+ * root logger).
+ * @param level the log level ({@code null} can be used to remove any custom level for
+ * the logger and use the default configuration instead)
+ */
+public void setLogLevel(String loggerName, LogLevel level) {
+	throw new UnsupportedOperationException("Unable to set log level");
+}
+```
+
+- 目前是个空方法，需要子类来实现。
+- 我们先不着急看子类的实现，等后面继续看。
+
+## 3.5 getShutdownHandler
+
+`#getShutdownHandler()` 方法，获得 ShutdownHook 的 Runnable 对象。代码如下：
+
+```
+// LoggingSystem.java
+
+/**
+ * Returns a {@link Runnable} that can handle shutdown of this logging system when the
+ * JVM exits. The default implementation returns {@code null}, indicating that no
+ * shutdown is required.
+ * @return the shutdown handler, or {@code null}
+ */
+public Runnable getShutdownHandler() {
+	return null;
+}
+```
+
+- 目前是个空方法，需要子类来实现。
+- 我们先不着急看子类的实现，等后面继续看。
+
+## 3.6 cleanUp
+
+`#cleanUp()` 方法，清理。代码如下：
+
+```
+// LoggingSystem.java
+
+/**
+ * Clean up the logging system. The default implementation does nothing. Subclasses
+ * should override this method to perform any logging system-specific cleanup.
+ */
+public void cleanUp() {
+}
+```
+
+- 目前是个空方法，需要子类来实现。
+- 我们先不着急看子类的实现，等后面继续看。
+
+# 4. LoggingSystemProperties
+
+`org.springframework.boot.logging.LoggingSystemProperties` ，LoggingSystem 的配置类。
+
+## 4.1 构造方法
+
+```
+// LoggingSystemProperties.java
+
+private final Environment environment;
+
+public LoggingSystemProperties(Environment environment) {
+	Assert.notNull(environment, "Environment must not be null");
+	this.environment = environment;
+}
+```
+
+## 4.2 apply
+
+`#apply()` 方法，解析 `environment` 的配置变量到系统属性中。代码如下：
+
+```
+// LoggingSystemProperties.java
+
+public void apply() {
+    apply(null);
+}
+
+public void apply(LogFile logFile) {
+    // <1> 获得 PropertyResolver 对象
+    PropertyResolver resolver = getPropertyResolver();
+    // <2> 解析配置文件到系统属性中
+    setSystemProperty(resolver, EXCEPTION_CONVERSION_WORD, "exception-conversion-word");
+    setSystemProperty(PID_KEY, new ApplicationPid().toString()); // 应用进程编号
+    setSystemProperty(resolver, CONSOLE_LOG_PATTERN, "pattern.console");
+    setSystemProperty(resolver, FILE_LOG_PATTERN, "pattern.file");
+    setSystemProperty(resolver, FILE_MAX_HISTORY, "file.max-history");
+    setSystemProperty(resolver, FILE_MAX_SIZE, "file.max-size");
+    setSystemProperty(resolver, LOG_LEVEL_PATTERN, "pattern.level");
+    setSystemProperty(resolver, LOG_DATEFORMAT_PATTERN, "pattern.dateformat");
+    // <3> 如果 logFile 非空，则应用配置
+    if (logFile != null) {
+        logFile.applyToSystemProperties();
+    }
+}
+```
+
+- ```
+  <1>
+  ```
+
+   
+
+  处，调用
+
+   
+
+  ```
+  #getPropertyResolver()
+  ```
+
+   
+
+  方法，获得 PropertyResolver 对象。代码如下：
+
+  ```
+  // LoggingSystemProperties.java
+  
+  private PropertyResolver getPropertyResolver() {
+  	if (this.environment instanceof ConfigurableEnvironment) {
+  		PropertySourcesPropertyResolver resolver = new PropertySourcesPropertyResolver(((ConfigurableEnvironment) this.environment).getPropertySources());
+  		resolver.setIgnoreUnresolvableNestedPlaceholders(true);
+  		return resolver;
+  	}
+  	return this.environment;
+  }
+  ```
+
+- `<2>` 处，调用 `#setSystemProperty(PropertyResolver resolver, String systemPropertyName, String propertyName)` 方法，解析配置文件到系统属性中。代码如下：
+
+  ```
+  // LoggingSystemProperties.java
+  
+  public static final String PID_KEY = "PID";
+  public static final String EXCEPTION_CONVERSION_WORD = "LOG_EXCEPTION_CONVERSION_WORD";
+  public static final String LOG_FILE = "LOG_FILE";
+  public static final String LOG_PATH = "LOG_PATH";
+  public static final String FILE_LOG_PATTERN = "FILE_LOG_PATTERN";
+  public static final String FILE_MAX_HISTORY = "LOG_FILE_MAX_HISTORY";
+  public static final String FILE_MAX_SIZE = "LOG_FILE_MAX_SIZE";
+  public static final String LOG_LEVEL_PATTERN = "LOG_LEVEL_PATTERN";
+  public static final String LOG_DATEFORMAT_PATTERN = "LOG_DATEFORMAT_PATTERN";
+  
+  private void setSystemProperty(PropertyResolver resolver, String systemPropertyName, String propertyName) {
+  	setSystemProperty(systemPropertyName, resolver.getProperty("logging." + propertyName)); // <X>
+  }
+  
+  private void setSystemProperty(String name, String value) {
+  	if (System.getProperty(name) == null && value != null) {
+  		System.setProperty(name, value);
+  	}
+  }
+  ```
+
+  - `<X>` 处，读取的是 `environment` 中的 `logging.` 开头的配置属性。
+
+# 5. LogFile
+
+`org.springframework.boot.logging.LogFile` ，日志文件。
+
+## 5.1 构造方法
+
+```
+// LogFile.java
+
+/**
+ * 文件名
+ */
+private final String file;
+/**
+ * 文件路径
+ */
+private final String path;
+```
+
+## 5.2 applyToSystemProperties
+
+`#applyToSystemProperties()` 方法，应用 `file`、`path` 到系统属性。代码如下：
+
+```
+// LogFile.java
+
+public static final String FILE_NAME_PROPERTY = "logging.file.name";
+public static final String FILE_PATH_PROPERTY = "logging.file.path";
+
+public void applyToSystemProperties() {
+	applyTo(System.getProperties());
+}
+
+public void applyTo(Properties properties) {
+	put(properties, LoggingSystemProperties.LOG_PATH, this.path);
+	put(properties, LoggingSystemProperties.LOG_FILE, toString());
+}
+```
+
+- ```
+  #toString()
+  ```
+
+   
+
+  方法，返回文件名。代码如下：
+
+  ```
+  // LogFile.java
+  
+  @Override
+  public String toString() {
+  	if (StringUtils.hasLength(this.file)) {
+  		return this.file;
+  	}
+  	return new File(this.path, "spring.log").getPath();
+  }
+  ```
+
+- ```
+  #put(Properties properties, String key, String value)
+  ```
+
+   
+
+  方法，添加属性值到系统属性。代码如下：
+
+  ```
+  // LogFile.java
+  
+  private void put(Properties properties, String key, String value) {
+  	if (StringUtils.hasLength(value)) {
+  		properties.put(key, value);
+  	}
+  }
+  ```
+
+## 5.3 get
+
+`#get(PropertyResolver propertyResolver)` 方法，获得（创建）LogFile 对象。代码如下：
+
+```
+// LogFile.java
+
+public static LogFile get(PropertyResolver propertyResolver) {
+    // <1> 获得 file 和 path 属性
+	String file = getLogFileProperty(propertyResolver, FILE_NAME_PROPERTY, FILE_PROPERTY);
+	String path = getLogFileProperty(propertyResolver, FILE_PATH_PROPERTY, PATH_PROPERTY);
+	// <2> 创建 LogFile 对象
+	if (StringUtils.hasLength(file) || StringUtils.hasLength(path)) {
+		return new LogFile(file, path);
+	}
+	return null;
+}
+```
+
+- ```
+  <1>
+  ```
+
+   
+
+  处，调用
+
+   
+
+  ```
+  #getLogFileProperty(PropertyResolver propertyResolver, String propertyName, String deprecatedPropertyName)
+  ```
+
+   
+
+  方法，获得
+
+   
+
+  ```
+  file
+  ```
+
+   
+
+  和
+
+   
+
+  ```
+  path
+  ```
+
+   
+
+  属性。代码如下：
+
+  ```
+  // LogFile.java
+  
+  private static String getLogFileProperty(PropertyResolver propertyResolver, String propertyName, String deprecatedPropertyName) {
+  	String property = propertyResolver.getProperty(propertyName);
+  	if (property != null) {
+  		return property;
+  	}
+  	return propertyResolver.getProperty(deprecatedPropertyName);
+  }
+  ```
+
+- `<2>` 处，创建 LogFile 对象。
+
+# 6. LogLevel
+
+`org.springframework.boot.logging.LogLevel` ，Spring Boot 日志枚举类。代码如下：
+
+```
+// LogLevel.java
+
+public enum LogLevel {
+
+	TRACE, DEBUG, INFO, WARN, ERROR, FATAL, OFF
+
+}
+```
+
+每个日志框架，都有其日志级别。通过 LogLevel 枚举类，和它们映射。
+
+# 7. LoggingSystem 的实现类
+
+## 7.1 NoOpLoggingSystem
+
+NoOpLoggingSystem ，是 LoggingSystem 的内部静态类，继承 LoggingSystem 类，空操作的 LoggingSystem 实现类，用于禁用日志系统的时候。代码如下：
+
+```
+// LoggingSystem#NoOpLoggingSystem.java
+
+static class NoOpLoggingSystem extends LoggingSystem {
+
+	@Override
+	public void beforeInitialize() {
+
+	}
+
+	@Override
+	public void setLogLevel(String loggerName, LogLevel level) {
+
+	}
+
+	@Override
+	public List<LoggerConfiguration> getLoggerConfigurations() {
+		return Collections.emptyList();
+	}
+
+	@Override
+	public LoggerConfiguration getLoggerConfiguration(String loggerName) {
+		return null;
+	}
+
+}
+```
+
+## 7.2 AbstractLoggingSystem
+
+`org.springframework.boot.logging.AbstractLoggingSystem` ，继承 LoggingSystem 抽象类，是 LoggingSystem 的抽象基类。
+
+### 7.2.1 构造方法
+
+```
+// AbstractLoggingSystem.java
+
+private final ClassLoader classLoader;
+
+public AbstractLoggingSystem(ClassLoader classLoader) {
+	this.classLoader = classLoader;
+}
+```
+
+### 7.2.2 initialize
+
+实现 `#initialize(LoggingInitializationContext initializationContext, String configLocation, LogFile logFile)` 方法，提供模板化的初始化逻辑。代码如下：
+
+```
+// AbstractLoggingSystem.java
+
+@Override
+public void initialize(LoggingInitializationContext initializationContext, String configLocation, LogFile logFile) {
+    // <1> 有自定义的配置文件，则使用指定配置文件进行初始化
+    if (StringUtils.hasLength(configLocation)) {
+        initializeWithSpecificConfig(initializationContext, configLocation, logFile);
+        return;
+    }
+    // <2> 无自定义的配置文件，则使用约定配置文件进行初始化
+    initializeWithConventions(initializationContext, logFile);
+}
+```
+
+- `<1>` 处，有自定义的配置文件，则调用 `#initializeWithSpecificConfig(LoggingInitializationContext initializationContext, String configLocation, LogFile logFile)` 方法，使用指定配置文件进行初始化。详细解析，见 [「7.2.2.1 initializeWithSpecificConfig」](https://svip.iocoder.cn/Spring-Boot/logger-system/#) 。
+- `<2>` 处，无自定义的配置文件，则调用 `#initializeWithConventions(LoggingInitializationContext initializationContext, LogFile logFile)` 方法，使用约定配置文件进行初始化。详细解析，见 [7.2.2.2 initializeWithConventions](https://svip.iocoder.cn/Spring-Boot/logger-system/#) 。
+
+#### 7.2.2.1 initializeWithSpecificConfig
+
+`#initializeWithSpecificConfig(LoggingInitializationContext initializationContext, String configLocation, LogFile logFile)` 方法，使用指定配置文件进行初始化。代码如下：
+
+```
+// AbstractLoggingSystem.java
+
+private void initializeWithSpecificConfig(LoggingInitializationContext initializationContext, String configLocation, LogFile logFile) {
+    // <1> 获得配置文件（可能有占位符）
+    configLocation = SystemPropertyUtils.resolvePlaceholders(configLocation);
+    // <2> 加载配置文件
+    loadConfiguration(initializationContext, configLocation, logFile);
+}
+```
+
+- `<1>` 处，获得配置文件（可能有占位符）。
+
+- ```
+  <2>
+  ```
+
+   
+
+  处，调用
+
+   
+
+  ```
+  #loadConfiguration(LoggingInitializationContext initializationContext, String location, LogFile logFile))
+  ```
+
+   
+
+  抽象
+
+  方法，加载配置文件。代码如下：
+
+  ```
+  // AbstractLoggingSystem.java
+  
+  /**
+   * Load a specific configuration.
+   * @param initializationContext the logging initialization context
+   * @param location the location of the configuration to load (never {@code null})
+   * @param logFile the file to load or {@code null} if no log file is to be written
+   */
+  protected abstract void loadConfiguration(LoggingInitializationContext initializationContext, String location, LogFile logFile);
+  ```
+
+#### 7.2.2.2 initializeWithConventions
+
+`#initializeWithConventions(LoggingInitializationContext initializationContext, LogFile logFile)` 方法，使用约定配置文件进行初始化。代码如下：
+
+```
+// AbstractLoggingSystem.java
+
+private void initializeWithConventions(LoggingInitializationContext initializationContext, LogFile logFile) {
+    // <1> 获得约定配置文件
+    String config = getSelfInitializationConfig();
+    // <2> 如果获取到，结果 logFile 为空，则重新初始化
+    if (config != null && logFile == null) {
+        // self initialization has occurred, reinitialize in case of property changes
+        reinitialize(initializationContext);
+        return;
+    }
+    // <3> 如果获取不到，则尝试获得约定配置文件（带 spring 后缀）
+    if (config == null) {
+        config = getSpringInitializationConfig();
+    }
+    // <4> 如果获取到，则加载配置文件
+    if (config != null) {
+        loadConfiguration(initializationContext, config, logFile);
+        return;
+    }
+    // <5> 如果获取不到，则加载默认配置
+    loadDefaults(initializationContext, logFile);
+}
+```
+
+- `<1>` 处，调用 `#getSelfInitializationConfig()` 方法，获得约定配置文件。代码如下：
+
+  ```
+  // AbstractLoggingSystem.java
+  
+  protected String getSelfInitializationConfig() {
+  	return findConfig(getStandardConfigLocations());
+  }
+  
+  protected abstract String[] getStandardConfigLocations();
+  
+  private String findConfig(String[] locations) {
+      // 遍历 locations 数组，逐个判断是否存在。若存在，则返回
+      for (String location : locations) {
+          ClassPathResource resource = new ClassPathResource(location, this.classLoader);
+          if (resource.exists()) {
+              return "classpath:" + location;
+          }
+      }
+      return null;
+  }
+  ```
+
+  - `#getStandardConfigLocations()` **抽象**方法，获得约定的配置文件。例如说：LogbackLoggingSystem 返回的是 `"logback-test.groovy"`、`"logback-test.xml"`、 `"logback.groovy"`、`"logback.xml"` 。
+
+- `<2>` 处，如果获取到，结果 `logFile` 为空，则调用 `#reinitialize(LoggingInitializationContext initializationContext)` 方法，重新初始化。代码如下：
+
+  ```
+  // AbstractLoggingSystem.java
+  
+  /**
+   * Reinitialize the logging system if required. Called when
+   * {@link #getSelfInitializationConfig()} is used and the log file hasn't changed. May
+   * be used to reload configuration (for example to pick up additional System
+   * properties).
+   * @param initializationContext the logging initialization context
+   */
+  protected void reinitialize(LoggingInitializationContext initializationContext) {
+  }
+  ```
+
+  - 一般情况下，`logFile` 非空~
+
+- `<3>` 处，如果获取不到，则调用 `#getSpringInitializationConfig()` 方法，尝试获得约定配置文件（带 `-spring` 后缀）。代码如下：
+
+  ```
+  // AbstractLoggingSystem.java
+  
+  /**
+   * Return any spring specific initialization config that should be applied. By default
+   * this method checks {@link #getSpringConfigLocations()}.
+   * @return the spring initialization config or {@code null}
+   */
+  protected String getSpringInitializationConfig() {
+  	return findConfig(getSpringConfigLocations());
+  }
+  
+  /**
+   * Return the spring config locations for this system. By default this method returns
+   * a set of locations based on {@link #getStandardConfigLocations()}.
+   * @return the spring config locations
+   * @see #getSpringInitializationConfig()
+   */
+  protected String[] getSpringConfigLocations() {
+  	String[] locations = getStandardConfigLocations();
+  	for (int i = 0; i < locations.length; i++) {
+  		String extension = StringUtils.getFilenameExtension(locations[i]);
+  		// 在文件名和后缀之间，拼接一个
+  		locations[i] = locations[i].substring(0, locations[i].length() - extension.length() - 1)
+                  + "-spring." + extension;
+  	}
+  	return locations;
+  }
+  ```
+
+  - 例如说：LogbackLoggingSystem 返回的是 `"logback-test-spring.groovy"`、`"logback-test-spring.xml"`、 `"logback-spring.groovy"`、`"logback-spring.xml"` 。
+
+- `<4>` 处，如果获取到，则调用 `#loadConfiguration(LoggingInitializationContext initializationContext, String location, LogFile logFile))` **抽象**方法，加载配置文件。
+
+- ```
+  <5>
+  ```
+
+   
+
+  处，如果获取不到，则调用
+
+   
+
+  ```
+  #loadDefaults(LoggingInitializationContext initializationContext, LogFile logFile)
+  ```
+
+   
+
+  抽象
+
+  方法，加载默认配置。代码如下：
+
+  ```
+  // AbstractLoggingSystem.java
+  
+  /**
+   * Load sensible defaults for the logging system.
+   * @param initializationContext the logging initialization context
+   * @param logFile the file to load or {@code null} if no log file is to be written
+   */
+  protected abstract void loadDefaults(LoggingInitializationContext initializationContext, LogFile logFile);
+  ```
+
+### 7.2.3 LogLevels
+
+LogLevels ，是 AbstractLoggingSystem 的内部静态类，用于 Spring Boot LogLevel 和日志框架的 LogLevel 做映射。代码如下：
+
+```
+// AbstractLoggingSystem#LogLevels.java
+
+/**
+ * Maintains a mapping between native levels and {@link LogLevel}.
+ *
+ * @param <T> the native level type
+ */
+protected static class LogLevels<T> {
+
+	private final Map<LogLevel, T> systemToNative;
+
+	private final Map<T, LogLevel> nativeToSystem;
+
+	public LogLevels() {
+		this.systemToNative = new EnumMap<>(LogLevel.class);
+		this.nativeToSystem = new HashMap<>();
+	}
+
+	public void map(LogLevel system, T nativeLevel) {
+		if (!this.systemToNative.containsKey(system)) {
+			this.systemToNative.put(system, nativeLevel);
+		}
+		if (!this.nativeToSystem.containsKey(nativeLevel)) {
+			this.nativeToSystem.put(nativeLevel, system);
+		}
+	}
+
+	public LogLevel convertNativeToSystem(T level) {
+		return this.nativeToSystem.get(level);
+	}
+
+	public T convertSystemToNative(LogLevel level) {
+		return this.systemToNative.get(level);
+	}
+
+	public Set<LogLevel> getSupported() {
+		return new LinkedHashSet<>(this.nativeToSystem.values());
+	}
+
+}
+```
+
+## 7.3 Slf4JLoggingSystem
+
+`org.springframework.boot.logging.Slf4JLoggingSystem` ，继承 AbstractLoggingSystem 抽象类，基于 Slf4J 的 LoggingSystem 的抽象基类。
+
+### 7.3.1 beforeInitialize
+
+重写 `#beforeInitialize()` 方法，代码如下：
+
+```
+// Slf4JLoggingSystem.java
+
+@Override
+public void beforeInitialize() {
+    // 父方法
+    super.beforeInitialize();
+    // <1> 配置 JUL 的桥接处理器
+    configureJdkLoggingBridgeHandler();
+}
+```
+
+- 因为艿艿没有特别完整的了解过日志框架，所以下面的解释，更多凭的是“直觉”！如果有错误的地方，给艿艿星球留言哈~
+- `<1>` 处，调用 `#configureJdkLoggingBridgeHandler()` 方法，配置 JUL 的桥接处理器。详细解析，见 [「7.3.1.1 configureJdkLoggingBridgeHandler」](https://svip.iocoder.cn/Spring-Boot/logger-system/#) 。
+
+#### 7.3.1.1 configureJdkLoggingBridgeHandler
+
+`#configureJdkLoggingBridgeHandler()` 方法，配置 JUL 的桥接处理器。代码如下：
+
+```
+// Slf4JLoggingSystem.java
+    
+private void configureJdkLoggingBridgeHandler() {
+    try {
+        // <1> 判断 JUL 是否桥接到 SLF4J 了
+        if (isBridgeJulIntoSlf4j()) {
+            // <2> 移除 JUL 桥接处理器
+            removeJdkLoggingBridgeHandler();
+            // <3> 重新安装 SLF4JBridgeHandler
+            SLF4JBridgeHandler.install();
+        }
+    } catch (Throwable ex) {
+        // Ignore. No java.util.logging bridge is installed.
+    }
+}
+```
+
+- `<1>` 处，调用 `#isBridgeJulIntoSlf4j()` 方法，判断 JUL 是否桥接到 SLF4J 了。代码如下：
+
+  ```
+  // Slf4JLoggingSystem.java
+  
+  private static final String BRIDGE_HANDLER = "org.slf4j.bridge.SLF4JBridgeHandler";
+  
+  /**
+   * Return whether bridging JUL into SLF4J or not.
+   * @return whether bridging JUL into SLF4J or not
+   * @since 2.0.4
+   */
+  protected final boolean isBridgeJulIntoSlf4j() {
+  	return isBridgeHandlerAvailable() // 判断是否存在 SLF4JBridgeHandler 类
+              && isJulUsingASingleConsoleHandlerAtMost(); // 判断是否 JUL 只有 ConsoleHandler 处理器被创建了
+  }
+  
+  protected final boolean isBridgeHandlerAvailable() {
+  	return ClassUtils.isPresent(BRIDGE_HANDLER, getClassLoader());
+  }
+  
+  private boolean isJulUsingASingleConsoleHandlerAtMost() {
+  	Logger rootLogger = LogManager.getLogManager().getLogger("");
+  	Handler[] handlers = rootLogger.getHandlers();
+  	return handlers.length == 0
+  			|| (handlers.length == 1 && handlers[0] instanceof ConsoleHandler);
+  }
+  ```
+
+  - 第一个方法，调用后面的两个方法判断~
+
+- `<2>` 处，调用 `#removeJdkLoggingBridgeHandler()` 方法，移除 JUL 桥接处理器。代码如下：
+
+  ```
+  // Slf4JLoggingSystem.java
+  
+  private void removeJdkLoggingBridgeHandler() {
+  	try {
+  		// 移除 JUL 的 ConsoleHandler
+  		removeDefaultRootHandler();
+  		// 卸载 SLF4JBridgeHandler
+  		SLF4JBridgeHandler.uninstall();
+  	} catch (Throwable ex) {
+  		// Ignore and continue
+  	}
+  }
+  
+  private void removeDefaultRootHandler() {
+  	try {
+  		Logger rootLogger = LogManager.getLogManager().getLogger("");
+  		Handler[] handlers = rootLogger.getHandlers();
+  		if (handlers.length == 1 && handlers[0] instanceof ConsoleHandler) {
+  			rootLogger.removeHandler(handlers[0]);
+  		}
+  	} catch (Throwable ex) {
+  		// Ignore and continue
+  	}
+  }
+  ```
+
+  - 移除 JUL 的 ConsoleHandler ，卸载 SLF4JBridgeHandler 。
+
+- `<3>` 处，会重新安装 SLF4JBridgeHandler。
+
+### 7.3.2 cleanUp
+
+重写 `#cleanUp()` 方法，代码如下：
+
+```
+// Slf4JLoggingSystem.java
+
+@Override
+public void cleanUp() {
+    // 判断 JUL 是否桥接到 SLF4J 了
+    if (isBridgeHandlerAvailable()) {
+        // 移除 JUL 桥接处理器
+        removeJdkLoggingBridgeHandler();
+    }
+}
+```
+
+### 7.3.3 loadConfiguration
+
+重写 `#loadConfiguration(LoggingInitializationContext initializationContext, String location, LogFile logFile)` 方法，代码如下：
+
+```
+// Slf4JLoggingSystem.java
+
+@Override
+protected void loadConfiguration(LoggingInitializationContext initializationContext, String location, LogFile logFile) {
+	Assert.notNull(location, "Location must not be null");
+	if (initializationContext != null) {
+		applySystemProperties(initializationContext.getEnvironment(), logFile);
+	}
+}
+```
+
+- 调用 `#applySystemProperties(Environment environment, LogFile logFile)` 方法，应用 `environment` 和 `logFile` 的属性，到系统属性种。在 [「4.2 apply」](https://svip.iocoder.cn/Spring-Boot/logger-system/#) 中，已经详细解析。
+- 不过有一点，搞不懂，为什么这么实现。
+
+## 7.4 LogbackLoggingSystem
+
+`org.springframework.boot.logging.logback.LogbackLoggingSystem` ，继承 Slf4JLoggingSystem 抽象类，基于 Logback 的 LoggingSystem 实现类。
+
+### 7.4.1 beforeInitialize
+
+重写 `#beforeInitialize()` 方法，代码如下：
+
+```
+// LogbackLoggingSystem.java
+
+@Override
+public void beforeInitialize() {
+    // <1.1> 获得 LoggerContext 对象
+    LoggerContext loggerContext = getLoggerContext();
+    // <1.2> 如果已经初始化过，则直接返回
+    if (isAlreadyInitialized(loggerContext)) {
+        return;
+    }
+    // <2> 调用父方法
+    super.beforeInitialize();
+    // <3> 添加 FILTER 到其中
+    loggerContext.getTurboFilterList().add(FILTER);
+}
+```
+
+- ```
+  <1.1>
+  ```
+
+   
+
+  处，调用
+
+   
+
+  ```
+  #getLoggerContext()
+  ```
+
+   
+
+  方法，获得 LoggerContext 对象。代码如下：
+
+  ```
+  // LogbackLoggingSystem.java
+  
+  private LoggerContext getLoggerContext() {
+  	ILoggerFactory factory = StaticLoggerBinder.getSingleton().getLoggerFactory();
+  	Assert.isInstanceOf(LoggerContext.class, factory,
+  			String.format(
+  					"LoggerFactory is not a Logback LoggerContext but Logback is on "
+  							+ "the classpath. Either remove Logback or the competing "
+  							+ "implementation (%s loaded from %s). If you are using "
+  							+ "WebLogic you will need to add 'org.slf4j' to "
+  							+ "prefer-application-packages in WEB-INF/weblogic.xml",
+  					factory.getClass(), getLocation(factory)));
+  	return (LoggerContext) factory;
+  }
+  ```
+
+- ```
+  <1.2>
+  ```
+
+   
+
+  处，调用
+
+   
+
+  ```
+  #isAlreadyInitialized(LoggerContext loggerContext)
+  ```
+
+   
+
+  方法，判断如果已经初始化过，则直接返回。代码如下：
+
+  ```
+  // LogbackLoggingSystem.java
+  
+  private boolean isAlreadyInitialized(LoggerContext loggerContext) {
+  	return loggerContext.getObject(LoggingSystem.class.getName()) != null;
+  }
+  ```
+
+- `<2>` 处，调用父方法。
+
+- `<3>` 处，添加 `FILTER` 到 `loggerContext` 其中。代码如下：
+
+  ```
+  // LogbackLoggingSystem.java
+  
+  private static final TurboFilter FILTER = new TurboFilter() {
+  
+  	@Override
+  	public FilterReply decide(Marker marker, ch.qos.logback.classic.Logger logger,
+  			Level level, String format, Object[] params, Throwable t) {
+  		return FilterReply.DENY;
+  	}
+  
+  };
+  ```
+
+  - 因为此时，Logback 并未初始化好，所以全部返回 `FilterReply.DENY` 。即，先不打印日志。
+
+### 7.4.2 getStandardConfigLocations
+
+实现 `#getStandardConfigLocations()` 方法，获得约定的配置文件的数组。代码如下：
+
+```
+// LogbackLoggingSystem.java
+
+@Override
+protected String[] getStandardConfigLocations() {
+	return new String[] { "logback-test.groovy", "logback-test.xml", "logback.groovy",
+			"logback.xml" };
+}
+```
+
+### 7.4.3 initialize
+
+重写 `#initialize(LoggingInitializationContext initializationContext, String configLocation, LogFile logFile)` 方法，代码如下：
+
+```
+// LogbackLoggingSystem.java
+
+private static final String CONFIGURATION_FILE_PROPERTY = "logback.configurationFile";
+
+@Override
+public void initialize(LoggingInitializationContext initializationContext, String configLocation, LogFile logFile) {
+    // <1> 如果已经初始化，则返回
+    LoggerContext loggerContext = getLoggerContext();
+    if (isAlreadyInitialized(loggerContext)) {
+        return;
+    }
+    // <2> 调用父方法
+    super.initialize(initializationContext, configLocation, logFile);
+    // <3> 移除 FILTER
+    loggerContext.getTurboFilterList().remove(FILTER);
+    // <4> 标记已经初始化
+    markAsInitialized(loggerContext);
+    // <5> 如果配置了 logback.configurationFile ，则打印日志
+    if (StringUtils.hasText(System.getProperty(CONFIGURATION_FILE_PROPERTY))) {
+        getLogger(LogbackLoggingSystem.class.getName()).warn("Ignoring '" + CONFIGURATION_FILE_PROPERTY + "' system property. " + "Please use 'logging.config' instead.");
+    }
+}
+```
+
+- `<1>` 处，如果已经初始化，则返回。
+
+- `<2>` 处，调用父方法，进行初始化。
+
+- `<3>` 处，从 `loggerContext` 中，移除 `FILTER` 。😈 如果不移除，就一直打印不出日志列。
+
+- `<4>` 处，调用 `#markAsInitialized(LoggerContext loggerContext)` 方法，标记已经初始化。代码如下：
+
+  ```
+  // LogbackLoggingSystem.java
+  
+  private void markAsInitialized(LoggerContext loggerContext) {
+  	loggerContext.putObject(LoggingSystem.class.getName(), new Object());
+  }
+  ```
+
+- `<5>` 处，如果配置了 `"logback.configurationFile"` ，则打印日志。
+
+#### 7.4.3.1 loadConfiguration
+
+实现 `#loadConfiguration(LoggingInitializationContext initializationContext, String location, LogFile logFile)` 方法，代码如下：
+
+```
+// LogbackLoggingSystem.java
+
+@Override
+protected void loadConfiguration(LoggingInitializationContext initializationContext, String location, LogFile logFile) {
+    // <1> 调用父方法
+    super.loadConfiguration(initializationContext, location, logFile);
+    // <2> 重置
+    LoggerContext loggerContext = getLoggerContext();
+    stopAndReset(loggerContext);
+    // <3> 读取配置文件，并进行配置
+    try {
+        configureByResourceUrl(initializationContext, loggerContext, ResourceUtils.getURL(location));
+    } catch (Exception ex) {
+        throw new IllegalStateException("Could not initialize Logback logging from " + location, ex);
+    }
+    // <4> 判断是否发生错误。如果有，则抛出 IllegalStateException 异常
+    List<Status> statuses = loggerContext.getStatusManager().getCopyOfStatusList();
+    StringBuilder errors = new StringBuilder();
+    for (Status status : statuses) {
+        if (status.getLevel() == Status.ERROR) {
+            errors.append((errors.length() > 0) ? String.format("%n") : "");
+            errors.append(status.toString());
+        }
+    }
+    if (errors.length() > 0) {
+        throw new IllegalStateException(String.format("Logback configuration error detected: %n%s", errors));
+    }
+}
+```
+
+- `<1>` 处，调用父方法。
+
+- `<2>` 处，调用 `#stopAndReset(LoggerContext loggerContext)` 方法，重置。代码如下：
+
+  ```
+  // LogbackLoggingSystem.java
+  
+  private void stopAndReset(LoggerContext loggerContext) {
+      // 停止
+      loggerContext.stop();
+      // 重置
+      loggerContext.reset();
+      // 如果是 SLF4J 桥接
+      if (isBridgeHandlerInstalled()) {
+          // 添加 LevelChangePropagator
+          addLevelChangePropagator(loggerContext);
+      }
+  }
+  
+  private boolean isBridgeHandlerInstalled() {
+      if (!isBridgeHandlerAvailable()) {
+          return false;
+      }
+      java.util.logging.Logger rootLogger = LogManager.getLogManager().getLogger("");
+      Handler[] handlers = rootLogger.getHandlers();
+      // 判断有 SLF4JBridgeHandler 唯一元素
+      return handlers.length == 1 && handlers[0] instanceof SLF4JBridgeHandler;
+  }
+  
+  private void addLevelChangePropagator(LoggerContext loggerContext) {
+      // 创建 LevelChangePropagator 对象（见 https://cloud.tencent.com/developer/ask/174323 说明）
+      LevelChangePropagator levelChangePropagator = new LevelChangePropagator();
+      // 设置属性
+      levelChangePropagator.setResetJUL(true);
+      levelChangePropagator.setContext(loggerContext);
+      // 添加 LevelChangePropagator 到 loggerContext 中
+      loggerContext.addListener(levelChangePropagator);
+  }
+  ```
+
+  - 通过阅读 https://cloud.tencent.com/developer/ask/174323 文章，我们能弄懂这里为什么要使用 LevelChangePropagator ，以及 [「7.3.1.1 configureJdkLoggingBridgeHandler」](https://svip.iocoder.cn/Spring-Boot/logger-system/#) 处的原因。
+
+- `<3>` 处，调用 `#configureByResourceUrl(LoggingInitializationContext initializationContext, LoggerContext loggerContext, URL url)` 方法，读取配置文件，并进行配置。代码如下：
+
+  ```
+  // LogbackLoggingSystem.java
+  
+  private void configureByResourceUrl(LoggingInitializationContext initializationContext, LoggerContext loggerContext, URL url) throws JoranException {
+      // <X> 如果是 xml 配置格式，则使用 SpringBootJoranConfigurator
+      if (url.toString().endsWith("xml")) {
+          JoranConfigurator configurator = new SpringBootJoranConfigurator(initializationContext);
+          configurator.setContext(loggerContext);
+          configurator.doConfigure(url);
+      // 如果是其它格式，则使用 ContextInitializer
+      } else {
+          new ContextInitializer(loggerContext).configureByResource(url);
+      }
+  }
+  ```
+
+  - `<X>` 处，如果是 Logback xml 配置格式，则使用 SpringBootJoranConfigurator 类。
+  - 至此，Logback 配置文件，就已经被读完落。
+
+- `<4>` 处，判断是否发生错误。如果有，则抛出 IllegalStateException 异常。
+
+##### 7.4.3.1.1 SpringBootJoranConfigurator
+
+`org.springframework.boot.logging.logback.SpringBootJoranConfigurator` ，继承 JoranConfigurator 类，增加 Spring Boot 自定义的标签。代码如下：
+
+```
+// SpringBootJoranConfigurator.java
+
+class SpringBootJoranConfigurator extends JoranConfigurator {
+
+	private LoggingInitializationContext initializationContext;
+
+	SpringBootJoranConfigurator(LoggingInitializationContext initializationContext) {
+		this.initializationContext = initializationContext;
+	}
+
+	@Override
+	public void addInstanceRules(RuleStore rs) {
+	    // 调用父方法
+		super.addInstanceRules(rs);
+		Environment environment = this.initializationContext.getEnvironment();
+		rs.addRule(new ElementSelector("configuration/springProperty"), new SpringPropertyAction(environment));
+		rs.addRule(new ElementSelector("*/springProfile"), new SpringProfileAction(environment));
+		rs.addRule(new ElementSelector("*/springProfile/*"), new NOPAction());
+	}
+
+}
+```
+
+- 不了解的胖友，可以先看看 [《SpringBoot 中 logback.xml 使用 application.yml 中属性》](https://www.cnblogs.com/jianliang-Wu/p/8945343.html) 文章。
+- [`org.springframework.boot.logging.logback.SpringProfileAction`](https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/logging/logback/SpringProfileAction.java) ，处理 `<springProfile />` 标签。
+- [`org.springframework.boot.logging.logback.SpringPropertyAction`](https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/logging/logback/SpringPropertyAction.java) ，处理 `<springProperty />` 标签。
+
+#### 7.4.3.2 reinitialize
+
+实现 `#reinitialize(LoggingInitializationContext initializationContext)` 方法，代码如下：
+
+```
+// LogbackLoggingSystem.java
+
+@Override
+protected void reinitialize(LoggingInitializationContext initializationContext) {
+	// <1> 重置
+	getLoggerContext().reset();
+	// <2> 清空 StatusManager
+	getLoggerContext().getStatusManager().clear();
+	// <3> 加载配置
+	loadConfiguration(initializationContext, getSelfInitializationConfig(), null);
+}
+```
+
+- `<1>` 处，重置。
+- `<2>` 处，清空 StatusManager 。
+- `<3>` 处，调用 `#loadConfiguration(LoggingInitializationContext initializationContext, String location, LogFile logFile)` 方法，加载配置。此时，使用的是约定的 Logback 配置文件。
+
+#### 7.4.3.3 loadDefaults
+
+实现 `#loadDefaults(LoggingInitializationContext initializationContext, LogFile logFile)` 方法，代码如下：
+
+```
+// LogbackLoggingSystem.java
+
+@Override
+protected void loadDefaults(LoggingInitializationContext initializationContext, LogFile logFile) {
+    // <1> 重置
+    LoggerContext context = getLoggerContext();
+    stopAndReset(context);
+    // <2> 创建 LogbackConfigurator 对象
+    LogbackConfigurator configurator = new LogbackConfigurator(context);
+    // <3> 从 environment 读取变量，设置到 context 中。
+    Environment environment = initializationContext.getEnvironment();
+    context.putProperty(LoggingSystemProperties.LOG_LEVEL_PATTERN, environment.resolvePlaceholders("${logging.pattern.level:${LOG_LEVEL_PATTERN:%5p}}"));
+    context.putProperty(LoggingSystemProperties.LOG_DATEFORMAT_PATTERN, environment.resolvePlaceholders("${logging.pattern.dateformat:${LOG_DATEFORMAT_PATTERN:yyyy-MM-dd HH:mm:ss.SSS}}"));
+    // <4> 创建 DefaultLogbackConfiguration 对象，设置到 configurator 中
+    new DefaultLogbackConfiguration(initializationContext, logFile).apply(configurator);
+    // <5> 设置日志文件，按天滚动
+    context.setPackagingDataEnabled(true);
+}
+```
+
+- `<1>` 处，调用 `#stopAndReset(LoggerContext loggerContext)` 方法，重置。
+- `<2>` 处，创建 LogbackConfigurator 对象。详细解析，见 [「7.4.3.3.1 LogbackConfigurator」](https://svip.iocoder.cn/Spring-Boot/logger-system/#) 。
+- `<3>` 处，从 `environment` 读取变量，设置到 `context` 中。
+- `<4>` 处，创建 DefaultLogbackConfiguration 对象，后调用 `DefaultLogbackConfiguration#apply(LogbackConfigurator)` 方法，设置到 `configurator` 中。详细解析，见 [「7.4.3.3.2 DefaultLogbackConfiguration」](https://svip.iocoder.cn/Spring-Boot/logger-system/#) 。
+- `<5>` 处，调用 `LoggerContext#setPackagingDataEnabled(boolean packagingDataEnabled)` 方法，设置日志文件，按天滚动。
+
+##### 7.4.3.3.1 LogbackConfigurator
+
+`org.springframework.boot.logging.logback.LogbackConfigurator` ，Logback 配置器，提供一些工具方法，方便配置 Logback 。
+
+因为 LogbackConfigurator 提供的方法，都是被 DefaultLogbackConfiguration 所调用。所以我们先跳到 [「7.4.3.3.2 DefaultLogbackConfiguration」](https://svip.iocoder.cn/Spring-Boot/logger-system/#) 中。
+
+###### 7.4.3.3.1.1 conversionRule
+
+`#conversionRule(String conversionWord, Class<? extends Converter> converterClass)` 方法，添加转换规则。代码如下：
+
+```
+// LogbackConfigurator.java
+
+public void conversionRule(String conversionWord, Class<? extends Converter> converterClass) {
+    Assert.hasLength(conversionWord, "Conversion word must not be empty");
+    Assert.notNull(converterClass, "Converter class must not be null");
+    // 获得注册表
+    Map<String, String> registry = (Map<String, String>) this.context.getObject(CoreConstants.PATTERN_RULE_REGISTRY);
+    // 如果注册表为空，则进行注册
+    if (registry == null) {
+        registry = new HashMap<>();
+        this.context.putObject(CoreConstants.PATTERN_RULE_REGISTRY, registry);
+    }
+    // 添加转换规则，到注册表中
+    registry.put(conversionWord, converterClass.getName());
+}
+```
+
+- 比较简单，胖友自己瞅瞅。
+- 目前有三个转换规则，分别是：
+  - [org.springframework.boot.logging.logback.ColorConverter](https://github.com/YunaiV/spring-boot/blob/master/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/logging/logback/ColorConverter.java) ，实现 ANSI 颜色转换器。
+  - [org.springframework.boot.logging.logback.ExtendedWhitespaceThrowableProxyConverter](https://github.com/YunaiV/spring-boot/blob/master/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/logging/logback/ExtendedWhitespaceThrowableProxyConverter.java) ，在异常堆栈的打印过程中添加一些空格。
+  - [org.springframework.boot.logging.logback.ExtendedWhitespaceThrowableProxyConverter](https://github.com/YunaiV/spring-boot/blob/master/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/logging/logback/ExtendedWhitespaceThrowableProxyConverter.java) ，在异常堆栈的打印过程中添加一些空格。
+  - [org.springframework.boot.logging.logback.WhitespaceThrowableProxyConverter](https://github.com/YunaiV/spring-boot/blob/master/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/logging/logback/WhitespaceThrowableProxyConverter.java) ，在异常堆栈的打印过程中添加一些空格。【同上】
+  - 就不详细解析啦，胖友自己瞅瞅就明白列。
+
+###### 7.4.3.3.1.2 logger
+
+`#logger(String name, Level level)` 方法，添加 Logger 。代码如下：
+
+```
+// LogbackConfigurator.java
+
+public void logger(String name, Level level) {
+    logger(name, level, true);
+}
+
+public void logger(String name, Level level, boolean additive) {
+    logger(name, level, additive, null);
+}
+
+public void logger(String name, Level level, boolean additive, Appender<ILoggingEvent> appender) {
+    // 获得 Logger 对象
+    Logger logger = this.context.getLogger(name);
+    // 设置 level
+    if (level != null) {
+        logger.setLevel(level);
+    }
+    // 设置 additive
+    logger.setAdditive(additive);
+    // 设置 appender
+    if (appender != null) {
+        logger.addAppender(appender);
+    }
+}
+```
+
+###### 7.4.3.3.1.3 appender
+
+`#appender(String name, Appender<?> appender)` 方法，启动 Appender 。代码如下：
+
+```
+// LogbackConfigurator.java
+
+public void appender(String name, Appender<?> appender) {
+	// 设置 name
+	appender.setName(name);
+	// 启动 Appender
+	start(appender);
+}
+
+public void start(LifeCycle lifeCycle) {
+    // 设置 context
+    if (lifeCycle instanceof ContextAware) {
+        ((ContextAware) lifeCycle).setContext(this.context);
+    }
+    // 启动
+    lifeCycle.start();
+}
+```
+
+###### 7.4.3.3.1.4 root
+
+`#root(Level level, Appender<ILoggingEvent>... appenders)` 方法，设置 appender 到 ROOT Logger 。代码如下：
+
+```
+// LogbackConfigurator.java
+
+public final void root(Level level, Appender<ILoggingEvent>... appenders) {
+    // 获得 Root Logger 对象
+    Logger logger = this.context.getLogger(org.slf4j.Logger.ROOT_LOGGER_NAME);
+    // 设置 level
+    if (level != null) {
+        logger.setLevel(level);
+    }
+    // 添加 appender 到 logger 中
+    for (Appender<ILoggingEvent> appender : appenders) {
+        logger.addAppender(appender);
+    }
+}
+```
+
+##### 7.4.3.3.2 DefaultLogbackConfiguration
+
+`org.springframework.boot.logging.logback.DefaultLogbackConfiguration` ，默认的 Logback 配置类。代码如下：
+
+> 相当于代码生成 `logback.xml` 的效果。
+
+##### 7.4.3.3.2.1 构造方法
+
+```
+// DefaultLogbackConfiguration.java
+
+/**
+ * PropertyResolver 对象。提供从 environment 解析配置
+ */
+private final PropertyResolver patterns;
+
+private final LogFile logFile;
+
+DefaultLogbackConfiguration(LoggingInitializationContext initializationContext, LogFile logFile) {
+    this.patterns = getPatternsResolver(initializationContext.getEnvironment());
+    this.logFile = logFile;
+}
+
+private PropertyResolver getPatternsResolver(Environment environment) {
+    // 创建 PropertySourcesPropertyResolver 对象，无 environment
+    if (environment == null) {
+        return new PropertySourcesPropertyResolver(null);
+    }
+    // 创建 PropertySourcesPropertyResolver 对象，有 environment
+    if (environment instanceof ConfigurableEnvironment) {
+        PropertySourcesPropertyResolver resolver = new PropertySourcesPropertyResolver(((ConfigurableEnvironment) environment).getPropertySources());
+        resolver.setIgnoreUnresolvableNestedPlaceholders(true);
+        return resolver;
+    }
+    // 直接返回 environment
+    return environment;
+}
+```
+
+##### 7.4.3.3.2.2 apply
+
+`#apply(LogbackConfigurator config)` 方法，应用配置。代码如下：
+
+```
+// DefaultLogbackConfiguration.java
+
+public void apply(LogbackConfigurator config) {
+    // <1> 锁
+    synchronized (config.getConfigurationLock()) {
+        // <2> 设置基础属性
+        base(config);
+        // <3> 创建 console Appender
+        Appender<ILoggingEvent> consoleAppender = consoleAppender(config);
+        // <4> 如果 logFile 非空，则创建 file Appender
+        if (this.logFile != null) {
+            Appender<ILoggingEvent> fileAppender = fileAppender(config, this.logFile.toString());
+            // <5> 设置 appender 到 ROOT Logger
+            config.root(Level.INFO, consoleAppender, fileAppender);
+        } else {
+            // <5> 设置 appender 到 ROOT Logger
+            config.root(Level.INFO, consoleAppender);
+        }
+    }
+}
+```
+
+- `<1>` 处，锁。代码如下：
+
+  ```
+  // LogbackConfigurator.java
+  
+  private LoggerContext context;
+  
+  public Object getConfigurationLock() {
+  	return this.context.getConfigurationLock();
+  }
+  ```
+
+- `<2>` 处，调用 `#base(LogbackConfigurator config)` 方法，设置基础属性。代码如下：
+
+  ```
+  // LogbackConfigurator.java
+  
+  private void base(LogbackConfigurator config) {
+  	// <2.1> Converter
+  	config.conversionRule("clr", ColorConverter.class);
+  	config.conversionRule("wex", WhitespaceThrowableProxyConverter.class);
+  	config.conversionRule("wEx", ExtendedWhitespaceThrowableProxyConverter.class);
+  	// <2.2> 默认的 logger
+  	config.logger("org.apache.catalina.startup.DigesterFactory", Level.ERROR);
+  	config.logger("org.apache.catalina.util.LifecycleBase", Level.ERROR);
+  	config.logger("org.apache.coyote.http11.Http11NioProtocol", Level.WARN);
+  	config.logger("org.apache.sshd.common.util.SecurityUtils", Level.WARN);
+  	config.logger("org.apache.tomcat.util.net.NioSelectorPool", Level.WARN);
+  	config.logger("org.eclipse.jetty.util.component.AbstractLifeCycle", Level.ERROR);
+  	config.logger("org.hibernate.validator.internal.util.Version", Level.WARN);
+  }
+  ```
+
+  - `<2.1>` 处，调用 `LogbackConfigurator#conversionRule(String conversionWord, Class<? extends Converter> converterClass)` 方法，添加转换规则。详细解析，见 [「 7.4.3.3.1.1 conversionRule」](https://svip.iocoder.cn/Spring-Boot/logger-system/#) 。
+  - `<2.2>` 处，调用 `LogbackConfigurator#logger(String name, Level level)` 方法，默认的 logger 。详细解析，见 [「7.4.3.3.1.2 logger」](https://svip.iocoder.cn/Spring-Boot/logger-system/#) 。
+
+- `<3>` 处，调用 `#consoleAppender(LogbackConfigurator config)` 方法，创建 console Appender 对象。代码如下：
+
+  ```
+  // LogbackConfigurator.java
+  
+  private static final String CONSOLE_LOG_PATTERN = "%clr(%d{${LOG_DATEFORMAT_PATTERN:-yyyy-MM-dd HH:mm:ss.SSS}}){faint} "
+  		+ "%clr(${LOG_LEVEL_PATTERN:-%5p}) %clr(${PID:- }){magenta} %clr(---){faint} "
+  		+ "%clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} "
+  		+ "%clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:-%wEx}";
+  
+  private Appender<ILoggingEvent> consoleAppender(LogbackConfigurator config) {
+  	ConsoleAppender<ILoggingEvent> appender = new ConsoleAppender<>();
+  	PatternLayoutEncoder encoder = new PatternLayoutEncoder();
+  	String logPattern = this.patterns.getProperty("logging.pattern.console", CONSOLE_LOG_PATTERN); // <X>
+  	encoder.setPattern(OptionHelper.substVars(logPattern, config.getContext()));
+  	config.start(encoder);
+  	appender.setEncoder(encoder);
+  	config.appender("CONSOLE", appender); // <Y>
+  	return appender;
+  }
+  ```
+
+  - `<X>` 处，从 `environment` 中，读取 `"logging.pattern.console"` 作为格式。如果找不到，使用 `CONSOLE_LOG_PATTERN` 。
+  - `<Y>` 处，调用 `LogbackConfigurator#appender(String name, Appender<?> appender)` 方法，启动 Appender 。详细解析，见 [「7.4.3.3.1.3 appender」](https://svip.iocoder.cn/Spring-Boot/logger-system/#) 。
+
+- `<4>` 处，如果 `logFile` 非空，则调用 `#fileAppender(LogbackConfigurator config, String logFile)` 方法，创建 file Appender。代码如下：
+
+  ```
+   // LogbackConfigurator.java
+   
+   private static final String FILE_LOG_PATTERN = "%d{${LOG_DATEFORMAT_PATTERN:-yyyy-MM-dd HH:mm:ss.SSS}} "
+  + "${LOG_LEVEL_PATTERN:-%5p} ${PID:- } --- [%t] %-40.40logger{39} : %m%n${LOG_EXCEPTION_CONVERSION_WORD:-%wEx}";
+  
+   private static final String MAX_FILE_SIZE = "10MB";
+   
+   private Appender<ILoggingEvent> fileAppender(LogbackConfigurator config, String logFile) {
+   	RollingFileAppender<ILoggingEvent> appender = new RollingFileAppender<>();
+   	PatternLayoutEncoder encoder = new PatternLayoutEncoder();
+   	String logPattern = this.patterns.getProperty("logging.pattern.file", FILE_LOG_PATTERN);
+   	encoder.setPattern(OptionHelper.substVars(logPattern, config.getContext()));
+   	appender.setEncoder(encoder);
+   	config.start(encoder);
+   	appender.setFile(logFile);
+   	// 滚动策略
+   	setRollingPolicy(appender, config, logFile);
+   	config.appender("FILE", appender);
+   	return appender;
+   }
+   
+   private void setRollingPolicy(RollingFileAppender<ILoggingEvent> appender, LogbackConfigurator config, String logFile) {
+   	SizeAndTimeBasedRollingPolicy<ILoggingEvent> rollingPolicy = new SizeAndTimeBasedRollingPolicy<>();
+   	rollingPolicy.setFileNamePattern(logFile + ".%d{yyyy-MM-dd}.%i.gz");
+   	// 单文件最大值
+   	setMaxFileSize(rollingPolicy, this.patterns.getProperty("logging.file.max-size", MAX_FILE_SIZE));
+   	rollingPolicy.setMaxHistory(this.patterns.getProperty("logging.file.max-history", Integer.class, CoreConstants.UNBOUND_HISTORY));
+   	appender.setRollingPolicy(rollingPolicy);
+   	rollingPolicy.setParent(appender);
+   	config.start(rollingPolicy);
+   }
+   
+   private void setMaxFileSize(SizeAndTimeBasedRollingPolicy<ILoggingEvent> rollingPolicy, String maxFileSize) {
+   	try {
+   		rollingPolicy.setMaxFileSize(FileSize.valueOf(maxFileSize));
+   	} catch (NoSuchMethodError ex) {
+   		// Logback < 1.1.8 used String configuration
+   		Method method = ReflectionUtils.findMethod(SizeAndTimeBasedRollingPolicy.class, "setMaxFileSize", String.class);
+   		ReflectionUtils.invokeMethod(method, rollingPolicy, maxFileSize);
+   	}
+   }
+  ```
+
+- `<5>` 处，调用 `LogbackConfigurator#root(Level level, Appender<ILoggingEvent>... appenders)` 方法，设置 appender 到 ROOT Logger 。详细解析，见 [「7.4.3.3.1.4 root」](https://svip.iocoder.cn/Spring-Boot/logger-system/#) 。
+
+### 7.4.4 setLogLevel
+
+实现 `#setLogLevel(String loggerName, LogLevel level)` 方法，代码如下：
+
+```
+// LogbackLoggingSystem.java
+
+private static final LogLevels<Level> LEVELS = new LogLevels<>();
+
+static {
+	LEVELS.map(LogLevel.TRACE, Level.TRACE);
+	LEVELS.map(LogLevel.TRACE, Level.ALL);
+	LEVELS.map(LogLevel.DEBUG, Level.DEBUG);
+	LEVELS.map(LogLevel.INFO, Level.INFO);
+	LEVELS.map(LogLevel.WARN, Level.WARN);
+	LEVELS.map(LogLevel.ERROR, Level.ERROR);
+	LEVELS.map(LogLevel.FATAL, Level.ERROR);
+	LEVELS.map(LogLevel.OFF, Level.OFF);
+}
+
+@Override
+public void setLogLevel(String loggerName, LogLevel level) {
+	// <1> 获得 Logger 对象
+	ch.qos.logback.classic.Logger logger = getLogger(loggerName);
+	// <2> 设置日志级别
+	if (logger != null) {
+		logger.setLevel(LEVELS.convertSystemToNative(level));
+	}
+}
+```
+
+- ```
+  <1>
+  ```
+
+   
+
+  处，调用
+
+   
+
+  ```
+  #getLogger(String name)
+  ```
+
+   
+
+  方法，获得 Logger 对象。代码如下：
+
+  ```
+  // LogbackLoggingSystem.java
+  
+  private ch.qos.logback.classic.Logger getLogger(String name) {
+  	LoggerContext factory = getLoggerContext();
+  	if (StringUtils.isEmpty(name) || ROOT_LOGGER_NAME.equals(name)) {
+  		name = Logger.ROOT_LOGGER_NAME;
+  	}
+  	return factory.getLogger(name);
+  
+  }
+  ```
+
+- `<2>` 处，设置日志级别。
+
+### 7.4.4 cleanUp
+
+重写 `#cleanUp()` 方法，代码如下：
+
+```
+// LogbackLoggingSystem.java
+
+@Override
+public void cleanUp() {
+	// 标记为未初始化
+	LoggerContext context = getLoggerContext();
+	markAsUninitialized(context);
+	// 调用父方法
+	super.cleanUp();
+	// 清空 StatusManager
+	context.getStatusManager().clear();
+	// 移除 FILTER
+	context.getTurboFilterList().remove(FILTER);
+}
+
+private void markAsUninitialized(LoggerContext loggerContext) {
+	loggerContext.removeObject(LoggingSystem.class.getName());
+}
+```
+
+### 7.4.5 getShutdownHandler
+
+实现 `#getShutdownHandler()` 方法，代码如下：
+
+```
+// LogbackLoggingSystem.java
+
+@Override
+public Runnable getShutdownHandler() {
+	return new ShutdownHandler();
+}
+
+private final class ShutdownHandler implements Runnable {
+
+	@Override
+	public void run() {
+		getLoggerContext().stop(); // 停止
+	}
+
+}
+```
+
+## 7.5 Log4J2LoggingSystem
+
+`org.springframework.boot.logging.log4j2.Log4J2LoggingSystem` ，继承 Slf4JLoggingSystem 抽象类，基于 Log4J2 的 LoggingSystem 实现类。
+
+就暂时不解析了，基本类似。感兴趣的胖友，可以看看 [《spring boot 源码解析28-Log4J2LoggingSystem》](https://blog.csdn.net/qq_26000415/article/details/79109517) 。
+
+## 7.6 JavaLoggingSystem
+
+`org.springframework.boot.logging.java.JavaLoggingSystem` ，继承 AbstractLoggingSystem 抽象类，基于 JUL 的 LoggingSystem 实现类。
+
+就暂时不解析了，基本类似。感兴趣的胖友，可以看看 [《spring boot 源码解析27-JavaLoggingSystem及LoggingSystem生命周期详解》](https://blog.csdn.net/qq_26000415/article/details/79103989) 的 [「LoggingSystem」](https://svip.iocoder.cn/Spring-Boot/logger-system/#) 部分。
+
+# 666. 彩蛋
+
+Spring Boot 的文章，基本都短不了~咋说呢？虽然长了一些吧，总体还是比较简单和顺畅的。
+
+参考和推荐如下文章：
+
+- 一个努力的码农 [《spring boot 源码解析29-LogbackLoggingSystem》](https://blog.csdn.net/qq_26000415/article/details/79130943)
+- oldflame-Jm [《Spring boot源码分析-log日志系统（6）》](https://blog.csdn.net/jamet/article/details/78060817)
\ No newline at end of file
diff --git a/springboot/16-Spring Boot 源码分析-ConfigurationProperties.md b/springboot/16-Spring Boot 源码分析-ConfigurationProperties.md
new file mode 100644
index 0000000..6891e25
--- /dev/null
+++ b/springboot/16-Spring Boot 源码分析-ConfigurationProperties.md	
@@ -0,0 +1,936 @@
+# 精尽 Spring Boot 源码分析 —— @ConfigurationProperties
+
+# 1. 概述
+
+本文我们来分享 `@ConfigurationProperties` 注解，如何将配置文件自动设置到被注解的类。代码如下：
+
+```
+// ConfigurationProperties.java
+
+/**
+ * Annotation for externalized configuration. Add this to a class definition or a
+ * {@code @Bean} method in a {@code @Configuration} class if you want to bind and validate
+ * some external Properties (e.g. from a .properties file).
+ * <p>
+ * Note that contrary to {@code @Value}, SpEL expressions are not evaluated since property
+ * values are externalized.
+ *
+ * @author Dave Syer
+ * @see ConfigurationPropertiesBindingPostProcessor
+ * @see EnableConfigurationProperties
+ */
+@Target({ElementType.TYPE, ElementType.METHOD})
+@Retention(RetentionPolicy.RUNTIME)
+@Documented
+public @interface ConfigurationProperties {
+
+    /**
+     * The name prefix of the properties that are valid to bind to this object. Synonym
+     * for {@link #prefix()}. A valid prefix is defined by one or more words separated
+     * with dots (e.g. {@code "acme.system.feature"}).
+     *
+     * @return the name prefix of the properties to bind
+     */
+    @AliasFor("prefix")
+    String value() default "";
+
+    /**
+     * The name prefix of the properties that are valid to bind to this object. Synonym
+     * for {@link #value()}. A valid prefix is defined by one or more words separated with
+     * dots (e.g. {@code "acme.system.feature"}).
+     *
+     * @return the name prefix of the properties to bind
+     */
+    @AliasFor("value")
+    String prefix() default "";
+
+    /**
+     * Flag to indicate that when binding to this object invalid fields should be ignored.
+     * Invalid means invalid according to the binder that is used, and usually this means
+     * fields of the wrong type (or that cannot be coerced into the correct type).
+     *
+     * @return the flag value (default false)
+     */
+    boolean ignoreInvalidFields() default false;
+
+    /**
+     * Flag to indicate that when binding to this object unknown fields should be ignored.
+     * An unknown field could be a sign of a mistake in the Properties.
+     *
+     * @return the flag value (default true)
+     */
+    boolean ignoreUnknownFields() default true;
+
+}
+```
+
+`@ConfigurationProperties` 注解有两种使用方法，可见 [《关与 @EnableConfigurationProperties 注解》](https://www.jianshu.com/p/7f54da1cb2eb) 文章。总结来说：
+
+- 第一种，`@Component` + `@ConfigurationProperties` 。
+- 第二种，`@EnableConfigurationProperties` + `ConfigurationProperties` 。
+
+实际情况下，更多的是使用第一种。当然，第二种的 `@EnableConfigurationProperties` 的效果，也是将指定的类，实现和 `@Component` 被注解的类是一样的，创建成 Bean 对象。
+这样，`@ConfigurationProperties` 就可以将配置文件自动设置到该 Bean 对象咧。
+
+# 2. @EnableConfigurationProperties
+
+`org.springframework.boot.context.properties.@EnableConfigurationProperties` 注解，可以将指定带有 `@ConfigurationProperties` 的类，注册成 BeanDefinition ，从而创建成 Bean 对象。代码如下：
+
+```
+// EnableConfigurationProperties.java
+
+/**
+ * Enable support for {@link ConfigurationProperties} annotated beans.
+ * {@link ConfigurationProperties} beans can be registered in the standard way (for
+ * example using {@link Bean @Bean} methods) or, for convenience, can be specified
+ * directly on this annotation.
+ *
+ * @author Dave Syer
+ */
+@Target(ElementType.TYPE)
+@Retention(RetentionPolicy.RUNTIME)
+@Documented
+@Import(EnableConfigurationPropertiesImportSelector.class)
+public @interface EnableConfigurationProperties {
+
+	/**
+     * 指定的类们
+     *
+	 * Convenient way to quickly register {@link ConfigurationProperties} annotated beans
+	 * with Spring. Standard Spring Beans will also be scanned regardless of this value.
+	 * @return {@link ConfigurationProperties} annotated beans to register
+	 */
+	Class<?>[] value() default {};
+
+}
+```
+
+- 从 `@Import` 注解上，可以看到使用 EnableConfigurationPropertiesImportSelector 处理。详细的解析，见 [「2.2 EnableConfigurationPropertiesImportSelector」](https://svip.iocoder.cn/Spring-Boot/ConfigurationProperties/#) 。
+
+## 2.1 ConfigurationPropertiesAutoConfiguration
+
+默认情况下，`@EnableConfigurationProperties` 会通过 `org.springframework.boot.autoconfigure.context.ConfigurationPropertiesAutoConfiguration` 类，进行开启。代码如下：
+
+```
+// ConfigurationPropertiesAutoConfiguration.java
+
+/**
+ * {@link EnableAutoConfiguration Auto-configuration} for {@link ConfigurationProperties}
+ * beans. Automatically binds and validates any bean annotated with
+ * {@code @ConfigurationProperties}.
+ *
+ * @author Stephane Nicoll
+ * @since 1.3.0
+ * @see EnableConfigurationProperties
+ * @see ConfigurationProperties
+ */
+@Configuration
+@EnableConfigurationProperties // <X>
+public class ConfigurationPropertiesAutoConfiguration {
+}
+```
+
+- 看，看看，看看看，`<X>` 哟~
+
+## 2.2 EnableConfigurationPropertiesImportSelector
+
+`org.springframework.boot.context.properties.EnableConfigurationPropertiesImportSelector` ，实现 ImportSelector 接口，处理 `@EnableConfigurationProperties` 注解。代码如下：
+
+```
+// EnableConfigurationPropertiesImportSelector.java
+
+private static final String[] IMPORTS = {
+		ConfigurationPropertiesBeanRegistrar.class.getName(),
+		ConfigurationPropertiesBindingPostProcessorRegistrar.class.getName() };
+
+@Override
+public String[] selectImports(AnnotationMetadata metadata) {
+	return IMPORTS;
+}
+```
+
+- 返回的
+
+   
+
+  ```
+  IMPORTS
+  ```
+
+   
+
+  的是两个 ImportBeanDefinitionRegistrar 实现类。分别是：
+
+  - ConfigurationPropertiesBeanRegistrar ，在 [「2.3 ConfigurationPropertiesBeanRegistrar」](https://svip.iocoder.cn/Spring-Boot/ConfigurationProperties/#) 中详细解析。
+  - ConfigurationPropertiesBindingPostProcessorRegistrar ，在 [「2.4 ConfigurationPropertiesBindingPostProcessorRegistrar」](https://svip.iocoder.cn/Spring-Boot/ConfigurationProperties/#) 中详细解析。
+
+## 2.3 ConfigurationPropertiesBeanRegistrar
+
+ConfigurationPropertiesBeanRegistrar ，是 EnableConfigurationPropertiesImportSelector 的内部静态类，实现 ImportBeanDefinitionRegistrar 接口，将 `@EnableConfigurationProperties` 注解指定的类，逐个注册成对应的 BeanDefinition 对象。代码如下：
+
+```
+// EnableConfigurationPropertiesImportSelector#ConfigurationPropertiesBeanRegistrar.java
+
+@Override
+public void registerBeanDefinitions(AnnotationMetadata metadata, BeanDefinitionRegistry registry) {
+    getTypes(metadata) // <1>
+            .forEach((type) -> register(registry, (ConfigurableListableBeanFactory) registry, type)); // <2>
+}
+```
+
+- `<1>` 处，调用 `#getTypes(AnnotationMetadata metadata)` 方法，获得 `@EnableConfigurationProperties` 注解指定的类的数组。代码如下：
+
+  ```
+  // EnableConfigurationPropertiesImportSelector#ConfigurationPropertiesBeanRegistrar.java
+  
+  private List<Class<?>> getTypes(AnnotationMetadata metadata) {
+      // 获得 @EnableConfigurationProperties 注解
+      MultiValueMap<String, Object> attributes = metadata.getAllAnnotationAttributes(EnableConfigurationProperties.class.getName(), false);
+      // 获得 value 属性
+      return collectClasses((attributes != null) ? attributes.get("value")
+              : Collections.emptyList());
+  }
+  
+  private List<Class<?>> collectClasses(List<?> values) {
+      return values.stream().flatMap((value) -> Arrays.stream((Object[]) value))
+              .map((o) -> (Class<?>) o).filter((type) -> void.class != type)
+              .collect(Collectors.toList());
+  }
+  ```
+
+  - ~
+
+- `<2>` 处，遍历，逐个调用 `#register(BeanDefinitionRegistry registry, ConfigurableListableBeanFactory beanFactory, Class<?> type)` 方法，注册每个类对应的 BeanDefinition 对象。代码如下：
+
+  ```
+  // EnableConfigurationPropertiesImportSelector#ConfigurationPropertiesBeanRegistrar.java
+  
+  private void register(BeanDefinitionRegistry registry, ConfigurableListableBeanFactory beanFactory, Class<?> type) {
+      // <2.1> 通过 @ConfigurationProperties 注解，获得最后要生成的 BeanDefinition 的名字。格式为 prefix-类全名 or 类全名
+      String name = getName(type);
+      // <2.2> 判断是否已经有该名字的 BeanDefinition 的名字。没有，才进行注册
+      if (!containsBeanDefinition(beanFactory, name)) {
+          registerBeanDefinition(registry, name, type); // <2.3> 
+      }
+  }
+  ```
+
+  - `<2.1>` 处，调用 `#getName(Class<?> type)` 方法，通过 `@ConfigurationProperties` 注解，获得最后要生成的 BeanDefinition 的名字。代码如下：
+
+    ```
+    // EnableConfigurationPropertiesImportSelector#ConfigurationPropertiesBeanRegistrar.java
+    
+    private String getName(Class<?> type) {
+        ConfigurationProperties annotation = AnnotationUtils.findAnnotation(type, ConfigurationProperties.class);
+        String prefix = (annotation != null) ? annotation.prefix() : "";
+        return (StringUtils.hasText(prefix) ? prefix + "-" + type.getName() : type.getName());
+    }
+    ```
+
+    - 格式为 `prefix-`类全名 or 类全名。
+
+  - `<2.2>` 处，调用 `#containsBeanDefinition(ConfigurableListableBeanFactory beanFactory, String name)` 方法，判断是否已经有该名字的 BeanDefinition 的名字。代码如下：
+
+    ```
+    // EnableConfigurationPropertiesImportSelector#ConfigurationPropertiesBeanRegistrar.java
+    
+    private boolean containsBeanDefinition(ConfigurableListableBeanFactory beanFactory, String name) {
+        // 判断是否存在 BeanDefinition 。如果有，则返回 true
+        if (beanFactory.containsBeanDefinition(name)) {
+            return true;
+        }
+        // 获得父容器，判断是否存在
+        BeanFactory parent = beanFactory.getParentBeanFactory();
+        if (parent instanceof ConfigurableListableBeanFactory) {
+            return containsBeanDefinition((ConfigurableListableBeanFactory) parent, name);
+        }
+        // 返回 false ，说明不存在
+        return false;
+    }
+    ```
+
+    - 如果不存在，才执行后续的注册 BeanDefinition 逻辑。
+
+  - `<2.3>` 处，调用 `#registerBeanDefinition(BeanDefinitionRegistry registry, String name, Class<?> type)` 方法，注册 BeanDefinition 。代码如下：
+
+    ```
+    // EnableConfigurationPropertiesImportSelector#ConfigurationPropertiesBeanRegistrar.java
+    
+    private void registerBeanDefinition(BeanDefinitionRegistry registry, String name, Class<?> type) {
+        // 断言，判断该类有 @ConfigurationProperties 注解
+        assertHasAnnotation(type);
+        // 创建 GenericBeanDefinition 对象
+        GenericBeanDefinition definition = new GenericBeanDefinition();
+        definition.setBeanClass(type);
+        // 注册到 BeanDefinitionRegistry 中
+        registry.registerBeanDefinition(name, definition);
+    }
+    
+    private void assertHasAnnotation(Class<?> type) {
+        Assert.notNull(
+                AnnotationUtils.findAnnotation(type, ConfigurationProperties.class),
+                () -> "No " + ConfigurationProperties.class.getSimpleName()
+                        + " annotation found on  '" + type.getName() + "'.");
+    }
+    ```
+
+    - ~
+
+## 2.4 ConfigurationPropertiesBindingPostProcessorRegistrar
+
+`org.springframework.boot.context.properties.ConfigurationPropertiesBindingPostProcessorRegistrar` ，实现 ImportBeanDefinitionRegistrar 接口，代码如下：
+
+```
+// ConfigurationPropertiesBindingPostProcessorRegistrar.java
+
+@Override
+public void registerBeanDefinitions(AnnotationMetadata importingClassMetadata, BeanDefinitionRegistry registry) {
+    if (!registry.containsBeanDefinition(ConfigurationPropertiesBindingPostProcessor.BEAN_NAME)) {
+        // <1> 注册 ConfigurationPropertiesBindingPostProcessor BeanDefinition
+        registerConfigurationPropertiesBindingPostProcessor(registry);
+        // <2> 注册 ConfigurationBeanFactoryMetadata BeanDefinition
+        registerConfigurationBeanFactoryMetadata(registry);
+    }
+}
+```
+
+- `<1>` 处，调用 `#registerConfigurationPropertiesBindingPostProcessor(BeanDefinitionRegistry registry)` 方法，注册 ConfigurationPropertiesBindingPostProcessor BeanDefinition 。代码如下：
+
+  ```
+  // ConfigurationPropertiesBindingPostProcessorRegistrar.java
+  
+  private void registerConfigurationPropertiesBindingPostProcessor(BeanDefinitionRegistry registry) {
+      // 创建 GenericBeanDefinition 对象
+      GenericBeanDefinition definition = new GenericBeanDefinition();
+      definition.setBeanClass(ConfigurationPropertiesBindingPostProcessor.class);
+      definition.setRole(BeanDefinition.ROLE_INFRASTRUCTURE);
+      // 注册
+      registry.registerBeanDefinition(ConfigurationPropertiesBindingPostProcessor.BEAN_NAME, definition);
+  }
+  ```
+
+  - 关于 ConfigurationPropertiesBindingPostProcessor 类，我们在 [「4. ConfigurationPropertiesBindingPostProcessor 相关」](https://svip.iocoder.cn/Spring-Boot/ConfigurationProperties/#) 中，详细解析。
+
+- `<2>` 处，调用 `#registerConfigurationBeanFactoryMetadata(BeanDefinitionRegistry registry)` 方法，注册 ConfigurationBeanFactoryMetadata BeanDefinition 。代码如下：
+
+  ```
+  // ConfigurationPropertiesBindingPostProcessorRegistrar.java
+  
+  private void registerConfigurationBeanFactoryMetadata(BeanDefinitionRegistry registry) {
+      // 创建 GenericBeanDefinition 对象
+      GenericBeanDefinition definition = new GenericBeanDefinition();
+      definition.setBeanClass(ConfigurationBeanFactoryMetadata.class);
+      definition.setRole(BeanDefinition.ROLE_INFRASTRUCTURE);
+      // 注册
+      registry.registerBeanDefinition(ConfigurationBeanFactoryMetadata.BEAN_NAME, definition);
+  }
+  ```
+
+  - 关于 ConfigurationBeanFactoryMetadata 类，我们在 [「3. ConfigurationBeanFactoryMetadata」](https://svip.iocoder.cn/Spring-Boot/ConfigurationProperties/#) 中，详细解析。
+
+# 3. ConfigurationBeanFactoryMetadata
+
+`org.springframework.boot.context.properties.ConfigurationBeanFactoryMetadata` ，初始化配置类创建 Bean 的每个方法的元数据。
+
+## 3.1 postProcessBeanFactory
+
+实现 `#postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory)` 方法，代码如下：
+
+```
+// ConfigurationBeanFactoryMetadata.java
+
+private ConfigurableListableBeanFactory beanFactory;
+
+/**
+ * FactoryMetadata 的映射
+ *
+ * KEY ：Bean 的名字
+ */
+private final Map<String, FactoryMetadata> beansFactoryMetadata = new HashMap<>();
+
+@Override
+public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
+    // <1> 初始化 beanFactory 属性
+    this.beanFactory = beanFactory;
+    // <2> 遍历所有的 BeanDefinition 的名字们
+    for (String name : beanFactory.getBeanDefinitionNames()) {
+        // <2.1> 获得 BeanDefinition 对象
+        BeanDefinition definition = beanFactory.getBeanDefinition(name);
+        // <2.2> 获得 method、bean 属性
+        String method = definition.getFactoryMethodName();
+        String bean = definition.getFactoryBeanName();
+        // <2.3> 添加到 beansFactoryMetadata 中
+        if (method != null && bean != null) {
+            this.beansFactoryMetadata.put(name, new FactoryMetadata(bean, method));
+        }
+    }
+}
+```
+
+- `<1>` 处，初始化 `beanFactory` 属性。
+
+- `<2>` 处，遍历所有的 BeanDefinition 的名字们，初始化 `beansFactoryMetadata` 属性。
+
+- `<2.1>` 处，获得 BeanDefinition 对象。
+
+- `<2.2>` 处，获得 BeanDefinition 的 `factoryMethodName`、`factoryBeanName` 属性。
+
+  - `factoryBeanName` 属性，是创建该 Bean 的工厂 Bean 的名字。
+
+  - `factoryMethodName` 属性，是创建 Bean 的工厂 Bean 的方法名。
+
+  - 以如下的 Configuration 类，举个例子：
+
+    ```
+    @Configuration
+    public class TestConfiguration {
+    
+        @Bean
+        public Object testObject() {
+            return new Object();
+        }
+    
+    }
+    ```
+
+    - 每个 `@Bean` 注解的方法，都是一个 `factoryBeanName` + `factoryMethodName` 。
+    - `factoryBeanName` 属性，为 `"testConfiguration"` 。
+    - `factoryMethodName` 属性，为 `"testObject"` 。
+
+- `<2.3>` 处，都非空的情况下，添加到 `beansFactoryMetadata` 中。
+
+- FactoryMetadata 是 ConfigurationBeanFactoryMetadata 的内部静态类。代码如下：
+
+  ```
+  // ConfigurationBeanFactoryMetadata#FactoryMetadata.java
+  
+  private static class FactoryMetadata {
+  
+      /**
+       * Bean 的名字
+       */
+      private final String bean;
+      /**
+       * Bean 的方法名
+       */
+      private final String method;
+  
+      // ... 省略 setting / getting  方法
+  
+  }
+  ```
+
+## 3.2 findFactoryMethod
+
+`#findFactoryMethod(String beanName)` 方法，获得指定 Bean 的创建方法。代码如下：
+
+```
+// ConfigurationBeanFactoryMetadata.java
+
+public Method findFactoryMethod(String beanName) {
+    // 如果不存在，则返回 null
+    if (!this.beansFactoryMetadata.containsKey(beanName)) {
+        return null;
+    }
+    AtomicReference<Method> found = new AtomicReference<>(null);
+    // 获得 beanName 对应的 FactoryMetadata 对象
+    FactoryMetadata metadata = this.beansFactoryMetadata.get(beanName);
+    // 获得对应的工厂类
+    Class<?> factoryType = this.beanFactory.getType(metadata.getBean());
+    if (ClassUtils.isCglibProxyClass(factoryType)) {
+        factoryType = factoryType.getSuperclass();
+    }
+    // 获得对应的工厂类的方法
+    String factoryMethod = metadata.getMethod();
+    ReflectionUtils.doWithMethods(factoryType, (method) -> {
+        if (method.getName().equals(factoryMethod)) {
+            found.compareAndSet(null, method);
+        }
+    });
+    return found.get();
+}
+```
+
+## 3.3 findFactoryAnnotation
+
+`#findFactoryAnnotation(String beanName, Class<A> type)` 方法，获得指定 Bean 的创建方法上的注解。代码如下：
+
+```
+// ConfigurationBeanFactoryMetadata.java
+
+public <A extends Annotation> A findFactoryAnnotation(String beanName, Class<A> type) {
+    // 获得方法
+    Method method = findFactoryMethod(beanName);
+    // 获得注解
+    return (method != null) ? AnnotationUtils.findAnnotation(method, type) : null;
+}
+```
+
+## 3.4 getBeansWithFactoryAnnotation
+
+`#getBeansWithFactoryAnnotation(Class<A> type)` 方法，获得 `beansFactoryMetadata` 中的每个 Bean 的方法上的指定注解。代码如下：
+
+```
+// ConfigurationBeanFactoryMetadata.java
+
+public <A extends Annotation> Map<String, Object> getBeansWithFactoryAnnotation(Class<A> type) {
+    Map<String, Object> result = new HashMap<>();
+    // 遍历 beansFactoryMetadata
+    for (String name : this.beansFactoryMetadata.keySet()) {
+        // 获得每个 Bean 的创建方法上的注解
+        if (findFactoryAnnotation(name, type) != null) {
+            result.put(name, this.beanFactory.getBean(name));
+        }
+    }
+    return result;
+}
+```
+
+😈 至此，我们基本能够明白，ConfigurationBeanFactoryMetadata 就是提供一些元数据的。
+
+# 4. ConfigurationPropertiesBindingPostProcessor 相关
+
+> 艿艿：因为 ConfigurationPropertiesBindingPostProcessor 涉及到好几个类，所以一起放在本小节来看看。
+
+## 4.1 ConfigurationPropertiesBindingPostProcessor
+
+`org.springframework.boot.context.properties.ConfigurationPropertiesBindingPostProcessor` ，实现 BeanPostProcessor、PriorityOrdered、ApplicationContextAware、InitializingBean 接口，将配置文件注入到 `@ConfigurationProperties` 注解的 Bean 的属性中。
+
+### 4.1.1 基本属性
+
+```
+// ConfigurationPropertiesBindingPostProcessor.java
+
+/**
+ * The bean name of the configuration properties validator.
+ */
+public static final String VALIDATOR_BEAN_NAME = "configurationPropertiesValidator";
+
+private ConfigurationBeanFactoryMetadata beanFactoryMetadata;
+
+private ApplicationContext applicationContext;
+
+private ConfigurationPropertiesBinder configurationPropertiesBinder;
+
+@Override
+public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
+    this.applicationContext = applicationContext; // <1>
+}
+
+@Override
+public void afterPropertiesSet() throws Exception {
+    // We can't use constructor injection of the application context because
+    // it causes eager factory bean initialization
+    this.beanFactoryMetadata = this.applicationContext.getBean(ConfigurationBeanFactoryMetadata.BEAN_NAME, ConfigurationBeanFactoryMetadata.class); // <2>
+    this.configurationPropertiesBinder = new ConfigurationPropertiesBinder(this.applicationContext, VALIDATOR_BEAN_NAME); // <3>
+}
+```
+
+- `<1>` 处，设置 `applicationContext` 属性。
+- `<2>` 处，设置 `beanFactoryMetadata` 属性。即，我们在 [「3. ConfigurationBeanFactoryMetadata」](https://svip.iocoder.cn/Spring-Boot/ConfigurationProperties/#) 中看到的。
+- `<3>` 处，创建 ConfigurationPropertiesBinder 对象，设置到 `configurationPropertiesBinder` 属性。TODO ConfigurationPropertiesBinder
+
+### 4.1.2 postProcessBeforeInitialization
+
+实现 `#postProcessBeforeInitialization(Object bean, String beanName)` 方法，代码如下：
+
+```
+// ConfigurationPropertiesBindingPostProcessor.java
+
+@Override
+public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
+    // <1> 获得 Bean 上的 @ConfigurationProperties 属性
+    ConfigurationProperties annotation = getAnnotation(bean, beanName, ConfigurationProperties.class);
+    if (annotation != null) {
+        // <2> 将配置文件注入到 `@ConfigurationProperties` 注解的 Bean 的属性中
+        bind(bean, beanName, annotation);
+    }
+    return bean;
+}
+```
+
+- ```
+  <1>
+  ```
+
+   
+
+  处，调用
+
+   
+
+  ```
+  #getAnnotation(Object bean, String beanName, Class<A> type)
+  ```
+
+   
+
+  方法，获得 Bean 上的
+
+   
+
+  ```
+  @ConfigurationProperties
+  ```
+
+   
+
+  属性。代码如下：
+
+  ```
+  // ConfigurationPropertiesBindingPostProcessor.java
+  
+  private <A extends Annotation> A getAnnotation(Object bean, String beanName, Class<A> type) {
+      // 获得 Bean 上的注解
+      A annotation = this.beanFactoryMetadata.findFactoryAnnotation(beanName, type);
+      // 如果获得不到，则获得 Bean 对应的 Class 上的注解
+      if (annotation == null) {
+          annotation = AnnotationUtils.findAnnotation(bean.getClass(), type);
+      }
+      return annotation;
+  }
+  ```
+
+- `<2>` 处，调用 `#bind(Object bean, String beanName, ConfigurationProperties annotation)` 方法，将配置文件注入到 `@ConfigurationProperties` 注解的 Bean 的属性中。代码如下：
+
+  ```
+  // ConfigurationPropertiesBindingPostProcessor.java
+  
+  private void bind(Object bean, String beanName, ConfigurationProperties annotation) {
+      // <2.1> 解析 Bean 的类型
+      ResolvableType type = getBeanType(bean, beanName);
+      // <2.2> 获得 Bean 上的 @Validated 注解
+      Validated validated = getAnnotation(bean, beanName, Validated.class);
+      // <2.3> 创建 Annotation 数组
+      Annotation[] annotations = (validated != null)
+              ? new Annotation[] { annotation, validated }
+              : new Annotation[] { annotation };
+      // <2.4> 创建 Bindable 对象
+      Bindable<?> target = Bindable.of(type).withExistingValue(bean).withAnnotations(annotations);
+      try {
+          // <2.5> 将配置文件注入到 `@ConfigurationProperties` 注解的 Bean 的属性中
+          this.configurationPropertiesBinder.bind(target);
+      } catch (Exception ex) {
+          throw new ConfigurationPropertiesBindException(beanName, bean, annotation, ex);
+      }
+  }
+  ```
+
+  - `<2.1>` 处，调用 `#getBeanType(Object bean, String beanName)` 方法，解析 Bean 的类型。代码如下：
+
+    ```
+    // ConfigurationPropertiesBindingPostProcessor.java
+    
+    private ResolvableType getBeanType(Object bean, String beanName) {
+        // 获得 beanName 对应的工厂方法
+        Method factoryMethod = this.beanFactoryMetadata.findFactoryMethod(beanName);
+        // 情况一：如果是，说明是 Configuration 类创建的 Bean 对象
+        if (factoryMethod != null) {
+            return ResolvableType.forMethodReturnType(factoryMethod);
+        }
+        // 情况二：如果否，说明是普通的类创建的 Bean 对象
+        return ResolvableType.forClass(bean.getClass());
+    }
+    ```
+
+    - 两种情况，见注释。
+
+  - `<2.2>` 处，调用 `#getAnnotation(Object bean, String beanName, Class<A> type)` 方法，获得 Bean 上的 `@Validated` 属性。`@ConfigurationProperties` 注解，可以配合 `@Validated` 注解，一起使用，从而实现校验的功能。具体可以看看 [《Enable `ConfigurationProperties` validation with `@Validated` on the factory method》](https://github.com/spring-projects/spring-boot/issues/10803) 文章。
+
+  - `<2.3>` 处，创建 Annotation 数组。
+
+  - `<2.4>` 处，创建 Bindable 对象。我们先不用去理解 Bindable 是个锤子，至少我们看到了 `withExistingValue(bean)` 设置了 Bean 对象，`withAnnotations(annotations)` 设置了 Annotation 注解数组。
+
+  - `<2.5>` 处，调用 `ConfigurationPropertiesBinder#bind(Bindable<?> target)` 方法，将配置文件注入到 `@ConfigurationProperties` 注解的 Bean 的属性中。详细解析，见 [「4.2 ConfigurationPropertiesBinder」](https://svip.iocoder.cn/Spring-Boot/ConfigurationProperties/#) 。
+
+## 4.2 ConfigurationPropertiesBinder
+
+`org.springframework.boot.context.properties.ConfigurationPropertiesBinder` ，处理 `@ConfigurationProperties` 注解的 Bean 的属性的注入。其类上的注释如下：
+
+```
+// ConfigurationPropertiesBinder.java
+
+/**
+ * Internal class by the {@link ConfigurationPropertiesBindingPostProcessor} to handle the
+ * actual {@link ConfigurationProperties} binding.
+ */
+```
+
+### 4.2.1 构造方法
+
+```
+// ConfigurationPropertiesBinder.java
+
+private final ApplicationContext applicationContext;
+
+private final PropertySources propertySources;
+
+private final Validator configurationPropertiesValidator;
+
+private final boolean jsr303Present;
+
+private volatile Validator jsr303Validator;
+
+private volatile Binder binder;
+
+ConfigurationPropertiesBinder(ApplicationContext applicationContext, String validatorBeanName) {
+	this.applicationContext = applicationContext; // <1>
+	this.propertySources = new PropertySourcesDeducer(applicationContext).getPropertySources(); // <2>
+	this.configurationPropertiesValidator = getConfigurationPropertiesValidator(applicationContext, validatorBeanName); // <3> 
+	this.jsr303Present = ConfigurationPropertiesJsr303Validator.isJsr303Present(applicationContext); // <4>
+}
+```
+
+- `<1>` 处，设置 `applicationContext` 属性。
+
+- `<2>` 处，创建 [`org.springframework.boot.context.properties.PropertySourcesDeducer`](https://github.com/YunaiV/spring-boot/blob/master/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/context/properties/PropertySourcesDeducer.java) 对象，然后调用 `PropertySourcesDeducer#getPropertySources()` 方法，获得 PropertySource 数组，之后设置给 `propertySources` 属性。关于 PropertySourcesDeducer.java 类，胖友点击链接，自己看看即可。
+
+- `<3>` 处，调用 `#getConfigurationPropertiesValidator(ApplicationContext applicationContext, String validatorBeanName)` 方法，获得配置的 Validator 对象。代码如下：
+
+  ```
+  // ConfigurationPropertiesBinder.java
+  
+  private Validator getConfigurationPropertiesValidator(ApplicationContext applicationContext, String validatorBeanName) {
+  	if (applicationContext.containsBean(validatorBeanName)) {
+  		return applicationContext.getBean(validatorBeanName, Validator.class);
+  	}
+  	return null;
+  }
+  ```
+
+  - 从上面的文章，可以知道 `validatorBeanName` 为 `"configurationPropertiesValidator"` 。即，创建的 Validator Bean 的对象。
+  - 一般情况下，我们不会配置该 Bean 对象，所以返回 `null` 。因此吧，可以暂时无视这个 `configurationPropertiesValidator` 属性~。
+
+- `<4>` 处，调用 `ConfigurationPropertiesJsr303Validator#isJsr303Present(ApplicationContext applicationContext)` 方法，是否有引入 Jsr 303 Validator 相关的依赖。关于它，详细解析见 [「4.3 ConfigurationPropertiesJsr303Validator」](https://svip.iocoder.cn/Spring-Boot/ConfigurationProperties/#) 中。
+
+### 4.2.2 bind
+
+`#bind(Bindable<?> target)` 方法，处理 `@ConfigurationProperties` 注解的 Bean 的属性的注入。代码如下：
+
+```
+// ConfigurationPropertiesBinder.java
+
+public void bind(Bindable<?> target) {
+    // <1> 获得 @ConfigurationProperties 注解的属性
+    ConfigurationProperties annotation = target.getAnnotation(ConfigurationProperties.class);
+    Assert.state(annotation != null, () -> "Missing @ConfigurationProperties on " + target);
+    // <2> 获得 Validator 数组
+    List<Validator> validators = getValidators(target);
+    // <3> 获得 BindHandler 对象
+    BindHandler bindHandler = getBindHandler(annotation, validators);
+    // <4> 获得 Binder 对象，然后执行绑定逻辑，处理 `@ConfigurationProperties` 注解的 Bean 的属性的注入
+    getBinder().bind(annotation.prefix(), target, bindHandler);
+}
+```
+
+- `<1>` 处，获得 `@ConfigurationProperties` 注解的属性。
+
+- `<2>` 处，调用 `#getValidators(Bindable<?> target)` 方法，获得 Validator 数组。代码如下：
+
+  ```
+  // ConfigurationPropertiesBinder.java
+  
+  private List<Validator> getValidators(Bindable<?> target) {
+      List<Validator> validators = new ArrayList<>(3);
+      // 来源一，configurationPropertiesValidator
+      if (this.configurationPropertiesValidator != null) {
+          validators.add(this.configurationPropertiesValidator);
+      }
+      // 来源二，ConfigurationPropertiesJsr303Validator 对象
+      if (this.jsr303Present && target.getAnnotation(Validated.class) != null) {
+          validators.add(getJsr303Validator());
+      }
+      // 来源三，自己实现了 Validator 接口
+      if (target.getValue() != null && target.getValue().get() instanceof Validator) {
+          validators.add((Validator) target.getValue().get());
+      }
+      return validators;
+  }
+  
+  // 返回 ConfigurationPropertiesJsr303Validator 对象
+  private Validator getJsr303Validator() {
+      if (this.jsr303Validator == null) {
+          this.jsr303Validator = new ConfigurationPropertiesJsr303Validator(this.applicationContext);
+      }
+      return this.jsr303Validator;
+  }
+  ```
+
+  - 三个来源。
+
+- `<3>` 处，调用 `#getBindHandler(ConfigurationProperties annotation, List<Validator> validators)` 方法，获得 BindHandler 对象。代码如下：
+
+  ```
+  // ConfigurationPropertiesBinder.java
+  
+  private BindHandler getBindHandler(ConfigurationProperties annotation, List<Validator> validators) {
+  	BindHandler handler = new IgnoreTopLevelConverterNotFoundBindHandler();
+  	// 如果有 ignoreInvalidFields 属性，进一步包装成 IgnoreErrorsBindHandler 类
+  	if (annotation.ignoreInvalidFields()) {
+  		handler = new IgnoreErrorsBindHandler(handler);
+  	}
+  	// 如果否 ignoreUnknownFields 属性，进一步包装成 NoUnboundElementsBindHandler 类
+  	if (!annotation.ignoreUnknownFields()) {
+  		UnboundElementsSourceFilter filter = new UnboundElementsSourceFilter();
+  		handler = new NoUnboundElementsBindHandler(handler, filter);
+  	}
+  	// <X> 如果 Validator 数组非空，进一步包装成 ValidationBindHandler 对象
+  	if (!validators.isEmpty()) {
+  		handler = new ValidationBindHandler(handler, validators.toArray(new Validator[0]));
+  	}
+  	// <Y> 如果有 ConfigurationPropertiesBindHandlerAdvisor 元素，则进一步处理 handler 对象
+  	for (ConfigurationPropertiesBindHandlerAdvisor advisor : getBindHandlerAdvisors()) {
+  		handler = advisor.apply(handler);
+  	}
+  	return handler;
+  }
+  
+  private List<ConfigurationPropertiesBindHandlerAdvisor> getBindHandlerAdvisors() {
+  	return this.applicationContext.getBeanProvider(ConfigurationPropertiesBindHandlerAdvisor.class)
+  			.orderedStream().collect(Collectors.toList());
+  }
+  ```
+
+  - `<X>` 处，通过将 `handler` 包装成 ValidationBindHandler 对象，从而实现 Validator 功能的提供。
+  - `<Y>` 处，此处的 [`org.springframework.boot.context.properties.ConfigurationPropertiesBindHandlerAdvisor`](https://github.com/YunaiV/spring-boot/blob/master/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/context/properties/ConfigurationPropertiesBindHandlerAdvisor.java) 接口，通过实现它，并注册到 Spring 容器中，可以对 `handler` 进一步处理。😈 当然，大多数情况下，包括 Spring Boot 也并未提供其实现，我们不需要这么做。所以呢，这块我们又可以无视落。
+  - 🙂 另外，关于 BindHandler 是什么，我们先不用去研究。后续，我们放在另外的文章，来慢慢讲解~
+
+- `<4>` 处，调用 `#getBinder()` 方法，获得 Binder 对象。代码如下：
+
+  ```
+  // ConfigurationPropertiesBinder.java
+  
+  private Binder getBinder() {
+  	if (this.binder == null) {
+  	    // 创建 Binder 对象
+  		this.binder = new Binder(getConfigurationPropertySources(),
+  				getPropertySourcesPlaceholdersResolver(),
+                  getConversionService(),
+  				getPropertyEditorInitializer());
+  	}
+  	return this.binder;
+  }
+  
+  private Iterable<ConfigurationPropertySource> getConfigurationPropertySources() {
+  	return ConfigurationPropertySources.from(this.propertySources);
+  }
+  
+  private PropertySourcesPlaceholdersResolver getPropertySourcesPlaceholdersResolver() {
+  	return new PropertySourcesPlaceholdersResolver(this.propertySources);
+  }
+  
+  private ConversionService getConversionService() {
+  	return new ConversionServiceDeducer(this.applicationContext).getConversionService(); // <X>
+  }
+  
+  private Consumer<PropertyEditorRegistry> getPropertyEditorInitializer() {
+  	if (this.applicationContext instanceof ConfigurableApplicationContext) {
+  		return ((ConfigurableApplicationContext) this.applicationContext).getBeanFactory()::copyRegisteredEditorsTo;
+  	}
+  	return null;
+  }
+  ```
+
+  - `<X>` 处，创建 ConversionServiceDeducer 创建，然后调用 `ConversionServiceDeducer#getConversionService()` 方法，获得 ConversionService 对象。ConversionService 是 Spring 中，用来作为类型转换器的。关于 [`org.springframework.boot.context.properties.ConversionServiceDeducer`](https://github.com/YunaiV/spring-boot/blob/master/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/context/properties/ConversionServiceDeducer.java) 类，胖友点击链接，简单看看即可。当然，也可以不看~
+
+- `<4>` 处，调用 `Binder#bind(String name, Bindable<T> target, BindHandler handler)` 方法，执行绑定逻辑，处理 `@ConfigurationProperties` 注解的 Bean 的属性的注入。😈 至此，撒花~
+
+## 4.3 ConfigurationPropertiesJsr303Validator
+
+`org.springframework.boot.context.properties.ConfigurationPropertiesJsr303Validator` ，实现 Validator 接口，`@ConfigurationProperties` + `@Validated` 注解的 Bean 的 JSR303 的 Validator 实现类。其类上的注释如下：
+
+```
+// ConfigurationPropertiesJsr303Validator.java
+
+/**
+ * Validator that supports configuration classes annotated with
+ * {@link Validated @Validated}.
+ */
+```
+
+### 4.3.1 构造方法
+
+```
+// ConfigurationPropertiesJsr303Validator.java
+
+private final Delegate delegate;
+
+ConfigurationPropertiesJsr303Validator(ApplicationContext applicationContext) {
+	this.delegate = new Delegate(applicationContext);
+}
+
+private static class Delegate extends LocalValidatorFactoryBean {
+
+    Delegate(ApplicationContext applicationContext) {
+        // 设置 applicationContext 属性
+        setApplicationContext(applicationContext);
+        // 设置 messageInterpolator 属性
+        setMessageInterpolator(new MessageInterpolatorFactory().getObject());
+        // 回调 afterPropertiesSet 方法
+        afterPropertiesSet();
+    }
+
+}
+```
+
+### 4.3.2 isJsr303Present
+
+`#isJsr303Present(ApplicationContext applicationContext)` 方法，校验是否支持 JSR303 。代码如下：
+
+```
+// ConfigurationPropertiesJsr303Validator.java
+
+private static final String[] VALIDATOR_CLASSES = { "javax.validation.Validator",
+		"javax.validation.ValidatorFactory",
+		"javax.validation.bootstrap.GenericBootstrap" };
+		
+public static boolean isJsr303Present(ApplicationContext applicationContext) {
+	ClassLoader classLoader = applicationContext.getClassLoader();
+	for (String validatorClass : VALIDATOR_CLASSES) {
+		if (!ClassUtils.isPresent(validatorClass, classLoader)) {
+			return false;
+		}
+	}
+	return true;
+}
+```
+
+- 通过判断，是否引入了相关的依赖。
+
+### 4.3.3 supports
+
+实现 `#supports(Class<?> type)` 方法，判断是否支持指定类的校验。代码如下：
+
+```
+// ConfigurationPropertiesJsr303Validator.java
+
+@Override
+public boolean supports(Class<?> type) {
+	return this.delegate.supports(type);
+}
+```
+
+### 4.3.4 validate
+
+实现 `#validate(Object target, Errors errors)` 方法，执行校验。代码如下：
+
+```
+// ConfigurationPropertiesJsr303Validator.java
+
+@Override
+public void validate(Object target, Errors errors) {
+	this.delegate.validate(target, errors);
+}
+```
+
+# 666. 彩蛋
+
+呼呼，终于写了一篇相对短一点的文章，舒服~关于本文看到的 Binder、BinderHandler、Bindable 等等类，属于 `org.springframework.boot.context.properties.bind` 包，后续我们根据需要，会对这块在进行详细的解析~
+
+参考和推荐如下文章：
+
+- oldflame-Jm [《Spring boot源码分析-ConfigurationProperties》](https://blog.csdn.net/jamet/article/details/78505703)
+- 梦想2018 [《spring @EnableConfigurationProperties 实现原理》](https://blog.csdn.net/ab411919134/article/details/81190425)
+- 一个努力的码农
+  - [《spring boot 源码解析13-@ConfigurationProperties是如何生效的》](https://blog.csdn.net/qq_26000415/article/details/78942494)
+  - [《spring boot 源码解析14-默认错误页面处理流程, 自定义,及EnableAutoConfigurationImportSelector处理》](https://blog.csdn.net/qq_26000415/article/details/78947283)
\ No newline at end of file
diff --git a/springboot/17-Spring Boot 源码分析-BeanDefinitionLoader.md b/springboot/17-Spring Boot 源码分析-BeanDefinitionLoader.md
new file mode 100644
index 0000000..5bdb509
--- /dev/null
+++ b/springboot/17-Spring Boot 源码分析-BeanDefinitionLoader.md	
@@ -0,0 +1,531 @@
+# 精尽 Spring Boot 源码分析 —— BeanDefinitionLoader
+
+# 1. 概述
+
+本文，我们来补充 [《精尽 Spring Boot 源码分析 —— SpringApplication》](http://svip.iocoder.cn/Spring-Boot/SpringApplication) 文章，并未详细解析的 BeanDefinitionLoader 。在 SpringApplication 中，我们可以看到 `#load(ApplicationContext context, Object[] sources)` 方法中，是如下一段代码：
+
+```
+// SpringApplication.java
+
+protected void load(ApplicationContext context, Object[] sources) {
+	if (logger.isDebugEnabled()) {
+		logger.debug("Loading source " + StringUtils.arrayToCommaDelimitedString(sources));
+	}
+	// <1> 创建 BeanDefinitionLoader 对象
+	BeanDefinitionLoader loader = createBeanDefinitionLoader(getBeanDefinitionRegistry(context), sources);
+	// <2> 设置 loader 的属性
+	if (this.beanNameGenerator != null) {
+		loader.setBeanNameGenerator(this.beanNameGenerator);
+	}
+	if (this.resourceLoader != null) {
+		loader.setResourceLoader(this.resourceLoader);
+	}
+	if (this.environment != null) {
+		loader.setEnvironment(this.environment);
+	}
+	// <3> 执行 BeanDefinition 加载
+	loader.load();
+}
+
+protected BeanDefinitionLoader createBeanDefinitionLoader(BeanDefinitionRegistry registry, Object[] sources) {
+	return new BeanDefinitionLoader(registry, sources);
+}
+```
+
+下面，我们来一起揭开它的面纱~
+
+# 2. BeanDefinitionLoader
+
+`org.springframework.boot.BeanDefinitionLoader` ，BeanDefinition 加载器（Loader），负责 Spring Boot 中，读取 BeanDefinition 。其类上的注释如下：
+
+```
+// BeanDefinitionLoader.java
+
+/**
+ * Loads bean definitions from underlying sources, including XML and JavaConfig. Acts as a
+ * simple facade over {@link AnnotatedBeanDefinitionReader},
+ * {@link XmlBeanDefinitionReader} and {@link ClassPathBeanDefinitionScanner}. See
+ * {@link SpringApplication} for the types of sources that are supported.
+ */
+```
+
+## 2.1 构造方法
+
+```
+// BeanDefinitionLoader.java
+
+/**
+ * 来源的数组
+ */
+private final Object[] sources;
+
+/**
+ * 注解的 BeanDefinition 读取器
+ */
+private final AnnotatedBeanDefinitionReader annotatedReader;
+/**
+ * XML 的 BeanDefinition 读取器
+ */
+private final XmlBeanDefinitionReader xmlReader;
+/**
+ * Groovy 的 BeanDefinition 读取器
+ */
+private BeanDefinitionReader groovyReader;
+/**
+ * Classpath 的 BeanDefinition 扫描器
+ */
+private final ClassPathBeanDefinitionScanner scanner;
+
+/**
+ * 资源加载器
+ */
+private ResourceLoader resourceLoader;
+
+/**
+ * Create a new {@link BeanDefinitionLoader} that will load beans into the specified
+ * {@link BeanDefinitionRegistry}.
+ * @param registry the bean definition registry that will contain the loaded beans
+ * @param sources the bean sources
+ */
+BeanDefinitionLoader(BeanDefinitionRegistry registry, Object... sources) {
+    Assert.notNull(registry, "Registry must not be null");
+    Assert.notEmpty(sources, "Sources must not be empty");
+    this.sources = sources; // <1>
+    // 创建 AnnotatedBeanDefinitionReader 对象
+    this.annotatedReader = new AnnotatedBeanDefinitionReader(registry);
+    // 创建 XmlBeanDefinitionReader 对象
+    this.xmlReader = new XmlBeanDefinitionReader(registry);
+    // 创建 GroovyBeanDefinitionReader 对象
+    if (isGroovyPresent()) {
+        this.groovyReader = new GroovyBeanDefinitionReader(registry);
+    }
+    // 创建 ClassPathBeanDefinitionScanner 对象
+    this.scanner = new ClassPathBeanDefinitionScanner(registry);
+    this.scanner.addExcludeFilter(new ClassExcludeFilter(sources));
+}
+```
+
+- `<1>` 处，设置 `sources` 属性。它来自方法参数 `Object... sources` ，来自 `SpringApplication#getAllSources()` 方法，代码如下：
+
+  ```
+  // BeanDefinitionLoader.java
+  
+  /**
+   * 主要的 Java Config 类的数组
+   */
+  private Set<Class<?>> primarySources;
+  
+  private Set<String> sources = new LinkedHashSet<>();
+  
+  /**
+   * Return an immutable set of all the sources that will be added to an
+   * ApplicationContext when {@link #run(String...)} is called. This method combines any
+   * primary sources specified in the constructor with any additional ones that have
+   * been {@link #setSources(Set) explicitly set}.
+   * @return an immutable set of all sources
+   */
+  public Set<Object> getAllSources() {
+  	Set<Object> allSources = new LinkedHashSet<>();
+  	if (!CollectionUtils.isEmpty(this.primarySources)) {
+  		allSources.addAll(this.primarySources);
+  	}
+  	if (!CollectionUtils.isEmpty(this.sources)) {
+  		allSources.addAll(this.sources);
+  	}
+  	return Collections.unmodifiableSet(allSources);
+  }
+  ```
+
+  - 默认情况下，返回的结果是 `Spring#run(Class<?> primarySource, String... args)` 方法的 `Class<?> primarySource` 的方法参数。例如说：[MVCApplication](https://github.com/YunaiV/spring-boot/blob/74690873857801615f1bf404c229a29986b96238/spring-boot-tests/spring-boot-yunai-tests/spring-boot-yunai-mvc-tests/src/main/java/cn/iocoder/springboot/mvc/MVCApplication.java) 。
+
+- `<2.1>` 处，创建 AnnotatedBeanDefinitionReader 对象，设置给 `annotatedReader` 属性。
+
+- `<2.2>` 处，创建 XmlBeanDefinitionReader 对象，设置给 `xmlReader` 属性。
+
+- `<2.3>` 处，创建 GroovyBeanDefinitionReader 对象，设置给 `groovyReader` 属性。其中，`#isGroovyPresent()` 方法，判断是否可以使用 Groovy 。代码如下：
+
+  ```
+  // BeanDefinitionLoader.java
+  
+  private boolean isGroovyPresent() {
+  	return ClassUtils.isPresent("groovy.lang.MetaClass", null);
+  }
+  ```
+
+- `<2.4>` 处，创建 ClassPathBeanDefinitionScanner 对象，并设置给 `scanner` 属性。其中，ClassExcludeFilter 是 BeanDefinitionLoader 的内部静态类，继承 AbstractTypeHierarchyTraversingFilter 抽象类，用于排除对 `sources` 的扫描。代码如下：
+
+  ```
+  // BeanDefinitionLoader.java
+  
+  /**
+   * Simple {@link TypeFilter} used to ensure that specified {@link Class} sources are
+   * not accidentally re-added during scanning.
+   */
+  private static class ClassExcludeFilter extends AbstractTypeHierarchyTraversingFilter {
+  
+  	private final Set<String> classNames = new HashSet<>();
+  
+  	ClassExcludeFilter(Object... sources) {
+  		super(false, false);
+  		for (Object source : sources) {
+  			if (source instanceof Class<?>) {
+  				this.classNames.add(((Class<?>) source).getName());
+  			}
+  		}
+  	}
+  
+  	@Override
+  	protected boolean matchClassName(String className) {
+  		return this.classNames.contains(className);
+  	}
+  
+  }
+  ```
+
+  - 如果不排除，则会出现重复读取 BeanDefinition 的情况。
+
+## 2.2 setBeanNameGenerator
+
+`#setBeanNameGenerator(BeanNameGenerator beanNameGenerator)` 方法，代码如下：
+
+```
+// BeanDefinitionLoader.java
+
+/**
+ * Set the bean name generator to be used by the underlying readers and scanner.
+ * @param beanNameGenerator the bean name generator
+ */
+public void setBeanNameGenerator(BeanNameGenerator beanNameGenerator) {
+	this.annotatedReader.setBeanNameGenerator(beanNameGenerator);
+	this.xmlReader.setBeanNameGenerator(beanNameGenerator);
+	this.scanner.setBeanNameGenerator(beanNameGenerator);
+}
+```
+
+## 2.3 setResourceLoader
+
+`#setResourceLoader(ResourceLoader resourceLoader)` 方法，代码如下：
+
+```
+// BeanDefinitionLoader.java
+
+/**
+ * Set the resource loader to be used by the underlying readers and scanner.
+ * @param resourceLoader the resource loader
+ */
+public void setResourceLoader(ResourceLoader resourceLoader) {
+	this.resourceLoader = resourceLoader;
+	this.xmlReader.setResourceLoader(resourceLoader);
+	this.scanner.setResourceLoader(resourceLoader);
+}
+```
+
+## 2.4 setEnvironment
+
+`#setEnvironment(ConfigurableEnvironment environment)` 方法，代码如下：
+
+```
+// BeanDefinitionLoader.java
+
+/**
+ * Set the environment to be used by the underlying readers and scanner.
+ * @param environment the environment
+ */
+public void setEnvironment(ConfigurableEnvironment environment) {
+	this.annotatedReader.setEnvironment(environment);
+	this.xmlReader.setEnvironment(environment);
+	this.scanner.setEnvironment(environment);
+}
+```
+
+## 2.5 load
+
+`#load()` 方法，执行 BeanDefinition 加载。代码如下：
+
+```
+// BeanDefinitionLoader.java
+
+/**
+ * Load the sources into the reader.
+ * @return the number of loaded beans
+ */
+public int load() {
+    int count = 0;
+    //  遍历 sources 数组，逐个加载
+    for (Object source : this.sources) {
+        count += load(source);
+    }
+    return count;
+}
+
+private int load(Object source) {
+    Assert.notNull(source, "Source must not be null");
+    // <1> 如果是 Class 类型，则使用 AnnotatedBeanDefinitionReader 执行加载
+    if (source instanceof Class<?>) {
+        return load((Class<?>) source);
+    }
+    // <2> 如果是 Resource 类型，则使用 XmlBeanDefinitionReader 执行加载
+    if (source instanceof Resource) {
+        return load((Resource) source);
+    }
+    // <3> 如果是 Package 类型，则使用 ClassPathBeanDefinitionScanner 执行加载
+    if (source instanceof Package) {
+        return load((Package) source);
+    }
+    // <4> 如果是 CharSequence 类型，则各种尝试去加载
+    if (source instanceof CharSequence) {
+        return load((CharSequence) source);
+    }
+    // <5> 无法处理的类型，抛出 IllegalArgumentException 异常
+    throw new IllegalArgumentException("Invalid source type " + source.getClass());
+}
+```
+
+- 针对不同 `source` 类型，执行不同的加载逻辑。
+- `<1>` 处，如果是 Class 类型，则调用 `#load(Class<?> source)` 方法，使用 AnnotatedBeanDefinitionReader 执行加载。详细解析，见 [「2.5.1 load(Class source)」](https://svip.iocoder.cn/Spring-Boot/BeanDefinitionLoader/#) 。
+- `<2>` 处，如果是 Resource 类型，则调用 `#load(Resource source)` 方法，使用 XmlBeanDefinitionReader 执行加载。详细解析，见 [「2.5.2 load(Resource source)」](https://svip.iocoder.cn/Spring-Boot/BeanDefinitionLoader/#) 。
+- `<3>` 处，如果是 Package 类型，则调用 `#load(Package source)` 方法，使用 ClassPathBeanDefinitionScanner 执行加载。详细解析，见 [「2.5.3 load(Package source)」](https://svip.iocoder.cn/Spring-Boot/BeanDefinitionLoader/#) 。
+- `<4>` 处，如果是 CharSequence 类型，则调用 `#load(CharSequence source)` 方法，各种尝试去加载。例如说 `source` 为 `"classpath:/applicationContext.xml"` 。详细解析，见 [「2.5.4 load(CharSequence source)」](https://svip.iocoder.cn/Spring-Boot/BeanDefinitionLoader/#) 。
+- `<5>` 处，无法处理的类型，抛出 IllegalArgumentException 异常。
+
+### 2.5.1 load(Class<?> source)
+
+`#load(Class<?> source)` 方法，使用 AnnotatedBeanDefinitionReader 执行加载。代码如下：
+
+```
+// BeanDefinitionLoader.java
+
+private int load(Class<?> source) {
+    // Groovy 相关，暂时忽略
+    if (isGroovyPresent()
+            && GroovyBeanDefinitionSource.class.isAssignableFrom(source)) {
+        // Any GroovyLoaders added in beans{} DSL can contribute beans here
+        GroovyBeanDefinitionSource loader = BeanUtils.instantiateClass(source, GroovyBeanDefinitionSource.class);
+        load(loader);
+    }
+    // <1> 如果是 Component ，则执行注册
+    if (isComponent(source)) {
+        this.annotatedReader.register(source); // <2>
+        return 1;
+    }
+    return 0;
+}
+```
+
+- `<1>` 处，调用 `#isComponent(Class<?> type)` 方法，判断是否为 Component 。代码如下：
+
+  ```
+  // BeanDefinitionLoader.java
+  
+  private boolean isComponent(Class<?> type) {
+      // This has to be a bit of a guess. The only way to be sure that this type is
+      // eligible is to make a bean definition out of it and try to instantiate it.
+      // 如果有 @Component 注解，则返回 true
+      if (AnnotationUtils.findAnnotation(type, Component.class) != null) {
+          return true;
+      }
+      // Nested anonymous classes are not eligible for registration, nor are groovy
+      // closures
+      // 暂时忽略
+      if (type.getName().matches(".*\\$_.*closure.*") || type.isAnonymousClass()
+              || type.getConstructors() == null || type.getConstructors().length == 0) {
+          return false;
+      }
+      return true;
+  }
+  ```
+
+  - 因为 Configuration 类，上面有 `@Configuration` 注解，而 `@Configuration` 上，自带 `@Component` 注解，所以该方法返回 `true` 。
+
+- `<2>` 处，调用 `AnnotatedBeanDefinitionReader#register(Class<?>... annotatedClasses)` 方法，执行注册。
+
+### 2.5.2 load(Resource source)
+
+`#load(Resource source)` 方法，使用 XmlBeanDefinitionReader 执行加载。代码如下：
+
+```
+// BeanDefinitionLoader.java
+
+private int load(Resource source) {
+    // Groovy 相关，暂时忽略
+    if (source.getFilename().endsWith(".groovy")) {
+        if (this.groovyReader == null) {
+            throw new BeanDefinitionStoreException("Cannot load Groovy beans without Groovy on classpath");
+        }
+        return this.groovyReader.loadBeanDefinitions(source);
+    }
+    // 使用 XmlBeanDefinitionReader 加载 BeanDefinition
+    return this.xmlReader.loadBeanDefinitions(source);
+}
+```
+
+- 调用 `XmlBeanDefinitionReader#loadBeanDefinitions(Resource resource)` 方法，从 XML 中加载 BeanDefinition 。
+
+### 2.5.3 load(Package source)
+
+`#load(Package source)` 方法，使用 ClassPathBeanDefinitionScanner 执行加载。代码如下：
+
+```
+// BeanDefinitionLoader.java
+
+private int load(Package source) {
+	return this.scanner.scan(source.getName());
+}
+```
+
+### 2.5.4 load(CharSequence source)
+
+`#load(CharSequence source)` 方法，各种尝试去加载。代码如下：
+
+> 按照 `source` 是 Class > Resource > Package 的顺序，尝试加载。
+
+```
+// BeanDefinitionLoader.java
+
+private int load(CharSequence source) {
+    // <1> 解析 source 。因为，有可能里面带有占位符。
+    String resolvedSource = this.xmlReader.getEnvironment().resolvePlaceholders(source.toString());
+    // <2> 尝试按照 Class 进行加载
+    // Attempt as a Class
+    try {
+        return load(ClassUtils.forName(resolvedSource, null));
+    } catch (IllegalArgumentException | ClassNotFoundException ex) {
+        // swallow exception and continue
+    }
+    // <3> 尝试按照 Resource 进行加载
+    // Attempt as resources
+    Resource[] resources = findResources(resolvedSource); // <3.1>
+    int loadCount = 0;
+    boolean atLeastOneResourceExists = false;
+    for (Resource resource : resources) {
+        if (isLoadCandidate(resource)) { // <3.2>
+            atLeastOneResourceExists = true;
+            loadCount += load(resource); // <3.3>
+        }
+    }
+    if (atLeastOneResourceExists) { // <3.4> 有加载到，则认为成功，返回。
+        return loadCount;
+    }
+    // Attempt as package
+    // <4> 尝试按照 Package 进行加载
+    Package packageResource = findPackage(resolvedSource); // <4.1>
+    if (packageResource != null) {
+        return load(packageResource); // <4.2>
+    }
+    // <5> 无法处理，抛出 IllegalArgumentException 异常
+    throw new IllegalArgumentException("Invalid source '" + resolvedSource + "'");
+}
+```
+
+- `<1>` 处，解析 `source` 。因为，有可能里面带有占位符。
+
+- `<2>` 处，将 `source` 转换成 Class ，然后执行 [「2.5.1 load(Class source)」](https://svip.iocoder.cn/Spring-Boot/BeanDefinitionLoader/#) 的流程。
+
+- `<3>` 处，尝试按照 Resource 进行加载。
+
+- `<3.1>` 处，调用 `#findResources(String source)` 方法，获得 `source` 对应的 Resource 数组。代码如下：
+
+  ```
+  // BeanDefinitionLoader.java
+  
+  private Resource[] findResources(String source) {
+      // 创建 ResourceLoader 对象
+      ResourceLoader loader = (this.resourceLoader != null) ? this.resourceLoader : new PathMatchingResourcePatternResolver();
+      try {
+          // 获得 Resource 数组
+          if (loader instanceof ResourcePatternResolver) {
+              return ((ResourcePatternResolver) loader).getResources(source);
+          }
+          // 获得 Resource 对象
+          return new Resource[] { loader.getResource(source) };
+      } catch (IOException ex) {
+          throw new IllegalStateException("Error reading source '" + source + "'");
+      }
+  }
+  ```
+
+- `<3.2>` 处，遍历 `resources` 数组，调用 `#isLoadCandidate(Resource resource)` 方法，判断是否为符合条件的 Resource 。代码如下：
+
+  ```
+  // BeanDefinitionLoader.java
+  
+  private boolean isLoadCandidate(Resource resource) {
+      // 不存在，则返回 false
+      if (resource == null || !resource.exists()) {
+          return false;
+      }
+      // 判断 resource 是 ClassPathResource 类，不是一个 package
+      if (resource instanceof ClassPathResource) {
+          // A simple package without a '.' may accidentally get loaded as an XML
+          // document if we're not careful. The result of getInputStream() will be
+          // a file list of the package content. We double check here that it's not
+          // actually a package.
+          String path = ((ClassPathResource) resource).getPath();
+          if (path.indexOf('.') == -1) {
+              try {
+                  return Package.getPackage(path) == null;
+              } catch (Exception ex) {
+                  // Ignore
+              }
+          }
+      }
+      // 返回 true ，符合条件
+      return true;
+  }
+  ```
+
+- `<3.3>` 处，执行 [「2.5.2 load(Resource source)」](https://svip.iocoder.cn/Spring-Boot/BeanDefinitionLoader/#) 的流程。
+
+- `<3.4>` 处，有加载到，则认为成功，返回。
+
+- `<4>` 处，尝试按照 Package 进行加载。
+
+- `<4.1>` 处，调用 `#findPackage(CharSequence source)` 方法，获得 Package 对象。代码如下：
+
+  ```
+  // BeanDefinitionLoader.java
+  
+  private Package findPackage(CharSequence source) {
+      // <X> 获得 source 对应的 Package 。如果存在，则返回
+      Package pkg = Package.getPackage(source.toString());
+      if (pkg != null) {
+          return pkg;
+      }
+      try {
+          // Attempt to find a class in this package
+          // 创建 ResourcePatternResolver 对象
+          ResourcePatternResolver resolver = new PathMatchingResourcePatternResolver(getClass().getClassLoader());
+          // 尝试加载 source 目录下的 class 们
+          Resource[] resources = resolver.getResources(ClassUtils.convertClassNameToResourcePath(source.toString()) + "/*.class");
+          // 遍历 resources 数组
+          for (Resource resource : resources) {
+              // 获得类名
+              String className = StringUtils.stripFilenameExtension(resource.getFilename());
+              // 按照 Class 进行加载 BeanDefinition
+              load(Class.forName(source.toString() + "." + className));
+              break;
+          }
+      } catch (Exception ex) {
+          // swallow exception and continue
+      }
+      // 返回 Package
+      return Package.getPackage(source.toString());
+  }
+  ```
+
+  - 虽然逻辑比较复杂，我们只需要看看 `<X>` 处的前半部分的逻辑即可。
+
+- `<4.2>` 处，执行 [「2.5.3 load(Package source)」](https://svip.iocoder.cn/Spring-Boot/BeanDefinitionLoader/#) 的流程。
+
+- `<5>` 处，无法处理，抛出 IllegalArgumentException 异常。
+
+# 666. 彩蛋
+
+简单小文一篇。如果胖友不了解 Spring BeanDefinition ，可以补充看看 [《【死磕 Spring】—— IoC 之加载 BeanDefinition》](http://svip.iocoder.cn/Spring/IoC-load-BeanDefinitions/) 文章。
+
+如果想要测试 SpringFactoriesLoader 的各种情况，可以调试 BeanDefinitionLoaderTests 提供的单元测试。
+
+参考和推荐如下文章：
+
+- 一个努力的码农 [《spring boot 源码解析8-SpringApplication#run第8步》](https://blog.csdn.net/qq_26000415/article/details/78915211)
+- oldflame-Jm [《Spring boot源码分析-BeanDefinitionLoader（7）》](https://blog.csdn.net/jamet/article/details/78291900)
\ No newline at end of file
diff --git a/springboot/18-Spring Boot 源码分析-SpringFactoriesLoader.md b/springboot/18-Spring Boot 源码分析-SpringFactoriesLoader.md
new file mode 100644
index 0000000..a14c75d
--- /dev/null
+++ b/springboot/18-Spring Boot 源码分析-SpringFactoriesLoader.md	
@@ -0,0 +1,205 @@
+# 精尽 Spring Boot 源码分析 —— SpringFactoriesLoader
+
+# 1. 概述
+
+本文，我们来补充 [《精尽 Spring Boot 源码分析 —— SpringApplication》](http://svip.iocoder.cn/Spring-Boot/SpringApplication) 文章，并未详细解析的 SpringFactoriesLoader 。
+
+- `spring.factories` 配置文件，我们可以认为是 Spring 自己的一套 SPI 机制的配置文件，在里面可以配置不同接口对应的实现类**们**。例如：
+
+  ```
+  # PropertySource Loaders
+  org.springframework.boot.env.PropertySourceLoader=\
+  org.springframework.boot.env.PropertiesPropertySourceLoader,\
+  org.springframework.boot.env.YamlPropertySourceLoader
+  
+  # Run Listeners
+  org.springframework.boot.SpringApplicationRunListener=\
+  org.springframework.boot.context.event.EventPublishingRunListener
+  
+  // ... 省略其它
+  ```
+
+  - 并且，Spring 内置了多个 `spring.factories` 配置文件。另外，我们也可以添加 `spring.factories` 配置文件。
+
+- SpringFactoriesLoader 类，用于加载 `spring.factories` 配置文件。
+
+> 艿艿：如果对 Java SPI 不了解的胖友，推荐后面看看 [《JAVA 拾遗 —— 关于 SPI 机制》](http://www.iocoder.cn/Fight/xuma/spi/?vip) 文章。
+
+# 2. SpringFactoriesLoader
+
+`org.springframework.core.io.support.SpringFactoriesLoader` ，加载 `spring.factories` 的工具类。其类上，注释如下：
+
+```
+// SpringFactoriesLoader.java
+
+/**
+ * General purpose factory loading mechanism for internal use within the framework.
+ *
+ * <p>{@code SpringFactoriesLoader} {@linkplain #loadFactories loads} and instantiates
+ * factories of a given type from {@value #FACTORIES_RESOURCE_LOCATION} files which
+ * may be present in multiple JAR files in the classpath. The {@code spring.factories}
+ * file must be in {@link Properties} format, where the key is the fully qualified
+ * name of the interface or abstract class, and the value is a comma-separated list of
+ * implementation class names. For example:
+ *
+ * <pre class="code">example.MyService=example.MyServiceImpl1,example.MyServiceImpl2</pre>
+ *
+ * where {@code example.MyService} is the name of the interface, and {@code MyServiceImpl1}
+ * and {@code MyServiceImpl2} are two implementations.
+ */
+```
+
+从包名我们就可以看出，SpringFactoriesLoader 是 Spring Framework 就已经提供的工具类，😈 而不是 Spring Boot 所特有的。
+
+## 2.1 构造方法
+
+```
+// SpringFactoriesLoader.java
+
+/**
+ * The location to look for factories.
+ * <p>Can be present in multiple JAR files.
+ */
+public static final String FACTORIES_RESOURCE_LOCATION = "META-INF/spring.factories";
+
+private static final Log logger = LogFactory.getLog(SpringFactoriesLoader.class);
+
+/**
+ * 缓存
+ *
+ * KEY1 ：ClassLoader
+ * KEY2 ：接口的类名
+ * VALUE ：实现的类名的数组。注意哟，是个 MultiValueMap 类
+ */
+private static final Map<ClassLoader, MultiValueMap<String, String>> cache = new ConcurrentReferenceHashMap<>();
+
+private SpringFactoriesLoader() {
+}
+```
+
+- `FACTORIES_RESOURCE_LOCATION` 静态属性，定义了读取的是 `"META-INF/spring.factories"` 配置文件。并且，每个 JAR 文件里，都可以有一个这个配置文件。
+- `cache` 静态属性，读取 `"META-INF/spring.factories"` 配置文件的缓存。
+
+## 2.2 loadFactoryNames
+
+`#loadFactoryNames(Class<?> factoryClass, @Nullable ClassLoader classLoader)` 静态方法，获得接口对应的实现类名们。代码如下：
+
+```
+// SpringFactoriesLoader.java
+
+/**
+ * Load the fully qualified class names of factory implementations of the
+ * given type from {@value #FACTORIES_RESOURCE_LOCATION}, using the given
+ * class loader.
+ * @param factoryClass the interface or abstract class representing the factory
+ * @param classLoader the ClassLoader to use for loading resources; can be
+ * {@code null} to use the default
+ * @throws IllegalArgumentException if an error occurs while loading factory names
+ * @see #loadFactories
+ */
+public static List<String> loadFactoryNames(Class<?> factoryClass, @Nullable ClassLoader classLoader) {
+    // 获得接口的类名
+    String factoryClassName = factoryClass.getName();
+    // 加载 FACTORIES_RESOURCE_LOCATION 配置文件，获得接口对应的实现类名们
+    return loadSpringFactories(classLoader).getOrDefault(factoryClassName, Collections.emptyList());
+}
+
+private static Map<String, List<String>> loadSpringFactories(@Nullable ClassLoader classLoader) {
+    // 如果缓存中已经存在，则直接返回
+    MultiValueMap<String, String> result = cache.get(classLoader);
+    if (result != null) {
+        return result;
+    }
+
+    try {
+        // 获得 FACTORIES_RESOURCE_LOCATION 对应的 URL 们
+        Enumeration<URL> urls = (classLoader != null ? classLoader.getResources(FACTORIES_RESOURCE_LOCATION) : ClassLoader.getSystemResources(FACTORIES_RESOURCE_LOCATION));
+        // 创建 LinkedMultiValueMap 对象
+        result = new LinkedMultiValueMap<>();
+        // 遍历 URL 数组
+        while (urls.hasMoreElements()) {
+            // 获得 URL
+            URL url = urls.nextElement();
+            // 创建 UrlResource 对象
+            UrlResource resource = new UrlResource(url);
+            // 加载 "META-INF/spring.factories" 配置文件，成为 Properties 对象
+            Properties properties = PropertiesLoaderUtils.loadProperties(resource);
+            // 遍历 Properties 对象
+            for (Map.Entry<?, ?> entry : properties.entrySet()) {
+                // 使用逗号分隔
+                List<String> factoryClassNames = Arrays.asList(StringUtils.commaDelimitedListToStringArray((String) entry.getValue()));
+                // 添加到 result 中
+                result.addAll((String) entry.getKey(), factoryClassNames);
+            }
+        }
+        // 添加到 cache 中
+        cache.put(classLoader, result);
+        return result;
+    } catch (IOException ex) {
+        throw new IllegalArgumentException("Unable to load factories from location [" + FACTORIES_RESOURCE_LOCATION + "]", ex);
+    }
+}
+```
+
+- 加载 `FACTORIES_RESOURCE_LOCATION` 配置文件，获得接口对应的实现类名们。
+
+## 2.3 loadFactories
+
+`#loadFactories(Class<T> factoryClass, @Nullable ClassLoader classLoader)` **静态**方法，获得接口对应的实现类名们，然后创建对应的对象们。代码如下：
+
+```
+// SpringFactoriesLoader.java
+
+/**
+ * Load and instantiate the factory implementations of the given type from
+ * {@value #FACTORIES_RESOURCE_LOCATION}, using the given class loader.
+ * <p>The returned factories are sorted through {@link AnnotationAwareOrderComparator}.
+ * <p>If a custom instantiation strategy is required, use {@link #loadFactoryNames}
+ * to obtain all registered factory names.
+ * @param factoryClass the interface or abstract class representing the factory
+ * @param classLoader the ClassLoader to use for loading (can be {@code null} to use the default)
+ * @throws IllegalArgumentException if any factory implementation class cannot
+ * be loaded or if an error occurs while instantiating any factory
+ * @see #loadFactoryNames
+ */
+public static <T> List<T> loadFactories(Class<T> factoryClass, @Nullable ClassLoader classLoader) {
+    Assert.notNull(factoryClass, "'factoryClass' must not be null");
+    // 获得 ClassLoader
+    ClassLoader classLoaderToUse = classLoader;
+    if (classLoaderToUse == null) {
+        classLoaderToUse = SpringFactoriesLoader.class.getClassLoader();
+    }
+    // 获得接口对应的实现类名们
+    List<String> factoryNames = loadFactoryNames(factoryClass, classLoaderToUse);
+    if (logger.isTraceEnabled()) {
+        logger.trace("Loaded [" + factoryClass.getName() + "] names: " + factoryNames);
+    }
+    // 遍历 factoryNames 数组，创建实现类的对象
+    List<T> result = new ArrayList<>(factoryNames.size());
+    for (String factoryName : factoryNames) {
+        result.add(instantiateFactory(factoryName, factoryClass, classLoaderToUse));
+    }
+    // 排序
+    AnnotationAwareOrderComparator.sort(result);
+    return result;
+}
+
+private static <T> T instantiateFactory(String instanceClassName, Class<T> factoryClass, ClassLoader classLoader) {
+    try {
+        // 获得 Class 类
+        Class<?> instanceClass = ClassUtils.forName(instanceClassName, classLoader);
+        // 判断是否实现了指定接口
+        if (!factoryClass.isAssignableFrom(instanceClass)) {
+            throw new IllegalArgumentException("Class [" + instanceClassName + "] is not assignable to [" + factoryClass.getName() + "]");
+        }
+        // 创建对象
+        return (T) ReflectionUtils.accessibleConstructor(instanceClass).newInstance();
+    } catch (Throwable ex) {
+        throw new IllegalArgumentException("Unable to instantiate factory class: " + factoryClass.getName(), ex);
+    }
+}
+```
+
+# 666. 彩蛋
+
+水文一篇，哇咔咔~
\ No newline at end of file
diff --git a/springboot/19-Spring Boot 源码分析-AutoConfigurationMetadataLoader.md b/springboot/19-Spring Boot 源码分析-AutoConfigurationMetadataLoader.md
new file mode 100644
index 0000000..22fc27e
--- /dev/null
+++ b/springboot/19-Spring Boot 源码分析-AutoConfigurationMetadataLoader.md	
@@ -0,0 +1,575 @@
+# 精尽 Spring Boot 源码分析 —— AutoConfigurationMetadataLoader
+
+# 1. 概述
+
+本文，我们来补充 [《精尽 Spring Boot 源码分析 —— 自动配置》](http://svip.iocoder.cn/Spring-Boot/AutoConfiguration) 文章，并未详细解析的 AutoConfigurationMetadataLoader 。在 SpringApplication 中，我们可以看到 `AutoConfigurationImportSelector.AutoConfigurationGroup#loadMetadata(ClassLoader classLoader, String path)` 方法中，加载自动配置类（AutoConfiguration）的元数据，是如下一段代码：
+
+```
+// AutoConfigurationImportSelector.AutoConfigurationGroup.java
+
+/**
+ * @return 获得 AutoConfigurationMetadata 对象
+ */
+private AutoConfigurationMetadata getAutoConfigurationMetadata() {
+    // 不存在，则进行加载
+    if (this.autoConfigurationMetadata == null) {
+        this.autoConfigurationMetadata = AutoConfigurationMetadataLoader.loadMetadata(this.beanClassLoader);
+    }
+    // 存在，则直接返回
+    return this.autoConfigurationMetadata;
+}
+```
+
+- 在内部，会调用 `AutoConfigurationMetadataLoader#loadMetadata(ClassLoader classLoader)` 方法，加载 AutoConfigurationMetadata 对象。
+- 而我们知道，后续会基于返回的 AutoConfigurationMetadata 对象，进行 AutoConfiguration 类的**过滤**，从而避免不符合条件的 AutoConfiguration 类的字节码，加载到 JVM 中。那么是怎么做到的呢？我们接着来看 [「2. AutoConfigurationMetadataLoader」](https://svip.iocoder.cn/Spring-Boot/AutoConfigurationMetadataLoader/#) 。
+
+# 2. AutoConfigurationMetadataLoader
+
+`org.springframework.boot.autoconfigure.AutoConfigurationMetadataLoader` ，AutoConfigurationMetadata 加载器。其类上的注释如下：
+
+```
+/**
+ * Internal utility used to load {@link AutoConfigurationMetadata}.
+ */
+```
+
+## 2.1 loadMetadata
+
+`#loadMetadata(ClassLoader classLoader)` **静态**方法，加载 AutoConfigurationMetadata 。代码如下：
+
+```
+// AutoConfigurationMetadataLoader.java
+
+protected static final String PATH = "META-INF/" + "spring-autoconfigure-metadata.properties";
+
+public static AutoConfigurationMetadata loadMetadata(ClassLoader classLoader) {
+    return loadMetadata(classLoader, PATH);
+}
+
+static AutoConfigurationMetadata loadMetadata(ClassLoader classLoader, String path) {
+    try {
+        // <1> 获得 PATH 对应的 URL 们
+        Enumeration<URL> urls = (classLoader != null) ? classLoader.getResources(path) : ClassLoader.getSystemResources(path);
+        // <2> 遍历 URL 数组，读取到 properties 中
+        Properties properties = new Properties();
+        while (urls.hasMoreElements()) {
+            properties.putAll(PropertiesLoaderUtils.loadProperties(new UrlResource(urls.nextElement())));
+        }
+        // <3> 将 properties 转换成 PropertiesAutoConfigurationMetadata 对象
+        return loadMetadata(properties);
+    } catch (IOException ex) {
+        throw new IllegalArgumentException("Unable to load @ConditionalOnClass location [" + path + "]", ex);
+    }
+}
+```
+
+- `<1>` 处，获得 `PATH` 对应的 URL 们，而 `PATH` 就是 `"META-INF/spring-autoconfigure-metadata.properties"` 文件。这样，我们就可以避免去 AutoConfiguration 类上，读取其 Condition 条件了，从而避免将不符合条件的 AutoConfiguration 类的字节码，加载到 JVM 中。那么，此时就会有一个疑问，`"META-INF/spring-autoconfigure-metadata.properties"` 是怎么来的呢？答案我们在 [「3. AutoConfigureAnnotationProcessor」](https://svip.iocoder.cn/Spring-Boot/AutoConfigurationMetadataLoader/#) 中说。
+
+- `<2>` 处，遍历 URL 数组，读取到 `properties` 中。
+
+- `<3>` 处，调用 `#loadMetadata(Properties properties)` 方法，将 `properties` 转换成 PropertiesAutoConfigurationMetadata 对象。代码如下：
+
+  ```
+  // AutoConfigurationMetadataLoader.java
+  
+  static AutoConfigurationMetadata loadMetadata(Properties properties) {
+  	return new PropertiesAutoConfigurationMetadata(properties);
+  }
+  ```
+
+  - 关于 PropertiesAutoConfigurationMetadata 类，在 [「2.2 」](https://svip.iocoder.cn/Spring-Boot/AutoConfigurationMetadataLoader/#) 中看。
+
+## 2.2 PropertiesAutoConfigurationMetadata
+
+PropertiesAutoConfigurationMetadata ，是 AutoConfigurationMetadataLoader 的内部静态类，实现 AutoConfigurationMetadata 接口，代码如下：
+
+```
+// AutoConfigurationMetadataLoader#PropertiesAutoConfigurationMetadata.java
+
+/**
+ * {@link AutoConfigurationMetadata} implementation backed by a properties file.
+ */
+private static class PropertiesAutoConfigurationMetadata implements AutoConfigurationMetadata {
+
+    /**
+     * Properties 对象
+     */
+    private final Properties properties;
+
+    PropertiesAutoConfigurationMetadata(Properties properties) {
+        this.properties = properties;
+    }
+
+    @Override
+    public boolean wasProcessed(String className) {
+        return this.properties.containsKey(className);
+    }
+
+    @Override
+    public Integer getInteger(String className, String key) {
+        return getInteger(className, key, null);
+    }
+
+    @Override
+    public Integer getInteger(String className, String key, Integer defaultValue) {
+        String value = get(className, key);
+        return (value != null) ? Integer.valueOf(value) : defaultValue;
+    }
+
+    @Override
+    public Set<String> getSet(String className, String key) {
+        return getSet(className, key, null);
+    }
+
+    @Override
+    public Set<String> getSet(String className, String key, Set<String> defaultValue) {
+        String value = get(className, key);
+        return (value != null) ? StringUtils.commaDelimitedListToSet(value) : defaultValue;
+    }
+
+    @Override
+    public String get(String className, String key) {
+        return get(className, key, null);
+    }
+
+    @Override
+    public String get(String className, String key, String defaultValue) {
+        String value = this.properties.getProperty(className + "." + key);
+        return (value != null) ? value : defaultValue;
+    }
+
+}
+```
+
+# 3. AutoConfigureAnnotationProcessor
+
+在 Spring Boot 的源码中，我们如果去检索 `"spring-autoconfigure-metadata.properties"` 文件，然而并找不到。是不是感觉很奇怪。于是乎，艿艿在搜索了一些网络的上的资料，原来是需要引入 `spring-boot-autoconfigure-processor` 依赖。这样，它的 AutoConfigureAnnotationProcessor 类，就会自动根据 AutoConfiguration 类的条件，生成 `"META-INF/spring-autoconfigure-metadata.properties"` 文件。
+
+那么，此时又会有一个疑惑，那是什么时候生成呢？AutoConfigureAnnotationProcessor 继承自 `javax.annotation.processing.AbstractProcessor` 类，它可以在**编译时**，扫描和处理注解（Annotation），从而生成 `"META-INF/spring-autoconfigure-metadata.properties"` 文件。😈 很有意思。
+
+> FROM [《Java 注解处理器》](https://www.race604.com/annotation-processing/)
+>
+> 注解处理器（Annotation Processor）是**javac**的一个工具，它用来在编译时扫描和处理注解（Annotation）。你可以对自定义注解，并注册相应的注解处理器。到这里，我假设你已经知道什么是注解，并且知道怎么申明的一个注解。如果你不熟悉注解，你可以在这[官方文档](http://docs.oracle.com/javase/tutorial/java/annotations/index.html)中得到更多信息。注解处理器在Java 5开始就有了，但是从Java 6（2006年12月发布）开始才有可用的API。过了一些时间，Java世界才意识到注解处理器的强大作用，所以它到最近几年才流行起来。
+
+那么，我们开始撸撸 AutoConfigureAnnotationProcessor 的源码吧。
+
+`org.springframework.boot.autoconfigureprocessor.AutoConfigureAnnotationProcessor` ，继承 AbstractProcessor 抽象类，根据 AutoConfiguration 类的条件，生成 `"META-INF/spring-autoconfigure-metadata.properties"` 文件。其类上注释如下：
+
+```
+// AutoConfigureAnnotationProcessor.java
+
+/**
+ * Annotation processor to store certain annotations from auto-configuration classes in a
+ * property file.
+ */
+```
+
+## 3.1 构造方法
+
+```
+// AutoConfigureAnnotationProcessor.java
+
+/**
+ * 注解名和全类名的映射
+ *
+ * KEY：注解名
+ * VALUE：全类名
+ */
+private final Map<String, String> annotations;
+/**
+ * 注解名和 ValueExtractor 的映射
+ *
+ * KEY：注解名
+ */
+private final Map<String, ValueExtractor> valueExtractors;
+
+/**
+ * 扫描和处理注解（Annotation），生成的 Properties 对象
+ */
+private final Properties properties = new Properties();
+
+public AutoConfigureAnnotationProcessor() {
+    // <1> 初始化 annotations 属性
+    Map<String, String> annotations = new LinkedHashMap<>();
+    addAnnotations(annotations);
+    this.annotations = Collections.unmodifiableMap(annotations);
+    // <2> 初始化 valueExtractors 属性
+    Map<String, ValueExtractor> valueExtractors = new LinkedHashMap<>();
+    addValueExtractors(valueExtractors);
+    this.valueExtractors = Collections.unmodifiableMap(valueExtractors);
+}
+```
+
+- ```
+  annotations
+  ```
+
+   
+
+  属性，注解名和全类名的映射。在
+
+   
+
+  ```
+  <1>
+  ```
+
+   
+
+  处，调用
+
+   
+
+  ```
+  #addAnnotations(Map<String, String> annotations)
+  ```
+
+   
+
+  方法，进行初始化。代码如下：
+
+  ```
+  // AutoConfigureAnnotationProcessor.java
+  
+  protected void addAnnotations(Map<String, String> annotations) {
+  	// 条件
+  	annotations.put("Configuration", "org.springframework.context.annotation.Configuration");
+  	annotations.put("ConditionalOnClass", "org.springframework.boot.autoconfigure.condition.ConditionalOnClass");
+  	annotations.put("ConditionalOnBean", "org.springframework.boot.autoconfigure.condition.ConditionalOnBean");
+  	annotations.put("ConditionalOnSingleCandidate", "org.springframework.boot.autoconfigure.condition.ConditionalOnSingleCandidate");
+  	annotations.put("ConditionalOnWebApplication", "org.springframework.boot.autoconfigure.condition.ConditionalOnWebApplication");
+  	// 排序
+  	annotations.put("AutoConfigureBefore", "org.springframework.boot.autoconfigure.AutoConfigureBefore");
+  	annotations.put("AutoConfigureAfter", "org.springframework.boot.autoconfigure.AutoConfigureAfter");
+  	annotations.put("AutoConfigureOrder", "org.springframework.boot.autoconfigure.AutoConfigureOrder");
+  }
+  ```
+
+- ```
+  valueExtractors
+  ```
+
+   
+
+  属性，注解名和 ValueExtractor 的映射。在
+
+   
+
+  ```
+  <2>
+  ```
+
+   
+
+  处，调用
+
+   
+
+  ```
+  #addValueExtractors(Map<String, ValueExtractor> attributes)
+  ```
+
+   
+
+  方法，进行初始化。代码如下：
+
+  ```
+  // AutoConfigureAnnotationProcessor.java
+  
+  private void addValueExtractors(Map<String, ValueExtractor> attributes) {
+      attributes.put("Configuration", ValueExtractor.allFrom("value"));
+      attributes.put("ConditionalOnClass", new OnClassConditionValueExtractor());
+      attributes.put("ConditionalOnBean", new OnBeanConditionValueExtractor());
+      attributes.put("ConditionalOnSingleCandidate", new OnBeanConditionValueExtractor());
+      attributes.put("ConditionalOnWebApplication", ValueExtractor.allFrom("type"));
+      attributes.put("AutoConfigureBefore", ValueExtractor.allFrom("value", "name"));
+      attributes.put("AutoConfigureAfter", ValueExtractor.allFrom("value", "name"));
+      attributes.put("AutoConfigureOrder", ValueExtractor.allFrom("value"));
+  }
+  ```
+
+- `properties` 属性，扫描和处理注解（Annotation），生成的 Properties 对象。
+
+## 3.2 ValueExtractor
+
+ValueExtractor ，是 AutoConfigureAnnotationProcessor 的内部接口，值提取器接口。代码如下：
+
+```
+// AutoConfigureAnnotationProcessor#ValueExtractor.java
+
+@FunctionalInterface
+private interface ValueExtractor {
+
+    /**
+     * 从注解中，获得对应的值的数组
+     *
+     * @param annotation 注解
+     * @return 值的数组
+     */
+    List<Object> getValues(AnnotationMirror annotation);
+
+    /**
+     * 创建 NamedValuesExtractor 对象
+     *
+     * @param names 从注解的指定 names 中，提取值们
+     * @return NamedValuesExtractor 对象
+     */
+    static ValueExtractor allFrom(String... names) {
+        return new NamedValuesExtractor(names);
+    }
+
+}
+```
+
+### 3.2.1 AbstractValueExtractor
+
+AbstractValueExtractor ，是 AutoConfigureAnnotationProcessor 的内部类，实现 ValueExtractor 接口，ValueExtractor 抽象实现类。代码如下：
+
+```
+// AutoConfigureAnnotationProcessor#AbstractValueExtractor.java
+
+private abstract static class AbstractValueExtractor implements ValueExtractor {
+
+    @SuppressWarnings("unchecked")
+    protected Stream<Object> extractValues(AnnotationValue annotationValue) {
+        // 注解值为空，返回空
+        if (annotationValue == null) {
+            return Stream.empty();
+        }
+        Object value = annotationValue.getValue();
+        // 注解值为数组，则遍历数组，逐个提取值
+        if (value instanceof List) {
+            return ((List<AnnotationValue>) value).stream()
+                    .map((annotation) -> extractValue(annotation.getValue()));
+        }
+        // 注解值非数组，直接提取值
+        return Stream.of(extractValue(value));
+    }
+
+    private Object extractValue(Object value) {
+        if (value instanceof DeclaredType) {
+            return Elements.getQualifiedName(((DeclaredType) value).asElement());
+        }
+        return value;
+    }
+
+}
+```
+
+- 提供了从 AnnotationValue 读取值的公用方法。
+
+### 3.2.2 NamedValuesExtractor
+
+NamedValuesExtractor ，是 AutoConfigureAnnotationProcessor 的内部类，继承 AbstractValueExtractor 抽象类，读取 `names` 的 ValueExtractor 实现类。代码如下：
+
+```
+// AutoConfigureAnnotationProcessor#NamedValuesExtractor.java
+
+private static class NamedValuesExtractor extends AbstractValueExtractor {
+
+    private final Set<String> names;
+
+    NamedValuesExtractor(String... names) {
+        this.names = new HashSet<>(Arrays.asList(names));
+    }
+
+    @Override
+    public List<Object> getValues(AnnotationMirror annotation) {
+        List<Object> result = new ArrayList<>();
+        // 遍历 names 数组，读取 name 对应的值，添加到 result 中
+        annotation.getElementValues().forEach((key, value) -> {
+            if (this.names.contains(key.getSimpleName().toString())) {
+                extractValues(value).forEach(result::add);
+            }
+        });
+        return result;
+    }
+
+}
+```
+
+### 3.2.3 OnBeanConditionValueExtractor
+
+OnBeanConditionValueExtractor ，是 AutoConfigureAnnotationProcessor 的内部类，继承 AbstractValueExtractor 抽象类，读取 `@ConditionalOnBean` 和 `@ConditionalOnSingleCandidate` 注解的 ValueExtractor 实现类。代码如下：
+
+```
+// AutoConfigureAnnotationProcessor#OnBeanConditionValueExtractor.java
+
+private static class OnBeanConditionValueExtractor extends AbstractValueExtractor {
+
+    @Override
+    public List<Object> getValues(AnnotationMirror annotation) {
+        // 遍历注解的元素们，读取到 attributes 中
+        Map<String, AnnotationValue> attributes = new LinkedHashMap<>();
+        annotation.getElementValues().forEach((key, value) -> attributes.put(key.getSimpleName().toString(), value));
+        // 如果 "name" 对应的值为空，返回空
+        if (attributes.containsKey("name")) {
+            return Collections.emptyList();
+        }
+        // 读取 "value"、`"type"` 对应的值，添加到 result 中
+        List<Object> result = new ArrayList<>();
+        extractValues(attributes.get("value")).forEach(result::add);
+        extractValues(attributes.get("type")).forEach(result::add);
+        return result;
+    }
+
+}
+```
+
+### 3.2.4 OnClassConditionValueExtractor
+
+OnClassConditionValueExtractor ，是 AutoConfigureAnnotationProcessor 的内部类，继承 NamedValuesExtractor 类，读取 `@OnClassConditionValueExtractor` 注解的 ValueExtractor 实现类。代码如下：
+
+```
+// AutoConfigureAnnotationProcessor#OnClassConditionValueExtractor.java
+
+private static class OnClassConditionValueExtractor extends NamedValuesExtractor {
+
+    OnClassConditionValueExtractor() {
+        super("value", "name");
+    }
+
+    @Override
+    public List<Object> getValues(AnnotationMirror annotation) {
+        // 读取 "value", "name" 的值
+        List<Object> values = super.getValues(annotation);
+        // 排序
+        values.sort(this::compare);
+        return values;
+    }
+
+    private int compare(Object o1, Object o2) {
+        return Comparator.comparing(this::isSpringClass)
+                .thenComparing(String.CASE_INSENSITIVE_ORDER)
+                .compare(o1.toString(), o2.toString());
+    }
+
+    private boolean isSpringClass(String type) {
+        return type.startsWith("org.springframework");
+    }
+
+}
+```
+
+## 3.3 process
+
+实现 `#process(Set<? extends TypeElement> annotations, RoundEnvironment roundEnv)` 方法，进行处理。代码如下：
+
+```
+// AutoConfigureAnnotationProcessor.java
+
+@Override
+public boolean process(Set<? extends TypeElement> annotations, RoundEnvironment roundEnv) {
+    // <1> 遍历 annotations 集合，逐个处理
+    for (Map.Entry<String, String> entry : this.annotations.entrySet()) {
+		process(roundEnv, entry.getKey(), entry.getValue());
+	}
+	// <2> 处理完成，写到文件 PROPERTIES_PATH 中
+	if (roundEnv.processingOver()) {
+		try {
+			writeProperties();
+		} catch (Exception ex) {
+			throw new IllegalStateException("Failed to write metadata", ex);
+		}
+	}
+	return false;
+}
+```
+
+- `<1>` 处，调用 `#process(RoundEnvironment roundEnv, String propertyKey, String annotationName)` 方法，遍历 `annotations` 集合，逐个处理，添加到 `properties` 中。代码如下：
+
+  ```
+  // AutoConfigureAnnotationProcessor.java
+  
+  private void process(RoundEnvironment roundEnv, String propertyKey, String annotationName) {
+      TypeElement annotationType = this.processingEnv.getElementUtils().getTypeElement(annotationName);
+      if (annotationType != null) {
+          for (Element element : roundEnv.getElementsAnnotatedWith(annotationType)) {
+              Element enclosingElement = element.getEnclosingElement();
+              if (enclosingElement != null
+                      && enclosingElement.getKind() == ElementKind.PACKAGE) {
+                  processElement(element, propertyKey, annotationName);
+              }
+          }
+      }
+  }
+  
+  // propertyKey=注解名
+  // annotationName=全类名
+  private void processElement(Element element, String propertyKey, String annotationName) {
+      try {
+          // 获得自动配置类的全类名。例如说：org.springframework.boot.autoconfigure.transaction.TransactionAutoConfiguration
+          String qualifiedName = Elements.getQualifiedName(element);
+          // 获得 AnnotationMirror 对象
+          AnnotationMirror annotation = getAnnotation(element, annotationName);
+          if (qualifiedName != null && annotation != null) {
+              // 获得值
+              List<Object> values = getValues(propertyKey, annotation);
+              // 添加到 properties 中
+              this.properties.put(qualifiedName + "." + propertyKey, toCommaDelimitedString(values));
+              // 添加到 properties 中
+              this.properties.put(qualifiedName, "");
+          }
+      } catch (Exception ex) {
+          throw new IllegalStateException("Error processing configuration meta-data on " + element, ex);
+      }
+  }
+  
+  // 获得 AnnotationMirror 对象
+  private AnnotationMirror getAnnotation(Element element, String type) {
+      if (element != null) {
+          for (AnnotationMirror annotation : element.getAnnotationMirrors()) {
+              if (type.equals(annotation.getAnnotationType().toString())) {
+                  return annotation;
+              }
+          }
+      }
+      return null;
+  }
+  
+  // 获得值
+  private List<Object> getValues(String propertyKey, AnnotationMirror annotation) {
+      ValueExtractor extractor = this.valueExtractors.get(propertyKey);
+      if (extractor == null) {
+          return Collections.emptyList();
+      }
+      return extractor.getValues(annotation);
+  }
+  
+  // 拼接值
+  private String toCommaDelimitedString(List<Object> list) {
+      StringBuilder result = new StringBuilder();
+      for (Object item : list) {
+          result.append((result.length() != 0) ? "," : "");
+          result.append(item);
+      }
+      return result.toString();
+  }
+  ```
+
+  - 胖友简单瞅两眼即可，不是很重要哈~
+
+- `<2>` 处，调用 `#writeProperties()` 方法，处理完成，写到文件 `PROPERTIES_PATH` 中。代码如下：
+
+  ```
+  // AutoConfigureAnnotationProcessor.java
+  
+  protected static final String PROPERTIES_PATH = "META-INF/" + "spring-autoconfigure-metadata.properties";
+  
+  private void writeProperties() throws IOException {
+      if (!this.properties.isEmpty()) {
+          // 创建 FileObject 对象
+          FileObject file = this.processingEnv.getFiler().createResource(StandardLocation.CLASS_OUTPUT, "", PROPERTIES_PATH);
+          // 写入 properties 到文件
+          try (OutputStream outputStream = file.openOutputStream()) {
+              this.properties.store(outputStream, null);
+          }
+      }
+  }
+  ```
+
+  - 这不，和 [「2. AutoConfigurationMetadataLoader」](https://svip.iocoder.cn/Spring-Boot/AutoConfigurationMetadataLoader/#) 就对上列。
+
+# 666. 彩蛋
+
+😈 简单小文一篇~在 `spring-boot-autoconfigure-processor` 的寻找上，花了一些些时间。HOHO ~
\ No newline at end of file
diff --git a/springboot/file-create.py b/springboot/file-create.py
new file mode 100644
index 0000000..a412975
--- /dev/null
+++ b/springboot/file-create.py
@@ -0,0 +1,27 @@
+import os
+import pyperclip
+
+# 获取当前脚本的路径
+script_dir = os.path.dirname(os.path.abspath(__file__))
+
+# 从剪贴板获取文件名列表，假设每行一个文件名
+file_names = pyperclip.paste().strip().split('\n')
+
+# 遍历文件名列表，为每个文件名添加排序前缀并创建文件
+for index, file_name in enumerate(file_names, start=1):
+    # 去除文件名两端的空白字符
+    file_name = file_name.strip()
+    
+    # 添加排序前缀和.md后缀
+    file_name_with_prefix = f"{index:02d}-{file_name}.md"  # 这里使用3位数的排序前缀，可以根据需要调整
+    
+    # 构建文件的完整路径
+    file_path = os.path.join(script_dir, file_name_with_prefix)
+    
+    # 创建文件
+    with open(file_path, 'w') as file:
+        # 如果需要写入初始内容，可以在这里添加
+        # 例如：file.write("This is the content of the file.")
+        pass  # 如果不需要写入内容，则使用pass
+
+print(f"Files created successfully in {script_dir}")
\ No newline at end of file
diff --git a/springboot/tmp.txt b/springboot/tmp.txt
new file mode 100644
index 0000000..f110aa1
--- /dev/null
+++ b/springboot/tmp.txt
@@ -0,0 +1,19 @@
+Spring Boot 面试题
+Spring Boot 学习指南
+Spring Boot 源码分析-调试环境搭建（Spring Boot 2.2.0 版本）
+Spring Boot 源码分析-调试环境搭建（Spring Boot 2.6.0 版本）
+Spring Boot 源码分析-项目结构一览
+Spring Boot 源码解析-Jar 启动实现
+Spring Boot 源码分析-SpringApplication
+Spring Boot 源码分析-自动配置
+Spring Boot 源码分析-Condition
+Spring Boot 源码分析-ServletWebServerApplicationContext
+Spring Boot 源码分析-ReactiveWebServerApplicationContext
+Spring Boot 源码分析-ApplicationContextInitializer
+Spring Boot 源码分析-ApplicationListener
+Spring Boot 源码分析-配置加载
+Spring Boot 源码分析-日志系统
+Spring Boot 源码分析-ConfigurationProperties
+Spring Boot 源码分析-BeanDefinitionLoader
+Spring Boot 源码分析-SpringFactoriesLoader
+Spring Boot 源码分析-AutoConfigurationMetadataLoader
\ No newline at end of file
diff --git a/springmvc/01-Spring MVC 面试题.assets/01.png b/springmvc/01-Spring MVC 面试题.assets/01.png
new file mode 100644
index 0000000..243b463
Binary files /dev/null and b/springmvc/01-Spring MVC 面试题.assets/01.png differ
diff --git a/springmvc/01-Spring MVC 面试题.assets/02.png b/springmvc/01-Spring MVC 面试题.assets/02.png
new file mode 100644
index 0000000..aa2f2a0
Binary files /dev/null and b/springmvc/01-Spring MVC 面试题.assets/02.png differ
diff --git a/springmvc/01-Spring MVC 面试题.assets/03.png b/springmvc/01-Spring MVC 面试题.assets/03.png
new file mode 100644
index 0000000..a21321b
Binary files /dev/null and b/springmvc/01-Spring MVC 面试题.assets/03.png differ
diff --git a/springmvc/01-Spring MVC 面试题.assets/15300766829012.jpg b/springmvc/01-Spring MVC 面试题.assets/15300766829012.jpg
new file mode 100644
index 0000000..2b8d146
Binary files /dev/null and b/springmvc/01-Spring MVC 面试题.assets/15300766829012.jpg differ
diff --git a/springmvc/01-Spring MVC 面试题.md b/springmvc/01-Spring MVC 面试题.md
new file mode 100644
index 0000000..30f3596
--- /dev/null
+++ b/springmvc/01-Spring MVC 面试题.md	
@@ -0,0 +1,486 @@
+# 精尽 Spring MVC 面试题「最新更新时间：2024-02」
+
+以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。
+
+如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的 Spring MVC 面试题的大保健。
+
+而题目的难度，艿艿尽量按照从容易到困难的顺序，逐步下去。
+
+当然，艿艿还是非常推荐胖友去撸一撸 Spring MVC 的源码，特别是如下两篇：
+
+- [《精尽 Spring MVC 源码分析 —— 组件一览》](http://svip.iocoder.cn/Spring-MVC/Components-intro/)
+- [《精尽 Spring MVC 源码分析 —— 请求处理一览》](http://svip.iocoder.cn/Spring-MVC/DispatcherServlet-process-request-intro/)
+
+考虑到 Spring MVC 和 Rest 关系比较大，所以本文一共分成两大块：
+
+- Spring MVC
+- REST
+
+# Spring MVC
+
+## Spring MVC 框架有什么用？
+
+Spring Web MVC 框架提供”模型-视图-控制器”( Model-View-Controller )架构和随时可用的组件，用于开发灵活且松散耦合的 Web 应用程序。
+
+MVC 模式有助于分离应用程序的不同方面，如输入逻辑，业务逻辑和 UI 逻辑，同时在所有这些元素之间提供松散耦合。
+
+## 介绍下 Spring MVC 的核心组件？
+
+Spring MVC 一共有九大核心组件，分别是：
+
+- MultipartResolver
+- LocaleResolver
+- ThemeResolver
+- HandlerMapping
+- HandlerAdapter
+- HandlerExceptionResolver
+- RequestToViewNameTranslator
+- ViewResolver
+- FlashMapManager
+
+虽然很多，但是在前后端分离的架构中，在 [「描述一下 DispatcherServlet 的工作流程？」](https://svip.iocoder.cn/Spring-MVC/Interview/#) 问题中，我们会明白，最关键的只有 HandlerMapping + HandlerAdapter + HandlerExceptionResolver 。
+
+关于每个组件的说明，直接看 [《精尽 Spring MVC 源码分析 —— 组件一览》](http://svip.iocoder.cn/Spring-MVC/Components-intro/) 。
+
+## 描述一下 DispatcherServlet 的工作流程？
+
+DispatcherServlet 的工作流程可以用一幅图来说明：
+
+[![DispatcherServlet 的工作流程](01-Spring MVC 面试题.assets/15300766829012.jpg)](https://blog-pictures.oss-cn-shanghai.aliyuncs.com/15300766829012.jpg)DispatcherServlet 的工作流程
+
+① **发送请求**
+
+用户向服务器发送 HTTP 请求，请求被 Spring MVC 的调度控制器 DispatcherServlet 捕获。
+
+② **映射处理器**
+
+DispatcherServlet 根据请求 URL ，调用 HandlerMapping 获得该 Handler 配置的所有相关的对象（包括 **Handler** 对象以及 Handler 对象对应的**拦截器**），最后以 HandlerExecutionChain 对象的形式返回。
+
+- 即 HandlerExecutionChain 中，包含对应的 **Handler** 对象和**拦截器**们。
+
+> 此处，对应的方法如下：
+>
+> ```
+> > // HandlerMapping.java
+> > 
+> > @Nullable
+> > HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception;
+> >
+> ```
+
+③ **处理器适配**
+
+DispatcherServlet 根据获得的 Handler，选择一个合适的HandlerAdapter 。（附注：如果成功获得 HandlerAdapter 后，此时将开始执行拦截器的 `#preHandler(...)` 方法）。
+
+提取请求 Request 中的模型数据，填充 Handler 入参，开始执行Handler（Controller)。 在填充Handler的入参过程中，根据你的配置，Spring 将帮你做一些额外的工作：
+
+- HttpMessageConverter ：会将请求消息（如 JSON、XML 等数据）转换成一个对象。
+- 数据转换：对请求消息进行数据转换。如 String 转换成 Integer、Double 等。
+- 数据格式化：对请求消息进行数据格式化。如将字符串转换成格式化数字或格式化日期等。
+- 数据验证： 验证数据的有效性（长度、格式等），验证结果存储到 BindingResult 或 Error 中。
+
+Handler(Controller) 执行完成后，向 DispatcherServlet 返回一个 ModelAndView 对象。
+
+> 此处，对应的方法如下：
+>
+> ```
+> > // HandlerAdapter.java
+> > 
+> > @Nullable
+> > ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception;
+> >
+> ```
+
+.
+
+> 图中没有 ④ 。
+
+⑤ **解析视图**
+
+根据返回的 ModelAndView ，选择一个适合的 ViewResolver（必须是已经注册到 Spring 容器中的 ViewResolver)，解析出 View 对象，然后返回给 DispatcherServlet。
+
+> 此处，对应的方法如下：
+>
+> ```
+> > // ViewResolver.java
+> > 
+> > @Nullable
+> > View resolveViewName(String viewName, Locale locale) throws Exception;
+> >
+> ```
+
+⑥ ⑦ **渲染视图** + **响应请求**
+
+ViewResolver 结合 Model 和 View，来渲染视图，并写回给用户( 浏览器 )。
+
+> 此处，对应的方法如下：
+>
+> ```
+> > // View.java
+> > 
+> > void render(@Nullable Map<String, ?> model, HttpServletRequest request, HttpServletResponse response) throws Exception;
+> >
+> ```
+
+------
+
+这样一看，胖友可能有点懵逼，所以还是推荐看看：
+
+- [《精尽 Spring MVC 源码分析 —— 组件一览》](http://svip.iocoder.cn/Spring-MVC/Components-intro/)
+- [《精尽 Spring MVC 源码分析 —— 请求处理一览》](http://svip.iocoder.cn/Spring-MVC/DispatcherServlet-process-request-intro/)
+
+**但是 Spring MVC 的流程真的一定是酱紫么**？
+
+既然这么问，答案当然不是。对于目前主流的架构，前后端已经进行分离了，所以 Spring MVC 只负责 **M**odel 和 **C**ontroller 两块，而将 **V**iew 移交给了前端。所以，在上图中的步骤 ⑤ 和 ⑥ 两步，已经不在需要。
+
+那么变成什么样了呢？在步骤 ③ 中，如果 Handler(Controller) 执行完后，如果判断方法有 `@ResponseBody` 注解，则直接将结果写回给用户( 浏览器 )。
+
+但是 HTTP 是不支持返回 Java POJO 对象的，所以需要将结果使用 [HttpMessageConverter](http://svip.iocoder.cn/Spring-MVC/HandlerAdapter-5-HttpMessageConverter/) 进行转换后，才能返回。例如说，大家所熟悉的 [FastJsonHttpMessageConverter](https://github.com/alibaba/fastjson/wiki/在-Spring-中集成-Fastjson) ，将 POJO 转换成 JSON 字符串返回。
+
+😈 是不是略微有点复杂，还是那句话，撸下源码，捅破这个窗口。当然，如果胖友精力有限，只要看整体流程的几篇即可。
+
+------
+
+嘻嘻，再来补充两个图，这真的是 Spring MVC 非常关键的问题，所以要用心理解。
+
+> FROM [《SpringMVC - 运行流程图及原理分析》](https://blog.csdn.net/J080624/article/details/77990164)
+>
+> **流程示意图**：
+>
+> [![流程示意图](01-Spring MVC 面试题.assets/01.png)](http://static.iocoder.cn/images/Spring/2022-02-21/01.png)流程示意图
+>
+> **代码序列图**：
+>
+> [![代码序列图](01-Spring MVC 面试题.assets/02.png)](http://static.iocoder.cn/images/Spring/2022-02-21/02.png)代码序列图
+>
+> ------
+>
+> FROM [《看透 Spring MVC：源代码分析与实践》](https://item.jd.com/11807414.html) P123
+>
+> **流程示意图**：
+>
+> [![《流程示意图》](01-Spring MVC 面试题.assets/03.png)](http://static.iocoder.cn/images/Spring/2022-02-21/03.png)《流程示意图》
+
+## @Controller 注解有什么用？
+
+`@Controller` 注解，它将一个类标记为 Spring Web MVC **控制器** Controller 。
+
+## @RestController 和 @Controller 有什么区别？
+
+`@RestController` 注解，在 `@Controller` 基础上，增加了 `@ResponseBody` 注解，更加适合目前前后端分离的架构下，提供 Restful API ，返回例如 JSON 数据格式。当然，返回什么样的数据格式，根据客户端的 `"ACCEPT"` 请求头来决定。
+
+## @RequestMapping 注解有什么用？
+
+`@RequestMapping` 注解，用于将特定 HTTP 请求方法映射到将处理相应请求的控制器中的特定类/方法。此注释可应用于两个级别：
+
+- 类级别：映射请求的 URL。
+- 方法级别：映射 URL 以及 HTTP 请求方法。
+
+## @RequestMapping 和 @GetMapping 注解的不同之处在哪里？
+
+- `@RequestMapping` 可注解在类和方法上；`@GetMapping` 仅可注册在方法上。
+- `@RequestMapping` 可进行 GET、POST、PUT、DELETE 等请求方法；`@GetMapping` 是 `@RequestMapping` 的 GET 请求方法的特例，目的是为了提高清晰度。
+
+## 返回 JSON 格式使用什么注解？
+
+可以使用 **`@ResponseBody`** 注解，或者使用包含 `@ResponseBody` 注解的 **`@RestController`** 注解。
+
+当然，还是需要配合相应的支持 JSON 格式化的 HttpMessageConverter 实现类。例如，Spring MVC 默认使用 MappingJackson2HttpMessageConverter 。
+
+## 介绍一下 WebApplicationContext ？
+
+WebApplicationContext 是实现ApplicationContext接口的子类，专门为 WEB 应用准备的。
+
+- 它允许从相对于 Web 根目录的路径中**加载配置文件**，**完成初始化 Spring MVC 组件的工作**。
+- 从 WebApplicationContext 中，可以获取 ServletContext 引用，整个 Web 应用上下文对象将作为属性放置在 ServletContext 中，以便 Web 应用环境可以访问 Spring 上下文。
+
+关于这一块，如果想要详细了解，可以看看如下两篇文章：
+
+- [《精尽 Spring MVC 源码分析 —— 容器的初始化（一）之 Root WebApplicationContext 容器》](http://svip.iocoder.cn/Spring-MVC/context-init-Root-WebApplicationContext/)
+- [《精尽 Spring MVC 源码分析 —— 容器的初始化（二）之 Servlet WebApplicationContext 容器》](http://svip.iocoder.cn/Spring-MVC/context-init-Servlet-WebApplicationContext/)
+
+## Spring MVC 的异常处理？
+
+Spring MVC 提供了异常解析器 HandlerExceptionResolver 接口，将处理器( `handler` )执行时发生的异常，解析( 转换 )成对应的 ModelAndView 结果。代码如下：
+
+```
+// HandlerExceptionResolver.java
+
+public interface HandlerExceptionResolver {
+
+    /**
+     * 解析异常，转换成对应的 ModelAndView 结果
+     */
+    @Nullable
+    ModelAndView resolveException(
+            HttpServletRequest request, HttpServletResponse response, @Nullable Object handler, Exception ex);
+
+}
+```
+
+- 也就是说，如果异常被解析成功，则会返回 ModelAndView 对象。
+- 详细的源码解析，见 [《精尽 Spring MVC 源码解析 —— HandlerExceptionResolver 组件》](http://svip.iocoder.cn/Spring-MVC/HandlerExceptionResolver/) 。
+
+一般情况下，我们使用 `@ExceptionHandler` 注解来实现过异常的处理，可以先看看 [《Spring 异常处理 ExceptionHandler 的使用》](https://www.jianshu.com/p/12e1a752974d) 。
+
+- 一般情况下，艿艿喜欢使用**第三种**。
+
+## Spring MVC 有什么优点？
+
+1. 使用真的真的真的非常**方便**，无论是添加 HTTP 请求方法映射的方法，还是不同数据格式的响应。
+2. 提供**拦截器机制**，可以方便的对请求进行拦截处理。
+3. 提供**异常机制**，可以方便的对异常做统一处理。
+4. 可以任意使用各种**视图**技术，而不仅仅局限于 JSP ，例如 Freemarker、Thymeleaf 等等。
+5. 不依赖于 Servlet API (目标虽是如此，但是在实现的时候确实是依赖于 Servlet 的，当然仅仅依赖 Servlet ，而不依赖 Filter、Listener )。
+
+## Spring MVC 怎样设定重定向和转发 ？
+
+- 结果转发：在返回值的前面加 `"forward:/"` 。
+- 重定向：在返回值的前面加上 `"redirect:/"` 。
+
+当然，目前前后端分离之后，我们作为后端开发，已经很少有机会用上这个功能了。
+
+## Spring MVC 的 Controller 是不是单例？
+
+绝绝绝大多数情况下，Controller 是**单例**。
+
+那么，Controller 里一般不建议存在**共享的变量**。实际场景下，艿艿也没碰到需要使用共享变量的情况。
+
+## Spring MVC 和 Struts2 的异同？
+
+1. 入口
+
+   不同
+
+   - Spring MVC 的入门是一个 Servlet **控制器**。
+   - Struts2 入门是一个 Filter **过滤器**。
+
+2. 配置映射
+
+   不同，
+
+   - Spring MVC 是基于**方法**开发，传递参数是通过**方法形参**，一般设置为**单例**。
+   - Struts2 是基于**类**开发，传递参数是通过**类的属性**，只能设计为**多例**。
+
+- 视图
+
+  不同
+
+  - Spring MVC 通过参数解析器是将 Request 对象内容进行解析成方法形参，将响应数据和页面封装成 **ModelAndView** 对象，最后又将模型数据通过 **Request** 对象传输到页面。其中，如果视图使用 JSP 时，默认使用 **JSTL** 。
+  - Struts2 采用**值栈**存储请求和响应的数据，通过 **OGNL** 存取数据。
+
+当然，更详细的也可以看看 [《面试题：Spring MVC 和 Struts2 的区别》](http://www.voidcn.com/article/p-ylualwcj-c.html) 一文。
+
+## 详细介绍下 Spring MVC 拦截器？
+
+`org.springframework.web.servlet.HandlerInterceptor` ，拦截器接口。代码如下：
+
+```
+// HandlerInterceptor.java
+
+/**
+ * 拦截处理器，在 {@link HandlerAdapter#handle(HttpServletRequest, HttpServletResponse, Object)} 执行之前
+ */
+default boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)
+		throws Exception {
+	return true;
+}
+
+/**
+ * 拦截处理器，在 {@link HandlerAdapter#handle(HttpServletRequest, HttpServletResponse, Object)} 执行成功之后
+ */
+default void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler,
+		@Nullable ModelAndView modelAndView) throws Exception {
+}
+
+/**
+ * 拦截处理器，在 {@link HandlerAdapter#handle(HttpServletRequest, HttpServletResponse, Object)} 执行完之后，无论成功还是失败
+ *
+ * 并且，只有该处理器 {@link #preHandle(HttpServletRequest, HttpServletResponse, Object)} 执行成功之后，才会被执行
+ */
+default void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler,
+		@Nullable Exception ex) throws Exception {
+}
+```
+
+- 一共有三个方法，分别为：
+
+  - `#preHandle(...)` 方法，调用 Controller 方法之**前**执行。
+
+  - `#postHandle(...)` 方法，调用 Controller 方法之**后**执行。
+
+  - ```
+    #afterCompletion(...)
+    ```
+
+     
+
+    方法，处理完 Controller 方法返回结果之
+
+    后
+
+    执行。
+
+    - 例如，页面渲染后。
+    - **当然，要注意，无论调用 Controller 方法是否成功，都会执行**。
+
+- 举个例子：
+
+  - 当俩个拦截器都实现放行操作时，执行顺序为 `preHandle[1] => preHandle[2] => postHandle[2] => postHandle[1] => afterCompletion[2] => afterCompletion[1]` 。
+  - 当第一个拦截器 `#preHandle(...)` 方法返回 `false` ，也就是对其进行拦截时，第二个拦截器是完全不执行的，第一个拦截器只执行 `#preHandle(...)` 部分。
+  - 当第一个拦截器 `#preHandle(...)` 方法返回 `true` ，第二个拦截器 `#preHandle(...)` 返回 `false` ，执行顺序为 `preHandle[1] => preHandle[2] => afterCompletion[1]` 。
+
+- 总结来说：
+
+  - `#preHandle(...)` 方法，按拦截器定义**顺序**调用。若任一拦截器返回 `false` ，则 Controller 方法不再调用。
+  - `#postHandle(...)` 和 `#afterCompletion(...)` 方法，按拦截器定义**逆序**调用。
+  - `#postHandler(...)` 方法，在调用 Controller 方法之**后**执行。
+  - `#afterCompletion(...)` 方法，只有该拦截器在 `#preHandle(...)` 方法返回 `true` 时，才能够被调用，且一定会被调用。为什么“且一定会被调用”呢？即使 `#afterCompletion(...)` 方法，按拦截器定义**逆序**调用时，前面的拦截器发生异常，后面的拦截器还能够调用，**即无视异常**。
+
+------
+
+关于这块，可以看看如下两篇文章：
+
+- [《Spring MVC 多个拦截器执行顺序及拦截器使用方法》](https://blog.csdn.net/amaxiaochen/article/details/77210880) 文章，通过**实践**更加理解。
+- [《精尽 Spring MVC 源码分析 —— HandlerMapping 组件（二）之 HandlerInterceptor》](http://svip.iocoder.cn/Spring-MVC/HandlerMapping-2-HandlerInterceptor/) 文章，通过**源码**更加理解。
+
+## Spring MVC 的拦截器可以做哪些事情？
+
+拦截器能做的事情非常非常非常多，例如：
+
+- 记录访问日志。
+- 记录异常日志。
+- 需要登陆的请求操作，拦截未登陆的用户。
+- …
+
+## Spring MVC 的拦截器和 Filter 过滤器有什么差别？
+
+看了文章 [《过滤器( Filter )和拦截器( Interceptor )的区别》](https://blog.csdn.net/xiaodanjava/article/details/32125687) ，感觉对比的怪怪的。艿艿觉得主要几个点吧：
+
+- **功能相同**：拦截器和 Filter都能实现相应的功能，谁也不比谁强。
+- **容器不同**：拦截器构建在 Spring MVC 体系中；Filter 构建在 Servlet 容器之上。
+- **使用便利性不同**：拦截器提供了三个方法，分别在不同的时机执行；过滤器仅提供一个方法，当然也能实现拦截器的执行时机的效果，就是麻烦一些。
+
+另外，😈 再补充一点小知识。我们会发现，拓展性好的框架，都会提供相应的拦截器或过滤器机制，方便的我们做一些拓展。例如：
+
+- Dubbo 的 Filter 机制。
+- Spring Cloud Gateway 的 Filter 机制。
+- Struts2 的拦截器机制。
+
+# REST
+
+本小节的内容，基本是基于 [《排名前 20 的 REST 和 Spring MVC 面试题》](http://www.spring4all.com/article/1445) 之上，做增补。
+
+## REST 代表着什么?
+
+REST 代表着抽象状态转移，它是根据 HTTP 协议从客户端发送数据到服务端，例如：服务端的一本书可以以 XML 或 JSON 格式传递到客户端。
+
+然而，假如你不熟悉REST，我建议你先看看 [REST API design and development](http://bit.ly/2zIGzWK) 这篇文章来更好的了解它。不过对于大多数胖友的英语，可能不太好，所以也可以阅读知乎上的 [《怎样用通俗的语言解释 REST，以及 RESTful？》](https://www.zhihu.com/question/28557115) 讨论。
+
+## 资源是什么?
+
+资源是指数据在 REST 架构中如何显示的。将实体作为资源公开 ，它允许客户端通过 HTTP 方法如：[GET](http://javarevisited.blogspot.sg/2012/03/get-post-method-in-http-and-https.html), [POST](http://www.java67.com/2014/08/difference-between-post-and-get-request.html),[PUT](http://www.java67.com/2016/09/when-to-use-put-or-post-in-restful-web-services.html), DELETE 等读，写，修改和创建资源。
+
+## 什么是安全的 REST 操作?
+
+REST 接口是通过 HTTP 方法完成操作。
+
+- 一些HTTP操作是安全的，如 GET 和 HEAD ，它不能在服务端修改资源
+- 换句话说，PUT,POST 和 DELETE 是不安全的，因为他们能修改服务端的资源。
+
+所以，是否安全的界限，在于**是否修改**服务端的资源。
+
+## 什么是幂等操作? 为什么幂等操作如此重要?
+
+有一些HTTP方法，如：GET，不管你使用多少次它都能产生相同的结果，在没有任何一边影响的情况下，发送多个 GET 请求到相同的[URI](http://www.java67.com/2013/01/difference-between-url-uri-and-urn.html) 将会产生相同的响应结果。因此，这就是所谓**幂等**操作。
+
+换句话说，[POST方法不是幂等操作](http://javarevisited.blogspot.sg/2016/05/what-are-idempotent-and-safe-methods-of-HTTP-and-REST.html) ，因为如果发送多个 POST 请求，它将在服务端创建不同的资源。但是，假如你用PUT更新资源，它将是幂等操作。
+
+甚至多个 PUT 请求被用来更新服务端资源，将得到相同的结果。你可以通过 Pluralsight 学习 [HTTP Fundamentals](http://pluralsight.pxf.io/c/1193463/424552/7490?u=https%3A%2F%2Fwww.pluralsight.com%2Fcourses%2Fxhttp-fund) 课程来了解 HTTP 协议和一般的 HTTP 的更多幂等操作。
+
+## REST 是可扩展的或说是协同的吗?
+
+是的，[REST](http://javarevisited.blogspot.sg/2015/08/difference-between-soap-and-restfull-webservice-java.html) 是可扩展的和可协作的。它既不托管一种特定的技术选择，也不定在客户端或者服务端。你可以用 [Java](http://javarevisited.blogspot.sg/2017/11/top-5-free-java-courses-for-beginners.html), [C++](http://www.java67.com/2018/02/5-free-cpp-courses-to-learn-programming.html), [Python](http://www.java67.com/2018/02/5-free-python-online-courses-for-beginners.html), 或 [JavaScript](http://www.java67.com/2018/04/top-5-free-javascript-courses-to-learn.html) 来创建 RESTful Web 服务，也可以在客户端使用它们。
+
+我建议你读一本关于REST接口的书来了解更多，如：[RESTful Web Services](http://javarevisited.blogspot.sg/2017/02/top-5-books-to-learn-rest-and-restful-web-services-in-java.html) 。
+
+> 艿艿：所以这里的“可拓展”、“协同”对应到我们平时常说的，“跨语言”、“语言无关”。
+
+## REST 用哪种 HTTP 方法呢?
+
+REST 能用任何的 HTTP 方法，但是，最受欢迎的是：
+
+- 用 GET 来检索服务端资源
+- 用 POST 来创建服务端资源
+- [用 PUT 来更新服务端资源](http://javarevisited.blogspot.sg/2016/04/what-is-purpose-of-http-request-types-in-RESTful-web-service.html#axzz56WGunSwy)
+- 用 DELETE 来删除服务端资源。
+
+恰好，这四个操作，对上我们日常逻辑的 CRUD 操作。
+
+> 艿艿：经常能听到胖友抱怨自己做的都是 CRUD 的功能。看了这个面试题，有没觉得原来 CRUD 也能玩的稍微高级一点？！
+>
+> 实际上，每个 CRUD 也是可以通过不断的打磨，玩的很高级。例如说 DDD 领域驱动，完整的单元测试，可扩展的设计。
+
+## 删除的 HTTP 状态返回码是什么 ?
+
+在删除成功之后，您的 REST API 应该返回什么状态代码，并没有严格的规则。它可以返回 200 或 204 没有内容。
+
+- 一般来说，如果删除操作成功，响应主体为空，返回 [204](http://www.netingcn.com/http-status-204.html) 。
+- 如果删除请求成功且响应体不是空的，则返回 200 。
+
+## REST API 是无状态的吗?
+
+**是的**，REST API 应该是无状态的，因为它是基于 HTTP 的，它也是无状态的。
+
+REST API 中的请求应该包含处理它所需的所有细节。它**不应该**依赖于以前或下一个请求或服务器端维护的一些数据，例如会话。
+
+**REST 规范为使其无状态设置了一个约束，在设计 REST API 时，您应该记住这一点**。
+
+## REST安全吗? 你能做什么来保护它?
+
+安全是一个宽泛的术语。它可能意味着消息的安全性，这是通过认证和授权提供的加密或访问限制提供的。
+
+REST 通常不是安全的，但是您可以通过使用 Spring Security 来保护它。
+
+- 至少，你可以通过在 Spring Security 配置文件中使用 HTTP 来启用 HTTP Basic Auth 基本认证。
+- 类似地，如果底层服务器支持 HTTPS ，你可以使用 HTTPS 公开 REST API 。
+
+## RestTemplate 的优势是什么?
+
+在 Spring Framework 中，RestTemplate 类是 [模板方法模式](http://www.java67.com/2012/09/top-10-java-design-pattern-interview-question-answer.html) 的实现。跟其他主流的模板类相似，如 JdbcTemplate 或 JmsTempalte ，它将在客户端简化跟 RESTful Web 服务的集成。正如在 RestTemplate 例子中显示的一样，你能非常容易地用它来调用 RESTful Web 服务。
+
+> 艿艿：当然，实际场景我还是更喜欢使用 [OkHttp](http://square.github.io/okhttp/) 作为 HTTP 库，因为更好的性能，使用也便捷，并且无需依赖 Spring 库。
+
+## HttpMessageConverter 在 Spring REST 中代表什么?
+
+HttpMessageConverter 是一种[策略接口](http://www.java67.com/2014/12/strategy-pattern-in-java-with-example.html) ，它指定了一个转换器，它可以转换 HTTP 请求和响应。Spring REST 用这个接口转换 HTTP 响应到多种格式，例如：JSON 或 XML 。
+
+每个 HttpMessageConverter 实现都有一种或几种相关联的MIME协议。Spring 使用 `"Accept"` 的标头来确定客户端所期待的内容类型。
+
+然后，它将尝试找到一个注册的 HTTPMessageConverter ，它能够处理特定的内容类型，并使用它将响应转换成这种格式，然后再将其发送给客户端。
+
+如果胖友对 HttpMessageConverter 不了解，可以看看 [《Spring 中 HttpMessageConverter 详解》](https://leokongwq.github.io/2017/06/14/spring-MessageConverter.html) 。
+
+## 如何创建 HttpMessageConverter 的自定义实现来支持一种新的请求/响应？
+
+我们仅需要创建自定义的 AbstractHttpMessageConverter 的实现，并使用 WebMvcConfigurerAdapter 的 `#extendMessageConverters(List<HttpMessageConverter<?>> converters)` 方法注中册它，该方法可以生成一种新的请求 / 响应类型。
+
+具体的示例，可以学习 [《在 Spring 中集成 Fastjson》](https://github.com/alibaba/fastjson/wiki/在-Spring-中集成-Fastjson) 文章。
+
+## @PathVariable 注解，在 Spring MVC 做了什么? 为什么 REST 在 Spring 中如此有用？
+
+`@PathVariable` 注解，是 Spring MVC 中有用的注解之一，它允许您从 URI 读取值，比如查询参数。它在使用 Spring 创建 RESTful Web 服务时特别有用，因为在 REST 中，资源标识符是 URI 的一部分。
+
+具体的使用示例，胖友如果不熟悉，可以看看 [《Spring MVC 的 @RequestParam 注解和 @PathVariable 注解的区别》](https://blog.csdn.net/cx361006796/article/details/52829759) 。
+
+# 666. 彩蛋
+
+文末的文末，艿艿还是那句话！！！！还是非常推荐胖友去撸一撸 Spring MVC 的源码，特别是如下两篇：
+
+- [《精尽 Spring MVC 源码分析 —— 组件一览》](http://svip.iocoder.cn/Spring-MVC/Components-intro/)
+- [《精尽 Spring MVC 源码分析 —— 请求处理一览》](http://svip.iocoder.cn/Spring-MVC/DispatcherServlet-process-request-intro/)
+
+参考和推荐如下文章：
+
+- [《排名前 20 的 REST 和 Spring MVC 面试题》](http://www.spring4all.com/article/1445)
+- [《跟着 Github 学习 Restful HTTP API 的优雅设计》](http://www.iocoder.cn/Fight/Learn-Restful-HTTP-API-design-from-Github/)
\ No newline at end of file
diff --git a/springmvc/02-Spring MVC 学习指南.md b/springmvc/02-Spring MVC 学习指南.md
new file mode 100644
index 0000000..5d2fa14
--- /dev/null
+++ b/springmvc/02-Spring MVC 学习指南.md	
@@ -0,0 +1,45 @@
+# 精尽 Spring MVC 学习指南
+
+# 1. 视频
+
+- [《Spring MVC 视频教程全集》](https://www.bilibili.com/video/av59567541/?pikaqiu) 一共有 60P 。
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 和《尚硅谷 Spring 视频教程》是同一个讲师。
+
+- [《SSM 整合视频教程全集》](https://www.bilibili.com/video/av59585780/?pikaqiu) 一共有 35P 。
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 和《尚硅谷 Spring 视频教程》是同一个讲师。
+
+- 黑马 [《黑马 spring MVC》](https://www.bilibili.com/video/av20870782) 一共有 44P 。就是声音有点小…
+
+- 廖师兄 [《Spring Boot 进阶之 Web 进阶》](https://www.imooc.com/learn/810) 两小时不到，挺不错的。
+
+- ReasonLee [《Spring MVC 拦截器》](https://www.imooc.com/learn/498) 40 分钟，可以的。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 2. 书籍
+
+[《Spring MVC 书单整理》](http://www.iocoder.cn/Books/Spring-MVC-books-recommended)
+
+- 韩路彪 [《看透 Spring MVC》](https://item.jd.com/11807414.html) 豆瓣评分 7.3 分，主要分享 Spring MVC 的源码
+
+# 3. 文章
+
+- 芋艿 [《芋道 Spring Boot SpringMVC 入门》](http://www.iocoder.cn/Spring-Boot/SpringMVC/?vip) 对应 [lab-23](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-23)
+- [《芋道 Spring Boot WebFlux 入门》](http://www.iocoder.cn/Spring-Boot/WebFlux/?vip) 对应 [lab-27](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-27)
+- [《芋道 Spring Boot API 接口文档 Swagger 入门》](http://www.iocoder.cn/Spring-Boot/Swagger/?vip) 对应 [lab-24](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-24)
+- [《芋道 Spring Boot API 接口文档 Swagger Starter 入门》](http://www.iocoder.cn/Spring-Boot/Swagger-Starter/?vip) 对应 [lab-24](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-24)
+- [《芋道 Spring Boot 分布式 Session 入门》](http://www.iocoder.cn/Spring-Boot/Distributed-Session/?vip) 对应 [lab-26](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-26)
+- 芋艿 [《芋道 Spring Boot 参数校验 Validation 入门》](http://www.iocoder.cn/Spring-Boot/Validation/?vip) 对应 [lab-22](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-22) 。
+- [《芋道 Spring Boot WebSocket 入门》](http://www.iocoder.cn/Spring-Boot/WebSocket/?vip) 对应 [lab-25](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-25)
+- [《芋道 Spring Boot API 接口文档 JApiDocs 入门》](http://www.iocoder.cn/Spring-Boot/JApiDocs/?vip) 对应 [lab-24](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-24)
+- [《芋道 Spring Boot API 接口文档 ShowDoc 入门》](http://www.iocoder.cn/Spring-Boot/ShowDoc/?vip) 对应 [lab-24](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-24)
+- 莫那·鲁道 [《面试问烂的 Spring MVC 过程》](http://www.iocoder.cn/Fight/Interview-poorly-asked-SpringMVC-process)
+- 知乎讨论 [《Spring MVC 的工作原理是什么样的,跟 Spring 的关系是怎么样的？》](https://www.zhihu.com/question/38696452)
+
+如果胖友有看到合适的文章，也可以推荐给我哟。
\ No newline at end of file
diff --git a/springmvc/03-Spring MVC 源码分析-调试环境搭建.assets/01-17199769204571.png b/springmvc/03-Spring MVC 源码分析-调试环境搭建.assets/01-17199769204571.png
new file mode 100644
index 0000000..2e589ed
Binary files /dev/null and b/springmvc/03-Spring MVC 源码分析-调试环境搭建.assets/01-17199769204571.png differ
diff --git a/springmvc/03-Spring MVC 源码分析-调试环境搭建.assets/01.png b/springmvc/03-Spring MVC 源码分析-调试环境搭建.assets/01.png
new file mode 100644
index 0000000..08059f1
Binary files /dev/null and b/springmvc/03-Spring MVC 源码分析-调试环境搭建.assets/01.png differ
diff --git a/springmvc/03-Spring MVC 源码分析-调试环境搭建.assets/02.png b/springmvc/03-Spring MVC 源码分析-调试环境搭建.assets/02.png
new file mode 100644
index 0000000..c1b10a8
Binary files /dev/null and b/springmvc/03-Spring MVC 源码分析-调试环境搭建.assets/02.png differ
diff --git a/springmvc/03-Spring MVC 源码分析-调试环境搭建.md b/springmvc/03-Spring MVC 源码分析-调试环境搭建.md
new file mode 100644
index 0000000..2b974e0
--- /dev/null
+++ b/springmvc/03-Spring MVC 源码分析-调试环境搭建.md	
@@ -0,0 +1,88 @@
+# 精尽 Spring MVC 源码分析 —— 调试环境搭建
+
+> 因为 `spring-mvc` 项目，是 `spring-framework` 的**子项目**，所以编译的方式，和 [《精尽 Spring 源码分析 —— 调试环境搭建》](http://svip.iocoder.cn/Spring/build-debugging-environment) 是一模一样的。
+
+# 1. 依赖工具
+
+- Gradle
+- Git
+- JDK1.8+
+- IntelliJ IDEA
+
+笔者目前使用的系统版本是 macOS Mojave 10.14 。所以，如果胖友是 Windows 环境，胖到一些问题，请在星球给我留言。
+
+另外，本文参考官方提供的文档 [《import-into-idea》](https://github.com/spring-projects/spring-framework/blob/master/import-into-idea.md) 。
+
+补充说明 1 ：IntelliJ IDEA 请使用 2018 版本，之前有胖友反馈搭建不起来，因为 IDEA 版本过低。
+
+# 2. 源码拉取
+
+从官方仓库 https://github.com/spring-projects/spring-framework `Fork` 出属于自己的仓库。
+
+- 为什么要 `Fork` ？既然开始阅读、调试源码，我们可能会写一些注释，有了自己的仓库，可以进行自由的提交。😈
+- 本文使用的 Spring 版本为 `5.1.1.BUILD-SNAPSHOT` 。
+- 使用 `IntelliJ IDEA` 从 `Fork` 出来的仓库拉取代码。因为 Spring 项目比较大，从仓库中拉取代码的时间会比较长。
+
+拉取完成后，Gradle 会开始自动 **Build** 项目。因为 Build 的过程中，会下载非常多的依赖，请耐心等待。
+
+- 😈 不过笔者有点不太确定，Gradle 是否会自动 **Build** 项目，反正我的会。如果此处碰到问题，请给我留言。
+
+# 3. 预编译 `spring-oxm` 项目
+
+打开 IDEA Terminal ，输入如下命令，预编译 `spring-oxm` 项目：
+
+```
+./gradlew :spring-oxm:compileTestJava
+```
+
+当看到 `BUILD SUCCESSFUL` ，说明编译成功。
+
+😈 另外，笔者有点不确定，Gradle 在上面已经自动 **Build** 项目，这个步骤是否还需要。但是笔者不熟悉 Gradle 的机制，官方文档又要求这么做，所以做下也没什么影响。哈哈哈哈。
+
+# 4. 运行示例
+
+在 `spring-webmvc` 项目中的 `src/test/java` 目录下，已经提供了一些单元测试，我们可以使用它来调试相应的逻辑。
+
+后续的文章，艿艿会说明自己所使用的单元测试。
+
+# 5. 可能碰到的问题
+
+## 5.1 报 InstrumentationSavingAgent 不存在的错误
+
+例如说，在运行 `spring-context` 项目中的单元测试时，会报 InstrumentationSavingAgent 存在的错误。此时，我们将 `spring-context.gradle` 修改如下：
+
+[![`spring-context.gradle` 修改图](03-Spring MVC 源码分析-调试环境搭建.assets/01.png)](http://static.iocoder.cn/images/Spring/2019-01-01/01.png)`spring-context.gradle` 修改图
+
+修改完成后，Gradle 又会自动 **Build** 项目，下载相关依赖。完成后，再次运行 `spring-context` 项目中的单元测试，顺利通过。
+
+## 5.2 其它
+
+如果胖友你在搭建调试环境的过程中，如果碰到任何问题，可以在星球给我留言。
+
+# 666. 彩蛋
+
+`spring-framework` 项目下，一共有四个和 web 相关的项目，大体关系如下：
+
+[![关系图](03-Spring MVC 源码分析-调试环境搭建.assets/01-17199769204571.png)](http://static.iocoder.cn/images/Spring/2022-01-01/01.png)关系图
+
+为什么画这个图的原因是，想让胖友知道，`spring-webmvc` 不是一个单独的项目，它有依赖的爸爸 `spring-web` 项目，也有两个兄弟 `spring-webflux` 和 `spring-websocket` 项目。
+
+这个系列，我们仅仅分享 `spring-webmvc` 项目，如果对其它感兴趣的胖友，自己 Google 。还是那句话，不要上来就源码，先学使用方法，了解其特性。
+
+------
+
+艿艿统计了下 `spring-mvc` 项目的代码量，整体的代码量，有点超过我的预期，如下图所示：
+
+[![代码统计](03-Spring MVC 源码分析-调试环境搭建.assets/02.png)](http://static.iocoder.cn/images/Spring/2022-01-01/02.png)代码统计
+
+真他喵的代码量多。当然，这个系列，艿艿不会解析所有的代码，而是挑选其中较为核心的部分。不然，真的是精尽人亡。哈哈哈哈。
+
+------
+
+实际上，市面上已经有两本比较好的，解析 Spring MVC 的书籍，分别是：
+
+- [《看透 Spring MVC：源代码分析与实践》](https://item.jd.com/11807414.html)
+- [《Spring 源码深度解析》](https://item.jd.com/11311737.html) 的 [「第 11 章 Spring MVC」](https://svip.iocoder.cn/Spring-MVC/build-debugging-environment/#) 小节
+- 韩路彪 [《看透 Spring MVC：源代码分析与实践》](https://item.jd.com/11807414.html) 的 [「第9章 创建 Spring MVC 之器」](https://svip.iocoder.cn/Spring-MVC/build-debugging-environment/#) 小节hexo
+
+艿艿自己在写这个系列时，也参考了里面其中非常多的内容。感谢 1024 。
\ No newline at end of file
diff --git a/springmvc/04-Spring MVC 源码分析-容器的初始化（一）之 Root WebApplicationContext 容器.assets/01.png b/springmvc/04-Spring MVC 源码分析-容器的初始化（一）之 Root WebApplicationContext 容器.assets/01.png
new file mode 100644
index 0000000..f463efa
Binary files /dev/null and b/springmvc/04-Spring MVC 源码分析-容器的初始化（一）之 Root WebApplicationContext 容器.assets/01.png differ
diff --git a/springmvc/04-Spring MVC 源码分析-容器的初始化（一）之 Root WebApplicationContext 容器.md b/springmvc/04-Spring MVC 源码分析-容器的初始化（一）之 Root WebApplicationContext 容器.md
new file mode 100644
index 0000000..13c3832
--- /dev/null
+++ b/springmvc/04-Spring MVC 源码分析-容器的初始化（一）之 Root WebApplicationContext 容器.md	
@@ -0,0 +1,519 @@
+# 精尽 Spring MVC 源码分析 —— 容器的初始化（一）之 Root WebApplicationContext 容器
+
+# 1. 概述
+
+随着 Spring Boot 逐步全面覆盖到我们的项目之中，我们已经基本忘却当年经典的 Servlet + Spring MVC 的组合，那让人熟悉的 `web.xml` 配置。而本文，我们想先抛开 Spring Boot 到一旁，回到从前，一起来看看 Servlet 是怎么和 Spring MVC 集成，怎么来初始化 Spring 容器的。
+
+在开始看具体的源码实现之前，我们先一起来看看现在“陌生”的 `web.xml` 配置。代码如下：
+
+```
+<!-- 省略非关键的配置 -->
+
+<!-- [1] Spring配置 -->
+<listener>
+    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
+</listener>
+<!-- 指定Spring Bean的配置文件所在目录。默认配置在WEB-INF目录下 -->
+<context-param>
+    <param-name>contextConfigLocation</param-name>
+    <param-value>classpath:config/applicationContext.xml</param-value>
+</context-param>
+
+<!-- ====================================== -->
+
+<!-- [2] Spring MVC配置 -->
+<servlet>
+    <servlet-name>spring</servlet-name>
+    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
+    <!-- 可以自定义servlet.xml配置文件的位置和名称，默认为WEB-INF目录下，名称为[<servlet-name>]-servlet.xml，如spring-servlet.xml
+    <init-param>
+        <param-name>contextConfigLocation</param-name>
+        <param-value>/WEB-INF/spring-servlet.xml</param-value> // 默认
+    </init-param>
+    -->
+    <load-on-startup>1</load-on-startup>
+</servlet>
+<servlet-mapping>
+    <servlet-name>spring</servlet-name>
+    <url-pattern>*.do</url-pattern>
+</servlet-mapping>
+```
+
+- `[1]` 处，配置了 `org.springframework.web.context.ContextLoaderListener` 对象。这是一个 `javax.servlet.ServletContextListener` 对象，会初始化一个**Root** Spring WebApplicationContext 容器。这个过程，详细解析，见 [「3. Root WebApplicationContext 容器」](https://svip.iocoder.cn/Spring-MVC/context-init-Root-WebApplicationContext/#) 。
+- `[2]` 处，配置了 `org.springframework.web.servlet.DispatcherServlet` 对象。这是一个 `javax.servlet.http.HttpServlet` 对象，它除了拦截我们制定的 `*.do` 请求外，也会初始化一个**属于它**的 Spring WebApplicationContext 容器。并且，这个容器是以 `[1]` 处的 Root 容器作为父容器。这个过程，详细解析，见 [《精尽 Spring MVC 源码分析 —— 容器的初始化（二）之 Servlet WebApplicationContext 容器》](http://svip.iocoder.cn/Spring-MVC/context-init-Servlet-WebApplicationContext) 。
+- 可能胖友会有疑惑，为什么有了 `[2]` 创建了容器，还需要 `[1]` 创建了容器呢？因为可以配置多个 `[2]` 呀。当然，实际场景下，不太会配置多个 `[2]` 。😈
+- 再总结一次，`[1]` 和 `[2]` 分别会创建其对应的 Spring WebApplicationContext 容器，并且它们是父子容器的关系。
+
+因为有些胖友可能没接触过 `web.xml` 配置，详细的可以看看：
+
+- J-Jian [《Spring MVC 的 web.xml 配置详解》](https://blog.csdn.net/mynewclass/article/details/78501604) **更加推荐**
+- yaohong [《Spring MVC 配置文件 web.xml 详解各方总结》](https://www.cnblogs.com/yaohong/p/5905750.html) **更加详细**
+
+------
+
+下面，我们就开始看详细的代码。
+
+# 2. 如何调试
+
+执行 `ContextLoaderTests#testContextLoaderListenerWithDefaultContext()` 单元测试方法，即可执行本文涉及的一些逻辑。
+
+当然，ContextLoaderTests 还提供了其他单元测试方法，胖友可以自己去尝试。
+
+# 3. Root WebApplicationContext 容器
+
+在概述中，我们已经看到，Root WebApplicationContext 容器的初始化，通过 ContextLoaderListener 来实现。在 Servlet 容器启动时，例如 Tomcat、Jetty 启动，则会被 ContextLoaderListener 监听到，从而调用 `#contextInitialized(ServletContextEvent event)` 方法，初始化 Root WebApplicationContext 容器。
+
+而 ContextLoaderListener 的类图如下：[![类图](04-Spring MVC 源码分析-容器的初始化（一）之 Root WebApplicationContext 容器.assets/01.png)](http://static.iocoder.cn/images/Spring/2022-02-01/01.png)类图
+
+## 3.1 ContextLoaderListener
+
+`org.springframework.web.context.ContextLoaderListener` ，实现 ServletContextListener 接口，继承 ContextLoader 类，实现 Servlet 容器启动和关闭时，分别初始化和销毁 WebApplicationContext 容器。
+
+> 注意，这个 ContextLoaderListener 类，是在 `spring-web` 项目中。
+
+### 3.1.1 构造方法
+
+```
+// ContextLoaderListener.java
+
+public ContextLoaderListener() {
+}
+
+public ContextLoaderListener(WebApplicationContext context) {
+	super(context);
+}
+```
+
+这两个构造方法，是因为父类 ContextLoader 有这两个构造方法，所以必须重新定义。比较需要注意的是，第二个构造方法，可以直接传递一个 WebApplicationContext 对象，那样，实际 ContextLoaderListener 就无需在创建一个新的 WebApplicationContext 对象。😈
+
+### 3.1.2 contextInitialized
+
+```
+// ContextLoaderListener.java
+
+@Override
+public void contextInitialized(ServletContextEvent event) {
+    // 初始化 WebApplicationContext
+	initWebApplicationContext(event.getServletContext());
+}
+```
+
+- 调用父类 ContextLoader 的 `#initWebApplicationContext(ServletContext servletContext)` 方法，初始化 WebApplicationContext 对象。详细解析，见 [「3.2 ContextLoader」](https://svip.iocoder.cn/Spring-MVC/context-init-Root-WebApplicationContext/#) 。
+
+### 3.1.3 contextDestroyed
+
+```
+// ContextLoaderListener.java
+
+@Override
+public void contextDestroyed(ServletContextEvent event) {
+	closeWebApplicationContext(event.getServletContext());
+	ContextCleanupListener.cleanupAttributes(event.getServletContext());
+}
+```
+
+- 销毁 WebApplicationContext 容器的逻辑。本文，甚至本系列，都应该暂时不会详细解析。所以，感兴趣的胖友，需要自己研究咯。当然，在这并不着急。
+
+## 3.2 ContextLoader
+
+`org.springframework.web.context.ContextLoader` ，真正实现初始化和销毁 WebApplicationContext 容器的逻辑的类。
+
+> 注意，这个 ContextLoaderListener 类，是在 `spring-web` 项目中。
+
+### 3.2.1 构造方法
+
+因为 ContextLoader 的属性比较多，我们逐块来看。
+
+第一块，`defaultStrategies` **静态**属性，默认的配置 Properties 对象。代码如下：
+
+```
+// ContextLoader.java
+
+/**
+ * Name of the class path resource (relative to the ContextLoader class)
+ * that defines ContextLoader's default strategy names.
+ */
+private static final String DEFAULT_STRATEGIES_PATH = "ContextLoader.properties";
+
+/**
+ * 默认的配置 Properties 对象
+ *
+ * 从 {@link #DEFAULT_STRATEGIES_PATH} 中读取
+ */
+private static final Properties defaultStrategies;
+
+static {
+	// Load default strategy implementations from properties file.
+	// This is currently strictly internal and not meant to be customized
+	// by application developers.
+	try {
+		ClassPathResource resource = new ClassPathResource(DEFAULT_STRATEGIES_PATH, ContextLoader.class);
+		defaultStrategies = PropertiesLoaderUtils.loadProperties(resource);
+	} catch (IOException ex) {
+		throw new IllegalStateException("Could not load 'ContextLoader.properties': " + ex.getMessage());
+	}
+}
+```
+
+- 从 `ContextLoader.properties` 中，读取默认的配置 Properties 对象。实际上，正如 `Load default strategy implementations from properties file. This is currently strictly internal and not meant to be customized by application developers.` 所注释，这是一个应用开发者无需关心的配置，而是 Spring 框架自身所定义的。打开来瞅瞅，代码如下：
+
+  ```
+  // spring-framework/spring-web/src/main/resources/org/springframework/web/context/ContextLoader.properties
+  
+  # Default WebApplicationContext implementation class for ContextLoader.
+  # Used as fallback when no explicit context implementation has been specified as context-param.
+  # Not meant to be customized by application developers.
+  
+  org.springframework.web.context.WebApplicationContext=org.springframework.web.context.support.XmlWebApplicationContext
+  ```
+
+  - 这意味着什么呢？如果我们没有在 `<context-param />` 标签中，配置指定的 WebApplicationContext 类型，就使用 XmlWebApplicationContext 类。😈 一般情况下，我们也不会主动指定。
+
+------
+
+第二块，`context` 属性，**Root** WebApplicationContext 对象。代码如下：
+
+```
+// ContextLoader.java
+
+/**
+ * Root WebApplicationContext 对象
+ *
+ * The root WebApplicationContext instance that this loader manages.
+ */
+@Nullable
+private WebApplicationContext context;
+
+public ContextLoader() {
+}
+
+public ContextLoader(WebApplicationContext context) {
+	this.context = context;
+}
+```
+
+- 在下文中，我们将会看到，如果 `context` 是直接传入，则不会进行初始化，重新创建。😈
+
+------
+
+实际上，ContextLoader 还有其它属性，因为非关键，所以就不赘述。
+
+### 3.2.2 initWebApplicationContext
+
+`#initWebApplicationContext(ServletContext servletContext)` 方法，初始化 WebApplicationContext 对象。代码如下：
+
+```
+// ContextLoader.java
+
+public WebApplicationContext initWebApplicationContext(ServletContext servletContext) {
+    // <1> 若已经存在 ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE 对应的 WebApplicationContext 对象，则抛出 IllegalStateException 异常。
+    // 例如，在 web.xml 中存在多个 ContextLoader 。
+	if (servletContext.getAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE) != null) {
+		throw new IllegalStateException(
+				"Cannot initialize context because there is already a root application context present - " +
+				"check whether you have multiple ContextLoader* definitions in your web.xml!");
+	}
+
+	// <2> 打印日志
+	servletContext.log("Initializing Spring root WebApplicationContext");
+	Log logger = LogFactory.getLog(ContextLoader.class);
+	if (logger.isInfoEnabled()) {
+		logger.info("Root WebApplicationContext: initialization started");
+	}
+
+	// 记录开始时间
+	long startTime = System.currentTimeMillis();
+
+	try {
+		// Store context in local instance variable, to guarantee that
+		// it is available on ServletContext shutdown.
+		if (this.context == null) {
+		    // <3> 初始化 context ，即创建 context 对象
+			this.context = createWebApplicationContext(servletContext);
+		}
+		// <4> 如果是 ConfigurableWebApplicationContext 的子类，如果未刷新，则进行配置和刷新
+		if (this.context instanceof ConfigurableWebApplicationContext) {
+			ConfigurableWebApplicationContext cwac = (ConfigurableWebApplicationContext) this.context;
+			if (!cwac.isActive()) { // <4.1> 未刷新( 激活 )
+				// The context has not yet been refreshed -> provide services such as
+				// setting the parent context, setting the application context id, etc
+				if (cwac.getParent() == null) { // <4.2> 无父容器，则进行加载和设置。
+					// The context instance was injected without an explicit parent ->
+					// determine parent for root web application context, if any.
+					ApplicationContext parent = loadParentContext(servletContext);
+					cwac.setParent(parent);
+				}
+				// <4.3> 配置 context 对象，并进行刷新
+				configureAndRefreshWebApplicationContext(cwac, servletContext);
+			}
+		}
+		// <5> 记录在 servletContext 中
+		servletContext.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE, this.context);
+
+		// <6> 记录到 currentContext 或 currentContextPerThread 中
+		ClassLoader ccl = Thread.currentThread().getContextClassLoader();
+		if (ccl == ContextLoader.class.getClassLoader()) {
+			currentContext = this.context;
+		} else if (ccl != null) {
+			currentContextPerThread.put(ccl, this.context);
+		}
+
+		// <7> 打印日志
+		if (logger.isInfoEnabled()) {
+			long elapsedTime = System.currentTimeMillis() - startTime;
+			logger.info("Root WebApplicationContext initialized in " + elapsedTime + " ms");
+		}
+
+		// <8> 返回 context
+		return this.context;
+	} catch (RuntimeException | Error ex) {
+	    // <9> 当发生异常，记录异常到 WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE 中，不再重新初始化。
+		logger.error("Context initialization failed", ex);
+		servletContext.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE, ex);
+		throw ex;
+	}
+}
+```
+
+- `<1>` 处，若已经存在 `ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE` 对应的 WebApplicationContext 对象，则抛出 IllegalStateException 异常。例如，在 `web.xml` 中存在多个 ContextLoader 。
+
+- `<2>` 处，打印日志。
+
+- `<3>` 处，调用 `#createWebApplicationContext(ServletContext sc)` 方法，初始化 `context` ，即创建 WebApplicationContext 对象。详细解析，胖友先跳到 [「3.2.3 createWebApplicationContext」](https://svip.iocoder.cn/Spring-MVC/context-init-Root-WebApplicationContext/#) 。
+
+- `<4>` 处，如果 `context` 是 ConfigurableWebApplicationContext 的子类，如果未刷新，则进行配置和刷新。
+
+  - `<4.1>` 处，如果未未刷新( 激活 )。默认情况下，是符合这个条件的，所以会往下执行。😈
+
+  - `<4.2>` 处，无父容器，则进行加载和设置。默认情况下，`#loadParentContext(ServletContext servletContext)` 方法，返回 `null` 。代码如下：
+
+    ```
+    // ContextLoader.java
+    
+    @Nullable
+    protected ApplicationContext loadParentContext(ServletContext servletContext) {
+    	return null;
+    }
+    ```
+
+    - 这是一个让子类实现的方法。当然，子类 ContextLoaderListener 并没有重写该方法。所以，实际上，`<4.2>` 处的逻辑，可以暂时忽略。
+
+  - `<4.3>` 处，调用 `#configureAndRefreshWebApplicationContext(ConfigurableWebApplicationContext wac, ServletContext sc)` 方法，配置 ConfigurableWebApplicationContext 对象，并进行刷新。详细解析，胖友先跳到 [「3.2.4 configureAndRefreshWebApplicationContext」](https://svip.iocoder.cn/Spring-MVC/context-init-Root-WebApplicationContext/#) 中。
+
+- `<5>` 处，记录 `context` 在 ServletContext 中。这样，如果 `web.xml` 如果定义了多个 ContextLoader ，就会在 `<1>` 处报错。
+
+- `<6>` 处，记录到 `currentContext` 或 `currentContextPerThread` 中，差异在于类加载器的不同。变量代码如下：
+
+  ```
+  // ContextLoader.java
+  
+  /**
+   * Map from (thread context) ClassLoader to corresponding 'current' WebApplicationContext.
+   */
+  private static final Map<ClassLoader, WebApplicationContext> currentContextPerThread =
+  		new ConcurrentHashMap<>(1);
+      
+  /**
+   * The 'current' WebApplicationContext, if the ContextLoader class is
+   * deployed in the web app ClassLoader itself.
+   */
+  @Nullable
+  private static volatile WebApplicationContext currentContext;
+  ```
+
+  - 目前这两个变量，在销毁 Spring WebApplicationContext 容器时会用到。暂时还看不太出其它的用途。搜索网络上的文章，也没人细说这个。如果知道的胖友，麻烦告知下。
+
+- `<7>` 处，打印日志。
+
+- `<8>` 处，返回 `context` 。
+
+- `<9>` 处，当发生异常，记录异常到 `WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE` 中，不再重新初始化。即对应到 `<1>` 处的逻辑。
+
+### 3.2.3 createWebApplicationContext
+
+`#createWebApplicationContext(ServletContext sc)` 方法，初始化 `context` ，即创建 WebApplicationContext 对象。代码如下：
+
+```
+// ContextLoader.java
+
+protected WebApplicationContext createWebApplicationContext(ServletContext sc) {
+    // <1> 获得 context 的类
+	Class<?> contextClass = determineContextClass(sc);
+	// <2> 判断 context 的类，是否符合 ConfigurableWebApplicationContext 的类型
+	if (!ConfigurableWebApplicationContext.class.isAssignableFrom(contextClass)) {
+		throw new ApplicationContextException("Custom context class [" + contextClass.getName() +
+				"] is not of type [" + ConfigurableWebApplicationContext.class.getName() + "]");
+	}
+	// <3> 创建 context 的类的对象
+	return (ConfigurableWebApplicationContext) BeanUtils.instantiateClass(contextClass);
+}
+```
+
+- `<1>` 处，调用 `#determineContextClass(ServletContext servletContext)` 方法，获得 `context` 的类。代码如下：
+
+  ```
+  // ContextLoader.java
+  
+  /**
+   * Config param for the root WebApplicationContext implementation class to use: {@value}.
+   * @see #determineContextClass(ServletContext)
+   */
+  public static final String CONTEXT_CLASS_PARAM = "contextClass";
+  
+  protected Class<?> determineContextClass(ServletContext servletContext) {
+      // 获得参数 contextClass 的值
+  	String contextClassName = servletContext.getInitParameter(CONTEXT_CLASS_PARAM);
+  	// 情况一，如果值非空，则获得该类
+  	if (contextClassName != null) {
+  		try {
+  			return ClassUtils.forName(contextClassName, ClassUtils.getDefaultClassLoader());
+  		} catch (ClassNotFoundException ex) {
+  			throw new ApplicationContextException(
+  					"Failed to load custom context class [" + contextClassName + "]", ex);
+  		}
+      // 情况二，从 defaultStrategies 获得该类
+  	} else {
+  		contextClassName = defaultStrategies.getProperty(WebApplicationContext.class.getName());
+  		try {
+  			return ClassUtils.forName(contextClassName, ContextLoader.class.getClassLoader());
+  		} catch (ClassNotFoundException ex) {
+  			throw new ApplicationContextException(
+  					"Failed to load default context class [" + contextClassName + "]", ex);
+  		}
+  	}
+  }
+  ```
+
+  - 分成**两种**情况。前者，从 ServletContext 配置的 `context` 类；后者，从 `ContextLoader.properties` 配置的 `context` 类。
+  - 默认情况下，我们不会主动在 ServletContext 配置的 `context` 类，所以基本是使用 `ContextLoader.properties` 配置的 `context` 类，即 **XmlWebApplicationContext** 类。
+
+- `<2>` 处，判断 `context` 的类，是否符合 ConfigurableWebApplicationContext 的类型。显然，XmlWebApplicationContext 是符合条件的，所以不会抛出 ApplicationContextException 异常。
+
+- `<3>` 处，调用 `BeanUtils#instantiateClass(Class<T> clazz)` 方法，创建 `context` 的类的对象。
+
+😈 回到 [「3.2.2 initWebApplicationContext」](https://svip.iocoder.cn/Spring-MVC/context-init-Root-WebApplicationContext/#) ，我们继续撸。
+
+### 3.2.4 configureAndRefreshWebApplicationContext
+
+`#configureAndRefreshWebApplicationContext(ConfigurableWebApplicationContext wac, ServletContext sc)` 方法，配置 ConfigurableWebApplicationContext 对象，并进行刷新。代码如下：
+
+```
+// ContextLoader.java
+
+/**
+ * Config param for the root WebApplicationContext id,
+ * to be used as serialization id for the underlying BeanFactory: {@value}.
+ */
+public static final String CONTEXT_ID_PARAM = "contextId";
+
+/**
+ * Name of servlet context parameter (i.e., {@value}) that can specify the
+ * config location for the root context, falling back to the implementation's
+ * default otherwise.
+ * @see org.springframework.web.context.support.XmlWebApplicationContext#DEFAULT_CONFIG_LOCATION
+ */
+public static final String CONFIG_LOCATION_PARAM = "contextConfigLocation";
+
+protected void configureAndRefreshWebApplicationContext(ConfigurableWebApplicationContext wac, ServletContext sc) {
+    // <1> 如果 wac 使用了默认编号，则重新设置 id 属性
+    if (ObjectUtils.identityToString(wac).equals(wac.getId())) {
+		// The application context id is still set to its original default value
+		// -> assign a more useful id based on available information
+        // 情况一，使用 contextId 属性
+        String idParam = sc.getInitParameter(CONTEXT_ID_PARAM);
+		if (idParam != null) {
+			wac.setId(idParam);
+        // 情况二，自动生成
+        } else {
+			// Generate default id...
+			wac.setId(ConfigurableWebApplicationContext.APPLICATION_CONTEXT_ID_PREFIX +
+					ObjectUtils.getDisplayString(sc.getContextPath()));
+		}
+	}
+
+	// <2>设置 context 的 ServletContext 属性
+	wac.setServletContext(sc);
+    // <3> 设置 context 的配置文件地址
+	String configLocationParam = sc.getInitParameter(CONFIG_LOCATION_PARAM);
+	if (configLocationParam != null) {
+		wac.setConfigLocation(configLocationParam);
+	}
+
+	// The wac environment's #initPropertySources will be called in any case when the context
+	// is refreshed; do it eagerly here to ensure servlet property sources are in place for
+	// use in any post-processing or initialization that occurs below prior to #refresh
+	// <4> TODO 芋艿，暂时忽略
+    ConfigurableEnvironment env = wac.getEnvironment();
+	if (env instanceof ConfigurableWebEnvironment) {
+		((ConfigurableWebEnvironment) env).initPropertySources(sc, null);
+	}
+
+	// <5> 执行自定义初始化 context TODO 芋艿，暂时忽略
+	customizeContext(sc, wac);
+
+	// 刷新 context ，执行初始化
+	wac.refresh();
+}
+```
+
+- 此处，注释上即写了 `wac` ，右写了 `context` ，实际上，是等价的东西。下面的文字，我们统一用 `wac` 。
+
+- `<1>` 处，如果 `wac` 使用了默认编号，则重新设置 `id` 属性。默认情况下，我们不会对 `wac` 设置编号，所以会执行进去。而实际上，`id` 的生成规则，也分成使用 `contextId` 在 `<context-param />` 标签中设置，和自动生成两种情况。😈 默认情况下，会走第二种情况。
+
+- `<2>` 处，设置 `wac` 的 ServletContext 属性。
+
+- 【**关键**】`<3>` 处，设置 `context` 的配置文件地址。例如我们在 [「1. 概述」](https://svip.iocoder.cn/Spring-MVC/context-init-Root-WebApplicationContext/#) 中所看到的。
+
+  ```
+  <context-param>
+      <param-name>contextConfigLocation</param-name>
+      <param-value>classpath:config/applicationContext.xml</param-value>
+  </context-param>
+  ```
+
+- `<4>` 处，TODO 芋艿，暂时忽略。非关键
+
+- `<5>` 处，调用 `#customizeContext(ServletContext sc, ConfigurableWebApplicationContext wac)` 方法，执行自定义初始化 `wac` 。非关键方法，先直接略过。感兴趣的胖友，自己去瞅瞅。
+
+- 【关键】`<6>` 处， 刷新 `wac` ，执行初始化。此处，就会进行一些的 Spring 容器的初始化。可能胖友对 Spring IOC 不是很了解，所以后面可以回过头看 [《精尽 Spring 源码》](http://svip.iocoder.cn/categories/Spring/?self) 。
+
+😈 回到 [「3.2.2 initWebApplicationContext」](https://svip.iocoder.cn/Spring-MVC/context-init-Root-WebApplicationContext/#) ，我们继续撸。
+
+### 3.2.5 closeWebApplicationContext
+
+`#closeWebApplicationContext(ServletContext servletContext)` 方法，关闭 WebApplicationContext 容器对象。代码如下：
+
+```
+// ContextLoader.java
+
+public void closeWebApplicationContext(ServletContext servletContext) {
+	servletContext.log("Closing Spring root WebApplicationContext");
+	try {
+	    // 关闭 context
+		if (this.context instanceof ConfigurableWebApplicationContext) {
+			((ConfigurableWebApplicationContext) this.context).close();
+		}
+	} finally {
+	    // 移除 currentContext 或 currentContextPerThread
+		ClassLoader ccl = Thread.currentThread().getContextClassLoader();
+		if (ccl == ContextLoader.class.getClassLoader()) {
+			currentContext = null;
+		} else if (ccl != null) {
+			currentContextPerThread.remove(ccl);
+		}
+		// 从 ServletContext 中移除
+		servletContext.removeAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE);
+	}
+}
+```
+
+- 不详细解析，胖友自己瞅瞅。
+
+# 666. 彩蛋
+
+下一篇，我们一起来看看 Servlet WebApplicationContext 容器是怎么初始化的。
+
+参考和推荐如下文章：
+
+- 田小波 [《Spring MVC 原理探秘 - 容器的创建过程》](https://www.tianxiaobo.com/2018/06/30/Spring-MVC-原理探秘-容器的创建过程/)
+- 郝佳 [《Spring 源码深度解析》](https://item.jd.com/11311737.html) 的 [「11.2 ContextLoaderListener」](https://svip.iocoder.cn/Spring-MVC/context-init-Root-WebApplicationContext/#) 小节
\ No newline at end of file
diff --git a/springmvc/05-Spring MVC 源码分析-容器的初始化（二）之 Servlet WebApplicationContext 容器.assets/01.png b/springmvc/05-Spring MVC 源码分析-容器的初始化（二）之 Servlet WebApplicationContext 容器.assets/01.png
new file mode 100644
index 0000000..4c36897
Binary files /dev/null and b/springmvc/05-Spring MVC 源码分析-容器的初始化（二）之 Servlet WebApplicationContext 容器.assets/01.png differ
diff --git a/springmvc/05-Spring MVC 源码分析-容器的初始化（二）之 Servlet WebApplicationContext 容器.md b/springmvc/05-Spring MVC 源码分析-容器的初始化（二）之 Servlet WebApplicationContext 容器.md
new file mode 100644
index 0000000..6aa805c
--- /dev/null
+++ b/springmvc/05-Spring MVC 源码分析-容器的初始化（二）之 Servlet WebApplicationContext 容器.md	
@@ -0,0 +1,981 @@
+# 精尽 Spring MVC 源码分析 —— 容器的初始化（二）之 Servlet WebApplicationContext 容器
+
+# 1. 概述
+
+本文接 [《精尽 Spring MVC 源码分析 —— 容器的初始化（一）之 Root WebApplicationContext 容器》](http://svip.iocoder.cn/Spring-MVC/context-init-Root-WebApplicationContext) 一文，我们来分享下 Servlet WebApplicationContext 容器的初始化的过程。
+
+在开始之前，我们还是回过头看一眼 `web.xml` 的配置。代码如下：
+
+```
+<servlet>
+    <servlet-name>spring</servlet-name>
+    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
+    <!-- 可以自定义servlet.xml配置文件的位置和名称，默认为WEB-INF目录下，名称为[<servlet-name>]-servlet.xml，如spring-servlet.xml
+    <init-param>
+        <param-name>contextConfigLocation</param-name>
+        <param-value>/WEB-INF/spring-servlet.xml</param-value> // 默认
+    </init-param>
+    -->
+    <load-on-startup>1</load-on-startup>
+</servlet>
+<servlet-mapping>
+    <servlet-name>spring</servlet-name>
+    <url-pattern>*.do</url-pattern>
+</servlet-mapping>
+```
+
+- 即， **Servlet** WebApplicationContext 容器的初始化，是在 DispatcherServlet 初始化的过程中执行。
+
+------
+
+DispatcherServlet 的类图如下：
+
+[![类图](05-Spring MVC 源码分析-容器的初始化（二）之 Servlet WebApplicationContext 容器.assets/01.png)](http://static.iocoder.cn/images/Spring/2022-02-04/01.png)类图
+
+- HttpServletBean ，负责将 ServletConfig 设置到当前 Servlet 对象中。类上的简单注释如下：
+
+  ```
+  // HttpServletBean.java
+  
+  /**
+   * Simple extension of {@link javax.servlet.http.HttpServlet} which treats
+   * its config parameters ({@code init-param} entries within the
+   * {@code servlet} tag in {@code web.xml}) as bean properties.
+   */
+  ```
+
+- FrameworkServlet ，负责初始化 Spring Servlet WebApplicationContext 容器。类上的简单注释如下：
+
+  ```
+  // FrameworkServlet.java
+  
+  /**
+   * Base servlet for Spring's web framework. Provides integration with
+   * a Spring application context, in a JavaBean-based overall solution.
+   */
+  ```
+
+- DispatcherServlet ，负责初始化 Spring MVC 的各个组件，以及处理客户端的请求。类上的简单注释如下：
+
+  ```
+  // DispatcherServlet.java
+  
+  /**
+   * Central dispatcher for HTTP request handlers/controllers, e.g. for web UI controllers
+   * or HTTP-based remote service exporters. Dispatches to registered handlers for processing
+   * a web request, providing convenient mapping and exception handling facilities.
+   */
+  ```
+
+每一层的 Servlet 实现类，执行对应负责的逻辑。干净~下面，我们逐个类来进行解析。
+
+# 2. 如何调试
+
+执行 `DispatcherServletTests#configuredDispatcherServlets()` 单元测试方法，即可执行本文涉及的一些逻辑。
+
+# 3. HttpServletBean
+
+`org.springframework.web.servlet.HttpServletBean` ，实现 EnvironmentCapable、EnvironmentAware 接口，继承 HttpServlet 抽象类，负责将 ServletConfig 集成到 Spring 中。当然，HttpServletBean 自身也是一个抽象类。
+
+## 3.1 构造方法
+
+```
+// HttpServletBean.java
+
+@Nullable
+private ConfigurableEnvironment environment;
+
+/**
+ * 必须配置的属性的集合
+ *
+ * 在 {@link ServletConfigPropertyValues} 中，会校验是否有对应的属性
+ */
+private final Set<String> requiredProperties = new HashSet<>(4);
+```
+
+- `environment` 属性，相关的方法，代码如下：
+
+  ```
+  // HttpServletBean.java
+  
+  // setting 方法
+  @Override // 实现自 EnvironmentAware 接口，自动注入
+  public void setEnvironment(Environment environment) {
+  	Assert.isInstanceOf(ConfigurableEnvironment.class, environment, "ConfigurableEnvironment required");
+  	this.environment = (ConfigurableEnvironment) environment;
+  }
+  
+  // getting 方法
+  @Override // 实现自 EnvironmentCapable 接口
+  public ConfigurableEnvironment getEnvironment() {
+      // 如果 environment 为空，主动创建
+  	if (this.environment == null) {
+  		this.environment = createEnvironment();
+  	}
+  	return this.environment;
+  }
+  
+  protected ConfigurableEnvironment createEnvironment() {
+  	return new StandardServletEnvironment();
+  }
+  ```
+
+  - 为什么 `environment` 属性，能够被自动注入呢？答案是 EnvironmentAware 接口。具体的源码解析，见 [《【死磕 Spring】—— IoC 之深入分析 Aware 接口》](http://svip.iocoder.cn/Spring/IoC-Aware-interface/?self) 。当然，也可以不看。
+
+- `requiredProperties` 属性，必须配置的属性的集合。可通过 `#addRequiredProperty(String property)` 方法，添加到其中。代码如下：
+
+  ```
+  // HttpServletBean.java
+  
+  protected final void addRequiredProperty(String property) {
+  	this.requiredProperties.add(property);
+  }
+  ```
+
+## 3.2 init
+
+`#init()` 方法，负责将 ServletConfig 设置到当前 Servlet 对象中。代码如下：
+
+```
+// HttpServletBean.java
+
+@Override
+public final void init() throws ServletException {
+	// Set bean properties from init parameters.
+    // <1> 解析 <init-param /> 标签，封装到 PropertyValues pvs 中
+	PropertyValues pvs = new ServletConfigPropertyValues(getServletConfig(), this.requiredProperties);
+	if (!pvs.isEmpty()) {
+		try {
+		    // <2.1> 将当前的这个 Servlet 对象，转化成一个 BeanWrapper 对象。从而能够以 Spring 的方式来将 pvs 注入到该 BeanWrapper 对象中
+			BeanWrapper bw = PropertyAccessorFactory.forBeanPropertyAccess(this);
+			ResourceLoader resourceLoader = new ServletContextResourceLoader(getServletContext());
+			// <2.2> 注册自定义属性编辑器，一旦碰到 Resource 类型的属性，将会使用 ResourceEditor 进行解析
+			bw.registerCustomEditor(Resource.class, new ResourceEditor(resourceLoader, getEnvironment()));
+            // <2.3> 空实现，留给子类覆盖
+			initBeanWrapper(bw);
+			// <2.4> 以 Spring 的方式来将 pvs 注入到该 BeanWrapper 对象中
+			bw.setPropertyValues(pvs, true);
+		} catch (BeansException ex) {
+			if (logger.isErrorEnabled()) {
+				logger.error("Failed to set bean properties on servlet '" + getServletName() + "'", ex);
+			}
+			throw ex;
+		}
+	}
+
+	// Let subclasses do whatever initialization they like.
+    // <3> 子类来实现，实现自定义的初始化逻辑。目前，有具体的代码实现。
+	initServletBean();
+}
+```
+
+- `<1>` 处，解析 Servlet 配置的 `<init-param />` 标签，封装到 PropertyValues `pvs` 中。其中，ServletConfigPropertyValues 是 HttpServletBean 的私有静态类，继承 MutablePropertyValues 类，**ServletConfig 的 PropertyValues 封装实现类**。代码如下：
+
+  ```
+  // HttpServletBean.java
+  
+  private static class ServletConfigPropertyValues extends MutablePropertyValues {
+  
+  	/**
+  	 * Create new ServletConfigPropertyValues.
+  	 * @param config the ServletConfig we'll use to take PropertyValues from
+  	 * @param requiredProperties set of property names we need, where
+  	 * we can't accept default values
+  	 * @throws ServletException if any required properties are missing
+  	 */
+  	public ServletConfigPropertyValues(ServletConfig config, Set<String> requiredProperties)
+  			throws ServletException {
+  	    // 获得缺失的属性的集合
+  		Set<String> missingProps = (!CollectionUtils.isEmpty(requiredProperties) ?
+  				new HashSet<>(requiredProperties) : null);
+  
+  		// <1> 遍历 ServletConfig 的初始化参数集合，添加到 ServletConfigPropertyValues 中，并从 missingProps 移除
+  		Enumeration<String> paramNames = config.getInitParameterNames();
+  		while (paramNames.hasMoreElements()) {
+  			String property = paramNames.nextElement();
+  			Object value = config.getInitParameter(property);
+  			// 添加到 ServletConfigPropertyValues 中
+  			addPropertyValue(new PropertyValue(property, value));
+  			// 从 missingProps 中移除
+  			if (missingProps != null) {
+  				missingProps.remove(property);
+  			}
+  		}
+  
+  		// Fail if we are still missing properties.
+          // <2> 如果存在缺失的属性，抛出 ServletException 异常
+  		if (!CollectionUtils.isEmpty(missingProps)) {
+  			throw new ServletException(
+  					"Initialization from ServletConfig for servlet '" + config.getServletName() +
+  					"' failed; the following required properties were missing: " +
+  					StringUtils.collectionToDelimitedString(missingProps, ", "));
+  		}
+  	}
+  
+  }
+  ```
+
+  - 代码简单，实现两方面的逻辑：`<1>` 处，遍历 ServletConfig 的初始化参数集合，添加到 ServletConfigPropertyValues 中；`<2>` 处，判断要求的属性是否齐全。如果不齐全，则抛出 ServletException 异常。
+
+- `<2.1>` 处，将当前的这个 Servlet 对象，转化成一个 BeanWrapper 对象。从而能够以 Spring 的方式来将 `pvs` 注入到该 BeanWrapper 对象中。简单来说，BeanWrapper 是 Spring 提供的一个用来操作 Java Bean 属性的工具，**使用它可以直接修改一个对象的属性**。
+
+- `<2.2>` 处，注册自定义属性编辑器，一旦碰到 Resource 类型的属性，将会使用 ResourceEditor 进行解析。
+
+- `<2.3>` 处，空实现，留给子类覆盖。代码如下：
+
+  ```
+  // HttpServletBean.java
+  
+  /**
+   * Initialize the BeanWrapper for this HttpServletBean,
+   * possibly with custom editors.
+   * <p>This default implementation is empty.
+   * @param bw the BeanWrapper to initialize
+   * @throws BeansException if thrown by BeanWrapper methods
+   * @see org.springframework.beans.BeanWrapper#registerCustomEditor
+   */
+  protected void initBeanWrapper(BeanWrapper bw) throws BeansException {
+  }
+  ```
+
+  - 然而实际上，子类暂时木有任何实现。
+
+- `<2.4>` 处，以 Spring 的方式来将 `pvs` 注入到该 BeanWrapper 对象中，技设置到当前 Servlet 对象中。可能比较费解，我们还是举个例子。假设如下：
+
+  ```
+  // web.xml
+  
+  <servlet>
+      <servlet-name>spring</servlet-name>
+      <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
+      <init-param>
+          <param-name>contextConfigLocation</param-name>
+          <param-value>/WEB-INF/spring-servlet.xml</param-value>
+      </init-param>
+      <load-on-startup>1</load-on-startup>
+  </servlet>
+  <servlet-mapping>
+      <servlet-name>spring</servlet-name>
+      <url-pattern>*.do</url-pattern>
+  </servlet-mapping>
+  ```
+
+  - 此处有配置了 `contextConfigLocation` 属性，那么通过 `<2.4>` 处的逻辑，会反射设置到 `FrameworkServlet.contextConfigLocation` 属性。代码如下：
+
+    ```
+    // FrameworkServlet.java
+    
+    /** Explicit context config location. */
+    @Nullable
+    private String contextConfigLocation;
+    
+    public void setContextConfigLocation(@Nullable String contextConfigLocation) {
+    	this.contextConfigLocation = contextConfigLocation;
+    }
+    ```
+
+    - 😈 看懂了这波骚操作了么？
+
+- `<3>` 处，调用 `#initServletBean()` 方法，子类来实现，实现自定义的初始化逻辑。目前，FrameworkServlet 实现类该方法。代码如下：
+
+  ```
+  // HttpServletBean.java
+  
+  protected void initServletBean() throws ServletException {
+  }
+  ```
+
+  - 详细解析，见 [「4. FrameworkServlet」](https://svip.iocoder.cn/Spring-MVC/context-init-Servlet-WebApplicationContext/#) 。
+
+# 4. FrameworkServlet
+
+`org.springframework.web.servlet.FrameworkServlet` ，实现 ApplicationContextAware 接口，继承 HttpServletBean 抽象类，负责初始化 Spring Servlet WebApplicationContext 容器。同时，FrameworkServlet 自身也是一个抽象类。
+
+## 4.1 构造方法
+
+FrameworkServlet 的属性还是非常多，我们还是只看部分的关键属性。代码如下：
+
+```
+// FrameworkServlet.java
+
+/**
+ * WebApplicationContext implementation class to create.
+ *
+ * 创建的 WebApplicationContext 类型
+ */
+private Class<?> contextClass = DEFAULT_CONTEXT_CLASS;
+
+/**
+ * Explicit context config location.
+ *
+ * 配置文件的地址
+ */
+@Nullable
+private String contextConfigLocation;
+
+/**
+ * WebApplicationContext for this servlet.
+ *
+ * WebApplicationContext 对象
+ */
+@Nullable
+private WebApplicationContext webApplicationContext;
+```
+
+- `contextClass` 属性，创建的 WebApplicationContext 类型，默认为 `DEFAULT_CONTEXT_CLASS` 。代码如下：
+
+  ```
+  /**
+   * Default context class for FrameworkServlet.
+   * @see org.springframework.web.context.support.XmlWebApplicationContext
+   */
+  public static final Class<?> DEFAULT_CONTEXT_CLASS = XmlWebApplicationContext.class;
+  ```
+
+  - 😈 又是我们熟悉的 XmlWebApplicationContext 类。在上一篇文章的 `ContextLoader.properties` 配置文件中，我们已经看到咯。
+
+- `contextConfigLocation` 属性，配置文件的地址。例如：`/WEB-INF/spring-servlet.xml` 。
+
+- `webApplicationContext` 属性，WebApplicationContext 对象，即本文的关键，**Servlet WebApplicationContext 容器**。它有四种方式进行“创建”。
+
+  - 方式一：通过构造方法，代码如下：
+
+    ```
+    // FrameworkServlet.java
+    
+    public FrameworkServlet(WebApplicationContext webApplicationContext) {
+    	this.webApplicationContext = webApplicationContext;
+    }
+    ```
+
+    - 通过方法参数 `webApplicationContext` 。
+
+  - 方式二：因为实现 ApplicationContextAware 接口，也可以 Spring 注入。代码如下：
+
+    ```
+    // FrameworkServlet.java
+    
+    /**
+     * If the WebApplicationContext was injected via {@link #setApplicationContext}.
+     *
+     * 标记 {@link #webApplicationContext} 属性，是否通过 {@link #setApplicationContext(ApplicationContext)} 方法进行注入
+     */
+    private boolean webApplicationContextInjected = false;
+    
+    @Override
+    public void setApplicationContext(ApplicationContext applicationContext) {
+    	if (this.webApplicationContext == null && applicationContext instanceof WebApplicationContext) {
+    		this.webApplicationContext = (WebApplicationContext) applicationContext;
+    		this.webApplicationContextInjected = true;
+    	}
+    }
+    ```
+
+    - 和方式一，是有几分类似的。
+
+  - 方式三：见 `#findWebApplicationContext()` 方法。
+
+  - 方式四：见 `#createWebApplicationContext(WebApplicationContext parent)` 方法。
+
+## 4.2 initServletBean
+
+`#initServletBean()` 方法，进一步初始化当前 Servlet 对象。实际上，重心在初始化 Servlet WebApplicationContext 容器。代码如下：
+
+```
+// FrameworkServlet.java
+
+@Override
+protected final void initServletBean() throws ServletException {
+	// 打日志
+    getServletContext().log("Initializing Spring " + getClass().getSimpleName() + " '" + getServletName() + "'");
+	if (logger.isInfoEnabled()) {
+		logger.info("Initializing Servlet '" + getServletName() + "'");
+	}
+
+	// 记录开始时间
+	long startTime = System.currentTimeMillis();
+
+	try {
+	    // 初始化 WebApplicationContext 对象
+		this.webApplicationContext = initWebApplicationContext();
+		// 空实现。子类有需要，可以实现该方法，实现自定义逻辑
+		initFrameworkServlet();
+	} catch (ServletException | RuntimeException ex) {
+		logger.error("Context initialization failed", ex);
+		throw ex;
+	}
+
+	// 打日志
+	if (logger.isDebugEnabled()) {
+		String value = this.enableLoggingRequestDetails ?
+				"shown which may lead to unsafe logging of potentially sensitive data" :
+				"masked to prevent unsafe logging of potentially sensitive data";
+		logger.debug("enableLoggingRequestDetails='" + this.enableLoggingRequestDetails +
+				"': request parameters and headers will be " + value);
+	}
+
+	// 打日志
+	if (logger.isInfoEnabled()) {
+		logger.info("Completed initialization in " + (System.currentTimeMillis() - startTime) + " ms");
+	}
+}
+```
+
+- `<1>` 处，调用 `#initWebApplicationContext()` 方法，初始化 Servlet WebApplicationContext 对象。详细解析，见 [「4.3 initWebApplicationContext」](https://svip.iocoder.cn/Spring-MVC/context-init-Servlet-WebApplicationContext/#) 。
+
+- `<2>` 处，调用 `#initFrameworkServlet()` 方法，空实现。子类有需要，可以实现该方法，实现自定义逻辑。代码如下：
+
+  ```
+  // FrameworkServlet.java
+  
+  /**
+   * This method will be invoked after any bean properties have been set and
+   * the WebApplicationContext has been loaded. The default implementation is empty;
+   * subclasses may override this method to perform any initialization they require.
+   * @throws ServletException in case of an initialization exception
+   */
+  protected void initFrameworkServlet() throws ServletException {
+  }
+  ```
+
+  - 😈 然而实际上，并没有子类，对该方法重新实现。
+
+## 4.3 initWebApplicationContext
+
+`#initWebApplicationContext()` 方法，初始化 Servlet WebApplicationContext 对象。代码如下：
+
+> 艿艿提示：这个方法的逻辑并不复杂，但是涉及调用的方法的逻辑比较多。同时，也是本文最最最核心的方法了。
+
+```
+// FrameworkServlet.java
+
+protected WebApplicationContext initWebApplicationContext() {
+    // <1> 获得根 WebApplicationContext 对象
+	WebApplicationContext rootContext = WebApplicationContextUtils.getWebApplicationContext(getServletContext());
+
+	// <2> 获得 WebApplicationContext wac 变量
+	WebApplicationContext wac = null;
+	// 第一种情况，如果构造方法已经传入 webApplicationContext 属性，则直接使用
+	if (this.webApplicationContext != null) {
+		// A context instance was injected at construction time -> use it
+        // 赋值给 wac 变量
+		wac = this.webApplicationContext;
+		// 如果是 ConfigurableWebApplicationContext 类型，并且未激活，则进行初始化
+		if (wac instanceof ConfigurableWebApplicationContext) {
+			ConfigurableWebApplicationContext cwac = (ConfigurableWebApplicationContext) wac;
+			if (!cwac.isActive()) { // 未激活
+				// The context has not yet been refreshed -> provide services such as
+				// setting the parent context, setting the application context id, etc
+                // 设置 wac 的父 context 为 rootContext 对象
+				if (cwac.getParent() == null) {
+					// The context instance was injected without an explicit parent -> set
+					// the root application context (if any; may be null) as the parent
+					cwac.setParent(rootContext);
+				}
+				// 配置和初始化 wac
+				configureAndRefreshWebApplicationContext(cwac);
+			}
+		}
+	}
+	// 第二种情况，从 ServletContext 获取对应的 WebApplicationContext 对象
+	if (wac == null) {
+		// No context instance was injected at construction time -> see if one
+		// has been registered in the servlet context. If one exists, it is assumed
+		// that the parent context (if any) has already been set and that the
+		// user has performed any initialization such as setting the context id
+		wac = findWebApplicationContext();
+	}
+	// 第三种，创建一个 WebApplicationContext 对象
+	if (wac == null) {
+		// No context instance is defined for this servlet -> create a local one
+		wac = createWebApplicationContext(rootContext);
+	}
+
+	// <3> 如果未触发刷新事件，则主动触发刷新事件
+	if (!this.refreshEventReceived) {
+		// Either the context is not a ConfigurableApplicationContext with refresh
+		// support or the context injected at construction time had already been
+		// refreshed -> trigger initial onRefresh manually here.
+		onRefresh(wac);
+	}
+
+	// <4> 将 context 设置到 ServletContext 中
+	if (this.publishContext) {
+		// Publish the context as a servlet context attribute.
+		String attrName = getServletContextAttributeName();
+		getServletContext().setAttribute(attrName, wac);
+	}
+
+	return wac;
+}
+```
+
+- `<1>` 处，调用 `WebApplicationContextUtils#getWebApplicationContext((ServletContext sc)` 方法，获得 Root WebApplicationContext 对象，这就是在 [《精尽 Spring MVC 源码分析 —— 容器的初始化（一）之 Root WebApplicationContext 容器》](http://svip.iocoder.cn/Spring-MVC/context-init-Root-WebApplicationContext) 中初始化的呀。代码如下：
+
+  ```
+  // WebApplicationContextUtils.java
+  
+  @Nullable
+  public static WebApplicationContext getWebApplicationContext(ServletContext sc) {
+  	return getWebApplicationContext(sc, WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE);
+  }
+  
+  @Nullable
+  public static WebApplicationContext getWebApplicationContext(ServletContext sc, String attrName) {
+  	Assert.notNull(sc, "ServletContext must not be null");
+  	Object attr = sc.getAttribute(attrName);
+  	// ... 省略各种校验的代码
+  	return (WebApplicationContext) attr;
+  }
+  ```
+
+  - 熟不熟悉，惊喜不惊喜。
+
+- `<2>` 处，获得 WebApplicationContext `wac` 变量。下面，会分成三种情况。
+
+- ========== 第一种情况 ==========
+
+- 如果构造方法已经传入 `webApplicationContext` 属性，则直接使用。实际上，就是我们在 [「4.1 构造方法」](https://svip.iocoder.cn/Spring-MVC/context-init-Servlet-WebApplicationContext/#) 提到的 **Servlet WebApplicationContext 容器**的第一、二种方式。
+
+- 实际上，这块代码和 `ContextLoader#initWebApplicationContext(ServletContext servletContext)` 的[中间段](https://github.com/spring-projects/spring-framework/blob/master/spring-web/src/main/java/org/springframework/web/context/ContextLoader.java#L280-L293) 是一样的。除了 `#configureAndRefreshWebApplicationContext(ConfigurableWebApplicationContext wac)` 的具体实现代码不同。详细解析，见 [「4.4 configureAndRefreshWebApplicationContext」](https://svip.iocoder.cn/Spring-MVC/context-init-Servlet-WebApplicationContext/#) 。
+
+- ========== 第二种情况 ==========
+
+- 这种情况，就是我们在 [「4.1 构造方法」](https://svip.iocoder.cn/Spring-MVC/context-init-Servlet-WebApplicationContext/#) 提到的 **Servlet WebApplicationContext 容器**的第三种方式。
+
+- 如果此处 `wac` 还是为空，则调用 `#findWebApplicationContext()` 方法，从 ServletContext 获取对应的 WebApplicationContext 对象。代码如下：
+
+  ```
+  // FrameworkServlet.java
+  
+  /** ServletContext attribute to find the WebApplicationContext in. */
+  @Nullable
+  private String contextAttribute;
+  @Nullable
+  public String getContextAttribute() {
+  	return this.contextAttribute;
+  }
+  
+  @Nullable
+  protected WebApplicationContext findWebApplicationContext() {
+  	String attrName = getContextAttribute();
+  	// 需要配置了 contextAttribute 属性下，才会去查找
+  	if (attrName == null) {
+  		return null;
+  	}
+  	// 从 ServletContext 中，获得属性名对应的 WebApplicationContext 对象
+  	WebApplicationContext wac = WebApplicationContextUtils.getWebApplicationContext(getServletContext(), attrName);
+  	// 如果不存在，则抛出 IllegalStateException 异常
+  	if (wac == null) {
+  		throw new IllegalStateException("No WebApplicationContext found: initializer not registered?");
+  	}
+  	return wac;
+  }
+  ```
+
+  - 一般情况下，我们不会配置 `contextAttribute` 属性。所以，这段逻辑暂时无视。
+
+- ========== 第三种情况 ==========
+
+- 这种情况，就是我们在 [「4.1 构造方法」](https://svip.iocoder.cn/Spring-MVC/context-init-Servlet-WebApplicationContext/#) 提到的 **Servlet WebApplicationContext 容器**的第四种方式。
+
+- 如果此处 `wac` 还是为空，则调用 `#createWebApplicationContext(WebApplicationContext parent)` 方法，创建一个 WebApplicationContext 对象。代码如下：
+
+  ```
+  // FrameworkServlet.java
+  
+  /**
+   * WebApplicationContext implementation class to create.
+   *
+   * 创建的 WebApplicationContext 类型
+   */
+  private Class<?> contextClass = DEFAULT_CONTEXT_CLASS;
+  public Class<?> getContextClass() {
+  	return this.contextClass;
+  }
+  
+  protected WebApplicationContext createWebApplicationContext(@Nullable ApplicationContext parent) {
+      // <a> 获得 context 的类
+  	Class<?> contextClass = getContextClass();
+  	// 如果非 ConfigurableWebApplicationContext 类型，抛出 ApplicationContextException 异常
+  	if (!ConfigurableWebApplicationContext.class.isAssignableFrom(contextClass)) {
+  		throw new ApplicationContextException(
+  				"Fatal initialization error in servlet with name '" + getServletName() +
+  				"': custom WebApplicationContext class [" + contextClass.getName() +
+  				"] is not of type ConfigurableWebApplicationContext");
+  	}
+  	// <b> 创建 context 类的对象
+  	ConfigurableWebApplicationContext wac =
+  			(ConfigurableWebApplicationContext) BeanUtils.instantiateClass(contextClass);
+  
+  	// <c> 设置 environment、parent、configLocation 属性
+  	wac.setEnvironment(getEnvironment());
+  	wac.setParent(parent);
+  	String configLocation = getContextConfigLocation();
+  	if (configLocation != null) {
+  		wac.setConfigLocation(configLocation);
+  	}
+  
+  	// <d> 配置和初始化 wac
+  	configureAndRefreshWebApplicationContext(wac);
+  
+  	return wac;
+  }
+  ```
+
+  - `<a>` 处，获得 `context` 的类，即 `contextClass` 属性。并且，如果非 ConfigurableWebApplicationContext 类型，抛出 ApplicationContextException 异常。
+  - `<b>` 处，创建 `context` 类的对象。
+  - `<c>` 处，设置 `environment`、`parent`、`configLocation` 属性。其中，`configLocation` 是个**重要**属性。
+  - `<d>` 处，调用 `#configureAndRefreshWebApplicationContext(ConfigurableWebApplicationContext wac)` 方法，配置和初始化 `wac` 。详细解析，见 [「4.4 configureAndRefreshWebApplicationContext」](https://svip.iocoder.cn/Spring-MVC/context-init-Servlet-WebApplicationContext/#) 。
+
+- ========== END ==========
+
+- `<3>` 处，如果未触发刷新事件，则调用 `#onRefresh(ApplicationContext context)` 主动触发刷新事件。详细解析，见 [「4.5 onRefresh」](https://svip.iocoder.cn/Spring-MVC/context-init-Servlet-WebApplicationContext/#) 中。另外，`refreshEventReceived` 属性，定义如下：
+
+  ```
+  // FrameworkServlet.java
+  
+  /**
+   * Flag used to detect whether onRefresh has already been called.
+   *
+   * 标记是否接收到 ContextRefreshedEvent 事件。即 {@link #onApplicationEvent(ContextRefreshedEvent)}
+   */
+  private boolean refreshEventReceived = false;
+  ```
+
+- `<4>` 处，如果 `publishContext` 为 `true` 时，则将 `context` 设置到 ServletContext 中。涉及到的变量和方法如下：
+
+  ```
+  // FrameworkServlet.java
+  
+  /**
+   * Should we publish the context as a ServletContext attribute?.
+   *
+   * 是否将 {@link #webApplicationContext} 设置到 {@link ServletContext} 的属性种
+   */
+  private boolean publishContext = true;
+  
+  /**
+   * Prefix for the ServletContext attribute for the WebApplicationContext.
+   * The completion is the servlet name.
+   */
+  public static final String SERVLET_CONTEXT_PREFIX = FrameworkServlet.class.getName() + ".CONTEXT.";
+  
+  public String getServletContextAttributeName() {
+  	return SERVLET_CONTEXT_PREFIX + getServletName();
+  }
+  
+  // HttpServletBean.java
+  
+  @Override
+  @Nullable
+  public String getServletName() {
+  	return (getServletConfig() != null ? getServletConfig().getServletName() : null);
+  }
+  ```
+
+## 4.4 configureAndRefreshWebApplicationContext
+
+`#configureAndRefreshWebApplicationContext(ConfigurableWebApplicationContext wac)` 方法，配置和初始化 `wac` 。代码如下：
+
+```
+// FrameworkServlet.java
+
+protected void configureAndRefreshWebApplicationContext(ConfigurableWebApplicationContext wac) {
+	// <1> 如果 wac 使用了默认编号，则重新设置 id 属性
+    if (ObjectUtils.identityToString(wac).equals(wac.getId())) {
+		// The application context id is still set to its original default value
+		// -> assign a more useful id based on available information
+        // 情况一，使用 contextId 属性
+		if (this.contextId != null) {
+			wac.setId(this.contextId);
+        // 情况二，自动生成
+		} else {
+			// Generate default id...
+			wac.setId(ConfigurableWebApplicationContext.APPLICATION_CONTEXT_ID_PREFIX +
+					ObjectUtils.getDisplayString(getServletContext().getContextPath()) + '/' + getServletName());
+		}
+	}
+
+	// <2> 设置 wac 的 servletContext、servletConfig、namespace 属性
+	wac.setServletContext(getServletContext());
+	wac.setServletConfig(getServletConfig());
+	wac.setNamespace(getNamespace());
+
+	// <3> 添加监听器 SourceFilteringListener 到 wac 中
+	wac.addApplicationListener(new SourceFilteringListener(wac, new ContextRefreshListener()));
+
+	// <4> TODO 芋艿，暂时忽略
+	// The wac environment's #initPropertySources will be called in any case when the context
+	// is refreshed; do it eagerly here to ensure servlet property sources are in place for
+	// use in any post-processing or initialization that occurs below prior to #refresh
+	ConfigurableEnvironment env = wac.getEnvironment();
+	if (env instanceof ConfigurableWebEnvironment) {
+		((ConfigurableWebEnvironment) env).initPropertySources(getServletContext(), getServletConfig());
+	}
+
+	// <5> 执行处理完 WebApplicationContext 后的逻辑。目前是个空方法，暂无任何实现
+	postProcessWebApplicationContext(wac);
+
+	// <6> 执行自定义初始化 context TODO 芋艿，暂时忽略
+	applyInitializers(wac);
+
+	// <7> 刷新 wac ，从而初始化 wac
+	wac.refresh();
+}
+```
+
+- 实际上，大体逻辑上，和 [《精尽 Spring MVC 源码分析 —— 容器的初始化（一）之 Root WebApplicationContext 容器》](http://svip.iocoder.cn/Spring-MVC/context-init-Root-WebApplicationContext) 的 [「4.3 configureAndRefreshWebApplicationContext」](https://svip.iocoder.cn/Spring-MVC/context-init-Servlet-WebApplicationContext/#) 小节是一致的。
+
+- 【相同】`<1>` 处，如果 `wac` 使用了默认编号，则重新设置 `id` 属性。
+
+- 【类似】`<2>` 处，设置 `wac` 的 `servletContext`、`servletConfi`g、`namespace` 属性。
+
+- 【独有】`<3>` 处，添加监听器 SourceFilteringListener 到 `wac` 中。这块的详细解析，见 [「4.5 onRefresh」](https://svip.iocoder.cn/Spring-MVC/context-init-Servlet-WebApplicationContext/#) 中。
+
+- 【相同】`<4>` 处，TODO 芋艿，暂时忽略。
+
+- 【独有】`<5>` 处，执行处理完 WebApplicationContext 后的逻辑。目前是个空方法，暂无任何实现。代码如下：
+
+  ```
+  // FrameworkServlet.java
+  
+  protected void postProcessWebApplicationContext(ConfigurableWebApplicationContext wac) {
+  }
+  ```
+
+- 【相同】`<6>` 处，执行自定义初始化 context TODO 芋艿，暂时忽略。
+- 【相同】`<7>` 处，刷新 `wac` ，从而初始化 `wac` 。
+
+## 4.5 onRefresh
+
+`#onRefresh(ApplicationContext context)` 方法，当 Servlet WebApplicationContext 刷新完成后，触发 Spring MVC 组件的初始化。代码如下：
+
+```
+// FrameworkServlet.java
+
+/**
+ * Template method which can be overridden to add servlet-specific refresh work.
+ * Called after successful context refresh.
+ * <p>This implementation is empty.
+ * @param context the current WebApplicationContext
+ * @see #refresh()
+ */
+protected void onRefresh(ApplicationContext context) {
+	// For subclasses: do nothing by default.
+}
+```
+
+- 这是一个空方法，具体的实现，在子类 DispatcherServlet 中。代码如下：
+
+  ```
+  // DispatcherServlet.java
+  
+  /**
+   * This implementation calls {@link #initStrategies}.
+   */
+  @Override
+  protected void onRefresh(ApplicationContext context) {
+  	initStrategies(context);
+  }
+  
+  /**
+   * Initialize the strategy objects that this servlet uses.
+   * <p>May be overridden in subclasses in order to initialize further strategy objects.
+   */
+  protected void initStrategies(ApplicationContext context) {
+      // 初始化 MultipartResolver
+  	initMultipartResolver(context);
+  	// 初始化 LocaleResolver
+  	initLocaleResolver(context);
+  	// 初始化 ThemeResolver
+  	initThemeResolver(context);
+  	// 初始化 HandlerMappings
+  	initHandlerMappings(context);
+  	// 初始化 HandlerAdapters
+  	initHandlerAdapters(context);
+  	// 初始化 HandlerExceptionResolvers 
+  	initHandlerExceptionResolvers(context);
+  	// 初始化 RequestToViewNameTranslator
+  	initRequestToViewNameTranslator(context);
+  	// 初始化 ViewResolvers
+  	initViewResolvers(context);
+  	// 初始化 FlashMapManager
+  	initFlashMapManager(context);
+  }
+  ```
+
+  - 这里，我们先不深究，在 DispatcherServlet 的初始化的文章中，详细解析。
+
+------
+
+`#onRefresh()` 方法，有两种方式被触发：
+
+- 方式一，在
+
+   
+
+  「4.3 initWebApplicationContext」
+
+   
+
+  中，有两种情形，会触发。
+
+  - 情形一：情况一 + `wac` 已激活。
+  - 情形二：情况二。
+  - 这两种情形，此时 `refreshEventReceived` 为 `false` ，所以会顺着 `#initWebApplicationContext()` 方法的 `<3>` 的逻辑，调用 `#onRefresh()` 方法。😈 貌似说的有点绕，大家自己顺顺。
+
+- 方式二，在
+
+   
+
+  「4.3 initWebApplicationContext」
+
+   
+
+  中，也有两种情况，会触发。不过相比方式一来说，过程会“曲折”一点。
+
+  - 情形一：情况一 + `wac` 未激活。
+  - 情形二：情况三。
+  - 这两种情形，都会调用 `#configureAndRefreshWebApplicationContext(ConfigurableWebApplicationContext wac)` 方法，在 `wac` 执行刷新完成后，会回调在该方法中，注册的 SourceFilteringListener 监听器。详细解析，见 [「5. SourceFilteringListener」](https://svip.iocoder.cn/Spring-MVC/context-init-Servlet-WebApplicationContext/#) 。
+
+# 5. SourceFilteringListener
+
+`org.springframework.context.event.SourceFilteringListener` ，实现 GenericApplicationListener、SmartApplicationListener 监听器，实现将原始对象触发的事件，转发给指定监听器。代码如下：
+
+```
+// SourceFilteringListener.java
+
+public class SourceFilteringListener implements GenericApplicationListener, SmartApplicationListener {
+
+    /**
+     * 原始类
+     */
+	private final Object source;
+    /**
+     * 代理的监听器
+     */
+	@Nullable
+	private GenericApplicationListener delegate;
+
+	/**
+	 * Create a SourceFilteringListener for the given event source.
+	 * @param source the event source that this listener filters for,
+	 * only processing events from this source
+	 * @param delegate the delegate listener to invoke with event
+	 * from the specified source
+	 */
+	public SourceFilteringListener(Object source, ApplicationListener<?> delegate) {
+		this.source = source;
+		this.delegate = (delegate instanceof GenericApplicationListener ?
+				(GenericApplicationListener) delegate : new GenericApplicationListenerAdapter(delegate));
+	}
+
+	/**
+	 * Create a SourceFilteringListener for the given event source,
+	 * expecting subclasses to override the {@link #onApplicationEventInternal}
+	 * method (instead of specifying a delegate listener).
+	 * @param source the event source that this listener filters for,
+	 * only processing events from this source
+	 */
+	protected SourceFilteringListener(Object source) {
+		this.source = source;
+	}
+
+
+	@Override
+	public void onApplicationEvent(ApplicationEvent event) {
+		if (event.getSource() == this.source) { // 判断来源
+			onApplicationEventInternal(event);
+		}
+	}
+
+	@Override
+	public boolean supportsEventType(ResolvableType eventType) {
+		return (this.delegate == null || this.delegate.supportsEventType(eventType));
+	}
+
+	@Override
+	public boolean supportsEventType(Class<? extends ApplicationEvent> eventType) {
+		return supportsEventType(ResolvableType.forType(eventType));
+	}
+
+	@Override
+	public boolean supportsSourceType(@Nullable Class<?> sourceType) {
+		return (sourceType != null && sourceType.isInstance(this.source));
+	}
+
+	@Override
+	public int getOrder() {
+		return (this.delegate != null ? this.delegate.getOrder() : Ordered.LOWEST_PRECEDENCE);
+	}
+
+
+	/**
+	 * Actually process the event, after having filtered according to the
+	 * desired event source already.
+	 * <p>The default implementation invokes the specified delegate, if any.
+	 * @param event the event to process (matching the specified source)
+	 */
+	protected void onApplicationEventInternal(ApplicationEvent event) {
+		if (this.delegate == null) {
+			throw new IllegalStateException(
+					"Must specify a delegate object or override the onApplicationEventInternal method");
+		}
+		this.delegate.onApplicationEvent(event);
+	}
+
+}
+```
+
+- 这个类的核心代码，就是 `#onApplicationEvent(ApplicationEvent event)` 方法中，判断事件的来源，就是原始类 `source` 。如果是，则调用 `#onApplicationEventInternal(ApplicationEvent event)` 方法，将事件转发给 `delegate` 监听器。
+
+------
+
+我们在回看下 `#configureAndRefreshWebApplicationContext(ConfigurableWebApplicationContext wac)` 方法，创建 SourceFilteringListener 对象时，传入的两个参数：
+
+- `source` 属性，就是 `wac` 对象。
+- `delegate` 属性，就是 ContextRefreshListener 对象。
+
+下面，让我们来看看 ContextRefreshListener 具体的代码实现，代码如下：
+
+```
+// FrameworkServlet.java
+
+private class ContextRefreshListener implements ApplicationListener<ContextRefreshedEvent> {
+
+	@Override
+	public void onApplicationEvent(ContextRefreshedEvent event) {
+		FrameworkServlet.this.onApplicationEvent(event);
+	}
+	
+}
+```
+
+- ContextRefreshListener 是 FrameworkServlet 的内部类。
+
+- 在 `#onApplicationEvent(ContextRefreshedEvent event)` 方法中，会回调 `FrameworkServlet#onApplicationEvent(event)` 方法，代码如下：
+
+  ```
+  // FrameworkServlet.java
+  
+  public void onApplicationEvent(ContextRefreshedEvent event) {
+      // <1> 标记 refreshEventReceived 为 true
+  	this.refreshEventReceived = true;
+  	// <2> 处理事件中的 ApplicationContext 对象。这个方法，目前是空实现，由子类 DispatcherServlet 来实现。
+  	onRefresh(event.getApplicationContext());
+  }
+  ```
+
+  - `<1>` 处，标记 `refreshEventReceived` 为 `true` 。这样，在 `#initWebApplicationContext()` 方法的 `<3>` 的逻辑，就**不会**调用 `#onRefresh()` 方法。
+  - `<2>` 处，调用 `#onRefresh(ApplicationContext context)` 方法，也就回到了 [「4.5 onRefresh」](https://svip.iocoder.cn/Spring-MVC/context-init-Servlet-WebApplicationContext/#) 的逻辑了。
+
+# 666. 彩蛋
+
+舒服，真舒服。哈哈哈哈~写舒服了。
+
+参考和推荐如下文章：
+
+- 田小波 [《Spring MVC 原理探秘 - 容器的创建过程》](https://www.tianxiaobo.com/2018/06/30/Spring-MVC-原理探秘-容器的创建过程/)
+- 郝佳 [《Spring 源码深度解析》](https://item.jd.com/11311737.html) 的 [「11.3 DispatcherServlet」](https://svip.iocoder.cn/Spring-MVC/context-init-Servlet-WebApplicationContext/#) 小节
+- 韩路彪 [《看透 Spring MVC：源代码分析与实践》](https://item.jd.com/11807414.html) 的 [「第9章 创建 Spring MVC 之器」](https://svip.iocoder.cn/Spring-MVC/context-init-Servlet-WebApplicationContext/#) 小节
\ No newline at end of file
diff --git a/springmvc/06-Spring MVC 源码分析-容器的初始化（三）之 Servlet 3.0 集成.assets/F835D518-A725-40D9-84BA-6AC014DAE5A7.png b/springmvc/06-Spring MVC 源码分析-容器的初始化（三）之 Servlet 3.0 集成.assets/F835D518-A725-40D9-84BA-6AC014DAE5A7.png
new file mode 100644
index 0000000..06ad67c
Binary files /dev/null and b/springmvc/06-Spring MVC 源码分析-容器的初始化（三）之 Servlet 3.0 集成.assets/F835D518-A725-40D9-84BA-6AC014DAE5A7.png differ
diff --git a/springmvc/06-Spring MVC 源码分析-容器的初始化（三）之 Servlet 3.0 集成.assets/WebApplicationInitializer.png b/springmvc/06-Spring MVC 源码分析-容器的初始化（三）之 Servlet 3.0 集成.assets/WebApplicationInitializer.png
new file mode 100644
index 0000000..7e97d0b
Binary files /dev/null and b/springmvc/06-Spring MVC 源码分析-容器的初始化（三）之 Servlet 3.0 集成.assets/WebApplicationInitializer.png differ
diff --git a/springmvc/06-Spring MVC 源码分析-容器的初始化（三）之 Servlet 3.0 集成.assets/servlet.png b/springmvc/06-Spring MVC 源码分析-容器的初始化（三）之 Servlet 3.0 集成.assets/servlet.png
new file mode 100644
index 0000000..db2dab9
Binary files /dev/null and b/springmvc/06-Spring MVC 源码分析-容器的初始化（三）之 Servlet 3.0 集成.assets/servlet.png differ
diff --git a/springmvc/06-Spring MVC 源码分析-容器的初始化（三）之 Servlet 3.0 集成.assets/servlet_3.0.jpg b/springmvc/06-Spring MVC 源码分析-容器的初始化（三）之 Servlet 3.0 集成.assets/servlet_3.0.jpg
new file mode 100644
index 0000000..b21ff74
Binary files /dev/null and b/springmvc/06-Spring MVC 源码分析-容器的初始化（三）之 Servlet 3.0 集成.assets/servlet_3.0.jpg differ
diff --git a/springmvc/06-Spring MVC 源码分析-容器的初始化（三）之 Servlet 3.0 集成.md b/springmvc/06-Spring MVC 源码分析-容器的初始化（三）之 Servlet 3.0 集成.md
new file mode 100644
index 0000000..4f52adc
--- /dev/null
+++ b/springmvc/06-Spring MVC 源码分析-容器的初始化（三）之 Servlet 3.0 集成.md	
@@ -0,0 +1,350 @@
+# 精尽 Spring MVC 源码分析 —— 容器的初始化（三）之 Servlet 3.0 集成
+
+本文，我们直接基于徐妈的 [《Spring 揭秘 —— 寻找遗失的 web.xml》](https://www.cnkirito.moe/servlet-explore/) 的文章，一起来看看 Spring MVC 的初始化过程，是如何集成到 Servlet 3.0 和 Spring Boot 之中的。
+
+因为篇幅较长，所以捉摸了下，会拆分成两部分：
+
+- **Spring MVC 是如何集成到 Servlet 3.0 中** 【本文】
+- Spring MVC 是如何集成到 Spring Boot 中
+
+> 艿艿的吐槽：大半夜( 大概是陵城 1 点左右)，问徐妈拿这篇文章的授权，徐妈说哦了。然后问他在干嘛，竟然在写代码。可怕的 95 后啊~~~~
+
+------
+
+今天我们来放松下心情，不聊分布式，云原生，来聊一聊初学者接触的最多的 java web 基础。几乎所有人都是从 servlet，jsp，filter 开始编写自己的第一个 hello world 工程。那时，还离不开 `web.xml` 的配置，在 xml 文件中编写繁琐的 servlet 和 filter 的配置。随着 spring 的普及，配置逐渐演变成了两种方式 —— java configuration 和 xml 配置共存。现如今，springboot 的普及，java configuration 成了主流，xml 配置似乎已经“灭绝”了。不知道你有没有好奇过，这中间都发生了哪些改变，web.xml 中的配置项又是被什么替代项取代了？
+
+[![servlet](06-Spring MVC 源码分析-容器的初始化（三）之 Servlet 3.0 集成.assets/servlet.png)](http://kirito.iocoder.cn/servlet.png)servlet
+
+# 1. Servlet 3.0 以前的时代
+
+为了体现出整个演进过程，还是来回顾下 n 年前我们是怎么写 servlet 和 filter 代码的。
+
+项目结构（本文都采用 maven 项目结构）
+
+```
+.
+├── pom.xml
+├── src
+    ├── main
+    │   ├── java
+    │   │   └── moe
+    │   │       └── cnkirito
+    │   │           ├── filter
+    │   │           │   └── HelloWorldFilter.java
+    │   │           └── servlet
+    │   │               └── HelloWorldServlet.java
+    │   └── resources
+    │       └── WEB-INF
+    │           └── web.xml
+    └── test
+        └── java
+public class HelloWorldServlet extends HttpServlet {
+
+    @Override
+    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
+        resp.setContentType("text/plain");
+        PrintWriter out = resp.getWriter();
+        out.println("hello world");
+    }
+
+}
+public class HelloWorldFilter implements Filter {
+
+    @Override
+    public void init(FilterConfig filterConfig) throws ServletException {
+
+    }
+
+    @Override
+    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
+        System.out.println("触发 hello world 过滤器...");
+        filterChain.doFilter(servletRequest,servletResponse);
+    }
+
+    @Override
+    public void destroy() {
+
+    }
+}
+```
+
+别忘了在 `web.xml` 中配置 servlet 和 filter 。
+
+```
+<?xml version="1.0" encoding="UTF-8"?>
+<web-app xmlns="http://java.sun.com/xml/ns/javaee"
+           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+           xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
+        http://java.sun.com/xml/ns/javaee/web-app_4_0.xsd"
+           version="4.0">
+
+    <servlet>
+        <servlet-name>HelloWorldServlet</servlet-name>
+        <servlet-class>moe.cnkirito.servlet.HelloWorldServlet</servlet-class>
+    </servlet>
+
+    <servlet-mapping>
+        <servlet-name>HelloWorldServlet</servlet-name>
+        <url-pattern>/hello</url-pattern>
+    </servlet-mapping>
+
+    <filter>
+        <filter-name>HelloWorldFilter</filter-name>
+        <filter-class>moe.cnkirito.filter.HelloWorldFilter</filter-class>
+    </filter>
+    <filter-mapping>
+        <filter-name>HelloWorldFilter</filter-name>
+        <url-pattern>/hello</url-pattern>
+    </filter-mapping>
+
+</web-app>
+```
+
+这样，一个 java web hello world 就完成了。当然，本文不是 servlet 的入门教程，只是为了对比。
+
+# 2. Servlet 3.0 新特性
+
+[![servlet_3.0](06-Spring MVC 源码分析-容器的初始化（三）之 Servlet 3.0 集成.assets/servlet_3.0.jpg)](http://kirito.iocoder.cn/servlet_3.0.jpg)servlet_3.0
+
+Servlet 3.0 作为 Java EE 6 规范体系中一员，随着 Java EE 6 规范一起发布。该版本在前一版本（Servlet 2.5）的基础上提供了若干新特性用于简化 Web 应用的开发和部署。其中一项新特性便是提供了无 xml 配置的特性。
+
+servlet3.0 首先提供了 `@WebServlet` ，`@WebFilter` 等注解，这样便有了抛弃 `web.xml` 的第一个途径，凭借注解声明 servlet 和 filter 来做到这一点。
+
+除了这种方式，servlet3.0 规范还提供了更强大的功能，可以在运行时动态注册 servlet ，filter，listener。以 servlet 为例，过滤器与监听器与之类似。ServletContext 为动态配置 Servlet 增加了如下方法：
+
+- ServletRegistration.Dynamic addServlet(String servletName,Class<? extends Servlet> servletClass)
+- ServletRegistration.Dynamic addServlet(String servletName, Servlet servlet)
+- ServletRegistration.Dynamic addServlet(String servletName, String className)
+- T createServlet(Class clazz)
+- ServletRegistration getServletRegistration(String servletName)
+- Map<String,? extends ServletRegistration> getServletRegistrations()
+
+其中前三个方法的作用是相同的，只是参数类型不同而已；
+通过 `#createServlet(Class clazz)` 方法创建的 Servlet，通常需要做一些自定义的配置，然后使用 `#addServlet(...)` 方法来将其动态注册为一个可以用于服务的 Servlet。
+两个 `#getServletRegistration()` 方法主要用于动态为 Servlet 增加映射信息，这等价于在 `web.xml` 中使用 标签为存在的 Servlet 增加映射信息。
+
+以上 ServletContext 新增的方法：
+
+- 要么是在 `javax.servlet.ServletContextListener` 的 `#contextInitialized(ServletContextEvent sce)` 方法中调用。
+- 要么是在 `javax.servlet.ServletContainerInitializer` 的 `#onStartup(Set<Class<?>> c, ServletContext ctx)` 方法中调用。
+
+ServletContainerInitializer 也是 Servlet 3.0 新增的一个接口，容器在启动时使用 JAR 服务 API(JAR Service API) 来发现 ServletContainerInitializer 的实现类，并且容器将 `WEB-INF/lib` 目录下 JAR 包中的类都交给该类的 `#onStartup(...)` 方法处理，我们通常需要在该实现类上使用 `@HandlesTypes` 注解来指定希望被处理的类，过滤掉不希望给 `#onStartup(...)` 处理的类。
+
+一个典型的 servlet3.0+ 的 web 项目结构如下：
+
+```
+.
+├── pom.xml
+└── src
+    ├── main
+    │   ├── java
+    │   │   └── moe
+    │   │       └── cnkirito
+    │   │           ├── CustomServletContainerInitializer.java
+    │   │           ├── filter
+    │   │           │   └── HelloWorldFilter.java
+    │   │           └── servlet
+    │   │               └── HelloWorldServlet.java
+    │   └── resources
+    │       └── META-INF
+    │           └── services
+    │               └── javax.servlet.ServletContainerInitializer
+    └── test
+        └── java
+```
+
+我并未对 HelloWorldServlet 和 HelloWorldFilter 做任何改动，而是新增了一个 CustomServletContainerInitializer ,它实现了 `javax.servlet.ServletContainerInitializer` 接口，用来在 web 容器启动时加载指定的 servlet 和 filter，代码如下：
+
+```
+public class CustomServletContainerInitializer implements ServletContainerInitializer {
+
+	private final static String JAR_HELLO_URL = "/hello";
+	
+	@Override
+	  public void onStartup(Set<Class<?>> c, ServletContext servletContext) {
+	  
+		System.out.println("创建 helloWorldServlet...");
+		
+		ServletRegistration.Dynamic servlet = servletContext.addServlet(
+		            HelloWorldServlet.class.getSimpleName(),
+		            HelloWorldServlet.class);
+		servlet.addMapping(JAR_HELLO_URL);
+		
+		System.out.println("创建 helloWorldFilter...");
+		
+		FilterRegistration.Dynamic filter = servletContext.addFilter(
+		            HelloWorldFilter.class.getSimpleName(), HelloWorldFilter.class);
+		EnumSet<DispatcherType> dispatcherTypes = EnumSet.allOf(DispatcherType.class);
+		dispatcherTypes.add(DispatcherType.REQUEST);
+		dispatcherTypes.add(DispatcherType.FORWARD);
+		filter.addMappingForUrlPatterns(dispatcherTypes, true, JAR_HELLO_URL);
+	}
+	
+}
+```
+
+对上述代码进行一些解读。ServletContext 我们称之为 servlet 上下文，它维护了整个 web 容器中注册的 servlet，filter，listener，以 servlet 为例，可以使用 `servletContext.addServlet` 等方法来添加 servlet。而方法入参中 `Set<Class<?>> c` 和 `@HandlesTypes` 注解在 demo 中我并未使用，感兴趣的朋友可以 debug 看看到底获取了哪些 class ，一般正常的流程是使用 `@HandlesTypes` 指定需要处理的 class，而后对 `Set<Class<?>>` 进行判断是否属于该 class，正如前文所言，`#onStartup(...)` 会加载不需要被处理的一些 class。
+
+这么声明一个 ServletContainerInitializer 的实现类，web 容器并不会识别它，所以，需要借助 SPI 机制来指定该初始化类，这一步骤是通过在项目路径下创建 `META-INF/services/javax.servlet.ServletContainerInitializer` 来做到的，它只包含一行内容：
+
+```
+moe.cnkirito.CustomServletContainerInitializer
+```
+
+使用 ServletContainerInitializer 和 SPI 机制，我们的 web 应用便可以彻底摆脱 `web.xml` 了。
+
+# 3. Spring 是如何支持 Servlet 3.0 的？
+
+回到我们的 spring 全家桶，可能已经忘了具体是什么时候开始不写 web.xml 了，我只知道现在的项目已经再也看不到它了，spring 又是如何支持 servlet3.0 规范的呢？
+
+寻找 spring 中 ServletContainerInitializer 的实现类并不困难，可以迅速定位到 `org.springframework.web.SpringServletContainerInitializer` 该实现类。
+
+```
+@HandlesTypes(WebApplicationInitializer.class)
+public class SpringServletContainerInitializer implements ServletContainerInitializer {
+
+    @Override
+	public void onStartup(Set<Class<?>> webAppInitializerClasses, ServletContext servletContext)
+			throws ServletException {
+
+		List<WebApplicationInitializer> initializers = new LinkedList<WebApplicationInitializer>();
+
+		if (webAppInitializerClasses != null) {
+			for (Class<?> waiClass : webAppInitializerClasses) {
+				// Be defensive: Some servlet containers provide us with invalid classes,
+				// no matter what @HandlesTypes says...
+                // <1>
+				if (!waiClass.isInterface() && !Modifier.isAbstract(waiClass.getModifiers()) &&
+						WebApplicationInitializer.class.isAssignableFrom(waiClass)) {
+					try {
+						initializers.add((WebApplicationInitializer) waiClass.newInstance());
+					}
+					catch (Throwable ex) {
+						throw new ServletException("Failed to instantiate WebApplicationInitializer class", ex);
+					}
+				}
+			}
+		}
+
+		if (initializers.isEmpty()) {
+			servletContext.log("No Spring WebApplicationInitializer types detected on classpath");
+			return;
+		}
+
+		servletContext.log(initializers.size() + " Spring WebApplicationInitializers detected on classpath");
+		AnnotationAwareOrderComparator.sort(initializers);
+        // <2>
+		for (WebApplicationInitializer initializer : initializers) {
+			initializer.onStartup(servletContext);
+		}
+	}
+}
+```
+
+查看其 java doc，描述如下：
+
+> Servlet 3.0 {@link ServletContainerInitializer} designed to support code-based configuration of the servlet container using Spring’s {@link WebApplicationInitializer} SPI as opposed to (or possibly in combination with) the traditional {@code web.xml}-based approach.
+
+注意我在源码中标注两个序号，这对于我们理解 spring 装配 servlet 的流程来说非常重要。
+
+- `<1>` 英文注释是 spring 源码中自带的，它提示我们由于 servlet 厂商实现的差异，onStartup 方法会加载我们本不想处理的 class，所以进行了特判。**另外，也要注意下 `@HandlesTypes(WebApplicationInitializer.class)` 注解**，如果厂商正确的实现 `@HandlesTypes` 的逻辑，传入的 `Set<Class<?>> webAppInitializerClasses` 都是 WebApplicationInitializer 对象。
+
+- `<2>` spring 与我们之前的 demo 不同，并没有在 SpringServletContainerInitializer 中直接对 servlet 和 filter 进行注册，而是委托给了一个陌生的类 `org.springframework.web.WebApplicationInitializer` 。WebApplicationInitializer 类便是 spring 用来初始化 web 环境的委托者类，它通常有三个实现类：
+
+  [![WebApplicationInitializer](06-Spring MVC 源码分析-容器的初始化（三）之 Servlet 3.0 集成.assets/WebApplicationInitializer.png)](http://kirito.iocoder.cn/WebApplicationInitializer.png)WebApplicationInitializer
+
+你一定不会对 DispatcherServlet 感到陌生，`AbstractDispatcherServletInitializer#registerDispatcherServlet` 便是无 `web.xml` 前提下创建 DispatcherServlet 的关键代码。代码如下：
+
+```
+// AbstractDispatcherServletInitializer.java
+
+@Override
+public void onStartup(ServletContext servletContext) throws ServletException {
+    // 调用父类启动的逻辑
+    super.onStartup(servletContext);
+    // 注册 DispacherServlt
+    registerDispatcherServlet(servletContext);
+}
+
+protected void registerDispatcherServlet(ServletContext servletContext) {
+    // 获得 Servlet 名
+    String servletName = getServletName();
+    Assert.hasLength(servletName, "getServletName() must not return null or empty");
+
+    // <1> 创建 WebApplicationContext 对象
+    WebApplicationContext servletAppContext = createServletApplicationContext();
+    Assert.notNull(servletAppContext, "createServletApplicationContext() must not return null");
+
+    // <2> 创建 FrameworkServlet 对象
+    FrameworkServlet dispatcherServlet = createDispatcherServlet(servletAppContext);
+    Assert.notNull(dispatcherServlet, "createDispatcherServlet(WebApplicationContext) must not return null");
+    dispatcherServlet.setContextInitializers(getServletApplicationContextInitializers());
+
+	ServletRegistration.Dynamic registration = servletContext.addServlet(servletName, dispatcherServlet);
+	if (registration == null) {
+		throw new IllegalStateException("Failed to register servlet with name '" + servletName + "'. " +
+				"Check if there is another servlet registered under the same name.");
+	}
+
+	registration.setLoadOnStartup(1);
+	registration.addMapping(getServletMappings());
+	registration.setAsyncSupported(isAsyncSupported());
+
+	// <3> 注册过滤器    
+	Filter[] filters = getServletFilters();
+	if (!ObjectUtils.isEmpty(filters)) {
+		for (Filter filter : filters) {
+			registerServletFilter(servletContext, filter);
+		}
+	}
+
+	customizeRegistration(registration);
+}
+```
+
+- `<1>` 处，调用 `#createServletApplicationContext()` 方法，创建 WebApplicationContext 对象。代码如下：
+
+  ```
+  // AbstractAnnotationConfigDispatcherServletInitializer.java
+  
+  @Override
+  protected WebApplicationContext createServletApplicationContext() {
+  	AnnotationConfigWebApplicationContext context = new AnnotationConfigWebApplicationContext();
+  	Class<?>[] configClasses = getServletConfigClasses();
+  	if (!ObjectUtils.isEmpty(configClasses)) {
+  		context.register(configClasses);
+  	}
+  	return context;
+  }
+  ```
+
+  - 该方法由子类 AbstractAnnotationConfigDispatcherServletInitializer 重写，并且创建的 WebApplicationContext 的子类 AnnotationConfigWebApplicationContext 对象。
+
+- `<2>` 处，调用 `#createDispatcherServlet(WebApplicationContext servletAppContext)` 方法，创建 FrameworkServlet 对象。代码如下：
+
+  ```
+  // AbstractDispatcherServletInitializer.java
+  
+  protected FrameworkServlet createDispatcherServlet(WebApplicationContext servletAppContext) {
+  	return new DispatcherServlet(servletAppContext);
+  }
+  ```
+
+  - 创建 FrameworkServlet 的子类 DispatcherServlet 对象。
+  - 另外，比较有趣的是传入的 `servletAppContext` 方法参数，这就是该 DispatcherServlet 的 **Servlet WebApplicationContext 容器**啊。
+
+------
+
+然后，我们可以去项目中寻找一下 `org.springframework:spring-web:version` 的依赖，它下面就存在一个 ServletContainerInitializer 的扩展，指向了 SpringServletContainerInitializer，这样只要在 servlet 3.0 环境下部署，spring 便可以自动加载进行初始化：
+
+[![SpringServletContainerInitializer](06-Spring MVC 源码分析-容器的初始化（三）之 Servlet 3.0 集成.assets/F835D518-A725-40D9-84BA-6AC014DAE5A7.png)](http://kirito.iocoder.cn/F835D518-A725-40D9-84BA-6AC014DAE5A7.png)SpringServletContainerInitializer
+
+注意，上述这一切特性从 spring 3 就已经存在了，而如今 spring 5 已经伴随 springboot 2.0 一起发行了。
+
+# 666. 彩蛋
+
+因为有胖友可能不熟悉 Java SPI 机制，所以推荐阅读徐妈的 [《JAVA拾遗 —— 关于SPI机制》](https://www.cnkirito.moe/spi/) 。
+
+感谢徐妈给的这篇文章的授权，使我能够完美的进行偷懒，哈哈哈哈。
+
+文章可能信息量比较大，如果有疑问的地方，请在知识星球留言，我们一起讨论。
\ No newline at end of file
diff --git a/springmvc/07-Spring MVC 源码分析-容器的初始化（四）之 Spring Boot 集成.assets/01.png b/springmvc/07-Spring MVC 源码分析-容器的初始化（四）之 Spring Boot 集成.assets/01.png
new file mode 100644
index 0000000..0002fb8
Binary files /dev/null and b/springmvc/07-Spring MVC 源码分析-容器的初始化（四）之 Spring Boot 集成.assets/01.png differ
diff --git a/springmvc/07-Spring MVC 源码分析-容器的初始化（四）之 Spring Boot 集成.assets/35560726-DD9D-478A-BFCA-12ACF4DB497D.png b/springmvc/07-Spring MVC 源码分析-容器的初始化（四）之 Spring Boot 集成.assets/35560726-DD9D-478A-BFCA-12ACF4DB497D.png
new file mode 100644
index 0000000..47e17dd
Binary files /dev/null and b/springmvc/07-Spring MVC 源码分析-容器的初始化（四）之 Spring Boot 集成.assets/35560726-DD9D-478A-BFCA-12ACF4DB497D.png differ
diff --git a/springmvc/07-Spring MVC 源码分析-容器的初始化（四）之 Spring Boot 集成.assets/8FFCA673-DB72-4C0A-BDE9-58CB4B80C484.png b/springmvc/07-Spring MVC 源码分析-容器的初始化（四）之 Spring Boot 集成.assets/8FFCA673-DB72-4C0A-BDE9-58CB4B80C484.png
new file mode 100644
index 0000000..fa87c7d
Binary files /dev/null and b/springmvc/07-Spring MVC 源码分析-容器的初始化（四）之 Spring Boot 集成.assets/8FFCA673-DB72-4C0A-BDE9-58CB4B80C484.png differ
diff --git a/springmvc/07-Spring MVC 源码分析-容器的初始化（四）之 Spring Boot 集成.assets/RegistrationBean.png b/springmvc/07-Spring MVC 源码分析-容器的初始化（四）之 Spring Boot 集成.assets/RegistrationBean.png
new file mode 100644
index 0000000..88ea2a5
Binary files /dev/null and b/springmvc/07-Spring MVC 源码分析-容器的初始化（四）之 Spring Boot 集成.assets/RegistrationBean.png differ
diff --git a/springmvc/07-Spring MVC 源码分析-容器的初始化（四）之 Spring Boot 集成.assets/TomcatStarter.png b/springmvc/07-Spring MVC 源码分析-容器的初始化（四）之 Spring Boot 集成.assets/TomcatStarter.png
new file mode 100644
index 0000000..58dab1a
Binary files /dev/null and b/springmvc/07-Spring MVC 源码分析-容器的初始化（四）之 Spring Boot 集成.assets/TomcatStarter.png differ
diff --git a/springmvc/07-Spring MVC 源码分析-容器的初始化（四）之 Spring Boot 集成.md b/springmvc/07-Spring MVC 源码分析-容器的初始化（四）之 Spring Boot 集成.md
new file mode 100644
index 0000000..9d65a39
--- /dev/null
+++ b/springmvc/07-Spring MVC 源码分析-容器的初始化（四）之 Spring Boot 集成.md	
@@ -0,0 +1,443 @@
+# 精尽 Spring MVC 源码分析 —— 容器的初始化（四）之 Spring Boot 集成
+
+本文，我们继续接 [《精尽 Spring MVC 源码分析 —— 容器的初始化（三）之 Servlet 3.0 集成》](http://svip.iocoder.cn/Spring-MVC/context-init-integration-with-Servlet-3.0) 一文，来分享 **Spring MVC 是如何集成到 Spring Boot 中**的。当然，还是基于徐妈的 [《Spring 揭秘 —— 寻找遗失的 web.xml》](https://www.cnkirito.moe/servlet-explore/) 的文章。
+
+> 艿艿的吐槽：为什么徐妈如此的吊呢？
+
+# 1. Spring Boot 如何加载 Servlet？
+
+读到这儿，你已经阅读了全文的 1/2。Spring Boot 对于 servlet 的处理才是重头戏：
+
+- 其一，是因为 Spring Boot 使用范围很广，很少有人用 spring 而不用 Spring Boot 了。
+- 其二，是因为它没有完全遵守 Servlet3.0 的规范！
+
+是的，前面所讲述的 servlet 的规范，无论是 `web.xml` 中的配置，还是 servlet3.0 中的 ServletContainerInitializer 和 Spring Boot 的加载流程都没有太大的关联。按照惯例，先卖个关子，先看看如何在 Spring Boot 中注册 servlet 和 filter，再来解释下 Spring Boot 的**独特**之处。
+
+## 1.1 注册方式一：Servlet 3.0 注解 + @ServletComponentScan
+
+Spring Boot 依旧兼容 Servlet 3.0 一系列以 `@Web*` 开头的注解：`@WebServlet`，`@WebFilter`，`@WebListener` 。
+
+```
+@WebServlet("/hello")
+public class HelloWorldServlet extends HttpServlet{}
+@WebFilter("/hello/*")
+public class HelloWorldFilter implements Filter {}
+```
+
+不要忘记让启动类去扫描到这些注解
+
+```
+@SpringBootApplication
+@ServletComponentScan
+public class SpringBootServletApplication {
+
+   public static void main(String[] args) {
+      SpringApplication.run(SpringBootServletApplication.class, args);
+   }
+}
+```
+
+我认为这是几种方式中最为简洁的方式，如果真的有特殊需求，需要在 Spring Boot 下注册 servlet，filter，可以采用这样的方式，比较直观。
+
+另外，`@ServletComponentScan` 在 `org.springframework.boot.web.servlet` 包下。
+
+> 艿艿的提示：关于这种注册方式的实现，本文不会细讲。
+>
+> 大体原理，`@ServletComponentScan` 注解上的 `@Import(ServletComponentScanRegistrar.class)` ，它会将扫描到的 `@WebServlet`、`@WebFilter`、`@WebListener` 的注解对应的类，最终封装成 FilterRegistrationBean、ServletRegistrationBean、ServletListenerRegistrationBean 对象，注册到 Spring 容器中。也就是说，**和注册方式二：RegistrationBean 统一了**。
+
+## 1.2 注册方式二：RegistrationBean
+
+```
+@Bean
+public ServletRegistrationBean helloWorldServlet() {
+    ServletRegistrationBean helloWorldServlet = new ServletRegistrationBean();
+    myServlet.addUrlMappings("/hello");
+    myServlet.setServlet(new HelloWorldServlet());
+    return helloWorldServlet;
+}
+
+@Bean
+public FilterRegistrationBean helloWorldFilter() {
+    FilterRegistrationBean helloWorldFilter = new FilterRegistrationBean();
+    myFilter.addUrlPatterns("/hello/*");
+    myFilter.setFilter(new HelloWorldFilter());
+    return helloWorldFilter;
+}
+```
+
+ServletRegistrationBean 和 FilterRegistrationBean 都集成自 RegistrationBean ，RegistrationBean 是 Spring Boot 中广泛应用的一个注册类，负责把 servlet，filter，listener 给容器化，使他们被 Spring 托管，并且完成自身对 Web 容器的注册。这种注册方式也值得推崇。
+
+[![RegistrationBean](07-Spring MVC 源码分析-容器的初始化（四）之 Spring Boot 集成.assets/RegistrationBean.png)](http://kirito.iocoder.cn/RegistrationBean.png)RegistrationBean
+
+从图中可以看出 RegistrationBean 的地位，它的几个实现类作用分别是：
+
+- 前三个，帮助容器注册 filter，servlet，listener 。
+- 最后的 DelegatingFilterProxyRegistrationBean 使用的不多，但熟悉 Spring Security 的朋友不会感到陌生，SpringSecurityFilterChain 就是通过这个代理类来调用的。
+- 另外 RegistrationBean 实现了 ServletContextInitializer 接口，这个接口将会是下面分析的核心接口，大家先混个眼熟，了解下它有一个抽象实现 RegistrationBean 即可。
+
+# 2. SpringBoot 中 Servlet 加载流程的源码分析
+
+暂时只介绍这两种方式，下面解释下之前卖的关子，为什么说 Spring Boot 没有完全遵守 servlet3.0 规范。讨论的前提是 Spring Boot 环境下使用**内嵌**的容器，比如最典型的 Tomcat 。
+
+高能预警，以下内容比较烧脑，觉得看起来吃力的朋友可以跳过本节直接看下一节的总结！
+
+> 艿艿的吐槽：徐妈牛逼！！！
+
+## 2.1 Initializer 被替换为 TomcatStarter
+
+当使用内嵌的 Tomcat 时，你会发现 Spring Boot 完全走了另一套初始化流程，完全没有使用前面提到的 SpringServletContainerInitializer ，实际上一开始我在各种 ServletContainerInitializer 的实现类中打了断点，最终定位到，根本没有运行到 SpringServletContainerInitializer 内部，**而是进入了 `org.springframework.boot.web.embedded.tomcat.TomcatStarter` 这个类中**。
+
+[![TomcatStarter](07-Spring MVC 源码分析-容器的初始化（四）之 Spring Boot 集成.assets/TomcatStarter.png)](http://kirito.iocoder.cn/TomcatStarter.png)TomcatStarter
+
+并且，仔细扫了一眼源码的包，并没有发现有 SPI 文件对应到 TomcatStarter。于是我猜想，**内嵌 Tomcat 的加载可能不依赖于 Servlet3.0 规范和 SPI** ！它完全走了一套独立的逻辑。为了验证这一点，我翻阅了 Spring Github 中的 issue，得到了 Spring 作者**肯定**的答复：https://github.com/spring-projects/spring-boot/issues/321
+
+> This was actually an intentional design decision. The search algorithm used by the containers was problematic. It also causes problems when you want to develop an executable WAR as you often want a `javax.servlet.ServletContainerInitializer` for the WAR that is not executed when you run `java -jar`.
+>
+> See the `org.springframework.boot.context.embedded.ServletContextInitializer` for an option that works with Spring Beans.
+
+Spring Boot 这么做是**有意**而为之。Spring Boot 考虑到了如下的问题，我们在使用 Spring Boot 时，开发阶段一般都是使用内嵌 Tomcat 容器，但部署时却存在两种选择：一种是打成 jar 包，使用 `java -jar` 的方式运行；另一种是打成 war 包，交给外置容器去运行。
+
+**前者就会导致容器搜索算法出现问题，因为这是 jar 包的运行策略，不会按照 Servlet 3.0 的策略去加载 ServletContainerInitializer**！
+
+最后作者还提供了一个替代选项：Servlet**Context**Initializer，注意是 Servlet**Context**Initializer ！它和 Servlet**Container**Initializer 长得特别像，别搞混淆了！
+
+- 前者 ServletContextInitializer 是 `org.springframework.boot.web.servlet.ServletContextInitializer` 。
+- 后者 ServletContainerInitializer 是 `javax.servlet.ServletContainerInitializer` 。前文还提到 RegistrationBean 实现了 ServletContextInitializer 接口。
+
+## 2.2 TomcatStarter 中的 ServletContextInitializer 是关键
+
+TomcatStarter 中 `org.springframework.boot.context.embedded.ServletContextInitializer[] initializers` 属性，是 Spring Boot 初始化 servlet，filter，listener 的关键。代码如下：
+
+```
+class TomcatStarter implements ServletContainerInitializer {
+
+   private final ServletContextInitializer[] initializers;
+
+   TomcatStarter(ServletContextInitializer[] initializers) {
+      this.initializers = initializers;
+   }
+
+   @Override
+   public void onStartup(Set<Class<?>> classes, ServletContext servletContext) throws ServletException {
+         for (ServletContextInitializer initializer : this.initializers) {
+            initializer.onStartup(servletContext);
+         }
+   }
+   
+}
+```
+
+经过删减源码后，可以看出 TomcatStarter 的主要逻辑，它其实就是负责调用一系列 ServletContextInitializer 的 `#onStartup(ServletContext servletContext)` 方法，那么在 debug 中，`ServletContextInitializer[] initializers` 到底包含了哪些类呢？会不会有我们前面介绍的 RegistrationBean 呢？
+
+[![initializers](07-Spring MVC 源码分析-容器的初始化（四）之 Spring Boot 集成.assets/35560726-DD9D-478A-BFCA-12ACF4DB497D.png)](http://kirito.iocoder.cn/35560726-DD9D-478A-BFCA-12ACF4DB497D.png)initializers
+
+太天真了，RegistrationBean 并没有出现在 TomcatStarter 的 debug 信息中，`initializers` 只包含了三个类，其中只有第一个类看上去比较核心，注意第一个类不是 EmbeddedWebApplicationContext ！而是这个类中的 `$1` 匿名类，为了搞清楚 Spring Boot 如何加载 filter、servlet、listener ，看来还得研究下 EmbeddedWebApplicationContext 的结构。
+
+> 艿艿的友情提示：
+>
+> 徐妈是基于 Spring Boot 1.5 的版本做的整体分析，要稍微注意下。
+>
+> 如果胖友是使用 Spring Boot 2.0 进行调试的，和本文在具体的实现类会有一些差异。当然，内核不变，胖友可以和艿艿一样对照着看。例如，EmbeddedWebApplicationContext 的逻辑，应该是修改到了 ServletWebServerApplicationContext 中。
+
+## 2.3 EmbeddedWebApplicationContext 中的 6 层迭代加载
+
+ApplicationContext 大家应该是比较熟悉的，这是 spring 一个比较核心的类，一般我们可以从中获取到那些注册在容器中的托管 Bean，而这篇文章，主要分析的便是它在内嵌容器中的实现类：`org.springframework.boot.context.embedded.EmbeddedWebApplicationContext` ，重点分析它加载 filter servlet listener 这部分的代码。**这里是整个代码中迭代层次最深的部分，做好心理准备起航**，来看看 EmbeddedWebApplicationContext 是怎么获取到所有的 servlet、filter、listener 的！以下方法均出自于 EmbeddedWebApplicationContext 。
+
+**第一层：onRefresh()**
+
+`#onRefresh()` 方法，是 ApplicationContext 的生命周期方法，EmbeddedWebApplicationContext 的实现非常简单，只干了一件事：
+
+```
+@Override
+protected void onRefresh() {
+   super.onRefresh();
+   try {
+      createEmbeddedServletContainer(); //第二层的入口
+   } catch (Throwable ex) {
+      throw new ApplicationContextException("Unable to start embedded container",
+            ex);
+   }
+}
+```
+
+- 调用 `#createEmbeddedServletContainer()` 方法，连接到了第二层。
+
+**第二层：createEmbeddedServletContainer()**
+
+看名字 Spring 是想创建一个内嵌的 Servlet 容器，ServletContainer 其实就是 servlet、filter、listener 的总称。
+
+```
+private void createEmbeddedServletContainer() {
+   EmbeddedServletContainer localContainer = this.embeddedServletContainer;
+   ServletContext localServletContext = getServletContext();
+   if (localContainer == null && localServletContext == null) {
+      EmbeddedServletContainerFactory containerFactory = getEmbeddedServletContainerFactory();
+      this.embeddedServletContainer = containerFactory
+            .getEmbeddedServletContainer(getSelfInitializer()); // 第三层的入口
+   } else if (localServletContext != null) {
+      try {
+         getSelfInitializer().onStartup(localServletContext);
+      } catch (ServletException ex) {
+         throw new ApplicationContextException("Cannot initialize servlet context",
+               ex);
+      }
+   }
+   initPropertySources();
+}
+```
+
+- 凡是带有 servlet，initializer 字样的方法，都是我们需要留意的。其中 `#getSelfInitializer()` 方法，便涉及到了我们最为关心的初始化流程，所以接着连接到了第三层。
+
+**第三层：getSelfInitializer()**
+
+```
+private org.springframework.boot.web.servlet.ServletContextInitializer getSelfInitializer() {
+   return new ServletContextInitializer() {
+   
+      @Override
+      public void onStartup(ServletContext servletContext) throws ServletException {
+         selfInitialize(servletContext);
+      }
+      
+   };
+}
+
+private void selfInitialize(ServletContext servletContext) throws ServletException {
+   prepareEmbeddedWebApplicationContext(servletContext);
+   ConfigurableListableBeanFactory beanFactory = getBeanFactory();
+   ExistingWebApplicationScopes existingScopes = new ExistingWebApplicationScopes(
+         beanFactory);
+   WebApplicationContextUtils.registerWebApplicationScopes(beanFactory,
+         getServletContext());
+   existingScopes.restore();
+   WebApplicationContextUtils.registerEnvironmentBeans(beanFactory,
+         getServletContext());
+   // 第四层的入口
+   for (ServletContextInitializer beans : getServletContextInitializerBeans()) {
+      beans.onStartup(servletContext);
+   }
+}
+```
+
+还记得前面 TomcatStarter 的 debug 信息中，第一个 ServletContextInitializer 就是出现在 EmbeddedWebApplicationContext 中的一个匿名类，没错了，就是这里的 `#getSelfInitializer()` 方法创建的！
+
+解释下这里的 `#getSelfInitializer()` 和 `#selfInitialize(ServletContext servletContext)` 方法，**为什么要这么设计**？
+这是典型的**回调式**方式，当匿名 ServletContextInitializer 类被 TomcatStarter 的 `#onStartup()` 方法调用，设计上是触发了 `#selfInitialize(ServletContext servletContext)` 方法的调用。
+所以这下就清晰了，为什么 TomcatStarter 中没有出现 RegistrationBean ，其实是隐式触发了 EmbeddedWebApplicationContext 中的 `#selfInitialize(ServletContext servletContext)` 方法。这样，`#selfInitialize(ServletContext servletContext)` 方法中，调用 `#getServletContextInitializerBeans()` 方法，获得 ServletContextInitializer 数组就成了关键。😈所以接着连接到了第四层。
+
+**第四层：getServletContextInitializerBeans()**
+
+```
+/**
+ * Returns {@link ServletContextInitializer}s that should be used with the embedded
+ * Servlet context. By default this method will first attempt to find
+ * {@link ServletContextInitializer}, {@link Servlet}, {@link Filter} and certain
+ * {@link EventListener} beans.
+ * @return the servlet initializer beans
+ */
+protected Collection<ServletContextInitializer> getServletContextInitializerBeans() {
+   return new ServletContextInitializerBeans(getBeanFactory()); //第五层的入口
+}
+```
+
+没错了，注释都告诉我们，这个 ServletContextInitializerBeans 类，就是用来加载 Servlet 和 Filter 的。
+
+**第五层：ServletContextInitializerBeans 的构造方法**
+
+```
+public ServletContextInitializerBeans(ListableBeanFactory beanFactory) {
+   this.initializers = new LinkedMultiValueMap<Class<?>, ServletContextInitializer>();
+   addServletContextInitializerBeans(beanFactory); // 第六层的入口
+   addAdaptableBeans(beanFactory);
+   List<ServletContextInitializer> sortedInitializers = new ArrayList<ServletContextInitializer>();
+   for (Map.Entry<?, List<ServletContextInitializer>> entry : this.initializers
+         .entrySet()) {
+      AnnotationAwareOrderComparator.sort(entry.getValue());
+      sortedInitializers.addAll(entry.getValue());
+   }
+   this.sortedList = Collections.unmodifiableList(sortedInitializers);
+}
+```
+
+**第六层：addServletContextInitializerBeans(beanFactory)**
+
+```
+// ServletContextInitializerBeans.java
+
+private void addServletContextInitializerBeans(ListableBeanFactory beanFactory) {
+   for (Entry<String, ServletContextInitializer> initializerBean : getOrderedBeansOfType(
+         beanFactory, ServletContextInitializer.class)) {
+      addServletContextInitializerBean(initializerBean.getKey(),
+            initializerBean.getValue(), beanFactory);
+   }
+}
+```
+
+- 调用 `#getOrderedBeansOfType( beanFactory, ServletContextInitializer.class)` 方法，便是去容器中寻找注册过得 ServletContextInitializer ，这时候就可以把之前那些 RegistrationBean 全部加载出来了。并且 RegistrationBean 还实现了 Ordered 接口，在这儿用于排序。
+
+- 后续的 `#addServletContextInitializerBean(ListableBeanFactory beanFactory)` 方法，胖友可以自己去瞅瞅。代码如下：
+
+  ```
+  // ServletContextInitializerBeans.java
+  
+  private void addServletContextInitializerBeans(ListableBeanFactory beanFactory) {
+  	for (Entry<String, ServletContextInitializer> initializerBean : getOrderedBeansOfType(
+  			beanFactory, ServletContextInitializer.class)) {
+  		addServletContextInitializerBean(initializerBean.getKey(),
+  				initializerBean.getValue(), beanFactory);
+  	}
+  }
+  
+  private void addServletContextInitializerBean(String beanName,
+  		ServletContextInitializer initializer, ListableBeanFactory beanFactory) {
+  	if (initializer instanceof ServletRegistrationBean) {
+  		Servlet source = ((ServletRegistrationBean<?>) initializer).getServlet();
+  		addServletContextInitializerBean(Servlet.class, beanName, initializer,
+  				beanFactory, source);
+  	} else if (initializer instanceof FilterRegistrationBean) {
+  		Filter source = ((FilterRegistrationBean<?>) initializer).getFilter();
+  		addServletContextInitializerBean(Filter.class, beanName, initializer,
+  				beanFactory, source);
+  	} else if (initializer instanceof DelegatingFilterProxyRegistrationBean) {
+  		String source = ((DelegatingFilterProxyRegistrationBean) initializer)
+  				.getTargetBeanName();
+  		addServletContextInitializerBean(Filter.class, beanName, initializer,
+  				beanFactory, source);
+  	} else if (initializer instanceof ServletListenerRegistrationBean) {
+  		EventListener source = ((ServletListenerRegistrationBean<?>) initializer)
+  				.getListener();
+  		addServletContextInitializerBean(EventListener.class, beanName, initializer,
+  				beanFactory, source);
+  	} else {
+  		addServletContextInitializerBean(ServletContextInitializer.class, beanName,
+  				initializer, beanFactory, initializer);
+  	}
+  }
+  ```
+
+  - 粗略看了一眼，各种 RegistrationBean 的处理。
+
+> 艿艿：涉及的东西，其实比较多，胖友可以多多调试理解。不说了，艿艿要继续调试了。
+
+# 3. EmbeddedWebApplicationContext加载流程总结
+
+如果你对具体的代码流程不感兴趣，可以跳过上述的 6 层分析，直接看本节的结论。总结如下：
+
+- EmbeddedWebApplicationContext 的 `#onRefresh()` 方法，触发配置了一个匿名的 ServletContextInitializer 。
+- 这个匿名的 ServletContextInitializer 的 `onStartup(ServletContext servletContext)` 方法，会去容器中搜索到了所有的 RegistrationBean ，并按照顺序加载到 ServletContext 中。
+- 这个匿名的 ServletContextInitializer 最终传递给 TomcatStarter，由 TomcatStarter 的 onStartup 方法去触发 ServletContextInitializer 的 `#onStartup(ServletContext servletContext)` 方法，最终完成装配！
+
+[![getServletContextInitializerBeans](07-Spring MVC 源码分析-容器的初始化（四）之 Spring Boot 集成.assets/8FFCA673-DB72-4C0A-BDE9-58CB4B80C484.png)](http://kirito.iocoder.cn/8FFCA673-DB72-4C0A-BDE9-58CB4B80C484.png)getServletContextInitializerBeans
+
+# 4. 第三种注册 Servlet 的方式
+
+> 艿艿的吐槽：徐妈的脑洞，真大~
+
+研究完了上述 Spring Boot 启动的内部原理，可以发现 ServletContextInitializer 其实是 Spring 中 ServletContainerInitializer 的代理，虽然 Spring Boot 中 Servlet3.0 不起作用了，但它的代理还是会被加载的，于是我们有了第三种方式注册 Servlet。代码如下：
+
+```
+@Configuration
+public class CustomServletContextInitializer implements ServletContextInitializer {
+
+    private final static String JAR_HELLO_URL = "/hello";
+
+    @Override
+    public void onStartup(ServletContext servletContext) throws ServletException {
+        System.out.println("创建 helloWorldServlet...");
+
+        ServletRegistration.Dynamic servlet = servletContext.addServlet(
+                HelloWorldServlet.class.getSimpleName(),
+                HelloWorldServlet.class);
+        servlet.addMapping(JAR_HELLO_URL);
+
+        System.out.println("创建 helloWorldFilter...");
+
+        FilterRegistration.Dynamic filter = servletContext.addFilter(
+                HelloWorldFilter.class.getSimpleName(), HelloWorldFilter.class);
+
+        EnumSet<DispatcherType> dispatcherTypes = EnumSet.allOf(DispatcherType.class);
+        dispatcherTypes.add(DispatcherType.REQUEST);
+        dispatcherTypes.add(DispatcherType.FORWARD);
+
+        filter.addMappingForUrlPatterns(dispatcherTypes, true, JAR_HELLO_URL);
+    }
+}
+```
+
+虽然 ServletContainerInitializer 不能被内嵌容器加载，ServletContextInitializer 却能被 Spring Boot 的 EmbeddedWebApplicationContext 加载到，从而装配其中的 servlet 和 filter。
+
+实际开发中，还是以一，二两种方法来注册为主，这里只是提供一个可能性，来让我们理解 Spring Boot 的加载流程。
+
+> 艿艿的说法：徐妈的意思，就是这个方式，请无视。哈哈哈哈哈。不过，其实是简单的。嘿嘿
+
+# 5. 加载流程拾遗
+
+## 5.1 TomcatStarter 既然不是通过 SPI 机制装配的，那是怎么被 Spring 使用的？
+
+自然是被 `new` 出来的。在 `TomcatEmbeddedServletContainerFactory#configureContext(Context context, ServletContextInitializer[] initializers)` 方法中可以看到，TomcatStarter 是被主动实例化出来的，并且还传入了 ServletContextInitializer 的数组，和上面分析的一样，一共有三个 ServletContextInitializer，包含了 EmbeddedWebApplicationContext 中的匿名实现。
+
+```
+// TomcatEmbeddedServletContainerFactory.java
+
+protected void configureContext(Context context,
+      ServletContextInitializer[] initializers) {
+   // <1> 
+   TomcatStarter starter = new TomcatStarter(initializers);
+   // <2>
+   if (context instanceof TomcatEmbeddedContext) {
+      // Should be true
+      ((TomcatEmbeddedContext) context).setStarter(starter);
+   }
+   context.addServletContainerInitializer(starter, NO_CLASSES);
+   // ... 省略无关代码
+}
+```
+
+- `<1>` 处，创建了 TomcatStarter 对象。
+- 【关键】`<2>` 处，通过 `context instanceof TomcatEmbeddedContext` 判断使用的是**内嵌**的 Tomcat ，所以将 TomcatStarter 作为 Initializer 。后续的逻辑，就变成了 [《精尽 Spring MVC 源码分析 —— 容器的初始化（三）之 Servlet 3.0 集成》](http://svip.iocoder.cn/Spring-MVC/context-init-integration-with-Servlet-3.0) ，只是正如本文 [「2.1 Initializer 被替换为 TomcatStarter」](https://svip.iocoder.cn/Spring-MVC/context-init-integration-with-SpringBoot/#) ，将 SpringServletContainerInitializer 替换成了 TomcatStarter 类。
+
+如果对 `<2>` 处的逻辑感兴趣的胖友，可以在 `TomcatServletWebServerFactory#getWebServer(ServletContextInitializer... initializers)` 方法，打个断点，逐步调试下去。当然，TomcatStarter 的 构造方法和 `#onStartup(Set<Class<?>> classes, ServletContext servletContext)` 方法，这两个方法的断点，也是要打上的。😈 这样，你就能把 [《精尽 Spring MVC 源码分析 —— 容器的初始化（三）之 Servlet 3.0 集成》](http://svip.iocoder.cn/Spring-MVC/context-init-integration-with-Servlet-3.0) ，只是正如本文 [「2.1 Initializer 被替换为 TomcatStarter」](http://svip.iocoder.cn/Spring-MVC/context-init-integration-with-Servlet-3.0) 和 [《精尽 Spring MVC 源码分析 —— 容器的初始化（四）之 Spring Boot 集成》](http://svip.iocoder.cn/Spring-MVC/context-init-integration-with-SpringBoot/) 给完整串联起来。
+
+## 5.2 TomcatEmbeddedServletContainerFactory 又是如何被声明的？
+
+```
+// EmbeddedServletContainerAutoConfiguration.java
+
+@AutoConfigureOrder(Ordered.HIGHEST_PRECEDENCE)
+@Configuration
+@ConditionalOnWebApplication // web 环境下
+@Import(BeanPostProcessorsRegistrar.class)
+public class EmbeddedServletContainerAutoConfiguration {
+
+   /**
+    * Nested configuration if Tomcat is being used.
+    */
+   @Configuration
+   @ConditionalOnClass({ Servlet.class, Tomcat.class }) // 不能再 Servlet + Tomcat 类
+   @ConditionalOnMissingBean(value = EmbeddedServletContainerFactory.class, search = SearchStrategy.CURRENT)
+   public static class EmbeddedTomcat {
+
+      @Bean
+      public TomcatEmbeddedServletContainerFactory tomcatEmbeddedServletContainerFactory() {
+         return new TomcatEmbeddedServletContainerFactory(); // TomcatEmbeddedServletContainerFactory 对象
+      }
+
+   }
+   
+   // 省略 EmbeddedJetty
+   
+   // 省略 EmbeddedUndertow
+}
+```
+
+只要类路径下存在 Tomcat 类，以及在 Web 环境下，就会触发 Spring Boot 的自动配置。
+
+# 总结
+
+存在 `web.xml` 配置的 java web 项目，servlet3.0 的 java web 项目，Spring Boot 内嵌容器的 java web 项目加载 Servlet，**这三种**，servlet，filter，listener 的流程都是有所差异的。理解清楚这其中的原来，其实并不容易，至少得搞懂 Servlet 3.0 的规范，Spring Boot 内嵌容器的加载流程等等前置逻辑。
+
+**最后感谢下小马哥的点拨，在此之前误以为： TomcatStarter 既然继承了 ServletContainerInitializer，应该也是符合 Servlet3.0 规范的，但实际上并没有被 SPI 加载**。
+
+简化整个流程，如下图所示：[![流程](07-Spring MVC 源码分析-容器的初始化（四）之 Spring Boot 集成.assets/01.png)](http://static.iocoder.cn/images/Spring/2022-02-10/01.png)流程
+
+- 胖友可以顺着这个图，在整理下细节。
\ No newline at end of file
diff --git a/springmvc/08-Spring MVC 源码分析-组件一览.assets/15300766829012.jpg b/springmvc/08-Spring MVC 源码分析-组件一览.assets/15300766829012.jpg
new file mode 100644
index 0000000..2b8d146
Binary files /dev/null and b/springmvc/08-Spring MVC 源码分析-组件一览.assets/15300766829012.jpg differ
diff --git a/springmvc/08-Spring MVC 源码分析-组件一览.md b/springmvc/08-Spring MVC 源码分析-组件一览.md
new file mode 100644
index 0000000..2d69a43
--- /dev/null
+++ b/springmvc/08-Spring MVC 源码分析-组件一览.md	
@@ -0,0 +1,350 @@
+# 精尽 Spring MVC 源码分析 —— 组件一览
+
+# 1. 概述
+
+在 [《精尽 Spring MVC 源码分析 —— 容器的初始化（二）之 Servlet WebApplicationContext 容器》](http://svip.iocoder.cn/Spring-MVC/context-init-Servlet-WebApplicationContext) 一文中，我们看到，会调用 DispatcherServlet 的 `#initStrategies(ApplicationContext context)` 方法，初始化 Spring MVC 的各种组件。代码如下：
+
+```
+// DispatcherServlet.java
+
+/** MultipartResolver used by this servlet. */
+@Nullable
+private MultipartResolver multipartResolver;
+
+/** LocaleResolver used by this servlet. */
+@Nullable
+private LocaleResolver localeResolver;
+
+/** ThemeResolver used by this servlet. */
+@Nullable
+private ThemeResolver themeResolver;
+
+/** List of HandlerMappings used by this servlet. */
+@Nullable
+private List<HandlerMapping> handlerMappings;
+
+/** List of HandlerAdapters used by this servlet. */
+@Nullable
+private List<HandlerAdapter> handlerAdapters;
+
+/** List of HandlerExceptionResolvers used by this servlet. */
+@Nullable
+private List<HandlerExceptionResolver> handlerExceptionResolvers;
+
+/** RequestToViewNameTranslator used by this servlet. */
+@Nullable
+private RequestToViewNameTranslator viewNameTranslator;
+
+/** FlashMapManager used by this servlet. */
+@Nullable
+private FlashMapManager flashMapManager;
+
+/** List of ViewResolvers used by this servlet. */
+@Nullable
+private List<ViewResolver> viewResolvers;
+    
+/**
+ * This implementation calls {@link #initStrategies}.
+ */
+@Override
+protected void onRefresh(ApplicationContext context) {
+	initStrategies(context);
+}
+    
+/**
+ * Initialize the strategy objects that this servlet uses.
+ * <p>May be overridden in subclasses in order to initialize further strategy objects.
+ */
+protected void initStrategies(ApplicationContext context) {
+    // 初始化 MultipartResolver
+	initMultipartResolver(context);
+	// 初始化 LocaleResolver
+	initLocaleResolver(context);
+	// 初始化 ThemeResolver
+	initThemeResolver(context);
+	// 初始化 HandlerMappings
+	initHandlerMappings(context);
+	// 初始化 HandlerAdapters
+	initHandlerAdapters(context);
+	// 初始化 HandlerExceptionResolvers 
+	initHandlerExceptionResolvers(context);
+	// 初始化 RequestToViewNameTranslator
+	initRequestToViewNameTranslator(context);
+	// 初始化 ViewResolvers
+	initViewResolvers(context);
+	// 初始化 FlashMapManager
+	initFlashMapManager(context);
+}
+```
+
+- 掐指一算，一共有 9 个组件。本文，我们对这 9 个组件，做一个简单的介绍。
+
+当然，在具体介绍组件之前，我们还是通过一张图，来看看这些组件，在一次用户的请求中，扮演了什么样的角色。
+
+> FROM [《Spring MVC 原理探秘 —— 一个请求的旅行过程》](https://www.tianxiaobo.com/2018/06/29/Spring-MVC-原理探秘-一个请求的旅行过程/)
+>
+> [![img](08-Spring MVC 源码分析-组件一览.assets/15300766829012.jpg)](https://blog-pictures.oss-cn-shanghai.aliyuncs.com/15300766829012.jpg)
+
+- 当然，这个图并没有包括所有的组件，主要涉及最核心的组件。😈
+
+# 2. MultipartResolver
+
+`org.springframework.web.multipart.MultipartResolver` ，内容类型( `Content-Type` )为 `multipart/*` 的请求的解析器接口。
+
+例如，文件上传请求，MultipartResolver 会将 HttpServletRequest 封装成 MultipartHttpServletRequest ，这样从 MultipartHttpServletRequest 中获得上传的文件。具体的使用示例，参见 [《spring-boot 上传文件 MultiPartFile 获取不到文件问题解决》](https://blog.csdn.net/happy_cheng/article/details/54178392)
+
+关于内容类型( `Content-Type` )为 `multipart/*` ，胖友可以看看 [《HTTP 协议之 multipart/form-data 请求分析》](https://blog.csdn.net/five3/article/details/7181521) 文章。
+
+MultipartResolver 接口，代码如下：
+
+```
+// MultipartResolver.java
+
+public interface MultipartResolver {
+
+	/**
+     * 是否为 multipart 请求
+	 */
+	boolean isMultipart(HttpServletRequest request);
+
+	/**
+     * 将 HttpServletRequest 请求封装成 MultipartHttpServletRequest 对象
+	 */
+	MultipartHttpServletRequest resolveMultipart(HttpServletRequest request) throws MultipartException;
+
+	/**
+     * 清理处理 multipart 产生的资源，例如临时文件
+     *
+	 */
+	void cleanupMultipart(MultipartHttpServletRequest request);
+
+}
+```
+
+# 3. LocaleResolver
+
+`org.springframework.web.servlet.LocaleResolver` ，本地化( 国际化 )解析器接口。代码如下：
+
+```
+// LocaleResolver.java
+
+public interface LocaleResolver {
+
+	/**
+     * 从请求中，解析出要使用的语言。例如，请求头的 "Accept-Language"
+	 */
+	Locale resolveLocale(HttpServletRequest request);
+
+	/**
+     * 设置请求所使用的语言
+	 */
+	void setLocale(HttpServletRequest request, @Nullable HttpServletResponse response, @Nullable Locale locale);
+
+}
+```
+
+具体的使用示例，参见 [《SpringMVC学习系列（8） 之 国际化》](https://www.cnblogs.com/liukemng/p/3750117.html) 。
+
+# 4. ThemeResolver
+
+`org.springframework.web.servlet.ThemeResolver` ，主题解析器接口。代码如下：
+
+```
+// ThemeResolver.java
+
+public interface ThemeResolver {
+
+	/**
+     * 从请求中，解析出使用的主题。例如，从请求头 User-Agent ，判断使用 PC 端，还是移动端的主题
+	 */
+	String resolveThemeName(HttpServletRequest request);
+
+	/**
+     * 设置请求，所使用的主题。
+	 */
+	void setThemeName(HttpServletRequest request, @Nullable HttpServletResponse response, @Nullable String themeName);
+
+}
+```
+
+具体的使用示例，参见 [《如何使用 Spring MVC 主题》](https://blog.csdn.net/neweastsun/article/details/79213867) 。
+
+当然，因为现在的前端，基本和后端做了分离，所以这个功能已经越来越少用了。
+
+# 5. HandlerMapping
+
+`org.springframework.web.servlet.HandlerMapping` ，处理器匹配接口，根据请求( `handler` )获得其的处理器( `handler` )和拦截器们( HandlerInterceptor 数组 )。代码如下：
+
+```
+// HandlerMapping.java
+
+public interface HandlerMapping {
+
+	String PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE = HandlerMapping.class.getName() + ".pathWithinHandlerMapping";
+	String BEST_MATCHING_PATTERN_ATTRIBUTE = HandlerMapping.class.getName() + ".bestMatchingPattern";
+	String INTROSPECT_TYPE_LEVEL_MAPPING = HandlerMapping.class.getName() + ".introspectTypeLevelMapping";
+	String URI_TEMPLATE_VARIABLES_ATTRIBUTE = HandlerMapping.class.getName() + ".uriTemplateVariables";
+	String MATRIX_VARIABLES_ATTRIBUTE = HandlerMapping.class.getName() + ".matrixVariables";
+	String PRODUCIBLE_MEDIA_TYPES_ATTRIBUTE = HandlerMapping.class.getName() + ".producibleMediaTypes";
+
+	/**
+     * 获得请求对应的处理器和拦截器们
+	 */
+	@Nullable
+	HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception;
+
+}
+```
+
+- 返回的对象类型是 HandlerExecutionChain ，它包含处理器( `handler` )和拦截器们( HandlerInterceptor 数组 )。简单代码如下：
+
+  ```
+  // HandlerExecutionChain.java
+  
+  /**
+   * 处理器
+   */
+  private final Object handler;
+  /**
+   * 拦截器数组
+   */
+  @Nullable
+  private HandlerInterceptor[] interceptors;
+  ```
+
+  - 注意，处理器的类型可能和我们想的不太一样，是个 **Object** 类型。
+
+# 6. HandlerAdapter
+
+`org.springframework.web.servlet.HandlerAdapter` ，处理器适配器接口。代码如下：
+
+```
+// HandlerAdapter.java
+
+public interface HandlerAdapter {
+
+	/**
+     * 是否支持该处理器
+	 */
+	boolean supports(Object handler);
+
+	/**
+     * 执行处理器，返回 ModelAndView 结果
+	 */
+	@Nullable
+	ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception;
+
+	/**
+     * 返回请求的最新更新时间。
+     *
+     * 如果不支持该操作，则返回 -1 即可
+	 */
+	long getLastModified(HttpServletRequest request, Object handler);
+
+}
+```
+
+- 因为，处理器 `handler` 的类型是 Object 类型，需要有一个调用者来实现 `handler` 是怎么被使用，怎么被执行。而 HandlerAdapter 的用途就在于此。可能如果接口名改成 HandlerInvoker ，笔者觉得会更好理解。
+- 三个接口，代码比较好理解，胖友瞅一眼，就不细讲了。
+
+# 7. HandlerExceptionResolver
+
+`org.springframework.web.servlet.HandlerExceptionResolver` ，处理器异常解析器接口，将处理器( `handler` )执行时发生的异常，解析( 转换 )成对应的 ModelAndView 结果。代码如下：
+
+```
+// HandlerExceptionResolver.java
+
+public interface HandlerExceptionResolver {
+
+	/**
+     * 解析异常，转换成对应的 ModelAndView 结果
+	 */
+	@Nullable
+	ModelAndView resolveException(
+			HttpServletRequest request, HttpServletResponse response, @Nullable Object handler, Exception ex);
+
+}
+```
+
+# 8. RequestToViewNameTranslator
+
+`org.springframework.web.servlet.RequestToViewNameTranslator` ，请求到视图名的转换器接口。代码如下：
+
+```
+// RequestToViewNameTranslator.java
+
+public interface RequestToViewNameTranslator {
+
+	/**
+     * 根据请求，获得其视图名
+	 */
+	@Nullable
+	String getViewName(HttpServletRequest request) throws Exception;
+
+}
+```
+
+粗略这么一看，有点不太好理解。捉摸了一下，还是放在后面一起讲解源码的时候，在详细讲解。
+
+# 9. ViewResolver
+
+`org.springframework.web.servlet.ViewResolver` ，实体解析器接口，根据视图名和国际化，获得最终的视图 View 对象。代码如下：
+
+```
+// ViewResolver.java
+
+public interface ViewResolver {
+
+	/**
+     * 根据视图名和国际化，获得最终的 View 对象
+	 */
+	@Nullable
+	View resolveViewName(String viewName, Locale locale) throws Exception;
+
+}
+```
+
+ViewResolver 的实现类比较多，例如说，InternalResourceViewResolver 负责解析 JSP 视图，FreeMarkerViewResolver 负责解析 Freemarker 视图。当然，详细的，我们后续文章解析。
+
+# 10. FlashMapManager
+
+`org.springframework.web.servlet.FlashMapManager` ，FlashMap 管理器接口，负责重定向时，保存参数到临时存储中。代码如下：
+
+```
+// FlashMapManager.java
+
+public interface FlashMapManager {
+
+	/**
+     * 恢复参数，并将恢复过的和超时的参数从保存介质中删除
+	 */
+	@Nullable
+	FlashMap retrieveAndUpdate(HttpServletRequest request, HttpServletResponse response);
+
+	/**
+     * 将参数保存起来
+	 */
+	void saveOutputFlashMap(FlashMap flashMap, HttpServletRequest request, HttpServletResponse response);
+
+}
+```
+
+默认情况下，这个临时存储会是 Session 。也就是说：
+
+- 重定向前，保存参数到 Seesion 中。
+- 重定向后，从 Session 中获得参数，并移除。
+
+具体使用示例，参见 [《Spring MVC Flash Attribute 的讲解与使用示例》](https://www.oschina.net/translate/spring-mvc-flash-attribute-example) 一文。
+
+当然，实际场景下，使用的非常少，特别是前后端分离之后。
+
+# 666. 彩蛋
+
+小小水文一篇，先一起了解下 Spring MVC 的组件。酱紫，我们下一篇好整体的了解一个用户的请求，DispatcherServlet 是如何使用上述的组件，对其进行处理的。
+
+参考和推荐如下文章：
+
+- 田小波 [《Spring MVC 原理探秘 - 一个请求的旅行过程》](https://www.tianxiaobo.com/2018/06/29/Spring-MVC-原理探秘-一个请求的旅行过程/)
+- glmapper [《SpringMVC 源码系列：九大组件小记》](http://www.glmapper.com/2018/11/10/spring-base-webmvc5/)
+- 郝佳 [《Spring 源码深度解析》](https://item.jd.com/11311737.html) 的 [「11.3 DispatcherServlet」](https://svip.iocoder.cn/Spring-MVC/Components-intro/#) 小节
+- 韩路彪 [《看透 Spring MVC：源代码分析与实践》](https://item.jd.com/11807414.html) 的 [「第9章 创建 Spring MVC 之器」](https://svip.iocoder.cn/Spring-MVC/Components-intro/#) 小节
\ No newline at end of file
diff --git a/springmvc/09-Spring MVC 源码分析-请求处理一览.assets/01.png b/springmvc/09-Spring MVC 源码分析-请求处理一览.assets/01.png
new file mode 100644
index 0000000..243b463
Binary files /dev/null and b/springmvc/09-Spring MVC 源码分析-请求处理一览.assets/01.png differ
diff --git a/springmvc/09-Spring MVC 源码分析-请求处理一览.assets/02.png b/springmvc/09-Spring MVC 源码分析-请求处理一览.assets/02.png
new file mode 100644
index 0000000..aa2f2a0
Binary files /dev/null and b/springmvc/09-Spring MVC 源码分析-请求处理一览.assets/02.png differ
diff --git a/springmvc/09-Spring MVC 源码分析-请求处理一览.assets/03.png b/springmvc/09-Spring MVC 源码分析-请求处理一览.assets/03.png
new file mode 100644
index 0000000..a21321b
Binary files /dev/null and b/springmvc/09-Spring MVC 源码分析-请求处理一览.assets/03.png differ
diff --git a/springmvc/09-Spring MVC 源码分析-请求处理一览.assets/15300766829012.jpg b/springmvc/09-Spring MVC 源码分析-请求处理一览.assets/15300766829012.jpg
new file mode 100644
index 0000000..2b8d146
Binary files /dev/null and b/springmvc/09-Spring MVC 源码分析-请求处理一览.assets/15300766829012.jpg differ
diff --git a/springmvc/09-Spring MVC 源码分析-请求处理一览.md b/springmvc/09-Spring MVC 源码分析-请求处理一览.md
new file mode 100644
index 0000000..ae4cf9f
--- /dev/null
+++ b/springmvc/09-Spring MVC 源码分析-请求处理一览.md	
@@ -0,0 +1,887 @@
+# 精尽 Spring MVC 源码分析 —— 请求处理一览
+
+# 1. 概述
+
+本文，我们来一览一个用户的请求，是如何被 DispatcherServlet 处理的。如下图所示：
+
+> FROM [《Spring MVC 原理探秘 —— 一个请求的旅行过程》](https://www.tianxiaobo.com/2018/06/29/Spring-MVC-原理探秘-一个请求的旅行过程/)
+>
+> [![img](09-Spring MVC 源码分析-请求处理一览.assets/15300766829012.jpg)](https://blog-pictures.oss-cn-shanghai.aliyuncs.com/15300766829012.jpg)
+
+整体流程实际不复杂，但是涉及的**全部**代码会非常多，所以本文重点在于解析**整体的流程**。特别具体和细节的代码实现，我们会放到后续的文章，一篇一篇细细咀嚼。
+
+## 1.1 如何调试
+
+> 艿艿：自我吐槽，写完之后才发现，忘记提供测试示例了。
+
+比较简单，调试 `org.springframework.web.servlet.DispatcherServletTests` 这个单元测试类，可以运行各种单元测试方法，执行各种情况。😈
+
+# 2. FrameworkServlet
+
+虽然在 [「1. 概述」](https://svip.iocoder.cn/Spring-MVC/DispatcherServlet-process-request-intro/#) 的整体流程图，我们看到请求首先是被 DispatcherServlet 所处理，但是实际上，FrameworkServlet 才是真正的入门。FrameworkServlet 会实现
+
+- `#doGet(HttpServletRequest request, HttpServletResponse response)`
+- `#doPost(HttpServletRequest request, HttpServletResponse response)`
+- `#doPut(HttpServletRequest request, HttpServletResponse response)`
+- `#doDelete(HttpServletRequest request, HttpServletResponse response)`
+- `#doOptions(HttpServletRequest request, HttpServletResponse response)`
+- `#doTrace(HttpServletRequest request, HttpServletResponse response)`
+- `#service(HttpServletRequest request, HttpServletResponse response)`
+
+等方法。而这些实现，最终会调用 `#processRequest(HttpServletRequest request, HttpServletResponse response)` 方法，处理请求。
+
+## 2.1 不同 HttpMethod 的请求处理
+
+### 2.1.1 service
+
+`#service(HttpServletRequest request, HttpServletResponse response)` 方法，代码如下：
+
+```
+// FrameworkServlet.java
+
+@Override
+protected void service(HttpServletRequest request, HttpServletResponse response)
+		throws ServletException, IOException {
+	// <1> 获得请求方法
+	HttpMethod httpMethod = HttpMethod.resolve(request.getMethod());
+	// <2.1> 处理 PATCH 请求
+	if (httpMethod == HttpMethod.PATCH || httpMethod == null) {
+		processRequest(request, response);
+	// <2.2> 调用父类，处理其它请求
+	} else {
+		super.service(request, response);
+	}
+}
+```
+
+- `<1>` 处，获得请求方法。
+
+- `<2.1>` 处，若请求方法是 `HttpMethod.PATCH` ，调用 `#processRequest(HttpServletRequest request, HttpServletResponse response)` 方法，处理请求。因为 HttpServlet 默认没提供 `#doPatch(HttpServletRequest request, HttpServletResponse response)` 方法，所以只能通过父类的 `#service(...)` 方法，从而实现。另外，关于 processRequest 的详细解析，见 [「2.2 processRequest」](https://svip.iocoder.cn/Spring-MVC/DispatcherServlet-process-request-intro/#) 。
+
+- `<2.2>` 处，其它类型的请求方法，还是调用父类的 `#service(HttpServletRequest request, HttpServletResponse response)` 方法，进行处理。代码如下：
+
+  ```
+  // HttpServlet.java
+  
+  protected void service(HttpServletRequest req, HttpServletResponse resp)
+      throws ServletException, IOException {
+      String method = req.getMethod();
+  
+      if (method.equals(METHOD_GET)) {
+          long lastModified = getLastModified(req);
+          if (lastModified == -1) {
+              // servlet doesn't support if-modified-since, no reason
+              // to go through further expensive logic
+              doGet(req, resp);
+          } else {
+              long ifModifiedSince = req.getDateHeader(HEADER_IFMODSINCE);
+              if (ifModifiedSince < lastModified) {
+                  // If the servlet mod time is later, call doGet()
+                  // Round down to the nearest second for a proper compare
+                  // A ifModifiedSince of -1 will always be less
+                  maybeSetLastModified(resp, lastModified);
+                  doGet(req, resp);
+              } else {
+                  resp.setStatus(HttpServletResponse.SC_NOT_MODIFIED);
+              }
+          }
+      } else if (method.equals(METHOD_HEAD)) {
+          long lastModified = getLastModified(req);
+          maybeSetLastModified(resp, lastModified);
+          doHead(req, resp);
+      } else if (method.equals(METHOD_POST)) {
+          doPost(req, resp);
+      } else if (method.equals(METHOD_PUT)) {
+          doPut(req, resp);
+      } else if (method.equals(METHOD_DELETE)) {
+          doDelete(req, resp);
+      } else if (method.equals(METHOD_OPTIONS)) {
+          doOptions(req,resp);
+      } else if (method.equals(METHOD_TRACE)) {
+          doTrace(req,resp);
+      } else {
+          //
+          // Note that this means NO servlet supports whatever
+          // method was requested, anywhere on this server.
+          //
+  
+          String errMsg = lStrings.getString("http.method_not_implemented");
+          Object[] errArgs = new Object[1];
+          errArgs[0] = method;
+          errMsg = MessageFormat.format(errMsg, errArgs);
+          
+          resp.sendError(HttpServletResponse.SC_NOT_IMPLEMENTED, errMsg);
+      }
+  }
+  ```
+
+可能会有胖友有疑惑，为什么不在 `#service(HttpServletRequest request, HttpServletResponse response)` 方法，直接调用 `#processRequest(HttpServletRequest request, HttpServletResponse response)` 方法就好列？因为针对不同的请求方法，处理略微有所不同。
+
+### 2.1.2 doGet & doPost & doPut & doDelete
+
+这四个方法，都是直接调用 `#processRequest(HttpServletRequest request, HttpServletResponse response)` 方法，处理请求。代码如下：
+
+```
+// FrameworkServlet.java
+
+@Override
+protected final void doGet(HttpServletRequest request, HttpServletResponse response)
+		throws ServletException, IOException {
+	processRequest(request, response);
+}
+
+@Override
+protected final void doPost(HttpServletRequest request, HttpServletResponse response)
+		throws ServletException, IOException {
+	processRequest(request, response);
+}
+
+@Override
+protected final void doPut(HttpServletRequest request, HttpServletResponse response)
+		throws ServletException, IOException {
+	processRequest(request, response);
+}
+
+@Override
+protected final void doDelete(HttpServletRequest request, HttpServletResponse response)
+		throws ServletException, IOException {
+	processRequest(request, response);
+}
+```
+
+### 2.1.3 doOptions
+
+```
+// FrameworkServlet.java
+
+/** Should we dispatch an HTTP OPTIONS request to {@link #doService}?. */
+private boolean dispatchOptionsRequest = false;
+
+/**
+ * Delegate OPTIONS requests to {@link #processRequest}, if desired.
+ * <p>Applies HttpServlet's standard OPTIONS processing otherwise,
+ * and also if there is still no 'Allow' header set after dispatching.
+ * @see #doService
+ */
+@Override
+protected void doOptions(HttpServletRequest request, HttpServletResponse response)
+		throws ServletException, IOException {
+	// 如果 dispatchOptionsRequest 为 true ，则处理该请求
+	if (this.dispatchOptionsRequest || CorsUtils.isPreFlightRequest(request)) {
+	    // 处理请求
+	    processRequest(request, response);
+		// 如果响应 Header 包含 "Allow" ，则不需要交给父方法处理
+		if (response.containsHeader("Allow")) {
+			// Proper OPTIONS response coming from a handler - we're done.
+			return;
+		}
+	}
+
+	// Use response wrapper in order to always add PATCH to the allowed methods
+	// 调用父方法，并在响应 Header 的 "Allow" 增加 PATCH 的值
+	super.doOptions(request, new HttpServletResponseWrapper(response) {
+		@Override
+		public void setHeader(String name, String value) {
+			if ("Allow".equals(name)) {
+				value = (StringUtils.hasLength(value) ? value + ", " : "") + HttpMethod.PATCH.name();
+			}
+			super.setHeader(name, value);
+		}
+	});
+}
+```
+
+- 选读，因为 OPTIONS 请求方法，实际场景下用的少。
+- 可参考 [《HTTP 的请求方法 OPTIONS》](https://blog.csdn.net/leikezhu1981/article/details/7402272) 。
+
+### 2.1.4 doTrace
+
+```
+// FrameworkServlet.java
+
+/** Should we dispatch an HTTP TRACE request to {@link #doService}?. */
+private boolean dispatchTraceRequest = false;
+
+/**
+ * Delegate TRACE requests to {@link #processRequest}, if desired.
+ * <p>Applies HttpServlet's standard TRACE processing otherwise.
+ * @see #doService
+ */
+@Override
+protected void doTrace(HttpServletRequest request, HttpServletResponse response)
+		throws ServletException, IOException {
+	// 如果 dispatchTraceRequest 为 true ，则处理该请求
+	if (this.dispatchTraceRequest) {
+		// 处理请求
+		processRequest(request, response);
+		// 如果响应的内容类型为 "message/http" ，则不需要交给父方法处理
+		if ("message/http".equals(response.getContentType())) {
+			// Proper TRACE response coming from a handler - we're done.
+			return;
+		}
+	}
+
+	// 调用父方法
+	super.doTrace(request, response);
+}
+```
+
+- 选读，因为 TRACE 请求方法，实际场景下用的少。
+- 可参读 [《HTTP Method详细解读(`GET` `HEAD` `POST` `OPTIONS` `PUT` `DELETE` `TRACE` `CONNECT`)》](https://www.cnblogs.com/machao/p/5788425.html) 的 [「9.8 TRACE」](https://svip.iocoder.cn/Spring-MVC/DispatcherServlet-process-request-intro/#) 小节。
+
+## 2.2 processRequest
+
+`#processRequest(HttpServletRequest request, HttpServletResponse response)` 方法，处理请求。代码如下：
+
+```
+// FrameworkServlet.java
+
+protected final void processRequest(HttpServletRequest request, HttpServletResponse response)
+		throws ServletException, IOException {
+	// <1> 记录当前时间，用于计算 web 请求的处理时间
+	long startTime = System.currentTimeMillis();
+	// <2> 记录异常
+	Throwable failureCause = null;
+
+	// <3> TODO 芋艿
+	LocaleContext previousLocaleContext = LocaleContextHolder.getLocaleContext();
+	LocaleContext localeContext = buildLocaleContext(request);
+
+	// <4> TODO 芋艿
+	RequestAttributes previousAttributes = RequestContextHolder.getRequestAttributes();
+	ServletRequestAttributes requestAttributes = buildRequestAttributes(request, response, previousAttributes);
+
+	// <5> TODO 芋艿
+	WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager(request);
+	asyncManager.registerCallableInterceptor(FrameworkServlet.class.getName(), new RequestBindingInterceptor());
+
+	// <6> TODO 芋艿
+	initContextHolders(request, localeContext, requestAttributes);
+
+	try {
+		// <7> 执行真正的逻辑
+		doService(request, response);
+	} catch (ServletException | IOException ex) {
+		failureCause = ex; // <8>
+		throw ex;
+	} catch (Throwable ex) {
+		failureCause = ex; // <8>
+		throw new NestedServletException("Request processing failed", ex);
+	} finally {
+		// <9> TODO 芋艿
+		resetContextHolders(request, previousLocaleContext, previousAttributes);
+		// <10> TODO 芋艿
+		if (requestAttributes != null) {
+			requestAttributes.requestCompleted();
+		}
+		// <11> 打印请求日志，并且日志级别为 DEBUG 
+		logResult(request, response, failureCause, asyncManager);
+		// <12> 发布 ServletRequestHandledEvent 事件
+		publishRequestHandledEvent(request, response, startTime, failureCause);
+	}
+}
+```
+
+- `<1>` 处，记录当前时间，用于计算 web 请求的处理时间。
+
+- `<2>` 处，记录异常。
+
+- `<3>` 处，TODO 1001 Locale
+
+- `<4>` 处，TODO 1002 RequestAttributes
+
+- `<5>` 处，TODO 1003 Asyn
+
+- `<6>` 处，TODO 1001 + 1002
+
+- 【重要】 `<7>` 处，调用 `#doService(HttpServletRequest request, HttpServletResponse response)` **抽象**方法，执行真正的逻辑。代码如下：
+
+  ```
+  // FrameworkServlet.java
+  
+  protected abstract void doService(HttpServletRequest request, HttpServletResponse response)
+  		throws Exception;
+  ```
+
+  - 该**抽象**方法由 DispatcherServlet 实现，所以这就是 DispatcherServlet 处理请求的**真正入口**。详细解析，见 [「3. DispatcherServlet」](https://svip.iocoder.cn/Spring-MVC/DispatcherServlet-process-request-intro/#) 。
+
+- `<8>` 处，记录抛出的异常，最终在 `finally` 的代码段中使用。
+
+- `<9>` 处，TODO 1001 + 1002
+
+- `<10>` 处，TODO 1001 + 1002
+
+- `<11>` 处，调用 `#logResult(HttpServletRequest request, HttpServletResponse response, Throwable failureCause, WebAsyncManager asyncManager)` 方法，打印请求日志，并且日志级别为 **DEBUG** 。这个方法，感兴趣的胖友，点击 [传送门](https://github.com/spring-projects/spring-framework/blob/master/spring-webmvc/src/main/java/org/springframework/web/servlet/FrameworkServlet.java#L1079-L1132) 查看。
+
+- `<12>` 处，调用 `#publishRequestHandledEvent(HttpServletRequest request, HttpServletResponse response, long startTime, Throwable failureCause)` 方法，发布 `org.springframework.web.context.support.ServletRequestHandledEvent` 事件。代码如下：
+
+  ```
+  // FrameworkServlet.java
+  
+  /** Should we publish a ServletRequestHandledEvent at the end of each request?. */
+  private boolean publishEvents = true;
+  
+  private void publishRequestHandledEvent(HttpServletRequest request, HttpServletResponse response,
+  		long startTime, @Nullable Throwable failureCause) {
+  	// 如果开启发布事件
+  	if (this.publishEvents && this.webApplicationContext != null) {
+  		// Whether or not we succeeded, publish an event.
+  		long processingTime = System.currentTimeMillis() - startTime;
+  		// 创建 ServletRequestHandledEvent 事件，并进行发布
+  		this.webApplicationContext.publishEvent(
+  				new ServletRequestHandledEvent(this,
+  						request.getRequestURI(), request.getRemoteAddr(),
+  						request.getMethod(), getServletConfig().getServletName(),
+  						WebUtils.getSessionId(request), getUsernameForRequest(request),
+  						processingTime, failureCause, response.getStatus()));
+  	}
+  }
+  ```
+
+  - 关于 ServletRequestHandledEvent 的监听使用，可参考 [《使用 Spring ApplicationListener 容器监听器来记录请求信息》](https://my.oschina.net/u/2419285/blog/1510163) 。
+
+> 艿艿：好像到了此处，一直没写到 DispatcherServlet 。😈 有种在啰嗦的感觉，嘿嘿。
+
+# 3. DispatcherServlet
+
+## 3.1 doService
+
+`#doService(HttpServletRequest request, HttpServletResponse response)` 方法，DispatcherServlet 的处理请求的入口方法，代码如下：
+
+```
+// DispatcherServlet.java
+
+@Override
+protected void doService(HttpServletRequest request, HttpServletResponse response) throws Exception {
+	// <1> 打印请求日志，并且日志级别为 DEBUG
+    logRequest(request);
+
+	// Keep a snapshot of the request attributes in case of an include,
+	// to be able to restore the original attributes after the include.
+	// <2> TODO 芋艿
+	Map<String, Object> attributesSnapshot = null;
+	if (WebUtils.isIncludeRequest(request)) {
+		attributesSnapshot = new HashMap<>();
+		Enumeration<?> attrNames = request.getAttributeNames();
+		while (attrNames.hasMoreElements()) {
+			String attrName = (String) attrNames.nextElement();
+			if (this.cleanupAfterInclude || attrName.startsWith(DEFAULT_STRATEGIES_PREFIX)) {
+				attributesSnapshot.put(attrName, request.getAttribute(attrName));
+			}
+		}
+	}
+
+	// Make framework objects available to handlers and view objects.
+	// <3> 设置 Spring 框架中的常用对象到 request 属性中
+	request.setAttribute(WEB_APPLICATION_CONTEXT_ATTRIBUTE, getWebApplicationContext());
+	request.setAttribute(LOCALE_RESOLVER_ATTRIBUTE, this.localeResolver);
+	request.setAttribute(THEME_RESOLVER_ATTRIBUTE, this.themeResolver);
+	request.setAttribute(THEME_SOURCE_ATTRIBUTE, getThemeSource());
+
+	// <4> TODO 芋艿 flashMapManager
+	if (this.flashMapManager != null) {
+		FlashMap inputFlashMap = this.flashMapManager.retrieveAndUpdate(request, response);
+		if (inputFlashMap != null) {
+			request.setAttribute(INPUT_FLASH_MAP_ATTRIBUTE, Collections.unmodifiableMap(inputFlashMap));
+		}
+		request.setAttribute(OUTPUT_FLASH_MAP_ATTRIBUTE, new FlashMap());
+		request.setAttribute(FLASH_MAP_MANAGER_ATTRIBUTE, this.flashMapManager);
+	}
+
+	try {
+		// <5> 执行请求的分发
+		doDispatch(request, response);
+	} finally {
+		// <6> TODO 芋艿
+		if (!WebAsyncUtils.getAsyncManager(request).isConcurrentHandlingStarted()) {
+			// Restore the original attribute snapshot, in case of an include.
+			if (attributesSnapshot != null) {
+				restoreAttributesAfterInclude(request, attributesSnapshot);
+			}
+		}
+	}
+}
+```
+
+- `<1>` 处，调用 `#logRequest(HttpServletRequest request)` 方法，打印请求日志，并且日志级别为 DEBUG 。这个方法，感兴趣的胖友，点击 [传送门](https://github.com/spring-projects/spring-framework/blob/master/spring-webmvc/src/main/java/org/springframework/web/servlet/DispatcherServlet.java#L954-L985) 查看。
+- `<2>` 处，TODO 1003 芋艿
+- `<3>` 处，设置 Spring 框架中的常用对象到 `request` 的属性中。
+- `<4>` 处，TODO 1004 芋艿 flashMapManager
+- `<5>` 处，调用 `#doDispatch(HttpServletRequest request, HttpServletResponse response)` 方法，执行请求的分发。详细解析，见 [「3.2 doDispatch」](https://svip.iocoder.cn/Spring-MVC/DispatcherServlet-process-request-intro/#) 。
+- `<6>` 处，TODO 1003 芋艿
+
+## 3.2 doDispatch
+
+`#doDispatch(HttpServletRequest request, HttpServletResponse response)` 方法，执行请求的分发。在开始看具体的代码实现之前，我们在来回味下这张图片：
+
+> FROM [《Spring MVC 原理探秘 —— 一个请求的旅行过程》](https://www.tianxiaobo.com/2018/06/29/Spring-MVC-原理探秘-一个请求的旅行过程/)
+>
+> [![img](09-Spring MVC 源码分析-请求处理一览.assets/15300766829012.jpg)](https://blog-pictures.oss-cn-shanghai.aliyuncs.com/15300766829012.jpg)
+
+- 实际上，这张图，更多的反应的是 DispatcherServlet 的 `#DispatcherServlet(...)` 方法的核心流程。
+
+代码如下：
+
+```
+// DispatcherServlet.java
+
+protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception {
+	HttpServletRequest processedRequest = request;
+	HandlerExecutionChain mappedHandler = null;
+	boolean multipartRequestParsed = false;
+
+	// <1> TODO 芋艿
+	WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager(request);
+
+	try {
+		ModelAndView mv = null;
+		Exception dispatchException = null;
+
+		try {
+			// TODO 芋艿
+			processedRequest = checkMultipart(request);
+			multipartRequestParsed = (processedRequest != request);
+
+			// Determine handler for the current request.
+			// <3> 获得请求对应的 HandlerExecutionChain 对象
+			mappedHandler = getHandler(processedRequest);
+			if (mappedHandler == null) { // <3.1> 如果获取不到，则根据配置抛出异常或返回 404 错误
+				noHandlerFound(processedRequest, response);
+				return;
+			}
+
+			// Determine handler adapter for the current request.
+			// <4> 获得当前 handler 对应的 HandlerAdapter 对象
+			HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());
+
+			// Process last-modified header, if supported by the handler.
+			// <4.1> TODO 芋艿 last-modified
+			String method = request.getMethod();
+			boolean isGet = "GET".equals(method);
+			if (isGet || "HEAD".equals(method)) {
+				long lastModified = ha.getLastModified(request, mappedHandler.getHandler());
+				if (new ServletWebRequest(request, response).checkNotModified(lastModified) && isGet) {
+					return;
+				}
+			}
+
+			// <5> 前置处理 拦截器
+			if (!mappedHandler.applyPreHandle(processedRequest, response)) {
+				return;
+			}
+
+			// Actually invoke the handler.
+			// <6> 真正的调用 handler 方法，并返回视图
+			mv = ha.handle(processedRequest, response, mappedHandler.getHandler());
+
+			// <7> TODO 芋艿
+			if (asyncManager.isConcurrentHandlingStarted()) {
+				return;
+			}
+
+			// <8> TODO 芋艿 视图
+			applyDefaultViewName(processedRequest, mv);
+			// <9> 后置处理 拦截器
+			mappedHandler.applyPostHandle(processedRequest, response, mv);
+		} catch (Exception ex) {
+			dispatchException = ex; // <10> 记录异常
+		} catch (Throwable err) {
+			// As of 4.3, we're processing Errors thrown from handler methods as well,
+			// making them available for @ExceptionHandler methods and other scenarios.
+			dispatchException = new NestedServletException("Handler dispatch failed", err); // <10> 记录异常
+		}
+
+		// <11> 处理正常和异常的请求调用结果。
+		processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);
+	} catch (Exception ex) {
+		// <12> 已完成 拦截器
+		triggerAfterCompletion(processedRequest, response, mappedHandler, ex);
+	} catch (Throwable err) {
+		// <12> 已完成 拦截器
+		triggerAfterCompletion(processedRequest, response, mappedHandler,
+				new NestedServletException("Handler processing failed", err));
+	} finally {
+		// <13.1> TODO 芋艿，干啥子？
+		if (asyncManager.isConcurrentHandlingStarted()) {
+			// Instead of postHandle and afterCompletion
+			if (mappedHandler != null) {
+				mappedHandler.applyAfterConcurrentHandlingStarted(processedRequest, response);
+			}
+		} else {
+			// <13.2> Clean up any resources used by a multipart request.
+			if (multipartRequestParsed) {
+				cleanupMultipart(processedRequest);
+			}
+		}
+	}
+}
+```
+
+- `<1>` 处，TODO 1003 Async
+
+- `<2>` 处，调用 `#checkMultipart(HttpServletRequest request)` 方法，检查是否是上传请求。如果是，则封装成 MultipartHttpServletRequest 对象。详细解析，见 [《精尽 Spring MVC 源码解析 —— MultipartResolver》](http://svip.iocoder.cn/Spring-MVC/MultipartResolver) 中。
+
+- `<3>` 处，调用 `#getHandler(HttpServletRequest request)` 方法，返回请求对应的是 HandlerExecutionChain 对象，它包含处理器( `handler` )和拦截器们( HandlerInterceptor 数组 )。代码如下：
+
+  ```
+  // DispatcherServlet.java
+  
+  /** List of HandlerMappings used by this servlet. */
+  @Nullable
+  private List<HandlerMapping> handlerMappings;
+     
+  @Nullable
+  protected HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {
+  	if (this.handlerMappings != null) {
+  		// 遍历 HandlerMapping 数组
+  		for (HandlerMapping mapping : this.handlerMappings) {
+  			// 获得请求对应的 HandlerExecutionChain 对象
+  			HandlerExecutionChain handler = mapping.getHandler(request);
+  			// 获得到，则返回
+  			if (handler != null) {
+  				return handler;
+  			}
+  		}
+  	}
+  	return null;
+  }
+  ```
+
+  - 详细的解析，见 [《精尽 Spring MVC 源码分析 —— HandlerMapping 组件（二）之 HandlerInterceptor》](http://svip.iocoder.cn/Spring-MVC/HandlerMapping-2-HandlerInterceptor)
+
+- `<3.1>` 处，如果获取不到，则调用 `#noHandlerFound(HttpServletRequest request, HttpServletResponse response)` 根据配置抛出异常或返回 404 错误。 代码比较简单，胖友点击 [传送门](https://github.com/spring-projects/spring-framework/blob/master/spring-webmvc/src/main/java/org/springframework/web/servlet/DispatcherServlet.java#L1240-L1257) 自己看该方法。
+
+- `<4>` 处，调用 `#getHandlerAdapter(Object handler)` 方法，获得当前 `handler` 对应的 HandlerAdapter 对象。代码如下：
+
+  ```
+  // DispatcherServlet.java
+  /** List of HandlerAdapters used by this servlet. */
+  @Nullable
+  private List<HandlerAdapter> handlerAdapters;    
+  
+  protected HandlerAdapter getHandlerAdapter(Object handler) throws ServletException {
+  	if (this.handlerAdapters != null) {
+  		// 遍历 HandlerAdapter 数组
+  		for (HandlerAdapter adapter : this.handlerAdapters) {
+   			// 判断是否支持当前处理器
+  			if (adapter.supports(handler)) {
+  				// 如果支持，则返回
+  				return adapter;
+  			}
+  		}
+  	}
+  	// 没找到对应的 HandlerAdapter 对象，抛出 ServletException 异常
+  	throw new ServletException("No adapter for handler [" + handler +
+  			"]: The DispatcherServlet configuration needs to include a HandlerAdapter that supports this handler");
+  }
+  ```
+
+  - 详细解析，见 [《精尽 Spring MVC 源码解析 —— HandlerAdapter 组件（一）之 HandlerAdapter》](http://svip.iocoder.cn/Spring-MVC/HandlerAdapter-1-HandlerAdapter)
+
+- `<4.1>` 处，见 [《精尽 Spring MVC 源码解析 —— HandlerAdapter 组件（一）之 HandlerAdapter》](http://svip.iocoder.cn/Spring-MVC/HandlerAdapter-1-HandlerAdapter)
+
+- 【拦截器】`<5>` 处，调用 `HandlerExecutionChain#applyPreHandle(HttpServletRequest request, HttpServletResponse response)` 方法，拦截器的前置处理，即调用 `HandlerInterceptor#preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)` 方法。详细解析，见 [《精尽 Spring MVC 源码分析 —— HandlerMapping 组件（二）之 HandlerInterceptor》](http://svip.iocoder.cn/Spring-MVC/HandlerMapping-2-HandlerInterceptor) 。
+
+- 【Controller】`<6>` 处，调用 `HandlerAdapter#handle(HttpServletRequest request, HttpServletResponse response, Object handler)` 方法，真正的调用 `handler` 方法，并返回视图。这里，一般就会调用我们定义的 Controller 的方法。详细解析，见 TODO 。
+
+- `<7>` 处，TODO 1003 Asyn
+
+- `<8>` 处，调用 `#applyDefaultViewName(HttpServletRequest request, ModelAndView mv)` 方法，当无视图的情况下，设置默认视图。代码如下：
+
+  ```
+  // DispatcherServlet.java
+  
+  /** RequestToViewNameTranslator used by this servlet. */
+  @Nullable
+  private RequestToViewNameTranslator viewNameTranslator;
+  
+  private void applyDefaultViewName(HttpServletRequest request, @Nullable ModelAndView mv) throws Exception {
+  	if (mv != null && !mv.hasView()) { // 无视图
+  		// 获得默认视图
+  		String defaultViewName = getDefaultViewName(request);
+  		// 设置默认视图
+  		if (defaultViewName != null) {
+  			mv.setViewName(defaultViewName);
+  		}
+  	}
+  }
+  
+  @Nullable
+  protected String getDefaultViewName(HttpServletRequest request) throws Exception {
+  	// 从请求中，获得视图
+  	return (this.viewNameTranslator != null ? this.viewNameTranslator.getViewName(request) : null);
+  }
+  ```
+
+  - 详细解析，见 [《精尽 Spring MVC 源码解析 —— RequestToViewNameTranslator》](http://svip.iocoder.cn/Spring-MVC/RequestToViewNameTranslator) 中。
+
+- 【拦截器】`<9>` 处，调用 `HandlerExecutionChain#applyPostHandle(HttpServletRequest request, HttpServletResponse response, ModelAndView mv)` 方法，拦截器的后置处理，即调用 `HandlerInterceptor#postHandle(HttpServletRequest request, HttpServletResponse response, Object handler)` 方法。详细解析，见 [《精尽 Spring MVC 源码分析 —— HandlerMapping 组件（二）之 HandlerInterceptor》](http://svip.iocoder.cn/Spring-MVC/HandlerMapping-2-HandlerInterceptor) 。
+
+- `<10>` 处，记录异常。**注意**，此处仅仅记录，不会抛出异常，而是统一交给 `<11>` 处理。
+
+- `<11>` 处，调用 `#processDispatchResult(HttpServletRequest request, HttpServletResponse response, HandlerExecutionChain mappedHandler, ModelAndView mv, Exception exception)` 方法，处理**正常和异常**的请求调用结果。注意，正常的、异常的，都会进行处理。详细解析，见 [「3.3 processDispatchResult」](https://svip.iocoder.cn/Spring-MVC/DispatcherServlet-process-request-intro/#) 。
+
+- 【拦截器】`<12>` 处，调用 `#triggerAfterCompletion(HttpServletRequest request, HttpServletResponse response, HandlerExecutionChain mappedHandler, Exception ex)` 方法，拦截器的已完成处理，即调用 `HandlerInterceptor#triggerAfterCompletion(HttpServletRequest request, HttpServletResponse response, Exception ex)` 方法。详细解析，见 [《精尽 Spring MVC 源码分析 —— HandlerMapping 组件（二）之 HandlerInterceptor》](http://svip.iocoder.cn/Spring-MVC/HandlerMapping-2-HandlerInterceptor) 。
+
+- `<13.1>` 处，TODO 1003 Asyn
+
+- `<13.2>` 处，如果是上传请求，则调用 `#cleanupMultipart(HttpServletRequest request)` 方法，清理资源。详细解析，见 [《精尽 Spring MVC 源码解析 —— MultipartResolver》](http://svip.iocoder.cn/Spring-MVC/MultipartResolver) 中。
+
+## 3.3 processDispatchResult
+
+`#processDispatchResult(HttpServletRequest request, HttpServletResponse response, HandlerExecutionChain mappedHandler, ModelAndView mv, Exception exception)` 方法，处理**正常和异常**的请求调用结果。代码如下：
+
+```
+// DispatcherServlet.java
+
+private void processDispatchResult(HttpServletRequest request, HttpServletResponse response,
+		@Nullable HandlerExecutionChain mappedHandler, @Nullable ModelAndView mv,
+		@Nullable Exception exception) throws Exception {
+	// <1> 标记，是否是生成的 ModelAndView 对象
+	boolean errorView = false;
+
+	// <2> 如果是否异常的结果
+	if (exception != null) {
+	    // 情况一，从 ModelAndViewDefiningException 中获得 ModelAndView 对象
+		if (exception instanceof ModelAndViewDefiningException) {
+			logger.debug("ModelAndViewDefiningException encountered", exception);
+			mv = ((ModelAndViewDefiningException) exception).getModelAndView();
+		// 情况二，处理异常，生成 ModelAndView 对象
+		} else {
+			Object handler = (mappedHandler != null ? mappedHandler.getHandler() : null);
+			mv = processHandlerException(request, response, handler, exception);
+			// 标记 errorView
+			errorView = (mv != null);
+		}
+	}
+
+	// Did the handler return a view to render?
+	if (mv != null && !mv.wasCleared()) {
+		// <3.1> 渲染页面
+		render(mv, request, response);
+		// <3.2> 清理请求中的错误消息属性
+		if (errorView) {
+			WebUtils.clearErrorRequestAttributes(request);
+		}
+	} else {
+		if (logger.isTraceEnabled()) {
+			logger.trace("No view rendering, null ModelAndView returned.");
+		}
+	}
+
+	// <4> TODO 芋艿
+	if (WebAsyncUtils.getAsyncManager(request).isConcurrentHandlingStarted()) {
+		// Concurrent handling started during a forward
+		return;
+	}
+
+	// <5> 已完成处理 拦截器
+	if (mappedHandler != null) {
+		mappedHandler.triggerAfterCompletion(request, response, null);
+	}
+}
+```
+
+- `<1>` 处，`errorView` 属性，标记是否是生成的 ModelAndView 对象。
+
+- `<2>` 处，如果是否**异常**的结果。
+
+  - `<2.1>` 处，情况一，从 ModelAndViewDefiningException 中获得 ModelAndView 对象。
+
+  - `<2.2>` 处，情况二，调用 `#processHandlerException(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex)` 方法，处理异常，生成 ModelAndView 对象。代码如下：
+
+    ```
+    // DispatcherServlet.java
+    
+    @Nullable
+    protected ModelAndView processHandlerException(HttpServletRequest request, HttpServletResponse response,
+    		@Nullable Object handler, Exception ex) throws Exception {
+    	// Success and error responses may use different content types
+        // 移除 PRODUCIBLE_MEDIA_TYPES_ATTRIBUTE 属性
+    	request.removeAttribute(HandlerMapping.PRODUCIBLE_MEDIA_TYPES_ATTRIBUTE);
+    
+    	// Check registered HandlerExceptionResolvers...
+    	// <a> 遍历 HandlerExceptionResolver 数组，解析异常，生成 ModelAndView 对象
+    	ModelAndView exMv = null;
+    	if (this.handlerExceptionResolvers != null) {
+    		// 遍历 HandlerExceptionResolver 数组
+    		for (HandlerExceptionResolver resolver : this.handlerExceptionResolvers) {
+    			// 解析异常，生成 ModelAndView 对象
+    		    exMv = resolver.resolveException(request, response, handler, ex);
+    		    // 生成成功，结束循环
+    			if (exMv != null) {
+    				break;
+    			}
+    		}
+    	}
+    	// 情况一，生成了 ModelAndView 对象，进行返回
+    	if (exMv != null) {
+    		// ModelAndView 对象为空，则返回 null
+    		if (exMv.isEmpty()) {
+    			request.setAttribute(EXCEPTION_ATTRIBUTE, ex); // 记录异常到 request 中
+    			return null;
+    		}
+    		// We might still need view name translation for a plain error model...
+    		// 设置默认视图
+    		if (!exMv.hasView()) {
+    			String defaultViewName = getDefaultViewName(request);
+    			if (defaultViewName != null) {
+    				exMv.setViewName(defaultViewName);
+    			}
+    		}
+    		// 打印日志
+    		if (logger.isTraceEnabled()) {
+    			logger.trace("Using resolved error view: " + exMv, ex);
+    		}
+    		if (logger.isDebugEnabled()) {
+    			logger.debug("Using resolved error view: " + exMv);
+    		}
+    		// 设置请求中的错误消息属性
+    		WebUtils.exposeErrorRequestAttributes(request, ex, getServletName());
+    		return exMv;
+    	}
+    	// 情况二，未生成 ModelAndView 对象，则抛出异常
+    	throw ex;
+    }
+    ```
+
+    - `<a>` 处，遍历 HandlerExceptionResolver 数组，调用 `HandlerExceptionResolver#resolveException(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex)` 方法，解析异常，生成 ModelAndView 对象。详细解析，TODO
+    - `<b>` 处，情况一，生成了 ModelAndView 对象，进行返回。当然，这里的后续代码还有 10 多行，比较简单，胖友自己瞅瞅就 OK 啦。
+    - `<c>` 处，情况二，未生成 ModelAndView 对象，则抛出异常。
+
+- `<3.1>` 处，调用 `#render(ModelAndView mv, HttpServletRequest request, HttpServletResponse response)` 方法，渲染页面。详细解析，见 [「3.4 render」](https://svip.iocoder.cn/Spring-MVC/DispatcherServlet-process-request-intro/#) 。
+
+- `<3.2>` 处，当是 `<2>` 处的情况二时，则调用 `WebUtils#clearErrorRequestAttributes(HttpServletRequest request)` 方法，清理请求中的错误消息属性。为什么会有这一步呢？答案在 `#processHandlerException(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex)` 方法中，会调用 `WebUtils#exposeErrorRequestAttributes(HttpServletRequest request, Throwable ex, String servletName)` 方法，设置请求中的错误消息属性。
+
+- `<4>` 处，TODO 1003 芋艿
+
+- 【拦截器】`<5>` 处，调用 `#triggerAfterCompletion(HttpServletRequest request, HttpServletResponse response, HandlerExecutionChain mappedHandler, Exception ex)` 方法，拦截器的已完成处理，即调用 `HandlerInterceptor#triggerAfterCompletion(HttpServletRequest request, HttpServletResponse response, Exception ex)` 方法。详细解析，见 [《精尽 Spring MVC 源码分析 —— HandlerMapping 组件（二）之 HandlerInterceptor》](http://svip.iocoder.cn/Spring-MVC/HandlerMapping-2-HandlerInterceptor) 。
+
+## 3.4 render
+
+`#render(ModelAndView mv, HttpServletRequest request, HttpServletResponse response)` 方法，渲染 ModelAndView 。代码如下：
+
+```
+// DispatcherServlet.java
+
+protected void render(ModelAndView mv, HttpServletRequest request, HttpServletResponse response) throws Exception {
+	// Determine locale for request and apply it to the response.
+	// <1> TODO 芋艿 从 request 中获得 Locale 对象，并设置到 response 中
+	Locale locale = (this.localeResolver != null ? this.localeResolver.resolveLocale(request) : request.getLocale());
+	response.setLocale(locale);
+
+	// 获得 View 对象
+	View view;
+	String viewName = mv.getViewName();
+	// 情况一，使用 viewName 获得 View 对象
+	if (viewName != null) {
+		// We need to resolve the view name.
+		// <2.1> 使用 viewName 获得 View 对象
+		view = resolveViewName(viewName, mv.getModelInternal(), locale, request);
+		if (view == null) { // 获取不到，抛出 ServletException 异常
+			throw new ServletException("Could not resolve view with name '" + mv.getViewName() +
+					"' in servlet with name '" + getServletName() + "'");
+		}
+	// 情况二，直接使用 ModelAndView 对象的 View 对象
+	} else {
+		// No need to lookup: the ModelAndView object contains the actual View object.
+		// 直接使用 ModelAndView 对象的 View 对象
+		view = mv.getView();
+		if (view == null) { // 获取不到，抛出 ServletException 异常
+			throw new ServletException("ModelAndView [" + mv + "] neither contains a view name nor a " +
+					"View object in servlet with name '" + getServletName() + "'");
+		}
+	}
+
+	// Delegate to the View object for rendering.
+	// 打印日志
+	if (logger.isTraceEnabled()) {
+		logger.trace("Rendering view [" + view + "] ");
+	}
+	try {
+		// <3> 设置响应的状态码
+		if (mv.getStatus() != null) {
+			response.setStatus(mv.getStatus().value());
+		}
+		// <4> 渲染页面
+		view.render(mv.getModelInternal(), request, response);
+	} catch (Exception ex) {
+		if (logger.isDebugEnabled()) {
+			logger.debug("Error rendering view [" + view + "]", ex);
+		}
+		throw ex;
+	}
+}
+```
+
+- `<1>` 处，调用 `LocaleResolver#resolveLocale(HttpServletRequest request)` 方法，从 `request` 中获得 Locale 对象，并设置到 `response` 中。详细解析，见 TODO 1001
+
+- `<2>` 处，获得 View 对象。分成两种情况，代码比较简单，胖友自己瞅瞅。
+
+- `<2.1>` 处，调用 `#resolveViewName(String viewName, Map<String, Object> model, Locale locale, HttpServletRequest request)` 方法，使用 `viewName` 获得 View 对象。代码如下：
+
+  ```
+  // DispatcherServlet.java
+  
+  @Nullable
+  protected View resolveViewName(String viewName, @Nullable Map<String, Object> model,
+  		Locale locale, HttpServletRequest request) throws Exception {
+  	if (this.viewResolvers != null) {
+  	    // 遍历 ViewResolver 数组
+  		for (ViewResolver viewResolver : this.viewResolvers) {
+  		    // 根据 viewName + locale 参数，解析出 View 对象
+  			View view = viewResolver.resolveViewName(viewName, locale);
+  			// 解析成功，直接返回 View 对象
+  			if (view != null) {
+  				return view;
+  			}
+  		}
+  	}
+  	// 返回空
+  	return null;
+  }
+  ```
+
+  - 详细解析，见 [《精尽 Spring MVC 源码解析 —— ViewResolver》](http://svip.iocoder.cn/Spring-MVC/ViewResolver)
+
+- `<3>` 处，设置响应的状态码。
+
+- `<4>` 处，调用 `View#render(Map<String, ?> model, HttpServletRequest request, HttpServletResponse response)` 方法，渲染视图。详细解析，见 [《精尽 Spring MVC 源码解析 —— ViewResolver》](http://svip.iocoder.cn/Spring-MVC/ViewResolver) 。
+
+# 666. 彩蛋
+
+到此，我们已经对 DispatcherServlet 是如何处理请求已经有了整体的认识。当然，我们对每个 Spring MVC 组件，细节暂时没有进行深扣，正如我们在看本文，会有大量的 TODO 。不要方，后面的每一篇，我们会对每个 Spring MVC 组件逐个解析。这样，我们对 Spring MVC 会更加了解。
+
+其实，这也是看源码的套路，先整理，后局部，逐步逐步抽丝剥茧，看清理透。
+
+还有，在看完后续的 Spring MVC 的每个组件后，胖友可以在回过头在重新看看这个文章，是否能够将文章更好的串联在一起。
+
+------
+
+下面，艿艿整理了一些网络上讲述 Spring MVC 处理请求的一些图，帮助我们更好的理解这个过程。
+
+> FROM [《SpringMVC - 运行流程图及原理分析》](https://blog.csdn.net/J080624/article/details/77990164)
+>
+> **流程示意图**：
+>
+> [![流程示意图](09-Spring MVC 源码分析-请求处理一览.assets/01.png)](http://static.iocoder.cn/images/Spring/2022-02-21/01.png)流程示意图
+>
+> **代码序列图**：
+>
+> [![代码序列图](09-Spring MVC 源码分析-请求处理一览.assets/02.png)](http://static.iocoder.cn/images/Spring/2022-02-21/02.png)代码序列图
+>
+> ------
+>
+> FROM [《看透 Spring MVC：源代码分析与实践》](https://item.jd.com/11807414.html) P123
+>
+> **流程示意图**：
+>
+> [![《流程示意图》](09-Spring MVC 源码分析-请求处理一览.assets/03.png)](http://static.iocoder.cn/images/Spring/2022-02-21/03.png)《流程示意图》
+
+------
+
+参考和推荐如下文章：
+
+- 田小波 [《Spring MVC 原理探秘 - 一个请求的旅行过程》](https://www.tianxiaobo.com/2018/06/29/Spring-MVC-原理探秘-一个请求的旅行过程/)
+- 郝佳 [《Spring 源码深度解析》](https://item.jd.com/11311737.html) 的 [「11.3 DispatcherServlet」](https://svip.iocoder.cn/Spring-MVC/DispatcherServlet-process-request-intro/#) 小节
+- 韩路彪 [《看透 Spring MVC：源代码分析与实践》](https://item.jd.com/11807414.html) 的 [「第10章 Spring MVC 之用」](https://svip.iocoder.cn/Spring-MVC/DispatcherServlet-process-request-intro/#) 小节
\ No newline at end of file
diff --git a/springmvc/10-Spring MVC 源码分析-HandlerMapping 组件（一）之 AbstractHandlerMapping.assets/01.png b/springmvc/10-Spring MVC 源码分析-HandlerMapping 组件（一）之 AbstractHandlerMapping.assets/01.png
new file mode 100644
index 0000000..e54f861
Binary files /dev/null and b/springmvc/10-Spring MVC 源码分析-HandlerMapping 组件（一）之 AbstractHandlerMapping.assets/01.png differ
diff --git a/springmvc/10-Spring MVC 源码分析-HandlerMapping 组件（一）之 AbstractHandlerMapping.md b/springmvc/10-Spring MVC 源码分析-HandlerMapping 组件（一）之 AbstractHandlerMapping.md
new file mode 100644
index 0000000..b9ad967
--- /dev/null
+++ b/springmvc/10-Spring MVC 源码分析-HandlerMapping 组件（一）之 AbstractHandlerMapping.md	
@@ -0,0 +1,632 @@
+# 精尽 Spring MVC 源码分析 —— HandlerMapping 组件（一）之 AbstractHandlerMapping
+
+# 1. 概述
+
+本文，我们来分享 HandlerMapping 组件。在 [《精尽 Spring MVC 源码分析 —— 组件一览》](http://svip.iocoder.cn/Spring-MVC/Components-intro) 中，我们对它已经做了介绍：
+
+`org.springframework.web.servlet.HandlerMapping` ，处理器匹配接口，根据请求( `handler` )获得其的处理器( `handler` )和拦截器们( HandlerInterceptor 数组 )。代码如下：
+
+```
+// HandlerMapping.java
+
+public interface HandlerMapping {
+
+    String PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE = HandlerMapping.class.getName() + ".pathWithinHandlerMapping";
+    String BEST_MATCHING_PATTERN_ATTRIBUTE = HandlerMapping.class.getName() + ".bestMatchingPattern";
+    String INTROSPECT_TYPE_LEVEL_MAPPING = HandlerMapping.class.getName() + ".introspectTypeLevelMapping";
+    String URI_TEMPLATE_VARIABLES_ATTRIBUTE = HandlerMapping.class.getName() + ".uriTemplateVariables";
+    String MATRIX_VARIABLES_ATTRIBUTE = HandlerMapping.class.getName() + ".matrixVariables";
+    String PRODUCIBLE_MEDIA_TYPES_ATTRIBUTE = HandlerMapping.class.getName() + ".producibleMediaTypes";
+
+    /**
+     * 获得请求对应的处理器和拦截器们
+     */
+    @Nullable
+    HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception;
+
+}
+```
+
+- 返回的对象类型是 HandlerExecutionChain ，它包含处理器( `handler` )和拦截器们( HandlerInterceptor 数组 )。
+
+# 2. 类图
+
+HandlerMapping 的子类比较多，整体类图如下：
+
+[![类图](10-Spring MVC 源码分析-HandlerMapping 组件（一）之 AbstractHandlerMapping.assets/01.png)](http://static.iocoder.cn/images/Spring/2022-03-01/01.png)类图
+
+- 绿框 **AbstractHandlerMapping** 抽象类，实现了【获得请求对应的处理器和拦截器们】的骨架逻辑，而暴露 `#getHandlerInternal(HttpServletRequest request)` 抽象方法，交由子类实现。这就是我们常说的[“模板方法模式”](http://www.iocoder.cn/DesignPattern/xiaomingge/Template-Method/) 。
+- AbstractHandlerMapping 的子类，分成两派，分别是：
+  - 红框 **AbstractUrlHandlerMapping** 系，基于 URL 进行匹配。例如 [《基于XML配置的Spring MVC 简单的HelloWorld实例应用》](https://www.cnblogs.com/liuhongfeng/p/4769076.html) 。当然，实际我们开发时，这种方式已经基本不用了，被 `@RequestMapping` 等注解的方式所取代。不过，Spring MVC 内置的一些路径匹配，还是使用这种方式。
+  - 黄框 **AbstractHandlerMethodMapping** 系，基于 Method 进行匹配。例如，我们所熟知的 `@RequestMapping` 等注解的方式。
+- 白框 MatchableHandlerMapping 接口，定义判断请求和指定 `pattern` 路径是否匹配的接口方法。详细的，我们在 [「4. MatchableHandlerMapping」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-1-AbstractHandlerMapping/#) 中来看。
+
+------
+
+考虑到文章的篇幅和更加干净，我们拆分成三篇文章：
+
+- 本文，分享 AbstractHandlerMapping 抽象类、MatchableHandlerMapping 接口
+- 下文，分享 AbstractHandlerMethodMapping 系
+- 下下文，分享 AbstractUrlHandlerMapping 系
+
+😈 看源码，实际上，要一块一块拆解出来，从整体到局部，一点一点来啃。
+
+# 3. AbstractHandlerMapping
+
+`org.springframework.web.servlet.handler.AbstractHandlerMapping` ，实现 **HandlerMapping**、Ordered、BeanNameAware 接口，继承 WebApplicationObjectSupport 抽象类，HandlerMapping **抽象基类**，实现了【获得请求对应的处理器和拦截器们】的骨架逻辑，而暴露 `#getHandlerInternal(HttpServletRequest request)` 抽象方法，交由子类实现。
+
+> WebApplicationObjectSupport 抽象类，提供 `applicationContext` 属性的声明和注入。
+
+## 3.1 构造方法
+
+```
+// AbstractHandlerMapping.java
+
+/**
+ * 默认处理器
+ */
+@Nullable
+private Object defaultHandler;
+
+/**
+ * URL 路径工具类
+ */
+private UrlPathHelper urlPathHelper = new UrlPathHelper();
+
+/**
+ * 路径匹配器
+ */
+private PathMatcher pathMatcher = new AntPathMatcher();
+
+/**
+ * 配置的拦截器数组.
+ *
+ * 在 {@link #initInterceptors()} 方法中，初始化到 {@link #adaptedInterceptors} 中
+ *
+ * 添加方式有两种：
+ *
+ * 1. {@link #setInterceptors(Object...)} 方法
+ * 2. {@link #extendInterceptors(List)} 方法
+ */
+private final List<Object> interceptors = new ArrayList<>();
+
+/**
+ * 初始化后的拦截器 HandlerInterceptor 数组
+ */
+private final List<HandlerInterceptor> adaptedInterceptors = new ArrayList<>();
+
+/**
+ * TODO cors
+ */
+private CorsConfigurationSource corsConfigurationSource = new UrlBasedCorsConfigurationSource();
+
+/**
+ * TODO cors
+ */
+private CorsProcessor corsProcessor = new DefaultCorsProcessor();
+
+/**
+ * 顺序
+ */
+private int order = Ordered.LOWEST_PRECEDENCE;  // default: same as non-Ordered
+
+/**
+ * Bean 名字
+ */
+@Nullable
+private String beanName;
+```
+
+- `defaultHandler` 属性，**默认**处理器。在获得不到处理器时，可使用该属性。
+
+- `interceptors` 属性，**配置**的拦截器数组。注释，胖友需要详细看看。其中，`#setInterceptors(Object... interceptors)` 方法，代码如下：
+
+  ```
+  // AbstractHandlerMapping.java
+  
+  public void setInterceptors(Object... interceptors) {
+  	this.interceptors.addAll(Arrays.asList(interceptors));
+  }
+  ```
+
+- `adaptedInterceptors` 属性，**初始化后**的拦截器 HandlerInterceptor 数组。
+
+- TODO 1012 cors
+
+## 3.2 initApplicationContext
+
+> 该方法，是对 WebApplicationObjectSupport 的覆写，而 WebApplicationObjectSupport 的集成关系是 WebApplicationObjectSupport => ApplicationObjectSupport => ApplicationContextAware 。
+
+`#initApplicationContext()` 方法，初始化拦截器。代码如下：
+
+```
+// AbstractHandlerMapping.java
+
+@Override
+protected void initApplicationContext() throws BeansException {
+    // <1> 空方法。交给子类实现，用于注册自定义的拦截器到 interceptors 中。目前暂无子类实现。
+    extendInterceptors(this.interceptors);
+    // <2> 扫描已注册的 MappedInterceptor 的 Bean 们，添加到 mappedInterceptors 中
+    detectMappedInterceptors(this.adaptedInterceptors);
+    // <3> 将 interceptors 初始化成 HandlerInterceptor 类型，添加到 mappedInterceptors 中
+    initInterceptors();
+}
+```
+
+- `<1>` 处，调用 `#extendInterceptors(List<Object> interceptors)` 方法，空方法。交给子类实现，用于注册自定义的拦截器到 `interceptors` 中。目前暂无子类实现。代码如下：
+
+  ```
+  // AbstractHandlerMapping.java
+  
+  protected void extendInterceptors(List<Object> interceptors) {
+  }
+  ```
+
+  - 😈 所以，可以无视这个方法先。
+
+- `<2>` 处，调用 `#detectMappedInterceptors(List<HandlerInterceptor> mappedInterceptors)` 方法，扫描已注册的 MappedInterceptor 的 Bean 们，添加到 `mappedInterceptors` 中。代码如下：
+
+  ```
+  // AbstractHandlerMapping.java
+  
+  protected void detectMappedInterceptors(List<HandlerInterceptor> mappedInterceptors) {
+  	// 扫描已注册的 MappedInterceptor 的 Bean 们，添加到 mappedInterceptors 中
+  	// MappedInterceptor 会根据请求路径做匹配，是否进行拦截。
+  	mappedInterceptors.addAll(
+  			BeanFactoryUtils.beansOfTypeIncludingAncestors(
+  					obtainApplicationContext(), MappedInterceptor.class, true, false).values());
+  }
+  ```
+
+  - 为什么会扫描 MappedInterceptor 的 Bean 们？详细解析，见 [《精尽 Spring MVC 源码分析 —— HandlerMapping 组件（二）之 HandlerInterceptor》](http://svip.iocoder.cn/Spring-MVC/HandlerMapping-2-HandlerInterceptor) 的 [「5.1 `` 标签」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-1-AbstractHandlerMapping/#)。
+  - 英文 detect 的中文解释是检测，和扫描基本是一个意思。
+  - 调用 `BeanFactoryUtils#beansOfTypeIncludingAncestors(ListableBeanFactory lbf, Class<T> type, boolean includeNonSingletons, boolean allowEagerInit)` 方法，扫描已注册的 MappedInterceptor 的 Bean 们，然后添加到 `mappedInterceptors` 中。关于这个方法的实现，胖友自己瞅瞅前面 Spring IOC 的文章。😈 当然，也可以先不看。嘿嘿。
+  - 关于 MappedInterceptor 拦截器类，会根据请求路径做匹配，是否进行拦截。详细解析，见 [《精尽 Spring MVC 源码分析 —— HandlerMapping 组件（二）之 HandlerInterceptor》](http://svip.iocoder.cn/Spring-MVC/HandlerMapping-2-HandlerInterceptor) 的 [「4.1 MappedInterceptor](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-1-AbstractHandlerMapping/#)。
+
+- `<3>` 处，调用 `#initInterceptors()` 方法，将 `interceptors` 初始化成 HandlerInterceptor 类型，添加到 `mappedInterceptors` 中。代码如下：
+
+  ```
+  // AbstractHandlerMapping.java
+  
+  protected void initInterceptors() {
+      if (!this.interceptors.isEmpty()) {
+          // 遍历 interceptors 数组
+          for (int i = 0; i < this.interceptors.size(); i++) {
+              // 获得 interceptor 对象
+              Object interceptor = this.interceptors.get(i);
+              if (interceptor == null) { // 若为空，抛出 IllegalArgumentException 异常
+                  throw new IllegalArgumentException("Entry number " + i + " in interceptors array is null");
+              }
+              // 将 interceptors 初始化成 HandlerInterceptor 类型，添加到 mappedInterceptors 中
+              // 注意，HandlerInterceptor 无需进行路径匹配，直接拦截全部
+              this.adaptedInterceptors.add(adaptInterceptor(interceptor)); // <x>
+          }
+      }
+  }
+  ```
+
+  - 代码比较简单，胖友自己瞅瞅即可。
+
+  - `<x>` 处，调用 `#adaptInterceptor(Object interceptor)` 方法，将 `interceptors` 初始化成 HandlerInterceptor 类型。代码如下：
+
+    ```
+    // AbstractHandlerMapping.java
+    
+    protected HandlerInterceptor adaptInterceptor(Object interceptor) {
+    	// HandlerInterceptor 类型，直接返回
+    	if (interceptor instanceof HandlerInterceptor) {
+    		return (HandlerInterceptor) interceptor;
+     	// WebRequestInterceptor 类型，适配成 WebRequestHandlerInterceptorAdapter 对象，然后返回
+    	} else if (interceptor instanceof WebRequestInterceptor) {
+    		return new WebRequestHandlerInterceptorAdapter((WebRequestInterceptor) interceptor);
+    	// 错误类型，抛出 IllegalArgumentException 异常
+    	} else {
+    		throw new IllegalArgumentException("Interceptor type not supported: " + interceptor.getClass().getName());
+    	}
+    }
+    ```
+
+    - 比较好理解。关于 HandlerInterceptor、WebRequestInterceptor、WebRequestHandlerInterceptorAdapter 的拦截器类，TODO 1008
+
+## 3.3 getHandler
+
+`#getHandler(HttpServletRequest request)` 方法，获得请求对应的 HandlerExecutionChain 对象。代码如下：
+
+```
+// AbstractHandlerMapping.java
+
+@Override
+@Nullable
+public final HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {
+    // <1> 获得处理器。该方法是抽象方法，由子类实现
+    Object handler = getHandlerInternal(request);
+    // <2> 获得不到，则使用默认处理器
+    if (handler == null) {
+        handler = getDefaultHandler();
+    }
+    // <3> 还是获得不到，则返回 null
+    if (handler == null) {
+        return null;
+    }
+    // Bean name or resolved handler?
+    // <4> 如果找到的处理器是 String 类型，则从容器中找到 String 对应的 Bean 类型作为处理器。
+    // TODO 芋艿，什么情况？？？
+    if (handler instanceof String) {
+        String handlerName = (String) handler;
+        handler = obtainApplicationContext().getBean(handlerName);
+    }
+
+    // <5> 获得 HandlerExecutionChain 对象
+    HandlerExecutionChain executionChain = getHandlerExecutionChain(handler, request);
+
+    // 打印日志
+    if (logger.isTraceEnabled()) {
+        logger.trace("Mapped to " + handler);
+    }
+    else if (logger.isDebugEnabled() && !request.getDispatcherType().equals(DispatcherType.ASYNC)) {
+        logger.debug("Mapped to " + executionChain.getHandler());
+    }
+
+    // <6> TODO 芋艿 cors
+    if (CorsUtils.isCorsRequest(request)) {
+        CorsConfiguration globalConfig = this.corsConfigurationSource.getCorsConfiguration(request);
+        CorsConfiguration handlerConfig = getCorsConfiguration(handler, request);
+        CorsConfiguration config = (globalConfig != null ? globalConfig.combine(handlerConfig) : handlerConfig);
+        executionChain = getCorsHandlerExecutionChain(request, executionChain, config);
+    }
+
+    // <7> 返回    
+    return executionChain;
+}
+```
+
+- `<1>` 处，调用 `#getHandlerInternal(HttpServletRequest request)` **抽象**方法，获得 `handler` 对象。代码如下：
+
+  ```
+  // AbstractHandlerMapping.java 
+  
+  @Nullable
+  protected abstract Object getHandlerInternal(HttpServletRequest request) throws Exception;
+  ```
+
+- `<2>` 处，获得不到，则调用 `#getDefaultHandler()` 方法，使用默认处理器。代码如下：
+
+  ```
+  // AbstractHandlerMapping.java
+  
+  public Object getDefaultHandler() {
+  	return this.defaultHandler;
+  }
+  ```
+
+  - 😈 实际上，我们一般不太会设置默认处理器。
+
+- `<3>` 处，还是获得不到，则返回 `null` 。
+
+- `<4>` 处，如果找到的处理器是 String 类型，则调用 `BeanFactory#getBean(String name)` 方法，从容器中找到 String 对应的 Bean 类型作为处理器。
+
+- `<5>` 处，调用 `#getHandlerExecutionChain(Object handler, HttpServletRequest request)` 方法，获得 HandlerExecutionChain 对象。代码如下：
+
+  ```
+  // AbstractHandlerMapping.java
+  
+  protected HandlerExecutionChain getHandlerExecutionChain(Object handler, HttpServletRequest request) {
+      // 创建 HandlerExecutionChain 对象
+      HandlerExecutionChain chain = (handler instanceof HandlerExecutionChain ?
+              (HandlerExecutionChain) handler : new HandlerExecutionChain(handler));
+  
+      // 获得请求路径
+      String lookupPath = this.urlPathHelper.getLookupPathForRequest(request);
+      // 遍历 adaptedInterceptors 数组，获得请求匹配的拦截器
+      for (HandlerInterceptor interceptor : this.adaptedInterceptors) {
+          // 需要匹配，若路径匹配，则添加到 chain 中
+          if (interceptor instanceof MappedInterceptor) {
+              MappedInterceptor mappedInterceptor = (MappedInterceptor) interceptor;
+              if (mappedInterceptor.matches(lookupPath, this.pathMatcher)) { // 匹配
+                  chain.addInterceptor(mappedInterceptor.getInterceptor());
+              }
+          // 无需匹配，直接添加到 chain 中
+          } else {
+              chain.addInterceptor(interceptor);
+          }
+      }
+      return chain;
+  }
+  ```
+
+  - 虽然代码比较长，但是重心在于从 `adaptedInterceptors` 中，获得请求路径对应的**符合**的 HandlerInterceptor 数组。实际上，只有 MappedInterceptor 类型的拦截器，需要进行匹配。
+
+- `<6>` 处，TODO 1012 芋艿 cors
+
+- `<7>` 处，返回 `<5>` 处创建的 HandlerExecutionChain 对象。
+
+# 4. MatchableHandlerMapping
+
+`org.springframework.web.servlet.handler.MatchableHandlerMapping` ，定义判断请求和指定 `pattern` 路径是否匹配的接口方法。代码如下：
+
+```
+// MatchableHandlerMapping.java
+
+public interface MatchableHandlerMapping extends HandlerMapping {
+
+	/**
+     * 判断请求和指定 `pattern` 路径是否匹配的接口方法
+     *
+	 * Determine whether the given request matches the request criteria.
+	 * @param request the current request
+	 * @param pattern the pattern to match
+	 * @return the result from request matching, or {@code null} if none
+	 */
+	@Nullable
+	RequestMatchResult match(HttpServletRequest request, String pattern);
+
+}
+```
+
+- 返回的是 `org.springframework.web.servlet.handler.RequestMatchResult` 类，请求匹配结果。代码如下：
+
+  ```
+  // RequestMatchResult.java
+  
+  public class RequestMatchResult {
+  
+      /**
+       * 匹配上的路径
+       */
+  	private final String matchingPattern;
+  
+      /**
+       * 被匹配的路径
+       */
+  	private final String lookupPath;
+  
+      /**
+       * 路径匹配器
+       */
+  	private final PathMatcher pathMatcher;
+  
+  	/**
+  	 * Create an instance with a matching pattern.
+  	 * @param matchingPattern the matching pattern, possibly not the same as the
+  	 * input pattern, e.g. inputPattern="/foo" and matchingPattern="/foo/".
+  	 * @param lookupPath the lookup path extracted from the request
+  	 * @param pathMatcher the PathMatcher used
+  	 */
+  	public RequestMatchResult(String matchingPattern, String lookupPath, PathMatcher pathMatcher) {
+  		Assert.hasText(matchingPattern, "'matchingPattern' is required");
+  		Assert.hasText(lookupPath, "'lookupPath' is required");
+  		Assert.notNull(pathMatcher, "'pathMatcher' is required");
+  		this.matchingPattern = matchingPattern;
+  		this.lookupPath = lookupPath;
+  		this.pathMatcher = pathMatcher;
+  	}
+  
+  
+  	/**
+  	 * Extract URI template variables from the matching pattern as defined in
+  	 * {@link PathMatcher#extractUriTemplateVariables}.
+  	 * @return a map with URI template variables
+  	 */
+  	public Map<String, String> extractUriTemplateVariables() {
+  		return this.pathMatcher.extractUriTemplateVariables(this.matchingPattern, this.lookupPath);
+  	}
+  
+  }
+  ```
+
+- 目前实现 MatchableHandlerMapping 接口的类，有 RequestMappingHandlerMapping 类和 AbstractUrlHandlerMapping 抽象类。
+
+可能胖友现在看 `#match(HttpServletRequest request, String pattern)` 方法有点懵逼？！淡定。我们会在后续的文章，详细解析的。
+
+# 5. DispatcherServlet
+
+在 DispatcherServlet 中，通过调用 `#initHandlerMappings(ApplicationContext context)` 方法，初始化 HandlerMapping 们。酱紫，HandlerMapping 就集成到 DispatcherServlet 中了。代码如下：
+
+```
+// DispatcherServlet.java
+
+/**
+ * Well-known name for the HandlerMapping object in the bean factory for this namespace.
+ * Only used when "detectAllHandlerMappings" is turned off.
+ * @see #setDetectAllHandlerMappings
+ */
+public static final String HANDLER_MAPPING_BEAN_NAME = "handlerMapping";
+
+/** Detect all HandlerMappings or just expect "handlerMapping" bean?. */
+private boolean detectAllHandlerMappings = true;
+
+/** List of HandlerMappings used by this servlet. */
+@Nullable
+private List<HandlerMapping> handlerMappings;
+
+private void initHandlerMappings(ApplicationContext context) {
+    // 置空 handlerMappings
+    this.handlerMappings = null;
+
+    // <1> 如果开启探测功能，则扫描已注册的 HandlerMapping 的 Bean 们，添加到 handlerMappings 中
+    if (this.detectAllHandlerMappings) {
+        // Find all HandlerMappings in the ApplicationContext, including ancestor contexts.
+        // 扫描已注册的 HandlerMapping 的 Bean 们
+        Map<String, HandlerMapping> matchingBeans =
+                BeanFactoryUtils.beansOfTypeIncludingAncestors(context, HandlerMapping.class, true, false);
+        // 添加到 handlerMappings 中，并进行排序
+        if (!matchingBeans.isEmpty()) {
+            this.handlerMappings = new ArrayList<>(matchingBeans.values());
+            // We keep HandlerMappings in sorted order.
+            AnnotationAwareOrderComparator.sort(this.handlerMappings);
+        }
+    // <2> 如果关闭探测功能，则获得 HANDLER_MAPPING_BEAN_NAME 对应的 Bean 对象，并设置为 handlerMappings
+    } else {
+        try {
+            HandlerMapping hm = context.getBean(HANDLER_MAPPING_BEAN_NAME, HandlerMapping.class);
+            this.handlerMappings = Collections.singletonList(hm);
+        } catch (NoSuchBeanDefinitionException ex) {
+            // Ignore, we'll add a default HandlerMapping later.
+        }
+    }
+
+    // Ensure we have at least one HandlerMapping, by registering
+    // a default HandlerMapping if no other mappings are found.
+    // <3> 如果未获得到，则获得默认配置的 HandlerMapping 类
+    if (this.handlerMappings == null) {
+        this.handlerMappings = getDefaultStrategies(context, HandlerMapping.class);
+        if (logger.isTraceEnabled()) {
+            logger.trace("No HandlerMappings declared for servlet '" + getServletName() +
+                    "': using default strategies from DispatcherServlet.properties");
+        }
+    }
+}
+```
+
+- `<1>` 处，如果开启探测功能，则扫描已注册的 HandlerMapping 的 Bean 们，添加到 `handlerMappings` 中。
+
+- `<2>` 处，如果关闭探测功能，则获得 `HANDLER_MAPPING_BEAN_NAME`( `"handlerMapping"` ) 对应的 Bean 对象，并设置为 `handlerMappings` 。
+
+- `<3>` 处，如果未获得到，则调用 `#getDefaultStrategies(ApplicationContext context, Class<T> strategyInterface)` 方法，获得默认配置的 HandlerMapping 类。代码如下：
+
+  ```
+  // DispatcherServlet.java
+  
+  protected <T> List<T> getDefaultStrategies(ApplicationContext context, Class<T> strategyInterface) {
+  	// <1> 获得 strategyInterface 对应的 value 值
+      String key = strategyInterface.getName();
+  	String value = defaultStrategies.getProperty(key);
+  	// <2> 创建 value 对应的对象们，并返回
+  	if (value != null) {
+  	    // 基于 "," 分隔，创建 classNames 数组
+  		String[] classNames = StringUtils.commaDelimitedListToStringArray(value);
+  		// 创建 strategyInterface 集合
+  		List<T> strategies = new ArrayList<>(classNames.length);
+  		// 遍历 classNames 数组，创建对应的类，添加到 strategyInterface 中
+  		for (String className : classNames) {
+  			try {
+  			    // 获得 className 类
+  				Class<?> clazz = ClassUtils.forName(className, DispatcherServlet.class.getClassLoader());
+  				// 创建 className 对应的类，并添加到 strategies 中
+  				Object strategy = createDefaultStrategy(context, clazz);
+  				strategies.add((T) strategy);
+  			} catch (ClassNotFoundException ex) {
+  				throw new BeanInitializationException(
+  						"Could not find DispatcherServlet's default strategy class [" + className +
+  						"] for interface [" + key + "]", ex);
+  			} catch (LinkageError err) {
+  				throw new BeanInitializationException(
+  						"Unresolvable class definition for DispatcherServlet's default strategy class [" +
+  						className + "] for interface [" + key + "]", err);
+  			}
+  		}
+  		// 返回 strategies
+  		return strategies;
+  	} else {
+  		return new LinkedList<>();
+  	}
+  }
+  ```
+
+  - 实际上，这是个通用的方法，提供给不同的 `strategyInterface` 接口，获得对应的类型的**数组**。
+
+  - `<1>` 处，获得 `strategyInterface` 对应的 `value` 值。
+
+  - 关于 `defaultStrategies` 属性，涉及的代码如下：
+
+    ```
+    // DispatcherServlet.java
+    
+    /**
+     * Name of the class path resource (relative to the DispatcherServlet class)
+     * that defines DispatcherServlet's default strategy names.
+     */
+    private static final String DEFAULT_STRATEGIES_PATH = "DispatcherServlet.properties";
+    
+    /**
+     * 默认配置类
+     */
+    private static final Properties defaultStrategies;
+    
+    static {
+    	// Load default strategy implementations from properties file.
+    	// This is currently strictly internal and not meant to be customized
+    	// by application developers.
+    	try {
+    	    // 初始化 defaultStrategies
+    		ClassPathResource resource = new ClassPathResource(DEFAULT_STRATEGIES_PATH, DispatcherServlet.class);
+    		defaultStrategies = PropertiesLoaderUtils.loadProperties(resource);
+    	} catch (IOException ex) {
+    		throw new IllegalStateException("Could not load '" + DEFAULT_STRATEGIES_PATH + "': " + ex.getMessage());
+    	}
+    }
+    ```
+
+    - 其中，`DispatcherServlet.properties` 的配置如下：
+
+      ```
+      org.springframework.web.servlet.LocaleResolver=org.springframework.web.servlet.i18n.AcceptHeaderLocaleResolver
+      
+      org.springframework.web.servlet.ThemeResolver=org.springframework.web.servlet.theme.FixedThemeResolver
+      
+      org.springframework.web.servlet.HandlerMapping=org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping,\
+      	org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping
+      
+      org.springframework.web.servlet.HandlerAdapter=org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter,\
+      	org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter,\
+      	org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter
+      
+      org.springframework.web.servlet.HandlerExceptionResolver=org.springframework.web.servlet.mvc.method.annotation.ExceptionHandlerExceptionResolver,\
+      	org.springframework.web.servlet.mvc.annotation.ResponseStatusExceptionResolver,\
+      	org.springframework.web.servlet.mvc.support.DefaultHandlerExceptionResolver
+      
+      org.springframework.web.servlet.RequestToViewNameTranslator=org.springframework.web.servlet.view.DefaultRequestToViewNameTranslator
+      
+      org.springframework.web.servlet.ViewResolver=org.springframework.web.servlet.view.InternalResourceViewResolver
+      
+      org.springframework.web.servlet.FlashMapManager=org.springframework.web.servlet.support.SessionFlashMapManager
+      ```
+
+      - 我们可以看到，HandlerMapping 接口，对应的是 BeanNameUrlHandlerMapping 和 RequestMappingHandlerMapping 类。
+
+  - `<2>` 处，创建 `value` 对应的对象们，并返回。代码量比较多，但是比较简单，胖友自己瞅瞅。其中，`#createDefaultStrategy(ApplicationContext context, Class<?> clazz)` 方法，创建对象。代码如下：
+
+    ```
+    // DispatcherServlet.java
+    
+    protected Object createDefaultStrategy(ApplicationContext context, Class<?> clazz) {
+    	return context.getAutowireCapableBeanFactory().createBean(clazz);
+    }
+    ```
+
+    - 是通过 Spring IOC 容器，进行创建对象。
+
+------
+
+然后，我们在回过头看看 DispatcherServlet 对 `handlerMappings` 的使用，在 `#getHandler(HttpServletRequest request)` 方法中，代码如下：
+
+```
+// DispatcherServlet.java
+
+@Nullable
+protected HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {
+    if (this.handlerMappings != null) {
+        // 遍历 HandlerMapping 数组
+        for (HandlerMapping mapping : this.handlerMappings) {
+            // 获得请求对应的 HandlerExecutionChain 对象
+            HandlerExecutionChain handler = mapping.getHandler(request);
+            // 获得到，则返回
+            if (handler != null) {
+                return handler;
+            }
+        }
+    }
+    return null;
+}
+```
+
+- 就不详细解释了。现在一看，是否就明白多了？？😝
+
+# 666. 彩蛋
+
+下面一篇文章，我们先分享 HandlerInterceptor 拦截器，再分享 AbstractHandlerMethodMapping、AbstractUrlHandlerMapping 类。因为，后两者，对拦截器是有依赖的。
+
+参考和推荐如下文章：
+
+- 郝佳 [《Spring 源码深度解析》](https://item.jd.com/11311737.html) 的 [「11.3 DispatcherServlet」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-1-AbstractHandlerMapping/#) 小节
+- 韩路彪 [《看透 Spring MVC：源代码分析与实践》](https://item.jd.com/11807414.html) 的 [「第12章 HandlerMapping」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-1-AbstractHandlerMapping/#) 小节
\ No newline at end of file
diff --git a/springmvc/11-Spring MVC 源码分析-HandlerMapping 组件（二）之 HandlerInterceptor.assets/01.png b/springmvc/11-Spring MVC 源码分析-HandlerMapping 组件（二）之 HandlerInterceptor.assets/01.png
new file mode 100644
index 0000000..45df5e3
Binary files /dev/null and b/springmvc/11-Spring MVC 源码分析-HandlerMapping 组件（二）之 HandlerInterceptor.assets/01.png differ
diff --git a/springmvc/11-Spring MVC 源码分析-HandlerMapping 组件（二）之 HandlerInterceptor.md b/springmvc/11-Spring MVC 源码分析-HandlerMapping 组件（二）之 HandlerInterceptor.md
new file mode 100644
index 0000000..25cf52d
--- /dev/null
+++ b/springmvc/11-Spring MVC 源码分析-HandlerMapping 组件（二）之 HandlerInterceptor.md	
@@ -0,0 +1,679 @@
+# 精尽 Spring MVC 源码分析 —— HandlerMapping 组件（二）之 HandlerInterceptor
+
+# 1. 概述
+
+本文，我们来分享 Spring MVC 的拦截器，可能是大家最最最熟悉的组件。如果胖友没有实现过自定义的 Spring MVC 的拦截器，那可能有丢丢遗憾。所以，在看这篇文章之余，胖友也可以自己去尝试写一个 Spring MVC 的拦截器。
+
+# 2. HandlerInterceptor
+
+`org.springframework.web.servlet.HandlerInterceptor` ，处理器拦截器接口。代码如下：
+
+```
+// HandlerInterceptor.java
+
+public interface HandlerInterceptor {
+
+    /**
+     * 拦截处理器，在 {@link HandlerAdapter#handle(HttpServletRequest, HttpServletResponse, Object)} 执行之前
+     */
+    default boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)
+            throws Exception {
+        return true;
+    }
+
+    /**
+     * 拦截处理器，在 {@link HandlerAdapter#handle(HttpServletRequest, HttpServletResponse, Object)} 执行成功之后
+     */
+    default void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler,
+            @Nullable ModelAndView modelAndView) throws Exception {
+    }
+
+    /**
+     * 拦截处理器，在 {@link HandlerAdapter} 执行完之后，无论成功还是失败
+     *
+     * 并且，只有 {@link #preHandle(HttpServletRequest, HttpServletResponse, Object)} 执行成功之后，才会被执行
+     */
+    default void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler,
+            @Nullable Exception ex) throws Exception {
+    }
+
+}
+```
+
+一共有三个方法，胖友看看方法上的注释。
+
+# 3. HandlerExecutionChain
+
+`org.springframework.web.servlet.HandlerExecutionChain` ，处理器执行链。
+
+## 3.1 构造方法
+
+```
+// HandlerExecutionChain.java
+
+/**
+ * 处理器
+ */
+private final Object handler;
+/**
+ * 拦截器数组
+ */
+@Nullable
+private HandlerInterceptor[] interceptors;
+/**
+ * 拦截器数组。
+ *
+ * 在实际使用时，会调用 {@link #getInterceptors()} 方法，初始化到 {@link #interceptors} 中
+ */
+@Nullable
+private List<HandlerInterceptor> interceptorList;
+
+/**
+ * 已执行 {@link HandlerInterceptor#preHandle(HttpServletRequest, HttpServletResponse, Object)} 的位置
+ *
+ * 主要用于实现 {@link #applyPostHandle(HttpServletRequest, HttpServletResponse, ModelAndView)} 的逻辑
+ */
+private int interceptorIndex = -1;
+
+/**
+ * Create a new HandlerExecutionChain.
+ * @param handler the handler object to execute
+ */
+public HandlerExecutionChain(Object handler) {
+    this(handler, (HandlerInterceptor[]) null);
+}
+
+/**
+ * Create a new HandlerExecutionChain.
+ * @param handler the handler object to execute
+ * @param interceptors the array of interceptors to apply
+ * (in the given order) before the handler itself executes
+ */
+public HandlerExecutionChain(Object handler, @Nullable HandlerInterceptor... interceptors) {
+    if (handler instanceof HandlerExecutionChain) {
+        HandlerExecutionChain originalChain = (HandlerExecutionChain) handler;
+        this.handler = originalChain.getHandler();
+        // 初始化到 interceptorList 中
+        this.interceptorList = new ArrayList<>();
+        CollectionUtils.mergeArrayIntoCollection(originalChain.getInterceptors(), this.interceptorList); // 逻辑比较简单，就是将前者添加到后者中，即添加到 interceptorList 中
+        CollectionUtils.mergeArrayIntoCollection(interceptors, this.interceptorList); // 逻辑比较简单，就是将前者添加到后者中，即添加到 interceptorList 中
+    } else {
+        this.handler = handler;
+        this.interceptors = interceptors;
+    }
+}
+```
+
+## 3.2 addInterceptor
+
+`#addInterceptor(HandlerInterceptor interceptor)` 方法，添加拦截器到 `interceptorList` 中。代码如下：
+
+```
+// HandlerExecutionChain.java
+
+public void addInterceptor(HandlerInterceptor interceptor) {
+	initInterceptorList().add(interceptor);
+}
+```
+
+- 首先，会调用 `#initInterceptorList()` 方法，保证 `interceptorList` 已初始化。代码如下：
+
+  ```
+  // HandlerExecutionChain.java
+  
+  private List<HandlerInterceptor> initInterceptorList() {
+  	// 如果 interceptorList 为空，则初始化为 ArrayList
+  	if (this.interceptorList == null) {
+  		this.interceptorList = new ArrayList<>();
+  		// 如果 interceptors 非空，则添加到 interceptorList 中
+  		if (this.interceptors != null) {
+  			// An interceptor array specified through the constructor
+  			CollectionUtils.mergeArrayIntoCollection(this.interceptors, this.interceptorList);
+  		}
+  	}
+  	// 置空 interceptors
+  	this.interceptors = null;
+  	// 返回 interceptorList
+  	return this.interceptorList;
+  }
+  ```
+
+  - 虽然代码有点长，但是逻辑很简单。实际上，我们将 `interceptorList` 是 `interceptors` 的**配置**。
+
+- 然后，添加 `interceptor` 到 `interceptorList` 中。
+
+------
+
+`#addInterceptor(HandlerInterceptor interceptor)` 方法，添加拦截器们到 `interceptorList` 中。代码如下：
+
+```
+// HandlerExecutionChain.java
+
+public void addInterceptors(HandlerInterceptor... interceptors) {
+	if (!ObjectUtils.isEmpty(interceptors)) {
+		CollectionUtils.mergeArrayIntoCollection(interceptors, initInterceptorList());
+	}
+}
+```
+
+## 3.3 getInterceptors
+
+`#getInterceptors()` 方法，获得 `interceptors` 数组。代码如下：
+
+```
+// HandlerExecutionChain.java
+
+@Nullable
+public HandlerInterceptor[] getInterceptors() {
+	// 将 interceptorList 初始化到 interceptors 中
+	if (this.interceptors == null && this.interceptorList != null) {
+		this.interceptors = this.interceptorList.toArray(new HandlerInterceptor[0]);
+	}
+	// 返回 interceptors 数组
+	return this.interceptors;
+}
+```
+
+## 3.4 applyPreHandle
+
+`#applyPreHandle(HttpServletRequest request, HttpServletResponse response)` 方法，应用拦截器的前置处理。代码如下：
+
+```
+// HandlerExecutionChain.java
+
+/**
+ * 应用拦截器的前置处理
+ *
+ * Apply preHandle methods of registered interceptors.
+ * @return {@code true} if the execution chain should proceed with the
+ * next interceptor or the handler itself. Else, DispatcherServlet assumes
+ * that this interceptor has already dealt with the response itself.
+ */
+boolean applyPreHandle(HttpServletRequest request, HttpServletResponse response) throws Exception {
+    // <1> 获得拦截器数组
+    HandlerInterceptor[] interceptors = getInterceptors();
+    if (!ObjectUtils.isEmpty(interceptors)) {
+        // <2> 遍历拦截器数组
+        for (int i = 0; i < interceptors.length; i++) {
+            HandlerInterceptor interceptor = interceptors[i];
+            // <3> 前置处理
+            if (!interceptor.preHandle(request, response, this.handler)) {
+                // <3.1> 触发已完成处理
+                triggerAfterCompletion(request, response, null);
+                // 返回 false ，前置处理失败
+                return false;
+            }
+            // <3.2> 标记 interceptorIndex 位置
+            this.interceptorIndex = i;
+        }
+    }
+    // <4> 返回 true ，前置处理成功
+    return true;
+}
+```
+
+- `<1>` 处，调用 `#getInterceptors()` 方法，获得拦截器数组。即，[「3.3 getInterceptors」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-2-HandlerInterceptor/#) 处的逻辑。
+
+- `<2>` 处，遍历拦截器数组，逐个调用。
+
+- ```
+  <3>
+  ```
+
+   
+
+  处，调用
+
+   
+
+  ```
+  HandlerInterceptor#preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)
+  ```
+
+   
+
+  方法，执行拦截器的前置处理。如果成功，则返回
+
+   
+
+  ```
+  true
+  ```
+
+   
+
+  ，否则返回
+
+   
+
+  ```
+  false
+  ```
+
+   
+
+  。
+
+  - ```
+    <3.1>
+    ```
+
+     
+
+    处，执行失败，则调用
+
+     
+
+    ```
+    #triggerAfterCompletion(HttpServletRequest request, HttpServletResponse response, Exception ex)
+    ```
+
+     
+
+    方法，触发已完成处理。详细解析，见
+
+     
+
+    「3.5 triggerAfterCompletion」
+
+     
+
+    。注意，此处不是触发当前拦截器的已完成逻辑，而是触发
+
+     
+
+    ```
+    [0, interceptorIndex)
+    ```
+
+     
+
+    这几个拦截器已完成的逻辑(
+
+     
+
+    不包括
+
+    当前这个拦截器 )，并且是按照
+
+    倒序
+
+    执行的。
+
+    - 返回 `false` ，因为有拦截器执行失败。
+
+  - `<3.2>` 处，标记 `interceptorIndex` 位置。
+
+- `<4>` 处，返回 `true` ，如果全部拦截器执行成功。
+
+## 3.5 triggerAfterCompletion
+
+`#triggerAfterCompletion(HttpServletRequest request, HttpServletResponse response, Exception ex)` 方法，触发拦截器的已完成处理。代码如下：
+
+```
+// HandlerExecutionChain.java
+
+/**
+ * Trigger afterCompletion callbacks on the mapped HandlerInterceptors.
+ * Will just invoke afterCompletion for all interceptors whose preHandle invocation
+ * has successfully completed and returned true.
+ */
+void triggerAfterCompletion(HttpServletRequest request, HttpServletResponse response, @Nullable Exception ex)
+		throws Exception {
+	// 获得拦截器数组
+	HandlerInterceptor[] interceptors = getInterceptors();
+	if (!ObjectUtils.isEmpty(interceptors)) {
+		// 遍历拦截器数组
+		for (int i = this.interceptorIndex; i >= 0; i--) { // 倒序！！！
+			HandlerInterceptor interceptor = interceptors[i];
+			try {
+				// 已完成处理
+				interceptor.afterCompletion(request, response, this.handler, ex);
+			} catch (Throwable ex2) { // 注意，如果执行失败，仅仅会打印错误日志，不会结束循环
+				logger.error("HandlerInterceptor.afterCompletion threw exception", ex2);
+			}
+		}
+	}
+}
+```
+
+- 代码比较简单，正如上文所说。胖友自己瞅瞅，每一行的注释，都要仔细看。
+
+## 3.6 applyPostHandle
+
+`#applyPostHandle(HttpServletRequest request, HttpServletResponse response, ModelAndView mv)` 方法，应用拦截器的后置处理。代码如下：
+
+```
+// HandlerExecutionChain.java
+
+void applyPostHandle(HttpServletRequest request, HttpServletResponse response, @Nullable ModelAndView mv)
+		throws Exception {
+    // 获得拦截器数组
+    HandlerInterceptor[] interceptors = getInterceptors();
+	if (!ObjectUtils.isEmpty(interceptors)) {
+        // 遍历拦截器数组
+        for (int i = interceptors.length - 1; i >= 0; i--) { // 倒序
+			HandlerInterceptor interceptor = interceptors[i];
+			// 后置处理
+			interceptor.postHandle(request, response, this.handler, mv);
+		}
+	}
+}
+```
+
+- 代码比较简单。胖友自己瞅瞅，每一行的注释，都要仔细看。
+
+## 3.7 applyAfterConcurrentHandlingStarted
+
+TODO 1003
+
+# 4. HandlerInterceptor 实现类
+
+HandlerInterceptor 的实现类，如下图所示：
+
+[![类图](11-Spring MVC 源码分析-HandlerMapping 组件（二）之 HandlerInterceptor.assets/01.png)](http://static.iocoder.cn/images/Spring/2022-03-04/01.png)类图
+
+比较多，本文我们只看几个重要的实现类。
+
+## 4.1 MappedInterceptor
+
+`org.springframework.web.servlet.handler.MappedInterceptor` ，实现 HandlerInterceptor 接口，支持地址匹配的 HandlerInterceptor 实现类。
+
+示例如下：
+
+```
+<mvc:interceptors>
+    <mvc:interceptor>
+        <mvc:mapping path="/interceptor/**" />
+        <mvc:exclude-mapping path="/interceptor/b/*" />
+        <bean class="com.elim.learn.spring.mvc.interceptor.MyInterceptor" />
+    </mvc:interceptor>
+</mvc:interceptors>
+```
+
+- 每一个 `<mvc:interceptor />` 标签，将被解析成一个 MappedInterceptor Bean 对象。
+
+### 4.1.1 构造方法
+
+```
+// MappedInterceptor.java
+
+/**
+ * 匹配的路径
+ */
+@Nullable
+private final String[] includePatterns;
+/**
+ * 不匹配的路径
+ */
+@Nullable
+private final String[] excludePatterns;
+/**
+ * 路径匹配器
+ */
+@Nullable
+private PathMatcher pathMatcher;
+
+/**
+ * HandlerInterceptor 拦截器对象
+ */
+private final HandlerInterceptor interceptor;
+
+public MappedInterceptor(@Nullable String[] includePatterns, HandlerInterceptor interceptor) {
+	this(includePatterns, null, interceptor);
+}
+
+public MappedInterceptor(@Nullable String[] includePatterns, @Nullable String[] excludePatterns,
+		HandlerInterceptor interceptor) {
+	this.includePatterns = includePatterns;
+	this.excludePatterns = excludePatterns;
+	this.interceptor = interceptor;
+}
+
+public MappedInterceptor(@Nullable String[] includePatterns, WebRequestInterceptor interceptor) {
+	this(includePatterns, null, interceptor);
+}
+
+public MappedInterceptor(@Nullable String[] includePatterns, @Nullable String[] excludePatterns,
+		WebRequestInterceptor interceptor) {
+
+	this(includePatterns, excludePatterns, new WebRequestHandlerInterceptorAdapter(interceptor));
+}
+```
+
+- 属性比较简单，胖友自己瞅瞅。
+- `includePatterns` + `excludePatterns` + `pathMatcher` 属性，匹配路径。
+- `interceptor` 拦截器。
+
+### 4.1.2 matches
+
+`#matches(String lookupPath, PathMatcher pathMatcher)` 方法，判断路径是否匹配。代码如下：
+
+```
+// MappedInterceptor.java
+
+/**
+ * Determine a match for the given lookup path.
+ * @param lookupPath the current request path
+ * @param pathMatcher a path matcher for path pattern matching
+ * @return {@code true} if the interceptor applies to the given request path
+ */
+public boolean matches(String lookupPath, PathMatcher pathMatcher) {
+	PathMatcher pathMatcherToUse = (this.pathMatcher != null ? this.pathMatcher : pathMatcher);
+	// 先排重
+	if (!ObjectUtils.isEmpty(this.excludePatterns)) {
+		for (String pattern : this.excludePatterns) {
+			if (pathMatcherToUse.match(pattern, lookupPath)) { // 匹配
+				return false;
+			}
+		}
+	}
+	// 特殊，如果包含为空，则默认就是包含
+	if (ObjectUtils.isEmpty(this.includePatterns)) {
+		return true;
+	}
+	// 后包含
+	for (String pattern : this.includePatterns) {
+		if (pathMatcherToUse.match(pattern, lookupPath)) { // 匹配
+			return true;
+		}
+	}
+	return false;
+}
+```
+
+简单，胖友自己瞅瞅
+
+### 4.1.3 拦截方法实现
+
+```
+// MappedInterceptor.java
+
+@Override
+public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)
+		throws Exception {
+	return this.interceptor.preHandle(request, response, handler);
+}
+
+@Override
+public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler,
+		@Nullable ModelAndView modelAndView) throws Exception {
+	this.interceptor.postHandle(request, response, handler, modelAndView);
+}
+
+@Override
+public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler,
+		@Nullable Exception ex) throws Exception {
+	this.interceptor.afterCompletion(request, response, handler, ex);
+}
+```
+
+直接调用拦截器对应的方法。
+
+## 4.2 其他
+
+TODO WebRequestInterceptor
+TODO ASYC
+TODO
+
+# 5. 拦截器配置
+
+在 Spring MVC 中，有多种方式，配置拦截器。那么对拦截器的配置是怎么解析和初始化的呢？下面，我们逐小节来解析。当然，本文暂时不会特别详细解析，而是交给胖友自己去研读。😝
+
+## 5.1 `<mvc:interceptors />` 标签
+
+实际上，我们已经看过 `<mvc:interceptors />` 的配置示例。那么，再来看一次，哈哈哈哈。
+
+```
+<mvc:interceptors>
+    <mvc:interceptor>
+        <mvc:mapping path="/interceptor/**" />
+        <mvc:exclude-mapping path="/interceptor/b/*" />
+        <bean class="com.elim.learn.spring.mvc.interceptor.MyInterceptor" />
+    </mvc:interceptor>
+</mvc:interceptors>
+```
+
+- 每一个 `<mvc:interceptor />` 标签，会被 `org.springframework.web.servlet.config.InterceptorsBeanDefinitionParser` 解析成 [「4.1 MappedInterceptor」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-2-HandlerInterceptor/#) 对象，注册到 Spring IOC 容器中。
+
+- 在 AbstractHandlerMapping 的 `#detectMappedInterceptors(List<HandlerInterceptor> mappedInterceptors)` 方法中，会扫描 MappedInterceptor Bean 。代码如下：
+
+  ```
+  // AbstractHandlerMapping.java
+  
+  protected void detectMappedInterceptors(List<HandlerInterceptor> mappedInterceptors) {
+  	// 扫描已注册的 MappedInterceptor 的 Bean 们，添加到 mappedInterceptors 中
+  	// MappedInterceptor 会根据请求路径做匹配，是否进行拦截。
+  	mappedInterceptors.addAll(
+  			BeanFactoryUtils.beansOfTypeIncludingAncestors(
+  					obtainApplicationContext(), MappedInterceptor.class, true, false).values());
+  }
+  ```
+
+所以，这种方式，胖友只要看看 **InterceptorsBeanDefinitionParser** 类即可。
+
+当然，基于这样的思路，我们直接配置 MappedInterceptor 的 Bean 对象也是可以的，无论是通过 XML ，还是通过 `@Bean` 注解。
+
+## 5.2 Java Config
+
+在使用 Spring Boot 时，这是主流的方式。示例如下：
+
+```
+// SecurityInterceptor.java
+
+@Component
+public class SecurityInterceptor extends HandlerInterceptorAdapter {
+
+    // ... 省略无关代码
+
+}
+
+// MVCConfiguration.java
+
+@EnableWebMvc
+@Configuration
+public class MVCConfiguration extends WebMvcConfigurerAdapter {
+
+    @Autowired
+    private SecurityInterceptor securityInterceptor;
+
+    @Override
+    public void addInterceptors(InterceptorRegistry registry) {
+        registry.addInterceptor(securityInterceptor);
+    }
+
+}
+```
+
+- SecurityInterceptor 是拦截器，通过 `@Component` 注册到 Spring IOC 容器中。因为它是 HandlerInterceptorAdapter 的子类，而不是 MappedInterceptor 的子类，所以不会被 AbstractHandlerMapping 的 `#detectMappedInterceptors(List<HandlerInterceptor> mappedInterceptors)` 方法扫描到。
+- 在 MVCConfiguration 的 `#addInterceptors(InterceptorRegistry registry)` 方法中，我们将 `securityInterceptor` 拦截器添加到 InterceptorRegistry 这个拦截器注册表中。
+
+所以，这种方式，胖友可能要看的类是不少的，艿艿暂时没有细看。
+
+- **InterceptorRegistry**
+- **WebMvcConfigurerAdapter**
+
+通过 WebMvcConfigurationSupport 的 `#getInterceptors()` 方法，获得拦截器们。代码如下：
+
+```
+// WebMvcConfigurationSupport.java
+
+@Nullable
+private List<Object> interceptors;
+
+protected final Object[] getInterceptors() {
+    // 若 interceptors 未初始化，则进行初始化
+	if (this.interceptors == null) {
+		// 创建 InterceptorRegistry 对象
+		InterceptorRegistry registry = new InterceptorRegistry();
+		// 添加拦截器到 interceptors 中
+		addInterceptors(registry); // <x>
+		// 添加内置拦截器到 interceptors 中
+		registry.addInterceptor(new ConversionServiceExposingInterceptor(mvcConversionService()));
+		registry.addInterceptor(new ResourceUrlProviderExposingInterceptor(mvcResourceUrlProvider()));
+		// 初始化到 interceptors 属性
+		this.interceptors = registry.getInterceptors();
+	}
+	// 若 interceptors 已初始化，则直接返回
+	return this.interceptors.toArray();
+}
+```
+
+- 代码虽然比较长，重点在 `<x>` 处，调用 `#addInterceptors(InterceptorRegistry registry)` 方法，添加拦截器到 `interceptors` 中。代码如下：
+
+  ```
+  // WebMvcConfigurationSupport.java
+  
+  protected void addInterceptors(InterceptorRegistry registry) {
+  }
+  ```
+
+  - 这是一个空方法，可由子类来进行实现。
+
+- 我们一起来看 DelegatingWebMvcConfiguration 对 `#addInterceptors(InterceptorRegistry registry)` 方法，从 WebMvcConfigurer 对象中，获得拦截器，并添加到 `registry` 中。代码如下：
+
+  ```
+  // DelegatingWebMvcConfiguration.java
+  
+  private final WebMvcConfigurerComposite configurers = new WebMvcConfigurerComposite();
+  
+  @Override
+  protected void addInterceptors(InterceptorRegistry registry) {
+      this.configurers.addInterceptors(registry);
+  }
+  
+  // WebMvcConfigurerComposite.class
+  
+  @Override
+  public void addInterceptors(InterceptorRegistry registry) {
+      for (WebMvcConfigurer delegate : this.delegates) {
+          delegate.addInterceptors(registry);
+      }
+  }
+  ```
+
+  - 其中，我们在示例给的 MVCConfiguration ，其实就是一个 WebMvcConfigurer 对象。这样，我们自己实现的 MVCConfiguration 的 `#addInterceptors(InterceptorRegistry registry)` 方法，就会被调用列。
+
+而通过这样的方式的方式配置拦截器，最终通过 AbstractMappingHandler 的 `#setInterceptors(Object... interceptors)` 方法，设置到 MappingHandler 中。代码如下：
+
+```
+// AbstractHandlerMapping.java
+
+public void setInterceptors(Object... interceptors) {
+	this.interceptors.addAll(Arrays.asList(interceptors));
+}
+```
+
+- 当然，具体哪些地方调用 AbstractMappingHandler 的 `#setInterceptors(Object... interceptors)` 方法，请使用 IDEA 的**搜索**下，哪些地方调用了 WebMvcConfigurationSupport 的 `#getInterceptors()` 方法。
+
+> 艿艿：关于这个过程，可以搭建一个 Spring Boot 项目，然后配置一个自定义拦截器，进行调试。
+
+# 666. 彩蛋
+
+正如文头所说，如果没实现过 Spring MVC 自定义拦截器的胖友，赶紧先来一发。😈
+
+参考和推荐如下文章：
+
+- 丶Format [《Spring MVC 拦截器详解[附带源码分析\]》](https://www.cnblogs.com/fangjian0423/p/springMVC-interceptor.html)
+- 郝佳 [《Spring 源码深度解析》](https://item.jd.com/11311737.html) 的 [「11.3 DispatcherServlet」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-2-HandlerInterceptor/#) 小节
+- 韩路彪 [《看透 Spring MVC：源代码分析与实践》](https://item.jd.com/11807414.html) 的 [「第12章 HandlerMapping」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-2-HandlerInterceptor/#) 小节
\ No newline at end of file
diff --git a/springmvc/12-Spring MVC 源码解析-HandlerMapping 组件（三）之 AbstractHandlerMethodMapping.assets/01.png b/springmvc/12-Spring MVC 源码解析-HandlerMapping 组件（三）之 AbstractHandlerMethodMapping.assets/01.png
new file mode 100644
index 0000000..e54f861
Binary files /dev/null and b/springmvc/12-Spring MVC 源码解析-HandlerMapping 组件（三）之 AbstractHandlerMethodMapping.assets/01.png differ
diff --git a/springmvc/12-Spring MVC 源码解析-HandlerMapping 组件（三）之 AbstractHandlerMethodMapping.md b/springmvc/12-Spring MVC 源码解析-HandlerMapping 组件（三）之 AbstractHandlerMethodMapping.md
new file mode 100644
index 0000000..360ce27
--- /dev/null
+++ b/springmvc/12-Spring MVC 源码解析-HandlerMapping 组件（三）之 AbstractHandlerMethodMapping.md	
@@ -0,0 +1,1780 @@
+# 精尽 Spring MVC 源码解析 —— HandlerMapping 组件（三）之 AbstractHandlerMethodMapping
+
+# 1. 概述
+
+本文接 [《精尽 Spring MVC 源码分析 —— HandlerMapping 组件（一）之 AbstractHandlerMapping》](http://svip.iocoder.cn/Spring-MVC/HandlerMapping-1-AbstractHandlerMapping) 一文，分享 AbstractHandlerMapping 的右半边 **AbstractHandlerMethodMapping** 系，即下图右半边**黄色**部分：
+
+[![类图](12-Spring MVC 源码解析-HandlerMapping 组件（三）之 AbstractHandlerMethodMapping.assets/01.png)](http://static.iocoder.cn/images/Spring/2022-03-01/01.png)类图
+
+- 一共有三个子类，继承关系很简单，AbstractHandlerMethodMapping <= RequestMappingInfoHandlerMapping <= RequestMappingHandlerMapping 。所以，我们在下面的每一小节，分享一个类。
+
+# 2. 注解
+
+Spring MVC 的请求匹配的注解，我们已经是熟悉的不能再熟悉，如下:
+
+- [`org.springframework.web.bind.annotation.@RequestMapping`](https://github.com/spring-projects/spring-framework/blob/master/spring-web/src/main/java/org/springframework/web/bind/annotation/RequestMapping.java)
+- [`org.springframework.web.bind.annotation.@GetMapping`](https://github.com/spring-projects/spring-framework/blob/master/spring-web/src/main/java/org/springframework/web/bind/annotation/GetMapping.java)
+- [`org.springframework.web.bind.annotation.@PostMapping`](https://github.com/spring-projects/spring-framework/blob/master/spring-web/src/main/java/org/springframework/web/bind/annotation/PostMapping.java)
+- [`org.springframework.web.bind.annotation.@PutMapping`](https://github.com/spring-projects/spring-framework/blob/master/spring-web/src/main/java/org/springframework/web/bind/annotation/PutMapping.java)
+- [`org.springframework.web.bind.annotation.@DeleteMapping`](https://github.com/spring-projects/spring-framework/blob/master/spring-web/src/main/java/org/springframework/web/bind/annotation/DeleteMapping.java)
+- [`org.springframework.web.bind.annotation.@PatchMapping`](https://github.com/spring-projects/spring-framework/blob/master/spring-web/src/main/java/org/springframework/web/bind/annotation/PatchMapping.java)
+
+具体每个注解有哪些属性，胖友点击链接瞅瞅即可。毕竟，太熟悉了。哈哈哈哈。
+
+# 3. AbstractHandlerMethodMapping
+
+`org.springframework.web.servlet.result.method.AbstractHandlerMethodMapping` ，实现 InitializingBean 接口，继承 AbstractHandlerMapping 抽象类，以 **Method** 作为 **Handler** 的 HandlerMapping 抽象类，提供 Mapping 的初始化、注册等通用的骨架方法。这就是我们常说的[“模板方法模式”](http://www.iocoder.cn/DesignPattern/xiaomingge/Template-Method/) 。
+
+那么具体是什么呢？AbstractHandlerMethodMapping 定义为了 `<T>` 泛型，交给子类做决定。例如，子类 RequestMappingInfoHandlerMapping 使用 RequestMappingInfo 类作为 `<T>` 泛型，也就是我们在 [「2. 注解」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-3-AbstractHandlerMethodMapping/#) 看到的 `@RequestMapping` 等注解。
+
+## 3.1 构造方法
+
+```
+// AbstractHandlerMethodMapping.java
+
+public abstract class AbstractHandlerMethodMapping<T> extends AbstractHandlerMapping implements InitializingBean {
+
+    /**
+     * Mapping 注册表
+     */
+    private final MappingRegistry mappingRegistry = new MappingRegistry();
+
+    /**
+     * Mapping 命名策略
+     */
+    @Nullable
+    private HandlerMethodMappingNamingStrategy<T> namingStrategy;
+}
+```
+
+- `<T>` 泛型，就是我们上面提到的，Mapping 的类型。
+
+- `mappingRegistry` 属性，Mapping 注册表。详细解析，见 [「3.2 MappingRegistry」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-3-AbstractHandlerMethodMapping/#) 。
+
+- `namingStrategy` 属性，`org.springframework.web.servlet.handler.HandlerMethodMappingNamingStrategy` 接口，😈 名字好长，Handler **的** Method **的** Mapping **的**名字生成策略接口。代码如下：
+
+  ```
+  // HandlerMethodMappingNamingStrategy.java
+  
+  @FunctionalInterface
+  public interface HandlerMethodMappingNamingStrategy<T> {
+  
+  /**
+   * 获得名字
+   *
+   * Determine the name for the given HandlerMethod and mapping.
+   * @param handlerMethod the handler method
+   * @param mapping the mapping
+   * @return the name
+   */
+  	String getName(HandlerMethod handlerMethod, T mapping);
+  
+  }
+  ```
+
+  - 可能不太好理解，获得 Mapping 的名字。这样，我们就可以根据 Mapping 的名字，获得 Handler 。
+
+  - `org.springframework.web.servlet.mvc.method.RequestMappingInfoHandlerMethodMappingNamingStrategy` 实现该接口，代码如下：
+
+    ```
+    // RequestMappingInfoHandlerMethodMappingNamingStrategy.java
+    
+    public class RequestMappingInfoHandlerMethodMappingNamingStrategy
+            implements HandlerMethodMappingNamingStrategy<RequestMappingInfo> {
+    
+        /** Separator between the type and method-level parts of a HandlerMethod mapping name. */
+        public static final String SEPARATOR = "#";
+    
+        @Override
+        public String getName(HandlerMethod handlerMethod, RequestMappingInfo mapping) {
+            // 情况一，mapping 名字非空，则使用 mapping 的名字
+            if (mapping.getName() != null) {
+                return mapping.getName();
+            }
+            // 情况二，使用类名大写 + "#" + 方法名
+            StringBuilder sb = new StringBuilder();
+            String simpleTypeName = handlerMethod.getBeanType().getSimpleName();
+            for (int i = 0 ; i < simpleTypeName.length(); i++) {
+                if (Character.isUpperCase(simpleTypeName.charAt(i))) {
+                    sb.append(simpleTypeName.charAt(i));
+                }
+            }
+            sb.append(SEPARATOR).append(handlerMethod.getMethod().getName());
+            return sb.toString();
+        }
+    
+    }
+    ```
+
+    - 比较好理解，分成两种情况。
+    - 情况一，如果 Mapping 已经配置名字，则直接返回。例如，`@RequestMapping(name = "login", value = "user/login")` 注解的方法，它对应的 Mapping 的名字就是 `"login"` 。
+    - 情况二，如果 Mapping 未配置名字，则使用使用类名大写 + `"#"` + 方法名。例如，`@RequestMapping(value = "user/login")` 注解的方法，假设它所在的类为 UserController ，对应的方法名为 login ，则它对应的 Mapping 的名字就是 `USERCONTROLLER#login` 。
+
+## 3.2 MappingRegistry
+
+MappingRegistry ，是 AbstractHandlerMethodMapping 的私有类，Mapping 注册表。
+
+### 3.2.1 构造方法
+
+```
+// AbstractHandlerMethodMapping.java#MappingRegistry
+
+/**
+ * 注册表
+ *
+ * KEY: Mapping
+ */
+private final Map<T, MappingRegistration<T>> registry = new HashMap<>();
+
+/**
+ * 注册表2
+ *
+ * KEY：Mapping
+ */
+private final Map<T, HandlerMethod> mappingLookup = new LinkedHashMap<>();
+
+/**
+ * 直接 URL 的映射
+ *
+ * KEY：直接 URL
+ * VALUE：Mapping 数组
+ */
+private final MultiValueMap<String, T> urlLookup = new LinkedMultiValueMap<>();
+
+/**
+ * Mapping 的名字与 HandlerMethod 的映射
+ *
+ * KEY：Mapping 的名字
+ * VALUE：HandlerMethod 数组
+ */
+private final Map<String, List<HandlerMethod>> nameLookup = new ConcurrentHashMap<>();
+
+/**
+ * TODO 1012 cors
+ */
+private final Map<HandlerMethod, CorsConfiguration> corsLookup = new ConcurrentHashMap<>();
+
+/**
+ * 读写锁
+ */
+private final ReentrantReadWriteLock readWriteLock = new ReentrantReadWriteLock();
+```
+
+- `registry` 属性，注册表 1 。其中，KEY 为 Mapping ，即 `<T>` 泛型。
+
+- `mappingLookup` 属性，注册表 2 。其中，KEY 为 Mapping ，即 `<T>` 泛型。
+
+- `urlLookup` 属性，直接 URL 的映射。其中，KEY 为直接 URL ，VALUE 为 Mapping 数组。比较不好理解，我们放在 [「3.2.2 register」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-3-AbstractHandlerMethodMapping/#) 一起看。
+
+- `nameLookup` 属性，Mapping 的名字与 HandlerMethod 的映射。其中，KEY 为 Mapping 的名字( 就是 [「3.1 构造方法」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-3-AbstractHandlerMethodMapping/#) 中，我们看到的 HandlerMethodMappingNamingStrategy 生成的 Mapping 的名字 )，VALUE 为 HandlerMethod 数组。
+
+- `readWriteLock` 属性，读写锁。下文，会看到它的使用。涉及它的有两个方法：
+
+  ```
+  // AbstractHandlerMethodMapping.java#MappingRegistry
+  
+  /**
+   * 获得读锁
+   *
+   * Acquire the read lock when using getMappings and getMappingsByUrl.
+   */
+  public void acquireReadLock() {
+  	this.readWriteLock.readLock().lock();
+  }
+  
+  /**
+   * 获得写锁
+   *
+   * Release the read lock after using getMappings and getMappingsByUrl.
+   */
+  public void releaseReadLock() {
+  	this.readWriteLock.readLock().unlock();
+  }
+  ```
+
+### 3.2.2 register
+
+`#register(T mapping, Object handler, Method method)` 方法，注册。代码如下：
+
+```
+// AbstractHandlerMethodMapping.java#MappingRegistry
+
+public void register(T mapping, Object handler, Method method) {
+    // <1> 获得写锁
+    this.readWriteLock.writeLock().lock();
+    try {
+        // <2.1> 创建 HandlerMethod 对象
+        HandlerMethod handlerMethod = createHandlerMethod(handler, method);
+        // <2.2> 校验当前 mapping 不存在，否则抛出 IllegalStateException 异常
+        assertUniqueMethodMapping(handlerMethod, mapping);
+        // <2.3> 添加 mapping + HandlerMethod 到 mappingLookup 中
+        this.mappingLookup.put(mapping, handlerMethod);
+
+        // <3.1> 获得 mapping 对应的普通 URL 数组
+        List<String> directUrls = getDirectUrls(mapping);
+        // <3.2> 添加到 url + mapping 到 urlLookup 集合中
+        for (String url : directUrls) {
+            this.urlLookup.add(url, mapping);
+        }
+
+        // <4> 初始化 nameLookup
+        String name = null;
+        if (getNamingStrategy() != null) {
+            // <4.1> 获得 Mapping 的名字
+            name = getNamingStrategy().getName(handlerMethod, mapping);
+            // <4.2> 添加到 mapping 的名字 + HandlerMethod 到 nameLookup 中
+            addMappingName(name, handlerMethod);
+        }
+
+        // <5> TODO 1012 cors
+        CorsConfiguration corsConfig = initCorsConfiguration(handler, method, mapping);
+        if (corsConfig != null) {
+            this.corsLookup.put(handlerMethod, corsConfig);
+        }
+
+        // <6> 创建 MappingRegistration 对象，并 mapping + MappingRegistration 添加到 registry 中
+        this.registry.put(mapping, new MappingRegistration<>(mapping, handlerMethod));
+    } finally {
+        // <7> 释放写锁
+        this.readWriteLock.writeLock().unlock();
+    }
+}
+```
+
+- `<1>` 处，获得写锁。
+
+- `<2.1>` 处，调用 `#createHandlerMethod(Object handler, Method method)` 方法，创建 HandlerMethod 对象。详细解析，见 [「3.3 createHandlerMethod」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-3-AbstractHandlerMethodMapping/#) 。
+
+- `<2.2>` 处，调用 `#assertUniqueMethodMapping(HandlerMethod newHandlerMethod, T mapping)` 方法，校验当前 `mapping` 不存在，否则抛出 IllegalStateException 异常。代码如下：
+
+  ```
+  // AbstractHandlerMethodMapping.java#MappingRegistry
+  
+  private void assertUniqueMethodMapping(HandlerMethod newHandlerMethod, T mapping) {
+  	HandlerMethod handlerMethod = this.mappingLookup.get(mapping);
+  	if (handlerMethod != null && !handlerMethod.equals(newHandlerMethod)) { // 存在，且不相等，说明不唯一
+  		throw new IllegalStateException(
+  				"Ambiguous mapping. Cannot map '" + newHandlerMethod.getBean() + "' method \n" +
+  						newHandlerMethod + "\nto " + mapping + ": There is already '" +
+  						handlerMethod.getBean() + "' bean method\n" + handlerMethod + " mapped.");
+  	}
+  }
+  ```
+
+- `<2.3>` 处，添加 `mapping` + HandlerMethod 到 `mappingLookup` 中。
+
+- `<3.1>` 处，调用 `#getDirectUrls(T mapping)` 方法，获得 mapping 对应的直接 URL 数组。代码如下：
+
+  ```
+  // AbstractHandlerMethodMapping.java#MappingRegistry
+  
+  private List<String> getDirectUrls(T mapping) {
+  	List<String> urls = new ArrayList<>(1);
+  	// 遍历 Mapping 对应的路径
+  	for (String path : getMappingPathPatterns(mapping)) {
+  		// 非**模式**路径
+  		if (!getPathMatcher().isPattern(path)) {
+  			urls.add(path);
+  		}
+  	}
+  	return urls;
+  }
+  ```
+
+  - 例如，`@RequestMapping("/user/login")` 注解对应的路径，**就是**直接路径。
+  - 例如，`@RequestMapping("/user/${id}")` 注解对应的路径，**不是**直接路径。
+
+- `<3.2>` 处，添加到 直接 url + `mapping` 到 `urlLookup` 集合中。
+
+- `<4.1>` 处，调用 `HandlerMethodMappingNamingStrategy#getName(HandlerMethod handlerMethod, T mapping)` 方法，获得 Mapping 的名字。
+
+- `<4.2>` 处，调用 `#addMappingName(String name, HandlerMethod handlerMethod)` 方法，添加 `mapping` 的名字 + HandlerMethod 到 `nameLookup` 中。代码如下：
+
+  ```
+  // AbstractHandlerMethodMapping.java#MappingRegistry
+  
+  private void addMappingName(String name, HandlerMethod handlerMethod) {
+      // 获得 Mapping 的名字，对应的 HandlerMethod 数组
+      List<HandlerMethod> oldList = this.nameLookup.get(name);
+  	if (oldList == null) {
+  		oldList = Collections.emptyList();
+  	}
+  
+  	// 如果已经存在，则不用添加
+  	for (HandlerMethod current : oldList) {
+  		if (handlerMethod.equals(current)) {
+  			return;
+  		}
+  	}
+  
+  	// 添加到 nameLookup 中
+  	List<HandlerMethod> newList = new ArrayList<>(oldList.size() + 1); // 重新创建的原因是，保证数组的大小固定。因为，基本不太存在扩容的可能性，申请大了就浪费了。
+  	newList.addAll(oldList);
+  	newList.add(handlerMethod);
+  	this.nameLookup.put(name, newList);
+  }
+  ```
+
+  - 比较简单，胖友自己瞅瞅就懂了。
+
+- `<5>` 处，TODO 1012 cors
+
+- `<6>` 处，创建 MappingRegistration 对象，并 `mapping` + MappingRegistration 添加到 `registry` 中。关于 MappingRegistration 类，详细解析，见 [「3.4 MappingRegistration」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-3-AbstractHandlerMethodMapping/#) 。
+
+- `<7>` 处，释放写锁。
+
+### 3.2.3 unregister
+
+`#unregister(T mapping)` 方法，取消注册。代码如下：
+
+```
+// AbstractHandlerMethodMapping.java#MappingRegistry
+
+public void unregister(T mapping) {
+    // 获得写锁
+    this.readWriteLock.writeLock().lock();
+    try {
+        // 从 registry 中移除
+        MappingRegistration<T> definition = this.registry.remove(mapping);
+        if (definition == null) {
+            return;
+        }
+
+        // 从 mappingLookup 中移除
+        this.mappingLookup.remove(definition.getMapping());
+
+        // 从 urlLookup 移除
+        for (String url : definition.getDirectUrls()) {
+            List<T> list = this.urlLookup.get(url);
+            if (list != null) {
+                list.remove(definition.getMapping());
+                if (list.isEmpty()) {
+                    this.urlLookup.remove(url);
+                }
+            }
+        }
+
+        // 从 nameLookup 移除
+        removeMappingName(definition);
+
+        // 从 corsLookup 中移除
+        this.corsLookup.remove(definition.getHandlerMethod());
+    } finally {
+        // 释放写锁
+        this.readWriteLock.writeLock().unlock();
+    }
+}
+```
+
+- 比较简单，胖友自己瞅瞅。另外，`#removeMappingName(MappingRegistration<T> definition)` 方法，胖友也自己瞅瞅。
+
+## 3.3 createHandlerMethod
+
+`#createHandlerMethod(Object handler, Method method)` 方法，创建 HandlerMethod 对象。代码如下：
+
+```
+// AbstractHandlerMethodMapping.java
+
+protected HandlerMethod createHandlerMethod(Object handler, Method method) {
+    HandlerMethod handlerMethod;
+    // <1> 如果 handler 类型为 String， 说明对应一个 Bean 对象，例如 UserController 使用 @Controller 注解后，默认 handler 为它的 beanName ，即 `userController`
+    if (handler instanceof String) {
+        String beanName = (String) handler;
+        handlerMethod = new HandlerMethod(beanName,
+                obtainApplicationContext().getAutowireCapableBeanFactory(), method);
+    // <2> 如果 handler 类型非 String ，说明是一个已经是一个 handler 对象，就无需处理，直接创建 HandlerMethod 对象
+    } else {
+        handlerMethod = new HandlerMethod(handler, method);
+    }
+    return handlerMethod;
+}
+```
+
+- `<1>` 处，如果 `handler` 类型**为** String， 说明对应一个 Bean 对象，例如 UserController 使用 `@Controller` 注解后， `handler` 为它的默认的 `beanName = userController` 。
+- `<2>` 处，如果 `handler` 类型**非** String ，说明是一个已经是一个 `handler` 对象，就无需处理，直接创建 HandlerMethod 对象。
+- 到了此处，我们已经可以觉察，实际上，HandlerMethod 是 `handler` + `method` 的组合，一个对象的某个方法。
+
+### 3.3.1 HandlerMethod
+
+`org.springframework.web.method.HandlerMethod` ，处理器的方法的封装对象。属性如下：
+
+```
+// HandlerMethod.java
+
+/**
+ * Bean 对象
+ */
+private final Object bean;
+
+@Nullable
+private final BeanFactory beanFactory;
+
+/**
+ * Bean 的类型
+ */
+private final Class<?> beanType;
+
+/**
+ * 方法
+ */
+private final Method method;
+
+/**
+ * {@link #method} 的桥接方法
+ *
+ * 详细说明
+ *
+ * 1. https://www.jianshu.com/p/250030ea9b28
+ * 2. https://blog.csdn.net/mhmyqn/article/details/47342577
+ */
+private final Method bridgedMethod;
+
+/**
+ * 方法参数数组
+ */
+private final MethodParameter[] parameters;
+
+/**
+ * 响应的状态码，即 {@link ResponseStatus#code()}
+ */
+@Nullable
+private HttpStatus responseStatus;
+/**
+ * 响应的状态码原因，即 {@link ResponseStatus#reason()}
+ */
+@Nullable
+private String responseStatusReason;
+
+/**
+ * 解析自哪个 HandlerMethod 对象
+ *
+ * 仅构造方法中传入 HandlerMethod 类型的参数适用，例如 {@link #HandlerMethod(HandlerMethod)}
+ */
+@Nullable
+private HandlerMethod resolvedFromHandlerMethod;
+
+/**
+ * 父接口的方法的参数注解数组
+ */
+@Nullable
+private volatile List<Annotation[][]> interfaceParameterAnnotations;
+```
+
+- 属性，虽然比较多，但是比较好理解。我们顺着构造方法，一起来看看。
+
+**HandlerMethod(String beanName, BeanFactory beanFactory, Method method) 构造方法**
+
+对应 `#createHandlerMethod(Object handler, Method method)` 方法的 `<1>` 的情况，代码如下：
+
+```
+// HandlerMethod.java
+
+/**
+ * Create an instance from a bean name, a method, and a {@code BeanFactory}.
+ * The method {@link #createWithResolvedBean()} may be used later to
+ * re-create the {@code HandlerMethod} with an initialized bean.
+ */
+public HandlerMethod(String beanName, BeanFactory beanFactory, Method method) {
+	Assert.hasText(beanName, "Bean name is required");
+	Assert.notNull(beanFactory, "BeanFactory is required");
+	Assert.notNull(method, "Method is required");
+	// <1> 将 beanName 赋值给 bean 属性，说明 beanFactory + bean 的方式，获得 handler 对象
+	this.bean = beanName;
+	this.beanFactory = beanFactory;
+	// <2> 初始化 beanType 属性
+	Class<?> beanType = beanFactory.getType(beanName);
+	if (beanType == null) {
+		throw new IllegalStateException("Cannot resolve bean type for bean with name '" + beanName + "'");
+	}
+	this.beanType = ClassUtils.getUserClass(beanType);
+	// <3> 初始化 method、bridgedMethod 属性
+	this.method = method;
+	this.bridgedMethod = BridgeMethodResolver.findBridgedMethod(method);
+	// <4> 初始化 parameters 属性
+	this.parameters = initMethodParameters();
+	// <5> 初始化 responseStatus、responseStatusReason 属性
+	evaluateResponseStatus();
+}
+```
+
+- `<1>` 处， 将 `beanName` 赋值给 `bean` 属性，说明 `beanFactory` + `bean` 的方式，获得 `handler` 对象。
+
+- `<2>` 处，初始化 `beanType` 属性。
+
+- `<3>` 处，初始化 `method`、`bridgedMethod` 属性。
+
+- `<5>` 处，调用 `#evaluateResponseStatus()` 方法，初始化 `responseStatus`、`responseStatusReason` 属性。代码如下：
+
+  ```
+  // HandlerMethod.java
+  
+  private void evaluateResponseStatus() {
+  	ResponseStatus annotation = getMethodAnnotation(ResponseStatus.class);
+  	if (annotation == null) {
+  		annotation = AnnotatedElementUtils.findMergedAnnotation(getBeanType(), ResponseStatus.class);
+  	}
+  	if (annotation != null) {
+  		this.responseStatus = annotation.code();
+  		this.responseStatusReason = annotation.reason();
+  	}
+  }
+  ```
+
+- `<4>` 处，调用 `#initMethodParameters()` 方法，初始化 `parameters` 属性。代码如下：
+
+  ```
+  // HandlerMethod.java
+  
+  private MethodParameter[] initMethodParameters() {
+  	int count = this.bridgedMethod.getParameterCount();
+  	// 创建 MethodParameter 数组
+  	MethodParameter[] result = new MethodParameter[count];
+  	// 遍历 bridgedMethod 的参数，逐个解析参数类型
+  	for (int i = 0; i < count; i++) {
+  		HandlerMethodParameter parameter = new HandlerMethodParameter(i);
+  		GenericTypeResolver.resolveParameterType(parameter, this.beanType);
+  		result[i] = parameter;
+  	}
+  	return result;
+  }
+  ```
+
+  - 关于 MethodParameter 和 GenericTypeResolver 类，本文就不详细解析，胖友自己去瞅瞅。
+  - 关于 HandlerMethodParameter ，TODO 1014 HandlerMethodParameter
+
+------
+
+**HandlerMethod(Object bean, Method method) 构造方法**
+
+对应 `#createHandlerMethod(Object handler, Method method)` 方法的 `<2>` 的情况，代码如下：
+
+```
+// HandlerMethod.java
+
+/**
+ * Create an instance from a bean instance and a method.
+ */
+public HandlerMethod(Object bean, Method method) {
+	Assert.notNull(bean, "Bean is required");
+	Assert.notNull(method, "Method is required");
+	// 初始化 bean
+	this.bean = bean;
+	this.beanFactory = null; // 置空 beanFactory ，因为不用
+	// 初始化 beanType 属性
+	this.beanType = ClassUtils.getUserClass(bean);
+	// 初始化 method 和 bridgedMethod 属性
+	this.method = method;
+	this.bridgedMethod = BridgeMethodResolver.findBridgedMethod(method);
+	// 初始化 parameters 属性
+	this.parameters = initMethodParameters();
+	// 初始化 responseStatus、responseStatusReason 属性
+	evaluateResponseStatus();
+}
+```
+
+- 灰常简单。
+
+## 3.4 MappingRegistration
+
+MappingRegistration ，是 AbstractHandlerMethodMapping 的私有静态类，Mapping 注册登记。代码如下：
+
+```
+// AbstractHandlerMethodMapping.java
+
+private static class MappingRegistration<T> {
+
+    /**
+     * Mapping 对象
+     */
+    private final T mapping;
+
+    /**
+     * HandlerMethod 对象
+     */
+    private final HandlerMethod handlerMethod;
+
+    /**
+     * 直接 URL 数组
+     */
+    private final List<String> directUrls;
+
+    /**
+     * {@link #mapping} 的名字
+     */
+    @Nullable
+    private final String mappingName;
+
+    public MappingRegistration(T mapping, HandlerMethod handlerMethod,
+            @Nullable List<String> directUrls, @Nullable String mappingName) {
+
+        Assert.notNull(mapping, "Mapping must not be null");
+        Assert.notNull(handlerMethod, "HandlerMethod must not be null");
+        this.mapping = mapping;
+        this.handlerMethod = handlerMethod;
+        this.directUrls = (directUrls != null ? directUrls : Collections.emptyList());
+        this.mappingName = mappingName;
+    }
+
+    // ... 省略 getting 方法
+}
+```
+
+## 3.5 afterPropertiesSet
+
+> 艿艿：打起精神，虽然前面已经看了很多代码。此处，我们才真正进行**初始化**。
+
+**实现** `#afterPropertiesSet()` 方法，进行初始化。代码如下：
+
+```
+// AbstractHandlerMethodMapping.java
+
+/**
+ * 是否只扫描可访问的 HandlerMethod 们
+ */
+private boolean detectHandlerMethodsInAncestorContexts = false;
+
+@Override
+public void afterPropertiesSet() {
+	// <x> 初始化处理器的方法们
+	initHandlerMethods();
+}
+
+/**
+ * Scan beans in the ApplicationContext, detect and register handler methods.
+ * @see #getCandidateBeanNames()
+ * @see #processCandidateBean
+ * @see #handlerMethodsInitialized
+ */
+protected void initHandlerMethods() {
+	// <1.1> 遍历 Bean ，逐个处理
+	for (String beanName : getCandidateBeanNames()) {
+		if (!beanName.startsWith(SCOPED_TARGET_NAME_PREFIX)) {
+			// <1.2> 处理 Bean
+			processCandidateBean(beanName);
+		}
+	}
+	// <2> 初始化处理器的方法们。目前是空方法，暂无具体的实现
+	handlerMethodsInitialized(getHandlerMethods());
+}
+```
+
+- `<1.1>` 处，调用 `#getCandidateBeanNames()` 方法，获得所有 Bean 的名字们，然后进行遍历处理。代码如下：
+
+  ```
+  // AbstractHandlerMethodMapping.java
+  
+  /**
+   * Determine the names of candidate beans in the application context.
+   * @since 5.1
+   * @see #setDetectHandlerMethodsInAncestorContexts
+   * @see BeanFactoryUtils#beanNamesForTypeIncludingAncestors
+   */
+  protected String[] getCandidateBeanNames() {
+  	return (this.detectHandlerMethodsInAncestorContexts ? // 可访问
+  			BeanFactoryUtils.beanNamesForTypeIncludingAncestors(obtainApplicationContext(), Object.class) :
+  			obtainApplicationContext().getBeanNamesForType(Object.class));
+  }
+  ```
+
+- `<1.2>` 处，调用 `#processCandidateBean(String beanName)` 方法，处理 Bean。详细解析，见 [「3.5.1 processCandidateBean」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-3-AbstractHandlerMethodMapping/#) 。
+
+- `<2>` 处，调用 `#handlerMethodsInitialized(Map<T, HandlerMethod> handlerMethods)` 方法，初始化处理器的方法们。目前是空方法，暂无具体的实现。代码如下：
+
+  ```
+  // AbstractHandlerMethodMapping.java
+      
+  /**
+   * Invoked after all handler methods have been detected.
+   * @param handlerMethods a read-only map with handler methods and mappings.
+   */
+  protected void handlerMethodsInitialized(Map<T, HandlerMethod> handlerMethods) {
+  }
+  ```
+
+  - 所以，可以忽略这个方法。
+
+### 3.5.1 processCandidateBean
+
+`#processCandidateBean(String beanName)` 方法，判断 Bean 是否为处理器，如果是，则扫描处理器方法。代码如下：
+
+```
+// AbstractHandlerMethodMapping.java
+
+/**
+ * Determine the type of the specified candidate bean and call
+ * {@link #detectHandlerMethods} if identified as a handler type.
+ * <p>This implementation avoids bean creation through checking
+ * {@link org.springframework.beans.factory.BeanFactory#getType}
+ * and calling {@link #detectHandlerMethods} with the bean name.
+ * @param beanName the name of the candidate bean
+ * @since 5.1
+ * @see #isHandler
+ * @see #detectHandlerMethods
+ */
+protected void processCandidateBean(String beanName) {
+    // <1> 获得 Bean 对应的类型
+    Class<?> beanType = null;
+    try {
+        beanType = obtainApplicationContext().getType(beanName);
+    } catch (Throwable ex) {
+        // An unresolvable bean type, probably from a lazy bean - let's ignore it.
+        if (logger.isTraceEnabled()) {
+            logger.trace("Could not resolve type for bean '" + beanName + "'", ex);
+        }
+    }
+    // 判断 Bean 是否为处理器，如果是，则扫描处理器方法
+    if (beanType != null && isHandler(beanType)) { // <2.1>
+        detectHandlerMethods(beanName); // <2.2>
+    }
+}
+```
+
+- `<1>` 处，获得 Bean 对应的类型。
+
+- `<2.1>` 处，调用 `#isHandler(Class<?> beanType)` **抽象**方法，判断 Bean 的类型是否为处理器。代码如下：
+
+  ```
+  // AbstractHandlerMethodMapping.java
+  
+  /**
+   * Whether the given type is a handler with handler methods.
+   * @param beanType the type of the bean being checked
+   * @return "true" if this a handler type, "false" otherwise.
+   */
+  protected abstract boolean isHandler(Class<?> beanType);
+  ```
+
+  - 该方法在 RequestMappingHandlerMapping 类中实现。详细解析，见 [「5.3 isHandler」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-3-AbstractHandlerMethodMapping/#) 。
+
+- `<2.2>` 处，调用 `#detectHandlerMethods(Object handler)` 方法， 扫描处理器的方法们。详细解析，见 [「3.5.2 detectHandlerMethods」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-3-AbstractHandlerMethodMapping/#) 。
+
+### 3.5.2 detectHandlerMethods
+
+`#handlerMethodsInitialized(Map<T, HandlerMethod> handlerMethods)` 方法，初始化处理器的方法们。代码如下：
+
+```
+// AbstractHandlerMethodMapping.java
+
+/**
+ * Look for handler methods in a handler.
+ * @param handler the bean name of a handler or a handler instance
+ */
+protected void detectHandlerMethods(final Object handler) {
+    // <1> 获得处理器类型
+    Class<?> handlerType = (handler instanceof String ?
+            obtainApplicationContext().getType((String) handler) : handler.getClass());
+
+    if (handlerType != null) {
+        // <2> 获得真实的类。因为，handlerType 可能是代理类
+        final Class<?> userType = ClassUtils.getUserClass(handlerType);
+        // <3> 获得匹配的方法的集合
+        Map<Method, T> methods = MethodIntrospector.selectMethods(userType,
+                (MethodIntrospector.MetadataLookup<T>) method -> getMappingForMethod(method, userType)); // 抽象方法，子类实现
+        if (logger.isTraceEnabled()) {
+            logger.trace("Mapped " + methods.size() + " handler method(s) for " + userType + ": " + methods);
+        }
+        // <4> 遍历方法，逐个注册 HandlerMethod
+        methods.forEach((key, mapping) -> {
+            Method invocableMethod = AopUtils.selectInvocableMethod(key, userType);
+            registerHandlerMethod(handler, invocableMethod, mapping);
+        });
+    }
+}
+```
+
+- `<1>` 处，获得处理器类型。这里也分成两种情况，和 [「3.3 createHandlerMethod」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-3-AbstractHandlerMethodMapping/#) 的一样，就不重复赘述了。
+
+- `<2>` 处，调用 `ClassUtils#getUserClass(handlerType)` 方法，获得真实的类。因为，handlerType 可能是代理类。代码如下：
+
+  ```
+  // ClassUtils.java
+  
+  public static Class<?> getUserClass(Class<?> clazz) {
+  	// 如果 CG_CLASS 代理类，则获取其父类
+  	if (clazz.getName().contains(CGLIB_CLASS_SEPARATOR)) {
+  		Class<?> superclass = clazz.getSuperclass();
+  		if (superclass != null && superclass != Object.class) {
+  			return superclass;
+  		}
+  	}
+  	return clazz;
+  }
+  ```
+
+- `<3>` 处，获得匹配的方法的集合。通过 `#getMappingForMethod(Method method, Class<?> handlerType)` **抽象**方法，获得方法的 Mapping 信息。代码如下：
+
+  ```
+  // AbstractHandlerMethodMapping.java
+  
+  /**
+   * Provide the mapping for a handler method. A method for which no
+   * mapping can be provided is not a handler method.
+   * @param method the method to provide a mapping for
+   * @param handlerType the handler type, possibly a sub-type of the method's
+   * declaring class
+   * @return the mapping, or {@code null} if the method is not mapped
+   */
+  @Nullable
+  protected abstract T getMappingForMethod(Method method, Class<?> handlerType);
+  ```
+
+  - 该方法在 RequestMappingHandlerMapping 类中实现。详细解析，见 [「5.4 getMappingForMethod」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-3-AbstractHandlerMethodMapping/#) 。
+
+- `<4>` 处，遍历方法，逐个调用 `#registerHandlerMethod(Object handler, Method method, T mapping)` 方法，注册 HandlerMethod 。代码如下：
+
+  ```
+  // AbstractHandlerMethodMapping.java
+  
+  /**
+   * 注册 HandlerMethod
+   *
+   * Register a handler method and its unique mapping. Invoked at startup for
+   * each detected handler method.
+   * @param handler the bean name of the handler or the handler instance
+   * @param method the method to register
+   * @param mapping the mapping conditions associated with the handler method
+   * @throws IllegalStateException if another method was already registered
+   * under the same mapping
+   */
+  protected void registerHandlerMethod(Object handler, Method method, T mapping) {
+  	this.mappingRegistry.register(mapping, handler, method);
+  }
+  ```
+
+  - 这样，Mapping 和 `handler` + `method` ，就成功注册到 `mappingRegistry` 中。😈 那么，可能比较重要的问题是，究竟 Mapping 是什么？实际上，在 RequestMappingHandlerMapping 中，就是 `@RequestMapping` 解析成的 RequestMappingInfo 对象。淡定淡定，继续细细往下看。
+
+## 3.6 getHandlerInternal
+
+> 艿艿：这个方法，就是我们在 [《精尽 Spring MVC 源码分析 —— HandlerMapping 组件（一）之 AbstractHandlerMapping》](http://svip.iocoder.cn/Spring-MVC/HandlerMapping-1-AbstractHandlerMapping) 中，看到 AbstractHandlerMapping 给子类暴露的**很核心**的方法。
+
+**实现** `#getHandlerInternal(ServerWebExchange exchange)` 方法，获得请求对应的 HandlerMethod 对象。代码如下：
+
+```
+// AbstractHandlerMethodMapping.java
+
+// AbstractHandlerMethodMapping.java
+
+/**
+ * Look up a handler method for the given request.
+ */
+@Override
+protected HandlerMethod getHandlerInternal(HttpServletRequest request) throws Exception {
+    // <1> 获得请求的路径
+    String lookupPath = getUrlPathHelper().getLookupPathForRequest(request);
+    // <2> 获得写锁
+    this.mappingRegistry.acquireReadLock();
+    try {
+        // <3> 获得 HandlerMethod 对象
+        HandlerMethod handlerMethod = lookupHandlerMethod(lookupPath, request);
+        // <4> 进一步，获得 HandlerMethod 对象
+        return (handlerMethod != null ? handlerMethod.createWithResolvedBean() : null);
+    } finally {
+        // <5> 释放写锁
+        this.mappingRegistry.releaseReadLock();
+    }
+}
+```
+
+- `<1>` 处，获得请求的路径。
+
+- `<2>` 处，获得读锁。
+
+- `<3>` 处，调用 `#lookupHandlerMethod(ServerWebExchange exchange)` 方法，获得 HandlerMethod 对象。详细解析，见 [「3.6.1 lookupHandlerMethod」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-3-AbstractHandlerMethodMapping/#) 。
+
+- `<4>` 处，如果获得到 HandlerMethod 对象，则调用 `HandlerMethod#createWithResolvedBean()` 方法，进一步，获得 HandlerMethod 对象。代码如下：
+
+  ```
+  // HandlerMethod.java
+  
+  /**
+   * If the provided instance contains a bean name rather than an object instance,
+   * the bean name is resolved before a {@link HandlerMethod} is created and returned.
+   */
+  public HandlerMethod createWithResolvedBean() {
+  	Object handler = this.bean;
+  	// 如果是 bean 是 String类型，则获取对应的 handler 对象。例如，bean = userController 字符串，获取后，handler = UserController 对象
+  	if (this.bean instanceof String) {
+  		Assert.state(this.beanFactory != null, "Cannot resolve bean name without BeanFactory");
+  		String beanName = (String) this.bean;
+  		handler = this.beanFactory.getBean(beanName);
+  	}
+  	// 创建 HandlerMethod 对象
+  	return new HandlerMethod(this, handler);
+  }
+  ```
+
+  - 比较简单，胖友自己瞅瞅。
+
+- `<5>` 处，释放读锁。
+
+### 3.6.1 lookupHandlerMethod
+
+`#lookupHandlerMethod(ServerWebExchange exchange)` 方法，获得 HandlerMethod 对象。代码如下：
+
+```
+// AbstractHandlerMethodMapping.java
+    
+/**
+ * Look up the best-matching handler method for the current request.
+ * If multiple matches are found, the best match is selected.
+ * @param lookupPath mapping lookup path within the current servlet mapping
+ * @param request the current request
+ * @return the best-matching handler method, or {@code null} if no match
+ * @see #handleMatch(Object, String, HttpServletRequest)
+ * @see #handleNoMatch(Set, String, HttpServletRequest)
+ */
+protected HandlerMethod lookupHandlerMethod(String lookupPath, HttpServletRequest request) throws Exception {
+    // <1> Match 数组，存储匹配上当前请求的结果
+    List<Match> matches = new ArrayList<>();
+    // <1.1> 优先，基于直接 URL 的 Mapping 们，进行匹配
+    List<T> directPathMatches = this.mappingRegistry.getMappingsByUrl(lookupPath);
+    if (directPathMatches != null) {
+        addMatchingMappings(directPathMatches, matches, request);
+    }
+    // <1.2> 其次，扫描注册表的 Mapping 们，进行匹配
+    if (matches.isEmpty()) {
+        // No choice but to go through all mappings...
+        addMatchingMappings(this.mappingRegistry.getMappings().keySet(), matches, request);
+    }
+
+    // <2> 如果匹配到，则获取最佳匹配的 Match 对象的 handlerMethod 属性
+    if (!matches.isEmpty()) {
+        // <2.1> 创建 MatchComparator 对象，排序 matches 结果
+        Comparator<Match> comparator = new MatchComparator(getMappingComparator(request));
+        matches.sort(comparator);
+        // <2.2> 获得首个 Match 对象
+        Match bestMatch = matches.get(0);
+        // <2.3> 处理存在多个 Match 对象的情况！！
+        if (matches.size() > 1) {
+            if (logger.isTraceEnabled()) {
+                logger.trace(matches.size() + " matching mappings: " + matches);
+            }
+            // TODO 1012 cors
+            if (CorsUtils.isPreFlightRequest(request)) {
+                return PREFLIGHT_AMBIGUOUS_MATCH;
+            }
+            // 比较 bestMatch 和 secondBestMatch ，如果相等，说明有问题，抛出 IllegalStateException 异常
+            // 因为，两个优先级一样高，说明无法判断谁更优先
+            Match secondBestMatch = matches.get(1);
+            if (comparator.compare(bestMatch, secondBestMatch) == 0) {
+                Method m1 = bestMatch.handlerMethod.getMethod();
+                Method m2 = secondBestMatch.handlerMethod.getMethod();
+                String uri = request.getRequestURI();
+                throw new IllegalStateException(
+                        "Ambiguous handler methods mapped for '" + uri + "': {" + m1 + ", " + m2 + "}");
+            }
+        }
+        // <2.4> 处理首个 Match 对象
+        handleMatch(bestMatch.mapping, lookupPath, request);
+        // <2.5> 返回首个 Match 对象的 handlerMethod 属性
+        return bestMatch.handlerMethod;
+    // <3> 如果匹配不到，则处理不匹配的情况
+    } else {
+        return handleNoMatch(this.mappingRegistry.getMappings().keySet(), lookupPath, request);
+    }
+}
+```
+
+- `<1>` 处，Match 数组，存储匹配上当前请求的结果。其中，Match 是 AbstractHandlerMethodMapping 的内部类，代码如下：
+
+  ```
+  // AbstractHandlerMethodMapping.java
+  
+  /**
+   * A thin wrapper around a matched HandlerMethod and its mapping, for the purpose of
+   * comparing the best match with a comparator in the context of the current request.
+   */
+  private class Match {
+  
+      /**
+       * Mapping 对象
+       */
+      private final T mapping;
+      /**
+       * HandlerMethod 对象
+       */
+      private final HandlerMethod handlerMethod;
+  
+      public Match(T mapping, HandlerMethod handlerMethod) {
+          this.mapping = mapping;
+          this.handlerMethod = handlerMethod;
+      }
+  
+      @Override
+      public String toString() {
+          return this.mapping.toString();
+      }
+  
+  }
+  ```
+
+  - 将 `mapping` 和 `handlerMethod` 封装在一起的对象。
+
+- `<1.1>` 处，优先，基于**直接 URL 的 Mapping 们**，进行匹配。
+
+- `<1.2>` 处，其次，基于**扫描注册表的 Mapping 们**，进行匹配。
+
+- 上述 `<1.1>` 和 `<1.2>` 处，都会调用 `#addMatchingMappings(Collection<T> mappings, List<Match> matches, ServerWebExchange exchange)` 方法，将当前请求和注册表中的 Mapping 进行匹配。若匹配成功，则生成 Mapping 记录，添加到 `matches` 中。代码如下：
+
+  ```
+  // AbstractHandlerMethodMapping.java
+  
+  private void addMatchingMappings(Collection<T> mappings, List<Match> matches, ServerWebExchange exchange) {
+      // 遍历 Mapping 数组
+  	for (T mapping : mappings) {
+  	    // <1> 执行匹配
+  		T match = getMatchingMapping(mapping, exchange);
+  		// <2> 如果匹配，则创建 Match 对象，添加到 matches 中
+  		if (match != null) {
+  			matches.add(new Match(match, this.mappingRegistry.getMappings().get(mapping)));
+  		}
+  	}
+  }
+  ```
+
+  - `<1>` 处，遍历 Mapping 数组，逐个调用 `#getMatchingMapping(T mapping, ServerWebExchange exchange)` **抽象**方法，执行匹配。代码如下：
+
+    ```
+    // AbstractHandlerMethodMapping.java
+    
+    /**
+     * Check if a mapping matches the current request and return a (potentially
+     * new) mapping with conditions relevant to the current request.
+     * @param mapping the mapping to get a match for
+     * @param exchange the current exchange
+     * @return the match, or {@code null} if the mapping doesn't match
+     */
+    @Nullable
+    protected abstract T getMatchingMapping(T mapping, ServerWebExchange exchange);
+    ```
+
+    - 如果匹配，则返回的结果**非空**。
+    - 该方法在 RequestMappingInfoHandlerMapping 类中实现。详细解析，见 [「5.4 getMappingForMethod」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-3-AbstractHandlerMethodMapping/#) 。
+
+  - `<2>` 处，如果匹配，则创建 Match 对象，添加到 `matches` 中。
+
+- `<2>` 处，如果匹配到，则获取**最佳匹配**的 Match 对象的 `handlerMethod` 属性。
+
+  - `<2.1>` 处，创建 MatchComparator 对象，排序 `matches` 结果。其中 MatchComparator 实现 Comparator 接口，是 AbstractHandlerMethodMapping 的私有类，Match 排序器。代码如下：
+
+    ```
+    // AbstractHandlerMethodMapping.java
+    
+    private class MatchComparator implements Comparator<Match> {
+    
+    	private final Comparator<T> comparator;
+    
+    	public MatchComparator(Comparator<T> comparator) {
+    		this.comparator = comparator;
+    	}
+    
+    	@Override
+    	public int compare(Match match1, Match match2) {
+    		return this.comparator.compare(match1.mapping, match2.mapping);
+    	}
+    }
+    ```
+
+    - 重点在于 `#compare(Match match1, Match match2)` 方法的实现。通过 `mapping` 属性，即 Mapping 对象。详细解析，见 [「4.2 RequestMappingInfo」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-3-AbstractHandlerMethodMapping/#) 。
+
+  - `<2.2>` 处，获得**首个** Match 对象 `bestMatch` 变量。
+
+  - `<2.3>` 处，处理存在多个 Match 对象的情况！！获得**第二** Match 对象 `secondBestMatch` 变量。通过 `bestMatch` 和 `secondBestMatch` 的比较，如果一样的优先级，则抛出 IllegalStateException 异常。因为，两个优先级一样高，说明无法判断谁更优先。
+
+  - `<2.4>` 处，调用 `#handleMatch(T mapping, String lookupPath, HttpServletRequest request)` 方法，设置匹配的路径 `lookupPath` 到请求属性种。代码如下：
+
+    ```
+    // AbstractHandlerMethodMapping.java
+    
+    protected void handleMatch(T mapping, String lookupPath, HttpServletRequest request) {
+    	request.setAttribute(HandlerMapping.PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE, lookupPath);
+    }
+    ```
+
+    - 实际上，这个方法，在 RequestMappingInfoHandlerMapping 中，会被重写。详细解析，见 [「5. RequestMappingInfoHandlerMapping」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-3-AbstractHandlerMethodMapping/#) 中。
+
+  - `<2.5>` 处，返回**首个** Match 对象的 `handlerMethod` 属性，即它是最匹配的。
+
+- `<3>` 处，如果匹配不到，调用 `#handleNoMatch(Set<T> mappings, String lookupPath, HttpServletRequest request)` 方法，处理不匹配的情况。代码如下：
+
+  ```
+  // AbstractHandlerMethodMapping.java
+  
+  /**
+   * Invoked when no matching mapping is not found.
+   * @param mappings all registered mappings
+   * @param lookupPath mapping lookup path within the current servlet mapping
+   * @param request the current request
+   * @throws ServletException in case of errors
+   */
+  @Nullable
+  protected HandlerMethod handleNoMatch(Set<T> mappings, String lookupPath, HttpServletRequest request)
+  		throws Exception {
+  	return null;
+  }
+  ```
+
+  - 目前是空实现，在 RequestMappingInfoHandlerMapping 中，会被重写。详细解析，见 [「5. RequestMappingInfoHandlerMapping」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-3-AbstractHandlerMethodMapping/#) 中。
+
+# 4. RequestMappingInfoHandlerMapping
+
+`org.springframework.web.servlet.mvc.method.RequestMappingInfoHandlerMapping` ，继承 AbstractHandlerMethodMapping 抽象类，定义了使用的泛型 `<T>` 为 `org.springframework.web.servlet.mvc.method.RequestMappingInfo` 类，即 Mapping 类型就是 RequestMappingInfo 。
+
+**这样有什么好处呢**？RequestMappingInfoHandlerMapping 定义了使用了 RequestMappingInfo 对象，而 其子类 RequestMappingHandlerMapping 使用了 `@RequestMapping` 注解，来生成 RequestMappingInfo 对象。这样，如果未来我们自己定义了自己的注解，或者其他方式来生成 RequestMappingHandlerMapping 对象，未尝不可。关于这点，胖友可以再仔细思考下。
+
+- [「3. AbstractHandlerMethodMapping」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-3-AbstractHandlerMethodMapping/#) 的定位
+- [「4. RequestMappingInfoHandlerMapping」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-3-AbstractHandlerMethodMapping/#) 的定位
+- [「5. RequestMappingHandlerMapping」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-3-AbstractHandlerMethodMapping/#) 的定位
+
+## 4.1 构造方法
+
+```
+// RequestMappingInfoHandlerMapping.java
+
+public abstract class RequestMappingInfoHandlerMapping extends AbstractHandlerMethodMapping<RequestMappingInfo> {
+
+	protected RequestMappingInfoHandlerMapping() {
+		setHandlerMethodMappingNamingStrategy(new RequestMappingInfoHandlerMethodMappingNamingStrategy());
+	}
+
+}
+```
+
+- `<T>` 泛型，为 RequestMappingInfo 类型。
+- 设置了 `AbstractHandlerMethodMapping.namingStrategy` 属性，为 RequestMappingInfoHandlerMethodMappingNamingStrategy 对象。关于它，在 [「3.1 构造方法」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-3-AbstractHandlerMethodMapping/#) 已经介绍了。
+
+## 4.2 RequestMappingInfo
+
+> RequestMappingInfo 不是 RequestMappingInfoHandlerMapping 的内部类，但是是 **RequestMappingInfo**-HandlerMapping 的**前缀**。
+
+`org.springframework.web.servlet.mvc.method.RequestMappingInfo` ，实现 RequestCondition 接口，请求匹配信息。
+
+> 关于 `org.springframework.web.servlet.mvc.condition.RequestCondition` ，请求条件接口，定义了三个方法，分别是
+>
+> - `#combine(T other)` 合并方法
+> - `#getMatchingCondition(HttpServletRequest request)` 匹配方法
+> - `#compareTo(T other, HttpServletRequest request)` 比较方法
+>
+> 原代码，胖友点击 [传送门](https://github.com/spring-projects/spring-framework/blob/master/spring-webmvc/src/main/java/org/springframework/web/servlet/mvc/condition/RequestCondition.java) 查看。
+
+### 4.2.1 构造方法
+
+```
+// RequestMappingInfo.java
+
+/**
+ * 名字
+ */
+@Nullable
+private final String name;
+
+/**
+ * 请求路径的条件
+ */
+private final PatternsRequestCondition patternsCondition;
+
+/**
+ * 请求方法的条件
+ */
+private final RequestMethodsRequestCondition methodsCondition;
+
+/**
+ * 参数的条件
+ */
+private final ParamsRequestCondition paramsCondition;
+
+/**
+ * 请求头的条件
+ */
+private final HeadersRequestCondition headersCondition;
+
+/**
+ * 可消费的 Content-Type 的条件
+ */
+private final ConsumesRequestCondition consumesCondition;
+
+/**
+ * 可生产的 Content-Type 的条件
+ */
+private final ProducesRequestCondition producesCondition;
+
+/**
+ * 自定义的条件
+ */
+private final RequestConditionHolder customConditionHolder;
+```
+
+- 这里，我们可以看到各种条件。实际上，和 `@RequestMapping` 注解是一一对应的。所以，每个属性的详细解释，胖友也可以看看 [《使用 @RequestMapping 注解映射请求路径》](https://linesh.gitbooks.io/spring-mvc-documentation-linesh-translation/content/publish/21-3/2-mapping-requests-with-@requestmapping.html) 。
+
+- 😈 实际上，我们日常使用最多的还是 `patternsCondition` 请求路径条件，和 `methodsCondition` 请求方法条件。
+
+- RequestCondition 的整体类图如下，
+
+  ![RequestCondition 类图](http://static.iocoder.cn/images/2022-03-07/01.png)
+
+  RequestCondition 类图
+
+  - 还是比较多的，本文我们只会简单介绍 PatternsRequestCondition 的实现。
+  - 😈 Google 了一圈，是不是已经有人详细写了 RequestCondition 的解析，发现还没人细写。说明，可能都不太感兴趣，哈哈哈哈。
+
+### 4.2.2 getMatchingCondition
+
+`#getMatchingCondition(HttpServletRequest request)` 方法，从当前 RequestMappingInfo 获得匹配的条件。如果匹配，则基于其匹配的条件，创建**新的** RequestMappingInfo 对象。如果不匹配，则返回 `null` 。代码如下：
+
+```
+// RequestMappingInfo.java
+
+@SuppressWarnings("Duplicates")
+@Override
+@Nullable
+public RequestMappingInfo getMatchingCondition(HttpServletRequest request) {
+    // 匹配 methodsCondition、paramsCondition、headersCondition、consumesCondition、producesCondition
+	RequestMethodsRequestCondition methods = this.methodsCondition.getMatchingCondition(request);
+	ParamsRequestCondition params = this.paramsCondition.getMatchingCondition(request);
+	HeadersRequestCondition headers = this.headersCondition.getMatchingCondition(request);
+	ConsumesRequestCondition consumes = this.consumesCondition.getMatchingCondition(request);
+	ProducesRequestCondition produces = this.producesCondition.getMatchingCondition(request);
+	// 如果任一为空，则返回 null ，表示匹配失败
+	if (methods == null || params == null || headers == null || consumes == null || produces == null) {
+		return null;
+	}
+
+	// 匹配 patternsCondition
+	PatternsRequestCondition patterns = this.patternsCondition.getMatchingCondition(request);
+	if (patterns == null) { // 如果 patterns 为空，则返回 null ，表示匹配失败
+		return null;
+	}
+
+	// 匹配 customConditionHolder
+	RequestConditionHolder custom = this.customConditionHolder.getMatchingCondition(request);
+	if (custom == null) { // 如果 custom 为空，则返回 null ，表示匹配失败
+		return null;
+	}
+
+	// 创建匹配的 RequestMappingInfo 对象。
+	// 为什么要创建 RequestMappingInfo 对象呢？因为当前 RequestMappingInfo 对象，一个 methodsCondition 可以配置 GET、POST、DELETE 等等条件，但是实际就匹配一个请求类型，此时 methods 只代表其匹配的那个。
+	return new RequestMappingInfo(this.name, patterns,
+			methods, params, headers, consumes, produces, custom.getCondition());
+}
+```
+
+- 虽然代码非常长，实际都是调用每个属性对应的 `#getMatchingCondition(HttpServletRequest request)` 方法，获得其匹配的**真正的**条件。
+
+- 那么可能胖友会疑惑，如果一个 `@RequestMapping(value = "user/login")` 注解，并未写 **RequestMethod** 的条件，岂不是会报空？实际上不会。在这种情况下，会创建一个 RequestMethodsRequestCondition 对象，并且在匹配时，直接返回自身。代码如下：
+
+  ```
+  // RequestMappingInfo.java
+  
+  /**
+   * RequestMethod 集合
+   */
+  private final Set<RequestMethod> methods;
+  
+  @Override
+  @Nullable
+  public RequestMethodsRequestCondition getMatchingCondition(HttpServletRequest request) {
+  	if (CorsUtils.isPreFlightRequest(request)) {
+  		return matchPreFlight(request);
+  	}
+  
+  	// 空的情况下，就返回自身
+  	if (getMethods().isEmpty()) {
+  		if (RequestMethod.OPTIONS.name().equals(request.getMethod()) &&
+  				!DispatcherType.ERROR.equals(request.getDispatcherType())) {
+  			return null; // No implicit match for OPTIONS (we handle it)
+  		}
+  		return this;
+  	}
+  
+  	// 非空，逐个匹配
+  	return matchRequestMethod(request.getMethod());
+  }
+  ```
+
+```
+* 也就是说，没有 **RequestMethod** 的条件，一定匹配成功，且结果就是自身 RequestMethodsRequestCondition 对象。
+```
+
+- 这个方法，详细的代码，胖友自己瞅瞅落。
+
+### 4.2.3 compareTo
+
+`#compareTo(RequestMappingInfo other, HttpServletRequest request)` 方法，比较优先级。代码如下：
+
+```
+// RequestMappingInfo.java
+
+/**
+ * Compares "this" info (i.e. the current instance) with another info in the context of a request.
+ * <p>Note: It is assumed both instances have been obtained via
+ * {@link #getMatchingCondition(HttpServletRequest)} to ensure they have conditions with
+ * content relevant to current request.
+ */
+@Override
+public int compareTo(RequestMappingInfo other, HttpServletRequest request) {
+	int result;
+	// Automatic vs explicit HTTP HEAD mapping
+	// 针对 HEAD 请求方法，特殊处理
+	if (HttpMethod.HEAD.matches(request.getMethod())) {
+		result = this.methodsCondition.compareTo(other.getMethodsCondition(), request);
+		if (result != 0) {
+			return result;
+		}
+	}
+	// 比较 patternsCondition
+	result = this.patternsCondition.compareTo(other.getPatternsCondition(), request);
+	if (result != 0) {
+		return result;
+	}
+	// 比较 paramsCondition
+	result = this.paramsCondition.compareTo(other.getParamsCondition(), request);
+	if (result != 0) {
+		return result;
+	}
+	// 比较 headersCondition
+	result = this.headersCondition.compareTo(other.getHeadersCondition(), request);
+	if (result != 0) {
+		return result;
+	}
+	// 比较 consumesCondition
+	result = this.consumesCondition.compareTo(other.getConsumesCondition(), request);
+	if (result != 0) {
+		return result;
+	}
+	// 比较 producesCondition
+	result = this.producesCondition.compareTo(other.getProducesCondition(), request);
+	if (result != 0) {
+		return result;
+	}
+	// Implicit (no method) vs explicit HTTP method mappings
+	// 比较 methodsCondition
+	result = this.methodsCondition.compareTo(other.getMethodsCondition(), request);
+	if (result != 0) {
+		return result;
+	}
+	// 比较 customConditionHolder
+	result = this.customConditionHolder.compareTo(other.customConditionHolder, request);
+	if (result != 0) {
+		return result;
+	}
+	return 0;
+}
+```
+
+- 虽然代码非常长，实际都是按照优先级，逐个调用每个属性对应的 `#compareTo(RequestMethodsRequestCondition other, HttpServletRequest request)` 方法，直到比到**不相等**。
+
+### 4.2.4 PatternsRequestCondition
+
+`org.springframework.web.servlet.mvc.condition.PatternsRequestCondition` ，继承 AbstractRequestCondition 抽象类，请求路径条件。
+
+这是最重要的 RequestCondition 实现类，所以胖友一定要看看。😈 当然，艿艿这里先偷懒下，胖友可以看看 [《详解 SpringMVC 请求的时候是如何找到正确的 Controller [附带源码分析\]》](https://www.cnblogs.com/fangjian0423/p/springMVC-request-mapping.html) 的 [「PatternsRequestCondition」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-3-AbstractHandlerMethodMapping/#) 部分。
+
+- 当然，艿艿还是写了 PatternsRequestCondition 的简单注释。
+
+## 4.3 getMappingPathPatterns
+
+`#getMappingPathPatterns(RequestMappingInfo info)` 方法，获得 Mapping 对应的请求路径集合。代码如下：
+
+```
+// RequestMappingInfoHandlerMapping.java
+
+/**
+ * Get the URL path patterns associated with this {@link RequestMappingInfo}.
+ */
+@Override
+protected Set<String> getMappingPathPatterns(RequestMappingInfo info) {
+	return info.getPatternsCondition().getPatterns();
+}
+```
+
+- 该方法，在 [「3.2.2 register」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-3-AbstractHandlerMethodMapping/#) 中，看到对该方法的调用。
+
+> 艿艿：因为担心调用栈太深，文章无法排版。所以文章相对来说，按照类的维度来写。所以，一些方法的解释，胖友一定要结合着看看。😈 最好，边看，边结合 IDEA 调试。
+
+## 4.4 getMatchingMapping
+
+`#getMatchingMapping(RequestMappingInfo info, HttpServletRequest request)` 方法，获得请求对应的 RequestMappingInfo 对象。代码如下：
+
+```
+// RequestMappingInfoHandlerMapping.java
+
+/**
+ * Check if the given RequestMappingInfo matches the current request and
+ * return a (potentially new) instance with conditions that match the
+ * current request -- for example with a subset of URL patterns.
+ * @return an info in case of a match; or {@code null} otherwise.
+ */
+@Override
+protected RequestMappingInfo getMatchingMapping(RequestMappingInfo info, HttpServletRequest request) {
+	return info.getMatchingCondition(request);
+}
+```
+
+- 方法内部，调用的就是 [「4.2.2 getMatchingCondition」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-3-AbstractHandlerMethodMapping/#) 的方法。
+- 该方法，在 [「3.6.1 lookupHandlerMethod」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-3-AbstractHandlerMethodMapping/#) 中，看到对该方法的调用。
+
+## 4.5 handleMatch
+
+`#handleMatch(RequestMappingInfo info, String lookupPath, HttpServletRequest request)` 方法，覆写父类的方法，设置更多的属性，到请求中。代码如下：
+
+```
+// RequestMappingInfoHandlerMapping.java
+
+/**
+ * Expose URI template variables, matrix variables, and producible media types in the request.
+ * @see HandlerMapping#URI_TEMPLATE_VARIABLES_ATTRIBUTE
+ * @see HandlerMapping#MATRIX_VARIABLES_ATTRIBUTE
+ * @see HandlerMapping#PRODUCIBLE_MEDIA_TYPES_ATTRIBUTE
+ */
+@Override
+protected void handleMatch(RequestMappingInfo info, String lookupPath, HttpServletRequest request) {
+	super.handleMatch(info, lookupPath, request);
+
+	// 获得 bestPattern 和 uriVariables
+	String bestPattern; // 最佳路径
+	Map<String, String> uriVariables; // 路径上的变量集合
+	Set<String> patterns = info.getPatternsCondition().getPatterns();
+	if (patterns.isEmpty()) {
+		bestPattern = lookupPath;
+		uriVariables = Collections.emptyMap();
+	} else {
+		bestPattern = patterns.iterator().next();
+		uriVariables = getPathMatcher().extractUriTemplateVariables(bestPattern, lookupPath);
+	}
+	request.setAttribute(BEST_MATCHING_PATTERN_ATTRIBUTE, bestPattern);
+
+	// 设置 MATRIX_VARIABLES_ATTRIBUTE 属性，到请求中
+	if (isMatrixVariableContentAvailable()) {
+		Map<String, MultiValueMap<String, String>> matrixVars = extractMatrixVariables(request, uriVariables);
+		request.setAttribute(HandlerMapping.MATRIX_VARIABLES_ATTRIBUTE, matrixVars);
+	}
+
+	// 设置 URI_TEMPLATE_VARIABLES_ATTRIBUTE 属性，到请求中
+	Map<String, String> decodedUriVariables = getUrlPathHelper().decodePathVariables(request, uriVariables);
+	request.setAttribute(HandlerMapping.URI_TEMPLATE_VARIABLES_ATTRIBUTE, decodedUriVariables);
+
+	// 设置 PRODUCIBLE_MEDIA_TYPES_ATTRIBUTE 属性，到请求中
+	if (!info.getProducesCondition().getProducibleMediaTypes().isEmpty()) {
+		Set<MediaType> mediaTypes = info.getProducesCondition().getProducibleMediaTypes();
+		request.setAttribute(PRODUCIBLE_MEDIA_TYPES_ATTRIBUTE, mediaTypes);
+	}
+}
+```
+
+这个方法，会调用如下两个方法，感兴趣的胖友，自己研究下：
+
+- `isMatrixVariableContentAvailable()` 方法
+- `extractMatrixVariables(HttpServletRequest request, Map<String, String> uriVariables)` 方法
+
+## 4.6 handleNoMatch
+
+`#handleNoMatch(Set<RequestMappingInfo> infos, String lookupPath, HttpServletRequest request)` 方法，覆写父类方法，处理无匹配 Mapping 的情况。主要用途是，给出为什么找不到 Mapping 的原因。代码如下：
+
+```
+// RequestMappingInfoHandlerMapping.java
+
+/**
+ * Iterate all RequestMappingInfo's once again, look if any match by URL at
+ * least and raise exceptions according to what doesn't match.
+ * @throws HttpRequestMethodNotSupportedException if there are matches by URL
+ * but not by HTTP method
+ * @throws HttpMediaTypeNotAcceptableException if there are matches by URL
+ * but not by consumable/producible media types
+ */
+@Override
+protected HandlerMethod handleNoMatch(
+        Set<RequestMappingInfo> infos, String lookupPath, HttpServletRequest request) throws ServletException {
+    // <1> 创建 PartialMatchHelper 对象，解析可能的错误
+    PartialMatchHelper helper = new PartialMatchHelper(infos, request);
+    if (helper.isEmpty()) {
+        return null;
+    }
+
+    // <2> 方法错误
+    if (helper.hasMethodsMismatch()) {
+        Set<String> methods = helper.getAllowedMethods();
+        if (HttpMethod.OPTIONS.matches(request.getMethod())) {
+            HttpOptionsHandler handler = new HttpOptionsHandler(methods);
+            return new HandlerMethod(handler, HTTP_OPTIONS_HANDLE_METHOD);
+        }
+        throw new HttpRequestMethodNotSupportedException(request.getMethod(), methods);
+    }
+
+    // 可消费的 Content-Type 错误
+    if (helper.hasConsumesMismatch()) {
+        Set<MediaType> mediaTypes = helper.getConsumableMediaTypes();
+        MediaType contentType = null;
+        if (StringUtils.hasLength(request.getContentType())) {
+            try {
+                contentType = MediaType.parseMediaType(request.getContentType());
+            } catch (InvalidMediaTypeException ex) {
+                throw new HttpMediaTypeNotSupportedException(ex.getMessage());
+            }
+        }
+        throw new HttpMediaTypeNotSupportedException(contentType, new ArrayList<>(mediaTypes));
+    }
+
+    // 可生产的 Content-Type 错误
+    if (helper.hasProducesMismatch()) {
+        Set<MediaType> mediaTypes = helper.getProducibleMediaTypes();
+        throw new HttpMediaTypeNotAcceptableException(new ArrayList<>(mediaTypes));
+    }
+
+    // <5> 参数错误
+    if (helper.hasParamsMismatch()) {
+        List<String[]> conditions = helper.getParamConditions();
+        throw new UnsatisfiedServletRequestParameterException(conditions, request.getParameterMap());
+    }
+
+    return null;
+}
+```
+
+- `<1>` 处，核心代码在 PartialMatchHelper 中实现，当然 😈 本文还是不详细解析，感兴趣的朋友，自己瞅瞅。
+- `<2>` 处，方法错误。这是一个非常常见的错误，例如说 `POST user/login` 存在，但是我们请求了 `GET user/login` 。
+- `<5>` 处，参数错误。
+- 如果胖友想要对这个方法抛出的异常，作进一步的处理，可以参考 [《Spring Boot 全局异常处理及自定义异常类》](https://blog.csdn.net/qq_34083066/article/details/79424142) 。
+
+# 5. RequestMappingHandlerMapping
+
+`org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping`，实现 MatchableHandlerMapping 接口、EmbeddedValueResolverAware 接口，继承 RequestMappingInfoHandlerMapping 抽象类，基于 `@RequestMapping` 注解来构建 RequestMappingInfo 对象。
+
+## 5.1 构造方法
+
+```
+// RequestMappingHandlerMapping.java
+
+private boolean useSuffixPatternMatch = true;
+
+private boolean useRegisteredSuffixPatternMatch = false;
+
+private boolean useTrailingSlashMatch = true;
+
+private Map<String, Predicate<Class<?>>> pathPrefixes = new LinkedHashMap<>();
+
+private ContentNegotiationManager contentNegotiationManager = new ContentNegotiationManager();
+
+@Nullable
+private StringValueResolver embeddedValueResolver;
+
+/**
+ * RequestMappingInfo.BuilderConfiguration 配置
+ */
+private RequestMappingInfo.BuilderConfiguration config = new RequestMappingInfo.BuilderConfiguration();
+```
+
+- 如果胖友想设置如上的值，可以参考 [《Spring mvc autowire RequestMappingHandlerMapping》](https://stackoverflow.com/questions/31893335/spring-mvc-autowire-requestmappinghandlermapping) 。
+
+## 5.2 afterPropertiesSet
+
+```
+// RequestMappingHandlerMapping.java
+
+@Override
+public void afterPropertiesSet() {
+	// 构建 RequestMappingInfo.BuilderConfiguration 对象
+	this.config = new RequestMappingInfo.BuilderConfiguration();
+	this.config.setUrlPathHelper(getUrlPathHelper());
+	this.config.setPathMatcher(getPathMatcher());
+	this.config.setSuffixPatternMatch(this.useSuffixPatternMatch);
+	this.config.setTrailingSlashMatch(this.useTrailingSlashMatch);
+	this.config.setRegisteredSuffixPatternMatch(this.useRegisteredSuffixPatternMatch);
+	this.config.setContentNegotiationManager(getContentNegotiationManager());
+
+	// 调用父类，初始化
+	super.afterPropertiesSet();
+}
+```
+
+## 5.3 isHandler
+
+> 艿艿：😈 看到此处，有没很感动的感觉。
+
+实现 `#isHandler(Class<?> beanType)` 方法，判断是否为处理器。代码如下：
+
+```
+// RequestMappingHandlerMapping.java
+
+/**
+ * {@inheritDoc}
+ * <p>Expects a handler to have either a type-level @{@link Controller}
+ * annotation or a type-level @{@link RequestMapping} annotation.
+ */
+@Override
+protected boolean isHandler(Class<?> beanType) {
+	return (AnnotatedElementUtils.hasAnnotation(beanType, Controller.class) ||
+			AnnotatedElementUtils.hasAnnotation(beanType, RequestMapping.class));
+}
+```
+
+## 5.4 getMappingForMethod
+
+> 艿艿：😈 看到此处，有没更感动的感觉。
+
+`#getMappingForMethod(Method method, Class<?> handlerType)` 方法，获得方法上的 RequestMappingInfo 对象，基于 `@RequestMapping` 构造。代码如下：
+
+```
+// RequestMappingHandlerMapping.java
+
+/**
+ * Uses method and type-level @{@link RequestMapping} annotations to create
+ * the RequestMappingInfo.
+ * @return the created RequestMappingInfo, or {@code null} if the method
+ * does not have a {@code @RequestMapping} annotation.
+ * @see #getCustomMethodCondition(Method)
+ * @see #getCustomTypeCondition(Class)
+ */
+@Override
+@Nullable
+protected RequestMappingInfo getMappingForMethod(Method method, Class<?> handlerType) {
+    // <1> 基于方法上的 @RequestMapping 注解，创建 RequestMappingInfo 对象
+    RequestMappingInfo info = createRequestMappingInfo(method);
+    if (info != null) {
+        // <2> 基于类上的 @RequestMapping 注解，合并进去
+        RequestMappingInfo typeInfo = createRequestMappingInfo(handlerType);
+        if (typeInfo != null) {
+            info = typeInfo.combine(info);
+        }
+        // <3> 如果有前缀，则设置到 info 中
+        String prefix = getPathPrefix(handlerType);
+        if (prefix != null) {
+            info = RequestMappingInfo.paths(prefix).build().combine(info);
+        }
+    }
+    return info;
+}
+```
+
+- `<1>` 处，调用 `#createRequestMappingInfo(AnnotatedElement element)` 方法，基于方法上的 `@RequestMapping` 注解，创建 RequestMappingInfo 对象。代码如下：
+
+  ```
+  // RequestMappingHandlerMapping.java
+  
+  /**
+   * Delegates to {@link #createRequestMappingInfo(RequestMapping, RequestCondition)},
+   * supplying the appropriate custom {@link RequestCondition} depending on whether
+   * the supplied {@code annotatedElement} is a class or method.
+   * @see #getCustomTypeCondition(Class)
+   * @see #getCustomMethodCondition(Method)
+   */
+  @Nullable
+  private RequestMappingInfo createRequestMappingInfo(AnnotatedElement element) {
+  	// <1> 获得 @RequestMapping 注解
+  	RequestMapping requestMapping = AnnotatedElementUtils.findMergedAnnotation(element, RequestMapping.class);
+  	// <2> 获得自定义的条件。目前都是空方法，可以无视
+  	RequestCondition<?> condition = (element instanceof Class ?
+  			getCustomTypeCondition((Class<?>) element) : getCustomMethodCondition((Method) element));
+  	// <3> 基于 @RequestMapping 注解，创建 RequestMappingInfo 对象
+  	return (requestMapping != null ? createRequestMappingInfo(requestMapping, condition) : null);
+  }
+  ```
+
+  - `<1>` 处，获得 `@RequestMapping` 注解。当然，`@GetMapping`、`@PostMapping` 等等注解，也可以被扫描到。
+
+  - `<2>` 处，获得自定义的条件。目前都是空方法，可以无视。代码如下：
+
+    ```
+    // RequestMappingHandlerMapping.java
+    
+    /**
+     * Provide a custom type-level request condition.
+     * The custom {@link RequestCondition} can be of any type so long as the
+     * same condition type is returned from all calls to this method in order
+     * to ensure custom request conditions can be combined and compared.
+     * <p>Consider extending {@link AbstractRequestCondition} for custom
+     * condition types and using {@link CompositeRequestCondition} to provide
+     * multiple custom conditions.
+     * @param handlerType the handler type for which to create the condition
+     * @return the condition, or {@code null}
+     */
+    @Nullable
+    protected RequestCondition<?> getCustomTypeCondition(Class<?> handlerType) {
+    	return null;
+    }
+    
+    /**
+     * Provide a custom method-level request condition.
+     * The custom {@link RequestCondition} can be of any type so long as the
+     * same condition type is returned from all calls to this method in order
+     * to ensure custom request conditions can be combined and compared.
+     * <p>Consider extending {@link AbstractRequestCondition} for custom
+     * condition types and using {@link CompositeRequestCondition} to provide
+     * multiple custom conditions.
+     * @param method the handler method for which to create the condition
+     * @return the condition, or {@code null}
+     */
+    @Nullable
+    protected RequestCondition<?> getCustomMethodCondition(Method method) {
+    	return null;
+    }
+    ```
+
+    - 可以暂时无视。
+
+  - `<3>` 处，调用 `#createRequestMappingInfo(RequestMapping requestMapping, RequestCondition<?> customCondition)` 方法，基于 `@RequestMapping` 注解，创建 RequestMappingInfo 对象。代码如下：
+
+    ```
+    // RequestMappingHandlerMapping.java
+    
+    /**
+     * Create a {@link RequestMappingInfo} from the supplied
+     * {@link RequestMapping @RequestMapping} annotation, which is either
+     * a directly declared annotation, a meta-annotation, or the synthesized
+     * result of merging annotation attributes within an annotation hierarchy.
+     */
+    protected RequestMappingInfo createRequestMappingInfo(RequestMapping requestMapping, @Nullable RequestCondition<?> customCondition) {
+    // 创建 RequestMappingInfo.Builder 对象，设置对应属性
+    	RequestMappingInfo.Builder builder = RequestMappingInfo
+    			.paths(resolveEmbeddedValuesInPatterns(requestMapping.path()))
+    			.methods(requestMapping.method())
+    			.params(requestMapping.params())
+    			.headers(requestMapping.headers())
+    			.consumes(requestMapping.consumes())
+    			.produces(requestMapping.produces())
+    			.mappingName(requestMapping.name());
+    	if (customCondition != null) {
+    		builder.customCondition(customCondition);
+    	}
+    	// 创建 RequestMappingInfo 对象
+    	return builder.options(this.config).build();
+    }
+    ```
+
+    - 关于 RequestMappingInfo.Builder 类，胖友自己可以简单看看。
+
+- `<2>` 处，基于类上的 `@RequestMapping` 注解，创建 RequestMappingInfo 对象，并合并进去。
+
+- `<3>` 处，如果有前缀，则设置到 `info` 中。
+
+## 5.5 match
+
+`#match(HttpServletRequest request, String pattern)` 方法，执行匹配。代码如下：
+
+```
+// RequestMappingHandlerMapping.java
+
+@Override
+public RequestMatchResult match(HttpServletRequest request, String pattern) {
+	// 创建 RequestMappingInfo 对象
+	RequestMappingInfo info = RequestMappingInfo.paths(pattern).options(this.config).build();
+	// 获得匹配的 RequestMappingInfo 对象
+	RequestMappingInfo matchingInfo = info.getMatchingCondition(request);
+	if (matchingInfo == null) { // 如果不匹配，则返回 null
+		return null;
+	}
+	// 获得请求路径的集合
+	Set<String> patterns = matchingInfo.getPatternsCondition().getPatterns();
+	// 获得请求的路径
+	String lookupPath = getUrlPathHelper().getLookupPathForRequest(request);
+	// 创建 RequestMatchResult 结果
+	return new RequestMatchResult(patterns.iterator().next(), lookupPath, getPathMatcher());
+}
+```
+
+# 666. 彩蛋
+
+卧槽，又好长一篇。有点吐血了！！！！！
+
+参考和推荐如下文章：
+
+- 韩路彪 [《看透 Spring MVC：源代码分析与实践》](https://item.jd.com/11807414.html) 的 [「12.3 AbstractHandlerMethodMapping 系列」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-3-AbstractHandlerMethodMapping/#) 小节
\ No newline at end of file
diff --git a/springmvc/13-Spring MVC 源码解析-HandlerMapping 组件（四）之 AbstractUrlHandlerMapping.assets/01-17199770676931.png b/springmvc/13-Spring MVC 源码解析-HandlerMapping 组件（四）之 AbstractUrlHandlerMapping.assets/01-17199770676931.png
new file mode 100644
index 0000000..dd931d4
Binary files /dev/null and b/springmvc/13-Spring MVC 源码解析-HandlerMapping 组件（四）之 AbstractUrlHandlerMapping.assets/01-17199770676931.png differ
diff --git a/springmvc/13-Spring MVC 源码解析-HandlerMapping 组件（四）之 AbstractUrlHandlerMapping.assets/01.png b/springmvc/13-Spring MVC 源码解析-HandlerMapping 组件（四）之 AbstractUrlHandlerMapping.assets/01.png
new file mode 100644
index 0000000..e54f861
Binary files /dev/null and b/springmvc/13-Spring MVC 源码解析-HandlerMapping 组件（四）之 AbstractUrlHandlerMapping.assets/01.png differ
diff --git a/springmvc/13-Spring MVC 源码解析-HandlerMapping 组件（四）之 AbstractUrlHandlerMapping.md b/springmvc/13-Spring MVC 源码解析-HandlerMapping 组件（四）之 AbstractUrlHandlerMapping.md
new file mode 100644
index 0000000..45cb3a9
--- /dev/null
+++ b/springmvc/13-Spring MVC 源码解析-HandlerMapping 组件（四）之 AbstractUrlHandlerMapping.md	
@@ -0,0 +1,755 @@
+# 精尽 Spring MVC 源码解析 —— HandlerMapping 组件（四）之 AbstractUrlHandlerMapping
+
+> 艿艿：这是一篇相对选读的文章，因为 AbstractUrlHandlerMapping ，我们实际开发基本不会涉及。
+
+# 1. 概述
+
+本文接 [《精尽 Spring MVC 源码分析 —— HandlerMapping 组件（一）之 AbstractHandlerMapping》](http://svip.iocoder.cn/Spring-MVC/HandlerMapping-1-AbstractHandlerMapping) 一文，分享 AbstractHandlerMapping 的左半边 **AbstractUrlHandlerMapping** 系，即下图右半边**红色**部分：
+
+[![类图](13-Spring MVC 源码解析-HandlerMapping 组件（四）之 AbstractUrlHandlerMapping.assets/01.png)](http://static.iocoder.cn/images/Spring/2022-03-01/01.png)类图
+
+- 一共有五个子类，分成两条线。
+  - AbstractUrlHandlerMapping <= SimpleUrlHandlerMapping <= WebSocketHandlerMapping 。
+  - AbstractUrlHandlerMapping <= AbstractDetectingUrlHandlerMapping <= BeanNameUrlHandlerMapping 。
+- 其中，左下角的 WebSocketHandlerMapping 是 `spring-websocket` 项目中的类，本文会无视它。
+
+所以，本文我们实际会是按照 AbstractUrlHandlerMapping、SimpleUrlHandlerMapping、AbstractDetectingUrlHandlerMapping、BeanNameUrlHandlerMapping 进行顺序分享。
+
+# 2. AbstractUrlHandlerMapping
+
+`org.springframework.web.servlet.handler.AbstractUrlHandlerMapping` ，实现 MatchableHandlerMapping 接口，继承 AbstractHandlerMapping 抽象类，以 **URL** 作为 **Handler** 的 HandlerMapping 抽象类，提供 Handler 的获取、注册等等通用的骨架方法。
+
+## 2.1 构造方法
+
+```
+// AbstractUrlHandlerMapping.java
+
+/**
+ * 根路径的处理器
+ */
+@Nullable
+private Object rootHandler;
+
+/**
+ * 使用后置的 / 匹配
+ */
+private boolean useTrailingSlashMatch = false;
+
+/**
+ * 是否延迟加载处理器
+ *
+ * 默认，关闭。
+ */
+private boolean lazyInitHandlers = false;
+
+/**
+ * 路径和处理器的映射
+ *
+ * KEY：路径 {@link #lookupHandler(String, HttpServletRequest)}
+ */
+private final Map<String, Object> handlerMap = new LinkedHashMap<>();
+```
+
+## 2.2 registerHandler
+
+`#registerHandler(String[] urlPaths, String beanName)` 方法，注册多个 URL 的处理器。代码如下：
+
+```
+// AbstractUrlHandlerMapping.java
+
+/**
+ * 注册指定 URL 数组的处理器
+ *
+ * Register the specified handler for the given URL paths.
+ * @param urlPaths the URLs that the bean should be mapped to
+ * @param beanName the name of the handler bean
+ * @throws BeansException if the handler couldn't be registered
+ * @throws IllegalStateException if there is a conflicting handler registered
+ */
+protected void registerHandler(String[] urlPaths, String beanName) throws BeansException, IllegalStateException {
+    Assert.notNull(urlPaths, "URL path array must not be null");
+    // 遍历 urlPath 数组
+    for (String urlPath : urlPaths) {
+        // 注册处理器
+        registerHandler(urlPath, beanName);
+    }
+}
+```
+
+------
+
+`#registerHandler(String urlPath, Object handler)` 方法，注册单个 URL 的处理器。代码如下：
+
+```
+// AbstractUrlHandlerMapping.java
+
+/**
+ * 注册单个 URL 的处理器
+ *
+ * Register the specified handler for the given URL path.
+ * @param urlPath the URL the bean should be mapped to
+ * @param handler the handler instance or handler bean name String
+ * (a bean name will automatically be resolved into the corresponding handler bean)
+ * @throws BeansException if the handler couldn't be registered
+ * @throws IllegalStateException if there is a conflicting handler registered
+ */
+protected void registerHandler(String urlPath, Object handler) throws BeansException, IllegalStateException {
+    Assert.notNull(urlPath, "URL path must not be null");
+    Assert.notNull(handler, "Handler object must not be null");
+    Object resolvedHandler = handler;
+
+    // Eagerly resolve handler if referencing singleton via name.
+    // <1> 如果非延迟加载，并且 handler 为 String 类型，并且还是单例，则去获取 String 对应的 Bean 对象
+    if (!this.lazyInitHandlers && handler instanceof String) {
+        String handlerName = (String) handler;
+        ApplicationContext applicationContext = obtainApplicationContext();
+        if (applicationContext.isSingleton(handlerName)) { // 必须是单例
+            resolvedHandler = applicationContext.getBean(handlerName);
+        }
+    }
+
+    // <2> 获得 urlPath 对应的处理器
+    Object mappedHandler = this.handlerMap.get(urlPath);
+    // <3> 如果已经存在，并且和 resolvedHandler 不同，则抛出 IllegalStateException 异常
+    if (mappedHandler != null) {
+        if (mappedHandler != resolvedHandler) {
+            throw new IllegalStateException(
+                    "Cannot map " + getHandlerDescription(handler) + " to URL path [" + urlPath +
+                    "]: There is already " + getHandlerDescription(mappedHandler) + " mapped.");
+        }
+    } else {
+        // <4.1> 如果是 / 根路径，则设置为 rootHandler
+        if (urlPath.equals("/")) {
+            if (logger.isTraceEnabled()) {
+                logger.trace("Root mapping to " + getHandlerDescription(handler));
+            }
+            setRootHandler(resolvedHandler);
+        // <4.2> 如果是 /* 路径，则设置为默认处理器
+        } else if (urlPath.equals("/*")) {
+            if (logger.isTraceEnabled()) {
+                logger.trace("Default mapping to " + getHandlerDescription(handler));
+            }
+            setDefaultHandler(resolvedHandler);
+        // <4.3> 添加到 handlerMap 中
+        } else {
+            this.handlerMap.put(urlPath, resolvedHandler);
+            if (logger.isTraceEnabled()) {
+                logger.trace("Mapped [" + urlPath + "] onto " + getHandlerDescription(handler));
+            }
+        }
+    }
+}
+```
+
+- `<1>` 处，如果非延迟加载，并且 `handler` 为 String 类型，并且还是单例，则去获取 String 对应的 Bean 对象。
+- `<2>` 处，获得 `urlPath` 对应的处理器。
+- `<3>` 处，如果已经存在，并且和 `resolvedHandler` 不同，则抛出 IllegalStateException 异常。
+- `<4.1>` 处，如果是 `/` 根路径，则设置处理器为 `rootHandler` 。
+- `<4.2>` 处，如果是 `/*` 路径，则设置处理器为默认处理器。
+- `<4.3>` 处，添加到 `handlerMap` 中。
+
+## 2.3 getHandlerInternal
+
+实现 `#getHandlerInternal(HttpServletRequest request)` 方法，获得处理器。代码如下：
+
+```
+// AbstractUrlHandlerMapping.java
+
+/**
+ * Look up a handler for the URL path of the given request.
+ * @param request current HTTP request
+ * @return the handler instance, or {@code null} if none found
+ */
+@Override
+@Nullable
+protected Object getHandlerInternal(HttpServletRequest request) throws Exception {
+    // <1> 获得请求的路径
+    String lookupPath = getUrlPathHelper().getLookupPathForRequest(request);
+    // <2> 获得处理器
+    Object handler = lookupHandler(lookupPath, request);
+    // <3> 如果找不到处理器，则使用 rootHandler 或 defaultHandler 处理器
+    if (handler == null) {
+        // We need to care for the default handler directly, since we need to
+        // expose the PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE for it as well.
+        Object rawHandler = null;
+        // <3.1> 如果是根路径，则使用 rootHandler 处理器
+        if ("/".equals(lookupPath)) {
+            rawHandler = getRootHandler();
+        }
+        // <3.2> 使用默认处理器
+        if (rawHandler == null) {
+            rawHandler = getDefaultHandler();
+        }
+        if (rawHandler != null) {
+            // Bean name or resolved handler?
+            // <3.3> 如果找到的处理器是 String 类型，则从容器中找到 String 对应的 Bean 类型作为处理器。
+            if (rawHandler instanceof String) {
+                String handlerName = (String) rawHandler;
+                rawHandler = obtainApplicationContext().getBean(handlerName);
+            }
+            // <3.4> 空方法，校验处理器。目前暂无子类实现该方法
+            validateHandler(rawHandler, request);
+            // <3.5> 创建处理器
+            handler = buildPathExposingHandler(rawHandler, lookupPath, lookupPath, null);
+        }
+    }
+    return handler;
+}
+```
+
+- `<1>` 处，获得请求的路径。
+
+- `<2>` 处，调用 `#lookupHandler(String urlPath, HttpServletRequest request)` 方法，获得处理器。详细解析，见 [「2.4 lookupHandler」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-4-AbstractUrlHandlerMapping/#) 。
+
+- `<3>` 处，如果找不到处理器，则使用 `rootHandler` 或 `defaultHandler` 处理器。
+
+  - `<3.1>` 处， 如果是**根**路径，则使用 `rootHandler` 处理器。
+
+  - `<3.2>` 处，使用**默认**处理器。
+
+  - `<3.3>` 处，如果找到的处理器是 String 类型，则从容器中找到 String 对应的 Bean 类型作为处理器。
+
+  - `<3.4>` 处，调用 `#validateHandler(Object handler, HttpServletRequest request)` 方法，空方法，校验处理器。目前暂无子类实现该方法。代码如下：
+
+    ```
+    // AbstractUrlHandlerMapping.java
+    
+    /**
+     * Validate the given handler against the current request.
+     * <p>The default implementation is empty. Can be overridden in subclasses,
+     * for example to enforce specific preconditions expressed in URL mappings.
+     * @param handler the handler object to validate
+     * @param request current HTTP request
+     * @throws Exception if validation failed
+     */
+    protected void validateHandler(Object handler, HttpServletRequest request) throws Exception {
+    }
+    ```
+
+    - 忽略忽略~
+
+  - `<3.5>` 处，调用 `#buildPathExposingHandler(handler, bestMatch, pathWithinMapping, uriTemplateVariables)` 方法，构建暴露路径的 Handler 。详细解析，见 [「2.5 buildPathExposingHandler」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-4-AbstractUrlHandlerMapping/#) 。
+
+## 2.4 lookupHandler
+
+`#lookupHandler(String urlPath, HttpServletRequest request)` 方法，获得处理器。代码如下：
+
+```
+// AbstractUrlHandlerMapping.java
+
+@Nullable
+protected Object lookupHandler(String urlPath, HttpServletRequest request) throws Exception {
+    // Direct match?
+    // <1.1> 情况一，从 handlerMap 中，直接匹配处理器
+    Object handler = this.handlerMap.get(urlPath);
+    if (handler != null) {
+        // Bean name or resolved handler?
+        // <1.2> 如果找到的处理器是 String 类型，则从容器中找到 String 对应的 Bean 类型作为处理器。
+        if (handler instanceof String) {
+            String handlerName = (String) handler;
+            handler = obtainApplicationContext().getBean(handlerName);
+        }
+        // <1.3> 空方法，校验处理器。目前暂无子类实现该方法
+        validateHandler(handler, request);
+        // <1.4> 创建处理器
+        return buildPathExposingHandler(handler, urlPath, urlPath, null);
+    }
+
+    // Pattern match?
+    // <2.1> 情况二，Pattern 匹配合适的，并添加到 matchingPatterns 中
+    List<String> matchingPatterns = new ArrayList<>();
+    for (String registeredPattern : this.handlerMap.keySet()) {
+        if (getPathMatcher().match(registeredPattern, urlPath)) {
+            matchingPatterns.add(registeredPattern);
+        } else if (useTrailingSlashMatch()) {
+            if (!registeredPattern.endsWith("/") && getPathMatcher().match(registeredPattern + "/", urlPath)) {
+                matchingPatterns.add(registeredPattern +"/");
+            }
+        }
+    }
+
+    // <2.2> 获得首个匹配的结果
+    String bestMatch = null;
+    Comparator<String> patternComparator = getPathMatcher().getPatternComparator(urlPath);
+    if (!matchingPatterns.isEmpty()) {
+        matchingPatterns.sort(patternComparator); // 排序
+        if (logger.isTraceEnabled() && matchingPatterns.size() > 1) {
+            logger.trace("Matching patterns " + matchingPatterns);
+        }
+        bestMatch = matchingPatterns.get(0);
+    }
+    if (bestMatch != null) {
+        // <2.3> 获得 bestMatch 对应的处理器
+        handler = this.handlerMap.get(bestMatch);
+        if (handler == null) {
+            if (bestMatch.endsWith("/")) {
+                handler = this.handlerMap.get(bestMatch.substring(0, bestMatch.length() - 1));
+            }
+            if (handler == null) { // 如果获得不到，抛出 IllegalStateException 异常
+                throw new IllegalStateException(
+                        "Could not find handler for best pattern match [" + bestMatch + "]");
+            }
+        }
+        // Bean name or resolved handler?
+        // <2.4> 如果找到的处理器是 String 类型，则从容器中找到 String 对应的 Bean 类型作为处理器。
+        if (handler instanceof String) {
+            String handlerName = (String) handler;
+            handler = obtainApplicationContext().getBean(handlerName);
+        }
+        // <2.5> 空方法，校验处理器。目前暂无子类实现该方法
+        validateHandler(handler, request);
+        // <2.6> 获得匹配的路径
+        String pathWithinMapping = getPathMatcher().extractPathWithinPattern(bestMatch, urlPath);
+
+        // There might be multiple 'best patterns', let's make sure we have the correct URI template variables
+        // for all of them
+        // <2.7> 获得路径参数集合
+        Map<String, String> uriTemplateVariables = new LinkedHashMap<>();
+        for (String matchingPattern : matchingPatterns) {
+            if (patternComparator.compare(bestMatch, matchingPattern) == 0) {
+                Map<String, String> vars = getPathMatcher().extractUriTemplateVariables(matchingPattern, urlPath);
+                Map<String, String> decodedVars = getUrlPathHelper().decodePathVariables(request, vars);
+                uriTemplateVariables.putAll(decodedVars);
+            }
+        }
+        if (logger.isTraceEnabled() && uriTemplateVariables.size() > 0) {
+            logger.trace("URI variables " + uriTemplateVariables);
+        }
+        // <2.8> 创建处理器
+        return buildPathExposingHandler(handler, bestMatch, pathWithinMapping, uriTemplateVariables);
+    }
+
+    // <3> No handler found...
+    return null;
+}
+```
+
+- 逻辑有点长，整体分成两种情况，分别是直接匹配和 Pattern 模式匹配。
+- ============ 情况一：直接匹配 ==========
+- `<1.1>` 处，从 `handlerMap` 中，**直接匹配**处理器。
+- `<1.2>` 处，如果找到的处理器是 String 类型，则从容器中找到 String 对应的 Bean 类型作为处理器。
+- `<1.3>` 处，调用 `#validateHandler(Object handler, HttpServletRequest request)` 方法，空方法，校验处理器。
+- `<1.4>` 处，调用 `#buildPathExposingHandler(handler, bestMatch, pathWithinMapping, uriTemplateVariables)` 方法，构建暴露路径的 Handler 。详细解析，见 [「2.5 buildPathExposingHandler」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-4-AbstractUrlHandlerMapping/#) 。
+- ============ 情况二：模式匹配 ==========
+- `<2.1>` 处，遍历 `handlerMap` 集合，逐个 Pattern 匹配合适的，并添加到 `matchingPatterns` 中。
+- `<2.2>` 处，获得首个匹配的结果 `patternComparator` 。
+- `<2.3>` 处，获得 `bestMatch` 对应的处理器。
+- `<2.4>` 处，如果找到的处理器是 String 类型，则从容器中找到 String 对应的 Bean 类型作为处理器。
+- `<2.5>` 处，调用 `#validateHandler(Object handler, HttpServletRequest request)` 方法，空方法，校验处理器。
+- `<2.6>` 处，获得匹配的路径。😈 这块艿艿暂时没细看。
+- `<2.7>` 处，获得路径参数集合 `uriTemplateVariables` 。😈 这块艿艿也没细看。因为，可能存在多个最佳匹配，所以每个都会比较一次，全部添加到 `uriTemplateVariables` 中。
+- `<2.8>` 处，调用 `#buildPathExposingHandler(handler, bestMatch, pathWithinMapping, uriTemplateVariables)` 方法，构建暴露路径的 Handler 。详细解析，见 [「2.5 buildPathExposingHandler」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-4-AbstractUrlHandlerMapping/#) 。
+- ============ 情况三：都不匹配 ==========
+- `<3>` 处，都不匹配，返回 `null` 。
+
+## 2.5 buildPathExposingHandler
+
+`#buildPathExposingHandler(Object rawHandler, String bestMatchingPattern, String pathWithinMapping, Map<String, String> uriTemplateVariables)` 方法，构建暴露路径的 Handler 。代码如下：
+
+```
+// AbstractUrlHandlerMapping.java
+
+/**
+ * Build a handler object for the given raw handler, exposing the actual
+ * handler, the {@link #PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE}, as well as
+ * the {@link #URI_TEMPLATE_VARIABLES_ATTRIBUTE} before executing the handler.
+ * <p>The default implementation builds a {@link HandlerExecutionChain}
+ * with a special interceptor that exposes the path attribute and uri template variables
+ * @param rawHandler the raw handler to expose
+ * @param pathWithinMapping the path to expose before executing the handler
+ * @param uriTemplateVariables the URI template variables, can be {@code null} if no variables found
+ * @return the final handler object
+ */
+protected Object buildPathExposingHandler(Object rawHandler, String bestMatchingPattern,
+		String pathWithinMapping, @Nullable Map<String, String> uriTemplateVariables) {
+	// <1> 创建 HandlerExecutionChain 对象
+	HandlerExecutionChain chain = new HandlerExecutionChain(rawHandler);
+	// <2.1> 添加 PathExposingHandlerInterceptor 拦截器，到 chain 中
+	chain.addInterceptor(new PathExposingHandlerInterceptor(bestMatchingPattern, pathWithinMapping));
+	// <2.2> 添加 UriTemplateVariablesHandlerInterceptor 拦截器，到 chain 中
+	if (!CollectionUtils.isEmpty(uriTemplateVariables)) {
+		chain.addInterceptor(new UriTemplateVariablesHandlerInterceptor(uriTemplateVariables));
+	}
+	return chain;
+}
+```
+
+- 比较大的特点是，在 `<1>` 处，创建了 HandlerExecutionChain 对象，并且后续在 `<2.1>` 和 `<2.2>` 处，分别添加 PathExposingHandlerInterceptor 和 UriTemplateVariablesHandlerInterceptor 拦截器。用途在于通过这两个拦截器，暴露 `bestMatchingPattern` 和 `uriTemplateVariables` 到请求的属性中。
+
+- PathExposingHandlerInterceptor ，继承 HandlerInterceptorAdapter 类，是 AbstractUrlHandlerMapping 的内部类，代码如下：
+
+  ```
+      // AbstractUrlHandlerMapping.java#PathExposingHandlerInterceptor.java
+  
+  /**
+   * Special interceptor for exposing the
+   * {@link AbstractUrlHandlerMapping#PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE} attribute.
+   * @see AbstractUrlHandlerMapping#exposePathWithinMapping
+   */
+  private class PathExposingHandlerInterceptor extends HandlerInterceptorAdapter {
+  
+      /**
+       * 最佳匹配的路径
+       */
+      private final String bestMatchingPattern;
+  
+      /**
+       * 被匹配的路径
+       */
+      private final String pathWithinMapping;
+  
+      public PathExposingHandlerInterceptor(String bestMatchingPattern, String pathWithinMapping) {
+          this.bestMatchingPattern = bestMatchingPattern;
+          this.pathWithinMapping = pathWithinMapping;
+      }
+  
+      @Override
+      public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
+          // 暴露 BEST_MATCHING_PATTERN_ATTRIBUTE、PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE 属性
+          exposePathWithinMapping(this.bestMatchingPattern, this.pathWithinMapping, request);
+          // 暴露 INTROSPECT_TYPE_LEVEL_MAPPING 属性
+          request.setAttribute(INTROSPECT_TYPE_LEVEL_MAPPING, supportsTypeLevelMappings());
+          return true;
+      }
+  
+  }
+  
+  // AbstractUrlHandlerMapping.java
+  
+  /**
+   * Expose the path within the current mapping as request attribute.
+   * @param pathWithinMapping the path within the current mapping
+   * @param request the request to expose the path to
+   * @see #PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE
+   */
+  protected void exposePathWithinMapping(String bestMatchingPattern, String pathWithinMapping,
+          HttpServletRequest request) {
+      request.setAttribute(BEST_MATCHING_PATTERN_ATTRIBUTE, bestMatchingPattern);
+      request.setAttribute(PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE, pathWithinMapping);
+  }
+  ```
+
+- UriTemplateVariablesHandlerInterceptor ，继承 HandlerInterceptorAdapter 类，是 AbstractUrlHandlerMapping 的内部类，代码如下：
+
+  ```
+  // AbstractUrlHandlerMapping.java#PathExposingHandlerInterceptor.java
+  
+  /**
+   * Special interceptor for exposing the
+   * {@link AbstractUrlHandlerMapping#URI_TEMPLATE_VARIABLES_ATTRIBUTE} attribute.
+   * @see AbstractUrlHandlerMapping#exposePathWithinMapping
+   */
+  private class UriTemplateVariablesHandlerInterceptor extends HandlerInterceptorAdapter {
+  
+  	private final Map<String, String> uriTemplateVariables;
+  
+  	public UriTemplateVariablesHandlerInterceptor(Map<String, String> uriTemplateVariables) {
+  		this.uriTemplateVariables = uriTemplateVariables;
+  	}
+  
+  	@Override
+  	public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
+  		exposeUriTemplateVariables(this.uriTemplateVariables, request);
+  		return true;
+  	}
+  }
+  
+  // AbstractUrlHandlerMapping.java
+  
+  /**
+   * Expose the URI templates variables as request attribute.
+   * @param uriTemplateVariables the URI template variables
+   * @param request the request to expose the path to
+   * @see #PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE
+   */
+  protected void exposeUriTemplateVariables(Map<String, String> uriTemplateVariables, HttpServletRequest request) {
+  	request.setAttribute(URI_TEMPLATE_VARIABLES_ATTRIBUTE, uriTemplateVariables);
+  }
+  ```
+
+## 2.6 match
+
+`#match(HttpServletRequest request, String pattern)` 方法，执行匹配。代码如下：
+
+```
+// AbstractUrlHandlerMapping.java
+
+@Override
+@Nullable
+public RequestMatchResult match(HttpServletRequest request, String pattern) {
+	// 获得请求路径
+	String lookupPath = getUrlPathHelper().getLookupPathForRequest(request);
+	// 模式匹配，若匹配，则返回 RequestMatchResult 对象
+	if (getPathMatcher().match(pattern, lookupPath)) {
+		return new RequestMatchResult(pattern, lookupPath, getPathMatcher());
+	} else if (useTrailingSlashMatch()) {
+		if (!pattern.endsWith("/") && getPathMatcher().match(pattern + "/", lookupPath)) {
+			return new RequestMatchResult(pattern + "/", lookupPath, getPathMatcher());
+		}
+	}
+	// 不匹配，则返回 null
+	return null;
+}
+```
+
+# 3. SimpleUrlHandlerMapping
+
+`org.springframework.web.servlet.handler.SimpleUrlHandlerMapping` ，继承 AbstractUrlHandlerMapping 抽象类，简单的 简单的 UrlHandlerMapping 实现类。
+
+😈 如果胖友使用 Spring MVC 早，可能看过 [《基于 XML 配置的Spring MVC 简单的 HelloWorld 实例应用》](https://www.cnblogs.com/liuhongfeng/p/4769076.html) 这样的配置。当然，现在基本已经不存在了。因为，被 `@RequestMapping` 注解这样的方式所取代。更多的是 Spring MVC 自己内部的组件可能在使用，例如下图：[![使用情况](13-Spring MVC 源码解析-HandlerMapping 组件（四）之 AbstractUrlHandlerMapping.assets/01-17199770676931.png)](http://static.iocoder.cn/images/Spring/2022-03-10/01.png)使用情况
+
+## 3.1 构造方法
+
+```
+// SimpleUrlHandlerMapping.java
+
+/**
+ * 配置的 URL 与处理器的映射
+ *
+ * 最终，会调用 {@link #registerHandlers(Map)} 进行注册到 {@link AbstractUrlHandlerMapping#handlerMap} 中
+ */
+private final Map<String, Object> urlMap = new LinkedHashMap<>();
+```
+
+- 可以通过如下两个方法，设置到 `urlMap` 属性。代码如下：
+
+  ```
+  // SimpleUrlHandlerMapping.java
+  
+  /**
+   * Map URL paths to handler bean names.
+   * This is the typical way of configuring this HandlerMapping.
+   * <p>Supports direct URL matches and Ant-style pattern matches. For syntax
+   * details, see the {@link org.springframework.util.AntPathMatcher} javadoc.
+   * @param mappings properties with URLs as keys and bean names as values
+   * @see #setUrlMap
+   */
+  public void setMappings(Properties mappings) {
+  	CollectionUtils.mergePropertiesIntoMap(mappings, this.urlMap);
+  }
+  
+  /**
+   * Set a Map with URL paths as keys and handler beans (or handler bean names)
+   * as values. Convenient for population with bean references.
+   * <p>Supports direct URL matches and Ant-style pattern matches. For syntax
+   * details, see the {@link org.springframework.util.AntPathMatcher} javadoc.
+   * @param urlMap map with URLs as keys and beans as values
+   * @see #setMappings
+   */
+  public void setUrlMap(Map<String, ?> urlMap) {
+  	this.urlMap.putAll(urlMap);
+  }
+  ```
+
+## 3.2 initApplicationContext
+
+`#initApplicationContext()` 方法，进行初始化。代码如下：
+
+```
+// SimpleUrlHandlerMapping.java
+
+@Override
+public void initApplicationContext() throws BeansException {
+	// 调用父类方法，进行初始化
+	super.initApplicationContext();
+	// 将 urlMap 配置，注册处理器
+	registerHandlers(this.urlMap);
+}
+```
+
+- 调用 `#registerHandlers(Map<String, Object> urlMap)` 方法，将 `urlMap` 配置，注册到处理器。代码如下：
+
+  ```
+  // SimpleUrlHandlerMapping.java
+  
+  /**
+   * Register all handlers specified in the URL map for the corresponding paths.
+   * @param urlMap a Map with URL paths as keys and handler beans or bean names as values
+   * @throws BeansException if a handler couldn't be registered
+   * @throws IllegalStateException if there is a conflicting handler registered
+   */
+  protected void registerHandlers(Map<String, Object> urlMap) throws BeansException {
+     // 为空，则仅打印日志
+      if (urlMap.isEmpty()) {
+  		logger.trace("No patterns in " + formatMappingName());
+     // 非空，则进行注册
+      } else {
+  		// 遍历 urlMap 数组，逐个注册处理器
+  		urlMap.forEach((url, handler) -> {
+  			// Prepend with slash if not already present.
+  			if (!url.startsWith("/")) { // 附加 / 前缀
+  				url = "/" + url;
+  			}
+  			// Remove whitespace from handler bean name.
+  			if (handler instanceof String) { // trim 方法，去掉头尾空格
+  				handler = ((String) handler).trim();
+  			}
+  			// 【核心代码】注册处理器
+  			registerHandler(url, handler);
+  		});
+  		// 打印日志
+  		if (logger.isDebugEnabled()) {
+  			List<String> patterns = new ArrayList<>();
+  			if (getRootHandler() != null) {
+  				patterns.add("/");
+  			}
+  			if (getDefaultHandler() != null) {
+  				patterns.add("/**");
+  			}
+  			patterns.addAll(getHandlerMap().keySet());
+  			logger.debug("Patterns " + patterns + " in " + formatMappingName());
+  		}
+  	}
+  }
+  ```
+
+# 4. AbstractDetectingUrlHandlerMapping
+
+`org.springframework.web.servlet.handler.AbstractDetectingUrlHandlerMapping` ，继承 AbstractUrlHandlerMapping 抽象类，自动探测的 UrlHandlerMapping 抽象实现类。
+
+## 4.1 构造方法
+
+```
+// AbstractDetectingUrlHandlerMapping.java
+
+/**
+ * 是否只扫描可访问的 Handler 们
+ */
+private boolean detectHandlersInAncestorContexts = false;
+
+/**
+ * Set whether to detect handler beans in ancestor ApplicationContexts.
+ * <p>Default is "false": Only handler beans in the current ApplicationContext
+ * will be detected, i.e. only in the context that this HandlerMapping itself
+ * is defined in (typically the current DispatcherServlet's context).
+ * <p>Switch this flag on to detect handler beans in ancestor contexts
+ * (typically the Spring root WebApplicationContext) as well.
+ */
+public void setDetectHandlersInAncestorContexts(boolean detectHandlersInAncestorContexts) {
+	this.detectHandlersInAncestorContexts = detectHandlersInAncestorContexts;
+}
+```
+
+## 4.2 initApplicationContext
+
+`#initApplicationContext()` 方法，进行初始化。代码如下：
+
+```
+// AbstractDetectingUrlHandlerMapping.java
+
+@Override
+public void initApplicationContext() throws ApplicationContextException {
+    // 调用父类方法，进行初始化
+    super.initApplicationContext();
+    // 自动探测处理器
+    detectHandlers();
+}
+```
+
+- 调用 `#detectHandlers()` 方法，自动探测处理器。代码如下：
+
+  ```
+  // AbstractDetectingUrlHandlerMapping.java
+  
+  /**
+   * Register all handlers found in the current ApplicationContext.
+   * <p>The actual URL determination for a handler is up to the concrete
+   * {@link #determineUrlsForHandler(String)} implementation. A bean for
+   * which no such URLs could be determined is simply not considered a handler.
+   * @throws org.springframework.beans.BeansException if the handler couldn't be registered
+   * @see #determineUrlsForHandler(String)
+   */
+  protected void detectHandlers() throws BeansException {
+  	// <1> 获得 Bean 的名字的数组
+  	ApplicationContext applicationContext = obtainApplicationContext();
+  	String[] beanNames = (this.detectHandlersInAncestorContexts ?
+  			BeanFactoryUtils.beanNamesForTypeIncludingAncestors(applicationContext, Object.class) :
+  			applicationContext.getBeanNamesForType(Object.class));
+  
+  	// Take any bean name that we can determine URLs for.
+  	// <2> 遍历 Bean ，逐个注册
+  	for (String beanName : beanNames) {
+  		// <2.1> 获得 Bean 对应的 URL 们
+  		String[] urls = determineUrlsForHandler(beanName);
+  		// <2.2> 如果 URL 们非空，则执行注册处理器
+  		if (!ObjectUtils.isEmpty(urls)) {
+  			// URL paths found: Let's consider it a handler.
+  			registerHandler(urls, beanName);
+  		}
+  	}
+  
+  	if ((logger.isDebugEnabled() && !getHandlerMap().isEmpty()) || logger.isTraceEnabled()) {
+  		logger.debug("Detected " + getHandlerMap().size() + " mappings in " + formatMappingName());
+  	}
+  }
+  ```
+
+  - `<1>` 处，获得 Bean 的名字的数组。
+
+  - `<2>` 处，遍历 Bean ，逐个注册。
+
+  - `<2.1>` 处，调用 `#determineUrlsForHandler(String beanName)` **抽象**方法，获得 Bean 对应的 URL 们。代码如下：
+
+    ```
+    // AbstractDetectingUrlHandlerMapping.java
+    
+    /**
+     * Determine the URLs for the given handler bean.
+     * @param beanName the name of the candidate bean
+     * @return the URLs determined for the bean, or an empty array if none
+     */
+    protected abstract String[] determineUrlsForHandler(String beanName);
+    ```
+
+    - 这是 AbstractDetectingUrlHandlerMapping 的关键方法。但是，AbstractDetectingUrlHandlerMapping 只是搭建了自动探测的骨架。具体的探索逻辑，还是交给子类处理。
+
+  - `<2.2>` 处，如果 URL 们非空，则调用父类 AbstractUrlHandlerMapping 的 `#registerHandler(String[] urlPaths, String beanName)` 方法，执行注册处理器。
+
+可能胖友看完这个类，一脸懵逼。不要方，继续来看 BeanNameUrlHandlerMapping 类。
+
+# 5. BeanNameUrlHandlerMapping
+
+`org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping` ，继承 AbstractDetectingUrlHandlerMapping 抽象类，基于 Bean 的名字来自动探测的 HandlerMapping 实现类。
+
+再看具体代码之前，我们先看看 [《HandlerMapping 和 BeanNameUrlHandlerMapping 的使用》](https://blog.csdn.net/qq_36074096/article/details/77423617) 。
+
+然后，再来看一眼代码，如下：
+
+```
+// BeanNameUrlHandlerMapping.java
+
+public class BeanNameUrlHandlerMapping extends AbstractDetectingUrlHandlerMapping {
+
+	/**
+	 * Checks name and aliases of the given bean for URLs, starting with "/".
+	 */
+	@Override
+	protected String[] determineUrlsForHandler(String beanName) {
+		List<String> urls = new ArrayList<>();
+		// 如果是以 / 开头，添加到 urls
+		if (beanName.startsWith("/")) {
+			urls.add(beanName);
+		}
+		// 获得 beanName 的别名们，如果以 / 开头，则添加到 urls
+		String[] aliases = obtainApplicationContext().getAliases(beanName);
+		for (String alias : aliases) {
+			if (alias.startsWith("/")) {
+				urls.add(alias);
+			}
+		}
+		// 返回
+		return StringUtils.toStringArray(urls);
+	}
+
+}
+```
+
+- 是不是一眼就看明白了？哈哈哈哈
+
+# 666. 彩蛋
+
+卧槽，好简单的一篇，开心~~~
+
+参考和推荐如下文章：
+
+- 韩路彪 [《看透 Spring MVC：源代码分析与实践》](https://item.jd.com/11807414.html) 的 [「12.2 AbstractUrlHandlerMapping 系列」](https://svip.iocoder.cn/Spring-MVC/HandlerMapping-4-AbstractUrlHandlerMapping/#) 小节
\ No newline at end of file
diff --git a/springmvc/14-Spring MVC 源码解析-HandlerAdapter 组件（一）之 HandlerAdapter.assets/01.png b/springmvc/14-Spring MVC 源码解析-HandlerAdapter 组件（一）之 HandlerAdapter.assets/01.png
new file mode 100644
index 0000000..f408155
Binary files /dev/null and b/springmvc/14-Spring MVC 源码解析-HandlerAdapter 组件（一）之 HandlerAdapter.assets/01.png differ
diff --git a/springmvc/14-Spring MVC 源码解析-HandlerAdapter 组件（一）之 HandlerAdapter.md b/springmvc/14-Spring MVC 源码解析-HandlerAdapter 组件（一）之 HandlerAdapter.md
new file mode 100644
index 0000000..3485bb7
--- /dev/null
+++ b/springmvc/14-Spring MVC 源码解析-HandlerAdapter 组件（一）之 HandlerAdapter.md	
@@ -0,0 +1,860 @@
+# 精尽 Spring MVC 源码解析 —— HandlerAdapter 组件（一）之 HandlerAdapter
+
+# 1. 概述
+
+本文，我们来分享 HandlerMapping 组件。在 [《精尽 Spring MVC 源码分析 —— 组件一览》](http://svip.iocoder.cn/Spring-MVC/Components-intro) 中，我们对它已经做了介绍：
+
+`org.springframework.web.servlet.HandlerAdapter` ，处理器适配器接口。代码如下：
+
+```
+// HandlerAdapter.java
+
+public interface HandlerAdapter {
+
+    /**
+     * 是否支持该处理器
+     */
+    boolean supports(Object handler);
+
+    /**
+     * 执行处理器，返回 ModelAndView 结果
+     */
+    @Nullable
+    ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception;
+
+    /**
+     * 返回请求的最新更新时间。
+     *
+     * 如果不支持该操作，则返回 -1 即可
+     */
+    long getLastModified(HttpServletRequest request, Object handler);
+
+}
+```
+
+- 因为，处理器 `handler` 的类型是 Object 类型，需要有一个调用者来实现 `handler` 是怎么被使用，怎么被执行。而 HandlerAdapter 的用途就在于此。可能如果接口名改成 HandlerInvoker ，笔者觉得会更好理解。
+
+# 2. HandlerAdapter
+
+HandlerAdapter 的子类比较多，整体类图如下：[![HandlerAdapter 类图](14-Spring MVC 源码解析-HandlerAdapter 组件（一）之 HandlerAdapter.assets/01.png)](http://static.iocoder.cn/images/Spring/2022-03-20/01.png)HandlerAdapter 类图
+
+- 左边的 AbstractHandlerMethodAdapter 和 RequestMappingHandlerAdapter 相对复杂
+- 右边的 SimpleServletHandlerAdapter、HttpRequestHandlerAdapter、SimpleControllerHandlerAdapter 相对简单
+
+那么，我们从~~难的~~简单的开始。哈哈哈哈。
+
+# 3. SimpleControllerHandlerAdapter
+
+`org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter` ，实现 HandlerAdapter 接口，基于 `org.springframework.web.servlet.mvc.Controller` 的 HandlerAdapter 实现类。代码如下：
+
+```
+// SimpleControllerHandlerAdapter.java
+
+public class SimpleControllerHandlerAdapter implements HandlerAdapter {
+
+    @Override
+    public boolean supports(Object handler) {
+        // <1> 判断是 Controller 类型
+        return (handler instanceof Controller);
+    }
+
+    @Override
+    @Nullable
+    public ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler)
+            throws Exception {
+        // <2> Controller 类型的调用
+        return ((Controller) handler).handleRequest(request, response);
+    }
+
+    @Override
+    public long getLastModified(HttpServletRequest request, Object handler) {
+        // 处理器实现了 LastModified 接口的情况下
+        if (handler instanceof LastModified) {
+            return ((LastModified) handler).getLastModified(request);
+        }
+        return -1L;
+    }
+
+}
+```
+
+- `<1>` 处，判断处理器 `handler` 是 Controller 类型。注意，不是 `@Controller` 注解。
+- `<2>` 处，调用 `Controller#handleRequest(HttpServletRequest request, HttpServletResponse response)` 方法，Controller 类型的调用。
+
+# 4. HttpRequestHandlerAdapter
+
+`org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter` ，实现 HandlerAdapter 接口，基于 `org.springframework.web.HttpRequestHandler` 的 HandlerAdapter 实现类。代码如下：
+
+```
+// HttpRequestHandlerAdapter.java
+
+public class HttpRequestHandlerAdapter implements HandlerAdapter {
+
+    @Override
+    public boolean supports(Object handler) {
+        // 判断是 HttpRequestHandler 类型
+        return (handler instanceof HttpRequestHandler);
+    }
+
+    @Override
+    @Nullable
+    public ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler)
+            throws Exception {
+        // HttpRequestHandler 类型的调用
+        ((HttpRequestHandler) handler).handleRequest(request, response);
+        return null;
+    }
+
+    @Override
+    public long getLastModified(HttpServletRequest request, Object handler) {
+        // 处理器实现了 LastModified 接口的情况下
+        if (handler instanceof LastModified) {
+            return ((LastModified) handler).getLastModified(request);
+        }
+        return -1L;
+    }
+
+}
+```
+
+- 和 [「3. SimpleControllerHandlerAdapter」](https://svip.iocoder.cn/Spring-MVC/HandlerAdapter-1-HandlerAdapter/#) 类似。
+
+# 5. SimpleServletHandlerAdapter
+
+`org.springframework.web.servlet.handler.SimpleServletHandlerAdapter` ，实现 HandlerAdapter 接口，基于 `javax.servlet.Servlet` 的 HandlerAdapter 实现类。代码如下：
+
+```
+// SimpleServletHandlerAdapter.java
+
+public class SimpleServletHandlerAdapter implements HandlerAdapter {
+
+    @Override
+    public boolean supports(Object handler) {
+        // 判断是 Servlet 类型
+        return (handler instanceof Servlet);
+    }
+
+    @Override
+    @Nullable
+    public ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler)
+            throws Exception {
+        // Servlet 类型的调用
+        ((Servlet) handler).service(request, response);
+        return null;
+    }
+
+    @Override
+    public long getLastModified(HttpServletRequest request, Object handler) {
+        return -1;
+    }
+
+}
+```
+
+# 6. AbstractHandlerMethodAdapter
+
+`org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter` ，实现 HandlerAdapter、Ordered 接口，继承 WebContentGenerator 抽象类，基于 `org.springframework.web.method.HandlerMethod` 的 HandlerMethodAdapter 抽象类。
+
+为什么要有这层抽象？让我们回过头看看 [《精尽 Spring MVC 源码解析 —— HandlerMapping 组件（三）之 AbstractHandlerMethodMapping》](http://svip.iocoder.cn/Spring-MVC/HandlerMapping-3-AbstractHandlerMethodMapping) 就会明白：
+
+- AbstractHandlerMethodMapping 对应 [「6. AbstractHandlerMethodAdapter」](https://svip.iocoder.cn/Spring-MVC/HandlerAdapter-1-HandlerAdapter/#) 。
+- RequestMappingInfoHandlerMapping 对应 [「7. RequestMappingHandlerAdapter」](https://svip.iocoder.cn/Spring-MVC/HandlerAdapter-1-HandlerAdapter/#) 。
+
+## 6.1 构造方法
+
+```
+// AbstractHandlerMethodAdapter.java
+
+private int order = Ordered.LOWEST_PRECEDENCE;
+
+public AbstractHandlerMethodAdapter() {
+    // no restriction of HTTP methods by default
+    // 调用 WebContentGenerator 类的构造方法
+    // 参数 restrictDefaultSupportedMethods 参数为 false ，表示不需要严格校验 HttpMethod
+    super(false);
+}
+```
+
+## 6.2 supports
+
+实现 `#supports(Object handler)` 方法，支持 HandlerMethod 类型的处理器。代码如下：
+
+```
+// AbstractHandlerMethodAdapter.java
+
+@Override
+public final boolean supports(Object handler) {
+	return (handler instanceof HandlerMethod && supportsInternal((HandlerMethod) handler));
+}
+```
+
+- 其中，`#supportsInternal(HandlerMethod handlerMethod)` 方法，由子类实现。代码如下：
+
+  ```
+  // AbstractHandlerMethodAdapter.java
+  
+  /**
+   * Given a handler method, return whether or not this adapter can support it.
+   * @param handlerMethod the handler method to check
+   * @return whether or not this adapter can adapt the given method
+   */
+  protected abstract boolean supportsInternal(HandlerMethod handlerMethod);
+  ```
+
+  - 关于 RequestMappingHandlerAdapter 类对该方法的实现，见 [「7.3 supportsInternal」](https://svip.iocoder.cn/Spring-MVC/HandlerAdapter-1-HandlerAdapter/#) 。
+
+## 6.3 handle
+
+实现 `#handle(HttpServletRequest request, HttpServletResponse response, Object handler)` 方法，处理器请求。代码如下：
+
+```
+// AbstractHandlerMethodAdapter.java
+
+@Override
+@Nullable
+public final ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler)
+		throws Exception {
+	return handleInternal(request, response, (HandlerMethod) handler);
+}
+
+/**
+ * Use the given handler method to handle the request.
+ * @param request current HTTP request
+ * @param response current HTTP response
+ * @param handlerMethod handler method to use. This object must have previously been passed to the
+ * {@link #supportsInternal(HandlerMethod)} this interface, which must have returned {@code true}.
+ * @return a ModelAndView object with the name of the view and the required model data,
+ * or {@code null} if the request has been handled directly
+ * @throws Exception in case of errors
+ */
+@Nullable
+protected abstract ModelAndView handleInternal(HttpServletRequest request,
+		HttpServletResponse response, HandlerMethod handlerMethod) throws Exception;
+```
+
+- 其中，`#handleInternal(...)` 抽象方法，将 `handler` 参数是 HandlerMethod 类型。关于 RequestMappingHandlerAdapter 类对该方法的实现，见 [「7.5 handleInternal」](https://svip.iocoder.cn/Spring-MVC/HandlerAdapter-1-HandlerAdapter/#) 。
+
+## 6.4 getLastModified
+
+`#getLastModified(HttpServletRequest request, Object handler)` 方法，获得最后更新时间。代码如下：
+
+```
+// AbstractHandlerMethodAdapter.java
+
+@Override
+public final long getLastModified(HttpServletRequest request, Object handler) {
+	return getLastModifiedInternal(request, (HandlerMethod) handler);
+}
+
+/**
+ * Same contract as for {@link javax.servlet.http.HttpServlet#getLastModified(HttpServletRequest)}.
+ * @param request current HTTP request
+ * @param handlerMethod handler method to use
+ * @return the lastModified value for the given handler
+ */
+protected abstract long getLastModifiedInternal(HttpServletRequest request, HandlerMethod handlerMethod);
+```
+
+- 套路同 [「6.3 handle」](https://svip.iocoder.cn/Spring-MVC/HandlerAdapter-1-HandlerAdapter/#) 。
+
+# 7. RequestMappingHandlerAdapter
+
+`org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter` ，实现 BeanFactoryAware、InitializingBean 接口，继承 AbstractHandlerMethodAdapter 抽象类，基于 `@RequestMapping` 注解的 HandlerMethod 的 HandlerMethodAdapter 实现类。
+
+## 7.1 构造方法
+
+```
+// RequestMappingHandlerAdapter.java
+
+/**
+ * MethodFilter that matches {@link InitBinder @InitBinder} methods.
+ */
+public static final MethodFilter INIT_BINDER_METHODS = method ->
+		AnnotatedElementUtils.hasAnnotation(method, InitBinder.class);
+
+/**
+ * MethodFilter that matches {@link ModelAttribute @ModelAttribute} methods.
+ */
+public static final MethodFilter MODEL_ATTRIBUTE_METHODS = method ->
+		(!AnnotatedElementUtils.hasAnnotation(method, RequestMapping.class) &&
+				AnnotatedElementUtils.hasAnnotation(method, ModelAttribute.class));
+
+@Nullable
+private List<HandlerMethodArgumentResolver> customArgumentResolvers;
+
+@Nullable
+private HandlerMethodArgumentResolverComposite argumentResolvers;
+
+@Nullable
+private HandlerMethodArgumentResolverComposite initBinderArgumentResolvers;
+
+@Nullable
+private List<HandlerMethodReturnValueHandler> customReturnValueHandlers;
+
+@Nullable
+private HandlerMethodReturnValueHandlerComposite returnValueHandlers;
+
+@Nullable
+private List<ModelAndViewResolver> modelAndViewResolvers;
+
+private ContentNegotiationManager contentNegotiationManager = new ContentNegotiationManager();
+
+private List<HttpMessageConverter<?>> messageConverters;
+
+private List<Object> requestResponseBodyAdvice = new ArrayList<>();
+
+@Nullable
+private WebBindingInitializer webBindingInitializer;
+
+private AsyncTaskExecutor taskExecutor = new SimpleAsyncTaskExecutor("MvcAsync");
+
+@Nullable
+private Long asyncRequestTimeout;
+
+private CallableProcessingInterceptor[] callableInterceptors = new CallableProcessingInterceptor[0];
+
+private DeferredResultProcessingInterceptor[] deferredResultInterceptors = new DeferredResultProcessingInterceptor[0];
+
+private ReactiveAdapterRegistry reactiveAdapterRegistry = ReactiveAdapterRegistry.getSharedInstance();
+
+private boolean ignoreDefaultModelOnRedirect = false;
+
+private int cacheSecondsForSessionAttributeHandlers = 0;
+
+/**
+ * 是否对相同 Session 加锁
+ */
+private boolean synchronizeOnSession = false;
+
+private SessionAttributeStore sessionAttributeStore = new DefaultSessionAttributeStore();
+
+private ParameterNameDiscoverer parameterNameDiscoverer = new DefaultParameterNameDiscoverer();
+
+@Nullable
+private ConfigurableBeanFactory beanFactory;
+
+// ========== 缓存 ==========
+
+private final Map<Class<?>, SessionAttributesHandler> sessionAttributesHandlerCache = new ConcurrentHashMap<>(64);
+
+private final Map<Class<?>, Set<Method>> initBinderCache = new ConcurrentHashMap<>(64);
+
+private final Map<ControllerAdviceBean, Set<Method>> initBinderAdviceCache = new LinkedHashMap<>();
+
+private final Map<Class<?>, Set<Method>> modelAttributeCache = new ConcurrentHashMap<>(64);
+
+private final Map<ControllerAdviceBean, Set<Method>> modelAttributeAdviceCache = new LinkedHashMap<>();
+	
+public RequestMappingHandlerAdapter() {
+	// 初始化 messageConverters
+	StringHttpMessageConverter stringHttpMessageConverter = new StringHttpMessageConverter();
+	stringHttpMessageConverter.setWriteAcceptCharset(false);  // see SPR-7316
+
+	this.messageConverters = new ArrayList<>(4);
+	this.messageConverters.add(new ByteArrayHttpMessageConverter());
+	this.messageConverters.add(stringHttpMessageConverter);
+	try {
+		this.messageConverters.add(new SourceHttpMessageConverter<>());
+	} catch (Error err) {
+		// Ignore when no TransformerFactory implementation is available
+	}
+	this.messageConverters.add(new AllEncompassingFormHttpMessageConverter());
+}
+```
+
+- 属性比较多，先不着急看，有个印象即可。
+- 另外，也是因为属性多，所以 RequestMappingHandlerAdapter 有大量的 setting 方法。
+
+## 7.2 afterPropertiesSet
+
+> 艿艿：这里我们会看到大量的 RequestMappingHandlerAdapter 的属性初始化。😈 当然，本小节还是不细讲。哈哈哈哈。
+
+`#afterPropertiesSet()` 方法，进一步初始化 RequestMappingHandlerAdapter 。代码如下：
+
+```
+// RequestMappingHandlerAdapter.java
+
+@Override
+public void afterPropertiesSet() {
+	// Do this first, it may add ResponseBody advice beans
+	// <1> 初始化 ControllerAdvice 相关
+	initControllerAdviceCache();
+
+	// <2> 初始化 argumentResolvers 属性
+	if (this.argumentResolvers == null) {
+		List<HandlerMethodArgumentResolver> resolvers = getDefaultArgumentResolvers();
+		this.argumentResolvers = new HandlerMethodArgumentResolverComposite().addResolvers(resolvers);
+	}
+	// <3> 初始化 initBinderArgumentResolvers 属性
+	if (this.initBinderArgumentResolvers == null) {
+		List<HandlerMethodArgumentResolver> resolvers = getDefaultInitBinderArgumentResolvers();
+		this.initBinderArgumentResolvers = new HandlerMethodArgumentResolverComposite().addResolvers(resolvers);
+	}
+	// <4> 初始化 returnValueHandlers 属性
+	if (this.returnValueHandlers == null) {
+		List<HandlerMethodReturnValueHandler> handlers = getDefaultReturnValueHandlers();
+		this.returnValueHandlers = new HandlerMethodReturnValueHandlerComposite().addHandlers(handlers);
+	}
+}
+```
+
+- `<1>` 处，调用 `#initControllerAdviceCache()` 方法，初始化 ControllerAdvice 相关。详细解析，见 [「7.2.1 initControllerAdviceCache」](https://svip.iocoder.cn/Spring-MVC/HandlerAdapter-1-HandlerAdapter/#) 。
+- `<2>` 处，初始化 `argumentResolvers` 属性。其中，`#getDefaultArgumentResolvers()` 方法，获得默认的 HandlerMethodArgumentResolver 数组。详细解析，见 [「7.2.2 getDefaultArgumentResolvers」](https://svip.iocoder.cn/Spring-MVC/HandlerAdapter-1-HandlerAdapter/#) 。
+- `<3>` 处，初始化 `initBinderArgumentResolvers` 属性。其中，`#getDefaultInitBinderArgumentResolvers()` 方法，获得默认的 HandlerMethodArgumentResolver 数组。详细解析，见 [「7.2.3 getDefaultInitBinderArgumentResolvers」](https://svip.iocoder.cn/Spring-MVC/HandlerAdapter-1-HandlerAdapter/#) 。
+- `<4>` 处，初始化 `returnValueHandlers` 属性。其中，`#getDefaultReturnValueHandlers()` 方法，获得默认的 HandlerMethodReturnValueHandler 数组。详细解析，见 [「7.2.4 getDefaultReturnValueHandlers」](https://svip.iocoder.cn/Spring-MVC/HandlerAdapter-1-HandlerAdapter/#) 。
+
+### 7.2.1 initControllerAdviceCache
+
+`#initControllerAdviceCache()` 方法，初始化 ControllerAdvice 相关。代码如下：
+
+```
+// RequestMappingHandlerAdapter.java
+
+private void initControllerAdviceCache() {
+	if (getApplicationContext() == null) {
+		return;
+	}
+
+	// <1> 扫描 @ControllerAdvice 注解的 Bean 们，并将进行排序
+	List<ControllerAdviceBean> adviceBeans = ControllerAdviceBean.findAnnotatedBeans(getApplicationContext());
+	AnnotationAwareOrderComparator.sort(adviceBeans);
+
+	List<Object> requestResponseBodyAdviceBeans = new ArrayList<>();
+
+	// <2> 遍历 ControllerAdviceBean 数组
+	for (ControllerAdviceBean adviceBean : adviceBeans) {
+		Class<?> beanType = adviceBean.getBeanType();
+		if (beanType == null) {
+			throw new IllegalStateException("Unresolvable type for ControllerAdviceBean: " + adviceBean);
+		}
+		// <2.1> 扫描有 @ModelAttribute ，无 @RequestMapping 注解的方法，添加到 modelAttributeAdviceCache 中
+		Set<Method> attrMethods = MethodIntrospector.selectMethods(beanType, MODEL_ATTRIBUTE_METHODS);
+		if (!attrMethods.isEmpty()) {
+			this.modelAttributeAdviceCache.put(adviceBean, attrMethods);
+		}
+		// <2.2> 扫描有 @InitBinder 注解的方法，添加到 initBinderAdviceCache 中
+		Set<Method> binderMethods = MethodIntrospector.selectMethods(beanType, INIT_BINDER_METHODS);
+		if (!binderMethods.isEmpty()) {
+			this.initBinderAdviceCache.put(adviceBean, binderMethods);
+		}
+		// <2.3> 如果是 RequestBodyAdvice 或 ResponseBodyAdvice 的子类，添加到 requestResponseBodyAdviceBeans 中
+		if (RequestBodyAdvice.class.isAssignableFrom(beanType)) {
+			requestResponseBodyAdviceBeans.add(adviceBean);
+		}
+		if (ResponseBodyAdvice.class.isAssignableFrom(beanType)) {
+			requestResponseBodyAdviceBeans.add(adviceBean);
+		}
+	}
+
+	// <2.3> 将 requestResponseBodyAdviceBeans 添加到 this.requestResponseBodyAdvice 属性种
+	if (!requestResponseBodyAdviceBeans.isEmpty()) {
+		this.requestResponseBodyAdvice.addAll(0, requestResponseBodyAdviceBeans);
+	}
+
+	// 打印日志
+	if (logger.isDebugEnabled()) {
+		int modelSize = this.modelAttributeAdviceCache.size();
+		int binderSize = this.initBinderAdviceCache.size();
+		int reqCount = getBodyAdviceCount(RequestBodyAdvice.class);
+		int resCount = getBodyAdviceCount(ResponseBodyAdvice.class);
+		if (modelSize == 0 && binderSize == 0 && reqCount == 0 && resCount == 0) {
+			logger.debug("ControllerAdvice beans: none");
+		} else {
+			logger.debug("ControllerAdvice beans: " + modelSize + " @ModelAttribute, " + binderSize +
+					" @InitBinder, " + reqCount + " RequestBodyAdvice, " + resCount + ", ResponseBodyAdvice");
+		}
+	}
+}
+```
+
+- `<1>` 处，调用 `ControllerAdviceBean#findAnnotatedBeans(ApplicationContext context)` 方法，扫描 `@ControllerAdvice` 注解的 Bean 们，并将进行排序。可能有胖友不熟悉这个注解，可以看看 [《Spring 3.2 新注解 @ControllerAdvice》](http://jinnianshilongnian.iteye.com/blog/1866350) 。
+- `<2>` 处，遍历 ControllerAdviceBean 数组。
+- `<2.1>` 处，扫描有 `@ModelAttribute` ，无 `@RequestMapping` 注解的方法，添加到 `modelAttributeAdviceCache` 中。
+- `<2.2>` 处，扫描有 `@InitBinder` 注解的方法，添加到 `initBinderAdviceCache` 中。
+- `<2.3>` 处，如果是 RequestBodyAdvice 或 ResponseBodyAdvice 的子类，添加到 `requestResponseBodyAdviceBeans` 中。
+
+### 7.2.2 getDefaultArgumentResolvers
+
+`#getDefaultArgumentResolvers()` 方法，获得默认的 HandlerMethodArgumentResolver 数组。见 [传送门](https://github.com/spring-projects/spring-framework/blob/master/spring-webmvc/src/main/java/org/springframework/web/servlet/mvc/method/annotation/RequestMappingHandlerAdapter.java#L637-L682) 。
+
+### 7.2.3 getDefaultInitBinderArgumentResolvers
+
+`#getDefaultInitBinderArgumentResolvers()` 方法，获得默认的 HandlerMethodArgumentResolver 数组。见 [传送门](https://github.com/spring-projects/spring-framework/blob/master/spring-webmvc/src/main/java/org/springframework/web/servlet/mvc/method/annotation/RequestMappingHandlerAdapter.java#L684-L715) 。
+
+### 7.2.4 getDefaultReturnValueHandlers
+
+`#getDefaultReturnValueHandlers()` 方法，获得默认的 HandlerMethodReturnValueHandler 数组。见 [传送门](https://github.com/spring-projects/spring-framework/blob/master/spring-webmvc/src/main/java/org/springframework/web/servlet/mvc/method/annotation/RequestMappingHandlerAdapter.java#L717-L761) 。
+
+## 7.3 supportsInternal
+
+实现 `#supportsInternal()` 接口，默认返回 `true` 。代码如下：
+
+```
+// RequestMappingHandlerAdapter.java
+
+/**
+ * Always return {@code true} since any method argument and return value
+ * type will be processed in some way. A method argument not recognized
+ * by any HandlerMethodArgumentResolver is interpreted as a request parameter
+ * if it is a simple type, or as a model attribute otherwise. A return value
+ * not recognized by any HandlerMethodReturnValueHandler will be interpreted
+ * as a model attribute.
+ */
+@Override
+protected boolean supportsInternal(HandlerMethod handlerMethod) {
+	return true;
+}
+```
+
+## 7.4 getLastModifiedInternal
+
+实现 `#getLastModifiedInternal()` 方法，默认返回 `-1` 。代码如下：
+
+```
+// RequestMappingHandlerAdapter.java
+
+/**
+ * This implementation always returns -1. An {@code @RequestMapping} method can
+ * calculate the lastModified value, call {@link WebRequest#checkNotModified(long)},
+ * and return {@code null} if the result of that call is {@code true}.
+ */
+@Override
+protected long getLastModifiedInternal(HttpServletRequest request, HandlerMethod handlerMethod) {
+	return -1;
+}
+```
+
+## 7.5 handleInternal
+
+实现 `#handleInternal(HttpServletRequest request, HttpServletResponse response, HandlerMethod handlerMethod)` 方法，处理请求。代码如下：
+
+```
+// RequestMappingHandlerAdapter.java
+
+@Override
+protected ModelAndView handleInternal(HttpServletRequest request, HttpServletResponse response, HandlerMethod handlerMethod) throws Exception {
+    // 处理结果 ModelAndView 对象
+    ModelAndView mav;
+
+    // <1> 校验请求
+    checkRequest(request);
+
+	// Execute invokeHandlerMethod in synchronized block if required.
+	// <2> 调用 HandlerMethod 方法
+	if (this.synchronizeOnSession) { // 同步相同 Session 的逻辑
+		HttpSession session = request.getSession(false);
+		if (session != null) {
+			Object mutex = WebUtils.getSessionMutex(session);
+			synchronized (mutex) {
+				mav = invokeHandlerMethod(request, response, handlerMethod);
+			}
+		} else {
+			// No HttpSession available -> no mutex necessary
+			mav = invokeHandlerMethod(request, response, handlerMethod);
+		}
+	} else {
+		// No synchronization on session demanded at all...
+		mav = invokeHandlerMethod(request, response, handlerMethod);
+	}
+
+	// <3> TODO WebContentGenerator
+	if (!response.containsHeader(HEADER_CACHE_CONTROL)) {
+		if (getSessionAttributesHandler(handlerMethod).hasSessionAttributes()) {
+			applyCacheSeconds(response, this.cacheSecondsForSessionAttributeHandlers);
+		} else {
+			prepareResponse(response);
+		}
+	}
+
+	return mav;
+}
+```
+
+- `<1>` 处，调用父类 WebContentGenerator 的 `#checkRequest(ttpServletRequest request)` 方法，校验请求是否合法。代码如下：
+
+  ```
+  // WebContentGenerator.java
+  
+  protected final void checkRequest(HttpServletRequest request) throws ServletException {
+  	// Check whether we should support the request method.
+  	String method = request.getMethod();
+  	if (this.supportedMethods != null && !this.supportedMethods.contains(method)) {
+  		throw new HttpRequestMethodNotSupportedException(method, this.supportedMethods);
+  	}
+  
+  	// Check whether a session is required.
+  	if (this.requireSession && request.getSession(false) == null) {
+  		throw new HttpSessionRequiredException("Pre-existing session required but none found");
+  	}
+  }
+  ```
+
+  - 主要是 **HttpMethod 的类型**和**是否有 Session** 的校验。
+
+- `<2>` 处，调用 `#invokeHandlerMethod(HttpServletRequest request, HttpServletResponse response, HandlerMethod handlerMethod)` 方法，调用 HandlerMethod 方法。详细解析，见 [「7.5.1 invokeHandlerMethod」](https://svip.iocoder.cn/Spring-MVC/HandlerAdapter-1-HandlerAdapter/#) 。
+
+  - 在 `<2>` 中，有一个通过 `synchronizeOnSession` 属性，控制是否**同步相同 Session** 的逻辑，还是蛮有趣的。其中 `WebUtils#getSessionMutex(session)` 方法，获得用来锁的对象。代码如下：
+
+    ```
+    // WebUtils.java
+    	
+    public static Object getSessionMutex(HttpSession session) {
+    	Assert.notNull(session, "Session must not be null");
+    	Object mutex = session.getAttribute(SESSION_MUTEX_ATTRIBUTE);
+    	if (mutex == null) {
+    		mutex = session;
+    	}
+    	return mutex;
+    }
+    ```
+
+    - 当然，因为锁是通过 `synchronized` 是 JVM 进程级，所以在分布式环境下，无法达到**同步相同 Session** 的功能。默认情况下，`synchronizeOnSession` 为 `false` 。
+
+- `<3>` 处，TODO 1015 WebContentGenerator
+
+### 7.5.1 invokeHandlerMethod
+
+`#invokeHandlerMethod(HttpServletRequest request, HttpServletResponse response, HandlerMethod handlerMethod)` 方法，调用 HandlerMethod 方法。代码如下：
+
+```
+// RequestMappingHandlerAdapter.java
+
+/**
+ * Invoke the {@link RequestMapping} handler method preparing a {@link ModelAndView}
+ * if view resolution is required.
+ * @since 4.2
+ * @see #createInvocableHandlerMethod(HandlerMethod)
+ */
+@Nullable
+protected ModelAndView invokeHandlerMethod(HttpServletRequest request,
+        HttpServletResponse response, HandlerMethod handlerMethod) throws Exception {
+
+    // <1> 创建 ServletWebRequest 对象
+    ServletWebRequest webRequest = new ServletWebRequest(request, response);
+    try {
+        // <2> 创建 WebDataBinderFactory 对象
+        WebDataBinderFactory binderFactory = getDataBinderFactory(handlerMethod);
+        // <3> 创建 ModelFactory 对象
+        ModelFactory modelFactory = getModelFactory(handlerMethod, binderFactory);
+
+        // <4> 创建 ServletInvocableHandlerMethod 对象，并设置其相关属性
+        ServletInvocableHandlerMethod invocableMethod = createInvocableHandlerMethod(handlerMethod);
+        if (this.argumentResolvers != null) {
+            invocableMethod.setHandlerMethodArgumentResolvers(this.argumentResolvers);
+        }
+        if (this.returnValueHandlers != null) {
+            invocableMethod.setHandlerMethodReturnValueHandlers(this.returnValueHandlers);
+        }
+        invocableMethod.setDataBinderFactory(binderFactory);
+        invocableMethod.setParameterNameDiscoverer(this.parameterNameDiscoverer);
+
+        // <5> 创建 ModelAndViewContainer 对象，并初始其相关属性
+        ModelAndViewContainer mavContainer = new ModelAndViewContainer();
+        mavContainer.addAllAttributes(RequestContextUtils.getInputFlashMap(request));
+        modelFactory.initModel(webRequest, mavContainer, invocableMethod);
+        mavContainer.setIgnoreDefaultModelOnRedirect(this.ignoreDefaultModelOnRedirect);
+
+        // <6> TODO 芋艿 1003 async
+        AsyncWebRequest asyncWebRequest = WebAsyncUtils.createAsyncWebRequest(request, response);
+        asyncWebRequest.setTimeout(this.asyncRequestTimeout);
+
+        // <7> TODO 芋艿 1003 async
+        WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager(request);
+        asyncManager.setTaskExecutor(this.taskExecutor);
+        asyncManager.setAsyncWebRequest(asyncWebRequest);
+        asyncManager.registerCallableInterceptors(this.callableInterceptors);
+        asyncManager.registerDeferredResultInterceptors(this.deferredResultInterceptors);
+
+        // <8> TODO 芋艿 1003 async
+        if (asyncManager.hasConcurrentResult()) {
+            Object result = asyncManager.getConcurrentResult();
+            mavContainer = (ModelAndViewContainer) asyncManager.getConcurrentResultContext()[0];
+            asyncManager.clearConcurrentResult();
+            LogFormatUtils.traceDebug(logger, traceOn -> {
+                String formatted = LogFormatUtils.formatValue(result, !traceOn);
+                return "Resume with async result [" + formatted + "]";
+            });
+            invocableMethod = invocableMethod.wrapConcurrentResult(result);
+        }
+
+        // <9> 执行调用
+        invocableMethod.invokeAndHandle(webRequest, mavContainer);
+
+        // <10> TODO 芋艿 1003 async
+        if (asyncManager.isConcurrentHandlingStarted()) {
+            return null;
+        }
+
+        // <11> 获得 ModelAndView 对象
+        return getModelAndView(mavContainer, modelFactory, webRequest);
+    } finally {
+        // <12> 标记请求完成
+        webRequest.requestCompleted();
+    }
+}
+```
+
+- 因为，Spring MVC 提供了大量的特性，所以涉及的组件会不少。😈 我们主要先梳理好主流程，所以涉及的组件，还是先不详细解析。我们的目的是，看到怎么调用 HandlerMethod 方法的，即调用 Controller 的 `@RequestMapping` 注解的方法。
+
+- `<1>` 处，创建 ServletWebRequest 对象。
+
+- `<2>` 处，调用 `#getDataBinderFactory(HandlerMethod handlerMethod)` 方法，创建 WebDataBinderFactory 对象。TODO 1016 WebDataBinderFactory
+
+- `<3>` 处，调用 `#getModelFactory(HandlerMethod handlerMethod, WebDataBinderFactory binderFactory)` 方法，创建 ModelFactory 对象。TODO 1017 ModelFactory
+
+- `<4>` 处，调用 `#createInvocableHandlerMethod(HandlerMethod handlerMethod)` 方法，创建 ServletInvocableHandlerMethod 对象，然后设置其属性。本文会对 ServletInvocableHandlerMethod 做简单的解析。当然，详细的解析，胖友可以后续看看 [《精尽 Spring MVC 源码解析 —— HandlerAdapter 组件（二）之 ServletInvocableHandlerMethod》](http://svip.iocoder.cn/Spring-MVC/HandlerAdapter-2-ServletInvocableHandlerMethod) 一文。
+
+- `<5>` 处，创建 ModelAndViewContainer 对象，并初始其相关属性。TODO 1019 ModelAndViewContainer
+
+- `<6>` 处，TODO 芋艿 1003 async
+
+- `<7>` 处，TODO 芋艿 1003 async
+
+- `<8>` 处，TODO 芋艿 1003 async
+
+- 【关键】`<9>` 处，调用 `ServletInvocableHandlerMethod#invokeAndHandle(ServletWebRequest webRequest, ModelAndViewContainer mavContainer, Object... providedArgs)` 方法，执行调用。代码如下：
+
+  ```
+  // ServletInvocableHandlerMethod.java
+  
+  /**
+   * Invoke the method and handle the return value through one of the
+   * configured {@link HandlerMethodReturnValueHandler HandlerMethodReturnValueHandlers}.
+   * @param webRequest the current request
+   * @param mavContainer the ModelAndViewContainer for this request
+   * @param providedArgs "given" arguments matched by type (not resolved)
+   */
+  public void invokeAndHandle(ServletWebRequest webRequest, ModelAndViewContainer mavContainer,
+  		Object... providedArgs) throws Exception {
+  	// <x> 执行调用
+  	Object returnValue = invokeForRequest(webRequest, mavContainer, providedArgs);
+  	// 设置响应状态码
+  	setResponseStatus(webRequest);
+  
+  	// 设置 ModelAndViewContainer 为请求已处理，返回
+  	if (returnValue == null) { // 返回 null
+  		if (isRequestNotModified(webRequest) || getResponseStatus() != null || mavContainer.isRequestHandled()) {
+  			mavContainer.setRequestHandled(true);
+  			return;
+  		}
+  	} else if (StringUtils.hasText(getResponseStatusReason())) { // 有 responseStatusReason
+  		mavContainer.setRequestHandled(true);
+  		return;
+  	}
+  
+  	// 设置 ModelAndViewContainer 为请求未处理
+  	mavContainer.setRequestHandled(false);
+  	Assert.state(this.returnValueHandlers != null, "No return value handlers");
+  	// 处理器返回值
+  	try {
+  		this.returnValueHandlers.handleReturnValue(
+  				returnValue, getReturnValueType(returnValue), mavContainer, webRequest);
+  	} catch (Exception ex) {
+  		if (logger.isTraceEnabled()) {
+  			logger.trace(formatErrorForReturnValue(returnValue), ex);
+  		}
+  		throw ex;
+  	}
+  }
+  ```
+
+  - 在 `<x>` 处，调用父类 InvocableHandlerMethod 的 `#invokeForRequest(NativeWebRequest request, @Nullable ModelAndViewContainer mavContainer, Object... providedArgs)` 方法，执行调用。代码如下：
+
+    ```
+    // InvocableHandlerMethod.java
+    
+    @Nullable
+    public Object invokeForRequest(NativeWebRequest request, @Nullable ModelAndViewContainer mavContainer,
+    		Object... providedArgs) throws Exception {
+    	// <y> 解析参数
+    	Object[] args = getMethodArgumentValues(request, mavContainer, providedArgs);
+    	if (logger.isTraceEnabled()) {
+    		logger.trace("Arguments: " + Arrays.toString(args));
+    	}
+    	// 执行调用
+    	return doInvoke(args);
+    }
+    
+    protected Object doInvoke(Object... args) throws Exception {
+    	// <z1> 设置方法为可访问
+    	ReflectionUtils.makeAccessible(getBridgedMethod());
+    	try {
+    	    // <z2> 执行调用
+    		return getBridgedMethod().invoke(getBean(), args);
+    	} catch (IllegalArgumentException ex) {
+    		assertTargetBean(getBridgedMethod(), getBean(), args);
+    		String text = (ex.getMessage() != null ? ex.getMessage() : "Illegal argument");
+    		throw new IllegalStateException(formatInvokeError(text, args), ex);
+    	} catch (InvocationTargetException ex) {
+    		// Unwrap for HandlerExceptionResolvers ...
+    		Throwable targetException = ex.getTargetException();
+    		if (targetException instanceof RuntimeException) {
+    			throw (RuntimeException) targetException;
+    		} else if (targetException instanceof Error) {
+    			throw (Error) targetException;
+    		} else if (targetException instanceof Exception) {
+    			throw (Exception) targetException;
+    		} else {
+    			throw new IllegalStateException(formatInvokeError("Invocation failure", args), targetException);
+    		}
+    	}
+    }
+    ```
+
+    - `<y>` 处，调用 `#getMethodArgumentValues(NativeWebRequest request, ModelAndViewContainer mavContainer, Object... providedArgs)` 方法，解析方法的参数值们。
+    - `<z1>` 处，设置方法为可访问。
+    - `<z2>` 处，反射调用 `@RequestMapping` 注解的方法。😈 有一点忘记提了，InvocableHandlerMethod 是 HandlerMethod 的子类，所以通过 HandlerMethod 的 `#getBridgedMethod()` 方法，可以获得对应的 `@RequestMapping` 注解的方法。
+
+- `<10>` 处，TODO 芋艿 1003 async
+
+- `<11>` 处，调用 `#getModelAndView(ModelAndViewContainer mavContainer, ModelFactory modelFactory, NativeWebRequest webRequest)` 方法，获得 ModelAndView 对象。代码如下：
+
+  ```
+  // RequestMappingHandlerAdapter.java
+  
+  @Nullable
+  private ModelAndView getModelAndView(ModelAndViewContainer mavContainer,
+          ModelFactory modelFactory, NativeWebRequest webRequest) throws Exception {
+      // <1> TODO 1017 ModelFactory
+      modelFactory.updateModel(webRequest, mavContainer);
+  
+      // 情况一，如果 mavContainer 已处理，则返回“空”的 ModelAndView 对象。
+      if (mavContainer.isRequestHandled()) {
+          return null;
+      }
+  
+      // 情况二，如果 mavContainer 未处，则基于 `mavContainer` 生成 ModelAndView 对象
+      ModelMap model = mavContainer.getModel();
+      // 创建 ModelAndView 对象，并设置相关属性
+      ModelAndView mav = new ModelAndView(mavContainer.getViewName(), model, mavContainer.getStatus());
+      if (!mavContainer.isViewReference()) {
+          mav.setView((View) mavContainer.getView());
+      }
+      // TODO 1004 flashMapManager
+      if (model instanceof RedirectAttributes) {
+          Map<String, ?> flashAttributes = ((RedirectAttributes) model).getFlashAttributes();
+          HttpServletRequest request = webRequest.getNativeRequest(HttpServletRequest.class);
+          if (request != null) {
+              RequestContextUtils.getOutputFlashMap(request).putAll(flashAttributes);
+          }
+      }
+      return mav;
+  }
+  ```
+
+  - `<1>` 处，TODO 1017 ModelFactory
+  - `<2>` 处，情况一，如果 mavContainer 已处理，则返回“空”的 ModelAndView 对象。
+  - `<3>` 处，情况二，如果 mavContainer 未处，则基于 `mavContainer` 生成 ModelAndView 对象。
+  - 😈 这个方法，涉及后续文章的内容，胖友可以先跳过，后续在回来理解。
+
+- `<12>` 处，标记请求完成。
+
+# 666. 彩蛋
+
+😈 头疼，HandlerAdapter 的处理过程，涉及的组件较多。后续的文章，我们慢慢一个一个梳理。
+
+还是那句老话，先整体，后局部，一点一点慢慢来。
+
+参考和推荐如下文章：
+
+- 韩路彪 [《看透 Spring MVC：源代码分析与实践》](https://item.jd.com/11807414.html) 的 [「第13章 HandlerAdapter」](https://svip.iocoder.cn/Spring-MVC/HandlerAdapter-1-HandlerAdapter/#) 小节
\ No newline at end of file
diff --git a/springmvc/15-Spring MVC 源码解析-HandlerAdapter 组件（二）之 ServletInvocableHandlerMethod.assets/01.png b/springmvc/15-Spring MVC 源码解析-HandlerAdapter 组件（二）之 ServletInvocableHandlerMethod.assets/01.png
new file mode 100644
index 0000000..5b3ad10
Binary files /dev/null and b/springmvc/15-Spring MVC 源码解析-HandlerAdapter 组件（二）之 ServletInvocableHandlerMethod.assets/01.png differ
diff --git a/springmvc/15-Spring MVC 源码解析-HandlerAdapter 组件（二）之 ServletInvocableHandlerMethod.md b/springmvc/15-Spring MVC 源码解析-HandlerAdapter 组件（二）之 ServletInvocableHandlerMethod.md
new file mode 100644
index 0000000..4f95e5b
--- /dev/null
+++ b/springmvc/15-Spring MVC 源码解析-HandlerAdapter 组件（二）之 ServletInvocableHandlerMethod.md	
@@ -0,0 +1,328 @@
+# 精尽 Spring MVC 源码解析 —— HandlerAdapter 组件（二）之 ServletInvocableHandlerMethod
+
+# 1. 概述
+
+本文接 [《精尽 Spring MVC 源码解析 —— HandlerAdapter 组件（一）之 HandlerAdapter》](http://svip.iocoder.cn/Spring-MVC/HandlerAdapter-1-HandlerAdapter) 一文，我们“**再次**”来分享 ServletInvocableHandlerMethod 组件。虽然 😈 WebDataBinderFactory、ModelFactory 等等类，还处于 TODO 状态，但是，我们还是非常有必要，对 ServletInvocableHandlerMethod 再来一波分析。
+
+> 艿艿：HandlerAdapter 真的是 Spring MVC 九大组件里，最最最复杂的，没有之一。
+
+# 2. 类图
+
+ServletInvocableHandlerMethod 的整体类图如下：
+
+[![HandlerAdapter 类图](15-Spring MVC 源码解析-HandlerAdapter 组件（二）之 ServletInvocableHandlerMethod.assets/01.png)](http://static.iocoder.cn/images/Spring/2022-03-23/01.png)HandlerAdapter 类图
+
+我们来逐个解析。
+
+# 3. HandlerMethod
+
+`org.springframework.web.method.HandlerMethod` ，处理器的方法的封装对象。
+
+在 [《精尽 Spring MVC 源码解析 —— HandlerMapping 组件（三）之 AbstractHandlerMethodMapping》](http://svip.iocoder.cn/Spring-MVC/HandlerMapping-3-AbstractHandlerMethodMapping) 的 [「3.3.1 HandlerMethod」](https://svip.iocoder.cn/Spring-MVC/HandlerAdapter-2-ServletInvocableHandlerMethod/#) 中，我们已经做过详细解析。
+
+# 4. InvocableHandlerMethod
+
+`org.springframework.web.method.support.InvocableHandlerMethod` ，继承 HandlerMethod 类，可 invoke 调用的 HandlerMethod 实现类。
+
+😈 也就是说，HandlerMethod 只提供了处理器的方法的基本信息，不提供调用逻辑。
+
+## 4.1 构造方法
+
+```
+// InvocableHandlerMethod.java
+
+@Nullable
+private WebDataBinderFactory dataBinderFactory;
+
+private HandlerMethodArgumentResolverComposite argumentResolvers = new HandlerMethodArgumentResolverComposite();
+
+private ParameterNameDiscoverer parameterNameDiscoverer = new DefaultParameterNameDiscoverer();
+
+public InvocableHandlerMethod(HandlerMethod handlerMethod) {
+	super(handlerMethod);
+}
+
+public InvocableHandlerMethod(Object bean, Method method) {
+	super(bean, method);
+}
+
+public InvocableHandlerMethod(Object bean, String methodName, Class<?>... parameterTypes)
+		throws NoSuchMethodException {
+	super(bean, methodName, parameterTypes);
+}
+```
+
+- `dataBinderFactory`、`argumentResolvers`、`parameterNameDiscoverer` 参数，是通过 setting 方法，进行设置。
+
+## 4.2 invokeForRequest
+
+`#invokeForRequest(NativeWebRequest request, ModelAndViewContainer mavContainer, Object... providedArgs)` 方法，执行请求。代码如下：
+
+```
+// InvocableHandlerMethod.java
+
+/**
+ * Invoke the method after resolving its argument values in the context of the given request.
+ * <p>Argument values are commonly resolved through {@link HandlerMethodArgumentResolver HandlerMethodArgumentResolvers}.
+ * The {@code providedArgs} parameter however may supply argument values to be used directly,
+ * i.e. without argument resolution. Examples of provided argument values include a
+ * {@link WebDataBinder}, a {@link SessionStatus}, or a thrown exception instance.
+ * Provided argument values are checked before argument resolvers.
+ * @param request the current request
+ * @param mavContainer the ModelAndViewContainer for this request
+ * @param providedArgs "given" arguments matched by type, not resolved
+ * @return the raw value returned by the invoked method
+ * @throws Exception raised if no suitable argument resolver can be found,
+ * or if the method raised an exception
+ */
+@Nullable
+public Object invokeForRequest(NativeWebRequest request, @Nullable ModelAndViewContainer mavContainer,
+		Object... providedArgs) throws Exception {
+	// <1> 解析参数
+	Object[] args = getMethodArgumentValues(request, mavContainer, providedArgs);
+	if (logger.isTraceEnabled()) {
+		logger.trace("Arguments: " + Arrays.toString(args));
+	}
+	// <2> 执行调用
+	return doInvoke(args);
+}
+```
+
+- `<1>` 处，调用 `#getMethodArgumentValues(NativeWebRequest request, ModelAndViewContainer mavContainer, Object... providedArgs)` 方法，解析方法的参数们。代码如下：
+
+  ```
+  // InvocableHandlerMethod.java
+  
+  private Object[] getMethodArgumentValues(NativeWebRequest request, @Nullable ModelAndViewContainer mavContainer,
+          Object... providedArgs) throws Exception {
+      // 方法的参数信息的数组
+      MethodParameter[] parameters = getMethodParameters();
+      // 解析后的参数结果数组
+      Object[] args = new Object[parameters.length];
+  
+      // 遍历，开始解析
+      for (int i = 0; i < parameters.length; i++) {
+          // 获得当前遍历的 MethodParameter 对象，并设置 parameterNameDiscoverer 到其中
+          MethodParameter parameter = parameters[i];
+          parameter.initParameterNameDiscovery(this.parameterNameDiscoverer);
+          // <1> 先从 providedArgs 中获得参数。如果获得到，则进入下一个参数的解析
+          args[i] = resolveProvidedArgument(parameter, providedArgs);
+          if (args[i] != null) {
+              continue;
+          }
+          // <2> 判断 argumentResolvers 是否支持当前的参数解析
+          if (this.argumentResolvers.supportsParameter(parameter)) {
+              try {
+                  // 执行解析。解析成功后，则进入下一个参数的解析
+                  args[i] = this.argumentResolvers.resolveArgument(
+                          parameter, mavContainer, request, this.dataBinderFactory);
+                  continue;
+              } catch (Exception ex) {
+                  // 解析失败，打印日志，并抛出异常
+                  // Leave stack trace for later, e.g. AbstractHandlerExceptionResolver
+                  if (logger.isDebugEnabled()) {
+                      String message = ex.getMessage();
+                      if (message != null && !message.contains(parameter.getExecutable().toGenericString())) {
+                          logger.debug(formatArgumentError(parameter, message));
+                      }
+                  }
+                  throw ex;
+              }
+          }
+          // 解析失败，抛出 IllegalStateException 异常
+          if (args[i] == null) {
+              throw new IllegalStateException(formatArgumentError(parameter, "No suitable resolver"));
+          }
+      }
+  
+      // 返回结果
+      return args;
+  }
+  ```
+
+  - 总体的逻辑，比较简单，胖友跟着注释过一遍，就不啰嗦啦。
+  - `<1>` 处，先从 `providedArgs` 中获得参数。如果获得到，则进入下一个参数的解析。默认情况下，`providedArgs` 参数不会传递，所以可以暂时先忽略。保证核心逻辑的理解。
+  - `<2>` 处，判断 `argumentResolvers` 是否支持当前的参数解析。如果支持，则进行解析。关于 HandlerMethodArgumentResolverComposite 的详细解析，见 [《精尽 Spring MVC 源码解析 —— HandlerAdapter 组件（三）之 HandlerMethodArgumentResolver》](http://svip.iocoder.cn/Spring-MVC/HandlerAdapter-3-HandlerMethodArgumentResolver) 。
+
+- `<2>` 方法，调用 `#doInvoke(Object... args)` 方法，执行调用。代码如下：
+
+  ```
+  // InvocableHandlerMethod.java
+  
+  protected Object doInvoke(Object... args) throws Exception {
+  	// 设置方法为可访问
+  	ReflectionUtils.makeAccessible(getBridgedMethod());
+  	try {
+  		// 执行调用
+  		return getBridgedMethod().invoke(getBean(), args);
+  	} catch (IllegalArgumentException ex) {
+  		assertTargetBean(getBridgedMethod(), getBean(), args);
+  		String text = (ex.getMessage() != null ? ex.getMessage() : "Illegal argument");
+  		throw new IllegalStateException(formatInvokeError(text, args), ex);
+  	} catch (InvocationTargetException ex) {
+  		// Unwrap for HandlerExceptionResolvers ...
+  		Throwable targetException = ex.getTargetException();
+  		if (targetException instanceof RuntimeException) {
+  			throw (RuntimeException) targetException;
+  		} else if (targetException instanceof Error) {
+  			throw (Error) targetException;
+  		} else if (targetException instanceof Exception) {
+  			throw (Exception) targetException;
+  		} else {
+  			throw new IllegalStateException(formatInvokeError("Invocation failure", args), targetException);
+  		}
+  	}
+  }
+  ```
+
+  - 通过反射方法，调用对应的方法。那么，为什么是 Bridged Method 呢？感兴趣的胖友，可以看看 [《Bridge Method (桥接方法)》](http://berdy.iteye.com/blog/810488) 文章。有趣~
+
+# 5. ServletInvocableHandlerMethod
+
+`org.springframework.web.servlet.mvc.method.annotation。ServletInvocableHandlerMethod` ，继承 InvocableHandlerMethod 类，考虑 Servlet 的 InvocableHandlerMethod 实现类。😈 貌似这样翻译也很奇怪，直接开始看代码吧。
+
+```
+// ServletInvocableHandlerMethod.java
+
+/**
+ * Extends {@link InvocableHandlerMethod} with the ability to handle return
+ * values through a registered {@link HandlerMethodReturnValueHandler} and
+ * also supports setting the response status based on a method-level
+ * {@code @ResponseStatus} annotation.
+ *
+ * <p>A {@code null} return value (including void) may be interpreted as the
+ * end of request processing in combination with a {@code @ResponseStatus}
+ * annotation, a not-modified check condition
+ * (see {@link ServletWebRequest#checkNotModified(long)}), or
+ * a method argument that provides access to the response stream.
+ *
+ * @author Rossen Stoyanchev
+ * @author Juergen Hoeller
+ * @since 3.1
+ */
+```
+
+## 5.1 构造方法
+
+```
+// ServletInvocableHandlerMethod.java
+
+/**
+ * 返回结果处理器
+ */
+@Nullable
+private HandlerMethodReturnValueHandlerComposite returnValueHandlers;
+
+public ServletInvocableHandlerMethod(Object handler, Method method) {
+	super(handler, method);
+}
+
+public ServletInvocableHandlerMethod(HandlerMethod handlerMethod) {
+	super(handlerMethod);
+}
+```
+
+- `returnValueHandlers` 属性的设置，通过 setting 方法。
+
+## 5.2 invokeAndHandle
+
+`#invokeAndHandle(ServletWebRequest webRequest, ModelAndViewContainer mavContainer, Object... providedArgs)` 方法，请求调用，**并处理返回结果**。代码如下：
+
+```
+// ServletInvocableHandlerMethod.java
+
+/**
+ * Invoke the method and handle the return value through one of the
+ * configured {@link HandlerMethodReturnValueHandler HandlerMethodReturnValueHandlers}.
+ * @param webRequest the current request
+ * @param mavContainer the ModelAndViewContainer for this request
+ * @param providedArgs "given" arguments matched by type (not resolved)
+ */
+public void invokeAndHandle(ServletWebRequest webRequest, ModelAndViewContainer mavContainer,
+		Object... providedArgs) throws Exception {
+	// <1> 执行调用
+	Object returnValue = invokeForRequest(webRequest, mavContainer, providedArgs);
+	// <2> 设置响应状态码
+	setResponseStatus(webRequest);
+
+	// <3> 设置 ModelAndViewContainer 为请求已处理，返回
+	if (returnValue == null) { // 返回 null
+		if (isRequestNotModified(webRequest) || getResponseStatus() != null || mavContainer.isRequestHandled()) {
+			mavContainer.setRequestHandled(true);
+			return;
+		}
+	} else if (StringUtils.hasText(getResponseStatusReason())) { // 有 responseStatusReason
+		mavContainer.setRequestHandled(true);
+		return;
+	}
+
+	// <4> 设置 ModelAndViewContainer 为请求未处理
+	mavContainer.setRequestHandled(false);
+	Assert.state(this.returnValueHandlers != null, "No return value handlers");
+	// <5> 处理器返回值
+	try {
+		this.returnValueHandlers.handleReturnValue(
+				returnValue, getReturnValueType(returnValue), mavContainer, webRequest);
+	} catch (Exception ex) {
+		if (logger.isTraceEnabled()) {
+			logger.trace(formatErrorForReturnValue(returnValue), ex);
+		}
+		throw ex;
+	}
+}
+```
+
+- `<1>` 处，调用父 InvocableHandlerMethod 类的 `#invokeForRequest(NativeWebRequest request, ModelAndViewContainer mavContainer, Object... providedArgs)` 方法，执行调用。在 [「4.2 invokeForRequest」](https://svip.iocoder.cn/Spring-MVC/HandlerAdapter-2-ServletInvocableHandlerMethod/#) 中，已经详细解析。
+
+- `<2>` 处，调用 `#setResponseStatus(ServletWebRequest webRequest)` 设置响应的状态码。代码如下：
+
+  ```
+  // ServletInvocableHandlerMethod.java
+  
+  /**
+   * Set the response status according to the {@link ResponseStatus} annotation.
+   */
+  private void setResponseStatus(ServletWebRequest webRequest) throws IOException {
+      // 获得状态码。
+      // 此处，想要非空，需要通过 @ResponseStatus 注解方法
+      HttpStatus status = getResponseStatus();
+  	if (status == null) { // 若为空，则返回
+  		return;
+  	}
+  
+  	// 设置响应的状态码
+  	HttpServletResponse response = webRequest.getResponse();
+  	if (response != null) {
+  		String reason = getResponseStatusReason();
+  		if (StringUtils.hasText(reason)) { // 有 reason ，则设置 status + reason
+  			response.sendError(status.value(), reason);
+  		} else { // 无 reason ，则仅设置 status
+  			response.setStatus(status.value());
+  		}
+  	}
+  
+  	// To be picked up by RedirectView
+  	// 为了 RedirectView ，所以进行设置
+  	webRequest.getRequest().setAttribute(View.RESPONSE_STATUS_ATTRIBUTE, status);
+  }
+  ```
+
+  - 代码比较简单，胖友自己瞅瞅。主要和 `@ResponseStatus` 注解有关。😈 估计，用过的胖友不太多，哈哈哈哈。艿艿也基本没用过。
+
+- `<3>` 处，设置 ModelAndViewContainer 为请求已处理，返回。具体的逻辑，胖友可以简单看看即可。因为，实际情况下，我们很少使用 `@ResponseStatus` 注解。
+
+- `<4>` 处，设置 ModelAndViewContainer 为请求未处理。
+
+- `<5>` 处，调用 `HandlerMethodReturnValueHandlerComposite#handleReturnValue(Object returnValue, MethodParameter returnType, ModelAndViewContainer mavContainer, NativeWebRequest webRequest)` 方法，处理返回值。详细解析，见 [《精尽 Spring MVC 源码解析 —— HandlerAdapter 组件（四）之 HandlerMethodArgumentResolver》](http://svip.iocoder.cn/Spring-MVC/HandlerAdapter-4-HandlerMethodReturnValueHandler) 。
+
+# 6. ConcurrentResultHandlerMethod
+
+TODO 1003 ASYNC 相关
+
+# 666. 彩蛋
+
+仔细一琢磨，还是先暂时本文。酱紫，就显得艿艿写了好多篇，胖友看完了好多篇。是不是很棒，哈哈哈哈。
+
+参考和推荐如下文章：
+
+- 韩路彪 [《看透 Spring MVC：源代码分析与实践》](https://item.jd.com/11807414.html) 的 [「12.3 AbstractHandlerMethodMapping 系列」](https://svip.iocoder.cn/Spring-MVC/HandlerAdapter-2-ServletInvocableHandlerMethod/#) 小节
\ No newline at end of file
diff --git a/springmvc/16-Spring MVC 源码解析-HandlerAdapter 组件（三）之 HandlerMethodArgumentResolver.assets/01.png b/springmvc/16-Spring MVC 源码解析-HandlerAdapter 组件（三）之 HandlerMethodArgumentResolver.assets/01.png
new file mode 100644
index 0000000..039d7e7
Binary files /dev/null and b/springmvc/16-Spring MVC 源码解析-HandlerAdapter 组件（三）之 HandlerMethodArgumentResolver.assets/01.png differ
diff --git a/springmvc/16-Spring MVC 源码解析-HandlerAdapter 组件（三）之 HandlerMethodArgumentResolver.assets/02.png b/springmvc/16-Spring MVC 源码解析-HandlerAdapter 组件（三）之 HandlerMethodArgumentResolver.assets/02.png
new file mode 100644
index 0000000..8249d7b
Binary files /dev/null and b/springmvc/16-Spring MVC 源码解析-HandlerAdapter 组件（三）之 HandlerMethodArgumentResolver.assets/02.png differ
diff --git a/springmvc/16-Spring MVC 源码解析-HandlerAdapter 组件（三）之 HandlerMethodArgumentResolver.md b/springmvc/16-Spring MVC 源码解析-HandlerAdapter 组件（三）之 HandlerMethodArgumentResolver.md
new file mode 100644
index 0000000..3dc1acb
--- /dev/null
+++ b/springmvc/16-Spring MVC 源码解析-HandlerAdapter 组件（三）之 HandlerMethodArgumentResolver.md	
@@ -0,0 +1,901 @@
+# 精尽 Spring MVC 源码解析 —— HandlerAdapter 组件（三）之 HandlerMethodArgumentResolver
+
+# 1. 概述
+
+本文接 [《精尽 Spring MVC 源码解析 —— HandlerAdapter 组件（二）之 ServletInvocableHandlerMethod》](http://svip.iocoder.cn/Spring-MVC/HandlerAdapter-2-ServletInvocableHandlerMethod) 一文，我们来分享 HandlerMethodArgumentResolver ，HandlerMethod 的参数解析器接口。代码如下：
+
+```
+// HandlerMethodArgumentResolver.java
+
+// HandlerMethodArgumentResolver.java
+
+public interface HandlerMethodArgumentResolver {
+
+    /**
+     * 是否支持解析该参数
+     *
+     * Whether the given {@linkplain MethodParameter method parameter} is
+     * supported by this resolver.
+     * @param parameter the method parameter to check
+     * @return {@code true} if this resolver supports the supplied parameter;
+     * {@code false} otherwise
+     */
+    boolean supportsParameter(MethodParameter parameter);
+
+    /**
+     * 解析该参数
+     *
+     * Resolves a method parameter into an argument value from a given request.
+     * A {@link ModelAndViewContainer} provides access to the model for the
+     * request. A {@link WebDataBinderFactory} provides a way to create
+     * a {@link WebDataBinder} instance when needed for data binding and
+     * type conversion purposes.
+     * @param parameter the method parameter to resolve. This parameter must
+     * have previously been passed to {@link #supportsParameter} which must
+     * have returned {@code true}.
+     * @param mavContainer the ModelAndViewContainer for the current request
+     * @param webRequest the current request
+     * @param binderFactory a factory for creating {@link WebDataBinder} instances
+     * @return the resolved argument value, or {@code null} if not resolvable
+     * @throws Exception in case of errors with the preparation of argument values
+     */
+    @Nullable
+    Object resolveArgument(MethodParameter parameter, @Nullable ModelAndViewContainer mavContainer,
+            NativeWebRequest webRequest, @Nullable WebDataBinderFactory binderFactory) throws Exception;
+
+}
+```
+
+- 两个方法，分别是是否支持解析该参数、以及解析该参数。
+
+# 2. 类图
+
+HandlerMethodArgumentResolver 的实现类非常多，如下图所示：[![HandlerAdapter 类图](16-Spring MVC 源码解析-HandlerAdapter 组件（三）之 HandlerMethodArgumentResolver.assets/01.png)](http://static.iocoder.cn/images/Spring/2022-03-26/01.png)HandlerAdapter 类图
+
+因为实在太大，胖友可以点击 [传送](http://static.iocoder.cn/images/Spring/2022-03-26/01.png) 查看。
+
+下面，我要说什么化，想必熟悉我的胖友已经知道了，我们就分析几个 HandlerMethodArgumentResolver 实现类。哈哈哈哈
+
+# 3. HandlerMethodArgumentResolverComposite
+
+`org.springframework.web.method.support.HandlerMethodArgumentResolverComposite` ，实现 HandlerMethodArgumentResolver 接口，复合的 HandlerMethodArgumentResolver 实现类。
+
+## 3.1 构造方法
+
+```
+// HandlerMethodArgumentResolverComposite.java
+
+/**
+ * HandlerMethodArgumentResolver 数组
+ */
+private final List<HandlerMethodArgumentResolver> argumentResolvers = new LinkedList<>();
+
+/**
+ * MethodParameter 与 HandlerMethodArgumentResolver 的映射，作为缓存。
+ */
+private final Map<MethodParameter, HandlerMethodArgumentResolver> argumentResolverCache =
+		new ConcurrentHashMap<>(256);
+```
+
+- `argumentResolvers` 属性，HandlerMethodArgumentResolver 数组。这就是 Composite 复合~
+- `argumentResolverCache` 属性，MethodParameter 与 HandlerMethodArgumentResolver 的映射，作为**缓存**。因为，MethodParameter 是需要从 `argumentResolvers` 遍历到适合其的解析器，通过缓存后，无需再次重复遍历。
+
+另外，在 [《精尽 Spring MVC 源码解析 —— HandlerAdapter 组件（一）之 HandlerAdapter》](http://svip.iocoder.cn/Spring-MVC/HandlerAdapter-1-HandlerAdapter) 的 [「7.2.2 getDefaultArgumentResolvers」](https://svip.iocoder.cn/Spring-MVC/HandlerAdapter-3-HandlerMethodArgumentResolver/#) 中，我们已经看到了，HandlerMethodArgumentResolverComposite 默认复合的所有 HandlerMethodArgumentResolver 对象。😈 忘记的胖友，可以点下 [传送门](https://github.com/spring-projects/spring-framework/blob/master/spring-webmvc/src/main/java/org/springframework/web/servlet/mvc/method/annotation/RequestMappingHandlerAdapter.java#L637-L682) 再瞅瞅。
+
+## 3.2 getArgumentResolver
+
+`#getArgumentResolver(MethodParameter parameter)` 方法，获得方法参数对应的 HandlerMethodArgumentResolver 对象。代码如下：
+
+```
+// HandlerMethodArgumentResolverComposite.java
+
+/**
+ * Find a registered {@link HandlerMethodArgumentResolver} that supports the given method parameter.
+ */
+@Nullable
+private HandlerMethodArgumentResolver getArgumentResolver(MethodParameter parameter) {
+    // 优先从 argumentResolverCache 缓存中，获得 parameter 对应的 HandlerMethodArgumentResolver 对象
+    HandlerMethodArgumentResolver result = this.argumentResolverCache.get(parameter);
+    if (result == null) {
+        // 获得不到，则遍历 argumentResolvers 数组，逐个判断是否支持。
+        for (HandlerMethodArgumentResolver methodArgumentResolver : this.argumentResolvers) {
+            // 如果支持，则添加到 argumentResolverCache 缓存中，并返回
+            if (methodArgumentResolver.supportsParameter(parameter)) {
+                result = methodArgumentResolver;
+                this.argumentResolverCache.put(parameter, result);
+                break;
+            }
+        }
+    }
+    return result;
+}
+```
+
+## 3.3 supportsParameter
+
+实现 `#supportsParameter(MethodParameter parameter)` 方法，如果能获得到对应的 HandlerMethodArgumentResolver 处理器，则说明支持。代码如下：
+
+```
+// HandlerMethodArgumentResolverComposite.java
+
+@Override
+public boolean supportsParameter(MethodParameter parameter) {
+	return (getArgumentResolver(parameter) != null);
+}
+```
+
+## 3.4 resolveArgument
+
+`#resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer, NativeWebRequest webRequest, WebDataBinderFactory binderFactory)` 方法，解析指定参数的值。代码如下：
+
+```
+// HandlerMethodArgumentResolverComposite.java
+
+@Override
+@Nullable
+public Object resolveArgument(MethodParameter parameter, @Nullable ModelAndViewContainer mavContainer,
+		NativeWebRequest webRequest, @Nullable WebDataBinderFactory binderFactory) throws Exception {
+	// 获得 HandlerMethodArgumentResolver 对象
+	HandlerMethodArgumentResolver resolver = getArgumentResolver(parameter);
+	// 如果获得不到，抛出 IllegalArgumentException 异常
+	if (resolver == null) {
+		throw new IllegalArgumentException("Unknown parameter type [" + parameter.getParameterType().getName() + "]");
+	}
+	// 执行解析
+	return resolver.resolveArgument(parameter, mavContainer, webRequest, binderFactory);
+}
+```
+
+# 4. AbstractNamedValueMethodArgumentResolver
+
+`org.springframework.web.method.annotation.AbstractNamedValueMethodArgumentResolver` ，实现 ValueMethodArgumentResolver 接口，基于名字获取值的HandlerMethodArgumentResolver 抽象基类。例如说，`@RequestParam(value = "username")` 注解的参数，就是从请求中获得 `username` 对应的参数值。😈 明白了么？
+
+AbstractNamedValueMethodArgumentResolver 的子类不多，如下图所示：[![AbstractNamedValueMethodArgumentResolver 类图](16-Spring MVC 源码解析-HandlerAdapter 组件（三）之 HandlerMethodArgumentResolver.assets/02.png)](http://static.iocoder.cn/images/Spring/2022-03-26/02.png)AbstractNamedValueMethodArgumentResolver 类图
+
+😝 虽然不多，但是我们仅仅分析常用的，分别是：
+
+- RequestParamMethodArgumentResolver ，基于 `@RequestParam` 注解( 也可不加该注解的请求参数 )的方法参数，在 [「5. RequestParamMethodArgumentResolver」](https://svip.iocoder.cn/Spring-MVC/HandlerAdapter-3-HandlerMethodArgumentResolver/#) 中，详细解析。
+- PathVariableMethodArgumentResolver ，基于 `@PathVariable` 注解的方法参数，在 [「6. PathVariableMethodArgumentResolver」](https://svip.iocoder.cn/Spring-MVC/HandlerAdapter-3-HandlerMethodArgumentResolver/#) 中，详细解析。
+
+## 4.1 构造方法
+
+```
+// AbstractNamedValueMethodArgumentResolver.java
+
+@Nullable
+private final ConfigurableBeanFactory configurableBeanFactory;
+
+@Nullable
+private final BeanExpressionContext expressionContext;
+
+/**
+ * MethodParameter 和 NamedValueInfo 的映射，作为缓存。
+ */
+private final Map<MethodParameter, NamedValueInfo> namedValueInfoCache = new ConcurrentHashMap<>(256);
+
+public AbstractNamedValueMethodArgumentResolver() {
+	this.configurableBeanFactory = null;
+	this.expressionContext = null;
+}
+
+public AbstractNamedValueMethodArgumentResolver(@Nullable ConfigurableBeanFactory beanFactory) {
+	this.configurableBeanFactory = beanFactory;
+	this.expressionContext =
+			(beanFactory != null ? new BeanExpressionContext(beanFactory, new RequestScope()) : null);
+}
+```
+
+- `namedValueInfoCache` 属性，MethodParameter 和 NamedValueInfo 的映射，作为**缓存**。
+
+## 4.2 NamedValueInfo
+
+NamedValueInfo ，是 AbstractNamedValueMethodArgumentResolver 的静态类，代码如下：
+
+```
+// AbstractNamedValueMethodArgumentResolver.java
+
+/**
+ * Represents the information about a named value, including name, whether it's required and a default value.
+ */
+protected static class NamedValueInfo {
+
+    /**
+     * 名字
+     */
+	private final String name;
+    /**
+     * 是否必填
+     */
+	private final boolean required;
+    /**
+     * 默认值
+     */
+	@Nullable
+	private final String defaultValue;
+
+	public NamedValueInfo(String name, boolean required, @Nullable String defaultValue) {
+		this.name = name;
+		this.required = required;
+		this.defaultValue = defaultValue;
+	}
+
+}
+```
+
+## 4.3 getNamedValueInfo
+
+`#getNamedValueInfo(MethodParameter parameter)` 方法，获得方法参数对应的 NamedValueInfo 对象。代码如下：
+
+```
+// AbstractNamedValueMethodArgumentResolver.java
+
+private NamedValueInfo getNamedValueInfo(MethodParameter parameter) {
+    // <1> 从 namedValueInfoCache 缓存中，获得 NamedValueInfo 对象
+    NamedValueInfo namedValueInfo = this.namedValueInfoCache.get(parameter);
+	if (namedValueInfo == null) {
+        // <2> 获得不到，则创建 namedValueInfo 对象。这是一个抽象方法，子类来实现
+        namedValueInfo = createNamedValueInfo(parameter);
+        // <3> 更新 namedValueInfo 对象
+		namedValueInfo = updateNamedValueInfo(parameter, namedValueInfo);
+		// <4> 添加到 namedValueInfoCache 缓存中
+		this.namedValueInfoCache.put(parameter, namedValueInfo);
+	}
+	return namedValueInfo;
+}
+```
+
+- `<1>` 处，从 `namedValueInfoCache` 缓存中，获得 NamedValueInfo 对象。
+
+- `<2>` 处，获得不到，则调用 `#createNamedValueInfo(MethodParameter parameter)` 方法，创建 namedValueInfo 对象。这是一个**抽象**方法，子类来实现。代码如下：
+
+  ```
+  // AbstractNamedValueMethodArgumentResolver.java
+  
+  /**
+   * Create the {@link NamedValueInfo} object for the given method parameter. Implementations typically
+   * retrieve the method annotation by means of {@link MethodParameter#getParameterAnnotation(Class)}.
+   * @param parameter the method parameter
+   * @return the named value information
+   */
+  protected abstract NamedValueInfo createNamedValueInfo(MethodParameter parameter);
+  ```
+
+- `<3>` 处，调用 `#updateNamedValueInfo(MethodParameter parameter, NamedValueInfo info)` 方法，更新 `namedValueInfo` 对象。代码如下：
+
+  ```
+  // AbstractNamedValueMethodArgumentResolver.java
+  
+  /**
+   * Create a new NamedValueInfo based on the given NamedValueInfo with sanitized values.
+   */
+  private NamedValueInfo updateNamedValueInfo(MethodParameter parameter, NamedValueInfo info) {
+  	String name = info.name;
+  	// 如果名字为空，则抛出 IllegalArgumentException 异常
+  	if (info.name.isEmpty()) {
+  		name = parameter.getParameterName(); // 【注意！！！】如果 name 为空，则使用参数名
+  		if (name == null) {
+  			throw new IllegalArgumentException(
+  					"Name for argument type [" + parameter.getNestedParameterType().getName() +
+  					"] not available, and parameter name information not found in class file either.");
+  		}
+  	}
+  	// 获得默认值
+  	String defaultValue = (ValueConstants.DEFAULT_NONE.equals(info.defaultValue) ? null : info.defaultValue);
+  	// 创建 NamedValueInfo 对象
+  	return new NamedValueInfo(name, info.required, defaultValue);
+  }
+  ```
+
+  - 最终，会创建一个**新的** NamedValueInfo 对象。
+
+- `<4>` 处，添加到 `namedValueInfoCache` 缓存中。
+
+## 4.4 resolveArgument
+
+`#resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer, NativeWebRequest webRequest, WebDataBinderFactory binderFactory)` 方法，解析指定参数的值。代码如下：
+
+```
+// AbstractNamedValueMethodArgumentResolver.java
+
+@Override
+@Nullable
+public final Object resolveArgument(MethodParameter parameter, @Nullable ModelAndViewContainer mavContainer,
+		NativeWebRequest webRequest, @Nullable WebDataBinderFactory binderFactory) throws Exception {
+    // <1> 获得方法参数对应的 NamedValueInfo 对象。
+	NamedValueInfo namedValueInfo = getNamedValueInfo(parameter);
+	// <2> 如果 parameter 是内嵌类型的，则获取内嵌的参数。否则，还是使用 parameter 自身
+	MethodParameter nestedParameter = parameter.nestedIfOptional();
+
+	// <3> 如果 name 是占位符，则进行解析成对应的值
+	Object resolvedName = resolveStringValue(namedValueInfo.name);
+	if (resolvedName == null) { // 如果解析不到，则抛出 IllegalArgumentException 异常
+		throw new IllegalArgumentException(
+				"Specified name must not resolve to null: [" + namedValueInfo.name + "]");
+	}
+
+	// <4> 解析 name 对应的值
+	Object arg = resolveName(resolvedName.toString(), nestedParameter, webRequest);
+	// <5> 如果 arg 不存在，则使用默认值
+	if (arg == null) {
+		if (namedValueInfo.defaultValue != null) { // <5.1> 使用默认值
+			arg = resolveStringValue(namedValueInfo.defaultValue);
+		} else if (namedValueInfo.required && !nestedParameter.isOptional()) { // <5.2> 如果是必填，则处理参数缺失的情况
+			handleMissingValue(namedValueInfo.name, nestedParameter, webRequest);
+		}
+		// <5.3> 处理空值的情况
+		arg = handleNullValue(namedValueInfo.name, arg, nestedParameter.getNestedParameterType());
+    // <6> 如果 arg 为空串，则使用默认值
+	} else if ("".equals(arg) && namedValueInfo.defaultValue != null) {
+		arg = resolveStringValue(namedValueInfo.defaultValue);
+	}
+
+	// <7> 执行值的类型转换
+	if (binderFactory != null) {
+		WebDataBinder binder = binderFactory.createBinder(webRequest, null, namedValueInfo.name);
+		try {
+			arg = binder.convertIfNecessary(arg, parameter.getParameterType(), parameter);
+		} catch (ConversionNotSupportedException ex) {
+			throw new MethodArgumentConversionNotSupportedException(arg, ex.getRequiredType(),
+					namedValueInfo.name, parameter, ex.getCause());
+		} catch (TypeMismatchException ex) {
+			throw new MethodArgumentTypeMismatchException(arg, ex.getRequiredType(),
+					namedValueInfo.name, parameter, ex.getCause());
+		}
+	}
+
+	// 处理解析的值
+	handleResolvedValue(arg, namedValueInfo.name, parameter, mavContainer, webRequest);
+
+	return arg;
+}
+```
+
+- `<1>` 处，调用 `#getNamedValueInfo(MethodParameter parameter)` 方法，获得方法参数对应的 NamedValueInfo 对象。也就是说，在 [「4.3 getNamedValueInfo」](https://svip.iocoder.cn/Spring-MVC/HandlerAdapter-3-HandlerMethodArgumentResolver/#) 中。
+
+- `<2>` 处，如果 `parameter` 是内嵌类型的，则获取内嵌的参数。否则，还是使用 `parameter` 自身。一般情况下，`parameter` 参数，我们不太会使用 Optional 类型。所以，胖友也可以不理解。
+
+- `<3>` 处，调用 `#resolveStringValue(String value)` 方法，如果 `name` 是占位符，则进行解析成对应的值。代码如下：
+
+  ```
+  // AbstractNamedValueMethodArgumentResolver.java
+  
+  @Nullable
+  private Object resolveStringValue(String value) {
+      // 如果 configurableBeanFactory 为空，则不进行解析
+  	if (this.configurableBeanFactory == null) {
+  		return value;
+  	}
+      // 如果 exprResolver 或 expressionContext 为空，则不进行解析
+      BeanExpressionResolver exprResolver = this.configurableBeanFactory.getBeanExpressionResolver();
+      if (exprResolver == null || this.expressionContext == null) {
+          return value;
+      }
+  	// 获得占位符对应的值
+  	String placeholdersResolved = this.configurableBeanFactory.resolveEmbeddedValue(value);
+      // 计算表达式
+  	return exprResolver.evaluate(placeholdersResolved, this.expressionContext);
+  }
+  ```
+
+  - 这种用法非常小众，艿艿重来没用过。示例如下：
+
+    ```
+    // Controller.java
+    
+    @RequestMapping("/hello3")
+    public String hello3(@RequestParam(value = "${server.port}") String name) {
+        return "666";
+    }
+    
+    // application.properties
+    server.port=8012
+    ```
+
+    - 此时，就可以 `GET /hello3?8012=xxx` 。
+
+- `<4>` 处，调用 `#resolveName(String name, MethodParameter parameter, NativeWebRequest request)` **抽象**方法，解析 `name` 对应的值。代码如下：
+
+  ```
+  // AbstractNamedValueMethodArgumentResolver.java
+  
+  @Nullable
+  protected abstract Object resolveName(String name, MethodParameter parameter, NativeWebRequest request)
+  		throws Exception;
+  ```
+
+- `<5>` 处，如果 `arg` 为 `null` ，则使用默认值。
+
+  - `<5.1>` 处，如果默认值非空，则调用 `#resolveStringValue(defaultValue)` 方法，解析默认值。
+
+  - `<5.2>` 处，如果是必填，则调用 `#handleMissingValue(handleMissingValue)` 方法，处理参数缺失的情况调用。代码如下：
+
+    ```
+    // AbstractNamedValueMethodArgumentResolver.java
+    
+    protected void handleMissingValue(String name, MethodParameter parameter, NativeWebRequest request)
+    		throws Exception {
+    	handleMissingValue(name, parameter);
+    }
+    
+    protected void handleMissingValue(String name, MethodParameter parameter) throws ServletException {
+    	throw new ServletRequestBindingException("Missing argument '" + name +
+    			"' for method parameter of type " + parameter.getNestedParameterType().getSimpleName());
+    }
+    ```
+
+    - 抛出 ServletRequestBindingException 异常。
+    - 另外，子类 RequestParamMethodArgumentResolver 会重写该方法。
+
+  - `<5.3>` 处，调用 `#handleNullValue(String name, Object value, Class<?> paramType)` 方法，处理 `null` 值的情况。代码如下：
+
+    ```
+    // AbstractNamedValueMethodArgumentResolver.java
+    
+    /**
+     * A {@code null} results in a {@code false} value for {@code boolean}s or an exception for other primitives.
+     */
+    @Nullable
+    private Object handleNullValue(String name, @Nullable Object value, Class<?> paramType) {
+    	if (value == null) {
+    	    // 如果是 Boolean 类型，则返回 FALSE
+    		if (Boolean.TYPE.equals(paramType)) {
+    			return Boolean.FALSE;
+            // 如果基本类型，因为 null 无法转化，则抛出 IllegalStateException 异常
+    		} else if (paramType.isPrimitive()) {
+    			throw new IllegalStateException("Optional " + paramType.getSimpleName() + " parameter '" + name +
+    					"' is present but cannot be translated into a null value due to being declared as a " +
+    					"primitive type. Consider declaring it as object wrapper for the corresponding primitive type.");
+    		}
+    	}
+    	// 返回默认值
+    	return value;
+    }
+    ```
+
+    - 牛逼，各种细节的处理啊。
+
+- `<6>` 处，逻辑同 `<5.1>` 处。
+
+- `<7>` 处，执行值的类型转换。TODO 1016
+
+- `<8>` 处，调用 `#handleResolvedValue(Object arg, String name, MethodParameter parameter, ModelAndViewContainer mavContainer, NativeWebRequest webRequest)` 方法，解析值后的后置处理。代码如下：
+
+  ```
+  // AbstractNamedValueMethodArgumentResolver.java
+  
+  protected void handleResolvedValue(@Nullable Object arg, String name, MethodParameter parameter,
+  		@Nullable ModelAndViewContainer mavContainer, NativeWebRequest webRequest) {
+  }
+  ```
+
+  - 默认为空方法。
+  - 另外，子类 PathVariableMethodArgumentResolver 会重写该方法。
+
+> 艿艿：代码有丢丢长，实际逻辑是不复杂的。胖友在回看下。
+
+# 5. RequestParamMethodArgumentResolver
+
+`org.springframework.web.method.annotation.RequestParamMethodArgumentResolver` ，实现 UriComponentsContributor 接口，继承 AbstractNamedValueMethodArgumentResolver 抽象类，请求参数的 HandlerMethodArgumentResolver 实现类，处理**普通的请求参数**。
+
+## 5.1 构造方法
+
+```
+// RequestParamMethodArgumentResolver.java
+
+private static final TypeDescriptor STRING_TYPE_DESCRIPTOR = TypeDescriptor.valueOf(String.class);
+
+/**
+ * 是否使用默认解决。
+ *
+ * 这个变量有点绕，见 {@link #supportsParameter(MethodParameter)} 方法
+ */
+private final boolean useDefaultResolution;
+
+public RequestParamMethodArgumentResolver(boolean useDefaultResolution) {
+	this.useDefaultResolution = useDefaultResolution;
+}
+
+public RequestParamMethodArgumentResolver(@Nullable ConfigurableBeanFactory beanFactory,
+		boolean useDefaultResolution) {
+	super(beanFactory);
+	this.useDefaultResolution = useDefaultResolution;
+}
+```
+
+## 5.2 supportsParameter
+
+实现 `#supportsParameter(MethodParameter parameter)` 方法，代码如下：
+
+```
+// RequestParamMethodArgumentResolver.java
+
+@Override
+public boolean supportsParameter(MethodParameter parameter) {
+    // 有 @RequestParam 注解的情况
+    if (parameter.hasParameterAnnotation(RequestParam.class)) {
+        // <3> 如果是 Map 类型，则 @RequestParam 注解必须要有 name 属性
+        if (Map.class.isAssignableFrom(parameter.nestedIfOptional().getNestedParameterType())) {
+            RequestParam requestParam = parameter.getParameterAnnotation(RequestParam.class);
+            return (requestParam != null && StringUtils.hasText(requestParam.name()));
+        // 其它，默认支持
+        } else {
+            return true;
+        }
+    } else {
+        // 如果有 @RequestPart 注解，返回 false 。即 @RequestPart 的优先级 > @RequestParam
+        if (parameter.hasParameterAnnotation(RequestPart.class)) {
+            return false;
+        }
+        // 获得参数，如果存在内嵌的情况
+        parameter = parameter.nestedIfOptional();
+        // <1> 如果 Multipart 参数。则返回 true ，表示支持
+        if (MultipartResolutionDelegate.isMultipartArgument(parameter)) {
+            return true;
+        // <2> 如果开启 useDefaultResolution 功能，则判断是否为普通类型
+        } else if (this.useDefaultResolution) {
+            return BeanUtils.isSimpleProperty(parameter.getNestedParameterType());
+        // 其它，不支持
+        } else {
+            return false;
+        }
+    }
+}
+```
+
+- 情况有点多，胖友耐心看下注释。我们只讲里面的几处调用。
+
+- `<1>` 处，调用 `MultipartResolutionDelegate#isMultipartArgument(parameter)` 方法，如果 Multipart 参数。则返回 `true` ，表示支持。代码如下：
+
+  ```
+  // MultipartResolutionDelegate.java
+  
+  public static boolean isMultipartArgument(MethodParameter parameter) {
+  	Class<?> paramType = parameter.getNestedParameterType();
+  	// MultipartFile 的多种情况
+  	return (MultipartFile.class == paramType || isMultipartFileCollection(parameter) || isMultipartFileArray(parameter) ||
+  			// Part 的多种情况
+  			(Part.class == paramType || isPartCollection(parameter) || isPartArray(parameter)));
+  }
+  ```
+
+  - 上传文件相关的类型。
+
+- `<2>` 处，如果开启 `useDefaultResolution` 功能，则调用 `BeanUtils#isSimpleProperty(Class<?> clazz)` 方法，判断是否为普通类型。代码如下：
+
+  ```
+  // BeanUtils.java
+  
+  public static boolean isSimpleProperty(Class<?> clazz) {
+  	Assert.notNull(clazz, "Class must not be null");
+  	return isSimpleValueType(clazz) || (clazz.isArray() && isSimpleValueType(clazz.getComponentType()));
+  }
+  
+  public static boolean isSimpleValueType(Class<?> clazz) {
+  	return (ClassUtils.isPrimitiveOrWrapper(clazz) ||
+  			Enum.class.isAssignableFrom(clazz) ||
+  			CharSequence.class.isAssignableFrom(clazz) ||
+  			Number.class.isAssignableFrom(clazz) ||
+  			Date.class.isAssignableFrom(clazz) ||
+  			URI.class == clazz || URL.class == clazz ||
+  			Locale.class == clazz || Class.class == clazz);
+  }
+  ```
+
+- 继续补充 `<2>` 处，那么 `useDefaultResolution` 到底是怎么样的赋值呢？回到 RequestMappingHandlerAdapter 的 `#getDefaultArgumentResolvers()` 的方法，精简代码如下：
+
+  ```
+  // RequestMappingHandlerAdapter.java
+  
+  private List<HandlerMethodArgumentResolver> getDefaultArgumentResolvers() {
+  	List<HandlerMethodArgumentResolver> resolvers = new ArrayList<>();
+  
+  	// Annotation-based argument resolution
+  	resolvers.add(new RequestParamMethodArgumentResolver(getBeanFactory(), false));
+  	
+  	// .. 省略一大片
+  
+  	// Catch-all
+  	resolvers.add(new RequestParamMethodArgumentResolver(getBeanFactory(), true));
+  	
+  	// .. 省略几个
+  
+  	return resolvers;
+  }
+  ```
+
+  - 我们可以看到有两个 RequestParamMethodArgumentResolver 对象，前者 `useDefaultResolution` 为 `false` ，后者为 `useDefaultResolution` 为 `true` 。什么意思呢？优先将待有 `@RequestParam` 注解的请求参数给第一个 RequestParamMethodArgumentResolver 对象；其次，给中间省略的一大片参数解析器试试能不能解析；最后，使用第二个 RequestParamMethodArgumentResolver 兜底，处理剩余的情况。
+
+- `<3>` 处，如果是 Map 类型，则 @RequestParam 注解必须要有 `name` 属性。是不是感觉有几分灵异？答案在 [「6. RequestParamMapMethodArgumentResolver」](https://svip.iocoder.cn/Spring-MVC/HandlerAdapter-3-HandlerMethodArgumentResolver/#) 一起讲。
+
+## 5.3 createNamedValueInfo
+
+`#createNamedValueInfo(MethodParameter parameter)` 方法，创建 NamedValueInfo 对象。代码如下：
+
+```
+// RequestParamMethodArgumentResolver.java
+
+@Override
+protected NamedValueInfo createNamedValueInfo(MethodParameter parameter) {
+	RequestParam ann = parameter.getParameterAnnotation(RequestParam.class);
+	return (ann != null ? new RequestParamNamedValueInfo(ann) : new RequestParamNamedValueInfo());
+}
+
+private static class RequestParamNamedValueInfo extends NamedValueInfo {
+
+	public RequestParamNamedValueInfo() {
+		super("", false, ValueConstants.DEFAULT_NONE);
+	}
+
+	public RequestParamNamedValueInfo(RequestParam annotation) {
+		super(annotation.name(), annotation.required(), annotation.defaultValue());
+	}
+	
+}
+```
+
+- 虽然，在无 `@RequestMapping` 时，返回的 RequestParamNamedValueInfo 对象的 `name` 属性为 `""` ，但是胖友在回过头看 [「4.3 getNamedValueInfo」](https://svip.iocoder.cn/Spring-MVC/HandlerAdapter-3-HandlerMethodArgumentResolver/#) ，有一个“【注意】！！！”的地方。😈
+
+## 5.4 resolveName
+
+实现 `#resolveName(String name, MethodParameter parameter, NativeWebRequest request)` 方法，获得参数的值。代码如下：
+
+```
+// RequestParamMethodArgumentResolver.java
+
+@Override
+@Nullable
+protected Object resolveName(String name, MethodParameter parameter, NativeWebRequest request) throws Exception {
+	// 情况一，HttpServletRequest 情况下的 MultipartFile 和 Part 的情况
+	HttpServletRequest servletRequest = request.getNativeRequest(HttpServletRequest.class);
+	if (servletRequest != null) {
+		Object mpArg = MultipartResolutionDelegate.resolveMultipartArgument(name, parameter, servletRequest);
+		if (mpArg != MultipartResolutionDelegate.UNRESOLVABLE) {
+			return mpArg;
+		}
+	}
+
+	// 情况二，MultipartHttpServletRequest 情况下的 MultipartFile 的情况
+	Object arg = null;
+	MultipartHttpServletRequest multipartRequest = request.getNativeRequest(MultipartHttpServletRequest.class);
+	if (multipartRequest != null) {
+		List<MultipartFile> files = multipartRequest.getFiles(name);
+		if (!files.isEmpty()) {
+			arg = (files.size() == 1 ? files.get(0) : files);
+		}
+	}
+
+	// 情况三，普通参数的获取
+	if (arg == null) {
+		String[] paramValues = request.getParameterValues(name);
+		if (paramValues != null) {
+			arg = (paramValues.length == 1 ? paramValues[0] : paramValues);
+		}
+	}
+	return arg;
+}
+```
+
+- 情况一、二，是处理参数类型为**文件** `org.springframework.web.multipart.MultipartFile` 和 `javax.servlet.http.Part` 的参数的获取。
+- 情况三，是处理**普通**参数的获取。就是我们常见的 String、Integer 之类的请求参数。
+
+## 5.5 handleMissingValue
+
+重写 `#handleMissingValue(String name, MethodParameter parameter, NativeWebRequest request)` 方法，代码如下：
+
+```
+// RequestParamMethodArgumentResolver.java
+
+@Override
+protected void handleMissingValue(String name, MethodParameter parameter, NativeWebRequest request)
+		throws Exception {
+	HttpServletRequest servletRequest = request.getNativeRequest(HttpServletRequest.class);
+	if (MultipartResolutionDelegate.isMultipartArgument(parameter)) {
+		if (servletRequest == null || !MultipartResolutionDelegate.isMultipartRequest(servletRequest)) {
+			throw new MultipartException("Current request is not a multipart request");
+		} else {
+			throw new MissingServletRequestPartException(name);
+		}
+	} else {
+		throw new MissingServletRequestParameterException(name, parameter.getNestedParameterType().getSimpleName());
+	}
+}
+```
+
+- 根据参数的类型，做更详细的异常抛出。
+
+# 6. RequestParamMapMethodArgumentResolver
+
+`org.springframework.web.method.annotation.RequestParamMapMethodArgumentResolver` ，实现 HandlerMethodArgumentResolver 接口，处理带有 `@RequestParam` 注解，但是注解上无 `name` 属性的 Map 类型的参数的 RequestParamMethodArgumentResolver 实现类。代码如下：
+
+```
+// RequestParamMapMethodArgumentResolver.java
+
+public class RequestParamMapMethodArgumentResolver implements HandlerMethodArgumentResolver {
+
+    @Override
+    public boolean supportsParameter(MethodParameter parameter) {
+        RequestParam requestParam = parameter.getParameterAnnotation(RequestParam.class);
+        return (requestParam != null && Map.class.isAssignableFrom(parameter.getParameterType()) &&
+                !StringUtils.hasText(requestParam.name()));
+    }
+
+    @Override
+    public Object resolveArgument(MethodParameter parameter, @Nullable ModelAndViewContainer mavContainer,
+            NativeWebRequest webRequest, @Nullable WebDataBinderFactory binderFactory) throws Exception {
+
+        Class<?> paramType = parameter.getParameterType();
+
+        // 获得请求的参数集合
+        Map<String, String[]> parameterMap = webRequest.getParameterMap();
+
+        // MultiValueMap 类型的处理
+        if (MultiValueMap.class.isAssignableFrom(paramType)) {
+            MultiValueMap<String, String> result = new LinkedMultiValueMap<>(parameterMap.size());
+            parameterMap.forEach((key, values) -> {
+                for (String value : values) {
+                    result.add(key, value);
+                }
+            });
+            return result;
+        // 普通 Map 类型的处理
+        } else {
+            Map<String, String> result = new LinkedHashMap<>(parameterMap.size());
+            parameterMap.forEach((key, values) -> {
+                if (values.length > 0) {
+                    result.put(key, values[0]);
+                }
+            });
+            return result;
+        }
+    }
+}
+```
+
+- 具体的代码实现，胖友自己瞅瞅。当然，良心如艿艿，还是会提供示例。
+
+① 对于 RequestParamMapMethodArgumentResolver 类，它的效果是，将所有参数添加到 Map 集合中。示例如下：
+
+```
+// Controller.java
+
+@RequestMapping("/hello4")
+public String hello4(@RequestParam Map<String, Object> map) {
+    return "666";
+}
+```
+
+- `GET /hello4?name=yyy&age=20` 的 `name` 和 `age` 参数，就会都添加到 `map` 中。
+
+② 对于 RequestParamMethodArgumentResolver 类，它的效果是，将指定名字的参数添加到 Map 集合中。示例如下：
+
+```
+// Controller.java
+
+@RequestMapping("/hello5")
+public String hello5(@RequestParam(name = "map") Map<String, Object> map) {
+    return "666";
+}
+```
+
+- `GET /hello4?map={"name": "yyyy", age: 20}` 的 `map` 参数，就会都添加到 `map` 中。当然，要注意下，实际请求要 UrlEncode 编码下参数，所以实际请求是 `GET /hello4?map=%7b%22name%22%3a+%22yyyy%22%2c+age%3a+20%7d` 。
+
+# 7. PathVariableMethodArgumentResolver
+
+`org.springframework.web.servlet.mvc.method.annotation.PathVariableMethodArgumentResolver` ，实现 UriComponentsContributor 接口，继承 AbstractNamedValueMethodArgumentResolver 抽象类，处理路径参数。
+
+## 7.1 supportsParameter
+
+实现 `#supportsParameter(MethodParameter parameter)` 方法，代码如下：
+
+```
+// PathVariableMethodArgumentResolver.java
+
+@Override
+public boolean supportsParameter(MethodParameter parameter) {
+	// 如果无 @PathVariable 注解
+	if (!parameter.hasParameterAnnotation(PathVariable.class)) {
+		return false;
+	}
+	// <x> Map 类型，有 @PathVariable 注解，但是有 name 属性
+	if (Map.class.isAssignableFrom(parameter.nestedIfOptional().getNestedParameterType())) {
+		PathVariable pathVariable = parameter.getParameterAnnotation(PathVariable.class);
+		return (pathVariable != null && StringUtils.hasText(pathVariable.value()));
+	}
+	// 有 @PathVariable 注解
+	return true;
+}
+```
+
+- 大体逻辑，胖友自己看代码。
+- `<x>` 处，又出了上面刚刚说过的 Map 的情况，胖友自己去对比 `org.springframework.web.servlet.mvc.method.annotation.PathVariableMapMethodArgumentResolver` 类。
+
+## 7.2 createNamedValueInfo
+
+实现 `#createNamedValueInfo(MethodParameter parameter)` 方法，代码如下：
+
+```
+// PathVariableMethodArgumentResolver.java
+
+@Override
+protected NamedValueInfo createNamedValueInfo(MethodParameter parameter) {
+    // 获得 @PathVariable 注解
+	PathVariable ann = parameter.getParameterAnnotation(PathVariable.class);
+	Assert.state(ann != null, "No PathVariable annotation");
+	// 创建 PathVariableNamedValueInfo 对象
+	return new PathVariableNamedValueInfo(ann);
+}
+
+private static class PathVariableNamedValueInfo extends NamedValueInfo {
+
+	public PathVariableNamedValueInfo(PathVariable annotation) {
+		super(annotation.name(), annotation.required(), ValueConstants.DEFAULT_NONE);
+	}
+	
+}
+```
+
+## 7.3 resolveName
+
+实现 `#resolveName(String name, MethodParameter parameter, NativeWebRequest request)` 方法，代码如下：
+
+```
+// PathVariableMethodArgumentResolver.java
+
+@Override
+@Nullable
+protected Object resolveName(String name, MethodParameter parameter, NativeWebRequest request) throws Exception {
+	// 获得路径参数
+	Map<String, String> uriTemplateVars = (Map<String, String>) request.getAttribute(
+			HandlerMapping.URI_TEMPLATE_VARIABLES_ATTRIBUTE, RequestAttributes.SCOPE_REQUEST);
+	// 获得参数值
+	return (uriTemplateVars != null ? uriTemplateVars.get(name) : null);
+}
+```
+
+## 7.4 handleMissingValue
+
+重写 `#handleMissingValue()` 方法，抛出 MissingPathVariableException 异常。代码如下：
+
+```
+// PathVariableMethodArgumentResolver.java
+
+@Override
+protected void handleMissingValue(String name, MethodParameter parameter) throws ServletRequestBindingException {
+    // 抛出 MissingPathVariableException 异常
+    throw new MissingPathVariableException(name, parameter);
+}
+```
+
+## 7.5 handleResolvedValue
+
+重写 `#handleResolvedValue(Object arg, String name, MethodParameter parameter, ModelAndViewContainer mavContainer, NativeWebRequest request)` 方法，添加获得的属性值到请求的 `View.PATH_VARIABLES` 属性种。代码如下：
+
+```
+// PathVariableMethodArgumentResolver.java
+
+@Override
+protected void handleResolvedValue(@Nullable Object arg, String name, MethodParameter parameter,
+        @Nullable ModelAndViewContainer mavContainer, NativeWebRequest request) {
+    // 获得 pathVars
+    String key = View.PATH_VARIABLES;
+    int scope = RequestAttributes.SCOPE_REQUEST;
+    Map<String, Object> pathVars = (Map<String, Object>) request.getAttribute(key, scope);
+    // 如果不存在 pathVars ，则进行创建
+    if (pathVars == null) {
+        pathVars = new HashMap<>();
+        request.setAttribute(key, pathVars, scope);
+    }
+    // 添加 name + arg 到 pathVars 中
+    pathVars.put(name, arg);
+}
+```
+
+# 666. 彩蛋
+
+感觉，还有一些需要写的 HandlerMethodArgumentResolver 实现类，暂时还没想好。
+
+如果胖友有什么 HandlerMethodArgumentResolver 实现类，希望艿艿来写，请在星球给我留言。TODO 9999 HandlerMethodArgumentResolver
+
+参考和推荐如下文章：
+
+- 韩路彪 [《看透 Spring MVC：源代码分析与实践》](https://item.jd.com/11807414.html) 的 [「第 13.7 HandlerMethodArgumentResolver」](https://svip.iocoder.cn/Spring-MVC/HandlerAdapter-3-HandlerMethodArgumentResolver/#) 小节
\ No newline at end of file
diff --git a/springmvc/17-Spring MVC 源码解析-HandlerAdapter 组件（四）之 HandlerMethodReturnValueHandler.assets/01.png b/springmvc/17-Spring MVC 源码解析-HandlerAdapter 组件（四）之 HandlerMethodReturnValueHandler.assets/01.png
new file mode 100644
index 0000000..894c1d2
Binary files /dev/null and b/springmvc/17-Spring MVC 源码解析-HandlerAdapter 组件（四）之 HandlerMethodReturnValueHandler.assets/01.png differ
diff --git a/springmvc/17-Spring MVC 源码解析-HandlerAdapter 组件（四）之 HandlerMethodReturnValueHandler.assets/02.png b/springmvc/17-Spring MVC 源码解析-HandlerAdapter 组件（四）之 HandlerMethodReturnValueHandler.assets/02.png
new file mode 100644
index 0000000..75dd307
Binary files /dev/null and b/springmvc/17-Spring MVC 源码解析-HandlerAdapter 组件（四）之 HandlerMethodReturnValueHandler.assets/02.png differ
diff --git a/springmvc/17-Spring MVC 源码解析-HandlerAdapter 组件（四）之 HandlerMethodReturnValueHandler.md b/springmvc/17-Spring MVC 源码解析-HandlerAdapter 组件（四）之 HandlerMethodReturnValueHandler.md
new file mode 100644
index 0000000..809b572
--- /dev/null
+++ b/springmvc/17-Spring MVC 源码解析-HandlerAdapter 组件（四）之 HandlerMethodReturnValueHandler.md	
@@ -0,0 +1,807 @@
+# 精尽 Spring MVC 源码解析 —— HandlerAdapter 组件（四）之 HandlerMethodReturnValueHandler
+
+# 1. 概述
+
+本文接 [《精尽 Spring MVC 源码解析 —— HandlerAdapter 组件（二）之 ServletInvocableHandlerMethod》](http://svip.iocoder.cn/Spring-MVC/HandlerAdapter-2-ServletInvocableHandlerMethod) 一文，我们来分享 HandlerMethodReturnValueHandler ，HandlerMethod 的**返回值**的处理器接口。代码如下：
+
+```
+// HandlerMethodReturnValueHandler.java
+
+public interface HandlerMethodReturnValueHandler {
+
+    /**
+     * 是否支持该类型
+     *
+     * Whether the given {@linkplain MethodParameter method return type} is
+     * supported by this handler.
+     * @param returnType the method return type to check
+     * @return {@code true} if this handler supports the supplied return type;
+     * {@code false} otherwise
+     */
+    boolean supportsReturnType(MethodParameter returnType);
+
+    /**
+     * 处理返回值，设置到 {@param mavContainer} 中
+     *
+     * Handle the given return value by adding attributes to the model and
+     * setting a view or setting the
+     * {@link ModelAndViewContainer#setRequestHandled} flag to {@code true}
+     * to indicate the response has been handled directly.
+     * @param returnValue the value returned from the handler method
+     * @param returnType the type of the return value. This type must have
+     * previously been passed to {@link #supportsReturnType} which must
+     * have returned {@code true}.
+     * @param mavContainer the ModelAndViewContainer for the current request
+     * @param webRequest the current request
+     * @throws Exception if the return value handling results in an error
+     */
+    void handleReturnValue(@Nullable Object returnValue, MethodParameter returnType,
+            ModelAndViewContainer mavContainer, NativeWebRequest webRequest) throws Exception;
+
+}
+```
+
+- 两个方法，分别是是否支持解析该类型、以及处理返回值。
+
+# 2. 类图
+
+HandlerMethodReturnValueHandler 的实现类非常多，如下图所示：
+
+[![HandlerMethodReturnValueHandler 类图](17-Spring MVC 源码解析-HandlerAdapter 组件（四）之 HandlerMethodReturnValueHandler.assets/01.png)](http://static.iocoder.cn/images/Spring/2022-03-29/01.png)HandlerMethodReturnValueHandler 类图
+
+因为实在太大，胖友可以点击 [传送](http://static.iocoder.cn/images/Spring/2022-03-29/01.png) 查看。
+
+下面，我要说什么化，想必熟悉我的胖友已经知道了，我们就分析几个 HandlerMethodReturnValueHandler 实现类。哈哈哈哈。
+
+# 3. ModelAndViewContainer
+
+`org.springframework.web.method.support.ModelAndViewContainer` ，主要是作为 Model 和 View 的容器，当然其中还有其它属性。
+
+## 3.1 构造方法
+
+```
+// ModelAndViewContainer.java
+
+/**
+ * 是否在 redirect 重定向时，忽略 {@link #redirectModel}
+ */
+private boolean ignoreDefaultModelOnRedirect = false;
+
+/**
+ * 视图，Object 类型。
+ *
+ * 实际情况下，也可以是 String 类型的逻辑视图
+ */
+@Nullable
+private Object view;
+
+/**
+ * 默认使用的 Model 。实际上是个 Map
+ */
+private final ModelMap defaultModel = new BindingAwareModelMap();
+
+/**
+ * redirect 重定向的 Model ，在重定向时使用。
+ */
+@Nullable
+private ModelMap redirectModel;
+
+/**
+ * 处理器返回 redirect 视图的标识
+ */
+private boolean redirectModelScenario = false;
+
+/**
+ * Http 响应状态
+ */
+@Nullable
+private HttpStatus status;
+
+/**
+ * TODO
+ */
+private final Set<String> noBinding = new HashSet<>(4);
+
+/**
+ * TODO
+ */
+private final Set<String> bindingDisabled = new HashSet<>(4);
+
+/**
+ * 用于设置 SessionAttribute 的标识
+ */
+private final SessionStatus sessionStatus = new SimpleSessionStatus();
+
+/**
+ * 请求是否处理完的标识
+ */
+private boolean requestHandled = false;
+```
+
+- 属性有点多，不要懵逼。我们带着一起在下面的几个方法来瞅瞅。
+
+## 3.2 getModel
+
+`#getModel()` 方法，获得 Model 对象。代码如下：
+
+```
+// ModelAndViewContainer.java
+
+public ModelMap getModel() {
+    // 是否使用默认 Model
+	if (useDefaultModel()) {
+		return this.defaultModel;
+	} else {
+		if (this.redirectModel == null) {
+			this.redirectModel = new ModelMap();
+		}
+		return this.redirectModel;
+	}
+}
+
+/**
+ * Whether to use the default model or the redirect model.
+ */
+private boolean useDefaultModel() {
+	return (!this.redirectModelScenario || (this.redirectModel == null && !this.ignoreDefaultModelOnRedirect));
+}
+```
+
+- 从代码中，可以看出，有两种情况下，使用
+
+   
+
+  ```
+  defaultModel
+  ```
+
+   
+
+  默认 Model ：
+
+  - 情况一 `!this.redirectModelScenario` ，处理器返回 redirect 视图的标识为 `false` 的时候，即不重定向。
+  - 情况二 `this.redirectModel == null && !this.ignoreDefaultModelOnRedirect` ，`redirectModel` 重定向 Model 为**空**，并且 `ignoreDefaultModelOnRedirect` 为 `true` ，即忽略 `defaultModel` 。
+
+- 那么，问题就来了，
+
+  ```
+  redirectModelScenario
+  ```
+
+   
+
+  和
+
+   
+
+  ```
+  ignoreDefaultModelOnRedirect
+  ```
+
+   
+
+  什么时候被改变？
+
+  - `redirectModelScenario` 属性，可见 [「6.3 handleReturnValue」](https://svip.iocoder.cn/Spring-MVC/HandlerAdapter-4-HandlerMethodReturnValueHandler/#) 中。
+  - `ignoreDefaultModelOnRedirect` 属性，和 `RequestMappingHandlerAdapter.ignoreDefaultModelOnRedirect` 的属性是一致的，在 `RequestMappingHandlerAdapter#invokeHandlerMethod(HttpServletRequest request, HttpServletResponse response, HandlerMethod handlerMethod)` 方法中，进行设置。
+
+- 另外，`org.springframework.ui.ModelMap` 是继承 LinkedHashMap 类，并增加了部分常用方法。比较简单，胖友点击 [传送门](https://github.com/spring-projects/spring-framework/blob/master/spring-context/src/main/java/org/springframework/ui/ModelMap.java) 瞅瞅。
+
+## 3.3 View 相关的方法
+
+比较简单，胖友自己瞅瞅。
+
+```
+// ModelAndViewContainer.java
+
+public void setViewName(@Nullable String viewName) {
+	this.view = viewName;
+}
+@Nullable
+public String getViewName() {
+	return (this.view instanceof String ? (String) this.view : null);
+}
+
+public void setView(@Nullable Object view) {
+	this.view = view;
+}
+@Nullable
+public Object getView() {
+	return this.view;
+}
+
+public boolean isViewReference() {
+	return (this.view instanceof String);
+}
+```
+
+## 3.4 requestHandled 标识
+
+关于 `requestHandled` 的修改地方，实际在 Spring MVC 地方蛮多处都可以进行修改。感兴趣的胖友，可以使用 IDEA 右键该属性，选择 “Find Usages” 进行查看。
+
+目前，我们在 [《精尽 Spring MVC 源码解析 —— HandlerAdapter 组件（二）之 ServletInvocableHandlerMethod》](http://svip.iocoder.cn/Spring-MVC/HandlerAdapter-2-ServletInvocableHandlerMethod) 的 [「5.2 invokeAndHandle」](https://svip.iocoder.cn/Spring-MVC/HandlerAdapter-4-HandlerMethodReturnValueHandler/#) 中，已经看到该属性的修改。
+
+# 4. HandlerMethodReturnValueHandlerComposite
+
+`org.springframework.web.method.support.HandlerMethodReturnValueHandlerComposite` ，实现 HandlerMethodReturnValueHandler 接口，复合的 HandlerMethodReturnValueHandler 实现类。
+
+实际上，和我们在 [《精尽 Spring MVC 源码解析 —— HandlerAdapter 组件（三）之 HandlerMethodArgumentResolver》](http://svip.iocoder.cn/Spring-MVC/HandlerAdapter-3-HandlerMethodArgumentResolver) 的 [「3. HandlerMethodArgumentResolverComposite」](https://svip.iocoder.cn/Spring-MVC/HandlerAdapter-4-HandlerMethodReturnValueHandler/#) 是一致的。
+
+## 4.1 构造方法
+
+```
+// HandlerMethodReturnValueHandlerComposite.java
+
+/**
+ * HandlerMethodReturnValueHandler 数组
+ */
+private final List<HandlerMethodReturnValueHandler> returnValueHandlers = new ArrayList<>();
+```
+
+另外，在 [《精尽 Spring MVC 源码解析 —— HandlerAdapter 组件（一）之 HandlerAdapter》](http://svip.iocoder.cn/Spring-MVC/HandlerAdapter-1-HandlerAdapter) 的 [「7.2.4 getDefaultReturnValueHandlers」](https://svip.iocoder.cn/Spring-MVC/HandlerAdapter-4-HandlerMethodReturnValueHandler/#) 中，我们已经看到了，HandlerMethodReturnValueHandlerComposite 默认复合的所有 HandlerMethodReturnValueHandler 对象。😈 忘记的胖友，可以点下 [传送门](https://github.com/spring-projects/spring-framework/blob/master/spring-webmvc/src/main/java/org/springframework/web/servlet/mvc/method/annotation/RequestMappingHandlerAdapter.java#L717-L761) 再瞅瞅。
+
+## 4.2 getReturnValueHandler
+
+`#getReturnValueHandler(MethodParameter returnType)` 方法，获得方法返回值对应的 HandlerMethodReturnValueHandler 对象。代码如下：
+
+```
+// HandlerMethodReturnValueHandlerComposite.java
+
+@Nullable
+private HandlerMethodReturnValueHandler getReturnValueHandler(MethodParameter returnType) {
+    // 遍历 returnValueHandlers 数组，逐个判断是否支持
+    for (HandlerMethodReturnValueHandler handler : this.returnValueHandlers) {
+        // 如果支持，则返回
+        if (handler.supportsReturnType(returnType)) {
+            return handler;
+        }
+    }
+    return null;
+}
+```
+
+- 😈 不过有点纳闷，这里为什么不加缓存？！
+
+## 4.3 supportsParameter
+
+实现 `#getReturnValueHandler(MethodParameter returnType)` 方法，如果能获得到对应的 HandlerMethodReturnValueHandler 处理器，则说明支持。代码如下：
+
+```
+// HandlerMethodReturnValueHandlerComposite.java
+
+@Override
+public boolean supportsReturnType(MethodParameter returnType) {
+	return getReturnValueHandler(returnType) != null;
+}
+```
+
+## 4.4 handleReturnValue
+
+`#handleReturnValue(Object returnValue, MethodParameter returnType, ModelAndViewContainer mavContainer, NativeWebRequest webRequest)` 方法，处理返回值。代码如下：
+
+```
+// HandlerMethodReturnValueHandlerComposite.java
+
+@Override
+public void handleReturnValue(@Nullable Object returnValue, MethodParameter returnType,
+		ModelAndViewContainer mavContainer, NativeWebRequest webRequest) throws Exception {
+	// <x> 获得 HandlerMethodReturnValueHandler 对象
+	HandlerMethodReturnValueHandler handler = selectHandler(returnValue, returnType);
+	// 如果获取不到，则抛出 IllegalArgumentException 异常
+	if (handler == null) {
+		throw new IllegalArgumentException("Unknown return value type: " + returnType.getParameterType().getName());
+	}
+	// 处理器返回值
+	handler.handleReturnValue(returnValue, returnType, mavContainer, webRequest);
+}
+```
+
+- 其中，比较神奇的是，`<x>` 处，调用 `#selectHandler(Object value, MethodParameter returnType)` 方法，获得 HandlerMethodReturnValueHandler 对象。代码如下：
+
+  ```
+  // HandlerMethodReturnValueHandlerComposite.java
+  
+  @Nullable
+  private HandlerMethodReturnValueHandler selectHandler(@Nullable Object value, MethodParameter returnType) {
+      // 判断是否为异步返回值
+      boolean isAsyncValue = isAsyncReturnValue(value, returnType);
+      // 遍历 HandlerMethodReturnValueHandler 数组，逐个判断是否支持
+      for (HandlerMethodReturnValueHandler handler : this.returnValueHandlers) {
+          // 如果是异步返回值的类型，则必须要求是 AsyncHandlerMethodReturnValueHandler 类型的处理器
+          if (isAsyncValue && !(handler instanceof AsyncHandlerMethodReturnValueHandler)) {
+              continue;
+          }
+          // 如果支持，则返回
+          if (handler.supportsReturnType(returnType)) {
+              return handler;
+          }
+      }
+      return null;
+  }
+  
+  // 判断逻辑是，有异步处理器 AsyncHandlerMethodReturnValueHandler ，并且返回值符合异步的类型
+  private boolean isAsyncReturnValue(@Nullable Object value, MethodParameter returnType) {
+      for (HandlerMethodReturnValueHandler handler : this.returnValueHandlers) {
+          if (handler instanceof AsyncHandlerMethodReturnValueHandler &&
+                  ((AsyncHandlerMethodReturnValueHandler) handler).isAsyncReturnValue(value, returnType)) {
+              return true;
+          }
+      }
+      return false;
+  }
+  ```
+
+  - 在 `#getReturnValueHandler(MethodParameter returnType)` 方法的基础上，增加了**异步**处理器 AsyncHandlerMethodReturnValueHandler 的逻辑。
+
+# 5. RequestResponseBodyMethodProcessor
+
+`org.springframework.web.servlet.mvc.method.annotation.RequestResponseBodyMethodProcessor` ，继承 AbstractMessageConverterMethodProcessor 抽象类，处理请求参数添加了 `@RequestBody` 注解，或者返回值添加了 `@ResponseBody` 注解的处理。
+
+因为前后端分离之后，后端基本是提供 Restful API ，所以 RequestResponseBodyMethodProcessor 成为了目前最常用的 HandlerMethodReturnValueHandler 实现类。
+
+[![HandlerMethodReturnValueHandler 类图](17-Spring MVC 源码解析-HandlerAdapter 组件（四）之 HandlerMethodReturnValueHandler.assets/02.png)](http://static.iocoder.cn/images/Spring/2022-03-29/02.png)HandlerMethodReturnValueHandler 类图
+
+从图中，我们也会发现，RequestResponseBodyMethodProcessor 也是 HandlerMethodArgumentResolver 的实现类。当然本文暂时不写，未来补充到 [《精尽 Spring MVC 源码解析 —— HandlerAdapter 组件（三）之 HandlerMethodArgumentResolver》](http://svip.iocoder.cn/Spring-MVC/HandlerAdapter-3-HandlerMethodArgumentResolver) 中。
+
+------
+
+简单示例代码如下：
+
+```
+@RestController
+@RequestMapping("/user")
+public class UserController {
+
+    @RequestMapping("/walks")
+    public List<User> walk() {
+        List<User> users = new ArrayList();
+        users.add(new User().setUsername("nihao"));
+        users.add(new User().setUsername("zaijian"));
+        return users;
+    }
+
+}
+```
+
+- 虽然，`#walks()` 方法的返回值没添加 `@ResponseBody` 注解，但是 `@RestController` 注解，默认有 `@ResponseBody` 注解 。
+
+## 5.1 构造方法
+
+```
+// RequestResponseBodyMethodProcessor.java
+
+public RequestResponseBodyMethodProcessor(List<HttpMessageConverter<?>> converters) {
+	super(converters);
+}
+
+public RequestResponseBodyMethodProcessor(List<HttpMessageConverter<?>> converters,
+		@Nullable ContentNegotiationManager manager) {
+	super(converters, manager);
+}
+
+public RequestResponseBodyMethodProcessor(List<HttpMessageConverter<?>> converters,
+		@Nullable List<Object> requestResponseBodyAdvice) {
+	super(converters, null, requestResponseBodyAdvice);
+}
+
+public RequestResponseBodyMethodProcessor(List<HttpMessageConverter<?>> converters,
+		@Nullable ContentNegotiationManager manager, @Nullable List<Object> requestResponseBodyAdvice) {
+	super(converters, manager, requestResponseBodyAdvice);
+}
+```
+
+- `converters` 参数，HttpMessageConverter 数组。关于 HttpMessageConverter ，可以说我们非常熟悉的朋友了。例如，我们想要将 POJO 对象，返回成 JSON 数据给前端，就会使用到 MappingJackson2HttpMessageConverter 类。
+- `requestResponseBodyAdvice` 参数，一般情况是 ResponseBodyAdvice 类型，可实现对返回结果的修改。具体的使用示例，可见 [《@ControllerAdvice, ResponseBodyAdvice 统一处理返回值/响应体》](https://blog.csdn.net/u012852374/article/details/53837156) 。
+
+## 5.2 supportsReturnType
+
+实现 `#supportsReturnType(MethodParameter returnType)` 方法，判断是否添加 `@ResponseBody` 注解。代码如下：
+
+```
+// RequestResponseBodyMethodProcessor.java
+
+@Override
+public boolean supportsReturnType(MethodParameter returnType) {
+	return (AnnotatedElementUtils.hasAnnotation(returnType.getContainingClass(), ResponseBody.class)
+            || returnType.hasMethodAnnotation(ResponseBody.class));
+}
+```
+
+## 5.3 handleReturnValue
+
+实现 `#handleReturnValue(Object returnValue, MethodParameter returnType, ModelAndViewContainer mavContainer, NativeWebRequest webRequest)` 方法，代码如下：
+
+```
+// RequestResponseBodyMethodProcessor.java
+
+@Override
+public void handleReturnValue(@Nullable Object returnValue, MethodParameter returnType,
+        ModelAndViewContainer mavContainer, NativeWebRequest webRequest)
+        throws IOException, HttpMediaTypeNotAcceptableException, HttpMessageNotWritableException {
+    // <1> 设置已处理
+    mavContainer.setRequestHandled(true);
+
+    // <2> 创建请求和响应
+    ServletServerHttpRequest inputMessage = createInputMessage(webRequest);
+    ServletServerHttpResponse outputMessage = createOutputMessage(webRequest);
+
+    // Try even with null return value. ResponseBodyAdvice could get involved.
+    // <3> 使用 HttpMessageConverter 对对象进行转换，并写入到响应
+    writeWithMessageConverters(returnValue, returnType, inputMessage, outputMessage);
+}
+```
+
+- `<1>` 处，设置 `mavContainer` 已处理。
+- `<2>` 处，创建请求和响应。
+- `<3>` 处，调用父类 AbstractMessageConverterMethodProcessor 的 `#writeWithMessageConverters(returnValue, returnType, inputMessage, outputMessage)` 方法，使用 HttpMessageConverter 对对象进行转换，并写入到响应。详细解析，见 [「5.4.1 writeWithMessageConverters」](https://svip.iocoder.cn/Spring-MVC/HandlerAdapter-4-HandlerMethodReturnValueHandler/#) 。
+
+### 5.4.1 writeWithMessageConverters
+
+> 该方法，是 AbstractMessageConverterMethodProcessor 中提供。
+
+`#writeWithMessageConverters(returnValue, returnType, inputMessage, outputMessage)` 方法，使用 HttpMessageConverter 对对象进行转换，并写入到响应。代码如下：
+
+```
+// AbstractMessageConverterMethodProcessor.java
+
+protected <T> void writeWithMessageConverters(@Nullable T value, MethodParameter returnType,
+        ServletServerHttpRequest inputMessage, ServletServerHttpResponse outputMessage)
+        throws IOException, HttpMediaTypeNotAcceptableException, HttpMessageNotWritableException {
+
+    // <1> 获得 body、valueType、targetType
+    Object body;
+    Class<?> valueType;
+    Type targetType;
+    if (value instanceof CharSequence) {
+        body = value.toString();
+        valueType = String.class;
+        targetType = String.class;
+    } else {
+        body = value;
+        valueType = getReturnValueType(body, returnType);
+        targetType = GenericTypeResolver.resolveType(getGenericType(returnType), returnType.getContainingClass());
+    }
+
+    // <2> 是否为 Resource 类型。暂时无视，实际暂时没用到
+    if (isResourceType(value, returnType)) {
+        outputMessage.getHeaders().set(HttpHeaders.ACCEPT_RANGES, "bytes");
+        if (value != null && inputMessage.getHeaders().getFirst(HttpHeaders.RANGE) != null &&
+                outputMessage.getServletResponse().getStatus() == 200) {
+            Resource resource = (Resource) value;
+            try {
+                List<HttpRange> httpRanges = inputMessage.getHeaders().getRange();
+                outputMessage.getServletResponse().setStatus(HttpStatus.PARTIAL_CONTENT.value());
+                body = HttpRange.toResourceRegions(httpRanges, resource);
+                valueType = body.getClass();
+                targetType = RESOURCE_REGION_LIST_TYPE;
+            } catch (IllegalArgumentException ex) {
+                outputMessage.getHeaders().set(HttpHeaders.CONTENT_RANGE, "bytes */" + resource.contentLength());
+                outputMessage.getServletResponse().setStatus(HttpStatus.REQUESTED_RANGE_NOT_SATISFIABLE.value());
+            }
+        }
+    }
+
+    // <3> 选择使用的 MediaType
+    MediaType selectedMediaType = null;
+    // <3.1> 获得响应中的 ContentType 的值
+    MediaType contentType = outputMessage.getHeaders().getContentType();
+    // <3.1.1> 如果存在 ContentType 的值，并且不包含通配符，则使用它作为 selectedMediaType
+    if (contentType != null && contentType.isConcrete()) {
+        if (logger.isDebugEnabled()) {
+            logger.debug("Found 'Content-Type:" + contentType + "' in response");
+        }
+        selectedMediaType = contentType;
+    } else {
+        HttpServletRequest request = inputMessage.getServletRequest();
+        // <3.2.1> 从请求中，获得可接受的 MediaType 数组。默认实现是，从请求头 ACCEPT 中获取
+        List<MediaType> acceptableTypes = getAcceptableMediaTypes(request);
+        // <3.2.2> 获得可产生的 MediaType 数组
+        List<MediaType> producibleTypes = getProducibleMediaTypes(request, valueType, targetType);
+        // <3.2.3> 如果 body 非空，并且无可产生的 MediaType 数组，则抛出 HttpMediaTypeNotAcceptableException 异常
+        if (body != null && producibleTypes.isEmpty()) {
+            throw new HttpMessageNotWritableException(
+                    "No converter found for return value of type: " + valueType);
+        }
+
+        // <3.2.4> 通过 acceptableTypes 来比对，将符合的 producibleType 添加到 mediaTypesToUse 结果数组中
+        List<MediaType> mediaTypesToUse = new ArrayList<>();
+        for (MediaType requestedType : acceptableTypes) {
+            for (MediaType producibleType : producibleTypes) {
+                if (requestedType.isCompatibleWith(producibleType)) {
+                    mediaTypesToUse.add(getMostSpecificMediaType(requestedType, producibleType));
+                }
+            }
+        }
+        // <3.2.5> 如果没有符合的，并且 body 非空，则抛出 HttpMediaTypeNotAcceptableException 异常
+        if (mediaTypesToUse.isEmpty()) {
+            if (body != null) {
+                throw new HttpMediaTypeNotAcceptableException(producibleTypes);
+            }
+            if (logger.isDebugEnabled()) {
+                logger.debug("No match for " + acceptableTypes + ", supported: " + producibleTypes);
+            }
+            return;
+        }
+
+        // <3.2.6> 按照 MediaType 的 specificity 和 quality 排序
+        MediaType.sortBySpecificityAndQuality(mediaTypesToUse);
+
+        // <3.2.7> 选择其中一个最匹配的，主要考虑不包含通配符的。例如 application/json;q=0.8 。
+        for (MediaType mediaType : mediaTypesToUse) {
+            if (mediaType.isConcrete()) {
+                selectedMediaType = mediaType;
+                break;
+            } else if (mediaType.equals(MediaType.ALL) || mediaType.equals(MEDIA_TYPE_APPLICATION)) {
+                selectedMediaType = MediaType.APPLICATION_OCTET_STREAM;
+                break;
+            }
+        }
+
+        if (logger.isDebugEnabled()) {
+            logger.debug("Using '" + selectedMediaType + "', given " +
+                    acceptableTypes + " and supported " + producibleTypes);
+        }
+    }
+
+    // <4> 如果匹配到，则进行写入逻辑
+    if (selectedMediaType != null) {
+        // <4.1> 移除 quality 。例如，application/json;q=0.8 移除后为 application/json 。
+        selectedMediaType = selectedMediaType.removeQualityValue();
+        // <4.2> 遍历 messageConverters 数组，
+        for (HttpMessageConverter<?> converter : this.messageConverters) {
+            // <4.3> 判断 HttpMessageConverter 是否支持转换目标类型
+            GenericHttpMessageConverter genericConverter = (converter instanceof GenericHttpMessageConverter ?
+                    (GenericHttpMessageConverter<?>) converter : null);
+            if (genericConverter != null ?
+                    ((GenericHttpMessageConverter) converter).canWrite(targetType, valueType, selectedMediaType) :
+                    converter.canWrite(valueType, selectedMediaType)) {
+                // <5.1> 如果有 RequestResponseBodyAdvice ，则可以对返回的结果，做修改。
+                body = getAdvice().beforeBodyWrite(body, returnType, selectedMediaType,
+                        (Class<? extends HttpMessageConverter<?>>) converter.getClass(),
+                        inputMessage, outputMessage);
+                // <5.2> body 非空，则进行写入
+                if (body != null) {
+                    // 打印日志
+                    final Object theBody = body; // 这个变量的用途是，打印是匿名类，需要有 final
+                    LogFormatUtils.traceDebug(logger, traceOn ->
+                            "Writing [" + LogFormatUtils.formatValue(theBody, traceOn) + "]");
+                    // 添加 CONTENT_DISPOSITION 头。一般情况下用不到，暂时忽略
+                    addContentDispositionHeader(inputMessage, outputMessage);
+                    // <5.3> 写入内容
+                    if (genericConverter != null) {
+                        genericConverter.write(body, targetType, selectedMediaType, outputMessage);
+                    } else {
+                        ((HttpMessageConverter) converter).write(body, selectedMediaType, outputMessage);
+                    }
+                } else {
+                    if (logger.isDebugEnabled()) {
+                        logger.debug("Nothing to write: null body");
+                    }
+                }
+                // <5.4> return 返回。结果整个逻辑
+                return;
+            }
+        }
+    }
+
+    // <6> 如果到达此处，并且 body 非空，说明没有匹配的 HttpMessageConverter 转换器，则抛出 HttpMediaTypeNotAcceptableException 异常
+    if (body != null) {
+        throw new HttpMediaTypeNotAcceptableException(this.allSupportedMediaTypes);
+    }
+}
+```
+
+- 怎么说呢？这个方法逻辑非常多。但是实际上，核心逻辑非常简单：
+
+  - 1、获得响应使用的 MediaType 对象。
+  - 2、获得响应结果和 Media 对象获得对应的 HttpMessageConverter 对象。
+  - 3、使用 HttpMessageConverter 将响应结果进行转化，写入到响应中。
+
+- `<1>` 处，获得 `body`、`valueType`、`targetType` 。例如上面提供的示例，这三个值分别是，`users` 数组、ArrayList、User 。
+
+- `<2>` 处，调用 `#isResourceType(Object value, MethodParameter returnType)` 方法，判断是否为 Resource 类型。代码如下：
+
+  ```
+  // AbstractMessageConverterMethodProcessor.java
+  
+  protected boolean isResourceType(@Nullable Object value, MethodParameter returnType) {
+  	Class<?> clazz = getReturnValueType(value, returnType);
+  	return clazz != InputStreamResource.class && Resource.class.isAssignableFrom(clazz);
+  }
+  ```
+
+  - 因为我们实际使用时，不会返回 Resource 类型，所以暂时无视这个块逻辑。
+
+- ========== 第一步 ==========
+
+- `<3>` 处，选择使用的 MediaType 对象。
+
+- `<3.1>` 处，获得响应中的 ContentType 的值。
+
+- `<3.1.1>` 处，如果存在 ContentType 的值，并且不包含通配符，则使用它作为 `selectedMediaType` 。目前调试下来，`<3.1>` 处，返回的都是 `null` 。所以此处的逻辑，可以无视。😈 暂时不知道，什么情况下返回的是非 `null` 。
+
+- `<3.2.1>` 处，调用 `#getAcceptableMediaTypes(HttpServletRequest request)` 方法，从请求中，获得可接受的 MediaType 数组。默认实现是，从请求头 `"ACCEPT"` 中获取。关于这个方法，比较简单，胖友自己去瞅瞅，重点实现在 `org.springframework.web.accept.HeaderContentNegotiationStrategy` 类中。
+
+- `<3.2.2>` 处，调用 `#getProducibleMediaTypes(HttpServletRequest request, Class<?> valueClass, Type targetType)` 方法，获得可产生的 MediaType 数组。代码如下：
+
+  ```
+  // AbstractMessageConverterMethodProcessor.java
+  
+  protected List<MediaType> getProducibleMediaTypes(
+          HttpServletRequest request, Class<?> valueClass, @Nullable Type targetType) {
+      // 先从请求 PRODUCIBLE_MEDIA_TYPES_ATTRIBUTE 属性种获得。该属性的来源是 @RequestMapping(producer = xxx) 。
+      Set<MediaType> mediaTypes =
+              (Set<MediaType>) request.getAttribute(HandlerMapping.PRODUCIBLE_MEDIA_TYPES_ATTRIBUTE);
+      // 如果非空，则使用该属性
+      if (!CollectionUtils.isEmpty(mediaTypes)) {
+          return new ArrayList<>(mediaTypes);
+      // <x> 如果 allSupportedMediaTypes 非空，则遍历 HttpMessageConverter 数组，进行类型匹配
+      } else if (!this.allSupportedMediaTypes.isEmpty()) {
+          List<MediaType> result = new ArrayList<>();
+          for (HttpMessageConverter<?> converter : this.messageConverters) {
+              if (converter instanceof GenericHttpMessageConverter && targetType != null) {
+                  if (((GenericHttpMessageConverter<?>) converter).canWrite(targetType, valueClass, null)) {
+                      result.addAll(converter.getSupportedMediaTypes());
+                  }
+              } else if (converter.canWrite(valueClass, null)) {
+                  result.addAll(converter.getSupportedMediaTypes());
+              }
+          }
+          return result;
+      // 其它，则返回 MediaType.ALL
+      } else {
+          return Collections.singletonList(MediaType.ALL);
+      }
+  }
+  ```
+
+  - 逻辑比较简单，胖友自己瞅瞅。重点在 `<x>` 处。
+
+- `<3.2.3>` 处，如果 `body` 非空，并且无可产生的 MediaType 数组，则抛出 HttpMediaTypeNotAcceptableException 异常。
+
+- 【重要】`<3.2.4>` 处，通过 `acceptableTypes` 来比对，将符合的 `producibleType` 添加到 `mediaTypesToUse` 结果数组中。
+
+- `<3.2.5>` 处，如果没有符合的，并且 `body` 非空，则抛出 HttpMediaTypeNotAcceptableException 异常。
+
+- 【重要】`<3.2.6>` 处，按照 MediaType 的 specificity 和 quality 排序。
+
+- 【重要】`<3.2.7>` 处，选择其中一个最匹配的，主要考虑不包含通配符的。例如 `application/json;q=0.8` 。
+
+- ========== 第二步 + 第三步 ==========
+
+- `<4>` 处，如果匹配到，则进行写入逻辑。
+
+- `<4.1>` 处，移除 `quality` 。例如，`application/json;q=0.8` 移除后为 `application/json` 。
+
+- `<4.2>` 处，遍历 `messageConverters` 数组。关于 `messageConverters` 的定义，代码如下：
+
+  ```
+  // AbstractMessageConverterMethodProcessor.java
+  
+  /**
+   * HttpMessageConverter 数组
+   */
+  protected final List<HttpMessageConverter<?>> messageConverters;
+  ```
+
+- `<4.3>` 处，判断 HttpMessageConverter 是否支持转换目标类型。
+
+- `<5.1>` 处，如果有 RequestResponseBodyAdvice ，则可以对返回的结果，做修改。关于 RequestResponseBodyAdvice 的定义，代码如下：
+
+  ```
+  // AbstractMessageConverterMethodProcessor.java
+  
+  /**
+   * RequestResponseBodyAdviceChain 对象
+   */
+  private final RequestResponseBodyAdviceChain advice;
+  
+  // 构造方法中
+  this.advice = new RequestResponseBodyAdviceChain(requestResponseBodyAdvice);
+  ```
+
+  - 关于 RequestResponseBodyAdviceChain 类，本文暂时不去做详细解析，胖友先自己去研究下。
+
+- `<5.2>` 处，`body` 非空，则进行写入。
+
+- 【重要】`<5.3>` 处，写入内容。
+
+- `<5.4>` 处，`return` 返回。结束整个逻辑。
+
+- `<6>` 处，如果到达此处，并且 `body` 非空，说明没有匹配的 HttpMessageConverter 转换器，则抛出 HttpMediaTypeNotAcceptableException 异常。
+
+------
+
+至此，整个逻辑已经解析完成。在日常使用 Spring MVC 中，我们经常碰到的组件的**调用**，应该要有一个比较好的理解。如果没有，在多多调试。特别是：
+
+- 1、HttpMessageConverter
+- 2、RequestResponseBodyAdviceChain
+
+# 6. ViewNameMethodReturnValueHandler
+
+`org.springframework.web.servlet.mvc.method.annotation.ViewNameMethodReturnValueHandler` ，实现 HandlerMethodReturnValueHandler 接口，处理返回结果是视图名的 ReturnValueHandler 实现类。
+
+ViewNameMethodReturnValueHandler 适用于前后端未分离，Controller 返回视图名的场景，例如 JSP、Freemarker 等等。
+
+## 6.1 构造方法
+
+```
+// ViewNameMethodReturnValueHandler.java
+
+/**
+ * 重定向的表达式的数组
+ */
+@Nullable
+private String[] redirectPatterns;
+```
+
+- `redirectPatterns` 属性，一般情况下，不进行设置。至于用途，我们来看看 `#isRedirectViewName(String viewName)` 方法，判断是否为重定向的视图名。代码如下：
+
+  ```
+  // ViewNameMethodReturnValueHandler.java
+  
+  protected boolean isRedirectViewName(String viewName) {
+  	return (PatternMatchUtils.simpleMatch(this.redirectPatterns, viewName) // 符合 redirectPatterns 表达式
+              || viewName.startsWith("redirect:")); // 以 redirect: 开头
+  }
+  ```
+
+  - 😈 是不是明白落？是不是也弄清楚，为什么 `"redirect:"` 开头，就是重定向的视图。
+
+## 6.2 supportsReturnType
+
+实现 `#supportsReturnType(MethodParameter returnType)` 方法，判断返回值类型是否为 `void` 或者字符串。代码如下：
+
+```
+// ViewNameMethodReturnValueHandler.java
+
+@Override
+public boolean supportsReturnType(MethodParameter returnType) {
+	Class<?> paramType = returnType.getParameterType();
+	return (void.class == paramType || CharSequence.class.isAssignableFrom(paramType));
+}
+```
+
+- 那么有胖友就会有疑惑？如果想要使用 [「5. RequestResponseBodyMethodProcessor」](https://svip.iocoder.cn/Spring-MVC/HandlerAdapter-4-HandlerMethodReturnValueHandler/#) ，结果返回 String 类型的结果，岂不是被 ViewNameMethodReturnValueHandler ？在回到 [传送门](https://github.com/spring-projects/spring-framework/blob/master/spring-webmvc/src/main/java/org/springframework/web/servlet/mvc/method/annotation/RequestMappingHandlerAdapter.java#L717-L761) 再瞅瞅，RequestResponseBodyMethodProcessor 的添加在 ViewNameMethodReturnValueHandler 之前，所以不会有这样的问题。
+
+## 6.3 handleReturnValue
+
+实现 `#handleReturnValue(Object returnValue, MethodParameter returnType, ModelAndViewContainer mavContainer, NativeWebRequest webRequest)` 方法，代码如下：
+
+```
+// ViewNameMethodReturnValueHandler.java
+
+@Override
+public void handleReturnValue(@Nullable Object returnValue, MethodParameter returnType,
+        ModelAndViewContainer mavContainer, NativeWebRequest webRequest) throws Exception {
+    // 如果是 String 类型
+    if (returnValue instanceof CharSequence) {
+        // 设置视图名到 mavContainer 中
+        String viewName = returnValue.toString();
+        mavContainer.setViewName(viewName);
+        // 如果是重定向，则标记到 mavContainer 中
+        if (isRedirectViewName(viewName)) {
+            mavContainer.setRedirectModelScenario(true);
+        }
+    // 如果是非 String 类型，而且非 void ，则抛出 UnsupportedOperationException 异常
+    } else if (returnValue != null){
+        // should not happen
+        throw new UnsupportedOperationException("Unexpected return type: " +
+                returnType.getParameterType().getName() + " in method: " + returnType.getMethod());
+    }
+}
+```
+
+- `<1>` 处，设置视图名到 `mavContainer` 中。
+- `<2>` 处，如果是重定向，则标记到 `mavContainer` 中的 `redirectModelScenario` 属性中。
+- 注意噢，胖友是否有发现，此时 `redirectModelScenario` 的 `requestHandled` 属性，并未并未像 [「5. RequestResponseBodyMethodProcessor」](https://svip.iocoder.cn/Spring-MVC/HandlerAdapter-4-HandlerMethodReturnValueHandler/#) 一样，设置为 `true` 。这是为什么呢？因为**返回结果是视图名**的场景下，会使用 ViewResolver 解析出其对应的视图 View 对象，然后执行 `View#render(Map<String, ?> model, HttpServletRequest request, HttpServletResponse response)` 方法，进行渲染。
+
+# 666. 彩蛋
+
+感觉，还有一些需要写的 HandlerMethodReturnValueHandler 实现类，暂时还没想好。
+
+如果胖友有什么 HandlerMethodReturnValueHandler 实现类，希望艿艿来写，请在星球给我留言。TODO 9999 HandlerMethodReturnValueHandler
+
+参考和推荐如下文章：
+
+- 韩路彪 [《看透 Spring MVC：源代码分析与实践》](https://item.jd.com/11807414.html) 的 [「第 13.8 HandlerMethodReturnValueHandler」](https://svip.iocoder.cn/Spring-MVC/HandlerAdapter-4-HandlerMethodReturnValueHandler/#) 小节
\ No newline at end of file
diff --git a/springmvc/18-Spring MVC 源码解析-HandlerAdapter 组件（五）之 HttpMessageConverter.assets/01.png b/springmvc/18-Spring MVC 源码解析-HandlerAdapter 组件（五）之 HttpMessageConverter.assets/01.png
new file mode 100644
index 0000000..51e9222
Binary files /dev/null and b/springmvc/18-Spring MVC 源码解析-HandlerAdapter 组件（五）之 HttpMessageConverter.assets/01.png differ
diff --git a/springmvc/18-Spring MVC 源码解析-HandlerAdapter 组件（五）之 HttpMessageConverter.assets/091627_zgNV_118997.png b/springmvc/18-Spring MVC 源码解析-HandlerAdapter 组件（五）之 HttpMessageConverter.assets/091627_zgNV_118997.png
new file mode 100644
index 0000000..22cc77b
Binary files /dev/null and b/springmvc/18-Spring MVC 源码解析-HandlerAdapter 组件（五）之 HttpMessageConverter.assets/091627_zgNV_118997.png differ
diff --git a/springmvc/18-Spring MVC 源码解析-HandlerAdapter 组件（五）之 HttpMessageConverter.md b/springmvc/18-Spring MVC 源码解析-HandlerAdapter 组件（五）之 HttpMessageConverter.md
new file mode 100644
index 0000000..f762f6a
--- /dev/null
+++ b/springmvc/18-Spring MVC 源码解析-HandlerAdapter 组件（五）之 HttpMessageConverter.md	
@@ -0,0 +1,212 @@
+# 精尽 Spring MVC 源码解析 —— HandlerAdapter 组件（五）之 HttpMessageConverter
+
+# 1. 概述
+
+> 😈 因为想偷懒，所以…
+>
+> 这里艿艿就转载 相见欢 的 [《Spring MVC 源码剖析（五） —— 消息转换器 HttpMessageConverter》](https://my.oschina.net/lichhao/blog/172562) 。
+
+在 Spring MVC 中，可以使用 `@RequestBody` 和 `@ResponseBody` 两个注解，分别完成请求报文到对象和对象到响应报文的转换，底层这种灵活的消息转换机制，就是Spring 3.x 中新引入的 HttpMessageConverter ，即消息转换器机制。
+
+Http 请求的抽象，还是回到请求-响应，也就是解析请求体，然后返回响应报文这个最基本的 Http 请求过程中来。我们知道，在 Servlet 标准中，可以用`javax.servlet.ServletRequest` 接口中的以下方法：
+
+```
+public ServletInputStream getInputStream() throws IOException;
+```
+
+来得到一个ServletInputStream。这个 ServletInputStream 中，可以读取到一个原始请求报文的所有内容。同样的，在 `javax.servlet.ServletResponse` 接口中，可以用以下方法：
+
+```
+public ServletOutputStream getOutputStream() throws IOException;
+```
+
+来得到一个 ServletOutputStream 。这个 ServletOutputSteam ，继承自 java 中的OutputStream，可以让你输出 Http 的响应报文内容。
+
+让我们尝试着像 SpringMVC 的设计者一样来思考一下。我们知道，Http 请求和响应报文本质上都是一串字符串，当请求报文来到 java 世界，它会被封装成为一个 ServletInputStream 的输入流，供我们读取报文。响应报文则是通过一个 ServletOutputStream 的输出流，来输出响应报文。
+
+我们从流中，只能读取到原始的字符串报文，同样，我们往输出流中，也只能写原始的字符。而在 Java 世界中，处理业务逻辑，都是以一个个有业务意义的**对象**为处理维度的，那么在报文到达 Spring MVC 和从 Spring MVC 出去，都存在一个字符串到 Java 对象的阻抗问题。这一过程，不可能由开发者手工转换。我们知道，在 Struts2 中，采用了 OGNL 来应对这个问题，而在 SpringMVC 中，它是 HttpMessageConverter机 制。我们先来看 HttpInputMessage 和 HttpOutputMessage两个接口。
+
+# 2. HttpInputMessage
+
+这个类是 Spring MVC 内部对一次 Http 请求报文的抽象，在 HttpMessageConverter 的 `read(...)` 方法中，有一个 HttpInputMessage 的形参，它正是 Spring MVC 的消息转换器所作用的受体“请求消息”的内部抽象，消息转换器从“请求消息”中按照规则提取消息，转换为方法形参中声明的对象。
+
+```
+package org.springframework.http;
+
+import java.io.IOException;
+import java.io.InputStream;
+
+public interface HttpInputMessage extends HttpMessage {
+
+	InputStream getBody() throws IOException;
+
+}
+```
+
+# 3. HttpOutputMessage
+
+这个类是 Spring MVC 内部对一次 Http 响应报文的抽象，在 HttpMessageConverter 的 `#write(...)` 方法中，有一个 HttpOutputMessage 的形参，它正是 Spring MVC 的消息转换器所作用的受体“响应消息”的内部抽象，消息转换器将“响应消息”按照一定的规则写到响应报文中。
+
+```
+package org.springframework.http;
+
+import java.io.IOException;
+import java.io.OutputStream;
+
+public interface HttpOutputMessage extends HttpMessage {
+
+	OutputStream getBody() throws IOException;
+
+}
+```
+
+# 4. HttpMessageConverter
+
+对消息转换器最高层次的接口抽象，描述了一个消息转换器的一般特征，我们可以从这个接口中定义的方法，来领悟Spring3.x的设计者对这一机制的思考过程。
+
+```
+package org.springframework.http.converter;
+
+import java.io.IOException;
+import java.util.List;
+
+import org.springframework.http.HttpInputMessage;
+import org.springframework.http.HttpOutputMessage;
+import org.springframework.http.MediaType;
+
+public interface HttpMessageConverter<T> {
+
+	boolean canRead(Class<?> clazz, MediaType mediaType);
+
+	boolean canWrite(Class<?> clazz, MediaType mediaType);
+
+	List<MediaType> getSupportedMediaTypes();
+
+	T read(Class<? extends T> clazz, HttpInputMessage inputMessage)
+			throws IOException, HttpMessageNotReadableException;
+
+	void write(T t, MediaType contentType, HttpOutputMessage outputMessage)
+			throws IOException, HttpMessageNotWritableException;
+
+}
+```
+
+HttpMessageConverter接口的定义出现了成对的 `canRead(...)` + `#read(...)` 和 `#canWrite(...)` + `#write(...)` 方法。而 MediaType 是对请求的 Media Type 属性的封装。举个例子，当我们声明了下面这个处理方法。
+
+```
+@RequestMapping(value = "/string", method = RequestMethod.POST)
+public @ResponseBody String readString(@RequestBody String string) {
+    return "Read string '" + string + "'";
+}
+```
+
+在 SpringMVC 进入 `#readString(...)` 方法前，会根据 `@RequestBody` 注解选择适当的 HttpMessageConverter 实现类来将请求参数解析到 `string` 变量中，具体来说是使用了 StringHttpMessageConverter 类，它的 `#canRead(...)` 方法返回 `true`，然后它的 `#read(...)` 方法会从请求中读出请求参数，绑定到 `#readString(@RequestBody String string)` 方法的 `string` 变量中。
+
+当 Spring MVC 执行 `#readString(@RequestBody String string)` 方法后，由于返回值标识了 `@ResponseBody` 注解，Spring MVC 将使用 StringHttpMessageConverter 的 `#write(...)` 方法，将结果作为 String 值写入响应报文，当然，此时 `#canWrite(....)` 方法返回 `true` 。
+
+我们可以用下面的图，简单描述一下这个过程。
+
+[![消息转换图](18-Spring MVC 源码解析-HandlerAdapter 组件（五）之 HttpMessageConverter.assets/091627_zgNV_118997.png)](http://static.iocoder.cn/oschina/uploads/space/2013/1026/091627_zgNV_118997.png)消息转换图
+
+# 5. RequestResponseBodyMethodProcessor
+
+将上述过程集中描述的一个类是 `org.springframework.web.servlet.mvc.method.annotation.RequestResponseBodyMethodProcessor` ，这个类同时实现了 HandlerMethodArgumentResolver 和 HandlerMethodReturnValueHandler 两个接口。前者是将请求报文绑定到处理方法形参的策略接口，后者则是对处理方法返回值进行处理的策略接口。两个接口的源码如下：
+
+```
+// HandlerMethodArgumentResolver.java
+
+public interface HandlerMethodArgumentResolver {
+
+	boolean supportsParameter(MethodParameter parameter);
+
+	Object resolveArgument(MethodParameter parameter,
+						   ModelAndViewContainer mavContainer,
+						   NativeWebRequest webRequest,
+						   WebDataBinderFactory binderFactory) throws Exception;
+}
+
+// HandlerMethodReturnValueHandler.java
+
+public interface HandlerMethodReturnValueHandler {
+
+	boolean supportsReturnType(MethodParameter returnType);
+
+	void handleReturnValue(Object returnValue,
+						   MethodParameter returnType,
+						   ModelAndViewContainer mavContainer,
+						   NativeWebRequest webRequest) throws Exception;
+}
+```
+
+RequestResponseBodyMethodProcessor 这个类，同时充当了方法参数解析和返回值处理两种角色。我们从它的源码中，可以找到上面两个接口的方法实现。
+
+对 HandlerMethodArgumentResolver 接口的实现：
+
+```
+// RequestResponseBodyMethodProcessor.java
+
+public boolean supportsParameter(MethodParameter parameter) {
+	return parameter.hasParameterAnnotation(RequestBody.class);
+}
+
+public Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer,
+		NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception {
+
+	Object argument = readWithMessageConverters(webRequest, parameter, parameter.getGenericParameterType());
+
+	String name = Conventions.getVariableNameForParameter(parameter);
+	WebDataBinder binder = binderFactory.createBinder(webRequest, argument, name);
+
+	if (argument != null) {
+		validate(binder, parameter);
+	}
+
+	mavContainer.addAttribute(BindingResult.MODEL_KEY_PREFIX + name, binder.getBindingResult());
+
+	return argument;
+}
+```
+
+对 HandlerMethodReturnValueHandler 接口的实现
+
+```
+// RequestResponseBodyMethodProcessor.java
+
+public boolean supportsReturnType(MethodParameter returnType) {
+	return returnType.getMethodAnnotation(ResponseBody.class) != null;
+}
+
+public void handleReturnValue(Object returnValue, MethodParameter returnType,
+		ModelAndViewContainer mavContainer, NativeWebRequest webRequest)
+		throws IOException, HttpMediaTypeNotAcceptableException {
+
+	mavContainer.setRequestHandled(true);
+	if (returnValue != null) {
+		writeWithMessageConverters(returnValue, returnType, webRequest);
+	}
+}
+```
+
+看完上面的代码，整个 HttpMessageConverter 消息转换的脉络已经非常清晰。因为两个接口的实现，分别是以是否有 `@RequestBody` 和 `@ResponseBody` 为条件，然后分别调用 HttpMessageConverter 来进行消息的读写。
+
+# 6. 思考
+
+张小龙在谈微信的本质时候说：“微信只是个平台，消息在其中流转”。在我们对 Spring MVC 源码分析的过程中，我们可以从 HttpMessageConverter 机制中领悟到类似的道理。在Spring MVC 的设计者眼中，一次请求报文和一次响应报文，分别被抽象为一个请求消息HttpInputMessage 和一个响应消息 HttpOutputMessage 。
+
+处理请求时，由合适的消息转换器将请求报文绑定为方法中的形参对象，在这里，同一个对象就有可能出现多种不同的消息形式，比如 json 和 xml 。同样，当响应请求时，方法的返回值也同样可能被返回为不同的消息形式，比如 json 和 xml 。
+
+在 Spring MVC 中，针对不同的消息形式，我们有不同的 HttpMessageConverter 实现类来处理各种消息形式。但是，只要这些消息所蕴含的“有效信息”是一致的，那么各种不同的消息转换器，都会生成同样的转换结果。至于各种消息间解析细节的不同，就被屏蔽在不同的 HttpMessageConverter 实现类中了。
+
+# 7. 补充
+
+> 艿艿默默补充一波，其实是给胖友布置了下作业。
+
+HttpMessageConverter 的整体类图如下：[![HttpMessageConverter](18-Spring MVC 源码解析-HandlerAdapter 组件（五）之 HttpMessageConverter.assets/01.png)](http://static.iocoder.cn/images/Spring/2022-04-01/01.png)HttpMessageConverter
+
+- 实现类还是比较多的，所以胖友要根据自己的需要，进行调试。
+
+胖友可以看看 MappingJackson2HttpMessageConverter 类，Spring MVC 提供的默认的 JSON 消息格式的转换器。
+
+如果胖友想要使用 Fastjson 作为 JSON 的工具类，可以看看 `com.alibaba.fastjson.support.spring.FastJsonHttpMessageConverter` 类，和 [《在 Spring 中集成 Fastjson》](https://github.com/alibaba/fastjson/wiki/在-Spring-中集成-Fastjson) 一文。
+
+😈 完美偷懒成功，嘻嘻。
\ No newline at end of file
diff --git a/springmvc/19-Spring MVC 源码解析-HandlerExceptionResolver 组件.assets/01.png b/springmvc/19-Spring MVC 源码解析-HandlerExceptionResolver 组件.assets/01.png
new file mode 100644
index 0000000..25f550f
Binary files /dev/null and b/springmvc/19-Spring MVC 源码解析-HandlerExceptionResolver 组件.assets/01.png differ
diff --git a/springmvc/19-Spring MVC 源码解析-HandlerExceptionResolver 组件.md b/springmvc/19-Spring MVC 源码解析-HandlerExceptionResolver 组件.md
new file mode 100644
index 0000000..6a79540
--- /dev/null
+++ b/springmvc/19-Spring MVC 源码解析-HandlerExceptionResolver 组件.md	
@@ -0,0 +1,1443 @@
+# 精尽 Spring MVC 源码解析 —— HandlerExceptionResolver 组件
+
+# 1. 概述
+
+本文，我们来分享 HandlerExceptionResolver 组件。在 [《精尽 Spring MVC 源码分析 —— 组件一览》](http://svip.iocoder.cn/Spring-MVC/Components-intro) 中，我们对它已经做了介绍：
+
+`org.springframework.web.servlet.HandlerExceptionResolver` ，处理器异常解析器接口，将处理器( `handler` )执行时发生的异常，解析( 转换 )成对应的 ModelAndView 结果。代码如下：
+
+```
+// HandlerExceptionResolver.java
+
+public interface HandlerExceptionResolver {
+
+    /**
+     * 解析异常，转换成对应的 ModelAndView 结果
+     */
+    @Nullable
+    ModelAndView resolveException(
+            HttpServletRequest request, HttpServletResponse response, @Nullable Object handler, Exception ex);
+
+}
+```
+
+- 也就是说，如果异常被**解析成功**，则会返回 ModelAndView 对象。
+
+# 2. 类图
+
+HandlerExceptionResolver 的类图如下：
+
+[![类图](19-Spring MVC 源码解析-HandlerExceptionResolver 组件.assets/01.png)](http://static.iocoder.cn/images/Spring/2022-06-01/01.png)类图
+
+# 3. 初始化
+
+仔细一瞅，类还是不少的哈。我们以**默认配置的 Spring Boot 场景**下为例，来一起看看 DispatcherServlet 的 `#initHandlerExceptionResolvers(ApplicationContext context)` 方法，初始化 `handlerExceptionResolvers` 变量。代码如下：
+
+```
+// DispatcherServlet.java
+
+/** Detect all HandlerExceptionResolvers or just expect "handlerExceptionResolver" bean?. */
+private boolean detectAllHandlerExceptionResolvers = true;
+    
+@Nullable
+private List<HandlerExceptionResolver> handlerExceptionResolvers;
+
+private void initHandlerExceptionResolvers(ApplicationContext context) {
+    // 置空 handlerExceptionResolvers 处理
+    this.handlerExceptionResolvers = null;
+
+    // 情况一，自动扫描 HandlerExceptionResolver 类型的 Bean 们
+    if (this.detectAllHandlerExceptionResolvers) {
+        // Find all HandlerExceptionResolvers in the ApplicationContext, including ancestor contexts.
+        Map<String, HandlerExceptionResolver> matchingBeans = BeanFactoryUtils
+                .beansOfTypeIncludingAncestors(context, HandlerExceptionResolver.class, true, false);
+        if (!matchingBeans.isEmpty()) {
+            this.handlerExceptionResolvers = new ArrayList<>(matchingBeans.values());
+            // We keep HandlerExceptionResolvers in sorted order.
+            AnnotationAwareOrderComparator.sort(this.handlerExceptionResolvers);
+        }
+    // 情况二，获得名字为 HANDLER_EXCEPTION_RESOLVER_BEAN_NAME 的 Bean 们
+    } else {
+        try {
+            HandlerExceptionResolver her =
+                    context.getBean(HANDLER_EXCEPTION_RESOLVER_BEAN_NAME, HandlerExceptionResolver.class);
+            this.handlerExceptionResolvers = Collections.singletonList(her);
+        } catch (NoSuchBeanDefinitionException ex) {
+            // Ignore, no HandlerExceptionResolver is fine too.
+        }
+    }
+
+    // Ensure we have at least some HandlerExceptionResolvers, by registering
+    // default HandlerExceptionResolvers if no other resolvers are found.
+    // 情况三，如果未获得到，则获得默认配置的 HandlerExceptionResolver 类
+    if (this.handlerExceptionResolvers == null) {
+        this.handlerExceptionResolvers = getDefaultStrategies(context, HandlerExceptionResolver.class);
+        if (logger.isTraceEnabled()) {
+            logger.trace("No HandlerExceptionResolvers declared in servlet '" + getServletName() +
+                    "': using default strategies from DispatcherServlet.properties");
+        }
+    }
+}
+```
+
+- 一共有三种情况，初始化 `handlerExceptionResolvers` 属性。
+
+- 默认情况下，
+
+  ```
+  detectAllHandlerExceptionResolvers
+  ```
+
+   
+
+  为
+
+   
+
+  ```
+  true
+  ```
+
+   
+
+  ，所以走
+
+  情况一
+
+  的逻辑，自动扫描 HandlerExceptionResolver 类型的 Bean 们。在
+
+  默认配置的 Spring Boot 场景
+
+  下，
+
+  ```
+  handlerExceptionResolvers
+  ```
+
+   
+
+  的结果是：
+
+  - `org.springframework.boot.autoconfigure.web.DefaultErrorAttributes`
+  - HandlerExceptionResolverComposite
+
+所以，我们可以先忽略掉 SpringBoot 中实现的 DefaultErrorAttributes 类，而来到 [「4. HandlerExceptionResolverComposite」](https://svip.iocoder.cn/Spring-MVC/HandlerExceptionResolver/#) 中。
+
+> 艿艿：DefaultErrorAttributes 的代码逻辑非常简单，并且是相对“酱油”的逻辑，胖友自己去瞅瞅即可。
+
+# 4. HandlerExceptionResolverComposite
+
+`org.springframework.web.servlet.handler.HandlerExceptionResolverComposite` ，实现 HandlerExceptionResolver、Ordered 接口，复合的 HandlerExceptionResolver 实现类。
+
+## 4.1 构造方法
+
+```
+// HandlerExceptionResolverComposite.java
+
+/**
+ * resolvers 数组
+ */
+@Nullable
+private List<HandlerExceptionResolver> resolvers;
+
+/**
+ * 优先级，最低
+ */
+private int order = Ordered.LOWEST_PRECEDENCE;
+```
+
+那么，还是让我们来看看，在**默认配置的 Spring Boot 场景**下，是通过 WebMvcConfigurationSupport 的 `#handlerExceptionResolver()` 方法，进行初始化。代码如下：
+
+```
+// WebMvcConfigurationSupport.java
+
+@Bean
+public HandlerExceptionResolver handlerExceptionResolver() {
+    // <1> 创建 HandlerExceptionResolver 数组
+    List<HandlerExceptionResolver> exceptionResolvers = new ArrayList<>();
+    // <1.1> 添加配置的 HandlerExceptionResolver 到 exceptionResolvers 中
+    configureHandlerExceptionResolvers(exceptionResolvers);
+    // <1.2> 如果 exceptionResolvers 为空，添加默认 HandlerExceptionResolver 数组
+    if (exceptionResolvers.isEmpty()) {
+        addDefaultHandlerExceptionResolvers(exceptionResolvers);
+    }
+    // <1.3> 子类定义的 HandlerExceptionResolver 数组，到 exceptionResolvers 中
+    extendHandlerExceptionResolvers(exceptionResolvers);
+
+    // <2> 创建 HandlerExceptionResolverComposite 数组
+    HandlerExceptionResolverComposite composite = new HandlerExceptionResolverComposite();
+    composite.setOrder(0);
+    composite.setExceptionResolvers(exceptionResolvers);
+    return composite;
+}
+```
+
+- `@Bean` 注解，注册一个类型为 HandlerExceptionResolver 的 Bean 对象。所以，在 [「3. 初始化」](https://svip.iocoder.cn/Spring-MVC/HandlerExceptionResolver/#) 可以被扫描到。
+
+- `<1>` 处，创建 HandlerExceptionResolver 数组 `exceptionResolvers` 。
+
+  - `<1.1>` 处，添加配置的 HandlerExceptionResolver 到 `exceptionResolvers` 中。默认情况下，不会配置。所以感兴趣的胖友，自己去看。
+
+  - `<1.2>` 处，因为此时 `exceptionResolvers` 为空，所以调用 `#addDefaultHandlerExceptionResolvers(List<HandlerExceptionResolver> exceptionResolvers)` 方法，添加**默认** HandlerExceptionResolver 数组。代码如下：
+
+    ```
+    // WebMvcConfigurationSupport.java
+    
+    protected final void addDefaultHandlerExceptionResolvers(List<HandlerExceptionResolver> exceptionResolvers) {
+    	// 创建 ExceptionHandlerExceptionResolver 对象
+    	ExceptionHandlerExceptionResolver exceptionHandlerResolver = createExceptionHandlerExceptionResolver();
+    	exceptionHandlerResolver.setContentNegotiationManager(mvcContentNegotiationManager());
+    	exceptionHandlerResolver.setMessageConverters(getMessageConverters());
+    	exceptionHandlerResolver.setCustomArgumentResolvers(getArgumentResolvers());
+    	exceptionHandlerResolver.setCustomReturnValueHandlers(getReturnValueHandlers());
+    	if (jackson2Present) {
+    		exceptionHandlerResolver.setResponseBodyAdvice(
+    				Collections.singletonList(new JsonViewResponseBodyAdvice()));
+    	}
+    	if (this.applicationContext != null) {
+    		exceptionHandlerResolver.setApplicationContext(this.applicationContext);
+    	}
+    	exceptionHandlerResolver.afterPropertiesSet();
+    	exceptionResolvers.add(exceptionHandlerResolver);
+    
+    	// 创建 ResponseStatusExceptionResolver 对象
+    	ResponseStatusExceptionResolver responseStatusResolver = new ResponseStatusExceptionResolver();
+    	responseStatusResolver.setMessageSource(this.applicationContext);
+    	exceptionResolvers.add(responseStatusResolver);
+    
+    	// 创建 DefaultHandlerExceptionResolver 对象
+    	exceptionResolvers.add(new DefaultHandlerExceptionResolver());
+    }
+    ```
+
+    - 依次创建 ExceptionHandlerExceptionResolver、ResponseStatusExceptionResolver、DefaultHandlerExceptionResolver 对象，添加到 `exceptionResolvers` 中。
+
+  - `<1.3>` 处，子类定义的 HandlerExceptionResolver 数组，到 `exceptionResolvers` 中。默认情况下，无定义。所以，可以无视先。
+
+- `<2>` 处，创建 HandlerExceptionResolverComposite 数组。
+
+## 4.2 resolveException
+
+实现 `#resolveException(HttpServletRequest request, HttpServletResponse response, Object handler,Exception ex)` 方法，遍历 HandlerExceptionResolver 数组，逐个处理异常 `ex` ，如果成功，则返回 ModelAndView 对象。代码如下：
+
+```
+// WebMvcConfigurationSupport.java
+
+@Override
+@Nullable
+public ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response,
+        @Nullable Object handler,Exception ex) {
+    if (this.resolvers != null) {
+        // 遍历 HandlerExceptionResolver 数组，逐个处理异常 ex ，如果成功，则返回 ModelAndView 对象
+        for (HandlerExceptionResolver handlerExceptionResolver : this.resolvers) {
+            ModelAndView mav = handlerExceptionResolver.resolveException(request, response, handler, ex);
+            if (mav != null) {
+                return mav;
+            }
+        }
+    }
+    return null;
+}
+```
+
+# 5. AbstractHandlerExceptionResolver
+
+`org.springframework.web.servlet.handler.AbstractHandlerExceptionResolver`，实现 HandlerExceptionResolver、Ordered 接口，HandlerExceptionResolver 抽象类，作为所有 HandlerExceptionResolver 实现类的**基类**。
+
+## 5.1 构造方法
+
+```
+// AbstractHandlerExceptionResolver.java
+
+/**
+ * 顺序，优先级最低
+ */
+private int order = Ordered.LOWEST_PRECEDENCE;
+
+/**
+ * 匹配的处理器对象的集合
+ */
+@Nullable
+private Set<?> mappedHandlers;
+
+/**
+ * 匹配的处理器类型的数组
+ */
+@Nullable
+private Class<?>[] mappedHandlerClasses;
+
+@Nullable
+private Log warnLogger;
+
+/**
+ * 防止响应缓存
+ */
+private boolean preventResponseCaching = false;
+```
+
+- 每个属性，我们放在下面的方法，进行详细解析。
+
+## 5.2 shouldApplyTo
+
+`#shouldApplyTo(HttpServletRequest request, Object handler)` 方法，判断当前 HandlerExceptionResolver 是否能应用到传入的 `handler` 处理器。代码如下：
+
+```
+// AbstractHandlerExceptionResolver.java
+
+protected boolean shouldApplyTo(HttpServletRequest request, @Nullable Object handler) {
+    if (handler != null) {
+        // <1> 如果 mappedHandlers 包含 handler 对象，则返回 true
+        if (this.mappedHandlers != null && this.mappedHandlers.contains(handler)) {
+            return true;
+        }
+        // <2> 如果 mappedHandlerClasses 包含 handler 的类型，则返回 true
+        if (this.mappedHandlerClasses != null) {
+            for (Class<?> handlerClass : this.mappedHandlerClasses) {
+                if (handlerClass.isInstance(handler)) {
+                    return true;
+                }
+            }
+        }
+    }
+    // Else only apply if there are no explicit handler mappings.
+    // <3> 如果 mappedHandlers 和 mappedHandlerClasses 都为空，说明直接匹配
+    return (this.mappedHandlers == null && this.mappedHandlerClasses == null);
+}
+```
+
+- 有 `<1>`、`<2>`、`<3>` 种情况，可以满足条件。
+
+## 5.3 prepareResponse
+
+`#prepareResponse(Exception ex, HttpServletResponse response)` 方法，阻止响应缓存。代码如下：
+
+```
+// AbstractHandlerExceptionResolver.java
+
+private static final String HEADER_CACHE_CONTROL = "Cache-Control";
+
+protected void prepareResponse(Exception ex, HttpServletResponse response) {
+	if (this.preventResponseCaching) {
+		preventCaching(response);
+	}
+}
+
+protected void preventCaching(HttpServletResponse response) {
+	response.addHeader(HEADER_CACHE_CONTROL, "no-store");
+}
+```
+
+- 如果想要阻止响应缓存，需要设置 `preventResponseCaching` 为 `true` 。
+
+## 5.4 resolveException
+
+实现 `#resolveException(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex)` 方法，代码如下：
+
+```
+// AbstractHandlerExceptionResolver.java
+
+@Override
+@Nullable
+public ModelAndView resolveException(
+        HttpServletRequest request, HttpServletResponse response, @Nullable Object handler, Exception ex) {
+    // 判断是否可以应用
+    if (shouldApplyTo(request, handler)) {
+        // 阻止缓存
+        prepareResponse(ex, response);
+        // 执行解析异常，返回 ModelAndView 对象
+        ModelAndView result = doResolveException(request, response, handler, ex);
+        // 如果 ModelAndView 对象非空，则进行返回
+        if (result != null) {
+            // Print warn message when warn logger is not enabled...
+            if (logger.isWarnEnabled() && (this.warnLogger == null || !this.warnLogger.isWarnEnabled())) {
+                logger.warn("Resolved [" + ex + "]" + (result.isEmpty() ? "" : " to " + result));
+            }
+            // 打印异常日志
+            // warnLogger with full stack trace (requires explicit config)
+            logException(ex, request);
+        }
+        // 返回 ModelAndView 对象
+        return result;
+    // 不可应用，直接返回 null
+    } else {
+        return null;
+    }
+}
+```
+
+- 逻辑非常简单，胖友自己看着注释来瞅瞅即懂。
+
+- `<1>` 处，调用 `#doResolveException(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex)` **抽象**方法，执行解析异常，返回 ModelAndView 对象。代码如下：
+
+  ```
+  // AbstractHandlerExceptionResolver.java
+  
+  @Nullable
+  protected abstract ModelAndView doResolveException(
+  		HttpServletRequest request, HttpServletResponse response, @Nullable Object handler, Exception ex);
+  ```
+
+  - 子类通过实现该抽象方法，实现自己的处理异常逻辑。
+
+- `<2>` 处，调用 `#logException(Exception ex, HttpServletRequest request)` 方法，打印异常日志。代码如下：
+
+  ```
+  // AbstractHandlerExceptionResolver.java
+  
+  protected void logException(Exception ex, HttpServletRequest request) {
+  	if (this.warnLogger != null && this.warnLogger.isWarnEnabled()) {
+  		this.warnLogger.warn(buildLogMessage(ex, request));
+  	}
+  }
+  ```
+
+# 6. AbstractHandlerMethodExceptionResolver
+
+`org.springframework.web.servlet.handler.AbstractHandlerMethodExceptionResolver` ，继承 AbstractHandlerExceptionResolver 抽象类，基于 `handler` 类型为 HandlerMethod 的 HandlerExceptionResolver 抽象类。
+
+可能胖友会有疑惑，为什么 AbstractHandlerMethodExceptionResolver 只有一个 ExceptionHandlerExceptionResolver 子类，为什么还要做抽象呢？因为 ExceptionHandlerExceptionResolver 是基于 `@ExceptionHandler` 注解来配置对应的异常处理器，而如果未来我们想自定义其它的方式来配置对应的异常处理器，就可以来继承 AbstractHandlerMethodExceptionResolver 这个抽象类。😈
+
+> 艿艿：有没发现 Spring MVC 中，存在大量的逻辑与配置分离的分层实现？嘻嘻
+
+## 6.1 shouldApplyTo
+
+重写 `#shouldApplyTo(HttpServletRequest request, Object handler)` 方法，代码如下：
+
+```
+// AbstractHandlerMethodExceptionResolver.java
+
+@Override
+protected boolean shouldApplyTo(HttpServletRequest request, @Nullable Object handler) {
+    // 情况一，如果 handler 为空，则直接调用父方法
+    if (handler == null) {
+        return super.shouldApplyTo(request, null);
+    // 情况二，处理 handler 为 HandlerMethod 类型的情况
+    } else if (handler instanceof HandlerMethod) {
+        // <x> 获得真正的 handler
+        HandlerMethod handlerMethod = (HandlerMethod) handler;
+        handler = handlerMethod.getBean();
+        // 调用父方法
+        return super.shouldApplyTo(request, handler);
+    // 情况三，直接返回 false
+    } else {
+        return false;
+    }
+}
+```
+
+- 重点在于情况二，需要在 `<x>` 处，调用 `HandlerMethod#getBean()` 方法，获得真正的 `handler` 处理器。为什么呢？胖友自己翻翻前面的文章，找找原因。😈
+
+## 6.2 doResolveException
+
+重写 `#doResolveException(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex)` 方法，代码如下：
+
+```
+// AbstractHandlerMethodExceptionResolver.java
+
+@Override
+@Nullable
+protected final ModelAndView doResolveException(
+		HttpServletRequest request, HttpServletResponse response, @Nullable Object handler, Exception ex) {
+	return doResolveHandlerMethodException(request, response, (HandlerMethod) handler, ex);
+}
+
+@Nullable
+protected abstract ModelAndView doResolveHandlerMethodException(
+		HttpServletRequest request, HttpServletResponse response, @Nullable HandlerMethod handlerMethod, Exception ex);
+```
+
+- 将 `handler` 转换成 HandlerMethod 类型，并提供新的抽象方法。
+
+# 7. ExceptionHandlerExceptionResolver
+
+`org.springframework.web.servlet.mvc.method.annotation.ExceptionHandlerExceptionResolver` ，实现 ApplicationContextAware、InitializingBean 接口，继承 AbstractHandlerMethodExceptionResolver 抽象类，基于 `@ExceptionHandler` 配置 HandlerMethod 的 HandlerExceptionResolver 实现类。
+
+可能有的胖友并没有使用 `@ExceptionHandler` 注解来实现过异常的处理，可以先看看 [《Spring 异常处理 ExceptionHandler 的使用》](https://www.jianshu.com/p/12e1a752974d) 。
+
+- 一般情况下，艿艿喜欢使用**第三种**。
+
+## 7.1 构造方法
+
+```
+// ExceptionHandlerExceptionResolver.java
+
+@Nullable
+private List<HandlerMethodArgumentResolver> customArgumentResolvers;
+
+@Nullable
+private HandlerMethodArgumentResolverComposite argumentResolvers;
+
+@Nullable
+private List<HandlerMethodReturnValueHandler> customReturnValueHandlers;
+
+@Nullable
+private HandlerMethodReturnValueHandlerComposite returnValueHandlers;
+
+private List<HttpMessageConverter<?>> messageConverters;
+
+private ContentNegotiationManager contentNegotiationManager = new ContentNegotiationManager();
+
+private final List<Object> responseBodyAdvice = new ArrayList<>();
+
+@Nullable
+private ApplicationContext applicationContext;
+
+private final Map<Class<?>, ExceptionHandlerMethodResolver> exceptionHandlerCache =
+		new ConcurrentHashMap<>(64);
+
+private final Map<ControllerAdviceBean, ExceptionHandlerMethodResolver> exceptionHandlerAdviceCache =
+		new LinkedHashMap<>();
+
+public ExceptionHandlerExceptionResolver() {
+	StringHttpMessageConverter stringHttpMessageConverter = new StringHttpMessageConverter();
+	stringHttpMessageConverter.setWriteAcceptCharset(false);  // see SPR-7316
+
+	// 初始化 messageConverters
+	this.messageConverters = new ArrayList<>();
+	this.messageConverters.add(new ByteArrayHttpMessageConverter());
+	this.messageConverters.add(stringHttpMessageConverter);
+	try {
+		this.messageConverters.add(new SourceHttpMessageConverter<>());
+	} catch (Error err) {
+		// Ignore when no TransformerFactory implementation is available
+	}
+	this.messageConverters.add(new AllEncompassingFormHttpMessageConverter());
+}
+```
+
+- 和 [《精尽 Spring MVC 源码解析 —— HandlerAdapter 组件（一）之 HandlerAdapter》](http://svip.iocoder.cn/Spring-MVC/HandlerAdapter-1-HandlerAdapter) 的 [「7. RequestMappingHandlerAdapter」](https://svip.iocoder.cn/Spring-MVC/HandlerExceptionResolver/#) 类似，有大量的相同变量，也是最终调用 ServletInvocableHandlerMethod 的方法。😈 可能胖友有点闷逼？继续往下瞅，哈哈哈哈。
+
+## 7.2 afterPropertiesSet
+
+`#afterPropertiesSet()` 方法，进一步初始化 ExceptionHandlerExceptionResolver 。代码如下：
+
+```
+// ExceptionHandlerExceptionResolver.java
+
+@Override
+public void afterPropertiesSet() {
+    // Do this first, it may add ResponseBodyAdvice beans
+    // 初始化 exceptionHandlerAdviceCache、responseBodyAdvice
+    initExceptionHandlerAdviceCache();
+
+    // 初始化 argumentResolvers 参数
+    if (this.argumentResolvers == null) {
+        List<HandlerMethodArgumentResolver> resolvers = getDefaultArgumentResolvers();
+        this.argumentResolvers = new HandlerMethodArgumentResolverComposite().addResolvers(resolvers);
+    }
+    // 初始化 returnValueHandlers 参数
+    if (this.returnValueHandlers == null) {
+        List<HandlerMethodReturnValueHandler> handlers = getDefaultReturnValueHandlers();
+        this.returnValueHandlers = new HandlerMethodReturnValueHandlerComposite().addHandlers(handlers);
+    }
+}
+```
+
+- `<1>` 处，调用 `#initExceptionHandlerAdviceCache()` 方法，初始化 `exceptionHandlerAdviceCache`、`responseBodyAdvice` 。详细解析，见 [「7.2.1 initExceptionHandlerAdviceCache」](https://svip.iocoder.cn/Spring-MVC/HandlerExceptionResolver/#) 。
+- `<2>` 处，初始化 `argumentResolvers` 属性。其中，`#getDefaultArgumentResolvers()` 方法，获得默认的 HandlerMethodArgumentResolver 数组。详细解析，见 [「7.2.2 getDefaultArgumentResolvers」](https://svip.iocoder.cn/Spring-MVC/HandlerExceptionResolver/#) 。
+- `<3>` 处，初始化 `returnValueHandlers` 属性。其中，`#getDefaultReturnValueHandlers()` 方法，获得默认的 HandlerMethodReturnValueHandler 数组。详细解析，见 [「7.2.3 getDefaultReturnValueHandlers」](https://svip.iocoder.cn/Spring-MVC/HandlerExceptionResolver/#) 。
+
+### 7.2.1 initExceptionHandlerAdviceCache
+
+`#initExceptionHandlerAdviceCache()` 方法，初始化 `exceptionHandlerAdviceCache`、`responseBodyAdvice` 。代码如下：
+
+```
+// ExceptionHandlerExceptionResolver.java
+
+private void initExceptionHandlerAdviceCache() {
+    if (getApplicationContext() == null) {
+        return;
+    }
+
+    // <1> 扫描 @ControllerAdvice 注解的 Bean 们，并将进行排序
+    List<ControllerAdviceBean> adviceBeans = ControllerAdviceBean.findAnnotatedBeans(getApplicationContext());
+    AnnotationAwareOrderComparator.sort(adviceBeans);
+
+    // <2> 遍历 ControllerAdviceBean 数组
+    for (ControllerAdviceBean adviceBean : adviceBeans) {
+        Class<?> beanType = adviceBean.getBeanType();
+        if (beanType == null) {
+            throw new IllegalStateException("Unresolvable type for ControllerAdviceBean: " + adviceBean);
+        }
+        // <2.1> 扫描该 ControllerAdviceBean 对应的类型
+        ExceptionHandlerMethodResolver resolver = new ExceptionHandlerMethodResolver(beanType);
+        // <2.2> 有 @ExceptionHandler 注解，则添加到 exceptionHandlerAdviceCache 中
+        if (resolver.hasExceptionMappings()) {
+            this.exceptionHandlerAdviceCache.put(adviceBean, resolver);
+        }
+        
+        // <2.3> 如果该 beanType 类型是 ResponseBodyAdvice 子类，则添加到 responseBodyAdvice 中
+        if (ResponseBodyAdvice.class.isAssignableFrom(beanType)) {
+            this.responseBodyAdvice.add(adviceBean);
+        }
+    }
+
+    // 打印日志
+    if (logger.isDebugEnabled()) {
+        int handlerSize = this.exceptionHandlerAdviceCache.size();
+        int adviceSize = this.responseBodyAdvice.size();
+        if (handlerSize == 0 && adviceSize == 0) {
+            logger.debug("ControllerAdvice beans: none");
+        } else {
+            logger.debug("ControllerAdvice beans: " +
+                    handlerSize + " @ExceptionHandler, " + adviceSize + " ResponseBodyAdvice");
+        }
+    }
+}
+```
+
+- `<1>` 处，调用 `ControllerAdviceBean#findAnnotatedBeans(ApplicationContext context)` 方法，扫描 `@ControllerAdvice` 注解的 Bean 们，并将进行排序。可能有胖友不熟悉这个注解，可以看看 [《Spring 3.2 新注解 @ControllerAdvice》](http://jinnianshilongnian.iteye.com/blog/1866350) 。
+
+- ```
+  <2>
+  ```
+
+   
+
+  处，遍历 ControllerAdviceBean 数组。
+
+  - `<2.1>` + `<2.2>` 处，扫描该 ControllerAdviceBean 对应的类型，如果有 `@ExceptionHandler` 注解，则添加到 `exceptionHandlerAdviceCache` 中。关于 ExceptionHandlerMethodResolver 类，胖友可以先跳到 [「7.3 ExceptionHandlerMethodResolver」](https://svip.iocoder.cn/Spring-MVC/HandlerExceptionResolver/#) 小节，看完后回来。
+  - `<2.3>` 处，如果该 `beanType` 类型是 ResponseBodyAdvice 子类，则添加到 `responseBodyAdvice` 中。
+
+### 7.2.2 getDefaultArgumentResolvers
+
+`#getDefaultArgumentResolvers()` 方法，获得默认的 HandlerMethodArgumentResolver 数组。见 [传送门](https://github.com/spring-projects/spring-framework/blob/master/spring-webmvc/src/main/java/org/springframework/web/servlet/mvc/method/annotation/ExceptionHandlerExceptionResolver.java#L318-L341) 。
+
+### 7.2.3 getDefaultReturnValueHandlers
+
+`#getDefaultReturnValueHandlers()` 方法，获得默认的 HandlerMethodReturnValueHandler 数组。见 [传送门](https://github.com/spring-projects/spring-framework/blob/master/spring-webmvc/src/main/java/org/springframework/web/servlet/mvc/method/annotation/ExceptionHandlerExceptionResolver.java#L343-L375) 。
+
+## 7.3 ExceptionHandlerMethodResolver
+
+> 艿艿：关于 ExceptionHandlerMethodResolver 类，因为只有 ExceptionHandlerExceptionResolver 类在用，所以放在此处。😈 不过 ExceptionHandlerExceptionResolver 的类名，看起来好容易混淆。。。
+
+`org.springframework.web.method.annotation.ExceptionHandlerMethodResolver`，注解了 `@ExceptionHandler` 的方法的解析器。
+
+### 7.3.1 构造方法
+
+```
+// ExceptionHandlerMethodResolver.java
+
+/**
+ * A filter for selecting {@code @ExceptionHandler} methods.
+ *
+ * MethodFilter 对象，用于过滤带有 @ExceptionHandler 注解的方法
+ */
+public static final MethodFilter EXCEPTION_HANDLER_METHODS = method ->
+        AnnotatedElementUtils.hasAnnotation(method, ExceptionHandler.class);
+
+/**
+ * 已经映射的方法
+ *
+ * 在 {@link #ExceptionHandlerMethodResolver(Class)} 构造方法中初始化
+ */
+private final Map<Class<? extends Throwable>, Method> mappedMethods = new HashMap<>(16);
+
+/**
+ * 已经匹配的方法
+ *
+ * 在 {@link #resolveMethod(Exception)} 方法中初始化
+ */
+private final Map<Class<? extends Throwable>, Method> exceptionLookupCache = new ConcurrentReferenceHashMap<>(16);
+
+public ExceptionHandlerMethodResolver(Class<?> handlerType) {
+    // <1> 遍历 @ExceptionHandler 注解的方法
+    for (Method method : MethodIntrospector.selectMethods(handlerType, EXCEPTION_HANDLER_METHODS)) {
+        // <2> 遍历处理的异常集合
+        for (Class<? extends Throwable> exceptionType : detectExceptionMappings(method)) {
+            // <3> 添加到 mappedMethods 中
+            addExceptionMapping(exceptionType, method);
+        }
+    }
+}
+```
+
+- `mappedMethods` 和 `exceptionLookupCache` 差别在于，后者是经过查找，比较优先级后所产生的。
+
+- `<1>` 处，遍历 `@ExceptionHandler` 注解的方法。
+
+- `<2>` 处，调用 `#detectExceptionMappings(Method method)` 方法，获得方法的异常数组。代码如下：
+
+  ```
+  // ExceptionHandlerMethodResolver.java
+  
+  private List<Class<? extends Throwable>> detectExceptionMappings(Method method) {
+      List<Class<? extends Throwable>> result = new ArrayList<>();
+      // 首先，从方法上的 @ExceptionHandler 注解中，获得所处理的异常，添加到 result 中
+      detectAnnotationExceptionMappings(method, result);
+      // 其次，如果获取不到，从方法参数中，获得所处理的异常，添加到 result 中
+      if (result.isEmpty()) {
+          for (Class<?> paramType : method.getParameterTypes()) {
+              if (Throwable.class.isAssignableFrom(paramType)) {
+                  result.add((Class<? extends Throwable>) paramType);
+              }
+          }
+      }
+      // 如果获取不到，则抛出 IllegalStateException 异常
+      if (result.isEmpty()) {
+          throw new IllegalStateException("No exception types mapped to " + method);
+      }
+      return result;
+  }
+  
+  private void detectAnnotationExceptionMappings(Method method, List<Class<? extends Throwable>> result) {
+      ExceptionHandler ann = AnnotatedElementUtils.findMergedAnnotation(method, ExceptionHandler.class);
+      Assert.state(ann != null, "No ExceptionHandler annotation");
+      result.addAll(Arrays.asList(ann.value()));
+  }
+  ```
+
+- `<3>` 处，调用 `#addExceptionMapping(Class<? extends Throwable> exceptionType, Method method)` 方法，添加到 `mappedMethods` 中。代码如下：
+
+  ```
+  // ExceptionHandlerMethodResolver.java
+  
+  private void addExceptionMapping(Class<? extends Throwable> exceptionType, Method method) {
+      // 添加到 mappedMethods 中
+      Method oldMethod = this.mappedMethods.put(exceptionType, method);
+      // 如果已存在，说明冲突，所以抛出 IllegalStateException 异常
+      if (oldMethod != null && !oldMethod.equals(method)) {
+          throw new IllegalStateException("Ambiguous @ExceptionHandler method mapped for [" +
+                  exceptionType + "]: {" + oldMethod + ", " + method + "}");
+      }
+  }
+  ```
+
+### 7.3.2 hasExceptionMappings
+
+`#hasExceptionMappings()` 方法，判断 `mappedMethods` 非空。代码如下：
+
+```
+// ExceptionHandlerMethodResolver.java
+
+public boolean hasExceptionMappings() {
+	return !this.mappedMethods.isEmpty();
+}
+```
+
+### 7.3.3 resolveMethod
+
+`#resolveMethod(Exception exception)` 方法，解析异常对应的方法。代码如下：
+
+```
+// ExceptionHandlerMethodResolver.java
+
+@Nullable
+public Method resolveMethod(Exception exception) {
+	return resolveMethodByThrowable(exception);
+}
+
+@Nullable
+public Method resolveMethodByThrowable(Throwable exception) {
+	// 首先，获得异常对应的方法
+	Method method = resolveMethodByExceptionType(exception.getClass());
+	// 其次，获取不到，则使用异常 cause 对应的方法
+	if (method == null) {
+		Throwable cause = exception.getCause();
+		if (cause != null) {
+			method = resolveMethodByExceptionType(cause.getClass());
+		}
+	}
+	return method;
+}
+```
+
+- 按照 `exception` 和 `exception.cause` 的先后，调用 `#resolveMethodByExceptionType(Class<? extends Throwable> exceptionType)` 方法，获得异常对应的方法。代码如下：
+
+  ```
+  // ExceptionHandlerMethodResolver.java
+  
+  @Nullable
+  public Method resolveMethodByExceptionType(Class<? extends Throwable> exceptionType) {
+  	// 首先，先从 exceptionLookupCache 缓存中获得
+  	Method method = this.exceptionLookupCache.get(exceptionType);
+  	// 其次，获取不到，则从 mappedMethods 中获得，并添加到 exceptionLookupCache 中
+  	if (method == null) {
+  		method = getMappedMethod(exceptionType);
+  		this.exceptionLookupCache.put(exceptionType, method);
+  	}
+  	return method;
+  }
+  ```
+
+  - 代码比较简单，胖友自己瞅瞅。
+
+  - 调用 `#getMappedMethod(Class<? extends Throwable> exceptionType)` 方法，获得异常对应的方法。代码如下：
+
+    ```
+    // ExceptionHandlerMethodResolver.java
+    
+    @Nullable
+    private Method getMappedMethod(Class<? extends Throwable> exceptionType) {
+        List<Class<? extends Throwable>> matches = new ArrayList<>();
+        // 遍历 mappedMethods 数组，匹配异常，添加到 matches 中
+        for (Class<? extends Throwable> mappedException : this.mappedMethods.keySet()) {
+            if (mappedException.isAssignableFrom(exceptionType)) {
+                matches.add(mappedException);
+            }
+        }
+        // 将匹配的结果，排序，选择第一个
+        if (!matches.isEmpty()) {
+            matches.sort(new ExceptionDepthComparator(exceptionType));
+            return this.mappedMethods.get(matches.get(0));
+        } else {
+            return null;
+        }
+    }
+    ```
+
+    - 代码还是比较简单，胖友自己瞅瞅。
+    - 关于 `org.springframework.core.ExceptionDepthComparator` 比较器，胖友自己点击 [传送门](https://github.com/spring-projects/spring-framework/blob/master/spring-core/src/main/java/org/springframework/core/ExceptionDepthComparator.java) 查看。大体的逻辑是，比较它们和目标类的**继承层级**，越小越匹配。
+
+## 7.4 getExceptionHandlerMethod
+
+`#getExceptionHandlerMethod(HandlerMethod handlerMethod, Exception exception)` 方法，获得异常对应的 ServletInvocableHandlerMethod 对象。代码如下：
+
+```
+// ExceptionHandlerMethodResolver.java
+
+@Nullable
+protected ServletInvocableHandlerMethod getExceptionHandlerMethod(
+        @Nullable HandlerMethod handlerMethod, Exception exception) {
+    // 处理器的类型
+    Class<?> handlerType = null;
+
+    // <1> 首先，如果 handlerMethod 非空，则先获得 Controller 对应的 @ExceptionHandler 处理器对应的方法
+    if (handlerMethod != null) {
+        // Local exception handler methods on the controller class itself.
+        // To be invoked through the proxy, even in case of an interface-based proxy.
+        // 获得 handlerType
+        handlerType = handlerMethod.getBeanType();
+        // 获得 handlerType 对应的 ExceptionHandlerMethodResolver 对象
+        ExceptionHandlerMethodResolver resolver = this.exceptionHandlerCache.get(handlerType);
+        if (resolver == null) {
+            resolver = new ExceptionHandlerMethodResolver(handlerType);
+            this.exceptionHandlerCache.put(handlerType, resolver);
+        }
+        // 获得异常对应的 Method 方法
+        Method method = resolver.resolveMethod(exception);
+        // 如果获得到 Method 方法，则创建 ServletInvocableHandlerMethod 对象，并返回
+        if (method != null) {
+            return new ServletInvocableHandlerMethod(handlerMethod.getBean(), method);
+        }
+        // For advice applicability check below (involving base packages, assignable types
+        // and annotation presence), use target class instead of interface-based proxy.
+        // 获得 handlerType 的原始类。因为，此处有可能是代理对象
+        if (Proxy.isProxyClass(handlerType)) {
+            handlerType = AopUtils.getTargetClass(handlerMethod.getBean());
+        }
+    }
+
+    // <2> 其次，使用 ControllerAdvice 对应的 @ExceptionHandler 处理器对应的方法
+    for (Map.Entry<ControllerAdviceBean, ExceptionHandlerMethodResolver> entry : this.exceptionHandlerAdviceCache.entrySet()) {
+        ControllerAdviceBean advice = entry.getKey();
+        // 如果 ControllerAdvice 支持当前的 handlerType
+        if (advice.isApplicableToBeanType(handlerType)) {
+            // 获得 handlerType 对应的 ExceptionHandlerMethodResolver 对象
+            ExceptionHandlerMethodResolver resolver = entry.getValue();
+            // 获得异常对应的 Method 方法
+            Method method = resolver.resolveMethod(exception);
+            // 如果获得到 Method 方法，则创建 ServletInvocableHandlerMethod 对象，并返回
+            if (method != null) {
+                return new ServletInvocableHandlerMethod(advice.resolveBean(), method);
+            }
+        }
+    }
+
+    // 最差，获取不到
+    return null;
+}
+```
+
+- 虽然代码比较多，但是总体分成 `<1>`、`<2>` 两大种情况。
+- ========== 第一种 `@Controller` 级 ==========
+- `<1>` 处，首先，如果 `handlerMethod` 非空，则先获得 Controller 对应的 `@ExceptionHandler` 处理器对应的方法。
+- 剩余的部分，胖友看代码注释
+- ========== 第二种 `@ControllerAdvice` 级 ==========
+- `<2>` 处，其次，使用 ControllerAdvice 对应的 `@ExceptionHandler` 处理器对应的方法。
+- 剩余的部分，胖友看代码注释
+- ========= 分割线 =========
+- 当然，也有可能获取不到的情况，则会返回 `null` 。
+
+## 7.5 doResolveHandlerMethodException
+
+实现 `#doResolveHandlerMethodException(ttpServletRequest request, HttpServletResponse response, HandlerMethod handlerMethod, Exception exception)` 方法，代码如下：
+
+```
+// ExceptionHandlerMethodResolver.java
+
+@Override
+@Nullable
+protected ModelAndView doResolveHandlerMethodException(HttpServletRequest request,
+        HttpServletResponse response, @Nullable HandlerMethod handlerMethod, Exception exception) {
+
+    // <1> 获得异常对应的 ServletInvocableHandlerMethod 对象
+    ServletInvocableHandlerMethod exceptionHandlerMethod = getExceptionHandlerMethod(handlerMethod, exception);
+    if (exceptionHandlerMethod == null) {
+        return null;
+    }
+
+    // <1.1> 设置 ServletInvocableHandlerMethod 对象的相关属性
+    if (this.argumentResolvers != null) {
+        exceptionHandlerMethod.setHandlerMethodArgumentResolvers(this.argumentResolvers);
+    }
+    if (this.returnValueHandlers != null) {
+        exceptionHandlerMethod.setHandlerMethodReturnValueHandlers(this.returnValueHandlers);
+    }
+
+    // <1.2> 创建 ServletWebRequest 对象
+    ServletWebRequest webRequest = new ServletWebRequest(request, response);
+    // <1.3> 创建 ModelAndViewContainer 对象
+    ModelAndViewContainer mavContainer = new ModelAndViewContainer();
+
+    try {
+        if (logger.isDebugEnabled()) {
+            logger.debug("Using @ExceptionHandler " + exceptionHandlerMethod);
+        }
+        // <2> 执行 ServletInvocableHandlerMethod 的调用
+        Throwable cause = exception.getCause();
+        if (cause != null) {
+            // Expose cause as provided argument as well
+            exceptionHandlerMethod.invokeAndHandle(webRequest, mavContainer, exception, cause, handlerMethod);
+        } else {
+            // Otherwise, just the given exception as-is
+            exceptionHandlerMethod.invokeAndHandle(webRequest, mavContainer, exception, handlerMethod);
+        }
+    } catch (Throwable invocationEx) {
+        // <2.1> 发生异常，则直接返回
+        // Any other than the original exception is unintended here,
+        // probably an accident (e.g. failed assertion or the like).
+        if (invocationEx != exception && logger.isWarnEnabled()) {
+            logger.warn("Failure in @ExceptionHandler " + exceptionHandlerMethod, invocationEx);
+        }
+        // Continue with default processing of the original exception...
+        return null;
+    }
+
+    // <3.1> 如果 mavContainer 已处理，则返回“空”的 ModelAndView 对象。
+    if (mavContainer.isRequestHandled()) {
+        return new ModelAndView();
+    // <3.2> 如果 mavContainer 未处，则基于 `mavContainer` 生成 ModelAndView 对象
+    } else {
+        ModelMap model = mavContainer.getModel();
+        HttpStatus status = mavContainer.getStatus();
+        // <3.2.1> 创建 ModelAndView 对象，并设置相关属性
+        ModelAndView mav = new ModelAndView(mavContainer.getViewName(), model, status);
+        mav.setViewName(mavContainer.getViewName());
+        if (!mavContainer.isViewReference()) {
+            mav.setView((View) mavContainer.getView());
+        }
+        // <3.2.2> TODO 1004 flashMapManager
+        if (model instanceof RedirectAttributes) {
+            Map<String, ?> flashAttributes = ((RedirectAttributes) model).getFlashAttributes();
+            RequestContextUtils.getOutputFlashMap(request).putAll(flashAttributes);
+        }
+        return mav;
+    }
+}
+```
+
+- ```
+  <1>
+  ```
+
+   
+
+  处，调用
+
+   
+
+  ```
+  #getExceptionHandlerMethod(HandlerMethod handlerMethod, Exception exception)
+  ```
+
+   
+
+  方法，获得异常对应的 ServletInvocableHandlerMethod 对象。详细解析，见
+
+   
+
+  「7.4 getExceptionHandlerMethod」
+
+   
+
+  。
+
+  - `<1.1>` 处，设置 ServletInvocableHandlerMethod 对象的相关属性。
+
+- `<1.2>` 处，创建 ServletWebRequest 对象。
+
+- `<1.3>` 处，创建 ModelAndViewContainer 对象。
+
+- 【重要】
+
+  ```
+  <2>
+  ```
+
+   
+
+  处，执行 ServletInvocableHandlerMethod 的调用。
+
+  - 在 [《精尽 Spring MVC 源码解析 —— HandlerAdapter 组件（二）之 ServletInvocableHandlerMethod》](http://svip.iocoder.cn/Spring-MVC/HandlerAdapter-2-ServletInvocableHandlerMethod) 中，已经详细解析。如果不太记得的胖友，回去复习下。
+  - 【也很重要】比较特别的是，此处传入了 `Object... providedArgs` 参数为 `exception` 和 `handlerMethod` 变量，这也是为什么 `@ExceptionHanlder` 注解的方法，可以设置为这两个参数。😈
+  - `<2.1>` 处，发生异常，则直接返回。
+
+- `<3.1>` 处，如果 `mavContainer` **已处理**，则返回“空”的 ModelAndView 对象。😈 这样，就不会被后续的 ViewResolver 所处理。为什么呢？胖友自己回看下 DispatcherServlet 的 `#processHandlerException(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex)` 方法，就很容易明白。没有明白的话，仔细思考下，或者来星球讨论一波。
+
+- ```
+  <3.2>
+  ```
+
+   
+
+  处，如果
+
+   
+
+  ```
+  mavContainer
+  ```
+
+   
+
+  未处，则基于
+
+   
+
+  ```
+  mavContainer
+  ```
+
+   
+
+  生成 ModelAndView 对象。
+
+  - `<3.2.1>` 处，创建 ModelAndView 对象，并设置相关属性。
+  - `<3.2.2>` 处， TODO 1004 flashMapManager
+
+# 8. ResponseStatusExceptionResolver
+
+`org.springframework.web.servlet.mvc.annotation.ResponseStatusExceptionResolver` ，实现 MessageSourceAware 接口，继承 AbstractHandlerExceptionResolver 抽象类，基于 `@ResponseStatus` 提供错误响应的 HandlerExceptionResolver 实现类。
+
+## 8.1 构造方法
+
+```
+// ResponseStatusExceptionResolver.java
+
+@Nullable
+private MessageSource messageSource;
+```
+
+## 8.2 applyStatusAndReason
+
+`#applyStatusAndReason(int statusCode, @Nullable String reason, HttpServletResponse response)` 方法，设置错误响应。代码如下：
+
+```
+// ResponseStatusExceptionResolver.java
+
+protected ModelAndView applyStatusAndReason(int statusCode, @Nullable String reason, HttpServletResponse response)
+        throws IOException {
+    // 情况一，如果无错误提示，则响应只设置状态码
+    if (!StringUtils.hasLength(reason)) {
+        response.sendError(statusCode);
+    // 情况二，如果有错误信息，则响应设置状态码 + 错误提示
+    } else {
+        // 进一步解析错误提示，如果有 messageSource 的情况下
+        String resolvedReason = (this.messageSource != null ?
+                this.messageSource.getMessage(reason, null, reason, LocaleContextHolder.getLocale()) :
+                reason);
+        // 设置
+        response.sendError(statusCode, resolvedReason);
+    }
+
+    // 创建“空” ModelAndView 对象，并返回
+    return new ModelAndView();
+}
+```
+
+- 注意，此处返回的也是“空”的 ModelAndView 对象。
+
+## 8.3 doResolveException
+
+实现 `#doResolveException(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex)` 方法，代码如下：
+
+```
+// ResponseStatusExceptionResolver.java
+
+@Override
+@Nullable
+protected ModelAndView doResolveException(
+        HttpServletRequest request, HttpServletResponse response, @Nullable Object handler, Exception ex) {
+    try {
+        // <1> 情况一，如果异常是 ResponseStatusException 类型，进行解析并设置到响应
+        if (ex instanceof ResponseStatusException) {
+            return resolveResponseStatusException((ResponseStatusException) ex, request, response, handler);
+        }
+
+        // <2> 情况二，如果有 @ResponseStatus 注解，进行解析并设置到响应
+        ResponseStatus status = AnnotatedElementUtils.findMergedAnnotation(ex.getClass(), ResponseStatus.class);
+        if (status != null) {
+            return resolveResponseStatus(status, request, response, handler, ex);
+        }
+
+        // <3> 情况三，使用异常的 cause 在走一次情况一、情况二的逻辑。
+        if (ex.getCause() instanceof Exception) {
+            ex = (Exception) ex.getCause();
+            return doResolveException(request, response, handler, ex);
+        }
+    } catch (Exception resolveEx) {
+        logger.warn("Failure while trying to resolve exception [" + ex.getClass().getName() + "]", resolveEx);
+    }
+    return null;
+}
+```
+
+- 分成三种情况。
+
+- `<1>` 处，情况一，如果异常是 ResponseStatusException 类型，调用 `#resolveResponseStatus(ResponseStatusException ex, HttpServletRequest request, HttpServletResponse response, Object handler)` 方法，进行解析并设置到响应。代码如下：
+
+  ```
+  // ResponseStatusExceptionResolver.java
+  
+  protected ModelAndView resolveResponseStatusException(ResponseStatusException ex,
+  		HttpServletRequest request, HttpServletResponse response, @Nullable Object handler) throws Exception {
+  
+  	int statusCode = ex.getStatus().value();
+  	String reason = ex.getReason();
+  	return applyStatusAndReason(statusCode, reason, response);
+  }
+  ```
+
+- `<2>` 处，情况二，如果异常有 `@ResponseStatus` 注解，调用 `#resolveResponseStatus(ResponseStatus responseStatus, HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex)` 方法，进行解析并设置到响应。代码如下：
+
+  ```
+  // ResponseStatusExceptionResolver.java
+  
+  protected ModelAndView resolveResponseStatus(ResponseStatus responseStatus, HttpServletRequest request,
+  		HttpServletResponse response, @Nullable Object handler, Exception ex) throws Exception {
+  
+  	int statusCode = responseStatus.code().value();
+  	String reason = responseStatus.reason();
+  	return applyStatusAndReason(statusCode, reason, response);
+  }
+  ```
+
+- `<3>` 处，情况三，使用异常的 `cause` 在走一次情况一、情况二的逻辑。
+
+# 9. DefaultHandlerExceptionResolver
+
+`org.springframework.web.servlet.mvc.support.DefaultHandlerExceptionResolver` ，继承 AbstractHandlerExceptionResolver 抽象类，默认 HandlerExceptionResolver 实现类，针对各种异常，设置错误响应。
+
+其中，实现 `#doResolveException(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex)` 方法，代码如下：
+
+```
+// DefaultHandlerExceptionResolver.java
+
+@Override
+@Nullable
+protected ModelAndView doResolveException(
+		HttpServletRequest request, HttpServletResponse response, @Nullable Object handler, Exception ex) {
+
+	try {
+		if (ex instanceof HttpRequestMethodNotSupportedException) {
+			return handleHttpRequestMethodNotSupported(
+					(HttpRequestMethodNotSupportedException) ex, request, response, handler);
+		} else if (ex instanceof HttpMediaTypeNotSupportedException) {
+			return handleHttpMediaTypeNotSupported(
+					(HttpMediaTypeNotSupportedException) ex, request, response, handler);
+		} else if (ex instanceof HttpMediaTypeNotAcceptableException) {
+			return handleHttpMediaTypeNotAcceptable(
+					(HttpMediaTypeNotAcceptableException) ex, request, response, handler);
+		} else if (ex instanceof MissingPathVariableException) {
+			return handleMissingPathVariable(
+					(MissingPathVariableException) ex, request, response, handler);
+		} else if (ex instanceof MissingServletRequestParameterException) {
+			return handleMissingServletRequestParameter(
+					(MissingServletRequestParameterException) ex, request, response, handler);
+		} else if (ex instanceof ServletRequestBindingException) {
+			return handleServletRequestBindingException(
+					(ServletRequestBindingException) ex, request, response, handler);
+		} else if (ex instanceof ConversionNotSupportedException) {
+			return handleConversionNotSupported(
+					(ConversionNotSupportedException) ex, request, response, handler);
+		} else if (ex instanceof TypeMismatchException) {
+			return handleTypeMismatch(
+					(TypeMismatchException) ex, request, response, handler);
+		} else if (ex instanceof HttpMessageNotReadableException) {
+			return handleHttpMessageNotReadable(
+					(HttpMessageNotReadableException) ex, request, response, handler);
+		} else if (ex instanceof HttpMessageNotWritableException) {
+			return handleHttpMessageNotWritable(
+					(HttpMessageNotWritableException) ex, request, response, handler);
+		} else if (ex instanceof MethodArgumentNotValidException) {
+			return handleMethodArgumentNotValidException(
+					(MethodArgumentNotValidException) ex, request, response, handler);
+		} else if (ex instanceof MissingServletRequestPartException) {
+			return handleMissingServletRequestPartException(
+					(MissingServletRequestPartException) ex, request, response, handler);
+		} else if (ex instanceof BindException) {
+			return handleBindException((BindException) ex, request, response, handler);
+		} else if (ex instanceof NoHandlerFoundException) {
+			return handleNoHandlerFoundException(
+					(NoHandlerFoundException) ex, request, response, handler);
+		} else if (ex instanceof AsyncRequestTimeoutException) {
+			return handleAsyncRequestTimeoutException(
+					(AsyncRequestTimeoutException) ex, request, response, handler);
+		}
+	} catch (Exception handlerEx) {
+		if (logger.isWarnEnabled()) {
+			logger.warn("Failure while trying to resolve exception [" + ex.getClass().getName() + "]", handlerEx);
+		}
+	}
+	return null;
+}
+```
+
+比较简单，就不啰嗦解析。感兴趣的胖友，自己去瞅瞅这个类即可。
+
+# 10. SimpleMappingExceptionResolver
+
+> 艿艿：这个类是选读的，不敢兴趣的胖友，可以绕过。
+
+`org.springframework.web.servlet.handler.SimpleMappingExceptionResolver` ，继承 AbstractHandlerExceptionResolver 抽象类，是 Spring MVC 提供的一个简易匹配的异常处理方式。
+
+可通过 XML 中进行配置，示例如下：
+
+```
+<bean class="org.springframework.web.servlet.handler.SimpleMappingExceptionResolver">
+	<!-- 默认异常视图 -->
+	<property name="defaultErrorView" value="error" />
+	<!-- 视图中获取exception信息变量名 -->
+	<property name="exceptionAttribute" value="ex" />
+	<!-- 异常同视图映射关系 -->
+	<property name="exceptionMappings">
+		<props>
+			<prop key="com.lcifn.springmvc.exception.BusinessException">businessEx</prop>
+		</props>
+	</property>
+</bean>
+```
+
+## 10.1 构造方法
+
+```
+// SimpleMappingExceptionResolver.java
+
+/** The default name of the exception attribute: "exception". */
+public static final String DEFAULT_EXCEPTION_ATTRIBUTE = "exception";
+
+/**
+ * 异常的视图映射
+ *
+ * KEY：异常的全类名
+ * VALUE：视图名
+ */
+@Nullable
+private Properties exceptionMappings;
+
+/**
+ * 排除的异常的数组
+ */
+@Nullable
+private Class<?>[] excludedExceptions;
+
+/**
+ * 默认视图名
+ */
+@Nullable
+private String defaultErrorView;
+
+/**
+ * 默认的状态码
+ */
+@Nullable
+private Integer defaultStatusCode;
+
+/**
+ * 状态码的映射
+ *
+ * KEY：视图名
+ * VALUE：状态码
+ */
+private Map<String, Integer> statusCodes = new HashMap<>();
+
+/**
+ * 异常设置到 {@link ModelAndView} 的属性名
+ */
+@Nullable
+private String exceptionAttribute = DEFAULT_EXCEPTION_ATTRIBUTE;
+```
+
+- 属性比较多，随着下面的方法，一起瞅瞅。
+
+## 10.2 doResolveException
+
+实现 `#doResolveException(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex)` 方法，代码如下：
+
+```
+// SimpleMappingExceptionResolver.java
+
+@Override
+@Nullable
+protected ModelAndView doResolveException(
+        HttpServletRequest request, HttpServletResponse response, @Nullable Object handler, Exception ex) {
+    // Expose ModelAndView for chosen error view.
+    // <1> 获得异常对应的视图
+    String viewName = determineViewName(ex, request);
+    if (viewName != null) {
+        // Apply HTTP status code for error views, if specified.
+        // Only apply it if we're processing a top-level request.
+        // <2> 获得视图对应的状态码
+        Integer statusCode = determineStatusCode(request, viewName);
+        // <3> 设置状态码到响应
+        if (statusCode != null) {
+            applyStatusCodeIfPossible(request, response, statusCode);
+        }
+        // <4> 创建 ModelAndView 对象，并返回
+        return getModelAndView(viewName, ex, request);
+    } else {
+        return null;
+    }
+}
+```
+
+- `<1>` 处，调用 `#determineViewName(Exception ex, HttpServletRequest request)` 方法，获得异常对应的视图。代码如下：
+
+  ```
+  // SimpleMappingExceptionResolver.java
+  
+  @Nullable
+  protected String determineViewName(Exception ex, HttpServletRequest request) {
+      String viewName = null;
+      // 如果是排除的异常，返回 null
+      if (this.excludedExceptions != null) {
+          for (Class<?> excludedEx : this.excludedExceptions) {
+              if (excludedEx.equals(ex.getClass())) {
+                  return null;
+              }
+          }
+      }
+      // Check for specific exception mappings.
+      // 获得异常对应的视图
+      if (this.exceptionMappings != null) {
+          viewName = findMatchingViewName(this.exceptionMappings, ex);
+      }
+      // Return default error view else, if defined.
+      // 如果获得不到视图，并且有默认视图，则使用默认视图
+      if (viewName == null && this.defaultErrorView != null) {
+          if (logger.isDebugEnabled()) {
+              logger.debug("Resolving to default view '" + this.defaultErrorView + "'");
+          }
+          viewName = this.defaultErrorView;
+      }
+      return viewName;
+  }
+  ```
+
+  - 其中，调用 `#findMatchingViewName(Properties exceptionMappings, Exception ex)` 方法，获得异常对应的视图。代码如下：
+
+    ```
+    // SimpleMappingExceptionResolver.java
+    
+    @Nullable
+    protected String findMatchingViewName(Properties exceptionMappings, Exception ex) {
+        String viewName = null;
+        String dominantMapping = null;
+        int deepest = Integer.MAX_VALUE;
+        // 遍历 exceptionMappings 数组，寻找最匹配的视图名
+        for (Enumeration<?> names = exceptionMappings.propertyNames(); names.hasMoreElements();) {
+            String exceptionMapping = (String) names.nextElement();
+            // 获得层级
+            int depth = getDepth(exceptionMapping, ex);
+            // 如果层级更低，则使用它
+            if (depth >= 0 && (depth < deepest || (depth == deepest &&
+                    dominantMapping != null && exceptionMapping.length() > dominantMapping.length()))) { // 层级相同，类全名更长，则选择它
+                deepest = depth;
+                dominantMapping = exceptionMapping;
+                viewName = exceptionMappings.getProperty(exceptionMapping);
+            }
+        }
+        // 返回 viewName
+        if (viewName != null && logger.isDebugEnabled()) {
+            logger.debug("Resolving to view '" + viewName + "' based on mapping [" + dominantMapping + "]");
+        }
+        return viewName;
+    }
+    
+    protected int getDepth(String exceptionMapping, Exception ex) {
+        return getDepth(exceptionMapping, ex.getClass(), 0);
+    }
+    
+    private int getDepth(String exceptionMapping, Class<?> exceptionClass, int depth) {
+        // 匹配上
+        if (exceptionClass.getName().contains(exceptionMapping)) {
+            // Found it!
+            return depth;
+        }
+        // If we've gone as far as we can go and haven't found it...
+        // 未匹配上
+        if (exceptionClass == Throwable.class) {
+            return -1;
+        }
+        // 递归父类，继续匹配
+        return getDepth(exceptionMapping, exceptionClass.getSuperclass(), depth + 1);
+    }
+    ```
+
+    - 简单，胖友自己瞅瞅即可。
+
+- `<2>` 处，调用 `#determineStatusCode(HttpServletRequest request, String viewName)` 方法，获得视图对应的状态码。代码如下：
+
+  ```
+  // SimpleMappingExceptionResolver.java
+  
+  @Nullable
+  protected Integer determineStatusCode(HttpServletRequest request, String viewName) {
+  	// 从 statusCodes 中，获得视图名对应的状态码
+  	if (this.statusCodes.containsKey(viewName)) {
+  		return this.statusCodes.get(viewName);
+  	}
+  	// 获得不到，使用默认状态码
+  	return this.defaultStatusCode;
+  }
+  ```
+
+- `<3>` 处，调用 `#applyStatusCodeIfPossible(HttpServletRequest request, HttpServletResponse response, int statusCode)` 方法，设置状态码到响应。代码如下：
+
+  ```
+  // SimpleMappingExceptionResolver.java
+  
+  protected void applyStatusCodeIfPossible(HttpServletRequest request, HttpServletResponse response, int statusCode) {
+  	if (!WebUtils.isIncludeRequest(request)) {
+  		if (logger.isDebugEnabled()) {
+  			logger.debug("Applying HTTP status " + statusCode);
+  		}
+  		response.setStatus(statusCode);
+  		request.setAttribute(WebUtils.ERROR_STATUS_CODE_ATTRIBUTE, statusCode);
+  	}
+  }
+  ```
+
+- `<4>` 处，调用 `#getModelAndView(String viewName, Exception ex)` 方法，创建 ModelAndView 对象。代码如下：
+
+  ```
+  // SimpleMappingExceptionResolver.java
+  
+  protected ModelAndView getModelAndView(String viewName, Exception ex) {
+  	ModelAndView mv = new ModelAndView(viewName);
+  	// 添加 exceptionAttribute
+  	if (this.exceptionAttribute != null) {
+  		mv.addObject(this.exceptionAttribute, ex);
+  	}
+  	return mv;
+  }
+  ```
+
+# 666. 彩蛋
+
+虽然很长，但是实际上，灰常简单。嘿嘿。
+
+参考和推荐如下文章：
+
+- 韩路彪 [《看透 Spring MVC：源代码分析与实践》](https://item.jd.com/11807414.html) 的 [「第16章 HandlerExceptionResolver」](https://svip.iocoder.cn/Spring-MVC/HandlerExceptionResolver/#) 小节
\ No newline at end of file
diff --git a/springmvc/20-Spring MVC 源码解析-RequestToViewNameTranslator 组件.md b/springmvc/20-Spring MVC 源码解析-RequestToViewNameTranslator 组件.md
new file mode 100644
index 0000000..cf1c9c7
--- /dev/null
+++ b/springmvc/20-Spring MVC 源码解析-RequestToViewNameTranslator 组件.md	
@@ -0,0 +1,125 @@
+# 精尽 Spring MVC 源码解析 —— RequestToViewNameTranslator 组件
+
+# 1. 概述
+
+本文，我们来分享 RequestToViewNameTranslator 组件。在 [《精尽 Spring MVC 源码分析 —— 组件一览》](http://svip.iocoder.cn/Spring-MVC/Components-intro) 中，我们对它已经做了介绍：
+
+`org.springframework.web.servlet.RequestToViewNameTranslator` ，请求到视图名的转换器接口。代码如下：
+
+```
+// RequestToViewNameTranslator.java
+
+public interface RequestToViewNameTranslator {
+
+	/**
+     * 根据请求，获得其视图名
+	 */
+	@Nullable
+	String getViewName(HttpServletRequest request) throws Exception;
+
+}
+```
+
+- 在 DispatcherServlet 中，我们已经看到，在 ModelAndView 不存在对应的视图时，会通过 RequestToViewNameTranslator 来获取默认的视图名，作为其视图。
+
+# 2. DefaultRequestToViewNameTranslator
+
+`org.springframework.web.servlet.view.DefaultRequestToViewNameTranslator` ，实现 RequestToViewNameTranslator 接口，默认且是唯一的 RequestToViewNameTranslator 实现类。
+
+## 2.1 构造方法
+
+```
+// DefaultRequestToViewNameTranslator.java
+
+private static final String SLASH = "/";
+
+/**
+ * 前缀
+ */
+private String prefix = "";
+/**
+ * 后缀
+ */
+private String suffix = "";
+
+/**
+ * 分隔符
+ */
+private String separator = SLASH;
+
+/**
+ * 是否移除开头 {@link #SLASH}
+ */
+private boolean stripLeadingSlash = true;
+/**
+ * 是否移除末尾 {@link #SLASH}
+ */
+private boolean stripTrailingSlash = true;
+/**
+ * 是否移除拓展名
+ */
+private boolean stripExtension = true;
+
+/**
+ * URL 路径工具类
+ */
+private UrlPathHelper urlPathHelper = new UrlPathHelper();
+```
+
+- 不要看变量这么多，实际灰常简单。一起继续往下瞅瞅。
+
+## 2.2 getViewName
+
+实现 `#getViewName(HttpServletRequest request)` 方法，代码如下：
+
+```
+// DefaultRequestToViewNameTranslator.java
+
+@Override
+public String getViewName(HttpServletRequest request) {
+    // 获得请求路径
+    String lookupPath = this.urlPathHelper.getLookupPathForRequest(request);
+    // 获得视图名
+    return (this.prefix + transformPath(lookupPath) + this.suffix);
+}
+```
+
+- `<1>` 处，获得请求路径。
+
+- `<2>` 处，调用 `#transformPath(String lookupPath)` 方法，转换请求路径，后续在拼接上 `prefix` 和 `suffix` ，形成最终的视图名。代码如下：
+
+  ```
+  // DefaultRequestToViewNameTranslator.java
+  
+  @Nullable
+  protected String transformPath(String lookupPath) {
+      String path = lookupPath;
+      // 移除开头 SLASH
+      if (this.stripLeadingSlash && path.startsWith(SLASH)) {
+          path = path.substring(1);
+      }
+      // 移除末尾 SLASH
+      if (this.stripTrailingSlash && path.endsWith(SLASH)) {
+          path = path.substring(0, path.length() - 1);
+      }
+      // 移除拓展名
+      if (this.stripExtension) {
+          path = StringUtils.stripFilenameExtension(path);
+      }
+      // 替换分隔符
+      if (!SLASH.equals(this.separator)) {
+          path = StringUtils.replace(path, SLASH, this.separator);
+      }
+      return path;
+  }
+  ```
+
+  - 好咧，这就是这个类的核心。😈 没有其它代码了。哈哈哈哈。
+
+# 666. 彩蛋
+
+开心么？？？哈哈哈哈？？？？
+
+参考和推荐如下文章：
+
+- 韩路彪 [《看透 Spring MVC：源代码分析与实践》](https://item.jd.com/11807414.html) 的 [「第15章 RequestToViewNameTranslator」](https://svip.iocoder.cn/Spring-MVC/RequestToViewNameTranslator/#) 小节
\ No newline at end of file
diff --git a/springmvc/21-Spring MVC 源码解析-LocaleResolver 组件.assets/41a00a9f69243a72aa4c82f6bb758b05.png b/springmvc/21-Spring MVC 源码解析-LocaleResolver 组件.assets/41a00a9f69243a72aa4c82f6bb758b05.png
new file mode 100644
index 0000000..a2908d4
Binary files /dev/null and b/springmvc/21-Spring MVC 源码解析-LocaleResolver 组件.assets/41a00a9f69243a72aa4c82f6bb758b05.png differ
diff --git a/springmvc/21-Spring MVC 源码解析-LocaleResolver 组件.assets/47659f045806606287c2d8d3a44f295c.png b/springmvc/21-Spring MVC 源码解析-LocaleResolver 组件.assets/47659f045806606287c2d8d3a44f295c.png
new file mode 100644
index 0000000..2eefbd4
Binary files /dev/null and b/springmvc/21-Spring MVC 源码解析-LocaleResolver 组件.assets/47659f045806606287c2d8d3a44f295c.png differ
diff --git a/springmvc/21-Spring MVC 源码解析-LocaleResolver 组件.md b/springmvc/21-Spring MVC 源码解析-LocaleResolver 组件.md
new file mode 100644
index 0000000..f45433a
--- /dev/null
+++ b/springmvc/21-Spring MVC 源码解析-LocaleResolver 组件.md	
@@ -0,0 +1,303 @@
+# 精尽 Spring MVC 源码解析 —— LocaleResolver 组件
+
+> LocaleResolver 实际使用很少，所以艿艿也没特别细看，就看了下 AcceptHeaderLocaleResolver 类。
+>
+> 这里艿艿就转载 N3verL4nd 的 [《SpringMVC 源码解析 —— LocaleResolver》](https://blog.csdn.net/x_iya/article/details/78285318) 。
+
+# 1. LocaleResolver
+
+LocaleResolver 是一个解决国际化的策略接口。它包含两个方法：`#resolveLocale(...)` 和 `#setLocale(...)` ，代码如下：
+
+```
+public interface LocaleResolver {
+
+    Locale resolveLocale(HttpServletRequest request);
+    
+    void setLocale(HttpServletRequest request, @Nullable HttpServletResponse response, @Nullable Locale locale);
+
+}
+```
+
+实现此接口的类：
+
+[![LocaleResolver 类图](21-Spring MVC 源码解析-LocaleResolver 组件.assets/47659f045806606287c2d8d3a44f295c.png)](http://static.iocoder.cn/47659f045806606287c2d8d3a44f295c)LocaleResolver 类图
+
+# 2. AcceptHeaderLocaleResolver
+
+SpringMVC 默认使用的是：AcceptHeaderLocaleResolver 。
+
+[![`DispatcherServlet.properties`](21-Spring MVC 源码解析-LocaleResolver 组件.assets/41a00a9f69243a72aa4c82f6bb758b05.png)](http://static.iocoder.cn/41a00a9f69243a72aa4c82f6bb758b05)`DispatcherServlet.properties`
+
+```
+/**
+ * LocaleResolver 接口的实现类
+ * 简单地使用 HTTP 请求头里的 Accept-Language 来指定 Locale对象(即客户端浏览器发送的语言环境，通常是客户端的操作系统)
+ *
+ * 注意:不支持 setLocale 方法，因为只能通过更改客户端的区域设置来更改 Accept-Language 请求头
+ */
+public class AcceptHeaderLocaleResolver implements LocaleResolver {
+
+    private final List<Locale> supportedLocales = new ArrayList<>(4);
+
+    @Nullable
+    private Locale defaultLocale;
+
+    /**
+     * 配置支持的区域设置列表
+     */
+    public void setSupportedLocales(@Nullable List<Locale> locales) {
+        this.supportedLocales.clear();
+        if (locales != null) {
+            this.supportedLocales.addAll(locales);
+        }
+    }
+
+    /**
+     * 返回配置的支持的区域设置列表
+     */
+    public List<Locale> getSupportedLocales() {
+        return this.supportedLocales;
+    }
+
+    /**
+     * 如果 HTTP 请求头没有 Accept-Language，则使用该默认的语言环境设置
+     */
+    public void setDefaultLocale(@Nullable Locale defaultLocale) {
+        this.defaultLocale = defaultLocale;
+    }
+
+    /**
+     * 返回默认配置的语言环境(如果有)
+     */
+    @Nullable
+    public Locale getDefaultLocale() {
+        return this.defaultLocale;
+    }
+
+    @Override
+    public Locale resolveLocale(HttpServletRequest request) {
+        Locale defaultLocale = getDefaultLocale();
+        if (defaultLocale != null && request.getHeader("Accept-Language") == null) {
+            return defaultLocale;
+        }
+        Locale requestLocale = request.getLocale();
+        if (isSupportedLocale(requestLocale)) {
+            return requestLocale;
+        }
+        Locale supportedLocale = findSupportedLocale(request);
+        if (supportedLocale != null) {
+            return supportedLocale;
+        }
+        return (defaultLocale != null ? defaultLocale : requestLocale);
+    }
+
+    private boolean isSupportedLocale(Locale locale) {
+        List<Locale> supportedLocales = getSupportedLocales();
+        return (supportedLocales.isEmpty() || supportedLocales.contains(locale));
+    }
+
+    @Nullable
+    private Locale findSupportedLocale(HttpServletRequest request) {
+        Enumeration<Locale> requestLocales = request.getLocales();
+        while (requestLocales.hasMoreElements()) {
+            Locale locale = requestLocales.nextElement();
+            if (getSupportedLocales().contains(locale)) {
+                return locale;
+            }
+        }
+        return null;
+    }
+
+    @Override
+    public void setLocale(HttpServletRequest request, @Nullable HttpServletResponse response, @Nullable Locale locale) {
+        throw new UnsupportedOperationException(
+                "Cannot change HTTP accept header - use a different locale resolution strategy");
+    }
+
+}
+```
+
+`#resolveLocale(...)` 方法的处理流程：
+
+- 如果 HTTP 请求头里不含有 `Accept-Language` ，并且默认的语言环境 `defaultLocale` 不为空，则使用默认的语言环境。否则，从请求里获得 Locale 。
+- 而一般的我们没有配置 `supportedLocales` 与`defaultLocale` 属性(需要配置注入)，所以 AcceptHeaderLocaleResolver 使用`Accept-Language` 来构造 Locale 对象。
+
+# 3. AbstractLocaleResolver
+
+```
+/**
+ * 实现 LocaleResolver 接口的抽象基类
+ * 提供对默认语言环境的支持
+ */
+public abstract class AbstractLocaleResolver implements LocaleResolver {
+
+    @Nullable
+    private Locale defaultLocale;
+    public void setDefaultLocale(@Nullable Locale defaultLocale) {
+        this.defaultLocale = defaultLocale;
+    }
+    
+    @Nullable
+    protected Locale getDefaultLocale() {
+        return this.defaultLocale;
+    }
+    
+}
+```
+
+# 4. LocaleContextResolver
+
+```
+public interface LocaleContextResolver extends LocaleResolver {
+
+    LocaleContext resolveLocaleContext(HttpServletRequest request);
+    
+    void setLocaleContext(HttpServletRequest request, @Nullable HttpServletResponse response,
+            @Nullable LocaleContext localeContext);
+            
+}
+```
+
+# 5. AbstractLocaleContextResolver
+
+```
+/**
+ * LocaleContextResolver 实现的抽象基类:提供对默认语言环境和默认时区的支持
+ * 还提供了 resolveLocale 和 setLocale 的预实现版本，委托给 resolveLocaleContext 和 setLocaleContext
+ */
+public abstract class AbstractLocaleContextResolver extends AbstractLocaleResolver implements LocaleContextResolver {
+
+    @Nullable
+    private TimeZone defaultTimeZone;
+    public void setDefaultTimeZone(@Nullable TimeZone defaultTimeZone) {
+        this.defaultTimeZone = defaultTimeZone;
+    }
+    
+    @Nullable
+    public TimeZone getDefaultTimeZone() {
+        return this.defaultTimeZone;
+    }
+    
+    @Override
+    public Locale resolveLocale(HttpServletRequest request) {
+        Locale locale = resolveLocaleContext(request).getLocale();
+        return (locale != null ? locale : request.getLocale());
+    }
+    
+    @Override
+    public void setLocale(HttpServletRequest request, @Nullable HttpServletResponse response, @Nullable Locale locale) {
+        setLocaleContext(request, response, (locale != null ? new SimpleLocaleContext(locale) : null));
+    }
+    
+}
+```
+
+# 6. SessionLocaleResolver
+
+```
+public class SessionLocaleResolver extends AbstractLocaleContextResolver {
+
+    public static final String LOCALE_SESSION_ATTRIBUTE_NAME = SessionLocaleResolver.class.getName() + ".LOCALE";
+    public static final String TIME_ZONE_SESSION_ATTRIBUTE_NAME = SessionLocaleResolver.class.getName() + ".TIME_ZONE";
+    private String localeAttributeName = LOCALE_SESSION_ATTRIBUTE_NAME;
+    private String timeZoneAttributeName = TIME_ZONE_SESSION_ATTRIBUTE_NAME;
+
+    /**
+     * 在 HttpSession 中指定相应属性的名称，保存当前的 Locale 值
+     * 默认值为 LOCALE_SESSION_ATTRIBUTE_NAME
+     */
+    public void setLocaleAttributeName(String localeAttributeName) {
+        this.localeAttributeName = localeAttributeName;
+    }
+
+    /**
+     * 在 HttpSession 中指定相应属性的名称，保存当前的 TimeZone 值
+     * 默认值为 TIME_ZONE_SESSION_ATTRIBUTE_NAME
+     */
+    public void setTimeZoneAttributeName(String timeZoneAttributeName) {
+        this.timeZoneAttributeName = timeZoneAttributeName;
+    }
+
+    @Override
+    public Locale resolveLocale(HttpServletRequest request) {
+        Locale locale = (Locale) WebUtils.getSessionAttribute(request, this.localeAttributeName);
+        if (locale == null) {
+            locale = determineDefaultLocale(request);
+        }
+        return locale;
+    }
+
+    @Override
+    public LocaleContext resolveLocaleContext(final HttpServletRequest request) {
+        return new TimeZoneAwareLocaleContext() {
+        
+            @Override
+            public Locale getLocale() {
+                Locale locale = (Locale) WebUtils.getSessionAttribute(request, localeAttributeName);
+                if (locale == null) {
+                    locale = determineDefaultLocale(request);
+                }
+                return locale;
+            }
+            
+            @Override
+            @Nullable
+            public TimeZone getTimeZone() {
+                TimeZone timeZone = (TimeZone) WebUtils.getSessionAttribute(request, timeZoneAttributeName);
+                if (timeZone == null) {
+                    timeZone = determineDefaultTimeZone(request);
+                }
+                return timeZone;
+            }
+            
+        };
+    }
+
+    @Override
+    public void setLocaleContext(HttpServletRequest request, @Nullable HttpServletResponse response,
+            @Nullable LocaleContext localeContext) {
+
+        Locale locale = null;
+        TimeZone timeZone = null;
+        if (localeContext != null) {
+            locale = localeContext.getLocale();
+            if (localeContext instanceof TimeZoneAwareLocaleContext) {
+                timeZone = ((TimeZoneAwareLocaleContext) localeContext).getTimeZone();
+            }
+        }
+        // 将 Locale 与 TimeZone 保存到 HttpSession
+        WebUtils.setSessionAttribute(request, this.localeAttributeName, locale);
+        WebUtils.setSessionAttribute(request, this.timeZoneAttributeName, timeZone);
+    }
+
+
+    /**
+     * 确定给定请求的默认语言环境，如果没有找到 Locale 会话属性，则调用
+     * 默认实现返回指定的默认语言环境（如果有的话）返回到请求的Accept-Header 语言环境
+     */
+    protected Locale determineDefaultLocale(HttpServletRequest request) {
+        Locale defaultLocale = getDefaultLocale();
+        if (defaultLocale == null) {
+            defaultLocale = request.getLocale();
+        }
+        return defaultLocale;
+    }
+
+    /**
+     * 确定给定请求的默认时区，如果未找到TimeZone会话属性，则调用
+     * 默认实现返回指定的默认时区（如果有），否则返回null
+     */
+    @Nullable
+    protected TimeZone determineDefaultTimeZone(HttpServletRequest request) {
+        return getDefaultTimeZone();
+    }
+
+}
+```
+
+# 666. 彩蛋
+
+参考和推荐如下文章：
+
+- 韩路彪 [《看透 Spring MVC：源代码分析与实践》](https://item.jd.com/11807414.html) 的 [「第18章 LocaleResolver」](https://svip.iocoder.cn/Spring-MVC/LocaleResolver/#) 小节
+- rj042 [《Spring MVC 之 LocaleResolver(解析用户区域)》](http://blog.csdn.net/rj042/article/details/23354225)
\ No newline at end of file
diff --git a/springmvc/22-Spring MVC 源码解析-ThemeResolver 组件.assets/01.png b/springmvc/22-Spring MVC 源码解析-ThemeResolver 组件.assets/01.png
new file mode 100644
index 0000000..19f226c
Binary files /dev/null and b/springmvc/22-Spring MVC 源码解析-ThemeResolver 组件.assets/01.png differ
diff --git a/springmvc/22-Spring MVC 源码解析-ThemeResolver 组件.md b/springmvc/22-Spring MVC 源码解析-ThemeResolver 组件.md
new file mode 100644
index 0000000..00164ca
--- /dev/null
+++ b/springmvc/22-Spring MVC 源码解析-ThemeResolver 组件.md	
@@ -0,0 +1,240 @@
+# 精尽 Spring MVC 源码解析 —— ThemeResolver 组件
+
+> ThemeResolver 实际使用很少，所以艿艿也没特别细看。
+>
+> 这里艿艿就转载 IAMTJW 的 [《Spring MVC 源码分析 —— 动态样式ThemeResolver（二）》](https://blog.csdn.net/qq924862077/article/details/53484532) 。
+
+# 1. 概述
+
+在上一篇博客 [《Spring MVC 源码分析 —— 动态样式ThemeResolver（一）》](https://blog.csdn.net/qq924862077/article/details/53438710) 中我们介绍了多样式ThemeResolver 的使用方法，接下来我们对源码进行简单的分析一下。
+
+# 2. 类图
+
+ThemeResolver 的体系结构如下：[![ThemeResolver 类图](22-Spring MVC 源码解析-ThemeResolver 组件.assets/01.png)](http://static.iocoder.cn/images/Spring/2022-06-10/01.png)ThemeResolver 类图
+
+# 3. ThemeResolver
+
+接口 ThemeResolver 中定义的接口是比较简单的，提供两个接口：
+
+- （1）`#resolveThemeName` 方法，获取样式名。
+- （2）`#setThemeName` 方法，设置样式名。
+
+```
+public interface ThemeResolver {
+
+	/**
+     * 从请求中，解析出使用的主题。例如，从请求头 User-Agent ，判断使用 PC 端，还是移动端的主题
+     *
+	 * Resolve the current theme name via the given request.
+	 * Should return a default theme as fallback in any case.
+	 * @param request request to be used for resolution
+	 * @return the current theme name
+	 */
+	String resolveThemeName(HttpServletRequest request);
+
+	/**
+     * 设置请求，所使用的主题。
+     *
+	 * Set the current theme name to the given one.
+	 * @param request request to be used for theme name modification
+	 * @param response response to be used for theme name modification
+	 * @param themeName the new theme name ({@code null} or empty to reset it)
+	 * @throws UnsupportedOperationException if the ThemeResolver implementation
+	 * does not support dynamic changing of the theme
+	 */
+	void setThemeName(HttpServletRequest request, @Nullable HttpServletResponse response, @Nullable String themeName);
+
+}
+```
+
+# 4. AbstractThemeResolver
+
+抽象类 AbstractThemeResolver ，提供两个方法：
+
+- （1）`#setDefaultThemeName(...)` 方法，设置默认的样式名。
+- （2）`#getDefaultThemeName(...)` 方法，获取默认的样式名。
+
+```
+public abstract class AbstractThemeResolver implements ThemeResolver {
+
+	/**
+	 * Out-of-the-box value for the default theme name: "theme".
+	 */
+	public static final String ORIGINAL_DEFAULT_THEME_NAME = "theme";
+
+	private String defaultThemeName = ORIGINAL_DEFAULT_THEME_NAME;
+
+	public void setDefaultThemeName(String defaultThemeName) {
+		this.defaultThemeName = defaultThemeName;
+	}
+
+	public String getDefaultThemeName() {
+		return this.defaultThemeName;
+	}
+
+}
+```
+
+}
+
+# 5. SessionThemeResolver
+
+实现类 SessionThemeResolver 的实现也是比较简单的，就是将`themeName` 保存到 Session 中就可以了。
+
+```
+public class SessionThemeResolver extends AbstractThemeResolver {
+
+	/**
+	 * Name of the session attribute that holds the theme name.
+	 * Only used internally by this implementation.
+	 * Use {@code RequestContext(Utils).getTheme()}
+	 * to retrieve the current theme in controllers or views.
+	 * @see org.springframework.web.servlet.support.RequestContext#getTheme
+	 * @see org.springframework.web.servlet.support.RequestContextUtils#getTheme
+	 */
+	public static final String THEME_SESSION_ATTRIBUTE_NAME = SessionThemeResolver.class.getName() + ".THEME";
+
+
+	@Override
+	public String resolveThemeName(HttpServletRequest request) {
+		String themeName = (String) WebUtils.getSessionAttribute(request, THEME_SESSION_ATTRIBUTE_NAME);
+		// A specific theme indicated, or do we need to fallback to the default?
+		return (themeName != null ? themeName : getDefaultThemeName());
+	}
+
+	@Override
+	public void setThemeName(
+			HttpServletRequest request, @Nullable HttpServletResponse response, @Nullable String themeName) {
+		WebUtils.setSessionAttribute(request, THEME_SESSION_ATTRIBUTE_NAME,
+				(StringUtils.hasText(themeName) ? themeName : null));
+	}
+
+}
+```
+
+# 6. FixedThemeResolver
+
+实现 FixedThemeResolver 中没有具体的实现操作。
+
+```
+public class FixedThemeResolver extends AbstractThemeResolver {
+
+	@Override
+	public String resolveThemeName(HttpServletRequest request) {
+		return getDefaultThemeName();
+	}
+
+	@Override
+	public void setThemeName(
+			HttpServletRequest request, @Nullable HttpServletResponse response, @Nullable String themeName) {
+		throw new UnsupportedOperationException("Cannot change theme - use a different theme resolution strategy");
+	}
+
+}
+```
+
+# 7. CookieThemeResolver
+
+实现类 CookieThemeResolver 的实现也是比较简单的，就是将`themeName` 保存到 Cookie 中就可以了。
+
+```
+public class CookieThemeResolver extends CookieGenerator implements ThemeResolver {
+
+	/**
+	 * The default theme name used if no alternative is provided.
+	 */
+	public static final String ORIGINAL_DEFAULT_THEME_NAME = "theme";
+
+	/**
+	 * Name of the request attribute that holds the theme name. Only used
+	 * for overriding a cookie value if the theme has been changed in the
+	 * course of the current request! Use RequestContext.getTheme() to
+	 * retrieve the current theme in controllers or views.
+	 * @see org.springframework.web.servlet.support.RequestContext#getTheme
+	 */
+	public static final String THEME_REQUEST_ATTRIBUTE_NAME = CookieThemeResolver.class.getName() + ".THEME";
+
+	/**
+	 * The default name of the cookie that holds the theme name.
+	 */
+	public static final String DEFAULT_COOKIE_NAME = CookieThemeResolver.class.getName() + ".THEME";
+
+
+	private String defaultThemeName = ORIGINAL_DEFAULT_THEME_NAME;
+
+
+	public CookieThemeResolver() {
+		setCookieName(DEFAULT_COOKIE_NAME);
+	}
+
+
+	/**
+	 * Set the name of the default theme.
+	 */
+	public void setDefaultThemeName(String defaultThemeName) {
+		this.defaultThemeName = defaultThemeName;
+	}
+
+	/**
+	 * Return the name of the default theme.
+	 */
+	public String getDefaultThemeName() {
+		return this.defaultThemeName;
+	}
+
+
+	@Override
+	public String resolveThemeName(HttpServletRequest request) {
+		// Check request for preparsed or preset theme.
+		String themeName = (String) request.getAttribute(THEME_REQUEST_ATTRIBUTE_NAME);
+		if (themeName != null) {
+			return themeName;
+		}
+
+		// Retrieve cookie value from request.
+		String cookieName = getCookieName();
+		if (cookieName != null) {
+			Cookie cookie = WebUtils.getCookie(request, cookieName);
+			if (cookie != null) {
+				String value = cookie.getValue();
+				if (StringUtils.hasText(value)) {
+					themeName = value;
+				}
+			}
+		}
+
+		// Fall back to default theme.
+		if (themeName == null) {
+			themeName = getDefaultThemeName();
+		}
+		request.setAttribute(THEME_REQUEST_ATTRIBUTE_NAME, themeName);
+		return themeName;
+	}
+
+	@Override
+	public void setThemeName(
+			HttpServletRequest request, @Nullable HttpServletResponse response, @Nullable String themeName) {
+
+		Assert.notNull(response, "HttpServletResponse is required for CookieThemeResolver");
+
+		if (StringUtils.hasText(themeName)) {
+			// Set request attribute and add cookie.
+			request.setAttribute(THEME_REQUEST_ATTRIBUTE_NAME, themeName);
+			addCookie(response, themeName);
+		} else {
+			// Set request attribute to fallback theme and remove cookie.
+			request.setAttribute(THEME_REQUEST_ATTRIBUTE_NAME, getDefaultThemeName());
+			removeCookie(response);
+		}
+	}
+
+}
+```
+
+# 666. 彩蛋
+
+没有彩蛋~
+
+参考和推荐如下文章：
+
+- 韩路彪 [《看透 Spring MVC：源代码分析与实践》](https://item.jd.com/11807414.html) 的 [「第19章 ThemeResolver」](https://svip.iocoder.cn/Spring-MVC/ThemeResolver/#) 小节
\ No newline at end of file
diff --git a/springmvc/23-Spring MVC 源码解析-ViewResolver 组件.assets/01.png b/springmvc/23-Spring MVC 源码解析-ViewResolver 组件.assets/01.png
new file mode 100644
index 0000000..017a98e
Binary files /dev/null and b/springmvc/23-Spring MVC 源码解析-ViewResolver 组件.assets/01.png differ
diff --git a/springmvc/23-Spring MVC 源码解析-ViewResolver 组件.assets/02.png b/springmvc/23-Spring MVC 源码解析-ViewResolver 组件.assets/02.png
new file mode 100644
index 0000000..6aff03b
Binary files /dev/null and b/springmvc/23-Spring MVC 源码解析-ViewResolver 组件.assets/02.png differ
diff --git a/springmvc/23-Spring MVC 源码解析-ViewResolver 组件.md b/springmvc/23-Spring MVC 源码解析-ViewResolver 组件.md
new file mode 100644
index 0000000..e4c6ff4
--- /dev/null
+++ b/springmvc/23-Spring MVC 源码解析-ViewResolver 组件.md	
@@ -0,0 +1,1404 @@
+# 精尽 Spring MVC 源码解析 —— ViewResolver 组件
+
+# 1. 概述
+
+本文，我们来分享 ViewResolver 组件。在 [《精尽 Spring MVC 源码分析 —— 组件一览》](http://svip.iocoder.cn/Spring-MVC/Components-intro) 中，我们对它已经做了介绍：
+
+`org.springframework.web.servlet.ViewResolver` ，实体解析器接口，根据视图名和国际化，获得最终的视图 View 对象。代码如下：
+
+```
+// ViewResolver.java
+
+public interface ViewResolver {
+
+	/**
+     * 根据视图名和国际化，获得最终的 View 对象
+	 */
+	@Nullable
+	View resolveViewName(String viewName, Locale locale) throws Exception;
+
+}
+```
+
+# 2. 类图
+
+ViewResolver 的类图如下：
+
+[![类图](23-Spring MVC 源码解析-ViewResolver 组件.assets/01.png)](http://static.iocoder.cn/images/Spring/2022-06-13/01.png)类图
+
+虽然实现类比较多，ViewResolver 分成五类实现类，就是 ViewResolver 的五个直接实现类。
+
+# 3. 初始化
+
+我们以**默认配置的 Spring Boot 场景**下为例，来一起看看 DispatcherServlet 的 `#initViewResolvers(ApplicationContext context)` 方法，初始化 `viewResolvers` 变量。代码如下：
+
+```
+// DispatcherServlet.java
+
+/** List of ViewResolvers used by this servlet. */
+@Nullable
+private List<ViewResolver> viewResolvers;
+
+/** Detect all ViewResolvers or just expect "viewResolver" bean?. */
+private boolean detectAllViewResolvers = true;
+
+private void initViewResolvers(ApplicationContext context) {
+    // 置空 viewResolvers 处理
+    this.viewResolvers = null;
+
+    // 情况一，自动扫描 ViewResolver 类型的 Bean 们
+    if (this.detectAllViewResolvers) {
+        // Find all ViewResolvers in the ApplicationContext, including ancestor contexts.
+        Map<String, ViewResolver> matchingBeans =
+                BeanFactoryUtils.beansOfTypeIncludingAncestors(context, ViewResolver.class, true, false);
+        if (!matchingBeans.isEmpty()) {
+            this.viewResolvers = new ArrayList<>(matchingBeans.values());
+            // We keep ViewResolvers in sorted order.
+            AnnotationAwareOrderComparator.sort(this.viewResolvers);
+        }
+    // 情况二，获得名字为 VIEW_RESOLVER_BEAN_NAME 的 Bean 们
+    } else {
+        try {
+            ViewResolver vr = context.getBean(VIEW_RESOLVER_BEAN_NAME, ViewResolver.class);
+            this.viewResolvers = Collections.singletonList(vr);
+        } catch (NoSuchBeanDefinitionException ex) {
+            // Ignore, we'll add a default ViewResolver later.
+        }
+    }
+
+    // Ensure we have at least one ViewResolver, by registering
+    // a default ViewResolver if no other resolvers are found.
+    // 情况三，如果未获得到，则获得默认配置的 ViewResolver 类
+    if (this.viewResolvers == null) {
+        this.viewResolvers = getDefaultStrategies(context, ViewResolver.class);
+        if (logger.isTraceEnabled()) {
+            logger.trace("No ViewResolvers declared for servlet '" + getServletName() +
+                    "': using default strategies from DispatcherServlet.properties");
+        }
+    }
+}
+```
+
+- 一共有三种情况，初始化 `viewResolvers` 属性。
+
+- 默认情况下，
+
+  ```
+  detectAllViewResolvers
+  ```
+
+   
+
+  为
+
+   
+
+  ```
+  true
+  ```
+
+   
+
+  ，所以走
+
+  情况一
+
+  的逻辑，自动扫描 ViewResolver 类型的 Bean 们。在
+
+  默认配置的 Spring Boot 场景
+
+  下，
+
+  ```
+  viewResolvers
+  ```
+
+   
+
+  的结果是：
+
+  - ContentNegotiatingViewResolver
+  - BeanNameViewResolver
+  - ThymeleafViewResolver
+  - ViewResolverComposite
+  - InternalResourceViewResolver
+
+从实现上来说，ContentNegotiatingViewResolver 是最最最重要的 ViewResolver 实现类，所以我们先开始瞅瞅它。
+
+# 4. ContentNegotiatingViewResolver
+
+`org.springframework.web.servlet.view.ContentNegotiatingViewResolver` ，实现 ViewResolver、Ordered、InitializingBean 接口，继承 WebApplicationObjectSupport 抽象类，基于**内容类型**来获取对应 View 的 ViewResolver 实现类。
+
+其中，**内容类型**指的是 `"Content-Type"` 和拓展后缀。
+
+## 4.1 构造方法
+
+```
+// ContentNegotiatingViewResolver.java
+
+@Nullable
+private ContentNegotiationManager contentNegotiationManager;
+/**
+ * ContentNegotiationManager 的工厂，用于创建 {@link #contentNegotiationManager} 对象
+ */
+private final ContentNegotiationManagerFactoryBean cnmFactoryBean = new ContentNegotiationManagerFactoryBean();
+
+/**
+ * 在找不到 View 对象时，返回 {@link #NOT_ACCEPTABLE_VIEW}
+ */
+private boolean useNotAcceptableStatusCode = false;
+
+/**
+ * 默认 View 数组
+ */
+@Nullable
+private List<View> defaultViews;
+
+/**
+ * ViewResolver 数组
+ */
+@Nullable
+private List<ViewResolver> viewResolvers;
+
+/**
+ * 顺序，优先级最高
+ */
+private int order = Ordered.HIGHEST_PRECEDENCE;
+```
+
+- ```
+  viewResolvers
+  ```
+
+   
+
+  属性，ViewResolver 数组。对于来说，ContentNegotiatingViewResolver 会使用这些
+
+   
+
+  ```
+  viewResolvers
+  ```
+
+   
+
+  们，解析出所有的 View 们，然后基于
+
+  内容类型
+
+  来获取对应的 View 们。此时的 View 结果，可能是一个，可能是多个，所以需要比较获取到
+
+  最优
+
+  的 View 对象。
+
+  - `defaultViews` 属性，默认 View 数组。那么此处的默认是什么意思呢？在 `viewResolvers` 们解析出所有的 View 们的基础上，也会添加 `defaultViews` 到 View 结果中。😈 如果听起来有点绕，下面看具体的代码，会更加易懂。
+
+- `order` 属性，顺序，优先级**最高**。所以，这也是为什么在 [「3. 初始化」](https://svip.iocoder.cn/Spring-MVC/ViewResolver/#) 中排行第一。
+
+## 4.2 initServletContext
+
+实现 `#initServletContext(ServletContext servletContext)` 方法，初始化 `viewResolvers` 属性。代码如下：
+
+```
+// ContentNegotiatingViewResolver.java
+
+@Override
+protected void initServletContext(ServletContext servletContext) {
+    // <1> 扫描所有 ViewResolver 的 Bean 们
+    Collection<ViewResolver> matchingBeans =
+            BeanFactoryUtils.beansOfTypeIncludingAncestors(obtainApplicationContext(), ViewResolver.class).values();
+    // <1.1> 情况一，如果 viewResolvers 为空，则将 matchingBeans 作为 viewResolvers 。
+    if (this.viewResolvers == null) {
+        this.viewResolvers = new ArrayList<>(matchingBeans.size());
+        for (ViewResolver viewResolver : matchingBeans) {
+            if (this != viewResolver) { // 排除自己
+                this.viewResolvers.add(viewResolver);
+            }
+        }
+    // <1.2> 情况二，如果 viewResolvers 非空，则和 matchingBeans 进行比对，判断哪些未进行初始化，那么需要进行初始化
+    } else {
+        for (int i = 0; i < this.viewResolvers.size(); i++) {
+            ViewResolver vr = this.viewResolvers.get(i);
+            // 已存在在 matchingBeans 中，说明已经初始化，则直接 continue
+            if (matchingBeans.contains(vr)) {
+                continue;
+            }
+            // 不存在在 matchingBeans 中，说明还未初始化，则进行初始化
+            String name = vr.getClass().getName() + i;
+            obtainApplicationContext().getAutowireCapableBeanFactory().initializeBean(vr, name);
+        }
+    }
+    // <1.3> 排序 viewResolvers 数组
+    AnnotationAwareOrderComparator.sort(this.viewResolvers);
+
+    // <2> 设置 cnmFactoryBean 的 servletContext 属性
+    this.cnmFactoryBean.setServletContext(servletContext);
+}
+```
+
+- ```
+  <1>
+  ```
+
+   
+
+  处，扫描所有 ViewResolver 的 Bean 们。
+
+  - 【重要】`<1.1>` 处，情况一，如果 `viewResolvers` 为空，则将 `matchingBeans` 作为 `viewResolvers` 。默认情况下，走的是这段逻辑。所以此时 `viewResolvers` 会有 BeanNameViewResolver、ThymeleafViewResolver、ViewResolverComposite、InternalResourceViewResolver 四个对象。
+  - `<1.2>` 处，情况二，如果 `viewResolvers` 非空，则和 `matchingBeans` 进行比对，判断哪些未进行初始化，那么需要进行初始化。有点点绕，艿艿也懵逼了下，胖友在瞅瞅。
+  - `<1.3>` 处，排序 `viewResolvers` 数组。
+
+- `<2>` 处，设置 `cnmFactoryBean` 的 `servletContext` 属性。
+
+## 4.3 afterPropertiesSet
+
+实现 `#afterPropertiesSet()` 方法，初始化 `contentNegotiationManager` 属性。代码如下：
+
+```
+// ContentNegotiatingViewResolver.java
+
+@Override
+public void afterPropertiesSet() {
+    // 如果 contentNegotiationManager 为空，则进行创建
+    if (this.contentNegotiationManager == null) {
+        this.contentNegotiationManager = this.cnmFactoryBean.build();
+    }
+    if (this.viewResolvers == null || this.viewResolvers.isEmpty()) {
+        logger.warn("No ViewResolvers configured");
+    }
+}
+```
+
+## 4.4 resolveViewName
+
+实现 `#resolveViewName(String viewName, Locale locale)` 方法，代码如下：
+
+```
+// ContentNegotiatingViewResolver.java
+
+@Override
+@Nullable
+public View resolveViewName(String viewName, Locale locale) throws Exception {
+    RequestAttributes attrs = RequestContextHolder.getRequestAttributes();
+    Assert.state(attrs instanceof ServletRequestAttributes, "No current ServletRequestAttributes");
+    // <1> 获得 MediaType 数组
+    List<MediaType> requestedMediaTypes = getMediaTypes(((ServletRequestAttributes) attrs).getRequest());
+    if (requestedMediaTypes != null) {
+        // <2.1> 获得匹配的 View 数组
+        List<View> candidateViews = getCandidateViews(viewName, locale, requestedMediaTypes);
+        // <2.2> 筛选最匹配的 View 对象
+        View bestView = getBestView(candidateViews, requestedMediaTypes, attrs);
+        // 如果筛选成功，则返回
+        if (bestView != null) {
+            return bestView;
+        }
+    }
+
+    String mediaTypeInfo = logger.isDebugEnabled() && requestedMediaTypes != null ?
+            " given " + requestedMediaTypes.toString() : "";
+
+    // <3> 如果匹配不到 View 对象，则根据 useNotAcceptableStatusCode ，返回 NOT_ACCEPTABLE_VIEW 或 null 。
+    if (this.useNotAcceptableStatusCode) {
+        if (logger.isDebugEnabled()) {
+            logger.debug("Using 406 NOT_ACCEPTABLE" + mediaTypeInfo);
+        }
+        return NOT_ACCEPTABLE_VIEW;
+    } else {
+        logger.debug("View remains unresolved" + mediaTypeInfo);
+        return null;
+    }
+}
+```
+
+- `<1>` 处，调用 `#getCandidateViews(HttpServletRequest request)` 方法，获得 MediaType 数组。详细解析，见 [「4.4.1 getMediaTypes」](https://svip.iocoder.cn/Spring-MVC/ViewResolver/#) 。
+
+- `<2.1>` 处，调用 `#getCandidateViews(String viewName, Locale locale, List<MediaType> requestedMediaTypes)` 方法，获得匹配的 View 数组。详细解析，见 [「4.4.2 getCandidateViews」](https://svip.iocoder.cn/Spring-MVC/ViewResolver/#) 。
+
+- `<2.3>` 处，调用 `#getBestView(List<View> candidateViews, List<MediaType> requestedMediaTypes, RequestAttributes attrs)` 方法，筛选最匹配的 View 对象。详细解析，见 [「4.4.3 getBestView」](https://svip.iocoder.cn/Spring-MVC/ViewResolver/#) 。
+
+- `<3>` 处，如果匹配不到 View 对象，则根据 `useNotAcceptableStatusCode` ，返回 `NOT_ACCEPTABLE_VIEW` 或 `null` 。其中，`NOT_ACCEPTABLE_VIEW` 变量，代码如下：
+
+  ```
+  // ContentNegotiatingViewResolver.java
+  
+  private static final View NOT_ACCEPTABLE_VIEW = new View() {
+  
+      @Override
+      @Nullable
+      public String getContentType() {
+          return null;
+      }
+  
+      @Override
+      public void render(@Nullable Map<String, ?> model, HttpServletRequest request, HttpServletResponse response) {
+          response.setStatus(HttpServletResponse.SC_NOT_ACCEPTABLE);
+      }
+      
+  };
+  ```
+
+  - 这个视图的渲染，只会设置响应状态码为 `SC_NOT_ACCEPTABLE` 。
+
+😈 逻辑有丢丢上，胖友耐心了，嘿嘿。
+
+### 4.4.1 getMediaTypes
+
+`#getCandidateViews(HttpServletRequest request)` 方法，获得 MediaType 数组。代码如下：
+
+```
+// ContentNegotiatingViewResolver.java
+
+@Nullable
+protected List<MediaType> getMediaTypes(HttpServletRequest request) {
+    Assert.state(this.contentNegotiationManager != null, "No ContentNegotiationManager set");
+    try {
+        // 创建 ServletWebRequest 对象
+        ServletWebRequest webRequest = new ServletWebRequest(request);
+        // 从请求中，获得可接受的 MediaType 数组。默认实现是，从请求头 ACCEPT 中获取
+        List<MediaType> acceptableMediaTypes = this.contentNegotiationManager.resolveMediaTypes(webRequest);
+        // 获得可产生的 MediaType 数组
+        List<MediaType> producibleMediaTypes = getProducibleMediaTypes(request);
+        // 通过 acceptableTypes 来比对，将符合的 producibleType 添加到 mediaTypesToUse 结果数组中
+        Set<MediaType> compatibleMediaTypes = new LinkedHashSet<>();
+        for (MediaType acceptable : acceptableMediaTypes) {
+            for (MediaType producible : producibleMediaTypes) {
+                if (acceptable.isCompatibleWith(producible)) {
+                    compatibleMediaTypes.add(getMostSpecificMediaType(acceptable, producible));
+                }
+            }
+        }
+
+        // 按照 MediaType 的 specificity、quality 排序
+        List<MediaType> selectedMediaTypes = new ArrayList<>(compatibleMediaTypes);
+        MediaType.sortBySpecificityAndQuality(selectedMediaTypes);
+        return selectedMediaTypes;
+    } catch (HttpMediaTypeNotAcceptableException ex) {
+        if (logger.isDebugEnabled()) {
+            logger.debug(ex.getMessage());
+        }
+        return null;
+    }
+}
+
+@SuppressWarnings("unchecked")
+private List<MediaType> getProducibleMediaTypes(HttpServletRequest request) {
+    Set<MediaType> mediaTypes = (Set<MediaType>)
+            request.getAttribute(HandlerMapping.PRODUCIBLE_MEDIA_TYPES_ATTRIBUTE);
+    if (!CollectionUtils.isEmpty(mediaTypes)) {
+        return new ArrayList<>(mediaTypes);
+    } else {
+        return Collections.singletonList(MediaType.ALL);
+    }
+}
+
+/**
+ * Return the more specific of the acceptable and the producible media types
+ * with the q-value of the former.
+ */
+private MediaType getMostSpecificMediaType(MediaType acceptType, MediaType produceType) {
+    produceType = produceType.copyQualityValue(acceptType);
+    return (MediaType.SPECIFICITY_COMPARATOR.compare(acceptType, produceType) < 0 ? acceptType : produceType);
+}
+```
+
+- 逻辑虽然灰常长，但是在 [《精尽 Spring MVC 源码解析 —— HandlerAdapter 组件（四）之 HandlerMethodReturnValueHandler》](http://svip.iocoder.cn/Spring-MVC/HandlerAdapter-4-HandlerMethodArgumentResolver) 中的 [「5.4.1 HandlerMethodReturnValueHandler」](https://svip.iocoder.cn/Spring-MVC/ViewResolver/#) 中，已经看过类似的 MediaType 的匹配逻辑，所以就不重复赘述。
+
+### 4.4.2 getCandidateViews
+
+`#getCandidateViews(String viewName, Locale locale, List<MediaType> requestedMediaTypes)` 方法，获得匹配的 View 数组。代码如下：
+
+```
+// ContentNegotiatingViewResolver.java
+
+private List<View> getCandidateViews(String viewName, Locale locale, List<MediaType> requestedMediaTypes)
+        throws Exception {
+    // 创建 View 数组
+    List<View> candidateViews = new ArrayList<>();
+
+    // <1> 来源一，通过 viewResolvers 解析出 View 数组结果，添加到 candidateViews 中
+    if (this.viewResolvers != null) {
+        Assert.state(this.contentNegotiationManager != null, "No ContentNegotiationManager set");
+        // <1.1> 遍历 viewResolvers 数组
+        for (ViewResolver viewResolver : this.viewResolvers) {
+            // <1.2> 情况一，获得 View 对象，添加到 candidateViews 中
+            View view = viewResolver.resolveViewName(viewName, locale);
+            if (view != null) {
+                candidateViews.add(view);
+            }
+            // <1.3> 情况二，带有文拓展后缀的方式，获得 View 对象，添加到 candidateViews 中
+            // <1.3.1> 遍历 MediaType 数组
+            for (MediaType requestedMediaType : requestedMediaTypes) {
+                // <1.3.2> 获得 MediaType 对应的拓展后缀的数组
+                List<String> extensions = this.contentNegotiationManager.resolveFileExtensions(requestedMediaType);
+                // <1.3.3> 遍历拓展后缀的数组
+                for (String extension : extensions) {
+                    // <1.3.4> 带有文拓展后缀的方式，获得 View 对象，添加到 candidateViews 中
+                    String viewNameWithExtension = viewName + '.' + extension;
+                    view = viewResolver.resolveViewName(viewNameWithExtension, locale);
+                    if (view != null) {
+                        candidateViews.add(view);
+                    }
+                }
+            }
+        }
+    }
+
+    // <2> 来源二，添加 defaultViews 到 candidateViews 中
+    if (!CollectionUtils.isEmpty(this.defaultViews)) {
+        candidateViews.addAll(this.defaultViews);
+    }
+    return candidateViews;
+}
+```
+
+- `candidateViews` 属性，View 数组。下面，一共有两个来源。
+
+- ========== 来源一 ==========
+
+- ```
+  <1>
+  ```
+
+   
+
+  处，来源一，通过
+
+   
+
+  ```
+  viewResolvers
+  ```
+
+   
+
+  解析出 View 数组结果，添加到
+
+   
+
+  ```
+  candidateViews
+  ```
+
+   
+
+  中。
+
+  - `<1.1>` 处，遍历 `viewResolvers` 数组。
+
+  - 【重要】`<1.2>` 处，情况①，获得 View 对象，添加到 `candidateViews` 中。
+
+  - ```
+    <1.3>
+    ```
+
+     
+
+    处，情况②，带有文拓展后缀的方式，获得 View 对象，添加到
+
+     
+
+    ```
+    candidateViews
+    ```
+
+     
+
+    中。😈 当然，默认情况下，这个逻辑，我们可以无视，因为在
+
+     
+
+    ```
+    <1.3.2>
+    ```
+
+     
+
+    处，我们在
+
+    默认情况
+
+    下，并未配置 MediaType 对应的拓展后缀。
+
+    - `<1.3.1>` 处，遍历 MediaType 数组。
+    - `<1.3.2>` 处，获得 MediaType 对应的拓展后缀的数组。
+    - `<1.3.3>` 处，遍历拓展后缀的数组。
+    - 【重要】`<1.3.4>` 处，带有文拓展后缀的方式，获得 View 对象，添加到 `candidateViews` 中。
+
+- `<2>` 处，来源二，添加 `defaultViews` 到 `candidateViews` 中。
+
+### 4.4.3 getBestView
+
+`#getBestView(List<View> candidateViews, List<MediaType> requestedMediaTypes, RequestAttributes attrs)` 方法，筛选最匹配的 View 对象。代码如下：
+
+```
+// ContentNegotiatingViewResolver.java
+
+@Nullable
+private View getBestView(List<View> candidateViews, List<MediaType> requestedMediaTypes, RequestAttributes attrs) {
+    // <1> 遍历 candidateView 数组，如果有重定向的 View 类型，则返回它
+    for (View candidateView : candidateViews) {
+        if (candidateView instanceof SmartView) {
+            SmartView smartView = (SmartView) candidateView; // RedirectView 是 SmartView 的子类
+            if (smartView.isRedirectView()) {
+                return candidateView;
+            }
+        }
+    }
+    // <2> 遍历 requestedMediaTypes 数组
+    for (MediaType mediaType : requestedMediaTypes) {
+        // <2> 遍历 candidateViews 数组
+        for (View candidateView : candidateViews) {
+            if (StringUtils.hasText(candidateView.getContentType())) {
+                // <2.1> 如果 MediaType 类型匹配，则返回该 View 对象
+                MediaType candidateContentType = MediaType.parseMediaType(candidateView.getContentType());
+                if (mediaType.isCompatibleWith(candidateContentType)) {
+                    if (logger.isDebugEnabled()) {
+                        logger.debug("Selected '" + mediaType + "' given " + requestedMediaTypes);
+                    }
+                    attrs.setAttribute(View.SELECTED_CONTENT_TYPE, mediaType, RequestAttributes.SCOPE_REQUEST); // 设置匹配的 MediaType 到请求属性中
+                    return candidateView;
+                }
+            }
+        }
+    }
+    return null;
+}
+```
+
+- `<1>` 处，遍历 `candidateView` 数组，如果有**重定向**的 View 类型，则返回它。也就是说，**重定向**的 View ，优先级更高。
+- `<2>` 处，遍历 `requestedMediaTypes` 和 `candidateViews` 数组，**先找到**一个 MediaType 类型匹配，则返回该 View 对象，然后返回它。也就是说，优先级的匹配规则，由 ViewResolver 在 `viewResolvers` 的位置，越靠前，优先级越高。
+
+# 5. BeanNameViewResolver
+
+`org.springframework.web.servlet.view.BeanNameViewResolver` ，实现 ViewResolver、Ordered 接口，继承 WebApplicationObjectSupport 抽象类，基于 Bean 的名字获得 View 对象的 ViewResolver 实现类。
+
+## 5.1 构造方法
+
+```
+// BeanNameViewResolver.java
+
+/**
+ * 顺序，优先级最低
+ */
+private int order = Ordered.LOWEST_PRECEDENCE;  // default: same as non-Ordered
+```
+
+## 5.2 resolveViewName
+
+实现 `#resolveViewName(String viewName, Locale locale)` 方法，获得 Bean 的名字获得 View 对象。代码如下：
+
+```
+// BeanNameViewResolver.java
+
+@Override
+@Nullable
+public View resolveViewName(String viewName, Locale locale) throws BeansException {
+    // 如果 Bean 对应的 Bean 对象不存在，则返回 null
+    ApplicationContext context = obtainApplicationContext();
+    if (!context.containsBean(viewName)) {
+        // Allow for ViewResolver chaining...
+        return null;
+    }
+    // 如果 Bean 对应的 Bean 类型不是 View ，则返回 null
+    if (!context.isTypeMatch(viewName, View.class)) {
+        if (logger.isDebugEnabled()) {
+            logger.debug("Found bean named '" + viewName + "' but it does not implement View");
+        }
+        // Since we're looking into the general ApplicationContext here,
+        // let's accept this as a non-match and allow for chaining as well...
+        return null;
+    }
+    // 获得 Bean 名字对应的 View 对象
+    return context.getBean(viewName, View.class);
+}
+```
+
+# 6. ViewResolverComposite
+
+`org.springframework.web.servlet.view.ViewResolverComposite` ，实现 ViewResolver、Ordered、InitializingBean、ApplicationContextAware、ServletContextAware 接口，复合的 ViewResolver 实现类。
+
+## 6.1 构造方法
+
+```
+// ViewResolverComposite.java
+
+/**
+ * ViewResolver 数组
+ */
+private final List<ViewResolver> viewResolvers = new ArrayList<>();
+
+/**
+ * 顺序，优先级最低
+ */
+private int order = Ordered.LOWEST_PRECEDENCE;
+```
+
+## 6.2 afterPropertiesSet
+
+实现 `#afterPropertiesSet()` 方法，进一步初始化。代码如下：
+
+```
+// ViewResolverComposite.java
+
+@Override
+public void afterPropertiesSet() throws Exception {
+	for (ViewResolver viewResolver : this.viewResolvers) {
+		if (viewResolver instanceof InitializingBean) {
+			((InitializingBean) viewResolver).afterPropertiesSet();
+		}
+	}
+}
+```
+
+## 6.3 resolveViewName
+
+实现 `#resolveViewName(String viewName, Locale locale)` 方法，代码如下：
+
+```
+// ViewResolverComposite.java
+
+@Override
+@Nullable
+public View resolveViewName(String viewName, Locale locale) throws Exception {
+    // 遍历 viewResolvers 数组，逐个进行解析，但凡成功，则返回该 View 对象
+    for (ViewResolver viewResolver : this.viewResolvers) {
+        // 执行解析
+        View view = viewResolver.resolveViewName(viewName, locale);
+        // 解析成功，则返回该 View 对象
+        if (view != null) {
+            return view;
+        }
+    }
+    return null;
+}
+```
+
+# 7. AbstractCachingViewResolver
+
+`org.springframework.web.servlet.view.AbstractCachingViewResolver` ，实现 ViewResolver 接口，继承 WebApplicationObjectSupport 抽象类，提供通用的**缓存**的 ViewResolver 抽象类。对于相同的视图名，返回的是相同的 View 对象，所以通过缓存，可以进一步提供性能。
+
+## 7.1 构造方法
+
+```
+// AbstractCachingViewResolver.java
+
+/**
+ * Default maximum number of entries for the view cache: 1024.
+ */
+public static final int DEFAULT_CACHE_LIMIT = 1024;
+
+/**
+ * Dummy marker object for unresolved views in the cache Maps.
+ */
+private static final View UNRESOLVED_VIEW = new View() {
+
+    @Override
+    @Nullable
+    public String getContentType() {
+        return null;
+    }
+
+    @Override
+    public void render(@Nullable Map<String, ?> model, HttpServletRequest request, HttpServletResponse response) {
+    }
+
+};
+
+/**
+ * The maximum number of entries in the cache.
+ */
+private volatile int cacheLimit = DEFAULT_CACHE_LIMIT; // 缓存上限。如果 cacheLimit = 0 ，表示禁用缓存
+
+/**
+ * Whether we should refrain from resolving views again if unresolved once.
+ */
+private boolean cacheUnresolved = true; // 是否缓存空 View 对象
+
+/**
+ * Fast access cache for Views, returning already cached instances without a global lock.
+ * 
+ * View 的缓存的映射
+ *
+ * KEY：{@link #getCacheKey(String, Locale)}
+ */
+private final Map<Object, View> viewAccessCache = new ConcurrentHashMap<>(DEFAULT_CACHE_LIMIT);
+
+/**
+ * Map from view key to View instance, synchronized for View creation.
+ *
+ * View 的缓存的映射。相比 {@link #viewAccessCache} 来说，增加了 synchronized 锁
+ */
+@SuppressWarnings("serial")
+private final Map<Object, View> viewCreationCache =
+        new LinkedHashMap<Object, View>(DEFAULT_CACHE_LIMIT, 0.75f, true) {
+            @Override
+            protected boolean removeEldestEntry(Map.Entry<Object, View> eldest) {
+                // 如果超过上限，则从 viewAccessCache 中也移除
+                if (size() > getCacheLimit()) {
+                    viewAccessCache.remove(eldest.getKey());
+                    return true;
+                } else {
+                    return false;
+                }
+            }
+        };
+```
+
+- 大多数变量比较易懂。比较有趣的是 `viewAccessCache` 和 `viewCreationCache` 属性的存在。
+
+  - 通过 `viewAccessCache` 属性，提供更快的访问 View 缓存。
+
+  - 通过 `viewCreationCache` 属性，提供缓存的上限的功能。可能有胖友不太了解为什么 LinkedHashMap 能实现 LRU 缓存过期的功能，可以看看 [《LRU 缓存实现(Java)》](https://www.cnblogs.com/lzrabbit/p/3734850.html) 。
+
+  - KEY 是通过 `#getCacheKey(String viewName, Locale locale)` 方法，获得缓存 KEY 。代码如下：
+
+    ```
+    // AbstractCachingViewResolver.java
+    
+    /**
+     * Return the cache key for the given view name and the given locale.
+     * <p>Default is a String consisting of view name and locale suffix.
+     * Can be overridden in subclasses.
+     * <p>Needs to respect the locale in general, as a different locale can
+     * lead to a different view resource.
+     */
+    protected Object getCacheKey(String viewName, Locale locale) {
+        return viewName + '_' + locale;
+    }
+    ```
+
+    - 😈
+
+## 7.2 loadView
+
+`#loadView(String viewName, Locale locale)` **抽象**方法，加载 `viewName` 对应的 View 对象。代码如下：
+
+```
+// AbstractCachingViewResolver.java
+
+/**
+ * Subclasses must implement this method, building a View object
+ * for the specified view. The returned View objects will be
+ * cached by this ViewResolver base class.
+ * <p>Subclasses are not forced to support internationalization:
+ * A subclass that does not may simply ignore the locale parameter.
+ *
+ * @param viewName the name of the view to retrieve
+ * @param locale   the Locale to retrieve the view for
+ * @return the View instance, or {@code null} if not found
+ * (optional, to allow for ViewResolver chaining)
+ * @throws Exception if the view couldn't be resolved
+ * @see #resolveViewName
+ */
+@Nullable
+protected abstract View loadView(String viewName, Locale locale) throws Exception;
+```
+
+## 7.3 createView
+
+`#createView(String viewName, Locale locale)` 方法，创建 `viewName` 对应的 View 对象。代码如下：
+
+```
+// AbstractCachingViewResolver.java
+
+/**
+ * Create the actual View object.
+ * <p>The default implementation delegates to {@link #loadView}.
+ * This can be overridden to resolve certain view names in a special fashion,
+ * before delegating to the actual {@code loadView} implementation
+ * provided by the subclass.
+ *
+ * @param viewName the name of the view to retrieve
+ * @param locale   the Locale to retrieve the view for
+ * @return the View instance, or {@code null} if not found
+ * (optional, to allow for ViewResolver chaining)
+ * @throws Exception if the view couldn't be resolved
+ * @see #loadView
+ */
+@Nullable
+protected View createView(String viewName, Locale locale) throws Exception {
+    return loadView(viewName, locale);
+}
+```
+
+- 在方法内部，就会调用 [「7.2 loadView」](https://svip.iocoder.cn/Spring-MVC/ViewResolver/#) 方法。
+
+## 7.4 resolveViewName
+
+实现 `#resolveViewName(String viewName, Locale locale)` 方法，代码如下：
+
+```
+// AbstractCachingViewResolver.java
+
+@Override
+@Nullable
+public View resolveViewName(String viewName, Locale locale) throws Exception {
+    // 如果禁用缓存，则创建 viewName 对应的 View 对象
+    if (!isCache()) {
+        return createView(viewName, locale);
+    } else {
+        // 获得缓存 KEY
+        Object cacheKey = getCacheKey(viewName, locale);
+        // 从 viewAccessCache 缓存中，获得 View 对象
+        View view = this.viewAccessCache.get(cacheKey);
+        // 如果获得不到缓存，则从 viewCreationCache 中，获得 View 对象
+        if (view == null) {
+            // synchronized 锁
+            synchronized (this.viewCreationCache) {
+                // 从 viewCreationCache 中，获得 View 对象
+                view = this.viewCreationCache.get(cacheKey);
+                // 如果不存在，则创建 viewName 对应的 View 对象
+                if (view == null) {
+                    // Ask the subclass to create the View object.
+                    // 创建 viewName 对应的 View 对象
+                    view = createView(viewName, locale);
+                    // 如果创建失败，但是 cacheUnresolved 为 true ，则设置为 UNRESOLVED_VIEW
+                    if (view == null && this.cacheUnresolved) {
+                        view = UNRESOLVED_VIEW;
+                    }
+                    // 如果 view 非空，则添加到 viewAccessCache 缓存中
+                    if (view != null) {
+                        this.viewAccessCache.put(cacheKey, view);
+                        this.viewCreationCache.put(cacheKey, view);
+                    }
+                }
+            }
+        } else {
+            if (logger.isTraceEnabled()) {
+                logger.trace(formatKey(cacheKey) + "served from cache");
+            }
+        }
+        // 返回 view
+        return (view != UNRESOLVED_VIEW ? view : null);
+    }
+}
+```
+
+- 😈 虽然代码略长，但是逻辑还是非常清晰的。胖友自己瞅瞅，妥妥的。
+
+## 7.5 子类
+
+关于 AbstractCachingViewResolver 抽象类，有三个子类：
+
+- UrlBasedViewResolver
+- XmlViewResolver
+- ResourceBundleViewResolver
+
+其中，UrlBasedViewResolver 是相比更关键的子类，所以在 [「8. UrlBasedViewResolver」](https://svip.iocoder.cn/Spring-MVC/ViewResolver/#) 中，我们一起来瞅瞅。
+
+而另外两个子类，感兴趣的胖友，自己去看看罗。
+
+# 8. UrlBasedViewResolver
+
+`org.springframework.web.servlet.view.UrlBasedViewResolver` ，实现 Ordered 接口，继承 AbstractCachingViewResolver 抽象类，基于 Url 的 ViewResolver 实现类。
+
+## 8.1 构造方法
+
+```
+// UrlBasedViewResolver.java
+
+/**
+ * Prefix for special view names that specify a redirect URL (usually
+ * to a controller after a form has been submitted and processed).
+ * Such view names will not be resolved in the configured default
+ * way but rather be treated as special shortcut.
+ */
+public static final String REDIRECT_URL_PREFIX = "redirect:";
+
+/**
+ * Prefix for special view names that specify a forward URL (usually
+ * to a controller after a form has been submitted and processed).
+ * Such view names will not be resolved in the configured default
+ * way but rather be treated as special shortcut.
+ */
+public static final String FORWARD_URL_PREFIX = "forward:";
+
+/**
+ * View 的类型
+ *
+ * 不同的实现类，会对应一个 View 的类型
+ */
+@Nullable
+private Class<?> viewClass;
+
+/**
+ * 前缀
+ */
+private String prefix = "";
+/**
+ * 后缀
+ */
+private String suffix = "";
+
+/**
+ * ContentType 类型
+ */
+@Nullable
+private String contentType;
+
+/**
+ *
+ */
+private boolean redirectContextRelative = true;
+
+private boolean redirectHttp10Compatible = true;
+
+@Nullable
+private String[] redirectHosts;
+
+/**
+ * RequestAttributes 暴露给 View 使用时的属性
+ */
+@Nullable
+private String requestContextAttribute;
+
+@Nullable
+private Boolean exposeContextBeansAsAttributes;
+
+/** Map of static attributes, keyed by attribute name (String). */
+private final Map<String, Object> staticAttributes = new HashMap<>();
+
+/**
+ * 是否暴露路径变量给 View 使用
+ */
+@Nullable
+private Boolean exposePathVariables;
+
+@Nullable
+private String[] exposedContextBeanNames;
+
+/**
+ * 是否只处理指定的视图名们
+ */
+@Nullable
+private String[] viewNames;
+
+/**
+ * 顺序，优先级最低
+ */
+private int order = Ordered.LOWEST_PRECEDENCE;
+```
+
+- 那个，还是变量有点多，我们随着下面的方法，一起来瞅瞅。哈哈哈哈
+
+## 8.2 initApplicationContext
+
+实现 `#initApplicationContext()` 方法，进一步初始化。代码如下：
+
+```
+// UrlBasedViewResolver.java
+
+@Override
+protected void initApplicationContext() {
+    // 调用父类该方法，进行初始化
+	super.initApplicationContext();
+	// 校验 viewClass 非空
+	if (getViewClass() == null) {
+		throw new IllegalArgumentException("Property 'viewClass' is required");
+	}
+}
+```
+
+- 子类中，我们会看到，`viewClass` 属性一般会在构造中法中设置。
+
+## 8.3 getCacheKey
+
+重写 `#getCacheKey(String viewName, Locale locale)` 方法，忽略 `locale` 参数，仅仅使用 `viewName` 作为缓存 KEY 。代码如下：
+
+```
+// UrlBasedViewResolver.java
+
+@Override
+protected Object getCacheKey(String viewName, Locale locale) {
+	return viewName;
+}
+```
+
+😈 也就是说，不支持 Locale 特性。
+
+## 8.4 canHandle
+
+`#canHandle(String viewName, Locale locale)` 方法，判断传入的视图名是否可以被处理。代码如下：
+
+```
+// UrlBasedViewResolver.java
+
+protected boolean canHandle(String viewName, Locale locale) {
+	String[] viewNames = getViewNames();
+	return (viewNames == null || PatternMatchUtils.simpleMatch(viewNames, viewName));
+}
+```
+
+- 一般情况下，`viewNames` 为空，所以会满足 `viewNames == null` 代码块。也就说，所有视图名都可以被处理。
+
+## 8.5 applyLifecycleMethods
+
+`#applyLifecycleMethods(String viewName, AbstractUrlBasedView view)` 方法，代码如下：
+
+```
+// UrlBasedViewResolver.java
+
+protected View applyLifecycleMethods(String viewName, AbstractUrlBasedView view) {
+    // 情况一，如果 viewName 有对应的 View Bean 对象，则使用它
+    ApplicationContext context = getApplicationContext();
+    if (context != null) {
+        Object initialized = context.getAutowireCapableBeanFactory().initializeBean(view, viewName);
+        if (initialized instanceof View) {
+            return (View) initialized;
+        }
+    }
+    // 情况二，直接返回 view
+    return view;
+}
+```
+
+这个方法的逻辑比较易懂，但是不太明白具体的使用场景。😈 感觉先不用理解它的用途也可以。
+
+## 8.6 createView
+
+重写 `#createView(String viewName, Locale locale)` 方法，增加了对 REDIRECT、FORWARD 的情况的处理。代码如下：
+
+```
+// UrlBasedViewResolver.java
+
+@Override
+protected View createView(String viewName, Locale locale) throws Exception {
+    // If this resolver is not supposed to handle the given view,
+    // return null to pass on to the next resolver in the chain.
+    // 判断当前视图是否可以处理
+    if (!canHandle(viewName, locale)) {
+        return null;
+    }
+
+    // Check for special "redirect:" prefix.
+    // 如果是 REDIRECT 开头，创建 RedirectView 视图
+    if (viewName.startsWith(REDIRECT_URL_PREFIX)) {
+        // 创建 RedirectView 对象
+        String redirectUrl = viewName.substring(REDIRECT_URL_PREFIX.length());
+        RedirectView view = new RedirectView(redirectUrl,
+                isRedirectContextRelative(), isRedirectHttp10Compatible());
+        // 设置 RedirectView 对象的 hosts 属性
+        String[] hosts = getRedirectHosts();
+        if (hosts != null) {
+            view.setHosts(hosts);
+        }
+        // 应用
+        return applyLifecycleMethods(REDIRECT_URL_PREFIX, view);
+    }
+
+    // Check for special "forward:" prefix.
+    // 如果是 FORWARD 开头，创建 InternalResourceView 视图
+    if (viewName.startsWith(FORWARD_URL_PREFIX)) {
+        // 创建 InternalResourceView 对象
+        String forwardUrl = viewName.substring(FORWARD_URL_PREFIX.length());
+        InternalResourceView view = new InternalResourceView(forwardUrl);
+        // 应用
+        return applyLifecycleMethods(FORWARD_URL_PREFIX, view);
+    }
+
+    // Else fall back to superclass implementation: calling loadView.
+    // 创建视图名对应的 View 对象
+    return super.createView(viewName, locale);
+}
+```
+
+## 8.9 loadView
+
+实现 `#loadView(String viewName, Locale locale)` 方法，加载 viewName 对应的 View 对象。代码如下：
+
+```
+// UrlBasedViewResolver.java
+
+@Override
+protected View loadView(String viewName, Locale locale) throws Exception {
+    // <x> 创建 viewName 对应的 View 对象
+	AbstractUrlBasedView view = buildView(viewName);
+	// 应用
+	View result = applyLifecycleMethods(viewName, view);
+	// 返回
+	return (view.checkResource(locale) ? result : null);
+}
+```
+
+- 其中，`<x>` 处，调用 `#buildView(String viewName)` 方法，创建 `viewName` 对应的 View 对象。代码如下：
+
+  ```
+  // UrlBasedViewResolver.java
+  
+  protected AbstractUrlBasedView buildView(String viewName) throws Exception {
+      Class<?> viewClass = getViewClass();
+      Assert.state(viewClass != null, "No view class");
+  
+      // 创建 AbstractUrlBasedView 对象
+      AbstractUrlBasedView view = (AbstractUrlBasedView) BeanUtils.instantiateClass(viewClass);
+  
+      // 设置各种属性
+  
+      view.setUrl(getPrefix() + viewName + getSuffix());
+  
+      String contentType = getContentType();
+      if (contentType != null) {
+          view.setContentType(contentType);
+      }
+  
+      view.setRequestContextAttribute(getRequestContextAttribute());
+      view.setAttributesMap(getAttributesMap());
+  
+      Boolean exposePathVariables = getExposePathVariables();
+      if (exposePathVariables != null) {
+          view.setExposePathVariables(exposePathVariables);
+      }
+      Boolean exposeContextBeansAsAttributes = getExposeContextBeansAsAttributes();
+      if (exposeContextBeansAsAttributes != null) {
+          view.setExposeContextBeansAsAttributes(exposeContextBeansAsAttributes);
+      }
+      String[] exposedContextBeanNames = getExposedContextBeanNames();
+      if (exposedContextBeanNames != null) {
+          view.setExposedContextBeanNames(exposedContextBeanNames);
+      }
+  
+      return view;
+  }
+  ```
+
+## 8.10 requiredViewClass
+
+`#requiredViewClass()` 方法，定义了产生的视图。代码如下：
+
+```
+// UrlBasedViewResolver.java
+
+protected Class<?> requiredViewClass() {
+	return AbstractUrlBasedView.class;
+}
+```
+
+## 8.11 子类
+
+关于 UrlBasedViewResolver 抽象类，有三个子类：
+
+- AbstractTemplateViewResolver
+- InternalResourceViewResolver
+- TilesViewResolver
+- ScriptTemplateViewResolver
+- XsltViewResolver
+
+其中，InternalResourceViewResolver 和 AbstractTemplateViewResolver 是相比更关键的子类，所以在 [「9. InternalResourceViewResolver」](https://svip.iocoder.cn/Spring-MVC/ViewResolver/#) 和 [「10. AbstractTemplateViewResolver」](https://svip.iocoder.cn/Spring-MVC/ViewResolver/#) 中，我们一起来瞅瞅。
+
+而另外三个子类，感兴趣的胖友，自己去看看罗。
+
+# 9. InternalResourceViewResolver
+
+`org.springframework.web.servlet.view.InternalResourceViewResolver` ，继承 UrlBasedViewResolver 类，解析出 JSP 的 ViewResolver 实现类。
+
+## 9.1 构造方法
+
+```
+// InternalResourceViewResolver.java
+
+/**
+ * 判断 javax.servlet.jsp.jstl.core.Config 是否存在
+ */
+private static final boolean jstlPresent = ClassUtils.isPresent(
+        "javax.servlet.jsp.jstl.core.Config", InternalResourceViewResolver.class.getClassLoader());
+
+@Nullable
+private Boolean alwaysInclude;
+
+public InternalResourceViewResolver() {
+    // 获得 viewClass
+    Class<?> viewClass = requiredViewClass();
+    if (InternalResourceView.class == viewClass && jstlPresent) {
+        viewClass = JstlView.class;
+    }
+    // 设置 viewClass
+    setViewClass(viewClass);
+}
+
+public InternalResourceViewResolver(String prefix, String suffix) {
+    this();
+    setPrefix(prefix);
+    setSuffix(suffix);
+}
+
+@Override
+protected Class<?> requiredViewClass() {
+    return InternalResourceView.class;
+}
+```
+
+- 从构造方法中，可以看出，视图名会是 InternalResourceView 或 JstlView 类。😈 实际上，JstlView 是 InternalResourceView 的子类。
+
+## 9.2 buildView
+
+重写 `#buildView(String viewName)` 方法，代码如下：
+
+```
+// InternalResourceViewResolver.java
+
+@Override
+protected AbstractUrlBasedView buildView(String viewName) throws Exception {
+    // 调用父方法
+    InternalResourceView view = (InternalResourceView) super.buildView(viewName);
+
+    // 设置 View 对象的相关属性
+    if (this.alwaysInclude != null) {
+        view.setAlwaysInclude(this.alwaysInclude);
+    }
+    view.setPreventDispatchLoop(true);
+    return view;
+}
+```
+
+- 增加设置两个属性。
+
+# 10. AbstractTemplateViewResolver
+
+`org.springframework.web.servlet.view.AbstractTemplateViewResolver` ，继承 UrlBasedViewResolver 类，解析出 AbstractTemplateView 的 ViewResolver 抽象类。
+
+## 10.1 构造方法
+
+```
+// AbstractTemplateViewResolver.java
+
+/**
+ * 是否将所有 RequestAttributes 暴露给 View 使用
+ */
+private boolean exposeRequestAttributes = false;
+/**
+ * 当 RequestAttributes 中存在 Model 中同名的参数，是否允许使用 RequestAttributes 中的值将 Model 中的值进行覆盖
+ *
+ * {@link #exposeRequestAttributes}
+ */
+private boolean allowRequestOverride = false;
+
+/**
+ * 是否将 SessionAttributes 暴露给 View 使用
+ */
+private boolean exposeSessionAttributes = false;
+/**
+ * 当 SessionAttributes 中存在 Model 中同名的参数，是否允许使用 SessionAttributes 中的值将 Model 中的值进行覆盖
+ *
+ * {@link #exposeSessionAttributes}
+ */
+private boolean allowSessionOverride = false;
+
+/**
+ * 是否将 RequestContext 暴露给 view 为 spring 的宏( Macro )所使用
+ */
+private boolean exposeSpringMacroHelpers = true;
+```
+
+## 10.2 requiredViewClass
+
+重写 `#requiredViewClass()` 方法，返回 AbstractTemplateView 类。代码如下：
+
+```
+// AbstractTemplateViewResolver.java
+
+@Override
+protected Class<?> requiredViewClass() {
+	return AbstractTemplateView.class;
+}
+```
+
+## 10.3 buildView
+
+重写 `#buildView(String viewName)` 方法，代码如下：
+
+```
+// AbstractTemplateViewResolver.java
+
+@Override
+protected AbstractUrlBasedView buildView(String viewName) throws Exception {
+    // 调用父类方法，创建 AbstractTemplateView 对象
+    AbstractTemplateView view = (AbstractTemplateView) super.buildView(viewName);
+
+    // 设置相关属性
+    view.setExposeRequestAttributes(this.exposeRequestAttributes);
+    view.setAllowRequestOverride(this.allowRequestOverride);
+    view.setExposeSessionAttributes(this.exposeSessionAttributes);
+    view.setAllowSessionOverride(this.allowSessionOverride);
+    view.setExposeSpringMacroHelpers(this.exposeSpringMacroHelpers);
+    return view;
+}
+```
+
+- 增加设置五个属性。
+
+## 10.4 子类
+
+关于 AbstractTemplateViewResolver 抽象类，有二个子类：
+
+- FreeMarkerViewResolver
+
+  ```
+  // FreeMarkerViewResolver.java
+  
+  public class FreeMarkerViewResolver extends AbstractTemplateViewResolver {
+  
+  	public FreeMarkerViewResolver() {
+  		setViewClass(requiredViewClass());
+  	}
+  
+  	public FreeMarkerViewResolver(String prefix, String suffix) {
+  		this();
+  		setPrefix(prefix);
+  		setSuffix(suffix);
+  	}
+  
+  	/**
+  	 * Requires {@link FreeMarkerView}.
+  	 */
+  	@Override
+  	protected Class<?> requiredViewClass() {
+  		return FreeMarkerView.class;
+  	}
+  
+  }
+  ```
+
+- GroovyMarkupViewResolver
+
+  ```
+  // GroovyMarkupViewResolver.java
+  
+  public class GroovyMarkupViewResolver extends AbstractTemplateViewResolver {
+  
+  	public GroovyMarkupViewResolver() {
+  		setViewClass(requiredViewClass());
+  	}
+  
+  	public GroovyMarkupViewResolver(String prefix, String suffix) {
+  		this();
+  		setPrefix(prefix);
+  		setSuffix(suffix);
+  	}
+  
+  
+  	@Override
+  	protected Class<?> requiredViewClass() {
+  		return GroovyMarkupView.class;
+  	}
+  
+  	/**
+  	 * This resolver supports i18n, so cache keys should contain the locale.
+  	 */
+  	@Override
+  	protected Object getCacheKey(String viewName, Locale locale) {
+  		return viewName + '_' + locale;
+  	}
+  
+  }
+  ```
+
+# 666. 彩蛋
+
+本文涉及的，还有一个非常重要的组件没有进行分享，`org.springframework.web.servlet.View` 体系。整体类图如下：[![类图](23-Spring MVC 源码解析-ViewResolver 组件.assets/02.png)](http://static.iocoder.cn/images/Spring/2022-06-13/02.png)类图
+
+艿艿暂时不会去详细解析这块。😈 估计，也没什么人感兴趣，哈哈哈哈。
+
+参考和推荐如下文章：
+
+- 韩路彪 [《看透 Spring MVC：源代码分析与实践》](https://item.jd.com/11807414.html) 的 [「第14章 ViewResolver」](https://svip.iocoder.cn/Spring-MVC/ViewResolver/#) 小节
\ No newline at end of file
diff --git a/springmvc/24-Spring MVC 源码解析-MultipartResolver 组件.assets/01.png b/springmvc/24-Spring MVC 源码解析-MultipartResolver 组件.assets/01.png
new file mode 100644
index 0000000..be8bef4
Binary files /dev/null and b/springmvc/24-Spring MVC 源码解析-MultipartResolver 组件.assets/01.png differ
diff --git a/springmvc/24-Spring MVC 源码解析-MultipartResolver 组件.md b/springmvc/24-Spring MVC 源码解析-MultipartResolver 组件.md
new file mode 100644
index 0000000..dce71b5
--- /dev/null
+++ b/springmvc/24-Spring MVC 源码解析-MultipartResolver 组件.md	
@@ -0,0 +1,336 @@
+# 精尽 Spring MVC 源码解析 —— MultipartResolver 组件
+
+# 1. 概述
+
+本文，我们来分享 MultipartResolver 组件。在 [《精尽 Spring MVC 源码分析 —— 组件一览》](http://svip.iocoder.cn/Spring-MVC/Components-intro) 中，我们对它已经做了介绍：
+
+`org.springframework.web.multipart.MultipartResolver` ，内容类型( `Content-Type` )为 `multipart/*` 的请求的解析器接口。
+
+例如，文件上传请求，MultipartResolver 会将 HttpServletRequest 封装成 MultipartHttpServletRequest ，这样从 MultipartHttpServletRequest 中获得上传的文件。具体的使用示例，参见 [《spring-boot 上传文件 MultiPartFile 获取不到文件问题解决》](https://blog.csdn.net/happy_cheng/article/details/54178392)
+
+关于内容类型( `Content-Type` )为 `multipart/*` ，胖友可以看看 [《HTTP 协议之 multipart/form-data 请求分析》](https://blog.csdn.net/five3/article/details/7181521) 文章。
+
+MultipartResolver 接口，代码如下：
+
+```
+// MultipartResolver.java
+
+public interface MultipartResolver {
+
+    /**
+     * 是否为 multipart 请求
+     */
+    boolean isMultipart(HttpServletRequest request);
+
+    /**
+     * 将 HttpServletRequest 请求封装成 MultipartHttpServletRequest 对象
+     */
+    MultipartHttpServletRequest resolveMultipart(HttpServletRequest request) throws MultipartException;
+
+    /**
+     * 清理处理 multipart 产生的资源，例如临时文件
+     *
+     */
+    void cleanupMultipart(MultipartHttpServletRequest request);
+
+}
+```
+
+# 2. 类图
+
+MultipartResolver 的体系结构如下：[![MultipartResolver 类图](24-Spring MVC 源码解析-MultipartResolver 组件.assets/01.png)](http://static.iocoder.cn/images/Spring/2022-06-16/01.png)MultipartResolver 类图
+
+一共有两块：
+
+- 上半部分，MultipartRequest 接口及其实现类
+- 下半部分，MultipartResolver 接口以及其实现类
+
+# 3. 初始化
+
+我们以**默认配置的 Spring Boot 场景**下为例，来一起看看 DispatcherServlet 的 `#initMultipartResolver(ApplicationContext context)` 方法，初始化 `multipartResolver` 变量。代码如下：
+
+```
+// DispatcherServlet.java
+
+/** MultipartResolver used by this servlet. */
+@Nullable
+private MultipartResolver multipartResolver;
+
+private void initMultipartResolver(ApplicationContext context) {
+	try {
+	    // 获得 MULTIPART_RESOLVER_BEAN_NAME 对应的 MultipartResolver Bean 对象
+		this.multipartResolver = context.getBean(MULTIPART_RESOLVER_BEAN_NAME, MultipartResolver.class);
+		if (logger.isTraceEnabled()) {
+			logger.trace("Detected " + this.multipartResolver);
+		} else if (logger.isDebugEnabled()) {
+			logger.debug("Detected " + this.multipartResolver.getClass().getSimpleName());
+		}
+	} catch (NoSuchBeanDefinitionException ex) {
+		// Default is no multipart resolver.
+		this.multipartResolver = null;
+		if (logger.isTraceEnabled()) {
+			logger.trace("No MultipartResolver '" + MULTIPART_RESOLVER_BEAN_NAME + "' declared");
+		}
+	}
+}
+```
+
+- 默认情况下，`multipartResolver` 对应的是 StandardServletMultipartResolver 类的 Bean 对象。
+
+# 4. StandardServletMultipartResolver
+
+`org.springframework.web.multipart.support.StandardServletMultipartResolver` ，实现 MultipartResolver 接口，使用 Servlet 3.0 标准的上传 API 的 MultipartResolver 实现类。
+
+## 4.1 构造方法
+
+```
+// StandardServletMultipartResolver.java
+
+/**
+ * 是否延迟解析
+ */
+private boolean resolveLazily = false;
+```
+
+- `resolveLazily` 属性，是否延迟解析。什么意思呢？就是是否在需要获得对应文件时，在进行文件的解析。
+
+## 4.2 isMultipart
+
+实现 `#isMultipart(HttpServletRequest request)` 方法，代码如下：
+
+```
+// StandardServletMultipartResolver.java
+
+@Override
+public boolean isMultipart(HttpServletRequest request) {
+	return StringUtils.startsWithIgnoreCase(request.getContentType(), "multipart/");
+}
+```
+
+## 4.3 resolveMultipart
+
+实现 `#resolveMultipart(HttpServletRequest request)` 方法，创建 StandardMultipartHttpServletRequest 对象。代码如下：
+
+```
+// StandardServletMultipartResolver.java
+
+@Override
+public MultipartHttpServletRequest resolveMultipart(HttpServletRequest request) throws MultipartException {
+	return new StandardMultipartHttpServletRequest(request, this.resolveLazily);
+}
+```
+
+- 如果此处传入的 `resolveLazily = true` ，则不会进行解析。
+- 关于 StandardMultipartHttpServletRequest 类，在 [「4.5 StandardMultipartHttpServletRequest」](https://svip.iocoder.cn/Spring-MVC/MultipartResolver/#) 中，详细解析。
+
+## 4.4 cleanupMultipart
+
+实现 `#cleanupMultipart(MultipartHttpServletRequest request)` 方法，删除临时的 `javax.servlet.http.Part` 们。代码如下：
+
+```
+// StandardServletMultipartResolver.java
+
+@Override
+public void cleanupMultipart(MultipartHttpServletRequest request) {
+    if (!(request instanceof AbstractMultipartHttpServletRequest) ||
+            ((AbstractMultipartHttpServletRequest) request).isResolved()) {
+        // To be on the safe side: explicitly delete the parts,
+        // but only actual file parts (for Resin compatibility)
+        try {
+            // 删除临时的 Part 们
+            for (Part part : request.getParts()) {
+                if (request.getFile(part.getName()) != null) {
+                    part.delete();
+                }
+            }
+        } catch (Throwable ex) {
+            LogFactory.getLog(getClass()).warn("Failed to perform cleanup of multipart items", ex);
+        }
+    }
+}
+```
+
+## 4.5 StandardMultipartHttpServletRequest
+
+`org.springframework.web.multipart.support.StandardMultipartHttpServletRequest` ，继承 AbstractMultipartHttpServletRequest 抽象类，基于 Servlet 3.0 的 Multipart HttpServletRequest 实现类。
+
+### 4.5.1 构造方法
+
+```
+// StandardMultipartHttpServletRequest.java
+
+/**
+ * 普通参数名的集合
+ */
+@Nullable
+private Set<String> multipartParameterNames;
+
+public StandardMultipartHttpServletRequest(HttpServletRequest request) throws MultipartException {
+	this(request, false);
+}
+
+public StandardMultipartHttpServletRequest(HttpServletRequest request, boolean lazyParsing)
+		throws MultipartException {
+	super(request);
+	// <1> 如果不延迟加载，则解析请求
+	if (!lazyParsing) {
+		parseRequest(request);
+	}
+}
+```
+
+- `multipartParameterNames` 属性，普通参数名的集合。普通参数名，指的是非上传文件的参数名。
+- `<1>` 处，如果不延迟加载，调用 `#parseRequest(HttpServletRequest request)` 方法，则解析请求。详细解析，见 [「4.5.2 parseRequest」](https://svip.iocoder.cn/Spring-MVC/MultipartResolver/#) 。
+
+### 4.5.2 parseRequest
+
+`#parseRequest(HttpServletRequest request)` 方法，解析请求。代码如下：
+
+```
+// StandardMultipartHttpServletRequest.java
+
+private void parseRequest(HttpServletRequest request) {
+    try {
+        Collection<Part> parts = request.getParts();
+        this.multipartParameterNames = new LinkedHashSet<>(parts.size());
+        MultiValueMap<String, MultipartFile> files = new LinkedMultiValueMap<>(parts.size());
+
+        // <1> 遍历 parts 数组
+        for (Part part : parts) {
+            // <1.1> 获得 CONTENT_DISPOSITION 头的值
+            String headerValue = part.getHeader(HttpHeaders.CONTENT_DISPOSITION);
+            // <1.2> 获得 ContentDisposition 对象
+            ContentDisposition disposition = ContentDisposition.parse(headerValue);
+            // <1.3> 获得文件名
+            String filename = disposition.getFilename();
+            // <1.4> 情况一，文件名非空，说明是文件参数，则创建 StandardMultipartFile 对象，添加到 files 中
+            if (filename != null) {
+                if (filename.startsWith("=?") && filename.endsWith("?=")) {
+                    filename = MimeDelegate.decode(filename);
+                }
+                files.add(part.getName(), new StandardMultipartFile(part, filename));
+            // <1.5> 情况二，文件名为空，说明是普通参数，则添加 part.name 到 multipartParameterNames 中
+            } else {
+                this.multipartParameterNames.add(part.getName());
+            }
+        }
+        // <2> 设置到 multipartFiles 属性
+        setMultipartFiles(files);
+    } catch (Throwable ex) {
+        // <3>
+        handleParseFailure(ex);
+    }
+}
+```
+
+- ```
+  <1>
+  ```
+
+   
+
+  处，遍历
+
+   
+
+  ```
+  parts
+  ```
+
+   
+
+  数组，逐个解析参数。
+
+  - `<1.1>` 处，获得 `CONTENT_DISPOSITION` 头的值。
+  - `<1.2>` 处，调用 `ContentDisposition#parse(String contentDisposition)` 方法，获得 ContentDisposition 对象。这个方法，暂时不细讲，感兴趣的胖友，自己去瞅瞅。
+  - `<1.3>` 处，获得文件名。
+  - `<1.4>` 处，情况一，文件名非空，说明是**文件参数**，则创建 StandardMultipartFile 对象，添加到 `files` 中。其中，StandardMultipartFile 是 StandardMultipartHttpServletRequest 的内部类，点击 [传送门](https://github.com/spring-projects/spring-framework/blob/master/spring-web/src/main/java/org/springframework/web/multipart/support/StandardMultipartHttpServletRequest.java#L206-L271) 链接，胖友瞅瞅。
+  - `<1.5>` 处，情况二，文件名为空，说明是**普通参数**，则添加 `part.name` 到 `multipartParameterNames` 中。
+
+- `<2>` 处，调用父类 AbstractMultipartHttpServletRequest 的 `#setMultipartFiles(MultiValueMap<String, MultipartFile> multipartFiles)` 方法，设置 `multipartFiles` 属性。代码如下：
+
+  ```
+  // AbstractMultipartHttpServletRequest.java
+  
+  @Nullable
+  private MultiValueMap<String, MultipartFile> multipartFiles;
+  
+  protected final void setMultipartFiles(MultiValueMap<String, MultipartFile> multipartFiles) {
+  	this.multipartFiles =
+  			new LinkedMultiValueMap<>(Collections.unmodifiableMap(multipartFiles));
+  }
+  ```
+
+- `<3>` 处，如果发生异常，调用 `#handleParseFailure(Throwable ex)` 方法，抛出封装的异常。代码如下：
+
+  ```
+  // StandardMultipartHttpServletRequest.java.java
+  
+  protected void handleParseFailure(Throwable ex) {
+  	String msg = ex.getMessage();
+  	if (msg != null && msg.contains("size") && msg.contains("exceed")) {
+  		throw new MaxUploadSizeExceededException(-1, ex);
+  	}
+  	throw new MultipartException("Failed to parse multipart servlet request", ex);
+  }
+  ```
+
+### 4.5.3 initializeMultipart
+
+如果我们开启 `lazyParsing` 延迟解析的功能，则可通过 `multipartParameterNames` 属性是否为 `null` 来判断，是否已经初始化。示例代码如下：
+
+```
+// StandardMultipartHttpServletRequest.java.java
+
+if (this.multipartParameterNames == null) {
+	initializeMultipart();
+}
+```
+
+其中，实现 `#initializeMultipart()` 方法，内部调用 `#parseRequest(HttpServletRequest request)` 方法，解析请求。代码如下：
+
+```
+// StandardMultipartHttpServletRequest.java
+
+@Override
+protected void initializeMultipart() {
+	parseRequest(getRequest());
+}
+```
+
+### 4.5.4 getFile
+
+`#getFile(String name)` 方法，是由父类 AbstractMultipartHttpServletRequest 统一实现，代码如下：
+
+```
+// StandardMultipartHttpServletRequest.java
+
+@Override
+public MultipartFile getFile(String name) {
+	return getMultipartFiles().getFirst(name);
+}
+
+protected MultiValueMap<String, MultipartFile> getMultipartFiles() {
+	// 如果未初始化，则进行初始化
+    if (this.multipartFiles == null) {
+		initializeMultipart();
+	}
+	// 返回
+	return this.multipartFiles;
+}
+```
+
+# 5. CommonsMultipartResolver
+
+`org.springframework.web.multipart.commons.CommonsMultipartResolver` ，实现 MultipartResolver、ServletContextAware 接口，继承 CommonsFileUploadSupport 抽象类，基于 [`commons-fileupload`](http://commons.apache.org/proper/commons-fileupload) 的 Multipart HttpServletRequest 实现类。
+
+因为不是**默认**的 MultipartResolver 实现类，所以这里就不展开分享。感兴趣的胖友呢？还是可以自己去瞅瞅。当然，艿艿自己也没看，哈哈哈哈。
+
+# 666. 彩蛋
+
+😈 写的有点不嗨皮，T T
+
+参考和推荐如下文章：
+
+- 乒乓狂魔 [SpringMVC 文件上传接口设计与实现](https://my.oschina.net/pingpangkuangmo/blog/381113) 写的比较有趣！
+- 韩路彪 [《看透 Spring MVC：源代码分析与实践》](https://item.jd.com/11807414.html) 的 [「第17章 MultipartResolver」](https://svip.iocoder.cn/Spring-MVC/MultipartResolver/#) 小节
\ No newline at end of file
diff --git a/springmvc/file-create.py b/springmvc/file-create.py
new file mode 100644
index 0000000..a412975
--- /dev/null
+++ b/springmvc/file-create.py
@@ -0,0 +1,27 @@
+import os
+import pyperclip
+
+# 获取当前脚本的路径
+script_dir = os.path.dirname(os.path.abspath(__file__))
+
+# 从剪贴板获取文件名列表，假设每行一个文件名
+file_names = pyperclip.paste().strip().split('\n')
+
+# 遍历文件名列表，为每个文件名添加排序前缀并创建文件
+for index, file_name in enumerate(file_names, start=1):
+    # 去除文件名两端的空白字符
+    file_name = file_name.strip()
+    
+    # 添加排序前缀和.md后缀
+    file_name_with_prefix = f"{index:02d}-{file_name}.md"  # 这里使用3位数的排序前缀，可以根据需要调整
+    
+    # 构建文件的完整路径
+    file_path = os.path.join(script_dir, file_name_with_prefix)
+    
+    # 创建文件
+    with open(file_path, 'w') as file:
+        # 如果需要写入初始内容，可以在这里添加
+        # 例如：file.write("This is the content of the file.")
+        pass  # 如果不需要写入内容，则使用pass
+
+print(f"Files created successfully in {script_dir}")
\ No newline at end of file
diff --git a/springmvc/tmp.txt b/springmvc/tmp.txt
new file mode 100644
index 0000000..ba47aac
--- /dev/null
+++ b/springmvc/tmp.txt
@@ -0,0 +1,24 @@
+Spring MVC 面试题
+Spring MVC 学习指南
+Spring MVC 源码分析-调试环境搭建
+Spring MVC 源码分析-容器的初始化（一）之 Root WebApplicationContext 容器
+Spring MVC 源码分析-容器的初始化（二）之 Servlet WebApplicationContext 容器
+Spring MVC 源码分析-容器的初始化（三）之 Servlet 3.0 集成
+Spring MVC 源码分析-容器的初始化（四）之 Spring Boot 集成
+Spring MVC 源码分析-组件一览
+Spring MVC 源码分析-请求处理一览
+Spring MVC 源码分析-HandlerMapping 组件（一）之 AbstractHandlerMapping
+Spring MVC 源码分析-HandlerMapping 组件（二）之 HandlerInterceptor
+Spring MVC 源码解析-HandlerMapping 组件（三）之 AbstractHandlerMethodMapping
+Spring MVC 源码解析-HandlerMapping 组件（四）之 AbstractUrlHandlerMapping
+Spring MVC 源码解析-HandlerAdapter 组件（一）之 HandlerAdapter
+Spring MVC 源码解析-HandlerAdapter 组件（二）之 ServletInvocableHandlerMethod
+Spring MVC 源码解析-HandlerAdapter 组件（三）之 HandlerMethodArgumentResolver
+Spring MVC 源码解析-HandlerAdapter 组件（四）之 HandlerMethodReturnValueHandler
+Spring MVC 源码解析-HandlerAdapter 组件（五）之 HttpMessageConverter
+Spring MVC 源码解析-HandlerExceptionResolver 组件
+Spring MVC 源码解析-RequestToViewNameTranslator 组件
+Spring MVC 源码解析-LocaleResolver 组件
+Spring MVC 源码解析-ThemeResolver 组件
+Spring MVC 源码解析-ViewResolver 组件
+Spring MVC 源码解析-MultipartResolver 组件
\ No newline at end of file
diff --git a/学习指南/01-学习指南.assets/01.png b/学习指南/01-学习指南.assets/01.png
new file mode 100644
index 0000000..5e7392d
Binary files /dev/null and b/学习指南/01-学习指南.assets/01.png differ
diff --git a/学习指南/01-学习指南.assets/02.png b/学习指南/01-学习指南.assets/02.png
new file mode 100644
index 0000000..f349f5c
Binary files /dev/null and b/学习指南/01-学习指南.assets/02.png differ
diff --git a/学习指南/01-学习指南.assets/03.png b/学习指南/01-学习指南.assets/03.png
new file mode 100644
index 0000000..90c6a42
Binary files /dev/null and b/学习指南/01-学习指南.assets/03.png differ
diff --git a/学习指南/01-学习指南.assets/04.png b/学习指南/01-学习指南.assets/04.png
new file mode 100644
index 0000000..4011b17
Binary files /dev/null and b/学习指南/01-学习指南.assets/04.png differ
diff --git a/学习指南/01-学习指南.assets/05.png b/学习指南/01-学习指南.assets/05.png
new file mode 100644
index 0000000..5bf70cf
Binary files /dev/null and b/学习指南/01-学习指南.assets/05.png differ
diff --git a/学习指南/01-学习指南.assets/06.png b/学习指南/01-学习指南.assets/06.png
new file mode 100644
index 0000000..fa3c97c
Binary files /dev/null and b/学习指南/01-学习指南.assets/06.png differ
diff --git a/学习指南/01-学习指南.assets/07.png b/学习指南/01-学习指南.assets/07.png
new file mode 100644
index 0000000..8f2b141
Binary files /dev/null and b/学习指南/01-学习指南.assets/07.png differ
diff --git a/学习指南/01-学习指南.assets/08.png b/学习指南/01-学习指南.assets/08.png
new file mode 100644
index 0000000..537a787
Binary files /dev/null and b/学习指南/01-学习指南.assets/08.png differ
diff --git a/学习指南/01-学习指南.md b/学习指南/01-学习指南.md
new file mode 100644
index 0000000..bd9d98b
--- /dev/null
+++ b/学习指南/01-学习指南.md
@@ -0,0 +1,288 @@
+# 精尽学习指南
+
+> 艿艿：这是第一个版本，后续会继续优化。嘿嘿。
+>
+> 后面，艿艿会把每个学习资料给补充进去。
+
+# 1. 概述
+
+无论我们是工作多久的工程师，我们总是在某一刻会大呼“学不动了学不动了”。
+
+并且，我们是无可避免需要有大量加班，比较好的是 985 ，比较苦逼的是 996 。一旦陷入其中，我们可能就忘却了学习这个事情。
+
+另外，我们还会有一个困扰，技术栈这么多，我们应该怎么学习呢？
+
+艿艿的想法是：
+
+- 点
+- 线
+- 面
+- 立体
+
+什么是点？我们平时会在技术社区、公众号、博客上，学习一些技术，但是大家普遍会觉得比较琐碎。
+
+什么是线？当我们学习了同一个技术的多个点之后，我们会逐渐形成这个知识线，对这个知识会相对有整体的认识。
+
+什么是面？当我们学习了多个技术之后，我们会逐步自己的知识面，脑海里会有一颗若隐若现的知识树。
+
+什么是立体？当我们形成自己的知识面之后，我们肯定会惊呼“老子会很多东西，但是好像没有什么擅长的”。有木有？哈哈哈。这个时候，我们需要针对自己感兴趣的技术栈，做深入的理解，慢慢形成某几个技术的深度，这样，我们就开始立体了。当然，一定是几个技术的深入，而不是方块，而是一个锥子，一锥刺骨的那种，杀手锏。
+
+当然，本文暂时先对这个泛泛而谈，本文的重心在于如何先形成自己的**“点 -> 线 -> 面”**。我们先来看一个图：[![img](01-学习指南.assets/01.png)](http://static.iocoder.cn/images/Learn/01.png)
+
+- 一切的核心，都是为了实战。
+- 入门，是为了让我们能够实战。
+- 原理，是为了让我们更好的实战。
+- 源码，是为了让我们更具象的理解原理，从而更好的实战。
+- 所以，一切的核心，都是为了实战。
+
+也因此，一个技术栈的学习的逐步顺序是：入门 => 实战 => 原理 => 源码。
+
+那么，这个和本文又有什么关系呢？我们再来看一张图：
+
+[![路线图](01-学习指南.assets/02.png)](http://static.iocoder.cn/images/Learn/02.png)路线图
+
+- 1、可能胖友会懵逼，卧槽，要学习的有这么多。
+- 2、可能胖友会说，为什么没有 Dubbo、Zookeeper 等等
+- 3、可能胖友会说，怎么没有 AI、大数据呢？
+
+这个路线图，我们定位是让业务开发工程师，有一条相对明确的学习路线，最终实现搭建自己的知识体系。
+
+# 2. 路线图
+
+下面，我们来分块来看看路线图。
+
+## 第一步，单体应用
+
+第一步，我们先要学习，能够搭建一个最基本的单体应用。如下图所示：[![单体应用](01-学习指南.assets/03.png)](http://static.iocoder.cn/images/Learn/03.png)单体应用
+
+在这个过程中，我建议观看视频。
+
+- Java
+
+  > [《精尽 Java【基础】学习指南》](http://svip.iocoder.cn/Java/Core/tutorials/) 入门即可。
+  >
+  > 艿艿当前看的马士兵。
+
+- Servlet & JSP & JDBC
+
+  > 这个的视频资源，自己找，艿艿当前看的马士兵。
+
+- MySQL
+
+  > [《精尽 MySQL 学习指南》](http://svip.iocoder.cn/MySQL/tutorials/) 入门即可。
+
+- MyBatis
+
+  > [《精尽 MyBatis 学习指南》](http://svip.iocoder.cn/MyBatis/tutorials/) 入门即可。
+
+- Spring MVC
+
+  > [《精尽 Spring MVC 学习指南》](http://svip.iocoder.cn/Spring-MVC/tutorials/) 入门即可。
+
+- Spring Boot
+
+  > [《精尽 Spring Boot 学习指南》](http://svip.iocoder.cn/Spring-Boot/tutorials/)
+  >
+  > 看看尚硅谷的《Spring Boot 视频教程》是不错的。
+
+- Redis
+
+  > [《精尽 Redis 学习指南》](http://svip.iocoder.cn/Redis/tutorials/) 入门即可。
+
+- MongoDB
+
+  > [《精尽 MongoDB 学习指南》](http://svip.iocoder.cn/MongoDB/tutorials/) 入门即可。
+
+- Spring Security
+
+  > TODO 待补充
+
+- Nginx
+
+  > [《精尽 Nginx 学习指南》](http://svip.iocoder.cn/Nginx/tutorials/) 入门即可。
+
+在这一步中，我们需要对每个技术点只要达到“入门”和“实战”两点。
+
+## 第二步，微服务架构
+
+第二步，我们要再学习，能够搭建一个微服务架构的应用。如下图所示：[![微服务架构](01-学习指南.assets/04.png)](http://static.iocoder.cn/images/Learn/04.png)微服务架构
+
+在这个过程中，我建议以观看视频为主，同时能够认真看完 Spring Cloud 相关的书籍。
+
+> 为什么要推荐开始看书？因为，到了这个阶段，我们要开始从被动的从视频学习，慢慢变成主动的观看书籍。
+>
+> [《精尽 Spring Cloud 学习指南》](http://svip.iocoder.cn/Spring-Cloud/tutorials)
+>
+> - 推荐的书籍是，翟永超的 [《Spring Cloud微服务实战》](https://union-click.jd.com/jdc?d=505Twi)
+
+- Eureka
+- Hystrix
+- Zuul
+- Spring Cloud Config
+- RabbitMQ
+- Zipkin
+
+那么，可能对微服务技术选型有一定的了解会问，为什么不是学习 Dubbo 呢？注意噢，我们是为了搭建知识体系，从这方面上来说，艿艿觉得 Spring Cloud 更适合达成这个目标，周边的书籍、资料更加完善。
+
+当然，等未来回过头，艿艿还是建议大家去学习下 Dubbo 。
+
+在这一步中，我们需要对每个技术点只要达到“入门”和“实战”和“原理”三点。
+
+还有啊，其实每个类型的组件，还有其他的选择，胖友后续也要去学习下：
+
+- Eureka *VS* Zookeeper
+
+  > TODO 待补充
+
+- Hystrix *VS* Sentinel
+
+  > TODO 待补充
+
+- Zuul *VS* Spring Cloud Gateway
+
+  > TODO 待补充
+
+- Spring Cloud Config *VS* Apollo
+
+  > TODO 待补充
+
+- RabbitMQ *VS* RocketMQ VS Kafka
+
+  > - [《精尽 RocketMQ 学习指南》](http://svip.iocoder.cn/RocketMQ/tutorials/)
+  > - [《精尽 Kafka 学习指南》](http://svip.iocoder.cn/Kafka/tutorials/)
+  > - [《精尽 RabbitMQ 学习指南》](http://svip.iocoder.cn/RabbitMQ/tutorials/)
+
+- Zipkin *VS* SkyWalking
+
+  > TODO 待补充
+
+不要慌，知识这个东西，总是一通百通的。
+
+还有噢，到了这个阶段的学习，我们要关注每个组件怎么实现高性能，怎么实现高可用。
+
+## 第三步，其它中间件
+
+第三步，我们还要学习，微服务架构需要的其他中间件。如下图所示：[![其它中间件](01-学习指南.assets/05.png)](http://static.iocoder.cn/images/Learn/05.png)其它中间件
+
+在这个过程中，我建议以看书、看博客为主，以视频为辅助。
+
+> 为什么不再以视频为主呢？我们要能够更加更加更加主动的学习能力。
+
+- Quartz 或者 Elastic-Job 或者 XXL-Job
+
+  > TODO 待补充
+
+- Elasticsearch
+
+  > TODO 待补充
+
+- Sharding Sphere
+
+  > TODO 待补充
+
+- TCC Transaction
+
+  > TODO 待补充
+
+- ELK
+
+  > TODO 待补充
+
+在这一步中，我们需要对每个技术点只要达到“入门”和“实战”和“原理”三点。
+
+也就是说，在这一步中，我们已经不能简单的只会实战，要对原理有一定的认知。
+
+## 关于工具
+
+[![工具](01-学习指南.assets/06.png)](http://static.iocoder.cn/images/Learn/06.png)工具
+
+Maven、Git、Jenkins ，学会常用的即可。
+
+## 关于运维
+
+[![运维](01-学习指南.assets/07.png)](http://static.iocoder.cn/images/Learn/07.png)运维
+
+Linux 学会常用的命令即可。
+
+Docker 和 Kuberante ，选择性，非必须。
+
+## 关于基础
+
+[![基础](01-学习指南.assets/08.png)](http://static.iocoder.cn/images/Learn/08.png)基础
+
+关于如下的基础：
+
+- Java 并发
+
+  > [《精尽 Java【并发】学习指南》](http://svip.iocoder.cn/Java/Concurrent/tutorials/)
+
+- NIO & Netty
+
+  > [《精尽 Netty 学习指南》](http://svip.iocoder.cn/Netty/tutorials/)
+
+- 设计模式
+
+  > [《精尽设计学习指南》](http://svip.iocoder.cn/Design-Pattern/tutorials/)
+
+- JVM
+
+  > [《精尽 Java【虚拟机】学习指南》](http://svip.iocoder.cn/Java/VirtualMachine/tutorials/)
+
+- 算法
+
+  > TODO 待补充
+
+实际上，😈 我们更多使用到的是面试的时候，哈哈哈哈。
+
+当然，我们希望成为一个有趣的程序员，35 岁不被淘汰，这些基本功肯定要去补的。
+
+不过呢，艿艿个人的建议是，基础放在【第一步】【第二步】【第三步】学习完之后，在回过头来干。
+
+## 补充说明
+
+**在我们搭建知识体系，请对着每个知识点，认真看每个技术对应的[《精尽 XXX 学习指南》](http://svip.iocoder.cn/tags/学习指南/)里面推荐的书，踏踏实实在把每个技术栈体系化学习下。**
+
+**在我们搭建知识体系，请对着每个知识点，认真看每个技术对应的[《精尽 XXX 学习指南》](http://svip.iocoder.cn/tags/学习指南/)里面推荐的书，踏踏实实在把每个技术栈体系化学习下。**
+
+**在我们搭建知识体系，请对着每个知识点，认真看每个技术对应的[《精尽 XXX 学习指南》](http://svip.iocoder.cn/tags/学习指南/)里面推荐的书，踏踏实实在把每个技术栈体系化学习下。**
+
+另外，为了验证学习的结果，以及将来有复习的可能性，请做好笔记，可以下载一个【印象笔记】应用，记录、狠狠的记录。
+
+再另外，也可以看看每个技术栈对应的[《精尽 XXX 面试题》](http://svip.iocoder.cn/tags/面试题/)，验证验证自己学习的咋样~
+
+# 什么时候看源码？
+
+艿艿一开始看源码，单纯觉得好玩。后来一想，对于一个有追求的工程师，每年看掉几套源码，那么工作 5 年之后，基本主流的源码，都已经看过了。虽然这个过程会比较痛苦，但是前几年确实是我们时间最多的时候。我们不需要考虑家人、孩子。
+
+关于选择看什么源码的顺序，我建议从应用层到基础层。我举个例子：
+
+- 先看 Spring MVC 源码，在看 Spring 源码。
+- 先看 Dubbo 源码，在看 Netty 源码。
+
+然后呢，如果胖友真的不知道看什么源码，我建议可以星球给艿艿留言。
+
+如下，是艿艿自己经历的，看源码的顺序，可能不一定能成为参考：
+
+- Spring Security
+- Spring MVC
+- Shiro
+- RocketMQ
+- MyCAT
+- Sharding JDBC
+- TCC Transaction
+- Eureka
+- Hystrix
+- Spring Cloud Gateway
+- SkyWalking
+- Dubbo
+- Netty
+- Spring
+- MyBatis
+
+# 彩蛋
+
+写的有点杂乱，但是想想，先出一个版本。省得自己的想法丢失。
+
+万一的万一，对胖友有一些些帮助呢？
+
+希望，我们至少能成为有趣的工程师，再然后，贪心一点，成为厉害的工程师。
\ No newline at end of file
diff --git a/学习指南/02-Netty 学习指南.md b/学习指南/02-Netty 学习指南.md
new file mode 100644
index 0000000..e5d4447
--- /dev/null
+++ b/学习指南/02-Netty 学习指南.md	
@@ -0,0 +1,39 @@
+# 精尽 Netty 学习指南
+
+# 视频
+
+- [《NIO 视频教程全集》](https://www.bilibili.com/video/av59543731/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共有 13P ，3 小时多。
+  >
+  > 适合对 NIO 了解不多的胖哟偶偶
+
+- [《Netty 视频教程全集》](https://www.bilibili.com/video/av59683486?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 92 P ，61 小时。涉及的还是蛮广的。
+
+- 闪电侠 [《Java 读源码之 Netty 深入剖析》](https://coding.imooc.com/class/ds/230) 好基友，艿艿已经看过一遍，灰常不错
+
+- 学徒无忧 [《全网首部 Netty 源码剖析与 NIO + Netty 5 各种RPC架构实战演练》](https://www.bilibili.com/video/av33238175) 一共 60 P ，源码解析为主，基于 Netty 5 ，有点不清晰
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 书籍
+
+[《Netty 书单整理》](http://www.iocoder.cn/Books/Netty-books-recommended)
+
+- 闪电侠 [《Netty 入门与实战：仿写微信 IM 即时通讯系统》](https://juejin.im/book/5b4bc28bf265da0f60130116?referrer=5904c637b123db3ee479d923) 最易懂的 Netty 入门与实战的书籍
+- 诺曼·毛瑞尔 [《Netty 实战》](https://union-click.jd.com/jdc?d=RakFcl) 豆瓣评分 8.1 分，还是不错的书籍，艿艿买了
+
+# 文章
+
+1. [微信聊天表结构设计](https://wenku.baidu.com/view/b7c83e54ba0d4a7302763acf.html)
+2. [微信小程序中如何使用 WebSocket 实现长连接](https://www.cnblogs.com/imstudy/p/9224604.html)
+3. [新手入门一篇就够：从零开发移动端 IM](http://www.52im.net/thread-464-1-1.html)
+4. [大佬的 Netty 企业即时通讯系统博客](http://www.cookqq.com/listBlog.action?type=8a10a5f34e38beab014e4cd6b9e801cf)
+5. [《Netty高性能编程备忘录(上)》](http://calvin1978.blogcn.com/articles/netty-performance.html)
+6. [《Netty高性能编程备忘录（下）》](http://calvin1978.blogcn.com/articles/netty-performance2.html)
\ No newline at end of file
diff --git a/学习指南/03-Dubbo 学习指南.md b/学习指南/03-Dubbo 学习指南.md
new file mode 100644
index 0000000..5a88df8
--- /dev/null
+++ b/学习指南/03-Dubbo 学习指南.md	
@@ -0,0 +1,104 @@
+# 精尽 Dubbo 学习指南
+
+# 视频
+
+- [《Java 视频教程_Dubbo》](https://www.bilibili.com/video/av62353311/?pikaqiu) 一共有 30P 。徐妈已经刷了一遍。
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 书籍
+
+暂无书籍
+
+TODO 芋艿，等待超哥的书出版
+
+艿艿正在和朋友们，基于 Spring Boot + Dubbo 开发一个开源的 B2C 电商系统，可以来 https://gitee.com/zhijiantianya/onemall 瞅一瞅。如果想要参与，给艿艿留言哈。
+
+> 等 Spring Cloud Alibaba 稳定一些，会进行替换。
+
+# 专栏
+
+## 基础入门
+
+- [《芋道 Spring Boot Dubbo 入门》](http://www.iocoder.cn/Spring-Boot/Dubbo/?vip) 对应 [lab-30](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-30)
+- [《芋道 Spring Cloud Alibaba 服务调用 Dubbo 入门》](http://www.iocoder.cn/Spring-Cloud-Alibaba/Dubbo/?vip) 对应 [labx-07-spring-cloud-alibaba-dubbo](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-07-spring-cloud-alibaba-dubbo)
+- [《性能测试 —— Dubbo 基准测试》](http://www.iocoder.cn/Performance-Testing/Dubbo-benchmark/?vip)
+
+## 注册中心
+
+**[Zookeeper](http://www.iocoder.cn/Zookeeper/install/?vip)**
+
+- [《芋道 Spring Boot Dubbo 入门》](http://www.iocoder.cn/Spring-Boot/Dubbo/?vip)的[「2. XML 配置」](https://svip.iocoder.cn/Dubbo/tutorials/#)和[「3. 注解配置」](https://svip.iocoder.cn/Dubbo/tutorials/#)小节
+
+**[Nacos](http://www.iocoder.cn/Nacos/install/?vip)**
+
+- [《芋道 Spring Boot Dubbo 入门》](http://www.iocoder.cn/Spring-Boot/Dubbo/?vip)的[「6. 整合 Nacos」](https://svip.iocoder.cn/Dubbo/tutorials/#)小节
+- [《芋道 Spring Cloud Alibaba 服务调用 Dubbo 入门》](http://www.iocoder.cn/Spring-Cloud-Alibaba/Dubbo/?vip)的[「2. 快速入门」](https://svip.iocoder.cn/Dubbo/tutorials/#)小节
+
+## 服务保障
+
+**[Sentinel](http://www.iocoder.cn/Sentinel/install/?vip)**
+
+- [《芋道 Spring Boot Dubbo 入门》](http://www.iocoder.cn/Spring-Boot/Dubbo/?vip)的[「7. 整合 Sentinel」](https://svip.iocoder.cn/Dubbo/tutorials/#)小节
+- [《芋道 Spring Cloud Alibaba 服务调用 Dubbo 入门》](http://www.iocoder.cn/Spring-Cloud-Alibaba/Dubbo/?vip)的[「6. 整合 Sentinel」](https://svip.iocoder.cn/Dubbo/tutorials/#)小节
+
+**[Hystrix](http://www.iocoder.cn/categories/Hystrix/?vip)**
+
+- [《芋道 Spring Boot 服务容错 Hystrix 入门》](http://www.iocoder.cn/Spring-Boot/Hystrix/?vip)的[「6. 集成到 Dubbo」](https://svip.iocoder.cn/Dubbo/tutorials/#)小节
+- [《芋道 Spring Cloud Netflix 服务容错 Hystrix 入门》](http://www.iocoder.cn/Spring-Cloud/Netflix-Hystrix/?vip)的[「10. 集成到 Dubbo」](https://svip.iocoder.cn/Dubbo/tutorials/#)小节
+
+## API 网关
+
+- [《芋道 Soul 极简入门（国产微服务网关）》](http://www.iocoder.cn/Soul/install/?vip)的[「3. 接入 Dubbo 应用」](https://svip.iocoder.cn/Dubbo/tutorials/#)小节
+
+## 分布式事务
+
+**[Seata](http://www.iocoder.cn/Seata/install/?vip)**
+
+- [《芋道 Dubbo 分布式事务 Seata 入门》](http://www.iocoder.cn/Dubbo/Seata/?vip) 对应 [lab-53](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-53)
+- [《芋道 Spring Cloud Alibaba 分布式事务 Seata 入门》](http://www.iocoder.cn/Spring-Cloud-Alibaba/Seata/?vip)的[「2. AT 模式 + Dubbo」](https://svip.iocoder.cn/Dubbo/tutorials/#)小节
+
+**[TCC Transaction](http://www.iocoder.cn/categories/TCC-Transaction/?vip)**
+
+- [《TCC-Transaction 源码分析 —— Dubbo 支持》](http://www.iocoder.cn/TCC-Transaction/dubbo-support/?self)
+
+## 链路追踪
+
+**[SkyWalking](http://www.iocoder.cn/SkyWalking/install/?vip)**
+
+- [《芋道 Spring Boot 链路追踪 SkyWalking 入门》](http://www.iocoder.cn/Spring-Boot/SkyWalking/?vip) 的[「16. Dubbo 示例」](https://svip.iocoder.cn/Dubbo/tutorials/#)小节
+- [《芋道 Spring Cloud 链路追踪 SkyWalking 入门》](http://www.iocoder.cn/Spring-Cloud/SkyWalking/?vip) 的[「7. Dubbo 示例」](https://svip.iocoder.cn/Dubbo/tutorials/#)小节
+
+**[Zipkin](http://www.iocoder.cn/Zipkin/install/?vip)**
+
+- [《芋道 Spring Boot 链路追踪 Zipkin》](http://www.iocoder.cn/Spring-Cloud/Spring-Cloud-Sleuth/?vip) 的[「13. Dubbo 示例」](https://svip.iocoder.cn/Dubbo/tutorials/#)小节
+- [《芋道 Spring Cloud 链路追踪 Spring Cloud Sleuth》](http://www.iocoder.cn/Spring-Cloud/Spring-Cloud-Sleuth/?vip) 的[「7. Dubbo 示例」](https://svip.iocoder.cn/Dubbo/tutorials/#)小节
+
+## 监控管理
+
+**[CAT](http://www.iocoder.cn/CAT/install/?vip)**
+
+- [《芋道 Spring Boot 监控平台 CAT 入门》](http://www.iocoder.cn/Spring-Boot/CAT/?vip) 的[「13. Dubbo 集成」](https://svip.iocoder.cn/Dubbo/tutorials/#)小节
+
+**[Dubbo Admin](http://www.iocoder.cn/Dubbo/Admin/?vip)**
+
+- [《芋道 Dubbo Admin 快速入门》](http://www.iocoder.cn/Dubbo/Admin/?vip)
+
+# 其它
+
+非常重要，一定一定一定认真看官方文档
+
+- [《Dubbo 用户指南》](http://dubbo.apache.org/zh-cn/docs/user/quick-start.html) 必选。
+- [《Dubbo 开发指南》](http://dubbo.apache.org/zh-cn/docs/dev/build.html) 进阶。
+- [《Dubbo 运维管理》](http://dubbo.apache.org/zh-cn/docs/admin/install/provider-demo.html) 可选。
+
+如果你想参与到 Dubbo 的开发之中，如下两篇文章给了我们很不错的指引：
+
+- 徐妈 [《以 Dubbo 为例，聊聊如何向开源项目做贡献》](http://dubbo.apache.org/zh-cn/blog/dubbo-contribue-to-opensource.html)
+- jerrick [《如何参与贡献 Dubbo 社区》](http://dubbo.apache.org/zh-cn/blog/how-to-involve-dubbo-community.html)
+
+如果你对 Dubbo 是怎么做一次版本的发布 Release ，可以参见：
+
+- Jun Liu [《如何准备 Apache Release》](http://dubbo.apache.org/zh-cn/blog/prepare-an-apache-release.html)
\ No newline at end of file
diff --git a/学习指南/04-Spring 学习指南.md b/学习指南/04-Spring 学习指南.md
new file mode 100644
index 0000000..de4c234
--- /dev/null
+++ b/学习指南/04-Spring 学习指南.md	
@@ -0,0 +1,69 @@
+# 精尽 Spring 学习指南
+
+# 1. 视频
+
+😈 记得艿艿当年学习 Spring ，还是看的马士兵老师的。有握爪的同学么？嘻嘻。
+
+- [《Spring XML 视频教程全集》](https://www.bilibili.com/video/av59570922/?pikaqiu) 一共有 36P 。
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 虽然版本是 Spring4 ，和 Spring5 实际差距没这么大。
+  >
+  > 和《尚硅谷 Spring MVC 视频教程》是同一个讲师。
+
+- [《Spring 注解视频教程全集》](https://www.bilibili.com/video/av59569306/?pikaqiu) 一共有 61P 。
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 和《尚硅谷 Spring MVC 视频教程》是同一个讲师。
+
+- [《SSM 整合视频教程全集》](https://www.bilibili.com/video/av59585780/?pikaqiu) 一共有 35P 。
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 和《尚硅谷 Spring 视频教程》是同一个讲师。
+
+- 布丁狼 [《Java 大神之路（第八季 Spring5）》](https://www.bilibili.com/video/av33077509) 一共有 57P 。声音有点小…
+
+- 传智播客 [《Spring3 框架》](https://www.imooc.com/learn/498) 一共有 87P 。
+
+- moocer [《Spring 入门篇》](http://www.imooc.com/learn/196) 一共 7 小时，侧重 Spring IoC 和 AOP 。
+
+- apollo_0001 [《探秘 Spring AOP》](http://www.imooc.com/learn/869) 一共 2 小时 30 分钟，侧重 Spring AOP 。
+
+- 慕_神 [《Spring 事务管理》](http://www.imooc.com/learn/478) 一共 2 小时，侧重 Spring Transaction 。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+虽然现在 Spring Boot 给我们带来了非常便利的搭建开发环境的方式，但是艿艿的态度，希望大家能对 Spring 本身能够有比较深入的理解。知其然，知其所以然。这是技术的态度，也是让我们能够走的更远的基础。
+
+# 2. 书籍
+
+[《Spring 书单整理》](http://www.iocoder.cn/Books/Netty-Spring-recommended)
+
+- [《Spring 实战（第4版）》](https://item.jd.com/11899370.html) 豆瓣评分：8.3 ，艿艿当年入门 Spring 的书，翻烂了。
+- [《Spring 揭秘》](https://union-click.jd.com/jdc?d=kYry5g) 豆瓣评分：9.0 ，zhisheng 学习 Spring 的书，虽然 Spring 版本比较老，但是不妨碍我们理解 Spring 。
+- 陈雄华/林开雄/文建国 [《精通Spring 4.x》](https://book.douban.com/subject/26952826/) 豆瓣评分 8.2 分，很厚，799 页。
+- [《Spring 源码深度解析》](https://item.jd.com/11311737.html) 豆瓣评分：6.6 ，艿艿当时撸 Spring 源码，翻了好几遍，认为评分低了，还是很值得推荐的。
+- [《Spring 技术内幕》](https://item.jd.com/1027598917.html) 豆瓣评分 5.8 ，也是 Spring 源码相关，艿艿当年也买过，没读完~
+
+# 3. 文章
+
+- [《Spring 框架的设计理念与设计模式分析》](https://www.ibm.com/developerworks/cn/java/j-lo-spring-principle/index.html)
+
+- [《超全面 Spring 复习总结笔记》](https://www.jianshu.com/p/15a0f94b4063)
+
+  > 艿艿说：推荐这篇文章的原因不是这篇文章写的多好，而是希望我们，在每次之后，我们要去整理总结，即使是简单的笔记，也值得输出。
+  >
+  > 生活的节奏很快，学习之后，总会淡忘。通过文字，能让我们更快的回忆起来。
+
+- [《彻底征服 Spring AOP 之理论篇》](https://segmentfault.com/a/1190000007469968)
+
+- [《彻底征服 Spring AOP 之实战篇》](https://segmentfault.com/a/1190000007469982)
+
+- [《可能是最漂亮的 Spring 事务管理详解》](https://mp.weixin.qq.com/s?__biz=MzUzMTA2NTU2Ng==&mid=2247484702&idx=1&sn=c04261d63929db09ff6df7cadc7cca21&chksm=fa497aafcd3ef3b94082da7bca841b5b7b528eb2a52dbc4eb647b97be63a9a1cf38a9e71bf90&token=165108535&lang=zh_CN#rd)
+
+- [《Spring 事务管理 － 编程式事务、声明式事务》](https://blog.csdn.net/xktxoo/article/details/77919508)
+
+如果胖友有看到合适的文章，也可以推荐给我哟。
\ No newline at end of file
diff --git a/学习指南/05-Spring MVC 学习指南.md b/学习指南/05-Spring MVC 学习指南.md
new file mode 100644
index 0000000..5d2fa14
--- /dev/null
+++ b/学习指南/05-Spring MVC 学习指南.md	
@@ -0,0 +1,45 @@
+# 精尽 Spring MVC 学习指南
+
+# 1. 视频
+
+- [《Spring MVC 视频教程全集》](https://www.bilibili.com/video/av59567541/?pikaqiu) 一共有 60P 。
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 和《尚硅谷 Spring 视频教程》是同一个讲师。
+
+- [《SSM 整合视频教程全集》](https://www.bilibili.com/video/av59585780/?pikaqiu) 一共有 35P 。
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 和《尚硅谷 Spring 视频教程》是同一个讲师。
+
+- 黑马 [《黑马 spring MVC》](https://www.bilibili.com/video/av20870782) 一共有 44P 。就是声音有点小…
+
+- 廖师兄 [《Spring Boot 进阶之 Web 进阶》](https://www.imooc.com/learn/810) 两小时不到，挺不错的。
+
+- ReasonLee [《Spring MVC 拦截器》](https://www.imooc.com/learn/498) 40 分钟，可以的。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 2. 书籍
+
+[《Spring MVC 书单整理》](http://www.iocoder.cn/Books/Spring-MVC-books-recommended)
+
+- 韩路彪 [《看透 Spring MVC》](https://item.jd.com/11807414.html) 豆瓣评分 7.3 分，主要分享 Spring MVC 的源码
+
+# 3. 文章
+
+- 芋艿 [《芋道 Spring Boot SpringMVC 入门》](http://www.iocoder.cn/Spring-Boot/SpringMVC/?vip) 对应 [lab-23](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-23)
+- [《芋道 Spring Boot WebFlux 入门》](http://www.iocoder.cn/Spring-Boot/WebFlux/?vip) 对应 [lab-27](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-27)
+- [《芋道 Spring Boot API 接口文档 Swagger 入门》](http://www.iocoder.cn/Spring-Boot/Swagger/?vip) 对应 [lab-24](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-24)
+- [《芋道 Spring Boot API 接口文档 Swagger Starter 入门》](http://www.iocoder.cn/Spring-Boot/Swagger-Starter/?vip) 对应 [lab-24](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-24)
+- [《芋道 Spring Boot 分布式 Session 入门》](http://www.iocoder.cn/Spring-Boot/Distributed-Session/?vip) 对应 [lab-26](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-26)
+- 芋艿 [《芋道 Spring Boot 参数校验 Validation 入门》](http://www.iocoder.cn/Spring-Boot/Validation/?vip) 对应 [lab-22](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-22) 。
+- [《芋道 Spring Boot WebSocket 入门》](http://www.iocoder.cn/Spring-Boot/WebSocket/?vip) 对应 [lab-25](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-25)
+- [《芋道 Spring Boot API 接口文档 JApiDocs 入门》](http://www.iocoder.cn/Spring-Boot/JApiDocs/?vip) 对应 [lab-24](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-24)
+- [《芋道 Spring Boot API 接口文档 ShowDoc 入门》](http://www.iocoder.cn/Spring-Boot/ShowDoc/?vip) 对应 [lab-24](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-24)
+- 莫那·鲁道 [《面试问烂的 Spring MVC 过程》](http://www.iocoder.cn/Fight/Interview-poorly-asked-SpringMVC-process)
+- 知乎讨论 [《Spring MVC 的工作原理是什么样的,跟 Spring 的关系是怎么样的？》](https://www.zhihu.com/question/38696452)
+
+如果胖友有看到合适的文章，也可以推荐给我哟。
\ No newline at end of file
diff --git a/学习指南/06-Spring Boot 学习指南.md b/学习指南/06-Spring Boot 学习指南.md
new file mode 100644
index 0000000..e59077f
--- /dev/null
+++ b/学习指南/06-Spring Boot 学习指南.md	
@@ -0,0 +1,172 @@
+# 精尽 Spring Boot 学习指南
+
+# 1. 视频
+
+- [《Spring Boot 视频教程全集》](https://www.bilibili.com/video/av59572480/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 本视频分成 A/B 两部分。
+  >
+  > - A 部分（核心技术篇） P01-P72
+  >
+  >   着重介绍SpringBoot的使用和内部原理；内容包含微服务概念、配置文件、日志框架的使用、web开发、Thymeleaf模板引擎、Docker容器技术、MyBatis、Spring Data JPA、自定义starter等；
+  >
+  > - B 部分（整合篇） P73-P112
+  >
+  >   着重介绍SpringBoot的与各大场景的整合使用，内容包括：缓存（整合Redis），消息中间件（整合RabbitMQ），检索（整合ElasticSearch），任务（异步任务，定时任务，邮件任务），安全（整合SpringSecurity），分布式（Zookeeper/dubbo，整合SpringCloud），SpringBoot应用监管；
+
+- 龙虾三少 [《Spring Boot 构建电商基础秒杀项目》](https://www.imooc.com/learn/1079) 6 小时，貌似还没录制完，优点在于相对项目实战。
+
+- 风间影月 [《Spring Boot 微信小程序 – 微信登录功能实战》](https://www.imooc.com/learn/1059) 54 分钟，现在大部分互联网公司都有小程序，不然都不好意思出来混了。
+
+- 风间影月 [《Spring Boot 开发常用技术整合》](https://www.imooc.com/learn/956) 2 小时 45 分钟，虽然不长，覆盖了Spring Boot 最常用的部分。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+不过艿艿还是要提醒下大家，Spring Boot 给大家便捷的开发方式，但是也可能带走大家对 Spring 深入了解的机会。当然，如果真的是这样，错的不是工具，而是我们。我们在获得便捷的同时，需要把这部分节省的时间，用心继续去学习~
+
+# 2. 书籍
+
+[《Spring Boot 书单整理》](http://www.iocoder.cn/Books/Spring-Boot-books-recommended)
+
+看了一圈市面上的 Spring Boot 相关的书籍，貌似评价暂时没有特别合适的书籍推荐。目前感觉下来，还是 [《Spring Boot 揭秘》](https://union-click.jd.com/jdc?d=Ym8Bu8) 不错一些。
+
+# 3. 文章
+
+## 打好基础
+
+- [《芋道 Spring Boot 快速入门》](http://www.iocoder.cn/Spring-Boot/quick-start/?vip)
+- [《芋道 Spring Boot 自动配置原理》](http://www.iocoder.cn/Spring-Boot/autoconfigure/?vip) 对应 [lab-47](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-47)
+- [《芋道 Spring Boot Jar 启动原理》](http://www.iocoder.cn/Spring-Boot/jar/?vip)
+
+## 开发工具
+
+- [《芋道 Spring Boot 热部署入门》](http://www.iocoder.cn/Spring-Boot/hot-swap/?vip) 对应 [lab-48-hot-swap](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-48-hot-swap)
+- [《芋道 Spring Boot 消除冗余代码 Lombok 入门》](http://www.iocoder.cn/Spring-Boot/Lombok/?vip) 对应 [lab-49](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-49)
+- [《芋道 Spring Boot 对象转换 MapStruct 入门》](http://www.iocoder.cn/Spring-Boot/MapStruct/?vip) 对应 [lab-55](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-55)
+
+## Web 开发
+
+- [《芋道 Spring Boot SpringMVC 入门》](http://www.iocoder.cn/Spring-Boot/SpringMVC/?vip) 对应 [lab-23](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-23)
+- [《芋道 Spring Boot WebFlux 入门》](http://www.iocoder.cn/Spring-Boot/WebFlux/?vip) 对应 [lab-27](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-27)
+- [《芋道 Spring Boot 分布式 Session 入门》](http://www.iocoder.cn/Spring-Boot/Distributed-Session/?vip) 对应 [lab-26](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-26)
+- [《芋道 Spring Boot API 接口文档 Swagger 入门》](http://www.iocoder.cn/Spring-Boot/Swagger/?vip) 对应 [lab-24](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-24)
+- [《芋道 Spring Boot API 接口文档 Swagger Starter 入门》](http://www.iocoder.cn/Spring-Boot/Swagger-Starter/?vip) 对应 [lab-24](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-24)
+- [《芋道 Spring Boot 参数校验 Validation 入门》](http://www.iocoder.cn/Spring-Boot/Validation/?vip) 对应 [lab-22](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-22)
+- [《芋道 Spring Boot WebSocket 入门》](http://www.iocoder.cn/Spring-Boot/WebSocket/?vip) 对应 [lab-25](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-25)
+- [《芋道 Spring Boot API 接口文档 JApiDocs 入门》](http://www.iocoder.cn/Spring-Boot/JApiDocs/?vip) 对应 [lab-24](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-24)
+- [《芋道 Spring Boot API 接口文档 ShowDoc 入门》](http://www.iocoder.cn/Spring-Boot/ShowDoc/?vip) 对应 [lab-24](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-24)
+- [《芋道 Spring Boot API 接口调试 IDEA HTTP Client》](http://www.iocoder.cn/Spring-Boot/IDEA-HTTP-Client/?vip) 对应 [lab-71-http-debug](https://github.com/YunaiV/SpringBoot-Labs/blob/master/lab-71-http-debug/)
+
+## 文件存储
+
+- [《芋道 Spring Boot 对象存储 MinIO 入门》](https://www.iocoder.cn/Spring-Boot/MinIO/?vip) 对应 [lab-72-minio](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-72-minio)
+
+## 数据访问
+
+**关系数据库**
+
+- [《芋道 Spring Boot 数据库连接池入门》](http://www.iocoder.cn/Spring-Boot/datasource-pool/?vip) 对应 [lab-19](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-19)
+- [《芋道 Spring Boot MyBatis 入门》](http://www.iocoder.cn/Spring-Boot/MyBatis/?vip) 对应 [lab-12-mybatis](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-12-mybatis)
+- [《芋道 Spring Boot JPA 入门》](http://www.iocoder.cn/Spring-Boot/JPA/?vip) 对应 [lab-13-spring-data-jpa](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-13-spring-data-jpa)
+- [《芋道 Spring Boot JdbcTemplate 入门》](http://www.iocoder.cn/Spring-Boot/JdbcTemplate/?vip) 对应 [lab-14-spring-jdbc-template](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-14-spring-jdbc-template)
+- [《芋道 Spring Boot 多数据源（读写分离）入门》](http://www.iocoder.cn/Spring-Boot/dynamic-datasource/?vip) 对应 [lab-17](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-17)
+- [《芋道 Spring Boot 分库分表入门》](http://www.iocoder.cn/Spring-Boot/sharding-datasource/?vip) 对应 [lab-18](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-18)
+- [《芋道 Spring Boot 数据库版本管理入门》](http://www.iocoder.cn/Spring-Boot/database-version-control/?vip) 对应 [lab-20](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-20)
+- [《芋道 Spring Boot 数据表结构文档》](http://www.iocoder.cn/Spring-Boot/DB-Doc-screw/?vip) 对应 [lab-70-db-doc](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-70-db-doc)
+
+**非关系数据库**
+
+- [《芋道 Spring Boot Redis 入门》](http://www.iocoder.cn/Spring-Boot/Redis/?vip) 对应 [lab-11-spring-data-redis](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-11-spring-data-redis)
+- [《芋道 Spring Boot 缓存 Cache 入门》](http://www.iocoder.cn/Spring-Boot/Cache/?vip) 对应 [lab-21](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-21)
+- [《芋道 Spring Boot MongoDB 入门》](http://www.iocoder.cn/Spring-Boot/MongoDB/?vip) 对应 [lab-16-spring-data-mongo](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-16-spring-data-mongo)
+- [《芋道 Spring Boot Elasticsearch 入门》](http://www.iocoder.cn/Spring-Boot/Elasticsearch/?vip) 对应 [lab-15](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-15)
+- [《芋道 Spring Boot Solr 入门》](http://www.iocoder.cn/Spring-Boot/Solr/?vip) 对应 [lab-66](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-66)
+
+## 事务管理
+
+- [《芋道 Spring Boot 分布式事务 Seata 入门》](http://www.iocoder.cn/Spring-Boot/Seata/?vip) 对应 [lab-52](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-52)
+
+## RPC 开发
+
+- [《芋道 Spring Boot Netty 入门》](http://www.iocoder.cn/Spring-Boot/Netty/?vip) 对应 [lab-67](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-67)
+- [《芋道 Spring Boot Dubbo 入门》](http://www.iocoder.cn/Spring-Boot/Dubbo/?vip) 对应 [lab-30](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-30)
+- [《芋道 Spring Boot 声明式调用 Feign 入门》](http://www.iocoder.cn/Spring-Boot/Feign/?vip) 对应 [lab-58](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-58)
+- [《芋道 Spring Boot gRPC 入门》](http://www.iocoder.cn/Spring-Boot/gRPC/?vip) 对应 [lab-64](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-64)
+- [《芋道 Spring Boot Web Services 入门》](http://www.iocoder.cn/Spring-Boot/Web-Services/?vip) 对应 [lab-65](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-65)
+- [《芋道 Spring Boot SOFARPC 入门》](http://www.iocoder.cn/Spring-Boot/SOFARPC/?vip) 对应 [lab-62](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-62)
+- [《芋道 Spring Boot Motan 入门》](http://www.iocoder.cn/Spring-Boot/Motan/?vip) 对应 [lab-63](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-63)
+- 《芋道 Spring Boot RSocket 入门》计划中…
+
+## 安全控制
+
+- [《芋道 Spring Boot 安全框架 Spring Security 入门》](http://www.iocoder.cn/Spring-Boot/Spring-Security/?vip) 对应 [lab-01-spring-security](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-01-spring-security)
+- [《芋道 Spring Boot 安全框架 Shiro 入门》](http://www.iocoder.cn/Spring-Boot/Shiro/?vip) 对应 [lab-33](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-33)
+
+**OAuth 2.0**
+
+- [《芋道 Spring Security OAuth2 入门》](http://www.iocoder.cn/Spring-Security/OAuth2-learning/?vip) 对应 [lab-68-spring-security-oauth](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-68-spring-security-oauth)
+- [《芋道 Spring Security OAuth2 存储器》](http://www.iocoder.cn/Spring-Security/OAuth2-learning-store/?vip) 对应 [lab-68-spring-security-oauth](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-68-spring-security-oauth)
+- [《芋道 Spring Security OAuth2 单点登陆》](http://www.iocoder.cn/Spring-Security/OAuth2-learning-sso/?vip) 对应 [lab-68-spring-security-oauth](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-68-spring-security-oauth)
+
+## 定时任务与异步任务
+
+- [《芋道 Spring Boot 定时任务入门》](http://www.iocoder.cn/Spring-Boot/Job/?vip) 对应 [lab-28](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-28)
+- [《芋道 Spring Boot 异步任务入门》](http://www.iocoder.cn/Spring-Boot/Async-Job/?vip) 对应 [lab-29](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-29)
+
+## 消息队列
+
+- [《芋道 Spring Boot 消息队列 RocketMQ 入门》](http://www.iocoder.cn/Spring-Boot/RocketMQ/?vip) 对应 [lab-31](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-31)
+- [《芋道 Spring Boot 消息队列 Kafka 入门》](http://www.iocoder.cn/Spring-Boot/Kafka/?vip) 对应 [lab-03-kafka](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-03-kafka)
+- [《芋道 Spring Boot 消息队列 RabbitMQ 入门》](http://www.iocoder.cn/Spring-Boot/RabbitMQ/?vip) 对应 [lab-04-rabbitmq](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-04-rabbitmq)
+- [《芋道 Spring Boot 消息队列 ActiveMQ 入门》](http://www.iocoder.cn/Spring-Boot/ActiveMQ/?vip) 对应 [lab-32](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-32)
+- [《芋道 Spring Boot 事件机制 Event 入门》](http://www.iocoder.cn/Spring-Boot/Event/?vip) 对应 对应 [lab-54](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-54)
+
+## 配置中心
+
+- [《芋道 Spring Boot 配置文件入门》](http://www.iocoder.cn/Spring-Boot/config-file/?vip) 对应 [lab-43](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-43)
+- [《芋道 Spring Boot 配置中心 Apollo 入门》](http://www.iocoder.cn/Spring-Boot/config-apollo/?vip) 对应 [lab-45](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-45)
+- [《芋道 Spring Boot 配置中心 Nacos 入门》](http://www.iocoder.cn/Spring-Boot/config-nacos/?vip) 对应 [lab-44](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-44)
+
+## 注册中心
+
+- [《芋道 Spring Boot 注册中心 Nacos 入门》](http://www.iocoder.cn/Spring-Boot/registry-nacos/?vip) 对应 [lab-44](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-44)
+
+## 持续交付
+
+- [《芋道 Spring Boot 持续交付 Jenkins 入门》](http://www.iocoder.cn/Spring-Boot/Jenkins/?vip) 对应 [lab-41](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-41)
+- [《芋道 Spring Boot 单元测试 Test 入门》](http://www.iocoder.cn/Spring-Boot/Unit-Test/?vip) 对应 [lab-42](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-42)
+- 《芋道 Spring Boot 容器 Docker 入门》计划中…
+
+## 服务容错
+
+- [《芋道 Spring Boot 服务容错 Sentinel 入门》](http://www.iocoder.cn/Spring-Boot/Sentinel/?vip) 对应 [lab-46](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-46)
+- [《芋道 Spring Boot 服务容错 Hystrix 入门》](http://www.iocoder.cn/Spring-Boot/Hystrix/?vip) 对应 [lab-57](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-57)
+- [《芋道 Spring Boot 服务容错 Resilience4j 入门》](http://www.iocoder.cn/Spring-Boot/Resilience4j/?vip) 对应 [lab-59](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-59)
+
+## 监控管理
+
+- [《芋道 Spring Boot 监控端点 Actuator 入门》](http://www.iocoder.cn/Spring-Boot/Actuator/?vip) 对应 [lab-34](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-34)
+- [《芋道 Spring Boot 监控工具 Admin 入门》](http://www.iocoder.cn/Spring-Boot/Admin/?vip) 对应 [lab-35](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-35)
+- [《芋道 Spring Boot 监控平台 Prometheus + Grafana 入门》](http://www.iocoder.cn/Spring-Boot/Prometheus-and-Grafana/?vip) 对应 [lab-36](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-36)
+- [《芋道 Spring Boot 监控平台 CAT 入门》](http://www.iocoder.cn/Spring-Boot/CAT/?vip) 对应 [lab-61](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-61)
+
+## 日志管理
+
+- [《芋道 Spring Boot 日志集成 Logging 入门》](http://www.iocoder.cn/Spring-Boot/Logging/?vip) 对应 [lab-37](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-37)
+- [《芋道 Spring Boot 日志平台 ELK + Filebeat 入门》](http://www.iocoder.cn/Spring-Boot/ELK/?vip) 对应 [lab-38](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-38)
+
+## 链路追踪
+
+- [《芋道 Spring Boot 链路追踪 SkyWalking 入门》](http://www.iocoder.cn/Spring-Boot/SkyWalking/?vip) 对应 [lab-39](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-39)
+- [《芋道 Spring Boot 链路追踪 Zipkin 入门》](http://www.iocoder.cn/Spring-Boot/Zipkin/?vip) 对应 [lab-40](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-40)
+- 《芋道 Spring Boot 链路追踪 Pinpoint 入门》计划中…
+- 《芋道 Spring Boot 链路追踪 Elastic APM 入门》计划中…
+
+## 其它
+
+- [《Spring Boot 2.x 精品教程》](http://www.iocoder.cn/Spring-Boot/good-collection/)
+- [《给你一份 Spring Boot 知识清单》](http://www.iocoder.cn/Fight/Give-you-a-list-of-Spring-Boot-knowledge)
+
+如果胖友有看到合适的文章，也可以推荐给我哟。
\ No newline at end of file
diff --git a/学习指南/07-Spring Cloud 学习指南.md b/学习指南/07-Spring Cloud 学习指南.md
new file mode 100644
index 0000000..d671af2
--- /dev/null
+++ b/学习指南/07-Spring Cloud 学习指南.md	
@@ -0,0 +1,148 @@
+# 精尽 Spring Cloud 学习指南
+
+# 1. 视频
+
+> 友情提示：如果不喜欢看视频的胖友，可以看艿艿写的[「2. Spring Cloud Alibaba 专栏」](https://svip.iocoder.cn/Spring-Cloud/tutorials/#)和[「3. Spring Cloud 专栏」](https://svip.iocoder.cn/Spring-Cloud/tutorials/#)。
+
+- [《Spring Cloud 视频教程全集》](https://www.bilibili.com/video/av59639535/?pikaqiu) 一共有 50P 。
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 包含 Eureka、Ribbon、Feign、Hystrix、HystrixDashboard、Zuul、Config 。虽然说，目前 Eureka、Hystrix 等等已经停止维护，但是它们仍然是值得学习的。
+
+- [《Spring Cloud Alibaba 视频教程全集》](https://www.bilibili.com/video/BV11E411u7yy/?pikaqiu) 一共有 150P 。
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > Spring Cloud Alibaba 主要在 P95 开始噢~
+
+- 千锋教育 [《Java微服务架构（Spring Boot + Spring Cloud）》](https://www.bilibili.com/video/av36042649)
+
+  > 一共 156P ，如果只看 Spring Cloud 可以从第 74P 开始看。
+  >
+  > 老师声音比较清晰，干净~
+
+- 传智博客 [《微服务 Spring Cloud & Docker视频教程》](https://www.bilibili.com/video/av36291265)
+
+  > 一共 51P ，比较恶心的是下不到课件的 Word 。
+
+- 周立 [《Spring Cloud 微服务实战视频课程》](https://www.bilibili.com/video/av24536999)
+
+  > 一共 51P ，讲师比较有名~
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+不过艿艿还是要提醒下大家，Spring Cloud 给大家便捷的开发方式，可以很低成本的开发微服务，但是我们一定一定一定要，了解微服务中的每个组件，以及每个组件的原理。**知其然，知其所以然。**
+
+# 2. Spring Cloud Alibaba 专栏
+
+## 2.1 Spring Cloud Alibaba 全家桶
+
+- [《芋道 Spring Cloud Alibaba 介绍》](http://www.iocoder.cn/Spring-Cloud-Alibaba/intro/?vip)
+- [《芋道 Spring Cloud Alibaba 注册中心 Nacos 入门》](http://www.iocoder.cn/Spring-Cloud-Alibaba/Nacos-Discovery/?vip) 对应 [labx-01-spring-cloud-alibaba-nacos-discovery](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-01-spring-cloud-alibaba-nacos-discovery)
+- [《芋道 Spring Cloud Alibaba 服务调用 Dubbo 入门》](http://www.iocoder.cn/Spring-Cloud-Alibaba/Dubbo/?vip) 对应 [labx-07-spring-cloud-alibaba-dubbo](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-07-spring-cloud-alibaba-dubbo)
+- [《芋道 Spring Cloud Alibaba 服务容错 Sentinel 入门》](http://www.iocoder.cn/Spring-Cloud-Alibaba/Sentinel/?vip) 对应 [labx-04-spring-cloud-alibaba-sentinel](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-04-spring-cloud-alibaba-sentinel)
+- [《芋道 Spring Cloud Alibaba 消息队列 RocketMQ 入门》](http://www.iocoder.cn/Spring-Cloud-Alibaba/RocketMQ/?vip) 对应 [labx-06-spring-cloud-stream-rocketmq](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-06-spring-cloud-stream-rocketmq)
+- [《芋道 Spring Cloud Alibaba 事件总线 Bus RocketMQ 入门》](http://www.iocoder.cn/Spring-Cloud-Alibaba/Bus-RocketMQ/?vip) 对应 [labx-20](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-20)
+- [《芋道 Spring Cloud Alibaba 配置中心 Nacos 入门》](http://www.iocoder.cn/Spring-Cloud-Alibaba/Nacos-Config/?vip) 对应 [labx-05-spring-cloud-alibaba-nacos-config](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-05-spring-cloud-alibaba-nacos-config)
+- [《芋道 Spring Cloud Alibaba 分布式事务 Seata 入门》](http://www.iocoder.cn/Spring-Cloud-Alibaba/Seata/?vip) 对应 [labx-17](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-17)
+
+## 2.2 推荐搭配食用
+
+- [《芋道 Spring Cloud Netflix 负载均衡 Ribbon 入门》](http://www.iocoder.cn/Spring-Cloud-Netflix/Ribbon/?vip) 对应 [labx-02-spring-cloud-netflix-ribbon](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-02-spring-cloud-netflix-ribbon)
+- [《芋道 Spring Cloud 声明式调用 Feign 入门》](http://www.iocoder.cn/Spring-Cloud/Feign/?vip) 对应 [labx-03-spring-cloud-feign](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-03-spring-cloud-feign)
+- [《芋道 Spring Cloud 服务网关 Spring Cloud Gateway 入门》](http://www.iocoder.cn/Spring-Cloud/Spring-Cloud-Gateway/?vip) 对应 [labx-08-spring-cloud-gateway](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-08-spring-cloud-gateway)
+- [《芋道 Spring Cloud 链路追踪 SkyWalking 入门》](http://www.iocoder.cn/Spring-Cloud/SkyWalking/?vip) 对应 [labx-14](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-14)
+- [《芋道 Dubbo Admin 快速入门》](http://www.iocoder.cn/Dubbo/Admin/?vip)
+- [《芋道 Dubbo Swagger 快速入门》](http://www.iocoder.cn/Dubbo/Swagger/?vip) 对应 [swagger-dubbo](https://github.com/YunaiV/swagger-dubbo)
+
+# 3. Spring Cloud 专栏
+
+## 3.1 注册中心
+
+- [《芋道 Spring Cloud Alibaba 注册中心 Nacos 入门》](http://www.iocoder.cn/Spring-Cloud-Alibaba/Nacos-Discovery/?vip) 对应 [labx-01-spring-cloud-alibaba-nacos-discovery](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-01-spring-cloud-alibaba-nacos-discovery)
+- [《芋道 Spring Cloud Netflix 注册中心 Eureka 入门》](http://www.iocoder.cn/Spring-Cloud/Netflix-Eureka?vip) 对应 [labx-22](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-22)
+- [《芋道 Spring Cloud 注册中心 Zookeeper 入门》](http://www.iocoder.cn/Spring-Cloud/ZooKeeper-Discovery/?vip) 对应 [labx-25](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-25)
+- [《芋道 Spring Cloud 注册中心 Consul 入门》](http://www.iocoder.cn/Spring-Cloud/Consul-Discovery/?vip) 对应 [labx-27](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-27)
+- [《芋道 Spring Cloud 注册中心 Etcd 入门》](http://www.iocoder.cn/Spring-Cloud/Etcd/?vip)
+
+## 3.2 服务调用
+
+- [《芋道 Spring Cloud Alibaba 服务调用 Dubbo 入门》](http://www.iocoder.cn/Spring-Cloud-Alibaba/Dubbo/?vip) 对应 [labx-07-spring-cloud-alibaba-dubbo](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-07-spring-cloud-alibaba-dubbo)
+- [《芋道 Spring Cloud Netflix 负载均衡 Ribbon 入门》](http://www.iocoder.cn/Spring-Cloud-Netflix/Ribbon/?vip) 对应 [labx-02-spring-cloud-netflix-ribbon](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-02-spring-cloud-netflix-ribbon)
+- [《芋道 Spring Cloud 声明式调用 Feign 入门》](http://www.iocoder.cn/Spring-Cloud/Feign/?vip) 对应 [labx-03-spring-cloud-feign](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-03-spring-cloud-feign)
+- [《芋道 Spring Cloud 服务调用 gRPC 入门》](http://www.iocoder.cn/Spring-Cloud/gRPC/?vip) 对应 [labx-30-spring-cloud-grpc](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-30-spring-cloud-grpc)
+
+## 3.3 服务容错
+
+- [《芋道 Spring Cloud Alibaba 服务容错 Sentinel 入门》](http://www.iocoder.cn/Spring-Cloud-Alibaba/Sentinel/?vip) 对应 [labx-04-spring-cloud-alibaba-sentinel](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-04-spring-cloud-alibaba-sentinel)
+- [《芋道 Spring Cloud Netflix 服务容错 Hystrix 入门》](http://www.iocoder.cn/Spring-Cloud/Netflix-Hystrix/?vip) 对应 [labx-23](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-23)
+- [《芋道 Spring Cloud 服务容错 Resilience4j 入门》](http://www.iocoder.cn/Spring-Cloud/Resilience4j/?vip) 对应 [lab-59](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-59)
+
+## 3.4 API 网关
+
+- [《芋道 Spring Cloud 服务网关 Spring Cloud Gateway 入门》](http://www.iocoder.cn/Spring-Cloud/Spring-Cloud-Gateway/?vip) 对应 [labx-08-spring-cloud-gateway](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-08-spring-cloud-gateway)
+- [《芋道 Spring Cloud Netflix 服务网关 Zuul 入门》](http://www.iocoder.cn/Spring-Cloud/Netflix-Zuul/?vip) 对应 对应 [labx-21](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-21)
+- [《性能测试 —— Spring Cloud Gateway、Zuul 基准测试》](http://www.iocoder.cn/Performance-Testing/SpringCloudGateway-Zuul-benchmark/?vip) 对应 [lab-07](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-07)
+
+> 如下非 Spring Cloud 网关，先放在这里…
+
+- [《芋道 APISIX 极简入门（国产微服务网关）》](http://www.iocoder.cn/APISIX/install/?vip) 对应 [lab-56](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-56)
+- [《芋道 Soul 极简入门（国产微服务网关）》](http://www.iocoder.cn/Soul/install/?vip) 对应 [lab-60](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-60)
+- [《芋道 Kong 极简入门（微服务网关）》](http://www.iocoder.cn/Kong/install/?vip) 对应 [lab-56](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-56)
+
+## 3.5 配置中心
+
+- [《芋道 Spring Cloud Alibaba 配置中心 Nacos 入门》](http://www.iocoder.cn/Spring-Cloud-Alibaba/Nacos-Config/?vip) 对应 [labx-05-spring-cloud-alibaba-nacos-config](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-05-spring-cloud-alibaba-nacos-config)
+- [《芋道 Spring Cloud 配置中心 Apollo 入门》](http://www.iocoder.cn/Spring-Cloud/Apollo/?vip) 对应 [labx-09-spring-cloud-apollo](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-09-spring-cloud-apollo)
+- [《芋道 Spring Cloud 配置中心 Spring Cloud Config 入门》](http://www.iocoder.cn/Spring-Cloud/Spring-Cloud-Config/?vip) 对应 [labx-12-spring-cloud-config](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-12-spring-cloud-config)
+- [《芋道 Spring Cloud 配置中心 Zookeeper 入门》](http://www.iocoder.cn/Spring-Cloud/ZooKeeper-Config/?vip) 对应 [labx-26](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-26)
+- [《芋道 Spring Cloud 配置中心 Consul 入门》](http://www.iocoder.cn/Spring-Cloud/Consul-Config/?vip) 对应 [labx-28](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-28)
+- [《芋道 Spring Cloud 配置中心 Etcd 入门》](http://www.iocoder.cn/Spring-Cloud/Etcd/?vip)
+
+## 3.6 消息队列
+
+**Spring Cloud Stream**
+
+- [《芋道 Spring Cloud Alibaba 消息队列 RocketMQ 入门》](http://www.iocoder.cn/Spring-Cloud-Alibaba/RocketMQ/?vip) 对应 [labx-06-spring-cloud-stream-rocketmq](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-06-spring-cloud-stream-rocketmq)
+- [《芋道 Spring Cloud 消息队列 RabbitMQ 入门》](http://www.iocoder.cn/Spring-Cloud/RabbitMQ/?vip) 对应 [labx-10-spring-cloud-stream-rabbitmq](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-10-spring-cloud-stream-rabbitmq)
+- [《芋道 Spring Cloud 消息队列 Kafka 入门》](http://www.iocoder.cn/Spring-Cloud/Kafka/?vip) 对应 [labx-11-spring-cloud-stream-kafka](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-11-spring-cloud-stream-kafka)
+- [《芋道 Spring Cloud 消息队列 ActiveMQ 入门》](http://www.iocoder.cn/Spring-Cloud/ActiveMQ/?vip)
+
+**Spring Cloud Bus**
+
+- [《芋道 Spring Cloud Alibaba 事件总线 Bus RocketMQ 入门》](http://www.iocoder.cn/Spring-Cloud-Alibaba/Bus-RocketMQ/?vip) 对应 [labx-20](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-20)
+- [《芋道 Spring Cloud 事件总线 Bus RabbitMQ 入门》](http://www.iocoder.cn/Spring-Cloud/Bus-RabbitMQ/?vip) 对应 [labx-19](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-19)
+- [《芋道 Spring Cloud 事件总线 Bus Kafka 入门》](http://www.iocoder.cn/Spring-Cloud/Bus-Kafka/?vip) 对应 [labx-18](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-18)
+- [《芋道 Spring Cloud 事件总线 Bus Consul 入门》](http://www.iocoder.cn/Spring-Cloud/Bus-Consul/?vip) 对应 [labx-29-spring-cloud-consul-bus](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-29-spring-cloud-consul-bus)
+
+## 3.9 分布式事务
+
+- [《芋道 Spring Cloud Alibaba 分布式事务 Seata 入门》](http://www.iocoder.cn/Spring-Cloud-Alibaba/Seata/?vip) 对应 [labx-17](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-17)
+
+## 3.8 监控管理
+
+- [《芋道 Spring Boot 异常管理平台 Sentry 入门》](http://www.iocoder.cn/Spring-Boot/Sentry/?vip) 对应 [lab-51](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-51)
+- [《芋道 Spring Boot 监控端点 Actuator 入门》](http://www.iocoder.cn/Spring-Boot/Actuator/?vip) 对应 [lab-34](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-34)
+- [《芋道 Spring Cloud 监控工具 Admin 入门》](http://www.iocoder.cn/Spring-Cloud/SB-Admin/?vip) 对应 [labx-15](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-15)
+- [《芋道 Spring Boot 监控平台 Prometheus + Grafana 入门》](http://www.iocoder.cn/Spring-Boot/Prometheus-and-Grafana/?vip) 对应 [lab-36](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-36)
+
+## 3.9 持续交付
+
+- [《芋道 Spring Cloud 持续交付 Jenkins 入门》](http://www.iocoder.cn/Spring-Cloud/Jenkins/?vip) 对应 [labx-16](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-16)
+- [《芋道 Spring Boot 单元测试 Test 入门》](http://www.iocoder.cn/Spring-Boot/Unit-Test/?vip) 对应 [lab-42](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-42)
+- 《芋道 Spring Cloud 容器 Docker 入门》计划中…
+
+## 3.10 链路追踪
+
+- [《芋道 Spring Cloud 链路追踪 SkyWalking 入门》](http://www.iocoder.cn/Spring-Cloud/SkyWalking/?vip) 对应 [labx-14](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-14)
+- [《芋道 Spring Cloud 链路追踪 Spring Cloud Sleuth》](http://www.iocoder.cn/Spring-Cloud/Spring-Cloud-Sleuth/?vip) 对应 [labx-13](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-13)
+
+# 4. 书籍
+
+[《Spring Cloud 书单整理》](http://www.iocoder.cn/Books/Spring-Cloud-books-recommended)
+
+比较推荐其中的两本：
+
+- [《Spring Cloud 微服务实战》](https://union-click.jd.com/jdc?d=505Twi) ，可能是市面上最好的 Spring Cloud 教程。
+- [《微服务设计》](https://union-click.jd.com/jdc?d=0oiQ5c) ，要认真学习微服务，不然仅仅只是会使用框架的工程师。
\ No newline at end of file
diff --git a/学习指南/08-MyBatis 学习指南.md b/学习指南/08-MyBatis 学习指南.md
new file mode 100644
index 0000000..a3cbc2e
--- /dev/null
+++ b/学习指南/08-MyBatis 学习指南.md	
@@ -0,0 +1,84 @@
+# 精尽 MyBatis 学习指南
+
+# 视频
+
+- [《MyBatis 视频教程全集》](https://www.bilibili.com/video/av59564271/?pikaqiu) 一共 235P 。
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 本视频分成 A/B/C 三部分。
+  >
+  > - 【必选】A 部分（MyBatis 篇） P01-P88
+  >
+  >   MyBatis配置文件编写，MyBatis动态SQL，MyBatis缓存机制，MyBatis-Spring整合，MyBatis逆向工程，MyBatis高级内容（MyBatis源码解析，MyBatis单/多插件运行机制，MyBatis四大对象工作原理，自定义TypeHandler、MyBatis存储过程&游标处理等）。 视频中会在重要的地方对比MyBatis操作MySQL以及Oracle之间的差异性。
+  >
+  > - 【可选】B 部分（MyBatis-Plus 篇） P89-P178
+  >
+  >   MyBatis-Plus是一款非常强大的MyBatis增强工具包,只做增强不做改变.在不用编写任何SQL语句的情况下即可以极其方便的实现单一、批量、分页等操作。本套教程基于MyBatis-Plus新2.3版本。
+  >
+  > - 【随意】C 部分（通用 Mapper 篇） P179-P235
+  >
+  >   通用Mapper是一款非常好用的MyBatis插件，它能够帮助我们自动生成常用增删改查操作的SQL语句，克服MyBatis开发过程中需要大量编写SQL语句的弊端。由于通用Mapper是根据实体类的属性自动生成对应的SQL语句，所以可以说通用Mapper插件是对MyBatis在ORM方面不足的重要补充。
+
+- [《SSM 整合视频教程全集》](https://www.bilibili.com/video/av59585780/?pikaqiu) 一共有 35P 。
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 和《尚硅谷 Spring 视频教程》是同一个讲师。
+
+- 源生活 [《通过自动回复机器人学 Mybatis — 基础版》](https://www.imooc.com/learn/154) 一共 4 小时 30 分钟。
+
+- 源生活 [《通过自动回复机器人学Mybatis — 加强版》](https://www.imooc.com/learn/260) 一共 2 小时 43 分钟。
+
+- 黑马程序员 [《黑马程序员 - mybatis》](https://www.bilibili.com/video/av17774929) 一共有 50P 。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 书籍
+
+[《MyBatis 书单整理》](http://www.iocoder.cn/Books/MyBatis-books-recommended)
+
+- 刘增辉 [《MyBatis 从入门到精通》](https://book.douban.com/subject/27074809/) 豆瓣评分 7.2 分
+- 杨开振 [《深入浅出 MyBatis 技术原理与实战》](https://book.douban.com/subject/26858114/) 豆瓣 5.2 分
+- 徐郡明 [《MyBatis 技术内幕》](https://book.douban.com/subject/27087564/) 豆瓣评分 7.9 分 重源码
+
+如果是为了入门学习，推荐第一本。
+如果是为了阅读源码，推荐第三本。
+
+# 文章
+
+非常重要，一定一定一定认真看官方文档 [《MyBatis 官方文档》](http://www.mybatis.org/mybatis-3/zh/index.html) 。
+
+- [《芋道 Spring Boot 数据库连接池入门》](http://www.iocoder.cn/Spring-Boot/datasource-pool/?vip) 对应 [lab-19](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-19)
+
+- [《芋道 Spring Boot MyBatis 入门》](http://www.iocoder.cn/Spring-Boot/MyBatis/?vip) 对应 [lab-12-mybatis](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-12-mybatis)
+
+- [《芋道 Spring Boot 多数据源（读写分离）入门》](http://www.iocoder.cn/Spring-Boot/dynamic-datasource/?vip) 对应 [lab-17](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-17)
+
+- [《芋道 Spring Boot 分库分表入门》](http://www.iocoder.cn/Spring-Boot/sharding-datasource/?vip) 对应 [lab-18](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-18)
+
+- 《芋道 Spring Boot 数据库版本管理入门》
+
+   
+
+  对应
+
+   
+
+  lab-20
+
+  - [《芋道 Spring Boot 数据表结构文档》](http://www.iocoder.cn/Spring-Boot/DB-Doc-screw/?vip) 对应 [lab-70-db-doc](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-70-db-doc)
+
+- [《性能测试 —— MySQL 基准测试》](http://www.iocoder.cn/Performance-Testing/MySQL-benchmark/?github)
+
+- [《Spring Boot 整合 MyBatis》](http://www.iocoder.cn/Spring-Boot/didi/spring-boot-mybatis/?svip)
+
+- [《Spring Boot 中使用 MyBatis 注解配置详解》](http://www.iocoder.cn/Spring-Boot/didi/spring-boot-mybatis-annotations/?svip)
+
+- [《一起来学 SpringBoot 2.x | 第七篇：整合 Mybatis》](http://www.iocoder.cn/Spring-Boot/battcn/v2-orm-mybatis/?svip)
+
+- [《Spring Boot 整合 Mybatis 的完整 Web 案例》](http://www.iocoder.cn/Spring-Boot/bysocket/spring-boot-mybatis-with-web-in-action/?svip)
+
+- [《Spring Boot 整合 Mybatis Annotation 注解案例》](http://www.iocoder.cn/Spring-Boot/byscoket/spring-boot-mybatis-annotations-in-action/?svip)
+
+- [《Spring Boot 整合 Mybatis 实现 Druid 多数据源配置》](http://www.iocoder.cn/Spring-Boot/byscoket/spring-boot-mybatis-with-druid?svip)
\ No newline at end of file
diff --git a/学习指南/09-Hibernate 学习指南.md b/学习指南/09-Hibernate 学习指南.md
new file mode 100644
index 0000000..fd5fcd5
--- /dev/null
+++ b/学习指南/09-Hibernate 学习指南.md	
@@ -0,0 +1,62 @@
+# 精尽 Hibernate 学习指南
+
+可能对于头发比较茂盛的胖友来说，可能是没学习过 Hibernate 。一旦提到 Hibernate 时，就深恶痛绝，鄙视其不够灵活，且性能过差。但是呢，实际是：
+
+- 1、Hibernate 和 MyBatis 不会存在太大的性能差异。往往出现性能问题是，使用者错误的使用。
+- 2、国外大多数使用 Hibernate 为主，国内大多数使用 MyBatis 为主。
+
+感兴趣的胖友，可以看看如下三篇文章：
+
+- [《国内程序员的十大疑问之一：为什么老外不愿意用MyBatis？》](https://www.jianshu.com/p/654f387cd865)
+- [《为什么感觉国内比较流行的 mybatis 在国外好像没人用的样子？》](https://www.v2ex.com/t/518087)
+- [《MyBatis和Hibernate相比，优势在哪里？》](https://www.zhihu.com/question/21104468)
+
+当然了，既然 MyBatis 是国内比较重度使用，所以 Hibernate 可以作为选择性学习。亲，请不要挑战“国情”。
+
+抛开以上的问题不说，可能很多胖友是搞不清楚 JPA、Spring Data JPA、Hibernate 三者的关系的。😈 可以来看看 [《JPA规范与ORM框架之间的关系是怎样的呢？》](https://www.cnblogs.com/xiaoheike/p/5150553.html) 。嘿嘿，艿艿有时候喜欢拿这个问题来“坑”候选人。不过哈，答对只会加分，答错也不会扣分，纯粹判断这个人是否在这块的知识体系是否清晰。
+
+# 视频
+
+- [《Hibernate 视频教程全集》](https://www.bilibili.com/video/av59574656/?pikaqiu) 一共 60P ，15 小时。
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 本视频分成 A/B/C 三部分。
+  >
+  > - 【必选】A 部分（Hibernate 篇） P01-P25
+  >
+  >   Hibernate配置文件编写，Hibernate动态SQL，Hibernate缓存机制，Hibernate-Spring整合，Hibernate逆向工程，Hibernate高级内容（Hibernate源码解析，Hibernate单/多插件运行机制，Hibernate四大对象工作原理，自定义TypeHandler、Hibernate存储过程&游标处理等）。 视频中会在重要的地方对比Hibernate操作MySQL以及Oracle之间的差异性。
+  >
+  > - 【可选】B 部分（JPA 篇） P26-P49
+  >
+  >   Hibernate-Plus是一款非常强大的Hibernate增强工具包,只做增强不做改变.在不用编写任何SQL语句的情况下即可以极其方便的实现单一、批量、分页等操作。本套教程基于Hibernate-Plus新2.3版本。
+  >
+  > - 【必选】C 部分（Spring Data 篇） P50-P60
+  >
+  >   虽然是讲 Spring Data ，但是内容是以 Spring Data JPA 为主。当然实际上，Spring Data 是一个体系，也有 Spring Data MongoDB 等等其他实现。
+
+- 传智播客 [《Hibernate 从入门到精通》](https://www.bilibili.com/video/av46992190) 一共有 50P ，12 小时。
+
+- 千锋教育 [《快速入门Hibernate5.0》](https://www.bilibili.com/video/av45818582) 一共有 32P ，7 小时。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 书籍
+
+[《Hibernate 书单整理》](http://www.iocoder.cn/Books/Hibernate-books-recommended)
+
+相对来说，没有什么特别合适的书。当年艿艿买的是孙卫琴的《精通Hibernate（第2版）》，但是奈何，实在太厚，并且工作中使用的是 MyBatis 。所以呢，就没有去看。
+
+而入门的时候，自己看的是马士兵的 Hiberante 。
+
+# 文章
+
+- [《芋道 Spring Boot 数据库连接池入门》](http://www.iocoder.cn/Spring-Boot/datasource-pool/?vip) 对应 [lab-19](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-19)
+- [《芋道 Spring Boot JPA 入门》](http://www.iocoder.cn/Spring-Boot/JPA/?vip) 对应 [lab-13-spring-data-jpa](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-13-spring-data-jpa)
+- [《芋道 Spring Boot 多数据源（读写分离）入门》](http://www.iocoder.cn/Spring-Boot/dynamic-datasource/?vip) 对应 [lab-17](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-17)
+- [《芋道 Spring Boot 分库分表入门》](http://www.iocoder.cn/Spring-Boot/sharding-datasource/?vip) 对应 [lab-18](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-18)
+- [《芋道 Spring Boot 数据库版本管理入门》](http://www.iocoder.cn/Spring-Boot/database-version-control/?vip) 对应 [lab-20](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-20)
+- [《芋道 Spring Boot 数据表结构文档》](http://www.iocoder.cn/Spring-Boot/DB-Doc-screw/?vip) 对应 [lab-70-db-doc](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-70-db-doc)
+- [《性能测试 —— MySQL 基准测试》](http://www.iocoder.cn/Performance-Testing/MySQL-benchmark/?github)
+- [《一起来学 SpringBoot 2.x | 第六篇：整合 SpringDataJPA》](http://www.iocoder.cn/Spring-Boot/battcn/v2-orm-jpa/?svip&vip)
+- [《Spring Data JPA 从入门到进阶系列教程》](http://www.iocoder.cn/Spring-Data-JPA/good-collection/?svip&vip)
\ No newline at end of file
diff --git a/学习指南/10-RocketMQ 学习指南.md b/学习指南/10-RocketMQ 学习指南.md
new file mode 100644
index 0000000..cf0fc23
--- /dev/null
+++ b/学习指南/10-RocketMQ 学习指南.md	
@@ -0,0 +1,63 @@
+# 精尽 RocketMQ 学习指南
+
+# 视频
+
+- [《RocketMQ 视频教程全集》](https://www.bilibili.com/video/av59635085/?pikaqiu)
+  \> **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  \>
+  \> 一共有 15P ，2 小时。
+  \>
+
+- 马士兵 [《RocketMQ 视频》](https://www.bilibili.com/video/av11074519)
+
+  > 2 小时多。😈 想当年，艿艿是听马老师的 Java 视频入门的，有多少胖友也是的，🙋
+
+- 阿里 P9 沈旬 [《阿里分布式开放消息服务(ONS)原理与实践》](http://v.youku.com/v_show/id_XODY4NjYxNDE2.html?spm=a2h0j.11185381.listitem_page1.5!10~A)
+
+  > 一共有 3 个 Part ，非常值得看。
+
+- 传智播客 [《中间件之 RocketMQ》](https://www.bilibili.com/video/av30925688)
+
+  > 暂时挂了，后续修复
+  >
+  > 目录有点杂，需要胖友自己看，不仅仅有 RocketMQ ，还有部分 RabbitMQ 等等。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 书籍
+
+[《RocketMQ 书单整理》](http://www.iocoder.cn/Books/RocketMQ-books-recommended)
+
+- 目前暂时没有特别好的 RocketMQ 书籍。所以更加推荐阅读如下内容：
+  - [《RocketMQ 用户指南》](http://gd-rus-public.cn-hangzhou.oss-pub.aliyun-inc.com/attachment/201604/08/20160408164726/RocketMQ_userguide.pdf) 基于 RocketMQ 3 的版本。
+  - [《RocketMQ 原理简介》](http://gd-rus-public.cn-hangzhou.oss-pub.aliyun-inc.com/attachment/201604/08/20160408165024/RocketMQ_design.pdf) 基于 RocketMQ 3 的版本。
+  - [《RocketMQ 最佳实践》](http://gd-rus-public.cn-hangzhou.oss-pub.aliyun-inc.com/attachment/201604/08/20160408164929/RocketMQ_experience.pdf) 基于 RocketMQ 3 的版本。
+  - [《阿里云 —— 消息队列 MQ》](https://help.aliyun.com/product/29530.html?spm=a2c4g.11186623.6.540.68cc5b3aZYDU2Y) 阿里云的消息队列，就是 RocketMQ 的云服务。
+
+# 文章
+
+**RocketMQ 源码**
+
+- 艿艿 [《RocketMQ 源码解析系列》](http://www.iocoder.cn/categories/RocketMQ/?vip)
+- 艿艿 [《性能测试 —— RocketMQ 基准测试》](http://www.iocoder.cn/Performance-Testing/RocketMQ-benchmark/?vip)
+
+**RocketMQ 入门**
+
+- [《芋道 Spring Boot 消息队列 RocketMQ 入门》](http://www.iocoder.cn/Spring-Boot/RocketMQ/?vip) 对应 [lab-31](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-31) 。
+- [《芋道 RocketMQ 安装部署》](http://www.iocoder.cn/RocketMQ/install/?vip)
+- 艿艿把网络上看到比较好的，按照自己的理解整理了下顺序。注意哈，几篇文章的作者是不同的。
+  - zhisheng [《RocketMQ 入门 —— 初探》](http://www.iocoder.cn/RocketMQ/start/intro)
+  - zhisheng [《RocketMQ 入门 —— 安装以及快速入门》](http://www.iocoder.cn/RocketMQ/start/install)
+  - zhisheng [《RocketMQ 入门 —— 简单的消息示例》](http://www.iocoder.cn/RocketMQ/start/example)
+  - zhisheng [《RocketMQ 入门 —— 基于 Spring 使用 RocketMQ 以及监控》](http://www.iocoder.cn/RocketMQ/start/spring-example-and-monitor)
+  - 辽天 [《RocketMQ 入门 —— 基于 Spring Boot 使用 RocketMQ》](http://www.iocoder.cn/RocketMQ/start/spring-boot-example)
+  - CHEN川 [《RocketMQ 入门 —— 原理与实践》](http://www.iocoder.cn/RocketMQ/start/RocketMQ/start/Principle-and-practice)
+
+**RocketMQ 原理**
+
+- Jaskey Lam [《RocketMQ 详解》](https://zhuanlan.zhihu.com/rocketmq)
+- 鼬神 [《Apache RocketMQ 背后的设计思路与最佳实践》](http://jm.taobao.org/2017/03/09/20170309/)
+- 阿里中间件小哥 [《一文讲透 Apache RocketMQ 技术精华》](http://www.10tiao.com/html/683/201811/2650718577/1.html)
+- 冯嘉 [《RocketMQ 4.3 正式发布，支持分布式事务》](https://www.infoq.cn/article/2018%2F08%2Frocketmq-4.3-release)
+
+如果胖友有看到合适的文章，也可以推荐给我哟。
\ No newline at end of file
diff --git a/学习指南/11-RabbitMQ 学习指南.md b/学习指南/11-RabbitMQ 学习指南.md
new file mode 100644
index 0000000..a05178d
--- /dev/null
+++ b/学习指南/11-RabbitMQ 学习指南.md	
@@ -0,0 +1,41 @@
+# 精尽 RabbitMQ 学习指南
+
+# 1. 视频
+
+- [《RabbitMQ 视频教程全集》](https://www.bilibili.com/video/av59630756/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共有 17P ，3 小时。
+  >
+  > 听说是照着厮大的 《RabbitMQ 实战指南》 讲的，哈哈哈哈。
+
+- [《ActiveMQ 视频教程全集》](https://www.bilibili.com/video/av59631589/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共有 17P ，6 小时。
+  >
+  > 嘿嘿，先暂时把 ActiveMQ 的视频，放在本文中。木有找到合适的地方。
+  >
+  > 一般来说，现在已经不太需要学习 ActiveMQ 了，使用的公司已经很少了，主要是老项目。
+
+- 阿神 [《RabbitMQ 消息中间件极速入门与实战》](https://www.imooc.com/learn/1042)
+
+  > 2 小时 31 分钟。以 RabbitMQ 入门，和 Spring Boot2 整合为主。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 2. 书籍
+
+[《RabbitMQ 书单整理》](http://www.iocoder.cn/Books/RabbitMQ-books-recommended)
+
+- 当然二话不说，强烈建议看看厮大的 [《RabbitMQ 实战指南》](https://union-click.jd.com/jdc?d=mmamvo) ，无敌！
+
+# 3. 文章
+
+- 艿艿 [《芋道 RabbitMQ 安装部署》](http://www.iocoder.cn/RabbitMQ/install/?vip)
+- 艿艿 [《芋道 Spring Boot 消息队列 RabbitMQ 入门》](http://www.iocoder.cn/Spring-Boot/RabbitMQ/?vip) 对应 [lab-04-rabbitmq](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-04-rabbitmq)
+- 艿艿 [《性能测试 —— RocketMQ 基准测试》](http://www.iocoder.cn/Performance-Testing/RocketMQ-benchmark/?vip)
+- 厮大 [《RabbitMQ 各种文章》](http://www.iocoder.cn/RabbitMQ/good-collection/)
+- oliver_lv [《浅析消息队列 RabbitMQ》](http://blog.jobbole.com/107237/)
\ No newline at end of file
diff --git a/学习指南/12-Shiro 学习指南.md b/学习指南/12-Shiro 学习指南.md
new file mode 100644
index 0000000..f114aa9
--- /dev/null
+++ b/学习指南/12-Shiro 学习指南.md	
@@ -0,0 +1,33 @@
+# 精尽 Shiro 学习指南
+
+# 视频
+
+- [《Shiro 视频教程全集》](https://www.bilibili.com/video/av59635802/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 27P ，3 小时。
+
+- [《RBAC 权限实战视频教程全集》](https://www.bilibili.com/video/av48305719/?self)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 62P ，9 小时。
+
+- 叩丁狼教育 [《Shiro最新全套在线教程》](https://www.bilibili.com/video/av39052886) 一共 30P，7 小时不到。
+
+- 千锋教育 [《千锋Java教程：Shiro框架从入门到实战》](https://www.bilibili.com/video/av39289229) 一共 16P， 6 小时多。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 书籍
+
+没有 Shiro 或 Spring Security 的书籍。
+
+# 文章
+
+- [《芋道 Spring Boot 安全框架 Spring Security 入门》](http://www.iocoder.cn/Spring-Boot/Spring-Security/?vip) 对应 [lab-01-spring-security](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-01-spring-security)
+- [《芋道 Spring Boot 授权框架 Spring Security OAuth2 入门》](http://www.iocoder.cn/Spring-Security/OAuth2-learning/?vip) 对应 [lab-68-spring-security-oauth](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-02-spring-security-oauth) 。
+- [《芋道 Spring Boot 安全框架 Shiro 入门》](http://www.iocoder.cn/Spring-Boot/Shiro/?vip) 对应 [lab-33](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-33) 。
+- [《Shiro 源码解析》](http://www.iocoder.cn/Shiro/good-collection/?vip&svip)
+- [《Spring Security 源码解析》](http://www.iocoder.cn/Spring-Security/good-collection/?vip&svip)
\ No newline at end of file
diff --git a/学习指南/13-Kafka 学习指南.md b/学习指南/13-Kafka 学习指南.md
new file mode 100644
index 0000000..c5ea134
--- /dev/null
+++ b/学习指南/13-Kafka 学习指南.md	
@@ -0,0 +1,52 @@
+# 精尽 Kafka 学习指南
+
+# 1. 视频
+
+- [《消息队列 Kafka 视频教程全集》](https://www.bilibili.com/video/av59634004/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 24P ，5 个小时多。
+
+- 炼石成金 [《中间件之 Kafka》](https://www.bilibili.com/video/av30928064)
+
+  > 一共有 19P 。概念部分讲的蛮细的。
+  >
+  > 暂时失效，后续修复。
+
+- 书生小四 [《Kafka 流处理平台》](https://www.imooc.com/learn/1043)
+
+  > 一共 1 小时 16 分钟。简单的入门，时间也不长。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 2. 书籍
+
+[《Kafka 书单整理》](http://www.iocoder.cn/Books/Kafka-books-recommended)
+
+- **宇宙级预告，厮大的 Kafka 书籍也要出了，高能预警**！！！！
+- 入门进阶的话，推荐 [《Kafka 权威指南》](https://u.jd.com/jJpbF8) 豆瓣评分 9 分，恐怖。
+- 原理源码的话，推荐 [《Apache Kafka 源码剖析》](https://u.jd.com/bhCtFA) 豆瓣评分 8.3 分
+
+相比 RabbitMQ 和 RocketMQ 来说，Kafka 牛逼的书，真的太多了。所以呢，Kafka 如果是胖友系统中非常重要的组件，建议多看几本，也是没错的。据说，我们家厮大，看了 7 本。恐怖如厮~
+
+# 3. 文章
+
+- [《芋道 Kafka 极简入门》](http://www.iocoder.cn/Kafka/install/?vip)
+- [《芋道 Spring Boot 分布式消息队列 Kafka 入门》](http://www.iocoder.cn/Spring-Boot/Kafka/?vip)
+- [《芋道 Spring Cloud 消息队列 Kafka 入门》](http://www.iocoder.cn/Spring-Cloud/Kafka/?vip)
+- [《芋道 Spring Cloud 事件总线 Bus Kafka 入门》](http://www.iocoder.cn/Spring-Cloud/Bus-Kafka/?vip)
+- [《如何搭建 Kafka 调试环境，仅需 5 分钟！》](http://www.iocoder.cn/Kafka/build-debugging-environment/?vip)
+
+------
+
+- 艿艿 [《性能测试 —— RocketMQ 基准测试》](http://www.iocoder.cn/Performance-Testing/RocketMQ-benchmark/?vip)
+- 厮大
+  - [《Kafka 各种文章》](http://www.iocoder.cn/Kafka/good-collection/)
+  - [《Kafka 数据可靠性深度解读》](https://blog.csdn.net/u013256816/article/details/71091774) 强烈推荐，惊为天人。
+- 飞哥
+  - [《Kafka 设计（上）》](http://www.jianshu.com/p/e5b8ddb479f4)
+  - [《Kafka 设计（下）》](http://www.jianshu.com/p/dd494be9d706)
+- 薛定谔的鸡 [《Kafka 史上最详细原理总结》](https://blog.csdn.net/YChenFeng/article/details/74980531)
+
+如果胖友有看到合适的文章，也可以推荐给我哟。
\ No newline at end of file
diff --git a/学习指南/14-Redis 学习指南.md b/学习指南/14-Redis 学习指南.md
new file mode 100644
index 0000000..7cebccc
--- /dev/null
+++ b/学习指南/14-Redis 学习指南.md	
@@ -0,0 +1,65 @@
+# 精尽 Redis 学习指南
+
+# 1. 视频
+
+- [《Redis 视频教程全集》](https://www.bilibili.com/video/av59604203/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 28P ，9 个多小时。
+
+- 动力节点 [《Redis 视频教程》](https://www.bilibili.com/video/av16841549)
+
+  > 一共 24P ，覆盖 Redis 还是比较全的。
+
+- RyzeZiggs [《Redis 从入门到高可用，分布式实践》](https://www.bilibili.com/video/av37985196)
+
+  > 一共 17P ，非入门，覆盖常见的 Redis 实践常见的问题。
+  >
+  > 暂时挂了，后续修复
+
+- 慕神 [《Redis 入门》](https://www.imooc.com/learn/839)
+
+  > 一共 2 小时 30 分钟不到，入门级。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 2. 书籍
+
+[《Redis 书单整理》](http://www.iocoder.cn/Books/Redis-books-recommended)
+
+- 付磊 / 张益军 [《Redis 开发与运维》](https://u.jd.com/lDNJa9)
+
+  > 豆瓣评分 9.0 的神书，各种实战。
+
+- 黄健宏 [《Redis 设计与实现》](https://u.jd.com/Fl5NTt)
+
+  > 豆瓣评分 8.4 ，重在 Redis 的原理和源码。
+
+- 老钱 [《Redis 深度历险：核心原理与应用实践》](https://juejin.im/book/5afc2e5f6fb9a07a9b362527?referrer=5904c637b123db3ee479d923)
+
+  > 电子书，内容挺深入，地铁上可以看看。
+
+如果胖友已经有 Redis 的基础，可以按照 [《Redis 深度历险：核心原理与应用实践》](https://juejin.im/book/5afc2e5f6fb9a07a9b362527?referrer=5904c637b123db3ee479d923) => [《Redis 开发与运维》](https://u.jd.com/lDNJa9) 的顺序来看。主要考虑是，[《Redis 深度历险：核心原理与应用实践》](https://juejin.im/book/5afc2e5f6fb9a07a9b362527?referrer=5904c637b123db3ee479d923) 是精简的原理和实践方面的内容，可以更快的得到“很爽”的学习快感。
+
+如果胖友已经有 Redis 的基础，可以按照 [《Redis 开发与运维》](https://u.jd.com/lDNJa9) => [《Redis 深度历险：核心原理与应用实践》](https://juejin.im/book/5afc2e5f6fb9a07a9b362527?referrer=5904c637b123db3ee479d923) => 的顺序来看。主要考虑是，[《Redis 开发与运维》](https://u.jd.com/lDNJa9) 是覆盖面更全，更成体系化。
+
+关于 [《Redis 设计与实现》](https://u.jd.com/Fl5NTt) 这本书，主要以源码为主。艿艿自己的话，暂时没看，主要考虑需要花费的时间比较多，收益可能比较少。等以后，实战碰到问题，找不到资料的时候，在抽时间来看对应的源码。😈 当然，也是因为 C 语言多少是个障碍，哈哈哈。
+
+# 3. 文章
+
+- 芋艿 [《芋道 Spring Boot Redis 入门》](http://www.iocoder.cn/Spring-Boot/Redis/?vip)
+- 芋艿 [《芋道 Spring Boot 缓存 Cache 入门》](http://www.iocoder.cn/Spring-Boot/Cache/?vip)
+- 芋艿 [《精尽 Redis 源码分析 —— 调试环境搭建》](http://svip.iocoder.cn/Redis/build-debugging-environment/?self)
+- 芋艿 [《精尽 Redisson 源码分析 —— 调试环境搭建》](http://svip.iocoder.cn/Redisson/build-debugging-environment/?self)
+- 芋艿 [《精尽 Redisson 源码分析 —— 限流器 RateLimiter》](http://svip.iocoder.cn/Redisson/RateLimiter/?self)
+- 芋艿 [《精尽 Redisson 源码分析 —— 可重入分布式锁 ReentrantLock》](http://svip.iocoder.cn/Redisson/ReentrantLock/?self)
+- 芋艿 [《精尽 Redisson 源码分析 —— 可靠分布式锁 RedLock》](http://svip.iocoder.cn/Redisson/RedLock/?self)
+- 芋艿 [《性能测试 —— Redis 基准测试》](http://www.iocoder.cn/Performance-Testing/Redis-benchmark/?self)
+- 付磊 [《阿里云 Redis 开发规范》](https://yq.aliyun.com/articles/531067?spm=a2c4e.11155435.0.0.5f9a3236YxSXGA)
+- 付磊 / 张益军 [《Redis 架构之防雪崩设计：网站不宕机背后的兵法》](https://mp.weixin.qq.com/s/TBCEwLVAXdsTszRVpXhVug)
+- Spring4All [《技术专题讨论第五期：论系统架构设计中缓存的重要性》](http://www.spring4all.com/question/177)
+- Allen_jiang [《脚踏两只船的困惑 - Memcached 与 Redis》](https://www.imooc.com/article/23549)
+- 阿里云云栖社区 [《Redis 深入之道：原理解析、场景使用以及视频解读》](https://zhuanlan.zhihu.com/p/28073983)
+- carlosfu [《Redis-Cluster 实战)》](https://www.iteye.com/blogs/subjects/Redis_Cluster_Devops)
+- 怀听 [《阿里云 Redis 混合存储典型场景：如何轻松搭建视频直播间系统》](https://yq.aliyun.com/articles/582487?spm=a2c4e.11155435.0.0.6159b169C9jUkZ)
\ No newline at end of file
diff --git a/学习指南/15-MySQL 学习指南.md b/学习指南/15-MySQL 学习指南.md
new file mode 100644
index 0000000..bec6729
--- /dev/null
+++ b/学习指南/15-MySQL 学习指南.md	
@@ -0,0 +1,89 @@
+# 精尽 MySQL 学习指南
+
+# 1. 视频
+
+- [《MySQL 视频教程全集》](https://www.bilibili.com/video/av59623481/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 241P ，21 个多小时。
+  >
+  > 本视频分成 A/B 两部分。
+  >
+  > - 【必选】A 部分（MySQL 核心技术） P01-P178
+  > - 【必选】B 部分（MySQL 高级进阶）P179-P241
+
+- [《Oracle 视频教程全集》](https://www.bilibili.com/video/av59590533/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 42P ，21 个多小时。
+
+- [《SQLServer 视频教程全集》](https://www.bilibili.com/video/av59596659/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 99P ，22 个多小时。
+
+- 燕十八 [《MySQL 从入门到精通视频教程 》](https://www.bilibili.com/video/av19538278/)
+
+  > 一共 46P ，比较全面，讲师还是蛮幽默的，当然胖友也可能觉得啰嗦。
+
+- 钟勇 [《MySQL 数据库进阶/高级教程》](https://www.bilibili.com/video/av22645209)
+
+  > 一共 38P ，风格偏向干货型，正如其标题，讲进阶，而不是入门。
+
+- sqlercn [《性能优化之 MySQL 优化》](https://www.imooc.com/learn/194)
+
+  > 一共 2 小时，比较简单的讲了下 MySQL 相关的优化。
+
+- sqlercn [《MySQL5.7 复制功能实战》](https://www.imooc.com/learn/589)
+
+  > 一共 1 小时 29 分，了解 MySQL 复制功能。
+
+- 神思者l [《MySQL 集群（PXC）入门》](https://www.imooc.com/learn/993)
+
+  > 一共 3 小时 12 分钟，了解 MySQL PXC 。
+
+- 沈询 [《在线分布式数据库原理与实践》](https://www.imooc.com/learn/272)
+
+  > 一共 1 小时 53 分钟，有趣，牛逼，强烈推荐！！！
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 2. 书籍
+
+[《MySQL 书单整理》](http://www.iocoder.cn/Books/MySQL-books-recommended)
+
+书籍比较多，胖友可以根据自己的需要来选择。购买之前，可以多看看豆瓣和亚马逊对数的评价。如下几本是艿艿和基友比较推荐的：
+
+- [《高性能 MySQL》](https://union-click.jd.com/jdc?d=6UXfwU)
+
+  > 豆瓣评分 9.3 ，神书！基本人手一本。最最最墙裂推荐，可能没有之一。
+
+- [《高可用 MySQL》](https://union-click.jd.com/jdc?d=0s7OAw)
+
+  > 豆瓣评分 8.0 ，《高性能 MySQL》的姊妹篇。
+
+- [《MySQL 必知必会》](https://u.jd.com/XcZehc)
+
+  > 豆瓣评分 8.4 ，适合 MySQL 入门。
+
+- 还有其它书籍也是不错的，胖友根据需要瞅瞅。当然，还是那句话，买一本看一本，不贪多。
+
+另外，[MySQL 的官方文档](https://dev.mysql.com/doc/refman/8.0/en/)，写的也是非常不错的，英语比较好的胖友，也可以看看。
+
+# 3. 文章
+
+- [《芋道 Spring Boot 数据库连接池入门》](http://www.iocoder.cn/Spring-Boot/datasource-pool/?vip) 对应 [lab-19](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-19)
+- [《芋道 Spring Boot MyBatis 入门》](http://www.iocoder.cn/Spring-Boot/MyBatis/?vip) 对应 [lab-12-mybatis](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-12-mybatis)
+- [《芋道 Spring Boot JPA 入门》](http://www.iocoder.cn/Spring-Boot/JPA/?vip) 对应 [lab-13-spring-data-jpa](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-13-spring-data-jpa)
+- [《芋道 Spring Boot JdbcTemplate 入门》](http://www.iocoder.cn/Spring-Boot/JdbcTemplate/?vip) 对应 [lab-14-spring-jdbc-template](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-14-spring-jdbc-template)
+- [《芋道 Spring Boot 多数据源（读写分离）入门》](http://www.iocoder.cn/Spring-Boot/dynamic-datasource/?vip) 对应 [lab-17](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-17)
+- [《芋道 Spring Boot 分库分表入门》](http://www.iocoder.cn/Spring-Boot/sharding-datasource/?vip) 对应 [lab-18](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-18)
+- [《芋道 Spring Boot 数据库版本管理入门》](http://www.iocoder.cn/Spring-Boot/database-version-control/?vip) 对应 [lab-20](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-20)
+- [《芋道 Spring Boot 数据表结构文档》](http://www.iocoder.cn/Spring-Boot/DB-Doc-screw/?vip) 对应 [lab-70-db-doc](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-70-db-doc)
+- [《性能测试 —— MySQL 基准测试》](http://www.iocoder.cn/Performance-Testing/MySQL-benchmark/?vip)
+- [《MySQL 数据库开发的三十六条军规》](https://blog.csdn.net/aa_moon/article/details/53435768)
+- bali [《数据库分库分表后，如何部署上线？》](http://www.iocoder.cn/Fight/After-the-database-sharding-how-to-deploy-online/)
+- 阿飞 [《分库分表技术演进&最佳实践》](https://mp.weixin.qq.com/s/3ZxGq9ZpgdjQFeD2BIJ1MA)
\ No newline at end of file
diff --git a/学习指南/16-Elasticsearch 学习指南.md b/学习指南/16-Elasticsearch 学习指南.md
new file mode 100644
index 0000000..782fec2
--- /dev/null
+++ b/学习指南/16-Elasticsearch 学习指南.md	
@@ -0,0 +1,44 @@
+# 精尽 Elasticsearch 学习指南
+
+目前 Elasticsearch 已经更新到 7.X 的版本，市面上的资料可能有些滞后，但是问题不大，有差异的地方，当然是 [官网文档](https://www.elastic.co/guide/index.html) 走起。
+
+另外，在 [Elasticsearch 中文社区](https://elasticsearch.cn/) 也提供了非常多靠谱的资料。
+
+# 1. 视频
+
+- [《Elasticsearch 视频教程全集》](https://www.bilibili.com/video/av59628430/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 62P ，女老师，嘿嘿，版本比较新，是 Elasticsearch 6 的版本。
+  >
+  > 全文搜索的需求非常大。而开源的解决办法Elasricsearch（Elastic）就是一个非常好的工具。目前是全文搜索引擎的首选。本系列教程由浅入深讲解了在CentOS7系统下如何搭建ElasticSearch，如何使用Kibana实现各种方式的搜索并详细分析了搜索的原理，最后讲解了在JAVA应用中如何集成ElasticSearch并实现搜索。
+
+- 龙果学院 [《Elasticsearch 顶尖高手系列 - 快速入门篇》](https://www.bilibili.com/video/av29521652)
+
+  > 一共 74P ，口语化，比较舒服。基于 Elasticsearch5.2 版本。
+  >
+  > 另外，还有一个 [《Elasticsearch 顶尖高手系列 - 进阶篇》](https://www.bilibili.com/video/av46797028) 。
+
+- rockybean [《Elastic Stack 入门》](https://www.imooc.com/learn/920)
+
+  > 一共 1 小时 30 分钟多，ELK 相关。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 2. 书籍
+
+[《Elasticsearch 书单整理》](http://www.iocoder.cn/Books/Elasticsearch-books-recommended/)
+
+艿艿暂时挑不出合适的书，比较感兴趣的还是[《Elasticsearch源码解析与优化实战》](https://u.jd.com/FxxLWO) 这本。
+
+另外，[《Elasticsearch 实战》](https://u.jd.com/s77Fx9) 最近出版不久，可能也不错，毕竟“实战”系列比较靠谱。
+
+建议的话，胖友可以先看看上面的视频。
+
+# 3. 文章
+
+- 芋艿 [《芋道 Spring Boot Elasticsearch 入门》](http://www.iocoder.cn/Spring-Boot/Elasticsearch/?vip) 对应 [lab-15](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-15) 。
+- 芋艿 [《芋道 Elasticsearch 安装部署》](http://www.iocoder.cn/Elasticsearch/install/?vip)
+- 芋艿 [《芋道 ELK(Elasticsearch + Logstash + Kibana) 安装部署》](http://www.iocoder.cn/Elasticsearch/ELK-install/?vip)
+- 阮一峰 [《全文搜索引擎 Elasticsearch 入门教程》](http://www.ruanyifeng.com/blog/2017/08/elasticsearch.html)
\ No newline at end of file
diff --git a/学习指南/17-设计模式学习指南.md b/学习指南/17-设计模式学习指南.md
new file mode 100644
index 0000000..a8048e2
--- /dev/null
+++ b/学习指南/17-设计模式学习指南.md
@@ -0,0 +1,47 @@
+# 精尽设计模式学习指南
+
+# 1. 视频
+
+- [《设计模式视频教程全集》](https://www.bilibili.com/video/av59599696/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共有 150P 33 小时。死磕！！！
+
+- [《Java 视频教程全集》](https://www.bilibili.com/video/av59529105/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 从 P286 ~ P314 ，适合作为一个入门的教程。
+
+- 极客学院 [《Java 的 23 种设计模式》](https://www.bilibili.com/video/av29988660?)
+
+  > 一共 81P ，按照 [《Head First 设计模式》](https://union-click.jd.com/jdc?d=HYyuyM) 来讲的，可以结合着看。
+
+- 极客班 [《23 个设计模式》](https://www.bilibili.com/video/av24176315)
+
+  > 一共 26P ，评价不错。
+
+- 北风网 [《一周彻底搞懂 23 种设计模式（Java实现）》](https://www.bilibili.com/video/av34162848)
+
+  > 一共 25P ，讲的算清晰，不过声音略小。
+
+相对来说，设计模式的课程的标题比较固定。所以说，如果一个设计模式看不懂，可以看另外的视频对这个模式的讲解。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 2. 书籍
+
+[《设计模式书单整理》](http://www.iocoder.cn/Books/Design-Pattern-books-recommended)
+
+设计模式好书比较多，推荐看 [《Head First 设计模式》](https://union-click.jd.com/jdc?d=HYyuyM) 这本书，从头到尾看完，每种模式的具体实现代码，自己手敲下，好好感受。
+
+# 3. 文章
+
+- 小明哥 [《设计模式 —— 精品合集》](http://www.iocoder.cn/DesignPattern/good-collection/?vip)
+- 知秋
+  - [《Spring 框架中的设计模式(一)》](http://www.iocoder.cn/Spring/DesignPattern-1?vip)
+  - [《Spring 框架中的设计模式(二)》](http://www.iocoder.cn/Spring/DesignPattern-2?vip)
+  - [《Spring 框架中的设计模式(三)》](http://www.iocoder.cn/Spring/DesignPattern-3?vip)
+  - [《Spring 框架中的设计模式(四)》](http://www.iocoder.cn/Spring/DesignPattern-4?vip)
+  - [《Spring 框架中的设计模式(五)》](http://www.iocoder.cn/Spring/DesignPattern-5?vip)
\ No newline at end of file
diff --git a/学习指南/18-数据结构与算法学习指南.md b/学习指南/18-数据结构与算法学习指南.md
new file mode 100644
index 0000000..0c24d6e
--- /dev/null
+++ b/学习指南/18-数据结构与算法学习指南.md
@@ -0,0 +1,82 @@
+# 精尽数据结构与算法学习指南
+
+对于大多数人，算法会相对比较枯燥，所以可以以看视频为主，书籍为辅。适当的，可以去 [LeetCode](https://leetcode.com/) 刷点题。
+
+有一点要注意，我们常常把 **“数据结构”** 和 **“算法”** 放在一起说，实际上它们是很有关系、相辅相成的**两个**东西，简单类比我们平时写的代码：
+
+- 数据结构 = 数据表结构
+- 算法 = 逻辑代码
+
+详细的，可以看看 [《数据结构和算法的关系》](https://blog.csdn.net/xujiangdong1992/article/details/72867903) 文章。
+
+# 1. 视频
+
+- [《Java 语言数据结构与算法视频教程全集》](https://www.bilibili.com/video/av59600020/?self)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共有 195P ，50 小时。
+
+- [《C 语言数据结构与算法视频教程全集》](https://www.bilibili.com/video/av59628848/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共有 99P ，28 小时。
+  >
+  > 听说是照着 《大话数据结构》 念的，哈哈哈哈。
+
+- 【清华大学】邓俊辉教授 [《数据结构与算法》](https://www.bilibili.com/video/av22774520)
+
+  > 一共 474P ，数量比较多，每 P 的时长不多，一共 34 小时。当然，内容挺棒的。
+
+- 【北京大学】屈婉玲教授 [《算法设计与分析》](https://www.bilibili.com/video/av7134874)
+
+  > 一共 76P ，分成 10 个章节，一共 16 小时。
+
+- 【浙江大学】陈越 [《数据结构》](https://www.bilibili.com/video/av18586085)
+
+  > 一共 143P，分成 11 个章节，一共 17 小时。
+
+- 【麻省理工学院】公开课 [《算法导论》](http://open.163.com/special/opencourse/algorithms.html)
+
+  > 一共 23 集，相对讲的比较难 :-D
+
+相对来说，算法的课程的标题比较固定。所以说，如果一个算法看不懂，可以看另外的视频对这个算法的讲解。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 2. 书籍
+
+[《数据结构与算法书单整理》](http://www.iocoder.cn/Books/Data-Structures-and-Algorithms-books-recommended)
+
+- [《数据结构与算法分析：Java 语言描述》](https://union-click.jd.com/jdc?d=IOGxFX)
+
+  > 豆瓣评分 8.3 分，厚度可以接受，主要 Java 语言是很大的优势。
+
+- [《算法导论(原书第 3 版)》](https://u.jd.com/M6Fx6x)
+
+  > 豆瓣评分 9.3 分，4800 多人评价，基本是最经典的一本算法书籍。
+
+- [《我的第一本算法书》](https://u.jd.com/IIN1uV)
+
+  > 豆瓣评分 9.7 分，趣味性极强的算法书籍。算法可能对于大多数人来说，特别枯燥，比较难找到嗨点。那么，这本书相对会适合你，能看完的算法书，才是最合适你的算法书。
+
+- [《程序员代码面试指南：IT 名企算法与数据结构题目最优解（第二版）》](https://item.jd.com/12518392.html)
+
+  > 豆瓣评分 8.9 分，以面试视角的算法书。
+
+- [《剑指 Offer：名企面试官精讲典型编程题》](https://union-click.jd.com/jdc?d=wnrKQh)
+
+  > 豆瓣评分 9.1 分，也讲了面试中的算法，同时也介绍了其它的。
+
+- [《编程之美：微软技术面试心得》](https://u.jd.com/wTp20p)
+
+  > 豆瓣评分 8.3 分，3000 多人评价，还是一本面试相关的算法书籍。主要是，大多数胖友学习算法是为了解决面试，所以就多推荐一点啦。
+
+根据自己的情况和用途，选择哪一本书。
+
+艿艿最近刷了下 [数据结构与算法之美](http://www.iocoder.cn/images/jikeshijian/数据结构与算法之美.jpg) 和 [算法面试通关 40 讲](http://www.iocoder.cn/images/jikeshijian/算法面试通关40讲.jpg) ，还不错。
+
+# 3. 文章
+
+- [《算法学习笔记》](http://www.iocoder.cn/Fight/Algorithmic-learning-notes/?vip)
\ No newline at end of file
diff --git a/学习指南/19-计算机网络学习指南.md b/学习指南/19-计算机网络学习指南.md
new file mode 100644
index 0000000..6dae866
--- /dev/null
+++ b/学习指南/19-计算机网络学习指南.md
@@ -0,0 +1,41 @@
+# 精尽计算机网络学习指南
+
+大多数胖友应该是开发工程师居多，所以在计算机网络的理解，重心在 HTTP > TCP 。当然，都理解是更棒的选择。
+
+# 1. 视频
+
+- [《TCP/IP 视频教程全集》](https://www.bilibili.com/video/av59637918/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 23P ，14 小时多。讲的比较细，相对推荐。
+
+- [《HTTP 视频教程全集》](https://www.bilibili.com/video/av59637918/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 9P ，7 小时多。讲师有点幽默。
+
+  - ps：HTTP 相关，艿艿暂时没找到特别合适的视频，希望能覆盖到 HTTP1、HTTP2、HTTPS 。所以，HTTP 的内容，建议选择看看书籍。
+
+- 电子科技大学 [《TCP/IP 详解》](https://www.bilibili.com/video/av23038786)
+
+  > 一共 42P ，讲的不错，就是音质有点令人☹️ 。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 2. 书籍
+
+[《计算机网络书单整理》](http://www.iocoder.cn/Books/Net-books-recommended)
+
+- 图解系列是非常适合理解这种枯燥的概念的，所以推荐如下三本书：
+  - [《图解 TCP/IP(第 5 版)》](https://u.jd.com/LF9IuE)
+  - [《图解 HTTP》](https://u.jd.com/xE2oKH)
+  - [《网络是怎样连接的》](https://item.jd.com/26222331708.html)
+- HTTP 的理解，对开发帮助还是蛮大的，所以再推荐如下两本书：
+  - [《HTTP 权威指南》](https://union-click.jd.com/jdc?d=TgCRBb)
+  - [《HTTP/2 基础教程》](https://u.jd.com/8K8wF2)
+
+# 3. 文章
+
+- 老钱 [《跟着动画来学习 TCP 三次握手和四次挥手》](http://www.iocoder.cn/Interview/Follow-the-animation-to-learn-TCP-three-handshakes-and-four-waves/?vip)
\ No newline at end of file
diff --git a/学习指南/20-Linux 学习指南.md b/学习指南/20-Linux 学习指南.md
new file mode 100644
index 0000000..6bd544e
--- /dev/null
+++ b/学习指南/20-Linux 学习指南.md	
@@ -0,0 +1,64 @@
+# 精尽 Linux 学习指南
+
+大多数胖友都是开发工程师，所以我们在 Linux 方面的学习，更多的是掌握常用的 Linux 命令，简单的 Shell 脚本。这样，我们看看服务器日志，瞅瞅 Linux 的运行状况(CPU、内存、磁盘等)，安装常用软件等等。
+
+> 也可以看看知乎 [《Web 后端攻城狮要学 Linux 吗，一般要学到什么水平呢？》](https://www.zhihu.com/question/31859809) 上的讨论。
+
+当然，是否相对全面的掌握 Linux 里的知识，主要看工作需要，以及自己的个人兴趣啦。
+
+# 1. 视频
+
+- [《Linux 视频教程全集》](https://www.bilibili.com/video/av59640439/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 78P ，21 个多小时。
+
+- 兄弟连(李明 + 沈超) [《史上最牛的 Linux 视频教程》](https://www.bilibili.com/video/av18156598)
+
+  > 一共 78P ，时长有 21 小时。
+
+- 黑马 [《Linux 全套教程》](https://www.bilibili.com/video/av33660709)
+
+  > 一共 344P ，时长有 71 小时。
+
+- 京峰教育(吴光科) [《Shell 编程从入门到放弃（2016）》](https://svip.iocoder.cn/Linux/tutorials/)
+
+  > 一共 20P ，时长有 8 小时。
+
+- 马哥教育(王晓春) [《全新 Shell 脚本入门教程（2019）》](https://www.bilibili.com/video/av8104450)
+
+  > 一共 5P ，时长有 6 小时。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 2. 书籍
+
+[《Linux 书单整理》](http://www.iocoder.cn/Books/Linux-books-recommended/?vip)
+
+- [《鸟哥的 Linux 私房菜:基础学习篇(第四版)》](https://u.jd.com/0gS6Dx)
+
+  > - 豆瓣评分：9.1【2269 人评价】
+  > - 推荐理由：本书是最具知名度的Linux入门书《鸟哥的Linux私房菜基础学习篇》的最新版，全面而详细地介绍了Linux操作系统。
+  > - 友情提示：内容非常全面，建议挑选和自己实际工作相关度较高的，其他部分有需要再阅读。
+  >
+  > 艿艿当然很认真的看了这本书~
+
+- [《鸟哥的Linux私房菜 （服务器架设篇）》](https://union-click.jd.com/jdc?d=TC0EE6)
+
+  > - 豆瓣评分：8.8 【198 人评价】
+  > - 推荐理由：胖友已有 Linux 基础，想要进一步学习服务器架设？还想了解如何维护与管理您的服务器？本书是不错的选择。
+  >
+  > 不过这本书，艿艿只看了一部分，比较多是从网上搜索文章来学习的。
+
+- [《Linux 内核设计与实现》](https://union-click.jd.com/jdc?d=3VaGzn)
+
+  > - 豆瓣评分：8.7【286 人评价】
+  > - 详细描述了 Linux 内核的主要子系统和特点，包括 Linux 内核的设计、实现和接口。从理论到实践涵盖了 Linux 内核的方方面面，可以满足读者的各种兴趣和需求。
+  > - 友情提示：Linux 内核方面不乏好书。本书篇幅方面较为合适。
+  >
+  > 艿艿买的是这本，不过被虐的太惨了，在慢慢啃。
+
+# 3. 文章
+
+- [《如何用九条命令在一分钟内检查 Linux 服务器性能？》](http://www.iocoder.cn/Fight/How-do-I-check-Linux-server-performance-in-one-minute-with-nine-commands/?vip)
\ No newline at end of file
diff --git a/学习指南/21-Git 学习指南.md b/学习指南/21-Git 学习指南.md
new file mode 100644
index 0000000..1d29668
--- /dev/null
+++ b/学习指南/21-Git 学习指南.md	
@@ -0,0 +1,41 @@
+# 精尽 Git 学习指南
+
+绝大数情况下，我们对 Git 需要掌握的是：
+
+1. Git 常用命令
+2. Git 分支管理模型
+
+# 1. 视频
+
+- [《Git 视频教程全集》](https://www.bilibili.com/video/av59634634/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 62P ，6 个多小时。
+
+- 黑马程序员 [《学会 Git 玩转 Github》](https://www.bilibili.com/video/av10475153)
+
+  > 一共 10 P ，3 个小时不到。
+  >
+  > 也讲了如何使用 Github Page 搭建个人博客。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 2. 书籍
+
+[《Git 书单整理》](http://www.iocoder.cn/Books/Git-books-recommended/?vip)
+
+- 超级强烈推荐 [《Git 教程》](https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000)
+
+  > 文字 + 图片 + 视频 。
+  >
+  > 比较浅显易懂
+
+- 其它的书籍，胖友根据情况买落。🙂 艿艿是不太想为了 Git 看 200-300 页的书。嘿嘿。
+
+# 3. 文章
+
+- marklodato [《图解 Git》](https://marklodato.github.io/visual-git-guide/index-zh-cn.html)
+- 超哥 [《Git 常用命令速查手册》](http://www.iocoder.cn/Fight/Git-command-quick-reference-manual/?vip)
+- 猫尾 [《Git 提交记录和分支模型》](http://www.iocoder.cn/Fight/Git-commits-records-and-branching-models/?vip)
+- 自由 [《我必须分享给大家的 Git 资源汇总》](http://www.iocoder.cn/Fight/I-have-to-share-Git-resource-summary-with-you/?vip)
\ No newline at end of file
diff --git a/学习指南/22-Maven 学习指南.md b/学习指南/22-Maven 学习指南.md
new file mode 100644
index 0000000..e737623
--- /dev/null
+++ b/学习指南/22-Maven 学习指南.md	
@@ -0,0 +1,39 @@
+# 精尽 Maven 学习指南
+
+绝大数情况下，我们对 Maven 需要掌握的是：
+
+1. Maven 基本概念。
+2. 使用 Maven 创建项目。
+3. 使用 Maven 构建 war、jar 包等。
+
+# 1. 视频
+
+- [《Maven 视频教程全集》](https://www.bilibili.com/video/av59640042/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 35P ，5 个多小时。
+
+- [《Gradle 视频教程全集》](https://www.bilibili.com/video/av59640008/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 12P ，1 个多小时。
+
+- 张果 [《Maven 快速学习教程》](https://www.bilibili.com/video/av31623453)
+
+  > 一共 23P ，7 个多小时。
+  >
+  > 基于 IDEA 使用 Maven 插件，好评~
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 2. 书籍
+
+[《Maven 书单整理》](http://www.iocoder.cn/Books/Maven-books-recommended/?vip)
+
+推荐 [《Maven 实战》](https://union-click.jd.com/jdc?d=hNj9Lu) 书，基本是能找到的最好的 Maven 资料~并且，本书作者本人，就是 Java 领域超强的技术专家。
+
+# 3. 文章
+
+- 张果 [《一个小时学会 Maven》](https://www.cnblogs.com/best/p/9676515.html)
\ No newline at end of file
diff --git a/学习指南/23-Jenkins 学习指南.md b/学习指南/23-Jenkins 学习指南.md
new file mode 100644
index 0000000..dd6c0aa
--- /dev/null
+++ b/学习指南/23-Jenkins 学习指南.md	
@@ -0,0 +1,41 @@
+# 精尽 Jenkins 学习指南
+
+绝大数情况下，我们对 Jenkins 需要掌握的是：
+
+1. Jenkins 配置项目发布。
+2. 持续交付的理论体系。
+
+# 1. 视频
+
+- 《Jenkins 视频教程全集》
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 22P ，1 个多小时。
+
+☹️ 暂时找不到特别合适的视频。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 2. 书籍
+
+[《Jenkins 书单整理》](http://www.iocoder.cn/Books/Jenkins-books-recommended/?vip)
+
+- [《Jenkins 权威指南》](https://union-click.jd.com/jdc?d=75C9Oh)
+
+  > 版本有点太老，不是很推荐购买。
+
+- [《持续交付》](https://u.jd.com/vKHLZ7)
+
+  > - 豆瓣评分：8.6【311 人评价】
+  >
+  > Jenkins 给我们带来持续集成的能力，而持续集成是持续交付中的一环。所以，我们是非常有必要系统的学习下持续交付相关的知识体系。
+  >
+  > 因为，我们使用 Jenkins 不仅仅是想要能够发布项目，而是希望整个项目的交付能够更有序。
+
+# 3. 文章
+
+如果胖友有看到合适的文章，也可以推荐给我哟。
+
+- [《芋道 Jenkins 安装部署》](http://www.iocoder.cn/Jenkins/install?vip)
+- [《芋道 Spring Boot 持续交付 Jenkins 入门》](http://www.iocoder.cn/Spring-Boot/Jenkins/?vip) 对应 [lab-41](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-41) 。
\ No newline at end of file
diff --git a/学习指南/24-IntelliJ IDEA 学习指南.md b/学习指南/24-IntelliJ IDEA 学习指南.md
new file mode 100644
index 0000000..fde5daa
--- /dev/null
+++ b/学习指南/24-IntelliJ IDEA 学习指南.md	
@@ -0,0 +1,30 @@
+# 精尽 IntelliJ IDEA 学习指南
+
+# 1. 视频
+
+- [《IntelliJ IDEA 视频教程全集》](https://www.bilibili.com/video/av59631589/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 19P ，4 个小时不到。
+
+- 闪电侠 [《IntelliJ IDEA 神器使用技巧》](https://www.imooc.com/learn/924)
+
+  > 时长 2 小时多，从此改变你的 IDEA 使用习惯！
+  >
+  > 😈 艿艿要问闪电侠要 5 毛水军费，哈哈哈哈。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 2. 书籍
+
+在亚马逊搜了下，IDEA 也是有书的，感觉蛮神奇的。但是，目前都是英文的，所以就可能不太适合拿来做推荐。
+
+当然，良心的艿艿在 Github 的仓库中无意中发现 https://github.com/judasn/IntelliJ-IDEA-Tutorial ，可能是最强的 IntelliJ IDEA 简体中文专题教程。推荐一波~
+
+> 佩服下这个作者的毅力，维护了至少 3 年+了。
+
+# 3. 文章
+
+- [《芋道 IDEA 插件推荐》](http://www.iocoder.cn/IDEA/plugins/?vip)
+- [《IntelliJ IDEA 最新注册码（截止到2019年5月4日）》](https://blog.csdn.net/qq_35246620/article/details/80522720)
\ No newline at end of file
diff --git a/学习指南/25-Java【基础】学习指南.md b/学习指南/25-Java【基础】学习指南.md
new file mode 100644
index 0000000..ad426e2
--- /dev/null
+++ b/学习指南/25-Java【基础】学习指南.md
@@ -0,0 +1,82 @@
+# 精尽 Java【基础】学习指南
+
+# 1. 视频
+
+- [《Java 视频教程全集》](https://www.bilibili.com/video/av59529105/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 另外，这个视频不仅仅包括 Java 部分，也包括 JVM、设计模式等等，也比较推荐。
+  >
+  > 注意，GUI 目前用的比较少，简单了解即可，当然最推荐是直接跳过！
+
+- [《Java 8/9/11 新特性视频教程全集》](https://www.bilibili.com/video/av59549886/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 本视频分成 A/B/C 三部分，一共 65P ，15 小时多。
+  >
+  > - A 部分 Java8 P01-P21
+  >
+  >   本Java视频涵盖了 Java8 的所有新特性：Lambda表达式、强大的 Stream API、全新时间日期 API、ConcurrentHashMap、MetaSpace。Java8 的新特性使 Java 的运行速度更快、代码更少（Lambda 表达式）、便于并行、最大化减少空指针异常。
+  >
+  > - B 部分 Java9 P22-P49
+  >
+  >   本套《Java9新特性》视频涵盖oracle公司2017年9月公布的java 9 新特性的核心内容。 主要包含：模块化系统，REPL工具：jshell命令，多版本兼容jar包，语法的新变化：接口私有方法、异常处理、钻石操作符、String存储结构变化等，新增API：Stream、List、Set、图像处理等。可以说java 9 的更新是一个大的工程。
+  >
+  > - C 部分 Java11 P50-P65
+  >
+  >   本套视频语调轻快、讲解深入，带你一睹Java11的风采：新的局部变量的语法、更方便的调试运行程序的方式jshell及直接运行源代码、令人瞩目的ZGC, JFR、全新HttpClient API、兼容Unicode10的新的字符串API等。
+
+- 马士兵 [《Java 视频教程》](https://www.bilibili.com/video/av36806419)
+
+  > Java 部分，只要看 P1~P148 的视频。
+  > 剩余的部分，是关于 GUI 等等的内容，可以暂时不看。
+  >
+  > 艿艿当年学习，就是看的马士兵老师的视频。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+------
+
+学习完 Java 基础之后，就要学习 Java Web 相关的知识，可以看如下视频：
+
+- [《Java JDBC 视频教程全集》](https://www.bilibili.com/video/av59534040/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 24P ，11 个多小时。
+
+- [《Java Web 视频教程全集》](https://www.bilibili.com/video/av59545633/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 103P ，41 个多小时。
+
+- [《Java Web 项目实战视频教程全集》](https://www.bilibili.com/video/av60990675/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 17P ，8 个多小时。
+
+# 2. 书籍
+
+[《Java【基础】书单整理》](http://www.iocoder.cn/Books/Java-Core-books-recommended)
+
+- [《《Head First Java》 》](https://svip.iocoder.cn/Java/Core/tutorials/TODO) ，适合入门。
+
+- [《Effective Java 中文版（第三版）》](https://union-click.jd.com/jdc?d=S003h8) ，豆瓣评分 9.1 。本书介绍了在Java 编程中极具实用价值的经验规则，这些经验规则涵盖了大多数开发人员每天所面临的问题的解决方案。
+
+  > 艿艿：想当年，艿艿在实习的时候，在公交地铁上啃完这本书，收获颇多。
+  >
+  > 注意，本书不适合入门。
+
+- [《Java 性能权威指南》](https://union-click.jd.com/jdc?d=EK9G95) 和 [《Java 性能优化权威指南》](https://u.jd.com/b4XBVv) ，专注 Java 性能优化方面的书籍。
+
+- [《码出高效：Java 开发手册》](https://u.jd.com/ESouWq) ，阿里提供的 Java 开发规约和实践。
+
+# 3. 文章
+
+TODO 有点不知道推荐什么文章
+
+- [《芋道 Spring Boot JdbcTemplate 入门》](http://www.iocoder.cn/Spring-Boot/JdbcTemplate/?vip) 对应 [lab-14-spring-jdbc-template](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-14-spring-jdbc-template)
\ No newline at end of file
diff --git a/学习指南/26-Java【并发】学习指南.md b/学习指南/26-Java【并发】学习指南.md
new file mode 100644
index 0000000..5ad6068
--- /dev/null
+++ b/学习指南/26-Java【并发】学习指南.md
@@ -0,0 +1,47 @@
+# 精尽 Java【并发】学习指南
+
+# 1. 视频
+
+- [《Java 视频教程全集》](https://www.bilibili.com/video/av59529105/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 从 P194 ~ P232 ，适合作为一个入门的教程。
+
+- [《Java 并发视频教程全集》](https://www.bilibili.com/video/av59548640/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 15P ，适合作为一个入门的教程。
+
+- 叶子猿 [《Java 并发编程原理与实战》](https://www.bilibili.com/video/av43697557)
+
+  > 一共 59P ，讲的还是不错的。
+  >
+  > 适合作为一个进阶的课程。
+
+- 马士兵 [《Java多线程高并发编程》](https://www.bilibili.com/video/av33688545)
+
+  > 一共 23P ，马老师的幽默一如既往，但是略显啰嗦。
+  >
+  > 目前不是很推荐，可以作为一个补充吧。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 2. 书籍
+
+[《Java【并发】书单整理》](http://www.iocoder.cn/Books/Java-Concurrent-books-recommended/)
+
+- [《Java 并发编程实战》](https://union-click.jd.com/jdc?d=x2yrwq) ，豆瓣评分 9.0 ，深入浅出地介绍了 Java 线程和并发。
+
+  > 艿艿当年撸的好认真的一本书，当时立志成为一个牛逼的游戏后端主程(负责人)。
+
+- [《Java 并发编程的艺术》](https://u.jd.com/gpkonU) ，豆瓣评分 7.2 ，正如书名，很艺术的讲解了 Java 并发的原理，爆赞！
+
+另外，上述书单还有一些好书，胖友可以根据自己需要挑选挑选~
+
+# 3. 文章
+
+- 小明哥 [《死磕 Java 并发》](http://www.iocoder.cn/categories/JUC/?vip)
+- 程晓明 [《深入 Java 内存模型》](https://files-cdn.cnblogs.com/files/skywang12345/深入Java内存模型.pdf)
+- zhisheng [《深入理解 Java 内存模型》读书笔记](http://www.iocoder.cn/JUC/zhisheng/Java-Memory-Model/?vip)
\ No newline at end of file
diff --git a/学习指南/27-Java【虚拟机】学习指南.md b/学习指南/27-Java【虚拟机】学习指南.md
new file mode 100644
index 0000000..1dcc1c3
--- /dev/null
+++ b/学习指南/27-Java【虚拟机】学习指南.md
@@ -0,0 +1,54 @@
+# 精尽 Java【虚拟机】学习指南
+
+# 1. 视频
+
+- [《JVM 视频教程全集》](https://www.bilibili.com/video/av59549567/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 目前还不完整，主要作为 JVM 的快速入门。
+
+- [《Java 视频教程全集》](https://www.bilibili.com/video/av59529105/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 从 P280 ~ P285 ，主要讲解了 JVM 类加载机制，面试中贼喜欢问。
+
+- 叶子猿 [《深入理解 Java 虚拟机》](https://www.bilibili.com/video/av29502877)
+
+  > 一共 108P ，按照 [《深入理解Java虚拟机：JVM高级特性与最佳实践(第2版) 》](https://union-click.jd.com/jdc?d=Wa6dWb) 来讲的，可以结合着看。
+  >
+  > 适合作为进阶的内容。
+
+- 葛一鸣 [《深入 JVM 内核原理》](https://www.bilibili.com/video/av19249632)
+
+  > 一共 11P ，虽然看起来少，每 1P 基本是 40 分钟起。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 2. 书籍
+
+[《Java【虚拟机】书单整理》](http://www.iocoder.cn/Books/Java-Virtual-Machine-books-recommended)
+
+- 最最最推荐 [《深入理解Java虚拟机：JVM高级特性与最佳实践(第2版) 》](https://union-click.jd.com/jdc?d=Wa6dWb) 这本书，基本是必买的一本。
+- 一本好玩的书 [《自己动手写 Java 虚拟机》](https://u.jd.com/t0ia5p) ，不过读完估计要花些心思。
+
+其它书，也是非常不错的，胖友可以耐心看看。
+
+另外，[《深入拆解 Java 虚拟机》](http://gk.link/a/100kc) 也是不错的一个教程，艿艿也看了一遍~
+
+# 3. 文章
+
+- R 大 —— JVM 圈的传说
+  - [《RednaxelaFX 关于 VM 的帖的目录》](https://rednaxelafx.iteye.com/blog/362738)
+  - [知乎](https://www.zhihu.com/people/rednaxelafx/answers) R 大经常混迹在知乎上，有非常多的精彩回答。
+- 你假笨 —— JVM 圈的另一个传说
+  - [个人博客](http://lovestblog.cn/blog/archives/)
+  - [简书](https://www.jianshu.com/u/d126f1401a09)
+  - [iteye](https://nijiaben.iteye.com/category/273764)
+  - 牛逼文章
+    - [《据说 99.99% 的人都会答错的类加载的问题》](https://mp.weixin.qq.com/s/uyj9UDxR3DfWD3ZCzJrJLQ)
+- 飞哥
+  - TODO
+- 狼哥
+  - TODO
\ No newline at end of file
diff --git a/学习指南/28-Zookeeper 学习指南.md b/学习指南/28-Zookeeper 学习指南.md
new file mode 100644
index 0000000..7f1f52d
--- /dev/null
+++ b/学习指南/28-Zookeeper 学习指南.md	
@@ -0,0 +1,34 @@
+# 精尽 Zookeeper 学习指南
+
+# 1. 视频
+
+- [《Zookeeper 视频教程全集》](https://www.bilibili.com/video/av59629934/?self)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 23P ，2 个小时不到。
+
+- 尚学堂 [《Zookeeper 课程》](https://www.bilibili.com/video/av36435142)
+
+  > 一共 9P ，5 小时不到。
+
+- 叶子猿 [《Zookeeper 原理与实战》](https://www.roncoo.com/view/104)
+
+  > 一共 30 讲，需要付费。
+  >
+  > 大家自己解决。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 2. 书单
+
+[《Zookeeper 书单整理》](http://www.iocoder.cn/Books/Zookeeper-books-recommended)
+
+相对来说，Zookeeper 的书籍比较少。艿艿自己的话，买的是 [《从 Paxos 到 Zookeeper 分布式一致性原理与实践》](https://union-click.jd.com/jdc?d=YxOiGe) 。当然，说来惭愧，还没看完。
+
+# 3. 文章
+
+- [《芋道 Zookeeper 极简入门》](http://www.iocoder.cn/Zookeeper/install/?github)
+- [《ZooKeeper GUI 客户端》](http://www.iocoder.cn/Zookeeper/PrettyZoo/?github)
+- [《芋道 Spring Cloud 注册中心 Zookeeper 入门》](http://www.iocoder.cn/Spring-Cloud/ZooKeeper-Discovery/?github) 对应 [labx-25](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-25)
+- [《芋道 Spring Cloud 配置中心 Zookeeper 入门》](http://www.iocoder.cn/Spring-Cloud/ZooKeeper-Config/?github) 对应 [labx-26](https://github.com/YunaiV/SpringBoot-Labs/tree/master/labx-26)
\ No newline at end of file
diff --git a/学习指南/29-Nginx 学习指南.md b/学习指南/29-Nginx 学习指南.md
new file mode 100644
index 0000000..dd5038a
--- /dev/null
+++ b/学习指南/29-Nginx 学习指南.md	
@@ -0,0 +1,48 @@
+# 精尽 Nginx 学习指南
+
+# 1. 视频
+
+- [《Nginx 视频教程全集》](https://www.bilibili.com/video/av59639498/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 23 P ，13.5 小时。
+  >
+  > 增加了性能相关的部分，更更加详细。
+
+- 黑马程序员 [《Nginx 视频》](https://www.bilibili.com/video/av22576578)
+
+  > 一共 9 P ，3.5 小时。
+  >
+  > 比较精简，基本满足对 Nginx 的学习。
+
+- 老男孩教育 [《企业级 Nginx 负载均衡与 keepalived 高可用实战视频教程》](https://www.bilibili.com/video/av25869969)
+
+  > 一共 33 P ，6 小时。
+  >
+  > 把高可用部分也讲了，会更加详细。
+
+- 陶辉 [《Nginx 核心知识 100 讲》](http://static.iocoder.cn/images/jikeshijian/nginx.png)
+
+  > 一共 100 讲，约 10 小时。
+  >
+  > 需要付费，讲师是《深入理解 Nginx ：模块开发与架构详解》的作者，阿里云团队。
+
+# 2. 书单
+
+[《Nginx 书单整理》](http://www.iocoder.cn/Books/Nginx-books-recommended)
+
+- [《深入理解 Nginx（第 2 版）》](https://union-click.jd.com/jdc?d=19KLxr)
+
+  > 豆瓣评分 8.5 分。不过这本书，相对适用于需要在 Nginx 开发的工程师。
+
+- 不过艿艿觉得，对于我们开发来说，Nginx 研究不需要特别深入，更多深入的可能是运维工程师。
+
+# 3. 文章
+
+TODO
+
+- [《性能测试 —— Nginx 基准测试》](http://www.iocoder.cn/Performance-Testing/Nginx-benchmark/?vip)
+- [《芋道 Tengine 安装部署》](http://www.iocoder.cn/Nginx/Tengine-install/?vip)
+- [《性能测试 —— Tomcat、Jetty、Undertow 基准测试》](http://www.iocoder.cn/Performance-Testing/Tomcat-Jetty-Undertow-benchmark/?vip)
+- [《性能测试 —— Spring Cloud Gateway、Zuul 基准测试》](http://www.iocoder.cn/Performance-Testing/SpringCloudGateway-Zuul-benchmark/?vip)
\ No newline at end of file
diff --git a/学习指南/30-任务调度学习指南.md b/学习指南/30-任务调度学习指南.md
new file mode 100644
index 0000000..221a08e
--- /dev/null
+++ b/学习指南/30-任务调度学习指南.md
@@ -0,0 +1,49 @@
+# 精尽任务调度学习指南
+
+目前来说，任务调度系统，主流的有三种技术选型：
+
+- Quartz
+- Elastic Job
+- XXL-Job
+
+它们的大体关系是：
+
+- Quartz 可以单独使用，通过 MySQL 实现高可用。
+- Quartz 也被 Elastic Job、XXL-Job 进行封装，形成分布式调度系统。也就是说，三种技术选型，调度的内核都是 Quartz 。
+- Elastic Job 是去中心化的任务调度方案，XXL-Job 是中心化的任务调度方案。
+- 从易用性上来说，XXL-Job > Elastic Job 。相比来说，Elastic Job 的运维会更困难一些。
+- 从性能上来说，Elastic Job > XXL-Job 。因为其去中心化，所以不会因为中心调度节点，形成性能瓶颈。当然，大多数情况下，基本能满足我们的业务场景需要。毕竟，大厂公司居少。
+
+从学习的角度，三者都可以看看，花不了多少时间。
+
+艿艿自己的话，采用过的方案：
+
+- 1. 最早使用 Quartz + MySQL ，然后自己二次封装了一些运维需要的功能。因为 Quartz 不提供运维的功能，例如说暂停任务，立即执行一次任务，任务的执行监控等等。
+- 1. 后来，调研了下 Elastic Job ，也深入了研究了源码，考虑到体量，暂时就没用。
+- 1. 再后来，看了下 XXL-Job ，觉得基本能满足自己的诉求，就目前主要用了是这个。
+
+推荐阅读文章：
+
+- 芋艿 [《芋道 Spring Boot 定时任务入门》](http://www.iocoder.cn/Spring-Boot/Job/?vip) 对应 [lab-28](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-28) 。
+- 芋艿 [《芋道 XXL-JOB 安装部署》](http://www.iocoder.cn/XXL-JOB/install/?vip)
+- [《芋道 Spring Boot 异步任务入门》](http://www.iocoder.cn/Spring-Boot/Async-Job/?vip) 对应 [lab-29](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-29) 。
+
+# 1. Quartz
+
+- [《Quartz 视频教程全集》](https://www.bilibili.com/video/av59632817/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 21P ，3 个小时多。
+
+# 2. Elastic Job
+
+- [《Elastic Job 视频教程全集》](https://www.bilibili.com/video/av59632516/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 7P ，1 个小时多。
+
+# 3. XXL-Job
+
+文档比较健全，可以直接看 http://www.xuxueli.com/xxl-job/ 。
\ No newline at end of file
diff --git a/学习指南/31-Docker 学习指南.md b/学习指南/31-Docker 学习指南.md
new file mode 100644
index 0000000..18558bc
--- /dev/null
+++ b/学习指南/31-Docker 学习指南.md	
@@ -0,0 +1,33 @@
+# 精尽 Docker 学习指南
+
+# 1. 视频
+
+- [《容器 Docker 视频教程全集》](https://www.bilibili.com/video/av59639711/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 34P ，8 个小时不到。
+
+- 马哥 [《2018黑马 Docker 容器技术 + k8s 集群技术》](https://www.bilibili.com/video/av35847195)
+
+  > 一共 36P ，46 小时。
+  >
+  > 比较全面。
+
+- 极客学院 [《最新 docker 构建微服务框架 零基础入门》](https://www.bilibili.com/video/av23053656)
+
+  > 一共 58P ，26 小时多。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 2. 书单
+
+[《Docker 书单整理》](http://www.iocoder.cn/Books/Docker-books-recommended)
+
+- [《第一本 Docker 书 修订版》](https://union-click.jd.com/jdc?d=W4EYRx)
+
+  > 豆瓣评分 8.2 ，146 人评价。
+  >
+  > 比较适合入门 Docker 的一本薄书，252 页。
+
+- 剩余的，推荐开始直接干 Kubernetes 。边看，会发现 Docker 的知识遗漏点，在回过头补充。
\ No newline at end of file
diff --git a/学习指南/32-Kubernetes 学习指南.md b/学习指南/32-Kubernetes 学习指南.md
new file mode 100644
index 0000000..229bd67
--- /dev/null
+++ b/学习指南/32-Kubernetes 学习指南.md	
@@ -0,0 +1,29 @@
+# 精尽 Kubernetes 学习指南
+
+# 1. 视频
+
+- [《Kubernetes 视频教程全集》](https://www.bilibili.com/video/BV1ME411g7EU/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 70P ，17 小时。
+  >
+  > 比较全面。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 2. 书单
+
+[《Kubernetes 书单整理》](http://www.iocoder.cn/Books/Kubernetes-books-recommended)
+
+- [《Kubernetes权威指南》](https://union-click.jd.com/jdc?d=eGWYXy)
+
+  > 豆瓣评分：8.1 ，24 人评价。
+  >
+  > 艿艿已经刷完，感觉还不错。
+  >
+  > 另外，本书还有一本姊妹篇 [《Kubernetes 权威指南：企业级容器云实战》](https://item.jd.com/12420042.html) ，看了下作者，蛮多大佬。
+
+- [《深入剖析 Kubernetes 52 讲》](http://static.iocoder.cn/images/jksj/Kubernetes.jpeg)
+
+  > 张磊，Kubernetes 大佬，非常不错。
\ No newline at end of file
diff --git a/学习指南/33-React 学习指南.md b/学习指南/33-React 学习指南.md
new file mode 100644
index 0000000..4bfcbd7
--- /dev/null
+++ b/学习指南/33-React 学习指南.md	
@@ -0,0 +1,53 @@
+# 精尽 React 学习指南
+
+# 1. 视频
+
+- React
+
+  - [《React 视频教程全集》](https://www.bilibili.com/video/av59726903/?pikaqiu)
+
+    > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+    >
+    > 一共有 45P ，13 小时。
+
+  - 黑马程序员 [《最全的 react 视频》](https://www.bilibili.com/video/av37668737)
+
+    > 一共 54P ，10 小时不到。貌似，还没更新完。
+
+- 【前端】[《React 前台项目实战教程全集》](https://www.bilibili.com/video/av59727745/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 76P ，21 小时。
+
+- 【前端】[《React 后台项目实战教程全集》](https://www.bilibili.com/video/av59709253/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 76P ，38 小时。
+
+- React Native
+
+  - 使用 React 开发 App 。
+
+  - 未知 [《React Native 项目实战》](https://www.bilibili.com/video/av9213669)
+
+    > 一共 68P ，21 小时多。
+
+  - 后盾人 [《react native 深入讲解进阶课》](https://www.bilibili.com/video/av3573430)
+
+    > 一共 98P ，20 小时多。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 2. 书籍
+
+[《React 书单整理》](http://www.iocoder.cn/Books/React-books-recommended)
+
+自己选择，不过问了下公司的前端，貌似基本没特别去看过 React 的书籍，主要看的是官方文档为主。
+
+# 3. 文章
+
+- [Ant Design](https://ant.design/index-cn)
+
+  > 推荐一个 React 的 UI 组件库。虽然上次出了一次圣诞事故，但是还是指的推荐使用的。😈 艿艿团队，管理后台部分，就基于它之上，进行二次封装。
\ No newline at end of file
diff --git a/学习指南/34-Vue 学习指南.md b/学习指南/34-Vue 学习指南.md
new file mode 100644
index 0000000..67e47b7
--- /dev/null
+++ b/学习指南/34-Vue 学习指南.md	
@@ -0,0 +1,61 @@
+# 精尽 Vue 学习指南
+
+Vue 算比较前端的框架，很多时候，我们看看官方文档基本也够。
+
+- [《Vue.js 2.X 官方文档》](https://cn.vuejs.org/v2/guide/index.html)
+
+# 1. 视频
+
+- Vue
+
+  - [《Vue 视频教程全集》](https://www.bilibili.com/video/av59658020/?pikaqiu)
+
+    > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+    >
+    > 一共 75P ，21 小时。
+
+  - 黑马程序员 [《最全的 vue.js 视频》](https://www.bilibili.com/video/av36650577)
+
+    > 一共 204P ，32 小时。
+
+- 【前端】[《Vue 项目实战视频教程全集》](https://www.bilibili.com/video/av59658020/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 82P ，18 小时。
+
+- [mpVue](https://github.com/Meituan-Dianping/mpvue)
+
+  - 使用 Vue 开发微信小程序的解决方案。
+
+  - [《mpVue 视频教程全集》](https://www.bilibili.com/video/av59642709/?pikaqiu)
+
+    > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+    >
+    > 一共 18P，4 小时不到。
+
+- [Weex](https://weex.apache.org/cn/guide/)
+
+  - 使用 Vue 开发 App 的解决方案。
+
+  - GeoffZhu [《weex 入门与实战视频教程》](https://www.bilibili.com/video/av20117163)
+
+    > 一共 12P ，4 小时不到。
+
+  - 技术胖 [《WEEX 入门到实战视频教程》](https://www.bilibili.com/video/av14478917)
+
+    > 一共 17P ，5 小时不到。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 2. 书籍
+
+[《Vue 书单整理》](http://www.iocoder.cn/Books/vue-books-recommended)
+
+自己选择，不过问了下公司的前端，貌似基本没特别去看过 Vue 的书籍，主要看的是官方文档为主。
+
+# 3. 文章
+
+- [《React 和 Vue 到底谁更牛？听听尤雨溪怎么说》](https://www.oschina.net/news/102645/react-vs-vuejs)
+
+  > 听完尤大的分享，可以在反过头思考，为什么国内的开源，和国外的开源会有很大的差别。
\ No newline at end of file
diff --git a/学习指南/35-Angular 学习指南.md b/学习指南/35-Angular 学习指南.md
new file mode 100644
index 0000000..37f0609
--- /dev/null
+++ b/学习指南/35-Angular 学习指南.md	
@@ -0,0 +1,50 @@
+# 精尽 Angular 学习指南
+
+Angular 框架，目前了解到，国内使用的不是很多，知道的案例主要有：
+
+- 1、阿里云
+- 2、开源配置中心 Apollo
+
+所以，个人更加建议胖友学习 React 或者 Vue 。😈 艿艿自己的话，不会 Angular 。
+
+# 1. 视频
+
+- Angular
+
+  - [《Angular 视频教程全集》](https://www.bilibili.com/video/av59652977/?pikaqiu)
+
+    > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+    >
+    > 一共有 18P ，4 小时。
+
+  - IT 营 [《Angular7 教程》](https://www.bilibili.com/video/av38131273)
+
+    > 一共 15P ，7 个多小时。
+
+  - 接灰的电子产品 [《新 angular4.x 框架与 redux 开发大型企业级管理项目》](https://www.bilibili.com/video/av26186412)
+
+    > 一共 61P ，一共 23 个多小时。
+
+  - 千锋教育 [《Angular 入门精讲课程》](https://www.bilibili.com/video/av22934232)
+
+    > 一共 76P ，一共 5 个多小时。
+
+- Ionic
+
+  - 使用 Angular 开发 App 的解决方案。
+
+  - IT 营 [《2018 年 Ionic3.x 视频教程》](https://www.bilibili.com/video/av38572158)
+
+    > 一共 4P ，一共 1 个多小时。
+    >
+    > 感觉可能不是很完整的教程，因为 Ionic 内容应该不少。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 2. 书籍
+
+[《Angular 书单整理》](http://www.iocoder.cn/Books/Angular-books-recommended)
+
+暂时推荐不来书籍，胖友自己选择哈。
+
+# 3. 文章
\ No newline at end of file
diff --git a/学习指南/36-【项目实战】学习指南.md b/学习指南/36-【项目实战】学习指南.md
new file mode 100644
index 0000000..9274524
--- /dev/null
+++ b/学习指南/36-【项目实战】学习指南.md
@@ -0,0 +1,105 @@
+# 精尽【项目实战】学习指南
+
+TODO 未完
+
+# 1. 权限系统
+
+- 【后端】[《RBAC 权限实战视频教程全集》](https://www.bilibili.com/video/av59635802/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 62P ，9 小时。
+
+推荐阅读文章：
+
+- [《芋道 Spring Boot 安全框架 Spring Security 入门》](http://www.iocoder.cn/Spring-Boot/Spring-Security/?vip) 对应 [lab-01-spring-security](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-01-spring-security)
+- [《芋道 Spring Boot 授权框架 Spring Security OAuth2 入门》](http://www.iocoder.cn/Spring-Security/OAuth2-learning/?vip) 对应 [lab-02-spring-security-oauth](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-02-spring-security-oauth) 。
+- [《芋道 Spring Boot 安全框架 Shiro 入门》](http://www.iocoder.cn/Spring-Boot/Shiro/?vip) 对应 [lab-33](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-33) 。
+
+# 2. 电商项目
+
+- 【后端 + 前端】《「一个商城」开源项目》
+
+  > 这个是艿艿最近在做的 B2C 电商开源项目，地址是：
+  >
+  > - https://gitee.com/zhijiantianya/onemall （记得点 star 嘻嘻）
+  >
+  > 有想要参与的同学，欢迎微信私聊，或者知识星球私信。
+  > 灰常渴望大家来参与，一起来愉快的 CRUD 。
+
+- 【后端】[《电商设计手册》](https://github.com/skr-shop/manuals)
+
+  > 只设计不码码。
+
+- 【后端】[《电商项目实战视频教程全集》](https://www.bilibili.com/video/av59641879/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 168P ，50 小时。
+
+- 【前端】[《React 后台项目实战教程全集》](https://www.bilibili.com/video/av59709253/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 76P ，38 小时。
+
+- 【后端】[《从 0 开始独立完成企业级Java电商网站开发（服务端）》](https://coding.imooc.com/class/96.html)
+
+  > 慕课网出的付费教程，自己解决。
+
+# 3. 秒杀项目
+
+- 【后端】[《Java 秒杀系统方案优化 —— 高性能高并发实战》](https://coding.imooc.com/class/168.html)
+
+  > 慕课网出的付费教程，自己解决。
+
+# 4. 外卖项目
+
+- 【前端】[《Vue 项目实战视频教程全集》](https://www.bilibili.com/video/av59658020/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 82P ，18 小时。
+
+# 5. 招聘项目
+
+- 【前端】[《React 前台项目实战视频教程全集》](https://www.bilibili.com/video/av59727745/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 76P ，21 小时。
+
+# 6. 教育项目
+
+- 【后端】
+
+   
+
+  《Python 项目实战视频教程全集》
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 包括 Django 的使用。
+  >
+  > 一共 105P ，26 个多小时。
+  > 注意，这是个基于 Python 的教程。
+
+# 7. 音乐项目
+
+# 8. 微信小程序
+
+- 【前端】[《微信小程序视频教程全集》](https://www.bilibili.com/video/av59679883/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 29P ，7 小时。
+
+# 9. 微信公众号
+
+- 【后端】[《微信公众号视频教程全集》](https://www.bilibili.com/video/av59740522/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 32P ，12 小时。
+  >
+  > 注意，这是个基于 NodeJS 的教程。
\ No newline at end of file
diff --git a/学习指南/37-【大数据】学习指南.md b/学习指南/37-【大数据】学习指南.md
new file mode 100644
index 0000000..18850fe
--- /dev/null
+++ b/学习指南/37-【大数据】学习指南.md
@@ -0,0 +1,80 @@
+# 精尽【大数据】学习指南
+
+因为艿艿本身不是大数据方向的，所以去请教了下胖友，现在大数据领域需要学习哪些技术栈：
+
+- 1. HDFS
+- 1. Yarn
+- 1. Zookeeper
+- 1. HBase
+- 1. Hive
+- 1. Kafka
+- 1. Spark
+- 1. Flink
+
+# 1. Hadoop
+
+- [《Hadoop 视频教程全集》](https://www.bilibili.com/video/av59769574/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 210P ，35 个小时多。
+  >
+  > 包括 HDFS、Yarn 。另外，Hadoop MapReduce 框架，目前已经使用比较少。
+
+# 2. Zookeeper
+
+见 [《精尽 Zookeeper 学习指南》](http://svip.iocoder.cn/Zookeeper/tutorials) 。
+
+# 3. HBase
+
+- [Apache HBase 中文社区](https://yq.aliyun.com/teams/382)
+
+  > 强烈推荐~
+
+- [《HBase 视频教程全集》](https://www.bilibili.com/video/av59738356/?pikaqiu) 一共有 60P 。
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 50P ，11 个小时多。
+
+# 4. Hive
+
+- [《HBase 视频教程全集》](https://www.bilibili.com/video/av59758171/?pikaqiu) 一共有 60P 。
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 102P ，16 个小时多。
+
+# 5. Kafka
+
+见 [《精尽 Kafka 学习指南》](http://svip.iocoder.cn/Kafka/tutorials) 。
+
+# 6. Spark
+
+- [《Spark 视频教程全集》](https://www.bilibili.com/video/av59734386/?pikaqiu) 一共有 60P 。
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 103P ，22 个小时多。
+
+# 7. Flink
+
+- [Apache Flink 中文社区](https://space.bilibili.com/33807709)
+
+  > 强烈推荐~
+
+- [《Flink 视频教程全集》](https://www.bilibili.com/video/av59731122/?pikaqiu) 一共有 9P 。
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 9P ，4 个小时多。
+
+- [《Flink 入门及实战》](https://www.bilibili.com/video/av45168748)
+
+# 8. Flume
+
+- [《Flume 视频教程全集》](https://www.bilibili.com/video/av59739343/?pikaqiu) 一共有 20P 。
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 20 ，3 个小时多。
\ No newline at end of file
diff --git a/学习指南/38-【前端】学习指南.md b/学习指南/38-【前端】学习指南.md
new file mode 100644
index 0000000..e418121
--- /dev/null
+++ b/学习指南/38-【前端】学习指南.md
@@ -0,0 +1,155 @@
+# 精尽【前端】学习指南
+
+一个经典的大姨吗问题，后端是否要学习前端，可以看看知乎的讨论：
+
+- [《后端开发需要学习前端框架吗？》](https://www.zhihu.com/question/315872455)
+- [《现在前后端分离趋势下，后端还要学习前端吗?》](https://www.zhihu.com/question/310064653)
+
+艿艿的想法：
+
+1. 先学好后端，根据工作的需求，去决定是否学习前端。
+2. 前后端分离的是架构，作为一个后端工程师，能够写简单的前端，也是一个必备的技能。
+3. 未来有一天，会不在分前后端工程师，而是**工程师**，即做前端，也做后端，甚至运维。当然，是建立在技术越来越纯属，门槛越来越低。
+
+下面，我们每个小节，会分享一个前端的技术栈的学习。
+
+# 1. HTML
+
+- [《HTML 视频教程全集》](https://svip.iocoder.cn/FrontEnd/tutorials/B 站：https://www.bilibili.com/video/av59657634/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 103P ，29 个小时多。
+
+  - 《HTML5 视频教程全集》
+
+    > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+    >
+    > 本视频分成 A/B 两部分。
+    >
+    > - A 部分（核心技术） P01-P48
+    > - B 部分（实战） P49-P81
+    >
+    > 一共 81P ，31 个小时多。
+
+- [《HTML 项目实战视频教程全集》](https://www.bilibili.com/video/av59646061/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 62P ，24 个小时多。
+
+# 2. CSS
+
+- [《CSS 视频教程全集》](https://www.bilibili.com/video/av59718796/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 本视频分成 A/B 两部分。
+  >
+  > - A 部分（CSS2.1） P01-P27
+  > - B 部分（CSS3） P28-P94
+  >
+  > 一共 94P ，29 个小时多。
+
+- [《Less 视频教程全集》](https://www.bilibili.com/video/av59710179/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 8P ，2 个小时多。
+  >
+  > Less 是一门CSS预处理语言，它扩展了CSS语言，增加了变量、Mixin、函数等特性，使CSS更易维护和扩展。
+
+# 3. Javascript
+
+- [《Javascript 视频教程全集》](https://www.bilibili.com/video/av59715096/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 本视频分成 A/B/C/D 四部分。
+  >
+  > - A 部分（核心技术） P01-P140
+  > - B 部分（高级） P141-P188
+  > - C 部分（ES5、ES6、ES7） P189-P222
+  > - D 部分（JS 模块化） P223-P232
+  >
+  > 一共 232P ，67 个小时多。
+
+# 4. Bootstrap
+
+> 可选。目前使用的越来越少，更多的使用 Ant Design 为主。
+
+- 《Bootstrap 项目实战视频教程全集》
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 10P ，4 个小时多。
+
+# 5. React
+
+见 [《精尽 React 学习指南》](http://svip.iocoder.cn/React/tutorials) 。
+
+# 6. Vue
+
+见 [《精尽 Vue 学习指南》](http://svip.iocoder.cn/Vue/tutorials) 。
+
+# 7. Angular
+
+> 可选。国内目前使用 Angular 相对较少，更多是 React 后者 Vue 为主。
+
+见 [《精尽 Angular 学习指南》](http://svip.iocoder.cn/Angular/tutorials) 。
+
+# 8. Webpack
+
+- [《Webpack 视频教程全集》](https://www.bilibili.com/video/av59678537/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 7P ，1 个小时多。
+
+# 9. Gulp
+
+- [《Gulp 视频教程全集》](https://www.bilibili.com/video/av59709599/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 9P ，1 个小时多。
+
+# 10. NodeJS
+
+- [《NodeJS 视频教程全集》](https://www.bilibili.com/video/av59643654/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 20P ，6 个小时多。
+
+# 233. 面试题
+
+- [《前端面试题视频教程全集》](https://www.bilibili.com/video/av59639585/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 26P ，5 个小时多。
+
+# 666. 淘汰的前端技术
+
+- jQuery [《jQuery 视频教程全集》](https://www.bilibili.com/video/av59641998/?pikaqiu)
+
+  > 被 Zepto 取代。
+  >
+  > 虽然被淘汰，但是还是有胖友想要有 JQuery 的学习视频，所以还是弄了下。
+  >
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 54P ，18 个小时多。
+
+- Zepto
+
+  > 轻量级的 jQuery 的实现类，目前基本不再使用。
+
+- Bootstrap
+
+  > 具体上文已经提及。
+
+- Grunt
+
+  > 目前被 Gulp 取代。
\ No newline at end of file
diff --git a/学习指南/39-Go 学习指南.md b/学习指南/39-Go 学习指南.md
new file mode 100644
index 0000000..4872bf1
--- /dev/null
+++ b/学习指南/39-Go 学习指南.md	
@@ -0,0 +1,38 @@
+# 精尽 Go 学习指南
+
+# 1. 视频
+
+- [《Go 视频教程全集》](https://www.bilibili.com/video/av47775383/?self)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 391P ，118 个多小时。
+
+- 黑马程序员
+
+  - [《20 个小时快速入门 Go 语言（上）》](https://www.bilibili.com/video/av20432910)
+
+  - [《20 个小时快速入门 Go 语言（中）》](https://www.bilibili.com/video/av20434140)
+
+  - [《20 个小时快速入门 Go 语言（下）》](https://www.bilibili.com/video/av20466109)
+
+  - [《Go 语言 Web 开发 Beego 框架深入浅出》](https://www.bilibili.com/video/av33550508)
+
+    > 一共 63P ，14 个小时不到。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 2. 书籍
+
+[《Go 书单整理》](http://www.iocoder.cn/Books/Go-books-recommended)
+
+Go 的书籍，好的还是比较多的，如下是朋友（Go 大佬）推荐的书：
+
+- [《Go 语言学习笔记》](https://union-click.jd.com/jdc?d=gj1Lqm)
+  - 豆瓣评分：8.4 【57 人评价】
+  - 推荐理由：基于Go1.6， 解析语言规范，深入剖析Go运行时源码
+  - 友情提示：雨痕大大，教科书级人物。
+- [《Go 语言编程》](https://union-click.jd.com/jdc?d=xPOncj)
+  - 豆瓣评分：7.1 【444 人评价】
+  - 推荐理由：这本书从整体的写作风格来说，会以介绍 Go 语言特性为主，示例则尽量采用作者平常的实践，而不是一个没有太大实际意义的语法示范样例。
+  - 友情提示：本书作者背景极强，许式伟为原金山WPS首席架构师、曾是盛大创新院研究员，目前是国内Go语言实践圈子公认的Go语言专家。
\ No newline at end of file
diff --git a/学习指南/40-Python 学习指南.md b/学习指南/40-Python 学习指南.md
new file mode 100644
index 0000000..4d2f217
--- /dev/null
+++ b/学习指南/40-Python 学习指南.md	
@@ -0,0 +1,41 @@
+# 精尽 Python 学习指南
+
+# 1. 视频
+
+- [《Python 视频教程全集》](https://www.bilibili.com/video/av59768359/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 76P ，19 个多小时。
+
+- [《Python 项目实战视频教程全集》](https://www.bilibili.com/video/av59740677?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 包括 Django 的使用。
+  >
+  > 一共 105P ，26 个多小时。
+
+- [《Python 爬虫视频教程全集》](https://www.bilibili.com/video/av59706997/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 62P ，6 个多小时。
+
+- [《Python 人工智能视频教程全集》](https://www.bilibili.com/video/av59777194/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 23P ，7 个多小时。
+  >
+  > 这个只是简单的入门，不是很建议看~后续艿艿在整理和人工智能相关的资料。
+
+- [《人工智能 Tensorflow 视频教程全集》](https://www.bilibili.com/video/av59746352/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 29P ，5 个多小时。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 2. 书籍
\ No newline at end of file
diff --git a/学习指南/41-MongoDB 学习指南.md b/学习指南/41-MongoDB 学习指南.md
new file mode 100644
index 0000000..1ee5f50
--- /dev/null
+++ b/学习指南/41-MongoDB 学习指南.md	
@@ -0,0 +1,48 @@
+# 精尽 MongoDB 学习指南
+
+目前 MongoDB 已经更新到 4.X 的版本，市面上的资料可能有些滞后，但是问题不大，有差异的地方，当然是 [官网文档](https://docs.mongodb.com/) 走起。
+
+另外，在 [MongoDB 中文社区](http://www.mongoing.com/) 也提供了非常多靠谱的资料。
+
+# 1. 视频
+
+- [《MongoDB 视频教程全集》](https://www.bilibili.com/video/av59604756/?pikaqiu)
+
+  > **推荐~记得 b 站【收藏 + 点赞 + 投币】素质三连噢**。
+  >
+  > 一共 18P ，6 个多小时不到。
+
+- 小马技术 [《MongoDB 从入门到学会》](https://www.bilibili.com/video/av24311263)
+
+  > 一共 15P ，也是简单入门 MongoDB 。
+
+- Stannum [《MongoDB4.0 新特性》](https://www.imooc.com/learn/1026)
+
+  > 一共 1 小时多，分享事务、订阅等特性。
+
+- Jeson老师 [《MongoDB 集群之分片技术应用》](https://www.imooc.com/learn/501)
+
+  > 一共 2 小时不到，MongoDB 分片，可以了解下，实际生产很多公司未必用的到。
+
+- MongoDB 中文社区 [《MongoDB 大会视频》](https://www.imooc.com/u/1200677/courses?sort=publish)
+
+  > MongoDB 中文社区的各种大会的视频，可以选择性看看。
+
+- DevOpen.Club [《MongoDB 数据库入门与进阶》](https://www.bilibili.com/video/av13384870)
+
+  > 一共 20P ，简单入门 MongoDB 。
+
+上述的视频，是艿艿翻了下目前大家看的比较多的视频，利益无关哈。
+
+# 2. 书籍
+
+[《Mongodb 书单整理》](http://www.iocoder.cn/Books/MongoDB-books-recommended/)
+
+[《MongoDB 权威指南》](https://u.jd.com/ANlvN1) 和 [《MongoDB 实战》](https://u.jd.com/EO1oxl) 两本书都不错，艿艿都看了，后对来说推荐后者一些，更精简和实战。当然，前者也是不错的。
+
+# 3. 文章
+
+- 芋艿 [《芋道 Spring Boot MongoDB 入门》](http://www.iocoder.cn/Spring-Boot/MongoDB/?vip) 对应 [lab-16-spring-data-mongo](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-16-spring-data-mongo)
+- 芋艿 [《性能测试 —— MongoDB 基准测试》](http://www.iocoder.cn/Performance-Testing/MongoDB-benchmark/?vip)
+- 芋艿 [《MongoDB 安装部署》](http://www.iocoder.cn/MongoDB/install/?vip)
+- TJ [《MongoDB 最佳实践 – 持续更新版》](http://www.mongoing.com/archives/3895)
\ No newline at end of file
diff --git a/学习指南/file-create.py b/学习指南/file-create.py
new file mode 100644
index 0000000..a412975
--- /dev/null
+++ b/学习指南/file-create.py
@@ -0,0 +1,27 @@
+import os
+import pyperclip
+
+# 获取当前脚本的路径
+script_dir = os.path.dirname(os.path.abspath(__file__))
+
+# 从剪贴板获取文件名列表，假设每行一个文件名
+file_names = pyperclip.paste().strip().split('\n')
+
+# 遍历文件名列表，为每个文件名添加排序前缀并创建文件
+for index, file_name in enumerate(file_names, start=1):
+    # 去除文件名两端的空白字符
+    file_name = file_name.strip()
+    
+    # 添加排序前缀和.md后缀
+    file_name_with_prefix = f"{index:02d}-{file_name}.md"  # 这里使用3位数的排序前缀，可以根据需要调整
+    
+    # 构建文件的完整路径
+    file_path = os.path.join(script_dir, file_name_with_prefix)
+    
+    # 创建文件
+    with open(file_path, 'w') as file:
+        # 如果需要写入初始内容，可以在这里添加
+        # 例如：file.write("This is the content of the file.")
+        pass  # 如果不需要写入内容，则使用pass
+
+print(f"Files created successfully in {script_dir}")
\ No newline at end of file
diff --git a/学习指南/tmp.txt b/学习指南/tmp.txt
new file mode 100644
index 0000000..8099a85
--- /dev/null
+++ b/学习指南/tmp.txt
@@ -0,0 +1,41 @@
+学习指南
+Netty 学习指南
+Dubbo 学习指南
+Spring 学习指南
+Spring MVC 学习指南
+Spring Boot 学习指南
+Spring Cloud 学习指南
+MyBatis 学习指南
+Hibernate 学习指南
+RocketMQ 学习指南
+RabbitMQ 学习指南
+Shiro 学习指南
+Kafka 学习指南
+Redis 学习指南
+MySQL 学习指南
+Elasticsearch 学习指南
+设计模式学习指南
+数据结构与算法学习指南
+计算机网络学习指南
+Linux 学习指南
+Git 学习指南
+Maven 学习指南
+Jenkins 学习指南
+IntelliJ IDEA 学习指南
+Java【基础】学习指南
+Java【并发】学习指南
+Java【虚拟机】学习指南
+Zookeeper 学习指南
+Nginx 学习指南
+任务调度学习指南
+Docker 学习指南
+Kubernetes 学习指南
+React 学习指南
+Vue 学习指南
+Angular 学习指南
+【项目实战】学习指南
+【大数据】学习指南
+【前端】学习指南
+Go 学习指南
+Python 学习指南
+MongoDB 学习指南
\ No newline at end of file
diff --git a/文档/springboot.md b/文档/springboot.md
new file mode 100644
index 0000000..e69de29
diff --git a/面试题/01-Netty 面试题.assets/01.png b/面试题/01-Netty 面试题.assets/01.png
new file mode 100644
index 0000000..2dbf0ca
Binary files /dev/null and b/面试题/01-Netty 面试题.assets/01.png differ
diff --git a/面试题/01-Netty 面试题.assets/02.png b/面试题/01-Netty 面试题.assets/02.png
new file mode 100644
index 0000000..7635d92
Binary files /dev/null and b/面试题/01-Netty 面试题.assets/02.png differ
diff --git a/面试题/01-Netty 面试题.assets/03.png b/面试题/01-Netty 面试题.assets/03.png
new file mode 100644
index 0000000..bcba6e1
Binary files /dev/null and b/面试题/01-Netty 面试题.assets/03.png differ
diff --git a/面试题/01-Netty 面试题.assets/85d98e3cb0e6e39f80d02234e039a4dd.jpeg b/面试题/01-Netty 面试题.assets/85d98e3cb0e6e39f80d02234e039a4dd.jpeg
new file mode 100644
index 0000000..f6f0a4e
Binary files /dev/null and b/面试题/01-Netty 面试题.assets/85d98e3cb0e6e39f80d02234e039a4dd.jpeg differ
diff --git a/面试题/01-Netty 面试题.md b/面试题/01-Netty 面试题.md
new file mode 100644
index 0000000..301410c
--- /dev/null
+++ b/面试题/01-Netty 面试题.md	
@@ -0,0 +1,731 @@
+# 精尽 Netty 面试题「最新更新时间：2024-02」
+
+以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。
+
+如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的 Netty 面试题的大保健。
+
+而题目的难度，艿艿尽量按照从容易到困难的顺序，逐步下去。
+
+## BIO 是什么？
+
+🦅 **概念**
+
+- BIO ，全称 Block-IO ，是一种**阻塞** + **同步**的通信模式。
+- 是一个比较传统的通信方式，模式简单，使用方便。但并发处理能力低，通信耗时，依赖网速。
+
+🦅 **原理**
+
+- 服务器通过一个 Acceptor 线程，负责监听客户端请求和为每个客户端创建一个新的线程进行链路处理。典型的**一请求一应答模式**。
+- 若客户端数量增多，频繁地创建和销毁线程会给服务器打开很大的压力。后改良为用线程池的方式代替新增线程，被称为伪异步 IO 。
+
+🦅 **示例**
+
+- 代码参见 [bio](https://github.com/ITDragonBlog/daydayup/tree/master/Netty/socket-io/src/com/itdragon/bio) 。
+
+🦅 **小结**
+
+BIO 模型中，通过 Socket 和 ServerSocket 实现套接字通道的通信。阻塞，同步，建立连接耗时。
+
+## NIO 是什么？
+
+🦅 **概念**
+
+- NIO ，全称 New IO ，也叫 Non-Block IO ，是一种**非阻塞** + 同步的通信模式。
+- [《精尽 Netty 源码分析 —— NIO 基础（一）之简介》](http://svip.iocoder.cn/Netty/nio-1-intro/)
+
+🦅 **原理**
+
+- NIO 相对于 BIO 来说一大进步。客户端和服务器之间通过 Channel 通信。NIO 可以在 Channel 进行读写操作。这些 Channel 都会被注册在 Selector 多路复用器上。Selector 通过一个线程不停的轮询这些 Channel 。找出已经准备就绪的 Channel 执行 IO 操作。
+- NIO 通过一个线程轮询，实现千万个客户端的请求，这就是非阻塞 NIO 的特点。
+  - 缓冲区 Buffer ：它是 NIO 与 BIO 的一个重要区别。
+    - BIO 是将数据直接写入或读取到流 Stream 对象中。
+    - NIO 的数据操作都是在 Buffer 中进行的。Buffer 实际上是一个数组。Buffer 最常见的类型是ByteBuffer，另外还有 CharBuffer，ShortBuffer，IntBuffer，LongBuffer，FloatBuffer，DoubleBuffer。
+    - [《精尽 Netty 源码分析 —— NIO 基础（三）之 Buffer》](http://svip.iocoder.cn/Netty/nio-3-buffer/)
+  - 通道 Channel ：和流 Stream 不同，通道是双向的。NIO可以通过 Channel 进行数据的读、写和同时读写操作。
+    - 通道分为两大类：一类是网络读写（SelectableChannel），一类是用于文件操作（FileChannel）。我们使用的是前者 SocketChannel 和 ServerSocketChannel ，都是SelectableChannel 的子类。
+    - [《精尽 Netty 源码分析 —— NIO 基础（二）之 Channel》](http://svip.iocoder.cn/Netty/nio-2-channel/)
+  - 多路复用器 Selector ：NIO 编程的基础。多路复用器提供选择已经就绪的任务的能力：就是 Selector 会不断地轮询注册在其上的通道（Channel），如果某个通道处于就绪状态，会被 Selector 轮询出来，然后通过 SelectionKey 可以取得就绪的Channel集合，从而进行后续的 IO 操作。
+    - 服务器端只要提供一个线程负责 Selector 的轮询，就可以接入成千上万个客户端，这就是 JDK NIO 库的巨大进步。
+    - [《精尽 Netty 源码分析 —— NIO 基础（四）之 Selector》](http://svip.iocoder.cn/Netty/nio-4-selector/)
+
+🦅 **示例**
+
+- 代码参见 [nio](https://github.com/ITDragonBlog/daydayup/tree/master/Netty/socket-io/src/com/itdragon/nio)
+- [《精尽 Netty 源码分析 —— NIO 基础（五）之示例》](http://svip.iocoder.cn/Netty/nio-5-demo/)
+
+🦅 **小结**
+
+NIO 模型中通过 SocketChannel 和 ServerSocketChannel 实现套接字通道的通信。非阻塞，同步，避免为每个 TCP 连接创建一个线程。
+
+🦅 **继续挖掘**
+
+可能有胖友对非阻塞和阻塞，同步和异步的定义有点懵逼，我们再来看下 [《精尽 Netty 源码分析 —— NIO 基础（一）之简介》](http://svip.iocoder.cn/Netty/nio-1-intro/) 提到的一段话：
+
+> 老艿艿：在一些文章中，会将 Java NIO 描述成**异步** IO ，实际是不太正确的： Java NIO 是**同步** IO ，Java AIO ( 也称为 NIO 2 )是**异步** IO。具体原因，推荐阅读文章：
+>
+> - [《异步和非阻塞一样吗? (内容涉及 BIO, NIO, AIO, Netty)》](https://blog.csdn.net/matthew_zhang/article/details/71328697) 。
+> - [《BIO与NIO、AIO的区别(这个容易理解)》](https://blog.csdn.net/skiof007/article/details/52873421)
+>
+> 总结来说，在 **Unix IO 模型**的语境下：
+>
+> - 同步和异步的区别：数据拷贝阶段是否需要完全由操作系统处理。
+> - 阻塞和非阻塞操作：是针对发起 IO 请求操作后，是否有立刻返回一个标志信息而不让请求线程等待。
+>
+> 因此，Java NIO 是**同步**且非阻塞的 IO 。
+
+- 另外，胖友在瞅瞅下面这个图来理解下：[![Unix 的 5 种 IO 模型](http://static.iocoder.cn/images/Netty/2017_10_24/01.png)](http://static.iocoder.cn/images/Netty/2017_10_24/01.png)Unix 的 5 种 IO 模型
+
+## AIO 是什么？
+
+> 艿艿：这个面试题，重点在于陈述我们对 BIO、NIO 的理解，对于 AIO 来说，基本理解即可。
+
+🦅 **概念**
+
+- AIO ，全称 Asynchronous IO ，也叫 NIO**2** ，是一种**非阻塞** + **异步**的通信模式。在 NIO 的基础上，引入了新的异步通道的概念，并提供了异步文件通道和异步套接字通道的实现。
+- 原理：
+- AIO 并没有采用 NIO 的多路复用器，而是使用异步通道的概念。其 read，write 方法的返回类型，都是 Future 对象。而 Future 模型是异步的，其核心思想是：**去主函数等待时间**。
+
+🦅 **示例**
+
+- 代码参见 [aio](https://github.com/ITDragonBlog/daydayup/tree/master/Netty/socket-io/src/com/itdragon/aio)
+
+🦅 **小结**
+
+AIO 模型中通过 AsynchronousSocketChannel 和 AsynchronousServerSocketChannel 实现套接字通道的通信。非阻塞，异步。
+
+## BIO、NIO 有什么区别？
+
+- 线程模型不同
+  - BIO：一个连接一个线程，客户端有连接请求时服务器端就需要启动一个线程进行处理。所以，线程开销大。可改良为用线程池的方式代替新创建线程，被称为伪异步 IO 。
+  - NIO：一个请求一个线程，但客户端发送的连接请求都会注册到多路复用器上，多路复用器轮询到连接有新的 I/O 请求时，才启动一个线程进行处理。可改良为一个线程处理多个请求，基于 [多 Reactor 模型](http://svip.iocoder.cn/Netty/EventLoop-1-Reactor-Model/)。
+- BIO 是面向流( Stream )的，而 NIO 是面向缓冲区( Buffer )的。
+- BIO 的各种操作是阻塞的，而 NIO 的各种操作是非阻塞的。
+- BIO 的 Socket 是单向的，而 NIO 的 Channel 是双向的。
+
+可能文字比较难记，整理出来就是下图：[![BIO 对比 NIO 对比 AIO](01-Netty 面试题.assets/02.png)](http://static.iocoder.cn/images/Netty/2017_10_24/02.png)BIO 对比 NIO 对比 AIO
+
+- 有一点要注意，虽然图中说 NIO 的性能一般，但是在绝大多数我们日常业务场景，NIO 和 AIO 的性能差距实际没这么大。在 Netty5 中，基于 AIO 改造和支持，最后发现，性能并没有想象中这么强悍，所以 Netty5 被废弃，而是继续保持 Netty4 为主版本，使用 NIO 为主。
+
+为了胖友能更好的记住和理解 BIO、NIO、AIO 的流程，胖友可以在理解下图：[![BIO、NIO、AIO 的流程图](http://static.iocoder.cn/images/Netty/2017_10_24/03.png)](http://static.iocoder.cn/images/Netty/2017_10_24/03.png)BIO、NIO、AIO 的流程图
+
+## 什么是 Netty ？
+
+> Netty 是一款提供异步的、事件驱动的网络应用程序框架和工具，用以快速开发高性能、高可靠性的网络服务器和客户端程序。
+>
+> 也就是说，Netty 是一个基于 NIO 的客户、服务器端编程框架。使用 Netty 可以确保你快速和简单地开发出一个网络应用，例如实现了某种协议的客户，服务端应用。Netty 相当简化和流线化了网络应用的编程开发过程，例如，TCP 和 UDP 的 socket 服务开发。
+>
+> （以上摘自百度百科）。
+
+Netty 具有如下特性( 摘自《Netty in Action》 )
+
+| 分类     | Netty的特性                                                  |
+| :------- | :----------------------------------------------------------- |
+| 设计     | 1. 统一的 API ，支持多种传输类型( 阻塞和非阻塞的 ) 2. 简单而强大的线程模型 3. 真正的无连接数据报套接字( UDP )支持 4. 连接逻辑组件( ChannelHander 中顺序处理消息 )以及组件复用( 一个 ChannelHandel 可以被多个ChannelPipeLine 复用 ) |
+| 易于使用 | 1. 详实的 Javadoc 和大量的示例集 2. 不需要超过 JDK 1.6+ 的依赖 |
+| 性能     | 拥有比 Java 的核心 API 更高的吞吐量以及更低的延迟( 得益于池化和复用 )，更低的资源消耗以及最少的内存复制 |
+| 健壮性   | 1. 不会因为慢速、快速或者超载的连接而导致 OutOfMemoryError 2. 消除在高速网络中 NIO 应用程序常见的不公平读 / 写比率 |
+| 安全性   | 完整的 SSL/TLS 以及 StartTLs 支持，可用于受限环境下，如 Applet 和 OSGI |
+| 社区驱动 | 发布快速而且频繁                                             |
+
+## 为什么选择 Netty ？
+
+- **使用简单**：API 使用简单，开发门槛低。
+- **功能强大**：预置了多种编解码功能，支持多种主流协议。
+- **定制能力强**：可以通过 ChannelHandler 对通信框架进行灵活的扩展。
+- **性能高**：通过与其它业界主流的 NIO 框架对比，Netty 的综合性能最优。
+- **成熟稳定**：Netty 修复了已经发现的所有 JDK NIO BUG，业务开发人员不需要再为 NIO 的 BUG 而烦恼。
+- **社区活跃**：版本迭代周期短，发现的BUG可以被及时修复，同时，更多的新功能会被加入。
+- **案例丰富**：经历了大规模的商业应用考验，质量已经得到验证。在互联网、大数据、网络游戏、企业应用、电信软件等众多行业得到成功商用，证明了它可以完全满足不同行业的商业应用。
+
+实际上，这个也是我们做技术选型的一些参考点，不仅仅适用于 Netty ，也同样适用于其他技术栈。当然，😈 面试都可以酱紫回答，显得很高端。
+
+## 为什么说 Netty 使用简单？
+
+🦅 我们假设要搭建一个 Server 服务器，使用 **Java NIO 的步骤**如下：
+
+1. 创建 ServerSocketChannel 。
+
+   - 绑定监听端口，并配置为非阻塞模式。
+
+2. 创建 Selector，将之前创建的 ServerSocketChannel 注册到 Selector 上，监听
+
+    
+
+   ```
+   SelectionKey.OP_ACCEPT
+   ```
+
+    
+
+   。
+
+   - 循环执行 `Selector#select()` 方法，轮询就绪的 Channel。
+
+3. 轮询就绪的 Channel 时，如果是处于
+
+    
+
+   ```
+   OP_ACCEPT
+   ```
+
+    
+
+   状态，说明是新的客户端接入，调用
+
+    
+
+   ```
+   ServerSocketChannel#accept()
+   ```
+
+    
+
+   方法，接收新的客户端。
+
+   - 设置新接入的 SocketChannel 为非阻塞模式，并注册到 Selector 上，监听 `OP_READ` 。
+
+4. 如果轮询的 Channel 状态是
+
+    
+
+   ```
+   OP_READ
+   ```
+
+    
+
+   ，说明有新的就绪数据包需要读取，则构造 ByteBuffer 对象，读取数据。
+
+   - 这里，解码数据包的过程，需要我们自己编写。
+
+> 艿艿：注意噢，上述步骤还是最简的 Java NIO 启动步骤，不包括**多 Reactor 多线程模型**噢！可能有胖友不知道什么是 Reactor 模型，在 [「什么是 Reactor 模型？」](https://svip.iocoder.cn/Netty/Interview/#) 问题中，我们会详细解释。
+
+🦅 使用 **Netty 的步骤**如下：
+
+1. 创建 NIO 线程组 EventLoopGroup 和 ServerBootstrap。
+   - 设置 ServerBootstrap 的属性：线程组、SO_BACKLOG 选项，设置 NioServerSocketChannel 为 Channel
+   - 设置业务处理 Handler 和 编解码器 Codec 。
+   - 绑定端口，启动服务器程序。
+2. 在业务处理 Handler 中，处理客户端发送的数据，并给出响应。
+
+🦅 那么相比 Java NIO，使用 Netty 开发程序，都**简化了哪些步骤**呢？
+
+1. 无需关心 `OP_ACCEPT`、`OP_READ`、`OP_WRITE` 等等 **IO 操作**，Netty 已经封装，对我们在使用是透明无感的。
+2. 使用 boss 和 worker EventLoopGroup ，Netty 直接提供**多 Reactor 多线程模型**。
+3. 在 Netty 中，我们看到有使用一个解码器 FixedLengthFrameDecoder，可以用于处理定长消息的问题，能够解决 **TCP 粘包拆包**问题，十分方便。如果使用 Java NIO ，需要我们自行实现解码器。
+
+------
+
+😈 如果胖友不知道如何使用 Java NIO 编写一个 Server ，建议自己去实现以下。
+😈 如果胖友没有使用过 Netty 编写一个 Server ，建议去入门下。
+
+## 说说业务中 Netty 的使用场景？
+
+- 构建高性能、低时延的各种 Java 中间件，Netty 主要作为基础通信框架提供高性能、低时延的通信服务。例如：
+  - RocketMQ ，分布式消息队列。
+  - Dubbo ，服务调用框架。
+  - Spring WebFlux ，基于响应式的 Web 框架。
+  - HDFS ，分布式文件系统。
+- 公有或者私有协议栈的基础通信框架，例如可以基于 Netty 构建异步、高性能的 WebSocket、Protobuf 等协议的支持。
+- 各领域应用，例如大数据、游戏等，Netty 作为高性能的通信框架用于内部各模块的数据分发、传输和汇总等，实现模块之间高性能通信。
+
+## 说说 Netty 如何实现高性能？
+
+1. **线程模型** ：更加优雅的 Reactor 模式实现、灵活的线程模型、利用 EventLoop 等创新性的机制，可以非常高效地管理成百上千的 Channel 。
+
+2. **内存池设计** ：使用池化的 Direct Buffer 等技术，在提高 IO 性能的同时，减少了对象的创建和销毁。并且，内吃吃的内部实现是用一颗二叉查找树，更好的管理内存分配情况。
+
+3. **内存零拷贝** ：使用 Direct Buffer ，可以使用 Zero-Copy 机制。
+
+   > Zero-Copy ，在操作数据时，不需要将数据 Buffer 从一个内存区域拷贝到另一个内存区域。因为少了一次内存的拷贝，因此 CPU 的效率就得到的提升。
+
+4. **协议支持** ：提供对 Protobuf 等高性能序列化协议支持。
+
+5. 使用更多本地代码
+
+   。例如：
+
+   - 直接利用 JNI 调用 Open SSL 等方式，获得比 Java 内建 SSL 引擎更好的性能。
+   - 利用 JNI 提供了 Native Socket Transport ，在使用 Epoll edge-triggered 的情况下，可以有一定的性能提升。
+
+6. 其它：
+
+   - 利用反射等技术直接操纵 SelectionKey ，使用数组而不是 Java 容器等。
+   - 实现 [FastThreadLocal](https://segmentfault.com/a/1190000012926809) 类，当请求频繁时，带来更好的性能。
+   - ….
+
+另外，推荐阅读白衣大大的两篇文章：
+
+1. [《Netty高性能编程备忘录(上)》](http://calvin1978.blogcn.com/articles/netty-performance.html)
+2. [《Netty高性能编程备忘录（下）》](http://calvin1978.blogcn.com/articles/netty-performance2.html)
+
+> 下面三连问！
+>
+> Netty 是一个高性能的、高可靠的、可扩展的异步通信框架，那么高性能、高可靠、可扩展设计体现在哪里呢？
+
+## Netty 的高性能如何体现？
+
+> 这个问题，和 [「说说 Netty 如何实现高性能？」](https://svip.iocoder.cn/Netty/Interview/#) 问题，会有点重叠。没事，反正理解就好，也背不下来。哈哈哈哈。
+
+性能是设计出来的，而不是测试出来的。那么，Netty 的架构设计是如何实现高性能的呢？
+
+1. **线程模型** ：采用异步非阻塞的 I/O 类库，基于 Reactor 模式实现，解决了传统同步阻塞 I/O 模式下服务端无法平滑处理客户端线性增长的问题。
+
+2. **堆外内存** ：TCP 接收和发送缓冲区采用直接内存代替堆内存，避免了内存复制，提升了 I/O 读取和写入性能。
+
+3. **内存池设计** ：支持通过内存池的方式循环利用 ByteBuf，避免了频繁创建和销毁 ByteBuf 带来的性能消耗。
+
+4. **参数配置** ：可配置的 I/O 线程数目和 TCP 参数等，为不同用户提供定制化的调优参数，满足不同的性能场景。
+
+5. **队列优化** ：采用环形数组缓冲区，实现无锁化并发编程，代替传统的线程安全容器或锁。
+
+6. **并发能力** ：合理使用线程安全容器、原子类等，提升系统的并发能力。
+
+7. **降低锁竞争** ：关键资源的使用采用单线程串行化的方式，避免多线程并发访问带来的锁竞争和额外的 CPU 资源消耗问题。
+
+8. 内存泄露检测
+
+    
+
+   ：通过引用计数器及时地释放不再被引用的对象，细粒度的内存管理降低了 GC 的频率，减少频繁 GC 带来的时延增大和 CPU 损耗。
+
+   - [《精尽 Netty 源码解析 —— Buffer 之 ByteBuf（三）内存泄露检测》](http://svip.iocoder.cn/Netty/ByteBuf-1-3-ByteBuf-resource-leak-detector/)
+
+## Netty 的高可靠如何体现？
+
+1. 链路有效性检测
+
+   ：由于长连接不需要每次发送消息都创建链路，也不需要在消息完成交互时关闭链路，因此相对于短连接性能更高。为了保证长连接的链路有效性，往往需要通过心跳机制周期性地进行链路检测。使用心跳机制的原因是，避免在系统空闲时因网络闪断而断开连接，之后又遇到海量业务冲击导致消息积压无法处理。为了解决这个问题，需要周期性地对链路进行有效性检测，一旦发现问题，可以及时关闭链路，重建 TCP 连接。为了支持心跳，Netty 提供了两种链路空闲检测机制：
+
+   - 读空闲超时机制：连续 T 周期没有消息可读时，发送心跳消息，进行链路检测。如果连续 N 个周期没有读取到心跳消息，可以主动关闭链路，重建连接。
+   - 写空闲超时机制：连续 T 周期没有消息需要发送时，发送心跳消息，进行链路检测。如果连续 N 个周期没有读取对方发回的心跳消息，可以主动关闭链路，重建连接。
+   - [《精尽 Netty 源码解析 —— ChannelHandler（五）之 IdleStateHandler》](http://svip.iocoder.cn/Netty/ChannelHandler-5-idle/)
+
+2. 内存保护机制
+
+   ：Netty 提供多种机制对内存进行保护，包括以下几个方面：
+
+   - 通过对象引用计数器对 ByteBuf 进行细粒度的内存申请和释放，对非法的对象引用进行检测和保护。
+   - 可设置的内存容量上限，包括 ByteBuf、线程池线程数等，避免异常请求耗光内存。
+
+3. 优雅停机
+
+   ：优雅停机功能指的是当系统推出时，JVM 通过注册的 Shutdown Hook 拦截到退出信号量，然后执行推出操作，释放相关模块的资源占用，将缓冲区的消息处理完成或清空，将待刷新的数据持久化到磁盘和数据库中，等到资源回收和缓冲区消息处理完成之后，再退出。
+
+   - [《精尽 Netty 源码解析 —— EventLoop（八）之 EventLoop 优雅关闭》](http://svip.iocoder.cn/Netty/EventLoop-8-EventLoop-shutdown/)
+
+## Netty 的可扩展如何体现？
+
+可定制、易扩展。
+
+- **责任链模式** ：ChannelPipeline 基于责任链模式开发，便于业务逻辑的拦截、定制和扩展。
+- **基于接口的开发** ：关键的类库都提供了接口或抽象类，便于用户自定义实现。
+- **提供大量的工厂类** ：通过重载这些工厂类，可以按需创建出用户需要的对象。
+- **提供大量系统参数** ：供用户按需设置，增强系统的场景定制性。
+
+------
+
+> 艿艿：说个题外话。
+>
+> 实际上，任何的技术的研究，我们都可以去思考，它的高性能是怎么体现的，它的可靠性是怎么体现的，它的可拓展是怎么体现的。
+>
+> 当然，因为很多时候有近义词，所以：
+>
+> - 高性能 => 高并发
+> - 可靠性 => 高可用
+> - 可拓展 => 高拓展
+>
+> 例如说，MySQL 如何实现高性能，MySQL 如何搭建高可用，😈 MySQL 如何做拓展貌似暂时没，哈哈哈哈。
+
+## 简单介绍 Netty 的核心组件？
+
+Netty 有如下六个核心组件：
+
+- Bootstrap & ServerBootstrap
+- Channel
+- ChannelFuture
+- EventLoop & EventLoopGroup
+- ChannelHandler
+- ChannelPipeline
+
+详细的，请直接阅读 [《精尽 Netty 源码分析 —— Netty 简介（二）之核心组件》](http://svip.iocoder.cn/Netty/intro-2/) 一文。
+
+## 说说 Netty 的逻辑架构？
+
+Netty 采用了典型的**三层网络架构**进行设计和开发，其逻辑架构如下图所示：
+
+[![Netty 逻辑架构图](http://static.iocoder.cn/85d98e3cb0e6e39f80d02234e039a4dd)](http://static.iocoder.cn/85d98e3cb0e6e39f80d02234e039a4dd)Netty 逻辑架构图
+
+> 艿艿：注意，这个图是自下向上看。哈哈哈~
+
+1. **Reactor 通信调度层**：由一系列辅助类组成，包括 Reactor 线程 NioEventLoop 及其父类，NioSocketChannel 和 NioServerSocketChannel 等等。该层的职责就是监听网络的读写和连接操作，负责将网络层的数据读到内存缓冲区，然后触发各自网络事件，例如连接创建、连接激活、读事件、写事件等。将这些事件触发到 pipeline 中，由 pipeline 管理的职责链来进行后续的处理。
+2. **职责链 ChannelPipeline**：负责事件在职责链中的有序传播，以及负责动态地编排职责链。职责链可以选择监听和处理自己关心的事件，拦截处理和向后传播事件。
+3. **业务逻辑编排层**：业务逻辑编排层通常有两类，一类是纯粹的业务逻辑编排，一类是应用层协议插件，用于特定协议相关的会话和链路管理。由于应用层协议栈往往是开发一次到处运行，并且变动较小，故而将应用协议到 POJO 的转变和上层业务放到不同的 ChannelHandler 中，就可以实现协议层和业务逻辑层的隔离，实现架构层面的分层隔离。
+
+## 什么是 Reactor 模型？
+
+直接阅读 [《精尽 Netty 源码解析 —— EventLoop（一）之 Reactor 模型》](http://svip.iocoder.cn/Netty/EventLoop-1-Reactor-Model/) 一文。
+
+认真仔细读，这是一个高频面试题。
+
+## 请介绍 Netty 的线程模型？
+
+还是阅读 [《精尽 Netty 源码解析 —— EventLoop（一）之 Reactor 模型》](http://svip.iocoder.cn/Netty/EventLoop-1-Reactor-Model/) 一文。
+
+认真仔细读，这真的真的真的是一个高频面试题。
+
+## 什么是业务线程池？
+
+🦅 **问题**
+
+在 [「什么是 Reactor 模型？」](https://svip.iocoder.cn/Netty/Interview/#) 问题中，无论是那种类型的 Reactor 模型，都需要在 Reactor 所在的线程中，进行读写操作。那么此时就会有一个问题，如果我们读取到数据，需要进行业务逻辑处理，并且这个业务逻辑需要对数据库、缓存等等进行操作，会有什么问题呢？假设这个数据库操作需要 5 ms ，那就意味着这个 Reactor 线程在这 5 ms 无法进行注册在这个 Reactor 的 Channel 进行读写操作。也就是说，多个 Channel 的所有读写操作都变成了串行。势必，这样的效率会非常非常非常的低。
+
+🦅 **解决**
+
+那么怎么解决呢？创建业务线程池，将读取到的数据，提交到业务线程池中进行处理。这样，Reactor 的 Channel 就不会被阻塞，而 Channel 的所有读写操作都变成了并行了。
+
+🦅 **案例**
+
+如果胖友熟悉 Dubbo 框架，就会发现 [《Dubbo 用户指南 —— 线程模型》](http://dubbo.apache.org/zh-cn/docs/user/demos/thread-model.html) 。😈 认真读下，可以跟面试官吹一吹啦。
+
+## TCP 粘包 / 拆包的原因？应该这么解决？
+
+🦅 **概念**
+
+TCP 是以流的方式来处理数据，所以会导致粘包 / 拆包。
+
+- 拆包：一个完整的包可能会被 TCP 拆分成多个包进行发送。
+- 粘包：也可能把小的封装成一个大的数据包发送。
+
+🦅 **原因**
+
+- 应用程序写入的字节大小大于套接字发送缓冲区的大小，会发生**拆包**现象。而应用程序写入数据小于套接字缓冲区大小，网卡将应用多次写入的数据发送到网络上，这将会发生**粘包**现象。
+- 待发送数据大于 MSS（最大报文长度），TCP 在传输前将进行**拆包**。
+- 以太网帧的 payload（净荷）大于 MTU（默认为 1500 字节）进行 IP 分片**拆包**。
+- 接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生**粘包**。
+
+🦅 **解决**
+
+在 Netty 中，提供了多个 Decoder 解析类，如下：
+
+- ① FixedLengthFrameDecoder ，基于**固定长度**消息进行粘包拆包处理的。
+- ② LengthFieldBasedFrameDecoder ，基于**消息头指定消息长度**进行粘包拆包处理的。
+- ③ LineBasedFrameDecoder ，基于**换行**来进行消息粘包拆包处理的。
+- ④ DelimiterBasedFrameDecoder ，基于**指定消息边界方式**进行粘包拆包处理的。
+
+实际上，上述四个 FrameDecoder 实现可以进行规整：
+
+- ① 是 ② 的特例，**固定长度**是**消息头指定消息长度**的一种形式。
+- ③ 是 ④ 的特例，**换行**是于**指定消息边界方式**的一种形式。
+
+感兴趣的胖友，可以看看如下两篇文章：
+
+- [《精尽 Netty 源码解析 —— Codec 之 ByteToMessageDecoder（一）Cumulator》](http://svip.iocoder.cn/Netty/Codec-1-1-ByteToMessageDecoder-core-impl/)
+- [《精尽 Netty 源码解析 —— Codec 之 ByteToMessageDecoder（二）FrameDecoder》](http://svip.iocoder.cn/Netty/Codec-1-2-ByteToMessageDecoder-FrameDecoder/)
+
+## 了解哪几种序列化协议？
+
+🦅 **概念**
+
+- 序列化（编码），是将对象序列化为二进制形式（字节数组），主要用于网络传输、数据持久化等。
+- 反序列化（解码），则是将从网络、磁盘等读取的字节数组还原成原始对象，主要用于网络传输对象的解码，以便完成远程调用。
+
+🦅 **选型**
+
+在选择序列化协议的选择，主要考虑以下三个因素：
+
+- 序列化后的**字节大小**。更少的字节数，可以减少网络带宽、磁盘的占用。
+- 序列化的**性能**。对 CPU、内存资源占用情况。
+- 是否支持**跨语言**。例如，异构系统的对接和开发语言切换。
+
+🦅 **方案**
+
+> 如果对序列化工具了解不多的胖友，可能一看有这么多优缺点会比较懵逼，可以先记得有哪些序列化工具，然后在慢慢熟悉它们的优缺点。
+>
+> 重点，还是知道【**选型**】的考虑点。
+
+1. 【重点】Java 默认提供的序列化
+
+   - 无法跨语言；序列化后的字节大小太大；序列化的性能差。
+
+2. 【重点】XML 。
+
+   - 优点：人机可读性好，可指定元素或特性的名称。
+   - 缺点：序列化数据只包含数据本身以及类的结构，不包括类型标识和程序集信息；只能序列化公共属性和字段；不能序列化方法；文件庞大，文件格式复杂，传输占带宽。
+   - 适用场景：当做配置文件存储数据，实时数据转换。
+
+3. 【重点】JSON ，是一种轻量级的数据交换格式。
+
+   - 优点：兼容性高、数据格式比较简单，易于读写、序列化后数据较小，可扩展性好，兼容性好。与 XML 相比，其协议比较简单，解析速度比较快。
+   - 缺点：数据的描述性比 XML 差、不适合性能要求为 ms 级别的情况、额外空间开销比较大。
+   - 适用场景（可替代 XML ）：跨防火墙访问、可调式性要求高、基于Restful API 请求、传输数据量相对小，实时性要求相对低（例如秒级别）的服务。
+
+4. 【了解】Thrift ，不仅是序列化协议，还是一个 RPC 框架。
+
+   - 优点：序列化后的体积小, 速度快、支持多种语言和丰富的数据类型、对于数据字段的增删具有较强的兼容性、支持二进制压缩编码。
+   - 缺点：使用者较少、跨防火墙访问时，不安全、不具有可读性，调试代码时相对困难、不能与其他传输层协议共同使用（例如 HTTP）、无法支持向持久层直接读写数据，即不适合做数据持久化序列化协议。
+   - 适用场景：分布式系统的 RPC 解决方案。
+
+5. 【了解】Avro ，Hadoop 的一个子项目，解决了JSON的冗长和没有IDL的问题。
+
+   - 优点：支持丰富的数据类型、简单的动态语言结合功能、具有自我描述属性、提高了数据解析速度、快速可压缩的二进制数据形式、可以实现远程过程调用 RPC、支持跨编程语言实现。
+   - 缺点：对于习惯于静态类型语言的用户不直观。
+   - 适用场景：在 Hadoop 中做 Hive、Pig 和 MapReduce 的持久化数据格式。
+
+6. 【重点】Protobuf ，将数据结构以
+
+    
+
+   ```
+   .proto
+   ```
+
+    
+
+   文件进行描述，通过代码生成工具可以生成对应数据结构的 POJO 对象和 Protobuf 相关的方法和属性。
+
+   - 优点：序列化后码流小，性能高、结构化数据存储格式（XML JSON等）、通过标识字段的顺序，可以实现协议的前向兼容、结构化的文档更容易管理和维护。
+   - 缺点：需要依赖于工具生成代码、支持的语言相对较少，官方只支持Java 、C++、python。
+   - 适用场景：对性能要求高的 RPC 调用、具有良好的跨防火墙的访问属性、适合应用层对象的持久化。
+
+7. 其它
+
+   - 【重点】Protostuff ，基于 Protobuf 协议，但不需要配置proto 文件，直接导包即可。
+
+     - 目前，微博 RPC 框架 Motan 在使用它。
+
+   - 【了解】Jboss Marshaling ，可以直接序列化 Java 类， 无须实 `java.io.Serializable` 接口。
+
+   - 【了解】Message Pack ，一个高效的二进制序列化格式。
+
+   - 【重点】
+
+     Hessian
+
+      
+
+     ，采用二进制协议的轻量级 remoting on http 服务。
+
+     - 目前，阿里 RPC 框架 Dubbo 的**默认**序列化协议。
+
+   - 【重要】kryo ，是一个快速高效的Java对象图形序列化框架，主要特点是性能、高效和易用。该项目用来序列化对象到文件、数据库或者网络。
+
+     - 目前，阿里 RPC 框架 Dubbo 的可选序列化协议。
+
+   - 【重要】FST ，fast-serialization 是重新实现的 Java 快速对象序列化的开发包。序列化速度更快（2-10倍）、体积更小，而且兼容 JDK 原生的序列化。要求 JDK 1.7 支持。
+
+     - 目前，阿里 RPC 框架 Dubbo 的可选序列化协议。
+
+## Netty 的零拷贝实现？
+
+Netty 的零拷贝实现，是体现在多方面的，主要如下：
+
+1. 【重点】Netty 的接收和发送 ByteBuffer 采用堆外直接内存
+
+    
+
+   Direct Buffer
+
+    
+
+   。
+
+   - 使用堆外直接内存进行 Socket 读写，不需要进行字节缓冲区的二次拷贝；使用堆内内存会多了一次内存拷贝，JVM 会将堆内存 Buffer 拷贝一份到直接内存中，然后才写入 Socket 中。
+   - Netty 创建的 ByteBuffer 类型，由 ChannelConfig 配置。而 ChannelConfig 配置的 ByteBufAllocator 默认创建 Direct Buffer 类型。
+
+2. CompositeByteBuf
+
+    
+
+   类，可以将多个 ByteBuf 合并为一个逻辑上的 ByteBuf ，避免了传统通过内存拷贝的方式将几个小 Buffer 合并成一个大的 Buffer 。
+
+   - `#addComponents(...)` 方法，可将 header 与 body 合并为一个逻辑上的 ByteBuf 。这两个 ByteBuf 在CompositeByteBuf 内部都是单独存在的，即 CompositeByteBuf 只是逻辑上是一个整体。
+
+3. 通过
+
+    
+
+   FileRegion
+
+    
+
+   包装的 FileChannel 。
+
+   - `#tranferTo(...)` 方法，实现文件传输, 可以直接将文件缓冲区的数据发送到目标 Channel ，避免了传统通过循环 write 方式，导致的内存拷贝问题。
+
+4. 通过 **wrap** 方法, 我们可以将 `byte[]` 数组、ByteBuf、ByteBuffer 等包装成一个 Netty ByteBuf 对象, 进而避免了拷贝操作。
+
+## 原生的 NIO 存在 Epoll Bug 是什么？Netty 是怎么解决的？
+
+🦅 **Java NIO Epoll BUG**
+
+Java NIO Epoll 会导致 Selector 空轮询，最终导致 CPU 100% 。
+
+官方声称在 JDK 1.6 版本的 update18 修复了该问题，但是直到 JDK 1.7 版本该问题仍旧存在，只不过该 BUG 发生概率降低了一些而已，它并没有得到根本性解决。
+
+🦅 **Netty 解决方案**
+
+对 Selector 的 select 操作周期进行**统计**，每完成一次**空**的 select 操作进行一次计数，若在某个周期内连续发生 N 次空轮询，则判断触发了 Epoll 死循环 Bug 。
+
+> 艿艿：此处**空**的 select 操作的定义是，select 操作执行了 0 毫秒。
+
+此时，Netty **重建** Selector 来解决。判断是否是其他线程发起的重建请求，若不是则将原 SocketChannel 从旧的 Selector 上取消注册，然后重新注册到新的 Selector 上，最后将原来的 Selector 关闭。
+
+## 什么是 Netty 空闲检测？
+
+在 Netty 中，提供了 IdleStateHandler 类，正如其名，空闲状态处理器，用于检测连接的读写是否处于空闲状态。如果是，则会触发 IdleStateEvent 。
+
+IdleStateHandler 目前提供三种类型的心跳检测，通过构造方法来设置。代码如下：
+
+```
+// IdleStateHandler.java
+
+public IdleStateHandler(
+        int readerIdleTimeSeconds,
+        int writerIdleTimeSeconds,
+        int allIdleTimeSeconds) {
+    this(readerIdleTimeSeconds, writerIdleTimeSeconds, allIdleTimeSeconds,
+         TimeUnit.SECONDS);
+}
+```
+
+- `readerIdleTimeSeconds` 参数：为读超时时间，即测试端一定时间内未接受到被测试端消息。
+- `writerIdleTimeSeconds` 参数：为写超时时间，即测试端一定时间内向被测试端发送消息。
+- `allIdleTimeSeconds` 参数：为读或写超时时间。
+
+------
+
+另外，我们会在网络上看到类似《IdleStateHandler 心跳机制》这样标题的文章，实际上空闲检测和心跳机制是**两件事**。
+
+- 只是说，因为我们使用 IdleStateHandler 的目的，就是检测到连接处于空闲，通过心跳判断其是否还是**有效的连接**。
+- 虽然说，TCP 协议层提供了 Keeplive 机制，但是该机制默认的心跳时间是 2 小时，依赖操作系统实现不够灵活。因而，我们才在应用层上，自己实现心跳机制。
+
+具体的，我们来看看下面的问题 [「Netty 如何实现重连？」](https://svip.iocoder.cn/Netty/Interview/#) 。
+
+## Netty 如何实现重连？
+
+- 客户端，通过 IdleStateHandler 实现定时检测是否空闲，例如说 15 秒。
+  - 如果空闲，则向服务端发起心跳。
+  - 如果多次心跳失败，则关闭和服务端的连接，然后重新发起连接。
+- 服务端，通过 IdleStateHandler 实现定时检测客户端是否空闲，例如说 90 秒。
+  - 如果检测到空闲，则关闭客户端。
+  - 注意，如果接收到客户端的心跳请求，要反馈一个心跳响应给客户端。通过这样的方式，使客户端知道自己心跳成功。
+
+如下艿艿在自己的 [TaroRPC](https://github.com/YunaiV/TaroRPC) 中提供的一个示例：
+
+- [NettyClient.java](https://github.com/YunaiV/TaroRPC/blob/master/transport/transport-netty4/src/main/java/cn/iocoder/taro/transport/netty4/NettyClient.java) 中，设置 IdleStateHandler 和 ClientHeartbeatHandler。核心代码如下：
+
+  ```
+  // NettyHandler.java
+  
+  .addLast("idleState", new IdleStateHandler(TaroConstants.TRANSPORT_CLIENT_IDLE, TaroConstants.TRANSPORT_CLIENT_IDLE, 0, TimeUnit.MILLISECONDS))
+  .addLast("heartbeat", new ClientHeartbeatHandler())
+  ```
+
+- [NettyServer.java](https://github.com/YunaiV/TaroRPC/blob/master/transport/transport-netty4/src/main/java/cn/iocoder/taro/transport/netty4/NettyServer.java) 中，设置 IdleStateHandler 和 ServerHeartbeatHandler。核心代码如下：
+
+  ```
+  // NettyServer.java
+  
+  .addLast("idleState", new IdleStateHandler(0, 0, TaroConstants.TRANSPORT_SERVER_IDLE, TimeUnit.MILLISECONDS))
+  .addLast("heartbeat", new ServerHeartbeatHandler())
+  ```
+
+- [ClientHeartbeatHandler.java](https://github.com/YunaiV/TaroRPC/blob/master/transport/transport-netty4/src/main/java/cn/iocoder/taro/transport/netty4/heartbeat/ClientHeartbeatHandler.java) 中，碰到空闲，则发起心跳。不过，如何重连，暂时没有实现。需要考虑，重新发起连接可能会失败的情况。具体的，可以看看 [《一起学Netty（十四）之 Netty生产级的心跳和重连机制》](https://blog.csdn.net/linuu/article/details/51509847) 文章中的，ConnectionWatchdog 的代码。
+
+- [ServerHeartbeatHandler.java](https://github.com/YunaiV/TaroRPC/blob/6ce2af911ccec9ed5dc75c7f3ebda9c758272f3b/transport/transport-netty4/src/main/java/cn/iocoder/taro/transport/netty4/heartbeat/ServerHeartbeatHandler.java) 中，检测到客户端空闲，则直接关闭连接。
+
+## Netty 自己实现的 ByteBuf 有什么优点？
+
+如下是 [《Netty 实战》](http://svip.iocoder.cn/Netty/ByteBuf-1-1-ByteBuf-intro/#) 对它的**优点总**结：
+
+> - A01. 它可以被用户自定义的**缓冲区类型**扩展
+> - A02. 通过内置的符合缓冲区类型实现了透明的**零拷贝**
+> - A03. 容量可以**按需增长**
+> - A04. 在读和写这两种模式之间切换不需要调用 `#flip()` 方法
+> - A05. 读和写使用了**不同的索引**
+> - A06. 支持方法的**链式**调用
+> - A07. 支持引用计数
+> - A08. 支持**池化**
+
+- 特别是第 A04 这点，相信很多胖友都被 NIO ByteBuffer 反人类的读模式和写模式给坑哭了。在 [《精尽 Netty 源码分析 —— NIO 基础（三）之 Buffer》](http://svip.iocoder.cn/Netty/nio-3-buffer/) 中，我们也吐槽过了。😈
+
+想要进一步深入的，可以看看 [《精尽 Netty 源码解析 —— Buffer 之 ByteBuf（一）简介》](http://svip.iocoder.cn/Netty/ByteBuf-1-1-ByteBuf-intro/) 。
+
+## Netty 为什么要实现内存管理？
+
+🦅 **老艿艿的理解**
+
+在 Netty 中，IO 读写必定是非常频繁的操作，而考虑到更高效的网络传输性能，Direct ByteBuffer 必然是最合适的选择。但是 Direct ByteBuffer 的申请和释放是高成本的操作，那么进行**池化**管理，多次重用是比较有效的方式。但是，不同于一般于我们常见的对象池、连接池等**池化**的案例，ByteBuffer 是有**大小**一说。又但是，申请多大的 Direct ByteBuffer 进行池化又会是一个大问题，太大会浪费内存，太小又会出现频繁的扩容和内存复制！！！所以呢，就需要有一个合适的内存管理算法，解决**高效分配内存**的同时又解决**内存碎片化**的问题。
+
+🦅 **官方的说法**
+
+> FROM [《Netty 学习笔记 —— Pooled buffer》](https://skyao.gitbooks.io/learning-netty/content/buffer/pooled_buffer.html)
+>
+> Netty 4.x 增加了 Pooled Buffer，实现了高性能的 buffer 池，分配策略则是结合了 buddy allocation 和 slab allocation 的 **jemalloc** 变种，代码在`io.netty.buffer.PoolArena` 中。
+>
+> 官方说提供了以下优势：
+>
+> - 频繁分配、释放 buffer 时减少了 GC 压力。
+> - 在初始化新 buffer 时减少内存带宽消耗( 初始化时不可避免的要给buffer数组赋初始值 )。
+> - 及时的释放 direct buffer 。
+
+🦅 **hushi55 大佬的理解**
+
+> > C/C++ 和 java 中有个围城，城里的想出来，城外的想进去！**
+>
+> 这个围城就是自动内存管理！
+>
+> **Netty 4 buffer 介绍**
+>
+> Netty4 带来一个与众不同的特点是其 ByteBuf 的实现，相比之下，通过维护两个独立的读写指针， 要比 `io.netty.buffer.ByteBuf` 简单不少，也会更高效一些。不过，Netty 的 ByteBuf 带给我们的最大不同，就是他不再基于传统 JVM 的 GC 模式，相反，它采用了类似于 C++ 中的 malloc/free 的机制，需要开发人员来手动管理回收与释放。从手动内存管理上升到GC，是一个历史的巨大进步， 不过，在20年后，居然有曲线的回归到了手动内存管理模式，正印证了马克思哲学观： **社会总是在螺旋式前进的，没有永远的最好。**
+>
+> **① GC 内存管理分析**
+>
+> 的确，就内存管理而言，GC带给我们的价值是不言而喻的，不仅大大的降低了程序员的心智包袱， 而且，也极大的减少了内存管理带来的 Crash 困扰，为函数式编程（大量的临时对象）、脚本语言编程带来了春天。 并且，高效的GC算法也让大部分情况下程序可以有更高的执行效率。 不过，也有很多的情况，可能是手工内存管理更为合适的。譬如：
+>
+> - 对于类似于业务逻辑相对简单，譬如网络路由转发型应用（很多erlang应用其实是这种类型）， 但是 QPS 非常高，比如1M级，在这种情况下，在每次处理中即便产生1K的垃圾，都会导致频繁的GC产生。 在这种模式下，erlang 的按进程回收模式，或者是 C/C++ 的手工回收机制，效率更高。
+> - Cache 型应用，由于对象的存在周期太长，GC 基本上就变得没有价值。
+>
+> 所以，理论上，尴尬的GC实际上比较适合于处理介于这 2 者之间的情况： 对象分配的频繁程度相比数据处理的时间要少得多的，但又是相对短暂的， 典型的，对于OLTP型的服务，处理能力在 1K QPS 量级，每个请求的对象分配在 10K-50K 量级， 能够在 5-10s 的时间内进行一 次younger GC ，每次GC的时间可以控制在 10ms 水平上， 这类的应用，实在是太适合 GC 行的模式了，而且结合 Java 高效的分代 GC ，简直就是一个理想搭配。
+>
+> **② 影响**
+>
+> Netty 4 引入了手工内存的模式，我觉得这是一大创新，这种模式甚至于会延展， 应用到 Cache 应用中。实际上，结合 JVM 的诸多优秀特性，如果用 Java 来实现一个 Redis 型 Cache、 或者 In-memory SQL Engine，或者是一个 Mongo DB，我觉得相比 C/C++ 而言，都要更简单很多。 实际上，JVM 也已经提供了打通这种技术的机制，就是 Direct Memory 和 Unsafe 对象。 基于这个基础，我们可以像 C 语言一样直接操作内存。实际上，Netty4 的 ByteBuf 也是基于这个基础的。
+
+更多详细的内容，胖友可以看看 [《精尽 Netty 源码解析 —— Buffer 之 Jemalloc（一）简介》](http://svip.iocoder.cn/Netty/ByteBuf-3-1-Jemalloc-intro/) 。
+
+## Netty 如何实心内存管理？
+
+> 这个题目，简单了解即可，如果深入，就要去看 [《精尽 Netty 源码解析 —— Buffer》](http://svip.iocoder.cn/categories/Netty/) 相关的源码。而且，看完就忘记，比较难和复杂。
+>
+> 当然，看懂那一刻，乐趣无穷，哈哈哈哈。
+
+Netty 内存管理机制，基于 [Jemalloc](http://www.cnhalo.net/2016/06/13/memory-optimize/) 算法。
+
+- 首先会预申请一大块内存 **Arena** ，Arena 由许多 Chunk 组成，而每个 Chunk 默认由2048个page组成。
+- **Chunk** 通过 **AVL** 树的形式组织 **Page** ，每个叶子节点表示一个 Page ，而中间节点表示内存区域，节点自己记录它在整个 Arena 中的偏移地址。当区域被分配出去后，中间节点上的标记位会被标记，这样就表示这个中间节点以下的所有节点都已被分配了。大于 8k 的内存分配在 **PoolChunkList** 中，而 **PoolSubpage** 用于分配小于 8k 的内存，它会把一个 page 分割成多段，进行内存分配。
+
+## 什么是 Netty 的内存泄露检测？是如何进行实现的？
+
+> 艿艿：这是一道比较复杂的面试题，可以挑战一下。
+
+推荐阅读如下两篇文章：
+
+- [《Netty 之有效规避内存泄漏》](http://calvin1978.blogcn.com/articles/netty-leak.html) 从原理层面解释。
+- [《精尽 Netty 源码解析 —— Buffer 之 ByteBuf（三）内存泄露检测》](http://svip.iocoder.cn/Netty/ByteBuf-1-3-ByteBuf-resource-leak-detector/) 从源码层面解读。
+
+另外，Netty 的内存泄露检测的实现，是对 WeakReference 和 ReferenceQueue 很好的学习。之前很多胖友在看了 [《Java 中的四种引用类型》](http://www.iocoder.cn/Fight/Four-reference-types-in-Java) 之后，是不太理解 Java 的四种引用的具体使用场景，这不就来了么。
+
+# 666. 彩蛋
+
+😈 撸完 Netty 源码之后，一段时间没去用，东西都忘了蛮多。不过因为读过源码，在看这些面试题，会发现轻松太多了。有一种，“老朋友”的感觉。妥妥的。
+
+参考与推荐如下文章：
+
+- itdragon [《Netty 序章之 BIO NIO AIO 演变》](https://segmentfault.com/a/1190000012976683)
+- 白夜行515 [《【面试题】Netty相关》](https://blog.csdn.net/baiye_xing/article/details/76735113)
+- albon [《Netty 权威指南笔记（二）：Java NIO 和 Netty 对比》](https://www.jianshu.com/p/93876f1bf6d1)
+- albon [《Netty 权威指南笔记（四）：架构剖析》](https://www.jianshu.com/p/ececec069cc1)
+- 狗窝 [《面试题之 Netty》](https://nizouba.com/articles/2018/11/04/1541322296629.html) 题目很不错，就是图片都挂了。
\ No newline at end of file
diff --git a/面试题/02-Dubbo 面试题.assets/01-17182492529961.png b/面试题/02-Dubbo 面试题.assets/01-17182492529961.png
new file mode 100644
index 0000000..4015a56
Binary files /dev/null and b/面试题/02-Dubbo 面试题.assets/01-17182492529961.png differ
diff --git a/面试题/02-Dubbo 面试题.assets/01-17182492529962.png b/面试题/02-Dubbo 面试题.assets/01-17182492529962.png
new file mode 100644
index 0000000..36d5859
Binary files /dev/null and b/面试题/02-Dubbo 面试题.assets/01-17182492529962.png differ
diff --git a/面试题/02-Dubbo 面试题.assets/01-17182492529963.png b/面试题/02-Dubbo 面试题.assets/01-17182492529963.png
new file mode 100644
index 0000000..7a44fda
--- /dev/null
+++ b/面试题/02-Dubbo 面试题.assets/01-17182492529963.png	
@@ -0,0 +1,31 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+	<meta charset="utf-8">
+	<meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
+	<meta name="description" content="">
+	<meta name="author" content="">
+	<title>http://svip.iocoder.cn</title>
+	<link href="https://lf6-cdn-tos.bytecdntp.com/cdn/expire-1-M/bootstrap/4.6.1/css/bootstrap.min.css"
+				type="text/css" rel="stylesheet" />
+	<link href="https://getbootstrap.com/docs/4.0/examples/signin/signin.css" rel="stylesheet" crossorigin="anonymous"/>
+</head>
+<body>
+<div class="container">
+	<form action="/user/auth" class="form-signin" method="post"><input type="hidden" name="_csrf" value="d9fb8669-e03f-4554-8b00-5629cb129814"/>
+		<h2 class="form-signin-heading">登录</h2>
+		
+		<p>
+			<label for="username" class="sr-only">用户名</label>
+			<input type="text" id="username" name="username" class="form-control" placeholder="用户名" required autofocus>
+		</p>
+		<p>
+			<label for="password" class="sr-only">密码</label>
+			<input type="password" id="password" name="password" class="form-control" placeholder="密码" required>
+		</p>
+		<button class="btn btn-lg btn-primary btn-block" type="submit">登录</button>
+		<p>如果账号密码不正确，访问 <a href="https://t.zsxq.com/11JUHkGgl">https://t.zsxq.com/11JUHkGgl</a>  或 <a href="https://t.zsxq.com/yBUj2NN">https://t.zsxq.com/yBUj2NN</a> 解决</p>
+	</form>
+</div>
+</body>
+</html>
diff --git a/面试题/02-Dubbo 面试题.assets/01-17182492529964.png b/面试题/02-Dubbo 面试题.assets/01-17182492529964.png
new file mode 100644
index 0000000..507ddca
Binary files /dev/null and b/面试题/02-Dubbo 面试题.assets/01-17182492529964.png differ
diff --git a/面试题/02-Dubbo 面试题.assets/01-17182492529965.png b/面试题/02-Dubbo 面试题.assets/01-17182492529965.png
new file mode 100644
index 0000000..a63c924
Binary files /dev/null and b/面试题/02-Dubbo 面试题.assets/01-17182492529965.png differ
diff --git a/面试题/02-Dubbo 面试题.assets/01.png b/面试题/02-Dubbo 面试题.assets/01.png
new file mode 100644
index 0000000..5a7bb40
Binary files /dev/null and b/面试题/02-Dubbo 面试题.assets/01.png differ
diff --git a/面试题/02-Dubbo 面试题.md b/面试题/02-Dubbo 面试题.md
new file mode 100644
index 0000000..70395f1
--- /dev/null
+++ b/面试题/02-Dubbo 面试题.md	
@@ -0,0 +1,1035 @@
+# 精尽 Dubbo 面试题「最新更新时间：2024-02」
+
+以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。
+
+如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的 Dubbo 面试题的大保健。
+
+而题目的难度，艿艿尽量按照从容易到困难的顺序，逐步下去。
+
+## Dubbo 有几种配置方式？
+
+正如在 [《Dubbo 用户指南 —— 配置》](http://dubbo.apache.org/zh-cn/docs/user/configuration/xml.html) 中所见，一共有四种配置方式：
+
+- XML 配置
+- 注解配置
+- 属性配置
+- Java API 配置
+
+实际上，还有第五种方式，外部化配置。参见 [《Dubbo 新编程模型之外部化配置》](https://segmentfault.com/a/1190000012661402) 。
+
+目前，主要使用的是 XML 配置和注解配置。具体使用哪一种，就看大家各自的喜好。目前，艿艿偏好 XML 配置，更加清晰好管理。
+
+## Dubbo 如何和 Spring Boot 进行集成？
+
+官方提供提供了集成库 `dubbo-spring-boot` ，对应仓库为 https://github.com/apache/incubator-dubbo-spring-boot-project 。
+
+## Dubbo 框架的分层设计
+
+在 [《精尽 Dubbo 源码分析 —— 核心流程一览》](http://svip.iocoder.cn/) 一文中，对 Dubbo 框架的分层已经有过介绍，这里再来一次。
+
+相对比较**复杂**，一共分成 **10 层**，当然理解后是非常**清晰**的。如下图所示：
+
+[![整体设计](02-Dubbo 面试题.assets/01.png)](http://static.iocoder.cn/images/Dubbo/2018_03_01/01.png)整体设计
+
+**图例说明**
+
+- 最顶上九个**图标**，代表本图中的对象与流程。
+
+- 图中左边 **淡蓝背景**( Consumer ) 的为服务消费方使用的接口，右边 **淡绿色背景**( Provider ) 的为服务提供方使用的接口，位于中轴线上的为双方都用到的接口。
+
+- 图中从下至上分为十层，各层均为**单向**依赖，右边的 **黑色箭头**( Depend ) 代表层之间的依赖关系，每一层都可以剥离上层被复用。其中，Service 和 Config 层为 API，其它各层均为 [SPI](http://blog.csdn.net/top_code/article/details/51934459) 。
+
+  > 注意，Dubbo 并未使用 JDK SPI 机制，而是自己实现了一套 Dubbo SPI 机制。
+
+- 图中 **绿色小块**( Interface ) 的为扩展接口，**蓝色小块**( Class ) 为实现类，图中只显示用于关联各层的实现类。
+
+- 图中 **蓝色虚线**( Init ) 为初始化过程，即启动时组装链。**红色实线**( Call )为方法调用过程，即运行时调时链。**紫色三角箭头**( Inherit )为继承，可以把子类看作父类的同一个节点，线上的文字为调用的方法。
+
+**各层说明**
+
+虽然，有 10 层这么多，但是总体是分层 Business、RPC、Remoting **三大层**。如下：
+
+- ==================== Business ====================
+
+- **Service 业务层**：业务代码的接口与实现。我们实际使用 Dubbo 的业务层级。
+
+  > 接口层，给服务提供者和消费者来实现的。
+
+- ==================== RPC ====================
+
+- **config 配置层**：对外配置接口，以 ServiceConfig, ReferenceConfig 为中心，可以直接初始化配置类，也可以通过 Spring 解析配置生成配置类。
+
+  > 配置层，主要是对 Dubbo 进行各种配置的。
+
+- **proxy 服务代理层**：服务接口透明代理，生成服务的客户端 Stub 和服务器端 Skeleton, 扩展接口为 ProxyFactory 。
+
+  > 服务代理层，无论是 consumer 还是 provider，Dubbo 都会给你生成代理，代理之间进行网络通信。
+  >
+  > 如果胖友了解 Spring Cloud 体系，可以类比成 Feign 对于 consumer ，Spring MVC 对于 provider 。
+
+- **registry** 注册中心层：封装服务地址的注册与发现，以服务 URL 为中心，扩展接口为 RegistryFactory, Registry, RegistryService 。
+
+  > 服务注册层，负责服务的注册与发现。
+  >
+  > 如果胖友了解 Spring Cloud 体系，可以类比成 Eureka Client 。
+
+- **cluster 路由层**：封装多个提供者的路由及负载均衡，并桥接注册中心，以 Invoker 为中心，扩展接口为 Cluster, Directory, Router, LoadBalance 。
+
+  > 集群层，封装多个服务提供者的路由以及负载均衡，将多个实例组合成一个服务。
+  >
+  > 如果胖友了解 Spring Cloud 体系，可以类比城 Ribbon 。
+
+- **monitor 监控层**：RPC 调用次数和调用时间监控，以 Statistics 为中心，扩展接口为 MonitorFactory, Monitor, MonitorService 。
+
+  > 监控层，对 rpc 接口的调用次数和调用时间进行监控。
+  >
+  > 如果胖友了解 SkyWalking 链路追踪，你会发现，SkyWalking 基于 MonitorFilter 实现增强，从而透明化埋点监控。
+
+- ==================== Remoting ====================
+
+- **protocol 远程调用层**：封将 RPC 调用，以 Invocation, Result 为中心，扩展接口为 Protocol, Invoker, Exporter 。
+
+  > 远程调用层，封装 rpc 调用。
+
+- **exchange 信息交换层**：封装请求响应模式，同步转异步，以 Request, Response 为中心，扩展接口为 Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer 。
+
+  > 信息交换层，封装请求响应模式，同步转异步。
+
+- **transport 网络传输层**：抽象 mina 和 netty 为统一接口，以 Message 为中心，扩展接口为 Channel, Transporter, Client, Server, Codec 。
+
+  > 网络传输层，抽象 mina 和 netty 为统一接口。
+
+- **serialize 数据序列化层**：可复用的一些工具，扩展接口为 Serialization, ObjectInput, ObjectOutput, ThreadPool 。
+
+  > 数据序列化层。
+
+## Dubbo 调用流程
+
+[![简化调用图](02-Dubbo 面试题.assets/01-17182492529961.png)](http://static.iocoder.cn/images/Dubbo/2018_01_01/01.png)简化调用图
+
+- Provider
+  - 第 0 步，start 启动服务。
+  - 第 1 步，register 注册服务到注册中心。
+- Consumer
+  - 第 2 步，subscribe 向注册中心订阅服务。
+    - 注意，只订阅使用到的服务。
+    - 再注意，首次会拉取订阅的服务列表，缓存在本地。
+  - 【异步】第 3 步，notify 当服务发生变化时，获取最新的服务列表，更新本地缓存。
+- invoke 调用
+  - Consumer 直接发起对 Provider 的调用，无需经过注册中心。而对多个 Provider 的负载均衡，Consumer 通过 **cluster** 组件实现。
+- count 监控
+  - 【异步】Consumer 和 Provider 都异步通知监控中心。
+
+这里艿艿在引用一张在网上看到的图，更立体的展示 Dubbo 的调用流程：
+
+[![详细调用图](02-Dubbo 面试题.assets/01-17182492529962.png)](http://static.iocoder.cn/images/Dubbo/2017_10_24/01.png)详细调用图
+
+- 注意，图中的【代理】指的是 **proxy 代理服务层**，和 Consumer 或 Provider 在同一进城中。
+- 注意，图中的【负载均衡】指的是 **cluster 路由层**，和 Consumer 或 Provider 在同一进程中。
+
+最近又用 Processon 手绘了一张 Dubbo 的调用图，建议胖友自己试着手绘下~
+
+[![更清晰的调用图](02-Dubbo 面试题.assets/01-17182492529963.png)](http://svip.iocoder.cn/images/Dubbo/2017_10_24/01.png)更清晰的调用图
+
+原图地址：https://www.processon.com/view/link/5f4899995653bb0c71dc4c1a
+
+## Dubbo 调用是同步的吗？
+
+默认情况下，调用是**同步**的方式。
+
+可以参考 [《Dubbo 用户指南 —— 异步调用》](http://dubbo.apache.org/zh-cn/docs/user/demos/async-call.html) 文档，配置**异步**调用的方式。当然，使用上，感觉蛮不优雅的。所以，在 Dubbo 2.7 版本后，又提供了新的两种方式，具体先参见 [《Dubbo下一站：Apache顶级项目》](https://mp.weixin.qq.com/s/3WwXcWJbP7iOS3vmN-Ek1Q) 文章。估计，后续才会更新官方文档。
+
+## 谈谈对 Dubbo 的异常处理机制？
+
+Dubbo 异常处理机制涉及的内容比较多，核心在于 Provider 的 异常过滤器 **ExceptionFilter** 对调用结果的各种情况的处理。所以建议胖友看如下三篇文章：
+
+- 墙裂推荐 [《Dubbo(四) 异常处理》](https://blog.csdn.net/qq315737546/article/details/53915067)
+- [《浅谈 Dubbo 的 ExceptionFilter 异常处理》](https://blog.csdn.net/mj158518/article/details/51228649)
+- [《精尽 Dubbo 源码分析 —— 过滤器（七）之 ExceptionFilter》](http://svip.iocoder.cn/Dubbo/filter-exception-filter/)
+
+## Dubbo 如何做参数校验？
+
+在 [《Dubbo 用户指南 —— 参数验证》](http://dubbo.apache.org/zh-cn/docs/user/demos/parameter-validation.html) 中，介绍如下：
+
+> 参数验证功能是基于 [JSR303](https://jcp.org/en/jsr/detail?id=303) 实现的，用户只需标识 JSR303 标准的验证 annotation，并通过声明 filter 来实现验证。
+
+- 参数校验功能，通过参数校验过滤器 ValidationFilter 来实现。
+- ValidationFilter 在 Dubbo Provider 和 Consumer 都可生效。
+  - 如果我们将**校验注解**写在 Service 接口的方法上，那么 Consumer 在本地就会校验。如果校验不通过，直接抛出校验失败的异常，不会发起 Dubbo 调用。
+  - 如果我们将**校验注解**写在 Service 实现的方法上，那么 Consumer 在本地不会校验，而是由 Provider 校验。
+
+## Dubbo 可以对调用结果进行缓存吗?
+
+Dubbo 通过 CacheFilter 过滤器，提供结果缓存的功能，且既可以适用于 Consumer 也可以适用于 Provider 。
+
+通过结果缓存，用于加速热门数据的访问速度，Dubbo 提供声明式缓存，以减少用户加缓存的工作量。
+
+Dubbo 目前提供三种实现：
+
+- `lru` ：基于最近最少使用原则删除多余缓存，保持最热的数据被缓存。
+- `threadlocal` ：当前线程缓存，比如一个页面渲染，用到很多 portal，每个 portal 都要去查用户信息，通过线程缓存，可以减少这种多余访问。
+- `jcache` ：与 [JSR107](https://jcp.org/en/jsr/detail?id=107) 集成，可以桥接各种缓存实现。
+
+详细的源码解析，可见 [《精尽 Dubbo 源码分析 —— 过滤器（十）之 CacheFilter》](http://svip.iocoder.cn/Dubbo/filter-cache-filter/) 。
+
+## 注册中心挂了还可以通信吗？
+
+可以。对于正在运行的 Consumer 调用 Provider 是不需要经过注册中心，所以不受影响。并且，Consumer 进程中，内存已经缓存了 Provider 列表。
+
+那么，此时 Provider 如果下线呢？如果 Provider 是**正常关闭**，它会主动且直接对和其处于连接中的 Consumer 们，发送一条“我要关闭”了的消息。那么，Consumer 们就不会调用该 Provider ，而调用其它的 Provider 。
+
+另外，因为 Consumer 也会持久化 Provider 列表到本地文件。所以，此处如果 Consumer 重启，依然能够通过本地缓存的文件，获得到 Provider 列表。
+
+再另外，一般情况下，注册中心是一个集群，如果一个节点挂了，Dubbo Consumer 和 Provider 将自动切换到集群的另外一个节点上。
+
+## Dubbo 在 Zookeeper 存储了哪些信息？
+
+下面，我们先来看下 [《Dubbo 用户指南 —— zookeeper 注册中心》](https://dubbo.gitbooks.io/dubbo-user-book/references/registry/zookeeper.html) 文档，内容如下：
+
+> [![流程](02-Dubbo 面试题.assets/01-17182492529964.png)](http://static.iocoder.cn/images/Dubbo/2018_08_04/01.png)流程
+>
+> 流程说明：
+>
+> - **服务提供者**启动时: 向 `/dubbo/com.foo.BarService/providers` 目录下写入自己的 URL 地址
+> - **服务消费者**启动时: 订阅 `/dubbo/com.foo.BarService/providers` 目录下的提供者 URL 地址。并向 `/dubbo/com.foo.BarService/consumers` 目录下写入自己的 URL 地址
+> - **监控中心**启动时: 订阅 `/dubbo/com.foo.BarService` 目录下的所有提供者和消费者 URL 地址。
+
+- 在图中，我们可以看到 Zookeeper 的节点层级，自上而下是：
+  - **Root** 层：根目录，可通过 `<dubbo:registry group="dubbo" />` 的 `"group"` 设置 Zookeeper 的根节点，缺省使用 `"dubbo"` 。
+  - **Service** 层：服务接口全名。
+  - **Type** 层：分类。目前除了我们在图中看到的 `"providers"`( 服务提供者列表 ) `"consumers"`( 服务消费者列表 ) 外，还有 [`"routes"`](https://dubbo.gitbooks.io/dubbo-user-book/demos/routing-rule.html)( 路由规则列表 ) 和 [`"configurations"`](https://dubbo.gitbooks.io/dubbo-user-book/demos/config-rule.html)( 配置规则列表 )。
+  - **URL** 层：URL ，根据不同 Type 目录，下面可以是服务提供者 URL 、服务消费者 URL 、路由规则 URL 、配置规则 URL 。
+  - 实际上 URL 上带有 `"category"` 参数，已经能判断每个 URL 的分类，但是 Zookeeper 是基于节点目录订阅的，所以增加了 **Type** 层。
+- 实际上，**服务消费者**启动后，不仅仅订阅了 `"providers"` 分类，也订阅了 `"routes"` `"configurations"` 分类。
+
+## Dubbo Provider 如何实现优雅停机？
+
+在 [《Dubbo 用户指南 —— 优雅停机》](http://dubbo.apache.org/zh-cn/docs/user/demos/graceful-shutdown.html) 中，已经对这块进行了详细的说明。
+
+**优雅停机**
+
+> Dubbo 是通过 JDK 的 ShutdownHook 来完成优雅停机的，所以如果用户使用 `kill -9 PID` 等强制关闭指令，是不会执行优雅停机的，只有通过 `kill PID` 时，才会执行。
+
+- 因为大多数情况下，Dubbo 的声明周期是交给 Spring 进行管理，所以在最新的 Dubbo 版本中，增加了对 Spring 关闭事件的监听，从而关闭 Dubbo 服务。对应可见 https://github.com/apache/incubator-dubbo/issues/2865 。
+
+**服务提供方的优雅停机过程**
+
+1. 首先，从注册中心中取消注册自己，从而使消费者不要再拉取到它。
+2. 然后，sleep 10 秒( 可配 )，等到服务消费，接收到注册中心通知到该服务提供者已经下线，加大了在不重试情况下优雅停机的成功率。😈 此处是个概率学，嘻嘻。
+3. 之后，广播 READONLY 事件给所有 Consumer 们，告诉它们不要在调用我了！！！【很有趣的一个步骤】并且，如果此处注册中心挂掉的情况，依然能达到告诉 Consumer ，我要下线了的功能。
+4. 再之后，sleep 10 毫秒，保证 Consumer 们，尽可能接收到该消息。
+5. 再再之后，先标记为不接收新请求，新请求过来时直接报错，让客户端重试其它机器。
+6. 再再再之后，关闭心跳线程。
+7. 最后，检测线程池中的线程是否正在运行，如果有，等待所有线程执行完成，除非超时，则强制关闭。
+8. 最最后，关闭服务器。
+
+整个过程比较复杂，感兴趣的胖友，可以详细来看看 [《精尽 Dubbo 源码解析 —— 优雅停机》](http://svip.iocoder.cn/Dubbo/graceful-shutdown/) 。
+
+**服务消费方的优雅停机过程**
+
+1. 停止时，不再发起新的调用请求，所有新的调用在客户端即报错。
+2. 然后，检测有没有请求的响应还没有返回，等待响应返回，除非超时，则强制关闭。
+
+## Dubbo Provider 异步关闭时，如何从注册中心下线？
+
+**① Zookeeper 注册中心的情况下**
+
+服务提供者，注册到 Zookeeper 上时，创建的是 EPHEMERAL 临时节点。所以在服务提供者异常关闭时，等待 Zookeeper 会话超时，那么该临时节点就会自动删除。
+
+**② Redis 注册中心的情况下**
+
+使用 Redis 作为注册中心，是有点小众的选择，我们就不在本文详细说了。感兴趣的胖友，可以看看 [《精尽 Dubbo 源码分析 —— 注册中心（三）之 Redis》](http://svip.iocoder.cn/Dubbo/registry-redis/) 一文。总的来说，实现上，还是蛮有趣的。因为，需要通知到消费者，服务列表发生变化，所以就无法使用 Redis Key 自动过期。所以… 还是看文章吧。哈哈哈哈。
+
+## Dubbo Consumer 只能调用从注册中心获取的 Provider 么？
+
+不是，Consumer 可以强制直连 Provider 。
+
+在**开发及测试环境**下，经常需要绕过注册中心，只测试指定服务提供者，这时候可能需要点对点直连，点对点直连方式，将以服务接口为单位，忽略注册中心的提供者列表，A 接口配置点对点，不影响 B 接口从注册中心获取列表。
+
+相关文档，可见 [《Dubbo 用户指南 —— 直连提供者》](http://dubbo.apache.org/zh-cn/docs/user/demos/explicit-target.html) 。
+
+另外，直连 Dubbo Provider 时，如果要 Debug 调试 Dubbo Provider ，可以通过配置，禁用该 Provider 注册到注册中心。否则，会被其它 Consumer 调用到。具体的配置方式，参见 [《Dubbo 用户指南 —— 只订阅》](http://dubbo.apache.org/zh-cn/docs/user/demos/subscribe-only.html) 。
+
+## Dubbo 支持哪些通信协议？
+
+> 对应【protocol 远程调用层】。
+
+Dubbo 目前支持如下 9 种通信协议：
+
+- 【重要】`dubbo://` ，默认协议。参见 [《Dubbo 用户指南 —— dubbo://》](http://dubbo.apache.org/zh-cn/docs/user/references/protocol/dubbo.html) 。
+- 【重要】`rest://` ，贡献自 Dubbox ，目前最合适的 HTTP Restful API 协议。参见 [《Dubbo 用户指南 —— rest://》](http://dubbo.apache.org/zh-cn/docs/user/references/protocol/rest.html) 。
+- `rmi://` ，参见 [《Dubbo 用户指南 —— rmi://》](http://dubbo.apache.org/zh-cn/docs/user/references/protocol/rmi.html) 。
+- `webservice://` ，参见 [《Dubbo 用户指南 —— webservice://》](http://dubbo.apache.org/zh-cn/docs/user/references/protocol/webservice.html) 。
+- `hessian://` ，参见 [《Dubbo 用户指南 —— hessian://》](http://dubbo.apache.org/zh-cn/docs/user/references/protocol/hessian.html) 。
+- `thrift://` ，参见 [《Dubbo 用户指南 —— thrift://》](http://dubbo.apache.org/zh-cn/docs/user/references/protocol/thrift.html) 。
+- `memcached://` ，参见 [《Dubbo 用户指南 —— memcached://》](http://dubbo.apache.org/zh-cn/docs/user/references/protocol/memcached.html) 。
+- `redis://` ，参见 [《Dubbo 用户指南 —— redis://》](http://dubbo.apache.org/zh-cn/docs/user/references/protocol/redis.html) 。
+- `http://` ，参见 [《Dubbo 用户指南 —— http://》](http://dubbo.apache.org/zh-cn/docs/user/references/protocol/http.html) 。注意，这个和我们理解的 HTTP 协议有差异，而是 Spring 的 HttpInvoker 实现。
+
+实际上，社区里还有其他通信协议正处于孵化：
+
+- `jsonrpc://` ，对应 Github 仓库为 https://github.com/apache/incubator-dubbo-rpc-jsonrpc ，来自千米网的贡献。
+
+😈 每一种通信协议的实现，在 [《精尽 Dubbo 源码解析》](http://svip.iocoder.cn/categories/Dubbo/) 中，都有详细解析。
+
+另外，在 [《Dubbo 用户指南 —— 性能测试报告》](http://dubbo.apache.org/zh-cn/docs/user/perf-test.html) 中，官方提供了上述协议的性能测试对比。
+
+## 什么是本地暴露和远程暴露，他们的区别？
+
+远程暴露，比较好理解。在 [「Dubbo 支持哪些通信协议？」](https://svip.iocoder.cn/Dubbo/Interview/#) 问题汇总，我们看到的，都是远程暴露。每次 Consumer 调用 Provider 都是跨进程，需要进行网络通信。
+
+本地暴露，在 [《Dubbo 用户指南 —— 本地调用》](http://dubbo.apache.org/zh-cn/docs/user/demos/local-call.html) 一文中，定义如下：
+
+> 本地调用使用了 `injvm://` 协议，是一个伪协议，它不开启端口，不发起远程调用，只在 JVM 内直接关联，但执行 Dubbo 的 Filter 链。
+
+- 怎么理解呢？本地的 Dubbo Service Proxy 对象，每次调用时，会走 Dubbo Filter 链。
+- 举个例子，Spring Boot Controller 调用 Service 逻辑，就变成了调用 Dubbo Service Proxy 对象。这样，如果未来有一天，本地 Dubbo Service 迁移成远程的 Dubbo Service ，只需要进行配置的修改，而对 Controller 是透明的。
+
+## Dubbo 使用什么通信框架？
+
+> 对应【transport 网络传输层】。
+
+在通信框架的选择上，强大的技术社区有非常多的选择，如下列表：
+
+- Netty3
+- Netty4
+- Mina
+- Grizzly
+
+那么 Dubbo 是如何做技术选型和实现的呢？Dubbo 在通信层拆分成了 API 层、实现层。项目结构如下：
+
+- API 层：
+  - `dubbo-remoting-api`
+- 实现层：
+  - `dubbo-remoting-netty3`
+  - `dubbo-remoting-netty4`
+  - `dubbo-remoting-mina`
+  - `dubbo-remoting-grizzly`
+
+再配合上 Dubbo SPI 的机制，使用者可以自定义使用哪一种具体的实现。美滋滋。
+
+在 Dubbo 的最新版本，默认使用 **Netty4** 的版本。😈 这就是结论。嘻嘻。
+
+## Dubbo 支持哪些序列化方式？
+
+> 对应【serialize 数据序列化层】。
+
+Dubbo 目前支付如下 7 种序列化方式：
+
+- 【重要】Hessian2 ：基于 Hessian 实现的序列化拓展。
+
+  ```
+  dubbo://
+  ```
+
+   
+
+  协议的默认序列化方案。
+
+  - Hessian 除了是 Web 服务，也提供了其序列化实现，因此 Dubbo 基于它实现了序列化拓展。
+  - 另外，Dubbo 维护了自己的 [`hessian-lite`](https://github.com/alibaba/dubbo/tree/4bbc0ddddacc915ddc8ff292dd28745bbc0031fd/hessian-lite) ，对 [Hessian 2](http://hessian.caucho.com/) 的 **序列化** 部分的精简、改进、BugFix 。
+
+- Dubbo ：Dubbo 自己实现的序列化拓展。
+
+  - 具体可参见 [《精尽 Dubbo 源码分析 —— 序列化（二）之 Dubbo 实现》](http://svip.iocoder.cn/Dubbo/serialize-2-dubbo/) 。
+
+- Kryo ：基于
+
+   
+
+  Kryo
+
+   
+
+  实现的序列化拓展。
+
+  - 具体可参见 [《Dubbo 用户指南 —— Kryo 序列化》](http://dubbo.apache.org/zh-cn/docs/user/demos/serialization.html)
+
+- FST ：基于
+
+   
+
+  FST
+
+   
+
+  实现的序列化拓展。
+
+  - 具体可参见 [《Dubbo 用户指南 —— FST 序列化》](http://dubbo.apache.org/zh-cn/docs/user/demos/serialization.html)
+
+- JSON ：基于 [Fastjson](https://www.oschina.net/p/fastjson) 实现的序列化拓展。
+
+- NativeJava ：基于 Java 原生的序列化拓展。
+
+- CompactedJava ：在 **NativeJava** 的基础上，实现了对 ClassDescriptor 的处理。
+
+可能胖友会一脸懵逼，有这么多？其实还好，上述基本是市面上主流的集中序列化工具，Dubbo 基于它们之上提供序列化拓展。
+
+然后，胖友可能会说，**Protobuf** 也是非常优秀的序列化方案，为什么 Dubbo 没有基于它的序列化拓展？从 Dubbo 后续的开发计划上，应该会增加该序列化的支持。另外，微博的 Motan 有实现对 Protobuf 序列化的支持，感兴趣的胖友，可以看看 [《深入理解RPC之序列化篇 —— 总结篇》](https://www.cnkirito.moe/rpc-serialize-2/) 的 [「Protostuff实现」](https://svip.iocoder.cn/Dubbo/Interview/#) 小节。
+
+## Dubbo 有哪些负载均衡策略？
+
+> 对应【cluster 路由层】的 LoadBalance 组件。
+
+在 [《Dubbo 用户指南 —— 负载均衡》](http://dubbo.apache.org/zh-cn/docs/user/demos/loadbalance.html) 中，我们可以看到 Dubbo 内置 4 种负载均衡策略。其中，默认使用 `random` 随机调用策略。
+
+**Random LoadBalance**
+
+- **随机**，按权重设置随机概率。
+- 在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
+
+**RoundRobin LoadBalance**
+
+- **轮询**，按公约后的权重设置轮询比率。
+
+- 存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
+
+  > 举个栗子。
+  >
+  > 跟运维同学申请机器，有的时候，我们运气好，正好公司资源比较充足，刚刚有一批热气腾腾、刚刚做好的一批虚拟机新鲜出炉，配置都比较高。8核+16g，机器，2 台。过了一段时间，我感觉 2 台机器有点不太够，我去找运维同学，哥儿们，你能不能再给我 1 台机器，4核+8G的机器。我还是得要。
+  >
+  > 这个时候，可以给两台 8核16g 的机器设置权重 4，给剩余 1 台 4核8G 的机器设置权重 2。
+
+**LeastActive LoadBalance**
+
+- **最少活跃调用数**，相同活跃数的随机，活跃数指调用前后计数差。
+
+- 使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
+
+  > 这个就是自动感知一下，如果某个机器性能越差，那么接收的请求越少，越不活跃，此时就会给不活跃的性能差的机器更少的请求。
+
+**ConsistentHash LoadBalance**
+
+- **一致性 Hash**，相同参数的请求总是发到同一提供者。
+- 当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
+
+## Dubbo 有哪些集群容错策略？
+
+> 对应【cluster 路由层】的 Cluster 组件。
+
+在 [《Dubbo 用户指南 —— 集群容错》](http://dubbo.apache.org/zh-cn/docs/user/demos/fault-tolerent-strategy.html) 中，我们可以看到 Dubbo 内置 6 种负载均衡策略。其中，默认使用 `failover` 失败自动重试其他服务的策略。
+
+**Failover Cluster**
+
+失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。可通过 `retries="2"` 来设置重试次数(不含第一次)。
+
+**Failfast Cluster**
+
+快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。
+
+**Failsafe Cluster**
+
+失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。
+
+**Failback Cluster**
+
+失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。
+
+**Forking Cluster**
+
+并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 `forks="2"` 来设置最大并行数。
+
+**Broadcast Cluster**
+
+广播调用所有提供者，逐个调用，任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息。
+
+## Dubbo 有哪些动态代理策略？
+
+> 对应【proxy 服务代理层】。
+
+可能有胖友对动态代理不是很了解。因为，Consumer 仅仅引用服务 `***-api.jar` 包，那么可以获得到需要服务的 XXXService 接口。那么，通过动态创建对应调用 Dubbo 服务的实现类。简化代码如下：
+
+```
+// ProxyFactory.java
+
+/**
+ * create proxy.
+ *
+ * 创建 Proxy ，在引用服务调用。
+ *
+ * @param invoker Invoker 对象
+ * @return proxy
+ */
+@Adaptive({Constants.PROXY_KEY})
+<T> T getProxy(Invoker<T> invoker) throws RpcException;
+```
+
+- 方法参数 `invoker` ，实现了调用 Dubbo 服务的逻辑。
+- 返回的 `<T>` 结果，就是 XXXService 的实现类，而这个实现类，就是通过动态代理的**工具类**进行生成。
+
+通过动态代理的方式，实现了对于我们开发使用 Dubbo 时，透明的效果。当然，因为实际场景下，我们是结合 Spring 场景在使用，所以不会直接使用该 API 。
+
+------
+
+目前实现动态代理的**工具类**还是蛮多的，如下：
+
+- Javassist
+- JDK *原生自带*
+- CGLIB
+- ASM
+
+其中，Dubbo 动态代理使用了 Javassist 和 JDK 两种方式。
+
+- 默认情况下，使用 Javassist 。
+- 可通过 SPI 机制，切换使用 JDK 的方式。
+
+**为什么默认使用 Javassist？**
+
+在 Dubbo 开发者【梁飞】的博客 [《动态代理方案性能对比》](https://javatar.iteye.com/blog/814426) 中，我们可以看到这几种方式的性能差异，而 Javassit 排在第一。也就是说，因为**性能**的原因。
+
+有一点需要注意，Javassit 提供**字节码** bytecode 生成方式和动态代理接口两种方式。后者的性能比 JDK 自带的还慢，所以 Dubbo 使用的是前者**字节码** bytecode 生成方式。
+
+**那么是不是 JDK 代理就没意义？**
+
+实际上，JDK 代理在 JDK 1.8 版本下，性能已经有很大的提升，并且无需引入三方工具的依赖，也是非常棒的选择。所以，Spring 和 Motan 在动态代理生成上，优先选择 JDK 代理。
+
+> 注意，Spring 同时也选择了 CGLIB 作为生成动态代理的工具之一。
+
+------
+
+更多的内容，非常推荐阅读徐妈的 [《深入理解 RPC 之动态代理篇》](http://www.iocoder.cn/RPC/laoxu/rpc-dynamic-proxy/) 。很棒！
+
+## Dubbo SPI 的设计思想是什么？
+
+首先的首先，我们得来理解 Java SPI 是什么？因为徐妈在这块已经写了非常非常非常不错的文章，我们直接**认真**，一定要**认真**看 [《JAVA 拾遗 —— 关于 SPI 机制》](http://www.iocoder.cn/Fight/xuma/spi/) 。
+
+那么既然 Java SPI 机制已经这么牛逼，为什么 Dubbo 还要自己实现 Dubbo SPI 机制呢？良心的 Dubbo 在 [《Dubbo 开发指南 —— 扩展点加载》](http://dubbo.apache.org/zh-cn/docs/dev/SPI.html) 中，给出了答案：
+
+- 1、JDK 标准的 SPI 会一次性实例化扩展点所有实现，如果有扩展实现初始化很耗时，但如果没用上也加载，会很浪费资源。
+- 2、如果扩展点加载失败，连扩展点的名称都拿不到了。比如：JDK 标准的 ScriptEngine，通过 getName() 获取脚本类型的名称，但如果 RubyScriptEngine 因为所依赖的 jruby.jar 不存在，导致 RubyScriptEngine 类加载失败，这个失败原因被吃掉了，和 ruby 对应不起来，当用户执行 ruby 脚本时，会报不支持 ruby，而不是真正失败的原因。
+- 3、增加了对扩展点 IoC 和 AOP 的支持，一个扩展点可以直接 setter 注入其它扩展点。
+
+什么意思呢？
+
+- 第一点问题，Dubbo 有很多的拓展点，例如 Protocol、Filter 等等。并且每个拓展点有多种的实现，例如 Protocol 有 DubboProtocol、InjvmProtocol、RestProtocol 等等。那么使用 JDK SPI 机制，会初始化无用的拓展点及其实现，造成不必要的耗时与资源浪费。
+- 第二点问题，因为没用过 ScriptEngine ，所以看不懂，哈哈哈哈。
+- 第三点问题，严格来说，这不算问题，**而是增加了功能特性**，更多的提现是，Dubbo SPI 提供类似 Spring IoC 和 AOP 的功能。
+
+如果如果如果想要深入理解 Dubbo SPI 体系，胖友可以阅读 [《精尽 Dubbo 源码分析 —— 拓展机制 SPI》](http://svip.iocoder.cn/Dubbo/spi) 。艿话说的好，读懂 Dubbo SPI 的源码，你就读懂了一半 Dubbo 的源码。
+
+如果说，胖友想要自定义一个 Dubbo SPI 某个拓展点的实现，可以阅读 [《Dubbo 开发指南 —— 扩展点加载》](http://dubbo.apache.org/zh-cn/docs/dev/SPI.html) 。当然，如果你是首次写，可能会有一丢丢复杂。实际场景下，我们写的最多的是 [Filter 调用拦截扩展](http://dubbo.apache.org/zh-cn/docs/dev/impls/filter.html) 。所以，撸起袖子，来一发！
+
+------
+
+当然，虽然 Dubbo 实现了 Dubbo SPI ，这并意味着 Java SPI 不好用。实际上，Java SPI 被大量中间件所采用，例如 Tomcat、SkyWalking、JDBC 等等。
+
+------
+
+再引申下，有些刁钻的面试官，可能会让你先讲讲 Spring IoC 是如何实现的，Dubbo SPI 是怎么提供 IoC 功能的，那么你可以看看如下两篇文章来准备：
+
+- Spring IoC ，[《面试问烂的 Spring IoC 过程》](http://www.iocoder.cn/Fight/Interview-poorly-asked-Spring-IOC-process-1/) 。
+- Dubbo SPI IoC ，[《Dubbo SPI 机制和 IoC》](https://segmentfault.com/a/1190000014698351#articleHeader12) 的 [「IOC 注入」](https://svip.iocoder.cn/Dubbo/Interview/部分)。
+
+再再引申下，有些刁钻的面试官，可能会让你先讲讲 Spring AOP 是如何实现的，Dubbo SPI 是怎么提供 AOP 功能的，那么你可以看看如下两篇文章来准备：
+
+- Spring AOP ，[《面试问烂的 Spring AOP 原理》](http://www.iocoder.cn/Fight/Interview-poorly-asked-Spring-AOP-principles/) 。
+
+- Dubbo SPI AOP ，详细见 [《精尽 Dubbo 源码分析 —— 拓展机制 SPI》](http://svip.iocoder.cn/Dubbo/spi) 文章。核心源码是：
+
+  ```
+  private static final ConcurrentMap<Class<?>, Object> EXTENSION_INSTANCES = new ConcurrentHashMap<Class<?>, Object>();
+      
+    1: 
+    7: @SuppressWarnings("unchecked")
+    8: private T createExtension(String name) {
+    9:     // 获得拓展名对应的拓展实现类
+   10:     Class<?> clazz = getExtensionClasses().get(name);
+   11:     if (clazz == null) {
+   12:         throw findException(name); // 抛出异常
+   13:     }
+   14:     try {
+   15:         // 从缓存中，获得拓展对象。
+   16:         T instance = (T) EXTENSION_INSTANCES.get(clazz);
+   17:         if (instance == null) {
+   18:             // 当缓存不存在时，创建拓展对象，并添加到缓存中。
+   19:             EXTENSION_INSTANCES.putIfAbsent(clazz, clazz.newInstance());
+   20:             instance = (T) EXTENSION_INSTANCES.get(clazz);
+   21:         }
+   22:         // 注入依赖的属性
+   23:         injectExtension(instance);
+   24:         // 创建 Wrapper 拓展对象
+   25:         Set<Class<?>> wrapperClasses = cachedWrapperClasses;
+   26:         if (wrapperClasses != null && !wrapperClasses.isEmpty()) {
+   27:             for (Class<?> wrapperClass : wrapperClasses) {
+   28:                 instance = injectExtension((T) wrapperClass.getConstructor(type).newInstance(instance));
+   29:             }
+   30:         }
+   31:         return instance;
+   32:     } catch (Throwable t) {
+   33:         throw new IllegalStateException("Extension instance(name: " + name + ", class: " +
+   34:                 type + ")  could not be instantiated: " + t.getMessage(), t);
+   35:     }
+   36: }
+  ```
+
+  - 第 24 至 30 行：创建 Wrapper 拓展对象，将 `instance` **包装在其中**。在 [《Dubbo 开发指南 —— 扩展点加载》](https://dubbo.gitbooks.io/dubbo-dev-book/SPI.html) 文章中，如此介绍 Wrapper 类：
+
+    > Wrapper 类同样实现了扩展点接口，但是 Wrapper 不是扩展点的真正实现。它的用途主要是用于从 ExtensionLoader 返回扩展点时，包装在真正的扩展点实现外。即从 ExtensionLoader 中返回的实际上是 Wrapper 类的实例，Wrapper 持有了实际的扩展点实现类。
+    >
+    > 扩展点的 Wrapper 类可以有多个，也可以根据需要新增。
+    >
+    > 通过 Wrapper 类可以把所有扩展点公共逻辑移至 Wrapper 中。新加的 Wrapper 在所有的扩展点上添加了逻辑，有些类似 AOP，即 Wrapper 代理了扩展点。
+    >
+    > - 例如：[ListenerExporterWrapper](https://github.com/YunaiV/dubbo/blob/6b8e51ac55880a0f10a34f297d0869fcdbb42369/dubbo-rpc/dubbo-rpc-api/src/main/java/com/alibaba/dubbo/rpc/listener/ListenerExporterWrapper.java)、[ProtocolFilterWrapper](https://github.com/YunaiV/dubbo/blob/6b8e51ac55880a0f10a34f297d0869fcdbb42369/dubbo-rpc/dubbo-rpc-api/src/main/java/com/alibaba/dubbo/rpc/protocol/ProtocolFilterWrapper.java) 。
+
+## Dubbo 服务如何监控和管理？
+
+一旦使用 Dubbo 做了服务化后，必须必须必须要做的**服务治理**，也就是说，要做服务的管理与监控。当然，还有服务的降级和限流。这块，放在下面的面试题，在详细解析。
+
+**Dubbo 管理平台 + 监控平台**
+
+- `dubbo-monitor` 监控平台，基于 Dubbo 的【monitor 监控层】，实现相应的监控数据的收集到监控平台。
+- `dubbo-admin` 管理平台，基于注册中心，可以获取到服务相关的信息。
+
+关于这块的选择，胖友直接看看 [《Dubbo监控和管理（dubbokeeper）》](https://www.jianshu.com/p/a022e1305e66) 。
+
+另外，目前 Dubbo 正在重做 `dubbo-admin` 管理平台，感兴趣的胖友，可以跟进 https://github.com/apache/incubator-dubbo-ops 。
+
+**链路追踪**
+
+关链路追踪的概念，就不重复介绍了，😈 如果不懂，请自行 Google 下。
+
+目前能够实现链路追踪的组件还是比较多的，如下：
+
+- Apache SkyWalking 【推荐】
+- Zipkin
+- Cat
+- PinPoint
+
+具体集成的方式，Dubbo 官方推荐了两篇博文：
+
+- [《使用 Apache SkyWalking (Incubator) 做分布式跟踪》](http://www.iocoder.cn/SkyWalking/How-do-I-use-Skywalking-to-do-tracking-for-the-Dubbo-service)
+- [《在 Dubbo 中使用 Zipkin》](http://dubbo.apache.org/zh-cn/blog/use-zipkin-in-dubbo.html)
+
+## Dubbo 服务如何做降级？
+
+比如说服务 A 调用服务 B，结果服务 B 挂掉了。服务 A 再重试几次调用服务 B，还是不行，那么直接降级，走一个备用的逻辑，给用户返回响应。
+
+在 Dubbo 中，实现服务降级的功能，一共有两大种方式。
+
+**① Dubbo 原生自带的服务降级功能**
+
+具体可以看看 [《Dubbo 用户指南 —— 服务降级》](http://dubbo.apache.org/zh-cn/docs/user/demos/service-downgrade.html) 。
+
+当然，这个功能，并不能实现现代微服务的**熔断器**的功能。所以一般情况下，不太推荐这种方式，而是采用第二种方式。
+
+**② 引入支持服务降级的组件**
+
+目前开源社区常用的有两种组件支持服务降级的功能，分别是：
+
+- Alibaba Sentinel
+- Netflix Hystrix
+
+因为目前 Hystrix 已经停止维护，并且和 Dubbo 的集成度不是特别高，需要做二次开发，所以推荐使用 Sentinel 。具体的介绍，胖友可以看看 [《Sentinel 介绍》](https://github.com/alibaba/Sentinel/wiki/介绍) 。
+
+关于 Dubbo 如何集成 Sentinel ，胖友可以阅读 [《Sentinel 为 Dubbo 服务保驾护航》](http://www.iocoder.cn/Sentinel/all/sentinel-introduction-for-dubbo/) 一文。
+
+关于 Sentinel 和 Hystrix 对比，胖友可以阅读 [《Sentinel 与 Hystrix 的对比》](http://www.iocoder.cn/Sentinel/all/Sentinel-and-Hystrix/) 一文。
+
+## Dubbo 如何做限流？
+
+在做服务稳定性时，有一句非常经典的话：
+
+- 怀疑第三方
+- 防备使用方
+- 做好自己
+
+那么，上面看到的服务降级，就属于怀疑第三方。
+而本小节的限流目的，就是防备使用方。
+
+此处，艿艿要再推荐一篇文章：[《你应该如何正确健壮后端服务？》](http://www.iocoder.cn/Fight/How-do-you-robust-back-end-services/) 。
+
+------
+
+目前，在 Dubbo 中，实现服务降级的功能，一共有两大种方式。
+
+**① Dubbo 原生自带的限流功能**
+
+通过 TpsLimitFilter 实现，仅适用于服务提供者。具体的使用方式，源码实现，看看 [《精尽 Dubbo 源码分析 —— 过滤器（九）之 TpsLimitFilter》](http://svip.iocoder.cn/Dubbo/filter-limit-filter/) 。
+
+😈 参照 TpsLimitFilter 的思路，可以实现自定义限流的 Filter ，并且使用 Guava RateLimiter 工具类，达到 [令牌桶算法限流](https://svip.iocoder.cn/Dubbo/Interview/令牌桶算法限流) 的功能。
+
+**② 引入支持限流的组件**
+
+关于这个功能，还是推荐集成 Sentinel 组件。
+
+## Dubbo 的失败重试是什么？
+
+所谓失败重试，就是 consumer 调用 provider 要是失败了，比如抛异常了，此时应该是可以重试的，或者调用超时了也可以重试。
+
+实际场景下，我们一般会**禁用掉重试**。因为，因为超时后重试会有问题，超时你不知道是成功还是失败。例如，可能会导致两次扣款的问题。
+
+所以，我们一般使用 failfast 集群容错策略，而不是 failover 策略。配置如下：
+
+```
+<dubbo:service cluster="failfast" timeout="2000" />
+```
+
+另外，一定一定一定要配置适合自己业务的**超时时间**。
+
+当然，可以将操作分成**读**和**写**两种，前者支持重试，后者不支持重试。因为，**读**操作天然具有幂等性。
+
+## Dubbo 支持哪些注册中心？
+
+Dubbo 支持多种主流注册中心，如下：
+
+- 【默认】Zookeeper ，参见 [《用户指南 —— Zookeeper 注册中心》](http://dubbo.apache.org/zh-cn/docs/user/references/registry/zookeeper.html) 。
+- Redis ，参见 [《用户指南 —— Redis 注册中心》](http://dubbo.apache.org/zh-cn/docs/user/references/registry/redis.html) 。
+- Multicast 注册中心，参见 [《用户指南 —— Multicast 注册中心》](http://dubbo.apache.org/zh-cn/docs/user/references/registry/multicast.html) 。
+- Simple 注册中心，参见 [《用户指南 —— Simple 注册中心》](http://dubbo.apache.org/zh-cn/docs/user/references/registry/simple.html) 。
+
+目前 Alibaba 正在开源新的注册中心 [Nacos](https://nacos.io/zh-cn/) ，也是未来的选择之一。
+
+当然，Netflix Eureka 也是注册中心的一个选择，不过 Dubbo 暂未集成实现。
+
+另外，此处会引申一个经典的问题，见 [《为什么不应该使用 ZooKeeper 做服务发现》](http://dockone.io/article/78) 文章。
+
+\##
+
+## Dubbo 接口如何实现幂等性？
+
+> 所谓幂等，简单地说，就是对接口的多次调用所产生的结果和调用一次是一致的。扩展一下，这里的接口，可以理解为对外发布的 HTTP 接口或者 Thrift 接口，也可以是接收消息的内部接口，甚至是一个内部方法或操作。
+>
+> 那么我们为什么需要接口具有幂等性呢？设想一下以下情形：
+>
+> - 在 App 中下订单的时候，点击确认之后，没反应，就又点击了几次。在这种情况下，如果无法保证该接口的幂等性，那么将会出现重复下单问题。
+> - 在接收消息的时候，消息推送重复。如果处理消息的接口无法保证幂等，那么重复消费消息产生的影响可能会非常大。
+
+所以，从这段描述中，幂等性不仅仅是 Dubbo 接口的问题，包括 HTTP 接口、Thrift 接口都存在这样的问题，甚至说 MQ 消息、定时任务，都会碰到这样的场景。那么应该怎么办呢？
+
+> 这个不是技术问题，这个没有通用的一个方法，这个应该**结合业务**来保证幂等性。
+>
+> 所谓**幂等性**，就是说一个接口，多次发起同一个请求，你这个接口得保证结果是准确的，比如不能多扣款、不能多插入一条数据、不能将统计值多加了 1。这就是幂等性。
+>
+> 其实保证幂等性主要是三点：
+>
+> - 对于每个请求必须有一个唯一的标识，举个栗子：订单支付请求，肯定得包含订单 id，一个订单 id 最多支付一次，对吧。
+> - 每次处理完请求之后，必须有一个记录标识这个请求处理过了。常见的方案是在 mysql 中记录个状态啥的，比如支付之前记录一条这个订单的支付流水。
+> - 每次接收请求需要进行判断，判断之前是否处理过。比如说，如果有一个订单已经支付了，就已经有了一条支付流水，那么如果重复发送这个请求，则此时先插入支付流水，orderId 已经存在了，唯一键约束生效，报错插入不进去的。然后你就不用再扣款了。
+>
+> 实际运作过程中，你要结合自己的业务来，比如说利用 redis，用 orderId 作为唯一键。只有成功插入这个支付流水，才可以执行实际的支付扣款。
+>
+> 要求是支付一个订单，必须插入一条支付流水，order_id 建一个唯一键 `unique key`。你在支付一个订单之前，先插入一条支付流水，order_id 就已经进去了。你就可以写一个标识到 redis 里面去，`set order_id payed`，下一次重复请求过来了，先查 redis 的 order_id 对应的 value，如果是 `payed` 就说明已经支付过了，你就别重复支付了。
+
+## Dubbo 如何升级接口？
+
+参考 [《Dubbo 用户指南 —— 多版本》](http://dubbo.apache.org/zh-cn/docs/user/demos/multi-versions.html) 。
+
+当一个接口实现，出现不兼容升级时，**可以用版本号过渡**，版本号不同的服务相互间不引用。
+
+可以按照以下的步骤进行版本迁移：
+
+1. 在低压力时间段，先升级一半提供者为新版本。
+2. 再将所有消费者升级为新版本。
+3. 然后将剩下的一半提供者升级为新版本。
+
+利用多版本的特性，我们也能实现灰度的功能。对于第 2 步，不要升级所有消费者为新版本，而是一半。
+
+## Dubbo 在安全机制方面是如何解决的？
+
+通过令牌验证在**注册中心**控制权限，以决定要不要下发令牌给消费者，可以防止消费者绕过注册中心访问提供者。
+
+另外通过注册中心可灵活改变授权方式，而不需修改或升级提供者。
+
+[![认证流程](02-Dubbo 面试题.assets/01-17182492529965.png)](http://static.iocoder.cn/images/Dubbo/2018_11_19/01.png)认证流程
+
+相关文档，可以参见 [《Dubbo 用户指南 —— 令牌验证》](http://dubbo.apache.org/zh-cn/docs/user/demos/token-authorization.html) 。
+
+源码解析，可以参见 [《精尽 Dubbo 源码分析 —— 过滤器（八）之 TokenFilter》](http://svip.iocoder.cn/Dubbo/filter-token-filter) 。
+
+## Dubbo 需要 Web 容器吗？
+
+这个问题，仔细回答，需要思考 Web 容器的定义。然而实际上，真正想问的是，Dubbo 服务启动是否需要启动类似 Tomcat、Jetty 等服务器。
+
+这个答案可以是，也可以是不是。为什么呢？根据协议的不同，Provider 会启动不同的服务器。
+
+- 在使用 `dubbo://` 协议时，答案是**否**，因为 Provider 启动 Netty、Mina 等 NIO Server 。
+- 在使用 `rest://` 协议时，答案是**是**，Provider 启动 Tomcat、Jetty 等 HTTP 服务器，或者也可以使用 Netty 封装的 HTTP 服务器。
+- 在使用 `hessian://` 协议时，答案是**是**，Provider 启动 Jetty、Tomcat 等 HTTP 服务器。
+
+## 为什么要将系统进行拆分？
+
+这个问题，不是仅仅适用于 Dubbo 的场景，而是 SOA、微服务。
+
+> 网上查查，答案极度零散和复杂，很琐碎，原因一大坨。但是我这里给大家直观的感受：
+>
+> 要是**不拆分**，一个大系统几十万行代码，20 个人维护一份代码，简直是悲剧啊。代码经常改着改着就冲突了，各种代码冲突和合并要处理，非常耗费时间；经常我改动了我的代码，你调用了我的，导致你的代码也得重新测试，麻烦的要死；然后每次发布都是几十万行代码的系统一起发布，大家得一起提心吊胆准备上线，几十万行代码的上线，可能每次上线都要做很多的检查，很多异常问题的处理，简直是又麻烦又痛苦；而且如果我现在打算把技术升级到最新的 spring 版本，还不行，因为这可能导致你的代码报错，我不敢随意乱改技术。
+>
+> 假设一个系统是 20 万行代码，其中 小A 在里面改了 1000 行代码，但是此时发布的时候是这个 20 万行代码的大系统一块儿发布。就意味着 20 万上代码在线上就可能出现各种变化，20 个人，每个人都要紧张地等在电脑面前，上线之后，检查日志，看自己负责的那一块儿有没有什么问题。
+>
+> 小A 就检查了自己负责的 1 万行代码对应的功能，确保ok就闪人了；结果不巧的是，小A 上线的时候不小心修改了线上机器的某个配置，导致另外 小B 和 小C 负责的 2 万行代码对应的一些功能，出错了。
+>
+> 几十个人负责维护一个几十万行代码的单块应用，每次上线，准备几个礼拜，上线 -> 部署 -> 检查自己负责的功能。
+>
+> **拆分了以后**，整个世界清爽了，几十万行代码的系统，拆分成 20 个服务，平均每个服务就 1~2 万行代码，每个服务部署到单独的机器上。20 个工程，20 个 git 代码仓库里，20 个码农，每个人维护自己的那个服务就可以了，是自己独立的代码，跟别人没关系。再也没有代码冲突了，爽。每次就测试我自己的代码就可以了，爽。每次就发布我自己的一个小服务就可以了，爽。技术上想怎么升级就怎么升级，保持接口不变就可以了，爽。
+>
+> 所以简单来说，一句话总结，如果是那种代码量多达几十万行的中大型项目，团队里有几十个人，那么如果不拆分系统，**开发效率极其低下**，问题很多。但是拆分系统之后，每个人就负责自己的一小部分就好了，可以随便玩儿随便弄。分布式系统拆分之后，可以大幅度提升复杂系统大型团队的开发效率。
+>
+> 但是同时，也要**提醒**的一点是，系统拆分成分布式系统之后，大量的分布式系统面临的问题也是接踵而来，所以后面的问题都是在**围绕分布式系统带来的复杂技术挑战**在说。
+
+艿艿曾经维护过一个几十万行的单体项目，并且基本是一天发布 2-3 次，期间的痛苦，简直了。
+
+## Dubbo 如何集成配置中心？
+
+对于使用了 Dubbo 的系统，配置分成两类：
+
+- ① Dubbo 自身配置。
+  - 例如：Dubbo 请求超时，Dubbo 重试次数等等。
+- ② 非 Dubbo 自身配置
+  - 基建配置，例如：数据库、Redis 等配置。
+  - 业务配置，例如：订单超时时间，下单频率等等配置。
+
+对于 ① ，如果我们在 Provider 配置 Dubbo 请求超时时间，当 Consumer 未配置请求超时时间，会继承该配置，使用该请求超时时间。
+
+- 实现原理：
+  - Provider 启动时，会注册到注册中心中，包括我们在 [``](http://dubbo.apache.org/zh-cn/docs/user/references/xml/dubbo-service.html) 中的配置。
+  - Consumer 启动时，从注册中心获取到 Provider 列表后，会合并它们在 `<dubbo:service />` 的配置来使用。当然，如果 Consumer 自己配置了该配置项，则使用自身的。例如说，Provider 配置了请求超时时间是 10s ，而 Consumer 配置了请求超时超时是 5s ，那么最终 Consumer 请求超时的时间是 5s 。
+  - 绝大数配置可以被继承，合并的核心逻辑，见 [`ClusterUtils#mergeUrl(URL remoteUrl, Map localMap)`](https://github.com/apache/incubator-dubbo/blob/master/dubbo-cluster/src/main/java/org/apache/dubbo/rpc/cluster/support/ClusterUtils.java#L35-L122) 方法。
+- 实现代码，见 [《精尽 Dubbo 源码解析 —— 集群容错（六）之 Configurator 实现》](http://svip.iocoder.cn/Dubbo/cluster-6-impl-configurator/) 。
+
+对于 ② ，市面上有非常多的配置中心可供选择：
+
+- Apollo
+- Nacos
+- Disconf
+
+这个问题不大。对于配置中心的选择，我们考虑的不是它和 Dubbo 的集成，而是它和 Spring 的集成。因为，大多数情况下，我们都是使用 Spring 作为框架的整合基础。目前，Apollo 和 Nacos 对 Spring 的支持是比较不错的。
+
+## Dubbo 如何实现分布式事务？
+
+首先，关于分布式事务的功能，不是 Dubbo 作为服务治理框架需要去实现的，所以 Dubbo 本身并没有实现。所以在 [《Dubbo 用户指南 —— 分布式事务》](http://dubbo.apache.org/zh-cn/docs/user/demos/distributed-transaction.html) 也提到，目前并未实现。
+
+说起分布式，理论的文章很多，落地的实践很少。笔者翻阅了各种分布式事务组件的选型，大体如下：
+
+- TCC 模型：TCC-Transaction、Hmily
+- XA 模型：Sharding Sphere、MyCAT
+- 2PC 模型：raincat、lcn
+- MQ 模型：RocketMQ
+- BED 模型：Sharding Sphere
+- Saga 模型：ServiceComb Saga
+
+那怎么选择呢？目前社区对于分布式事务的选择，暂时没有定论，至少笔者没有看到。笔者的想法如下：
+
+- 从覆盖场景来说，TCC 无疑是最优秀的，但是大家觉得相对复杂。实际上，复杂场景下，使用 TCC 来实现，反倒会容易很多。另外，TCC 模型，一直没有大厂开源，也是一大痛点。
+- 从使用建议来说，MQ 可能是相对合适的( 不说 XA 的原因还是性能问题 )，并且基本轮询了一圈朋友，发现大多都是使用 MQ 实现最终一致性居多。
+- 2PC 模型的实现，笔者觉得非常新奇，奈何隔离性是一个硬伤。
+- Saga 模型，可以认为是 TCC 模型的简化版，所以在理解和编写的难度上，简单非常多。
+
+所以结论是什么呢？
+
+- TCC 模型：TCC-Transaction、Hmily 。
+  - 已经提供了和 Dubbo 集成的方案，胖友可以自己去试试。
+- XA 模型：Sharding Sphere、MyCAT 。
+  - 无需和 Dubbo 进行集成。
+- 2PC 模型：raincat、lcn 。
+  - 已经提供了和 Dubbo 集成的方案，胖友可以自己去试试。
+- MQ 模型：RocketMQ 。
+  - 无需和 Dubbo 进行集成。
+- BED 模型：Sharding Sphere 。
+  - 无需和 Dubbo 进行集成。
+- Saga 模型：ServiceComb Saga 。
+  - **好像**已经提供了和 Dubbo 集成的方案，参见 [《Saga-dubbo-demo》](https://github.com/apache/servicecomb-pack/blob/64d8cfdfb9e0c8362e962eb17765b57ae2211c84/saga-demo/saga-dubbo-demo/README.md) 文档。
+  - 😈 暂时没去深入研究。
+
+另外，胖友在理解分布式事务时，一定要记住，分布式事务需要由多个**本地**事务组成。无论是上述的那种事务组件模型，它们都是扮演一个**协调者**，使多个**本地**事务达到最终一致性。而协调的过程中，就非常依赖每个方法操作可以被重复执行不会产生副作用，那么就需要：
+
+- 幂等性！因为可能会被重复调用。如果调用两次退款，结果退了两次钱，那就麻烦大了。
+- 本地事务！因为执行过程中可能会出错，需要回滚。
+
+## Dubbo 如何集成网关服务？
+
+Dubbo 如何集成到网关服务，需要思考两个问题：
+
+- 网关如何**调用** Dubbo 服务。
+- 网关如何**发现** Dubbo 服务。
+
+我们先来看看，市面上有哪些网关服务：
+
+- Zuul
+- Spring Cloud Gateway
+- Kong
+
+如上三个解决方案，都是基于 HTTP 调用后端的服务。那么，这样的情况下，Dubbo 只能通过暴露 `rest://` 协议的服务，才能被它们调用。
+
+那么 Dubbo 的 `rest://` 协议的服务，怎么能够被如上三个解决方案注册发现呢？
+
+- 因为 Dubbo 可用的注册中心有 Zookeeper ，如果要被 Zuul 或 Spring Cloud Gateway 注册发现，可以使用 `spring-cloud-starter-zookeeper-discovery` 库。具体可参见 [《Service Discovery with Zookeeper》](https://cloud.spring.io/spring-cloud-zookeeper/1.2.x/multi/multi_spring-cloud-zookeeper-discovery.html) 文章。
+- Dubbo 与 Kong 的集成，相对比较麻烦，需要通过 Kong 的 API 添加相应的路由规则。具体可参见 [《选择 Kong 作为你的 API 网关》](https://www.cnkirito.moe/kong-introduction/) 文章。
+
+可能会有胖友问，有没支持 `dubbo://` 协议的网关服务呢？目前有新的网关开源 [Soul](https://dromara.org/website/zh-cn/docs/soul/soul.html) ，基于 Dubbo 泛化调用的特性，实现对 `dubbo://` 协议的 Dubbo 服务的调用。
+
+- 感兴趣的胖友，可以去研究下。
+- 关于 Dubbo 泛化调用的特性，胖友可以看看 [《Dubbo 用户指南 —— 使用泛化调用》](http://dubbo.apache.org/zh-cn/docs/user/demos/generic-reference.html) 。
+
+实际场景下，我们真的需要 Dubbo 集成到网关吗？具艿艿了解到，很多公司，并未使用网关，而是使用 Spring Boot 搭建一个 Web 项目，引入 `*-api.jar` 包，然后进行调用，从而对外暴露 HTTP API 。
+
+## 如何进行系统拆分？
+
+这个问题，不是仅仅适用于 Dubbo 的场景，而是 SOA、微服务。接上面 [「为什么要将系统进行拆分？」](https://svip.iocoder.cn/Dubbo/Interview/#) 。
+
+> 这个问题说大可以很大，可以扯到领域驱动模型设计上去，说小了也很小，我不太想给大家太过于学术的说法，因为你也不可能背这个答案，过去了直接说吧。还是说的简单一点，大家自己到时候知道怎么回答就行了。
+>
+> 系统拆分为分布式系统，拆成多个服务，拆成微服务的架构，是需要拆很多轮的。并不是说上来一个架构师一次就给拆好了，而以后都不用拆。
+>
+> 第一轮；团队继续扩大，拆好的某个服务，刚开始是 1 个人维护 1 万行代码，后来业务系统越来越复杂，这个服务是 10 万行代码，5 个人；第二轮，1个服务 -> 5个服务，每个服务 2 万行代码，每人负责一个服务。
+>
+> 如果是多人维护一个服务，最理想的情况下，几十个人，1 个人负责 1 个或 2~3 个服务；某个服务工作量变大了，代码量越来越多，某个同学，负责一个服务，代码量变成了 10 万行了，他自己不堪重负，他现在一个人拆开，5 个服务，1 个人顶着，负责 5 个人，接着招人，2 个人，给那个同学带着，3 个人负责 5 个服务，其中 2 个人每个人负责 2 个服务，1 个人负责 1 个服务。
+>
+> 个人建议，一个服务的代码不要太多，1万行左右，两三万撑死了吧。
+>
+> 大部分的系统，是要进行**多轮拆分**的，第一次拆分，可能就是将以前的多个模块该拆分开来了，比如说将电商系统拆分成订单系统、商品系统、采购系统、仓储系统、用户系统，等等吧。
+>
+> 但是后面可能每个系统又变得越来越复杂了，比如说采购系统里面又分成了供应商管理系统、采购单管理系统，订单系统又拆分成了购物车系统、价格系统、订单管理系统。
+>
+> 扯深了实在很深，所以这里先给大家举个例子，你自己感受一下，**核心意思就是根据情况，先拆分一轮，后面如果系统更复杂了，可以继续分拆**。你根据自己负责系统的例子，来考虑一下就好了。
+
+## 拆分后不用 Dubbo 可以吗？
+
+当然是可以，方式还有很多：
+
+- 第一种，使用 Spring Cloud 技术体系，这个也是目前可能最主流的之一。
+- 第二种，Dubbo 换成 gRPC 或者 Thrift 。当然，此时要自己实现注册发现、负载均衡、集群容错等等功能。
+- 第三种，Dubbo 换成同等定位的服务化框架，例如微博的 Motan 、蚂蚁金服的 SofaRPC 。
+- 第四种，Spring MVC + Nginx 。
+- 第五种，每个服务拆成一个 Maven 项目，打成 Jar 包，给其它服务使用。😈 当然，这个不是一个比较特别的方案。
+
+> 当然可以了，大不了最次，就是各个系统之间，直接基于 spring mvc，就纯 http 接口互相通信呗，还能咋样。但是这个肯定是有问题的，因为 http 接口通信维护起来成本很高，你要考虑**超时重试**、**负载均衡**等等各种乱七八糟的问题，比如说你的订单系统调用商品系统，商品系统部署了 5 台机器，你怎么把请求均匀地甩给那 5 台机器？这不就是负载均衡？你要是都自己搞那是可以的，但是确实很痛苦。
+>
+> 所以 dubbo 说白了，是一种 rpc 框架，就是说本地就是进行接口调用，但是 dubbo 会代理这个调用请求，跟远程机器网络通信，给你处理掉负载均衡了、服务实例上下线自动感知了、超时重试了，等等乱七八糟的问题。那你就不用自己做了，用 dubbo 就可以了。
+
+## Spring Cloud 与 Dubbo 怎么选择？
+
+首先，我们来看看这两个技术栈在国内的流行程度，据艿艿了解到：
+
+- 对于国外，Spring Cloud 基本已经统一国外的微服务体系。
+- 对于国内，老的系统使用 Dubbo 较多，新的系统使用 Spring Cloud 较多。
+
+这样说起来，仿佛 Spring Cloud 和 Dubbo 是冲突的关系？！
+
+实际上，并不然。我们现在所使用的 Spring Cloud 技术体系，实际上是 Spring Cloud Netflix 为主，例如说：
+
+- Netflix Eureka 注册中心
+- Netflix Hystrix 熔断组件
+- Netflix Ribbon 负载均衡
+- Netflix Zuul 网关服务
+
+但是，开源的世界，总是这么有趣。目前 Alibaba 基于 Spring Cloud 的**接口**，对的是接口，实现了一套 [Spring Cloud Alibaba](https://github.com/spring-cloud-incubator/spring-cloud-alibaba) 技术体系，并且已经获得 Spring Cloud 的认可，处于孵化状态。组件如下：
+
+- Nacos 注册中心，对标 Eureka 。
+- Nacos 配置中心，集成到 Spring Cloud Config 。
+- Sentinel 服务保障，对标 Hystrix 。
+- Dubbo 服务调用( 包括负载均衡 )，对标 Ribbon + Feign 。
+- **缺失** 网关服务。
+- RocketMQ 队列服务，集成到 Spring Cloud Stream 。
+
+更多的讨论，胖友可以尾随知乎上的 [《请问哪位大神比较过 spring cloud 和 dubbo ，各自的优缺点是什么?》](https://www.zhihu.com/question/45413135) 。
+
+艿艿的个人态度上，还是非常看好 Spring Cloud Alibaba 技术体系的。为什么呢？因为 Alibaba 背后有阿里云的存在，提供开源项目和商业服务的统一。😈 这个，是 Netflix 所无法比拟的。例如说：
+
+| 开源项目 | 阿里云服务 |
+| :------- | :--------- |
+| Tengine  | LBS        |
+| Dubbo    | EDAS       |
+| RocketMQ | ONS        |
+
+这里在抛出一个话题。目前传说 Dubbo 在国外的接受度比较低，那么在 Spring Cloud Alibaba 成功孵化完后，是否能够杀入国外的市场呢？让我们拭目以待。
+
+**在聊一丢丢有意思的事情**。
+
+事实上，Netflix 已经基本不再维护 Eureka、Hystrix ，更有趣的是，因为网关的事情，Zuul 和 Spring Cloud 团队有点闹掰了，因而后来有了 Spring Cloud Gateway 。因而，Zuul2 后续在 Spring Cloud 体系中的情况，会非常有趣~
+
+另外，Spring Cloud 貌似也实现了一个 LoadBalance 负载均衡组件哟。
+
+## 如何自己设计一个类似 Dubbo 的 RPC 框架？
+
+**面试官心理分析**
+
+> 说实话，就这问题，其实就跟问你如何自己设计一个 MQ 一样的道理，就考两个：
+>
+> - 你有没有对某个 rpc 框架原理有非常深入的理解。
+> - 你能不能从整体上来思考一下，如何设计一个 rpc 框架，考考你的系统设计能力。
+
+**面试题剖析**
+
+> 其实问到你这问题，你起码不能认怂，因为是知识的扫盲，那我不可能给你深入讲解什么 kafka 源码剖析，dubbo 源码剖析，何况我就算讲了，你要真的消化理解和吸收，起码个把月以后了。
+>
+> 所以我给大家一个建议，遇到这类问题，起码从你了解的类似框架的原理入手，自己说说参照 dubbo 的原理，你来设计一下，举个例子，dubbo 不是有那么多分层么？而且每个分层是干啥的，你大概是不是知道？那就按照这个思路大致说一下吧，起码你不能懵逼，要比那些上来就懵，啥也说不出来的人要好一些。
+>
+> 举个栗子，我给大家说个最简单的回答思路：
+>
+> - 上来你的服务就得去注册中心注册吧，你是不是得有个注册中心，保留各个服务的信心，可以用 zookeeper 来做，对吧。
+> - 然后你的消费者需要去注册中心拿对应的服务信息吧，对吧，而且每个服务可能会存在于多台机器上。
+> - 接着你就该发起一次请求了，咋发起？当然是基于动态代理了，你面向接口获取到一个动态代理，这个动态代理就是接口在本地的一个代理，然后这个代理会找到服务对应的机器地址。
+> - 然后找哪个机器发送请求？那肯定得有个负载均衡算法了，比如最简单的可以随机轮询是不是。
+> - 接着找到一台机器，就可以跟它发送请求了，第一个问题咋发送？你可以说用 netty 了，nio 方式；第二个问题发送啥格式数据？你可以说用 hessian 序列化协议了，或者是别的，对吧。然后请求过去了。
+> - 服务器那边一样的，需要针对你自己的服务生成一个动态代理，监听某个网络端口了，然后代理你本地的服务代码。接收到请求的时候，就调用对应的服务代码，对吧。
+>
+> 这就是一个最最基本的 rpc 框架的思路，先不说你有多牛逼的技术功底，哪怕这个最简单的思路你先给出来行不行？
+
+如果上述描述，胖友看的比较闷逼，可以阅读下徐妈写的 [《简单了解 RPC 实现原理》](http://www.iocoder.cn/RPC/laoxu/easy-know-rpc/) ，自己动手撸一个最最最基础的 RPC 通信的过程。
+
+因为 Dubbo 实现了大量的抽象，并且提供了多种代码实现，以及大量的 RPC 特性，所以代码量会相对较多。
+
+如果胖友是自己实现一个最小化的 PRC 框架，可能代码量会比想象中的少很多，可能几千行代码就够了。强烈推荐，胖友自己撸起袖子，动起手来。从此之后，你会对 RPC 框架，有更深入的理解。
+
+## 其他问题
+
+当然，Dubbo 还有很多非常细节，甚至牵扯到源码的问题，艿艿并未全部列列举。如下的问题，需要胖友自己去耐心看源码，思考答案。
+
+- Dubbo 服务发布过程中，做了哪些事？
+  - [《精尽 Dubbo 源码分析 —— 服务暴露（一）之本地暴露（Injvm）》](http://svip.iocoder.cn/Dubbo/service-export-local/)
+  - [《精尽 Dubbo 源码分析 —— 服务暴露（二）之远程暴露（Dubbo）》](http://svip.iocoder.cn/Dubbo/service-export-remote-dubbo/)
+- Dubbo 服务引用过程中，做了哪些事？
+  - [《精尽 Dubbo 源码分析 —— 服务引用（一）之本地引用（Injvm）》](http://svip.iocoder.cn/Dubbo/reference-refer-local/)
+  - [《精尽 Dubbo 源码分析 —— 服务引用（二）之远程引用（Dubbo）》](http://svip.iocoder.cn/Dubbo/reference-refer-dubbo/)
+- Dubbo 管理平台能够动态改变接口的一些配置，其原理是怎样的?
+  - 路由规则
+    - [《精尽 Dubbo 源码解析 —— 集群容错（七）之 Router 实现》](http://svip.iocoder.cn/Dubbo/cluster-7-impl-router/)
+    - [《Dubbo 用户指南 —— 路由规则》](http://dubbo.apache.org/zh-cn/docs/user/demos/routing-rule.html)
+  - 配置规则
+    - [《精尽 Dubbo 源码解析 —— 集群容错（六）之 Configurator 实现》](http://svip.iocoder.cn/Dubbo/cluster-6-impl-configurator/)
+    - [《Dubbo 用户指南 —— 配置规则》](http://dubbo.apache.org/zh-cn/docs/user/demos/config-rule.html)
+- 在 Dubbo 中，什么时候更新本地的 Zookeeper 信息缓存文件？订阅Zookeeper 信息的整体过程是怎么样的?
+  - [《精尽 Dubbo 源码分析 —— 注册中心（一）之抽象 API》](http://svip.iocoder.cn/Dubbo/registry-api/)
+  - [《精尽 Dubbo 源码分析 —— 注册中心（二）之 Zookeeper》](http://svip.iocoder.cn/Dubbo/registry-zookeeper/)
+- 最小活跃数算法中是如何统计这个活跃数的？
+  - [《精尽 Dubbo 源码分析 —— 过滤器（四）之 ActiveLimitFilter && ExecuteLimitFilter》](http://svip.iocoder.cn/Dubbo/filter-method-limit-filter/) ，主要 [「2. 2. RpcStatus」](https://svip.iocoder.cn/Dubbo/Interview/#) 和 [「3. ActiveLimitFilter」](https://svip.iocoder.cn/Dubbo/Interview/#) 部分。
+  - [《精尽 Dubbo 源码解析 —— 集群容错（四）之 LoadBalance 实现》](http://svip.iocoder.cn/Dubbo/cluster-4-impl-loadbalance/) ，主要 [「6. LeastActiveLoadBalance」](https://svip.iocoder.cn/Dubbo/Interview/#) 部分。
+- 简单谈谈你对一致性哈希算法的认识？
+  - [《精尽 Dubbo 源码解析 —— 集群容错（四）之 LoadBalance 实现》](http://svip.iocoder.cn/Dubbo/cluster-4-impl-loadbalance/) ，主要 [「7. ConsistentHashSelector」](https://svip.iocoder.cn/Dubbo/Interview/#) 部分。
+  - 关于一致性哈希算法在缓存中的使用，我们会单独在缓存相关的面试题中分享。
+
+## 666. 彩蛋
+
+在看到此处，胖友有没发现，在实际面试的 Dubbo 问题中，Dubbo 官方文档已经给了我们很多答案。这说明什么呢？一定一定一定要认真研读官方提供的知识，毕竟，这是最系统，且第一手的资料。
+
+如果胖友想对 RPC 有一个整体的理解，推荐看看徐妈的这套文章《深入理解 RPC 系列》：
+
+- [《简单了解 RPC 实现原理》](http://www.iocoder.cn/RPC/laoxu/easy-know-rpc/)
+- [《深入理解 RPC 之序列化篇 – Kryo》](http://www.iocoder.cn/RPC/laoxu/rpc-serialize-1/)
+- [《深入理解 RPC 之序列化篇 – 总结篇》](http://www.iocoder.cn/RPC/laoxu/rpc-serialize-2/)
+- [《深入理解 RPC 之动态代理篇》](http://www.iocoder.cn/RPC/laoxu/rpc-dynamic-proxy/)
+- [《深入理解 RPC 之传输篇》](http://www.iocoder.cn/RPC/laoxu/rpc-transport/)
+- [《Motan 中使用异步 RPC 接口》](http://www.iocoder.cn/RPC/laoxu/motan-async/)
+- [《深入理解 RPC 之协议篇》](http://www.iocoder.cn/RPC/laoxu/rpc-protocol/)
+- [《深入理解RPC之服务注册与发现篇》](http://www.iocoder.cn/RPC/laoxu/rpc-registry/)
+- [《深入理解 RPC 之集群篇》](http://www.iocoder.cn/RPC/laoxu/rpc-cluster/)
+- [《【千米网】从跨语言调用到 dubbo2.js》](http://www.iocoder.cn/RPC/laoxu/dubbojs-in-qianmi/)
+- [《天池中间件大赛 Dubbo Mesh 优化总结（QPS 从 1000 到 6850）》](http://www.iocoder.cn/RPC/laoxu/dubboMesh/)
+
+参考与推荐如下文章：
+
+- [《Dubbo 用户指南》](http://dubbo.apache.org/zh-cn/docs/user/quick-start.html) 必选。
+- [《Dubbo 开发指南》](http://dubbo.apache.org/zh-cn/docs/dev/build.html) 进阶。
+- [《Dubbo 运维管理》](http://dubbo.apache.org/zh-cn/docs/admin/install/provider-demo.html) 可选。
+- [《分布式系统互斥性与幂等性问题的分析与解决》](https://tech.meituan.com/distributed_system_mutually_exclusive_idempotence_cerberus_gtis.html)
+- 黑马程序员 [《【上海校区】整理的 Dubbo 面试题》](https://blog.csdn.net/liyanlei5858/article/details/79236685)
+- 美团 [《说一下 Dubbo 的工作原理？注册中心挂了可以继续通信吗？》](https://github.com/doocs/advanced-java/blob/master/docs/distributed-system/dubbo-operating-principle.md)
+- lijiaccy [《Java 面试之 Dubbo》](https://www.jianshu.com/p/9d062eceb765)
+- Java 知音 [Dubbo 面试题](https://juejin.im/entry/5b3af5fd518825621d57791a)
+- [《Dubbo 支持哪些序列化协议？说一下 Hessian 的数据结构？PB 知道吗？为什么 PB 的效率是最高的？》](https://github.com/doocs/advanced-java/blob/master/docs/distributed-system/dubbo-serialization-protocol.md)
+- [《Dubbo 的 SPI 思想是什么？》](https://github.com/doocs/advanced-java/blob/master/docs/distributed-system/dubbo-spi.md)
+- [《如何基于 Dubbo 进行服务治理、服务降级、失败重试以及超时重试？》](https://github.com/doocs/advanced-java/blob/master/docs/distributed-system/dubbo-service-management.md)
+- [《分布式服务接口的幂等性如何设计（比如不能重复扣款）？》](https://github.com/doocs/advanced-java/blob/master/docs/distributed-system/distributed-system-idempotency.md)
+- [《为什么要进行系统拆分？如何进行系统拆分？拆分后不用 Dubbo 可以吗？》](https://github.com/doocs/advanced-java/blob/master/docs/distributed-system/why-dubbo.md)
+- [《如何自己设计一个类似 Dubbo 的 rpc 框架？》](https://github.com/doocs/advanced-java/blob/master/docs/distributed-system/dubbo-rpc-design.md)
\ No newline at end of file
diff --git a/面试题/03-Spring 面试题.assets/01.jpg b/面试题/03-Spring 面试题.assets/01.jpg
new file mode 100644
index 0000000..3a54ee5
Binary files /dev/null and b/面试题/03-Spring 面试题.assets/01.jpg differ
diff --git a/面试题/03-Spring 面试题.assets/02.jpg b/面试题/03-Spring 面试题.assets/02.jpg
new file mode 100644
index 0000000..82e742d
Binary files /dev/null and b/面试题/03-Spring 面试题.assets/02.jpg differ
diff --git a/面试题/03-Spring 面试题.assets/03.jpg b/面试题/03-Spring 面试题.assets/03.jpg
new file mode 100644
index 0000000..0ce47a2
Binary files /dev/null and b/面试题/03-Spring 面试题.assets/03.jpg differ
diff --git a/面试题/03-Spring 面试题.assets/04.jpg b/面试题/03-Spring 面试题.assets/04.jpg
new file mode 100644
index 0000000..4c8765f
Binary files /dev/null and b/面试题/03-Spring 面试题.assets/04.jpg differ
diff --git a/面试题/03-Spring 面试题.assets/05.jpg b/面试题/03-Spring 面试题.assets/05.jpg
new file mode 100644
index 0000000..91677da
Binary files /dev/null and b/面试题/03-Spring 面试题.assets/05.jpg differ
diff --git a/面试题/03-Spring 面试题.assets/06.png b/面试题/03-Spring 面试题.assets/06.png
new file mode 100644
index 0000000..c4bf9c9
Binary files /dev/null and b/面试题/03-Spring 面试题.assets/06.png differ
diff --git a/面试题/03-Spring 面试题.assets/07.png b/面试题/03-Spring 面试题.assets/07.png
new file mode 100644
index 0000000..21dcece
Binary files /dev/null and b/面试题/03-Spring 面试题.assets/07.png differ
diff --git a/面试题/03-Spring 面试题.assets/08.png b/面试题/03-Spring 面试题.assets/08.png
new file mode 100644
index 0000000..2a8fa1a
Binary files /dev/null and b/面试题/03-Spring 面试题.assets/08.png differ
diff --git a/面试题/03-Spring 面试题.assets/09.jpg b/面试题/03-Spring 面试题.assets/09.jpg
new file mode 100644
index 0000000..2acfa46
Binary files /dev/null and b/面试题/03-Spring 面试题.assets/09.jpg differ
diff --git a/面试题/03-Spring 面试题.md b/面试题/03-Spring 面试题.md
new file mode 100644
index 0000000..23cee01
--- /dev/null
+++ b/面试题/03-Spring 面试题.md	
@@ -0,0 +1,1416 @@
+# 精尽 Spring 面试题「最新更新时间：2024-02」
+
+以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。
+
+如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的 Spring 面试题的大保健。
+
+而题目的难度，艿艿尽量按照从容易到困难的顺序，逐步下去。
+
+> 注意 1 ，这个面试题，暂时不包括 Spring MVC 部分。主要以 Spring IoC、Spring AOP、Spring Transaction 为主。
+>
+> 注意 2 ，T T Spring 怎么会有这么多问题，艿艿自己面试很多都不太问，跟背书一样。所以整理的过程，真的是痛苦万分。
+
+Spring 是一个很庞大的技术体系，可以说包容一切，所以本文我们按照下面的顺序，罗列各种面试题：
+
+- Spring **整体**相关的面试
+- Spring **IoC** 相关的面试题
+- Spring **AOP** 相关的面试题
+- Spring **Transaction** 相关的面试题
+- Spring **Data Access** 相关的面试题
+
+# Spring 整体
+
+## 什么是 Spring Framework？
+
+Spring 是一个开源应用框架，旨在降低应用程序开发的复杂度。
+
+- 它是轻量级、松散耦合的。
+
+  > 它的轻量级主要是相对于 EJB 。随着 Spring 的体系越来越庞大，大家被 Spring 的配置搞懵逼了，所以后来出了 Spring Boot 。
+
+- 它具有分层体系结构，允许用户选择组件，同时还为 J2EE 应用程序开发提供了一个有凝聚力的框架。
+
+- 它可以集成其他框架，如 Spring MVC、Hibernate、MyBatis 等，所以又称为框架的框架( 粘合剂、脚手架 )。
+
+## Spring Framework 中有多少个模块，它们分别是什么？
+
+如下是一张比较早期版本的 Spring Framework 的模块图：
+
+> 艿艿：因为它的配色比较好看，哈哈哈哈。所以，没自己画一个最新的。
+
+[![Spring Framework](03-Spring 面试题.assets/01.jpg)](http://static.iocoder.cn/images/Spring/2018-12-24/01.jpg)Spring Framework
+
+我们按照一个一个分块来说。
+
+**Spring 核心容器**
+
+> 对应图中，Core Container 。
+
+该层基本上是 Spring Framework 的核心。它包含以下模块：
+
+- Spring Core
+
+- Spring Bean
+
+  > 核心容器提供 Spring 框架的基本功能。核心容器的主要组件是 BeanFactory，它是工厂模式的实现。BeanFactory 使用控制反转 （IOC）模式将应用程序的配置和依赖性规范与实际的应用程序代码分开。
+
+- Spring Context
+
+  > Spring 上下文是一个配置文件，向 Spring 框架提供上下文信息。Spring 上下文包括企业服务，例如 JNDI、EJB、电子邮件、国际化、事件机制、校验和调度功能。
+
+- SpEL (Spring Expression Language)
+
+  > Spring 表达式语言全称为 “Spring Expression Language”，缩写为 “SpEL” ，类似于 Struts2 中使用的 OGNL 表达式语言，能在运行时构建复杂表达式、存取对象图属性、对象方法调用等等，并且能与 Spring 功能完美整合，如能用来配置 Bean 定义。
+
+或者说，这块就是 Spring IoC 。
+
+**数据访问**
+
+> 对应图中，Data Access 。
+
+该层提供与数据库交互的支持。它包含以下模块：
+
+- JDBC (Java DataBase Connectivity)
+
+  > Spring 对 JDBC 的封装模块，提供了对关系数据库的访问。
+
+- ORM (Object Relational Mapping)
+
+  > Spring ORM 模块，提供了对 hibernate5 和 JPA 的集成。
+  >
+  > - hibernate5 是一个 ORM 框架。
+  > - JPA 是一个 Java 持久化 API 。
+
+- OXM (Object XML Mappers)
+
+  > Spring 提供了一套类似 ORM 的映射机制，用来将 Java 对象和 XML 文件进行映射。这就是 Spring 的对象 XML 映射功能，有时候也成为 XML 的序列化和反序列化。
+  >
+  > 用的比较少，胖友了解下即可。
+
+- Transaction
+
+  > Spring 简单而强大的事务管理功能，包括声明式事务和编程式事务。
+
+**Web**
+
+该层提供了创建 Web 应用程序的支持。它包含以下模块：
+
+- WebMVC
+
+  > MVC 框架是一个全功能的构建 Web 应用程序的 MVC 实现。通过策略接口，MVC 框架变成为高度可配置的，MVC 容纳了大量视图技术，其中包括 JSP、Velocity、Tiles、iText 和 POI。
+
+- WebFlux
+
+  > 基于 Reactive 库的响应式的 Web 开发框架
+  >
+  > 不了解的胖友，可以看看 [《使用 Spring 5 的 WebFlux 开发反应式 Web 应用》](https://www.ibm.com/developerworks/cn/java/spring5-webflux-reactive/index.html)
+
+- WebSocket
+
+  > Spring 4.0 的一个最大更新是增加了对 Websocket 的支持。
+  >
+  > Websocket 提供了一个在 Web 应用中实现高效、双向通讯，需考虑客户端(浏览器)和服务端之间高频和低延时消息交换的机制。
+  >
+  > 一般的应用场景有：在线交易、网页聊天、游戏、协作、数据可视化等。
+
+- ~~Portlet~~ 已经废弃
+
+**AOP**
+
+该层支持面向切面编程。它包含以下模块：
+
+- AOP
+
+  > 通过配置管理特性，Spring AOP 模块直接将面向方面的编程功能集成到了 Spring 框架中。所以，可以很容易地使 Spring 框架管理的任何对象支持 AOP。
+  >
+  > Spring AOP 模块为基于 Spring 的应用程序中的对象提供了事务管理服务。通过使用 Spring AOP，不用依赖 EJB 组件，就可以将声明性事务管理集成到应用程序中。
+
+- Aspects
+
+  > 该模块为与 AspectJ 的集成提供支持。
+
+- Instrumentation
+
+  > 该层为类检测和类加载器实现提供支持。
+  >
+  > 用的比较少，胖友了解下即可。
+
+**其它**
+
+- JMS (Java Messaging Service)
+
+  > 提供了一个 JMS 集成框架，简化了 JMS API 的使用。
+  >
+  > 可能有胖友不太了解 JMS ，可以看看 [《JMS(Java消息服务)入门教程》](https://www.cnblogs.com/chenpi/p/5559349.html) 。
+
+- Test
+
+  > 该模块为使用 JUnit 和 TestNG 进行测试提供支持。
+
+- Messaging
+
+  > 该模块为 STOMP 提供支持。它还支持注解编程模型，该模型用于从 WebSocket 客户端路由和处理 STOMP 消息。
+
+## 使用 Spring 框架能带来哪些好处？
+
+下面列举了一些使用 Spring 框架带来的主要好处：
+
+> 艿艿：注意，下文中加粗的内容，这是本句话的关键。
+
+- **DI** ：**[Dependency Injection(DI)](http://howtodoinjava.com/2013/03/19/inversion-of-control-ioc-and-dependency-injection-di-patterns-in-spring-framework-and-related-interview-questions/)** 方法，使得构造器和 JavaBean、properties 文件中的依赖关系一目了然。
+- **轻量级**：与 EJB 容器相比较，IoC 容器更加趋向于**轻量级**。这样一来 IoC 容器在有限的内存和 CPU 资源的情况下，进行应用程序的开发和发布就变得十分有利。
+- **面向切面编程(AOP)**： Spring 支持面向**切面编程**，同时把应用的业务逻辑与系统的服务分离开来。
+- **集成主流框架**：Spring 并没有闭门造车，Spring **集成**了已有的技术栈，比如 ORM 框架、Logging 日期框架、J2EE、Quartz 和 JDK Timer ，以及其他视图技术。
+- 模块化：Spring 框架是按照**模块**的形式来组织的。由包和类的命名，就可以看出其所属的模块，开发者仅仅需要选用他们需要的模块即可。
+- **便捷的测试**：要 [测试一项用Spring开发的应用程序](http://howtodoinjava.com/2013/04/19/how-to-unit-test-spring-security-authentication-with-junit/) 十分简单，因为**测试**相关的环境代码都已经囊括在框架中了。更加简单的是，利用 JavaBean 形式的 POJO 类，可以很方便的利用依赖注入来写入测试数据。
+- **Web 框架**：Spring 的 **Web 框架**亦是一个精心设计的 Web MVC 框架，为开发者们在 Web 框架的选择上提供了一个除了主流框架比如 Struts 、过度设计的、不流行 Web 框架的以外的有力选项。
+- **事务管理**：Spring 提供了一个便捷的**事务管理**接口，适用于小型的本地事物处理（比如在单 DB 的环境下）和复杂的共同事物处理（比如利用 JTA 的复杂 DB 环境）。
+- **异常处理**：Spring 提供一个方便的 API ，将特定技术的异常(由JDBC, Hibernate, 或 JDO 抛出)转化为一致的、Unchecked 异常。
+
+当然，Spring 代码优点的同时，一定会带来相应的缺点：
+
+- 每个框架都有的问题，调试阶段不直观，后期的 bug 对应阶段，不容易判断问题所在。要花一定的时间去理解它。
+
+- 把很多 JavaEE 的东西封装了，在满足快速开发高质量程序的同时，隐藏了实现细节。
+
+  > 这就导致，很多工程师，离开了 Spring 之后，就不知道怎么工作了。从 Java 工程师，变成了 Spring 工程师。对于有追求的我们，还是需要知其然，知其所以然。
+
+## Spring 框架中都用到了哪些设计模式？
+
+Spring 框架中使用到了大量的设计模式，下面列举了比较有代表性的：
+
+- 代理模式 — 在 AOP 和 remoting 中被用的比较多。
+- 单例模式 — 在 Spring 配置文件中定义的 Bean 默认为单例模式。
+- 模板方法 — 用来解决代码重复的问题。比如 [RestTemplate](http://howtodoinjava.com/2015/02/20/spring-restful-client-resttemplate-example/)、JmsTemplate、JdbcTemplate 。
+- 前端控制器 — Spring提供了 DispatcherServlet 来对请求进行分发。
+- 视图帮助(View Helper) — Spring 提供了一系列的 JSP 标签，高效宏来辅助将分散的代码整合在视图里。
+- 依赖注入 — 贯穿于 BeanFactory / ApplicationContext 接口的核心理念。
+- 工厂模式 — BeanFactory 用来创建对象的实例。
+
+当然，感兴趣的胖友，觉得不过瘾，可以看看艿艿基友知秋写的几篇文章：
+
+- [《Spring 框架中的设计模式(一)》](http://www.iocoder.cn/Spring/DesignPattern-1)
+- [《Spring 框架中的设计模式(二)》](http://www.iocoder.cn/Spring/DesignPattern-2)
+- [《Spring 框架中的设计模式(三)》](http://www.iocoder.cn/Spring/DesignPattern-3)
+- [《Spring 框架中的设计模式(四)》](http://www.iocoder.cn/Spring/DesignPattern-4)
+- [《Spring 框架中的设计模式(五)》](http://www.iocoder.cn/Spring/DesignPattern-5)
+
+# Spring IoC
+
+> 下面，我们会将分成 IoC 和 Bean 两部分来分享 Spring 容器的内容。
+>
+> - IoC ，侧重在于容器。
+> - Bean ，侧重在于被容器管理的 Bean 。
+
+## 什么是 Spring IoC 容器？
+
+> 注意，正确的拼写是 IoC 。
+
+Spring 框架的核心是 Spring IoC 容器。容器创建 Bean 对象，将它们装配在一起，配置它们并管理它们的完整生命周期。
+
+- Spring 容器使用**依赖注入**来管理组成应用程序的 Bean 对象。
+- 容器通过读取提供的**配置元数据** Bean Definition 来接收对象进行实例化，配置和组装的指令。
+- 该配置元数据 Bean Definition 可以通过 XML，Java 注解或 Java Config 代码**提供**。
+
+> 艿艿，注意上面三段段话的**加粗**部分的内容。
+
+[![Spring IoC](03-Spring 面试题.assets/02.jpg)](http://static.iocoder.cn/images/Spring/2018-12-24/02.jpg)Spring IoC
+
+## 什么是依赖注入？
+
+在依赖注入中，你不必主动、手动创建对象，但必须描述如何创建它们。
+
+- 你不是直接在代码中将组件和服务连接在一起，而是描述配置文件中哪些组件需要哪些服务。
+- 然后，再由 IoC 容器将它们装配在一起。
+
+另外，依赖注入的英文缩写是 Dependency Injection ，简称 DI 。
+
+## IoC 和 DI 有什么区别？
+
+> 艿艿的吐槽，最怕这种概念题。下面引用知乎上的一个讨论：[《IoC 和DI 有什么区别？》](https://www.zhihu.com/question/25392984)
+
+IoC 是个更宽泛的概念，DI 是更具体的。引用郑烨的一篇博客，引用郑烨的一篇博客，[我眼中的Spring](https://link.zhihu.com/?target=http%3A//dreamhead.blogbus.com/logs/125334.html)
+
+> **Dependency Injection**
+> 原来，它叫 IoC 。
+> Martin Flower 发话了，是个框架都有 IoC ，这不足以新生容器反转的“如何定位插件的具体实现”，于是，它有了个新名字，Dependency Injection 。
+>
+> 其实，它就是一种将调用者与被调用者分离的思想，Uncle Bob 管它叫DIP（Dependency Inversion Principle），并把它归入OO设计原则。
+> 同 Spring 相比，它更早进入我的大脑。一切都是那么朦胧，直至 Spring 出现。
+>
+> 慢慢的，我知道了它还分为三种：
+>
+> - Interface Injection（type 1）
+> - Setter Injection（type 2）
+> - Constructor Injection（type 3）。
+>
+> Martin Flower那篇为它更名的大作让我心目关于它的一切趋于完整。
+>
+> 在 Spring 中，它是一切的基础。Spring 的种种优势随之而来。
+> 于我而言，它为我带来更多的是思维方式的转变，恐怕以后我再也无法写出那种一大块的全功能程序了。
+
+## 可以通过多少种方式完成依赖注入？
+
+通常，依赖注入可以通过**三种**方式完成，即：
+
+> 上面一个问题的三种方式的英文，下面是三种方式的中文。
+
+- 接口注入
+- 构造函数注入
+- setter 注入
+
+目前，在 Spring Framework 中，仅使用构造函数和 setter 注入这**两种**方式。
+
+那么这两种方式各有什么优缺点呢？胖友可以简单阅读 [《Spring两种依赖注入方式的比较》](https://my.oschina.net/itblog/blog/203746)，不用太较真。综述来说：
+
+| 构造函数注入               | setter 注入                |
+| :------------------------- | :------------------------- |
+| 没有部分注入               | 有部分注入                 |
+| 不会覆盖 setter 属性       | 会覆盖 setter 属性         |
+| 任意修改都会创建一个新实例 | 任意修改不会创建一个新实例 |
+| 适用于设置很多属性         | 适用于设置少量属性         |
+
+- 实际场景下，setting 注入使用的更多。
+
+## Spring 中有多少种 IoC 容器？
+
+Spring 提供了两种( 不是“个” ) IoC 容器，分别是 BeanFactory、ApplicationContext 。
+
+**BeanFactory**
+
+> BeanFactory 在 `spring-beans` 项目提供。
+
+BeanFactory ，就像一个包含 Bean 集合的工厂类。它会在客户端要求时实例化 Bean 对象。
+
+**ApplicationContext**
+
+> ApplicationContext 在 `spring-context` 项目提供。
+
+ApplicationContext 接口扩展了 BeanFactory 接口，它在 BeanFactory 基础上提供了一些额外的功能。内置如下功能：
+
+- MessageSource ：管理 message ，实现国际化等功能。
+- ApplicationEventPublisher ：事件发布。
+- ResourcePatternResolver ：多资源加载。
+- EnvironmentCapable ：系统 Environment（profile + Properties）相关。
+- Lifecycle ：管理生命周期。
+- Closable ：关闭，释放资源
+- InitializingBean：自定义初始化。
+- BeanNameAware：设置 beanName 的 Aware 接口。
+
+另外，ApplicationContext 会自动初始化非懒加载的 Bean 对象们。
+
+详细的内容，感兴趣的胖友，可以看看 [《【死磕 Spring】—— ApplicationContext 相关接口架构分析》](http://svip.iocoder.cn/Spring/ApplicationContext/) 一文。源码之前无秘密。简单总结下 BeanFactory 与 ApplicationContext 两者的差异：
+
+> 艿艿：可能很多胖友没看过源码，所以会比较难。
+
+| BeanFactory                | ApplicationContext       |
+| :------------------------- | :----------------------- |
+| 它使用懒加载               | 它使用即时加载           |
+| 它使用语法显式提供资源对象 | 它自己创建和管理资源对象 |
+| 不支持国际化               | 支持国际化               |
+| 不支持基于依赖的注解       | 支持基于依赖的注解       |
+
+另外，BeanFactory 也被称为**低级**容器，而 ApplicationContext 被称为**高级**容器。
+
+## 请介绍下常用的 BeanFactory 容器？
+
+BeanFactory 最常用的是 XmlBeanFactory 。它可以根据 XML 文件中定义的内容，创建相应的 Bean。
+
+## 请介绍下常用的 ApplicationContext 容器？
+
+以下是三种较常见的 ApplicationContext 实现方式：
+
+- 1、ClassPathXmlApplicationContext ：从 ClassPath 的 XML 配置文件中读取上下文，并生成上下文定义。应用程序上下文从程序环境变量中取得。示例代码如下：
+
+  ```
+  ApplicationContext context = new ClassPathXmlApplicationContext(“bean.xml”);
+  ```
+
+- 2、FileSystemXmlApplicationContext ：由文件系统中的XML配置文件读取上下文。示例代码如下：
+
+  ```
+  ApplicationContext context = new FileSystemXmlApplicationContext(“bean.xml”);
+  ```
+
+- 3、XmlWebApplicationContext ：由 Web 应用的XML文件读取上下文。例如我们在 Spring MVC 使用的情况。
+
+当然，目前我们更多的是使用 Spring Boot 为主，所以使用的是第四种 ApplicationContext 容器，ConfigServletWebServerApplicationContext 。
+
+## 列举一些 IoC 的一些好处？
+
+- 它将最小化应用程序中的代码量。
+- 它以最小的影响和最少的侵入机制促进松耦合。
+- 它支持即时的实例化和延迟加载 Bean 对象。
+- 它将使您的应用程序易于测试，因为它不需要单元测试用例中的任何单例或 JNDI 查找机制。
+
+## 简述 Spring IoC 的实现机制？
+
+简单来说，Spring 中的 IoC 的实现原理，就是**工厂模式**加**反射机制**。代码如下：
+
+```
+interface Fruit {
+
+     public abstract void eat();
+     
+}
+class Apple implements Fruit {
+
+    public void eat(){
+        System.out.println("Apple");
+    }
+    
+}
+class Orange implements Fruit {
+    public void eat(){
+        System.out.println("Orange");
+    }
+}
+
+class Factory {
+
+    public static Fruit getInstance(String className) {
+        Fruit f = null;
+        try {
+            f = (Fruit) Class.forName(className).newInstance();
+        } catch (Exception e) {
+            e.printStackTrace();
+        }
+        return f;
+    }
+    
+}
+
+class Client {
+
+    public static void main(String[] args) {
+        Fruit f = Factory.getInstance("io.github.dunwu.spring.Apple");
+        if(f != null){
+            f.eat();
+        }
+    }
+    
+}
+```
+
+- Fruit 接口，有 Apple 和 Orange 两个实现类。
+- Factory 工厂，通过反射机制，创建 `className` 对应的 Fruit 对象。
+- Client 通过 Factory 工厂，获得对应的 Fruit 对象。
+- 😈 实际情况下，Spring IoC 比这个复杂很多很多，例如单例 Bean 对象，Bean 的属性注入，相互依赖的 Bean 的处理，以及等等。
+
+在基友 [《面试问烂的 Spring IoC 过程》](http://www.iocoder.cn/Fight/Interview-poorly-asked-Spring-IOC-process-1/) 的文章中，把 Spring IoC 相关的内容，讲的非常不错。
+
+## Spring 框架中有哪些不同类型的事件？
+
+Spring 的 ApplicationContext 提供了支持事件和代码中监听器的功能。
+
+我们可以创建 Bean 用来监听在 ApplicationContext 中发布的事件。如果一个 Bean 实现了 ApplicationListener 接口，当一个ApplicationEvent 被发布以后，Bean 会自动被通知。示例代码如下：
+
+```
+public class AllApplicationEventListener implements ApplicationListener<ApplicationEvent> {  
+    
+    @Override  
+    public void onApplicationEvent(ApplicationEvent applicationEvent) {  
+        // process event  
+    }
+    
+}
+```
+
+Spring 提供了以下五种标准的事件：
+
+1. 上下文更新事件（ContextRefreshedEvent）：该事件会在ApplicationContext 被初始化或者更新时发布。也可以在调用ConfigurableApplicationContext 接口中的 `#refresh()` 方法时被触发。
+2. 上下文开始事件（ContextStartedEvent）：当容器调用ConfigurableApplicationContext 的 `#start()` 方法开始/重新开始容器时触发该事件。
+3. 上下文停止事件（ContextStoppedEvent）：当容器调用 ConfigurableApplicationContext 的 `#stop()` 方法停止容器时触发该事件。
+4. 上下文关闭事件（ContextClosedEvent）：当ApplicationContext 被关闭时触发该事件。容器被关闭时，其管理的所有单例 Bean 都被销毁。
+5. 请求处理事件（RequestHandledEvent）：在 We b应用中，当一个HTTP 请求（request）结束触发该事件。
+
+------
+
+除了上面介绍的事件以外，还可以通过扩展 ApplicationEvent 类来开发**自定义**的事件。
+
+① 示例自定义的事件的类，代码如下：
+
+```
+public class CustomApplicationEvent extends ApplicationEvent{  
+
+    public CustomApplicationEvent(Object source, final String msg) {  
+        super(source);
+    }  
+
+}
+```
+
+② 为了监听这个事件，还需要创建一个监听器。示例代码如下：
+
+```
+public class CustomEventListener implements ApplicationListener<CustomApplicationEvent> {
+
+    @Override  
+    public void onApplicationEvent(CustomApplicationEvent applicationEvent) {  
+        // handle event  
+    }
+    
+}
+```
+
+③ 之后通过 ApplicationContext 接口的 `#publishEvent(Object event)` 方法，来发布自定义事件。示例代码如下：
+
+```
+// 创建 CustomApplicationEvent 事件
+CustomApplicationEvent customEvent = new CustomApplicationEvent(applicationContext, "Test message");
+// 发布事件
+applicationContext.publishEvent(customEvent);
+```
+
+# Spring Bean
+
+## 什么是 Spring Bean ？
+
+- Bean 由 Spring IoC 容器实例化，配置，装配和管理。
+- Bean 是基于用户提供给 IoC 容器的配置元数据 Bean Definition 创建。
+
+这个问题，胖友可以在回过头看 [「什么是 Spring IoC 容器？」](https://svip.iocoder.cn/Spring/Interview/#) 问题，相互对照。
+
+## Spring 有哪些配置方式
+
+单纯从 Spring Framework 提供的方式，一共有三种：
+
+- 1、XML 配置文件。
+
+  Bean 所需的依赖项和服务在 XML 格式的配置文件中指定。这些配置文件通常包含许多 bean 定义和特定于应用程序的配置选项。它们通常以 bean 标签开头。例如：
+
+  ```
+  <bean id="studentBean" class="org.edureka.firstSpring.StudentBean">
+      <property name="name" value="Edureka"></property>
+  </bean>
+  ```
+
+- 2、注解配置。
+
+  您可以通过在相关的类，方法或字段声明上使用注解，将 Bean 配置为组件类本身，而不是使用 XML 来描述 Bean 装配。默认情况下，Spring 容器中未打开注解装配。因此，您需要在使用它之前在 Spring 配置文件中启用它。例如：
+
+  ```
+  <beans>
+  <context:annotation-config/>
+  <!-- bean definitions go here -->
+  </beans>
+  ```
+
+- 3、Java Config 配置。
+
+  Spring 的 Java 配置是通过使用 @Bean 和 @Configuration 来实现。
+
+  - `@Bean` 注解扮演与 `<bean />` 元素相同的角色。
+
+  - `@Configuration` 类允许通过简单地调用同一个类中的其他 `@Bean` 方法来定义 Bean 间依赖关系。
+
+  - 例如：
+
+    ```
+    @Configuration
+    public class StudentConfig {
+        
+        @Bean
+        public StudentBean myStudent() {
+            return new StudentBean();
+        }
+        
+    }
+    ```
+
+    - 是不是很熟悉 😈
+
+目前主要使用 **Java Config** 配置为主。当然，三种配置方式是可以混合使用的。例如说：
+
+- Dubbo 服务的配置，艿艿喜欢使用 XML 。
+- Spring MVC 请求的配置，艿艿喜欢使用 `@RequestMapping` 注解。
+- Spring MVC 拦截器的配置，艿艿喜欢 Java Config 配置。
+
+------
+
+另外，现在已经是 Spring Boot 的天下，所以更加是 **Java Config** 配置为主。
+
+## Spring 支持几种 Bean Scope ？
+
+> 艿艿，这个是一个比较小众的题目，简单了解即可。
+
+Spring Bean 支持 5 种 Scope ，分别如下：
+
+- Singleton - 每个 Spring IoC 容器仅有一个单 Bean 实例。**默认**
+- Prototype - 每次请求都会产生一个新的实例。
+- Request - 每一次 HTTP 请求都会产生一个新的 Bean 实例，并且该 Bean 仅在当前 HTTP 请求内有效。
+- Session - 每一个的 Session 都会产生一个新的 Bean 实例，同时该 Bean 仅在当前 HTTP Session 内有效。
+- Application - 每一个 Web Application 都会产生一个新的 Bean ，同时该 Bean 仅在当前 Web Application 内有效。
+
+> 另外，网络上很多文章说有 Global-session 级别，它是 Portlet 模块独有，目前已经废弃，在 Spring5 中是找不到的。
+
+仅当用户使用支持 Web 的 ApplicationContext 时，**最后三个才可用**。
+
+再补充一点，开发者是可以**自定义** Bean Scope ，具体可参见 [《Spring（10）—— Bean 作用范围（二）—— 自定义 Scope》](https://blog.csdn.net/elim168/article/details/75581670) 。
+
+不错呢，还是那句话，这个题目简单了解下即可，实际常用的只有 Singleton 和 Prototype 两种级别，甚至说，只有 Singleton 级别。😈
+
+## Spring Bean 在容器的生命周期是什么样的？
+
+> 艿艿说：这是一个比较高级的 Spring 的面试题，非常常见，并且答对比较加分。当然，如果实际真正弄懂，需要对 Spring Bean 的源码，有比较好的理解，所以 [《精尽 Spring 源码》](http://svip.iocoder.cn/categories/Spring/) 系列，该读还是读吧。
+
+> 艿艿：要注意下面每段话，艿艿进行加粗的地方。
+
+Spring Bean 的**初始化**流程如下：
+
+- 实例化 Bean 对象
+
+  - Spring 容器根据配置中的 Bean Definition(定义)中**实例化** Bean 对象。
+
+    > Bean Definition 可以通过 XML，Java 注解或 Java Config 代码提供。
+
+  - Spring 使用依赖注入**填充**所有属性，如 Bean 中所定义的配置。
+
+- Aware 相关的属性，注入到 Bean 对象
+
+  - 如果 Bean 实现 **BeanNameAware** 接口，则工厂通过传递 Bean 的 beanName 来调用 `#setBeanName(String name)` 方法。
+  - 如果 Bean 实现 **BeanFactoryAware** 接口，工厂通过传递自身的实例来调用 `#setBeanFactory(BeanFactory beanFactory)` 方法。
+
+- 调用相应的方法，进一步初始化 Bean 对象
+
+  - 如果存在与 Bean 关联的任何 **BeanPostProcessor** 们，则调用 `#preProcessBeforeInitialization(Object bean, String beanName)` 方法。
+  - 如果 Bean 实现 **InitializingBean** 接口，则会调用 `#afterPropertiesSet()` 方法。
+  - 如果为 Bean 指定了 **init** 方法（例如 `<bean />` 的 `init-method` 属性），那么将调用该方法。
+  - 如果存在与 Bean 关联的任何 **BeanPostProcessor** 们，则将调用 `#postProcessAfterInitialization(Object bean, String beanName)` 方法。
+
+Spring Bean 的**销毁**流程如下：
+
+- 如果 Bean 实现 **DisposableBean** 接口，当 spring 容器关闭时，会调用 `#destroy()` 方法。
+- 如果为 bean 指定了 **destroy** 方法（例如 `<bean />` 的 `destroy-method` 属性），那么将调用该方法。
+
+整体如下图：[![流程图](03-Spring 面试题.assets/03.jpg)](http://static.iocoder.cn/images/Spring/2018-12-24/03.jpg)流程图
+
+无意中，艿艿又翻到一张有趣的整体图，如下图：
+
+[![流程图](03-Spring 面试题.assets/08.png)](http://static.iocoder.cn/images/Spring/2018-12-24/08.png)流程图
+
+## 什么是 Spring 的内部 bean？
+
+只有将 Bean **仅**用作另一个 Bean 的属性时，才能将 Bean 声明为内部 Bean。
+
+- 为了定义 Bean，Spring 提供基于 XML 的配置元数据在 `<property>`或 `<constructor-arg>` 中提供了 `<bean>`元素的使用。
+- 内部 Bean 总是**匿名**的，并且它们总是作为**原型 Prototype** 。
+
+例如，假设我们有一个 Student 类，其中引用了 Person 类。这里我们将只创建一个 Person 类实例并在 Student 中使用它。示例代码如下：
+
+```
+// Student.java
+
+public class Student {
+
+    private Person person;
+    
+    // ... Setters and Getters
+}
+
+// Person.java
+
+public class Person {
+
+    private String name;
+    private String address;
+    
+    // ... Setters and Getters
+}
+<!-- bean.xml -->
+
+<bean id=“StudentBean" class="com.edureka.Student">
+    <property name="person">
+        <!--This is inner bean -->
+        <bean class="com.edureka.Person">
+            <property name="name" value=“Scott"></property>
+            <property name="address" value=“Bangalore"></property>
+        </bean>
+    </property>
+</bean>
+```
+
+## 什么是 Spring 装配？
+
+当 Bean 在 Spring 容器中组合在一起时，它被称为**装配**或 **Bean 装配**。Spring 容器需要知道需要什么 Bean 以及容器应该如何使用依赖注入来将 Bean 绑定在一起，同时装配 Bean 。
+
+> 装配，和上文提到的 DI 依赖注入，实际是一个东西。
+
+**自动装配有哪些方式？**
+
+Spring 容器能够自动装配 Bean 。也就是说，可以通过检查 BeanFactory 的内容让 Spring 自动解析 Bean 的协作者。
+
+自动装配的不同模式：
+
+- no - 这是默认设置，表示没有自动装配。应使用显式 Bean 引用进行装配。
+- byName - 它根据 Bean 的名称注入对象依赖项。它匹配并装配其属性与 XML 文件中由相同名称定义的 Bean 。
+- 【最常用】**byType** - 它根据类型注入对象依赖项。如果属性的类型与 XML 文件中的一个 Bean 类型匹配，则匹配并装配属性。
+- 构造函数 - 它通过调用类的构造函数来注入依赖项。它有大量的参数。
+- autodetect - 首先容器尝试通过构造函数使用 autowire 装配，如果不能，则尝试通过 byType 自动装配。
+
+**自动装配有什么局限？**
+
+> 艿艿：这个题目，了解下即可，也不是很准确。
+
+- 覆盖的可能性 - 您始终可以使用 `<constructor-arg>` 和 `<property>` 设置指定依赖项，这将覆盖自动装配。
+
+- 基本元数据类型 - 简单属性（如原数据类型，字符串和类）无法自动装配。
+
+  > 这种，严格来说，也不能称为局限。因为可以通过配置文件来解决。
+
+- 令人困惑的性质 - 总是喜欢使用明确的装配，因为自动装配不太精确。
+
+## 解释什么叫延迟加载？
+
+默认情况下，容器启动之后会将所有作用域为**单例**的 Bean 都创建好，但是有的业务场景我们并不需要它提前都创建好。此时，我们可以在Bean 中设置 `lzay-init = "true"` 。
+
+- 这样，当容器启动之后，作用域为单例的 Bean ，就不在创建。
+- 而是在获得该 Bean 时，才真正在创建加载。
+
+## Spring 框架中的单例 Bean 是线程安全的么？
+
+Spring 框架并没有对[单例](http://howtodoinjava.com/2012/10/22/singleton-design-pattern-in-java/) Bean 进行任何多线程的封装处理。
+
+- 关于单例 Bean 的[线程安全](http://howtodoinjava.com/2014/06/02/what-is-thread-safety/)和并发问题，需要开发者自行去搞定。
+- 并且，单例的线程安全问题，也不是 Spring 应该去关心的。Spring 应该做的是，提供根据配置，创建单例 Bean 或多例 Bean 的功能。
+
+当然，但实际上，大部分的 Spring Bean 并没有可变的状态(比如Serview 类和 DAO 类)，所以在某种程度上说 Spring 的单例 Bean 是线程安全的。
+
+如果你的 Bean 有多种状态的话，就需要自行保证线程安全。最浅显的解决办法，就是将多态 Bean 的作用域( Scope )由 Singleton 变更为 Prototype 。
+
+## Spring Bean 怎么解决循环依赖的问题？
+
+> 艿艿说：能回答出这个问题的，一般是比较厉害的。
+
+这是个比较复杂的问题，有能力的胖友，建议看下 [《【死磕 Spring】—— IoC 之加载 Bean：创建 Bean（五）之循环依赖处理》](http://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-5/)
+
+感觉，不通过源码，很难解释清楚这个问题。如果看不懂的胖友，可以在认真看完，在星球里，我们一起多交流下。好玩的。
+
+# Spring 注解
+
+这块内容，实际写在 [「Spring Bean」](https://svip.iocoder.cn/Spring/Interview/#) 中比较合适，考虑到后续的问题，都是关于注解的，所以单独起一个大的章节。
+
+## 什么是基于注解的容器配置？
+
+不使用 XML 来描述 Bean 装配，开发人员通过在相关的类，方法或字段声明上使用**注解**将配置移动到组件类本身。它可以作为 XML 设置的替代方案。例如：
+
+Spring 的 Java 配置是通过使用 `@Bean` 和 `@Configuration` 来实现。
+
+- `@Bean` 注解，扮演与 `<bean />` 元素相同的角色。
+- `@Configuration` 注解的类，允许通过简单地调用同一个类中的其他 `@Bean` 方法来定义 Bean 间依赖关系。
+
+示例如下：
+
+```
+@Configuration
+public class StudentConfig {
+
+    @Bean
+    public StudentBean myStudent() {
+        return new StudentBean();
+    }
+    
+}
+```
+
+## 如何在 Spring 中启动注解装配？
+
+默认情况下，Spring 容器中未打开注解装配。因此，要使用基于注解装配，我们必须通过配置 `<context：annotation-config />` 元素在 Spring 配置文件中启用它。
+
+当然，如果胖友是使用 Spring Boot ，默认情况下已经开启。
+
+## @Component, @Controller, @Repository, @Service 有何区别？
+
+- `@Component` ：它将 Java 类标记为 Bean 。它是任何 Spring 管理组件的**通用**构造型。
+- `@Controller` ：它将一个类标记为 Spring Web MVC **控制器**。
+- `@Service` ：此注解是组件注解的特化。它不会对 `@Component` 注解提供任何其他行为。您可以在**服务层**类中使用 @Service 而不是 `@Component` ，因为它以更好的方式指定了意图。
+- `@Repository` ：这个注解是具有类似用途和功能的 `@Component` 注解的特化。它为 **DAO** 提供了额外的好处。它将 DAO 导入 IoC 容器，并使未经检查的异常有资格转换为 Spring DataAccessException 。
+
+## @Required 注解有什么用？
+
+`@Required` 注解，应用于 Bean 属性 setter 方法。
+
+- 此注解仅指示必须在配置时使用 Bean 定义中的显式属性值或使用自动装配填充受影响的 Bean 属性。
+- 如果尚未填充受影响的 Bean 属性，则容器将抛出 BeanInitializationException 异常。
+
+示例代码如下：
+
+```
+public class Employee {
+
+    private String name;
+    
+    @Required
+    public void setName(String name){
+        this.name=name;
+    }
+    
+    public string getName(){
+        return name;
+    }
+    
+}
+```
+
+- T T 貌似平时很少用这个注解噢。
+
+## @Autowired 注解有什么用？
+
+`@Autowired` 注解，可以更准确地控制应该在何处以及如何进行自动装配。
+
+- 此注解用于在 setter 方法，构造函数，具有任意名称或多个参数的属性或方法上自动装配 Bean。
+- 默认情况下，它是类型驱动的注入。
+
+示例代码如下：
+
+```
+public class EmpAccount {
+    
+    @Autowired
+    private Employee emp;
+    
+}
+```
+
+## @Qualifier 注解有什么用？
+
+当你创建多个**相同类型**的 Bean ，并希望仅使用属性装配**其中一个** Bean 时，您可以使用 `@Qualifier` 注解和 `@Autowired` 通过指定 ID 应该装配哪个**确切的** Bean 来消除歧义。
+
+例如，应用中有两个类型为 Employee 的 Bean ID 为 `"emp1"` 和 `"emp2"` ，此处，我们希望 EmployeeAccount Bean 注入 `"emp1"` 对应的 Bean 对象。代码如下：
+
+```
+public class EmployeeAccount {
+
+    @Autowired
+    @Qualifier(emp1)
+    private Employee emp;
+
+}
+```
+
+# Spring AOP
+
+> Spring AOP 的面试题中，大多数都是概念题，主要是对切面的理解。概念点主要有：
+>
+> - AOP
+> - Aspect
+> - JoinPoint
+> - PointCut
+> - Advice
+> - Target
+> - AOP Proxy
+> - Weaving
+
+- 在阅读完 [「Spring AOP」](https://svip.iocoder.cn/Spring/Interview/#) 的面试题后，在回过头思考下这些概念点，到底理解了多少。注意，不是背，理解！
+
+非常推荐阅读如下两篇文章：
+
+- [《彻底征服 Spring AOP 之理论篇》](https://segmentfault.com/a/1190000007469968)
+- [《彻底征服 Spring AOP 之实战篇》](https://segmentfault.com/a/1190000007469982)
+
+## 什么是 AOP ？
+
+AOP(Aspect-Oriented Programming)，即**面向切面编程**, 它与 OOP( Object-Oriented Programming, 面向对象编程) 相辅相成， 提供了与 OOP 不同的抽象软件结构的视角。
+
+- 在 OOP 中，以类( Class )作为基本单元
+- 在 AOP 中，以**切面( Aspect )**作为基本单元。
+
+## 什么是 Aspect ？
+
+Aspect 由 **PointCut** 和 **Advice** 组成。
+
+- 它既包含了横切逻辑的定义，也包括了连接点的定义。
+- Spring AOP 就是负责实施切面的框架，它将切面所定义的横切逻辑编织到切面所指定的连接点中。
+
+AOP 的工作重心在于如何将增强编织目标对象的连接点上, 这里包含两个工作:
+
+1. 如何通过 PointCut 和 Advice 定位到特定的 **JoinPoint** 上。
+2. 如何在 Advice 中编写切面代码。
+
+**可以简单地认为, 使用 @Aspect 注解的类就是切面**
+
+[![流程图](03-Spring 面试题.assets/04.jpg)](http://static.iocoder.cn/images/Spring/2018-12-24/04.jpg)流程图
+
+## 什么是 JoinPoint ?
+
+JoinPoint ，**切点**，程序运行中的一些时间点, 例如：
+
+- 一个方法的执行。
+- 或者是一个异常的处理。
+
+在 Spring AOP 中，JoinPoint 总是方法的执行点。
+
+## 什么是 PointCut ？
+
+PointCut ，**匹配** JoinPoint 的谓词(a predicate that matches join points)。
+
+> 简单来说，PointCut 是匹配 JoinPoint 的条件。
+
+- Advice 是和特定的 PointCut 关联的，并且在 PointCut 相匹配的 JoinPoint 中执行。即 `Advice => PointCut => JoinPoint` 。
+- 在 Spring 中, 所有的方法都可以认为是 JoinPoint ，但是我们并不希望在所有的方法上都添加 Advice 。**而 PointCut 的作用**，就是提供一组规则(使用 AspectJ PointCut expression language 来描述) 来匹配 JoinPoint ，给满足规则的 JoinPoint 添加 Advice 。
+
+😈 是不是觉得有点绕，实际场景下，其实也不会弄的这么清楚~~
+
+## 关于 JoinPoint 和 PointCut 的区别
+
+JoinPoint 和 PointCut 本质上就是**两个不同纬度上**的东西。
+
+- 在 Spring AOP 中，所有的方法执行都是 JoinPoint 。而 PointCut 是一个描述信息，它修饰的是 JoinPoint ，通过 PointCut ，我们就可以确定哪些 JoinPoint 可以被织入 Advice 。
+- Advice 是在 JoinPoint 上执行的，而 PointCut 规定了哪些 JoinPoint 可以执行哪些 Advice 。
+
+或者，我们在换一种说法：
+
+1. 首先，Advice 通过 PointCut 查询需要被织入的 JoinPoint 。
+2. 然后，Advice 在查询到 JoinPoint 上执行逻辑。
+
+## 什么是 Advice ？
+
+Advice ，**通知**。
+
+- 特定 JoinPoint 处的 Aspect 所采取的动作称为 Advice 。
+- Spring AOP 使用一个 Advice 作为拦截器，在 JoinPoint “周围”维护一系列的**拦截器**。
+
+**有哪些类型的 Advice？**
+
+- Before - 这些类型的 Advice 在 JoinPoint 方法之前执行，并使用 `@Before` 注解标记进行配置。
+- After Returning - 这些类型的 Advice 在连接点方法正常执行后执行，并使用 `@AfterReturning` 注解标记进行配置。
+- After Throwing - 这些类型的 Advice 仅在 JoinPoint 方法通过抛出异常退出并使用 `@AfterThrowing` 注解标记配置时执行。
+- After Finally - 这些类型的 Advice 在连接点方法之后执行，无论方法退出是正常还是异常返回，并使用 `@After` 注解标记进行配置。
+- Around - 这些类型的 Advice 在连接点之前和之后执行，并使用 `@Around` 注解标记进行配置。
+
+😈 看起来，是不是和拦截器的执行时间，有几分相似。实际上，用于拦截效果的各种实现，大体都是类似的。
+
+## 什么是 Target ？
+
+Target ，织入 Advice 的**目标对象**。目标对象也被称为 **Advised Object** 。
+
+- 因为 Spring AOP 使用运行时代理的方式来实现 Aspect ，因此 Advised Object 总是一个代理对象(Proxied Object) 。
+- **注意, Advised Object 指的不是原来的对象，而是织入 Advice 后所产生的代理对象**。
+- Advice + Target Object = Advised Object = Proxy 。
+
+## AOP 有哪些实现方式？
+
+实现 AOP 的技术，主要分为两大类：
+
+- ① **静态代理** - 指使用 AOP 框架提供的命令进行编译，从而在编译阶段就可生成 AOP 代理类，因此也称为编译时增强。
+
+  - 编译时编织（特殊编译器实现）
+
+  - 类加载时编织（特殊的类加载器实现）。
+
+    > 例如，SkyWalking 基于 Java Agent 机制，配置上 ByteBuddy 库，实现类加载时编织时增强，从而实现链路追踪的透明埋点。
+    >
+    > 感兴趣的胖友，可以看看 [《SkyWalking 源码分析之 JavaAgent 工具 ByteBuddy 的应用》](http://www.kailing.pub/article/index/arcid/178.html) 。
+
+- ② **动态代理** - 在运行时在内存中“临时”生成 AOP 动态代理类，因此也被称为运行时增强。目前 Spring 中使用了两种动态代理库：
+
+  - JDK 动态代理
+  - CGLIB
+
+那么 Spring 什么时候使用 JDK 动态代理，什么时候使用 CGLIB 呢？
+
+```
+// From 《Spring 源码深度解析》P172
+// Spring AOP 部分使用 JDK 动态代理或者 CGLIB 来为目标对象创建代理。（建议尽量使用 JDK 的动态代理）
+// 如果被代理的目标对象实现了至少一个接口，则会使用 JDK 动态代理。所有该目标类型实现的接口都讲被代理。
+// 若该目标对象没有实现任何接口，则创建一个 CGLIB 代理。
+// 如果你希望强制使用 CGLIB 代理，（例如希望代理目标对象的所有方法，而不只是实现自接口的方法）那也可以。但是需要考虑以下两个方法：
+//      1> 无法通知(advise) Final 方法，因为它们不能被覆盖。
+//      2> 你需要将 CGLIB 二进制发型包放在 classpath 下面。
+// 为什么 Spring 默认使用 JDK 的动态代理呢？笔者猜测原因如下：
+//      1> 使用 JDK 原生支持，减少三方依赖
+//      2> JDK8 开始后，JDK 代理的性能差距 CGLIB 的性能不会太多。可参见：https://www.cnblogs.com/haiq/p/4304615.html
+```
+
+- 实际上，Spring AOP 的代码量不大，与其在窗户外面不清不楚，不如捅破它！感兴趣的胖友，可以撸一撸 [《精尽 Spring 源码分析 —— AOP 源码简单导读》](http://svip.iocoder.cn/Spring/aop-simple-intro/) 。
+
+或者，我们来换一个解答答案：
+
+Spring AOP 中的动态代理主要有两种方式，
+
+- JDK 动态代理
+
+  JDK 动态代理通过反射来接收被代理的类，并且要求被代理的类必须实现一个接口。JDK动态代理的核心是 InvocationHandler 接口和 Proxy 类。
+
+- CGLIB 动态代理
+
+  如果目标类没有实现接口，那么 Spring AOP 会选择使用 CGLIB 来动态代理目标类。当然，Spring 也支持配置，**强制**使用 CGLIB 动态代理。
+  CGLIB（Code Generation Library），是一个代码生成的类库，可以在运行时动态的生成某个类的子类，注意，CGLIB 是通过继承的方式做的动态代理，因此如果某个类被标记为 `final` ，那么它是无法使用 CGLIB 做动态代理的。
+
+## Spring AOP and AspectJ AOP 有什么区别？
+
+- 代理方式不同
+  - Spring AOP 基于动态代理方式实现。
+  - AspectJ AOP 基于静态代理方式实现。
+- PointCut 支持力度不同
+  - Spring AOP **仅**支持方法级别的 PointCut 。
+  - AspectJ AOP 提供了完全的 AOP 支持，它还支持属性级别的 PointCut 。
+
+## 什么是编织（Weaving）？
+
+Weaving ，**编织**。
+
+- 为了创建一个 Advice 对象而链接一个 Aspect 和其它应用类型或对象，称为编织（Weaving）。
+- 在 Spring AOP 中，编织在运行时执行，即动态代理。请参考下图：[![Proxy](03-Spring 面试题.assets/05.jpg)](http://static.iocoder.cn/images/Spring/2018-12-24/05.jpg)Proxy
+
+## Spring 如何使用 AOP 切面？
+
+在 Spring AOP 中，有两种方式配置 AOP 切面：
+
+- 基于 **XML** 方式的切面实现。
+- 基于 **注解** 方式的切面实现。
+
+目前，主流喜欢使用 **注解** 方式。胖友可以看看 [《彻底征服 Spring AOP 之实战篇》](https://segmentfault.com/a/1190000007469982) 。
+
+# Spring Transaction
+
+非常推荐阅读如下文章：
+
+- [《可能是最漂亮的 Spring 事务管理详解》](https://mp.weixin.qq.com/s?__biz=MzUzMTA2NTU2Ng==&mid=2247484702&idx=1&sn=c04261d63929db09ff6df7cadc7cca21&chksm=fa497aafcd3ef3b94082da7bca841b5b7b528eb2a52dbc4eb647b97be63a9a1cf38a9e71bf90&token=165108535&lang=zh_CN#rd)
+
+## 什么是事务？
+
+事务就是对一系列的数据库操作（比如插入多条数据）进行统一的提交或回滚操作，如果插入成功，那么一起成功，如果中间有一条出现异常，那么回滚之前的所有操作。
+
+这样可以防止出现脏数据，防止数据库数据出现问题。
+
+## 事务的特性指的是？
+
+指的是 **ACID** ，如下图所示：
+
+[![事务的特性](03-Spring 面试题.assets/06.png)](http://static.iocoder.cn/images/Spring/2018-12-24/06.png)事务的特性
+
+1. **原子性** Atomicity ：一个事务（transaction）中的所有操作，或者全部完成，或者全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被恢复（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。即，事务不可分割、不可约简。
+2. **一致性** Consistency ：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设[约束](https://zh.wikipedia.org/wiki/数据完整性)、[触发器](https://zh.wikipedia.org/wiki/触发器_(数据库))、[级联回滚](https://zh.wikipedia.org/w/index.php?title=级联回滚&action=edit&redlink=1)等。
+3. **隔离性** Isolation ：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。
+4. **持久性** Durability ：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。
+
+## 列举 Spring 支持的事务管理类型？
+
+目前 Spring 提供两种类型的事务管理：
+
+- **声明式**事务：通过使用注解或基于 XML 的配置事务，从而事务管理与业务代码分离。
+- **编程式**事务：通过编码的方式实现事务管理，需要在代码中显式的调用事务的获得、提交、回滚。它为您提供极大的灵活性，但维护起来非常困难。
+
+实际场景下，我们一般使用 Spring Boot + 注解的**声明式**事务。具体的示例，胖友可以看看 [《Spring Boot 事务注解详解》](https://www.jianshu.com/p/cddeca2c9245) 。
+
+另外，也推荐看看 [《Spring 事务管理 － 编程式事务、声明式事务》](https://blog.csdn.net/xktxoo/article/details/77919508) 一文。
+
+## Spring 事务如何和不同的数据持久层框架做集成？
+
+① 首先，我们先明确下，这里数据持久层框架，指的是 Spring JDBC、Hibernate、Spring JPA、MyBatis 等等。
+
+② 然后，Spring 事务的管理，是通过 `org.springframework.transaction.PlatformTransactionManager` 进行管理，定义如下：
+
+```
+// PlatformTransactionManager.java
+
+public interface PlatformTransactionManager {
+
+    // 根据事务定义 TransactionDefinition ，获得 TransactionStatus 。 
+    TransactionStatus getTransaction(@Nullable TransactionDefinition definition) throws TransactionException;
+
+    // 根据情况，提交事务
+    void commit(TransactionStatus status) throws TransactionException;
+    
+    // 根据情况，回滚事务
+    void rollback(TransactionStatus status) throws TransactionException;
+    
+}
+```
+
+- PlatformTransactionManager 是负责事务管理的接口，一共有三个接口方法，分别负责事务的获得、提交、回滚。
+
+- ```
+  #getTransaction(TransactionDefinition definition)
+  ```
+
+   
+
+  方法，根据事务定义 TransactionDefinition ，获得 TransactionStatus 。
+
+  - 为什么不是创建事务呢？因为如果当前如果已经有事务，则不会进行创建，一般来说会跟当前线程进行绑定。如果不存在事务，则进行创建。
+  - 为什么返回的是 TransactionStatus 对象？在 TransactionStatus 中，不仅仅包含事务属性，还包含事务的其它信息，例如是否只读、是否为新创建的事务等等。😈 下面，也会详细解析 TransactionStatus 。
+  - 事务 TransactionDefinition 是什么？😈 下面，也会详细解析 TransactionStatus 。
+
+- ```
+  #commit(TransactionStatus status)
+  ```
+
+   
+
+  方法，根据 TransactionStatus 情况，提交事务。
+
+  - 为什么根据 TransactionStatus 情况，进行提交？例如说，带
+
+    ```
+    @Transactional
+    ```
+
+     
+
+    注解的的 A 方法，会调用
+
+     
+
+    ```
+    @Transactional
+    ```
+
+     
+
+    注解的的 B 方法。
+
+    - 在 B 方法结束调用后，会执行 `PlatformTransactionManager#commit(TransactionStatus status)` 方法，此处事务**是不能**、**也不会**提交的。
+    - 而是在 A 方法结束调用后，执行 `PlatformTransactionManager#commit(TransactionStatus status)` 方法，提交事务。
+
+- ```
+  #rollback(TransactionStatus status)
+  ```
+
+   
+
+  方法，根据 TransactionStatus 情况，回滚事务。
+
+  - 为什么根据 TransactionStatus 情况，进行回滚？原因同 `#commit(TransactionStatus status)` 方法。
+
+③ 再之后，PlatformTransactionManager 有**抽象子**类 `org.springframework.transaction.support.AbstractPlatformTransactionManager` ，基于 [模板方法模式](https://blog.csdn.net/carson_ho/article/details/54910518) ，实现事务整体逻辑的骨架，而抽象 `#doCommit(DefaultTransactionStatus status)`、`#doRollback(DefaultTransactionStatus status)` 等等方法，交由子类类来实现。
+
+> 前方高能，即将进入关键的 ④ 步骤。
+
+④ 最后，不同的数据持久层框架，会有其对应的 PlatformTransactionManager 实现类，如下图所示：[![事务的特性](03-Spring 面试题.assets/07.png)](http://static.iocoder.cn/images/Spring/2018-12-24/07.png)事务的特性
+
+- 所有的实现类，都基于 AbstractPlatformTransactionManager 这个骨架类。
+- HibernateTransactionManager ，和 Hibernate5 的事务管理做集成。
+- DataSourceTransactionManager ，和 JDBC 的事务管理做集成。所以，它也适用于 MyBatis、Spring JDBC 等等。
+- JpaTransactionManager ，和 JPA 的事务管理做集成。
+
+如下，是一个比较常见的 XML 方式来配置的事务管理器，使用的是 DataSourceTransactionManager 。代码如下：
+
+```
+<!-- 事务管理器 -->
+<bean id="transactionManager"
+class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
+    <!-- 数据源 -->
+    <property name="dataSource" ref="dataSource" />
+</bean>
+```
+
+- 正如上文所说，它适用于 MyBatis、Spring JDBC 等等。
+
+------
+
+😈 是不是很有趣，更多详细的解析，可见如下几篇文章：
+
+- [《精尽 Spring 源码分析 —— Transaction 源码简单导读》](http://svip.iocoder.cn/categories/Spring/)
+- [《精尽 MyBatis 源码分析 —— 事务模块》](http://svip.iocoder.cn/MyBatis/transaction-package/)
+- [《精尽 MyBatis 源码解析 —— Spring 集成（四）之事务》](http://svip.iocoder.cn/MyBatis/Spring-Integration-4/)
+
+## 为什么在 Spring 事务中不能切换数据源？
+
+做过 Spring 多数据源的胖友，都会有个惨痛的经历，为什么在开启事务的 Service 层的方法中，无法切换数据源呢？因为，在 Spring 的事务管理中，**所使用的数据库连接会和当前线程所绑定**，即使我们设置了另外一个数据源，使用的还是当前的数据源连接。
+
+另外，多个数据源且需要事务的场景，本身会带来**多事务一致性**的问题，暂时没有特别好的解决方案。
+
+所以一般一个应用，推荐除非了读写分离所带来的多数据源，其它情况下，建议只有一个数据源。并且，随着微服务日益身形，一个服务对应一个 DB 是比较常见的架构选择。
+
+## @Transactional 注解有哪些属性？如何使用？
+
+`@Transactional` 注解的**属性**如下：
+
+| 属性                   | 类型                               | 描述                                   |
+| :--------------------- | :--------------------------------- | :------------------------------------- |
+| value                  | String                             | 可选的限定描述符，指定使用的事务管理器 |
+| propagation            | enum: Propagation                  | 可选的事务传播行为设置                 |
+| isolation              | enum: Isolation                    | 可选的事务隔离级别设置                 |
+| readOnly               | boolean                            | 读写或只读事务，默认读写               |
+| timeout                | int (in seconds granularity)       | 事务超时时间设置                       |
+| rollbackFor            | Class对象数组，必须继承自Throwable | 导致事务回滚的异常类数组               |
+| rollbackForClassName   | 类名数组，必须继承自Throwable      | 导致事务回滚的异常类名字数组           |
+| noRollbackFor          | Class对象数组，必须继承自Throwable | 不会导致事务回滚的异常类数组           |
+| noRollbackForClassName | 类名数组，必须继承自Throwable      | 不会导致事务回滚的异常类名字数组       |
+
+- 一般情况下，我们直接使用 `@Transactional` 的所有属性默认值即可。
+
+具体**用法**如下：
+
+- `@Transactional` 可以作用于接口、接口方法、类以及类方法上。当作用于类上时，该类的所有 `public` 方法将都具有该类型的事务属性，同时，我们也可以在方法级别使用该标注来覆盖类级别的定义。
+- 虽然 `@Transactional` 注解可以作用于接口、接口方法、类以及类方法上，但是 Spring 建议不要在接口或者接口方法上使用该注解，因为这只有在使用基于接口的代理时它才会生效。另外， **`@Transactional` 注解应该只被应用到 `public` 方法上，这是由 Spring AOP 的本质决定的**。如果你在 `protected`、`private` 或者默认可见性的方法上使用 `@Transactional` 注解，这将被忽略，也不会抛出任何异常。**这一点，非常需要注意**。
+
+------
+
+下面，我们来简单说下**源码**相关的东西。
+
+`@Transactional` 注解的属性，会解析成 `org.springframework.transaction.TransactionDefinition` 对象，即事务定义。TransactionDefinition 代码如下：
+
+```
+public interface TransactionDefinition {
+
+	int getPropagationBehavior(); // 事务的传播行为
+	int getIsolationLevel(); // 事务的隔离级别
+	int getTimeout(); // 事务的超时时间
+	boolean isReadOnly(); // 事务是否只读
+	@Nullable
+	String getName(); // 事务的名字
+
+}
+```
+
+- 可能会胖友有以后，`@Transactional` 注解的 `rollbackFor`、`rollbackForClassName`、`noRollbackFor`、`noRollbackForClassName` 属性貌似没体现出来？它们提现在 TransactionDefinition 的实现类 RuleBasedTransactionAttribute 中。
+- `#getPropagationBehavior()` 方法，返回事务的**传播行为**，该值是个枚举，在下面来说。
+- `#getIsolationLevel()` 方法，返回事务的**隔离级别**，该值是个枚举，在下面来说。
+
+## 什么是事务的隔离级别？分成哪些隔离级别？
+
+关于这个问题，涉及的内容会比较多，胖友直接看如下两篇文章：
+
+- [《数据库四大特性以及事务隔离级别》](https://zhuanlan.zhihu.com/p/25419593)
+- [《五分钟搞清楚 MySQL 事务隔离级别》](https://www.jianshu.com/p/4e3edbedb9a8)
+
+另外，有一点非常重要，不同数据库对四个隔离级别的支持和实现略有不同。因为我们目前互联网主要使用 MySQL 为主，所以至少要搞懂 MySQL 对隔离级别的支持和实现情况。
+
+在 TransactionDefinition 接口中，定义了“**四种**”的隔离级别枚举。代码如下：
+
+```
+// TransactionDefinition.java
+
+/**
+ * 【Spring 独有】使用后端数据库默认的隔离级别
+ *
+ * MySQL 默认采用的 REPEATABLE_READ隔离级别
+ * Oracle 默认采用的 READ_COMMITTED隔离级别
+ */
+int ISOLATION_DEFAULT = -1;
+
+/**
+ * 最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读
+ */
+int ISOLATION_READ_UNCOMMITTED = Connection.TRANSACTION_READ_UNCOMMITTED;
+
+/**
+ * 允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生
+ */
+int ISOLATION_READ_COMMITTED = Connection.TRANSACTION_READ_COMMITTED;
+/**
+ * 对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。
+ */
+int ISOLATION_REPEATABLE_READ = Connection.TRANSACTION_REPEATABLE_READ;
+/**
+ * 最高的隔离级别，完全服从ACID的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。
+ *
+ * 但是这将严重影响程序的性能。通常情况下也不会用到该级别。
+ */
+int ISOLATION_SERIALIZABLE = Connection.TRANSACTION_SERIALIZABLE;
+```
+
+## 什么是事务的传播级别？分成哪些传播级别？
+
+事务的**传播行为**，指的是当前带有事务配置的方法，需要怎么处理事务。
+
+- 例如：方法可能继续在现有事务中运行，也可能开启一个新事务，并在自己的事务中运行。
+
+- 有一点需要注意，事务的传播级别，并不是数据库事务规范中的名词，**而是 Spring 自身所定义的**。通过事务的传播级别，Spring 才知道如何处理事务，是创建一个新事务呢，还是继续使用当前的事务。
+
+  > 艿艿的自我吐槽：是不是有种背概念背的想哭
+
+在 TransactionDefinition 接口中，定义了**三类七种**传播级别。代码如下：
+
+```
+// TransactionDefinition.java
+
+// ========== 支持当前事务的情况 ========== 
+
+/**
+ * 如果当前存在事务，则使用该事务。
+ * 如果当前没有事务，则创建一个新的事务。
+ */
+int PROPAGATION_REQUIRED = 0;
+/**
+ * 如果当前存在事务，则使用该事务。
+ * 如果当前没有事务，则以非事务的方式继续运行。
+ */
+int PROPAGATION_SUPPORTS = 1;
+/**
+ * 如果当前存在事务，则使用该事务。
+ * 如果当前没有事务，则抛出异常。
+ */
+int PROPAGATION_MANDATORY = 2;
+
+// ========== 不支持当前事务的情况 ========== 
+
+/**
+ * 创建一个新的事务。
+ * 如果当前存在事务，则把当前事务挂起。
+ */
+int PROPAGATION_REQUIRES_NEW = 3;
+/**
+ * 以非事务方式运行。
+ * 如果当前存在事务，则把当前事务挂起。
+ */
+int PROPAGATION_NOT_SUPPORTED = 4;
+/**
+ * 以非事务方式运行。
+ * 如果当前存在事务，则抛出异常。
+ */
+int PROPAGATION_NEVER = 5;
+
+// ========== 其他情况 ========== 
+
+/**
+ * 如果当前存在事务，则创建一个事务作为当前事务的嵌套事务来运行。
+ * 如果当前没有事务，则等价于 {@link TransactionDefinition#PROPAGATION_REQUIRED}
+ */
+int PROPAGATION_NESTED = 6;
+```
+
+- 分类之后，其实还是比较好记的。当然，绝大数场景，我们只用 `PROPAGATION_REQUIRED` 传播级别。
+
+- 这里需要指出的是，前面的六种事务传播行为是 Spring 从 EJB 中引入的，他们共享相同的概念。而
+
+   
+
+  ```
+  PROPAGATION_NESTED
+  ```
+
+   
+
+  是 Spring 所特有的。
+
+  - 以 `PROPAGATION_NESTED` 启动的事务内嵌于外部事务中（如果存在外部事务的话），此时，内嵌事务并不是一个独立的事务，它依赖于外部事务的存在，只有通过外部的事务提交，才能引起内部事务的提交，嵌套的子事务不能单独提交。如果熟悉 JDBC 中的保存点（SavePoint）的概念，那嵌套事务就很容易理解了，其实嵌套的子事务就是保存点的一个应用，一个事务中可以包括多个保存点，每一个嵌套子事务。另外，外部事务的回滚也会导致嵌套子事务的回滚。
+  - 😈 当然，虽然上面 `PROPAGATION_NESTED` 文字很长，实际我们基本没用过。或者说，去掉基本，我们根本没用过。
+
+## 什么是事务的超时属性？
+
+所谓事务超时，就是指一个事务所允许执行的最长时间，如果超过该时间限制但事务还没有完成，则自动回滚事务。
+
+在 TransactionDefinition 中以 `int` 的值来表示超时时间，其单位是秒。
+
+当然，这个属性，貌似我们基本也没用过。
+
+## 什么是事务的只读属性？
+
+事务的只读属性是指，对事务性资源进行只读操作或者是读写操作。
+
+- 所谓事务性资源就是指那些被事务管理的资源，比如数据源、JMS 资源，以及自定义的事务性资源等等。
+- 如果确定只对事务性资源进行只读操作，那么我们可以将事务标志为只读的，以提高事务处理的性能。感兴趣的胖友，可以看看 [《不使用事务和使用只读事务的区别 》](https://my.oschina.net/uniquejava/blog/80954) 。
+
+在 TransactionDefinition 中以 `boolean` 类型来表示该事务是否只读。
+
+## 什么是事务的回滚规则？
+
+回滚规则，定义了哪些异常会导致事务回滚而哪些不会。
+
+- 默认情况下，事务只有遇到运行期异常时才会回滚，而在遇到检查型异常时不会回滚（这一行为与EJB的回滚行为是一致的）。
+- 但是你可以声明事务在遇到特定的检查型异常时像遇到运行期异常那样回滚。同样，你还可以声明事务遇到特定的异常不回滚，即使这些异常是运行期异常。
+
+注意，事务的回滚规则，并不是数据库事务规范中的名词，**而是 Spring 自身所定义的**。
+
+## 简单介绍 TransactionStatus ？
+
+> 艿艿：这个可能不是一个面试题，主要满足下大家的好奇心。
+
+TransactionStatus 接口，记录事务的状态，不仅仅包含事务本身，还包含事务的其它信息。代码如下：
+
+```
+// TransactionStatus.java
+
+public interface TransactionStatus extends SavepointManager, Flushable {
+
+    /**
+     * 是否是新创建的事务
+     */
+    boolean isNewTransaction();
+
+    /**
+     * 是否有 Savepoint
+     *
+     * 在 {@link TransactionDefinition#PROPAGATION_NESTED} 传播级别使用。
+     */
+    boolean hasSavepoint();
+
+    /**
+     * 设置为只回滚
+     */
+    void setRollbackOnly();
+    /**
+     * 是否为只回滚
+     */
+    boolean isRollbackOnly();
+
+    /**
+     * 执行 flush 操作
+     */
+    @Override
+    void flush();
+
+    /**
+     * 是否事务已经完成
+     */
+    boolean isCompleted();
+
+}
+```
+
+- 为什么没有事务对象呢？在 TransactionStatus 的实现类 DefaultTransactionStatus 中，有个 `Object transaction` 属性，表示事务对象。
+- `#isNewTransaction()` 方法，表示是否是新创建的事务。有什么用呢？答案结合 [「Spring 事务如何和不同的数据持久层框架做集成？」](https://svip.iocoder.cn/Spring/Interview/#) 问题，我们对 `#commit(TransactionStatus status)` 方法的解释。通过该方法，我们可以判断，当前事务是否当前方法所创建的，只有创建事务的方法，**才能且应该真正的提交事务**。
+
+## 使用 Spring 事务有什么优点？
+
+1. 通过 PlatformTransactionManager ，为不同的数据层持久框架提供统一的 API ，无需关心到底是原生 JDBC、Spring JDBC、JPA、Hibernate 还是 MyBatis 。
+2. 通过使用声明式事务，使业务代码和事务管理的逻辑分离，更加清晰。
+
+从倾向上来说，艿艿比较喜欢**注解** + 声明式事务。
+
+# Spring Data Access
+
+> 艿艿：这块的问题，感觉面试问的不多，至少我很少问。哈哈哈。就当做下了解，万一问了呢。
+
+## Spring 支持哪些 ORM 框架？
+
+- Hibernate
+- JPA
+- MyBatis
+- [JDO](https://docs.spring.io/spring/docs/3.0.0.M4/reference/html/ch13s04.html)
+- [OJB](https://db.apache.org/ojb/docu/howtos/howto-use-spring.html)
+
+可能会有胖友说，不是应该还有 Spring JDBC 吗。注意，Spring JDBC 不是 ORM 框架。
+
+## 在 Spring 框架中如何更有效地使用 JDBC ？
+
+Spring 提供了 Spring JDBC 框架，方便我们使用 JDBC 。
+
+对于开发者，只需要使用 JdbcTemplate 类，它提供了很多便利的方法解决诸如把数据库数据转变成基本数据类型或对象，执行写好的或可调用的数据库操作语句，提供自定义的数据错误处理。
+
+没有使用过的胖友，可以看看 [《Spring JDBC 访问关系型数据库》](https://www.tianmaying.com/tutorial/spring-jdbc-data-accessing) 文章。
+
+## Spring 数据数据访问层有哪些异常？
+
+通过使用 Spring 数据数据访问层，它统一了各个数据持久层框架的不同异常，统一进行提供 `org.springframework.dao.DataAccessException` 异常及其子类。如下图所示：
+
+[![流程图](03-Spring 面试题.assets/09.jpg)](http://static.iocoder.cn/images/Spring/2018-12-24/09.jpg)流程图
+
+## 使用 Spring 访问 Hibernate 的方法有哪些？
+
+> 艿艿：这个问题很灵异，因为艿艿已经好久不使用 Hibernate 了，所以答案是直接复制的。
+
+我们可以通过两种方式使用 Spring 访问 Hibernate：
+
+- 使用 Hibernate 模板和回调进行控制反转。
+- 扩展 HibernateDAOSupport 并应用 AOP 拦截器节点。
+
+> 艿艿：不过我记得，12 年我用过 Spring JPA 的方式，操作 Hibernate 。具体可参考 [《一起来学 SpringBoot 2.x | 第六篇：整合 Spring Data JPA》](http://www.iocoder.cn/Spring-Boot/battcn/v2-orm-jpa/) 。
+
+当然，我们可以再来看一道 [《JPA 规范与 ORM 框架之间的关系是怎样的呢？》](https://www.cnblogs.com/xiaoheike/p/5150553.html) 。这个问题，我倒是问过面试的候选人，哈哈哈哈。
+
+# 666. 彩蛋
+
+整理 Spring 面试题的过程中，又把 Spring 的知识点又复习了一遍。我突然有点想念，那本被我翻烂的 [《Spring 实战》](https://book.douban.com/subject/26767354/) 。😈 我要买一本原版的！！！
+
+参考与推荐如下文章：
+
+- Java 架构 [《Spring 面试题》](https://yq.aliyun.com/articles/669702)
+- 永顺 [《彻底征服 Spring AOP 之理论篇》](https://segmentfault.com/a/1190000007469968)
+- 陌上桑花开花 [《Java 面试题集（七）– Spring常见面试问题》](https://blog.csdn.net/u014079773/article/details/52453002)
+- 一人浅醉 [《Spring 的 @Transactional 注解详细用法》](https://www.cnblogs.com/yepei/p/4716112.html)
+- dalaoyang [《Spring 面试题》](https://juejin.im/post/5b065000f265da0de45235e6)
\ No newline at end of file
diff --git a/面试题/04-Spring MVC 面试题.assets/01.png b/面试题/04-Spring MVC 面试题.assets/01.png
new file mode 100644
index 0000000..243b463
Binary files /dev/null and b/面试题/04-Spring MVC 面试题.assets/01.png differ
diff --git a/面试题/04-Spring MVC 面试题.assets/02.png b/面试题/04-Spring MVC 面试题.assets/02.png
new file mode 100644
index 0000000..aa2f2a0
Binary files /dev/null and b/面试题/04-Spring MVC 面试题.assets/02.png differ
diff --git a/面试题/04-Spring MVC 面试题.assets/03.png b/面试题/04-Spring MVC 面试题.assets/03.png
new file mode 100644
index 0000000..a21321b
Binary files /dev/null and b/面试题/04-Spring MVC 面试题.assets/03.png differ
diff --git a/面试题/04-Spring MVC 面试题.assets/15300766829012.jpg b/面试题/04-Spring MVC 面试题.assets/15300766829012.jpg
new file mode 100644
index 0000000..2b8d146
Binary files /dev/null and b/面试题/04-Spring MVC 面试题.assets/15300766829012.jpg differ
diff --git a/面试题/04-Spring MVC 面试题.md b/面试题/04-Spring MVC 面试题.md
new file mode 100644
index 0000000..fa580f5
--- /dev/null
+++ b/面试题/04-Spring MVC 面试题.md	
@@ -0,0 +1,486 @@
+# 精尽 Spring MVC 面试题「最新更新时间：2024-02」
+
+以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。
+
+如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的 Spring MVC 面试题的大保健。
+
+而题目的难度，艿艿尽量按照从容易到困难的顺序，逐步下去。
+
+当然，艿艿还是非常推荐胖友去撸一撸 Spring MVC 的源码，特别是如下两篇：
+
+- [《精尽 Spring MVC 源码分析 —— 组件一览》](http://svip.iocoder.cn/Spring-MVC/Components-intro/)
+- [《精尽 Spring MVC 源码分析 —— 请求处理一览》](http://svip.iocoder.cn/Spring-MVC/DispatcherServlet-process-request-intro/)
+
+考虑到 Spring MVC 和 Rest 关系比较大，所以本文一共分成两大块：
+
+- Spring MVC
+- REST
+
+# Spring MVC
+
+## Spring MVC 框架有什么用？
+
+Spring Web MVC 框架提供”模型-视图-控制器”( Model-View-Controller )架构和随时可用的组件，用于开发灵活且松散耦合的 Web 应用程序。
+
+MVC 模式有助于分离应用程序的不同方面，如输入逻辑，业务逻辑和 UI 逻辑，同时在所有这些元素之间提供松散耦合。
+
+## 介绍下 Spring MVC 的核心组件？
+
+Spring MVC 一共有九大核心组件，分别是：
+
+- MultipartResolver
+- LocaleResolver
+- ThemeResolver
+- HandlerMapping
+- HandlerAdapter
+- HandlerExceptionResolver
+- RequestToViewNameTranslator
+- ViewResolver
+- FlashMapManager
+
+虽然很多，但是在前后端分离的架构中，在 [「描述一下 DispatcherServlet 的工作流程？」](https://svip.iocoder.cn/Spring-MVC/Interview/#) 问题中，我们会明白，最关键的只有 HandlerMapping + HandlerAdapter + HandlerExceptionResolver 。
+
+关于每个组件的说明，直接看 [《精尽 Spring MVC 源码分析 —— 组件一览》](http://svip.iocoder.cn/Spring-MVC/Components-intro/) 。
+
+## 描述一下 DispatcherServlet 的工作流程？
+
+DispatcherServlet 的工作流程可以用一幅图来说明：
+
+[![DispatcherServlet 的工作流程](04-Spring MVC 面试题.assets/15300766829012.jpg)](https://blog-pictures.oss-cn-shanghai.aliyuncs.com/15300766829012.jpg)DispatcherServlet 的工作流程
+
+① **发送请求**
+
+用户向服务器发送 HTTP 请求，请求被 Spring MVC 的调度控制器 DispatcherServlet 捕获。
+
+② **映射处理器**
+
+DispatcherServlet 根据请求 URL ，调用 HandlerMapping 获得该 Handler 配置的所有相关的对象（包括 **Handler** 对象以及 Handler 对象对应的**拦截器**），最后以 HandlerExecutionChain 对象的形式返回。
+
+- 即 HandlerExecutionChain 中，包含对应的 **Handler** 对象和**拦截器**们。
+
+> 此处，对应的方法如下：
+>
+> ```
+> > // HandlerMapping.java
+> > 
+> > @Nullable
+> > HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception;
+> >
+> ```
+
+③ **处理器适配**
+
+DispatcherServlet 根据获得的 Handler，选择一个合适的HandlerAdapter 。（附注：如果成功获得 HandlerAdapter 后，此时将开始执行拦截器的 `#preHandler(...)` 方法）。
+
+提取请求 Request 中的模型数据，填充 Handler 入参，开始执行Handler（Controller)。 在填充Handler的入参过程中，根据你的配置，Spring 将帮你做一些额外的工作：
+
+- HttpMessageConverter ：会将请求消息（如 JSON、XML 等数据）转换成一个对象。
+- 数据转换：对请求消息进行数据转换。如 String 转换成 Integer、Double 等。
+- 数据格式化：对请求消息进行数据格式化。如将字符串转换成格式化数字或格式化日期等。
+- 数据验证： 验证数据的有效性（长度、格式等），验证结果存储到 BindingResult 或 Error 中。
+
+Handler(Controller) 执行完成后，向 DispatcherServlet 返回一个 ModelAndView 对象。
+
+> 此处，对应的方法如下：
+>
+> ```
+> > // HandlerAdapter.java
+> > 
+> > @Nullable
+> > ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception;
+> >
+> ```
+
+.
+
+> 图中没有 ④ 。
+
+⑤ **解析视图**
+
+根据返回的 ModelAndView ，选择一个适合的 ViewResolver（必须是已经注册到 Spring 容器中的 ViewResolver)，解析出 View 对象，然后返回给 DispatcherServlet。
+
+> 此处，对应的方法如下：
+>
+> ```
+> > // ViewResolver.java
+> > 
+> > @Nullable
+> > View resolveViewName(String viewName, Locale locale) throws Exception;
+> >
+> ```
+
+⑥ ⑦ **渲染视图** + **响应请求**
+
+ViewResolver 结合 Model 和 View，来渲染视图，并写回给用户( 浏览器 )。
+
+> 此处，对应的方法如下：
+>
+> ```
+> > // View.java
+> > 
+> > void render(@Nullable Map<String, ?> model, HttpServletRequest request, HttpServletResponse response) throws Exception;
+> >
+> ```
+
+------
+
+这样一看，胖友可能有点懵逼，所以还是推荐看看：
+
+- [《精尽 Spring MVC 源码分析 —— 组件一览》](http://svip.iocoder.cn/Spring-MVC/Components-intro/)
+- [《精尽 Spring MVC 源码分析 —— 请求处理一览》](http://svip.iocoder.cn/Spring-MVC/DispatcherServlet-process-request-intro/)
+
+**但是 Spring MVC 的流程真的一定是酱紫么**？
+
+既然这么问，答案当然不是。对于目前主流的架构，前后端已经进行分离了，所以 Spring MVC 只负责 **M**odel 和 **C**ontroller 两块，而将 **V**iew 移交给了前端。所以，在上图中的步骤 ⑤ 和 ⑥ 两步，已经不在需要。
+
+那么变成什么样了呢？在步骤 ③ 中，如果 Handler(Controller) 执行完后，如果判断方法有 `@ResponseBody` 注解，则直接将结果写回给用户( 浏览器 )。
+
+但是 HTTP 是不支持返回 Java POJO 对象的，所以需要将结果使用 [HttpMessageConverter](http://svip.iocoder.cn/Spring-MVC/HandlerAdapter-5-HttpMessageConverter/) 进行转换后，才能返回。例如说，大家所熟悉的 [FastJsonHttpMessageConverter](https://github.com/alibaba/fastjson/wiki/在-Spring-中集成-Fastjson) ，将 POJO 转换成 JSON 字符串返回。
+
+😈 是不是略微有点复杂，还是那句话，撸下源码，捅破这个窗口。当然，如果胖友精力有限，只要看整体流程的几篇即可。
+
+------
+
+嘻嘻，再来补充两个图，这真的是 Spring MVC 非常关键的问题，所以要用心理解。
+
+> FROM [《SpringMVC - 运行流程图及原理分析》](https://blog.csdn.net/J080624/article/details/77990164)
+>
+> **流程示意图**：
+>
+> [![流程示意图](04-Spring MVC 面试题.assets/01.png)](http://static.iocoder.cn/images/Spring/2022-02-21/01.png)流程示意图
+>
+> **代码序列图**：
+>
+> [![代码序列图](04-Spring MVC 面试题.assets/02.png)](http://static.iocoder.cn/images/Spring/2022-02-21/02.png)代码序列图
+>
+> ------
+>
+> FROM [《看透 Spring MVC：源代码分析与实践》](https://item.jd.com/11807414.html) P123
+>
+> **流程示意图**：
+>
+> [![《流程示意图》](04-Spring MVC 面试题.assets/03.png)](http://static.iocoder.cn/images/Spring/2022-02-21/03.png)《流程示意图》
+
+## @Controller 注解有什么用？
+
+`@Controller` 注解，它将一个类标记为 Spring Web MVC **控制器** Controller 。
+
+## @RestController 和 @Controller 有什么区别？
+
+`@RestController` 注解，在 `@Controller` 基础上，增加了 `@ResponseBody` 注解，更加适合目前前后端分离的架构下，提供 Restful API ，返回例如 JSON 数据格式。当然，返回什么样的数据格式，根据客户端的 `"ACCEPT"` 请求头来决定。
+
+## @RequestMapping 注解有什么用？
+
+`@RequestMapping` 注解，用于将特定 HTTP 请求方法映射到将处理相应请求的控制器中的特定类/方法。此注释可应用于两个级别：
+
+- 类级别：映射请求的 URL。
+- 方法级别：映射 URL 以及 HTTP 请求方法。
+
+## @RequestMapping 和 @GetMapping 注解的不同之处在哪里？
+
+- `@RequestMapping` 可注解在类和方法上；`@GetMapping` 仅可注册在方法上。
+- `@RequestMapping` 可进行 GET、POST、PUT、DELETE 等请求方法；`@GetMapping` 是 `@RequestMapping` 的 GET 请求方法的特例，目的是为了提高清晰度。
+
+## 返回 JSON 格式使用什么注解？
+
+可以使用 **`@ResponseBody`** 注解，或者使用包含 `@ResponseBody` 注解的 **`@RestController`** 注解。
+
+当然，还是需要配合相应的支持 JSON 格式化的 HttpMessageConverter 实现类。例如，Spring MVC 默认使用 MappingJackson2HttpMessageConverter 。
+
+## 介绍一下 WebApplicationContext ？
+
+WebApplicationContext 是实现ApplicationContext接口的子类，专门为 WEB 应用准备的。
+
+- 它允许从相对于 Web 根目录的路径中**加载配置文件**，**完成初始化 Spring MVC 组件的工作**。
+- 从 WebApplicationContext 中，可以获取 ServletContext 引用，整个 Web 应用上下文对象将作为属性放置在 ServletContext 中，以便 Web 应用环境可以访问 Spring 上下文。
+
+关于这一块，如果想要详细了解，可以看看如下两篇文章：
+
+- [《精尽 Spring MVC 源码分析 —— 容器的初始化（一）之 Root WebApplicationContext 容器》](http://svip.iocoder.cn/Spring-MVC/context-init-Root-WebApplicationContext/)
+- [《精尽 Spring MVC 源码分析 —— 容器的初始化（二）之 Servlet WebApplicationContext 容器》](http://svip.iocoder.cn/Spring-MVC/context-init-Servlet-WebApplicationContext/)
+
+## Spring MVC 的异常处理？
+
+Spring MVC 提供了异常解析器 HandlerExceptionResolver 接口，将处理器( `handler` )执行时发生的异常，解析( 转换 )成对应的 ModelAndView 结果。代码如下：
+
+```
+// HandlerExceptionResolver.java
+
+public interface HandlerExceptionResolver {
+
+    /**
+     * 解析异常，转换成对应的 ModelAndView 结果
+     */
+    @Nullable
+    ModelAndView resolveException(
+            HttpServletRequest request, HttpServletResponse response, @Nullable Object handler, Exception ex);
+
+}
+```
+
+- 也就是说，如果异常被解析成功，则会返回 ModelAndView 对象。
+- 详细的源码解析，见 [《精尽 Spring MVC 源码解析 —— HandlerExceptionResolver 组件》](http://svip.iocoder.cn/Spring-MVC/HandlerExceptionResolver/) 。
+
+一般情况下，我们使用 `@ExceptionHandler` 注解来实现过异常的处理，可以先看看 [《Spring 异常处理 ExceptionHandler 的使用》](https://www.jianshu.com/p/12e1a752974d) 。
+
+- 一般情况下，艿艿喜欢使用**第三种**。
+
+## Spring MVC 有什么优点？
+
+1. 使用真的真的真的非常**方便**，无论是添加 HTTP 请求方法映射的方法，还是不同数据格式的响应。
+2. 提供**拦截器机制**，可以方便的对请求进行拦截处理。
+3. 提供**异常机制**，可以方便的对异常做统一处理。
+4. 可以任意使用各种**视图**技术，而不仅仅局限于 JSP ，例如 Freemarker、Thymeleaf 等等。
+5. 不依赖于 Servlet API (目标虽是如此，但是在实现的时候确实是依赖于 Servlet 的，当然仅仅依赖 Servlet ，而不依赖 Filter、Listener )。
+
+## Spring MVC 怎样设定重定向和转发 ？
+
+- 结果转发：在返回值的前面加 `"forward:/"` 。
+- 重定向：在返回值的前面加上 `"redirect:/"` 。
+
+当然，目前前后端分离之后，我们作为后端开发，已经很少有机会用上这个功能了。
+
+## Spring MVC 的 Controller 是不是单例？
+
+绝绝绝大多数情况下，Controller 是**单例**。
+
+那么，Controller 里一般不建议存在**共享的变量**。实际场景下，艿艿也没碰到需要使用共享变量的情况。
+
+## Spring MVC 和 Struts2 的异同？
+
+1. 入口
+
+   不同
+
+   - Spring MVC 的入门是一个 Servlet **控制器**。
+   - Struts2 入门是一个 Filter **过滤器**。
+
+2. 配置映射
+
+   不同，
+
+   - Spring MVC 是基于**方法**开发，传递参数是通过**方法形参**，一般设置为**单例**。
+   - Struts2 是基于**类**开发，传递参数是通过**类的属性**，只能设计为**多例**。
+
+- 视图
+
+  不同
+
+  - Spring MVC 通过参数解析器是将 Request 对象内容进行解析成方法形参，将响应数据和页面封装成 **ModelAndView** 对象，最后又将模型数据通过 **Request** 对象传输到页面。其中，如果视图使用 JSP 时，默认使用 **JSTL** 。
+  - Struts2 采用**值栈**存储请求和响应的数据，通过 **OGNL** 存取数据。
+
+当然，更详细的也可以看看 [《面试题：Spring MVC 和 Struts2 的区别》](http://www.voidcn.com/article/p-ylualwcj-c.html) 一文。
+
+## 详细介绍下 Spring MVC 拦截器？
+
+`org.springframework.web.servlet.HandlerInterceptor` ，拦截器接口。代码如下：
+
+```
+// HandlerInterceptor.java
+
+/**
+ * 拦截处理器，在 {@link HandlerAdapter#handle(HttpServletRequest, HttpServletResponse, Object)} 执行之前
+ */
+default boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)
+		throws Exception {
+	return true;
+}
+
+/**
+ * 拦截处理器，在 {@link HandlerAdapter#handle(HttpServletRequest, HttpServletResponse, Object)} 执行成功之后
+ */
+default void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler,
+		@Nullable ModelAndView modelAndView) throws Exception {
+}
+
+/**
+ * 拦截处理器，在 {@link HandlerAdapter#handle(HttpServletRequest, HttpServletResponse, Object)} 执行完之后，无论成功还是失败
+ *
+ * 并且，只有该处理器 {@link #preHandle(HttpServletRequest, HttpServletResponse, Object)} 执行成功之后，才会被执行
+ */
+default void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler,
+		@Nullable Exception ex) throws Exception {
+}
+```
+
+- 一共有三个方法，分别为：
+
+  - `#preHandle(...)` 方法，调用 Controller 方法之**前**执行。
+
+  - `#postHandle(...)` 方法，调用 Controller 方法之**后**执行。
+
+  - ```
+    #afterCompletion(...)
+    ```
+
+     
+
+    方法，处理完 Controller 方法返回结果之
+
+    后
+
+    执行。
+
+    - 例如，页面渲染后。
+    - **当然，要注意，无论调用 Controller 方法是否成功，都会执行**。
+
+- 举个例子：
+
+  - 当俩个拦截器都实现放行操作时，执行顺序为 `preHandle[1] => preHandle[2] => postHandle[2] => postHandle[1] => afterCompletion[2] => afterCompletion[1]` 。
+  - 当第一个拦截器 `#preHandle(...)` 方法返回 `false` ，也就是对其进行拦截时，第二个拦截器是完全不执行的，第一个拦截器只执行 `#preHandle(...)` 部分。
+  - 当第一个拦截器 `#preHandle(...)` 方法返回 `true` ，第二个拦截器 `#preHandle(...)` 返回 `false` ，执行顺序为 `preHandle[1] => preHandle[2] => afterCompletion[1]` 。
+
+- 总结来说：
+
+  - `#preHandle(...)` 方法，按拦截器定义**顺序**调用。若任一拦截器返回 `false` ，则 Controller 方法不再调用。
+  - `#postHandle(...)` 和 `#afterCompletion(...)` 方法，按拦截器定义**逆序**调用。
+  - `#postHandler(...)` 方法，在调用 Controller 方法之**后**执行。
+  - `#afterCompletion(...)` 方法，只有该拦截器在 `#preHandle(...)` 方法返回 `true` 时，才能够被调用，且一定会被调用。为什么“且一定会被调用”呢？即使 `#afterCompletion(...)` 方法，按拦截器定义**逆序**调用时，前面的拦截器发生异常，后面的拦截器还能够调用，**即无视异常**。
+
+------
+
+关于这块，可以看看如下两篇文章：
+
+- [《Spring MVC 多个拦截器执行顺序及拦截器使用方法》](https://blog.csdn.net/amaxiaochen/article/details/77210880) 文章，通过**实践**更加理解。
+- [《精尽 Spring MVC 源码分析 —— HandlerMapping 组件（二）之 HandlerInterceptor》](http://svip.iocoder.cn/Spring-MVC/HandlerMapping-2-HandlerInterceptor/) 文章，通过**源码**更加理解。
+
+## Spring MVC 的拦截器可以做哪些事情？
+
+拦截器能做的事情非常非常非常多，例如：
+
+- 记录访问日志。
+- 记录异常日志。
+- 需要登陆的请求操作，拦截未登陆的用户。
+- …
+
+## Spring MVC 的拦截器和 Filter 过滤器有什么差别？
+
+看了文章 [《过滤器( Filter )和拦截器( Interceptor )的区别》](https://blog.csdn.net/xiaodanjava/article/details/32125687) ，感觉对比的怪怪的。艿艿觉得主要几个点吧：
+
+- **功能相同**：拦截器和 Filter都能实现相应的功能，谁也不比谁强。
+- **容器不同**：拦截器构建在 Spring MVC 体系中；Filter 构建在 Servlet 容器之上。
+- **使用便利性不同**：拦截器提供了三个方法，分别在不同的时机执行；过滤器仅提供一个方法，当然也能实现拦截器的执行时机的效果，就是麻烦一些。
+
+另外，😈 再补充一点小知识。我们会发现，拓展性好的框架，都会提供相应的拦截器或过滤器机制，方便的我们做一些拓展。例如：
+
+- Dubbo 的 Filter 机制。
+- Spring Cloud Gateway 的 Filter 机制。
+- Struts2 的拦截器机制。
+
+# REST
+
+本小节的内容，基本是基于 [《排名前 20 的 REST 和 Spring MVC 面试题》](http://www.spring4all.com/article/1445) 之上，做增补。
+
+## REST 代表着什么?
+
+REST 代表着抽象状态转移，它是根据 HTTP 协议从客户端发送数据到服务端，例如：服务端的一本书可以以 XML 或 JSON 格式传递到客户端。
+
+然而，假如你不熟悉REST，我建议你先看看 [REST API design and development](http://bit.ly/2zIGzWK) 这篇文章来更好的了解它。不过对于大多数胖友的英语，可能不太好，所以也可以阅读知乎上的 [《怎样用通俗的语言解释 REST，以及 RESTful？》](https://www.zhihu.com/question/28557115) 讨论。
+
+## 资源是什么?
+
+资源是指数据在 REST 架构中如何显示的。将实体作为资源公开 ，它允许客户端通过 HTTP 方法如：[GET](http://javarevisited.blogspot.sg/2012/03/get-post-method-in-http-and-https.html), [POST](http://www.java67.com/2014/08/difference-between-post-and-get-request.html),[PUT](http://www.java67.com/2016/09/when-to-use-put-or-post-in-restful-web-services.html), DELETE 等读，写，修改和创建资源。
+
+## 什么是安全的 REST 操作?
+
+REST 接口是通过 HTTP 方法完成操作。
+
+- 一些HTTP操作是安全的，如 GET 和 HEAD ，它不能在服务端修改资源
+- 换句话说，PUT,POST 和 DELETE 是不安全的，因为他们能修改服务端的资源。
+
+所以，是否安全的界限，在于**是否修改**服务端的资源。
+
+## 什么是幂等操作? 为什么幂等操作如此重要?
+
+有一些HTTP方法，如：GET，不管你使用多少次它都能产生相同的结果，在没有任何一边影响的情况下，发送多个 GET 请求到相同的[URI](http://www.java67.com/2013/01/difference-between-url-uri-and-urn.html) 将会产生相同的响应结果。因此，这就是所谓**幂等**操作。
+
+换句话说，[POST方法不是幂等操作](http://javarevisited.blogspot.sg/2016/05/what-are-idempotent-and-safe-methods-of-HTTP-and-REST.html) ，因为如果发送多个 POST 请求，它将在服务端创建不同的资源。但是，假如你用PUT更新资源，它将是幂等操作。
+
+甚至多个 PUT 请求被用来更新服务端资源，将得到相同的结果。你可以通过 Pluralsight 学习 [HTTP Fundamentals](http://pluralsight.pxf.io/c/1193463/424552/7490?u=https%3A%2F%2Fwww.pluralsight.com%2Fcourses%2Fxhttp-fund) 课程来了解 HTTP 协议和一般的 HTTP 的更多幂等操作。
+
+## REST 是可扩展的或说是协同的吗?
+
+是的，[REST](http://javarevisited.blogspot.sg/2015/08/difference-between-soap-and-restfull-webservice-java.html) 是可扩展的和可协作的。它既不托管一种特定的技术选择，也不定在客户端或者服务端。你可以用 [Java](http://javarevisited.blogspot.sg/2017/11/top-5-free-java-courses-for-beginners.html), [C++](http://www.java67.com/2018/02/5-free-cpp-courses-to-learn-programming.html), [Python](http://www.java67.com/2018/02/5-free-python-online-courses-for-beginners.html), 或 [JavaScript](http://www.java67.com/2018/04/top-5-free-javascript-courses-to-learn.html) 来创建 RESTful Web 服务，也可以在客户端使用它们。
+
+我建议你读一本关于REST接口的书来了解更多，如：[RESTful Web Services](http://javarevisited.blogspot.sg/2017/02/top-5-books-to-learn-rest-and-restful-web-services-in-java.html) 。
+
+> 艿艿：所以这里的“可拓展”、“协同”对应到我们平时常说的，“跨语言”、“语言无关”。
+
+## REST 用哪种 HTTP 方法呢?
+
+REST 能用任何的 HTTP 方法，但是，最受欢迎的是：
+
+- 用 GET 来检索服务端资源
+- 用 POST 来创建服务端资源
+- [用 PUT 来更新服务端资源](http://javarevisited.blogspot.sg/2016/04/what-is-purpose-of-http-request-types-in-RESTful-web-service.html#axzz56WGunSwy)
+- 用 DELETE 来删除服务端资源。
+
+恰好，这四个操作，对上我们日常逻辑的 CRUD 操作。
+
+> 艿艿：经常能听到胖友抱怨自己做的都是 CRUD 的功能。看了这个面试题，有没觉得原来 CRUD 也能玩的稍微高级一点？！
+>
+> 实际上，每个 CRUD 也是可以通过不断的打磨，玩的很高级。例如说 DDD 领域驱动，完整的单元测试，可扩展的设计。
+
+## 删除的 HTTP 状态返回码是什么 ?
+
+在删除成功之后，您的 REST API 应该返回什么状态代码，并没有严格的规则。它可以返回 200 或 204 没有内容。
+
+- 一般来说，如果删除操作成功，响应主体为空，返回 [204](http://www.netingcn.com/http-status-204.html) 。
+- 如果删除请求成功且响应体不是空的，则返回 200 。
+
+## REST API 是无状态的吗?
+
+**是的**，REST API 应该是无状态的，因为它是基于 HTTP 的，它也是无状态的。
+
+REST API 中的请求应该包含处理它所需的所有细节。它**不应该**依赖于以前或下一个请求或服务器端维护的一些数据，例如会话。
+
+**REST 规范为使其无状态设置了一个约束，在设计 REST API 时，您应该记住这一点**。
+
+## REST安全吗? 你能做什么来保护它?
+
+安全是一个宽泛的术语。它可能意味着消息的安全性，这是通过认证和授权提供的加密或访问限制提供的。
+
+REST 通常不是安全的，但是您可以通过使用 Spring Security 来保护它。
+
+- 至少，你可以通过在 Spring Security 配置文件中使用 HTTP 来启用 HTTP Basic Auth 基本认证。
+- 类似地，如果底层服务器支持 HTTPS ，你可以使用 HTTPS 公开 REST API 。
+
+## RestTemplate 的优势是什么?
+
+在 Spring Framework 中，RestTemplate 类是 [模板方法模式](http://www.java67.com/2012/09/top-10-java-design-pattern-interview-question-answer.html) 的实现。跟其他主流的模板类相似，如 JdbcTemplate 或 JmsTempalte ，它将在客户端简化跟 RESTful Web 服务的集成。正如在 RestTemplate 例子中显示的一样，你能非常容易地用它来调用 RESTful Web 服务。
+
+> 艿艿：当然，实际场景我还是更喜欢使用 [OkHttp](http://square.github.io/okhttp/) 作为 HTTP 库，因为更好的性能，使用也便捷，并且无需依赖 Spring 库。
+
+## HttpMessageConverter 在 Spring REST 中代表什么?
+
+HttpMessageConverter 是一种[策略接口](http://www.java67.com/2014/12/strategy-pattern-in-java-with-example.html) ，它指定了一个转换器，它可以转换 HTTP 请求和响应。Spring REST 用这个接口转换 HTTP 响应到多种格式，例如：JSON 或 XML 。
+
+每个 HttpMessageConverter 实现都有一种或几种相关联的MIME协议。Spring 使用 `"Accept"` 的标头来确定客户端所期待的内容类型。
+
+然后，它将尝试找到一个注册的 HTTPMessageConverter ，它能够处理特定的内容类型，并使用它将响应转换成这种格式，然后再将其发送给客户端。
+
+如果胖友对 HttpMessageConverter 不了解，可以看看 [《Spring 中 HttpMessageConverter 详解》](https://leokongwq.github.io/2017/06/14/spring-MessageConverter.html) 。
+
+## 如何创建 HttpMessageConverter 的自定义实现来支持一种新的请求/响应？
+
+我们仅需要创建自定义的 AbstractHttpMessageConverter 的实现，并使用 WebMvcConfigurerAdapter 的 `#extendMessageConverters(List<HttpMessageConverter<?>> converters)` 方法注中册它，该方法可以生成一种新的请求 / 响应类型。
+
+具体的示例，可以学习 [《在 Spring 中集成 Fastjson》](https://github.com/alibaba/fastjson/wiki/在-Spring-中集成-Fastjson) 文章。
+
+## @PathVariable 注解，在 Spring MVC 做了什么? 为什么 REST 在 Spring 中如此有用？
+
+`@PathVariable` 注解，是 Spring MVC 中有用的注解之一，它允许您从 URI 读取值，比如查询参数。它在使用 Spring 创建 RESTful Web 服务时特别有用，因为在 REST 中，资源标识符是 URI 的一部分。
+
+具体的使用示例，胖友如果不熟悉，可以看看 [《Spring MVC 的 @RequestParam 注解和 @PathVariable 注解的区别》](https://blog.csdn.net/cx361006796/article/details/52829759) 。
+
+# 666. 彩蛋
+
+文末的文末，艿艿还是那句话！！！！还是非常推荐胖友去撸一撸 Spring MVC 的源码，特别是如下两篇：
+
+- [《精尽 Spring MVC 源码分析 —— 组件一览》](http://svip.iocoder.cn/Spring-MVC/Components-intro/)
+- [《精尽 Spring MVC 源码分析 —— 请求处理一览》](http://svip.iocoder.cn/Spring-MVC/DispatcherServlet-process-request-intro/)
+
+参考和推荐如下文章：
+
+- [《排名前 20 的 REST 和 Spring MVC 面试题》](http://www.spring4all.com/article/1445)
+- [《跟着 Github 学习 Restful HTTP API 的优雅设计》](http://www.iocoder.cn/Fight/Learn-Restful-HTTP-API-design-from-Github/)
\ No newline at end of file
diff --git a/面试题/05-Spring Boot 面试题.assets/01.png b/面试题/05-Spring Boot 面试题.assets/01.png
new file mode 100644
index 0000000..14571b7
Binary files /dev/null and b/面试题/05-Spring Boot 面试题.assets/01.png differ
diff --git a/面试题/05-Spring Boot 面试题.assets/02.png b/面试题/05-Spring Boot 面试题.assets/02.png
new file mode 100644
index 0000000..a0f11f3
Binary files /dev/null and b/面试题/05-Spring Boot 面试题.assets/02.png differ
diff --git a/面试题/05-Spring Boot 面试题.assets/03.png b/面试题/05-Spring Boot 面试题.assets/03.png
new file mode 100644
index 0000000..183b0cc
Binary files /dev/null and b/面试题/05-Spring Boot 面试题.assets/03.png differ
diff --git a/面试题/05-Spring Boot 面试题.assets/04.png b/面试题/05-Spring Boot 面试题.assets/04.png
new file mode 100644
index 0000000..927878f
Binary files /dev/null and b/面试题/05-Spring Boot 面试题.assets/04.png differ
diff --git a/面试题/05-Spring Boot 面试题.assets/05.png b/面试题/05-Spring Boot 面试题.assets/05.png
new file mode 100644
index 0000000..02c04df
Binary files /dev/null and b/面试题/05-Spring Boot 面试题.assets/05.png differ
diff --git a/面试题/05-Spring Boot 面试题.md b/面试题/05-Spring Boot 面试题.md
new file mode 100644
index 0000000..daf5998
--- /dev/null
+++ b/面试题/05-Spring Boot 面试题.md	
@@ -0,0 +1,802 @@
+# 精尽 Spring Boot 面试题「最新更新时间：2024-02」
+
+以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。
+
+如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的 Spring Boot 面试题的大保健。
+
+而题目的难度，艿艿尽量按照从容易到困难的顺序，逐步下去。
+
+在内容上，我们会分成两大块：
+
+- 核心技术篇，分享 Spring Boot 的核心技术相关的内容。
+- 整合篇，分享 Spring Boot 整合一些框架的面试题，例如 JPA 如何集成到 Spring Boot 中。
+
+# 核心技术篇
+
+## Spring Boot 是什么？
+
+[Spring Boot](https://github.com/spring-projects/spring-boot) 是 Spring 的**子项目**，正如其名字，提供 Spring 的引导( **Boot** )的功能。
+
+通过 Spring Boot ，我们开发者可以快速配置 Spring 项目，引入各种 Spring MVC、Spring Transaction、Spring AOP、MyBatis 等等框架，而无需不断重复编写繁重的 Spring 配置，降低了 Spring 的使用成本。
+
+> 艿艿：犹记当年，Spring XML 为主的时代，大晚上各种搜索 Spring 的配置，苦不堪言。现在有了 Spring Boot 之后，生活真美好。
+
+Spring Boot 提供了各种 Starter 启动器，提供标准化的默认配置。例如：
+
+- [`spring-boot-starter-web`](https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-web/2.1.1.RELEASE) 启动器，可以快速配置 Spring MVC 。
+- [`mybatis-spring-boot-starter`](https://mvnrepository.com/artifact/org.mybatis.spring.boot/mybatis-spring-boot-starter/1.3.2) 启动器，可以快速配置 MyBatis 。
+
+并且，Spring Boot 基本已经一统 Java 项目的开发，大量的开源项目都实现了其的 Starter 启动器。例如：
+
+- [`incubator-dubbo-spring-boot-project`](https://github.com/apache/incubator-dubbo-spring-boot-project) 启动器，可以快速配置 Dubbo 。
+- [`rocketmq-spring-boot-starter`](https://github.com/maihaoche/rocketmq-spring-boot-starter) 启动器，可以快速配置 RocketMQ 。
+
+## Spring Boot 提供了哪些核心功能？
+
+- 1、独立运行 Spring 项目
+
+  Spring Boot 可以以 jar 包形式独立运行，运行一个 Spring Boot 项目只需要通过 `java -jar xx.jar` 来运行。
+
+- 2、内嵌 Servlet 容器
+
+  Spring Boot 可以选择内嵌 Tomcat、Jetty 或者 Undertow，这样我们无须以 war 包形式部署项目。
+
+  > 第 2 点是对第 1 点的补充，在 Spring Boot 未出来的时候，大多数 Web 项目，是打包成 war 包，部署到 Tomcat、Jetty 等容器。
+
+- 3、提供 Starter 简化 Maven 配置
+
+  Spring 提供了一系列的 starter pom 来简化 Maven 的依赖加载。例如，当你使用了 `spring-boot-starter-web` ，会自动加入如下依赖：[![`spring-boot-starter-web` 的 pom 文件](05-Spring Boot 面试题.assets/01.png)](http://static.iocoder.cn/images/Spring/2018-12-26/01.png)`spring-boot-starter-web` 的 pom 文件
+
+- 4、[自动配置 Spring Bean](https://www.jianshu.com/p/ddb6e32e3faf)
+
+  Spring Boot 检测到特定类的存在，就会针对这个应用做一定的配置，进行自动配置 Bean ，这样会极大地减少我们要使用的配置。
+
+  当然，Spring Boot 只考虑大多数的开发场景，并不是所有的场景，若在实际开发中我们需要配置Bean ，而 Spring Boot 没有提供支持，则可以自定义自动配置进行解决。
+
+- 5、[准生产的应用监控](https://blog.csdn.net/wangshuang1631/article/details/72810412)
+
+  Spring Boot 提供基于 HTTP、JMX、SSH 对运行时的项目进行监控。
+
+- 6、无代码生成和 XML 配置
+
+  Spring Boot 没有引入任何形式的代码生成，它是使用的 Spring 4.0 的条件 `@Condition` 注解以实现根据条件进行配置。同时使用了 Maven /Gradle 的**依赖传递解析机制**来实现 Spring 应用里面的自动配置。
+
+  > 第 6 点是第 3 点的补充。
+
+## Spring Boot 有什么优缺点？
+
+> 艿艿：任何技术栈，有优点必有缺点，没有银弹。
+>
+> 另外，这个问题的回答，我们是基于 [《Spring Boot浅谈(是什么/能干什么/优点和不足)》](https://blog.csdn.net/fly_zhyu/article/details/76407830) 整理，所以胖友主要看下这篇文章。
+
+**Spring Boot 的优点**
+
+> 艿艿：优点和 [「Spring Boot 提供了哪些核心功能？」](https://svip.iocoder.cn/Spring-Boot/Interview/#) 问题的答案，是比较重叠的。
+
+- 1、使【编码】变简单。
+- 2、使【配置】变简单。
+- 3、使【部署】变简单。
+- 4、使【监控】变简单。
+
+**Spring Boot 的缺点**
+
+> 艿艿：如下的缺点，基于 [《Spring Boot浅谈(是什么/能干什么/优点和不足)》](https://blog.csdn.net/fly_zhyu/article/details/76407830)，考虑的出发点是把 Spring Boot 作为微服务的框架的选型的角度进行考虑。
+
+- 1、没有提供相应的【服务发现和注册】的配套功能。
+
+  > 艿艿：当然，实际上 Spring Boot 本身是不需要提供这样的功能。服务发现和注册的功能，是在 Spring Cloud 中进行提供。
+
+- 2、自身的 acturator 所提供的【监控功能】，也需要与现有的监控对接。
+
+- 3、没有配套的【安全管控】方案。
+
+  > 艿艿：关于这一点，艿艿也有点迷糊，Spring Security 是可以比较方便的集成到 Spring Boot 中，所以不晓得这里的【安全管控】的定义是什么。所以这一点，面试的时候回答，可以暂时先省略。
+
+- 4、对于 REST 的落地，还需要自行结合实际进行 URI 的规范化工作
+
+  > 艿艿：这个严格来说，不算缺点。本身，是规范的范畴。
+
+所以，上面的缺点，严格来说可能不太适合在面试中回答。艿艿认为，Spring Boot 的缺点主要是，因为自动配置 Spring Bean 的功能，我们可能无法知道，哪些 Bean 被进行创建了。这个时候，如果我们想要自定义一些 Bean ，可能存在冲突，或者不知道实际注入的情况。
+
+## Spring Boot、Spring MVC 和 Spring 有什么区别？
+
+Spring 的完整名字，应该是 Spring Framework 。它提供了多个模块，Spring IoC、Spring AOP、Spring MVC 等等。所以，Spring MVC 是 Spring Framework 众多模块中的一个。
+
+而 Spring Boot 是构造在 Spring Framework 之上的 Boot 启动器，旨在更容易的配置一个 Spring 项目。
+
+总结说来，如下图所示：[![Spring Boot 对比 Spring MVC 对比 Spring ？](05-Spring Boot 面试题.assets/02.png)](http://static.iocoder.cn/images/Spring/2018-12-26/02.png)Spring Boot 对比 Spring MVC 对比 Spring ？
+
+## Spring Boot 中的 Starter 是什么？
+
+比较**通俗**的说法：
+
+> FROM [《Spring Boot 中 Starter 是什么》](https://www.cnblogs.com/EasonJim/p/7615801.html)
+>
+> 比如我们要在 Spring Boot 中引入 Web MVC 的支持时，我们通常会引入这个模块 `spring-boot-starter-web` ，而这个模块如果解压包出来会发现里面什么都没有，只定义了一些 **POM** 依赖。如下图所示：[![`spring-boot-starter-web`](05-Spring Boot 面试题.assets/03.png)](http://static.iocoder.cn/images/Spring/2018-12-26/03.png)`spring-boot-starter-web`
+>
+> 经过研究，Starter 主要用来简化依赖用的。比如我们之前做MVC时要引入日志组件，那么需要去找到log4j的版本，然后引入，现在有了Starter之后，直接用这个之后，log4j就自动引入了，也不用关心版本这些问题。
+
+比较**书名**的说法：
+
+> FROM [《Spring Boot Starter 介绍》](http://www.importnew.com/27101.html)
+>
+> 依赖管理是任何复杂项目的关键部分。以手动的方式来实现依赖管理不太现实，你得花更多时间，同时你在项目的其他重要方面能付出的时间就会变得越少。
+>
+> Spring Boot Starter 就是为了解决这个问题而诞生的。Starter **POM** 是一组方便的依赖描述符，您可以将其包含在应用程序中。您可以获得所需的所有 Spring 和相关技术的一站式服务，无需通过示例代码搜索和复制粘贴依赖。
+
+## Spring Boot 常用的 Starter 有哪些？
+
+- `spring-boot-starter-web` ：提供 Spring MVC + 内嵌的 Tomcat 。
+- `spring-boot-starter-data-jpa` ：提供 Spring JPA + Hibernate 。
+- `spring-boot-starter-data-redis` ：提供 Redis 。
+- `mybatis-spring-boot-starter` ：提供 MyBatis 。
+
+## 创建一个 Spring Boot Project 的最简单的方法是什么？
+
+Spring Initializr 是创建 Spring Boot Projects 的一个很好的工具。打开 `"https://start.spring.io/"` 网站，我们可以看到 Spring Initializr 工具，如下图所示：
+
+[![Spring Initializr](05-Spring Boot 面试题.assets/04.png)](http://static.iocoder.cn/images/Spring/2018-12-26/04.png)Spring Initializr
+
+- 图中的每一个**红线**，都可以填写相应的配置。相信胖友都很熟悉，就不哔哔了。
+- 点击生 GenerateProject ，生成 Spring Boot Project 。
+- 将项目导入 IDEA ，记得选择现有的 Maven 项目。
+
+------
+
+当然，我们以前使用 IDEA 创建 Spring 项目的方式，也一样能创建 Spring Boot Project 。Spring Initializr 更多的是，提供一个便捷的工具。
+
+## 如何统一引入 Spring Boot 版本？
+
+**目前有两种方式**。
+
+① 方式一：继承 `spring-boot-starter-parent` 项目。配置代码如下：
+
+```
+<parent>
+    <groupId>org.springframework.boot</groupId>
+    <artifactId>spring-boot-starter-parent</artifactId>
+    <version>1.5.1.RELEASE</version>
+</parent>
+```
+
+② 方式二：导入 spring-boot-dependencies 项目依赖。配置代码如下：
+
+```
+<dependencyManagement>
+    <dependencies>
+        <dependency>
+            <groupId>org.springframework.boot</groupId>
+            <artifactId>spring-boot-dependencies</artifactId>
+            <version>1.5.1.RELEASE</version>
+            <type>pom</type>
+            <scope>import</scope>
+        </dependency>
+    </dependencies>
+</dependencyManagement>
+```
+
+**如何选择？**
+
+因为一般我们的项目中，都有项目自己的 Maven parent 项目，所以【方式一】显然会存在冲突。所以实际场景下，推荐使用【方式二】。
+
+详细的，推荐阅读 [《Spring Boot 不使用默认的 parent，改用自己的项目的 parent》](https://blog.csdn.net/rainbow702/article/details/55046298) 文章。
+
+另外，在使用 Spring Cloud 的时候，也可以使用这样的方式。
+
+## 运行 Spring Boot 有哪几种方式？
+
+- 1、打包成 Fat Jar ，直接使用 `java -jar` 运行。目前主流的做法，推荐。
+- 2、在 IDEA 或 Eclipse 中，直接运行应用的 Spring Boot 启动类的 `#main(String[] args)` 启动。适用于开发调试场景。
+- 3、如果是 Web 项目，可以打包成 War 包，使用外部 Tomcat 或 Jetty 等容器。
+
+## 如何打包 Spring Boot 项目？
+
+通过引入 `spring-boot-maven-plugin` 插件，执行 `mvn clean package` 命令，将 Spring Boot 项目打成一个 Fat Jar 。后续，我们就可以直接使用 `java -jar` 运行。
+
+关于 `spring-boot-maven-plugin` 插件，更多详细的可以看看 [《创建可执行 jar》](https://qbgbook.gitbooks.io/spring-boot-reference-guide-zh/II. Getting started/11.5. Creating an executable jar.html) 。
+
+## 如果更改内嵌 Tomcat 的端口？
+
+- 方式一，修改 `application.properties` 配置文件的 `server.port` 属性。
+
+  ```
+  server.port=9090
+  ```
+
+- 方式二，通过启动命令增加 `server.port` 参数进行修改。
+
+  ```
+  java -jar xxx.jar --server.port=9090
+  ```
+
+当然，以上的方式，不仅仅适用于 Tomcat ，也适用于 Jetty、Undertow 等服务器。
+
+## 如何重新加载 Spring Boot 上的更改，而无需重新启动服务器？
+
+一共有三种方式，可以实现效果：
+
+- 【推荐】`spring-boot-devtools` 插件。注意，这个工具需要配置 IDEA 的自动编译。
+
+- Spring Loaded 插件。
+
+  > Spring Boot 2.X 后，官方宣布不再支持 Spring Loaded 插件 的更新，所以基本可以无视它了。
+
+- [JRebel](https://www.jianshu.com/p/bab43eaa4e14) 插件，需要付费。
+
+关于如何使用 `spring-boot-devtools` 和 Spring Loaded 插件，胖友可以看看 [《Spring Boot 学习笔记：Spring Boot Developer Tools 与热部署》](https://segmentfault.com/a/1190000014488100) 。
+
+## Spring Boot 的配置文件有哪几种格式？
+
+Spring Boot 目前支持两种格式的配置文件：
+
+- `.properties` 格式。示例如下：
+
+  ```
+  server.port = 9090
+  ```
+
+- `.yaml` 格式。示例如下：
+
+  ```
+  server:
+      port: 9090
+  ```
+
+------
+
+可能有胖友不了解 **YAML 格式**？
+
+YAML 是一种人类可读的数据序列化语言，它通常用于配置文件。
+
+- 与 Properties 文件相比，如果我们想要在配置文件中添加复杂的属性 YAML 文件就更加**结构化**。从上面的示例，我们可以看出 YAML 具有**分层**配置数据。
+
+- 当然 YAML 在 Spring 会存在一个缺陷，
+
+  `@PropertySource`
+
+   
+
+  注解不支持读取 YAML 配置文件，仅支持 Properties 配置文件。
+
+  - 不过这个问题也不大，可以麻烦一点使用 [`@Value`](https://blog.csdn.net/lafengwnagzi/article/details/74178374) 注解，来读取 YAML 配置项。
+
+实际场景下，艿艿相对比较喜欢使用 Properties 配置文件。个人喜欢~当然，YAML 已经越来越流行了。
+
+## Spring Boot 默认配置文件是什么？
+
+对于 Spring Boot 应用，默认的配置文件根目录下的 **application** 配置文件，当然可以是 Properties 格式，也可以是 YAML 格式。
+
+可能有胖友说，我在网上看到面试题中，说还有一个根目录下的 **bootstrap** 配置文件。这个是 Spring Cloud 新增的启动配置文件，[需要引入 `spring-cloud-context` 依赖后，才会进行加载](https://my.oschina.net/freeskyjs/blog/1843048)。它的特点和用途主要是：
+
+> 参考 [《Spring Cloud 中配置文件名 bootstrap.yml 和 application.yml 区别》](https://my.oschina.net/neverforget/blog/1525947) 文章。
+
+- 【特点】因为 bootstrap 由父 ApplicationContext 加载，比 application 优先加载。
+- 【特点】因为 bootstrap 优先于 application 加载，所以不会被它覆盖。
+- 【用途】使用配置中心 Spring Cloud Config 时，需要在 bootstrap 中配置配置中心的地址，从而实现父 ApplicationContext 加载时，从配置中心拉取相应的配置到应用中。
+
+另外，[《Appendix A. Common application properties》](https://docs.spring.io/spring-boot/docs/current/reference/html/common-application-properties.html) 中，有 application 配置文件的通用属性列表。
+
+## Spring Boot 如何定义多套不同环境配置？
+
+可以参考 [《Spring Boot 教程 - Spring Boot Profiles 实现多环境下配置切换》](https://blog.csdn.net/top_code/article/details/78570047) 一文。
+
+但是，需要考虑一个问题，生产环境的配置文件的安全性，显然我们不能且不应该把生产的配置放到项目的 Git 仓库中进行管理。那么应该怎么办呢？
+
+- 方案一，生产环境的配置文件放在生产环境的服务器中，以 `java -jar myproject.jar --spring.config.location=/xxx/yyy/application-prod.properties` 命令，设置 参数 `spring.config.location` 指向配置文件。
+- 方案二，使用 Jenkins 在执行打包，配置上 Maven Profile 功能，使用服务器上的配置文件。😈 整体来说，和【方案一】的差异是，将配置文件打包进了 Jar 包中。
+- 方案三，使用配置中心。
+
+## Spring Boot 配置加载顺序？
+
+在 Spring Boot 中，除了我们常用的 application 配置文件之外，还有：
+
+- 系统环境变量
+- 命令行参数
+- 等等…
+
+参考 [《Externalized Configuration》](https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html) 文档，我们整理顺序如下：
+
+1. ```
+   spring-boot-devtools
+   ```
+
+    
+
+   依赖的
+
+    
+
+   ```
+   spring-boot-devtools.properties
+   ```
+
+    
+
+   配置文件。
+
+   > 这个灰常小众，具体说明可以看看 [《Spring Boot参考文档（12）开发者工具》](https://blog.csdn.net/u011499747/article/details/71746325) ，建议无视。
+
+2. 单元测试上的
+
+    
+
+   ```
+   @TestPropertySource
+   ```
+
+    
+
+   和
+
+    
+
+   ```
+   @SpringBootTest
+   ```
+
+    
+
+   注解指定的参数。
+
+   > 前者的优先级高于后者。可以看看 [《Spring、Spring Boot 和TestNG 测试指南 - @TestPropertySource》](https://segmentfault.com/a/1190000010854607) 一文。
+
+3. 命令行指定的参数。例如 `java -jar springboot.jar --server.port=9090` 。
+
+4. 命令行中的 `spring.application.json` 指定参数。例如 `java -Dspring.application.json='{"name":"Java"}' -jar springboot.jar` 。
+
+5. ServletConfig 初始化参数。
+
+6. ServletContext 初始化参数。
+
+7. JNDI 参数。例如 `java:comp/env` 。
+
+8. Java 系统变量，即 `System#getProperties()` 方法对应的。
+
+9. 操作系统环境变量。
+
+10. RandomValuePropertySource 配置的 `random.*` 属性对应的值。
+
+11. Jar **外部**的带指定 profile 的 application 配置文件。例如 `application-{profile}.yaml` 。
+
+12. Jar **内部**的带指定 profile 的 application 配置文件。例如 `application-{profile}.yaml` 。
+
+13. Jar **外部** application 配置文件。例如 `application.yaml` 。
+
+14. Jar **内部** application 配置文件。例如 `application.yaml` 。
+
+15. 在自定义的 `@Configuration` 类中定于的 `@PropertySource` 。
+
+16. 启动的 main 方法中，定义的默认配置。即通过 `SpringApplication#setDefaultProperties(Map<String, Object> defaultProperties)` 方法进行设置。
+
+嘿嘿，是不是很多很长，不用真的去记住。
+
+- 一般来说，面试官不会因为这个题目回答的不好，对你扣分。
+- 实际使用时，做下测试即可。
+- 每一种配置方式的详细说明，可以看看 [《Spring Boot 参考指南（外部化配置）》](https://segmentfault.com/a/1190000015069140) 。
+
+## Spring Boot 有哪些配置方式？
+
+和 Spring 一样，一共提供了三种方式。
+
+- 1、XML 配置文件。
+
+  Bean 所需的依赖项和服务在 XML 格式的配置文件中指定。这些配置文件通常包含许多 bean 定义和特定于应用程序的配置选项。它们通常以 bean 标签开头。例如：
+
+  ```
+  <bean id="studentBean" class="org.edureka.firstSpring.StudentBean">
+      <property name="name" value="Edureka"></property>
+  </bean>
+  ```
+
+- 2、注解配置。
+
+  您可以通过在相关的类，方法或字段声明上使用注解，将 Bean 配置为组件类本身，而不是使用 XML 来描述 Bean 装配。默认情况下，Spring 容器中未打开注解装配。因此，您需要在使用它之前在 Spring 配置文件中启用它。例如：
+
+  ```
+  <beans>
+  <context:annotation-config/>
+  <!-- bean definitions go here -->
+  </beans>
+  ```
+
+- 3、Java Config 配置。
+
+  Spring 的 Java 配置是通过使用 @Bean 和 @Configuration 来实现。
+
+  - `@Bean` 注解扮演与 `<bean />` 元素相同的角色。
+
+  - `@Configuration` 类允许通过简单地调用同一个类中的其他 `@Bean` 方法来定义 Bean 间依赖关系。
+
+  - 例如：
+
+    ```
+    @Configuration
+    public class StudentConfig {
+        
+        @Bean
+        public StudentBean myStudent() {
+            return new StudentBean();
+        }
+        
+    }
+    ```
+
+    - 是不是很熟悉 😈
+
+目前主要使用 **Java Config** 配置为主。当然，三种配置方式是可以混合使用的。例如说：
+
+- Dubbo 服务的配置，艿艿喜欢使用 XML 。
+- Spring MVC 请求的配置，艿艿喜欢使用 `@RequestMapping` 注解。
+- Spring MVC 拦截器的配置，艿艿喜欢 Java Config 配置。
+
+------
+
+另外，现在已经是 Spring Boot 的天下，所以更加是 **Java Config** 配置为主。
+
+## Spring Boot 的核心注解是哪个？
+
+```
+package cn.iocoder.skywalking.web01;
+
+import org.springframework.boot.SpringApplication;
+import org.springframework.boot.autoconfigure.SpringBootApplication;
+
+@SpringBootApplication
+public class Web01Application {
+
+    public static void main(String[] args) {
+        SpringApplication.run(Web01Application.class, args);
+    }
+
+}
+```
+
+- `@SpringBootApplication` 注解，就是 Spring Boot 的核心注解。
+
+`org.springframework.boot.autoconfigure.@SpringBootApplication` 注解的代码如下：
+
+```
+// SpringBootApplication.java
+
+@Target({ElementType.TYPE})
+@Retention(RetentionPolicy.RUNTIME)
+@Documented
+@Inherited
+@SpringBootConfiguration
+@EnableAutoConfiguration
+@ComponentScan(
+    excludeFilters = {@Filter(
+    type = FilterType.CUSTOM,
+    classes = {TypeExcludeFilter.class}
+), @Filter(
+    type = FilterType.CUSTOM,
+    classes = {AutoConfigurationExcludeFilter.class}
+)}
+)
+public @interface SpringBootApplication {
+    @AliasFor(
+        annotation = EnableAutoConfiguration.class
+    )
+    Class<?>[] exclude() default {};
+
+    @AliasFor(
+        annotation = EnableAutoConfiguration.class
+    )
+    String[] excludeName() default {};
+
+    @AliasFor(
+        annotation = ComponentScan.class,
+        attribute = "basePackages"
+    )
+    String[] scanBasePackages() default {};
+
+    @AliasFor(
+        annotation = ComponentScan.class,
+        attribute = "basePackageClasses"
+    )
+    Class<?>[] scanBasePackageClasses() default {};
+}
+```
+
+- 它组合了 3 个注解，详细说明，胖友看看 [《Spring Boot 系列：@SpringBootApplication 注解》](https://blog.csdn.net/claram/article/details/75125749) 。
+
+- `@Configuration` 注解，指定类是 **Bean 定义**的配置类。
+
+  > `@Configuration` 注解，来自 `spring-context` 项目，用于 Java Config ，不是 Spring Boot 新带来的。
+
+- `#ComponentScan` 注解，扫描指定包下的 Bean 们。
+
+  > `@ComponentScan` 注解，来自 `spring-context` 项目，用于 Java Config ，不是 Spring Boot 新带来的。
+
+- `@EnableAutoConfiguration` 注解，打开自动配置的功能。如果我们想要关闭某个类的自动配置，可以设置注解的 `exclude` 或 `excludeName` 属性。
+
+  > `@EnableAutoConfiguration` 注解，来自 `spring-boot-autoconfigure` 项目，**它才是 Spring Boot 新带来的**。
+
+## 什么是 Spring Boot 自动配置？
+
+在 [「Spring Boot 的核心注解是哪个？」](https://svip.iocoder.cn/Spring-Boot/Interview/#) 中，我们已经看到，使用 `@@EnableAutoConfiguration` 注解，打开 Spring Boot 自动配置的功能。具体如何实现的，可以看看如下两篇文章：
+
+- [《@EnableAutoConfiguration 注解的工作原理》](https://www.jianshu.com/p/464d04c36fb1) 。
+- [《一个面试题引起的 Spring Boot 启动解析》](https://juejin.im/post/5b679fbc5188251aad213110)
+- 建议，能一边调试，一边看这篇文章。调试很简单，任一搭建一个 Spring Boot 项目即可。
+
+如下是一个比较简单的总结：
+
+1. Spring Boot 在启动时扫描项目所依赖的 jar 包，寻找包含`spring.factories` 文件的 jar 包。
+2. 根据 `spring.factories` 配置加载 AutoConfigure 类。
+3. 根据 [`@Conditional` 等条件注解](https://svip.iocoder.cn/Spring-Boot/Interview/Spring Boot 条件注解) 的条件，进行自动配置并将 Bean 注入 Spring IoC 中。
+
+## Spring Boot 有哪几种读取配置的方式？
+
+Spring Boot 目前支持 **2** 种读取配置：
+
+1. `@Value` 注解，读取配置到属性。最最最常用。
+
+   > 另外，支持和 `@PropertySource` 注解一起使用，指定使用的配置文件。
+
+2. `@ConfigurationProperties` 注解，读取配置到类上。
+
+   > 另外，支持和 `@PropertySource` 注解一起使用，指定使用的配置文件。
+
+详细的使用方式，可以参考 [《Spring Boot 读取配置的几种方式》](https://aoyouzi.iteye.com/blog/2422837) 。
+
+## 使用 Spring Boot 后，项目结构是怎么样的呢？
+
+我们先来说说项目的分层。一般来说，主流的有两种方式：
+
+- 方式一，`controller`、`service`、`dao` 三个包，每个包下面添加相应的 XXXController、YYYService、ZZZDAO 。
+- 方式二，按照业务模块分包，每个包里面放 Controller、Service、DAO 类。例如，业务模块分成 `user`、`order`、`item` 等等包，在 `user` 包里放 UserController、UserService、UserDAO 类。
+
+那么，使用 Spring Boot 的项目怎么分层呢？艿艿自己的想法
+
+- 现在项目都会进行服务化分拆，每个项目不会特别复杂，所以建议使用【方式一】。
+- 以前的项目，大多是单体的项目，动则项目几万到几十万的代码，当时多采用【方式二】。
+
+下面是一个简单的 Spring Boot 项目的 Demo ，如下所示：[![Spring Boot 项目的 Demo](05-Spring Boot 面试题.assets/05.png)](http://static.iocoder.cn/images/Spring/2018-12-26/05.png)Spring Boot 项目的 Demo
+
+## 如何在 Spring Boot 启动的时候运行一些特殊的代码？
+
+如果需要在 SpringApplication 启动后执行一些特殊的代码，你可以实现 ApplicationRunner 或 CommandLineRunner 接口，这两个接口工作方式相同，都只提供单一的 run 方法，该方法仅在 `SpringApplication#run(...)` 方法**完成之前调用**。
+
+一般情况下，我们不太会使用该功能。如果真需要，胖友可以详细看看 [《使用 ApplicationRunner 或 CommandLineRunner 》](https://qbgbook.gitbooks.io/spring-boot-reference-guide-zh/IV. Spring Boot features/23.8 Using the ApplicationRunner or CommandLineRunner.html) 。
+
+## Spring Boot 2.X 有什么新特性？
+
+1. 起步 JDK 8 和支持 JDK 9
+2. 第三方库的升级
+3. Reactive Spring
+4. HTTP/2 支持
+5. 配置属性的绑定
+6. Gradle 插件
+7. Actuator 改进
+8. 数据支持的改进
+9. Web 的改进
+10. 支持 Quartz 自动配置
+11. 测试的改进
+12. 其它…
+
+详细的说明，可以看看 [《Spring Boot 2.0系列文章(二)：Spring Boot 2.0 新特性详解》](http://www.54tianzhisheng.cn/2018/03/06/SpringBoot2-new-features) 。
+
+# 整合篇
+
+## 如何将内嵌服务器换成 Jetty ？
+
+默认情况下，`spring-boot-starter-web` 模块使用 Tomcat 作为内嵌的服务器。所以需要去除对 `spring-boot-starter-tomcat` 模块的引用，添加 `spring-boot-starter-jetty` 模块的引用。代码如下：
+
+```
+<dependency>
+    <groupId>org.springframework.boot</groupId>
+    <artifactId>spring-boot-starter-web</artifactId>
+    <exclusions>
+        <exclusion> <!-- 去除 Tomcat -->
+            <groupId>org.springframework.boot</groupId>
+            <artifactId>spring-boot-starter-tomcat</artifactId>
+        </exclusion>
+    </exclusions>
+</dependency>
+<dependency> <!-- 引入 Jetty -->
+    <groupId>org.springframework.boot</groupId>
+    <artifactId>spring-boot-starter-jetty</artifactId>
+</dependency>
+```
+
+## Spring Boot 中的监视器 Actuator 是什么？
+
+`spring-boot-actuator` 提供 Spring Boot 的监视器功能，可帮助我们访问生产环境中正在运行的应用程序的**当前状态**。
+
+- 关于 Spring Boot Actuator 的教程，可以看看 [《Spring Boot Actuator 使用》](https://www.jianshu.com/p/af9738634a21) 。
+- 上述教程是基于 Spring Boot 1.X 的版本，如果胖友使用 Spring Boot 2.X 的版本，你将会发现 `/beans` 等 Endpoint 是不存在的，参考 [《Spring boot 2 - Actuator endpoint, where is /beans endpoint》](https://stackoverflow.com/questions/49174700/spring-boot-2-actuator-endpoint-where-is-beans-endpoint) 问题来解决。
+
+**安全性**
+
+Spring Boot 2.X 默认情况下，`spring-boot-actuator` 产生的 Endpoint 是没有安全保护的，但是 Actuator 可能暴露敏感信息。
+
+所以一般的做法是，引入 `spring-boot-start-security` 依赖，使用 Spring Security 对它们进行安全保护。
+
+## 如何集成 Spring Boot 和 Spring MVC ？
+
+1. 引入 `spring-boot-starter-web` 的依赖。
+
+2. 实现 WebMvcConfigurer 接口，可添加自定义的 Spring MVC 配置。
+
+   > 因为 Spring Boot 2 基于 JDK 8 的版本，而 JDK 8 提供 `default` 方法，所以 Spring Boot 2 废弃了 WebMvcConfigurerAdapter 适配类，直接使用 WebMvcConfigurer 即可。
+
+   ```
+   // WebMvcConfigurer.java
+   public interface WebMvcConfigurer {
+   
+       /** 配置路径匹配器 **/
+       default void configurePathMatch(PathMatchConfigurer configurer) {}
+       
+       /** 配置内容裁决的一些选项 **/
+       default void configureContentNegotiation(ContentNegotiationConfigurer configurer) { }
+   
+       /** 异步相关的配置 **/
+       default void configureAsyncSupport(AsyncSupportConfigurer configurer) { }
+   
+       default void configureDefaultServletHandling(DefaultServletHandlerConfigurer configurer) { }
+   
+       default void addFormatters(FormatterRegistry registry) {
+       }
+   
+       /** 添加拦截器 **/
+       default void addInterceptors(InterceptorRegistry registry) { }
+   
+       /** 静态资源处理 **/
+       default void addResourceHandlers(ResourceHandlerRegistry registry) { }
+   
+       /** 解决跨域问题 **/
+       default void addCorsMappings(CorsRegistry registry) { }
+   
+       default void addViewControllers(ViewControllerRegistry registry) { }
+   
+       /** 配置视图解析器 **/
+       default void configureViewResolvers(ViewResolverRegistry registry) { }
+   
+       /** 添加参数解析器 **/
+       default void addArgumentResolvers(List<HandlerMethodArgumentResolver> resolvers) {
+       }
+   
+       /** 添加返回值处理器 **/
+       default void addReturnValueHandlers(List<HandlerMethodReturnValueHandler> handlers) { }
+   
+       /** 这里配置视图解析器 **/
+       default void configureMessageConverters(List<HttpMessageConverter<?>> converters) { }
+   
+       /** 配置消息转换器 **/
+       default void extendMessageConverters(List<HttpMessageConverter<?>> converters) { }
+   
+      /** 配置异常处理器 **/
+       default void configureHandlerExceptionResolvers(List<HandlerExceptionResolver> resolvers) { }
+   
+       default void extendHandlerExceptionResolvers(List<HandlerExceptionResolver> resolvers) { }
+   
+       @Nullable
+       default Validator getValidator() { return null; }
+   
+       @Nullable
+       default MessageCodesResolver getMessageCodesResolver() {  return null; }
+   
+   }
+   ```
+
+------
+
+在使用 Spring MVC 时，我们一般会做如下几件事情：
+
+1. 实现自己项目需要的拦截器，并在 WebMvcConfigurer 实现类中配置。可参见 [MVCConfiguration](https://github.com/YunaiV/oceans/blob/2a2d3746905f1349e260e88049e7e28346c7648f/bff/webapp-bff/src/main/java/cn/iocoder/oceans/webapp/bff/config/MVCConfiguration.java) 类。
+2. 配置 `@ControllerAdvice` + `@ExceptionHandler` 注解，实现全局异常处理。可参见 [GlobalExceptionHandler](https://github.com/YunaiV/oceans/blob/2a2d3746905f1349e260e88049e7e28346c7648f/bff/webapp-bff/src/main/java/cn/iocoder/oceans/webapp/bff/config/GlobalExceptionHandler.java) 类。
+3. 配置 `@ControllerAdvice` ，实现 ResponseBodyAdvice 接口，实现全局统一返回。可参见 [GlobalResponseBodyAdvice](https://github.com/YunaiV/oceans/blob/2a2d3746905f1349e260e88049e7e28346c7648f/bff/webapp-bff/src/main/java/cn/iocoder/oceans/webapp/bff/config/GlobalResponseBodyAdvice.java) 。
+
+当然，有一点需要注意，WebMvcConfigurer、ResponseBodyAdvice、`@ControllerAdvice`、`@ExceptionHandler` 接口，都是 Spring MVC 框架自身已经有的东西。
+
+- `spring-boot-starter-web` 的依赖，帮我们解决的是 Spring MVC 的依赖以及相关的 Tomcat 等组件。
+
+## 如何集成 Spring Boot 和 Spring Security ？
+
+目前比较主流的安全框架有两个：
+
+1. Spring Security
+2. Apache Shiro
+
+对于任何项目来说，安全认证总是少不了，同样适用于使用 Spring Boot 的项目。相对来说，Spring Security 现在会比 Apache Shiro 更流行。
+
+Spring Boot 和 Spring Security 的配置方式比较简单：
+
+1. 引入 `spring-boot-starter-security` 的依赖。
+2. 继承 WebSecurityConfigurerAdapter ，添加**自定义**的安全配置。
+
+当然，每个项目的安全配置是不同的，需要胖友自己选择。更多详细的使用，建议认真阅读如下文章：
+
+- [《Spring Boot中 使用 Spring Security 进行安全控制》](http://blog.didispace.com/springbootsecurity/) ，快速上手。
+- [《Spring Security 实现原理与源码解析系统 —— 精品合集》](http://www.iocoder.cn/Spring-Security/good-collection/) ，深入源码。
+
+另外，安全是一个很大的话题，感兴趣的胖友，可以看看 [《Spring Boot 十种安全措施》](https://www.jdon.com/49653) 一文。
+
+## 如何集成 Spring Boot 和 Spring Security OAuth2 ？
+
+参见 [《Spring Security OAuth2 入门》](http://www.iocoder.cn/Spring-Security/OAuth2-learning/) 文章，内容有点多。
+
+## 如何集成 Spring Boot 和 JPA ？
+
+1. 引入 `spring-boot-starter-data-jpa` 的依赖。
+2. 在 application 配置文件中，加入 JPA 相关的少量配置。当然，数据库的配置也要添加进去。
+3. 具体编码。
+
+详细的使用，胖友可以参考：
+
+- [《一起来学 SpringBoot 2.x | 第六篇：整合 Spring Data JPA》](http://www.iocoder.cn/Spring-Boot/battcn/v2-orm-jpa/)
+
+有两点需要注意：
+
+- Spring Boot 2 默认使用的数据库连接池是 [HikariCP](https://github.com/brettwooldridge/HikariCP) ，目前最好的性能的数据库连接池的实现。
+- `spring-boot-starter-data-jpa` 的依赖，使用的默认 JPA 实现是 Hibernate 5.X 。
+
+## 如何集成 Spring Boot 和 MyBatis ？
+
+1. 引入 `mybatis-spring-boot-starter` 的依赖。
+2. 在 application 配置文件中，加入 MyBatis 相关的少量配置。当然，数据库的配置也要添加进去。
+3. 具体编码。
+
+详细的使用，胖友可以参考：
+
+- [《一起来学 SpringBoot 2.x | 第七篇：整合 Mybatis》](http://www.iocoder.cn/Spring-Boot/battcn/v2-orm-mybatis/)
+
+## 如何集成 Spring Boot 和 RabbitMQ ？
+
+1. 引入 `spring-boot-starter-amqp` 的依赖
+2. 在 application 配置文件中，加入 RabbitMQ 相关的少量配置。
+3. 具体编码。
+
+详细的使用，胖友可以参考：
+
+- [《一起来学 SpringBoot 2.x | 第十二篇：初探 RabbitMQ 消息队列》](http://www.iocoder.cn/Spring-Boot/battcn/v2-queue-rabbitmq/)
+- [《一起来学 SpringBoot 2.x | 第十三篇：RabbitMQ 延迟队列》](http://www.iocoder.cn/Spring-Boot/battcn/v2-queue-rabbitmq-delay/)
+
+## 如何集成 Spring Boot 和 Kafka ？
+
+1. 引入 `spring-kafka` 的依赖。
+2. 在 application 配置文件中，加入 Kafka 相关的少量配置。
+3. 具体编码。
+
+详细的使用，胖友可以参考：
+
+- [《Spring Boot系列文章（一）：SpringBoot Kafka 整合使用》](http://www.54tianzhisheng.cn/2018/01/05/SpringBoot-Kafka/)
+
+## 如何集成 Spring Boot 和 RocketMQ ？
+
+1. 引入 `rocketmq-spring-boot` 的依赖。
+2. 在 application 配置文件中，加入 RocketMQ 相关的少量配置。
+3. 具体编码。
+
+详细的使用，胖友可以参考：
+
+- [《我用这种方法在 Spring 中实现消息的发送和消费》](http://www.iocoder.cn/RocketMQ/start/spring-boot-example)
+
+## Spring Boot 支持哪些日志框架？
+
+Spring Boot 支持的日志框架有：
+
+- Logback
+- Log4j2
+- Log4j
+- Java Util Logging
+
+默认使用的是 Logback 日志框架，也是目前较为推荐的，具体配置，可以参见 [《一起来学 SpringBoot 2.x | 第三篇：SpringBoot 日志配置》](http://www.iocoder.cn/Spring-Boot/battcn/v2-config-logs/) 。
+
+因为 Log4j2 的性能更加优秀，也有人在生产上使用，可以参考 [《Spring Boot Log4j2 日志性能之巅》](https://www.jianshu.com/p/f18a9cff351d) 配置。
+
+# 666. 彩蛋
+
+😈 看完之后，复习复习 Spring Boot 美滋滋。有一种奇怪的感觉，把面试题写成了 Spring 的学习指南。
+
+当然，如果胖友有新的面试题，欢迎在星球一起探讨补充。
+
+参考和推荐如下文章：
+
+- 我有面试宝典 [《[经验分享\] Spring Boot面试题总结》](http://www.wityx.com/post/242_1_1.html)
+- Java 知音 [《Spring Boot 面试题精华》](https://cloud.tencent.com/developer/article/1348086)
+- 祖大帅 [《一个面试题引起的 Spring Boot 启动解析》](https://juejin.im/post/5b679fbc5188251aad213110)
+- 大胡子叔叔_ [《Spring Boot + Spring Cloud 相关面试题》](https://blog.csdn.net/panhaigang123/article/details/79587612)
+- 墨斗鱼博客 [《20 道 Spring Boot 面试题》](https://www.mudouyu.com/article/26)
+- 夕阳雨晴 [《Spring Boot Starter 的面试题》](https://blog.csdn.net/sun1021873926/article/details/78176354)
\ No newline at end of file
diff --git a/面试题/06-Spring Cloud 面试题.assets/01-17182493081051.png b/面试题/06-Spring Cloud 面试题.assets/01-17182493081051.png
new file mode 100644
index 0000000..701b61d
Binary files /dev/null and b/面试题/06-Spring Cloud 面试题.assets/01-17182493081051.png differ
diff --git a/面试题/06-Spring Cloud 面试题.assets/01.png b/面试题/06-Spring Cloud 面试题.assets/01.png
new file mode 100644
index 0000000..ea86e62
--- /dev/null
+++ b/面试题/06-Spring Cloud 面试题.assets/01.png	
@@ -0,0 +1,31 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+	<meta charset="utf-8">
+	<meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
+	<meta name="description" content="">
+	<meta name="author" content="">
+	<title>http://svip.iocoder.cn</title>
+	<link href="https://lf6-cdn-tos.bytecdntp.com/cdn/expire-1-M/bootstrap/4.6.1/css/bootstrap.min.css"
+				type="text/css" rel="stylesheet" />
+	<link href="https://getbootstrap.com/docs/4.0/examples/signin/signin.css" rel="stylesheet" crossorigin="anonymous"/>
+</head>
+<body>
+<div class="container">
+	<form action="/user/auth" class="form-signin" method="post"><input type="hidden" name="_csrf" value="ef402abe-a008-4752-9666-9dab4eb1363c"/>
+		<h2 class="form-signin-heading">登录</h2>
+		
+		<p>
+			<label for="username" class="sr-only">用户名</label>
+			<input type="text" id="username" name="username" class="form-control" placeholder="用户名" required autofocus>
+		</p>
+		<p>
+			<label for="password" class="sr-only">密码</label>
+			<input type="password" id="password" name="password" class="form-control" placeholder="密码" required>
+		</p>
+		<button class="btn btn-lg btn-primary btn-block" type="submit">登录</button>
+		<p>如果账号密码不正确，访问 <a href="https://t.zsxq.com/11JUHkGgl">https://t.zsxq.com/11JUHkGgl</a>  或 <a href="https://t.zsxq.com/yBUj2NN">https://t.zsxq.com/yBUj2NN</a> 解决</p>
+	</form>
+</div>
+</body>
+</html>
diff --git a/面试题/06-Spring Cloud 面试题.assets/20944a735d250d7d3338fe9deea179f8.jpeg b/面试题/06-Spring Cloud 面试题.assets/20944a735d250d7d3338fe9deea179f8.jpeg
new file mode 100644
index 0000000..86cb654
Binary files /dev/null and b/面试题/06-Spring Cloud 面试题.assets/20944a735d250d7d3338fe9deea179f8.jpeg differ
diff --git a/面试题/06-Spring Cloud 面试题.assets/252461fbb6d64d3dbc1914b7eadbfb86.jpeg b/面试题/06-Spring Cloud 面试题.assets/252461fbb6d64d3dbc1914b7eadbfb86.jpeg
new file mode 100644
index 0000000..c0cfdae
Binary files /dev/null and b/面试题/06-Spring Cloud 面试题.assets/252461fbb6d64d3dbc1914b7eadbfb86.jpeg differ
diff --git a/面试题/06-Spring Cloud 面试题.assets/25e9704082444add1192bc69c87198e9.jpeg b/面试题/06-Spring Cloud 面试题.assets/25e9704082444add1192bc69c87198e9.jpeg
new file mode 100644
index 0000000..beb83fa
Binary files /dev/null and b/面试题/06-Spring Cloud 面试题.assets/25e9704082444add1192bc69c87198e9.jpeg differ
diff --git a/面试题/06-Spring Cloud 面试题.assets/36465fd7d91b3a4aeb3b28c3777649e6.jpeg b/面试题/06-Spring Cloud 面试题.assets/36465fd7d91b3a4aeb3b28c3777649e6.jpeg
new file mode 100644
index 0000000..29a7c9d
Binary files /dev/null and b/面试题/06-Spring Cloud 面试题.assets/36465fd7d91b3a4aeb3b28c3777649e6.jpeg differ
diff --git a/面试题/06-Spring Cloud 面试题.assets/43f306a2aa7bc27015d3baa7832d13b6.jpeg b/面试题/06-Spring Cloud 面试题.assets/43f306a2aa7bc27015d3baa7832d13b6.jpeg
new file mode 100644
index 0000000..a043508
Binary files /dev/null and b/面试题/06-Spring Cloud 面试题.assets/43f306a2aa7bc27015d3baa7832d13b6.jpeg differ
diff --git a/面试题/06-Spring Cloud 面试题.assets/4935fcc0a209fd1d4b70cade94986f59.jpeg b/面试题/06-Spring Cloud 面试题.assets/4935fcc0a209fd1d4b70cade94986f59.jpeg
new file mode 100644
index 0000000..7cba0e8
Binary files /dev/null and b/面试题/06-Spring Cloud 面试题.assets/4935fcc0a209fd1d4b70cade94986f59.jpeg differ
diff --git a/面试题/06-Spring Cloud 面试题.assets/64e9a7827c76d38f899160da6f736ea2.jpeg b/面试题/06-Spring Cloud 面试题.assets/64e9a7827c76d38f899160da6f736ea2.jpeg
new file mode 100644
index 0000000..c7cc609
Binary files /dev/null and b/面试题/06-Spring Cloud 面试题.assets/64e9a7827c76d38f899160da6f736ea2.jpeg differ
diff --git a/面试题/06-Spring Cloud 面试题.assets/6650aa32de0def76db0e4c5228619aef.jpeg b/面试题/06-Spring Cloud 面试题.assets/6650aa32de0def76db0e4c5228619aef.jpeg
new file mode 100644
index 0000000..e168476
Binary files /dev/null and b/面试题/06-Spring Cloud 面试题.assets/6650aa32de0def76db0e4c5228619aef.jpeg differ
diff --git a/面试题/06-Spring Cloud 面试题.assets/7832f7526998500b2253f5bc0683e930.jpeg b/面试题/06-Spring Cloud 面试题.assets/7832f7526998500b2253f5bc0683e930.jpeg
new file mode 100644
index 0000000..91b9933
Binary files /dev/null and b/面试题/06-Spring Cloud 面试题.assets/7832f7526998500b2253f5bc0683e930.jpeg differ
diff --git a/面试题/06-Spring Cloud 面试题.assets/80c74f1d7cb9fc2a416e7b61a055d778.jpeg b/面试题/06-Spring Cloud 面试题.assets/80c74f1d7cb9fc2a416e7b61a055d778.jpeg
new file mode 100644
index 0000000..b9c9e0a
Binary files /dev/null and b/面试题/06-Spring Cloud 面试题.assets/80c74f1d7cb9fc2a416e7b61a055d778.jpeg differ
diff --git a/面试题/06-Spring Cloud 面试题.assets/8848af2a2e093d0421d1c7113dedefc1.jpeg b/面试题/06-Spring Cloud 面试题.assets/8848af2a2e093d0421d1c7113dedefc1.jpeg
new file mode 100644
index 0000000..b6cab99
Binary files /dev/null and b/面试题/06-Spring Cloud 面试题.assets/8848af2a2e093d0421d1c7113dedefc1.jpeg differ
diff --git a/面试题/06-Spring Cloud 面试题.assets/950702ef9d35f23b5081c341c1de329a.jpeg b/面试题/06-Spring Cloud 面试题.assets/950702ef9d35f23b5081c341c1de329a.jpeg
new file mode 100644
index 0000000..33a8900
Binary files /dev/null and b/面试题/06-Spring Cloud 面试题.assets/950702ef9d35f23b5081c341c1de329a.jpeg differ
diff --git a/面试题/06-Spring Cloud 面试题.assets/c1a8294fcaf03a88818e4194bb348f0b.jpeg b/面试题/06-Spring Cloud 面试题.assets/c1a8294fcaf03a88818e4194bb348f0b.jpeg
new file mode 100644
index 0000000..9c7a623
Binary files /dev/null and b/面试题/06-Spring Cloud 面试题.assets/c1a8294fcaf03a88818e4194bb348f0b.jpeg differ
diff --git a/面试题/06-Spring Cloud 面试题.assets/d4610e439ae20ceb2d24020e9ff25c3a.jpeg b/面试题/06-Spring Cloud 面试题.assets/d4610e439ae20ceb2d24020e9ff25c3a.jpeg
new file mode 100644
index 0000000..0d25a35
Binary files /dev/null and b/面试题/06-Spring Cloud 面试题.assets/d4610e439ae20ceb2d24020e9ff25c3a.jpeg differ
diff --git a/面试题/06-Spring Cloud 面试题.md b/面试题/06-Spring Cloud 面试题.md
new file mode 100644
index 0000000..3817ccc
--- /dev/null
+++ b/面试题/06-Spring Cloud 面试题.md	
@@ -0,0 +1,517 @@
+# 精尽 Spring Cloud 面试题「最新更新时间：2024-02」
+
+以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。
+
+如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的 Spring Cloud 面试题的大保健。
+
+而题目的难度，艿艿尽量按照从容易到困难的顺序，逐步下去。
+
+> 为什么标题会带有 Beta 呢？
+>
+> 因为艿艿自己生产并未使用 Spring Cloud ，而是使用 Dubbo 。所以，在实战经验方面，会相对匮乏。所以，这篇面试题，献丑了~
+
+另外，本文不会详细解答每个问题，而是提供很多问题回答的文章。等后续艿艿详细的研究了 Spring Cloud Alibaba 后，补充好这篇文章~
+
+# 什么是 Spring Cloud ？
+
+Spring Cloud 是构建在 Spring Boot 基础之上，用于快速构建分布式系统的通用模式的工具集。或者说，换成大家更为熟知的，用于构建微服务的技术栈。
+
+## Spring Cloud 核心功能是什么？
+
+毫无疑问，Spring Cloud 可以说是目前微服务架构的最好的选择，涵盖了基本我们需要的所有组件，所以也被称为全家桶。Spring Cloud 主要提供了如下核心的功能：
+
+- Distributed/versioned configuration 分布式/版本化的配置管理
+- Service registration and discovery 服务注册与服务发现
+- Routing 路由
+- Service-to-service calls 端到端的调用
+- Load balancing 负载均衡
+- Circuit Breakers 断路器
+- Global locks 全局锁
+- Leadership election and cluster state 选举与集群状态管理
+- Distributed messaging 分布式消息
+
+## Spring Cloud 有哪些组件？
+
+Spring Cloud的 组件相当繁杂，拥有诸多子项目。如下脑图所示：
+
+[![Spring Cloud的 组件](06-Spring Cloud 面试题.assets/4935fcc0a209fd1d4b70cade94986f59.jpeg)](http://static.iocoder.cn/4935fcc0a209fd1d4b70cade94986f59)Spring Cloud的 组件
+
+我们最为熟知的，可能就是 [Spring Cloud Netflix](https://github.com/spring-cloud/spring-cloud-netflix) ，它是 Netflix 公司基于它们自己的 Eureka、Hystrix、Zuul、Ribbon 等组件，构建的一个 Spring Cloud 实现技术栈。
+
+当然，可能关心 Spring Cloud 体系的胖友，已经知道 [Spring Cloud Netflix](https://github.com/spring-cloud/spring-cloud-netflix) 要进入维护模式，可能会略感担心。实际上，目前已经开始有新的基于 Spring Cloud 实现，可以作为新的选择。如下表格：
+
+> [《Spring Cloud Netflix 项目进入维护模式》](https://blog.csdn.net/alex_xfboy/article/details/85258425) ，感兴趣的胖友，可以看看新闻。
+
+|          | Netflix | 阿里        | 其它                                                         |
+| :------- | :------ | :---------- | :----------------------------------------------------------- |
+| 注册中心 | Eureka  | Nacos       | Zookeeper、Consul、Etcd                                      |
+| 熔断器   | Hystrix | Sentinel    | Resilience4j                                                 |
+| 网关     | Zuul1   | 暂无        | Spring Cloud Gateway                                         |
+| 负载均衡 | Ribbon  | Dubbo(未来) | [`spring-cloud-loadbalancer`](https://github.com/spring-cloud/spring-cloud-commons/tree/master/spring-cloud-loadbalancer) |
+
+其它组件，例如配置中心、链路追踪、服务引用等等，都有相应其它的实现。妥妥的~
+
+## Spring Cloud 和 Spring Boot 的区别和关系？
+
+1. Spring Boot 专注于快速方便的开发单个个体微服务。
+2. Spring Cloud 是关注全局的微服务协调整理治理框架以及一整套的落地解决方案，它将 Spring Boot 开发的一个个单体微服务整合并管理起来，为各个微服务之间提供：配置管理，服务发现，断路器，路由，微代理，事件总线等的集成服务。
+3. Spring Boot 可以离开 Spring Cloud 独立使用，但是 Spring Cloud 离不开 Spring Boot ，属于依赖的关系。
+
+总结：
+
+- Spring Boot ，专注于快速，方便的开发单个微服务个体。
+- Spring Cloud ，关注全局的服务治理框架。
+
+## Spring Cloud 和 Dubbo 的区别？
+
+参见 [《精尽 Dubbo 面试题》](http://svip.iocoder.cn/Dubbo/Interview) 文章的 [「Spring Cloud 与 Dubbo 怎么选择？」](https://svip.iocoder.cn/Spring-Cloud/Interview/#) 问题的解答。
+
+# 什么是微服务？
+
+直接看 [什么是微服务？](http://www.iocoder.cn/Geek/Learn-micro-services-from-zero/What-is-a-micro-service/) 文章。
+
+## 微服务的优缺点分别是什么？
+
+**1）优点**
+
+- 每一个服务足够内聚,代码容易理解
+- 开发效率提高，一个服务只做一件事
+- 微服务能够被小团队单独开发
+- 微服务是松耦合的，是有功能意义的服务
+- 可以用不同的语言开发,面向接口编程
+- 易于与第三方集成
+- 微服务只是业务逻辑的代码，不会和 HTML、CSS 或者其他界面组合
+  - 开发中，两种开发模式
+    - 前后端分离
+    - 全栈工程师
+- 可以灵活搭配,连接公共库/连接独立库
+
+**2）缺点**
+
+- 分布式系统的负责性
+- 多服务运维难度，随着服务的增加，运维的压力也在增大
+- 系统部署依赖
+- 服务间通信成本
+- 数据一致性
+- 系统集成测试
+- 性能监控
+
+# 注册中心
+
+在 Spring Cloud 中，能够使用的注册中心，还是比较多的，如下：
+
+- [`spring-cloud-netflix-eureka-server`](https://github.com/spring-cloud/spring-cloud-netflix/tree/master/spring-cloud-netflix-eureka-server) 和 [`spring-cloud-netflix-eureka-client`](https://github.com/spring-cloud/spring-cloud-netflix/tree/master/spring-cloud-netflix-eureka-server) ，基于 Eureka 实现。
+- [`spring-cloud-alibaba-nacos-discovery`](https://github.com/spring-cloud-incubator/spring-cloud-alibaba/tree/master/spring-cloud-alibaba-nacos-discovery) ，基于 Nacos 实现。
+- [`spring-cloud-zookeeper-discovery`](https://github.com/spring-cloud/spring-cloud-zookeeper/tree/master/spring-cloud-zookeeper-discovery) ，基于 Zookeeper 实现。
+- … 等等
+
+以上的实现，都是基于 [`spring-cloud-commons`](https://github.com/spring-cloud/spring-cloud-commons) 的 [`discovery`](https://github.com/spring-cloud/spring-cloud-commons/blob/master/spring-cloud-commons/src/main/java/org/springframework/cloud/client/discovery/) 的 [DiscoveryClient](https://github.com/spring-cloud/spring-cloud-commons/blob/master/spring-cloud-commons/src/main/java/org/springframework/cloud/client/discovery/DiscoveryClient.java) 接口，实现统一的客户端的注册发现。
+
+## 为什么要使用服务发现？
+
+简单来说，通过注册中心，调用方(Consumer)获得服务方(Provider)的地址，从而能够调用。
+
+当然，实际情况下，会分成两种注册中心的发现模式：
+
+1. 客户端发现模式
+2. 服务端发现模式
+
+在 Spring Cloud 中，我们使用前者，即客户端发现模式。
+
+详细的内容，可以看看 [《为什么要使用服务发现》](https://blog.csdn.net/u013035373/article/details/79414529) 。
+
+## Eureka
+
+[![Eureka 集群](06-Spring Cloud 面试题.assets/25e9704082444add1192bc69c87198e9.jpeg)](http://static.iocoder.cn/25e9704082444add1192bc69c87198e9)Eureka 集群
+
+- 作用：实现服务治理（服务注册与发现）
+- 简介：Spring Cloud Eureka是Spring Cloud Netflix项目下的服务治理模块。
+- 由两个组件组成：Eureka 服务端和 Eureka 客户端。
+  - Eureka 服务端，用作服务注册中心，支持集群部署。
+  - Eureka 客户端，是一个 Java 客户端，用来处理服务注册与发现。
+
+在应用启动时，Eureka 客户端向服务端注册自己的服务信息，同时将服务端的服务信息缓存到本地。客户端会和服务端周期性的进行心跳交互，以更新服务租约和服务信息。
+
+Eureka 原理，整体如下图：[![Eureka 原理](06-Spring Cloud 面试题.assets/80c74f1d7cb9fc2a416e7b61a055d778.jpeg)](http://static.iocoder.cn/80c74f1d7cb9fc2a416e7b61a055d778)Eureka 原理
+
+关于 Eureka 的源码解析，可以看看艿艿写的 [《Eureka 源码解析系列》](http://www.iocoder.cn/categories/Eureka/) 。
+
+### Eureka 如何实现集群？
+
+[《配置 Eureka Server 集群》](https://www.jianshu.com/p/5d5b2cf7d476)
+
+此处，也很容易引申出一个问题，为什么 Eureka 被设计成 AP 的系统，答案可以看看 [《为什么不应该使用 ZooKeeper 做服务发现》](http://dockone.io/article/78) 。
+
+### 聊聊 Eureka 缓存机制？
+
+艿艿画了下 Eureka 的缓存机制，如下图所示：
+
+[![Eureka 缓存机制](06-Spring Cloud 面试题.assets/01.png)](http://svip.iocoder.cn/images/SpringCloud/2018_10_28/01.png)Eureka 缓存机制
+
+> 原图可见地址：https://www.processon.com/view/link/5f49e2055653bb0c71de11e4
+>
+> 建议胖友可以手绘下，便于面试和面试官你侬我侬~
+
+推荐额外阅读下如下三篇文章：
+
+- [《详解 Eureka 缓存机制》](https://www.infoq.cn/article/y_1BCrbLONU61s1gbGsU)
+- [《Eureka 的多级缓存机制》](https://blog.csdn.net/qq_38545713/article/details/105535950)
+- [《Eureka 缓存细节以及生产环境的最佳配置》](http://bhsc881114.github.io/2018/04/01/eureka缓存细节以及生产环境的最佳配置/)
+
+### 什么是 Eureka 自我保护机制？
+
+[《[Spring Cloud\] Eureka 的自我保护模式及相关问题》](https://blog.csdn.net/t894690230/article/details/78207495)
+
+# 负载均衡
+
+在 Spring Cloud 中，能够使用的负载均衡，如下：
+
+- [`spring-cloud-netflix-ribbon`](https://github.com/spring-cloud/spring-cloud-netflix/tree/master/spring-cloud-netflix-ribbon) ，基于 Ribbon 实现。
+- [`spring-cloud-loadbalancer`](https://github.com/spring-cloud/spring-cloud-commons/tree/master/spring-cloud-loadbalancer) ，提供简单的负载均衡功能。
+
+以上的实现，都是基于 [`spring-cloud-commons`](https://github.com/spring-cloud/spring-cloud-commons) 的 [`loadbalancer`](https://github.com/spring-cloud/spring-cloud-commons/tree/master/spring-cloud-commons/src/main/java/org/springframework/cloud/client/loadbalancer) 的 [ServiceInstanceChooser](https://github.com/spring-cloud/spring-cloud-commons/blob/ecabe2bb8d9cb14aa6edcff41fdb79dc304ed004/spring-cloud-commons/src/main/java/org/springframework/cloud/client/loadbalancer/ServiceInstanceChooser.java) 接口，实现统一的服务的选择。并且，负载均衡组件在选择需要调用的服务之后，还提供调用该服务的功能，具体方法见 [LoadBalancerClient](https://github.com/spring-cloud/spring-cloud-commons/blob/master/spring-cloud-commons/src/main/java/org/springframework/cloud/client/loadbalancer/LoadBalancerClient.java) 接口的 `#execute(...)` 方法。
+
+## 为什么要负载均衡？
+
+简单来说，随着业务的发展，单台服务无法支撑访问的需要，于是搭建多个服务形成集群。那么随之要解决的是，每次请求，调用哪个服务，也就是需要进行负载均衡。
+
+目前负载均衡有两种模式：
+
+1. 客户端模式
+2. 服务端模式
+
+在 Spring Cloud 中，我们使用前者，即客户端模式。
+
+详细的内容，可以看看 [《客户端负载均衡与服务端负载均衡》](https://blog.csdn.net/u014401141/article/details/78676296) 。
+
+🦅 **负载平衡的意义什么？**
+
+在计算中，负载平衡可以改善跨计算机，计算机集群，网络链接，中央处理单元或磁盘驱动器等多种计算资源的工作负载分布。负载平衡旨在优化资源使用，最大化吞吐量，最小化响应时间并避免任何单一资源的过载。使用多个组件进行负载平衡而不是单个组件可能会通过冗余来提高可靠性和可用性。负载平衡通常涉及专用软件或硬件，例如多层交换机或域名系统服务器进程。
+
+## Ribbon
+
+[![Ribbon](06-Spring Cloud 面试题.assets/950702ef9d35f23b5081c341c1de329a.jpeg)](http://static.iocoder.cn/950702ef9d35f23b5081c341c1de329a)Ribbon
+
+- 作用：主要提供客户侧的软件负载均衡算法。
+- 简介：Spring Cloud Ribbon 是一个基于 HTTP 和 TCP 的客户端负载均衡工具，它基于 Netflix Ribbon 实现。通过 Spring Cloud 的封装，可以让我们轻松地将面向服务的 REST 模版请求自动转换成客户端负载均衡的服务调用。
+- 注意看上图，关键点就是将外界的 rest 调用，根据负载均衡策略转换为微服务调用。
+
+Ribbon 原理，整体如下图：[![Ribbon 原理](06-Spring Cloud 面试题.assets/36465fd7d91b3a4aeb3b28c3777649e6.jpeg)](http://static.iocoder.cn/36465fd7d91b3a4aeb3b28c3777649e6)Ribbon 原理
+
+关于 Ribbon 的源码解析，可以看看艿艿整理的 [《Ribbon 源码解析系列》](http://www.iocoder.cn/Ribbon/good-collection/?vip) 。
+
+### Ribbon 有哪些负载均衡算法？
+
+[《Ribbon 负载均衡策略配置》](https://blog.csdn.net/rickiyeat/article/details/64918756)
+
+其中，默认的负载均衡算法是 Round Robin 算法，顺序向下轮询。
+
+### 聊聊 Ribbon 缓存机制？
+
+还是 [《Eureka 缓存细节以及生产环境的最佳配置》](http://bhsc881114.github.io/2018/04/01/eureka缓存细节以及生产环境的最佳配置/) 这篇文章，Ribbon 的缓存，可能也坑道蛮多人了。
+
+### 聊聊 Ribbon 重试机制？
+
+[《Spring Cloud Ribbon 重试机制》](https://www.jianshu.com/p/cdb6fedcab70)
+
+除了重试次数，还有请求的超时可以配置。
+
+### Ribbon 是怎么和 Eureka 整合的？
+
+对着我们看到那张 Ribbon 原理图：
+
+[![Ribbon 原理](06-Spring Cloud 面试题.assets/36465fd7d91b3a4aeb3b28c3777649e6.jpeg)](http://static.iocoder.cn/36465fd7d91b3a4aeb3b28c3777649e6)Ribbon 原理
+
+- 首先，Ribbon 会从 Eureka Client 里获取到对应的服务列表。
+- 然后，Ribbon 使用负载均衡算法获得使用的服务。
+- 最后，Ribbon 调用对应的服务。
+
+另外，此处的 Eureka 仅仅是作为注册中心的举例，也是可以配合其它的注册中心使用，例如 Zookeeper 。可参考 [《以 Zookeeper 为注册中心搭建 Spring Cloud 环境》](https://www.jianshu.com/p/775c363d0fda) 文章。
+
+# 声明式调用
+
+在 Spring Cloud 中，目前使用的声明式调用组件，只有：
+
+- `spring-cloud-openfeign` ，基于 Feign 实现。
+
+如果熟悉 Dubbo 胖友的会知道，Dubbo 的 Service API 接口，也是一种声明式调用的提现。
+
+> 艿艿：注意噢，Feign 并非 Netflix 团队开发的组件。所有基于 Netflix 组件都在 `spring-cloud-netflix` 项目下噢。
+
+## Feign
+
+[Feign](https://github.com/OpenFeign/feign) 是受到 Retrofit、JAXRS-2.0 和 WebSocket 启发的 Java 客户端联编程序。Feign 的主要目标是将Java Http 客户端变得简单。
+
+具体 Feign 如何使用，可以看看 [《对于 Spring Cloud Feign 入门示例的一点思考》](https://blog.csdn.net/u013815546/article/details/76637541) 。
+
+有一点要注意，Feign 并非一定要在 Spring Cloud 下使用，单独使用也是没问题的。
+
+### Feign 实现原理？
+
+**Feign的一个关键机制就是使用了动态代理**。咱们一起来看看下面的图，结合图来分析：
+
+- 首先，如果你对某个接口定义了 `@FeignClient` 注解，Feign 就会针对这个接口创建一个动态代理。
+- 接着你要是调用那个接口，本质就是会调用 Feign 创建的动态代理，这是核心中的核心。
+- Feig n的动态代理会根据你在接口上的 `@RequestMapping` 等注解，来动态构造出你要请求的服务的地址。
+- 最后针对这个地址，发起请求、解析响应。
+
+[![Feign 原理](06-Spring Cloud 面试题.assets/6650aa32de0def76db0e4c5228619aef.jpeg)](http://static.iocoder.cn/6650aa32de0def76db0e4c5228619aef)Feign 原理
+
+### Feign 和 Ribbon 的区别？
+
+Ribbon 和 Feign 都是使用于调用用其余服务的，不过方式不同。
+
+- 启动类用的注解不同。
+  - Ribbon 使用的是 `@RibbonClient` 。
+  - Feign 使用的是 `@EnableFeignClients` 。
+- 服务的指定位置不同。
+  - Ribbon 是在 `@RibbonClient` 注解上设置。
+  - Feign 则是在定义声明方法的接口中用 `@FeignClient` 注解上设置。
+- 调使用方式不同。
+  - Ribbon 需要自己构建 Http 请求，模拟 Http 请求而后用 RestTemplate 发送给其余服务，步骤相当繁琐。
+  - Feign 采使用接口的方式，将需要调使用的其余服务的方法定义成声明方法就可，不需要自己构建 Http 请求。不过要注意的是声明方法的注解、方法签名要和提供服务的方法完全一致。
+
+### Feign 是怎么和 Ribbon、Eureka 整合的？
+
+结合 [「 Ribbon 是怎么和 Eureka 整合的？」](https://svip.iocoder.cn/Spring-Cloud/Interview/#) 问题，并结合如下图：
+
+[![Feign + Ribbon + Eureka](06-Spring Cloud 面试题.assets/252461fbb6d64d3dbc1914b7eadbfb86.jpeg)](http://static.iocoder.cn/252461fbb6d64d3dbc1914b7eadbfb86)Feign + Ribbon + Eureka
+
+- 首先，用户调用 Feign 创建的动态代理。
+
+- 然后，Feign 调用 Ribbon 发起调用流程。
+
+  - 首先，Ribbon 会从 Eureka Client 里获取到对应的服务列表。
+
+  - 然后，Ribbon 使用负载均衡算法获得使用的服务。
+
+  - ~~最后，Ribbon 调用对应的服务。~~最后，Ribbon 调用 Feign ，而 Feign 调用 HTTP 库最终调用使用的服务。
+
+    > 这可能是比较绕的，艿艿自己也困惑了一下，后来去请教了下 didi 。因为 Feign 和 Ribbon 都存在使用 HTTP 库调用指定的服务，那么两者在集成之后，必然是只能保留一个。比较正常的理解，也是保留 Feign 的调用，而 Ribbon 更纯粹的只负责负载均衡的功能。
+
+想要完全理解，建议胖友直接看如下两个类：
+
+- [LoadBalancerFeignClient](https://github.com/spring-cloud/spring-cloud-openfeign/blob/master/spring-cloud-openfeign-core/src/main/java/org/springframework/cloud/openfeign/ribbon/LoadBalancerFeignClient.java) ，Spring Cloud 实现 Feign Client 接口的二次封装，实现对 Ribbon 的调用。
+
+- [FeignLoadBalancer](https://github.com/spring-cloud/spring-cloud-openfeign/blob/master/spring-cloud-openfeign-core/src/main/java/org/springframework/cloud/openfeign/ribbon/FeignLoadBalancer.java) ，Ribbon 的集成。
+
+  > 集成的是 AbstractLoadBalancerAwareClient 抽象类，它会自动注入项目中所使用的负载均衡组件。
+
+- LoadBalancerFeignClient =》调用=》 FeignLoadBalancer 。
+
+### 聊聊 Feign 重试机制？
+
+可以看看 [《Spring Cloud 各组件重试总结》](http://www.itmuch.com/spring-cloud-sum/spring-cloud-retry/) 文章。因为 Ribbon 和 Feign 都有重试机制，在整合 Ribbon 的情况下，不使用 Feign 重试，而是使用 Ribbon 的重试。
+
+# 服务保障
+
+在 Spring Cloud 中，能够使用的服务保证，如下：
+
+- [`spring-cloud-netflix-hystrix`](https://github.com/spring-cloud/spring-cloud-netflix/tree/master/spring-cloud-netflix-hystrix) ，基于 Hystrix 实现。
+- Resilience4j
+- [`spring-cloud-alibaba-sentinel`](https://github.com/spring-cloud-incubator/spring-cloud-alibaba/tree/master/spring-cloud-alibaba-sentinel) ，基于 Sentinel 实现。
+
+## 为什么要使用服务保障？
+
+在微服务架构中，我们将业务拆分成一个个的服务，服务与服务之间可以相互调用（RPC）。为了保证其高可用，单个服务又必须集群部署。由于网络原因或者自身的原因，服务并不能保证服务的 100% 可用，如果单个服务出现问题，调用这个服务就会出现网络延迟，此时若有大量的网络涌入，会形成任务累积，导致服务瘫痪，甚至导致服务“雪崩”。为了解决这个问题，就出现断路器模型。
+
+详细的内容，可以看看 [《为什么要使用断路器 Hystrix？》](https://www.cnblogs.com/xyhero/p/53852cf0245c229fe3e22756a220508b.html) 。
+
+## Hystrix
+
+[![Hystrix](06-Spring Cloud 面试题.assets/7832f7526998500b2253f5bc0683e930.jpeg)](http://static.iocoder.cn/7832f7526998500b2253f5bc0683e930)Hystrix
+
+- 作用：断路器，保护系统，控制故障范围。
+- 简介：Hystrix 是一个延迟和容错库，旨在隔离远程系统，服务和第三方库的访问点，当出现故障是不可避免的故障时，停止级联故障并在复杂的分布式系统中实现弹性。
+
+Hystrix 原理，整体如下图：[![Hystrix 原理](06-Spring Cloud 面试题.assets/8848af2a2e093d0421d1c7113dedefc1.jpeg)](http://static.iocoder.cn/8848af2a2e093d0421d1c7113dedefc1)Hystrix 原理
+
+关于 Hystrix 的源码解析，可以看看艿艿写的 [《Hystrix 源码解析系列》](http://www.iocoder.cn/categories/Hystrix/) 。
+
+### Hystrix 隔离策略？
+
+Hystrix 有两种隔离策略：
+
+- 线程池隔离
+- 信号量隔离
+
+实际场景下，使用线程池隔离居多，因为支持超时功能。
+
+详细的，可以看看 [《Hystrix 的资源隔离策略》](https://blog.csdn.net/liuchuanhong1/article/details/73718794) 文章。
+
+### 聊聊 Hystrix 缓存机制？
+
+Hystrix 提供缓存功能，作用是：
+
+- 减少重复的请求数。
+- 在同一个用户请求的上下文中，相同依赖服务的返回数据始终保持一致。
+
+详细的，可以看看 [《Hystrix 缓存功能的使用》](https://blog.csdn.net/zhuchuangang/article/details/74566185) 文章。
+
+### 什么是 Hystrix 断路器？
+
+Hystrix 断路器通过 HystrixCircuitBreaker 实现。
+
+HystrixCircuitBreaker 有三种状态 ：
+
+- `CLOSED` ：关闭
+- `OPEN` ：打开
+- `HALF_OPEN` ：半开
+
+其中，断路器处于 `OPEN` 状态时，链路处于**非健康**状态，命令执行时，直接调用**回退**逻辑，跳过**正常**逻辑。
+
+HystrixCircuitBreaker 状态变迁如下图 ：
+
+[![HystrixCircuitBreaker 状态](06-Spring Cloud 面试题.assets/01-17182493081051.png)](http://static.iocoder.cn/images/Hystrix/2018_11_08/01.png)HystrixCircuitBreaker 状态
+
+- 红线
+
+   
+
+  ：初始时，断路器处于
+
+   
+
+  ```
+  CLOSED
+  ```
+
+   
+
+  状态，链路处于
+
+  健康
+
+  状态。当满足如下条件，断路器从
+
+   
+
+  ```
+  CLOSED
+  ```
+
+   
+
+  变成
+
+   
+
+  ```
+  OPEN
+  ```
+
+   
+
+  状态：
+
+  - **周期**( 可配，`HystrixCommandProperties.default_metricsRollingStatisticalWindow = 10000 ms` )内，总请求数超过一定**量**( 可配，`HystrixCommandProperties.circuitBreakerRequestVolumeThreshold = 20` ) 。
+  - **错误**请求占总请求数超过一定**比例**( 可配，`HystrixCommandProperties.circuitBreakerErrorThresholdPercentage = 50%` ) 。
+
+- **绿线** ：断路器处于 `OPEN` 状态，命令执行时，若当前时间超过断路器**开启**时间一定时间( `HystrixCommandProperties.circuitBreakerSleepWindowInMilliseconds = 5000 ms` )，断路器变成 `HALF_OPEN` 状态，**尝试**调用**正常**逻辑，根据执行是否成功，**打开或关闭**熔断器【**蓝线**】。
+
+### 什么是 Hystrix 服务降级？
+
+在 Hystrix 断路器熔断时，可以调用一个降级方法，返回相应的结果。当然，降级方法需要配置和编码，如果胖友不需要，也可以不写，也就是不会有服务降级的功能。
+
+具体的使用方式，可以看看 [《通过 Hystrix 理解熔断和降级》](https://blog.csdn.net/jiaobuchong/article/details/78232920) 。
+
+# 网关服务
+
+在 Spring Cloud 中，能够使用的网关服务，主要是两个，如下：
+
+- [`spring-cloud-netflix-zuul`](https://github.com/spring-cloud/spring-cloud-netflix/tree/e460b94b90ea93658a9bedb1af2509ea71cacae4/spring-cloud-netflix-zuul) ，基于 Zuul1 实现。
+
+  > Netflix 最新开源的网关服务是 Zuul2 ，基于响应式的网关服务。
+
+- [`spring-cloud-gateway`](https://github.com/spring-cloud/spring-cloud-gateway) ，基于 Spring Webflux 实现。
+
+  > 艿艿：比较大的可能性，是未来 Spring Cloud 网关的主流选择。考虑到目前资料的情况，建议使用 Zuul1 可能是更稳妥的选择，因为 Zuul1 已经能满足绝大数性能要求，实在不行也可以集群。
+
+## 为什么要网关服务？
+
+使用网关服务，我们实现统一的功能：
+
+- 动态路由
+- 灰度发布
+- 健康检查
+- 限流
+- 熔断
+- 认证: 如数支持 HMAC, JWT, Basic, OAuth 2.0 等常用协议
+- 鉴权: 权限控制，IP 黑白名单，同样是 OpenResty 的特性
+- 可用性
+- 高性能
+
+详细的，可以看看 [《为什么微服务需要 API 网关？》](http://dockone.io/article/2033) 。
+
+## Zuul
+
+[![Zuul](06-Spring Cloud 面试题.assets/c1a8294fcaf03a88818e4194bb348f0b.jpeg)](http://static.iocoder.cn/c1a8294fcaf03a88818e4194bb348f0b)Zuul
+
+- 作用：API 网关，路由，负载均衡等多种作用。
+- 简介：类似 Nginx ，反向代理的功能，不过 Netflix 自己增加了一些配合其他组件的特性。
+- 在微服务架构中，后端服务往往不直接开放给调用端，而是通过一个 API网关根据请求的 url ，路由到相应的服务。当添加API网关后，在第三方调用端和服务提供方之间就创建了一面墙，这面墙直接与调用方通信进行权限控制，后将请求均衡分发给后台服务端。
+
+Zuul 原理，整体如下图：[![Zuul 原理](06-Spring Cloud 面试题.assets/20944a735d250d7d3338fe9deea179f8.jpeg)](http://static.iocoder.cn/20944a735d250d7d3338fe9deea179f8)Zuul 原理
+
+关于 Zuul 的源码解析，可以看看艿艿整理的 [《Zuul 源码解析系列》](http://www.iocoder.cn/Zuul/good-collection/) 。
+
+## Spring Cloud Gateway
+
+关于 Spring Cloud Gateway 的源码解析，可以看看艿艿写的 [《Spring Cloud Gateway 源码解析系列》](http://www.iocoder.cn/categories/Spring-Cloud-Gateway/) 。
+
+# 配置中心
+
+在 Spring Cloud 中，能够使用的配置中心，如下：
+
+- [`spring-cloud-config`](https://github.com/spring-cloud/spring-cloud-config) ，基于 Git、SVN 作为存储。
+
+- [`spring-cloud-alibaba-nacos-config`](https://github.com/spring-cloud-incubator/spring-cloud-alibaba/tree/master/spring-cloud-alibaba-nacos-config) ，基于 Nacos 实现。
+
+- [Apollo](https://github.com/ctripcorp/apollo) ，携程开源的配置中心。
+
+  > 艿艿：目前 Spring Cloud 最成熟的配置中心的选择。
+
+## Spring Cloud Config
+
+[![Spring Cloud Config](06-Spring Cloud 面试题.assets/d4610e439ae20ceb2d24020e9ff25c3a.jpeg)](http://static.iocoder.cn/d4610e439ae20ceb2d24020e9ff25c3a)Spring Cloud Config
+
+- 作用：配置管理
+- 简介：Spring Cloud Config 提供服务器端和客户端。服务器存储后端的默认实现使用 Git ，因此它轻松支持标签版本的配置环境，以及可以访问用于管理内容的各种工具。
+- 这个还是静态的，得配合 Spring Cloud Bus 实现动态的配置更新。
+
+虽然 Spring Cloud Config 官方并未推出管理平台，我们可以考虑看看 [《为 Spring Cloud Config 插上管理的翅膀》](http://www.iocoder.cn/Spring-Cloud-Config/didi/spring-cloud-config-admin-1-0-0-release/) 。
+
+## Apollo
+
+关于 Apollo 的源码解析，可以看看艿艿写的 [《Spring Cloud Apollo 源码解析系列》](http://www.iocoder.cn/categories/Apollo/) 。
+
+# 链路追踪
+
+在 Spring Cloud 中，能够使用的链路追踪，主要是两个，如下：
+
+- [`skywalking`](https://github.com/apache/incubator-skywalking) ，已经进入 Apache ，不仅仅能够透明的监控链路，还可以监控 JVM 等等。
+- [`spring-cloud-sleuth`](https://github.com/spring-cloud/spring-cloud-sleuth) ，基于 Zipkin 实现。
+
+## SkyWalking
+
+关于 SkyWalking 的源码解析，可以看看艿艿写的 [《SkyWalking 源码解析系列》](http://www.iocoder.cn/categories/SkyWalking/) 。
+
+## Spring Cloud Sleuth
+
+Spring Cloud Sleuth 原理，整体如下图：[![Spring Cloud Sleuth 原理](06-Spring Cloud 面试题.assets/43f306a2aa7bc27015d3baa7832d13b6.jpeg)](http://static.iocoder.cn/43f306a2aa7bc27015d3baa7832d13b6)Spring Cloud Sleuth 原理
+
+# TODO 消息队列
+
+# 彩蛋
+
+第一个版本的 Spring Cloud 面试题，主要把整个文章的大体结构定了，后续在慢慢完善补充~
+
+如下是 Eureka + Ribbon + Feign + Hystrix + Zuul 整合后的图：[![Eureka + Ribbon + Feign + Hystrix + Zuul](06-Spring Cloud 面试题.assets/64e9a7827c76d38f899160da6f736ea2.jpeg)](http://static.iocoder.cn/64e9a7827c76d38f899160da6f736ea2)Eureka + Ribbon + Feign + Hystrix + Zuul
+
+参考与推荐如下文章：
+
+- [《微服务框架之 Spring Cloud 面试题汇总》](http://www.3da4.com/thread-4948-1-1.html)
+- [《Spring Boot 和 Spring Cloud 面试题》](https://yiweifen.com/v-1-339414.html)
+- [《Spring Cloud 简介与 5 大常用组件》](https://www.toutiao.com/a6642286207961137671/)
+- [《面试必问的 Spring Cloud 实现原理图》](https://www.youdingyi.com/thread-2500-1-1.html)
+- [《拜托！面试请不要再问我 Spring Cloud 底层原理》](https://juejin.im/post/5be13b83f265da6116393fc7)
\ No newline at end of file
diff --git a/面试题/07-MyBatis 面试题.assets/02.png b/面试题/07-MyBatis 面试题.assets/02.png
new file mode 100644
index 0000000..94bf127
Binary files /dev/null and b/面试题/07-MyBatis 面试题.assets/02.png differ
diff --git a/面试题/07-MyBatis 面试题.md b/面试题/07-MyBatis 面试题.md
new file mode 100644
index 0000000..8b1fe0e
--- /dev/null
+++ b/面试题/07-MyBatis 面试题.md	
@@ -0,0 +1,655 @@
+# 精尽 MyBatis 面试题「最新更新时间：2024-02」
+
+以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。
+
+如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的 MyBatis 面试题的大保健。
+
+而题目的难度，艿艿尽量按照从容易到困难的顺序，逐步下去。
+
+## MyBatis 编程步骤
+
+1. 创建 SqlSessionFactory 对象。
+2. 通过 SqlSessionFactory 获取 SqlSession 对象。
+3. 通过 SqlSession 获得 Mapper 代理对象。
+4. 通过 Mapper 代理对象，执行数据库操作。
+5. 执行成功，则使用 SqlSession 提交事务。
+6. 执行失败，则使用 SqlSession 回滚事务。
+7. 最终，关闭会话。
+
+## `#{}` 和 `${}` 的区别是什么？
+
+`${}` 是 Properties 文件中的变量占位符，它可以用于 XML 标签属性值和 SQL 内部，属于**字符串替换**。例如将 `${driver}` 会被静态替换为 `com.mysql.jdbc.Driver` ：
+
+```
+<dataSource type="UNPOOLED">
+    <property name="driver" value="${driver}"/>
+    <property name="url" value="${url}"/>
+    <property name="username" value="${username}"/>
+</dataSource>
+```
+
+`${}` 也可以对传递进来的参数**原样拼接**在 SQL 中。代码如下：
+
+```
+<select id="getSubject3" parameterType="Integer" resultType="Subject">
+    SELECT * FROM subject
+    WHERE id = ${id}
+</select>
+```
+
+- 实际场景下，不推荐这么做。因为，可能有 SQL 注入的风险。
+
+------
+
+`#{}` 是 SQL 的参数占位符，Mybatis 会将 SQL 中的 `#{}` 替换为 `?` 号，在 SQL 执行前会使用 PreparedStatement 的参数设置方法，按序给 SQL 的 `?` 号占位符设置参数值，比如 `ps.setInt(0, parameterValue)` 。 所以，`#{}` 是**预编译处理**，可以有效防止 SQL 注入，提高系统安全性。
+
+------
+
+另外，`#{}` 和 `${}` 的取值方式非常方便。例如：`#{item.name}` 的取值方式，为使用反射从参数对象中，获取 `item` 对象的 `name` 属性值，相当于 `param.getItem().getName()` 。
+
+## 当实体类中的属性名和表中的字段名不一样 ，怎么办？
+
+第一种， 通过在查询的 SQL 语句中定义字段名的别名，让字段名的别名和实体类的属性名一致。代码如下：
+
+```
+<select id="selectOrder" parameterType="Integer" resultType="Order"> 
+    SELECT order_id AS id, order_no AS orderno, order_price AS price 
+    FROM orders 
+    WHERE order_id = #{id}
+</select>
+```
+
+- 这里，艿艿还有几点建议：
+  - 1、数据库的关键字，统一使用大写，例如：`SELECT`、`AS`、`FROM`、`WHERE` 。
+  - 2、每 5 个查询字段换一行，保持整齐。
+  - 3、`,` 的后面，和 `=` 的前后，需要有空格，更加清晰。
+  - 4、`SELECT`、`FROM`、`WHERE` 等，单独一行，高端大气。
+
+------
+
+第二种，是第一种的特殊情况。大多数场景下，数据库字段名和实体类中的属性名差，主要是前者为**下划线风格**，后者为**驼峰风格**。在这种情况下，可以直接配置如下，实现自动的下划线转驼峰的功能。
+
+```
+<setting name="logImpl" value="LOG4J"/>
+    <setting name="mapUnderscoreToCamelCase" value="true" />
+</settings>
+```
+
+😈 也就说，约定大于配置。非常推荐！
+
+------
+
+第三种，通过 `<resultMap>` 来映射字段名和实体类属性名的一一对应的关系。代码如下：
+
+```
+<resultMap type="me.gacl.domain.Order" id=”OrderResultMap”> 
+    <!–- 用 id 属性来映射主键字段 -–> 
+    <id property="id" column="order_id"> 
+    <!–- 用 result 属性来映射非主键字段，property 为实体类属性名，column 为数据表中的属性 -–> 
+    <result property="orderNo" column ="order_no" /> 
+    <result property="price" column="order_price" /> 
+</resultMap>
+
+<select id="getOrder" parameterType="Integer" resultMap="OrderResultMap">
+    SELECT * 
+    FROM orders 
+    WHERE order_id = #{id}
+</select>
+```
+
+- 此处 `SELECT *` 仅仅作为示例只用，实际场景下，千万千万千万不要这么干。用多少字段，查询多少字段。
+- 相比第一种，第三种的**重用性**会一些。
+
+## XML 映射文件中，除了常见的 select | insert | update | delete标 签之外，还有哪些标签？
+
+如下部分，可见 [《MyBatis 文档 —— Mapper XML 文件》](http://www.mybatis.org/mybatis-3/zh/sqlmap-xml.html) ：
+
+- ```
+  <cache />
+  ```
+
+   
+
+  标签，给定命名空间的缓存配置。
+
+  - `<cache-ref />` 标签，其他命名空间缓存配置的引用。
+
+- `<resultMap />` 标签，是最复杂也是最强大的元素，用来描述如何从数据库结果集中来加载对象。
+
+- ~~`` 标签，已废弃！老式风格的参数映射。内联参数是首选,这个元素可能在将来被移除，这里不会记录。~~
+
+- ```
+  <sql />
+  ```
+
+   
+
+  标签，可被其他语句引用的可重用语句块。
+
+  - `<include />` 标签，引用 `<sql />` 标签的语句。
+
+- `<selectKey />` 标签，不支持自增的主键生成策略标签。
+
+如下部分，可见 [《MyBatis 文档 —— 动态 SQL》](http://www.mybatis.org/mybatis-3/zh/dynamic-sql.html) ：
+
+- `<if />`
+- `<choose />`、`<when />`、`<otherwise />`
+- `<trim />`、`<where />`、`<set />`
+- `<foreach />`
+- `<bind />`
+
+## Mybatis 动态 SQL 是做什么的？都有哪些动态 SQL ？能简述一下动态 SQL 的执行原理吗？
+
+- Mybatis 动态 SQL ，可以让我们在 XML 映射文件内，以 XML 标签的形式编写动态 SQL ，完成逻辑判断和动态拼接 SQL 的功能。
+- Mybatis 提供了 9 种动态 SQL 标签：`<if />`、`<choose />`、`<when />`、`<otherwise />`、`<trim />`、`<where />`、`<set />`、`<foreach />`、`<bind />` 。
+- 其执行原理为，使用 **OGNL** 的表达式，从 SQL 参数对象中计算表达式的值，根据表达式的值动态拼接 SQL ，以此来完成动态 SQL 的功能。
+
+如上的内容，更加详细的话，请看 [《MyBatis 文档 —— 动态 SQL》](http://www.mybatis.org/mybatis-3/zh/dynamic-sql.html) 文档。
+
+## 最佳实践中，通常一个 XML 映射文件，都会写一个 Mapper 接口与之对应。请问，这个 Mapper 接口的工作原理是什么？Mapper 接口里的方法，参数不同时，方法能重载吗？
+
+Mapper 接口，对应的关系如下：
+
+- 接口的全限名，就是映射文件中的 `"namespace"` 的值。
+- 接口的方法名，就是映射文件中 MappedStatement 的 `"id"` 值。
+- 接口方法内的参数，就是传递给 SQL 的参数。
+
+Mapper 接口是没有实现类的，当调用接口方法时，接口全限名 + 方法名拼接字符串作为 key 值，可唯一定位一个对应的 MappedStatement 。举例：`com.mybatis3.mappers.StudentDao.findStudentById` ，可以唯一找到 `"namespace"` 为 `com.mybatis3.mappers.StudentDao` 下面 `"id"` 为 `findStudentById` 的 MappedStatement 。
+
+总结来说，在 Mybatis 中，每一个 `<select />`、`<insert />`、`<update />`、`<delete />` 标签，都会被解析为一个 MappedStatement 对象。
+
+另外，Mapper 接口的实现类，通过 MyBatis 使用 **JDK Proxy** 自动生成其代理对象 Proxy ，而代理对象 Proxy 会拦截接口方法，从而“调用”对应的 MappedStatement 方法，最终执行 SQL ，返回执行结果。整体流程如下图：[![流程](07-MyBatis 面试题.assets/02.png)](http://static.iocoder.cn/images/MyBatis/2020_03_15/02.png)流程
+
+- 其中，SqlSession 在调用 Executor 之前，会获得对应的 MappedStatement 方法。例如：`DefaultSqlSession#select(String statement, Object parameter, RowBounds rowBounds, ResultHandler handler)` 方法，代码如下：
+
+  ```
+  // DefaultSqlSession.java
+  
+  @Override
+  public void select(String statement, Object parameter, RowBounds rowBounds, ResultHandler handler) {
+      try {
+          // 获得 MappedStatement 对象
+          MappedStatement ms = configuration.getMappedStatement(statement);
+          // 执行查询
+          executor.query(ms, wrapCollection(parameter), rowBounds, handler);
+      } catch (Exception e) {
+          throw ExceptionFactory.wrapException("Error querying database.  Cause: " + e, e);
+      } finally {
+          ErrorContext.instance().reset();
+      }
+  }
+  ```
+
+  - 完整的流程，胖友可以慢慢撸下 MyBatis 的源码。
+
+------
+
+Mapper 接口里的方法，是不能重载的，因为是**全限名 + 方法名**的保存和寻找策略。😈 所以有时，想个 Mapper 接口里的方法名，还是蛮闹心的，嘿嘿。
+
+## Mapper 
接口绑定有几种实现方式,分别是怎么实现的?
+
+接口绑定有三种实现方式：
+
+第一种，通过 **XML Mapper** 里面写 SQL 来绑定。在这种情况下，要指定 XML 映射文件里面的 `"namespace"` 必须为接口的全路径名。
+
+第二种，通过**注解**绑定，就是在接口的方法上面加上 `@Select`、`@Update`、`@Insert`、`@Delete` 注解，里面包含 SQL 语句来绑定。
+
+第三种，是第二种的特例，也是通过**注解**绑定，在接口的方法上面加上 `@


SelectProvider`、`@UpdateProvider`、`@InsertProvider`、`@DeleteProvider` 注解，通过 Java 代码，生成对应的动态 SQL 。
+
+------
+
+实际场景下，最最最推荐的是**第一种**方式。因为，SQL 通过注解写在 Java 代码中，会非常杂乱。而写在 XML 中，更加有整体性，并且可以更加方便的使用 OGNL 表达式。
+
+## Mybatis 的 XML Mapper文件中，不同的 XML 映射文件，id 是否可以重复？
+
+不同的 XML Mapper 文件，如果配置了 `"namespace"` ，那么 id 可以重复；如果没有配置 `"namespace"` ，那么 id 不能重复。毕竟`"namespace"` 不是必须的，只是最佳实践而已。
+
+原因就是，`namespace + id` 是作为 `Map<String, MappedStatement>` 的 key 使用的。如果没有 `"namespace"`，就剩下 id ，那么 id 重复会导致数据互相覆盖。如果有了 `"namespace"`，自然 id 就可以重复，`"namespace"`不同，`namespace + id` 自然也就不同。
+
+## 如何获取自动生成的(主)键值?
+
+不同的数据库，获取自动生成的(主)键值的方式是不同的。
+
+MySQL 有两种方式，但是**自增主键**，代码如下：
+
+```
+// 方式一，使用 useGeneratedKeys + keyProperty 属性
+<insert id="insert" parameterType="Person" useGeneratedKeys="true" keyProperty="id">
+    INSERT INTO person(name, pswd)
+    VALUE (#{name}, #{pswd})
+</insert>
+    
+// 方式二，使用 `<selectKey />` 标签
+<insert id="insert" parameterType="Person">
+    <selectKey keyProperty="id" resultType="long" order="AFTER">
+        SELECT LAST_INSERT_ID()
+    </selectKey>
+        
+    INSERT INTO person(name, pswd)
+    VALUE (#{name}, #{pswd})
+</insert>
+```
+
+- 其中，**方式一**较为常用。
+
+------
+
+Oracle 有两种方式，**序列**和**触发器**。因为艿艿自己不了解 Oracle ，所以问了银行的朋友，他们是使用**序列**。而基于**序列**，根据 `<selectKey />` 执行的时机，也有两种方式，代码如下：
+
+```
+// 这个是创建表的自增序列
+CREATE SEQUENCE student_sequence
+INCREMENT BY 1
+NOMAXVALUE
+NOCYCLE
+CACHE 10;
+
+// 方式一，使用 `<selectKey />` 标签 + BEFORE
+<insert id="add" parameterType="Student">
+　　<selectKey keyProperty="student_id" resultType="int" order="BEFORE">
+      select student_sequence.nextval FROM dual
+    </selectKey>
+    
+     INSERT INTO student(student_id, student_name, student_age)
+     VALUES (#{student_id},#{student_name},#{student_age})
+</insert>
+
+// 方式二，使用 `<selectKey />` 标签 + AFTER
+<insert id="save" parameterType="com.threeti.to.ZoneTO" >
+    <selectKey resultType="java.lang.Long" keyProperty="id" order="AFTER" >
+      SELECT SEQ_ZONE.CURRVAL AS id FROM dual
+    </selectKey>
+    
+    INSERT INTO TBL_ZONE (ID, NAME ) 
+    VALUES (SEQ_ZONE.NEXTVAL, #{name,jdbcType=VARCHAR})
+</insert>
+```
+
+- 他们使用第一种方式，没有具体原因，可能就没什么讲究吧。嘿嘿。
+
+至于为什么不用**触发器**呢？朋友描述如下：
+
+> 朋友：触发器不行啊，我们这边原来也有触发器，一有数据更改就会有问题了呀
+> 艿艿：数据更改指的是？
+> 朋友：就改线上某几条数据
+> 艿艿：噢噢。手动改是吧？
+> 朋友：不行~
+
+------
+
+当然，数据库还有 SQLServer、PostgreSQL、DB2、H2 等等，具体的方式，胖友自己 Google 下噢。
+
+关于如何获取自动生成的(主)键值的**原理**，可以看看 [《精尽 MyBatis 源码分析 —— SQL 执行（三）之 KeyGenerator》](http://svip.iocoder.cn/MyBatis/executor-3/) 。
+
+## Mybatis 执行批量插入，能返回数据库主键列表吗？
+
+能，JDBC 都能做，Mybatis 当然也能做。
+
+## 在 Mapper 中如何传递多个参数?
+
+第一种，使用 Map 集合，装载多个参数进行传递。代码如下：
+
+```
+// 调用方法
+Map<String, Object> map = new HashMap();
+map.put("start", start);
+map.put("end", end);
+return studentMapper.selectStudents(map);
+
+// Mapper 接口
+List<Student> selectStudents(Map<String, Object> map);
+
+// Mapper XML 代码
+<select id="selectStudents" parameterType="Map" resultType="Student">
+    SELECT * 
+    FROM students 
+    LIMIT #{start}, #{end}
+</select>
+```
+
+- 显然，这不是一种优雅的方式。
+
+------
+
+第二种，保持传递多个参数，使用 `@Param` 注解。代码如下：
+
+```
+// 调用方法
+return studentMapper.selectStudents(0, 10);
+
+// Mapper 接口
+List<Student> selectStudents(@Param("start") Integer start, @Param("end") Integer end);
+
+// Mapper XML 代码
+<select id="selectStudents" resultType="Student">
+    SELECT * 
+    FROM students 
+    LIMIT #{start}, #{end}
+</select>
+```
+
+- 推荐使用这种方式。
+
+------
+
+第三种，保持传递多个参数，不使用 `@Param` 注解。代码如下：
+
+```
+// 调用方法
+return studentMapper.selectStudents(0, 10);
+
+// Mapper 接口
+List<Student> selectStudents(Integer start, Integer end);
+
+// Mapper XML 代码
+<select id="selectStudents" resultType="Student">
+    SELECT * 
+    FROM students 
+    LIMIT #{param1}, #{param2}
+</select>
+```
+
+- 其中，按照参数在方法方法中的位置，从 1 开始，逐个为 `#{param1}`、`#{param2}`、`#{param3}` 不断向下。
+
+## Mybatis 是否可以映射 Enum 枚举类？
+
+Mybatis 可以映射枚举类，对应的实现类为 EnumTypeHandler 或 EnumOrdinalTypeHandler 。
+
+- EnumTypeHandler ，基于 `Enum.name` 属性( String )。**默认**。
+- EnumOrdinalTypeHandler ，基于 `Enum.ordinal` 属性( `int` )。可通过 `<setting name="defaultEnumTypeHandler" value="EnumOrdinalTypeHandler" />` 来设置。
+
+😈 当然，实际开发场景，我们很少使用 Enum 类型，更加的方式是，代码如下：
+
+```
+public class Dog {
+
+    public static final int STATUS_GOOD = 1;
+    public static final int STATUS_BETTER = 2;
+    public static final int STATUS_BEST = 3；
+    
+    private int status;
+    
+}
+```
+
+------
+
+并且，不单可以映射枚举类，Mybatis 可以映射任何对象到表的一列上。映射方式为自定义一个 TypeHandler 类，实现 TypeHandler 的`#setParameter(...)` 和 `#getResult(...)` 接口方法。
+
+TypeHandler 有两个作用：
+
+- 一是，完成从 javaType 至 jdbcType 的转换。
+- 二是，完成 jdbcType 至 javaType 的转换。
+
+具体体现为 `#setParameter(...)` 和 `#getResult(..)` 两个方法，分别代表设置 SQL 问号占位符参数和获取列查询结果。
+
+关于 TypeHandler 的**原理**，可以看看 [《精尽 MyBatis 源码分析 —— 类型模块》](http://svip.iocoder.cn/MyBatis/type-package/) 。
+
+## Mybatis 都有哪些 Executor 执行器？它们之间的区别是什么？
+
+Mybatis 有四种 Executor 执行器，分别是 SimpleExecutor、ReuseExecutor、BatchExecutor、CachingExecutor 。
+
+- SimpleExecutor ：每执行一次 update 或 select 操作，就创建一个 Statement 对象，用完立刻关闭 Statement 对象。
+- ReuseExecutor ：执行 update 或 select 操作，以 SQL 作为key 查找**缓存**的 Statement 对象，存在就使用，不存在就创建；用完后，不关闭 Statement 对象，而是放置于缓存 `Map<String, Statement>` 内，供下一次使用。简言之，就是重复使用 Statement 对象。
+- BatchExecutor ：执行 update 操作（没有 select 操作，因为 JDBC 批处理不支持 select 操作），将所有 SQL 都添加到批处理中（通过 addBatch 方法），等待统一执行（使用 executeBatch 方法）。它缓存了多个 Statement 对象，每个 Statement 对象都是调用 addBatch 方法完毕后，等待一次执行 executeBatch 批处理。**实际上，整个过程与 JDBC 批处理是相同**。
+- CachingExecutor ：在上述的三个执行器之上，增加**二级缓存**的功能。
+
+------
+
+通过设置 `<setting name="defaultExecutorType" value="">` 的 `"value"` 属性，可传入 SIMPLE、REUSE、BATCH 三个值，分别使用 SimpleExecutor、ReuseExecutor、BatchExecutor 执行器。
+
+通过设置 `<setting name="cacheEnabled" value=""` 的 `"value"` 属性为 `true` 时，创建 CachingExecutor 执行器。
+
+------
+
+这块的源码解析，可见 [《精尽 MyBatis 源码分析 —— SQL 执行（一）之 Executor》](http://svip.iocoder.cn/MyBatis/executor-1) 。
+
+## MyBatis 如何执行批量插入?
+
+首先，在 Mapper XML 编写一个简单的 Insert 语句。代码如下：
+
+```
+<insert id="insertUser" parameterType="String"> 
+    INSERT INTO users(name) 
+    VALUES (#{value}) 
+</insert>
+```
+
+然后，然后在对应的 Mapper 接口中，编写映射的方法。代码如下：
+
+```
+public interface UserMapper {
+    
+    void insertUser(@Param("name") String name);
+
+}
+```
+
+最后，调用该 Mapper 接口方法。代码如下：
+
+```
+private static SqlSessionFactory sqlSessionFactory;
+
+@Test
+public void testBatch() {
+    // 创建要插入的用户的名字的数组
+    List<String> names = new ArrayList<>();
+    names.add("占小狼");
+    names.add("朱小厮");
+    names.add("徐妈");
+    names.add("飞哥");
+
+    // 获得执行器类型为 Batch 的 SqlSession 对象，并且 autoCommit = false ，禁止事务自动提交
+    try (SqlSession session = sqlSessionFactory.openSession(ExecutorType.BATCH, false)) {
+        // 获得 Mapper 对象
+        UserMapper mapper = session.getMapper(UserMapper.class);
+        // 循环插入
+        for (String name : names) {
+            mapper.insertUser(name);
+        }
+        // 提交批量操作
+        session.commit();
+    }
+}
+```
+
+代码比较简单，胖友仔细看看。当然，还有另一种方式，代码如下：
+
+```
+INSERT INTO [表名]([列名],[列名]) 
+VALUES
+([列值],[列值])),
+([列值],[列值])),
+([列值],[列值]));
+```
+
+- 对于这种方式，需要保证单条 SQL 不超过语句的最大限制 `max_allowed_packet` 大小，默认为 1 M 。
+
+这两种方式的性能对比，可以看看 [《[实验\]mybatis批量插入方式的比较》](https://www.jianshu.com/p/cce617be9f9e) 。
+
+## 介绍 MyBatis 的一级缓存和二级缓存的概念和实现原理？
+
+内容有些长，直接参见 [《聊聊 MyBatis 缓存机制》](https://tech.meituan.com/mybatis_cache.html) 一文。
+
+------
+
+这块的源码解析，可见 [《精尽 MyBatis 源码分析 —— 缓存模块》](http://svip.iocoder.cn/MyBatis/cache-package) 。
+
+## Mybatis 是否支持延迟加载？如果支持，它的实现原理是什么？
+
+Mybatis 仅支持 association 关联对象和 collection 关联集合对象的延迟加载。其中，association 指的就是**一对一**，collection 指的就是**一对多查询**。
+
+在 Mybatis 配置文件中，可以配置 `<setting name="lazyLoadingEnabled" value="true" />` 来启用延迟加载的功能。默认情况下，延迟加载的功能是**关闭**的。
+
+------
+
+它的原理是，使用 CGLIB 或 Javassist( 默认 ) 创建目标对象的代理对象。当调用代理对象的延迟加载属性的 getting 方法时，进入拦截器方法。比如调用 `a.getB().getName()` 方法，进入拦截器的 `invoke(...)` 方法，发现 `a.getB()` 需要延迟加载时，那么就会单独发送事先保存好的查询关联 B 对象的 SQL ，把 B 查询上来，然后调用`a.setB(b)` 方法，于是 `a` 对象 `b` 属性就有值了，接着完成`a.getB().getName()` 方法的调用。这就是延迟加载的基本原理。
+
+当然了，不光是 Mybatis，几乎所有的包括 Hibernate 在内，支持延迟加载的原理都是一样的。
+
+------
+
+这块的源码解析，可见 [《 精尽 MyBatis 源码分析 —— SQL 执行（五）之延迟加载》](http://svip.iocoder.cn/MyBatis/executor-5) 文章。
+
+## Mybatis 能否执行一对一、一对多的关联查询吗？都有哪些实现方式，以及它们之间的区别。
+
+> 艿艿：这道题有点难度。理解倒是好理解，主要那块源码的实现，艿艿看的有点懵逼。大体的意思是懂的，但是一些细节没扣完。
+
+能，Mybatis 不仅可以执行一对一、一对多的关联查询，还可以执行多对一，多对多的关联查询。
+
+> 艿艿：不过貌似，我自己实际开发中，还是比较喜欢自己去查询和拼接映射的数据。😈
+
+- 多对一查询，其实就是一对一查询，只需要把 `selectOne(...)` 修改为 `selectList(...)` 即可。案例可见 [《MyBatis：多对一表关系详解》](https://blog.csdn.net/xzm_rainbow/article/details/15336959) 。
+- 多对多查询，其实就是一对多查询，只需要把 `#selectOne(...)` 修改为 `selectList(...)` 即可。案例可见 [《【MyBatis学习10】高级映射之多对多查询》](https://blog.csdn.net/eson_15/article/details/51655188) 。
+
+------
+
+关联对象查询，有两种实现方式：
+
+> 艿艿：所有的技术方案，即会有好处，又会有坏处。很难出现，一个完美的银弹方案。
+
+- 一种是单独发送一个 SQL 去查询关联对象，赋给主对象，然后返回主对象。好处是多条 SQL 分开，相对简单，坏处是发起的 SQL 可能会比较多。
+- 另一种是使用嵌套查询，嵌套查询的含义为使用 `join` 查询，一部分列是 A 对象的属性值，另外一部分列是关联对象 B 的属性值。好处是只发一个 SQL 查询，就可以把主对象和其关联对象查出来，坏处是 SQL 可能比较复杂。
+
+那么问题来了，`join` 查询出来 100 条记录，如何确定主对象是 5 个，而不是 100 个呢？其去重复的原理是 `<resultMap>` 标签内的`<id>` 子标签，指定了唯一确定一条记录的 `id` 列。Mybatis 会根据`<id>` 列值来完成 100 条记录的去重复功能，`<id>` 可以有多个，代表了联合主键的语意。
+
+同样主对象的关联对象，也是根据这个原理去重复的。尽管一般情况下，只有主对象会有重复记录，关联对象一般不会重复。例如：下面 `join` 查询出来6条记录，一、二列是 Teacher 对象列，第三列为 Student 对象列。Mybatis 去重复处理后，结果为 1 个老师和 6 个学生，而不是 6 个老师和 6 个学生。
+
+| t_id | t_name  | s_id |
+| :--- | :------ | :--- |
+| 1    | teacher | 38   |
+| 1    | teacher | 39   |
+| 1    | teacher | 40   |
+| 1    | teacher | 41   |
+| 1    | teacher | 42   |
+| 1    | teacher | 43   |
+
+## 简述 Mybatis 的插件运行原理？以及如何编写一个插件？
+
+Mybatis 仅可以编写针对 ParameterHandler、ResultSetHandler、StatementHandler、Executor 这 4 种接口的插件。
+
+Mybatis 使用 JDK 的动态代理，为需要拦截的接口生成代理对象以实现接口方法拦截功能，每当执行这 4 种接口对象的方法时，就会进入拦截方法，具体就是 InvocationHandler 的 `#invoke(...)`方法。当然，只会拦截那些你指定需要拦截的方法。
+
+------
+
+编写一个 MyBatis 插件的步骤如下：
+
+1. 首先，实现 Mybatis 的 Interceptor 接口，并实现 `#intercept(...)` 方法。
+2. 然后，在给插件编写注解，指定要拦截哪一个接口的哪些方法即可
+3. 最后，在配置文件中配置你编写的插件。
+
+具体的，可以参考 [《MyBatis 官方文档 —— 插件》](http://www.mybatis.org/mybatis-3/zh/configuration.html#plugins) 。
+
+------
+
+插件的详细解析，可以看看 [《精尽 MyBatis 源码分析 —— 插件体系（一）之原理》](http://svip.iocoder.cn/MyBatis/plugin-1) 。
+
+## Mybatis 是如何进行分页的？分页插件的原理是什么？
+
+Mybatis 使用 RowBounds 对象进行分页，它是针对 ResultSet 结果集执行的**内存分页**，而非**数据库分页**。
+
+所以，实际场景下，不适合直接使用 MyBatis 原有的 RowBounds 对象进行分页。而是使用如下两种方案：
+
+- 在 SQL 内直接书写带有数据库分页的参数来完成数据库分页功能
+- 也可以使用分页插件来完成数据库分页。
+
+这两者都是基于数据库分页，差别在于前者是工程师**手动**编写分页条件，后者是插件**自动**添加分页条件。
+
+------
+
+分页插件的基本原理是使用 Mybatis 提供的插件接口，实现自定义分页插件。在插件的拦截方法内，拦截待执行的 SQL ，然后重写 SQL ，根据dialect 方言，添加对应的物理分页语句和物理分页参数。
+
+举例：`SELECT * FROM student` ，拦截 SQL 后重写为：`select * FROM student LIMI 0，10` 。
+
+目前市面上目前使用比较广泛的 MyBatis 分页插件有：
+
+- [Mybatis-PageHelper](https://github.com/pagehelper/Mybatis-PageHelper)
+- [MyBatis-Plus](https://github.com/baomidou/mybatis-plus)
+
+从现在看来，[MyBatis-Plus](https://github.com/baomidou/mybatis-plus) 逐步使用的更加广泛。
+
+关于 MyBatis 分页插件的原理深入，可以看看 [《精尽 MyBatis 源码分析 —— 插件体系（二）之 PageHelper》](http://svip.iocoder.cn/MyBatis/plugin-2) 。
+
+## MyBatis 与 Hibernate 有哪些不同？
+
+Mybatis 和 Hibernate 不同，它**不完全是**一个 ORM 框架，因为MyBatis 需要程序员自己编写 SQL 语句。不过 MyBatis 可以通过 XML 或注解方式灵活配置要运行的 SQL 语句，并将 Java 对象和 SQL 语句映射生成最终执行的 SQL ，最后将 SQL 执行的结果再映射生成 Java 对象。
+
+Mybatis 学习门槛低，简单易学，程序员直接编写原生态 SQL ，可严格控制 SQL 执行性能，灵活度高。但是灵活的前提是 MyBatis 无法做到数据库无关性，如果需要实现支持多种数据库的软件则需要自定义多套 SQL 映射文件，工作量大。
+
+Hibernate 对象/关系映射能力强，数据库无关性好。如果用 Hibernate 开发可以节省很多代码，提高效率。但是 Hibernate 的缺点是学习门槛高，要精通门槛更高，而且怎么设计 O/R 映射，在性能和对象模型之间如何权衡，以及怎样用好 Hibernate 需要具有很强的经验和能力才行。
+
+总之，按照用户的需求在有限的资源环境下只要能做出维护性、扩展性良好的软件架构都是好架构，所以框架只有适合才是最好。简单总结如下：
+
+- Hibernate 属于全自动 ORM 映射工具，使用 Hibernate 查询关联对象或者关联集合对象时，可以根据对象关系模型直接获取。
+- Mybatis 属于半自动 ORM 映射工具，在查询关联对象或关联集合对象时，需要手动编写 SQL 来完成。
+
+另外，在 [《浅析 Mybatis 与 Hibernate 的区别与用途》](https://www.jianshu.com/p/96171e647885) 文章，也是写的非常不错的。
+
+当然，实际上，MyBatis 也可以搭配自动生成代码的工具，提升开发效率，还可以使用 [MyBatis-Plus](http://mp.baomidou.com/) 框架，已经内置常用的 SQL 操作，也是非常不错的。
+
+## JDBC 编程有哪些不足之处，MyBatis是如何解决这些问题的？
+
+问题一：SQL 语句写在代码中造成代码不易维护，且代码会比较混乱。
+
+解决方式：将 SQL 语句配置在 Mapper XML 文件中，与 Java 代码分离。
+
+------
+
+问题二：根据参数不同，拼接不同的 SQL 语句非常麻烦。例如 SQL 语句的 WHERE 条件不一定，可能多也可能少，占位符需要和参数一一对应。
+
+解决方式：MyBatis 提供 `<where />`、`<if />` 等等动态语句所需要的标签，并支持 OGNL 表达式，简化了动态 SQL 拼接的代码，提升了开发效率。
+
+------
+
+问题三，对结果集解析麻烦，SQL 变化可能导致解析代码变化，且解析前需要遍历。
+
+解决方式：Mybatis 自动将 SQL 执行结果映射成 Java 对象。
+
+------
+
+问题四，数据库链接创建、释放频繁造成系统资源浪费从而影响系统性能，如果使用数据库链接池可解决此问题。
+
+解决方式：在 `mybatis-config.xml` 中，配置数据链接池，使用连接池管理数据库链接。
+
+😈 当然，即使不使用 MyBatis ，也可以使用数据库连接池。
+另外，MyBatis 默认提供了数据库连接池的实现，只是说，因为其它开源的数据库连接池性能更好，所以一般很少使用 MyBatis 自带的连接池实现。
+
+## Mybatis 比 IBatis 比较大的几个改进是什么？
+
+> 这是一个选择性了解的问题，因为可能现在很多面试官，都没用过 IBatis 框架。
+
+1. 有接口绑定，包括注解绑定 SQL 和 XML 绑定 SQL 。
+2. 动态 SQL 由原来的节点配置变成 OGNL 表达式。
+3. 在一对一或一对多的时候，引进了 `association` ，在一对多的时候，引入了 `collection`节点，不过都是在 `<resultMap />` 里面配置。
+
+## Mybatis 映射文件中，如果 A 标签通过 include 引用了B标签的内容，请问，B 标签能否定义在 A 标签的后面，还是说必须定义在A标签的前面？
+
+> 老艿艿：这道题目，已经和源码实现，有点关系了。
+
+虽然 Mybatis 解析 XML 映射文件是**按照顺序**解析的。但是，被引用的 B 标签依然可以定义在任何地方，Mybatis 都可以正确识别。**也就是说，无需按照顺序，进行定义**。
+
+原理是，Mybatis 解析 A 标签，发现 A 标签引用了 B 标签，但是 B 标签尚未解析到，尚不存在，此时，Mybatis 会将 A 标签标记为**未解析状态**。然后，继续解析余下的标签，包含 B 标签，待所有标签解析完毕，Mybatis 会重新解析那些被标记为未解析的标签，此时再解析A标签时，B 标签已经存在，A 标签也就可以正常解析完成了。
+
+可能有一些绕，胖友可以看看 [《精尽 MyBatis 源码解析 —— MyBatis 初始化（一）之加载 mybatis-config》](http://svip.iocoder.cn/MyBatis/builder-package-1) 。
+
+此处，我们在引申一个问题，Spring IOC 中，存在互相依赖的 Bean 对象，该如何解决呢？答案见 [《【死磕 Spring】—— IoC 之加载 Bean：创建 Bean（五）之循环依赖处理》](http://svip.iocoder.cn/Spring/IoC-get-Bean-createBean-5/) 。
+
+## 简述 Mybatis 的 XML 映射文件和 Mybatis 内部数据结构之间的映射关系？
+
+> 老艿艿：这道题目，已经和源码实现，有点关系了。
+
+Mybatis 将所有 XML 配置信息都封装到 All-In-One 重量级对象Configuration内部。
+
+在 XML Mapper 文件中：
+
+- `<parameterMap>` 标签，会被解析为 ParameterMap 对象，其每个子元素会被解析为 ParameterMapping 对象。
+- `<resultMap>` 标签，会被解析为 ResultMap 对象，其每个子元素会被解析为 ResultMapping 对象。
+- 每一个 `<select>`、`<insert>`、`<update>`、`<delete>` 标签，均会被解析为一个 MappedStatement 对象，标签内的 SQL 会被解析为一个 BoundSql 对象。
+
+## 666. 彩蛋
+
+参考与推荐如下文章：
+
+- 祖大俊 [《Mybatis3.4.x技术内幕（二十三）：Mybatis面试问题集锦（大结局）》](https://my.oschina.net/zudajun/blog/747682)
+- Java3y [《Mybatis 常见面试题》](https://segmentfault.com/a/1190000013678579)
+- Homiss [《MyBatis 面试题》](https://github.com/Homiss/Java-interview-questions/blob/master/框架/MyBatis面试题.md)
\ No newline at end of file
diff --git a/面试题/08-精尽【消息队列 】面试题.assets/01.png b/面试题/08-精尽【消息队列 】面试题.assets/01.png
new file mode 100644
index 0000000..1d8eec5
Binary files /dev/null and b/面试题/08-精尽【消息队列 】面试题.assets/01.png differ
diff --git a/面试题/08-精尽【消息队列 】面试题.assets/03.png b/面试题/08-精尽【消息队列 】面试题.assets/03.png
new file mode 100644
index 0000000..f008319
Binary files /dev/null and b/面试题/08-精尽【消息队列 】面试题.assets/03.png differ
diff --git a/面试题/08-精尽【消息队列 】面试题.assets/04.png b/面试题/08-精尽【消息队列 】面试题.assets/04.png
new file mode 100644
index 0000000..a15ab97
Binary files /dev/null and b/面试题/08-精尽【消息队列 】面试题.assets/04.png differ
diff --git a/面试题/08-精尽【消息队列 】面试题.assets/05.png b/面试题/08-精尽【消息队列 】面试题.assets/05.png
new file mode 100644
index 0000000..f301385
Binary files /dev/null and b/面试题/08-精尽【消息队列 】面试题.assets/05.png differ
diff --git a/面试题/08-精尽【消息队列 】面试题.assets/06.png b/面试题/08-精尽【消息队列 】面试题.assets/06.png
new file mode 100644
index 0000000..328375b
Binary files /dev/null and b/面试题/08-精尽【消息队列 】面试题.assets/06.png differ
diff --git a/面试题/08-精尽【消息队列 】面试题.assets/07.png b/面试题/08-精尽【消息队列 】面试题.assets/07.png
new file mode 100644
index 0000000..6e8660b
Binary files /dev/null and b/面试题/08-精尽【消息队列 】面试题.assets/07.png differ
diff --git a/面试题/08-精尽【消息队列 】面试题.assets/08.png b/面试题/08-精尽【消息队列 】面试题.assets/08.png
new file mode 100644
index 0000000..a433cbe
Binary files /dev/null and b/面试题/08-精尽【消息队列 】面试题.assets/08.png differ
diff --git a/面试题/08-精尽【消息队列 】面试题.assets/09.png b/面试题/08-精尽【消息队列 】面试题.assets/09.png
new file mode 100644
index 0000000..03fafcc
Binary files /dev/null and b/面试题/08-精尽【消息队列 】面试题.assets/09.png differ
diff --git a/面试题/08-精尽【消息队列 】面试题.md b/面试题/08-精尽【消息队列 】面试题.md
new file mode 100644
index 0000000..f042bf9
--- /dev/null
+++ b/面试题/08-精尽【消息队列 】面试题.md	
@@ -0,0 +1,484 @@
+# 精尽【消息队列 】面试题「最新更新时间：2024-02」
+
+以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。
+
+如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的【消息队列】面试题的大保健。
+
+而题目的难度，艿艿尽量按照从容易到困难的顺序，逐步下去。
+
+另外，本文只分享通用的【消息队列】的面试题，关于 RocketMQ、Kafka、RabbitMQ 会单独分享。
+
+## 什么是消息队列？
+
+消息队列，是分布式系统中重要的组件。
+
+- 主要解决应用耦合，异步消息，流量削锋等问题。
+- 可实现高性能，高可用，可伸缩和最终一致性架构，是大型分布式系统不可缺少的中间件。
+
+目前主流的消息队列有
+
+- Kafka
+- RabbitMQ
+- RocketMQ ，老版本是 MetaQ 。
+- ActiveMQ ，目前用的人越来越少了。
+
+另外，消息队列容易和 Java 中的本地 MessageQueue 搞混，所以消息队列更多被称为消息中间件、分布式消息队列等等。
+
+## 消息队列由哪些角色组成？
+
+如下图所示：
+
+[![MQ 角色](08-精尽【消息队列 】面试题.assets/01.png)](http://static.iocoder.cn/images/MQ/2019_11_12/01.png)MQ 角色
+
+- 生产者（Producer）：负责产生消息。
+- 消费者（Consumer）：负责消费消息
+- 消息代理（Message Broker）：负责存储消息和转发消息两件事情。其中，转发消息分为推送和拉取两种方式。
+  - 拉取（Pull），是指 Consumer 主动从 Message Broker 获取消息
+  - 推送（Push），是指 Message Broker 主动将 Consumer 感兴趣的消息推送给 Consumer 。
+
+## 消息队列有哪些使用场景？
+
+一般来说，有四大类使用场景：
+
+- 应用解耦
+- 异步处理
+- 流量削峰
+- 消息通讯
+- 日志处理
+
+**其中，应用解耦、异步处理是比较核心的**。
+
+> 艿艿：这个问题，也适合回答《为什么使用消息队列？》，当然需要扩充下，下面我们来看看。
+
+## 为什么使用消息队列进行应用解耦？
+
+传统模式下，如下图所示：[![传统模式](08-精尽【消息队列 】面试题.assets/03.png)](http://static.iocoder.cn/images/MQ/2019_11_12/03.png)传统模式
+
+- 缺点比较明显，系统间耦合性太强。系统 A 在代码中直接调用系统 B 和系统 C 的代码，如果将来 D 系统接入，系统 A 还需要修改代码，过于麻烦！并且，万一系统 A、B、C 万一还改接口，还要持续跟进。
+
+引入消息队列后，如下图所示：[![新模式](08-精尽【消息队列 】面试题.assets/04.png)](http://static.iocoder.cn/images/MQ/2019_11_12/04.png)新模式
+
+- 将消息写入消息队列，需要消息的系统自己从消息队列中订阅，从而系统 A 不需要做任何修改。
+
+所以，有了消息队列之后，从主动调用的方式，变成了消息的订阅发布( 或者说，事件的发布和监听 )，从而解耦。
+
+举个实际场景的例子，用户支付订单完成后，系统需要给用户发红包、增加积分等等行为，就可以通过这样的方式进行解耦。
+
+## 为什么使用消息队列进行异步处理？
+
+> 艿艿：这个应该对于大多数开发者，这是最最最核心的用途了！！！
+
+传统模式下，如下图所示：[![传统模式](08-精尽【消息队列 】面试题.assets/05.png)](http://static.iocoder.cn/images/MQ/2019_11_12/05.png)传统模式
+
+- A 系统需要
+
+  串行
+
+  逐个
+
+  同步
+
+  调用系统 B、C、D 。这其中会有很多问题：
+
+  - 如果每个系统调用执行是 200ms ，那么这个逻辑就要执行 600ms ，非常慢。
+  - 如果任一一个系统调用异常报错，那么整个逻辑就报错了。
+  - 如果任一一个系统调用超时，那么整个逻辑就超时了。
+  - …
+
+引入消息队列后，如下图所示：[![新模式](08-精尽【消息队列 】面试题.assets/06.png)](http://static.iocoder.cn/images/MQ/2019_11_12/06.png)新模式
+
+- 通过发送 3 条 MQ 消息，通过 Consumer 消费，从而
+
+  异步
+
+  、
+
+  并行
+
+  调用系统 B、C、D 。
+
+  - 因为发送 MQ 消息是比较快的，假设每个操作 2 ms ，那么这个逻辑只要执行 6 ms ，非常快。
+  - 当然，有胖友会有，可能发送 MQ 消息会失败。当然，这个是会存在的，此时可以异步重试。当然，可能异步重试的过程中，JVM 进程挂了，此时又需要其他的机制来保证。不过，相比**串行**逐个**同步**调用系统 B、C、D 来说，出错的几率会低很多很多。
+
+另外，使用消息队列进行异步处理，会有一个前提，返回的结果不依赖于处理的结果。
+
+## 为什么使用消息队列进行流量消峰？
+
+传统模式下，如下图所示：[![传统模式](08-精尽【消息队列 】面试题.assets/07.png)](http://static.iocoder.cn/images/MQ/2019_11_12/07.png)传统模式
+
+- 对于大多数系统，一定会有访问量的波峰和波谷。比较明显的，就是我们经常使用的美团外卖，又或者被人诟病的小米秒杀。
+- 如果在并发量大的时间，所有的请求直接打到数据库，造成数据库直接挂掉。
+
+引入消息队列后，如下图所示：[![新模式](08-精尽【消息队列 】面试题.assets/08.png)](http://static.iocoder.cn/images/MQ/2019_11_12/08.png)新模式
+
+- 通过将请求先转发到消息队列中。然后，系统 A 慢慢的按照数据库能处理的并发量，从消息队列中逐步拉取消息进行消费。在**生产中，这个短暂的高峰期积压是允许的**，😈 相比把数据库打挂来说。
+- 当然，可能有胖友说，访问量这么大，不会把消息队列给打挂么？相比来说，消息队列的性能会比数据库性能更好，并且，横向的扩展能力更强。
+
+## 为什么使用消息队列进行消息通信？
+
+消息通讯是指，消息队列一般都内置了高效的通信机制，因此也可以用在纯的消息通讯。比如实现：
+
+- IM 聊天。
+- 点对点消息队列。可能大家会比较懵逼，有基于消息队列的 RPC 框架实现，例如 [rabbitmq-jsonrpc](https://github.com/rabbitmq/rabbitmq-jsonrpc) ，虽然现在用的人比较少。
+- 面向物联网的 MQTT 。阿里在开源的 RocketMQ 基础上，增加了 MQTT 协议的支持，可见 [消息队列 for IoT](https://cn.aliyun.com/product/ons) 。
+- ….
+
+## 如何使用消息队列进行日志处理？
+
+日志处理，是指将消息队列用在日志处理中，比如 Kafka 的应用，解决大量**日志传输**的问题。
+
+[![日志传输](08-精尽【消息队列 】面试题.assets/09.png)](http://static.iocoder.cn/images/MQ/2019_11_12/09.png)日志传输
+
+- 日志采集客户端，负责日志数据采集，定时批量写入 Kafka 队列。
+- Kafka 消息队列，负责日志数据的接收，存储和转发。
+- 日志处理应用：订阅并消费 Kafka 队列中的日志数据。
+
+大家最熟悉的就是 [ELK + Kafka 日志方案](http://www.demodashi.com/demo/10181.html)，如下：
+
+> 详细的，胖友可以点击链接，查看文章。
+
+- Kafka ：接收用户日志的消息队列。
+- Logstash ：对接 Kafka 写入的日志，做日志解析，统一成 JSON 输出给 Elasticsearch 中。
+- Elasticsearch ：实时日志分析服务的核心技术，一个 schemaless ，实时的数据存储服务，通过 index 组织数据，兼具强大的搜索和统计功能。
+- Kibana ：基于 Elasticsearch 的数据可视化组件，超强的数据可视化能力是众多公司选择 ELK stack 的重要原因。
+
+## 消息队列有什么优缺点？
+
+任何中间件的引入，带来优点的时候，也同时会带来缺点。
+
+优点，在上述的 [「消息队列有哪些使用场景？」](https://svip.iocoder.cn/MQ/Interview/#) 问题中，我们已经看到了。
+
+缺点，主要是如下三点：
+
+- 系统可用性降低。
+
+  系统引入的外部依赖越多，越容易挂掉。本来你就是 A 系统调用 BCD 三个系统的接口就好了，本来 ABCD 四个系统好好的，没啥问题，你偏加个 MQ 进来，万一 MQ 挂了咋整，MQ 一挂，整套系统崩溃的，你不就完了？**所以，消息队列一定要做好高可用**。
+
+- 系统复杂度提高。
+
+  主要需要多考虑，1）消息怎么不重复消息。2）消息怎么保证不丢失。3）需要消息顺序的业务场景，怎么处理。
+
+- 一致性问题。
+
+  A 系统处理完了直接返回成功了，人都以为你这个请求就成功了。但是问题是，要是 B、C。D 三个系统那里，B、D 两个系统写库成功了，结果 C 系统写库失败了，咋整？你这数据就不一致了。
+  当然，这不仅仅是 MQ 的问题，引入 RPC 之后本身就存在这样的问题。**如果我们在使用 MQ 时，一定要达到数据的最终一致性**。即，C 系统最终执行完成。
+
+## 消息队列有几种消费语义？
+
+一共有 3 种，分别如下：
+
+1. 消息至多被消费一次（At most once）：消息可能会丢失，但绝不重传。
+2. 消息至少被消费一次（At least once）：消息可以重传，但绝不丢失。
+3. 消息仅被消费一次（Exactly once）：每一条消息只被传递一次。
+
+为了支持上面 3 种消费语义，可以分 3 个阶段，考虑消息队列系统中Producer、Message Broker、Consumer 需要满足的条件。
+
+> 下面的内容，可能比较绕，胖友耐心理解。
+
+🦅 **1. 消息至多被消费一次**
+
+该语义是最容易满足的，特点是整个消息队列吞吐量大，实现简单。适合能容忍丢消息，~~消息重复消费的任务~~（和厮大沟通了下，这句话应该是错的，所以去掉）。
+
+> 和晓峰又讨论了下，“~~消息重复消费的任务~~”的意思是，因为不会重复投递，所以间接解决了消息重复消费的问题。
+
+- Producer 发送消息到 Message Broker 阶段
+  - Producer 发消息给Message Broker 时，不要求 Message Broker 对接收到的消息响应确认，Producer 也不用关心 Message Broker 是否收到消息了。
+- Message Broker 存储/转发阶段
+  - 对 Message Broker 的存储不要求持久性。
+  - 转发消息时，也不用关心 Consumer 是否真的收到了。
+- Consumer 消费阶段
+  - Consumer 从 Message Broker 中获取到消息后，可以从 Message Broker 删除消息。
+  - 或 Message Broker 在消息被 Consumer 拿去消费时删除消息，不用关心 Consumer 最后对消息的消费情况如何。
+
+🦅 **2. 消息至少被消费一次**
+
+适合不能容忍丢消息，允许重复消费的任务。
+
+- Producer 发送消息到 Message Broker 阶段
+  - Producer 发消息给 Message Broker ，Message Broker 必须响应对消息的确认。
+- Message Broker 存储/转发阶段
+  - Message Broker 必须提供持久性保障。
+  - 转发消息时，Message Broker 需要 Consumer 通知删除消息，才能将消息删除。
+- Consumer消费阶段
+  - Consumer 从 Message Broker 中获取到消息，必须在消费完成后，Message Broker上的消息才能被删除。
+
+🦅 **3. 消息仅被消费一次**
+
+适合对消息消费情况要求非常高的任务，实现较为复杂。
+
+在这里需要考虑一个问题，就是这里的“仅被消费一次”指的是如下哪种场景：
+
+- Message Broker 上存储的消息被 Consumer 仅消费一次。
+- Producer 上产生的消息被 Consumer 仅消费一次。
+
+① Message Broker 上存储的消息被 Consumer 仅消费一次
+
+- Producer 发送消息到 Message Broker 阶段
+  - Producer 发消息给 Message Broker 时，不要求 Message Broker 对接收到的消息响应确认，Producer 也不用关心Message Broker 是否收到消息了。
+- Message Broker 存储/转发阶段
+  - Message Broker 必须提供持久性保障
+  - 并且，每条消息在其消费队列里有唯一标识（这个唯一标识可以由 Producer 产生，也可以由 Message Broker 产生）。
+- Consumer 消费阶段
+  - Consumer 从 Message Broker中获取到消息后，需要记录下消费的消息标识，以便在后续消费中防止对某个消息重复消费（比如 Consumer 获取到消息，消费完后，还没来得及从 Message Broker 删除消息，就挂了，这样 Message Broker 如果把消息重新加入待消费队列的话，那么这条消息就会被重复消费了）。
+
+② Producer 上产生的消息被 Consumer 仅消费一次
+
+- Producer 发送消息到 Message Broker 阶段
+  - Producer 发消息给 Message Broker 时，Message Broker 必须响应对消息的确认，并且 Producer 负责为该消息产生唯一标识，以防止 Consumer 重复消费（因为 Producer 发消息给Message Broker 后，由于网络问题没收到 Message Broker 的响应，可能会重发消息给到 Message Broker ）。
+- Message Broker 存储/转发阶段
+  - Message Broker 必须提供持久性保障
+  - 并且，每条消息在其消费队列里有唯一标识（这个唯一标识需要由Producer产生）。
+- Consumer 消费阶段
+  - 和【① Message Broker 上存储的消息被 Consumer 仅消费一次】相同。
+
+------
+
+虽然 3 种方式看起来比较复杂，但是我们会发现，是层层递进，越来越可靠。
+
+实际生产场景下，我们是倾向第 3 种的 ② 的情况，每条消息从 Producer 保证被送达，并且被 Consumer 仅消费一次。当然，重心还是如何保证 **Consumer 仅消费一次**，虽然说，消息产生的唯一标志可以在框架层级去做排重，但是最稳妥的，还是业务层也保证消费的幂等性。
+
+## 消息队列有几种投递方式？分别有什么优缺点
+
+在 [「消息队列由哪些角色组成？」](https://svip.iocoder.cn/MQ/Interview/#) 中，我们已经提到消息队列有 **push 推送**和 **pull 拉取**两种投递方式。
+
+一种模型的某些场景下的优点，在另一些场景就可能是缺点。无论是 push 还是 pull ，都存在各种的利弊。
+
+- push
+  - 优点，就是及时性。
+  - 缺点，就是受限于消费者的消费能力，可能造成消息的堆积，Broker 会不断给消费者发送不能处理的消息。
+- pull
+  - 优点，就是主动权掌握在消费方，可以根据自己的消息速度进行消息拉取。
+  - 缺点，就是消费方不知道什么时候可以获取的最新的消息，会有消息延迟和忙等。
+
+目前的消息队列，基于 push + pull 模式结合的方式，Broker 仅仅告诉 Consumer 有新的消息，具体的消息拉取，还是 Consumer 自己主动拉取。
+
+> 艿艿：其实这个问题，会告诉我们两个道理。
+>
+> 1. 一个功能的实现，有多种实现方式，有优点就有缺点。并且，一个实现的缺点，恰好是另外一个实现的优点。
+> 2. 一个功能的实现，可能是多种实现方式的结合，取一个平衡点，不那么优，也不那么缺。😈 再说一句题外话，是和否之间，还有灰色地方。
+
+## 如何保证消费者的消费消息的幂等性？
+
+🦅 **分析原因**
+
+在 [「消息队列有几种消费语义？」](https://svip.iocoder.cn/MQ/Interview/#) 中，我们已经看了三种消费语义。如果要达到消费者的消费消息的幂等性，就需要**消息仅被消费一次**，且**每条消息从 Producer 保证被送达，并且被 Consumer 仅消费一次**。
+
+那么，我们就基于这个场景，来思考下，为什么会出现消息重复的问题？
+
+- 对于 Producer 来说
+
+  - 可能因为网络问题，Producer 重试多次发送消息，实际第一次就发送成功，那么就会产生多条相同的消息。
+  - ….
+
+- 对于 Consumer 来说
+
+  - 可能因为 Broker 的消息进度丢失，导致消息重复投递给 Consumer 。
+
+  - Consumer 消费成功，但是因为 JVM 异常崩溃，导致消息的消费进度未及时同步给 Consumer 。
+
+    > 对于大多数消息队列，考虑到性能，消费进度是异步定时同步给 Broker 。
+
+  - …
+
+🦅 **如何解决**
+
+所以，上述的种种情况，都可能导致消费者会获取到重复的消息，那么我们的思考就无法是解决不发送、投递重复的消息，而是消费者在消费时，如何保证幂等性。
+
+消费者实现幂等性，有两种方式：
+
+1. 框架层统一封装。
+2. 业务层自己实现。
+
+① **框架层统一封装**
+
+首先，需要有一个消息排重的唯一标识，该编号只能由 Producer 生成，例如说使用 uuid、或者其它唯一编号的算法 。
+
+然后，就需要有一个排重的存储器，例如说：
+
+- 使用关系数据库，增加一个排重表，使用消息编号作为唯一主键。
+- 使用 KV 数据库，KEY 存储消息编号，VALUE 任一。*此处，暂时不考虑 KV 数据库持久化的问题*
+
+那么，我们要什么时候插入这条排重记录呢？
+
+- 在消息消费执行业务逻辑**之前**，插入这条排重记录。但是，此时会有可能 JVM 异常崩溃。那么 JVM 重启后，这条消息就无法被消费了。因为，已经存在这条排重记录。
+
+- 在消息消费执行业务逻辑
+
+  之后
+
+  ，插入这条排重记录。
+
+  - 如果业务逻辑执行失败，显然，我们不能插入这条排重记录，因为我们后续要消费重试。
+  - 如果业务逻辑执行成功，此时，我们可以插入这条排重记录。但是，万一插入这条排重记录失败呢？**那么，需要让插入记录和业务逻辑在同一个事务当中，此时，我们只能使用数据库**。
+
+😈 感觉好复杂，嘿嘿。
+
+② **业务层自己实现**
+
+方式很多，这个和 HTTP 请求实现幂等是一样的逻辑：
+
+- 先查询数据库，判断数据是否已经被更新过。如果是，则直接返回消费完成，否则执行消费。
+- 更新数据库时，带上数据的状态。如果更新失败，则直接返回消费完成，否则执行消费。
+- …
+
+如果胖友的系统的并发量非常大，可以使用 Zookeeper 或者 Redis 实现分布式锁，避免并发带来的问题。当然，引入一个组件，也会带来另外的复杂性：
+
+1. 系统的并发能力下降。
+2. Zookeeper 和 Redis 在获取分布式锁时，发现它们已经挂掉，此时到底要不要继续执行下去呢？嘿嘿。
+
+**选择**
+
+正常情况下，出现重复消息的概率其实很小，如果由框架层统一封装来实现的话，肯定会对消息系统的吞吐量和高可用有影响，所以最好还是由业务层自己实现处理消息重复的问题。
+
+当然，这两种方式不是冲突的。可以提供不同类型的消息，根据配置，使用哪种方式。例如说：
+
+- 默认情况下，开启【框架层统一封装】的功能。
+- 可以通过配置，关闭【框架层统一封装】的功能。
+
+当然，如果可能的话，尽可能业务层自己实现。/(ㄒoㄒ)/~~但是，实际上，很多时候，开发者不太会注意，哈哈哈哈。
+
+## 如何保证生产者的发送消息的可靠性？
+
+不同的消息队列，其架构不同，所以实现发送消息的可靠性的方案不同。所以参见如下文章：
+
+- RocketMQ [《精尽 RocketMQ 面试题》](http://svip.iocoder.cn/RocketMQ/Interview/) 的 [「RocketMQ 是否会弄丢数据？」](https://svip.iocoder.cn/MQ/Interview/#) 的面试题。
+- RabbitMQ [《精尽 RabbitMQ 面试题》](http://svip.iocoder.cn/RabbitMQ/Interview/) 的 [「RabbitMQ 是否会弄丢数据？」](https://svip.iocoder.cn/MQ/Interview/#) 的面试题。
+- Kafka [《精尽 Kafka 面试题》](http://svip.iocoder.cn/Kafka/Interview/) 的 [「Kafka 是否会弄丢数据？」](https://svip.iocoder.cn/MQ/Interview/#) 的面试题。
+
+## 如何保证消息的顺序性？
+
+不同的消息队列，其架构不同，所以实现消息的顺序性的方案不同。所以参见如下文章：
+
+- RocketMQ [《精尽 RocketMQ 面试题》](http://svip.iocoder.cn/RocketMQ/Interview/) 的 [「什么是顺序消息？如何实现？」](https://svip.iocoder.cn/MQ/Interview/#) 的面试题。
+- RabbitMQ [《精尽 RabbitMQ 面试题》](http://svip.iocoder.cn/RabbitMQ/Interview/) 的 [「RabbitMQ 如何保证消息的顺序性？」](https://svip.iocoder.cn/MQ/Interview/#) 面试题。
+- Kafka [《精尽 Kafka 面试题》](http://svip.iocoder.cn/Kafka/Interview/) 的 [「Kafka 如何保证消息的顺序性？」](https://svip.iocoder.cn/MQ/Interview/#) 的面试题。
+
+## 如何解决消息积压的问题？
+
+TODO
+
+## 如何解决消息过期的问题？
+
+TODO
+
+## 消息队列如何实现高可用？
+
+不同的消息队列，其架构不同，所以实现高可用的方案不同。所以参见如下文章：
+
+- RocketMQ [《精尽 RocketMQ 面试题》](http://svip.iocoder.cn/RocketMQ/Interview/) 的 [「如何实现 RocketMQ 高可用？」](https://svip.iocoder.cn/MQ/Interview/#) 的面试题。
+- RabbitMQ [《精尽 RabbitMQ 面试题》](http://svip.iocoder.cn/RabbitMQ/Interview/) 的 [「RabbitMQ 如何实现高可用？」](https://svip.iocoder.cn/MQ/Interview/#) 的面试题。
+- Kafka [《精尽 Kafka 面试题》](http://svip.iocoder.cn/Kafka/Interview/) 的 [「Kafka 如何实现高可用？」](https://svip.iocoder.cn/MQ/Interview/#) 的面试题。
+
+## Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么优缺点？
+
+这四者，对比如下表格如下：
+
+| 特性                     | ActiveMQ                              | RabbitMQ                                           | RocketMQ                                                     | Kafka                                                        |
+| :----------------------- | :------------------------------------ | :------------------------------------------------- | :----------------------------------------------------------- | :----------------------------------------------------------- |
+| 单机吞吐量               | 万级，比 RocketMQ、Kafka 低一个数量级 | 同 ActiveMQ                                        | 10 万级，支撑高吞吐                                          | 10 万级，高吞吐，一般配合大数据类的系统来进行实时数据计算、日志采集等场景 |
+| topic 数量对吞吐量的影响 |                                       |                                                    | topic 可以达到几百/几千的级别，吞吐量会有较小幅度的下降，这是 RocketMQ 的一大优势，在同等机器下，可以支撑大量的 topic | topic 从几十到几百个时候，吞吐量会大幅度下降，在同等机器下，Kafka 尽量保证 topic 数量不要过多，如果要支撑大规模的 topic，需要增加更多的机器资源 |
+| 时效性                   | ms 级                                 | 微秒级，这是 RabbitMQ 的一大特点，延迟最低         | ms 级                                                        | 延迟在 ms 级以内                                             |
+| 可用性                   | 高，基于主从架构实现高可用            | 同 ActiveMQ                                        | 非常高，分布式架构                                           | 非常高，分布式，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用 |
+| 消息可靠性               | 有较低的概率丢失数据                  |                                                    | 经过参数优化配置，可以做到 0 丢失                            | 同 RocketMQ                                                  |
+| 功能支持                 | MQ 领域的功能极其完备                 | 基于 erlang 开发，并发能力很强，性能极好，延时很低 | MQ 功能较为完善，还是分布式的，扩展性好                      | 功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用 |
+
+🦅 **ActiveMQ**
+
+一般的业务系统要引入 MQ，最早大家都用 ActiveMQ ，但是现在确实大家用的不多了( 特别是互联网公司 )，没经过大规模吞吐量场景的验证( **性能较差** )，社区也不是很活跃( 主要精力在研发 [ActiveMQ Apollo](https://activemq.apache.org/apollo/) )，所以大家还是算了，我个人不推荐用这个了。
+
+🦅 **RabbitMQ**
+
+后来大家开始用 RabbitMQ，但是确实 Erlang 语言阻止了大量的 Java 工程师去深入研究和掌控它，对公司而言，几乎处于不可控的状态，但是确实人家是开源的，比较稳定的支持，社区活跃度也高。另外，因为 Spring Cloud 在消息队列的支持上，对 RabbitMQ 是比较不错的，所以在选型上又更加被推崇。
+
+🦅 **RocketMQ**
+
+不过现在确实越来越多的公司，会去用 RocketMQ，确实很不错（阿里出品）。~~但社区可能有突然黄掉的风险，对自己公司技术实力有绝对自信的，推荐用 RocketMQ，否则回去老老实实用 RabbitMQ 吧，人家有活跃的开源社区，绝对不会黄。~~ 目前已经加入 Apache ，所以社区层面有相应的保证，并且是使用 Java 语言进行实现，对于 Java 工程师更容易去深入研究和掌控它。目前，也是比较推荐去选择的。并且，如果使用阿里云，可以直接使用其云服务。
+
+当然，现在比较被社区诟病的是，官方暂未提供比较好的中文文档，国内外也缺乏比较好的 RocketMQ 书籍，所以是比较大的痛点。
+
+🦅 **总结**
+
+- 所以**中小型公司**，技术实力较为一般，技术挑战不是特别高，用 RabbitMQ 是不错的选择
+
+- 大型公司
+
+  ，基础架构研发实力较强，用 RocketMQ 是很好的选择。
+
+  - 当然，中小型公司使用 RocketMQ 也是没什么问题的选择，特别是以 Java 为主语言的公司。
+
+- 如果是
+
+  大数据领域
+
+  的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范。
+
+  - 另外，目前国内也是有非常多的公司，将 Kafka 应用在业务系统中，例如唯品会、陆金所、美团等等。
+
+目前，艿艿的团队使用 RocketMQ 作为消息队列，因为有 RocketMQ 5 年左右使用经验，并且目前线上环境是使用阿里云，适合我们团队。
+
+🦅 **补充**
+
+推荐阅读如下几篇文章：
+
+- [《Kafka、RabbitMQ、RocketMQ等消息中间件的对比》](https://blog.csdn.net/belvine/article/details/80842240)
+- [《Kafka、RabbitMQ、RocketMQ消息中间件的对比 —— 消息发送性能》](http://jm.taobao.org/2016/04/01/kafka-vs-rabbitmq-vs-rocketmq-message-send-performance/)
+- [《RocketMQ与Kafka对比（18项差异）》](https://www.cnblogs.com/BYRans/p/6100653.html)
+
+当然，很多测评放在现在已经不适用了，特别是 Kafka ，大量评测是基于 0.X 版本，而 Kafka 目前已经演进到 2.X 版本，已经不可同日而语了。
+
+🔥 **使用示例**
+
+- [《芋道 Spring Boot 消息队列 RocketMQ 入门》](http://www.iocoder.cn/Spring-Boot/RocketMQ/?vip) 对应 [lab-31](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-31) 。
+- [《芋道 Spring Boot 消息队列 Kafka 入门》](http://www.iocoder.cn/Spring-Boot/Kafka/?vip) 对应 [lab-03-kafka](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-03-kafka)
+- [《芋道 Spring Boot 消息队列 RabbitMQ 入门》](http://www.iocoder.cn/Spring-Boot/RabbitMQ/?vip) 对应 [lab-04-rabbitmq](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-04-rabbitmq)
+- [《芋道 Spring Boot 消息队列 ActiveMQ 入门》](http://www.iocoder.cn/Spring-Boot/ActiveMQ/?vip) 对应 [lab-32](https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-32) 。
+
+## 消息队列的一般存储方式有哪些？
+
+当前业界几款主流的MQ消息队列采用的存储方式主要有以下三种方式。
+
+🦅 **1. 分布式KV存储**
+
+这类 MQ 一般会采用诸如 LevelDB 、RocksDB 和 Redis 来作为消息持久化的方式。由于分布式缓存的读写能力要优于 DB ，所以在对消息的读写能力要求都不是比较高的情况下，采用这种方式倒也不失为一种可以替代的设计方案。
+
+消息存储于分布式 KV 需要解决的问题在于如何保证 MQ 整体的可靠性。
+
+🦅 **2. 文件系统**
+
+目前业界较为常用的几款产品（RocketMQ / Kafka / RabbitMQ）均采用的是消息刷盘至所部署虚拟机/物理机的文件系统来做持久化（刷盘一般可以分为异步刷盘和同步刷盘两种模式）。
+
+> 刷盘指的是存储到硬盘。
+
+消息刷盘为消息存储提供了一种高效率、高可靠性和高性能的数据持久化方式。除非部署 MQ 机器本身或是本地磁盘挂了，否则一般是不会出现无法持久化的故障问题。
+
+🦅 **3. 关系型数据库 DB**
+
+Apache下开源的另外一款MQ—ActiveMQ（默认采用的KahaDB做消息存储）可选用 JDBC 的方式来做消息持久化，通过简单的 XML 配置信息即可实现JDBC消息存储。
+
+由于，普通关系型数据库（如 MySQL ）在单表数据量达到千万级别的情况下，其 IO 读写性能往往会出现瓶颈。因此，如果要选型或者自研一款性能强劲、吞吐量大、消息堆积能力突出的 MQ 消息队列，那么并不推荐采用关系型数据库作为消息持久化的方案。在可靠性方面，该种方案非常依赖 DB ，如果一旦 DB 出现故障，则 MQ 的消息就无法落盘存储会导致线上故障。
+
+🦅 **小结**
+
+因此，综合上所述从存储效率来说，**文件系统 > 分布式 KV 存储 > 关系型数据库 DB** ，直接操作文件系统肯定是最快和最高效的，而关系型数据库 TPS 一般相比于分布式 KV 系统会更低一些（简略地说，关系型数据库本身也是一个需要读写文件 Server ，这时 MQ 作为 Client与其建立连接并发送待持久化的消息数据，同时又需要依赖 DB 的事务等，这一系列操作都比较消耗性能），所以如果追求高效的IO读写，那么选择操作文件系统会更加合适一些。但是如果从易于实现和快速集成来看，**文件系统 > 分布式 KV 存储 > 关系型数据库 DB**，但是性能会下降很多。
+
+另外，从消息中间件的本身定义来考虑，应该尽量减少对于外部第三方中间件的依赖。一般来说依赖的外部系统越多，也会使得本身的设计越复杂，所以个人的理解是采用**文件系统**作为消息存储的方式，更贴近消息中间件本身的定义。
+
+## 如何自己设计消息队列？
+
+TODO
+
+## 666. 彩蛋
+
+写的头疼，嘻嘻。继续加油~~
+
+参考与推荐如下文章：
+
+- 小火箭 [《关于消息队列的思考》](http://yangxikun.com/2017/03/22/message-queue.html)
+- zhangxd [《JAVA 高级面试题 1》](http://zhangxianda.com/2017/06/22/JAVA高级面试题/)
+- wayen [《面试：分布式之消息队列要点复习》](https://segmentfault.com/a/1190000015301449)
+- 步积 [《消息队列技术介绍》](https://www.jianshu.com/p/689ce4205021) 。如果胖友对 MQ 没有系统了解过，可以认真仔细看看。
+- 送人玫瑰手留余香 [《面试阿里后的总结》](http://www.voidcn.com/article/p-dzmqlwhn-boa.html)
+- yanglbme [《为什么使用消息队列？消息队列有什么优点和缺点？Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么优点和缺点？》](https://github.com/doocs/advanced-java/blob/master/docs/high-concurrency/why-mq.md)
+- 癫狂侠 [《消息中间件—RocketMQ消息存储（一）》](https://www.jianshu.com/p/b73fdd893f98)
+- hacpai [《【面试宝典】消息队列如何保证幂等性？》](https://hacpai.com/article/1542160729029)
+- yanglbme [《如何保证消息不被重复消费？（如何保证消息消费时的幂等性）》](https://github.com/doocs/advanced-java/blob/master/docs/high-concurrency/how-to-ensure-that-messages-are-not-repeatedly-consumed.md)
\ No newline at end of file
diff --git a/面试题/09-RocketMQ 面试题.assets/01.png b/面试题/09-RocketMQ 面试题.assets/01.png
new file mode 100644
index 0000000..f1a4bfa
Binary files /dev/null and b/面试题/09-RocketMQ 面试题.assets/01.png differ
diff --git a/面试题/09-RocketMQ 面试题.assets/02.png b/面试题/09-RocketMQ 面试题.assets/02.png
new file mode 100644
index 0000000..6caa0e5
Binary files /dev/null and b/面试题/09-RocketMQ 面试题.assets/02.png differ
diff --git a/面试题/09-RocketMQ 面试题.md b/面试题/09-RocketMQ 面试题.md
new file mode 100644
index 0000000..d272486
--- /dev/null
+++ b/面试题/09-RocketMQ 面试题.md	
@@ -0,0 +1,531 @@
+# 精尽 RocketMQ 面试题「最新更新时间：2024-02」
+
+以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。
+
+如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的 RocketMQ 的大保健。
+
+而题目的难度，艿艿尽量按照从容易到困难的顺序，逐步下去。
+
+> 友情提示：在开始阅读之前，胖友至少对 [《RocketMQ —— 角色与术语详解》](http://jaskey.github.io/blog/2016/12/15/rocketmq-concept/) 有简单的了解。
+
+另外，这个面试题是建立在胖友看过 [《精尽【消息队列 】面试题》](http://svip.iocoder.cn/MQ/Interview) 。
+
+## RocketMQ 是什么？
+
+RocketMQ 是阿里巴巴在 2012 年开源的分布式消息中间件，目前已经捐赠给 Apache 软件基金会，并于 2017 年 9 月 25 日成为 Apache 的顶级项目。作为经历过多次阿里巴巴双十一这种“超级工程”的洗礼并有稳定出色表现的国产中间件，以其高性能、低延时和高可靠等特性近年来已经也被越来越多的国内企业使用。
+
+------
+
+如下是 RocketMQ 产生的原因：
+
+> 淘宝内部的交易系统使用了淘宝自主研发的 Notify 消息中间件，使用 MySQL 作为消息存储媒介，可完全水平扩容，为了进一步降低成本，我们认为存储部分可以进一步优化，2011 年初，Linkin开源了 Kafka 这个优秀的消息中间件，淘宝中间件团队在对 Kafka 做过充分 Review 之后， Kafka 无限消息堆积，高效的持久化速度吸引了我们，但是同时发现这个消息系统主要定位于日志传输，对于使用在淘宝交易、订单、充值等场景下还有诸多特性不满足，为此我们重新用 Java 语言编写了 RocketMQ ，定位于非日志的可靠消息传输（日志场景也OK），目前 RocketMQ 在阿里集团被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理， binglog 分发等场景。
+
+## RocketMQ 由哪些角色组成？
+
+如下图所示：[![RocketMQ 角色](09-RocketMQ 面试题.assets/01.png)](http://static.iocoder.cn/images/RocketMQ/2019_11_12/01.png)RocketMQ 角色
+
+- 生产者（Producer）：负责产生消息，生产者向消息服务器发送由业务应用程序系统生成的消息。
+- 消费者（Consumer）：负责消费消息，消费者从消息服务器拉取信息并将其输入用户应用程序。
+- 消息服务器（Broker）：是消息存储中心，主要作用是接收来自 Producer 的消息并存储， Consumer 从这里取得消息。
+- 名称服务器（NameServer）：用来保存 Broker 相关 Topic 等元信息并给 Producer ，提供 Consumer 查找 Broker 信息。
+
+## 请描述下 RocketMQ 的整体流程？
+
+[![整体流程](09-RocketMQ 面试题.assets/02.png)](http://static.iocoder.cn/images/RocketMQ/2019_11_12/02.png)整体流程
+
+- 1、启动 **Namesrv**，Namesrv起 来后监听端口，等待 Broker、Producer、Consumer 连上来，相当于一个路由控制中心。
+
+- 2、**Broker** 启动，跟所有的 Namesrv 保持长连接，定时发送心跳包。
+
+  > 心跳包中，包含当前 Broker 信息(IP+端口等)以及存储所有 Topic 信息。
+  > 注册成功后，Namesrv 集群中就有 Topic 跟 Broker 的映射关系。
+
+  - 3、收发消息前，先创建 Topic 。创建 Topic 时，需要指定该 Topic 要存储在 哪些 Broker上。也可以在发送消息时自动创建Topic。
+
+- 4、**Producer** 发送消息。
+
+  > 启动时，先跟 Namesrv 集群中的其中一台建立长连接，并从Namesrv 中获取当前发送的 Topic 存在哪些 Broker 上，然后跟对应的 Broker 建立长连接，直接向 Broker 发消息。
+
+- 5、**Consumer** 消费消息。
+
+  > Consumer 跟 Producer 类似。跟其中一台 Namesrv 建立长连接，获取当前订阅 Topic 存在哪些 Broker 上，然后直接跟 Broker 建立连接通道，开始消费消息。
+
+------
+
+> 艿艿：下面，我们先逐步对 RocketMQ 每个角色进行介绍。
+>
+> 对不了解 RocketMQ 的胖友来说，可能概念会有点多。淡定~
+
+## 请说说你对 Namesrv 的了解？
+
+- 1、 Namesrv 用于存储 Topic、Broker 关系信息，功能简单，稳定性高。
+
+  - 多个 Namesrv 之间相互没有通信，单台 Namesrv 宕机不影响其它 Namesrv 与集群。
+
+    > 多个 Namesrv 之间的信息共享，**通过 Broker 主动向多个 Namesrv 都发起心跳**。正如上文所说，Broker 需要跟所有 Namesrv 连接。
+
+  - 即使整个 Namesrv 集群宕机，已经正常工作的 Producer、Consumer、Broker 仍然能正常工作，但新起的 Producer、Consumer、Broker 就无法工作。
+
+    > 这点和 Dubbo 有些不同，不会缓存 Topic 等元信息到本地文件。
+
+- 2、 Namesrv 压力不会太大，平时主要开销是在维持心跳和提供 Topic-Broker 的关系数据。但有一点需要注意，Broker 向 Namesr 发心跳时，会带上当前自己所负责的所有 Topic 信息，如果 Topic 个数太多（万级别），会导致一次心跳中，就 Topic 的数据就几十 M，网络情况差的话，网络传输失败，心跳失败，导致 Namesrv 误认为 Broker 心跳失败。
+
+  > 当然，一般公司，很难达到过万级的 Topic ，因为一方面体量达不到，另一方面 RocketMQ 提供了 Tag 属性。
+  >
+  > 另外，内网环境网络相对是比较稳定的，传输几十 M 问题不大。同时，如果真的要优化，Broker 可以把心跳包做压缩，再发送给 Namesrv 。不过，这样也会带来 CPU 的占用率的提升。
+
+## 如何配置 Namesrv 地址到生产者和消费者？
+
+将 Namesrv 地址列表提供给客户端( 生产者和消费者 )，有四种方法：
+
+- 编程方式，就像 `producer.setNamesrvAddr("ip:port")` 。
+- Java 启动参数设置，使用 `rocketmq.namesrv.addr` 。
+- 环境变量，使用 `NAMESRV_ADDR` 。
+- HTTP 端点，例如说：`http://namesrv.rocketmq.xxx.com` 地址，通过 DNS 解析获得 Namesrv 真正的地址。
+
+## 请说说你对 Broker 的了解？
+
+- 1、 **高并发读写服务**。Broker的高并发读写主要是依靠以下两点：
+
+  - 消息顺序写，所有 Topic 数据同时只会写一个文件，一个文件满1G ，再写新文件，真正的顺序写盘，使得发消息 TPS 大幅提高。
+  - 消息随机读，RocketMQ 尽可能让读命中系统 Pagecache ，因为操作系统访问 Pagecache 时，即使只访问 1K 的消息，系统也会提前预读出更多的数据，在下次读时就可能命中 Pagecache ，减少 IO 操作。
+
+- 2、 **负载均衡与动态伸缩**。
+
+  - 负载均衡：Broker 上存 Topic 信息，Topic 由多个队列组成，队列会平均分散在多个 Broker 上，而 Producer 的发送机制保证消息尽量平均分布到所有队列中，最终效果就是所有消息都平均落在每个 Broker 上。
+
+  - 动态伸缩能力（非顺序消息）：Broker 的伸缩性体现在两个维度：Topic、Broker。
+
+    - Topic 维度：假如一个 Topic 的消息量特别大，但集群水位压力还是很低，就可以扩大该 Topic 的队列数， Topic 的队列数跟发送、消费速度成正比。
+
+      > Topic 的队列数一旦扩大，就无法很方便的缩小。因为，生产者和消费者都是基于相同的队列数来处理。
+      > 如果真的想要缩小，只能新建一个 Topic ，然后使用它。
+      > 不过，Topic 的队列数，也不存在什么影响的，淡定。
+
+    - Broker 维度：如果集群水位很高了，需要扩容，直接加机器部署 Broker 就可以。Broker 启动后向 Namesrv 注册，Producer、Consumer 通过 Namesrv 发现新Broker，立即跟该 Broker 直连，收发消息。
+
+      > 新增的 Broker 想要下线，想要下线也比较麻烦，暂时没特别好的方案。大体的前提是，消费者消费完该 Broker 的消息，生产者不往这个 Broker 发送消息。
+
+- 3、 **高可用 & 高可靠**。
+
+  - 高可用：集群部署时一般都为主备，备机实时从主机同步消息，如果其中一个主机宕机，备机提供消费服务，但不提供写服务。
+
+  - 高可靠：所有发往 Broker 的消息，有同步刷盘和异步刷盘机制。
+
+    - 同步刷盘时，消息写入物理文件才会返回成功。
+
+    - 异步刷盘时，只有机器宕机，才会产生消息丢失，Broker 挂掉可能会发生，但是机器宕机崩溃是很少发生的，除非突然断电。
+
+      > 如果 Broker 挂掉，未同步到硬盘的消息，还在 Pagecache 中呆着。
+
+- 4、 **Broker 与 Namesrv 的心跳机制**。
+
+  - 单个 Broker 跟所有 Namesrv 保持心跳请求，心跳间隔为30秒，心跳请求中包括当前 Broker 所有的 Topic 信息。
+  - Namesrv 会反查 Broker 的心跳信息，如果某个 Broker 在 2 分钟之内都没有心跳，则认为该 Broker 下线，调整 Topic 跟 Broker 的对应关系。但此时 Namesrv 不会主动通知Producer、Consumer 有 Broker 宕机。也就说，只能等 Producer、Consumer 下次定时拉取 Topic 信息的时候，才会发现有 Broker 宕机。
+
+从上面的描述中，我们也已经发现 Broker 是 RocketMQ 中最最最复杂的角色，主要包括如下五个模块：
+
+[Broker 组件图](https://ws1.sinaimg.cn/large/006tKfTcgy1fo4vbpoxtej30r30dsdgs.jpg)
+
+- 远程处理模块：是 Broker 的入口，处理来自客户的请求。
+- Client Manager ：管理客户端（生产者/消费者），并维护消费者的主题订阅。
+- Store Service ：提供简单的 API 来存储或查询物理磁盘中的消息。
+- HA 服务：提供主节点和从节点之间的数据同步功能。
+- 索引服务：通过指定键为消息建立索引，并提供快速的消息查询。
+
+## Broker 如何实现消息的存储？
+
+关于 Broker 如何实现消息的存储，这是一个很大的话题，所以艿艿建议直接看如下的资料，保持耐心。
+
+- 《读懂这篇文章，你的阿里技术面就可以过关了 | Apache RocketMQ》
+
+   
+
+  的如下部分：
+
+  - [「三、RocketMQ的存储模型」](https://svip.iocoder.cn/RocketMQ/Interview/#)
+
+- 《RocketMQ 原理简介》
+
+   
+
+  的如下部分：
+
+  - [「6.3 数据存储结构」](https://svip.iocoder.cn/RocketMQ/Interview/#)
+  - [「6.4 存储目录结构」](https://svip.iocoder.cn/RocketMQ/Interview/#)
+  - [「7.1 单机支持 1 万以上持久化队列」](https://svip.iocoder.cn/RocketMQ/Interview/#)
+  - [「7.2 刷盘策略」](https://svip.iocoder.cn/RocketMQ/Interview/#)
+
+- 癫狂侠
+
+  - [《消息中间件 —— RocketMQ消息存储（一）》](https://www.jianshu.com/p/b73fdd893f98)
+  - [《消息中间件 —— RocketMQ消息存储（二）》](https://www.jianshu.com/p/6d0c118c17de)
+
+## 请说说你对 Producer 的了解？
+
+- 1、**获得 Topic-Broker 的映射关系**。
+
+  - Producer 启动时，也需要指定 Namesrv 的地址，从 Namesrv 集群中选一台建立长连接。如果该 Namesrv 宕机，会自动连其他 Namesrv ，直到有可用的 Namesrv 为止。
+  - 生产者每 30 秒从 Namesrv 获取 Topic 跟 Broker 的映射关系，更新到本地内存中。然后再跟 Topic 涉及的所有 Broker 建立长连接，每隔 30 秒发一次心跳。
+  - 在 Broker 端也会每 10 秒扫描一次当前注册的 Producer ，如果发现某个 Producer 超过 2 分钟都没有发心跳，则断开连接。
+
+- 2、**生产者端的负载均衡**。
+
+  - 生产者发送时，会自动轮询当前所有可发送的broker，一条消息发送成功，下次换另外一个broker发送，以达到消息平均落到所有的broker上。
+
+    > 这里需要注意一点：假如某个 Broker 宕机，意味生产者最长需要 30 秒才能感知到。在这期间会向宕机的 Broker 发送消息。当一条消息发送到某个 Broker 失败后，会自动再重发 2 次，假如还是发送失败，则抛出发送失败异常。
+    >
+    > 客户端里会自动轮询另外一个 Broker 重新发送，这个对于用户是透明的。
+
+## Producer 发送消息有几种方式？
+
+Producer 发送消息，有三种方式：
+
+1. 同步方式
+2. 异步方式
+3. Oneway 方式
+
+其中，方式 1 和 2 比较常见，具体使用哪一种方式需要根据业务情况来判断。而方式 3 ，适合大数据场景，允许有一定消息丢失的场景。
+
+具体的代码实现，可以看看 [《芋道 Spring Boot 消息队列 RocketMQ 入门》](http://www.iocoder.cn/Spring-Boot/RocketMQ/?vip)的[「3. 快速入门」](https://svip.iocoder.cn/RocketMQ/Interview/#) 小节
+
+## 请说说你对 Consumer 的了解？
+
+- 1、
+
+  获得 Topic-Broker 的映射关系
+
+  。
+
+  - Consumer 启动时需要指定 Namesrv 地址，与其中一个 Namesrv 建立长连接。消费者每隔 30 秒从 Namesrv 获取所有Topic 的最新队列情况，这意味着某个 Broker 如果宕机，客户端最多要 30 秒才能感知。连接建立后，从 Namesrv 中获取当前消费 Topic 所涉及的 Broker，直连 Broker 。
+  - Consumer 跟 Broker 是长连接，会每隔 30 秒发心跳信息到Broker 。Broker 端每 10 秒检查一次当前存活的 Consumer ，若发现某个 Consumer 2 分钟内没有心跳，就断开与该 Consumer 的连接，并且向该消费组的其他实例发送通知，触发该消费者集群的负载均衡。
+
+- 2、**消费者端的负载均衡**。根据消费者的消费模式不同，负载均衡方式也不同。
+
+  > 消费者有两种消费模式：集群消费和广播消费。
+  >
+  > - 集群消费：一个 Topic 可以由同一个消费这分组( Consumer Group )下所有消费者分担消费。
+  >   具体例子：假如 TopicA 有 6 个队列，某个消费者分组起了 2 个消费者实例，那么每个消费者负责消费 3 个队列。如果再增加一个消费者分组相同消费者实例，即当前共有 3 个消费者同时消费 6 个队列，那每个消费者负责 2 个队列的消费。
+
+  - 广播消费：每个消费者消费 Topic 下的所有队列。
+
+## 消费者消费模式有几种？
+
+消费者消费模式有两种：集群消费和广播消费。
+
+🦅 **1. 集群消费**
+
+消费者的一种消费模式。一个 Consumer Group 中的各个 Consumer 实例分摊去消费消息，即一条消息只会投递到一个 Consumer Group 下面的一个实例。
+
+- 实际上，每个 Consumer 是平均分摊 Message Queue 的去做拉取消费。例如某个 Topic 有 3 个队列，其中一个 Consumer Group 有 3 个实例（可能是 3 个进程，或者 3 台机器），那么每个实例只消费其中的 1 个队列。
+- 而由 Producer 发送消息的时候是轮询所有的队列，所以消息会平均散落在不同的队列上，可以认为队列上的消息是平均的。那么实例也就平均地消费消息了。
+- 这种模式下，消费进度的存储会持久化到 Broker 。
+- 当新建一个 Consumer Group 时，默认情况下，该分组的消费者会从 min offset 开始重新消费消息。
+
+具体的代码实现，可以看看 [《芋道 Spring Boot 消息队列 RocketMQ 入门》](http://www.iocoder.cn/Spring-Boot/RocketMQ/?vip)的[「3. 快速入门」](https://svip.iocoder.cn/RocketMQ/Interview/#) 小节，在[「3.10 简单测试」](https://svip.iocoder.cn/RocketMQ/Interview/#)中有集群消费的示例。
+
+🦅 **2. 广播消费**
+
+消费者的一种消费模式。消息将对一 个Consumer Group 下的各个 Consumer 实例都投递一遍。即即使这些 Consumer 属于同一个Consumer Group ，消息也会被 Consumer Group 中的每个 Consumer 都消费一次。
+
+- 实际上，是一个消费组下的每个消费者实例都获取到了 Topic 下面的每个 Message Queue 去拉取消费。所以消息会投递到每个消费者实例。
+- 这种模式下，消费进度会存储持久化到实例本地。
+
+具体的代码实现，可以看看 [《芋道 Spring Boot 消息队列 RocketMQ 入门》](http://www.iocoder.cn/Spring-Boot/RocketMQ/?vip)的[「7. 广播消费」](https://svip.iocoder.cn/RocketMQ/Interview/#) 小节。
+
+## 消费者获取消息有几种模式？
+
+消费者获取消息有两种模式：推送模式和拉取模式。
+
+🦅 **1. PushConsumer**
+
+推送模式（虽然 RocketMQ 使用的是长轮询）的消费者。消息的能及时被消费。使用非常简单，内部已处理如线程池消费、流控、负载均衡、异常处理等等的各种场景。
+
+- 长轮询，就是我们在 [《 精尽【消息队列 】面试题》](http://svip.iocoder.cn/MQ/Interview) 提到的，push + pull 模式结合的方式。
+
+🦅 **2. PullConsumer**
+
+拉取模式的消费者。应用主动控制拉取的时机，怎么拉取，怎么消费等。主动权更高。但要自己处理各种场景。
+
+------
+
+决绝绝大多数场景下，我们只会使用 PushConsumer 推送模式。😈 至少艿艿目前，暂时还没用过 PullConsumer 。
+
+## 如何对消息进行重放？
+
+消费位点就是一个数字，把 Consumer Offset 改一下，就可以达到重放的目的了。
+
+## 什么是顺序消息？如何实现？
+
+消费消息的顺序要同发送消息的顺序一致。由于 Consumer 消费消息的时候是针对 Message Queue 顺序拉取并开始消费，且一条 Message Queue 只会给一个消费者（集群模式下），所以能够保证同一个消费者实例对于 Queue 上消息的消费是顺序地开始消费（不一定顺序消费完成，因为消费可能并行）。
+
+- Consumer ：在 RocketMQ 中，顺序消费主要指的是都是 Queue 级别的局部顺序。这一类消息为满足顺序性，必须 Producer 单线程顺序发送，且发送到同一个队列，这样 Consumer 就可以按照 Producer 发送的顺序去消费消息。
+- Producer ：生产者发送的时候可以用 MessageQueueSelector 为某一批消息（通常是有相同的唯一标示id）选择同一个 Queue ，则这一批消息的消费将是顺序消息（并由同一个consumer完成消息）。或者 Message Queue 的数量只有 1 ，但这样消费的实例只能有一个，多出来的实例都会空跑。
+
+**当然，上面的文字比较绕，总的来说，RocketMQ 提供了两种顺序级别**：
+
+- 普通顺序消息 ：Producer 将相关联的消息发送到相同的消息队列。
+
+- 严格顺序消息 ：在【普通顺序消息】的基础上，Consumer 严格顺序消费。
+
+  > 也就说，顺序消息包括两块：Producer 的顺序发送，和 Consumer 的顺序消费。
+
+🦅 **1. 普通顺序消息**
+
+顺序消息的一种，正常情况下可以保证完全的顺序消息，但是一旦发生异常，Broker 宕机或重启，由于队列总数发生发化，消费者会触发负载均衡，而默认地负载均衡算法采取哈希取模平均，这样负载均衡分配到定位的队列会发化，使得队列可能分配到别的实例上，则会短暂地出现消息顺序不一致。
+
+如果业务能容忍在集群异常情况（如某个 Broker 宕机或者重启）下，消息短暂的乱序，使用普通顺序方式比较合适。
+
+🦅 **2. 严格顺序消息**
+
+顺序消息的一种，无论正常异常情况都能保证顺序，但是牺牲了分布式 Failover 特性，即 Broker 集群中只要有一台机器不可用，则整个集群都不可用，服务可用性大大降低。
+
+如果服务器部署为同步双写模式，此缺陷可通过备机自动切换为主避免，不过仍然会存在几分钟的服务不可用。（依赖同步双写，主备自动切换，自动切换功能目前并未实现）
+
+🦅 **小结**
+
+目前已知的应用只有数据库 binlog 同步强依赖严格顺序消息，其他应用绝大部分都可以容忍短暂乱序，推荐使用普通的顺序消息。
+
+🦅 **实现原理**
+
+顺序消息的实现，相对比较复杂，想要深入理解的胖友，可以看看 [《RocketMQ 源码分析 —— Message 顺序发送与消费》](http://www.iocoder.cn/RocketMQ/message-send-and-consume-orderly/) 。
+
+具体的代码实现，可以看看 [《芋道 Spring Boot 消息队列 RocketMQ 入门》](http://www.iocoder.cn/Spring-Boot/RocketMQ/?vip)的[「8. 顺序消息」](https://svip.iocoder.cn/RocketMQ/Interview/#) 小节。
+
+## 顺序消息扩容的过程中，如何在不停写的情况下保证消息顺序？
+
+1. 成倍扩容，实现扩容前后，同样的 key，hash 到原队列，或者 hash 到新扩容的队列。
+2. 扩容前，记录旧队列中的最大位点。
+3. 对于每个 Consumer Group ，保证旧队列中的数据消费完，再消费新队列，也即：先对新队列进行禁读即可。
+
+## 什么是定时消息？如何实现？
+
+定时消息，是指消息发到 Broker 后，不能立刻被 Consumer 消费，要到特定的时间点或者等待特定的时间后才能被消费。
+
+目前，开源版本的 RocketMQ 只支持固定延迟级别的延迟消息，不支持任一时刻的延迟消息。如下表格：
+
+| 延迟级别 | 时间 |
+| :------- | :--- |
+| 1        | 1s   |
+| 2        | 5s   |
+| 3        | 10s  |
+| 4        | 30s  |
+| 5        | 1m   |
+| 6        | 2m   |
+| 7        | 3m   |
+| 8        | 4m   |
+| 9        | 5m   |
+| 10       | 6m   |
+| 11       | 7m   |
+| 12       | 8m   |
+| 13       | 9m   |
+| 14       | 10m  |
+| 15       | 20m  |
+| 16       | 30m  |
+| 17       | 1h   |
+| 18       | 2h   |
+
+- 可通过配置文件，自定义每个延迟级别对应的延迟时间。当然，这是全局的。
+- 如果胖友想要实现任一时刻的延迟消息，比较简单的方式是插入延迟消息到数据库中，然后通过定时任务轮询，到达指定时间，发送到 RocketMQ 中。
+
+🦅 **实现原理**
+
+- 1、 定时消息发送到 Broker 后，会被存储 Topic 为 `SCHEDULE_TOPIC_XXXX` 中，并且所在 Queue 编号为延迟级别 - 1 。
+
+  > 需要 -1 的原因是，延迟级别是从 1 开始的。如果延迟级别为 0 ，意味着无需延迟。
+
+- 2、Broker 针对每个 `SCHEDULE_TOPIC_XXXX` 的队列，都创建一个定时任务，**顺序**扫描到达时间的延迟消息，重新存储到延迟消息**原始**的 Topic 的**原始** Queue 中，这样它就可以被 Consumer 消费到。此处会有两个问题：
+
+  - 为什么是“**顺序**扫描到达时间的延迟消息”？因为先进 `SCHEDULE_TOPIC_XXXX` 的延迟消息，在其所在的队列，意味着先到达延迟时间。
+  - 会不会存在重复扫描的情况？每个 `SCHEDULE_TOPIC_XXXX` 的扫描进度，会每 10s 存储到 `config/delayOffset.json` 文件中，所以正常情况下，不会存在重复扫描。如果异常关闭，则可能导致重复扫描。
+
+详细的，胖友可以看看 [《RocketMQ 源码分析 —— 定时消息与消息重试》](http://www.iocoder.cn/RocketMQ/message-schedule-and-retry/) 。
+
+具体的代码实现，可以看看 [《芋道 Spring Boot 消息队列 RocketMQ 入门》](http://www.iocoder.cn/Spring-Boot/RocketMQ/?vip)的[「5. 定时消息」](https://svip.iocoder.cn/RocketMQ/Interview/#) 小节。
+
+## 什么是消息重试？如何实现？
+
+消息重试，Consumer 消费消息失败后，要提供一种重试机制，令消息再消费一次。
+
+- Consumer 会将消费失败的消息发回 Broker，进入延迟消息队列。即，消费失败的消息，不会立即消费。
+- 也就是说，消息重试是构建在定时消息之上的功能。
+
+🦅 **消息重试的主要流程**
+
+1. Consumer 消费失败，将消息发送回 Broker 。
+2. Broker 收到重试消息之后置换 Topic ，存储消息。
+3. Consumer 会拉取该 Topic 对应的 retryTopic 的消息。
+4. Consumer 拉取到 retryTopic 消息之后，置换到原始的 Topic ，把消息交给 Listener 消费。
+
+这里，可能有几个点，胖友会比较懵逼，艿艿简单解释下：
+
+1. Consumer 消息失败后，会将消息的 Topic 修改为 `%RETRY%` + Topic 进行，添加 `"RETRY_TOPIC"` 属性为原始 Topic ，然后再返回给 Broker 中。
+2. Broker 收到重试消息之后，会有两次修改消息的 Topic 。
+   - 首先，会将消息的 Topic 修改为 `%RETRY%` + ConsumerGroup ，因为这个消息是当前消费这分组消费失败，只能被这个消费组所重新消费。😈 注意噢，消费者会默认订阅 Topic 为 `%RETRY%` + ConsumerGroup 的消息。
+   - 然后，会将消息的 Topic 修改为 `SCHEDULE_TOPIC_XXXX` ，添加 `"REAL_TOPIC"` 属性为 `%RETRY%` + ConsumerGroup ，因为重试消息需要延迟消费。
+3. Consumer 会拉取该 Topic 对应的 retryTopic 的消息，此处的 retryTopic 为 `%RETRY%` + ConsumerGroup 。
+4. Consumer 拉取到 retryTopic 消息之后，置换到原始的 Topic ，因为有消息的 `"RETRY_TOPIC"` 属性是原始 Topic ，然后把消息交给 Listener 消费。
+
+😈 有一丢丢复杂，胖友可以在思考思考~详细的，胖友可以看看 [《RocketMQ 源码分析 —— 定时消息与消息重试》](http://www.iocoder.cn/RocketMQ/message-schedule-and-retry/) 。
+
+具体的代码实现，可以看看 [《芋道 Spring Boot 消息队列 RocketMQ 入门》](http://www.iocoder.cn/Spring-Boot/RocketMQ/?vip)的[「6. 消费重试」](https://svip.iocoder.cn/RocketMQ/Interview/#) 小节。
+
+## 多次消费失败后，怎么办？
+
+默认情况下，当一条消息被消费失败 16 次后，会被存储到 Topic 为 `"%DLQ%"` + ConsumerGroup 到死信队列。
+
+为什么 Topic 是 `"%DLQ%"` + ConsumerGroup 呢？因为，是这个 ConsumerGroup 对消息的消费失败，所以 Topic 里要以 ConsumerGroup 为维度。
+
+后续，我们可以通过订阅 `"%DLQ%"` + ConsumerGroup ，做相应的告警。
+
+## 什么是事务消息？如何实现？
+
+关于事务消息的概念和原理，胖友可以看看官方对这块的解答，即 [《RocketMQ 4.3 正式发布，支持分布式事务》](https://www.infoq.cn/article/2018%2F08%2Frocketmq-4.3-release) 的 [「四 事务消息」](https://svip.iocoder.cn/RocketMQ/Interview/#) 小节。
+
+艿艿 16 年的时候，基于 RocketMQ 早期的版本，写了 [《RocketMQ 源码分析 —— 事务消息》](http://www.iocoder.cn/RocketMQ/message-transaction/) 文章，虽然 RocketMQ 版本不太一样，但是大体的思路是差不多的，可以帮助胖友更容易的读懂事务消息相关的源码。
+
+- 简单看了下最新版本的 RocketMQ 的事务代码，新增了
+
+   
+
+  ```
+  RMQ_SYS_TRANS_HALF_TOPIC
+  ```
+
+   
+
+  和
+
+   
+
+  ```
+  RMQ_SYS_TRANS_OP_HALF_TOPIC
+  ```
+
+   
+
+  两个队列。
+
+  - Producer 发送 PREPARED Message 到 Broker 后，先存储到 `RMQ_SYS_TRANS_HALF_TOPIC` 队列中。
+  - Producer 提交或回滚 PREPARED Message 时，会添加一条消息到 `RMQ_SYS_TRANS_OP_HALF_TOPIC` 队列中，标记这个消息已经处理。
+  - Producer 提交 PREPARED Message 时，会将当前消息存储到原 Topic 的队列中，从而该消息能够被 Consumer 拉取消费。
+
+具体的代码实现，可以看看 [《芋道 Spring Boot 消息队列 RocketMQ 入门》](http://www.iocoder.cn/Spring-Boot/RocketMQ/?vip)的[「9. 事务消息」](https://svip.iocoder.cn/RocketMQ/Interview/#) 小节。
+
+## 如何实现 RocketMQ 高可用？
+
+在 [「RocketMQ 由哪些角色组成？」](https://svip.iocoder.cn/RocketMQ/Interview/#) 中，我们看到 RocketMQ 有四个角色，需要考虑每个角色的高可用。
+
+[![RocketMQ 集群](09-RocketMQ 面试题.assets/02.png)](http://static.iocoder.cn/images/RocketMQ/2019_11_12/02.png)RocketMQ 集群
+
+🦅 **1. Producer**
+
+- 1、Producer 自身在应用中，所以无需考虑高可用。
+- 2、Producer 配置多个 Namesrv 列表，从而保证 Producer 和 Namesrv 的连接高可用。并且，会从 Namesrv 定时拉取最新的 Topic 信息。
+- 3、Producer 会和所有 Broker 直连，在发送消息时，会选择一个 Broker 进行发送。如果发送失败，则会使用另外一个 Broker 。
+- 4、Producer 会定时向 Broker 心跳，证明其存活。而 Broker 会定时检测，判断是否有 Producer 异常下线。
+
+🦅 **2. Consumer**
+
+- 1、Consumer 需要部署多个节点，以保证 Consumer 自身的高可用。当相同消费者分组中有新的 Consumer 上线，或者老的 Consumer 下线，会重新分配 Topic 的 Queue 到目前消费分组的 Consumer 们。
+- 2、Consumer 配置多个 Namesrv 列表，从而保证 Consumer 和 Namesrv 的连接高可用。并且，会从 Consumer 定时拉取最新的 Topic 信息。
+- 3、Consumer 会和所有 Broker 直连，消费相应分配到的 Queue 的消息。如果消费失败，则会发回消息到 Broker 中。
+- 4、Consumer 会定时向 Broker 心跳，证明其存活。而 Broker 会定时检测，判断是否有 Consumer 异常下线。
+
+🦅 **3. Namesrv**
+
+- 1、Namesrv 需要部署多个节点，以保证 Namesrv 的高可用。
+- 2、Namesrv 本身是无状态，不产生数据的存储，是通过 Broker 心跳将 Topic 信息同步到 Namesrv 中。
+- 3、多个 Namesrv 之间不会有数据的同步，是通过 Broker 向多个 Namesrv 多写。
+
+🦅 **4. Broker**
+
+- 1、多个 Broker 可以形成一个 Broker 分组。每个 Broker 分组存在一个 Master 和多个 Slave 节点。
+  - Master 节点，可提供读和写功能。Slave 节点，可提供读功能。
+  - Master 节点会不断发送新的 CommitLog 给 Slave节点。Slave 节点不断上报本地的 CommitLog 已经同步到的位置给 Master 节点。
+  - Slave 节点会从 Master 节点拉取消费进度、Topic 配置等等。
+- 2、多个 Broker 分组，形成 Broker 集群。
+  - Broker 集群和集群之间，不存在通信与数据同步。
+- 3、Broker 可以配置同步刷盘或异步刷盘，根据消息的持久化的可靠性来配置。
+
+🦅 **总结**
+
+目前官方提供三套配置：
+
+- **2m-2s-async**
+
+| brokerClusterName | brokerName | brokerRole   | brokerId |
+| :---------------- | :--------- | :----------- | :------- |
+| DefaultCluster    | broker-a   | ASYNC_MASTER | 0        |
+| DefaultCluster    | broker-a   | SLAVE        | 1        |
+| DefaultCluster    | broker-b   | ASYNC_MASTER | 0        |
+| DefaultCluster    | broker-b   | SLAVE        | 1        |
+
+- **2m-2s-sync**
+
+| brokerClusterName | brokerName | brokerRole  | brokerId |
+| :---------------- | :--------- | :---------- | :------- |
+| DefaultCluster    | broker-a   | SYNC_MASTER | 0        |
+| DefaultCluster    | broker-a   | SLAVE       | 1        |
+| DefaultCluster    | broker-b   | SYNC_MASTER | 0        |
+| DefaultCluster    | broker-b   | SLAVE       | 1        |
+
+- **2m-noslave**
+
+| brokerClusterName | brokerName | brokerRole   | brokerId |
+| :---------------- | :--------- | :----------- | :------- |
+| DefaultCluster    | broker-a   | ASYNC_MASTER | 0        |
+| DefaultCluster    | broker-b   | ASYNC_MASTER | 0        |
+
+相关的源码解析，胖友可以看看 [《RocketMQ 源码分析 —— 高可用》](http://www.iocoder.cn/RocketMQ/high-availability/) 。
+
+## RocketMQ 是否会弄丢数据？
+
+> 艿艿：注意，RocketMQ 是否会丢数据，主要取决于我们如何使用。这点，非常重要噢。
+
+🦅 **消费端弄丢了数据？**
+
+对于消费端，如果我们在使用 Push 模式的情况下，只有我们消费返回成功，才会异步定期更新消费进度到 Broker 上。
+
+如果消费端异常崩溃，可能导致消费进度未更新到 Broker 上，那么无非是 Consumer 可能重复拉取到已经消费过的消息。关于这个，就需要消费端做好消费的幂等性。
+
+🦅 **Broker 弄丢了数据？**
+
+在上面的问题中，我们已经看到了 Broker 提供了两个特性：
+
+- 刷盘方式：同步刷盘、异步刷盘。
+- 复制方式：同步复制、异步复制。
+
+如果要保证 Broker 数据最大化的不丢，需要在搭建 Broker 集群时，设置为同步刷盘、同步复制。当然，带来了可靠性，也会一定程度降低性能。
+
+如果想要在可靠性和性能之间做一个平衡，可以选择同步复制，加主从 Broker 都是和异步刷盘。因为，刷盘比较消耗性能。
+
+🦅 **生产者会不会弄丢数据？**
+
+Producer 可以设置三次发送消息重试。
+
+## 如何保证消费者的消费消息的幂等性？
+
+在 [《精尽【消息队列 】面试题》](http://svip.iocoder.cn/MQ/Interview) 中，已经解析过该问题。当然，我们有几点要补充下：
+
+- Producer 在发送消息时，默认会生成消息编号( `msgId` )，可见 `org.apache.rocketmq.common.message.MessageClientExt` 类。
+- Broker 在存储消息时，会生成结合 offset 的消息编号( `offsetMsgId` ) 。
+- Consumer 在消费消息失败后，将该消息发回 Broker 后，会产生新的 `offsetMsgId` 编号，但是 `msgId` 不变。
+
+## 重点补充说明
+
+RocketMQ 涉及的内容很多，能够问的问题也特别多，但是我们不能仅仅为了面试，应该是为了对 RocketMQ 了解更多，使用的更优雅。所以，强烈胖友认真撸下如下三个 PDF ：
+
+- [《RocketMQ 用户指南》](http://gd-rus-public.cn-hangzhou.oss-pub.aliyun-inc.com/attachment/201604/08/20160408164726/RocketMQ_userguide.pdf) 基于 RocketMQ 3 的版本。
+- [《RocketMQ 原理简介》](http://alibaba.github.io/RocketMQ-docs/document/design/RocketMQ_design.pdf) 基于 RocketMQ 3 的版本。
+- [《RocketMQ 最佳实践》](http://gd-rus-public.cn-hangzhou.oss-pub.aliyun-inc.com/attachment/201604/08/20160408164929/RocketMQ_experience.pdf) 基于 RocketMQ 3 的版本。
+
+## 666. 彩蛋
+
+RocketMQ 能够问的东西，真的挺多的，中间也和一些朋友探讨过。如果胖友有什么想要问的，可以在星球给艿艿留言。
+
+参考与推荐如下文章：
+
+- javahongxi [《RocketMQ 架构模块解析》](https://blog.csdn.net/javahongxi/article/details/72956608)
+- 薛定谔的风口猪 [《RocketMQ —— 角色与术语详解》](http://jaskey.github.io/blog/2016/12/15/rocketmq-concept/)
+- 阿里中间件小哥 [《一文讲透 Apache RocketMQ 技术精华》](http://www.10tiao.com/html/683/201811/2650718577/1.html)
\ No newline at end of file
diff --git a/面试题/10-RabbitMQ 面试题.assets/0cb69bbcda6043bc0c9d7733de251d76.png b/面试题/10-RabbitMQ 面试题.assets/0cb69bbcda6043bc0c9d7733de251d76.png
new file mode 100644
index 0000000..3d67769
Binary files /dev/null and b/面试题/10-RabbitMQ 面试题.assets/0cb69bbcda6043bc0c9d7733de251d76.png differ
diff --git a/面试题/10-RabbitMQ 面试题.assets/20a6c4d82a08becf7e8d913662b00357.png b/面试题/10-RabbitMQ 面试题.assets/20a6c4d82a08becf7e8d913662b00357.png
new file mode 100644
index 0000000..3994fa6
Binary files /dev/null and b/面试题/10-RabbitMQ 面试题.assets/20a6c4d82a08becf7e8d913662b00357.png differ
diff --git a/面试题/10-RabbitMQ 面试题.assets/29ea655479f826f9a6a5d9d005f46c7c.png b/面试题/10-RabbitMQ 面试题.assets/29ea655479f826f9a6a5d9d005f46c7c.png
new file mode 100644
index 0000000..f022e2d
Binary files /dev/null and b/面试题/10-RabbitMQ 面试题.assets/29ea655479f826f9a6a5d9d005f46c7c.png differ
diff --git a/面试题/10-RabbitMQ 面试题.assets/6303e69011255831c54d605250a6aa67.png b/面试题/10-RabbitMQ 面试题.assets/6303e69011255831c54d605250a6aa67.png
new file mode 100644
index 0000000..4841731
Binary files /dev/null and b/面试题/10-RabbitMQ 面试题.assets/6303e69011255831c54d605250a6aa67.png differ
diff --git a/面试题/10-RabbitMQ 面试题.assets/75d36ed17c91932e28b5eeba681ad8ec.png b/面试题/10-RabbitMQ 面试题.assets/75d36ed17c91932e28b5eeba681ad8ec.png
new file mode 100644
index 0000000..13d1921
Binary files /dev/null and b/面试题/10-RabbitMQ 面试题.assets/75d36ed17c91932e28b5eeba681ad8ec.png differ
diff --git a/面试题/10-RabbitMQ 面试题.assets/83213e2ac79cd8899b09a66a5cf71669.png b/面试题/10-RabbitMQ 面试题.assets/83213e2ac79cd8899b09a66a5cf71669.png
new file mode 100644
index 0000000..5ebd1af
Binary files /dev/null and b/面试题/10-RabbitMQ 面试题.assets/83213e2ac79cd8899b09a66a5cf71669.png differ
diff --git a/面试题/10-RabbitMQ 面试题.assets/c7566feb7a61cb647296a7224ba7f39d.png b/面试题/10-RabbitMQ 面试题.assets/c7566feb7a61cb647296a7224ba7f39d.png
new file mode 100644
index 0000000..479c706
Binary files /dev/null and b/面试题/10-RabbitMQ 面试题.assets/c7566feb7a61cb647296a7224ba7f39d.png differ
diff --git a/面试题/10-RabbitMQ 面试题.assets/f1bd6c79deaa6fae89a62d0e53f1ad43.png b/面试题/10-RabbitMQ 面试题.assets/f1bd6c79deaa6fae89a62d0e53f1ad43.png
new file mode 100644
index 0000000..1936f45
Binary files /dev/null and b/面试题/10-RabbitMQ 面试题.assets/f1bd6c79deaa6fae89a62d0e53f1ad43.png differ
diff --git a/面试题/10-RabbitMQ 面试题.md b/面试题/10-RabbitMQ 面试题.md
new file mode 100644
index 0000000..1e52ac5
--- /dev/null
+++ b/面试题/10-RabbitMQ 面试题.md	
@@ -0,0 +1,549 @@
+# 精尽 RabbitMQ 面试题「最新更新时间：2024-02」
+
+以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。
+
+如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的 RabbitMQ 面试题的大保健。
+
+而题目的难度，艿艿尽量按照从容易到困难的顺序，逐步下去。
+
+> 艿艿：我们生产主要使用的是 RocketMQ ，所以对 RabbitMQ 灰常不熟悉（😈 看了《RabbitMQ 实战指南》入门级的萌新）。所以本文以整理为主。如果胖友在实际面试场景下，碰到 RabbitMQ 的一些问题，可以返回到星球，艿艿可以去请教厮哒哒，然后来装比。
+
+## RabbitMQ 是什么？
+
+RabbitMQ 是一个由 Erlang 语言开发的 AMQP 的开源实现。
+
+> AMQP ：Advanced Message Queue，高级消息队列协议。它是应用层协议的一个开放标准，为面向消息的中间件设计，基于此协议的客户端与消息中间件可传递消息，并不受产品、开发语言等条件的限制。
+
+RabbitMQ 最初起源于金融系统，用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。具体特点包括：
+
+- 1、可靠性（Reliability）
+
+  > RabbitMQ 使用一些机制来保证可靠性，如持久化、传输确认、发布确认。
+
+- 2、灵活的路由（Flexible Routing）
+
+  > 在消息进入队列之前，通过 Exchange 来路由消息的。对于典型的路由功能，RabbitMQ 已经提供了一些内置的 Exchange 来实现。针对更复杂的路由功能，可以将多个 Exchange 绑定在一起，也通过插件机制实现自己的 Exchange 。
+
+- 3、消息集群（Clustering）
+
+  > 多个 RabbitMQ 服务器可以组成一个集群，形成一个逻辑 Broker 。
+
+- 4、高可用（Highly Available Queues）
+
+  > 队列可以在集群中的机器上进行镜像，使得在部分节点出问题的情况下队列仍然可用。
+
+- 5、多种协议（Multi-protocol）
+
+  > RabbitMQ 支持多种消息队列协议，比如 STOMP、MQTT 等等。
+
+- 6、多语言客户端（Many Clients）
+
+  > RabbitMQ 几乎支持所有常用语言，比如 Java、.NET、Ruby 等等。
+
+- 7、管理界面（Management UI）
+
+  > RabbitMQ 提供了一个易用的用户界面，使得用户可以监控和管理消息 Broker 的许多方面。
+
+- 8、跟踪机制（Tracing）
+
+  > 如果消息异常，RabbitMQ 提供了消息跟踪机制，使用者可以找出发生了什么。
+
+- 9、插件机制（Plugin System）
+
+  > RabbitMQ 提供了许多插件，来从多方面进行扩展，也可以编写自己的插件。
+
+更详细的，推荐阅读 [《消息队列之 RabbitMQ》](http://www.iocoder.cn/RabbitMQ/yuliu/doc/?vip) 。它提供了：
+
+- 1、RabbitMQ 的介绍
+- 2、RabbitMQ 的概念
+- 3、RabbitMQ 的 Server 安装
+- 4、RabbitMQ 的 Java Client 使用示例
+- 5、RabbitMQ 的集群
+
+## RabbitMQ 中的 Broker 是指什么？Cluster 又是指什么？
+
+- Broker ，是指一个或多个 erlang node 的逻辑分组，且 node 上运行着 RabbitMQ 应用程序。
+- Cluster ，是在 Broker 的基础之上，增加了 node 之间共享元数据的约束。
+
+🦅 **vhost 是什么？起什么作用？**
+
+vhost 可以理解为虚拟 Broker ，即 mini-RabbitMQ server 。其内部均含有独立的 queue、exchange 和 binding 等，但最最重要的是，其拥有独立的权限系统，可以做到 vhost 范围的用户控制。当然，从 RabbitMQ 的全局角度，vhost 可以作为不同权限隔离的手段（一个典型的例子就是不同的应用可以跑在不同的 vhost 中）。
+
+> 这个，和 Tomcat、Nginx、Apache 的 vhost 是一样的概念。
+
+## 什么是元数据？元数据分为哪些类型？包括哪些内容？
+
+在非 Cluster 模式下，元数据主要分为：
+
+- Queue 元数据（queue 名字和属性等）
+- Exchange 元数据（exchange 名字、类型和属性等）
+- Binding 元数据（存放路由关系的查找表）
+- Vhost 元数据（vhost 范围内针对前三者的名字空间约束和安全属性设置）。
+
+🦅 **与 Cluster 相关的元数据有哪些？元数据是如何保存的？元数据在 Cluster 中是如何分布的？**
+
+在 Cluster 模式下，还包括 Cluster 中 node 位置信息和 node 关系信息。
+
+元数据根据 erlang node 的类型确定是仅保存于 RAM 中，还是同时保存在 RAM 和 disk 上。元数据在 Cluster 中是全 node 分布的。
+
+下图所示为 queue 的元数据在单 node 和 cluster 两种模式下的分布图：
+
+[![分布图](10-RabbitMQ 面试题.assets/c7566feb7a61cb647296a7224ba7f39d.png)](http://static.iocoder.cn/c7566feb7a61cb647296a7224ba7f39d)分布图
+
+🦅 **RAM node 和 Disk node 的区别？**
+
+- RAM node 仅将 fabric（即 queue、exchange 和 binding等 RabbitMQ基础构件）相关元数据保存到内存中，但 Disk node 会在内存和磁盘中均进行存储。
+- RAM node 上唯一会存储到磁盘上的元数据是 Cluster 中使用的 Disk node 的地址。并且要求在 RabbitMQ Cluster 中至少存在一个 Disk node 。
+
+## RabbitMQ 概念里的 channel、exchange 和 queue 是什么？
+
+- queue 具有自己的 erlang 进程；
+- exchange 内部实现为保存 binding 关系的查找表；
+- channel 是实际进行路由工作的实体，即负责按照 routing_key 将 message 投递给 queue 。
+
+由 AMQP 协议描述可知，channel 是真实 TCP 连接之上的虚拟连接，所有 AMQP 命令都是通过 channel 发送的，且每一个 channel 有唯一的 ID 。
+
+- 一个 channel 只能被单独一个操作系统线程使用，故投递到特定 channel 上的 message 是有顺序的。但一个操作系统线程上允许使用多个 channel 。
+
+- channel 号为 0 的 channel 用于处理所有对于当前 connection 全局有效的帧，而 1-65535 号 channel 用于处理和特定 channel 相关的帧。
+
+- AMQP 协议给出的 channel 复用模型如下：
+
+  ![channel 复用模型](10-RabbitMQ 面试题.assets/0cb69bbcda6043bc0c9d7733de251d76.png)
+
+  channel 复用模型
+
+  - 其中每一个 channel 运行在一个独立的线程上，多线程共享同一个 socket 。
+
+🦅 **消息基于什么传输？**
+
+由于 TCP 连接的创建和销毁开销较大，且并发数受系统资源限制，会造成性能瓶颈。RabbitMQ 使用信道的方式来传输数据。信道是建立在真实的 TCP 连接内的虚拟连接，且每条 TCP连接上的信道数量没有限制。
+
+🦅 **RabbitMQ 上的一个 queue 中存放的 message 是否有数量限制？**
+
+可以认为是无限制，因为限制取决于机器的内存，但是消息过多会导致处理效率的下降。
+
+> 下面的几个问题，Cluster 相关。
+
+🦅 **在单 node 系统和多 node 构成的 cluster 系统中声明 queue、exchange ，以及进行 binding 会有什么不同？**
+
+- 当你在单 node 上声明 queue 时，只要该 node 上相关元数据进行了变更，你就会得到 `Queue.Declare-ok` 回应；而在 cluster 上声明 queue ，则要求 cluster 上的全部 node 都要进行元数据成功更新，才会得到 `Queue.Declare-ok` 回应。
+- 另外，若 node 类型为 RAM node 则变更的数据仅保存在内存中，若类型为 Disk node 则还要变更保存在磁盘上的数据。
+
+🦅 **客户端连接到 Cluster 中的任意 node 上是否都能正常工作？**
+
+是的。客户端感觉不到有何不同。
+
+🦅 **若 Cluster 中拥有某个 queue 的 owner node 失效了，且该 queue 被声明具有 durable 属性，是否能够成功从其他 node 上重新声明该 queue ？**
+
+- 不能，在这种情况下，将得到 404 NOT_FOUND 错误。只能等 queue 所属的 node 恢复后才能使用该 queue 。
+- 但若该 queue 本身不具有 durable 属性，则可在其他 node 上重新声明。
+
+🦅 **Cluster 中 node 的失效会对 consumer 产生什么影响？若是在 cluster 中创建了 mirrored queue ，这时 node 失效会对 consumer 产生什么影响？**
+
+- 若是 consumer 所连接的那个 node 失效（无论该 node 是否为 consumer 所订阅 queue 的 owner node），则 consumer 会在发现 TCP 连接断开时，按标准行为执行重连逻辑，并根据 “Assume Nothing” 原则重建相应的 fabric 即可。
+- 若是失效的 node 为 consumer 订阅 queue 的 owner node，则 consumer 只能通过 Consumer Cancellation Notification 机制来检测与该 queue 订阅关系的终止，否则会出现傻等却没有任何消息来到的问题。
+
+🦅 **Consumer Cancellation Notification 机制用于什么场景？**
+
+用于保证当镜像 queue 中 master 挂掉时，连接到 slave 上的 consumer 可以收到自身 consume 被取消的通知，进而可以重新执行 consume 动作从新选出的 master 出获得消息。
+
+若不采用该机制，连接到 slave 上的 consumer 将不会感知 master 挂掉这个事情，导致后续无法再收到新 master 广播出来的 message 。
+
+另外，因为在镜像 queue 模式下，存在将 message 进行 requeue 的可能，所以实现 consumer 的逻辑时需要能够正确处理出现重复 message 的情况。
+
+🦅 **能够在地理上分开的不同数据中心使用 RabbitMQ cluster 么？**
+
+不能。
+
+- 第一，你无法控制所创建的 queue 实际分布在 cluster 里的哪个 node 上（一般使用 HAProxy + cluster 模型时都是这样），这可能会导致各种跨地域访问时的常见问题。
+- 第二，Erlang 的 OTP 通信框架对延迟的容忍度有限，这可能会触发各种超时，导致业务疲于处理。
+- 第三，在广域网上的连接失效问题将导致经典的“脑裂”问题，而 RabbitMQ 目前无法处理。（该问题主要是说 Mnesia）
+
+## 如何确保消息正确地发送至 RabbitMQ？
+
+RabbitMQ 使用**发送方确认模式**，确保消息正确地发送到 RabbitMQ。
+
+- 发送方确认模式：将信道设置成 confirm 模式（发送方确认模式），则所有在信道上发布的消息都会被指派一个唯一的 ID 。一旦消息被投递到目的队列后，或者消息被写入磁盘后（可持久化的消息），信道会发送一个确认给生产者（包含消息唯一ID）。如果 RabbitMQ 发生内部错误从而导致消息丢失，会发送一条 nack（not acknowledged，未确认）消息。
+- 发送方确认模式是异步的，生产者应用程序在等待确认的同时，可以继续发送消息。当确认消息到达生产者应用程序，生产者应用程序的回调方法就会被触发来处理确认消息。
+
+具体的代码实现，可以看看 [《芋道 Spring Boot 消息队列 RabbitMQ 入门》](http://www.iocoder.cn/Spring-Boot/RabbitMQ/?vip)的[「14. 生产者的发送确认」](https://svip.iocoder.cn/RabbitMQ/Interview/#) 小节
+
+🦅 **向不存在的 exchange 发 publish 消息会发生什么？向不存在的 queue 执行 consume 动作会发生什么？**
+
+都会收到 `Channel.Close` 信令告之不存在（内含原因 404 NOT_FOUND）。
+
+🦅 **什么情况下会出现 blackholed 问题？**
+
+> blackholed ，对应中文为“黑洞”。
+
+blackholed 问题是指，向 exchange 投递了 message ，而由于各种原因导致该 message 丢失，但发送者却不知道。可导致 blackholed 的情况：
+
+- 1、向未绑定 queue 的 exchange 发送 message 。
+- 2、exchange 以 binding_key key_A 绑定了 queue queue_A，但向该 exchange 发送 message 使用的 routing_key 却是 key_B 。
+
+🦅 **如何防止出现 blackholed 问题？**
+
+没有特别好的办法，只能在具体实践中通过各种方式保证相关 fabric 的存在。另外，如果在执行 `Basic.Publish` 时设置 `mandatory=true` ，则在遇到可能出现 blackholed 情况时，服务器会通过返回 `Basic.Return` 告之当前 message 无法被正确投递（内含原因 312 NO_ROUTE）。
+
+具体的代码实现，可以看看 [《芋道 Spring Boot 消息队列 RabbitMQ 入门》](http://www.iocoder.cn/Spring-Boot/RabbitMQ/?vip)的[「14.3 ReturnCallback」](https://svip.iocoder.cn/RabbitMQ/Interview/#) 小节
+
+🦅 **routing_key 和 binding_key 的最大长度是多少？**
+
+255 字节。
+
+🦅 **消息怎么路由？**
+
+从概念上来说，消息路由必须有三部分：交换器、路由、绑定。
+
+- 生产者把消息发布到**交换器**上；
+
+- **绑定**决定了消息如何从路由器路由到特定的队列；
+
+  > 如果一个路由绑定了两个队列，那么发送给该路由时，这两个队列都会增加一条消息。
+
+- 消息最终到达**队列**，并被消费者接收。
+
+详细来说，就是：
+
+- 消息发布到交换器时，消息将拥有一个路由键（routing key），在消息创建时设定。
+- 通过队列路由键，可以把队列绑定到交换器上。
+- 消息到达交换器后，RabbitMQ 会将消息的路由键与队列的路由键进行匹配（针对不同的交换器有不同的路由规则）。如果能够匹配到队列，则消息会投递到相应队列中；如果不能匹配到任何队列，消息将进入 “黑洞”。
+
+常用的交换器主要分为一下三种：
+
+- direct：如果路由键完全匹配，消息就被投递到相应的队列。
+- fanout：如果交换器收到消息，将会广播到所有绑定的队列上。
+- topic：可以使来自不同源头的消息能够到达同一个队列。 使用 topic 交换器时，可以使用通配符，比如：`“*”` 匹配特定位置的任意文本， `“.”` 把路由键分为了几部分，`“#”` 匹配所有规则等。特别注意：发往 topic 交换器的消息不能随意的设置选择键（routing_key），必须是由 `"."` 隔开的一系列的标识符组成。
+
+具体的代码实现，可以看看 [《芋道 Spring Boot 消息队列 RabbitMQ 入门》](http://www.iocoder.cn/Spring-Boot/RabbitMQ/?vip)的[「3. 快速入门」](https://svip.iocoder.cn/RabbitMQ/Interview/#) 小节
+
+## 如何确保消息接收方消费了消息？
+
+RabbitMQ 使用**接收方消息确认机制**，确保消息接收方消费了消息。
+
+- 接收方消息确认机制：消费者接收每一条消息后都必须进行确认（消息接收和消息确认是两个不同操作）。只有消费者确认了消息，RabbitMQ 才能安全地把消息从队列中删除。
+
+这里并没有用到超时机制，RabbitMQ 仅通过 Consumer 的连接中断来确认是否需要重新发送消息。也就是说，只要连接不中断，RabbitMQ 给了 Consumer 足够长的时间来处理消息。
+
+下面罗列几种特殊情况：
+
+- 如果消费者接收到消息，在确认之前断开了连接或取消订阅，RabbitMQ 会认为消息没有被分发，然后重新分发给下一个订阅的消费者。（可能存在消息重复消费的隐患，需要根据 bizId 去重）
+- 如果消费者接收到消息却没有确认消息，连接也未断开，则 RabbitMQ 认为该消费者繁忙，将不会给该消费者分发更多的消息。
+
+具体的代码实现，可以看看 [《芋道 Spring Boot 消息队列 RabbitMQ 入门》](http://www.iocoder.cn/Spring-Boot/RabbitMQ/?vip)的[「13. 消费者的消息确认」](https://svip.iocoder.cn/RabbitMQ/Interview/#) 小节。
+
+🦅 **如何避免消息重复投递或重复消费？**
+
+在消息生产时，MQ 内部针对每条生产者发送的消息生成一个 inner-msg-id ，作为去重和幂等的依据（消息投递失败并重传），避免重复的消息进入队列
+
+在消息消费时，要求消息体中必须要有一个 bizId（对于同一业务全局唯一，如支付 ID、订单 ID、帖子 ID 等）作为去重和幂等的依据，避免同一条消息被重复消费。
+
+🦅 **消息如何分发？**
+
+若该队列至少有一个消费者订阅，消息将以循环（round-robin）的方式发送给消费者。每条消息只会分发给一个订阅的消费者（前提是消费者能够正常处理消息并进行确认）。
+
+🦅 **RabbitMQ 有几种消费模式？**
+
+RabbitMQ 有 pull 和 push 两种消费模式。具体的使用，可参见 [《RabbitMQ 之 Consumer 消费模式（Push & Pull）》](https://blog.csdn.net/u013256816/article/details/62890189) 文章。
+
+## 为什么不应该对所有的 message 都使用持久化机制？
+
+首先，必然导致性能的下降，因为写磁盘比写 RAM 慢的多，message 的吞吐量可能有 10 倍的差距。
+
+其次，message 的持久化机制用在 RabbitMQ 的内置 Cluster 方案时会出现“坑爹”问题。矛盾点在于：
+
+- 若 message 设置了 persistent 属性，但 queue 未设置 durable 属性，那么当该 queue 的 owner node 出现异常后，在未重建该 queue 前，发往该 queue 的 message 将被 blackholed 。
+- 若 message 设置了 persistent 属性，同时 queue 也设置了 durable 属性，那么当 queue 的 owner node 异常且无法重启的情况下，则该 queue 无法在其他 node 上重建，只能等待其 owner node 重启后，才能恢复该 queue 的使用，而在这段时间内发送给该 queue 的 message 将被 blackholed 。
+
+所以，是否要对 message 进行持久化，需要综合考虑性能需要，以及可能遇到的问题。若想达到 100,000 条/秒以上的消息吞吐量（单 RabbitMQ 服务器），则要么使用其他的方式来确保 message 的可靠 delivery ，要么使用非常快速的存储系统以支持全持久化（例如使用 SSD）。另外一种处理原则是：仅对关键消息作持久化处理（根据业务重要程度），且应该保证关键消息的量不会导致性能瓶颈。
+
+🦅 **RabbitMQ 允许发送的 message 最大可达多大？**
+
+根据 AMQP 协议规定，消息体的大小由 64-bit 的值来指定，所以你就可以知道到底能发多大的数据了。
+
+🦅 **为什么说保证 message 被可靠持久化的条件是 queue 和 exchange 具有 durable 属性，同时 message 具有 persistent 属性才行？**
+
+binding 关系可以表示为 exchange–binding–queue 。从文档中我们知道，若要求投递的 message 能够不丢失，要求 message 本身设置 persistent 属性，同时要求 exchange 和 queue 都设置 durable 属性。
+
+- 其实这问题可以这么想，若 exchange 或 queue 未设置 durable 属性，则在其 crash 之后就会无法恢复，那么即使 message 设置了 persistent 属性，仍然存在 message 虽然能恢复但却无处容身的问题。
+- 同理，若 message 本身未设置 persistent 属性，则 message 的持久化更无从谈起。
+
+🦅 **如何确保消息不丢失？**
+
+消息持久化的前提是：将交换器/队列的 durable 属性设置为 true ，表示交换器/队列是持久交换器/队列，在服务器崩溃或重启之后不需要重新创建交换器/队列（交换器/队列会自动创建）。
+
+如果消息想要从 RabbitMQ 崩溃中恢复，那么消息必须：
+
+- 在消息发布前，通过把它的 “投递模式” 选项设置为2（持久）来把消息标记成持久化
+- 将消息发送到持久交换器
+- 消息到达持久队列
+
+RabbitMQ 确保持久性消息能从服务器重启中恢复的方式是，将它们写入磁盘上的一个持久化日志文件。
+
+- 当发布一条持久性消息到持久交换器上时，RabbitMQ 会在消息提交到日志文件后才发送响应（如果消息路由到了非持久队列，它会自动从持久化日志中移除）。
+- 一旦消费者从持久队列中消费了一条持久化消息，RabbitMQ 会在持久化日志中把这条消息标记为等待垃圾收集。如果持久化消息在被消费之前 RabbitMQ 重启，那么 RabbitMQ 会自动重建交换器和队列（以及绑定），并重播持久化日志文件中的消息到合适的队列或者交换器上。
+
+## 什么是死信队列？
+
+DLX，Dead-Letter-Exchange。利用 DLX ，当消息在一个队列中变成死信（dead message）之后，它能被重新 publish 到另一个 Exchange ，这个 Exchange 就是DLX。消息变成死信一向有一下几种情况：
+
+- 消息被拒绝（basic.reject / basic.nack）并且 `requeue=false` 。
+- 消息 TTL 过期（参考：RabbitMQ之TTL（Time-To-Live 过期时间））。
+- 队列达到最大长度。
+
+详细的，可以看看 [《RabbitMQ 之死信队列》](http://www.iocoder.cn/RabbitMQ/dead-letter-queue/?vip) 文章。
+
+🦅 **“dead letter”queue 的用途？**
+
+当消息被 RabbitMQ server 投递到 consumer 后，但 consumer 却通过 `Basic.Reject` 进行了拒绝时（同时设置 `requeue=false`），那么该消息会被放入 “dead letter” queue 中。该 queue 可用于排查 message 被 reject 或 undeliver 的原因。
+
+🦅 **`Basic.Reject` 的用法是什么？**
+
+该信令可用于 consumer 对收到的 message 进行 reject 。
+
+- 若在该信令中设置 `requeue=true` ，则当 RabbitMQ server 收到该拒绝信令后，会将该 message 重新发送到下一个处于 consume 状态的 consumer 处（理论上仍可能将该消息发送给当前 consumer）。
+- 若设置 `requeue=false` ，则 RabbitMQ server 在收到拒绝信令后，将直接将该 message 从 queue 中移除。
+
+另外一种移除 queue 中 message 的小技巧是，consumer 回复 `Basic.Ack` 但不对获取到的 message 做任何处理。而 `Basic.Nack`是对 Basic.Reject 的扩展，以支持一次拒绝多条 message 的能力。
+
+## RabbitMQ 中的 cluster、mirrored queue，以及 warrens 机制分别用于解决什么问题？
+
+🦅 **1）cluster**
+
+- cluster 是为了解决当 cluster 中的任意 node 失效后，producer 和 consumer 均可以通过其他 node 继续工作，即提高了可用性；另外可以通过增加 node 数量增加 cluster 的消息吞吐量的目的。
+- cluster 本身不负责 message 的可靠性问题（该问题由 producer 通过各种机制自行解决）；cluster 无法解决跨数据中心的问题（即脑裂问题）。
+- 另外，在cluster 前使用 HAProxy 可以解决 node 的选择问题，即业务无需知道 cluster 中多个 node 的 ip 地址。可以利用 HAProxy 进行失效 node 的探测，可以作负载均衡。下图为 HAProxy + cluster 的模型：[HAProxy + cluster 的模型](https://img-blog.csdnimg.cn/20181219191433895)
+
+🦅 **2）Mirrored queue**
+
+- Mirrored queue 是为了解决使用 cluster 时所创建的 queue 的完整信息仅存在于单一 node 上的问题，从另一个角度增加可用性。
+- 若想正确使用该功能，需要保证：1）consumer 需要支持 Consumer Cancellation Notification 机制；2）consumer 必须能够正确处理重复 message 。
+
+🦅 **3）Warrens**
+
+Warrens 是为了解决 cluster 中 message 可能被 blackholed 的问题，即不能接受 producer 不停 republish message 但 RabbitMQ server 无回应的情况。
+
+Warrens 有两种构成方式：
+
+- 一种模型，是两台独立的 RabbitMQ server + HAProxy ，其中两个 server 的状态分别为 active 和 hot-standby 。该模型的特点为：两台 server 之间无任何数据共享和协议交互，两台 server 可以基于不同的 RabbitMQ 版本。如下图所示：[模型一](https://img-blog.csdnimg.cn/20181219191433914)
+- 另一种模型，为两台共享存储的 RabbitMQ server + keepalived ，其中两个 server 的状态分别为 active 和 cold-standby 。该模型的特点为：两台 server 基于共享存储可以做到完全恢复，要求必须基于完全相同的 RabbitMQ 版本。如下图所示：[模型二](https://img-blog.csdnimg.cn/20181219191433931)
+
+Warrens 模型存在的问题：
+
+- 对于第一种模型，虽然理论上讲不会丢失消息，但若在该模型上使用持久化机制，就会出现这样一种情况，即若作为 active 的 server 异常后，持久化在该 server 上的消息将暂时无法被 consume ，因为此时该 queue 将无法在作为 hot-standby 的 server 上被重建，所以，只能等到异常的 active server 恢复后，才能从其上的 queue 中获取相应的 message 进行处理。而对于业务来说，需要具有：a.感知 AMQP 连接断开后重建各种 fabric 的能力；b.感知 active server 恢复的能力；c.切换回 active server 的时机控制，以及切回后，针对 message 先后顺序产生的变化进行处理的能力。
+- 对于第二种模型，因为是基于共享存储的模式，所以导致 active server 异常的条件，可能同样会导致 cold-standby server 异常；另外，在该模型下，要求 active 和 cold-standby 的 server 必须具有相同的 node 名和 UID ，否则将产生访问权限问题；最后，由于该模型是冷备方案，故无法保证 cold-standby server 能在你要求的时限内成功启动。
+
+## RabbitMQ 如何实现高可用？
+
+> 这个问题，和 [「RabbitMQ 中的 cluster、mirrored queue，以及 warrens 机制分别用于解决什么问题？」](https://svip.iocoder.cn/RabbitMQ/Interview/#) 会比较类似。
+
+RabbitMQ 的高可用，是基于**主从**做高可用性的。它有三种模式：
+
+- 单机模式
+- 普通集群模式
+- 镜像集群模式
+
+🦅 **1）单机模式**
+
+单机模式，就是启动单个 RabbitMQ 节点，一般用于本地开发或者测试环境。实际生产环境下，基本不会使用。
+
+🦅 **普通集群模式（无高可用性）**
+
+> 这种方式，就是上面问题的 **cluster** 。
+
+普通集群模式，意思就是在多台机器上启动多个 RabbitMQ 实例，每个机器启动一个。
+
+- 你**创建的 queue，只会放在一个 RabbitMQ 实例上**，但是每个实例都同步 queue 的元数据（元数据可以认为是 queue 的一些配置信息，通过元数据，可以找到 queue 所在实例）。
+- 你消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从 queue 所在实例上拉取数据过来。
+
+[![架构图](10-RabbitMQ 面试题.assets/75d36ed17c91932e28b5eeba681ad8ec.png)](http://static.iocoder.cn/75d36ed17c91932e28b5eeba681ad8ec)架构图
+
+这种方式确实很麻烦，也不怎么好，**没做到所谓的分布式**，就是个普通集群。因为这导致你要么消费者每次随机连接一个实例然后拉取数据，要么固定连接那个 queue 所在实例消费数据，前者有**数据拉取的开销**，后者导致**单实例性能瓶颈**。
+
+而且如果那个放 queue 的实例宕机了，会导致接下来其他实例就无法从那个实例拉取，如果你**开启了消息持久化**，让 RabbitMQ 落地存储消息的话，**消息不一定会丢**，得等这个实例恢复了，然后才可以继续从这个 queue 拉取数据。
+
+所以这个事儿就比较尴尬了，这就**没有什么所谓的高可用性**，**这方案主要是提高吞吐量的**，就是说让集群中多个节点来服务某个 queue 的读写操作。
+
+🦅 **镜像集群模式（高可用性）**
+
+> 艿艿：请教了下胖友，他们采用这种方式。
+>
+> 这种方式，就是上面问题的 **Mirrored queue** 。
+
+这种模式，才是所谓的 RabbitMQ 的高可用模式。跟普通集群模式不一样的是，在镜像集群模式下，你创建的 queue，无论元数据还是 queue 里的消息都会**存在于多个实例上**，就是说，每个 RabbitMQ 节点都有这个 queue 的一个**完整镜像**，包含 queue 的全部数据的意思。然后每次你写消息到 queue 的时候，都会自动把**消息同步**到多个实例的 queue 上。
+
+[![架构图](10-RabbitMQ 面试题.assets/20a6c4d82a08becf7e8d913662b00357.png)](http://static.iocoder.cn/20a6c4d82a08becf7e8d913662b00357)架构图
+
+那么**如何开启这个镜像集群模式**呢？其实很简单，RabbitMQ 有很好的管理控制台，就是在后台新增一个策略，这个策略是**镜像集群模式的策略**，指定的时候是可以要求数据同步到所有节点的，也可以要求同步到指定数量的节点，再次创建 queue 的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。
+
+这样的话，好处在于，你任何一个机器宕机了，没事儿，其它机器（节点）还包含了这个 queue 的完整数据，别的 consumer 都可以到其它节点上去消费数据。坏处在于，第一，这个性能开销也太大了吧，消息需要同步到所有机器上，导致网络带宽压力和消耗很重！第二，这么玩儿，不是分布式的，就**没有扩展性可言**了，如果某个 queue 负载很重，你加机器，新增的机器也包含了这个 queue 的所有数据，并**没有办法线性扩展**你的 queue。你想，如果这个 queue 的数据量很大，大到这个机器上的容量无法容纳了，此时该怎么办呢？
+
+## 如何使用 RabbitMQ 实现 RPC
+
+基于 [RabbitMQ reply_to](https://www.rabbitmq.com/direct-reply-to.html) 特性，可以很轻易使用 RabbitMQ 实现 RPC 功能。
+
+具体的代码实现，可以看看 [《芋道 Spring Boot 消息队列 RabbitMQ 入门》](http://www.iocoder.cn/Spring-Boot/RabbitMQ/?vip)的[「15. RPC 远程调用」](https://svip.iocoder.cn/RabbitMQ/Interview/#) 小节。
+
+🦅 **使用 RabbitMQ 实现 RPC 有什么好处？**
+
+- 1、将客户端和服务器解耦：客户端只是发布一个请求到 MQ 并消费这个请求的响应。并不关心具体由谁来处理这个请求，MQ 另一端的请求的消费者可以随意替换成任何可以处理请求的服务器，并不影响到客户端。
+
+  > 相当于 RPC 的注册发现功能，交给 RabbitMQ 来实现了。
+
+- 2、减轻服务器的压力：传统的 RPC 模式中如果客户端和请求过多，服务器的压力会过大。由 MQ 作为中间件的话，过多的请求而是被 MQ 消化掉，服务器可以控制消费请求的频次，并不会影响到服务器。
+
+- 3、服务器的横向扩展更加容易：如果服务器的处理能力不能满足请求的频次，只需要增加服务器来消费 MQ 的消息即可，MQ会帮我们实现消息消费的负载均衡。
+
+- 4、可以看出 RabbitMQ 对于 RPC 模式的支持也是比较友好地，
+
+  ```
+  amq.rabbitmq.reply-to
+  ```
+
+  ,
+
+   
+
+  ```
+  reply_to
+  ```
+
+  ,
+
+   
+
+  ```
+  correlation_id
+  ```
+
+   
+
+  这些特性都说明了这一点，再加上
+
+   
+
+  spring-rabbit
+
+   
+
+  的实现，可以让我们很简单的使用消息队列模式的 RPC 调用。
+
+  > 例如说：[`rabbitmq-jsonrpc`](https://github.com/rabbitmq/rabbitmq-jsonrpc) 的实现。
+
+当然，虽然有这些优点，实际场景下，我们并不会这么做。😈
+
+🦅 **为什么 heavy RPC 的使用场景下不建议采用 disk node ？**
+
+heavy RPC 是指在业务逻辑中高频调用 RabbitMQ 提供的 RPC 机制，导致不断创建、销毁 reply queue ，进而造成 disk node 的性能问题（因为会针对元数据不断写盘）。所以在使用 RPC 机制时需要考虑自身的业务场景，一般来说不建议。
+
+## RabbitMQ 是否会弄丢数据？
+
+> 艿艿：这个问题，基本是我们前面看到的几个问题的总结合并。
+
+[![弄丢消息的几种情况](10-RabbitMQ 面试题.assets/6303e69011255831c54d605250a6aa67.png)](http://static.iocoder.cn/6303e69011255831c54d605250a6aa67)弄丢消息的几种情况
+
+🦅 **生产者弄丢了数据？**
+
+生产者将数据发送到 RabbitMQ 的时候，可能数据就在半路给搞丢了，因为网络问题啥的，都有可能。
+
+> 方案一：事务功能
+
+🚀 此时可以选择用 RabbitMQ 提供的【事务功能】，就是生产者**发送数据之前**开启 RabbitMQ 事务`channel.txSelect`，然后发送消息，如果消息没有成功被 RabbitMQ 接收到，那么生产者会收到异常报错，此时就可以回滚事务`channel.txRollback`，然后重试发送消息；如果收到了消息，那么可以提交事务`channel.txCommit`。代码如下：
+
+```
+// 开启事务
+channel.txSelect
+try {
+    // 这里发送消息
+} catch (Exception e) {
+    channel.txRollback
+
+    // 这里再次重发这条消息
+}
+
+// 提交事务
+channel.txCommit
+```
+
+- 但是问题是，RabbitMQ 事务机制（同步）一搞，基本上**吞吐量会下来，因为太耗性能**。
+
+具体的代码实现，可以看看 [《芋道 Spring Boot 消息队列 RabbitMQ 入门》](http://www.iocoder.cn/Spring-Boot/RabbitMQ/?vip)的[「12. 事务消息」](https://svip.iocoder.cn/RabbitMQ/Interview/#) 小节。
+
+> 方案二：confirm 功能。
+
+🚀 所以一般来说，如果你要确保说写 RabbitMQ 的消息别丢，可以开启 【`confirm` 模式】，在生产者那里设置开启 `confirm` 模式之后，你每次写的消息都会分配一个唯一的 id，然后如果写入了 RabbitMQ 中，RabbitMQ 会给你回传一个 `ack` 消息，告诉你说这个消息 ok 了。如果 RabbitMQ 没能处理这个消息，会回调你的一个 `nack` 接口，告诉你这个消息接收失败，你可以重试。而且你可以结合这个机制自己在内存里维护每个消息 id 的状态，如果超过一定时间还没接收到这个消息的回调，那么你可以重发。
+
+具体的代码实现，可以看看 [《芋道 Spring Boot 消息队列 RabbitMQ 入门》](http://www.iocoder.cn/Spring-Boot/RabbitMQ/?vip)的[「14. 生产者的发送确认」](https://svip.iocoder.cn/RabbitMQ/Interview/#) 小节。
+
+> 对比总结
+
+🚀 事务机制和 `confirm` 机制最大的不同在于，**事务机制是同步的**，你提交一个事务之后会**阻塞**在那儿，但是 `confirm` 机制是**异步**的，你发送个消息之后就可以发送下一个消息，然后那个消息 RabbitMQ 接收了之后会异步回调你的一个接口通知你这个消息接收到了。
+
+所以一般在生产者这块**避免数据丢失**，都是用 `confirm` 机制的。
+
+> 😈 不过 confirm 功能，也可能存在丢消息的情况。举个例子，如果回调到 `nack` 接口，此时 JVM 挂掉了，那么此消息就丢失了。（这个是艿艿的猜想，还在找胖友探讨中。关于这块，欢迎星球讨论。）
+
+🦅 **Broker 弄丢了数据**
+
+就是 Broker 自己弄丢了数据，这个你必须**开启 Broker 的持久化**，就是消息写入之后会持久化到磁盘，哪怕是 Broker 自己挂了，**恢复之后会自动读取之前存储的数据**，一般数据不会丢。除非极其罕见的是，Broker 还没持久化，自己就挂了，**可能导致少量数据丢失**，但是这个概率较小。
+
+设置持久化有**两个步骤**：
+
+- 创建 queue 的时候将其设置为持久化
+  这样就可以保证 RabbitMQ 持久化 queue 的元数据，但是它是不会持久化 queue 里的数据的。
+- 第二个是发送消息的时候将消息的 `deliveryMode` 设置为 2
+  就是将消息设置为持久化的，此时 RabbitMQ 就会将消息持久化到磁盘上去。
+
+必须要同时设置这两个持久化才行，Broker 哪怕是挂了，再次重启，也会从磁盘上重启恢复 queue，恢复这个 queue 里的数据。
+
+注意，哪怕是你给 Broker 开启了持久化机制，也有一种可能，就是这个消息写到了 Broker 中，但是还没来得及持久化到磁盘上，结果不巧，此时 Broker 挂了，就会导致内存里的一点点数据丢失。
+
+所以，持久化可以跟生产者那边的 `confirm` 机制配合起来，只有消息被持久化到磁盘之后，才会通知生产者 `ack` 了，所以哪怕是在持久化到磁盘之前，Broker 挂了，数据丢了，生产者收不到 `ack`，你也是可以自己重发的。
+
+🦅 **消费端弄丢了数据？**
+
+RabbitMQ 如果丢失了数据，主要是因为你消费的时候，**刚消费到，还没处理，结果进程挂了**，比如重启了，那么就尴尬了，RabbitMQ 认为你都消费了，这数据就丢了。
+
+这个时候得用 RabbitMQ 提供的 `ack` 机制，简单来说，就是你必须关闭 RabbitMQ 的自动 `ack`，可以通过一个 api 来调用就行，然后每次你自己代码里确保处理完的时候，再在程序里 `ack` 一把。这样的话，如果你还没处理完，不就没有 `ack` 了？那 RabbitMQ 就认为你还没处理完，这个时候 RabbitMQ 会把这个消费分配给别的 consumer 去处理，消息是不会丢的。
+
+🦅 **总结**
+
+[![总结](10-RabbitMQ 面试题.assets/83213e2ac79cd8899b09a66a5cf71669.png)](http://static.iocoder.cn/83213e2ac79cd8899b09a66a5cf71669)总结
+
+## RabbitMQ 如何保证消息的顺序性？
+
+和 Kafka 与 RocketMQ 不同，Kafka 不存在类似类似 Topic 的概念，而是真正的一条一条队列，并且每个队列可以被多个 Consumer 拉取消息。这个，是非常大的一个差异。
+
+🚀 **来看看 RabbitMQ 顺序错乱的场景**：
+
+一个 queue，多个 consumer。比如，生产者向 RabbitMQ 里发送了三条数据，顺序依次是 data1/data2/data3，压入的是 RabbitMQ 的一个内存队列。有三个消费者分别从 MQ 中消费这三条数据中的一条，结果消费者 2 先执行完操作，把 data2 存入数据库，然后是 data1/data3。这不明显乱了。😈 也就是说，乱序消费的问题。
+
+[![乱序](10-RabbitMQ 面试题.assets/29ea655479f826f9a6a5d9d005f46c7c.png)](http://static.iocoder.cn/29ea655479f826f9a6a5d9d005f46c7c)乱序
+
+🚀 **解决方案**：
+
+- 方案一，拆分多个 queue，每个 queue 一个 consumer，就是多一些 queue 而已，确实是麻烦点。
+
+  > 这个方式，有点模仿 Kafka 和 RocketMQ 中 Topic 的概念。例如说，原先一个 queue 叫 `"xxx"` ，那么多个 queue ，我们可以叫 `"xxx-01"`、`"xxx-02"` 等，相同前缀，不同后缀。
+
+- 方案二，或者就一个 queue 但是对应一个 consumer，然后这个 consumer 内部用内存队列做排队，然后分发给底层不同的 worker 来处理。
+
+  > 这种方式，就是讲一个 queue 里的，相同的“key” 交给同一个 worker 来执行。因为 RabbitMQ 是可以单条消息来 ack ，所以还是比较方便的。这一点，也是和 RocketMQ 和 Kafka 不同的地方。
+
+[![解决乱序](10-RabbitMQ 面试题.assets/f1bd6c79deaa6fae89a62d0e53f1ad43.png)](http://static.iocoder.cn/f1bd6c79deaa6fae89a62d0e53f1ad43)解决乱序
+
+实际上，我们会发现上述的两个方案，前提都是一个 queue 只能启动一个 consumer 对应。
+
+具体的代码实现，可以看看 [《芋道 Spring Boot 消息队列 RabbitMQ 入门》](http://www.iocoder.cn/Spring-Boot/RabbitMQ/?vip)的[「11. 顺序消息」](https://svip.iocoder.cn/RabbitMQ/Interview/#) 小节
+
+# 666. 彩蛋
+
+写的很糟糕，一度想删除。后来想想，先就酱紫，可能这就是此时自己对 RabbitMQ 掌握的情况。后面等自己业务场景真的开始使用 RabbitMQ 之后，在好好倒腾倒腾。Sad But Tree 。
+
+参考与推荐如下文章：
+
+- [《RabbitMQ 面试专题》](https://blog.csdn.net/qq_30764991/article/details/80573352)
+- [《如何保证消息队列的高可用？》](https://github.com/doocs/advanced-java/blob/master/docs/high-concurrency/how-to-ensure-high-availability-of-message-queues.md)
+- [《RabbitMQ 面试要点》](https://chaser520.iteye.com/blog/2428253)
+- [《如何保证消息的可靠性传输？（如何处理消息丢失的问题）》](https://github.com/doocs/advanced-java/blob/master/docs/high-concurrency/how-to-ensure-the-reliable-transmission-of-messages.md)
\ No newline at end of file
diff --git a/面试题/11-Kafka 面试题.assets/00e8ec59cf40c62db53b4d66dc45e17c.jpeg b/面试题/11-Kafka 面试题.assets/00e8ec59cf40c62db53b4d66dc45e17c.jpeg
new file mode 100644
index 0000000..ebd8c4e
Binary files /dev/null and b/面试题/11-Kafka 面试题.assets/00e8ec59cf40c62db53b4d66dc45e17c.jpeg differ
diff --git a/面试题/11-Kafka 面试题.assets/1f42986437f76c108007e86a51ae1287.jpeg b/面试题/11-Kafka 面试题.assets/1f42986437f76c108007e86a51ae1287.jpeg
new file mode 100644
index 0000000..5e03bbc
Binary files /dev/null and b/面试题/11-Kafka 面试题.assets/1f42986437f76c108007e86a51ae1287.jpeg differ
diff --git a/面试题/11-Kafka 面试题.assets/3636ff4bd554ee1dfcfb92448073b5b8.png b/面试题/11-Kafka 面试题.assets/3636ff4bd554ee1dfcfb92448073b5b8.png
new file mode 100644
index 0000000..f4a6e46
Binary files /dev/null and b/面试题/11-Kafka 面试题.assets/3636ff4bd554ee1dfcfb92448073b5b8.png differ
diff --git a/面试题/11-Kafka 面试题.assets/456f3adab70714c0a1b1fdbd8a686732.png b/面试题/11-Kafka 面试题.assets/456f3adab70714c0a1b1fdbd8a686732.png
new file mode 100644
index 0000000..70d86bc
Binary files /dev/null and b/面试题/11-Kafka 面试题.assets/456f3adab70714c0a1b1fdbd8a686732.png differ
diff --git a/面试题/11-Kafka 面试题.assets/792a59a9b2b4f271c179e81cf4278322.jpeg b/面试题/11-Kafka 面试题.assets/792a59a9b2b4f271c179e81cf4278322.jpeg
new file mode 100644
index 0000000..6f21c54
Binary files /dev/null and b/面试题/11-Kafka 面试题.assets/792a59a9b2b4f271c179e81cf4278322.jpeg differ
diff --git a/面试题/11-Kafka 面试题.assets/8493bc98876609462fba617d520d1b9a.jpeg b/面试题/11-Kafka 面试题.assets/8493bc98876609462fba617d520d1b9a.jpeg
new file mode 100644
index 0000000..afddcea
Binary files /dev/null and b/面试题/11-Kafka 面试题.assets/8493bc98876609462fba617d520d1b9a.jpeg differ
diff --git a/面试题/11-Kafka 面试题.assets/a034ab2df1d5b67520432355e0bbf95b.png b/面试题/11-Kafka 面试题.assets/a034ab2df1d5b67520432355e0bbf95b.png
new file mode 100644
index 0000000..1bae486
Binary files /dev/null and b/面试题/11-Kafka 面试题.assets/a034ab2df1d5b67520432355e0bbf95b.png differ
diff --git a/面试题/11-Kafka 面试题.assets/ac883ce247c1ff31c7cd4244392dcaed.png b/面试题/11-Kafka 面试题.assets/ac883ce247c1ff31c7cd4244392dcaed.png
new file mode 100644
index 0000000..3a9da1a
Binary files /dev/null and b/面试题/11-Kafka 面试题.assets/ac883ce247c1ff31c7cd4244392dcaed.png differ
diff --git a/面试题/11-Kafka 面试题.md b/面试题/11-Kafka 面试题.md
new file mode 100644
index 0000000..6cc0909
--- /dev/null
+++ b/面试题/11-Kafka 面试题.md	
@@ -0,0 +1,589 @@
+# 精尽 Kafka 面试题「最新更新时间：2024-02」
+
+以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。
+
+如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的 Kafka 面试题的大保健。
+
+而题目的难度，艿艿尽量按照从容易到困难的顺序，逐步下去。
+
+另外，这个面试题是建立在胖友看过 [《精尽【消息队列 】面试题》](http://svip.iocoder.cn/MQ/Interview) 。
+
+如果可能的话，推荐胖友先阅读了 [《Kafka 权威指南》](https://u.jd.com/jJpbF8) ，更加系统可靠。
+
+## Apache Kafka 是什么?
+
+Kafka 是基于**发布与订阅**的**消息系统**。它最初由 LinkedIn 公司开发，之后成为 Apache 项目的一部分。Kafka 是一个分布式的，可分区的，冗余备份的持久性的日志服务。它主要用于处理活跃的流式数据。
+
+在大数据系统中，常常会碰到一个问题，整个大数据是由各个子系统组成，数据需要在各个子系统中高性能、低延迟的不停流转。传统的企业消息系统并不是非常适合大规模的数据处理。为了同时搞定在线应用（消息）和离线应用（数据文件、日志），Kafka 就出现了。Kafka 可以起到两个作用：
+
+- 降低系统组网复杂度。
+- 降低编程复杂度，各个子系统不在是相互协商接口，各个子系统类似插口插在插座上，Kafka 承担高速**数据总线**的作用。
+
+🦅 **Kafka 的主要特点？**
+
+- 1、同时为发布和订阅提供高吞吐量。据了解，Kafka 每秒可以生产约 25 万消息（50MB），每秒处理 55 万消息（110MB）。
+
+- 2、可进行持久化操作。将消息持久化到磁盘，因此可用于批量消费，例如 ETL ，以及实时应用程序。通过将数据持久化到硬盘，以及replication ，可以防止数据丢失。
+
+- 3、分布式系统，易于向外扩展。所有的 Producer、Broker 和Consumer 都会有多个，均为分布式的。并且，无需停机即可扩展机器。
+
+- 4、消息被处理的状态是在 Consumer 端维护，而不是由 Broker 端维护。当失败时，能自动平衡。
+
+  > 这段是从网络上找来的。感觉想要表达的意思是
+  >
+  > - 消息是否被处理完成，是通过 Consumer 提交消费进度给 Broker ，而不是 Broker 消息被 Consumer 拉取后，就标记为已消费。
+  > - 当 Consumer 异常崩溃时，可以重新分配消息分区到其它的 Consumer 们，然后继续消费。
+
+- 5、支持 online 和 offline 的场景。
+
+🦅 **聊聊 Kafka 的设计要点？**
+
+1）吞吐量
+
+高吞吐是 Kafka 需要实现的核心目标之一，为此 kafka 做了以下一些设计：
+
+- 1、数据磁盘持久化：消息不在内存中 Cache ，直接写入到磁盘，充分利用磁盘的顺序读写性能。
+
+  > 直接使用 Linux 文件系统的 Cache ，来高效缓存数据。
+
+- 2、zero-copy：减少 IO 操作步骤
+
+  > 采用 Linux Zero-Copy 提高发送性能。
+  >
+  > - 传统的数据发送需要发送 4 次上下文切换。
+  > - 采用 sendfile 系统调用之后，数据直接在内核态交换，系统上下文切换减少为 2 次。根据测试结果，可以提高 60% 的数据发送性能。Zero-Copy 详细的技术细节可以参考 [《Efficient data transfer through zero copy》](https://developer.ibm.com/articles/j-zerocopy/) 文章。
+
+- 3、数据批量发送
+
+- 4、数据压缩
+
+- 5、Topic 划分为多个 Partition ，提高并行度。
+
+  > 数据在磁盘上存取代价为 `O(1)`。
+  >
+  > - Kafka 以 Topic 来进行消息管理，每个 Topic 包含多个 Partition ，每个 Partition 对应一个逻辑 log ，有多个 segment 文件组成。
+  > - 每个 segment 中存储多条消息（见下图），消息 id 由其逻辑位置决定，即从消息 id 可直接定位到消息的存储位置，避免 id 到位置的额外映射。
+  > - 每个 Partition 在内存中对应一个 index ，记录每个 segment 中的第一条消息偏移。
+  >
+  > 发布者发到某个 Topic 的消息会被均匀的分布到多个 Partition 上（随机或根据用户指定的回调函数进行分布），Broker 收到发布消息往对应 Partition 的最后一个 segment 上添加该消息。
+  > 当某个 segment上 的消息条数达到配置值或消息发布时间超过阈值时，segment上 的消息会被 flush 到磁盘，只有 flush 到磁盘上的消息订阅者才能订阅到，segment 达到一定的大小后将不会再往该 segment 写数据，Broker 会创建新的 segment 文件。
+
+2）负载均衡
+
+- 1、Producer 根据用户指定的算法，将消息发送到指定的 Partition 中。
+- 2、Topic 存在多个 Partition ，每个 Partition 有自己的replica ，每个 replica 分布在不同的 Broker 节点上。多个Partition 需要选取出 Leader partition ，Leader Partition 负责读写，并由 Zookeeper 负责 fail over 。
+- 3、相同 Topic 的多个 Partition 会分配给不同的 Consumer 进行拉取消息，进行消费。
+
+3）拉取系统
+
+由于 Kafka Broker 会持久化数据，Broker 没有内存压力，因此， Consumer 非常适合采取 pull 的方式消费数据，具有以下几点好处：
+
+- 1、简化 Kafka 设计。
+- 2、Consumer 根据消费能力自主控制消息拉取速度。
+- 3、Consumer 根据自身情况自主选择消费模式，例如批量，重复消费，从尾端开始消费等。
+
+4）可扩展性
+
+> 通过 Zookeeper 管理 Broker 与 Consumer 的动态加入与离开。
+
+- 当需要增加 Broker 节点时，新增的 Broker 会向 Zookeeper 注册，而 Producer 及 Consumer 会根据注册在 Zookeeper 上的 watcher 感知这些变化，并及时作出调整。
+- 当新增和删除 Consumer 节点时，相同 Topic 的多个 Partition 会分配给剩余的 Consumer 们。
+
+另外，推荐阅读 [《为什么 Kafka 这么快？》](https://mp.weixin.qq.com/s/pzVS7r3QaQPFwob-fY8b4A) 文章，写的更加细致。
+
+## Kafka 的架构是怎么样的？
+
+[![Kafka 架构图](11-Kafka 面试题.assets/ac883ce247c1ff31c7cd4244392dcaed.png)](http://static.iocoder.cn/ac883ce247c1ff31c7cd4244392dcaed)Kafka 架构图
+
+Kafka 的整体架构非常简单，是分布式架构，Producer、Broker 和Consumer 都可以有多个。
+
+- Producer，Consumer 实现 Kafka 注册的接口。
+- 数据从 Producer 发送到 Broker 中，Broker 承担一个中间缓存和分发的作用。
+- Broker 分发注册到系统中的 Consumer。Broker 的作用类似于缓存，即活跃的数据和离线处理系统之间的缓存。
+- 客户端和服务器端的通信，是基于简单，高性能，且与编程语言无关的 TCP 协议。
+
+几个重要的基本概念：
+
+- Topic：特指 Kafka 处理的消息源（feeds of messages）的不同分类。
+
+- Partition：Topic 物理上的分组（分区），一个 Topic 可以分为多个 Partition 。每个 Partition 都是一个有序的队列。Partition 中的每条消息都会被分配一个有序的 id（offset）。
+
+  > - replicas：Partition 的副本集，保障 Partition 的高可用。
+  > - leader：replicas 中的一个角色，Producer 和 Consumer 只跟 Leader 交互。
+  > - follower：replicas 中的一个角色，从 leader 中复制数据，作为副本，一旦 leader 挂掉，会从它的 followers 中选举出一个新的 leader 继续提供服务。
+
+- Message：消息，是通信的基本单位，每个 Producer 可以向一个Topic（主题）发布一些消息。
+
+- Producers：消息和数据生产者，向 Kafka 的一个 Topic 发布消息的过程，叫做 producers 。
+
+- Consumers：消息和数据消费者，订阅 Topic ，并处理其发布的消息的过程，叫做 consumers 。
+
+  > Consumer group：每个 Consumer 都属于一个 Consumer group，每条消息只能被 Consumer group 中的一个 Consumer 消费，但可以被多个 Consumer group 消费。
+
+- Broker：缓存代理，Kafka 集群中的一台或多台服务器统称为 broker 。
+
+  > Controller：Kafka 集群中，通过 Zookeeper 选举某个 Broker 作为 Controller ，用来进行 leader election 以及 各种 failover 。
+
+- ZooKeeper：Kafka 通过 ZooKeeper 来存储集群的 Topic、Partition 等元信息等。
+
+😈 单纯角色来说，Kafka 和 RocketMQ 是基本一致的。比较明显的差异是：
+
+> RocketMQ 从 Kafka 演化而来。
+
+- 1、Kafka 使用 Zookeeper 作为命名服务；RocketMQ 自己实现了一个轻量级的 Namesrv 。
+
+- 2、Kafka Broker 的每个分区都有一个首领分区；RocketMQ 每个分区的“首领”分区，都在 Broker Master 节点上。
+
+  > RocketMQ 没有首领分区一说，所以打上了引号。
+
+- 3、Kafka Consumer 使用 poll 的方式拉取消息；RocketMQ Consumer 提供 poll 的方式的同时，封装了一个 push 的方式。
+
+  > RocketMQ 的 push 的方式，也是基于 poll 的方式的封装。
+
+- … 当然还有其它 …
+
+🦅 **Kafka 为什么要将 Topic 进行分区？**
+
+正如我们在 [「聊聊 Kafka 的设计要点？」](https://svip.iocoder.cn/Kafka/Interview/#) 问题中所看到的，是为了负载均衡，从而能够水平拓展。
+
+- Topic 只是逻辑概念，面向的是 Producer 和 Consumer ，而 Partition 则是物理概念。如果 Topic 不进行分区，而将 Topic 内的消息存储于一个 Broker，那么关于该 Topic 的所有读写请求都将由这一个 Broker 处理，吞吐量很容易陷入瓶颈，这显然是不符合高吞吐量应用场景的。
+- 有了 Partition 概念以后，假设一个 Topic 被分为 10 个 Partitions ，Kafka 会根据一定的算法将 10 个 Partition 尽可能均匀的分布到不同的 Broker（服务器）上。
+- 当 Producer 发布消息时，Producer 客户端可以采用 random、key-hash 及轮询等算法选定目标 Partition ，若不指定，Kafka 也将根据一定算法将其置于某一分区上。
+- 当 Consumer 拉取消息时，Consumer 客户端可以采用 Range、轮询 等算法分配 Partition ，从而从不同的 Broker 拉取对应的 Partition 的 leader 分区。
+
+所以，Partiton 机制可以极大的提高吞吐量，并且使得系统具备良好的水平扩展能力。
+
+## Kafka 的应用场景有哪些？
+
+[![Kafka 的应用场景](11-Kafka 面试题.assets/3636ff4bd554ee1dfcfb92448073b5b8.png)](http://static.iocoder.cn/3636ff4bd554ee1dfcfb92448073b5b8)Kafka 的应用场景
+
+1）消息队列
+
+比起大多数的消息系统来说，Kafka 有更好的吞吐量，内置的分区，冗余及容错性，这让 Kafka 成为了一个很好的大规模消息处理应用的解决方案。消息系统一般吞吐量相对较低，但是需要更小的端到端延时，并常常依赖于 Kafka 提供的强大的持久性保障。在这个领域，Kafka 足以媲美传统消息系统，如 ActiveMQ 或 RabbitMQ 。
+
+2）行为跟踪
+
+Kafka 的另一个应用场景，是跟踪用户浏览页面、搜索及其他行为，以发布订阅的模式实时记录到对应的 Topic 里。那么这些结果被订阅者拿到后，就可以做进一步的实时处理，或实时监控，或放到 Hadoop / 离线数据仓库里处理。
+
+3）元信息监控
+
+作为操作记录的监控模块来使用，即汇集记录一些操作信息，可以理解为运维性质的数据监控吧。
+
+4）日志收集
+
+日志收集方面，其实开源产品有很多，包括 Scribe、Apache Flume 。很多人使用 Kafka 代替日志聚合（log aggregation）。日志聚合一般来说是从服务器上收集日志文件，然后放到一个集中的位置（文件服务器或 HDFS）进行处理。
+
+然而， Kafka 忽略掉文件的细节，将其更清晰地抽象成一个个日志或事件的消息流。这就让 Kafka 处理过程延迟更低，更容易支持多数据源和分布式数据处理。比起以日志为中心的系统比如 Scribe 或者 Flume 来说，Kafka 提供同样高效的性能和因为复制导致的更高的耐用性保证，以及更低的端到端延迟。
+
+5）流处理
+
+这个场景可能比较多，也很好理解。保存收集流数据，以提供之后对接的 Storm 或其他流式计算框架进行处理。很多用户会将那些从原始 Topic 来的数据进行阶段性处理，汇总，扩充或者以其他的方式转换到新的 Topic 下再继续后面的处理。
+
+例如一个文章推荐的处理流程，可能是先从 RSS 数据源中抓取文章的内容，然后将其丢入一个叫做“文章”的 Topic 中。后续操作可能是需要对这个内容进行清理，比如回复正常数据或者删除重复数据，最后再将内容匹配的结果返还给用户。这就在一个独立的 Topic 之外，产生了一系列的实时数据处理的流程。Strom 和 Samza 是非常著名的实现这种类型数据转换的框架。
+
+6）事件源
+
+事件源，是一种应用程序设计的方式。该方式的状态转移被记录为按时间顺序排序的记录序列。Kafka 可以存储大量的日志数据，这使得它成为一个对这种方式的应用来说绝佳的后台。比如动态汇总（News feed）。
+
+7）持久性日志（Commit Log）
+
+Kafka 可以为一种外部的持久性日志的分布式系统提供服务。这种日志可以在节点间备份数据，并为故障节点数据回复提供一种重新同步的机制。Kafka 中日志压缩功能为这种用法提供了条件。在这种用法中，Kafka 类似于 Apache BookKeeper 项目。
+
+## Kafka 消息发送和消费的简化流程是什么？
+
+[![Kafka 消息发送和消费](11-Kafka 面试题.assets/456f3adab70714c0a1b1fdbd8a686732.png)](http://static.iocoder.cn/456f3adab70714c0a1b1fdbd8a686732)Kafka 消息发送和消费
+
+- 1、Producer ，根据指定的 partition 方法（round-robin、hash等），将消息发布到指定 Topic 的 Partition 里面。
+- 2、Kafka 集群，接收到 Producer 发过来的消息后，将其持久化到硬盘，并保留消息指定时长（可配置），而不关注消息是否被消费。
+- 3、Consumer ，从 Kafka 集群 pull 数据，并控制获取消息的 offset 。至于消费的进度，可手动或者自动提交给 Kafka 集群。
+
+🦅 **1）Producer 发送消息**
+
+Producer 采用 push 模式将消息发布到 Broker，每条消息都被 append 到 Patition 中，属于顺序写磁盘（顺序写磁盘效率比随机写内存要高，保障 Kafka 吞吐率）。Producer 发送消息到 Broker 时，会根据分区算法选择将其存储到哪一个 Partition 。
+
+其路由机制为：
+
+- 1、指定了 Partition ，则直接使用。
+- 2、未指定 Partition 但指定 key ，通过对 key 进行 hash 选出一个 Partition 。
+- 3、Partition 和 key 都未指定，使用轮询选出一个 Partition 。
+
+写入流程：
+
+- 1、Producer 先从 ZooKeeper 的 `"/brokers/.../state"` 节点找到该 Partition 的 leader 。
+
+  > 注意噢，Producer 只和 Partition 的 leader 进行交互。
+
+- 2、Producer 将消息发送给该 leader 。
+
+- 3、leader 将消息写入本地 log 。
+
+- 4、followers 从 leader pull 消息，写入本地 log 后 leader 发送 ACK 。
+
+- 5、leader 收到所有 ISR 中的 replica 的 ACK 后，增加 HW（high watermark ，最后 commit 的 offset） 并向 Producer 发送 ACK 。
+
+🦅 **2）Broker 存储消息**
+
+物理上把 Topic 分成一个或多个 Patition，每个 Patition 物理上对应一个文件夹（该文件夹存储该 Patition 的所有消息和索引文件）。
+
+🦅 **3）Consumer 消费消息**
+
+high-level Consumer API 提供了 consumer group 的语义，一个消息只能被 group 内的一个 Consumer 所消费，且 Consumer 消费消息时不关注 offset ，最后一个 offset 由 ZooKeeper 保存（下次消费时，该 group 中的 Consumer 将从 offset 记录的位置开始消费）。
+
+注意：
+
+- 1、如果消费线程大于 Patition 数量，则有些线程将收不到消息。
+- 2、如果 Patition 数量大于消费线程数，则有些线程多收到多个 Patition 的消息。
+- 3、如果一个线程消费多个 Patition，则无法保证你收到的消息的顺序，而一个 Patition 内的消息是有序的。
+
+Consumer 采用 pull 模式从 Broker 中读取数据。
+
+- push 模式，很难适应消费速率不同的消费者，因为消息发送速率是由 Broker 决定的。它的目标是尽可能以最快速度传递消息，但是这样很容易造成 Consumer 来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。而 pull 模式，则可以根据 Consumer 的消费能力以适当的速率消费消息。
+- 对于 Kafka 而言，pull 模式更合适，它可简化 Broker 的设计，Consumer 可自主控制消费消息的速率，同时 Consumer 可以自己控制消费方式——即可批量消费也可逐条消费，同时还能选择不同的提交方式从而实现不同的传输语义。
+
+🦅 **Kafka Producer 有哪些发送模式？**
+
+Kafka 的发送模式由 Producer 端的配置参数 `producer.type`来设置。
+
+- 这个参数指定了在后台线程中消息的发送方式是同步的还是异步的，默认是同步的方式，即 `producer.type=sync` 。
+- 如果设置成异步的模式，即 `producer.type=async` ，可以是 Producer 以 batch 的形式 push 数据，这样会极大的提高 Broker的性能，但是这样会增加丢失数据的风险。
+- 如果需要确保消息的可靠性，必须要将 `producer.type`设置为 sync 。
+
+对于异步模式，还有 4 个配套的参数，如下：
+
+[![参数](11-Kafka 面试题.assets/792a59a9b2b4f271c179e81cf4278322.jpeg)](http://static.iocoder.cn/792a59a9b2b4f271c179e81cf4278322)参数
+
+- 以 batch 的方式推送数据可以极大的提高处理效率，Kafka Producer 可以将消息在内存中累计到一定数量后作为一个 batch 发送请求。batch 的数量大小可以通过 Producer 的参数（`batch.num.messages`）控制。通过增加 batch 的大小，可以减少网络请求和磁盘 IO 的次数，当然具体参数设置需要在效率和时效性方面做一个权衡。
+
+- 在比较新的版本中还有
+
+   
+
+  ```
+  batch.size
+  ```
+
+   
+
+  这个参数。Producer 会尝试批量发送属于同一个 Partition 的消息以减少请求的数量. 这样可以提升客户端和服务端的性能。默认大小是 16348 byte (16k).
+
+  - 发送到 Broker 的请求可以包含多个 batch ，每个 batch 的数据属于同一个 Partition 。
+  - 太小的 batch 会降低吞吐. 太大会浪费内存。
+
+具体的代码实现，可以看看 [《芋道 Spring Boot 消息队列 Kafka 入门》](http://www.iocoder.cn/Spring-Boot/RabbitMQ/?vip)的[「3. 快速入门」](https://svip.iocoder.cn/Kafka/Interview/#)和[「4. 批量发送消息」](https://svip.iocoder.cn/Kafka/Interview/#)小节。
+
+🦅 **Kafka Consumer 是否可以消费指定的分区消息？**
+
+Consumer 消费消息时，向 Broker 发出“fetch”请求去消费特定分区的消息，Consumer 指定消息在日志中的偏移量(offset)，就可以消费从这个位置开始的消息，Consumer 拥有了 offset 的控制权，可以向后回滚去重新消费之前的消息，这是很有意义的。
+
+🦅 **Kafka 的 high-level API 和 low-level API 的区别？**
+
+High Level API
+
+- 屏蔽了每个 Topic 的每个 Partition 的 offset 管理（自动读取Zookeeper 中该 Consumer group 的 last offset）、Broker 失败转移、以及增减 Partition 时 Consumer 时的负载均衡（Kafka 自动进行负载均衡）。
+- 如果 Consumer 比 Partition 多，是一种浪费。一个 Partition 上是不允许并发的，所以 Consumer 数不要大于 Partition 数。
+
+Low Level API
+
+> Low-level API 也就是 Simple Consumer API ，实际上非常复杂。
+
+- API 控制更灵活，例如消息重复读取，消息 offset 跳读，Exactly Once 原语。
+- API 更复杂，offset 不再透明，需要自己管理，Broker 自动失败转移需要处理，增加 Consumer、Partition、Broker 需要自己做负载均衡。
+
+## Kafka 的网络模型是怎么样的？
+
+Kafka 基于高吞吐率和效率考虑，并没有使用第三方网络框架，而且自己基于 Java NIO 封装的。
+
+🦅 **1）KafkaClient ，单线程 Selector 模型。**
+
+[![KafkaClient](11-Kafka 面试题.assets/00e8ec59cf40c62db53b4d66dc45e17c.jpeg)](http://static.iocoder.cn/00e8ec59cf40c62db53b4d66dc45e17c)KafkaClient
+
+> 实际上，就是 NettyClient 的 NIO 方式。
+
+- 单线程模式适用于并发链接数小，逻辑简单，数据量小。
+- 在 Kafka 中，Consumer 和 Producer 都是使用的上面的单线程模式。这种模式不适合 Kafka 的服务端，在服务端中请求处理过程比较复杂，会造成线程阻塞，一旦出现后续请求就会无法处理，会造成大量请求超时，引起雪崩。而在服务器中应该充分利用多线程来处理执行逻辑。
+
+🦅 **2）KafkaServer ，多线程 Selector 模型。**
+
+> KafkaServer ，指的是 Kafka Broker 。
+
+[![KafkaServer](11-Kafka 面试题.assets/8493bc98876609462fba617d520d1b9a.jpeg)](http://static.iocoder.cn/8493bc98876609462fba617d520d1b9a)KafkaServer
+
+Broker 的内部处理流水线化，分为多个阶段来进行(SEDA)，以提高吞吐量和性能，尽量避免 Thead 盲等待，以下为过程说明。
+
+> 实际上，就是 NettyServer 的 NIO 方式。
+
+- Accept Thread 负责与客户端建立连接链路，然后把 Socket 轮转交给Process Thread 。
+
+  > 相当于 Netty 的 Boss EventLoop 。
+
+- Process Thread 负责接收请求和响应数据，Process Thread 每次基于 Selector 事件循环，首先从 Response Queue 读取响应数据，向客户端回复响应，然后接收到客户端请求后，读取数据放入 Request Queue 。
+
+  > 相当于 Netty 的 Worker EventLoop 。
+
+- Work Thread 负责业务逻辑、IO 磁盘处理等，负责从 Request Queue 读取请求，并把处理结果放入 Response Queue 中，待 Process Thread 发送出去。
+
+  > 相当于业务线程池。
+
+😈 实际上，艿艿的想法，如果自己实现 MQ ，完全可以直接使用 Netty 作为网络通信框架。包括，RocketMQ 就是如此实现的。
+
+🦅 **解释如何提高远程用户的吞吐量?**
+
+如果 Producer、Consumer 位于与 Broker 不同的数据中心，则可能需要调优套接口缓冲区大小，以对长网络延迟进行摊销。
+
+## Kafka 的数据存储模型是怎么样的?
+
+Kafka 每个 Topic 下面的所有消息都是以 Partition 的方式分布式的存储在多个节点上。同时在 Kafka 的机器上，每个 Partition 其实都会对应一个日志目录，在目录下面会对应多个日志分段（LogSegment）。
+
+```
+MacBook-Pro-5:test-0 yunai$ ls
+00000000000000000000.index	00000000000000000000.timeindex	leader-epoch-checkpoint
+00000000000000000000.log	00000000000000000004.snapshot
+```
+
+- Topic 为 `test` ，Partition 为 0 ，所以文件目录是 `test-0` 。
+
+LogSegment 文件由两部分组成，分别为 `.index` 文件和 `.log` 文件，分别表示为 segment **索引**文件和**数据**文件。这两个文件的命令规则为：Partition 全局的第一个 segment 从 0 开始，后续每个 segment 文件名为上一个 segment 文件最后一条消息的 offset 值，数值大小为 64 位，20 位数字字符长度，没有数字用 0 填充，如下，假设有 1000 条消息，每个 LogSegment 大小为 100 ，下面展现了 900-1000 的 `.index` 和 `.log` 文件：
+
+[`.index` 和 `.log` 文件](https://user-gold-cdn.xitu.io/2018/7/24/164ca4f7e778be7c?imageView2/0/w/1280/h/960/format/jpeg/ignore-error/1)
+
+- 由于 Kafka 消息数据太大，如果全部建立索引，即占了空间又增加了耗时，所以 Kafka 选择了稀疏索引的方式（通过 `.index` 索引 `.log` 文件），这样的话索引可以直接进入内存，加快偏查询速度。
+
+🦅 **简单介绍一下如何读取数据？**
+
+如果我们要读取第 911 条数据。
+
+- 首先第一步，找到它是属于哪一段的，根据二分法查找到他属于的文件，找到 `0000900.index` 和 `00000900.log` 之后。
+
+- 然后，去 `.index` 中去查找 `(911-900) =11` 这个索引或者小于 11 最近的索引，在这里通过二分法我们找到了索引是 `[10,1367]` 。
+
+  > - 10 表示，第 10 条消息开始。
+  > - 1367 表示，在 `.log` 的第 1367 字节开始。
+  >
+  > 😈 所以，本图的第 911 条的“1360”是错的，相比“1367” 反倒小了。
+
+- 然后，我们通过这条索引的物理位置 1367 ，开始往后找，直到找到 911 条数据。
+
+上面讲的是如果要找某个 offset 的流程，但是我们大多数时候并不需要查找某个 offset ，只需要按照顺序读即可。而在顺序读中，操作系统会对内存和磁盘之间添加 page cahe ，也就是我们平常见到的预读操作，所以我们的顺序读操作时速度很快。但是 Kafka 有个问题，如果分区过多，那么日志分段也会很多，写的时候由于是批量写，其实就会变成随机写了，随机 I/O 这个时候对性能影响很大。所以一般来说 Kafka 不能有太多的Partition 。针对这一点，RocketMQ 把所有的日志都写在一个文件里面，就能变成顺序写，通过一定优化，读也能接近于顺序读。
+
+> 并且，截止到 RocketMQ4 版本，索引文件，对每个数据文件中的消息，都有对应的索引。这个是和 Kafka 的稀疏索引不太一样的地方。
+
+更详尽的，推荐阅读 [《Kafka 之数据存储》](http://matt33.com/2016/03/08/kafka-store/) 文章。
+
+🦅 **为什么不能以 Partition 作为存储单位？**
+
+如果就以 Partition 为最小存储单位，可以想象，当 Kafka Producer 不断发送消息，必然会引起 Partition 文件的无限扩张，将对消息文件的维护以及已消费的消息的清理带来严重的影响，因此，需以 segment 为单位将 Partition 进一步细分。
+
+每个 Partition（目录）相当于一个巨型文件，被平均分配到多个大小相等的 segment（段）数据文件中（每个 segment 文件中消息数量不一定相等），这种特性也方便 old segment 的删除，即方便已被消费的消息的清理，提高磁盘的利用率。每个 Partition 只需要支持顺序读写就行，segment 的文件生命周期由服务端配置参数（`log.segment.bytes`，`log.roll.{ms,hours}` 等若干参数）决定。
+
+## Kafka 的消息格式是怎么样的？
+
+message 中的物理结构为：
+
+[![message 物理结构](11-Kafka 面试题.assets/a034ab2df1d5b67520432355e0bbf95b.png)](http://static.iocoder.cn/a034ab2df1d5b67520432355e0bbf95b)message 物理结构
+
+参数说明：
+
+| 关键字              | 解释说明                                                     |
+| :------------------ | :----------------------------------------------------------- |
+| 8 byte offset       | 在parition(分区)内的每条消息都有一个有序的id号，这个id号被称为偏移(offset),它可以唯一确定每条消息在parition(分区)内的位置。即offset表示partiion的第多少message |
+| 4 byte message size | message大小                                                  |
+| 4 byte CRC32        | 用crc32校验message                                           |
+| 1 byte “magic”      | 表示本次发布Kafka服务程序协议版本号                          |
+| 1 byte “attributes” | 表示为独立版本、或标识压缩类型、或编码类型                   |
+| 4 byte key length   | 表示key的长度,当key为-1时，K byte key字段不填                |
+| K byte key          | 可选                                                         |
+| value bytes payload | 表示实际消息数据                                             |
+
+不过，这是早期 Kafka 的版本，最新版本的格式，推荐阅读如下两篇文章：
+
+- [《一文看懂 Kafka 消息格式的演变》](http://www.iocoder.cn/Kafka/message-format/?vip)
+- [《Kafka 消息格式中的变长字段（Varints）》](http://www.iocoder.cn/Kafka/varints/)
+
+当然，看懂这个数据格式，基本也能知道消息的大体格式。
+
+## Kafka 的副本机制是怎么样的？
+
+Kafka 的副本机制，是多个 Broker 节点对其他节点的 Topic 分区的日志进行复制。当集群中的某个节点出现故障，访问故障节点的请求会被转移到其他正常节点(这一过程通常叫 Reblance)，Kafka 每个主题的每个分区都有一个主副本以及 0 个或者多个副本，副本保持和主副本的数据同步，当主副本出故障时就会被替代。
+
+[![副本机制](11-Kafka 面试题.assets/1f42986437f76c108007e86a51ae1287.jpeg)](http://static.iocoder.cn/1f42986437f76c108007e86a51ae1287)副本机制
+
+> 注意哈，下面说的 Leader 指的是每个 Topic 的某个分区的 Leader ，而不是 Broker 集群中的【集群控制器】。
+
+在 Kafka 中并不是所有的副本都能被拿来替代主副本，所以在 Kafka 的Leader 节点中维护着一个 ISR（In sync Replicas）集合，翻译过来也叫正在同步中集合，在这个集合中的需要满足两个条件:
+
+- 1、节点必须和 Zookeeper 保持连接。
+- 2、在同步的过程中这个副本不能落后主副本太多。
+
+另外还有个 AR（Assigned Replicas）用来标识副本的全集，OSR 用来表示由于落后被剔除的副本集合，所以公式如下：
+
+- ISR = Leader + 没有落后太多的副本。
+- AR = OSR + ISR 。
+
+这里先要说下两个名词：HW 和 LEO 。
+
+- HW（高水位 HighWatermark），是 Consumer 能够看到的此 Partition 的位置。
+- LEO（logEndOffset），是每个 Partition 的 log 最后一条 Message 的位置。
+- HW 能保证 Leader 所在的 Broker 失效，该消息仍然可以从新选举的Leader 中获取，不会造成消息丢失。
+
+当 Producer 向 Leader 发送数据时，可以通过`request.required.acks` 参数来设置数据可靠性的级别：
+
+- 1（默认）：这意味着 Producer 在 ISR 中的 Leader 已成功收到的数据并得到确认后发送下一条 message 。如果 Leader 宕机了，则会丢失数据。
+- 0：这意味着 Producer 无需等待来自 Broker 的确认而继续发送下一批消息。这种情况下数据传输效率最高，但是数据可靠性确是最低的。
+- -1：Producer 需要等待 ISR 中的所有 Follower 都确认接收到数据后才算一次发送完成，可靠性最高。但是这样也不能保证数据不丢失，比如当 ISR 中只有 Leader 时(其他节点都和 Zookeeper 断开连接，或者都没追上)，这样就变成了 `acks=1` 的情况。
+
+关于这块详详细的内容，推荐阅读
+
+- [《Kafka 数据可靠性深度解读》](https://blog.csdn.net/u013256816/article/details/71091774) 的 [「3 高可靠性存储分析」](https://svip.iocoder.cn/Kafka/Interview/#) 小节
+- [《Kafka 集群内复制功能深入剖析》](https://www.jianshu.com/p/03d6a335237f)
+
+## ZooKeeper 在 Kafka 中起到什么作用？
+
+关于 ZooKeeper 是什么，不了解的胖友，直接去看 [《精尽 Zookeeper 面试题》](http://svip.iocoder.cn/Zookeeper/Interview/) 。
+
+在基于 Kafka 的分布式消息队列中，ZooKeeper 的作用有：
+
+- 1、Broker 在 ZooKeeper 中的注册。
+
+- 2、Topic 在 ZooKeeper 中的注册。
+
+- 3、Consumer 在 ZooKeeper 中的注册。
+
+- 4、Producer 负载均衡。
+
+  > 主要指的是，Producer 从 Zookeeper 拉取 Topic 元数据，从而能够将消息发送负载均衡到对应 Topic 的分区中。
+
+- 5、Consumer 负载均衡。
+
+- 6、记录消费进度 Offset 。
+
+  > Kafka 已推荐将 consumer 的 Offset 信息保存在 Kafka 内部的 Topic 中。
+
+- 7、记录 Partition 与 Consumer 的关系。
+
+其实，总结起来，就是两类功能：
+
+- Broker、Producer、Consumer 和 Zookeeper 的交互。
+
+  > 对应 1、2、3、5 。
+
+- 相应的状态存储到 Zookeeper 中。
+
+  > 对应 4、6、7 。
+
+详细的每一点，看 [《再谈基于 Kafka 和 ZooKeeper 的分布式消息队列原理》](https://gitbook.cn/books/5bc446269a9adf54c7ccb8bc/index.html) 的 [「Kafka 架构中 ZooKeeper 以怎样的形式存在？」](https://svip.iocoder.cn/Kafka/Interview/#) 小节。
+
+## Kafka 如何实现高可用？
+
+在 [「Kafka 的架构是怎么样的？」](https://svip.iocoder.cn/Kafka/Interview/#) 问题中，已经基本回答了这个问题。
+
+[Kafka 集群](https://segmentfault.com/img/bVbcmpm?w=776&h=436)
+
+- Zookeeper 部署 2N+1 节点，形成 Zookeeper 集群，保证高可用。
+
+- Kafka Broker 部署集群。每个 Topic 的 Partition ，基于【副本机制】，在 Broker 集群中复制，形成 replica 副本，保证消息存储的可靠性。每个 replica 副本，都会选择出一个 leader 分区（Partition），提供给客户端（Producer 和 Consumer）进行读写。
+
+- Kafka Producer 无需考虑集群，因为和业务服务部署在一起。Producer 从 Zookeeper 拉取到 Topic 的元数据后，选择对应的 Topic 的 leader 分区，进行消息发送写入。而 Broker 根据 Producer 的 `request.required.acks` 配置，是写入自己完成就响应给 Producer 成功，还是写入所有 Broker 完成再响应。这个，就是胖友自己对消息的可靠性的选择。
+
+- Kafka Consumer 部署集群。每个 Consumer 分配其对应的 Topic Partition ，根据对应的分配策略。并且，Consumer 只从 leader 分区（Partition）拉取消息。另外，当有新的 Consumer 加入或者老的 Consumer 离开，都会将 Topic Partition 再均衡，重新分配给 Consumer 。
+
+  > 注意噢，此处说的都是同一个 Kafka Consumer group 。
+
+总的来说，Kafka 和 RocketMQ 的高可用方式是比较类似的，主要的差异在 Kafka Broker 的副本机制，和 RocketMQ Broker 的主从复制，两者的差异，以及差异带来的生产和消费不同。😈 当然，实际上，都是和“主” Broker 做消息的发送和读取不是？！
+
+## 什么是 Kafka 事务？
+
+推荐阅读 [《Kafka 事务简介》](https://blog.csdn.net/ransom0512/article/details/78840042) 文章。
+
+😈 和想象中的，是不是有点差别？！
+
+具体的代码实现，可以看看 [《芋道 Spring Boot 消息队列 Kafka 入门》](http://www.iocoder.cn/Spring-Boot/RabbitMQ/?vip)的[「11. 事务消息」](https://svip.iocoder.cn/Kafka/Interview/#)小节。
+
+## Kafka 是否会弄丢数据？
+
+> 艿艿：注意，Kafka 是否会丢数据，主要取决于我们如何使用。这点，非常重要噢。
+
+🦅 **消费端弄丢了数据？**
+
+唯一可能导致消费者弄丢数据的情况，就是说，你消费到了这个消息，然后消费者那边自动提交了 offset ，让 Broker 以为你已经消费好了这个消息，但其实你才刚准备处理这个消息，你还没处理，你自己就挂了，此时这条消息就丢咯。
+
+这不是跟 RabbitMQ 差不多吗，大家都知道 Kafka 会自动提交 offset ，那么只要关闭自动提交 offset ，在处理完之后自己手动提交 offset ，就可以保证数据不会丢。但是此时确实还是可能会有重复消费，比如你刚处理完，还没提交 offset ，结果自己挂了，此时肯定会重复消费一次，自己保证幂等性就好了。
+
+> RocketMQ push 模式下，在确认消息被消费完成，才会提交 Offset 给 Broker 。
+
+生产环境碰到的一个问题，就是说我们的 Kafka 消费者消费到了数据之后是写到一个内存的 queue 里先缓冲一下，结果有的时候，你刚把消息写入内存 queue ，然后消费者会自动提交 offset 。然后此时我们重启了系统，就会导致内存 queue 里还没来得及处理的数据就丢失了。
+
+具体的代码实现，可以看看 [《芋道 Spring Boot 消息队列 Kafka 入门》](http://www.iocoder.cn/Spring-Boot/RabbitMQ/?vip)的[「12. 消费进度的提交机制」](https://svip.iocoder.cn/Kafka/Interview/#)小节。
+
+🦅 **Broker 弄丢了数据？**
+
+这块比较常见的一个场景，就是 Kafka 某个 Broker 宕机，然后重新选举 Partition 的 leader。大家想想，要是此时其他的 follower 刚好还有些数据没有同步，结果此时 leader 挂了，然后选举某个 follower 成 leader 之后，不就少了一些数据？这就丢了一些数据啊。
+
+生产环境也遇到过，我们也是，之前 Partition 的 leader 机器宕机了，将 follower 切换为 leader 之后，就会发现说这个数据就丢了。
+
+所以此时一般是要求起码设置如下 4 个参数：
+
+- 给 Topic 设置 `replication.factor` 参数：这个值必须大于 1，要求每个 partition 必须有至少 2 个副本。
+
+- 在 Kafka 服务端设置 `min.insync.replicas` 参数：这个值必须大于 1 ，这个是要求一个 leader 至少感知到有至少一个 follower 还跟自己保持联系，没掉队，这样才能确保 leader 挂了还有一个 follower 吧。
+
+- 在 Producer 端设置 `acks=all`：这个是要求每条数据，必须是**写入所有 replica 之后，才能认为是写成功了**。
+
+  > 不过这个也不一定能够绝对保证，例如说，Broker 集群里，所有节点都挂了，只剩下一个节点。此时，`acks=all` 和 `acks=1` 就等价了。当然，也可以通过设置 `min.insync.replics` 参数，每次写入要求最小的同步副本数。
+  >
+  > 这块也和朋友交流了下，他们金融场景下，`acks=all` 也是这么配置的。原因嘛，因为他们是金融场景呀。
+
+- 在 Producer 端设置 `retries=MAX`（很大很大很大的一个值，无限次重试的意思）：这个是**要求一旦写入失败，就无限重试**，卡在这里了。
+
+我们生产环境就是按照上述要求配置的，这样配置之后，至少在 Kafka broker 端就可以保证在 leader 所在 Broker 发生故障，进行 leader 切换时，数据不会丢失。
+
+🦅 **生产者会不会弄丢数据？**
+
+如果按照上述的思路设置了 `acks=all` ，一定不会丢，要求是，你的 leader 接收到消息，所有的 follower 都同步到了消息之后，才认为本次写成功了。如果没满足这个条件，生产者会自动不断的重试，重试无限次。
+
+- 关于 Kafka Producer 重试发送消息的逻辑的源码解析，可以看看 [《Kafka 重试机制解读》](https://www.jianshu.com/p/5bf9c7c02ada) 。
+
+------
+
+😈 另外，在推荐一篇文章 [《360 度测试：KAFKA 会丢数据么？其高可用是否满足需求？》](https://juejin.im/post/5bf8f2bee51d4507c12bc722) ，提供了一些测试示例。
+
+关于这一块，可以重点看看 [《Kafka 权威指南》](https://u.jd.com/jJpbF8) 的 [「6.4 在可靠的系统里使用生产者」](https://svip.iocoder.cn/Kafka/Interview/#) 和 [「6.5 在可靠的系统里使用消费者」](https://svip.iocoder.cn/Kafka/Interview/#) 小节。
+
+## Kafka 如何保证消息的顺序性？
+
+Kafka 本身，并不像 RocketMQ 一样，提供顺序性的消息。所以，提供的方案，都是相对有损的。如下：
+
+> 这里的顺序消息，我们更多指的是，单个 Partition 的消息，被顺序消费。
+
+- 方式一，Consumer ，对每个 Partition 内部单线程消费，单线程吞吐量太低，一般不会用这个。
+
+- 方式二，Consumer ，拉取到消息后，写到 N 个内存 queue，具有相同 key 的数据都到同一个内存 queue 。然后，对于 N 个线程，每个线程分别消费一个内存 queue 即可，这样就能保证顺序性。
+
+  > 这种方式，相当于对【方式一】的改进，将相同 Partition 的消息进一步拆分，保证相同 key 的数据消费是顺序的。
+  >
+  > 不过这种方式，消费进度的更新会比较麻烦。
+
+当然，实际情况也不太需要考虑消息的顺序性，基本没有业务需要。
+
+具体的代码实现，可以看看 [《芋道 Spring Boot 消息队列 Kafka 入门》](http://www.iocoder.cn/Spring-Boot/RabbitMQ/?vip)的[「10. 顺序消息」](https://svip.iocoder.cn/Kafka/Interview/#)小节。
+
+## 666. 彩蛋
+
+😈 略显仓促的一篇文章，后续会重新在梳理一下。如果胖友对 Kafka 有什么疑惑，一定要在星球里提出，我们一起在讨论和解答一波，然后整理到这篇文章中。
+
+同时，期待下厮大的 Kafka 新书。
+
+参考与推荐如下文章：
+
+- [《高并发面试必问：分布式消息系统 Kafka 简介》](https://blog.csdn.net/caisini_vc/article/details/48007297)
+
+- [《14 个最常见的 Kafka 面试题及答案》](https://blog.csdn.net/yjh314/article/details/77568580)
+
+  > 这篇博客，有点傻逼。。。。
+
+- [《你需要知道的 Kafka》](https://juejin.im/post/5b573eafe51d45198f5c80a4)
+
+- [《Kafka 内部网络框架模型分析》](https://blog.csdn.net/lizhitao/article/details/52332749)
+
+- [《再谈基于 Kafka 和 ZooKeeper 的分布式消息队列原理》](https://gitbook.cn/books/5bc446269a9adf54c7ccb8bc/index.html)
+
+- [《如何保证消息的可靠性传输？（如何处理消息丢失的问题）》](https://github.com/doocs/advanced-java/blob/master/docs/high-concurrency/how-to-ensure-the-reliable-transmission-of-messages.md)
\ No newline at end of file
diff --git a/面试题/12-精尽【缓存】面试题.assets/01.png b/面试题/12-精尽【缓存】面试题.assets/01.png
new file mode 100644
index 0000000..30afad8
Binary files /dev/null and b/面试题/12-精尽【缓存】面试题.assets/01.png differ
diff --git a/面试题/12-精尽【缓存】面试题.assets/02.png b/面试题/12-精尽【缓存】面试题.assets/02.png
new file mode 100644
index 0000000..3a4e5e8
Binary files /dev/null and b/面试题/12-精尽【缓存】面试题.assets/02.png differ
diff --git a/面试题/12-精尽【缓存】面试题.assets/03.png b/面试题/12-精尽【缓存】面试题.assets/03.png
new file mode 100644
index 0000000..3989cca
Binary files /dev/null and b/面试题/12-精尽【缓存】面试题.assets/03.png differ
diff --git a/面试题/12-精尽【缓存】面试题.assets/f434927790ae53b4fa955ecd9952f787.png b/面试题/12-精尽【缓存】面试题.assets/f434927790ae53b4fa955ecd9952f787.png
new file mode 100644
index 0000000..9908f86
Binary files /dev/null and b/面试题/12-精尽【缓存】面试题.assets/f434927790ae53b4fa955ecd9952f787.png differ
diff --git a/面试题/12-精尽【缓存】面试题.md b/面试题/12-精尽【缓存】面试题.md
new file mode 100644
index 0000000..a861ac7
--- /dev/null
+++ b/面试题/12-精尽【缓存】面试题.md
@@ -0,0 +1,487 @@
+# 精尽【缓存】面试题「最新更新时间：2024-02」
+
+以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。
+
+如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的【缓存】面试题的大保健。
+
+而题目的难度，艿艿尽量按照从容易到困难的顺序，逐步下去。
+
+另外，本文只分享通用的【缓存】的面试题，关于 Redis、MemCache 会单独分享。
+
+再另外，本文【缓存】指的更多的是分布式缓存服务，而不是 HTTP 缓存等等。
+
+再再另外，强烈推荐购买 [《Redis 开发与运维》](https://u.jd.com/lDNJa9) ，真心不错，可以完完整整 Redis 。
+
+## 什么是缓存？
+
+> 艿艿：这个问题，理解即可。
+
+缓存，就是数据交换的缓冲区，针对服务对象的不同（本质就是不同的硬件）都可以构建缓存。
+
+目的是，**把读写速度【慢】的介质的数据保存在读写速度【快】的介质中，从而提高读写速度，减少时间消耗**。例如：
+
+- CPU 高速缓存 ：高速缓存的读写速度远高于内存。
+  - CPU 读数据时，如果在高速缓存中找到所需数据，就不需要读内存
+  - CPU 写数据时，先写到高速缓存，再回写到内存。
+- 磁盘缓存：磁盘缓存其实就把常用的磁盘数据保存在内存中，内存读写速度也是远高于磁盘的。
+  - 读数据，时从内存读取。
+  - 写数据时，可先写到内存，定时或定量回写到磁盘，或者是同步回写。
+
+在 [《CPU 内存访问速度，磁盘和网络速度，所有人都应该知道的数字》](https://www.cnblogs.com/liqiu/p/3211746.html) 中，胖友可以更好的理解不同介质的速度。
+
+## 为什么要用缓存？
+
+正如在 [「什么是缓存？」](https://svip.iocoder.cn/Cache/Interview/#) 问题中所看到的，使用缓存的目的，就是提升读写性能。而实际业务场景下，更多的是为了提升**读性能**，带来更好的性能，更高的并发量。
+
+日常业务中，我们使用比较多的数据库是 MySQL ，缓存是 Redis 。一起来看看，阿里云提供的性能规格：
+
+- Redis 性能规格，https://help.aliyun.com/document_detail/26350.html 。打底 8W QPS ，最高可达千万 QPS 。
+- MySQL 性能规格 https://help.aliyun.com/document_detail/53637.html 。打底 1.4K QPS ，最高 7W QPS 。
+
+艿艿自己，也分别进行了下 Redis 和 MySQL 的基准测试，感兴趣的胖友，可以看看，甚至自己上手玩玩。
+
+- [《性能测试 —— Redis 基准测试》](http://www.iocoder.cn/Performance-Testing/Redis-benchmark/?vip)
+- [《性能测试 —— MySQL 基准测试》](http://www.iocoder.cn/Performance-Testing/MySQL-benchmark/?vip)
+
+如此一比较，Redis 比 MySQL 的读写性能好很多。那么，我们将 MySQL 的热点数据，缓存到 Redis 中，提升读取性能，也减小 MySQL 的读取压力。例如说：
+
+- 论坛帖子的访问频率比较高，且要实时更新阅读量，使用 Redis 记录帖子的阅读量，可以提升性能和并发。
+- 商品信息，数据更新的频率不高，但是读取的频率很高，特别是热门商品。
+
+## 请说说有哪些缓存算法？是否能手写一下 LRU 代码的实现？
+
+🦅 **缓存算法**
+
+缓存算法，比较常见的是三种：
+
+- LRU（least recently used ，最近最少使用)
+- LFU（Least Frequently used ，最不经常使用)
+- FIFO（first in first out ，先进先出)
+
+完整的话，胖友可以看看 [《缓存、缓存算法和缓存框架简介》](http://blog.jobbole.com/30940/) 的 [「缓存算法」](https://svip.iocoder.cn/Cache/Interview/#) 部分。
+
+🦅 **手写 LRU 代码的实现**
+
+手写 LRU 代码的实现，有多种方式。其中，最简单的是基于 LinkedHashMap 来实现，代码如下：
+
+```
+class LRUCache<K, V> extends LinkedHashMap<K, V> {
+    private final int CACHE_SIZE;
+
+    /**
+     * 传递进来最多能缓存多少数据
+     *
+     * @param cacheSize 缓存大小
+     */
+    public LRUCache(int cacheSize) {
+        // true 表示让 LinkedHashMap 按照访问顺序来进行排序，最近访问的放在头部，最老访问的放在尾部。
+        super((int) Math.ceil(cacheSize / 0.75) + 1, 0.75f, true);
+        CACHE_SIZE = cacheSize;
+    }
+
+    @Override
+    protected boolean removeEldestEntry(Map.Entry<K, V> eldest) {
+        // 当 map 中的数据量大于指定的缓存个数的时候，就自动删除最老的数据。
+        return size() > CACHE_SIZE;
+    }
+
+}
+```
+
+其它更复杂，更能体现个人编码能力的 LRU 实现方式，可以看看如下两篇文章：
+
+- [《动手实现一个 LRU Cache》](https://crossoverjie.top/2018/04/07/algorithm/LRU-cache/)
+- [《缓存、缓存算法和缓存框架简介》](http://blog.jobbole.com/30940/) 文末，并且还提供了 FIFO、LFU 的代码实现。
+
+## 常见的常见的缓存工具和框架有哪些？
+
+在 Java 后端开发中，常见的缓存工具和框架列举如下：
+
+- 本地缓存：Guava LocalCache、Ehcache、Caffeine 。
+  - Ehcache 的功能更加丰富，Caffeine 的性能要比 Guava LocalCache 好。
+- 分布式缓存：Redis、Memcached、Tair 。
+  - Redis 最为主流和常用。
+
+## 用了缓存之后，有哪些常见问题？
+
+常见的问题，可列举如下：
+
+- 写入问题
+  - 缓存何时**写入**？并且写时如何避免并发重复写入？
+  - 缓存如何**失效**？
+  - 缓存和 DB 的**一致性**如何保证？
+- 经典三连问
+  - 如何避免缓存**穿透**的问题？
+  - 如何避免缓存**击穿**的问题？
+  - 如果避免缓存**雪崩**的问题？
+
+> 艿艿：重点可以去“记”加粗的六个词。
+
+下面，我们会对每个问题，逐步解析。
+
+## 当查询缓存报错，怎么提高可用性？
+
+缓存可以极大的提高查询性能，但是缓存数据丢失和缓存不可用不能影响应用的正常工作。
+
+因此，一般情况下，如果缓存出现异常，需要手动捕获这个异常，并且记录日志，并且从数据库查询数据返回给用户，而不应该导致业务不可用。
+
+当然，这样做可能会带来缓存雪崩的问题。具体怎么解决，可以看看本文 [「如何避免缓存”雪崩”的问题？」](https://svip.iocoder.cn/Cache/Interview/#) 问题。
+
+## 如果避免缓存”穿透”的问题？
+
+🦅 **缓存穿透**
+
+缓存穿透，是指查询一个一定**不存在**的数据，由于缓存是不命中时被动写，并且处于容错考虑，如果从 DB 查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到 DB 去查询，失去了缓存的意义。
+
+> 被动写：当从缓存中查不到数据时，然后从数据库查询到该数据，写入该数据到缓存中。
+
+在流量大时，可能 DB 就挂掉了，要是有人利用不存在的 key 频繁攻击我们的应用，这就是漏洞。如下图：[![缓存穿透](12-精尽【缓存】面试题.assets/01.png)](http://static.iocoder.cn/images/Cache/2019-11-21/01.png)缓存穿透
+
+- 在 [「为什么要用缓存？」](https://svip.iocoder.cn/Cache/Interview/#) 中，我们已经看到，MySQL 的性能是远不如 Redis 的，如果大量的请求直接打到 MySQL ，则会直接打挂 MySQL 。
+- 当然，缓存穿透不一定是攻击，也可能是我们自己程序写的问题，疯狂读取不存在的数据，又或者“无脑”的爬虫，顺序爬取数据。
+- 另外，一定要注意，**缓存穿透**，指的是查询一个**不存在**的数据，很容器和我们要讲到的**缓存击穿**搞混淆。
+
+🦅 **如何解决**
+
+有两种方案可以解决：
+
+1）方案一，缓存空对象。
+
+当从 DB 查询数据为空，我们仍然将这个空结果进行缓存，具体的值需要使用**特殊的标识**，能和真正缓存的数据区分开。另外，需要设置较短的过期时间，一般建议不要超过 5 分钟。
+
+> 为什么要较短的过期时间？因为缓存久没有意义，也浪费缓存的内存。
+
+2）方案二，BloomFilter 布隆过滤器。
+
+在缓存服务的基础上，构建 BloomFilter 数据结构，在 BloomFilter 中存储对应的 KEY 是否存在，如果存在，说明该 KEY 对应的值**不为空**。那么整个逻辑的如下：
+
+- 1、根据 KEY 查询【BloomFilter 缓存】。如果不存在对应的值，直接返回；如果存在，继续向下执行。【后续的流程，就是标准的流程】
+- 2、根据 KEY 查询在【数据缓存】的值。如果存在值，直接返回；如果不存在值，继续向下执行。
+- 3、查询 DB 对应的值，如果存在，则更新到缓存，并返回该值。
+
+可能有胖友不是很了解 BloomFilter 布隆过滤器，会有疑惑，为什么 BloomFilter 不存储 KEY 是不存在的情况（就是我们方案二反过来）？
+
+- BloomFilter 存在误判。简单来说，**存在的不一定存在，不存在的一定不存在**。这样就会导致，一个存在的 KEY 被误判成不存在。
+- 同时，BloomFilter 不允许删除。例如说，一个 KEY 一开始是不存在的，后来数据新增了，但是 BloomFilter 不允许删除的特点，就会导致一直会被判断成不存在。
+
+当然，使用 BloomFilter 布隆过滤器的话，需要提前将已存在的 KEY ，初始化存储到【BloomFilter 缓存】中。
+
+🦅 **选择**
+
+这两个方案，各有其优缺点。
+
+|          | 缓存空对象                                          | BloomFilter 布隆过滤器                    |
+| :------- | :-------------------------------------------------- | :---------------------------------------- |
+| 适用场景 | 1、数据命中不高 2、保证一致性                       | 1、数据命中不高 2、数据相对固定、实时性低 |
+| 维护成本 | 1、代码维护简单 2、需要过多的缓存空间 3、数据不一致 | 1、代码维护复杂 2、缓存空间占用小         |
+
+实际情况下，使用方案二比较多。因为，相比方案一来说，更加节省内容，对缓存的负荷更小。
+
+注意，常用的缓存 Redis 默认不支持 BloomFilter 数据结构。具体怎么解决，参考如下文章：
+
+- [RedisBloom](https://github.com/RedisBloom/RedisBloom)
+
+  > Redis 4.0 引入 Module 机制，支持 Server 自定义拓展。而 RedisBloom ，就是 Redis BloomFilter 的拓展。
+
+- [Redis-Lua-scaling-bloom-filter](https://github.com/erikdubbelboer/Redis-Lua-scaling-bloom-filter)
+
+  > Lua 脚本，实现 BloomFilter 的功能。
+
+- [Redisson BloomFilter](https://github.com/redisson/redisson/wiki/6.-分布式对象#68-布隆过滤器bloom-filter)
+
+  > Java Redis 库，实现 BloomFilter 的功能。
+
+- 其它文章
+
+  - [《Google Guava之BloomFilter 源码分析及基于 Redis 的重构》](https://segmentfault.com/a/1190000012620152)
+  - [《基于 Redis 的 BloomFilter 实现》](https://segmentfault.com/a/1190000017370384)
+
+> 艿艿的遐想：因为 BloomFilter 布隆过滤器存在的误判的情况，如果最后去 DB 查询不到数据的情况，是不是可以结合方案一，缓存空对象到【BloomFilter 缓存】中。后来想想，必要性不大，因为 BloomFilter 布隆过滤器误判率很低，没必要把方案复杂化，大道至简。
+
+------
+
+另外，推荐看下 [《Redis架构之防雪崩设计：网站不宕机背后的兵法》](https://mp.weixin.qq.com/s/TBCEwLVAXdsTszRVpXhVug) 文章的 [「一、缓存穿透预防及优化」](https://svip.iocoder.cn/Cache/Interview/#) ，大神解释的更好，且提供相应的图和伪代码。
+
+## 如何避免缓存”雪崩”的问题？
+
+🦅 **缓存雪崩**
+
+缓存雪崩，是指缓存由于某些原因无法提供服务( 例如，缓存挂掉了 )，所有请求全部达到 DB 中，导致 DB 负荷大增，最终挂掉的情况。
+
+🦅 **如何解决**
+
+预防和解决缓存雪崩的问题，可以从以下**多个方面进行共同着手**。
+
+1）缓存高可用
+
+通过搭建缓存的高可用，避免缓存挂掉导致无法提供服务的情况，从而降低出现缓存雪崩的情况。
+
+假设我们使用 Redis 作为缓存，则可以使用 Redis Sentinel 或 Redis Cluster 实现高可用。
+
+2）本地缓存
+
+如果使用本地缓存时，即使分布式缓存挂了，也可以将 DB 查询到的结果缓存到本地，避免后续请求全部到达 DB 中。
+
+当然，引入本地缓存也会有相应的问题，例如说：
+
+- 本地缓存的实时性怎么保证？
+  - 方案一，可以引入消息队列。在数据更新时，发布数据更新的消息；而进程中有相应的消费者消费该消息，从而更新本地缓存。
+  - 方案二，设置较短的过期时间，请求时从 DB 重新拉取。
+  - 方案三，使用 [「如果避免缓存”击穿”的问题？」](https://svip.iocoder.cn/Cache/Interview/#) 问题的【方案二】，手动过期。
+- 每个进程可能会本地缓存相同的数据，导致数据浪费？
+  - 方案一，需要配置本地缓存的过期策略和缓存数量上限。
+
+> 艿艿：上述的几个方案写的有点笼统，如果有不理解的地方，请在星球给艿艿留言。
+
+如果我们使用 JVM ，则可以使用 Ehcache、Guava Cache 实现本地缓存的功能。
+
+3）请求 DB 限流
+
+通过限制 DB 的每秒请求数，避免把 DB 也打挂了。这样至少能有两个好处：
+
+1. 可能有一部分用户，还可以使用，系统还没死透。
+2. 未来缓存服务恢复后，系统立即就已经恢复，无需再处理 DB 也挂掉的情况。
+
+当然，被限流的请求，我们最好也要有相应的处理，走【服务降级】，提供一些默认的值，或者友情提示，甚至空白的值也行。
+
+如果我们使用 Java ，则可以使用 Guava RateLimiter、Sentinel、Hystrix 实现限流的功能。
+
+4）提前演练
+
+在项目上线前，演练缓存宕掉后，应用以及后端的负载情况以及可能出现的问题，在此基础上做一些预案设定。
+
+------
+
+另外，推荐看下 [《Redis架构之防雪崩设计：网站不宕机背后的兵法》](https://mp.weixin.qq.com/s/TBCEwLVAXdsTszRVpXhVug) 文章的 [「二、缓存雪崩问题优化」](https://svip.iocoder.cn/Cache/Interview/#) ，大神解释的更好，且提供相应的图和伪代码。
+
+## 如果避免缓存”击穿”的问题？
+
+🦅 **缓存击穿**
+
+缓存击穿，是指某个**极度“热点”**数据在某个时间点过期时，恰好在这个时间点对这个 KEY 有大量的并发请求过来，这些请求发现缓存过期一般都会从 DB 加载数据并回设到缓存，但是这个时候大并发的请求可能会瞬间 DB 压垮。
+
+- 对于一些设置了过期时间的 KEY ，如果这些 KEY 可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑这个问题。
+- 区别：
+  - 和缓存“雪崩“”的区别在于，前者针对某一 KEY 缓存，后者则是很多 KEY 。
+  - 和缓存“穿透“”的区别在于，这个 KEY 是真实存在对应的值的。
+
+🦅 **如何解决**
+
+有两种方案可以解决：
+
+1）方案一，使用互斥锁。
+
+请求发现缓存不存在后，去查询 DB 前，使用分布式锁，保证有且只有一个线程去查询 DB ，并更新到缓存。流程如下：
+
+- 1、获取分布式锁，直到成功或超时。如果超时，则抛出异常，返回。如果成功，继续向下执行。
+- 2、获取缓存。如果存在值，则直接返回；如果不存在，则继续往下执行。😈 因为，获得到锁，可能已经被“那个”线程去查询过 DB ，并更新到缓存中了。
+- 3、查询 DB ，并更新到缓存中，返回值。
+
+2）方案二，手动过期。
+
+缓存上从不设置过期时间，功能上将过期时间存在 KEY 对应的 VALUE 里。流程如下：
+
+- 1、获取缓存。通过 VALUE 的过期时间，判断是否过期。如果未过期，则直接返回；如果已过期，继续往下执行。
+- 2、通过一个后台的异步线程进行缓存的构建，也就是“手动”过期。通过后台的异步线程，保证有且只有一个线程去查询 DB。
+- 3、同时，虽然 VALUE 已经过期，还是直接返回。通过这样的方式，保证服务的可用性，虽然损失了一定的时效性。
+
+🦅 **选择**
+
+这两个方案，各有其优缺点。
+
+|      | 使用互斥锁                          | 手动过期                  |
+| :--- | :---------------------------------- | :------------------------ |
+| 优点 | 1、思路简单 2、保证一致性           | 1、性价最佳，用户无需等待 |
+| 缺点 | 1、代码复杂度增大 2、存在死锁的风险 | 1、无法保证缓存一致性     |
+
+具体使用哪一种方案，胖友可以根据自己的业务场景去做选择。
+
+- 有一点要注意，上述的两个方案，都是建立在**极度“热点”**数据存在的情况，所以实际场景下，需要结合 [「如果避免缓存”穿透”的问题？」](https://svip.iocoder.cn/Cache/Interview/#) 的方案，一起使用。
+
+------
+
+另外，推荐看下 [《Redis 架构之防雪崩设计：网站不宕机背后的兵法》](https://mp.weixin.qq.com/s/TBCEwLVAXdsTszRVpXhVug) 文章的 [「三、缓存热点 key 重建优化」](https://svip.iocoder.cn/Cache/Interview/#) ，大神解释的更好，且提供相应的图和伪代码。
+
+## 缓存和 DB 的一致性如何保证？
+
+🦅 **产生原因**
+
+主要有两种情况，会导致缓存和 DB 的一致性问题：
+
+1. 并发的场景下，导致读取老的 DB 数据，更新到缓存中。
+
+   > 这里，主要指的是，更新 DB 数据之前，先删除 Cache 的数据。在低并发量下没什么问题，但是在高并发下，就会存在问题。在(删除 Cache 的数据, 和更新 DB 数据)时间之间，恰好有一个请求，我们如果使用**被动读**，因为此时 DB 数据还是老的，又会将老的数据写入到 Cache 中。
+
+2. 缓存和 DB 的操作，不在一个事务中，可能只有一个 DB 操作成功，而另一个 Cache 操作失败，导致不一致。
+
+当然，有一点我们要注意，缓存和 DB 的一致性，我们指的更多的是最终一致性。我们使用缓存只要是提高读操作的性能，真正在写操作的业务逻辑，还是以数据库为准。例如说，我们可能缓存用户钱包的余额在缓存中，在前端查询钱包余额时，读取缓存，在使用钱包余额时，读取数据库。
+
+🦅 **解决方案**
+
+在开始说解决方案之前，胖友先看看如下几篇文章，可能有一丢丢多，保持耐心。
+
+- 左耳朵耗子
+  - [《缓存更新的套路》](https://coolshell.cn/articles/17416.html)
+- 沈剑
+  - [《缓存架构设计细节二三事》](https://www.w3cschool.cn/architectroad/architectroad-cache-architecture-design.html)
+  - [《缓存与数据库一致性优化》](https://www.w3cschool.cn/architectroad/architectroad-consistency-of-cache-with-database.html) 这篇，我觉得写的方案不太可行。
+
+下面，我们就来看看几种方案。当然无论哪种方案，比较重要的就是解决两个问题：
+
+- 1、将缓存可能存在的并行写，实现串行写。
+
+  > 注意，这里指的是缓存的并行写。在被动读中，如果缓存不存在，也存在写。
+
+- 2、实现数据的最终一致性。
+
+1）先淘汰缓存，再写数据库
+
+因为先淘汰缓存，所以数据的最终一致性是可以得到有效的保证的。为什么呢？先淘汰缓存，即使写数据库发生异常，也就是下次缓存读取时，多读取一次数据库。
+
+但是，这种方案会存在缓存和 DB 的数据会不一致的情况，[《缓存与数据库一致性优化》](https://www.w3cschool.cn/architectroad/architectroad-consistency-of-cache-with-database.html) 已经说了。
+
+那么，我们需要解决缓存并行写，实现串行写。比较简单的方式，引入分布式锁。
+
+- 在写请求时，先淘汰缓存之前，先获取该分布式锁。
+- 在读请求时，发现缓存不存在时，先获取分布式锁。
+
+这样，缓存的并行写就成功的变成串行写落。实际上，就是 [「如果避免缓存”击穿”的问题？」](https://svip.iocoder.cn/Cache/Interview/#) 的【方案一】互斥锁的加强版。
+
+整体执行，如下草图：
+
+> 艿艿：临时手绘，不要打我。字很丑，哈哈哈哈。
+
+[![草图](12-精尽【缓存】面试题.assets/02.png)](http://static.iocoder.cn/images/Cache/2019-11-21/02.png)草图
+
+- 写请求时，是否主动更新缓存，根据自己业务的需要，是否有，都没问题。
+
+2）先写数据库，再更新缓存
+
+按照“先写数据库，再更新缓存”，我们要保证 DB 和缓存的操作，能够在“同一个事务”中，从而实现最终一致性。
+
+**基于定时任务来实现**
+
+- 首先，写入数据库。
+- 然后，在写入数据库所在的事务中，插入一条记录到任务表。该记录会存储需要更新的缓存 KEY 和 VALUE 。
+- 【异步】最后，定时任务每秒扫描任务表，更新到缓存中，之后删除该记录。
+
+**基于消息队列来实现**
+
+- 首先，写入数据库。
+- 然后，发送带有缓存 KEY 和 VALUE 的事务消息。此时，需要有支持事务消息特性的消息队列，或者我们自己封装消息队列，支持事务消息。
+- 【异步】最后，消费者消费该消息，更新到缓存中。
+
+这两种方式，可以进一步优化，可以先尝试更新缓存，如果失败，则插入任务表，或者事务消息。
+
+另外，极端情况下，如果并发写执行时，先更新成功 DB 的，结果后更新缓存，如下图所示：[![草图](12-精尽【缓存】面试题.assets/03.png)](http://static.iocoder.cn/images/Cache/2019-11-21/03.png)草图
+
+> 艿艿：灵魂画手，哈哈哈哈。
+
+- 理论来说，希望的更新缓存顺序是，线程 1 快于线程 2 ，但是实际线程1 晚于线程 2 ，导致数据不一致。
+- 可能胖友会说，图中不是基于定时任务或消息队列来实现异步更新缓存啊？答案是一直的，如果网络抖动，导致【插入任务表，或者事务消息】的顺序不一致。
+- 那么怎么解决呢？需要做如下三件事情：
+  - 1、在缓存值中，拼接上数据版本号或者时间戳。例如说：`value = {value: 原值, version: xxx}` 。
+  - 2、在任务表的记录，或者事务消息中，增加上数据版本号或者时间戳的字段。
+  - 3、在定时任务或消息队列执行更新缓存时，先读取缓存，对比版本号或时间戳，大于才进行更新。😈 当然，此处也会有并发问题，所以还是得引入分布式锁或 CAS 操作。
+    - 关于 Redis 分布式锁，可以看看 [《精尽 Redis 面试题》](http://svip.iocoder.cn/Redis/Interview) 的 [「如何使用 Redis 实现分布式锁？」](https://svip.iocoder.cn/Cache/Interview/#) 问题。
+    - 关于 Redis CAS 操作，可以看看 [《精尽 Redis 面试题》](http://svip.iocoder.cn/Redis/Interview) 的 [「什么是 Redis 事务？」](https://svip.iocoder.cn/Cache/Interview/#) 问题。
+
+3）基于数据库的 binlog 日志
+
+> 艿艿：如下内容，引用自 [《技术专题讨论第五期：论系统架构设计中缓存的重要性》](http://www.spring4all.com/question/177) 文章，超哥对这个问题的回答。
+
+[![binlog 方案](12-精尽【缓存】面试题.assets/f434927790ae53b4fa955ecd9952f787.png)](http://static.iocoder.cn/f434927790ae53b4fa955ecd9952f787)binlog 方案
+
+- 应用直接写数据到数据库中。
+- 数据库更新binlog日志。
+- 利用Canal中间件读取binlog日志。
+- Canal借助于限流组件按频率将数据发到MQ中。
+- 应用监控MQ通道，将MQ的数据更新到Redis缓存中。
+
+可以看到这种方案对研发人员来说比较轻量，不用关心缓存层面，而且这个方案虽然比较重，但是却容易形成统一的解决方案。
+
+------
+
+当然，以上种种方案，各有其复杂性，如果胖友心里没底，还是仅仅使用如下任一方案：
+
+- “**先淘汰缓存，再写数据库**”的方案，并且无需引入分布式锁。
+
+  > 沈剑大佬，比较支持这种方案，见 [《缓存架构设计细节二三事》](https://www.w3cschool.cn/architectroad/architectroad-cache-architecture-design.html) 。
+
+- “**先写数据库，再更新缓存**”的方案，并且无需引入定时任务或者消息队列。
+
+  > 左耳朵耗子，比较支持这种方案，[《缓存更新的套路》](https://coolshell.cn/articles/17416.html)。
+
+原因如下：
+
+> FROM 基友老梁的总结
+>
+> 使用缓存过程中，经常会遇到缓存数据的不一致性和脏读现象。一般情况下，采取缓存双淘汰机制，在更新数据库的**前**淘汰缓存。此外，设定超时时间，例如三十分钟。
+>
+> **极端场景下，即使有脏数据进入缓存，这个脏数据也最存在一段时间后自动销毁。**
+
+- 重点，是最后一句话哟。
+- 真的，和几个朋友沟通了下，真的出现不一致的情况，靠缓存过期后，重新从 DB 中读取即可。
+
+另外，在 DB 主从架构下，方案会更加复杂。详细可以看看 [《主从 DB 与 cache 一致性优化》](https://www.w3cschool.cn/architectroad/architectroad-consistency-of-cache-with-master-and-slave-database.html) 。
+
+> 艿艿：这是一道相对复杂的问题，重点在于理解为什么产生不一致的原因，然后针对这个原因去解决。
+
+## 什么是缓存预热？如何实现缓存预热？
+
+🦅 **缓存预热**
+
+在刚启动的缓存系统中，如果缓存中没有任何数据，如果依靠用户请求的方式重建缓存数据，那么对数据库的压力非常大，而且系统的性能开销也是巨大的。
+
+此时，最好的策略是启动时就把热点数据加载好。这样，用户请求时，直接读取的就是缓存的数据，而无需去读取 DB 重建缓存数据。
+
+举个例子，热门的或者推荐的商品，需要提前预热到缓存中。
+
+🦅 **如何实现**
+
+一般来说，有如下几种方式来实现：
+
+1. 数据量不大时，项目启动时，自动进行初始化。
+2. 写个修复数据脚本，手动执行该脚本。
+3. 写个管理界面，可以手动点击，预热对应的数据到缓存中。
+
+## 缓存数据的淘汰策略有哪些？
+
+除了缓存服务器自带的缓存**自动**失效策略之外，我们还可以根据具体的业务需求进行自定义的**“手动”**缓存淘汰，常见的策略有两种：
+
+- 1、定时去清理过期的缓存。
+- 2、当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。
+
+两者各有优劣，第一种的缺点是维护大量缓存的 key 是比较麻烦的，第二种的缺点就是每次用户请求过来都要判断缓存失效，逻辑相对比较复杂！
+具体用哪种方案，大家可以根据自己的应用场景来权衡。
+
+## 缓存如何存储 POJO 对象？
+
+实际场景下，缓存值可能是一个 POJO 对象，就需要考虑如何 POJO 对象存储的问题。目前有两种方式：
+
+- 方案一，将 POJO 对象
+
+  序列化
+
+  进行存储，适合 Redis 和 Memcached 。
+
+  - 可参考 [《Redis 序列化方式StringRedisSerializer、FastJsonRedisSerializer 和 KryoRedisSerializer》](https://blog.csdn.net/xiaolyuh123/article/details/78682200) 文章。
+  - 对于 POJO 对象比较大，可以考虑使用压缩算法，例如说 Snappy、zlib、GZip 等等。
+
+- 方案二，使用 Hash 数据结构，适合 Redis 。
+
+  - 可参考 [《Redis 之序列化 POJO》](https://my.oschina.net/yuyidi/blog/499951) 文章。
+
+不过对于 Redis 来说，大多数情况下，会考虑使用 JSON 序列化的方案。想要深入的胖友，可以看看如下两篇文章，很有趣：
+
+- [《Redis 内存压缩实战》](http://www.iocoder.cn/Fight/Redis-memory-compression-combat/?self) ，Redis HASH 数据结构，可以通过 ziplist 的编码方式，压缩数据。
+- [《redis-strings-vs-redis-hashes-to-represent-json-efficiency》](https://stackoverflow.com/questions/16375188/redis-strings-vs-redis-hashes-to-represent-json-efficiency) ，重点看 BMiner 的回答，提供了四种方案，非常有趣。
+
+## 666. 彩蛋
+
+参考与推荐如下文章：
+
+- _痕迹 [《缓存那些事（二）什么是缓存以及缓存的作用》](https://www.jianshu.com/p/118725df0db2)
+- yanglbme [《在项目中缓存是如何使用的？缓存如果使用不当会造成什么后果？》](https://github.com/doocs/advanced-java/blob/master/docs/high-concurrency/why-cache.md)
+- boothsun [《缓存常见问题》](https://www.zybuluo.com/boothsun/note/1078466)
+- 超神杀戮 [《缓存穿透与缓存雪崩》](https://www.cnblogs.com/fidelQuan/p/4543387.html)
\ No newline at end of file
diff --git a/面试题/13-Redis 面试题.assets/01.png b/面试题/13-Redis 面试题.assets/01.png
new file mode 100644
index 0000000..f8113c4
Binary files /dev/null and b/面试题/13-Redis 面试题.assets/01.png differ
diff --git a/面试题/13-Redis 面试题.md b/面试题/13-Redis 面试题.md
new file mode 100644
index 0000000..28491a5
--- /dev/null
+++ b/面试题/13-Redis 面试题.md	
@@ -0,0 +1,948 @@
+# 精尽 Redis 面试题「最新更新时间：2024-02」
+
+> 这个面试题是建立在胖友看过 [《精尽【缓存 】面试题》](http://svip.iocoder.cn/Cache/Interview) 。
+
+以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。
+
+如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的 Redis 面试题的大保健。
+
+而题目的难度，艿艿尽量按照从容易到困难的顺序，逐步下去。
+
+## 什么是 Redis ？
+
+[Redis](http://lib.csdn.net/base/redis) ，全称 Remote Dictionary Server ，是一个基于内存的高性能 Key-Value [数据库](http://lib.csdn.net/base/mysql)。
+
+Redis 已经成为互联网公司在缓存组件选择的唯一。例如说，在各种公有云上，缓存服务都是提供的 Redis。再例如说，招聘简历要求上，都会要求掌握 Redis 。
+
+## Redis 有什么优点？
+
+🦅 **1. 速度快**
+
+因为数据存在内存中，类似于 HashMap ，HashMap 的优势就是查找和操作的时间复杂度都是O (1) 。
+
+> Redis 本质上是一个 Key-Value 类型的内存数据库，很像 Memcached ，整个数据库统统加载在内存当中进行操作，定期通过异步操作把数据库数据 flush 到硬盘上进行保存。
+>
+> 因为是纯内存操作，Redis 的性能非常出色，每秒可以处理超过 10 万次读写操作，是已知性能最快的 Key-Value 数据库。
+
+- 如果我们查看在[阿里云销售的 Redis 规格](https://help.aliyun.com/document_detail/26350.html)，最低的也是 8W QPS 。
+
+🦅 **2. 支持丰富数据类型**
+
+支持 String ，List，Set，Sorted Set，Hash 五种基础的数据结构。
+
+> Redis 的出色之处不仅仅是性能，Redis 最大的魅力是支持保存多种数据结构，此外单个 Value 的最大限制是 1GB，不像 Memcached只能保存 1MB 的数据，因此 Redis 可以用来实现很多有用的功能。比方说：
+>
+> - 用他的 List 来做 FIFO 双向链表，实现一个轻量级的高性能消息队列服务。
+> - 用他的 Set 可以做高性能的 tag 系统等等。
+
+同时，在基础的数据结构之上，还提供 [Bitmap](http://redisdoc.com/bitmap/index.html)、[HyperLogLog](http://redisdoc.com/hyperloglog/index.html)、[GEO](http://redisdoc.com/geo/index.html) 等高级的数据结构。
+
+如果面试想要加分，胖友一定要去看看这些高级的数据结构，面试与日常开发，必备神器。
+
+🦅 **3. 丰富的特性**
+
+- 订阅发布 Pub / Sub 功能
+- Key 过期策略
+- 事务
+- 支持多个 DB
+- 计数
+- …
+
+并且在 Redis 5.0 增加了 Stream 功能，一个新的强大的支持多播的可持久化的消息队列，提供类似 Kafka 的功能。
+
+🦅 **4. 持久化存储**
+
+Redis 提供 RDB 和 AOF 两种数据的持久化存储方案，解决内存数据库最担心的万一 Redis 挂掉，数据会消失掉。
+
+🦅 **5、高可用**
+
+内置 Redis Sentinel ，提供高可用方案，实现主从故障自动转移。
+
+内置 Redis Cluster ，提供集群方案，实现基于槽的分片方案，从而支持更大的 Redis 规模。
+
+## Redis 有什么缺点？
+
+- 1、由于 Redis 是内存数据库，所以，单台机器，存储的数据量，跟机器本身的内存大小。虽然 Redis 本身有 Key 过期策略，但是还是需要提前预估和节约内存。如果内存增长过快，需要定期删除数据。
+
+  > 另外，可使用 Redis Cluster、Codis 等方案，对 Redis 进行分区，从单机 Redis 变成集群 Redis 。
+
+- 2、如果进行完整重同步，由于需要生成 RDB 文件，并进行传输，会占用主机的 CPU ，并会消耗现网的带宽。不过 Redis2.8 版本，已经有部分重同步的功能，但是还是有可能有完整重同步的。比如，新上线的备机。
+
+- 3、修改配置文件，进行重启，将硬盘中的数据加载进内存，时间比较久。在这个过程中，Redis 不能提供服务。
+
+## Redis 和 Memcached 的区别有哪些？
+
+> 艿艿：随着 Memcached 日渐没落，这个问题问的越来越少了。
+
+🦅 **1. Redis 支持复杂的数据结构**
+
+- Memcached 仅提供简单的字符串。
+- Redis 提供复杂的数据结构，丰富的数据操作。
+
+也因为 Redis 支持复杂的数据结构，Redis 即使晚于 Memcached 推出，却获得更多开发者的青睐。
+
+Redis 相比 Memcached 来说，拥有更多的数据结构，能支持更丰富的数据操作。如果需要缓存能够支持更复杂的结构和操作，Redis 会是不错的选择。
+
+🦅 **2. Redis 原生支持集群模式**
+
+- 在 Redis3.x 版本中，官方便能支持 Cluster 模式。
+- Memcached 没有原生的集群模式，需要依靠客户端来实现往集群中分片写入数据。
+
+🦅 **3. 性能对比**
+
+- Redis 只使用单核，而 Memcached 可以使用多核，所以平均每一个核上 Redis在存储小数据时比 Memcached 性能更高。
+- 在 100k 以上的数据中，Memcached 性能要高于 Redis 。虽然 Redis 最近也在存储大数据的性能上进行优化，但是比起 Memcached，还是稍有逊色。
+
+更多关于性能的对比，可以看看 [《Memcached 与 Redis 的关键性能指标比较》](https://www.jianshu.com/p/34f90813d7c9) 。
+
+🦅 **4. 内存管理机制不同**
+
+相比来说，Redis 的内存管理机制，会更加简单。
+
+- Redis 采用的是**包装**的 malloc/free ，使用时现场申请的方式。
+- Memcached 采用的是 Slab Allocation 机制管理内存，预分配的内存池的方式。
+
+如果对比两者的内存使用效率：
+
+- 简单的 Key-Value 存储的话，Memcached 的内存利用率更高，可以使用类似内存池。
+- 如果 Redis 采用 hash 结构来做 key-value 存储，由于其组合式的压缩， 其内存利用率会高于 Memcached 。
+
+🦅 **5. 网络 IO 模型**
+
+- Memcached 是多线程，非阻塞 IO 复用的网络模型，原型上接近 Nignx 。
+- Redis 使用单线程的 IO 复用模型，自己封装了一个简单的 AeEvent 事件处理框架，主要实现了 epoll ， kqueue 和 select ，更接近 Apache 早期的模式。
+
+🦅 **6. 持久化存储**
+
+- Memcached 不支持持久化存储，重启时，数据被清空。
+- Redis 支持持久化存储，重启时，可以恢复已持久化的数据。
+
+------
+
+也推荐阅读下 [《脚踏两只船的困惑 - Memcached 与 Redis》](https://www.imooc.com/article/23549) 。
+
+## 请说说 Redis 的线程模型？
+
+> 艿艿：这个是我从网络上找的资料，讲的灰常不错。**一般来说，回答道 Redis 是非阻塞 IO ，多路复用**。
+
+Redis 内部使用文件事件处理器 `file event handler`，这个文件事件处理器是单线程的，所以 Redis 才叫做单线程的模型。它采用 IO 多路复用机制同时监听多个 Socket，根据 Socket 上的事件来选择对应的事件处理器进行处理。
+
+文件事件处理器的结构包含 4 个部分：
+
+- 多个 Socket 。
+- IO 多路复用程序。
+- 文件事件分派器。
+- 事件处理器（连接应答处理器、命令请求处理器、命令回复处理器）。
+
+多个 Socket 可能会并发产生不同的操作，每个操作对应不同的文件事件，但是 IO 多路复用程序会监听多个 socket，会将 socket 产生的事件放入队列中排队，事件分派器每次从队列中取出一个事件，把该事件交给对应的事件处理器进行处理。
+
+来看客户端与 redis 的一次通信过程：
+
+[![redis-single-thread-model](13-Redis 面试题.assets/01.png)](http://static.iocoder.cn/images/Redis/2019_11_22/01.png)redis-single-thread-model
+
+- 客户端 Socket01 向 Redis 的 Server Socket 请求建立连接，此时 Server Socket 会产生一个 `AE_READABLE` 事件，IO 多路复用程序监听到 server socket 产生的事件后，将该事件压入队列中。文件事件分派器从队列中获取该事件，交给`连接应答处理器`。连接应答处理器会创建一个能与客户端通信的 Socket01，并将该 Socket01 的 `AE_READABLE` 事件与命令请求处理器关联。
+- 假设此时客户端发送了一个 `set key value` 请求，此时 Redis 中的 Socket01 会产生 `AE_READABLE` 事件，IO 多路复用程序将事件压入队列，此时事件分派器从队列中获取到该事件，由于前面 Socket01 的 `AE_READABLE` 事件已经与命令请求处理器关联，因此事件分派器将事件交给命令请求处理器来处理。命令请求处理器读取 Scket01 的 `set key value` 并在自己内存中完成 `set key value` 的设置。操作完成后，它会将 Scket01 的 `AE_WRITABLE` 事件与令回复处理器关联。
+- 如果此时客户端准备好接收返回结果了，那么 Redis 中的 Socket01 会产生一个 `AE_WRITABLE` 事件，同样压入队列中，事件分派器找到相关联的命令回复处理器，由命令回复处理器对 socket01 输入本次操作的一个结果，比如 `ok`，之后解除 Socket01 的 `AE_WRITABLE` 事件与命令回复处理器的关联。
+
+这样便完成了一次通信。😈 耐心理解一下，灰常重要。如果还是不能理解，可以在网络上搜一些资料，在理解理解。
+
+## 为什么 Redis 单线程模型也能效率这么高？
+
+- 1、C 语言实现。
+
+  > 我们都知道，C 语言的执行速度非常快。
+
+- 2、纯内存操作。
+
+  > Redis 为了达到最快的读写速度，将数据都读到内存中，并通过异步的方式将数据写入磁盘。所以 Redis 具有快速和数据持久化的特征。
+  >
+  > 如果不将数据放在内存中，磁盘 I/O 速度为严重影响 Redis 的性能。
+
+- 3、基于非阻塞的 IO 多路复用机制。
+
+- 4、单线程，避免了多线程的频繁上下文切换问题。
+
+  > Redis 利用队列技术，将并发访问变为串行访问，消除了传统数据库串行控制的开销。
+  >
+  > 实际上，Redis 4.0 开始，也开始有了一些异步线程，用于处理一些耗时操作。例如说，异步线程，实现[惰性删除](https://blog.csdn.net/zhanglong_4444/article/details/88350443)（解决大 KEY 删除，阻塞主线程）和异步 AOF （解决磁盘 IO 紧张时，fsync 执行一次很慢）等等。
+
+- 5、丰富的数据结构。
+
+  > Redis 全程使用 hash 结构，读取速度快，还有一些特殊的数据结构，对数据存储进行了优化。例如，压缩表，对短数据进行压缩存储；再再如，跳表，使用有序的数据结构加快读取的速度。
+  >
+  > 也因为 Redis 是单线程的，所以可以实现丰富的数据结构，无需考虑并发的问题。
+
+## Redis 是单线程的，如何提高多核 CPU 的利用率？
+
+可以在同一个服务器部署多个 Redis 的实例，并把他们当作不同的服务器来使用，在某些时候，无论如何一个服务器是不够的， 所以，如果你想使用多个 CPU ，你可以考虑一下分区。
+
+## Redis 有几种持久化方式？
+
+> 艿艿：这个问题有一丢丢长，耐心看完。
+>
+> 面试的时候，如果不能完整回答出来，也不会有大问题。重点，在于有条理，对 RDB 和 AOF 有理解。
+
+🦅 **持久化方式**
+
+Redis 提供了两种方式，实现数据的持久化到硬盘。
+
+- 1、【全量】RDB 持久化，是指在指定的时间间隔内将内存中的**数据集快照**写入磁盘。实际操作过程是，fork 一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。
+- 2、【增量】AOF持久化，以日志的形式记录服务器所处理的每一个**写、删除操作**，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。
+
+🦅 **RDB 优缺点**
+
+① 优点
+
+- 灵活设置备份频率和周期。你可能打算每个小时归档一次最近 24 小时的数据，同时还要每天归档一次最近 30 天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。
+- 非常适合冷备份，对于灾难恢复而言，RDB 是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。推荐，可以将这种完整的数据文件发送到一些远程的安全存储上去，比如说 Amazon 的 S3 云服务上去，在国内可以是阿里云的 OSS 分布式存储上。
+- 性能最大化。对于 Redis 的服务进程而言，在开始持久化时，它唯一需要做的只是 fork 出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行 IO 操作了。也就是说，RDB 对 Redis 对外提供的读写服务，影响非常小，可以让 Redis 保持高性能。
+- 恢复更快。相比于 AOF 机制，RDB 的恢复速度更更快，更适合恢复数据，特别是在数据集非常大的情况。
+
+② 缺点
+
+- 如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么 RDB 将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。
+
+  > 所以，RDB 实际场景下，需要和 AOF 一起使用。
+
+- 由于 RDB 是通过 fork 子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是 1 秒钟。
+
+  > 所以，RDB 建议在业务低估，例如在半夜执行。
+
+🦅 **AOF 优缺点**
+
+① 优点
+
+- 该机制可以带来更高的
+
+  数据安全性
+
+  ，即数据持久性。Redis 中提供了 3 种同步策略，即每秒同步、每修改(执行一个命令)同步和不同步。
+
+  - 事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。
+  - 而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。
+  - 至于不同步，无需多言，我想大家都能正确的理解它。
+
+- 由于该机制对日志文件的写入操作采用的是
+
+   
+
+  append
+
+   
+
+  模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。
+
+  - 因为以 append-only 模式写入，所以没有任何磁盘寻址的开销，写入性能非常高。
+  - 另外，如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在 Redis 下一次启动之前，我们可以通过 redis-check-aof 工具来帮助我们解决数据一致性的问题。
+
+- 如果 AOF 日志过大，Redis 可以自动启用 **rewrite** 机制。即使出现后台重写操作，也不会影响客户端的读写。因为在 rewrite log 的时候，会对其中的指令进行压缩，创建出一份需要恢复数据的最小日志出来。再创建新日志文件的时候，老的日志文件还是照常写入。当新的 merge 后的日志文件 ready 的时候，再交换新老日志文件即可。
+
+  > 注意，AOF **rewrite** 机制，和 RDB 一样，也需要 fork 出一次子进程，如果 Redis 内存比较大，可能会因为 fork 阻塞下主进程。
+
+- AOF 包含一个格式清晰、易于理解的日志文件用于记录所有的**修改操作**。事实上，我们也可以通过该文件完成数据的重建。
+
+② 缺点
+
+- 对于相同数量的数据集而言，AOF 文件通常要大于 RDB 文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
+- 根据同步策略的不同，AOF 在运行效率上往往会慢于 RDB 。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和 RDB 一样高效。
+- 以前 AOF 发生过 bug ，就是通过 AOF 记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。所以说，类似 AOF 这种较为复杂的基于命令日志/merge/回放的方式，比基于 RDB 每次持久化一份完整的数据快照文件的方式，更加脆弱一些，容易有 bug 。不过 AOF 就是为了避免 rewrite 过程导致的 bug ，因此每次 rewrite 并不是基于旧的指令日志进行 merge 的，而是基于当时内存中的数据进行指令的重新构建，这样健壮性会好很多。
+
+🦅 **如何选择**
+
+- 不要仅仅使用 RDB，因为那样会导致你丢失很多数据。
+
+- 也不要仅仅使用 AOF，因为那样有两个问题，第一，你通过 AOF 做冷备，没有 RDB 做冷备，来的恢复速度更快; 第二，RDB 每次简单粗暴生成数据快照，更加健壮，可以避免 AOF 这种复杂的备份和恢复机制的 bug 。
+
+- Redis 支持同时开启开启两种持久化方式，我们可以综合使用 AOF 和 RDB 两种持久化机制，用 AOF 来保证数据不丢失，作为数据恢复的第一选择; 用 RDB 来做不同程度的冷备，在 AOF 文件都丢失或损坏不可用的时候，还可以使用 RDB 来进行快速的数据恢复。
+
+  - 如果同时使用 RDB 和 AOF 两种持久化机制，那么在 Redis 重启的时候，会使用 **AOF** 来重新构建数据，因为 AOF 中的**数据更加完整**。
+
+    > 一般来说， 如果想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功能。如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失，那么你可以只使用 RDB 持久化。
+    >
+    > 有很多用户都只使用 AOF 持久化，但并不推荐这种方式：因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比AOF恢复的速度要快，除此之外，使用 RDB 还可以避免之前提到的 AOF 程序的 bug。
+
+在 Redis4.0 版本开始，允许你使用 RDB-AOF 混合持久化方式，详细可见 [《Redis4.0 之 RDB-AOF 混合持久化》](https://yq.aliyun.com/articles/193034) 。也因此，RDB 和 AOF 同时使用，是希望达到安全的持久化的推荐方式。
+
+------
+
+另外，RDB 和 AOF 涉及的知识点蛮多的，可以看看：
+
+- [《Redis 设计与实现 —— RDB》](https://redisbook.readthedocs.io/en/latest/internal/rdb.html)
+- [《Redis 设计与实现 —— AOF》](https://redisbook.readthedocs.io/en/latest/internal/aof.html)
+
+如下是老钱对这块的总结，可能更加适合面试的场景：
+
+- bgsave 做镜像全量持久化，AOF 做增量持久化。因为 bgsave 会耗费较长时间，不够实时，在停机的时候会导致大量丢失数据，所以需要 AOF 来配合使用。在 Redis 实例重启时，会使用 bgsave 持久化文件重新构建内存，再使用 AOF 重放近期的操作指令来实现完整恢复重启之前的状态。
+
+  > 和老钱沟通了下，最后一句重启恢复，使用的是 RDB-AOF 的混合方案。
+
+- 对方追问那如果突然机器掉电会怎样？取决于 AOF 日志 sync 属性的配置，如果不要求性能，在每条写指令时都 sync 一下磁盘，就不会丢失数据。但是在高性能的要求下每次都 sync 是不现实的，一般都使用定时 sync ，比如 1 秒 1 次，这个时候最多就会丢失 1 秒的数据。
+
+  > 实际上，极端情况下，是最多丢失 2 秒的数据。因为 AOF 线程，负责每秒执行一次 fsync 操作，操作完成后，记录最后同步时间。主线程，负责对比上次同步时间，如果超过 2 秒，阻塞等待成功。
+
+- 对方追问 bgsave 的原理是什么？你给出两个词汇就可以了，fork 和 cow 。fork 是指 Redis 通过创建子进程来进行 bgsave 操作。cow 指的是 copy on write ，子进程创建后，父子进程共享数据段，父进程继续提供读写服务，写脏的页面数据会逐渐和子进程分离开来。
+
+  > 艿艿：这里 bgsave 操作后，会产生 RDB 快照文件。
+
+为什么不建议在主 Redis 节点开启 RDB 功能呢？因为会带来一定时间的阻塞，特别是数据量大的时候。
+
+> 如下来自球友【jian】的回答，感恩~
+>
+> - 【重点】**子进程 fork 相关的阻塞：在 bgsave 的时候，Redis 主进程会 fork 一个子进程，利用操作系统的写时复制技术，这个子进程在拷贝父进程的时候理论上是很快的，因为并不需要全拷贝，比如主进程虽然占了 10G 内存，但子进程拷贝他可能只要 200 毫秒，我认为也就阻塞了 200 毫秒(此耗时基本跟主进程占用的内存是成正比的)，这个具体的时间可以通过统计项 info stats 里的 last_fork_usec 查看。**
+> - CPU 单线程相关的阻塞：Redis 主进程是单线程跑在单核 CPU 上的，如果显示绑定了CPU ，则子进程会与主进程共享一个 CPU ，而子进程进行持久化的时候是非常占CPU（强势 90%），因此这种情况也可能导致提供服务的主进程发生阻塞（因此如果需要持久化功能，不建议绑定CPU）。
+> - 内存相关的阻塞：虽然利用写时复制技术可以大大降低进程拷贝的内存消耗，但这也导致了父进程在处理写请求时需要维护修改的内存页，因此这部分内存过大的话（修改页数多或每页占空间大）也会导致父进程的写操作阻塞。（而不巧的是，Linux中TransparentHugePage 会将复制内存页面单位有 4K 变成 2M ，这对于 Redis 来说是比较不友好的，也是建议优化的，具体可百度之）
+> - 磁盘相关的阻塞：极端情况下，假设整个机器的内存已经所剩无几，触发了内存交换（SWAP），则整个 Redis的效率将会非常低下（显然这不仅仅针对 save/bgsave ），因此，关注系统的 io 情况，也是定位阻塞问题的一种方法。
+>
+> 艿艿后来又看了下这个答案，是 [《Redis 开发与运维》](https://u.jd.com/lDNJa9) 的「5.3 持久化 —— 问题定位于优化」小节。
+
+## Redis 有几种数据“过期”策略？
+
+Redis 的过期策略，就是指当 Redis 中缓存的 key 过期了，Redis 如何处理。
+
+Redis 提供了 3 种数据过期策略：
+
+- 被动删除：当读/写一个已经过期的 key 时，会触发惰性删除策略，直接删除掉这个过期 key 。
+- 主动删除：由于惰性删除策略无法保证冷数据被及时删掉，所以 Redis 会定期主动淘汰一批已过期的 key 。
+- 主动删除：当前已用内存超过 maxmemory 限定时，触发主动清理策略，即 [「数据“淘汰”策略」](https://svip.iocoder.cn/Redis/Interview/#) 。
+
+在 Redis 中，同时使用了上述 3 种策略，即它们**非互斥**的。
+
+想要进一步了解，可以看看 [《关于 Redis 数据过期策略》](https://www.cnblogs.com/chenpingzhao/p/5022467.html) 文章。
+
+## Redis 有哪几种数据“淘汰”策略？
+
+Redis 内存数据集大小上升到一定大小的时候，就会进行数据淘汰策略。
+
+Redis 提供了 6 种数据淘汰策略：
+
+1. volatile-lru
+2. volatile-ttl
+3. volatile-random
+4. allkeys-lru
+5. allkeys-random
+6. 【默认策略】no-enviction
+
+具体的**每种数据淘汰策略的定义**，和**如何选择讨论策略**，可见 [《Redis实战（二） 内存淘汰机制》](http://blog.720ui.com/2016/redis_action_02_maxmemory_policy/) 。
+
+在 Redis 4.0 后，基于 LFU（Least Frequently Used）最近最少使用算法，增加了 2 种淘汰策略：
+
+1. volatile-lfu
+2. allkeys-lfu
+
+🦅 **Redis LRU 算法**
+
+另外，Redis 的 LRU 算法，**并不是一个严格的 LRU 实现**。这意味着 Redis 不能选择最佳候选键来回收，也就是最久未被访问的那些键。相反，Redis 会尝试执行一个近似的 LRU 算法，通过采样一小部分键，然后在采样键中回收最适合(拥有最久未被访问时间)的那个。
+
+**Redis 没有使用真正实现严格的 LRU 算是的原因是，因为消耗更多的内存。然而对于使用 Redis 的应用来说，使用近似的 LRU 算法，事实上是等价的。**
+
+具体的可以看看如下文章：
+
+- [《想不到！面试官问我：Redis 内存满了怎么办？》](http://www.iocoder.cn/Fight/Cannot-think-of-The-interviewer-asked-me-what-if-Redis-runs-out-of-memory/?self)
+- [《使用 Redis 作为一个 LRU 缓存》](http://ifeve.com/lru-cache/)
+
+🦅 **MySQL 里有 2000w 数据，Redis 中只存 20w 的数据，如何保证 Redis 中的数据都是热点数据？**
+
+> 艿艿：这个是从网络上找到的一个神奇的问题，并且看了答案之后，觉得有点莫名的对不上。
+>
+> 所以，感觉这个问题的目的是，如何保证热点数据不要被淘汰。
+
+在 [「Redis 有哪几种数据“淘汰”策略？」](https://svip.iocoder.cn/Redis/Interview/#) 问题中，我们已经看到，“Redis 内存数据集大小上升到一定 maxmemory 的时候，就会进行数据淘汰策略。” 。
+
+那么，如果我们此时要保证热点数据不被淘汰，那么需要选择 volatile-lru 或 allkeys-lru 这两个基于 LRU 算法的淘汰策略。
+
+相比较来说，最终会选择 allkeys-lru 淘汰策略。原因是，如果我们的应用对缓存的访问符合幂律分布，也就是存在相对热点数据，或者我们不太清楚我们应用的缓存访问分布状况，我们可以选择 allkeys-lru 策略。如果在 Redis 4.0 版本，可以考虑使用 volatile-lfu ，更加符合“热”的概念，频率越高，代表越热。
+
+🦅 **Redis 回收进程如何工作的？**
+
+理解回收进程如何工作是非常重要的：
+
+- 一个客户端运行了新的写命令，添加了新的数据。
+- Redis 检查内存使用情况，如果大于 maxmemory 的限制, 则根据设定好的策略进行回收。
+- Redis 执行新命令。
+
+所以我们不断地穿越内存限制的边界，通过不断达到边界然后不断地回收回到边界以下（跌宕起伏）。
+
+## 如果有大量的 key 需要设置同一时间过期，一般需要注意什么？
+
+如果大量的 key 过期时间设置的过于集中，到过期的那个时间点，Redis可能会出现短暂的卡顿现象。
+
+一般需要在时间上加一个随机值，使得过期时间分散一些。
+
+------
+
+上次基友也碰到这个问题，请教了下，他的方案是调大 hz 参数，每次过期的 key 更多，从而最终达到避免一次过期过多。
+
+> 这个定期的频率，由配置文件中的 hz 参数决定，代表了一秒钟内，后台任务期望被调用的次数。Redis 3.0.0 中的默认值是 10 ，代表每秒钟调用 10 次后台任务。
+>
+> hz 调大将会提高 Redis 主动淘汰的频率，如果你的 Redis 存储中包含很多冷数据占用内存过大的话，可以考虑将这个值调大，但 Redis 作者建议这个值不要超过 100 。我们实际线上将这个值调大到 100 ，观察到 CPU 会增加 2% 左右，但对冷数据的内存释放速度确实有明显的提高（通过观察 keyspace 个数和 used_memory 大小）。
+
+## Redis 有哪些数据结构？
+
+如果你是 Redis 普通玩家，可能你的回答是如下五种数据结构：
+
+- 字符串 String
+- 字典Hash
+- 列表List
+- 集合Set
+- 有序集合 SortedSet
+
+如果你是 Redis 中级玩家，还需要加上下面几种数据结构：
+
+- HyperLogLog
+- Geo
+- Bitmap
+
+如果你是 Redis 高端玩家，你可能玩过 Redis Module ，可以再加上下面几种数据结构：
+
+- BloomFilter
+- RedisSearch
+- Redis-ML
+- JSON
+
+另外，在 Redis 5.0 增加了 Stream 功能，一个新的强大的支持多播的可持久化的消息队列，提供类似 Kafka 的功能。😈 默默跟面试官在装一波。
+
+## 聊聊 Redis 使用场景
+
+Redis 可用的场景非常之多：
+
+- 数据缓存
+- 会话缓存
+- 时效性数据
+- 访问频率
+- 计数器
+- 社交列表
+- 记录用户判定信息
+- 交集、并集和差集
+- 热门列表与排行榜
+- 最新动态
+- 消息队列
+- 分布式锁
+
+详细的介绍，可以看看如下文章：
+
+- [《聊聊 Redis 使用场景》](http://blog.720ui.com/2017/redis_core_use/)
+- [《Redis 应用场景及实例》](https://www.jianshu.com/p/af277c77b1c9)
+- [《Redis 常见的应用场景解析》](https://zhuanlan.zhihu.com/p/29665317)
+- [《Redis 和 Memcached 各有什么优缺点，主要的应用场景是什么样的？》](https://www.zhihu.com/question/19829601)
+
+## Redis 支持的 Java 客户端都有哪些？
+
+使用比较广泛的有三个 Java 客户端：
+
+- Redisson
+
+  > Redisson ，是一个高级的分布式协调 Redis 客服端，能帮助用户在分布式环境中轻松实现一些 Java 的对象 (Bloom filter, BitSet, Set, SetMultimap, ScoredSortedSet, SortedSet, Map, ConcurrentMap, List, ListMultimap, Queue, BlockingQueue, Deque, BlockingDeque, Semaphore, Lock, ReadWriteLock, AtomicLong, CountDownLatch, Publish / Subscribe, HyperLogLog)。
+
+- Jedis
+
+  > Jedis 是 Redis 的 Java 实现的客户端，其 API 提供了比较全面的 Redis 命令的支持。
+  >
+  > Redisson 实现了分布式和可扩展的 Java 数据结构，和 Jedis 相比，Jedis 功能较为简单。
+  >
+  > Redisson 的宗旨是促进使用者对 Redis 的关注分离，从而让使用者能够将精力更集中地放在处理业务逻辑上。
+
+- Lettuce
+
+  > Lettuce 是一个可伸缩线程安全的 Redis 客户端。多个线程可以共享同一个 RedisConnection 。它利用优秀 Netty NIO 框架来高效地管理多个连接。
+
+Redis 官方推荐使用 Redisson 或 Jedis 。
+
+Spring Boot 2.x 内置支持 Jedis 和 Lettuce 。一般情况下，建议：
+
+- 使用 Spring Data Redis ，提供了透明使用 Jedis 和 Lettuce 的封装。也就是说，大多数时候，我们可以通过配置使用 Jedis 或 Lettuce 进行 Redis 的操作，而上层使用 Spring Data Redis 提供的统一 API 。
+- 从目前来说，Jedis 会比 Lettuce 更加流行，并且更加稳定。虽然说 Jedis 有一段时间，不再进行更新，但是突然又开始更新，可能是诈尸了。
+- 如果想要更加丰富的特性，例如说分布式锁，布隆过滤器，可以考虑研究下 Redisson 。
+
+## 如何使用 Redis 实现分布式锁？
+
+Redis 实现分布式锁，需要考虑如下几个方面：
+
+- 1、正确的获得锁
+
+  > set 指令附带 nx 参数，保证有且只有一个进程获得到。
+
+- 2、正确的释放锁
+
+  > 使用 Lua 脚本，比对锁持有的是不是自己。如果是，则进行删除来释放。
+
+- 3、超时的自动释放锁
+
+  > set 指令附带 expire 参数，通过过期机制来实现超时释放。
+
+- 4、未获得到锁的等待机制
+
+  > sleep 或者基于 Redis 的订阅 Pub/Sub 机制。
+  >
+  > 一些业务场景，可能需要支持获得不到锁，直接返回 false ，不等待。
+
+- 5、【可选】锁的重入性
+
+  > 通过 ThreadLocal 记录是第几次获得相同的锁。
+  >
+  > 1）有且第一次计数为 1 && 获得锁时，才向 Redis 发起获得锁的操作。
+  > 2）有且计数为 0 && 释放锁时，才向 Redis 发起释放锁的操作。
+
+- 6、锁超时的处理
+
+  > 一般情况下，可以考虑告警 + 后台线程自动续锁的超时时间。通过这样的机制，保证有且仅有一个线程，正在持有锁。
+
+- 7、Redis 分布式锁丢失问题
+
+  > 具体看「方案二：Redlock」。
+
+下面，我们来详细说下每个方案。
+
+🦅 **方案一：set 指令**
+
+先拿 setnx 来争抢锁，抢到之后，再用 expire 给锁加一个过期时间防止锁忘记了释放。
+
+- 这时候对方会告诉你说你回答得不错，然后接着问如果在 setnx 之后执行 expire 之前进程意外 crash 或者要重启维护了，那会怎么样？
+- 这时候你要给予惊讶的反馈：唉，是喔，这个锁就永远得不到释放了。紧接着你需要抓一抓自己得脑袋，故作思考片刻，好像接下来的结果是你主动思考出来的，然后回答：我记得 set 指令有非常复杂的参数，这个应该是可以同时把 setnx 和 expire 合成一条指令来用的！对方这时会显露笑容，心里开始默念：摁，这小子还不错。
+
+所以，我们可以使用 **set** 指令，实现分布式锁。指令如下：
+
+```
+SET key value [EX seconds] [PX milliseconds] [NX|XX]
+```
+
+- 可以使用 `SET key value EX seconds NX` 命令，尝试获得锁。
+- 具体的实现，可以参考如下文章：
+  - [《精尽 Redisson 源码分析 —— 可重入分布式锁 ReentrantLock》](http://svip.iocoder.cn/Redisson/ReentrantLock/?self)
+  - [《Redis 分布式锁进化史解读 + 缺陷分析》](http://www.iocoder.cn/Fight/redisfen-bu-shi-suo-jin-hua-shi/?self)
+  - [《Redis 分布式锁的正确实现方式（Java 版）》](http://www.iocoder.cn/Fight/Correct-implementation-of-Redis-distributed-locks-by-Java/?self)
+
+🦅 **方案二：Redlock**
+
+set 指令的方案，适合用于在单机 Redis 节点的场景下，在多 Redis 节点的场景下，会存在分布式锁丢失的问题。所以，Redis 作者 Antirez 基于分布式环境下提出了一种更高级的分布式锁的实现方式：Redlock 。
+
+具体的源码解析，可以看看 [《精尽 Redisson 源码分析 —— 可靠分布式锁 RedLock》](http://svip.iocoder.cn/Redisson/RedLock/?self) 文章。
+
+具体的方案，胖友可以看看老友飞哥的两篇博客：
+
+- [《Redlock：Redis分布式锁最牛逼的实现》](https://mp.weixin.qq.com/s/JLEzNqQsx-Lec03eAsXFOQ)
+- [《Redisson 实现 Redis 分布式锁的 N 种姿势》](https://www.jianshu.com/p/f302aa345ca8)
+
+最近艿艿画了一个 Redisson 实现分布式锁的流程图，胖友可以点击[传送门](https://www.processon.com/view/link/5f4c871d079129356ec6f4d7)阅读。
+
+🦅 **对比 Zookeeper 分布式锁**
+
+- 从可靠性上来说，Zookeeper 分布式锁好于 Redis 分布式锁。
+- 从性能上来说，Redis 分布式锁好于 Zookeeper 分布式锁。
+
+所以，没有绝对的好坏，可以根据自己的业务来具体选择。如果想要更简单，甚至可以考虑基于 MySQL 行锁来实现分布式锁。
+
+## 如何使用 Redis 实现分布式限流？
+
+在 Spring Cloud Gateway 中，提供了 Redis 分布式限流器的实现，具体直接看艿艿写的 [《Spring-Cloud-Gateway 源码解析 —— 过滤器 (4.10) 之 RequestRateLimiterGatewayFilterFactory 请求限流》](http://www.iocoder.cn/Spring-Cloud-Gateway/filter-request-rate-limiter/) 的 [「5.3 Redis Lua 脚本」](https://svip.iocoder.cn/Redis/Interview/#) 部分。
+
+另外，Redisson 库中，也提供了 Redis 分布式限流的实现，不过需要使用 Pro 版本。
+
+🦅 **请用 Redis 和任意语言实现一段恶意登录保护的代码，限制 1 小时内每用户 Id 最多只能登录 5 次。**
+
+这个问题，关键点，就是每个用户，每 3600 秒，只能登陆 5 次。这么一想，其实就是一个如何使用 Redis 实现限流的问题。Redis 实现限流，一共有两种方案：
+
+- 使用 zset 实现滑动窗口限流。代码如下：
+
+  ```
+  public boolean isActionAllowed(String userId, String actionKey, int period,
+      int maxCount) {
+      String key = String.format("hist:%s:%s", userId, actionKey); // 使用用户编号 + 行为作为 KEY 。这样，我们就可以统计某个用户的操作行为。
+      long nowTs = System.currentTimeMillis(); // 获取当前时间。
+      Pipeline pipe = jedis.pipelined(); // pipeline 批量操作，提升效率。
+      pipe.multi(); // 此处启动了事务，可以保证指令的原子性。
+      pipe.zadd(key, nowTs, "" + nowTs); // zset 添加，key value score 要看下。
+      pipe.zremrangeByScore(key, 0, nowTs - (period * 1000)); // zremrangeByScore ，移除超过周期的 value 。
+  
+      Response<Long> count = pipe.zcard(key); // zcard ，计算 zset 的数量
+      pipe.expire(key, period + 1); // 设置过期。这里多 + 1 秒，为了防止网络延迟。
+      pipe.exec(); // pipeline 执行
+      pipe.close();
+  
+      return count.get() <= maxCount; // 是否超过最大次数。
+  }
+  ```
+
+  - 该实现会存在一个问题，可能一个无效的操作，也被记录到次数中。完美的话，可能需要基于 Lua 脚本实现。
+  - 另外，上述代码是每秒操作的时间，实际需要改成每 N 秒。比较简单，直接上手怼即可。
+
+- 使用 Lua 脚本，实现令牌桶限流算法。具体可以看看艿艿对 [《Spring-Cloud-Gateway 源码解析 —— 过滤器 (4.10) 之 RequestRateLimiterGatewayFilterFactory 请求限流》](http://www.iocoder.cn/Spring-Cloud-Gateway/filter-request-rate-limiter/?self) 的源码解析。
+
+- 使用 Lua 脚本，实现简单的滑动窗口。具体可以看看艿艿对 [《精尽 Redisson 源码分析 —— 限流器 RateLimiter》](http://svip.iocoder.cn/Redisson/RateLimiter/?self) 的源码解析。
+
+## 如何使用 Redis 实现消息队列？
+
+一般使用 list 结构作为队列，rpush 生产消息，lpop 消费消息。当 lpop 没有消息的时候，要适当 sleep 一会再重试。
+
+- 如果对方追问可不可以不用 sleep 呢？list 还有个指令叫 blpop ，在没有消息的时候，它会阻塞住直到消息到来。
+
+- 如果对方追问能不能生产一次消费多次呢？使用 pub / sub 主题订阅者模式，可以实现 1:N 的消息队列。
+
+- 如果对方追问 pub / sub 有什么缺点？在消费者下线的情况下，生产的消息会丢失，得使用专业的消息队列如 rabbitmq 等。
+
+  > 之前生产中，艿艿就碰到因为网络闪断，导致订阅的 pub/sub 消息丢失，导致 JVM 应用的数据字典和系统参数等缓存未刷新，业务受到影响。所以，最好还是使用专业的消息队列的订阅功能（广播消费）。
+
+- 如果对方追问 redis 如何实现延时队列？我估计现在你很想把面试官一棒打死如果你手上有一根棒球棍的话，怎么问的这么详细。但是你很克制，然后神态自若的回答道：使用 sortedset ，拿时间戳作为 score ，消息内容作为 key 调用 zadd 来生产消息，消费者用 zrangebyscore 指令获取 N 秒之前的数据轮询进行处理。
+
+  > 可能很多胖友会觉得抽象，可以看看 [《Redis 学习笔记之延时队列》](https://cloud.tencent.com/developer/article/1401122) 。面试中，能回答到 Redis zset 实现延迟队列，还是蛮加分的。
+
+到这里，面试官暗地里已经对你竖起了大拇指。但是他不知道的是此刻你却竖起了中指，在椅子背后。
+
+当然，实际上 Redis 真的真的真的不推荐作为消息队列使用，它最多只是消息队列的存储层，上层的逻辑，还需要做大量的封装和支持。
+
+另外，在 Redis 5.0 增加了 Stream 功能，一个新的强大的支持多播的可持久化的消息队列，提供类似 Kafka 的功能。
+
+## 什么是 Redis Pipelining ？
+
+一次请求/响应服务器能实现处理新的请求即使旧的请求还未被响应。这样就可以将多个命令发送到服务器，而不用等待回复，最后在一个步骤中读取该答复。
+
+> 注意，Redis Pipelining 是 Redis Client 实现的功能，而不是 Redis Server 提供的特性。假设我们有 3 个请求进行下举例子。
+>
+> - 未使用 Pipeline 时，那么整个执行的顺序是，req1->resp1->req2->resp2->req3->resp3 。
+> - 在使用 Pipeline 时，那么整个执行的顺序是，[req1,req2,req3] 一起发给 Redis Server ，而 Redis Server 收到请求后，一个一个请求进行执行，然后响应，不会进行什么特殊处理。而 Client 在收到 resp1,resp2,resp3 后，进行响应给业务上层。
+>
+> 所以，Pipeline 的作用，是避免每发一个请求，就阻塞等待这个请求的结果。
+
+这就是管道（pipelining），是一种几十年来广泛使用的技术。例如许多 POP3 协议已经实现支持这个功能，大大加快了从服务器下载新邮件的过程。
+
+Redis 很早就支持管道（[pipelining](http://redis.cn/topics/pipelining.html)）技术，因此无论你运行的是什么版本，你都可以使用管道（pipelining）操作 Redis。
+
+🦅 **Redis 如何做大量数据插入？**
+
+Redis 2.6 开始，Redis-cli 支持一种新的被称之为 pipe mode 的新模式用于执行大量数据插入工作。
+
+具体可见 [《Redis 大量数据插入》](http://www.redis.cn/topics/mass-insert.html) 文章。
+
+## 什么是 Redis 事务？
+
+和众多其它数据库一样，Redis 作为 NoSQL 数据库也同样提供了事务机制。在 Redis 中，MULTI / EXEC / DISCARD / WATCH 这四个命令是我们实现事务的基石。相信对有关系型数据库开发经验的开发者而言这一概念并不陌生，即便如此，我们还是会简要的列出 Redis 中事务的实现特征：
+
+- 1、在事务中的所有命令都将会被串行化的顺序执行，事务执行期间，Redis 不会再为其它客户端的请求提供任何服务，从而保证了事物中的所有命令被原子的执行。
+
+  > Lua 脚本，也能实现该功能。
+
+- 2、和关系型数据库中的事务相比，在 Redis 事务中如果有某一条命令执行失败，其后的命令仍然会被继续执行。
+
+  > 这一点，非常重要。回答错了，就回家面壁思过，一天不许喝可乐。
+  >
+  > 这一点，是 Lua 脚本不具备的。
+
+- 3、我们可以通过 MULTI 命令开启一个事务，有关系型数据库开发经验的人可以将其理解为 `"BEGIN TRANSACTION"` 语句。在该语句之后执行的命令，都将被视为事务之内的操作，最后我们可以通过执行 EXEC / DISCARD 命令来提交 / 回滚该事务内的所有操作。这两个 Redis 命令，可被视为等同于关系型数据库中的 COMMIT / ROLLBACK 语句。
+
+  > 开启事务后，所有语句，发送给 Redis Server ，都会暂存在 Server 中。
+
+- 4、在事务开启之前，如果客户端与服务器之间出现通讯故障并导致网络断开，其后所有待执行的语句都将不会被服务器执行。然而如果网络中断事件是发生在客户端执行 EXEC 命令之后，那么该事务中的所有命令都会被服务器执行。
+
+🦅 **如何实现 Redis CAS 操作？**
+
+在 Redis 的事务中，WATCH 命令可用于提供 CAS(check-and-set) 功能。
+
+假设我们通过 WATCH 命令在事务执行之前监控了多个 keys ，倘若在 WATCH 之后有任何 Key 的值发生了变化，EXEC 命令执行的事务都将被放弃，同时返回 `nil` 应答以通知调用者事务执行失败。
+
+具体的示例，可以看看 [《Redis 事务锁 CAS 实现以及深入误区》](https://www.jianshu.com/p/0244a875aa26) 。
+
+## Redis 集群都有哪些方案？
+
+Redis 集群方案如下：
+
+- 1、Redis Sentinel
+- 2、Redis Cluster
+- 3、Twemproxy
+- 4、Codis
+- 5、客户端分片
+
+关于前四种，可以看看 [《Redis 实战（四）集群机制》](http://blog.720ui.com/2016/redis_action_04_cluster/) 这篇文章。
+
+关于最后一种，客户端分片，在 Redis Cluster 出现之前使用较多，目前已经使用比较少了。实现方式如下：
+
+> 在业务代码层实现，起几个毫无关联的 Redis 实例，在代码层，对 Key 进行 hash 计算，然后去对应的 Redis 实例操作数据。
+>
+> 这种方式对 hash 层代码要求比较高，考虑部分包括，节点失效后的替代算法方案，数据震荡后的自动脚本恢复，实例的监控，等等。
+
+🦅 **选择**
+
+目前一般在选型上来说：
+
+- 体量较小时，选择 Redis Sentinel ，单主 Redis 足以支撑业务。
+
+- 体量较大时，选择 Redis Cluster ，通过分片，使用更多内存。
+
+  > 关于这个问题，多大体量需要使用 Redis Cluster 呢？朋友的建议是 10G+ 的时候。主要原因是：
+  >
+  > - 1、一次 RDB 时间随着内存越大，会变大越来越久。同时，一次 fork 的时间也会变久。还有，重启通过 RDB 文件，或者 AOF 日志，恢复时间都会变长。
+  > - 2、体量大之后，读写的 QPS 势必比体量小的时候打的多，那么使用 Redis Cluster 相比 Redis Sentinel ，可以分散读写压力到不同的集群中。
+
+🦅 **Redis 集群如何扩容？**
+
+- ~~如果 Redis 被当做**缓存**使用，使用一致性哈希实现动态扩容缩容。~~
+
+  > 删除的原因是，不考虑客户端分片的情况，目前基本已经不在用了。
+
+- 如果 Redis 被当做一个**持久化存**储使用，必须使用固定的 keys-to-nodes 映射关系，节点的数量一旦确定不能变化。否则的话(即 Redis 节点需要动态变化的情况），必须使用可以在运行时进行数据再平衡的一套系统，而当前只有 Redis Cluster、Codis 可以做到这样。
+
+如果是 Redis Cluster 集群的扩容，可以看看 [《Redis 开发与运维》](https://u.jd.com/lDNJa9) 的「10.4 集群 —— 集群伸缩」小节。简单来说，一共三步：
+
+- 1、准备新节点。
+- 2、加入集群。
+- 3、迁移槽和数据。
+
+## 什么是 Redis 主从同步？
+
+**Redis 主从同步**
+
+Redis 的主从同步(replication)机制，允许 Slave 从 Master 那里，通过网络传输拷贝到完整的数据备份，从而达到主从机制。
+
+- 主数据库可以进行读写操作，当发生写操作的时候自动将数据同步到从数据库，而从数据库一般是只读的，并接收主数据库同步过来的数据。
+- 一个主数据库可以有多个从数据库，而一个从数据库只能有一个主数据库。
+- 第一次同步时，主节点做一次 bgsave 操作，并同时将后续修改操作记录到内存 buffer ，待完成后将 RDB 文件全量同步到复制节点，复制节点接受完成后将 RDB 镜像加载到内存。加载完成后，再通知主节点将期间修改的操作记录同步到复制节点进行重放就完成了同步过程。
+
+**好处**
+
+通过 Redis 的复制功，能可以很好的实现数据库的读写分离，提高服务器的负载能力。主数据库主要进行写操作，而从数据库负责读操作。
+
+> 实际上，我们不是非常推荐在 Redis 中，使用读写分离。主要有两个原因：
+>
+> - Redis Sentinel 只保证主节点的故障的失效转移，而例如说 Jedis 库，也只监听了主节点的变化，但是从节点故障的情况，Jedis 是不进行处理的。这就会导致，Jedis 读会访问到从节点，导致问题。当然，Redisson 库的功能比较强大，已经支持从节点的故障监听。
+> - 如果到达需要读写分离的体量，一般写操作也不一定会少，可以考虑上 Redis Cluster 方案，更加可靠。
+
+------
+
+Redis 主从同步，是很多 Redis 集群方案的基础，例如 Redis Sentinel、Redis Cluster 等等。
+
+更多详细，可以看看如下：
+
+> 因为主从复制的内容很多，艿艿这里就不详细哔哔了。实际场景下，对于开发的面试，我们也不会特别问，毕竟更偏运维的内容。
+
+- [《Redis 官方文档 —— 复制》](http://redis.cn/topics/replication.html)
+- [《Redis 开发与运维》](https://u.jd.com/lDNJa9) 的「6. 复制」章节，更加详细完整。
+
+## 如何使用 Redis Sentinel 实现高可用？
+
+详细，可以看看如下：
+
+> 因为 Redis Sentinel 的内容很多，艿艿这里就不详细哔哔了。实际场景下，对于开发的面试，我们也不会特别问，毕竟更偏运维的内容。
+
+- [《Redis 官方文档 —— Sentinel 高可用》](http://redis.cn/topics/sentinel.html)
+- [《Redis 开发与运维》](https://u.jd.com/lDNJa9) 的「9. 哨兵」章节，更加详细完整。
+
+## 如果使用 Redis Cluster 实现高可用？
+
+详细，可以看看如下：
+
+> 因为 Redis Sentinel 的内容很多，艿艿这里就不详细哔哔了。实际场景下，对于开发的面试，我们也不会特别问，毕竟更偏运维的内容。
+
+- [《Redis 官方文档 —— Redis Cluster 集群》](http://redis.cn/topics/cluster-tutorial.html)
+- [《Redis 开发与运维》](https://u.jd.com/lDNJa9) 的「10. 集群」章节，更加详细完整。
+
+🦅 **说说 Redis 哈希槽的概念？**
+
+Redis Cluster 没有使用一致性 hash ，而是引入了哈希槽的概念。
+
+Redis 集群有 16384 个哈希槽，每个 key 通过 CRC16 校验后对 16384 取模来决定放置哪个槽，集群的每个节点负责一部分 hash 槽。
+
+因为最大是 16384 个哈希槽，所以考虑 Redis 集群中的每个节点都能分配到一个哈希槽，所以最多支持 16384 个 Redis 节点。
+
+为什么是 16384 呢？主要考虑集群内的网络带宽，而 16384 刚好是 2K 字节大小。
+
+🦅 **Redis Cluster 的主从复制模型是怎样的？**
+
+为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用，所以集群使用了**主从复制**模型，每个节点都会有 N-1 个复制节点。
+
+所以，Redis Cluster 可以说是 Redis Sentinel 带分片的加强版。也可以说：
+
+- Redis Sentinel 着眼于高可用，在 master 宕机时会自动将 slave 提升为 master ，继续提供服务。
+- Redis Cluster 着眼于扩展性，在单个 Redis 内存不足时，使用 Cluster 进行分片存储。
+
+🦅 **Redis Cluster 方案什么情况下会导致整个集群不可用？**
+
+有 A，B，C 三个节点的集群，在没有复制模型的情况下，如果节点 B 宕机了，那么整个集群就会以为缺少 5501-11000 这个范围的槽而不可用。当然，这种情况也可以配置 `cluster-require-full-coverage=no` ，整个集群无需所有槽位覆盖。
+
+🦅 **Redis Cluster 会有写操作丢失吗？为什么？**
+
+Redis 并不能保证数据的强一致性，而是【异步复制】，这意味这在实际中集群在特定的条件下可能会丢失写操作。
+
+> 艿艿：一定一定一定要注意，无论对于 Redis Sentinel 还是 Redis Cluster 方案，都是通过主从复制，所以在数据的复制方面，都存在相同的情况。
+
+🦅 **Redis 集群如何选择数据库？**
+
+Redis 集群目前无法做数据库选择，默认在 0 数据库。
+
+🦅 **请说说生产环境中的 Redis 是怎么部署的？**
+
+> 重点问题，仔细理解。
+
+- Redis Cluster ，10 台机器，5 台机器部署了 Redis 主实例，另外 5 台机器部署了 Redis 的从实例，每个主实例挂了一个从实例，5 个节点对外提供读写服务，每个节点的读写高峰 qps 可能可以达到每秒 5 万，5 台机器最多是 25 万读写请求每秒。
+
+- 机器是什么配置？32G 内存 + 8 核 CPU + 1T 磁盘，但是分配给 Redis 进程的是 10G 内存，一般线上生产环境，Redis 的内存尽量不要超过 10G，超过 10G 可能会有问题。那么，5 台机器对外提供读写，一共有 50G 内存。
+
+- 因为每个主实例都挂了一个从实例，所以是高可用的，任何一个主实例宕机，都会自动故障迁移，Redis 从实例会自动变成主实例继续提供读写服务。
+
+- 你往内存里写的是什么数据？每条数据的大小是多少？商品数据，每条数据是 10kb 。100 条数据是 1mb ，10 万条数据是 1G 。常驻内存的是 200 万条商品数据，占用内存是 20G ，仅仅不到总内存的 50% 。目前高峰期每秒就是 3500 左右的请求量。
+
+  > 一般来说，当公司体量大了之后，建议是一个业务线独占一个或多个 Redis Cluster 集群，实现好业务线与业务线之间的隔离。
+
+- 其实大型的公司，会有基础架构的 Team 负责缓存集群的运维。
+
+## 什么是 Redis 分区？
+
+> 这个问题，和 [「Redis 集群都有哪些方案？」](https://svip.iocoder.cn/Redis/Interview/#) 是同类问题。
+>
+> 简单看看即可，重点还是去理解 Redis Cluster 集群方案。
+
+🦅 关于如下四个问题，直接看 [《Redis 分区》](http://www.runoob.com/redis/redis-partitioning.html) 文章。
+
+- Redis 分区是什么？
+- 分区的优势？
+- 分区的不足？
+- 分区类型？
+
+可能有胖友会懵逼，又是 Redis 主从复制，又是 Redis 分区，又是 Redis 集群。傻傻分不清啊！
+
+- Redis 分区是一种模式，将数据分区到不同的 Redis 节点上，而 Redis 集群的 Redis Cluster、Twemproxy、Codis、客户端分片( 不包括 Redis Sentinel ) 这四种方案，是 Redis 分区的具体实现。
+
+  > 注意，Redis Sentinel 实现的是 Redis 的高可用，一定要分清楚。实际上，胖友可以对比 MySQL 和 MongoDB 的高可用、集群的方案，发现思路都是一致的。
+
+- Redis 每个分区，如果想要实现高可用，需要使用到 Redis 主从复制。
+
+🦅 **你知道有哪些 Redis 分区实现方案**？
+
+Redis 分区方案，主要分成两种类型：
+
+- 客户端分区，就是在客户端就已经决定数据会被存储到哪个 Redis 节点或者从哪个 Redis 节点读取。大多数客户端已经实现了客户端分区。
+  - 案例：Redis Cluster 和客户端分区。
+- 代理分区，意味着客户端将请求发送给代理，然后代理决定去哪个节点写数据或者读数据。代理根据分区规则决定请求哪些 Redis 实例，然后根据 Redis 的响应结果返回给客户端。
+  - 案例：Twemproxy 和 Codis 。
+
+查询路由(Query routing)的意思，是客户端随机地请求任意一个 Redis 实例，然后由 Redis 将请求转发给正确的 Redis 节点。Redis Cluster 实现了一种混合形式的查询路由，但并不是直接将请求从一个Redis 节点转发到另一个 Redis 节点，而是在客户端的帮助下直接 Redirect 到正确的 Redis 节点。
+
+> Redis Cluster 的重定向，可以认真看看 [《Redis 开发与运维》](https://u.jd.com/lDNJa9) 的「10.5 集群 - 请求路由」章节。
+
+🦅 **分布式 Redis 是前期做还是后期规模上来了再做好？为什么？？**
+
+如下是网络上的一个答案：
+
+> 既然 Redis 是如此的轻量，为防止以后的扩容，最好的办法就是一开始就启动较多实例。即便你只有一台服务器，你也可以一开始就让 Redis 以分布式的方式运行，使用分区，在同一台服务器上启动多个实例。
+>
+> 一开始就多设置几个 Redis 实例，例如 32 或者 64 个实例，对大多数用户来说这操作起来可能比较麻烦，但是从长久来看做这点牺牲是值得的。
+>
+> 这样的话，当你的数据不断增长，需要更多的 Redis 服务器时，你需要做的就是仅仅将 Redis 实例从一台服务迁移到另外一台服务器而已（而不用考虑重新分区的问题）。一旦你添加了另一台服务器，你需要将你一半的 Redis 实例从第一台机器迁移到第二台机器。
+
+- 和飞哥沟通了下，这个操作不是很合理。
+- 无论怎么说，建议，需要搭建下 Redis Sentinel 高可用，至于拓展性，根据自己的情况，是否使用 Redis Cluster 集群。同时， Redis Cluster 集群会有运维的复杂性，同时会存在跨分片操作（例如说 mget 等等）、事务等操作是不支持的。
+
+## Redis 有哪些重要的健康指标？
+
+推荐阅读 [《Redis 几个重要的健康指标》](https://mp.weixin.qq.com/s/D_khsApGkRckEoV75pYpDA)
+
+- 存活情况
+- 连接数
+- 阻塞客户端数量
+- 使用内存峰值
+- 内存碎片率
+- 缓存命中率
+- OPS
+- 持久化
+- 失效KEY
+- 慢日志
+
+**如何提高 Redis 命中率？**
+
+推荐阅读 [《如何提高缓存命中率（Redis）》](http://www.cnblogs.com/shamo89/p/8383915.html) 。
+
+## 怎么优化 Redis 的内存占用？
+
+推荐阅读 [《Redis 的内存优化》](https://www.jianshu.com/p/8677603d3865)
+
+- redisObject 对象
+- 缩减键值对象
+- 共享对象池
+- 字符串优化
+- 编码优化
+- 控制 key 的数量
+
+🦅 **一个 Redis 实例最多能存放多少的 keys？List、Set、Sorted Set 他们最多能存放多少元素？**
+
+一个 Redis 实例，最多能存放多少的 keys ，List、Set、Sorted Set 他们最多能存放多少元素。
+
+理论上，Redis 可以处理多达 2^32 的 keys ，并且在实际中进行了测试，每个实例至少存放了 2 亿 5 千万的 keys。
+
+任何 list、set、和 sorted set 都可以放 2^32 个元素。
+
+🦅 **假如 Redis 里面有 1 亿个 key，其中有 10w 个 key 是以某个固定的已知的前缀开头的，如果将它们全部找出来？**
+
+使用 `keys` 指令可以扫出指定模式的 key 列表。
+
+- 对方接着追问：如果这个 Redis 正在给线上的业务提供服务，那使用 `keys` 指令会有什么问题？
+- 这个时候你要回答 Redis 关键的一个特性：Redis 的单线程的。`keys` 指令会导致线程阻塞一段时间，线上服务会停顿，直到指令执行完毕，服务才能恢复。这个时候可以使用 `scan` 指令，`scan` 指令可以无阻塞的提取出指定模式的 key 列表，但是会有一定的重复概率，在客户端做一次去重就可以了，但是整体所花费的时间会比直接用 `keys` 指令长。
+
+## Redis 常见的性能问题都有哪些？如何解决？
+
+- 1、**Master 最好不要做任何持久化工作，如 RDB 内存快照和 AOF 日志文件**。
+
+  > 经过和朋友讨论，主节点开启 AOF 日志功能，尽量避免 AOF 重写。
+
+  - Master 写内存快照，save 命令调度 rdbSave 函数，会阻塞主线程的工作，当快照比较大时对性能影响是非常大的，会间断性暂停服务，所以 Master 最好不要写内存快照。
+  - Master AOF 持久化，如果不重写 AOF 文件，这个持久化方式对性能的影响是最小的，但是 AOF 文件会不断增大，AOF 文件过大会影响 Master 重启的恢复速度。
+  - 所以，Master 最好不要做任何持久化工作，包括内存快照和 AOF 日志文件，特别是不要启用内存快照做持久化。如果数据比较关键，某个 Slave 开启AOF备份数据，策略为每秒同步一次。
+
+- 2、Master 调用 BGREWRITEAOF 重写 AOF 文件，AOF 在重写的时候会占大量的 CPU 和内存资源，导致服务 load 过高，出现短暂服务暂停现象。
+
+  - 一般来说，出现这个问题，很多时候是因为 Master 的内存过大，一次 AOF 重写需要占用的 CPU 和内存的资源较多，此时可以考虑 Redis Cluster 方案。
+
+- 3、尽量避免在压力很大的主库上增加过多的从库。
+
+  - 可以考虑在从上挂载其它的从。
+
+- 4、主从复制不要用图状结构，用单向链表结构更为稳定，即：`Master <- Slave1 <- Slave2 <- Slave3...` 。
+
+  - 这样的结构，也方便解决单点故障问题，实现 Slave 对 Master 的替换。如果 Master挂了，可以立刻启用 Slave1 做 Master ，其他不变。
+
+    > 从节点在切换主节点作为复制源的时候，会重新发起全量复制。所以此处通过 Slave1 挂在 Slave 下，可以规避这个问题。同时，也减少了 Master 的复制压力。当然，坏处就是 Slave1 的延迟可能会高一些些，所以还是需要取舍。
+
+- 5、Redis 主从复制的性能问题，为了主从复制的速度和连接的稳定性，Slave 和 Master 最好在同一个局域网内。
+
+------
+
+和飞哥沟通过后，他们主节点开启 AOF ，从节点开启 AOF + RDB 。
+
+和晓峰沟通后，他们主节点开启 AOF ，从节点开启 RDB 居多，也有开启 AOF + RDB 的。
+
+## 修改配置不重启 Redis 会实时生效吗？
+
+针对运行实例，有许多配置选项可以通过 `CONFIG SET` 命令进行修改，而无需执行任何形式的重启。
+
+从 Redis 2.2 开始，可以从 AOF 切换到 RDB 的快照持久性或其他方式而不需要重启 Redis。检索 `CONFIG GET *` 命令获取更多信息。
+
+但偶尔重新启动是必须的，如为升级 Redis 程序到新的版本，或者当你需要修改某些目前 CONFIG 命令还不支持的配置参数的时候。
+
+## 其他问题
+
+有些比较凶残的面试官，可能会问我们一些 Redis 数据结构的问题，例如：
+
+- Skiplist 插入和查询原理？
+
+- 压缩列表的原理？
+
+- Redis 底层为什么使用跳跃表而不是红黑树？
+
+  > 跳跃表在范围查找的时候性能比较高。
+
+想要了解这块，需要花一定的时间去撸一撸源码，推荐可以看如下两块内容：
+
+- [《Redis 深度历险：核心原理与应用实践》](https://juejin.im/book/5afc2e5f6fb9a07a9b362527?referrer=5904c637b123db3ee479d923)
+- [《Redis 设计与实现》](https://u.jd.com/Fl5NTt)
+
+推荐先读第一本，可以深入浅出的了解 Redis 原理和源码。然后在读第二本，硬核了解 Redis 的设计与实现（源码）。
+
+## 666. 彩蛋
+
+哇哦，爽。虽然过程痛苦，但是中间请教了蛮多人问题，收获颇多哈。
+
+嘿嘿，在回答问题的过程中，胖友会发现一直在推荐 [《Redis 开发与运维》](https://u.jd.com/lDNJa9) 这本书。在艿艿整理完第一版 Redis 面试题后，发现对有些 Redis 的面试题，理解还是有所欠缺（当然现在可能也是，哈哈哈），重新翻看了下这本书，发现很多问题都得到了非常不错的解答。所以，推荐再推荐。
+
+参考与推荐如下文章：
+
+- JeffreyLcm [《Redis 面试题》](https://segmentfault.com/a/1190000014507534)
+- 烙印99 [《史上最全 Redis 面试题及答案》](https://www.imooc.com/article/36399)
+- yanglbme [《Redis 和 Memcached 有什么区别？Redis 的线程模型是什么？为什么单线程的 Redis 比多线程的 Memcached 效率要高得多？》](https://github.com/doocs/advanced-java/blob/master/docs/high-concurrency/redis-single-thread-model.md)
+- 老钱 [《天下无难试之 Redis 面试题刁难大全》](https://zhuanlan.zhihu.com/p/32540678)
+- yanglbme [《Redis 的持久化有哪几种方式？不同的持久化机制都有什么优缺点？持久化机制具体底层是如何实现的？》](https://github.com/doocs/advanced-java/blob/master/docs/high-concurrency/redis-persistence.md)
\ No newline at end of file
diff --git a/面试题/14-MySQL 面试题.assets/01.png b/面试题/14-MySQL 面试题.assets/01.png
new file mode 100644
index 0000000..eefc608
Binary files /dev/null and b/面试题/14-MySQL 面试题.assets/01.png differ
diff --git a/面试题/14-MySQL 面试题.assets/06.png b/面试题/14-MySQL 面试题.assets/06.png
new file mode 100644
index 0000000..c4bf9c9
Binary files /dev/null and b/面试题/14-MySQL 面试题.assets/06.png differ
diff --git a/面试题/14-MySQL 面试题.assets/259d196856a231aff5e3cf1505848af4.png b/面试题/14-MySQL 面试题.assets/259d196856a231aff5e3cf1505848af4.png
new file mode 100644
index 0000000..8882e00
Binary files /dev/null and b/面试题/14-MySQL 面试题.assets/259d196856a231aff5e3cf1505848af4.png differ
diff --git a/面试题/14-MySQL 面试题.assets/2fb922405a35479fa99eb2de4708638c.png b/面试题/14-MySQL 面试题.assets/2fb922405a35479fa99eb2de4708638c.png
new file mode 100644
index 0000000..66175dd
Binary files /dev/null and b/面试题/14-MySQL 面试题.assets/2fb922405a35479fa99eb2de4708638c.png differ
diff --git a/面试题/14-MySQL 面试题.assets/84ea509fa091a10add4e7614e6cb37db.png b/面试题/14-MySQL 面试题.assets/84ea509fa091a10add4e7614e6cb37db.png
new file mode 100644
index 0000000..afa1222
Binary files /dev/null and b/面试题/14-MySQL 面试题.assets/84ea509fa091a10add4e7614e6cb37db.png differ
diff --git a/面试题/14-MySQL 面试题.assets/d49d260fc1eb8f992df0401b70d70e3d.png b/面试题/14-MySQL 面试题.assets/d49d260fc1eb8f992df0401b70d70e3d.png
new file mode 100644
index 0000000..eecebf5
Binary files /dev/null and b/面试题/14-MySQL 面试题.assets/d49d260fc1eb8f992df0401b70d70e3d.png differ
diff --git a/面试题/14-MySQL 面试题.md b/面试题/14-MySQL 面试题.md
new file mode 100644
index 0000000..841c586
--- /dev/null
+++ b/面试题/14-MySQL 面试题.md	
@@ -0,0 +1,1104 @@
+# 精尽 MySQL 面试题「最新更新时间：2024-02」
+
+以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。
+
+如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的 MySQL 面试题的大保健。
+
+而题目的难度，艿艿尽量按照从容易到困难的顺序，逐步下去。
+
+另外，MySQL 涉及的内容非常非常非常多，所以面试题也容易写的杂乱。当年，我们记着几个一定要掌握的重心：
+
+> 重点的题目，艿艿已经在标题前，添加了【重点】前缀。
+
+1. 索引。
+2. 锁。
+3. 事务和隔离级别。
+
+因为 MySQL 还会有部分内容和运维相关度比较高，所以本文我们分成两部分【开发】【运维】两部分。
+
+- 对于【开发】部分，我们需要掌握。
+- 对于【运维】部分，更多考验开发的知识储备情况，当然能回答出来是比较好的，特别是对于高级开发工程师、架构师等。
+
+# 开发
+
+## 为什么互联网公司一般选择 MySQL 而不是 Oracle?
+
+**免费**、流行、够用。
+
+😈 当然，这个回答要稍微润色下。不过一般，很少问这个问题了。
+
+## 数据库的三范式是什么？什么是反模式？
+
+> 艿艿：重点在于反模式的回答。实际开发中，不会严格遵守三范式。
+
+胖友直接看 [《服务端指南 数据存储篇 | MySQL（07） 范式与反模式》](http://blog.720ui.com/2017/mysql_core_07_anti-pattern/) 。
+
+## MySQL 有哪些数据类型？
+
+MySQL 支持多种类型，大致可以分为三类：数值、日期/时间和字符串(字符)类型。具体可以看看 [《MySQL 数据类型》](http://www.runoob.com/mysql/mysql-data-types.html) 文档。
+
+- 正确的使用数据类型，对数据库的优化是非常重要的。
+
+🦅 **MySQL 中 varchar 与 char 的区别？varchar(50) 中的 50 代表的涵义？**
+
+- 1、varchar 与 char 的区别，char 是一种固定长度的类型，varchar 则是一种可变长度的类型。
+
+- 2、varchar(50) 中 50 的涵义最多存放 50 个字符。varchar(50) 和 (200) 存储 hello 所占空间一样，
+
+  但后者在排序时会消耗更多内存，因为 `ORDER BY col` 采用 fixed_length 计算 col 长度(memory引擎也一样)
+
+  。
+
+  > 所以，实际场景下，选择合适的 varchar 长度还是有必要的。
+
+🦅 **int(11) 中的 11 代表什么涵义？**
+
+int(11) 中的 11 ，不影响字段存储的范围，只影响展示效果。具体可以看看 [《MySQL 中 int 长度的意义》](https://blog.csdn.net/qmhball/article/details/51544484) 文章。
+
+🦅 **金额(金钱)相关的数据，选择什么数据类型？**
+
+- 方式一，使用 int 或者 bigint 类型。如果需要存储到分的维度，需要 *100 进行放大。
+- 方式二，使用 decimal 类型，避免精度丢失。如果使用 Java 语言时，需要使用 BigDecimal 进行对应。
+
+🦅 **一张表，里面有 ID 自增主键，当 insert 了 17 条记录之后，删除了第 15,16,17 条记录，再把 MySQL 重启，再 insert 一条记录，这条记录的 ID 是 18 还是 15？**
+
+- 一般情况下，我们创建的表的类型是 InnoDB ，如果新增一条记录（不重启 MySQL 的情况下），这条记录的 ID 是18 ；但是如果重启 MySQL 的话，这条记录的 ID 是 15 。因为 InnoDB 表只把自增主键的最大 ID 记录到内存中，所以重启数据库或者对表 OPTIMIZE 操作，都会使最大 ID 丢失。
+- 但是，如果我们使用表的类型是 MyISAM ，那么这条记录的 ID 就是 18 。因为 MyISAM 表会把自增主键的最大 ID 记录到数据文件里面，重启 MYSQL 后，自增主键的最大 ID 也不会丢失。
+
+最后，还可以跟面试官装个 x ，生产数据，不建议进行物理删除记录。
+
+🦅 **表中有大字段 X(例如：text 类型)，且字段 X 不会经常更新，以读为为主，请问您是选择拆成子表，还是继续放一起?写出您这样选择的理由**
+
+- 拆带来的问题：连接消耗 + 存储拆分空间。
+
+  > 如果能容忍拆分带来的空间问题，拆的话最好和经常要查询的表的主键在物理结构上放置在一起(分区) 顺序 IO ，减少连接消耗，最后这是一个文本列再加上一个全文索引来尽量抵消连接消耗。
+
+- 不拆可能带来的问题：查询性能。
+
+  > 如果能容忍不拆分带来的查询性能损失的话，上面的方案在某个极致条件下肯定会出现问题，那么不拆就是最好的选择。
+
+实际场景下，例如说商品表数据量比较大的情况下，会将商品描述单独存储到一个表中。即，使用拆的方案。
+
+## MySQL 有哪些存储引擎？
+
+MySQL 提供了多种的存储引擎：
+
+- InnoDB
+- MyISAM
+- MRG_MYISAM
+- MEMORY
+- CSV
+- ARCHIVE
+- BLACKHOLE
+- PERFORMANCE_SCHEMA
+- FEDERATED
+- …
+
+具体每种存储引擎的介绍，可以看看 [《数据库存储引擎》](https://github.com/jaywcjlove/mysql-tutorial/blob/master/chapter3/3.5.md) 。
+
+🦅 **如何选择合适的存储引擎？**
+
+提供几个选择标准，然后按照标准，选择对应的存储引擎即可，也可以根据 [常用引擎对比](https://github.com/jaywcjlove/mysql-tutorial/blob/master/chapter3/3.5.md#常用引擎对比) 来选择你使用的存储引擎。使用哪种引擎需要根据需求灵活选择，一个数据库中多个表可以使用不同的引擎以满足各种性能和实际需求。使用合适的存储引擎，将会提高整个数据库的性能。
+
+1. 是否需要支持事务。
+
+2. 对索引和缓存的支持。
+
+3. 是否需要使用热备。
+
+4. 崩溃恢复，能否接受崩溃。
+
+5. 存储的限制。
+
+6. 是否需要外键支持。
+
+   > 艿艿：目前开发已经不考虑外键，主要原因是性能。具体可以看看 [《从 MySQL 物理外键开始的思考》](http://www.justabug.net/think-in-mysql-foreign-key/) 文章。
+
+目前，MySQL 默认的存储引擎是 InnoDB ，并且也是最主流的选择。主要原因如下：
+
+- 【最重要】支持事务。
+- 支持行级锁和表级锁，能支持更多的并发量。
+- 查询不加锁，完全不影响查询。
+- 支持崩溃后恢复。
+
+在 MySQL5.1 以及之前的版本，默认的存储引擎是 MyISAM ，但是目前已经不再更新，且它有几个比较关键的缺点：
+
+- 不支持事务。
+- 使用表级锁，如果数据量大，一个插入操作锁定表后，其他请求都将阻塞。
+
+> 艿艿：也就是说，我们不需要花太多力气在 MyISAM 的学习上。
+
+🦅 **请说明 InnoDB 和 MyISAM 的区别**
+
+|              | InnoDB         | MyISAM |
+| :----------- | :------------- | :----- |
+| 事务         | 支持           | 不支持 |
+| 存储限制     | 64TB           | 无     |
+| 锁粒度       | 行锁           | 表锁   |
+| 崩溃后的恢复 | 支持           | 不支持 |
+| 外键         | 支持           | 不支持 |
+| 全文检索     | 5.7 版本后支持 | 支持   |
+
+更完整的对比，可以看看 [《数据库存储引擎》](https://github.com/jaywcjlove/mysql-tutorial/blob/master/chapter3/3.5.md) 的 [「常用引擎对比」](https://svip.iocoder.cn/MySQL/Interview/#) 小节。
+
+🦅 **请说说 InnoDB 的 4 大特性？**
+
+> 艿艿：貌似我面试没被问过…反正，我是没弄懂过~~
+
+- 插入缓冲(insert buffer)
+- 二次写(double write)
+- 自适应哈希索引(ahi)
+- 预读(read ahead)
+
+🦅 **为什么 SELECT COUNT(\*) FROM table 在 InnoDB 比 MyISAM 慢？**
+
+对于 `SELECT COUNT(*) FROM table` 语句，在没有 `WHERE` 条件的情况下，InnoDB 比 MyISAM 可能会慢很多，尤其在大表的情况下。因为，InnoDB 是去实时统计结果，会全表扫描；而 MyISAM 内部维持了一个计数器，预存了结果，所以直接返回即可。
+
+详细的原因，胖友可以看看 [《高性能 MySQL 之 Count 统计查询》](https://blog.csdn.net/qq_15037231/article/details/81179383) 博客。
+
+🦅 **各种不同 MySQL 版本的 Innodb 的改进？**
+
+> 艿艿：这是一个选择了解的问题。
+
+MySQL5.6 下 Innodb 引擎的主要改进：
+
+1. online DDL
+2. memcached NoSQL 接口
+3. transportable tablespace（ alter table discard/import tablespace）
+4. MySQL 正常关闭时，可以 dump 出 buffer pool 的（ space， page_no），重启时 reload，加快预热速度
+5. 索引和表的统计信息持久化到 mysql.innodb_table_stats 和 mysql.innodb_index_stats，可提供稳定的执行计划
+6. Compressed row format 支持压缩表
+
+MySQL5.7 下 Innodb 引擎的主要改进：
+
+- 1、修改 varchar 字段长度有时可以使用
+
+  > 这里的“有时”，指的是也有些限制。可见 [《MySQL 5.7 online ddl 的一些改进》](https://yq.aliyun.com/articles/581726) 。
+
+- 2、Buffer pool 支持在线改变大小
+
+- 3、Buffer pool 支持导出部分比例
+
+- 4、支持新建 innodb tablespace，并可以在其中创建多张表
+
+- 5、磁盘临时表采用 innodb 存储，并且存储在 innodb temp tablespace 里面，以前是 MyISAM 存储
+
+- 6、透明表空间压缩功能
+
+## 【重点】什么是索引？
+
+索引，类似于书籍的目录，想找到一本书的某个特定的主题，需要先找到书的目录，定位对应的页码。
+
+MySQL 中存储引擎使用类似的方式进行查询，先去索引中查找对应的值，然后根据匹配的索引找到对应的数据行。
+
+🦅 **索引有什么好处？**
+
+1. 提高数据的检索速度，降低数据库IO成本：使用索引的意义就是通过缩小表中需要查询的记录的数目从而加快搜索的速度。
+2. 降低数据排序的成本，降低CPU消耗：索引之所以查的快，是因为先将数据排好序，若该字段正好需要排序，则正好降低了排序的成本。
+
+🦅 **索引有什么坏处？**
+
+1. 占用存储空间：索引实际上也是一张表，记录了主键与索引字段，一般以索引文件的形式存储在磁盘上。
+2. 降低更新表的速度：表的数据发生了变化，对应的索引也需要一起变更，从而减低的更新速度。否则索引指向的物理数据可能不对，这也是索引失效的原因之一。
+
+🦅 **索引的使用场景？**
+
+- 1、对非常小的表，大部分情况下全表扫描效率更高。
+
+- 2、对中大型表，索引非常有效。
+
+- 3、特大型的表，建立和使用索引的代价随着增长，可以使用分区技术来解决。
+
+  > 实际场景下，MySQL 分区表很少使用，原因可以看看 [《互联网公司为啥不使用 MySQL 分区表？》](https://blog.csdn.net/admin1973/article/details/55504018) 文章。
+  >
+  > 对于特大型的表，更常用的是“分库分表”，目前解决方案有 Sharding Sphere、MyCAT 等等。
+
+🦅 **索引的类型？**
+
+索引，都是实现在存储引擎层的。主要有六种类型：
+
+- 1、普通索引：最基本的索引，没有任何约束。
+
+- 2、唯一索引：与普通索引类似，但具有唯一性约束。
+
+- 3、主键索引：特殊的唯一索引，不允许有空值。
+
+- 4、复合索引：将多个列组合在一起创建索引，可以覆盖多个列。
+
+- 5、外键索引：只有InnoDB类型的表才可以使用外键索引，保证数据的一致性、完整性和实现级联操作。
+
+- 6、全文索引：MySQL 自带的全文索引只能用于 InnoDB、MyISAM ，并且只能对英文进行全文检索，一般使用全文索引引擎。
+
+  > 常用的全文索引引擎的解决方案有 Elasticsearch、Solr 等等。最为常用的是 Elasticsearch 。
+
+具体的使用，可以看看 [《服务端指南 数据存储篇 | MySQL（03） 如何设计索引》](http://blog.720ui.com/2017/mysql_core_03_how_use_index/) 。
+
+🦅 **MySQL 索引的“创建”原则？**
+
+> 注意，是“创建”噢。
+
+- 1、最适合索引的列是出现在 `WHERE` 子句中的列，或连接子句中的列，而不是出现在 `SELECT` 关键字后的列。
+
+- 2、索引列的基数越大，索引效果越好。
+
+  > 具体为什么，可以看看如下两篇文章：
+  >
+  > - [《MySQL 索引基数》](https://blog.csdn.net/mingyundezuoan/article/details/79038989) 理解相对简单
+  > - [《低基数索引为什么会对性能产生负面影响》](https://www.ibm.com/developerworks/cn/data/library/techarticle/dm-1309cardinal/index.html) 写的更原理，所以较为难懂。
+
+- 3、根据情况创建复合索引，复合索引可以提高查询效率。
+
+  > 因为复合索引的基数会更大。
+
+- 4、避免创建过多的索引，索引会额外占用磁盘空间，降低写操作效率。
+
+- 5、主键尽可能选择较短的数据类型，可以有效减少索引的磁盘占用提高查询效率。
+
+- 6、对字符串进行索引，应该定制一个前缀长度，可以节省大量的索引空间。
+
+🦅 **MySQL 索引的“使用”注意事项？**
+
+> 注意，是“使用”噢。
+
+- 1、应尽量避免在 `WHERE` 子句中使用 `!=` 或 `<>` 操作符，否则将引擎放弃使用索引而进行全表扫描。优化器将无法通过索引来确定将要命中的行数,因此需要搜索该表的所有行。
+
+  > 注意，`column IS NULL` 也是不可以使用索引的。
+
+- 2、应尽量避免在 `WHERE` 子句中使用 `OR` 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：`SELECT id FROM t WHERE num = 10 OR num = 20` 。
+
+- 3、应尽量避免在 `WHERE` 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。
+
+- 4、应尽量避免在 `WHERE` 子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。
+
+- 5、不要在 `WHERE` 子句中的 `=` 左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。
+
+- 6、复合索引遵循前缀原则。
+
+- 7、如果 MySQL 评估使用索引比全表扫描更慢，会放弃使用索引。如果此时想要索引，可以在语句中添加强制索引。
+
+- 8、列类型是字符串类型，查询时一定要给值加引号，否则索引失效。
+
+- 9、`LIKE` 查询，`%` 不能在前，因为无法使用索引。如果需要模糊匹配，可以使用全文索引。
+
+关于这块，可以看看 [《服务端指南 数据存储篇 | MySQL（04） 索引使用的注意事项》](http://blog.720ui.com/2017/mysql_core_04_index_item/) 文章，写的更加细致。
+
+🦅 **以下三条 SQL 如何建索引，只建一条怎么建？**
+
+```
+WHERE a = 1 AND b = 1
+WHERE b = 1
+WHERE b = 1 ORDER BY time DESC
+```
+
+- 以顺序 b , a, time 建立复合索引，`CREATE INDEX table1_b_a_time ON index_test01(b, a, time)`。
+- 对于第一条 SQL ，因为最新 MySQL 版本会优化 `WHERE` 子句后面的列顺序，以匹配复合索引顺序。
+
+🦅 **想知道一个查询用到了哪个索引，如何查看?**
+
+`EXPLAIN` 显示了 MYSQL 如何使用索引来处理 SELECT 语句以及连接表,可以帮助选择更好的索引和写出更优化的查询语句。
+
+使用方法，在 `SELECT` 语句前加上 `EXPLAIN` 就可以了。感兴趣的胖友，可以详细看看 [《MySQL explain 执行计划详细解释》](http://www.jfox.info/2017/mysql-explain执行计划详细解释.html) 。
+
+## 【重点】MySQL 索引的原理？
+
+解释 MySQL 索引的原理，篇幅会比较长，并且网络上已经有靠谱的资料可以看，所以艿艿这里整理了几篇，胖友可以对照着看。
+
+- [《MySQL索引背后的数据结构及算法原理》](http://blog.codinglabs.org/articles/theory-of-mysql-index.html)
+
+  > 写的一点都不好，艿艿在地铁反复看了 10 遍。
+  >
+  > 强烈推荐！！！！
+
+- [《MySQL 索引原理》](https://blog.csdn.net/u013235478/article/details/50625677)
+
+- [《深入理解 MySQL 索引原理和实现 —— 为什么索引可以加速查询？》](https://blog.csdn.net/tongdanping/article/details/79878302)
+
+下面，艿艿对关键知识做下整理，方便胖友回顾。
+
+🦅 **MySQL 有哪些索引方法？**
+
+> 艿艿：这个问题是索引方法 Index Method ，上面的索引类型 Index Type 。
+
+在 MySQL 中，我们可以看到两种索引方式：
+
+- B-Tree 索引。
+- Hash 索引。
+
+实际场景下，我们基本仅仅使用 B-Tree 索引。详细的对比可以看看 [《MySQL BTree 索引和 hash 索引的区别》](https://blog.csdn.net/oChangWen/article/details/54024063) 。
+
+对于 Hash 索引，我们了解即可，面试重点是掌握 B-Tree 索引的原理。
+
+🦅 **什么是 B-Tree 索引？**
+
+B-Tree 是为磁盘等外存储设备设计的一种平衡查找树。因此在讲 B-Tree 之前先了解下磁盘的相关知识。
+
+- 系统从磁盘读取数据到内存时是以磁盘块（block）为基本单位的，位于同一个磁盘块中的数据会被一次性读取出来，而不是需要什么取什么。
+
+- InnoDB存储引擎中有页（Page）的概念，页是其磁盘管理的最小单位。InnoDB 存储引擎中默认每个页的大小为 16 KB，可通过参数 innodb_page_size 将页的大小设置为 4K、8K、16K ，在 MySQL 中可通过如下命令查看页的大小：
+
+  ```
+  mysql> show variables like 'innodb_page_size';
+  ```
+
+- 而系统一个磁盘块的存储空间往往没有这么大，因此 InnoDB 每次申请磁盘空间时都会是若干地址连续磁盘块来达到页的大小 16KB 。InnoDB 在把磁盘数据读入到磁盘时会以页为基本单位，在查询数据时如果一个页中的每条数据都能有助于定位数据记录的位置，这将会减少磁盘 I/O 次数，提高查询效率。
+
+B-Tree 结构的数据可以让系统高效的找到数据所在的磁盘块。为了描述B-Tree，首先定义一条记录为一个二元组 [key, data] ，key 为记录的键值，对应表中的主键值，data 为一行记录中除主键外的数据。对于不同的记录，key值互不相同。
+
+一棵 m 阶的 B-Tree 有如下特性：
+
+> 艿艿：如果胖友对算法了解不对，可能对下面的各种数字关系不太能理解。最起码，要弄懂层级关系，以及每种节点存储的数据。
+
+1. 每个节点最多有 m 个孩子。
+   - 除了根节点和叶子节点外，其它每个节点至少有 Ceil(m/2) 个孩子。
+   - 若根节点不是叶子节点，则至少有 2 个孩子。
+2. 所有叶子节点都在同一层，且不包含其它关键字信息。
+3. 每个非叶子节点包含 n 个关键字信息（P0,P1,…Pn, k1,…kn）
+   - 关键字的个数 n 满足：ceil(m/2)-1 <= n <= m-1
+   - ki(i=1,…n) 为关键字，且关键字升序排序。
+   - Pi(i=0,…n) 为指向子树根节点的指针。P(i-1) 指向的子树的所有节点关键字均小于 ki ，但都大于 k(i-1) 。
+
+B-Tree 中的每个节点根据实际情况可以包含大量的关键字信息和分支，如下图所示为一个 3 阶的 B-Tree：
+
+[![B-Tree 的结构](14-MySQL 面试题.assets/84ea509fa091a10add4e7614e6cb37db.png)](http://static.iocoder.cn/84ea509fa091a10add4e7614e6cb37db)B-Tree 的结构
+
+- 每个节点占用一个盘块的磁盘空间，一个节点上有两个升序排序的 key 和三个指向子树根节点的 point ，point 存储的是子节点所在磁盘块的地址。两个 key 划分成的三个范围域，对应三个 point 指向的子树的数据的范围域。
+- 以根节点为例，key 为 17 和 35 ，P1 指针指向的子树的数据范围为小于 17 ，P2 指针指向的子树的数据范围为 [17~35] ，P3 指针指向的子树的数据范围为大于 35 。
+
+模拟查找 key 为 29 的过程：
+
+- 1、根据根节点找到磁盘块 1 ，读入内存。【磁盘I/O操作第1次】
+- 2、比较 key 29 在区间（17,35），找到磁盘块 1 的指针 P2 。
+- 3、根据 P2 指针找到磁盘块 3 ，读入内存。【磁盘I/O操作第2次】
+- 4、比较 key 29 在区间（26,30），找到磁盘块3的指针P2。
+- 5、根据 P2 指针找到磁盘块 8 ，读入内存。【磁盘I/O操作第3次】
+- 6、在磁盘块 8 中的 key 列表中找到 eky 29 。
+
+分析上面过程，发现需要 3 次磁盘 I/O 操作，和 3 次内存查找操作。由于内存中的 key 是一个有序表结构，可以利用二分法查找提高效率。而 3 次磁盘 I/O 操作是影响整个 B-Tree 查找效率的决定因素。B-Tree 相对于 AVLTree 缩减了节点个数，使每次磁盘 I/O 取到内存的数据都发挥了作用，从而提高了查询效率。
+
+🦅 **什么是 B+Tree 索引？**
+
+B+Tree 是在 B-Tree 基础上的一种优化，使其更适合实现外存储索引结构，InnoDB存储引擎就是用 B+Tree 实现其索引结构。
+
+> 下面这一段，面试非常关键。
+
+从上一节中的 B-Tree 结构图中可以看到，每个节点中不仅包含数据的 key 值，还有 data 值。而每一个页的存储空间是有限的，如果 data 数据较大时将会导致每个节点（即一个页）能存储的 key 的数量很小，当存储的数据量很大时同样会导致 B-Tree 的深度较大，增大查询时的磁盘 I/O 次数，进而影响查询效率。在 B+Tree 中，所有数据记录节点都是按照键值大小顺序存放在同一层的叶子节点上，而非叶子节点上只存储 key 值信息，这样可以大大加大每个节点存储的 key 值数量，降低 B+Tree 的高度。
+
+B+Tree 相对于 B-Tree 有几点不同：
+
+- 非叶子节点只存储键值信息。
+- 所有叶子节点之间都有一个链指针。
+- 数据记录都存放在叶子节点中。
+
+将上一节中的 B-Tree 优化，由于 B+Tree 的非叶子节点只存储键值信息，假设每个磁盘块能存储 4 个键值及指针信息，则变成 B+Tree 后其结构如下图所示：
+
+[![B+Tree 的结构](14-MySQL 面试题.assets/259d196856a231aff5e3cf1505848af4.png)](http://static.iocoder.cn/259d196856a231aff5e3cf1505848af4)B+Tree 的结构
+
+- 通常在 B+Tree 上有两个头指针，一个指向根节点，另一个指向关键字最小的叶子节点，而且所有叶子节点（即数据节点）之间是一种链式环结构。因此可以对 B+Tree 进行两种查找运算：一种是对于主键的范围查找和分页查找，另一种是从根节点开始，进行随机查找。
+
+可能上面例子中只有 22 条数据记录，看不出 B+Tree 的优点，下面做一个推算：
+
+- InnoDB 存储引擎中页的大小为 16KB，一般表的主键类型为 INT（占用4个字节） 或 BIGINT（占用8个字节），指针类型也一般为 4 或 8 个字节，也就是说一个页（B+Tree 中的一个节点）中大概存储 16KB/(8B+8B)=1K 个键值（因为是估值，为方便计算，这里的 K 取值为〖10〗^3）。也就是说一个深度为 3 的 B+Tree 索引可以维护10^3 *10^3* 10^3 = 10亿 条记录。
+- 实际情况中每个节点可能不能填充满，因此在数据库中，B+Tree 的高度一般都在 2~4 层。MySQL 的 InnoDB 存储引擎在设计时是将根节点常驻内存的，也就是说查找某一键值的行记录时最多只需要 1~3 次磁盘 I/O 操作。
+
+🦅 **B-Tree 有哪些索引类型？**
+
+在 B+Tree 中，根据叶子节点的内容，索引类型分为**主键索引**和**非主键索引**。
+
+> 注意，这里的索引类型，和上面的索引类型，还是对的上的噢。
+
+- 主键索引的叶子节点存的数据是整行数据( 即具体数据 )。在 InnoDB 里，主键索引也被称为**聚集索引**（clustered index）。
+
+- 非主键索引的叶子节点存的数据是整行数据的主键，键值是索引。在 InnoDB 里，非主键索引也被称为
+
+  辅助索引
+
+  （secondary index）。
+
+  > 二级索引的叶节点存储的是主键值，而不是行指针，这是为了减少当出现行移动或数据页分裂时二级索引的维护工作，但会让二级索引占用更多的空间。
+
+辅助索引与聚集索引的区别在于辅助索引的叶子节点并不包含行记录的全部数据，而是存储相应行数据的聚集索引键，即主键。当通过辅助索引来查询数据时，需要进过两步：
+
+- 首先，InnoDB 存储引擎会遍历辅助索引找到主键。
+- 然后，再通过主键在聚集索引中找到完整的行记录数据。
+
+另外，InnoDB 通过主键聚簇数据，如果没有定义主键，会选择一个唯一的非空索引代替，如果没有这样的索引，会隐式定义个主键作为聚簇索引。
+
+再另外，可能有胖友有和艿艿的一样疑惑，在**辅助索引**如果相同的索引怎么存储？最终存储到 B+Tree 非子节点中时，它们对应的主键 ID 是不同的，所以妥妥的。如下图所示：[![相同的索引怎么存储](14-MySQL 面试题.assets/01.png)](http://static.iocoder.cn/images/MySQL/2019_12_01/01.png)相同的索引怎么存储
+
+🦅 **聚簇索引的注意点有哪些？**
+
+聚簇索引表最大限度地提高了 I/O 密集型应用的性能，但它也有以下几个限制：
+
+- 1、插入速度严重依赖于插入顺序，按照主键的顺序插入是最快的方式，否则将会出现页分裂，严重影响性能。因此，对于 InnoDB 表，我们一般都会定义一个自增的 ID 列为主键。
+
+  > 关于这一点，可能面试官会换一个问法。例如，为什么主键需要是自增 ID ，又或者为什么主键需要带有时间性关联。
+
+- 2、更新主键的代价很高，因为将会导致被更新的行移动。因此，对于InnoDB 表，我们一般定义主键为不可更新。
+
+  > MySQL 默认情况下，主键是允许更新的。对于 MongoDB ，其 主键是不允许更新的。
+
+- 3、二级索引访问需要两次索引查找，第一次找到主键值，第二次根据主键值找到行数据。
+
+  > 当然，有一种情况可以无需二次查找，基于非主键索引查询，但是查询字段只有主键 ID ，那么在二级索引中就可以查找到。
+
+- 4、主键 ID 建议使用整型。因为，每个主键索引的 B+Tree 节点的键值可以存储更多主键 ID ，每个非主键索引的 B+Tree 节点的数据可以存储更多主键 ID 。
+
+🦅 **什么是索引的最左匹配特性？**
+
+当 B+Tree 的数据项是复合的数据结构，比如索引 `(name, age, sex)` 的时候，B+Tree 是按照从左到右的顺序来建立搜索树的。
+
+- 比如当 `(张三, 20, F)` 这样的数据来检索的时候，B+Tree 会优先比较 name 来确定下一步的所搜方向，如果 name 相同再依次比较 age 和 sex ，最后得到检索的数据。
+- 但当 `(20, F)` 这样的没有 name 的数据来的时候，B+Tree 就不知道下一步该查哪个节点，因为建立搜索树的时候 name 就是第一个比较因子，必须要先根据 name 来搜索才能知道下一步去哪里查询。
+- 比如当 `(张三, F)` 这样的数据来检索时，B+Tree 可以用 name 来指定搜索方向，但下一个字段 age 的缺失，所以只能把名字等于张三的数据都找到，然后再匹配性别是 F 的数据了。
+
+这个是非常重要的性质，即索引的最左匹配特性。
+
+🦅 **MyISAM 索引实现？**
+
+> 艿艿：注意，我们上面看到的都是 InnoDB 存储引擎下的索引实现。
+
+MyISAM 索引的实现，和 InnoDB 索引的实现是一样使用 B+Tree ，**差别在于 MyISAM 索引文件和数据文件是分离的，索引文件仅保存数据记录的地址**。
+
+1）主键索引：
+
+MyISAM引 擎使用B+Tree作为索引结构，**叶节点的data域存放的是数据记录的地址**。下图是MyISAM主键索引的原理图：
+
+[![主键索引](14-MySQL 面试题.assets/d49d260fc1eb8f992df0401b70d70e3d.png)](http://static.iocoder.cn/d49d260fc1eb8f992df0401b70d70e3d)主键索引
+
+- 这里设表一共有三列，假设我们以 Col1 为主键，上图是一个 MyISAM 表的主索引（Primary key）示意。可以看出 MyISAM 的索引文件仅仅保存数据记录的地址。
+
+2）辅助索引：
+
+**在 MyISAM 中，主索引和辅助索引在结构上没有任何区别，只是主索引要求 key 是唯一的，而辅助索引的 key 可以重复。**如果我们在 Col2 上建立一个辅助索引，则此索引的结构如下图所示：
+
+[![辅助索引](14-MySQL 面试题.assets/2fb922405a35479fa99eb2de4708638c.png)](http://static.iocoder.cn/2fb922405a35479fa99eb2de4708638c)辅助索引
+
+- 同样也是一颗 B+Tree ，data 域保存数据记录的地址。因此，**MyISAM 中索引检索的算法为首先按照 B+Tree 搜索算法搜索索引，如果指定的 Key 存在，则取出其 data 域的值，然后以 data 域的值为地址，读取相应数据记录。**
+
+MyISAM 的索引方式也叫做“**非聚集**”的，之所以这么称呼是为了与InnoDB 的聚集索引区分。
+
+🦅 **MyISAM 索引与 InnoDB 索引的区别？**
+
+- InnoDB 索引是聚簇索引，MyISAM 索引是非聚簇索引。
+
+- InnoDB 的主键索引的叶子节点存储着行数据，因此主键索引非常高效。
+
+- MyISAM 索引的叶子节点存储的是行数据地址，需要再寻址一次才能得到数据。
+
+- InnoDB 非主键索引的叶子节点存储的是主键和其他带索引的列数据，因此查询时做到覆盖索引会非常高效。
+
+  > 覆盖索引，指的是基于非主键索引查询，但是查询字段只有主键 ID ，那么在二级索引中就可以查找到。
+
+## 【重点】请说说 MySQL 的四种事务隔离级别？
+
+> 艿艿：这是面试中最常见的问题。如果回答不对，可能就被抬走了。
+
+事务就是对一系列的数据库操作（比如插入多条数据）进行统一的提交或回滚操作，如果插入成功，那么一起成功，如果中间有一条出现异常，那么回滚之前的所有操作。
+
+这样可以防止出现脏数据，防止数据库数据出现问题。
+
+🦅 **事务的特性指的是？**
+
+指的是 **ACID** ，如下图所示：
+
+[![事务的特性](14-MySQL 面试题.assets/06.png)](http://static.iocoder.cn/images/Spring/2018-12-24/06.png)事务的特性
+
+1. **原子性** Atomicity ：一个事务（transaction）中的所有操作，或者全部完成，或者全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被恢复（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。即，事务不可分割、不可约简。
+2. **一致性** Consistency ：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设[约束](https://zh.wikipedia.org/wiki/数据完整性)、[触发器](https://zh.wikipedia.org/wiki/触发器_(数据库))、[级联回滚](https://zh.wikipedia.org/w/index.php?title=级联回滚&action=edit&redlink=1)等。
+3. **隔离性** Isolation ：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。
+4. **持久性** Durability ：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。
+
+🦅 **事务的并发问题？**
+
+实际场景下，事务并不是串行的，所以会带来如下三个问题：
+
+- 1、脏读：事务 A 读取了事务 B 更新的数据，然后 B 回滚操作，那么 A 读取到的数据是脏数据。
+- 2、不可重复读：事务 A 多次读取同一数据，事务 B 在事务 A 多次读取的过程中，对数据作了更新并提交，导致事务 A 多次读取同一数据时，结果不一致。
+- 3、幻读：系统管理员 A 将数据库中所有学生的成绩从具体分数改为 ABCDE 等级，但是系统管理员 B 就在这个时候插入了一条具体分数的记录，当系统管理员 A 改结束后发现还有一条记录没有改过来，就好像发生了幻觉一样，这就叫幻读。
+
+小结：不可重复读的和幻读很容易混淆，不可重复读侧重于修改，幻读侧重于新增或删除。解决不可重复读的问题只需锁住满足条件的行，解决幻读需要锁表。
+
+🦅 **MySQL 事务隔离级别会产生的并发问题？**
+
+事务定义了四种事务隔离级别，不同数据库在实现时，产生的并发问题是不同的。
+
+> 不同的隔离级别有不同的现象，并有不同的锁定/并发机制，隔离级别越高，数据库的并发性就越差。
+
+- READ UNCOMMITTED（未提交读）：事务中的修改，即使没有提交，对其他事务也都是可见的。
+
+  > 会导致脏读。
+
+- READ COMMITTED（提交读）：事务从开始直到提交之前，所做的任何修改对其他事务都是不可见的。
+
+  > 会导致不可重复读。
+  >
+  > 这个隔离级别，也可以叫做“不可重复读”。
+
+- REPEATABLE READ（可重复读）：一个事务按相同的查询条件读取以前检索过的数据，其他事务插入了满足其查询条件的新数据。产生幻行。
+
+  > 会导致幻读。
+
+- SERIALIZABLE（可串行化）：强制事务串行执行。
+
+MySQL InnoDB 采用 **MVCC** 来支持高并发，实现结果如下表所示：
+
+> 关于 Oracle 和 PostgreSQL ，需要胖友自己去搜索资料。
+
+| 事务隔离级别                 | 脏读 | 不可重复读 | 幻读    |
+| :--------------------------- | :--- | :--------- | :------ |
+| 读未提交（read-uncommitted） | 是   | 是         | 是      |
+| 读已提交（read-committed）   | 否   | 是         | 是      |
+| 可重复读（repeatable-read）  | 否   | 否         | 是（x） |
+| 串行化（serializable）       | 否   | 否         | 否      |
+
+- MySQL 默认的事务隔离级别为可重复读（repeatable-read） 。
+
+- 上图的 `<X>` 处，**MySQL 通过 MVCC + 事务第一次调用 `SELECT` 语句才生成快照，实现其在可重复读（repeatable-read）的隔离级别下，不存在幻读问题。**也就是说，上图 `<X>` 处，需要改成“否”！！！！想要进一步了解的，可以看看 [《MySQL InnoDB 事务 —— 一致性读(快照读)》](https://blog.csdn.net/cxm19881208/article/details/79415726)、[《MYSQL 当前读和快照读》](https://blog.csdn.net/z69183787/article/details/81709743)、[《【MySQL】当前读、快照读、MVCC》](https://www.cnblogs.com/wwcom123/p/10727194.html) 文章。
+
+  > 艿艿：实际上，艿艿在看完上述几篇文章，仿佛理解了，仿佛又有一点懵逼。后来在看完丁奇老师的 [《MySQL 实战 45 讲》](http://www.iocoder.cn/images/jikeshijian/MySQL实战45讲.jpg) 的「08 | 事务到底是隔离的还是不隔离的？」后，稳了，通透了。
+
+- 😈 记住这个表的方式，我们会发现它是自左上向右下是一个对角线。当然，最好是去理解。
+
+- 具体的实验，胖友可以看看 [《MySQL 的四种事务隔离级别》](https://www.cnblogs.com/huanongying/p/7021555.html) 。
+
+- 有些资料说可重复读解决了幻读，实际是存在的，可以通过 `SELECT xxx FROM t WHERE id = ? FOR UPDATE` 的方式，获得到悲观锁，禁止其它事务操作对应的数据，从而解决幻读问题。感兴趣的胖友，可以看看如下文章：
+
+  - 必读 [《MySQL 幻读的详解、实例及解决办法》](https://segmentfault.com/a/1190000016566788) 案例性更强，易懂。
+
+    > 其实 RR 也是可以避免幻读的，通过对 select 操作手动加 行X锁（SELECT … FOR UPDATE 这也正是 SERIALIZABLE 隔离级别下会隐式为你做的事情），同时还需要知道，即便当前记录不存在，比如 id = 1 是不存在的，当前事务也会获得一把记录锁（因为InnoDB的行锁锁定的是索引，故记录实体存在与否没关系，存在就加 行X锁，不存在就加 next-key lock间隙X锁），其他事务则无法插入此索引的记录，故杜绝了幻读。
+
+  - 选读 [《MySQL 的 InnoDB 的幻读问题》](http://blog.sina.com.cn/s/blog_499740cb0100ugs7.html) 原理性更强，读懂会很爽。
+
+  - 随意 [《Innodb 中 RR 隔离级别能否防止幻读？》](https://github.com/Yhzhtk/note/issues/42) 一个简单的讨论。
+
+## 【重点】请说说 MySQL 的锁机制？
+
+表锁是日常开发中的常见问题，因此也是面试当中最常见的考察点，当多个查询同一时刻进行数据修改时，就会产生并发控制的问题。MySQL 的共享锁和排他锁，就是读锁和写锁。
+
+- 共享锁：不堵塞，多个用户可以同时读一个资源，互不干扰。
+- 排他锁：一个写锁会阻塞其他的读锁和写锁，这样可以只允许一个用户进行写入，防止其他用户读取正在写入的资源。
+
+🦅 **锁的粒度？**
+
+- 表锁：系统开销最小，会锁定整张表，MyIsam 使用表锁。
+- 行锁：最大程度的支持并发处理，但是也带来了最大的锁开销，InnoDB 使用行锁。
+
+🦅 **什么是悲观锁？什么是乐观锁？**
+
+1）悲观锁
+
+它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。
+
+在悲观锁的情况下，为了保证事务的隔离性，就需要一致性锁定读。读取数据时给加锁，其它事务无法修改这些数据。修改删除数据时也要加锁，其它事务无法读取这些数据。
+
+> 艿艿：悲观锁，就是我们上面看到的共享锁和排他锁。
+
+2）乐观锁
+
+相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。
+
+而乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本（ Version ）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。
+
+> 艿艿：乐观锁，实际就是通过版本号，从而实现 CAS 原子性更新。
+
+🦅 **什么是死锁？**
+
+多数情况下，可以认为如果一个资源被锁定，它总会在以后某个时间被释放。而死锁发生在当多个进程访问同一数据库时，其中每个进程拥有的锁都是其他进程所需的，由此造成每个进程都无法继续下去。简单的说，进程 A 等待进程 B 释放他的资源，B 又等待 A 释放他的资源，这样就互相等待就形成死锁。
+
+虽然进程在运行过程中，可能发生死锁，但死锁的发生也必须具备一定的条件，死锁的发生必须具备以下四个必要条件：
+
+- 互斥条件：指进程对所分配到的资源进行排它性使用，即在一段时间内某资源只由一个进程占用。如果此时还有其它进程请求资源，则请求者只能等待，直至占有资源的进程用毕释放。
+- 请求和保持条件：指进程已经保持至少一个资源，但又提出了新的资源请求，而该资源已被其它进程占有，此时请求进程阻塞，但又对自己已获得的其它资源保持不放。
+- 不剥夺条件：指进程已获得的资源，在未使用完之前，不能被剥夺，只能在使用完时由自己释放。
+- 环路等待条件：指在发生死锁时，必然存在一个进程——资源的环形链，即进程集合 {P0，P1，P2，•••，Pn} 中的 P0 正在等待一个 P1 占用的资源；P1 正在等待 P2 占用的资源，……，Pn 正在等待已被 P0 占用的资源。
+
+下列方法有助于最大限度地降低死锁：
+
+- 设置获得锁的超时时间。
+
+  > 通过超时，至少保证最差最差最差情况下，可以有退出的口子。
+
+- 按同一顺序访问对象。
+
+  > 这个是最重要的方式。
+
+- 避免事务中的用户交互。
+
+- 保持事务简短并在一个批处理中。
+
+- 使用低隔离级别。
+
+- 使用绑定连接。
+
+🦅 **MySQL 中 InnoDB 引擎的行锁是通过加在什么上完成(或称实现)的？为什么是这样子的？？**
+
+InnoDB 是基于索引来完成行锁。例如：`SELECT * FROM tab_with_index WHERE id = 1 FOR UPDATE` 。
+
+- `FOR UPDATE` 可以根据条件来完成**行锁**锁定，并且 id 是有索引键的列,如果 id 不是索引键那么 InnoDB 将完成**表锁**，并发将无从谈起。
+
+🦅 **关于熟悉 MySQL 的锁机制？**
+
+> 艿艿：这个问题，艿艿也没特别研究，先 mark 在这里。
+
+- gap 锁
+
+- next-key 锁
+
+- Innodb 的行锁是怎么实现的？
+
+  > Innodb 的锁的策略为 next-key 锁，即 record lock + gap lock ，是通过在 index 上加 lock 实现的。
+  >
+  > - 如果 index 为 unique index ，则降级为 record lock 行锁。
+  > - 如果是普通 index ，则为 next-key lock 。
+  > - 如果没有 index ，则直接锁住全表，即表锁。
+
+- MyISAM 的表锁是怎么实现的？
+
+  > MyISAM 直接使用表锁。
+
+## 【重要】MySQL 查询执行顺序？
+
+MySQL 查询执行的顺序是：
+
+```
+(1)     SELECT
+(2)     DISTINCT <select_list>
+(3)     FROM <left_table>
+(4)     <join_type> JOIN <right_table>
+(5)     ON <join_condition>
+(6)     WHERE <where_condition>
+(7)     GROUP BY <group_by_list>
+(8)     HAVING <having_condition>
+(9)     ORDER BY <order_by_condition>
+(10)    LIMIT <limit_number>
+```
+
+具体的，可以看看 [《SQL 查询之执行顺序解析》](http://zouzls.github.io/2017/03/23/SQL查询之执行顺序解析/) 文章。
+
+## 【重要】聊聊 MySQL SQL 优化？
+
+可以看看如下几篇文章：
+
+- [《PHP 面试之 MySQL 查询优化》](https://www.jianshu.com/p/ab958a4823d1)
+- [《【面试】【MySQL常见问题总结】【03】》](https://blog.csdn.net/DERRANTCM/article/details/51534411) 第 078、095、105 题
+
+另外，除了从 SQL 层面进行优化，也可以从服务器硬件层面，进一步优化 MySQL 。具体可以看看 [《MySQL 数据库性能优化之硬件优化》](https://blog.csdn.net/bemavery/article/details/46241533) 。
+
+## 【加分】什么是 MVCC ？
+
+> 艿艿：这是一个面试的加分题，一些大厂比较喜欢问，例如蚂蚁金服。
+
+多版本并发控制（MVCC），是一种用来**解决读-写冲突**的无锁并发控制，也就是为事务分配单向增长的时间戳，为每个修改保存一个版本，版本与事务时间戳关联，读操作只读该事务开始前的数据库的快照。 这样在读操作不用阻塞写操作，写操作不用阻塞读操作的同时，避免了脏读和不可重复读。
+
+推荐可以看看如下资料：
+
+- 沈询 [《在线分布式数据库原理与实践》](https://www.imooc.com/learn/272)
+
+  > 一共 1 小时 53 分钟，有趣，牛逼，强烈推荐！！！
+
+- 钟延辉
+
+  - [《分布式数据库 MVCC 技术探秘 (1)》](https://mp.weixin.qq.com/s/sOxLZlXRYR-zZKStE7qAwg)
+  - [《分布式数据库 MVCC 技术探秘(2): 混合逻辑时钟》](https://mp.weixin.qq.com/s/8lX3Gyq4J5vLHETtG01EdA)
+
+## 编写 SQL 查询语句的考题合集
+
+因为考题比较多，艿艿就不一一列举，瞄了一些还不错的文章，如下：
+
+- [《10 道 MySQL 查询语句面试题》](https://www.yanxurui.cc/posts/mysql/2016-11-10-10-sql-interview-questions/)
+- [《MySQL 开发面试题》](https://www.cnblogs.com/geaozhang/p/6839297.html)
+- [《企业面试题｜最常问的 MySQL 面试题集合（二）》](https://juejin.im/entry/5b57ebdcf265da0f61320e6f)
+
+## MySQL 数据库 CPU 飙升到 500% 的话，怎么处理？
+
+当 CPU 飙升到 500% 时，先用操作系统命令 top 命令观察是不是 mysqld 占用导致的，如果不是，找出占用高的进程，并进行相关处理。
+
+> 如果此时是 IO 压力比较大，可以使用 iostat 命令，定位是哪个进程占用了磁盘 IO 。
+
+如果是 mysqld 造成的，使用 `show processlist` 命令，看看里面跑的 Session 情况，是不是有消耗资源的 SQL 在运行。找出消耗高的 SQL ，看看执行计划是否准确， index 是否缺失，或者实在是数据量太大造成。一般来说，肯定要 kill 掉这些线程(同时观察 CPU 使用率是否下降)，等进行相应的调整(比如说加索引、改 SQL 、改内存参数)之后，再重新跑这些 SQL。
+
+> 也可以查看 MySQL 慢查询日志，看是否有慢 SQL 。
+
+也有可能是每个 SQL 消耗资源并不多，但是突然之间，有大量的 Session 连进来导致 CPU 飙升，这种情况就需要跟应用一起来分析为何连接数会激增，再做出相应的调整，比如说限制连接数等。
+
+🦅 **在 MySQL 服务器运行缓慢的情况下输入什么命令能缓解服务器压力？**
+
+> 这个回答，和上面的回答思路是差不多的，优秀在更有层次感。
+
+1）检查系统的状态
+
+通过操作系统的一些工具检查系统的状态，比如 CPU、内存、交换、磁盘的利用率，根据经验或与系统正常时的状态相比对，有时系统表面上看起来看空闲，这也可能不是一个正常的状态，因为 CPU 可能正等待IO的完成。除此之外，还应观注那些占用系统资源(CPU、内存)的进程。
+
+- 使用 sar 来检查操作系统是否存在 IO 问题。
+- 使用 vmstat 监控内存 CPU 资源。
+- 磁盘 IO 问题，处理方式：做 raid10 提高性能 。
+- 网络问题，telnet 一下 MySQL 对外开放的端口。如果不通的话，看看防火墙是否正确设置了。另外，看看 MySQ L是不是开启了 skip-networking 的选项，如果开启请关闭。
+
+2）检查 MySQL 参数
+
+- max_connect_errors
+- connect_timeout
+- skip-name-resolve
+- slave-net-timeout=seconds
+- master-connect-retry
+
+3）检查 MySQL 相关状态值
+
+- 关注连接数
+- 关注下系统锁情况
+- 关注慢查询（slow query）日志
+
+# 运维
+
+理解一遍，即使有蛮多不会，也不要担心太多。
+
+## Innodb 的事务与日志的实现方式
+
+🦅 **有多少种日志？**
+
+- redo 日志
+- undo 日志
+
+🦅 **日志的存放形式？**
+
+- redo：在页修改的时候，先写到 redo log buffer 里面， 然后写到 redo log 的文件系统缓存里面(fwrite)，然后再同步到磁盘文件（fsync）。
+- undo：在 MySQL5.5 之前，undo 只能存放在 ibdata *文件里面， 5.6 之后，可以通过设置 innodb_undo_tablespaces 参数把 undo log 存放在 ibdata* 之外。
+
+🦅 **事务是如何通过日志来实现的，说得越深入越好**
+
+> 艿艿：这个流程的理解还是比较简单的，实际思考实现感觉还是蛮复杂的。
+
+基本流程如下：
+
+- 因为事务在修改页时，要先记 undo ，在记 undo 之前要记 undo 的 redo， 然后修改数据页，再记数据页修改的 redo。 redo（里面包括 undo 的修改）一定要比数据页先持久化到磁盘。
+- 当事务需要回滚时，因为有 undo，可以把数据页回滚到前镜像的状态。
+- 崩溃恢复时，如果 redo log 中事务没有对应的 commit 记录，那么需要用 undo 把该事务的修改回滚到事务开始之前。如果有 commit 记录，就用 redo 前滚到该事务完成时并提交掉。
+
+## MySQL binlog 的几种日志录入格式以及区别
+
+🦅 **各种日志格式的涵义**
+
+binlog 有三种格式类型，分别如下：
+
+1）Statement
+
+每一条会修改数据的 SQL 都会记录在 binlog 中。
+
+- 优点：不需要记录每一行的变化，减少了 binlog 日志量，节约了 IO，提高性能。(相比 row 能节约多少性能与日志量，这个取决于应用的 SQL 情况，正常同一条记录修改或者插入 row 格式所产生的日志量还小于 Statement 产生的日志量，但是考虑到如果带条件的 update 操作，以及整表删除，alter 表等操作，ROW 格式会产生大量日志，因此在考虑是否使用 ROW 格式日志时应该跟据应用的实际情况，其所产生的日志量会增加多少，以及带来的 IO 性能问题。)
+
+- 缺点：由于记录的只是执行语句，为了这些语句能在 slave 上正确运行，因此还必须记录每条语句在执行的时候的一些相关信息，以保证所有语句能在 slave 得到和在 master 端执行时候相同 的结果。另外 MySQL 的复制，像一些特定函数功能，slave 可与 master 上要保持一致会有很多相关问题(如 `sleep()` 函数，`last_insert_id()`，以及 user-defined functions(udf) 会出现问题)。
+
+- 使用以下函数的语句也无法被复制：
+
+  - `LOAD_FILE()`
+
+  - `UUID()`
+
+  - `USER()`
+
+  - `FOUND_ROWS()`
+
+  - `SYSDATE()` (除非启动时启用了 `--sysdate-is-now` 选项)
+
+    > 同时在 INSERT …SELECT 会产生比 RBR 更多的行级锁 。
+
+2）Row
+
+不记录 SQL 语句上下文相关信息，仅保存哪条记录被修改。
+
+- 优点：binlog 中可以不记录执行的 SQL 语句的上下文相关的信息，仅需要记录那一条记录被修改成什么了。所以 rowlevel 的日志内容会非常清楚的记录下每一行数据修改的细节。而且不会出现某些特定情况下的存储过程，或 function ，以及 trigger 的调用和触发无法被正确复制的问题。
+- 缺点：所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容,比如一条 Update 语句，修改多条记录，则 binlog 中每一条修改都会有记录，这样造成 binlog 日志量会很大，特别是当执行 alter table 之类的语句的时候，由于表结构修改，每条记录都发生改变，那么该表每一条记录都会记录到日志中。
+
+3）Mixedlevel
+
+是以上两种 level 的混合使用。
+
+- 一般的语句修改使用 Statement 格式保存 binlog 。
+- 如一些函数，statement 无法完成主从复制的操作，则采用 Row 格式保存 binlog 。
+
+MySQL 会根据执行的每一条具体的 SQL 语句来区分对待记录的日志形式，也就是在 Statement 和 Row 之间选择 一种。
+
+新版本的 MySQL 中对 row level 模式也被做了优化，并不是所有的修改都会以 row level 来记录。
+
+- 像遇到表结构变更的时候就会以 Statement 模式来记录。
+- 至于 Update 或者 Delete 等修改数据的语句，还是会记录所有行的变更，即使用 Row 模式。
+
+🦅 **适用场景？**
+
+在一条 SQL 操作了多行数据时， Statement 更节省空间，Row 更占用空间。但是， Row 模式更可靠。
+
+因为，互联网公司，使用 MySQL 的功能相对少，基本不使用存储过程、触发器、函数的功能，选择默认的语句模式，Statement Level（默认）即可。
+
+🦅 **结合第一个问题，每一种日志格式在复制中的优劣？**
+
+- Statement 可能占用空间会相对小一些，传送到 slave 的时间可能也短，但是没有 Row 模式的可靠。
+- Row 模式在操作多行数据时更占用空间，但是可靠。
+
+所以，这是在占用空间和可靠之间的选择。
+
+**如何在线正确清理 MySQL binlog？**
+
+MySQL 中的 binlog 日志记录了数据中的数据变动，便于对数据的基于时间点和基于位置的恢复。但日志文件的大小会越来越大，占用大量的磁盘空间，因此需要定时清理一部分日志信息。
+
+```
+# 首先查看主从库正在使用的binlog文件名称
+show master(slave) status
+
+# 删除之前一定要备份
+purge master logs before'2017-09-01 00:00:00'; # 删除指定时间前的日志
+purge master logs to'mysql-bin.000001'; # 删除指定的日志文件
+
+# 自动删除：通过设置binlog的过期时间让系统自动删除日志
+show variables like 'expire_logs_days'; # 查看过期时间
+set global expire_logs_days = 30; # 设置过期时间
+```
+
+## MySQL 主从复制的流程是怎么样的？
+
+MySQL 的主从复制是基于如下 3 个线程的交互（多线程复制里面应该是 4 类线程）：
+
+- 1、Master 上面的 binlog dump 线程，该线程负责将 master 的 binlog event 传到 slave 。
+- 2、Slave 上面的 IO 线程，该线程负责接收 Master 传过来的 binlog，并写入 relay log 。
+- 3、Slave 上面的 SQL 线程，该线程负责读取 relay log 并执行。
+- 4、如果是多线程复制，无论是 5.6 库级别的假多线程还是 MariaDB 或者 5.7 的真正的多线程复制， SQL 线程只做 coordinator ，只负责把 relay log 中的 binlog 读出来然后交给 worker 线程， woker 线程负责具体 binlog event 的执行。
+
+🦅 **MySQL 如何保证复制过程中数据一致性？**
+
+> 艿艿：这个问题比较难，理解不了也没问题。我自己也没完全理解，主要是网络找到这个答案，后续有精力在研究。
+
+- 1、在 MySQL5.5 以及之前， slave 的 SQL 线程执行的 relay log 的位置只能保存在文件（ relay-log.info）里面，并且该文件默认每执行 10000 次事务做一次同步到磁盘， 这意味着 slave 意外 crash 重启时， SQL 线程执行到的位置和数据库的数据是不一致的，将导致复制报错，如果不重搭复制，则有可能会导致数据不一致。
+  - MySQL 5.6 引入参数 relay_log_info_repository，将该参数设置为 TABLE 时， MySQL 将 SQL 线程执行到的位置存到 mysql.slave_relay_log_info 表，这样更新该表的位置和 SQL 线程执行的用户事务绑定成一个事务，这样 slave 意外宕机后，slave 通过 innodb 的崩溃恢复可以把 SQL 线程执行到的位置和用户事务恢复到一致性的状态。
+- 2、MySQL 5.6 引入 GTID 复制，每个 GTID 对应的事务在每个实例上面最多执行一次， 这极大地提高了复制的数据一致性。
+- 3、MySQL 5.5 引入半同步复制， 用户安装半同步复制插件并且开启参数后，设置超时时间，可保证在超时时间内如果 binlog 不传到 slave 上面，那么用户提交事务时不会返回，直到超时后切成异步复制，但是如果切成异步之前用户线程提交时在 master 上面等待的时候，事务已经提交，该事务对 master 上面的其他 session 是可见的，如果这时 master 宕机，那么到 slave 上面该事务又不可见了，该问题直到 5.7 才解决。
+- 4、MySQL 5.7 引入无损半同步复制，引入参 rpl_semi_sync_master_wait_point，该参数默认为 after_sync，指的是在切成半同步之前，事务不提交，而是接收到 slave 的 ACK 确认之后才提交该事务，从此，复制真正可以做到无损的了。
+- 5、可以再说一下 5.7 的无损复制情况下， master 意外宕机，重启后发现有 binlog 没传到 slave 上面，这部分 binlog 怎么办？？？分 2 种情况讨论， 1 宕机时已经切成异步了， 2 是宕机时还没切成异步？？？ 这个怎么判断宕机时有没有切成异步呢？？？ 分别怎么处理？？？
+
+🦅 **MySQL 如何解决主从复制的延时性？**
+
+5.5 是单线程复制，5.6 是多库复制（对于单库或者单表的并发操作是没用的），5.7 是真正意义的多线程复制，它的原理是基于 group commit， 只要 master 上面的事务是 group commit 的，那 slave 上面也可以通过多个 worker线程去并发执行。 和 MairaDB10.0.0.5 引入多线程复制的原理基本一样。
+
+🦅 **工作遇到的复制 bug 的解决方法？**
+
+5.6 的多库复制有时候自己会停止，我们写了一个脚本重新 start slave 。
+
+🦅 **你是否做过主从一致性校验，如果有，怎么做的，如果没有，你打算怎么做？**
+
+主从一致性校验有多种工具 例如 checksum、mysqldiff、pt-table-checksum 等。
+
+## 聊聊 MySQL 备份方式？备份策略是怎么样的？
+
+具体的，胖友可以看看 [《MySQL 高级备份策略》](http://www.qinglin.net/1015.html) 。主要有几个知识点：
+
+- 数据的备份类型
+
+  - 【常用】完全备份
+
+    > 这是大多数人常用的方式，它可以备份整个数据库，包含用户表、系统表、索引、视图和存储过程等所有数据库对象。但它需要花费更多的时间和空间，所以，一般推荐一周做一次完全备份。
+
+  - 增量备份
+
+    > 它是只备份数据库一部分的另一种方法，它不使用事务日志，相反，它使用整个数据库的一种新映象。它比最初的完全备份小，因为它只包含自上次完全备份以来所改变的数据库。它的优点是存储和恢复速度快。推荐每天做一次差异备份。
+
+  - 【常用】事务日志备份
+
+    > 事务日志是一个单独的文件，它记录数据库的改变，备份的时候只需要复制自上次备份以来对数据库所做的改变，所以只需要很少的时间。为了使数据库具有鲁棒性，推荐每小时甚至更频繁的备份事务日志。
+
+  - 文件备份
+
+    > 数据库可以由硬盘上的许多文件构成。如果这个数据库非常大，并且一个晚上也不能将它备份完，那么可以使用文件备份每晚备份数据库的一部分。由于一般情况下数据库不会大到必须使用多个文件存储，所以这种备份不是很常用。
+
+- 备份数据的类型
+
+  - 热备份
+  - 温备份
+  - 冷备份
+
+- 备份工具
+
+  - cp
+  - mysqldump
+  - xtrabackup
+  - lvm2 快照
+
+🦅 **MySQL 几种备份方式？**
+
+MySQL 一般有 3 种备份方式。
+
+1）逻辑备份
+
+使用 MySQL 自带的 mysqldump 工具进行备份。备份成sql文件形式。
+
+- 优点：最大好处是能够与正在运行的 MySQL 自动协同工作，在运行期间可以确保备份是当时的点，它会自动将对应操作的表锁定，不允许其他用户修改(只能访问)。可能会阻止修改操作。SQL 文件通用方便移植。
+- 缺点：备份的速度比较慢。如果是数据量很多的时候，就很耗时间。如果数据库服务器处在提供给用户服务状态，在这段长时间操作过程中，意味着要锁定表(一般是读锁定，只能读不能写入数据)，那么服务就会影响的。
+
+2）物理备份
+
+> 艿艿：因为现在主流是 InnoDB ，所以基本不再考虑这种方式。
+
+直接拷贝只适用于 MyISAM 类型的表。这种类型的表是与机器独立的。但实际情况是，你设计数据库的时候不可能全部使用 MyISAM 类型表。你也不可能因为 MyISAM 类型表与机器独立，方便移植，于是就选择这种表，这并不是选择它的理由。
+
+- 缺点：你不能去操作正在运行的 MySQL 服务器(在拷贝的过程中有用户通过应用程序访问更新数据，这样就无法备份当时的数据)，可能无法移植到其他机器上去。
+
+3）双机热备份。
+
+当数据量太大的时候备份是一个很大的问题，MySQL 数据库提供了一种主从备份的机制，也就是双机热备。
+
+- 优点：适合数据量大的时候。现在明白了，大的互联网公司对于 MySQL 数据备份，都是采用热机备份。搭建多台数据库服务器，进行主从复制。
+
+🦅 **数据库不能停机，请问如何备份? 如何进行全备份和增量备份?**
+
+可以使用逻辑备份和双机热备份。
+
+- 完全备份：完整备份一般一段时间进行一次，且在网站访问量最小的时候，这样常借助批处理文件定时备份。主要是写一个批处理文件在里面写上处理程序的绝对路径然后把要处理的东西写在后面，即完全备份数据库。
+- 增量备份：对 ddl 和 dml 语句进行二进制备份。且 5.0 无法增量备份，5.1 后可以。如果要实现增量备份需要在 `my.ini` 文件中配置备份路径即可，重启 MySQL 服务器，增量备份就启动了。
+
+🦅 **你的备份工具的选择？备份计划是怎么样的？**
+
+视库的大小来定，一般来说 100G 内的库，可以考虑使用 mysqldump 来做，因为 mysqldump 更加轻巧灵活，备份时间选在业务低峰期，可以每天进行都进行全量备份(mysqldump 备份出来的文件比较小，压缩之后更小)。
+
+100G 以上的库，可以考虑用 xtrabackup 来做，备份速度明显要比 mysqldump 要快。一般是选择一周一个全备，其余每天进行增量备份，备份时间为业务低峰期。
+
+> 艿艿：一般情况下，选择每周备份 + 每天增量备份比较靠谱。
+
+🦅 **备份恢复时间是多长？**
+
+物理备份恢复快，逻辑备份恢复慢。
+
+这里跟机器，尤其是硬盘的速率有关系，以下列举几个仅供参考：
+
+- 20G 的 2 分钟（mysqldump）
+- 80G 的 30分钟（mysqldump)
+- 111G 的 30分钟（mysqldump)
+- 288G 的 3 小时（xtrabackup)
+- 3T 的 4 小时（xtrabackup)
+
+逻辑导入时间一般是备份时间的 5 倍以上。
+
+🦅 **备份恢复失败如何处理？**
+
+首先在恢复之前就应该做足准备工作，避免恢复的时候出错。比如说备份之后的有效性检查、权限检查、空间检查等。如果万一报错，再根据报错的提示来进行相应的调整。
+
+🦅 **mysqldump 和 xtrabackup 实现原理？**
+
+1）mysqldump
+
+mysqldump 是最简单的逻辑备份方式。
+
+- 在备份 MyISAM 表的时候，如果要得到一致的数据，就需要锁表，简单而粗暴。
+- 在备份 InnoDB 表的时候，加上 `–master-data=1 –single-transaction` 选项，在事务开始时刻，记录下 binlog pos 点，然后利用 MVCC 来获取一致的数据，由于是一个长事务，在写入和更新量很大的数据库上，将产生非常多的 undo ，显著影响性能，所以要慎用。
+- 优点：简单，可针对单表备份，在全量导出表结构的时候尤其有用。
+- 缺点：简单粗暴，单线程，备份慢而且恢复慢，跨 IDC 有可能遇到时区问题
+
+2）xtrabackup
+
+xtrabackup 实际上是物理备份+逻辑备份的组合。
+
+- 在备份 InnoDB 表的时候，它拷贝 ibd 文件，并一刻不停的监视 redo log 的变化，append 到自己的事务日志文件。在拷贝 ibd 文件过程中，ibd文件本身可能被写”花”，这都不是问题，因为在拷贝完成后的第一个 prepare 阶段，xtrabackup 采用类似于 Innodb 崩溃恢复的方法，把数据文件恢复到与日志文件一致的状态，并把未提交的事务回滚。
+- 如果同时需要备份 MyISAM 表以及 InnoDB 表结构等文件，那么就需要用 `flush tables with lock` 来获得全局锁，开始拷贝这些不再变化的文件，同时获得 binlog 位置，拷贝结束后释放锁，也停止对 redo log 的监视。
+
+🦅 **如何从 mysqldump 产生的全库备份中只恢复某一个库、某一张表？**
+
+具体可见 [《MySQL 全库备份中恢复某个库和某张表以及 mysqldump 参数 –ignore-table 介绍》](http://blog.51cto.com/wujianwei/1959473) 文章。
+
+## 聊聊 MySQL 集群?
+
+> 艿艿：这块艿艿懂的少，主要找了一些网络上的资料。
+
+- [《五大常见的 MySQL 高可用方案》](https://zhuanlan.zhihu.com/p/25960208)
+- [《高性能、高可用、可扩展的 MySQL 集群如何组建？》](https://www.zhihu.com/question/21307639)
+
+🦅 **对于简历中写有熟悉 MySQL 高可用方案？**
+
+我一般先问他现在管理的数据库架构是什么，如果他只说出了主从，而没有说任何 HA 的方案，那么我就可以判断出他没有实际的 HA 经验。
+
+不过这时候也不能就是断定他不懂 MySQL 高可用，也许是没有实际机会去使用，那么我就要问 [MMM](http://www.cnblogs.com/gomysql/p/3671896.html) 以及 [MHA](https://svip.iocoder.cn/MySQL/Interview/MySQL高可用架构之MHA) 以及 [MM + keepalived](http://blog.51cto.com/sumongodb/1953244) 等的原理、实现方式以及它们之间的优势和不足了，一般这种情况下，能说出这个的基本没有。
+
+- MMM 那东西好像不靠谱，据说不稳定，但是有人在用的，和 mysql-router 比较像，都是指定可写的机器和只读机器。
+- MHA 的话一句话说不完，可以搜索下相关博客。
+
+🦅 **使用过其他分支版本的数据库吗？Percona、Mariadb 等。对Percona 的 pxc 集群了解吗？**
+
+除了 Oracle 旗下的 MySQL 外，我还使用过 Percona Server 。
+
+Percona 是在原生 MySQL 的基础上，进行了优化和改进，所以 Percona 的性能比 MySQL 更好。
+
+- 目前，我知道 Percona 提供免费的线程池功能，而社区版的 MySQL 没有线程池的功能（当然，企业版的mysql是有线程池的，但是需要收费）
+- 另外 Percona 还支持 NUMA 等功能。
+
+我熟悉 pxc ，我曾经在测试环境搭建过 pxc ，但是没有在生产上使用，因为目前使用 pxc 的企业不是很多，目前我知道搜狐在用 pxc 。
+
+- pxc 是摒弃 MySQL 主从的概念，即对于 pxc 来说，每个节点都可以读写，并且写一份数据，其他节点会同时拥有，这是一种同步的复制方案（区别于 MySQL 主从的异步复制）。
+
+## 聊聊 MySQL 安全？
+
+感兴趣的胖友，可以看看：
+
+- [《保障 MySQL 安全的14个最佳方法》](http://netsecurity.51cto.com/art/201311/418159.htm)
+- [《详解 MySQL 安全配置》](https://www.freebuf.com/articles/database/36777.html)
+
+## MySQL 有哪些日志？
+
+- 错误日志：记录了当 mysqld 启动和停止时，以及服务器在运行过程中发生任何严重错误时的相关信息。
+
+- 二进制文件：记录了所有的 DDL（数据定义语言）语句和 DML（数据操纵语言）语句，不包括数据查询语句。语句以“事件”的形式保存，它描述了数据的更改过程。（定期删除日志，默认关闭）。
+
+  > 就是我们上面看到的 MySQL binlog 日志。
+
+- 查询日志：记录了客户端的所有语句，格式为纯文本格式，可以直接进行读取。（log 日志中记录了所有数据库的操作，对于访问频繁的系统，此日志对系统性能的影响较大，建议关闭，默认关闭）。
+
+- 慢查询日志：慢查询日志记录了包含所有执行时间超过参数long_query_time（单位：秒）所设置值的 SQL 语句的日志。（纯文本格式）
+
+  > 重要，一定要开启。
+
+另外，错误日志和慢查询日志的详细解释，可以看看 [《MySQL 日志文件之错误日志和慢查询日志详解》](https://blog.csdn.net/xlgen157387/article/details/76019934) 文章。
+
+## 聊聊 MySQL 监控？
+
+**你是如何监控你们的数据库的？**
+
+监控的工具有很多，例如 Zabbix ，Lepus ，我这里用的是 [Lepus](https://github.com/lijiapengsa/lepus) 。
+
+## 对一个大表做在线 DDL ，怎么进行实施的才能尽可能降低影响？
+
+使用 pt-online-schema-change ，具体可以看看 [《MySQL 大表在线 DML 神器–pt-online-schema-change》](https://blog.csdn.net/mchdba/article/details/76253016) 文章。
+
+另外，还有一些其它的工具，胖友可以搜索下。
+
+# 彩蛋
+
+T T 知识点真多，胖友还是重点掌握文初说的几个，不要方，我们能赢。如下是艿艿在网络上找到过的一个 MySQL 问题清单（研发向）：
+
+> - 3-1 数据库架构
+> - 3-2 优化你的索引-运用二叉查找树
+> - 3-3 优化你的索引-运用B树
+> - 3-4 优化你的索引-运用B+树
+> - 3-5 优化你的索引-运用Hash以及BitMap
+> - 3-6 密集索引和稀疏索引的区别
+> - 3-7 索引额外的问题之如何调优Sql
+> - 3-8 索引额外问题之最左匹配原则的成因
+> - 3-9 索引额外问题之索引是建立越多越好吗
+> - 3-10 锁模块之MyISAM与InooDB关于锁方面的区别
+> - 3-11 锁模块之MyISAM与InooDB关于锁方面的区别_2
+> - 3-12 锁模块之数据库事务的四大特性
+> - 3-13 锁模块之事务并发访问产生的问题以及事务隔离机制
+> - 3-14 锁模块之事务并发访问产生的问题以及事务隔离机制_2
+> - 3-15 锁模块之当前读和快照读
+> - 3-16 锁模块之RR如何避免幻读
+> - 3-17 锁模块小结
+> - 3-18 关键语法讲解
+> - 3-19 本章总结
+> - 3-20 彩蛋之面试的三层架构
+
+------
+
+参考与推荐如下文章：
+
+- ranjun940726 [《PHP 面试指南》](https://www.kancloud.cn/ranjun940726/php_interview)
+- 紫葡萄0 [《MySQL 索引的使用和优化》](https://www.jianshu.com/p/07c42e310e67)
+- Ddaidai [《【MySQL】20 个经典面试题》](https://www.jianshu.com/p/977a9e7d80b3)
+- 瘦瘦鸭 [《MySQL 面试知识点总结》](https://segmentfault.com/a/1190000014316316)
+- 立超的专栏 [《MyISAM 和 InnoDB 的索引实现》](https://www.cnblogs.com/zlcxbb/p/5757245.html)
+- 时芥蓝 [《MySQL 面试之必会知识点》](https://www.jianshu.com/p/5052f6a454ef)
+- derrantcm [《【面试】【MySQL常见问题总结】【04】》](https://blog.csdn.net/DERRANTCM/article/details/51535193)
+- mrlapulga [《MySQL 经典面试题》](https://www.mrlapulga.com/?p=59) 提供的面试题，难的想哭。
+- 小麦苗 [《MySQL 笔试面试题集合》](https://yq.aliyun.com/articles/283427) 全的想哭。
\ No newline at end of file
diff --git a/面试题/15-精尽【分库分表】面试题.md b/面试题/15-精尽【分库分表】面试题.md
new file mode 100644
index 0000000..b93898d
--- /dev/null
+++ b/面试题/15-精尽【分库分表】面试题.md
@@ -0,0 +1,327 @@
+# 精尽【分库分表】面试题「最新更新时间：2024-02」
+
+以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。
+
+如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的【分库分表】面试题的大保健。
+
+而题目的难度，艿艿尽量按照从容易到困难的顺序，逐步下去。
+
+## 为什么使用分库分表？
+
+> 如下内容，引用自 Sharding Sphere 的文档，写的很大气。
+>
+> [《ShardingSphere > 概念 & 功能 > 数据分片》](http://shardingsphere.io/document/current/cn/features/sharding/)
+
+传统的将数据集中存储至单一数据节点的解决方案，在**性能、可用性和运维成本**这三方面已经难于满足互联网的海量数据场景。
+
+1）性能
+
+从性能方面来说，由于关系型数据库大多采用 B+ 树类型的索引，在数据量超过阈值的情况下，索引深度的增加也将使得磁盘访问的 IO 次数增加，进而导致查询性能的下降。
+
+同时，高并发访问请求也使得集中式数据库成为系统的最大瓶颈。
+
+2）可用性
+
+从可用性的方面来讲，服务化的无状态型，能够达到较小成本的随意扩容，这必然导致系统的最终压力都落在数据库之上。而单一的数据节点，或者简单的主从架构，已经越来越难以承担。数据库的可用性，已成为整个系统的关键。
+
+3）运维成本
+
+从运维成本方面考虑，当一个数据库实例中的数据达到阈值以上，对于 DBA 的运维压力就会增大。数据备份和恢复的时间成本都将随着数据量的大小而愈发不可控。一般来讲，单一数据库实例的数据的阈值在 1TB 之内，是比较合理的范围。
+
+🦅 **那么为什么不选择 NoSQL 呢？**
+
+在传统的关系型数据库无法满足互联网场景需要的情况下，将数据存储至原生支持分布式的 NoSQL 的尝试越来越多。 但 NoSQL 对 SQL 的不兼容性以及生态圈的不完善，使得它们在与关系型数据库的博弈中始终无法完成致命一击，而关系型数据库的地位却依然不可撼动。
+
+## 什么是分库分表？
+
+数据分片，指按照某个维度将存放在单一数据库中的数据分散地存放至多个数据库或表中以达到提升性能瓶颈以及可用性的效果。数据分片的有效手段是对关系型数据库进行**分库和分表**。
+
+- 分库和分表均可以有效的避免由数据量超过可承受阈值而产生的查询瓶颈。除此之外，分库还能够用于有效的分散对数据库单点的访问量。
+- 分表虽然无法缓解数据库压力，但却能够提供尽量将分布式事务转化为本地事务的可能，一旦涉及到跨库的更新操作，分布式事务往往会使问题变得复杂。
+- 使用多主多从的分片方式，可以有效的避免数据单点，从而提升数据架构的可用性。
+
+通过分库和分表进行数据的拆分来使得各个表的数据量保持在阈值以下，以及对流量进行疏导应对高访问量，是应对高并发和海量数据系统的有效手段。数据分片的拆分方式又分为垂直分片和水平分片。
+
+🦅 **垂直分片**
+
+按照业务拆分的方式称为垂直分片，又称为纵向拆分，它的核心理念是专库专用。 在拆分之前，一个数据库由多个数据表构成，每个表对应着不同的业务。而拆分之后，则是按照业务将表进行归类，分布到不同的数据库中，从而将压力分散至不同的数据库。
+
+下图展示了根据业务需要，将用户表和订单表垂直分片到不同的数据库的方案：
+
+[![垂直分片](http://shardingsphere.jd.com/document/current/img/sharding/vertical_sharding.png)](http://shardingsphere.jd.com/document/current/img/sharding/vertical_sharding.png)垂直分片
+
+垂直分片往往需要对架构和设计进行调整。通常来讲，是来不及应对互联网业务需求快速变化的；而且，它也并无法真正的解决单点瓶颈。 垂直拆分可以缓解数据量和访问量带来的问题，但无法根治。如果垂直拆分之后，表中的数据量依然超过单节点所能承载的阈值，则需要水平分片来进一步处理。
+
+垂直拆分的优点：
+
+- 库表职责单一，复杂度降低，易于维护。
+- 单库或单表压力降低。 相互之间的影响也会降低。
+
+垂直拆分的缺点：
+
+- 部分表关联无法在数据库级别完成，需要在程序中完成。
+- 单表大数据量仍然存在性能瓶颈。
+- 单表或单库高热点访问依旧对 DB 压力非常大。
+- 事务处理相对更为复杂，需要分布式事务的介入。
+- 拆分达到一定程度之后，扩展性会遇到限制。
+
+🦅 **水平分片**
+
+水平分片又称为横向拆分。 相对于垂直分片，它不再将数据根据业务逻辑分类，而是通过某个字段（或某几个字段），根据某种规则将数据分散至多个库或表中，每个分片仅包含数据的一部分。
+
+例如：根据主键分片，偶数主键的记录放入 0 库（或表），奇数主键的记录放入 1 库（或表），如下图所示：
+
+[![水平分片](http://shardingsphere.jd.com/document/current/img/sharding/horizontal_sharding.png)](http://shardingsphere.jd.com/document/current/img/sharding/horizontal_sharding.png)水平分片
+
+水平分片从理论上突破了单机数据量处理的瓶颈，并且扩展相对自由，是分库分表的标准解决方案。
+
+水平拆分的优点：
+
+- 解决单表单库大数据量和高热点访问性能遇到瓶颈的问题。
+- 应用程序端整体架构改动相对较少。
+- 事务处理相对简单。
+- 只要切分规则能够定义好，基本上较难遇到扩展性限制。
+
+水平拆分缺点：
+
+- 拆分规则相对更复杂，很难抽象出一个能够满足整个数据库的切分规则。
+- 后期数据的维护难度有所增加，人为手工定位数据更困难。
+- 产品逻辑将变复杂。比如按年来进行历史数据归档拆分，这个时候在页面设计上就需要约束用户必须要先选择年，然后才能进行查询。
+
+🦅 **总结？**
+
+- 数据表垂直拆分：单表复杂度。
+- 数据库垂直拆分：功能拆分。
+- 水平拆分
+  - 分表：解决单表大数据量问题。
+  - 分库：为了解决单库性能问题。
+
+## 用了分库分表之后，有哪些常见问题？
+
+虽然数据分片解决了性能、可用性以及单点备份恢复等问题，但分布式的架构在获得了收益的同时，也引入了新的问题。
+
+- 面对如此散乱的分库分表之后的数据，应用开发工程师和数据库管理员对数据库的操作变得异常繁重就是其中的重要挑战之一。他们需要知道数据需要从哪个具体的数据库的分表中获取。
+
+- 另一个挑战则是，能够正确的运行在单节点数据库中的 SQL ，在分片之后的数据库中并不一定能够正确运行。
+
+  - 例如，分表导致表名称的修改，或者分页、排序、聚合分组等操作的不正确处理。
+  - 例如，跨节点 join 的问题。
+
+- **跨库事务**也是分布式的数据库集群要面对的棘手事情。
+
+  - 合理采用分表，可以在降低单表数据量的情况下，尽量使用本地事务，善于使用同库不同表可有效避免分布式事务带来的麻烦。
+
+    > 要达到这个效果，需要尽量把同一组数据放到同一组 DB 服务器上。
+    >
+    > 例如说，将同一个用户的订单主表，和订单明细表放到同一个库，那么在创建订单时，还是可以使用相同本地事务。
+
+  - 在不能避免跨库事务的场景，有些业务仍然需要保持事务的一致性。而基于 XA 的分布式事务由于在并发度高的场景中性能无法满足需要，并未被互联网巨头大规模使用，他们大多采用最终一致性的柔性事务代替强一致事务。
+
+- 分布式全局唯一 ID 。
+
+  - 在单库单表的情况下，直接使用数据库自增特性来生成主键ID，这样确实比较简单。
+  - 在分库分表的环境中，数据分布在不同的分表上，不能再借助数据库自增长特性。需要使用全局唯一 ID，例如 UUID、GUID等 。
+
+关于这块，也可以看看 [《分库分表》](https://www.yuque.com/lexiangqizhong/java/ckt9uw) 文章。
+
+## 了解和使用过哪些分库分表中间件？
+
+在将数据库进行分库分表之后，我们一般会引入分库分表的中间件，使之能够达到如下目标。
+
+> 尽量透明化分库分表所带来的影响，让使用方尽量像使用一个数据库一样使用水平分片之后的数据库集群，这是分库分表的主要设计目标。
+
+🦅 **分库分表的实现方式？**
+
+目前，市面上提供的分库分表的中间件，主要有两种实现方式：
+
+- Client 模式
+- Proxy 模式
+
+🦅 **分库分表中间件？**
+
+比较常见的包括：
+
+- Cobar
+- MyCAT
+- Atlas
+- TDDL
+- Sharding Sphere
+
+1）Cobar
+
+阿里 b2b 团队开发和开源的，属于 Proxy 层方案。
+
+早些年还可以用，但是最近几年都没更新了，基本没啥人用，差不多算是被抛弃的状态吧。而且不支持读写分离、存储过程、跨库 join 和分页等操作。
+
+2）MyCAT
+
+基于 Cobar 改造的，属于 Proxy 层方案，支持的功能非常完善，而且目前应该是非常火的而且不断流行的数据库中间件，社区很活跃，也有一些公司开始在用了。但是确实相比于 Sharding Sphere 来说，年轻一些，经历的锤炼少一些。
+
+3）Atlas
+
+360 开源的，属于 Proxy 层方案，以前是有一些公司在用的，但是确实有一个很大的问题就是社区最新的维护都在 5 年前了。所以，现在用的公司基本也很少了。
+
+4）TDDL
+
+淘宝团队开发的，属于 client 层方案。支持基本的 crud 语法和读写分离，但不支持 join、多表查询等语法。目前使用的也不多，因为还依赖淘宝的 diamond 配置管理系统。
+
+5）Sharding Sphere
+
+Sharding Sphere ，可能是目前最好的开源的分库分表解决方案，目前已经进入 Apache 孵化。
+
+Sharding Sphere 提供三种模式：
+
+> 关于每一种模式的介绍，可以看看 [《ShardingSphere > 概览》](http://shardingsphere.io/document/current/cn/overview/)
+
+- Sharding-JDBC
+- Sharding-Proxy
+- Sharding-Sidecar 计划开发中。
+
+其中，Sharding-JDBC 属于 client 层方案，被大量互联网公司所采用。例如，当当、京东金融、中国移动等等。
+
+🦅 **如何选择？**
+
+综上，现在其实建议考量的，就是 Sharding Sphere ，这个可以满足我们的诉求。
+
+Sharding Sphere 的 Sharding-JDBC 方案，这种 Client 层方案的**优点在于不用部署，运维成本低，不需要代理层的二次转发请求，性能很高**，但是如果遇到升级啥的需要各个系统都重新升级版本再发布，各个系统都需要**耦合** sharding-jdbc 的依赖。
+
+> 据艿艿了解到，例如阿里、美团内部，更多使用的是 Client 模式。
+
+Sharding Sphere 的 Sharding-Proxy 方案，这种 Proxy 层方案，可以解决我们平时查询数据库的需求。我们只需要连接一个 Sharding-Proxy ，就可以查询分库分表中的数据。另外，如果我们有跨语言的需求，例如 PHP、GO 等，也可以使用它。
+
+## 如何迁移到分库分表？
+
+一般来说，会有三种方式：
+
+- 1、停止部署法。
+- 2、双写部署法，基于业务层。
+- 3、双写部署法，基于 binlog 。
+
+具体的详细方案，可以看看如下两篇文章：
+
+- [《数据库分库分表后，如何部署上线？》](http://www.iocoder.cn/Fight/After-the-database-sharding-how-to-deploy-online/)
+- [《【面试宝典】如何把单库数据迁移到分库分表？》](http://www.chaiguanxin.com/articles/2018/11/11/1541923418699.html)
+- [《分库分表的面试题3》](https://www.cnblogs.com/daiwei1981/p/9416068.html)
+
+另外，这是另外一个比较相对详细的【双写部署法，基于业务层】的过程：
+
+- 双写 ，老库为主。读操作还是读老库老表，写操作是双写到新老表。
+- 历史数据迁移 dts + 新数据对账校验（job） + 历史数据校验。
+- 切读：读写以新表为主，新表成功就成功了。
+- 观察几天，下掉写老库操作。
+
+另外，飞哥的 [《不停机分库分表迁移》](https://www.jianshu.com/p/223d71421f49) 文章，也非常推荐看看。
+
+🦅 **如何设计可以动态扩容缩容的分库分表方案？**
+
+可以参看 [《如何设计可以动态扩容缩容的分库分表方案？》](https://github.com/doocs/advanced-java/blob/master/docs/high-concurrency/database-shard-dynamic-expand.md) 文章。简单的结论是：
+
+- 提前考虑好容量的规划，避免扩容的情况。
+- 如果真的需要扩容，走上述的 [「如何迁移到分库分表？」](https://svip.iocoder.cn/database-sharding/Interview/#) 提到的方案。
+
+## 什么是分布式主键？怎么实现？
+
+分布式主键的实现方案有很多，可以看看 [《谈谈 ID》](http://www.iocoder.cn/Architecture/talk-about-global-id/) 的总结。
+
+一般来说，目前采用 SnowFlake 的居多，可以看看 [《Sharding-JDBC 源码分析 —— 分布式主键》](http://www.iocoder.cn/Sharding-JDBC/distributed-id/?vip) 的源码的具体实现，比较简单。
+
+## 分片键的选择？
+
+分库分表后，分片键的选择非常重要。一般来说是这样的：
+
+- 信息表，使用 id 进行分片。例如说，文章、商品信息等等。
+- 业务表，使用 user_id 进行分片。例如说，订单表、支付表等等。
+- 日志表，使用 create_time 进行分片。例如说，访问日志、登陆日志等等。
+
+🦅 **分片算法的选择？**
+
+选择好分片键之后，还需要考虑分片算法。一般来说，有如下两种：
+
+- 取余分片算法。例如说，有四个库，那么 user_id 为 10 时，分到第
+
+   
+
+  ```
+  10 % 4 = 2
+  ```
+
+   
+
+  个库。
+
+  - 当然，如果分片键是字符串，则需要先进行 hash 的方式，转换成整形，这样才可以取余。
+  - 当然，如果分片键是整数，也可以使用 hash 的方式。
+
+- 范围算法。
+
+  - 例如说，时间范围。
+
+上述两种算法，各有优缺点。
+
+- 对于取余来说：
+  - 好处，可以平均分配每个库的数据量和请求压力。
+  - 坏处，在于说扩容起来比较麻烦，会有一个数据迁移的过程，之前的数据需要重新计算 hash 值重新分配到不同的库或表。
+- 对于 range 来说：
+  - 好处，扩容的时候很简单，因为你只要预备好，给每个月都准备一个库就可以了，到了一个新的月份的时候，自然而然，就会写新的库了。
+  - 缺点，但是大部分的请求，都是访问最新的数据。实际生产用 range，要看场景。
+
+🦅 **如果查询条件不带分片键，怎么办？**
+
+当查询不带分片键时，则中间件一般会扫描所有库表，然后聚合结果，然后进行返回。
+
+对于大多数情况下，如果每个库表的查询速度还可以，返回结果的速度也是不错的。具体，胖友可以根据自己的业务进行测试。
+
+🦅 **使用 user_id 分库分表后，使用 id 查询怎么办？**
+
+有四种方案。
+
+1）不处理
+
+正如在 [「如果查询条件不带分片键，怎么办？」](https://svip.iocoder.cn/database-sharding/Interview/#) 问题所说，如果性能可以接受，可以不去处理。当然，前提是这样的查询不多，不会给系统带来负担。
+
+2）映射关系
+
+创建映射表，只有 id、user_id 两列字段。使用 id 查询时，先从映射表获得 id 对应的 user_id ，然后再使用 id + user_id 去查询对应的表。
+
+当然，随着业务量的增长，映射表也会越来越大，后续也可能需要进行分库分表。
+
+对于这方式，也可以有一些优化方案。
+
+- 映射表改成缓存到 Redis 等 KV 缓存中。当然，需要考虑如果 Redis 持久化的情况。
+- 将映射表缓存到内存中，减少一次到映射表的查询。
+
+3）基因 id
+
+分库基因：假如通过 user_id 分库，分为 8 个库，采用 user_id % 8 的方式进行路由，此时是由 user_id 的最后 3bit 来决定这行 User 数据具体落到哪个库上，那么这 3bit 可以看为分库基因。那么，如果我们将这 3 bit 参考类似 Snowflake 的方式，融入进入到 id 。
+
+> 艿艿：这里的 3 bit 只是举例子，实际需要考虑自己分多少库表，来决定到底使用多少 bit 。
+
+上面的映射关系的方法需要额外存储映射表，按非 user_id 字段查询时，还需要多一次数据库或 Cache 的访问。通过基因 id ，就可以知道数据所在的库表。
+
+详细说明，可以看看 [《用 uid 分库，uname 上的查询怎么办？》](http://www.10tiao.com/html/249/201704/2651960032/1.html) 文章。
+
+目前，可以从 [《大众点评订单系统分库分表实践》](https://tech.meituan.com/dianping_order_db_sharding.html) 文章中，看到大众点评订单使用了基因 id 。
+
+4）多 sharding column
+
+具体的内容，可以参考 [《分库分表的正确姿势，你 GET 到了么？》](https://yq.aliyun.com/articles/641529) 。当然，这种方案也是比较复杂的方案。
+
+## 如何解决分布式事务？
+
+目前市面上，分布式事务的解决方案还是蛮多的，但是都是基于一个前提，需要保证本地事务。**那么，就对我们在分库分表时，就有相应的要求：数据在分库分表时，需要保证一个逻辑中，能够形成本地事务**。举个例子，创建订单时，我们会插入订单表和订单明细表，那么：
+
+- 如果我们基于这两个表的 id 进行分库分表，将会导致插入的记录被分到不同的库表中，因为创建下单可以购买 n 个商品，那么就会有 1 条订单记录和 n 条 订单明细记录。而这 n 条订单明细记录无法和 1 条订单记录分到一个库表中。
+
+- 如果我们基于这两个表的 user_id 进行分库分表，那么插入的记录被分到相同的库表中。
+
+  > 艿艿：这也是为什么业务表一般使用 user_id 进行分库分表的原因之一。
+
+可能会有胖友有疑问，为什么一定要形成本地事务？在有了本地事务的基础上，通过使用分布式事务的解决方案，协调多个本地事务，形成最终一致性。另外，😈 本地事务在这个过程中，能够保证万一执行失败，再重试时，不会产生脏数据。
+
+## 彩蛋
+
+参考与推荐如下文章：
+
+- [《Sharding Sphere 官方文档》](http://shardingsphere.io/document/current/cn/overview/)
+- boothsun [《分库分表面试准备》](https://www.zybuluo.com/boothsun/note/1107670)
+- butterfly100 [《数据库分库分表思路》](https://www.cnblogs.com/butterfly100/p/9034281.html)
\ No newline at end of file
diff --git a/面试题/16-精尽【分布式事务】面试题.assets/4da5bc0df774ef90e97c6358eb7e632f.webp b/面试题/16-精尽【分布式事务】面试题.assets/4da5bc0df774ef90e97c6358eb7e632f.webp
new file mode 100644
index 0000000..a60c7f6
Binary files /dev/null and b/面试题/16-精尽【分布式事务】面试题.assets/4da5bc0df774ef90e97c6358eb7e632f.webp differ
diff --git a/面试题/16-精尽【分布式事务】面试题.assets/728bf44f14926be91f33c4c7fda15fad.webp b/面试题/16-精尽【分布式事务】面试题.assets/728bf44f14926be91f33c4c7fda15fad.webp
new file mode 100644
index 0000000..163e5e8
Binary files /dev/null and b/面试题/16-精尽【分布式事务】面试题.assets/728bf44f14926be91f33c4c7fda15fad.webp differ
diff --git a/面试题/16-精尽【分布式事务】面试题.assets/80a431c9be51ed67d9c67f7a1de7c2ed.png b/面试题/16-精尽【分布式事务】面试题.assets/80a431c9be51ed67d9c67f7a1de7c2ed.png
new file mode 100644
index 0000000..f9588d6
Binary files /dev/null and b/面试题/16-精尽【分布式事务】面试题.assets/80a431c9be51ed67d9c67f7a1de7c2ed.png differ
diff --git a/面试题/16-精尽【分布式事务】面试题.assets/b1fc3558543e402cb373792eade99e0f.png b/面试题/16-精尽【分布式事务】面试题.assets/b1fc3558543e402cb373792eade99e0f.png
new file mode 100644
index 0000000..385e7e3
Binary files /dev/null and b/面试题/16-精尽【分布式事务】面试题.assets/b1fc3558543e402cb373792eade99e0f.png differ
diff --git a/面试题/16-精尽【分布式事务】面试题.assets/baef17d9dde837632e9a7894cb825cb2.png b/面试题/16-精尽【分布式事务】面试题.assets/baef17d9dde837632e9a7894cb825cb2.png
new file mode 100644
index 0000000..f24a62f
Binary files /dev/null and b/面试题/16-精尽【分布式事务】面试题.assets/baef17d9dde837632e9a7894cb825cb2.png differ
diff --git a/面试题/16-精尽【分布式事务】面试题.assets/c015006c18d7b4a59463fd00d589f2e1.webp b/面试题/16-精尽【分布式事务】面试题.assets/c015006c18d7b4a59463fd00d589f2e1.webp
new file mode 100644
index 0000000..064ee80
Binary files /dev/null and b/面试题/16-精尽【分布式事务】面试题.assets/c015006c18d7b4a59463fd00d589f2e1.webp differ
diff --git a/面试题/16-精尽【分布式事务】面试题.assets/c8f27f0e1107c328476600c4ed2608ec.webp b/面试题/16-精尽【分布式事务】面试题.assets/c8f27f0e1107c328476600c4ed2608ec.webp
new file mode 100644
index 0000000..7e45bb8
Binary files /dev/null and b/面试题/16-精尽【分布式事务】面试题.assets/c8f27f0e1107c328476600c4ed2608ec.webp differ
diff --git a/面试题/16-精尽【分布式事务】面试题.assets/d25d3a43ddbcbc256913e4b6622d88a3.jpeg b/面试题/16-精尽【分布式事务】面试题.assets/d25d3a43ddbcbc256913e4b6622d88a3.jpeg
new file mode 100644
index 0000000..abf6939
Binary files /dev/null and b/面试题/16-精尽【分布式事务】面试题.assets/d25d3a43ddbcbc256913e4b6622d88a3.jpeg differ
diff --git a/面试题/16-精尽【分布式事务】面试题.assets/fca74dec683cdea6b986652feec19958.webp b/面试题/16-精尽【分布式事务】面试题.assets/fca74dec683cdea6b986652feec19958.webp
new file mode 100644
index 0000000..206b4fd
Binary files /dev/null and b/面试题/16-精尽【分布式事务】面试题.assets/fca74dec683cdea6b986652feec19958.webp differ
diff --git a/面试题/16-精尽【分布式事务】面试题.md b/面试题/16-精尽【分布式事务】面试题.md
new file mode 100644
index 0000000..95e0f94
--- /dev/null
+++ b/面试题/16-精尽【分布式事务】面试题.md
@@ -0,0 +1,451 @@
+# 精尽【分布式事务】面试题「最新更新时间：2024-02」
+
+以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。
+
+如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的【分布式事务】面试题的大保健。
+
+而题目的难度，艿艿尽量按照从容易到困难的顺序，逐步下去。
+
+## 什么是分布式事务？
+
+分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。
+
+或者，在换一句话说，分布式事务 = n 个本地事务。通过事务管理器，达到 n 个本地事务要么全部成功，要么全部失败。
+
+## 为什么会有分布式事务？
+
+从本地事务来看，我们可以看为两块，一个是 service 产生多个节点，另一个是 resource 产生多个节点。
+
+😈 可能会有胖说，我们就是一个单体应用，不存在这样的情况。OK ，没问题，那么我们回过头来想想用户下单完成，我们需要给用户发短信。如果发送短信失败，可能是网络抖动的原因，我们是不应该去回滚本地事务，那么此时也可以认为是一个分布式事务。
+
+1）service 多个节点
+
+随着互联网快速发展，微服务，SOA等服务架构模式正在被大规模的使用，举个简单的例子，一个公司之内，用户的资产可能分为好多个部分，比如余额，积分，优惠券等等。在公司内部有可能积分功能由一个微服务团队维护，优惠券又是另外的团队维护。
+
+
+
+这样的话就无法保证积分扣减了之后，优惠券能否扣减成功。
+
+2）resource 多个节点
+
+同样的，互联网发展得太快了，我们的Mysql一般来说装千万级的数据就得进行分库分表，对于一个支付宝的转账业务来说，你给的朋友转钱，有可能你的数据库是在北京，而你的朋友的钱是存在上海，所以我们依然无法保证他们能同时成功。
+
+[![img](16-精尽【分布式事务】面试题.assets/d25d3a43ddbcbc256913e4b6622d88a3.jpeg)](http://static.iocoder.cn/d25d3a43ddbcbc256913e4b6622d88a3)
+
+😈 可能会有胖友说，我们数据没做分库分表，不存在这样的情况。OK，没问题，那么我们回过头来想想最常见的场景，系统里引入了 Redis 做缓存，那么 DB 和 Redis 的一致性问题，就是一种分布式事务的场景。
+
+🦅 **是否真的要分布式事务？**
+
+在说分布式事务的方案之前，首先你一定要明确你是否真的需要分布式事务？
+
+上面说过出现分布式事务的两个原因，其中有个原因是因为微服务过多。我见过太多团队一个人维护几个微服务，太多团队过度设计，搞得所有人疲劳不堪，而微服务过多就会引出分布式事务，这个时候我不会建议你去采用分布式事务的方案，而是请把需要事务的微服务聚合成一个单机服务，使用数据库的本地事务。因为不论任何一种方案都会增加你系统的复杂度，这样的成本实在是太高了，千万不要因为追求某些设计，而引入不必要的成本和复杂度。
+
+当然，如果你是个人的练习 Demo 项目，请使劲的造，拼命的玩。甚至说，我建议你能读完所使用的分布式事务的方案的原理和源码。因为，一旦上了生产，出了问题，你很有可能无从下手~
+
+所以，想清楚你是否需要分布式事务，你是否能够 hold 住分布式事务的解决方案。
+
+## 分布式事务的基础？
+
+数据库的 ACID 满足了数据库本地事务的基础，但是它无法满足分布式事务，这个时候衍生了 CAP 和 BASE 两个经典理论。
+
+🦅 **CAP 理论**
+
+CAP 定理，又被叫作布鲁尔定理。对于设计分布式系统来说(不仅仅是分布式事务)的架构师来说，CAP 就是你的入门理论。
+
+- C (一致性)：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
+- A (可用性)：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
+- P (分区容错性)：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在 C 和 A 之间做出选择。
+
+高可用、数据一致性是很多系统设计的目标，但是分区又是不可避免的事情。我们来看一看分别拥有 CA、CP 和 AP 的情况。
+
+- CA without P：如果不要求 P（不允许分区），则 C（强一致性）和A（可用性）是可以保证的。但其实分区不是你想不想的问题，而是始终会存在，因此 CA 的系统更多的是允许分区后各子系统依然保持 CA 。
+- CP without A：如果不要求 A（可用），相当于每个请求都需要在 Server 之间强一致，而 P（分区）会导致同步时间无限延长，如此 CP 也是可以保证的。很多传统的数据库分布式事务都属于这种模式。
+- AP wihtout C：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。
+
+可能胖友看完之后，会一脸懵逼，可以看看 [《分布式系统理论（一）：CAP 定理》](https://my.oschina.net/lhztt/blog/915533) 文章提供的示例：
+
+- MySQL 主从异步复制是 AP 系统。
+- MySQL 主从半同步复制是 CP 系统。
+- Zookeeper 是 CP 系统。
+- Redis 主从同步是 AP 系统。
+- Eureka 主从同步是 AP 系统。
+
+从上的示例中，**“三选二”是一个伪命题**。不是为了 P（分区容忍性），要在 A 和 C 之间选择一个。分区很少出现，CAP 在大多数时候允许完美的 C 和 A 。但当分区存在或可感知其影响的情况下，就要预备一种策略去探知分区并显式处理其影响。
+
+> 艿艿，如果关于**“三选二”是一个伪命题**无法理解，可以回过头在看一眼“CA without P” ，对比下就好理解了。对于单节点，CA 必然是可以保证的。
+
+另外，关于 CAP 的论证过程，也是蛮有趣的一块内容，感兴趣的胖友，可以自己去搜索下。
+
+🦅 **BASE 理论**
+
+BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性) 三个短语的缩写。是对 CAP 中AP 的一个扩展
+
+1. BA 基本可用：分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。
+2. S 软状态：允许系统中存在中间状态，这个状态不影响系统可用性，这里指的是 CAP 中的不一致。
+3. E 最终一致：最终一致是指经过一段时间后，所有节点数据都将会达到一致。
+
+BASE 解决了 CAP 中理论没有网络延迟，在 BASE 中用软状态和最终一致，保证了延迟后的一致性。
+
+BASE 和 ACID 是相反的，它完全不同于 ACID 的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。
+
+> 对于大部分的分布式应用而言，只要数据在规定的时间内达到最终一致性即可。我们可以把符合传统的 ACID 叫做刚性事务，把满足 BASE 理论的最终一致性事务叫做柔性事务。
+>
+> 一味的追求强一致性，并非最佳方案。对于分布式应用来说，刚柔并济是更加合理的设计方案，即在本地服务中采用强一致事务，在跨系统调用中采用最终一致性。如何权衡系统的性能与一致性，是十分考验架构师与开发者的设计功力的。
+
+**具体到分布式事务的实现上，业界主要采用了 XA 协议的强一致规范以及柔性事务的最终一致规范**。
+
+> 艿艿：所以，市面上的分布式事务的解决方案，除了 XA 协议是强一直的，其他都是最终一致的。
+
+## 分布式事务的实现主要有哪些方案？
+
+分布式事务的实现主要有以下 6 种方案：
+
+- XA 方案
+- TCC 方案
+- 本地消息表
+- 可靠消息最终一致性方案
+- 最大努力通知方案
+- SAGA
+
+## 聊聊 XA 方案？
+
+XA 是 X/Open CAE Specification (Distributed Transaction Processing)模型，它定义的 TM（Transaction Manager）与 RM（Resource Manager）之间进行通信的接口。
+
+Java中 的 `javax.transaction.xa.XAResource` 定义了 XA 接口，它依赖数据库厂商对 jdbc-driver 的具体实现。
+
+- `mysql-connector-java-5.1.30` 的实现可参 `com.mysql.jdbc.jdbc2.optional.MysqlXAConnection` 类。
+
+在 XA 规范中，数据库充当 RM 角色，应用需要充当 TM 的角色，即生成全局的 txId ，调用 XAResource 接口，把多个本地事务协调为全局统一的分布式事务。
+
+目前 XA 有两种实现：
+
+- 基于一阶段提交( 1PC ) 的**弱** XA 。
+- 基于二阶段提交( 2PC ) 的**强** XA 。
+
+### 弱 XA
+
+[![弱 XA 的顺序图](16-精尽【分布式事务】面试题.assets/fca74dec683cdea6b986652feec19958.webp)](http://static.iocoder.cn/fca74dec683cdea6b986652feec19958)弱 XA 的顺序图
+
+- 弱 XA 通过去掉 XA 的 Prepare 阶段，以达到减少资源锁定范围而提升并发性能的效果。典型的实现为在一个业务线程中，遍历所有的数据库连接，依次做 commit 或者 rollback 。
+- 弱 XA 同本地事务相比，性能损耗低，但在事务提交的执行过程中，若出现网络故障、数据库宕机等预期之外的异常，将会造成数据不一致，且无法进行回滚。
+
+🦅 **解决方案？**
+
+基于弱 XA 的事务无需额外的实现成本，相对容易。目前支持的有：
+
+- MyCAT ，具体的源码解析，可以看看 [《MyCAT 源码分析 —— XA 分布式事务》](http://www.iocoder.cn/MyCAT/xa-distributed-transaction/) 。
+- Sharding-Sphere 默认支持。
+
+### 强 XA
+
+[![强 XA 的顺序图](16-精尽【分布式事务】面试题.assets/c8f27f0e1107c328476600c4ed2608ec.webp)](http://static.iocoder.cn/c8f27f0e1107c328476600c4ed2608ec)强 XA 的顺序图
+
+- 二阶段提交是 XA 的标准实现。它将分布式事务的提交拆分为 2 个阶段：prepare 和 commit/rollback 。
+  - 第一阶段：事务管理器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交。
+  - 第二阶段：事务协调器要求每个数据库提交数据，或者回滚数据。
+- 开启 XA 全局事务后，所有子事务会按照本地默认的隔离级别锁定资源，并记录 undo 和 redo 日志。然后由 TM 发起 prepare 投票，询问所有的子事务是否可以进行提交：
+  - 当所有子事务反馈的结果为 “yes” 时，TM 再发起 commit 。
+  - 若其中任何一个子事务反馈的结果为“no”，TM 则发起 rollback 。
+  - 如果在 prepare 阶段的反馈结果为 “yes” ，而 commit 的过程中出现宕机等异常时，则在节点服务重启后，可根据 XA recover 再次进行 commit 补偿，以保证数据的一致性。
+
+🦅 **优点？**
+
+- 尽量保证了数据的强一致，实现成本较低，在各大主流数据库都有自己实现，对于 MySQL 是从 5.5 开始支持。
+
+🦅 **缺点？**
+
+- 单点问题：事务管理器在整个流程中扮演的角色很关键，如果其宕机，比如在第一阶段已经完成，在第二阶段正准备提交的时候事务管理器宕机，资源管理器就会一直阻塞，导致数据库无法使用。
+
+  > 艿艿：如果事务管理器是 Proxy 模式的数据库中间件，并且实现高可用，可能可以解决这个问题。不太肯定，需要到时翻下 Sharding Sphere 的源码。TODO
+
+- 同步阻塞：在准备就绪之后，资源管理器中的资源一直处于阻塞，直到提交完成，释放资源。
+
+- 数据不一致：两阶段提交协议虽然为分布式数据强一致性所设计，但仍然存在数据不一致性的可能，比如在第二阶段中，假设协调者发出了事务commit 的通知，但是因为网络问题该通知仅被一部分参与者所收到并执行了 commit 操作，其余的参与者则因为没有收到通知一直处于阻塞状态，这时候就产生了数据的不一致性。
+
+  > 艿艿：此处的数据不一致也问题不大，因为使用 xa 会锁定记录，无法被访问。
+
+🦅 解决方案？
+
+- Sharding Sphere
+
+  > Sharding Sphere 支持基于 XA 的强一致性事务解决方案，可以通过 SPI 注入不同的第三方组件作为事务管理器实现 XA 协议，如 Atomikos 和 Narayana 。
+
+- [Spring JTA + Atomikos](https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-jta.html)
+
+### 应用场景
+
+这种分布式事务方案，比较适合单块应用里，跨多个库的分布式事务，而且因为严重依赖于数据库层面来搞定复杂的事务，效率很低，绝对不适合高并发的场景。
+
+这个方案，我们很少用，一般来说**某个系统内部如果出现跨多个库**的这么一个操作，是**不合规**的。我可以给大家介绍一下， 现在微服务，一个大的系统分成几百个服务，几十个服务。一般来说，我们的规定和规范，是要求**每个服务只能操作自己对应的一个数据库**。
+
+如果你要操作别的服务对应的库，不允许直连别的服务的库，违反微服务架构的规范，你随便交叉胡乱访问，几百个服务的话，全体乱套，这样的一套服务是没法管理的，没法治理的，可能会出现数据被别人改错，自己的库被别人写挂等情况。
+
+如果你要操作别人的服务的库，你必须是通过**调用别的服务的接口**来实现，绝对不允许交叉访问别人的数据库。
+
+[![distributed-transacion-XA](16-精尽【分布式事务】面试题.assets/baef17d9dde837632e9a7894cb825cb2.png)](http://static.iocoder.cn/baef17d9dde837632e9a7894cb825cb2)distributed-transacion-XA
+
+## 聊聊 TCC 方案？
+
+TCC 模型是把锁的粒度完全交给业务处理，它需要每个子事务业务都实现Try-Confirm / Cancel 接口。
+
+> TCC 模式本质也是 2PC ，只是 TCC 在应用层控制。
+
+- Try:
+  - 尝试执行业务
+  - 完成所有业务检查（一致性）
+  - 预留必须业务资源（准隔离性）
+- Confirm:
+  - 确认执行业务；
+  - 真正执行业务，不作任何业务检查
+  - 只使用Try阶段预留的业务资源
+  - Confirm 操作满足幂等性
+
+- Cancel:
+  - 取消执行业务
+  - 释放Try阶段预留的业务资源
+  - Cancel操作满足幂等性
+
+这三个阶段，都会按本地事务的方式执行。不同于 XA的prepare ，TCC 无需将 XA 的投票期间的所有资源挂起，因此极大的提高了吞吐量。
+
+🦅 **应用场景**
+
+下面对TCC模式下，A账户往B账户汇款100元为例子，对业务的改造进行详细的分析：
+
+[![img](16-精尽【分布式事务】面试题.assets/4da5bc0df774ef90e97c6358eb7e632f.webp)](http://static.iocoder.cn/4da5bc0df774ef90e97c6358eb7e632f)img
+
+- 汇款服务和收款服务分别需要实现，Try-Confirm-Cancel 接口，并在业务初始化阶段将其注入到 TCC 事务管理器中。
+
+汇款服务
+
+- Try：
+  - 检查A账户有效性，即查看A账户的状态是否为“转帐中”或者“冻结”
+  - 检查A账户余额是否充足
+  - 从A账户中扣减 100 元，并将状态置为“转账中”
+  - 预留扣减资源，将从 A 往 B 账户转账 100 元这个事件存入消息或者日志中
+- Confirm：
+  - 不做任何操作
+- Cancel：
+  - A 账户增加 100 元
+  - 从日志或者消息中，释放扣减资源
+
+收款服务
+
+- Try：
+  - 检查 B 账户账户是否有效；
+- Confirm：
+  - 读取日志或者消息，B 账户增加 100 元
+  - 从日志或者消息中，释放扣减资源；
+- Cancel：
+  - 不做任何操作
+
+由此可以看出，TCC 模型对业务的侵入强，改造的难度大。
+
+但是，在需要前置资源锁定的场景，不得不使用 XA 或 TCC 的方式。再例如说，下单场景，在订单创建之前，需要扣除如下几个资源：
+
+- 优惠劵
+- 钱包余额
+- 积分
+- ….
+
+那么，不得不进行前置多资源锁定，无非是使用 XA 的强锁，还是 TCC 的弱锁。在 [oceans](https://github.com/YunaiV/oceans/tree/0.0.1) 的 tag `0.0.1` 中，在未使用 TCC 的情况下，模拟 TCC 的效果的苦闷。
+
+当然，如果能不用 TCC 的情况下，尽量不要用 TCC 。因为，编写回滚逻辑的代码，可能会比较恶心。
+
+🦅 **解决方案？**
+
+- TCC-Transaction ，听说喜马拉雅在用。具体的源码解析，可以看看 [《TCC-Transaction 源码分析》](http://www.iocoder.cn/categories/TCC-Transaction/) 。
+- Hmily ，具体的源码解析，可以看看 [《Hmily 实现原理与源码解析系列 —— 精品合集》](http://www.iocoder.cn/Hmily/good-collection/) 。
+- ByteTCC
+
+## 聊聊本地消息表？
+
+本地消息表，其实是 [国外的 Ebay 搞出来的这么一套思想](https://queue.acm.org/detail.cfm?id=1394128) 。
+
+这个大概意思是这样的：
+
+[![distributed-transaction-local-message-table](16-精尽【分布式事务】面试题.assets/b1fc3558543e402cb373792eade99e0f.png)](http://static.iocoder.cn/b1fc3558543e402cb373792eade99e0f)distributed-transaction-local-message-table
+
+1. A 系统在自己本地一个事务里操作同时，插入一条数据到消息表；
+2. 接着 A 系统将这个消息发送到 MQ 中去；
+3. B 系统接收到消息之后，在一个事务里，往自己本地消息表里插入一条数据，同时执行其他的业务操作，如果这个消息已经被处理过了，那么此时这个事务会回滚，这样**保证不会重复处理消息**；
+4. B 系统执行成功之后，就会更新自己本地消息表的状态以及 A 系统消息表的状态；
+5. 如果 B 系统处理失败了，那么就不会更新消息表状态，那么此时 A 系统会定时扫描自己的消息表，如果有未处理的消息，会再次发送到 MQ 中去，让 B 再次处理；
+6. 这个方案保证了最终一致性，哪怕 B 事务失败了，但是 A 会不断重发消息，直到 B 那边成功为止。
+
+这个方案说实话最大的问题就在于**严重依赖于数据库的消息表来管理事务**啥的，会导致如果是高并发场景咋办呢？咋扩展呢？所以一般确实很少用。
+
+本地消息队列是 BASE 理论，是最终一致模型，适用于对一致性要求不高的。实现这个模型时需要注意重试的幂等。
+
+## 聊聊可靠消息最终一致性方案？
+
+这个的意思，就是干脆不要用本地的消息表了，直接基于 MQ 来实现事务。比如阿里的 RocketMQ 就支持消息事务。
+
+大概的意思就是：
+
+[![distributed-transaction-reliable-message](16-精尽【分布式事务】面试题.assets/80a431c9be51ed67d9c67f7a1de7c2ed.png)](http://static.iocoder.cn/80a431c9be51ed67d9c67f7a1de7c2ed)distributed-transaction-reliable-message
+
+1. A 系统先发送一个 prepared 消息到 mq，如果这个 prepared 消息发送失败那么就直接取消操作别执行了；
+2. 如果这个消息发送成功过了，那么接着执行本地事务，如果成功就告诉 mq 发送确认消息，如果失败就告诉 mq 回滚消息；
+3. 如果发送了确认消息，那么此时 B 系统会接收到确认消息，然后执行本地的事务；
+4. mq 会自动**定时轮询**所有 prepared 消息回调你的接口，问你，这个消息是不是本地事务处理失败了，所有没发送确认的消息，是继续重试还是回滚？一般来说这里你就可以查下数据库看之前本地事务是否执行，如果回滚了，那么这里也回滚吧。这个就是避免可能本地事务执行成功了，而确认消息却发送失败了。
+5. 这个方案里，要是系统 B 的事务失败了咋办？重试咯，自动不断重试直到成功，如果实在是不行，要么就是针对重要的资金类业务进行回滚，比如 B 系统本地回滚后，想办法通知系统 A 也回滚；或者是发送报警由人工来手工回滚和补偿。
+
+**这个还是比较合适的，目前国内互联网公司大都是这么玩儿的**。
+
+🦅 **解决方案**
+
+- RocketMQ 事务消息，源码解析，可见 [《RocketMQ 源码分析 —— 事务消息》](http://www.iocoder.cn/RocketMQ/message-transaction/?vip) 。
+
+  > 虽然 RocketMQ 早期开源事务消息后又阉割闭源，但是在 RocketMQ 4.3 版本中，又重新提供。所以，不要搞错落。
+
+- [《RabbitMQ 之消息确认机制（事务+Confirm）》](https://blog.csdn.net/u013256816/article/details/55515234)
+
+- Kafka 事务消息，https://zhuanlan.zhihu.com/p/42046847 TODO 需要找厮大确认下
+
+## 聊聊最大努力通知方案？
+
+艿艿瞅了瞅市面上的资料，分别有两种解释。或者说，两种不同的解决方案。
+
+### 解释一
+
+最大努力送达，是针对于弱 XA 的一种补偿策略。它采用事务表记录所有的事务操作 SQL 。
+
+[![img](16-精尽【分布式事务】面试题.assets/728bf44f14926be91f33c4c7fda15fad.webp)](http://static.iocoder.cn/728bf44f14926be91f33c4c7fda15fad)img
+
+- 如果子事务提交成功，将会删除事务日志。
+- 如果执行失败，则会按照配置的重试次数，尝试再次提交，即最大努力的进行提交，尽量保证数据的一致性，这里可以根据不同的业务场景，平衡 C 和 A ，采用同步重试或异步重试。
+
+🦅 **优点**
+
+- 无锁定资源时间，性能损耗小。
+
+🦅 **缺点**
+
+- 尝试多次提交失败后，无法回滚，它仅适用于事务最终一定能够成功的业务场景。
+
+🦅 **总结**
+
+- 因此 BED 是通过事务回滚功能上的妥协，来换取性能的提升。
+
+貌似，暂时也想象不到具体的使用场景。
+
+🦅 **解决方案**
+
+正如上图，提供的解决方式 Sharding-JDBC ，具体的源码解析，可见 [《Sharding-JDBC 源码分析 —— 分布式事务（一）之最大努力型》](http://www.iocoder.cn/Sharding-JDBC/transaction-bed/?vip) 。
+
+### 解释二
+
+这个方案的大致意思就是：
+
+1. 系统 A 本地事务执行完之后，发送个消息到 MQ；
+2. 这里会有个专门消费 MQ 的**最大努力通知服务**，这个服务会消费 MQ 然后写入数据库中记录下来，或者是放入个内存队列也可以，接着调用系统 B 的接口；
+3. 要是系统 B 执行成功就 ok 了；要是系统 B 执行失败了，那么最大努力通知服务就定时尝试重新调用系统 B，反复 N 次，最后还是不行就放弃。
+
+🦅 **解决方案**
+
+按照这个解释，RocketMQ 的消息重试，符合这个解释。具体的源码解析，见 [《RocketMQ 源码分析 —— 定时消息与消息重试》](http://www.iocoder.cn/RocketMQ/message-schedule-and-retry/) 。
+
+比较常见的场景，就是支付成功后，多次回调~
+
+## 聊聊 Saga 方案？
+
+Saga 是 30 年前一篇数据库伦理提到的一个概念。其核心思想是将长事务拆分为多个本地短事务，由 Saga 事务协调器协调，如果正常结束那就正常完成，如果某个步骤失败，则根据相反顺序一次调用补偿操作。
+
+Saga 的组成如下：
+
+- 每个 Saga 由一系列 sub-transaction Ti 组成
+- 每个Ti 都有对应的补偿动作 Ci ，补偿动作用于撤销 Ti 造成的结果。这里的每个 T ，都是一个本地事务。
+- 可以看到，和 TCC 相比，Saga 没有“预留 try”动作 ，它的 Ti 就是直接提交到库。
+
+Saga的执行顺序有两种：
+
+- 子事务序列 T1, T2, …, Tn得以完成 (最佳情况)。
+- 或者序列 T1, T2, …, Tj, Cj, …, C2, C1, 0 < j < n, 得以完成。
+
+Saga 定义了两种恢复策略：
+
+- 向后恢复：补偿所有已完成的事务，如果任一子事务失败。
+
+  > 向后恢复，即上面提到的第二种执行顺序，其中 j 是发生错误的 sub-transaction ，这种做法的效果是撤销掉之前所有成功的 sub-transation ，使得整个 Saga 的执行结果撤销。
+
+- 向前恢复：重试失败的事务，假设每个子事务最终都会成功。
+
+  > 显然，向前恢复没有必要提供补偿事务，如果你的业务中，子事务（最终）总会成功，或补偿事务难以定义或不可能，向前恢复更符合你的需求。理论上补偿事务永不失败，然而，在分布式世界中，服务器可能会宕机、网络可能会失败，甚至数据中心也可能会停电，这时需要提供故障恢复后回退的机制，比如人工干预。
+
+🦅 **如何解决没有 Prepare阶段可能带来的问题？**
+
+由于 Saga 模型中没有 Prepare 阶段，因此事务间不能保证隔离性，当多个 Saga 事务操作同一资源时，就会产生更新丢失、脏数据读取等问题，这时需要在业务层控制并发。例如：
+
+- 在应用层面加锁。
+- 应用层面预先冻结资源。
+
+还是拿 100 元买一瓶水的例子来说。
+
+- 这里定义：
+
+  - T1=扣100元 T2=给用户加一瓶水 T3=减库存一瓶水
+  - C1=加100元 C2=给用户减一瓶水 C3=给库存加一瓶水
+
+- 我们一次进行 T1，T2，T3。如果发生问题，就执行发生问题的 C 操作的反向。上面说到的隔离性的问题会出现在，如果执行到 T3 这个时候需要执行回滚，但是这个用户已经把水喝了(**另外一个事务**)，回滚的时候就会发现，无法给用户减一瓶水了。这就是事务之间没有隔离性的问题。
+
+  > 艿艿：也就是说，给的太早，但是可以被取消！
+
+可以看见 Saga 模式没有隔离性的影响还是较大，可以参照华为的解决方案:
+
+- 从业务层面入手加入一 Session 以及锁的机制来保证能够串行化操作资源。
+- 也可以在业务层面通过预先冻结资金的方式隔离这部分资源，最后在业务操作的过程中可以通过及时读取当前状态的方式获取到最新的更新。
+
+🦅 **解决方案**
+
+- Apache Service Comb 的 Saga 事务引擎
+
+- Sharding Sphere 的 Saga 支持
+
+  > 实际是基于 Apache Service Comb 的 Saga 事务引擎之上进行开发。
+
+## 你们公司是如何处理分布式事务的？
+
+如果你真的被问到，可以这么说：
+
+- 我们某某特别严格的场景，用的是 TCC 来保证强一致性。
+
+  > 你找一个严格资金要求绝对不能错的场景，你可以说你是用的 TCC 方案。
+
+- 然后其他的一些场景，基于阿里的 RocketMQ 来实现了分布式事务。
+
+  > 如果是一般的分布式事务场景，订单插入之后要调用库存服务更新库存，库存数据没有资金那么的敏感，可以用可靠消息最终一致性方案。
+
+## 什么是三阶段协议？
+
+这个问题，严格来说不属于【分布式事务】相关，考虑到本文已经出现了一阶段提交、二阶段提交，所以这里就瞬时“硬塞”一个三阶段提交。
+
+感兴趣的胖友，可以看看 [《数据库 分布式事务 2阶提交 3阶提交》](https://www.jianshu.com/p/a20f1895d9c7) 文章。
+
+\##
+
+## 事务解决方案的对比总结
+
+总的来说，TCC 和 MQ 都是以服务为范围进行分布式事务的处理，而 XA、BED、SAGA 则是以数据库为范围进行分布式处理。
+
+> 对于数据库中间来来说，更趋向于选择后者，对于业务而言侵入小，改造的成本低。
+
+[![对比图](http://static.iocoder.cn/c015006c18d7b4a59463fd00d589f2e1)](http://static.iocoder.cn/c015006c18d7b4a59463fd00d589f2e1)对比图
+
+- 图中暂时未包括：1）本地消息表；2）可靠消息最终一致性方案 。因为，这个是 Sharding Sphere 官方提供的图，嘻嘻。
+
+## 彩蛋
+
+😈 虽然以前基本读过市面上很多分布式事务解决方案的源码，但是因为是断断续续的读，没有专门花时间去整理。这次重新整理了下，收获还是蛮多的。
+
+另外，开源社区里还有两个同类型的 2PC 事务解决方案，感兴趣的胖友，也可以看看：
+
+> 艿艿：主要我没有特别研究，所以也不太好写。
+
+- [Raincat](https://github.com/yu199195/Raincat)
+- [LCN](https://github.com/codingapi/tx-lcn)
+
+参考与推荐如下文章：
+
+- 高效运维 [《分布式系统的 CAP 理论》](http://www.yunweipai.com/archives/8432.html)
+- 咖啡拿铁 [《再有人问你分布式事务，把这篇扔给他》](https://juejin.im/post/5b5a0bf9f265da0f6523913b)
+- yanglbme [《分布式事务了解吗？你们如何解决分布式事务问题的？TCC 如果出现网络连不通怎么办？XA 的一致性如何保证？》](https://github.com/doocs/advanced-java/blob/master/docs/distributed-system/distributed-transaction.md)
\ No newline at end of file
diff --git a/面试题/17-MongoDB 面试题.md b/面试题/17-MongoDB 面试题.md
new file mode 100644
index 0000000..34f0d8f
--- /dev/null
+++ b/面试题/17-MongoDB 面试题.md	
@@ -0,0 +1,318 @@
+# 精尽 MongoDB 面试题「最新更新时间：2024-02」
+
+以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。
+
+如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的 MongoDB 面试题的大保健。
+
+而题目的难度，艿艿尽量按照从容易到困难的顺序，逐步下去。
+
+> 艿艿：对于 MongoDB 的面试题的准备，我的想法是看过一遍即可，更大的重心在于 MySQL 的面试题的准备。
+>
+> 因为，从目前的技术风向标来说，大家在技术选项上，更偏向 MySQL + 分库分表，解决海量数据存储的问题。同时 NewSQL 也慢慢走进大家的视野之中，例如 TiDB 。
+
+## 什么是 NoSQL 数据库？
+
+NoSQL 是非关系型数据库，NoSQL = Not Only SQL 。
+
+🦅 **NoSQL 和 RDBMS 有什么区别？**
+
+- 关系型数据库，采用的结构化的数据。
+- NoSQL 采用的是键值对的方式存储数据。
+
+🦅 **在哪些情况下使用和不使用 NoSQL 数据库？**
+
+> 艿艿：如下是我从网上找到的答案，怎么看着会觉得怪怪的。
+
+优先考虑使用 NoSQL 数据库
+
+- 在处理非结构化 / 半结构化的大数据
+- 在水平方向上进行扩展
+- 随时应对动态增加的数据项
+
+优先考虑关系型数据库
+
+- 在考虑数据库的成熟度
+- 分析和商业智能
+- 管理及专业性等问题
+
+> 艿艿：下面我说下自己的观点
+
+- 信息表(例如，商品信息)，使用 NoSQL 数据库不错，因为 NoSQL 往往提供灵活的数据类型。
+- 交易表，使用关系数据库，因为往往需要关注事务性。
+- 对 BI 分析等，使用关系数据库，因为周边设施更加完善。
+
+🦅 **非关系型数据库有哪些？**
+
+比较常见的三个是：
+
+- MongoDB
+- Redis
+- Elasticsearch
+
+## 什么是 MongoDB ？
+
+> MongoDB 是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。
+>
+> - 它支持的数据结构非常松散，是类似 jSON 的 BSON 格式，因此可以存储比较复杂的数据类型。
+> - Mongo 最大的特点是他支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。
+
+综合来说，MongoDB 可以说是最棒的文档数据库。
+
+🦅 **MongoDB的特点是什么？**
+
+- 面向集合的存储：适合存储对象及 JSON 形式的数据。
+
+  > 这个也是 MongoDB 和 MySQL 之间最基本的级别。
+
+- 动态查询：MongoDB 支持丰富的查询表达式。查询指令使用 JSON 形式的标记，可轻易查询文档中内嵌的对象及数组。
+
+- 完整的索引支持：包括文档内嵌对象及数组。Mongo的查询优化器会分析查询表达式，并生成一个高效的查询计划。
+
+- 查询监视：MongoDB 包含一个监视工具用于分析数据库操作的性能。
+
+- 复制及自动故障转移：MongoDB 数据库支持服务器之间的数据复制，支持主-从模式及服务器之间的相互复制。复制的主要目标是提供冗余及自动故障转移。
+
+- 高效的传统存储方式：支持二进制数据及大型对象（如照片或图片）。
+
+- 自动分片以支持云级别的伸缩性：自动分片功能支持水平的数据库集群，可动态添加额外的机器。
+
+🦅 **术语和概念？**
+
+MySQL 中的许多概念在 MongoDB 中具有相近的类比。本表概述了每个系统中的一些常见概念。
+
+| MySQL       | MongoDB          |
+| :---------- | :--------------- |
+| 库 Database | 库 Database      |
+| 表 Table    | 集合 Collection  |
+| 行 Row      | 文档 Document    |
+| 列 Column   | 字段 Field       |
+| joins       | 嵌入文档或者链接 |
+
+- MongoDB 数据库，可以看成是一个电子化的文件柜，用户可以对文件中的数据运行新增、检索、更新、删除等操作。数据库是一个所有集合的容器，在文件系统中每一个数据库都有一个相关的物理文件。
+
+- MongoDB 集合，就是一组 MongoDB 文档。它相当于关系型数据库（RDBMS）中的表这种概念。集合位于单独的一个数据库中。一个集合内的多个文档可以有多个不同的字段。一般来说，集合中的文档都有着相同或相关的目的。
+
+- MongoDB 文档，由一组 key value 组成。文档是动态模式，这意味着同一集合里的文档不需要有相同的字段和结构。在关系型数据库中 Table 中的每一条记录相当于 MongoDB 中的一个文档。
+
+  > 不过一般情况下，相同 Collection 下的 Document 字段是统一的。
+
+🦅 **MySQL 与 MongoDB 的功能对比？**
+
+|                | MySQL | MongoDB |
+| :------------- | :---- | :------ |
+| 丰富的数据模型 | 否    | 是      |
+| 动态 Schema    | 否    | 是      |
+| 数据类型       | 是    | 是      |
+| 数据本地化     | 否    | 是      |
+| 字段更新       | 是    | 是      |
+| 易于编程       | 否    | 是      |
+| 复杂事务       | 是    | 否      |
+| 审计           | 是    | 是      |
+| 自动分片       | 否    | 是      |
+
+- 这是一个比较老的比较。
+- MySQL5.7 版本开始，也提供了 JSON 类型的数据格式。
+- MongoDB4.0 版本开始，也提供了事务功能。
+- 关于是否易于编程，这个看每个人的自己的想法，实际都还可以。
+
+## MongoDB 有哪些存储引擎？
+
+从 [《MongoDB Documentation —— Storage Engines》](https://docs.mongodb.com/manual/core/storage-engines/) 中，我们看到 MongoDB 有三种存储引擎：
+
+- WiredTiger Storage Engine **默认**
+- In-Memory Storage Engine
+- MMAPv1 Storage Engine **(Deprecated as of MongoDB 4.0)**
+
+具体的对比，可以看看 [《MongoDB 存储引擎选择》](https://blog.csdn.net/xiaoQL520/article/details/76973887) 文章。
+
+- 生产环境下，基本使用的都是 WiredTiger Storage Engine ，因为各方面性能都优于 MMAPv1 Storage Engine 。
+- 如果真的需要 In-Memory Storage Engine 的情况，Redis 或者是一个更加的选择。
+
+## MongoDB 支持哪些数据类型？
+
+- String
+- Integer
+- Double
+- Boolean
+- Object
+- ObjectId
+- Arrays
+- Min/Max Keys
+- Datetime
+- Code
+- Regular Expression
+- … 等等
+
+🦅 **为什么要在 MongoDB 中用”Code”数据类型？**
+
+“Code” 类型，用于在文档中存储 JavaScript 代码。决绝绝大多数业务场景下，我们并不会使用这个数据类型。
+
+🦅 **为什么要在 MongoDB 中用”Regular Expression”数据类型？**
+
+“Regular Expression” 类型，用于在文档中存储正则表达式。
+
+🦅 **为什么在 MongoDB 中使用”ObjectId”数据类型？**
+
+“ObjectId” 数据类型，用于存储文档 id 。关于 ObjectId 的组成，可以看看 [《MongoDB 深究之 ObjectId》](https://www.cnblogs.com/xjk15082/archive/2011/09/18/2180792.html) 。
+
+- 另外，ObjectId 天然就是分布式主键的实现，所以在 MongoDB 分片后，依然可以继续使用。
+
+当然，对于绝大数业务场景下，我们还是希望能够使用自增 ID ，可以参看 [《Java 中实现 MongoDB 自增主键 ID》](https://blog.csdn.net/qq_16504067/article/details/79270777) 。
+
+- 另外，使用 SnowFlake 等等，也是一种方式。
+
+🦅 **如何理解 MongoDB 中的 GridFS 机制，MongoDB 为何使用 GridFS 来存储文件？**
+
+GridFS 是一种将大型文件存储在 MongoDB 中的文件规范。使用 GridFS 可以将大文件分隔成多个小文档存放，这样我们能够有效的保存大文档，而且解决了 BSON 对象有限制的问题。
+
+当然，实际生产环境下，建议使用专门的文件服务器，例如 FastDFS、TFS 等，而不是使用 MongoDB GridFS 。
+
+🦅 **MongoDB 支持存储过程吗？如果支持的话，怎么用？**
+
+MongoDB 支持存储过程，它是 Javascript 写的，保存 `db.system.js` 表中。
+
+当然，和 MySQL 一样，实际场景下，不会使用存储过程。
+
+## MongoDB 为什么选择 B-Tree 索引?
+
+在 [《精尽 MySQL 面试题》](http://svip.iocoder.cn/MySQL/Interview) 中，我们已经看到 MySQL 使用的是 B+Tree 索引。
+
+- B+Tree 内节点不存储数据，所有 data 存储在叶节点导致查询时间复杂度固定为 log(n) 。
+- B-Tree 查询时间复杂度不固定，与 key 在树中的位置有关，最好为O(1) 。
+
+我们知道，尽可能少的磁盘 IO 是提高性能的有效手段。MongoDB 是聚合型数据库，而 B-Tree 恰好 key 和 data 域聚合在一起。
+
+至于 MongoDB 为什么使用 B-Tree 而不是 B+Tree ，可以从它的设计角度来考虑，它并不是传统的关系性数据库，而是以 JSON 格式作为存储的 NoSQL ，目的就是高性能，高可用，易扩展。
+
+- MySQL 由于使用 B+ 树，数据都在叶节点上，每次查询都需要访问到叶节点，而 MongoDB 使用 B-Tree ，所有节点都有 data 域，只要找到指定索引就可以进行访问，无疑单次查询平均快于 MySQL 。
+
+具体的讨论，可以看看 [《为什么有关 MongoDB 采用 B 树索引，以及 MySQL B+ 树做索引？》](https://www.zhihu.com/question/28774706) 上的讨论。当然，艿艿也觉得这个回答可能有点牵强。列出这个问题的目的在于，让我们知道 MongoDB 并不是使用 B+Tree 来实现索引。
+
+🦅 **MongoDB 在 A:{B,C} 上建立索引，查询 A:{B,C} 和 A:{C,B} 都会使用索引吗？**
+
+因为 MongoDB 使用 B-Tree 索引，实际上查询和 MySQL 的 B+Tree 索引是基本一致的。
+
+- A:{B,C} 上，可以完整使用索引。
+- A:{C,B} 上，只能部分使用索引，只有 A 部分。
+
+## 什么是 MongoDB 聚合操作？
+
+聚合操作，能够处理数据记录并返回计算结果。聚合操作能将多个文档中的值组合起来，对成组数据执行各种操作，返回单一的结果。它相当于 SQL 中的 `COUUNT(*)` 组合 `GROUP BY` 。
+
+对于 MongoDB 中的聚合操作，应该使用 aggregate 方法。具体使用，可以看看 [《MongoDB Documentation —— aggregate》](https://docs.mongodb.com/manual/reference/method/db.collection.aggregate/) 。
+
+## MongoDB 如何实现高可用？
+
+和 MySQL 一样，MongoDB 也提供了其复制方案，为实现高可用提供了基础。目前，MongoDB 支持两种复制模式：
+
+- Master / Slave ，主从复制，角色包括 Master 和 Slave 。
+- Replica Set ，复制集复制，角色包括 Primary 和 Secondary 以及 Arbiter 。
+
+生产环境下，只会使用 Replica Set 复制级的方式，实现 MongoDB 的高可用。主要因为，它提供了良好的自动故障切换功能。具体的搭建方式，可以看看 [《MongoDB 集群搭建及使用》](https://blog.csdn.net/supermapsupport/article/details/78953080) 。
+
+🦅 **什么是 Primary?**
+
+Primary，它是当前备份集群(replica set)中负责处理所有写入操作的主要节点/成员。在一个复制集集群中，当失效备援(failover)事件发生时，Secondary 中的一个成员会变成新的 Primary。
+
+🦅 **什么是 Secondary？**
+
+Secondary ，从当前的 Primary上 复制相应的操作。它是通过跟踪复制`oplog(local.oplog.rs)` 做到的。
+
+🦅 **MongoDB 如何实现读写分离？**
+
+在程序中，我们可以配置读取 Secondary 节点的数据，从而实现读写分离。例如说，每天晚上的 T+1 数据统计，可以读取 Secondary 节点的数据。具体可以参见 [《Mongodb 的读写分离使用 Replica Sets 来实现》](http://www.cookqq.com/blog/8a10a5f35167c83a0151802b12ab0963) 文章。
+
+🦅 **什么是 MongoDB 的延迟节点？**
+
+参见文章 [《Mongodb 延迟复制节点配置》](http://blog.51cto.com/icenycmh/1841001) 。
+
+另外，MongoDB 的延迟节点，是不对外提供服务，所以在其上做全量备份，也是非常不错的选择。
+
+## MongoDB 如何实现分片？
+
+MongoDB 分片，是将数据水平切分到不同的物理节点。当应用数据越来越大的时候，数据量也会越来越大。当数据量增长时，单台机器有可能无法存储数据或可接受的读取写入吞吐量。利用分片技术可以添加更多的机器来应对数据量增加以及读写操作的要求。
+
+> 或者，我们可以将 MongoDB 分片理解成内置的分库分表功能。
+
+具体如何使用，可以看看 [《MongoDB 分片》](http://www.runoob.com/mongodb/mongodb-sharding.html) 文章。
+
+🦅 **我应该启动一个集群分片(sharded)还是一个非分片集群的 MongoDB 环境?**
+
+为开发便捷起见，我们建议以非集群分片(unsharded)方式开始一个 MongoDB 环境，除非一台服务器不足以存放你的初始数据集。从非集群分片升级到集群分片(sharding)是无缝的，所以在你的数据集还不是很大的时候没必要考虑集群分片(sharding)。
+
+另外，引入 MongoDB 分片后，会带来相应的运维复杂性，所以在 MongoDB 复制集能够支撑当前业务的情况下，不要过早的使用 MongoDB 分片。
+
+🦅 **分片(Shard)和复制(replication)是怎样工作的?**
+
+每一个分片(shard)是一个分区数据的逻辑集合。分片可能由单一服务器或者集群组成，我们推荐为每一个分片(shard)使用集群。
+
+🦅 **数据在什么时候才会扩展到多个分片(Shard)里?**
+
+MongoDB 分片是基于区域(range)的。所以一个集合(collection)中的所有的对象都被存放到一个块(chunk)中。只有当存在多余一个块的时候，才会有多个分片获取数据的选项。
+
+现在，每个默认块的大小是 64Mb，所以你需要至少 64 Mb 空间才可以实施一个迁移。
+
+🦅 **当更新一个正在被迁移的块（Chunk）上的文档时会发生什么？**
+
+更新操作会立即发生在旧的块（Chunk）上，然后更改才会在所有权转移前复制到新的分片上。
+
+🦅 **如果一个分片（Shard）停止或很慢的时候，发起一个查询会怎样？**
+
+如果一个分片停止了，除非查询设置了 “Partial” 选项，否则查询会返回一个错误。如果一个分片响应很慢，MongoDB 会等待它的响应。
+
+🦅 **我可以把 moveChunk 目录里的旧文件删除吗?**
+
+没问题，这些文件是在分片(shard)进行均衡操作(balancing)的时候产生的临时文件。一旦这些操作已经完成，相关的临时文件也应该被删除掉。
+
+但目前清理工作是需要手动的，所以请小心地考虑再释放这些文件的空间。
+
+🦅 **如果块移动操作(moveChunk)失败了，我需要手动清除部分转移的文档吗?**
+
+不需要，移动操作是一致(consistent)并且是确定性的(deterministic)。
+
+- 一次失败后，移动操作会不断重试。
+- 当完成后，数据只会出现在新的分片里(shard)。
+
+## 为什么要在 MongoDB 中使用分析器？
+
+数据库分析工具(Database Profiler)，会针对正在运行的 mongod 实例收集数据库命令执行的相关信息。
+
+- 包括增删改查的命令以及配置和管理命令。
+- 分析器(profiler) 会写入所有收集的数据到 `system.profile` 集合，一个 capped 集合在管理员数据库。
+
+分析器默认是关闭，的你能通过 per 数据库或 per 实例开启。
+
+## 聊聊 MongoDB 备份？
+
+和 MySQL 备份方式和策略类似，MongoDB 也需要定期的全量备份，以及定期的增量备份。具体可以看看 [《MongoDB 增量备份方案》](https://winway.github.io/2017/09/28/mongodb-point-in-time-backup-restore/) 和 [《Mongodb 增量备份脚本与原理》](https://my.oschina.net/passerman/blog/712035) 。
+
+🦅 **journal 回放在条目(entry)不完整时(比如恰巧有一个中途故障了)会遇到问题吗?**
+
+每个 journal (group) 的写操作都是一致的，除非它是完整的，否则在恢复过程中它不会回放。
+
+🦅 **更新操作立刻 fsync 到磁盘?**
+
+不会，磁盘写操作默认是延迟执行的。写操作可能在两三秒(默认在60秒内)后到达磁盘。
+
+- 例如，如果一秒内数据库收到一千个对一个对象递增的操作，仅刷新磁盘一次。
+
+- 通过 `syncPeriodSecs` 启动参数，可以进行配置。
+
+  > mongod 使用 fsync 操作将数据 flush 到磁盘的时间间隔，默认值为 60（单位：秒），强烈建议不要修改此值。
+  >
+  > mongod 将变更的数据写入journal后再写入内存，并间歇性的将内存数据 flush 到磁盘中，即延迟写入磁盘，有效提升磁盘效率。
+
+🦅 **为什么我的数据文件如此庞大?**
+
+MongoDB 会积极的预分配预留空间，来防止文件系统碎片。
+
+## 彩蛋
+
+许久不用 MongoDB ，生产基本换成 MySQL ，因为对事务性的要求更高。
+
+参考与推荐如下文章：
+
+- genuinecx [《MongoDB 经典面试题集锦》](http://blog.51cto.com/favccxx/1376656)
+- 搜云库技术团队 [《Mysql InnoDB B+树索引和哈希索引的区别？ MongoDB 为什么使用 B-树?》](https://segmentfault.com/a/1190000014178842)
+- 加多 [《MongoDB 和 MySQL 对比(译)》](http://ifeve.com/mongodb和mysql对比译/)
+- longz [《MongoDB 面试题问题以及参考答案》](https://zhuanlan.zhihu.com/p/37437657)
\ No newline at end of file
diff --git a/面试题/18-Elasticsearch 面试题（TODO）.md b/面试题/18-Elasticsearch 面试题（TODO）.md
new file mode 100644
index 0000000..e69de29
diff --git a/面试题/19-精尽设计模式面试题（TODO）.md b/面试题/19-精尽设计模式面试题（TODO）.md
new file mode 100644
index 0000000..e69de29
diff --git a/面试题/20-精尽数据结构与算法面试题.assets/01.png b/面试题/20-精尽数据结构与算法面试题.assets/01.png
new file mode 100644
index 0000000..427e813
Binary files /dev/null and b/面试题/20-精尽数据结构与算法面试题.assets/01.png differ
diff --git a/面试题/20-精尽数据结构与算法面试题.assets/02.png b/面试题/20-精尽数据结构与算法面试题.assets/02.png
new file mode 100644
index 0000000..26d7f7a
Binary files /dev/null and b/面试题/20-精尽数据结构与算法面试题.assets/02.png differ
diff --git a/面试题/20-精尽数据结构与算法面试题.assets/03.png b/面试题/20-精尽数据结构与算法面试题.assets/03.png
new file mode 100644
index 0000000..63318aa
Binary files /dev/null and b/面试题/20-精尽数据结构与算法面试题.assets/03.png differ
diff --git a/面试题/20-精尽数据结构与算法面试题.md b/面试题/20-精尽数据结构与算法面试题.md
new file mode 100644
index 0000000..a8d6c7f
--- /dev/null
+++ b/面试题/20-精尽数据结构与算法面试题.md
@@ -0,0 +1,1885 @@
+# 精尽数据结构与算法面试题「最新更新时间：2024-02」
+
+> 本文，我们将“数据结构与算法”，直接简称“算法”，更加简洁。实际上，数据结构、算法，是两个相关性很高的不同的知识点。
+
+当胖友准备开始准备算法相关的面试，就要做好心理准备，这可能是比想象中痛苦的过程，并且时间还不短，少则三个月，半年也是比较正常的时间。
+
+不过艿艿觉得，随着现在互联网越来越朝着**精英化**发展，对学历对履历的要求越来越高，大公司甚至部分小公司，也愈发注重基础技术。而基础技术，无非考核两点，编程语言和算法。所以，这个过程，可能真的是我们必须去体验的。
+
+不过换过来思考，算法不会像我们学习的框架或者中间件，有过时一说。也就说，学习一次，终身受众。并且，相比大多数 CRUD 的无脑，撩撩算法，也是一种“放松”，哈哈哈哈。
+
+# 如何学习？
+
+可能很多同学，一说到算法面试的准备，就想到的是去 LeetCode 去刷题？！但是，这个真的正确么？一半一半。相信绝大多数胖友，在大学里是没有认真学习算法，又或者在工作中，因为应用较少，所以基本忘记的也差不多了。
+
+**那么，就必须重新学习下算法！**请不要上来就去 LeetCode 去刷题，简直是花样作死。算法准备，是一场持久战，需要系统的去准备。那么，怎么进行学习呢？
+
+讲真，市面上大多数算法，无论是书籍，还是视频，真的真的真的是看不下去啊看不下去。有握爪的胖友么？最近，刷了王争的 [《数据结构与算法之美》](http://www.iocoder.cn/images/jikeshijian/数据结构与算法之美.jpg) ，哈哈哈，还很认真的做了笔记。如下图：
+
+[![笔记](20-精尽数据结构与算法面试题.assets/01.png)](http://www.iocoder.cn/images/Interview/2020-01-04/01.png)笔记
+
+> 艿艿，利益无关，主要是自己看了，真的觉得不错，足够适合我们准备算法面试。如果想要挑战，请去看 [《数据结构与算法分析：Java语言描述》](https://item.jd.com/11886254.html) 等等。呵，等着胖友回来说，“奶奶，我错了~~~😿” 哈哈哈哈。
+
+但是，还是要打个预防针，即使艿艿推荐了 [《数据结构与算法之美》](http://www.iocoder.cn/images/jikeshijian/数据结构与算法之美.jpg) 这个教程，也并不意味着它很简单。它还是非常难的，特别是红黑树！简直是魔鬼啊！！！仅仅是说，它足够能够让艿艿看完，并且蛮多时候在地铁上就能耐心看完。嘻嘻，不过呢，我有 2 年 ACM 集训的经验，可能底子又比大多数同学好点。对于 [《数据结构与算法分析：Java语言描述》](https://item.jd.com/11886254.html) 来说，在地铁上，真的是分分钟趟睡，又或是拿出手机，刷刷刷。
+
+胖友，要拿出勇气！如果碰到困难的，就退缩，就不要准备算法面试，不要想着去大公司。想啥呢！对吧。
+
+# 如何练习？
+
+**三分学，七分练**。用在算法面试的准备中，非常适合。哈哈哈，在算法面试的准备中，真正占用时间的是，不是算法的学习，而是在算法的练习中。这个过程，比学习算法会更加痛苦和难受。但是，也只有经历了练习的过程，学习算法，才可能真正变成学会算法。
+
+就好比说，我们学习了数学的某个知识点，直接去考试，绝大数情况下，可能是直接懵逼。同理，切换到真正去公司面试时，考到具体的算法题目，肯定也是类似的情况。所以，一定要勤加练习，死磕练习，玩命练习。
+
+那么，如何练习算法呢？答案很简单，去刷 LeetCode 。比较幸运的是，目前 LeetCode 有国内的版本，可以访问 https://leetcode-cn.com/ 进行愉快的玩耍，照顾我们这些英语不好的孩子。LeetCode 本土化的名字，真的是堪比麦丹劳的“金拱门”，竟然见“力扣”，哈哈哈哈。
+
+不过，怎么刷 LeetCode 呢？毕竟 LeetCode 已经进入**千题**时代，想要全部做完，肯定是不太现实，即使时间允许，我们的实力也不允许，哈哈哈哈。推荐看看 [《花花酱 LeetCode进入千题时代后该如何刷题?》](https://www.bilibili.com/video/av42947553/?p=1) 。可以开倍速播放，比较核心的，就是下面这张图：
+
+> [![如何刷题](20-精尽数据结构与算法面试题.assets/02.png)](http://www.iocoder.cn/images/Interview/2020-01-04/02.png)如何刷题
+
+即使如此，可能对于基础相对薄弱的，或者之前没啥刷题经验的胖友，直接上来就刷 LeetCode 题目，特别是一些**困难**级别的题目，可能简直是进了地狱模式的游戏难度，挫败感 120 分的强烈。那么怎么办呢？马化腾爸爸，很早就告诉了我们残酷的真理，“不充钱，怎么变强！”。所以，我们可能需要看一些针对 LeetCode 出的刷题面试**视频**课程：
+
+- 覃超 [《算法面试通关 40 讲》](http://www.iocoder.cn/images/jikeshijian/算法面试通关40讲.jpg)
+
+- 左神 [《牛客算法系列》](https://www.nowcoder.com/courses)
+
+  > 貌似不是针对 LeetCode 课程的，主要是牛逼，所以放这里。
+
+- 小象学院 [《面试算法 LeetCode 刷题班》](http://www.chinahadoop.cn/classroom/59/introduction)
+
+- 苏勇 [《300 分钟搞定算法面试》](https://kaiwu.lagou.com/course/courseInfo.htm)
+
+  > 拉钩网和 LeetCode 联合处的课程。
+
+艿艿的话，自己刷的是，覃超 [《算法面试通关 40 讲》](http://www.iocoder.cn/images/jikeshijian/算法面试通关40讲.jpg) 。并且，还是老样子，认真做了笔记，如下图：
+
+[![笔记](20-精尽数据结构与算法面试题.assets/03.png)](http://www.iocoder.cn/images/Interview/2020-01-04/03.png)笔记
+
+> 题外话，因为艿艿自己不准备面试，所以一般是不会去看算法。但是考虑到，这篇文章，蛮多人催的，所以自己又看了蛮多的资料的。就冲这份良心，我都给自己打 120 分。
+
+另外，市面上也有一些讲面试算法的书，这里也补充整理下，直接放下面：
+
+- 左神 [《程序员代码面试指南：IT 名企算法与数据结构题目最优解（第二版）》](https://item.jd.com/12518392.html)
+
+  > 豆瓣评分 8.9 分，以面试视角的算法书。
+
+- 何海涛 [《剑指 Offer：名企面试官精讲典型编程题》](https://union-click.jd.com/jdc?d=wnrKQh)
+
+  > 豆瓣评分 9.1 分，也讲了面试中的算法，同时也介绍了其它的。
+
+- [《编程之美：微软技术面试心得》](https://u.jd.com/wTp20p)
+
+  > 豆瓣评分 8.3 分，3000 多人评价，还是一本面试相关的算法书籍。主要是，大多数胖友学习算法是为了解决面试，所以就多推荐一点啦。
+
+考虑到大多数胖友，都是在职为主的，可以直接考虑 [《算法面试通关 40 讲》](http://www.iocoder.cn/images/jikeshijian/算法面试通关40讲.jpg) 。主要原因，还是因为我目前暂时只看完了这套教程。后续，我也抽时间看看，左神和小象学院的视频，良心如我。
+
+# 哪些题目？
+
+正如我们在 [《花花酱 LeetCode进入千题时代后该如何刷题?》](https://www.bilibili.com/video/av42947553/?p=1) 看到的视频，我们需要每个类型的 10-20 题，所以我们需要知道，算法面试，主要有哪些**题型**，每个题型刷哪些**题目**。
+
+题型来说，我们可以按照数据结构与算法分别分类：
+
+> 整理题型和题库时，按照自己的想法，并且参考下面的资料：
+>
+> - [LeetCode](https://leetcode-cn.com/problemset/all/) ，提供了每道题所属的题型，很赞！
+> - [数据结构与算法之美](http://www.iocoder.cn/images/jikeshijian/数据结构与算法之美.jpg)
+> - [算法面试通关 40 讲](http://www.iocoder.cn/images/jikeshijian/算法面试通关40讲.jpg)
+> - [花花酱 LeetCode 题目分类](https://docs.google.com/spreadsheets/d/1SbpY-04Cz8EWw3A_LBUmDEXKUMO31DBjfeMoA0dlfIA/edit#gid=126913158)
+> - [CS-Notes](https://github.com/CyC2018/CS-Notes/)
+> - [LeetCode 详解](https://legacy.gitbook.com/book/hk029/leetbook/details)
+> - [AlgoCasts](https://algocasts.io/episodes)
+
+- 数据结构
+
+  - 数组
+
+    > 矩阵，本质是二维数组。有些文章会喜欢归类成“数组与矩阵”，是一个意思。
+
+  - 链表
+
+  - 栈和队列
+
+  - 字符串
+
+  - 哈希表（散列表）
+
+  - 树
+
+  - 堆
+
+  - 图
+
+- 算法
+
+  - 双指针
+  - 排序
+  - 二分查找
+  - 深度优先搜索
+  - 广度优先搜索
+  - 拓扑排序
+  - 并查集
+  - 分治算法
+  - 回溯算法
+  - 贪心算法
+  - 动态规划
+  - 位运算
+  - 数学
+
+下面，按照这个分类，逐个来看看，需要做哪些题目。
+
+> 友情提示：题目的顺序，主要按照王争老师的 [《数据结构与算法之美》](http://www.iocoder.cn/images/jikeshijian/数据结构与算法之美.jpg) 为主。主要考虑点，是艿艿是按照这个顺序复习的，哈哈哈哈。
+>
+> 注意：每个下面的每个**解答**后面，每个 Solution 类，都对应一个解决方式。另外，一些题目，可能存在**多解**。建议的话，都去理解掉，因为面试官可能刨根问底。
+>
+> 😈 嘿嘿，发现自己撸了快 300 题 leetcode 左右，所以体量还是比较大的。艿艿尽量参考 LeetCode 提供的「🔥热题 HOT 100 」、「精选 TOP 面试题」，进行下标记。
+>
+> 刷题很累，多多坚持！
+
+## 数组
+
+> 【双指针】，一般用于数组的解题中。所以它的题目，我们也会放在【数组】这个题型中，也就是当前小节。通过双指针，可以将一些时间复杂度为 O(N^2) 的解法，进行优化成 O(N) 。
+>
+> 因为把【数组】和【双指针】放在了一起，所以题目可能蛮多的。保持淡定，相比动态规划等题目，这两类算比较简单的。
+
+### 001. 两数之和
+
+- 题目：https://leetcode-cn.com/problems/two-sum/
+- 难度：简单
+- 解答：[no0001](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0001)
+
+👉 **相似题目**：167. 两数之和 II - 输入有序数组
+
+- 题目：https://leetcode-cn.com/problems/two-sum-ii-input-array-is-sorted/
+- 难度：简单
+- 解答：[no0167](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0167)
+
+👉 **相似题目**：015. 三数之和
+
+- 题目：https://leetcode-cn.com/problems/3sum/
+- 难度：中等
+- 解答：[no0015](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0015)
+
+👉 **相似题目**：016. 最接近的三数之和
+
+- 题目：https://leetcode-cn.com/problems/3sum-closest/
+- 难度：中等
+- 解答：[no0016](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0016)
+
+👉 **相似题目**：018. 四数之和
+
+- 题目：https://leetcode-cn.com/problems/4sum/
+- 难度：中等
+- 解答：[no0018](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0018)
+
+👉 **相似题目**：454. 四数相加 II
+
+- 题目：https://leetcode-cn.com/problems/4sum/
+- 难度：中等
+- 解答：[no0454](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0454)
+
+👉 **相似题目**：633. 平方数之和
+
+- 题目：https://leetcode-cn.com/problems/sum-of-square-numbers/
+- 难度：简单
+- 解答：[no0633](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0633)
+
+### 011. 盛最多水的容器
+
+- 题目：https://leetcode-cn.com/problems/container-with-most-water/
+- 难度：中等
+- 解答：[no0011](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0011)
+
+👉 **相似题目**：042. 接雨水
+
+- 题目：https://leetcode-cn.com/problems/trapping-rain-water/
+- 难度：困难
+- 解答：[no0042](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0042)
+
+### 283. 移动零
+
+- 题目：https://leetcode-cn.com/problems/move-zeroes/description/
+- 难度：简单
+- 解答：[no0283](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0283)
+
+👉 **相似题目**：027. 移除元素
+
+- 题目：https://leetcode-cn.com/problems/remove-element/
+- 难度：简单
+- 解答：[no0027](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0027)
+
+👉 **相似题目**：026. 删除排序数组中的重复项
+
+- 题目：https://leetcode-cn.com/problems/remove-duplicates-from-sorted-array/
+- 难度：简单
+- 解答：[no0026](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0026)
+
+👉 **相似题目**：080. 删除排序数组中的重复项 II
+
+- 题目：https://leetcode-cn.com/problems/remove-duplicates-from-sorted-array-ii/
+- 难度：中等
+- 解答：[no0080](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0080)
+
+### 485. 最大连续 1 的个数
+
+- 题目：https://leetcode-cn.com/problems/max-consecutive-ones/
+- 难度：简单
+- 解答：[no0485](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0485)
+
+### 645. 错误的集合
+
+- 题目：https://leetcode-cn.com/problems/set-mismatch/
+- 难度：简单
+- 解答：[no0645](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0645)
+
+👉 **相似题目**：448. 找到所有数组中消失的数字
+
+- 题目：https://leetcode-cn.com/problems/find-all-numbers-disappeared-in-an-array/
+- 难度：简单
+- 解答：[no0448](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0448)
+
+👉 **相似题目**：442. 找到所有数组中消失的数字
+
+- 题目：https://leetcode-cn.com/problems/find-all-duplicates-in-an-array/
+- 难度：中等
+- 解答：[no0442](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0442)
+
+### 667. 优美的排列 II
+
+- 题目：https://leetcode-cn.com/problems/beautiful-arrangement-ii/
+- 难度：中等
+- 解答：[no0667](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0667)
+- 备注：找规律，更像一个【数学题】。
+
+### 697. 数组的度
+
+- 题目：https://leetcode-cn.com/problems/degree-of-an-array/
+- 难度：简单
+- 解答：[no0697](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0697)
+
+### 565. 嵌套数组
+
+- 题目：https://leetcode-cn.com/problems/array-nesting/
+- 难度：中等
+- 解答：[no0565](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0565)
+
+### 769. 最多能完成排序的块
+
+- 题目：https://leetcode-cn.com/problems/max-chunks-to-make-sorted/
+- 难度：中等
+- 解答：[no0769](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0769)
+- 备注：找规律，更像一个【数学题】。
+
+👉 **相似题目**：768. 最多能完成排序的块 II
+
+- 题目：https://leetcode-cn.com/problems/max-chunks-to-make-sorted-ii/
+- 难度：困难
+- 解答：[no0768](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0768)
+
+### 977. 有序数组的平方
+
+- 题目：https://leetcode-cn.com/problems/squares-of-a-sorted-array/
+- 难度：简单
+- 解答：[no0997](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0997)
+
+### 118. 杨辉三角
+
+- 题目：https://leetcode-cn.com/problems/pascals-triangle/
+- 难度：简单
+- 解答：[no0118](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0118)
+
+👉 **相似题目**：119. 杨辉三角 II
+
+- 题目：https://leetcode-cn.com/problems/pascals-triangle-ii/
+- 难度：简单
+- 解答：[no0119](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0119)
+
+### 189. 旋转数组
+
+- 题目：https://leetcode-cn.com/problems/rotate-array/
+- 难度：简单
+- 解答：[no0189](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0189)
+
+### 238. 除自身以外数组的乘积
+
+- 题目：https://leetcode-cn.com/problems/product-of-array-except-self/
+- 难度：中等
+- 解答：[no0238](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0238)
+
+## 矩阵
+
+### 766. 托普利茨矩阵
+
+- 题目：https://leetcode-cn.com/problems/toeplitz-matrix/
+- 难度：简单
+- 解答：[no0766](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0766)
+
+### 566. 重塑矩阵
+
+- 题目：https://leetcode-cn.com/problems/reshape-the-matrix/
+- 难度：简单
+- 解答：[no0566](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0566)
+
+### 074. 搜索二维矩阵
+
+- 题目：https://leetcode-cn.com/problems/search-a-2d-matrix/
+- 难度：中等
+- 解答：[no0074](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0074)
+
+### 240. 搜索二维矩阵 II
+
+- 题目：https://leetcode-cn.com/problems/search-a-2d-matrix-ii/
+- 难度：中等
+- 解答：[no0240](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0240)
+
+### 054. 螺旋矩阵
+
+- 题目：https://leetcode-cn.com/problems/spiral-matrix/
+- 难度：中等
+- 解答：[no0054](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0054)
+
+### 073. 矩阵置零
+
+- 题目：https://leetcode-cn.com/problems/set-matrix-zeroes/
+- 难度：中等
+- 解答：[no0073](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0073)
+
+## 字符串
+
+### 028. 实现 strStr()
+
+- 题目：https://leetcode-cn.com/problems/implement-strstr/
+- 难度：简单
+- 解答：[no0028](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0028)
+
+### 242. 有效的字母异位词
+
+- 题目：https://leetcode-cn.com/problems/valid-anagram/
+- 难度：简单
+- 解答：[no0242](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0242)
+
+👉 **相似题目**：049. 字母异位词分组
+
+- 题目：https://leetcode-cn.com/problems/group-anagrams/
+- 难度：中等
+- 解答：[no0049](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0049)
+
+### 205. 字符串同构
+
+- 题目：https://leetcode-cn.com/problems/isomorphic-strings/
+- 难度：简单
+- 解答：[no0205](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0205)
+
+### 125. 验证回文串
+
+- 题目：https://leetcode-cn.com/problems/valid-palindrome/
+- 难度：简单
+- 解答：[no0125](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0125)
+
+👉 **相似题目**：680. 验证回文字符串 Ⅱ
+
+- 题目：https://leetcode-cn.com/problems/valid-palindrome-ii/
+- 难度：简单
+- 解答：[no0680](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0680)
+
+👉 **相似题目**：409. 最长回文串
+
+- 题目：https://leetcode-cn.com/problems/longest-palindrome/
+- 难度：简单
+- 解答：[no0409](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0409)
+
+👉 **相似题目**：009. 判断一个整数是否是回文数
+
+- 题目：https://leetcode-cn.com/problems/palindrome-number/
+- 难度：简单
+- 解答：[no0009](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0009)
+
+### 344. 反转字符串
+
+- 题目：https://leetcode-cn.com/problems/reverse-string/
+- 难度：简单
+- 解答：[no0344](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0344)
+
+👉 **相似题目**：345. 反转字符串中的元音字母
+
+> 艿艿：这道题目，刚一看，一脸懵逼。可以简单理解成，需要将元音字母之间，做兑换。例如说，第一个元音字符和倒数一个元音字符对换，第二个原因字符和倒数第二个元音字符对换。而元音字母是 `aeiouAEIOU` 。
+
+- 题目：https://leetcode-cn.com/problems/reverse-vowels-of-a-string/
+- 难度：简单
+- 解答：[no0345](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0345)
+
+### 524. 通过删除字母匹配到字典里最长单词
+
+- 题目：https://leetcode-cn.com/problems/longest-word-in-dictionary-through-deleting/
+- 难度：中等
+- 解答：[no0524](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0524)
+
+### 003. 无重复字符的最长子串
+
+- 题目：https://leetcode-cn.com/problems/longest-substring-without-repeating-characters/
+
+- 难度：中等
+
+- 解答：[no0003](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0003)
+
+  > 基于滑动窗口实现
+
+👉 **相似题目**：159. 至多包含两个不同字符的最长子串
+
+- 题目：https://leetcode-cn.com/problems/longest-substring-with-at-most-two-distinct-characters/
+- 难度：困难
+- 解答：[no0159](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0159)
+
+👉 **相似题目**：340. 至多包含两个不同字符的最长子串
+
+- 题目：https://leetcode-cn.com/problems/longest-substring-with-at-most-k-distinct-characters/
+- 难度：困难
+- 解答：[no0340](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0340)
+
+### 696. 计数二进制子串
+
+- 题目：https://leetcode-cn.com/problems/count-binary-substrings/
+- 难度：简单
+- 解答：[no0696](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0696)
+
+### 151. 翻转字符串里的单词
+
+- 题目：https://leetcode-cn.com/problems/reverse-words-in-a-string/
+- 难度：中等
+- 解答：[no0151](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0151)
+
+👉 **相似题目**：557. 反转字符串中的单词 III
+
+- 题目：https://leetcode-cn.com/problems/reverse-words-in-a-string-iii/
+- 难度：简单
+- 解答：[no0557](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0557)
+
+### 008. 字符串转换整数 (atoi)
+
+- 题目：https://leetcode-cn.com/problems/string-to-integer-atoi/
+- 难度：中等
+- 解答：[no0008](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0008)
+
+## 链表
+
+> 每次写链表，都蛮头疼的。如果在搭配上递归的方式，简直就是一脸懵逼。
+>
+> 往往链表的答案不复杂，就是懵逼啊懵逼。
+
+### 707. 设计链表
+
+- 题目：https://leetcode-cn.com/problems/design-linked-list/
+
+- 难度：简单
+
+- 解答：[no0707](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0707)
+
+  > 我猜测，一次通过的胖友，基本没有，嘿嘿，虽然是个简单题。
+
+### 002. 两数相加
+
+- 题目：https://leetcode-cn.com/problems/add-two-numbers/
+- 难度：简单
+- 解答：[no0002](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0002)
+
+👉 **相似题目**：445. 两数相加 II
+
+- 题目：https://leetcode-cn.com/problems/add-two-numbers-ii/
+- 难度：中等
+- 解答：[no0445](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0445)
+
+### 024. 两两交换链表中的节点
+
+- 题目：https://leetcode-cn.com/problems/swap-nodes-in-pairs/
+
+- 难度：中等
+
+- 解答：[no0024](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0024)
+
+  > 注意点，交换时，不仅仅要考虑交换的两个节点，还要考虑，之前的节点，指向新的节点。
+
+👉 **相似题目**：234. 回文链表
+
+- 题目：https://leetcode-cn.com/problems/palindrome-linked-list/
+- 难度：简单
+- 解答：[no0234](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0234)
+
+👉 **相似题目**：206. 反转链表
+
+- 题目：https://leetcode-cn.com/problems/reverse-linked-list/
+- 难度：简单
+- 解答：[no0206](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0206)
+
+👉 **相似题目**：092. 反转链表 II
+
+- 题目：https://leetcode-cn.com/problems/reverse-linked-list-ii/
+- 难度：中等
+- 解答：[no0092](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0092)
+
+👉 **相似题目**：025. K 个一组翻转链表
+
+- 题目：https://leetcode-cn.com/problems/reverse-nodes-in-k-group/
+- 难度：困难
+- 解答：[no0025](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0025)
+
+👉 **相似题目** 061. 旋转链表
+
+- 题目：https://leetcode-cn.com/problems/rotate-list/
+- 难度：中等
+- 解答：[no0061](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0061)
+
+### 083. 删除排序链表中的重复元素
+
+- 题目：https://leetcode-cn.com/problems/remove-duplicates-from-sorted-list/
+- 难度：简单
+- 解答：[no0083](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0083)
+
+👉 **相似题目**：082. 删除排序链表中的重复元素 II
+
+- 题目：https://leetcode-cn.com/problems/remove-duplicates-from-sorted-list-ii/
+- 难度：中等
+- 解答：[no0082](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0082)
+
+### 160. 相交链表
+
+- 题目：https://leetcode-cn.com/problems/intersection-of-two-linked-lists/
+- 难度：简单
+- 解答：[no0160](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0160)
+
+👉 **相似题目**：141. 环形链表
+
+- 题目：https://leetcode-cn.com/problems/linked-list-cycle/
+- 难度：简单
+- 解答：[no0141](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0141)
+
+👉 **相似题目**：142. 环形链表 II
+
+- 题目：https://leetcode-cn.com/problems/max-chunks-to-make-sorted-ii/
+- 难度：中等
+- 解答：[no0142](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0142)
+
+### 148. 排序链表
+
+- 题目：https://leetcode-cn.com/problems/sort-list/
+- 难度：中等
+- 解答：[no0148](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0148)
+
+👉 **相似题目**：147. 对链表进行插入排序
+
+- 题目：https://leetcode-cn.com/problems/insertion-sort-list/
+- 难度：中等
+- 解答：[no0147](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0147)
+
+### 021. 合并两个有序链表
+
+- 题目：https://leetcode-cn.com/problems/merge-k-sorted-lists/
+- 难度：简单
+- 解答：[no0021](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0021)
+
+👉 **相似题目**：023. 合并K个排序链表
+
+- 题目：https://leetcode-cn.com/problems/merge-k-sorted-lists/
+- 难度：困难
+- 解答：[no0023](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0023)
+
+### 725. 分隔链表
+
+- 题目：https://leetcode-cn.com/problems/split-linked-list-in-parts/
+- 难度：中等
+- 解答：[no0725](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0725)
+
+👉 **相似题目**：328. 奇偶链表
+
+- 题目：https://leetcode-cn.com/problems/merge-k-sorted-lists/
+- 难度：困难
+- 解答：[no0023](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0023)
+
+### 725. 分隔链表
+
+- 题目：https://leetcode-cn.com/problems/split-linked-list-in-parts/
+- 难度：中等
+- 解答：[no0725](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0725)
+
+### 086. 分隔链表
+
+- 题目：https://leetcode-cn.com/problems/partition-list/
+- 难度：中等
+- 解答：[no0086](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0086)
+
+## 二分查找
+
+> 艿艿：其实我们已经在前面做了一堆二分查找的题目，嘿嘿。
+>
+> 当然，本小节，我们会看到很多略微变种的二分查找。
+
+### 287. 寻找重复数
+
+- 题目：https://leetcode-cn.com/problems/find-the-duplicate-number/
+- 难度：中等
+- 解答：[no0287](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0287)
+- 备注：有三种解答，不同时间复杂度，胖友要注意看。
+  - 最佳解是，经典的**弗洛伊德的乌龟和兔子（循环检测）**。🙂 可能看弗洛伊德的乌龟和兔子，整个推导的过程比较懵逼，耐心。
+
+### 035. 搜索插入位置
+
+- 题目：https://leetcode-cn.com/problems/search-insert-position/
+- 难度：简单
+- 解答：[no0035](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0035)
+
+👉 **相似题目**：744. 寻找比目标字母大的最小字母
+
+- 题目：https://leetcode-cn.com/problems/search-insert-position/
+- 难度：简单
+- 解答：[no0744](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0744)
+
+👉 **相似题目**：034. 在排序数组中查找元素的第一个和最后一个位置
+
+- 题目：https://leetcode-cn.com/problems/find-first-and-last-position-of-element-in-sorted-array/
+- 难度：中等
+- 解答：[no0034](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0034)
+
+👉 **相似题目**：704. 二分查找
+
+- 题目：https://leetcode-cn.com/problems/binary-search/solution/er-fen-cha-zhao-xiang-jie-by-labuladong/
+- 难度：简单
+- 解答：[no0704](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0704)
+
+👉 **相似题目**：981. 基于时间的键值存储
+
+- 题目：https://leetcode-cn.com/problems/time-based-key-value-store/
+- 难度：中等
+- 解答：[no0981](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0981)
+
+👉 **相似题目**：278. 第一个错误的版本
+
+- 题目：https://leetcode-cn.com/problems/first-bad-version/
+- 难度：简单
+- 解答：[no0278](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0278)
+
+### 153. 寻找旋转排序数组中的最小值
+
+- 题目：https://leetcode-cn.com/problems/find-minimum-in-rotated-sorted-array/
+- 难度：中等
+- 解答：[no0153](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0153)
+
+👉 **相似题目**：154. 搜索旋转排序数组
+
+- 题目：https://leetcode-cn.com/problems/search-in-rotated-sorted-array/
+- 难度：困难
+- 解答：[no0154](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0154)
+
+👉 **相似题目**：033. 搜索旋转排序数组
+
+- 题目：https://leetcode-cn.com/problems/search-in-rotated-sorted-array/
+- 难度：中等
+- 解答：[no0033](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0033)
+
+👉 **相似题目**：081. 搜索旋转排序数组 II
+
+- 题目：https://leetcode-cn.com/problems/search-in-rotated-sorted-array-ii/
+
+- 难度：中等
+
+  > 假设 154 是困难，那么这题，应该也是困难…
+
+- 解答：[no0081](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0081)
+
+### 852. 山脉数组的峰顶索引
+
+- 题目：https://leetcode-cn.com/problems/peak-index-in-a-mountain-array/
+- 难度：简单
+- 解答：[no0852](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0852)
+
+👉 **相似题目**：162. 寻找峰值
+
+- 题目：https://leetcode-cn.com/problems/find-peak-element/
+- 难度：中等
+- 解答：[no0162](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0162)
+
+### 069. x 的平方根
+
+- 题目：https://leetcode-cn.com/problems/sqrtx/
+- 难度：简单
+- 解答：[no0069](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0069)
+
+👉 **相似题目**：367. 有效的完全平方数
+
+- 题目：https://leetcode-cn.com/problems/powx-n/
+- 难度：简单
+- 解答：[no0367](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0367)
+
+👉 **相似题目**：540. 有序数组中的单一元素
+
+- 题目：https://leetcode-cn.com/problems/single-element-in-a-sorted-array/
+- 难度：中等
+- 解答：[no0540](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0540)
+
+## 栈和队列
+
+> 这个小节里，我们把「滑动窗口」，也归类在这里。未来，可能会拆分出去。
+
+### 232. 用队列实现栈
+
+- 题目：https://leetcode-cn.com/problems/implement-queue-using-stacks/
+- 难度：简单
+- 解答：[no0232](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0232)
+
+👉 **相似题目**：225. 用队列实现栈
+
+- 题目：https://leetcode-cn.com/problems/implement-stack-using-queues/
+- 难度：简单
+- 解答：[no0225](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0225)
+
+### 155. 最小栈
+
+- 题目：https://leetcode-cn.com/problems/min-stack/
+- 难度：简单
+- 解答：[no0155](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0155)
+
+👉 **相似题目**：716. 最大栈
+
+- 题目：https://leetcode-cn.com/problems/max-stack/
+- 难度：简单
+- 解答：[no0716](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0716)
+
+### 020. 有效的括号
+
+- 题目：https://leetcode-cn.com/problems/valid-parentheses/
+- 难度：简单
+- 解答：[no0020](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0020)
+
+👉 **相似题目**：1003. 检查替换后的词是否有效
+
+- 题目：https://leetcode-cn.com/problems/check-if-word-is-valid-after-substitutions/
+- 难度：中等
+- 解答：[no1003](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no1003)
+
+### 496. 下一个更大元素 I
+
+- 题目：https://leetcode-cn.com/problems/next-greater-element-i/
+- 难度：简单
+- 解答：[no0496](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0496)
+
+👉 **相似题目**：503. 下一个更大元素 II
+
+- 题目：https://leetcode-cn.com/problems/next-greater-element-ii/
+- 难度：中等
+- 解答：[no0503](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0503)
+
+👉 **相似题目**：739. 每日温度
+
+- 题目：https://leetcode-cn.com/problems/daily-temperatures/
+- 难度：中等
+- 解答：[no0739](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0739)
+
+👉 **相似题目**：239. 滑动窗口最大值
+
+- 题目：https://leetcode-cn.com/problems/sliding-window-maximum/
+- 难度：困难
+- 解答：[no0239](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0239)
+
+👉 **相似题目**：076. 最小覆盖子串
+
+- 题目：https://leetcode-cn.com/problems/minimum-window-substring/
+- 难度：困难
+- 解答：[no0076](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0076)
+
+👉 **相似题目**：438. 找到字符串中所有字母异位词
+
+- 题目：https://leetcode-cn.com/problems/find-all-anagrams-in-a-string/
+- 难度：简单
+- 解答：[no0438](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0438)
+
+## 递归
+
+### 856. 括号的分数
+
+- 题目：https://leetcode-cn.com/problems/score-of-parentheses/
+- 难度：中等
+- 解答：[no0856](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0856)
+
+### 394. 字符串解码
+
+- 题目：https://leetcode-cn.com/problems/decode-string/
+- 难度：中等
+- 解答：[no0394](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0394)
+
+👉 **相似题目**：726. 原子的数量
+
+- 题目：https://leetcode-cn.com/problems/number-of-atoms/
+- 难度：困难
+- 解答：[no0726](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0726)
+
+## 排序
+
+### 215. 数组中的第 K 个最大元素
+
+- 题目：https://leetcode-cn.com/problems/kth-largest-element-in-an-array/
+
+- 难度：中等
+
+- 解答：
+
+  no0215
+
+  - 堆排序
+  - 快速排序
+
+### 347. 前 K 个高频元素
+
+- 题目：https://leetcode-cn.com/problems/top-k-frequent-elements/
+
+- 难度：中等
+
+- 解答：
+
+  no0347
+
+  - 计数排序 + 快速排序
+
+👉 **相似题目**：451. 根据字符出现频率排序
+
+- 题目：https://leetcode-cn.com/problems/sort-characters-by-frequency/
+- 难度：中等
+- 解答：[no0415](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0415)
+
+### 075. 颜色分类
+
+- 题目：https://leetcode-cn.com/problems/sort-colors/
+- 难度：中等
+- 解答：[no0075](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0075)
+
+## 哈希表
+
+### 217. 存在重复元素
+
+- 题目：https://leetcode-cn.com/problems/contains-duplicate/
+- 难度：简单
+- 解答：[no0217](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0217)
+
+👉 **相似题目**：219. 存在重复元素 II
+
+- 题目：https://leetcode-cn.com/problems/contains-duplicate-ii/
+- 难度：简单
+- 解答：[no0219](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0219)
+
+👉 **相似题目**：220. 存在重复元素 III
+
+- 题目：https://leetcode-cn.com/problems/contains-duplicate-iii/
+
+- 难度：中等
+
+- 解答：
+
+  no0220
+
+  - 平衡二叉树
+  - 桶排序，😈 可以通过这个题目练习下。
+
+### 594. 最长和谐子序列
+
+- 题目：https://leetcode-cn.com/problems/longest-harmonious-subsequence/
+- 难度：简单
+- 解答：[no0594](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0594)
+
+### 128. 最长连续序列
+
+- 题目：https://leetcode-cn.com/problems/longest-consecutive-sequence/
+- 难度：困难
+- 解答：[no0128](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0128)
+
+### 387. 字符串中的第一个唯一字符
+
+- 题目：https://leetcode-cn.com/problems/first-unique-character-in-a-string/
+- 难度：简单
+- 解答：[no0387](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0387)
+
+## 树
+
+> 本小节，题目蛮多的，淡定。
+>
+> 另外，会包括一些二叉搜索树的题目，主要考虑相似题。
+
+### 104. 二叉树的最大深度
+
+- 题目：https://leetcode-cn.com/problems/maximum-depth-of-binary-tree/
+- 难度：简单
+- 解答：[no0104](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0104)
+
+👉 **相似题目**：111. 二叉树的最小深度
+
+- 题目：https://leetcode-cn.com/problems/minimum-depth-of-binary-tree/
+- 难度：简单
+- 解答：[no0111](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0111)
+
+👉 **相似题目**：110. 平衡二叉树
+
+- 题目：https://leetcode-cn.com/problems/balanced-binary-tree/
+- 难度：简单
+- 解答：[no0110](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0110)
+
+👉 **相似题目**：543. 两节点的最长路径
+
+- 题目：https://leetcode.com/problems/diameter-of-binary-tree/
+- 难度：简单
+- 解答：[no0543](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0543)
+
+### 112. 路径总和
+
+- 题目：https://leetcode-cn.com/problems/path-sum/
+- 难度：简单
+- 解答：[no0112](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0112)
+
+👉 **相似题目**：113. 路径总和 II
+
+- 题目：https://leetcode-cn.com/problems/path-sum-ii/
+- 难度：中等
+- 解答：[no0113](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0113)
+
+👉 **相似题目**：437. 路径总和 III
+
+- 题目：https://leetcode-cn.com/problems/path-sum-iii/
+- 难度：简单
+- 解答：[no0437](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0437)
+
+👉 **相似题目**：666. 路径总和 IIII
+
+- 题目：https://leetcode-cn.com/problems/path-sum-iiii/
+- 难度：简单
+- 解答：[no0666](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0666)
+
+👉 **相似题目**：687. 最长同值路径
+
+- 题目：https://leetcode-cn.com/problems/longest-univalue-path/
+- 难度：简单
+- 解答：[no0687](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0687)
+
+👉 **相似题目**：二叉树的所有路径
+
+- 题目：https://leetcode-cn.com/problems/binary-tree-paths/
+- 难度：简单
+- 解答：[no0257](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0257)
+
+👉 **相似题目**：129. 求根到叶子节点数字之和
+
+- 题目：https://leetcode-cn.com/problems/binary-tree-maximum-path-sum/
+- 难度：中等
+- 解答：[no0129](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0129)
+
+👉 **相似题目**：124. 二叉树中的最大路径和
+
+- 题目：https://leetcode-cn.com/problems/sum-root-to-leaf-numbers/
+- 难度：困难
+- 解答：[no0124](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0124)
+
+👉 **相似题目**：508. 出现次数最多的子树元素和
+
+- 题目：https://leetcode-cn.com/problems/most-frequent-subtree-sum/%3E
+- 难度：中等
+- 解答：[no0508](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0508)
+
+### 226. 翻转二叉树
+
+- 题目：https://leetcode-cn.com/problems/invert-binary-tree/
+- 难度：简单
+- 解答：[no0226](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0226)
+
+### 617. 合并二叉树
+
+- 题目：https://leetcode-cn.com/problems/merge-two-binary-trees/
+- 难度：简单
+- 解答：[no0617](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0617)
+
+### 572. 另一个树的子树
+
+- 题目：https://leetcode-cn.com/problems/subtree-of-another-tree/
+- 难度：简单
+- 解答：[no0572](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0572)
+
+👉 **相似题目**：100. 相同的树
+
+- 题目：https://leetcode-cn.com/problems/same-tree/
+- 难度：简单
+- 解答：[no0100](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0100)
+
+👉 **相似题目**：965. 单值二叉树
+
+- 题目：https://leetcode-cn.com/problems/univalued-binary-tree/
+- 难度：简单
+- 解答：[no0965](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0965)
+
+👉 **相似题目**：872. 叶子相似的树
+
+- 题目：https://leetcode-cn.com/problems/leaf-similar-trees/
+- 难度：简单
+- 解答：[no0872](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0872)
+
+👉 **相似题目**：101. 对称二叉树
+
+- 题目：https://leetcode-cn.com/problems/symmetric-tree/
+- 难度：简单
+- 解答：[no0101](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0101)
+
+### 337. 打家劫舍 III
+
+- 题目：https://leetcode-cn.com/problems/house-robber-iii/
+
+- 难度：中等
+
+- 解答：
+
+  no0337
+
+  - 暴力 DFS 递归
+  - 经典的树状动态规划
+
+### 671. 二叉树中第二小的节点
+
+- 题目：https://leetcode-cn.com/problems/second-minimum-node-in-a-binary-tree/
+- 难度：简单
+- 解答：[no0671](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0671)
+
+👉 **相似题目**：230. 二叉搜索树中第K小的元素
+
+- 题目：https://leetcode-cn.com/problems/kth-smallest-element-in-a-bst/
+- 难度：中等
+- 解答：[no0230](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0230)
+
+### 637. 二叉树的层平均值
+
+- 题目：https://leetcode-cn.com/problems/average-of-levels-in-binary-tree/
+- 难度：简单
+- 解答：[no0637](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0637)
+
+👉 **相似题目**：102. 二叉树的层次遍历
+
+- 题目：https://leetcode-cn.com/problems/binary-tree-level-order-traversal/
+- 难度：中等
+- 解答：[no0102](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0102)
+
+👉 **相似题目**：107. 二叉树的层次遍历 II
+
+- 题目：https://leetcode-cn.com/problems/binary-tree-level-order-traversal-ii/
+- 难度：简单
+- 解答：[no0107](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0107)
+
+### 517. 找树左下角的值
+
+- 题目：https://leetcode-cn.com/problems/find-bottom-left-tree-value/
+- 难度：简单
+- 解答：[no0517](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0517)
+
+### 144. 二叉树的前序遍历
+
+- 题目：https://leetcode-cn.com/problems/find-bottom-left-tree-value/
+- 难度：中等
+- 解答：[no0144](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0144)
+
+👉 **相似题目**：094. 二叉树的中序遍历
+
+- 题目：https://leetcode-cn.com/problems/binary-tree-inorder-traversal/
+- 难度：中等
+- 解答：[no0094](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0094)
+
+👉 **相似题目**：145. 二叉树的后序遍历
+
+- 题目：https://leetcode-cn.com/problems/binary-tree-postorder-traversal/
+- 难度：困难
+- 解答：[no0145](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0145)
+
+👉 **相似题目**：589. N 叉树的前序遍历
+
+- 题目：https://leetcode-cn.com/problems/n-ary-tree-preorder-traversal/
+- 难度：简单
+- 解答：[no0589](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0589)
+
+👉 **相似题目**：429. N 叉树的层序遍历
+
+- 题目：https://leetcode-cn.com/problems/n-ary-tree-level-order-traversal/
+- 难度：简单
+- 解答：[no0429](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0429)
+
+👉 **相似题目**：590. N 叉树的后序遍历
+
+- 题目：https://leetcode-cn.com/problems/n-ary-tree-postorder-traversal/
+- 难度：简单
+- 解答：[no0590](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0590)
+
+👉 **相似题目**：987. 二叉树的垂序遍历
+
+- 题目：https://leetcode-cn.com/problems/vertical-order-traversal-of-a-binary-tree/
+- 难度：中等
+- 解答：[no0987](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0987)
+
+### 297. 二叉树的序列化与反序列化
+
+- 题目：https://leetcode-cn.com/problems/serialize-and-deserialize-binary-tree/
+- 难度：困难
+- 解答：[no0297](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0297)
+
+👉 **相似题目**：449. 序列化和反序列化二叉搜索树
+
+- 题目：https://leetcode-cn.com/problems/serialize-and-deserialize-bst/
+- 难度：中等
+- 解答：[no0449](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0449)
+
+### 236. 二叉树的最近公共祖先
+
+- 题目：https://leetcode-cn.com/problems/lowest-common-ancestor-of-a-binary-tree/
+- 难度：中等
+- 解答：[no0236](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0236)
+
+👉 **相似题目**：235. 二叉搜索树的最近公共祖先
+
+- 题目：https://leetcode-cn.com/problems/lowest-common-ancestor-of-a-binary-search-tree/
+- 难度：简单
+- 解答：[no0235](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0235)
+
+### 814. 二叉树剪枝
+
+- 题目：https://leetcode-cn.com/problems/binary-tree-pruning/
+- 难度：简单
+- 解答：[no0814](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0814)
+
+## 二叉搜索树
+
+### 501. 二叉搜索树中的众数
+
+- 题目：https://leetcode-cn.com/problems/find-mode-in-binary-search-tree/
+- 难度：简单
+- 解答：[no0501](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0501)
+
+👉 **相似题目**：098. 验证二叉搜索树
+
+- 题目：https://leetcode-cn.com/problems/validate-binary-search-tree/
+- 难度：中等
+- 解答：[no0098](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0098)
+
+👉 **相似题目**：530. 二叉搜索树的最小绝对差
+
+- 题目：https://leetcode-cn.com/problems/minimum-absolute-difference-in-bst/
+- 难度：简单
+- 解答：[no0530](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0530)
+
+👉 **相似题目**：538. 把二叉搜索树转换为累加树
+
+- 题目：https://leetcode-cn.com/problems/convert-bst-to-greater-tree/
+- 难度：简单
+- 解答：[no0538](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0538)
+
+👉 **相似题目**：653. 两数之和 IV - 输入 BST
+
+- 题目：https://leetcode-cn.com/problems/two-sum-iv-input-is-a-bst/
+- 难度：简单
+- 解答：[no0653](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0653)
+
+### 108. 将有序数组转换为二叉搜索树
+
+- 题目：https://leetcode-cn.com/problems/convert-sorted-array-to-binary-search-tree/
+- 难度：简单
+- 解答：[no0108](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0108)
+
+👉 **相似题目**：109. 有序链表转换二叉搜索树
+
+- 题目：https://leetcode-cn.com/problems/convert-sorted-list-to-binary-search-tree/
+- 难度：中等
+- 解答：[no0109](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0109)
+
+### 700. 二叉搜索树中的搜索
+
+- 题目：https://leetcode-cn.com/problems/search-in-a-binary-search-tree/
+- 难度：简单
+- 解答：[no0700](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0700)
+
+👉 **相似题目**：701. 二叉搜索树中的插入操作
+
+- 题目：https://leetcode-cn.com/problems/insert-into-a-binary-search-tree/
+- 难度：中等
+- 解答：[no0701](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0701)
+
+👉 **相似题目**：450. 删除二叉搜索树中的节点
+
+- 题目：https://leetcode-cn.com/problems/delete-node-in-a-bst/
+- 难度：中等
+- 解答：[no0450](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0450)
+
+👉 **相似题目**：776. 拆分二叉搜索树
+
+- 题目：https://leetcode-cn.com/problems/split-bst/
+- 难度：中等
+- 解答：[no0776](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0776)
+
+👉 **相似题目**：669. 修剪二叉搜索树
+
+- 题目：https://leetcode-cn.com/problems/trim-a-binary-search-tree/
+- 难度：简单
+- 解答：[no0669](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0669)
+
+### 099. 恢复二叉搜索树
+
+- 题目：https://leetcode-cn.com/problems/recover-binary-search-tree/
+- 难度：困难
+- 解答：[no0099](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0099)
+
+## 字典树
+
+### 208. 实现 Trie (前缀树)
+
+- 题目：https://leetcode-cn.com/problems/implement-trie-prefix-tree/
+- 难度：中等
+- 解答：[no0208](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0208)
+
+👉 **相似题目**：键值映射
+
+- 题目：https://leetcode-cn.com/problems/map-sum-pairs/
+- 难度：中等
+- 解答：[no0677](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0667)
+
+## BFS && DFS
+
+> 考虑到很多题目，既可以用广度优先搜索，也可以使用深度优先搜索。所以，放在一个小节。
+
+### 785. 判断二分图
+
+- 题目：https://leetcode-cn.com/problems/is-graph-bipartite/
+- 难度：中等
+- 解答：[no0785](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0785)
+
+### 133. 克隆图
+
+- 题目：https://leetcode-cn.com/problems/clone-graph/
+- 难度：中等
+- 解答：[no0133](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0133)
+
+👉 **相似题目**：138. 复制带随机指针的链表
+
+- 题目：https://leetcode-cn.com/problems/copy-list-with-random-pointer/
+- 难度：中等
+- 解答：[no0138](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0138)
+
+### 733. 图像渲染
+
+- 题目：https://leetcode-cn.com/problems/flood-fill/
+- 难度：简单
+- 解答：[no0733](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0733)
+
+👉 **相似题目**：827. 最大人工岛
+
+- 题目：https://leetcode-cn.com/problems/making-a-large-island/
+- 难度：困难
+- 解答：[no0827](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0827)
+
+### 279. 完全平方数
+
+- 题目：https://leetcode-cn.com/problems/perfect-squares/
+- 难度：中等
+- 解答：[no0279](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0279)
+
+### 127. 单词接龙
+
+- 题目：https://leetcode-cn.com/problems/word-ladder/
+- 难度：中等
+- 解答：[no0127](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0127)
+
+👉 **相似题目**：126. 单词接龙 II
+
+- 题目：https://leetcode-cn.com/problems/word-ladder-ii/
+- 难度：困难
+- 解答：[no0126](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0126)
+
+👉 **相似题目**：433. 最小基因变化
+
+- 题目：https://leetcode-cn.com/problems/minimum-genetic-mutation/
+- 难度：中等
+- 解答：[no0433](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0433)
+
+👉 **相似题目**：752. 打开转盘锁
+
+- 题目：https://leetcode-cn.com/problems/open-the-lock/
+- 难度：中等
+- 解答：[no0752](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0752)
+
+### 695. 岛屿的最大面积
+
+- 题目：https://leetcode-cn.com/problems/max-area-of-island/
+- 难度：中等
+- 解答：[no0695](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0695)
+
+👉 **相似题目**：200. 岛屿数量
+
+- 题目：https://leetcode-cn.com/problems/number-of-islands/
+- 难度：中等
+- 解答：[no0200](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0200)
+
+👉 **相似题目**：130. 被围绕的区域
+
+- 题目：https://leetcode-cn.com/problems/surrounded-regions/
+- 难度：中等
+- 解答：[no0130](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0130)
+
+### 547. 朋友圈
+
+- 题目：https://leetcode-cn.com/problems/friend-circles/
+- 难度：中等
+- 解答：[no0547](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0547)
+
+### 417. 太平洋大西洋水流问题
+
+- 题目：https://leetcode-cn.com/problems/pacific-atlantic-water-flow/
+- 难度：中等
+- 解答：[no0417](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0417)
+
+### 841. 钥匙和房间
+
+- 题目：https://leetcode-cn.com/problems/keys-and-rooms/
+- 难度：中等
+- 解答：[no0841](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0841)
+
+### 542. 01 矩阵
+
+- 题目：https://leetcode-cn.com/problems/01-matrix/
+- 难度：中等
+- 解答：[no0542](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0542)
+
+👉 **相似题目**：934. 最短的桥
+
+- 题目：https://leetcode-cn.com/problems/shortest-bridge/
+- 难度：中等
+- 解答：[no0934](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0934)
+
+👉 **相似题目**：675. 为高尔夫比赛砍树
+
+- 题目：https://leetcode-cn.com/problems/cut-off-trees-for-golf-event/
+- 难度：中等
+- 解答：[no0675](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0675)
+
+## 并查集
+
+> 实际上，并查集的题目，是可以使用 BFS 和 DFS 进行实现的，所以本小节题目不会放很多。很多题目，我们在 [「BFS && DFS」](https://svip.iocoder.cn/Data-Structures-and-Algorithms/Interview/#) 小节，顺手去写了下。
+
+### 684. 冗余连接
+
+- 题目：https://leetcode-cn.com/problems/redundant-connection/
+- 难度：中等
+- 解答：[no0684](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0684)
+
+## 拓扑排序
+
+### 207. 课程表
+
+- 题目：https://leetcode-cn.com/problems/course-schedule/
+- 难度：中等
+- 解答：[no0207](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0207)
+
+👉 **相似题目**：210. 课程表 II
+
+- 题目：https://leetcode-cn.com/problems/course-schedule-ii/
+- 难度：中等
+- 解答：[no0210](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0210)
+
+### 802. 找到最终的安全状态
+
+- 题目：https://leetcode-cn.com/problems/find-eventual-safe-states/
+- 难度：中等
+- 解答：[no0802](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0802)
+
+## 回溯算法
+
+> 我们会发现，很多回溯算法，是使用 DFS 进行实现。回溯算法是一种思想，常常使用 DFS 算法的方式，进行实现。
+
+### 017. 电话号码的字母组合
+
+- 题目：https://leetcode-cn.com/problems/letter-combinations-of-a-phone-number/
+- 难度：中等
+- 解答：[no0017](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0017)
+
+👉 **相似题目**：022. 括号生成
+
+- 题目：https://leetcode-cn.com/problems/generate-parentheses/
+- 难度：中等
+- 解答：[no0022](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0022)
+
+👉 **相似题目**：301. 删除无效的括号
+
+- 题目：https://leetcode-cn.com/problems/remove-invalid-parentheses/
+- 难度：困难
+- 解答：[no0301](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0301)
+
+### 093. 复原IP地址
+
+- 题目：https://leetcode-cn.com/problems/restore-ip-addresses/
+- 难度：中等
+- 解答：[no0093](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0093)
+
+### 079. 单词搜索
+
+- 题目：https://leetcode-cn.com/problems/word-search/
+- 难度：中等
+- 解答：[no0079](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0079)
+
+👉 **相似题目**：212. 单词搜索 II
+
+- 题目：https://leetcode-cn.com/problems/word-search-ii/
+- 难度：困难
+- 解答：[no0212](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0212)
+
+### 046. 全排列
+
+- 题目：https://leetcode-cn.com/problems/permutations/
+- 难度：中等
+- 解答：[no0046](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0046)
+
+👉 **相似题目**：047. 全排列 II
+
+- 题目：https://leetcode-cn.com/problems/permutations-ii/
+- 难度：中等
+- 解答：[no0047](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0047)
+
+👉 **相似题目**：996. 正方形数组的数目
+
+- 题目：https://leetcode-cn.com/problems/number-of-squareful-arrays/
+- 难度：困难
+- 解答：[no0996](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no00996)
+
+👉 **相似题目**：077. 组合
+
+- 题目：https://leetcode-cn.com/problems/combinations/
+- 难度：中等
+- 解答：[no0077](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0077)
+
+👉 **相似题目**：784. 字母大小写全排列
+
+- 题目：https://leetcode-cn.com/problems/letter-case-permutation/
+- 难度：简单
+- 解答：[no0784](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0784)
+
+👉 **相似题目**：039. 组合总和
+
+- 题目：https://leetcode-cn.com/problems/combination-sum/
+- 难度：中等
+- 解答：[no0039](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0039)
+
+👉 **相似题目**：040. 组合总和 II
+
+- 题目：https://leetcode-cn.com/problems/combination-sum-ii/
+- 难度：中等
+- 解答：[no0040](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0040)
+
+👉 **相似题目**：216. 组合总和 III
+
+- 题目：https://leetcode-cn.com/problems/combination-sum-iii/
+- 难度：中等
+- 解答：[no0216](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0216)
+
+👉 **相似题目**：282. 给表达式添加运算符
+
+- 题目：https://leetcode-cn.com/problems/expression-add-operators/
+- 难度：困难
+- 解答：[no0282](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0282)
+
+### 078. 子集
+
+- 题目：https://leetcode-cn.com/problems/subsets/
+- 难度：中等
+- 解答：[no0078](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0078)
+
+👉 **相似题目**：090. 子集 II
+
+- 题目：https://leetcode-cn.com/problems/subsets-ii/
+- 难度：中等
+- 解答：[no0090](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0090)
+
+### 131. 分割回文串
+
+- 题目：https://leetcode-cn.com/problems/palindrome-partitioning/
+- 难度：中等
+- 解答：[no0131](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0131)
+
+### 842. 将数组拆分成斐波那契序列
+
+- 题目：https://leetcode-cn.com/problems/split-array-into-fibonacci-sequence/
+- 难度：中等
+- 解答：[no0842](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0842)
+
+### 037. 解数独
+
+- 题目：https://leetcode-cn.com/problems/sudoku-solver/
+- 难度：困难
+- 解答：[no0037](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0037)
+
+👉 **相似题目**：051. N皇后
+
+- 题目：https://leetcode-cn.com/problems/n-queens/
+- 难度：中等
+- 解答：[no0051](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0051)
+
+👉 **相似题目**：052. N皇后
+
+- 题目：https://leetcode-cn.com/problems/n-queens-ii/
+- 难度：中等
+- 解答：[no0052](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0052)
+
+## 分治算法
+
+### 241. 为运算表达式设计优先级
+
+- 题目：https://leetcode-cn.com/problems/different-ways-to-add-parentheses/
+- 难度：中等
+- 解答：[no0241](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0241)
+
+### 096. 不同的二叉搜索树
+
+- 题目：https://leetcode-cn.com/problems/unique-binary-search-trees/
+- 难度：中等
+- 解答：[no0096](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0096)
+
+👉 **相似题目**：095. 不同的二叉搜索树 II
+
+- 题目：https://leetcode-cn.com/problems/unique-binary-search-trees-ii/
+- 难度：中等
+- 解答：[no0095](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0095)
+
+> 关于下面的众数的题目，只有 169 是通过分治算法解决，并且还不是最优解。最优是 [“Boyer-Moore 投票算法”](https://blog.csdn.net/kimixuchen/article/details/52787307) 。
+
+### 169. 求众数
+
+- 题目：https://leetcode-cn.com/problems/majority-element/
+- 难度：简单
+- 解答：[no0169](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0169)
+
+👉 **相似题目**：229. 求众数 II
+
+- 题目：https://leetcode-cn.com/problems/majority-element-ii/
+- 难度：中等
+- 解答：[no0229](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0229)
+
+## 贪心算法
+
+### 455. 分发饼干
+
+- 题目：https://leetcode-cn.com/problems/assign-cookies/
+- 难度：简单
+- 解答：[no0455](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0455)
+
+### 435. 无重叠区间
+
+- 题目：https://leetcode-cn.com/problems/non-overlapping-intervals/
+- 难度：中等
+- 解答：[no0435](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0435)
+
+👉 **相似题目**：452. 用最少数量的箭引爆气球
+
+- 题目：https://leetcode-cn.com/problems/minimum-number-of-arrows-to-burst-balloons/
+- 难度：中等
+- 解答：[no0452](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0452)
+
+### 406. 根据身高重建队列
+
+- 题目：https://leetcode-cn.com/problems/queue-reconstruction-by-height/
+- 难度：中等
+- 解答：[no0406](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0406)
+
+### 121. 买卖股票的最佳时机
+
+- 题目：https://leetcode-cn.com/problems/best-time-to-buy-and-sell-stock/
+- 难度：简单
+- 解答：[no0121](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0121)
+
+👉 **相似题目**：122. 买卖股票的最佳时机 II
+
+- 题目：https://leetcode-cn.com/problems/best-time-to-buy-and-sell-stock-ii/
+- 难度：简单
+- 解答：[no0122](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0122)
+
+### 392. 判断子序列
+
+- 题目：https://leetcode-cn.com/problems/is-subsequence/
+- 难度：简单
+- 解答：[no0392](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0392)
+
+### 055. 跳跃游戏
+
+- 题目：https://leetcode-cn.com/problems/is-subsequence/
+- 难度：简单
+- 解答：[no0053](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0053)
+
+### 763. 划分字母区间
+
+- 题目：https://leetcode-cn.com/problems/partition-labels/
+- 难度：中等
+- 解答：[no0763](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0763)
+
+### 055. 跳跃游戏
+
+- 题目：https://leetcode-cn.com/problems/jump-game/
+- 难度：中等
+- 解答：[no0055](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0055)
+
+👉 **相似题目**：045. 跳跃游戏 II
+
+- 题目：https://leetcode-cn.com/problems/jump-game-ii/
+- 难度：困难
+- 解答：[no0045](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0045)
+
+## 动态规划 DOING
+
+TODO 需要整理下
+
+动态规划题型
+
+- 0-1 背包
+- 斐波那契数列
+
+### 509. 斐波那契数
+
+- 题目：https://leetcode-cn.com/problems/fibonacci-number/
+- 难度：简单
+- 解答：[no0509](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0509)
+
+👉 **相似题目**：070. 爬楼梯
+
+- 题目：https://leetcode-cn.com/problems/climbing-stairs/
+- 难度：简单
+- 解答：[no0070](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0070)
+
+👉 **相似题目**：746. 使用最小花费爬楼梯
+
+- 题目：https://leetcode-cn.com/problems/min-cost-climbing-stairs/
+- 难度：简单
+- 解答：[no0746](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0746)
+
+### 198. 打家劫舍
+
+- 题目：https://leetcode-cn.com/problems/house-robber/
+- 难度：简单
+- 解答：[no0198](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0198)
+
+👉 **相似题目**：213. 打家劫舍 II
+
+- 题目：https://leetcode-cn.com/problems/house-robber-II/
+- 难度：中等
+- 解答：[no0213](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0213)
+
+### 064. 最小路径和
+
+- 题目：https://leetcode-cn.com/problems/minimum-path-sum/
+- 难度：中等
+- 解答：[no0064](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0064)
+
+👉 **相似题目**：062. 不同路径
+
+- 题目：https://leetcode-cn.com/problems/unique-paths/
+- 难度：中等
+- 解答：[no0062](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0062)
+
+👉 **相似题目**：063. 不同路径 II
+
+- 题目：https://leetcode-cn.com/problems/unique-paths-ii/
+- 难度：中等
+- 解答：[no0063](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0063)
+
+### 303. 区域和检索 - 数组不可变
+
+- 题目：https://leetcode-cn.com/problems/range-sum-query-immutable/
+- 难度：简单
+- 解答：[no0303](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0303)
+
+### 413. 等差数列划分
+
+- 题目：https://leetcode-cn.com/problems/arithmetic-slices/
+- 难度：中等
+- 解答：[no0413](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0413)
+
+### 343. 整数拆分
+
+- 题目：https://leetcode-cn.com/problems/integer-break/
+- 难度：中等
+- 解答：[no0343](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0343)
+
+### 091. 解码方法
+
+- 题目：https://leetcode-cn.com/problems/decode-ways/
+- 难度：中等
+- 解答：[no0091](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0091)
+
+### 416. 分割等和子集
+
+- 题目：https://leetcode-cn.com/problems/partition-equal-subset-sum/
+- 难度：中等
+- 解答：[no0416](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0416)
+
+### 494. 目标和
+
+- 题目：https://leetcode-cn.com/problems/target-sum/
+- 难度：中等
+- 解答：[no0494](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0494)
+
+### 474. 一和零
+
+- 题目：https://leetcode-cn.com/problems/ones-and-zeroes/
+- 难度：中等
+- 解答：[no0474](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0474)
+
+### 322. 零钱兑换
+
+- 题目：https://leetcode-cn.com/problems/coin-change/
+- 难度：中等
+- 解答：[no0322](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0322)
+
+👉 **相似题目**：518. 零钱兑换 II
+
+- 题目：https://leetcode-cn.com/problems/coin-change-2/
+- 难度：中等
+- 解答：[no0518](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0518)
+
+👉 **相似题目**：377. 组合总和 Ⅳ
+
+- 题目：https://leetcode-cn.com/problems/combination-sum-iv/
+- 难度：中等
+- 解答：[no0377](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0377)
+
+### 139. 单词拆分
+
+- 题目：https://leetcode-cn.com/problems/word-break/
+- 难度：中等
+- 解答：[no0139](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0139)
+
+### 309. 最佳买卖股票时机含冷冻期
+
+- 题目：https://leetcode-cn.com/problems/best-time-to-buy-and-sell-stock-with-cooldown/
+- 难度：中等
+- 解答：[no0309](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0309)
+
+👉 **相似题目**：714. 买卖股票的最佳时机含手续费
+
+- 题目：https://leetcode-cn.com/problems/best-time-to-buy-and-sell-stock-with-transaction-fee/
+- 难度：中等
+- 解答：[no0714](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0714)
+
+👉 **相似题目**：123. 买卖股票的最佳时机 III
+
+- 题目：https://leetcode-cn.com/problems/best-time-to-buy-and-sell-stock-iii/
+- 难度：困难
+- 解答：[no0123](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0123)
+
+👉 **相似题目**：188. 买卖股票的最佳时机 IV
+
+- 题目：https://leetcode-cn.com/problems/best-time-to-buy-and-sell-stock-iv/
+- 难度：困难
+- 解答：[no0188](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0188)
+
+### 221. 最大正方形
+
+- 题目：https://leetcode-cn.com/problems/maximal-square/
+- 难度：中等
+- 解答：[no0221](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0221)
+
+👉 **相似题目**：085. 最大矩形
+
+- 题目：https://leetcode-cn.com/problems/maximal-rectangle/
+- 难度：困难
+- 解答：[no0085](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0085)
+
+👉 **相似题目**：84. 柱状图中最大的矩形
+
+- 题目：https://leetcode-cn.com/problems/largest-rectangle-in-histogram/
+- 难度：困难
+- 解答：[no0084](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0084)
+
+### 152. 乘积最大子序列
+
+- 题目：https://leetcode-cn.com/problems/maximum-product-subarray/
+- 难度：中等
+- 解答：[no0152](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0152)
+
+## 位运算
+
+> 位操作很骚，有些想不到，真的就是想不到。
+
+### 461. 汉明距离
+
+- 题目：https://leetcode-cn.com/problems/hamming-distance/
+- 难度：简单
+- 解答：[no0461](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0461)
+
+### 136. 只出现一次的数字
+
+- 题目：https://leetcode-cn.com/problems/single-number/
+- 难度：简单
+- 解答：[no0136](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0136)
+
+👉 **相似题目**：268. 缺失数字
+
+- 题目：https://leetcode-cn.com/problems/missing-number/
+- 难度：简单
+- 解答：[no0268](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0268)
+
+👉 **相似题目**：260. 只出现一次的数字 III
+
+- 题目：https://leetcode-cn.com/problems/single-number-iii/
+- 难度：中等
+- 解答：[no0260](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0260)
+
+### 190. 颠倒二进制位
+
+- 题目：https://leetcode-cn.com/problems/reverse-bits/
+- 难度：简单
+- 解答：[no0190](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0190)
+
+### 231. 2 的幂
+
+- 题目：https://leetcode-cn.com/problems/power-of-two/
+- 难度：简单
+- 解答：[no0231](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0231)
+
+👉 **相似题目**：342. 4 的幂
+
+- 题目：https://leetcode-cn.com/problems/power-of-four/
+- 难度：简单
+- 解答：[no0342](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0342)
+
+### 693. 交替位二进制数
+
+- 题目：https://leetcode-cn.com/problems/binary-number-with-alternating-bits/
+- 难度：简单
+- 解答：[no0693](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0693)
+
+### 476. 数字的补数
+
+- 题目：https://leetcode-cn.com/problems/number-complement/
+- 难度：简单
+- 解答：[no0476](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no476)
+
+### 371. 两整数之和
+
+- 题目：https://leetcode-cn.com/problems/sum-of-two-integers/
+- 难度：简单
+- 解答：[no0371](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0317)
+
+### 318. 最大单词长度乘积
+
+- 题目：https://leetcode-cn.com/problems/maximum-product-of-word-lengths/
+- 难度：
+- 解答：[no0318](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0318)
+
+### 191. 位1的个数
+
+- 题目：https://leetcode-cn.com/problems/number-of-1-bits/
+- 难度：简单
+- 解答：[no0191](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0191)
+
+👉 **相似题目**：338. 比特位计数
+
+- 题目：https://leetcode-cn.com/problems/counting-bits/
+- 难度：中等
+- 解答：[no0338](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0338)
+
+## 数学 TODO
+
+## TODO
+
+\###
+
+- 题目：<>
+- 难度：
+- 解答：[no0](https://github.com/YunaiV/algorithm1024/tree/master/src/main/java/cn/iocoder/algorithm/leetcode/no0)
+
+👉 **相似题目**：
\ No newline at end of file
diff --git a/面试题/21-精尽计算机网络面试题.assets/01-171824950787319.jpeg b/面试题/21-精尽计算机网络面试题.assets/01-171824950787319.jpeg
new file mode 100644
index 0000000..e76560c
Binary files /dev/null and b/面试题/21-精尽计算机网络面试题.assets/01-171824950787319.jpeg differ
diff --git a/面试题/21-精尽计算机网络面试题.assets/0332b5d6001f7446a04a5d54b9b93d7e-171824950787322 b/面试题/21-精尽计算机网络面试题.assets/0332b5d6001f7446a04a5d54b9b93d7e-171824950787322
new file mode 100644
index 0000000..c2155c7
Binary files /dev/null and b/面试题/21-精尽计算机网络面试题.assets/0332b5d6001f7446a04a5d54b9b93d7e-171824950787322 differ
diff --git a/面试题/21-精尽计算机网络面试题.assets/047b5c455b1153e895df36e364134fcd.jpeg b/面试题/21-精尽计算机网络面试题.assets/047b5c455b1153e895df36e364134fcd.jpeg
new file mode 100644
index 0000000..2ddcdde
Binary files /dev/null and b/面试题/21-精尽计算机网络面试题.assets/047b5c455b1153e895df36e364134fcd.jpeg differ
diff --git a/面试题/21-精尽计算机网络面试题.assets/04edb57536fc9bbd3ea096cafa5d3630.png b/面试题/21-精尽计算机网络面试题.assets/04edb57536fc9bbd3ea096cafa5d3630.png
new file mode 100644
index 0000000..3642d05
Binary files /dev/null and b/面试题/21-精尽计算机网络面试题.assets/04edb57536fc9bbd3ea096cafa5d3630.png differ
diff --git a/面试题/21-精尽计算机网络面试题.assets/0e2ff871cdb6c2b58a6a2fc3bec51933.jpeg b/面试题/21-精尽计算机网络面试题.assets/0e2ff871cdb6c2b58a6a2fc3bec51933.jpeg
new file mode 100644
index 0000000..cb37774
Binary files /dev/null and b/面试题/21-精尽计算机网络面试题.assets/0e2ff871cdb6c2b58a6a2fc3bec51933.jpeg differ
diff --git a/面试题/21-精尽计算机网络面试题.assets/2cf7b8d1689ae6e920ef1b2c3eafb8b2.png b/面试题/21-精尽计算机网络面试题.assets/2cf7b8d1689ae6e920ef1b2c3eafb8b2.png
new file mode 100644
index 0000000..727a0db
Binary files /dev/null and b/面试题/21-精尽计算机网络面试题.assets/2cf7b8d1689ae6e920ef1b2c3eafb8b2.png differ
diff --git a/面试题/21-精尽计算机网络面试题.assets/3ed1936c7ee8639606bc8b3dccc2d5bc.png b/面试题/21-精尽计算机网络面试题.assets/3ed1936c7ee8639606bc8b3dccc2d5bc.png
new file mode 100644
index 0000000..2118efb
Binary files /dev/null and b/面试题/21-精尽计算机网络面试题.assets/3ed1936c7ee8639606bc8b3dccc2d5bc.png differ
diff --git a/面试题/21-精尽计算机网络面试题.assets/482a127d8fd07940d8f255610c716792-171824950787323 b/面试题/21-精尽计算机网络面试题.assets/482a127d8fd07940d8f255610c716792-171824950787323
new file mode 100644
index 0000000..03fb264
Binary files /dev/null and b/面试题/21-精尽计算机网络面试题.assets/482a127d8fd07940d8f255610c716792-171824950787323 differ
diff --git a/面试题/21-精尽计算机网络面试题.assets/61ed2a8b189fc549a9c7407c2ebedb64-171824950787321 b/面试题/21-精尽计算机网络面试题.assets/61ed2a8b189fc549a9c7407c2ebedb64-171824950787321
new file mode 100644
index 0000000..1fb5434
Binary files /dev/null and b/面试题/21-精尽计算机网络面试题.assets/61ed2a8b189fc549a9c7407c2ebedb64-171824950787321 differ
diff --git a/面试题/21-精尽计算机网络面试题.assets/6ed78395a32a0fbf56afed309dc1eb71.jpeg b/面试题/21-精尽计算机网络面试题.assets/6ed78395a32a0fbf56afed309dc1eb71.jpeg
new file mode 100644
index 0000000..2ccc0b9
Binary files /dev/null and b/面试题/21-精尽计算机网络面试题.assets/6ed78395a32a0fbf56afed309dc1eb71.jpeg differ
diff --git a/面试题/21-精尽计算机网络面试题.assets/7268e2a2553c6612396b7de03667d348-171824950787324 b/面试题/21-精尽计算机网络面试题.assets/7268e2a2553c6612396b7de03667d348-171824950787324
new file mode 100644
index 0000000..aa1931f
Binary files /dev/null and b/面试题/21-精尽计算机网络面试题.assets/7268e2a2553c6612396b7de03667d348-171824950787324 differ
diff --git a/面试题/21-精尽计算机网络面试题.assets/82cf7ea112281d126f23db03a502c249.jpeg b/面试题/21-精尽计算机网络面试题.assets/82cf7ea112281d126f23db03a502c249.jpeg
new file mode 100644
index 0000000..c35fb76
Binary files /dev/null and b/面试题/21-精尽计算机网络面试题.assets/82cf7ea112281d126f23db03a502c249.jpeg differ
diff --git a/面试题/21-精尽计算机网络面试题.assets/96da7b757bb0dc2f2eaf86ac8ad20858.jpeg b/面试题/21-精尽计算机网络面试题.assets/96da7b757bb0dc2f2eaf86ac8ad20858.jpeg
new file mode 100644
index 0000000..eadee62
Binary files /dev/null and b/面试题/21-精尽计算机网络面试题.assets/96da7b757bb0dc2f2eaf86ac8ad20858.jpeg differ
diff --git a/面试题/21-精尽计算机网络面试题.assets/a36ed3dad53b9b4439bc8156bc63a2c0.jpeg b/面试题/21-精尽计算机网络面试题.assets/a36ed3dad53b9b4439bc8156bc63a2c0.jpeg
new file mode 100644
index 0000000..db0c11b
Binary files /dev/null and b/面试题/21-精尽计算机网络面试题.assets/a36ed3dad53b9b4439bc8156bc63a2c0.jpeg differ
diff --git a/面试题/21-精尽计算机网络面试题.assets/a9e8780d6b899cf5709579fc9c451fd9-171824950787318 b/面试题/21-精尽计算机网络面试题.assets/a9e8780d6b899cf5709579fc9c451fd9-171824950787318
new file mode 100644
index 0000000..d0ee08c
Binary files /dev/null and b/面试题/21-精尽计算机网络面试题.assets/a9e8780d6b899cf5709579fc9c451fd9-171824950787318 differ
diff --git a/面试题/21-精尽计算机网络面试题.assets/bd1dd61fc5562ec031e0c6aa712c926b.jpeg b/面试题/21-精尽计算机网络面试题.assets/bd1dd61fc5562ec031e0c6aa712c926b.jpeg
new file mode 100644
index 0000000..3f94cbc
Binary files /dev/null and b/面试题/21-精尽计算机网络面试题.assets/bd1dd61fc5562ec031e0c6aa712c926b.jpeg differ
diff --git a/面试题/21-精尽计算机网络面试题.assets/bdf6be06c37bcc026ed906f392661e3b-171824950787320 b/面试题/21-精尽计算机网络面试题.assets/bdf6be06c37bcc026ed906f392661e3b-171824950787320
new file mode 100644
index 0000000..190c363
Binary files /dev/null and b/面试题/21-精尽计算机网络面试题.assets/bdf6be06c37bcc026ed906f392661e3b-171824950787320 differ
diff --git a/面试题/21-精尽计算机网络面试题.assets/be5603b1bb6ff46b640909b5b8976827-171824950787216 b/面试题/21-精尽计算机网络面试题.assets/be5603b1bb6ff46b640909b5b8976827-171824950787216
new file mode 100644
index 0000000..d2bd1f5
Binary files /dev/null and b/面试题/21-精尽计算机网络面试题.assets/be5603b1bb6ff46b640909b5b8976827-171824950787216 differ
diff --git a/面试题/21-精尽计算机网络面试题.assets/c30ec0b3743d1f9751d3ba511f94578b-171824950787326 b/面试题/21-精尽计算机网络面试题.assets/c30ec0b3743d1f9751d3ba511f94578b-171824950787326
new file mode 100644
index 0000000..38dbabb
Binary files /dev/null and b/面试题/21-精尽计算机网络面试题.assets/c30ec0b3743d1f9751d3ba511f94578b-171824950787326 differ
diff --git a/面试题/21-精尽计算机网络面试题.assets/d1fd249da13a52e27748fbfcbb06942c.jpeg b/面试题/21-精尽计算机网络面试题.assets/d1fd249da13a52e27748fbfcbb06942c.jpeg
new file mode 100644
index 0000000..016226b
Binary files /dev/null and b/面试题/21-精尽计算机网络面试题.assets/d1fd249da13a52e27748fbfcbb06942c.jpeg differ
diff --git a/面试题/21-精尽计算机网络面试题.assets/d5ac995144720c33399d8e518cb973a6.jpeg b/面试题/21-精尽计算机网络面试题.assets/d5ac995144720c33399d8e518cb973a6.jpeg
new file mode 100644
index 0000000..d747596
Binary files /dev/null and b/面试题/21-精尽计算机网络面试题.assets/d5ac995144720c33399d8e518cb973a6.jpeg differ
diff --git a/面试题/21-精尽计算机网络面试题.assets/d6f64b4331cc61156c5a098c18ce05a9.png b/面试题/21-精尽计算机网络面试题.assets/d6f64b4331cc61156c5a098c18ce05a9.png
new file mode 100644
index 0000000..0b4980a
Binary files /dev/null and b/面试题/21-精尽计算机网络面试题.assets/d6f64b4331cc61156c5a098c18ce05a9.png differ
diff --git a/面试题/21-精尽计算机网络面试题.assets/da1ada597b5feedcd7d6c17d1989629d.jpeg b/面试题/21-精尽计算机网络面试题.assets/da1ada597b5feedcd7d6c17d1989629d.jpeg
new file mode 100644
index 0000000..5149008
Binary files /dev/null and b/面试题/21-精尽计算机网络面试题.assets/da1ada597b5feedcd7d6c17d1989629d.jpeg differ
diff --git a/面试题/21-精尽计算机网络面试题.assets/e0f66085155bdcdaa170fab4507fa4f1.jpeg b/面试题/21-精尽计算机网络面试题.assets/e0f66085155bdcdaa170fab4507fa4f1.jpeg
new file mode 100644
index 0000000..2f6de08
Binary files /dev/null and b/面试题/21-精尽计算机网络面试题.assets/e0f66085155bdcdaa170fab4507fa4f1.jpeg differ
diff --git a/面试题/21-精尽计算机网络面试题.assets/e80a784ed96b6c688ef8e4e409f4cd18.jpeg b/面试题/21-精尽计算机网络面试题.assets/e80a784ed96b6c688ef8e4e409f4cd18.jpeg
new file mode 100644
index 0000000..4fb6a34
Binary files /dev/null and b/面试题/21-精尽计算机网络面试题.assets/e80a784ed96b6c688ef8e4e409f4cd18.jpeg differ
diff --git a/面试题/21-精尽计算机网络面试题.md b/面试题/21-精尽计算机网络面试题.md
new file mode 100644
index 0000000..ced1868
--- /dev/null
+++ b/面试题/21-精尽计算机网络面试题.md
@@ -0,0 +1,1316 @@
+# 精尽计算机网络面试题「最新更新时间：2024-02」
+
+以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。
+
+如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的【网络】面试题的大保健。
+
+而题目的难度，艿艿尽量按照从容易到困难的顺序，逐步下去。
+
+因为网络是个很大的话题，所以本文以常见的 TCP 和 HTTP 题目为主，例如：
+
+- TCP 三次握手、四次挥手是什么？
+- HTTP1.0、HTTP1.1、HTTP2 等的区别？
+- …
+
+**注意，经常问的问题，会在前面加【重要】标识**。
+
+# 网络体系结构
+
+强烈推荐阅读两篇文章：
+
+> 艿艿：可以后续回过头来看。
+
+- [《计算机网络体系结构综述（上）》](https://blog.csdn.net/justloveyou_/article/details/69611328)
+- [《计算机网络体系结构综述（下）》](https://blog.csdn.net/justloveyou_/article/details/69612153)
+
+简单一瞥：
+
+- **OSI 七层体系结构**具有概念清楚、理论完整的特点，是一个理论上的国际标准，但却不是事实上的国际标准。
+- 具有简单易用特点的 **TCP/IP 四层体系结构**则是事实上的标准。
+- 需要指出的是，**五层体系结构**虽然综合了 OSI 和 TCP/IP 的优点，但其只是为了学术学习研究而提出的，没有具体的实际意义。
+- 三者结构示意图如下所示：[![原理体系结构 VS OS VS TCP/IP](21-精尽计算机网络面试题.assets/d6f64b4331cc61156c5a098c18ce05a9.png)](http://static.iocoder.cn/d6f64b4331cc61156c5a098c18ce05a9)原理体系结构 VS OS VS TCP/IP
+
+## 简述 OSI 七层体系结构
+
+> 艿艿：比较复杂，至少要说出有哪些层。
+
+自上而下是：
+
+- 应用层（数据）：确定进程之间通信的性质以满足用户需要以及提供网络与用户应用
+- 表示层（数据）：主要解决用户信息的语法表示问题，如加密解密
+- 会话层（数据）：提供包括访问验证和会话管理在内的建立和维护应用之间通信的机制，如服务器验证用户登录便是由会话层完成的
+- 传输层（段）：实现网络不同主机上用户进程之间的数据通信，可靠
+  与不可靠的传输，传输层的错误检测，流量控制等
+- 网络层（包）：提供逻辑地址（IP）、选路，数据从源端到目的端的
+  传输
+- 数据链路层（帧）：将上层数据封装成帧，用MAC地址访问媒介，错误检测与修正
+- 物理层（比特流）：设备之间比特流的传输，物理接口，电气特性等
+
+详细可以看 [《计算机网络体系结构综述（下）》](https://blog.csdn.net/justloveyou_/article/details/69612153) 的 [「二. OSI 七层体系结构简述」](https://svip.iocoder.cn/Net/Interview/#) 小节。
+
+[OSI 七层体系结构](https://user-gold-cdn.xitu.io/2018/7/29/164e529309f0fa33?imageslim)
+
+## 简述 TCP/IP 四层体系结构
+
+> 艿艿：比较复杂，至少要说出有哪些层。
+
+自上而下是：
+
+> 实际上，如果我们把一些 RPC 框架的分层套到 TCP/IP 四层体系结构，也是可以的。跳到 [《精尽 Dubbo 面试题》](http://svip.iocoder.cn/Dubbo/Interview/) 的 [「Dubbo 框架的分层设计」](http://svip.iocoder.cn/Dubbo/Interview/#Dubbo-框架的分层设计) 问题瞅瞅噢。
+
+- 应用层
+
+  > HTTP、TELNET、FTP、SMTP
+
+- 传输层
+
+  > TCP、UDP
+
+- 网络层
+
+  > IP、ICMP
+
+- 数据接口
+
+  > PPP
+
+详细可以看 [《计算机网络体系结构综述（下）》](https://blog.csdn.net/justloveyou_/article/details/69612153) 的 [「三. TCP/IP 四层体系结构」](https://svip.iocoder.cn/Net/Interview/#) 小节。
+
+## 知道各个层使用的是哪个数据交换设备？
+
+> 这个问题，了解即可。
+
+- 网关：应用层、传输层。
+
+  > 网关在传输层上以实现网络互连，是最复杂的网络互连设备，仅用于两个高层协议不同的网络互连。
+  >
+  > 网关的结构也和路由器类似，不同的是互连层。网关既可以用于广域网互连，也可以用于局域网互连。
+
+- 【重点】路由器：网络层
+
+  > 路由选择、存储转发
+
+- 【重点】交换机：数据链路层、网络层
+
+  > 识别数据包中的 MAC 地址信息，根据 MAC 地址进行转发，并将这些 MAC 地址与对应的端口记录在自己内部的一个地址表中。
+
+- 网桥：数据链路层
+
+  > 将两个 LAN 连起来，根据 MAC 地址来转发帧。
+
+- 集线器（Hub）：物理层
+
+  > 纯硬件设备，主要用来连接计算机等网络终端。
+
+- 中继器：物理层
+
+  > 在比特级别对网络信号进行再生和重定时，从而使得它们能够在网络上传输更长的距离。
+
+🦅 **交换机是什么？**
+
+在计算机网络系统中，交换机是针对共享工作模式的弱点而推出的。交换机拥有一条高带宽的背部总线和内部交换矩阵。交换机的所有的端口都挂接在这条背部总线上，当控制电路收到数据包以后，处理端口会查找内存中的地址对照表以确定目的 MAC（网卡的硬件地址）的 NIC（网卡）挂接在哪个端口上，通过内部交换矩阵迅速将数据包传送到目的端口。**目的 MAC 若不存在，交换机才广播到所有的端口，接收端口回应后交换机会“学习”新的地址，并把它添加入内部地址表中**。
+
+交换机工作于 OSI 参考模型的第二层，即数据链路层。交换机内部的 CPU 会在每个端口成功连接时，通过 ARP 协议学习它的 MAC 地址，保存成一张 ARP 表。在今后的通讯中，发往该 MAC 地址的数据包将仅送往其对应的端口，而不是所有的端口。因此，交换机可用于划分数据链路层广播，即冲突域；但它不能划分网络层广播，即广播域。
+
+🦅 **路由器是什么？**
+
+路由器（Router），是一种计算机网络设备，提供了路由与转发两种重要机制，可以决定数据包从来源端到目的端所经过的路由路径（host 到 host 之间的传输路径），这个过程称为**路由**；将路由器输入端的数据包移送至适当的路由器输出端(在路由器内部进行)，这称为**转发**。所以，路由器的一个作用是连通不同的网络，另一个作用是选择信息传送的线路。
+
+路由工作在 OSI 模型的第三层 —— 即网络层，例如 IP 协议。当然，这也是路由器与交换器的**差别**，路由器是属于 OSI 第三层的产品，交换器是 OSI 第二层的产品(这里特指二层交换机)。
+
+🦅 **常见的路由选择协议，以及它们的区别？**
+
+常见的路由选择协议有：RIP 协议、OSPF 协议。
+
+- RIP 协议：底层是贝尔曼福特算法，它选择路由的度量标准（metric)是跳数，最大跳数是 15 跳。如果大于 15 跳，它就会丢弃数据包。
+- OSPF 协议：底层是迪杰斯特拉算法，是链路状态路由选择协议，它选择路由的度量标准是带宽，延迟。
+
+🦅 **什么是网关设备？**
+
+这个我们就不在本文中多写，感兴趣的胖友，可以看看 [《维基百科 —— 网关》](https://zh.wikipedia.org/wiki/网关) 文章。
+
+🦅 **详细说明 Keepalived 的故障切换工作原理？**
+
+这种故障切换，是通过 **VRRP** 协议来实现的。
+
+- 主节点会按一定的时间间隔发送心跳信息的广播包，告诉备节点自己的存活状态信息。
+- 当主节点发生故障时，备节点在一段时间内就收到广播包，从而判断主节点出现故障，因此会调用自身的接管程序来接管主节点的 IP 资源及服务。
+- 当主节点恢复时，备节点会主动释放资源，恢复到接管前的状态，从而来实现主备故障切换
+
+例如，MySQL 基于 Keepalived 实现高可用。详细的，可以看看 [《Keepalived + MySQL实现高可用》](https://www.cnblogs.com/gomysql/p/3856484.html) 。
+
+# IP
+
+## IP 地址的分类？
+
+IP 地址是指互联网协议地址，是 IP 协议提供的一种统一的地址格式，它为互联网上的每一个网络和每一台主机分配一个逻辑地址，以此来屏蔽物理地址的差异。
+
+IP 地址编址方案将IP地址空间划分为 A、B、C、D、E 五类，其中 A、B、C 是基本类，D、E 类作为多播和保留使用，为特殊地址。
+
+每个 IP 地址包括两个标识码（ID），即网络 ID 和主机 ID 。同一个物理网络上的所有主机都使用同一个网络 ID ，网络上的一个主机（包括网络上工作站，服务器和路由器等）有一个主机 ID 与其对应。A~E 类地址的特点如下：
+
+[![五类互联网地址](21-精尽计算机网络面试题.assets/0e2ff871cdb6c2b58a6a2fc3bec51933.jpeg)](http://static.iocoder.cn/0e2ff871cdb6c2b58a6a2fc3bec51933)五类互联网地址
+
+- A 类地址：以 0 开头，第一个字节范围：0~127 。
+- B 类地址：以 10 开头，第一个字节范围：128~191 。
+- C 类地址：以 110 开头，第一个字节范围：192~223。
+- D 类地址：以 1110 开头，第一个字节范围：224~239 。
+- E 类地址：以 1111 开头，保留地址。
+
+详细的，可以看看 [《IP 地址分类（A类 B类 C类 D类 E类）》](https://blog.csdn.net/kzadmxz/article/details/73658168) 文章。
+
+🦅 **IP 地址与物理地址的区别？**
+
+- 物理地址(MAC 地址)，是数据链路层和物理层使用的地址。
+- IP 地址是网络层和以上各层使用的地址，是一种逻辑地址。
+- 其中 ARP 协议用于 IP 地址与物理地址的对应。
+
+详细的，可以看看 [《即生瑜，何生亮 —— MAC 地址与 IP 地址》](http://blog.sciencenet.cn/blog-411071-1037673.html) 文章。
+
+## 网络层的 ARP 协议工作原理？
+
+网络层的 ARP 协议完成了 IP 地址与物理地址的映射。
+
+- 首先，每台主机都会在自己的 ARP 缓冲区中建立一个 ARP 列表，以表示 IP 地址和 MAC 地址的对应关系。
+- 当源主机需要将一个数据包要发送到目的主机时，会首先检查自己 ARP 列表中是否存在该 IP 地址对应的 MAC 地址：
+  - 如果有，就直接将数据包发送到这个 MAC 地址。
+  - 如果没有，就向本地网段发起一个ARP请求的广播包，查询此目的主机对应的 MAC 地址。此 ARP 请求数据包里包括源主机的 IP 地址、硬件地址、以及目的主机的 IP 地址。网络中所有的主机收到这个 ARP 请求后，会检查数据包中的目的 IP 是否和自己的 I P地址一致。
+    - 如果不相同，就忽略此数据包。
+    - 如果相同，该主机首先将发送端的 MAC 地址和 IP 地址添加到自己的 ARP 列表中(如果 ARP 表中已经存在该 IP 的信息，则将其覆盖)，然后给源主机发送一个 ARP 响应数据包，告诉对方自己是它需要查找的 MAC 地址。
+      - 源主机收到这个 ARP 响应数据包后，将得到的目的主机的 IP 地址和 MAC 地址添加到自己的 ARP 列表中，并利用此信息开始数据的传输。
+      - 如果源主机一直没有收到 ARP 响应数据包，表示 ARP 查询失败。
+
+> 注意，在 OSI 模型中 ARP 协议属于链路层；而在 TCP/IP 模型中，ARP 协议属于网络层。
+
+## 如何划分子网、超网？
+
+🦅 **如何划分子网？**
+
+> 艿艿：可选了解。
+
+划分子网（变长子网掩码 VLSM）：划分子网的方法是从网络的主机号借用若干位作为子网号 subnet-id ，与此同时主机号也减少相应位数（总位数 32 位不变）。
+
+由此两级 IP 地址可变为三级 IP 地址：`IP地址 ::= {<网络号>,<子网号>,<主机号>}` ，划分子网只是把 IP 地址的主机号这部分进行再划分，并不改变 IP 地址原来的网络号。
+
+🦅 **如何划分超网？**
+
+> 艿艿：可选了解。
+
+构造超网（无分类编址 CIDR）：CIDR 消除了传统的 A 类、B 类和 C 类地址以及划分子网的概念，把 32 位的 IP 地址划分为两个部分。
+
+例如：`128.14.35.7/20` 是某个 CIDR 地址块中的一个地址，其前 20 位是网络前缀（用下划线表示的部分），后面的 12 位为主机号
+
+🦅 **子网掩码的作用？**
+
+子网掩码只有一个作用，就是将某个 IP 地址划分成**网络地址**和**主机地址**两部分。
+
+用于子网掩码的位数，决定于可能的子网数目和每个子网的主机数目。
+
+## 什么是单播、组播(多播)、广播、任播？
+
+> 艿艿：这个问题，一般面试应该不问，主要是为了大家扩充下知识面吧。
+
+- **单播**(unicast): 是指封包在计算机网络的传输中，目的地址为单一目标的一种传输方式。它是现今网络应用最为广泛，通常所使用的网络协议或服务大多采用单播传输，例如一切基于TCP的协议。
+- **组播**(multicast): 也叫多播， 多点广播或群播。 指把信息同时传递给一组目的地址。它使用策略是最高效的，因为消息在每条网络链路上只需传递一次，而且只有在链路分叉的时候，消息才会被复制。
+- **广播**(broadcast):是指封包在计算机网络中传输时，目的地址为网络中所有设备的一种传输方式。实际上，这里所说的“所有设备”也是限定在一个范围之中，称为“广播域”。
+- **任播**(anycast):是一种网络寻址和路由的策略，使得资料可以根据路由拓朴来决定送到“最近”或“最好”的目的地。
+
+感兴趣的胖友，可以详细看 [《单播，组播(多播)，广播以及任播》](https://colobu.com/2014/10/21/udp-and-unicast-multicast-broadcast-anycast/) 文章。
+
+## 区别 IPv4 和 IPv6 ？
+
+- 我们大多数人使用的是第二代互联网 IPv4 技术，它的最大问题是网络地址资源有限，从理论上讲能编址 1600 万个网络、链接 40 亿台主机。而根据相关数据，全球 IPv4 的 IP 地址已经即将用完。
+- 而 IPv6 是作为 IETF 设计的用于替代现行版本 IP 协议(IPv4)的下一代 IP 协议，其 IPV6 地址长度为 12 8位，地址空间增大了 2^98 次方倍，几乎可以说是用之不竭的。所以随着 IPv4 不足，支持 IPv6 的网络势必会增长。
+
+# ICMP
+
+> 艿艿：这个小节，可以快速看。因为，面试不一定问的很多。
+
+## ICMP 协议的主要功能？
+
+用于在 IP 主机、路由器之间传递控制消息。
+
+如下图所示：[![ICMP 协议](21-精尽计算机网络面试题.assets/d1fd249da13a52e27748fbfcbb06942c.jpeg)](http://static.iocoder.cn/d1fd249da13a52e27748fbfcbb06942c)ICMP 协议
+
+## 简述一下 ping 的原理？
+
+一般在网络不通的时候，大家会用 ping 测一下网络是否通畅。
+
+ping 是基于 ICMP 协议工作的。ICMP 全称 Internet Control Message Protocol ，就是互联网**控制**报文协议。这里的关键词是“控制”，那具体是怎么控制的呢？ 网络包在异常负责的网络环境中传输时，会遇到各种问题，当遇到问题时，要传出消息，报告情况，这样才能调整传输策略。
+
+ICMP 报文是封装在 IP 包里面的。因为传输指令的时候，肯定需要源地址和目标地址。如下图：[![ICMP 报文](21-精尽计算机网络面试题.assets/bd1dd61fc5562ec031e0c6aa712c926b.jpeg)](http://static.iocoder.cn/bd1dd61fc5562ec031e0c6aa712c926b)ICMP 报文
+
+## 什么是 Traceroute ？
+
+> Traceroute 是构建在 ICMP 协议之上的应用。
+
+Traceroute ，是用来侦测主机到目的主机之间所经路由情况的重要工具，也是最便利的工具。
+
+> 前面说到，尽管 ping 工具也可以进行侦测，但是，因为 IP 头的限制，ping 不能完全的记录下所经过的路由器。所以Traceroute 正好就填补了这个缺憾。
+
+Traceroute 的**原理**是非常非常的有意思。
+
+> - 它受到目的主机的 IP 后，首先给目的主机发送一个 TTL=1（还记得 TTL 是什么吗？）的 UDP(后面就知道 UDP是什么了)数据包，而经过的第一个路由器收到这个数据包以后，就自动把 TTL 减1，而 TTL 变为 0 以后，路由器就把这个包给抛弃了，并同时产生 一个主机不可达的 ICMP 数据报给主机。
+> - 主机收到这个数据报以后再发一个 TTL=2 的 UDP 数据报给目的主机，然后刺激第二个路由器给主机发 ICMP 数据 报。如此往复直到到达目的主机。
+>
+> 这样，traceroute 就拿到了所有的路由器 IP 。从而避开了 IP 头只能记录有限路由 IP 的问题。
+
+有人要问，我怎么知道 UDP 到没到达目的主机呢？
+
+> 这就涉及一个技巧的问题，TCP 和 UDP 协议有一个端口号定义，而普通的网络程序只监控少数的几个号码较小的端口，比如说 80、23 等等。而 traceroute 发送的是端口号 >30000(真变态) 的 UDP 包，所以到达目的主机的时候，目的主机只能发送一个端口不可达的 ICMP 数据报给主机。主机接到这个报告以后就知道，目标主机到了。
+
+😈 很多情况下，在我们 ping 不通目标地址时，会尝试使用 traceroute 命令，看看是否在中间哪个 IP 无法访问。
+
+# TCP
+
+## TCP 是什么？
+
+TCP(Transmission Control Protocol)，传输控制协议，是一种面向连接的、可靠的、基于字节流的传输层通信协议。主要特点如下：
+
+- TCP 是面向连接的。
+
+  > 就好像打电话一样，通话前需要先拨号建立连接，通话结束后要挂机释放连接
+
+- 每一条 TCP 连接只能有两个端点，每一条TCP连接只能是点对点的（一对一）。
+
+- TCP 提供可靠交付的服务。通过TCP连接传送的数据，无差错、不丢失、不重复、并且按序到达。
+
+- TCP 提供全双工通信。TCP 允许通信双方的应用进程在任何时候都能发送数据。TCP 连接的两端都设有发送缓存和接收缓存，用来临时存放双方通信的数据。
+
+- 面向字节流。
+
+  > TCP 中的“流”（Stream），指的是流入进程或从进程流出的字节序列。
+  >
+  > “面向字节流”的含义是：虽然应用程序和 TCP 的交互是一次一个数据块（大小不等），但 TCP 把应用程序交下来的数据仅仅看成是一连串的无结构的字节流。
+
+## TCP 对应的应用层协议？
+
+- FTP ：定义了文件传输协议，使用 21 端口。常说某某计算机开了 FTP 服务便是启动了文件传输服务。下载文件，上传主页，都要用到 FTP 服务。
+- Telnet ：它是一种用于远程登陆的端口，用户可以以自己的身份远程连接到计算机上，通过这种端口可以提供一种基于 DOS 模式下的通信服务。如以前的 BBS 是纯字符界面的，支持 BBS 的服务器将 23 端口打开，对外提供服务。
+- 邮箱
+  - SMTP ：定义了简单邮件传送协议，现在很多邮件服务器都用的是这个协议，用于发送邮件。如常见的免费邮件服务中用的就是这个邮件服务端口，所以在电子邮件设置-中常看到有这么 SMTP 端口设置这个栏，服务器开放的是 25 号端口。
+  - POP3 ：它是和 SMTP 对应，POP3 用于接收邮件。通常情况下，POP3 协议所用的是 110 端口。也是说，只要你有相应的使用 POP3 协议的程序（例如 Foxmail 或 Outlook），就可以不以 Web 方式登陆进邮箱界面，直接用邮件程序就可以收到邮件（如是 163 邮箱就没有必要先进入网易网站，再进入自己的邮箱来收信）。
+- HTTP ：从 Web 服务器传输超文本到本地浏览器的传送协议。
+
+## TCP 头部是怎么样的？
+
+- [《通俗大白话来理解 TCP 协议的三次握手和四次分手》](https://github.com/jawil/blog/issues/14) 的 [「TCP头部」](https://svip.iocoder.cn/Net/Interview/#) 小节。
+- [《TCP 协议的学习 （二）TCP 头部信息》](https://blog.csdn.net/qq_34501940/article/details/51073691)
+
+## 【重要】什么是 TCP 三次握手？
+
+三次握手，简单来说，就是：
+
+[TCP 三次握手的漫画](https://camo.githubusercontent.com/91cee189ca7c400e3be6aa35cdda000ecbb58930/687474703a2f2f6f6f327239726e7a702e626b742e636c6f7564646e2e636f6d2f3630363537332d32303137303331373139313333363933322d313635343735313132332e706e67)
+
+- 发送方：我要和你建立链接？
+- 接收方：你真的要和我建立链接么？
+- 发送方：我真的要和你建立链接，成功。
+
+详细来说，步骤如下：
+
+[![TCP 三次握手的干货](21-精尽计算机网络面试题.assets/04edb57536fc9bbd3ea096cafa5d3630.png)](http://static.iocoder.cn/04edb57536fc9bbd3ea096cafa5d3630)TCP 三次握手的干货
+
+- 第一次握手：Client 将标志位 `SYN=1` ，随机产生一个值 `seq=J` ，并将该数据包发送给 Server 。此时，Client 进入SYN_SENT 状态，等待 Server 确认。
+
+- 第二次握手：Server 收到数据包后由标志位 `SYN=1` 知道Client请求建立连接，Server 将标志位 `SYN` 和 `ACK` 都置为 1 ，`ack=J+1`，随机产生一个值 `seq=K` ，并将该数据包发送给 Client 以确认连接请求，Server 进入 `SYN_RCVD` 状态。此时，Server 进入 SYC_RCVD 状态。
+
+- 第三次握手：Client 收到确认后，检查
+
+   
+
+  ```
+  ack
+  ```
+
+   
+
+  是否为
+
+   
+
+  ```
+  J+1
+  ```
+
+   
+
+  ，
+
+  ```
+  ACK
+  ```
+
+   
+
+  是否为 1 。
+
+  - 如果正确，则将标志位 `ACK` 置为 1 ，`ack=K+1` ，并将该数据包发送给 Server 。此时，Client 进入 ESTABLISHED 状态。
+  - Server 检查 `ack` 是否为 `K+1` ，`ACK` 是否为 1 ，如果正确则连接建立成功。此时 Server 进入 ESTABLISHED 状态，完成三次握手，随后 Client 与 Server 之间可以开始传输数据了。
+
+- 仔细看来，Client 会发起两次数据包，分别是 `SYNC` 和 `ACK` ；Server 会发起一次数据包，包含 `SYNC` 和 `ACK` 。也就是说，三次握手的过程中，Client 和 Server 互相做了一次 `SYNC` 和 `ACK` 。
+
+🦅 **为什么 TCP 连接需要三次握手，两次不可以么，为什么？**
+
+为了防止**已失效的连接请求**报文突然又传送到了服务端，因而产生错误。
+
+> 客户端发出的连接请求报文并未丢失，而是在某个网络节点长时间滞留了，以致延误到链接释放以后的某个时间才到达 Server 。
+>
+> - 若不采用“三次握手”，那么只要 Server 发出确认数据包，新的连接就建立了。由于 Client 此时并未发出建立连接的请求，所以其不会理睬 Server 的确认，也不与 Server 通信；而这时 Server 一直在等待 Client 的请求，这样 Server 就白白浪费了一定的资源。
+> - 若采用“三次握手”，在这种情况下，由于 Server 端没有收到来自客户端的确认，则就会知道 Client 并没有要求建立请求，就不会建立连接。
+
+在 [《通俗大白话来理解 TCP 协议的三次握手和四次挥手》](https://github.com/jawil/blog/issues/14) 中，搜 [“为什么要三次握手”](https://svip.iocoder.cn/Net/Interview/#) 关键字，也有非常好的解答。
+
+- **这就很明白了，防止了服务器端的一直等待而浪费资源**。
+
+**🦅 客户端不断进行请求链接会怎样？**
+
+服务器端准备为每个请求创建一个链接，并向其发送确认报文，然后等待客户端进行确认后创建。如果此时客户端一直不确认，会造成 SYN 攻击，即：
+
+> SYN 攻击，英文为 SYN Flood ，是一种典型的 DoS/DDoS 攻击。
+
+- 1、客户端向服务端发送请求连接数据包。
+
+- 2、服务端向客户端发送确认数据包。
+
+- 3、客户端不向服务端发送确认数据包，服务器一直等待来自客户端的确认。
+
+  > 这是这一步！！！
+
+🚀 如何检测 SYN 攻击？检测 SYN 攻击非常的方便，当你在服务器上看到大量的半连接状态时，特别是源 IP 地址是随机的，基本上可以断定这是一次 SYN 攻击。在 Linux/Unix 上可以使用系统自带的 netstat 命令来检测 SYN 攻击。
+
+🚀 怎么解决 SYN 攻击呢？答案是**只能预防**，没有彻底根治的办法，除非不使用 TCP 。方式如下：
+
+- 1、限制同时打开 SYN 半链接的数目
+
+  > 艿艿：是不是很像我们常用的“限流”。
+
+- 2、缩短 SYN 半链接的 Timeout 时间
+
+  > 艿艿：是不是很像我们常用的“超时”。
+
+- 3、关闭不必要的服务。
+
+  > 艿艿：酱紫，这个服务就不会被 SYN 攻击连接。
+
+- 4、增加最大半连接数。
+
+- 5、过滤网关防护。
+
+- 6、
+
+  SYN cookie
+
+   
+
+  技术。
+
+  > 艿艿：有一点点重新“设计” TCP 的味道，或者可以理解成对 TCP 的增强。
+
+## 【重要】什么是 TCP 四次挥手？
+
+四次挥手，简单来说，就是：
+
+- 发送方：我要和你断开连接！
+- 接收方：好的，断吧。
+- 接收方：我也要和你断开连接！
+- 发送方：好的，断吧。
+
+详细来说，步骤如下：
+
+[![TCP 四次挥手的干货](21-精尽计算机网络面试题.assets/2cf7b8d1689ae6e920ef1b2c3eafb8b2.png)](http://static.iocoder.cn/2cf7b8d1689ae6e920ef1b2c3eafb8b2)TCP 四次挥手的干货
+
+> 如下使用 Client 和 Server 的方式，仅仅是为了方便，也是可以从 Server 向 Client 发起。
+
+- 第一次挥手：Client 发送一个 `FIN=M` ，用来关闭 Client 到 Server 的数据传送。此时，Client 进入 FIN_WAIT_1 状态。
+- 第二次挥手，Server 收到 `FIN` 后，发送一个 `ACK` 给 Client ，确认序号为 `M+1`（与 `SYN` 相同，一个 `FIN` 占用一个序号）。此时，Server 进入 CLOSE_WAIT 状态。注意，TCP 链接处于**半关闭**状态，即客户端已经没有要发送的数据了，但服务端若发送数据，则客户端仍要接收。
+- 第三次挥手，Server 发送一个 `FIN=N` ，用来关闭 Server 到 Client 的数据传送。此时 Server 进入 LAST_ACK 状态。
+- 第四次挥手，Client 收到 `FIN` 后，此时 Client 进入 TIME_WAIT 状态。接着，Client 发送一个 `ACK` 给 Server ，确认序号为 `N+1` 。Server 接收到后，此时 Server 进入 CLOSED 状态，完成四次挥手。
+
+🦅 **为什么要四次挥手？**
+
+TCP 协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。**TCP 是全双工模式**，这就意味着：
+
+- 当主机 1 发出 `FIN` 报文段时，只是表示主机 1 已经没有数据要发送了，主机 1 告诉主机 2 ，它的数据已经全部发送完毕了；**但是，这个时候主机 1 还是可以接受来自主机 2 的数据；**当主机 2 返回 `ACK` 报文段时，表示它已经知道主机 1 没有数据发送了，但是主机 2 还是可以发送数据到主机 1 的。
+
+  > 艿艿：因为主机 2 此时可能还有数据想要发送给主机 1 ，所以挥手不能像握手只有三次，而是多了那么“一次”！
+
+- 当主机 2 也发送了 `FIN` 报文段时，这个时候就表示主机 2 也没有数据要发送了，就会告诉主机 1 ，我也没有数据要发送了，之后彼此就会愉快的中断这次 TCP 连接。
+
+  > 艿艿：我们把四次挥手，理解成一次和平的挥手~
+
+如果要正确的理解四次的原理，就需要了解四次挥手过程中的状态变化。
+
+> 主动方=发送方；被动方=接收方。
+>
+> 状态前面的（主动方）（被动方），表示该状态属于谁。
+
+- （主动方）FIN_WAIT_1 ：这个状态要好好解释一下，其实 FIN_WAIT_1 和 FIN_WAIT_2 状态的真正含义都是表示等待对方的
+
+   
+
+  ```
+  FIN
+  ```
+
+   
+
+  报文。而这两种状态的区别是：
+
+  - FIN_WAIT_1 状态实际上是当 Socket 在 ESTABLISHED 状态时，它想主动关闭连接，向对方发送了 `FIN` 报文，此时该 Socket 即进入到 FIN_WAIT_1 状态。
+  - 而当对方回应 `ACK` 报文后，则进入到 FIN_WAIT_2 状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应`ACK` 报文。所以， FIN_WAIT_1 状态一般是比较难见到的，而 FIN_WAIT_2 状态还有时常常可以用 netstat 看到。
+
+- （主动方）FIN_WAIT_2 ：上面已经详细解释了这种状态，实际上 FIN_WAIT_2 状态下的 Socket，表示半连接，也即有一方要求 close 连接，但另外还告诉对方，我暂时还有点数据需要传送给你(`ACK` 信息)，稍后再关闭连接。
+
+- （被动方）CLOSE_WAIT ：这种状态的含义其实是表示在等待关闭。怎么理解呢？当对方 close 一个 Socket 后发送 `FIN` 报文给自己，你系统毫无疑问地会回应一个 `ACK` 报文给对方，此时则进入到 CLOSE_WAIT 状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以 close 这个 Socket ，发送 `FIN` 报文给对方，也即关闭连接。所以你在 CLOSE_WAIT 状态下，需要完成的事情是等待你去关闭连接。
+
+- （被动方）LAST_ACK ：这个状态还是比较容易好理解的，它是被动关闭一方在发送 `FIN` 报文后，最后等待对方的 `ACK` 报文。当收到 `ACK` 报文后，也即可以进入到 CLOSED 可用状态了。
+
+- （主动方）TIME_WAIT ：表示收到了对方的 `FIN` 报文，并发送出了 `ACK` 报文，就等 [2MSL](https://blog.csdn.net/xiaofei0859/article/details/6044694) 后即可回到 CLOSED 可用状态了。如果 FIN_WAIT_1 状态下，收到了对方同时带 `FIN` 标志和 `ACK` 标志的报文时，可以直接进入到 TIME_WAIT 状态，而无须经过 FIN_WAIT_2 状态。
+
+  > **为何一定要等 2MSL ？**
+  >
+  > 如果不等，释放的端口可能会重连刚断开的服务器端口，这样依然存活在网络里的老的 TCP 报文可能与新 TCP 连接报文冲突，造成数据冲突，为避免此种情况，需要耐心等待网络老的 TCP 连接的活跃报文全部死翘翘，2MSL 时间可以满足这个需求（尽管非常保守）！
+  >
+  > 更多，可以看看知乎 [《为什么 TCP 4 次挥手时等待为 2MSL？》](https://www.zhihu.com/question/67013338) 的讨论。
+
+- CLOSED ：表示连接中断。
+
+另外，关于 TIME_WAIT 和 CLOSE_WAIT 状态的区别，胖友可以在细看下 [《TIME_WAIT 和 CLOSE_WAIT 状态区别》](https://blog.csdn.net/kobejayandy/article/details/17655739) 。
+
+## 【重要】TCP 数据如何传输？
+
+建立连接后，两台主机就可以相互传输数据了。如下图所示：[![TCP 套接字的数据交换过程](21-精尽计算机网络面试题.assets/6ed78395a32a0fbf56afed309dc1eb71.jpeg)](http://static.iocoder.cn/6ed78395a32a0fbf56afed309dc1eb71)TCP 套接字的数据交换过程
+
+- 上图给出了主机 A 分 2 次（分 2 个数据包）向主机 B 传递 200 字节的过程。
+
+- 首先，主机 A 通过 1 个数据包发送 100 个字节的数据，数据包的
+
+   
+
+  ```
+  Seq
+  ```
+
+   
+
+  号设置为 1200 。主机 B 为了确认这一点，向主机 A 发送
+
+   
+
+  ```
+  ACK
+  ```
+
+   
+
+  包，并将
+
+   
+
+  ```
+  Ack
+  ```
+
+   
+
+  号设置为 1301 。
+
+  - 为了保证数据准确到达，目标机器在收到数据包（包括 `SYN` 包、`FIN` 包、普通数据包等）包后必须立即回传 `ACK` 包，这样发送方才能确认数据传输成功。
+
+  - 此时
+
+     
+
+    ```
+    Ack
+    ```
+
+     
+
+    号为 1301 而不是 1201，原因在于
+
+     
+
+    ```
+    Ack
+    ```
+
+     
+
+    号的增量为传输的数据字节数。假设每次
+
+     
+
+    ```
+    Ack
+    ```
+
+     
+
+    号不加传输的字节数，这样虽然可以确认数据包的传输，但无法明确 100 字节全部正确传递还是丢失了一部分，比如只传递了 80 字节。因此按如下的公式确认
+
+     
+
+    ```
+    Ack
+    ```
+
+     
+
+    号：
+
+    ```
+    Ack
+    ```
+
+     
+
+    号 =
+
+     
+
+    ```
+    Seq
+    ```
+
+     
+
+    号 + 传递的字节数 + 1 。
+
+    - 与三次握手协议相同，最后加 1 是为了告诉对方要传递的 `Seq` 号。
+
+OK，让我们重新来看下 TCP 的整个过程。如下图所示：[TCP 过程](https://camo.githubusercontent.com/36cf7d4e1598683fe72a5e1c3e837b16840f4085/687474703a2f2f6f6f327239726e7a702e626b742e636c6f7564646e2e636f6d2f6a656c6c797468696e6b544350342e6a7067)
+
+🦅 **TCP 数据传输丢失怎么办？**
+
+> 艿艿：这个问题，也可以改成提问，什么是 TCP 重传。
+
+因为各种原因，TCP 数据包可能存在丢失的情况，TCP 会进行数据重传。如下图所示：
+
+[![TCP套接字数据传输过程中发生错误](http://static.iocoder.cn/a36ed3dad53b9b4439bc8156bc63a2c0)](http://static.iocoder.cn/a36ed3dad53b9b4439bc8156bc63a2c0)TCP套接字数据传输过程中发生错误
+
+- 上图表示通过 `Seq` 1301 数据包向主机 B 传递 100 字节的数据，但中间发生了错误，主机 B 未收到。经过一段时间后，主机 A 仍未收到对于 `Seq` 1301 的 `ACK` 确认，因此尝试重传数据。为了完成数据包的重传，TCP 套接字每次发送数据包时都会**启动定时器**，如果在一定时间内没有收到目标机器传回的 `ACK` 包，那么定时器超时，数据包会重传。上图演示的是数据包丢失的情况，也会有 `ACK` 包丢失的情况，一样会重传。
+
+- 重传超时时间(RTO，Retransmission Time Out)
+
+  > 这个值太大了会导致不必要的等待，太小会导致不必要的重传，理论上最好是网络 RTT 时间，但又受制于网络距离与瞬态时延变化，所以实际上使用自适应的动态算法（例如 Jacobson 算法和 Karn 算法等）来确定超时时间。
+  >
+  > 往返时间（RTT，Round-Trip Time）表示从发送端发送数据开始，到发送端收到来自接收端的 `ACK` 确认包（接收端收到数据后便立即确认），总共经历的时延。
+
+- 重传次数
+
+  > TCP 数据包重传次数，根据系统设置的不同而有所区别。有些系统，一个数据包只会被重传 3 次，如果重传 3 次后还未收到该数据包的 `ACK` 确认，就不再尝试重传。但有些要求很高的业务系统，会不断地重传丢失的数据包，以尽最大可能保证业务数据的正常交互。
+  >
+  > 最后需要说明的是，发送端只有在收到对方的 `ACK` 确认包后，才会清空输出缓冲区中的数据。
+
+**ps：TCP 数据传输的过程，和 MQ Broker 投递消息给 Consumer 是一样的，只有在 Consumer Ack 确认消息已经消费，该消息才不会再被投递给 Consumer 。**
+
+另外，也推荐阅读 [《网络基本功（九）：细说TCP重传》](https://wizardforcel.gitbooks.io/network-basic/content/8.html) 。
+
+## 【重要】什么是 TCP 滑动窗口？
+
+在看 TCP 滑动窗口的概念之前，我们先来看看它出现的**背景**？
+
+> 将 TCP 与 UDP 这样的简单传输协议区分开来的是，它传输数据的质量。TCP 对于发送数据进行跟踪，这种数据管理需要协议有以下两大关键功能：
+>
+> - 可靠性：保证数据确实到达目的地。如果未到达，能够发现并重传。
+> - 数据流控：管理数据的发送速率，以使接收设备不致于过载。
+>
+> 要完成这些任务，整个协议操作是围绕**滑动窗口** + **确认机制**来进行的。因此，理解了滑动窗口，也就是理解了 TCP 。
+
+那么，到底什么是 TCP 滑动窗口呢？
+
+> 滑动窗口协议，是传输层进行流控的一种措施，接收方通过通告发送方自己的窗口大小，从而控制发送方的发送速度，从而达到防止发送方发送速度过快而导致自己被淹没的目的。
+>
+> TCP 的滑动窗口解决了端到端的流量控制问题，允许接受方对传输进行限制，直到它拥有足够的缓冲空间来容纳更多的数据。
+
+可能这么描述之后，胖友会有点懵逼，那么建议看下面三篇文章，耐心~
+
+- [《TCP 滑动窗口控制流量的原理》](https://www.cnblogs.com/luoquan/p/4886345.html)
+
+  > 比较易懂的一篇文章。
+
+- [《网络基本功（八）：细说 TCP 滑动窗口》](https://wizardforcel.gitbooks.io/network-basic/content/7.html)
+
+  > 更为详细的一篇文章。
+
+- [《TCP 协议的滑动窗口具体是怎样控制流量的？》](https://www.zhihu.com/question/32255109)
+
+  > 知乎上的讨论，重点看「wuxinliulei」和「安静的木小昊」的回答。特别是后者的，回答很生动形象。
+
+## TCP 协议如何来保证传输的可靠性？
+
+TCP 提供一种面向连接的、可靠的字节流服务。其中，面向连接意味着两个使用 TCP 的应用（通常是一个客户和一个服务器）在彼此交换数据之前必须先建立一个 TCP 连接。
+
+- 在一个 TCP 连接中，仅有两方进行彼此通信。
+- 而字节流服务意味着两个应用程序通过 TCP 链接交换 8bit 字节构成的字节流，TCP 不在字节流中插入记录标识符。
+
+对于可靠性，TCP 通过以下方式进行保证：
+
+- 数据包校验：目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时 TCP 发送数据端超时后会重发数据。
+- 对失序数据包重排序：既然 TCP 报文段作为 IP 数据报来传输，而 IP 数据报的到达可能会失序，因此 TC P报文段的到达也可能会失序。TCP 将对失序数据进行重新排序，然后才交给应用层。
+- 丢弃重复数据：对于重复数据，能够丢弃重复数据。
+- 应答机制：当 TCP 收到发自 TCP 连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒。
+- 超时重发：当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。
+- 流量控制：TCP 连接的每一方都有固定大小的缓冲空间。TCP 的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP 使用的流量控制协议是可变大小的**滑动窗口协议**。
+
+## 什么是 TCP 拥堵？
+
+计算机网络中的带宽、交换结点中的缓存及处理机等都是网络的资源。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就会变坏，这种情况就叫做**拥塞**。
+
+🦅 **怎么解决 TCP 拥堵？**
+
+通过拥塞控制来解决。拥堵控制，就是防止过多的数据注入网络中，这样可以使网络中的路由器或链路不致过载。注意，拥塞控制和流量控制不同，前者是一个**全局性**的过程，而后者指**点对点**通信量的控制。
+
+拥塞控制的方法主要有以下四种：
+
+- 1、慢开始。
+- 2、拥塞避免。
+- 3、快重传。
+- 4、快恢复。
+
+**1）慢开始**
+
+不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小。
+
+**2）拥塞避免**
+
+拥塞避免算法，让拥塞窗口缓慢增长，即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1 ，而不是加倍，这样拥塞窗口按线性规律缓慢增长。
+
+[![慢开始和拥塞避免算法的实现举例](http://static.iocoder.cn/3ed1936c7ee8639606bc8b3dccc2d5bc)](http://static.iocoder.cn/3ed1936c7ee8639606bc8b3dccc2d5bc)慢开始和拥塞避免算法的实现举例
+
+**3）快重传**
+
+快重传，要求接收方在收到一个**失序的报文段**后就立即发出**重复确认**（为的是使发送方及早知道有报文段没有到达对方），而不要等到自己发送数据时捎带确认。
+
+快重传算法规定，发送方只要一连收到三个重复确认，就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。
+
+[![快重传的示意图](http://static.iocoder.cn/96da7b757bb0dc2f2eaf86ac8ad20858)](http://static.iocoder.cn/96da7b757bb0dc2f2eaf86ac8ad20858)快重传的示意图
+
+**4）快恢复**
+
+快重传配合使用的还有快恢复算法，当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把 ssthresh 门限减半。
+
+- 但是接下去并不执行慢开始算法：因为如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。
+- 所以此时不执行慢开始算法，而是将 cwnd 设置为 ssthresh 的大小，然后执行拥塞避免算法。
+
+[![从连续收到三个重复的确认转入拥堵避免](http://static.iocoder.cn/d5ac995144720c33399d8e518cb973a6)](http://static.iocoder.cn/d5ac995144720c33399d8e518cb973a6)从连续收到三个重复的确认转入拥堵避免
+
+# UDP
+
+## UDP 是什么？
+
+UDP（User Data Protocol，用户数据报协议），是与 TCP 相对应的协议。它是面向非连接的协议，它不与对方建立连接，而是直接就把数据包发送过去。
+
+主要特点如下：
+
+- UDP 是无连接的。
+
+- UDP 使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的链接状态（这里面有许多参数）。
+
+- UDP 是面向报文的。
+
+- UDP 没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低。
+
+  > 对实时应用很有用，如 直播，实时视频会议等
+
+- UDP 支持一对一、一对多、多对一和多对多的交互通信。
+
+- UDP 的首部开销小，只有 8 个字节，比 TCP 的 20 个字节的首部要短。
+
+## UDP 对应的应用层协议？
+
+- DNS ：用于域名解析服务，将域名地址转换为 IP 地址。DNS 用的是 53 号端口。
+- SNMP ：简单网络管理协议，使用 161 号端口，是用来管理网络设备的。由于网络设备很多，无连接的服务就体现出其优势。
+- TFTP(Trivial File Transfer Protocol)：简单文件传输协议，该协议在熟知端口 69 上使用 UDP 服务。
+
+## 【重要】TCP 与 UDP 的区别
+
+> 这个问题，上面在介绍 TCP 和 UDP 都提到了，就是做了整合哈。
+
+TCP(Transmission Control Protocol)和 UDP(User Datagram Protocol) 协议属于传输层协议，它们之间的区别包括：
+
+[![TCP 与 UDP 的区别](http://static.iocoder.cn/047b5c455b1153e895df36e364134fcd)](http://static.iocoder.cn/047b5c455b1153e895df36e364134fcd)TCP 与 UDP 的区别
+
+- TCP 是面向连接的；UDP 是无连接的。
+- TCP 是可靠的；UDP 是不可靠的。
+- TCP 只支持点对点通信；UDP 支持一对一、一对多、多对一、多对多的通信模式。
+- TCP 是面向字节流的；UDP 是面向报文的。
+- TCP 有拥塞控制机制；UDP 没有拥塞控制，适合媒体通信。
+- TCP 首部开销(20 个字节)，比 UDP 的首部开销(8 个字节)要大。
+
+🦅 **为什么 TCP 叫数据流模式？ UDP 叫数据报模式？**
+
+所谓的**“流模式”**，是指**TCP 发送端发送几次数据和接收端接收几次数据是没有必然联系的**。
+
+- 比如你通过 TCP 连接给另一端发送数据，你只调用了一次 write ，发送了 100 个字节，但是对方可以分 10 次收完，每次 10 个字节；你也可以调用 10 次 write ，每次 10 个字节，但是对方可以一次就收完。
+- 原因：这是因为 TCP 是面向连接的，一个 Socket 中收到的数据都是由同一台主机发出，且有序地到达，所以每次读取多少数据都可以。
+
+所谓的**“数据报模式”**，是指 **UDP 发送端调用了几次 write ，接收端必须用相同次数的 read 读完**。
+
+- UDP 是基于报文的，在接收的时候，每次最多只能读取一个报文，报文和报文是不会合并的，如果缓冲区小于报文长度，则多出的部分会被丢弃。
+- 原因：这是因为 UDP 是无连接的，只要知道接收端的 IP 和端口，任何主机都可以向接收端发送数据。这时候，如果一次能读取超过一个报文的数据，则会乱套。
+
+## UDP 报文的格式
+
+[![UDP 报文格式](http://static.iocoder.cn/e80a784ed96b6c688ef8e4e409f4cd18)](http://static.iocoder.cn/e80a784ed96b6c688ef8e4e409f4cd18)UDP 报文格式
+
+- 16 位 * 4 = 64 位 = 8 字节。
+
+# DNS
+
+## DNS 是什么？
+
+- 域名解析，[www.xxx.com](http://www.xxx.com/) 转换成 IP ，能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的 IP 数串。
+- DNS 协议运行在 UDP 协议之上，使用端口号 53 。
+
+## 主机解析域名的顺序？
+
+1. 浏览器缓存
+2. 找本机的 hosts 文件
+3. 路由缓存
+4. 找 DNS 服务器(本地域名、顶级域名、根域名)
+   - [迭代查询](https://blog.csdn.net/wuchuanpingstone/article/details/6720723)
+   - [递归查询](https://blog.csdn.net/wuchuanpingstone/article/details/6720723)
+
+## DNS 使用什么协议？
+
+> 参见 [《DNS使用的是 TCP 协议还是 UDP 协议》](https://benbenxiongyuan.iteye.com/blog/1088085) 文章。
+
+既使用 TCP 又使用 UDP 。
+
+- 区域传送时使用 TCP 协议。
+
+  > - 辅域名服务器会定时（一般时 3 小时）向主域名服务器进行查询以便了解数据是否有变动。如有变动，则会执行一次区域传送，进行数据同步。区域传送将使用 TCP 而不是 UDP ，因为数据同步传送的数据量比一个请求和应答的数据量要多得多。
+  > - TCP 是一种可靠的连接，保证了数据的准确性。
+
+- 域名解析时使用 UDP 协议。
+
+  > - 客户端向 DNS 服务器查询域名，一般返回的内容都不超过 512 字节，用 UDP 传输即可。
+  >
+  >   > UDP 报文的最大长度为 512 字节。
+  >
+  > - 不用经过 TCP 三次握手，这样 DNS 服务器负载更低，响应更快。虽然从理论上说，客户端也可以指定向 DNS 服务器查询的时候使用 TCP ，但事实上，很多 DNS 服务器进行配置的时候，仅支持 UDP 查询包。
+
+# HTTP
+
+## HTTP 是什么？
+
+HTTP 协议，是 Hyper Text Transfer Protocol（超文本传输协议）的缩写，是用于从万维网（WWW:World Wide Web ）服务器传输超文本到本地浏览器的传送协议。
+
+主要特点如下：
+
+- 简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有 GET、HEAD、POST 等等。每种方法规定了客户与服务器联系的类型不同。由于 HTTP 协议简单，使得 HTTP 服务器的程序规模小，因而通信速度很快。
+
+- 数据格式灵活：HTTP 允许传输任意类型的数据对象。正在传输的类型由Content-Type 加以标记。
+
+- 无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
+
+  > 主要指的是不使用 Keep-Alive 机制的情况下。
+
+- 无状态：HTTP 协议是无状态协议。无状态，是指协议对于事务处理没有记忆能力。无状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。
+
+  > 无状态，所以更容易做服务的扩容，支撑更大的访问量。
+
+- 支持 B/S 及 C/S 模式。
+
+  > 另外，HTTP 协议已经不仅仅使用在浏览器上。在前后端分离的架构中，又或者微服务架构的内部通信中，HTTP 因为其数据格式的通用性，和语言无关，被大规模使用。
+
+## HTTP 基本格式
+
+> 艿艿：详细的，可以看看 [《猫哥网络编程系列：详解 BAT 面试题》](https://github.com/kaiye/kaiye.github.com/issues/3) 文章。
+
+🦅 **HTTP 请求格式**
+
+[![HTTP 请求格式](http://static.iocoder.cn/e0f66085155bdcdaa170fab4507fa4f1)](http://static.iocoder.cn/e0f66085155bdcdaa170fab4507fa4f1)HTTP 请求格式
+
+- 请求行：用来说明请求类型，要访问的资源以及所使用的 HTTP 版本。
+- 请求头部：紧接着请求行（即第一行）之后的部分，用来说明服务器要使用的附加信息从第二行起为请求头部。
+  - HOST ，将指出请求的目的地。
+  - User-Agent ，服务器端和客户端脚本都能访问它,它是浏览器类型检测逻辑的重要基础。该信息由你的浏览器来定义，并且在每个请求中自动发送等等
+  - …
+- 空行：请求头部后面的空行是必须的。
+- 请求数据：也叫主体，可以添加任意的其他数据。
+
+🦅 **HTTP 响应格式**
+
+[![HTTP 响应格式](http://static.iocoder.cn/da1ada597b5feedcd7d6c17d1989629d)](http://static.iocoder.cn/da1ada597b5feedcd7d6c17d1989629d)HTTP 响应格式
+
+- 状态行：由 HTTP 协议版本号、状态码、状态消息三部分组成。
+- 消息报头：用来说明客户端要使用的一些附加信息。
+- 空行：消息报头后面的空行是必须的。
+- 响应正文：服务器返回给客户端的文本信息。
+
+🦅 **URI 和 URL 的区别？**
+
+见 [《URI 和 URL 的区别》](https://www.jianshu.com/p/ba15d066f777) 文章。
+
+## HTTP 协议包括哪些请求？
+
+- GET: 对服务器资源的简单请求。
+- POST: 用于发送包含用户提交数据的请求。
+- HEAD：类似于 GET 请求，不过返回的响应中没有具体内容，用于获取报头。
+- PUT：传说中请求文档的一个版本。
+- DELETE：发出一个删除指定文档的请求。
+- TRACE：发送一个请求副本，以跟踪其处理进程。
+- OPTIONS：返回所有可用的方法，检查服务器支持哪些方法。
+- CONNECT：用于 SSL 隧道的基于代理的请求。
+
+🦅 **GET 和 POST 的区别？**
+
+| 请求方式 | 数据位置            | 明文密文 | 数据安全 | 长度限制          | 应用场景 |
+| :------- | :------------------ | :------- | :------- | :---------------- | :------- |
+| GET      | HTTP 请求的 path 中 | 明文     | 不安全   | 长度较小，一般 2k | 查询数据 |
+| POST     | HTTP 请求 body 中   | 可明可密 | 安全     | 支持较大数据传输  | 修改数据 |
+
+- GET 请求可被缓存；POST 请求不会被缓存。
+
+- GET 请求可被收藏为书签；POST 不能被收藏为书签。
+
+- 【非常有趣】参见 [《99%的人理解错 HTTP 中 GET 与 POST 的区别》](https://www.oschina.net/news/77354/http-get-post-different)
+
+  > - 对于 GET 方式的请求，浏览器会把 HTTP header 和 data 一并发送出去，服务器响应 200（返回数据）。
+  > - 而对于 POST，浏览器先发送 header ，服务器响应 100 continue ，浏览器再发送 data ，服务器响应 200 ok（返回数据）。
+  >
+  > 也就是说，GET 只需要汽车跑一趟就把货送到了，而 POS T得跑两趟，第一趟，先去和服务器打个招呼“嗨，我等下要送一批货来，你们打开门迎接我”，然后再回头把货送过去。
+  >
+  > ps：不过要注意，POST 具体发几次，也和浏览器的实现有关系。例如：Firefox 只发一次。
+  > ps2：据研究，在网络环境好的情况下，发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下，两次包的 TCP 在验证数据包完整性上，有非常大的优点。
+
+## HTTP 有哪些状态码？
+
+- 1×× : 请求处理中，请求已被接受，正在处理
+- 2×× : 请求成功，请求被成功处理
+  - 200 OK // 客户端请求成功
+- 3×× : 重定向，要完成请求必须进行进一步处理
+  - 301 Moved Permanently // 永久重定向,使用域名跳转
+  - 302 Found // 临时重定向,未登陆的用户访问用户中心重定向到登录页面
+- 4×× : 客户端错误，请求不合法
+  - 400 Bad Request // 客户端请求有语法错误，不能被服务器所理解
+  - 401 Unauthorized // 请求未经授权，这个状态代码必须和 WWW-Authenticate 报头域一起使用
+  - 403 Forbidden // 服务器收到请求，但是拒绝提供服务
+  - 404 Not Found // 请求资源不存在，eg：输入了错误的 URL
+- 5×× : 服务器端错误，服务器不能处理合法请求
+  - 500 Internal Server Error // 服务器发生不可预期的错误
+  - 503 Server Unavailable // 服务器当前不能处理客户端的请求，一段时间后可能恢复正常
+
+完整的状态码列表，可以看看 [《HTTP 状态码》](https://zh.wikipedia.org/zh-hans/HTTP状态码) 文章。
+
+🦅 **forward 和 redirect 的区别？**
+
+- 直接转发方式（Forward），客户端和浏览器只发出一次请求，Servlet、HTML、JSP 或其它信息资源，由第二个信息资源响应该请求，在请求对象 request 中，保存的对象对于每个信息资源是共享的。
+- 间接转发方式（Redirect），实际是两次 HTTP 请求，服务器端在响应第一次请求的时候，让浏览器再向另外一个 URL 发出请求，从而达到转发的目的。
+
+详细的，请看 [《请求转发（Forward）和重定向（Redirect）的区别》](https://www.cnblogs.com/Qian123/p/5345527.html) 。
+
+🦅 **HTTP 返回码中 301 与 302 的区别？**
+
+301，302 都是 HTTP 状态的编码，都代表着某个 URL 发生了转移，不同之处在于：
+
+- 301 redirect: 301 代表永久性转移(Permanently Moved)。
+- 302 redirect: 302 代表暂时性转移(Temporarily Moved)。
+
+详细的，请看 [《HTTP 返回码中 301 与 302 的区别》](https://blog.csdn.net/qmhball/article/details/7838989) 文章。
+
+## HTTP、TCP、Socket 的关系是什么？
+
+- TCP/IP 代表传输控制协议/网际协议，指的是一系列协议族。
+- HTTP 本身就是一个协议，是从 Web 服务器传输超文本到本地浏览器的传送协议。
+- Socket 是 TCP/IP 网络的 API ，其实就是一个门面模式，它把复杂的 TCP/IP 协议族隐藏在 Socket 接口后面。对用户来说，一组简单的接口就是全部，让 Socket 去组织数据，以符合指定的协议。
+
+综上所述：
+
+- 需要 IP 协议来连接网络
+- TCP 是一种允许我们安全传输数据的机制，使用 TCP 协议来传输数据的 HTTP 是 Web 服务器和客户端使用的特殊协议。
+- HTTP 基于 TCP 协议，所以可以使用 Socket 去建立一个 TCP 连接。
+
+## Cookies 和 Session 的区别
+
+- Session 在服务器端，Cookie 在客户端（浏览器）。
+
+  > Session 默认被存在在服务器的一个文件里（不是内存）。
+
+- Session 的运行依赖 sessionid ，而 sessionid 是存在 Cookie 中的，也就是说，如果浏览器禁用了 Cookie ，同时 session 也会失效。但是，可以通过其它方式实现，比如在 url 参数中传递 sessionid 。
+
+- Session 可以放在文件、数据库、或内存中都可以。
+
+- 【关键】**用户验证这种场合一般会用 Session** 。
+
+## 【重要】一次完整的 HTTP 请求所经历的步骤
+
+> 这里的客户端，更多指的是浏览器。
+
+- 1、DNS 解析(通过访问的域名找出其 IP 地址，递归搜索)。
+
+- 2、HTTP 请求，当输入一个请求时，建立一个 Socket 连接发起 TCP的 3 次握手。
+
+  > 如果是 HTTPS 请求，会略微有不同。等到 HTTPS 小节，我们在来讲。
+
+- 3.1、客户端向服务器发送请求命令（一般是 GET 或 POST 请求）。
+
+  > 这个是补充内容，面试一般不用回答。
+  >
+  > 客户端的网络层不用关心应用层或者传输层的东西，主要做的是通过查找路由表确定如何到达服务器，期间可能经过多个路由器，这些都是由路由器来完成的工作，我不作过多的描述，无非就是通过查找路由表决定通过那个路径到达服务器。
+  >
+  > 客户端的链路层，包通过链路层发送到路由器，通过邻居协议查找给定 IP 地址的 MAC 地址，然后发送 ARP 请求查找目的地址，如果得到回应后就可以使用 ARP 的请求应答交换的 IP 数据包现在就可以传输了，然后发送 IP 数据包到达服务器的地址。
+
+- 3.2、客户端发送请求头信息和数据。
+
+- 4.1、服务器发送应答头信息。
+
+- 4.2、服务器向客户端发送数据。
+
+- 5、服务器关闭 TCP 连接（4次挥手）。
+
+  > 这里是否关闭 TCP 连接，也根据 HTTP Keep-Alive 机制有关。
+  >
+  > 同时，客户端也可以主动发起关闭 TCP 连接。
+
+- 6、客户端根据返回的 HTML、CSS、JS 进行渲染。
+
+如下是《图解HTTP》提供的图片：[![HTTP 请求所经历的步骤](http://static.iocoder.cn/be5603b1bb6ff46b640909b5b8976827)](http://static.iocoder.cn/be5603b1bb6ff46b640909b5b8976827)HTTP 请求所经历的步骤
+
+## HTTP1.0 和 HTTP1.1 有什么区别？
+
+主要是如下 8 点：
+
+- 1、可扩展性
+
+- 2、缓存
+
+- 3、带宽优化
+
+  > 带来了[分块传输](https://zh.wikipedia.org/wiki/分块传输编码) 。可能的话，面试也会问。
+
+- 【最重要】4、长连接
+
+- 5、消息传递
+
+- 6、Host 头域
+
+- 7、错误提示
+
+- 8、内容协商
+
+详细的每一点的说明，可以看 [《HTTP1.0 与 HTTP1.1 的区别》](https://blog.csdn.net/ForgotAboutGirl/article/details/6936982) 文章，特别是第 4 点【长连接】。
+
+> HTTP1.1 支持长连接（PersistentConnection）和请求的流水线（Pipelining）。
+>
+> - 长连接（PersistentConnection）：处理在一个 TCP 连接上可以传送多个 HTTP 请求和响应，减少了建立和关闭连接的消耗和延迟。在 HTTP1.1中 默认开启`Connection：keep-alive` ，一定程度上弥补了 HTTP1.0 每次请求都要创建连接的缺点。
+> - 请求的流水线（Pipelining）：HTTP1.1 还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容，这样也显著地减少了整个下载过程所需要的时间。
+>
+> 推荐，在看看 [《HTTP Keep-Alive 是什么？如何工作？》](http://www.nowamagic.net/academy/detail/23350305) 文章。
+>
+> 关于这一点，可能演变的问题有：
+>
+> - HTTP 的长连接是什么意思？
+> - HTTP Keep-Alive 机制是什么？
+> - HTTP Keep-Alive 机制和 TCP Keep-Alive 有什么区别？
+
+## SPDY 是什么？
+
+> 艿艿：关于这个问题，了解就好。
+>
+> HTTP Working-Group 最终决定以 SPDY/2 为基础，开发 HTTP/2 。
+
+2012 年，Google 如一声惊雷提出了 SPDY 的方案，优化了 HTTP1.X 的请求延迟，解决了 HTTP1.X 的安全性，具体如下：
+
+- 1、降低延迟
+
+  > 针对 HTTP 高延迟的问题，SPDY 优雅的采取了多路复用（multiplexing）。多路复用通过多个请求 Stream 共享一个 Tcp连 接的方式，解决了 HOL blocking 的问题，降低了延迟同时提高了带宽的利用率。
+
+- 2、请求优先级（request prioritization）
+
+  > 多路复用带来一个新的问题是，在连接共享的基础之上有可能会导致关键请求被阻塞。SPDY 允许给每个 request 设置优先级，这样重要的请求就会优先得到响应。
+  >
+  > 比如浏览器加载首页，首页的 html 内容应该优先展示，之后才是各种静态资源文件，脚本文件等加载，这样可以保证用户能第一时间看到网页内容。
+
+- 3、header 压缩
+
+  > 前面提到 HTTP1.x 的 header 很多时候都是重复多余的。选择合适的压缩算法可以减小包的大小和数量。
+
+- 4、基于 HTTPS 的加密协议传输
+
+  > 大大提高了传输数据的安全性。
+
+- 5、服务端推送（server push）
+
+  > 采用了 SPDY 的网页，例如我的网页有一个 `sytle.css` 的请求，在客户端收到 `sytle.css` 数据的同时，服务端会将 `sytle.js` 的文件推送给客户端。当客户端再次尝试获取 `sytle.js` 时就可以直接从缓存中获取到，不用再发请求了。
+  >
+  > 🙂 和我们理解的服务端推送，有点（非常）不一样哈。
+
+🚀 SPDY 构成图如下：[![SPDY 构成图](http://static.iocoder.cn/82cf7ea112281d126f23db03a502c249)](http://static.iocoder.cn/82cf7ea112281d126f23db03a502c249)SPDY 构成图
+
+- SPDY 位于 HTTP 之下，TCP 和 SSL 之上，这样可以轻松兼容老版本的 HTTP 协议(将 HTTP1.x 的内容封装成一种新的 frame 格式)，同时可以使用已有的 SSL 功能。
+
+# HTTPS
+
+推荐先看下 [《九个问题从入门到熟悉 HTTPS》](http://juejin.im/post/58c5268a61ff4b005d99652a) 文章，写的很有趣~
+
+另外，也看看 [《SSL/TLS 双向认证(一) – SSL/TLS工作原理》](https://blog.csdn.net/ustccw/article/details/76691248) 文章，写的更技术向~
+
+下面的面试题的答案，我们会基于上述文章来整理。
+
+## HTTPS 是什么？
+
+HTTPS ，实际就是在 TCP 层与 HTTP 层之间加入了 SSL/TLS 来为上层的安全保驾护航，主要用到对称加密、非对称加密、证书，等技术进行客户端与服务器的数据加密传输，最终达到保证整个通信的安全性。
+
+[![img](http://static.iocoder.cn/a9e8780d6b899cf5709579fc9c451fd9)](http://static.iocoder.cn/a9e8780d6b899cf5709579fc9c451fd9)
+
+一句话概括：**HTTP + 加密 + 认证 + 完整性保护 = HTTPS** 。
+
+🦅 **什么是 SSL 呢？什么是 TLS 呢？**
+
+官方定义，SSL 是安全套接层(secure sockets layer)；TLS 是 SSL 的继任者，叫传输层安全(transport layer security)。
+
+它们存在的唯一目的就是保证上层通讯安全的一套机制。它的发展依次经历了下面几个时期，像手机软件升级一样，每次更新都添加或去除功能，比如引进新的加密算法，修改握手方式等。
+
+- SSL1.0: 已废除
+- SSL2.0: RFC6176 ，已废除
+- SSL3.0: RFC6101 ，基本废除
+- **TLS1.0**: RFC2246 ，目前大都采用此种方式
+- TLS1.1: RFC4346
+- TLS1.2: RFC5246 ，没有广泛使用
+- TLS1.3: IETF 正在酝酿中
+
+> 艿艿：为了下面描述方便，统一先叫 SSL 。
+
+🦅 **SSL/TLS 协议作用？**
+
+1. 认证用户和服务器，确保数据发送到正确的客户机和服务器。
+
+   > 客户端必须避免中间人攻击，即除了真正的服务器，任何第三方都无法冒充服务器。
+
+2. 加密数据以防止数据中途被窃取。
+
+3. 维护数据的完整性，确保数据在传输过程中不被改变。
+
+## HTTP 和 HTTPS 的区别？
+
+- 端口不同：HTTP 与 HTTPS 使用不同的连接方式，用的端口也不一样，前者是 80，后者是 443。
+
+  > 艿艿：个人的想法，实际 HTTPS 也是可以使用 80 端口，但是考虑继续保持 HTTP 的兼容，只好退而求其次，使用 443 端口。
+
+- 资源消耗：和 HTTP 通信相比，HTTPS 通信会由于加解密处理消耗更多的 CPU 和内存资源。
+
+- 开销：HTTPS 通信需要证书，而证书一般需要向认证机构申请免费或者付费购买。
+
+  > HTTPS 可以有效的防止运营商劫持，解决了防劫持的一个大问题。
+
+## SSL 加密方式是什么？
+
+> - 对称密钥加密，是指加密和解密使用同一个密钥的方式，这种方式存在的最大问题就是密钥发送问题，即如何安全地将密钥发给对方。
+> - 非对称加密，指使用一对非对称密钥，即公钥和私钥，公钥可以随意发布，但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用自己的私钥进行解密。
+
+SSL 协议，即用到了对称加密也用到了非对称加密，如下图所示：[![SSL 加密过程](http://static.iocoder.cn/images/Net/2020_03_01/01.jpeg)](http://static.iocoder.cn/images/Net/2020_03_01/01.jpeg)SSL 加密过程
+
+> TODO 这个配图有问题。原图我在翻，貌似不小心被我删除了。。。。
+
+- 在建立传输链路时，SSL 首先对对称加密的密钥使用公钥进行非对称加密。
+
+  > 艿艿：注意哟，这里 Server 返回给 Client 的不是公钥( `server.pub` )，而是 `server.crt` 。Client 需要使用 `ca.key` 从 `server.crt` 中解密出公钥( `server.pub` ) 。
+
+- 链路建立好之后，SSL 对传输内容使用公钥( `server.pub` )对称加密。
+
+🦅 **为什么公钥传输的步骤这么复杂呢？**
+
+答案请看 [《九个问题从入门到熟悉 HTTPS》](http://juejin.im/post/58c5268a61ff4b005d99652a) 文章的如下问题：
+
+- Q5: 那公钥怎么传输
+- Q6: 你在逗我么。。。。
+- Q7: 怎么知道证书有没有被篡改？
+- Q8: 这样可以防止第三方冒充服务器么
+
+也就是说，通过 CA 来保证。至于 `server.crt` 证书是怎么申请的呢？请看 [《SSL/TLS 双向认证(一) – SSL/TLS工作原理》](https://blog.csdn.net/ustccw/article/details/76691248) 文章的 [「CA 的证书 ca.crt 和 SSL Server 的证书 server.crt 是什么关系呢？ 」](https://svip.iocoder.cn/Net/Interview/#) 问题的解答。
+
+> 艿艿：看这块，我已经要被绕晕了！！！耐心~胖友，理解后会很爽。
+
+## 什么是单向认证、双向认证？
+
+- 单向认证，指的是只有一个对象校验对端的证书合法性。
+
+  > 通常都是 Client 来校验服务器的合法性。那么 Client 需要一个`ca.crt` ，服务器需要 `server.crt` 和 `server.key` 。
+
+- 双向认证，指的是相互校验，Server 需要校验每个 Client ，Client 也需要校验服务器。
+
+  > - Server 需要 `server.key`、`server.crt`、`ca.crt` 。
+  > - Client 需要 `client.key`、`client.crt`、`ca.crt` 。
+
+🦅 **1）单向认证的过程？**
+
+[![单向认证](http://static.iocoder.cn/bdf6be06c37bcc026ed906f392661e3b)](http://static.iocoder.cn/bdf6be06c37bcc026ed906f392661e3b)单向认证
+
+- 1、客户端向服务端发送 SSL 协议版本号、加密算法种类、随机数等信息。
+
+- 2、服务端给客户端返回 SSL 协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书。
+
+- 3、客户端使用服务端返回的信息验证服务器的合法性，包括：
+
+  - 证书是否过期。
+
+  - 发型服务器证书的 CA 是否可靠。
+
+  - 返回的公钥是否能正确解开返回证书中的数字签名。
+
+  - 服务器证书上的域名是否和服务器的实际域名相匹配
+
+    > 验证通过后，将继续进行通信；否则，终止通信。
+
+  - 4、客户端向服务端发送自己所能支持的对称加密方案，供服务器端进行选择。
+  - 5、服务器端在客户端提供的加密方案中选择加密程度最高的加密方式。
+
+- 6、服务器将选择好的加密方案通过明文方式返回给客户端。
+
+- 7、客户端接收到服务端返回的加密方式后，使用该加密方式生成产生随机码，用作通信过程中对称加密的密钥，使用服务端返回的公钥进行加密，将加密后的随机码发送至服务器。
+
+- 8、服务器收到客户端返回的加密信息后，使用自己的私钥进行解密，获取对称加密密钥。
+
+  > **在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通信过程中信息的安全**。
+
+🦅 **2）双向认证的过程？**
+
+双向认证和单向认证原理基本差不多，只是除了客户端需要认证服务端以外，增加了服务端对客户端的认证，具体过程如下：
+
+[![双向认证](http://static.iocoder.cn/61ed2a8b189fc549a9c7407c2ebedb64)](http://static.iocoder.cn/61ed2a8b189fc549a9c7407c2ebedb64)双向认证
+
+- 1、客户端向服务端发送 SSL 协议版本号、加密算法种类、随机数等信息。
+
+- 2、服务端给客户端返回 SSL 协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书。
+
+- 3、客户端使用服务端返回的信息验证服务器的合法性，包括：
+
+  - 证书是否过期。
+
+  - 发型服务器证书的 CA 是否可靠。
+
+  - 返回的公钥是否能正确解开返回证书中的数字签名。
+
+  - 服务器证书上的域名是否和服务器的实际域名相匹配
+
+    > 验证通过后，将继续进行通信；否则，终止通信。
+
+  - **【新增】4、服务端要求客户端发送客户端的证书，客户端会将自己的证书发送至服务端。**
+  - **【新增】5、验证客户端的证书，通过验证后，会获得客户端的公钥。**
+  - 6、客户端向服务端发送自己所能支持的对称加密方案，供服务器端进行选择。
+  - 7、服务器端在客户端提供的加密方案中选择加密程度最高的加密方式。
+
+- 8、服务器将选择好的加密方案通过明文方式返回给客户端。
+
+- 9、客户端接收到服务端返回的加密方式后，使用该加密方式生成产生随机码，用作通信过程中对称加密的密钥，使用服务端返回的公钥进行加密，将加密后的随机码发送至服务器。
+
+- 10、服务器收到客户端返回的加密信息后，使用自己的私钥进行解密，获取对称加密密钥。
+
+  > **在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通信过程中信息的安全**。
+
+🦅 **如何选择单向认证还是双向认证**
+
+- 一般一个站点很多用户访问就用单向认证。
+
+- 企业接口对接就用双向认证。
+
+  > 如果想要提高 APP 的安全级别，也可以考虑双向认证。因为，APP 天然方便放入客户端证书，从而提高安全级别。
+
+## 为什么抓包工具还能抓到 HTTPS 数据包并解密成功呢
+
+不是说HTTPS在网络中传输的是密文吗？这个问题就是**中间者攻击**（man in zhe middle）。
+
+[![中间者攻击原理图](http://static.iocoder.cn/0332b5d6001f7446a04a5d54b9b93d7e)](http://static.iocoder.cn/0332b5d6001f7446a04a5d54b9b93d7e)中间者攻击原理图
+
+- 解决办法，就是 HTTPS 单向验证。在客户端中内置服务器公钥，在第三步服务器返回的公钥，除了验证公钥的有效性之外，再比对公钥是不是和内置的公钥一样，不一样说明被中间者攻击了，就断开链接不在请求了。
+- 这个原理的前提是服务器的私钥没有泄露，客户端的代码不会被破解，道高一尺魔高一丈。信息安全就是在合理的范围内，选择比较合适的加密方法，没有绝对论，只有相对论。在某个范围内比较安全。
+
+## HTTPS 握手会影响性能么？
+
+TCP 有三次握手，再加上 HTTPS 的四次握手，影响肯定有，但是可以接受。
+
+- 首先，HTTPS 肯定会更慢一点，时间主要花费在两组 SSL 之间的耗时和证书的读取验证上，对称算法的加解密时间几乎可以忽略不计。
+- 而且如果不是首次握手，后续的请求并不需要完整的握手过程。客户端可以把上次的加密情况直接发送给服务器从而快速恢复，具体细节可以参考 [《图解 SSL/TLS 协议》](http://www.ruanyifeng.com/blog/2014/09/illustration-ssl.html) 。
+- 除此以外，SSL 握手的时间并不是只能用来传递加密信息，还可以承担起客户端和服务器沟通 HTTP2 兼容情况的任务。因此从 HTTPS 切换到 HTTP2.0 不会有任何性能上的开销，反倒是得益于 HTTP2.0 的多路复用等技术，后续可以节约大量时间。
+- 如果把 HTTPS2.0 当做目标，那么 HTTPS 的性能损耗就更小了，远远比不上它带来的安全性提升。
+
+# HTTP2
+
+[![HTTP2 和 HTTP1.1 的区别](http://static.iocoder.cn/482a127d8fd07940d8f255610c716792)](http://static.iocoder.cn/482a127d8fd07940d8f255610c716792)HTTP2 和 HTTP1.1 的区别
+
+## 什么是 HTTP2.0 ？
+
+HTTP2.0 ，可以说是SPDY的升级版（其实原本也是基于SPDY设计的），但是，HTTP2.0 跟 SPDY 仍有不同的地方，如下：
+
+- HTTP2.0 支持明文 HTTP 传输，而 SPDY 强制使用 HTTPS 。
+- HTTP2.0 消息头的压缩算法采用 [HPACK](https://link.jianshu.com/?t=http://http2.github.io/http2-spec/compression.html)，而非 SPDY 采用的 [DEFLATE](https://link.jianshu.com/?t=http://zh.wikipedia.org/wiki/DEFLATE) 。
+
+## HTTP2.0 和 HTTP1.X 相比的新特性？
+
+- 1、新的二进制格式（Binary Format）
+
+  > HTTP1.x 的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认 0 和 1 的组合。基于这种考虑 HTTP2.0 的协议解析决定采用二进制格式，实现方便且健壮。
+
+- 同 SPDY 对 HTTP1.1 的改进。
+
+  - 2、降低延迟
+  - 3、多路复用（MultiPlexing）
+  - 4、header 压缩
+  - 5、服务端推送（server push）
+
+## Nginx 怎么做 HTTP2.0 的升级改造？
+
+- 1、虽然 HTTP2.0 其实可以支持非 HTTPS 的，但是现在主流的浏览器像 Chrome，Firefox 表示还是只支持基于 TLS 部署的 HTTP2.0协议，所以要想升级成 HTTP2.0 还是先升级 HTTPS 为好。
+- 2、当你的网站已经升级 HTTPS 之后，那么升级 HTTP2.0 就简单很多，如果你使用 NGINX ，只要在配置文件中启动相应的协议就可以了，可以参考 [NGINX白皮书](https://link.jianshu.com/?t=https://www.nginx.com/wp-content/uploads/2015/09/NGINX_HTTP2_White_Paper_v4.pdf)，[NGINX配置HTTP2.0官方指南](https://link.jianshu.com/?t=https://www.nginx.com/blog/nginx-1-9-5/) 。
+- 3、使用了 HTTP2.0 那么，原本的 HTTP1.x 怎么办？这个问题其实不用担心，HTTP2.0 完全兼容 HTTP1.x 的语义，对于不支持 HTTP2.0 的浏览器，NGINX 会自动向下兼容的。
+
+在我们内部的微服务 API 接口，也可以做 HTTP2 的改造，可以参考如下文章：
+
+> 艿艿：选读，作为知识的扩充
+
+- [《Spring Cloud 使用 HTTP2》](https://www.jianshu.com/p/ed3f8f983764)
+- [《再说 SpringBoot2.0 与 HTTP/2》](https://www.jianshu.com/p/7ddcdd3847d6)
+
+## HTTP2.0 的多路复用和 HTTP1.X 中的长连接复用有什么区别？
+
+- HTTP/1.0：一次请求-响应，建立一个连接，用完关闭；每一个请求都要建立一个连接。
+- HTTP/1.1：Pipeling 解决方式为，若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会。一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的线头阻塞。
+- HTTP/2：多个请求可同时在一个连接上并行执行。某个请求任务耗时严重，不会影响到其它连接的正常执行。
+
+如下图所示：[![HTTP/1.1 对比 HTTP/2](http://static.iocoder.cn/7268e2a2553c6612396b7de03667d348)](http://static.iocoder.cn/7268e2a2553c6612396b7de03667d348)HTTP/1.1 对比 HTTP/2
+
+🦅 **HTTP2.0 多路复用有多好？**
+
+> 艿艿：最近重新看了 TCP ，发现再看这个问题，真的是有趣！
+
+HTTP 性能优化的关键并不在于高带宽，而是低延迟。TCP 连接会随着时间进行自我「调谐」，起初会限制连接的最大速度，如果数据成功传输，会随着时间的推移提高传输的速度。这种调谐则被称为 TCP 慢启动。由于这种原因，让原本就具有突发性和短时性的 HTTP 连接变的十分低效。
+
+HTTP/2 通过让所有数据流共用同一个连接，可以更有效地使用 TCP 连接，让高带宽也能真正的服务于 HTTP 的性能提升。
+
+## 服务器推送到底是什么？
+
+服务端推送能把客户端所需要的资源伴随着 `index.html` 一起发送到客户端，省去了客户端重复请求的步骤。正因为没有发起请求，建立连接等操作，所以静态资源通过服务端推送的方式可以极大地提升速度。具体如下：
+
+- 普通的客户端请求过程：[![普通的客户端请求过程](http://static.iocoder.cn/9eecd5ec56714731d0e38c6ef9c468d1)](http://static.iocoder.cn/9eecd5ec56714731d0e38c6ef9c468d1)普通的客户端请求过程
+- 服务端推送的过程：[![服务端推送的过程](http://static.iocoder.cn/c30ec0b3743d1f9751d3ba511f94578b)](http://static.iocoder.cn/c30ec0b3743d1f9751d3ba511f94578b)服务端推送的过程
+
+## 为什么需要头部(header)压缩？
+
+假定一个页面有 100 个资源需要加载（这个数量对于今天的 Web 而言还是挺保守的），而每一次请求都有 1kb 的消息头（这同样也并不少见，因为 Cookie 和引用等东西的存在），则至少需要多消耗 100kb 来获取这些消息头。HTTP2.0 可以维护一个字典，差量更新 HTTP 头部，大大降低因头部传输产生的流量。
+
+具体参考：[《HTTP/2 头部压缩技术介绍》](https://link.jianshu.com/?t=https://imququ.com/post/header-compression-in-http2.html) 文章。
+
+- 维护一份相同的静态字典（Static Table），包含常见的头部名称，以及特别常见的头部名称与值的组合。
+- 维护一份相同的动态字典（Dynamic Table），可以动态地添加内容。
+- 支持基于静态哈夫曼码表的哈夫曼编码（Huffman Coding）。
+
+# 彩蛋
+
+感觉，大学丢掉的网络知识，又一次回到我的脑子中了。好开心，又可以遗忘一轮啦，哈哈哈哈。
+
+参考与推荐如下文章：
+
+- [《Https 单向认证和双向认证》](https://blog.csdn.net/duanbokan/article/details/50847612)
+- [《【网络协议】ping 的工作原理》](https://blog.csdn.net/Maybe_ch/article/details/82598782)
+- [《HTTP1.0、HTTP1.1 和 HTTP2.0 的区别》](https://www.jianshu.com/p/be29d679cbff)
+- [《计算机网络常见面试题》](https://segmentfault.com/a/1190000010819141)
+- [《总结的网络面试题》](https://www.jianshu.com/p/a1f5daf7ada5)
+- [《面试/笔试第一弹 —— 计算机网络面试问题集锦》](https://blog.csdn.net/justloveyou_/article/details/78303617)
+- [《通俗大白话来理解 TCP 协议的三次握手和四次挥手》](https://github.com/jawil/blog/issues/14)
+- [《TCP 数据的传输过程》](https://www.jianshu.com/p/b71ec62b6eb5)
+- [《搞定计算机网络面试，看这篇就够了（补充版）》](https://juejin.im/post/5b7be0b2e51d4538db34a51e)
\ No newline at end of file
diff --git a/面试题/22-Linux 面试题.assets/21cb3c25dac3045e9392a55906c581e4-17182495239995 b/面试题/22-Linux 面试题.assets/21cb3c25dac3045e9392a55906c581e4-17182495239995
new file mode 100644
index 0000000..41da561
Binary files /dev/null and b/面试题/22-Linux 面试题.assets/21cb3c25dac3045e9392a55906c581e4-17182495239995 differ
diff --git a/面试题/22-Linux 面试题.assets/27d6182eb0d582a975870534368a436b-171824952399910 b/面试题/22-Linux 面试题.assets/27d6182eb0d582a975870534368a436b-171824952399910
new file mode 100644
index 0000000..18b6dfd
Binary files /dev/null and b/面试题/22-Linux 面试题.assets/27d6182eb0d582a975870534368a436b-171824952399910 differ
diff --git a/面试题/22-Linux 面试题.assets/64991a70b828228d02ec18bc722ed10f.jpeg b/面试题/22-Linux 面试题.assets/64991a70b828228d02ec18bc722ed10f.jpeg
new file mode 100644
index 0000000..1ada49e
Binary files /dev/null and b/面试题/22-Linux 面试题.assets/64991a70b828228d02ec18bc722ed10f.jpeg differ
diff --git a/面试题/22-Linux 面试题.assets/7cf02db233d20982427c0799c713fb32-17182495239996 b/面试题/22-Linux 面试题.assets/7cf02db233d20982427c0799c713fb32-17182495239996
new file mode 100644
index 0000000..605b8d0
Binary files /dev/null and b/面试题/22-Linux 面试题.assets/7cf02db233d20982427c0799c713fb32-17182495239996 differ
diff --git a/面试题/22-Linux 面试题.assets/8c61ee5a2a59b6fb2de4edd893cb7412-17182495239994 b/面试题/22-Linux 面试题.assets/8c61ee5a2a59b6fb2de4edd893cb7412-17182495239994
new file mode 100644
index 0000000..61d663e
Binary files /dev/null and b/面试题/22-Linux 面试题.assets/8c61ee5a2a59b6fb2de4edd893cb7412-17182495239994 differ
diff --git a/面试题/22-Linux 面试题.assets/a32adc09e567efe7ca9ab0d7e77c22ce-17182495239998 b/面试题/22-Linux 面试题.assets/a32adc09e567efe7ca9ab0d7e77c22ce-17182495239998
new file mode 100644
index 0000000..9bb80e5
Binary files /dev/null and b/面试题/22-Linux 面试题.assets/a32adc09e567efe7ca9ab0d7e77c22ce-17182495239998 differ
diff --git a/面试题/22-Linux 面试题.assets/b1e0efa3199c1dad93db3f69de812e7d-17182495239992 b/面试题/22-Linux 面试题.assets/b1e0efa3199c1dad93db3f69de812e7d-17182495239992
new file mode 100644
index 0000000..8dda27c
Binary files /dev/null and b/面试题/22-Linux 面试题.assets/b1e0efa3199c1dad93db3f69de812e7d-17182495239992 differ
diff --git a/面试题/22-Linux 面试题.assets/b6865417dd1245e4f3c4ba877ce9c5aa-171824952399911 b/面试题/22-Linux 面试题.assets/b6865417dd1245e4f3c4ba877ce9c5aa-171824952399911
new file mode 100644
index 0000000..8e4b876
Binary files /dev/null and b/面试题/22-Linux 面试题.assets/b6865417dd1245e4f3c4ba877ce9c5aa-171824952399911 differ
diff --git a/面试题/22-Linux 面试题.assets/c47f9cf21355ced275d4c1dadc254b21-17182495239999 b/面试题/22-Linux 面试题.assets/c47f9cf21355ced275d4c1dadc254b21-17182495239999
new file mode 100644
index 0000000..2036f84
Binary files /dev/null and b/面试题/22-Linux 面试题.assets/c47f9cf21355ced275d4c1dadc254b21-17182495239999 differ
diff --git a/面试题/22-Linux 面试题.assets/c6afc22251bafccf163d532c1e96b7f2-17182495239997 b/面试题/22-Linux 面试题.assets/c6afc22251bafccf163d532c1e96b7f2-17182495239997
new file mode 100644
index 0000000..628ba24
Binary files /dev/null and b/面试题/22-Linux 面试题.assets/c6afc22251bafccf163d532c1e96b7f2-17182495239997 differ
diff --git a/面试题/22-Linux 面试题.assets/cb2d25b03441be2a1c068e336390b895-17182495239993 b/面试题/22-Linux 面试题.assets/cb2d25b03441be2a1c068e336390b895-17182495239993
new file mode 100644
index 0000000..d15ab4c
Binary files /dev/null and b/面试题/22-Linux 面试题.assets/cb2d25b03441be2a1c068e336390b895-17182495239993 differ
diff --git a/面试题/22-Linux 面试题.md b/面试题/22-Linux 面试题.md
new file mode 100644
index 0000000..3869fb5
--- /dev/null
+++ b/面试题/22-Linux 面试题.md	
@@ -0,0 +1,1614 @@
+# 精尽 Linux 面试题「最新更新时间：2024-02」
+
+以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。
+
+如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的【网络】面试题的大保健。
+
+而题目的难度，艿艿尽量按照从容易到困难的顺序，逐步下去。
+
+另外，本面试题面向的是开发，而不是运维。所以会写的相对简单，以开发常见的 Linux 面试题为准。并且，本文会整理一些常用的 Linux 的命令，对应标题为 `命令` 结果为的小节，例如说 `cp` 命令，对应到 “cp 命令” 小节。
+
+# 常用命令
+
+> 艿艿：这一小节会非常非常非常长，当做温故知新吧。
+>
+> 另外，面试官也可能会问，你熟悉 Linux 么？你平时使用哪些 Linux 命令。酱紫的连环炮~
+>
+> 当然，建议重点看下 [「性能相关」](https://svip.iocoder.cn/Linux/Interview/#) 小节。
+
+## 目录相关
+
+### find 命令
+
+[《Linux 命令大全 —— find 命令》](http://man.linuxde.net/find)
+
+- 查找指定文件名的文件(不区分大小写)：`find -iname "MyProgram.c"` 。
+- 对找到的文件执行某个命令：`find -iname "MyProgram.c" -exec md5sum {} \;` 。
+- 查找 home 目录下的所有空文件：`find ~ -empty` 。
+
+🦅 **【常用】如何在 `/usr` 目录下找出大小超过 10MB 的文件?**
+
+- 输入命令 `find /usr -type f -size +10240k` 命令。
+
+- 输出结果如下：
+
+  ```
+  /usr/lib/locale/locale-archive
+  /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.151-1.b12.el7_4.x86_64/jre/lib/amd64/server/classes.jsa
+  /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.151-1.b12.el7_4.x86_64/jre/lib/amd64/server/libjvm.so
+  /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.151-1.b12.el7_4.x86_64/jre/lib/rt.jar
+  
+  // ... 省略
+  ```
+
+另外，du 命令也可以做类似的事情，可以看看 [《查找 Linux 系统中的占用磁盘空间最大的前 10 个文件或文件夹》](https://my.oschina.net/huxuanhui/blog/58119) 文章。
+
+🦅 **如何在 `/var` 目录下找出 90 天之内未被访问过的文件？**
+
+- 输入命令：`find /var \! -atime -90` 。
+
+🦅 **如何在 `/home` 目录下找出 120 天之前被修改过的文件？**
+
+- 输入命令：`find /home -mtime +120` 。
+
+🦅 **在整个目录树下查找文件 `“core”` ，如发现则无需提示直接删除它们？**
+
+- 输入命令：`find / -name core -exec rm {} \;` 。
+
+### ls 命令
+
+[《Linux 命令大全 —— ls 命令》](http://man.linuxde.net/ls)
+
+- 以易读的方式显示文件大小(显示为 MB,GB…)：`ls -lh` 。
+- 以最后修改时间升序列出文件：`ls -ltr` 。
+- 在文件名后面显示文件类型：`ls -F` 。
+
+### pwd 命令
+
+[《Linux 命令大全 —— pwd 命令》](http://man.linuxde.net/pwd)
+
+- 输出当前工作目录：`pwd` 。
+
+### cd 命令
+
+[《Linux 命令大全 —— cd 命令》](http://man.linuxde.net/cd)
+
+- `cd` ：可以在最近工作的两个目录间切换。
+
+## mkdir 命令
+
+[《Linux 命令大全 —— mkdir 命令》](http://man.linuxde.net/mkdir)
+
+- 在 home 目录下创建一个名为 temp 的目录：`mkdir ~/temp` 。
+- 使用 `-p` 选项可以创建一个路径上所有不存在的目录：`mkdir -p dir1/dir2/dir3/dir4/` 。
+
+### df 命令
+
+[《Linux 命令大全 —— df 命令》](http://man.linuxde.net/df)
+
+- 显示文件系统的磁盘使用情况，默认情况下 `df -k` 将以字节为单位输出磁盘的使用量。
+- 使用 `df -h` 选项可以以更符合阅读习惯的方式显示磁盘使用量。
+- 使用 `df -T` 选项显示文件系统类型。
+
+### rm 命令
+
+[《Linux 命令大全 —— rm 命令》](http://man.linuxde.net/rm)
+
+- 删除文件前先确认：`rm -i filename.txt` 。
+- 在文件名中使用 shell 的元字符会非常有用。删除文件前先打印文件名并进行确认：`rm -i file*` 。
+- 递归删除文件夹下所有文件，并删除该文件夹：`rm -r example` 。
+
+### mv 命令
+
+[《Linux 命令大全 —— mv 命令》](http://man.linuxde.net/mv)
+
+- 将 file1 重命名为 file2 ，如果 file2 存在则提示是否覆盖：`mv -i file1 file2` 。
+- `-v` 会输出重命名的过程，当文件名中包含通配符时，这个选项会非常方便：`mv -v file1 file2` 。
+
+### cp 命令
+
+[《Linux 命令大全 —— cp 命令》](http://man.linuxde.net/cp)
+
+- 拷贝 file1 到 file2 ，并保持文件的权限、属主和时间戳：`cp -p file1 file2` 。
+- 拷贝 file1 到 file2 ，如果 file2 存在会提示是否覆盖：`cp -i file1 file2` 。
+
+🦅 **有一普通用户想在每周日凌晨零点零分定期备份 `/user/backup`到 `/tmp` 目录下，该用户应如何做?**
+
+- 配置如下：
+
+  ```
+  crontab -e
+  0 0 * * 7 /bin/cp /user/backup /tmp
+  ```
+
+🦅 **每周一下午三点将 `/tmp/logs` 目录下面的后缀为 `\*.log` 的所有文件 rsync 同步到备份服务器 `192.168.1.100` 中同样的目录下面**
+
+- 配置如下：
+
+  ```
+  crontab -e
+  00 15 * * 1 rsync -avzP /tmp/logs/*.log root@192.168.1.100:/tmp/logs
+  ```
+
+相比来说，`rsync` 比 `scp` 的性能更好。具体可以看看 [《scp 与 rsync 性能实测》](https://tinyhema.iteye.com/blog/2107158) 文章。
+
+### mount 命令
+
+[《Linux 命令大全 —— mount 命令》](http://man.linuxde.net/mount)
+
+- 如果要挂载一个文件系统，需要先创建一个目录，然后将这个文件系统挂载到这个目录上：
+
+  ```
+  # mkdir /u01
+  
+  # mount /dev/sdb1 /u01
+  ```
+
+- 也可以把它添加到 fstab 中进行自动挂载，这样任何时候系统重启的时候，文件系统都会被加载：
+
+  ```
+  /dev/sdb1 /u01 ext2 defaults 0 2
+  ```
+
+### cat 命令
+
+[《Linux 命令大全 —— cat 命令》](http://man.linuxde.net/cat)
+
+- 你可以一次查看多个文件的内容，下面的命令会先打印 file1 的内容，然后打印 file2 的内容：`cat file1 file2` 。
+- `-n` 命令可以在每行的前面加上行号：`cat -n /etc/logrotate.conf` 。
+
+🦅 **如何看当前 Linux 系统有几颗物理 CPU 和每颗 CPU 的核数？**
+
+```
+[root@centos6 ~ 10:55 #35]# cat /proc/cpuinfo|grep -c 'physical id'
+4
+
+[root@centos6 ~ 10:56 #36]# cat /proc/cpuinfo|grep -c 'processor'
+4
+```
+
+### tail 命令
+
+[《Linux 命令大全 —— tail 命令》](http://man.linuxde.net/tail)
+
+- tail 命令默认显示文件最后的 10 行文本：`tail filename.txt` 。
+- 你可以使用 `-n` 选项指定要显示的行数：`tail -n N filename.txt` 。
+- 你也可以使用 `-f` 选项进行实时查看，这个命令执行后会等待，如果有新行添加到文件尾部，它会继续输出新的行，在查看日志时这个选项会非常有用。你可以通过 `CTRL-C` 终止命令的执行：`tail -f log-file` 。
+
+### less 命令
+
+[《Linux 命令大全 —— less 命令》](http://man.linuxde.net/less)
+
+- 这个命名可以在不加载整个文件的前提下显示文件内容，在查看大型日志文件的时候这个命令会非常有用：`less huge-log-file.log` 。
+
+- 当你用 less 命令打开某个文件时，下面两个按键会给你带来很多帮助，他们用于向前和向后滚屏：
+
+  ```
+  CTRL+F – forward one window
+  CTRL+B – backward one window
+  ```
+
+## 通用命令
+
+### grep 命令
+
+[《Linux 命令大全 —— grep 命令》](http://man.linuxde.net/grep)
+
+- 在文件中查找字符串(不区分大小写)：`grep -i "the" demo_file` 。
+- 输出成功匹配的行，以及该行之后的三行：`grep -A 3 -i "example" demo_text` 。
+- 在一个文件夹中递归查询包含指定字符串的文件：`grep -r "ramesh" *` 。
+
+### sed 命令
+
+[《Linux 命令大全 —— sed 命令》](http://man.linuxde.net/sed)
+
+- 当你将 Dos 系统中的文件复制到 Unix/Linux 后，这个文件每行都会以 `\r\n` 结尾，sed 可以轻易将其转换为 Unix 格式的文件，使用`\n` 结尾的文件：`sed 's/.$//' filename` 。
+- 反转文件内容并输出：`sed -n '1!G; h; p' filename` 。
+- 为非空行添加行号：`sed '/./=' thegeekstuff.txt | sed 'N; s/\n/ /'` 。
+
+🦅 **用 sed 命令将指定的路径 `/usr/local/http` 替换成为 `/usr/src/local/http` ？**
+
+```
+[root@centos7 ~]# echo "/usr/local/http/" | sed 's#/usr/local/#/usr/src/local/#'
+```
+
+🦅 **打印 `/etc/ssh/sshd_config` 的第一百行？**
+
+```
+sed -n '100p' /etc/ssh/sshd_config
+```
+
+🦅 **用 sed 命令永久关闭防火墙？**
+
+```
+[root@centos7 ~]# sed -i.bak 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config 
+[root@centos7 ~]# cat /etc/selinux/config
+
+# This file controls the state of SELinux on the system.
+# SELINUX= can take one of these three values:
+#     enforcing - SELinux security policy is enforced.
+#     permissive - SELinux prints warnings instead of enforcing.
+#     disabled - No SELinux policy is loaded.
+SELINUX=disabled
+# SELINUXTYPE= can take one of three two values:
+#     targeted - Targeted processes are protected,
+#     minimum - Modification of targeted policy. Only selected processes are protected. 
+#     mls - Multi Level Security protection.
+SELINUXTYPE=targeted
+```
+
+### awk 命令
+
+[《Linux 命令大全 —— awk 命令》](http://man.linuxde.net/awk)
+
+- 删除重复行：`$ awk '!($0 in array) { array[$0]; print}' temp` 。
+- 打印 `/etc/passwd` 中所有包含同样的 uid 和 gid 的行：`awk -F ':' '$3=$4' /etc/passwd` 。
+- 打印文件中的指定部分的字段：`awk '{print $2,$5;}' employee.txt` 。
+
+可能会有胖友刚开始会懵逼，awk 和 sed 命令不是类似的么，那么就可以看看 [《【总结】awk 与 sed 的区别》](https://blog.csdn.net/lonfee88/article/details/6034396) 。
+
+🦅 **打印 /etc/passwd 的 1 到 3 行？**
+
+- 使用 sed 命令：
+
+  ```
+  [root@centos7 ~]# sed -n '1,3p' /etc/passwd
+  root:x:0:0:root:/root:/bin/bash
+  system:x:0:0::/home/system:/bin/bash
+  bin:x:1:1:bin:/bin:/sbin/nologin
+  ```
+
+- 使用 awk 命令：
+
+  ```
+  [root@centos7 ~]# awk 'NR>=1&&NR<=3{print $0}' /etc/passwd   
+  root:x:0:0:root:/root:/bin/bash
+  system:x:0:0::/home/system:/bin/bash
+  bin:x:1:1:bin:/bin:/sbin/nologin
+  ```
+
+### vim 命令
+
+[《Linux vi/vim》](http://www.runoob.com/linux/linux-vim.html)
+
+- 打开文件并跳到第 10 行：`vim +10 filename.txt` 。
+- 打开文件跳到第一个匹配的行：`vim +/search-term filename.txt` 。
+- 以只读模式打开文件：`vim -R /etc/passwd` 。
+
+### diff 命令
+
+> 貌似不太常用，当学习下。
+
+[《Linux 命令大全 —— diff 命令》](http://man.linuxde.net/diff)
+
+- 比较的时候忽略空白符：`diff -w name_list.txt name_list_new.txt` 。
+
+### sort 命令
+
+> 貌似不太常用，当学习下。
+
+[《Linux 命令大全 —— sort 命令》](http://man.linuxde.net/sort)
+
+- 以升序对文件内容排序：`sort names.txt` 。
+- 以降序对文件内容排序：`sort -r names.txt` 。
+- 以第三个字段对 `/etc/passwd` 的内容排序：`sort -t: -k 3n /etc/passwd | more` 。
+
+🦅 ****
+
+### xargs 命令
+
+[《Linux 命令大全 —— xargs 命令》](http://man.linuxde.net/xargs)
+
+- 将所有图片文件拷贝到外部驱动器：`ls *.jpg | xargs -n1 -i cp {} /external-hard-drive/directory` 。
+- 将系统中所有 jpg 文件压缩打包：`find / -name *.jpg -type f -print | xargs tar -cvzf images.tar.gz` 。
+- 下载文件中列出的所有 url 对应的页面：`cat url-list.txt | xargs wget –c` 。
+
+🦅 **把当前目录下所有后缀名为 .txt 的文件的权限修改为 777 ？**
+
+- 方式一，使用 xargs 命令：`find ./ -type f -name "*.txt" |xargs chmod 777` 。
+- 方式二，使用 exec 命令：`find ./ -type f -name "*.txt" -exec chmod 777 {}` 。
+
+## 压缩相关
+
+### tar 命令
+
+[《tar 压缩解压缩命令详解》](https://www.cnblogs.com/jyaray/archive/2011/04/30/2033362.html)
+
+- 创建一个新的 tar 文件： `tar cvf archive_name.tar dirname/` 。
+- 解压 tar 文件：`tar xvf archive_name.tar` 。
+- 查看 tar 文件：`tar tvf archive_name.tar` 。
+
+### gzip 命令
+
+[《Linux 命令大全 —— gzip 命令》](http://man.linuxde.net/gzip)
+
+- 创建一个 `*.gz` 的压缩文件：`gzip test.txt` 。
+- 解压 `*.gz` 文件：`gzip -d test.txt.gz` 。
+- 显示压缩的比率：`gzip -l *.gz` 。
+
+### bzip2 命令
+
+[《Linux 命令大全 —— bzip2 命令》](http://man.linuxde.net/bzip2)
+
+- 创建 `*.bz2` 压缩文件：`bzip2 test.txt` 。
+- 解压 `*.bz2` 文件：`bzip2 -d test.txt.bz2` 。
+
+### unzip 命令
+
+[《Linux 命令大全 —— unzip 命令》](http://man.linuxde.net/unzip)
+
+- 解压 `*.zip` 文件：`unzip test.zip` 。
+- 查看 `*.zip` 文件的内容：`unzip -l jasper.zip` 。
+
+## 系统命令
+
+### export 命令
+
+[《Linux 命令大全 —— export 命令》](http://man.linuxde.net/export)
+
+- 输出跟字符串 oracle 匹配的环境变量：`export | grep ORCALE` 。
+- 设置全局环境变量：`export ORACLE_HOME=/u01/app/oracle/product/10.2.0` 。
+
+### kill 命令
+
+[《Linux 命令大全 —— kill 命令》](http://man.linuxde.net/kill)
+
+kill 用于终止一个进程。一般我们会先用 `ps -ef` 查找某个进程得到它的进程号，然后再使用 `kill -9` 进程号终止该进程。你还可以使用killall、pkill、xkill 来终止进程
+
+> 艿艿：注意，`-9` 表示强制终止指定进程。实际场景下，不会这么做。
+>
+> 但一般情况下，只需要 `kill 进程编号` 就可结束。
+
+```
+$ ps -ef | grep vim
+ramesh    7243  7222  9 22:43 pts/2    00:00:00 vim
+
+$ kill -9 7243
+```
+
+### passwd 命令
+
+[《Linux 命令大全 —— passwd 命令》](http://man.linuxde.net/passwd)
+
+- passwd 用于在命令行修改密码，使用这个命令会要求你先输入旧密码，然后输入新密码：`passwd` 。
+- 超级用户可以用这个命令修改其他用户的密码，这个时候不需要输入用户的密码：`passwd USERNAME` 。
+- passwd 还可以删除某个用户的密码，这个命令只有 root 用户才能操作，删除密码后，这个用户不需要输入密码就可以登录到系统：`passwd -d USERNAME` 。
+
+### su 命令
+
+[《Linux 命令大全 —— su 命令》](http://man.linuxde.net/su)
+
+- su 命令用于切换用户账号，超级用户使用这个命令可以切换到任何其他用户而不用输入密码：`su - USERNAME` 。
+
+- 用另外一个用户名执行一个命令下面的示例中用户 john 使用 raj 用户名执行 ls 命令，执行完后返回 john 的账号：
+
+  ```
+  [john@dev-server]$ su - raj -c 'ls'
+  
+  [john@dev-server]$
+  ```
+
+- 用指定用户登录，并且使用指定的 shell 程序，而不用默认的：`su -s 'SHELLNAME' USERNAME` 。
+
+### yum 命令
+
+[《Linux 命令大全 —— yum 命令》](http://man.linuxde.net/yum)
+
+- 使用 yum 安装 apache ：`yum install httpd` 。
+- 更新 apache ：`yum update httpd` 。
+- 卸载/删除 apache ：`yum remove httpd` 。
+
+### rpm 命令
+
+[《Linux 命令大全 —— rpm 命令》](http://man.linuxde.net/rpm)
+
+- 使用 rpm 安装 apache ：`rpm -ivh httpd-2.2.3-22.0.1.el5.i386.rpm` 。
+- 更新 apache ：`rpm -uvh httpd-2.2.3-22.0.1.el5.i386.rpm` 。
+- 卸载/删除 apache ：`rpm -ev httpd` 。
+
+### shutdown 命令
+
+[《Linux 命令大全 —— shutdown 命令》](http://man.linuxde.net/shutdown)
+
+- 关闭系统并立即关机：`shutdown -h now` 。
+- 10 分钟后关机：`shutdown -h +10` 。
+- 重启：`shutdown -r now` 。
+- 重启期间强制进行系统检查：`shutdown -Fr now` 。
+
+### crontab 命令
+
+[《Linux 命令大全 —— crontab 命令》](http://man.linuxde.net/crontab)
+
+- 查看某个用户的 crontab 配置：`crontab -u user -l` 。
+- 设置一个每十分钟执行一次的计划任务：`*/10 * * * * /home/ramesh/check-disk-space` 。【前提是，在 crontab 下】
+
+### service 命令
+
+[《Linux 命令大全 —— service 命令》](http://man.linuxde.net/service)
+
+- service 命令用于运行 System V init 脚本，这些脚本一般位于 `/etc/init.d` 文件下，这个命令可以直接运行这个文件夹里面的脚本，而不用加上路径。
+- 查看服务状态：`service ssh status` 。
+- 查看所有服务状态：`service --status-all` 。
+- 重启服务：`service ssh restart` 。
+
+另外，使用 chkconfig 命令，可以设置服务在系统启动时，是否自动启动。详细的，见 [《Linux 命令大全 —— chkconfig 命令》](http://man.linuxde.net/chkconfig) 文章。
+
+### chmod 命令
+
+[《Linux 命令大全 —— chmod 命令》](http://man.linuxde.net/chmod)
+
+- chmod 用于改变文件和目录的权限。
+- 给指定文件的属主和属组所有权限(包括读、写、执行)：`chmod ug+rwx file.txt` 。
+- 删除指定文件的属组的所有权限：`chmod g-rwx file.txt` 。
+- 修改目录的权限，以及递归修改目录下面所有文件和子目录的权限：`chmod -R ug+rwx file.txt` 。
+
+### chown 命令
+
+[《Linux 命令大全 —— chown 命令》](http://man.linuxde.net/chown)
+
+- chown 用于改变文件属主和属组。
+- 同时将某个文件的属主改为 oracle ，属组改为 db ：`chown oracle:dba dbora.sh` 。
+- 使用 `-R` 选项对目录和目录下的文件进行递归修改：`chown -R oracle:dba /home/oracle` 。
+
+### uname 命令
+
+[《Linux 命令大全 —— uname 命令》](http://man.linuxde.net/uname)
+
+- uname 可以显示一些重要的系统信息，例如内核名称、主机名、内核版本号、处理器类型之类的信息：`uname -a` 。
+
+### whereis 命令
+
+[《Linux 命令大全 —— whereis 命令》](http://man.linuxde.net/whereis)
+
+- 当你不知道某个命令的位置时可以使用 whereis 命令，下面使用 whereis 查找 ls 的位置：`whereis ls` 。
+- 当你想查找某个可执行程序的位置，但这个程序又不在 whereis 的默认目录下，你可以使用 `-B` 选项，并指定目录作为这个选项的参数。下面的命令在 `/tmp` 目录下查找 lsmk 命令：`whereis -u -B /tmp -f lsmk` 。
+
+### locate 命令
+
+[《Linux 命令大全 —— locate 命令》](http://man.linuxde.net/locate)
+
+- locate 命名可以显示某个指定文件（或一组文件）的路径，它会使用由 updatedb 创建的数据库。
+- 下面的命令会显示系统中所有包含 crontab 字符串的文件：`locate crontab` 。
+
+另外，胖友如果使用 CentOS 找不到 locate 命令，可以看看 [《CentOS 系统找到 locate 命令及 locate 搜索不到存在的文件》](https://blog.csdn.net/u014800380/article/details/72476026) 文章。
+
+### man 命令
+
+[《Linux 命令大全 —— man 命令》](http://man.linuxde.net/man)
+
+- 显示某个命令的 man 页面：`man crontab` 。
+
+- 些命令可能会有多个 ma n页面，每个 man 页面对应一种命令类型：`man SECTION-NUMBER commandname` 。
+
+- 命令类型：
+
+  - man 页面一般可以分为 8 种命令类型。
+
+    - 1. 用户命令
+    - 1. 系统调用
+    - 1. c 库函数
+    - 1. 设备与网络接口
+    - 1. 文件格式
+    - 1. 游戏与屏保
+    - 1. 环境、表、宏
+    - 1. 系统管理员命令和后台运行命令
+
+  - 例如，我们执行 `whatis crontab` ，你可以看到 crontab 有两个命令类型 1 和 5 ，所以我们可以通过下面的命令查看命令类型 5 的 man 页面：
+
+    ```
+    $ whatis crontab
+    crontab (1)          - maintain crontab files for individual users (V3)
+    crontab (5)          - tables for driving cron
+    
+    $ man 5 crontab
+    ```
+
+## 网络相关
+
+### ifconfig 命令
+
+[《Linux 命令大全 —— ifconfig 命令》](http://man.linuxde.net/ifconfig)
+
+- ifconfig 用于查看和配置 Linux 系统的网络接口。
+- 查看所有网络接口及其状态：`ifconfig -a` 。
+- 使用 up 和 down 命令启动或停止某个接口：`ifconfig eth0 up` 和 `ifconfig eth0 down` 。
+
+🦅 **用一条命令显示本机 eth0 网卡的 IP 地址，不显示其它字符？**
+
+- 输入命令任一一个命令即可：
+
+  ```
+  # 方法一：
+  ifconfig eth0|grep inet|awk -F ':' '{print $2}'|awk '{print $1}'
+  # 方法二
+  ifconfig eth0|grep "inet addr"|awk -F '[ :]+' '{print $4}' 
+  # 方法三：
+  ifconfig eth0|awk -F '[ :]+' 'NR==2 {print $4}' 
+  # 方法四：
+  ifconfig eth0|sed -n '2p'|sed 's#^.*addr:##g'|sed 's# Bc.*$##g'
+  # 方法五：
+  ifconfig eth0|sed -n '2p'|sed -r 's#^.*addr:(.*)  Bc.*$#\1#g'
+  # 方法六(CENTOS7 也适用)：
+  ip addr|grep eth0|grep inet|awk '{print $2}'|awk -F '/' '{print $1}'
+  ```
+
+### ping 命令
+
+[《Linux 命令大全 —— ping 命令》](http://man.linuxde.net/ping)
+
+- ping 一个远程主机，只发 5 个数据包：`ping -c 5 gmail.com` 。
+
+🦅 **如何禁止服务器被 ping ？**
+
+```
+[root@node0 ~]# echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_all  // 这个时候，别人是可以 ping 通自己的
+[root@node1 ~]# ping 192.168.6.6
+PING 192.168.6.6 (192.168.6.6) 56(84) bytes of data.
+64 bytes from 192.168.6.6: icmp_seq=1 ttl=64 time=1.79 ms
+64 bytes from 192.168.6.6: icmp_seq=2 ttl=64 time=0.597 ms
+
+[root@node0 ~]# echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
+[root@node1 ~]# ping 192.168.6.6    // ping 不能了
+PING 192.168.6.6 (192.168.6.6) 56(84) bytes of data.
+--- 192.168.6.6 ping statistics ---
+93 packets transmitted, 0 received, 100% packet loss, time 92168ms
+```
+
+### curl 命令
+
+[《Linux 命令大全 —— curl 命令》](http://man.linuxde.net/curl)
+
+如果我们使用 ping 测试某个地址是否能连接，那么 curl 测试用个 URL 是否可以访问。
+
+🦅 **写出一个 curl 命令，访问指定服务器 `61.135.169.121` 上的如下 URL ：`http://www.baidu.com/s?wd=test` ，访问的超时时间是 20 秒**
+
+- 输入命令 `curl --connect-timeout 20 http://61.135.169.121/s?wd=test` 。
+
+### wget 命令
+
+[《Linux 命令大全 —— wget 命令》](http://man.linuxde.net/wget)
+
+- 使用 wget 从网上下载软件、音乐、视频：`wget http://prdownloads.sourceforge.net/sourceforge/nagios/nagios-3.2.1.tar.gz` 。
+- 下载文件并以指定的文件名保存文件：`wget -O taglist.zip http://www.vim.org/scripts/download_script.php?src_id=7701` 。
+
+### ftp 命令
+
+[《Linux 命令大全 —— ftp 命令》](http://man.linuxde.net/ftp)
+
+- ftp 命令和 sftp 命令的用法基本相似。
+
+- 连接 ftp 服务器并下载多个文件：
+
+  ```
+  $ ftp IP/hostname
+  ftp> mget *.html
+  ```
+
+- 显示远程主机上文件列表：
+
+  ```
+  ftp> mls *.html -
+  /ftptest/features.html
+  /ftptest/index.html
+  /ftptest/othertools.html
+  /ftptest/samplereport.html
+  /ftptest/usage.html
+  ```
+
+### ssh 命令
+
+[《Linux 命令大全 —— ssh 命令》](http://man.linuxde.net/ssh)
+
+- 登录到远程主机：`ssh username@remotehost.example.com` 。
+- 显示 ssh 客户端版本：`ssh -V` 。
+
+\##【重要】服务器状态相关
+
+通过如下命令，我们可以知道 Linux 服务器运行情况，从而可以排查性能的情况。
+
+因为我们是每小节一个命令，胖友后面可以看看 [《Linux 性能分析工具介绍（CPU，内存，磁盘 I/O，网络）》](https://blog.csdn.net/ZYC88888/article/details/79028175) 文章，它将本小节的命令，又做了一次归类，和介绍。所以，可以结合着一起读读。
+
+### ps 命令
+
+[《Linux 命令大全 —— ps 命令》](http://man.linuxde.net/ps)
+
+- ps 命令用于显示正在运行中的进程的信息。
+- 查看当前正在运行的所有进程：`ps -ef | more` 。
+- 以树状结构显示当前正在运行的进程，H 选项表示显示进程的层次结构：`ps -efH | more` 。
+
+🦅 **查看后台所有 java 进程？**
+
+- 方式一：`ps -ef |grep java` 。
+- 方式二：`jps -m` 。
+
+### uptime 命令
+
+[《Linux 命令大全 —— uptime 命令》](http://man.linuxde.net/uptime)
+
+[![uptime](22-Linux 面试题.assets/64991a70b828228d02ec18bc722ed10f.jpeg)](http://static.iocoder.cn/64991a70b828228d02ec18bc722ed10f)uptime
+
+这个命令可以快速查看机器的负载情况。在 Linux 系统中，这些数据表示等待 CPU 资源的进程和阻塞在不可中断 IO 进程（进程状态为 D）的数量。这些数据可以让我们对系统资源使用有一个宏观的了解。
+
+命令的输出分别表示 1 分钟、5 分钟、15 分钟的平均负载情况。通过这三个数据，可以了解服务器负载是在趋于紧张还是趋于缓解。
+
+- 如果 1 分钟平均负载很高，而 15 分钟平均负载很低，说明服务器正在命令高负载情况，需要进一步排查 CPU 资源都消耗在了哪里。
+- 反之，如果 15 分钟平均负载很高，1 分钟平均负载较低，则有可能是 CPU 资源紧张时刻已经过去。
+- 上面例子中的输出，可以看见最近 1 分钟的平均负载非常高，且远高于最近 15 分钟负载，因此我们需要继续排查当前系统中有什么进程消耗了大量的资源。可以通过下文将会介绍的 vmstat、mpstat 等命令进一步排查。
+
+另外，还有一个 [《Linux 命令大全 —— w 命令》](http://man.linuxde.net/w) ，也是使用比较方便的，快速查看系统负载情况的命令。
+
+### dmesg 命令
+
+[《Linux 命令大全 —— dmesg 命令》](http://man.linuxde.net/dmesg)
+
+[![dmesg](http://static.iocoder.cn/b1e0efa3199c1dad93db3f69de812e7d)](http://static.iocoder.cn/b1e0efa3199c1dad93db3f69de812e7d)dmesg
+
+该命令会输出系统日志的最后 10 行。示例中的输出，可以看见一次内核的 oom kill 和一次 TCP 丢包。这些日志可以帮助排查性能问题。千万不要忘了这一步。
+
+### vmstat 命令
+
+[《Linux 命令大全 —— vmstat 命令》](http://man.linuxde.net/vmstat)
+
+[![vmstat](http://static.iocoder.cn/cb2d25b03441be2a1c068e336390b895)](http://static.iocoder.cn/cb2d25b03441be2a1c068e336390b895)vmstat
+
+vmstat 命令，每行会输出一些系统核心指标，这些指标可以让我们更详细的了解系统状态。后面跟的参数 1 ，表示每秒输出一次统计信息，表头提示了每一列的含义，这几介绍一些和性能调优相关的列：
+
+- r：等待在 CPU 资源的进程数。这个数据比平均负载更加能够体现 CPU 负载情况，数据中不包含等待 IO 的进程。如果这个数值大于机器 CPU 核数，那么机器的 CPU 资源已经饱和。
+- free：系统可用内存数（以千字节为单位），如果剩余内存不足，也会导致系统性能问题。下文介绍到的 free 命令，可以更详细的了解系统内存的使用情况。
+- si，so：交换区写入和读取的数量。如果这个数据不为 0 ，说明系统已经在使用交换区（swap），机器物理内存已经不足。
+- us, sy, id, wa, st：这些都代表了 CPU 时间的消耗，它们分别表示用户时间(user)、系统（内核）时间(sys)、空闲时间(idle)、IO等待时间(wait)和被偷走的时间(stolen，一般被其他虚拟机消耗)。
+
+上述这些 CPU 时间，可以让我们很快了解 CPU 是否处于繁忙状态。一般情况下，如果用户时间和系统时间相加非常大，CPU 出于忙于执行指令。如果IO等待时间很长，那么系统的瓶颈可能在磁盘 IO 。
+
+示例命令的输出可以看见，大量 CPU 时间消耗在用户态，也就是用户应用程序消耗了 CPU 时间。这不一定是性能问题，需要结合 r 队列，一起分析。
+
+### mpstat 命令
+
+[![mpstat](http://static.iocoder.cn/8c61ee5a2a59b6fb2de4edd893cb7412)](http://static.iocoder.cn/8c61ee5a2a59b6fb2de4edd893cb7412)mpstat
+
+该命令可以显示每个 CPU 的占用情况，如果有一个 CPU 占用率特别高，那么有可能是一个单线程应用程序引起的。
+
+### pidstat 命令
+
+[![pidstat](http://static.iocoder.cn/21cb3c25dac3045e9392a55906c581e4)](http://static.iocoder.cn/21cb3c25dac3045e9392a55906c581e4)pidstat
+
+pidstat 命令输出进程的 CPU 占用率，该命令会持续输出，并且不会覆盖之前的数据，可以方便观察系统动态。如上的输出，可以看见两个 JAVA 进程占用了将近 1600% 的CPU时间，既消耗了大约 16 个 CPU 核心的运算资源。
+
+### iostat 命令
+
+[![iostat](http://static.iocoder.cn/7cf02db233d20982427c0799c713fb32)](http://static.iocoder.cn/7cf02db233d20982427c0799c713fb32)iostat
+
+- r/s, w/s, rkB/s, wkB/s：分别表示每秒读写次数和每秒读写数据量（千字节）。读写量过大，可能会引起性能问题。
+- await：IO 操作的平均等待时间，单位是毫秒。这是应用程序在和磁盘交互时，需要消耗的时间，包括 IO 等待和实际操作的耗时。如果这个数值过大，可能是硬件设备遇到了瓶颈或者出现故障。
+- avgqu-sz：向设备发出的请求平均数量。如果这个数值大于 1 ，可能是硬件设备已经饱和（部分前端硬件设备支持并行写入）。
+- %util：设备利用率。这个数值表示设备的繁忙程度，经验值是如果超过 60 ，可能会影响 IO 性能（可以参照 IO 操作平均等待时间）。如果到达 100% ，说明硬件设备已经饱和。
+
+如果显示的是逻辑设备的数据，那么设备利用率不代表后端实际的硬件设备已经饱和。值得注意的是，即使 IO 性能不理想，也不一定意味这应用程序性能会不好，可以利用诸如预读取、写缓存等策略提升应用性能。
+
+### free 命令
+
+[《Linux 命令大全 —— free 命令》](http://man.linuxde.net/free)
+
+[![free](http://static.iocoder.cn/c6afc22251bafccf163d532c1e96b7f2)](http://static.iocoder.cn/c6afc22251bafccf163d532c1e96b7f2)free
+
+free 命令可以查看系统内存的使用情况，`-m` 参数表示按照兆字节展示。最后两列分别表示用于IO缓存的内存数，和用于文件系统页缓存的内存数。需要注意的是，第二行 `-/+ buffers/cache` ，看上去缓存占用了大量内存空间。
+
+这是 Linux 系统的内存使用策略，尽可能的利用内存，如果应用程序需要内存，这部分内存会立即被回收并分配给应用程序。因此，这部分内存一般也被当成是可用内存。
+
+如果可用内存非常少，系统可能会动用交换区(如果配置了的话)，这样会增加 IO 开销(可以在 iostat 命令中体现)，降低系统性能。
+
+🦅 **【重要】Linux系统里，您知道 buffer 和 cache 如何区分吗？**
+
+Buffer 和 Cache 都是内存中的一块区域。
+
+- 当 CPU 需要写数据到磁盘时，由于磁盘速度比较慢，所以 CPU 先把数据存进 Buffer ，然后 CPU 去执行其他任务，Buffer中的数据会定期写入磁。
+- 当 CPU 需要从磁盘读入数据时，由于磁盘速度比较慢，可以把即将用到的数据提前存入 Cache ，CPU 直接从 Cache中 拿数据要快的多。
+
+详细的，可以看看 [《Linux中 buffer/cache、swap、虚拟内存和Page》](https://blog.csdn.net/cymm_liu/article/details/8228828) 。
+
+### sar 命令
+
+[《Linux 命令大全 —— sar 命令》](http://man.linuxde.net/sar)
+
+[![sar 设备](http://static.iocoder.cn/a32adc09e567efe7ca9ab0d7e77c22ce)](http://static.iocoder.cn/a32adc09e567efe7ca9ab0d7e77c22ce)sar 设备
+
+- sar 命令在这里可以查看网络设备的吞吐率。在排查性能问题时，可以通过网络设备的吞吐量，判断网络设备是否已经饱和。如示例输出中，eth0 网卡设备，吞吐率大概在 22 Mbytes/s ，既 176 Mbits/sec ，没有达到 1Gbit/sec 的硬件上限。
+
+[![sar TCP](http://static.iocoder.cn/c47f9cf21355ced275d4c1dadc254b21)](http://static.iocoder.cn/c47f9cf21355ced275d4c1dadc254b21)sar TCP
+
+- sar命令在这里用于查看 TCP 连接状态，其中包括：
+  - active/s：每秒本地发起的TCP连接数，既通过connect调用创建的TCP连接；
+  - passive/s：每秒远程发起的TCP连接数，即通过accept调用创建的TCP连接；
+  - retrans/s：每秒TCP重传数量；
+
+TCP 连接数可以用来判断性能问题是否由于建立了过多的连接，进一步可以判断是主动发起的连接，还是被动接受的连接。TCP 重传可能是因为网络环境恶劣，或者服务器压力。
+
+🦅 **我们可以使用哪个命令查看系统的历史负载（比如说两天前的）？**
+
+```
+sar -q -f /var/log/sa/sa22 # 查看 22 号的系统负载
+```
+
+### top 命令
+
+[《Linux 命令大全 —— top 命令》](http://man.linuxde.net/top)
+
+[![top](http://static.iocoder.cn/27d6182eb0d582a975870534368a436b)](http://static.iocoder.cn/27d6182eb0d582a975870534368a436b)top
+
+top 命令包含了前面好几个命令的检查的内容。比如系统负载情况（uptime）、系统内存使用情况（free）、系统 CPU 使用情况（vmstat）等。因此通过这个命令，可以相对全面的查看系统负载的来源。同时，top 命令支持排序，可以按照不同的列排序，方便查找出诸如内存占用最多的进程、CPU占用率最高的进程等。
+
+但是，top 命令相对于前面一些命令，输出是一个瞬间值，如果不持续盯着，可能会错过一些线索。这时可能需要暂停 top 命令刷新，来记录和比对数据。
+
+### netstat 命令
+
+[《Linux 命令大全 —— netstat 命令》](http://man.linuxde.net/netstat)
+
+🦅 **如何查看系统都开启了哪些端口？**
+
+```
+[root@centos6 ~ 13:20 #55]# netstat -lnp
+Active Internet connections (only servers)
+Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name
+tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN      1035/sshd
+tcp        0      0 :::22                       :::*                        LISTEN      1035/sshd
+udp        0      0 0.0.0.0:68                  0.0.0.0:*                               931/dhclient
+Active UNIX domain sockets (only servers)
+Proto RefCnt Flags       Type       State         I-Node PID/Program name    Path
+unix  2      [ ACC ]     STREAM     LISTENING     6825   1/init              @/com/ubuntu/upstart
+unix  2      [ ACC ]     STREAM     LISTENING     8429   1003/dbus-daemon    /var/run/dbus/system_bus_socket
+```
+
+🦅 **如何查看网络连接状况？**
+
+```
+[root@centos6 ~ 13:22 #58]# netstat -an
+Active Internet connections (servers and established)
+Proto Recv-Q Send-Q Local Address               Foreign Address             State
+tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN
+tcp        0      0 192.168.147.130:22          192.168.147.1:23893         ESTABLISHED
+tcp        0      0 :::22                       :::*                        LISTEN
+udp        0      0 0.0.0.0:68                  0.0.0.0:*
+
+// ... 省略其它
+```
+
+🦅 **如何统计系统当前进程连接数？**
+
+- 输入命令 `netstat -an | grep ESTABLISHED | wc -l` 。
+- 输出结果 `177` 。一共有 177 连接数。
+
+🦅 **用 netstat 命令配合其他命令，按照源 IP 统计所有到 80 端口的 ESTABLISHED 状态链接的个数？**
+
+> 严格来说，这个题目考验的是对 awk 的使用。
+
+- 首先，使用 `netstat -an|grep ESTABLISHED` 命令。结果如下：
+
+  ```
+  tcp        0      0 120.27.146.122:80       113.65.18.33:62721      ESTABLISHED
+  tcp        0      0 120.27.146.122:80       27.43.83.115:47148      ESTABLISHED
+  tcp        0      0 120.27.146.122:58838    106.39.162.96:443       ESTABLISHED
+  tcp        0      0 120.27.146.122:52304    203.208.40.121:443      ESTABLISHED
+  tcp        0      0 120.27.146.122:33194    203.208.40.122:443      ESTABLISHED
+  tcp        0      0 120.27.146.122:53758    101.37.183.144:443      ESTABLISHED
+  tcp        0      0 120.27.146.122:27017    23.105.193.30:50556     ESTABLISHED
+  
+  // ... 省略其它
+  ```
+
+- 然后，进一步修改命令，使用 `netstat -an|grep ESTABLISHED|grep ":80"|awk 'BEGIN{FS="[[:space:]:]+"}{print $4}'` 命令。结果如下：
+
+  ```
+  120.27.146.122
+  120.27.146.122
+  120.27.146.122
+  120.27.146.122
+  120.27.146.122
+  120.27.146.122
+  120.27.146.122
+  120.27.146.122
+  120.27.146.122
+  120.27.146.122
+  120.27.146.122
+  120.27.146.122
+  120.27.146.122
+  120.27.146.122
+  120.27.146.122
+  120.27.146.122
+  10.47.111.216
+  
+  // ... 省略其它
+  ```
+
+  - 说明：`FS` 是字段分隔符，简单的可以用多个 awk 过滤。
+
+- 最后，再进一步修改命令，使用 `netstat -an|grep ESTABLISHED|grep ":80"|awk 'BEGIN{FS="[[:space:]:]+"}{print $4}'|sort|uniq -c|sort -nr` 命令。结果如下：
+
+  ```
+  47 120.27.146.122
+   1 10.47.111.216
+  ```
+
+  - 第一列为连接数，第二列为 IP 。
+
+> 虽然我们这里罗列了很多的命令，下面，还是会有其它命令。
+
+# Linux 概述
+
+## Linux 的体系结构
+
+从大的方面讲，Linux 体系结构可以分为两块：[Linux 体系结构](https://img-blog.csdn.net/20170401170616835?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvd2VpeGluXzM2Mzk3MTQx/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast)
+
+- 用户空间(User Space) ：用户空间又包括用户的应用程序(User Applications)、C 库(C Library) 。
+- 内核空间(Kernel Space) ：内核空间又包括系统调用接口(System Call Interface)、内核(Kernel)、平台架构相关的代码(Architecture-Dependent Kernel Code) 。
+
+🦅 **为什么 Linux 体系结构要分为用户空间和内核空间的原因？**
+
+- 1、现代 CPU 实现了不同的工作模式，不同模式下 CPU 可以执行的指令和访问的寄存器不同。
+- 2、Linux 从 CPU 的角度出发，为了保护内核的安全，把系统分成了两部分。
+
+用户空间和内核空间是程序执行的**两种不同的状态**，我们可以通过两种方式完成用户空间到内核空间的转移：1）系统调用；2）硬件中断。
+
+## 什么是 Linux 内核？
+
+> 了解即可。
+
+Linux 系统的核心是内核。内核控制着计算机系统上的所有硬件和软件，在必要时分配硬件，并根据需要执行软件。
+
+1. 系统内存管理
+2. 应用程序管理
+3. 硬件设备管理
+4. 文件系统管理
+
+详细的，可以看看 [《是时候深入了解 Linux 的系统结构了》](https://juejin.im/post/5a391e146fb9a045167d5255) 。
+
+## Linux 开机启动过程？
+
+> 了解即可。
+
+- 1、主机加电自检，加载 BIOS 硬件信息。
+
+- 2、读取 MBR 的引导文件(GRUB、LILO)。
+
+  > 艿艿：比较“闲”的胖友，可以感兴趣看看 [《引导加载程序之争：了解 LILO 和 GRUB》](https://www.ibm.com/developerworks/cn/linux/l-bootload.html) 文章。
+
+- 3、引导 Linux 内核。
+
+- 4、运行第一个进程 init (进程号永远为 1 )。
+
+- 5、进入相应的运行级别。
+
+- 6、运行终端，输入用户名和密码。
+
+🦅 **Linux系 统缺省的运行级别？**
+
+- 1. 关机。
+- 1. 单机用户模式。
+- 1. 字符界面的多用户模式(不支持网络)。
+- 1. 字符界面的多用户模式。
+- 1. 未分配使用。
+- 1. 图形界面的多用户模式。
+- 1. 重启。
+
+## Linux 使用的进程间通信方式？
+
+> 了解即可，不需要太深入。
+
+- 1、管道(pipe)、流管道(s_pipe)、有名管道(FIFO)。
+- 2、信号(signal) 。
+- 3、消息队列。
+- 4、共享内存。
+- 5、信号量。
+- 6、套接字(socket) 。
+
+详细的，可以看看：
+
+- [《Linux 进程间通信的几种方式总结 —— linux 内核剖析（七）》](https://blog.csdn.net/gatieme/article/details/50908749)
+- [《目前 Linux 进程间通信的常用方法是什么(pipe？信号量？消息队列？)?》](https://www.zhihu.com/question/23995948)
+
+## Linux 有哪些系统日志文件？
+
+参见 [《Linux 系统日志及日志分析》](http://c.biancheng.net/cpp/html/2783.html) 文章，比较重要的是 `/var/log/messages` 日志文件。
+
+> 该日志文件是许多进程日志文件的汇总，从该文件可以看出任何入侵企图或成功的入侵。
+>
+> 另外，如果胖友的系统里有 ELK 日志集中收集，它也会被收集进去。
+
+## Linux 虚拟内存是什么？
+
+> 艿艿：选读，面试不问。作为一个知识点，比较底层~
+
+直接看 [《虚拟内存的那点事儿》](https://juejin.im/post/59f8691b51882534af254317) 文章。
+
+# 磁盘、目录、文件
+
+## 简单 Linux 文件系统？
+
+**在 Linux 操作系统中，所有被操作系统管理的资源，例如网络接口卡、磁盘驱动器、打印机、输入输出设备、普通文件或是目录都被看作是一个文件。**
+
+也就是说在 Linux 系统中有一个重要的概念：**一切都是文件**。其实这是 Unix 哲学的一个体现，而 Linux 是重写 Unix 而来，所以这个概念也就传承了下来。在 Unix 系统中，把一切资源都看作是文件，包括硬件设备。UNIX系统把每个硬件都看成是一个文件，通常称为设备文件，这样用户就可以用读写文件的方式实现对硬件的访问。
+
+Linux 支持 5 种文件类型，如下图所示：[![文件类型](http://static.iocoder.cn/b6865417dd1245e4f3c4ba877ce9c5aa)](http://static.iocoder.cn/b6865417dd1245e4f3c4ba877ce9c5aa)文件类型
+
+## Linux 的目录结构是怎样的？
+
+> 艿艿：这个问题，一般不会问。更多是实际使用时，需要知道。
+
+Linux 文件系统的结构层次鲜明，就像一棵倒立的树，最顶层是其根目录：
+[![Linux的目录结构](http://static.iocoder.cn/5c2f54f28d4eabbe138fd8cbb763a1f1)](http://static.iocoder.cn/5c2f54f28d4eabbe138fd8cbb763a1f1)Linux的目录结构
+
+**常见目录说明：**
+
+- **/bin：** 存放二进制可执行文件(ls,cat,mkdir等)，常用命令一般都在这里；
+- **/etc：** 存放系统管理和配置文件；
+- **/home：** 存放所有用户文件的根目录，是用户主目录的基点，比如用户user的主目录就是/home/user，可以用~user表示；
+- **/usr ：** 用于存放系统应用程序；
+- **/opt：** 额外安装的可选应用程序包所放置的位置。一般情况下，我们可以把tomcat等都安装到这里；
+- **/proc：** 虚拟文件系统目录，是系统内存的映射。可直接访问这个目录来获取系统信息；
+- **/root：** 超级用户（系统管理员）的主目录（特权阶级^o^）；
+- **/sbin:** 存放二进制可执行文件，只有root才能访问。这里存放的是系统管理员使用的系统级别的管理命令和程序。如ifconfig等；
+- **/dev：** 用于存放设备文件；
+- **/mnt：** 系统管理员安装临时文件系统的安装点，系统提供这个目录是让用户临时挂载其他的文件系统；
+- **/boot：** 存放用于系统引导时使用的各种文件；
+- **/lib ：** 存放着和系统运行相关的库文件 ；
+- **/tmp：** 用于存放各种临时文件，是公用的临时文件存储点；
+- **/var：** 用于存放运行时需要改变数据的文件，也是某些大文件的溢出区，比方说各种服务的日志文件（系统启动日志等。）等；
+- **/lost+found：** 这个目录平时是空的，系统非正常关机而留下“无家可归”的文件（windows下叫什么.chk）就在这里。
+
+## 什么是 inode ？
+
+> 艿艿：一般来说，面试不会问 inode 。但是 inode 是一个重要概念，是理解 Unix/Linux 文件系统和硬盘储存的基础。
+
+查看 [《理解 inode》](http://www.ruanyifeng.com/blog/2011/12/inode.html) 文章。
+
+- [《缺页中断 —— FIFO、LRU、OPT 这三种置换算法》](https://blog.csdn.net/u011080472/article/details/51206332) 。
+
+🦅 **简述 Linux 文件系统通过 i 节点把文件的逻辑结构和物理结构转换的工作过程？**
+
+> 如果看的一脸懵逼，也没关系。一般来说，面试官不太会问这个题目。
+
+Linux 通过 inode 节点表将文件的逻辑结构和物理结构进行转换。
+
+- inode 节点是一个 64 字节长的表，表中包含了文件的相关信息，其中有文件的大小、文件所有者、文件的存取许可方式以及文件的类型等重要信息。在 inode 节点表中最重要的内容是磁盘地址表。在磁盘地址表中有 13 个块号，文件将以块号在磁盘地址表中出现的顺序依次读取相应的块。
+- Linux 文件系统通过把 inode 节点和文件名进行连接，当需要读取该文件时，文件系统在当前目录表中查找该文件名对应的项，由此得到该文件相对应的 inode 节点号，通过该 inode 节点的磁盘地址表把分散存放的文件物理块连接成文件的逻辑结构。
+
+## 什么是硬链接和软链接？
+
+1）硬链接
+
+由于 Linux 下的文件是通过索引节点(inode)来识别文件，硬链接可以认为是一个指针，指向文件索引节点的指针，系统并不为它重新分配 inode 。每添加一个一个硬链接，文件的链接数就加 1 。
+
+- 不足：1）不可以在不同文件系统的文件间建立链接；2）只有超级用户才可以为目录创建硬链接。
+
+2）软链接
+
+软链接克服了硬链接的不足，没有任何文件系统的限制，任何用户可以创建指向目录的符号链接。因而现在更为广泛使用，它具有更大的灵活性，甚至可以跨越不同机器、不同网络对文件进行链接。
+
+- 不足：因为链接文件包含有原文件的路径信息，所以当原文件从一个目录下移到其他目录中，再访问链接文件，系统就找不到了，而硬链接就没有这个缺陷，你想怎么移就怎么移；还有它要系统分配额外的空间用于建立新的索引节点和保存原文件的路径。
+
+😈 **实际场景下，基本是使用软链接**。详细的，胖友可以看看 [《关于硬链接和软连接（符号链接）的区别》](https://blog.csdn.net/hairetz/article/details/4168296) 。总结区别如下：
+
+- 硬链接不可以跨分区，软件链可以跨分区。
+- 硬链接指向一个 inode 节点，而软链接则是创建一个新的 inode 节点。
+- 删除硬链接文件，不会删除原文件，删除软链接文件，会把原文件删除。
+
+## RAID 是什么?
+
+> RAID 全称为独立磁盘冗余阵列(Redundant Array of Independent Disks)，基本思想就是把多个相对便宜的硬盘组合起来，成为一个硬盘阵列组，使性能达到甚至超过一个价格昂贵、 容量巨大的硬盘。RAID 通常被用在服务器电脑上，使用完全相同的硬盘组成一个逻辑扇区，因此操作系统只会把它当做一个硬盘。
+>
+> RAID 分为不同的等级，各个不同的等级均在数据可靠性及读写性能上做了不同的权衡。在实际应用中，可以依据自己的实际需求选择不同的 RAID 方案。
+
+详细的，胖友可以看看 [《RAID 技术介绍和总结》](http://blog.jobbole.com/83808/) 。当然，因为很多公司都使用云服务，大家很难接触到 RAID 这个概念，更多的可能是普通云盘、SSD 云盘酱紫的概念。
+
+# 网络
+
+## iptables 命令
+
+iptables ，是一个配置 Linux 内核防火墙的命令行工具。功能非常强大，对于我们开发来说，主要掌握如何开放端口即可。例如：
+
+- 把来源 IP 为 192.168.1.101 访问本机 80 端口的包直接拒绝：`iptables -I INPUT -s 192.168.1.101 -p tcp --dport 80 -j REJECT` 。
+
+- 开启 80 端口，因为web对外都是这个端口
+
+  ```
+  iptables -A INPUT -p tcp --dport 80 -j ACCEP
+  ```
+
+- 另外，要注意使用 `iptables save` 命令，进行保存。否则，服务器重启后，配置的规则将丢失。
+
+详细的，可以看看：
+
+- [《Linux 命令大全 —— iptables 命令》](http://man.linuxde.net/iptables)
+- [《Linux 面试经历：iptables 面试题》](http://www.manongjc.com/article/39191.html)
+- [《百度 Linux 运维防火墙 iptables 的面试题》](https://idc.wanyunshuju.com/yunwei/571.html)
+- [《奇虎 360 Linux 运维工程师 iptables 防火墙面试题》](https://idc.wanyunshuju.com/yunwei/462.html)
+
+## route 命令
+
+[《Linux 命令大全 —— route 命令》](http://man.linuxde.net/route)
+
+🦅 **添加一条到 `192.168.3.0/24` 的路由，网关为 `192.168.1.254` ？**
+
+- 输入命令 `route add -net 192.168.3.0/24 netmask 255.255.255.0 gw 192.168.1.254` 。
+
+🦅 **查看本机路由的三种方式？**
+
+```
+[root@centos6 ~]# route -n
+Kernel IP routing table
+Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
+192.168.220.0   0.0.0.0         255.255.255.0   U     1      0        0 eth1
+169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0
+172.16.0.0      0.0.0.0         255.255.0.0     U     0      0        0 eth0
+0.0.0.0         172.16.0.1      0.0.0.0         UG    0      0        0 eth0
+
+[root@centos6 ~]# netstat -nr
+Kernel IP routing table
+Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
+192.168.220.0   0.0.0.0         255.255.255.0   U         0 0          0 eth1
+169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth0
+172.16.0.0      0.0.0.0         255.255.0.0     U         0 0          0 eth0
+0.0.0.0         172.16.0.1      0.0.0.0         UG        0 0          0 eth0
+
+[root@centos6 ~]#  ip route
+192.168.220.0/24 dev eth1  proto kernel  scope link  src 192.168.220.157  metric 1 
+169.254.0.0/16 dev eth0  scope link  metric 1002 
+172.16.0.0/16 dev eth0  proto kernel  scope link  src 172.16.251.6 
+default via 172.16.0.1 dev eth0  proto static
+```
+
+## tcpdump 命令
+
+[《Linux 命令大全 —— tcpdump 命令》](http://man.linuxde.net/tcpdump)
+
+🦅 **在 Linux 系统下如何按照下面要求抓包：只过滤出访问 HTTP 服务的，目标 IP 为 192.168.0.111 ，一共抓 1000 个包，并且保存到 1.cap 文件中？？**
+
+```
+tcpdump -nn -s0 host 192.168.0.111 and port 80 -c 1000 -w 1.cap
+```
+
+## 如何配置静态 IP ？
+
+参见文章 [《Linux 设置静态IP》](https://www.jianshu.com/p/33784a06c1a9) 。这是一个必备技能。
+
+🦅 **是否可以给一个网卡配置多个 IP？**
+
+可以，参见文章 [《Linux 下一个网卡配置多个 IP【虚拟ip】》](https://blog.csdn.net/turkeyzhou/article/details/16971225) 。不过，一般比较少这么做。更多的是，一台服务器有两个网卡，配置了两个不同的 IP 。
+
+🦅 **如何查看某个网卡是否连接着交换机？**
+
+> 艿艿：原来还有酱紫的命令！学习到新技能了。
+>
+> 不过阿里云不支持酱紫的操作。
+
+`mii-tool eth0` 或者 `mii-tool eth1` 。
+
+## 设置 DNS 需要修改哪个配置文件？
+
+- 全局的配置，可以在 `/etc/resolv.conf` 文件中配置。
+- 指定网卡的配置，可以在 `/etc/sysconfig/network-scripts/ifcfg-eth0` 文件中配置。
+- 一般来说，肯定是全局配置即可。
+
+🦅 **`/etc/hosts` 文件什么做用？**
+
+在 `/etc/hosts` 文中，我们可以配置指定域名和 IP 的映射关系。详细的，可以看看 [《Linux环境下 /etc/hosts 文件详解》](https://www.jianshu.com/p/476a92a39b45) 文章。
+
+🦅 **在 Linux 下如何指定dns服务器，来解析某个域名？**
+
+使用 dig 命令：`dig @DNSip http://domain.com` 。例如：
+
+```
+dig @8.8.8.8 www.baidu.com # 使用谷歌 DNS 解析百度
+```
+
+# 安全
+
+## 一台 Linux 系统初始化环境后需要做一些什么安全工作？
+
+- 1、添加普通用户登陆，禁止 root 用户登陆，更改 SSH 端口号。
+
+  > 修改 SSH 端口不一定绝对哈。当然，如果要暴露在外网，建议改下。
+
+- 2、服务器使用密钥登陆，禁止密码登陆。
+
+- 3、开启防火墙，关闭 SElinux ，根据业务需求设置相应的防火墙规则。
+
+- 4、装 fail2ban 这种防止 SSH 暴力破击的软件。
+
+- 5、设置只允许公司办公网出口 IP 能登陆服务器(看公司实际需要)
+
+  > 也可以安装 VPN 等软件，只允许连接 VPN 到服务器上。
+
+- 6、修改历史命令记录的条数为 10 条。
+
+- 7、只允许有需要的服务器可以访问外网，其它全部禁止。
+
+- 8、做好软件层面的防护。
+
+  - 8.1 设置 nginx_waf 模块防止 SQL 注入。
+  - 8.2 把 Web 服务使用 www 用户启动，更改网站目录的所有者和所属组为 www 。
+
+## 什么叫 CC 攻击？什么叫 DDOS 攻击？
+
+- CC 攻击，主要是用来攻击页面的，模拟多个用户不停的对你的页面进行访问，从而使你的系统资源消耗殆尽。
+
+- DDOS 攻击，中文名叫分布式拒绝服务攻击，指借助服务器技术将多个计算机联合起来作为攻击平台，来对一个或多个目标发动 DDOS 攻击。
+
+  > 攻击，即是通过大量合法的请求占用大量网络资源，以达到瘫痪网络的目的。
+
+🦅 **怎么预防 CC 攻击和 DDOS 攻击？**
+
+防 CC、DDOS 攻击，这些只能是用硬件防火墙做流量清洗，将攻击流量引入黑洞。
+
+> 流量清洗这一块，主要是买 ISP 服务商的防攻击的服务就可以，机房一般有空余流量，我们一般是买服务，毕竟攻击不会是持续长时间。
+>
+> 例如说，[《阿里云 —— DDoS 高防IP》](https://cn.aliyun.com/product/ddos) 。
+
+## 什么是网站数据库注入？
+
+- 由于程序员的水平及经验参差不齐，大部分程序员在编写代码的时候，没有对用户输入数据的合法性进行判断。
+- 应用程序存在安全隐患。用户可以提交一段数据库查询代码，根据程序返回的结果，获得某些他想得知的数据，这就是所谓的 SQL 注入。
+- SQL注入，是从正常的 WWW 端口访问，而且表面看起来跟一般的 Web 页面访问没什么区别，如果管理员没查看日志的习惯，可能被入侵很长时间都不会发觉。
+
+🦅 **如何过滤与预防？**
+
+数据库网页端注入这种，可以考虑使用 nginx_waf 做过滤与预防。
+
+# Shell
+
+> 艿艿：本小节为选读。我也不太会写 Shell 脚本，都是写的时候，在网络上拼拼凑凑。。。
+
+## Shell 脚本是什么？
+
+一个 Shell 脚本是一个文本文件，包含一个或多个命令。作为系统管理员，我们经常需要使用多个命令来完成一项任务，我们可以添加这些所有命令在一个文本文件(Shell 脚本)来完成这些日常工作任务。
+
+🦅 **什么是默认登录 Shell ？**
+
+在 Linux 操作系统，`"/bin/bash"` 是默认登录 Shell，是在创建用户时分配的。
+
+使用 chsh 命令可以改变默认的 Shell 。示例如下所示：
+
+```
+# chsh <用户名> -s <新shell>
+# chsh linuxtechi -s /bin/sh
+```
+
+🦅 **在 Shell 脚本中，如何写入注释？**
+
+注释可以用来描述一个脚本可以做什么和它是如何工作的。每一行注释以 `#` 开头。例子如下：
+
+```
+#!/bin/bash
+# This is a command
+echo “I am logged in as $USER”
+```
+
+## 语法级
+
+### 可以在 Shell 脚本中使用哪些类型的变量？
+
+在 Shell 脚本，我们可以使用两种类型的变量：
+
+- 系统定义变量
+
+  > 系统变量是由系统系统自己创建的。这些变量通常由大写字母组成，可以通过 `set` 命令查看。
+
+- 用户定义变量
+
+  > 用户变量由系统用户来生成和定义，变量的值可以通过命令 `"echo $<变量名>"` 查看。
+
+🦅 **Shell脚本中 `$?` 标记的用途是什么？**
+
+在写一个 Shell 脚本时，如果你想要检查前一命令是否执行成功，在 `if` 条件中使用 `$?` 可以来检查前一命令的结束状态。
+
+- 如果结束状态是 0 ，说明前一个命令执行成功。例如：
+
+  ```
+  root@localhost:~# ls /usr/bin/shar
+  /usr/bin/shar
+  root@localhost:~# echo $?
+  0
+  ```
+
+- 如果结束状态不是0，说明命令执行失败。例如：
+
+  ```
+  root@localhost:~# ls /usr/bin/share
+  ls: cannot access /usr/bin/share: No such file or directory
+  root@localhost:~# echo $?
+  2
+  ```
+
+🦅 **Bourne Shell(bash) 中有哪些特殊的变量？**
+
+下面的表列出了 Bourne Shell 为命令行设置的特殊变量。
+
+```
+内建变量    解释
+$0    命令行中的脚本名字
+$1    第一个命令行参数
+$2    第二个命令行参数
+…..    …….
+$9    第九个命令行参数
+$#    命令行参数的数量
+$*    所有命令行参数，以空格隔开
+```
+
+🦅 **如何取消变量或取消变量赋值？**
+
+`unset` 命令用于取消变量或取消变量赋值。语法如下所示：
+
+```
+# unset <变量名>
+```
+
+### Shell 脚本中 `if` 语法如何嵌套?
+
+```
+if [ 条件 ]
+then
+命令1
+命令2
+…..
+else
+if [ 条件 ]
+then
+命令1
+命令2
+….
+else
+命令1
+命令2
+…..
+fi
+fi
+```
+
+🦅 **在 Shell 脚本中如何比较两个数字？**
+
+在 `if-then` 中使用测试命令（ `-gt` 等）来比较两个数字。例如：
+
+```
+#!/bin/bash
+x=10
+y=20
+if [ $x -gt $y ]
+then
+echo “x is greater than y”
+else
+echo “y is greater than x”
+fi
+```
+
+### Shell 脚本中 `case` 语句的语法?
+
+基础语法如下：
+
+```
+case 变量 in
+值1)
+命令1
+命令2
+…..
+最后命令
+!!
+值2)
+命令1
+命令2
+……
+最后命令
+;;
+esac
+```
+
+### Shell 脚本中 `for` 循环语法？
+
+基础语法如下：
+
+```
+for 变量 in 循环列表
+do
+命令1
+命令2
+….
+最后命令
+done
+```
+
+### Shell 脚本中 `while` 循环语法？
+
+如同 `for` 循环，`while` 循环只要条件成立就重复它的命令块。
+不同于 `for`循环，`while` 循环会不断迭代，直到它的条件不为真。
+
+基础语法：
+
+```
+while [ 条件 ]
+do
+命令…
+done
+```
+
+🦅 **`do-while` 语句的基本格式？**
+
+`do-while` 语句类似于 `while` 语句，但检查条件语句之前先执行命令（LCTT 译注：意即至少执行一次。）。下面是用 `do-while` 语句的语法：
+
+```
+do
+{
+命令
+} while (条件)
+```
+
+🦅 **Shell 脚本中 `break` 命令的作用？**
+
+`break` 命令一个简单的用途是退出执行中的循环。我们可以在 `while` 和 `until` 循环中使用 `break` 命令跳出循环。
+
+🦅 **Shell 脚本中 `continue` 命令的作用？**
+
+`continue` 命令不同于 `break` 命令，它只跳出当前循环的迭代，而不是整个循环。`continue` 命令很多时候是很有用的，例如错误发生，但我们依然希望继续执行大循环的时候。
+
+### 如何使脚本可执行?
+
+使用 chmod 命令来使脚本可执行。例子如下：`chmod a+x myscript.sh` 。
+
+🦅 **`#!/bin/bash` 的作用？**
+
+`#!/bin/bash` 是 Shell 脚本的第一行，称为释伴（shebang）行。
+
+- 这里 `#` 符号叫做 hash ，而 `!` 叫做 bang。
+- 它的意思是命令通过 `/bin/bash` 来执行。
+
+🦅 **如何调试 Shell脚本？**
+
+- 使用 `-x'` 数（`sh -x myscript.sh`）可以调试 Shell脚本。
+- 另一个种方法是使用 `-nv` 参数(`sh -nv myscript.sh`)。
+
+🦅 **如何将标准输出和错误输出同时重定向到同一位置?**
+
+- 方法一：`2>&1 (如# ls /usr/share/doc > out.txt 2>&1 )` 。
+- 方法二：`&> (如# ls /usr/share/doc &> out.txt )` 。
+
+🦅 **在 Shell 脚本中，如何测试文件？**
+
+test 命令可以用来测试文件。基础用法如下表格：
+
+```
+Test         用法
+-d 文件名    如果文件存在并且是目录，返回true
+-e 文件名    如果文件存在，返回true
+-f 文件名    如果文件存在并且是普通文件，返回true
+-r 文件名    如果文件存在并可读，返回true
+-s 文件名    如果文件存在并且不为空，返回true
+-w 文件名    如果文件存在并可写，返回true
+-x 文件名    如果文件存在并可执行，返回true
+```
+
+### 在 Shell 脚本如何定义函数呢？
+
+函数是拥有名字的代码块。当我们定义代码块，我们就可以在我们的脚本调用函数名字，该块就会被执行。示例如下所示：
+
+```
+$ diskusage () { df -h ; }
+译注：下面是我给的shell函数语法，原文没有
+[ function ] 函数名 [()]
+{
+命令;
+[return int;]
+}
+```
+
+🦅 **如何让 Shell 就脚本得到来自终端的输入?**
+
+read 命令可以读取来自终端（使用键盘）的数据。read 命令得到用户的输入并置于你给出的变量中。例子如下：
+
+```
+# vi /tmp/test.sh
+#!/bin/bash
+echo ‘Please enter your name’
+read name
+echo “My Name is $name”
+# ./test.sh
+Please enter your name
+LinuxTechi
+My Name is LinuxTechi
+```
+
+🦅 **如何执行算术运算？**
+
+有两种方法来执行算术运算：
+
+- 1、使用 expr 命令：`# expr 5 + 2` 。
+- 2、用一个美元符号和方括号（`$[ 表达式 ]`）：`test=$[16 + 4] ; test=$[16 + 4]` 。
+
+## 编程题
+
+### 判断一文件是不是字符设备文件，如果是将其拷贝到 `/dev` 目录下？
+
+```
+#!/bin/bash
+read -p "Input file name: " FILENAME
+if [ -c "$FILENAME" ];then
+　　cp $FILENAME /dev
+fi
+```
+
+### 添加一个新组为 class1 ，然后添加属于这个组的 30 个用户，用户名的形式为 stdxx ，其中 xx 从 01 到 30 ？
+
+```
+#!/bin/bash
+groupadd class1
+for((i=1;i<31;i++))
+do
+        if [ $i -le 10 ];then
+                useradd -g class1 std0$i
+        else
+                useradd -g class1 std$i
+        fi
+done
+```
+
+🦅 **编写 Shell 程序，实现自动删除 50 个账号的功能，账号名为stud1 至 stud50 ？**
+
+```
+#!/bin/bash
+for((i=1;i<51;i++))
+do
+                userdel -r stud$i
+done
+```
+
+## 写一个 sed 命令，修改 `/tmp/input.txt` 文件的内容？
+
+要求：
+
+- 删除所有空行。
+- 一行中，如果包含 “11111”，则在 “11111” 前面插入 “AAA”，在 “11111” 后面插入 “BBB” 。比如：将内容为 0000111112222 的一行改为 0000AAA11111BBB2222 。
+
+```
+[root@~]# cat -n /tmp/input.txt
+     1  000011111222
+     2
+     3  000011111222222
+     4  11111000000222
+     5
+     6
+     7  111111111111122222222222
+     8  2211111111
+     9  112222222
+    10  1122
+    11
+
+# 删除所有空行命令
+[root@~]# sed '/^$/d' /tmp/input.txt
+000011111222
+000011111222222
+11111000000222
+111111111111122222222222
+2211111111
+112222222
+1122
+
+# 插入指定的字符
+[root@~]# sed 's#\(11111\)#AAA\1BBB#g' /tmp/input.txt
+0000AAA11111BBB222
+0000AAA11111BBB222222
+AAA11111BBB000000222
+AAA11111BBBAAA11111BBB11122222222222
+22AAA11111BBB111
+112222222
+1122
+```
+
+# 实战
+
+## 如何选择 Linux 操作系统版本?
+
+一般来讲，桌面用户首选 Ubuntu ；服务器首选 RHEL 或 CentOS ，两者中首选 CentOS 。
+
+根据具体要求：
+
+- 安全性要求较高，则选择 Debian 或者 FreeBSD 。
+
+- 需要使用数据库高级服务和电子邮件网络应用的用户可以选择 SUSE 。
+
+- 想要新技术新功能可以选择 Feddora ，Feddora 是 RHEL 和 CentOS 的一个测试版和预发布版本。
+
+- 【重点】**根据现有状况，绝大多数互联网公司选择 CentOS 。现在比较常用的是 6 系列，现在市场占有大概一半左右。另外的原因是 CentOS 更侧重服务器领域，并且无版权约束**。
+
+  > CentOS 7 系列，也慢慢使用的会比较多了。
+
+## 如何规划一台 Linux 主机，步骤是怎样？
+
+- 1、确定机器是做什么用的，比如是做 WEB 、DB、还是游戏服务器。
+
+  > 不同的用途，机器的配置会有所不同。
+
+- 2、确定好之后，就要定系统需要怎么安装，默认安装哪些系统、分区怎么做。
+
+- 3、需要优化系统的哪些参数，需要创建哪些用户等等的。
+
+## 请问当用户反馈网站访问慢，你会如何处理？
+
+🦅 **有哪些方面的因素会导致网站网站访问慢？**
+
+- 1、服务器出口带宽不够用
+
+  > - 本身服务器购买的出口带宽比较小。一旦并发量大的话，就会造成分给每个用户的出口带宽就小，访问速度自然就会慢。
+  > - 跨运营商网络导致带宽缩减。例如，公司网站放在电信的网络上，那么客户这边对接是长城宽带或联通，这也可能导致带宽的缩减。
+
+- 2、服务器负载过大，导致响应不过来
+
+  > 可以从两个方面入手分析：
+  >
+  > - 分析系统负载，使用 w 命令或者 uptime 命令查看系统负载。如果负载很高，则使用 top 命令查看 CPU ，MEM 等占用情况，要么是 CPU 繁忙，要么是内存不够。
+  > - 如果这二者都正常，再去使用 sar 命令分析网卡流量，分析是不是遭到了攻击。一旦分析出问题的原因，采取对应的措施解决，如决定要不要杀死一些进程，或者禁止一些访问等。
+
+- 3、数据库瓶颈
+
+  > - 如果慢查询比较多。那么就要开发人员或 DBA 协助进行 SQL 语句的优化。
+  > - 如果数据库响应慢，考虑可以加一个数据库缓存，如 Redis 等。然后，也可以搭建 MySQL 主从，一台 MySQL 服务器负责写，其他几台从数据库负责读。
+
+- 4、网站开发代码没有优化好
+
+  > - 例如 SQL 语句没有优化，导致数据库读写相当耗时。
+
+🦅 **针对网站访问慢，怎么去排查？**
+
+- 1、首先要确定是用户端还是服务端的问题。当接到用户反馈访问慢，那边自己立即访问网站看看，如果自己这边访问快，基本断定是用户端问题，就需要耐心跟客户解释，协助客户解决问题。
+
+  > 艿艿：不要上来就看服务端的问题。一定要从源头开始，逐步逐步往下。
+
+- 2、如果访问也慢，那么可以利用浏览器的调试功能，看看加载那一项数据消耗时间过多，是图片加载慢，还是某些数据加载慢。
+
+- 3、针对服务器负载情况。查看服务器硬件(网络、CPU、内存)的消耗情况。如果是购买的云主机，比如阿里云，可以登录阿里云平台提供各方面的监控，比如 CPU、内存、带宽的使用情况。
+
+- 4、如果发现硬件资源消耗都不高，那么就需要通过查日志，比如看看 MySQL慢查询的日志，看看是不是某条 SQL 语句查询慢，导致网站访问慢。
+
+🦅 **怎么去解决？**
+
+- 1、如果是出口带宽问题，那么久申请加大出口带宽。
+- 2、如果慢查询比较多，那么就要开发人员或 DBA 协助进行 SQL 语句的优化。
+- 3、如果数据库响应慢，考虑可以加一个数据库缓存，如 Redis 等等。然后也可以搭建MySQL 主从，一台 MySQL 服务器负责写，其他几台从数据库负责读。
+- 4、申请购买 CDN 服务，加载用户的访问。
+- 5、如果访问还比较慢，那就需要从整体架构上进行优化咯。做到专角色专用，多台服务器提供同一个服务。
+
+## 如何排查 CPU load 过高问题？
+
+- [《cpu load 过高问题排查》](https://www.cnblogs.com/lddbupt/p/5779655.html)
+
+## Linux 性能调优都有哪几种方法？
+
+- 1、Disabling daemons (关闭 daemons)。
+- 2、Shutting down the GUI (关闭 GUI)。
+- 3、Changing kernel parameters (改变内核参数)。
+- 4、Kernel parameters (内核参数)。
+- 5、Tuning the processor subsystem (处理器子系统调优)。
+- 6、Tuning the memory subsystem (内存子系统调优)。
+- 7、Tuning the file system (文件系统子系统调优)。
+- 8、Tuning the network subsystem（网络子系统调优)。
+
+# 666. 彩蛋
+
+Linux 的面试题，主要是以整理为主。但是，整理的过程，比较痛苦。因为，对于开发的 Linux 面试题，真的问的灰常简单。
+
+参考与推荐如下文章：
+
+- [《Linux 笔试面试常见题目（整理）》](https://blog.csdn.net/xy010902100449/article/details/46537427)
+
+  > 题目比较琐碎，偏运维~
+
+- [《总结：Linux 体系结构和内核结构区别》](https://blog.csdn.net/weixin_36397141/article/details/68946202)
+
+- [《39 条常见的 Linux 系统简单面试题》](https://zhuanlan.zhihu.com/p/32250942)
+
+- [《Linux 面试题哪里有》](https://t.cj.sina.com.cn/articles/view/6334503969/17990dc21001004vj1)
+
+- [《Linux 面试题》](https://www.kancloud.cn/louis1986/mianshi/579722)
+
+- [《如何用九条命令在一分钟内检查 Linux 服务器性能？》](http://fight/How-do-I-check-Linux-server-performance-in-one-minute-with-nine-commands?vip)
+
+- [《后端程序员必备的 Linux 基础知识》](https://github.com/Snailclimb/JavaGuide/blob/master/操作系统/后端程序员必备的Linux基础知识.md)
+
+- [《中国 100 强互联网企业 Linux 运维面试题合集曝光！》](http://www.magedu.com/74545.html)
+
+- [《Linux 运维面试题》](https://idc.wanyunshuju.com/yunwei/)
\ No newline at end of file
diff --git a/面试题/23-Git 面试题.assets/033f8d41d6f67a01a7cfefa6b9aa4cf4.png b/面试题/23-Git 面试题.assets/033f8d41d6f67a01a7cfefa6b9aa4cf4.png
new file mode 100644
index 0000000..193f7e3
Binary files /dev/null and b/面试题/23-Git 面试题.assets/033f8d41d6f67a01a7cfefa6b9aa4cf4.png differ
diff --git a/面试题/23-Git 面试题.assets/2135c3721109d120d0bde7f2ac0a1faa.png b/面试题/23-Git 面试题.assets/2135c3721109d120d0bde7f2ac0a1faa.png
new file mode 100644
index 0000000..39f4f70
Binary files /dev/null and b/面试题/23-Git 面试题.assets/2135c3721109d120d0bde7f2ac0a1faa.png differ
diff --git a/面试题/23-Git 面试题.assets/3054153c1904dfd5f3b9d3fbc6bf2375.jpeg b/面试题/23-Git 面试题.assets/3054153c1904dfd5f3b9d3fbc6bf2375.jpeg
new file mode 100644
index 0000000..a024bc4
Binary files /dev/null and b/面试题/23-Git 面试题.assets/3054153c1904dfd5f3b9d3fbc6bf2375.jpeg differ
diff --git a/面试题/23-Git 面试题.assets/37923f2478edc5709b36562b26c9e008.png b/面试题/23-Git 面试题.assets/37923f2478edc5709b36562b26c9e008.png
new file mode 100644
index 0000000..34c877d
Binary files /dev/null and b/面试题/23-Git 面试题.assets/37923f2478edc5709b36562b26c9e008.png differ
diff --git a/面试题/23-Git 面试题.assets/6227935e023affd4e0a339ccd197c8a6.png b/面试题/23-Git 面试题.assets/6227935e023affd4e0a339ccd197c8a6.png
new file mode 100644
index 0000000..f488844
Binary files /dev/null and b/面试题/23-Git 面试题.assets/6227935e023affd4e0a339ccd197c8a6.png differ
diff --git a/面试题/23-Git 面试题.assets/7200ee4a67dad8b11387fab7abef9f76.png b/面试题/23-Git 面试题.assets/7200ee4a67dad8b11387fab7abef9f76.png
new file mode 100644
index 0000000..1086a31
Binary files /dev/null and b/面试题/23-Git 面试题.assets/7200ee4a67dad8b11387fab7abef9f76.png differ
diff --git a/面试题/23-Git 面试题.assets/8689680c780eefe3b2d22ee6afbe8c62.png b/面试题/23-Git 面试题.assets/8689680c780eefe3b2d22ee6afbe8c62.png
new file mode 100644
index 0000000..fdcfab0
Binary files /dev/null and b/面试题/23-Git 面试题.assets/8689680c780eefe3b2d22ee6afbe8c62.png differ
diff --git a/面试题/23-Git 面试题.assets/a87e005d714e9fd3b8da23c3b20c4fff.png b/面试题/23-Git 面试题.assets/a87e005d714e9fd3b8da23c3b20c4fff.png
new file mode 100644
index 0000000..0728084
Binary files /dev/null and b/面试题/23-Git 面试题.assets/a87e005d714e9fd3b8da23c3b20c4fff.png differ
diff --git a/面试题/23-Git 面试题.md b/面试题/23-Git 面试题.md
new file mode 100644
index 0000000..6dee28f
--- /dev/null
+++ b/面试题/23-Git 面试题.md	
@@ -0,0 +1,479 @@
+# 精尽 Git 面试题「最新更新时间：2024-02」
+
+以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。
+
+如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的 Git 面试题的大保健。
+
+而题目的难度，艿艿尽量按照从容易到困难的顺序，逐步下去。
+
+# 基础
+
+## Git 的一些常用命令？
+
+[![Git 常用命令](http://static.iocoder.cn/3054153c1904dfd5f3b9d3fbc6bf2375)](http://static.iocoder.cn/3054153c1904dfd5f3b9d3fbc6bf2375)Git 常用命令
+
+- `git init`：创建 Git 库。
+
+- `git status` ：查看当前仓库的状态。
+
+- `git show` ：# 显示某次提交的内容 git show $id
+
+- `git diff` ：查看本次修改与上次修改的内容的区别。
+
+- `git add <file>` ：把现在所要添加的文件放到暂存区中。
+
+  - `git log -p <file>` ：查看每次详细修改内容的 diff 。
+
+  - `git rm <file>` ：从版本库中删除文件。
+
+  - `git reset <file>` ：从暂存区恢复到工作文件。
+
+  - `git reset HEAD^` ：恢复最近一次提交过的状态，即放弃上次提交后的所有本次修改` 。
+
+    > HEAD 本身是一個游标，它通常會指向某一个本地端分支或是其它 commit，所以你也可以把 HEAD 当做是目前所在的分支（current branch）。 可参见 [《Git 中 HEAD 是什么东西》](https://juejin.im/entry/59a38c5d6fb9a0248e5cc884) 。
+
+- `git commit` ：把 Git add 到暂存区的内容提交到代码区中。
+
+- `git clone` ：从远程仓库拷贝代码到本地。
+
+- ```
+  git branch
+  ```
+
+   
+
+  ：查看当前的分支名称。
+
+  - `git branch -r` ：查看远程分支。
+
+- `git checkout` ：切换分支。
+
+- `git merge <branch>` ：将 branch 分支合并到当前分支。
+
+- ```
+  git stash
+  ```
+
+   
+
+  ：暂存。
+
+  - `git stash pop` ：恢复最近一次的暂存。
+
+- ```
+  git pull
+  ```
+
+   
+
+  ：抓取远程仓库所有分支更新并合并到本地。
+
+  - `git push origin master` ：将本地主分支推到远程主分支。
+
+[![整体流程](23-Git 面试题.assets/033f8d41d6f67a01a7cfefa6b9aa4cf4.png)](http://static.iocoder.cn/033f8d41d6f67a01a7cfefa6b9aa4cf4)整体流程
+
+## 平时使用什么 Git 工具？
+
+**1）命令行**
+
+只能说十个里面九个菜，还有一个是大神，虽然命令行提供了全部的功能，但是很多用 GUI 工具可以很便捷解决的问题，命令行做起来都比较麻烦。
+
+当然并不是让大家不要去命令行，通过命令行可以对 git 的功能和原理有一个更深入的了解。
+
+**2）IDEA Git 插件**
+
+IDEA Git 插件越来越强大，很多时候，我们日常使用 Git ，更多使用它。具体的教程，可以看看 [《IntelliJ IDEA 下的使用 git》](https://blog.csdn.net/huangfan322/article/details/53220060) 。
+
+**3）SourceTree**
+
+> 艿艿：可以说是最好用的 Git 工具，没有之一。
+
+日常使用的一个图形化的 Git 增强工具，而最好用的功能就在于它集成了 GitFlow ，让开发者可以更简单、更规范的去做一些 Git 操作；
+
+另外它还提供了更友好的 merge 界面，但是操作起来不是很顺手，因为它只支持整行删除。
+
+[![SourceTree](23-Git 面试题.assets/8689680c780eefe3b2d22ee6afbe8c62.png)](http://static.iocoder.cn/8689680c780eefe3b2d22ee6afbe8c62)SourceTree
+
+**4）其它**
+
+- [SmartGit](https://www.syntevo.com/smartgit/)
+- [Tower](https://www.git-tower.com/mac)
+- Atom
+
+## Git 和 SVN 的优缺点？
+
+Git 是分布式版本控制系统，SVN 是集中式版本控制系统。
+
+1）SVN 的优缺点
+
+- 优点
+  - 1、管理方便，逻辑明确，符合一般人思维习惯。
+  - 2、易于管理，集中式服务器更能保证安全性。
+  - 3、代码一致性非常高。
+  - 4、适合开发人数不多的项目开发。
+- 缺点
+  - 1、服务器压力太大，数据库容量暴增。
+  - 2、如果不能连接到服务器上，基本上不可以工作，因为 SVN 是集中式服务器，如果服务器不能连接上，就不能提交，还原，对比等等。
+  - 3、不适合开源开发（开发人数非常非常多，但是 Google App Engine 就是用 SVN 的）。但是一般集中式管理的有非常明确的权限管理机制（例如分支访问限制），可以实现分层管理，从而很好的解决开发人数众多的问题。
+
+2）Git 优缺点
+
+- 优点
+  - 1、适合分布式开发，强调个体。
+  - 2、公共服务器压力和数据量都不会太大。
+  - 3、速度快、灵活。
+  - 4、任意两个开发者之间可以很容易的解决冲突。
+  - 5、离线工作。
+- 缺点
+  - 1、学习周期相对而言比较长。
+  - 2、不符合常规思维。
+  - 3、代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。
+
+所以，很多公司的开发团队使用 Git 作为版本管理，而产品团队使用 SVN 。
+
+## 说说创建分支的步骤？
+
+- 1、`git branch xxx_dev` ：创建名字为 `xxx_dev` 的分支。
+- 2、`git checkout xxx_dev` ：切换到名字为 `xxx_dev` 的分支。
+- 3、`git push origin xxx_dev` ：执行推送的操作，完成本地分支向远程分支的同步。
+
+更详细的，可以看看 [《Github 创建新分支》](https://blog.csdn.net/top_code/article/details/51931916) 文章。
+
+🦅 ****
+
+🦅 **tag 是什么？**
+
+tag ，指向一次 commit 的 id ，通常用来给分支做一个标记。
+
+> 大多数情况下，我们会将每个 Release 版本打一个分支。例如 SkyWalking 的 Tag 是 https://github.com/apache/incubator-skywalking/tags 。
+
+- 打标签 ：`git tag -a v1.01 -m "Release version 1.01"` 。
+- 提交标签到远程仓库 ：`git push origin --tags` 。
+- 查看标签 ：`git tag` 。
+- 查看某两次 tag 之间的 commit ：`git log --pretty=oneline tagA..tagB` 。
+- 查看某次 tag 之后的 commit ：`git log --pretty=oneline tagA..` 。
+
+🦅 **Git 提交代码时候写错 commit 信息后，如何重新设置 commit 信息？**
+
+可以通过 `git commit --amend` 来对本次 commit 进行修改。
+
+🦅 **删除已经合并过的分支会发生什么事？**
+
+分支本身就像是指标或贴纸一样的东西，它指着或贴在某个 commit 上面，分支并不是目录或档桉的复制品（但在有些版控系统的确是）。
+
+在 Git 裡，删除分支就像是你把包装盒上的贴纸撕下来，贴纸撕掉了，盒子并不会就这样跟着消失。所以，当你删除合并过的分支不会发生什么事，也不会造成档桉或目录跟着被删除的状况。
+
+## add 和 stage 有什么区别？
+
+在回答这个问题之前需要先了解 Git 仓库的三个组成部分：
+
+- 工作区(Working Directory)：在 Git 管理下的正常目录都算是工作区，我们平时的编辑工作都是在工作区完成。
+- 暂存区(Stage)：临时区域。里面存放将要提交文件的快照。
+- 历史记录区(History)：`git commit` 后的记录区。
+
+然后，是这三个区的转换关系以及转换所使用的命令：[![三个区的转换关系](23-Git 面试题.assets/2135c3721109d120d0bde7f2ac0a1faa.png)](http://static.iocoder.cn/2135c3721109d120d0bde7f2ac0a1faa)三个区的转换关系
+
+再然后，我们就可以来说一下 `git add` 和 `git stage` 了。
+
+- **其实，他们两是同义的**，所以，惊不惊喜，意不意外？这个问题竟然是个陷阱…引入 `git stage` 的原因其实比较有趣：是因为要跟 `svn add` 区分，两者的功能是完全不一样的，svn add 是将某个文件加入版本控制，而 git add 则是把某个文件加入暂存区。
+- 因为在 Git 出来之前大家用 SVN 比较多，所以为了避免误导，Git 引入了 `git stage` ，然后把 `git diff --staged` 做为 `git diff --cached` 的相同命令。基于这个原因，我们建议使用 `git stage` 以及 `git diff --staged` 。
+
+🦅 **如何从 Git 中删除文件，而不将其从文件系统中删除？**
+
+如果你在 `git add` 过程中误操作，你最终会添加不想提交的文件。但是，`git rm` 则会把你的文件从你暂存区（索引）和文件系统（工作树）中删除，这可能不是你想要的。
+
+换成 `git reset` 操作：
+
+```
+git reset filename          # or
+echo filename >> .gitingore # add it to .gitignore to avoid re-adding it
+```
+
+- 上面意思是，`git reset <file>` 是 `git add <file>` 的逆操作。
+
+## merge 和 rebase 的有什么区别？
+
+Git 合并的两种方法。
+
+- `git merge` ，把本地代码和已经取得的远程仓库代码合并。
+- `git rebase` ，是复位基底的意思。
+
+`git merge` 会生成一个新的节点，之前的提交会分开显示；而 `git rebase` 操作不会生成新的操作，将两个分支融合成一个线性的提交。
+
+推荐看看 [《git rebase 和 git merge 的区别》](https://www.jianshu.com/p/f23f72251abc) 和 [《git merge 和 git rebase 的区别》](https://blog.csdn.net/zhangyulin54321/article/details/79996768)。
+
+🦅 **什么时候使用 rebase 代替 merge ？**
+
+这两个命令都是把修改从一个分支集成到另一个分支上，它们只是以非常不同的方式进行。
+
+- 考虑一下场景，在合并和变基前：
+
+  ```
+  A <- B <- C    [master]
+  ^
+   \
+    D <- E       [branch]
+  ```
+
+- 在 `git merge master` 之后：
+
+  ```
+  A <- B <- C
+  ^         ^
+   \         \
+    D <- E <- F
+  ```
+
+- 在 `git rebase master` 之后：
+
+  ```
+  A <- B <- C <- D <- E
+  ```
+
+使用变基时，意味着使用另一个分支作为集成修改的新基础。
+
+- 何时使用：
+  - 如果你对修改不够果断，请使用合并操作。
+  - 根据你希望的历史记录的样子，而选择使用变基或合并操作。
+- 更多需要考虑的因素：
+  - 分支是否与团队外部的开发人员共享修改（如开源、公开项目）？如果是这样，请不要使用变基操作。变基会破坏分支，除非他们使用 `git pull --rebase` ，否则这些开发人员将会得到损坏的或不一致的仓库。
+  - 你的开发团队技术是否足够娴熟？变基是一种破坏性操作。这意味着，如果你没有正确使用它，你可能会丢失提交，并且/或者会破坏其他开发者仓库的一致性。
+  - 分支本身是否代表有用的信息？一些团队使用功能分支（branch-per-feature）模式，每个分支代表一个功能（或错误修复，或子功能等）。在此模式中，分支有助于识别相关提交的集合。在每个开发人员分支（branch-per-developer）模式中，分支本身不会传达任何其他信息（提交信息已有作者）。则在这种模式下，变基不会有任何破坏。
+  - 是否无论如何都要还原合并？恢复（如在撤销中）变基，是相当困难的，并且/或者在变基中存在冲突时，是不可能完成的。如果你考虑到日后可能需要恢复，请使用合并操作。
+
+🦅 **reset 与 rebase 有什么区别？**
+
+- reset 操作，不修改 commit 相关的东西，只会去修改 `.git` 目录下的东西。
+- rebase 操作，会试图修改你已经 commit 的东西，比如覆盖 commit 的历史等，但是不能使用 rebase 来修改已经 push 过的内容，容易出现兼容性问题。rebase 还可以来解决内容的冲突，解决两个人修改了同一份内容，然后失败的问题。
+
+推荐看看 [《“git reset”和“git rebase”有什么区别？》](https://codeday.me/bug/20171012/84739.html) 。
+
+🦅 **reset 与 revert 与 checkout 有什么区别？**
+
+首先是它们的共同点：用来撤销代码仓库中的某些更改。
+
+然后是不同点：
+
+- 1）从 commit 层面来说：
+
+  - `git reset` ，可以将一个分支的末端指向之前的一个 commit 。然后再下次 Git 执行垃圾回收的时候，会把这个 commit 之后的 commit 都扔掉。`git reset` 还支持三种标记，用来标记 reset 指令影响的范围：
+
+    - `--mixed` ：会影响到暂存区和历史记录区。也是默认选项；
+
+    - `--soft` ：只影响历史记录区；
+
+    - `--hard`：影响工作区、暂存区和历史记录区。
+
+      > 注意：因为 `git reset` 是直接删除 commit 记录，从而会影响到其他开发人员的分支，所以不要在公共分支（比如 develop）做这个操作。
+
+  - `git checkout` ，可以将 HEAD 移到一个新的分支，并更新工作目录。因为可能会覆盖本地的修改，所以执行这个指令之前，你需要 stash 或者 commit 暂存区和工作区的更改。
+
+  - `git revert` ，和 `git reset` 的目的是一样的，但是做法不同，它会以创建新的 commit 的方式来撤销 commit ，这样能保留之前的 commit 历史，比较安全。另外，同样因为可能会覆盖本地的修改，所以执行这个指令之前，你需要 stash 或者 commit 暂存区和工作区的更改。
+
+- 2）从文件层面来说
+
+  - `git reset` ，只是把文件从历史记录区拿到暂存区，不影响工作区的内容，而且不支持 `--mixed`、`--soft` 和 `--hard` 。
+  - `git checkout` ，则是把文件从历史记录拿到工作区，不影响暂存区的内容。
+  - `git revert` ，不支持文件层面的操作。
+
+总的来说，回答关键点：
+
+- 对于 commit 层面和文件层面，这三个指令本身功能差别很大。
+- `git revert` 不支持文件层面的操作。
+- 不要在公共分支做 `git reset` 操作。
+
+🦅 **不小心用 `git reset --hard` 指令把提交理掉了，有机会救回來吗？**
+
+放心，基本上东西进了 Git 就不容易消失，它們只是以一种我们肉眼看不懂的格式存放在 Git 空间裡。我们可以透過 `git reflog` 指令去翻一下被 reset 的那個 Commit 的编号值，然後再做一次 `git reset --hard` 就可以把它救回來了。
+
+## Git 如何解决代码冲突？
+
+```
+git stash
+git pull
+git stash pop
+```
+
+> 最常用。
+
+- 这个操作就是把自己修改的代码隐藏，然后把远程仓库的代码拉下来，然后把自己隐藏的修改的代码释放出来，让 Git 自动合并。
+
+```
+git reset –hard
+git pull
+```
+
+🦅 **假如你现在的分支为 `main_dev`，并在这个分支上修复了一个Bug ，但是在 `main_zh_test` 分支也发现了同样的一个 Bug ，如果不用 copy 代码的方式，你如何把 `main_dev` 修复这个 Bug 提交的代码合并到 `main_zh_test` 分支上，请贴出你的 Git 操作指令和指令的含义?**
+
+> 假设合并时没有冲突
+
+- 1、在 `main_dev` 分支上，通过 gitlog 命令，使用 bugid 搜索提交的 commit id 。
+- 2、使用 `git checkout main_zh_test` 命令，切换到 `main_zh_test` 分支。
+- 3、使用 `git cherry-pick commitid` 将对 Bug 的修改批量移植到该分支上。
+- 4、`git commit` ，提交到本地。
+- 5、`git push` ，推送到远程仓库。
+
+所以，重心在于 cherry-pick 使用，参见 [《git cherry-pick 使用指南》](https://www.jianshu.com/p/08c3f1804b36) 文章。
+
+🦅 **如果你正在某个分支进行开发，突然被老叫去修别的问题，这时候你会怎么处理手边的工作？**
+
+- 一种是直接先 `git commit` ，等要处理的问题解決後再回來這個分支，再 `git reset` 把 Commit 拆开來继续接著做。
+- 另一种做法，則是使用 `git stash` 指令，先把目前的进度存在 stash 上，等任务結束后可以再使用 `git stash pop` 或 `git stash apply` 把当时的及大怒再拿出來。
+
+## pull 与 fetch 有什么区别？
+
+```
+pull = fetch + merge
+```
+
+- 使用 `git fetch` 是取回远端更新，不会对本地执行 merge 操作，不会去动你的本地的内容。
+- 而是用 ·git pull` 会更新你本地代码到服务器上对应分支的最新版本。
+- 如果要代码库的文件完全覆盖本地版本。
+
+## 什么是 fork 操作？
+
+fork ，是对一个仓库的克隆。克隆一个仓库允许你自由试验各种改变，而不影响原始的项目。
+
+一般来说，fork 被用于去更改别人的项目（贡献代码给已经开源的项目）或者使用别人的项目作为你自己想法的初始开发点。
+
+> 使用 fork 提出改变的一个很好的例子是漏洞修复。与其记录一个你发现的问题，不如：
+>
+> - fork 这个仓库
+> - 进行修复
+> - 向这个项目的拥有者提交一个 pull requset
+>
+> 如果这个项目的拥有者认同你的成果，他们可能会将你的修复更新到原始的仓库中！
+
+- 目前很多开源项目，采用 fork + pull request 的方式，实现新功能的开发，Code Review 等等。
+
+🦅 **Fork 和 Clone 有什么区别？**
+
+Clone ，不是 Fork ，克隆是个对某个远程仓库的本地拷贝。克隆时，实际上是拷贝整个源存储仓库，包括所有历史记录和分支。
+
+🦅 **Fork 和 Branch 有什么区别？**
+
+Branch ，是一种机制，用于处理单一存储仓库中的变更，并最终目的是用于与其他部分代码合并。
+
+## Git 服务器
+
+Git 服务器的选择，实际上是比较多的。
+
+- 公有服务方案
+
+  - Github
+  - Gitee
+
+- 私有化部署方案
+
+  - GitLab
+
+  - Gogs
+
+  - Bitbucket
+
+    > 注意，Gitlab 和 Bitbucket 也提供公有服务的方案。
+
+一般情况下，大多数公司使用 GitLab 作为 Git 服务器。
+
+> GitLab是一个利用 [Ruby on Rails](http://www.oschina.net/p/ruby+on+rails) 开发的开源应用程序，实现一个自托管的[Git](http://www.oschina.net/p/git)项目仓库，可通过Web界面进行访问公开的或者私人项目。
+>
+> 它拥有与[Github](http://www.oschina.net/p/github)类似的功能，能够浏览源代码，管理缺陷和注释。可以管理团队对仓库的访问，它非常易于浏览提交过的版本并提供一个文件历史库。它还提供一个代码片段收集功能可以轻松实现代码复用，便于日后有需要的时候进行查找。
+
+- 不过因为 GitLb 使用 Ruby on Rails 实现，所以占用的系统资源会比较多。
+
+# 【重要】Git 工作流
+
+Git 因为其灵活性，所以提供了多种工作流的方式：
+
+1. 集中式工作流。
+2. 功能分支工作流。
+3. Gitflow 工作流
+
+## Git 集中式工作流
+
+参见 [《Git 工作流指南：集中式工作流》](http://blog.jobbole.com/76847/) 文章。
+
+## Git 功能分支工作流
+
+参见 [《Git 工作流指南：功能分支工作流》](http://blog.jobbole.com/76857/) 文章。
+
+## Gitflow 工作流
+
+参见 [《Git 工作流指南：Gitflow 工作流》](http://blog.jobbole.com/76867/) 文章。
+
+- 两个长期维护分支
+  - 主分支(master)
+  - 开发分支(develop)
+- 三种短期分支
+  - 功能分支(feature branch)
+  - 补丁分支(hotfix branch)
+  - 预发分支(release branch)
+
+🦅 **GitFlow 的优势有哪些？**
+
+- 1、并行开发：GitFlow 可以很方便的实现并行开发：每个新功能都会建立一个新的 feature 分支，从而和已经完成的功能隔离开来，而且只有在新功能完成开发的情况下，其对应的 feature 分支才会合并到主开发分支上（也就是我们经常说的 develop 分支）。另外，如果你正在开发某个功能，同时又有一个新的功能需要开发，你只需要提交当前 feature 的代码，然后创建另外一个 feature 分支并完成新功能开发。然后再切回之前的 feature 分支即可继续完成之前功能的开发。
+- 2、协作开发：GitFlow 还支持多人协同开发，因为每个 feature 分支上改动的代码都只是为了让某个新的 feature 可以独立运行。同时我们也很容易知道每个人都在干啥。
+- 3、发布阶段：当一个新 feature 开发完成的时候，它会被合并到 develop 分支，这个分支主要用来暂时保存那些还没有发布的内容，所以如果需要再开发新的 feature，我们只需要从 develop 分支创建新分支，即可包含所有已经完成的 feature 。
+- 4、支持紧急修复：GitFlow 还包含了 hotfix 分支。这种类型的分支是从某个已经发布的 tag 上创建出来并做一个紧急的修复，而且这个紧急修复只影响这个已经发布的 tag，而不会影响到你正在开发的新 feature 。
+
+## Forking 工作流程
+
+**Forking 工作流程**，与其他流行的 Git 工作流程有着根本的区别。它不是用单个服务端仓库充当“中央”代码库，而是为每个开发者提供自己的服务端仓库。Forking 工作流程最常用于公共开源项目中。
+
+- Forking 工作流程的**主要优点**是可以汇集提交贡献，又无需每个开发者提交到一个中央仓库中，从而实现干净的项目历史记录。开发者可以推送（push）代码到自己的服务端仓库，而只有项目维护人员才能直接推送（push）代码到官方仓库中。
+- 当开发者准备发布本地提交时，他们的提交会推送到自己的公共仓库中，而不是官方仓库。然后他们向主仓库提交请求拉取（pull request），这会告知项目维护人员有可以集成的更新。
+
+当然，这并不是说Forking 工作流程和上述的工作流是冲突的关系，而是可以相互结合。目前，很多公司都采用 **Gitflow 工作流 + Forking 工作流程结合**的方式。为什么呢？
+
+- 1、对于主仓库，读权限是所有开发人员都有，但是写权限是只有部分“管理”开发人员有，从而对主仓库的统一管理。
+
+  > 😈 如果不酱紫，主仓库岂不是可以被各种乱改。
+
+- 2、所有开发人员，提交代码到自己的服务端仓库，通过 pull request 到主仓库。这样，“管理”开发人员就可以对代码进行 Code Review ，保证代码质量。
+
+## 解释下 PR 和 MR 的区别？
+
+PR 和 MR 的全称分别是 pull request 和 merge request。
+
+🚀 解释它们两者的区别之前，我们需要先了解一下 Code Review，因为 PR 和 MR 的引入正是为了进行 Code Review。
+
+- Code Review 是指在开发过程中，对代码的系统性检查。通常的目的是查找系统缺陷，保证代码质量和提高开发者自身水平。 Code Review 是轻量级代码评审，相对于正式代码评审，轻量级代码评审所需要的各种成本要明显低的多，如果流程正确，它可以起到更加积极的效果。
+- 进行 Code Review 的原因：
+  - 提高代码质量
+  - 及早发现潜在缺陷与 BUG ，降低事故成本。
+  - 促进团队内部知识共享，提高团队整体水平
+  - 评审过程对于评审人员来说，也是一种思路重构的过程，帮助更多的人理解系统。
+
+🚀 然后我们需要了解下 fork 和 branch ，因为这是 PR 和 MR 各自所属的协作流程。
+
+- **fork** 是 git 上的一个协作流程。通俗来说就是把别人的仓库备份到自己仓库，修修改改，然后再把修改的东西提交给对方审核，对方同意后，就可以实现帮别人改代码的小目标了。fork 包含了两个流程：
+  - fork 并更新某个仓库[![img](23-Git 面试题.assets/6227935e023affd4e0a339ccd197c8a6.png)](http://static.iocoder.cn/6227935e023affd4e0a339ccd197c8a6)
+  - 同步 fork[![img](23-Git 面试题.assets/a87e005d714e9fd3b8da23c3b20c4fff.png)](http://static.iocoder.cn/a87e005d714e9fd3b8da23c3b20c4fff)
+- 和 fork 不同，**branch** 并不涉及其他的仓库，操作都在当前仓库完成。[![img](http://static.iocoder.cn/7200ee4a67dad8b11387fab7abef9f76)](http://static.iocoder.cn/7200ee4a67dad8b11387fab7abef9f76)img
+
+考察关键点：
+
+- Code review；
+- PR 和 MR 所属流程的细节。
+
+回答关键点：
+
+- 回答这个问题的时候不要单单只说它们的区别。而是要从 PR 和 MR 产生的原因，分析它们所属的流程，然后再得出两者的区别。
+
+# 666. 彩蛋
+
+在网络上，找到一个牛逼的 Git 脑图：[![脑图](http://static.iocoder.cn/37923f2478edc5709b36562b26c9e008)](http://static.iocoder.cn/37923f2478edc5709b36562b26c9e008)脑图
+
+参考与推荐如下文章：
+
+- [《Git 面試題》](https://gitbook.tw/interview)
+
+  > 读者写的非常棒，即使不准备面试，也可以看看，作为平时使用 Git 一些场景下的解决方案。
+
+- [《面试当中的 Git 问题》](https://blog.csdn.net/qq_26768741/article/details/66975516)
+
+- [《Git 的常见问题以及面试题汇总》](https://www.breakyizhan.com/git/5035.html)
+
+- [《泪流满面的 11 个 Git 面试题》](http://blog.jobbole.com/114297/)
+
+- [《面试中的那些 Git 问题 - 基础部分》](http://www.cocoachina.com/ios/20171023/20873.html)
\ No newline at end of file
diff --git a/面试题/24-Jenkins 面试题（Beta）.assets/ed38bed0711e35a59a5f1cb605ea667a.jpeg b/面试题/24-Jenkins 面试题（Beta）.assets/ed38bed0711e35a59a5f1cb605ea667a.jpeg
new file mode 100644
index 0000000..60079a8
Binary files /dev/null and b/面试题/24-Jenkins 面试题（Beta）.assets/ed38bed0711e35a59a5f1cb605ea667a.jpeg differ
diff --git a/面试题/24-Jenkins 面试题（Beta）.md b/面试题/24-Jenkins 面试题（Beta）.md
new file mode 100644
index 0000000..f95d5a4
--- /dev/null
+++ b/面试题/24-Jenkins 面试题（Beta）.md	
@@ -0,0 +1,143 @@
+# 精尽 Jenkins 面试题（Beta）
+
+以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。
+
+如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的 Jenkins 面试题的大保健。
+
+而题目的难度，艿艿尽量按照从容易到困难的顺序，逐步下去。
+
+> 艿艿：实际上，面试中基本不会问 Jenkins 。因为，也没啥好问的。所以，本文胖友可以作为啥呢？我也不造，就当简单过过一些知识点吧。
+
+## 持续集成是什么？
+
+持续集成，源于极限编程(XP)，是一种软件实践，软件开发过程中集成步骤是一个漫长并且无法预测的过程。集成过程中可能会爆发大量的问题，因此集成过程需要尽可能小而多，实际上持续集成讲的是不断的去做软件的集成工作。
+
+🦅 **持续集成有什么作用？**
+
+- 场景一、某项目最后做模块集成的时候，发现很多接口都不通，甚至有的模块连安装包都没有。
+- 场景二、没有可用的软件包，需要人手动去编译打包最新的代码。
+- 场景三、搭建测试环境的时候，需要手动去解压包，然后一系列拷贝修改配置等等。
+- 场景四、团队成员或者 teamleader 想了解当前项目的状态，该如何去展示这些信息。
+
+持续集成就是用来解决以上问题，它的价值主要在于减少重复的步骤，降低项目的风险，任何时间任何地点生成可用的软件，增强项目的可见性等。
+
+[![集成结构组成图](24-Jenkins 面试题（Beta）.assets/ed38bed0711e35a59a5f1cb605ea667a.jpeg)](http://static.iocoder.cn/ed38bed0711e35a59a5f1cb605ea667a)集成结构组成图
+
+> 艿艿：胖友，有没发现前后端分离之后，集成越来越是一个问题，特别是项目越到后期，越多问题。尽早集成，即使前期进度可能会略有滞后，大家需要经常加班。但是呢，前紧后松，一定能让项目更加可控。
+
+🦅 **持续集成怎么做？**
+
+持续集成，最简单的形式是包括一个监控版本控制（SVN、Git 等等）变化的工具。当变化被发觉时，这个工具可以自动的编译并测试你的应用。
+
+当然，目前更多的是，使用 Jenkins 来实现持续集成。
+
+> 艿艿：我记得我 11 年工作的时候，公司内部做了一个简单的发布系统。这个系统会告诉我们哪些类发生了变化，然后我们选择哪几个类需要发布到测试或生产环境上。😈 实在简陋，而且常常会少发，痛苦不堪。感谢 Jenkins ，嘿嘿。
+
+🦅 **持续集成有哪些良好的实践？**
+
+- 维护一个单一的代码库
+
+- 使构建自动化
+
+- 使构建自测试
+
+  > 自测试，相对来说难落地，主要原因：
+  >
+  > - 大多数公司，开发很少写单元测试。
+  > - 大多数公司，没有自动化测试工程师。
+
+- 每人每天都向主线提交代码
+
+  > 因为采用 GitFlow 工作流，所以不能向 master 分支提交代码，更多的是，向主仓库对应的功能分支提交。
+  >
+  > 如果真的要向 master 提交，需要配合 [特性开关](https://www.jianshu.com/p/304697cdb440) 。
+
+- 每次提交都应在集成机上进行构建
+
+- 快速构建
+
+- 使任何人都能轻易获得可执行文件
+
+- 人人都能看到正在发生什么
+
+- 自动化部署
+
+## 简单介绍 Jenkins 是什么？
+
+- 持续集成是一种实践，而 Jenkins 可以帮助团队去尽量好的去完成这种实践。
+
+  > 即，Jenkins 是一个持续集成的工具。
+
+- Jenkins 是基于 Java 语言的开源持续集成工具，提供了一套非常易用的用户界面，用以自动化构建、测试、部署等功能。
+
+- Jenkins 类似于 Eclipse ，基于插件化的架构，方便功能的扩展，目前有几百个现成插件可以使用，这些插件涵盖从版本控制、构建工具、代码质量、构建通知、集成外部系统、UI定制、游戏等等各个方面。
+
+  > 😈 只要是个工具，基本是**插件化**的架构。
+
+> 历史小故事：
+>
+> 伴随着 Jenkins ，有时人们还可能看到它与 Hudson 关联。Hudson 是由 Sun Microsystems 开发的一个非常流行的开源，基于 Java 的持续集成工具，后来被 Oracle 收购。Sun 被 Oracle 收购之后，一个从 Hudson 源代码的分支由 Jenkins 创建出台。
+
+## Jenkins 你都用了哪些插件？
+
+- 最常用
+  - [SSH Plugin](https://blog.csdn.net/taiyangdao/article/details/70163225) ：这个可以登陆远程服务器，然后在上面执行脚本。
+  - [Role Strategy Plugin](https://blog.csdn.net/wanglei_storage/article/details/78339409) ：用来精细化管理权限，基于角色维度。
+  - [Git plugin](https://wiki.jenkins.io/display/JENKINS/Git+Plugin) ：对 Git 的支持。
+  - [SCM](https://blog.csdn.net/itfootball/article/details/45061093) ：除 CVS 和 Subversion 外，需要实现与源代码控制系统支持的插件。
+- 根据情况
+  - Triggers ：事件监听并触发构建的插件。例如，URL 改变触发器将监控一个 URL ，当地址内容发生改变，这个触发器就将执行一次作业。
+  - Build tools ：实现额外构建工具的插件，如 MSBuild 和 Rake 。如果您想在 Hudson 中构建非 Java 的软件时这些就特别有用。
+  - Build wrappers ：通常涉及时执行在受控制的构建过程本身之前和之后事件的插件。例如，VMware 插件将在构建之前启动一个客户虚拟机，建立和然后在构建完成后关闭它。这在您可能需要访问 VM 以执行单元测试的情况下是非常有用的。
+
+## Jenkins 如何实现发布和回滚？
+
+- 发布：Jenkins 配置好代码路径(SVN 或 Git)，然后拉代码，打tag 。需要编译就编译，编译之后推送到发布服务器（Jenkins 里面可以调脚本），然后从分发服务器往下分发到业务服务器上。
+
+- 回滚：按照版本号到发布服务器找到对应的版本推送。
+
+  > 一定要打 Tag 噢，不然回滚会比较麻烦。
+
+## Jenkins 怎么做备份与恢复？
+
+目前有三种方式：
+
+- 1、使用插件备份。
+
+  > 例如 ThinBackup 插件。
+
+- 2、使用 Rsync 异地备份。
+
+- 3、使用版本控制工具进行备份。
+
+具体的，可以参考文章 [《Jenkins 系列： （五） Jenkins 数据备份与恢复》](https://blog.csdn.net/huaqiangli/article/details/79201831) 。
+
+相对来说，比较推荐使用 ThinBackup 插件，简单方便，能够满足需求。
+
+## Jenkins 如何删除历史构建数据？
+
+目前来说，有三种方式：
+
+- 1、手工删除构建记录。
+- 2、转移磁盘空间。
+- 3、自动丢弃构建历史数据。
+
+具体的，可以参考文章 [《Jenkins 服务器磁盘空间管理策略》](https://blog.csdn.net/lantian08251/article/details/41380483) 。
+
+如果说，我们希望多保持一些构建历史数据，那么可以设置较大的“发布包最大保留”，同时我们需要提供相对大的磁盘空间。当然，即使再大的磁盘空间，也可能被撑爆，所以出问题时，我们可以手工删除构建记录。也就会说，三种方式，一起配合。
+
+另外，Jenkins 的日志文件也挺占用内存你的，可以参考 [《Linux 中 Jenkins 日志记录占满磁盘问题》](https://www.itbox.info/p/1490170/jenkins-log-auto-del-dev-vda1-use-max-depth-lsof) 文章，进行处理。
+
+## 彩蛋
+
+发现，真的没什么好写的。当然，如果没有自己配置过 Jenkins 的胖友，建议尝试自己搭建一次，然后至少部署几个 Spring Boot 的项目，再然后，思考下需要划分几套环境，每套环境的定义。一般来说：
+
+```
+Feature 环境 => 测试环境 => 预发布环境 => 生产环境
+```
+
+参考与推荐如下文章：
+
+- [《Jenkins 面试题》](https://www.cnblogs.com/luoahong/articles/8313870.html)
+- [《持续集成以及 Jenkins 的知识介绍》](https://www.cnblogs.com/tsbc/p/4882485.html)
+- [《如何在 CentOS 下安装部署 Jenkins 持续集成环境》](https://idc.wanyunshuju.com/li/573.html)
\ No newline at end of file
diff --git a/面试题/25-Maven 面试题.assets/01.jpg b/面试题/25-Maven 面试题.assets/01.jpg
new file mode 100644
index 0000000..23aecb8
Binary files /dev/null and b/面试题/25-Maven 面试题.assets/01.jpg differ
diff --git a/面试题/25-Maven 面试题.md b/面试题/25-Maven 面试题.md
new file mode 100644
index 0000000..9b90766
--- /dev/null
+++ b/面试题/25-Maven 面试题.md	
@@ -0,0 +1,496 @@
+# 精尽 Maven 面试题「最新更新时间：2024-02」
+
+以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。
+
+如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的 Maven 面试题的大保健。
+
+而题目的难度，艿艿尽量按照从容易到困难的顺序，逐步下去。
+
+> 艿艿：实际上，面试中基本不会问 Maven 。因为，也没啥好问的。所以，本文胖友可以作为啥呢？我也不造，就当简单过过一些知识点吧。
+
+## Maven 是什么？
+
+Maven 主要服务于基于 Java 平台的项目构建、依赖管理和项目信息管理。
+
+Maven 的主要功能主要分为 5 点：
+
+- 依赖管理系统
+- 多模块构建
+- 一致的项目结构
+- 一致的构建模型和插件机制
+
+🦅 **你们项目为什么选用 Maven 进行构建？**
+
+- 首先，Maven 是一个优秀的项目构建工具。使用maven，可以很方便的对项目进行分模块构建，这样在开发和测试打包部署时，效率会提高很多。
+- 其次，Maven 可以进行依赖的管理。使用 Maven ，可以将不同系统的依赖进行统一管理，并且可以进行依赖之间的传递和继承。
+
+🦅 **Maven 规约是什么？**
+
+- `/src/main/java/` ：Java 源码。
+- `/src/main/resource` ：Java 配置文件，资源文件。
+- `/src/test/java/` ：Java 测试代码。
+- `/src/test/resource` ：Java 测试配置文件，资源文件。
+- `/target` ：文件编译过程中生成的 `.class` 文件、jar、war 等等。
+- `pom.xml` ：配置文件
+
+Maven 要负责项目的自动化构建，以编译为例，Maven 要想自动进行编译，那么它必须知道 Java 的源文件保存在哪里，这样约定之后，不用我们手动指定位置，Maven 能知道位置，从而帮我们完成自动编译。
+
+遵循**“约定>>>配置>>>编码”**。即能进行配置的不要去编码指定，能事先约定规则的不要去进行配置。这样既减轻了劳动力，也能防止出错。
+
+## Maven 常用命令
+
+- `mvn archetype：create` ：创建 Maven 项目。
+- `mvn compile` ：编译源代码。
+- `mvn deploy` ：发布项目。
+- `mvn test-compile` ：编译测试源代码。
+- `mvn test` ：运行应用程序中的单元测试。
+- `mvn site` ：生成项目相关信息的网站。
+- `mvn clean` ：清除项目目录中的生成结果。
+- `mvn package` ：根据项目生成的 jar/war 等。
+- `mvn install` ：在本地 Repository 中安装 jar 。
+- `mvn eclipse:eclipse` ：生成 Eclipse 项目文件。
+- `mvn jetty:run` 启动 Jetty 服务。
+- `mvn tomcat:run` ：启动 Tomcat 服务。
+- `mvn clean package -Dmaven.test.skip=true` ：清除以前的包后重新打包，跳过测试类。
+
+用到最多的命令
+
+- `mvn eclipse:clean` ：清除 Project 中以前的编译的东西，重新再来。
+- `mvn eclipse:eclipse` ：开始编译 Maven 的 Project 。
+- `mvn clean package` ：清除以前的包后重新打包。
+
+## Maven 有哪些优点和缺点
+
+🦅 **1）优点**
+
+- 简化了项目依赖管理。
+
+  > 当年，多少人被 SSH 整合搞死搞活，很多时候，是因为依赖不完整，或者版本不正确。自从 Maven 出来后，终于可以无痛了~当然，也有一部分功劳是 Spring Boot ，这是后话。
+
+- 易于上手，对于新手可能一个 `mvn clean package` 命令就可能满足我们的工作。
+
+- 便于与持续集成工具(Jenkins)整合。
+
+- 便于项目升级，无论是项目本身升级还是项目使用的依赖升级。
+
+- 有助于多模块项目的开发，一个模块开发好后，发布到仓库，依赖该模块时可以直接从仓库更新，而不用自己去编译。
+
+- Maven 有很多插件，便于功能扩展，比如生产站点，自动发布版本等。
+
+🦅 **2）缺点**
+
+- Maven 是一个庞大的构建系统，学习难度大。
+
+  > 这里的学习，更多指的完整学习。如果基本使用，并不会存在该问题。
+
+- Maven 采用约定优于配置的策略(convention over configuration)，虽然上手容易，但是一旦出了问题，难于调试。
+
+  > 这个确实，略微痛苦。
+
+- 当依赖很多时，m2eclipse 老是搞得 Eclipse 很卡。
+
+  > 使用 IDEA ，而不是 Eclipse ，完美解决。
+
+- 中国的网络环境差，很多 repository 无法访问，比如 Google Code、 JBoss 仓库无法访问等。
+
+  > 这个也好解决，在 `<mirrors>` 中增加阿里巴巴的 Maven 私服，具体可以参见 [《提高 Maven 速度 —— Maven 仓库修改成国内阿里巴巴地址》](https://my.oschina.net/af8991/blog/833513) 文章。
+
+## 对比其它构建工具
+
+🦅 **什么是构建？**
+
+> 艿艿：这个回答，也适用于 [「你们项目为什么选用 Maven 进行构建？」](https://svip.iocoder.cn/Maven/Interview/#)。
+
+我们都知道，写完代码之后需要进行编译和运行，以笔者自身为例，使用 IDE 写完代码，需要进行编译，再生成 war 包，以便部署到 Tomcat。
+
+在编写 Java 代码的时候，我们除了需要调用 JDK 的 API ，还需要调用许多第三方的 API ，假如没有构建工具，你需要把这些 jar 包下载到本地，然后添加进入工程，在 IDE 中进行添加设置。这种方式非常繁琐，并且在遇到版本升级，Git 同步等时候，程序会变得非常脆弱，极易产生未知错误。所以便有了构建工具的产生，它可以让我们专注于写代码，而不需要考虑如何导入 jar 包，如何升级 jar 包版本，以及 git 多人协作等等问题。这是在编译过程中的优势，在运行和发布的过程中，构建工具依然可以帮助我们将工程生成指定格式的文件。
+
+Java 世界中主要有三大构建工具：Ant、Maven和Gradle。经过几年的发展，Ant 几乎销声匿迹，Maven 也日薄西山，而 Gradle 的发展则如日中天。
+
+🦅 **Maven 和 Gradle 对比？**
+
+详细的，参见 [《Maven 和 Gradle 对比》](http://www.cnblogs.com/huang0925/p/5209563.html) 文章。
+
+🦅 **Maven 和 Ant 有什么区别？**
+
+详细的，参见文章：
+
+> 应该蛮多人，学习的时候，已经不考虑 Ant 这个东西了。
+
+- [《Java 面试题：Maven 和 ANT 有什么区别？》](https://www.jishux.com/p/f4bc99bf9e813c39)
+- [《Java 基础面试题 Ant 和 Maven》](http://www.fzjava3g.com/jishu/20140618/1676.html)
+
+## Maven 坐标的含义？
+
+```
+<!-- FROM https://github.com/junit-team/junit4/blob/master/pom.xml -->
+<groupId>junit</groupId>
+<artifactId>junit</artifactId>
+<version>4.13-BETA</version>
+```
+
+Maven 给我们制定了一套规则 —— 使用坐标进行**唯一标识**。Maven 的坐标元素包括 groupId、artifactId、version、packaging、classfier 。
+
+只要我们提供正确的坐标元素，Maven 就能找到对应的构件，首先去你的本地仓库查找，没有的话再去远程仓库下载。如果没有配置远程仓库，会默认从中央仓库地址(http://repo1.maven.org/maven2)下载构件，该中央仓库包含了世界上大部分流行的开源项目构件，但不一定所有构件都有。
+
+在我们自己开发项目的时候，也是要给我们的项目定义坐标的，这是强制性要求，只有这样，其他项目才能引用该项目的构件。
+
+- groupId
+
+   
+
+  ：定义当前 Maven 项目隶属的实际项目。
+
+  - 首先，Maven 项目和实际项目不一定是一对一的关系。比如 Spring FrameWork 这一实际项目，其对应的 Maven 项目会有很多，如 `spring-core`、`spring-context` 等。这是由于 Maven 中模块的概念，因此，一个实际项目往往会被划分成很多模块。
+  - 其次，groupId 不应该对应项目隶属的组织或公司。原因很简单，一个组织下会有很多实际项目，如果 groupId 只定义到组织级别，而后面我们会看到，artifactId 只能定义 Maven 项目(模块)，那么实际项目这个层次将难以定义。
+  - 最后，groupId 的表示方式与 Java 包名的表达方式类似，通常与域名反向一一对应。
+  - 上例中，groupId 为 `junit` ，是不是感觉很特殊，这样也是可以的，因为全世界就这么个 junit ，它也没有很多分支。
+
+- artifactId
+
+   
+
+  ：该元素定义当前实际项目中的一个 Maven 项目(模块)。
+
+  - 推荐的做法是使用实际项目名称作为 artifactId 的前缀。比如上例中的 junit ，junit 就是实际的项目名称，方便而且直观。
+  - 在默认情况下，Maven 生成的构件，会以 artifactId 作为文件头。例如 `junit-3.8.1.jar` ，使用实际项目名称作为前缀，就能方便的从本地仓库找到某个项目的构件。
+
+- version
+
+   
+
+  ：该元素定义了使用构件的版本。
+
+  - 如上例中 junit 的版本是 `4.13-BETA` ，你也可以改为 `4.1.2` 表示使用 `4.1.2` 版本的 junit 。
+
+- packaging
+
+   
+
+  ：定义 Maven 项目打包的方式，使用构件的什么包。打包方式通常与所生成构件的文件扩展名对应。
+
+  - 如上例中没有 `packaging` ，则默认为 jar 包，最终的文件名为`junit-4.13-BETA.jar` 。
+  - 当然，也可以打包成 war 等。
+
+- classifier
+
+   
+
+  ：该元素用来帮助定义构建输出的一些附件。附属构件与主构件对应。
+
+  - 如上例中的主构件为 `junit-4.13-BETA.jar` ，该项目可能还会通过一些插件生成如 `junit-4.13-BETA-javadoc.jar`、`junit-4.13-BETA-sources.jar`，这样附属构件也就拥有了自己唯一的坐标。
+
+上述 5 个元素中：
+
+- `groupId`、`artifactId`、`version` 是必须定义的。
+- `packaging` 是可选的(默认为 jar )。
+- 而 `classfier` 是不能直接定义的，需要结合插件使用。
+
+🦅 **Maven 版本规则？**
+
+Maven 主要是这样定义版本规则的：`<主版本>.<次版本>.<增量版本>` 。比如说 `1.2.3` ，主版本是 1 ，次版本是 2 ，增量版本是 3 。
+
+- 主版本，一般来说代表了项目的重大的架构变更，比如说 Maven 1 和 Maven 2 ，在架构上已经两样了，将来的 Maven 3 和 Maven 2 也会有很大的变化。
+- 次版本，一般代表了一些功能的增加或变化，但没有架构的变化，比如说Nexus 1.3 较之于 Nexus 1.2 来说，增加了一系列新的或者改进的功能（仓库镜像支持，改进的仓库管理界面等等），但从大的架构上来说，1.3 和 1.2 没什么区别。
+- 增量版本，一般是一些小的 bug fix ，不会有重大的功能变化。
+
+一般来说，在我们发布一次重要的版本之后，随之会开发新的版本。比如说，`myapp-1.1` 发布之后，就着手开发 `myapp-1.2` 了。由于`myapp-1.2` 有新的主要功能的添加和变化，在发布测试前，它会变得不稳定，而 `myapp-1.1` 是一个比较稳定的版本，现在的问题是，我们在`myapp-1.1中` 发现了一些 BUG（当然在 1.2 中也存在），为了能够在一段时间内修复 BUG 并仍然发布稳定的版本，我们就会用到分支(branch)，我们基于 1.1 开启一个分支 1.1.1 ，在这个分支中修复 BUG ，并快速发布。这既保证了版本的稳定，也能够使bug得到快速修复，也不同停止 1.2 的开发。只是，每次修复分支 1.1.1 中的 BUG 后，需要 merge 代码到 1.2 中。
+
+🦅 **多模块如何聚合？**
+
+配置一个打包类型为 `pom` 的聚合模块，然后在该 `pom` 中使用元素声明要聚合的模块。具体的，参见 [《Maven系列五：多模块项目中的聚合和继承》](https://blog.csdn.net/zdq0394123/article/details/9634061) 文章。
+
+## Maven `<dependencie />` 是什么？
+
+`<dependencie />` ，依赖关系。属性如下：
+
+- `groupId` ：依赖项的 `groupId` 。
+
+- `artifactId` ：依赖项的 `artifactId` 。
+
+- `version` ：依赖项的 `version` 。
+
+- `scope` ：依赖项的适用范围。
+
+  > - `compile` ：默认值，适用于所有阶段（开发、测试、部署、运行），本 jar 会一直存在所有阶段。
+  > - `provided` ：只在开发、测试阶段使用，目的是不让 Servlet 容器和你本地仓库的 jar 包冲突 。如 `servlet.jar` 。
+  > - `runtime` ：只在运行时使用，如 JDBC 驱动，适用运行和测试阶段。
+  > - `test` ：只在测试时使用，用于编译和运行测试代码，不会随项目发布。
+  > - `system` ：类似 `provided` ，需要显式提供包含依赖的 jar 包，Maven 不会在 Repository 中查找它。
+  > - `import` ：用于一个 `<dependencyManagement />` 对另一个 `<dependencyManagement />` 的继承。非常重要，通过它，可以实现类似 [《Maven Spring BOM (bill of materials)》](https://www.cnblogs.com/YLsY/p/5711103.html) 的功能。
+
+- `exclusions` ：排除项目中的依赖冲突时使用。
+
+🦅 **`<dependencyManagement />` 和 `<dependencie />` 区别是什么？**
+
+- `<dependencyManagement />` ， 统一了 Maven 中依赖的版本号，定义在 `dependencie />` 中的依赖，在不指定具体版本号时，就会沿着上层找到 `<dependencyManagement />` 中的依赖，并使用它的版本号。这样的话，当有多个子项目引用同一个依赖时，就不需要重复声明各自的版本号，只需统一使用 `<dependencyManagement />` 中的版本号即可。
+- 还有个不同点，`<dependencyManagement />` 中出现的依赖，并不一定会在项目中使用，而 `<dependencie />` 中的依赖，肯定是包含在项目中的。
+
+🦅 **对于一个多模块项目，如果管理项目依赖的版本？**
+
+- 方式一，通过在父模块中声明 `<dependencyManagement />` 和`<pluginManagement />`， 然后让子模块通过元素指定父模块，这样子模块在定义依赖是就可以只定义 `groupId` 和 `artifactId`，自动使用父模块的 `version` ，这样统一整个项目的依赖的版本。
+
+  > 继承的方式。
+
+- 方式二，使用 `<dependencie />` 声明 `<scope />` 为 `import` 的依赖，从而引入一个 pom 的`<dependencyManagement />` 的。具体的，可以看看 [《Maven Spring BOM (bill of materials)》](https://www.cnblogs.com/YLsY/p/5711103.html) 文章。
+
+  > 组合的方式。
+
+## Maven 依赖的解析机制是怎么样的？
+
+1. 解析发布(RELEASE)版本：如果本地有，直接使用本地的，没有就向远程仓库请求。
+2. 解析快照(SNAPSHOT)版本：合并本地和远程仓库的元数据文件 `groupId/artifactId/version/maven-metadata.xml` ，这个文件存的版本都是带时间戳的，将最新的一个改名为不带时间戳的格式供本次编译使用。
+3. 解析版本为 LATEST 过于复杂，且解析的结果不稳定，不推荐在项目中使用，感兴趣的同学自己去研究，简而言之就是合并`groupId/artifactId/maven-metadata.xml` 找到对应的最新版本和包含快照的最新版本。
+
+🦅 **LASTEST、RELEASE、SNAPSHOT 的区别？**
+
+- LASTEST ：是指某个特定构件最新的发布版或者快照版(SNAPSHOT)，最近被部署到某个特定仓库的构件。
+
+- RELEASE ：是指仓库中最后的一个非快照版本。
+
+- SNAPSHOT ：泛指。如果不 SNAPSHOT ，如果名字不变，本地有了不会从远程拉。如果每次更新都改名字，其他用的人也都改名字，太蛋疼了。
+
+  > 关于 SNAPSHOT 版本，建议看看 [《理解 Maven 中的 SNAPSHOT 版本和正式版本》](http://www.huangbowen.net/blog/2016/01/29/understand-official-version-and-snapshot-version-in-maven/) 。
+
+🦅 **Maven 依赖原则？**
+
+- 1、赖路径最短优先原则。
+
+  > 一个项目 Demo 依赖了两个 jar 包，其中 `A-B-C-X(1.0)` ， `A-D-X(2.0)` 。由于 `X(2.0)` 路径最短，所以项目使用的是 `X(2.0)` 。
+
+- 2、pom文 件中申明顺序优先。
+
+  > 如果 `A-B-X(1.0)` ，`A-C-X(2.0)` 这样的路径长度一样怎么办呢？这样的情况下，Maven 会根据 pom 文件声明的顺序加载，如果先声明了 B ，后声明了 C ，那就最后的依赖就会是 `X(1.0)` 。
+
+- 3、覆写优先
+
+  > 子 pom 内声明的优先于父 pom 中的依赖。
+
+🦅 **如何解决 jar 冲突？**
+
+遇到冲突的时候第一步，要找到 Maven 加载的到时是什么版本的 jar 包，通过们 `mvn dependency:tree` 查看依赖树，或者使用 [IDEA Maven Helper](https://plugins.jetbrains.com/plugin/7179-maven-helper) 插件。
+
+然后，通过 Maven 的依赖原则来调整坐标在 pom 文件的申明顺序是最好的办法，或者使用将冲突中不想要的 jar 引入的 jar 进行 `<exclusions>` 掉。
+
+## Maven 生命周期是怎么样的？
+
+Maven 中有三个独立的生命周期：
+
+- 1、Clean
+- 2、Default
+- 3、Site
+
+> 每个生命周期都有这个特点：不管用户要求执行的命令对应生命周期中的哪一个阶段，Maven都会自动从当前生命周期的最初位置开始执行，直到完成用户下达的指令
+
+一个完整的项目构建过程通常包括清理、编译、测试、打包、集成测试、验证、部署等步骤，Maven 从中抽取了一套完善的、易扩展的生命周期。Maven 的生命周期是抽象的，其中的具体任务都交由插件来完成。Maven 为大多数构建任务编写并绑定了默认的插件，如针对编译的插件：`maven-compiler-plugin` 。用户也可自行配置或编写插件。
+
+Maven有三套相互独立的生命周期，分别是 Clean、Default 和 Site。每个生命周期包含一些阶段，阶段是有顺序的，后面的阶段依赖于前面的阶段。
+
+- 1、Clean 生命周期：清理项目，包含三个 phase ：
+  - pre-clean：执行清理前需要完成的工作。
+  - clean：清理上一次构建生成的文件。
+  - post-clean：执行清理后需要完成的工作
+- 2、Default 生命周期：构建项目，重要的 phase 如下：
+  - validate：验证工程是否正确，所有需要的资源是否可用。
+  - compile：编译项目的源代码。
+  - test：使用合适的单元测试框架来测试已编译的源代码。这些测试不需要已打包和布署。
+  - package：把已编译的代码打包成可发布的格式，比如 jar、war 等。
+  - integration-test：如有需要，将包处理和发布到一个能够进行集成测试的环境。
+  - verify：运行所有检查，验证包是否有效且达到质量标准。
+  - install：把包安装到maven本地仓库，可以被其他工程作为依赖来使用。
+  - deploy：在集成或者发布环境下执行，将最终版本的包拷贝到远程的repository，使得其他的开发者或者工程可以共享。
+- 3、Site 生命周期：建立和发布项目站点，phase 如下：
+  - pre-site：生成项目站点之前需要完成的工作
+  - site：生成项目站点文档
+  - post-site：生成项目站点之后需要完成的工作
+  - site-deploy：将项目站点发布到服务器
+
+各个生命周期相互独立，一个生命周期的阶段前后依赖。
+
+- `mvn clean` ：调用 Clean 生命周期的 clean 阶段，实际执行 pre-clean 和 clean 阶段
+- `mvn test` ：调用 Default 生命周期的 test 阶段，实际执行 test 以及之前所有阶段
+- `mvn clean install` ：调用 Clean 生命周期的 clean 阶段和 Default 生命周期 的 install 阶段，实际执行 pre-clean 和 clean ，install 以及之前所有阶段。
+
+而我们在 IDEA Maven 中，也可以看到 Maven 生命周期的操作：
+
+[![IDEA Maven](25-Maven 面试题.assets/01.jpg)](http://static.iocoder.cn/images/Maven/01.jpg)IDEA Maven
+
+- clean ：清理自动生成的文件，也就是 target 目录。
+- validate ：验证 Maven 描述文件是否有效。
+- compile ：编译 java 代码。
+- test ：运行测试代码。
+- package ：项目打成 jar、war 包等。
+- verify ：验证构件包是否有效。
+- install ：将构件包安装到本地仓库。
+- deploy ：将构件包部署到远程仓库。
+- site ：生成项目站点。
+
+🦅 **我们经常使用 `mvn clean package` 命令进行项目打包，请问该命令执行了哪些动作来完成该任务？**
+
+> 艿艿：这个问题吧，基本不会问的，了解即可。
+
+在这个命令中我们调用了 Maven 的 clean 周期的 clean 阶段绑定的插件任务，以及 default 周期的 package 阶段绑定的插件任务。
+
+默认执行的任务有（Maven的术语叫 goal ，也有人翻译成目标，我这里用任务啦）：
+
+```
+`maven-clean-plugin:clean` -> 
+`maven-resources-plugin:resources` -> 
+`maven-compile-plugin:compile` -> 
+`mavne-resources-plugin:testResources` -> 
+`maven-compile-plugin:testCompile` -> 
+`maven-jar-plugin:jar`
+```
+
+## 什么是 Maven 插件？
+
+Maven 生命周期的每一个阶段的具体实现都是由 Maven 插件实现的。插件通常提供了一个目标的集合，并且可以使用下面的语法执行：`mvn [plugin-name]:[goal-name]`
+
+Maven 提供了下面两种类型的插件：
+
+- Build plugins ：在构建时执行，并在 `pom.xml` 的 元素中配置。
+- Reporting plugins ：在网站生成过程中执行，并在 `pom.xml` 的元素中配置。
+
+下面是一些常用插件的列表：
+
+- clean ：构建之后清理目标文件。删除目标目录。
+- compiler ：编译 Java 源文件。
+- surefile ：运行 JUnit 单元测试。创建测试报告。
+- jar ：从当前工程中构建 JAR 文件。
+- war ：从当前工程中构建 WAR 文件。
+- javadoc ：为工程生成 Javadoc 。
+- antrun ：从构建过程的任意一个阶段中运行一个 ant 任务的集合。
+
+🦅 **如何实现自定义插件？**
+
+大多数情况下，我们不太需要开发自定义的 Maven 插件，并且面试一般也不会问。当然，感兴趣的胖友，可以看看 [《Maven 自定义插件开发》](https://blog.csdn.net/u012620150/article/details/78652624) 。
+
+🦅 **Maven 插件的解析机制？**
+
+> 艿艿：这个问题，选择性理解即可。
+
+当我们输入 `mvn dependency:tree` 这样的指令，解析的步骤为：
+
+- 1、解析 `groupId` :
+
+  > Maven 使用默认的 groupId 插件为 `org.apache.maven.plugins` 或者 `org.codehaus.mojo` 。
+
+- 2、解析 `artifactId` (Maven 的官方叫做插件前缀解析策略)：
+
+  > 合并该 `groupId` 在所有仓库中的元数据库文件（`maven-metadata-repository.xml`），比如 Maven 官方插件的元数据文件所在的目录为 `org\apache\maven\plugins` ，该文件下有如下的条目：
+  >
+  > ```
+  > > <plugin>
+  > >   <name>Maven Dependency Plugin</name>
+  > >   <prefix>dependency</prefix>
+  > >   <artifactId>maven-dependency-plugin</artifactId>
+  > > </plugin>
+  > >
+  > ```
+
+  - 通过比较这样的条目，我们就将该命令的 `artifactId` 解析为`maven-dependency-plugin` 。
+
+- 3、解析 `version` ：
+
+  > 如果你在项目的 `pom` 中声明了该插件的版本，那么直接使用该版本的插件，否则合并所有仓库中 `groupId/artifactId/maven-metadata-repository.xml` ，找到最新的发布版本。
+
+对于非官方的插件，有如下两个方法可以选择：
+
+- 使用 `groupId:artifactId:version:goal` 来运行。
+- 在 `settings.xml` 中添加 `pluginGroup` 项，这样 Maven 不能在官方的插件库中解析到某个插件，那么就可以去你配置的 `group` 下查找啦。
+
+## 什么是 Maven 仓库？
+
+🚀 Maven 的仓库只有两大类：
+
+- 1、本地仓库。
+- 2、远程仓库。在远程仓库中又分成了 3 种：
+  - 中央仓库。
+  - 私服。
+  - 其它公共库。
+
+🚀 Maven 会先搜索本地仓库（repository），发现本地没有然后从远程仓库（中央仓库）获取。
+
+- 但中央仓库只有一个，最好从其镜象处下载。国内可以用阿里云下的服务器。【*其它公共库*】
+- 也有通过 Nexus 搭建的私服进行获取的。【*私服*】
+
+🚀 Maven 中的仓库分为两种，SNAPSHOT 快照仓库和 RELEASE 发布仓库。
+
+- SNAPSHOT 快照仓库用于保存开发过程中的不稳定版本，RELEASE 正式仓库则是用来保存稳定的发行版本。定义一个组件/模块为快照版本，只需要在 `pom` 文件中在该模块的版本号后加上 `-SNAPSHOT` 即可(注意这里必须是大写)，如下：
+
+  ```
+  <groupId>cc.mzone</groupId>
+  <artifactId>m1</artifactId>
+  <version>0.1-SNAPSHOT</version>
+  <packaging>jar</packaging>
+  ```
+
+- Maven 会根据模块的版本号(`pom` 文件中的 `version`)中是否带有 `-SNAPSHOT` 来判断是快照版本还是正式版本。
+
+  - 如果是快照版本，那么在 `mvn deploy` 时会自动发布到快照版本库中，会覆盖老的快照版本。而在使用快照版本的模块，在不更改版本号的情况下，直接编译打包时，Maven 会自动从镜像服务器上下载最新的快照版本。
+  - 如果是正式发布版本，那么在 `mvn deploy` 时会自动发布到正式版本库中，而使用正式版本的模块，在不更改版本号的情况下，编译打包时如果本地已经存在该版本的模块则不会主动去镜像服务器上下载。
+
+所以，我们在开发阶段，可以将公用库的版本设置为快照版本，而被依赖组件则引用快照版本进行开发，在公用库的快照版本更新后，我们也不需要修改 pom 文件提示版本号来下载新的版本，直接 mvn 执行相关编译、打包命令即可重新下载最新的快照库了，从而也方便了我们进行开发。
+
+🦅 **什么是私服？**
+
+私服是一种特殊的远程仓库，它是架设在局域网内的仓库服务，私服代理广域网上的远程仓库，供局域网内的 Maven 用户使用。当 Maven 需要下载构件的时候，它从私服请求，如果私服上不存在该构件，则从外部的远程仓库下载，缓存在私服上之后，再为 Maven 的下载请求提供服务。我们还可以把一些无法从外部仓库下载到的构件上传到私服上。
+
+🚀 Maven 私服的 5 个特性：
+
+- 1、节省自己的外网带宽：减少重复请求造成的外网带宽消耗。
+- 2、加速 Maven 构件：如果项目配置了很多外部远程仓库的时候，构建速度就会大大降低。
+- 3、部署第三方构件：有些构件无法从外部仓库获得的时候，我们可以把这些构件部署到内部仓库(私服)中，供内部 Maven 项目使用。
+- 4、提高稳定性，增强控制：Internet 不稳定的时候，Maven 构建也会变的不稳定，一些私服软件还提供了其他的功能。
+- 5、降低中央仓库的负荷：Maven 中央仓库被请求的数量是巨大的，配置私服也可以大大降低中央仓库的压力。
+
+🚀 当前主流的 Maven 私服：
+
+- Apache 的 Archiva
+- JFrog 的 Artifactory
+- 【主流】Sonatype 的 Nexus 。
+
+🚀 常见的 Maven 私服的仓库类型：
+
+- （宿主仓库）hosted repository 。
+- （代理仓库）proxy repository 。
+- （仓库组）group repository 。
+
+对于大多数公司，一般来说使用 Nexus + 阿里云仓库的方式，可参考如下两篇文章：
+
+- [《使用 Nexus 搭建 Maven 私有仓库》](https://www.jianshu.com/p/9740778b154f)
+- [《Nexus 配置阿里云仓库》](https://blog.csdn.net/qq_30633989/article/details/80399596)
+
+🦅 **如何配置远程仓库？**
+
+用文本编辑器工具打开 `setting.xml` 文件，增加一个 `<mirror />`：
+
+> 艿艿：此处以阿里云为例子。
+
+```
+<mirrors>
+    <mirror>
+        <id>nexus-aliyun</id>
+        <mirrorOf>*</mirrorOf>
+        <name>Nexus aliyun</name>
+        <url>http://maven.aliyun.com/nexus/content/groups/public</url>
+    </mirror>
+</mirrors>
+```
+
+🦅 **如何使用 Maven 将 jar 包发布到中央仓库？**
+
+> 本小节为选读，适合开源作者，想要将自己的库发布到中央仓库，进行共享。
+
+详细的，参见 [《发布 jar 包到 Maven 中央仓库》](https://blog.csdn.net/ljbmxsm/article/details/78009268) 文章。
+
+## 彩蛋
+
+犹记得，11 年第一次在项目中引入 Maven 的惊艳，终于无需使用 Ant 带来的种种痛苦，以及每次更新项目，几百 M 一个，还有搭建项目时需要引入各种版本的依赖。
+
+参考与推荐如下文章：
+
+- [《Maven 面试基本知识点》](http://www.manongjc.com/article/36792.html)
+- [《JAVA 面试常问知识总结（十） —— Maven》](http://morecoder.com/article/1133612.html)
+- [《菜鸟面试必知的 Maven 知识》](http://aes.jypc.org/?p=22684)
+- [《面试题之 Maven》](https://nizouba.com/articles/2018/10/23/1540302457251.html)
\ No newline at end of file
diff --git a/面试题/26-Java【基础】面试题.assets/01.jpg b/面试题/26-Java【基础】面试题.assets/01.jpg
new file mode 100644
index 0000000..aa173a4
Binary files /dev/null and b/面试题/26-Java【基础】面试题.assets/01.jpg differ
diff --git a/面试题/26-Java【基础】面试题.assets/3b7fc781e8c5f9b354fbab05639dbcca.png b/面试题/26-Java【基础】面试题.assets/3b7fc781e8c5f9b354fbab05639dbcca.png
new file mode 100644
index 0000000..5cf9a58
Binary files /dev/null and b/面试题/26-Java【基础】面试题.assets/3b7fc781e8c5f9b354fbab05639dbcca.png differ
diff --git a/面试题/26-Java【基础】面试题.assets/eb408ac849a679b09941be7ebd734768.jpeg b/面试题/26-Java【基础】面试题.assets/eb408ac849a679b09941be7ebd734768.jpeg
new file mode 100644
index 0000000..d1a2eab
Binary files /dev/null and b/面试题/26-Java【基础】面试题.assets/eb408ac849a679b09941be7ebd734768.jpeg differ
diff --git a/面试题/26-Java【基础】面试题.md b/面试题/26-Java【基础】面试题.md
new file mode 100644
index 0000000..5bb0244
--- /dev/null
+++ b/面试题/26-Java【基础】面试题.md
@@ -0,0 +1,691 @@
+# 精尽 Java【基础】面试题「最新更新时间：2024-02」
+
+以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。
+
+如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的 Java【基础】面试题的大保健。
+
+而题目的难度，艿艿尽量按照从容易到困难的顺序，逐步下去。
+
+考虑到 Java 涉及的知识点非常非常非常之多，所以我们会分成五大篇来分享，分别是：
+
+- Java【基础】
+
+  > 本文。😈 分不到其它类别里的，都会放到本文。
+
+- Java【集合】
+
+- Java【并发】
+
+- Java【网络】
+
+  > 因为 Java 网络编程大多使用 Netty ，所以面试题统一整理到 [《精尽 Netty 面试题》](http://svip.iocoder.cn/Netty/Interview) 中，避免重复。
+
+- Java【虚拟机】
+
+## 什么是面向对象？
+
+面向对象是一种思想，世间万物都可以看做一个对象，这里只讨论面向对象编程（OOP），Java 是一个支持并发、基于类和面向对象的计算机编程语言。面向对象软件开发具有以下优点：
+
+- 代码开发模块化，更易维护和修改。
+- 代码复用性强。
+- 增强代码的可靠性和灵活性。
+- 增加代码的可读性。
+
+🦅 **请说说面向对象的特征？**
+
+四点：**封装**、**继承**、**多态**、**抽象**。
+
+> 艿艿：这个题目，能说出上述四点就好了。
+
+1）封装
+
+封装，给对象提供了隐藏内部特性和行为的能力。对象提供一些能被其他对象访问的方法来改变它内部的数据。在 Java 当中，有 4 种修饰符： `default`、`public`、`private` 和 `protected` 。每一种修饰符给其他的位于同一个包或者不同包下面对象赋予了不同的访问权限。
+
+下面列出了使用封装的一些好处：
+
+- 通过隐藏对象的属性来保护对象内部的状态。
+- 提高了代码的可用性和可维护性，因为对象的行为可以被单独的改变或者是扩展。
+- 禁止对象之间的不良交互提高模块化。
+
+2）继承
+
+继承，给对象提供了从基类获取字段和方法的能力。继承提供了代码的重用行，也可以在不修改类的情况下给现存的类添加新特性。
+
+3）多态
+
+多态，是编程语言给不同的底层数据类型做相同的接口展示的一种能力。一个多态类型上的操作，可以应用到其他类型的值上面。
+
+4）抽象
+
+抽象，是把想法从具体的实例中分离出来的步骤，因此，要根据他们的功能而不是实现细节来创建类。
+
+Java 支持创建只暴漏接口而不包含方法实现的抽象的类。这种抽象技术的主要目的是把类的行为和实现细节分离开。
+
+🦅 **面向对象和面向过程的区别？**
+
+- 面向过程
+  - 优点：性能比面向对象高，因为类调用时需要实例化，开销比较大，比较消耗资源。比如，单片机、嵌入式开发、Linux/Unix 等一般采用面向过程开发，性能是最重要的因素。
+  - 缺点：没有面向对象易维护、易复用、易扩展。
+- 面向对象
+  - 优点：易维护、易复用、易扩展，由于面向对象有封装、继承、多态性的特性，可以设计出低耦合的系统，使系统更加灵活、更加易于维护。
+  - 缺点：性能比面向过程低。
+
+🦅 **重载和重写的区别？**
+
+1）重写 `override`
+
+- 方法名、参数、返回值相同。
+- 子类方法不能缩小父类方法的访问权限。
+- 子类方法不能抛出比父类方法更多的异常(但子类方法可以不抛出异常)。
+- 存在于父类和子类之间。
+- 方法被定义为 `final` 不能被重写。
+
+2）重载 `overload`
+
+- 参数类型、个数、顺序至少有一个不相同。
+- 不能重载只有返回值不同的方法名。
+- 存在于父类和子类、同类中。
+
+🦅 **对比图**
+
+[对比图](https://user-gold-cdn.xitu.io/2018/5/9/16342c734014a933?imageView2/0/w/1280/h/960/format/jpeg/ignore-error/1)
+
+🦅 **Java 中，什么是构造方法？什么是构造方法重载？什么是拷贝构造方法？**
+
+1）构造方法
+
+当新对象被创建的时候，构造方法会被调用。每一个类都有构造方法。在程序员没有给类提供构造方法的情况下，Java 编译器会为这个类创建一个默认的构造方法。
+
+2）构造方法重载
+
+Java 中构造方法重载和方法重载很相似。可以为一个类创建多个构造方法。每一个构造方法必须有它自己唯一的参数列表。
+
+3）拷贝构造方法
+
+Java 不支持像 C++ 中那样的[拷贝构造方法](http://www.runoob.com/cplusplus/cpp-copy-constructor.html)，这个不同点是因为如果你不自己写构造方法的情况下，Java 不会创建默认的拷贝构造方法。
+
+## JDK、JRE、JVM 分别是什么关系？
+
+🦅 **JDK**
+
+JDK 即为 Java 开发工具包，包含编写 Java 程序所必须的编译、运行等开发工具以及 JRE。开发工具如：
+
+- 用于编译 Java 程序的 javac 命令。
+- 用于启动 JVM 运行 Java 程序的 Java 命令。
+- 用于生成文档的 Javadoc 命令。
+- 用于打包的 jar 命令等等。
+
+> 简单说，就是 JDK 包含 JRE 包含 JVM。
+
+🦅 **JRE**
+
+JRE 即为 Java 运行环境，提供了运行 Java 应用程序所必须的软件环境，包含有 Java 虚拟机（JVM）和丰富的系统类库。系统类库即为 Java 提前封装好的功能类，只需拿来直接使用即可，可以大大的提高开发效率。
+
+> 简单说，就是 JRE 包含 JVM。
+
+🦅 **JVM**
+
+JVM 即为 Java 虚拟机，提供了字节码文件(`.class`)的运行环境支持。
+
+> [![JDK > JRE > JVM](26-Java【基础】面试题.assets/01.jpg)](http://static.iocoder.cn/images/JDK/2020_02_01/01.jpg)JDK > JRE > JVM
+
+🦅 **为什么 Java 被称作是“平台无关的编程语言”？**
+
+Java 虚拟机是一个可以执行 Java 字节码的虚拟机进程。
+
+- Java 源文件( `.java` )被编译成能被 Java 虚拟机执行的字节码文件( `.class` )。
+- Java 被设计成允许应用程序可以运行在任意的平台，而不需要程序员为每一个平台单独重写或者是重新编译。Java 虚拟机让这个变为可能，因为它知道底层硬件平台的指令长度和其他特性。
+
+🦅 **JDK 各版本的新特性？**
+
+- JDK5 ~ JDK10 ，看 https://www.jianshu.com/p/37b52f1ebd4a 。
+- JDK11 ，看 https://www.jianshu.com/p/81b65eded96c 。
+
+对于大多数面试官，肯定不会问你 JDK 各版本的新特性，更多的会问 JDK8 引入了什么重要的特性？一般上，关键的回答是Lambda 表达式和集合之流式操作，然后说说你在项目中怎么使用的。
+
+🦅 **Java 和 C++ 的区别？**
+
+- 都是面向对象的语言，都支持封装、继承和多态。
+- Java 不提供指针来直接访问内存，程序内存更加安全。
+- Java 的类是单继承的，C++ 支持多重继承；虽然 Java 的类不可以多继承，但是接口可以多继承。
+- 【重要】Java 有自动内存管理机制，不需要程序员手动释放无用内存。
+
+## 什么是字节码？采用字节码的最大好处是什么？
+
+🦅 **什么是字节码？**
+
+> 这个问题，面试官可以衍生提问，Java 是编译执行的语言，还是解释执行的语言。
+
+Java 中引入了虚拟机的概念，即在机器和编译程序之间加入了一层抽象的虚拟的机器。这台虚拟的机器在任何平台上都提供给编译程序一个的共同的接口。
+
+编译程序只需要面向虚拟机，生成虚拟机能够理解的代码，然后由解释器来将虚拟机代码转换为特定系统的机器码执行。在 Java 中，这种供虚拟机理解的代码叫做字节码（即扩展名为 `.class` 的文件），它不面向任何特定的处理器，只面向虚拟机。
+
+每一种平台的解释器是不同的，但是实现的虚拟机是相同的。Java 源程序经过编译器编译后变成字节码，字节码由虚拟机解释执行，虚拟机将每一条要执行的字节码送给解释器，解释器将其翻译成特定机器上的机器码，然后在特定的机器上运行。**这也就是解释了 Java 的编译与解释并存的特点**。
+
+```
+Java 源代码
+=> 编译器 => JVM 可执行的 Java 字节码(即虚拟指令)
+=> JVM => JVM 中解释器 => 机器可执行的二进制机器码 => 程序运行
+```
+
+🦅 **采用字节码的好处？**
+
+Java 语言通过字节码的方式，在一定程度上解决了传统解释型语言执行效率低的问题，同时又保留了解释型语言可移植的特点。所以 Java 程序运行时比较高效，而且，由于字节码并不专对一种特定的机器，因此，Java程序无须重新编译便可在多种不同的计算机上运行。
+
+> 解释型语言：解释型语言，是在运行的时候将程序翻译成机器语言。解释型语言的程序不需要在运行前编译，在运行程序的时候才翻译，专门的解释器负责在每个语句执行的时候解释程序代码。这样解释型语言每执行一次就要翻译一次，效率比较低。——百度百科
+>
+> 例如：Python、PHP 。
+
+## Java 中的几种基本数据类型是什么？各自占用多少字节？
+
+Java 支持的数据类型包括基本数据类型和引用类型。
+
+**基本数据**类型如下：
+
+- 整数值型：`byte`、`short`、`int`、`long`
+- 字符型：`char`
+- 浮点类型：`float`、`double`
+- 布尔型：`boolean`
+- 整数型：默认 `int` 型，小数默认是 `double` 型。Float 和 Long 类型的必须加后缀。比如：`float f = 100f` 。
+
+**引用类型**声明的变量是指该变量在内存中实际存储的是一个引用地址，实体在堆中。
+
+- 引用类型包括类、接口、数组等。
+- 特别注意，String 是引用类型不是基本类型。
+
+🦅 **什么是值传递和引用传递？**
+
+- 值传递，是对基本型变量而言的，传递的是该变量的一个副本，改变副本不影响原变量。
+- 引用传递，一般是对于对象型变量而言的，传递的是该对象地址的一个副本，并不是原对象本身。
+
+一般认为，Java 内的传递都是值传递，Java 中实例对象的传递是引用传递。
+
+🦅 **是否可以在 static 环境中访问非 static 变量？**
+
+`static` 变量在 Java 中是属于类的，它在所有的实例中的值是一样的。当类被 Java 虚拟机载入的时候，会对 `static` 变量进行初始化。
+
+如果你的代码尝试不用实例来访问非 `static` 的变量，编译器会报错，因为这些变量还没有被创建出来，还没有跟任何实例关联上。
+
+🦅 **char 型变量中能不能存贮一个中文汉字？为什么？**
+
+- 在 C 语言中，char 类型占 1 个字节，而汉字占 2 个字节，所以不能存储。
+- 在 Java 语言中，char 类型占 2 个字节，而且 Java 默认采用 Unicode 编码，一个 Unicode 码是 16 位，所以一个 Unicode 码占两个字节，Java 中无论汉字还是英文字母，都是用 Unicode 编码来表示的。所以，在 Java 中，char 类型变量可以存储一个中文汉字。
+
+## String、StringBuffer、StringBuilder 的区别？
+
+Java 平台提供了两种类型的字符串：String 和 StringBuffer/StringBuilder，它们可以储存和操作字符串。
+
+- String ，是只读字符串，也就意味着 String 引用的字符串内容是不能被改变的。
+
+  > 每次对 String 类型进行改变的时候，都会生成一个新的 String 对象，然后将指针指向新的 String 对象。
+
+- StringBuffer/StringBuilder 类，表示的字符串对象可以直接进行修改。StringBuilder 是 Java 5 中引入的，它和 StringBuffer 的方法完全相同，区别在于它是在单线程环境下使用的，因为它的所有方面都没有被 `synchronized` 修饰，因此它的效率也比 StringBuffer 要高。
+
+  > StringBuffer 每次都会对 StringBuffer 对象本身进行操作，而不是生成新的对象并改变对象引用。
+  >
+  > 相同情况下使用 StirngBuilder 相比使用 StringBuffer 仅能获得 10%~15% 左右的性能提升，但却要冒多线程不安全的风险。
+
+🦅 **对于三者使用的总结？**
+
+- 操作少量的数据 = String 。
+
+  > 这个也是实际编码较为经常使用的方式。
+
+- 单线程操作字符串缓冲区下操作大量数据 = StringBuilder 。
+
+  > 甚至有时，我们为了避免每个线程重复创建 StringBuilder 对象，会通过 ThreadLocal + StringBuilder 的方式，进行对 StringBuilder 的重用。具体可以参考 [《StringBuilder 在高性能场景下的正确用法》](http://nathanchen.github.io/14596982516208.html) 文章。
+
+- 多线程操作字符串缓冲区下操作大量数据 = StringBuffer
+
+  > 实际场景下，我们基本不太会出现，多线程操作同一个 StringBuffer 对象。
+
+🦅 **`String s = new String("xyz")` 会创建几个对象？**
+
+- 首先，在 String 池内找，找到 `"xyz"` 字符串，不创建 `"xyz"` 对应的 String 对象，否则创建一个对象。
+- 然后，遇到 `new` 关键字，在内存上创建 String 对象，并将其返回给 `s` ，又一个对象。
+
+所以，总共是 1 个或者 2 个对象。
+
+具体的，可以看看 [《关于String s = new String(“xyz”); 创建几个对象的问题》](https://blog.csdn.net/tzs_1041218129/article/details/69367423) 文章的测试代码。
+
+🦅 **String 为什么是不可变的？**
+
+简单的来说，String 类中使用 `final` 关键字字符数组保存字符串。代码如下：
+
+```
+// String.java
+
+private final char[] value;
+```
+
+- 所以 String 对象是不可变的。
+
+而 StringBuilder 与 StringBuffer 都继承自 AbstractStringBuilder 类，在 AbstractStringBuilder 中也是使用字符数组保存字符串 `char[] value` ，但是没有用 `final` 关键字修饰。代码如下：
+
+```
+// AbstractStringBuilder.java
+
+char[] value;
+```
+
+- 所以这两种对象都是可变的。
+
+🦅 **StringTokenizer 是什么？**
+
+StringTokenizer ，是一个用来分割字符串的工具类。
+
+示例代码如下：
+
+```
+StringTokenizer st = new StringTokenizer(”Hello World”);
+while (st.hasMoreTokens()) {
+    System.out.println(st.nextToken());
+}
+```
+
+输出如下：
+
+```
+Hello
+World
+```
+
+## 什么是自动拆装箱？
+
+自动装箱和拆箱，就是基本类型和引用类型之间的转换。
+
+🦅 **为什么要转换？**
+
+如果你在 Java5 下进行过编程的话，你一定不会陌生这一点，你不能直接地向集合( Collection )中放入原始类型值，因为集合只接收对象。
+
+- 通常这种情况下你的做法是，将这些原始类型的值转换成对象，然后将这些转换的对象放入集合中。使用 Integer、Double、Boolean 等这些类，我们可以将原始类型值转换成对应的对象，但是从某些程度可能使得代码不是那么简洁精炼。
+- 为了让代码简练，Java5 引入了具有在原始类型和对象类型自动转换的装箱和拆箱机制。
+- 但是自动装箱和拆箱并非完美，在使用时需要有一些注意事项，如果没有搞明白自动装箱和拆箱，可能会引起难以察觉的 Bug 。
+
+🦅 **int 和 Integer 有什么区别？**
+
+- `int` 是基本数据类型。
+- Integer 是其包装类，注意是一个类。
+
+当然，要注意下 Integer 的缓存策略，可以看看 [《理解Java Integer 的缓存策略》](http://www.importnew.com/18884.html) 文章。
+
+## equals 与 == 的区别？
+
+- 值类型（
+
+  ```
+  int
+  ```
+
+  ,
+
+  ```
+  char
+  ```
+
+  ,
+
+  ```
+  long
+  ```
+
+  ,
+
+  ```
+  boolean
+  ```
+
+   
+
+  等）的话
+
+  - 都是用 == 判断相等性。
+
+- 对象引用的话
+
+  - == 判断引用所指的对象是否是同一个。
+
+  - equals 方法，是 Object 的成员函数，有些类会覆盖(`override`) 这个方法，用于判断对象的等价性。
+
+    > 例如 String 类，两个引用所指向的 String 都是 `"abc"` ，但可能出现他们实际对应的对象并不是同一个（和 JVM 实现方式有关），因此用 == 判断他们可能不相等，但用 equals 方法判断一定是相等的。
+
+🦅 **如何在父类中为子类自动完成所有的 hashCode 和 equals 实现？这么做有何优劣？**
+
+父类的 equals ，一般情况下是无法满足子类的 equals 的需求。
+
+- 比如所有的对象都继承 Object ，默认使用的是 Object 的 equals 方法，在比较两个对象的时候，是看他们是否指向同一个地址。但是我们的需求是对象的某个属性相同，就相等了，而默认的 equals 方法满足不了当前的需求，所以我们要重写 equals 方法。
+- 如果重写了 equals 方法，就必须重写 hashCode 方法，否则就会降低 Map 等集合的索引速度。
+
+🦅 **说一说你对 `java.lang.Object` 对象中 hashCode 和 equals 方法的理解。在什么场景下需要重新实现这两个方法?**
+
+这个问题，和上个 [「如何在父类中为子类自动完成所有的 hashCode 和 equals 实现？这么做有何优劣？」](https://svip.iocoder.cn/Java/Core/Interview/#) 一样的答案。
+
+🦅 **这样的 a.hashCode() 有什么用，与 a.equals(b) 有什么关系?**
+
+> 这个问题，和上述问题，就是换个姿势，差不了太多。
+
+1. equals 方法，用于比较对象的内容是否相等。
+
+   > 当覆盖了 equals 方法时，比较对象是否相等将通过覆盖后的 equals 方法进行比较（判断对象的内容是否相等）。
+
+2. hashCode 方法，大多在集合中用到。
+
+   > 将对象放入到集合中时，首先判断要放入对象的 hashCode 值与集合中的任意一个元素的 hashCode 值是否相等，如果不相等直接将该对象放入集合中。
+   >
+   > 如果 hashCode 值相等，然后再通过 equals 方法判断要放入对象与集合中的任意一个对象是否相等，如果 equals 判断不相等，直接将该元素放入到集合中，否则不放入。
+
+🦅 **有没有可能 2 个不相等的对象有相同的 hashCode？**
+
+可能会发生，这个被称为**哈希碰撞**。当然，相等的对象，即我们重写了 equals 方法，一定也要重写 hashCode 方法，否则将出现我们在 HashMap 中，相等的对象作为 key ，将找不到对应的 value 。
+
+所以说，equals 和 hashCode 的关系会是：
+
+- equals 不相等，hashCode 可能相等。
+- equals 相等，请重写 hashCode 方法，保证 hashCode 相等。
+
+一般来说，hashCode 方法的重写，可以看看 [《科普：为什么 String hashCode 方法选择数字31作为乘子》](https://segmentfault.com/a/1190000010799123) 方法。
+
+## final、finally、finalize 的区别？
+
+1）final
+
+`final` ，是修饰符关键字。
+
+- 如果一个类被声明为 `final` ，意味着它不能再派生出新的子类，不能作为父类被继承。因此一个类不能既被声明为 `abstract` 的，又被声明为 `final` 的。
+- 将变量或方法声明为 `final` ，可以保证它们在使用中不被改变。被声明为 final 的变量必须在声明时给定初值，而在以后的引用中只能读取，不可修改。被声明为 `final` 的方法也同样只能使用，不能重写。
+
+> 另外，在早期的 Java 实现版本中，会将 `final` 方法转为内嵌调用。但是如果方法过于庞大，可能看不到内嵌调用带来的任何性能提升（现在的 Java 版本已经不需要使用 `final` 方法进行这些优化了）。类中所有的`private` 方法都隐式地指定为 `final` 。
+
+2）finally
+
+在异常处理时提供 `finally` 块来执行任何清除操作。如果抛出一个异常，那么相匹配的 `catch` 子句就会执行，然后控制就会进入 `finally` 块（如果有的话）。
+
+在以下 4 种特殊情况下，finally块不会被执行：
+
+- 在 `finally` 语句块中发生了异常。
+- 在前面的代码中用了 `System.exit()` 退出程序。
+- 程序所在的线程死亡。
+- 关闭 CPU 。
+
+3）finalize
+
+`finalize` ，是方法名。
+
+Java 允许使用 `#finalize()` 方法，在垃圾收集器将对象从内存中清除出去之前做必要的清理工作。这个方法是由垃圾收集器在确定这个对象没有被引用时对这个对象调用的。
+
+- 它是在 Object 类中定义的，因此所有的类都继承了它。
+- 子类覆盖 `finalize()` 方法，以整理系统资源或者执行其他清理工作。
+- `#finalize()` 方法，是在垃圾收集器删除对象之前对这个对象调用的。
+
+一般情况下，我们在业务中不会自己实现这个方法，更多是在一些框架中使用，例如 [《Netty Using finalize() to release ByteBufs》](https://github.com/netty/netty/issues/4145) 。
+
+🦅 **String 类能被继承吗，为什么？**
+
+不能，因为 String 是 `final` 修饰。
+
+## 抽象类和接口有什么区别？
+
+从设计层面来说，抽象是对类的抽象，是一种模板设计，接口是行为的抽象，是一种行为的规范。
+
+- Java 提供和支持创建抽象类和接口。它们的实现有共同点，不同点在于：接口中所有的方法隐含的都是抽象的，而抽象类则可以同时包含抽象和非抽象的方法。
+- 类可以实现很多个接口，但是只能继承一个抽象类。类可以不实现抽象类和接口声明的所有方法，当然，在这种情况下，类也必须得声明成是抽象的。
+- 抽象类可以在不提供接口方法实现的情况下实现接口。
+- Java 接口中声明的变量默认都是 `final` 的。抽象类可以包含非 `final` 的变量。
+- Java 接口中的成员函数默认是 `public` 的。抽象类的成员函数可以是 `private`，`protected` 或者是 `public` 。
+- 接口是绝对抽象的，不可以被实例化。抽象类也不可以被实例化，但是，如果它包含 `#main(String[] args)` 方法的话是可以被调用的。
+
+🦅 **继承和组合的区别在哪？**
+
+- 继承：指的是一个类（称为子类、子接口）继承另外的一个类（称为父类、父接口）的功能，并可以增加它自己的新功能的能力，继承是类与类或者接口与接口之间最常见的关系。在 Java 中，此类关系通过关键字 `extends` 明确标识，在设计时一般没有争议性。
+- 组合：组合是关联关系的一种特例，他体现的是整体与部分、拥有的关系，即 has-a 的关系，此时整体与部分之间是可分离的，他们可以具有各自的生命周期，部分可以属于多个整体对象，也可以为多个整体对象共享。
+  - 比如，计算机与 CPU 、公司与员工的关系等。
+  - 表现在代码层面，和关联关系是一致的，只能从语义级别来区分。
+
+因为组合能带来比继承更好的灵活性，所以有句话叫做“组合优于继承”。感兴趣的胖友，可以看看 [《怎样理解“组合优于继承”以及“OO的反模块化”，在这些方面FP具体来说有什么优势？》](https://www.zhihu.com/question/21862257) 文章。
+
+🦅 **请详细讲述一下 RandomAccess 接口有什么作用？**
+
+RandomAccess 用来当标记的，是一种**标记**接口，接口的非典型用法。意思是，随机访问任意下标元素都比较快。
+
+用处，当要实现某些算法时，会判断当前类是否实现了 RandomAccess 接口，会根据结果选择不同的算法。
+
+## 讲讲类的实例化顺序？
+
+初始化顺序如下：
+
+- 父类静态变量
+- 父类静态代码块
+- 子类静态变量、
+- 子类静态代码块
+- 父类非静态变量（父类实例成员变量）
+- 父类构造函数
+- 子类非静态变量（子类实例成员变量）
+- 子类构造函数
+
+感兴趣的胖友，可以详细看看 [《Java 类的实例化顺序》](https://blog.csdn.net/Vencc__/article/details/52222628) 文章，提供的示例。
+
+## 什么是内部类？
+
+简单的说，就是在一个类、接口或者方法的内部创建另一个类。这样理解的话，创建内部类的方法就很明确了。当然，详细的可以看看 [《Java 内部类总结（吐血之作）》](https://blog.csdn.net/hikvision_java_gyh/article/details/8964155) 文章。
+
+🦅 **内部类的作用是什么？**
+
+内部类提供了更好的封装，除了该外围类，其他类都不能访问。
+
+🦅 **Anonymous Inner Class(匿名内部类)是否可以继承其它类？是否可以实现接口？**
+
+可以继承其他类或实现其他接口，在 Java 集合的流式操作中，我们常常这么干。
+
+🦅 **内部类可以引用它的包含类（外部类）的成员吗？有没有什么限制？**
+
+一个内部类对象可以访问创建它的外部类对象的成员，包括私有成员。
+
+## 什么是 Java IO ？
+
+Java IO 相关的类，在 `java.io` 包下，具体操作分成面向字节(Byte)和面向字符(Character)两种方式。如下图所示：
+
+[![类图](26-Java【基础】面试题.assets/eb408ac849a679b09941be7ebd734768.jpeg)](http://static.iocoder.cn/eb408ac849a679b09941be7ebd734768)类图
+
+## 什么是 Java 序列化？
+
+序列化就是一种用来处理对象流的机制，所谓对象流也就是将对象的内容进行流化。
+
+- 可以对流化后的对象进行读写操作，也可将流化后的对象传输于网络之间。
+- 序列化是为了解决在对对象流进行读写操作时所引发的问题。
+
+反序列化的过程，则是和序列化相反的过程。
+
+> 另外，我们不能将序列化局限在 Java 对象转换成二进制数组，例如说，我们将一个 Java 对象，转换成 JSON 字符串，或者 XML 字符串，这也可以理解为是序列化。
+
+🦅 **如何实现 Java 序列化？**
+
+> 如下的方式，就是 Java 内置的序列化方案，实际场景下，我们可以自定义序列化的方案，例如说 Google Protobuf 。
+
+将需要被序列化的类，实现 Serializable 接口，该接口没有需要实现的方法，`implements Serializable` 只是为了标注该对象是可被序列化的。
+
+- 序列化
+  - 然后，使用一个输出流(如：FileOutputStream)来构造一个 ObjectOutputStream(对象流)对象
+  - 接着，使用 ObjectOutputStream 对象的 `#writeObject(Object obj)` 方法，就可以将参数为 `obj` 的对象写出(即保存其状态)。
+- 反序列化
+  - 要恢复的话则用输入流。
+
+🦅 **Java 序列话中，如果有些字段不想进行序列化怎么办？**
+
+对于不想进行序列化的变量，使用 `transient` 关键字修饰。
+
+- 当对象被序列化时，阻止实例中那些用此关键字修饰的的变量序列化。
+- 当对象被反序列化时，被 `transient` 修饰的变量值不会被持久化和恢复。
+- `transient` 只能修饰变量，不能修饰类和方法。
+
+## 如何实现对象克隆？
+
+一般来说，有两种方式：
+
+- 1、实现 Cloneable 接口，并重写 Object 类中的 `#clone()` 方法。可以实现**浅克隆**，也可以实现**深克隆**。
+- 2、实现 Serializable 接口，通过对象的序列化和反序列化实现克隆。可以实现真正的**深克隆**。
+
+> 艿艿：这个问题，也可以变种来问，什么是**浅克隆**和**深克隆**。
+
+具体的代码实现，可以看看 [《Java 对象的浅克隆和深克隆》](https://blog.csdn.net/caomiao2006/article/details/52590622) 文章。
+
+实际场景下，我们使用的克隆比较少，更多是对象之间的属性克隆。例如说，将 DO 的属性复制到 DTO 中，又或者将 DTO 的属性复制到 VO 中。此时，我们一般使用 BeanUtils 工具类。具体的使用，看看 [《浅谈 BeanUtils 的拷贝，深度克隆》](https://www.cnblogs.com/tison/p/7840647.html) 文章。
+
+## error 和 exception 有什么区别？CheckedException 和 RuntimeException 有什么区别？
+
+Java 的异常体系，基于共同的祖先 `java.lang.Throwable` 类。如下图所示：
+
+[![Throwable 类图](26-Java【基础】面试题.assets/3b7fc781e8c5f9b354fbab05639dbcca.png)](http://static.iocoder.cn/3b7fc781e8c5f9b354fbab05639dbcca)Throwable 类图
+
+> 感谢【贾鹤鸣】胖友指出的问题。图有点问题：
+>
+> 1. 图中的 ArrithmeticException 异常，多了一个 r ，正确拼写是 ArithmeticException 。
+> 2. 图中 ClassNotFoundException 异常，父类是 `ReflectiveOperationException => Exception` ，不属于 RunTimeException 。
+
+- Error（错误），表示系统级的错误和程序不必处理的异常，是 Java 运行环境中的内部错误或者硬件问题。
+  - 例如：内存资源不足等。
+  - 对于这种错误，程序基本无能为力，除了退出运行外别无选择，它是由 Java 虚拟机抛出的。
+- Exception（异常），表示需要捕捉或者需要程序进行处理的异常，它处理的是因为程序设计的瑕疵而引起的问题或者在外的输入等引起的一般性问题，是程序必须处理的。Exception 又分为运行时异常，受检查异常。
+  - RuntimeException(运行时异常)，表示无法让程序恢复的异常，导致的原因通常是因为执行了错误的操作，建议终止逻辑，因此，编译器不检查这些异常。
+  - CheckedException(受检查异常)，是表示程序可以处理的异常，也即表示程序可以修复（由程序自己接受异常并且做出处理），所以称之为受检查异常。
+
+🦅 **异常的使用的注意地方？**
+
+神作《Effective Java》中对异常的使用给出了以下指导原则：
+
+> 艿艿：该书，十分推荐去阅读。
+
+- 不要将异常处理用于正常的控制流（设计良好的 API 不应该强迫它的调用者为了正常的控制流而使用异常）。
+- 对可以恢复的情况使用受检异常，对编程错误使用运行时异常。
+- 避免不必要的使用受检异常（可以通过一些状态检测手段来避免异常的发生）。
+- 优先使用标准的异常。
+- 每个方法抛出的异常都要有文档。
+- 保持异常的原子性
+- 不要在 `catch` 中忽略掉捕获到的异常。
+
+🦅 **Throwable 类常用方法？**
+
+- `#getMessage()` 方法：返回异常发生时的详细信息。
+
+- `#getCause()` 方法：获得导致当前 Throwable 异常的 Throwable 异常。
+
+- ```
+  #getStackTrace()
+  ```
+
+   
+
+  方法：获得 Throwable 对象封装的异常信息。
+
+  - `#printStackTrace()` 方法：在控制台上打印。
+
+🦅 **请列出 5 个运行时异常？**
+
+- NullPointerException
+- IndexOutOfBoundsException
+- ClassCastException
+- ArrayStoreException
+- BufferOverflowException
+
+🦅 **`throw` 与 `throws` 的区别 ？**
+
+- `throw` ，用于在程序中显式地抛出一个异常。
+- `throws` ，用于指出在该方法中没有处理的异常。**每个方法必须显式指明哪些异常没有处理，以便该方法的调用者可以预防可能发生的异常**。最后，多个异常用逗号分隔。
+
+🦅 **异常处理中 `finally` 语句块的重要性?**
+
+不管程序是否发生了异常, `finally` 语句块都会被执行，甚至当没有`catch` 声明但抛出了一个异常时, `finally` 语句块也会被执行。
+
+`finally` 语句块通常用于释放资源, 如 I/O 缓冲区, 数据库连接等等。
+
+🦅 **异常被处理后异常对象会发生什么?**
+
+> 艿艿：这个问题有点奇怪，从网上找来的…
+
+异常对象会在下次 GC 执行时被回收。
+
+## 说说反射的用途及实现？
+
+Java 反射机制主要提供了以下功能：
+
+- 在运行时构造一个类的对象。
+- 判断一个类所具有的成员变量和方法。
+- 调用一个对象的方法。
+- 生成动态代理。
+
+反射的应用很多，很多框架都有用到：
+
+- Spring 框架的 IoC 基于反射创建对象和设置依赖属性。
+- Spring MVC 的请求调用对应方法，也是通过反射。
+- JDBC 的 `Class#forName(String className)` 方法，也是使用反射。
+
+不了解 Java 反射的同学，可以看看 [《什么是反射、反射可以做些什么》](http://www.cnblogs.com/zhaopei/p/reflection.html) 。
+
+> 对于大多数 Java 萌新，包括艿艿在内。不过后来发现，再难的 Java 知识，未来都需要变成我们的基础知识，嘻嘻。
+
+🦅 **反射中，Class.forName 和 ClassLoader 区别？**
+
+这两者，都可用来对类进行加载。差别在于：
+
+- `Class#forName(...)` 方法，除了将类的 `.class` 文件加载到JVM 中之外，还会对类进行解释，执行类中的 `static` 块。
+
+- ClassLoader 只干一件事情，就是将 `.class` 文件加载到 JVM 中，不会执行 `static` 中的内容，只有在 newInstance 才会去执行 `static` 块。
+
+  > `Class#forName(name, initialize, loader)` 方法，带参函数也可控制是否加载 `static` 块，并且只有调用了newInstance 方法采用调用构造函数，创建类的对象。
+
+详细的测试，可以看看 [《Java 反射中，Class.forName 和ClassLoader 的区别(代码说话)》](https://blog.csdn.net/qq_27093465/article/details/52262340) 文章。
+
+🦅 **UnsupportedOperationException 是什么？**
+
+UnsupportedOperationException ，是用于表明操作不支持的异常。
+
+在 JDK 类中已被大量运用，在集合框架`java.util.Collections.UnmodifiableCollection` 将会在所有 add 和 remove 操作中抛出这个异常。
+
+## 什么是注解？
+
+直接看 [《深入浅出 Java 注解》](https://www.jianshu.com/p/5cac4cb9be54) 。
+
+如果胖友没有自己实现自定义的注解，千万一定马上去尝试写下。酱紫，我们会对注解，有更好且清晰的认识。
+
+## 什么时候用断言（`assert`）？
+
+断言，在软件开发中是一种常用的调试方式，很多开发语言中都支持这种机制。
+
+- 一般来说，断言用于保证程序最基本、关键的正确性。断言检查通常在开发和测试时开启。为了保证程序的执行效率，在软件发布后断言检查通常是关闭的。
+
+- 断言是一个包含布尔表达式的语句，在执行这个语句时假定该表达式为`true`；如果表达式的值为 `false` ，那么系统会报告一个AssertionError 错误。断言的使用如下面的代码所示：
+
+  ```
+  assert(a > 0); // throws an AssertionError if a <= 0
+  ```
+
+  - 断言可以有两种形式：
+    - `assert Expression1;` 。
+    - `assert Expression1 : Expression2;` 。
+    - Expression1 应该总是产生一个布尔值。
+    - Expression2 可以是得出一个值的任意表达式；这个值用于生成显示更多调试信息的字符串消息。
+
+- 要在运行时启用断言，可以在启动 JVM 时使用 `-enableassertions` 或者 `-ea` 标记。要在运行时选择禁用断言，可以在启动 JVM 时使用 `-da` 或者 `-disableassertions` 标记。要在系统类中启用或禁用断言，可使用 `-esa` 或 `-dsa` 标记。还可以在包的基础上启用或者禁用断言。
+
+当然，实际场景下，我们会在 Spring 的源码中看到，它自己封装了 Assert 类，实现更方便的断言功能，并且，在生产环境下也启用。
+
+另外，在单元测试中，也会使用自己封装的断言类，判断执行结果的正确与错误。
+
+## Java 对象创建的方式？
+
+1. 使用 `new` 关键字创建对象。
+2. 使用 Class 类的 newInstance 方法(反射机制)。
+3. 使用 Constructor 类的 newInstance 方法(反射机制)。
+4. 使用 clone 方法创建对象。
+5. 使用(反)序列化机制创建对象。
+
+## 彩蛋
+
+一写到 Java 基础，怎么说呢？就觉着概念挺多的，有点无从下手。实际情况下呢，艿艿自己面试的时候，很多问题可能都不太会问。那么，就把本文当成一种复习的文章吧，哈哈哈哈。
+
+参考与推荐如下文章：
+
+- [《2018 年最新 Java 面试题及答案整理》](https://juejin.im/entry/5af2557c6fb9a07aa83eb59c)
+- [《32 道常见的 Java 基础面试题》](http://www.ituring.com.cn/article/507089)
+- [《Java 总结》](http://www.n35n.com/2017/07/JAVA总结/)
+- [《Java 基础知识》](https://github.com/Snailclimb/JavaGuide/blob/3dc5234d3a77d134e4768b17cc864c4cc1030e41/Java相关/Java基础知识.md)
+- [Java 面试宝典](http://wiki.jikexueyuan.com/project/java-interview-bible/basic-concept.html)
\ No newline at end of file
diff --git a/面试题/27-Java【集合】面试题.assets/jpeg.webp b/面试题/27-Java【集合】面试题.assets/jpeg.webp
new file mode 100644
index 0000000..37de5db
Binary files /dev/null and b/面试题/27-Java【集合】面试题.assets/jpeg.webp differ
diff --git a/面试题/27-Java【集合】面试题.md b/面试题/27-Java【集合】面试题.md
new file mode 100644
index 0000000..2506f6f
--- /dev/null
+++ b/面试题/27-Java【集合】面试题.md
@@ -0,0 +1,487 @@
+# 精尽 Java【集合】面试题「最新更新时间：2024-02」
+
+以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。
+
+如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的 Java【集合】面试题的大保健。
+
+而题目的难度，艿艿尽量按照从容易到困难的顺序，逐步下去。
+
+[![Java 集合的脑图](27-Java【集合】面试题.assets/jpeg.webp)](https://upload-images.jianshu.io/upload_images/1637925-3ef7a86d5856e763.png?imageMogr2/auto-orient/strip|imageView2/2/w/747/format/jpeg)Java 集合的脑图
+
+# 基础
+
+## Java 集合框架有哪些？
+
+Java 集合框架，可以看看 [《Java 集合框架》](http://www.runoob.com/java/java-collections.html) 文章。
+
+🦅 **说出一些集合框架的优点？**
+
+集合框架的部分优点如下：
+
+- 1、使用核心集合类降低开发成本，而非实现我们自己的集合类。
+- 2、随着使用经过严格测试的集合框架类，代码质量会得到提高。
+- 3、通过使用 JDK 附带的集合类，可以降低代码维护成本。
+- 4、复用性和可操作性。
+
+🦅 **集合框架中的泛型有什么优点？**
+
+Java5 引入了泛型，所有的集合接口和实现都大量地使用它。泛型允许我们为集合提供一个可以容纳的对象类型。因此，如果你添加其它类型的任何元素，它会在编译时报错。这避免了在运行时出现 ClassCastException，因为你将会在编译时得到报错信息。
+
+泛型也使得代码整洁，我们不需要使用显式转换和 `instanceOf` 操作符。它也给运行时带来好处，因为不会产生类型检查的字节码指令。
+
+## Java 集合框架的基础接口有哪些？
+
+- Collection ，为集合层级的根接口。一个集合代表一组对象，这些对象即为它的元素。Java 平台不提供这个接口任何直接的实现。
+  - Set ，是一个不能包含重复元素的集合。这个接口对数学集合抽象进行建模，被用来代表集合，就如一副牌。
+  - List ，是一个有序集合，可以包含重复元素。你可以通过它的索引来访问任何元素。List 更像长度动态变换的数组。
+- Map ，是一个将 key 映射到 value 的对象。一个 Map 不能包含重复的 key，每个 key 最多只能映射一个 value 。
+- 一些其它的接口有 Queue、Dequeue、SortedSet、SortedMap 和 ListIterator 。
+
+🦅 **为何 Collection 不从 Cloneable 和 Serializable 接口继承？**
+
+Collection 接口指定一组对象，对象即为它的元素。
+
+- 如何维护这些元素由 Collection 的具体实现决定。例如，一些如 List 的 Collection 实现允许重复的元素，而其它的如 Set 就不允许。
+- 很多 Collection 实现有一个公有的 clone 方法。然而，把它放到集合的所有实现中也是没有意义的。这是因为 Collection 是一个抽象表现，重要的是实现。
+
+当与具体实现打交道的时候，克隆或序列化的语义和含义才发挥作用。所以，具体实现应该决定如何对它进行克隆或序列化，或它是否可以被克隆或序列化。在所有的实现中授权克隆和序列化，最终导致更少的灵活性和更多的限制，**特定的实现应该决定它是否可以被克隆和序列化**。
+
+🦅 **为何 Map 接口不继承 Collection 接口？**
+
+尽管 Map 接口和它的实现也是集合框架的一部分，但 Map 不是集合，集合也不是 Map。因此，Map 继承 Collection 毫无意义，反之亦然。
+
+如果 Map 继承 Collection 接口，那么元素去哪儿？Map 包含 key-value 对，它提供抽取 key 或 value 列表集合( Collection )的方法，但是它不适合“一组对象”规范。
+
+🦅 **Collection 和 Collections 的区别？**
+
+- Collection ，是集合类的上级接口，继承与他的接口主要有 Set 和List 。
+- Collections ，是针对集合类的一个工具类，它提供一系列静态方法实现对各种集合的搜索、排序、线程安全化等操作。
+
+🦅 **集合框架里实现的通用算法有哪些？**
+
+Java 集合框架提供常用的算法实现，比如排序和搜索。
+
+Collections类包含这些方法实现。大部分算法是操作 List 的，但一部分对所有类型的集合都是可用的。部分算法有排序、搜索、混编、最大最小值。
+
+🦅 **集合框架底层数据结构总结**
+
+1）List
+
+- ArrayList ：Object 数组。
+- Vector ：Object 数组。
+- LinkedList ：双向链表(JDK6 之前为循环链表，JDK7 取消了循环)。
+
+2）Map
+
+- HashMap ：
+  - JDK8 之前，HashMap 由数组+链表组成的，数组是HashMap的主体，链表则是主要为了解决哈希冲突而存在的（“拉链法”解决冲突）。
+  - JDK8 以后，在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为 8 ）时，将链表转化为红黑树，以减少搜索时间。
+- LinkedHashMap ：LinkedHashMap 继承自 HashMap，所以它的底层仍然是基于拉链式散列结构即由数组和链表或红黑树组成。另外，LinkedHashMap 在上面结构的基础上，增加了一条双向链表，使得上面的结构可以保持键值对的插入顺序。同时通过对链表进行相应的操作，实现了访问顺序相关逻辑。详细可以查看：[《LinkedHashMap 源码详细分析（JDK1.8）》](https://www.imooc.com/article/22931) 。
+- Hashtable ：数组+链表组成的，数组是 HashMap 的主体，链表则是主要为了解决哈希冲突而存在的。
+- TreeMap ：红黑树（自平衡的排序二叉树）。
+
+3）Set
+
+- HashSet ：无序，唯一，基于 HashMap 实现的，底层采用 HashMap 来保存元素。
+- LinkedHashSet ：LinkedHashSet 继承自 HashSet，并且其内部是通过 LinkedHashMap 来实现的。有点类似于我们之前说的LinkedHashMap 其内部是基于 HashMap 实现一样，不过还是有一点点区别的。
+- TreeSet ：有序，唯一，红黑树(自平衡的排序二叉树)。
+
+## 什么是迭代器(Iterator)？
+
+Iterator 接口，提供了很多对集合元素进行迭代的方法。每一个集合类都包含了可以返回迭代器实例的迭代方法。迭代器可以在迭代的过程中删除底层集合的元素，但是不可以直接调用集合的 `#remove(Object Obj)` 方法删除，可以通过迭代器的 `#remove()` 方法删除。
+
+🦅 **Iterator 和 ListIterator 的区别是什么？**
+
+- Iterator 可用来遍历 Set 和 List 集合，但是 ListIterator 只能用来遍历 List。
+- Iterator 对集合只能是前向遍历，ListIterator 既可以前向也可以后向。
+- ListIterator 实现了 Iterator 接口，并包含其他的功能。比如：增加元素，替换元素，获取前一个和后一个元素的索引等等。
+
+🦅 **快速失败（fail-fast）和安全失败（fail-safe）的区别是什么？**
+
+差别在于 ConcurrentModification 异常：
+
+- 快速失败：当你在迭代一个集合的时候，如果有另一个线程正在修改你正在访问的那个集合时，就会抛出一个 ConcurrentModification 异常。 在 `java.util` 包下的都是快速失败。
+- 安全失败：你在迭代的时候会去底层集合做一个拷贝，所以你在修改上层集合的时候是不会受影响的，不会抛出 ConcurrentModification 异常。在 `java.util.concurrent` 包下的全是安全失败的。
+
+🦅 **如何删除 List 中的某个元素？**
+
+有两种方式，分别如下：
+
+- 方式一，使用 Iterator ，顺序向下，如果找到元素，则使用 remove 方法进行移除。
+- 方式二，倒序遍历 List ，如果找到元素，则使用 remove 方法进行移除。
+
+🦅 **Enumeration 和 Iterator 接口有什么不同？**
+
+- Enumeration 跟 Iterator 相比较快两倍，而且占用更少的内存。
+- 但是，Iterator 相对于 Enumeration 更安全，因为其他线程不能修改当前迭代器遍历的集合对象。同时，Iterators 允许调用者从底层集合中移除元素，这些 Enumerations 都没法完成。
+
+对于很多胖友，可能并未使用过 Enumeration 类，所以可以看看 [《Java Enumeration 接口》](http://www.runoob.com/java/java-enumeration-interface.html) 文章。
+
+🦅 **为何 Iterator 接口没有具体的实现？**
+
+Iterator 接口，定义了遍历集合的方法，但它的实现则是集合实现类的责任。每个能够返回用于遍历的 Iterator 的集合类都有它自己的 Iterator 实现内部类。
+
+这就允许集合类去选择迭代器是 fail-fast 还是 fail-safe 的。比如，ArrayList 迭代器是 fail-fast 的，而 CopyOnWriteArrayList 迭代器是 fail-safe 的。
+
+## Comparable 和 Comparator 的区别?
+
+- Comparable 接口，在 `java.lang` 包下，用于当前对象和其它对象的比较，所以它有一个 `#compareTo(Object obj)` 方法用来排序，该方法只有一个参数。
+- Comparator 接口，在 `java.util` 包下，用于传入的两个对象的比较，所以它有一个 `#compare(Object obj1, Object obj2)` 方法用来排序，该方法有两个参数。
+
+详细的，可以看看 [《Java 自定义比较器》](https://blog.csdn.net/whing123/article/details/77851737) 文章，重点是如何自己实现 Comparable 和 Comparator 的方法。
+
+🦅 **compareTo 方法的返回值表示的意思？**
+
+- 大于 0 ，表示对象大于参数对象。
+- 小于 0 ，表示对象小于参数对象
+- 等于 0 ，表示两者相等。
+
+🦅 **如何对 Object 的 List 排序？**
+
+- 对 `Object[]` 数组进行排序时，我们可以用 `Arrays#sort(...)` 方法。
+- 对 `List<Object>` 数组进行排序时，我们可以用 `Collections#sort(...)` 方法。
+
+## 有哪些关于 Java 集合框架的最佳实践？
+
+- 基于应用的需求来选择使用正确类型的集合，这对性能来说是非常重要的。例如，如果元素的大小是固定的，并且知道优先级，我们将会使用一个 Array ，而不是 ArrayList 。
+- 一些集合类允许我们指定他们的初始容量。因此，如果我们知道存储数据的大概数值，就可以避免重散列或者大小的调整。
+- 总是使用泛型来保证类型安全，可靠性和健壮性。同时，使用泛型还可以避免运行时的 ClassCastException 异常。
+- 在 Map 中使用 JDK 提供的不可变类作为一个 key，这样可以避免 hashcode 的实现和我们自定义类的 equals 方法。
+- 应该依照接口而不是实现来编程。
+- 返回零长度的集合或者数组，而不是返回一个 `null` ，这样可以防止底层集合是空的。
+
+# 区别
+
+## List 和 Set 区别？
+
+List，Set 都是继承自 Collection 接口。
+
+- List 特点：元素有放入顺序，元素可重复。
+- Set 特点：元素无放入顺序，元素不可重复，重复元素会覆盖掉。
+
+> 注意：元素虽然无放入顺序，但是元素在 Set 中的位置是有该元素的 hashcode 决定的，其位置其实是固定的。
+>
+> 另外 List 支持 `for` 循环，也就是通过下标来遍历，也可以用迭代器，但是 Set 只能用迭代，因为他无序，无法用下标来取得想要的值。
+
+Set 和 List 对比：
+
+- Set：检索指定的元素效率高，删除和插入效率高，插入和删除**可能会**引起元素位置改变。
+- List：和数组类似，List 可以动态增长，查找**指定的**元素效率低，插入删除指定的元素效率低，因为可能会引起其他元素位置改变。
+
+当然，如果是随机访问（指定下标），则 List 会快于 Set 。总之，什么场景下使用 Set ，什么场景下使用 List ，还是比较明确的。
+
+## List 和 Map 区别？
+
+- List 是对象集合，允许对象重复。
+- Map 是键值对的集合，不允许 key 重复。
+
+## Array 和 ArrayList 有何区别？什么时候更适合用 Array？
+
+- Array 可以容纳基本类型和对象，而 ArrayList 只能容纳对象。
+- Array 是指定大小的，而 ArrayList 大小是固定的，可自动扩容。
+- Array 没有提供 ArrayList 那么多功能，比如 addAll、removeAll 和 iterator 等。
+
+尽管 ArrayList 明显是更好的选择，但也有些时候 Array 比较好用，比如下面的三种情况。
+
+- 1、如果列表的大小已经指定，大部分情况下是存储和遍历它们
+- 2、对于遍历基本数据类型，尽管 Collections 使用自动装箱来减轻编码任务，在指定大小的基本类型的列表上工作也会变得很慢。
+- 3、如果你要使用多维数组，使用 `[][]` 比 List 会方便。
+
+## ArrayList 与 LinkedList 区别？
+
+🦅 **ArrayList**
+
+- 优点：ArrayList 是实现了基于动态数组的数据结构，因为地址连续，一旦数据存储好了，查询操作效率会比较高（在内存里是连着放的）。
+- 缺点：因为地址连续，ArrayList 要移动数据，所以插入和删除操作效率比较低。
+
+🦅 **LinkedList**
+
+- 优点：LinkedList 基于链表的数据结构，地址是任意的，所以在开辟内存空间的时候不需要等一个连续的地址。对于新增和删除操作 add 和 remove ，LinedList 比较占优势。LinkedList 适用于要头尾操作或插入指定位置的场景。
+- 缺点：因为 LinkedList 要移动指针，所以查询操作性能比较低。
+
+🦅 **适用场景分析**：
+
+- 当需要对数据进行对随机访问的情况下，选用 ArrayList 。
+
+- 当需要对数据进行多次增加删除修改时，采用 LinkedList 。
+
+  > 如果容量固定，并且只会添加到尾部，不会引起扩容，优先采用 ArrayList 。
+
+- 当然，绝大数业务的场景下，使用 ArrayList 就够了。主要是，注意好避免 ArrayList 的扩容，以及非顺序的插入。
+
+🦅 **ArrayList 是如何扩容的？**
+
+直接看 [《ArrayList 动态扩容详解》](https://www.cnblogs.com/kuoAT/p/6771653.html) 文章，很详细。主要结论如下：
+
+- 如果通过无参构造的话，初始数组容量为 0 ，当真正对数组进行添加时，才真正分配容量。每次按照 **1.5** 倍（位运算）的比率通过 copeOf 的方式扩容。
+- 在 JKD6 中实现是，如果通过无参构造的话，初始数组容量为10，每次通过 copeOf 的方式扩容后容量为原来的 **1.5** 倍。
+
+> 重点是 1.5 倍扩容，这是和 HashMap 2 倍扩容不同的地方。
+
+🦅 **ArrayList 集合加入 1 万条数据，应该怎么提高效率？**
+
+ArrayList 的默认初始容量为 10 ，要插入大量数据的时候需要不断扩容，而扩容是非常影响性能的。因此，现在明确了 10 万条数据了，我们可以直接在初始化的时候就设置 ArrayList 的容量！
+
+这样就可以提高效率了~
+
+## ArrayList 与 Vector 区别？
+
+ArrayList 和 Vector 都是用数组实现的，主要有这么三个区别：
+
+- 1、Vector 是多线程安全的，线程安全就是说多线程访问同一代码，不会产生不确定的结果，而 ArrayList 不是。这个可以从源码中看出，Vector 类中的方法很多有 `synchronized` 进行修饰，这样就导致了 Vector 在效率上无法与 ArrayList 相比。
+
+  > Vector 是一种老的动态数组，是线程同步的，效率很低，一般不赞成使用。
+
+- 2、两个都是采用的线性连续空间存储元素，但是当空间不足的时候，两个类的增加方式是不同。
+
+- 3、Vector 可以设置增长因子，而 ArrayList 不可以。
+
+适用场景分析：
+
+- 1、Vector 是线程同步的，所以它也是线程安全的，而 ArrayList 是线程无需同步的，是不安全的。如果不考虑到线程的安全因素，一般用 ArrayList 效率比较高。
+
+  > 实际场景下，如果需要多线程访问安全的数组，使用 CopyOnWriteArrayList 。
+
+- 2、如果集合中的元素的数目大于目前集合数组的长度时，在集合中使用数据量比较大的数据，用 Vector 有一定的优势。
+
+  > 这种情况下，使用 LinkedList 更合适。
+
+## HashMap 和 Hashtable 的区别？
+
+> Hashtable 是在 Java 1.0 的时候创建的，而集合的统一规范命名是在后来的 Java2.0 开始约定的，而当时其他一部分集合类的发布构成了新的集合框架。
+
+- Hashtable 继承 Dictionary ，HashMap 继承的是 Java2 出现的 Map 接口。
+- 2、HashMap 去掉了 Hashtable 的 contains 方法，但是加上了 containsValue 和 containsKey 方法。
+- 3、HashMap 允许空键值，而 Hashtable 不允许。
+- 【重点】4、HashTable 是同步的，而 HashMap 是非同步的，效率上比 HashTable 要高。也因此，HashMap 更适合于单线程环境，而 HashTable 适合于多线程环境。
+- 5、HashMap 的迭代器（Iterator）是 fail-fast 迭代器，HashTable的 enumerator 迭代器不是 fail-fast 的。
+- 【重要】6、HashTable 中数组默认大小是 11 ，扩容方法是 `old * 2 + 1` ，HashMap 默认大小是 16 ，扩容每次为 2 的指数大小。
+
+一般现在不建议用 HashTable 。主要原因是两点：
+
+- 一是，HashTable 是遗留类，内部实现很多没优化和冗余。
+- 二是，即使在多线程环境下，现在也有同步的 ConcurrentHashMap 替代，没有必要因为是多线程而用 Hashtable 。
+
+🦅 **Hashtable 的 `#size()` 方法中明明只有一条语句 `"return count;"` ，为什么还要做同步？**
+
+同一时间只能有一条线程执行固定类的同步方法，但是对于类的非同步方法，可以多条线程同时访问。所以，这样就有问题了，可能线程 A 在执行 Hashtable 的 put 方法添加数据，线程 B 则可以正常调用 `#size()` 方法读取 Hashtable 中当前元素的个数，那读取到的值可能不是最新的，可能线程 A 添加了完了数据，但是没有对 `count++` ，线程 B 就已经读取 `count` 了，那么对于线程 B 来说读取到的 `count` 一定是不准确的。
+
+**而给 `#size()` 方法加了同步之后，意味着线程 B 调用 `#size()` 方法只有在线程 A 调用 put 方法完毕之后才可以调用，这样就保证了线程安全性**。
+
+## HashSet 和 HashMap 的区别？
+
+- Set 是线性结构，值不能重复。HashSet 是 Set 的 hash 实现，HashSet 中值不能重复是用 HashMap 的 key 来实现的。
+
+- Map 是键值对映射，可以空键空值。HashMap 是 Map 的 hash 实现，key 的唯一性是通过 key 值 hashcode 的唯一来确定，value 值是则是链表结构。
+
+  > 因为不同的 key 值，可能有相同的 hashcode ，所以 value 值需要是链表结构。
+
+他们的共同点都是 hash 算法实现的唯一性，他们都不能持有基本类型，只能持有对象。
+
+> 为了更好的性能，Netty 自己实现了 key 为基本类型的 HashMap ，例如 [IntObjectHashMap](https://netty.io/4.1/api/io/netty/util/collection/IntObjectHashMap.html) 。
+
+## HashSet 和 TreeSet 的区别？
+
+- HashSet 是用一个 hash 表来实现的，因此，它的元素是无序的。添加，删除和 HashSet 包括的方法的持续时间复杂度是 `O(1)` 。
+- TreeSet 是用一个树形结构实现的，因此，它是有序的。添加，删除和 TreeSet 包含的方法的持续时间复杂度是 `O(logn)` 。
+
+🦅 **如何决定选用 HashMap 还是 TreeMap？**
+
+- 对于在 Map 中插入、删除和定位元素这类操作，HashMap 是最好的选择。
+- 然而，假如你需要对一个有序的 key 集合进行遍历， TreeMap 是更好的选择。
+
+基于你的 collection 的大小，也许向 HashMap 中添加元素会更快，再将 HashMap 换为 TreeMap 进行有序 key 的遍历。
+
+## HashMap 和 ConcurrentHashMap 的区别？
+
+ConcurrentHashMap 是线程安全的 HashMap 的实现。主要区别如下：
+
+- 1、ConcurrentHashMap 对整个桶数组进行了分割分段(Segment)，然后在每一个分段上都用 lock 锁进行保护，相对 于Hashtable 的 syn 关键字锁的粒度更精细了一些，并发性能更好。而 HashMap 没有锁机制，不是线程安全的。
+
+  > JDK8 之后，ConcurrentHashMap 启用了一种全新的方式实现,利用 CAS 算法。
+
+- 2、HashMap 的键值对允许有 `null` ，但是 ConCurrentHashMap 都不允许。
+
+## 队列和栈是什么，列出它们的区别？
+
+栈和队列两者都被用来预存储数据。
+
+- ```
+  java.util.Queue
+  ```
+
+   
+
+  是一个接口，它的实现类在Java并发包中。
+
+  - 队列允许先进先出（FIFO）检索元素，但并非总是这样。
+  - Deque 接口允许从两端检索元素。
+
+- 栈与队列很相似，但它允许对元素进行后进先出（LIFO）进行检索。
+
+  - Stack 是一个扩展自 Vector 的类，而 Queue 是一个接口。
+
+# 原理
+
+## HashMap 的工作原理是什么？
+
+我们知道在 Java 中最常用的两种结构是数组和模拟指针（引用），几乎所有的数据结构都可以利用这两种来组合实现，HashMap 也是如此。实际上 HashMap 是一个**“链表散列”**。
+
+HashMap 是基于 hashing 的原理。
+
+[![HashMap 图解](http://dl.iteye.com/upload/attachment/177479/3f05dd61-955e-3eb2-bf8e-31da8a361148.jpg)](http://dl.iteye.com/upload/attachment/177479/3f05dd61-955e-3eb2-bf8e-31da8a361148.jpg)HashMap 图解
+
+- 我们使用 `#put(key, value)` 方法来存储对象到 HashMap 中，使用 `get(key)` 方法从 HashMap 中获取对象。
+- 当我们给 `#put(key, value)` 方法传递键和值时，我们先对键调用 `#hashCode()` 方法，返回的 hashCode 用于找到 bucket 位置来储存 Entry 对象。
+
+🦅 **当两个对象的 hashCode 相同会发生什么？**
+
+因为 hashcode 相同，所以它们的 bucket 位置相同，“碰撞”会发生。
+
+因为 HashMap 使用链表存储对象，这个 Entry（包含有键值对的 Map.Entry 对象）会存储在链表中。
+
+🦅 **hashCode 和 equals 方法有何重要性？**
+
+HashMap 使用 key 对象的 `#hashCode()` 和 `#equals(Object obj)` 方法去决定 key-value 对的索引。当我们试着从 HashMap 中获取值的时候，这些方法也会被用到。
+
+- 如果这两个方法没有被正确地实现，在这种情况下，两个不同 Key 也许会产生相同的 `#hashCode()` 和 `#equals(Object obj)` 输出，HashMap 将会认为它们是相同的，然后覆盖它们，而非把它们存储到不同的地方。
+
+同样的，所有不允许存储重复数据的集合类都使用 `#hashCode()` 和 `#equals(Object obj)` 去查找重复，所以正确实现它们非常重要。`#hashCode()` 和 `#equals(Object obj)` 方法的实现，应该遵循以下规则：
+
+- 如果 `o1.equals(o2)` ，那么 `o1.hashCode() == o2.hashCode()` 总是为 `true` 的。
+- 如果 `o1.hashCode() == o2.hashCode()` ，并不意味 `o1.equals(o2)` 会为 `true` 。
+
+🦅 **HashMap 默认容量是多少？**
+
+默认容量都是 16 ，负载因子是 0.75 。就是当 HashMap 填充了 75% 的 busket 是就会扩容，最小的可能性是（`16 * 0.75 = 12`），一般为原内存的 2 倍。
+
+🦅 **有哪些顺序的 HashMap 实现类？**
+
+- LinkedHashMap ，是基于元素进入集合的顺序或者被访问的先后顺序排序。
+- TreeMap ，是基于元素的固有顺序 (由 Comparator 或者 Comparable 确定)。
+
+🦅 **我们能否使用任何类作为 Map 的 key？**
+
+我们可以使用任何类作为 Map 的 key ，然而在使用它们之前，需要考虑以下几点：
+
+- 1、如果类重写了 equals 方法，它也应该重写 hashcode 方法。
+
+- 2、类的所有实例需要遵循与 equals 和 hashcode 相关的规则。
+
+- 3、如果一个类没有使用 equals ，你不应该在 hashcode 中使用它。
+
+- 4、用户自定义 key 类的最佳实践是使之为不可变的，这样，hashcode 值可以被缓存起来，拥有更好的性能。不可变的类也可以确保hashcode 和 equals 在未来不会改变，这样就会解决与可变相关的问题了。
+
+  > 比如，我有一个 类MyKey ，在 HashMap 中使用它。代码如下：
+
+  ```
+  //传递给MyKey的name参数被用于equals()和hashCode()中
+  MyKey key = new MyKey('Pankaj'); //assume hashCode=1234
+  myHashMap.put(key, 'Value');
+  // 以下的代码会改变key的hashCode()和equals()值
+  key.setName('Amit'); //assume new hashCode=7890
+  //下面会返回null，因为HashMap会尝试查找存储同样索引的key，而key已被改变了，匹配失败，返回null
+  myHashMap.get(new MyKey('Pankaj'));
+  ```
+
+  - 那就是为何 String 和 Integer 被作为 HashMap 的 key 大量使用。
+
+🦅 **HashMap 的长度为什么是 2 的幂次方？**
+
+为了能让 HashMap 存取高效，尽量较少碰撞，也就是要尽量把数据分配均匀，每个链表/红黑树长度大致相同。这个实现就是把数据存到哪个链表/红黑树中的算法。
+
+这个算法应该如何设计呢？我们首先可能会想到采用 `%` 取余的操作来实现。但是，重点来了：
+
+- 取余(`%`)操作中如果除数是 2 的幂次则等价于与其除数减一的与(`&`)操作（也就是说 `hash % length == hash & (length - 1)` 的前提是 length 是 2 的 n 次方；）。
+- 并且，采用二进制位操作 `&`，相对于 `%` 能够提高运算效率，
+
+这就解释了 HashMap 的长度为什么是 2 的幂次方。
+
+## HashSet 的工作原理是什么？
+
+HashSet 是构建在 HashMap 之上的 Set hashing 实现类。让我们直接撸下源码，代码如下：
+
+```
+// HashSet.java
+
+private transient HashMap<E,Object> map;
+
+private static final Object PRESENT = new Object();
+```
+
+- `map` 属性，当我们创建一个 HashMap 对象时，其内部也会创建一个 `map` 对象。后续 HashSet 所有的操作，实际都是基于这个 `map` 之上的封装。
+
+- `PRESENT` 静态属性，所有 `map` 中 KEY 对应的值，都是它，避免重复创建。
+
+- OK ，再来看一眼 add 方法，代码如下：
+
+  ```
+  // HashSet.java
+  
+  public boolean add(E e) {
+      return map.put(e, PRESENT) == null;
+  }
+  ```
+
+  - 是不是一目了然。
+
+🦅 **HashSet 如何检查重复？**
+
+> 艿艿：正如我们上面看到 HashSet 的实现原理，我们自然可以推导出，HashMap 也是如何检查重复滴。
+
+如下摘取自 《Head First Java》 第二版：
+
+当你把对象加入 HashSet 时，HashSet会先计算对象的hashcode值来判断对象加入的位置，同时也会与其他加入的对象的hashcode值作比较。
+
+- 如果没有相符的 hashcode ，HashSet会假设对象没有重复出现。
+- 但是如果发现有相同 hashcode 值的对象，这时会调用 equals 方法来检查 hashcode 相等的对象是否真的相同。
+  - 如果两者相同，HashSet 就不会让加入操作成功。
+  - **如果两者不同，HashSet 就会让加入操作成功**。
+
+## EnumSet 是什么？
+
+`java.util.EnumSet` ，是使用枚举类型的集合实现。
+
+- 当集合创建时，枚举集合中的所有元素必须来自单个指定的枚举类型，可以是显示的或隐示的。EnumSet 是不同步的，不允许值为 `null` 的元素。
+- 它也提供了一些有用的方法，比如 `#copyOf(Collection c)`、`#of(E first, E... rest)` 和 `#complementOf(EnumSet s)` 方法。
+
+关于 EnumSet 的源码解析，见 [《EnumSet 源码分析》](https://blog.csdn.net/u010887744/article/details/50834738) 文章。
+
+## TODO TreeMap 原理
+
+Java 中的 TreeMap 是使用红黑树实现的。
+
+TODO TreeMap和TreeSet在排序时如何比较元素？Collections工具类中的sort()方法如何比较元素？
+
+等到源码解析后，在进行补充。
+
+## Java Priority Queue 是什么?
+
+PriorityQueue 是一个基于优先级堆的无界队列，它的元素都以他们的自然顺序有序排列。
+
+- 在它创建的时候，我们可以可以提供一个比较器 Comparator 来负责PriorityQueue 中元素的排序。
+- PriorityQueue 不允许 ``null元素，不允许不提供自然排序的对象，也不允许没有任何关联 Comparator 的对象。
+- 最后，PriorityQueue 不是线程安全的，在执行入队和出队操作它需要 `O(log(n))` 的时间复杂度。
+
+🦅 **poll 方法和 remove 方法的区别？**
+
+poll 和 remove 方法，都是从队列中取出一个元素，差别在于：
+
+- poll 方法，在获取元素失败的时候会返回空
+- remove() 方法，失败的时候会抛出异常。
+
+🦅 **LinkedHashMap 和 PriorityQueue 的区别是什么？**
+
+- PriorityQueue 保证最高或者最低优先级的的元素总是在队列头部，LinkedHashMap 维持的顺序是元素插入的顺序。
+- 当遍历一个 PriorityQueue 时，没有任何顺序保证，但是 LinkedHashMap 课保证遍历顺序是元素插入的顺序。
+
+# 彩蛋
+
+参考与推荐如下文章：
+
+- [《2018 年最新 Java 面试题及答案整理》](https://juejin.im/entry/5af2557c6fb9a07aa83eb59c)
+- [《互联网常见的 14 个 Java 面试题》](https://www.oldboyedu.com/zuixin_wenzhang/index/id/302.html)
+
+TODO 需要补充的内容
+
+- 1. 跳跃表
\ No newline at end of file
diff --git a/面试题/28-Java【并发】面试题.assets/04a277229fd3b24e058417f9c571681c.png b/面试题/28-Java【并发】面试题.assets/04a277229fd3b24e058417f9c571681c.png
new file mode 100644
index 0000000..6c9e49c
Binary files /dev/null and b/面试题/28-Java【并发】面试题.assets/04a277229fd3b24e058417f9c571681c.png differ
diff --git a/面试题/28-Java【并发】面试题.assets/3281138331173cdd53d1364f9c56d594.png b/面试题/28-Java【并发】面试题.assets/3281138331173cdd53d1364f9c56d594.png
new file mode 100644
index 0000000..d178622
Binary files /dev/null and b/面试题/28-Java【并发】面试题.assets/3281138331173cdd53d1364f9c56d594.png differ
diff --git a/面试题/28-Java【并发】面试题.assets/3f43df826320de201b726e7f20c97868.png b/面试题/28-Java【并发】面试题.assets/3f43df826320de201b726e7f20c97868.png
new file mode 100644
index 0000000..aa4e9dd
Binary files /dev/null and b/面试题/28-Java【并发】面试题.assets/3f43df826320de201b726e7f20c97868.png differ
diff --git a/面试题/28-Java【并发】面试题.assets/506052a856416414e18c7ed79d43cc5c-171824960835810 b/面试题/28-Java【并发】面试题.assets/506052a856416414e18c7ed79d43cc5c-171824960835810
new file mode 100644
index 0000000..08ce4b5
Binary files /dev/null and b/面试题/28-Java【并发】面试题.assets/506052a856416414e18c7ed79d43cc5c-171824960835810 differ
diff --git a/面试题/28-Java【并发】面试题.assets/5eeec5f68f4fc412246efd4111d6fdec.png b/面试题/28-Java【并发】面试题.assets/5eeec5f68f4fc412246efd4111d6fdec.png
new file mode 100644
index 0000000..5ddc9c9
Binary files /dev/null and b/面试题/28-Java【并发】面试题.assets/5eeec5f68f4fc412246efd4111d6fdec.png differ
diff --git a/面试题/28-Java【并发】面试题.assets/89bf0392f832b459ed62efb31af4461e.jpeg b/面试题/28-Java【并发】面试题.assets/89bf0392f832b459ed62efb31af4461e.jpeg
new file mode 100644
index 0000000..ca70e81
Binary files /dev/null and b/面试题/28-Java【并发】面试题.assets/89bf0392f832b459ed62efb31af4461e.jpeg differ
diff --git a/面试题/28-Java【并发】面试题.assets/a79be5f48c26abb905348e43a1732d55-17182496083589 b/面试题/28-Java【并发】面试题.assets/a79be5f48c26abb905348e43a1732d55-17182496083589
new file mode 100644
index 0000000..96dbd39
Binary files /dev/null and b/面试题/28-Java【并发】面试题.assets/a79be5f48c26abb905348e43a1732d55-17182496083589 differ
diff --git a/面试题/28-Java【并发】面试题.assets/b2647746fcfbc58730dc7d34bf0a70e9.jpeg b/面试题/28-Java【并发】面试题.assets/b2647746fcfbc58730dc7d34bf0a70e9.jpeg
new file mode 100644
index 0000000..be20521
Binary files /dev/null and b/面试题/28-Java【并发】面试题.assets/b2647746fcfbc58730dc7d34bf0a70e9.jpeg differ
diff --git a/面试题/28-Java【并发】面试题.assets/b9bc9653929e5da43d8edad6e6a0d293-17182496083578 b/面试题/28-Java【并发】面试题.assets/b9bc9653929e5da43d8edad6e6a0d293-17182496083578
new file mode 100644
index 0000000..750265c
Binary files /dev/null and b/面试题/28-Java【并发】面试题.assets/b9bc9653929e5da43d8edad6e6a0d293-17182496083578 differ
diff --git a/面试题/28-Java【并发】面试题.assets/d07d3538b177da26feef167d4a8c7080.jpeg b/面试题/28-Java【并发】面试题.assets/d07d3538b177da26feef167d4a8c7080.jpeg
new file mode 100644
index 0000000..7f4bfc0
Binary files /dev/null and b/面试题/28-Java【并发】面试题.assets/d07d3538b177da26feef167d4a8c7080.jpeg differ
diff --git a/面试题/28-Java【并发】面试题.md b/面试题/28-Java【并发】面试题.md
new file mode 100644
index 0000000..ca1c863
--- /dev/null
+++ b/面试题/28-Java【并发】面试题.md
@@ -0,0 +1,1637 @@
+# 精尽 Java【并发】面试题「最新更新时间：2024-02」
+
+以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。
+
+如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的 Java【并发】面试题的大保健。
+
+而题目的难度，艿艿尽量按照从容易到困难的顺序，逐步下去。
+
+因为 Java 并发涉及到的内容会非常多，本面试题可能很难覆盖到所有的知识点，所以推荐 [《Java并发编程的艺术》](https://u.jd.com/gpkonU) 。并且，本文会将面试题和该书的章节，大体保持一致。嘻嘻~
+
+另外，本文涉及的面试题会超级超级超级多，所以艿艿已经分了小节，胖友要注意哟。
+
+# Java 线程
+
+- [![线程](http://static.iocoder.cn/89bf0392f832b459ed62efb31af4461e)](http://static.iocoder.cn/89bf0392f832b459ed62efb31af4461e)线程
+- [![通知 + 等待](http://static.iocoder.cn/b2647746fcfbc58730dc7d34bf0a70e9)](http://static.iocoder.cn/b2647746fcfbc58730dc7d34bf0a70e9)通知 + 等待
+- [![线程通信](http://static.iocoder.cn/d07d3538b177da26feef167d4a8c7080)](http://static.iocoder.cn/d07d3538b177da26feef167d4a8c7080)线程通信
+- [![常见问题](http://static.iocoder.cn/3f43df826320de201b726e7f20c97868)](http://static.iocoder.cn/3f43df826320de201b726e7f20c97868)常见问题
+
+## 简述线程、进程、程序的基本概念？
+
+🦅 **程序**
+
+程序，是含有指令和数据的文件，被存储在磁盘或其他的数据存储设备中，也就是说程序是静态的代码。
+
+🦅 **进程**
+
+进程，是程序的一次执行过程，是系统运行程序的基本单位，因此进程是动态的。系统运行一个程序即是一个进程从创建，运行到消亡的过程。简单来说，一个进程就是一个执行中的程序，它在计算机中一个指令接着一个指令地执行着，同时，每个进程还占有某些系统资源如CPU时间，内存空间，文件，文件，输入输出设备的使用权等等。换句话说，当程序在执行时，将会被操作系统载入内存中。
+
+🦅 **线程**
+
+线程，与进程相似，但线程是一个比进程更小的执行单位。一个进程在其执行的过程中可以产生多个线程。与进程不同的是同类的多个线程共享同一块内存空间和一组系统资源，所以系统在产生一个线程，或是在各个线程之间作切换工作时，负担要比进程小得多，也正因为如此，线程也被称为轻量级进程。
+
+> 艿艿：如下是可选内容。
+>
+> 另外，Java 线程是重量级的，每个线程默认使用 1024KB 的内存，所以一个 Java 进程是无法开启大量线程的。感兴趣的胖友，可以看 [《Java 中的轻量级线程？》](http://landcareweb.com/questions/33900/javazhong-de-qing-liang-ji-xian-cheng) 的讨论，没准未来 Java 也有内置的协程（Coroutine）。
+
+🦅 **三者之间的关系**
+
+- 线程是进程划分成的更小的运行单位。线程和进程最大的不同在于基本上各进程是独立的，而各线程则不一定，因为同一进程中的线程极有可能会相互影响。
+- 从另一角度来说，进程属于操作系统的范畴，主要是同一段时间内，可以同时执行一个以上的程序，而线程则是在同一程序内几乎同时执行一个以上的程序段。
+
+🦅 **线程有什么优缺点？**
+
+1）好处
+
+- 使用多线程可以把程序中占据时间长的任务放到后台去处理，如图片、视屏的下载。
+- 发挥多核处理器的优势，并发执行让系统运行的更快、更流畅，用户体验更好。
+
+2）坏处
+
+- 大量的线程降低代码的可读性。
+- 更多的线程需要更多的内存空间。
+- 当多个线程对同一个资源出现争夺时候要注意线程安全的问题。
+
+🦅 **你了解守护线程吗？它和非守护线程有什么区别？**
+
+Java 中的线程分为两种：守护线程（Daemon）和用户线程（User）。
+
+- 任何线程都可以设置为守护线程和用户线程，通过方法`Thread#setDaemon(boolean on)` 设置。`true` 则把该线程设置为守护线程，反之则为用户线程。
+- `Thread#setDaemon(boolean on)` 方法，必须在`Thread#start()` 方法之前调用，否则运行时会抛出异常。
+
+唯一的区别是：
+
+> 程序运行完毕，JVM 会等待非守护线程完成后关闭，但是 JVM 不会等待守护线程。
+
+- 判断虚拟机(JVM)何时离开，Daemon 是为其他线程提供服务，如果全部的 User Thread 已经撤离，Daemon 没有可服务的线程，JVM 撤离。
+- 也可以理解为守护线程是 JVM 自动创建的线程（但不一定），用户线程是程序创建的线程。比如，JVM 的垃圾回收线程是一个守护线程，当所有线程已经撤离，不再产生垃圾，守护线程自然就没事可干了，当垃圾回收线程是 Java 虚拟机上仅剩的线程时，Java 虚拟机会自动离开。
+
+扩展：Thread Dump 打印出来的线程信息，含有 daemon 字样的线程即为守护进程。可能会有：服务守护进程、编译守护进程、Windows 下的监听 Ctrl + break 的守护进程、Finalizer 守护进程、引用处理守护进程、GC 守护进程。
+
+关于守护线程的各种骚操作，可以看看 [《Java 守护线程概述》](https://blog.csdn.net/u013256816/article/details/50392298) 。
+
+🦅 **什么是线程组，为什么在 Java 中不推荐使用？**
+
+> 艿艿：这是个小众知识，了解即可。貌似，艿艿也重来没使用过这个类。
+
+ThreadGroup 类，可以把线程归属到某一个线程组中，线程组中可以有线程对象，也可以有线程组，组中还可以有线程，这样的组织结构有点类似于树的形式。
+
+> 简单的说，ThreadGroup 为了方便线程的管理。
+
+为什么不推荐使用？ThreadGroup API 比较薄弱，它并没有比 Thread 提供了更多的功能。它有两个主要的功能：一是获取线程组中处于活跃状态线程的列表；二是设置为线程设置未捕获异常处理器(uncaught exception handler)。但在 Java5 中 Thread 类也添加了 `#setUncaughtExceptionHandler(UncaughtExceptionHandler eh)` 方法，所以 ThreadGroup 是已经过时的，不建议继续使用。
+
+## 什么是多线程上下文切换？
+
+多线程会共同使用一组计算机上的 CPU ，而线程数大于给程序分配的 CPU 数量时，为了让各个线程都有执行的机会，就需要轮转使用 CPU 。
+
+不同的线程切换使用 CPU 发生的切换数据等，就是上下文切换。
+
+- 在上下文切换过程中，CPU 会停止处理当前运行的程序，并保存当前程序运行的具体位置以便之后继续运行。从这个角度来看，上下文切换有点像我们同时阅读几本书，在来回切换书本的同时我们需要记住每本书当前读到的页码。在程序中，上下文切换过程中的“页码”信息是保存在进程控制块（PCB）中的。PCB还经常被称作“切换桢”（switchframe）。“页码”信息会一直保存到CPU的内存中，直到他们被再次使用。
+- 上下文切换是存储和恢复 CPU 状态的过程，它使得线程执行能够从中断点恢复执行。上下文切换是多任务操作系统和多线程环境的基本特征。
+
+🦅 **Java 中用到的线程调度算法是什么？**
+
+假设计算机只有一个 CPU ，则在任意时刻只能执行一条机器指令，每个线程只有获得 CPU 的使用权才能执行指令。
+
+- 所谓多线程的并发运行，其实是指从宏观上看，各个线程轮流获得 CPU 的使用权，分别执行各自的任务。
+- 在运行池中，会有多个处于就绪状态的线程在等待 CPU ，Java 虚拟机的一项任务就是负责线程的调度，线程调度是指按照特定机制为多个线程分配 CPU 的使用权。
+
+有两种调度模型：分时调度模型和抢占式调度模型。
+
+- 分时调度模型是指让所有的线程轮流获得 CPU 的使用权,并且平均分配每个线程占用的 CPU 的时间片这个也比较好理解。
+
+- Java 虚拟机采用抢占式调度模型，是指优先让可运行池中优先级高的线程占用 CPU ，如果可运行池中的线程优先级相同，那么就随机选择一个线程，使其占用 CPU 。处于运行状态的线程会一直运行，直至它不得不放弃 CPU 。
+
+  > 如非特别需要，尽量不要用，防止线程饥饿。
+
+🦅 **什么是线程饥饿？**
+
+饥饿，一个或者多个线程因为种种原因无法获得所需要的资源，导致一直无法执行的状态。
+
+Java 中导致饥饿的原因：
+
+- 高优先级线程吞噬所有的低优先级线程的 CPU 时间。
+- 线程被永久堵塞在一个等待进入同步块的状态，因为其他线程总是能在它之前持续地对该同步块进行访问。
+- 线程在等待一个本身也处于永久等待完成的对象(比如调用这个对象的 wait 方法)，因为其他线程总是被持续地获得唤醒。
+
+🦅 **你对线程优先级的理解是什么？**
+
+每一个线程都是有优先级的，一般来说，高优先级的线程在运行时会具有优先权，但这依赖于线程调度的实现，这个实现是和操作系统相关的(OS dependent)。
+
+- 我们可以定义线程的优先级，但是这并不能保证高优先级的线程会在低优先级的线程前执行。线程优先级是一个 int 变量(从1-10)，1 代表最低优先级，10 代表最高优先级。
+- Java 的线程优先级调度会委托给操作系统去处理，所以与具体的操作系统优先级有关，如非特别需要，一般无需设置线程优先级。
+
+## 线程的生命周期？
+
+线程一共有五个状态，分别如下：
+
+- 新建(new)：当创建Thread类的一个实例（对象）时，此线程进入新建状态（未被启动）。例如：`Thread t1 = new Thread()` 。
+
+- 可运行(runnable)：线程对象创建后，其他线程(比如 main 线程）调用了该对象的 start 方法。该状态的线程位于可运行线程池中，等待被线程调度选中，获取 cpu 的使用权。例如：`t1.start()` 。
+
+  > 有些文章，会称可运行(runnable)为就绪，意思是一样的。
+
+- 运行(running)：线程获得 CPU 资源正在执行任务（`#run()` 方法），此时除非此线程自动放弃 CPU 资源或者有优先级更高的线程进入，线程将一直运行到结束。
+
+- 死亡(dead)：当线程执行完毕或被其它线程杀死，线程就进入死亡状态，这时线程不可能再进入就绪状态等待执行。
+
+  - 自然终止：正常运行完 `#run()`方法，终止。
+  - 异常终止：调用 `#stop()` 方法，让一个线程终止运行。
+
+- 堵塞(blocked)：由于某种原因导致正在运行的线程让出 CPU 并暂停自己的执行，即进入堵塞状态。直到线程进入可运行(runnable)状态，才有机会再次获得 CPU 资源，转到运行(running)状态。阻塞的情况有三种：
+
+  - 正在睡眠：调用 `#sleep(long t)` 方法，可使线程进入睡眠方式。
+
+    > 一个睡眠着的线程在指定的时间过去可进入可运行(runnable)状态。
+
+  - 正在等待：调用 `#wait()` 方法。
+
+    > 调用 `notify()` 方法，回到就绪状态。
+
+  - 被另一个线程所阻塞：调用 `#suspend()` 方法。
+
+    > 调用 `#resume()` 方法，就可以恢复。
+
+整体如下图所示：[![Thread 的线程状态](http://static.iocoder.cn/04a277229fd3b24e058417f9c571681c)](http://static.iocoder.cn/04a277229fd3b24e058417f9c571681c)Thread 的线程状态
+
+- 中间一行是线程的顺畅的执行过程的四个状态。其上下两侧，是存在对应的情况，达到阻塞状态和恢复执行的过程。
+- 有一点要注意，新建(new)和死亡(dead)是单向的状态，不可重复。****
+- 理解线程的状态，可以用早起坐地铁来比喻这个过程：
+  - 还没起床：sleeping 。
+  - 起床收拾好了，随时可以坐地铁出发：Runnable 。
+  - 等地铁来：Waiting 。
+  - 地铁来了，但要排队上地铁：I/O 阻塞 。
+  - 上了地铁，发现暂时没座位：synchronized 阻塞。
+  - 地铁上找到座位：Running 。
+  - 到达目的地：Dead 。
+
+如下是另外一个图，把阻塞的情况，放在了一起，也可以作为参考：[![Thread 的线程状态](http://static.iocoder.cn/3281138331173cdd53d1364f9c56d594)](http://static.iocoder.cn/3281138331173cdd53d1364f9c56d594)Thread 的线程状态
+
+无意中，又看到一张画的更牛逼的，如下图：
+
+[![Thread 的线程状态](http://static.iocoder.cn/5eeec5f68f4fc412246efd4111d6fdec)](http://static.iocoder.cn/5eeec5f68f4fc412246efd4111d6fdec)Thread 的线程状态
+
+🦅 **如何结束一个一直运行的线程？**
+
+一般来说，有两种方式：
+
+- 方式一，使用退出标志，这个 flag 变量要多线程可见。
+
+  > 在这种方式中，之所以引入共享变量，是因为该变量可以被多个执行相同任务的线程用来作为是否中断的信号，通知中断线程的执行。
+
+- 方式二，使用 interrupt 方法，结合 isInterrupted 方法一起使用。
+
+  > 如果一个线程由于等待某些事件的发生而被阻塞，又该怎样停止该线程呢？这种情况经常会发生，比如当一个线程由于需要等候键盘输入而被阻塞，或者调用 `Thread#join()` 方法，或者 `Thread#sleep(...)` 方法，在网络中调用`ServerSocket#accept()` 方法，或者调用了`DatagramSocket#receive()` 方法时，都有可能导致线程阻塞，使线程处于处于不可运行状态时。即使主程序中将该线程的共享变量设置为 `true` ，但该线程此时根本无法检查循环标志，当然也就无法立即中断。
+  >
+  > 这里我们给出的建议是，不要使用 `Thread#stop()· 方法，而是使用 Thread 提供的`#interrupt()` 方法，因为该方法虽然不会中断一个正在运行的线程，但是它可以使一个被阻塞的线程抛出一个中断异常，从而使线程提前结束阻塞状态，退出堵塞代码。
+
+所以，方式一和方式二，并不是冲突的两种方式，而是可能根据实际场景下，进行结合。
+
+🦅 **一个线程如果出现了运行时异常会怎么样?**
+
+如果这个异常没有被捕获的话，这个线程就停止执行了。
+
+另外重要的一点是：如果这个线程持有某个某个对象的监视器，那么这个对象监视器会被立即释放。
+
+## 创建线程的方式及实现？
+
+Java 中创建线程主要有三种方式：
+
+> 具体的每种方式的代码实现，可以看看 [《Java创建线程的四种方式》](https://blog.csdn.net/u012973218/article/details/51280044) 。
+>
+> 关于文章中的方式四，实际是基于线程池的方式，使用下面的三种方式，也是生产实践中，最为推荐和常用的方式。
+
+- 方式一，继承 Thread 类创建线程类。
+- 方式二，通过 Runnable 接口创建线程类。
+- 方式三，通过 Callable 和 Future 创建线程。
+
+创建线程的三种方式的对比：
+
+- 使用方式一
+
+  - 优点：编写简单，如果需要访问当前线程，则无需使用 `Thread#currentThread()` 方法，直接使用 `this` 即可获得当前线程。
+  - 缺点：线程类已经继承了 Thread 类，所以不能再继承其他父类。
+
+- 使用方式二、或方式三
+
+  - 优点：
+
+    - 线程类只是实现了 Runnable 接口或 Callable 接口，还可以继承其他类。
+
+    - 在这种方式下，多个线程可以共享同一个 `target` 对象，所以非常适合多个相同线程来处理同一份资源的情况，从而可以将 CPU、代码和数据分开，形成清晰的模型，较好地体现了面向对象的思想。
+
+      ```
+      Runnable runner = new Runnable(){ ... };
+      // 通过new Thread(target, name) 方法创建新线程
+      new Thread(runna,"新线程1").start();
+      new Thread(runna,"新线程2").start();
+      ```
+
+      - 当然，实际比较少这么用。
+
+    - 【最重要】**可以使用线程池**。
+
+  - 缺点：编程稍微复杂，如果要访问当前线程，则必须使用`Thread#currentThread()` 方法。
+
+🦅 **start 和 run 方法有什么区别？**
+
+- 当你调用 start 方法时，你将创建新的线程，并且执行在 run 方法里的代码。
+- 但是如果你直接调用 run 方法，它不会创建新的线程也不会执行调用线程的代码，只会把 run 方法当作普通方法去执行。
+
+**一个线程运行时发生异常会怎样？**
+
+如果异常没有被捕获该线程将会停止执行。`Thread.UncaughtExceptionHandler` 是用于处理未捕获异常造成线程突然中断情况的一个内嵌接口。当一个未捕获异常将造成线程中断的时候 JVM 会使用 `Thread#getUncaughtExceptionHandler()` 方法来查询线程的 UncaughtExceptionHandler 并将线程和异常作为参数传递给 handler 的 `#uncaughtException(exception)` 方法进行处理。
+
+具体的使用，可以看看 [《JAVA 多线程之 UncaughtExceptionHandler —— 处理非正常的线程中止》](https://blog.csdn.net/u013256816/article/details/50417822) 。
+
+## 如何使用 wait + notify 实现通知机制？
+
+> wait + notify 对于大多数胖友，一开始理解可能会比较困难，多看多理解吧。
+
+在 Java 发展史上，曾经使用 suspend、resume 方法对于线程进行阻塞唤醒，但随之出现很多问题，比较典型的还是死锁问题。
+
+解决方案可以使用以对象为目标的阻塞，即利用 Object 类的 wait 和 notify方法实现线程阻塞。
+
+- 首先，wait、notify 方法是针对对象的，调用任意对象的 wait 方法都将导致线程阻塞，阻塞的同时也将释放该对象的锁，相应地，调用任意对象的 notify 方法则将随机解除该对象阻塞的线程，但它需要重新获取改对象的锁，直到获取成功才能往下执行。
+- 其次，wait、notify 方法必须在 `synchronized` 块或方法中被调用，并且要保证同步块或方法的锁对象与调用 wait、notify 方法的对象是同一个，如此一来在调用 wait 之前当前线程就已经成功获取某对象的锁，执行 wait 阻塞后当前线程就将之前获取的对象锁释放。
+
+具体的实现，看看 [《Wait / Notify通知机制解析》](https://juejin.im/entry/5a2bb783f265da43163cff74) 文章。
+
+通过 wait + notify 的组合，可以通知机制，不过我们也可以使用其它工具，胖友可以思考下。例如如下的每一个方式：
+
+- Condition
+- CountDownLatch
+- Queue
+- Future
+- …
+
+> 艿艿：这个问题可以衍生下，Java 如何实现多线程之间的通讯和协作？具体的可以看看 [《Java多线程——线程间协作方式总结及使用示例》](https://blog.csdn.net/zhoucheng05_13/article/details/78311179) 文章，当然不仅限于该文章所提供的方式。😈 胖友可以认真思索下。
+
+🦅 **Thread类的 sleep 方法和对象的 wait 方法都可以让线程暂停执行，它们有什么区别？**
+
+> 关于这个问题，可以结合 [「线程的生命周期？」](https://svip.iocoder.cn/Java/Concurrent/Interview/#) 问题的图，一起瞅瞅。
+
+- sleep 方法，是线程类 Thread 的静态方法。调用此方法会让当前线程暂停执行指定的时间，将执行机会（CPU）让给其他线程，但是对象的锁依然保持，因此休眠时间结束后会自动恢复（线程回到就绪状态）
+- wait 方法，是 Object 类的方法。调用对象的 `#wait()` 方法，会导致当前线程放弃对象的锁（线程暂停执行），进入对象的等待池（wait pool），只有调用对象的 `#notify()` 方法（或`#notifyAll()`方法）时，才能唤醒等待池中的线程进入等锁池（lock pool），如果线程重新获得对象的锁就可以进入就绪状态。
+
+🦅 **请说出与线程同步以及线程调度相关的方法？**
+
+- wait 方法，使一个线程处于等待（阻塞）状态，并且释放所持有的对象的锁。
+- sleep 方法，使一个正在运行的线程处于睡眠状态，是一个静态方法，调用此方法要处理 InterruptedException 异常。
+- notify 方法，唤醒一个处于等待状态的线程，当然在调用此方法的时候，并不能确切的唤醒某一个等待状态的线程，而是由 JVM 确定唤醒哪个线程，而且与优先级无关。
+- notityAll 方法，唤醒所有处于等待状态的线程，该方法并不是将对象的锁给所有线程，而是让它们竞争，只有获得锁的线程才能进入就绪状态。
+
+🦅 **notify 和 notifyAll 有什么区别？**
+
+当一个线程进入 wait 之后，就必须等其他线程 notify/notifyAll 。
+
+- 使用 notifyAll,可以唤醒所有处于 wait 状态的线程，使其重新进入锁的争夺队列中，而 notify 只能唤醒一个。
+- 如果没把握，建议 notifyAll ，防止 notify 因为信号丢失而造成程序错误。
+
+关于 notify 的信息丢失，可以看看 [《wait 和 notify 的坑》](https://www.jianshu.com/p/91d95bb5a4bd) 文章。
+
+🦅 **为什么 wait, notify 和 notifyAll 这三方法不在 Thread 类里面？**
+
+一个很明显的原因是 Java 提供的锁是对象级的而不是线程级的，每个对象都有锁，通过线程获得。
+
+由于 wait，notify 和 notifyAll 方法都是锁级别的操作，所以把它们定义在 Object 类中，因为锁属于对象。
+
+🦅 **为什么 wait 和 notify 方法要在同步块中调用？**
+
+- Java API 强制要求这样做，如果你不这么做，你的代码会抛出 IllegalMonitorStateException 异常。
+- 还有一个原因是为了避免 wait 和 notify 之间产生竞态条件。
+
+🦅 **为什么你应该在循环中检查等待条件？**
+
+处于等待状态的线程可能会收到错误警报和伪唤醒，如果不在循环中检查等待条件，程序就会在没有满足结束条件的情况下退出。
+
+所以，我们不能写 `if (condition)` 而应该是 `while (condition)` ，特别是 CAS 竞争的时候。示例代码如下：
+
+```
+// The standard idiom for using the wait method
+synchronized (obj) {
+    while (condition does not hold) {
+        obj.wait(); // (Releases lock, and reacquires on wakeup)
+    }
+    ... // Perform action appropriate to condition
+}
+```
+
+- 另外，也可以看看 [《wait 必须放在 while 循环里面的原因探析》](https://blog.csdn.net/qq_35181209/article/details/77362297)
+
+## sleep、join、yield 方法有什么区别？
+
+1）sleep 方法
+
+在指定的毫秒数内，让当前正在执行的线程休眠（暂停执行），此操作受到系统计时器和调度程序精度和准确性的影响。让其他线程有机会继续执行，但它并不释放对象锁。也就是如果有`synchronized` 同步块，其他线程仍然不能访问共享数据。注意该方法要捕获异常。
+
+比如有两个线程同时执行(没有 `synchronized`)，一个线程优先级为`MAX_PRIORITY` ，另一个为 `MIN_PRIORITY` 。
+
+- 如果没有 sleep 方法，只有高优先级的线程执行完成后，低优先级的线程才能执行。但当高优先级的线程 `#sleep(5000)` 后，低优先级就有机会执行了。
+- 总之，sleep 方法，可以使低优先级的线程得到执行的机会，当然也可以让同优先级、高优先级的线程有执行的机会。
+
+2）yield 方法
+
+yield 方法和 sleep 方法类似，也不会释放“锁标志”，区别在于：
+
+- 它没有参数，即 yield 方法只是使当前线程重新回到可执行状态，所以执行yield 的线程有可能在进入到可执行状态后马上又被执行。
+- 另外 yield 方法只能使同优先级或者高优先级的线程得到执行机会，这也和 sleep 方法不同。
+
+3）join 方法
+
+Thread 的非静态方法 join ，让一个线程 B “加入”到另外一个线程 A 的尾部。在线程 A 执行完毕之前，线程 B 不能工作。示例代码如下：
+
+```
+Thread t = new MyThread();
+t.start();
+t.join();
+```
+
+- 保证当前线程停止执行，直到该线程所加入的线程 `t` 完成为止。然而，如果它加入的线程 `t` 没有存活，则当前线程不需要停止。
+
+🦅 **线程的 sleep 方法和 yield 方法有什么区别？**
+
+- sleep 方法给其他线程运行机会时不考虑线程的优先级，因此会给低优先级的线程以运行的机会。yield 方法只会给相同优先级或更高优先级的线程以运行的机会。
+- 线程执行 sleep 方法后转入阻塞（blocked）状态，而执行 yield 方法后转入就绪（ready）状态。
+- sleep 方法声明抛出 InterruptedException 异常，而 yield 方法没有声明任何异常。
+- sleep 方法比 yield 方法（跟操作系统 CPU 调度相关）具有更好的可移植性。
+
+> 艿艿：实际场景下，我们很少使用 yield 方法噢。
+
+🦅 **为什么 Thread 类的 sleep 和 yield 方法是静态的？**
+
+Thread 类的 sleep 和 yield 方法，将在当前正在执行的线程上运行。所以在其他处于等待状态的线程上调用这些方法是没有意义的。这就是为什么这些方法是静态的。它们可以在当前正在执行的线程中工作，并避免程序员错误的认为可以在其他非运行线程调用这些方法。
+
+🦅 **sleep(0) 有什么用途？**
+
+`Thread#sleep(0)` 方法，并非是真的要线程挂起 0 毫秒，意义在于这次调用 `Thread#sleep(0)` 方法，把当前线程确实的被冻结了一下，让其他线程有机会优先执行。`Thread#sleep(0)` 方法，是你的线程暂时放弃 CPU ，也就是释放一些未用的时间片给其他线程或进程使用，就相当于一个**让位动作**。
+
+感兴趣的胖友，可以看看 [《Sleep(0) 的妙用》](https://blog.csdn.net/qiaoquan3/article/details/56281092) 的示例。
+
+🦅 **你如何确保 main 方法所在的线程是 Java 程序最后结束的线程？**
+
+> 考点，就是 join 方法。
+
+我们可以使用 Thread 类的 `#join()` 方法，来确保所有程序创建的线程在 main 方法退出前结束。
+
+## interrupted 和 isInterrupted 方法的区别？
+
+1）interrupt 方法
+
+`Thread#interrupt()` 方法，用于中断线程。调用该方法的线程的状态为将被置为”中断”状态。
+
+注意：线程中断仅仅是置线程的中断状态位，不会停止线程。需要用户自己去监视线程的状态为并做处理。支持线程中断的方法（也就是线程中断后会抛出 InterruptedException 的方法）就是在监视线程的中断状态，一旦线程的中断状态被置为“中断状态”，就会抛出中断异常。
+
+2）interrupted
+
+`Thread#interrupted()` **静态**方法，查询当前线程的中断状态，并且清除原状态。如果一个线程被中断了，第一次调用 `#interrupted()` 方法则返回 `true` ，第二次和后面的就返回 `false` 了。
+
+```
+// Thread.java
+
+public static boolean interrupted() {
+    return currentThread().isInterrupted(true); // 清理
+}
+
+private native boolean isInterrupted(boolean ClearInterrupted);
+```
+
+3）interrupted
+
+`Thread#isInterrupted()` 方法，查询指定线程的中断状态，不会清除原状态。代码如下：
+
+```
+// Thread.java
+
+public boolean isInterrupted() {
+    return isInterrupted(false); // 不清楚
+}
+
+private native boolean isInterrupted(boolean ClearInterrupted);
+```
+
+## 什么叫线程安全？
+
+线程安全，是编程中的术语，指某个函数、函数库在多线程环境中被调用时，能够正确地处理多个线程之间的共享变量，使程序功能正确完成。
+
+🦅 **Servlet 是线程安全吗？**
+
+Servlet 不是线程安全的，Servlet 是单实例多线程的，当多个线程同时访问同一个方法，是不能保证共享变量的线程安全性的。
+
+🦅 **Struts2 是线程安全吗？**
+
+Struts2 的 Action 是多实例多线程的，是线程安全的，每个请求过来都会 `new` 一个新的 Action 分配给这个请求，请求完成后销毁。
+
+🦅 **SpringMVC 是线程安全吗？**
+
+不是的，和 Servlet 类似的处理流程。
+
+🦅 **单例模式的线程安全性?**
+
+老生常谈的问题了，首先要说的是单例模式的线程安全意味着：某个类的实例在多线程环境下只会被创建一次出来。单例模式有很多种的写法，我总结一下：
+
+- 饿汉式单例模式的写法：线程安全
+- 懒汉式单例模式的写法：非线程安全
+- 双检锁单例模式的写法：线程安全
+
+## 多线程同步和互斥有几种实现方法，都是什么？
+
+1）**线程同步**
+
+线程同步，是指线程之间所具有的一种制约关系，一个线程的执行依赖另一个线程的消息，当它没有得到另一个线程的消息时应等待，直到消息到达时才被唤醒。
+
+线程间的同步方法，大体可分为两类：用户模式和内核模式。顾名思义：
+
+- 内核模式，就是指利用系统内核对象的单一性来进行同步，使用时需要切换内核态与用户态。内核模式下的方法有：
+  - 事件
+  - 信号量
+  - 互斥量
+- 用户模式，就是不需要切换到内核态，只在用户态完成操作。用户模式下的方法有：
+  - 原子操作（例如一个单一的全局变量）
+  - 临界区
+
+2）**线程互斥**
+
+线程互斥，是指对于共享的进程系统资源，在各单个线程访问时的排它性。
+
+- 当有若干个线程都要使用某一共享资源时，任何时刻最多只允许一个线程去使用，其它要使用该资源的线程必须等待，直到占用资源者释放该资源。
+- 线程互斥可以看成是一种特殊的线程同步。
+
+🦅 **如何在两个线程间共享数据？**
+
+在两个线程间**共享变量**，即可实现共享。
+
+一般来说，共享变量要求变量本身是线程安全的，然后在线程内使用的时候，如果有对共享变量的复合操作，那么也得保证复合操作的线程安全性。
+
+🦅 **怎么检测一个线程是否拥有锁？**
+
+调用 `Thread#holdsLock(Object obj)` **静态**方法，它返回 `true` 如果当且仅当当前线程拥有某个具体对象的锁。代码如下：
+
+```
+// Thread.java
+
+public static native boolean holdsLock(Object obj);
+```
+
+🦅 **10 个线程和 2 个线程的同步代码，哪个更容易写？**
+
+从写代码的角度来说，两者的复杂度是相同的，因为同步代码与线程数量是相互独立的。
+
+但是同步策略的选择依赖于线程的数量，因为越多的线程意味着更大的竞争，所以你需要利用同步技术，如锁分离，这要求更复杂的代码和专业知识。
+
+## 什么是 ThreadLocal 变量？
+
+ThreadLocal ，是 Java 里一种特殊的变量。每个线程都有一个 ThreadLocal 就是每个线程都拥有了自己独立的一个变量，竞争条件被彻底消除了。
+
+它是为创建代价高昂的对象获取线程安全的好方法，比如你可以用 ThreadLocal 让 SimpleDateFormat 变成线程安全的，因为那个类创建代价高昂且每次调用都需要创建不同的实例所以不值得在局部范围使用它，如果为每个线程提供一个自己独有的变量拷贝，将大大提高效率。
+
+- 首先，通过复用减少了代价高昂的对象的创建个数。
+- 其次，你在没有使用高代价的同步或者不变性的情况下获得了线程安全。
+
+😈 所以，ThreadLocal 很适合实现线程级的单例。
+
+详细的，可以看看 [《Java并发编程：深入剖析ThreadLocal》](https://www.cnblogs.com/dolphin0520/p/3920407.html) 文章。
+
+关于源码，可以看看 [《【死磕 Java 并发】—– 深入分析 ThreadLocal》](http://www.iocoder.cn/JUC/sike/ThreadLocal/?vip) 。
+
+🦅 **什么是 InheritableThreadLocal ？**
+
+InheritableThreadLocal 类，是 ThreadLocal 类的子类。ThreadLocal 中每个线程拥有它自己的值，与 ThreadLocal 不同的是，**InheritableThreadLocal 允许一个线程以及该线程创建的所有子线程都可以访问它保存的值**。
+
+- 具体的实现原理，可以看看 [《Java 多线程：InheritableThreadLocal 实现原理》](https://blog.csdn.net/ni357103403/article/details/51970748) 文章。
+- 具体的使用示例，可以看看 [《Spring Cloud中Hystrix 线程隔离导致ThreadLocal数据丢失》](http://blog.didispace.com/Spring-Cloud中Hystrix-线程隔离导致ThreadLocal数据丢失/) 。
+
+🦅 **在多线程环境下，SimpleDateFormat 是线程安全的吗？**
+
+不是，非常不幸，DateFormat 的所有实现，包括 SimpleDateFormat 都不是线程安全的，因此你不应该在多线程序中使用，除非是在对外线程安全的环境中使用，**如将 SimpleDateFormat 限制在 ThreadLocal 中**。
+
+如果你不这么做，在解析或者格式化日期的时候，可能会获取到一个不正确的结果。因此，从日期、时间处理的所有实践来说，我强力推荐 joda-time 库。
+
+## 如何在 Java 中获取线程堆栈？
+
+- `kill -3 [java pid]`
+
+  不会在当前终端输出，它会输出到代码执行的或指定的地方去。比如， `kill -3 tomcat pid` , 输出堆栈到 log 目录下。
+
+- `Jstack [java pid]`
+
+  这个比较简单，在当前终端显示，也可以重定向到指定文件中。
+
+- [`JVisualVM：Thread Dump`](https://juejin.im/post/5a3b92def265da4319567218)
+
+  不做说明，打开 JVisualVM 后，都是界面操作，过程还是很简单的。
+
+## 什么是Java Timer 类？
+
+`java.util.Timer` ，是一个工具类，可以用于安排一个线程在未来的某个特定时间执行。Timer 类可以用安排一次性任务或者周期任务。
+
+`java.util.TimerTask` ，是一个实现了 Runnable 接口的抽象类，我们需要去继承这个类来创建我们自己的定时任务并使用 Timer 去安排它的执行。
+
+目前有开源的 Qurtz 可以用来创建定时任务。
+
+## 你有哪些多线程开发良好的实践？
+
+- 1、给线程命名。
+
+  > 这样可以方便找 bug 或追踪。OrderProcessor、QuoteProcessor、TradeProcessor 这种名字比 Thread-1、Thread-2、Thread-3 好多了，给线程起一个和它要完成的任务相关的名字，所有的主要框架甚至JDK都遵循这个最佳实践。
+
+- 2、最小化同步范围。
+
+  > 锁花费的代价高昂且上下文切换更耗费时间空间，试试最低限度的使用同步和锁，缩小临界区。因此相对于同步方法我更喜欢同步块，它给我拥有对锁的绝对控制权。
+
+- 3、优先使用 `volatile` ，而不是 `synchronized` 。
+
+- 4、尽可能使用更高层次的并发工具而非 wait 和 notify 方法来实现线程通信。
+
+  > 首先，CountDownLatch, Semaphore, CyclicBarrier 和 Exchanger 这些同步类简化了编码操作，而用 wait 和 notify 很难实现对复杂控制流的控制。
+  >
+  > 其次，这些类是由最好的企业编写和维护在后续的 JDK 中它们还会不断优化和完善，使用这些更高等级的同步工具你的程序可以不费吹灰之力获得优化。
+
+- 5、优先使用并发容器，而非同步容器。
+
+  > 这是另外一个容易遵循且受益巨大的最佳实践，并发容器比同步容器的可扩展性更好，所以在并发编程时使用并发集合效果更好。如果下一次你需要用到 Map ，我们应该首先想到用 ConcurrentHashMap 类。
+
+- 6、考虑使用线程池。
+
+## 并发编程和并行编程有什么区别？
+
+并发（Concurrency）和并行（Parallellism）是：
+
+- 解释一：并行是指两个或者多个事件在同一时刻发生；而并发是指两个或多个事件在同一时间间隔发生。
+- 解释二：并行是在不同实体上的多个事件；并发是在同一实体上的多个事件。
+- 解释三：在一台处理器上“同时”处理多个任务，在多台处理器上同时处理多个任务。如 Hadoop 分布式集群。
+
+所以并发编程的目标是，充分的利用处理器的每一个核，以达到最高的处理性能。
+
+## 同步和异步有何异同，在什么情况下分别使用他们？
+
+如果数据将在线程间共享。例如正在写的数据以后可能被另一个线程读到，或者正在读的数据可能已经被另一个线程写过了，那么这些数据就是共享数据，必须进行**同步**存取。
+
+当应用程序在对象上调用了一个需要花费很长时间来执行的方法，并且不希望让程序等待方法的返回时，就应该使用**异步**编程，在很多情况下采用异步途径往往更有效率。
+
+> 当然，如果我们对效率没有特别大的要求，也不一定需要使用异步编程，因为它会带来编码的复杂性。总之，合适才是正确的。
+
+# Java 锁
+
+- `synchronized`
+  - [![synchronized-1](http://static.iocoder.cn/b9bc9653929e5da43d8edad6e6a0d293)](http://static.iocoder.cn/b9bc9653929e5da43d8edad6e6a0d293)synchronized-1
+  - [![synchronized-2导图](http://static.iocoder.cn/a79be5f48c26abb905348e43a1732d55)](http://static.iocoder.cn/a79be5f48c26abb905348e43a1732d55)synchronized-2导图
+- `volatile`
+  - [![volatile](http://static.iocoder.cn/506052a856416414e18c7ed79d43cc5c)](http://static.iocoder.cn/506052a856416414e18c7ed79d43cc5c)volatile
+
+## `synchronized` 的原理是什么?
+
+`synchronized`是 Java 内置的关键字，它提供了一种独占的加锁方式。
+
+- `synchronized`的获取和释放锁由JVM实现，用户不需要显示的释放锁，非常方便。
+
+- 然而，
+
+  ```
+  synchronized
+  ```
+
+   
+
+  也有一定的局限性。
+
+  - 当线程尝试获取锁的时候，如果获取不到锁会一直阻塞。
+  - 如果获取锁的线程进入休眠或者阻塞，除非当前线程异常，否则其他线程尝试获取锁必须一直等待。
+
+关于原理，直接阅读 [《【死磕 Java 并发】—– 深入分析 synchronized 的实现原理》](http://www.iocoder.cn/JUC/sike/synchronized/?vip) 文章，有几个重点要注意看。
+
+- 实现原理
+- Java 对象头、Monitor
+- 锁优化
+  - 自旋锁
+    - 适应自旋锁
+  - 锁消除
+  - 锁粗化
+  - 锁的升级
+    - 重量级锁
+    - 轻量级锁
+    - 偏向锁
+
+🦅 **当一个线程进入某个对象的一个 `synchronized` 的实例方法后，其它线程是否可进入此对象的其它方法？**
+
+- 如果其他方法没有 `synchronized` 的话，其他线程是可以进入的。
+- 所以要开放一个线程安全的对象时，得保证每个方法都是线程安全的。
+
+🦅 **同步方法和同步块，哪个是更好的选择？**
+
+同步块是更好的选择，因为它不会锁住整个对象（当然你也可以让它锁住整个对象）。同步方法会锁住整个对象，哪怕这个类中有多个不相关联的同步块，这通常会导致他们停止执行并需要等待获得这个对象上的锁。
+
+同步块更要符合开放调用的原则，只在需要锁住的代码块锁住相应的对象，这样从侧面来说也可以避免死锁。
+
+🦅 **在监视器(Monitor)内部，是如何做线程同步的？**
+
+监视器和锁在 Java 虚拟机中是一块使用的。监视器监视一块同步代码块，确保一次只有一个线程执行同步代码块。每一个监视器都和一个对象引用相关联。**线程在获取锁之前不允许执行同步代码**。
+
+🦅 **Java 如何实现“自旋”（spin）**
+
+参考 [《Java 锁的种类以及辨析（一）：自旋锁》](http://ifeve.com/java_lock_see1/)
+
+代码如下：
+
+```
+public class SpinLock {
+
+    private AtomicReference<Thread> sign =new AtomicReference<>();
+
+    public void lock() { // <1>
+        Thread current = Thread.currentThread();
+        while(!sign .compareAndSet(null, current)) {
+            // <1.1>
+        }
+    }
+
+    public void unlock () { // <2>
+        Thread current = Thread.currentThread();
+        sign .compareAndSet(current, null);
+    }
+
+}
+```
+
+- `<1>` 处，`#lock()` 方法，如果获得不到锁，就会“死循环”，直到或得到锁为止。考虑到“死循环”会持续占用 CPU ，可能导致其它线程无法获得到 CPU 执行，可以在 `<1.1>` 处增加 `Thread.yiead()` 代码段，出让下 CPU 。
+- `<2>` 处，`#unlock()` 方法，释放锁。
+
+## volatile 实现原理
+
+`volatile` 涉及的内容，其实蛮多的，所以胖友直接看：
+
+- [《【死磕 Java 并发】—– 深入分析 volatile 的实现原理》](http://www.iocoder.cn/JUC/sike/volatile/?vip)
+- [聊聊并发（一）——深入分析Volatile的实现原理](https://www.infoq.cn/article/ftf-java-volatile)
+
+🦅 **`volatile` 有什么用？**
+
+`volatile` 保证内存可见性和禁止指令重排。
+
+> 同时，`volatile` 可以提供部分原子性。
+
+简单来说，`volatile` 用于多线程环境下的单次操作(单次读或者单次写)。
+
+🦅 **`volatile` 变量和 atomic 变量有什么不同？**
+
+- `volatile` 变量，可以确保先行关系，即写操作会发生在后续的读操作之前，但它并不能保证原子性。例如用 `volatile` 修饰 `count` 变量，那么 `count++` 操作就不是原子性的。
+- AtomicInteger 类提供的 atomic 方法，可以让这种操作具有原子性。例如 `#getAndIncrement()` 方法，会原子性的进行增量操作把当前值加一，其它数据类型和引用变量也可以进行相似操作。
+
+🦅 **可以创建 `volatile` 数组吗?**
+
+Java 中可以创建 `volatile` 类型数组，不过只是一个指向数组的引用，而不是整个数组。如果改变引用指向的数组，将会受到 `volatile` 的保护，但是如果多个线程同时改变数组的元素，`volatile` 标示符就不能起到之前的保护作用了。
+
+同理，对于 Java POJO 类，使用 `volatile` 修饰，只能保证这个引用的可见性，不能保证其内部的属性。
+
+🦅 **`volatile` 能使得一个非原子操作变成原子操作吗?**
+
+一个典型的例子是在类中有一个 `long` 类型的成员变量。如果你知道该成员变量会被多个线程访问，如计数器、价格等，你最好是将其设置为 `volatile` 。为什么？因为 Java 中读取 `long` 类型变量不是原子的，需要分成两步，如果一个线程正在修改该 `long` 变量的值，另一个线程可能只能看到该值的一半（前 32 位）。但是对一个 `volatile` 型的 `long` 或 `double` 变量的读写是原子。
+
+> 如下的内容，可以作为上面的内容的补充。
+>
+> 一种实践是用 `volatile` 修饰 `long` 和 `double` 变量，使其能按原子类型来读写。`double` 和 `long` 都是64位宽，因此对这两种类型的读是分为两部分的，第一次读取第一个 32 位，然后再读剩下的 32 位，这个过程不是原子的，但 Java 中 `volatile` 型的 `long` 或 `double` 变量的读写是原子的。
+
+🦅 **`volatile` 类型变量提供什么保证？**
+
+`volatile` 主要有两方面的作用：
+
+1. 避免指令重排
+2. 可见性保证
+
+例如，JVM 或者 JIT 为了获得更好的性能会对语句重排序，但是 `volatile` 类型变量即使在没有同步块的情况下赋值也不会与其他语句重排序。
+
+- `volatile` 提供 happens-before 的保证，确保一个线程的修改能对其他线程是可见的。
+- 某些情况下，`volatile` 还能提供原子性，如读 64 位数据类型，像 `long` 和 `double` 都不是原子的(低 32 位和高 32 位)，但 `volatile` 类型的 `double` 和 `long` 就是原子的。**不过需要在 64 位的 JVM 虚拟机上**。详细的分析，可以看看 [《Java中 long 和 double 的原子性》](https://my.oschina.net/u/1753415/blog/724242) 。
+
+🦅 **`volatile` 和 `synchronized` 的区别？**
+
+1. `volatile` 本质是在告诉 JVM 当前变量在寄存器（工作内存）中的值是不确定的，需要从主存中读取。`synchronized` 则是锁定当前变量，只有当前线程可以访问该变量，其他线程被阻塞住。
+2. `volatile` 仅能使用在变量级别。`synchronized` 则可以使用在变量、方法、和类级别的。
+3. `volatile` 仅能实现变量的修改可见性，不能保证原子性。而`synchronized` 则可以保证变量的修改可见性和原子性。
+4. `volatile` 不会造成线程的阻塞。`synchronized` 可能会造成线程的阻塞。
+5. `volatile` 标记的变量不会被编译器优化。`synchronized`标记的变量可以被编译器优化。
+
+> 另外，会有面试官会问 `volatile` 能否取代 `synchronized` 呢？答案肯定是不能，虽然说 `volatile` 被称之为轻量级锁，但是和 `synchronized` 是有本质上的区别，原因就是上面的几点落。
+
+🦅 **什么场景下可以使用 `volatile` 替换 `synchronized` ？**
+
+1. 只需要保证共享资源的可见性的时候可以使用 `volatile` 替代，`synchronized` 保证可操作的原子性一致性和可见性。
+2. `volatile` 适用于新值不依赖于旧值的情形。
+3. 1 写 N 读。
+4. 不与其他变量构成不变性条件时候使用 `volatile` 。
+
+## 什么是死锁、活锁？
+
+死锁，是指两个或两个以上的进程（或线程）在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。
+
+产生死锁的必要条件：
+
+- 互斥条件：所谓互斥就是进程在某一时间内独占资源。
+- 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
+- 不剥夺条件：进程已获得资源，在末使用完之前，不能强行剥夺。
+- 循环等待条件：若干进程之间形成一种头尾相接的循环等待资源关系。
+
+死锁的解决方法：
+
+- 撤消陷于死锁的全部进程。
+- 逐个撤消陷于死锁的进程，直到死锁不存在。
+- 从陷于死锁的进程中逐个强迫放弃所占用的资源，直至死锁消失。
+- 从另外一些进程那里强行剥夺足够数量的资源分配给死锁进程，以解除死锁状态。
+
+🦅 **什么是活锁？**
+
+活锁，任务或者执行者没有被阻塞，由于某些条件没有满足，导致一直重复尝试，失败，尝试，失败。
+
+🦅 **死锁与活锁的区别？**
+
+活锁和死锁的区别在于，处于活锁的实体是在不断的改变状态，所谓的“活”，而处于死锁的实体表现为等待；活锁有可能自行解开，死锁则不能。
+
+实际上，聪慧的胖友是不是已经发现，死锁就是悲观锁可能产生的结果，而活锁是乐观锁可能产生的结果。
+
+## 什么是悲观锁、乐观锁？
+
+1）悲观锁
+
+悲观锁，总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁。
+
+- 传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。
+- 再比如 Java 里面的同步原语 `synchronized` 关键字的实现也是悲观锁。
+
+2）乐观锁
+
+乐观锁，顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。
+
+- 像数据库提供的类似于 write_condition 机制，其实都是提供的乐观锁。
+
+  > 例如，version 字段（比较跟上一次的版本号，如果一样则更新，如果失败则要重复读-比较-写的操作）
+
+- 在 Java 中 `java.util.concurrent.atomic` 包下面的原子变量类就是使用了乐观锁的一种实现方式 CAS 实现的。
+
+乐观锁的实现方式：
+
+- 使用版本标识来确定读到的数据与提交时的数据是否一致。提交后修改版本标识，不一致时可以采取丢弃和再次尝试的策略。
+- Java 中的 Compare and Swap 即 CAS ，当多个线程尝试使用 CAS 同时更新同一个变量时，只有其中一个线程能更新变量的值，而其它线程都失败，失败的线程并不会被挂起，而是被告知这次竞争中失败，并可以再次尝试。
+
+# Java Lock 接口
+
+> 艿艿：虽然 Lock 也翻译成锁，但是和上面的 [「Java 锁」](https://svip.iocoder.cn/Java/Concurrent/Interview/#) 分开，它更多强调的是 `synchronized` 和 `volatile` 关键字带来的重量级和轻量级锁。而 Lock 是 Java 锁接口，提供了更多灵活的功能。
+
+[![Lock](http://static.iocoder.cn/d2cd1e16577dd6482d1e58ace2062408)](http://static.iocoder.cn/d2cd1e16577dd6482d1e58ace2062408)Lock
+
+## Java AQS
+
+`java.util.concurrent.locks.AbstractQueuedSynchronizer` 抽象类，简称 AQS ，是一个用于构建锁和同步容器的同步器。事实上`concurrent` 包内许多类都是基于 AQS 构建。例如 ReentrantLock，Semaphore，CountDownLatch，ReentrantReadWriteLock，等。AQS 解决了在实现同步容器时设计的大量细节问题。
+
+AQS 使用一个 FIFO 的队列表示排队等待锁的线程，队列头节点称作“哨兵节点”或者“哑节点”，它不与任何线程关联。其他的节点与等待线程关联，每个节点维护一个等待状态 `waitStatus` 。
+
+可能这么说，胖友会一脸懵逼，最好的方式，还是直接去撸源码，可见如下的四篇文章。
+
+> 可能胖友在阅读时，会有一定的挫败感，没关系，大家都是如此，包括艿艿，还有我认识的各种大佬。
+
+- [《【死磕 Java 并发】—– J.U.C 之 AQS：AQS 简介》](http://www.iocoder.cn/JUC/sike/aqs-0-intro?vip)
+- [《【死磕 Java 并发】—– J.U.C 之 AQS：CLH 同步队列》](http://www.iocoder.cn/JUC/sike/aqs-1-clh?vip)
+- [《【死磕 Java 并发】—– J.U.C 之 AQS：同步状态的获取与释放》](http://www.iocoder.cn/JUC/sike/aqs-2?vip)
+- [《【死磕 Java 并发】—– J.U.C 之 AQS：阻塞和唤醒线程》](http://www.iocoder.cn/JUC/sike/aqs-3?vip)
+
+## 什么是 Java Lock 接口？
+
+`java.util.concurrent.locks.Lock` 接口，比 `synchronized` 提供更具拓展行的锁操作。它允许更灵活的结构，可以具有完全不同的性质，并且可以支持多个相关类的条件对象。它的优势有：
+
+- 可以使锁更公平。
+- 可以使线程在等待锁的时候响应中断。
+- 可以让线程尝试获取锁，并在无法获取锁的时候立即返回或者等待一段时间。
+- 可以在不同的范围，以不同的顺序获取和释放锁。
+
+## 什么是可重入锁（ReentrantLock）？
+
+举例来说明锁的可重入性。代码如下：
+
+```
+public class UnReentrant{
+
+    Lock lock = new Lock();
+
+    public void outer() {
+        lock.lock();
+        inner();
+        lock.unlock();
+    }
+
+    public void inner() {
+        lock.lock();
+        //do something
+        lock.unlock();
+    }
+
+}
+```
+
+- `#outer()` 方法中调用了 `#inner()` 方法，`#outer()` 方法先锁住了 `lock` ，这样 `#inner()` 就不能再获取 `lock` 。
+- 其实调用 `#outer()` 方法的线程已经获取了 `lock` 锁，但是不能在 `#inner()` 方法中重复利用已经获取的锁资源，这种锁即称之为不可重入。
+- 可重入就意味着：线程可以进入任何一个它已经拥有的锁所同步着的代码块。
+
+`synchronized`、ReentrantLock 都是可重入的锁，可重入锁相对来说简化了并发编程的开发。
+
+关于 ReentrantLock 类，详细的源码解析，可以看看 [《【死磕 Java 并发】—– J.U.C 之重入锁：ReentrantLock》](http://www.iocoder.cn/JUC/sike/ReentrantLock/?vip) 。
+
+> 简单来说，ReenTrantLock 的实现是一种自旋锁，通过循环调用 CAS 操作来实现加锁。它的性能比较好也是因为避免了使线程进入内核态的阻塞状态。想尽办法避免线程进入内核的阻塞状态是我们去分析和理解锁设计的关键钥匙。
+
+🦅 **synchronized 和 ReentrantLock 异同？**
+
+- 相同点
+  - 都实现了多线程同步和内存可见性语义。
+  - 都是可重入锁。
+- 不同点
+  - 同步实现机制不同
+    - `synchronized` 通过 Java 对象头锁标记和 Monitor 对象实现同步。
+    - ReentrantLock 通过CAS、AQS（AbstractQueuedSynchronizer）和 LockSupport（用于阻塞和解除阻塞）实现同步。
+      *
+  - 可见性实现机制不同
+    - `synchronized` 依赖 JVM 内存模型保证包含共享变量的多线程内存可见性。
+    - ReentrantLock 通过 ASQ 的 `volatile state` 保证包含共享变量的多线程内存可见性。
+  - 使用方式不同
+    - `synchronized` 可以修饰实例方法（锁住实例对象）、静态方法（锁住类对象）、代码块（显示指定锁对象）。
+    - ReentrantLock 显示调用 tryLock 和 lock 方法，需要在 `finally` 块中释放锁。
+  - 功能丰富程度不同
+    - `synchronized` 不可设置等待时间、不可被中断（interrupted）。
+    - ReentrantLock 提供有限时间等候锁（设置过期时间）、可中断锁（lockInterruptibly）、condition（提供 await、condition（提供 await、signal 等方法）等丰富功能
+  - 锁类型不同
+    - `synchronized` 只支持非公平锁。
+    - ReentrantLock 提供公平锁和非公平锁实现。当然，在大部分情况下，非公平锁是高效的选择。
+
+> 在 `synchronized` 优化以前，它的性能是比 ReenTrantLock 差很多的，但是自从 `synchronized` 引入了偏向锁，轻量级锁（自旋锁）后，两者的性能就差不多了，在两种方法都可用的情况下，官方甚至建议使用 `synchronized` 。
+>
+> 并且，实际代码实战中，可能的优化场景是，通过读写分离，进一步性能的提升，所以使用 ReentrantReadWriteLock 。😝
+
+## ReadWriteLock 是什么？
+
+ReadWriteLock ，读写锁是，用来提升并发程序性能的锁分离技术的 Lock 实现类。可以用于 “多读少写” 的场景，读写锁支持多个读操作并发执行，写操作只能由一个线程来操作。
+
+ReadWriteLock 对向数据结构相对不频繁地写入，但是有多个任务要经常读取这个数据结构的这类情况进行了优化。ReadWriteLock 使得你可以同时有多个读取者，只要它们都不试图写入即可。如果写锁已经被其他任务持有，那么任何读取者都不能访问，直至这个写锁被释放为止。
+
+ReadWriteLock 对程序性能的提高主要受制于如下几个因素：
+
+1. 数据被读取的频率与被修改的频率相比较的结果。
+2. 读取和写入的时间
+3. 有多少线程竞争
+4. 是否在多处理机器上运行
+
+ReadWriteLock 的源码解析，可以看看 [《【死磕 Java 并发】—– J.U.C 之读写锁：ReentrantReadWriteLock》](http://www.iocoder.cn/JUC/sike/ReentrantReadWriteLock/) 。
+
+## Condition 是什么？
+
+在没有 Lock 之前，我们使用 `synchronized` 来控制同步，配合 Object 的 `#wait()`、`#notify()` 等一系列方法可以实现**等待 / 通知模式**。在 Java SE 5 后，Java 提供了 Lock 接口，相对于 `synchronized` 而言，Lock 提供了条件 Condition ，对线程的等待、唤醒操作更加详细和灵活。下图是 Condition 与 Object 的监视器方法的对比（摘自《Java并发编程的艺术》）：
+
+[![Condition 与 Object 的监视器方法的对比](http://static.iocoder.cn/e7e7bb0837bbe68a4364366d4ec9c5db)](http://static.iocoder.cn/e7e7bb0837bbe68a4364366d4ec9c5db)Condition 与 Object 的监视器方法的对比
+
+- Condition 的使用，可以看看 [《怎么理解 Condition》](http://www.importnew.com/9281.html)
+- Condition 的源码，可以看看 [《【死磕 Java 并发】—– J.U.C 之 Condition》](http://www.iocoder.cn/JUC/sike/Condition/) 。
+
+🦅 **用三个线程按顺序循环打印 abc 三个字母，比如 abcabcabc ？**
+
+- 使用 Lock + Condition 来实现。具体代码，参看 [《用三个线程按顺序循环打印 abc 三个字母，比如 abcabcabc》](https://blog.csdn.net/Big_Blogger/article/details/65629204) 。
+- 使用 `synchronized` + await/notifyAll 来实现，参看 [《Java用三个线程按顺序循环打印 abc 三个字母,比如 abcabcabc》](https://blog.csdn.net/weixin_41704428/article/details/80482928) 。
+
+## LockSupport 是什么？
+
+LockSupport 是 JDK 中比较底层的类，用来创建锁和其他同步工具类的基本线程阻塞。
+
+- Java 锁和同步器框架的核心 AQS(AbstractQueuedSynchronizer)，就是通过调用 `LockSupport#park()`和 `LockSupport#unpark()` 方法，来实现线程的阻塞和唤醒的。
+- LockSupport 很类似于二元信号量(只有 1 个许可证可供使用)，如果这个许可还没有被占用，当前线程获取许可并继续执行；如果许可已经被占用，当前线程阻塞，等待获取许可。
+
+对于 LockSupport 了解即可，面试一般问的不多。感兴趣的胖友，可以看看如下文章：
+
+- [《多线程同步工具 —— LockSupport》](https://www.cnblogs.com/hvicen/p/6217303.html)
+- [《Java 并发编程 —— LockSupport》](http://www.tianshouzhi.com/api/tutorials/mutithread/303) 带部分源码解析。
+
+# Java 内存模型
+
+关于 Java 内存模型，涉及的内容会很多，所以建议胖友看如下的 [《深入Java内存模型.pdf》](https://files-cdn.cnblogs.com/files/skywang12345/深入Java内存模型.pdf) 这本小书。
+
+然后，看完之后你肯定会忘记，就可以靠 [《《深入理解 Java 内存模型》读书笔记》](http://www.iocoder.cn/JUC/zhisheng/Java-Memory-Model?vip) 来补刀。
+
+再另外，[《深入拆解 Java 虚拟机》](http://gk.link/a/100kc) 的 [「第五部分 高效并发」](https://svip.iocoder.cn/Java/Concurrent/Interview/#) 也推荐阅读。
+
+## 什么是 Java 内存模型？
+
+Java 虚拟机规范中试图定义一种 Java 内存模型（Java Memory Model，JMM）来屏蔽掉各层硬件和操作系统的内存访问差异，以实现让 Java 程序在各种平台下都能达到一致的内存访问效果。
+
+Java 内存模型规定了所有的变量都存储在主内存（Main Memory）中。每条线程还有自己的工作内存（Working Memory），线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝，线程对变量的所有操作（读取、赋值等）都必须在**工作内存**中进行，而不能直接读写主内存中的变量。不同的线程之间也无法直接访问对方工作内存中的变量，线程间的变量值的传递均需要通过主内存来完成，线程、主内存、工作内存三者的关系如下图：
+
+[![线程、主内存、工作内存](http://static.iocoder.cn/images/JDK/2020_02_07/01.png)](http://static.iocoder.cn/images/JDK/2020_02_07/01.png)线程、主内存、工作内存
+
+> 艿艿：当然，有个面试官会把 Java 内存模型，和 JVM 内存结构搞混淆。所以，在回答之前，可以先和面试官确认下说的是哪个。
+>
+> 关于 JVM 内存结构的面试题，我们在 [《精尽 Java【虚拟机】面试题》](http://svip.iocoder.cn/Java/VirtualMachine/Interview) 中在详细分享。
+
+## 两个线程之间是如何通信的呢？
+
+线程之间的通信方式，目前有共享内存和消息传递两种。
+
+**1）共享内存**
+
+在共享内存的并发模型里，线程之间共享程序的公共状态，线程之间通过写-读内存中的公共状态来隐式进行通信。典型的共享内存通信方式，就是通过共享对象进行通信。
+
+[![共享内存](http://static.iocoder.cn/images/JDK/2020_02_07/02.png)](http://static.iocoder.cn/images/JDK/2020_02_07/02.png)共享内存
+
+例如上图线程 A 与 线程 B 之间如果要通信的话，那么就必须经历下面两个步骤：
+
+1. 首先，线程 A 把本地内存 A 更新过得共享变量刷新到主内存中去。
+2. 然后，线程 B 到主内存中去读取线程 A 之前更新过的共享变量。
+
+**2）消息传递**
+
+在消息传递的并发模型里，线程之间没有公共状态，线程之间必须通过明确的发送消息来显式进行通信。在 Java 中典型的消息传递方式，就是 `#wait()` 和 `#notify()` ，或者 BlockingQueue 。
+
+[![消息传递](http://static.iocoder.cn/images/JDK/2020_02_07/03.png)](http://static.iocoder.cn/images/JDK/2020_02_07/03.png)消息传递
+
+## 为什么代码会重排序？
+
+在执行程序时，为了提供性能，处理器和编译器常常会对指令进行重排序，但是不能随意重排序，不是你想怎么排序就怎么排序，它需要满足以下两个条件：
+
+- 在单线程环境下不能改变程序运行的结果。
+- 存在数据依赖关系的不允许重排序
+
+**需要注意的是：重排序不会影响单线程环境的执行结果，但是会破坏多线程的执行语义**。
+
+## 什么是内存模型的 happens-before 呢？
+
+详细看 [《【死磕 Java 并发】—– Java 内存模型之 happens-before》](http://www.iocoder.cn/JUC/sike/happens-before/?vip) 文章。
+
+## 什么是内存屏障？
+
+内存屏障，又称内存栅栏，是一组处理器指令，用于实现对内存操作的顺序限制。
+
+🦅 **内存屏障为何重要？**
+
+对主存的一次访问一般花费硬件的数百次时钟周期。处理器通过缓存（caching）能够从数量级上降低内存延迟的成本这些缓存为了性能重新排列待定内存操作的顺序。也就是说，程序的读写操作不一定会按照它要求处理器的顺序执行。当数据是不可变的，同时/或者数据限制在线程范围内，这些优化是无害的。如果把这些优化与对称多处理（symmetric multi-processing）和共享可变状态（shared mutable state）结合，那么就是一场噩梦。
+
+当基于共享可变状态的内存操作被重新排序时，程序可能行为不定。一个线程写入的数据可能被其他线程可见，原因是数据写入的顺序不一致。适当的放置内存屏障，通过强制处理器顺序执行待定的内存操作来避免这个问题。
+
+# Java 并发容器
+
+## 什么是并发容器的实现？
+
+何为同步容器？可以简单地理解为通过 `synchronized`来实现同步的容器，如果有多个线程调用同步容器的方法，它们将会串行执行。
+
+- 比如 Vector，Hashtable，以及 `Collections#synchronizedSet()`，`Collections#synchronizedList()` 等方法返回的容器。
+- 可以通过查看 Vector，Hashtable 等这些同步容器的实现代码，可以看到这些容器实现线程安全的方式就是将它们的状态封装起来，并在需要同步的方法上加上关键字 `synchronized` 。
+
+并发容器，使用了与同步容器完全不同的加锁策略来提供更高的并发性和伸缩性。
+
+- 例如在 ConcurrentHashMap 中采用了一种粒度更细的加锁机制，可以称为分段锁。在这种锁机制下，允许任意数量的读线程并发地访问 map ，并且执行读操作的线程和写操作的线程也可以并发的访问 map ，同时允许一定数量的写操作线程并发地修改 map ，所以它可以在并发环境下实现更高的吞吐量。
+- 再例如，CopyOnWriteArrayList 。
+
+## SynchronizedMap 和 ConcurrentHashMap 有什么区别？
+
+- SynchronizedMap
+  - 一次锁住整张表来保证线程安全，所以每次只能有一个线程来访为 map 。
+- ConcurrentHashMap
+  - 使用分段锁来保证在多线程下的性能。ConcurrentHashMap 中则是一次锁住一个桶。ConcurrentHashMap 默认将 hash 表分为 16 个桶，诸如 get,put,remove 等常用操作只锁当前需要用到的桶。这样，原来只能一个线程进入，现在却能同时有 16 个写线程执行，并发性能的提升是显而易见的。【注意，这块是 JDK7 的实现。在 JDK8 中，具体的实现已经改变】
+  - 另外 ConcurrentHashMap 使用了一种不同的迭代方式。在这种迭代方式中，当 iterator 被创建后集合再发生改变就不再是抛出 ConcurrentModificationException 异常，取而代之的是在改变时 `new` 新的数据从而不影响原有的数据，iterator 完成后再将头指针替换为新的数据 ，这样 iterator 线程可以使用原来老的数据，而写线程也可以并发的完成改变。
+
+关于 ConcurrentHashMap 的源码解析，推荐胖友看看如下两篇文章：
+
+- [《【死磕 Java 并发】—– J.U.C 之 Java并发容器：ConcurrentHashMap》](http://www.iocoder.cn/JUC/sike/ConcurrentHashMap/?vip)
+- [《【死磕 Java 并发】—– J.U.C 之 ConcurrentHashMap 红黑树转换分析》](http://www.iocoder.cn/JUC/sike/ConcurrentHashMap-red-black-tree/?vip)
+
+🦅 **Java 中 ConcurrentHashMap 的并发度是什么？**
+
+在 JDK8 前，ConcurrentHashMap 把实际 map 划分成若干部分来实现它的可扩展性和线程安全。这种划分是使用并发度获得的，它是 ConcurrentHashMap 类构造函数的一个可选参数，默认值为 16 ，这样在多线程情况下就能避免争用。
+
+在 JDK8 后，它摒弃了 Segment（锁段）的概念，而是启用了一种全新的方式实现，利用 CAS 算法。同时加入了更多的辅助变量来提高并发度，具体内容还是查看源码吧。
+
+🦅 **ConcurrentHashMap 为何读不用加锁？**
+
+在 JDK7 以及以前
+
+- HashEntry 中的
+
+   
+
+  ```
+  key
+  ```
+
+  、
+
+  ```
+  hash
+  ```
+
+  、
+
+  ```
+  next
+  ```
+
+   
+
+  均为
+
+   
+
+  ```
+  final
+  ```
+
+   
+
+  型，只能表头插入、删除结点。
+
+  - HashEntry 类的 `value` 域被声明为 `volatile` 型。
+  - 不允许用 `null` 作为键和值，当读线程读到某个 HashEntry 的 `value` 域的值为 `null` 时，便知道产生了冲突——发生了重排序现象（put 方法设置新 `value` 对象的字节码指令重排序），需要加锁后重新读入这个 `value` 值。
+
+- `volatile` 变量 `count` 协调读写线程之间的内存可见性，写操作后修改 `count` ，读操作先读 `count`，根据 happen-before 传递性原则写操作的修改读操作能够看到。
+
+在 JDK8 开始
+
+- Node 的 `val` 和 `next` 均为 `volatile` 型。
+- `#tabAt(..,)` 和 `#casTabAt(...)` 对应的 Unsafe 操作实现了 `volatile` 语义。
+
+## CopyOnWriteArrayList 可以用于什么应用场景？
+
+CopyOnWriteArrayList(免锁容器)的好处之一是当多个迭代器同时遍历和修改这个列表时，不会抛出ConcurrentModificationException 异常。在 CopyOnWriteArrayList 中，写入将导致创建整个底层数组的副本，而源数组将保留在原地，使得复制的数组在被修改时，读取操作可以安全地执行。
+
+- 由于写操作的时候，需要拷贝数组，会消耗内存，如果原数组的内容比较多的情况下，可能导致 ygc 或者 fgc 。
+- 不能用于实时读的场景，像拷贝数组、新增元素都需要时间，所以调用一个 set 操作后，读取到数据可能还是旧的,虽然 CopyOnWriteArrayList 能做到最终一致性,但是还是没法满足实时性要求。
+
+CopyOnWriteArrayList 透露的思想：
+
+- 读写分离，读和写分开
+- 最终一致性
+- 使用另外开辟空间的思路，来解决并发冲突
+
+CopyOnWriteArrayList 适用于读操作远远多于写操作的场景。例如，缓存。
+
+关于 CopyOnWriteArrayList 的源码，可以看看 [《CopyOnWriteArrayList 实现原理及源码分析》](http://www.importnew.com/12773.html) 文章。
+
+# Java 阻塞队列
+
+## 什么是阻塞队列？有什么适用场景？
+
+阻塞队列（BlockingQueue）是一个支持两个附加操作的队列。这两个附加的操作是：
+
+- 在队列为空时，获取元素的线程会等待队列变为非空。
+- 当队列满时，存储元素的线程会等待队列可用。
+
+阻塞队列常用于生产者和消费者的场景：
+
+- 生产者是往队列里添加元素的线程，消费者是从队列里拿元素的线程
+- 阻塞队列就是生产者存放元素的容器，而消费者也只从容器里拿元素。
+
+> 艿艿：如下的内容，和上面是相对重复的，或者是换一个说法，重新描述。
+
+BlockingQueue 接口，是 Queue 的子接口，它的主要用途并不是作为容器，而是作为线程同步的的工具，因此他具有一个很明显的特性：
+
+- 当生产者线程试图向 BlockingQueue 放入元素时，如果队列已满，则线程被阻塞。
+- 当消费者线程试图从中取出一个元素时，如果队列为空，则该线程会被阻塞。
+- 正是因为它所具有这个特性，所以在程序中多个线程交替向BlockingQueue中 放入元素，取出元素，它可以很好的控制线程之间的通信。
+
+阻塞队列使用最经典的场景，就是 Socket 客户端数据的读取和解析：
+
+- 读取数据的线程不断将数据放入队列。
+- 然后，解析线程不断从队列取数据解析。
+
+## Java 提供了哪些阻塞队列的实现？
+
+JDK7 提供了 7 个阻塞队列。分别是：
+
+> Java5 之前实现同步存取时，可以使用普通的一个集合，然后在使用线程的协作和线程同步可以实现生产者，消费者模式，主要的技术就是用好 wait、notify、notifyAll、`sychronized` 这些关键字。
+>
+> 而在 Java5 之后，可以使用阻塞队列来实现，此方式大大简少了代码量，使得多线程编程更加容易，安全方面也有保障。
+
+- 【最常用】ArrayBlockingQueue ：一个由数组结构组成的有界阻塞队列。
+
+  > 此队列按照先进先出（FIFO）的原则对元素进行排序，但是默认情况下不保证线程公平的访问队列，即如果队列满了，那么被阻塞在外面的线程对队列访问的顺序是不能保证线程公平（即先阻塞，先插入）的。
+
+- LinkedBlockingQueue ：一个由链表结构组成的有界阻塞队列。
+
+  > 此队列按照先出先进的原则对元素进行排序
+
+- PriorityBlockingQueue ：一个支持优先级排序的无界阻塞队列。
+
+- DelayQueue：支持延时获取元素的无界阻塞队列，即可以指定多久才能从队列中获取当前元素。
+
+- SynchronousQueue：一个不存储元素的阻塞队列。
+
+  > 每一个 put 必须等待一个 take 操作，否则不能继续添加元素。并且他支持公平访问队列。
+
+- LinkedTransferQueue：一个由链表结构组成的无界阻塞队列。
+
+  > 相对于其他阻塞队列，多了 tryTransfer 和 transfer 方法。
+  >
+  > - transfer 方法：如果当前有消费者正在等待接收元素（take 或者待时间限制的 poll 方法），transfer 可以把生产者传入的元素立刻传给消费者。如果没有消费者等待接收元素，则将元素放在队列的 tail 节点，并等到该元素被消费者消费了才返回。
+  > - tryTransfer 方法：用来试探生产者传入的元素能否直接传给消费者。如果没有消费者在等待，则返回 false 。和上述方法的区别是该方法无论消费者是否接收，方法立即返回。而 transfer 方法是必须等到消费者消费了才返回。
+
+- LinkedBlockingDeque：一个由链表结构组成的双向阻塞队列。
+
+  > 优势在于多线程入队时，减少一半的竞争。
+
+具体的源码解析，可以看看如下文章：
+
+- [《【死磕 Java 并发】—– J.U.C 之阻塞队列：ArrayBlockingQueue》](http://www.iocoder.cn/JUC/sike/ArrayBlockingQueue?vip)
+- [《【死磕 Java 并发】—– J.U.C 之阻塞队列：PriorityBlockingQueue》](http://www.iocoder.cn/JUC/sike/PriorityBlockingQueue?vip)
+- [《【死磕 Java 并发】—– J.U.C 之阻塞队列：DelayQueue》](http://www.iocoder.cn/JUC/sike/DelayQueue?vip)
+- [《【死磕 Java 并发】—– J.U.C 之阻塞队列：SynchronousQueue》](http://www.iocoder.cn/JUC/sike/SynchronousQueue?vip)
+- [《【死磕 Java 并发】—– J.U.C 之阻塞队列：LinkedTransferQueue》](http://www.iocoder.cn/JUC/sike/LinkedTransferQueue?vip)
+- [《【死磕 Java 并发】—– J.U.C 之阻塞队列：LinkedBlockingDeque》](http://www.iocoder.cn/JUC/sike/LinkedBlockingDeque?vip)
+- [《【死磕 Java 并发】—– J.U.C 之阻塞队列：BlockingQueue 总结》](http://www.iocoder.cn/JUC/sike/BlockingQueue?vip)
+
+🦅 **阻塞队列提供哪些重要方法？**
+
+| 方法处理方式 | 抛出异常  | 返回特殊值 | 一直阻塞 | 超时退出             |
+| :----------- | :-------- | :--------- | :------- | :------------------- |
+| 插入方法     | add(e)    | offer(e)   | put(e)   | offer(e, time, unit) |
+| 移除方法     | remove()  | poll()     | take()   | poll(time, unit)     |
+| 检查方法     | element() | peek()     | 不可用   | 不可用               |
+
+🦅 **ArrayBlockingQueue 与 LinkedBlockingQueue 的区别？**
+
+| Queue               | 阻塞与否 | 是否有界 | 线程安全保障    | 适用场景                       | 注意事项                                                     |
+| :------------------ | :------- | :------- | :-------------- | :----------------------------- | :----------------------------------------------------------- |
+| ArrayBlockingQueue  | 阻塞     | 有界     | 一把全局锁      | 生产消费模型，平衡两边处理速度 | 用于存储队列元素的存储空间是预先分配的，使用过程中内存开销较小（无须动态申请存储空间） |
+| LinkedBlockingQueue | 阻塞     | 可配置   | 存取采用 2 把锁 | 生产消费模型，平衡两边处理速度 | 无界的时候注意内存溢出问题，用于存储队列元素的存储空间是在其使用过程中动态分配的，因此它可能会增加 JVM 垃圾回收的负担。 |
+
+感兴趣的胖友，可以看看如下两篇文章：
+
+- [《ArrayBlockingQueue 与 LinkedBlockingQueue》](https://www.jianshu.com/p/5b85c1794351)
+- [《从一个故障说说 Java 的三个 BlockingQueue》](http://hellojava.info/?p=464)
+
+## 什么是双端队列？
+
+在上面，我们看到的 LinkedBlockingQueue、ArrayBlockingQueue、PriorityBlockingQueue、SynchronousQueue 等，都是阻塞队列。
+
+而 ArrayDeque、LinkedBlockingDeque 就是双端队列，类名以 Deque 结尾。
+
+- 正如阻塞队列适用于生产者消费者模式，双端队列同样适用与另一种模式，即
+
+  工作密取
+
+  。在生产者-消费者设计中，所有消费者共享一个工作队列，而在工作密取中，每个消费者都有各自的双端队列。
+
+  - 如果一个消费者完成了自己双端队列中的全部工作，那么他就可以从其他消费者的双端队列末尾秘密的获取工作。具有更好的可伸缩性，这是因为工作者线程不会在单个共享的任务队列上发生竞争。
+  - 在大多数时候，他们都只是访问自己的双端队列，从而极大的减少了竞争。当工作者线程需要访问另一个队列时，它会从队列的尾部而不是头部获取工作，因此进一步降低了队列上的竞争。
+
+- 适用于：网页爬虫等任务中
+
+> 😈 实际场景下，双端队列，我们使用比较少。艿艿根本没用过。
+
+## 延迟队列的实现方式，DelayQueue 和时间轮算法的异同？
+
+JDK 的 Timer 和 DelayQueue 插入和删除操作的平均时间复杂度为 `O(nlog(n))` ，而基于时间轮可以将插入和删除操作的时间复杂度都降为 `O(1)` 。
+
+- 关于 DelayQueue 的实现方式，在 [《【死磕 Java 并发】—– J.U.C 之阻塞队列：DelayQueue》》](http://www.iocoder.cn/JUC/sike/DelayQueue?vip) 。
+- 关于实践论的实现方法，在 [《Kafka解惑之时间轮（TimingWheel）》](https://blog.csdn.net/u013256816/article/details/80697456) 。
+
+## 简述 ConcurrentLinkedQueue 和 LinkedBlockingQueue 的用处和不同之处？
+
+参考 [《LinkedBlockingQueue 和 ConcurrentLinkedQueue的用法及区别》](https://www.jianshu.com/p/1a49293294aa) 。
+
+在 Java 多线程应用中，队列的使用率很高，多数生产消费模型的首选数据结构就是队列(先进先出)。
+
+Java 提供的线程安全的 Queue 可以分为
+
+- 阻塞队列，典型例子是 LinkedBlockingQueue 。
+
+  > 适用阻塞队列的好处：多线程操作共同的队列时不需要额外的同步，另外就是队列会自动平衡负载，即那边（生产与消费两边）处理快了就会被阻塞掉，从而减少两边的处理速度差距。
+
+- 非阻塞队列，典型例子是 ConcurrentLinkedQueue 。
+
+  > 当许多线程共享访问一个公共集合时，`ConcurrentLinkedQueue` 是一个恰当的选择。
+
+具体的选择，如下：
+
+- LinkedBlockingQueue 多用于任务队列。
+  - 单生产者，单消费者
+  - 多生产者，单消费者
+- ConcurrentLinkedQueue 多用于消息队列。
+  - 单生产者，多消费者
+  - 多生产者，多消费者
+
+# Java 原子操作类
+
+## 什么是原子操作？
+
+原子操作（Atomic Operation），意为”不可被中断的一个或一系列操作”。
+
+- 处理器使用基于对缓存加锁或总线加锁的方式，来实现多处理器之间的原子操作。
+- 在 Java 中，可以通过锁和循环 CAS 的方式来实现原子操作。CAS操作 —— Compare & Set ，或是 Compare & Swap ，现在几乎所有的 CPU 指令都支持 CAS 的原子操作。
+
+原子操作是指一个不受其他操作影响的操作任务单元。原子操作是在多线程环境下避免数据不一致必须的手段。
+
+- `int++` 并不是一个原子操作，所以当一个线程读取它的值并加 1 时，另外一个线程有可能会读到之前的值，这就会引发错误。
+- 为了解决这个问题，必须保证增加操作是原子的，在 JDK5 之前我们可以使用同步技术来做到这一点。到 JDK5 后，`java.util.concurrent.atomic` 包提供了 `int` 和 `long` 类型的原子包装类，它们可以自动的保证对于他们的操作是原子的并且不需要使用同步。
+
+`java.util.concurrent` 这个包里面提供了一组原子类。其基本的特性就是在多线程环境下，当有多个线程同时执行这些类的实例包含的方法时，具有排他性，即当某个线程进入方法，执行其中的指令时，不会被其他线程打断，而别的线程就像自旋锁一样，一直等到该方法执行完成，才由 JVM 从等待队列中选择一个另一个线程进入，这只是一种逻辑上的理解。
+
+- 原子类：AtomicBoolean，AtomicInteger，AtomicLong，AtomicReference 。
+- 原子数组：AtomicIntegerArray，AtomicLongArray，AtomicReferenceArray 。
+- 原子属性更新器：AtomicLongFieldUpdater，AtomicIntegerFieldUpdater，AtomicReferenceFieldUpdater 。
+- 解决 ABA 问题的原子类：AtomicMarkableReference（通过引入一个`boolean` 来反映中间有没有变过），AtomicStampedReference（通过引入一个 `int` 来累加来反映中间有没有变过）。
+
+关于 CAS 的内容，建议胖友在看看 [《【死磕 Java 并发】—- 深入分析 CAS》](http://www.iocoder.cn/JUC/sike/CAS/) 。
+
+## CAS 操作有什么缺点？
+
+1）**ABA 问题**
+
+比如说一个线程 one 从内存位置 V 中取出 A ，这时候另一个线程 two 也从内存中取出 A ，并且 two 进行了一些操作变成了 B ，然后 two 又将 V 位置的数据变成 A ，这时候线程 one 进行 CAS 操作发现内存中仍然是 A ，然后 one 操作成功。尽管线程 one 的 CAS 操作成功，但可能存在潜藏的问题。
+
+从 Java5 开始 JDK 的 `atomic`包里提供了一个类 AtomicStampedReference 来解决 ABA 问题。
+
+2）**循环时间长开销大**
+
+对于资源竞争严重（线程冲突严重）的情况，CAS 自旋的概率会比较大，从而浪费更多的 CPU 资源，效率低于 `synchronized` 。
+
+3）**只能保证一个共享变量的原子操作**
+
+当对一个共享变量执行操作时，我们可以使用循环 CAS 的方式来保证原子操作，但是对多个共享变量操作时，循环 CAS 就无法保证操作的原子性，这个时候就可以用锁。
+
+# Java 并发工具类
+
+## Semaphore 是什么？
+
+Semaphore ，是一种新的同步类，它是一个计数信号。从概念上讲，从概念上讲，信号量维护了一个许可集合。
+
+- 如有必要，在许可可用前会阻塞每一个 `#acquire()` 方法，然后再获取该许可。
+- 每个 `#release()` 方法，添加一个许可，从而可能释放一个正在阻塞的获取者。
+- 但是，不使用实际的许可对象，Semaphore 只对可用许可的数量进行计数，并采取相应的行动。
+
+信号量常常用于多线程的代码中，比如数据库连接池。
+
+- 使用方式，可以看看 [《JAVA多线程 – 信号量(Semaphore)》](https://my.oschina.net/cloudcoder/blog/362974) 。
+- 源码解析，可以看看 [《【死磕 Java 并发】—– J.U.C 之并发工具类：Semaphore》](http://www.iocoder.cn/JUC/sike/Semaphore/) 。
+
+## 说说 CountDownLatch 原理
+
+CountDownLatch ，字面意思是减小计数（CountDown）的门闩（Latch）。它要做的事情是，等待指定数量的计数被减少，意味着门闩被打开，然后进行执行。
+
+CountDownLatch 默认的构造方法是 `CountDownLatch(int count)` ，其参数表示需要减少的计数，主线程调用 `#await()` 方法告诉 CountDownLatch 阻塞等待指定数量的计数被减少，然后其它线程调用 CountDownLatch 的 `#countDown()` 方法，减小计数(不会阻塞)。等待计数被减少到零，主线程结束阻塞等待，继续往下执行。
+
+- CountDownLatch 的使用示例，请看 [《Java 多线程 CountDownLatch 用法》](https://zk1878.iteye.com/blog/1002652) 。
+- CountDownLatch 的源码解析，请看 [《【死磕 Java 并发】—– J.U.C 之并发工具类：CountDownLatch》](http://www.iocoder.cn/JUC/sike/CountDownLatch/?vip)
+
+## 说说 CyclicBarrier 原理
+
+CyclicBarrier ，字面意思是可循环使用（Cyclic）的屏障（Barrier）。它要做的事情是，让一组线程到达一个屏障（也可以叫同步点）时被阻塞，直到最后一个线程到达屏障时，屏障才会开门，所有被屏障拦截的线程才会继续干活。
+
+CyclicBarrier 默认的构造方法是 `CyclicBarrier(int parties)` ，其参数表示屏障拦截的线程数量，每个线程调用 `#await()` 方法告诉 CyclicBarrier 我已经到达了屏障，然后当前线程被阻塞，直到 `parties` 个线程到达，结束阻塞。
+
+- CyclicBarrier 的使用示例，请看 [《CyclicBarrier 的用法》](https://www.cnblogs.com/liuling/p/2013-8-21-01.html)
+- CyclicBarrier 的源码解析，请看 [《【死磕 Java 并发】—- J.U.C 之并发工具类：CyclicBarrier》](http://www.iocoder.cn/JUC/sike/CyclicBarrier/?vip) 。
+
+## 说说 Exchanger 原理
+
+实际场景下，问了一圈朋友，Exchanger 基本没在业务中使用过。
+
+- Exchanger 的使用示例，请看 [《【Java并发】线程同步工具Exchanger的使用》](https://blog.csdn.net/eson_15/article/details/51581842) 。
+- Exchanger 的源码解析，请看 [《【死磕 Java 并发】—– J.U.C 之并发工具类：Exchanger》](http://www.iocoder.cn/JUC/sike/Exchanger/)
+
+## CyclicBarrier 和 CountdownLatch 有什么区别？
+
+CyclicBarrier 可以重复使用，而 CountdownLatch 不能重复使用。
+
+- CountDownLatch 其实可以把它看作一个计数器，只不过这个计数器的操作是原子操作。
+  - 你可以向 CountDownLatch 对象设置一个初始的数字作为计数值，任何调用这个对象上的 `#await()` 方法都会阻塞，直到这个计数器的计数值被其他的线程减为 0 为止。所以在当前计数到达零之前，await 方法会一直受阻塞。之后，会释放所有等待的线程，await 的所有后续调用都将立即返回。这种现象只出现一次——计数无法被重置。如果需要重置计数，请考虑使用 CyclicBarrier 。
+  - CountDownLatch 的一个非常典型的应用场景是：有一个任务想要往下执行，但必须要等到其他的任务执行完毕后才可以继续往下执行。假如我们这个想要继续往下执行的任务调用一个 CountDownLatch 对象的 `#await()` 方法，其他的任务执行完自己的任务后调用同一个 CountDownLatch 对象上的 `#countDown()` 方法，这个调用 `#await()` 方法的任务将一直阻塞等待，直到这个 CountDownLatch 对象的计数值减到 0 为止。
+- CyclicBarrier 一个同步辅助类，它允许一组线程互相等待，直到到达某个公共屏障点 (common barrier point)。在涉及一组固定大小的线程的程序中，这些线程必须不时地互相等待，此时 CyclicBarrier 很有用。因为该 barrier 在释放等待线程后可以重用，所以称它为循环的 barrier 。
+
+整理表格如下：
+
+| CountDownLatch                                               | CyclicBarrier                                                |
+| :----------------------------------------------------------- | :----------------------------------------------------------- |
+| 减计数方式                                                   | 加计数方式                                                   |
+| 计算为 0 时释放所有等待的线程                                | 计数达到指定值时释放所有等待线程                             |
+| 计数为 0 时，无法重置                                        | 计数达到指定值时，计数置为 0 重新开始                        |
+| 调用 `#countDown()` 方法计数减一，调用 `#await()` 方法只进行阻塞，对计数没任何影响 | 调用 `#await()` 方法计数加 1 ，若加 1 后的值不等于构造方法的值，则线程阻塞 |
+| 不可重复利用                                                 | 可重复利用                                                   |
+
+# Java 线程池
+
+[![线程池](http://static.iocoder.cn/346a78f2c213423bcce456102006f4b3)](http://static.iocoder.cn/346a78f2c213423bcce456102006f4b3)线程池
+
+## 什么是 Executor 框架？
+
+Executor 框架，是一个根据一组执行策略调用，调度，执行和控制的异步任务的框架。
+
+无限制的创建线程，会引起应用程序内存溢出。所以创建一个线程池是个更好的的解决方案，因为可以限制线程的数量并且可以回收再利用这些线程。利用 Executor 框架，可以非常方便的创建一个线程池。
+
+🦅 **为什么使用 Executor 框架？**
+
+1. 每次执行任务创建线程 `new Thread()` 比较消耗性能，创建一个线程是比较耗时、耗资源的。
+2. 调用 `new Thread()` 创建的线程缺乏管理，被称为野线程，而且可以无限制的创建，线程之间的相互竞争会导致过多占用系统资源而导致系统瘫痪，还有线程之间的频繁交替也会消耗很多系统资源。
+3. 接使用 `new Thread()` 启动的线程不利于扩展，比如定时执行、定期执行、定时定期执行、线程中断等都不便实现。
+
+🦅 **在 Java 中 Executor 和 Executors 的区别？**
+
+- Executors 是 Executor 的工具类，不同方法按照我们的需求创建了不同的线程池，来满足业务的需求。
+- Executor 接口对象，能执行我们的线程任务。
+  - ExecutorService 接口，继承了 Executor 接口，并进行了扩展，提供了更多的方法我们能获得任务执行的状态并且可以获取任务的返回值。
+    - 使用 ThreadPoolExecutor ，可以创建自定义线程池。
+  - Future 表示异步计算的结果，他提供了检查计算是否完成的方法，以等待计算的完成，并可以使用 `#get()` 方法，获取计算的结果。
+
+## 讲讲线程池的实现原理
+
+- [《Java并发编程：线程池的使用》](http://www.cnblogs.com/dolphin0520/p/3932921.html)
+- [《【死磕 Java 并发】—– J.U.C 之线程池：线程池的基础架构》](http://www.iocoder.cn/JUC/sike/ThreadPool-core/?vip)
+- [《【死磕 Java 并发】—– J.U.C 之线程池：ThreadPoolExecutor》](http://www.iocoder.cn/JUC/sike/ThreadPoolExecutor/?vip)
+- [《【死磕 Java 并发】—– J.U.C 之线程池：ScheduledThreadPoolExecutor》](http://www.iocoder.cn/JUC/sike/ScheduledThreadPoolExecutor/?vip)
+
+## 创建线程池的几种方式？
+
+Java 类库提供一个灵活的线程池以及一些有用的默认配置，我们可以通过Executors 的静态方法来创建线程池。
+
+> Executors 创建的线程池，分成普通任务线程池，和定时任务线程池。
+
+- 普通任务线程池
+
+  - 1、
+
+    ```
+    #newFixedThreadPool(int nThreads)
+    ```
+
+     
+
+    方法，创建一个固定长度的线程池。
+
+    - 每当提交一个任务就创建一个线程，直到达到线程池的最大数量，这时线程规模将不再变化。
+    - 当线程发生未预期的错误而结束时，线程池会补充一个新的线程。
+
+  - 2、
+
+    ```
+    #newCachedThreadPool()
+    ```
+
+     
+
+    方法，创建一个可缓存的线程池。
+
+    - 如果线程池的规模超过了处理需求，将自动回收空闲线程。
+    - 当需求增加时，则可以自动添加新线程。线程池的规模不存在任何限制。
+
+  - 3、
+
+    ```
+    #newSingleThreadExecutor()
+    ```
+
+     
+
+    方法，创建一个单线程的线程池。
+
+    - 它创建单个工作线程来执行任务，如果这个线程异常结束，会创建一个新的来替代它。
+    - 它的特点是，能确保依照任务在队列中的顺序来串行执行。
+
+- 定时任务线程池
+
+  - 4、`#newScheduledThreadPool(int corePoolSize)` 方法，创建了一个固定长度的线程池，而且以延迟或定时的方式来执行任务，类似 Timer 。
+  - 5、`#newSingleThreadExecutor()` 方法，创建了一个固定长度为 1 的线程池，而且以延迟或定时的方式来执行任务，类似 Timer 。
+
+🦅 **如何使用 ThreadPoolExecutor 创建线程池？**
+
+Executors 提供了创建线程池的常用模板，实际场景下，我们可能需要自动以更灵活的线程池，此时就需要使用 ThreadPoolExecutor 类。
+
+```
+// ThreadPoolExecutor.java
+
+public ThreadPoolExecutor(int corePoolSize,
+                          int maximumPoolSize,
+                          long keepAliveTime,
+                          TimeUnit unit,
+                          BlockingQueue<Runnable> workQueue,
+                          ThreadFactory threadFactory,
+                          RejectedExecutionHandler handler) {
+    if (corePoolSize < 0 ||
+        maximumPoolSize <= 0 ||
+        maximumPoolSize < corePoolSize ||
+        keepAliveTime < 0)
+        throw new IllegalArgumentException();
+    if (workQueue == null || threadFactory == null || handler == null)
+        throw new NullPointerException();
+    this.corePoolSize = corePoolSize;
+    this.maximumPoolSize = maximumPoolSize;
+    this.workQueue = workQueue;
+    this.keepAliveTime = unit.toNanos(keepAliveTime);
+    this.threadFactory = threadFactory;
+    this.handler = handler;
+}
+```
+
+- `corePoolSize` 参数，核心线程数大小，当线程数 < corePoolSize ，会创建线程执行任务。
+
+- ```
+  maximumPoolSize
+  ```
+
+   
+
+  参数，最大线程数， 当线程数 >= corePoolSize 的时候，会把任务放入
+
+   
+
+  ```
+  workQueue
+  ```
+
+   
+
+  队列中。
+
+  - `keepAliveTime` 参数，保持存活时间，当线程数大于 `corePoolSize` 的空闲线程能保持的最大时间。
+  - `unit` 参数，时间单位。
+
+- ```
+  workQueue
+  ```
+
+   
+
+  参数，保存任务的阻塞队列。
+
+  - `handler` 参数，超过阻塞队列的大小时，使用的拒绝策略。
+
+- `threadFactory` 参数，创建线程的工厂。
+
+🦅 **ThreadPoolExecutor 有哪些拒绝策略？**
+
+ThreadPoolExecutor 默认有四个拒绝策略：
+
+- `ThreadPoolExecutor.AbortPolicy()` ，直接抛出异常 RejectedExecutionException 。
+- `ThreadPoolExecutor.CallerRunsPolicy()` ，直接调用 run 方法并且阻塞执行。
+- `ThreadPoolExecutor.DiscardPolicy()` ，直接丢弃后来的任务。
+- `ThreadPoolExecutor.DiscardOldestPolicy()` ，丢弃在队列中队首的任务。
+
+如果我们有需要，可以自己实现 RejectedExecutionHandler 接口，实现自定义的拒绝逻辑。当然，绝大多数是不需要的。
+
+🦅 ****
+
+## 线程池的关闭方式有几种？
+
+ThreadPoolExecutor 提供了两个方法，用于线程池的关闭，分别是：
+
+- `#shutdown()` 方法，不会立即终止线程池，而是要等所有任务缓存队列中的任务都执行完后才终止，但再也不会接受新的任务。
+- `#shutdownNow()` 方法，立即终止线程池，并尝试打断正在执行的任务，并且清空任务缓存队列，返回尚未执行的任务。
+
+实际场景下，一般会结合这两个方法，一起实现线程池的优雅关闭。示例代码如下：
+
+```
+void shutdownAndAwaitTermination(ExecutorService pool) {
+  pool.shutdown(); // Disable new tasks from being submitted
+  try {
+    // Wait a while for existing tasks to terminate
+    if (!pool.awaitTermination(60, TimeUnit.SECONDS)) {
+      pool.shutdownNow(); // Cancel currently executing tasks
+      // Wait a while for tasks to respond to being cancelled
+      if (!pool.awaitTermination(60, TimeUnit.SECONDS))
+          System.err.println("Pool did not terminate");
+      }
+    }
+  } catch (InterruptedException ie) {
+    // (Re-)Cancel if current thread also interrupted
+    pool.shutdownNow();
+    // Preserve interrupt status
+    Thread.currentThread().interrupt();
+  }
+}
+```
+
+## Java 线程池大小为何会大多被设置成 CPU 核心数 +1 ？
+
+详细的可以看看 [《如何合理地估算线程池大小？》](http://ifeve.com/how-to-calculate-threadpool-size/) 。如下是简单的总结和整理：
+
+一般说来，大家认为线程池的大小经验值应该这样设置：（其中 N 为CPU的个数）
+
+- 如果是 CPU 密集型应用，则线程池大小设置为 N+1
+
+  > 因为 CPU 密集型任务使得 CPU 使用率很高，若开过多的线程数，只能增加上下文切换的次数，因此会带来额外的开销。
+
+- 如果是 IO 密集型应用，则线程池大小设置为 2N+1
+
+  > IO密 集型任务 CPU 使用率并不高，因此可以让 CPU 在等待 IO 的时候去处理别的任务，充分利用 CPU 时间。
+
+- 如果是混合型应用，那么分别创建线程池
+
+  > 可以将任务分成 IO 密集型和 CPU 密集型任务，然后分别用不同的线程池去处理。 只要分完之后两个任务的执行时间相差不大，那么就会比串行执行来的高效。
+  >
+  > 因为如果划分之后两个任务执行时间相差甚远，那么先执行完的任务就要等后执行完的任务，最终的时间仍然取决于后执行完的任务，而且还要加上任务拆分与合并的开销，得不偿失。
+
+如果一台服务器上只部署这一个应用并且只有这一个线程池，那么这种估算或许合理，具体还需自行测试验证。
+
+但是，IO 优化中，这样的估算公式可能更适合：最佳线程数目 = （（线程等待时间 + 线程 CPU 时间）/ 线程 CPU 时间 ）* CPU 数目
+**因为很显然，线程等待时间所占比例越高，需要越多线程。线程CPU时间所占比例越高，需要越少线程。**
+
+下面举个例子：比如平均每个线程 CPU 运行时间为 0.5s ，而线程等待时间（非 CPU 运行时间，比如 IO）为 1.5s ，CPU 核心数为 8 。
+那么根据上面这个公式估算得到：`((0.5 + 1.5) / 0.5) * 8 = 32`。这个公式进一步转化为：最佳线程数目 = （线程等待时间与线程 CPU 时间之比 + 1）* CPU数目。
+
+🦅 **线程池容量的动态调整？**
+
+ThreadPoolExecutor 提供了动态调整线程池容量大小的方法：
+
+- setCorePoolSize：设置核心池大小。
+- setMaximumPoolSize：设置线程池最大能创建的线程数目大小。
+
+当上述参数从小变大时，ThreadPoolExecutor 进行线程赋值，还可能立即创建新的线程来执行任务。
+
+## 什么是 Callable、Future、FutureTask ？
+
+1）**Callable**
+
+Callable 接口，类似于 Runnable ，从名字就可以看出来了，但是Runnable 不会返回结果，并且无法抛出返回结果的异常，而 Callable 功能更强大一些，被线程执行后，可以返回值，这个返回值可以被 Future 拿到，也就是说，Future 可以拿到异步执行任务的返回值。
+
+> 简单来说，可以认为是带有回调的 Runnable 。
+
+2）**Future**
+
+Future 接口，表示异步任务，是还没有完成的任务给出的未来结果。所以说 Callable 用于产生结果，Future 用于获取结果。
+
+3）**FutureTask**
+
+在 Java 并发程序中，FutureTask 表示一个可以取消的异步运算。
+
+- 它有启动和取消运算、查询运算是否完成和取回运算结果等方法。只有当运算完成的时候结果才能取回，如果运算尚未完成 get 方法将会阻塞。
+- 一个 FutureTask 对象，可以对调用了 Callable 和 Runnable 的对象进行包装，由于 FutureTask 也是继承了 Runnable 接口，所以它可以提交给 Executor 来执行。
+
+## 线程池执行任务的过程？
+
+刚创建时，里面没有线程调用 execute() 方法，添加任务时：
+
+1. 如果正在运行的线程数量小于核心参数
+
+    
+
+   ```
+   corePoolSize
+   ```
+
+    
+
+   ，继续创建线程运行这个任务
+
+   - 否则，如果正在运行的线程数量大于或等于 `corePoolSize` ，将任务加入到阻塞队列中。
+   - 否则，如果队列已满，同时正在运行的线程数量小于核心参数 `maximumPoolSize` ，继续创建线程运行这个任务。
+   - 否则，如果队列已满，同时正在运行的线程数量大于或等于 `maximumPoolSize` ，根据设置的拒绝策略处理。
+
+2. 完成一个任务，继续取下一个任务处理。
+
+   - 没有任务继续处理，线程被中断或者线程池被关闭时，线程退出执行，如果线程池被关闭，线程结束。
+   - 否则，判断线程池正在运行的线程数量是否大于核心线程数，如果是，线程结束，否则线程阻塞。因此线程池任务全部执行完成后，继续留存的线程池大小为 `corePoolSize` 。
+
+🦅 **线程池中 submit 和 execute 方法有什么区别？**
+
+两个方法都可以向线程池提交任务。
+
+- `#execute(...)` 方法，返回类型是 `void` ，它定义在 Executor 接口中。
+- `#submit(...)` 方法，可以返回持有计算结果的 Future 对象，它定义在 ExecutorService 接口中，它扩展了 Executor 接口，其它线程池类像 ThreadPoolExecutor 和 ScheduledThreadPoolExecutor 都有这些方法。
+
+🦅 **如果你提交任务时，线程池队列已满，这时会发生什么？**
+
+> 艿艿：重点在于线程池的队列是有界还是无界的。
+
+- 如果你使用的 LinkedBlockingQueue，也就是无界队列的话，没关系，继续添加任务到阻塞队列中等待执行，因为 LinkedBlockingQueue 可以近乎认为是一个无穷大的队列，可以无限存放任务。
+- 如果你使用的是有界队列比方说 ArrayBlockingQueue 的话，任务首先会被添加到 ArrayBlockingQueue 中，ArrayBlockingQueue满了，则会使用拒绝策略 RejectedExecutionHandler 处理满了的任务，默认是 AbortPolicy 。
+
+## Fork/Join 框架是什么？
+
+> 艿艿：这是，可能了解的人不多，我也是。大体知道就好。
+
+Oracle 的官方给出的定义是：Fork/Join 框架是一个实现了 ExecutorService接口 的多线程处理器。它可以把一个大的任务划分为若干个小的任务并发执行，充分利用可用的资源，进而提高应用的执行效率。
+
+我们再通过 Fork 和 Join 这两个单词来理解下 Fork/Join 框架。
+
+- Fork 就是把一个大任务切分为若干子任务并行的执行，Join 就是合并这些子任务的执行结果，最后得到这个大任务的结果。
+- 比如计算 `1+2+...＋10000` ，可以分割成 10 个子任务，每个子任务分别对 1000 个数进行求和，最终汇总这 10 个子任务的结果。
+
+感兴趣的胖友，可以看看如下文章：
+
+- [《JDK 7 中的 Fork/Join 模式》](https://www.ibm.com/developerworks/cn/java/j-lo-forkjoin/index.html)
+- [《聊聊并发（八） —— Fork/Join 框架介绍》](https://www.infoq.cn/article/fork-join-introduction)
+
+## 如何让一段程序并发的执行，并最终汇总结果？
+
+- 1、CountDownLatch：允许一个或者多个线程等待前面的一个或多个线程完成，构造一个 CountDownLatch 时指定需要 countDown 的点的数量，每完成一点就 countDown 一下。当所有点都完成，CountDownLatch 的 `#await()` 就解除阻塞。
+
+- 2、CyclicBarrier：可循环使用的 Barrier ，它的作用是让一组线程到达一个 Barrier 后阻塞，直到所有线程都到达 Barrier 后才能继续执行。
+
+  > CountDownLatch 的计数值只能使用一次，CyclicBarrier 可以通过使用 reset 重置，还可以指定到达栅栏后优先执行的任务。
+
+- 3、Fork/Join 框架，fork 把大任务分解成多个小任务，然后汇总多个小任务的结果得到最终结果。使用一个双端队列，当线程空闲时从双端队列的另一端领取任务。
+
+# 彩蛋
+
+真多，真多，好他喵的多！耐心看。
+
+哈哈哈，实际面试吧，也不会问这么多。嘻嘻~
+
+参考与推荐如下文章：
+
+- [《无锁队列的实现》](https://coolshell.cn/articles/8239.html)
+- [《Java并发编程 73 道面试题及答案》](https://blog.csdn.net/qq_34039315/article/details/7854931)
+- [《史上最全 Java 面试题（带全部答案）》](https://blog.csdn.net/linzhiqiang0316/article/details/80473906)
+- [《最近 5 年 133 个 Java 面试问题列表》](http://www.importnew.com/17232.html)
+- [《Java 基础知识》](https://github.com/Snailclimb/JavaGuide/blob/3dc5234d3a77d134e4768b17cc864c4cc1030e41/Java相关/Java基础知识.md)
+- [《Java并发编程指南》](https://blog.csdn.net/column/details/20860.html)
+- [《Java 线程池大小为何会大多被设置成 CPU 核心数 +1？》](https://www.zhihu.com/question/38128980)
+- [《Java线程面试题 Top 50》](http://www.importnew.com/12773.html)
\ No newline at end of file
diff --git a/面试题/29-Java【虚拟机】面试题.assets/01.jpg b/面试题/29-Java【虚拟机】面试题.assets/01.jpg
new file mode 100644
index 0000000..be94435
Binary files /dev/null and b/面试题/29-Java【虚拟机】面试题.assets/01.jpg differ
diff --git a/面试题/29-Java【虚拟机】面试题.assets/02.png b/面试题/29-Java【虚拟机】面试题.assets/02.png
new file mode 100644
index 0000000..9b43973
Binary files /dev/null and b/面试题/29-Java【虚拟机】面试题.assets/02.png differ
diff --git a/面试题/29-Java【虚拟机】面试题.assets/03.png b/面试题/29-Java【虚拟机】面试题.assets/03.png
new file mode 100644
index 0000000..93b3766
Binary files /dev/null and b/面试题/29-Java【虚拟机】面试题.assets/03.png differ
diff --git a/面试题/29-Java【虚拟机】面试题.assets/04.png b/面试题/29-Java【虚拟机】面试题.assets/04.png
new file mode 100644
index 0000000..e2cde4a
Binary files /dev/null and b/面试题/29-Java【虚拟机】面试题.assets/04.png differ
diff --git a/面试题/29-Java【虚拟机】面试题.assets/05.png b/面试题/29-Java【虚拟机】面试题.assets/05.png
new file mode 100644
index 0000000..a9fc539
Binary files /dev/null and b/面试题/29-Java【虚拟机】面试题.assets/05.png differ
diff --git a/面试题/29-Java【虚拟机】面试题.assets/06.png b/面试题/29-Java【虚拟机】面试题.assets/06.png
new file mode 100644
index 0000000..d053195
Binary files /dev/null and b/面试题/29-Java【虚拟机】面试题.assets/06.png differ
diff --git a/面试题/29-Java【虚拟机】面试题.assets/07.png b/面试题/29-Java【虚拟机】面试题.assets/07.png
new file mode 100644
index 0000000..d838d43
Binary files /dev/null and b/面试题/29-Java【虚拟机】面试题.assets/07.png differ
diff --git a/面试题/29-Java【虚拟机】面试题.assets/08-171824962283715.png b/面试题/29-Java【虚拟机】面试题.assets/08-171824962283715.png
new file mode 100644
index 0000000..04427f8
Binary files /dev/null and b/面试题/29-Java【虚拟机】面试题.assets/08-171824962283715.png differ
diff --git a/面试题/29-Java【虚拟机】面试题.assets/09.png b/面试题/29-Java【虚拟机】面试题.assets/09.png
new file mode 100644
index 0000000..73a66be
Binary files /dev/null and b/面试题/29-Java【虚拟机】面试题.assets/09.png differ
diff --git a/面试题/29-Java【虚拟机】面试题.assets/52ea9a3813e09621c563b1cd4bdf0d22.jpeg b/面试题/29-Java【虚拟机】面试题.assets/52ea9a3813e09621c563b1cd4bdf0d22.jpeg
new file mode 100644
index 0000000..b4808db
Binary files /dev/null and b/面试题/29-Java【虚拟机】面试题.assets/52ea9a3813e09621c563b1cd4bdf0d22.jpeg differ
diff --git a/面试题/29-Java【虚拟机】面试题.assets/5f64c6b9436f6efbe54cfc2d01727301.png b/面试题/29-Java【虚拟机】面试题.assets/5f64c6b9436f6efbe54cfc2d01727301.png
new file mode 100644
index 0000000..280310e
Binary files /dev/null and b/面试题/29-Java【虚拟机】面试题.assets/5f64c6b9436f6efbe54cfc2d01727301.png differ
diff --git a/面试题/29-Java【虚拟机】面试题.assets/67796f9fc657b7b4dd0054f561248f5b.png b/面试题/29-Java【虚拟机】面试题.assets/67796f9fc657b7b4dd0054f561248f5b.png
new file mode 100644
index 0000000..214d406
Binary files /dev/null and b/面试题/29-Java【虚拟机】面试题.assets/67796f9fc657b7b4dd0054f561248f5b.png differ
diff --git a/面试题/29-Java【虚拟机】面试题.assets/bc22a30cbe93b8dedda080144a73b613.png b/面试题/29-Java【虚拟机】面试题.assets/bc22a30cbe93b8dedda080144a73b613.png
new file mode 100644
index 0000000..8571658
Binary files /dev/null and b/面试题/29-Java【虚拟机】面试题.assets/bc22a30cbe93b8dedda080144a73b613.png differ
diff --git a/面试题/29-Java【虚拟机】面试题.assets/cc3f228ca5353fd5deb4b22b7a9709e6.jpeg b/面试题/29-Java【虚拟机】面试题.assets/cc3f228ca5353fd5deb4b22b7a9709e6.jpeg
new file mode 100644
index 0000000..5bd3421
Binary files /dev/null and b/面试题/29-Java【虚拟机】面试题.assets/cc3f228ca5353fd5deb4b22b7a9709e6.jpeg differ
diff --git a/面试题/29-Java【虚拟机】面试题.assets/f07ac7c68994aa21b7b4271073ea4e5b.jpeg b/面试题/29-Java【虚拟机】面试题.assets/f07ac7c68994aa21b7b4271073ea4e5b.jpeg
new file mode 100644
index 0000000..caf9982
Binary files /dev/null and b/面试题/29-Java【虚拟机】面试题.assets/f07ac7c68994aa21b7b4271073ea4e5b.jpeg differ
diff --git a/面试题/29-Java【虚拟机】面试题.assets/f20e86724ff310733d7556bd203dc061-171824962283717 b/面试题/29-Java【虚拟机】面试题.assets/f20e86724ff310733d7556bd203dc061-171824962283717
new file mode 100644
index 0000000..b44801b
Binary files /dev/null and b/面试题/29-Java【虚拟机】面试题.assets/f20e86724ff310733d7556bd203dc061-171824962283717 differ
diff --git a/面试题/29-Java【虚拟机】面试题.assets/fec52af474f1250831d46b541e0fe7a9.jpeg b/面试题/29-Java【虚拟机】面试题.assets/fec52af474f1250831d46b541e0fe7a9.jpeg
new file mode 100644
index 0000000..737101e
Binary files /dev/null and b/面试题/29-Java【虚拟机】面试题.assets/fec52af474f1250831d46b541e0fe7a9.jpeg differ
diff --git a/面试题/29-Java【虚拟机】面试题.md b/面试题/29-Java【虚拟机】面试题.md
new file mode 100644
index 0000000..02f721e
--- /dev/null
+++ b/面试题/29-Java【虚拟机】面试题.md
@@ -0,0 +1,1111 @@
+# 精尽 Java【虚拟机】面试题「最新更新时间：2024-02」
+
+以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。
+
+如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的 Java【虚拟机】面试题的大保健。
+
+而题目的难度，艿艿尽量按照从容易到困难的顺序，逐步下去。
+
+因为 Java 并发涉及到的内容会非常多，本面试题可能很难覆盖到所有的知识点，所以推荐 [《深入拆解 Java 虚拟机》](http://gk.link/a/100kc) 。并且，本文会将面试题和该书的章节，大体保持一致。嘻嘻~
+
+另外，本文涉及的面试题会超级超级超级多，所以艿艿已经分了小节，胖友要注意哟。
+
+对于大部分 JVM 的面试题，基本都是概念题，所以艿艿一些面试题如果和 [《深入拆解 Java 虚拟机》](http://gk.link/a/100kc) 中，可以找到对应的章节，会进行注明。毕竟，看书可以理解更加深刻。
+
+> 艿艿：因为和字节码、指令级，理解起来相对复杂，实际面试问的也相对少。所以，本文暂时先不写。当然，未来肯定要补的，这么有趣的东西，胖友说是不是。
+
+# 走近 Java
+
+## 什么是虚拟机？
+
+Java 虚拟机，是一个可以执行 Java 字节码的虚拟机进程。Java 源文件被编译成能被 Java 虚拟机执行的字节码文件( `.class` )。
+
+Java 被设计成允许应用程序可以运行在任意的平台，而不需要程序员为每一个平台单独重写或者是重新编译。Java 虚拟机让这个变为可能，因为它知道底层硬件平台的指令长度和其他特性。
+
+但是，跨平台的是 Java 程序(包括字节码文件)，，而不是 JVM。JVM 是用 C/C++ 开发的，是编译后的机器码，不能跨平台，不同平台下需要安装不同版本的 JVM 。
+
+[![不同平台，不同 JVM](29-Java【虚拟机】面试题.assets/5f64c6b9436f6efbe54cfc2d01727301.png)](http://static.iocoder.cn/5f64c6b9436f6efbe54cfc2d01727301)不同平台，不同 JVM
+
+- 也就是说，JVM 能够跨计算机体系结构来执行 Java 字节码，主要是由于 JVM 屏蔽了与各个计算机平台相关的软件或者硬件之间的差异，使得与平台相关的耦合统一由 JVM 提供者来实现。
+
+## JVM 由哪些部分组成？
+
+> 考察对 JVM 体系结构的掌握
+>
+> [《深入拆解 Java 虚拟机》](http://gk.link/a/100kc) 的 [「2.2 运行时数据区域」](https://svip.iocoder.cn/Java/VirtualMachine/Interview/#) 。
+
+JVM 的结构基本上由 4 部分组成：
+
+> 注意打钩的 4 个地方。
+
+[![img](29-Java【虚拟机】面试题.assets/01.jpg)](http://static.iocoder.cn/images/JDK/2020_02_10/01.jpg)
+
+- **类加载器**，在 JVM 启动时或者类运行时将需要的 class 加载到 JVM 中。
+
+- **内存区**，将内存划分成若干个区以模拟实际机器上的存储、记录和调度功能模块，如实际机器上的各种功能的寄存器或者 PC 指针的记录器等。
+
+  > 关于这一块，我们在 [「Java 内存区域与内存溢出异常」](https://svip.iocoder.cn/Java/VirtualMachine/Interview/#) 也会细看。
+
+- **执行引擎**，执行引擎的任务是负责执行 class 文件中包含的字节码指令，相当于实际机器上的 CPU 。
+
+- **本地方法调用**，调用 C 或 C++ 实现的本地方法的代码返回结果。
+
+## 怎样通过 Java 程序来判断 JVM 是 32 位 还是 64 位？
+
+Sun 有一个 Java System 属性来确定JVM的位数：32 或 64。
+
+- `sun.arch.data.model=32 // 32 bit JVM`
+- `sun.arch.data.model=64 // 64 bit JVM`
+
+我可以使用以下语句来确定 JVM 是 32 位还是 64 位：
+
+```
+System.getProperty("sun.arch.data.model")
+```
+
+🦅 **32 位 JVM 和 64 位 JVM 的最大堆内存分别是多数？**
+
+理论上说上 32 位的 JVM 堆内存可以到达 2^32，即 4GB ，但实际上会比这个小很多。不同操作系统之间不同，如 Windows 系统大约 1.5 GB，Solaris 大约 3GB。
+
+64 位 JVM 允许指定最大的堆内存，理论上可以达到 2^64 ，这是一个非常大的数字，实际上你可以指定堆内存大小到 100GB 。甚至有的 JVM，如 Azul ，堆内存到 1000G 都是可能的。
+
+🦅 **64 位 JVM 中，int 的长度是多数？**
+
+Java 中，int 类型变量的长度是一个固定值，与平台无关，都是 32 位或者 4 个字节。意思就是说，在 32 位 和 64 位 的Java 虚拟机中，int 类型的长度是相同的。
+
+# Java 内存区域与内存溢出异常
+
+## JVM 运行内存的分类？
+
+> [《深入拆解 Java 虚拟机》](http://gk.link/a/100kc) 的 [「2.3.1 对象的创建」](https://svip.iocoder.cn/Java/VirtualMachine/Interview/#) 。
+
+JVM 运行内存的分类如下图所示：
+
+> 注意，这个图是基于 JDK6 版本的运行内存的分类。
+
+[![img](29-Java【虚拟机】面试题.assets/02.png)](http://static.iocoder.cn/images/JDK/2020_02_10/02.png)
+
+- 程序计数器
+
+  ： Java 线程私有，类似于操作系统里的 PC 计数器，它可以看做是当前线程所执行的字节码的行号指示器。
+
+  - 如果线程正在执行的是一个 Java 方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址；如果正在执行的是 Native 方法，这个计数器值则为空（Undefined）。
+  - 此内存区域是唯一一个在 Java 虚拟机规范中没有规定任何 OutOfMemoryError 情况的区域。
+
+- 虚拟机栈（栈内存）
+
+  ：Java线程私有，虚拟机栈描述的是 Java 方法执行的内存模型：
+
+  - 每个方法在执行的时候，都会创建一个栈帧用于存储局部变量、操作数、动态链接、方法出口等信息。
+  - 每个方法调用都意味着一个栈帧在虚拟机栈中入栈到出栈的过程。
+
+- **本地方法栈** ：和 Java 虚拟机栈的作用类似，区别是该区域为 JVM 提供使用 Native 方法的服务。
+
+- 堆内存
+
+  （线程共享）：所有线程共享的一块区域，垃圾收集器管理的主要区域。
+
+  - 目前主要的垃圾回收算法都是分代收集算法，所以 Java 堆中还可以细分为：新生代和老年代；再细致一点的有 Eden 空间、From Survivor 空间、To Survivor 空间等，默认情况下新生代按照 `8:1:1` 的比例来分配。
+  - 根据 Java 虚拟机规范的规定，Java 堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可，就像我们的磁盘一样。
+
+- 方法区
+
+  （线程共享）：各个线程共享的一个区域，用于存储虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。
+
+  - 虽然 Java 虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫做 Non-Heap（非堆），目的应该是与 Java 堆区分开来。
+  - 运行时常量池：是方法区的一部分，用于存放编译器生成的各种字面量和符号引用。
+
+🦅 **直接内存是不是虚拟机运行时数据区的一部分？**
+
+参见 [《JVM 直接内存》](https://blog.csdn.net/leaf_0303/article/details/78961936) 文章。
+
+直接内存(Direct Memory)，并不是虚拟机运行时数据区的一部分，也不是 Java 虚拟机规范中农定义的内存区域。在 JDK1.4 中新加入了 NIO(New Input/Output) 类，引入了一种基于通道(Channel)与缓冲区（Buffer）的 I/O 方式，它可以使用 native 函数库直接分配堆外内存，然后通脱一个存储在 Java 堆中的 DirectByteBuffer 对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在 Java 堆和 Native 堆中来回复制数据。
+
+- 本机直接内存的分配不会受到 Java 堆大小的限制，受到本机总内存大小限制。
+- 配置虚拟机参数时，不要忽略直接内存，防止出现 OutOfMemoryError 异常。
+
+🦅 **直接内存（堆外内存）与堆内存比较？**
+
+1. 直接内存申请空间耗费更高的性能，当频繁申请到一定量时尤为明显。
+2. 直接内存 IO 读写的性能要优于普通的堆内存，在多次读写操作的情况下差异明显。
+
+🦅 **实际上，后续的版本，主要对【方法区】做了一定的调整**
+
+- JDK7 的改变
+
+  - 存储在永久代的部分数据就已经转移到了 Java Heap 或者是 Native Heap。但永久代仍存在于 JDK7 中，但是并没完全移除。
+  - 常量池和静态变量放到 Java 堆里。
+
+- JDK8 的改变
+
+  - 废弃 PermGen（永久代），新增 Metaspace（元数据区）。
+
+  - 那么方法区还在么？FROM 狼哥 的解答：方法区在 Metaspace 中了，方法区都是一个概念的东西。😈 狼哥通过撸源码获得该信息。
+
+    > 因为，《Java 虚拟机规范》只是规定了有方法区这么个概念和它的作用，并没有规定如何去实现它。那么，在不同的 JVM 上方法区的实现肯定是不同的了。
+    >
+    > 同时，大多数用的 JVM 都是 Sun 公司的 HotSpot 。在 HotSpot 上把 GC 分代收集扩展至方法区，或者说使用永久带来实现方法区。
+
+- 参考文章
+
+  - [《JVM 内存堆布局图解分析》](https://www.cnblogs.com/SaraMoring/p/5713732.html)
+  - [《笔记之 JVM 方法区：永久带 VS 元空间》](https://www.jianshu.com/p/855b38c57925)
+  - [《JVM —— 移除永久代》](https://blog.csdn.net/wenniuwuren/article/details/51170275)
+  - [《JDK 源码剖析五：JDK8 —— 废弃永久代（PermGen）迎来元空间（Metaspace）》](https://www.bbsmax.com/A/RnJW679gzq/)
+  - [《Java8 内存模型 —— 永久代(PermGen)和元空间(Metaspace)》](https://www.cnblogs.com/paddix/p/5309550.html)
+
+🦅 **JDK8 之后 Perm Space 有哪些变动? MetaSpace ⼤⼩默认是⽆限的么? 还是你们会通过什么⽅式来指定⼤⼩?**
+
+- JDK8 后用元空间替代了 Perm Space ；字符串常量存放到堆内存中。
+- MetaSpace 大小默认没有限制，一般根据系统内存的大小。JVM 会动态改变此值。
+- 可以通过 JVM 参数配置
+  - `-XX:MetaspaceSize` ： 分配给类元数据空间（以字节计）的初始大小（Oracle 逻辑存储上的初始高水位，the initial high-water-mark）。此值为估计值，MetaspaceSize 的值设置的过大会延长垃圾回收时间。垃圾回收过后，引起下一次垃圾回收的类元数据空间的大小可能会变大。
+  - `-XX:MaxMetaspaceSize` ：分配给类元数据空间的最大值，超过此值就会触发Full GC 。此值默认没有限制，但应取决于系统内存的大小，JVM 会动态地改变此值。
+
+🦅 **为什么要废弃永久代？**
+
+1）现实使用中易出问题。
+
+由于永久代内存经常不够用或发生内存泄露，爆出异常 `java.lang.OutOfMemoryError: PermGen` 。
+
+- 字符串存在永久代中，容易出现性能问题和内存溢出。
+- 类及方法的信息等比较难确定其大小，因此对于永久代的大小指定比较困难，太小容易出现永久代溢出，太大则容易导致老年代溢出。
+
+2）永久代会为 GC 带来不必要的复杂度，并且回收效率偏低。
+
+3）Oracle 可能会将HotSpot 与 JRockit 合二为一。
+
+参照 JEP122 ：http://openjdk.java.net/jeps/122 ，原文截取：
+
+> Motivation
+>
+> This is part of the JRockit and Hotspot convergence effort. JRockit customers do not need to configure the permanent generation (since JRockit does not have a permanent generation) and are accustomed to not configuring the permanent generation.
+
+即：移除永久代是为融合 HotSpot JVM 与 JRockit VM 而做出的努力，因为 JRockit 没有永久代，不需要配置永久代。
+
+## Java 内存堆和栈区别？
+
+- 栈内存用来存储基本类型的变量和对象的引用变量；堆内存用来存储Java中的对象，无论是成员变量，局部变量，还是类变量，它们指向的对象都存储在堆内存中。
+- 栈内存归属于单个线程，每个线程都会有一个栈内存，其存储的变量只能在其所属线程中可见，即栈内存可以理解成线程的私有内存；堆内存中的对象对所有线程可见。堆内存中的对象可以被所有线程访问。
+- 如果栈内存没有可用的空间存储方法调用和局部变量，JVM 会抛出 `java.lang.StackOverFlowError` 错误；如果是堆内存没有可用的空间存储生成的对象，JVM 会抛出 `java.lang.OutOfMemoryError` 错误。
+- 栈的内存要远远小于堆内存，如果你使用递归的话，那么你的栈很快就会充满。`-Xss` 选项设置栈内存的大小，`-Xms` 选项可以设置堆的开始时的大小。
+
+当然，如果你记不住这个些，只要记住如下即可：
+
+> JVM 中堆和栈属于不同的内存区域，使用目的也不同。栈常用于保存方法帧和局部变量，而对象总是在堆上分配。栈通常都比堆小，也不会在多个线程之间共享，而堆被整个 JVM 的所有线程共享。
+
+[![img](29-Java【虚拟机】面试题.assets/03.png)](http://static.iocoder.cn/images/JDK/2020_02_10/03.png)
+
+## JAVA 对象创建的过程？
+
+> [《深入拆解 Java 虚拟机》](http://gk.link/a/100kc) 的 [「2.3.1 对象的创建」](https://svip.iocoder.cn/Java/VirtualMachine/Interview/#) 。
+>
+> 注意，加粗的文字部分。
+
+JAVA 对象创建的过程，如下图所示：[![JAVA 对象创建的过程](29-Java【虚拟机】面试题.assets/06.png)](http://static.iocoder.cn/images/JDK/2020_02_10/06.png)JAVA 对象创建的过程
+
+- Java 中对象的创建就是在堆上分配内存空间的过程，此处说的对象创建仅限于 new 关键字创建的普通 Java 对象，不包括数组对象的创建。
+
+1）检测类是否被加载
+
+当虚拟机遇到 `new` 指令时，首先先去检查这个指令的参数是否能在常量池中**定位到一个类的符号引用**，并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有，就执行类加载过程。
+
+2）为对象分配内存
+
+类加载完成以后，虚拟机就开始为对象分配内存，此时所需内存的大小就已经确定了。只需要在堆上分配所需要的内存即可。
+
+具体的分配内存有两种情况：第一种情况是内存空间绝对规整，第二种情况是内存空间是不连续的。
+
+- 对于内存绝对规整的情况相对简单一些，虚拟机只需要在被占用的内存和可用空间之间移动指针即可，这种方式被称为“**指针碰撞**”。
+- 对于内存不规整的情况稍微复杂一点，这时候虚拟机需要维护一个列表，来记录哪些内存是可用的。分配内存的时候需要找到一个可用的内存空间，然后在列表上记录下已被分配，这种方式成为“**空闲列表**”。
+
+多线程并发时会出现正在给对象 A 分配内存，还没来得及修改指针，对象 B 又用这个指针**分配内存**，这样就出现问题了。解决这种问题有两种方案：
+
+- 第一种，是采用同步的办法，使用 CAS 来保证操作的原子性。
+- 另一种，是每个线程分配内存都在自己的空间内进行，即是每个线程都在堆中预先分配一小块内存，称为本地线程分配缓冲（Thread Local Allocation Buffer, TLAB），分配内存的时候再TLAB上分配，互不干扰。可以通过 `-XX:+/-UseTLAB` 参数决定。
+
+3）为分配的内存空间初始化零值
+
+对象的内存分配完成后，还需要将对象的内存空间都初始化为零值，这样能保证对象即使没有赋初值，也可以直接使用。
+
+4）对对象进行其他设置
+
+分配完内存空间，初始化零值之后，虚拟机还需要对对象进行其他必要的设置，设置的地方都在对象头中，包括这个对象所属的类，类的元数据信息，对象的 hashcode ，GC 分代年龄等信息。
+
+5）执行 init 方法
+
+执行完上面的步骤之后，在虚拟机里这个对象就算创建成功了，但是对于 Java 程序来说还需要执行 init 方法才算真正的创建完成，因为这个时候对象只是被初始化零值了，还没有真正的去根据程序中的代码分配初始值，调用了 init 方法之后，这个对象才真正能使用。
+
+到此为止一个对象就产生了，这就是 new 关键字创建对象的过程。过程如下：
+
+[![JAVA 对象创建的过程](29-Java【虚拟机】面试题.assets/07.png)](http://static.iocoder.cn/images/JDK/2020_02_10/07.png)JAVA 对象创建的过程
+
+> 另外，这个问题，面试官可能引申成 “`A a = new A()` 经历过什么过程”的问题。
+
+## 对象的内存布局是怎样的？
+
+> [《深入拆解 Java 虚拟机》](http://gk.link/a/100kc) 的 [「2.3.2 对象的内存布局」](https://svip.iocoder.cn/Java/VirtualMachine/Interview/#) 。
+
+对象的内存布局包括三个部分：
+
+- 对象头：对象头包括两部分信息。
+  - 第一部分，是存储对象自身的运行时数据，如哈希码，GC 分代年龄，锁状态标志，线程持有的锁等等。
+  - 第二部分，是类型指针，即对象指向类元数据的指针。
+- 实例数据：就是数据。
+- 对齐填充：不是必然的存在，就是为了对齐。
+
+## 对象是如何定位访问的？
+
+> [《深入拆解 Java 虚拟机》](http://gk.link/a/100kc) 的 [「2.3.3 对象的访问定位」](https://svip.iocoder.cn/Java/VirtualMachine/Interview/#) 。
+
+对象的访问定位有两种：
+
+- 句柄定位：Java 堆会画出一块内存来作为句柄池，reference 中存储的就是对象的句柄地址，而句柄中包含了对象实例数据与类型数据各自的具体地址信息。[![句柄定位](29-Java【虚拟机】面试题.assets/04.png)](http://static.iocoder.cn/images/JDK/2020_02_10/04.png)句柄定位
+- 直接指针访问：Java 堆对象的不居中就必须考虑如何放置访问类型数据的相关信息，而 reference 中存储的直接就是对象地址。[![直接指针访问](29-Java【虚拟机】面试题.assets/05.png)](http://static.iocoder.cn/images/JDK/2020_02_10/05.png)直接指针访问
+
+🦅 **对比两种方式？**
+
+这两种对象访问方式各有优势。
+
+- 使用句柄来访问的最大好处，就是 reference 中存储的是稳定的句柄地址，在对象被移动（垃圾收集时移动对象是非常普遍的行为）时只会改变句柄中的实例数据指针，而 reference 本身不需要修改。
+- 使用直接指针访问方式的最大好处就是速度更快，它节省了一次指针定位的时间开销，由于对象的访问在 Java 中非常频繁，因此这类开销积少成多后也是一项非常可观的执行成本。
+
+我们目前主要虚拟机 Sun HotSpot 而言，它是使用第二种方式进行对象访问的，但从整个软件开发的范围来看，各种语言和框架使用句柄来访问的情况也十分常见。
+
+## 有哪些 OutOfMemoryError 异常？
+
+> [《深入拆解 Java 虚拟机》](http://gk.link/a/100kc) 的 [「2.4 实战：OutOfMemoryError 异常」](https://svip.iocoder.cn/Java/VirtualMachine/Interview/#) 。
+
+在 Java 虚拟机中规范的描述中，除了程序计数器外，虚拟机内存的其它几个运行时区域都有发生的 OutOfMemoryError(简称为“OOM”) 异常的可能。
+
+- Java 堆溢出
+
+- 虚拟机栈和本地方法栈溢出
+
+- 方法区和运行时常量池溢出
+
+  > 从 JDK8 开始，就变成元数据区的内存溢出。
+
+- 本机直接内存溢出
+
+**1）Java 堆溢出**
+
+重现方式，参见 [《Java 堆溢出》](https://blog.csdn.net/sells2012/article/details/18654915) 文章。
+
+另外，Java 堆溢出的原因，有可能是内存泄露，可以使用 MAT 进行分析。
+
+**2）虚拟机栈和本地方法栈溢出**
+
+由于在 HotSpot 虚拟机中并不区分虚拟机栈和本地方法栈，因此，对于 HotSpot 来说，虽然 `-Xoss` 参数（设置本地方法栈大小）存在，但实际上是无效的，栈容量只由 `-Xss`参数设定。
+
+关于虚拟机栈和本地方法栈，在 Java 虚拟机规范中描述了两种异常：
+
+- 如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出 StackOverflowError 异常。
+
+  > StackOverflowError 不属于 OOM 异常哈。
+
+- 如果虚拟机在扩展栈时无法申请到足够的内存空间，则抛出 OutOfMemoryError 异常。
+
+重现方式，参见 [《OutOfMemoryError 异常 —— 虚拟机栈和本地方法栈溢出》](https://blog.csdn.net/en_joker/article/details/79727675) 文章。
+
+**3）运行时常量池溢出**
+
+因为 JDK7 将常量池和静态变量放到 Java 堆里，所以无法触发运行时常量池溢出。如果想要触发，可以使用 JDK6 的版本。
+
+重现方式，参见 [《JVM 内存溢出 - 方法区及运行时常量池溢出》](https://www.niuhp.com/java/jvm-oom-pg.html) 文章。
+
+**4）方法区的内存溢出**
+
+因为 JDK8 将方法区溢出，所以无法触发方法区的内存溢出溢出。如果想要触发，可以使用 JDK7 的版本。
+
+重现方式，参见 [《Java 方法区溢出》](https://blog.csdn.net/tanga842428/article/details/52636836) 文章。
+
+**5）元数据区的内存溢出**
+
+实际上，方法区的内存溢出在 JDK8 中，变成了元数据区的内存溢出。所以，重现方式，还是参见 [《Java 方法区溢出》](https://blog.csdn.net/tanga842428/article/details/52636836) 文章，只是说，需要增加 `-XX:MaxMetaspaceSize=10m` VM 配置项。
+
+**6）本机直接内存溢出**
+
+重现方式，参见 [《JVM 内存溢出 —— 直接内存溢出》](https://www.niuhp.com/java/jvm-oom-direct.html) 文章。
+
+------
+
+另外，非常推荐一篇文章，胖友耐心阅读，提供了更多有趣的案例，[《Java 内存溢出(OOM)异常完全指南》](https://www.jianshu.com/p/2fdee831ed03) 。
+
+🦅 **当出现了内存溢出，你怎么排错？**
+
+- 1、首先，控制台查看错误日志。
+- 2、然后，使用 JDK 自带的 jvisualvm 工具查看系统的堆栈日志。
+- 3、定位出内存溢出的空间：堆，栈还是永久代（JDK8 以后不会出现永久代的内存溢出）。
+  - 如果是堆内存溢出，看是否创建了超大的对象。
+  - 如果是栈内存溢出，看是否创建了超大的对象，或者产生了死循环。
+
+## Java 中会存在内存泄漏吗？
+
+理论上 Java 因为有垃圾回收机制（GC）不会存在内存泄露问题（这也是 Java 被广泛使用于服务器端编程的一个重要原因）。然而在实际开发中，可能会存在无用但可达的对象，这些对象不能被 GC 回收也会发生内存泄露。例如说：
+
+- Hibernate 的 Session（一级缓存）中的对象属于持久态，垃圾回收器是不会回收这些对象的，然而这些对象中可能存在无用的垃圾对象。
+- 使用 Netty 的堆外的 ByteBuf 对象，在使用完后，并未归还，导致使用的一点一点在泄露。
+
+# 垃圾收集器与内存分配策略
+
+## 什么是垃圾回收机制？
+
+> [《深入拆解 Java 虚拟机》](http://gk.link/a/100kc) 的 [「3.1 概述」](https://svip.iocoder.cn/Java/VirtualMachine/Interview/#) 。
+
+- Java 中对象是采用 `new` 或者反射的方法创建的，这些对象的创建都是在堆(Heap)中分配的，所有对象的回收都是由 Java 虚拟机通过垃圾回收机制完成的。GC 为了能够正确释放对象，会监控每个对象的运行状况，对他们的申请、引用、被引用、赋值等状况进行监控。
+- Java 程序员不用担心内存管理，因为垃圾收集器会自动进行管理。
+- 可以调用下面的方法之一：`System#gc()` 或 `Runtime#getRuntime()#gc()` ，但 JVM 也可以屏蔽掉显示的垃圾回收调用。
+
+🦅 **为什么不建议在程序中显式的声明 `System.gc()` ？**
+
+因为显式声明是做堆内存全扫描，也就是 Full GC ，是需要停止所有的活动的(Stop The World Collection)，对应用很大可能存在影响。
+
+另外，调用 `System.gc()` 方法后，不会立即执行 Full GC ，而是虚拟机自己决定的。
+
+🦅 **如果一个对象的引用被设置为 `null` , GC 会立即释放该对象的内存么?**
+
+不会, 这个对象将会在下一次 GC 循环中被回收。
+
+🦅 **`#finalize()` 方法什么时候被调用？它的目的是什么？**
+
+> [《深入拆解 Java 虚拟机》](http://gk.link/a/100kc) 的 [「3.2.4 生存还是死亡」](https://svip.iocoder.cn/Java/VirtualMachine/Interview/#) 。
+
+`#finallize()` 方法，是在释放该对象内存前由 GC (垃圾回收器)调用。
+
+- 通常建议在这个方法中释放该对象持有的资源，例如持有的堆外内存、和远程服务的长连接。
+- 一般情况下，不建议重写该方法。
+- 对于一个对象，该方法有且仅会被调用一次。
+
+## 如何判断一个对象是否已经死去？
+
+> [《深入拆解 Java 虚拟机》](http://gk.link/a/100kc) 的 [「3.2 对象已死吗」](https://svip.iocoder.cn/Java/VirtualMachine/Interview/#) 。
+
+有两种方式：
+
+1. 引用计数
+2. 可达性分析
+
+**1）引用计数**
+
+每个对象有一个引用计数属性，新增一个引用时计数加 1 ，引用释放时计数减 1 ，计数为 0 时可以回收。此方法简单，无法解决对象相互循环引用的问题。目前在用的有 Python、ActionScript3 等语言。
+
+**2）可达性分析（Reachability Analysis）**
+
+从 GC Roots 开始向下搜索，搜索所走过的路径称为引用链。当一个对象到 GC Roots 没有任何引用链相连时，则证明此对象是不可用的。不可达对象。目前在用的有 Java、C# 等语言。
+
+🦅 **如果 A 和 B 对象循环引用，是否可以被 GC？**
+
+可以，因为 Java 采用可达性分析的判断方式。
+
+🦅 **在 Java 语言里，可作为 GC Roots 的对象包括以下几种？**
+
+1. 虚拟机栈（栈帧中的本地变量表）中引用的对象。
+2. 方法区中的类静态属性引用的对象。
+3. 方法区中常量引用的对象。
+4. 本地方法栈中 JNI(即一般说的 Native 方法)中引用的对象。
+
+🦅 **方法区是否能被回收？**
+
+方法区可以被回收，但是价值很低，主要回收废弃的常量和无用的类。
+
+如何判断无用的类，需要完全满足如下三个条件：
+
+1. 该类所有实例都被回收（Java 堆中没有该类的对象）。
+2. 加载该类的 ClassLoader 已经被回收。
+3. 该类对应的 `java.lang.Class` 对象没有在任何地方被引用，无法在任何地方利用反射访问该类。
+
+## Java 对象有哪些引用类型？
+
+> [《深入拆解 Java 虚拟机》](http://gk.link/a/100kc) 的 [「3.2.3 再谈引用类型」](https://svip.iocoder.cn/Java/VirtualMachine/Interview/#) 。
+
+Java 一共有四种引用类型：
+
+- 强引用
+- 软引用（SoftReference）
+- 弱引用（WeakReference）
+- 虚引用（PhantomReference）
+
+**1）强引用**
+
+以前我们使用的大部分引用实际上都是强引用，这是使用最普遍的引用。如果一个对象具有强引用，那就类似于必不可少的生活用品，垃圾回收器绝不会回收它。当内存空间不足，Java 虚拟机宁愿抛出 OutOfMemoryError 错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足问题。
+
+> 艿艿：不然，代码都没法写了 😈
+
+**2）软引用（SoftReference）**
+
+如果一个对象只具有软引用，那就类似于可有可物的生活用品。如果内存空间足够，垃圾回收器就不会回收它，如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。软引用可用来实现内存敏感的高速缓存。
+
+软引用可以和一个引用队列（ReferenceQueue）联合使用，如果软引用所引用的对象被垃圾回收，JAVA 虚拟机就会把这个软引用加入到与之关联的引用队列中。
+
+使用示例，见 [《精尽 MyBatis 源码分析 —— 缓存模块》](http://svip.iocoder.cn/MyBatis/cache-package/) 的 [「2.10 SoftCache」](https://svip.iocoder.cn/Java/VirtualMachine/Interview/#) 小节。
+
+**3）弱引用（WeakReference）**
+
+如果一个对象只具有弱引用，那就类似于可有可物的生活用品。弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它 所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程， 因此不一定会很快发现那些只具有弱引用的对象。
+
+弱引用可以和一个引用队列（ReferenceQueue）联合使用，如果弱引用所引用的对象被垃圾回收，Java虚拟机就会把这个弱引用加入到与之关联的引用队列中。
+
+使用示例，见
+
+- [《精尽 MyBatis 源码分析 —— 缓存模块》](http://svip.iocoder.cn/MyBatis/cache-package/) 的 [「2.9 WeakCache」](https://svip.iocoder.cn/Java/VirtualMachine/Interview/#) 小节。
+- [《精尽 Netty 源码解析 —— Buffer 之 ByteBuf（三）内存泄露检测》](http://svip.iocoder.cn/Netty/ByteBuf-1-3-ByteBuf-resource-leak-detector/) 的 [「4. ResourceLeakDetector」](https://svip.iocoder.cn/Java/VirtualMachine/Interview/#) 小节。
+
+**4）虚引用（PhantomReference）**
+
+“虚引用”顾名思义，就是形同虚设，与其他几种引用都不同，虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收。
+
+虚引用主要用来跟踪对象被垃圾回收的活动。虚引用与软引用和弱引用的一个区别在于：虚引用必须和引用队列（ReferenceQueue）联合使用。当垃 圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之关联的引用队列中。程序可以通过判断引用队列中是否已经加入了虚引用，来了解被引用的对象是否将要被垃圾回收。程序如果发现某个虚引用已经被加入到引用队列，那么就可以在所引用的对象的内存被回收之前采取必要的行动。
+
+------
+
+如果胖友想看看各种引用在 GC 下的效果，可以看看 [《Java 中的四种引用类型》](http://www.iocoder.cn/Fight/Four-reference-types-in-Java/?vip) 提供的代码示例。
+
+🦅 **WeakReference 与 SoftReference的区别？**
+
+虽然 WeakReference 与 SoftReference 都有利于提高 GC 和 内存的效率。
+
+- 但是 WeakReference 一旦失去最后一个强引用，就会被 GC 回收
+- 而 SoftReference 虽然不能阻止被回收，但是可以延迟到 JVM 内存不足的时候。
+
+🦅 **为什么要有不同的引用类型？**
+
+不像 C 语言，我们可以控制内存的申请和释放，在 Java 中有时候我们需要适当的控制对象被回收的时机，因此就诞生了不同的引用类型，可以说不同的引用类型实则是对 GC 回收时机不可控的妥协。有以下几个使用场景可以充分的说明：
+
+- 利用软引用和弱引用解决 OOM 问题。用一个 HashMap 来保存图片的路径和相应图片对象关联的软引用之间的映射关系，在内存不足时，JVM 会自动回收这些缓存图片对象所占用的空间，从而有效地避免了 OOM 的问题.
+- 通过软引用实现 Java 对象的高速缓存。比如我们创建了一 Person 的类，如果每次需要查询一个人的信息，哪怕是几秒中之前刚刚查询过的，都要重新构建一个实例，这将引起大量 Person 对象的消耗，并且由于这些对象的生命周期相对较短，会引起多次 GC 影响性能。此时，通过软引用和 HashMap 的结合可以构建高速缓存，提供性能。
+
+## JVM 垃圾回收算法？
+
+> [《深入拆解 Java 虚拟机》](http://gk.link/a/100kc) 的 [「3.3 垃圾回收算法」](https://svip.iocoder.cn/Java/VirtualMachine/Interview/#) 。
+
+有四种算法：
+
+1. 标记-清除算法
+2. 标记-整理算法
+3. 复制算法
+4. 分代收集算法
+
+**1）标记-清除算法**
+
+标记-清除（Mark-Sweep）算法，是现代垃圾回收算法的思想基础。
+
+标记-清除算法将垃圾回收分为两个阶段：标记阶段和清除阶段。
+
+一种可行的实现是，在标记阶段，首先通过根节点，标记所有从根节点开始的可达对象。因此，未被标记的对象就是未被引用的垃圾对象（好多资料说标记出要回收的对象，其实明白大概意思就可以了）。然后，在清除阶段，清除所有未被标记的对象。
+
+[![标记-清除算法](29-Java【虚拟机】面试题.assets/f07ac7c68994aa21b7b4271073ea4e5b.jpeg)](http://static.iocoder.cn/f07ac7c68994aa21b7b4271073ea4e5b)标记-清除算法
+
+- 缺点：
+  - 1、效率问题，标记和清除两个过程的效率都不高。
+  - 2、空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大的对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
+
+**2）标记-整理算法**
+
+标记整理算法，类似与标记清除算法，不过它标记完对象后，不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉边界以外的内存。
+
+[![标记-整理算法](29-Java【虚拟机】面试题.assets/52ea9a3813e09621c563b1cd4bdf0d22.jpeg)](http://static.iocoder.cn/52ea9a3813e09621c563b1cd4bdf0d22)标记-整理算法
+
+- 优点：
+  - 1、相对标记清除算法，解决了内存碎片问题。
+  - 2、没有内存碎片后，对象创建内存分配也更快速了（可以使用TLAB进行分配）。
+- 缺点：
+  - 1、效率问题，（同标记清除算法）标记和整理两个过程的效率都不高。
+
+**3）复制算法**
+
+复制算法，可以解决效率问题，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块，当这一块内存用完了，就将还存活着的对象复制到另一块上面，然后再把已经使用过的内存空间一次清理掉，这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可（还可使用TLAB进行高效分配内存）。
+
+[![复制算法](29-Java【虚拟机】面试题.assets/cc3f228ca5353fd5deb4b22b7a9709e6.jpeg)](http://static.iocoder.cn/cc3f228ca5353fd5deb4b22b7a9709e6)复制算法
+
+- 图的上半部分是未回收前的内存区域，图的下半部分是回收后的内存区域。通过图，我们发现不管回收前还是回收后都有一半的空间未被利用。
+- 优点：
+  - 1、效率高，没有内存碎片。
+- 缺点：
+  - 1、浪费一半的内存空间。
+  - 2、复制收集算法在对象存活率较高时就要进行较多的复制操作，效率将会变低。
+
+**4）分代收集算法**
+
+当前商业虚拟机都是采用分代收集算法，它根据对象存活周期的不同将内存划分为几块，一般是把 Java 堆分为新生代和老年代，然后根据各个年代的特点采用最适当的收集算法。
+
+- 在新生代中，每次垃圾收集都发现有大批对象死去，只有少量存活，就选用复制算法。
+- 而老年代中，因为对象存活率高，没有额外空间对它进行分配担保，就必须使用“标记清理”或者“标记整理”算法来进行回收。
+
+[![分代收集算法](29-Java【虚拟机】面试题.assets/fec52af474f1250831d46b541e0fe7a9.jpeg)](http://static.iocoder.cn/fec52af474f1250831d46b541e0fe7a9)分代收集算法
+
+- 图的左半部分是未回收前的内存区域，右半部分是回收后的内存区域。
+- 对象分配策略：
+  - 对象优先在 Eden 区域分配，如果对象过大直接分配到 Old 区域。
+  - 长时间存活的对象进入到 Old 区域。
+- 改进自复制算法
+  - 现在的商业虚拟机都采用这种收集算法来回收新生代，IBM 公司的专门研究表明，新生代中的对象 98% 是“朝生夕死”的，所以并不需要按照 `1:1` 的比例来划分内存空间，而是将内存分为一块较大的 Eden 空间和两块较小的 Survivor 空间，每次使用 Eden 和其中一块 Survivor 。当回收时，将 Eden 和 Survivor 中还存活着的对象一次性地复制到另外一块 Survivor 空间上，最后清理掉 Eden 和刚才用过的 Survivor 空间。
+  - HotSpot 虚拟机默认 Eden 和 2 块 Survivor 的大小比例是 `8:1:1`，也就是每次新生代中可用内存空间为整个新生代容量的 90%（80%+10%），只有 10% 的内存会被“浪费”。当然，98% 的对象可回收只是一般场景下的数据，我们没有办法保证每次回收都只有不多于 10% 的对象存活，当 Survivor 空间不够用时，需要依赖其他内存（这里指老年代）进行分配担保（Handle Promotion）。
+
+## 什么是安全点？
+
+> [《深入拆解 Java 虚拟机》](http://gk.link/a/100kc) 的 [「3.4.2 安全点」](https://svip.iocoder.cn/Java/VirtualMachine/Interview/#) 。
+
+SafePoint 安全点，顾名思义是指一些特定的位置，当线程运行到这些位置时，线程的一些状态可以被确定(the thread’s representation of it’s Java machine state is well described)，比如记录OopMap 的状态，从而确定 GC Root 的信息，使 JVM 可以安全的进行一些操作，比如开始 GC 。
+
+SafePoint 指的特定位置主要有：
+
+1. 循环的末尾 (防止大循环的时候一直不进入 Safepoint ，而其他线程在等待它进入 Safepoint )。
+2. 方法返回前。
+3. 调用方法的 Call 之后。
+4. 抛出异常的位置。
+
+详细的内容，可以看看 [《深入学习 JVM-JVM 安全点和安全区域》](https://my.oschina.net/wenbo123/blog/1822414) 。
+
+- 如何使线程中断
+
+  - 主动式
+
+    > 主动式 JVM 设置一个全局变量，线程去按照某种策略检查这个变量一旦发现是 SafePoint 就主动挂起。
+    >
+    > HostSpot 虚拟机采用的是主动式使线程中断。
+
+  - 被动式
+
+    > 被动式就是发个信号，例如关机、Control+C ，带来的问题就是不可控，发信号的时候不知道线程处于什么状态。
+
+- 安全区域
+
+  > 如果程序长时间不执行，比如线程调用的 sleep 方法，这时候程序无法响应 JVM 中断请求这时候线程无法到达安全点，显然 JVM 也不可能等待程序唤醒，这时候就需要安全区域了。
+  >
+  > 安全区域是指一段代码片中，引用关系不会发生变化，在这个区域任何地方 GC 都是安全的，安全区域可以看做是安全点的一个扩展。
+  >
+  > - 线程执行到安全区域的代码时，首先标识自己进入了安全区域，这样 GC 时就不用管进入安全区域的线程了.
+  > - 线程要离开安全区域时就检查 JVM 是否完成了 GC Roots 枚举（或者整个 GC 过程），如果完成就继续执行，如果没有完成就等待直到收到可以安全离开的信号。
+
+## JVM 垃圾收集器有哪些？
+
+> [《深入拆解 Java 虚拟机》](http://gk.link/a/100kc) 的 [「3.5 垃圾收集器」](https://svip.iocoder.cn/Java/VirtualMachine/Interview/#) 。
+
+如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。
+
+- 新生代收集器
+
+  - Serial 收集器
+
+  - ParNew 收集器
+
+    > ParNew 收集器，是 Serial 收集器的多线程版。
+
+  - Parallel Scavenge 收集器
+
+- 老年代收集器
+
+  - Serial Old 收集器
+    - Serial Old 收集器，是 Serial 收集器的老年代版本。
+  - Parallel Old 收集器
+    - Parallel Old 收集器，是 Parallel Scavenge 收集器的老年代版本。
+  - CMS 收集器
+
+- 新生代 + 老年代收集器
+
+  - G1 收集器
+  - ZGC 收集器
+
+小结表格如下：
+
+| 收集器                | 串行、并行or并发 | 新生代/老年代 | 算法               | 目标         | 适用场景                                  |
+| :-------------------- | :--------------- | :------------ | :----------------- | :----------- | :---------------------------------------- |
+| **Serial**            | 串行             | 新生代        | 复制算法           | 响应速度优先 | 单CPU环境下的Client模式                   |
+| **Serial Old**        | 串行             | 老年代        | 标记-整理          | 响应速度优先 | 单CPU环境下的Client模式、CMS的后备预案    |
+| **ParNew**            | 并行             | 新生代        | 复制算法           | 响应速度优先 | 多CPU环境时在Server模式下与CMS配合        |
+| **Parallel Scavenge** | 并行             | 新生代        | 复制算法           | 吞吐量优先   | 在后台运算而不需要太多交互的任务          |
+| **Parallel Old**      | 并行             | 老年代        | 标记-整理          | 吞吐量优先   | 在后台运算而不需要太多交互的任务          |
+| **CMS**               | 并发             | 老年代        | 标记-清除          | 响应速度优先 | 集中在互联网站或B/S系统服务端上的Java应用 |
+| **G1**                | 并发             | both          | 标记-整理+复制算法 | 响应速度优先 | 面向服务端应用，将来替换CMS               |
+
+关于每种垃圾收集器的说明，请看 如下文章：
+
+- [《深入理解 JVM(3) —— 7 种垃圾收集器》](https://crowhawk.github.io/2017/08/15/jvm_3/)
+- [《一文读懂 Java 11 的 ZGC 为何如此高效》](https://zhuanlan.zhihu.com/p/43608166)
+
+🦅 **G1 和 CMS 的区别？**
+
+- CMS ：并发标记清除。他的主要步骤有：初始收集，并发标记，重新标记，并发清除（删除）、重置。
+
+- G1：主要步骤：初始标记，并发标记，重新标记，复制清除（整理）
+
+- CMS 的缺点是对 CPU 的要求比较高。G1是将内存化成了多块，所有对内段的大小有很大的要求。
+
+- CMS是清除，所以会存在很多的内存碎片。G1是整理，所以碎片空间较小。
+
+- G1 和 CMS 都是响应优先把，他们的目的都是尽量控制 STW 时间。
+
+  > G1 和 CMS 的 Full GC 都是单线程 mark sweep compact 算法，直到 JDK10 才优化为并行的。
+
+感兴趣的胖友，可以看看 [《GC 优化的一些总结》](http://engineering.xueqiu.com/blog/2015/06/25/jvm-gc-tuning/) 的分析。
+
+🦅 **CMS 算法的过程，CMS 回收过程中 JVM 是否需要暂停？**
+
+会有短暂的停顿。详细的，可以看看 [《[jvm\][面试] 并发收集器 CMS(Concurrent Mark-Sweep)》](https://blog.csdn.net/wfh6732/article/details/57490195) 。
+
+🦅 **如何使用指定的垃圾收集器**
+
+| 配置                    | 描述                                     |
+| :---------------------- | :--------------------------------------- |
+| -XX:+UserSerialGC       | 串行垃圾收集器                           |
+| -XX:+UserParrallelGC    | 并行垃圾收集器                           |
+| -XX:+UseConcMarkSweepGC | 并发标记扫描垃圾回收器                   |
+| -XX:ParallelCMSThreads  | 并发标记扫描垃圾回收器 =为使用的线程数量 |
+| -XX:+UseG1GC            | G1垃圾回收器                             |
+
+## 对象分配规则是什么？
+
+> [《深入拆解 Java 虚拟机》](http://gk.link/a/100kc) 的 [「3.6 对象分配与回收策略」](https://svip.iocoder.cn/Java/VirtualMachine/Interview/#) 。
+
+- 对象优先分配在 Eden 区。
+
+  > 如果 Eden 区无法分配，那么尝试把活着的对象放到 Survivor0 中去（Minor GC）
+  >
+  > - 如果 Survivor0 可以放入，那么放入之后清除 Eden 区。
+  > - 如果 Survivor0 不可以放入，那么尝试把 Eden 和 Survivor0 的存活对象放到 Survivor1 中。
+  >   - 如果 Survivor1 可以放入，那么放入 Survivor1 之后清除 Eden 和 Survivor0 ，之后再把 Survivor1 中的对象复制到 Survivor0 中，保持 Survivor1 一直为空。
+  >   - 如果 Survivor1 不可以放入，那么直接把它们放入到老年代中，并清除 Eden 和 Survivor0 ，这个过程也称为**分配担保**。
+  >
+  > ps：清除 Eden、Survivor 区，就是 Minor GC 。
+  >
+  > 总结来说，分配的顺序是：新生代（Eden => Survivor0 => Survivor1）=> 老年代
+
+- 大对象直接进入老年代（大对象是指需要大量连续内存空间的对象）。
+
+  > 这样做的目的是，避免在 Eden 区和两个 Survivor 区之间发生大量的内存拷贝（新生代采用复制算法收集内存）。
+
+- 长期存活的对象进入老年代。
+
+  > 虚拟机为每个对象定义了一个年龄计数器，如果对象经过了 1 次 Minor GC 那么对象会进入 Survivor 区，之后每经过一次 Minor GC 那么对象的年龄加 1 ，知道达到阀值对象进入老年区。
+
+- 动态判断对象的年龄。
+
+  > 为了更好的适用不同程序的内存情况，虚拟机并不是永远要求对象的年龄必须达到 MaxTenuringThreshold 才能晋升老年代。
+  >
+  > 如果 Survivor 区中相同年龄的所有对象大小的总和大于 Survivor 空间的一半，年龄大于或等于该年龄的对象可以直接进入老年代。
+
+- 空间分配担保。
+
+  > 每次进行 Minor GC 时，JVM 会计算 Survivor 区移至老年区的对象的平均大小，如果这个值大于老年区的剩余值大小则进行一次 Full GC ，如果小于检查 HandlePromotionFailure 设置，如果 `true` 则只进行 Monitor GC ，如果 `false` 则进行 Full GC 。
+
+如下是一张对象创建时，分配内存的图：[![内存分配](29-Java【虚拟机】面试题.assets/bc22a30cbe93b8dedda080144a73b613.png)](http://static.iocoder.cn/bc22a30cbe93b8dedda080144a73b613)内存分配
+
+🦅 **为什么新生代内存需要有两个 Survivor 区？**
+
+详细的原因，可以看 [《为什么新生代内存需要有两个 Survivor 区》](https://blog.csdn.net/qq_27093465/article/details/79802884) 文章。
+
+## 什么是新生代 GC 和老年代 GC？
+
+GC 经常发生的区域是堆区，堆区还可以细分为
+
+[![堆](29-Java【虚拟机】面试题.assets/67796f9fc657b7b4dd0054f561248f5b.png)](http://static.iocoder.cn/67796f9fc657b7b4dd0054f561248f5b)堆
+
+- 新生代
+  - 一个 Eden 区
+  - 两个 Survivor 区
+- 老年代
+
+> 默认新生代(Young)与老年代(Old)的比例的值为 `1:2` (该值可以通过参数 `–XX:NewRatio` 来指定)。
+>
+> 默认的 `Eden:from:to=8:1:1` (可以通过参数 `–XX:SurvivorRatio` 来设定)。
+
+**新生代GC（MinorGC/YoungGC）**：指发生在新生代的垃圾收集动作，因为 Java 对象大多都具备朝生夕灭的特性，所以 MinorGC 非常频繁，一般回收速度也比较快。
+
+**老年代GC（MajorGC/FullGC）**：指发生在老年代的 GC，出现了 MajorGC，经常会伴随至少一次的 MinorGC（但非绝对的，在 Parallel Scavenge 收集器的收集策略里就有直接进行 MajorGC 的策略选择过程）。MajorGC 的速度一般会比 MinorGC 慢 10 倍以上。
+
+🦅 **什么情况下会出现 Young GC？**
+
+对象优先在新生代 Eden 区中分配，如果 Eden 区没有足够的空间时，就会触发一次 Young GC 。
+
+🦅 **什么情况下回出现 Full GC？**
+
+Full GC 的触发条件有多个，FULL GC 的时候会 STOP THE WORD 。
+
+- 1、在执行 Young GC 之前，JVM 会进行空间分配担保——如果老年代的连续空间小于新生代对象的总大小（或历次晋升的平均大小），则触发一次 Full GC 。
+- 2、大对象直接进入老年代，从年轻代晋升上来的老对象，尝试在老年代分配内存时，但是老年代内存空间不够。
+- 3、显式调用 `System#gc()` 方法时。
+
+# 虚拟机性能监控与故障处理工具
+
+## JDK 的命令行工具有哪些可以监控虚拟机？
+
+> [《深入拆解 Java 虚拟机》](http://gk.link/a/100kc) 的 [「4.2 JDK 的命令行工具」](https://svip.iocoder.cn/Java/VirtualMachine/Interview/#) 。
+
+- jps ：虚拟机进程状况工具
+
+  > JVM Process Status Tool ，显示指定系统内所有的HotSpot虚拟机进程。
+
+- jstat ：虚拟机统计信息监控工具
+
+  > JVM statistics Monitoring ，是用于监视虚拟机运行时状态信息的命令，它可以显示出虚拟机进程中的类装载、内存、垃圾收集、JIT编译等运行数据。
+
+- jinfo ：Java 配置信息工具
+
+  > JVM Configuration info ，这个命令作用是实时查看和调整虚拟机运行参数。
+
+- jmap ：Java 内存映射工具
+
+  > JVM Memory Map ，命令用于生成 heap dump 文件。
+
+- jhat ：虚拟机堆转储快照分析工具
+
+  > JVM Heap Analysis Tool ，命令是与 jmap 搭配使用，用来分析 jmap 生成的 dump 文件。jhat 内置了一个微型 的HTTP/HTML 服务器，生成 dump 的分析结果后，可以在浏览器中查看。
+
+- jstack ：Java 堆栈跟踪工具
+
+  > Java Stack Trace ，用于生成 Java 虚拟机当前时刻的线程快照。
+
+- HSDIS ：JIT 生成代码反编译
+
+## JDK 的可视化工具有哪些可以监控虚拟机？
+
+> [《深入拆解 Java 虚拟机》](http://gk.link/a/100kc) 的 [「4.3 JDK 的可视化工具」](https://svip.iocoder.cn/Java/VirtualMachine/Interview/#) 。
+
+- Java 自带
+
+  - JConsole ：Java 监视与管理控制台
+
+    > Java Monitoring and Management Console 是从 Java5 开始，在 JDK 中自带的 Java 监控和管理控制台，用于对 JVM 中内存，线程和类等的监控。
+
+  - [VisualVM](https://blog.csdn.net/a19881029/article/details/8432368/) ：多合一故障处理工具
+
+    > JDK 自带全能工具，可以分析内存快照、线程快照、监控内存变化、GC变化等。
+    >
+    > 特别是 BTrace 插件，动态跟踪分析工具。
+
+- 第三方
+
+  - MAT ：内存分析工具
+
+    > Memory Analyzer Tool ，一个基于 Eclipse 的内存分析工具，是一个快速、功能丰富的 Java heap 分析工具，它可以帮助我们查找内存泄漏和减少内存消耗。
+
+  - [GChisto](https://svip.iocoder.cn/Java/VirtualMachine/Interview/GC 日志分析工具 —— GChisto) ：一款专业分析 GC 日志的工具。
+
+另外，一些开源项目，例如 [SkyWalking](https://github.com/apache/incubator-skywalking)、[Cat](https://github.com/dianping/cat) ，也提供了 JVM 监控的功能，更加适合生产环境，对 JVM 的监控。
+
+## 怎么获取 Java 程序使用的内存？
+
+可以通过 `java.lang.Runtime` 类中与内存相关方法来获取剩余的内存，总内存及最大堆内存。通过这些方法你也可以获取到堆使用的百分比及堆内存的剩余空间。
+
+- `Runtime#freeMemory()` 方法，返回剩余空间的字节数。
+- `Runtime#totalMemory()` 方法，总内存的字节数。
+- `Runtime#maxMemory()` 方法，返回最大内存的字节数。
+
+# 调优案例分析与实战
+
+在 [《深入拆解 Java 虚拟机》](http://gk.link/a/100kc) 的 [「第5章 调优案例分析与实战」](https://svip.iocoder.cn/Java/VirtualMachine/Interview/#) 中，已经提供了一些案例，建议胖友可以看看。
+
+## 常见 GC 的优化配置？
+
+| 配置              | 描述                                     |
+| :---------------- | :--------------------------------------- |
+| -Xms              | 初始化堆内存大小                         |
+| -Xmx              | 堆内存最大值                             |
+| -Xmn              | 新生代大小                               |
+| -XX:PermSize      | 初始化永久代大小                         |
+| -XX:MaxPermSize   | 永久代最大容量                           |
+| -XX:SurvivorRatio | 设置年轻代中 Eden 区与 Survivor 区的比值 |
+| -XX:Xmn           | 设置年轻代大小                           |
+
+另外，也可以看看 [《JVM 调优》](https://blog.csdn.net/zhaojw_420/article/details/70527138) 文章。
+
+## 如何排查线程 Full GC 频繁的问题？
+
+- [《线上 Full GC 频繁的排查》](https://blog.csdn.net/wilsonpeng3/article/details/70064336/)
+- [《触发 JVM 进行 Full GC 的情况及应对策略》](https://blog.csdn.net/chenleixing/article/details/46706039/)
+
+🦅 **JVM 的永久代中会发生垃圾回收么？**
+
+- **Young GC** 不会发生在永久代。
+
+- 如果永久代满了或者是超过了临界值，会触发完全垃圾回收(**Full GC**)。如果我们仔细查看垃圾收集器的输出信息，就会发现永久代也是被回收的。这就是为什么正确的永久代大小对避免 Full GC 是非常重要的原因。
+
+  > Java8 ：从永久代到元数据区 (注：Java8 中已经移除了永久代，新加了一个叫做元数据区的 native 内存区)。
+
+## 有看过 GC 日志么？
+
+> 艿艿：这个问题，一般面试不会问，加进来，主要让胖友知道，有这么个知识点。
+
+参见文章如下：
+
+- [《[JVM\]理解GC日志》](https://www.jianshu.com/p/fd1d4f21733a)
+- [《GC 日志查看分析》](https://blog.csdn.net/TimHeath/article/details/53053106)
+
+## TODO JVM 线程案例
+
+TODO 问晓峰
+TODO 问阿牛
+TODO 问狼哥
+TODO 问闪电侠
+TODO 问超哥
+
+# TODO 类文件结构
+
+# TODO 虚拟机类加载机制
+
+> 类加载器，是面试的重点，所以要掌握好。当然，相对来说难度也不算上~
+
+## 类加载器是有了解吗？
+
+> [《深入拆解 Java 虚拟机》](http://gk.link/a/100kc) 的 [「7.4 类加载器」](https://svip.iocoder.cn/Java/VirtualMachine/Interview/#) 。
+
+类加载器(ClassLoader)，用来加载 Java 类到 Java 虚拟机中。一般来说，Java 虚拟机使用 Java 类的方式如下：Java 源程序(`.java` 文件)在经过 Java 编译器编译之后就被转换成 Java 字节代码(`.class` 文件)。
+
+类加载器，负责读取 Java 字节代码，并转换成 `java.lang.Class` 类的一个实例。
+
+- 每个这样的实例用来表示一个 Java 类。通过此实例的 `Class#newInstance(...)` 方法，就可以创建出该类的一个对象。
+- 实际的情况可能更加复杂，比如 Java 字节代码可能是通过工具动态生成的，也可能是通过网络下载的。
+
+## 类加载发生的时机是什么时候？
+
+> [《深入拆解 Java 虚拟机》](http://gk.link/a/100kc) 的 [「7.2 类加载的时机」](https://svip.iocoder.cn/Java/VirtualMachine/Interview/#) 。
+
+虚拟机严格规定，有且仅有 5 种情况必须对类进行加载：
+
+> 注意，有些文章会称为对类进行“初始化”。
+
+- 1、遇到 `new`、`getstatic`、`putstatic`、`invokestatic` 这四条字节码指令时，如果类还没进行初始化，则需要先触发其初始化。
+- 2、使用 `java.lang.reflect` 包的方法对类进行反射调用的时候，如果类还没进行初始化，则需要先触发其初始化。
+- 3、当初始化了一个类的时候，如果发现其父类还没进行初始化，则需要先触发其父类的初始化。
+- 4、当虚拟机启动时，用户需要指定一个执行的主类，即调用其 `#main(String[] args)` 方法，虚拟机则会先初始化该主类。
+- 5、当使用 JDK7 的动态语言支持时，如果一个 `java.lang.invoke.MethodHandle` 实例最后的解析结果为 REF_getStatic、REF_putStatic、REF_invokeStatic 的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化。
+
+## 类加载器是如何加载 Class 文件的？
+
+> [《深入拆解 Java 虚拟机》](http://gk.link/a/100kc) 的 [「7.2 类加载的时机」](https://svip.iocoder.cn/Java/VirtualMachine/Interview/#) 。
+
+下图所示是 ClassLoader 加载一个 `.class` 文件到 JVM 时需要经过的步骤：
+
+[![类加载器是如何加载 class 文件](http://static.iocoder.cn/images/JDK/2020_02_10/08.png)](http://static.iocoder.cn/images/JDK/2020_02_10/08.png)类加载器是如何加载 class 文件
+
+- 第一个阶段，加载(Loading)，是找到 `.class` 文件并把这个文件包含的字节码加载到内存中。
+
+- 第二阶段，连接(Linking)，又可以分为三个步骤，分别是字节码验证、Class 类数据结构分析及相应的内存分配、最后的符号表的解析。
+
+- 第三阶段，Initialization(类中静态属性和初始化赋值)，以及Using(静态块的执行)等。
+
+  > 注意，不包括卸载(Unloading)部分。
+
+🦅 **1）加载**
+
+> 加载是“类加载”过程的第一阶段，胖友不要混淆这两个名字。
+
+在加载阶段，虚拟机需要完成以下三件事情：
+
+- 通过一个类的全限定名来获取其定义的二进制字节流。
+- 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
+- 在Java堆中生成一个代表这个类的 `java.lang.Class` 对象，作为对方法区中这些数据的访问入口。
+
+相对于类加载的其他阶段而言，加载阶段（准确地说，是加载阶段获取类的二进制字节流的动作）是可控性最强的阶段，因为开发人员既可以使用系统提供的类加载器来完成加载，也可以自定义自己的类加载器来完成加载。
+
+加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中，而且在Java堆中也创建一个 `java.lang.Class` 类的对象，这样便可以通过该对象访问方法区中的这些数据。
+
+🦅 **2）加载**
+
+**2.1 验证：确保被加载的类的正确性**
+
+验证是连接阶段的第一步，这一阶段的目的是为了确保 Class 文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。
+
+验证阶段大致会完成4个阶段的检验动作：
+
+- 文件格式验证：验证字节流是否符合 Class 文件格式的规范。例如：是否以 `0xCAFEBABE` 开头、主次版本号是否在当前虚拟机的处理范围之内、常量池中的常量是否有不被支持的类型。
+- 元数据验证：对字节码描述的信息进行语义分析（注意：对比 javac 编译阶段的语义分析），以保证其描述的信息符合 Java 语言规范的要求。例如：这个类是否有父类，除了 `java.lang.Object` 之外。
+- 字节码验证：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。
+- 符号引用验证：确保解析动作能正确执行。
+
+验证阶段是非常重要的，但不是必须的，它对程序运行期没有影响，如果所引用的类经过反复验证，那么可以考虑采用 `-Xverifynone` 参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。
+
+**2.2 准备：为类的静态变量分配内存，并将其初始化为默认值**
+
+准备阶段，是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中分配。对于该阶段有以下几点需要注意：
+
+- 1、这时候进行内存分配的仅包括类变量(`static`)，而不包括实例变量，实例变量会在对象实例化时随着对象一块分配在 Java 堆中。
+
+  > 思考下，对于类本身，静态变量就是其属性。
+
+- 2、这里所设置的初始值通常情况下是数据类型默认的零值(如 `0`、`0L`、`null`、`false` 等），而不是被在 Java 代码中被显式地赋予的值。
+
+  假设一个类变量的定义为： `public static int value = 3`。那么静态变量 `value` 在准备阶段过后的初始值为 `0`，而不是 `3`。因为这时候尚未开始执行任何 Java 方法，而把 `value` 赋值为 `3` 的 `public static` 指令是在程序编译后，存放于**类构造器** `<clinit>()` 方法之中的，所以把 `value` 赋值为 `3` 的动作将在初始化阶段才会执行。
+
+  > 这里还需要注意如下几点：
+  >
+  > - 对基本数据类型来说，对于类变量(`static`)和全局变量，如果不显式地对其赋值而直接使用，则系统会为其赋予默认的零值，而对于局部变量来说，在使用前必须显式地为其赋值，否则编译时不通过。
+  > - 对于同时被 `static` 和 `final` 修饰的常量，必须在声明的时候就为其显式地赋值，否则编译时不通过；而只被 `final` 修饰的常量则既可以在声明时显式地为其赋值，也可以在类初始化时显式地为其赋值，总之，在使用前必须为其显式地赋值，系统不会为其赋予默认零值。
+  > - 对于引用数据类型 reference 来说，如数组引用、对象引用等，如果没有对其进行显式地赋值而直接使用，系统都会为其赋予默认的空值，即 `null` 。
+  > - 如果在数组初始化时没有对数组中的各元素赋值，那么其中的元素将根据对应的数据类型而被赋予默认的“空”值。
+
+- 3、如果类字段的字段属性表中存在 ConstantValue 属性，即同时被 `final` 和 `static` 修饰，那么在准备阶段变量 `value` 就会被初始化为 ConstValue 属性所指定的值。
+
+  假设上面的类变量 `value` 被定义为： `public static final int value = 3` 。编译时， `javac` 将会为 `value` 生成 ConstantValue 属性。在准备阶段虚拟机就会根据 ConstantValue 的设置将 `value` 赋值为 3。我们可以理解为 `static final` 常量在编译期就将其结果放入了调用它的类的常量池中。
+
+**2.3 解析：把类中的符号引用转换为直接引用**
+
+> 这个步骤，艿艿看的也有点懵逼。
+>
+> R 大在 [《JVM 符号引用转换直接引用的过程?》](https://www.zhihu.com/question/50258991) 和 [《JVM 里的符号引用如何存储？》](https://www.zhihu.com/question/30300585) 做过解答，看的还是懵逼。
+
+解析阶段，是虚拟机将常量池内的符号引用替换为直接引用的过程。解析动作，主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符 7 类符号引用进行。
+
+- 符号引用，就是一组符号来描述目标，可以是任何字面量。
+- 直接引用，就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。
+
+🦅 **3）初始化**
+
+初始化，为类的静态变量赋予正确的初始值，JVM 负责对类进行初始化，主要对类变量进行初始化。在 Java 中对类变量进行初始值设定有两种方式：
+
+- 1、声明类变量是指定初始值。
+- 2、使用静态代码块为类变量指定初始值。
+
+JVM 初始化步骤：
+
+- 1、假如这个类还没有被加载和连接，则程序先加载并连接该类。
+- 2、假如该类的直接父类还没有被初始化，则先初始化其直接父类。
+- 3、假如类中有初始化语句，则系统依次执行这些初始化语句。
+
+## 什么是双亲委派模型（Parent Delegation Model）？
+
+> [《深入拆解 Java 虚拟机》](http://gk.link/a/100kc) 的 [「7.4.2 双亲委派模型」](https://svip.iocoder.cn/Java/VirtualMachine/Interview/#) 。
+
+类加载器 ClassLoader 是具有层次结构的，也就是父子关系，如下图所示：
+
+[![双亲委派模型](http://static.iocoder.cn/images/JDK/2020_02_10/09.png)](http://static.iocoder.cn/images/JDK/2020_02_10/09.png)双亲委派模型
+
+- Bootstrap ClassLoader ：根类加载器，负责加载 Java 的核心类，它不是 `java.lang.ClassLoader` 的子类，而是由 JVM 自身实现。
+
+  > 此处，说的是 Hotspot 的情况下。
+
+- Extension ClassLoader ：扩展类加载器，扩展类加载器的加载路径是 JDK 目录下 `jre/lib/ext` 。扩展加载器的 `#getParent()` 方法返回 `null` ，实际上扩展类加载器的父类加载器是根加载器，只是根加载器并不是 Java 实现的。
+
+- System ClassLoader ：系统(应用)类加载器，它负责在 JVM 启动时加载来自 Java 命令的 `-classpath` 选项、`java.class.path` 系统属性或 `CLASSPATH` 环境变量所指定的 jar 包和类路径。程序可以通过 `#getSystemClassLoader()` 来获取系统类加载器。系统加载器的加载路径是程序运行的当前路径。
+
+- 该模型要求除了顶层的 Bootstrap 启动类加载器外，其余的类加载器都应当有自己的父类加载器。子类加载器和父类加载器不是以继承（Inheritance）的关系来实现，而是通过组合（Composition）关系来复用父加载器的代码。简略代码如下：
+
+  ```
+  // java.lang.ClassLoader
+  
+  public abstract class ClassLoader {
+  
+      // ... 省略其它代码
+  
+      // The parent class loader for delegation
+      // Note: VM hardcoded the offset of this field, thus all new fields
+      // must be added *after* it.
+      private final ClassLoader parent;
+  
+  }
+  ```
+
+- 每个类加载器都有自己的命名空间（由该加载器及所有父类加载器所加载的类组成。
+
+  - 在同一个命名空间中，不会出现类的完整名字（包括类的包名）相同的两个类。
+  - 在不同的命名空间中，有可能会出现类的完整名字（包括类的包名）相同的两个类）。
+  - 类加载器负责加载所有的类，同一个类(一个类用其全限定类名(包名加类名)标志)只会被加载一次。
+
+🦅 **Java 虚拟机是如何判定两个 Java 类是相同的？**
+
+Java 虚拟机不仅要看类的全名是否相同，还要看加载此类的类加载器是否一样。**只有两者都相同的情况，才认为两个类是相同的**。即便是同样的字节代码，被不同的类加载器加载之后所得到的类，也是不同的。
+
+比如一个 Java 类 `com.example.Sample` ，编译之后生成了字节代码文件 `Sample.class` 。两个不同的类加载器 ClassLoaderA 和 ClassLoaderB 分别读取了这个 `Sample.class` 文件，并定义出两个 `java.lang.Class` 类的实例来表示这个类。这两个实例是不相同的。对于 Java 虚拟机来说，它们是不同的类。试图对这两个类的对象进行相互赋值，会抛出运行时异常 ClassCastException 。
+
+🦅 **双亲委派模型的工作过程？**
+
+- 1、当前 ClassLoader 首先从自己已经加载的类中，查询是否此类已经加载，如果已经加载则直接返回原来已经加载的类。
+
+  > 每个类加载器都有自己的加载缓存，当一个类被加载了以后就会放入缓存，等下次加载的时候就可以直接返回了。
+
+- 2、当前 ClassLoader 的缓存中没有找到被加载的类的时候
+
+  - 委托父类加载器去加载，父类加载器采用同样的策略，首先查看自己的缓存，然后委托父类的父类去加载，一直到 bootstrap ClassLoader。
+  - 当所有的父类加载器都没有加载的时候，再由当前的类加载器加载，并将其放入它自己的缓存中，以便下次有加载请求的时候直接返回。
+
+让我们来简单撸下源码。代码如下：
+
+> 艿艿：要不要跟面试官吹下，自己看过源码得知~
+
+```
+// java.lang.ClassLoader
+// 删除部分无关代码
+
+protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
+    synchronized (getClassLoadingLock(name)) {
+        // 首先，从缓存中获得 name 对应的类
+        Class<?> c = findLoadedClass(name);
+        if (c == null) { // 获得不到
+            try {
+                // 其次，如果父类非空，使用它去加载类
+                if (parent != null) {
+                    c = parent.loadClass(name, false);
+                // 其次，如果父类为空，使用 Bootstrap 去加载类
+                } else {
+                    c = findBootstrapClassOrNull(name);
+                }
+            } catch (ClassNotFoundException e) {
+            }
+
+            if (c == null) { // 还是加载不到
+                // 最差，使用自己去加载类
+                c = findClass(name);
+            }
+        }
+        // 如果要解析类，则进行解析
+        if (resolve) {
+            resolveClass(c);
+        }
+        return c;
+    }
+}
+```
+
+🦅 **为什么优先使用父 ClassLoader 加载类？**
+
+- 1、共享功能：可以避免重复加载，当父亲已经加载了该类的时候，子类不需要再次加载，一些 Framework 层级的类一旦被顶层的 ClassLoader 加载过就缓存在内存里面，以后任何地方用到都不需要重新加载。
+
+- 2、隔离功能：主要是为了安全性，避免用户自己编写的类动态替换 Java 的一些核心类，比如 String ，同时也避免了重复加载，因为 JVM 中区分不同类，不仅仅是根据类名，相同的 class 文件被不同的 ClassLoader 加载就是不同的两个类，如果相互转型的话会抛 `java.lang.ClassCaseException` 。
+
+  > 这也就是说，即使我们自己定义了一个 `java.util.String` 类，也不会被重复加载。
+
+## 什么是破坏双亲委托模型？
+
+> [《深入拆解 Java 虚拟机》](http://gk.link/a/100kc) 的 [「7.4.3 破坏双亲委派模型」](https://svip.iocoder.cn/Java/VirtualMachine/Interview/#) 。
+
+正如我们上面看到的源码，破坏双亲委托模型，需要做的是，`#loadClass(String name, boolean resolve)` 方法中，不调用父 `parent` ClassLoader 方法去加载类，那么就成功了。那么我们要做的仅仅是，错误的覆盖 `##loadClass(String name, boolean resolve)` 方法，不去使用父 `parent` ClassLoader 方法去加载类即可。
+
+想要深入的胖友，可以深入看看如下文章：
+
+- [《Tomcat 类加载器之为何违背双亲委派模型》](https://blog.csdn.net/dangwanma6489/article/details/80244981)
+- [《真正理解线程上下文类加载器（多案例分析）》](https://blog.csdn.net/yangcheng33/article/details/52631940) 提供了多种打破双亲委托模型的案例。
+- [《深入拆解 Java 虚拟机》](http://gk.link/a/100kc) 的 [「第 9 章 类加载及执行子系统的案例与实战」](https://svip.iocoder.cn/Java/VirtualMachine/Interview/#)
+
+🦅 **如何自定义 ClassLoader 类？**
+
+直接参考 [《Java 自定义 ClassLoader 实现 JVM 类加载》](https://www.jianshu.com/p/3036b46f1188) 文章即可。
+
+🦅 **OSGI 如何实现模块化热部署？**
+
+> 艿艿：了解即可。
+
+OSGI 实现模块化热部署的关键，是它自定义的类加载器机制的实现。每一个程序模块都有一个自己的类加载器，当需要等换一个模块时，就把模块连同类加载器一起换掉以实现代码的热替换。
+
+# TODO 虚拟机字节码执行引擎
+
+# TODO 早期（编译期）优化
+
+## TODO JIT
+
+有时我们会听到 JIT 这个概念，并说它是 JVM 的一部分，这让我们很困惑。JIT 是 JVM 的一部分，它可以在同一时间编译类似的字节码来优化将字节码转换为机器特定语言的过程相似的字节码，从而将优化字节码转换为机器特定语言的过程，这样减少转换过程所需要花费的时间。
+
+# TODO 晚期（运行期）优化
+
+# 666. 彩蛋
+
+总的来说，JVM 主要提问的点，如下脑图：
+
+[![脑图](http://static.iocoder.cn/f20e86724ff310733d7556bd203dc061)](http://static.iocoder.cn/f20e86724ff310733d7556bd203dc061)脑图
+
+参考与推荐如下文章：
+
+- [《Java 面试知识点解析(三)——JVM篇》](https://www.cnblogs.com/wmyskxz/p/9045972.html)
+- [《总结的 JVM 面试题》](https://www.jianshu.com/p/54eb60cfa7bd)
+- [《JAVA 对象创建的过程》](https://troywu0.gitbooks.io/spark/content/java对象创建的过程.html)
+- [《Java 虚拟机详解 —— JVM 常见问题总结》](https://www.cnblogs.com/smyhvae/p/4810168.html)
\ No newline at end of file
diff --git a/面试题/30-Zookeeper 面试题.assets/02.png b/面试题/30-Zookeeper 面试题.assets/02.png
new file mode 100644
index 0000000..b733348
Binary files /dev/null and b/面试题/30-Zookeeper 面试题.assets/02.png differ
diff --git a/面试题/30-Zookeeper 面试题.assets/20cdb662c4f40297b3713148fdfd1c47.jpeg b/面试题/30-Zookeeper 面试题.assets/20cdb662c4f40297b3713148fdfd1c47.jpeg
new file mode 100644
index 0000000..9343b2c
Binary files /dev/null and b/面试题/30-Zookeeper 面试题.assets/20cdb662c4f40297b3713148fdfd1c47.jpeg differ
diff --git a/面试题/30-Zookeeper 面试题.assets/4c9358ff89ffef1089190c6472ebe51c.png b/面试题/30-Zookeeper 面试题.assets/4c9358ff89ffef1089190c6472ebe51c.png
new file mode 100644
index 0000000..cd0ec1e
Binary files /dev/null and b/面试题/30-Zookeeper 面试题.assets/4c9358ff89ffef1089190c6472ebe51c.png differ
diff --git a/面试题/30-Zookeeper 面试题.assets/6591164c09fd2dadef24bd984c9f3a14.png b/面试题/30-Zookeeper 面试题.assets/6591164c09fd2dadef24bd984c9f3a14.png
new file mode 100644
index 0000000..f20b504
Binary files /dev/null and b/面试题/30-Zookeeper 面试题.assets/6591164c09fd2dadef24bd984c9f3a14.png differ
diff --git a/面试题/30-Zookeeper 面试题.md b/面试题/30-Zookeeper 面试题.md
new file mode 100644
index 0000000..aa08ba6
--- /dev/null
+++ b/面试题/30-Zookeeper 面试题.md	
@@ -0,0 +1,540 @@
+# 精尽 Zookeeper 面试题「最新更新时间：2024-02」
+
+以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。
+
+如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的 Zookeeper 面试题的大保健。
+
+而题目的难度，艿艿尽量按照从容易到困难的顺序，逐步下去。
+
+## Zookeeper 是什么？
+
+ZooKeeper 是一个开放源码的分布式协调服务，它是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
+
+分布式应用程序可以基于 Zookeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。
+
+Zookeeper 具有如下特性：
+
+- 顺序一致性(有序性)
+
+  > 从同一个客户端发起的事务请求，最终将会严格地按照其发起顺序被应用到 Zookeeper 中去。
+  >
+  > 有序性是 Zookeeper 中非常重要的一个特性。
+  >
+  > - 所有的更新都是全局有序的，每个更新都有一个唯一的时间戳，这个时间戳称为zxid(Zookeeper Transaction Id)。
+  > - 而读请求只会相对于更新有序，也就是读请求的返回结果中会带有这个 Zookeeper 最新的 zxid 。
+
+- 原子性
+
+  > 所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，即整个集群要么都成功应用了某个事务，要么都没有应用。
+
+- 单一视图
+
+  > 无论客户端连接的是哪个 Zookeeper 服务器，其看到的服务端数据模型都是一致的。
+
+- 可靠性
+
+  > 一旦服务端成功地应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态变更将会一直被保留，除非有另一个事务对其进行了变更。
+
+- 实时性
+
+  > Zookeeper 保证在一定的时间段内，客户端最终一定能够从服务端上读取到最新的数据状态。
+
+Zookeeper 对于读写请求有所不同：
+
+- 客户端的读请求可以被集群中的任意一台机器处理，如果读请求在节点上注册了监听器，这个监听器也是由所连接的 Zookeeper 机器来处理。
+- 对于写请求，这些请求会同时发给其他 Zookeeper 机器并且达成一致后，请求才会返回成功。因此，随着 Zookeeper 的集群机器增多，读请求的吞吐会提高但是写请求的吞吐会下降。
+
+🦅 **Chubby 是什么？和 Zookeeper 对比你怎么看？**
+
+- Chubby 是 Google 的，完全实现 Paxos 算法，不开源。
+- Zookeeper 是 Chubby 的开源实现，使用 ZAB 协议(Paxos 算法的变种)。
+
+🦅 **Zookeeper 的 Java 客户端都有哪些？**
+
+- Zookeeper 自带的 zkclient
+
+- Apache 开源的 Curator
+
+  > 实际项目中，采用 Curator 居多。因为，功能更加强大。
+
+具体的使用，可以看看 [《ZK 客户端操作》](https://www.zybuluo.com/boothsun/note/990793) 文章。
+
+另外，Zookeeper 没有特别好用的 GUI 工具，有需要的胖友，可以看看 [ZooInspector](https://blog.52itstyle.com/archives/343/) ，凑活能用。
+
+## Zookeeper 的设计目标？
+
+- 1、简单的数据结构，Zookeeper 使得分布式程序能够通过一个共享的树形结构的名字空间来进行相互协调，即 Zookeeper 服务器内存中的数据模型由一系列被称为 ZNode 的数据节点组成，Zookeeper 将全量的数据存储在内存中，以此来提高服务器吞吐、减少延迟的目的。
+
+- 2、可以构建集群 Zookeeper 集群通常由一组机器构成，组成 Zookeeper 集群的而每台机器都会在内存中维护当前服务器状态，并且每台机器之间都相互通信。
+
+- 3、顺序访问，对于来自客户端的每个更新请求，Zookeeper 都会分配一个全局唯一的递增编号，这个编号反映了所有事务操作的先后顺序。
+
+- 4、高性能，Zookeeper 和 Redis 一样全量数据存储在内存中，100%读请求压测 QPS 12-13W 。
+
+  > 没具体测试过，比想象中的高。感兴趣的胖友，可以看看 [《ZooKeeper 的一个性能测试》](https://blog.csdn.net/varyall/article/details/81638148) 。
+
+## Zookeeper 有哪些应用场景？
+
+Zookeeper 的功能很强大，应用场景很多，结合我们实际工作中使用 Dubbo 框架的情况，Zookeeper 主要是做注册中心用。
+
+- 基于 Dubbo 框架开发的提供者、消费者都向 Zookeeper 注册自己的 URL ，消费者还能拿到并订阅提供者的注册 URL ，以便在后续程序的执行中去调用提供者。
+- 而提供者发生了变动，也会通过 Zookeeper 向订阅的消费者发送通知。
+
+当然，Zookeeper 能提供的不仅仅如此，再例如：
+
+- 统一命名服务。
+
+  > 命名服务是指通过指定的名字来获取资源或服务的地址，利用zk创建一个全局的路径，即时唯一的路径，这个路径就可以作为一个名字，指向集群中机器或者提供服务的地址，又或者一个远程的对象等。
+
+- 分布式锁服务。
+
+  > 这个比较好理解，Zookeeper 实现的分布式锁的可靠性会比 Redis 实现的分布式锁高，当然相对来说，性能会低。
+
+- 配置管理。
+
+  > 例如说，[Spring Cloud Config Zookeeper](https://blog.csdn.net/CSDN_Stephen/article/details/78856323) ，就实现了基于 Zookeeper 的 Spring Cloud Config 的实现，提供配置中心的服务。
+
+- 注册与发现。
+
+  > 是否有机器加入或退出
+  >
+  > 所有机器约定在父目录下创建临时目录节点，然后监听父目录节点下的子节点变化。一旦有机器挂掉，该机器与 ZooKeeper 的连接断开，其所创建的临时目录节点也被删除，所有其他机器都收到通知：某个节点被删除了。
+
+- Master 选举。
+
+  > 基于 Zookeeper 实现分布式协调，从而实现主从的选举。这个在 Kafka、Elastic-Job 等等中间件，都有所使用到。
+
+- 分布式锁。
+
+  > 有了 ZooKeeper 的一致性文件系统，锁的问题变得容易。锁服务可以分成两类，一个是保持独占，另一个是控制时序。
+  >
+  > - 1、保持独占，我们把 znode 看作是一把锁，通过 createZnode 的方式来实现。所有客户端都去创建 `/distribute_lock` 节点，最终成功创建的那个客户端也即拥有了这把锁。用完删除掉自己创建的 `/distribute_lock` 节点就释放出锁。
+  > - 2、控制时序，`/distribute_lock` 已经预先存在，所有客户端在它下面创建临时顺序编号目录节点，和 Master 一样，编号最小的获得锁，用完删除，依次方便。
+  >
+  > 最近艿艿画了一个 Curator 基于 ZooKeeper 实现分布式锁的流程图，胖友可以点击[传送门](https://www.processon.com/view/link/5f4dc9a91e0853452d463ea5)查看。
+
+- 队列管理
+
+  > 两种类型的队列。
+  >
+  > - 1、同步队列，当一个队列的成员都聚齐时，这个队列才可用，否则一直等待。在约定的目录下创建临时目录节点，监听节点数目是否是我们要求的数目。
+  > - 2、队列按照 FIFO 方式进行入队和出队操作。和分布式锁服务中的控制时序的场景基本原理一致，入列有编号，出列按编号。创建 PERSISTENT_SEQUENTIAL 节点，创建成功时 Watcher 通知等待的队列，队列删除序列号最小的节点以消费。此场景下，znode 用于消息存储，znode 存储的数据就是消息队列中的消息内容，SEQUENTIAL 序列号就是消息的编号，按序取出即可。由于创建的节点是持久化的，所以不必担心队列消息丢失的问题。
+
+当然，详细的可以看看 [《Zookeeper 技术浅析》](http://www.cnblogs.com/sharpxiajun/archive/2013/06/02/3113923.html) 文章。另外，该问对 Zookeeper 的“特点”介绍，也要重点看看。
+
+😈 上述的很多功能，在 Apache Curator 已经默认提供实现了，直接调用 API 即可使用。
+
+🦅 **作为服务注册中心，Eureka 比 Zookeeper 好在哪里？**
+
+参见 [《作为服务注册中心，Eureka 比 Zookeeper 好在哪里》](https://blog.csdn.net/xuyw10000/article/details/79851697) 文章。
+
+比较重要的原因是，注册中心对可用性比一致性有更高的要求，也就是说，能够容忍在异常情况下，读取到几分钟前的数据。
+
+## Zookeeper 提供了什么？
+
+- 1、文件系统。
+- 2、通知机制。
+
+## Zookeeper 的文件系统是什么？
+
+Zookeeper 提供一个多层级的节点命名空间(节点称为 znode)。与文件系统不同的是，这些节点都可以设置关联的数据，而文件系统中只有文件节点可以存放数据而目录节点不行。
+
+Zookeeper 为了保证高吞吐和低延迟，在内存中维护了这个树状的目录结构，这种特性使得 Zookeeper 不能用于存放大量的数据，每个节点的存放数据上限为 1M 。
+
+🦅 **Zookeeper 有哪几种节点类型？**
+
+- PERSISTENT 持久节点
+
+  > 创建之后一直存在，除非有删除操作，创建节点的客户端会话失效也不影响此节点。
+
+- PERSISTENT_SEQUENTIAL 持久顺序节点
+
+  > 跟持久一样，就是父节点在创建下一级子节点的时候，记录每个子节点创建的先后顺序，会给每个子节点名加上一个数字后缀。
+
+- EPHEMERAL 临时节点
+
+  > 创建客户端会话失效（注意是会话失效，不是连接断了），节点也就没了。不能建子节点。
+
+- EPHEMERAL_SEQUENTIAL 临时顺序节点
+
+  > 基本特性同临时节点，增加了顺序属性，节点名后边会追加一个由父节点维护的自增整型数字。
+
+如下是艿艿整理的 Elastic-Job-Lite 使用 Zookeeper 作为存储的明细：[![Elastic-Job-Lite 详细](30-Zookeeper 面试题.assets/02.png)](http://static.iocoder.cn/images/Elastic-Job/2017_10_07/02.png)Elastic-Job-Lite 详细
+
+## Zookeeper 的通知机制是什么？
+
+Zookeeper 允许客户端向服务端的某个 znode 注册一个 Watcher 监听，当服务端的一些指定事件触发了这个 Watcher ，服务端会向指定客户端发送一个事件通知来实现分布式的通知功能，然后客户端根据 Watcher 通知状态和事件类型做出业务上的改变。
+
+整个流程如下：
+
+> 具体的过程，下面每个小问题，进行说明。
+
+- 第一步，客户端注册 Watcher 。
+- 第二步，服务端处理 Watcher 。
+- 第三步，客户端回调 Watcher 。
+
+Watcher 的特性总结：
+
+- 1、一次性。
+
+  > 无论是服务端还是客户端，一旦一个 Watcher 被触发， Zookeeper 都会将其从相应的存储中移除。这样的设计有效的减轻了服务端的压力，不然对于更新非常频繁的节点，服务端会不断的向客户端发送事件通知，无论对于网络还是服务端的压力都非常大。
+  >
+  > 😈 注意哟，这个特性可以变成一个面试题「Zookeeper 对节点的 watch 监听通知是永久的吗？」。
+  >
+  > 如果我们使用 [Apache Curator](https://curator.apache.org/) 作为操作 Zookeeper 的客户端，它可以帮我们自动透明的实现持续的 watch 操作，非常方便。
+
+- 2、客户端串行执行。
+
+  > 客户端 Watcher 回调的过程是一个串行同步的过程。
+
+- 3、轻量级 Watch 机制。
+
+  > - Watcher 通知非常简单，只会告诉客户端发生了事件，而不会说明事件的具体内容。
+  > - 客户端向服务端注册 Watcher 的时候，并不会把客户端真实的 Watcher 对象实体传递到服务端，仅仅是在客户端请求中使用`boolean` 类型属性进行了标记。
+
+- 4、Watcher event 异步发送 Watcher 的通知事件从 Server 发送到Client 是异步的，这就存在一个问题，不同的客户端和服务器之间通过Socket 进行通信，由于网络延迟或其他因素导致客户端在不通的时刻监听到事件，由于 Zookeeper 本身提供了 ordering guarantee ，即客户端监听事件后，才会感知它所监视 znode 发生了变化。所以我们使用 Zookeeper 不能期望能够监控到节点每次的变化。**Zookeeper 只能保证最终的一致性，而无法保证强一致性**。
+
+- 5、可以注册 Watcher 的操作：getData、exists、getChildren 。
+
+- 6、可以触发 Watcher 的操作：create、delete、setData 。
+
+- 7、当一个 Client 连接到一个新的服务器上时，watch 将会被以任意会话事件触发。当与一个服务器失去连接的时候，是无法接收到 watch 的。而当 Client 重新连接时，如果需要的话，所有先前注册过的watch ，都会被重新注册。通常这是完全透明的。只有在一个特殊情况下，watch 可能会丢失：对于一个未创建的 znode 的 exists watch ，如果在客户端断开连接期间被创建了，并且随后在客户端连接上之前又删除了，这种情况下，这个 watch 事件可能会被丢失。
+
+😈 看了这么多特性总结，最最最重要的是【**一次性**】。
+
+> 艿艿：下面三个步骤，选择性了解即可。面试如果问到，就当倒霉。
+
+🦅 **第一步，客户端注册 Watcher 实现？**
+
+- 1、调用 getData、getChildren、exist 三个 API ，传入Watcher 对象。
+- 2、标记请求 request ，封装 Watcher 到 WatchRegistration 。
+- 3、封装成 Packe t对象，发服务端发送 request 。
+- 4、收到服务端响应后，将 Watcher 注册到 ZKWatcherManager 中进行管理。
+- 5、请求返回，完成注册。
+
+🦅 **第二步，服务端处理 Watcher 实现？**
+
+- 1、服务端接收 Watcher 并存储。
+
+  > 接收到客户端请求，处理请求判断是否需要注册 Watcher ，需要的话将数据节点的节点路径和 ServerCnxn(ServerCnxn 代表一个客户端和服务端的连接，实现了 Watcher 的 process 接口，此时可以看成一个 Watcher 对象)存储在 WatcherManager 的 WatchTable 和 Watch2Paths 中去。
+
+- 2、Watcher 触发。
+
+  > 以服务端接收到 setData 事务请求触发 NodeDataChanged 事件为例：
+  >
+  > - 封装 WatchedEvent ：
+  >
+  >   > 将通知状态（SyncConnected）、事件类型（NodeDataChanged）以及节点路径封装成一个WatchedEvent对象
+  >
+  > - 查询 Watcher ：
+  >
+  >   > 从 WatchTable 中根据节点路径查找 Watcher 。
+  >   >
+  >   > - 没找到 ：说明没有客户端在该数据节点上注册过 Watcher 。
+  >   > - 找到 ：提取并从 WatchTable 和 Watch2Paths 中删除对应 Watcher (**从这里可以看出 Watcher 在服务端是一次性的，触发一次就失效了**)。
+
+- 3、调用 process 方法来触发 Watcher 。
+
+  > 这里 process 主要就是通过 ServerCnxn 对应的 TCP 连接发送 Watcher 事件通知。
+
+🦅 **第三步，客户端回调 Watcher 实现？**
+
+客户端 SendThread 线程接收事件通知，交由 EventThread 线程回调Watcher 。
+
+客户端的 Watcher 机制同样是一次性的，一旦被触发后，该 Watcher 就失效了。
+
+## Zookeeper 采用什么权限控制机制？
+
+> 在网上看到一个「你们的 Zookeeper 的节点加密是用的什么方式？」问题，应该也是问这个。
+
+目前，在 Linux/Unix 文件系统中，使用 UGO(User/Group/Others) 权限模型，也是使用最广泛的权限控制方式。是一种粗粒度的文件系统权限控制模式。
+
+> 一般我们管理后台，采用的 RBAC 居多，和 UGO 比较类似，差别在于一般将权限分配给 Role ，而不是直接给 User 。
+
+对于 Zookeeper ，它采用 ACL（Access Control List）访问控制列表。包括三个方面：
+
+- 权限模式（Scheme）
+
+  > - IP ：从 IP 地址粒度进行权限控制
+  > - 【常用】Digest ：最常用，用类似于 `username:password` 的权限标识来进行权限配置，便于区分不同应用来进行权限控制。
+  > - World ：最开放的权限控制方式，是一种特殊的 digest 模式，只有一个权限标识 `“world:anyone”` 。
+  > - Super ：超级用户。
+
+- 授权对象
+
+  > 授权对象指的是权限赋予的用户或一个指定实体，例如 IP 地址或是机器等。
+
+- 权限 Permission
+
+  > - CREATE ：数据节点创建权限，允许授权对象在该 znode 下创建子节点。
+  > - DELETE ：子节点删除权限，允许授权对象删除该数据节点的子节点。
+  > - READ ：数据节点的读取权限，允许授权对象访问该数据节点并读取其数据内容或子节点列表等。
+  > - WRITE ：数据节点更新权限，允许授权对象对该数据节点进行更新操作。
+  > - ADMIN ：数据节点管理权限，允许授权对象对该数据节点进行 ACL 相关设置操作。
+
+🦅 **Chroot 特性是什么？**
+
+Zookeeper 3.2.0 版本后，添加了 Chroot 特性。该特性允许每个客户端为自己设置一个命名空间。如果一个客户端设置了 Chroot ，那么该客户端对服务器的任何操作，都将会被限制在其自己的命名空间下。
+
+通过设置 Chroot ，能够将一个客户端应用于 Zookeeper 服务端的一颗子树相对应，在那些多个应用公用一个 Zookeeper 进群的场景下，对实现不同应用间的相互隔离非常有帮助。
+
+> 艿艿：貌似实际还用的比较少。
+
+## Zookeeper 的会话管理是怎么样的？
+
+ZooKeeper 的每个客户端都维护一组服务端信息，在创建连接时由应用指定，客户端随机选择一个服务端进行连接，连接成功后，服务端为每个连接分配一个唯一标识。
+
+- 客户端在创建连接时可以指定溢出时间，客户端会周期性的向服务端发送 PING 请求来保持连接。
+
+  > 如果客户端异常下线，或者网络问题，导致一段时间没心跳给 Zookeeper 服务端，则会被 Zookeeper 标记为下线。
+
+- 当客户端检测到与服务端断开连接后，客户端将自动选择服务端列表中的另一个服务端进行重连。客户端允许应用修改服务端列表，但修改可能导致客户端与服务端的重连。
+
+详细的，推荐阅读如下两篇文章：
+
+- [《ZooKeeper session 管理》](https://blog.csdn.net/tomato__/article/details/78560727)
+- [《ZooKeeper 技术内幕：会话》](http://ningg.top/zookeeper-lesson-3-session/) 更原理层面。
+
+## Zookeeper 的部署方式？
+
+Zookeeper 有两种部署方式：
+
+- 1、单机
+- 2、集群
+
+> Zookeeper 集群，是一个由多个 Server 组成，一个 Leader，多个 Follower。（这个不同于我们常见的 Master/Slave 模式）Leader 为客户端服务器提供读写服务，除了 Leader 外其他的机器只能提供读服务。
+>
+> 每个 Server 保存一份数据副本全数据一致，分布式读 Follower ，写由 Leader 实施更新请求转发，由 Leader 实施更新请求顺序进行，来自同一个 Client 的更新请求按其发送顺序依次执行数据更新原子性，一次数据更新要么成功，要么失败。
+>
+> 全局唯一数据视图，Client 无论连接到哪个 Server，数据视图都是一致的实时性，在一定事件范围内，Client 能读到最新数据。
+>
+> [![Zookeeper 集群](30-Zookeeper 面试题.assets/20cdb662c4f40297b3713148fdfd1c47.jpeg)](http://static.iocoder.cn/20cdb662c4f40297b3713148fdfd1c47)Zookeeper 集群
+
+一般来说，测试环境部署单机，而生产环境必须必须必须部署集群。
+
+🦅 **集群中的机器角色有哪些？**
+
+集群中一共有三种角色：
+
+- 1、Leader
+
+  > - 事务请求的唯一调度和处理者，保证集群事务处理的顺序性。
+  > - 集群内部各服务的调度者。
+
+- 2、Follower
+
+  > - 处理客户端的非事务请求，转发事务请求给 Leader 服务器。
+  > - 参与事务请求 Proposal 的投票。
+  > - 参与 Leader 选举投票。
+
+- 3、Observer
+
+  > 3.3.0 版本以后引入的一个服务器角色，在不影响集群事务处理能力的基础上提升集群的非事务处理能力。
+  >
+  > - 处理客户端的非事务请求，转发事务请求给 Leader 服务器
+  > - 不参与任何形式的投票。
+  >
+  > 如果 ZooKeeper 集群的读取负载很高，或者客户端多到跨机房，可以设置一些 Observer 服务器，以提高读取的吞吐量。Observer 和 Follower 比较相似，只有一些小区别：
+  >
+  > - 首先 Observer 不属于法定人数，即不参加选举也不响应提议，也不参与写操作的“过半写成功”策略；
+  > - 其次是 Observer 不需要将事务持久化到磁盘，一旦 Observer 被重启，需要从 Leader 重新同步整个名字空间。
+
+在一个集群中，最少需要 3 台。或者保证 2N + 1 台，即奇数。为什么保证奇数？主要是为了选举算法。
+
+🦅 **集群如果有 3 台机器，挂掉 1 台集群还能工作吗？挂掉 2 台呢？**
+
+记住一个原则：过半存活即可用。所以挂掉 1 台可以继续工作，挂掉 2 台不可以工作。
+
+🦅 **集群支持动态添加机器吗？**
+
+在 3.5 版本开始，支持动态扩容。
+
+而在 3.5 版本之前，Zookeeper 在这方面不太好。所以需要如下两种方式：
+
+- 全部重启：关闭所有 Zookeeper 服务，修改配置之后启动。不影响之前客户端的会话。
+- 逐个重启：顾名思义。这是比较常用的方式。
+
+🦅 **Zookeeper 下 Server 工作状态？**
+
+服务器具有四种状态，分别是：
+
+- LOOKING 寻找 Leader 状态
+
+  > 当服务器处于该状态时，它会认为当前集群中没有 Leader ，因此需要进入 Leader 选举状态。
+
+- FOLLOWING 跟随者状态
+
+  > 表明当前服务器角色是 Follower 。
+
+- LEADING 领导者状态
+
+  > 表明当前服务器角色是 Leader 。
+
+- OBSERVING 观察者状态
+
+  > 表明当前服务器角色是 Observer 。
+
+## ZooKeeper 的工作原理？
+
+ZooKeeper 的核心是原子广播，这个机制保证了各个 Server 之间的同步。实现这个机制的协议叫做 **Zab** 协议。Zab 协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）：
+
+- 选主：当服务启动或者 Leader 崩溃后，Zab 就进入了恢复模式，当新的 Leader 被选举出来，且大多数 Server 完成了和 Leader 的状态同步以后，恢复模式就结束了。
+
+  > 更加详细的描述。
+  >
+  > 当整个 Zookeeper 集群刚刚启动，或者 Leader 服务器宕机、重启或者网络故障导致不存在过半的服务器与 Leader服务器保持正常通信时，所有进程（服务器）进入崩溃恢复模式。
+  >
+  > - 首先，选举产生新的Leader服务器。
+  > - 然后，集群中 Follower 服务器开始与新的 Leader 服务器进行数据同步。
+  > - 当集群中超过半数机器与该Leader服务器完成数据同步之后，退出恢复模式进入消息广播模式，
+
+- 同步：状态同步保证了 Leader 和 Server 具有相同的系统状态。
+
+  > 更加详细的描述。
+  >
+  > Leader 服务器开始接收客户端的事务请求，生成事务提案来进行事务请求处理。
+
+🦅 **ZooKeeper 是如何保证事务的顺序一致性的？**
+
+ZooKeeper 采用了递增的事务 id 来识别，所有的 proposal（提议）都在被提出的时候加上了 zxid 。zxid 实际上是一个 64 位数字。
+
+- 高 32 位是 epoch 用来标识 Leader 是否发生了改变，如果有新的 Leader 产生出来，epoch会自增。
+- 低 32 位用来递增计数。
+
+当新产生的 peoposal 的时候，会依据数据库的两阶段过程，首先会向其他的 Server 发出事务执行请求，如果超过半数的机器都能执行并且能够成功，那么就会开始执行。
+
+🦅 **ZooKeeper 集群中个服务器之间是怎样通信的？**
+
+Leader 服务器会和每一个 Follower/Observer 服务器都建立 TCP 连接，同时为每个 Follower/Observer 都创建一个叫做 LearnerHandler 的实体。
+
+- LearnerHandler 主要负责 Leader 和 Follower/Observer 之间的网络通讯，包括数据同步，请求转发和 Proposal 提议的投票等。
+- Leader 服务器保存了所有 Follower/Observer 的 LearnerHandler 。
+
+🦅 **ZAB 和 Paxos 算法的联系与区别？**
+
+Paxos 算法是分布式选举算法，Zookeeper 使用的 ZAB 协议（Zookeeper 原子广播）。
+
+二者有相同的地方：
+
+- 都有一个 Leader，用来协调 N 个 Follower 的运行
+- Leader 要等待超半数的 Follower做 出正确反馈之后才进行提案。
+- 二者都有一个值来代表 Leader 的周期。ZAB 协议中，每个 Proposal 中都包含一个 epoch 值来代表当前的Leader周期，Paxos中名字为 Ballot 。
+
+不同的地方在于：
+
+- ZAB 用来构建高可用的分布式数据主备系统（Zookeeper），Paxos 是用来构建分布式一致性状态机系统。
+
+Paxos 算法、ZAB 协议要想讲清楚可不是一时半会的事儿，自 1990 年莱斯利·兰伯特提出 Paxos 算法以来，因为晦涩难懂并没有受到重视。后续几年，兰伯特通过好几篇论文对其进行更进一步地解释，也直到 06 年谷歌发表了三篇论文，选择 Paxos 作为 Chubby cell 的一致性算法，Paxo s才真正流行起来。
+
+对于普通开发者来说，尤其是学习使用 Zookeeper 的开发者明确一点就好：分布式 Zookeeper 选举 Leader 服务器的算法，与 Paxos 有很深的关系。
+
+## Zookeeper 的选举过程？
+
+当 Leader 崩溃，或者 Leader 失去大多数的 Follower，这时 Zookeeper 进入恢复模式，恢复模式需要重新选举出一个新的 Leader，让所有的 Server 都恢复到一个正确的状态。
+
+Zookeeper 的选举算法有两种：一种是基于 basic paxos 实现的，另外一种是基于 fast paxos 算法实现的。系统默认的选举算法为 fast paxos 。
+
+> 相对详细的，胖友可以看看 [《【分布式】Zookeeper的Leader选举》](http://www.cnblogs.com/leesf456/p/6107600.html) 和 [《Zookeeper 源码分析 —— Zookeeper Leader 选举算法》](https://juejin.im/post/5b949d595188255c6a041c22) 。
+>
+> - 不同阶段的选举流程
+>   - 服务器启动时期的 Leader 选举。
+>   - 服务器运行时期的 Leader 选举。
+> - 三种选举算法
+>   - LeaderElection ：使用 basic paxos 算法。
+>   - FastLeaderElection ：使用 fast paxos 算法。
+>   - AuthFastLeaderElection ：在 FastLeaderElection 的基础上，增加认证。
+>   - 最终在 Zookeeper 3.4.0 版本之后，只保留 FastLeaderElection 版本。
+
+😈 看下面的原理描述，还是有点懵逼。等后面艿艿自己去撸下源码，可能会清晰一些。
+
+🦅 **Zookeeper 选主流程(basic paxos)？**
+
+> 选择性了解。
+
+- 1、选举线程由当前 Server 发起选举的线程担任，其主要功能是对投票结果进行统计，并选出推荐的 Server 。
+- 2、选举线程首先向所有 Server 发起一次询问(包括自己)。
+- 3、选举线程收到回复后，验证是否是自己发起的询问(验证 zxid 是否一致)，然后获取对方的 id(myid)，并存储到当前询问对象列表中，最后获取对方提议的 Leader相关信息(id，zxid)，并将这些信息存储到当次选举的投票记录表中。
+- 4、收到所有 Server 回复以后，就计算出 zxid 最大的那个 Server ，并将这个 Server 相关信息设置成下一次要投票的 Server 。
+- 5、线程将当前 zxid 最大的 Server 设置为当前 Server 要推荐的 Leader ，如果此时获胜的 Server 获得 `n/2+1` 的 Server 票数，设置当前推荐的 Leader 为获胜的 Server ，将根据获胜的 Server 相关信息设置自己的状态，否则，继续这个过程，直到 Leader 被选举出来。
+
+通过流程分析我们可以得出：要使 Leader 获得多数 Server 的支持，则 Server 总数必须是奇数 `2n+1` ，且存活的 Server 的数目不得少于`n+1` 。每个 Server 启动后都会重复以上流程。
+
+在恢复模式下，如果是刚从崩溃状态恢复的或者刚启动的 Server 还会从磁盘快照中恢复数据和会话信息，Zookeeper 会记录事务日志并定期进行快照，方便在恢复时进行状态恢复。
+
+[![流程](http://static.iocoder.cn/4c9358ff89ffef1089190c6472ebe51c)](http://static.iocoder.cn/4c9358ff89ffef1089190c6472ebe51c)流程
+
+🦅 **Zookeeper 选主流程(fast paxos)？**
+
+> 重点了解。这块在 [《Zookeeper 源码分析 —— Zookeeper Leader 选举算法》](https://juejin.im/post/5b949d595188255c6a041c22) 写的比较详细。
+
+由于 LeaderElection 收敛速度较慢，所以 Zookeeper 引入了 FastLeaderElection 选举算法，FastLeaderElection 也成了Zookeeper默认的Leader选举算法。
+
+FastLeaderElection 是标准的 Fast Paxos 的实现。它首先向所有 Server 提议自己要成为 Leader ，当其它 Server 收到提议以后，解决 epoch 和 zxid 的冲突，并接受对方的提议，然后向对方发送接受提议完成的消息。重复这个流程，最后一定能选举出Leader。
+
+FastLeaderElection 算法通过异步的通信方式来收集其它节点的选票，同时在分析选票时又根据投票者的当前状态来作不同的处理，以加快 Leader 的选举进程。
+
+[![流程](http://static.iocoder.cn/6591164c09fd2dadef24bd984c9f3a14)](http://static.iocoder.cn/6591164c09fd2dadef24bd984c9f3a14)流程
+
+🦅 **为什么 Zookeeper 集群推荐节点数是单数？**
+
+在统计投票时，有个过半的概念，大于集群机器数量的一半，即大于或等于(`n/2+1`)。那么我们来看看如下的统计：
+
+| 集群数量 | 至少正常运行数量                 | 允许挂掉的数量 |
+| :------- | :------------------------------- | :------------- |
+| 2        | 2 的半数为 1，半数以上最少为 2   | 0              |
+| 3        | 3 的半数为 1.5，半数以上最少为 2 | 1              |
+| 4        | 4 的半数为 2，半数以上最少为 3   | 1              |
+| 5        | 5 的半数为 2.5，半数以上最少为 3 | 2              |
+| 6        | 6 的半数为 3，半数以上最少为 4   | 2              |
+
+通过以上可以发现：
+
+- 3 台服务器和 4 台服务器都最多允许 1 台服务器挂掉，5 台服务器和 6 台服务器都最多允许 2 台服务器挂掉，明显 4 台服务器成本高于 3 台服务器成本，6 台服务器成本高于 5 服务器成本。
+- 这是由于半数以上投票通过决定的。所以，Zookeeper 集群推荐节点数是单数。
+
+简单的来说，**节省资源**！
+
+另外，因为 Zookeeper 使用一致性协议，过多的节点，反倒会降低性能。😈
+
+🦅 **Zookeeper 是否需存在脑裂？**
+
+按道理说，Zookeeper 选举不会存在脑裂问题，因为需要 `n / 2 + 1` 投票通过，才能执行对应的写操作。但是听朋友说，实际场景下，貌似发生过脑裂问题。关于这块，艿艿心里也不太有底，欢迎在星球一起讨论。
+
+- [《Zookeeper 已经分布式环境中的假死脑裂》](https://blog.csdn.net/u010185262/article/details/49910301)
+
+  > 认为存在脑裂问题，以及提供怎么解决。
+
+- [《zookeeper（二）常见问题汇总》](https://blog.csdn.net/yjp198713/article/details/79400927)
+
+  > 认为不会存在脑裂问题。
+
+🦅 **机器中为什么会有 Leader？**
+
+在分布式环境中，有些业务逻辑只需要集群中的某一台机器进行执行，其他的机器可以共享这个结果，这样可以大大减少重复计算，提高性能，于是就需要进行 Leader 选举。
+
+## Zookeeper 的同步流程？
+
+选完 Leader 以后，Zookeeper 就进入状态同步过程。
+
+- 1、Leader 等待 Server 连接。
+- 2、Follower 连接 Leader ，将最大的 zxid 发送给 Leader 。
+- 3、Leader 根据 Follower 的 zxid 确定同步点。
+- 4、完成同步后通知 Follower 已经成为 update 状态。
+- 5、Follower 收到 update 消息后，又可以重新接受 Client 的请求进行服务了。
+
+当然，同步流程并不是像上述描述的这么简单，具体的，还是得看看 [《Zookeeper Leader 和 Learner 的数据同步》](https://blog.csdn.net/weixin_36145588/article/details/75043611) 。
+
+## 666. 彩蛋
+
+估计大多数胖友，学习 Zookeeper 的过程，是因为使用 Dubbo 时，需要使用到 Zookeeper 作为注册中心，然后快速搭建了下。然后，断断续续看了下 Zookeeper 的文章。🙂 就当是复习。面对的时候，比较重点的几个问题是：
+
+- Zookeeper 的选举过程？
+- Zookeeper 如何提供分布式锁？
+- Zookeeper 的一些应用场景？
+
+参考与推荐如下文章：
+
+- [《ZooKeeper 学习总结（3）—— ZooKeeper 常见面试题》](https://blog.csdn.net/u012562943/article/details/76128183)
+- [《Zookeeper 常见面试题》](https://blog.csdn.net/u013676711/article/details/53842438)
+- [《Zookeeper 面试题》](https://www.cnblogs.com/lanqiu5ge/p/9405601.html)
+- [《如果有人问你 ZooKeeper 是什么，就把这篇文章发给他》](https://juejin.im/post/5baf7db75188255c3d11622e)
\ No newline at end of file
diff --git a/面试题/31-Nginx 面试题.assets/7bdf14ce3d607e5765e37750cc49d65f.jpeg b/面试题/31-Nginx 面试题.assets/7bdf14ce3d607e5765e37750cc49d65f.jpeg
new file mode 100644
index 0000000..9ed12fb
Binary files /dev/null and b/面试题/31-Nginx 面试题.assets/7bdf14ce3d607e5765e37750cc49d65f.jpeg differ
diff --git a/面试题/31-Nginx 面试题.md b/面试题/31-Nginx 面试题.md
new file mode 100644
index 0000000..565e5f5
--- /dev/null
+++ b/面试题/31-Nginx 面试题.md	
@@ -0,0 +1,308 @@
+# 精尽 Nginx 面试题「最新更新时间：2024-02」
+
+以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。
+
+如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的 Nginx 面试题的大保健。
+
+而题目的难度，艿艿尽量按照从容易到困难的顺序，逐步下去。
+
+## 请解释一下什么是 Nginx ？
+
+Nginx ，是一个 Web 服务器和反向代理服务器，用于 HTTP、HTTPS、SMTP、POP3 和 IMAP 协议。
+
+目前使用的最多的 Web 服务器或者代理服务器，像淘宝、新浪、网易、迅雷等都在使用。
+
+Nginx 的主要功能如下：
+
+- 作为 http server (代替 Apache ，对 PHP 需要 FastCGI 处理器支持)
+
+  > FastCGI：Nginx 本身不支持 PHP 等语言，但是它可以通过 FastCGI 来将请求扔给某些语言或框架处理。
+
+- 反向代理服务器
+
+- 实现负载均衡
+
+- 虚拟主机
+
+🦅 **fastcgi 与 cgi 的区别？**
+
+1）cgi
+
+> web 服务器会根据请求的内容，然后会 fork 一个新进程来运行外部 c 程序（或 perl 脚本…）， 这个进程会把处理完的数据返回给 web 服务器，最后 web 服务器把内容发送给用户，刚才 fork 的进程也随之退出。
+>
+> 如果下次用户还请求改动态脚本，那么 web 服务器又再次 fork 一个新进程，周而复始的进行。
+
+2）fastcgi
+
+> web 服务器收到一个请求时，他不会重新 fork 一个进程（因为这个进程在 web 服务器启动时就开启了，而且不会退出），web 服务器直接把内容传递给这个进程（进程间通信，但 fastcgi 使用了别的方式，tcp 方式通信），这个进程收到请求后进行处理，把结果返回给 web 服务器，最后自己接着等待下一个请求的到来，而不是退出。
+
+🚀 综上，差别在于是否重复 fork 进程，处理请求。
+
+关于 Nginx 和 fastcgi 是如何运行的，可以看看 [《Nginx + FastCGI运行原理》](https://www.linuxba.com/archives/7682) 。
+
+同样，关于 cgi 可能也会存在 [《php 面试题五之 nginx 如何调用 php 和 php-fpm 的作用和工作原理》](https://phperzh.com/articles/7297) 问题。
+
+## Nginx 常用命令？
+
+- 启动 `nginx` 。
+- 停止 `nginx -s stop` 或 `nginx -s quit` 。
+- 重载配置 `./sbin/nginx -s reload(平滑重启)` 或 `service nginx reload` 。
+- 重载指定配置文件 `.nginx -c /usr/local/nginx/conf/nginx.conf` 。
+- 查看 nginx 版本 `nginx -v` 。
+- 检查配置文件是否正确 `nginx -t` 。
+- 显示帮助信息 `nginx -h` 。
+
+## Nginx 常用配置？
+
+```
+worker_processes  8; # 工作进程个数
+worker_connections  65535; # 每个工作进程能并发处理（发起）的最大连接数（包含所有连接数）
+error_log         /data/logs/nginx/error.log; # 错误日志打印地址
+access_log      /data/logs/nginx/access.log; # 进入日志打印地址
+log_format  main  '$remote_addr"$request" ''$status $upstream_addr "$request_time"'; # 进入日志格式
+
+## 如果未使用 fastcgi 功能的，可以无视
+fastcgi_connect_timeout=300; # 连接到后端 fastcgi 超时时间
+fastcgi_send_timeout=300; # 向 fastcgi 请求超时时间(这个指定值已经完成两次握手后向fastcgi传送请求的超时时间)
+fastcgi_rend_timeout=300; # 接收 fastcgi 应答超时时间，同理也是2次握手后
+fastcgi_buffer_size=64k; # 读取 fastcgi 应答第一部分需要多大缓冲区，该值表示使用1个64kb的缓冲区读取应答第一部分(应答头),可以设置为fastcgi_buffers选项缓冲区大小
+fastcgi_buffers 4 64k; # 指定本地需要多少和多大的缓冲区来缓冲fastcgi应答请求，假设一个php或java脚本所产生页面大小为256kb,那么会为其分配4个64kb的缓冲来缓存
+fastcgi_cache TEST; # 开启fastcgi缓存并为其指定为TEST名称，降低cpu负载,防止502错误发生
+
+listen       80; # 监听端口
+server_name  rrc.test.jiedaibao.com; # 允许域名
+root  /data/release/rrc/web; # 项目根目录
+index  index.php index.html index.htm; # 访问根文件
+```
+
+🦅 **Nginx 日志格式中的 `$time_local` 表示的是什么时间？请求开始的时间？请求结束的时间？其次，当我们从前到后观察日志中的 `$time_local` 时间时，有时候会发现时间顺序前后错乱的现象，请说明原因？**
+
+`$time_local` ：在服务器里请求开始写入本地的时间。
+
+因为请求发生时间有前有后，所以会时间顺序前后错乱。
+
+## Nginx 有哪些优点？
+
+- 跨平台、配置简单。
+
+- 非阻塞、高并发连接
+
+  > 处理 2-3 万并发连接数，官方监测能支持 5 万并发。
+
+- 内存消耗小
+
+  > 开启 10 个 Nginx 才占 150M 内存。
+
+- 成本低廉，且开源。
+
+- 稳定性高，宕机的概率非常小。
+
+## 使用“反向代理服务器”的优点是什么？
+
+反向代理服务器可以隐藏源服务器的存在和特征。它充当互联网云和 Web 服务器之间的中间层。这对于安全方面来说是很好的，特别是当我们使用 Web 托管服务时。
+
+> 这里，先不考虑负载均衡。
+
+🦅 **什么是正向代理？**
+
+一个位于客户端和原始服务器(origin server)之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端。
+
+- 客户端才能使用正向代理。
+- 正向代理总结就一句话：代理端代理的是客户端。例如说：😈 我们使用的翻墙软件，OpenVPN 等等。
+
+🦅 **什么是反向代理？**
+
+反向代理（Reverse Proxy）方式，是指以代理服务器来接受 Internet上的连接请求，然后将请求，发给内部网络上的服务器并将从服务器上得到的结果返回给 Internet 上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。
+
+反向代理总结就一句话：代理端代理的是服务端。
+
+🦅 **请列举 Nginx 和 Apache 之间的不同点？**
+
+[![对比图](31-Nginx 面试题.assets/7bdf14ce3d607e5765e37750cc49d65f.jpeg)](http://static.iocoder.cn/7bdf14ce3d607e5765e37750cc49d65f)对比图
+
+- 轻量级，同样起 web 服务，Nginx 比 Apache 占用更少的内存及资源。
+- 抗并发，Nginx 处理请求是异步非阻塞的，而 Apache 则是阻塞型的，在高并发下 Nginx 能保持低资源低消耗高性能。
+- 最核心的区别在于 Apache 是同步多进程模型，一个连接对应一个进程；Nginx 是异步的，多个连接（万级别）可以对应一个进程。
+- Nginx 高度模块化的设计，编写模块相对简单。
+
+🦅 **LVS、Nginx、HAproxy 有什么区别？**
+
+- LVS ：是基于四层的转发。
+
+- HAproxy ： 是基于四层和七层的转发，是专业的代理服务器。
+
+- Nginx ：是 WEB 服务器，缓存服务器，又是反向代理服务器，可以做七层的转发。
+
+  > Nginx 引入 [TCP 插件](https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/)之后，也可以支持四层的转发。
+
+🚀 区别
+
+LVS 由于是基于四层的转发所以只能做端口的转发，而基于 URL 的、基于目录的这种转发 LVS 就做不了。
+
+🚀 工作选择：
+
+HAproxy 和 Nginx 由于可以做七层的转发，所以 URL 和目录的转发都可以做，在很大并发量的时候我们就要选择 LVS ，像中小型公司的话并发量没那么大选择 HAproxy 或者 Nginx 足已。
+
+由于 HAproxy 由是专业的代理服务器配置简单，所以中小型企业推荐使用HAproxy 。
+
+> 有些使用，使用 HAproxy 还是 Nginx ，也和公司运维对哪个技术栈的掌控程度。掌控 OK ，选择 Nginx 会更加不错。
+>
+> 另外，LVS + Nginx 和 LVS + HAProxy 也是比较常见的选型组合。
+
+更多更详细的对比，感兴趣的胖友，可以看看 [《LVS、HAProxy、Nginx 负载均衡的比较分析》](https://blog.csdn.net/gzh0222/article/details/8540604) 。
+
+🦅 **Squid、Varinsh、Nginx 有什么区别？**
+
+三者都实现缓存服务器的作用。所以，本问题所有的视角，都是在作为缓存服务器下来聊。
+
+- 1、Nginx本来是反向代理/web服务器，用了插件可以做做这个副业(缓存服务器)。
+
+  > 但是本身不支持特性挺多，只能缓存静态文件。
+
+- 2、从这些功能上，Varinsh 和 Squid 是专业的 Cache 服务，而Nginx 这些是第三方模块完成。
+
+- 3、Varnish 本身的技术上优势要高于 Squid ，它采用了可视化页面缓存技术。
+
+  > - 在内存的利用上，Varnis h比 Squid 具有优势，性能要比 Squid 高。
+  > - 还有强大的通过 Varnish 管理端口，可以使用正则表达式快速、批量地清除部分缓存
+  > - Varnish 是内存缓存，速度一流，但是内存缓存也限制了其容量，缓存页面和图片一般是挺好的。
+
+- 4、Squid 的优势在于完整的庞大的 cache 技术资料，和很多的应用生产环境。
+
+🚀 工作选择：
+
+要做 cache 服务的话，我们肯定是要选择专业的 cache 服务，优先选择Squid 或者 Varnish 。
+
+## 请解释 Nginx 如何处理 HTTP 请求？
+
+- 首先，Nginx 在启动时，会解析配置文件，得到需要监听的端口与 IP 地址，然后在 Nginx 的 Master 进程里面先初始化好这个监控的Socket(创建 S ocket，设置 addr、reuse 等选项，绑定到指定的 ip 地址端口，再 listen 监听)。
+
+- 然后，再 fork(一个现有进程可以调用 fork 函数创建一个新进程。由 fork 创建的新进程被称为子进程 )出多个子进程出来。
+
+- 之后，子进程会竞争 accept 新的连接。此时，客户端就可以向 nginx 发起连接了。当客户端与nginx进行三次握手，与 nginx 建立好一个连接后。此时，某一个子进程会 accept 成功，得到这个建立好的连接的 Socket ，然后创建 nginx 对连接的封装，即 ngx_connection_t 结构体。
+
+- 接着，设置读写事件处理函数，并添加读写事件来与客户端进行数据的交换。
+
+  > 这里，还是有一些逻辑，继续在 [「Nginx 是如何实现高并发的？」](https://svip.iocoder.cn/Nginx/Interview/#) 问题中来看。
+
+- 最后，Nginx 或客户端来主动关掉连接，到此，一个连接就寿终正寝了。
+
+🦅 **Nginx 是如何实现高并发的？**
+
+如果一个 server 采用一个进程(或者线程)负责一个request的方式，那么进程数就是并发数。那么显而易见的，就是会有很多进程在等待中。等什么？最多的应该是等待网络传输。其缺点胖友应该也感觉到了，此处不述。
+
+> 思考下，Java 的 NIO 和 BIO 的对比哟。
+
+而 Nginx 的异步非阻塞工作方式正是利用了这点等待的时间。在需要等待的时候，这些进程就空闲出来待命了。因此表现为少数几个进程就解决了大量的并发问题。
+
+Nginx是如何利用的呢，简单来说：同样的 4 个进程，如果采用一个进程负责一个 request 的方式，那么，同时进来 4 个 request 之后，每个进程就负责其中一个，直至会话关闭。期间，如果有第 5 个request进来了。就无法及时反应了，因为 4 个进程都没干完活呢，因此，一般有个调度进程，每当新进来了一个 request ，就新开个进程来处理。
+
+> 回想下，BIO 是不是存在酱紫的问题？嘻嘻。
+
+Nginx 不这样，每进来一个 request ，会有一个 worker 进程去处理。但不是全程的处理，处理到什么程度呢？处理到可能发生阻塞的地方，比如向上游（后端）服务器转发 request ，并等待请求返回。那么，这个处理的 worker 不会这么傻等着，他会在发送完请求后，注册一个事件：“如果 upstream 返回了，告诉我一声，我再接着干”。于是他就休息去了。此时，如果再有 request 进来，他就可以很快再按这种方式处理。而一旦上游服务器返回了，就会触发这个事件，worker 才会来接手，这个 request 才会接着往下走。
+
+> 这就是为什么说，Nginx 基于事件模型。
+
+由于 web server 的工作性质决定了每个 request 的大部份生命都是在网络传输中，实际上花费在 server 机器上的时间片不多。这是几个进程就解决高并发的秘密所在。即：
+
+> webserver 刚好属于网络 IO 密集型应用，不算是计算密集型。
+
+而正如叔度所说的
+
+> 异步，非阻塞，使用 epoll ，和大量细节处的优化。
+
+也正是 Nginx 之所以然的技术基石。
+
+🦅 **为什么 Nginx 不使用多线程？**
+
+Apache: 创建多个进程或线程，而每个进程或线程都会为其分配 cpu 和内存（线程要比进程小的多，所以 worker 支持比 perfork 高的并发），并发过大会榨干服务器资源。
+
+Nginx: 采用单线程来异步非阻塞处理请求（管理员可以配置 Nginx 主进程的工作进程的数量）(epoll)，不会为每个请求分配 cpu 和内存资源，节省了大量资源，同时也减少了大量的 CPU 的上下文切换。所以才使得 Nginx 支持更高的并发。
+
+> Netty、Redis 基本采用相同思路。
+
+## 什么是动态资源、静态资源分离？
+
+动态资源、静态资源分离，是让动态网站里的动态网页根据一定规则把不变的资源和经常变的资源区分开来，动静资源做好了拆分以后我们就可以根据静态资源的特点将其做缓存操作，这就是网站静态化处理的核心思路。
+
+动态资源、静态资源分离简单的概括是：动态文件与静态文件的分离。
+
+🦅 **为什么要做动、静分离？**
+
+在我们的软件开发中，有些请求是需要后台处理的（如：`.jsp`,`.do` 等等），有些请求是不需要经过后台处理的（如：css、html、jpg、js 等等文件），这些不需要经过后台处理的文件称为静态文件，否则动态文件。
+
+因此我们后台处理忽略静态文件。这会有人又说那我后台忽略静态文件不就完了吗？当然这是可以的，但是这样后台的请求次数就明显增多了。在我们对资源的响应速度有要求的时候，我们应该使用这种动静分离的策略去解决动、静分离将网站静态资源（HTML，JavaScript，CSS，img等文件）与后台应用分开部署，提高用户访问静态代码的速度，降低对后台应用访问
+
+这里我们将静态资源放到 Nginx 中，动态资源转发到 Tomcat 服务器中去。
+
+😈 当然，因为现在七牛、阿里云等 CDN 服务已经很成熟，主流的做法，是把静态资源缓存到 CDN 服务中，从而提升访问速度。
+
+- 相比本地的 Nginx 来说，CDN 服务器由于在国内有更多的节点，可以实现用户的就近访问。
+- 并且，CDN 服务可以提供更大的带宽，不像我们自己的应用服务，提供的带宽是有限的。
+
+🦅 **什么叫 CDN 服务？**
+
+CDN ，即内容分发网络。
+
+其目的是，通过在现有的 Internet中 增加一层新的网络架构，将网站的内容发布到最接近用户的网络边缘，使用户可就近取得所需的内容，提高用户访问网站的速度。
+
+一般来说，因为现在 CDN 服务比较大众，所以基本所有公司都会使用 CDN 服务。
+
+## Nginx 有哪些负载均衡策略？
+
+负载均衡，即是代理服务器将接收的请求均衡的分发到各服务器中。
+
+Nginx 默认提供了 3 种负载均衡策略：
+
+- 1、轮询（默认）round_robin
+
+  > 每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器 down 掉，能自动剔除。
+
+- 2、IP 哈希 ip_hash
+
+  > 每个请求按访问 ip 的 hash 结果分配，这样每个访客固定访问一个后端服务器，可以解决 session 共享的问题。
+  >
+  > 当然，实际场景下，一般不考虑使用 ip_hash 解决 session 共享。
+
+- 3、最少连接 least_conn
+
+  > 下一个请求将被分派到活动连接数量最少的服务器
+
+通过 Nginx 插件，我们还可以引入 fair、url_hash 等负载均衡策略。
+
+另外，我们还可以配置每一个后端节点在负载均衡时的其它配置：
+
+```
+weight=1; # (weight 默认为1.weight越大，负载的权重就越大)
+down; # (down 表示单前的server暂时不参与负载)
+backup; # (其它所有的非backup机器down或者忙的时候，请求backup机器)
+max_fails=1; # 允许请求失败的次数默认为 1 。当超过最大次数时，返回 proxy_next_upstream 模块定义的错误
+fail_timeout=30; # max_fails 次失败后，暂停的时间
+```
+
+详细的，可以再看看 [《Nginx 官方文档 —— 使用 Nginx 作为 HTTP 负载均衡》](http://ifeve.com/nginx-http/) 文章。
+
+## Nginx 如何实现后端服务的健康检查？
+
+参见 [《Nginx 负载均衡中后端节点服务器健康检查的操作梳理》](https://www.cnblogs.com/kevingrace/p/6685698.html) 文章。
+
+- 方式一，利用 nginx 自带模块 ngx_http_proxy_module 和 ngx_http_upstream_module 对后端节点做健康检查。
+
+- 方式二，利用 nginx_upstream_check_module 模块对后端节点做健康检查。
+
+  > 推荐使用。
+
+## Nginx 如何开启压缩？
+
+参见 [《Nginx 开启 gzip 压缩的配置详解和压缩效果对比》](https://www.daixiaorui.com/read/251.html) 文章。
+
+## 666. 彩蛋
+
+对于开发来说，Nginx 我们主要掌握会用，所以实际面试场景下，问的也不会太深。
+
+参考与推荐如下文章：
+
+- [《Nginx 面试中最常见的 18 道题 —— 抱佛脚必备》](https://segmentfault.com/a/1190000010677483)
+- [《Nginx 常见面试题》](https://blog.csdn.net/xal0610/article/details/79531692)
+- [《Nginx 负载均衡策略》](https://www.jianshu.com/p/4af1940bd251)
+- [《Nginx 多进程模型是如何实现高并发的？》](https://www.zhihu.com/question/22062795)
\ No newline at end of file
diff --git a/面试题/file-create.py b/面试题/file-create.py
new file mode 100644
index 0000000..a412975
--- /dev/null
+++ b/面试题/file-create.py
@@ -0,0 +1,27 @@
+import os
+import pyperclip
+
+# 获取当前脚本的路径
+script_dir = os.path.dirname(os.path.abspath(__file__))
+
+# 从剪贴板获取文件名列表，假设每行一个文件名
+file_names = pyperclip.paste().strip().split('\n')
+
+# 遍历文件名列表，为每个文件名添加排序前缀并创建文件
+for index, file_name in enumerate(file_names, start=1):
+    # 去除文件名两端的空白字符
+    file_name = file_name.strip()
+    
+    # 添加排序前缀和.md后缀
+    file_name_with_prefix = f"{index:02d}-{file_name}.md"  # 这里使用3位数的排序前缀，可以根据需要调整
+    
+    # 构建文件的完整路径
+    file_path = os.path.join(script_dir, file_name_with_prefix)
+    
+    # 创建文件
+    with open(file_path, 'w') as file:
+        # 如果需要写入初始内容，可以在这里添加
+        # 例如：file.write("This is the content of the file.")
+        pass  # 如果不需要写入内容，则使用pass
+
+print(f"Files created successfully in {script_dir}")
\ No newline at end of file
diff --git a/面试题/tmp.txt b/面试题/tmp.txt
new file mode 100644
index 0000000..81554a6
--- /dev/null
+++ b/面试题/tmp.txt
@@ -0,0 +1,31 @@
+Netty 面试题
+Dubbo 面试题
+Spring 面试题
+Spring MVC 面试题
+Spring Boot 面试题
+Spring Cloud 面试题
+MyBatis 面试题
+精尽【消息队列 】面试题
+RocketMQ 面试题
+RabbitMQ 面试题
+Kafka 面试题
+精尽【缓存】面试题
+Redis 面试题
+MySQL 面试题
+精尽【分库分表】面试题
+精尽【分布式事务】面试题
+MongoDB 面试题
+Elasticsearch 面试题（TODO）
+精尽设计模式面试题（TODO）
+精尽数据结构与算法面试题
+精尽计算机网络面试题
+Linux 面试题
+Git 面试题
+Jenkins 面试题（Beta）
+Maven 面试题
+Java【基础】面试题
+Java【集合】面试题
+Java【并发】面试题
+Java【虚拟机】面试题
+Zookeeper 面试题
+Nginx 面试题
\ No newline at end of file