Differences Between @Autowired and @Resource in Spring Dependency Injection

Hello everyone, I'm Chen. When using IDEA for development you might notice a warning on fields annotated with Spring's @Autowired that says “Field injection is not recommended”, while using @Resource does not show this warning.

Field injection is not recommended (字段注入是不被推荐的)

Most online articles only compare the two annotations without explaining why; this post summarizes the reasons.

Common Spring DI Methods

Constructor injection : inject dependencies via constructor parameters.

Setter injection : inject dependencies by calling setter methods.

Field injection : inject dependencies directly on fields using @Autowired or @Resource .

@Autowired vs @Resource

Both annotations achieve dependency injection, but @Autowired is defined by Spring, whereas @Resource follows the JSR‑250 specification. Their basic functionality is similar, yet there are several detailed differences:

Dependency resolution : @Autowired defaults to byType and can be qualified with @Qualifier to specify a name; @Resource defaults to byName and falls back to byType if no matching name is found.

Applicable targets : @Autowired can be used on constructors, methods, parameters, and fields; @Resource can only be used on methods and fields.

Provider : @Autowired is provided by Spring; @Resource is provided by the JSR‑250 standard.

Advantages and Disadvantages of Different DI Styles

According to the Spring documentation, the recommended usage scenarios are:

Constructor injection : strong dependency, immutable – the component cannot function without the injected beans.

Setter injection : optional dependency, mutable – the component can work without the bean and the dependency may change frequently.

Field injection : generally should be avoided; if used, @Resource couples the component to the IoC container less tightly than @Autowired .

Drawbacks of Field Injection

Cannot inject immutable objects as constructor injection does.

Dependencies are hidden from external view; only constructors and setters are visible.

Creates tight coupling with the IoC container, making the component hard to use outside the container.

Unit tests also need the IoC container, increasing test complexity.

When many dependencies are present, the component may violate the Single Responsibility Principle.

Why IDEA Only Warns About @Autowired

Field injection is convenient because it reduces boilerplate code compared to constructor or setter injection. However, this convenience comes at the cost of stronger coupling to the Spring framework. @Autowired is a Spring‑specific annotation, so IDEA flags it as a potential design issue, while @Resource is a standard JSR‑250 annotation that any compliant IoC container should support, thus no warning is shown.

Personal opinion: Since @Autowired is Spring‑provided, it creates a strong binding to the framework; switching to another IoC container would break the injection. @Resource , being a Java standard, allows the container to remain interchangeable.

Recommended Reading (Please Follow)

How Netty Achieves Millions of Concurrent Connections on a Single Machine?

How to Optimize Performance When API Traffic Surges?

Spring Cloud Gateway + OAuth2.0: Distributed Unified Authentication and Authorization

Why Is Nacos So Powerful? An Implementation Perspective

Alibaba's Rate‑Limiting Tool Sentinel: 17 Questions

If you liked this article, please like and share to support me, thanks!