<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId></dependency>
spring.redis.host=192.168.8.74spring.redis.password=123456spring.redis.database=0
package com.example.springbootvipjtdemo.redisdemo;import org.springframework.beans.factory.annotation.Autowired;import org.springframework.data.redis.core.RedisTemplate;import org.springframework.web.bind.annotation.GetMapping;import org.springframework.web.bind.annotation.RequestMapping;import org.springframework.web.bind.annotation.RequestParam;import org.springframework.web.bind.annotation.RestController;/** * @author Eclipse_2019 * @create 2022/6/9 14:36 */@RestController@RequestMapping("/redis")public class RedisController { @Autowired private RedisTemplate redisTemplate; @GetMapping("/save") public String save(@RequestParam String key,@RequestParam String value){ redisTemplate.opsForValue().set(key,value); return "添加成功"; } @GetMapping("/get") public String get(@RequestParam String key){ String value = (String)redisTemplate.opsForValue().get(key); return value; }}
通过上面的案例,我们就能看出来,RedisTemplate这个类的bean对象,我们并没有通过XML的方式也没有通过注解的方式注入到IoC容器中去,但是我们就是可以通过@Autowired注解自动从容器里面拿到相应的Bean对象,再去进行属性注入。
那这是怎么做到的呢?接下来我们来分析一下自动装配的原理,等我们弄明白了原理,自然而然你们就懂了RedisTemplate的bean对象怎么来的。
@Target(ElementType.TYPE) // 注解的适用范围,其中TYPE用于描述类、接口(包括包注解类型)或enum声明@Retention(RetentionPolicy.RUNTIME) // 注解的生命周期,保留到class文件中(三个生命周期)@Documented // 表明这个注解应该被javadoc记录@Inherited // 子类可以继承该注解@SpringBootConfiguration // 继承了Configuration,表示当前是注解类@EnableAutoConfiguration // 开启springboot的注解功能,springboot的四大神器之一,其借助@import的帮助@ComponentScan(excludeFilters = { // 扫描路径设置@Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class),@Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) })public @interface SpringBootApplication {...}
在其中比较重要的有三个注解,分别是:
ComponentScan的功能其实就是自动扫描并加载符合条件的组件(比如@Component和@Repository等)或者bean定义;并将这些bean定义加载到IoC容器中。
我们可以通过basePackages等属性来细粒度的定制@ComponentScan自动扫描的范围,如果不指定,则默认Spring框架实现会从声明@ComponentScan所在类的package进行扫描。
注:所以SpringBoot的启动类最好是放在root package下,因为默认不指定basePackages。
此注解顾名思义是可以自动配置,所以应该是springboot中最为重要的注解。
@Target(ElementType.TYPE)@Retention(RetentionPolicy.RUNTIME)@Documented@Inherited@AutoConfigurationPackage@Import(AutoConfigurationImportSelector.class)//【重点注解】public @interface EnableAutoConfiguration {...}
其中最重要的两个注解:
当然还有其中比较重要的一个类就是:AutoConfigurationImportSelector.class。
@Target(ElementType.TYPE)@Retention(RetentionPolicy.RUNTIME)@Documented@Inherited@Import(AutoConfigurationPackages.Registrar.class)public @interface AutoConfigurationPackage {}
通过@Import(AutoConfigurationPackages.Registrar.class)
static class Registrar implements ImportBeanDefinitionRegistrar, DeterminableImports {@Overridepublic void registerBeanDefinitions(AnnotationMetadata metadata,BeanDefinitionRegistry registry) {register(registry, new PackageImport(metadata).getPackageName());}……}
注册当前启动类的根package;注册org.springframework.boot.autoconfigure.AutoConfigurationPackages的BeanDefinition。
AutoConfigurationPackage注解的作用是将添加该注解的类所在的package作为自动配置package 进行管理。
可以通过 AutoConfigurationPackages 工具类获取自动配置package列表。当通过注解@SpringBootApplication标注启动类时,已经为启动类添加了@AutoConfigurationPackage注解。路径为 @SpringBootApplication -> @EnableAutoConfiguration -> @AutoConfigurationPackage。也就是说当SpringBoot应用启动时默认会将启动类所在的package作为自动配置的package。
如我们创建了一个sbia-demo的应用,下面包含一个启动模块demo-bootstrap,启动类时Bootstrap,它添加了@SpringBootApplication注解,我们通过测试用例可以看到自动配置package为com.tm.sbia.demo.boot。
可以从图中看出AutoConfigurationImportSelector实现了 DeferredImportSelector 从 ImportSelector继承的方法:selectImports。
@Overridepublic String[] selectImports(AnnotationMetadata annotationMetadata) { if (!isEnabled(annotationMetadata)) { return NO_IMPORTS; } AutoConfigurationMetadata autoConfigurationMetadata = AutoConfigurationMetadataLoader .loadMetadata(this.beanClassLoader); AnnotationAttributes attributes = getAttributes(annotationMetadata); List<String> configurations = getCandidateConfigurations(annotationMetadata, attributes); configurations = removeDuplicates(configurations); Set<String> exclusions = getExclusions(annotationMetadata, attributes); checkExcludedClasses(configurations, exclusions); configurations.removeAll(exclusions); configurations = filter(configurations, autoConfigurationMetadata); fireAutoConfigurationImportEvents(configurations, exclusions); return StringUtils.toStringArray(configurations);}
第9行List configurations =getCandidateConfigurations(annotationMetadata,`attributes);其实是去加载各个组件jar下的 public static final String FACTORIES_RESOURCE_LOCATION = "META-INF/spring.factories";外部文件。
如果获取到类信息,spring可以通过类加载器将类加载到jvm中,现在我们已经通过spring-boot的starter依赖方式依赖了我们需要的组件,那么这些组件的类信息在select方法中就可以被获取到。
protected List<String> getCandidateConfigurations(AnnotationMetadata metadata, AnnotationAttributes attributes) { List<String> configurations = SpringFactoriesLoader.loadFactoryNames(this.getSpringFactoriesLoaderFactoryClass(), this.getBeanClassLoader()); Assert.notEmpty(configurations, "No auto configuration classes found in META-INF/spring.factories. If you are using a custom packaging, make sure that file is correct."); return configurations; }
其返回一个自动配置类的类名列表,方法调用了loadFactoryNames方法,查看该方法。
public static List<String> loadFactoryNames(Class<?> factoryClass, @Nullable ClassLoader classLoader) { String factoryClassName = factoryClass.getName(); return (List)loadSpringFactories(classLoader).getOrDefault(factoryClassName, Collections.emptyList());}
自动配置器会跟根据传入的factoryClass.getName()到项目系统路径下所有的spring.factories文件中找到相应的key,从而加载里面的类。
这个外部文件,有很多自动配置的类。如下:
其中,最关键的要属@Import(AutoConfigurationImportSelector.class),借助AutoConfigurationImportSelector,@EnableAutoConfiguration可以帮助SpringBoot应用将所有符合条件(spring.factories)的bean定义(如Java Config@Configuration配置)都加载到当前SpringBoot创建并使用的IoC容器。
其实SpringFactoriesLoader的底层原理就是借鉴于JDK的SPI机制,所以,在将SpringFactoriesLoader之前,我们现在发散一下SPI机制。
SPI ,全称为 Service Provider Interface,是一种服务发现机制。它通过在ClassPath路径下的META-INF/services文件夹查找文件,自动加载文件里所定义的类。这一机制为很多框架扩展提供了可能,比如在Dubbo、JDBC中都使用到了SPI机制。我们先通过一个很简单的例子来看下它是怎么用的。
首先,我们需要定义一个接口,SPIService。
package com.example.springbootvipjtdemo.spidemo;/** * @author Eclipse_2019 * @create 2022/6/8 17:55 */public interface SPIService { void doSomething();}
然后,定义两个实现类,没别的意思,只输入一句话。
package com.example.springbootvipjtdemo.spidemo;/** * @author Eclipse_2019 * @create 2022/6/8 17:56 */public class SpiImpl1 implements SPIService{ @Override public void doSomething() { System.out.println("第一个实现类干活。。。"); }}----------------------我是乖巧的分割线----------------------package com.example.springbootvipjtdemo.spidemo;/** * @author Eclipse_2019 * @create 2022/6/8 17:56 */public class SpiImpl2 implements SPIService{ @Override public void doSomething() { System.out.println("第二个实现类干活。。。"); }}
最后呢,要在ClassPath路径下配置添加一个文件。文件名字是接口的全限定类名,内容是实现类的全限定类名,多个实现类用换行符分隔。
文件路径如下:
内容就是实现类的全限定类名:
com.example.springbootvipjtdemo.spidemo.SpiImpl1com.example.springbootvipjtdemo.spidemo.SpiImpl2
然后我们就可以通过ServiceLoader.load或者Service.providers方法拿到实现类的实例。其中,Service.providers包位于sun.misc.Service,而ServiceLoader.load包位于java.util.ServiceLoader。
public class TestSPI { public static void main(String[] args) { Iterator<SPIService> providers = Service.providers(SPIService.class); ServiceLoader<SPIService> load = ServiceLoader.load(SPIService.class); while(providers.hasNext()) { SPIService ser = providers.next(); ser.doSomething(); } System.out.println("--------------------------------"); Iterator<SPIService> iterator = load.iterator(); while(iterator.hasNext()) { SPIService ser = iterator.next(); ser.doSomething(); } }}
两种方式的输出结果是一致的:
第一个实现类干活。。。第二个实现类干活。。。--------------------------------第一个实现类干活。。。第二个实现类干活。。。
我们看到一个位于sun.misc包,一个位于java.util包,sun包下的源码看不到。我们就以ServiceLoader.load为例,通过源码看看它里面到底怎么做的。
首先,我们先来了解下ServiceLoader,看看它的类结构。
public final class ServiceLoader<S> implements Iterable<S>//配置文件的路径private static final String PREFIX = "META-INF/services/";//加载的服务类或接口private final Class<S> service;//已加载的服务类集合private LinkedHashMap<String,S> providers = new LinkedHashMap<>();//类加载器private final ClassLoader loader;//内部类,真正加载服务类private LazyIterator lookupIterator;}
load方法创建了一些属性,重要的是实例化了内部类,LazyIterator。最后返回ServiceLoader的实例。
public final class ServiceLoader<S> implements Iterable<S>private ServiceLoader(Class<S> svc, ClassLoader cl) {//要加载的接口service = Objects.requireNonNull(svc, "Service interface cannot be null");//类加载器loader = (cl == null) ? ClassLoader.getSystemClassLoader() : cl;//访问控制器acc = (System.getSecurityManager() != null) ? AccessController.getContext() : null;//先清空providers.clear();//实例化内部类LazyIterator lookupIterator = new LazyIterator(service, loader);}}
查找实现类和创建实现类的过程,都在LazyIterator完成。当我们调用iterator.hasNext和iterator.next方法的时候,实际上调用的都是LazyIterator的相应方法。
public Iterator<S> iterator() {return new Iterator<S>() {public boolean hasNext() {return lookupIterator.hasNext();}public S next() {return lookupIterator.next();}.......};}
所以,我们重点关注lookupIterator.hasNext()方法,它最终会调用到hasNextService。
private class LazyIterator implements Iterator<S>{ Class<S> service; ClassLoader loader; Enumeration<URL> configs = null; Iterator<String> pending = null; String nextName = null; private boolean hasNextService() { //第二次调用的时候,已经解析完成了,直接返回 if (nextName != null) { return true; } if (configs == null) { //META-INF/services/ 加上接口的全限定类名,就是文件服务类的文件 //META-INF/services/com.viewscenessupervisor.spi.SPIService String fullName = PREFIX + service.getName(); //将文件路径转成URL对象 configs = loader.getResources(fullName); } while ((pending == null) || !pending.hasNext()) { //解析URL文件对象,读取内容,最后返回 pending = parse(service, configs.nextElement()); } //拿到第一个实现类的类名 nextName = pending.next(); return true; }}
当然,调用next方法的时候,实际调用到的是,lookupIterator.nextService。它通过反射的方式,创建实现类的实例并返回。
private class LazyIterator implements Iterator<S>{private S nextService() {//全限定类名String cn = nextName;nextName = null;//创建类的Class对象Class<?> c = Class.forName(cn, false, loader);//通过newInstance实例化S p = service.cast(c.newInstance());//放入集合,返回实例providers.put(cn, p);return p;}}
看到这儿,我想已经很清楚了。获取到类的实例,我们自然就可以对它为所欲为了!
我们开头说,SPI机制为很多框架的扩展提供了可能,其实JDBC就应用到了这一机制。回忆一下JDBC获取数据库连接的过程。在早期版本中,需要先设置数据库驱动的连接,再通过DriverManager.getConnection获取一个Connection。
String url = "jdbc:mysql:///consult?serverTimezone=UTC";String user = "root";String password = "root";Class.forName("com.mysql.jdbc.Driver");Connection connection = DriverManager.getConnection(url, user, password);
在较新版本中(具体哪个版本,笔者没有验证),设置数据库驱动连接,这一步骤就不再需要,那么它是怎么分辨是哪种数据库的呢?答案就在SPI。
我们把目光回到DriverManager类,它在静态代码块里面做了一件比较重要的事。很明显,它已经通过SPI机制, 把数据库驱动连接初始化了。
public class DriverManager { static { loadInitialDrivers(); println("JDBC DriverManager initialized"); }}
具体过程还得看loadInitialDrivers,它在里面查找的是Driver接口的服务类,所以它的文件路径就是:META-INF/services/java.sql.Driver。
public class DriverManager { private static void loadInitialDrivers() { AccessController.doPrivileged(new PrivilegedAction<Void>() { public Void run() { //很明显,它要加载Driver接口的服务类,Driver接口的包为:java.sql.Driver //所以它要找的就是META-INF/services/java.sql.Driver文件 ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class); Iterator<Driver> driversIterator = loadedDrivers.iterator(); try{ //查到之后创建对象 while(driversIterator.hasNext()) { driversIterator.next(); } } catch(Throwable t) { // Do nothing } return null; } }); }}
那么,这个文件哪里有呢?我们来看MySQL的jar包,就是这个文件,文件内容为:
com.mysql.cj.jdbc.Driver。
上一步已经找到了MySQL中的com.mysql.jdbc.Driver全限定类名,当调用next方法时,就会创建这个类的实例。它就完成了一件事,向DriverManager注册自身的实例。
public class Driver extends NonRegisteringDriver implements java.sql.Driver { static { try { //注册 //调用DriverManager类的注册方法 //往registeredDrivers集合中加入实例 java.sql.DriverManager.registerDriver(new Driver()); } catch (SQLException E) { throw new RuntimeException("Can't register driver!"); } } public Driver() throws SQLException { // Required for Class.forName().newInstance() }}
在DriverManager.getConnection()方法就是创建连接的地方,它通过循环已注册的数据库驱动程序,调用其connect方法,获取连接并返回。
private static Connection getConnection( String url, java.util.Properties info, Class<?> caller) throws SQLException { //registeredDrivers中就包含com.mysql.cj.jdbc.Driver实例 for(DriverInfo aDriver : registeredDrivers) { if(isDriverAllowed(aDriver.driver, callerCL)) { try { //调用connect方法创建连接 Connection con = aDriver.driver.connect(url, info); if (con != null) { return (con); } }catch (SQLException ex) { if (reason == null) { reason = ex; } } } else { println(" skipping: " + aDriver.getClass().getName()); } }}
既然我们知道JDBC是这样创建数据库连接的,我们能不能再扩展一下呢?如果我们自己也创建一个java.sql.Driver文件,自定义实现类MyDriver,那么,在获取连接的前后就可以动态修改一些信息。
还是先在项目ClassPath下创建文件,文件内容为自定义驱动类com.viewscenessupervisor.spi.MyDriver我们的MyDriver实现类,继承自MySQL中的NonRegisteringDriver,还要实现java.sql.Driver接口。这样,在调用connect方法的时候,就会调用到此类,但实际创建的过程还靠MySQL完成。
package com.viewscenessupervisor.spipublic class MyDriver extends NonRegisteringDriver implements Driver{ static { try { java.sql.DriverManager.registerDriver(new MyDriver()); } catch (SQLException E) { throw new RuntimeException("Can't register driver!"); } } public MyDriver()throws SQLException {} public Connection connect(String url, Properties info) throws SQLException { System.out.println("准备创建数据库连接.url:"+url); System.out.println("JDBC配置信息:"+info); info.setProperty("user", "root"); Connection connection = super.connect(url, info); System.out.println("数据库连接创建完成!"+connection.toString()); return connection; }}--------------------输出结果---------------------准备创建数据库连接.url:jdbc:mysql:///consult?serverTimezone=UTCJDBC配置信息:{user=root, password=root}数据库连接创建完成!com.mysql.cj.jdbc.ConnectionImpl@7cf10a6f
借助于Spring框架原有的一个工具类:SpringFactoriesLoader的支持,@EnableAutoConfiguration可以智能的自动配置功效才得以大功告成!
SpringFactoriesLoader属于Spring框架私有的一种扩展方案,其主要功能就是从指定的配置文件META-INF/spring.factories加载配置,加载工厂类。
SpringFactoriesLoader为Spring工厂加载器,该对象提供了loadFactoryNames方法,入参为factoryClass和classLoader即需要传入工厂类名称和对应的类加载器,方法会根据指定的classLoader,加载该类加器搜索路径下的指定文件,即spring.factories文件。
传入的工厂类为接口,而文件中对应的类则是接口的实现类,或最终作为实现类。
public abstract class SpringFactoriesLoader {//... public static <T> List<T> loadFactories(Class<T> factoryClass, ClassLoader classLoader) { ... } public static List<String> loadFactoryNames(Class<?> factoryClass, ClassLoader classLoader) { .... }}
配合@EnableAutoConfiguration使用的话,它更多是提供一种配置查找的功能支持,即根据@EnableAutoConfiguration的完整类名org.springframework.boot.autoconfigure.EnableAutoConfiguration作为查找的Key,获取对应的一组@Configuration类
上图就是从SpringBoot的autoconfigure依赖包中的META-INF/spring.factories配置文件中摘录的一段内容,可以很好地说明问题。
(重点)所以,@EnableAutoConfiguration自动配置的魔法其实就变成了:
从classpath中搜寻所有的META-INF/spring.factories配置文件,并将其中
org.springframework.boot.autoconfigure.EnableAutoConfiguration对应的配置项通过反射(Java Refletion)实例化为对应的标注了@Configuration的JavaConfig形式的IoC容器配置类,然后汇总为一个并加载到IoC容器。
本文链接://www.dmpip.com//www.dmpip.com/showinfo-26-11764-0.html玩转SpringBoot—自动装配解决Bean的复杂配置
声明:本网页内容旨在传播知识,若有侵权等问题请及时与本网联系,我们将在第一时间删除处理。邮件:2376512515@qq.com
上一篇: 彻底搞懂Spring的Bean加载