Spring对象创建范式的五大适用场景详解

前言

在 Spring 生态的长期演进中，控制反转（IoC）与依赖注入（DI）早已成为企业级开发的默认心智模型。然而，随着项目规模的膨胀，一种"万物皆 Bean"的教条主义倾向正在悄然侵蚀代码质量：容器启动时间从秒级劣化至分钟级，应用上下文中充斥着数千个仅被单一组件使用的伪单例，原本内聚的业务逻辑被过度抽象为散落的配置类。这种对框架的盲目崇拜，本质上是对面向对象设计原则的背离。

Spring 从未宣称要接管所有对象的生杀大权。相反，它提供了一套精密的分层治理体系：容器负责管理具有基础设施语义的协作组件，而开发者则保留对纯领域对象和工具对象的直接控制权。正确划分这条边界，不仅是性能优化的技术手段，更是区分"框架使用者"与"架构设计者"的认知分水岭。

一、 为什么不能"万物皆 Bean"

要理解何时不该使用依赖注入，首先必须量化"成为一个 Bean"的真实成本。这并非简单的 new 操作，而是一条涉及反射、代理、后处理的完整流水线。

当一个类被注册为 Bean 时，Spring 容器需要执行以下操作：通过 CGLIB 或 JDK 动态代理生成子类（若存在 AOP 需求），遍历所有 BeanPostProcessor 进行属性填充与方法拦截织入，解析并注入所有依赖项，执行初始化回调（@PostConstruct、InitializingBean），最后将实例放入单例缓存池。这一系列操作的耗时通常在毫秒级，对于单个 Bean 微不足道，但当数量累积至数千时，启动阶段的延迟将呈线性甚至超线性增长。

更隐蔽的成本在于内存占用。每个 Bean 实例除了自身字段外，还携带代理对象的元数据、AOP 拦截器链、依赖描述符等容器级附加结构。一个空的 Service Bean 经 CGLIB 代理后，其实际内存占用可达原始类的 3-5 倍。在高并发微服务场景中，这些本可避免的内存开销会直接转化为 GC 压力与响应延迟。

从 JVM 运行时角度看，直接 new 的对象享有 JIT 编译器的特殊优待。HotSpot VM 的逃逸分析（Escape Analysis）能够识别出未逃逸出方法作用域的对象，将其分配在栈上而非堆中，配合标量替换（Scalar Replacement）进一步消除对象头开销。这意味着许多临时对象的创建在机器码层面被完全优化掉，实现了真正的零成本抽象。而经由容器获取的 Bean，由于引用关系复杂且跨越多个调用帧，逃逸分析几乎无法生效，每次访问都必须经过堆内存寻址与可能的缓存未命中。

因此，"是否纳入容器"不是一个风格偏好问题，而是一个有明确物理代价的工程权衡。只有当容器提供的价值（生命周期管理、横切增强、依赖解析）显著超过其运行时成本时，注入才是合理的选择。

二、 适合直接实例化的五大场景

基于上述成本分析，以下五类场景因其本质特征与容器能力不匹配，应当坚决采用直接实例化。每个场景均附带生产级代码示例与设计意图解析。

1. 无状态纯工具类：线程安全与零开销的统一

此类对象不包含任何可变状态，所有方法均为基于入参的纯函数计算。它们是数学意义上的"函数"，而非面向对象意义上的"对象"。

@Component
@RequiredArgsConstructor
public class PathRoutingService {

    // ✅ 正确：无状态工具类，直接 new 复用
    // AntPathMatcher 是线程安全的，match() 方法不修改任何内部状态
    private final AntPathMatcher pathMatcher = new AntPathMatcher();

    // ❌ 错误示范（注释说明）：
    // @Autowired private AntPathMatcher pathMatcher;
    // 容器注入不会带来任何额外能力，反而增加启动开销与内存占用

    public boolean isWhitelisted(String requestPath, List<String> patterns) {
        for (String pattern : patterns) {
            if (pathMatcher.match(pattern, requestPath)) {
                return true;
            }
        }
        return false;
    }
}

设计原理：AntPathMatcher 的 match() 方法内部仅读取构造时传入的配置参数，不写入任何实例字段。这种不可变性使其天然线程安全，可在任意数量的线程间共享同一实例而无需同步。将其注册为 Bean 的唯一"好处"是可以被其他组件注入，但路径匹配通常是路由层的私有逻辑，暴露为全局 Bean 违反了最小知识原则。直接 new 既保证了线程安全，又避免了容器开销，还通过字段声明清晰表达了"这是一个内部工具"的设计意图。

关键验证点：使用前必须查阅源码或官方文档确认线程安全性。SimpleDateFormat 常被误认为工具类，但其内部持有可变 Calendar 实例，绝非线程安全，绝不能作为共享字段直接 new。

2. 轻量级策略对象：封装私有算法细节

当对象代表一种由配置驱动的算法规则，且仅服务于单一宿主 Bean 时，它是宿主的"私有实现"，而非独立的"协作组件"。

@Service
@RequiredArgsConstructor
public class OrderPricingService {

    // ✅ 正确：策略对象由宿主构造，参数来自外部配置
    // DiscountStrategy 是 PricingService 的私有算法细节
    private final DiscountCalculator discountCalculator;

    public OrderPricingService(
            @Value("${pricing.discount.rate:0.1}") double discountRate,
            @Value("${pricing.discount.max-cap:100}") double maxCap) {
        // 策略对象在构造期组装，运行时不再变化
        this.discountCalculator = new DiscountCalculator(discountRate, maxCap);
    }

    public BigDecimal calculateFinalPrice(Order order) {
        BigDecimal basePrice = order.getBasePrice();
        // 策略对象的使用完全内聚于当前 Service
        return discountCalculator.apply(basePrice);
    }

    // 策略类定义为静态内部类或包级私有类，强调其附属地位
    static class DiscountCalculator {
        private final double rate;
        private final double maxCap;

        DiscountCalculator(double rate, double maxCap) {
            this.rate = rate;
            this.maxCap = maxCap;
        }

        BigDecimal apply(BigDecimal price) {
            double discount = Math.min(price.doubleValue() * rate, maxCap);
            return price.subtract(BigDecimal.valueOf(discount));
        }
    }
}

设计原理：DiscountCalculator 的行为完全由构造参数决定，不依赖任何 Spring 基础设施。若将其抽取为独立 Bean 并通过 @Autowired 注入，会产生三重损害：其一，阅读 OrderPricingService 时必须跳转至另一个文件才能理解定价逻辑，破坏了代码的局部可读性；其二，DiscountCalculator 被暴露为全局 Bean，其他无关 Service 可能误注入并滥用，违反了封装原则；其三，若未来需要支持多套定价策略（如按租户区分），Bean 方式需要引入 @Qualifier 或条件装配等复杂机制，而直接 new 只需在构造器中增加一个分支判断。

核心收益：将策略对象视为"带参数的纯函数"而非"有状态的组件"，使业务逻辑的表达回归到算法本身，而非框架的装配规则。

3. 短生命周期临时对象：规避 Prototype 的性能陷阱

此类对象持有可变状态，仅在单次请求或方法调用内有效，用完即弃。它们是高并发热点路径上的常见角色。

@Service
public class LogAggregationService {

    public String aggregateLogs(List<LogEntry> entries) {
        // ✅ 正确：StringBuilder 是典型的短命可变对象
        // 直接 new 享受 JIT 栈上分配优化，GC 压力趋近于零
        StringBuilder buffer = new StringBuilder(entries.size() * 128);

        for (LogEntry entry : entries) {
            buffer.append(entry.getTimestamp())
                  .append(" | ")
                  .append(entry.getLevel())
                  .append(" | ")
                  .append(entry.getMessage())
                  .append('\n');
        }
        return buffer.toString();

        // ❌ 错误示范（概念说明）：
        // @Autowired ObjectProvider<StringBuilder> builderProvider;
        // StringBuilder sb = builderProvider.getObject();
        // Prototype Bean 仍需经过容器查找、实例化、后处理流程
        // 在高 QPS 场景下，容器开销远超对象创建本身
    }
}

设计原理：Prototype 作用域常被误解为"短命对象的解决方案"，实则它是一个性能反模式。每次 getObject() 调用都会触发完整的 Bean 创建流水线，包括同步锁竞争（单例注册表的并发保护）、后处理器遍历、属性类型转换等。在日志聚合这类每秒执行数万次的热点方法中，容器开销将成为主导因素。直接 new 的 StringBuilder 经 HotSpot 逃逸分析后，大概率被分配在执行线程的栈帧上，方法返回时随栈帧弹出自动回收，完全不触及垃圾收集器。

扩展场景：JSON 序列化器（如 new JsonWriter(outputStream)）、XML 解析器、加密 Cipher 实例、数据库 ResultSet 处理器等均属此类。核心判断标准是"可变状态 + 高频创建"，两者同时满足即排除容器管理。

4. 第三方库的非 Spring 原生对象：保持依赖关系的内聚性

当第三方库不提供 Spring Boot Starter，或其构造函数需要复杂参数，且仅被单一组件使用时，强行 @Bean 包装是一种不必要的间接层。

@Service
public class ExternalNotificationService {

    // ✅ 正确：第三方客户端作为私有依赖，在使用处直接构建
    // 明确表达"这个客户端就是为通知服务准备的"
    private final NotificationClient client;

    public ExternalNotificationService(
            @Value("${notification.endpoint}") String endpoint,
            @Value("${notification.api-key}") String apiKey,
            @Value("${notification.timeout-ms:5000}") int timeoutMs) {
        // 构造参数全部来自 Spring 配置，但客户端本身不是 Bean
        this.client = NotificationClient.builder()
                .endpoint(endpoint)
                .apiKey(apiKey)
                .timeout(Duration.ofMillis(timeoutMs))
                .retryPolicy(RetryPolicy.exponentialBackoff(3))
                .build();
    }

    public void sendAlert(String message) {
        client.send(NotificationRequest.of(message));
    }

    // ❌ 对比：若在 @Configuration 中定义 @Bean
    // 1. 产生一个仅被 ExternalNotificationService 消费的全局 Bean
    // 2. 配置类与使用方分离，修改时需跨文件协调
    // 3. 若未来需要第二个不同配置的客户端，需引入 @Qualifier 等复杂机制
}

设计原理：@Configuration 类的职责是声明"基础设施"，即那些具有独立生命周期、需要被多个消费者共享的资源（如数据源、连接池、消息模板）。而 NotificationClient 在此场景中是 ExternalNotificationService 的专属依赖，其配置参数、生命周期、错误处理策略均与宿主紧密耦合。将其提升为全局 Bean，等于将一个"实现细节"伪装成了"基础设施"，误导后续维护者认为它可以被安全地注入到其他组件中。

例外情况：若客户端的创建涉及昂贵资源（如 TCP 连接池建立、TLS 握手），即使只有一个消费者，也应使用 @Bean 管理，以便利用容器的懒加载（@Lazy）和销毁回调（@PreDestroy）确保资源的正确释放。此时权衡的天平从"内聚性"转向了"资源安全"。

5. 测试替身与手动组装：脱离容器的确定性验证

在单元测试中，直接 new 是保证测试隔离性与执行速度的基石。

@ExtendWith(MockitoExtension.class)
class OrderPricingServiceTest {

    @Test
    void shouldApplyDiscountCorrectly() {
        // ✅ 正确：直接构造被测对象，精确控制所有依赖
        // 测试不依赖 Spring 上下文，执行时间 < 1ms
        var calculator = new OrderPricingService.DiscountCalculator(0.1, 100);
        var service = new OrderPricingService(calculator); // 假设构造器接受策略对象

        Order order = Order.builder().basePrice(new BigDecimal("500")).build();
        BigDecimal result = service.calculateFinalPrice(order);

        assertEquals(new BigDecimal("450.00"), result);
    }

    // ❌ 对比：@SpringBootTest + @Autowired
    // 1. 启动完整容器，耗时数秒至数十秒
    // 2. 加载大量无关 Bean，测试结果受环境污染
    // 3. 无法精确控制 DiscountCalculator 的参数，难以覆盖边界条件
}

设计原理：单元测试的核心价值在于"快速反馈"与"行为隔离"。Spring 上下文是一个庞大的全局状态机，其中任何一个 Bean 的初始化失败、配置缺失或副作用都可能干扰目标测试。直接 new 确保了测试的可重复性与确定性，使开发者能够在编码过程中高频运行测试而不感知延迟。这也是为什么前述四种场景推荐直接 new 的深层原因之一：可测试性是设计质量的试金石，如果一个类必须依赖容器才能被构造，那它很可能承担了过多职责。

三、 绝对禁止手动 new 的红线区域

以下场景若使用 new，将导致功能性缺陷且无编译期提示，是必须严守的工程红线。

含有 Spring 注解的类：@Value、@Autowired、@Resource、@PostConstruct 等注解是容器后处理的契约，而非 Java 语言特性。手动 new 将使所有注解静默失效，字段值为 null，初始化方法不被调用。这是生产环境中最常见的隐蔽 Bug 来源。

实现 Spring 回调接口的类：InitializingBean、ApplicationContextAware、DisposableBean 等接口的回调由容器在特定生命周期节点触发。脱离容器即失去意义，对象将无法完成必要的初始化或资源清理。

需要 AOP 增强的 Service/Repository：@Transactional、@Cacheable、@Async、@PreAuthorize 等注解依赖代理对象织入横切逻辑。new 出来的原始实例调用这些方法时，事务不会开启、缓存不会生效、权限不会校验，且无任何警告日志。数据一致性 事故往往由此引发。

@Configuration 类本身：配置类必须被容器管理，否则其中的 @Bean 方法不会被扫描执行，整个配置模块静默失效。

四、 这样设计的深层收益

理解"何时 new、何时注入"不仅是为了遵守规范，更是为了获得以下四个维度的实质性收益。

性能收益的可量化性：减少不必要的 Bean 注册可直接缩短应用启动时间。在一个拥有 2000+ Bean 的典型微服务中，将其中 30% 的工具类、策略对象、临时对象改为直接 new，通常可将启动时间缩短 15%-25%，堆内存基线降低 10%-20%。在 Serverless 或弹性伸缩场景中，这意味着更快的冷启动速度与更低的资源账单。

认知负荷的结构性降低：代码的可读性不仅取决于命名与注释，更取决于信息的空间局部性。当策略对象、工具类以内联方式存在于使用处时，开发者无需在多个文件间跳转即可理解完整逻辑。这种"自包含"的代码结构显著降低了新成员的上手成本与日常维护的认知负担。

可测试性的内生保障：直接 new 的对象天然是可测试的，因为它们不依赖容器环境。这倒逼开发者在设计阶段就考虑构造函数的纯净性，避免隐式依赖。长此以往，代码库的整体可测试性将从"需要刻意维护的属性"变为"设计自然的副产品"。

架构演进的灵活性：当对象不被容器绑定时，重构的自由度大幅提升。可以将一个直接 new 的策略对象轻松迁移到非 Spring 环境（如批处理脚本、CLI 工具、Flink 作业），而无需剥离注解或模拟容器上下文。这种"框架无关性"是抵御技术栈锁定风险的重要屏障。

五、 决策矩阵

终极判断口诀：有状态、需代理、要共享、赖设施 → 注入；纯计算、私有化、短命、非原生 → new。

到此这篇关于Spring对象创建范式的五大适用场景详解的文章就介绍到这了,更多相关Spring对象创建范式内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！