Spring源码解读——容器是如何初始化的

Posted 2022-11-13 BaldWinf

为什么要读源码

• Spring是一群优秀的框架组成的社区、现在已经非常丰富了。当我们享受着Spring带来的便利同时，有时也想一探究竟。
• 人人都说Spring好，难免有人趋之若鹜，如果让你说出个究竟，你能说出多少来？就我而言，除了能拽两AOP、DI等耳熟能详的洋词以外，就很难有高深的见解了。
• 不得不说，选择先读Spring源码，是受到人云亦云的影响，既然都说他好，我们就要一探究竟。如果好，就要说出好的道理，如果不好，还要指出缺陷和不足。做不到这点，就算不上实事求是，就是“皇帝的新衣”了。
• 有点儿好奇
• 想写写东西。除了敲代码，偶尔写点别的东西，可以让我放松，也能装出很认真的样子-_-!

怎么读呢

当你下载好源码，也编译了，接下来就是欣赏源码了。可是突然发现，那画面太美以至于无法直视。怎么看，从哪里看？像对待一位亭亭玉立的处女一样，手足无措。

一切从实际出发

如果真有一位美女在你面前，你会做什么？答案是：在你没有搞清楚你和她的关系之前，你什么也不敢做。
对待源码也是这样。我用Spring源码，最多的地方莫过于启动项目的时候注入实例，包括Spring测试的时候常写的那句代码

ClassPathXmlApplicationContext ctx = new ClassPathXmlApplicationContext("bean.xml");

所以对我而言，Spring怎么启动并完成初始化，是我首先感兴趣的。这是我和Spring的直接关系

ClassPathXmlApplicationContext是什么

先看一张类图

看一下这张图，上图最底部的ClassPathXmlApplicationContext就是我关注的Context，Context是什么意思？一般翻译为“上下文”，我认为这点比较恶心，明显词不达意。我认为就叫“容器”更准确，这点我持保留意见，不一定有人认同。

顾名思义，ClassPathXmlApplicationContext的意思就是“类路径下的Xml形式的应用容器”。这个容器辈分很低，有很多的祖先。对于客户端来说，第一种初始化容器的方式，就是创建ClassPathXmlApplicationContext的实例，并且传入一个xml格式的配置文件名称，这个配置文件需要放在classpath路径下。

 new ClassPathXmlApplicationContext("bean.xml");

这里可以大胆猜测，ClassPathXmlApplicationContext的构造方法是一个复杂的过程，这个过程就是开启我们spring源码探险的征程。

ClassPathXmlApplicationContext的构造方法

我怀着激动无比的心情，ctrl+鼠标左键，点进了ClassPathXmlApplicationContext的构造方法中，看到了这个

    /**
     * Create a new ClassPathXmlApplicationContext, loading the definitions
     * from the given XML file and automatically refreshing the context.
     * @param configLocation resource location
     * @throws BeansException if context creation failed
     */
    public ClassPathXmlApplicationContext(String configLocation) throws BeansException 
        this(new String[] configLocation, true, null);
    

构造函数的重载，是常见的复用手段，这个技巧我也经常使用。上述代码值得注意的细节如下：

1、复用的构造函数有3个参数，我们的xml配置文件作为String数组的一个元素继续传递。是不是可以猜测 “spring的配置文件其实是支持多个的”。

2、第二个参数的是true，如果用idea的话，可以看到这个参数的名字叫“refresh”。一个boolean类型的变量叫refresh是否很容易猜到，这个参数其实是控制这个容器是否“重新刷新”的。至于重新刷新是什么，就目前而言我们是不清楚的

显然这里没有看到我想要的内容，于是我继续点进去，看到了：

    /**
     * Create a new ClassPathXmlApplicationContext with the given parent,
     * loading the definitions from the given XML files.
     * @param configLocations array of resource locations
     * @param refresh whether to automatically refresh the context,
     * loading all bean definitions and creating all singletons.
     * Alternatively, call refresh manually after further configuring the context.
     * @param parent the parent context
     * @throws BeansException if context creation failed
     * @see #refresh()
     */
    public ClassPathXmlApplicationContext(String[] configLocations, boolean refresh, ApplicationContext parent)
            throws BeansException 

        super(parent);
        setConfigLocations(configLocations);
        if (refresh) 
            refresh();
        
    

从注释中可以看到，我们一些猜想得到的验证。

1、配置文件路径是能支持多个的
2、refresh定义：是否自动刷新容器，加载所有定义并创建所有单例。否则，在更多其他配置操作后，手动刷新容器。

疑惑也多了

parent context 父容器是什么东西？
简单猜测下，应该是一个父类，这个类也是容器。

进一步看代码，共三部分

    // 调用父类构造器
    super(parent);
    // 配置文件相关
    setConfigLocations(configLocations);
    // 如果需要，刷新容器
    if (refresh) 
        refresh();
    

这三部分就是ClassPathXmlApplicationContext构造器的全部内容，虽然简短，但是深远。从这里我们可以看到spring源码的一个特点，复用率高，而且可读性非常好。这一点我非常佩服，我始终认为，写代码应该像写小说一样，每一个方法、变量的名字，都应该发挥它最大的作用，让看代码的人脑海中充满画面感。

supper（parent）指向何方

我在大海中，充满迷茫，这时海神波塞冬出现了，他希望我能完成一件伟大的使命，这个使命很模糊，但是第一件事情就是追寻，追寻一个起源。
supper（parent），到底指向什么？还想象不到。还有parent是什么？还不清楚，充满疑惑，我继续点击进去，竟然

    /**
     * Create a new AbstractXmlApplicationContext with the given parent context.
     * @param parent the parent context
     */
    public AbstractXmlApplicationContext(ApplicationContext parent) 
        super(parent);
    

离开了ClassPathXmlApplicationContext的怀抱，进入了AbstractXmlApplicationContext 。这个Context是什么，还记得那张图吗？先回头看看，然后再继续。

public abstract class AbstractXmlApplicationContext extends AbstractRefreshableConfigApplicationContext 
    ...

他是ClassPathXmlApplicationContext的父类，抽象的。抽象类给我的感觉两种
1、抽象类维护一种逻辑上的结构关系。
2、抽象类通过模板方法，提高复用。
这两点，我认为第一点更重要，为了复用使用抽象类，是不明智甚至愚蠢的。

supper（parent）带着parent找到了这个抽象容器，可是它什么也不做，继续supper（parent）。对于这种做法，我渐渐有种认同：一条父子链上的所有类，往往越往上，功能越简单，甚至是个空实现。越往下，往往越具体，方法的特征也更有“具体问题具体分析”的感觉。往上，更哲学，往下，更接地气。我们要做的就是，将适度具体的方法，放在适度的层级，放的对放的准，代码的复用率就会更高。

显然，spring的作者认为，这个parent太深奥了，在AbstractXmlApplicationContext容器中做处理，有点“小材大用”了。

继续往下点击，没想到

    /**
     * Create a new AbstractRefreshableConfigApplicationContext with the given parent context.
     * @param parent the parent context
     */
    public AbstractRefreshableConfigApplicationContext(ApplicationContext parent) 
        super(parent);
    

又是个过手卡油的家伙，AbstractRefreshableConfigApplicationContext可以翻看前面的类图，他算是ClassPathXmlApplicationContext的爷爷了。

继续点

public AbstractRefreshableApplicationContext(ApplicationContext parent) 
        super(parent);
    

不解释，继续

    /**
     * Create a new AbstractApplicationContext with the given parent context.
     * @param parent the parent context
     */
    public AbstractApplicationContext(ApplicationContext parent) 
        this();
        setParent(parent);
    

这里需要停一下，AbstractApplicationContext通过类图可以看到，它的地位有点特殊了，家族的人脉关系，在这里有了一个极大的丰富。
一个重要的发现是（看图）：

AbstractApplicationContext往下的子孙容器，首要一个身份是ResourceLoader，即资源加载器。而Context的身份来源居然是通过接口实现的。

这一点在逻辑上是很难理解的。就好比，一天，日昏黄，你饭后坐在门口，思绪飞扬，浮想你的祖先会是什么样的一个人呢？是诗人、商人、英雄、还是普通人呢？但最终你发现，原来你的祖先不是人，而是别的什么东西？是不是感觉到了“惊悚”，我对这样的继承关系，是不太认同的。

而我对这样的继承关系，唯一能想到的解释就是——“历史原因”。如果有识之士知道其中原委，不吝赐教。
这点我还是想多说两句，我始终认为继承是要谨慎的东西。好的继承关系，就像一部家庭伦理喜剧，而不好的继承关系，就是一部乱伦史。
为了复用而继承，就好比你的同学新买了一个iphonex，而你为了玩儿上它，竟然认他做“爹”，虽然iphonex得到了复用，但是伦理丧失、逻辑全无。后人如果不知其里，定会觉得“悬疑”无比，非常的“烧脑”，科学家们也会趋之若鹜。

AbstractApplicationContext的意义在于，super（parent）止于此，我们一定要关注一下。

    this();
    setParent(parent);

点开this（），看到

    /**
     * Create a new AbstractApplicationContext with no parent.
     */
    public AbstractApplicationContext() 
        this.resourcePatternResolver = getResourcePatternResolver();
    

注释很清楚：创建一个没有父容器的抽象构造容器。
然后初始化了一个resourcePatternResolver(资源模板解析器)
这里用到的资源模板解析器具体实例是：

    protected ResourcePatternResolver getResourcePatternResolver() 
        return new PathMatchingResourcePatternResolver(this);
    

叫PathMatchingResourcePatternResolver（路径匹配资源模板解析器）。而这个解析器需要一个类加载器的实例，我们给的就是this。这个this，可以理解就是我们创建的ClassPathXmlApplicationContext实例。

然后这个解析器持有了我们的资源加载器。

    /**
     * Create a new PathMatchingResourcePatternResolver.
     * <p>ClassLoader access will happen via the thread context class loader.
     * @param resourceLoader the ResourceLoader to load root directories and
     * actual resources with
     */
    public PathMatchingResourcePatternResolver(ResourceLoader resourceLoader) 
        Assert.notNull(resourceLoader, "ResourceLoader must not be null");
        this.resourceLoader = resourceLoader;
    

看完AbstractApplicationContext的this()之后，我们接着看下一行

setParent(parent);

看名字可以知道，这是添加父容器，这也是之前挖的一个坑，什么是父容器？需要点进去

    /**
     * @inheritDoc
     * <p>The parent @linkplain ApplicationContext#getEnvironment() environment is
     * @linkplain ConfigurableEnvironment#merge(ConfigurableEnvironment) merged with
     * this (child) application context environment if the parent is non-@code null and
     * its environment is an instance of @link ConfigurableEnvironment.
     * @see ConfigurableEnvironment#merge(ConfigurableEnvironment)
     */
    @Override
    public void setParent(ApplicationContext parent) 
        this.parent = parent;
        if (parent != null) 
            Environment parentEnvironment = parent.getEnvironment();
            if (parentEnvironment instanceof ConfigurableEnvironment) 
                getEnvironment().merge((ConfigurableEnvironment) parentEnvironment);
            
        
    

这里没有看懂这个setParent到底干了什么，而且我们用的测试方法是

    @Test
    public void testSingleConfigLocation() 
        ClassPathXmlApplicationContext ctx = new ClassPathXmlApplicationContext(FQ_SIMPLE_CONTEXT);
        assertTrue(ctx.containsBean("someMessageSource"));
        ctx.close();
    

这里没有涉及到parent，所以这个坑暂时也是没有办法填上了。
这样回顾ClassPathXmlApplicationContext，这三行中的第一行代码就讲完了

        super(parent);
        setConfigLocations(configLocations);
        if (refresh) 
            refresh();
        

总结下，基本上就是两部分
1、创建一个解析器，解析器拥有容器自己的实例，而容器实际上也是个资源加载器。
2、添加父容器，这里没有涉及到

setConfigLocations(configLocations)

super(parent)之后，是设置配置文件路径的功能，点进去
其实ClassPathXmlApplicationContext的setConfigLocations(configLocations)方法是继承自AbstractRefreshableConfigApplicationContext的

    /**
     * Set the config locations for this application context.
     * <p>If not set, the implementation may use a default as appropriate.
     */
    public void setConfigLocations(String... locations) 
        if (locations != null) 
            Assert.noNullElements(locations, "Config locations must not be null");
            this.configLocations = new String[locations.length];
            for (int i = 0; i < locations.length; i++) 
                this.configLocations[i] = resolvePath(locations[i]).trim();
            
        
        else 
            this.configLocations = null;
        
    

注释告诉了一个重要信息：为应用容器设置“配置路径”，如果不设置，将使用一个默认的实现。
我的设置路径是

/org/springframework/context/support/simpleContext.xml

扩展：
1、可变参数可以传入数组，这是我刚知道的事情。
2、对于数组，可以通过Assert.noNullElements方法判断是否含有元素

AbstractRefreshableConfigApplicationContext将“locations”一个个地加入到自己的configLocations当中，configLocations是“AbstractRefreshableConfigApplicationContext”的一个私有变量

private String[] configLocations;

可能正是因为这个变量，才有的AbstractRefreshableConfigApplicationContext这个容器。

在加入之前，有一个resolvePath的动作，跟进一下

    /**
     * Resolve the given path, replacing placeholders with corresponding
     * environment property values if necessary. Applied to config locations.
     * @param path the original file path
     * @return the resolved file path
     * @see org.springframework.core.env.Environment#resolveRequiredPlaceholders(String)
     */
    protected String resolvePath(String path) 
        return getEnvironment().resolveRequiredPlaceholders(path);
    

大概意思就是用相应的环境属性，替换占位符。

getEnvironment方法的实现在AbstractApplicationContext中，是AbstractRefreshableConfigApplicationContext的爷爷了，点进getEnvironment()方法看看：

    /**
     * @inheritDoc
     * <p>If @code null, a new environment will be initialized via
     * @link #createEnvironment().
     */
    @Override
    public ConfigurableEnvironment getEnvironment() 
        if (this.environment == null) 
            this.environment = createEnvironment();
        
        return this.environment;
    

有一个createEnvironment()方法，点进去

    /**
     * Create and return a new @link StandardEnvironment.
     * <p>Subclasses may override this method in order to supply
     * a custom @link ConfigurableEnvironment implementation.
     */
    protected ConfigurableEnvironment createEnvironment() 
        return new StandardEnvironment();
    

注释大意：
创建并返回一个标准环境（StandardEnvironment）
子类如果想提供一个自定义的“配置环境（ConfigurableEnvironment）”，继承这个方法。

那么StandardEnvironment()是什么？还是不太清楚，看一张图

原来StandardEnvironment是一个PropertyResolver，可以看下这个PropertyResolver是什么

/**
 * Interface for resolving properties against any underlying source.
 *
 * @author Chris Beams
 * @author Juergen Hoeller
 * @since 3.1
 * @see Environment
 * @see PropertySourcesPropertyResolver
 */
public interface PropertyResolver 
    ...

叫做属性解析器。

返回的PropertyResolver立即调用了方法

    /**
     * Resolve $... placeholders in the given text, replacing them with corresponding
     * property values as resolved by @link #getProperty. Unresolvable placeholders with
     * no default value will cause an IllegalArgumentException to be thrown.
     * @return the resolved String (never @code null)
     * @throws IllegalArgumentException if given text is @code null
     * or if any placeholders are unresolvable
     * @see org.springframework.util.SystemPropertyUtils#resolvePlaceholders(String, boolean)
     */
    String resolveRequiredPlaceholders(String text) throws IllegalArgumentException;

大概意思就是解析配置文件中的占位符，如果解析不了抛出异常