本文基于Spring 5.2.7
这是个很大的话题，但是是个非常实在的话题，注解天天用，处处用，请问你知道他是怎么起作用的吗？
如果你使用了注解，那么一定有代码在什么地方检索这个注解，并为这个注解的语义写了对应的逻辑。但是注解本身是没有任何行为的，他只是一个标记而已。所以注解是惰性的，看到注解时并没有行为，你需要找到注解对应的行为才能理解注解实际的作用。
但是要找到一个注解对应的行为很难，因为很多注解都是些三方库提供的，要想找到每个注解对应的行为有如大海捞针，能搞清楚这个知识点很难。
一、SpringBoot启动
SpringBoot要解析哪些注解在代码中已经写死了，所有注解的解析都是按照既定的顺序在执行，如@Configuration，@Import，这些都会在启动过程中解析，所以一切的起点是启动类上，但是，我们会看到启动类上往往是一个汇总的注解，如@EnableTransactionManagement，然后这个类上面会引入其他注解，那Spring是怎么解析到他引入的注解的呢？
原理就是Spring在扫描注解是一种递归的方式，比如在处理@Import注解时，就会递归处理：
org.springframework.context.annotation.ConfigurationClassParser#collectImports(...)
private void collectImports(SourceClass sourceClass, Set<SourceClass> imports, Set<SourceClass> visited)
throws IOException {
if (visited.add(sourceClass)) {
for (SourceClass annotation : sourceClass.getAnnotations()) {
String annName = annotation.getMetadata().getClassName();
if (!annName.equals(Import.class.getName())) {
collectImports(annotation, imports, visited);
}
}
imports.addAll(sourceClass.getAnnotationAttributes(Import.class.getName(), "value"));
}
}
这是Spring在启动解析配置时，递归解析注解，这里的sourceClass就是启动类，然后递归检查启动类上的@Import注解，所以才能检查到注解上的注解。
一般而言，spring会扫描所有的类，而且会扫描这些类上面的注解，Spring自身提供了很多注解，你写了Spring提供的注解，他就会扫描到，进而执行响应的动作。
你可以在启动类上写很多注解，必须要写的注解是org.springframework.boot.autoconfigure.SpringBootApplication
我们已经写了main()方法，SpringBoot已经自主启动运行，此时他会回过头来扫描启动类上的注解并解析，其实SpringBootApplication这个注解本身并没有语义，他是一个复合注解，用于引入其他的注解，这就要求Spring在扫描注解时能够递归扫描，实际上Spring就是这么做的。在判断一个bean上是否有某个注解时，Spring都是递归解析注解的。或者说所有的复合注解都是没有语义的，有语义的是复合注解上的单个注解。
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan(excludeFilters = { @Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class),
@Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) })
public @interface SpringBootApplication {
/**
* Exclude specific auto-configuration classes such that they will never be applied.
* @return the classes to exclude
*/
@AliasFor(annotation = EnableAutoConfiguration.class)
Class<?>[] exclude() default {};
/**
* Exclude specific auto-configuration class names such that they will never be
* applied.
* @return the class names to exclude
* @since 1.3.0
*/
@AliasFor(annotation = EnableAutoConfiguration.class)
String[] excludeName() default {};
/**
* Base packages to scan for annotated components. Use {@link #scanBasePackageClasses}
* for a type-safe alternative to String-based package names.
* <p>
* <strong>Note:</strong> this setting is an alias for
* {@link ComponentScan @ComponentScan} only. It has no effect on {@code @Entity}
* scanning or Spring Data {@link Repository} scanning. For those you should add
* {@link org.springframework.boot.autoconfigure.domain.EntityScan @EntityScan} and
* {@code @Enable...Repositories} annotations.
* @return base packages to scan
* @since 1.3.0
*/
@AliasFor(annotation = ComponentScan.class, attribute = "basePackages")
String[] scanBasePackages() default {};
/**
* Type-safe alternative to {@link #scanBasePackages} for specifying the packages to
* scan for annotated components. The package of each class specified will be scanned.
* <p>
* Consider creating a special no-op marker class or interface in each package that
* serves no purpose other than being referenced by this attribute.
* <p>
* <strong>Note:</strong> this setting is an alias for
* {@link ComponentScan @ComponentScan} only. It has no effect on {@code @Entity}
* scanning or Spring Data {@link Repository} scanning. For those you should add
* {@link org.springframework.boot.autoconfigure.domain.EntityScan @EntityScan} and
* {@code @Enable...Repositories} annotations.
* @return base packages to scan
* @since 1.3.0
*/
@AliasFor(annotation = ComponentScan.class, attribute = "basePackageClasses")
Class<?>[] scanBasePackageClasses() default {};
/**
* Specify whether {@link Bean @Bean} methods should get proxied in order to enforce
* bean lifecycle behavior, e.g. to return shared singleton bean instances even in
* case of direct {@code @Bean} method calls in user code. This feature requires
* method interception, implemented through a runtime-generated CGLIB subclass which
* comes with limitations such as the configuration class and its methods not being
* allowed to declare {@code final}.
* <p>
* The default is {@code true}, allowing for 'inter-bean references' within the
* configuration class as well as for external calls to this configuration's
* {@code @Bean} methods, e.g. from another configuration class. If this is not needed
* since each of this particular configuration's {@code @Bean} methods is
* self-contained and designed as a plain factory method for container use, switch
* this flag to {@code false} in order to avoid CGLIB subclass processing.
* <p>
* Turning off bean method interception effectively processes {@code @Bean} methods
* individually like when declared on non-{@code @Configuration} classes, a.k.a.
* "@Bean Lite Mode" (see {@link Bean @Bean's javadoc}). It is therefore behaviorally
* equivalent to removing the {@code @Configuration} stereotype.
* @since 2.2
* @return whether to proxy {@code @Bean} methods
*/
@AliasFor(annotation = Configuration.class)
boolean proxyBeanMethods() default true;
}
SpringBoot的run()方法里已经执行了很多事情，他里面就会扫描所有bean，并处理相关注解。启动类上面的注解此时也会被处理。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
