msb-public
/
source-code-hunter
mirror of https://github.com/doocs/source-code-hunter.git
6
2
Code Issues Projects Releases Wiki Activity

Merge remote-tracking branch 'remotes/other_master/master'

Browse Source
pull/34/head
huifer 6 years ago
parent 10e8e46a65 bd59de19c4
commit 3e45f233c4
101 changed files with 11140 additions and 4746 deletions
Show Stats Download Patch File Download Diff File

53
README.md
Unescape View File

@ -27,13 +27,13 @@
- [SpringMVC 的设计与实现](/docs/Spring/SpringMVC/SpringMVC的设计与实现.md)
- [SpringMVC 跨域解析](/docs/Spring/SpringMVC/SpringMVC-CROS.md)
### SpringJDBC
- 努力编写中...
### Spring事务
- [Spring 与事务处理](/docs/Spring/SpringTransaction/Spring与事务处理.md)
- [Spring 声明式事务处理](/docs/Spring/SpringTransaction/Spring声明式事务处理.md)
- [Spring 事务处理的设计与实现](/docs/Spring/SpringTransaction/Spring事务处理的设计与实现.md)
- [Spring事务处理器的设计与实现](/docs/Spring/SpringTransaction/Spring事务处理器的设计与实现.md)
- [Spring 事务管理器的设计与实现](/docs/Spring/SpringTransaction/Spring事务管理器的设计与实现.md)
### Spring源码故事（瞎编版）
- [面筋哥 IoC 容器的一天(上)](/docs/Spring/Spring源码故事（瞎编版）/面筋哥IoC容器的一天(上).md)
@ -83,24 +83,59 @@
## Netty
### IO
- [把被说烂的BIO、NIO、AIO再从头到尾扯一遍](docs/Netty/IO/把被说烂的BIO、NIO、AIO再从头到尾扯一遍.md)
### 设计原理
### 网络 IO 技术基础
- [把被说烂的 BIO、NIO、AIO 再从头到尾扯一遍](docs/Netty/IOTechnologyBase/把被说烂的BIO、NIO、AIO再从头到尾扯一遍.md)
- [IO模型](docs/Netty/IOTechnologyBase/IO模型.md)
- [四种IO编程及对比](docs/Netty/IOTechnologyBase/四种IO编程及对比.md)
### Netty 粘拆包解决方案
- [TCP粘拆包问题及Netty中的解决方案](docs/Netty/TCP粘拆包/TCP粘拆包问题及Netty中的解决方案.md)
### Netty 编解码
- [Java序列化缺点与主流编解码框架](docs/Netty/Netty编解码/Java序列化缺点与主流编解码框架.md)
### Netty 多协议开发
- [基于HTTP协议的Netty开发](docs/Netty/Netty多协议开发/基于HTTP协议的Netty开发.md)
- [基于WebSocket协议的Netty开发](docs/Netty/Netty多协议开发/基于WebSocket协议的Netty开发.md)
- [基于自定义协议的Netty开发](docs/Netty/Netty多协议开发/基于自定义协议的Netty开发.md)
### 基于Netty开发服务端及客户端
- [基于Netty的服务端开发](docs/Netty/基于Netty开发服务端及客户端/基于Netty的服务端开发.md)
- [基于Netty的客户端开发](docs/Netty/基于Netty开发服务端及客户端/基于Netty的客户端开发.md)
### Netty 主要组件的源码分析
- [ByteBuf组件]()
- [Channel组件 和 Unsafe组件]()
- [ChannelPipeline 和 ChannelHandler组件]()
- [EventLoop 和 EventLoopGroup组件]()
- [Future 和 Promise组件]()
### Netty 高级特性
- [Netty 架构设计](docs/Netty/AdvancedFeaturesOfNetty/Netty架构设计.md)
- [Netty 高性能之道](docs/Netty/AdvancedFeaturesOfNetty/Netty高性能之道.md)
- [Netty 高可靠性设计](docs/Netty/AdvancedFeaturesOfNetty/Netty高可靠性设计.md)
## Redis
- 努力编写中...
## Tomcat
- 努力编写中...
## 学习心得
### 个人经验
- [初级开发者应该从 spring 源码中学什么](docs/LearningExperience/PersonalExperience/初级开发者应该从spring源码中学什么.md)
- [初级开发者应该从 Spring 源码中学什么](docs/LearningExperience/PersonalExperience/初级开发者应该从spring源码中学什么.md)
### 编码规范
- [由量变到质变写出高质量代码](docs/LearningExperience/EncodingSpecification/由量变到质变写出高质量代码.md)
- [一个程序员的自我修养](docs/LearningExperience/EncodingSpecification/一个程序员的自我修养.md)
### 设计模式
- [从框架源码中学习设计模式](docs/LearningExperience/DesignPattern/从框架源码中学习设计模式.md)
- [从 Spring 及 Mybatis 框架源码中学习设计模式(创建型)](docs/LearningExperience/DesignPattern/从Spring及Mybatis框架源码中学习设计模式(创建型).md)
- [从 Spring 及 Mybatis 框架源码中学习设计模式(行为型)](docs/LearningExperience/DesignPattern/从Spring及Mybatis框架源码中学习设计模式(行为型).md)
- [从 Spring 及 Mybatis 框架源码中学习设计模式(结构型)](docs/LearningExperience/DesignPattern/从Spring及Mybatis框架源码中学习设计模式(结构型).md)
- [从框架源码中学习设计模式的感悟](docs/LearningExperience/DesignPattern/从框架源码中学习设计模式的感悟.md)
### 多线程
- [Java多线程编程在各主流框架中的应用]()
## 贡献者
感谢以下所有朋友对 [GitHub 技术社区 Doocs](https://github.com/doocs) 所做出的贡献，[参与项目维护请戳这儿](https://doocs.github.io/#/?id=how-to-join)。

834
docs/LearningExperience/DesignPattern/从Spring及Mybatis框架源码中学习设计模式(创建型).md
Unescape View File

@ -0,0 +1,834 @@
设计模式是解决问题的方案，从大神的代码中学习对设计模式的使用，可以有效提升个人编码及设计代码的能力。本系列博文用于总结阅读过的框架源码（Spring系列、Mybatis）及JDK源码中 所使用过的设计模式，并结合个人工作经验，重新理解设计模式。
本篇博文主要看一下创建型的几个设计模式，即，单例模式、各种工厂模式 及 建造者模式。
## 单例模式
### 个人理解
确保某个类只有一个实例，并提供该实例的获取方法。实际应用很多，不管是框架、JDK还是实际的项目开发，但大都会使用“饿汉式”或“枚举”来实现单例。“懒汉式”也有一些应用，但通过“双检锁机制”来保证单例的实现很少见。
### 实现方式
最简单的就是 使用一个私有构造函数、一个私有静态变量，以及一个公共静态方法的方式来实现。懒汉式、饿汉式等简单实现就不多BB咯，这里强调一下双检锁懒汉式实现的坑，以及枚举方式的实现吧，最后再结合spring源码 扩展一下单例bean的实现原理。
**1. 双检锁实现的坑**
```java
/**
* @author 云之君
* 双检锁 懒汉式，实现线程安全的单例
* 关键词：JVM指令重排、volatile、反射攻击
*/
public class Singleton3 {
/**
* 对于我们初级开发来说，这个volatile在实际开发中可能见过，但很少会用到
* 这里加个volatile进行修饰，也是本单例模式的精髓所在。
* 下面的 instance = new Singleton3(); 这行代码在JVM中其实是分三步执行的：
* 1、分配内存空间；
* 2、初始化对象；
* 3、将instance指向分配的内存地址。
* 但JVM具有指令重排的特性，实际的执行顺序可能会是1、3、2，导致多线程情况下出问题，
* 使用volatile修饰instance变量 可以 避免上述的指令重排
* tips：不太理解的是 第一个线程在执行第2步之前就已经释放了锁吗？导致其它线程进入synchronized代码块
* 执行 instance == null 的判断？
*/
private volatile static Singleton3 instance;
private Singleton3(){
}
public static Singleton3 getInstance(){
if(instance == null){
synchronized(Singleton3.class){
if(instance == null){
instance = new Singleton3();
}
}
}
return instance;
}
}
```
**2. 枚举实现**
其它的单例模式实现往往都会面临序列化 和 反射攻击的问题，比如上面的Singleton3如果实现了Serializable接口，那么在每次序列化时都会创建一个新对象，若要保证单例，必须声明所有字段都是transient的，并且提供一个readResolve()方法。反射攻击可以通过setAccessible()方法将私有的构造方法公共化，进而实例化。若要防止这种攻击，就需要在构造方法中添加 防止实例化第二个对象的代码。
枚举实现的单例在面对 复杂的序列化及反射攻击时，依然能够保持自己的单例状态，所以被认为是单例的最佳实践。比如，mybatis在定义SQL命令类型时就使用到了枚举。
```java
package org.apache.ibatis.mapping;
/**
* @author Clinton Begin
*/
public enum SqlCommandType {
UNKNOWN, INSERT, UPDATE, DELETE, SELECT, FLUSH;
}
```
### JDK中的范例
**1. java.lang.Runtime**
```java
/**
* 每个Java应用程序都有一个单例的Runtime对象，通过getRuntime()方法获得
* @author unascribed
* @see java.lang.Runtime#getRuntime()
* @since JDK1.0
*/
public class Runtime {
/** 很明显，这里用的是饿汉式 实现单例 */
private static Runtime currentRuntime = new Runtime();
public static Runtime getRuntime() {
return currentRuntime;
}
/** Don't let anyone else instantiate this class */
private Runtime() {}
}
```
**2. java.awt.Desktop**
```java
public class Desktop {
/**
* Suppresses default constructor for noninstantiability.
*/
private Desktop() {
peer = Toolkit.getDefaultToolkit().createDesktopPeer(this);
}
/**
* 由于对象较大，这里使用了懒汉式延迟加载，方式比较简单，直接把锁加在方法上。
* 使用双检锁方式实现的单例 还没怎么碰到过，有经验的小伙伴 欢迎留言补充
*/
public static synchronized Desktop getDesktop(){
if (GraphicsEnvironment.isHeadless()) throw new HeadlessException();
if (!Desktop.isDesktopSupported()) {
throw new UnsupportedOperationException("Desktop API is not " +
"supported on the current platform");
}
sun.awt.AppContext context = sun.awt.AppContext.getAppContext();
Desktop desktop = (Desktop)context.get(Desktop.class);
if (desktop == null) {
desktop = new Desktop();
context.put(Desktop.class, desktop);
}
return desktop;
}
}
```
### Spring的单例bean是如何实现的？
Spring实现单例bean是使用map注册表和synchronized同步机制实现的，通过分析spring的 AbstractBeanFactory 中的 doGetBean 方法和DefaultSingletonBeanRegistry的getSingleton()方法，可以理解其实现原理。
```java
public abstract class AbstractBeanFactory extends FactoryBeanRegistrySupport implements ConfigurableBeanFactory {
......
/**
* !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
* 真正实现向IOC容器获取Bean的功能，也是触发依赖注入(DI)功能的地方
* !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
*/
@SuppressWarnings("unchecked")
protected <T> T doGetBean(final String name, final Class<T> requiredType, final Object[] args,
boolean typeCheckOnly) throws BeansException {
......
//创建单例模式bean的实例对象
if (mbd.isSingleton()) {
//这里使用了一个匿名内部类，创建Bean实例对象，并且注册给所依赖的对象
sharedInstance = getSingleton(beanName, new ObjectFactory<Object>() {
public Object getObject() throws BeansException {
try {
/**
* ！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！
* 创建一个指定的Bean实例对象，如果有父级继承，则合并子类和父类的定义
* 走子类中的实现
* ！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！
*/
return createBean(beanName, mbd, args);
}
catch (BeansException ex) {
destroySingleton(beanName);
throw ex;
}
}
});
//获取给定Bean的实例对象
bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
}
......
}
}
/**
* 默认的单例bean注册器
*/
public class DefaultSingletonBeanRegistry extends SimpleAliasRegistry implements SingletonBeanRegistry {
/** 单例的bean实例的缓存 */
private final Map<String, Object> singletonObjects = new ConcurrentHashMap<String, Object>(64);
/**
* 返回给定beanName的 已经注册的 单例bean，如果没有注册，则注册并返回
*/
public Object getSingleton(String beanName, ObjectFactory<?> singletonFactory) {
Assert.notNull(beanName, "'beanName' must not be null");
// 加锁，保证单例bean在多线程环境下不会创建多个
synchronized (this.singletonObjects) {
// 先从缓存中取，有就直接返回，没有就创建、注册到singletonObjects、返回
Object singletonObject = this.singletonObjects.get(beanName);
if (singletonObject == null) {
if (this.singletonsCurrentlyInDestruction) {
throw new BeanCreationNotAllowedException(beanName,
"Singleton bean creation not allowed while the 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 + "'");
}
beforeSingletonCreation(beanName);
boolean recordSuppressedExceptions = (this.suppressedExceptions == null);
if (recordSuppressedExceptions) {
this.suppressedExceptions = new LinkedHashSet<Exception>();
}
try {
singletonObject = singletonFactory.getObject();
}
catch (BeanCreationException ex) {
if (recordSuppressedExceptions) {
for (Exception suppressedException : this.suppressedExceptions) {
ex.addRelatedCause(suppressedException);
}
}
throw ex;
}
finally {
if (recordSuppressedExceptions) {
this.suppressedExceptions = null;
}
afterSingletonCreation(beanName);
}
// 注册到单例bean的缓存
addSingleton(beanName, singletonObject);
}
return (singletonObject != NULL_OBJECT ? singletonObject : null);
}
}
}
```
## 简单工厂模式
### 个人理解
把同一系列类的实例化交由一个工厂类进行集中管控。与其说它是一种设计模式，倒不如把它看成一种编程习惯，因为它不符合“开闭原则”，增加新的产品类需要修改工厂类的代码。
### 简单实现
```java
public interface Hero {
void speak();
}
public class DaJi implements Hero {
@Override
public void speak() {
System.out.println("妲己，陪你玩 ~");
}
}
public class LiBai implements Hero{
@Override
public void speak() {
System.out.println("今朝有酒 今朝醉 ~");
}
}
/** 对各种英雄进行集中管理 */
public class HeroFactory {
public static Hero getShibing(String name){
if("LiBai".equals(name))
return new LiBai();
else if("DaJi".equals(name))
return new DaJi();
else
return null;
}
}
```
这种设计方式只在我们产品的“FBM资金管理”模块有看到过，其中对100+个按钮类进行了集中管控，不过其设计结构比上面这种要复杂的多。
## 工厂方法模式
### 个人理解
在顶级工厂（接口/抽象类）中定义 产品类的获取方法，由具体的子工厂实例化对应的产品，一般是一个子工厂对应一个特定的产品，实现对产品的集中管控，并且符合“开闭原则”。
### Mybatis中的范例
mybatis中数据源DataSource的获取使用到了该设计模式。接口DataSourceFactory定义了获取DataSource对象的方法，各实现类 完成了获取对应类型的DataSource对象的实现。(mybatis的源码都是缩进两个空格，难道国外的编码规范有独门派系？)
```java
public interface DataSourceFactory {
// 设置DataSource的属性，一般紧跟在DataSource初始化之后
void setProperties(Properties props);
// 获取DataSource对象
DataSource getDataSource();
}
public class JndiDataSourceFactory implements DataSourceFactory {
private DataSource dataSource;
@Override
public DataSource getDataSource() {
return dataSource;
}
@Override
public void setProperties(Properties properties) {
try {
InitialContext initCtx;
Properties env = getEnvProperties(properties);
if (env == null) {
initCtx = new InitialContext();
} else {
initCtx = new InitialContext(env);
}
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);
}
}
}
public class UnpooledDataSourceFactory implements DataSourceFactory {
protected DataSource dataSource;
// 在实例化该工厂时，就完成了DataSource的实例化
public UnpooledDataSourceFactory() {
this.dataSource = new UnpooledDataSource();
}
@Override
public DataSource getDataSource() {
return dataSource;
}
}
public class PooledDataSourceFactory extends UnpooledDataSourceFactory {
// 与UnpooledDataSourceFactory的不同之处是，其初始化的DataSource为PooledDataSource
public PooledDataSourceFactory() {
this.dataSource = new PooledDataSource();
}
}
public interface DataSource extends CommonDataSource, Wrapper {
Connection getConnection() throws SQLException;
Connection getConnection(String username, String password)
throws SQLException;
}
```
DataSource最主要的几个实现类内容都比较多，代码就不贴出来咯，感兴趣的同学可以到我的源码分析专题中看到详细解析。
**tips：什么时候该用简单工厂模式？什么时候该用工厂方法模式呢？**
个人认为，工厂方法模式符合“开闭原则”，增加新的产品类不用修改代码，应当优先考虑使用这种模式。如果产品类结构简单且数量庞大时，还是使用简单工厂模式更容易维护些，如：上百个按钮类。
## 抽象工厂模式
### 个人理解
设计结构上与“工厂方法”模式很像，最主要的区别是，工厂方法模式中 一个子工厂只对应**一个**具体的产品，而抽象工厂模式中，一个子工厂对应**一组**具有相关性的产品，即，存在多个获取不同产品的方法。这种设计模式也很少见人用，倒是“工厂方法”模式见的最多。
### 简单实现
```java
public abstract class AbstractFactory {
abstract protected AbstractProductA createProductA();
abstract protected AbstractProductB createProductB();
}
public class ConcreteFactory1 extends AbstractFactory {
@Override
protected AbstractProductA createProductA() {
return new ProductA1();
}
@Override
protected AbstractProductB createProductB() {
return new ProductB1();
}
}
public class ConcreteFactory2 extends AbstractFactory {
@Override
protected AbstractProductA createProductA() {
return new ProductA2();
}
@Override
protected AbstractProductB createProductB() {
return new ProductB2();
}
}
public class Client {
public static void main(String[] args) {
AbstractFactory factory = new ConcreteFactory1();
AbstractProductA productA = factory.createProductA();
AbstractProductB productB = factory.createProductB();
...
// 结合使用productA和productB进行后续操作
...
}
}
```
### JDK中的范例
JDK的javax.xml.transform.TransformerFactory组件使用了类似“抽象工厂”模式的设计，抽象类TransformerFactory定义了两个抽象方法newTransformer()和newTemplates()分别用于生成Transformer对象 和 Templates对象，其两个子类进行了不同的实现，源码如下（版本1.8）。
```java
public abstract class TransformerFactory {
public abstract Transformer newTransformer(Source source)
throws TransformerConfigurationException;
public abstract Templates newTemplates(Source source)
throws TransformerConfigurationException;
}
/**
* SAXTransformerFactory 继承了 TransformerFactory
*/
public class TransformerFactoryImpl
extends SAXTransformerFactory implements SourceLoader, ErrorListener {
@Override
public Transformer newTransformer(Source source) throws TransformerConfigurationException {
final Templates templates = newTemplates(source);
final Transformer transformer = templates.newTransformer();
if (_uriResolver != null) {
transformer.setURIResolver(_uriResolver);
}
return(transformer);
}
@Override
public Templates newTemplates(Source source) throws TransformerConfigurationException {
......
return new TemplatesImpl(bytecodes, transletName,
xsltc.getOutputProperties(), _indentNumber, this);
}
}
public class SmartTransformerFactoryImpl extends SAXTransformerFactory {
public Transformer newTransformer(Source source) throws TransformerConfigurationException {
if (_xalanFactory == null) {
createXalanTransformerFactory();
}
if (_errorlistener != null) {
_xalanFactory.setErrorListener(_errorlistener);
}
if (_uriresolver != null) {
_xalanFactory.setURIResolver(_uriresolver);
}
_currFactory = _xalanFactory;
return _currFactory.newTransformer(source);
}
public Templates newTemplates(Source source) throws TransformerConfigurationException {
if (_xsltcFactory == null) {
createXSLTCTransformerFactory();
}
if (_errorlistener != null) {
_xsltcFactory.setErrorListener(_errorlistener);
}
if (_uriresolver != null) {
_xsltcFactory.setURIResolver(_uriresolver);
}
_currFactory = _xsltcFactory;
return _currFactory.newTemplates(source);
}
}
```
## 建造者模式
### 个人理解
该模式主要用于将复杂对象的构建过程分解成一个个简单的步骤，或者分摊到多个类中进行构建，保证构建过程层次清晰，代码不会过分臃肿，屏蔽掉了复杂对象内部的具体构建细节，其类图结构如下所示。
![avatar](/images/DesignPattern/建造者模式类图.png)
该模式的主要角色如下：
- 建造者接口（Builder）：用于定义建造者构建产品对象的各种公共行为，主要分为 建造方法 和 获取构建好的产品对象；
- 具体建造者（ConcreteBuilder）：实现上述接口方法；
- 导演（Director）：通过调用具体建造者创建需要的产品对象；
- 产品（Product）：被建造的复杂对象。
其中的导演角色不必了解产品类的内部细节，只提供需要的信息给建造者，由具体建造者处理这些信息（这个处理过程可能会比较复杂）并完成产品构造，使产品对象的上层代码与产品对象的创建过程解耦。建造者模式将复杂产品的创建过程分散到不同的构造步骤中，这样可以对产品创建过程实现更加精细的控制，也会使创建过程更加清晰。每个具体建造者都可以创建出完整的产品对象，而且具体建造者之间是相互独立的， 因此系统就可以通过不同的具体建造者，得到不同的产品对象。当有新产品出现时，无须修改原有的代码，只需要添加新的具体建造者即可完成扩展，这符合“开放一封闭” 原则。
### 典型的范例 StringBuilder和StringBuffer
相信在拼SQL语句时大家一定经常用到StringBuffer和StringBuilder这两个类，它们就用到了建造者设计模式，源码如下（版本1.8）：
```java
abstract class AbstractStringBuilder implements Appendable, CharSequence {
/**
* The value is used for character storage.
*/
char[] value;
/**
* The count is the number of characters used.
*/
int count;
/**
* Creates an AbstractStringBuilder of the specified capacity.
*/
AbstractStringBuilder(int capacity) {
value = new char[capacity];
}
public AbstractStringBuilder append(String str) {
if (str == null)
return appendNull();
int len = str.length();
ensureCapacityInternal(count + len);
// 这里完成了对复杂String的构造，将str拼接到当前对象后面
str.getChars(0, len, value, count);
count += len;
return this;
}
}
/**
* @since JDK 1.5
*/
public final class StringBuilder extends AbstractStringBuilder
implements java.io.Serializable, CharSequence {
public StringBuilder() {
super(16);
}
@Override
public StringBuilder append(String str) {
super.append(str);
return this;
}
@Override
public String toString() {
// Create a copy, don't share the array
return new String(value, 0, count);
}
}
/**
* @since JDK 1.0
*/
public final class StringBuffer extends AbstractStringBuilder
implements java.io.Serializable, CharSequence {
/**
* toString返回的最后一个值的缓存。在修改StringBuffer时清除。
*/
private transient char[] toStringCache;
public StringBuffer() {
super(16);
}
/**
* 与StringBuilder建造者最大的不同就是，增加了线程安全机制
*/
@Override
public synchronized StringBuffer append(String str) {
toStringCache = null;
super.append(str);
return this;
}
}
```
### Mybatis中的范例
MyBatis 的初始化过程使用了建造者模式，抽象类 BaseBuilder 扮演了“建造者接口”的角色，对一些公用方法进行了实现，并定义了公共属性。XMLConfigBuilder、XMLMapperBuilder、XMLStatementBuilder 等实现类扮演了“具体建造者”的角色，分别用于解析mybatis-config.xml配置文件、映射配置文件 以及 SQL节点。Configuration 和 SqlSessionFactoryBuilder 则分别扮演了“产品” 和 “导演”的角色。**即，SqlSessionFactoryBuilder 使用了 BaseBuilder建造者组件 对复杂对象 Configuration 进行了构建。**
BaseBuilder组件的设计与上面标准的建造者模式是有很大不同的，BaseBuilder的建造者模式主要是为了将复杂对象Configuration的构建过程分解的层次更清晰，将整个构建过程分解到多个“具体构造者”类中，需要这些“具体构造者”共同配合才能完成Configuration的构造，单个“具体构造者”不具有单独构造产品的能力，这与StringBuilder及StringBuffer是不同的。
个人理解的构建者模式 其核心就是用来构建复杂对象的，比如 mybatis 对 Configuration 对象的构建。当然，我们也可以把 对这个对象的构建过程 写在一个类中，来满足我们的需求，但这样做的话，这个类就会变得及其臃肿，难以维护。所以把整个构建过程合理地拆分到多个类中，分别构建，整个代码就显得非常规整，且思路清晰，而且 建造者模式符合 开闭原则。其源码实现如下。
```java
public abstract class BaseBuilder {
/**
* Configuration 是 MyBatis 初始化过程的核心对象并且全局唯一，
* MyBatis 中几乎全部的配置信息会保存到Configuration 对象中。
* 也有人称它是一个“All-In-One”配置对象
*/
protected final Configuration configuration;
/**
* 在 mybatis-config.xml 配置文件中可以使用<typeAliases>标签定义别名，
* 这些定义的别名都会记录在该 TypeAliasRegistry 对象中
*/
protected final TypeAliasRegistry typeAliasRegistry;
/**
* 在 mybatis-config.xml 配置文件中可以使用<typeHandlers>标签添加自定义
* TypeHandler，完成指定数据库类型与 Java 类型的转换，这些 TypeHandler
* 都会记录在 TypeHandlerRegistry 中
*/
protected final TypeHandlerRegistry typeHandlerRegistry;
/**
* BaseBuilder 中记录的 TypeAliasRegistry 对象和 TypeHandlerRegistry 对象，
* 其实是全局唯一的，它们都是在 Configuration 对象初始化时创建的
*/
public BaseBuilder(Configuration configuration) {
this.configuration = configuration;
this.typeAliasRegistry = this.configuration.getTypeAliasRegistry();
this.typeHandlerRegistry = this.configuration.getTypeHandlerRegistry();
}
}
public class XMLConfigBuilder extends BaseBuilder {
/** 标识是否已经解析过 mybatis-config.xml 配置文件 */
private boolean parsed;
/** 用于解析 mybatis-config.xml 配置文件 */
private final XPathParser parser;
/** 标识 <environment> 配置的名称，默认读取 <environment> 标签的 default 属性 */
private String environment;
/** 负责创建和缓存 Reflector 对象 */
private final ReflectorFactory localReflectorFactory = new DefaultReflectorFactory();
public Configuration parse() {
if (parsed) {
throw new BuilderException("Each XMLConfigBuilder can only be used once.");
}
parsed = true;
// 在 mybatis-config.xml 配置文件中查找<configuration>节点，并开始解析
parseConfiguration(parser.evalNode("/configuration"));
return configuration;
}
private void parseConfiguration(XNode root) {
try {
//issue #117 read properties first
// 解析<properties>节点
propertiesElement(root.evalNode("properties"));
// 解析<settings>节点
Properties settings = settingsAsProperties(root.evalNode("settings"));
loadCustomVfs(settings);
loadCustomLogImpl(settings);
// 解析<typeAliases>节点
typeAliasesElement(root.evalNode("typeAliases"));
// 解析<plugins>节点
pluginElement(root.evalNode("plugins"));
// 解析<objectFactory>节点
objectFactoryElement(root.evalNode("objectFactory"));
// 解析<objectWrapperFactory>节点
objectWrapperFactoryElement(root.evalNode("objectWrapperFactory"));
// 解析<reflectorFactory>节点
reflectorFactoryElement(root.evalNode("reflectorFactory"));
settingsElement(settings);
// read it after objectFactory and objectWrapperFactory issue #631
// 解析<environments>节点
environmentsElement(root.evalNode("environments"));
// 解析<databaseIdProvider>节点
databaseIdProviderElement(root.evalNode("databaseIdProvider"));
// 解析<typeHandlers>节点
typeHandlerElement(root.evalNode("typeHandlers"));
// 解析<mappers>节点
mapperElement(root.evalNode("mappers"));
} catch (Exception e) {
throw new BuilderException("Error parsing SQL Mapper Configuration. Cause: " + e, e);
}
}
}
public class XMLMapperBuilder extends BaseBuilder {
private final XPathParser parser;
private final MapperBuilderAssistant builderAssistant;
private final Map<String, XNode> sqlFragments;
private final String resource;
public void parse() {
// 判断是否已经加载过该映射文件
if (!configuration.isResourceLoaded(resource)) {
// 处理<mapper>节点
configurationElement(parser.evalNode("/mapper"));
// 将 resource 添加到 Configuration.loadedResources 集合中保存，
// 它是 HashSet<String> 类型的集合，其中记录了已经加载过的映射文件
configuration.addLoadedResource(resource);
// 注册 Mapper 接口
bindMapperForNamespace();
}
// 处理 configurationElement() 方法中解析失败的<resultMap>节点
parsePendingResultMaps();
// 处理 configurationElement() 方法中解析失败的<cache-ref>节点
parsePendingCacheRefs();
// 处理 configurationElement() 方法中解析失败的 SQL 语句节点
parsePendingStatements();
}
private void configurationElement(XNode context) {
try {
// 获取<mapper>节点的 namespace 属性,若 namespace 属性为空，则抛出异常
String namespace = context.getStringAttribute("namespace");
if (namespace == null || namespace.equals("")) {
throw new BuilderException("Mapper's namespace cannot be empty");
}
// 设置 MapperBuilderAssistant 的 currentNamespace 字段，记录当前命名空间
builderAssistant.setCurrentNamespace(namespace);
// 解析<cache-ref>节点
cacheRefElement(context.evalNode("cache-ref"));
// 解析<cache>节点
cacheElement(context.evalNode("cache"));
// 解析<parameterMap>节点,(该节点 已废弃，不再推荐使用)
parameterMapElement(context.evalNodes("/mapper/parameterMap"));
// 解析<resultMap>节点
resultMapElements(context.evalNodes("/mapper/resultMap"));
// 解析<sql>节点
sqlElement(context.evalNodes("/mapper/sql"));
// 解析<select>、<insert>、<update>、<delete>等SQL节点
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);
}
}
}
public class XMLStatementBuilder extends BaseBuilder {
private final MapperBuilderAssistant builderAssistant;
private final XNode context;
private final String requiredDatabaseId;
public void parseStatementNode() {
// 获取 SQL 节点的 id 以及 databaseId 属性，若其 databaseId属性值与当前使用的数据库不匹配，
// 则不加载该 SQL 节点；若存在相同 id 且 databaseId 不为空的 SQL 节点，则不再加载该 SQL 节点
String id = context.getStringAttribute("id");
String databaseId = context.getStringAttribute("databaseId");
if (!databaseIdMatchesCurrent(id, databaseId, this.requiredDatabaseId)) {
return;
}
// 根据 SQL 节点的名称决定其 SqlCommandType
String nodeName = context.getNode().getNodeName();
SqlCommandType sqlCommandType = SqlCommandType.valueOf(nodeName.toUpperCase(Locale.ENGLISH));
boolean isSelect = sqlCommandType == SqlCommandType.SELECT;
boolean flushCache = context.getBooleanAttribute("flushCache", !isSelect);
boolean useCache = context.getBooleanAttribute("useCache", isSelect);
boolean resultOrdered = context.getBooleanAttribute("resultOrdered", false);
// 在解析 SQL 语句之前，先处理其中的<include>节点
XMLIncludeTransformer includeParser = new XMLIncludeTransformer(configuration, builderAssistant);
includeParser.applyIncludes(context.getNode());
String parameterType = context.getStringAttribute("parameterType");
Class<?> parameterTypeClass = resolveClass(parameterType);
String lang = context.getStringAttribute("lang");
LanguageDriver langDriver = getLanguageDriver(lang);
// 处理<selectKey>节点
processSelectKeyNodes(id, parameterTypeClass, langDriver);
// Parse the SQL (pre: <selectKey> and <include> were parsed and removed)
KeyGenerator keyGenerator;
String keyStatementId = id + SelectKeyGenerator.SELECT_KEY_SUFFIX;
keyStatementId = builderAssistant.applyCurrentNamespace(keyStatementId, true);
if (configuration.hasKeyGenerator(keyStatementId)) {
keyGenerator = configuration.getKeyGenerator(keyStatementId);
} else {
keyGenerator = context.getBooleanAttribute("useGeneratedKeys",
configuration.isUseGeneratedKeys() && SqlCommandType.INSERT.equals(sqlCommandType))
? Jdbc3KeyGenerator.INSTANCE : NoKeyGenerator.INSTANCE;
}
SqlSource sqlSource = langDriver.createSqlSource(configuration, context, parameterTypeClass);
StatementType statementType = StatementType.valueOf(context.getStringAttribute("statementType", StatementType.PREPARED.toString()));
Integer fetchSize = context.getIntAttribute("fetchSize");
Integer timeout = context.getIntAttribute("timeout");
String parameterMap = context.getStringAttribute("parameterMap");
String resultType = context.getStringAttribute("resultType");
Class<?> resultTypeClass = resolveClass(resultType);
String resultMap = context.getStringAttribute("resultMap");
String resultSetType = context.getStringAttribute("resultSetType");
ResultSetType resultSetTypeEnum = resolveResultSetType(resultSetType);
if (resultSetTypeEnum == null) {
resultSetTypeEnum = configuration.getDefaultResultSetType();
}
String keyProperty = context.getStringAttribute("keyProperty");
String keyColumn = context.getStringAttribute("keyColumn");
String resultSets = context.getStringAttribute("resultSets");
builderAssistant.addMappedStatement(id, sqlSource, statementType, sqlCommandType,
fetchSize, timeout, parameterMap, parameterTypeClass, resultMap, resultTypeClass,
resultSetTypeEnum, flushCache, useCache, resultOrdered,
keyGenerator, keyProperty, keyColumn, databaseId, langDriver, resultSets);
}
}
public class SqlSessionFactoryBuilder {
public SqlSessionFactory build(InputStream inputStream, String environment, Properties properties) {
try {
// 读取配置文件
XMLConfigBuilder parser = new XMLConfigBuilder(inputStream, environment, properties);
// 解析配置文件得到 Configuration 对象，然后用其创建 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.
}
}
}
public SqlSessionFactory build(Configuration config) {
return new DefaultSqlSessionFactory(config);
}
}
```

1113
docs/LearningExperience/DesignPattern/从Spring及Mybatis框架源码中学习设计模式(结构型).md
View File

File diff suppressed because it is too large Load Diff

1075
docs/LearningExperience/DesignPattern/从Spring及Mybatis框架源码中学习设计模式(行为型).md
View File

File diff suppressed because it is too large Load Diff

6
docs/LearningExperience/DesignPattern/从框架源码中学习设计模式.md
Unescape View File

@ -1,6 +0,0 @@
本文用于总结阅读过的框架中，所使用过的设计模式，结合实际生成中的源码，重新理解设计模式。
努力编写中...

5
docs/Spring/SpringTransaction/Spring事务处理器的设计与实现.md → docs/LearningExperience/DesignPattern/从框架源码中学习设计模式的感悟.md
Unescape View File

@ -1 +1,6 @@
努力编写中...

13
docs/LearningExperience/DesignPattern/设计模式.md
Unescape View File

@ -1,13 +0,0 @@
## 六大原则
1. 单一职责：一个类只负责唯一一项职责
2. 依赖倒置：即面向接口编程，系统的高层模块（顶层接口、顶层抽象类等）不应该依赖底层模块（具体实现类），当需求发生变化时，对外接口不变，只要提供新的实现类即可。
3. 接口隔离：尽量设计出功能单一的接口，避免实现类实现很多不必要的接口方法
4. **开放-封闭：对扩展开放，对修改关闭**，本原则是设计模式的终极目标
5. 迪米特法则：尽量减少类之间的耦合性
6. 里氏替换：继承体系的设计要合理
## 装饰器模式

847
docs/LearningExperience/EncodingSpecification/一个程序员的自我修养.md
Unescape View File

@ -0,0 +1,847 @@
本文用于总结《阿里Java开发手册》、《用友技术review手册》及个人Java开发工作经验，并结合这半年来的源码阅读经验进行编写。回顾那些写过的和读过的代码，回顾自己。
## 第一章 基础编码规范
### 1.1 命名规范
- 代码中的命名均不能以下划线或美元符号开始，也不能以下划线或美元符号结束。
tips：JDK动态代理生成的代理类 类名使用了\$符号开头，如\$Proxy1。
- 代码中的命名严禁使用拼音与英文混合的方式，更不允许直接使用中文的方式。
tips：正确的英文拼写和语法可以让阅读者易于理解，避免歧义。注意，即使纯拼音命名方式也要避免采用。alibaba，yonyou，Beijing等国际通用的名称，可视同英文。
在我们的财务相关模块的工程代码及数据库表设计中，可以看到一些拼音首字母缩写的命名方式，如：arap_djzb，arap是“应收应付”的英文缩写，djzb是“单据主表”的汉语拼音首字母，zdr、shr、lrr都是汉语拼音首字母缩写。当然，这些都是历史包袱，经历了这么多年的代码积累，很难从底层去修正咯，但在自己的实际编码中要以史为鉴，让自己的代码更加优雅规范，这也是同事是否尊重你的重要考量之一。
- 类名使用UpperCamelCase——大驼峰风格，但以下情形例外: DO / BO / DTO/ VO / AO /
PO / UID等。
tips：合理的类名后缀能够让我们在开发中快速地找到自己想要的代码，想看某个业务层就ctrl + shift + T搜索“XXXBO”，想看某展示层代码 就搜索“XXXVO”。
- 抽象类命名使用 Abstract 或 Base 开头；异常类命名使用 Exception 结尾；测试类命名以它要测试的类的名称开始，以 Test 结尾。
例如：Spring框架的AbstractApplicationContext和Mybatis框架的BaseExecutor都是抽象类。
- 方法名、参数名、成员变量、局部变量都统一使用lowerCamelCase——小驼峰风格。
- 常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长。
tips：实际编码中，有时确实会嫌某常量名太长，不便于使用。以后应该在语义完整清楚的情况下再考虑尽量缩短名称长度。
- 类型与中括号紧挨相连来表示数组。
正例：定义整形数组 int[] arrayDemo；
反例：在 main 参数中，使用 String args[]来定义。
- POJO 类中布尔类型的变量，都不要加 is 前缀，否则部分框架解析会引起序列化错误。
反例：定义为基本数据类型 Boolean isDeleted 的属性，它的方法也是 isDeleted()，RPC框架在反向解析的时候，“误以为”对应的属性名称是 deleted，导致属性获取不到，进而抛出异常。
tips：我们的VO类中有很多is开头的Boolean类型变量，如：DJZBHeaderVO中的isjszxzf（是否结算中心支付）字段。
- 包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用 单数形式，但是类名如果有复数含义，类名可以使用复数形式。
正例：应用工具类包名为 com.alibaba.ai.util、类名为 MessageUtils（此规则参考 spring 的框架结构）
- 杜绝完全不规范的缩写，避免望文不知义。
反例：AbstractClass“缩写”命名成 AbsClass；condition“缩写”命名成 condi，此类随 意缩写严重降低了代码的可阅读性。
- 为了达到代码自解释的目标，任何自定义编程元素在命名时，使用尽量完整的单词 组合来表达其意。
正例：在 JDK 中，表达原子更新的类名为：AtomicReferenceFieldUpdater。
反例：变量 int a 的随意命名方式。
- 如果模块、接口、类、方法使用了设计模式，在命名时需体现出具体模式。
tips：将设计模式体现在名字中，有利于阅读者快速理解架构设计理念。 如：Spring框架的BeanFactory（工厂模式）、JdkDynamicAopProxy（JDK动态代理模式）。
- 接口类中的方法和属性不要加任何修饰符号（public 也不要加），保持代码的简洁性，并加上有效的 Javadoc 注释。尽量不要在接口里定义变量，如果一定要定义变量，肯定是与接口方法相关，并且是整个应用的基础常量。
正例：接口方法签名 void commit();
接口基础常量 String COMPANY = "alibaba";
反例：接口方法定义 public abstract void f();
说明：JDK8 中接口允许有默认实现，那么这个 default 方法，是对所有实现类都有价值的默认实现。
- 接口和实现类的命名有两套规则：
【强制】对于 Service 和 DAO 类，基于 SOA 的理念，暴露出来的服务一定是接口，内部 的实现类用 Impl 的后缀与接口区别。
正例：CacheServiceImpl 实现 CacheService 接口。
【推荐】 如果是形容能力的接口名称，取对应的形容词为接口名（通常是–able 的形式）。
正例：AbstractTranslator 实现 Translatable 接口。
- 枚举类名建议带上 Enum 后缀，枚举成员名称需要全大写，单词间用下划线隔开。
说明：枚举其实就是特殊的类，域成员均为常量，且构造方法被默认强制是私有。
正例：枚举名字为 ProcessStatusEnum 的成员名称：SUCCESS / UNKNOWN_REASON。
- 各层命名规约：
A) Service/DAO 层方法命名规约
1） 获取单个对象的方法用 get 做前缀。
2） 获取多个对象的方法用 list 做前缀，复数形式结尾如：listObjects。
3） 获取统计值的方法用 count 做前缀。
4） 插入的方法用 save/insert 做前缀。
5） 删除的方法用 remove/delete 做前缀。
6） 修改的方法用 update 做前缀。
B) 领域模型命名规约
1） 数据对象：xxxDO，xxx 即为数据表名。
2） 数据传输对象：xxxDTO，xxx 为业务领域相关的名称。
3） 展示对象：xxxVO，xxx 一般为网页名称。
4） POJO 是 DO/DTO/BO/VO 的统称，禁止命名成 xxxPOJO。
### 1.2 常量定义
- 不允许任何魔法值（意义不明的变量 / 常量）直接出现在代码中。
反例：
String key = "Id#taobao_" + tradeId;
cache.put(key, value);
- 在 long 或者 Long 赋值时，数值后使用大写的 L，不能是小写的 l，小写容易跟数字 1 混淆，造成误解。
说明：Long a = 2l; 写的是数字的 21，还是 Long 型的 2?
- 不要使用一个常量类维护所有常量，要按常量功能进行归类，分开维护。
说明：大而全的常量类，杂乱无章，使用查找功能才能定位到修改的常量，不利于理解和维护。
正例：缓存相关常量放在类 CacheConsts 下；系统配置相关常量放在类 ConfigConsts 下。
- 常量的复用层次有五层：跨应用共享常量、应用内共享常量、子工程内共享常量、包内共享常量、类内共享常量。
1）跨应用共享常量：放置在二方库中，通常是 client.jar 中的 constant 目录下。
2）应用内共享常量：放置在一方库中，通常是子模块中的 constant 目录下。
反例：易懂变量也要统一定义成应用内共享常量，两位攻城师在两个类中分别定义了表示 “是” 的变量。
类 A 中：public static final String YES = "yes"；
类 B 中：public static final String YES = "y"；
A.YES.equals(B.YES)，预期是 true，但实际返回为 false，导致线上问题。
3）子工程内部共享常量：即在当前子工程的 constant 目录下。
4）包内共享常量：即在当前包下单独的 constant 目录下。
5）类内共享常量：直接在类内部 private static final 定义。
- 如果变量值仅在一个固定范围内变化用 enum 类型来定义。
说明：如果存在名称之外的延伸属性应使用 enum 类型，下面正例中的数字就是延伸信息，表示一年中的第几个季节。
正例：
```java
public enum SeasonEnum {
SPRING(1), SUMMER(2), AUTUMN(3), WINTER(4);
private int seq;
SeasonEnum(int seq){
this.seq = seq;
}
}
```
### 1.3 代码格式
代码格式无非就是一些空格、换行、缩进的问题，没必要死记，直接用开发工具（eclipse、IDEA）format一下即可，省时省力。
### 1.4 OOP 规约
- 避免通过一个类的对象引用访问此类的静态变量或方法，增加编译器解析成本。
- 所有的覆写方法，必须加@Override 注解。
说明：getObject()与 get0bject()的问题。一个是字母的 O，一个是数字的 0，加@Override 可以准确判断是否覆盖成功。另外，如果在抽象类中对方法签名（由方法名、参数的类型及**顺序** 确定唯一的方法签名）进行修改，其实现类会马上编译报错。
- 相同参数类型，相同业务含义，才可以使用 Java 的可变参数，避免使用 Object。
说明：可变参数必须放置在参数列表的最后。（能用数组的就不要使用可变参数编程，可变参数在编译时会被编译成数组类型。可变参数能兼容数组类参数，但是数组类参数却无法兼容可变参数。可变参数类型必须作为参数列表的最后一项，且不能放在定长参数的前面。）
正例：public List<User> listUsers(String type, Long... ids) {...}
- 外部正在调用或者二方库依赖的接口，不允许修改方法签名，避免对接口调用方产生影响。接口过时必须加@Deprecated 注解，并清晰地说明采用的新接口或者新服务是什么。
tips：
一方库：本工程范围内，各个模块和包之间的相互依赖。
二方库：引入的同一个公司内部的其他工程。
三方库：公司以外的其他依赖，比如apache，google等。
- 不能使用过时的类或方法。
说明：java.net.URLDecoder 中的方法 decode(String encodeStr) 这个方法已经过时，应该使用双参数 decode(String source, String encode)。接口提供方既然明确是过时接口， 那么有义务同时提供新的接口；作为调用方来说，有义务去考证过时方法的新实现是什么。
- Object 的 equals 方法容易抛空指针异常，应使用常量或确定有值的对象来调用 equals。
正例："test".equals(object);
反例：object.equals("test");
说明：推荐使用 java.util.Objects#equals（JDK7 引入的工具类）。**个人认为，当要比较两个不确定的对象时，可以考虑使用这个类，如果只是想确定某个对象是否为目标值，使用上面的方法并不差**。
- 所有的相同类型的包装类对象之间值的比较，全部使用 equals() 方法比较。
说明：对于 Integer var = ? 在-128 至 127 范围内的赋值，Integer 对象是在 IntegerCache.cache 产生，会复用已有对象，这个区间内的 Integer 值可以直接使用 == 进行判断，但是这个区间之外的所有数据，都会在堆上产生，并不会复用已有对象，这是一个大坑， 推荐使用 equals() 方法进行判断。
- 关于基本数据类型与包装数据类型的使用标准如下：
1）【强制】所有的 POJO 类属性必须使用包装数据类型。
2）【强制】RPC 方法的返回值和参数必须使用包装数据类型。
3）【推荐】所有的局部变量使用基本数据类型。
说明：POJO 类属性没有初值是提醒使用者在需要使用时，必须自己显式地进行赋值，任何 NPE 问题，或者入库检查，都由使用者来保证。
正例：数据库的查询结果可能是 null，因为自动拆箱，用基本数据类型接收有 NPE 风险。(不是很理解这个结论，ResultSet.getInt()等方法获得的是基本数据类型，ORM映射时怎么就拆箱咯？)
反例：比如显示成交总额涨跌情况，即正负 x%，x 为基本数据类型，调用的 RPC 服务，调用不成功时，返回的是默认值，页面显示为 0%，这是不合理的，应该显示成中划线。所以包装数据类型的 null 值，能够表示额外的信息，如：远程调用失败，异常退出。
- 定义 DO/DTO/VO 等 POJO 类时，不要设定任何属性默认值。
反例：POJO 类的 gmtCreate 默认值为 new Date()，但是这个属性在数据提取时并没有置入具 体值，在更新其它字段时又附带更新了此字段，导致创建时间被修改成当前时间。
- 序列化类新增属性时，请不要修改 serialVersionUID 字段，避免反序列化失败；如果完全不兼容升级，避免反序列化混乱，那么请修改 serialVersionUID 值。
说明：注意 serialVersionUID 不一致会抛出序列化运行时异常。
- **构造方法里面禁止加入任何业务逻辑，如果有初始化逻辑，请放在 init() 方法中。**
在很多client端的代码中有看到这种编码方式。
- POJO 类必须写 toString() 方法。使用 IDE 中的工具：source -> generate toString() 时，如果继承了另一个 POJO 类，注意在前面加一下 super.toString()。
说明：在方法执行抛出异常时，可以直接调用 POJO 的 toString()方法打印其属性值，便于排查问题。
- 当一个类有多个构造方法，或者多个同名方法，这些方法应该按顺序放置在一起， 便于阅读。
- 类内方法定义的顺序依次是：公有方法或保护方法 > 私有方法 > getter/setter 方法。
说明：公有方法是类的调用者和维护者最关心的方法，首屏展示最好；保护方法虽然只是子类 关心，也可能是“模板设计模式”下的核心方法；而私有方法外部一般不需要特别关心，是一个 黑盒实现；因为承载的信息价值较低，所有 Service 和 DAO 的 getter/setter 方法放在类体 最后。
- setter 方法中，参数名称与类成员变量名称一致，this.成员名 = 参数名。在 getter/setter 方法中，不要增加业务逻辑，增加排查问题的难度。
- 循环体内，字符串的连接方式，使用 StringBuilder 的 append 方法进行扩展。
- final 可以声明类、成员变量、方法、以及本地变量，下列情况使用 final 关键字：
1） 不允许被继承的类，如：String 类。
2） 不允许修改引用的域对象。
3） 不允许被重写的方法，如：POJO 类的 setter 方法。
4） **不允许运行过程中重新赋值的局部变量**，可以看到有些方法的形参中使用了final修饰。
5） 避免上下文重复使用一个变量，使用 final 描述可以强制重新定义一个变量，方便更好 地进行重构。
- 慎用 Object 的 clone 方法来拷贝对象。
说明：对象的 clone 方法默认是浅拷贝，若想实现深拷贝需要重写 clone 方法实现域对象的 深度遍历式拷贝。
- **类成员与方法访问控制从严**（合理使用Java的访问修饰符）：
1） 如果不允许外部直接通过 new 来创建对象，那么构造方法必须是 private。
2） 工具类不允许有 public 或 default 构造方法。
3） 类非 static 成员变量并且与子类共享，必须是 protected。
4） 类非 static 成员变量并且仅在本类使用，必须是 private。
5） 类 static 成员变量如果仅在本类使用，必须是 private。
6） 若是 static 成员变量，考虑是否为 final。
7） 类成员方法只供类内部调用，必须是 private。
8） 类成员方法只对继承类公开，那么限制为 protected。 说明：任何类、方法、参数、变量，严控访问范围。过于宽泛的访问范围，不利于模块解耦。
思考：如果是一个 private 的方法，想删除就删除，可是一个 public 的 service 成员方法或成员变量，删除一下，不得手心冒点汗吗？变量像自己的小孩，尽量在自己的视线内，变量作 用域太大，无限制的到处跑，那么你会担心的。
### 1.5 集合处理
- 关于 hashCode 和 equals 的处理，遵循如下规则：
1） 只要重写 equals，就必须重写 hashCode。
2） 因为 Set 存储的是不重复的对象，依据 hashCode 和 equals 进行判断，所以 Set 存储的 对象必须重写这两个方法。
3） 如果自定义对象作为 Map 的键，那么必须重写 hashCode 和 equals。
说明：String 重写了 hashCode 和 equals 方法，所以我们可以非常愉快地使用 String 对象 作为 key 来使用。
- ArrayList的subList结果不可强转成ArrayList，否则会抛出ClassCastException 异常，即java.util.RandomAccessSubList cannot be cast to java.util.ArrayList。
说明：subList 返回的是 ArrayList 的内部类 SubList，并不是 ArrayList 而是 ArrayList 的一个视图，对于 SubList 子列表的所有操作最终会反映到原列表上。
- 在 subList 场景中，高度注意对原集合元素的增加或删除，均会导致子列表的遍历、 增加、删除产生 ConcurrentModificationException 异常。
- 使用集合转数组的方法，必须使用集合的 toArray(T[] array)方法，传入的是类型完全一样的数组，大小就是 list.size()。
说明：使用 toArray 带参方法，入参分配的数组空间不够大时，toArray 方法内部将重新分配 内存空间，并返回新数组地址；如果数组元素个数大于实际所需，下标为[ list.size() ] 的数组元素将被置为 null，其它数组元素保持原值，因此最好将方法入参数组大小定义与集 合元素个数一致。
```java
// 正例：
List<String> list = new ArrayList<String>(2);
list.add("guan");
list.add("bao");
String[] array = new String[list.size()];
array = list.toArray(array);
// 反例：直接使用 toArray 无参方法存在问题，此方法返回值只能是 Object[]类，
// 若强转其它 类型数组将出现 ClassCastException 错误。
// 这是我平时的写法，初始化一个list.size()大小的数组似乎效率更好一些，如果数组的容量
// 比list小，原来的数组对象不会被使用，浪费系统资源
String[] strs = list.toArray(new String[0]);
```
- 使用工具类 Arrays.asList()把数组转换成集合时，不能使用其修改集合相关的方法，它的add/remove/clear 方法会抛出 UnsupportedOperationException 异常。
说明：asList() 的返回对象是一个 Arrays 的内部类ArrayList（而不是java.util.ArrayList），该内部类 并没有实现集合的修改/删除等方法。Arrays.asList 体现的是适配器模式，只是转换接口，后台的数据仍是数组。
```java
String[] str = new String[] { "you", "wu" };
List list = Arrays.asList(str);
第一种情况：list.add("yangguanbao"); 运行时异常。
第二种情况：str[0] = "gujin"; 那么 list.get(0)也会随之修改。
```
- 泛型通配符<? extends T>来接收返回的数据，此写法的泛型集合不能使用 add() 方 法，而<? super T>不能使用 get() 方法，作为接口调用赋值时易出错。
```java
// <? extends T>:上界通配符(Upper Bounds Wildcards）
// <? super T>:下界通配符(Lower Bounds Wildcards)
List<? extends C> list1; // list1 的元素的类型只能是 C 和 C 的子类。
List<? super C> list2; // list2 的元素的类型只能是 C 和 C 的父类。
// 简单来说就是 <? extends C> 上界为 C 类型范围粗略理解为 [C,+∞)，
// 不允许添加除 null 的元素，获取的元素类型是 C ；
// <? super C> 下界为 C 类型范围粗略理解为 (-∞,C]，允许添加 C 以及 C 的子类类型元素，
// 获取的元素类型是 Object
// 扩展说一下 PECS(Producer Extends Consumer Super)原则。
// 第一、频繁往外读取内容的，适合用<? extends T>。
// 第二、经常往里插入的，适合用<? super T>。
```
- 不要在 foreach 循环里进行元素的 remove/add 操作。remove 元素请使用 Iterator 方式，如果并发操作，需要对 Iterator 对象加锁。
```java
// 正例：
List<String> list = new ArrayList<>();
list.add("1");
list.add("2");
Iterator<String> iterator = list.iterator();
while (iterator.hasNext()) {
String item = iterator.next();
if (删除元素的条件) {
iterator.remove();
}
}
// 反例：对比ArrayList的remove()和Iterator的remove()方法，可以找到其中的坑。
for (String item : list) {
if ("1".equals(item)) {
list.remove(item);
}
}
```
- 在 JDK7 版本及以上，Comparator 实现类要满足如下三个条件，不然 Arrays.sort()， Collections.sort() 会报 IllegalArgumentException 异常。
说明：三个条件如下 1） x，y 的比较结果和 y，x 的比较结果相反。 2） x>y，y>z，则 x>z。 3） x=y，则 x，z 比较结果和 y，z 比较结果相同。
```java
// 反例：下例中没有处理相等的情况，实际使用中可能会出现异常：
new Comparator<Student>() {
@Override
public int compare(Student o1, Student o2) {
return o1.getId() > o2.getId() ? 1 : -1;
}
};
```
- 集合泛型定义时，在 JDK7 及以上，使用 diamond 语法或全省略。
说明：菱形泛型，即 diamond，直接使用<>来指代前边已经指定的类型。
```java
// 正例：
// <> diamond 方式
HashMap<String, String> userCache = new HashMap<>(16);
// 全省略方式
ArrayList<User> users = new ArrayList(10);
```
- 集合初始化时，指定集合初始值大小。
说明：HashMap 使用 HashMap(int initialCapacity) 初始化。
正例：initialCapacity = (需要存储的元素个数 / 负载因子) + 1。注意负载因子（即loader factor）默认为 0.75，如果暂时无法确定初始值大小，请设置为 16（即默认值）。
反例：HashMap 需要放置 1024 个元素，由于没有设置容量初始大小，随着元素不断增加，容量 7 次被迫扩大，resize() 需要重建 hash 表，严重影响性能。
- 使用 entrySet 遍历 Map 类集合 K-V，而不是 keySet 方式进行遍历。
说明：keySet 其实是遍历了 2 次，一次是转为 Iterator 对象，另一次是从 hashMap 中取出 key 所对应的 value。而 entrySet 只是遍历了一次就把 key 和 value 都放到了 entry 中，效率更高。如果是 JDK8，使用 Map.foreach() 方法。
正例：values()返回的是 V 值集合，是一个 list 集合对象；keySet()返回的是 K 值集合，是 一个 Set 集合对象；entrySet()返回的是 K-V 值组合集合。
```java
// 创建一个Map
Map<String, Object> infoMap = new HashMap<>();
infoMap.put("name", "Zebe");
infoMap.put("site", "www.zebe.me");
infoMap.put("email", "zebe@vip.qq.com");
// 传统的Map迭代方式
for (Map.Entry<String, Object> entry : infoMap.entrySet()) {
System.out.println(entry.getKey() + "：" + entry.getValue());
}
// JDK8的迭代方式
infoMap.forEach((key, value) -> {
System.out.println(key + "：" + value);
});
```
- 高度注意 Map 类集合 K-V 能不能存储 null 值的情况，如下表格：
集合类 | Key | Value | Super | 说明
-|-|-|-|-
HashMap | **允许为 null** | **允许为 null** | AbstractMap | 线程不安全
ConcurrentHashMap | 不允许为 null | 不允许为 null | AbstractMap| 锁分段技术（JDK8:CAS）
Hashtable | 不允许为 null | 不允许为 null | Dictionary | 线程安全
TreeMap | 不允许为 null | **允许为 null** | AbstractMap | 线程不安全
反例： 由于 HashMap 的干扰，很多人认为 ConcurrentHashMap 是可以置入 null 值，而事实上， 存储 null 值时会抛出 NPE 异常。
- 合理利用好集合的有序性(sort)和稳定性(order)，避免集合的无序性(unsort)和不稳定性(unorder)带来的负面影响。
说明：有序性是指遍历的结果是按某种比较规则依次排列的。稳定性指集合每次遍历的元素次序是一定的。如：ArrayList 是 order/unsort；HashMap 是 unorder/unsort；TreeSet 是 order/sort。
- 利用 Set 元素唯一的特性，可以快速对一个集合进行去重操作，避免使用 List 的 contains 方法进行遍历、对比、去重操作。
### 1.6 并发处理
- 获取单例对象需要保证线程安全，其中的方法也要保证线程安全。
说明：资源驱动类、工具类、单例工厂类都需要注意。
- 创建线程或线程池时请指定有意义的线程名称，方便出错时回溯。
```java
// 正例：
public class TimerTaskThread extends Thread {
public TimerTaskThread() {
super.setName("TimerTaskThread");
...
}
}
```
- 线程资源必须通过线程池提供，不允许在应用中自行显式创建线程。
说明：使用线程池的好处是减少在创建和销毁线程上所消耗的时间以及系统资源的开销，解决资源不足的问题。如果不使用线程池，有可能造成系统创建大量同类线程而导致消耗完内存或者“过度切换”的问题。
tips:我们的代码中的很多线程都是自行显式创建的，很少见到通过线程池进行统一管理的。
- 线程池不允许使用 Executors 去创建，而是通过 ThreadPoolExecutor 的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险。
说明：Executors 返回的线程池对象的弊端如下：
1）FixedThreadPool 和 SingleThreadPool: 允许的请求队列长度为 Integer.MAX_VALUE，可能会堆积大量的请求，从而导致 OOM。
2）CachedThreadPool 和 ScheduledThreadPool: 允许的创建线程数量为 Integer.MAX_VALUE，可能会创建大量的线程，从而导致 OOM。
- SimpleDateFormat 是线程不安全的类，一般不要定义为 static 变量，如果定义为 static，必须加锁，或者使用 DateUtils 工具类。
```java
// 正例：注意线程安全，使用 DateUtils。亦推荐如下处理：
private static final ThreadLocal<DateFormat> df = new ThreadLocal<DateFormat>() {
@Override
protected DateFormat initialValue() {
return new SimpleDateFormat("yyyy-MM-dd");
}
};
// 说明：如果是 JDK8 的应用，可以使用 Instant 代替 Date，LocalDateTime 代替 Calendar，
// DateTimeFormatter 代替 SimpleDateFormat，
// 官方给出的解释：simple beautiful strong immutable thread-safe。
```
- 高并发时，同步调用应该去考量锁的性能损耗。能用无锁数据结构，就不要用锁；能锁区块，就不要锁整个方法体；能用对象锁，就不要用类锁。
说明：尽可能使加锁的代码块工作量尽可能的小，**避免在锁代码块中调用 RPC 方法**。
- **对多个资源、数据库表、对象同时加锁时，需要保持一致的加锁顺序**，否则可能会造成死锁。
说明：线程一需要对表 A、B、C 依次全部加锁后才可以进行更新操作，那么线程二的加锁顺序也必须是 A、B、C，否则可能出现死锁。
- 并发修改同一记录时，避免更新丢失，需要加锁。要么在应用层加锁，要么在缓存加锁，要么在数据库层使用乐观锁，使用 version 作为更新依据。
说明：如果每次访问冲突概率小于 20%，推荐使用乐观锁，否则使用悲观锁。乐观锁的重试次数不得小于 3 次。
- 多线程并行处理定时任务时，Timer 运行多个 TimeTask 时，只要其中之一没有捕获抛出的异常，其它任务便会自动终止运行，使用 ScheduledExecutorService 则没有这个问题。
- 使用 CountDownLatch 进行异步转同步操作，每个线程退出前必须调用 countDown 方法，线程执行代码注意 catch 异常，确保 countDown 方法被执行到，避免主线程无法执行至 await 方法，直到超时才返回结果。
说明：注意，子线程抛出异常堆栈，不能在主线程 try-catch 到。
- 避免 Random 实例被多线程使用，虽然共享该实例是线程安全的，但会因竞争同一 seed 导致的性能下降。
说明：Random 实例包括 java.util.Random 的实例或者 Math.random()的方式。
正例：在 JDK7 之后，可以直接使用 API ThreadLocalRandom，而在 JDK7 之前，需要编码保证每个线程持有一个实例。
- 在并发场景下，通过双重检查锁（double-checked locking）实现延迟初始化的优化问题隐患(指令重排会导致 双检锁失效，产生隐患)(可参考 The "Double-Checked Locking is Broken" Declaration)，推荐解决方案中较为简单一种（适用于 JDK5 及以上版本），将目标属性声明为 volatile 型。
```java
// 反例：
class LazyInitDemo {
private Helper helper = null;
public Helper getHelper() {
if (helper == null)
synchronized(this) {
if (helper == null)
helper = new Helper();
}
return helper;
}
// other methods and fields...
}
```
- volatile 解决多线程内存不可见问题。对于一写多读，是可以解决变量同步问题， 但是如果多写，同样无法解决线程安全问题。
```java
// 如果是 count++操作，使用如下类实现：
AtomicInteger count = new AtomicInteger();
count.addAndGet(1);
// 如果是 JDK8，推 荐使用 LongAdder 对象，比 AtomicLong 性能更好（减少乐观锁的重试次数）。
```
- HashMap 在容量不够进行 resize 时由于高并发可能出现死链，导致 CPU 飙升，在开发过程中可以使用其它数据结构或加锁来规避此风险。
- ThreadLocal 无法解决共享对象的更新问题，ThreadLocal 对象建议使用 static 修饰。这个变量是针对一个线程内所有操作共享的，所以设置为静态变量，所有此类实例共享此静态变量 ，也就是说在类第一次被使用时装载，只分配一块存储空间，所有此类的对象(只要是这个线程内定义的)都可以操控这个变量。
### 1.7 控制语句
- 在一个 switch 块内，每个 case 要么通过 break/return 等来终止，要么注释说明程序将继续执行到哪一个 case 为止；在一个 switch 块内，都必须包含一个 default 语句并且放在最后，即使空代码。
- 在 if/else/for/while/do 语句中必须使用大括号，即使只有一行代码。
- 在高并发场景中，避免使用“等于”判断作为中断或退出的条件。
说明：如果并发控制没有处理好，容易产生等值判断被“击穿”的情况，使用大于或小于的区间判断条件来代替。
反例：判断剩余奖品数量等于 0 时，终止发放奖品，但因为并发处理错误导致奖品数量瞬间变成了负数，这样的话，活动无法终止。
- 表达异常的分支时，少用 if-else 方式，这种方式可以改写成：
```java
if (condition) {
...
return obj;
}
// 接着写 else 的业务逻辑代码;
// 说明：如果非得使用 if()...else if()...else...方式表达逻辑，【强制】避免后续代码维护困难，
// 请勿超过 3 层。
// 正例：超过 3 层的 if-else 的逻辑判断代码可以使用卫语句、策略模式、状态模式等来实现，其中卫语句示例如下：
public void today() {
if (isBusy()) {
System.out.println(“change time.”);
return;
}
if (isFree()) {
System.out.println(“go to travel.”);
return;
}
System.out.println(“stay at home to learn Alibaba Java Coding Guidelines.”);
return;
}
```
- 除常用方法（如 getXxx/isXxx）等外，不要在条件判断中执行其它复杂的语句，将复杂逻辑判断的结果赋值给一个有意义的布尔变量名，以提高可读性。
说明：很多 if 语句内的逻辑相当复杂，阅读者需要分析条件表达式的最终结果，才能明确什么样的条件执行什么样的语句，那么，如果阅读者分析逻辑表达式错误呢？
```java
// 正例：
// 伪代码如下
final boolean existed = (file.open(fileName, "w") != null) && (...) || (...);
if (existed) {
...
}
// 反例：在我们的代码中可以看到很多这种把复杂冗长的逻辑判断写在if语句中的
if ((file.open(fileName, "w") != null) && (...) || (...)) {
...
}
```
- **循环体中的语句要考量性能**，以下操作尽量移至循环体外处理，如：定义对象、变量、 获取数据库连接，进行不必要的 try-catch 操作（这个 try-catch 是否可以移至循环体外）。
- 避免采用取反逻辑运算符。
说明：取反逻辑不利于快速理解，并且取反逻辑写法必然存在对应的正向逻辑写法。
正例：使用 if (x < 628) 来表达 x 小于 628。
反例：使用 if (!(x >= 628)) 来表达 x 小于 628。
- 接口入参保护(即，参数校验)，这种场景常见的是用作批量操作的接口。
- 下列情形，需要进行参数校验：
1） 调用频次低的方法。
2） 执行时间开销很大的方法。此情形中，参数校验时间几乎可以忽略不计，但如果因为参数错误导致中间执行回退，或者错误，那得不偿失。
3） 需要极高稳定性和可用性的方法。
4） 对外提供的开放接口，不管是 RPC/API/HTTP 接口。
5） 敏感权限入口。
- 下列情形，不需要进行参数校验：
1） 极有可能被循环调用的方法。但在方法说明里必须注明外部参数检查要求。
2） 底层调用频度比较高的方法。毕竟是像纯净水过滤的最后一道，参数错误不太可能到底层才会暴露问题。一般 DAO 层与 Service 层都在同一个应用中，部署在同一台服务器中，所以 DAO 的参数校验，可以省略。
3） 被声明成 private 只会被自己代码所调用的方法，如果能够确定调用方法的代码传入参数已经做过检查或者肯定不会有问题，此时可以不校验参数。
### 1.8 注释规约
注释感觉是我们代码规范的重灾区咯，也是大家最容易忽略的地方。
- 类、类属性、类方法的注释必须使用 Javadoc 规范，使用/** 内容 */格式，不得使用 // xxx 方式。 说明：在 IDE 编辑窗口中，Javadoc 方式会提示相关注释，生成 Javadoc 可以正确输出相应注 释；在 IDE 中，工程调用方法时，不进入方法即可悬浮提示方法、参数、返回值的意义，提高阅读效率。
- 所有的抽象方法（包括接口中的方法）必须要用 Javadoc 注释、除了返回值、参数、 异常说明外，还必须指出该方法做什么事情，实现什么功能。
说明：对子类的实现要求，或者调用注意事项，请一并说明。
- 所有的类都必须添加创建者和创建日期。
- 方法内部单行注释，在被注释语句上方另起一行，使用 // 注释。方法内部多行注释 使用 /* */ 注释，注意与代码对齐。
- 所有的枚举类型字段必须要有注释，说明每个数据项的用途。
- 与其用“半吊子”英文来注释，不如用中文注释把问题说清楚。专有名词与关键字保持英文原文即可。
反例：“TCP 连接超时” 解释成 “传输控制协议连接超时”，理解反而费脑筋。
- 代码修改的同时，注释也要进行相应的修改，尤其是参数、返回值、异常、核心逻辑等的修改。
说明：代码与注释更新不同步，就像路网与导航软件更新不同步一样，如果导航软件严重滞后， 就失去了导航的意义。
- 谨慎注释掉代码。在上方详细说明，而不是简单地注释掉。如果无用，则删除。
说明：代码被注释掉有两种可能性。
1）后续会恢复此段代码逻辑。
2）永久不用。前者如果没有备注信息，难以知晓注释动机。后者建议直接删掉（代码仓库保存了历史代码）。
- 对于注释的要求：
第一、能够准确反应设计思想和代码逻辑；
第二、能够描述业务含义，使别的程序员能够迅速了解到代码背后的信息。完全没有注释的大段代码对于阅读者形同天书，注释是给自己看的，即使隔很长时间，也能清晰理解当时的思路；注释也是给继任者看的，使其能够快速接替自己的工作。
- 好的命名、代码结构是自解释的，注释力求精简准确、表达到位。避免出现注释的一个极端：过多过滥的注释，代码的逻辑一旦修改，修改注释是相当大的负担。
```java
// 反例：
// put elephant into fridge
put(elephant, fridge);
// 方法名 put，加上两个有意义的变量名 elephant 和 fridge，已经说明了这是在干什么，
// 语义清晰的代码不需要额外的注释。
```
- 特殊注释标记，请注明标记人与标记时间。注意及时处理这些标记，通过标记扫描， 经常清理此类标记。线上故障有时候就是来源于这些标记处的代码。
1） 待办事宜（TODO）:（ 标记人，标记时间，[预计处理时间] ）
表示需要实现，但目前还未实现的功能。这实际上是一个 Javadoc 的标签，目前的 Javadoc 还没有实现，但已经被广泛使用。只能应用于类，接口和方法（因为它是一个 Javadoc 标签）。
2） 错误，不能工作（FIXME）:（ 标记人，标记时间，[预计处理时间] ）
在注释中用 FIXME 标记某代码是错误的，而且不能工作，需要及时纠正的情况。
### 1.9 其它
- 在使用正则表达式时，利用好其预编译功能，可以有效加快正则匹配速度。
说明：不要在方法体内定义：Pattern pattern = Pattern.compile(“规则”);
- velocity 调用 POJO 类的属性时，建议直接使用属性名取值即可，模板引擎会自动按规范调用 POJO 的 getXxx()，如果是 boolean 基本数据类型变量（boolean 命名不需要加 is 前缀），会自动调用isXxx()方法。
说明：注意如果是 Boolean 包装类对象，优先调用 getXxx()的方法。
- 注意 Math.random() 这个方法返回是 double 类型，注意取值的范围 0≤x<1（能够 取到零值，注意除零异常），如果想获取整数类型的随机数，不要将 x 放大 10 的若干倍然后取整，直接使用 Random 对象的 nextInt 或者 nextLong 方法。
- 获取当前毫秒数 System.currentTimeMillis(); 而不是 new Date().getTime();
说明：如果想获取更加精确的纳秒级时间值，使用 System.nanoTime()的方式。在 JDK8 中， 针对统计时间等场景，推荐使用 Instant 类。
- 不要在视图模板中加入任何复杂的逻辑。
说明：根据 MVC 理论，视图的职责是展示，不要抢模型和控制器的活。
- 任何数据结构的构造或初始化，都应指定大小，避免数据结构无限增长吃光内存。
- 及时清理不再使用的代码段或配置信息。
说明：对于垃圾代码或过时配置，坚决清理干净，避免程序过度臃肿，代码冗余。
正例：对于暂时被注释掉，后续可能恢复使用的代码片断，在注释代码上方，统一规定使用三个斜杠(///)来说明注释掉代码的理由。
## 第二章 异常与日志规范
### 2.1 异常处理
- Java 类库中定义的可以通过预检查方式规避的 RuntimeException 异常不应该通过 catch 的方式来处理，比如：NullPointerException，IndexOutOfBoundsException 等等。
说明：无法通过预检查的异常除外，比如，**在解析字符串形式的数字时，不得不通过 catch NumberFormatException 来实现**。
正例：if (obj != null) {...}
反例：try { obj.method(); } catch (NullPointerException e) {…}
- 异常不要用来做流程控制，条件控制。
说明：异常设计的初衷是解决程序运行中的各种意外情况，且异常的处理效率比条件判断方式要低很多。
- catch 时请分清稳定代码和非稳定代码，稳定代码指的是无论如何不会出错的代码。 对于非稳定代码的 catch 尽可能进行区分异常类型，再做对应的异常处理。
说明：对大段代码进行 try-catch，使程序无法根据不同的异常做出正确的应激反应，也不利于定位问题，这是一种不负责任的表现。
正例：用户注册的场景中，如果用户输入非法字符，或用户名称已存在，或用户输入密码过于简单，在程序上作出分门别类的判断，并提示给用户。
- 捕获异常是为了处理它，不要捕获了却什么都不处理而抛弃之，如果不想处理它，请将该异常抛给它的调用者。最外层的业务使用者，必须处理异常，将其转化为用户可以理解的内容。
- 有 try 块放到了事务代码中，catch 异常后，如果需要回滚事务，一定要注意手动回滚事务。
- finally 块必须对资源对象、流对象进行关闭，有异常也要做 try-catch。
说明：如果 JDK7 及以上，可以使用 try-with-resources 方式。
- 不要在 finally 块中使用 return。
说明：finally 块中的 return 返回后方法结束执行，不会再执行 try 块中的 return 语句。
- 捕获异常与抛异常，必须是完全匹配，或者捕获异常是抛异常的父类。
说明：如果预期对方抛的是绣球，实际接到的是铅球，就会产生意外情况。
- 方法的返回值可以为 null，不强制返回空集合，或者空对象等，必须添加注释充分说明什么情况下会返回 null 值。
说明：本手册明确防止 NPE 是调用者的责任。即使被调用方法返回空集合或者空对象，对调用者来说，也并非高枕无忧，必须考虑到远程调用失败、序列化失败、运行时异常等场景返回 null 的情况。
- 防止 NPE，是程序员的基本修养，注意 NPE 产生的场景：
1）返回类型为基本数据类型，return 包装数据类型的对象时，自动拆箱有可能产生 NPE。
反例：public int f() { return Integer 对象}， 如果为 null，自动解箱抛 NPE。
2） 数据库的查询结果可能为 null。
3） 集合里的元素即使 isNotEmpty，取出的数据元素也可能为 null。
4） 远程调用返回对象时，一律要求进行空指针判断，防止 NPE。
5） 对于 Session 中获取的数据，建议 NPE 检查，避免空指针。
6） 级联调用 obj.getA().getB().getC()；一连串调用，易产生 NPE。
正例：使用 JDK8 的 Optional 类来防止 NPE 问题。
- 定义时区分 unchecked / checked 异常，避免直接抛出 new RuntimeException()， 更不允许抛出 Exception 或者 Throwable，应使用有业务含义的自定义异常。推荐业界已定义过的自定义异常，如：DAOException / ServiceException 等。
- 对于公司外的 http/api 开放接口必须使用“错误码”；而应用内部推荐异常抛出； 跨应用间 RPC 调用优先考虑使用 Result 方式，封装 isSuccess()方法、“错误码”、“错误简短信息”。
说明：关于 RPC 方法返回方式使用 Result 方式的理由。
1）使用抛异常返回方式，调用方如果没有捕获到就会产生运行时错误。
2）如果不加栈信息，只是 new 自定义异常，加入自己的理解的 error message，对于调用端解决问题的帮助不会太多。如果加了栈信息，在频繁调用出错的情况下，数据序列化和传输的性能损耗也是问题。
- 避免出现重复的代码（Don’t Repeat Yourself），即 DRY 原则。
说明：随意复制和粘贴代码，必然会导致代码的重复，在以后需要修改时，需要修改所有的副本，容易遗漏。必要时抽取共性方法，或者抽象公共类，甚至是组件化。
```java
// 正例：
// 一个类中有多个 public 方法，都需要进行数行相同的参数校验操作，这个时候请抽取：
private boolean checkParam(DTO dto) {...}
```
### 2.2 日志规约
- 应用中不可直接使用日志系统（Log4j、Logback）中的 API，而应依赖使用日志框架 SLF4J 中的API，使用门面模式的日志框架，有利于维护和各个类的日志处理方式统一。
```java
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
private static final Logger logger = LoggerFactory.getLogger(Abc.class);
```
- 日志文件至少保存 15 天，因为有些异常具备以“周”为频次发生的特点。
- 应用中的扩展日志（如打点、临时监控、访问日志等）命名方式：appName_logType_logName.log。 logType:日志类型，如 stats/monitor/access 等；logName:日志描述。这种命名的好处： 通过文件名就可知道日志文件属于什么应用，什么类型，什么目的，也有利于归类查找。
正例：mppserver 应用中单独监控时区转换异常，如：mppserver_monitor_timeZoneConvert.log
说明：推荐对日志进行分类，如将错误日志和业务日志分开存放，便于开发人员查看，也便于通过日志对系统进行及时监控。
- 对 trace/debug/info 级别的日志输出，必须使用条件输出形式或者使用占位符的方式。
说明：logger.debug("Processing trade with id: " + id + " and symbol: " + symbol); 如果日志级别是 warn，上述日志不会打印，但是会执行字符串拼接操作，如果 symbol 是对象， 会执行 toString()方法，浪费了系统资源，执行了上述操作，最终日志却没有打印。
```java
// 正例：
//（条件）建议采用如下方式
if (logger.isDebugEnabled()) {
logger.debug("Processing trade with id: " + id + " and symbol: " + symbol);
}
// 正例：（占位符）
logger.debug("Processing trade with id: {} and symbol : {} ", id, symbol);
```
- 避免重复打印日志，浪费磁盘空间，务必在 log4j.xml 中设置 additivity=false。
```xml
<!-- 正例： -->
<logger name="com.taobao.dubbo.config" additivity="false">
```
- 异常信息应该包括两类信息：案发现场信息和异常堆栈信息。如果不处理，那么通过关键字 throws 往上抛出。
正例：logger.error(各类参数或者对象 toString() + "_" + e.getMessage(), e);
- 谨慎地记录日志。生产环境禁止输出 debug 日志；有选择地输出 info 日志；如果使用 warn 来记录刚上线时的业务行为信息，一定要注意日志输出量的问题，避免把服务器磁盘撑爆，并记得及时删除这些观察日志。
说明：大量地输出无效日志，不利于系统性能提升，也不利于快速定位错误点。记录日志时请思考：这些日志真的有人看吗？看到这条日志你能做什么？能不能给问题排查带来好处？
- 可以使用 warn 日志级别来记录用户输入参数错误的情况，避免用户投诉时，无所适从。如非必要，请不要在此场景打出 error 级别，避免频繁报警。
说明：注意日志输出的级别，error 级别只记录系统逻辑出错、异常或者重要的错误信息。
- 尽量用英文来描述日志错误信息，如果日志中的错误信息用英文描述不清楚的话 使用中文描述即可，否则容易产生歧义。国际化团队或海外部署的服务器由于字符集问题，【强制】 使用全英文来注释和描述日志错误信息。
## 第三章 数据库规范
我们 to B 的业务主要使用的是Oracle和SQL server，去年参与适配了国产的华为GaussDB及达梦DM数据库。
### 3.1 建表规约
- 临时库、表名必须以tmp为前缀，如果是按照日期生成的，以日期为后缀
- 备份库、表必须以bak为前缀，如果是按照日期生成的，以日期为后缀
- 表达是与否概念的字段，必须使用 is_xxx 的方式命名，数据类型是 unsigned tinyint （1 表示是，0 表示否）。
说明：任何字段如果为非负数，必须是 unsigned。
注意：POJO 类中的任何布尔类型的变量，都不要加 is 前缀，所以，需要在&lt;resultMap&gt;设置从is_xxx 到 Xxx 的映射关系。数据库表示是与否的值，使用 tinyint 类型，坚持 is_xxx 的命名方式是为了明确其取值含义与取值范围。 正例：表达逻辑删除的字段名 is_deleted，1 表示删除，0 表示未删除。
tips：我们使用的是dr字段代表逻辑删除，且POJO和布尔字段也未使用上述规范，这也与我们的JDBC框架有关，我们的JDBC框架是自己设计的，与mybatis等主流框架有很大不同。
- 表名、字段名必须使用小写字母或数字，禁止出现数字开头，禁止两个下划线中间只出现数字。数据库字段名的修改代价很大，因为无法进行预发布，所以字段名称需要慎重考虑。
说明：**MySQL 在 Windows 下不区分大小写，但在 Linux 下默认是区分大小写。因此，数据库名、表名、字段名，都不允许出现任何大写字母，避免节外生枝。**
正例：aliyun_admin，rdc_config，level3_name
反例：AliyunAdmin，rdcConfig，level_3_name
- 表名不使用复数名词。
说明：表名应该仅仅表示表里面的实体内容，不应该表示实体数量，对应于 DO 类名也是单数形式，符合表达习惯。
- 禁用保留字，如 desc、range、match、delayed 等，请参考 MySQL 官方保留字。
- 主键索引名为 pk_字段名；唯一索引名为 uk_字段名；普通索引名则为 idx_字段名。
说明：pk_ 即 primary key；uk_ 即 unique key；idx_ 即 index 的简称。
- 小数类型为 decimal，禁止使用 float 和 double。
说明：float 和 double 在存储的时候，存在精度损失的问题，很可能在值的比较时，得到错误的结果。如果存储的数据范围超过 decimal 的范围，建议将数据拆成整数和小数分开存储。
- 如果存储的字符串长度几乎相等，使用 char 定长字符串类型。
tips：公司这一点倒是做的比较规范。
- varchar 是不定长字符串，不预先分配存储空间，长度不要超过 5000，如果存储长度大于此值，定义字段类型为 text，独立出来一张表，用主键来对应，避免影响其它字段索引效率。
tips：Oracle的varchar最大长度为4000，SQL server 8000，这是之前适配数据库时踩过的坑。
- 表必备三字段：id, gmt_create, gmt_modified。
说明：其中 id 必为主键，类型为 bigint unsigned、单表时自增、步长为 1。gmt_create、gmt_modified 的类型均为 datetime 类型，前者现在时表示主动创建，后者过去分词表示被动更新。
- **表的命名最好是加上“业务名称_表的作用”**。 正例：alipay_task / force_project / trade_config
- 库名与应用名称尽量一致。
- 如果修改字段含义或对字段表示的状态追加时，需要及时更新字段注释。
- 字段允许适当冗余，以提高查询性能，但必须考虑数据一致。冗余字段应遵循：
1）不是频繁修改的字段。
2）不是 varchar 超长字段，更不能是 text 字段。
正例：商品类目名称使用频率高，字段长度短，名称基本一成不变，可在相关联的表中冗余存储类目名称，避免关联查询。
- 单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表。
说明：如果预计三年后的数据量根本达不到这个级别，请不要在创建表时就分库分表。
- 合适的字符存储长度，不但节约数据库表空间、节约索引存储，更重要的是提升检索速度。
正例：如下表，其中无符号值可以避免误存负数，且扩大了表示范围。
### 3.2 SQL语句
- 不要使用 count(列名)或 count(常量)来替代 count(*)，count(*)是 SQL92 定义的 标准统计行数的语法，跟数据库无关，跟 NULL 和非 NULL 无关。
说明：**count(*)会统计值为 NULL 的行，而 count(列名)不会统计此列为 NULL 值的行**。
- **count(distinct col) 计算该列除 NULL 之外的不重复行数，注意 count(distinct col1, col2) 如果其中一列全为 NULL，那么即使另一列有不同的值，也返回为 0**。
- 当某一列的值全是 NULL 时，count(col)的返回结果为 0，但 sum(col)的返回结果为 NULL，因此使用 sum()时需注意 NPE 问题。
正例：可以使用如下方式来避免 sum 的 NPE 问题：SELECT IF(ISNULL(SUM(g)),0,SUM(g)) FROM table;
- 使用 ISNULL()来判断是否为 NULL 值。
说明：NULL 与任何值的直接比较都为 NULL。
1） NULL<>NULL 的返回结果是 NULL，而不是 false。
2） NULL=NULL 的返回结果是 NULL，而不是 true。
3） NULL<>1 的返回结果是 NULL，而不是 true。
- 在代码中写分页查询逻辑时，若 count 为 0 应直接返回，避免执行后面的分页语句。
- 不得使用外键与级联，一切外键概念必须在应用层解决。
说明： 以学生和成绩的关系为例，学生表中的student_id是主键，那么成绩表中的student_id 则为外键。如果更新学生表中的 student_id，同时触发成绩表中的 student_id 更新，即为级联更新。外键与级联更新适用于单机低并发，不适合分布式、高并发集群；级联更新是强阻塞，存在数据库更新风暴的风险；外键影响数据库的插入速度。
- 禁止使用存储过程，存储过程难以调试和扩展，更没有移植性。
- 数据订正（特别是删除、修改记录操作）时，要先 select，避免出现误删除，确认无误才能执行更新语句。
- in 操作能避免则避免，若实在避免不了，需要仔细评估 in 后边的集合元素数量，控 制在 1000 个之内。
- 如果有国际化需要，所有的字符存储与表示，均以 utf-8 编码，注意字符统计函数 的区别。
说明：
SELECT LENGTH("轻松工作")； 返回为 12
SELECT CHARACTER_LENGTH("轻松工作")； 返回为 4
如果需要存储表情，那么选择 utf8mb4 来进行存储，注意它与 utf-8 编码的区别。
- TRUNCATE TABLE 比 DELETE 速度快，且使用的系统和事务日志资源少，但 TRUNCATE 无事务且不触发 trigger，有可能造成事故，故不建议在开发代码中使用此语句。
说明：TRUNCATE TABLE 在功能上与不带 WHERE 子句的 DELETE 语句相同。
### 3.3 ORM映射
我们的JDBC框架是自己研发的，之前也有看过Mybatis的源码，两者的设计及使用还是差别挺大的。
- 在表查询中，一律不要使用 * 作为查询的字段列表，需要哪些字段必须明确写明。
说明：
1）增加查询分析器解析成本。
2）增减字段容易与 resultMap 配置不一致。
3）无用字 段增加网络消耗，尤其是 text 类型的字段。
- POJO 类的布尔属性不能加 is，而数据库字段必须加 is_，要求在 resultMap 中进行字段与属性之间的映射。
说明：参见定义 POJO 类以及数据库字段定义规定，在&lt;resultMap&gt;中增加映射，是必须的。 在 MyBatis Generator 生成的代码中，需要进行对应的修改。
- 不要用 resultClass 当返回参数，即使所有类属性名与数据库字段一一对应，也需要定义；反过来，每一个表也必然有一个 POJO 类与之对应。
说明：配置映射关系，使字段与 DO 类解耦，方便维护。
- sql.xml 配置参数使用：#{}， #param# 不要使用${} 此种方式容易出现 SQL 注入。
- iBATIS 自带的 queryForList(String statementName,int start,int size)不推 荐使用。
说明：其实现方式是在数据库取到statementName对应的SQL语句的所有记录，再通过subList 取 start,size 的子集合。
```java
// 正例：
Map<String, Object> map = new HashMap<>();
map.put("start", start);
map.put("size", size);
```
- 不允许直接拿 HashMap 与 Hashtable 作为查询结果集的输出。
说明：resultClass=”Hashtable”，会置入字段名和属性值，但是值的类型不可控。
- 更新数据表记录时，必须同时更新记录对应的 gmt_modified 字段值为当前时间。
- 不要写一个大而全的数据更新接口。传入为 POJO 类，不管是不是自己的目标更新字段，都进行 update table set c1=value1,c2=value2,c3=value3; 这是不对的。执行 SQL 时，不要更新无改动的字段，一是易出错；二是效率低；三是增加 binlog 存储。
- @Transactional 事务不要滥用。事务会影响数据库的 QPS，另外使用事务的地方需要考虑各方面的回滚方案，包括缓存回滚、搜索引擎回滚、消息补偿、统计修正等。
- &lt;isEqual&gt;中的 compareValue 是与属性值对比的常量，一般是数字，表示相等时带上此条件；&lt;isNotEmpty&gt;表示不为空且不为 null 时执行；&lt;isNotNull&gt;表示不为 null 值时 执行。
### 3.4 索引规范
- 业务上具有唯一特性的字段，即使是多个字段的组合，也必须建成唯一索引。
说明：不要以为唯一索引影响了 insert 速度，这个速度损耗可以忽略，但提高查找速度是明显的；另外，即使在应用层做了非常完善的校验控制，只要没有唯一索引，根据墨菲定律（只要有这个可能性 就一定会发生），必然有脏数据产生。
- 超过三个表禁止 join。需要 join 的字段，数据类型必须绝对一致；多表关联查询时，保证被关联的字段需要有索引。
说明：即使双表 join 也要注意表索引、SQL 性能。
- 在 varchar 字段上建立索引时，必须指定索引长度，没必要对全字段建立索引，根据实际文本区分度决定索引长度即可。
说明：索引的长度与区分度是一对矛盾体，一般对字符串类型数据，长度为 20 的索引，区分度会高达 90%以上，可以使用 count(distinct left(列名, 索引长度))/count(*)的区分度 来确定。
- 页面搜索严禁左模糊或者全模糊，如果需要请走搜索引擎来解决。
说明：索引文件具有 B-Tree 的最左前缀匹配特性，如果左边的值未确定，那么无法使用此索引。
- 如果有 order by 的场景，请注意利用索引的有序性。order by 最后的字段是组合索引的一部分，并且放在索引组合顺序的最后，避免出现 file_sort 的情况，影响查询性能。
正例：where a=? and b=? order by c; 索引：a_b_c
反例：索引中有范围查找，那么索引有序性无法利用，如：WHERE a>10 ORDER BY b; 索引 a_b 无法排序。
- 利用覆盖索引来进行查询操作，避免回表。
说明：如果一本书需要知道第 11 章是什么标题，会翻开第 11 章对应的那一页吗？目录浏览一下就好，这个目录就是起到覆盖索引的作用。
正例：能够建立索引的种类分为主键索引、唯一索引、普通索引三种，而覆盖索引只是一种查询的一种效果，用 explain 的结果，extra 列会出现：using index。
- 利用延迟关联或者子查询优化超多分页场景。
说明：MySQL 并不是跳过 offset 行，而是取 offset+N 行，然后返回放弃前 offset 行，返回 N 行，那当 offset 特别大的时候，效率就非常的低下，要么控制返回的总页数，要么对超过特定阈值的页数进行 SQL 改写。
正例：先快速定位需要获取的 id 段，然后再关联：
SELECT a.* FROM 表1 a, ( select id from 表1 where 条件 LIMIT 100000,20 ) b where a.id=b.id
- SQL 性能优化的目标：至少要达到 range 级别，要求是 ref 级别，如果可以是 consts 最好。
说明：
1）consts 单表中最多只有一个匹配行（主键或者唯一索引），在优化阶段即可读取到数据。
2）ref 指的是使用普通的索引（normal index）。
3）range 对索引进行范围检索。
反例：explain 表的结果，type=index，索引物理文件全扫描，速度非常慢，这个 index 级别比较range 还低，与全表扫描是小巫见大巫。
- 建组合索引的时候，区分度最高的在最左边。
正例：如果 where a=? and b=? ，如果 a 列的几乎接近于唯一值，那么只需要单建 idx_a 索引即可。
说明：存在非等号和等号混合时，在建索引时，请把等号条件的列前置。如：where c>? and d=? 那么即使 c 的区分度更高，也必须把 d 放在索引的最前列，即索引 idx_d_c。
- 防止因字段类型不同造成的隐式转换，导致索引失效。
- 创建索引时避免有如下极端误解：
1）宁滥勿缺。认为一个查询就需要建一个索引。
2）宁缺勿滥。认为索引会消耗空间、严重拖慢更新和新增速度。
3）抵制惟一索引。认为业务的惟一性一律需要在应用层通过“先查后插”方式解决。
## 安全规约
- 隶属于用户个人的页面或者功能必须进行权限控制校验。
说明：防止没有做水平权限校验就可随意访问、修改、删除别人的数据，比如查看他人的私信 内容、修改他人的订单。
- 用户敏感数据禁止直接展示，必须对展示数据进行脱敏。
说明：中国大陆个人手机号码显示为:158****9119，隐藏中间 4 位，防止隐私泄露。
- 用户输入的 SQL 参数严格使用参数绑定或者 METADATA 字段值限定，防止 SQL 注入， 禁止字符串拼接 SQL 访问数据库。
- 用户请求传入的任何参数必须做有效性验证。
说明：忽略参数校验可能导致：
1）page size 过大导致内存溢出；
2）恶意 order by 导致数据库慢查询；
3）任意重定向；
4）SQL 注入；
5）反序列化注入；
6）正则输入源串拒绝服务 ReDoS；
说明：Java 代码用正则来验证客户端的输入，有些正则写法验证普通用户输入没有问题，但是如果攻击人员使用的是特殊构造的字符串来验证，有可能导致死循环的结果。
- 禁止向 HTML 页面输出未经安全过滤或未正确转义的用户数据。
- 表单、AJAX 提交必须执行 CSRF 安全验证。
说明：CSRF(Cross-site request forgery)跨站请求伪造是一类常见编程漏洞。对于存在 CSRF 漏洞的应用/网站，攻击者可以事先构造好 URL，只要受害者用户一访问，后台便在用户不知情的情况下对数据库中用户参数进行相应修改。
- 在使用平台资源，譬如短信、邮件、电话、下单、支付，必须实现正确的防重放的机制，如数量限制、疲劳度控制、验证码校验，避免被滥刷而导致资损。
说明：如注册时发送验证码到手机，如果没有限制次数和频率，那么可以利用此功能骚扰到其它用户，并造成短信平台资源浪费。
- 发贴、评论、发送即时消息等用户生成内容的场景必须实现防刷、文本内容违禁词过滤等风控策略。

1
docs/LearningExperience/EncodingSpecification/由量变到质变写出高质量代码.md
Unescape View File

@ -1 +0,0 @@
努力编写中...

1
docs/LearningExperience/Multi-thread/Java多线程编程在各主流框架中的应用.md
Unescape View File

@ -0,0 +1 @@
努力更新中......

44
docs/Mybatis/基础支持层/1、反射工具箱和TypeHandler系列.md
Unescape View File

@ -111,7 +111,7 @@ public class CustomReflectorFactory extends DefaultReflectorFactory {
}
```
### 1.3 ObjectFactory
该类也是接口+一个默认实现类，并且支持自定义扩展，mybatis中有很多这样的设计方式。
该类也是接口加一个默认实现类，并且支持自定义扩展，Mybatis 中有很多这样的设计方式。
```java
/**
* MyBatis uses an ObjectFactory to create all needed new Objects.
@ -145,7 +145,7 @@ public interface ObjectFactory {
/**
* ObjectFactory接口 的唯一直接实现，反射工厂，根据传入的参数列表，选择
* 合适的构造函数实例化对象，不传参数，则直接调用其午餐构造方法
* 合适的构造函数实例化对象，不传参数，则直接调用其无参构造方法
*/
public class DefaultObjectFactory implements ObjectFactory, Serializable {
@ -206,9 +206,9 @@ public class DefaultObjectFactory implements ObjectFactory, Serializable {
}
```
## 2 类型转换
类型转换是实现ORM的重要一环，由于 数据库中的数据类型与Java语言的数据类型并不对等，所以在PrepareStatement为sql语句绑定参数时，需要从Java类型转换成JDBC类型，而从结果集获取数据时，又要将JDBC类型转换成Java类型，mybatis使用TypeHandler完成了上述的双向转换。
类型转换是实现 ORM 的重要一环，由于数据库中的数据类型与 Java语言 的数据类型并不对等，所以在 PrepareStatement 为 sql语句 绑定参数时，需要从 Java类型 转换成 JDBC类型，而从结果集获取数据时，又要将 JDBC类型 转换成 Java类型，Mybatis 使用 TypeHandler 完成了上述的双向转换。
### 2.1 JdbcType
mybatis通过JdbcType这个枚举类型代表了JDBC中的数据类型
Mybatis 通过 JdbcType 这个枚举类型代表了 JDBC 中的数据类型。
```java
/**
* 该枚举类描述了 JDBC 中的数据类型
@ -282,7 +282,7 @@ public enum JdbcType {
}
```
### 2.2 TypeHandler
TypeHandler是mybatis中所有类型转换器的顶层接口，主要用于实现 数据从Java类型到JdbcType类型的相互转换。
TypeHandler 是 Mybatis 中所有类型转换器的顶层接口，主要用于实现数据从 Java类型 到 JdbcType类型 的相互转换。
```java
public interface TypeHandler<T> {
@ -344,13 +344,13 @@ public abstract class BaseTypeHandler<T> extends TypeReference<T> implements Typ
public class IntegerTypeHandler extends BaseTypeHandler<Integer> {
/**
1. NonNull就是NoneNull，非空的意思
* NonNull 就是 NoneNull，非空的意思
*/
@Override
public void setNonNullParameter(PreparedStatement ps, int i, Integer parameter, JdbcType jdbcType)
throws SQLException {
// IntegerTypeHandler就调用PreparedStatement的setInt方法
// BooleanTypeHandler就调用PreparedStatement的setBoolean方法
// IntegerTypeHandler 就调用 PreparedStatement 的 setInt()方法
// BooleanTypeHandler 就调用 PreparedStatement 的 setBoolean()方法
// 其它的基本数据类型，以此类推
ps.setInt(i, parameter);
}
@ -379,9 +379,9 @@ public class IntegerTypeHandler extends BaseTypeHandler<Integer> {
```
TypeHandler 主要用于单个参数的类型转换，如果要将多个列的值转换成一个 Java对象，可以在映射文件中定义合适的映射规则 &lt;resultMap&gt; 完成映射。
### 2.3 TypeHandlerRegistry
TypeHandlerRegistry主要负责管理所有已知的TypeHandler，mybatis在初始化过程中会为所有已知的TypeHandler创建对象，并注册到TypeHandlerRegistry。
TypeHandlerRegistry 主要负责管理所有已知的 TypeHandler，Mybatis 在初始化过程中会为所有已知的 TypeHandler 创建对象，并注册到 TypeHandlerRegistry。
```java
//TypeHandlerRegistry中的核心字段
// TypeHandlerRegistry 中的核心字段如下
/** 该集合主要用于从结果集读取数据时，将数据从 JDBC类型 转换成 Java类型 */
private final Map<JdbcType, TypeHandler<?>> jdbcTypeHandlerMap = new EnumMap<>(JdbcType.class);
@ -392,14 +392,14 @@ TypeHandlerRegistry主要负责管理所有已知的TypeHandler，mybatis在初
*/
private final Map<Type, Map<JdbcType, TypeHandler<?>>> typeHandlerMap = new ConcurrentHashMap<>();
/** key TypeHandler的类型；value 该TypeHandler类型对应的TypeHandler对象 */
/** key：TypeHandler 的类型；value：该 TypeHandler类型 对应的 TypeHandler对象 */
private final Map<Class<?>, TypeHandler<?>> allTypeHandlersMap = new HashMap<>();
```
1. **注册TypeHandler对象**
**1、注册TypeHandler对象**
TypeHandlerRegistry 中的 register()方法 实现了注册 TypeHandler对象 的功能，该方法存在多种重载，但大多数 register()方法 最终都会走 register(Type javaType, JdbcType jdbcType, TypeHandler<?> handler) 的处理逻辑，该重载方法中分别指定了 TypeHandler 能够处理的 Java类型、JDBC类型、TypeHandler对象。
```java
/**
* TypeHandlerRegistry中对register方法实现了多种重载，本register方法
* TypeHandlerRegistry 中对 register()方法 实现了多种重载，本 register()方法
* 被很多重载方法调用，用来完成注册功能。
*/
private void register(Type javaType, JdbcType jdbcType, TypeHandler<?> handler) {
@ -436,10 +436,10 @@ TypeHandlerRegistry中的register()方法实现了注册TypeHandler对象的功
```java
/**
* 进行 Java 及 JDBC基本数据类型 的 TypeHandler 注册
* 除了注册mybatis提供的基本TypeHandler外，我们也可以添加自定义的TypeHandler
* 除了注册 Mybatis 提供的 基本TypeHandler 外，我们也可以添加自定义的 TypeHandler
* 接口实现，在 mybatis-config.xml配置文件 中 <typeHandlers>节点 下添加相应的
* <typeHandlers>节点配置，并指定自定义的TypeHandler实现类。mybatis在初始化时
* 会解析该节点，并将TypeHandler类型的对象注册到TypeHandlerRegistry中 供mybatis后续使用
* <typeHandlers>节点配置，并指定自定义的 TypeHandler实现类。Mybatis 在初始化时
* 会解析该节点，并将 TypeHandler类型 的对象注册到 TypeHandlerRegistry 中供 Mybatis 后续使用
*/
public TypeHandlerRegistry() {
register(Boolean.class, new BooleanTypeHandler());
@ -515,20 +515,20 @@ TypeHandlerRegistry中的register()方法实现了注册TypeHandler对象的功
register(JapaneseDate.class, new JapaneseDateTypeHandler());
}
```
2. **查找TypeHandler**
TypeHandlerRegistry其实就是一个容器，前面注册了一堆东西，也就是为了方便获取，其对应的方法为getTypeHandler()，也是存在多种重载，其中最重要的一个重载为getTypeHandler(Type type, JdbcType jdbcType)，它会根据指定的Java类型和JdbcType类型查找相应的TypeHandler对象。
**2、查找TypeHandler**
TypeHandlerRegistry 其实就是一个容器，前面注册了一堆东西，也就是为了方便获取，其对应的方法为 getTypeHandler()，该方法也存在多种重载，其中最重要的一个重载为 getTypeHandler(Type type, JdbcType jdbcType)，它会根据指定的 Java类型 和 JdbcType类型 查找相应的 TypeHandler对象。
```java
/**
* 获取 TypeHandler对象
* getTypeHandler方法亦存在多种重载，而本重载方法被其它多个重载方法调用
* getTypeHandler()方法 亦存在多种重载，而本重载方法被其它多个重载方法调用
*/
private <T> TypeHandler<T> getTypeHandler(Type type, JdbcType jdbcType) {
if (ParamMap.class.equals(type)) {
return null;
}
// Java数据类型 与 JDBC数据类型 的关系往往是一对多，
// 所以一般会先根据Java数据类型获取Map<JdbcType, TypeHandler<?>>
// 再根据JDBC数据类型获取对应的TypeHandler
// 所以一般会先根据 Java数据类型 获取 Map<JdbcType, TypeHandler<?>>对象
// 再根据 JDBC数据类型 获取对应的 TypeHandler对象
Map<JdbcType, TypeHandler<?>> jdbcHandlerMap = getJdbcHandlerMap(type);
TypeHandler<?> handler = null;
if (jdbcHandlerMap != null) {
@ -545,4 +545,4 @@ TypeHandlerRegistry其实就是一个容器，前面注册了一堆东西，也
return (TypeHandler<T>) handler;
}
```
除了mabatis本身自带的TypeHandler实现，我们还可以添加自定义的TypeHandler实现类，在配置文件mybatis-config.xml中的&lt;typeHandler&gt;标签下配置好自定义TypeHandler，mybatis就会在初始化时解析该标签内容，完成自定义TypeHandler的注册。
除了 Mabatis 本身自带的 TypeHandler实现，我们还可以添加自定义的 TypeHandler实现类，在配置文件 mybatis-config.xml 中的 &lt;typeHandler&gt; 标签下配置好 自定义TypeHandler，Mybatis 就会在初始化时解析该标签内容，完成 自定义TypeHandler 的注册。

19
docs/Mybatis/基础支持层/2、DataSource及Transaction模块.md
Unescape View File

@ -1,6 +1,6 @@
在数据持久层，数据源和事务是两个非常重要的组件，对数据持久层的影响很大，在实际开发中，一般会使用mybatis集成第三方数据源组件，如：c3p0、Druid，另外，mybatis也提供了自己的数据库连接池实现，本文会通过mybatis的源码实现来了解数据库连接池的设计。而事务方面，一般使用spring进行事务的管理，这里不做详细分析。下面我们看一下mybatis是如何对这两部分进行封装的。
在数据持久层，数据源和事务是两个非常重要的组件，对数据持久层的影响很大，在实际开发中，一般会使用 Mybatis 集成第三方数据源组件，如：c3p0、Druid，另外，Mybatis 也提供了自己的数据库连接池实现，本文会通过 Mybatis 的源码实现来了解数据库连接池的设计。而事务方面，一般使用 Spring 进行事务的管理，这里不做详细分析。下面我们看一下 Mybatis 是如何对这两部分进行封装的。
## 1 DataSource
常见的数据源都会实现javax.sql.DataSource接口，mybatis中提供了两个该接口的实现类，分别是：PooledDataSource和UnpooledDataSource，并使用不同的工厂类分别管理这两个类的对象。
常见的数据源都会实现 javax.sql.DataSource接口，Mybatis 中提供了两个该接口的实现类，分别是：PooledDataSource 和 UnpooledDataSource，并使用不同的工厂类分别管理这两个类的对象。
### 1.1 DataSourceFactory
DataSourceFactory系列类 的设计比较简单，DataSourceFactory 作为顶级接口，UnpooledDataSourceFactory 实现了该接口，PooledDataSourceFactory 又继承了 UnpooledDataSourceFactory。
```java
@ -101,7 +101,7 @@ public class UnpooledDataSource implements DataSource {
/**
* UnpooledDataSource 被加载时，会通过该静态代码块将已经在 DriverManager
* 中注册JDBC Driver复制一份到registeredDrivers
* 中注册的 JDBC Driver 注册到 registeredDrivers 中
*/
static {
Enumeration<Driver> drivers = DriverManager.getDrivers();
@ -198,7 +198,7 @@ class PooledConnection implements InvocationHandler {
/**
* invoke()方法 是本类的重点实现，也是 proxyConnection代理连接对象 的代理逻辑实现
* 它会对close()方法的调用进行处理，并在调用realConnection的方法之前进行校验
* 它会对 close()方法 的调用进行处理，并在调用 realConnection对象 的方法之前进行校验
*/
@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
@ -213,7 +213,7 @@ class PooledConnection implements InvocationHandler {
// 通过上面的 valid字段 校验连接是否有效
checkConnection();
}
// 调用realConnection的对应方法
// 调用 realConnection对象 的对应方法
return method.invoke(realConnection, args);
} catch (Throwable t) {
throw ExceptionUtil.unwrapThrowable(t);
@ -540,7 +540,8 @@ public class PooledDataSource implements DataSource {
state.activeConnections.remove(conn);
// 如果该连接有效
if (conn.isValid()) {
// 如果连接池中的空闲连接数未达到阈值 且 该连接确实属于本连接池（通过之前获取的expectedConnectionTypeCode进行校验）
// 如果连接池中的空闲连接数未达到阈值 且 该连接确实属于
// 本连接池（通过之前获取的 expectedConnectionTypeCode 进行校验）
if (state.idleConnections.size() < poolMaximumIdleConnections && conn.getConnectionTypeCode() == expectedConnectionTypeCode) {
// CheckoutTime = 应用从连接池取出连接到归还连接的时长
// accumulatedCheckoutTime = 所有连接累计的CheckoutTime
@ -703,8 +704,8 @@ public class PooledDataSource implements DataSource {
}
```
## 2 Transaction
遵循接口-实现类的设计原则，mybatis也是先使用Transaction接口对数据库事务做了抽象，而实现类则只提供了两个，即：JdbcTransaction和ManagedTransaction。这两种对象的获取，使用了两个对应的工厂类JdbcTransactionFactory和ManagedTransactionFactory。
不过一般我们并不会使用mybatis管理事务，而是将mybatis集成到spring，由spring进行事务的管理。细节部分会在后面的文章中详细讲解。
遵循 “接口-实现类” 的设计原则，Mybatis 也是先使用 Transaction接口 对数据库事务做了抽象，而实现类则只提供了两个，即：JdbcTransaction 和 ManagedTransaction。这两种对象的获取，使用了两个对应的工厂类 JdbcTransactionFactory 和 ManagedTransactionFactory。
不过一般我们并不会使用 Mybatis 管理事务，而是将 Mybatis 集成到 Spring，由 Spring 进行事务的管理。细节部分会在后面的文章中详细讲解。
```java
public interface Transaction {
@ -866,7 +867,7 @@ public class ManagedTransaction implements Transaction {
// 控制是否关闭持有的连接，在 close()方法 中用其判断是否真的关闭连接
private final boolean closeConnection;
// 本类的实现也很简单，commit、rollback方法都是空实现
// 本类的实现也很简单，commit()、rollback()方法 都是空实现
public ManagedTransaction(Connection connection, boolean closeConnection) {
this.connection = connection;
this.closeConnection = closeConnection;

26
docs/Mybatis/基础支持层/3、binding模块.md
Unescape View File

@ -1,6 +1,6 @@
binding模块主要为了解决一个历史遗留问题，原先查询一个VO对象时需要调用SqlSession.queryForObject(“selectXXVOById”, primaryKey)方法，执行指定的sql语句，第一个参数selectXXVOById指定了执行的sql语句id，如果我们不小心写错了参数，mybatis是无法在初始化时发现这个错误的，只会在实际调用queryForObject(“selectXXVOById”, primaryKey)方法时才会抛出异常，这对于工程师来说是非常难受的，就像泛型出来之前，很多类型转换不会在编译期发现错误一样。而binding模块就像Java的泛型机制一样，将程序的错误提前暴露出来，为开发人员省去不少排查问题的精力。
binding模块 主要为了解决一个历史遗留问题，原先查询一个 VO对象 时需要调用 SqlSession.queryForObject(“selectXXVOById”, primaryKey)方法，执行指定的 sql语句，第一个参数 selectXXVOById 指定了执行的 sql语句id，如果我们不小心写错了参数，Mybatis 是无法在初始化时发现这个错误的，只会在实际调用 queryForObject(“selectXXVOById”, primaryKey)方法 时才会抛出异常，这对于工程师来说是非常难受的，就像泛型出来之前，很多类型转换不会在编译期发现错误一样。而 binding模块 就像 Java的泛型机制 一样，将程序的错误提前暴露出来，为开发人员省去不少排查问题的精力。
binding模块的解决方案是，定义一个Mapper接口，在接口中定义sql语句对应的方法名(Id)及参数，这些方法在mybatis的初始化过程中，会与该Mapper接口对应的映射配置文件中的sql语句相关联，如果存在无法关联的sql语句，mybatis就会抛出异常，帮助我们及时发现问题。示例代码如下：
binding模块 的解决方案是，定义一个 Mapper接口，在接口中定义 sql语句 对应的 方法名Id 及 参数，这些方法在 Mybatis 的初始化过程中，会与该 Mapper接口 对应的映射配置文件中的 sql语句 相关联，如果存在无法关联的 sql语句，Mybatis 就会抛出异常，帮助我们及时发现问题。示例代码如下：
```java
public interface HeroMapper {
// 映射文件中会存在一个 <select>节点，id 为 “selectHeroVOById”
@ -9,16 +9,17 @@ public interface HeroMapper {
// 首先，获取 HeroMapper 对应的代理对象
HeroMapper heroMapper = session.getMapper(HeroMapper.class);
// 直接调用HeroMapper接口中的方法 获取结果集
// 直接调用 HeroMapper接口 中的方法，获取结果集
HeroVO heroVO = heroMapper.selectHeroVOById("23333");
```
## 1 MapperRegistry和MapperProxyFactory
MapperRegistry是Mapper接口及其对应的代理对象工厂的注册中心。Configuration是mybatis中全局性的配置对象，根据mybatis的核心配置文件mybatis-config.xml解析而成。Configuration通过mapperRegistry属性持有该对象。
mybatis在初始化过程中会读取映射配置文件和Mapper接口中的注解信息，并调用MapperRegistry的addMappers()方法填充knownMappers集合，在需要执行某sql语句时，会先调用getMapper()方法获取实现了Mapper接口的动态代理对象。
MapperRegistry 是 Mapper接口 及其对应的代理对象工厂的注册中心。Configuration 是 Mybatis 中全局性的配置对象，根据 Mybatis 的核心配置文件 mybatis-config.xml 解析而成。Configuration 通过 mapperRegistry属性 持有该对象。
Mybatis 在初始化过程中会读取映射配置文件和 Mapper接口 中的注解信息，并调用 MapperRegistry 的 addMappers()方法 填充 knownMappers集合，在需要执行某 sql语句 时，会先调用 getMapper()方法 获取实现了 Mapper接口 的动态代理对象。
```java
public class MapperRegistry {
// mybatis全局唯一的配置对象，包含了几乎所有配置信息
// Mybatis 全局唯一的配置对象，包含了几乎所有配置信息
private final Configuration config;
// key：Mapper接口，value：MapperProxyFactory 为 Mapper接口 创建代理对象的工厂
private final Map<Class<?>, MapperProxyFactory<?>> knownMappers = new HashMap<>();
@ -114,7 +115,7 @@ public class MapperProxyFactory<T> {
}
public T newInstance(SqlSession sqlSession) {
// 每都会创建一个新的MapperProxy对象
// 每次都会创建一个新的 MapperProxy对象
final MapperProxy<T> mapperProxy = new MapperProxy<>(sqlSession, mapperInterface, methodCache);
return newInstance(mapperProxy);
}
@ -169,7 +170,7 @@ public class MapperProxy<T> implements InvocationHandler, Serializable {
// 主要负责维护 methodCache 缓存
private MapperMethod cachedMapperMethod(Method method) {
// 这里用到了Java8的新特性，computeIfAbsent()是Java8的新方法，Lambda表达式也是Java8中最重要的新特性之一
// 这里用到了 Java8 的新特性，computeIfAbsent() 是 Java8 新增的方法，Lambda表达式 也是 Java8中 最重要的新特性之一
// computeIfAbsent()方法 表示 当前map中，若 key 对应的 value 为空，则执行传入的 Lambda表达式，将 key 和表达式的 value
// 存入 当前map，并返回 value值
// 在这段代码中的意思是：若 methodCache 中没有 method 对应的 value，就执行右侧的 Lambda表达式，并将表达式的结果
@ -180,6 +181,7 @@ public class MapperProxy<T> implements InvocationHandler, Serializable {
```
## 3 MapperMethod
MapperMethod 中封装了 Mapper接口 中对应方法的信息，和对应 sql语句 的信息，是连接 Mapper接口 及映射配置文件中定义的 sql语句 的桥梁。
MapperMethod 中持有两个非常重要的属性，这两个属性对应的类 都是 MapperMethod 中的静态内部类。另外，MapperMethod 在被实例化时就对这两个属性进行了初始化。
```java
public class MapperMethod {
@ -209,7 +211,7 @@ MapperMethod中的核心方法execute()就主要用到了这两个类，所以
final String methodName = method.getName();
// 该方法对应的类的 Class对象
final Class<?> declaringClass = method.getDeclaringClass();
// MappedStatement封装了sql语句相关的信息，在mybatis初始化时创建
// MappedStatement 封装了 sql语句 相关的信息，在 Mybatis初始化 时创建
MappedStatement ms = resolveMappedStatement(mapperInterface, methodName, declaringClass, configuration);
if (ms == null) {
// 处理 Flush注解
@ -289,7 +291,7 @@ MapperMethod中的核心方法execute()就主要用到了这两个类，所以
/**
* 顾名思义，这是一个处理 Mapper接口 中 方法参数列表的解析器，它使用了一个 SortedMap<Integer, String>
* 类型的容器 记录了参数在参数列表中的位置索引 与 参数名之间的对应关系，key参数在参数列表中的索引位置，
* 类型的容器，记录了参数在参数列表中的位置索引 与 参数名之间的对应关系，key参数 在参数列表中的索引位置，
* value参数名(参数名可用@Param注解指定，默认使用参数索引作为其名称)
*/
private final ParamNameResolver paramNameResolver;
@ -340,7 +342,7 @@ MapperMethod中的核心方法execute()就主要用到了这两个类，所以
}
```
### 3.3 execute()方法
execute()方法会根据sql语句的类型(CRUD)调用SqlSession对应的方法完成数据库操作，SqlSession是mybatis的核心组件之一，后面会详细解读。
execute()方法 会根据 sql语句 的类型(CRUD)调用 SqlSession 对应的方法完成数据库操作，SqlSession 是 Mybatis 的核心组件之一，后面会详细解读。
```java
public class MapperMethod {
public Object execute(SqlSession sqlSession, Object[] args) {
@ -521,7 +523,7 @@ public class MapperMethod {
Object param = method.convertArgsToSqlCommandParam(args);
if (method.hasRowBounds()) {
RowBounds rowBounds = method.extractRowBounds(args);
// 注意这里调用的是sqlSession的selectMap方法，使用返回的是一个Map类型结果集
// 注意这里调用的是 SqlSession 的 selectMap()方法，返回的是一个 Map类型结果集
result = sqlSession.selectMap(command.getName(), param, method.getMapKey(), rowBounds);
} else {
result = sqlSession.selectMap(command.getName(), param, method.getMapKey());

5
docs/Mybatis/基础支持层/4、缓存模块.md
Unescape View File

@ -1,4 +1,4 @@
MyBatis中的缓存分为一级缓存、二级缓存，但在本质上是相同的，它们使用的都是Cache接口的实现。MyBatis缓存模块的设计 使用了装饰器模式，这里不对此进行过多解析，以后会专门开一篇博文分析常用框架中使用到的设计模式。
MyBatis 中的缓存分为一级缓存、二级缓存，但在本质上是相同的，它们使用的都是 Cache接口 的实现。MyBatis缓存模块 的设计，使用了装饰器模式，这里不对此进行过多解析，以后会专门开一篇博文分析常用框架中使用到的设计模式。
## 1 Cache组件
MyBatis 中缓存模块相关的代码位于 org.apache.ibatis.cache包 下，其中 Cache接口 是缓存模块中最核心的接口，它定义了所有缓存的基本行为。
```java
@ -48,6 +48,7 @@ public interface Cache {
如下图所示，Cache接口 的实现类有很多，但大部分都是装饰器，只有 PerpetualCache 提供了 Cache 接口 的基本实现。
![avatar](/images/mybatis/Cache组件.png)
### 1.1 PerpetualCache
PerpetualCache（Perpetual：永恒的，持续的）在缓存模块中扮演着被装饰的角色，其实现比较简单，底层使用 HashMap 记录缓存项，也是通过该 HashMap对象 的方法实现的 Cache接口 中定义的相应方法。
```java
@ -141,7 +142,7 @@ public class BlockingCache implements Cache {
}
}
```
假设线程A在BlockingCache中未查找到keyA对应的缓存项时，线程A会获取keyA对应的锁，这样后续线程A在查找keyA时，其它线程会被阻塞。
假设 线程A 在 BlockingCache 中未查找到 keyA 对应的缓存项时，线程A 会获取 keyA 对应的锁，这样，线程A 在后续查找 keyA 时，其它线程会被阻塞。
```java
// 根据 key 获取锁对象，然后上锁
private void acquireLock(Object key) {

40
docs/Mybatis/核心处理层/1、MyBatis初始化.md
Unescape View File

@ -1,6 +1,6 @@
和spring框架的IoC容器初始化一样，mybatis也会通过定位、解析相应的配置文件完成自己的初始化。mybatis的配置文件主要有mybatis-config.xml核心配置文件及一系列映射配置文件，另外，mybatis也会根据注解进行配置。
和 Spring框架 的 IoC容器初始化 一样，Mybatis 也会通过定位、解析相应的配置文件完成自己的初始化。Mybatis 的配置文件主要有 mybatis-config.xml核心配置文件 及一系列映射配置文件，另外，Mybatis 也会根据注解进行配置。
## 1 BaseBuilder
mybatis初始化的主要内容是加载并解析mybatis-config.xml配置文件、映射配置文件以及相关的注解信息。mybatis的初始化入口是SqlSessionFactoryBuilder的build()方法。
Mybatis初始化 的主要内容是加载并解析 mybatis-config.xml配置文件、映射配置文件以及相关的注解信息。Mybatis 的初始化入口是 SqlSessionFactoryBuilder 的 build()方法。
```java
public class SqlSessionFactoryBuilder {
@ -17,14 +17,14 @@ public class SqlSessionFactoryBuilder {
}
/**
* build方法的主要实现
* build()方法 的主要实现
*/
public SqlSessionFactory build(Reader reader, String environment, Properties properties) {
try {
// SqlSessionFactory 会创建 XMLConfigBuilder对象 来解析 mybatis-config.xml配置文件
// XMLConfigBuilder 继承自 BaseBuilder抽象类，顾名思义这一系的类使用了 建造者设计模式
XMLConfigBuilder parser = new XMLConfigBuilder(reader, environment, properties);
// 解析配置文件的内容 到Configuration对象，根据到Configuration对象
// 解析配置文件的内容 到 Configuration对象，根据 Configuration对象
// 创建 DefaultSqlSessionFactory对象，然后返回
return build(parser.parse());
} catch (Exception e) {
@ -48,7 +48,7 @@ BaseBuilder中的核心字段如下：
```java
public abstract class BaseBuilder {
// 保存了mybatis的几乎所以核心配置信息，全局唯一
// 保存了 Mybatis 的几乎所以核心配置信息，全局唯一
protected final Configuration configuration;
// 在 mybatis-config.xml 中可以通过 <typeAliases>标签 定义别名
protected final TypeAliasRegistry typeAliasRegistry;
@ -115,7 +115,7 @@ public class XMLConfigBuilder extends BaseBuilder {
}
}
```
mybatis中的标签很多，所以相对应的解析方法也很多，这里挑几个比较重要的标签进行分析。
Mybatis 中的标签很多，所以相对应的解析方法也很多，这里挑几个比较重要的标签进行分析。
### 2.1 解析&lt;typeHandlers&gt;标签
```java
private void typeHandlerElement(XNode parent) throws Exception {
@ -156,7 +156,7 @@ mybatis中的标签很多，所以相对应的解析方法也很多，这里挑
### 2.2 解析&lt;environments&gt;标签
```java
/**
* mybatis可以配置多个<environment>环境，分别用于开发、测试及生产等，
* Mybatis 可以配置多个 <environment>环境，分别用于开发、测试及生产等，
* 但每个 SqlSessionFactory实例 只能选择其一
*/
private void environmentsElement(XNode context) throws Exception {
@ -186,13 +186,13 @@ mybatis中的标签很多，所以相对应的解析方法也很多，这里挑
}
```
### 2.3 解析&lt;databaseIdProvider&gt;标签
mybatis不像hibernate那样，通过hql的方式直接帮助开发人员屏蔽不同数据库产品在sql语法上的差异，针对不同的数据库产品，mybatis往往要编写不同的sql语句。但在mybatis-config.xml配置文件中，可以通过&lt;databaseIdProvider&gt;定义所有支持的数据库产品的databaseId，然后在映射配置文件中定义sql语句节点时，通过databaseId指定该sql语句应用的数据库产品，也可以达到类似的屏蔽数据库产品的功能。
Mybatis 不像 Hibernate 那样，通过 HQL 的方式直接帮助开发人员屏蔽不同数据库产品在 sql语法 上的差异，针对不同的数据库产品， Mybatis 往往要编写不同的 sql语句。但在 mybatis-config.xml配置文件 中，可以通过 &lt;databaseIdProvider&gt; 定义所有支持的数据库产品的 databaseId，然后在映射配置文件中定义 sql语句节点 时，通过 databaseId 指定该 sql语句 应用的数据库产品，也可以达到类似的屏蔽数据库产品的功能。
mybatis初始化时，会根据前面解析到的DataSource来确认当前使用的数据库产品，然后在解析映射文件时，加载不带databaseId属性的sql语句 及 带有databaseId属性的sql语句，其中，带有databaseId属性的sql语句优先级更高，会被优先选中。
Mybatis 初始化时，会根据前面解析到的 DataSource 来确认当前使用的数据库产品，然后在解析映射文件时，加载不带 databaseId属性 的 sql语句 及带有 databaseId属性 的 sql语句，其中，带有 databaseId属性 的 sql语句 优先级更高，会被优先选中。
```java
/**
* 解析 <databaseIdProvider>节点，并创建指定的 DatabaseIdProvider对象，
* 该对象会返回databaseId的值，mybatis会根据databaseId选择对应的sql语句去执行
* 该对象会返回 databaseId的值，Mybatis 会根据 databaseId 选择对应的 sql语句 去执行
*/
private void databaseIdProviderElement(XNode context) throws Exception {
DatabaseIdProvider databaseIdProvider = null;
@ -217,7 +217,7 @@ mybatis初始化时，会根据前面解析到的DataSource来确认当前使用
}
}
```
mybatis提供了DatabaseIdProvider接口，该接口的核心方法为getDatabaseId(DataSource dataSource)，主要根据dataSource查找对应的databaseId并返回。该接口的主要实现类为VendorDatabaseIdProvider。
Mybatis 提供了 DatabaseIdProvider接口，该接口的核心方法为 getDatabaseId(DataSource dataSource)，主要根据 dataSource 查找对应的 databaseId 并返回。该接口的主要实现类为 VendorDatabaseIdProvider。
```java
public class VendorDatabaseIdProvider implements DatabaseIdProvider {
@ -280,7 +280,7 @@ public class VendorDatabaseIdProvider implements DatabaseIdProvider {
}
```
### 2.4 解析&lt;mappers&gt;标签
mybatis初始化时，除了加载mybatis-config.xml文件，还会加载全部的映射配置文件，mybatis-config.xml文件的&lt;mapper&gt;节点会告诉mybatis去哪里查找映射配置文件，及使用了配置注解标识的接口。
Mybatis 初始化时，除了加载 mybatis-config.xml文件，还会加载全部的映射配置文件，mybatis-config.xml 文件的 &lt;mapper&gt;节点 会告诉 Mybatis 去哪里查找映射配置文件，及使用了配置注解标识的接口。
```java
/**
* 解析 <mappers>节点，本方法会创建 XMLMapperBuilder对象 加载映射文件，如果映射配置文件存在
@ -297,7 +297,7 @@ mybatis初始化时，除了加载mybatis-config.xml文件，还会加载全部
configuration.addMappers(mapperPackage);
} else {
// 获取 <mapper>节点 的 resource、url、mapperClass属性，这三个属性互斥，只能有一个不为空
// mybatis提供了通过包名、映射文件路径、类全名、URL四种方式引入映射器。
// Mybatis 提供了通过包名、映射文件路径、类全名、URL 四种方式引入映射器。
// 映射器由一个接口和一个 XML配置文件 组成，XML文件 中定义了一个 命名空间namespace，
// 它的值就是接口对应的全路径。
String resource = child.getStringAttribute("resource");
@ -376,9 +376,9 @@ XMLMapperBuilder也根据配置文件进行了一系列节点解析，我们着
### 3.1 解析&lt;resultMap&gt;节点
select语句 查询得到的结果是一张二维表，水平方向上是一个个字段，垂直方向上是一条条记录。而 Java 是面向对象的程序设计语言，对象是根据类的定义创建的，类之间的引用关系可以认为是嵌套结构。JDBC编程 中，为了将结果集中的数据映射成 VO对象，我们需要自己写代码从结果集中获取数据，然后将数据封装成对应的 VO对象，并设置好对象之间的关系，这种 ORM 的过程中存在大量重复的代码。
mybatis通过&lt;resultMap&gt;节点定义了ORM规则，可以满足大部分的映射需求，减少重复代码，提高开发效率。
Mybatis 通过 &lt;resultMap&gt;节点 定义了 ORM规则，可以满足大部分的映射需求，减少重复代码，提高开发效率。
在分析&lt;resultMap&gt;节点的解析过程之前，先看一下该过程使用的数据结构。每个ResultMapping对象记录了结果集中的一列与JavaBean中一个属性之间的映射关系。&lt;resultMap&gt;节点下除了&lt;discriminator&gt;子节点的其它子节点 都会被解析成对应的ResultMapping对象。
在分析 &lt;resultMap&gt;节点 的解析过程之前，先看一下该过程使用的数据结构。每个 ResultMapping对象 记录了结果集中的一列与 JavaBean 中一个属性之间的映射关系。&lt;resultMap&gt;节点 下除了 &lt;discriminator&gt;子节点 的其它子节点，都会被解析成对应的 ResultMapping对象。
```java
public class ResultMapping {
@ -442,7 +442,7 @@ public class ResultMap {
private Boolean autoMapping;
}
```
了解了ResultMapping 和ResultMap 记录的信息之后，下面开始介绍&lt;resultMap&gt;节点的解析过程。在XMLMapperBuilder中通过resultMapElements()方法解析映射配置文件中的全部&lt;resultMap&gt;节点，该方法会循环调用resultMapElement()方法处理每个＜resultMap＞节点。
了解了 ResultMapping 和 ResultMap 记录的信息之后，下面开始介绍 &lt;resultMap&gt;节点 的解析过程。在 XMLMapperBuilder 中通过 resultMapElements()方法 解析映射配置文件中的全部 &lt;resultMap&gt;节点，该方法会循环调用 resultMapElement()方法 处理每个 &lt;resultMap&gt; 节点。
```java
private ResultMap resultMapElement(XNode resultMapNode) throws Exception {
return resultMapElement(resultMapNode, Collections.<ResultMapping> emptyList());
@ -498,7 +498,7 @@ public class ResultMap {
}
}
```
从上面的代码我们可以看到，mybatis从&lt;resultMap&gt;节点获取到id属性和type属性值之后，就会通过XMLMapperBuilder的buildResultMappingFromContext()方法为&lt;result&gt;节点创建对应的ResultMapping 对象。
从上面的代码我们可以看到，Mybatis 从 &lt;resultMap&gt;节点 获取到 id属性 和 type属性值 之后，就会通过 XMLMapperBuilder 的 buildResultMappingFromContext()方法 为 &lt;result&gt;节点 创建对应的 ResultMapping对象。
```java
/**
* 根据上下文环境构建 ResultMapping
@ -605,12 +605,12 @@ public class MapperBuilderAssistant extends BaseBuilder {
}
```
## 4 XMLStatementBuilder
这一部分看的不是很懂，暂时保留，日后深入理解了再写。
## 5 绑定Mapper接口
通过之前对binding模块的解析可知，每个映射配置文件的命名空间可以绑定一个Mapper接口，并注册到MapperRegistry中。XMLMapperBuilder的bindMapperForNamespace()方法中，完成了映射配置文件与对应Mapper 接
口的绑定。
通过之前对 binding模块 的解析可知，每个映射配置文件的命名空间可以绑定一个 Mapper接口，并注册到 MapperRegistry中。XMLMapperBuilder 的 bindMapperForNamespace()方法 中，完成了映射配置文件与对应 Mapper接口 的绑定。
```java
public class XMLMapperBuilder extends BaseBuilder {
private void bindMapperForNamespace() {

73
docs/Netty/AdvancedFeaturesOfNetty/Netty架构设计.md
Unescape View File

@ -0,0 +1,73 @@
本博文用于重点分析 Netty 的逻辑架构及关键的架构质量属性，希望有助于大家从 Netty 的架构设计中汲取营养，设计出高性能、高可靠
性和可扩展的程序。
## Netty的三层架构设计
Netty 采用了典型的三层网络架构进行设计和开发，其逻辑架构图如下所示。
![avatar](/images/Netty/Netty逻辑架构图.png)
### 通信调度层 Reactor
它由一系列辅助类完成，包括 Reactor线程 NioEventLoop 及其父类，NioSocketChannel / NioServerSocketChannel 及其父类，Buffer组件，Unsafe组件 等。该层的主要职责就是**监听网络的读写和连接操作**，负责**将网络层的数据读取到内存缓冲区**，然后触发各种网络事件，例如连接创建、连接激活、读事件、写事件等，将这些事件触发到 PipeLine 中，由 PipeLine 管理的责任链来进行后续的处理。
### 责任链层 Pipeline
它负责上述的各种网络事件 在责任链中的有序传播，同时负责动态地编排责任链。责任链可以选择监听和处理自己关心的事件，它可以拦截处理事件，以及向前向后传播事件。不同应用的 Handler节点 的功能也不同，通常情况下，往往会开发 编解码Hanlder 用于消息的编解码，可以将外部的协议消息转换成 内部的POJO对象，这样上层业务则只需要关心处理业务逻辑即可，不需要感知底层的协议差异和线程模型差异，实现了架构层面的分层隔离。
### 业务逻辑编排层 Service ChannelHandler
业务逻辑编排层通常有两类：一类是纯粹的业务逻辑编排，还有一类是其他的应用层协议插件，用于特定协议相关的会话和链路管理。例如，CMPP协议，用于管理和中国移动短信系统的对接。
架构的不同层面，需要关心和处理的对象都不同，通常情况下，对于业务开发者，只需要关心责任链的拦截和 业务Handler 的编排。因为应用层协议栈往往是开发一次，到处运行，所以实际上对于业务开发者来说，只需要关心服务层的业务逻辑开发即可。各种应用协议以插件的形式提供，只有协议开发人员需要关注协议插件，对于其他业务开发人员来说，只需关心业务逻辑定制。这种分层的架构设计理念实现了 NIO框架 各层之间的解耦，便于上层业务协议栈的开发和业务逻辑的定制。
正是由于 Netty 的分层架构设计非常合理，基于 Netty 的各种应用服务器和协议栈开发才能够如雨后春笋般得到快速发展。
## 关键的架构质量属性
### 性能
影响最终产品的性能因素非常多，其中软件因素如下。
- 架构不合理导致的性能问题；
- 编码实现不合理导致的性能问题，例如，锁没用好导致的性能瓶颈。
硬件因素如下。
- 服务器硬件配置太低导致的性能问题；
- 带宽、磁盘的 IOPS 等限制导致的 IO操作 性能差；
- 测试环境被共用导致被测试的软件产品受到影响。
尽管影响产品性能的因素非常多，但是架构的性能模型合理与否对性能的影响非常大。如果一个产品的架构设计得不好，无论开发如何努力，都很难开发出一个高性能、高可用的软件产品。
“性能是设计出来的，而不是测试出来的”。下面我们看看 Netty 的架构设计是如何实现高性能的。
1. 采用非阻塞的 NIO类库，基于 Reactor 模式实现，解决了传统 同步阻塞IO模式 下一个服务端无法平滑地处理线性增长的客户端的问题。
2. TCP 接收和发送缓冲区**使用直接内存代替堆内存，避免了内存复制**，提升了 IO 读取和写入的性能。
3. 支持通过内存池的方式循环利用 ByteBuffer，避免了频繁创建和销毁 ByteBuffer 带来的性能损耗。
4. 可配置的 IO线程数、TCP参数 等，为不同的用户场景提供定制化的调优参数，满足不同的性能场景。
5. 采用环形数组缓冲区实现无锁化并发编程，代替传统的线程安全容器或者锁。
6. 合理地使用线程安全容器、原子类等，提升系统的并发处理能力。
7. 关键资源的处理使用单线程串行化的方式，避免多线程并发访问带来的锁竞争和额外的 CPU资源消耗问题。
8. 通过引用计数器及时地申请释放不再被引用的对象，细粒度的内存管理降低了 GC 的频率，减少了频繁 GC 带来的延时和 CPU损耗。
### 可靠性
作为一个高性能的异步通信框架，架构的可靠性是大家选择的另一个重要依据。下面我们看一下 Netty架构 的可靠性设计。
**1、链路有效性检测**
由于长连接不需要每次发送消息都创建链路，也不需要在消息交互完成时关闭链路，因此相对于短连接性能更高。对于长连接，一旦链路建立成功便一直维系双方之间的链路，直到系统退出。
为了保证长连接的链路有效性，往往需要通过心跳机制周期性地进行链路检测。使用周期性心跳的原因是：在系统空闲时，例如凌晨，往往没有业务消息。如果此时链路被防火墙 Hang住，或者遭遇网络闪断、网络单通等，通信双方无法识别出这类链路异常。等到第二天业务高峰期到来时，瞬间的海量业务冲击会导致消息积压无法发送给对方，由于链路的重建需要时间，这期间业务会大量失败 (集群或者分布式组网情况会好一些)。为了解决这个问题，需要周期性的 “心跳检测” 对链路进行有效性检查，一旦发生问题，可以及时关闭链路，重建 TCP连接。
当有业务消息时，无须心跳检测，可以由业务消息进行链路可用性检测。所以心跳消息往往是在链路空闲时发送的。为了支持心跳机制，Netty 提供了如下两种链路空闲检测机制。
- 读空闲超时机制：当经过 连续的周期 T 没有消息可读时，触发 超时Handler，用户可以基于 该读空闲超时Handler 发送心跳消息，进行链路检测，如果连续 N个周期 仍然没有读取到心跳消息，可以主动关闭这条链路。
- 写空闲超时机制：当经过 连续的周期 T 没有消息要发送时，触发 超时Handler，用户可以基于 该写空闲超时Handler 发送心跳消息，进行链路检测，如果连续 N 个周期 仍然没有接收到对方的心跳消息，可以主动关闭这条链路。
为了满足不同用户场景的心跳定制，Netty 提供了空闲状态检测事件通知机制，用户可以订阅：空闲超时事件、读空闲超时机制、写空闲超时事件，在接收到对应的空闲事件之后，灵活地进行定制。
**2、内存保护机制**
Netty 提供多种机制对内存进行保护，包括以下几个方面。
- 通过对象引用计数器对 Netty 的 ByteBuffer 等内置对象进行细粒度的内存申请和释放，对非法的对象引用进行检测和保护。
- 通过内存池来重用 ByteBuffer，节省内存。
- 可设置的内存容量上限，包括 ByteBuffer、线程池线程数等。
### 可定制性
Netty 的可定制性主要体现在以下几点。
- 责任链模式：ChannelPipeline 基于责任链模式开发，便于业务逻辑的拦截、定制和扩展。
- 基于接口的开发：关键的类库都提供了接口或者抽象类，如果 Netty 自身的实现无法满足用户的需求，可以由用户自定义实现相关接口。
- 提供了大量工厂类，通过重载这些工厂类可以按需创建出用户实现的对象。
- 提供了大量的系统参数供用户按需设置，增强系统的场景定制性。
### 可扩展性
基于 Netty 的 基本NIO框架，可以方便地进行应用层协议定制，例如，HTTP协议栈、Thrift协议栈、FTP协议栈 等。这些扩展不需要修改 Netty 的源码，直接基于 Netty 的二进制类库即可实现协议的扩展和定制。目前，业界存在大量的基于 Netty框架 开发的协议，例如基于 Netty 的 HTTP协议、Dubbo协议、RocketMQ内部私有协议 等。

1
docs/Netty/AdvancedFeaturesOfNetty/Netty高可靠性设计.md
Unescape View File

@ -0,0 +1 @@
努力编写中......

150
docs/Netty/AdvancedFeaturesOfNetty/Netty高性能之道.md
Unescape View File

@ -0,0 +1,150 @@
作为一个高性能的 NIO通信框架，Netty 被广泛应用于大数据处理、互联网消息中间件、游戏和金融行业等。大多数应用场景对底层的通信框架都有很高的性能要求，作为综合性能最高的 NIO框架 之一，Netty 可以完全满足不同领域对高性能通信的需求。本章我们将从架构层对 Netty 的高性能设计和关键代码实现进行剖析，看 Netty 是如何支撑高性能网络通信的。
## RPC 调用性能模型分析
### 传统 RPC 调用性能差的原因
**一、网络传输方式问题。**
传统的 RPC框架 或者基于 RMI 等方式的 远程过程调用 采用了同步阻塞I/O，当客户端的并发压力或者网络时延增大之后，同步阻塞I/O 会由于频繁的 wait 导致 I/O线程 经常性的阻塞，由于线程无法高效的工作，I/O 处理能力自然下降。
采用 BIO通信模型 的服务端，通常由一个独立的 Acceptor线程 负责监听客户端的连接，接收到客户端连接之后，为其创建一个新的线程处理请求消息，处理完成之后，返回应答消息给客户端，线程销毁，这就是典型的 “ 一请求，一应答 ” 模型。该架构最大的问题就是不具备弹性伸缩能力，当并发访问量增加后，服务端的线程个数和并发访问数成线性正比，由于线程是 Java虛拟机 非常宝贵的系统资源，当线程数膨胀之后，系统的性能急剧下降，随着并发量的继续增加，可能会发生句柄溢出、线程堆栈溢出等问题，并导致服务器最终宕机。
**二、序列化性能差。**
Java序列化 存在如下几个典型问题：
1. Java 序列化机制是 Java 内部的一 种对象编解码技术，无法跨语言使用。例如对于异构系统之间的对接，Java序列化 后的码流需要能够通过其他语言反序列化成原始对象，这很难支持。
2. 相比于其他开源的序列化框架，Java序列化 后的码流太大，无论是网络传输还是持久化到磁盘，都会导致额外的资源占用。
3. 序列化性能差，资源占用率高 ( 主要是 CPU 资源占用高 )。
**三、线程模型问题。**
由于采用 同步阻塞I/O，这会导致每个 TCP连接 都占用 1 个线程，由于线程资源是 JVM虚拟机 非常宝贵的资源，当 I/O 读写阻塞导致线程无法及时释放时，会导致系统性能急剧下降，严重的甚至会导致虚拟机无法创建新的线程。
### IO 通信性能三原则
尽管影响 I/O通信性能 的因素非常多，但是从架构层面看主要有三个要素。
1. 传输：用什么样的通道将数据发送给对方。可以选择 BIO、NIO 或者 AIO，I/O模型 在很大程度上决定了通信的性能；
2. 协议：采用什么样的通信协议，HTTP等公有协议或者内部私有协议。协议的选择不同，性能也不同。相比于公有协议，内部私有协议的性能通常可以被设计得更优；
3. 线程模型：数据报如何读取？读取之后的编解码在哪个线程进行，编解码后的消息如何派发，Reactor 线程模型的不同，对性能的影响也非常大。
## 异步非阻塞通信
在 I/O编程 过程中，当需要同时处理多个客户端接入请求时，可以利用多线程或者 I/O多路复用技术 进行处理。I/O多路复用技术 通过把多个 I/O 的阻塞复用到同一个 select 的阻塞上，从而使得系统在单线程的情况下可以同时处理多个客户端请求。与传统的多线程 / 多进程模型比，I/O多路复用 的最大优势是系统开销小，系统不需要创建新的额外进程或者线程，也不需要维护这些进程和线程的运行，降低了系统的维护工作量，节省了系统资源。
JDK1.4 提供了对非阻塞 I/O 的支持，JDK1.5 使用 epoll 替代了传统的 select / poll，极大地提升了 NIO通信 的性能。
与 Socket 和 ServerSocket 类相对应，NIO 也提供了 SocketChannel 和 ServerSocketChannel 两种不同的套接字通道实现。这两种新增的通道都支持阻塞和非阻塞两种模式。阻塞模式使用非常简单，但是性能和可靠性都不好，非阻塞模式则正好相反。开发人员一般可以根据自己的需要来选择合适的模式，一般来说，低负载、低并发的应用程序可以选择 同步阻塞I/O 以降低编程复杂度。但是对于高负载、高并发的网络应用，需要使用 NIO 的非阻塞模式进行开发。
Netty 的 I/O 线程 NioEventLoop 由于聚合了 多路复用器Selector，可以同时并发处理成百上千个客户端 SocketChannel。由于读写操作都是非阻塞的，这就可以充分提升 I/O线程 的运行效率，避免由频繁的 I/O阻塞 导致的线程挂起。另外，由于 Netty 采用了异步通信模式，一个 I/O线程 可以并发处理 N 个客户端连接和读写操作，这从根本上解决了传统 同步阻塞I/O “ 一连接，一线程 ” 模型，架构的性能、弹性伸缩能力和可靠性都得到了极大的提升。
## 高效的 Reactor 线程模型
常用的 Reactor线程模型 有三种，分别如下。
1. Reactor单线程模型；
2. Reactor 多线程模型；
3. 主从Reactor多线程模型。
Reactor单线程模型，指的是所有的 I/O操作 都在同一个 NIO线程 上面完成，NIO线程 的职责如下：
1. 作为 NIO服务端，接收客户端的 TCP连接；
2. 作为 NIO客户端，向服务端发起 TCP连接；
3. 读取通信对端的请求或者应答消息；
4. 向通信对端发送消息请求或者应答消息。
由于 Reactor模式 使用的是 异步非阻塞I/O，所有的 I/O操作 都不会导致阻塞，理论上一个线程可以独立处理所有 I/O 相关的操作。从架构层面看，一个 NIO线程 确实可以完成其承担的职责。例如，通过 Acceptor 接收客户端的 TCP连接请求消息，链路建立成功之后，通过 Dispatch 将对应的 ByteBuffer 派发到指定的 Handler 上进行消息解码。用户Handler 可以通过 NIO线程 将消息发送给客户端。
对于一些小容量应用场景，可以使用单线程模型，但是对于高负载、大并发的应用却不合适，主要原因如下。
1. 一个 NIO线程 同时处理成百上千的链路，性能上无法支撑。即便 NIO线程 的 CPU负荷 达到 100%，也无法满足海量消息的编码，解码、读取和发送；
2. 当 NIO线程 负载过重之后，处理速度将变慢，这会导致大量客户端连接超时，超时之后往往会进行重发，这更加重了 NIO线程 的负载，最终会导致大量消息积压和处理超时，NIO线程 会成为系统的性能瓶颈；
3. 可靠性问题。一旦 NIO线程 意外跑飞，或者进入死循环，会导致整个系统通信模块不可用，不能接收和处理外部消息，造成节点故障。
为了解决这些问题，演进出了 Reactor多线程模型，下面我们看一下 Reactor多线程模型。
Rector多线程模型 与单线程模型最大的区别就是有一组 NIO线程 处理 I/O操作，它的特点如下。
1. 有一个专门的 NIO线程 —— Acceptor线程 用于监听服务端口，接收客户端的 TCP连接请求；
2. 网络IO操作 —— 读、写等由一个 NIO线程池 负责，线程池可以采用标准的 JDK线程池 实现，它包含一个任务队列和 N 个可用的线程，由这些 NIO线程 负责消息的读取、解码、编码和发送；
3. 1 个 NIO线程 可以同时处理 N 条链路，但是 1 个链路只对应 1 个 NIO线程，以防止发生并发操作问题。
在绝大多数场景下，Reactor多线程模型 都可以满足性能需求，但是，在极特殊应用场景中，一个 NIO线程 负责监听和处理所有的客户端连接可能会存在性能问题。例如百万客户端并发连接，或者服务端需要对客户端的握手消息进行安全认证，认证本身非常损耗性能。在这类场景下，单独一个 Acceptor线程 可能会存在性能不足问题，为了解决性能问题，产生了第三种 Reactor线程模型 —— 主从Reactor多线程模型。
主从Reactor线程模型 的特点是，服务端用于接收客户端连接的不再是个单线程的连接处理Acceptor，而是一个独立的 Acceptor线程池。Acceptor 接收到客户端 TCP连接请求 处理完成后 ( 可能包含接入认证等 )，将新创建的 SocketChannel 注册到 I/O处理线程池 的某个I/O线程 上，由它负责 SocketChannel 的读写和编解码工作。Acceptor线程池 只用于客户端的登录、握手和安全认证，一旦链路建立成功，就将链路注册到 I/O处理线程池的 I/O线程 上，每个 I/O线程 可以同时监听 N 个链路，对链路产生的 IO事件 进行相应的 消息读取、解码、编码及消息发送等操作。
利用 主从Reactor线程模型，可以解决 1 个 Acceptor线程 无法有效处理所有客户端连接的性能问题。因此，Netty官方 也推荐使用该线程模型。
事实上，Netty 的线程模型并非固定不变，通过在启动辅助类中创建不同的 EventLoopGroup实例 并进行适当的参数配置，就可以支持上述三种 Reactor线程模型。可以根据业务场景的性能诉求，选择不同的线程模型。
Netty 单线程模型 服务端代码示例如下。
```java
EventLoopGroup reactor = new NioEventLoopGroup(1);
ServerBootstrap bootstrap = new ServerBootstrap();
bootstrap.group(reactor, reactor)
.channel(NioServerSocketChannel.class)
......
```
Netty 多线程模型 代码示例如下。.
```java
EventLoopGroup acceptor = new NioEventLoopGroup(1);
EventLoopGroup ioGroup = new NioEventLoopGroup();
ServerBootstrap bootstrap = new ServerBootstrap();
bootstrap.group(acceptor, ioGroup)
.channel(NioServerSocketChannel.class)
......
```
Netty 主从多线程模型 代码示例如下。
```java
EventLoopGroup acceptorGroup = new NioEventLoopGroup();
EventLoopGroup ioGroup = new NioEventLoopGroup();
ServerBootstrap bootstrap = new ServerBootstrap();
bootstrap.group(acceptorGroup, ioGroup)
.channel(NioServerSocketChannel.class)
......
```
## 无锁化的串行设计
在大多数场景下，并行多线程处理可以提升系统的并发性能。但是，如果对于共享资源的并发访问处理不当，会带来严重的锁竞争，这最终会导致性能的下降。为了尽可能地避免锁竞争带来的性能损耗，可以通过串行化设计，即消息的处理尽可能在同一个线程内完成，期间不进行线程切换，这样就避免了多线程竞争和同步锁。
为了尽可能提升性能，Netty 对消息的处理 采用了串行无锁化设计，在 I/O线程 内部进行串行操作，避免多线程竞争导致的性能下降。Netty 的串行化设计工作原理图如下图所示。
![avatar](/images/Netty/Netty串行化设计工作原理.png)
Netty 的 NioEventLoop 读取到消息之后，直接调用 ChannelPipeline 的 fireChannelRead(Object msg)，只要用户不主动切换线程，一直会由 NioEventLoop 调用到 用户的Handler，期间不进行线程切换。这种串行化处理方式避免了多线程操作导致的锁的竞争，从性能角度看是最优的。
## 零拷贝
Netty的 “ 零拷贝 ” 主要体现在如下三个方面。
第一种情况。Netty 的接收和发送 ByteBuffer 采用 堆外直接内存 (DIRECT BUFFERS) 进行 Socket读写，不需要进行字节缓冲区的二次拷贝。如果使用传统的 堆内存(HEAP BUFFERS) 进行 Socket读写，JVM 会将 堆内存Buffer 拷贝一份到 直接内存 中，然后才写入 Socket。相比于堆外直接内存，消息在发送过程中多了一次缓冲区的内存拷贝。
下面我们继续看第二种 “ 零拷贝 ” 的实现 CompositeByteBuf，它对外将多个 ByteBuf 封装成一个 ByteBuf，对外提供统一封装后的 ByteBuf接口。CompositeByteBuf 实际就是个 ByteBuf 的装饰器，它将多个 ByteBuf 组合成一个集合，然后对外提供统一的 ByteBuf接口，添加 ByteBuf，不需要做内存拷贝。
第三种 “ 零拷贝 ” 就是文件传输，Netty 文件传输类 DefaultFileRegion 通过 transferTo()方法 将文件发送到目标 Channel 中。很多操作系统直接将文件缓冲区的内容发送到目标 Channel 中，而不需要通过循环拷贝的方式，这是一种更加高效的传输方式，提升了传输性能，降低了 CPU 和内存占用，实现了文件传输的 “ 零拷贝 ” 。
## 内存池
随着 JVM虚拟机 和 JIT即时编译技术 的发展，对象的分配和回收是个非常轻量级的工作。但是对于 缓冲区Buffer，情况却稍有不同，特别是对于堆外直接内存的分配和回收，是一件耗时的操作。为了尽量重用缓冲区，Netty 提供了基于内存池的缓冲区重用机制。ByteBuf 的子类中提供了多种 PooledByteBuf 的实现，基于这些实现 Netty 提供了多种内存管理策略，通过在启动辅助类中配置相关参数，可以实现差异化的定制。
## Socket 与 SocketChannel
网络由下往上分为 物理层、数据链路层、网络层、传输层和应用层。IP协议 对应于网络层，TCP协议 对应于传输层，而 HTTP协议 对应于应用层，三者从本质上来说没有可比性，Socket 则是对 TCP/IP协议 的封装和应用 (程序员层面上)。也可以说，TPC/IP协议 是传输层协议，主要解决数据如何在网络中传输，而 HTTP 是应用层协议，主要解决如何包装数据。Socket 是对 TCP/IP协议 的封装，Socket 本身并不是协议，而是一个 调用接口(API)。 通过 Socket，我们才能使用 TCP/IP协议。
### 一、利用 Socket 建立网络连接的步骤
建立 Socket连接 至少需要一对套接字，其中一个运行于客户端，称为 clientSocket ，另一个运行于服务器端，称为 serverSocket 。套接字之间的连接过程分为三个步骤：服务器监听，客户端请求，连接确认。
1. 服务器监听：服务器端套接字并不定位具体的客户端套接字，而是处于等待连接的状态，实时监控网络状态，等待客户端的连接请求。
2. 客户端请求：指客户端的套接字提出连接请求，要连接的目标是服务器端的套接字。为此，客户端的套接字必须首先描述它要连接的服务器的套接字，指出服务器端套接字的地址和端口号，然后就向服务器端套接字提出连接请求。
3. 连接确认：当服务器端套接字监听到或者说接收到客户端套接字的连接请求时，就响应客户端套接字的请求，建立一个新的线程，把服务器端套接字的描述发给 客户端，一旦客户端确认了此描述，双方就正式建立连接。而服务器端套接字继续处于监听状态，继续接收其他客户端套接字的连接请求。
### 二、HTTP连接 的特点
　　HTTP协议 是 Web联网 的基础，也是手机联网常用的协议之一，HTTP协议 是建立在 TCP协议 之上的一种应用。HTTP连接 最显著的特点是客户端发送的每次请求 都需要服务器回送响应，在请求结束后，会主动释放连接。从建立连接到关闭连接的过程称为 “一次连接”。
### 三、TCP 和 UDP 的区别
1. TCP 是面向连接的，虽然说网络的不安全不稳定特性决定了多少次握手都不能保证连接的可靠性，但 TCP 的三次握手在很大程度上 保证了连接的可靠性。而 UDP 不是面向连接的，UDP 传送数据前并不与对方建立连接，对接收到的数据也不发送确认信号，发送端不知道数据是否会正确接收，当然也不用重发，所以说 UDP 是无连接的、不可靠的一种数据传输协议。
2. 也正由于 1 所说的特点，使得 UDP 的开销更小，数据传输速率更高，因为不必进行收发数据的确认，所以 UDP 的实时性更好。
### 四、Socket 与 SocketChannel 有什么区别
Socket、SocketChannel 二者的实质都是一样的，都是为了实现客户端与服务器端的连接而存在的，但是在使用上却有很大的区别。具体如下：
1. 所属包不同。Socket 在 java.net包 中，而 SocketChannel 在 java.nio包 中。
2. 异步方式不同。从包的不同，我们大体可以推断出他们主要的区别：Socket 是阻塞连接，SocketChannel 可以设置为非阻塞连接。使用 ServerSocket 与 Socket 的搭配，服务端Socket 往往要为每一个 客户端Socket 分配一个线程，而每一个线程都有可能处于长时间的阻塞状态中。过多的线程也会影响服务器的性能。而使用 SocketChannel 与 ServerSocketChannel 的搭配可以非阻塞通信，这样使得服务器端只需要一个线程就能处理所有 客户端Socket 的请求。
3. 性能不同。一般来说，高并发场景下，使用 SocketChannel 与 ServerSocketChannel 的搭配会有更好的性能。
4. 使用方式不同。Socket、ServerSocket类 可以传入不同参数直接实例化对象并绑定 IP 和 端口。而 SocketChannel、ServerSocketChannel类 需要借助 Selector类。
下面是 SocketChannel方式 需要用到的几个核心类：
ServerSocketChannel：ServerSocket 的替代类, 支持阻塞通信与非阻塞通信。
SocketChannel：Socket 的替代类, 支持阻塞通信与非阻塞通信。
Selector：为 ServerSocketChannel 监控接收客户端连接就绪事件, 为 SocketChannel 监控连接服务器读就绪和写就绪事件。
SelectionKey：代表 ServerSocketChannel 及 SocketChannel 向 Selector 注册事件的句柄。当一个 SelectionKey对象 位于 Selector对象 的 selected-keys集合 中时，就表示与这个 SelectionKey对象 相关的事件发生了。在 SelectionKey类 中有如下几个静态常量：
- SelectionKey.OP_ACCEPT，客户端连接就绪事件，等于监听 serverSocket.accept()，返回一个 socket。
- SelectionKey.OP_CONNECT，准备连接服务器就绪，跟上面类似，只不过是对于 socket 的，相当于监听了 socket.connect()。
- SelectionKey.OP_READ，读就绪事件, 表示输入流中已经有了可读数据, 可以执行读操作了。
- SelectionKey.OP_WRITE，写就绪事件, 表示可以执行写操作了。

57
docs/Netty/IOTechnologyBase/IO模型.md
Unescape View File

@ -0,0 +1,57 @@
## Linux 网络 IO 模型简介
Linux 的内核将所有外部设备都看做一个文件来操作，对一个文件的读写操作会调用内核提供的系统命令，返回一个fd (file descriptor，文件描述符)。而对一个 socket 的读写也会有相应的描述符，称为 socket fd (socket 描述符)，描述符就是一个数字，它指向内核中的一个结构体(文件路径，数据区等一些属性)。根据UNIX网络编程对 I/O模型 的分类，UNIX 提供了5种 I/O模型，分别如下。
#### 1、阻塞IO模型
在内核将数据准备好之前，系统调用会一直等待所有的套接字（Socket）传来数据，默认的是阻塞方式。
![avatar](/images/Netty/阻塞IO模型.png)
Java 中的 socket.read()方法 最终会调用底层操作系统的 recvfrom方法，OS 会判断来自网络的数据报是否准备好，当数据报准备好了之后，OS 就会将数据从内核空间拷贝到用户空间（因为我们的用户程序只能获取用户空间的内存，无法直接获取内核空间的内存）。拷贝完成之后 socket.read() 就会解除阻塞，并得到网络数据的结果。
BIO中的阻塞，就是阻塞在2个地方：
1. OS 等待数据报通过网络发送过来，如果建立连接后数据一直没过来，就会白白浪费线程的资源；
2. 将数据从内核空间拷贝到用户空间。
在这2个时候，我们的线程会一直被阻塞，啥事情都不干。
#### 2、非阻塞IO模型
![avatar](/images/Netty/非阻塞IO模型.png)
每次应用程序询问内核是否有数据报准备好，当有数据报准备好时，就进行拷贝数据报的操作，从内核拷贝到用户空间，和拷贝完成返回的这段时间，应用进程是阻塞的。但在没有数据报准备好时，并不会阻塞程序，内核直接返回未准备好的信号，等待应用进程的下一次询问。但是，轮寻对于CPU来说是较大的浪费，一般只有在特定的场景下才使用。
从图中可以看到，非阻塞IO 的 recvfrom调用 会立即得到一个返回结果(数据报是否准备好)，我们可以根据返回结果继续执行不同的逻辑。而阻塞IO 的recvfrom调用，如果无数据报准备好，一定会被阻塞住。虽然 非阻塞IO 比 阻塞IO 少了一段阻塞的过程，但事实上 非阻塞IO 这种方式也是低效的，因为我们不得不使用轮询方法区一直问 OS：“我的数据好了没啊”。
**BIO 不会在 拷贝数据之前 阻塞，但会在将数据从内核空间拷贝到用户空间时阻塞。一定要注意这个地方，Non-Blocking 还是会阻塞的。**
#### 3、IO复用模型
Linux 提供 select/poll，进程通过将一个或多个 fd 传递给 select 或 poll系统 调用，阻塞发生在 select/poll 操作上。select/poll 可以帮我们侦测多个 fd 是否处于就绪状态，它们顺序扫描 fd 是否就绪，但支持的 fd 数量有限，因此它的使用也受到了一些制约。Linux 还提供了一个 epoll系统调用，epoll 使用 基于事件驱动方式 代替 顺序扫描，因此性能更高，当有 fd 就绪时，立即回调函数 rollback。
![avatar](/images/Netty/IO复用模型.png)
#### 4、信号驱动IO模型
首先开启套接口信号驱动IO功能，并通过系统调用 sigaction 执行一个信号处理函数（此系统调用立即返回，进程继续工作，它是非阻塞的）。当数据准备就绪时，就为该进程生成一个 SIGIO信号，通过信号回调通知应用程序调用 recvfrom 来读取数据，并通知主循环函数处理数据。
![avatar](/images/Netty/信号驱动IO模型.png)
#### 5、异步IO模型
告知内核启动某个操作，并让内核在整个操作完成后(包括将数据从内核复制到用户自己的缓冲区)通知我们。这种模型与信号驱动模型的主要区别是：信号驱动IO 由内核通知我们何时可以开始一个 IO 操作；异步IO模型 由内核通知我们 IO操作何时已经完成。
![avatar](/images/Netty/异步IO模型.png)
从这五种 IO模型的结构 也可以看出，阻塞程度：阻塞IO>非阻塞IO>多路转接IO>信号驱动IO>异步IO，效率是由低到高的。
最后，我们看一下数据从客户端到服务器，再由服务器返回结果数据的整体IO流程，以便我们更好地理解上述的IO模型。
![avatar](/images/Netty/数据在客户端及服务器之间的整体IO流程.png)
## IO 多路复用技术
Java NIO 的核心类库中 多路复用器Selector 就是基于 epoll 的多路复用技术实现。
在 IO编程 过程中，当需要同时处理多个客户端接入请求时，可以利用多线程或者 IO多路复用技术 进行处理。IO多路复用技术 通过把多个 IO 的阻塞复用到同一个 select 的阻塞上，从而使得系统在单线程的情况下可以同时处理多个客户端请求。与传统的多线程/多进程模型比，IO多路复用 的最大优势是系统开销小，系统不需要创建新的额外进程或线程，也不需要维护这些进程和线程的运行，降低了系统的维护工作量，节省了系统资源，IO多路复用 的主要应用场景如下。
- 服务器需要同时处理多个处于监听状态或者多个连接状态的套接字;
- 服务器需要同时处理多种网络协议的套接字。
目前支持 IO多路复用 的系统调用有 select、pselect、poll、epoll，在 Linux网络编程 过程中，很长一段时间都使用 select 做轮询和网络事件通知，然而 select 的一些固有缺陷导致了它的应用受到了很大的限制，最终 Linux 选择了 epoll。epoll 与 select 的原理比较类似，为了克服 select 的缺点，epoll 作了很多重大改进，现总结如下。
1. 支持一个进程打开的 socket描述符 (fd) 不受限制(仅受限于操作系统的最大文件句柄数)；
2. IO效率 不会随着 FD 数目的增加而线性下降；
3. epoll的API更加简单。
值得说明的是，用来克服 select/poll 缺点的方法不只有 epoll, epoll 只是一种 Linux 的实现方案。

318
docs/Netty/IOTechnologyBase/四种IO编程及对比.md
Unescape View File

@ -0,0 +1,318 @@
## 传统的BIO编程
网络编程的基本模型是 Client/Server 模型，也就是两个进程之间进行相互通信，其中服务端提供位置信息(绑定的IP地址和监听端口)，客户端通过连接操作向服务端监听的地址发起连接请求，通过三次握手建立连接，如果连接建立成功，双方就可以通过网络套接字(Socket) 进行通信。
在基于传统同步阻塞模型开发中，ServerSocket 负责绑定IP 地址，启动监听端口，Socket负责发起连接操作。连接成功之后，双方通过输入和输出流进行同步阻塞式通信。
### BIO通信模型
通过下面的通信模型图可以发现，采用 BIO 通信模型的服务端，通常由一个独立的 Acceptor线程 负责监听客户端的连接，它接收到客户
端连接请求之后为每个客户端创建一个新的线程进行链路处理，处理完成之后，通过输出流返回应答给客户端，线程销毁。这就是典型的 “一请求一应答” 通信模型。
![avatar](/images/Netty/BIO通信模型.png)
该模型最大的问题就是缺乏弹性伸缩能力，当客户端并发访问量增加后，服务端的线程个数和客户端并发访问数呈1: 1的正比关系，由于线程是 Java虚拟机 非常宝贵的系统资源，当线程数膨胀之后，系统的性能将急剧下降，随着并发访问量的继续增大，系统会发生线程堆栈溢出、创建新线程失败等问题，并最终导致进程宕机或者僵死，不能对外提供服务。
在高性能服务器应用领域，往往需要面向成千上万个客户端的并发连接，这种模型显然无法满足高性能、高并发接入的场景。为了改进 一线程一连接 模型，后来又演进出了一种通过线程池或者消息队列实现1个或者多个线程处理N个客户端的模型，由于它的底层通信机制依然使用 同步阻塞IO，所以被称为 “伪异步”。
## 伪异步IO编程
为了解决 同步阻塞IO 面临的一个链路需要一个线程处理的问题，后来有人对它的线程模型进行了优化，后端通过一个线程池来处理多个客户端的请求接入，形成 客户端个数M：线程池最大线程数N 的比例关系，其中 M 可以远远大于 N。通过线程池可以灵活地调配线程资源，设置线程的最大值，防止由于海量并发接入导致线程耗尽。
### 伪异步IO模型图
采用线程池和任务队列可以实现一种叫做 伪异步的IO通信框架，其模型图下。当有新的客户端接入时，将客户端的 Socket 封装成一个 Task对象 (该类实现了java.lang.Runnable接口)，投递到后端的线程池中进行处理，JDK 的线程池维护一个消息队列和 N 个活跃线程，对消息队列中的任务进行处理。由于线程池可以设置消息队列的大小和最大线程数，因此，它的资源占用是可控的，无论多少个客户端并发访问，都不会导致资源的耗尽和宕机。
![avatar](/images/Netty/伪异步IO通信模型.png)
伪异步 IO通信框架 采用了线程池实现，因此避免了为每个请求都创建一个独立线程造成的线程资源耗尽问题。但是由于它底层的通信依然采用同步阻塞模型，因此无法从根本上解决问题。
### 伪异步IO编程弊端分析
要对 伪异步IO编程 的弊端进行深入分析，首先我们看两个 Java同步IO 的 API说明，随后结合代码进行详细分析。
```java
public abstract class InputStream implements Closeable {
/**
* Reads the next byte of data from the input stream. The value byte is
* returned as an <code>int</code> in the range <code>0</code> to
* <code>255</code>. If no byte is available because the end of the stream
* has been reached, the value <code>-1</code> is returned. This method
* blocks until input data is available, the end of the stream is detected,
* or an exception is thrown.
*
* <p> A subclass must provide an implementation of this method.
*
* @return the next byte of data, or <code>-1</code> if the end of the
* stream is reached.
* @exception IOException if an I/O error occurs.
*/
public abstract int read() throws IOException;
}
```
注意其中的一句话 **“This method blocks until input data is available, the end of the stream is detected, or an exception is thrown”**，当对 Socket 的输入流进行读取操作的时候，它会一直阻塞下去，直到发生如下三种事件。
- 有数据可读；
- 可用数据已经读取完毕；
- 发生空指针或者 IO异常。
这意味着当对方发送请求或者应答消息比较缓慢，或者网络传输较慢时，读取输入流一方的通信线程将被长时间阻塞，如果对方要 60s 才能够将数据发送完成，读取一方的 IO线程 也将会被同步阻塞 60s，在此期间，其他接入消息只能在消息队列中排队。
下面我们接着对输出流进行分析，还是看 JDK IO类库 输出流的 API文档，然后结合文档说明进行故障分析。
```java
public abstract class OutputStream implements Closeable, Flushable {
/**
* Writes an array of bytes. This method will block until the bytes are *actually written.
*
* @param b the data.
* @exception IOException if an I/O error occurs.
* @see java.io.OutputStream#write(byte[], int, int)
*/
public void write(byte b[]) throws IOException {
write(b, 0, b.length);
}
}
```
当调用 OutputStream 的 write()方法 写输出流的时候，它将会被阻塞，直到所有要发送的字节全部写入完毕，或者发生异常。学习过 TCP/IP 相关知识的人都知道，当消息的接收方处理缓慢的时候，将不能及时地从 TCP缓冲区 读取数据，这将会导致发送方的 TCP window size 不断减小，直到为 0，双方处于 Keep-Alive状态，消息发送方将不能再向 TCP缓冲区 写入消息，这时如果采用的是 同步阻塞IO，write操作 将会被无限期阻塞，直到 TCP window size 大于0 或者发生 IO异常。
通过对输入和输出流的 API文档 进行分析，我们了解到读和写操作都是同步阻塞的，阻塞的时间取决于对方 IO线程 的处理速度和 网络IO 的传输速度。本质上来讲，我们无法保证生产环境的网络状况和对方的应用程序能足够快，如果我们的应用程序依赖对方的处理速度，它的可靠性就非常差。也许在实验室进行的性能测试结果令人满意，但是一旦上线运行，面对恶劣的网络环境和良莠不齐的第三方系统，问题就会如火山一样喷发。
伪异步IO 实际上仅仅是对之前 IO线程模型 的一个简单优化，它无法从根本上解决 同步IO 导致的通信线程阻塞问题。下面我们就简单分析下通信对方返回应答时间过长会引起的级联故障。
1. 服务端处理缓慢，返回应答消息耗费60s， 平时只需要10ms。
2. 采用伪异步I/O的线程正在读取故障服务节点的响应，由于读取输入流是阻塞的，它将会被同步阻塞60s。
3. 假如所有的可用线程都被故障服务器阻塞，那后续所有的1/O消息都将在队列中排队。
4. 由于线程池采用阻塞队列实现，当队列积满之后，后续入队列的操作将被阻塞。
5. 由于前端只有一个Accptor线程接收客户端接入，它被阻塞在线程池的同步阻塞队列之后，新的客户端请求消息将被拒绝，客户端会发生大量的连接超时。
6. 由于几乎所有的连接都超时，调用者会认为系统已经崩溃，无法接收新的请求消息。
## NIO编程
与 Socket类 和 ServerSocket类 相对应，NIO 也提供了 SocketChannel 和 ServerSocketChannel 两种不同的套接字通道实现。这两种新增的通道都支持阻塞和非阻塞两种模式。阻塞模式使用非常简单，但是性能和可靠性都不好，非阻塞模式则正好相反。开发人员可以根据自
己的需要来选择合适的模式。一般来说，低负载、低并发的应用程序可以选择 同步阻塞IO，以降低编程复杂度；对于高负载、高并发的网络应用，需要使用 NIO 的非阻塞模式进行开发。
### NIO类库简介
NIO类库 是在 JDK 1.4 中引入的。NIO 弥补了原来 同步阻塞IO 的不足，它在 标准Java代码 中提供了高速的、面向块的IO。下面我们简单看一下 NIO类库 及其 相关概念。
**1、缓冲区Buffer**
Buffer对象 包含了一些要写入或者要读出的数据。在 NIO类库 中加入 Buffer对象，是其与 原IO类库 的一个重要区别。在面向流的 IO 中，可以将数据直接写入或者将数据直接读到 Stream对象 中。在NIO库中，所有数据都是用缓冲区处理的。在读取数据时，它是直接读到缓冲区中的；在写入数据时，写入到缓冲区中。任何时候访问 NIO 中的数据，都是通过缓冲区进行操作。
缓冲区实质上是一个数组。通常它是一个字节数组（ByteBuffer），也可以使用其他种类的数组。但是一个缓冲区不仅仅是一个数组，缓冲区提供了对数据的结构化访问以及维护读写位置（limit）等信息。最常用的缓冲区是 ByteBuffer，一个 ByteBuffer 提供了一组功能用于操作 byte数组。除了 ByteBuffer，还有其他的一些缓冲区，事实上，每一种 Java基本类型（除了 boolean）都对应有一种与之对应的缓冲区，如：CharBuffer、IntBuffer、DoubleBuffer 等等。Buffer组件中主要类的类图如下所示。
![avatar](/images/Netty/Buffer组件类图.png)
除了ByteBuffer，每一个 Buffer类 都有完全一样的操作，只是它们所处理的数据类型不一样。因为大多数 标准IO操作 都使用 ByteBuffer，所以它在具有一般缓冲区的操作之外还提供了一些特有的操作，以方便网络读写。
**2、通道Channel**
Channel 是一个通道，它就像自来水管一样，网络数据通过 Channel 读取和写入。通道与流的不同之处在于通道是双向的，可以用于读、写，或者二者同时进行；流是单向的，要么是 InputStream，要么是 OutputStream。因为 Channel 是全双工的，所以它可以比流更好地映射底层操作系统的 API。特别是在 UNIX网络编程模型 中，底层操作系统的通道都是全双工的，同时支持读写操作。Channel组件中 主要类的类图如下所示，从中我们可以看到最常用的 ServerSocketChannel 和 SocketChannel。
![avatar](/images/Netty/Channel组件类图.png)
**3、多路复用器Selector**
多路复用器Selector 是 Java NIO编程 的基础，熟练地掌握 Selector 对于 NIO编程 至关重要。多路复用器提供选择已经就绪的任务的能力。简单来讲，Selector会不断地轮询 “注册在其上的Channel”，如果某个 Channel 上面发生读或者写事件，这个 Channel 就处于就绪状态，会被 Selector 轮询出来，然后通过 SelectionKey 可以获取 “就绪 Channel 的集合”，进行后续的 IO操作。
一个 多路复用器Selector 可以同时轮询多个 Channel，由于 JDK 使用了 epoll() 代替传统的 select 的实现，所以它并没有最大连接句柄的限制。这也就意味着，只需要一个线程负责 Selector 的轮询，就可以接入成千上万的客户端。下面，我们通过 NIO编程的序列图 和 源码分析来熟悉相关的概念。
### NIO服务端序列图
![avatar](/images/Netty/NIO服务端序列图.png)
下面，我们看一下 NIO服务端 的主要创建过程。
1、打开 ServerSocketChannel，用于监听客户端的连接，它是所有客户端连接的
父管道，示例代码如下。
```java
ServerSocketChannel acceptorSvr = ServerSocketChannel.open();
```
2、绑定监听端口，设置连接为非阻塞模式，示例代码如下。
```java
acceptorSvr.socket().bind(new InetSocketAddress(InetAddress.getByName("IP"), port));
acceptorSvr.configureBlocking(false);
```
3、创建 Reactor线程，创建多路复用器并启动线程，示例代码如下。
```java
Selector selector = Selector.open();
New Thread (new ReactorTask()).start();
```
4、将 ServerSocketChannel 注册到 Reactor线程 的 多路复用器Selector 上，监听 ACCEPT事件，示例代码如下。
```java
SelectionKey key = acceptorSvr.register(selector, SelectionKey.OP_ ACCEPT, ioHandler);
```
5、多路复用器在线程 run()方法 的无限循环体内轮询 准备就绪的Key，示例代码如下。
```java
int num = selector.select();
Set selectedKeys = selector.selectedKeys();
Iterator it = selectedKeys.iterator();
while (it.hasNext()) {
SelectionKey key = (SelectionKey) it.next();
// .... deal with IO event ...
```
6、多路复用器Selector 监听到有新的客户端接入，处理新的接入请求，完成 TCP三次握手，建立物理链路，示例代码如下。
```java
SocketChannel channel = svrChannel.accept();
```
7、设置客户端链路为非阻塞模式，示例代码如下。
```java
channel.configureBlocking(false);
channel.socket().setReuseAddress(true);
......
```
8、将新接入的客户端连接注册到 Reactor线程 的多路复用器上，监听读操作，读取客户端发送的网络消息，示例代码如下。
```java
SelectionKey key = socketChannel.register(selector, SelectionKey.OP_READ, ioHandler);
```
9、异步读取客户端请求消息到缓冲区，示例代码如下。
```java
int readNumber = channel.read(receivedBuffer);
```
10、对 ByteBuffer 进行编解码，如果有半包消息指针 reset，继续读取后续的报文，将解码成功的消息封装成 Task，投递到业务线程池中,进行业务逻辑编排，示例代码如下。
```java
List messageList = null;
while (byteBuffer.hasRemain()) {
byteBuffer.mark();
Object message = decode(byteBuffer) ;
if (message == null) {
byteBuffer.reset();
break;
}
messageList.add(message);
}
if (!byteBuffer.hasRemain()) {
byteBuffer.clear();
} else {
byteBuffer.compact();
}
if (messageList != null && !messageList.isEmpty()) {
for (Object message : messageList) {
handlerTask(message);
}
}
```
11、将 POJO对象 encode 成 ByteBuffer，调用 SocketChannel 的 异步write接口，将消息异步发送给客户端，示例代码如下。
```java
socketChannel.write(byteBuffer);
```
注意：如果发送区 TCP缓冲区满，会导致写半包，此时，需要注册监听写操作位，循环写，直到整包消息写入 TCP缓冲区。对于 “半包问题” 此处暂不赘述，后续会单独写一篇详细分析 Netty 的处理策略。
### NIO 客户端序列图
![avatar](/images/Netty/NIO客户端序列图.png)
1、打开 SocketChannel，绑定客户端本地地址 (可选，默认系统会随机分配一个可用的本地地址)，示例代码如下。
```java
SocketChannel clientChannel = SocketChannel.open();
```
2、设置 SocketChannel 为非阻塞模式，同时设置客户端连接的 TCP参数，示例代码如下。
```java
clientChannel.configureBlocking(false);
socket.setReuseAddress(true);
socket.setReceiveBufferSize(BUFFER_SIZE);
socket.setSendBufferSize(BUFFER_SIZE);
```
3、异步连接服务端，示例代码如下。
```java
boolean connected = clientChannel.connect( new InetSocketAddress("ip", port) );
```
4、判断是否连接成功，如果连接成功，则直接注册读状态位到多路复用器中，如果当前没有连接成功，则重连 (异步连接，返回false，说明客户端已经发送 syne包，服务端没有返回 ack包，物理链路还没有建立)，示例代码如下。
```java
if (connected) {
clientChannel.register(selector, SelectionKey.OP_READ, ioHandler);
} else {
clientChannel.register(selector, SelectionKey.OP_CONNECT, ioHandler);
}
```
5、向 Reactor线程 的多路复用器注册 OP_CONNECT 状态位，监听服务端的 TCP ACK应答，示例代码如下。
```java
clientChannel.register(selector, SelectionKey.OP_CONNECT, ioHandler);
```
6、创建 Reactor线程，创建多路复用器并启动线程，代码如下。
```java
Selector selector = Selector.open();
New Thread( new ReactorTask() ).start();
```
7、多路复用器在线程 run()方法 的无限循环体内轮询 准备就绪的Key，代码如下。
```java
int num = selector.select();
Set selectedKeys = selector.selectedKeys();
Iterator it = selectedKeys.iterator();
while (it.hasNext()) {
SelectionKey key = (SelectionKey) it.next();
// ... deal with IO event ...
}
```
8、接收 connect事件，并进行处理，示例代码如下。
```java
if (key.isConnectable()) {
// handlerConnect();
}
```
9、判断连接结果，如果连接成功，注册读事件到多路复用器，示例代码如下。
```java
if(channel.finishConnect()) {
registerRead();
}
```
10、注册读事件到多路复用器，示例代码如下。
```java
clientChannel.register(selector, SelectionKey.OP_READ, ioHandler);
```
11、异步读客户端请求消息到缓冲区，示例代码如下。
```java
int readNumber = channel.read(receivedBuffer);
```
12、对 ByteBuffer 进行编解码，如果有半包消息接收缓冲区 Reset，继续读取后续的报文，将解码成功的消息封装成 Task，投递到业务线程池中，进行业务逻辑编排。示例代码如下。
```java
List messageList = null;
while (byteBuffer.hasRemain()) {
byteBuffer.mark();
object message = decode(byteBuffer);
if (message == nu11) {
byteBuffer.reset();
break;
}
messageList.add(message);
}
if (!byteBuffer.hasRemain()) {
byteBuffer.clear();
} else {
byteBuffer.compact();
}
if ( messageList != null && !messageList.isEmpty() )
for (Object message : messageList) {
handlerTask(message);
}
}
```
13、将 POJO对象 encode成 ByteBuffer，调用 SocketChannel 的 异步write接口，将消息异步发送给客户端。示例代码如下。
```java
socketChannel.write(buffer);
```
## AIO编程
NIO2.0 引入了新的异步通道的概念，并提供了异步文件通道和异步套接字通道的实现。异步通道提供以下两种方式获取获取操作结果。
- 通过 java.util.concurrent.Future类 来表示异步操作的结果;
- 在执行异步操作的时候传入一个 java.nio.channels.CompletionHandler接口 的实现类作为操作完成的回调。
NIO2.0 的异步套接字通道是真正的 异步非阻塞IO，对应于 UNIX网络编程 中的 事件驱动IO (AIO)。它不需要通过多路复用器 (Selector) 对注册的通道进行轮询操作即可实现异步读写，从而简化了 NIO 的编程模型。
由于在实际开发中使用较少，所以这里不对 AIO 进行详细分析。
## 四种IO编程模型的对比
对比之前，这里再澄清一下 “伪异步IO” 的概念。伪异步IO 的概念完全来源于实践，并没有官方说法。在 JDK NIO编程 没有流行之前，为了解决 Tomcat 通信线程同步IO 导致业务线程被挂住的问题，大家想到了一个办法，在通信线程和业务线程之间做个缓冲区，这个缓冲区用于隔离 IO线程 和业务线程间的直接访问，这样业务线程就不会被 IO线程 阻塞。而对于后端的业务侧来说，将消息或者 Task 放到线程池后就返回了，它不再直接访问 IO线程 或者进行 IO读写，这样也就不会被同步阻塞。
![avatar](/images/Netty/四种IO模型的功能特性对比图.png)
## 选择 Netty 开发项目的理由
从可维护性角度看，由于 NIO 采用了异步非阻塞编程模型，而且是一个 IO线程 处理多条链路，它的调试和跟踪非常麻烦，特别是生产环境中的问题，我们无法进行有效的调试和跟踪，往往只能靠一些日志来辅助分析，定位难度很大。
### 为什么不选择 Java原生NIO 进行开发
1. NIO 的类库和 API 使用起来非常繁杂，需要熟练掌握 Selector、ServerSocketChannel、SocketChannel、ByteBuffer 等。
2. 需要具备其他的额外技能做铺垫，例如，熟悉 Java多线程编程。这是因为 NIO编程 涉及到 Reactor模式，你必须对 多线程 和 网路编程 非常熟悉，才能编写出高质量的 NIO程序。
3. 可靠性能力补齐，工作量和难度都非常大。例如客户端面临：断连重连、网络闪断、半包读写、失败缓存、网络拥塞和异常码流的处理，等问题。
4. JDK NIO 的 BUG，例如臭名昭著的 epoll bug，它会导致 Selector空轮询，最终导致 CPU 100%。虽然官方声称修复了该问题，但是直到 JDK 1.7版本 该问题仍旧未得到彻底的解决。
### 为什么选择 Netty 进行开发
Netty 是业界最流行的 NIO框架 之一，它的健壮性、功能、性能、可定制性和可扩展性在同类框架中都是首屈一指的，已经得到成百上千的商用项目验证，例如 Hadoop 的 RPC框架 Avro ，阿里的 RPC框架 Dubbo 就使用了 Netty 作为底层通信框架。通过对Netty的分析，我们将它的优点总结如下。
- API使用简单，开发门槛低；
- 功能强大，预置了多种编解码功能，支持多种主流协议；
- 定制能力强，可以通过 ChannelHandler 对通信框架进行灵活地扩展；
- 性能高，通过与其他业界主流的 NIO框架 对比，Netty 的综合性能最优；
- 成熟、稳定，Netty 修复了已经发现的所有 JDK NIO BUG，业务开发人员不需要再为 NIO 的 BUG 而烦恼；
- 社区活跃，版本迭代周期短，发现的 BUG 可以被及时修复，同时，更多的新功能会加入；
- 经历了大规模的商业应用考验，质量得到验证。Netty 在互联网、大数据、网络游戏、企业应用、电信软件等众多行业已经得到了成功商用，证明它已经完全能够满足不同行业的商业应用了。
正是因为这些优点，Netty 逐渐成为了 Java NIO编程 的首选框架。

0
docs/Netty/IO/把被说烂的BIO、NIO、AIO再从头到尾扯一遍.md → docs/Netty/IOTechnologyBase/把被说烂的BIO、NIO、AIO再从头到尾扯一遍.md
Unescape View File

1
docs/Netty/Netty多协议开发/基于HTTP协议的Netty开发.md
Unescape View File

@ -0,0 +1 @@
努力编写中......

1
docs/Netty/Netty多协议开发/基于WebSocket协议的Netty开发.md
Unescape View File

@ -0,0 +1 @@
努力编写中......

1
docs/Netty/Netty多协议开发/基于自定义协议的Netty开发.md
Unescape View File

@ -0,0 +1 @@
努力编写中......

0
docs/Netty/IO/NIO原理详解.md → docs/Netty/Netty编解码/Java序列化缺点与主流编解码框架.md
Unescape View File

47
docs/Netty/TCP粘拆包/TCP粘拆包问题及Netty中的解决方案.md
Unescape View File

@ -0,0 +1,47 @@
## TCP粘包/拆包
熟悉 TCP编程 的都知道，无论是服务端还是客户端，当我们读取或者发送消息的时候，都需要考虑 TCP底层 的 粘包/拆包机制。TCP粘包/拆包问题，在功能测试时往往不会怎么出现，而一旦并发压力上来，或者发送大报文之后，就很容易出现 粘包 / 拆包问题。如果代码没有考虑，往往就会出现解码错位或者错误，导致程序不能正常工作。本篇博文，我们先简单了解 TCP粘包/拆包 的基础知识，然后来看看 Netty 是如何解决这个问题的。
### TCP粘包/拆包问题说明
TCP 是个 “流” 协议，所谓流，就是没有界限的一串数据。TCP底层 并不了解上层（如 HTTP协议）业务数据的具体含义，它会根据 TCP缓冲区 的实际情况进行包的划分，所以在业务上认为，一个完整的包可能会被 TCP 拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这就是所谓的 TCP粘包和拆包问题。我们可以通过下面的示例图，对 TCP粘包和拆包问题 进行说明。
![avatar](/images/Netty/TCP粘包拆包问题.png)
假设客户端依次发送了两个数据包 DI 和 D2 给服务端，由于服务端一次读取到的字节数是不确定的，故可能存在以下4种情况。
1. 服务端分两次读取到了两个独立的数据包，分别是 D1 和 D2，没有粘包和拆包；
2. 服务端一次接收到了两个数据包，DI 和 D2 粘合在一起，被称为 TCP粘包；
3. 服务端分两次读取到了两个数据包，第一次读取到了完整的 DI包 和 D2包的部分内容，第二次读取到了 D2包 的剩余内容，这被称为 TCP拆包；
4. 服务端分两次读取到了两个数据包，第一次读取到了 D1包的部分内容，第二次读取到了 D1包的剩余内容 和 D2包的整包。
如果此时服务端 TCP 接收滑窗非常小，而 数据包DI 和 D2 比较大，很有可能会发生第5种可能，即服务端分多次才能将 D1 和 D2包 接收完全，期间发生多次拆包。
### TCP粘包/拆包发生的原因
问题产生的原因有三个，分别如下。
1. **应用程序 write写入的字节大小 超出了 套接口发送缓冲区大小；**
2. 进行 MSS 大小的 TCP分段；
3. 以太网帧的 payload 大于 MTU 进行 IP分片。
### 粘拆包问题的解决策略
由于底层的 TCP 无法理解上层的业务数据，所以在底层是无法保证数据包不被拆分和重组的，这个问题只能通过上层的应用协议栈设计来解决，根据业界的主流协议的解决方案，可以归纳如下。
1. 固定消息长度，例如，每个报文的大小为 固定长度200字节，如果不够，空位补空格；
2. 在包尾使用 “回车换行符” 等特殊字符，作为消息结束的标志，例如FTP协议，这种方式在文本协议中应用比较广泛；
3. 将消息分为消息头和消息体，在消息头中定义一个 长度字段Len 来标识消息的总长度;
4. 更复杂的应用层协议。
介绍完了 TCP粘包/拆包 的基础，下面我们来看看 Netty 是如何使用一系列 “半包解码器” 来解决 TCP粘包/拆包问题的。
## 利用 Netty的解码器 解决 TCP粘拆包问题
根据上面的 粘拆包问题解决策略，Netty 提供了相应的解码器实现。有了这些解码器，用户不需要自己对读取的报文进行人工解码，也不需要考虑TCP的粘包和拆包。
### LineBasedFrameDecoder 和 StringDecoder 的原理分析
为了解决 TCP粘包 / 拆包 导致的 半包读写问题，Netty 默认提供了多种编解码器用于处理半包，只要能熟练掌握这些类库的使用，TCP粘拆包问题 从此会变得非常容易，你甚至不需要关心它们，这也是其他 NIO框架 和 JDK原生的 NIO API 所无法匹敌的。对于使用者来说，只要将支持半包解码的 Handler 添加到 ChannelPipeline对象 中即可，不需要写额外的代码，使用起来非常简单。
```java
// 示例代码，其中 socketChannel 是一个 SocketChannel对象
socketChannel.pipeline().addLast( new LineBasedFrameDecoder(1024) );
socketChannel.pipeline().addLast( new StringDecoder() );
```
LineBasedFrameDecoder 的工作原理是它依次遍历 ByteBuf 中的可读字节，判断看是否有 “\n” 或者 “\r\n”，如果有，就以此位置为结束位置，从可读索引到结束位置区间的字节就组成了一行。它是以换行符为结束标志的解码器，支持携带结束符或者不携带结束符两种解码方式，同时支持配置单行的最大长度。如果连续读取到最大长度后仍然没有发现换行符，就会抛出异常，同时忽略掉之前读到的异常码流。
StringDecoder 的功能非常简单，就是将接收到的对象转换成字符串，然后继续调用后面的 Handler。LineBasedFrameDecoder + StringDecoder组合 就是按行切换的文本解码器，它被设计用来支持 TCP 的粘包和拆包。
### 其它解码器
除了 LineBasedFrameDecoder 以外，还有两个常用的解码器 DelimiterBasedFrameDecoder 和 FixedLengthFrameDecoder，前者能自动对 “以分隔符做结束标志的消息” 进行解码，后者可以自动完成对定长消息的解码。使用方法也和前面的示例代码相同，结合 字符串解码器StringDecoder，轻松完成对很多消息的自动解码。

247
docs/Netty/基于Netty开发服务端及客户端/基于Netty的客户端开发.md
Unescape View File

@ -0,0 +1,247 @@
相对于服务端，Netty客户端 的创建更加复杂，除了要考虑线程模型、异步连接、客户端连接超时等因素外，还需要对连接过程中的各种异常进行考虑。本章将对 Netty客户端 创建的关键流程和源码进行分析，以期读者能够了解客户端创建的细节。
## 基于 Netty 创建客户端的流程分析
Netty 为了向使用者屏蔽 NIO通信 的底层细节，在和用户交互的边界做了封装，目的就是为了减少用户开发工作量，降低开发难度。Bootstrap 是 Socket 客户端创建工具类，用户通过 Bootstrap 可以方便地创建 Netty 的客户端并发起 异步TCP连接操作。
### 基于 Netty 创建客户端 时序图
![avatar](/images/Netty/基于Netty创建客户端时序图.png)
### Netty 创建客户端 流程分析
1. 用户线程创建 Bootstrap实例，通过 API 设置客户端相关的参数，异步发起客户端连接；
2. 创建处理客户端连接、I/O 读写的 Reactor线程组 NioEventLoopGroup。可以通过构造函数指定 IO线程 的个数，默认为 CPU 内核数的 2 倍；
3. 通过 Bootstrap 的 ChannelFactory 和用户指定的 Channel类型 创建用于客户端连接的 NioSocketChannel，它的功能类似于 JDK NIO类库 提供的 SocketChannel；
4. 创建默认的 Channel、Handler、Pipeline，用于调度和执行网络事件；
5. 异步发起 TCP连接，判断连接是否成功。如果成功，则直接将 NioSocketChannel 注册到多路复用器上，监听读操作位，用于数据报读取和消息发送；如果没有立即连接成功，则注册连接监听位到多路复用器，等待连接结果；
6. 注册对应的网络监听状态位到多路复用器；
7. 由多路复用器在 IO 现场中轮询各 Channel，处理连接结果；
8. 如果连接成功，设置 Future结果，发送连接成功事件，触发 ChanneIPipeline 执行；
9. 由 ChannelPipeline 调度执行系统和用户的 ChannelHandler，执行业务逻辑。
## Netty 客户端创建源码分析
Netty客户端 的创建流程比较繁琐，下面我们针对关键步骤和代码进行分析，通过梳理关键流程来掌握客户端创建的原理。
### 客户端连接辅助类 BootStrap
Bootstrap 是 Netty 提供的客户端连接工具类，主要用于简化客户端的创建，下面我们对它的 主要API 进行讲解。
设置 lO线程组：NIO的特点就是，一个多路复用器可以同时处理上干条链路，这就意味着，NIO模式中 一个线程可以处理多个 TCP连接。考虑到 lO线程 的处理性能，大多数 NIO框架 都采用线程池的方式处理 IO读写，Netty 也不例外。客户端相对于服务端，只需要一个处理 IO读写 的线程组即可，因为 Bootstrap 提供了 设置IO线程组 的接口，代码如下。
```java
public abstract class AbstractBootstrap<B extends AbstractBootstrap<B, C>, C extends Channel> implements Cloneable {
volatile EventLoopGroup group;
public B group(EventLoopGroup group) {
if (group == null) {
throw new NullPointerException("group");
} else if (this.group != null) {
throw new IllegalStateException("group set already");
} else {
this.group = group;
return this;
}
}
}
```
由于 Netty 的 NIO线程组 默认采用 EventLoopGroup接口，因此线程组参数使用 EventLoopGroup。
TCP参数设置接口：无论是 NIO，还是 BIO，创建客户端套接字的时候通常都会设置连接参数，例如接收和发送缓冲区大小、连接超时时间等。Bootstrap 也提供了客户端 TCP参数设置接口，代码如下。
```java
public <T> B option(ChannelOption<T> option, T value) {
if (option == null) {
throw new NullPointerException("option");
} else {
if (value == null) {
synchronized(this.options) {
this.options.remove(option);
}
} else {
synchronized(this.options) {
this.options.put(option, value);
}
}
return this;
}
}
```
Netty 提供的 主要TCP参数 如下。
1、SO_TIMEOUT：控制读取操作将阻塞多少毫秒。如果返回值为0，计时器就被禁止了，该线程将无限期阻塞；
2、SO_SNDBUF：套接字使用的发送缓冲区大小；
3、SO_RCVBUF：套接字使用的接收缓冲区大小；
4、SO_REUSEADDR：用于决定 如果网络上仍然有数据向旧的 ServerSocket 传输数据，是否允许新的 ServerSocket 绑定到与旧的 ServerSocket 同样的端口上。SO_REUSEADDR选项 的默认值与操作系统有关，在某些操作系统中，允许重用端口，而在某些操作系统中不允许重用端口；
5、CONNECT_TIMEOUT_MILLIS：客户端连接超时时间，由于 NIO原生的客户端 并不提供设置连接超时的接口，因此，Netty 采用的是自定义连接超时定时器负责检测和超时控制；
Channel接口：用于指定客户端使用的 Channel接口，对于 TCP客户端连接，默认使用 NioSocketChannel，代码如下。
```java
public B channel(Class<? extends C> channelClass) {
if (channelClass == null) {
throw new NullPointerException("channelClass");
} else {
return this.channelFactory((io.netty.channel.ChannelFactory)(new ReflectiveChannelFactory(channelClass)));
}
}
```
BootstrapChannelFactory 利用 参数channelClass，通过反射机制创建 NioSocketChannel对象。
设置 Handler接口：Bootstrap 为了简化 Handler 的编排，提供了 Channellnitializer，它继承了 ChannelHandlerAdapter，当 TCP链路 注册成功之后，调用 initChannel 接口，用于设置用户 ChanneIHandler。它的代码如下。
```java
public abstract class ChannelInitializer<C extends Channel> extends ChannelInboundHandlerAdapter {
public final void channelRegistered(ChannelHandlerContext ctx) throws Exception {
if (this.initChannel(ctx)) {
ctx.pipeline().fireChannelRegistered();
} else {
ctx.fireChannelRegistered();
}
}
}
```
最后一个比较重要的接口就是发起客户端连接，代码如下。
```java
ChannelFuture f = b.connect(host, port).sync();
```
### 客户端连接操作
首先要创建和初始化 NioSocketChannel，代码如下。
```java
public class Bootstrap extends AbstractBootstrap<Bootstrap, Channel> {
public ChannelFuture connect(SocketAddress remoteAddress, SocketAddress localAddress) {
if (remoteAddress == null) {
throw new NullPointerException("remoteAddress");
} else {
this.validate();
return this.doResolveAndConnect(remoteAddress, localAddress);
}
}
private ChannelFuture doResolveAndConnect(final SocketAddress remoteAddress, final SocketAddress localAddress) {
// 首先要创建和初始化 NioSocketChannel
ChannelFuture regFuture = this.initAndRegister();
final Channel channel = regFuture.channel();
if (regFuture.isDone()) {
// 初始化 Channel 之后，将其注册到 Selector 上
return !regFuture.isSuccess() ? regFuture : this.doResolveAndConnect0(channel, remoteAddress, localAddress, channel.newPromise());
} else {
final PendingRegistrationPromise promise = new PendingRegistrationPromise(channel);
regFuture.addListener(new ChannelFutureListener() {
public void operationComplete(ChannelFuture future) throws Exception {
Throwable cause = future.cause();
if (cause != null) {
promise.setFailure(cause);
} else {
promise.registered();
Bootstrap.this.doResolveAndConnect0(channel, remoteAddress, localAddress, promise);
}
}
});
return promise;
}
}
private ChannelFuture doResolveAndConnect0(final Channel channel, SocketAddress remoteAddress, final SocketAddress localAddress, final ChannelPromise promise) {
try {
EventLoop eventLoop = channel.eventLoop();
AddressResolver<SocketAddress> resolver = this.resolver.getResolver(eventLoop);
if (!resolver.isSupported(remoteAddress) || resolver.isResolved(remoteAddress)) {
doConnect(remoteAddress, localAddress, promise);
return promise;
}
Future<SocketAddress> resolveFuture = resolver.resolve(remoteAddress);
if (resolveFuture.isDone()) {
Throwable resolveFailureCause = resolveFuture.cause();
if (resolveFailureCause != null) {
channel.close();
promise.setFailure(resolveFailureCause);
} else {
doConnect((SocketAddress)resolveFuture.getNow(), localAddress, promise);
}
return promise;
}
resolveFuture.addListener(new FutureListener<SocketAddress>() {
public void operationComplete(Future<SocketAddress> future) throws Exception {
if (future.cause() != null) {
channel.close();
promise.setFailure(future.cause());
} else {
Bootstrap.doConnect((SocketAddress)future.getNow(), localAddress, promise);
}
}
});
} catch (Throwable var9) {
promise.tryFailure(var9);
}
return promise;
}
private static void doConnect(final SocketAddress remoteAddress, final SocketAddress localAddress, final ChannelPromise connectPromise) {
final Channel channel = connectPromise.channel();
channel.eventLoop().execute(new Runnable() {
public void run() {
if (localAddress == null) {
channel.connect(remoteAddress, connectPromise);
} else {
channel.connect(remoteAddress, localAddress, connectPromise);
}
connectPromise.addListener(ChannelFutureListener.CLOSE_ON_FAILURE);
}
});
}
}
```
需要注意的是，SocketChannel 执行 connect() 操作后有以下三种结果。
1. 连接成功，返回True；
2. 暂时没有连接上，服务端没有返回 ACK应答，连接结果不确定，返回False；
3. 连接失败，直接抛出 IO异常。
如果是第二种结果，需要将 NioSocketChannel 中的 selectionKey 设置为 OP_CONNECT，监听连接结果。异步连接返回之后，需要判断连接结果，如果连接成功，则触发 ChannelActive 事件。ChannelActive事件 最终会将 NioSocketChannel 中的 selectionKey 设置为 SelectionKey.OP_READ，用于监听网络读操作。如果没有立即连接上服务端，则注册 SelectionKey.OP_CONNECT 到多路复用器。如果连接过程发生异常，则关闭链路，进入连接失败处理流程。
### 异步连接结果通知
NioEventLoop 的 Selector 轮询 客户端连接Channel，当服务端返回握手应答之后，对连接结果进行判断，代码如下。
```java
if ((readyOps & 8) != 0) {
int ops = k.interestOps();
ops &= -9;
k.interestOps(ops);
unsafe.finishConnect();
}
```
下面对 finishConnect()方法 进行分析，代码如下。
```java
try {
boolean wasActive = AbstractNioChannel.this.isActive();
AbstractNioChannel.this.doFinishConnect();
this.fulfillConnectPromise(AbstractNioChannel.this.connectPromise, wasActive);
} catch (Throwable var5) {
......
}
```
doFinishConnect()方法 用于判断 JDK 的 SocketChannel 的连接结果，如果未出错 表示连接成功，其他值或者发生异常表示连接失败。
```java
protected void doFinishConnect() throws Exception {
if (!this.javaChannel().finishConnect()) {
throw new Error();
}
}
```
连接成功之后，调用 fufillConectPromise()方法，触发链路激活事件，该事件由 ChannelPipeline 进行传播。
### 客户端连接超时机制
对于SocketChannel接口，JDK并没有提供连接超时机制，需要NIO框架或者用户自己扩展实现。Netty利用定时器提供了客户端连接超时控制功能，下面我们对该功能进行详细讲解。
首先,用户在创建Netty 客户端的时候，可以通过ChannelOption.CONNECT_TIMEOUT_MILLIS配置项设置连接超时时间，代码如下。
```java
Bootstrap b = new Bootstrap();
b.group(workerGroup);
b.channel(NioSocketChannel.class);
b.option(ChannelOption.SO_KEEPALIVE, true);
b.option(ChannelOption.CONNECT_TIMEOUT_MILLIS, 3000);
```

606
docs/Netty/基于Netty开发服务端及客户端/基于Netty的服务端开发.md
Unescape View File

@ -0,0 +1,606 @@
## Netty 服务端创建源码分析
当我们直接使用 JDK 的 NIO类库 开发基于 NIO 的异步服务端时，需要用到 多路复用器Selector、ServerSocketChannel、SocketChannel、ByteBuffer、SelectionKey 等，相比于传统的 BIO开发，NIO 的开发要复杂很多，开发出稳定、高性能的异步通信框架，一直是个难题。Netty 为了向使用者屏蔽 NIO通信 的底层细节，在和用户交互的边界做了封装，目的就是为了减少用户开发工作量，降低开发难度。ServerBootstrap 是 Socket服务端 的启动辅助类，用户通过 ServerBootstrap 可以方便地创建 Netty 的服务端。
### Netty 服务端创建时序图
![avatar](/images/Netty/Netty服务端创建时序图.png)
下面我们对 Netty服务端创建 的关键步骤和原理进行详细解析。
1、**创建 ServerBootstrap实例**。ServerBootstrap 是 Netty服务端 的 启动辅助类，它提供了一系列的方法用于设置服务端启动相关的参数。底层对各种 原生NIO 的 API 进行了封装，减少了用户与 底层API 的接触，降低了开发难度。ServerBootstrap 中只有一个 public 的无参的构造函数可以给用户直接使用，ServerBootstrap 只开放一个无参的构造函数 的根本原因是 它的参数太多了，而且未来也可能会发生变化，为了解决这个问题，就需要引入 Builder建造者模式。
2、**设置并绑定 Reactor线程池**。Netty 的 Reactor线程池 是 EventLoopGroup，它实际上是一个 EventLoop数组。EventLoop 的职责是处理所有注册到本线程多路复用器 Selector 上的 Channel，Selector 的轮询操作由绑定的 EventLoop线程 的 run()方法 驱动，在一个循环体内循环执行。值得说明的是，EventLoop 的职责不仅仅是处理 网络IO事件，用户自定义的Task 和 定时任务Task 也统一由 EventLoop 负责处理，这样线程模型就实现了统一。从调度层面看，也不存在从 EventLoop线程 中再启动其他类型的线程用于异步执行另外的任务，这样就避免了多线程并发操作和锁竞争，提升了 IO线程 的处理和调度性能。
3、**设置并绑定 服务端Channel**。作为 NIO服务端，需要创建 ServerSocketChannel，Netty 对 原生NIO类库 进行了封装，对应的实现是NioServerSocketChannel。对于用户而言，不需要关心 服务端Channel 的底层实现细节和工作原理，只需要指定具体使用哪种服务端 Channel 即可。因此，Netty 中 ServerBootstrap的基类 提供了 channel()方法，用于指定 服务端Channel 的类型。Netty 通过工厂类，利用反射创建 NioServerSocketChannel对象。由于服务端监听端口往往只需要在系统启动时才会调用，因此反射对性能的影响并不大。相关代
码如下。
```java
public abstract class AbstractBootstrap<B extends AbstractBootstrap<B, C>, C extends Channel> implements Cloneable {
/**
* 通过 参数channelClass 创建一个 Channel实例，
*/
public B channel(Class<? extends C> channelClass) {
if (channelClass == null) {
throw new NullPointerException("channelClass");
}
return channelFactory(new ReflectiveChannelFactory<C>(channelClass));
}
}
```
4、**链路建立的时候创建并初始化 ChannelPipeline**。ChannelPipeline 并不是 NIO服务端 必需的，它本质就是一个负责处理网络事件的职责链，负责管理和执行 ChannelHandler。网络事件以事件流的形式在 ChannelPipeline 中流转，由 ChannelPipeline 根据 ChannelHandler的执行策略 调度 ChannelHandler的执行。典型的网络事件如下。
1. 链路注册；
2. 链路激活；
3. 链路断开；
4. 接收到请求消息；
5. 请求消息接收并处理完毕；
6. 发送应答消息；
7. 链路发生异常；
8. 发生用户自定义事件。
5、**初始化 ChannelPipeline 完成之后，添加并设置 ChannelHandler**。ChannelHandler 是 Netty 提供给用户定制和扩展的关键接口。利用 ChannelHandler 用户可以完成大多数的功能定制，例如消息编解码、心跳、安全认证、TSL/SSL 认证、流量控制和流量整形等。Netty 同时也提供了大量的 系统ChannelHandler 供用户使用，比较实用的 系统ChannelHandler 总结如下。
1. 系统编解码框架，ByteToMessageCodec；
2. 基于长度的半包解码器，LengthFieldBasedFrameDecoder；
3. 码流日志打印 Handler，LoggingHandler；
4. SSL 安全认证 Handler，SslHandler；
5. 链路空闲检测 Handler，IdleStateHandler；
6. 流量整形 Handler，ChannelTrafficShapingHandler；
7. Base64 编解码，Base64Decoder 和 Base64Encoder。
创建和添加 ChannelHandler 的代码示例如下。
```java
.childHandler( new ChannelInitializer<SocketChannel>() {
@Override
public void initChannel(SocketChannel ch) throws Exception {
ch.pipeline().addLast( new EchoServerHandler() );
}
});
```
6、**绑定并启动监听端口**。在绑定监听端口之前系统会做一系列的初始化和检测工作，完成之后，会启动监听端口，并将 ServerSocketChannel 注册到 Selector 上监听客户端连接。
7、**Selector 轮询**。由 Reactor线程 NioEventLoop 负责调度和执行 Selector 轮询操作，选择准备就绪的 Channel集合，相关代码如下。
```java
public final class NioEventLoop extends SingleThreadEventLoop {
private void select(boolean oldWakenUp) throws IOException {
Selector selector = this.selector;
......
int selectedKeys = selector.select(timeoutMillis);
selectCnt ++;
......
}
}
```
8、**当轮询到 准备就绪的Channel 之后，就由 Reactor线程 NioEventLoop 执行 ChannelPipeline 的相应方法，最终调度并执行 ChannelHandler**，接口如下图所示。
![avatar](/images/Netty/ChannelPipeline的调度相关方法.png)
9、**执行 Netty 中 系统的ChannelHandler 和 用户添加定制的ChannelHandler** 。ChannelPipeline 根据网络事件的类型，调度并执行 ChannelHandler，相关代码如下。
```java
public class DefaultChannelPipeline implements ChannelPipeline {
@Override
public final ChannelPipeline fireChannelRead(Object msg) {
AbstractChannelHandlerContext.invokeChannelRead(head, msg);
return this;
}
}
```
### 结合 Netty源码 对服务端的创建过程进行解析
首先通过构造函数创建 ServerBootstrap实例，随后，通常会创建两个 EventLoopGroup实例 (也可以只创建一个并共享)，代码如下。
```java
EventLoopGroup acceptorGroup = new NioEventLoopGroup();
EventLoopGroup iOGroup = new NioEventLoopGroup();
```
NioEventLoopGroup 实际就是一个 Reactor线程池，负责调度和执行客户端的接入、网络读写事件的处理、用户自定义任务和定时任务的执行。通过 ServerBootstrap 的 group()方法 将两个 EventLoopGroup实例 传入，代码如下。
```java
public class ServerBootstrap extends AbstractBootstrap<ServerBootstrap, ServerChannel> {
/**
* Set the {@link EventLoopGroup} for the parent (acceptor) and the child (client). These
* {@link EventLoopGroup}'s are used to handle all the events and IO for {@link ServerChannel} and
* {@link Channel}'s.
*/
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;
}
}
```
其中 parentGroup对象 被设置进了 ServerBootstrap 的父类 AbstractBootstrap 中，代码如下。
```java
public abstract class AbstractBootstrap<B extends AbstractBootstrap<B, C>, C extends Channel> implements Cloneable {
volatile EventLoopGroup group;
/**
* The {@link EventLoopGroup} which is used to handle all the events for the to-be-created
* {@link Channel}
*/
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();
}
}
```
该方法会被客户端和服务端重用，用于设置 工作IO线程，执行和调度网络事件的读写。线程组和线程类型设置完成后，需要设置 服务端Channel 用于端口监听和客户端链路接入。Netty 通过 Channel工厂类 来创建不同类型的 Channel，对于服务端，需要创建 NioServerSocketChannel。所以，通过指定 Channel类型 的方式创建 Channel工厂。ReflectiveChannelFactory 可以根据 Channel的类型 通过反射创建 Channel的实例，服务端需要创建的是 NioServerSocketChannel实例，代码如下。
```java
public class ReflectiveChannelFactory<T extends Channel> implements ChannelFactory<T> {
private final Constructor<? extends T> constructor;
public ReflectiveChannelFactory(Class<? extends T> clazz) {
ObjectUtil.checkNotNull(clazz, "clazz");
try {
this.constructor = clazz.getConstructor();
} catch (NoSuchMethodException e) {
throw new IllegalArgumentException("Class " + StringUtil.simpleClassName(clazz) +
" does not have a public non-arg constructor", e);
}
}
@Override
public T newChannel() {
try {
return constructor.newInstance();
} catch (Throwable t) {
throw new ChannelException("Unable to create Channel from class " + constructor.getDeclaringClass(), t);
}
}
}
```
指定 NioServerSocketChannel 后，需要设置 TCP 的一些参数，作为服务端，主要是设置 TCP 的 backlog参数。
backlog 指定了内核为此套接口排队的最大连接个数，对于给定的监听套接口，内核要维护两个队列：未链接队列 和 已连接队列，根据 TCP三次握手 的 三个子过程来分隔这两个队列。服务器处于 listen状态 时，收到客户端 syn过程(connect) 时在未完成队列中创建一个新的条目，然后用三次握手的第二个过程，即服务器的 syn响应客户端，此条目在第三个过程到达前 (客户端对服务器 syn 的 ack) 一直保留在未完成连接队列中，如果三次握手完成，该条目将从未完成连接队列搬到已完成连接队列尾部。当进程调用 accept 时，从已完成队列中的头部取出一个条目给进程，当已完成队列为空时进程将睡眠，直到有条目在已完成连接队列中才唤醒。backlog 被规定为两个队列总和的最大值，大多数实现默认值为 5，但在高并发 Web服务器 中此值显然不够。 需要设置此值更大一些的原因是，未完成连接队列的长度可能因为客户端 syn 的到达及等待三次握手的第三个过程延时 而增大。Netty 默认的 backlog 为 100，当然，用户可以修改默认值，这需要根据实际场景和网络状况进行灵活设置。
TCP参数 设置完成后，用户可以为启动辅助类和其父类分别指定 Handler。两者 Handler 的用途不同：子类中的 Handler 是 NioServerSocketChannel 对应的 ChannelPipeline 的 Handler；父类中的 Handler 是客户端新接入的连接 SocketChannel 对应的 ChannelPipeline 的 Handler。两者的区别可以通过下图来展示。
![avatar](/images/Netty/ServerBootstrap的Handler模型.png)
本质区别就是：ServerBootstrap 中的 Handler 是 NioServerSocketChannel 使用的，所有连接该监听端口的客户端都会执行它；父类AbstractBootstrap 中的 Handler 是个工厂类，它为每个新接入的客户端都创建一个新的 Handler。
服务端启动的最后一步，就是绑定本地端口，启动服务，下面我们来分析下这部分代码。
```java
public abstract class AbstractBootstrap<B extends AbstractBootstrap<B, C>, C extends Channel> implements Cloneable {
private ChannelFuture doBind(final SocketAddress localAddress) {
final ChannelFuture regFuture = initAndRegister();
final Channel channel = regFuture.channel();
if (regFuture.cause() != null) {
return regFuture;
}
if (regFuture.isDone()) {
// At this point we know that the registration was complete and successful.
ChannelPromise promise = channel.newPromise();
doBind0(regFuture, channel, localAddress, promise);
return promise;
} else {
// Registration future is almost always fulfilled already, but just in case it's not.
final PendingRegistrationPromise promise = new PendingRegistrationPromise(channel);
regFuture.addListener(new ChannelFutureListener() {
@Override
public void operationComplete(ChannelFuture future) throws Exception {
Throwable cause = future.cause();
if (cause != null) {
// Registration on the EventLoop failed so fail the ChannelPromise directly to not cause an
// IllegalStateException once we try to access the EventLoop of the Channel.
promise.setFailure(cause);
} else {
// Registration was successful, so set the correct executor to use.
// See https://github.com/netty/netty/issues/2586
promise.registered();
doBind0(regFuture, channel, localAddress, promise);
}
}
});
return promise;
}
}
}
```
先看下上述代码调用的 initAndRegister()方法。它首先实例化了一个 NioServerSocketChannel类型 的 Channel对象。相关代码如下。
```java
final ChannelFuture initAndRegister() {
Channel channel = null;
try {
channel = channelFactory.newChannel();
init(channel);
} catch (Throwable t) {
if (channel != null) {
// channel can be null if newChannel crashed (eg SocketException("too many open files"))
channel.unsafe().closeForcibly();
// as the Channel is not registered yet we need to force the usage of the GlobalEventExecutor
return new DefaultChannelPromise(channel, GlobalEventExecutor.INSTANCE).setFailure(t);
}
// as the Channel is not registered yet we need to force the usage of the GlobalEventExecutor
return new DefaultChannelPromise(new FailedChannel(), GlobalEventExecutor.INSTANCE).setFailure(t);
}
ChannelFuture regFuture = config().group().register(channel);
if (regFuture.cause() != null) {
if (channel.isRegistered()) {
channel.close();
} else {
channel.unsafe().closeForcibly();
}
}
return regFuture;
}
```
NioServerSocketChannel 创建成功后，对它进行初始化，初始化工作主要有以下三点。
```java
@Override
void init(Channel channel) throws Exception {
final Map<ChannelOption<?>, Object> options = options0();
synchronized (options) {
setChannelOptions(channel, options, logger);
}
// 1、设置 Socket参数 和 NioServerSocketChannel 的附加属性
final Map<AttributeKey<?>, Object> attrs = attrs0();
synchronized (attrs) {
for (Entry<AttributeKey<?>, Object> e: attrs.entrySet()) {
@SuppressWarnings("unchecked")
AttributeKey<Object> key = (AttributeKey<Object>) e.getKey();
channel.attr(key).set(e.getValue());
}
}
// 2、将 AbstractBootstrap 的 Handler 添加到 NioServerSocketChannel
// 的 ChannelPipeline 中
ChannelPipeline p = channel.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));
}
// 3、将用于服务端注册的 Handler ServerBootstrapAcceptor 添加到 ChannelPipeline 中
p.addLast(new ChannelInitializer<Channel>() {
@Override
public void initChannel(final Channel ch) throws Exception {
final ChannelPipeline pipeline = ch.pipeline();
ChannelHandler handler = config.handler();
if (handler != null) {
pipeline.addLast(handler);
}
ch.eventLoop().execute(new Runnable() {
@Override
public void run() {
pipeline.addLast(new ServerBootstrapAcceptor(
ch, currentChildGroup, currentChildHandler, currentChildOptions, currentChildAttrs));
}
});
}
});
}
```
到此，Netty 服务端监听的相关资源已经初始化完毕，就剩下最后一步，注册 NioServerSocketChannel 到 Reactor线程 的多路复用器上，然后轮询客户端连接事件。在分析注册代码之前，我们先通过下图，看看目前 NioServerSocketChannel 的 ChannelPipeline 的组成。
![avatar](/images/Netty/NioServerSocketChannel的ChannelPipeline.png)
最后，我们看下 NioServerSocketChannel 的注册。当 NioServerSocketChannel 初始化完成之后，需要将它注册到 Reactor线程 的多路复用器上监听新客户端的接入，代码如下。
```java
public abstract class AbstractChannel extends DefaultAttributeMap implements Channel {
protected abstract class AbstractUnsafe implements Unsafe {
/**
* 将完成初始化的 NioServerSocketChannel 注册到 Reactor线程
* 的多路复用器上，监听新客户端的接入
*/
@Override
public final void register(EventLoop eventLoop, final ChannelPromise promise) {
......
// 首先判断是否是 NioEventLoop 自身发起的操作。如果是，则不存在并发操作，直接
// 执行 Channel注册；如果由其他线程发起，则封装成一个 Task 放入消息队列中异步执行。
// 此处，由于是由 ServerBootstrap 所在线程执行的注册操作，所以会将其封装成 Task 投递
// 到 NioEventLoop 中执行
if (eventLoop.inEventLoop()) {
register0(promise);
} else {
try {
eventLoop.execute(new Runnable() {
@Override
public void run() {
register0(promise);
}
});
} catch (Throwable t) {
......
}
}
}
private void register0(ChannelPromise promise) {
try {
// check if the channel is still open as it could be closed in the mean time when the register
// call was outside of the eventLoop
if (!promise.setUncancellable() || !ensureOpen(promise)) {
return;
}
boolean firstRegistration = neverRegistered;
// 该方法在本类中是一个空实现，下面看一下它在子类 AbstractNioChannel 中的实现
doRegister();
neverRegistered = false;
registered = true;
pipeline.invokeHandlerAddedIfNeeded();
safeSetSuccess(promise);
pipeline.fireChannelRegistered();
if (isActive()) {
if (firstRegistration) {
pipeline.fireChannelActive();
} else if (config().isAutoRead()) {
beginRead();
}
}
} catch (Throwable t) {
closeForcibly();
closeFuture.setClosed();
safeSetFailure(promise, t);
}
}
}
}
public abstract class AbstractNioChannel extends AbstractChannel {
@Override
protected void doRegister() throws Exception {
boolean selected = false;
for (;;) {
try {
// 将 NioServerSocketChannel 注册到 NioEventLoop 的 多路复用器Selector 上
selectionKey = javaChannel().register(eventLoop().unwrappedSelector(), 0, this);
return;
} catch (CancelledKeyException e) {
......
}
}
}
}
```
到此，服务端监听启动部分源码已经分析完成。
## 结合 Netty源码 对客户端接入过程进行解析
负责处理网络读写、连接和客户端请求接入的 Reactor线程 就是 NioEventLoop，下面我们看下 NioEventLoop 是如何处理新的客户端连接接入的。当 多路复用器 检测到新的准备就绪的 Channel 时，默认执行 processSelectedKeysOptimized()方法，代码如下。
```java
public final class NioEventLoop extends SingleThreadEventLoop {
private void processSelectedKeys() {
if (selectedKeys != null) {
processSelectedKeysOptimized();
} else {
processSelectedKeysPlain(selector.selectedKeys());
}
}
private void processSelectedKeysOptimized() {
for (int i = 0; i < selectedKeys.size; ++i) {
final SelectionKey k = selectedKeys.keys[i];
selectedKeys.keys[i] = null;
final Object a = k.attachment();
if (a instanceof AbstractNioChannel) {
// 根据就绪的操作位 SelectionKey，执行不同的操作
processSelectedKey(k, (AbstractNioChannel) a);
} else {
@SuppressWarnings("unchecked")
NioTask<SelectableChannel> task = (NioTask<SelectableChannel>) a;
processSelectedKey(k, task);
}
if (needsToSelectAgain) {
selectedKeys.reset(i + 1);
selectAgain();
i = -1;
}
}
}
// 根据就绪的操作位 SelectionKey，执行不同的操作
private void processSelectedKey(SelectionKey k, AbstractNioChannel ch) {
// 由于不同的 Channel 执行不同的操作，所以 NioUnsafe 被设计成接口
// 由不同的 Channel 内部的 NioUnsafe实现类 负责具体实现
final AbstractNioChannel.NioUnsafe unsafe = ch.unsafe();
if (!k.isValid()) {
final EventLoop eventLoop;
try {
eventLoop = ch.eventLoop();
} catch (Throwable ignored) {
return;
}
if (eventLoop != this || eventLoop == null) {
return;
}
unsafe.close(unsafe.voidPromise());
return;
}
try {
int readyOps = k.readyOps();
if ((readyOps & SelectionKey.OP_CONNECT) != 0) {
int ops = k.interestOps();
ops &= ~SelectionKey.OP_CONNECT;
k.interestOps(ops);
unsafe.finishConnect();
}
if ((readyOps & SelectionKey.OP_WRITE) != 0) {
ch.unsafe().forceFlush();
}
// read()方法 的实现有两个，分别是 NioByteUnsafe 和 NioMessageUnsafe，
// 对于 NioServerSocketChannel，它使用的是 NioMessageUnsafe
// 下面看一下 NioMessageUnsafe 对 read() 方法的实现
if ((readyOps & (SelectionKey.OP_READ | SelectionKey.OP_ACCEPT)) != 0 || readyOps == 0) {
unsafe.read();
}
} catch (CancelledKeyException ignored) {
unsafe.close(unsafe.voidPromise());
}
}
}
public abstract class AbstractNioMessageChannel extends AbstractNioChannel {
private final class NioMessageUnsafe extends AbstractNioUnsafe {
private final List<Object> readBuf = new ArrayList<Object>();
@Override
public void read() {
assert eventLoop().inEventLoop();
final ChannelConfig config = config();
final ChannelPipeline pipeline = pipeline();
final RecvByteBufAllocator.Handle allocHandle = unsafe().recvBufAllocHandle();
allocHandle.reset(config);
boolean closed = false;
Throwable exception = null;
try {
try {
do {
// 接收新的客户端连接并创建 NioSocketChannel
int localRead = doReadMessages(readBuf);
if (localRead == 0) {
break;
}
if (localRead < 0) {
closed = true;
break;
}
allocHandle.incMessagesRead(localRead);
} while (allocHandle.continueReading());
} catch (Throwable t) {
exception = t;
}
int size = readBuf.size();
for (int i = 0; i < size; i ++) {
readPending = false;
// 接收到新的客户端连接后，触发 ChannelPipeline 的 channelRead方法。
// 事件在 ChannelPipeline 中传递，执行 ServerBootstrapAcceptor 的
// channelRead方法
pipeline.fireChannelRead(readBuf.get(i));
}
......
}
}
}
}
public class NioServerSocketChannel extends AbstractNioMessageChannel
implements io.netty.channel.socket.ServerSocketChannel {
/**
* 接收新的客户端连接并创建 NioSocketChannel
*/
@Override
protected int doReadMessages(List<Object> buf) throws Exception {
SocketChannel ch = SocketUtils.accept(javaChannel());
try {
if (ch != null) {
buf.add(new NioSocketChannel(this, ch));
return 1;
}
} catch (Throwable t) {
......
}
return 0;
}
}
public class ServerBootstrap extends AbstractBootstrap<ServerBootstrap, ServerChannel> {
private static class ServerBootstrapAcceptor extends ChannelInboundHandlerAdapter {
/**
* 该方法主要分为如下三个步骤。
*/
@Override
@SuppressWarnings("unchecked")
public void channelRead(ChannelHandlerContext ctx, Object msg) {
final Channel child = (Channel) msg;
// 第一步:将启动时传入的 childHandler 加入到客户端 SocketChannel 的 ChannelPipeline 中
child.pipeline().addLast(childHandler);
// 第二步:设置客户端 SocketChannel 的 TCP参数
setChannelOptions(child, childOptions, logger);
for (Entry<AttributeKey<?>, Object> e: childAttrs) {
child.attr((AttributeKey<Object>) e.getKey()).set(e.getValue());
}
// 第三步:注册 SocketChannel 到多路复用器
try {
childGroup.register(child).addListener(new ChannelFutureListener() {
@Override
public void operationComplete(ChannelFuture future) throws Exception {
if (!future.isSuccess()) {
forceClose(child, future.cause());
}
}
});
} catch (Throwable t) {
forceClose(child, t);
}
}
}
}
```
下面我们展开看下 NioSocketChannel 的 register()方法。NioSocketChannel 的注册方法与 ServerSocketChannel 的一致, 也是将 Channel 注册到 Reactor线程 的多路复用器上。由于注册的操作位是 0，所以，此时 NioSocketChannel 还不能读取客户端发送的消息，下面我们看看 是什么时候修改监听操作位为 OP_READ 的。
执行完注册操作之后，紧接着会触发 ChannelReadComplete 事件。我们继续分析 ChannelReadComplete 在 ChannelPipeline 中的处理流程：Netty 的 Header 和 Tail 本身不关注 ChannelReadComplete事件 就直接透传，执行完 ChannelReadComplete 后，接着执行 PipeLine 的 read()方法，最终执行 HeadHandler 的 read()方法。
HeadHandler 的 read()方法用来将网络操作位修改为读操作。创建 NioSocketChannel 的时候已经将 AbstractNioChannel 的 readInterestOp 设置为 OP_ READ，这样，执行 selectionKey. interestOps(interestOps | readInterestOp)操作 时就会把操作位设置为 OP_READ。代码如下。
```java
public abstract class AbstractNioByteChannel extends AbstractNioChannel {
protected AbstractNioByteChannel(Channel parent, SelectableChannel ch) {
super(parent, ch, SelectionKey.OP_READ);
}
}
```
到此，新接入的客户端连接处理完成，可以进行网络读写等 IO操作。

205
docs/Spring/AOP/AOP源码实现及分析.md
Unescape View File

@ -1,17 +1,16 @@
理论性的文字，我觉得就没必要再扯一遍咯，大道理讲这么多，越听越迷糊。不如直接看源码+注解来的明白痛快。所以话不多说，直接上源码。
理论性的文字，我觉得就没必要再扯一遍咯，大道理讲这么多，越听越迷糊。不如直接看源码加注释来的明白痛快。所以话不多说，直接上源码。
## 1、主要的接口
### 1.1、Advice 通知
定义了切面的增强方式，如：前置增强 BeforeAdvice，后置增强 AfterAdvice，异常增强 ThrowsAdvice 等。下面看两个主要的子接口的源码。
## 1 主要的接口
### 1.1 Advice 通知
本接口定义了切面的增强方式，如：前置增强 BeforeAdvice，后置增强 AfterAdvice，异常增强 ThrowsAdvice 等。下面看两个主要的子接口的源码。
```java
public interface MethodBeforeAdvice extends BeforeAdvice {
/**
* 目标方法 method 要开始执行时，AOP 会回调此方法
* 目标方法 method 开始执行前，AOP 会回调此方法
*/
void before(Method method, Object[] args, Object target) throws Throwable;
}
public interface AfterReturningAdvice extends AfterAdvice {
@ -20,11 +19,10 @@ public interface AfterReturningAdvice extends AfterAdvice {
* 目标方法 method 执行后，AOP 会回调此方法，注意，它还传入了 method 的返回值
*/
void afterReturning(Object returnValue, Method method, Object[] args, Object target) throws Throwable;
}
```
### 1.2、Pointcut 方法的横切面
用来定义需要增强的目标方法的集合，一般使用正则表达式去匹配筛选指定范围内的所有满足条件的目标方法。Pointcut 接口有很多实现，我们主要看一下 JdkRegexpMethodPointcut 和 NameMatchMethodPointcut 的实现原理，前者主要通过正则表达式对方法名进行匹配，后者则通过匹配方法名进行匹配。
### 1.2 Pointcut 方法的横切面
本接口用来定义需要增强的目标方法的集合，一般使用正则表达式去匹配筛选指定范围内的所有满足条件的目标方法。Pointcut 接口有很多实现，我们主要看一下 JdkRegexpMethodPointcut 和 NameMatchMethodPointcut 的实现原理，前者主要通过正则表达式对方法名进行匹配，后者则通过匹配方法名进行匹配。
```java
// JdkRegexpMethodPointcut 的实现源码
@ -47,7 +45,7 @@ public interface AfterReturningAdvice extends AfterAdvice {
return false;
}
```
### 1.3、Advisor 通知器
### 1.3 Advisor 通知器
将 Pointcut 和 Advice 有效地结合在一起。它定义了在哪些方法（Pointcut）上执行哪些动作（Advice）。下面看一下 DefaultPointcutAdvisor 的源码实现，它通过持有 Pointcut 和 Advice 属性来将两者有效地结合在一起。
```java
@ -63,7 +61,7 @@ public class DefaultPointcutAdvisor extends AbstractGenericPointcutAdvisor imple
}
/**
* 自己定义了 Pointcut，Advice 则使用父类中的定义
* 自己定义了 Pointcut属性，而 Advice属性 则使用父类中的定义
*/
public DefaultPointcutAdvisor(Pointcut pointcut, Advice advice) {
this.pointcut = pointcut;
@ -88,16 +86,13 @@ public abstract class AbstractGenericPointcutAdvisor extends AbstractPointcutAdv
public String toString() {
return getClass().getName() + ": advice [" + getAdvice() + "]";
}
}
```
## 2、spring AOP 的设计与实现
AOP 的实现代码中，主要使用了 JDK 动态代理，在特定场景下（被代理对象无 implements 的接口）也用到了 CGLIB 生成代理对象。通过 AOP 的源码设计可以看到，其先为目标对象建立了代理对象，这个代理对象的生成可以使用 JDK 动态代理或 CGLIB 完成。然后启动为代理对象配置的拦截器，对横切面（目标方法集合）进行相应的增强，将 AOP 的横切面设计和 Proxy 模式有机地结合起来，实现了在 AOP 中定义好的各种织入方式。
### 2.1、ProxyFactoryBean
这里我们主要以 ProxyFactoryBean 的实现为例，对 AOP 的实现原理进行分析。ProxyFactoryBean 主要持有目标对象 target 的代理对象 aopProxy，和 Advisor 通知器，而 Advisor 持有 Advice 和 Pointcut，这样就可以判断 aopProxy 中的方法 是否是某个指定的切面 Pointcut，然后根据其配置的织入方向（前置增强/后置增强），通过反射为其织入相应的增强行为 Advice。
## 2 Spring AOP 的设计与实现
AOP 的实现代码中，主要使用了 JDK 动态代理，在特定场景下（被代理对象没有 implements 的接口）也用到了 CGLIB 生成代理对象。通过 AOP 的源码设计可以看到，其先为目标对象建立了代理对象，这个代理对象的生成可以使用 JDK 动态代理或 CGLIB 完成。然后启动为代理对象配置的拦截器，对横切面（目标方法集合）进行相应的增强，将 AOP 的横切面设计和 Proxy 模式有机地结合起来，实现了在 AOP 中定义好的各种织入方式。
先看一下 ProxyFactoryBean 的配置和使用。
### 2.1 ProxyFactoryBean
这里我们主要以 ProxyFactoryBean 的实现为例，对 AOP 的实现原理进行分析。ProxyFactoryBean 主要持有目标对象 target 的代理对象 aopProxy，和 Advisor 通知器，而 Advisor 持有 Advice 和 Pointcut，这样就可以判断 aopProxy 中的方法 是否是某个指定的切面 Pointcut，然后根据其配置的织入方向（前置增强/后置增强），通过反射为其织入相应的增强行为 Advice。先看一下 ProxyFactoryBean 的配置和使用。
```xml
<!-- 定义自己的 Advisor 实现，其中包含了 Pointcut 和 Advice -->
@ -116,7 +111,7 @@ AOP 的实现代码中，主要使用了 JDK 动态代理，在特定场景下
</property>
</bean>
```
### 2.2、ProxyFactoryBean 为配置的 target 生成 AopProxy 代理对象
### 2.2 为配置的 target 生成 AopProxy 代理对象
ProxyFactoryBean 的 getObject() 方法先对通知器链进行了初始化，然后根据被代理对象类型的不同，生成代理对象。
```java
@ -140,7 +135,7 @@ ProxyFactoryBean 的 getObject() 方法先对通知器链进行了初始化，
}
}
```
### 2.3、initializeAdvisorChain() 初始化 Advisor 链
### 2.3 初始化 Advisor 链
```java
/**
@ -171,7 +166,6 @@ ProxyFactoryBean 的 getObject() 方法先对通知器链进行了初始化，
if (logger.isTraceEnabled()) {
logger.trace("Configuring advisor or advice '" + name + "'");
}
if (name.endsWith(GLOBAL_SUFFIX)) {
if (!(this.beanFactory instanceof ListableBeanFactory)) {
throw new AopConfigException(
@ -180,7 +174,6 @@ ProxyFactoryBean 的 getObject() 方法先对通知器链进行了初始化，
addGlobalAdvisor((ListableBeanFactory) this.beanFactory,
name.substring(0, name.length() - GLOBAL_SUFFIX.length()));
}
else {
// 对当前的 factoryBean 进行类型判断，是属于单例 bean 还是原型 bean
Object advice;
@ -197,16 +190,15 @@ ProxyFactoryBean 的 getObject() 方法先对通知器链进行了初始化，
}
}
}
this.advisorChainInitialized = true;
}
```
生成 singleton 的代理对象在 getSingletonInstance 方法中完成，这是 ProxyFactoryBean 生成 AopProxy 代理对象的调用入口。代理对象会封装对 target 对象的调用，针对 target 对象的方法调用会被这里生成的代理对象所拦截。
### 2.4、getSingletonInstance() 生成单例代理对象
### 2.4 生成单例代理对象
```java
/**
* 返回此类代理对象的单例实例，如果尚未创建该实例，则使用单例模式的懒汉式 创建它
* 返回此类代理对象的单例实例，如果尚未创建该实例，则单例地创建它
*/
private synchronized Object getSingletonInstance() {
if (this.singletonInstance == null) {
@ -263,11 +255,10 @@ public class ProxyCreatorSupport extends AdvisedSupport {
public AopProxyFactory getAopProxyFactory() {
return this.aopProxyFactory;
}
}
```
下面看一下 AopProxyFactory 接口的实现类 DefaultAopProxyFactory 的代码。
下面看一下 AopProxyFactory 接口的实现类 DefaultAopProxyFactory 的 createAopProxy(AdvisedSupport config)方法。
```java
public AopProxy createAopProxy(AdvisedSupport config) throws AopConfigException {
@ -299,10 +290,17 @@ public class ProxyCreatorSupport extends AdvisedSupport {
可以看到其根据目标对象是否实现了接口，而决定是使用 JDK动态代理 还是 CGLIB 去生成代理对象，而 AopProxy 接口的实现类也只有 JdkDynamicAopProxy 和 CglibAopProxy 这两个。
### 2.5、JDK 生成 AopProxy 代理对象
### 2.5 JDK动态代理 生成 AopProxy代理对象
```java
/**
* 可以看到，其实现了 InvocationHandler 接口，所以肯定也定义了一个 使用 java.lang.reflect.Proxy
* 动态生成代理对象的方法，并在实现的 invoke() 方法中为代理对象织入增强方法
*/
final class JdkDynamicAopProxy implements AopProxy, InvocationHandler, Serializable {
/** AdvisedSupport 持有一个 List<Advisor>属性 */
private final AdvisedSupport advised;
public JdkDynamicAopProxy(AdvisedSupport config) throws AopConfigException {
Assert.notNull(config, "AdvisedSupport must not be null");
if (config.getAdvisors().length == 0 && config.getTargetSource() == AdvisedSupport.EMPTY_TARGET_SOURCE) {
@ -326,16 +324,21 @@ final class JdkDynamicAopProxy implements AopProxy, InvocationHandler, Serializa
Class[] proxiedInterfaces = AopProxyUtils.completeProxiedInterfaces(this.advised);
findDefinedEqualsAndHashCodeMethods(proxiedInterfaces);
//通过 Proxy 生成代理对象并返回
// 通过 java.lang.reflect.Proxy 生成代理对象并返回
return Proxy.newProxyInstance(classLoader, proxiedInterfaces, this);
}
}
```
通过 JdkDynamicAopProxy 的源码可以非常清楚地看到，其使用了 JDK 动态代理的方式生成了代理对象。JdkDynamicAopProxy 实现了 InvocationHandler 接口，并通过 Proxy.newProxyInstance() 方法生成代理对象并返回。
通过 JdkDynamicAopProxy 的源码可以非常清楚地看到，其使用了 JDK动态代理 的方式生成了 代理对象。JdkDynamicAopProxy 实现了 InvocationHandler 接口，并通过 java.lang.reflect.Proxy 的 newProxyInstance()静态方法 生成代理对象并返回。
### 2.6、CGLIB 生成 AopProxy 代理对象（CglibAopProxy）
### 2.6 CGLIB 生成 AopProxy代理对象
```java
final class CglibAopProxy implements AopProxy, Serializable {
/** AdvisedSupport 持有一个 List<Advisor>属性 */
protected final AdvisedSupport advised;
public Object getProxy(ClassLoader classLoader) {
if (logger.isDebugEnabled()) {
logger.debug("Creating CGLIB proxy: target source is " + this.advised.getTargetSource());
@ -410,14 +413,16 @@ final class JdkDynamicAopProxy implements AopProxy, InvocationHandler, Serializa
}
}
```
为目标对象 target 生成代理对象之后，在调用代理对象的目标方法时，目标方法会进行 invoke() 回调或 callbacks() 回调，然后就可以在回调方法中对目标对象的目标方法进行拦截和增强处理了。
为 目标对象target 生成 代理对象 之后，在调用 代理对象 的目标方法时，目标方法会进行 invoke()回调（JDK动态代理） 或 callbacks()回调（CGLIB），然后就可以在回调方法中对目标对象的目标方法进行拦截和增强处理了。
## 3、spring AOP 拦截器调用的实现
在 spring AOP 通过 JDK 的 Proxy 类生成代理对象时，相关的拦截器已经配置到了代理对象持有的 InvocationHandler(即，ProxyBeanFactory) 的 invoke() 方法中，拦截器最后起作用，是通过调用代理对象的目标方法时，在代理类中触发了 InvocationHandler 的 invoke() 回调。通过 CGLIB 实现的 AOP，原理与此相似。
## 3 Spring AOP 拦截器调用的实现
在 Spring AOP 通过 JDK 的 Proxy类 生成代理对象时，相关的拦截器已经配置到了代理对象持有的 InvocationHandler(即，ProxyBeanFactory) 的 invoke() 方法中，拦截器最后起作用，是通过调用代理对象的目标方法时，在代理类中触发了 InvocationHandler 的 invoke() 回调。通过 CGLIB 实现的 AOP，原理与此相似。
### 3.1、JdkDynamicAopProxy 的 invoke() 拦截
### 3.1 JdkDynamicAopProxy 的 invoke() 拦截
前面已经通过两种不同的方式生成了 AopProxy 代理对象，下面我们先看一下 JdkDynamicAopProxy 中的 invoke()回调方法 中对拦截器调用的实现。
```java
final class JdkDynamicAopProxy implements AopProxy, InvocationHandler, Serializable {
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
MethodInvocation invocation;
Object oldProxy = null;
@ -429,7 +434,7 @@ final class JdkDynamicAopProxy implements AopProxy, InvocationHandler, Serializa
Object target = null;
try {
//如果目标对象调用的是 Obejct 类中的基本方法，如：equals、hashCode 则进行相应的处理
// 如果目标对象调用的是 Obejct类 中的基本方法，如：equals()、hashCode() 则进行相应的处理
if (!this.equalsDefined && AopUtils.isEqualsMethod(method)) {
// 如果目标对象没有重写 Object类 的基本方法：equals(Object other)
return equals(args[0]);
@ -458,10 +463,10 @@ final class JdkDynamicAopProxy implements AopProxy, InvocationHandler, Serializa
targetClass = target.getClass();
}
//获取定义好的拦截器链
// 获取定义好的拦截器链，即 Advisor列表
List<Object> chain = this.advised.getInterceptorsAndDynamicInterceptionAdvice(method, targetClass);
//如果没有配置拦截器，就直接调用目标对象 target 的 method 方法，并获取返回值
// 如果没有配置拦截器，就直接通过反射调用目标对象 target 的 method对象，并获取返回值
if (chain.isEmpty()) {
retVal = AopUtils.invokeJoinpointUsingReflection(target, method, args);
}
@ -478,7 +483,7 @@ final class JdkDynamicAopProxy implements AopProxy, InvocationHandler, Serializa
if (retVal != null && retVal == target && returnType.isInstance(proxy) &&
!RawTargetAccess.class.isAssignableFrom(method.getDeclaringClass())) {
// 特殊提醒：它返回“this”，方法的返回类型与类型兼容。
//注意，如果 target 在另一个返回的对象中设置了对自身的引用，spring 将无法处理
// 注意，如果 target 在另一个返回的对象中设置了对自身的引用，Spring 将无法处理
retVal = proxy;
} else if (retVal == null && returnType != Void.TYPE && returnType.isPrimitive()) {
throw new AopInvocationException("Null return value from advice does not match primitive return type for: " + method);
@ -496,11 +501,14 @@ final class JdkDynamicAopProxy implements AopProxy, InvocationHandler, Serializa
}
}
}
}
```
### 3.2、CglibAopProxy 的 intercept() 拦截
### 3.2 CglibAopProxy 的 intercept() 拦截
CglibAopProxy 的 intercept() 回调方法实现和 JdkDynamicAopProxy 的 invoke() 非常相似，只是在 CglibAopProxy 中构造 CglibMethodInvocation 对象来完成拦截器链的调用，而在 JdkDynamicAopProxy 中则是通过构造 ReflectiveMethodInvocation 对象来完成的。
```java
final class CglibAopProxy implements AopProxy, Serializable {
public Object intercept(Object proxy, Method method, Object[] args, MethodProxy methodProxy) throws Throwable {
Object oldProxy = null;
boolean setProxyContext = false;
@ -542,9 +550,10 @@ CglibAopProxy 的 intercept() 回调方法实现和 JdkDynamicAopProxy 的 invok
}
}
}
}
```
### 3.3、目标对象中目标方法的调用
对目标对象中目标方法的调用，是在 AopUtils 工具类中利用反射机制完成的。具体代码如下：
### 3.3 目标对象中目标方法的调用
对目标对象中目标方法的调用，是在 AopUtils 工具类中利用反射机制完成的，具体代码如下。
```java
public abstract class AopUtils {
@ -556,7 +565,7 @@ public abstract class AopUtils {
throws Throwable {
try {
//如果 method 是 private 等不可访问状态，则设置为 public 公开可访问
// 如果该 method 是 private的，则将其访问权限设为 public的
ReflectionUtils.makeAccessible(method);
// 最后利用反射完成调用
return method.invoke(target, args);
@ -574,30 +583,59 @@ public abstract class AopUtils {
}
}
```
### 3.4、AOP 拦截器链的调用
### 3.4 AOP 拦截器链的调用
JdkDynamicAopProxy 和 CglibAopProxy 虽然使用了不同的代理对象，但对 AOP 拦截的处理却是相同的，都是通过 ReflectiveMethodInvocation 的 proceed() 方法实现的。
```java
public class ReflectiveMethodInvocation implements ProxyMethodInvocation, Cloneable {
protected final Object proxy;
protected final Object target;
protected final Method method;
protected Object[] arguments;
private final Class targetClass;
/** MethodInterceptor和InterceptorAndDynamicMethodMatcher的集合 */
protected final List interceptorsAndDynamicMethodMatchers;
private int currentInterceptorIndex = -1;
protected ReflectiveMethodInvocation(Object proxy, Object target, Method method,
Object[] arguments, Class targetClass,
List<Object> interceptorsAndDynamicMethodMatchers) {
this.proxy = proxy;
this.target = target;
this.targetClass = targetClass;
this.method = BridgeMethodResolver.findBridgedMethod(method);
this.arguments = arguments;
this.interceptorsAndDynamicMethodMatchers = interceptorsAndDynamicMethodMatchers;
}
public Object proceed() throws Throwable {
//从拦截器链中按顺序依次调用拦截器，直到所有的拦截器调用完毕，开始调用目标方法，
//对目标方法的调用是在 invokeJoinpoint() 中通过 AopUtils 的 invokeJoinpointUsingReflection() 方法完成的
// 从拦截器链中按顺序依次调用拦截器，直到所有的拦截器调用完毕，开始调用目标方法，对目标方法的调用
// 是在 invokeJoinpoint() 中通过 AopUtils 的 invokeJoinpointUsingReflection() 方法完成的
if (this.currentInterceptorIndex == this.interceptorsAndDynamicMethodMatchers.size() - 1) {
// invokeJoinpoint() 直接通过 AopUtils 进行目标方法的调用
return invokeJoinpoint();
}
// 这里沿着定义好的 interceptorsAndDynamicMethodMatchers拦截器链 进行处理，
//它是一个 List，也没有定义泛型，interceptorOrInterceptionAdvice 是其中的一个元素，
// 它是一个 List，也没有定义泛型，interceptorOrInterceptionAdvice 是其中的一个元素
Object interceptorOrInterceptionAdvice =
this.interceptorsAndDynamicMethodMatchers.get(++this.currentInterceptorIndex);
if (interceptorOrInterceptionAdvice instanceof InterceptorAndDynamicMethodMatcher) {
// 这里通过拦截器的 方法匹配器methodMatcher 进行方法匹配，
// 如果 目标类 的 目标方法 和配置的 Pointcut 匹配，那么这个 增强行为advice 将会被执行，
//Pointcut 定义了切面，advice 定义了增强的行为
// Pointcut 定义了切面方法（要进行增强的方法），advice 定义了增强的行为
InterceptorAndDynamicMethodMatcher dm = (InterceptorAndDynamicMethodMatcher) interceptorOrInterceptionAdvice;
// 目标类的目标方法是否为 Pointcut 所定义的切面
if (dm.methodMatcher.matches(this.method, this.targetClass, this.arguments)) {
//执行增强方法
// 执行当前这个 拦截器interceptor 的 增强方法
return dm.interceptor.invoke(this);
}
else {
@ -611,17 +649,29 @@ JdkDynamicAopProxy 和 CglibAopProxy 虽然使用了不同的代理对象，但
return ((MethodInterceptor) interceptorOrInterceptionAdvice).invoke(this);
}
}
}
```
### 3.5、配置通知器
### 3.5 配置通知器
AdvisedSupport 中实现了获取拦截器链的方法，并使用了缓存。
```java
public class AdvisedSupport extends ProxyConfig implements Advised {
/** TargetSource持有一个比较重要的属性，targetClass */
TargetSource targetSource = EMPTY_TARGET_SOURCE;
/** 缓存 Method对象 和其对应的 拦截器链列表List<Advisor> */
private transient Map<MethodCacheKey, List<Object>> methodCache;
/** The AdvisorChainFactory to use */
AdvisorChainFactory advisorChainFactory = new DefaultAdvisorChainFactory();
/**
* 获取拦截器链，为提高效率，同时设置了缓存
*/
public List<Object> getInterceptorsAndDynamicInterceptionAdvice(Method method, Class targetClass) {
//这里使用了缓存 cached，如果缓存中有就从缓存中获取拦截器链
// 如果 缓存methodCache 中有就从缓存中获取 该Method对象 对应的拦截器链
// 没有，则调用 (DefaultAdvisorChainFactory)advisorChainFactory 的
//getInterceptorsAndDynamicInterceptionAdvice() 方法进行获取，并缓存到 cached
// getInterceptorsAndDynamicInterceptionAdvice() 方法进行获取，并缓存到 methodCache 中
MethodCacheKey cacheKey = new MethodCacheKey(method);
List<Object> cached = this.methodCache.get(cacheKey);
if (cached == null) {
@ -632,6 +682,7 @@ AdvisedSupport 中实现了获取拦截器链的方法，并使用了缓存。
}
return cached;
}
}
```
获取拦截器链的工作是由 AdvisorChainFactory 完成的，他是一个拦截器链的生成工厂。由于 AdvisorChainFactory 接口只有一个实现类 DefaultAdvisorChainFactory，所以我们直接看这个类中的实现就行咯。
@ -642,8 +693,8 @@ public class DefaultAdvisorChainFactory implements AdvisorChainFactory, Serializ
public List<Object> getInterceptorsAndDynamicInterceptionAdvice(
Advised config, Method method, Class targetClass) {
//advisor 链已经在传进来的 config 中持有了，这里可以直接使用
//advisor 中持有切面 和 增强行为的引用
// Advisor链 已经在传进来的 config 中持有了，这里可以直接使用。
// Advisor 中持有 切面Pointcut 和 增强行为Advice 两个重要属性
List<Object> interceptorList = new ArrayList<Object>(config.getAdvisors().length);
// 判断 config 中的 Advisors 是否符合配置要求
boolean hasIntroductions = hasMatchingIntroductions(config, targetClass);
@ -704,13 +755,15 @@ public class DefaultAdvisorChainFactory implements AdvisorChainFactory, Serializ
}
return false;
}
}
```
这里的 advisor 通知器是从 AdvisedSupport 中获取的，而 advisor 的初始化则是在 ProxyFactoryBean 的 getObject() 方法中完成的。
```java
public class ProxyFactoryBean extends ProxyCreatorSupport
implements FactoryBean<Object>, BeanClassLoaderAware, BeanFactoryAware {
/**
* 返回一个代理对象，当用户从 FactoryBean 中获取 bean 时调用，
* 创建此工厂要返回的 AOP 代理的实例，该实例将作为一个单例被缓存
@ -718,7 +771,7 @@ public class DefaultAdvisorChainFactory implements AdvisorChainFactory, Serializ
public Object getObject() throws BeansException {
// 初始化通知器链
initializeAdvisorChain();
//这里对 Singleton 和 prototype 的类型进行区分，生成对应的 proxy
// 这里对 Singleton 和 Prototype 的类型进行区分，生成对应的 proxy
if (isSingleton()) {
return getSingletonInstance();
}
@ -753,8 +806,8 @@ public class DefaultAdvisorChainFactory implements AdvisorChainFactory, Serializ
// 这里添加了 Advisor链 的调用，下面的 interceptorNames 是在配置文件中
// 通过 interceptorNames 进行配置的。由于每一个 Advisor 都是被配置为 bean 的，
//所以通过遍历 interceptorNames 得到的 name，其实就是 bean 的 id，通过这个 name（id）
//我们就可以从 IoC 容器中获取对应的实例化 bean
// 所以通过遍历 interceptorNames 得到的 name，其实就是 bean（Advisor） 的 id，通过这个 name（id）
// 我们就可以从 IoC 容器中获取对应的实例化 bean（Advisor）
for (String name : this.interceptorNames) {
if (logger.isTraceEnabled()) {
logger.trace("Configuring advisor or advice '" + name + "'");
@ -770,7 +823,7 @@ public class DefaultAdvisorChainFactory implements AdvisorChainFactory, Serializ
}
else {
//对当前的 factoryBean 进行类型判断，是属于单例 bean 还是原型 bean
// 对当前的 factoryBean 进行类型判断，是属于 单例bean，还是 原型bean
Object advice;
if (this.singleton || this.beanFactory.isSingleton(name)) {
// advisor 在文件中配置为 bean，所以这里通过 beanFactory 的 getBean()方法
@ -787,22 +840,25 @@ public class DefaultAdvisorChainFactory implements AdvisorChainFactory, Serializ
}
}
}
this.advisorChainInitialized = true;
}
}
```
注意，Advisor 本身就被配置为 bean，所以它的获取也是通过 IoC容器 获得的。
### 3.6、Advice 通知的实现
### 3.6 Advice 通知的实现
从 DefaultAdvisorChainFactory 类中的 getInterceptorsAndDynamicInterceptionAdvice() 方法我们可以看到，其通过 AdvisorAdapterRegistry 实例对象的 getInterceptors() 方法，利用配置的 advisor 完成了对拦截器的适配和注册。
```java
public class DefaultAdvisorChainFactory implements AdvisorChainFactory, Serializable {
public List<Object> getInterceptorsAndDynamicInterceptionAdvice(
Advised config, Method method, Class targetClass) {
//advisor 链已经在传进来的 config 中持有了，这里可以直接使用
//advisor 中持有切面 和 增强行为的引用
// Advisor链 已经在传进来的 config 中持有了，这里可以直接使用
// Advisor 中持有 切面Pointcut 和 增强行为Advice 的引用
List<Object> interceptorList = new ArrayList<Object>(config.getAdvisors().length);
// 判断 config 中的 Advisors 是否符合配置要求
boolean hasIntroductions = hasMatchingIntroductions(config, targetClass);
@ -847,6 +903,7 @@ public class DefaultAdvisorChainFactory implements AdvisorChainFactory, Serializ
}
return interceptorList;
}
}
```
DefaultAdvisorAdapterRegistry 的 getInterceptors()方法 封装了 advice 织入实现的入口。
@ -855,7 +912,7 @@ DefaultAdvisorAdapterRegistry 的 getInterceptors() 方法封装了 advice 织
public class DefaultAdvisorAdapterRegistry implements AdvisorAdapterRegistry, Serializable {
// 持有 AdvisorAdapter 的 list，这个 list 中的 AdvisorAdapter 与
//实现 spring AOP 的 advice 增强功能相对应
// 实现 Spring AOP 的 advice 增强功能相对应
private final List<AdvisorAdapter> adapters = new ArrayList<AdvisorAdapter>(3);
/**
@ -903,8 +960,7 @@ public class DefaultAdvisorAdapterRegistry implements AdvisorAdapterRegistry, Se
// 对通知进行适配，使用已经配置好的三种 AdvisorAdapter，然后从对应的
// adapter 中取出封装好的 AOP 编织功能的拦截器
for (AdvisorAdapter adapter : this.adapters) {
//adapter.supportsAdvice(advice) 方法中对 advice 的
//类型进行校验
// adapter.supportsAdvice(advice) 方法中对 advice 的类型进行校验
if (adapter.supportsAdvice(advice)) {
interceptors.add(adapter.getInterceptor(advisor));
}
@ -917,8 +973,7 @@ public class DefaultAdvisorAdapterRegistry implements AdvisorAdapterRegistry, Se
}
```
从 DefaultAdvisorAdapterRegistry 的实现中可以看到，其使用了一系列的 AdviceAdapter 适配器，如：MethodBeforeAdviceAdapter、AfterReturningAdviceAdapter、ThrowsAdviceAdapter，它们完全和 advice 的类型
一一对应，它们都是实现了 AdviceAdapter 接口的同一层次类，各自承担着不同的适配任务，一对一地服务于不同的 advice 实现。下面我们以 MethodBeforeAdviceAdapter 为例，看一下其源码实现。
从 DefaultAdvisorAdapterRegistry 的实现中可以看到，其使用了一系列的 AdviceAdapter 适配器，如：MethodBeforeAdviceAdapter、AfterReturningAdviceAdapter、ThrowsAdviceAdapter，它们完全和 Advice 的类型一一对应，它们都是实现了 AdviceAdapter 接口的同一层次类，各自承担着不同的适配任务，一对一地服务于不同的 Advice 实现。下面我们以 MethodBeforeAdviceAdapter 为例，看一下其源码实现。
```java
class MethodBeforeAdviceAdapter implements AdvisorAdapter, Serializable {
@ -931,11 +986,10 @@ class MethodBeforeAdviceAdapter implements AdvisorAdapter, Serializable {
MethodBeforeAdvice advice = (MethodBeforeAdvice) advisor.getAdvice();
return new MethodBeforeAdviceInterceptor(advice);
}
}
```
可以看到，其中的 getInterceptor() 方法把 advice 从 advisor 中取出来，然后创建了一个 MethodBeforeAdviceInterceptor 对象，并返回，这个对象中持有对 advice 的引用。下面我们看一下 MethodBeforeAdviceInterceptor 拦截器的源码实现。
可以看到，其中的 getInterceptor()方法 把 Advice 从 Advisor 中取出来，然后创建了一个 MethodBeforeAdviceInterceptor对象，并返回，这个对象中持有对 Advice 的引用。下面我们看一下 MethodBeforeAdviceInterceptor 拦截器的源码实现。
```java
public class MethodBeforeAdviceInterceptor implements MethodInterceptor, Serializable {
@ -951,21 +1005,20 @@ public class MethodBeforeAdviceInterceptor implements MethodInterceptor, Seriali
}
/**
* 这个 invoke 方法是拦截器的回调方法，会在代理对象的方法被调用时触发回调
* 这个 invoke()方法 是拦截器的回调方法，会在代理对象的方法被调用时触发回调
*/
public Object invoke(MethodInvocation mi) throws Throwable {
//首先触发了 advice 的 before() 方法的回调
// 首先触发了 advice对象 的 before()方法 的回调
// 然后才是 MethodInvocation 的 process()方法 回调
this.advice.before(mi.getMethod(), mi.getArguments(), mi.getThis() );
return mi.proceed();
}
}
```
可以看到，MethodBeforeAdviceInterceptor 的 invoke()方法 先是触发了 advice 的 before()方法，然后才是 MethodInvocation 的 proceed()方法调用。
回顾一下之前的代码，在 AopProxy 代理对象触发的 ReflectiveMethodInvocation 的 proceed() 中，在取得拦截器 interceptor 后调用了其 invoke() 方法。按照 AOP 的配置规则，ReflectiveMethodInvocation 触发的拦截器 invoke() 回调，最终会根据 advice 类型的不同，触发 spring 对不同的 advice 的拦截器封装，比如 MethodBeforeAdvice 最终会触发 MethodBeforeAdviceInterceptor 的 invoke() 回调，其它两个以此类推，这里就不逐一分析咯。
另外，可以结合我 GitHub 上对 spring 框架源码的阅读及个人理解一起看，会更有助于各位开发大佬理解，如果对你们有帮助的，还望各位老爷 watch，star，fork，素质三连一波，地址：https://github.com/AmyliaY/spring-aop-reading
回顾一下之前的代码，在 AopProxy代理对象 触发的 ReflectiveMethodInvocation 的 proceed() 中，在取得 拦截器interceptor 后调用了其 invoke()方法。按照 AOP 的配置规则，ReflectiveMethodInvocation 触发的拦截器 invoke()回调，最终会根据 Advice 类型的不同，触发 Spring 对不同的 Advice 的拦截器封装，比如 MethodBeforeAdvice 最终会触发 MethodBeforeAdviceInterceptor 的 invoke()回调，其它两个以此类推，这里就不逐一分析咯。
另外，可以结合我 GitHub 上对 Spring框架源码 的阅读及个人理解一起看，会更有助于各位开发大佬理解，如果本内容对你们有帮助的，还望各位同学 watch，star，fork，素质三连一波，地址：
https://github.com/AmyliaY/spring-aop-reading

45
docs/Spring/AOP/JDK动态代理的实现原理解析.md
Unescape View File

@ -1,9 +1,8 @@
最近在看 Spring AOP 部分的源码，所以对JDK动态代理具体是如何实现的这件事产生了很高的兴趣，而且能从源码上了解这个原理的话，也有助于对 spring-aop 模块的理解。话不多说，上代码。
```java
/**
* 一般会使用实现了 InvocationHandler接口的类 作为代理对象生成工厂，
* 并且通过持有被代理对象 target，在 invoke() 方法中对被代理对象的目标方法进行调用和增强，
* 一般会使用实现了 InvocationHandler接口 的类作为代理对象的生产工厂，
* 并且通过持有 被代理对象target，来在 invoke()方法 中对被代理对象的目标方法进行调用和增强，
* 这些我们都能通过下面这段代码看懂，但代理对象是如何生成的？invoke()方法 又是如何被调用的呢？
*/
public class ProxyFactory implements InvocationHandler {
@ -47,21 +46,22 @@ public class ProxyTest {
public static void main(String[] args) {
TargetObject target = new TargetObject();
// ProxyFactory 实现了 InvocationHandler 接口，其中的 getInstanse() 方法利用 Proxy 类帮助生成了
// target 目标对象的代理对象，并返回；且 ProxyFactory 持有对 target 的引用，可以在 invoke() 中完成对 target 相应方法
// 的调用，以及目标方法前置后置的增强处理
// ProxyFactory 实现了 InvocationHandler接口，其中的 getInstanse()方法 利用 Proxy类
// 生成了 target目标对象 的代理对象，并返回；且 ProxyFactory 持有对 target 的引用，可以在
// invoke() 中完成对 target 相应方法的调用，以及目标方法前置后置的增强处理
ProxyFactory proxyFactory = new ProxyFactory();
// 这个 mi 就是 JDK 的 Proxy 类生成的代理类$Proxy0 的对象，这个对象中的方法都持有对 invoke() 方法的回调
// 所以当调用其方法时，就能够执行 invoke() 中的增强处理
// 这个 mi 就是 JDK 的 Proxy类 动态生成的代理类 $Proxy0 的实例，该实例中的方法都持有对
// invoke()方法 的回调，所以当调用其方法时，就能够执行 invoke() 中的增强处理
MyInterface mi = (MyInterface) proxyFactory.getInstanse(target);
// 这样可以看到 mi 的 Class 到底是什么
System.out.println(mi.getClass());
// 这里实际上调用的就是$Proxy0 中对 play() 方法的实现，可以看到 play 方法通过 super.h.invoke()
// 完成了对 InvocationHandler 对象 proxyFactory 的 invoke() 方法的回调
// 所以我才能够通过 invoke() 方法实现对 target 对象方法的前置后置增强处理
// 这里实际上调用的就是 $Proxy0代理类 中对 play()方法 的实现，结合下面的代码可以看到
// play()方法 通过 super.h.invoke() 完成了对 InvocationHandler对象(proxyFactory)中
// invoke()方法 的回调，所以我们才能够通过 invoke()方法 实现对 target对象 方法的
// 前置后置增强处理
mi.play();
// 总的来说，就是在 invoke() 方法中完成 target 目标方法的调用，及前置后置增强
// 然后通过生成的代理类完成对对 invoke() 的回调
// 总的来说，就是在 invoke()方法 中完成 target目标方法 的调用，及前置后置增强，
// JDK 动态生成的代理类中对 invoke()方法 进行了回调
}
/**
@ -92,10 +92,9 @@ public class ProxyTest {
}
/**
* Proxy 生成的代理类，可以看到，其继承了 Proxy，并且实现了被代理类的接口
* Proxy 生成的代理类，可以看到，其继承了 Proxy，并且实现了 被代理类的接口MyInterface
*/
public final class $Proxy0 extends Proxy implements MyInterface
{
public final class $Proxy0 extends Proxy implements MyInterface {
private static Method m1;
private static Method m0;
private static Method m3;
@ -105,7 +104,7 @@ public final class $Proxy0 extends Proxy implements MyInterface
try {
$Proxy0.m1 = Class.forName("java.lang.Object").getMethod("equals", Class.forName("java.lang.Object"));
$Proxy0.m0 = Class.forName("java.lang.Object").getMethod("hashCode", (Class<?>[])new Class[0]);
//实例化 MyInterface 的 play 方法
// 实例化 MyInterface 的 play()方法
$Proxy0.m3 = Class.forName("com.shuitu.test.MyInterface").getMethod("play", (Class<?>[])new Class[0]);
$Proxy0.m2 = Class.forName("java.lang.Object").getMethod("toString", (Class<?>[])new Class[0]);
}
@ -123,9 +122,9 @@ public final class $Proxy0 extends Proxy implements MyInterface
public final void play() {
try {
//这个 h 其实就是我们调用 Proxy.newProxyInstance() 方法时传进去的 ProxyFactory 对象，
//该对象的 invoke() 方法中实现了对目标对象的目标方法的增强。看到这里，利用动态代理实现方法增强的
//调用原理就全部理清咯
// 这个 h 其实就是我们调用 Proxy.newProxyInstance()方法 时传进去的 ProxyFactory对象(它实现了
// InvocationHandler接口)，该对象的 invoke()方法 中实现了对目标对象的目标方法的增强。
// 看到这里，利用动态代理实现方法增强的实现原理就全部理清咯
super.h.invoke(this, $Proxy0.m3, null);
}
catch (Error | RuntimeException error) {
@ -171,11 +170,5 @@ public final class $Proxy0 extends Proxy implements MyInterface
throw new UndeclaredThrowableException(t);
}
}
}
```
#### 动态代理原理图
![avatar](/images/动态代理原理图1.png)
![avatar](/images/动态代理原理图2.png)

114
docs/Spring/IoC/1、BeanDefinition的资源定位过程.md
Unescape View File

@ -1,19 +1,19 @@
## 前言
之前一直想系统的拜读一下 spring 的源码，看看它到底是如何吸引身边的大神们对它的设计赞不绝口，虽然每天工作很忙，每天下班后总感觉脑子内存溢出，想去放松一下，但总是以此为借口，恐怕会一直拖下去。所以每天下班虽然有些疲惫，但还是按住自己啃下这块硬骨头。
spring 源码这种东西真的是一回生二回熟，第一遍会被各种设计模式和繁杂的方法调用搞得晕头转向，不知道这个方法调用的是哪个父类的实现，另一个方法又调的是哪个子类的实现，但当你耐下心来多走几遍，会发现越看越熟练，每次都能 get 到新的点。
spring 源码这种东西真的是一回生二回熟，第一遍会被各种设计模式和繁杂的方法调用搞得晕头转向，不知道看到的这些方法调用的是哪个父类的实现（IoC相关的类图实在太复杂咯，继承体系又深又广），但当你耐下心来多走几遍，会发现越看越熟练，每次都能 get 到新的点。
另外，对于第一次看 spring 源码的同学，建议先在 B 站上搜索相关视频看一下，然后再结合计文柯老师的《spring 技术内幕》深入理解，最后再输出自己的理解加强印象。
另外，对于第一次看 spring 源码的同学，建议先在 B 站上搜索相关视频看一下，然后再结合计文柯老师的《spring 技术内幕》深入理解，最后再输出自己的理解（写博文或部门内部授课）加强印象。
首先对于我们新手来说，还是从我们最常用的两个 IoC 容器开始分析，这次我们先分析 FileSystemXmlApplicationContext 这个 IoC 容器的具体实现，ClassPathXmlApplicationContext 留着下次讲解。
（PS：可以结合我 GitHub 上对 spring 框架源码的翻译注解一起看，会更有助于各位开发姥爷的理解。
地址：
（PS：可以结合我 GitHub 上对 Spring 框架源码的翻译注释一起看，会更有助于各位同学的理解。地址：
spring-beans https://github.com/AmyliaY/spring-beans-reading
spring-context https://github.com/AmyliaY/spring-context-reading
）
## FileSystemXmlApplicationContext 的构造方法
当我们传入一个 spring 配置文件去实例化 FileSystemXmlApplicationContext() 时，可以看一下它的构造方法都做了什么。
## 正文
当我们传入一个 Spring 配置文件去实例化 FileSystemXmlApplicationContext 时，可以看一下它的构造方法都做了什么。
```java
/**
* 下面这 4 个构造方法都调用了第 5 个构造方法
@ -42,10 +42,6 @@ spring-context https://github.com/AmyliaY/spring-context-reading
/**
* 如果应用直接使用 FileSystemXmlApplicationContext 进行实例化，则都会进到这个构造方法中来
* @param configLocations
* @param refresh
* @param parent
* @throws BeansException
*/
public FileSystemXmlApplicationContext(String[] configLocations, boolean refresh, ApplicationContext parent)
throws BeansException {
@ -73,21 +69,23 @@ spring-context https://github.com/AmyliaY/spring-context-reading
return new FileSystemResource(path);
}
```
## 看看其父类 AbstractApplicationContext 实现的 refresh() 方法，该方法就是 IoC 容器初始化的入口类
看看其父类 AbstractApplicationContext 实现的 refresh() 方法，该方法就是 IoC 容器初始化的入口类
```java
/**
* 容器初始化的过程：BeanDefinition 的 Resource 定位、BeanDefinition 的载入、BeanDefinition 的注册。
* BeanDefinition 的载入和 bean 的依赖注入是两个独立的过程，依赖注入一般发生在 应用第一次通过 getBean() 方法从容器获取 bean 时。
* BeanDefinition 的载入和 bean 的依赖注入是两个独立的过程，依赖注入一般发生在 应用第一次通过
* getBean() 方法从容器获取 bean 时。
*
* 另外需要注意的是，IoC 容器有一个预实例化的配置（即，将 AbstractBeanDefinition 中的 lazyInit 属性设为 true），使用户可以对容器的初始化
* 过程做一个微小的调控，lazyInit 设为 false 的 bean 将在容器初始化时进行依赖注入，而不会等到 getBean() 方法调用时才进行
* 另外需要注意的是，IoC 容器有一个预实例化的配置（即，将 AbstractBeanDefinition 中的 lazyInit 属性
* 设为 true），使用户可以对容器的初始化过程做一个微小的调控，lazyInit 设为 false 的 bean
* 将在容器初始化时进行依赖注入，而不会等到 getBean() 方法调用时才进行
*/
public void refresh() throws BeansException, IllegalStateException {
synchronized (this.startupShutdownMonitor) {
// 调用容器准备刷新的方法，获取容器的当前时间，同时给容器设置同步标识
// 调用容器准备刷新，获取容器的当前时间，同时给容器设置同步标识
prepareRefresh();
// 告诉子类启动 refreshBeanFactory() 方法，Bean 定义资源文件的载入从子类的 refreshBeanFactory() 方法启动开始
// 告诉子类启动 refreshBeanFactory() 方法，BeanDefinition 资源文件的载入从子类的 refreshBeanFactory() 方法启动开始
ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();
// 为 BeanFactory 配置容器特性，例如类加载器、事件处理器等
@ -135,7 +133,7 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
}
```
## 看看 obtainFreshBeanFactory 方法，该方法告诉了子类去刷新内部的 beanFactory
看看 obtainFreshBeanFactory() 方法，该方法告诉了子类去刷新内部的 beanFactory
```java
/**
* Tell the subclass to refresh the internal bean factory.
@ -144,7 +142,9 @@ spring-context https://github.com/AmyliaY/spring-context-reading
protected ConfigurableListableBeanFactory obtainFreshBeanFactory() {
// 自己定义了抽象的 refreshBeanFactory() 方法，具体实现交给了自己的子类
refreshBeanFactory();
// getBeanFactory() 也是一个抽象方法，委派给子类实现
// getBeanFactory() 也是一个抽象方法，交由子类实现
// 看到这里是不是很容易想起 “模板方法模式”，父类在模板方法中定义好流程，定义好抽象方法
// 具体实现交由子类完成
ConfigurableListableBeanFactory beanFactory = getBeanFactory();
if (logger.isDebugEnabled()) {
logger.debug("Bean factory for " + getDisplayName() + ": " + beanFactory);
@ -152,11 +152,12 @@ spring-context https://github.com/AmyliaY/spring-context-reading
return beanFactory;
}
```
## AbstractRefreshableApplicationContext 中对 refreshBeanFactory() 方法的实现
FileSystemXmlApplicationContext 从上层体系的各抽象类中继承了大量的方法实现，抽象类中抽取大量公共行为进行具体实现，留下 abstract 的个性化方法交给具体的子类实现，这是一个很好的 OOP 编程设计，我们在自己编码时也可以尝试这样设计自己的类图。理清 FileSystemXmlApplicationContext 的上层体系设计，就不易被各种设计模式搞晕咯。
下面看一下 AbstractRefreshableApplicationContext 中对 refreshBeanFactory() 方法的实现。FileSystemXmlApplicationContext 从上层体系的各抽象类中继承了大量的方法实现，抽象类中抽取大量公共行为进行具体实现，留下 abstract 的个性化方法交给具体的子类实现，这是一个很好的 OOP 编程设计，我们在自己编码时也可以尝试这样设计自己的类图。理清 FileSystemXmlApplicationContext 的上层体系设计，就不易被各种设计模式搞晕咯。
```java
// 在这里完成了容器的初始化，并赋值给自己 private 的 beanFactory 属性，为下一步调用做准备
// 从父类 AbstractApplicationContext 继承的抽象方法，自己做了实现
/**
* 在这里完成了容器的初始化，并赋值给自己私有的 beanFactory 属性，为下一步调用做准备
* 从父类 AbstractApplicationContext 继承的抽象方法，自己做了实现
*/
@Override
protected final void refreshBeanFactory() throws BeansException {
// 如果已经建立了 IoC 容器，则销毁并关闭容器
@ -170,7 +171,7 @@ FileSystemXmlApplicationContext 从上层体系的各抽象类中继承了大量
beanFactory.setSerializationId(getId());
// 对 IoC 容器进行定制化，如设置启动参数，开启注解的自动装配等
customizeBeanFactory(beanFactory);
// 载入 BeanDefinition，在当前类中只定义了抽象的 loadBeanDefinitions 方法，具体实现 调用子类容器
// 载入 BeanDefinition，在当前类中只定义了抽象的 loadBeanDefinitions() 方法，具体实现 调用子类容器
loadBeanDefinitions(beanFactory);
synchronized (this.beanFactoryMonitor) {
// 给自己的属性赋值
@ -182,10 +183,10 @@ FileSystemXmlApplicationContext 从上层体系的各抽象类中继承了大量
}
}
```
## AbstractXmlApplicationContext 中对 loadBeanDefinitions(DefaultListableBeanFactory beanFactory) 的实现
AbstractXmlApplicationContext 中对 loadBeanDefinitions(DefaultListableBeanFactory beanFactory) 的实现。
```java
/*
* 实现了爷类 AbstractRefreshableApplicationContext 的抽象方法
* 实现了基类 AbstractRefreshableApplicationContext 的抽象方法
*/
@Override
protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws BeansException, IOException {
@ -199,7 +200,8 @@ FileSystemXmlApplicationContext 从上层体系的各抽象类中继承了大量
// 继承了 DefaultResourceLoader，因此，本容器自身也是一个资源加载器
beanDefinitionReader.setResourceLoader(this);
// 设置 SAX 解析器，SAX（simple API for XML）是另一种 XML 解析方法。相比于 DOM，SAX 速度更快，占用内存更小。
// 它逐行扫描文档，一边扫描一边解析。相比于先将整个 XML 文件扫描近内存，再进行解析的 DOM，SAX 可以在解析文档的任意时刻停止解析，但操作也比 DOM 复杂。
// 它逐行扫描文档，一边扫描一边解析。相比于先将整个 XML 文件扫描近内存，再进行解析的 DOM，SAX 可以在解析文档的
// 任意时刻停止解析，但操作也比 DOM 复杂。
beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this));
// 初始化 beanDefinition 读取器，该方法同时启用了 Xml 的校验机制
@ -208,40 +210,43 @@ FileSystemXmlApplicationContext 从上层体系的各抽象类中继承了大量
loadBeanDefinitions(beanDefinitionReader);
}
```
## 继续看 AbstractXmlApplicationContext 中 loadBeanDefinitions 的重载方法
继续看 AbstractXmlApplicationContext 中 loadBeanDefinitions() 的重载方法。
```java
// 用传进来的 XmlBeanDefinitionReader 读取器加载 Xml 文件中的 BeanDefinition
/**
* 用传进来的 XmlBeanDefinitionReader 读取器加载 Xml 文件中的 BeanDefinition
*/
protected void loadBeanDefinitions(XmlBeanDefinitionReader reader) throws BeansException, IOException {
/**
* ClassPathXmlApplicationContext 与 FileSystemXmlApplicationContext
* 在这里的调用出现分歧，各自按不同的方式加载解析 Resource 资源
* 最后在具体的解析和 BeanDefinition 定位上又会殊途同归
* ClassPathXmlApplicationContext 与 FileSystemXmlApplicationContext 在这里的调用出现分歧，
* 各自按不同的方式加载解析 Resource 资源，最后在具体的解析和 BeanDefinition 定位上又会殊途同归。
*/
// 获取存放了 BeanDefinition 的所有 Resource，
// FileSystemXmlApplicationContext 类未对 getConfigResources() 进行重新，
// 所以调用父类的，return null。
// 获取存放了 BeanDefinition 的所有 Resource，FileSystemXmlApplicationContext 类未对
// getConfigResources() 进行重写，所以调用父类的，return null。
// 而 ClassPathXmlApplicationContext 对该方法进行了重写，返回设置的值
Resource[] configResources = getConfigResources();
if (configResources != null) {
// Xml Bean 读取器调用其父类 AbstractBeanDefinitionReader 读取定位的 Bean 定义资源
// XmlBeanDefinitionReader 调用其父类 AbstractBeanDefinitionReader 的方法加载 BeanDefinition
reader.loadBeanDefinitions(configResources);
}
// 调用父类 AbstractRefreshableConfigApplicationContext 实现的返回值为 String[] 的 getConfigLocations() 方法，
// 调用父类 AbstractRefreshableConfigApplicationContext 的实现，
// 优先返回 FileSystemXmlApplicationContext 构造方法中调用 setConfigLocations() 方法设置的资源
String[] configLocations = getConfigLocations();
if (configLocations != null) {
// XmlBeanDefinitionReader 读取器调用其父类 AbstractBeanDefinitionReader 的方法从配置位置加载 BeanDefinition
// XmlBeanDefinitionReader 调用其父类 AbstractBeanDefinitionReader 的方法从配置位置加载 BeanDefinition
reader.loadBeanDefinitions(configLocations);
}
}
```
## AbstractBeanDefinitionReader 中对 loadBeanDefinitions 方法的各种重载及调用
AbstractBeanDefinitionReader 中对 loadBeanDefinitions 方法的各种重载及调用。
```java
// loadBeanDefinitions() 方法的重载方法之一，调用了另一个重载方法 loadBeanDefinitions(String)
/**
* loadBeanDefinitions() 方法的重载方法之一，调用了另一个重载方法 loadBeanDefinitions(String)
*/
public int loadBeanDefinitions(String... locations) throws BeanDefinitionStoreException {
Assert.notNull(locations, "Location array must not be null");
// 计数 加载了多少个配置文件
// 计数器，统计加载了多少个配置文件
int counter = 0;
for (String location : locations) {
counter += loadBeanDefinitions(location);
@ -249,12 +254,16 @@ FileSystemXmlApplicationContext 从上层体系的各抽象类中继承了大量
return counter;
}
// 重载方法之一，调用了下面的 loadBeanDefinitions(String, Set<Resource>) 方法
/**
* 重载方法之一，调用了下面的 loadBeanDefinitions(String, Set<Resource>) 方法
*/
public int loadBeanDefinitions(String location) throws BeanDefinitionStoreException {
return loadBeanDefinitions(location, null);
}
// 获取在 IoC 容器初始化过程中设置的资源加载器
/**
* 获取在 IoC 容器初始化过程中设置的资源加载器
*/
public int loadBeanDefinitions(String location, Set<Resource> actualResources) throws BeanDefinitionStoreException {
// 在实例化 XmlBeanDefinitionReader 后 IoC 容器将自己注入进该读取器作为 resourceLoader 属性
ResourceLoader resourceLoader = getResourceLoader();
@ -295,9 +304,9 @@ FileSystemXmlApplicationContext 从上层体系的各抽象类中继承了大量
*/
Resource resource = resourceLoader.getResource(location);
// 从 resource 中加载 BeanDefinition，loadCount 为加载的 BeanDefinition 个数
// 该 loadBeanDefinitions() 方法来自其 implements 的 BeanDefinitionReader 接口，
// 该 loadBeanDefinitions() 方法来自其实现的 BeanDefinitionReader 接口，
// 且本类是一个抽象类，并未对该方法进行实现。而是交由子类进行实现，如果是用 xml 文件进行
// IoC 容器初始化的，则调用 XmlBeanDefinitionReader 中的实现
// IoC 容器的初始化，则调用 XmlBeanDefinitionReader 中的实现
int loadCount = loadBeanDefinitions(resource);
if (actualResources != null) {
actualResources.add(resource);
@ -309,9 +318,11 @@ FileSystemXmlApplicationContext 从上层体系的各抽象类中继承了大量
}
}
```
## resourceLoader 的 getResource() 方法有多种实现，看清 FileSystemXmlApplicationContext 的继承体系就可以明确，其走的是 DefaultResourceLoader 中的实现
resourceLoader 的 getResource() 方法有多种实现，看清 FileSystemXmlApplicationContext 的继承体系就可以明确，其走的是 DefaultResourceLoader 中的实现。
```java
// 获取 Resource 的具体实现方法
/**
* 获取 Resource 的具体实现方法
*/
public Resource getResource(String location) {
Assert.notNull(location, "Location must not be null");
// 如果 location 是类路径的方式，返回 ClassPathResource 类型的文件资源对象
@ -326,20 +337,19 @@ FileSystemXmlApplicationContext 从上层体系的各抽象类中继承了大量
return new UrlResource(url);
}
catch (MalformedURLException ex) {
// 如果既不是 classpath 标识，又不是 URL 标识的 Resource 定位，则调用
// 容器本身的 getResourceByPath 方法获取 Resource
// 根据实例化的子类对象，调用其子类对象中重写的此方法，
// 如 FileSystemXmlApplicationContext 子类中对此方法的重新
// 如果既不是 classpath 标识，又不是 URL 标识的 Resource 定位，则调用容器本身的
// getResourceByPath() 方法获取 Resource。根据实例化的子类对象，调用其子类对象中
// 重写的此方法，如 FileSystemXmlApplicationContext 子类中对此方法的重写
return getResourceByPath(location);
}
}
}
```
## 其中的 getResourceByPath(location) 方法的实现则是在 FileSystemXmlApplicationContext 中完成的
其中的 getResourceByPath(location) 方法的实现则是在 FileSystemXmlApplicationContext 中完成的。
```java
/**
* 实例化一个 FileSystemResource 并返回，以便后续对资源的 IO 操作
* 本方法是在 DefaultResourceLoader 的 getResource 方法中被调用的，
* 本方法是在 DefaultResourceLoader 的 getResource() 方法中被调用的，
*/
@Override
protected Resource getResourceByPath(String path) {

322
docs/Spring/IoC/2、将bean解析封装成BeanDefinition.md
Unescape View File

@ -1,16 +1,18 @@
接着上一篇的 BeanDefinition 资源定位开始讲。Spring IoC 容器 BeanDefinition 解析过程就是把用户在配置文件中定义好的 bean，解析并封装成容器可以装载的 BeanDefinition，BeanDefinition 是 spring 定义的基本数据结构，也是为了方便对 bean 进行管理和操作。
（PS：可以结合我 GitHub 上对 spring 框架源码的阅读及个人理解一起看，会更有助于各位开发大佬理解。
## 前言
接着上一篇的 BeanDefinition 资源定位开始讲。Spring IoC 容器 BeanDefinition 解析过程就是把用户在配置文件中配置的 bean，解析并封装成 IoC 容器可以装载的 BeanDefinition 对象，BeanDefinition 是 Spring 定义的基本数据结构，其中的属性与配置文件中 bean 的属性相对应。
（PS：可以结合我 GitHub 上对 Spring 框架源码的阅读及个人理解一起看，会更有助于各位开发大佬理解。地址如下。
spring-beans https://github.com/AmyliaY/spring-beans-reading
spring-context https://github.com/AmyliaY/spring-context-reading ）
spring-context https://github.com/AmyliaY/spring-context-reading
）
## 1、先看一下 AbstractRefreshableApplicationContext 中 refreshBeanFactory() 方法的 loadBeanDefinitions(beanFactory)
## 正文
首先看一下 AbstractRefreshableApplicationContext 的 refreshBeanFactory() 方法，这是一个模板方法，其中调用的 loadBeanDefinitions() 方法是一个抽象方法，交由子类实现。
```java
// 在这里完成了容器的初始化，并赋值给自己 private 的 beanFactory 属性，为下一步调用做准备
// 从父类 AbstractApplicationContext 继承的抽象方法，自己做了实现
/**
* 在这里完成了容器的初始化，并赋值给自己私有的 beanFactory 属性，为下一步调用做准备
* 从父类 AbstractApplicationContext 继承的抽象方法，自己做了实现
*/
@Override
protected final void refreshBeanFactory() throws BeansException {
// 如果已经建立了 IoC 容器，则销毁并关闭容器
@ -19,12 +21,12 @@ spring-context https://github.com/AmyliaY/spring-context-reading
closeBeanFactory();
}
try {
// 创建 IoC 容器，DefaultListableBeanFactory 类实现了 ConfigurableListableBeanFactory 接口
// 创建 IoC 容器，DefaultListableBeanFactory 实现了 ConfigurableListableBeanFactory 接口
DefaultListableBeanFactory beanFactory = createBeanFactory();
beanFactory.setSerializationId(getId());
// 对 IoC 容器进行定制化，如设置启动参数，开启注解的自动装配等
customizeBeanFactory(beanFactory);
// 载入 BeanDefinition，当前类中只定义了抽象的 loadBeanDefinitions 方法，具体的实现调用子类容器
// 载入 BeanDefinition，当前类中只定义了抽象的 loadBeanDefinitions() 方法，具体的实现调用子类容器
loadBeanDefinitions(beanFactory);
synchronized (this.beanFactoryMonitor) {
// 给自己的属性赋值
@ -36,65 +38,67 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
}
```
## 2、实现类 AbstractXmlApplicationContext 中的 loadBeanDefinitions(DefaultListableBeanFactory beanFactory)
下面看一下 AbstractRefreshableApplicationContext 的子类 AbstractXmlApplicationContext 对 loadBeanDefinitions() 方法的实现。
```java
/*
* 实现了爷类 AbstractRefreshableApplicationContext 的抽象方法
*/
@Override
protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws BeansException, IOException {
// DefaultListableBeanFactory 实现了 BeanDefinitionRegistry 接口，在初始化 XmlBeanDefinitionReader 时
// 将 BeanDefinition 注册器注入该 BeanDefinition 读取器
// 创建 用于从 Xml 中读取 BeanDefinition 的读取器，并通过回调设置到 IoC 容器中去，容器使用该读取器读取 BeanDefinition 资源
// DefaultListableBeanFactory 实现了 BeanDefinitionRegistry 接口，所以在初始化 XmlBeanDefinitionReader 时
// 将该 beanFactory 传入 XmlBeanDefinitionReader 的构造方法中。
// 从名字也能看出来它的功能，这是一个用于从 .xml文件 中读取 BeanDefinition 的读取器
XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReader(beanFactory);
beanDefinitionReader.setEnvironment(this.getEnvironment());
// 为 beanDefinition 读取器设置 资源加载器，由于本类的太爷爷类 AbstractApplicationContext
// 为 beanDefinition 读取器设置 资源加载器，由于本类的基类 AbstractApplicationContext
// 继承了 DefaultResourceLoader，因此，本容器自身也是一个资源加载器
beanDefinitionReader.setResourceLoader(this);
// 设置 SAX 解析器，SAX（simple API for XML）是另一种 XML 解析方法。相比于 DOM，SAX 速度更快，占用内存更小。
// 它逐行扫描文档，一边扫描一边解析。相比于先将整个 XML 文件扫描近内存，再进行解析的 DOM，SAX 可以在解析文档的任意时刻停止解析，但操作也比 DOM 复杂。
// 为 beanDefinitionReader 设置用于解析的 SAX 实例解析器，SAX（simple API for XML）是另一种XML解析方法。
// 相比于DOM，SAX速度更快，占用内存更小。它逐行扫描文档，一边扫描一边解析。相比于先将整个XML文件扫描进内存，
// 再进行解析的DOM，SAX可以在解析文档的任意时刻停止解析，但操作也比DOM复杂。
beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this));
// 初始化 beanDefinition 读取器，该方法同时启用了 Xml 的校验机制
// 初始化 beanDefinition 读取器，该方法同时启用了 XML 的校验机制
initBeanDefinitionReader(beanDefinitionReader);
// Bean 读取器真正实现加载的方法
// 用传进来的 XmlBeanDefinitionReader 读取器读取 .xml 文件中配置的 bean
loadBeanDefinitions(beanDefinitionReader);
}
```
## 3、loadBeanDefinitions(XmlBeanDefinitionReader reader)
接着看一下上面最后一个调用的方法 loadBeanDefinitions(XmlBeanDefinitionReader reader)。
```java
// 用传进来的 XmlBeanDefinitionReader 读取器加载 Xml 文件中的 BeanDefinition
/**
* 读取并解析 .xml 文件中配置的 bean，然后封装成 BeanDefinition 对象
*/
protected void loadBeanDefinitions(XmlBeanDefinitionReader reader) throws BeansException, IOException {
/**
* ClassPathXmlApplicationContext 与 FileSystemXmlApplicationContext
* 在这里的调用出现分歧，各自按不同的方式加载解析 Resource 资源
* 最后在具体的解析和 BeanDefinition 定位上又会殊途同归
*/
// 获取存放了 BeanDefinition 的所有 Resource，
// FileSystemXmlApplicationContext 类未对 getConfigResources() 进行重新，
// 所以调用父类的，return null。
// 获取存放了 BeanDefinition 的所有 Resource，FileSystemXmlApplicationContext 中未对
// getConfigResources() 进行重写，所以调用父类的，return null。
// 而 ClassPathXmlApplicationContext 对该方法进行了重写，返回设置的值
Resource[] configResources = getConfigResources();
if (configResources != null) {
// Xml Bean 读取器调用其父类 AbstractBeanDefinitionReader 读取定位的 Bean 定义资源
// 这里调用的是其父类 AbstractBeanDefinitionReader 中的方法，解析加载 BeanDefinition对象
reader.loadBeanDefinitions(configResources);
}
// 调用父类 AbstractRefreshableConfigApplicationContext 实现的返回值为 String[] 的 getConfigLocations() 方法，
// 优先返回 FileSystemXmlApplicationContext 构造方法中调用 setConfigLocations() 方法设置的资源
// 调用其父类 AbstractRefreshableConfigApplicationContext 中的实现，优先返回
// FileSystemXmlApplicationContext 构造方法中调用 setConfigLocations() 方法设置的资源路径
String[] configLocations = getConfigLocations();
if (configLocations != null) {
// XmlBeanDefinitionReader 读取器调用其父类 AbstractBeanDefinitionReader 的方法从配置位置加载 BeanDefinition
// 这里调用其父类 AbstractBeanDefinitionReader 的方法从配置位置加载 BeanDefinition
reader.loadBeanDefinitions(configLocations);
}
}
```
## 4、AbstractBeanDefinitionReader 对 loadBeanDefinitions() 方法的三重重载
AbstractBeanDefinitionReader 对 loadBeanDefinitions() 方法的三重重载。
```java
// loadBeanDefinitions() 方法的重载方法之一，调用了另一个重载方法 loadBeanDefinitions(String)
/**
* loadBeanDefinitions() 方法的重载方法之一，调用了另一个重载方法 loadBeanDefinitions(String location)
*/
public int loadBeanDefinitions(String... locations) throws BeanDefinitionStoreException {
Assert.notNull(locations, "Location array must not be null");
// 计数 加载了多少个配置文件
// 计数器，统计加载了多少个配置文件
int counter = 0;
for (String location : locations) {
counter += loadBeanDefinitions(location);
@ -102,14 +106,18 @@ spring-context https://github.com/AmyliaY/spring-context-reading
return counter;
}
// 重载方法之一，调用了下面的 loadBeanDefinitions(String, Set<Resource>) 方法
/**
* 重载方法之一，调用了下面的 loadBeanDefinitions(String location, Set<Resource> actualResources) 方法
*/
public int loadBeanDefinitions(String location) throws BeanDefinitionStoreException {
return loadBeanDefinitions(location, null);
}
// 获取在 IoC 容器初始化过程中设置的资源加载器
/**
* 获取在 IoC 容器初始化过程中设置的资源加载器
*/
public int loadBeanDefinitions(String location, Set<Resource> actualResources) throws BeanDefinitionStoreException {
// 在实例化 XmlBeanDefinitionReader 后 IoC 容器将自己注入进该读取器作为 resourceLoader 属性
// 在实例化 XmlBeanDefinitionReader 时 曾将 IoC 容器注入该对象，作为 resourceLoader 属性
ResourceLoader resourceLoader = getResourceLoader();
if (resourceLoader == null) {
throw new BeanDefinitionStoreException(
@ -118,10 +126,10 @@ spring-context https://github.com/AmyliaY/spring-context-reading
if (resourceLoader instanceof ResourcePatternResolver) {
try {
// 将指定位置的 BeanDefinition 资源文件解析为 IoC 容器封装的资源
// 加载多个指定位置的 BeanDefinition 资源文件
// 将指定位置的 bean 配置文件解析为 BeanDefinition 对象
// 加载多个指定位置的 BeanDefinition 资源
Resource[] resources = ((ResourcePatternResolver) resourceLoader).getResources(location);
// 委派调用其子类 XmlBeanDefinitionReader 的方法，实现加载功能
// 调用其子类 XmlBeanDefinitionReader 的方法，实现加载功能
int loadCount = loadBeanDefinitions(resources);
if (actualResources != null) {
for (Resource resource : resources) {
@ -142,7 +150,7 @@ spring-context https://github.com/AmyliaY/spring-context-reading
/**
* ！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！
* AbstractApplicationContext 继承了 DefaultResourceLoader，所以 AbstractApplicationContext
* 及其子类都会调用 DefaultResourceLoader 中的实现，将指定位置的资源文件解析为 Resource，
* 及其子类都可以调用 DefaultResourceLoader 中的方法，将指定位置的资源文件解析为 Resource，
* 至此完成了对 BeanDefinition 的资源定位
* ！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！
*/
@ -162,16 +170,20 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
}
```
## 5、XmlBeanDefinitionReader 读取器中的方法执行流，按代码的先后顺序
XmlBeanDefinitionReader 读取器中的方法执行流，按代码的先后顺序。
```java
// XmlBeanDefinitionReader 加载资源的入口方法
/**
* XmlBeanDefinitionReader 加载资源的入口方法
*/
public int loadBeanDefinitions(Resource resource) throws BeanDefinitionStoreException {
// 调用本类的重载方法，通过 new EncodedResource(resource) 获得的
// EncodedResource 对象能够将资源与读取资源所需的编码组合在一起
// 调用本类的重载方法，通过 new EncodedResource(resource) 获得的 EncodedResource 对象
// 能够将资源与读取资源所需的编码组合在一起
return loadBeanDefinitions(new EncodedResource(resource));
}
// 通过 encodedResource 进行资源解析，encodedResource 对象持有 resource 对象和 encoding 编码格式
/**
* 通过 encodedResource 进行资源解析，encodedResource 对象持有 resource 对象和 encoding 编码格式
*/
public int loadBeanDefinitions(EncodedResource encodedResource) throws BeanDefinitionStoreException {
Assert.notNull(encodedResource, "EncodedResource must not be null");
if (logger.isInfoEnabled()) {
@ -201,7 +213,7 @@ spring-context https://github.com/AmyliaY/spring-context-reading
return doLoadBeanDefinitions(inputSource, encodedResource.getResource());
}
finally {
// 关闭从 Resource 中得到的 IO 流
// 关闭 IO 流
inputStream.close();
}
}
@ -217,7 +229,9 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
}
// 从指定 XML 文件中实际载入 BeanDefinition 资源的方法
/**
* 从指定 XML 文件中解析 bean，封装成 BeanDefinition 对象的具体实现
*/
protected int doLoadBeanDefinitions(InputSource inputSource, Resource resource)
throws BeanDefinitionStoreException {
try {
@ -253,21 +267,23 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
}
// 按照 Spring 的 Bean 语义要求将 BeanDefinition 资源解析并转换为容器内部数据结构
/**
* 按照 Spring 对配置文件中 bean 元素的语义定义，将 bean 元素 解析成 BeanDefinition 对象
*/
public int registerBeanDefinitions(Document doc, Resource resource) throws BeanDefinitionStoreException {
// 得到 BeanDefinitionDocumentReader 来对 xml 格式的 BeanDefinition 解析
// 得到 BeanDefinitionDocumentReader，将 xml 中配置的 bean 解析成 BeanDefinition 对象
// BeanDefinitionDocumentReader 只是个接口，这里实际上是一个 DefaultBeanDefinitionDocumentReader 对象
BeanDefinitionDocumentReader documentReader = createBeanDefinitionDocumentReader();
documentReader.setEnvironment(this.getEnvironment());
// 获得容器中注册的 Bean 数量
// 获得容器中注册的 bean 数量
int countBefore = getRegistry().getBeanDefinitionCount();
// 解析过程入口，这里使用了委派模式，BeanDefinitionDocumentReader 只是个接口，
// 具体的解析实现过程由实现类 DefaultBeanDefinitionDocumentReader 完成
// 解析过程入口
documentReader.registerBeanDefinitions(doc, createReaderContext(resource));
// 统计解析的 Bean 数量
return getRegistry().getBeanDefinitionCount() - countBefore;
}
```
## 6、文档解析器 DefaultBeanDefinitionDocumentReader 对配置文件中元素的解析
文档解析器 DefaultBeanDefinitionDocumentReader 对配置文件中元素的解析。
```java
// 根据 Spring 对 Bean 的定义规则进行解析
public void registerBeanDefinitions(Document doc, XmlReaderContext readerContext) {
@ -282,7 +298,6 @@ spring-context https://github.com/AmyliaY/spring-context-reading
/**
* Register each bean definition within the given root {@code <beans/>} element.
* 依次注册 BeanDefinition，使用给定的根元素
*/
protected void doRegisterBeanDefinitions(Element root) {
@ -297,26 +312,28 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
// 具体的解析过程由 BeanDefinitionParserDelegate 实现，
// BeanDefinitionParserDelegate 中定义了 Spring Bean 定义 XML 文件的各种元素
// BeanDefinitionParserDelegate中定义了用于解析 bean 的各种属性及方法
BeanDefinitionParserDelegate parent = this.delegate;
this.delegate = createDelegate(this.readerContext, root, parent);
// 在解析 BeanDefinition 之前，进行自定义的解析，增强解析过程的可扩展性
// 前置解析处理，可以在解析 bean 之前进行自定义的解析，增强解析的可扩展性
preProcessXml(root);
// 从 Document 的根元素开始进行 Bean 定义的 Document 对象
parseBeanDefinitions(root, this.delegate);
// 在解析 Bean 定义之后，进行自定义的解析，增加解析过程的可扩展性
// 后置解析处理，可以在解析 bean 之后进行自定义的解析，增加解析的可扩展性
postProcessXml(root);
this.delegate = parent;
}
// 使用 Spring 的 Bean 规则从 Document 的根元素开始进行 Bean Definition 的解析
/**
* 根据 Spring 的 bean解析规则，从 Document 的根元素开始进行解析
*/
protected void parseBeanDefinitions(Element root, BeanDefinitionParserDelegate delegate) {
// Bean 定义的 Document 对象是否使用了 Spring 默认的 XML 命名空间
// 根节点 root 是否使用了 Spring 默认的 XML 命名空间
if (delegate.isDefaultNamespace(root)) {
// 获取 root 根元素的所有子节点
// 获取根元素的所有子节点
NodeList nl = root.getChildNodes();
for (int i = 0; i < nl.getLength(); i++) {
Node node = nl.item(i);
@ -324,47 +341,49 @@ spring-context https://github.com/AmyliaY/spring-context-reading
Element ele = (Element) node;
// 如果 ele 定义的 Document 的元素节点使用的是 Spring 默认的 XML 命名空间
if (delegate.isDefaultNamespace(ele)) {
// 使用 Spring 的 Bean 规则解析元素节点
// 使用 Spring 的 bean解析规则 解析元素节点
parseDefaultElement(ele, delegate);
}
else {
// 没有使用 Spring 默认的 XML 命名空间，则使用用户自定义的解
// 析规则解析元素节点
// 若没有使用 Spring 默认的 XML 命名空间，则使用用户自定义的解析规则解析元素节点
delegate.parseCustomElement(ele);
}
}
}
}
else {
// Document 的根节点没有使用 Spring 默认的命名空间，则使用用户自定义的
// 解析规则解析 Document 根节点
// 若 Document 的根节点没有使用 Spring 默认的命名空间，则使用用户自定义的解析规则
// 解析 Document 根节点
delegate.parseCustomElement(root);
}
}
// 使用 Spring 的 Bean 规则解析 Document 元素节点
/**
* 使用 Spring 的 bean解析规则 解析 Spring元素节点
*/
private void parseDefaultElement(Element ele, BeanDefinitionParserDelegate delegate) {
// 如果元素节点是 <Import> 导入元素，进行导入解析
// 解析 <Import> 元素
if (delegate.nodeNameEquals(ele, IMPORT_ELEMENT)) {
importBeanDefinitionResource(ele);
}
// 如果元素节点是 <Alias> 别名元素，进行别名解析
// 解析 <Alias> 元素
else if (delegate.nodeNameEquals(ele, ALIAS_ELEMENT)) {
processAliasRegistration(ele);
}
// 元素节点既不是导入元素，也不是别名元素，即普通的 <Bean> 元素，
// 按照 Spring 的 Bean 规则解析元素
// 若元素节点既不是 <Import> 也不是 <Alias>，即普通的 <Bean> 元素，
// 则按照 Spring 的 bean解析规则 解析元素
else if (delegate.nodeNameEquals(ele, BEAN_ELEMENT)) {
processBeanDefinition(ele, delegate);
}
// 如果被解析的元素是 beans，则递归调用 doRegisterBeanDefinitions(Element root) 方法
// 如果被解析的元素是 beans，则递归调用 doRegisterBeanDefinitions(Element root) 方法进行解析
else if (delegate.nodeNameEquals(ele, NESTED_BEANS_ELEMENT)) {
doRegisterBeanDefinitions(ele);
}
}
// 解析 <Import> 导入元素，从给定的导入路径加载 Bean 定义资源到 Spring IoC 容器中
/**
* 解析 <import> 元素
*/
protected void importBeanDefinitionResource(Element ele) {
// 获取给定的导入元素的 location 属性
String location = ele.getAttribute(RESOURCE_ATTRIBUTE);
@ -379,19 +398,17 @@ spring-context https://github.com/AmyliaY/spring-context-reading
Set<Resource> actualResources = new LinkedHashSet<Resource>(4);
// 标识给定的导入元素的 location 是否是绝对路径
// 标识给定的 <Import> 元素的 location 是否是绝对路径
boolean absoluteLocation = false;
try {
absoluteLocation = ResourcePatternUtils.isUrl(location) || ResourceUtils.toURI(location).isAbsolute();
}
catch (URISyntaxException ex) {
// 给定的导入元素的 location 不是绝对路径
}
// 给定的导入元素的 location 是绝对路径
if (absoluteLocation) {
try {
// 使用资源读入器加载给定路径的 Bean 定义资源
// 使用资源读取器加载给定路径的 bean
int importCount = getReaderContext().getReader().loadBeanDefinitions(location, actualResources);
if (logger.isDebugEnabled()) {
logger.debug("Imported " + importCount + " bean definitions from URL location [" + location + "]");
@ -403,22 +420,22 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
}
else {
// 给定的导入元素的 location 是相对路径
// 给定的 <import> 元素的 location 是相对路径
try {
int importCount;
// 将给定导入元素的 location 封装为相对路径资源
// 将给定 <import> 元素的 location 封装为相对路径资源
Resource relativeResource = getReaderContext().getResource().createRelative(location);
// 封装的相对路径资源存在
if (relativeResource.exists()) {
// 使用资源读入器加载 Bean 定义资源
// 使用资源读取器加载 bean
importCount = getReaderContext().getReader().loadBeanDefinitions(relativeResource);
actualResources.add(relativeResource);
}
// 封装的相对路径资源不存在
else {
// 获取 Spring IOC 容器资源读入器的基本路径
// 获取 Spring IOC 容器资源读取器的基本路径
String baseLocation = getReaderContext().getResource().getURL().toString();
// 根据 Spring IoC 容器资源读入器的基本路径加载给定导入路径的资源
// 根据 Spring IoC 容器资源读取器的基本路径加载给定导入路径的资源
importCount = getReaderContext().getReader().loadBeanDefinitions(
StringUtils.applyRelativePath(baseLocation, location), actualResources);
}
@ -440,45 +457,44 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
/**
* Process the given alias element, registering the alias with the registry.
* 解析 <Alias> 元素
*/
// 解析 <Alias> 别名元素，为 Bean 向 Spring IoC 容器注册别名
protected void processAliasRegistration(Element ele) {
// 获取 <Alias> 别名元素中 name 的属性值
// 获取 <Alias> 元素中的 name 属性值
String name = ele.getAttribute(NAME_ATTRIBUTE);
// 获取 <Alias> 别名元素中 alias 的属性值
// 获取 <Alias> 元素中的 alias 属性值
String alias = ele.getAttribute(ALIAS_ATTRIBUTE);
boolean valid = true;
// <alias> 别名元素的 name 属性值为空
// 若 <alias> 元素的 name 属性值为空
if (!StringUtils.hasText(name)) {
getReaderContext().error("Name must not be empty", ele);
valid = false;
}
// <alias> 别名元素的 alias 属性值为空
// 若 <alias> 元素的 alias 属性值为空
if (!StringUtils.hasText(alias)) {
getReaderContext().error("Alias must not be empty", ele);
valid = false;
}
if (valid) {
try {
// 向容器的资源读入器注册别名
// 向容器的资源读取器 注册别名
getReaderContext().getRegistry().registerAlias(name, alias);
}
catch (Exception ex) {
getReaderContext().error("Failed to register alias '" + alias +
"' for bean with name '" + name + "'", ele, ex);
}
// 在解析完 <Alias> 元素之后，发送容器别名处理完成事件
// 在解析完 <Alias> 元素之后，向容器发送别名处理完成事件
getReaderContext().fireAliasRegistered(name, alias, extractSource(ele));
}
}
// 解析 Bean 定义资源 Document 对象的普通元素
/**
* 解析 bean 元素
protected void processBeanDefinition(Element ele, BeanDefinitionParserDelegate delegate) {
// BeanDefinitionHolder 是对 BeanDefinition 的封装，即 BeanDefinition 的封装类
// 对 Document 对象中 <Bean> 元素的解析由 BeanDefinitionParserDelegate 实现
// BeanDefinitionHolder 是对 BeanDefinition 的进一步封装，持有一个 BeanDefinition 对象 及其对应
// 的 beanName、aliases别名。对 <Bean> 元素的解析由 BeanDefinitionParserDelegate 实现
BeanDefinitionHolder bdHolder = delegate.parseBeanDefinitionElement(ele);
if (bdHolder != null) {
// 对 bdHolder 进行包装处理
@ -486,7 +502,7 @@ spring-context https://github.com/AmyliaY/spring-context-reading
try {
/**
* ！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！
* 向 Spring IoC 容器注册解析 BeanDefinition，这是 BeanDefinition 向 IoC 容器注册的入口
* 向 Spring IoC 容器注册解析完成的 BeanDefinition对象，这是 BeanDefinition 向 IoC 容器注册的入口
* ！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！
*/
BeanDefinitionReaderUtils.registerBeanDefinition(bdHolder, getReaderContext().getRegistry());
@ -495,37 +511,41 @@ spring-context https://github.com/AmyliaY/spring-context-reading
getReaderContext().error("Failed to register bean definition with name '" +
bdHolder.getBeanName() + "'", ele, ex);
}
// 在完成向 Spring IOC 容器注册解析得到的 Bean 定义之后，发送注册事件
// 在完成向 Spring IOC 容器注册 BeanDefinition对象 之后，发送注册事件
getReaderContext().fireComponentRegistered(new BeanComponentDefinition(bdHolder));
}
}
```
## 7、看一下 BeanDefinitionParserDelegate 中对 bean 元素的详细解析过程
看一下 BeanDefinitionParserDelegate 中对 bean 元素的详细解析过程。
```java
// 解析 <Bean> 元素的入口
/**
* 解析 <bean> 元素的入口
*/
public BeanDefinitionHolder parseBeanDefinitionElement(Element ele) {
return parseBeanDefinitionElement(ele, null);
}
// 解析 BeanDefinition 资源文件中的 <Bean> 元素，这个方法中主要处理 <Bean> 元素的 id，name 和别名属性
/**
* 解析 <bean> 元素，这个方法中主要处理 <bean> 元素的 id、name 和 alias 属性
*/
public BeanDefinitionHolder parseBeanDefinitionElement(Element ele, BeanDefinition containingBean) {
// 获取 <Bean> 元素中的 id 属性值
// 获取 <bean> 元素中的 id 属性值
String id = ele.getAttribute(ID_ATTRIBUTE);
// 获取 <Bean> 元素中的 name 属性值
// 获取 <bean> 元素中的 name 属性值
String nameAttr = ele.getAttribute(NAME_ATTRIBUTE);
// 获取 <Bean> 元素中的 alias 属性值
// 获取 <bean> 元素中的 alias 属性值
List<String> aliases = new ArrayList<String>();
// 将 <Bean> 元素中的所有 name 属性值存放到别名中
// 将 <bean> 元素中的所有 name 属性值存放到别名中
if (StringUtils.hasLength(nameAttr)) {
String[] nameArr = StringUtils.tokenizeToStringArray(nameAttr, MULTI_VALUE_ATTRIBUTE_DELIMITERS);
aliases.addAll(Arrays.asList(nameArr));
}
String beanName = id;
// 如果 <Bean> 元素中没有配置 id 属性时，将别名中的第一个值赋值给 beanName
// 如果 <bean> 元素中没有配置 id 属性，则将 别名alias 中的第一个值赋值给 beanName
if (!StringUtils.hasText(beanName) && !aliases.isEmpty()) {
beanName = aliases.remove(0);
if (logger.isDebugEnabled()) {
@ -534,30 +554,27 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
}
// 检查 <Bean> 元素所配置的 id 或者 name 的唯一性，containingBean 标识 <Bean>
// 元素中是否包含子 <Bean> 元素
// 检查 <bean> 元素所配置的 id 或者 name 的唯一性
// 元素中是否包含子 <bean> 元素
if (containingBean == null) {
// 检查 <Bean> 元素所配置的 id、name 或者别名是否重复
// 检查 <bean> 元素所配置的 id、name 或者 别名alias 是否重复
checkNameUniqueness(beanName, aliases, ele);
}
// 详细对 <Bean> 元素中配置的 Bean 定义进行解析的地方
// 将 <bean> 元素解析成 BeanDefinition对象
AbstractBeanDefinition beanDefinition = parseBeanDefinitionElement(ele, beanName, containingBean);
if (beanDefinition != null) {
if (!StringUtils.hasText(beanName)) {
try {
// 如果 <bean> 元素中没有配置 id、name 或者 alias，且没有包含子元素
if (containingBean != null) {
// 如果 <Bean> 元素中没有配置 id、别名或者 name，且没有包含子元素
// <Bean> 元素，为解析的 Bean 生成一个唯一 beanName 并注册
// 为解析的 BeanDefinition 生成一个唯一的 beanName
beanName = BeanDefinitionReaderUtils.generateBeanName(
beanDefinition, this.readerContext.getRegistry(), true);
}
else {
// 如果 <Bean> 元素中没有配置 id、别名或者 name，且包含了子元素
// <Bean> 元素，为解析的 Bean 使用别名向 IOC 容器注册
beanName = this.readerContext.generateBeanName(beanDefinition);
// 为解析的 Bean 使用别名注册时，为了向后兼容
// Spring1.2/2.0，给别名添加类名后缀
// 在别名集合 aliases 中添加 bean 的类名
String beanClassName = beanDefinition.getBeanClassName();
if (beanClassName != null &&
beanName.startsWith(beanClassName) && beanName.length() > beanClassName.length() &&
@ -582,16 +599,17 @@ spring-context https://github.com/AmyliaY/spring-context-reading
return null;
}
// 详细对 <Bean> 元素中配置的 Bean 定义其他属性进行解析，由于上面的方法中已经对
// Bean 的 id、name 和别名等属性进行了处理，该方法中主要处理除这三个以外的其他属性数据
/**
* 详细对 <bean> 元素中的其他属性进行解析，上面的方法中已经对 bean 的 id、name 及 alias 属性进行了处理
*/
public AbstractBeanDefinition parseBeanDefinitionElement(
Element ele, String beanName, BeanDefinition containingBean) {
// 记录解析的 <Bean>
// 记录解析的 <bean>
this.parseState.push(new BeanEntry(beanName));
// 这里只读取 <Bean> 元素中配置的 class 名字，然后载入到 BeanDefinition 中去
// 只是记录配置的 class 名字，不做实例化，对象的实例化在依赖注入时完成
// 这里只读取 <bean> 元素中配置的 class 名字，然后载入到 BeanDefinition 中去
// 只是记录配置的 class 名字，不做实例化，对象的实例化在 getBean() 时发生
String className = null;
if (ele.hasAttribute(CLASS_ATTRIBUTE)) {
className = ele.getAttribute(CLASS_ATTRIBUTE).trim();
@ -599,35 +617,34 @@ spring-context https://github.com/AmyliaY/spring-context-reading
try {
String parent = null;
// 如果 <Bean> 元素中配置了 parent 属性，则获取 parent 属性的值
// 如果 <bean> 元素中配置了 parent 属性，则获取 parent 属性的值
if (ele.hasAttribute(PARENT_ATTRIBUTE)) {
parent = ele.getAttribute(PARENT_ATTRIBUTE);
}
// 根据 <Bean> 元素配置的 class 名称和 parent 属性值创建 BeanDefinition
// 为载入 Bean 定义信息做准备
// 根据 <bean> 元素配置的 class 名称和 parent 属性值创建 BeanDefinition
AbstractBeanDefinition bd = createBeanDefinition(className, parent);
// 对当前的 <Bean> 元素中配置的一些属性进行解析和设置，如配置的单态 (singleton) 属性等
// 对当前的 <bean> 元素中配置的一些属性进行解析和设置，如配置的单例 (singleton) 属性等
parseBeanDefinitionAttributes(ele, beanName, containingBean, bd);
// 为 <Bean> 元素解析的 Bean 设置 description 信息
// 为 BeanDefinition对象 注入 description属性值
bd.setDescription(DomUtils.getChildElementValueByTagName(ele, DESCRIPTION_ELEMENT));
// 对 <Bean> 元素的 meta(元信息) 属性解析
// 解析 <bean> 元素中的 meta 属性
parseMetaElements(ele, bd);
// 对 <Bean> 元素的 lookup-method 属性解析
// 解析 <bean> 元素中的 lookup-method 属性
parseLookupOverrideSubElements(ele, bd.getMethodOverrides());
// 对 <Bean> 元素的 replaced-method 属性解析
// 解析 <bean> 元素中的 replaced-method 属性
parseReplacedMethodSubElements(ele, bd.getMethodOverrides());
// 解析 <Bean> 元素的构造方法属性
// 解析 <bean> 元素的构造方法
parseConstructorArgElements(ele, bd);
// 解析 <Bean> 元素所有的 <property> 属性
// 解析 <bean> 元素中的所有 <property> 元素
parsePropertyElements(ele, bd);
// 解析 <Bean> 元素的 qualifier 属性
// 解析 <bean> 元素的 qualifier 属性
parseQualifierElements(ele, bd);
//为当前解析的 Bean 设置所需的资源和依赖对象
// 为当前BeanDefinition对象 设置所需的资源和依赖对象
bd.setResource(this.readerContext.getResource());
bd.setSource(extractSource(ele));
@ -645,15 +662,17 @@ spring-context https://github.com/AmyliaY/spring-context-reading
finally {
this.parseState.pop();
}
// 解析 <Bean> 元素出错时，返回 null
// 解析 <bean> 元素出错时，返回 null
return null;
}
```
## 8、对 bean 的部分子元素进行解析的具体实现
对 bean 的部分子元素进行解析的具体实现。
```java
// 解析 <Bean> 元素中所有的 <property> 子元素
/**
* 解析 <bean> 元素中所有的 <property> 子元素
*/
public void parsePropertyElements(Element beanEle, BeanDefinition bd) {
// 获取对应 bean 元素中所有的 <property> 子元素，逐一解析
// 获取对应 <bean> 元素中所有的 <property> 子元素，逐一解析
NodeList nl = beanEle.getChildNodes();
for (int i = 0; i < nl.getLength(); i++) {
Node node = nl.item(i);
@ -664,7 +683,9 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
}
// 详细解析 <property> 元素
/**
* 详细解析 <property> 元素
*/
public void parsePropertyElement(Element ele, BeanDefinition bd) {
// 获取 <property> 元素的名字
String propertyName = ele.getAttribute(NAME_ATTRIBUTE);
@ -680,14 +701,15 @@ spring-context https://github.com/AmyliaY/spring-context-reading
error("Multiple 'property' definitions for property '" + propertyName + "'", ele);
return;
}
// 解析获取 property 的值，返回的对象对应 对 bean 定义的 property 属性设置的
// 解析结果，这个解析结果会封装到 PropertyValue 对象中，然后设置到 BeanDefinitionHolder 中去
// 解析获取 propertyName 对应的 value值，propertyName 及其 value值会被封装到
// PropertyValue 对象中，然后 set 到 BeanDefinition对象中去
Object val = parsePropertyValue(ele, bd, propertyName);
// 根据 property 的名字和值创建 property 实例
// 根据 property 的 名字propertyName 和 值val 创建 PropertyValue实例
PropertyValue pv = new PropertyValue(propertyName, val);
// 解析 <property> 元素中的属性
// 解析 <meta> 元素
parseMetaElements(ele, pv);
pv.setSource(extractSource(ele));
// 为当前的 BeanDefinition对象设置 propertyValues 属性值
bd.getPropertyValues().addPropertyValue(pv);
}
finally {
@ -695,7 +717,9 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
}
// 解析获取 property 值
/**
* 解析获取 <property> 元素的属性值 value
*/
public Object parsePropertyValue(Element ele, BeanDefinition bd, String propertyName) {
String elementName = (propertyName != null) ?
"<property> element for property '" + propertyName + "'" :
@ -762,7 +786,9 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
}
// 解析 <property> 元素中 ref,value 或者集合等子元素
/**
* 解析 <property> 元素中 ref,value 或者集合等子元素
*/
public Object parsePropertySubElement(Element ele, BeanDefinition bd) {
return parsePropertySubElement(ele, bd, null);
}
@ -855,7 +881,9 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
}
// 解析 <list> 集合子元素
/**
* 解析 <list> 集合子元素
*/
public List parseListElement(Element collectionEle, BeanDefinition bd) {
// 获取 <list> 元素中的 value-type 属性，即获取集合元素的数据类型
String defaultElementType = collectionEle.getAttribute(VALUE_TYPE_ATTRIBUTE);
@ -872,7 +900,9 @@ spring-context https://github.com/AmyliaY/spring-context-reading
return target;
}
// 具体解析 <list> 集合元素，<array>、<list> 和 <set> 都使用该方法解析
/**
* 具体解析 <list> 集合元素，<array>、<list> 和 <set> 都使用该方法解析
*/
protected void parseCollectionElements(NodeList elementNodes, Collection<Object> target,
BeanDefinition bd, String defaultElementType) {
@ -887,4 +917,4 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
}
```
经过这样逐层地解析，我们在配置文件中定义的 Bean 就被整个解析成了可以被 IoC 容器装载和使用的 BeanDefinition，这种数据结构可以让 IoC 容器执行索引、查询等操作。经过上述解析得到的 BeanDefinition，接下来我们就可以将它注册到 IoC 容器中咯。
经过这样逐层地解析，我们在配置文件中定义的 bean 就被整个解析成了 IoC 容器能够装载和使用的 BeanDefinition对象，这种数据结构可以让 IoC 容器执行索引、查询等操作。经过上述解析，接下来我们就可以将得到的 BeanDefinition对象 注册到 IoC 容器中咯。

71
docs/Spring/IoC/3、将BeanDefinition注册进IoC容器.md
Unescape View File

@ -1,17 +1,21 @@
这篇文章分享一下 spring IoC 容器初始化第三部分的代码，也就是将前面解析得到的 BeanDefinition 注册进 IoC 容器，其实就是存入一个 ConcurrentHashMap<String, BeanDefinition> 中。
（PS：可以结合我 GitHub 上对 spring 框架源码的翻译注解一起看，会更有助于各位同学理解，地址：
## 前言
这篇文章分享一下 spring IoC 容器初始化第三部分的代码，也就是将前面解析出来的 BeanDefinition对象 注册进 IoC 容器，其实就是存入一个 ConcurrentHashMap<String, BeanDefinition> 中。
（PS：可以结合我 GitHub 上对 Spring 框架源码的翻译注释一起看，会更有助于各位同学理解，地址：
spring-beans https://github.com/AmyliaY/spring-beans-reading
spring-context https://github.com/AmyliaY/spring-context-reading
）
## 1、回过头看一下前面在 DefaultBeanDefinitionDocumentReader 中实现的 processBeanDefinition(Element ele, BeanDefinitionParserDelegate delegate) 方法
## 正文
回过头看一下前面在 DefaultBeanDefinitionDocumentReader 中实现的 processBeanDefinition(Element ele, BeanDefinitionParserDelegate delegate) 方法。
```java
// 解析 Bean 定义资源 Document 对象的普通元素
/**
* 将 .xml 文件中的元素解析成 BeanDefinition对象，并注册到 IoC容器 中
*/
protected void processBeanDefinition(Element ele, BeanDefinitionParserDelegate delegate) {
// BeanDefinitionHolder 是对 BeanDefinition 的封装，即 BeanDefinition 的封装类
// BeanDefinitionHolder 是对 BeanDefinition 的进一步封装，它持有一个 BeanDefinition 对象 及其对应
// 的 beanName、aliases别名。
// 对 Document 对象中 <Bean> 元素的解析由 BeanDefinitionParserDelegate 实现
BeanDefinitionHolder bdHolder = delegate.parseBeanDefinitionElement(ele);
if (bdHolder != null) {
@ -20,7 +24,7 @@ spring-context https://github.com/AmyliaY/spring-context-reading
try {
/**
* ！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！
* 向 Spring IoC 容器注册解析 BeanDefinition，这是 BeanDefinition 向 IoC 容器注册的入口
* 向 IoC 容器注册解析完成的 BeanDefinition对象，这是 BeanDefinition 向 IoC 容器注册的入口
* ！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！
*/
BeanDefinitionReaderUtils.registerBeanDefinition(bdHolder, getReaderContext().getRegistry());
@ -29,28 +33,30 @@ spring-context https://github.com/AmyliaY/spring-context-reading
getReaderContext().error("Failed to register bean definition with name '" +
bdHolder.getBeanName() + "'", ele, ex);
}
// 在完成向 Spring IOC 容器注册解析得到的 Bean 定义之后，发送注册事件
// 在完成向 IOC容器 注册 BeanDefinition对象 之后，发送注册事件
getReaderContext().fireComponentRegistered(new BeanComponentDefinition(bdHolder));
}
}
```
## 2、BeanDefinitionReaderUtils 的 registerBeanDefinition(BeanDefinitionHolder definitionHolder, BeanDefinitionRegistry registry) 方法
接着看一下 BeanDefinitionReaderUtils 的 registerBeanDefinition(BeanDefinitionHolder definitionHolder, BeanDefinitionRegistry registry) 方法。
```java
// 将解析的 BeanDefinitionHold 注册到容器中
/**
* 将解析到的 BeanDefinition对象 注册到 IoC容器
*/
public static void registerBeanDefinition(
BeanDefinitionHolder definitionHolder, BeanDefinitionRegistry registry)
throws BeanDefinitionStoreException {
// 获取解析的 BeanDefinition 的名称
// 获取解析的 <bean>元素 的名称 beanName
String beanName = definitionHolder.getBeanName();
/**
* ！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！
* 开始向 IOC 容器注册 BeanDefinition
* 开始向 IoC容器 注册 BeanDefinition对象
* ！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！
*/
registry.registerBeanDefinition(beanName, definitionHolder.getBeanDefinition());
// 如果解析的 BeanDefinition 有别名，向容器为其注册别名
// 如果解析的 <bean>元素 有别名alias，向容器中注册别名
String[] aliases = definitionHolder.getAliases();
if (aliases != null) {
for (String aliase : aliases) {
@ -59,16 +65,27 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
}
```
## 3、BeanDefinitionRegistry 中的 registerBeanDefinition(String beanName, BeanDefinition beanDefinition) 方法在 DefaultListableBeanFactory 实现类中的具体实现
BeanDefinitionRegistry 中的 registerBeanDefinition(String beanName, BeanDefinition beanDefinition) 方法在 DefaultListableBeanFactory 实现类中的具体实现。
```java
// 向 IoC 容器注册解析的 BeanDefinito
public class DefaultListableBeanFactory extends AbstractAutowireCapableBeanFactory
implements ConfigurableListableBeanFactory, BeanDefinitionRegistry, Serializable {
/** 按注册顺序排列的 beanDefinition名称列表(即 beanName) */
private final List<String> beanDefinitionNames = new ArrayList<String>();
/** IoC容器 的实际体现，key --> beanName，value --> BeanDefinition对象 */
private final Map<String, BeanDefinition> beanDefinitionMap = new ConcurrentHashMap<String, BeanDefinition>(64);
/**
* 向 IoC容器 注册解析的 beanName 和 BeanDefinition对象
*/
public void registerBeanDefinition(String beanName, BeanDefinition beanDefinition)
throws BeanDefinitionStoreException {
Assert.hasText(beanName, "Bean name must not be empty");
Assert.notNull(beanDefinition, "BeanDefinition must not be null");
// 校验解析的 BeanDefiniton
// 校验解析的 BeanDefiniton对象
if (beanDefinition instanceof AbstractBeanDefinition) {
try {
((AbstractBeanDefinition) beanDefinition).validate();
@ -83,34 +100,34 @@ spring-context https://github.com/AmyliaY/spring-context-reading
synchronized (this.beanDefinitionMap) {
Object oldBeanDefinition = this.beanDefinitionMap.get(beanName);
// 检查是否有同名的 BeanDefinition 已经在 IOC 容器中注册，如果已经注册，
// 并且不允许覆盖已注册的 BeanDefinition，则抛出注册失败异常，
// allowBeanDefinitionOverriding 默认为 true
// 检查是否有同名(beanName)的 BeanDefinition 存在于 IoC容器 中，如果已经存在，且不允许覆盖
// 已注册的 BeanDefinition，则抛出注册异常，allowBeanDefinitionOverriding 默认为 true
if (oldBeanDefinition != null) {
if (!this.allowBeanDefinitionOverriding) {
throw new BeanDefinitionStoreException(beanDefinition.getResourceDescription(), beanName,
"Cannot register bean definition [" + beanDefinition + "] for bean '" + beanName +
"': There is already [" + oldBeanDefinition + "] bound.");
}
else {// 如果允许覆盖，则同名的 Bean，后注册的覆盖先注册的
// 如果允许覆盖同名的 bean，后注册的会覆盖先注册的
else {
if (this.logger.isInfoEnabled()) {
this.logger.info("Overriding bean definition for bean '" + beanName +
"': replacing [" + oldBeanDefinition + "] with [" + beanDefinition + "]");
}
}
}
else {// IOC 容器中没有已经注册同名的 Bean，按正常注册流程注册
// 若该 beanName 在 IoC容器 中尚未注册，将其注册到 IoC容器中，
else {
// 将 beanName 注册到 beanDefinitionNames列表
this.beanDefinitionNames.add(beanName);
this.frozenBeanDefinitionNames = null;
}
// beanDefinitionMap 是 IoC容器 的最主要体现，他是一个 ConcurrentHashMap，
// 直接存储了 bean的唯一标识 beanName，及其对应的 BeanDefinition对象
this.beanDefinitionMap.put(beanName, beanDefinition);
}
// 重置所有已经注册过的 BeanDefinition 的缓存
resetBeanDefinition(beanName);
}
```
## 最后看一下 spring 的 IoC 容器在代码中最直接的体现
```java
// 存储注册信息的 BeanDefinition 集合，也就是所谓的 IoC 容器
private final Map<String, BeanDefinition> beanDefinitionMap = new ConcurrentHashMap<String, BeanDefinition>(64);
}
```

371
docs/Spring/IoC/4、依赖注入(DI).md
Unescape View File

@ -1,53 +1,55 @@
前面我们主要分析了 FileSystemXmlApplicationContext 这个具体的 IoC 容器的初始化源码实现，在 IoC 容器中建立了 BeanDefinition 的数据映射，将其和 beanName 一起绑定在一个 ConcurrentHashMap 中。现在我们来看一下 spring 是如何将 IoC 容器中的 Bean 根据配置关联在一起的。
## 前言
前面我们主要分析了 FileSystemXmlApplicationContext 这个具体的 IoC容器实现类 的初始化源码，在 IoC容器 中建立了 beanName 到 BeanDefinition 的数据映射，通过一个 ConcurrentHashMap。现在我们来看一下 Spring 是如何将 IoC 容器中存在依赖关系的 bean 根据配置联系在一起的。
Spring 中触发 IoC 容器“依赖注入”的方式有两种，一个是通过 getBean() 向容器索要 bean 时触发依赖注入；另一个是给 bean 配置 lazy-init 属性，spring 会自动调用此 bean 的 getBean() 方法，提前完成依赖注入。总的来说，想提高运行时获取 bean 的效率，可以考虑配置此属性。
Spring 中触发 IoC容器“依赖注入” 的方式有两种，一个是应用程序通过 getBean()方法 向容器索要 bean实例 时触发依赖注入；另一个是提前给 bean 配置了 lazy-init 属性为 false，Spring 在 IoC容器 初始化会自动调用此 bean 的 getBean() 方法，提前完成依赖注入。总的来说，想提高运行时获取 bean 的效率，可以考虑配置此属性。
下面我将分别解读这两种依赖注入的触发方式，先看 getBean() 的，因为 lazy-init 最后也是通过调用 getBean 完成的依赖注入。
（PS：可以结合我 GitHub 上对 spring 框架源码的阅读及个人理解一起看，会更有助于各位开发姥爷理解，地址：
下面我将分别解读这两种依赖注入的触发方式，先看 getBean() 的，因为 lazy-init 最后也是通过调用 getBean() 完成的依赖注入。
（PS：可以结合我 GitHub 上对 Spring 框架源码的阅读及个人理解一起看，会更有助于各位开发姥爷理解，地址：
spring-beans https://github.com/AmyliaY/spring-beans-reading
spring-context https://github.com/AmyliaY/spring-context-reading
）
## 1、AbstractBeanFactory 中的 getBean() 系列方法及 doGetBean() 具体实现
## 正文
首先看一下 AbstractBeanFactory 中的 getBean() 系列方法及 doGetBean() 具体实现。
```java
public abstract class AbstractBeanFactory extends FactoryBeanRegistrySupport implements ConfigurableBeanFactory {
//---------------------------------------------------------------------
// BeanFactory 接口的实现，下列的 getBean() 方法不论是哪种重载，最后都会走
// doGetBean(final String name, final Class<T> requiredType, final Object[] args, boolean typeCheckOnly) 的具体实现
//---------------------------------------------------------------------
// 获取 IOC 容器中指定名称的 Bean
// 获取 IoC容器 中指定名称的 bean
public Object getBean(String name) throws BeansException {
return doGetBean(name, null, null, false);
}
// 获取 IOC 容器中指定名称和类型的 Bean
// 获取 IoC容器 中指定名称和类型的 bean
public <T> T getBean(String name, Class<T> requiredType) throws BeansException {
return doGetBean(name, requiredType, null, false);
}
// 获取 IOC 容器中指定名称和参数的 Bean
// 获取 IoC容器 中指定名称和参数的 bean
public Object getBean(String name, Object... args) throws BeansException {
return doGetBean(name, null, args, false);
}
// 获取 IOC 容器中指定名称、类型和参数的 Bean
// 获取 IoC容器 中指定名称、类型和参数的 bean
public <T> T getBean(String name, Class<T> requiredType, Object... args) throws BeansException {
return doGetBean(name, requiredType, args, false);
}
// 真正实现向 IOC 容器获取 Bean 的功能，也是触发依赖注入 (DI) 功能的地方
// 真正实现向 IoC容器 获取 bean 的功能，也是触发 依赖注入(DI) 的地方
@SuppressWarnings("unchecked")
protected <T> T doGetBean(final String name, final Class<T> requiredType, final Object[] args,
boolean typeCheckOnly) throws BeansException {
// 根据用户指定的名称获取 IoC 容器中与 BeanDefinition 对应的 beanName
// 如果指定的是别名，则将别名转换为规范的 beanName
// 根据用户给定的名称(也可能是别名alias) 获取 IoC容器 中与 BeanDefinition 唯一对应的 beanName
final String beanName = transformedBeanName(name);
Object bean;
// 先查看缓存中是否有对应的，已创建的单例 Bean，对于单例 Bean，整个 IOC 容器中只创建一次
// 根据 beanName 查看缓存中是否有已实例化的 单例bean，对于 单例bean，整个 IoC容器 只创建一次
Object sharedInstance = getSingleton(beanName);
if (sharedInstance != null && args == null) {
if (logger.isDebugEnabled()) {
@ -59,12 +61,12 @@ spring-context https://github.com/AmyliaY/spring-context-reading
logger.debug("Returning cached instance of singleton bean '" + beanName + "'");
}
}
// 获取给定 Bean 的实例对象，主要是完成 FactoryBean 的相关处理
// 注意：BeanFactory 本质上是一个 IoC 容器，而 FactoryBean 是 IoC 容器中一种特殊的工厂 bean
// 能够生产其他对象，注意两者之间的区别
// 获取给定 bean 的实例对象，主要是完成 FactoryBean 的相关处理
// 注意：BeanFactory 是一个 IoC容器，它保存了 bean 的基本配置信息。
// 而 FactoryBean 是 IoC容器 中一种特殊的 bean，它能够实例化 bean对象，注意两者之间的区别
bean = getObjectForBeanInstance(sharedInstance, name, beanName, null);
}
// 如果应用程序要获取的 bean 还未创建
else {
if (isPrototypeCurrentlyInCreation(beanName)) {
throw new BeanCurrentlyInCreationException(beanName);
@ -75,7 +77,7 @@ spring-context https://github.com/AmyliaY/spring-context-reading
// 如果当前容器中没有指定的 bean，且当前容器的父容器不为空
// 则从父容器中去找，如果父容器也没有，则沿着当前容器的继承体系一直向上查找
if (parentBeanFactory != null && !containsBeanDefinition(beanName)) {
// 解析指定 Bean 名称的原始名称
// 根据用户传入的 name(有可能是别名alias)，获取唯一标识的 beanName
String nameToLookup = originalBeanName(name);
if (args != null) {
// 委派父级容器根据指定名称和显式的参数查找
@ -87,9 +89,9 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
}
// 创建的 Bean 是否需要进行类型验证，一般不需要
// 创建的 bean 是否需要进行类型验证，一般不需要
if (!typeCheckOnly) {
// 向容器标记指定的 Bean 已经被创建
// 向容器标记指定的 bean 已经被创建
markBeanAsCreated(beanName);
}
@ -98,26 +100,28 @@ spring-context https://github.com/AmyliaY/spring-context-reading
final RootBeanDefinition mbd = getMergedLocalBeanDefinition(beanName);
checkMergedBeanDefinition(mbd, beanName, args);
// 获取当前 Bean 依赖的所有 Bean，下面的 getBean(dependsOnBean) 方法会触发 getBean() 的递归调用，
// 直到取到一个不依赖任何其它 bean 的 bean 为止
// 获取当前 bean 所依赖bean 的 beanName，下面的 getBean(dependsOnBean) 方法会触发
// getBean() 的递归调用，直到取到一个不依赖任何其它 bean 的 bean 为止。
// 比如：beanA 依赖了 beanB，而 beanB 依赖了 beanC，那么在实例化 beanA 时会先实例化
// beanC，然后实例化 beanB 并将 beanC 注入进去，最后实例化 beanA 时将 beanB 注入
String[] dependsOn = mbd.getDependsOn();
if (dependsOn != null) {
for (String dependsOnBean : dependsOn) {
// 递归调用 getBean() 方法，获取当前 Bean 所依赖的 bean
// 递归调用 getBean() 方法，从末级节点依次实例化 依赖的bean
getBean(dependsOnBean);
// 把当前 bean 所依赖的 bean 进行注入
// 把 当前bean 直接依赖的bean 进行注册
//（也就是通过 setter 或构造方法将依赖的 bean 赋值给当前 bean 对应的属性）
registerDependentBean(dependsOnBean, beanName);
}
}
// 创建单例模式 bean 的实例对象
// 如果当前 bean 是单例的
if (mbd.isSingleton()) {
// 这里使用了一个匿名内部类，创建 Bean 实例对象，并且注册给所依赖的对象
// 这里使用了一个匿名内部类，创建 bean实例对象
sharedInstance = getSingleton(beanName, new ObjectFactory<Object>() {
public Object getObject() throws BeansException {
try {
// 创建一个指定 Bean 实例对象，如果有父级继承，则合并子类和父类的定义
// 根据给定的 beanName 及 RootBeanDefinition对象，创建 bean 实例对象
return createBean(beanName, mbd, args);
}
catch (BeansException ex) {
@ -126,41 +130,42 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
}
});
// 获取给定 Bean 的实例对象
// 获取给定 bean 的实例对象
bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
}
// IoC 容器创建原型模式 Bean 实例对象
// 创建原型模式的 bean 实例对象
else if (mbd.isPrototype()) {
// 原型模式 (Prototype) 是每次都会创建一个新的对象
// 原型模式 (Prototype) 每次都会创建一个新的对象
Object prototypeInstance = null;
try {
// 回调 beforePrototypeCreation 方法，默认的功能是注册当前创建的原型对象
// 回调 beforePrototypeCreation() 方法，默认的功能是注册当前创建的原型对象
beforePrototypeCreation(beanName);
// 创建指定 Bean 对象实例
// 创建指定 bean 对象实例
prototypeInstance = createBean(beanName, mbd, args);
}
finally {
// 回调 afterPrototypeCreation 方法，默认的功能告诉 IoC 容器指定 Bean 的原型对象不再创建了
// 回调 afterPrototypeCreation() 方法，默认的功能是告诉 IoC容器
// 指定 bean 的原型对象不再创建了
afterPrototypeCreation(beanName);
}
// 获取给定 Bean 的实例对象
// 获取给定 bean 的实例对象
bean = getObjectForBeanInstance(prototypeInstance, name, beanName, mbd);
}
// 要创建的 Bean 既不是单例模式，也不是原型模式，则根据 Bean 定义资源中
// 配置的生命周期范围，选择实例化 Bean 的合适方法，这种在 Web 应用程序中
// 要创建的 bean 既不是单例模式，也不是原型模式，则根据该 bean元素 在配置文件中
// 配置的生命周期范围，选择实例化 bean 的合适方法，这种在 Web 应用程序中
// 比较常用，如：request、session、application 等的生命周期
else {
// 获取此 bean 生命周期的范围
String scopeName = mbd.getScope();
final Scope scope = this.scopes.get(scopeName);
// Bean 定义资源中没有配置生命周期范围，则 Bean 定义不合法
// bean 定义资源中没有配置生命周期范围，则该 bean 的配置不合法
if (scope == null) {
throw new IllegalStateException("No Scope registered for scope '" + scopeName + "'");
}
try {
// 这里又使用了一个匿名内部类，获取一个指定生命周期范围的实例
// 这里又使用了一个 ObjectFactory 的匿名内部类，获取一个指定生命周期范围的实例
Object scopedInstance = scope.get(beanName, new ObjectFactory<Object>() {
public Object getObject() throws BeansException {
beforePrototypeCreation(beanName);
@ -172,7 +177,7 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
}
});
// 获取给定 Bean 的实例对象
// 获取给定 bean 的实例对象
bean = getObjectForBeanInstance(scopedInstance, name, beanName, mbd);
}
catch (IllegalStateException ex) {
@ -189,7 +194,7 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
}
// 对创建的 bean 实例对象进行非空验证和类型检查，如果没问题就返回这个已经完成依赖注入的 bean
// 对要返回的 bean实例对象 进行非空验证和类型检查，如果没问题就返回这个已经完成 依赖注入的bean
if (requiredType != null && bean != null && !requiredType.isAssignableFrom(bean.getClass())) {
try {
return getTypeConverter().convertIfNecessary(bean, requiredType);
@ -204,12 +209,16 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
return (T) bean;
}
}
```
总的来说，getBean() 方法是依赖注入的起点，之后会调用 createBean()，根据 BeanDefinition 的定义生成 bean 对象，下面我们看看 AbstractBeanFactory 的子类 AbstractAutowireCapableBeanFactory 中对 createBean() 的具体实现。
## 2、AbstractAutowireCapableBeanFactory 中的 createBean() 和 doCreateBean() 具体实现
总的来说，getBean() 方法是依赖注入的起点，之后会调用 createBean()，根据之前解析生成的 BeanDefinition对象 生成 bean 对象，下面我们看看 AbstractBeanFactory 的子类 AbstractAutowireCapableBeanFactory 中对 createBean() 的具体实现。
```java
// 创建指定的 bean 实例对象
public abstract class AbstractAutowireCapableBeanFactory extends AbstractBeanFactory
implements AutowireCapableBeanFactory {
/**
* 创建指定的 bean 实例对象
*/
@Override
protected Object createBean(final String beanName, final RootBeanDefinition mbd, final Object[] args)
throws BeanCreationException {
@ -217,11 +226,11 @@ spring-context https://github.com/AmyliaY/spring-context-reading
if (logger.isDebugEnabled()) {
logger.debug("Creating instance of bean '" + beanName + "'");
}
// 判断需要创建的 Bean 是否可以实例化，是否可以通过当前的类加载器加载
// 判断需要创建的 bean 是否可实例化，是否可以通过当前的类加载器加载
resolveBeanClass(mbd, beanName);
try {
// 校验和准备 Bean 中的方法覆盖
// 校验和准备 bean 中的方法覆盖
mbd.prepareMethodOverrides();
}
catch (BeanDefinitionValidationException ex) {
@ -230,7 +239,7 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
try {
// 如果 Bean 配置了后置处理器 PostProcessor，则这里返回一个 proxy 代理对象
// 如果 bean 配置了后置处理器 PostProcessor，则这里返回一个 proxy 代理对象
Object bean = resolveBeforeInstantiation(beanName, mbd);
if (bean != null) {
return bean;
@ -241,7 +250,7 @@ spring-context https://github.com/AmyliaY/spring-context-reading
"BeanPostProcessor before instantiation of bean failed", ex);
}
// 创建 Bean 实例对象的具体实现
// 创建 bean 实例对象的具体实现
Object beanInstance = doCreateBean(beanName, mbd, args);
if (logger.isDebugEnabled()) {
logger.debug("Finished creating instance of bean '" + beanName + "'");
@ -249,17 +258,17 @@ spring-context https://github.com/AmyliaY/spring-context-reading
return beanInstance;
}
// 创建 Bean 实例对象的具体实现，spring 中以 do 开头的都是方法的具体实现
/**
* 创建 bean 实例对象的具体实现，Spring 中以 do 开头的都是方法的具体实现
*/
protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final Object[] args) {
// 封装被创建的 Bean 对象
BeanWrapper instanceWrapper = null;
// 如果这个 bean 是单例的，则从缓存中获取这个 BeanWrapper 实例并清除
// 如果这个 bean 是单例的，则从缓存中获取这个 beanName 对应的 BeanWrapper实例，并清除
if (mbd.isSingleton()) {
instanceWrapper = this.factoryBeanInstanceCache.remove(beanName);
}
if (instanceWrapper == null) {
/**
* ！！！！！！！！！！！！！
* 创建实例对象
@ -280,7 +289,7 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
}
// 向容器中缓存单例模式的 Bean 对象，以防循环引用
// 向容器中缓存单例模式的 bean 对象，以防循环引用
boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
isSingletonCurrentlyInCreation(beanName));
if (earlySingletonExposure) {
@ -288,7 +297,7 @@ spring-context https://github.com/AmyliaY/spring-context-reading
logger.debug("Eagerly caching bean '" + beanName +
"' to allow for resolving potential circular references");
}
// 这里是一个匿名内部类，为了防止循环引用，尽早持有对象的引用
// 这里是一个 ObjectFactory 的匿名内部类，为了防止循环引用，尽早持有对象的引用
addSingletonFactory(beanName, new ObjectFactory<Object>() {
public Object getObject() throws BeansException {
return getEarlyBeanReference(beanName, mbd, bean);
@ -296,8 +305,8 @@ spring-context https://github.com/AmyliaY/spring-context-reading
});
}
// Bean 对象的初始化，依赖注入在此触发
// 这个 exposedObject 在初始化完成之后，将返回作为依赖注入完成后的 Bean
// bean 对象的初始化，依赖注入在此触发
// 这个 exposedObject 在初始化完成之后，将返回作为依赖注入完成后的 bean
Object exposedObject = bean;
try {
/**
@ -307,9 +316,7 @@ spring-context https://github.com/AmyliaY/spring-context-reading
*/
populateBean(beanName, mbd, instanceWrapper);
if (exposedObject != null) {
// 初始化 Bean 对象
// 在对 Bean 实例对象生成和依赖注入完成以后，开始对 Bean 实例对象
// 进行初始化 ，为 Bean 实例对象应用 BeanPostProcessor 后置处理器
// 初始化 bean对象
exposedObject = initializeBean(beanName, exposedObject, mbd);
}
}
@ -323,21 +330,21 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
if (earlySingletonExposure) {
// 获取指定名称的已注册的单例模式 Bean 对象
// 获取指定名称的已注册的 单例bean对象
Object earlySingletonReference = getSingleton(beanName, false);
if (earlySingletonReference != null) {
// 如果根据名称获取的已注册的 Bean 和正在实例化的 Bean 是同一个
// 如果根据名称获取的已注册的 bean 和正在实例化的 bean 是同一个
if (exposedObject == bean) {
// 当前实例化的 Bean 初始化完成
// 当前实例化的 bean 初始化完成
exposedObject = earlySingletonReference;
}
// 如果当前 Bean 依赖其他 Bean，并且当发生循环引用时不允许新创建实例对象
// 如果当前 bean 依赖其他 bean，并且当发生循环引用时不允许新创建实例对象
else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
String[] dependentBeans = getDependentBeans(beanName);
Set<String> actualDependentBeans = new LinkedHashSet<String>(dependentBeans.length);
// 获取当前 Bean 所依赖的其他 Bean
// 获取当前 bean 所依赖的其他 bean
for (String dependentBean : dependentBeans) {
// 对依赖 Bean 进行类型检查
// 对 依赖bean 进行类型检查
if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
actualDependentBeans.add(dependentBean);
}
@ -356,7 +363,7 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
try {
// 注册完成依赖注入的 Bean
// 注册 成完依赖注入的bean
registerDisposableBeanIfNecessary(beanName, bean, mbd);
}
catch (BeanDefinitionValidationException ex) {
@ -366,23 +373,23 @@ spring-context https://github.com/AmyliaY/spring-context-reading
// 为应用返回所需要的实例对象
return exposedObject;
}
}
```
从源码中可以看到 createBeanInstance() 和 populateBean() 这两个方法与依赖注入的实现非常密切，createBeanInstance() 方法中生成了 Bean 所包含的 Java 对象，populateBean() 方法对这些生成的 bean 对象之间的依赖关系进行了处理。下面我们先看一下 createBeanInstance() 方法的实现。
## 3、createBeanInstance() 方法的具体实现
从源码中可以看到 createBeanInstance() 和 populateBean() 这两个方法与依赖注入的实现非常密切，createBeanInstance() 方法中生成了 bean 所包含的 Java 对象，populateBean() 方法对这些生成的 bean 对象之间的依赖关系进行了处理。下面我们先看一下 createBeanInstance() 方法的实现。
```java
// 创建 Bean 的实例对象
/**
* 创建 bean 的实例对象
*/
protected BeanWrapper createBeanInstance(String beanName, RootBeanDefinition mbd, Object[] args) {
// 检查确认 Bean 是可实例化的
// 检查确认 bean 是可实例化的
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());
}
// 使用工厂方法对 Bean 进行实例化
// 使用 RootBeanDefinition对象 中的 factoryMethodName 对 bean 进行实例化
if (mbd.getFactoryMethodName() != null) {
return instantiateUsingFactoryMethod(beanName, mbd, args);
}
@ -400,8 +407,7 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
if (resolved) {
if (autowireNecessary) {
// 配置了自动装配属性，使用容器的自动装配实例化，
// 即，根据参数类型匹配 Bean 的构造方法
// 配置了自动装配属性，使用容器的自动装配实例化，即，根据参数类型匹配 bean 的构造方法
return autowireConstructor(beanName, mbd, null, null);
}
else {
@ -410,7 +416,7 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
}
// 使用 Bean 的构造方法进行实例化
// 使用 bean 的构造方法进行实例化
Constructor<?>[] ctors = determineConstructorsFromBeanPostProcessors(beanClass, beanName);
if (ctors != null ||
mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_CONSTRUCTOR ||
@ -422,14 +428,14 @@ spring-context https://github.com/AmyliaY/spring-context-reading
return instantiateBean(beanName, mbd);
}
// 使用默认的无参构造方法实例化 Bean 对象
// 使用默认的无参构造方法实例化 bean对象
protected BeanWrapper instantiateBean(final String beanName, final RootBeanDefinition mbd) {
try {
Object beanInstance;
final BeanFactory parent = this;
// 获取系统的安全管理接口，JDK 标准的安全管理 API
if (System.getSecurityManager() != null) {
// 这里是一个匿名内置类，根据实例化策略创建实例对象
// 这里使用了一个 PrivilegedAction 的匿名内部类，根据实例化策略创建实例对象
beanInstance = AccessController.doPrivileged(new PrivilegedAction<Object>() {
public Object run() {
return getInstantiationStrategy().instantiate(mbd, beanName, parent);
@ -437,10 +443,9 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}, getAccessControlContext());
}
else {
/**
* ！！！！！！！！！！！！！！
* 使用初始化策略实例化 Bean 对象
* 使用初始化策略实例化 bean 对象
* ！！！！！！！！！！！！！！
*/
beanInstance = getInstantiationStrategy().instantiate(mbd, beanName, parent);
@ -453,23 +458,22 @@ spring-context https://github.com/AmyliaY/spring-context-reading
throw new BeanCreationException(mbd.getResourceDescription(), beanName, "Instantiation of bean failed", ex);
}
}
```
从源码中我们可以看到其调用了 SimpleInstantiationStrategy 实现类来生成 bean 对象，这个类是 spring 用来生成 bean 对象的默认类，它提供了两种策略来实例化 bean 对象，一种是利用 Java 的反射机制，另一种是直接使用 CGLIB。
## 4、SimpleInstantiationStrategy 中的 instantiate() 方法实现
从源码中我们可以看到其调用了 SimpleInstantiationStrategy 实现类来生成 bean 对象，这个类是 Spring 用来生成 bean对象 的默认类，它提供了两种策略来实例化 bean对象，一种是利用 Java 的反射机制，另一种是直接使用 CGLIB。
```java
// 使用初始化策略实例化 Bean 对象
public class SimpleInstantiationStrategy implements InstantiationStrategy {
// 使用初始化策略实例化 bean对象
public Object instantiate(RootBeanDefinition beanDefinition, String beanName, BeanFactory owner) {
// 如果 Bean 定义中没有方法覆盖，则使用 Java 的反射机制实例化对象，否则使用 CGLIB
// 如果 配置的bean 中没有方法覆盖，则使用 Java 的反射机制实例化对象，否则使用 CGLIB
if (beanDefinition.getMethodOverrides().isEmpty()) {
Constructor<?> constructorToUse;
synchronized (beanDefinition.constructorArgumentLock) {
// 获取对象的构造方法或生成对象的工厂方法对 bean 进行实例化
// 获取对象的构造方法对 bean 进行实例化
constructorToUse = (Constructor<?>) beanDefinition.resolvedConstructorOrFactoryMethod;
// 如果前面没有获取到构造方法，则通过反射获取
if (constructorToUse == null) {
// 使用 JDK 的反射机制，判断要实例化的 Bean 是否是接口
// 使用 JDK 的反射机制，判断要实例化的 bean 是否是接口
final Class clazz = beanDefinition.getBeanClass();
// 如果 clazz 是一个接口，直接抛出异常
if (clazz.isInterface()) {
@ -477,7 +481,7 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
try {
if (System.getSecurityManager() != null) {
// 这里是一个匿名内置类，使用反射机制获取 Bean 的构造方法
// 这里使用了一个 PrivilegedExceptionAction 的匿名内部类，使用反射机制获取 bean 的构造方法
constructorToUse = AccessController.doPrivileged(new PrivilegedExceptionAction<Constructor>() {
public Constructor run() throws Exception {
return clazz.getDeclaredConstructor((Class[]) null);
@ -494,7 +498,8 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
}
}
// 使用 BeanUtils 实例化，通过反射机制调用”构造方法.newInstance(arg)”来进行实例化
// 根据传入的 Constructor，在 BeanUtils 中调用该 Constructor 的
// newInstance(Object...) 方法，实例化指定对象
return BeanUtils.instantiateClass(constructorToUse);
}
else {
@ -507,17 +512,19 @@ spring-context https://github.com/AmyliaY/spring-context-reading
return instantiateWithMethodInjection(beanDefinition, beanName, owner);
}
}
}
```
在 SimpleInstantiationStrategy 的子类 CglibSubclassingInstantiationStrategy 中可以看到使用 CGLIB 进行实例化的源码实现。
## 5、CglibSubclassingInstantiationStrategy 中使用 CGLIB 进行实例化的源码实现
```java
// 下面两个方法都通过实例化自己的私有静态内部类 CglibSubclassCreator，
// 然后调用该内部类对象的实例化方法 instantiate() 完成实例化
public class CglibSubclassingInstantiationStrategy extends SimpleInstantiationStrategy {
/**
* 下面两个方法都通过实例化自己的私有静态内部类 CglibSubclassCreator，
* 然后调用该内部类对象的实例化方法 instantiate() 完成实例化
*/
protected Object instantiateWithMethodInjection(
RootBeanDefinition beanDefinition, String beanName, BeanFactory owner) {
// 必须生成 cglib 子类
return new CglibSubclassCreator(beanDefinition, owner).instantiate(null, null);
}
@ -545,11 +552,11 @@ spring-context https://github.com/AmyliaY/spring-context-reading
this.owner = owner;
}
// 使用 CGLIB 进行 Bean 对象实例化
// 使用 CGLIB 进行 bean对象 实例化
public Object instantiate(Constructor ctor, Object[] args) {
// 实例化 Enhancer对象，并为 Enhancer对象 设置父类，生成 Java 对象的参数，比如：基类、回调方法等
Enhancer enhancer = new Enhancer();
// 将 Bean 本身作为其父类
// 将 bean 本身作为其父类
enhancer.setSuperclass(this.beanDefinition.getBeanClass());
enhancer.setCallbackFilter(new CallbackFilterImpl());
enhancer.setCallbacks(new Callback[] {
@ -558,33 +565,38 @@ spring-context https://github.com/AmyliaY/spring-context-reading
new ReplaceOverrideMethodInterceptor()
});
// 使用 CGLIB 的 create 方法生成实例对象
// 使用 CGLIB 的 create() 方法生成实例对象
return (ctor == null) ? enhancer.create() : enhancer.create(ctor.getParameterTypes(), args);
}
}
}
```
至此，完成了 bean 对象的实例化，然后就可以根据解析得到的 BeanDefinition 完成对各个属性的赋值处理，也就是依赖注入。这个实现方法就是前面 AbstractAutowireCapableBeanFactory 类中的 populateBean() 方法。
## 6、AbstractAutowireCapableBeanFactory 中的 populateBean()，完成依赖注入
至此，完成了 bean对象 的实例化，然后就可以根据解析得到的 BeanDefinition对象 完成对各个属性的赋值处理，也就是依赖注入。这个实现方法就是前面 AbstractAutowireCapableBeanFactory 类中的 populateBean() 方法。
```java
// 为属性赋值，完成依赖注入
public abstract class AbstractAutowireCapableBeanFactory extends AbstractBeanFactory
implements AutowireCapableBeanFactory {
/**
* 为属性赋值，完成依赖注入
*/
protected void populateBean(String beanName, RootBeanDefinition mbd, BeanWrapper bw) {
// 获取 BeanDefinition 中设置的 property，这些 property 来自对 BeanDefinition 的解析
// 获取 RootBeanDefinition 中设置的 属性值PropertyValues，这些属性值来自对
// .xml 文件中 bean元素 的解析
PropertyValues pvs = mbd.getPropertyValues();
// 如果实例对象为 null，而要注入的属性值不为空，则抛出下述异常
// 如果 BeanWrapper对象 为 null，而要注入的属性值不为空，则抛出下述异常
if (bw == null) {
if (!pvs.isEmpty()) {
throw new BeanCreationException(
mbd.getResourceDescription(), beanName, "Cannot apply property values to null instance");
}
else {
// 实例对象为 null，属性值也为空，不需要设置属性值，直接返回
// BeanWrapper对象 为 null，属性值也为空，不需要设置属性值，直接返回
return;
}
}
// 在设置属性之前调用 Bean 的 PostProcessor 后置处理器
// 在设置属性之前调用 bean 的 PostProcessor 后置处理器
boolean continueWithPropertyPopulation = true;
if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
@ -608,12 +620,12 @@ spring-context https://github.com/AmyliaY/spring-context-reading
mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_TYPE) {
MutablePropertyValues newPvs = new MutablePropertyValues(pvs);
// 对 autowire 自动装配的处理，根据 Bean 名称自动装配注入
// 对 autowire 自动装配的处理，根据 bean 名称自动装配注入
if (mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_NAME) {
autowireByName(beanName, mbd, bw, newPvs);
}
// 根据 Bean 类型自动装配注入
// 根据 bean 类型自动装配注入
if (mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_TYPE) {
autowireByType(beanName, mbd, bw, newPvs);
}
@ -621,9 +633,9 @@ spring-context https://github.com/AmyliaY/spring-context-reading
pvs = newPvs;
}
// 检查容器是否持有用于处理单例模式 Bean 关闭时的后置处理器
// 检查容器是否持有用于处理单例模式 bean 关闭时的后置处理器
boolean hasInstAwareBpps = hasInstantiationAwareBeanPostProcessors();
// Bean 实例对象没有依赖，即没有继承基类
// bean实例对象 没有依赖，即没有继承基类
boolean needsDepCheck = (mbd.getDependencyCheck() != RootBeanDefinition.DEPENDENCY_CHECK_NONE);
if (hasInstAwareBpps || needsDepCheck) {
@ -654,7 +666,9 @@ spring-context https://github.com/AmyliaY/spring-context-reading
applyPropertyValues(beanName, mbd, bw, pvs);
}
// 解析并注入依赖属性的过程
/**
* 解析并注入依赖属性的过程
*/
protected void applyPropertyValues(String beanName, BeanDefinition mbd, BeanWrapper bw, PropertyValues pvs) {
if (pvs == null || pvs.isEmpty()) {
return;
@ -697,7 +711,7 @@ spring-context https://github.com/AmyliaY/spring-context-reading
if (converter == null) {
converter = bw;
}
// 创建一个 BeanDefinition 属性值解析器，将 Bean 定义中的属性值解析为 Bean 实例对象的实际值
// 创建一个 BeanDefinition 属性值解析器，将 BeanDefinition 中的属性值解析为 bean 实例对象的实际值
BeanDefinitionValueResolver valueResolver = new BeanDefinitionValueResolver(this, beanName, mbd, converter);
// 为属性的解析值创建一个副本，最后将属性值注入到实例对象中
@ -771,15 +785,17 @@ spring-context https://github.com/AmyliaY/spring-context-reading
mbd.getResourceDescription(), beanName, "Error setting property values", ex);
}
}
}
```
## 7、BeanDefinitionValueResolver 中解析属性值，对注入类型进行转换的具体实现
BeanDefinitionValueResolver 中解析属性值，对注入类型进行转换的具体实现。
```java
// 解析属性值，对注入类型进行转换
class BeanDefinitionValueResolver {
/**
* 解析属性值，对注入类型进行转换
*/
public Object resolveValueIfNecessary(Object argName, Object value) {
// 对引用类型的属性进行解析，RuntimeBeanReference 是在对
// BeanDefinition 进行解析时生成的数据对象
// 对引用类型的属性进行解析，RuntimeBeanReference 是在对 BeanDefinition 进行解析时生成的数据对象
if (value instanceof RuntimeBeanReference) {
RuntimeBeanReference ref = (RuntimeBeanReference) value;
/**
@ -790,7 +806,7 @@ spring-context https://github.com/AmyliaY/spring-context-reading
return resolveReference(argName, ref);
}
// 对属性值是引用容器中另一个 Bean 名称的解析
// 对属性值是引用容器中另一个 bean 名称的解析
else if (value instanceof RuntimeBeanNameReference) {
String refName = ((RuntimeBeanNameReference) value).getBeanName();
refName = String.valueOf(evaluate(refName));
@ -800,7 +816,7 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
return refName;
}
// 对 BeanDefinitionHolder 类型属性的解析，主要是 Bean 中的内部类
// 对 BeanDefinitionHolder 类型属性的解析，主要是 bean 中的内部类
else if (value instanceof BeanDefinitionHolder) {
BeanDefinitionHolder bdHolder = (BeanDefinitionHolder) value;
return resolveInnerBean(argName, bdHolder.getBeanName(), bdHolder.getBeanDefinition());
@ -898,10 +914,12 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
}
// 解析引用类型的属性值
/**
* 解析引用类型的属性值
*/
private Object resolveReference(Object argName, RuntimeBeanReference ref) {
try {
// 获取引用的 BeanName
// 获取 所引用bean 的 beanName
String refName = ref.getBeanName();
refName = String.valueOf(evaluate(refName));
// 如果引用的对象在父容器中，则从父容器中获取指定的引用对象
@ -914,11 +932,11 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
return this.beanFactory.getParentBeanFactory().getBean(refName);
}
// 从当前的容器中获取指定的引用 Bean 对象，如果指定的 Bean 没有被实例化
// 则会递归触发引用 Bean 的初始化和依赖注入
// 从当前的容器中获取指定的引用 bean对象，如果指定的 bean 没有被实例化
// 则会递归触发引用 bean 的初始化和依赖注入
else {
Object bean = this.beanFactory.getBean(refName);
// 为 refName 对应的 BeanDefinition 注入依赖的 Bean
// 为 refName对应的bean 注入 它所依赖的bean
this.beanFactory.registerDependentBean(refName, this.beanName);
return bean;
}
@ -930,7 +948,9 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
}
// 解析 array 类型的属性
/**
* 解析 array 类型的属性
*/
private Object resolveManagedArray(Object argName, List<?> ml, Class<?> elementType) {
// 创建一个指定类型的数组，用于存放和返回解析后的数组
Object resolved = Array.newInstance(elementType, ml.size());
@ -942,7 +962,9 @@ spring-context https://github.com/AmyliaY/spring-context-reading
return resolved;
}
// 解析 list 类型的属性
/**
* 解析 list 类型的属性
*/
private List resolveManagedList(Object argName, List<?> ml) {
List<Object> resolved = new ArrayList<Object>(ml.size());
for (int i = 0; i < ml.size(); i++) {
@ -953,7 +975,9 @@ spring-context https://github.com/AmyliaY/spring-context-reading
return resolved;
}
// 解析 set 类型的属性
/**
* 解析 set 类型的属性
*/
private Set resolveManagedSet(Object argName, Set<?> ms) {
Set<Object> resolved = new LinkedHashSet<Object>(ms.size());
int i = 0;
@ -965,7 +989,9 @@ spring-context https://github.com/AmyliaY/spring-context-reading
return resolved;
}
// 解析 map 类型的属性
/**
* 解析 map 类型的属性
*/
private Map resolveManagedMap(Object argName, Map<?, ?> mm) {
Map<Object, Object> resolved = new LinkedHashMap<Object, Object>(mm.size());
// 递归解析 map 中每一个元素的 key 和 value
@ -977,11 +1003,24 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
return resolved;
}
}
```
至此，已经为依赖注入做好了准备，下面就该将 bean 对象设置到它所依赖的另一个 bean 的属性中去。AbstractPropertyAccessor 和其子类 BeanWrapperImpl 完成了依赖注入的详细过程。
## 8、AbstractPropertyAccessor 中的实现
至此，已经为依赖注入做好了准备，下面就该将 bean对象 设置到它所依赖的另一个 bean 的属性中去。AbstractPropertyAccessor 和其子类 BeanWrapperImpl 完成了依赖注入的详细过程。先看一下 AbstractPropertyAccessor 中的实现。
```java
public abstract class AbstractPropertyAccessor extends TypeConverterSupport implements ConfigurablePropertyAccessor {
/**
* setPropertyValues() 方法有多种重载，但最终都走的是
* setPropertyValues(PropertyValues pvs, boolean ignoreUnknown, boolean ignoreInvalid)重载方法
*/
public void setPropertyValues(Map<?, ?> map) throws BeansException {
setPropertyValues(new MutablePropertyValues(map));
}
public void setPropertyValues(PropertyValues pvs, boolean ignoreUnknown) throws BeansException {
setPropertyValues(pvs, ignoreUnknown, false);
}
public void setPropertyValues(PropertyValues pvs) throws BeansException {
setPropertyValues(pvs, false, false);
}
@ -996,7 +1035,7 @@ spring-context https://github.com/AmyliaY/spring-context-reading
try {
/**
* ！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！
* 走 BeanWrapperImpl 中的实现，也是 bean 属性值注入具体实现的入口
* 该方法走 BeanWrapperImpl 中的实现，这是 bean属性值注入 具体实现的入口
* ！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！
*/
setPropertyValue(pv);
@ -1019,18 +1058,20 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
}
// 如果遇到个别异常，则抛出复合异常
// 如果出现 PropertyAccessException 异常，则将这些异常积累起来放到一个集合中，然后一次性抛出！！！
// 这种抛异常的方式 在实际的开发中也时常使用，可以好好看一下，对比一下
if (propertyAccessExceptions != null) {
PropertyAccessException[] paeArray =
propertyAccessExceptions.toArray(new PropertyAccessException[propertyAccessExceptions.size()]);
throw new PropertyBatchUpdateException(paeArray);
}
}
}
```
## 9、BeanWrapperImpl 中的实现
最后看一下 BeanWrapperImpl 中的实现。
```java
public class BeanWrapperImpl extends AbstractPropertyAccessor implements BeanWrapper {
@Override
public void setPropertyValue(PropertyValue pv) throws BeansException {
// PropertyTokenHolder 是一个用于内部使用的内部类
@ -1064,17 +1105,17 @@ spring-context https://github.com/AmyliaY/spring-context-reading
/**
* ！！！！！！！！！！！！！！！！
* 实现属性值依赖注入的具体实现
* 依赖注入（将某个bean所依赖的值 注入到这个bean中） 的具体实现
* ！！！！！！！！！！！！！！！！
*/
@SuppressWarnings("unchecked")
private void setPropertyValue(PropertyTokenHolder tokens, PropertyValue pv) throws BeansException {
// PropertyTokenHolder 主要保存属性的名称、路径、以及集合的 size 等信息
// PropertyTokenHolder 是定义在 BeanWrapperImpl 中的内部类，主要保存属性的名称、路径、
// 以及集合的 size 等信息
String propertyName = tokens.canonicalName;
String actualName = tokens.actualName;
// 对集合类型的属性注入
// keys 是用来保存集合类型属性的 size
// 对集合类型的属性注入，PropertyTokenHolder 的 keys 是用来保存集合类型属性的 size
if (tokens.keys != null) {
// 将属性信息从 tokens 拷贝到 getterTokens
PropertyTokenHolder getterTokens = new PropertyTokenHolder();
@ -1284,7 +1325,7 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
pv.getOriginalPropertyValue().conversionNecessary = (valueToApply != originalValue);
}
// 根据 Java 的内省机制，获取属性的 setter(写方法) 方法
// 根据 Java 的内省机制，获取属性的 setter方法
final Method writeMethod = (pd instanceof GenericTypeAwarePropertyDescriptor ?
((GenericTypeAwarePropertyDescriptor) pd).getWriteMethodForActualAccess() :
pd.getWriteMethod());
@ -1343,27 +1384,35 @@ spring-context https://github.com/AmyliaY/spring-context-reading
}
}
}
}
```
终于完成了对 bean 的各种属性的依赖注入，在 bean 的实例化和依赖注入的过程中，需要依据 BeanDefinition 中的信息来递归地完成依赖注入。另外，在此过程中存在许多递归调用，一个递归是在上下文体系中查找需要的 bean 和创建 bean 的递归调用；另一个是在依赖注入时，通过递归调用容器的 getBean 方法，得到当前 bean 的依赖 bean，同时也触发对依赖 bean 的创建和注入；在对 bean 的属性进行依赖注入时，解析的过程也是递归的。这样，根据依赖关系，一层一层地完成 bean 的创建和注入，直到最后完成当前 bean 的创建。
至此，完成了对 bean 的各种属性的依赖注入，在 bean 的实例化和依赖注入的过程中，需要依据 BeanDefinition 中的信息来递归地完成依赖注入。另外，在此过程中存在许多递归调用，一个递归是在上下文体系中查找 当前bean依赖的bean 和创建 当前bean依赖的bean 的递归调用；另一个是在依赖注入时，通过递归调用容器的 getBean() 方法，得到当前 bean 的依赖 bean，同时也触发对依赖 bean 的创建和注入；在对 bean 的属性进行依赖注入时，解析的过程也是递归的。这样，根据依赖关系，从最末层的依赖bean开始，一层一层地完成 bean 的创建和注入，直到最后完成当前 bean 的创建。
## 最后补充一下通过 lazy-init 属性触发的依赖注入
lazy-init 触发的预实例化和依赖注入，发生在 IoC 容器完成对 BeanDefinition 的定位、载入、解析和注册之后。虽然会影响 IoC 容器初始化的性能，但确能有效提高应用第一次获取该 bean 的效率。
## lazy-init 属性触发的依赖注入
最后看一下 lazy-init 触发的预实例化和依赖注入，发生在 IoC 容器完成对 BeanDefinition 的定位、载入、解析和注册之后。通过牺牲 IoC 容器初始化的性能，来有效提升应用第一次获取该 bean 的效率。
lazy-init 实现的入口方法在我们前面解读过的 AbstractApplicationContext 的 refresh() 中，它是 IoC 容器正式启动的标志。
```java
public abstract class AbstractApplicationContext extends DefaultResourceLoader
implements ConfigurableApplicationContext, DisposableBean {
/**
* 容器初始化的过程：BeanDefinition 的 Resource 定位、BeanDefinition 的载入、BeanDefinition 的注册。
* BeanDefinition 的载入和 bean 的依赖注入是两个独立的过程，依赖注入一般发生在 应用第一次通过 getBean() 方法从容器获取 bean 时。
* 容器初始化的过程：
* 1、根据指定规则扫描指定目录，获取所有 用于配置bean的配置文件；
* 2、根据 Spring定义的规则，解析配置文件中的各个元素，将其封装成 IoC容器 可以装载的 BeanDefinition对象；
* 3、将封装好的 BeanDefinition 注册进 IoC容器。
*
* 另外需要注意的是，IoC 容器有一个预实例化的配置（即，将 AbstractBeanDefinition 中的 lazyInit 属性设为 true），使用户可以对容器的初始化
* 过程做一个微小的调控，lazyInit 设为 true 的 bean 将在容器初始化时进行依赖注入，而不会等到 getBean() 方法调用时才进行
* IoC容器的初始化 和 bean的依赖注入 是两个独立的过程，依赖注入一般发生在应用第一次通过 getBean()方法
* 从容器获取 bean 时。
* 另外需要注意的是，IoC容器 有一个预实例化的配置（即，将 <bean>元素 的 lazyInit属性 设为 false），
* 使该 <bean>元素对应的 bean可以提前实例化，而不用等到调用 getBean()方法 时才开始实例化。
*/
public void refresh() throws BeansException, IllegalStateException {
synchronized (this.startupShutdownMonitor) {
// 调用容器准备刷新的方法，获取容器的当前时间，同时给容器设置同步标识
prepareRefresh();
// 告诉子类启动 refreshBeanFactory() 方法，Bean 定义资源文件的载入从子类的 refreshBeanFactory() 方法启动开始
// 告诉子类启动 refreshBeanFactory() 方法，BeanDefinition 资源文件的载入从子类的
// refreshBeanFactory() 方法启动开始
ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();
// 为 BeanFactory 配置容器特性，例如类加载器、事件处理器等
@ -1373,7 +1422,7 @@ lazy-init 触发的预实例化和依赖注入，发生在 IoC 容器完成对 B
// 为容器的某些子类指定特殊的 BeanPost 事件处理器
postProcessBeanFactory(beanFactory);
// 调用所有注册的 BeanFactoryPostProcessor 的 Bean
// 调用所有注册的 BeanFactoryPostProcessor
invokeBeanFactoryPostProcessors(beanFactory);
// 为 BeanFactory 注册 BeanPost 事件处理器.
@ -1394,7 +1443,7 @@ lazy-init 触发的预实例化和依赖注入，发生在 IoC 容器完成对 B
/**
* ！！！！！！！！！！！！！！！！！！！！！
* 初始化 Bean，并对 lazy-init 属性进行处理
* 对配置了 lazy-init属性为true的bean 进行预实例化
* ！！！！！！！！！！！！！！！！！！！！！
*/
finishBeanFactoryInitialization(beanFactory);
@ -1415,16 +1464,18 @@ lazy-init 触发的预实例化和依赖注入，发生在 IoC 容器完成对 B
}
}
// 对配置了 lazy-init 属性的 Bean 进行预实例化处理
/**
* 对配置了 lazy-init属性为true的bean 进行预实例化
*/
protected void finishBeanFactoryInitialization(ConfigurableListableBeanFactory beanFactory) {
// 这是 Spring3 以后新加的代码，为容器指定一个转换服务 (ConversionService)
// 在对某些 Bean 属性进行转换时使用
// 在对某些 bean 属性进行转换时使用
if (beanFactory.containsBean(CONVERSION_SERVICE_BEAN_NAME) &&
beanFactory.isTypeMatch(CONVERSION_SERVICE_BEAN_NAME, ConversionService.class)) {
beanFactory.setConversionService(
/**
* ！！！！！！！！！！！！！！！！！！！！
* 在这里调用了 getBean() 方法，触发依赖注入
* 在这里 通过调用 getBean()方法，触发依赖注入
* ！！！！！！！！！！！！！！！！！！！！
*/
beanFactory.getBean(CONVERSION_SERVICE_BEAN_NAME, ConversionService.class));
@ -1441,8 +1492,8 @@ lazy-init 触发的预实例化和依赖注入，发生在 IoC 容器完成对 B
// 缓存容器中所有注册的 BeanDefinition 元数据，以防被修改
beanFactory.freezeConfiguration();
// 对配置了 lazy-init 属性的单态模式 Bean 进行预实例化处理
// 对配置了 lazy-init属性 的 单例bean 进行预实例化处理
beanFactory.preInstantiateSingletons();
}
}
```

24
docs/Spring/SpringMVC/IoC容器在Web环境中的启动.md
Unescape View File

@ -1,5 +1,5 @@
## 1 Web环境中的SpringMVC
在Web环境中，SpringMVC是建立在IoC容器基础上的。了解SpringMVC，首先要了解Spring的IoC容器是如何在Web环境中被载人并起作用的。
在 Web环境 中，SpringMVC 是建立在 IoC容器 基础上的。了解 SpringMVC，首先要了解 Spring 的 IoC容器 是如何在 Web环境 中被载入并起作用的。
Spring 的 IoC 是一个独立模块，它并不直接在 Web容器 中发挥作用，如果要在 Web环境 中使用 IoC容器，需要 Spring 为 IoC 设计一个启动过程，把 IoC容器 导入，并在 Web容器 中建立起来。具体说来，这个启动过程是和 Web容器 的启动过程集成在一起的。在这个过程中，一方面处理 Web容器 的启动，另一方面通过设计特定的 Web容器拦截器，将 IoC容器 载人到 Web环境 中来，并将其初始化。在这个过程建立完成以后，IoC容器 才能正常工作，而 SpringMVC 是建立在 IoC容器 的基础上的，这样才能建立起 MVC框架 的运行机制，从而响应从 Web容器 传递的 HTTP请求。
@ -28,7 +28,7 @@ web.xml是SpringMVC与Tomcat的接口部分。这个部署描述文件中，首
最后，作为 Spring MVC 的启动类，ContextLoaderListener 被定义为一个监听器，这个监听器是与 Web服务器 的生命周期相关联的，由 ContextLoaderListener监听器 负责完成 IoC容器 在 Web环境 中的启动工作。
DispatchServlet和ContextLoaderListener提供了在Web容器中对Spring的接口，也就是说，这些接口与Web容器耦合是通过ServletContext来实现的（ServletContext是容器和应用沟通的桥梁，从一定程度上讲ServletContext就是servlet规范的体现）。这个ServletContext为Spring的IoC容器提供了一个宿主环境，在宿主环境中，Spring MVC建立起一个IoC容器的体系。这个IoC容器体系是通过ContextLoaderListener的初始化来建立的，在建立IoC容器体系后，把DispatchServlet作为Spring MVC处理Web请求的转发器建立起来，从而完成响应HTTP请求的准备。有了这些基本配置，建立在IoC容器基础上的SpringMVC就可以正常地发挥作用了。下面我们看一下loC容器在Web容器中的启动代码实现。
DispatchServlet 和 ContextLoaderListener 提供了在 Web容器 中对 Spring 的接口，也就是说，这些接口与 Web容器 耦合是通过 ServletContext 来实现的（ServletContext 是容器和应用沟通的桥梁，从一定程度上讲 ServletContext 就是 servlet规范 的体现）。这个 ServletContext 为 Spring 的 IoC容器 提供了一个宿主环境，在宿主环境中，Spring MVC 建立起一个 IoC容器 的体系。这个 IoC容器体系 是通过 ContextLoaderListener 的初始化来建立的，在建立 IoC容器体系 后，把 DispatchServlet 作为 Spring MVC 处理 Web请求 的转发器建立起来，从而完成响应 HTTP请求 的准备。有了这些基本配置，建立在 IoC容器 基础上的 SpringMVC 就可以正常地发挥作用了。下面我们看一下 IoC容器 在 Web容器 中的启动代码实现。
## 2 IoC容器启动的基本过程
IoC容器 的启动过程就是建立上下文的过程，该上下文是与 ServletContext 相伴而生的，同时也是 IoC容器 在 Web应用环境 中的具体表现之一。由 ContextLoaderListener 启动的上下文为根上下文。在根上下文的基础上，还有一个与 Web MVC 相关的上下文用来保存控制器(DispatcherServlet)需要的 MVC对象，作为根上下文的子上下文，构成一个层次化的上下文体系。在 Web容器 中启动 Spring应用程序 时，首先建立根上下文，然后建立这个上下文体系，这个上下文体系的建立是由 ContextLoder 来完成的，其 UML时序图 如下图所示。
@ -40,8 +40,7 @@ IoC容器的启动过程就是建立上下文的过程，该上下文是与Servl
在 ContextLoader 中，完成了两个 IoC容器 建立的基本过程，一个是在 Web容器 中建立起 双亲IoC容器，另一个是生成相应的 WebApplicationContext 并将其初始化。
## 3 Web容器中的上下文设计
先从Web容器中的上下文入手，看看Web环境中的上下文设置有哪些特别之处，然后再
到ContextLoaderListener中去了解整个容器启动的过程。为了方便在Web环境中使用IoC容器，
先从 Web容器 中的上下文入手，看看 Web环境 中的上下文设置有哪些特别之处，然后再到 ContextLoaderListener 中去了解整个容器启动的过程。为了方便在 Web环境 中使用 IoC容器，
Spring 为 Web应用 提供了上下文的扩展接口 WebApplicationContext 来满足启动过程的需要，其继承关系如下图所示。
![avatar](/images/springMVC/WebApplicationContext接口的类继承关系.png)
@ -49,7 +48,7 @@ Spring为Web应用提供了上下文的扩展接口WebApplicationContext来满
在这个类继承关系中，可以从熟悉的 XmlWebApplicationContext 入手来了解它的接口实现。在接口设计中，最后是通过 ApplicationContex接口 与 BeanFactory接口 对接的，而对于具体的功能实现，很多都是封装在其基类 AbstractRefreshableWebApplicationContext 中完成的。
同样，在源代码中，也可以分析出类似的继承关系，在 WebApplicationContext 中可以看到相关的常量设计，比如 ROOT_ WEB_ APPLICATION_CONTEXT_ATTRIBUTE 等，这个常量是用来索引在 ServletContext 中存储的根上下文的。这个接口类定义的接口方法比较简单，在这个接口中，定义了一
个getServletContext方法，通过这个方法可以得到当前Web容器的Servlet上下文环境，通过
个 getServletContext()方法，通过这个方法可以得到当前 Web容器 的 Servlet上下文环境，通过
这个方法，相当于提供了一个 Web容器级别的 全局环境。
```java
public interface WebApplicationContext extends ApplicationContext {
@ -65,11 +64,11 @@ public interface WebApplicationContext extends ApplicationContext {
ServletContext getServletContext();
}
```
在启动过程中，Spring会使用一个默认的WebApplicationContext实现作为IoC容器，这个默认使用的IoC容器就是XmlWebApplicationContext，它继承了ApplicationContext，在ApplicationContext的基础上，增加了对Web环境和XML配置定义的处理。在XmlWebApplicationContext的初始化过程中，Web容器中的IoC容器被建立起来，从而在Web容器中建立起整个Spring应用。与前面博文中分析的IoC容器的初始化一样，这个过程也有loadBeanDefinition对BeanDefinition的载入。在Web环境中，对定位BeanDefinition的Resource有特别的要求，这个要求的处理体现在对getDefaultConfigLocations方法的处理中。这里使用了默认的BeanDefinition的配置路径，这个路径在XmlWebApplicationContext中作为一个常量定义好了，即/WEB-INF/applicationContext.xml。
在启动过程中，Spring 会使用一个默认的 WebApplicationContext 实现作为 IoC容器，这个默认使用的 IoC容器 就是 XmlWebApplicationContext，它继承了 ApplicationContext，在 ApplicationContext 的基础上，增加了对 Web环境 和 XML配置定义 的处理。在 XmlWebApplicationContext 的初始化过程中，Web容器 中的 IoC容器 被建立起来，从而在 Web容器 中建立起整个 Spring应用。与前面博文中分析的 IoC容器 的初始化一样，这个过程也有 loadBeanDefinition()方法 对 BeanDefinition 的载入。在 Web环境 中，对定位 BeanDefinition 的 Resource 有特别的要求，这个要求的处理体现在对 getDefaultConfigLocations()方法 的处理中。这里使用了默认的 BeanDefinition 的配置路径，这个路径在 XmlWebApplicationContext 中作为一个常量定义好了，即 /WEB-INF/applicationContext.xml。
```java
public class XmlWebApplicationContext extends AbstractRefreshableWebApplicationContext {
/** 若不指定其它文件，spring默认从"/WEB-INF/applicationContext.xml"目录文件 初始化IoC容器 */
/** 若不指定其它文件，Spring 默认从 "/WEB-INF/applicationContext.xml" 目录文件 初始化 IoC容器 */
public static final String DEFAULT_CONFIG_LOCATION = "/WEB-INF/applicationContext.xml";
/** 默认的配置文件在 /WEB-INF/ 目录下 */
@ -86,9 +85,8 @@ public class XmlWebApplicationContext extends AbstractRefreshableWebApplicationC
// 使用 XmlBeanDefinitionReader 对指定的 BeanFactory 进行解析
XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReader(beanFactory);
// 初始化beanDefinitionReader的属性，其中，设置ResourceLoader是因为
// XmlBeanDefinitionReader是DefaultResource的子类，所有这里同样会使用
// DefaultResourceLoader来定位BeanDefinition
// 初始化 beanDefinitionReader 的属性，其中，设置 ResourceLoader 是因为 XmlBeanDefinitionReader
// 是 DefaultResource 的子类，所有这里同样会使用 DefaultResourceLoader 来定位 BeanDefinition
beanDefinitionReader.setEnvironment(this.getEnvironment());
beanDefinitionReader.setResourceLoader(this);
beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this));
@ -129,7 +127,7 @@ public class XmlWebApplicationContext extends AbstractRefreshableWebApplicationC
}
}
```
从上面的代码中可以看到，在XmlWebApplicationContext中，基本的上下文功能都已经通过类的继承获得，这里需要处理的是，如何获取Bean定义信息，在这里，就转化为如何在Web容器环境中获得Bean定义信息。在获得Bean定义信息之后，后面的过程基本上就和前面分析的XmlFileSystemBeanFactory一样，是通过XmlBeanDefinitionReader来载人Bean定义信息的，最终完成整个上下文的初始化过程。
从上面的代码中可以看到，在 XmlWebApplicationContext 中，基本的上下文功能都已经通过类的继承获得，这里需要处理的是，如何获取 BeanDefinition信息，在这里，就转化为如何在 Web容器环境 中获得 BeanDefinition信息。在获得 BeanDefinition信息 之后，后面的过程基本上就和前面分析的 XmlFileSystemBeanFactory 一样，是通过 XmlBeanDefinitionReader 来载入 BeanDefinition信息 的，最终完成整个上下文的初始化过程。
## 4 ContextLoader的设计与实现
对于 Spring 承载的 Web应用 而言，可以指定在 Web应用程序 启动时载入 IoC容器（或者称为WebApplicationContext）。这个功能是由 ContextLoaderListener 来完成的，它是在 Web容器 中配置的监听器，会监听 Web容器 的启动，然后载入 IoC容器。这个 ContextLoaderListener 通过使用 ContextLoader 来完成实际的 WebApplicationContext，也就是 IoC容器 的初始化工作。这个 ContextLoader 就像 Spring应用程序 在 Web容器 中的启动器。这个启动过程是在 Web容器 中发生的，所以需要根据 Web容器 部署的要求来定义 ContextLoader，相关的配置在概述中已经看到了，这里就不重复了。
@ -219,8 +217,8 @@ public class ContextLoader {
ApplicationContext parent = loadParentContext(servletContext);
cwac.setParent(parent);
}
// 配置 并且初始化IoC容器，看到Refresh应该能想到AbstractApplicationContext
// 中的refresh()方法，猜到它是前面介绍的IoC容器的初始化入口
// 配置并初始化 IoC容器，看到下面方法中的 Refresh单词 应该能想到
// AbstractApplicationContext 中的 refresh()方法，猜到它是前面介绍的 IoC容器 的初始化入口
configureAndRefreshWebApplicationContext(cwac, servletContext);
}
}

63
docs/Spring/SpringMVC/SpringMVC的设计与实现.md
Unescape View File

@ -1,7 +1,7 @@
## 1 SpringMVC应用场景
在使用SpringMVC时，除了要在web.xml中配置ContextLoaderListener外，还要对DispatcherServlet进行配置。作为一个Servlet，这个DispatcherServlet实现的是Sun的J2EE核心模式中的前端控制器模式(Front Controller)， 作为一个前端控制器，所有的Web请求都需要通过它来处理，进行转发、匹配、数据处理后，并转由页面进行展现，因此这个DispatcerServlet可以看成是Spring MVC实现中最为核心的部分。
在使用 SpringMVC 时，除了要在 web.xml 中配置 ContextLoaderListener 外，还要对 DispatcherServlet 进行配置。作为一个 Servlet，这个 DispatcherServlet 实现的是 Sun 的 J2EE核心模式 中的 前端控制器模式(Front Controller)， 作为一个前端控制器，所有的 Web请求 都需要通过它来进行转发、匹配、数据处理，然后转由页面进行展现，因此这个 DispatcerServlet 可以看成是 SpringMVC实现 中最为核心的部分。
在Spring MVC中，对于不同的Web请求的映射需求，Spring MVC提供了不同的HandlerMapping的实现，可以让应用开发选取不同的映射策略。DispatcherSevlet默认了BeanNameUrlHandlerMapping作为映射策略实现。除了映射策略可以定制外，Spring MVC提供了各种Controller的实现来供应用扩展和使用，以应对不同的控制器使用场景，这些Controller控制器需要实现handleRequest接口方法，并返回ModelAndView对象。Spring MVC还提供了各种视图实现，比如常用的JSP视图。除此之外，Spring MVC还提供了拦截器供应用使用，允许应用对Web请求进行拦截，以及前置处理和后置处理。
在 SpringMVC 中，对于不同的 Web请求 的映射需求，SpringMVC 提供了不同的 HandlerMapping 的实现，可以让应用开发选取不同的映射策略。DispatcherSevlet 默认了 BeanNameUrlHandlerMapping 作为映射策略实现。除了映射策略可以定制外，SpringMVC 还提供了各种 Controller 的实现来供应用扩展和使用，以应对不同的控制器使用场景，这些 Controller控制器 需要实现 handleRequest()接口方法，并返回 ModelAndView对象。SpringMVC 还提供了各种视图实现，比如常用的 JSP视图。除此之外，SpringMVC 还提供了拦截器供应用使用，允许应用对 Web请求 进行拦截，以及前置处理和后置处理。
## 2 SpringMVC设计概览
在完成对 ContextLoaderListener 的初始化以后，Web容器 开始初始化 DispatcherServlet，这个初始化的启动与在 web.xml 中对载入次序的定义有关。DispatcherServlet 会建立自己的上下文来持有SpringMVC 的 Bean对象，在建立这个自己持有的 IoC容器 时，会**从 ServletContext 中得到根上下文**作为 DispatcherServlet 持有上下文的双亲上下文。有了这个根上下文，再对自己持有的上下文进行初始化，最后把自己持有的这个上下文保存到 ServletContext 中，供以后检索和使用。
@ -12,7 +12,7 @@
DispatcherServlet 通过继承 FrameworkServlet 和 HttpServletBean 而继承了 HttpServlet，通过使用Servlet API 来对 HTTP请求 进行响应，成为 SpringMVC 的前端处理器，同时成为 MVC模块 与 Web容器 集成的处理前端。
DispatcherServlet的工作大致可以分为两个部分：一个是初始化部分，由initServletBean()启动，通过initWebApplicationContext()方法最终调用DispatcherServlet的initStrategies()方法，在这个方法里，DispatcherServlet对MVC模块的其他部分进行了初始化，比如handlerMapping、ViewResolver等；另一个是对HTTP请求进行响应，作为一个Servlet，Web容器会调用Servlet的doGet()和doPost()方法，在经过FrameworkServlet的processRequest()简单处理后，会调用DispatcherServlet的doService()方法，在这个方法调用中封装了doDispatch()，这个doDispatch()是Dispatcher实现MVC模式的主要部分，下图为DispatcherServlet的处理过程时序图。
DispatcherServlet 的工作大致可以分为两个部分：一个是初始化部分，由 initServletBean()方法 启动，通过 initWebApplicationContext()方法 最终调用 DispatcherServlet 的 initStrategies()方法，在这个方法里，DispatcherServlet 对 MVC模块 的其他部分进行了初始化，比如 handlerMapping、ViewResolver 等；另一个是对 HTTP请求 进行响应，作为一个 Servlet，Web容器 会调用 Servlet 的doGet() 和 doPost()方法，在经过 FrameworkServlet 的 processRequest() 简单处理后，会调用 DispatcherServlet 的 doService()方法，在这个方法调用中封装了 doDispatch()，这个 doDispatch() 是 Dispatcher 实现 MVC模式 的主要部分，下图为 DispatcherServlet 的处理过程时序图。
![avatar](/images/springMVC/DispatcherServlet的处理过程.png)
@ -24,6 +24,7 @@ DispatcherServlet的工作大致可以分为两个部分：一个是初始化部
接着会执行 DispatcherServlet 持有的 IoC容器 的初始化过程，在这个初始化过程中，一个新的上下文被建立起来，这个 DispatcherServlet 持有的上下文被设置为根上下文的子上下文。一个 Web应用 中可以容纳多个 Servlet 存在；与此相对应，对于应用在 Web容器 中的上下体系，一个根上下文可以作为许多 Servlet上下文 的双亲上下文。了解 IoC 工作原理的读者知道，在向 IoC容器 getBean() 时，IoC容器 会首先向其双亲上下文去 getBean()，也就是说，在根上下文中定义的 Bean 是可以被各个 Servlet 持有的上下文得到和共享的。DispatcherServlet 持有的 上下文被建立起来以后，也需要和其他 IoC容器 一样完成初始化，这个初始化也是通过 refresh()方法 来完成的。最后，DispatcherServlet 给这个自己持有的上下文命名，并把它设置到 Web容器 的上下文中，这个名称和在 web.xml 中设置的 DispatcherServlet 的 Servlet名称 有关，从而保证了这个上下文在 Web环境上下文体系 中的唯一性。
```java
public abstract class HttpServletBean extends HttpServlet implements EnvironmentCapable, EnvironmentAware {
public final void init() throws ServletException {
if (logger.isDebugEnabled()) {
logger.debug("Initializing servlet '" + getServletName() + "'");
@ -54,6 +55,7 @@ public abstract class HttpServletBean extends HttpServlet implements Environment
public abstract class FrameworkServlet extends HttpServletBean {
/** 此 servlet 的 WebApplicationContext */
private WebApplicationContext webApplicationContext;
@ -232,7 +234,7 @@ public abstract class FrameworkServlet extends HttpServletBean {
wac.setParent(parent);
wac.setConfigLocation(getContextConfigLocation());
// 配置并且刷新wac
// 配置并且刷新 WebApplicationContext对象
configureAndRefreshWebApplicationContext(wac);
return wac;
@ -272,7 +274,7 @@ public abstract class FrameworkServlet extends HttpServletBean {
wac.setNamespace(getNamespace());
wac.addApplicationListener(new SourceFilteringListener(wac, new ContextRefreshListener()));
// 在刷新上下文的任何情况下，都将会调用wac环境的initPropertySources()方法。
// 在刷新上下文的任何情况下，都将会调用 此wac 的 env的 initPropertySources()方法。
// 在此处执行此方法，以确保在刷新上下文之前，servlet属性源 已准备就绪
ConfigurableEnvironment env = wac.getEnvironment();
if (env instanceof ConfigurableWebEnvironment) {
@ -288,7 +290,7 @@ public abstract class FrameworkServlet extends HttpServletBean {
}
}
```
这时候DispatcherServlet中的IoC容器已经建立起来了，这个IoC容器是 根上下文 的子容器。如果要查找一个由DispatcherServlet所持有的IoC容器来管理的Bean，系统会首先到 根上下文 中去查找。如果查找不到，才会到DispatcherServlet所管理的IoC容器去进行查找，这是由IoC容器getBean()的实现来决定的。通过一系列在Web容器中执行的动作，在这个上下文体系建立和初始化完毕的基础上，Spring MVC就可以发挥其作用了。下面来分析一下Spring MVC的具体实现。
这时候 DispatcherServlet 中的 IoC容器 已经建立起来了，这个 IoC容器 是 根上下文 的子容器。如果要查找一个由 DispatcherServlet 所持有的 IoC容器 来管理的 Bean，系统会首先到 根上下文 中去查找。如果查找不到，才会到 DispatcherServlet 所管理的 IoC容器 去进行查找，这是由 IoC容器 的 getBean() 的实现来决定的。通过一系列在 Web容器 中执行的动作，在这个上下文体系建立和初始化完毕的基础上，SpringMVC 就可以发挥其作用了。下面来分析一下 SpringMVC 的具体实现。
在前面分析 DispatchServlet 的初始化过程中可以看到，DispatchServlet 持有一个以自己的 Servlet名称 命名的 IoC容器。这个 IoC容器 是一个 WebApplicationContext对象，这个 IoC容器 建立起来以后，意味着 DispatcherServlet 拥有自己的 Bean定义空间，这为使用各个独立的 XML文件 来配置 MVC 中各个 Bean 创造了条件。由于在初始化结束以后，与 Web容器 相关的加载过程实际上已经完成了，SpringMVC 的具体实现和普通的 Spring应用程序 的实现并没有太大的差别。
@ -372,14 +374,12 @@ HandlerMappings完成对MVC中Controller的定义和配置，只不过在Web这
### 4.1 HandlerMapping的配置和设计原理
前面分析了 DispatcherServlet 对 SpringMVC框架 的初始化过程，在此基础上，我们再进一步分析 HandlerMapping 的实现原理，看看这个 MVC框架 中比较关键的控制部分是如何实现的。
在初始化完成时，在上下文环境中已定义的所有HandlerMapping都已经被加载了，这些加载的handlerMappings被放在一个List中并被排序，存储着HTTP请求对应的映射数据。这个List中的每一个元素都对应着一个具体handlerMapping的配置，一般每一个handlerMapping
可以持有一系列从URL请求到Controller的映射，而Spring MVC提供了一系列的HandlerMapping实现。
在初始化完成时，在上下文环境中已定义的所有 HandlerMapping 都已经被加载了，这些加载的 handlerMappings 被放在一个 List 中并被排序，存储着 HTTP请求 对应的映射数据。这个 List 中的每一个元素都对应着一个具体 handlerMapping 的配置，一般每一个 handlerMapping 可以持有一系列从 URL请求 到 Controller 的映射，而 SpringMVC 提供了一系列的 HandlerMapping 实现。
![avatar](/images/springMVC/HandlerMapping组件.png)
以SimpleUrlHandlerMapping这个handlerMapping为例来分析HandlerMapping的设计与实现。在SimpleUrlHandlerMapping中，定义了一个map来 持有 一系列的映射关系。通过这些在HandlerMapping中定义的映射关系，即这些URL请求和控制器的对应关系，使Spring MVC
应用可以根据HTTP请求确定一个对应的Controller。具体来说，这些映射关系是通过接口HandlerMapping来封装的，在HandlerMapping接 口中定义了一个getHandler方法，通过这个方法，可以获得与HTTP请求对应的HandlerExecutionChain，在这个HandlerExecutionChain
中，封装了具体的Controller对象。
以 SimpleUrlHandlerMapping 为例来分析 HandlerMapping 的设计与实现。在 SimpleUrlHandlerMapping 中，定义了一个 Map 来持有一系列的映射关系。通过这些在 HandlerMapping 中定义的映射关系，即这些 URL请求 和控制器的对应关系，使 SpringMVC
应用 可以根据 HTTP请求 确定一个对应的 Controller。具体来说，这些映射关系是通过 HandlerMapping接口 来封装的，在 HandlerMapping接口 中定义了一个 getHandler()方法，通过这个方法，可以获得与 HTTP请求 对应的 HandlerExecutionChain，在这个 HandlerExecutionChain 中，封装了具体的 Controller对象。
```java
public interface HandlerMapping {
@ -396,15 +396,13 @@ public interface HandlerMapping {
String PRODUCIBLE_MEDIA_TYPES_ATTRIBUTE = HandlerMapping.class.getName() + ".producibleMediaTypes";
/**
* 返回的这个HandlerExecutionChain不但持有handler本身，还包括了处理这个HTTP请求的拦截器
* 返回的这个 HandlerExecutionChain 不但持有 handler本身，还包括了处理这个 HTTP请求 的拦截器链
*/
HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception;
}
```
这个HandlerExecutionChain的实现看起来比较简洁，它持有一个Interceptor链和一个handler对象，这个handler对象实际上就是HTTP请求对应的Controller，在持有这个handler对象的同时，还在HandlerExecutionChain中设置了一个拦截器链，通过这个拦截器链中的拦截器,
可以为handler对象提供功能的增强。要完成这些工作，需要对拦截器链和handler都进行配置，这些配置都是在HandlerExecutionChain的初始化函数中完成的。为了维护这个拦截器链和handler，HandlerExecutionChain还提供了一系列与拦截器链维护相关的操作，比如，为拦
截器链增加拦截器的addInterceptor()方法。
这个 HandlerExecutionChain 的实现看起来比较简洁，它持有一个 拦截器链(HandlerInterceptor对象列表) 和一个 handler对象，这个 handler对象 实际上就是 HTTP请求 对应的 Controller，在持有这个 handler对象 的同时，还在 HandlerExecutionChain 中设置了一个拦截器链，通过这个拦截器链中的拦截器，可以为 handler对象 提供功能的增强。要完成这些工作，需要对拦截器链和 handler 都进行配置，这些配置都是在 HandlerExecutionChain 的初始化函数中完成的。为了维护这个拦截器链和 handler，HandlerExecutionChain 还提供了一系列与拦截器链维护相关的操作，比如，为拦截器链增加拦截器的 addInterceptor()方法。
```java
public class HandlerExecutionChain {
@ -496,12 +494,13 @@ public class HandlerExecutionChain {
}
}
```
HandlerExecutionChain中定义的Handler和Interceptor需要在定义HandlerMapping时配置好，例如对具体的SimpleURLHandlerMapping，要做的就是根据URL映射的方式，注册Handler和Interceptor，从而维护一个反映这种映射关系的handlerMap。当需要匹配HTTP请求时，需要查询这个handlerMap中的信息来得到对应的HandlerExecutionChain。这些信息是什么时候配置好的呢?这里有一个注册过程，这个注册过程在容器对Bean进行依赖注入时发生，它实际上是通过一个Bean的postProcessor()来完成的。以SimpleHandlerMapping为例，需要注意的是，这里用到了对容器的回调，只有SimpleHandlerMapping是ApplicationContextAware的子类才能启动这个注册过程。这个注册过程完成的是反映URL和Controller之间映射关系的handlerMap的建立。
HandlerExecutionChain 中定义的 Handler 和 HandlerInterceptor[]属性 需要在定义 HandlerMapping 时配置好，例如对具体的 SimpleURLHandlerMapping，要做的就是根据 URL映射 的方式，注册 Handler 和 HandlerInterceptor[]，从而维护一个反映这种映射关系的 handlerMap。当需要匹配 HTTP请求 时，需要查询这个 handlerMap 中的信息来得到对应的 HandlerExecutionChain。这些信息是什么时候配置好的呢?这里有一个注册过程，这个注册过程在容器对 Bean 进行依赖注入时发生，它实际上是通过一个 Bean 的 postProcessor() 来完成的。以 SimpleHandlerMapping 为例，需要注意的是，这里用到了对容器的回调，只有 SimpleHandlerMapping 是 ApplicationContextAware 的子类才能启动这个注册过程。这个注册过程完成的是反映 URL 和 Controller 之间映射关系的 handlerMap 的建立。
![avatar](/images/springMVC/SimpleUrlHandlerMapping的继承关系.png)
```java
public class SimpleUrlHandlerMapping extends AbstractUrlHandlerMapping {
@Override
public void initApplicationContext() throws BeansException {
super.initApplicationContext();
@ -535,10 +534,10 @@ public class SimpleUrlHandlerMapping extends AbstractUrlHandlerMapping {
}
}
```
这个SimpleUrlHandlerMapping注册过程的完成，很大一部分需要它的基类来配合，这个基类就是AbstractUrlHandlerMapping。在AbstractUrlHandlerMapping的处理过程中，如果使用Bean的名称作为映射，那么直接从容器中获取这个HTTP映射对应的Bean，然后还要对不同的URL配置进行解析处理，比如在HTTP请求中配置成“/”和通配符“/*” 的URL，以及正常的URL请求，完成这个解析处理过程以后，会
把URL和handler作为键值对放到一个handlerMap中去。
这个 SimpleUrlHandlerMapping 注册过程的完成，很大一部分需要它的基类来配合，这个基类就是 AbstractUrlHandlerMapping。在 AbstractUrlHandlerMapping 的处理过程中，如果使用 Bean 的名称作为映射，那么直接从容器中获取这个 HTTP映射 对应的 Bean，然后还要对不同的 URL配置 进行解析处理，比如在 HTTP请求 中配置成 “/” 和 通配符“/*” 的 URL，以及正常的 URL请求，完成这个解析处理过程以后，会把 URL 和 handler 作为键值对放到一个 handlerMap 中去。
```java
public abstract class AbstractHandlerMapping extends WebApplicationObjectSupport implements HandlerMapping, Ordered {
/**
* 为给定的 URL路径 注册指定的 handler处理程序
*/
@ -622,18 +621,18 @@ public abstract class AbstractHandlerMapping extends WebApplicationObjectSupport
}
}
```
这里的handlerMap是一个HashMap，其中保存了URL请求和Controller的映射关系，这个handlerMap是在AbstractUrlHandlerMapping中定义的（ Map<String, object> handlerMap = new LinkedHashMap<String, object>() ），这个配置好URL请求和handler映射数据的handlerMap，为Spring MVC响应HTTP请求准备好了基本的映射数据，根据这个handlerMap以及设置于其中的映射数据，可以方便地由
URL请求得到它所对应的handler。有了这些准备工作，Spring MVC就可以等待HTTP请求的到来了。
这里的 handlerMap 是一个 HashMap，其中保存了 “URL请求” --> “Controller对象” 的映射关系，这个 handlerMap 是在 AbstractUrlHandlerMapping 中定义的（ Map<String, object> handlerMap = new LinkedHashMap<String, object>() ），这个配置好 URL请求 和 handler映射数据 的 handlerMap，为 SpringMVC 响应 HTTP请求 准备好了基本的映射数据，根据这个 handlerMap 以及设置于其中的映射数据，可以方便地由 URL请求 得到它所对应的 handler。有了这些准备工作，SpringMVC 就可以等待 HTTP请求 的到来了。
### 4.2 使用HandlerMapping完成请求的映射处理
继续通过SimpleUrlHandlerMapping的实现来分析HandlerMapping的接口方法getHandler()，该方法会根据初始化时得到的映射关系来生成DispatcherServlet需要的HandlerExecutionChain，也就是说，这个getHandler()方法是实际使用HandlerMapping完成请求的映射处理的地方。在前面的HandlerExecutionChain的执行过程中，首先在AbstractHandlerMapping中启动getHandler的调用。
继续通过 SimpleUrlHandlerMapping的实现 来分析 HandlerMapping 的 接口方法getHandler()，该方法会根据初始化时得到的映射关系来生成 DispatcherServlet 需要的 HandlerExecutionChain，也就是说，这个 getHandler()方法 是实际使用 HandlerMapping 完成请求的映射处理的地方。在前面的 HandlerExecutionChain 的执行过程中，首先在 AbstractHandlerMapping 中启动 getHandler() 的调用。
```java
public abstract class AbstractHandlerMapping extends WebApplicationObjectSupport implements HandlerMapping, Ordered {
/**
* 查找给定请求的 handler，如果找不到特定的 handler，则返回到 defaultHandler
*/
public final HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {
// 模板方法模式
// 这里用到了模板方法模式，getHandler() 是一个模板方法，定义了流程，getHandlerInternal() 则是
// 一个抽象方法，交由子类实现
Object handler = getHandlerInternal(request);
// 如果找不到特定的 handler，则取 defaultHandler
if (handler == null) {
@ -643,8 +642,8 @@ public abstract class AbstractHandlerMapping extends WebApplicationObjectSupport
if (handler == null) {
return null;
}
// 如果该handler是String类型的，说明它是一个beanname
// 根据该beanname从IoC容器中获取真正的handler对象
// 如果该 handler 是 String类型的，说明它是一个 beanName
// 根据该 beanName 从 IoC容器 中获取真正的 handler对象
if (handler instanceof String) {
String handlerName = (String) handler;
handler = getApplicationContext().getBean(handlerName);
@ -658,7 +657,7 @@ public abstract class AbstractHandlerMapping extends WebApplicationObjectSupport
```java
public abstract class AbstractUrlHandlerMapping extends AbstractHandlerMapping {
/**
* 查找给定请求的URL路径 对应的handler
* 查找 给定请求的URL 对应的 handler
*/
@Override
protected Object getHandlerInternal(HttpServletRequest request) throws Exception {
@ -765,10 +764,10 @@ DispatcherServlet是Spring MVC框架中非常重要的一个类，不但建立
```java
public class DispatcherServlet extends FrameworkServlet {
/** 此servlet使用的HandlerMappings列表 */
/** 此 DispatcherServlet 使用的 HandlerMapping对象列表 */
private List<HandlerMapping> handlerMappings;
/** 此servlet使用的HandlerAdapter列表 */
/** 此 DispatcherServlet 使用的 HandlerAdapter对象列表 */
private List<HandlerAdapter> handlerAdapters;
@ -858,8 +857,8 @@ public class DispatcherServlet extends FrameworkServlet {
processedRequest = checkMultipart(request);
multipartRequestParsed = processedRequest != request;
// 2.取得处理当前请求的controller，这里也称为hanlder处理器，这里并不是
// 直接返回controller，而是返回的HandlerExecutionChain请求处理器链对象，
// 2.取得处理当前请求的 Controller对象，这里也称为 hanlder处理器，这里并不是
// 直接返回 controller对象，而是返回的 HandlerExecutionChain请求处理器链对象，
// 该对象封装了 handler 和 interceptors
mappedHandler = getHandler(processedRequest, false);
// 如果 handler 为空,则返回 404
@ -868,7 +867,7 @@ public class DispatcherServlet extends FrameworkServlet {
return;
}
// 3. 获取处理request的处理器适配器handler adapter
// 3. 获取处理 request 的处理器适配器 HandlerAdapter
HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());
// 获取 请求方式，如：GET, POST, PUT
@ -1010,7 +1009,3 @@ public class SimpleControllerHandlerAdapter implements HandlerAdapter {
}
```
经过上面一系列的处理，得到了 handler对象，接着就可以开始调用 handler对象 中的 HTTP响应动作了。在 handler 中封装了应用业务逻辑，由这些逻辑对 HTTP请求 进行相应的处理，生成需要的数据，并把这些数据封装到 ModelAndView对象 中去，这个 ModelAndView 的数据封装是 SpringMVC框架 的要求。对 handler 来说， 这些都是通过调用 handler()方法 中的 handleRequest()方法 来触发完成的。在得到 ModelAndView对象 以后，这个 ModelAndView对象 会被交给 MVC模式 中的视图类，由视图类对 ModelAndView对象 中的数据进行呈现。

4
docs/Spring/SpringTransaction/Spring与事务处理.md
Unescape View File

@ -10,9 +10,9 @@ Spring事务处理模块的类层次结构如下图所示。
从上图可以看到，Spring事务处理模块 是通过 AOP功能 来实现声明式事务处理的，比如事务属性的配置和读取，事务对象的抽象等。因此，在 Spring事务处理 中，可以通过设计一个 TransactionProxyFactoryBean 来使用 AOP功能，通过这个 TransactionProxyFactoryBean 可以生成 Proxy代理对象，在这个代理对象中，通过 TransactionInterceptor 来完成对代理方法的拦截，正是这些 AOP 的拦截功能，将事务处理的功能编织进来。
对于具体的事务处理实现，比如事务的生成、提交、回滚、挂起等，由于不同的底层数据库有不同的支持方式，因此，在Spring事务处理中，对主要的事务实现做了一个抽象和适配。适配的具体事务处理器包括：对DataSource数据源的事务处理支持，对Hibernate数据源的事务处理支持，对JDO数据源的事务处理支持，对JPA和JTA等数据源的事务处理支持等。这一系列的事务处理支持，都是通过设计PlatformTransactionManager、AbstractPlatforTransactionManager以及一系列具体事务处理器来实现的，而PlatformTransactionManager又实现了TransactionInterceptor接口，通过这样一个接口实现设计，就把这一系列的事务处理的实现与前面提到的TransactionProxyFactoryBean结合起来，从而形成了一个Spring声明式事务处理的设计体系。
对于具体的事务处理实现，比如事务的生成、提交、回滚、挂起等，由于不同的底层数据库有不同的支持方式，因此，在 Spring事务处理中，对主要的事务实现做了一个抽象和适配。适配的具体事务处理器包括：对 DataSource数据源 的事务处理支持，对 Hibernate数据源 的事务处理支持，对 JDO数据源 的事务处理支持，对 JPA 和 JTA 等数据源的事务处理支持等。这一系列的事务处理支持，都是通过设计 PlatformTransactionManager、AbstractPlatformTransactionManager 以及一系列具体事务处理器来实现的，而 PlatformTransactionManager 又实现了 TransactionInterceptor接口，通过这样一个接口实现设计，就把这一系列的事务处理的实现与前面提到的 TransactionProxyFactoryBean 结合起来，从而形成了一个 Spring声明式事务处理 的设计体系。
## 2 Spring事务处理 的应用场景
Spring 作为应用平台或框架的设计出发点是支持 POJO的开发，这点在实现事务处理的时候也不例外。在 Spring 中，它既支持编程式事务管理方式，又支持声明式事务处理方式，在使用 Spring 处理事务的时候，声明式事务处理通常比编程式事务管理更方便些。
Spring对应用的支持，一方面，通过声明式事务处理，将事务处理的过程和业务代码分离出来。这种声明方式实际上是通过AOP的方式来完成的。显然，Spring已经把那些通用的事务处理过程抽象出来，并通过AOP的方式进行封装，然后用声明式的使用方式交付给客户使用。这样，应用程序可以更简单地管理事务，并且只需要关注事务的处理策略。另一方面，应用在选择数据源时可能会采取不同的方案，当以Spring作为平台时，Spring在应用和具体的数据源之间，搭建一个中间平台，通过这个中间平台，解耦应用和具体数据源之间的绑定，并且，Spring为常用的数据源的事务处理支持提供了一系列的TransactionManager。这些Spring封装好的TransactionManager为应用提供了很大的方便，因为在这些具体事务处理过程中，已经根据底层的实现，封装好了事务处理的设置以及与特定数据源相关的特定事务处理过程，这样应用在使用不同的数据源时，可以做到事务处理的即开即用。这样的另一个好处是，如果应用有其他的数据源事务处理需要，Spring也提供了一种一致的方式。这种有机的事务过程抽象和具体的事务处理相结合的设计，是我们在日常的开发中非常需要模仿学习的。
Spring 对应用的支持，一方面，通过声明式事务处理，将事务处理的过程和业务代码分离出来。这种声明方式实际上是通过 AOP 的方式来完成的。显然，Spring 已经把那些通用的事务处理过程抽象出来，并通过 AOP 的方式进行封装，然后用声明式的使用方式交付给客户使用。这样，应用程序可以更简单地管理事务，并且只需要关注事务的处理策略。另一方面，应用在选择数据源时可能会采取不同的方案，当以 Spring 作为平台时，Spring 在应用和具体的数据源之间，搭建一个中间平台，通过这个中间平台，解耦应用和具体数据源之间的绑定，并且，Spring 为常用的数据源的事务处理支持提供了一系列的 TransactionManager。这些 Spring 封装好的 TransactionManager 为应用提供了很大的方便，因为在这些具体事务处理过程中，已经根据底层的实现，封装好了事务处理的设置以及与特定数据源相关的特定事务处理过程，这样应用在使用不同的数据源时，可以做到事务处理的即开即用。这样的另一个好处是，如果应用有其他的数据源事务处理需要， Spring 也提供了一种一致的方式。这种 有机的事务过程抽象 和 具体的事务处理 相结合的设计，是我们在日常的开发中非常需要模仿学习的。事务处理，将事务处理的过程和业务代码分离出来。这种声明方式实际上是通过AOP的方式来完成的。显然，Spring已经把那些通用的事务处理过程抽象出来，并通过AOP的方式进行封装，然后用声明式的使用方式交付给客户使用。这样，应用程序可以更简单地管理事务，并且只需要关注事务的处理策略。另一方面，应用在选择数据源时可能会采取不同的方案，当以Spring作为平台时，Spring在应用和具体的数据源之间，搭建一个中间平台，通过这个中间平台，解耦应用和具体数据源之间的绑定，并且，Spring为常用的数据源的事务处理支持提供了一系列的TransactionManager。这些Spring封装好的TransactionManager为应用提供了很大的方便，因为在这些具体事务处理过程中，已经根据底层的实现，封装好了事务处理的设置以及与特定数据源相关的特定事务处理过程，这样应用在使用不同的数据源时，可以做到事务处理的即开即用。这样的另一个好处是，如果应用有其他的数据源事务处理需要，Spring也提供了一种一致的方式。这种有机的事务过程抽象和具体的事务处理相结合的设计，是我们在日常的开发中非常需要模仿学习的。

547
docs/Spring/SpringTransaction/Spring事务处理的设计与实现.md
Unescape View File

@ -1 +1,546 @@
努力编写中...
## 1 事务处理的编程式使用
```java
TransactionDefinition td = new DefaultTransactionDefinition();
// transactionManager 是某一个具体的 PlatformTransactionManager实现类 的对象
TransactionStatus ts = transactionManager.getTransaction(td);
try {
// 这里是需要进行事务处理的方法调用
}
catch (Exception e) {
transactionManager.rollback(ts);
throw e;
}
transactionManager.commit(ts);
```
在使用编程式事务处理的过程中，利用 DefaultTransactionDefinition对象 来持有事务处理属性。同时，在创建事务的过程中得到一个 TransactionStatus对象，然后通过直接调用 transactionManager对象 的 commit() 和 rollback()方法 来完成事务处理。在这个编程式使用事务管理的过程中，没有看到框架特性的使用，非常简单和直接，很好地说明了事务管理的基本实现过程，以及在 Spring事务处理实现 中涉及一些主要的类，比如 TransationStatus、TransactionManager 等，对这些类的使用与声明式事务处理的最终实现是一样的。
与编程式使用事务管理不同，在使用声明式事务处理的时候，因为涉及 Spring框架 对事务处理的统一管理，以及对并发事务和事务属性的处理，所以采用的是一个比较复杂的处理过程，但复杂归复杂，这个过程对使用声明式事务处理的应用来说，基本上是不可见的，而是由 Spring框架 来完成的。有了这些背景铺垫和前面对 AOP封装事务处理 的了解，下面来看看 Spring 是如何提供声明式事务处理的，Spring 在这个相对较为复杂的过程中封装了什么。这层封装包括在事务处理中事务的创建、提交和回滚等比较核心的操作。
## 2 事务的创建
作为声明式事务处理实现的起始点，需要注意 TransactionInterceptor拦截器 的 invoke()回调 中使用的 createTransactionIfNecessary()方法，这个方法是在 TransactionInterceptor 的基类 TransactionAspectSupport 中实现的。为了了解这个方法的实现，先分析一下 TransactionInterceptor 的基类实现 TransactionAspectSupport，并以这个方法的实现为入口，了解 Spring 是如何根据当前的事务状态和事务属性配置完成事务创建的。
这个 TransactionAspectSupport 的 createTransactionIfNecessary()方法 作为事务创建的入口，其具体的实现时序如下图所示。在 createTransactionIfNecessary()方法 的调用中，会向 AbstractTransactionManager 执行 getTransaction()方法，这个获取 Transaction事务对象 的过程，在 AbstractTransactionManager实现 中需要对事务的情况做出不同的处理，然后，创建一个 TransactionStatus，并把这个 TransactionStatus 设置到对应的 TransactionInfo 中去，同时将 TransactionInfo 和当前的线程绑定，从而完成事务的创建过程。createTransactionIfNeccessary()方法 调用中，可以看到两个重要的数据对象 TransactionStatus 和 TransactionInfo 的创建，这两个对象持有的数据是事务处理器对事务进行处理的主要依据，对这两个对象的使用贯穿着整个事务处理的全过程。
![avatar](images/springTransaction/调用createTransactionIfNecessary()方法的时序图.png)
```java
public abstract class TransactionAspectSupport implements BeanFactoryAware, InitializingBean {
/**
* 根据给定的方法和类，在必要时创建事务
*/
@Deprecated
protected TransactionInfo createTransactionIfNecessary(Method method, Class targetClass) {
// 根据给定的方法和类获取 TransactionAttribute，
// 如果 TransactionAttribute 为空，则该方法是非事务性的
TransactionAttribute txAttr = getTransactionAttributeSource().getTransactionAttribute(method, targetClass);
// 使用确定的事务管理器
PlatformTransactionManager tm = determineTransactionManager(txAttr);
return createTransactionIfNecessary(tm, txAttr, methodIdentification(method, targetClass));
}
/**
* 根据给定的 TransactionAttribute 创建事务
*/
@SuppressWarnings("serial")
protected TransactionInfo createTransactionIfNecessary(
PlatformTransactionManager tm, TransactionAttribute txAttr, final String joinpointIdentification) {
// 如果未指定名称，则使用方法特征作为事务名称
if (txAttr != null && txAttr.getName() == null) {
txAttr = new DelegatingTransactionAttribute(txAttr) {
@Override
public String getName() {
return joinpointIdentification;
}
};
}
// TransactionStatus 封装了事务执行的状态信息
TransactionStatus status = null;
if (txAttr != null) {
if (tm != null) {
// 根据定义好的 事务方法配置信息TransactionAttribute，通过
// 平台事务管理器 PlatformTransactionManager 创建事务，同时返回
// TransactionStatus 来记录当前的事务状态，包括已经创建的事务
status = tm.getTransaction(txAttr);
}
else {
if (logger.isDebugEnabled()) {
logger.debug("Skipping transactional joinpoint [" + joinpointIdentification +
"] because no transaction manager has been configured");
}
}
}
// 准备 TransactionInfo，TransactionInfo对象 封装了事务处理的配置信息以及 TransactionStatus
return prepareTransactionInfo(tm, txAttr, joinpointIdentification, status);
}
protected TransactionInfo prepareTransactionInfo(PlatformTransactionManager tm,
TransactionAttribute txAttr, String joinpointIdentification, TransactionStatus status) {
TransactionInfo txInfo = new TransactionInfo(tm, txAttr, joinpointIdentification);
if (txAttr != null) {
if (logger.isTraceEnabled()) {
logger.trace("Getting transaction for [" + txInfo.getJoinpointIdentification() + "]");
}
// 为 TransactionInfo 设置 TransactionStatus，TransactionStatus 持有管理事务处理
// 需要的数据，如：transaction对象
// 如果不兼容的 TX 已经存在，事务管理器将标记错误
txInfo.newTransactionStatus(status);
}
else {
if (logger.isTraceEnabled())
logger.trace("Don't need to create transaction for [" + joinpointIdentification +
"]: This method isn't transactional.");
}
// 这里把当前的 TransactionInfo 与线程绑定，同时在 TransactionInfo 中由一个变量来保存以前
// 的 TransactionInfo，这样就持有了一连串与事务处理相关的 TransactionInfo
// 虽然不一定要创建新的事务，但总会在请求事务时创建 TransactionInfo
txInfo.bindToThread();
return txInfo;
}
}
```
在以上的处理过程之后，可以看到，具体的事务创建可以交给事务处理器来完成。在事务的创建过程中，已经为事务的管理做好了准备，包括记录事务处理状态，以及绑定事务信息和线程等。下面到事务处理器中去了解一下更底层的事务创建过程。
createTransactionIfNecessary()方法 通过调用 PlatformTransactionManager 的 getTransaction()方法，生成一个 TransactionStatus对象，封装了底层事务对象的创建。可以看到，AbstractPlatformTransactionManager 提供了创建事务的模板，这个模板会被具体的事务处理器所使用。从下面的代码中可以看到，AbstractPlatformTransactionManager 会根据事务属性配置和当前进程绑定的事务信息，对事务是否需要创建，怎样创建 进行一些通用的处理，然后把事务创建的底层工作交给具体的事务处理器完成。尽管具体的事务处理器完成事务创建的过程各不相同，但是不同的事务处理器对事务属性和当前进程事务信息的处理都是相同的，在 **AbstractPlatformTransactionManager** 中完成了该实现，这个实现过程是 Spring 提供统一事务处理的一个重要部分。
```java
public abstract class AbstractPlatformTransactionManager implements PlatformTransactionManager, Serializable {
//---------------------------------------------------------------------
// 实现了 PlatformTransactionManager接口 的方法
// 这里用了一个 模板方法模式，doGetTransaction(), doBegin() 都是交由子类实现的抽象方法
//---------------------------------------------------------------------
public final TransactionStatus getTransaction(TransactionDefinition definition) throws TransactionException {
// doGetTransaction() 是抽象方法，Transaction对象 的取得由具体的事务管理器
// 实现，比如：DataSourceTransactionManager
Object transaction = doGetTransaction();
// 缓存 debug标志，以避免重复检查
boolean debugEnabled = logger.isDebugEnabled();
if (definition == null) {
// 如果没有给出事务定义，则使用默认值
definition = new DefaultTransactionDefinition();
}
// 检查当前线程是否已经存在事务，如果已经存在事务，则根据事务属性中定义的 事务传播属性配置
// 来处理事务的产生
if (isExistingTransaction(transaction)) {
// 对当前线程中已经有事务存在的情况进行处理，结果封装在 TransactionStatus 中
return handleExistingTransaction(definition, transaction, debugEnabled);
}
// 检查 definition 中 timeout属性 的设置
if (definition.getTimeout() < TransactionDefinition.TIMEOUT_DEFAULT) {
throw new InvalidTimeoutException("Invalid transaction timeout", definition.getTimeout());
}
// 当前没有事务存在，这时需要根据事务属性设置来创建事务
// 这里可以看到对事务传播属性配置的处理，比如：MANDATORY、REQUIRED、REQUIRES_NEW、NESTED等
if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_MANDATORY) {
throw new IllegalTransactionStateException(
"No existing transaction found for transaction marked with propagation 'mandatory'");
}
else if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_REQUIRED ||
definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_REQUIRES_NEW ||
definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_NESTED) {
SuspendedResourcesHolder suspendedResources = suspend(null);
if (debugEnabled) {
logger.debug("Creating new transaction with name [" + definition.getName() + "]: " + definition);
}
try {
boolean newSynchronization = (getTransactionSynchronization() != SYNCHRONIZATION_NEVER);
// 将要返回的 DefaultTransactionStatus对象，封装了事务执行情况
DefaultTransactionStatus status = newTransactionStatus(
definition, transaction, true, newSynchronization, debugEnabled, suspendedResources);
// 创建事务，由具体的事务管理器来完成，如：DataSourceTransactionManager、HibernateTransactionManager
doBegin(transaction, definition);
prepareSynchronization(status, definition);
return status;
}
catch (RuntimeException ex) {
resume(null, suspendedResources);
throw ex;
}
catch (Error err) {
resume(null, suspendedResources);
throw err;
}
}
else {
boolean newSynchronization = (getTransactionSynchronization() == SYNCHRONIZATION_ALWAYS);
return prepareTransactionStatus(definition, null, true, newSynchronization, debugEnabled, null);
}
}
}
```
从上面的代码中可以看到，AbstractTransactionManager 提供的创建事务的实现模板，在这个模板的基础上，具体的事务处理器需要定义自己的实现来完成底层的事务创建工作，比如需要实现 isExistingTransaction() 和 doBegin()方法。关于这些由具体事务处理器实现的方法会在下面结合具体的事务处理器实现，如：DataSourceTransactionManager、HibernateTransactionManager进行分析。
事务创建的结果是生成一个 TransactionStatus对象， 通过这个对象来保存事务处理需要的基本信息，这个对象与前面提到过的 TransactionInfo对象 联系在一起， TransactionStatus 是 TransactionInfo 的一个属性，然后会把 TransactionInfo 保存在 ThreadLocal对象 里，这样当前线程可以通过 ThreadLocal对象 取得 TransactionInfo，以及与这个事务对应的 TransactionStatus对象，从而把事务的处理信息与调用事务方法的当前线程绑定起来。在 AbstractPlatformTransactionManager 创建事务的过程中，可以看到 TransactionStatus 的创建过程。
```java
public abstract class AbstractPlatformTransactionManager implements PlatformTransactionManager, Serializable {
/**
* 通过给定的参数，创建一个 TransactionStatus实例
*/
protected DefaultTransactionStatus newTransactionStatus(
TransactionDefinition definition, Object transaction, boolean newTransaction,
boolean newSynchronization, boolean debug, Object suspendedResources) {
// 这里判断是不是新事务，如果是新事务，需要把事务属性存放到当前线程中
// TransactionSynchronizationManager 维护了一系列的 ThreadLocal变量
// 来保持事务属性，比如，并发事务隔离级别，是否有活跃的事务等
boolean actualNewSynchronization = newSynchronization &&
!TransactionSynchronizationManager.isSynchronizationActive();
// 把结果记录在 DefaultTransactionStatus对象 中并返回
return new DefaultTransactionStatus(
transaction, newTransaction, actualNewSynchronization,
definition.isReadOnly(), debug, suspendedResources);
}
}
```
新事务的创建是比较好理解的，这里需要根据事务属性配置进行创建。所谓创建，首先是把创建工作交给具体的事务处理器来完成，比如 DataSourceTransactionManager，把创建的事务对象在 TransactionStatus 中保存下来，然后将其他的事务属性和 线程ThreadLocal变量 进行绑定。
相对于创建全新事务的另一种情况是：在创建当前事务时，线程中已经有事务存在了。这种情况同样需要处理，在声明式事务处理中，在当前线程调用事务方法的时候，就会考虑事务的创建处理，这个处理在方法 handleExistingTransaction() 中完成。这里对现有事务的处理，会涉及事务传播属性的具体处理，比如 PROPAGATION_NOT_SUPPORTED、PROPAGATION_ REQUIRES_ NEW等。
```java
public abstract class AbstractPlatformTransactionManager implements PlatformTransactionManager, Serializable {
/**
* 为存在的事务创建一个 TransactionStatus实例
*/
private TransactionStatus handleExistingTransaction(
TransactionDefinition definition, Object transaction, boolean debugEnabled)
throws TransactionException {
// PROPAGATION_NEVER 表示 以非事务方式执行，如果当前存在事务，则抛出异常
if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_NEVER) {
throw new IllegalTransactionStateException(
"Existing transaction found for transaction marked with propagation 'never'");
}
// PROPAGATION_NOT_SUPPORTED 表示 以非事务方式执行操作，如果当前存在事务，就把当前事务挂起
if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_NOT_SUPPORTED) {
if (debugEnabled) {
logger.debug("Suspending current transaction");
}
Object suspendedResources = suspend(transaction);
boolean newSynchronization = (getTransactionSynchronization() == SYNCHRONIZATION_ALWAYS);
// 注意这里的参数，transaction 为 null，newTransaction 为 false，这意味着事务方法不需要
// 放在事务环境中执行，同时挂起事务的信息记录也保存在 TransactionStatus 中，这里包括了
// 进程ThreadLocal 对事务信息的记录
return prepareTransactionStatus(
definition, null, false, newSynchronization, debugEnabled, suspendedResources);
}
// PROPAGATION_REQUIRES_NEW 表示 新建事务，如果当前存在事务，把当前事务挂起
if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_REQUIRES_NEW) {
if (debugEnabled) {
logger.debug("Suspending current transaction, creating new transaction with name [" +
definition.getName() + "]");
}
SuspendedResourcesHolder suspendedResources = suspend(transaction);
try {
boolean newSynchronization = (getTransactionSynchronization() != SYNCHRONIZATION_NEVER);
// 挂起事务的信息记录保存在 TransactionStatus 中，这里包括了 进程ThreadLocal 对事务信息的记录
DefaultTransactionStatus status = newTransactionStatus(
definition, transaction, true, newSynchronization, debugEnabled, suspendedResources);
doBegin(transaction, definition);
prepareSynchronization(status, definition);
return status;
}
catch (RuntimeException beginEx) {
resumeAfterBeginException(transaction, suspendedResources, beginEx);
throw beginEx;
}
catch (Error beginErr) {
resumeAfterBeginException(transaction, suspendedResources, beginErr);
throw beginErr;
}
}
// PROPAGATION_NESTED 表示 如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，
// 则执行与 PROPAGATION_REQUIRED 类似的操作
if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_NESTED) {
if (!isNestedTransactionAllowed()) {
throw new NestedTransactionNotSupportedException(
"Transaction manager does not allow nested transactions by default - " +
"specify 'nestedTransactionAllowed' property with value 'true'");
}
if (debugEnabled) {
logger.debug("Creating nested transaction with name [" + definition.getName() + "]");
}
if (useSavepointForNestedTransaction()) {
// 在 Spring 管理的事务中 创建事务保存点
DefaultTransactionStatus status =
prepareTransactionStatus(definition, transaction, false, false, debugEnabled, null);
status.createAndHoldSavepoint();
return status;
}
else {
boolean newSynchronization = (getTransactionSynchronization() != SYNCHRONIZATION_NEVER);
DefaultTransactionStatus status = newTransactionStatus(
definition, transaction, true, newSynchronization, debugEnabled, null);
doBegin(transaction, definition);
prepareSynchronization(status, definition);
return status;
}
}
if (debugEnabled) {
logger.debug("Participating in existing transaction");
}
// 这里判断 在当前事务方法中的属性配置 与已有事务的属性配置是否一致，如果不一致，
// 那么不执行事务方法 并抛出异常
if (isValidateExistingTransaction()) {
if (definition.getIsolationLevel() != TransactionDefinition.ISOLATION_DEFAULT) {
Integer currentIsolationLevel = TransactionSynchronizationManager.getCurrentTransactionIsolationLevel();
if (currentIsolationLevel == null || currentIsolationLevel != definition.getIsolationLevel()) {
Constants isoConstants = DefaultTransactionDefinition.constants;
throw new IllegalTransactionStateException("Participating transaction with definition [" +
definition + "] specifies isolation level which is incompatible with existing transaction: " +
(currentIsolationLevel != null ?
isoConstants.toCode(currentIsolationLevel, DefaultTransactionDefinition.PREFIX_ISOLATION) :
"(unknown)"));
}
}
if (!definition.isReadOnly()) {
if (TransactionSynchronizationManager.isCurrentTransactionReadOnly()) {
throw new IllegalTransactionStateException("Participating transaction with definition [" +
definition + "] is not marked as read-only but existing transaction is");
}
}
}
// 返回 DefaultTransactionStatus，注意 第三个参数false 代表当前事务方法没有使用新的事务
boolean newSynchronization = (getTransactionSynchronization() != SYNCHRONIZATION_NEVER);
return prepareTransactionStatus(definition, transaction, false, newSynchronization, debugEnabled, null);
}
}
```
## 3 事务的挂起
事务的挂起牵涉线程与事务处理信息的保存，下面看一下事务挂起的实现。
```java
public abstract class AbstractPlatformTransactionManager implements PlatformTransactionManager, Serializable {
/**
* 挂起给定的事务。先挂起事务同步，然后委托给 doSuspend()方法，子类一般会重写该方法。
* 该方法返回的 SuspendedResourcesHolder对象，会作为参数传递给 TransactionStatus
*/
protected final SuspendedResourcesHolder suspend(Object transaction) throws TransactionException {
if (TransactionSynchronizationManager.isSynchronizationActive()) {
List<TransactionSynchronization> suspendedSynchronizations = doSuspendSynchronization();
try {
Object suspendedResources = null;
// 把挂起事务的处理交给具体事务处理器去完成，如果具体的事务处理器不支持事务挂起，
// 就抛出异常
if (transaction != null) {
suspendedResources = doSuspend(transaction);
}
// 这里在线程中保存与事务处理有关的信息，并重置线程中相关的 ThreadLocal变量
String name = TransactionSynchronizationManager.getCurrentTransactionName();
TransactionSynchronizationManager.setCurrentTransactionName(null);
boolean readOnly = TransactionSynchronizationManager.isCurrentTransactionReadOnly();
TransactionSynchronizationManager.setCurrentTransactionReadOnly(false);
Integer isolationLevel = TransactionSynchronizationManager.getCurrentTransactionIsolationLevel();
TransactionSynchronizationManager.setCurrentTransactionIsolationLevel(null);
boolean wasActive = TransactionSynchronizationManager.isActualTransactionActive();
TransactionSynchronizationManager.setActualTransactionActive(false);
return new SuspendedResourcesHolder(
suspendedResources, suspendedSynchronizations, name, readOnly, isolationLevel, wasActive);
}
// 若doSuspend()方法出现RuntimeException异常或Error错误，则初始的事务依然存在
catch (RuntimeException ex) {
doResumeSynchronization(suspendedSynchronizations);
throw ex;
}
catch (Error err) {
doResumeSynchronization(suspendedSynchronizations);
throw err;
}
}
else if (transaction != null) {
Object suspendedResources = doSuspend(transaction);
return new SuspendedResourcesHolder(suspendedResources);
}
else {
return null;
}
}
}
```
基于以上内容，就可以完成声明式事务处理的创建了。声明式事务处理能使事务处理应用的开发变得简单，但是简单的背后，蕴含着平台付出的许多努力。
## 4 事务的提交
下面来看看事务提交是如何实现的。有了前面的对事务创建的分析，下面来分析一下在 Spring 中，声明式事务处理的事务提交是如何完成的。事务提交的调用入口是 TransactionInteceptor 的 invoke()方法，事务提交的具体实现则在其基类 TransactionAspectSupport 的 commitTransactionAfterReturning(TransactionInfo txInfo)方法 中，其中的参数 txInfo 是创建事务时生成的。同时，Spring 的事务管理框架生成的 TransactionStatus对象 就包含在 TransactionInfo对象 中。这个 commitTransactionAfterReturning()方法 在 TransactionInteceptor 的实现部分是比较简单的，它通过直接调用事务处理器来完成事务提交。
```java
public abstract class TransactionAspectSupport implements BeanFactoryAware, InitializingBean {
/**
* 在事务方法成功调用后执行，若出现异常，则不执行。如果不创建事务，则不执行任何操作。
*/
protected void commitTransactionAfterReturning(TransactionInfo txInfo) {
if (txInfo != null && txInfo.hasTransaction()) {
if (logger.isTraceEnabled()) {
logger.trace("Completing transaction for [" + txInfo.getJoinpointIdentification() + "]");
}
txInfo.getTransactionManager().commit(txInfo.getTransactionStatus());
}
}
}
```
与前面分析事务的创建过程一样，我们需要到事务管理器中去看看事务是如何提交的。同样，在 AbstractPlatformTransactionManager 中也有一个模板方法支持具体的事务管理器对事务提交的实现，这个模板方法的实现与前面我们看到的 getTransaction() 很像。
```java
public abstract class AbstractPlatformTransactionManager implements PlatformTransactionManager, Serializable {
/**
* 处理实际提交的事务，这是一个模板方法，其中的 doCommit() 是一个交由子类实现的抽象方法
*/
private void processCommit(DefaultTransactionStatus status) throws TransactionException {
try {
boolean beforeCompletionInvoked = false;
try {
// 事务提交的准备工作由具体的事务管理器来完成
prepareForCommit(status);
triggerBeforeCommit(status);
triggerBeforeCompletion(status);
beforeCompletionInvoked = true;
boolean globalRollbackOnly = false;
if (status.isNewTransaction() || isFailEarlyOnGlobalRollbackOnly()) {
globalRollbackOnly = status.isGlobalRollbackOnly();
}
// 嵌套事务的处理
if (status.hasSavepoint()) {
if (status.isDebug()) {
logger.debug("Releasing transaction savepoint");
}
status.releaseHeldSavepoint();
}
// 如果当前事务是一个新事务，调用具体事务处理器的 doCommit() 实现；否则，
// 不提交，由已经存在的事务来完成提交
else if (status.isNewTransaction()) {
if (status.isDebug()) {
logger.debug("Initiating transaction commit");
}
// 该实现由具体的事务管理器来完成
doCommit(status);
}
// 如果我们有一个全局仅回滚标记，但仍然没有从 commit 中获得相应的异常，
// 则抛出 UnexpectedRollbackException
if (globalRollbackOnly) {
throw new UnexpectedRollbackException(
"Transaction silently rolled back because it has been marked as rollback-only");
}
}
catch (UnexpectedRollbackException ex) {
// can only be caused by doCommit
triggerAfterCompletion(status, TransactionSynchronization.STATUS_ROLLED_BACK);
throw ex;
}
catch (TransactionException ex) {
// can only be caused by doCommit
if (isRollbackOnCommitFailure()) {
doRollbackOnCommitException(status, ex);
}
else {
triggerAfterCompletion(status, TransactionSynchronization.STATUS_UNKNOWN);
}
throw ex;
}
catch (RuntimeException ex) {
if (!beforeCompletionInvoked) {
triggerBeforeCompletion(status);
}
doRollbackOnCommitException(status, ex);
throw ex;
}
catch (Error err) {
if (!beforeCompletionInvoked) {
triggerBeforeCompletion(status);
}
doRollbackOnCommitException(status, err);
throw err;
}
// 触发器 afterCommit()回调，其中抛出的异常已传播到调用方，但该事务仍被视为已提交
try {
triggerAfterCommit(status);
}
finally {
triggerAfterCompletion(status, TransactionSynchronization.STATUS_COMMITTED);
}
}
finally {
cleanupAfterCompletion(status);
}
}
}
```
可以看到，事务提交的准备都是由具体的事务处理器来实现的。当然，对这些事务提交的处理，需要通过对 TransactionStatus 保存的事务处理的相关状态进行判断。提交过程涉及 AbstractPlatformTransactionManager 中的 doCommit() 和 prepareForCommit()方法，它们都是抽象方法，都在具体的事务处理器中完成实现，在下面对具体事务处理器的实现原理的分析中，可以看到对这些实现方法的具体分析。
## 5 事务的回滚
```java
public abstract class AbstractPlatformTransactionManager implements PlatformTransactionManager, Serializable {
/**
* 处理实际的事务回滚
*/
private void processRollback(DefaultTransactionStatus status) {
try {
try {
triggerBeforeCompletion(status);
// 嵌套事务的回滚处理
if (status.hasSavepoint()) {
if (status.isDebug()) {
logger.debug("Rolling back transaction to savepoint");
}
status.rollbackToHeldSavepoint();
}
// 当前事务调用方法中，新建事务的回滚处理
else if (status.isNewTransaction()) {
if (status.isDebug()) {
logger.debug("Initiating transaction rollback");
}
doRollback(status);
}
// 当前事务调用方法中，没有新建事务的回滚处理
else if (status.hasTransaction()) {
if (status.isLocalRollbackOnly() || isGlobalRollbackOnParticipationFailure()) {
if (status.isDebug()) {
logger.debug("Participating transaction failed - marking existing transaction as rollback-only");
}
doSetRollbackOnly(status);
}
// 由线程中的前一个事务来处理回滚，这里不执行任何操作
else {
if (status.isDebug()) {
logger.debug("Participating transaction failed - letting transaction originator decide on rollback");
}
}
}
else {
logger.debug("Should roll back transaction but cannot - no transaction available");
}
}
catch (RuntimeException ex) {
triggerAfterCompletion(status, TransactionSynchronization.STATUS_UNKNOWN);
throw ex;
}
catch (Error err) {
triggerAfterCompletion(status, TransactionSynchronization.STATUS_UNKNOWN);
throw err;
}
triggerAfterCompletion(status, TransactionSynchronization.STATUS_ROLLED_BACK);
}
finally {
cleanupAfterCompletion(status);
}
}
}
```
以上对事务的创建、提交和回滚的实现原理进行了分析，这些过程的实现都比较复杂，一方面 这些处理会涉及很多事务属性的处理；另一方面 会涉及事务处理过程中状态的设置，同时在事务处理的过程中，有许多处理也需要根据相应的状态来完成。这样看来，在实现事务处理的基本过程中就会产生许多事务处理的操作分支。
但总的来说，在事务执行的实现过程中，作为执行控制的 TransactionInfo对象 和 TransactionStatus对象 特别值得我们注意，比如它们如何与线程进行绑定，如何记录事务的执行情况等。如果大家在配置事务属性时有什么疑惑，不妨直接看看这些事务属性的处理过程，通过对这些实现原理的了解，可以极大地提高对这些事务处理属性使用的理解程度。

158
docs/Spring/SpringTransaction/Spring事务管理器的设计与实现.md
Unescape View File

@ -0,0 +1,158 @@
## 1 Spring事务处理的应用场景
下面，我们以 DataSourceTransactionManager事务管理器 为例，看一下在具体的事务管理器中如何实现事务创建、提交和回滚这些底层的事务处理操作。DataSourceTransationManager 和其他事务管理器一样，如 JtaTransactionManager，JpaTransactionManager 和 JdoTransactionManager，都继承自 AbstractPlatformManager，作为一个基类，AbstractPlatfromManager 封装了 Spring事务处理 中通用的处理部分，比如事务的创建、提交、回滚，事务状态和信息的处理，与线程的绑定等，有了这些通用处理的支持，对于具体的事务管理器而言，它们只需要处理和具体数据源相关的组件设置就可以了，比如在 HibernateTransactionManager 中，就只需要配置好和 Hibnernate事务处理 相关的接口以及相关的设置。所以，从 PlatformTransactionManager组件 的设计关系上，我们也可以看到，Spring事务处理 的主要过程是分两个部分完成的，通用的事务处理框架是在 AbstractPlatformManager 中完成，而 Spring 的事务接口与数据源实现的接口，多半是由具体的事务管理器来完成，它们都是作为 AbstractPlatformManager 的子类来是使用的。
可以看到，在 PlatformTransactionManager组件 的设计中 ，通过 PlatformTransactionManager接口 设计了一系列与事务处理息息相关的接口方法，如 getTransaction()、commit()、rollback() 这些和事务处理相关的统一接口。对于这些接口的实现，很大一部分是由 AbstractTransactionManager抽象类 来完成的，这个类中的 doGetTransaction()、doCommit() 等方法和 PlatformTransactionManager 的方法对应，实现的是事务处理中相对通用的部分。在这个 AbstractPlatformManager 下，为具体的数据源配置了不同的事务处理器，以处理不同数据源的事务处理，从而形成了一个从抽象到具体的事务处理中间平台设计，使应用通过声明式事务处理，即开即用事务处理服务，隔离那些与特定的数据源相关的具体实现。
![avatar](/images/springTransaction/PlatformTransactionManager组件的设计.png)
## 2 DataSourceTransactionManager的实现
我们先看一下 DataSourceTransactionManager，在这个事务管理器中，它的实现直接与事务处理的底层实现相关。在事务开始的时候，会调用 doBegin()方法，首先会得到相对应的 Connection，然后可以根据事务设置的需要，对 Connection 的相关属性进行配置，比如将 Connection 的 autoCommit功能 关闭，并对像 TimeoutInSeconds 这样的事务处理参数进行设置，最后通过 TransactionSynchronizationManager 来对资源进行绑定。
从下面的代码中可以看到，DataSourceTransactionManager 作为 AbstractPlatformTransactionManager 的子类，在 AbstractPlatformTransactionManager 中已经为事务实现设计好了一系列的模板方法，比如 事务的提交、回滚处理等。在 DataSourceTransactionManager 中， 可以看到对模板方法中一些抽象方法的具体实现。例如，由 DataSourceTransactionManager 的 doBegin()方法 实现负责事务的创建工作。具体来说，如果使用 DataSource 创建事务，最终通过设置 Connection 的 autoCommit属性 来对事务处理进行配置。在实现过程中，需要把数据库的 Connection 和当前的线程进行绑定。对于事务的提交和回滚，都是通过直接调用 Connection 的提交和回滚来完成的，在这个实现过程中，如何取得事务处理场景中的 Connection对象，也是一个值得注意的地方。
上面介绍了使用 DataSourceTransactionManager 实现事务创建、提交和回滚的过程，基本上与单独使用 Connection 实现事务处理是一样的，也是通过设置 autoCommit属性，调用 Connection 的 commit() 和 rollback()方法 来完成的。而我们在声明式事务处理中看到的那些事务处理属性，并不在 DataSourceTransactionManager 中完成，这和我们在前面分析中看到的是一致的。
![avatar](/images/springTransaction/PlatformTransactionManager组件的设计.png)
```java
public class DataSourceTransactionManager extends AbstractPlatformTransactionManager
implements ResourceTransactionManager, InitializingBean {
/** 持有 javax.sql.DataSource对象 */
private DataSource dataSource;
/**
* 这里是产生 Transaction对象 的地方，为 Transaction 的创建提供服务，对数据库而言，
* 事务工作是由 Connection 来完成的。这里把数据库的 Connection对象 放到了 ConnectionHolder 中，
* 然后封装到一个 DataSourceTransactionObject对象 中，在这个封装过程中增加了许多为事务处理服务的
* 控制数据
*/
@Override
protected Object doGetTransaction() {
DataSourceTransactionObject txObject = new DataSourceTransactionObject();
txObject.setSavepointAllowed(isNestedTransactionAllowed());
// 获取与当前线程绑定的 数据库Connection，这个 Connection 在第一个事务开始
// 的地方与线程绑定
ConnectionHolder conHolder =
(ConnectionHolder) TransactionSynchronizationManager.getResource(this.dataSource);
txObject.setConnectionHolder(conHolder, false);
return txObject;
}
/**
* 判断是否存在活跃的事务，由 ConnectionHolder 的 transactionActive属性 来控制
*/
@Override
protected boolean isExistingTransaction(Object transaction) {
DataSourceTransactionObject txObject = (DataSourceTransactionObject) transaction;
return (txObject.getConnectionHolder() != null && txObject.getConnectionHolder().isTransactionActive());
}
/**
* 这里是处理事务开始的地方，在这里设置隔离级别，但忽略超时
*/
@Override
protected void doBegin(Object transaction, TransactionDefinition definition) {
DataSourceTransactionObject txObject = (DataSourceTransactionObject) transaction;
Connection con = null;
try {
if (txObject.getConnectionHolder() == null ||
txObject.getConnectionHolder().isSynchronizedWithTransaction()) {
Connection newCon = this.dataSource.getConnection();
if (logger.isDebugEnabled()) {
logger.debug("Acquired Connection [" + newCon + "] for JDBC transaction");
}
txObject.setConnectionHolder(new ConnectionHolder(newCon), true);
}
txObject.getConnectionHolder().setSynchronizedWithTransaction(true);
con = txObject.getConnectionHolder().getConnection();
Integer previousIsolationLevel = DataSourceUtils.prepareConnectionForTransaction(con, definition);
txObject.setPreviousIsolationLevel(previousIsolationLevel);
// 这里是 数据库Connection 完成事务处理的重要配置，需要把 autoCommit属性 关掉
if (con.getAutoCommit()) {
txObject.setMustRestoreAutoCommit(true);
if (logger.isDebugEnabled()) {
logger.debug("Switching JDBC Connection [" + con + "] to manual commit");
}
con.setAutoCommit(false);
}
txObject.getConnectionHolder().setTransactionActive(true);
int timeout = determineTimeout(definition);
if (timeout != TransactionDefinition.TIMEOUT_DEFAULT) {
txObject.getConnectionHolder().setTimeoutInSeconds(timeout);
}
// 把当前的 数据库Connection 与线程绑定
if (txObject.isNewConnectionHolder()) {
TransactionSynchronizationManager.bindResource(getDataSource(), txObject.getConnectionHolder());
}
}
catch (Throwable ex) {
DataSourceUtils.releaseConnection(con, this.dataSource);
throw new CannotCreateTransactionException("Could not open JDBC Connection for transaction", ex);
}
}
/**
* 事务提交的具体实现
*/
@Override
protected void doCommit(DefaultTransactionStatus status) {
// 取得 Connection 以后，通过Connection 进行提交
DataSourceTransactionObject txObject = (DataSourceTransactionObject) status.getTransaction();
Connection con = txObject.getConnectionHolder().getConnection();
if (status.isDebug()) {
logger.debug("Committing JDBC transaction on Connection [" + con + "]");
}
try {
con.commit();
}
catch (SQLException ex) {
throw new TransactionSystemException("Could not commit JDBC transaction", ex);
}
}
/**
* 事务提交的具体实现，通过 Connection对象 的 rollback()方法 实现
*/
@Override
protected void doRollback(DefaultTransactionStatus status) {
DataSourceTransactionObject txObject = (DataSourceTransactionObject) status.getTransaction();
Connection con = txObject.getConnectionHolder().getConnection();
if (status.isDebug()) {
logger.debug("Rolling back JDBC transaction on Connection [" + con + "]");
}
try {
con.rollback();
}
catch (SQLException ex) {
throw new TransactionSystemException("Could not roll back JDBC transaction", ex);
}
}
}
```
上面介绍了使用 DataSourceTransactionManager 实现事务创建、提交和回滚的过程，基本上与单独使用 Connection 实现事务处理是一样的，也是通过设置 autoCommit属性，调用 Connection 的 commit() 和 rollback()方法 来完成的。看到这里，大家一定会觉得非常的熟悉。而我们在声明式事务处理中看到的那些事务处理属性，并不在 DataSourceTransactionManager 中完成，这和我们在前面分析中看到的是一致的。
## 3 小结
总体来说，从声明式事务的整个实现中我们看到，声明式事务处理完全可以看成是一个具体的 Spring AOP应用。从这个角度来看，Spring事务处理 的实现本身就为应用开发者提供了一个非常优秀的 AOP应用 参考实例。在 Spring 的声明式事务处理中，采用了 IoC容器 的 Bean配置 为事务方法调用提供事务属性设置，从而为应用对事务处理的使用提供方便。
有了声明式的使用方式，可以把对事务处理的实现与应用代码分离出来。从 Spring实现 的角度来看，声明式事务处理的大致实现过程是这样的：在为事务处理配置好 AOP 的基础设施(比如，对应的 Proxy代理对象 和 事务处理Interceptor拦截器对象)之后，首先需要完成对这些事务属性配置的读取，这些属性的读取处理是在 TransactionInterceptor 中实现的，在完成这些事务处理属性的读取之后，Spring 为事务处理的具体实现做好了准备。可以看到，Spring声明式事务处理 的过程同时也是一个整合事务处理实现到 Spring AOP 和 IoC容器 中去的过程。我们在整个过程中可以看到下面一些要点，在这些要点中，体现了对 Spring框架 的基本特性的灵活使用。
- 如何封装各种不同事务处理环境下的事务处理，具体来说，作为应用平台的 Spring，它没法对应用使用什么样的事务处理环境做出限制，这样，对应用户使用的不同的事务处理器，Spring事务处理平台 都需要为用户提供服务。这些事务处理实现包括在应用中常见的 DataSource 的 Connection、Hibermate 的 Transaction等，Spring事务处理 通过一种统一的方式把它们封装起来，从而实现一个通用的事务处理过程，实现这部分事务处理对应用透明，使应用即开即用。
- 如何读取事务处理属性值，在事务处理属性正确读取的基础上，结合事务处理代码，从而完成在既定的事务处理配置下，事务处理方法的实现。
- 如何灵活地使用 Spring AOP框架，对事务处理进行封装，提供给应用即开即用的声明式事务处理功能。
在这个过程中，有几个 Spring事务处理 的核心类是我们需要关注的。其中包括 **TransactionInterceptor**，它是使用 AOP 实现声明式事务处理的拦截器，封装了 Spring 对声明式事务处理实现的基本过程；还包括 TransactionAttributeSource 和 **TransactionAttribute** 这两个类，它们封装了对声明式事务处理属性的识别，以及信息的读入和配置。我们看到的 TransactionAttribute对象，可以视为对事务处理属性的数据抽象，如果在使用声明式事务处理的时候，应用没有配置这些属性，Spring 将为用户提供 DefaultTransactionAttribute对象，该对象提供了默认的事务处理属性设置。
在事务处理过程中，可以看到 **TransactionInfo** 和 **TransactionStatus** 这两个对象，它们是存放事务处理信息的主要数据对象，它们通过与线程的绑定来实现事务的隔离性。具体来说，TransactionInfo对象 本身就像是一个栈，对应着每一次事务方法的调用，它会保存每一次事务方法调用的事务处理信息。值得注意的是，在 TransactionInfo对象 中，它持有 TransactionStatus对象，这个 TransactionStatus 是非常重要的。由这个 TransactionStatus 来掌管事务执行的详细信息，包括具体的事务对象、事务执行状态、事务设置状态等。
在事务的创建、启动、提交和回滚的过程中，都需要与这个 TransactionStatus对象 中的数据打交道。在准备完这些与事务管理有关的数据之后，具体的事务处理是由 事务处理器TransactionManager 来完成的。在事务处理器完成事务处理的过程中，与具体事务处理器无关的操作都被封装到 AbstractPlatformTransactionManager 中实现了。这个抽象的事务处理器为不同的具体事务处理器提供了通用的事务处理模板，它封装了在事务处理过程中，与具体事务处理器无关的公共的事务处理部分。我们在具体的事务处理器(比如 DataSourceTransactionManager 和 HibernateTransactionManager)的实现中可以看到，最为底层的事务创建、挂起、提交、回滚操作。
在 Spring 中，也可以通过编程式的方法来使用事务处理器，以帮助我们处理事务。在编程式的事务处理使用中, TransactionDefinition 是定义事务处理属性的类。对于事务处理属性，Spring 还提供了一个默认的事务属性 DefaultTransactionDefinition 来供用户使用。这种事务处理方式在实现上看起来比声明式事务处理要简单，但编程式实现事务处理却会造成事务处理与业务代码的紧密耦合，因而不经常被使用。在这里，我们之所以举编程式使用事务处理的例子，是因为通过了解编程式事务处理的使用，可以清楚地了解 Spring 统一实现事务处理的大致过程。
有了这个背景，结合对声明式事务处理实现原理的详细分析，比如在声明式事务处理中，使用 AOP 对事务处理进行封装，对事务属性配置进行的处理，与线程绑定从而处理事务并发，并结合事务处理器的使用等，能够在很大程度上提高我们对整个 Spring事务处理实现 的理解。

162
docs/Spring/SpringTransaction/Spring声明式事务处理.md
Unescape View File

@ -19,7 +19,7 @@
public class TransactionProxyFactoryBean extends AbstractSingletonProxyFactoryBean
implements BeanFactoryAware {
/** 事务拦截器，通过AOP来发挥作用，spring在此拦截器中封装了 事务处理实现 */
/** 事务拦截器，通过 AOP 来发挥作用，Spring 在此拦截器中封装了事务处理实现 */
private final TransactionInterceptor transactionInterceptor = new TransactionInterceptor();
/** 切面 */
@ -36,7 +36,7 @@ public class TransactionProxyFactoryBean extends AbstractSingletonProxyFactoryBe
/**
* 创建 AOP 对事务处理的 advisor
* 本方法在IoC容器完成Bean的依赖注入时，通过initializeBean方法被调用
* 本方法在 IoC容器 完成 Bean的依赖注入时，通过 initializeBean()方法 被调用
*/
@Override
protected Object createMainInterceptor() {
@ -46,7 +46,7 @@ public class TransactionProxyFactoryBean extends AbstractSingletonProxyFactoryBe
return new DefaultPointcutAdvisor(this.pointcut, this.transactionInterceptor);
}
else {
// 如果没定义，则使用spring默认的切面，使用TransactionAttributeSourceAdvisor
// 如果没定义，则使用 Spring默认的切面，使用 TransactionAttributeSourceAdvisor
// 作为通知器，并配置拦截器
return new TransactionAttributeSourceAdvisor(this.transactionInterceptor);
}
@ -154,7 +154,7 @@ public abstract class AbstractSingletonProxyFactoryBean extends ProxyConfig
}
}
```
DefaultAopProxyFactory创建AOP Proxy的过程在前面分析AOP的实现原理时已分析过，这里就不再重复了。可以看到，通过以上的一系列步骤，Spring为实现事务处理而设计的拦截器TransctionInterceptor已经设置到ProxyFactory生成的AOP代理对象中去了，这里的TransactionInterceptor是作为AOP Advice的拦截器来实现它的功能的。在IoC容器中，配置其他与事务处理有关的属性，比如，比较熟悉的transactionManager和事务处理的属性，也同样会被设置到已经定义好的TransactionInterceptor中去。这些属性配置在TransactionInterceptor对事务方法进行拦截时会起作用。在AOP配置完成以后，可以看到，在Spring声明式事务处理实现中的一些重要的类已经悄然登场，比如TransactionAttributeSourceAdvisor和TransactionInterceptor，正是这些类通过AOP封装了Spring对事务处理的基本实现。
DefaultAopProxyFactory 创建 AOP Proxy 的过程在前面分析 AOP的实现原理 时已分析过，这里就不再重复了。可以看到，通过以上的一系列步骤，Spring 为实现事务处理而设计的 拦截器TransctionInterceptor 已经设置到 ProxyFactory 生成的 AOP代理对象 中去了，这里的 TransactionInterceptor 是作为 AOP Advice 的拦截器来实现它的功能的。在 IoC容器 中，配置其他与事务处理有关的属性，比如，比较熟悉的 transactionManager 和事务处理的属性，也同样会被设置到已经定义好的 TransactionInterceptor 中去。这些属性配置在 TransactionInterceptor，对事务方法进行拦截时会起作用。在 AOP配置 完成以后，可以看到，在 Spring声明式事务处理实现 中的一些重要的类已经悄然登场，比如 TransactionAttributeSourceAdvisor 和 TransactionInterceptor，正是这些类通过 AOP 封装了 Spring 对事务处理的基本实现。
### 2.2 事务处理配置的读入
在 AOP配置 完成的基础上，以 TransactionAttributeSourceAdvisor的实现 为入口，了解具体的事务属性配置是如何读入的。
@ -167,7 +167,7 @@ public class TransactionAttributeSourceAdvisor extends AbstractPointcutAdvisor {
private TransactionInterceptor transactionInterceptor;
/**
* 对于切面pointcut，这里使用了一个匿名内部类
* 对于 切面Pointcut，这里使用了一个匿名内部类
*/
private final TransactionAttributeSourcePointcut pointcut = new TransactionAttributeSourcePointcut() {
/**
@ -216,8 +216,8 @@ public class NameMatchTransactionAttributeSource implements TransactionAttribute
private Map<String, TransactionAttribute> nameMap = new HashMap<String, TransactionAttribute>();
/**
* 将给定属性transactionAttributes解析为名称/属性的map对象。以 方法名称 为键，
* 字符串属性定义 为值，可通过TransactionAttributeEditor解析为TransactionAttribute实例。
* 将给定 属性transactionAttributes 解析为 <名称, 属性> 的Map对象。以 方法名称 为 key，
* 字符串属性定义 为 value，可通过 TransactionAttributeEditor 解析为 TransactionAttribute实例。
*/
public void setProperties(Properties transactionAttributes) {
TransactionAttributeEditor tae = new TransactionAttributeEditor();
@ -270,7 +270,155 @@ public class NameMatchTransactionAttributeSource implements TransactionAttribute
protected boolean isMatch(String methodName, String mappedName) {
return PatternMatchUtils.simpleMatch(mappedName, methodName);
}
}
```
通过以上过程可以得到与目标对象调用方法相关的 TransactionAttribute对象，在这个对象中，封装了事务处理的配置。具体来说，在前面的匹配过程中，如果匹配返回的结果是 null，那么说明当前的调用方法不是一个事务方法，不需要纳入 Spring 统一的事务管理中，因为它并没有配置在 TransactionProxyFactoryBean 的事务处理设置中。如果返回的 TransactionAttribute对象 不是 null,那么这个返回的 TransactionAttribute对象 就已经包含了对事务方法的配置信息，对应这个事务方法的具体事务配置也已经读入到 TransactionAttribute对象 中了，为 TransactionInterceptor 做好了对调用的目标方法添加事务处理的准备。
### 2.3 事务处理拦截器的设计与实现
在完成以上的准备工作后，经过 TransactionProxyFactoryBean 的 AOP包装， 此时如果对目标对象进行方法调用，起作用的对象实际上是一个 Proxy代理对象，对目标对象方法的调用，不会直接作用在 TransactionProxyFactoryBean 设置的目标对象上，而会被设置的事务处理拦截器拦截。而在 TransactionProxyFactoryBean 的 AOP实现 中，获取 Proxy对象 的过程并不复杂，TransactionProxyFactoryBean 作为一个 FactoryBean，对这个 Bean 的对象的引用是通过调用其父类 AbstractSingletonProxyFactoryBean 的 getObject()方法 来得到的。
```java
public abstract class AbstractSingletonProxyFactoryBean extends ProxyConfig
implements FactoryBean<Object>, BeanClassLoaderAware, InitializingBean {
private Object proxy;
// 返回的是一个 proxy代理对象，这个 proxy 是 ProxyFactory 生成的 AOP代理，
// 已经封装了对事务处理的拦截器配置
public Object getObject() {
if (this.proxy == null) {
throw new FactoryBeanNotInitializedException();
}
return this.proxy;
}
}
```
InvocationHandler 的实现类中有一个非常重要的方法 invoke()，该方法是 proxy代理对象 的回调方法，在调用 proxy对象 的代理方法时触发这个回调。事务处理拦截器TransactionInterceptor 中实现了 InvocationHandler 的 invoke()方法，其过程是，首先获得调用方法的事务处理配置；在得到事务处理配置以后，会取得配置的 PlatformTransactionManager，由这个事务处理器来实现事务的创建、提交、回滚操作。
```java
public class TransactionInterceptor extends TransactionAspectSupport implements MethodInterceptor, Serializable {
public Object invoke(final MethodInvocation invocation) throws Throwable {
// 得到代理的目标对象，并将事务属性传递给目标对象
Class<?> targetClass = (invocation.getThis() != null ? AopUtils.getTargetClass(invocation.getThis()) : null);
// 在其父类 TransactionAspectSupport 中进行后续的事务处理
return invokeWithinTransaction(invocation.getMethod(), targetClass, new InvocationCallback() {
public Object proceedWithInvocation() throws Throwable {
return invocation.proceed();
}
});
}
}
public abstract class TransactionAspectSupport implements BeanFactoryAware, InitializingBean {
private static final ThreadLocal<TransactionInfo> transactionInfoHolder =
new NamedThreadLocal<TransactionInfo>("Current aspect-driven transaction");
protected Object invokeWithinTransaction(Method method, Class targetClass, final InvocationCallback invocation)
throws Throwable {
// 获取事务属性，如果属性为空，则该方法是非事务性的
final TransactionAttribute txAttr = getTransactionAttributeSource().getTransactionAttribute(method, targetClass);
final PlatformTransactionManager tm = determineTransactionManager(txAttr);
final String joinpointIdentification = methodIdentification(method, targetClass);
// 这里区分不同类型的 PlatformTransactionManager，因为他们的调用方式不同，
// 对 CallbackPreferringPlatformTransactionManager 来说，需要回调函数
// 来实现事务的创建和提交，而非 CallbackPreferringPlatformTransactionManager
// 则不需要
if (txAttr == null || !(tm instanceof CallbackPreferringPlatformTransactionManager)) {
// 这里创建事务，同时把创建事务过程中得到的信息放到 TransactionInfo 中，
// TransactionInfo 是保存当前事务状态的对象
TransactionInfo txInfo = createTransactionIfNecessary(tm, txAttr, joinpointIdentification);
Object retVal = null;
try {
// 这里的调用使处理沿着拦截器链进行，使最后目标对象的方法得以调用
retVal = invocation.proceedWithInvocation();
}
catch (Throwable ex) {
// 如果在事务处理方法调用中出现了异常，事务如何进行处理需要
// 根据具体情况考虑回滚或提交
completeTransactionAfterThrowing(txInfo, ex);
throw ex;
}
finally {
// 这里把 与线程绑定的 TransactionInfo 设置为 oldTransactionInfo
cleanupTransactionInfo(txInfo);
}
// 这里通过事务处理器来对事务进行提交
commitTransactionAfterReturning(txInfo);
return retVal;
} else {
// 使用回调的方式来使用事务处理器
try {
Object result = ((CallbackPreferringPlatformTransactionManager) tm).execute(txAttr,
new TransactionCallback<Object>() {
public Object doInTransaction(TransactionStatus status) {
TransactionInfo txInfo = prepareTransactionInfo(tm, txAttr, joinpointIdentification, status);
try {
return invocation.proceedWithInvocation();
}
catch (Throwable ex) {
if (txAttr.rollbackOn(ex)) {
// RuntimeException 会导致事务回滚
if (ex instanceof RuntimeException) {
throw (RuntimeException) ex;
}
else {
throw new ThrowableHolderException(ex);
}
}
else {
// 如果正常返回，则提交该事务
return new ThrowableHolder(ex);
}
}
finally {
cleanupTransactionInfo(txInfo);
}
}
});
// Check result: It might indicate a Throwable to rethrow.
if (result instanceof ThrowableHolder) {
throw ((ThrowableHolder) result).getThrowable();
}
else {
return result;
}
}
catch (ThrowableHolderException ex) {
throw ex.getCause();
}
}
}
/**
* 用于保存事务信息的不透明对象。子类必须将其传递回该类上的方法，但看不到其内部。
*/
protected final class TransactionInfo {
private final PlatformTransactionManager transactionManager;
private final TransactionAttribute transactionAttribute;
private final String joinpointIdentification;
private TransactionStatus transactionStatus;
private TransactionInfo oldTransactionInfo;
public TransactionInfo(PlatformTransactionManager transactionManager,
TransactionAttribute transactionAttribute, String joinpointIdentification) {
this.transactionManager = transactionManager;
this.transactionAttribute = transactionAttribute;
this.joinpointIdentification = joinpointIdentification;
}
}
}
```
以事务提交为例，简要的说明下该过程。在调用代理的事务方法时，因为前面已经完成了一系列 AOP配置，对事务方法的调用，最终启动
TransactionInterceptor拦截器 的 invoke()方法。在这个方法中，首先会读取该事务方法的事务属性配置，然后根据事务属性配置以及具体事务处理器的配置来决定采用哪一个事务处理器，这个事务处理器实际上是一个 PlatformTransactionManager。在确定好具体的事务处理器之后，会根据事务的运行情况和事务配置来决定是不是需要创建新的事务。
对于 Spring 而言，事务的管理实际上是通过一个 TransactionInfo对象 来完成的，在该对象中，封装了事务对象和事务处理的状态信息，这是事务处理的抽象。在这一步完成以后，会对拦截器链进行处理，因为有可能在该事务对象中还配置了除事务处理 AOP 之外的其他拦截器。在结束对拦截器链处理之后，会对 TransactionInfo 中的信息进行更新，以反映最近的事务处理情况，在这个时候，也就完成了事务提交的准备，通过调用 事务处理器PlatformTransactionManager 的 commitTransactionAfterReturning()方法 来完成事务的提交。这个提交的处理过程已经封装在 PlatformTransactionManager 的事务处理器中了，而与具体数据源相关的处理过程，最终委托给相关的具体事务处理器来完成，比如 DataSourceTransactionManager、Hibermate'TransactionManager 等。
在这个 invoke()方法 的实现中，可以看到整个事务处理在 AOP拦截器 中实现的全过程。同时，它也是 Spring 采用 AOP 封装事务处理和实现声明式事务处理的核心部分。这部分实现是一个桥梁，它胶合了具体的事务处理和 Spring AOP框架，可以看成是一个 Spring AOP应用，在这个桥梁搭建完成以后，Spring事务处理 的实现就开始了。

BIN
images/DesignPattern/建造者模式类图.png
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 9.7 KiB

BIN
images/DesignPattern/策略模式类图.png
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 12 KiB

BIN
images/DesignPattern/装饰器模式类图.png
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 16 KiB

BIN
images/DesignPattern/观察者模式类图.png
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 13 KiB

BIN
images/Netty/BIO通信模型.png
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 10 KiB

BIN
images/Netty/Buffer组件类图.png
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 5.0 KiB

BIN
images/Netty/ChannelPipeline的调度相关方法.png
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 26 KiB

BIN
images/Netty/Channel组件类图.png
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 18 KiB

BIN
images/Netty/IO复用模型.png
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 71 KiB

BIN
images/Netty/NIO客户端序列图.png
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 24 KiB

BIN
images/Netty/NIO服务端序列图.png
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 19 KiB

BIN
images/Netty/Netty串行化设计工作原理.png
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 31 KiB

BIN
images/Netty/Netty服务端创建时序图.png
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 24 KiB

BIN
images/Netty/Netty逻辑架构图.png
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 564 KiB

BIN
images/Netty/NioServerSocketChannel的ChannelPipeline.png
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 9.9 KiB

BIN
images/Netty/ServerBootstrap的Handler模型.png
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 125 KiB

BIN
images/Netty/TCP粘包拆包问题.png
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 11 KiB

BIN
images/Netty/伪异步IO通信模型.png
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 18 KiB

BIN
images/Netty/信号驱动IO模型.png
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 65 KiB

BIN
images/Netty/四种IO模型的功能特性对比图.png
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 13 KiB

BIN
images/Netty/基于Netty创建客户端时序图.png
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 26 KiB

BIN
images/Netty/异步IO模型.png
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 54 KiB

BIN
images/Netty/数据在客户端及服务器之间的整体IO流程.png
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 27 KiB

BIN
images/Netty/阻塞IO模型.png
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 47 KiB

BIN
images/Netty/非阻塞IO模型.png
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 71 KiB

BIN
images/multi-thread/线程池流程.png
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 47 KiB

BIN
images/spring/image-20200109150841916.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 101 KiB

After

Width:  |  Height:  |  Size: 68 KiB

BIN
images/spring/image-20200110093044672.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 13 KiB

After

Width:  |  Height:  |  Size: 9.8 KiB

BIN
images/spring/image-20200115083744268.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 79 KiB

After

Width:  |  Height:  |  Size: 54 KiB

BIN
images/spring/image-20200115084031725.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 8.2 KiB

After

Width:  |  Height:  |  Size: 6.1 KiB

BIN
images/spring/image-20200115093602651.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 8.5 KiB

After

Width:  |  Height:  |  Size: 6.3 KiB

BIN
images/spring/image-20200115105941265.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 54 KiB

After

Width:  |  Height:  |  Size: 29 KiB

BIN
images/spring/image-20200115141708702.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 13 KiB

After

Width:  |  Height:  |  Size: 6.9 KiB

BIN
images/spring/image-20200115143315633.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 65 KiB

After

Width:  |  Height:  |  Size: 47 KiB

BIN
images/spring/image-20200115143456554.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 66 KiB

After

Width:  |  Height:  |  Size: 49 KiB

BIN
images/spring/image-20200116085344737.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 21 KiB

After

Width:  |  Height:  |  Size: 17 KiB

BIN
images/spring/image-20200116085423073.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 9.7 KiB

After

Width:  |  Height:  |  Size: 5.9 KiB

BIN
images/spring/image-20200116085726577.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 19 KiB

After

Width:  |  Height:  |  Size: 10 KiB

BIN
images/spring/image-20200116085737632.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 8.0 KiB

After

Width:  |  Height:  |  Size: 4.5 KiB

BIN
images/spring/image-20200116085927359.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 41 KiB

After

Width:  |  Height:  |  Size: 32 KiB

BIN
images/spring/image-20200116092259944.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 49 KiB

After

Width:  |  Height:  |  Size: 38 KiB

BIN
images/spring/image-20200116141838601.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 57 KiB

After

Width:  |  Height:  |  Size: 42 KiB

BIN
images/spring/image-20200116141932486.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 27 KiB

After

Width:  |  Height:  |  Size: 21 KiB

BIN
images/spring/image-20200119085346675.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 131 KiB

After

Width:  |  Height:  |  Size: 92 KiB

BIN
images/spring/image-20200119085655734.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 42 KiB

After

Width:  |  Height:  |  Size: 30 KiB

BIN
images/spring/image-20200119101017989.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 79 KiB

After

Width:  |  Height:  |  Size: 61 KiB

BIN
images/spring/image-20200119101026726.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 37 KiB

After

Width:  |  Height:  |  Size: 29 KiB

BIN
images/spring/image-20200119101107820.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 43 KiB

After

Width:  |  Height:  |  Size: 32 KiB

BIN
images/spring/image-20200119101516591.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 42 KiB

After

Width:  |  Height:  |  Size: 17 KiB

BIN
images/springMVC/clazz/image-20200123085741347.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 102 KiB

After

Width:  |  Height:  |  Size: 80 KiB

BIN
images/springMVC/clazz/image-20200123085756168.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 74 KiB

After

Width:  |  Height:  |  Size: 50 KiB

BIN
images/springMVC/clazz/image-20200123085946476.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 46 KiB

After

Width:  |  Height:  |  Size: 27 KiB

BIN
images/springMVC/clazz/image-20200123090442409.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 6.2 KiB

After

Width:  |  Height:  |  Size: 4.5 KiB

BIN
images/springMVC/clazz/image-20200123090851644.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 42 KiB

After

Width:  |  Height:  |  Size: 22 KiB

BIN
images/springMVC/clazz/image-20200123091445694.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 68 KiB

After

Width:  |  Height:  |  Size: 39 KiB

BIN
images/springMVC/clazz/image-20200123093032179.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 43 KiB

After

Width:  |  Height:  |  Size: 24 KiB

BIN
images/springMVC/clazz/image-20200123093733129.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 6.2 KiB

After

Width:  |  Height:  |  Size: 4.4 KiB

BIN
images/springMVC/clazz/image-20200123094439617.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 24 KiB

After

Width:  |  Height:  |  Size: 16 KiB

BIN
images/springTransaction/PlatformTransactionManager组件的设计.png
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 16 KiB

BIN
images/springTransaction/实现DataSourceTransactionManager的时序图.png
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 16 KiB

Some files were not shown because too many files have changed in this diff Show More

Write Preview
Loading…
Cancel
Save