关于java:spring中让你眼前一亮的代码技巧

一. @Conditional 的弱小之处

不晓得你们有没有遇到过这些问题：

• 某个性能须要依据我的项目中有没有某个 jar 判断是否开启该性能。
• 某个 bean 的实例化须要先判断另一个 bean 有没有实例化，再判断是否实例化本人。
• 某个性能是否开启，在配置文件中有个参数能够对它进行管制。

如果你有遇到过上述这些问题，那么祝贺你，本节内容非常适合你。

@ConditionalOnClass

问题 1 能够用 @ConditionalOnClass注解解决，代码如下：

public class A {
}

public class B {
}

@ConditionalOnClass(B.class)
@Configuration
public class TestConfiguration {

    @Bean
    public A a() {return new A();
    }
}
复制代码

如果我的项目中存在 B 类，则会实例化 A 类。如果不存在 B 类，则不会实例化 A 类。

有人可能会问：不是判断有没有某个 jar 吗？怎么当初判断某个类了？

直接判断有没有该 jar 下的某个要害类更简略。

这个注解有个升级版的利用场景：比方 common 工程中写了一个发消息的工具类 mqTemplate，业务工程援用了 common 工程，只需再引入消息中间件，比方 rocketmq 的 jar 包，就能开启 mqTemplate 的性能。而如果有另一个业务工程，通用援用了 common 工程，如果不须要发消息的性能，不引入 rocketmq 的 jar 包即可。

这个注解的性能还是挺实用的吧？

@ConditionalOnBean

问题 2 能够通过 @ConditionalOnBean 注解解决，代码如下：

@Configuration
public class TestConfiguration {

    @Bean
    public B b() {return new B();
    }

    @ConditionalOnBean(name="b")
    @Bean
    public A a() {return new A();
    }
}
复制代码

实例 A 只有在实例 B 存在时，能力实例化。

@ConditionalOnProperty

问题 3 能够通过 @ConditionalOnProperty 注解解决，代码如下：

@ConditionalOnProperty(prefix = "demo",name="enable", havingValue = "true",matchIfMissing=true)
@Configuration
public class TestConfiguration {

    @Bean
    public A a() {return new A();
    }
}
复制代码

在 applicationContext.properties 文件中配置参数：

demo.enable=false
复制代码

各参数含意：

• prefix 示意参数名的前缀，这里是 demo
• name 示意参数名
• havingValue 示意指定的值，参数中配置的值须要跟指定的值比拟是否相等，相等才满足条件
• matchIfMissing 示意是否容许缺省配置。

这个性能能够作为开关，相比 EnableXXX 注解的开关更优雅，因为它能够通过参数配置是否开启，而 EnableXXX 注解的开关须要在代码中硬编码开启或敞开。

其余的 Conditional 注解

当然，spring用得比拟多的 Conditional 注解还有：ConditionalOnMissingClass、ConditionalOnMissingBean、ConditionalOnWebApplication 等。

上面用一张图整体认识一下 @Conditional 家族。

自定义 Conditional

说实话，集体认为 springboot 自带的 Conditional 系列曾经能够满足咱们绝大多数的需要了。但如果你有比拟非凡的场景，也能够自定义自定义 Conditional。

第一步，自定义注解：

@Conditional(MyCondition.class)
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD})
@Documented
public @interface MyConditionOnProperty {String name() default "";

    String havingValue() default "";}
复制代码

第二步，实现 Condition 接口：

public class MyCondition implements Condition {
    @Override
    public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {System.out.println("实现自定义逻辑");
        return false;
    }
}
复制代码

第三步，应用 @MyConditionOnProperty 注解。

Conditional的神秘就藏在 ConfigurationClassParser 类的 processConfigurationClass 办法中：

这个办法逻辑不简单：

1. 先判断有没有应用 Conditional 注解，如果没有间接返回 false
2. 收集 condition 到汇合中
3. 按 order 排序该汇合
4. 遍历该汇合，循环调用 condition 的 matchs 办法。

二. 如何妙用 @Import？

有时咱们须要在某个配置类中引入另外一些类，被引入的类也加到 spring 容器中。这时能够应用 @Import 注解实现这个性能。

如果你看过它的源码会发现，引入的类反对三种不同类型。

然而我认为最好将一般类和 @Configuration 注解的配置类离开解说，所以列了四种不同类型：

一般类

这种引入形式是最简略的，被引入的类会被实例化 bean 对象。

public class A {
}

@Import(A.class)
@Configuration
public class TestConfiguration {
}
复制代码

通过 @Import 注解引入 A 类，spring 就能主动实例化 A 对象，而后在须要应用的中央通过 @Autowired 注解注入即可：

@Autowired
private A a;
复制代码

是不是挺让人意外的？不必加 @Bean 注解也能实例化 bean。

@Configuration 注解的配置类

这种引入形式是最简单的，因为 @Configuration 注解还反对多种组合注解，比方：

• @Import
• @ImportResource
• @PropertySource 等。

public class A {
}

public class B {
}

@Import(B.class)
@Configuration
public class AConfiguration {

    @Bean
    public A a() {return new A();
    }
}

@Import(AConfiguration.class)
@Configuration
public class TestConfiguration {
}
复制代码

通过 @Import 注解引入 @Configuration 注解的配置类，会把该配置类相干 @Import、@ImportResource、@PropertySource 等注解引入的类进行递归，一次性全副引入。

因为文章篇幅无限不过多介绍了，这里留点悬念，前面会出一篇文章专门介绍 @Configuration 注解，因为它切实太太太重要了。

实现 ImportSelector 接口的类

这种引入形式须要实现 ImportSelector 接口：

public class AImportSelector implements ImportSelector {

private static final String CLASS_NAME = "com.sue.cache.service.test13.A";
    
 public String[] selectImports(AnnotationMetadata importingClassMetadata) {return new String[]{CLASS_NAME};
    }
}

@Import(AImportSelector.class)
@Configuration
public class TestConfiguration {
}
复制代码

这种形式的益处是 selectImports 办法返回的是数组，意味着能够同时引入多个类，还是十分不便的。

实现 ImportBeanDefinitionRegistrar 接口的类

这种引入形式须要实现 ImportBeanDefinitionRegistrar 接口：

public class AImportBeanDefinitionRegistrar implements ImportBeanDefinitionRegistrar {
    @Override
    public void registerBeanDefinitions(AnnotationMetadata importingClassMetadata, BeanDefinitionRegistry registry) {RootBeanDefinition rootBeanDefinition = new RootBeanDefinition(A.class);
        registry.registerBeanDefinition("a", rootBeanDefinition);
    }
}

@Import(AImportBeanDefinitionRegistrar.class)
@Configuration
public class TestConfiguration {
}
复制代码

这种形式是最灵便的，能在 registerBeanDefinitions 办法中获取到 BeanDefinitionRegistry 容器注册对象，能够手动管制 BeanDefinition 的创立和注册。

当然 @import 注解十分人性化，还反对同时引入多种不同类型的类。

@Import({B.class,AImportBeanDefinitionRegistrar.class})
@Configuration
public class TestConfiguration {
}
复制代码

这四种引入类的形式各有千秋，总结如下：

1. 一般类，用于创立没有特殊要求的 bean 实例。
2. @Configuration 注解的配置类，用于层层嵌套引入的场景。
3. 实现 ImportSelector 接口的类，用于一次性引入多个类的场景，或者能够依据不同的配置决定引入不同类的场景。
4. 实现 ImportBeanDefinitionRegistrar 接口的类，次要用于能够手动管制 BeanDefinition 的创立和注册的场景，它的办法中能够获取 BeanDefinitionRegistry 注册容器对象。

在 ConfigurationClassParser 类的 processImports 办法中能够看到这三种形式的解决逻辑：

最初的 else 办法其实蕴含了：一般类和 @Configuration 注解的配置类两种不同的解决逻辑。

三. @ConfigurationProperties 赋值

咱们在我的项目中应用配置参数是十分常见的场景，比方，咱们在配置线程池的时候，须要在 applicationContext.propeties 文件中定义如下配置：

thread.pool.corePoolSize=5
thread.pool.maxPoolSize=10
thread.pool.queueCapacity=200
thread.pool.keepAliveSeconds=30
复制代码

办法一：通过 @Value 注解读取这些配置。

public class ThreadPoolConfig {@Value("${thread.pool.corePoolSize:5}")
    private int corePoolSize;

    @Value("${thread.pool.maxPoolSize:10}")
    private int maxPoolSize;

    @Value("${thread.pool.queueCapacity:200}")
    private int queueCapacity;

    @Value("${thread.pool.keepAliveSeconds:30}")
    private int keepAliveSeconds;

    @Value("${thread.pool.threadNamePrefix:ASYNC_}")
    private String threadNamePrefix;

    @Bean
    public Executor threadPoolExecutor() {ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(corePoolSize);
        executor.setMaxPoolSize(maxPoolSize);
        executor.setQueueCapacity(queueCapacity);
        executor.setKeepAliveSeconds(keepAliveSeconds);
        executor.setThreadNamePrefix(threadNamePrefix);
        executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
        executor.initialize();
        return executor;
    }
}
复制代码

这种形式应用起来非常简单，但倡议在应用时都加上 :，因为: 前面跟的是默认值，比方：@Value(“${thread.pool.corePoolSize:5}”)，定义的默认外围线程数是 5。

如果有这样的场景：business 工程下定义了这个 ThreadPoolConfig 类，api 工程援用了 business 工程，同时 job 工程也援用了 business 工程，而 ThreadPoolConfig 类只想在 api 工程中应用。这时，如果不配置默认值，job 工程启动的时候可能会报错。

如果参数少还好，多的话，须要给每一个参数都加上 @Value 注解，是不是有点麻烦？

此外，还有一个问题，@Value 注解定义的参数看起来有点扩散，不容易分别哪些参数是一组的。

这时，@ConfigurationProperties 就派上用场了，它是 springboot 中新加的注解。

第一步，先定义 ThreadPoolProperties 类

@Data @Component @ConfigurationProperties(“thread.pool”) public class ThreadPoolProperties {

private int corePoolSize;
private int maxPoolSize;
private int queueCapacity;
private int keepAliveSeconds;
private String threadNamePrefix;
复制代码

} 第二步，应用 ThreadPoolProperties 类

@Configuration public class ThreadPoolConfig {

@Autowired
private ThreadPoolProperties threadPoolProperties;

@Bean
public Executor threadPoolExecutor() {ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
    executor.setCorePoolSize(threadPoolProperties.getCorePoolSize());
    executor.setMaxPoolSize(threadPoolProperties.getMaxPoolSize());
    executor.setQueueCapacity(threadPoolProperties.getQueueCapacity());
    executor.setKeepAliveSeconds(threadPoolProperties.getKeepAliveSeconds());
    executor.setThreadNamePrefix(threadPoolProperties.getThreadNamePrefix());
    executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
    executor.initialize();
    return executor;
}
复制代码

} 应用 @ConfigurationProperties 注解，能够将 thread.pool 结尾的参数间接赋值到 ThreadPoolProperties 类的同名参数中，这样省去了像 @Value 注解那样一个个手动去对应的过程。

这种形式显然要不便很多，咱们只需编写 xxxProperties 类，spring 会主动拆卸参数。此外，不同系列的参数能够定义不同的 xxxProperties 类，也便于管理，举荐优先应用这种形式。

它的底层是通过：ConfigurationPropertiesBindingPostProcessor类实现的，该类实现了 BeanPostProcessor 接口，在 postProcessBeforeInitialization 办法中解析 @ConfigurationProperties 注解，并且绑定数据到相应的对象上。

绑定是通过 Binder 类的 bindObject 办法实现的：

以上这段代码会递归绑定数据，次要思考了三种状况：

• bindAggregate 绑定汇合类
• bindBean 绑定对象
• bindProperty 绑定参数 后面两种状况最终也会调用到 bindProperty 办法。

「此外，情谊揭示一下：」

应用 @ConfigurationProperties 注解有些场景有问题，比方：在 apollo 中批改了某个参数，失常状况能够动静更新到 @ConfigurationProperties 注解定义的 xxxProperties 类的对象中，然而如果呈现比较复杂的对象，比方：

private Map<String, Map<String,String>>  urls;
复制代码

可能动静更新不了。

这时候该怎么办呢？

答案是应用 ApolloConfigChangeListener 监听器本人解决：

@ConditionalOnClass(com.ctrip.framework.apollo.spring.annotation.EnableApolloConfig.class)
public class ApolloConfigurationAutoRefresh implements ApplicationContextAware {
   private ApplicationContext applicationContext;
   
   @Override
   public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {this.applicationContext = applicationContext;}
   
    @ApolloConfigChangeListener
    private void onChange(ConfigChangeEvent changeEvent{refreshConfig(changeEvent.changedKeys());
    }
    private void refreshConfig(Set<String> changedKeys){System.out.println("将变更的参数更新到相应的对象中");
    }
}
复制代码

四. spring 事务要如何避坑？

spring 中的事务性能次要分为：申明式事务 和编程式事务。

申明式事务

大多数状况下，咱们在开发过程中应用更多的可能是申明式事务，即应用 @Transactional 注解定义的事务，因为它用起来更简略，不便。

只需在须要执行的事务办法上，加上 @Transactional 注解就能主动开启事务：

@Service
public class UserService {

    @Autowired
    private UserMapper userMapper;
    
    @Transactional
    public void add(UserModel userModel) {userMapper.insertUser(userModel);
    }
}
复制代码

这种申明式事务之所以能失效，是因为它的底层应用了 AOP，创立了代理对象，调用TransactionInterceptor 拦截器实现事务的性能。

spring 事务有个特地的中央：它获取的数据库连贯放在 ThreadLocal 中的，也就是说同一个线程中从始至终都能获取同一个数据库连贯，能够保障同一个线程中屡次数据库操作在同一个事务中执行。

失常状况下是没有问题的，然而如果使用不当，事务会生效，次要起因如下：

除了上述列举的问题之外，因为 @Transactional 注解最小粒度是要被定义在办法上，如果有多层的事务办法调用，可能会造成大事务问题。 所以，倡议在理论工作中少用 @Transactional 注解开启事务。

编程式事务

个别状况下编程式事务咱们能够通过 TransactionTemplate 类开启事务性能。有个好消息，就是 springboot 曾经默认实例化好这个对象了，咱们能间接在我的项目中应用。

@Service
public class UserService {
   @Autowired
   private TransactionTemplate transactionTemplate;
   
   ...
   
   public void save(final User user) {transactionTemplate.execute((status) => {
            doSameThing...
            return Boolean.TRUE;
         })
   }
}
复制代码

应用 TransactionTemplate 的编程式事务能防止很多事务生效的问题，然而对大事务问题，不肯定可能解决，只是说绝对于应用 @Transactional 注解要好些。

五. 跨域问题的解决方案

对于跨域问题，前后端的解决方案还是挺多的，这里我重点说说 spring 的解决方案，目前有三种：

一. 应用 @CrossOrigin 注解

@RequestMapping("/user")
@RestController
public class UserController {@CrossOrigin(origins = "http://localhost:8016")
    @RequestMapping("/getUser")
    public String getUser(@RequestParam("name") String name) {System.out.println("name:" + name);
        return "success";
    }
}
复制代码

该计划须要在跨域拜访的接口上加 @CrossOrigin 注解，拜访规定能够通过注解中的参数管制，管制粒度更细。如果须要跨域拜访的接口数量较少，能够应用该计划。

二. 减少全局配置

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {registry.addMapping("/**")
                .allowedOrigins("*")
                .allowedMethods("GET", "POST")
                .allowCredentials(true)
                .maxAge(3600)
                .allowedHeaders("*");

    }
}
复制代码

该计划须要实现 WebMvcConfigurer 接口，重写 addCorsMappings 办法，在该办法中定义跨域拜访的规定。这是一个全局的配置，能够利用于所有接口。

三. 自定义过滤器

@WebFilter("corsFilter")
@Configuration
public class CorsFilter implements Filter {

    @Override
    public void init(FilterConfig filterConfig) throws ServletException { }

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {HttpServletResponse httpServletResponse = (HttpServletResponse) response;
        httpServletResponse.setHeader("Access-Control-Allow-Origin", "*");
        httpServletResponse.setHeader("Access-Control-Allow-Methods", "POST, GET");
        httpServletResponse.setHeader("Access-Control-Max-Age", "3600");
        httpServletResponse.setHeader("Access-Control-Allow-Headers", "x-requested-with");
        chain.doFilter(request, response);
    }

    @Override
    public void destroy() {}
}
复制代码

该计划通过在申请的 header 中减少 Access-Control-Allow-Origin 等参数解决跨域问题。

顺便说一下，应用 @CrossOrigin 注解 和 实现 WebMvcConfigurer 接口的计划，spring 在底层最终都会调用到 DefaultCorsProcessor 类的 handleInternal 办法：

最终三种计划必由之路，都会往 header 中增加跨域须要参数，只是实现模式不一样而已。

六. 如何自定义 starter

以前在没有应用 starter 时，咱们在我的项目中须要引入新性能，步骤个别是这样的：

• 在 maven 仓库找该性能所需 jar 包
• 在 maven 仓库找该 jar 所依赖的其余 jar 包
• 配置新性能所需参数

以上这种形式会带来三个问题：

1. 如果依赖包较多，找起来很麻烦，容易找错，而且要花很多工夫。
2. 各依赖包之间可能会存在版本兼容性问题，我的项目引入这些 jar 包后，可能没法失常启动。
3. 如果有些参数没有配好，启动服务也会报错，没有默认配置。

「为了解决这些问题，springboot 的 starter 机制应运而生」。

starter 机制带来这些益处：

1. 它能启动相应的默认配置。
2. 它可能管理所需依赖，解脱了须要到处找依赖 和 兼容性问题的困扰。
3. 主动发现机制，将 spring.factories 文件中配置的类，主动注入到 spring 容器中。
4. 遵循“约定大于配置”的理念。

在业务工程中只需引入 starter 包，就能应用它的性能，太爽了。

上面用一张图，总结 starter 的几个因素：

接下来咱们一起实战，定义一个本人的 starter。

第一步，创立 id-generate-starter 工程： 其中的 pom.xml 配置如下：

<?xml version="1.0" encoding="UTF-8"?>

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <version>1.3.1</version>
    <groupId>com.sue</groupId>
    <artifactId>id-generate-spring-boot-starter</artifactId>
    <name>id-generate-spring-boot-starter</name>
    <dependencies>
        <dependency>
            <groupId>com.sue</groupId>
            <artifactId>id-generate-spring-boot-autoconfigure</artifactId>
            <version>1.3.1</version>
        </dependency>
    </dependencies>
</project>
复制代码

第二步，创立 id-generate-spring-boot-autoconfigure 工程： 该我的项目当中蕴含：

• pom.xml
• spring.factories
• IdGenerateAutoConfiguration
• IdGenerateService
• IdProperties

pom.xml 配置如下：

<?xml version="1.0" encoding="UTF-8"?>

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.0.4.RELEASE</version>
    </parent>
    <modelVersion>4.0.0</modelVersion>
    <version>1.3.1</version>
    <groupId>com.sue</groupId>
    <artifactId>id-generate-spring-boot-autoconfigure</artifactId>
    <name>id-generate-spring-boot-autoconfigure</name>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-autoconfigure</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-configuration-processor</artifactId>
            <optional>true</optional>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <source>1.8</source>
                    <target>1.8</target>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>
复制代码

spring.factories配置如下：

org.springframework.boot.autoconfigure.EnableAutoConfiguration=com.sue.IdGenerateAutoConfiguration

IdGenerateAutoConfiguration 类：@ConditionalOnClass(IdProperties.class)
@EnableConfigurationProperties(IdProperties.class)
@Configuration
public class IdGenerateAutoConfiguration {

    @Autowired
    private IdProperties properties;

    @Bean
    public IdGenerateService idGenerateService() {return new IdGenerateService(properties.getWorkId());
    }
}
复制代码

IdGenerateService 类：

public class IdGenerateService {

    private Long workId;

    public IdGenerateService(Long workId) {this.workId = workId;}

    public Long generate() {return new Random().nextInt(100) + this.workId;
    }
}
复制代码

IdProperties 类：

@ConfigurationProperties(prefix = IdProperties.PREFIX)
public class IdProperties {


    public static final String PREFIX = "sue";

    private Long workId;

    public Long getWorkId() {return workId;}

    public void setWorkId(Long workId) {this.workId = workId;}
}
复制代码

这样在业务我的项目中引入相干依赖:

<dependency>
      <groupId>com.sue</groupId>
      <artifactId>id-generate-spring-boot-starter</artifactId>
      <version>1.3.1</version>
</dependency>
复制代码

就能应用注入应用 IdGenerateService 的性能了

@Autowired
private IdGenerateService idGenerateService;
复制代码

完满。

七. 我的项目启动时的附加性能

有时候咱们须要在我的项目启动时定制化一些附加性能，比方：加载一些零碎参数、实现初始化、预热本地缓存等，该怎么办呢？

好消息是 springboot 提供了：

• CommandLineRunner
• ApplicationRunner

这两个接口帮忙咱们实现以上需要。

它们的用法还是挺简略的，以 ApplicationRunner 接口为例：

@Component
public class TestRunner implements ApplicationRunner {

    @Autowired
    private LoadDataService loadDataService;

    public void run(ApplicationArguments args) throws Exception {loadDataService.load();
    }
    
}
复制代码

实现 ApplicationRunner 接口，重写 run 办法，在该办法中实现本人定制化需要。

如果我的项目中有多个类实现了 ApplicationRunner 接口，他们的执行程序要怎么指定呢？

答案是应用 @Order(n) 注解，n 的值越小越先执行。当然也能够通过 @Priority 注解指定程序。

springboot我的项目启动时次要流程是这样的：

在 SpringApplication 类的 callRunners 办法中，咱们能看到这两个接口的具体调用：

最初还有一个问题：这两个接口有什么区别？

CommandLineRunner接口中 run 办法的参数为 String 数组 ApplicationRunner 中run办法的参数为 ApplicationArguments，该参数蕴含了String 数组参数 和 一些可选参数。

唠唠家常

写着写着又有这么多字了，依照常规，为了防止篇幅过长，明天就先写到这里。预报一下，前面会有 AOP、BeanPostProcessor、Configuration 注解等外围知识点的专题，每个主题的内容都挺多的，能够期待一下喔。

参考：《2020 最新 Java 根底精讲视频教程和学习路线！》
链接：https://juejin.cn/post/693505…