Spring自动注入Bean与手动创建实例的选型及性能问题咨询

一、判断使用注入单例Bean还是手动实例的经验法则 #

• 无状态/全局复用逻辑：如果类仅负责纯逻辑处理，不持有请求、会话级别的专属状态（比如工具类、业务规则校验器、配置完成的第三方客户端），优先用Spring单例Bean。这类实例创建成本高、复用性强，单例模式能避免重复初始化的开销。
• 请求/会话级带状态对象：如果类需要持有当前请求的上下文数据（比如用户信息、请求参数封装、流程中间状态），直接手动创建实例。比如订单处理上下文、用户表单验证器（绑定当前表单数据），这些状态属于单次请求专属，不能在多请求间共享。
• 依赖动态参数的实例：如果实例创建依赖每次请求都变化的参数，无法提前在Spring容器中初始化，必须手动创建。比如根据请求中的用户ID生成的专属业务处理器。

二、短生命周期实例的性能影响 #

现代JVM的对象创建和垃圾回收效率已经很高，只要不是极端数量级（比如每秒创建上百万个复杂对象），性能影响基本可以忽略。Spring本身也支持@RequestScope这类请求级Bean，底层就是每次请求创建新实例，实际项目中很少因为这个出现性能瓶颈。

如果确实担心，可做两点优化：

• 复用高成本对象：用对象池（如Apache Commons Pool）管理创建成本高的短生命周期对象（比如数据库连接、复杂解析器），但普通POJO级对象没必要。
• 避免循环内重复创建：如果在循环中频繁创建简单对象，尽量合并逻辑或采用更高效的创建方式，这属于通用代码优化，并非Spring特有的问题。

三、结合Spring Bean和手动实例的正确设计方式 #

以电商订单处理场景为例，拆分无状态逻辑和带状态上下文：

1. 无状态单例Bean（Spring管理）：

@Service
public class OrderRuleService {
    // 无状态，仅负责通用规则校验
    public boolean isValidOrderAmount(BigDecimal amount) {
        return amount.compareTo(BigDecimal.ZERO) > 0;
    }
}

2. 手动创建的带状态实例（封装业务上下文与行为）：

public class OrderProcessor {
    private final OrderRuleService ruleService;
    private final OrderDTO orderDTO;
    private boolean isOrderValid;

    // 通过构造注入单例Bean，绑定当前请求的订单数据
    public OrderProcessor(OrderRuleService ruleService, OrderDTO orderDTO) {
        this.ruleService = ruleService;
        this.orderDTO = orderDTO;
        this.isOrderValid = ruleService.isValidOrderAmount(orderDTO.getAmount());
    }

    // 封装订单处理行为，依赖自身持有的状态
    public OrderResult process() {
        if (!isOrderValid) {
            return OrderResult.invalid("订单金额非法");
        }
        // 执行具体订单处理逻辑
        return OrderResult.success();
    }
}

3. 在Controller中结合使用：

@RestController
@RequestMapping("/orders")
public class OrderController {
    private final OrderRuleService ruleService;

    public OrderController(OrderRuleService ruleService) {
        this.ruleService = ruleService;
    }

    @PostMapping
    public OrderResult createOrder(@RequestBody OrderDTO orderDTO) {
        // 手动创建带状态的处理器，注入单例规则服务
        OrderProcessor processor = new OrderProcessor(ruleService, orderDTO);
        return processor.process();
    }
}

核心设计思路：

• 把无状态的通用逻辑抽成Spring单例Bean，集中管理、复用，避免代码重复。
• 把带状态的业务上下文封装成手动创建的实例，让它自身负责状态维护和行为执行，符合面向对象的封装原则。
• 绝对避免将请求级状态放到单例Bean中，防止并发问题；也不要把通用逻辑写到带状态实例里，避免逻辑分散。

内容的提问来源于stack exchange，提问作者Jomy