第八节条件装配案例讲解

一、条件装配的作用是什么

条件装配是 Spring 框架中一个强大的特性，使得开发者能够创建更加灵活和可维护的应用程序。在 Spring Boot 中，这个特性被大量用于自动配置，极大地简化了基于 Spring 的应用开发。

二、条件装配注解

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-autoconfigure</artifactId>
  <version>${version}</version>
</dependency>

下面以版本2.1.13.RELEASE为例子。下面是包路径

org.springframework.boot.autoconfigure.condition.XXX

2.1 条件注解

2.2 条件注解说明

下面是相关注解的简单说明，标注颜色的可以重点关注

注解	作用
@ConditionalOnBean	当容器中存在指定的Bean时，满足条件。
@ConditionalOnMissingBean	当容器中不存在指定的Bean时，满足条件。
@ConditionalOnClass	当类路径上存在指定的类时，满足条件。
@ConditionalOnMissingClass	当类路径上缺少指定的类时，满足条件。
@ConditionalOnProperty	当存在指定的配置属性，并且属性值与给定的值相匹配时，满足条件。
@ConditionalOnResource	当指定的资源存在于类路径上时，满足条件。
@ConditionalOnExpression	基于SpEL表达式的结果，当表达式为true时，满足条件。
@ConditionalOnJava	当Java的版本匹配指定的条件时，满足条件。
@ConditionalOnWebApplication	当应用程序是一个Web应用时，满足条件。
@ConditionalOnNotWebApplication	当应用程序不是一个Web应用时，满足条件。
@ConditionalOnJndi	当指定的JNDI存在时，满足条件。
@ConditionalOnSingleCandidate	当容器中只存在一个指定的Bean，或者即使有多个也有一个被标记为首选时，满足条件。

前面5个可以重点关注，它是最常用的。在第三节中，我将分别针对上面的几个案例进行举例说明。

三、条件装配举例说明

用代码的方式来展示条件装配的作用，以及在实际生活中到底如何使用。

3.1 灵活性举例

场景描述：

假设我们正在开发一个多环境支持的应用程序，该应用在开发环境中使用基于内存的数据库（如 H2），而在生产环境中使用更稳定和持久的关系数据库（如 PostgreSQL）。

实现方式：

不使用条件装配时，我们可能需要在应用程序的不同版本中手动更改数据源配置，或者在代码中进行环境检查来决定使用哪个数据库。这样做会增加维护工作，也容易出错。

使用条件装配，我们可以利用注解来根据环境自动配置不同的数据源：

@Configuration
@ConditionalOnProperty(name = "use-in-memory-db", havingValue = "true")
public class H2DatabaseConfig {
    // Configuration for H2 Database
}

@Configuration
@ConditionalOnProperty(name = "use-in-memory-db", havingValue = "false")
public class PostgresDatabaseConfig {
    // Configuration for PostgreSQL Database
}

例子解释：

在这个例子中，我们有两个配置类，分别为 H2DatabaseConfig 和 PostgresDatabaseConfig。它们都使用了 @ConditionalOnProperty 注解来判断一个名为 use-in-memory-db 的属性的值。

如果 use-in-memory-db 属性设置为 true，Spring Boot 会实例化 H2DatabaseConfig 类并使用 H2 数据库配置。
如果 use-in-memory-db 属性设置为 false，Spring Boot 会实例化 PostgresDatabaseConfig 类并使用 PostgreSQL 数据库配置

提示：案例演示了 @ConditionalOnProperty 使用方式。

3.2 自动装配案例

根据配置，选择使用不通的缓存实现类。

简化实现

public interface CacheService {
    void put(String key, Object value);
    Object get(String key);
}

Redis 缓存服务实现:

@Configuration
@ConditionalOnClass(name = "redis.clients.jedis.Jedis")
public class RedisCacheConfig {

    @Bean
    public CacheService redisCacheService() {
        return new RedisCacheService();
    }

    // RedisCacheService 实现了 CacheService 接口
    // 使用 Redis 客户端进行具体的缓存操作
}

内存缓存服务实现:

@Configuration
@ConditionalOnMissingClass(value = "redis.clients.jedis.Jedis")
public class InMemoryCacheConfig {

    @Bean
    public CacheService inMemoryCacheService() {
        return new InMemoryCacheService();
    }

    // InMemoryCacheService 实现了 CacheService 接口
    // 使用 Java Map 进行缓存操作
}

在这个例子中，我们有两个配置类 RedisCacheConfig 和 InMemoryCacheConfig，它们都定义了一个用于条件装配的 CacheService Bean。

@ConditionalOnClass(name = "redis.clients.jedis.Jedis") 注解在 RedisCacheConfig 类上，表明如果类路径包含 Redis 的 Jedis 客户端类，则创建和注册 RedisCacheService 为 CacheService 的实现。

相对地，@ConditionalOnMissingClass(value = "redis.clients.jedis.Jedis") 注解在 InMemoryCacheConfig 类上，表明如果类路径不包含 Redis 的 Jedis 客户端类，则创建和注册 InMemoryCacheService 为 CacheService 的实现。

在这个条件装配的例子中，Spring Boot 应用会自动检查 Redis 客户端库是否存在，并基于检查结果来决定使用哪个缓存实现。这个过程完全自动化，无需开发者介入，也无需修改配置文件。如果你将 Redis 客户端库添加到项目的依赖中，Spring Boot 将自动配置使用 RedisCacheService；如果移除了相关依赖，则会回退到使用 InMemoryCacheService。

提示：案例演示了 @ConditionalOnClass、 ConditionalOnClass的使用方式。

3.4 避免条件冲突举例

假设我们的应用程序中既可以使用JPA来访问数据库，也可以使用MyBatis。但是，我们希望这两个持久层框架不要同时生效，以免它们尝试操作同一个数据库实体时产生冲突

JPA配置类:

@Configuration
@ConditionalOnClass(name = "org.springframework.data.jpa.repository.JpaRepository")
public class JpaConfig {
    // 这里配置JPA相关的Bean，例如EntityManagerFactory, TransactionManager等
}

MyBatis配置类:

@Configuration
@ConditionalOnClass(name = "org.mybatis.spring.SqlSessionFactoryBean")
@ConditionalOnMissingBean(type = "org.springframework.data.jpa.repository.JpaRepository")
public class MyBatisConfig {
    // 这里配置MyBatis相关的Bean，例如SqlSessionFactory, DataSource等
}

例子解释：

@ConditionalOnClass 注解检查类路径上是否存在指定的类。在这个例子中，JpaConfig 类上的 @ConditionalOnClass 注解会检查JPA的 JpaRepository 是否存在于类路径上，如果存在，那么JPA的相关配置就会被注册。

MyBatisConfig 类上同时使用了 @ConditionalOnClass 和 @ConditionalOnMissingBean 注解。@ConditionalOnClass 注解会检查类路径上是否存在MyBatis的 SqlSessionFactoryBean 类；而 @ConditionalOnMissingBean 注解则确保只有在不存在 JpaRepository 类型的Bean时，MyBatis的配置才会生效

避免Bean冲突：

这种配置方法确保了当两种持久层技术的类都存在于类路径上时，只有JPA的配置会生效，因为 JpaConfig 没有额外的限制条件。而MyBatis的配置则只有在JPA不可用（即类路径上没有 JpaRepository）时才会生效，从而避免了同时注册JPA和MyBatis持久层可能引起的Bean冲突。

举例说明，实际案例。以 tomcat 容器为例子。

请思考这样一个场景，为什么，我们的 SpringBoot 项目，不再关注 tomcat、jetty 容器了呢；他们的加载装配是如何实现的呢？

当Spring Boot在类路径上发现tomcat-embedded.jar时，它会自动配置Tomcat作为应用程序的默认服务器。同样，如果它发现jetty-embedded.jar，而没有发现Tomcat，那么它将配置Jetty服务器。

以下是简化后的Tomcat和Jetty自动配置的源码示例，用于解释Spring Boot是如何使用条件注解来实现自动配置的。

Tomcat自动配置：

@Configuration(proxyBeanMethods = false)
@ConditionalOnClass({Servlet.class, Tomcat.class, UpgradeProtocol.class})
@ConditionalOnMissingBean(value = ServletWebServerFactory.class, search = SearchStrategy.CURRENT)
public class TomcatServletWebServerFactoryConfiguration {

    @Bean
    public TomcatServletWebServerFactory tomcatServletWebServerFactory() {
        return new TomcatServletWebServerFactory();
    }

}

上面的配置类使用了@ConditionalOnClass注解，它意味着只有当Servlet、Tomcat和UpgradeProtocol这三个类都存在于类路径上时，该配置类才会被考虑。此外，@ConditionalOnMissingBean注解确保只有在当前上下文中不存在ServletWebServerFactory类型的Bean时，才会创建TomcatServletWebServerFactory的Bean。

3.5 提升性能

避免加载和初始化不需要的组件，可以提升应用程序的启动速度和运行时性能

Spring Boot 条件装配通过确保只有在需要时才创建和注册特定的 Beans，从而帮助提高应用程序的启动速度和运行时性能。这将避免浪费资源去加载和初始化那些在当前应用程序环境中不需要的组件。

下面是一个代码示例，它展示了如何使用 Spring Boot 条件装配来决定是否配置一个用于性能监控的组件。

场景描述：

假设我们的应用程序包含一个性能监控组件，这个组件在生产环境中是有用的，但在开发和测试环境中可能不需要它，因为它可能会降低应用的性能和增加额外的资源消耗.

@Configuration
@ConditionalOnProperty(name = "app.monitoring.enable", havingValue = "true")
public class PerformanceMonitoringConfig {

    @Bean
    public PerformanceMonitor performanceMonitor() {
        // 初始化性能监控组件
        return new PerformanceMonitor();
    }

    // 其它与性能监控相关的Beans...
}

在这个例子中，我们创建了一个配置类 PerformanceMonitoringConfig，它包含了创建 PerformanceMonitor Bean 的方法。类上的 @ConditionalOnProperty 注解告诉 Spring Boot，只有当 app.monitoring.enable 属性的值设置为 true 时，才创建 PerformanceMonitor Bean。

应用配置文件：

开发或测试环境 application-dev.properties 或 application-test.properties:

# 在开发和测试环境中，禁用性能监控
app.monitoring.enable=false

生产环境 :

# 在生产环境中，启用性能监控
app.monitoring.enable=true

提升性能的效果：

通过上述条件装配的方式，Spring Boot应用会根据配置文件中的属性值决定是否加载和初始化性能监控组件。这种机制确保了在开发和测试环境中，不会因为性能监控组件的存在而造成不必要的性能开销；而在生产环境中，性能监控组件才会被激活，为我们提供关键的性能数据。

这样的条件装配策略有助于在不同的环境中优化资源使用和应用性能，因为只有真正需要的组件才会被加载，从而加快了应用程序的启动时间，并在运行时提高了性能。

3.6 Profile（补充）

根据环境不同（开发环境和生产环境）来使用不同的邮件服务实现。在生产环境中，我们使用真实的邮件服务，而在开发环境中，我们使用一个模拟的邮件服务以避免发送真实的邮件。

public interface EmailService {
    void sendEmail(String to, String subject, String content);
}

定义邮件服务接口:

除去上面的注解外，在 Spring 中也提供了 Profile 来实现一定的条件装配。

生产环境的邮件服务实现:

@Profile("prod")
@Service
public class SmtpEmailService implements EmailService {
    // SMTP邮件服务相关的配置和方法
    public void sendEmail(String to, String subject, String content) {
        // 实际的邮件发送逻辑
    }
}

开发环境的邮件服务模拟实现:

@Profile("dev")
@Service
public class MockEmailService implements EmailService {
    // 模拟邮件服务的相关配置和方法
    public void sendEmail(String to, String subject, String content) {
        System.out.println("Mock email sent to " + to + " with subject " + subject);
        // 其他模拟操作
    }
}

在这个例子中，我们定义了一个邮件服务的接口 EmailService 和两个实现 SmtpEmailService 以及 MockEmailService。每个实现类上都使用了 Spring 的 @Profile 注解来指定它应该在哪个应用配置文件激活的情况下被注册。