Spring学习（一）

@Bean、@Configuration、@Component、 @Service、 @Repository 和 @Controller注解

首先声明两点：

1、除了@Bean，其他注解都被注解@Component修饰了，所以是基于@Component的扩展，只不过不同的业务场景作用不一样，共同点：都可以用来注入IOC容器生成Bean对象，当使用基于注解的配置和类路径扫描的时候，这些类就会被实例化、被扫描到IOC容器中。

2、这些注解都是用来注入IOC容器，生成Bean对象的（还需要配置自动组件扫描才可以哦，即@ComponentScan），只不过@Bean比较特殊，需要写在方法上，被@Bean修饰的方法的返回值用来生成Bean对象，id默认为方法名，方法的返回值可以是接口、实现类，生成的bean是方法中具体返回的实现类。不过有一点要注意，@Bean修饰的方法所在的类必须是IOC容器中的Bean对象，即所在的类必须被@Configuration、@Component等注解修饰，@Bean通常配合@Configuration使用。

一、@Component, @Service, @Controller, @Repository注解

引用spring的官方文档中的一段描述：

在Spring2.0之前的版本中，@Repository注解可以标记在任何的类上，用来表明该类是用来执行与数据库相关的操作（即dao对象），并支持自动处理数据库操作产生的异常

在Spring2.5版本中，引入了更多的Spring类注解：@Component,@Service,@Controller。@Component是一个通用的Spring容器管理的单例bean组件。而@Repository, @Service, @Controller就是针对不同的使用场景所采取的特定功能化的注解组件。

因此，当你的一个类被@Component所注解，那么就意味着同样可以用@Repository, @Service, @Controller来替代它，同时这些注解会具备有更多的功能，而且功能各异。

最后，如果你不知道要在项目的业务层采用@Service还是@Component注解。那么，@Service是一个更好的选择。

就如上文所说的，@Repository早已被支持了在你的持久层作为一个标记可以去自动处理数据库操作产生的异常（译者注：因为原生的java操作数据库所产生的异常只定义了几种，但是产生数据库异常的原因却有很多种，这样对于数据库操作的报错排查造成了一定的影响；而Spring拓展了原生的持久层异常，针对不同的产生原因有了更多的异常进行描述。所以，在注解了@Repository的类上如果数据库操作中抛出了异常，就能对其进行处理，转而抛出的是翻译后的spring专属数据库异常，方便我们对异常进行排查处理）。

注解	含义
@Component	最普通的组件，可以被注入到spring容器进行管理
@Repository	作用于持久层
@Service	作用于业务逻辑层
@Controller	作用于表现层（spring-mvc的注解）

这几个注解几乎可以说是一样的：因为被这些注解修饰的类就会被Spring扫描到并注入到Spring的bean容器中。

这里，有两个注解是不能被其他注解所互换的：

@Controller 注解的bean会被spring-mvc框架所使用。 
@Repository 会被作为持久层操作（数据库）的bean来使用 
如果想使用自定义的组件注解，那么只要在你定义的新注解中加上@Component即可：

@Component 
@Scope("prototype")
public @interface ScheduleJob {...}

这样，所有被@ScheduleJob注解的类就都可以注入到spring容器来进行管理。我们所需要做的，就是写一些新的代码来处理这个自定义注解（译者注：可以用反射的方法），进而执行我们想要执行的工作。

@Component就是跟<bean>一样，可以托管到Spring容器进行管理。

@Service, @Controller , @Repository = {@Component + 一些特定的功能}。这个就意味着这些注解在部分功能上是一样的。

当然，下面三个注解被用于为我们的应用进行分层：

@Controller注解类进行前端请求的处理，转发，重定向。包括调用Service层的方法 
@Service注解类处理业务逻辑 
@Repository注解类作为DAO对象（数据访问对象，Data Access Objects），这些类可以直接对数据库进行操作 
有这些分层操作的话，代码之间就实现了松耦合，代码之间的调用也清晰明朗，便于项目的管理；假想一下，如果只用@Controller注解，那么所有的请求转发，业务处理，数据库操作代码都糅合在一个地方，那这样的代码该有多难拓展和维护。

这段总结：

@Component, @Service, @Controller, @Repository是spring注解，注解后可以被spring框架所扫描并注入到spring容器来进行管理 
@Component是通用注解，其他三个注解是这个注解的拓展，并且具有了特定的功能 
@Repository注解在持久层中，具有将数据库操作抛出的原生异常翻译转化为spring的持久层异常的功能。 
@Controller层是spring-mvc的注解，具有将请求进行转发，重定向的功能。 
@Service层是业务逻辑层注解，这个注解只是标注该类处于业务逻辑层。 
用这些注解对应用进行分层之后，就能将请求处理，义务逻辑处理，数据库操作处理分离出来，为代码解耦，也方便了以后项目的维护和开发。

二、@Component与@Bean的区别

首先我们看看这两个注解的作用：

• @Component注解表明一个类会作为组件类，并告知Spring要为这个类创建bean。

• @Bean注解告诉Spring这个方法将会返回一个对象，这个对象要注册为Spring应用上下文中的bean。通常方法体中包含了最终产生bean实例的逻辑。

两者的目的是一样的，都是注册bean到Spring容器中。

@Component（@Controller、@Service、@Repository）通常是通过类路径扫描来自动侦测以及自动装配到Spring容器中。

而@Bean注解通常是我们在标有该注解的方法中定义产生这个bean的逻辑。

举个栗子：

@Controller

//在这里用Component，Controller，Service，Repository都可以起到相同的作用。

@RequestMapping(″/web/controller1″)
public class WebController {
    .....
}

而@Bean的用途则更加灵活

当我们引用第三方库中的类需要装配到Spring容器时，则只能通过@Bean来实现

举个例子：

public class WireThirdLibClass {
    @Bean
    public ThirdLibClass getThirdLibClass() {
        return new ThirdLibClass();
    }
}

再举个只能用@Bean的例子：

@Bean
public OneService getService(status) {
    case (status)  {
        when 1:
                return new serviceImpl1();
        when 2:
                return new serviceImpl2();
        when 3:
                return new serviceImpl3();
    }
}

以上这个例子是无法用Component以及其具体实现注解（Controller、Service、Repository）来实现的。

这段总结：@Component和@Bean都是用来注册Bean并装配到Spring容器中，但是Bean比Component的自定义性更强。可以实现一些Component实现不了的自定义加载类。

三、@Configuration 和 @Component 区别

 一句话概括就是 @Configuration 中所有带 @Bean 注解的方法都会被动态代理，因此调用该方法返回的都是同一个实例。（不清楚往下面看）

@Configuration 注解：

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Component
public @interface Configuration {
    String value() default "";
}

 从定义来看，@Configuration注解本质上还是 @Component，因此 <context:component-scan/> 或者 @ComponentScan 都能处理@Configuration 注解的类。

@Configuration 标记的类必须符合下面的要求：

• 配置类必须以类的形式提供（不能是工厂方法返回的实例），允许通过生成子类在运行时增强（cglib 动态代理）。
• 配置类不能是 final 类（没法动态代理）。
• 配置注解通常为了通过 @Bean 注解生成 Spring 容器管理的类，
• 配置类必须是非本地的（即不能在方法中声明，不能是 private）。
• 任何嵌套配置类都必须声明为static。
• @Bean 方法可能不会反过来创建进一步的配置类（也就是返回的 bean 如果带有 @Configuration，也不会被特殊处理，只会作为普通的 bean）。

加载过程：

Spring 容器在启动时，会加载默认的一些 PostPRocessor，其中就有 ConfigurationClassPostProcessor，这个后置处理程序专门处理带有 @Configuration 注解的类，这个程序会在 bean 定义加载完成后，在 bean 初始化前进行处理。主要处理的过程就是使用 cglib 动态代理增强类，而且是对其中带有 @Bean 注解的方法进行处理。 

在 ConfigurationClassPostProcessor 中的 postProcessBeanFactory 方法中调用了下面的方法：

/**
 * Post-processes a BeanFactory in search of Configuration class BeanDefinitions;
 * any candidates are then enhanced by a {@link ConfigurationClassEnhancer}.
 * Candidate status is determined by BeanDefinition attribute metadata.
 * @see ConfigurationClassEnhancer
 */
public void enhanceConfigurationClasses(ConfigurableListableBeanFactory beanFactory) {
    Map<String, AbstractBeanDefinition> configBeanDefs = new LinkedHashMap<String, AbstractBeanDefinition>();
    for (String beanName : beanFactory.getBeanDefinitionNames()) {
        BeanDefinition beanDef = beanFactory.getBeanDefinition(beanName);
        if (ConfigurationClassUtils.isFullConfigurationClass(beanDef)) {
            //省略部分代码
            configBeanDefs.put(beanName, (AbstractBeanDefinition) beanDef);
        }
    }
    if (configBeanDefs.isEmpty()) {
        // nothing to enhance -> return immediately
        return;
    }
    ConfigurationClassEnhancer enhancer = new ConfigurationClassEnhancer();
    for (Map.Entry<String, AbstractBeanDefinition> entry : configBeanDefs.entrySet()) {
        AbstractBeanDefinition beanDef = entry.getValue();
        // If a @Configuration class gets proxied, always proxy the target class
        beanDef.setAttribute(AutoProxyUtils.PRESERVE_TARGET_CLASS_ATTRIBUTE, Boolean.TRUE);
        try {
            // Set enhanced subclass of the user-specified bean class
            Class<?> configClass = beanDef.resolveBeanClass(this.beanClassLoader);
            Class<?> enhancedClass = enhancer.enhance(configClass, this.beanClassLoader);
            if (configClass != enhancedClass) {
                //省略部分代码
                beanDef.setBeanClass(enhancedClass);
            }
        }
        catch (Throwable ex) {
            throw new IllegalStateException(
              "Cannot load configuration class: " + beanDef.getBeanClassName(), ex);
        }
    }
}

 在方法的第一次循环中，查找到所有带有 @Configuration 注解的 bean 定义，然后在第二个 for 循环中，通过下面的方法对类进行增强：

Class<?> enhancedClass = enhancer.enhance(configClass, this.beanClassLoader);

 然后使用增强后的类替换了原有的 beanClass：

beanDef.setBeanClass(enhancedClass);

所以到此时，所有带有 @Configuration 注解的 bean 都已经变成了增强的类。

下面关注上面的 enhance 增强方法，多跟一步就能看到下面的方法：

/**
 * Creates a new CGLIB {@link Enhancer} instance.
 */
private Enhancer newEnhancer(Class<?> superclass, ClassLoader classLoader) {
    Enhancer enhancer = new Enhancer();
    enhancer.setSuperclass(superclass);
    enhancer.setInterfaces(new Class<?>[] {EnhancedConfiguration.class});
    enhancer.setUseFactory(false);
    enhancer.setNamingPolicy(SpringNamingPolicy.INSTANCE);
    enhancer.setStrategy(new BeanFactoryAwareGeneratorStrategy(classLoader));
    enhancer.setCallbackFilter(CALLBACK_FILTER);
    enhancer.setCallbackTypes(CALLBACK_FILTER.getCallbackTypes());
    return enhancer;
}

通过 cglib 代理的类在调用方法时，会通过 CallbackFilter 调用，这里的 CALLBACK_FILTER 如下：

// The callbacks to use. Note that these callbacks must be stateless.
private static final Callback[] CALLBACKS = new Callback[] {
        new BeanMethodInterceptor(),
        new BeanFactoryAwareMethodInterceptor(),
        NoOp.INSTANCE
};
 
private static final ConditionalCallbackFilter CALLBACK_FILTER = 
        new ConditionalCallbackFilter(CALLBACKS);

 其中 BeanMethodInterceptor 匹配方法如下：

@Override
public boolean isMatch(Method candidateMethod) {
    return BeanAnnotationHelper.isBeanAnnotated(candidateMethod);
}
 
//BeanAnnotationHelper
public static boolean isBeanAnnotated(Method method) {
    return AnnotatedElementUtils.hasAnnotation(method, Bean.class);
}

也就是当方法有 @Bean 注解的时候，就会执行这个回调方法。

另一个 BeanFactoryAwareMethodInterceptor 匹配的方法如下：

@Override
public boolean isMatch(Method candidateMethod) {
    return (candidateMethod.getName().equals("setBeanFactory") &&
            candidateMethod.getParameterTypes().length == 1 &&
            BeanFactory.class == candidateMethod.getParameterTypes()[0] &&
            BeanFactoryAware.class.isAssignableFrom(candidateMethod.getDeclaringClass()));
}

 当前类还需要实现 BeanFactoryAware 接口，上面的 isMatch 就是匹配的这个接口的方法。

@Bean 注解方法执行策略：

先给一个简单的示例代码：

@Configuration
public class MyBeanConfig {
 
    @Bean
    public Country country(){
        return new Country();
    }
 
    @Bean
    public UserInfo userInfo(){
        return new UserInfo(country());
    }
 
}

相信大多数人第一次看到上面 userInfo() 中调用 country() 时，会认为这里的 Country 和上面 @Bean 方法返回的 Country可能不是同一个对象，因此可能会通过下面的方式来替代这种方式：

@Autowired 
private Country country;

实际上不需要这么做（后面会给出需要这样做的场景），直接调用 country() 方法返回的是同一个实例。

下面看调用 country() 和 userInfo() 方法时的逻辑。

现在我们已经知道 @Configuration 注解的类是如何被处理的了，现在关注上面的 BeanMethodInterceptor，看看带有 @Bean 注解的方法执行的逻辑。下面分解来看 intercept 方法。

//首先通过反射从增强的 Configuration 注解类中获取 beanFactory
ConfigurableBeanFactory beanFactory = getBeanFactory(enhancedConfigInstance);
 
//然后通过方法获取 beanName，默认为方法名，可以通过 @Bean 注解指定
String beanName = BeanAnnotationHelper.determineBeanNameFor(beanMethod);
 
//确定这个 bean 是否指定了代理的范围
//默认下面 if 条件 false 不会执行
Scope scope = AnnotatedElementUtils.findMergedAnnotation(beanMethod, Scope.class);
if (scope != null && scope.proxyMode() != ScopedProxyMode.NO) {
    String scopedBeanName = ScopedProxyCreator.getTargetBeanName(beanName);
    if (beanFactory.isCurrentlyInCreation(scopedBeanName)) {
        beanName = scopedBeanName;
    }
}
 
//中间跳过一段 Factorybean 相关代码
 
//判断当前执行的方法是否为正在执行的 @Bean 方法
//因为存在在 userInfo() 方法中调用 country() 方法
//如果 country() 也有 @Bean 注解，那么这个返回值就是 false.
if (isCurrentlyInvokedFactoryMethod(beanMethod)) {
    // 判断返回值类型，如果是 BeanFactoryPostProcessor 就写警告日志
    if (logger.isWarnEnabled() &&
            BeanFactoryPostProcessor.class.isAssignableFrom(beanMethod.getReturnType())) {
        logger.warn(String.format(
            "@Bean method %s.%s is non-static and returns an object " +
            "assignable to Spring's BeanFactoryPostProcessor interface. This will " +
            "result in a failure to process annotations such as @Autowired, " +
            "@Resource and @PostConstruct within the method's declaring " +
            "@Configuration class. Add the 'static' modifier to this method to avoid " +
            "these container lifecycle issues; see @Bean javadoc for complete details.",
            beanMethod.getDeclaringClass().getSimpleName(), beanMethod.getName()));
    }
    //直接调用原方法创建 bean
    return cglibMethodProxy.invokeSuper(enhancedConfigInstance, beanMethodArgs);
}
//如果不满足上面 if，也就是在 userInfo() 中调用的 country() 方法
return obtainBeanInstanceFromFactory(beanMethod, beanMethodArgs, beanFactory, beanName);

关于 isCurrentlyInvokedFactoryMethod 方法
可以参考 SimpleInstantiationStrategy 中的 instantiate 方法，这里先设置的调用方法：

currentlyInvokedFactoryMethod.set(factoryMethod);
return factoryMethod.invoke(factoryBean, args);

而通过方法内部直接调用 country() 方法时，不走上面的逻辑，直接进的代理方法，也就是当前的 intercept方法，因此当前的工厂方法和执行的方法就不相同了。

obtainBeanInstanceFromFactory 方法比较简单，就是通过 beanFactory.getBean 获取 Country，如果已经创建了就会直接返回，如果没有执行过，就会通过 invokeSuper 首次执行。

因此我们在 @Configuration 注解定义的 bean 方法中可以直接调用方法，不需要 @Autowired 注入后使用。

@Component 注意：

@Component 注解并没有通过 cglib 来代理@Bean 方法的调用，因此像下面这样配置时，就是两个不同的 country。

@Component
public class MyBeanConfig {
 
    @Bean
    public Country country(){
        return new Country();
    }
 
    @Bean
    public UserInfo userInfo(){
        return new UserInfo(country());
    }
 
}

有些特殊情况下，我们不希望 MyBeanConfig 被代理（代理后会变成WebMvcConfig$$EnhancerBySpringCGLIB$$8bef3235293）时，就得用 @Component，这种情况下，上面的写法就需要改成下面这样：

@Component
public class MyBeanConfig {
 
    @Autowired
    private Country country;
 
    @Bean
    public Country country(){
        return new Country();
    }
 
    @Bean
    public UserInfo userInfo(){
        return new UserInfo(country);
    }
 
}

这种方式可以保证使用的同一个 Country 实例。

转载：https://blog.csdn.net/fansili/article/details/78740877

https://www.jianshu.com/p/3fbfbb843b63

https://blog.csdn.net/aa1358075776/article/details/81022306