Spring如何处理注解的深入理解

前言

传统的spring做法是使用.xml文件来对bean进行注入或者是配置aop、事物，这么做有两个缺点：

1、如果所有的内容都配置在.xml文件中，那么.xml文件将会十分庞大；如果按需求分开.xml文件，那么.xml文件又会非常多。总之这将导致配置文件的可读性与可维护性变得很低。

2、在开发中在.java文件和.xml文件之间不断切换，是一件麻烦的事，同时这种思维上的不连贯也会降低开发的效率。
为了解决这两个问题，spring引入了注解，通过"@xxx"的方式，让注解与java bean紧密结合，既大大减少了配置文件的体积，又增加了java bean的可读性与内聚性。

如果你看到了注解,那么一定有什么代码在什么地方处理了它.

alan hohn

我教java课程时强调的一点是注解是惰性的。换句话说，它们只是标记，可能具有某些属性，但没有自己的行为。因此，每当你在一段java代码上看到一个注解时，就意味着必须有一些其他的java代码来寻找那个注解并包含真正的智能来做一些有用的东西。

不幸的是，这种推理的问题在于，确切地确定哪一段代码正在处理注解是非常困难的，特别是如果它在库中。处理注解的代码可能会令人困惑，因为它使用反射并且必须以非常抽象的方式编写。所以我认为值得看看一个做得很好的例子来看看它是如何运行的。

我们详细研究一下 spring 框架中的 initdestroyannotationbeanpostprocessor 类是如何工作的。选择这个，因为它相对简单，只做了一些相对容易解释的事情, 碰巧和我手头的工作相关。

spring bean 的后处理

首先，我想首先解释一下 spring 的用途。spring 框架所做的一件事就是“依赖注入”。这改变了我们以往用代码将模块串在一起的方式。例如，假设我们编写了一些需要连接数据库的应用程序逻辑, 但并想将提供该连接的特定硬类编码到应用程序逻辑中，我们可以在构造函数或setter方法中将其表示为依赖项：

class myapplication {
 private dataconnection data;
 ...
 public void setdata(dataconnection data) {
  this.data = data;
 }
 ...
}

当然，如果想的话, 我们可以自己编写一个简单的库完成这种依赖注入，从而避免添加对 spring 的依赖项。但是如果我们在编写一个复杂的应用程序, 想将各模块连接在一起，那么spring可以非常方便。

既然没有什么神秘的，如果我们要让 spring 为我们注入这些依赖，那么就会有一个权衡。spring 需要“知道”依赖关系以及应用程序中的类和对象。spring 处理这个问题的方法多是由 spring 框架对对象进行实例化; 从而可以在称为"应用程序上下文"的大数据结构中跟踪管理这此对象。

后处理和初始化

而且这里是 initdestroybeanpostprocessor 进入的地方 。如果 spring 要处理实例化，那么在对象实例化完成之后，但是在应用程序开始真正的运行之前，需要进行一些“额外工作”。需要做的一件“额外工作”就是调用对象来告诉他们什么时候完全设置好，这样他们就可以进行任何需要的额外初始化。如果我们使用“setter”注入，如上所述，便通过调用setxxx() 方法注入依赖项，这一点尤其重要，因为在调用对象的构造函数时这些依赖项并不可用。所以 spring 需要允许用户指定在初始化对象后才应该调用的某个方法的名称。

spring 一直支持使用xml配置文件来定义由 spring 来实例化的对象，在这种情况下，有一个 'init-method' 属性可以用来指定初始化的方法。显然，在这种情况下，它仍然需要反射来实际查找并调用该方法。自java 5起, 增加了注解，所以spring 也支持带注解的标记方法，将它们标识为spring应该实例化的对象，识别需要注入的依赖项，以及识别应该调用的初始化和销毁​​方法。

最后一项 initdestroybeanpostprocessor 由其子类或其中一个子类处理。后处理器是一种特殊的对象，由spring实例化，实现后处理器接口。因为它实现了这个接口，所以spring会在每个spring实例化的对象上调用一个方法，允许它修改甚至替换该对象。这是spring采用模块化架构方法的一部分，可以更轻松地扩展功能。

这是怎么运作的?

事实上， jsr-250 确定了一些“常见”注解，包括 @postconstruct, 用于标记初始化方法,@predestroy 注解, 用于注解销毁方法的。不同的是，initdestroybeanpostprocessor 被设计成可以处理任何注解集，因此它提供了识别注解的方法：

 public void setinitannotationtype(class<? extends annotation> initannotationtype) {
  this.initannotationtype = initannotationtype;
 }
...
 public void setdestroyannotationtype(class<? extends annotation> destroyannotationtype) {
  this.destroyannotationtype = destroyannotationtype;
 }

请注意，这些是普通的 setter 方法，因此这个对象本身可以使用 spring 进行设置。就我而言，我使用spring 的 staticapplicationcontext，见我。

一旦 spring 实例化了各种对象并注入了所有依赖项，它就会在所有后处理器上为每个对象调用 postprocessbeforeinitialization 方法 。这使后处理器有机会在初始化之前修改或替换对象。因为已经注入了依赖项，所以这是 initdestroyannotationbeanpostprocessor 调用初始化方法的地方。

 lifecyclemetadata metadata = findlifecyclemetadata(bean.getclass());
 try {
  metadata.invokeinitmethods(bean, beanname);
 }

由于我们对代码如何处理注解感兴趣，我们感兴趣 findlifecyclemetadata() 方法，因为这是对类进行检查的地方。该方法检查缓存，该缓存用于避免执行超过必要的反射，因为它可能很昂贵。如果尚未检查该类，则调用 buildlifecyclemetadata() 方法。该方法的内容如下：

reflectionutils.dowithlocalmethods(targetclass, new reflectionutils.methodcallback() {
 @override
 public void dowith(method method) throws illegalargumentexception, illegalaccessexception {
  if (initannotationtype != null) {
   if (method.getannotation(initannotationtype) != null) {
    lifecycleelement element = new lifecycleelement(method);
    currinitmethods.add(element);
   }
  }
  ...
 }
});

这里 reflectionutils 是一个方便的类，简化了反射的使用。除此之外，它还将经过反射的众多已检查异常转换为未经检查的异常(?)，从而使事情变得更容易。此特定方法仅迭代本地方法（即不是继承的方法），并为每个方法调用回调。

完成所有设置之后，检查注解的部分非常无聊; 它只是调用java反射方法来检查注解，如果找到它，则将该方法存储为初始化方法。

总结

事实上，这里最终发生的事情很简单，这就是我在教反射时所要做的事情。调试使用注解来控制行为的代码可能具有挑战性，因为从外部来看它非常不透明，所以很难想象发生了什么（或者没有发生）和什么时候发生。但最终，正在发生的事情只是java代码; 它可能不会立即显现出代码的位置，但它就在那里。

好了，以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对的支持。