为什么要停止在 SpringBoot 中使用字段注，改用构造器注入

xxx_520s2023-11-04 11:11

停止在 SpringBoot 中使用字段注入！

本文为翻译文，来源：https://medium.com

在 Spring Boot 依赖项注入的上下文中，存在关于注入依赖项最佳实践的争论:字段注入、Setter注入和构造函数注入。

❝在本文中，我们将重点讨论字段注入的缺陷，并提出一个远离它的案例。❞

1 什么是字段注入？

字段注入涉及直接用 @Autowired 注释类的私有字段。这是一个例子：

@Component

public class OrderService {

@Autowired
private OrderRepository orderRepository;

public Order findOrderById(Long id) {
    return orderRepository.findById(id);
}

}

2 为什么应该停止使用字段注入

2.1 可测试性

字段注入使组件的单元测试变得复杂。 由于依赖项直接注入到字段中，因此我们无法在 Spring 上下文之外轻松提供模拟或替代实现。

让我们以 sameOrderService 类为例。

如果我们希望对 OrderService 进行单元测试，那么在模拟 OrderRepository 时会遇到困难，因为它是一个私有字段。下面是对 OrderService 进行单元测试的方法:

java 复制代码 
@RunWith(SpringJUnit4ClassRunner.class)
public class OrderServiceTest {

    private OrderService orderService;

    @Mock
    private OrderRepository orderRepository;

    @Before
    public void setUp() throws Exception {
        orderService = new OrderService();

        // This will set the mock orderRepository into orderService's private field
        ReflectionTestUtils.setField(orderService, "orderRepository", orderRepository);
    }

    ...
}

尽管可以实现，但使用反射来替换私有字段并不是一个很好的设计。它违背了面向对象的设计原则，使测试难以阅读和维护。

但是，如果我们使用构造函数注入：

java 复制代码 
@Component
public class OrderService {
    private final OrderRepository orderRepository;

    public OrderService(OrderRepository orderRepository) {
        this.orderRepository = orderRepository;
    }
}

我们可以在测试期间轻松提供模拟 OrderRepository：

java 复制代码 
OrderRepository mockRepo = mock(OrderRepository.class);
OrderService orderService = new OrderService(mockRepo);

2.2 不变性

字段注入使我们的 Bean 在构建后可变。而通过构造函数注入，一旦构造了一个对象，它的依赖关系就会保持不变。

举例来说：

字段注入类：

java 复制代码 
@Component
public class UserService {
    @Autowired
    private UserRepository userRepository;
}

这里，userRepository 在创建对象后可以重新分配引用，这就打破了不变性原则。

如果我们使用构造函数注入：

java 复制代码 
@Component
public class UserService {
    private final UserRepository userRepository;

    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }
}

该 userRepository 字段可以声明为最终字段，在构造完成后，就会一直保持不变。

2.2.1 这里的 @Autowired private UserRepository userRepository; 在不能在private后加一个final吗？

在Spring框架中，使用字段注入时，你通常不会在被@Autowired注解的字段后加上final关键字。原因在于当Spring创建Bean的实例时，它需要能够设置这些没有通过构造函数提供的依赖关系。如果字段被声明为final，那么它必须在构造对象的时候初始化，之后就不能再改变了。

字段注入通常是通过反射来完成的，反射可以允许即使字段被声明为private，仍然能够被外部类修改。但是，如果你使用final来修饰字段，反射也不能用于改变其值，因为final字段在构造对象后就不可变了。这就是为什么你会在构造函数注入中看到final字段，而在字段注入中不会看到。

构造函数注入提供了不变性，因为你可以将所有依赖项声明为final。这意味着一旦构造了对象，这些依赖项就不能更改，从而可以避免很多因为状态改变导致的问题。这也符合不变性原则，是当前推荐的注入方式，因为它提高了代码的安全性和健壮性。

总结一下，@Autowired注解的字段不能声明为final，因为Spring需要在对象构造后设置这些字段。如果你想要不变性，你应该使用构造函数注入，并将依赖项声明为final。

2.2.2 如果我使用构造函数注入一个bean，要怎么样使用他呢？

当你使用构造函数注入来注入一个Bean时，Spring容器会负责创建这个Bean的实例，并且会自动把构造函数需要的依赖项注入进去。这里是一个使用构造函数注入的基本步骤：

  1. 定义依赖项接口。
  2. 创建依赖项的实现类，并使用例如@Component注解将其标记为Spring管理的Bean。
  3. 在使用依赖项的类中，创建一个构造函数，该构造函数接受依赖项作为参数，并使用例如@Autowired注解（在Spring 4.3之后，如果类只有一个构造函数，可以省略@Autowired注解）。

以下是一个简单的示例：

java 复制代码 
// 依赖项接口
public interface UserRepository {
    // 定义所需要的操作，例如查找用户等
}

// 依赖项的实现类
@Component
public class UserRepositoryImpl implements UserRepository {
    // 实现UserRepository接口中定义的方法
}

// 使用依赖项的类
@Component
public class UserService {
    private final UserRepository userRepository;

    // 构造函数注入
    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    // 类中的其他方法可以使用userRepository
    public void performAction() {
        // 使用userRepository执行一些操作
    }
}

在这个例子中，UserService需要一个UserRepository的实例。Spring会自动找到匹配UserRepository类型的Bean（在这个例子中是UserRepositoryImpl的实例），然后创建一个UserService的实例，将UserRepositoryImpl作为参数传递给UserService的构造函数。

在Spring应用中，你不需要自己去创建UserService的实例。Spring容器会自动处理这一切。当你需要使用UserService时，你可以让Spring自动注入它，例如：

java 复制代码 
@RestController
public class UserController {
    
    private final UserService userService;

    // 在控制器中通过构造函数注入UserService
    public UserController(UserService userService) {
        this.userService = userService;
    }

    @GetMapping("/users")
    public ResponseEntity<List<User>> getUsers() {
        // 使用userService来处理获取用户的请求
    }
}

在上面的控制器中，UserService将被自动注入到UserController中。这样，你就可以在控制器中使用UserService提供的方法来处理请求了。

2.3 与Spring更紧密的耦合

字段注入使我们的类与 Spring 耦合更紧密，因为它直接在我们的字段上使用 Spring 特定的注释 ( @Autowired)。这可能会在以下场景中出现问题：

「不使用 Spring 的情况」：假设我们正在构建一个不使用 Spring 的轻量级命令行应用程序，但我们仍然想利用 UserService 的逻辑。在这种情况下，@Autowired 注释没有任何意义，不能用于注入依赖项。我们就必须重构该类或实现繁琐的解决方法才能重用UserService.

「切换到另一个 DI 框架」：如果我们决定切换到另一个依赖注入框架，比如 Google Guice，Spring 特定的框架 @Autowired 就会成为一个障碍。那时我们必须重构使用 Spring 特定注释的每一个地方，这会是十分繁琐的。

「可读性和理解性」：对于不熟悉 Spring 的开发人员来说，遇到 @Autowired 注解可能会感到困惑。他们可能想知道如何解决依赖关系，从而增加学习成本（ps：虽然不熟悉 Spring 开发的Java程序员可能很少了）。

2.4 空指针异常

当类利用字段注入并通过其默认构造函数实例化时，依赖字段保持未初始化。

举例来讲：

java 复制代码 
@Component
public class PaymentGateway {
    @Autowired
    private PaymentQueue paymentQueue;

    public void initiate (PaymentRequest request){
        paymentQueue.add(request);
        ...
    }
}

public class PaymentService {
    public void process (PaymentRequest request) {
        PaymentGateway gateway = new PaymentGateway();
        gateway.initiate(request);
    }   
}

通过上面的代码，我们不难看出，如果在运行时以这种状态访问PaymentGateway，则会发生 NullPointerException。在Spring上下文之外手动初始化这些字段的唯一方法是使用反射，反射机制的语法比较繁琐且易错，在程序可读性方面存在一定问题，所以不建议这样做。

2.4.1 为什么直接在非spring类中new一个spring的bean会报NPE？

在您提供的代码示例中，PaymentService类直接通过new关键字创建了PaymentGateway的实例，而不是通过Spring的依赖注入来获取。当直接使用new关键字创建实例时，Spring容器不会介入该对象的生命周期，这意味着Spring不会自动注入PaymentGateway中的依赖paymentQueue。

由于paymentQueue没有被初始化（因为Spring没有注入它），当initiate方法被调用时，它尝试访问paymentQueue的add方法。因为此时paymentQueue是null，所以尝试调用其方法会导致NullPointerException（NPE）。

在Spring应用程序中，为了避免此类问题，应该总是通过Spring容器获取Bean实例，这样Spring就能自动管理Bean的生命周期和依赖注入。如果你需要在Spring管理的Bean中使用PaymentGateway，你应该让Spring注入它，而不是自己创建实例。

例如，改正后的PaymentService可能会看起来像这样：

java 复制代码 
@Service
public class PaymentService {

    private final PaymentGateway paymentGateway;

    @Autowired
    public PaymentService(PaymentGateway paymentGateway) {
        this.paymentGateway = paymentGateway;
    }

    public void process(PaymentRequest request) {
        paymentGateway.initiate(request);
    }
}

在这个修改后的版本中，PaymentGateway由Spring通过构造函数注入到PaymentService中，这样就确保了PaymentGateway的paymentQueue依赖会被Spring容器自动注入，从而避免了NPE。

2.5 循环依赖

字段注入可能会掩盖循环依赖问题，使它们在开发过程中更难被发现。

举例来讲：

考虑两个相互依赖的服务AService和BService:

@Service

public class AService {

@Autowired

private BService bService;

}

@Service

public class BService {

@Autowired

private AService aService;

}

以上可能会导致应用程序中出现意想不到的问题。

使用构造函数注入，Spring会在启动期间立即抛出 BeanCurrentlyInCreationException，让我们意识到循环依赖。不过，要解决循环依赖问题，可以使用@Lazy延迟加载其中一个依赖项。

2.5.1 我记得spring中是允许循环依赖的吧，如何解决的

是的，Spring框架确实支持循环依赖，但是这种支持仅限于字段注入（setter注入）和方法注入。Spring通过使用三级缓存来解决单例作用域下的循环依赖问题，使得在构造函数中注入循环依赖的Bean成为可能。

对于构造函数注入来说，Spring无法处理循环依赖，因为在调用构造函数之前，每个Bean的依赖必须先被解决。如果A需要B才能创建，而B同时也需要A才能创建，Spring就无法决定应该先创建哪个Bean，因此会抛出BeanCurrentlyInCreationException异常。

对于您提到的例子，如果两个服务A和B都通过构造函数相互注入，Spring会在应用程序启动时检测到循环依赖并抛出异常。如果使用字段注入，Spring可以通过先实例化一个Bean，然后在设置属性时实现注入，从而解决循环依赖的问题。

2.5.2 构造器注入如何解决循环依赖问题

如果想要在构造函数注入中解决循环依赖问题，可以使用@Lazy注解来延迟依赖项的加载。例如：

java 复制代码 
@Service
public class AService {
    private final BService bService;

    @Autowired
    public AService(@Lazy BService bService) {
        this.bService = bService;
    }
}

@Service
public class BService {
    private final AService aService;

    @Autowired
    public BService(AService aService) {
        this.aService = aService;
    }
}

在上面的代码中，@Lazy注解确保了BService在AService实例化时不会立即被创建，而是在首次访问BService时才创建。这样，Spring可以先完成AService的创建，然后在需要时创建BService实例，避免了循环依赖问题。

2.6 @Autowired注入不推荐，那么@Resource呢，能够避免@Autowired的这些问题吗？

@Resource 是 Java EE 6 中的注解，它可以用来注入依赖项，其行为略有不同于 Spring 的 @Autowired。下面是这两个注解的一些区别：

  1. 来源：

    • @Autowired 是 Spring 特有的注解。
    • @Resource 来自于 Java 的 javax.annotation 包。

  2. 注入方式：

    • @Autowired 默认按类型进行自动装配。当需要按名称装配时，可以结合 @Qualifier 注解使用。
    • @Resource 默认按名称进行注入，如果没有找到与名称匹配的bean，则会按类型进行注入。它有两个重要属性：name 和 type。

  3. 兼容性：

    • @Autowired 与 Spring 紧密集成，支持Spring特有的功能，如 @Qualifier、@Primary 等。
    • @Resource 是标准的 Java 注解，因此它不依赖于 Spring，并且可以用在任何兼容 Java EE 的容器中。

关于能否避免 @Autowired 的问题：

  • 循环依赖 ：@Resource 并不能解决构造器注入时的循环依赖问题，这是因为循环依赖的问题与注入机制本身相关，而不是特定于某个注解。Spring容器需要创建bean实例时，必须解决所有必需的依赖，不管这些依赖是通过 @Autowired 还是 @Resource 注入的。

  • 依赖不明确 ：@Resource 默认按名称注入，这使得它在有多个类型相同的bean时，可以通过名称指定具体依赖哪个bean，从而在某种程度上提高了注入的明确性。

  • 自动装配的灵活性 ：使用 @Resource 时，你失去了 Spring 提供的一些灵活性，比如使用 @Primary 注解来指定首选的bean。

总的来说，@Resource 注解提供了另一种依赖注入的方式，但它并不能解决所有 @Autowired 可能引发的问题。在Spring框架中，建议优先使用构造器注入（无论是通过 @Autowired 还是通过参数解析），因为它可以帮助你避免上述提到的大多数问题，并且还能提高代码的可测试性。

2.7 在互联网大厂中，哪一种注入用的多？

在互联网大厂中，构造器注入（Constructor Injection）通常是首选的依赖注入方法，原因如下：

  1. 不变性和安全性 ：构造器注入使得依赖项可以是 final 的，这意味着一旦构造了对象，其依赖就不能更改。这种不变性可以减少在多线程环境下的问题，并确保依赖项在使用前已经被完全初始化。

  2. 可测试性：使用构造器注入，可以在不启动整个Spring容器的情况下，更容易地进行单元测试。

  3. 明确的依赖 ：构造器参数强制要求在创建对象时提供依赖项，这使得依赖关系更加明确，避免了 null 引用的可能性。

  4. 框架无关性：构造器注入不依赖于Spring或者任何其他依赖注入框架，这使得代码更容易迁移和重构。

尽管构造器注入在很多情况下是更好的选择，但在实际开发中，还是会根据具体场景和需求来决定使用哪种注入方式。例如，当存在多个构造器参数，并且这些参数中的某些是可选的，或者在某些复杂的依赖场景中，开发者可能会选择字段注入（Field Injection）或者设值注入（Setter Injection）。

@Autowired 和 @Resource 注解都用于自动装配Spring Bean，但由于 @Autowired 提供了与Spring更紧密的集成和更多的灵活性，它通常是更受青睐的选择。不过，实际使用哪一个还是要基于项目的具体需求、团队习惯以及编码规范来决定。在一些遵循严格的Java EE标准的项目中，可能会倾向于使用 @Resource。

最终，无论哪种注入方式，重要的是保持一致性、清晰性和可维护性。大厂的代码规范会倾向于推崇这些原则，并通过代码审查、文档和团队培训来确保最佳实践的贯彻执行。

3 结论

虽然字段注入可能看起来更简洁，但它的缺点远远超过了它的简洁性。构造函数注入在应用程序的可测试性、不变性和整体稳健性方面提供了明显的优势。

它与 SOLID 原则非常一致，确保我们的 Spring Boot 应用程序可维护且不易出错。

所以，建议大家停止在 Spring Boot 中使用字段注入！

图片

图片

图片热门推荐

老板VX群里发飙：八点不到都TM走了!不想干赶紧滚!

MySQL到底是 join 性能好，还是in一下更快呢？

Java编程教程-Java中的Properties类

图片

阅读原文

​

喜欢此内容的人还喜欢

体制内开始降薪了

Java面试那些事儿

不喜欢

入职字节1个月，工资贼高，但想离职~

Java面试那些事儿

不喜欢

面试官是自己前女友，全程被拷问~

Java面试那些事儿

不喜欢

微信扫一扫

关注该公众号

人划线

相关推荐
山山而川粤2 小时前
母婴用品系统｜Java｜SSM｜JSP｜
java·开发语言·后端·学习·mysql
m0_748235073 小时前
SpringBoot集成kafka
spring boot·kafka·linq
玉红7774 小时前
R语言的数据类型
开发语言·后端·golang
呜呼~225145 小时前
前后端数据交互
java·vue.js·spring boot·前端框架·intellij-idea·交互·css3
lvbu_2024war015 小时前
MATLAB语言的网络编程
开发语言·后端·golang
问道飞鱼5 小时前
【Springboot知识】Springboot进阶-实现CAS完整流程
java·spring boot·后端·cas
Q_19284999065 小时前
基于Spring Boot的电影网站系统
java·spring boot·后端
豌豆花下猫6 小时前
Python 潮流周刊#83：uv 的使用技巧（摘要）
后端·python·ai
凡人的AI工具箱6 小时前
每天40分玩转Django：Django部署概述
开发语言·数据库·后端·python·django
SomeB1oody6 小时前
【Rust自学】7.2. 路径（Path）Pt.1：相对路径、绝对路径与pub关键字
开发语言·后端·rust
热门推荐
01docker安装启动问题解决排查02组基轨迹建模 GBTM的介绍与实现（Stata 或 R）03玄机平台应急响应—webshell查杀04Gitlab ci/cd05【一文读懂】NTN（非地面网络）技术介绍06HCIA-datacom数通题库和录播视频资料07新手学习VR全景需要知道的几个问题08RAG 实践- Ollama+RagFlow 部署本地知识库09优化手机性能，解决卡顿问题：关闭这3个微信开关，释放内存空间10分布式训练原理总结（DP、PP、TP 、ZeRO）