生命週期管理

物件生命週期管理是指控制配置服務例項數量及其生存期的概念。換句話說，它允許您確定如何快取返回的例項。

手動生命週期管理

工廠

在現實世界中，工廠用於製造東西（例如汽車）。在面向物件程式設計中，工廠也製造東西；具體來說，面向物件工廠“製造”（例項化）物件。

至少在 Java 中，建構函式無法返回對現有物件的引用——它必須返回一個全新的物件。這會導致兩個問題——物件例項太多，以及相同的物件是重複的——不是同一個物件。

工廠通常實現為一個公共靜態方法，該方法位於一個只有私有建構函式的類中。這樣，只有工廠才能建立“保證^[1]”所有物件例項都由工廠建立的例項。

工廠通常有一個內部的“快取”物件。每當使用者向工廠請求一個新物件時，它會先檢查快取，如果快取中存在相同的物件，則返回快取中的物件；否則，它會建立一個新的例項，將其新增到快取並返回。

工廠還可以用於將使用者程式碼注入到“不可修改”的庫中。可以儲存和恢復實現庫物件某些重要功能的使用者物件。然後庫使用該工廠獲取使用者物件的例項，甚至不知道使用者用全新的程式碼替換了核心元件。

舉個例子…假設庫在很多地方使用 Library 物件。庫使用者可以建立一個類（我們稱之為 User），該類擴充套件了 Library。然後使用者呼叫 LibraryFactory.set(User.class)，工廠將其儲存起來。在庫內部，每當庫想要使用 Library 物件時，它都會呼叫 LibraryFactory.Factory() 函式來獲取一個新例項。無需修改任何程式碼，使用者現在就可以透過重寫 User 類中的一個或多個方法來完全改變庫的功能。

這在 Java SDK 內部用於允許您更改 SDK 部分的工作方式，而無需重寫任何程式碼。

↑ 在 Java 中，僅僅擁有私有建構函式並不能真正保證所有物件都來自工廠。序列化和反射仍然可以建立新的例項，而無需經過建構函式。

引用計數

引用計數是一種程式設計技術，它儲存對資源的引用、指標或控制代碼的數量，例如物件、記憶體塊、磁碟空間等等。

垃圾回收

垃圾回收是指釋放堆分配的記憶體。堆記憶體最終必須被釋放。要麼程式設計師的程式碼必須顯式地釋放它，要麼需要一些自動系統機制。

最常見的機制是標記清除。這是指系統知道某些頂層類（主要是執行緒和視窗）。它跟蹤從這些“已知”類到所有可達類的所有引用，並標記每個類。完成後，它會“清除”（刪除）所有未標記的類。

垃圾回收是面向物件開發的強大推動力——它完全改變了您的設計方式。在使用基於程式碼的記憶體管理時，必須有一種方法來跟蹤物件。如果它是在堆疊上建立的，那麼它將在方法退出時被刪除（因此傳遞到方法外部的例項將變為無效）。如果它是在堆上建立的，則一些物件必須手動刪除它——因此，如果您的方法將建立一個物件並將其傳遞給另外兩個都保留該物件的另一個物件，那麼您就會遇到問題。誰刪除了物件？原始方法不能，因為它將在兩個物件完成操作之前退出，而兩個物件不應該互相瞭解。

這類問題通常使用“引用計數”來解決，引用計數是垃圾回收的另一種形式，但它是手動形式。它還會導致建立的長期存在的、自由漫遊的類更少，因為它們必須被跟蹤。

GC 解決所有權問題。如果您使用的是支援垃圾回收的語言進行程式設計，您可以在執行時建立類，將它們傳遞出去，保留副本或忘記它……您實際上不會出錯。當所有例項都被“忘記”時，該類就會消失。

缺點是 GC 往往需要大量時間。近年來，情況有所改善，至少 Java 已經擁有了執行緒化的 GC 以及限制 GC 執行時間的能力。實際上，存在數十種調整和報告選項，以及從多個 GC 系統中選擇以滿足您的需求的能力。

GC 實現從微不足道的（例項計數）到非常複雜的都有。當前的預設 Java VM 使用多層系統，對新物件、中年物件和老物件使用不同的機制。例如，由於幾乎所有新物件都幾乎立即死亡，所以第一個部分（伊甸園）被分成兩半。當一半滿了時，當前引用的物件會被複制到另一邊。系統切換到使用“新”邊，完全忘記舊邊。不會呼叫任何顯式程式碼來刪除已經消失的物件。

這意味著 GC 實際上可能比傳統的分配/釋放更有效，因為對於幾乎所有物件來說，都沒有釋放操作。

垃圾回收應該被視為面向物件設計的必要條件。