Error message here!

Hide Error message here!

忘记密码?

Error message here!

请输入正确邮箱

Hide Error message here!

密码丢失?请输入您的电子邮件地址。您将收到一个重设密码链接。

Error message here!

返回登录

Close

Spring中你可能不知道的事(二)

CodeBear 2019-01-22 16:37:00 阅读数:223 评论数:0 点赞数:0 收藏数:0

在上一节中,我介绍了Spring中极为重要的BeanPostProcessor BeanFactoryPostProcessor Import ImportSelector,还介绍了一些其他的零碎知识点,正如我上一节所说的,Spring实在是太庞大了,是众多Java开发大神的结晶,很多功能,很多细节,可能一辈子都不会用到,不会发现,作为普通开发的我们,只能尽力去学习,去挖掘,也许哪天可以用到呢。

让我们进入正题吧。

Full Lite

在上一节中的第一块内容,我们知道了Spring中除了可以注册我们最常用的配置类,还可以注册一个普通的Bean,今天我就来做一个补充说明。

如果你接到一个需求,要求写一个配置类,完成扫描,你会怎么写?

作为经常使用Spring的来说,这是一个入门级别的问题,并且在20秒钟之内就可以完成编码:

@Configuration
@ComponentScan
public class AppConfig {
}
public class Main {
public static void main(String[] args) {
AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(AppConfig.class);
context.getBean(ServiceImpl.class).query();
}
}
@Component
public class ServiceImpl{
public void query() {
System.out.println("正在查询中");
}
}

运行:

image.png

但是你有没有尝试过把AppConfig类上的@Configuration注解给去除?你在心里肯定会犯嘀咕,这不能去除啊,这个@Configuration注解申明了咱们的AppConfig是一个Spring配置类,去除了@Configuration注解,怎么可能可以呢?但是事实胜于雄辩,当我们把@Configuration注解给删除,再次运行,你会见证到奇迹:

@ComponentScan
public class AppConfig {
}
public class Main {
public static void main(String[] args) {
AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(AppConfig.class);
context.getBean(ServiceImpl.class).query();
}
}

image.png

一点问题都没有!!!是不是到这里已经颠覆了你对Spring的认知。

其实,在Spring内部,把带上了@Configuration的配置类称之为Full配置类,把没有带上@Configuration,但是带上了@Component @ComponentScan @Import @ImportResource等注解的配置类称之为Lite配置类。

原谅我,实在找不到合适的中文翻译来表述这里的Full和Lite。

也许你会觉得这并没什么用,只是“茴的四种写法”而已。

别急,让我们看下去,将会继续刷新你的三观:

@ComponentScan
public class AppConfig {
}

注意现在的AppConfig类上没有加上@Configuration注解。

public class Main {
public static void main(String[] args) {
AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(AppConfig.class);
System.out.println(context.getBean(AppConfig.class).getClass().getSimpleName());
}
}

我们注册了Lite配置类,并且从Spring容器中取出了Lite配置类,打印出它的类名。

运行:

image.png

可以看到从容器取出来的就是AppConfig类,各位看官肯定会想,这不是废话吗,难道从容器取出来会变成了一只老母鸡?

别急嘛,让我们继续。

我们再在AppConfig类加上@Configuration注解,使其变成Full配置类,然后还是一样,注册这个配置类,取出这个配置类,打印类名:

image.png

你会惊讶的发现,的确从容器里取出了一个老母鸡,哦,不,是一个奇怪的类,从类名我们可以看到CGLIB这个关键字,CGLIB是动态代理的一种实现方式,也就是说我们的Full配置类被CGLIB代理了。

你是不是从来都没有注意过,竟然会有如此奇怪的设定,但是更让人惊讶的事情还在后头,让我们想想,为什么好端端的类,Spring要用Cglib代理?这又不是AOP。Spring内部肯定做了一些什么!没错,确实做了!!!

下面让我们看看Spring到底做了什么:

public class ServiceImpl {
public ServiceImpl() {
System.out.println("ServiceImpl类的构造方法");
}
}

ServiceImpl类中有一个构造方法,打印了一句话。

public class OtherImpl {
}

再定义一个OtherImpl类,里面什么都没有。

public class AppConfig {
@Bean
public ServiceImpl getServiceImpl() {
return new ServiceImpl();
}
@Bean
public OtherImpl getOtherImpl() {
getServiceImpl();
return new OtherImpl();
}
}

这个AppConfig没有加上@Configuration注解,是一个Lite配置类,里面定义了两个@Bean方法,其中getServiceImpl方法创建并且返回了ServiceImpl类的对象,getOtherImpl方法再次调用了getServiceImpl方法。

然后我们注册这个配置类:

public class Main {
public static void main(String[] args) {
AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(AppConfig.class);
}
}

运行:

image.png

发现打印了两次"ServiceImpl类的构造方法",这也很好理解,因为new了两次ServiceImpl嘛,肯定会执行两次ServiceImpl构造方法呀。

我们在把@Configuration注解给加上,让AppConfig称为一个Full配置类,再次运行:

image.png

你会惊讶的发现只打印了一次"ServiceImpl类的构造方法",说明只调用了一次ServiceImpl类的构造方法,其实这也说的通啊,因为Bean默认是Singleton的,所以只会创建一次对象嘛。

但是问题来了,为什么我们明明new了两次ServiceImpl类,但是真正只new了一次?结合上面的内容,很容易知道答案,因为Full配置类被Cglib代理了,它已经不是我们原先定义的AppConfig类了,最终执行的是代理对象。

好了,这个问题就讨论到这里,至于为什么说(如何证明)带上@Configuration注解的配置类称之为Full配置类,不带的称之为Lite配置类,Cglib是怎么代理Full配置类的,代理的规则又是什么,这就涉及到Spring的源码解析了,就不在今天的讨论内容之中了。

ImportBeanDefinitionRegistrar

大家一定使用过Mybatis,甚至使用过Mybatis的扩展,我在使用的时候,觉得太特么的神奇了,只要在配置类上打一个MapperScan注解,指定需要扫描哪些包,然后这些包里面只有接口,根本没有实现类,为什么可以完成数据库的一系列操作,不知道大家有没有和我一样的疑惑,直到我知道了ImportBeanDefinitionRegistrar这个神奇的接口,关于这个接口,我不知道该怎么去描述这个接口的作用,因为这个接口实在是太强大了,实在不是用简单的文字可以描述清楚的。下面我就利用这个接口来完成一个假的MapperScan,从中慢慢体验这个接口的强大,对了,这个接口要和Import注解配合使用。

首先需要定义一个注解:

@Import(CodeBearMapperScannerRegistrar.class)
@Retention(RetentionPolicy.RUNTIME)
public @interface CodeBearMapperScanner {
String value();
}

其中value就是需要扫描的包名,在这个注解类中又打了一个Import注解,来引ImportBeanDefinitionRegistrar类。

再定义一个注解:

@Retention(RetentionPolicy.RUNTIME)
public @interface CodeBearSql {
String value();
}

这个注解是打在方法上的,接收的是一个sql语句。

然后要定义一个类,去实现ImportBeanDefinitionRegistrar接口,重写提供的方法。

public class CodeBearMapperScannerRegistrar implements ImportBeanDefinitionRegistrar, ResourceLoaderAware {
private ResourceLoader resourceLoader;
@Override
public void registerBeanDefinitions(AnnotationMetadata importingClassMetadata, BeanDefinitionRegistry registry) {
try {
AnnotationAttributes annoAttrs =
AnnotationAttributes.fromMap(importingClassMetadata.getAnnotationAttributes(CodeBearMapperScanner.class.getName()));
String packageValue = annoAttrs.getString("value");
String pathValue = packageValue.replace(".", "/");
File[] files = resourceLoader.getResource(pathValue).getFile().listFiles();
for (File file : files) {
String name = file.getName().replace(".class", "");
Class<?> aClass = Class.forName(packageValue + "." + name);
if (aClass.isInterface()&&!aClass.isAnnotation()) {
BeanDefinitionBuilder beanDefinitionBuilder = BeanDefinitionBuilder.genericBeanDefinition();
AbstractBeanDefinition beanDefinition = beanDefinitionBuilder.getBeanDefinition();
beanDefinition.setBeanClass(CodeBeanFactoryBean.class);
beanDefinition.getConstructorArgumentValues().addGenericArgumentValue(packageValue + "." + name);
registry.registerBeanDefinition(name, beanDefinition);
}
}
} catch (Exception ex) {
}
}
@Override
public void setResourceLoader(ResourceLoader resourceLoader) {
this.resourceLoader = resourceLoader;
}
}

其中ResourceLoaderAware接口的作用不大,我只是利用这个接口,获得了ResourceLoader ,然后通过ResourceLoader去获得包下面的类而已。这方法的核心就是循环文件列表,根据包名和文件名,反射获得Class,接着判断Class是不是接口,如果是接口的话,动态注册Bean。如何动态去注册Bean呢?我在这里利用的是BeanDefinitionBuilder,通过BeanDefinitionBuilder获得一个BeanDefinition,此时BeanDefinition是一个很纯净的BeanDefinition,经过一些处理,再把最终的BeanDefinition注册到Spring容器。

关键就在于处理的这两行代码了,这里可能还看不懂,我们继续看下去。

我们需要再定义一个类,去实现FactoryBean,InvocationHandler两个接口:

public class CodeBeanFactoryBean implements FactoryBean, InvocationHandler {
private Class clazz;
public CodeBeanFactoryBean(Class clazz) {
this.clazz = clazz;
}
@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
CodeBearSql annotation = method.getAnnotation(CodeBearSql.class);
String sql= annotation.value();
System.out.println(sql);
return sql;
}
@Override
public Object getObject() throws Exception {
Object o = Proxy.newProxyInstance(this.getClass().getClassLoader(), new Class[]{clazz}, this);
return o;
}
@Override
public Class<?> getObjectType() {
return clazz;
}
}

关于FactoryBean接口,在上一节中有介绍,这里就不再阐述了。

这个类有一个构造方法,接收的是一个Class,这里接收的就是用来进行数据库操作的接口。getObject方法中,就利用传进来的接口和动态代理来创建一个代理对象,此时这个代理对象就是FactoryBean生产的一个Bean了,只要对JDK动态代理有一定了解的人都知道,返回出来的代理对象实现了我们用来进行数据库操作的接口。

我们需要把这个Bean交给Spring去管理,所以就有了CodeBearMapperScannerRegistrar中的这行代码:

beanDefinition.setBeanClass(CodeBeanFactoryBean.class);

因为创建CodeBeanFactoryBean对象需要一个Class参数。所以就有了CodeBearMapperScannerRegistrar中的这行代码:

//packageValue + "." +name 就是接口的全名称
beanDefinition.getConstructorArgumentValues().addGenericArgumentValue(packageValue + "." + name);

invoke方法比较简单,就是获得CodeBearSql注解上的sql语句,然后打印一下,当然这里只是模拟下,所以并没有去查询数据库。

下面让我们测试一下吧:

public interface UserRepo {
@CodeBearSql(value = "select * from user")
void get();
}
@Configuration
@CodeBearMapperScanner("com.codebear")
@ComponentScan
public class AppConfig {
}
@Service
public class Test {
@Autowired
UserRepo userRepo;
public void get(){
userRepo.get();
}
}

运行结果:
image.png
可以看到我们的功能已经实现了。其实Mybatis的MapperScan注解也是利用了ImportBeanDefinitionRegistrar接口去实现的。

可以看到第二块内容,其实已经比较复杂了,不光光有ImportBeanDefinitionRegistrar,还整合FactoryBean,还融入了动态代理。如果我们不知道FactoryBean,可能这个需求就很难实现了。所以每一块知识点都很重要。

这一节的内容到这里就结束了。

版权声明
本文为[CodeBear]所创,转载请带上原文链接,感谢
https://www.cnblogs.com/CodeBear/p/10304605.html

编程之旅,人生之路,不止于编程,还有诗和远方。
阅代码原理,看框架知识,学企业实践;
赏诗词,读日记,踏人生之路,观世界之行;

支付宝红包,每日可领