前言

在 Spring 生態(tài)的長期演進中，控制反轉（IoC）與依賴注入（DI）早已成為企業(yè)級開發(fā)的默認心智模型。然而，隨著項目規(guī)模的膨脹，一種"萬物皆 Bean"的教條主義傾向正在悄然侵蝕代碼質量：容器啟動時間從秒級劣化至分鐘級，應用上下文中充斥著數(shù)千個僅被單一組件使用的偽單例，原本內聚的業(yè)務邏輯被過度抽象為散落的配置類。這種對框架的盲目崇拜，本質上是對面向對象設計原則的背離。

Spring 從未宣稱要接管所有對象的生殺大權。相反，它提供了一套精密的分層治理體系：容器負責管理具有基礎設施語義的協(xié)作組件，而開發(fā)者則保留對純領域對象和工具對象的直接控制權。正確劃分這條邊界，不僅是性能優(yōu)化的技術手段，更是區(qū)分"框架使用者"與"架構設計者"的認知分水嶺。

一、 為什么不能"萬物皆 Bean"

要理解何時不該使用依賴注入，首先必須量化"成為一個 Bean"的真實成本。這并非簡單的 new 操作，而是一條涉及反射、代理、后處理的完整流水線。

當一個類被注冊為 Bean 時，Spring 容器需要執(zhí)行以下操作：通過 CGLIB 或 JDK 動態(tài)代理生成子類（若存在 AOP 需求），遍歷所有 BeanPostProcessor 進行屬性填充與方法攔截織入，解析并注入所有依賴項，執(zhí)行初始化回調（@PostConstruct、InitializingBean），最后將實例放入單例緩存池。這一系列操作的耗時通常在毫秒級，對于單個 Bean 微不足道，但當數(shù)量累積至數(shù)千時，啟動階段的延遲將呈線性甚至超線性增長。

更隱蔽的成本在于內存占用。每個 Bean 實例除了自身字段外，還攜帶代理對象的元數(shù)據(jù)、AOP 攔截器鏈、依賴描述符等容器級附加結構。一個空的 Service Bean 經 CGLIB 代理后，其實際內存占用可達原始類的 3-5 倍。在高并發(fā)微服務場景中，這些本可避免的內存開銷會直接轉化為 GC 壓力與響應延遲。

從 JVM 運行時角度看，直接 new 的對象享有 JIT 編譯器的特殊優(yōu)待。HotSpot VM 的逃逸分析（Escape Analysis）能夠識別出未逃逸出方法作用域的對象，將其分配在棧上而非堆中，配合標量替換（Scalar Replacement）進一步消除對象頭開銷。這意味著許多臨時對象的創(chuàng)建在機器碼層面被完全優(yōu)化掉，實現(xiàn)了真正的零成本抽象。而經由容器獲取的 Bean，由于引用關系復雜且跨越多個調用幀，逃逸分析幾乎無法生效，每次訪問都必須經過堆內存尋址與可能的緩存未命中。

因此，"是否納入容器"不是一個風格偏好問題，而是一個有明確物理代價的工程權衡。只有當容器提供的價值（生命周期管理、橫切增強、依賴解析）顯著超過其運行時成本時，注入才是合理的選擇。

二、 適合直接實例化的五大場景

基于上述成本分析，以下五類場景因其本質特征與容器能力不匹配，應當堅決采用直接實例化。每個場景均附帶生產級代碼示例與設計意圖解析。

1. 無狀態(tài)純工具類：線程安全與零開銷的統(tǒng)一

此類對象不包含任何可變狀態(tài)，所有方法均為基于入?yún)⒌募兒瘮?shù)計算。它們是數(shù)學意義上的"函數(shù)"，而非面向對象意義上的"對象"。

@Component
@RequiredArgsConstructor
public class PathRoutingService {

    // ? 正確：無狀態(tài)工具類，直接 new 復用
    // AntPathMatcher 是線程安全的，match() 方法不修改任何內部狀態(tài)
    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() 方法內部僅讀取構造時傳入的配置參數(shù)，不寫入任何實例字段。這種不可變性使其天然線程安全，可在任意數(shù)量的線程間共享同一實例而無需同步。將其注冊為 Bean 的唯一"好處"是可以被其他組件注入，但路徑匹配通常是路由層的私有邏輯，暴露為全局 Bean 違反了最小知識原則。直接 new 既保證了線程安全，又避免了容器開銷，還通過字段聲明清晰表達了"這是一個內部工具"的設計意圖。

關鍵驗證點：使用前必須查閱源碼或官方文檔確認線程安全性。SimpleDateFormat 常被誤認為工具類，但其內部持有可變 Calendar 實例，絕非線程安全，絕不能作為共享字段直接 new。

2. 輕量級策略對象：封裝私有算法細節(jié)

當對象代表一種由配置驅動的算法規(guī)則，且僅服務于單一宿主 Bean 時，它是宿主的"私有實現(xiàn)"，而非獨立的"協(xié)作組件"。

@Service
@RequiredArgsConstructor
public class OrderPricingService {

    // ? 正確：策略對象由宿主構造，參數(shù)來自外部配置
    // DiscountStrategy 是 PricingService 的私有算法細節(jié)
    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);
    }

    // 策略類定義為靜態(tài)內部類或包級私有類，強調其附屬地位
    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 的行為完全由構造參數(shù)決定，不依賴任何 Spring 基礎設施。若將其抽取為獨立 Bean 并通過 @Autowired 注入，會產生三重損害：其一，閱讀 OrderPricingService 時必須跳轉至另一個文件才能理解定價邏輯，破壞了代碼的局部可讀性；其二，DiscountCalculator 被暴露為全局 Bean，其他無關 Service 可能誤注入并濫用，違反了封裝原則；其三，若未來需要支持多套定價策略（如按租戶區(qū)分），Bean 方式需要引入 @Qualifier 或條件裝配等復雜機制，而直接 new 只需在構造器中增加一個分支判斷。

核心收益：將策略對象視為"帶參數(shù)的純函數(shù)"而非"有狀態(tài)的組件"，使業(yè)務邏輯的表達回歸到算法本身，而非框架的裝配規(guī)則。

3. 短生命周期臨時對象：規(guī)避 Prototype 的性能陷阱

此類對象持有可變狀態(tài)，僅在單次請求或方法調用內有效，用完即棄。它們是高并發(fā)熱點路徑上的常見角色。

@Service
public class LogAggregationService {

    public String aggregateLogs(List<LogEntry> entries) {
        // ? 正確：StringBuilder 是典型的短命可變對象
        // 直接 new 享受 JIT 棧上分配優(yōu)化，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 場景下，容器開銷遠超對象創(chuàng)建本身
    }
}

設計原理：Prototype 作用域常被誤解為"短命對象的解決方案"，實則它是一個性能反模式。每次 getObject() 調用都會觸發(fā)完整的 Bean 創(chuàng)建流水線，包括同步鎖競爭（單例注冊表的并發(fā)保護）、后處理器遍歷、屬性類型轉換等。在日志聚合這類每秒執(zhí)行數(shù)萬次的熱點方法中，容器開銷將成為主導因素。直接 new 的 StringBuilder 經 HotSpot 逃逸分析后，大概率被分配在執(zhí)行線程的棧幀上，方法返回時隨棧幀彈出自動回收，完全不觸及垃圾收集器。

擴展場景：JSON 序列化器（如 new JsonWriter(outputStream)）、XML 解析器、加密 Cipher 實例、數(shù)據(jù)庫 ResultSet 處理器等均屬此類。核心判斷標準是"可變狀態(tài) + 高頻創(chuàng)建"，兩者同時滿足即排除容器管理。

4. 第三方庫的非 Spring 原生對象：保持依賴關系的內聚性

當?shù)谌綆觳惶峁?Spring Boot Starter，或其構造函數(shù)需要復雜參數(shù)，且僅被單一組件使用時，強行 @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) {
        // 構造參數(shù)全部來自 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. 配置類與使用方分離，修改時需跨文件協(xié)調
    // 3. 若未來需要第二個不同配置的客戶端，需引入 @Qualifier 等復雜機制
}

設計原理：@Configuration 類的職責是聲明"基礎設施"，即那些具有獨立生命周期、需要被多個消費者共享的資源（如數(shù)據(jù)源、連接池、消息模板）。而 NotificationClient 在此場景中是 ExternalNotificationService 的專屬依賴，其配置參數(shù)、生命周期、錯誤處理策略均與宿主緊密耦合。將其提升為全局 Bean，等于將一個"實現(xiàn)細節(jié)"偽裝成了"基礎設施"，誤導后續(xù)維護者認為它可以被安全地注入到其他組件中。

例外情況：若客戶端的創(chuàng)建涉及昂貴資源（如 TCP 連接池建立、TLS 握手），即使只有一個消費者，也應使用 @Bean 管理，以便利用容器的懶加載（@Lazy）和銷毀回調（@PreDestroy）確保資源的正確釋放。此時權衡的天平從"內聚性"轉向了"資源安全"。

5. 測試替身與手動組裝：脫離容器的確定性驗證

在單元測試中，直接 new 是保證測試隔離性與執(zhí)行速度的基石。

@ExtendWith(MockitoExtension.class)
class OrderPricingServiceTest {

    @Test
    void shouldApplyDiscountCorrectly() {
        // ? 正確：直接構造被測對象，精確控制所有依賴
        // 測試不依賴 Spring 上下文，執(zhí)行時間 < 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. 啟動完整容器，耗時數(shù)秒至數(shù)十秒
    // 2. 加載大量無關 Bean，測試結果受環(huán)境污染
    // 3. 無法精確控制 DiscountCalculator 的參數(shù)，難以覆蓋邊界條件
}

設計原理：單元測試的核心價值在于"快速反饋"與"行為隔離"。Spring 上下文是一個龐大的全局狀態(tài)機，其中任何一個 Bean 的初始化失敗、配置缺失或副作用都可能干擾目標測試。直接 new 確保了測試的可重復性與確定性，使開發(fā)者能夠在編碼過程中高頻運行測試而不感知延遲。這也是為什么前述四種場景推薦直接 new 的深層原因之一：可測試性是設計質量的試金石，如果一個類必須依賴容器才能被構造，那它很可能承擔了過多職責。

三、 絕對禁止手動 new 的紅線區(qū)域

以下場景若使用 new，將導致功能性缺陷且無編譯期提示，是必須嚴守的工程紅線。

含有 Spring 注解的類：@Value、@Autowired、@Resource、@PostConstruct 等注解是容器后處理的契約，而非 Java 語言特性。手動 new 將使所有注解靜默失效，字段值為 null，初始化方法不被調用。這是生產環(huán)境中最常見的隱蔽 Bug 來源。

實現(xiàn) Spring 回調接口的類：InitializingBean、ApplicationContextAware、DisposableBean 等接口的回調由容器在特定生命周期節(jié)點觸發(fā)。脫離容器即失去意義，對象將無法完成必要的初始化或資源清理。

需要 AOP 增強的 Service/Repository：@Transactional、@Cacheable、@Async、@PreAuthorize 等注解依賴代理對象織入橫切邏輯。new 出來的原始實例調用這些方法時，事務不會開啟、緩存不會生效、權限不會校驗，且無任何警告日志。數(shù)據(jù)一致性 事故往往由此引發(fā)。

@Configuration 類本身：配置類必須被容器管理，否則其中的 @Bean 方法不會被掃描執(zhí)行，整個配置模塊靜默失效。

四、 這樣設計的深層收益

理解"何時 new、何時注入"不僅是為了遵守規(guī)范，更是為了獲得以下四個維度的實質性收益。

性能收益的可量化性：減少不必要的 Bean 注冊可直接縮短應用啟動時間。在一個擁有 2000+ Bean 的典型微服務中，將其中 30% 的工具類、策略對象、臨時對象改為直接 new，通?？蓪訒r間縮短 15%-25%，堆內存基線降低 10%-20%。在 Serverless 或彈性伸縮場景中，這意味著更快的冷啟動速度與更低的資源賬單。

認知負荷的結構性降低：代碼的可讀性不僅取決于命名與注釋，更取決于信息的空間局部性。當策略對象、工具類以內聯(lián)方式存在于使用處時，開發(fā)者無需在多個文件間跳轉即可理解完整邏輯。這種"自包含"的代碼結構顯著降低了新成員的上手成本與日常維護的認知負擔。

可測試性的內生保障：直接 new 的對象天然是可測試的，因為它們不依賴容器環(huán)境。這倒逼開發(fā)者在設計階段就考慮構造函數(shù)的純凈性，避免隱式依賴。長此以往，代碼庫的整體可測試性將從"需要刻意維護的屬性"變?yōu)?quot;設計自然的副產品"。

架構演進的靈活性：當對象不被容器綁定時，重構的自由度大幅提升?？梢詫⒁粋€直接 new 的策略對象輕松遷移到非 Spring 環(huán)境（如批處理腳本、CLI 工具、Flink 作業(yè)），而無需剝離注解或模擬容器上下文。這種"框架無關性"是抵御技術棧鎖定風險的重要屏障。

五、 決策矩陣

終極判斷口訣：有狀態(tài)、需代理、要共享、賴設施 → 注入；純計算、私有化、短命、非原生 → new。

到此這篇關于Spring對象創(chuàng)建范式的五大適用場景詳解的文章就介紹到這了,更多相關Spring對象創(chuàng)建范式內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論