Spring 中 @Autowired 和 @Resource 在五个方面的区别。
@Autowired注解是由Spring提供的,它可以用来对构造方法、成员变量及方法参数进行标注,它能够根据对象类型完成自动注入,代码如下:
public class Service {
// 构造方法注入
@Autowired
public Service(Service service) {
this.service = service;
}
// 成员变量注入
@Autowired
private Service service;
// 方法参数注入
@Autowired
public void setService(Service service) {
this.service = service;
}
}
再来看@Resource注解,代码如下:
public class Service {
@Resource(name = "service1")
private Service service1;
@Resource(name = "service2")
private Service service2;
@Reource
private Service service3;
@Reource
private Service service4;
}
它是由JDK提供的,遵循JSR-250规范,是JDK 1.6及以上加入的新特性。作为Java的标准,它的作用和@Autowired无区别。与@Autowired不同的是,它适用于所有的Java框架,而@Autowired只适用于Spring。读者可以简单地理解为,@Resource能够支持对象类型注入,也能够支持对象名称注入。
@Resource和@Autowired之间具体有哪些区别呢?
可以从以下5个方面来分析。
1.注解内部定义的参数不同
@Autowired只包含一个required参数,默认为true,表示开启自动注入。
public @interface Autowired {
// 是否开启自动注入,在不开启自动装配时,可设为false
boolean required() default true;
}
@Resource 包含7个参数,其中最重要的两个是name和type。
public @interface Resource {
// Bean的名称
String name() default "";
String lookup() default "";
// Java类,被解析为Bean的类型
Class<?> type() default java.lang.Object.class;
enum AuthenticationType {
CONTAINER,
APPLICATION
}
// 身份验证类型
AuthenticationType authenticationType() default AuthenticationType.CONTAINER;
// 组件是否可以与其他组件共享
boolean shareable() default true;
String mappedName() default "";
// 描述
String description() default "";
}
2.装配方式的默认值不同
@Autowired默认按type自动装配,而@Resource默认按name自动装配。@Resource注解可以自定义选择装配方式,如果指定name,则按name自动装配。如果指定type,则按type自动装配。
3.注解应用的范围不同
@Autowired能够用在构造方法、成员变量、方法参数及注解上,而@Resource能用在类、成员变量和方法参数上,源码如下。
@Target({ElementType.CONSTRUCTOR, ElementType.METHOD, ElementType.PARAMETER, ElementType.FIELD, ElementType.ANNOTATION_TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Autowired { ... }
@Target({TYPE, FIELD, METHOD})
@Retention(RUNTIME)
public @interface Resource { ... }
4.出处不同
@Autowired是Spring定义的注解,而@Resource遵循JSR-250的规范,定义在JDK中。所以@Autowired只能在Spring框架下使用,而@Resource则可以与其他框架一起使用。
5.装配顺序不同
@Autowired默认先与byType进行匹配,如果发现找到多个Bean,则又按照byName方式进行匹配,如果还有多个Bean,则报出异常。装配顺序如下图所示。
而@Resource的装载顺序分为如下4种情况。
1)如果同时指定name和type,则从Spring上下文中找到与它们唯一匹配的Bean进行装配,如果找不到则抛出异常,具体流程如下图所示。
2)如果指定name,则从上下文中查找与名称(ID)匹配的Bean进行装配,如果找不到则抛出异常,具体流程如下图所示。
3)如果指定type,则从上下文中找到与类型匹配的唯一Bean进行装配,如果找不到或者找到多个就会抛出异常,具体流程如下图所示。
4)如果既没有指定name,也没有指定type,则自动按byName方式进行装配。如果没有匹配成功,则仍按照type进行匹配,具体流程如下图所示。
下面这张表可以帮助大家更好地理解和区分@Autowired和@Resource。
总结一下,两者在功能上差别不大,使用起来也差不多。但是,在日常开发中建议使用@Autowired,有以下3个理由。
- @Autowired功能略强大。支持优先注入、可以配置允许Bean不存在。
- 若使用Spring框架,则使用其特有的注解更好一点。
- 有人认为@Resource更加通用,因为它是一个规范,其他框架也会支持。目前后端都在用Spring,没有必要考虑其他框架。
面试点评:我们可以直接告诉面试官这两个注解的差异,同时基于两个注解的特性解释更多的差异,这样可以更好地体现自己对这方面知识的理解深度。面试官想考查求职者对Spring依赖注入方式的理解,以及对@Autowired和@Resource两个注解底层实现方面的区别的理解。求职者在理解了底层实现的差异后,回答这个问题会比较容易。
推荐阅读
-
Spring 注解中 @Resource 和 @Autowired 使用方法的区别
-
Spring 中 @Autowired 和 @Resource 的区别
-
Spring 中 @Autowired 和 @Resource 在五个方面的区别。
-
Spring Framework 中的 @Autowired 和 @Resource 有什么区别?
-
@Validated和@Valid区别-1.分组 @Validated:提供了一个分组功能,可以在入参验证时,根据不同的分组采用不同的验证机制。没有添加分组属性时,默认验证没有分组的验证属性。 伪代码如下: public interface First{ } public interface Second{ } public class UserModel { @NotNull(message = "{id.empty}", groups = { First.class }) private int id; @NotNull(message = "{username.empty}", groups = { First.class, Second.class }) private String username; @NotNull(message = "{content.empty}", groups = { First.class, Second.class }) private String content; } public String save(@Validated( { Second.class }) UserModel userModel, BindingResult result) { if (result.hasErrors) { return "validate/error"; } return "redirect:/success"; } 对一个参数需要多种验证方式时,也可通过分配不同的组达到目的。例: @NotEmpty(groups = { First.class }) @Size(min = 3, max = 8, groups = { Second.class }) private String name; 分组还支持组序列 默认情况下,不同组别的约束验证是无序的,然而在某些情况下,约束验证的顺序却很重要,如下面两个例子:(1)第二个组中的约束验证依赖于一个稳定状态来运行,而这个稳定状态是由第一个组来进行验证的。(2)某个组的验证比较耗时,CPU 和内存的使用率相对比较大,最优的选择是将其放在最后进行验证。因此,在进行组验证的时候尚需提供一种有序的验证方式,这就提出了组序列的概念。 一个组可以定义为其他组的序列,使用它进行验证的时候必须符合该序列规定的顺序。在使用组序列验证的时候,如果序列前边的组验证失败,则后面的组将不再给予验证。 public interface GroupA { } public interface GroupB { } @GroupSequence( { GroupA.class, GroupB.class }) public interface Group { } public @ResponseBody String addPeople(@Validated({Group.class}) People p,BindingResult result) { if(result.hasErrors) { return "0"; } return "1"; } @Valid:作为标准JSR-303规范,还没有吸收分组的功能。 2.注解地方 @Validated:可以用在类型、方法和方法参数上。但是不能用在成员属性(字段)上 @Valid:可以用在方法、构造函数、方法参数和成员属性(字段)上 两者是否能用于成员属性(字段)上直接影响能否提供嵌套验证的功能。 3.嵌套验证 在比较两者嵌套验证时,先说明下什么叫做嵌套验证。 比如我们现在有个实体叫做Item: public class Item { @NotNull(message = "id不能为空") @Min(value = 1, message = "id必须为正整数") private Long id; @NotNull(message = "props不能为空") @Size(min = 1, message = "至少要有一个属性") private List<Prop> props; } Item带有很多属性,属性里面有:pid、vid、pidName和vidName,如下所示: public class Prop { @NotNull(message = "pid不能为空") @Min(value = 1, message = "pid必须为正整数") private Long pid; @NotNull(message = "vid不能为空") @Min(value = 1, message = "vid必须为正整数") private Long vid; @NotBlank(message = "pidName不能为空") private String pidName; @NotBlank(message = "vidName不能为空") private String vidName; } 属性这个实体也有自己的验证机制,比如pid和vid不能为空,pidName和vidName不能为空等。 现在我们有个ItemController接受一个Item的入参,想要对Item进行验证,如下所示: @RestController public class ItemController { @RequestMapping("/item/add") public void addItem(@Validated Item item, BindingResult bindingResult) { doSomething; } } 在上图中,如果Item实体的props属性不额外加注释,只有@NotNull和@Size,无论入参采用@Validated还是@Valid验证,Spring Validation框架只会对Item的id和props做非空和数量验证,不会对props字段里的Prop实体进行字段验证,也就是@Validated和@Valid加在方法参数前,都不会自动对参数进行嵌套验证。也就是说如果传的List中有Prop的pid为空或者是负数,入参验证不会检测出来。 为了能够进行嵌套验证,必须手动在Item实体的props字段上明确指出这个字段里面的实体也要进行验证。由于@Validated不能用在成员属性(字段)上,但是@Valid能加在成员属性(字段)上,而且@Valid类注解上也说明了它支持嵌套验证功能,那么我们能够推断出:@Valid加在方法参数时并不能够自动进行嵌套验证,而是用在需要嵌套验证类的相应字段上,来配合方法参数上@Validated或@Valid来进行嵌套验证。 我们修改Item类如下所示: public class Item { @NotNull(message = "id不能为空") @Min(value = 1, message = "id必须为正整数") private Long id; @Valid // 嵌套验证必须用@Valid @NotNull(message = "props不能为空") @Size(min = 1, message = "props至少要有一个自定义属性") private List<Prop> props; } 然后我们在ItemController的addItem函数上再使用@Validated或者@Valid,就能对Item的入参进行嵌套验证。此时Item里面的props如果含有Prop的相应字段为空的情况,Spring Validation框架就会检测出来,bindingResult就会记录相应的错误。 总结一下@Validated和@Valid在嵌套验证功能上的区别: