【SpringBoot2 从0开始】底层注解 - @Configuration

简介: 【SpringBoot2 从0开始】底层注解 - @Configuration

一、配置类


@Configuration这个注解作用就是告诉 springboot 这是一个配置类。


这个配置已经不陌生了,在之前 spring 相关的使用全注解方式时,就使用到了配置类。


在配置类里,可以使用@Bean标记在方法上,给容器注册组件,默认也是单实例的。


@Configuration //告诉SpringBoot这是一个配置类 == 配置文件
public class MyConfig {
    @Bean("user1") //给容器中添加组件。以方法名作为组件的id。返回类型就是组件类型。返回的值,就是组件在容器中的实例
    public User user01(){
        return new User("pingguo", 20);
    }
    @Bean("pet1")
    public Pet tomcatPet(){
        return new Pet("tomcat");
    }
}


主运行类还是之前示例中的,打印出所有组件的名称。


1268169-20210829225823108-2132174323.png


可以看到,有上面注册的 2 个组件:user1、pet1。


二、配置类本身也是组件


在主运行类的 main 方法里,加一个获取配置类的输出:


@SpringBootApplication(scanBasePackages = "com.pingguo")
public class MainApplication {
    public static void main(String[] args) {
        // 返回IOC容器
        final ConfigurableApplicationContext run = SpringApplication.run(MainApplication.class, args);
        // 查看容器里的组件
        final String[] beanDefinitionNames = run.getBeanDefinitionNames();
        for (String name: beanDefinitionNames) {
            System.out.println(name);
        }
        // 从容器中获取组件
        MyConfig bean = run.getBean(MyConfig.class);
        System.out.println("配置类也是组件:" + bean);
    }
}


运行 main 方法,


1268169-20210829230448832-1582133845.png


可以看到最后一个输出,说明配置类本身也是个组件。


三、proxyBeanMethods 属性


从springboot2.0之后,@Configuration 中多了一个属性 proxyBeanMethods,用来代理 bean 的。


默认值是true,也就是说该配置类会被代理(CGLIB),在同一个配置文件中调用其它被@Bean注解标注的方法获取对象时,springboot 总会检查容器中是否存在这个组件。

如果容器中存在,直接取。不存在的话,才会去创建,保证单实例。


现在看下false的情况。


@Configuration(proxyBeanMethods = false) //改成 false
public class MyConfig {
    @Bean("user1") //给容器中添加组件。以方法名作为组件的id。返回类型就是组件类型。返回的值,就是组件在容器中的实例
    public User user01(){
        return new User("pingguo", 20);
    }
    @Bean("pet1")
    public Pet tomcatPet(){
        return new Pet("tomcat");
    }
}


在主运行程序里多从调用方法获取对象,判断一下对象是否相等。


@SpringBootApplication(scanBasePackages = "com.pingguo")
public class MainApplication {
    public static void main(String[] args) {
        // 返回IOC容器
        final ConfigurableApplicationContext run = SpringApplication.run(MainApplication.class, args);
        // 查看容器里的组件
        final String[] beanDefinitionNames = run.getBeanDefinitionNames();
        for (String name: beanDefinitionNames) {
            System.out.println(name);
        }
        // 从容器中获取组件
        MyConfig bean = run.getBean(MyConfig.class);
        System.out.println("配置类也是组件:" + bean);
        User user1 = bean.user01();
        User user2 = bean.user01();
        System.out.println(user1 == user2);
    }
}


看最后的输出,会是 false。


1268169-20210830223519585-632301509.png


这里引出 2 个名词:Full 全模式,Lite 轻量级模式。


  • Full (proxyBeanMethods = true) : 该模式下注入容器中的同一个组件无论被取出多少次都是同一个bean实例,即单实例对象,
    在该模式下 SpringBoot 每次启动都会判断检查容器中是否存在该组件。
  • Lite (proxyBeanMethods = false): 该模式下注入容器中的同一个组件无论被取出多少次都是不同的bean实例,即多实例对象,


在该模式下 SpringBoot 每次启动会跳过检查容器中是否存在该组件。


那么这个是用来解决什么场景的问题呢?答案:组件依赖。


有组件依赖的场景


看下2个实体类:User、Pet。


public class User {
    private String name;
    private Integer age;
    private Pet pet;
... ...


固定代码部分:有参构造、无参构造、get和set方法、toString方法,就省去了。


public class Pet {
    private String name;
... ...


修改下配置类里的方法:


@Configuration(proxyBeanMethods = true)
public class MyConfig {
    @Bean("user1") 
    public User user01(){
        User pingguo = new User("pingguo",20);
        pingguo.setPet(tomcatPet());
        return pingguo;
    }
    @Bean("pet1")
    public Pet tomcatPet(){
        return new Pet("tomcat");
    }
}


到main方法测试一下:


// 依赖关系
    User user01 = run.getBean("user1", User.class);
    Pet pet1 = run.getBean("pet1", Pet.class);
    System.out.println("依赖:" + (user01.getPet() == pet1));


这里就是判断当proxyBeanMethods = true的情况下,User对象的 pet,是不是容器中的 pet。


如果是,那么结果就是true


1268169-20210830230338156-1907453948.png


此时再将proxyBeanMethods = false,重新运行一下,结果会是 false:


1268169-20210830230529570-1670451730.png


那么这 2 个模式分别在什么时候用呢?


当在你的同一个Configuration配置类中,注入到容器中的 bean 实例之间有依赖关系时,建议使用 Full 全模式。


当在你的同一个Configuration配置类中,注入到容器中的 bean 实例之间没有依赖关系时,建议使用 Lite 轻量级模式,以提高 springboot 的启动速度和性能。

相关文章
|
XML 安全 Java
使用 Spring 的 @Aspect 和 @Pointcut 注解简化面向方面的编程 (AOP)
面向方面编程(AOP)通过分离横切关注点,如日志、安全和事务,提升代码模块化与可维护性。Spring 提供了对 AOP 的强大支持,核心注解 `@Aspect` 和 `@Pointcut` 使得定义切面与切入点变得简洁直观。`@Aspect` 标记切面类,集中处理通用逻辑;`@Pointcut` 则通过表达式定义通知的应用位置,提高代码可读性与复用性。二者结合,使开发者能清晰划分业务逻辑与辅助功能,简化维护并提升系统灵活性。Spring AOP 借助代理机制实现运行时织入,与 Spring 容器无缝集成,支持依赖注入与声明式配置,是构建清晰、高内聚应用的理想选择。
960 0
|
缓存 监控 Java
SpringBoot @Scheduled 注解详解
使用`@Scheduled`注解实现方法周期性执行,支持固定间隔、延迟或Cron表达式触发,基于Spring Task,适用于日志清理、数据同步等定时任务场景。需启用`@EnableScheduling`,注意线程阻塞与分布式重复问题,推荐结合`@Async`异步处理,提升任务调度效率。
1771 128
|
Java 测试技术 API
将 Spring 的 @Embedded 和 @Embeddable 注解与 JPA 结合使用的指南
Spring的@Embedded和@Embeddable注解简化了JPA中复杂对象的管理,允许将对象直接嵌入实体,减少冗余表与连接操作,提升数据库设计效率。本文详解其用法、优势及适用场景。
536 126
|
Java 测试技术 数据库
使用Spring的@Retryable注解进行自动重试
在现代软件开发中,容错性和弹性至关重要。Spring框架提供的`@Retryable`注解为处理瞬时故障提供了一种声明式、可配置的重试机制,使开发者能够以简洁的方式增强应用的自我恢复能力。本文深入解析了`@Retryable`的使用方法及其参数配置,并结合`@Recover`实现失败回退策略,帮助构建更健壮、可靠的应用程序。
1260 1
使用Spring的@Retryable注解进行自动重试
|
XML Java 应用服务中间件
【SpringBoot(一)】Spring的认知、容器功能讲解与自动装配原理的入门,带你熟悉Springboot中基本的注解使用
SpringBoot专栏开篇第一章,讲述认识SpringBoot、Bean容器功能的讲解、自动装配原理的入门,还有其他常用的Springboot注解!如果想要了解SpringBoot,那么就进来看看吧!
925 2
|
XML Java 数据格式
常用SpringBoot注解汇总与用法说明
这些注解的使用和组合是Spring Boot快速开发和微服务实现的基础,通过它们,可以有效地指导Spring容器进行类发现、自动装配、配置、代理和管理等核心功能。开发者应当根据项目实际需求,运用这些注解来优化代码结构和服务逻辑。
791 12
|
传感器 Java 数据库
探索Spring Boot的@Conditional注解的上下文配置
Spring Boot 的 `@Conditional` 注解可根据不同条件动态控制 Bean 的加载,提升应用的灵活性与可配置性。本文深入解析其用法与优势,并结合实例展示如何通过自定义条件类实现环境适配的智能配置。
745 0
探索Spring Boot的@Conditional注解的上下文配置
|
智能设计 Java 测试技术
Spring中最大化@Lazy注解,实现资源高效利用
本文深入探讨了 Spring 框架中的 `@Lazy` 注解,介绍了其在资源管理和性能优化中的作用。通过延迟初始化 Bean,`@Lazy` 可显著提升应用启动速度,合理利用系统资源,并增强对 Bean 生命周期的控制。文章还分析了 `@Lazy` 的工作机制、使用场景、最佳实践以及常见陷阱与解决方案,帮助开发者更高效地构建可扩展、高性能的 Spring 应用程序。
492 0
Spring中最大化@Lazy注解,实现资源高效利用
|
安全 IDE Java
Spring 的@FieldDefaults和@Data:Lombok 注解以实现更简洁的代码
本文介绍了如何在 Spring 应用程序中使用 Project Lombok 的 `@Data` 和 `@FieldDefaults` 注解来减少样板代码,提升代码可读性和可维护性,并探讨了其适用场景与限制。
407 0
Spring 的@FieldDefaults和@Data:Lombok 注解以实现更简洁的代码