【Spring源码这样读】-再次走近容器Spring IOC 一

曾经终败给现在 2023-01-13 04:13 121阅读 0赞

> 准备工作已经做完了，现在我们就可以开始正式进入阅读环节。本文如题，主要讲的就是我们Spring的核心部分容器。这个词相比都是不陌生的，很多人接触Spring的时候就会接触到Spring的两大核心功能IOC和AOP。这里我们换一种角度来读，希望能给大家带来一些新的认知。大佬请略过，有异议的地方还请各位大佬指出。

### 什么是容器 ###

说到容器，估计很多人都会浮现两个概念：IOC、DI。

*  IOC：Inversion of Control，即控制反转。  
    IOC并不是一种什么技术，而是一种编程思想。那什么是控制反转，为什么控制反转？  
    先来看一个简单的示例：

public class Test {
        
        public static void main(String[] args) {
        
            new Test1().testMethod();
        }
    }
    
    class Test1 {
        
        public void testMethod() {
        
            System.out.println("testMethod方法被调用");
        }
    }

这是一段很简单的代码，在一个类里面调用了另外一个类的方法。调用另外一个类的方法时，我们直接创建该类的对象。在我们框架的使用当中我们是不需要去创建对象的，都是框架给我们在做这些事情。那这里我们就能明显的看到一个问题，对象在以不同的方式被使用。

谁控制谁？在我们上面的例子当中，可以明显的看到，new对象是我们当前方法来控制的。但是容器呢？我们基本看不到new的操作，我们都是直接注入使用，所以可以直接推断出对象的new动作不是当前使用的程序，而是框架。具体点说就是框架在做这件事情。  
什么是正转、反转？所谓的正转，就是程序内部直接new对象，并赋值。反转就是容器new对象，主动给程序提供

> 这种操作就解决了一个问题，解耦。试着想一下，如果我们的代码都通过写new来使用对象，对象的管理工作会很繁杂。

*  DI—Dependency Injection  
    即“依赖注入”：是组件之间依赖关系由容器在运行期决定，形象的说，即由容器动态的将某个依赖关系注入到组件之中。上面我们提到的框架再给我们new对象，然后给我们提供可以用的对象，其实这里就包含了对象的注入，如果不注入，框架创建的对象怎么被我们写的代码引用呢？

### Spring IOC容器的应用场景 ###

在 Spring 中，Spring IoC 提供了一个基本 JavaBean 容器，通过 IoC 模式管理依赖关系，并通过依赖注入和 AOP 切面增强了为 JavaBean 这样的 POJO 对象提供了事务管理、声明周期管理等功能。其实如果我们把IOC看做一个水桶，那么项目里面那些Bean就都是水。在没有框架的情况下，水是很不好收集保留的，但是当我们有了这个容器之后，我们发现，他给我们带来了很大的便利，不仅不需要来回的去new，也不需要去关心，他有多少了。

### Spring IOC容器的实现 ###

目前Spring IOC的主流实现就两种方式,BeanFactory和ApplicationContext,我们不妨来体验一下两种实现方式。

*  BeanFactory  
    这里需要创建一个简单的Spring项目，引入Spring的基本依赖即可，然后我们来尝试使用一下容器  
    先来创建一个简单的bean

public class TestBean {
        
    
        private String name = "this is bean";
    
        public String getName() {
        
            return this.name;
        }
    
    }

这个bean并没有什么特别的地方，很普通。然后我们再来创建一个配置文件testBeanFactory.xml，将bean交给容器管理

<?xml version="1.0" encoding="UTF-8"?>
 <beans xmlns="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
 
 <bean id="testBean" class="com.echo.demo.TestBean"/>
 
 </beans>

> 在我们的普通程序中，我们要使用bean就需要去new，但是这里，我们不需要了。可以直接通过容器来获取bean

获取被容器管理的bean

package com.echo.demo;
    
    import org.springframework.beans.factory.xml.XmlBeanFactory;
    import org.springframework.core.io.ClassPathResource;
    
    public class Test {
        
    
        public static void main(String[] args) {
        
    
            XmlBeanFactory xmlBeanFactory = new XmlBeanFactory(new ClassPathResource("testBeanFactory.xml"));
            TestBean testBean = (TestBean)xmlBeanFactory.getBean("testBean");
            System.out.println(testBean.getName());
    
        }
    
    }

> 到这里为止，我们已经体验了BeanFactory的基本用法。很简单，我们仅仅只是建了一个bean，并且声明了一下，然后就可以拿到这个bean的实例了。

*  ApplicationContext  
    我们不妨用ApplicatonContext也来做个实例，比对一下。和上面一样，来个一样的bean

public class TestBean {
        
    
        private String name = "this is bean";
    
        public String getName() {
        
            return this.name;
        }
    
    }

注意ApplicatonContext的实现也需要xml文件

到目前为止，其实我们看到的两种方式也没啥区别，但是我们看看获取bean的代码就知道了，使用上也就是获取bean的这两行代码不一样

package com.echo.demo;
    
    import org.springframework.context.ApplicationContext;
    import org.springframework.context.support.ClassPathXmlApplicationContext;
    
    public class Test {
        
    
        public static void main(String[] args) {
        
            ApplicationContext applicationContext = new ClassPathXmlApplicationContext("testApplicationContext.xml");
            TestBean testBean = (TestBean) applicationContext.getBean("testBean");
            System.out.println(testBean.getName());
        }
    
    }

这两段简易的代码，其实从我们一个使用的角度来讲，并没有很实质性的区别，无非就是用了另外一个类来调用获取bean的方法。这两段代码，不管是从表面上看还是从他的实现来看，都逃不过这么几部：

*  读取配置文件
 *  根据配置文件找到对应的类并通过反射来实例化
 *  然后存入容器，被调用的时候取出

> 那真的是这样的子的吗？我们深入实现来复核一下我们的想法

这里我们已经有了猜想，同时代码实例也已经有了，我们不妨来通过时序图深入了解一下。这个时序图是从我们代码的Test类开始的，这里我们画了一个XmlBeanFactory初始化的时序图来看我们的代码逻辑到底做了件什么事情。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hsZWNobw_size_16_color_FFFFFF_t_70]

当我们看到这个时序图的时候，其实应该是能比较明了的知道前面我们的代码，到底做了些什么事情。代码从ClassPathResource获取文件开始，最终拿到对象。如果光从时序图上来看的话，跟我们之前的推测没啥很大的出入，为了进一步的来了解我们的推测，我们用源码来应正一下。

*  代码中ClassPathResource到底做了件什么事情？先看这里

/**
 * Create a new {@code ClassPathResource} for {@code ClassLoader} usage.
 * A leading slash will be removed, as the ClassLoader resource access
 * methods will not accept it.
 * The thread context class loader will be used for
 * loading the resource.
 * @param path the absolute path within the class path
 * @see java.lang.ClassLoader#getResourceAsStream(String)
 * @see org.springframework.util.ClassUtils#getDefaultClassLoader()
 */
 public ClassPathResource(String path) {
 
 	this(path, (ClassLoader) null);
 }
 
 /**
 * Create a new {@code ClassPathResource} for {@code ClassLoader} usage.
 * A leading slash will be removed, as the ClassLoader resource access
 * methods will not accept it.
 * @param path the absolute path within the classpath
 * @param classLoader the class loader to load the resource with,
 * or {@code null} for the thread context class loader
 * @see ClassLoader#getResourceAsStream(String)
 */
 public ClassPathResource(String path, @Nullable ClassLoader classLoader) {
 
 	Assert.notNull(path, "Path must not be null");
 	String pathToUse = StringUtils.cleanPath(path);
 	if (pathToUse.startsWith("/")) {
 
 		pathToUse = pathToUse.substring(1);
 	}
 	this.path = pathToUse;
 	this.classLoader = (classLoader != null ? classLoader : ClassUtils.getDefaultClassLoader());
 }
 
 
 /**
 * Return the default ClassLoader to use: typically the thread context
 * ClassLoader, if available; the ClassLoader that loaded the ClassUtils
 * class will be used as fallback.
 * Call this method if you intend to use the thread context ClassLoader
 * in a scenario where you clearly prefer a non-null ClassLoader reference:
 * for example, for class path resource loading (but not necessarily for
 * {@code Class.forName}, which accepts a {@code null} ClassLoader
 * reference as well).
 * @return the default ClassLoader (only {@code null} if even the system
 * ClassLoader isn't accessible)
 * @see Thread#getContextClassLoader()
 * @see ClassLoader#getSystemClassLoader()
 */
 @Nullable
 public static ClassLoader getDefaultClassLoader() {
 
 	ClassLoader cl = null;
 	try {
 
 		cl = Thread.currentThread().getContextClassLoader();
 	}
 	catch (Throwable ex) {
 
 		// Cannot access thread context ClassLoader - falling back...
 	}
 	if (cl == null) {
 
 		// No thread context class loader -> use class loader of this class.
 		cl = ClassUtils.class.getClassLoader();
 		if (cl == null) {
 
 			// getClassLoader() returning null indicates the bootstrap ClassLoader
 			try {
 
 				cl = ClassLoader.getSystemClassLoader();
 			}
 			catch (Throwable ex) {
 
 				// Cannot access system ClassLoader - oh well, maybe the caller can live with null...
 			}
 		}
 	}
 	return cl;
 }
 
 
 /**
 * Returns the system class loader for delegation. This is the default
 * delegation parent for new <tt>ClassLoader</tt> instances, and is
 * typically the class loader used to start the application.
 *
 * This method is first invoked early in the runtime's startup
 * sequence, at which point it creates the system class loader and sets it
 * as the context class loader of the invoking <tt>Thread</tt>.
 *
 * The default system class loader is an implementation-dependent
 * instance of this class.
 *
 * If the system property "<tt>java.system.class.loader</tt>" is defined
 * when this method is first invoked then the value of that property is
 * taken to be the name of a class that will be returned as the system
 * class loader. The class is loaded using the default system class loader
 * and must define a public constructor that takes a single parameter of
 * type <tt>ClassLoader</tt> which is used as the delegation parent. An
 * instance is then created using this constructor with the default system
 * class loader as the parameter. The resulting class loader is defined
 * to be the system class loader.
 *
 * If a security manager is present, and the invoker's class loader is
 * not <tt>null</tt> and the invoker's class loader is not the same as or
 * an ancestor of the system class loader, then this method invokes the
 * security manager's {@link
 * SecurityManager#checkPermission(java.security.Permission)
 * <tt>checkPermission</tt>} method with a {@link
 * RuntimePermission#RuntimePermission(String)
 * <tt>RuntimePermission("getClassLoader")</tt>} permission to verify
 * access to the system class loader. If not, a
 * <tt>SecurityException</tt> will be thrown. 
 *
 * @return The system <tt>ClassLoader</tt> for delegation, or
 * <tt>null</tt> if none
 *
 * @throws SecurityException
 * If a security manager exists and its <tt>checkPermission</tt>
 * method doesn't allow access to the system class loader.
 *
 * @throws IllegalStateException
 * If invoked recursively during the construction of the class
 * loader specified by the "<tt>java.system.class.loader</tt>"
 * property.
 *
 * @throws Error
 * If the system property "<tt>java.system.class.loader</tt>"
 * is defined but the named class could not be loaded, the
 * provider class does not define the required constructor, or an
 * exception is thrown by that constructor when it is invoked. The
 * underlying cause of the error can be retrieved via the
 * {@link Throwable#getCause()} method.
 *
 * @revised 1.4
 */
 @CallerSensitive
 public static ClassLoader getSystemClassLoader() {
 
 initSystemClassLoader();
 if (scl == null) {
 
 return null;
 }
 SecurityManager sm = System.getSecurityManager();
 if (sm != null) {
 
 checkClassLoaderPermission(scl, Reflection.getCallerClass());
 }
 return scl;
 }

基本上核心代码都已经拿出来了，不难发现，其实就是做了一些初始化，还做了一个权限的判断。但是这一步代码好像并没有去获取到文件？没有获取到文件的真正内容？这一个问题由于本文过长，我们在下一篇文章再分析

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hsZWNobw_size_16_color_FFFFFF_t_70]: /images/20221022/767f4e14ff464f9c9a8a6c4cead7fa20.png