spring注解的理解

spring注解：注解（Annotation）提供了一种安全的类似注释的机制，为我们在代码中添加信息提供了一种形式化得方法，使我们可以在稍后某个时刻方便的使用这些数据（通过解析注解来使用这些数据），用来将任何的信息或者元数据与程序元素（类、方法、成员变量等）进行关联。其实就是更加直观更加明了的说明，这些说明信息与程序业务逻辑没有关系，并且是供指定的工具或框架使用的。Annotation像一种修饰符一样，应用于包、类型、构造方法、方法、成员变量、参数及本地变量的申明语句中。
Annotation其实是一种接口。通过java的反射机制相关的API来访问Annotation信息。相关类（框架或工具中的类）根据这些信息来决定如何使用该程序元素或改变它们的行为。Java语言解释器在工作时会忽略这些Annotation，因此在JVM中这些Annotation是“不起作用”的，只能通过配套的工具才能对这些Annotation类型的信息进行访问和处理。

spring开启注解的功能：一般在spring.xmll文件中`

1、@Autowired
顾名思义就是，实现自动装配，消除代码Java代码里面的getter/setter与bean属性中的property。默认是按照类型（byType）匹配 — 按照名字(byName)匹配
，@Autowired注解要去寻找的是一个Bean，如果属性找不到我不想让Spring容器抛出异常，而就是显示null，可以吗？可以的，其实异常信息里面也给出了提示了，就是将@Autowired注解的required属性设置为false即可

2、Qualifier（指定注入Bean的名称）
如果容器中有一个以上匹配的Bean，则可以通过@Qualifier注解限定Bean的名称

3、Resource
@Resource注解与@Autowired注解作用非常相似
这是详细一些的用法，说一下@Resource的装配顺序：
(1)、@Resource后面没有任何内容，默认通过name属性去匹配bean，找不到再按type去匹配
(2)、指定了name或者type则根据指定的类型去匹配bean
(3)、指定了name和type则根据指定的name和type去匹配bean，任何一个不匹配都将报错
然后，区分一下@Autowired和@Resource两个注解的区别：
(1)、@Autowired默认按照byType方式进行bean匹配，@Resource默认按照byName方式进行bean匹配
(2)、@Autowired是Spring的注解，@Resource是J2EE的注解，这个看一下导入注解的时候这两个注解的包名就一清二楚了
Spring属于第三方的，J2EE是Java自己的东西，因此，建议使用@Resource注解，以减少代码和Spring之间的耦合。

=======================================
上面这个例子，还可以继续简化，下一步的简化是把这bean也给去掉，使得spring配置文件里面只有一个自动扫描的标签，增强Java代码的内聚性并进一步减少配置文件。
要继续简化，可以使用@Service。

这里我还多加了一个@Scope注解，应该很好理解。因为Spring默认产生的bean是单例的，假如我不想使用单例怎么办，xml文件里面可以在bean里面配置scope属性。注解也是一样，配置@Scope即可，默认是”singleton”即单例，”prototype”表示原型即每次都会new一个新的出来。

使用注解来构造IoC容器
用注解来向Spring容器注册Bean。需要在applicationContext.xml中注册。

表明cn.gacl.java包及其子包中，如果某个类的头上带有特定的注解【@Component/@Repository/@Service/@Controller】，就会将这个对象作为Bean注册进Spring容器。也可以在

/ 注入userService@Resource(name = "userService")private UserService userService;注意

注意：在Action声明的”userService”变量的类型必须是”UserServiceImpl”或者是其父类”UserService”，否则由于类型不一致而无法注入，由于Action中的声明的”userService”变量使用了@Resource注解去标注，并且指明了其name = “userService”，这就等于告诉Spring，说我Action要实例化一个”userService”，你Spring快点帮我实例化好，然后给我，当Spring看到userService变量上的@Resource的注解时，根据其指明的name属性可以知道，Action中需要用到一个UserServiceImpl的实例，此时Spring就会把自己创建好的名字叫做”userService”的UserServiceImpl的实例注入给Action中的”userService”变量，帮助Action完成userService的实例化，这样在Action中就不用通过”UserService userService = new UserServiceImpl();”这种最原始的方式去实例化userService了。如果没有Spring，那么当Action需要使用UserServiceImpl时，必须通过”UserService userService = new UserServiceImpl();”主动去创建实例对象，但使用了Spring之后，Action要使用UserServiceImpl时，就不用主动去创建UserServiceImpl的实例了，创建UserServiceImpl实例已经交给Spring来做了，Spring把创建好的UserServiceImpl实例给Action，Action拿到就可以直接用了。Action由原来的主动创建UserServiceImpl实例后就可以马上使用，变成了被动等待由Spring创建好UserServiceImpl实例之后再注入给Action，Action才能够使用。这说明Action对”UserServiceImpl”类的“控制权”已经被“反转”了，原来主动权在自己手上，自己要使用”UserServiceImpl”类的实例，自己主动去new一个出来马上就可以使用了，但现在自己不能主动去new “UserServiceImpl”类的实例，new “UserServiceImpl”类的实例的权力已经被Spring拿走了，只有Spring才能够new “UserServiceImpl”类的实例，而Action只能等Spring创建好”UserServiceImpl”类的实例后，再“恳求”Spring把创建好的”UserServiceImpl”类的实例给他，这样他才能够使用”UserServiceImpl”，这就是Spring核心思想“控制反转”，也叫“依赖注入”，“依赖注入”也很好理解，Action需要使用UserServiceImpl干活，那么就是对UserServiceImpl产生了依赖，Spring把Acion需要依赖的UserServiceImpl