一. @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
办法中:
这个办法逻辑不简单:
- 先判断有没有应用 Conditional 注解,如果没有间接返回 false
- 收集 condition 到汇合中
- 按 order 排序该汇合
- 遍历该汇合,循环调用 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 {
}
复制代码
这四种引入类的形式各有千秋,总结如下:
- 一般类,用于创立没有特殊要求的 bean 实例。
- @Configuration 注解的配置类,用于层层嵌套引入的场景。
- 实现 ImportSelector 接口的类,用于一次性引入多个类的场景,或者能够依据不同的配置决定引入不同类的场景。
- 实现 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 包
- 配置新性能所需参数
以上这种形式会带来三个问题:
- 如果依赖包较多,找起来很麻烦,容易找错,而且要花很多工夫。
- 各依赖包之间可能会存在版本兼容性问题,我的项目引入这些 jar 包后,可能没法失常启动。
- 如果有些参数没有配好,启动服务也会报错,没有默认配置。
「为了解决这些问题,springboot 的 starter 机制应运而生」。
starter 机制带来这些益处:
- 它能启动相应的默认配置。
- 它可能管理所需依赖,解脱了须要到处找依赖 和 兼容性问题的困扰。
- 主动发现机制,将 spring.factories 文件中配置的类,主动注入到 spring 容器中。
- 遵循“约定大于配置”的理念。
在业务工程中只需引入 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…