## 對象創建與生命周期 我們在使用對象時要注意的一個關鍵問題就是對象的創建和銷毀方式。每個對象的生存都需要資源，尤其是內存。為了資源的重復利用，當對象不再被使用時，我們應該及時釋放資源，清理內存。 在簡單的編程場景下，對象的清理并不是問題。我們創建對象，按需使用，最后銷毀它。然而，情況往往要比這更復雜： 假設，我們正在為機場設計一個空中交通管制的系統（該例也適用于倉庫貨柜管理、影帶出租或者寵物寄養倉庫系統）。第一步比較簡單：創建一個用來保存飛機的集合，每當有飛機進入交通管制區域時，我們就創建一個“飛機”對象并將其加入到集合中，等到飛機離開時將其從這個集合中清除。與此同時，我們還需要一個記錄飛機信息的系統，也許這些數據不像主要控制功能那樣引人注意。比如，我們要記錄所有飛機中的小型飛機的的信息（比如飛行計劃）。此時，我們又創建了第二個集合來記錄所有小型飛機。 每當創建一個“飛機”對象的時候，將其放入第一個集合；若它屬于小型飛機，也必須同時將其放入第二個集合里。 現在問題開始棘手了：我們怎么知道何時該清理這些對象呢？當某一個系統處理完成，而其他系統可能還沒有處理完成。這樣的問題在其他的場景下也可能發生。在 C++ 程序設計中，當使用完一個對象后，必須明確將其刪除，這就讓問題變復雜了。 對象的數據在哪？它的生命周期是怎么被控制的？ 在 C++ 設計中采用的觀點是效率第一，因此它將選擇權交給了程序員。為了獲得最大的運行時速度，程序員可以在編寫程序時，通過將對象放在棧（Stack，有時稱為自動變量或作用域變量）或靜態存儲區域（static storage area）中來確定內存占用和生存時間。這些區域的對象會被優先分配內存和釋放。這種控制在某些情況下非常有用。 然而相對的，我們也犧牲了程序的靈活性。因為在編寫代碼時，我們必須要弄清楚對象的數量、生存時間還有類型。如果我們要用它來解決一個相當普遍的問題時（如計算機輔助設計、倉庫管理或空中交通管制等），限制就太大了。 第二種方法是在堆內存（Heap）中動態地創建對象。在這種方式下，直到程序運行我們才能確定需要創建的對象數量、生存時間和類型。什么時候需要，什么時候在堆內存中創建。 因為內存的占用是動態管理的，所以在運行時，在堆內存上開辟空間所需的時間可能比在棧內存上要長（但也不一定）。在棧內存開辟和釋放空間通常是一條將棧指針向下移動和一條將棧指針向上移動的匯編指令。開辟堆內存空間的時間取決于內存機制的設計。 動態方法有這樣一個合理假設：對象通常是復雜的，相比于對象創建的整體開銷，尋找和釋放內存空間的開銷微不足道。（原文：*The dynamic approach makes the generally logical assumption that objects tend to be complicated, so the extra overhead of finding storage and releasing that storage will not have an important impact on the creation of an object.*）此外，更好的靈活性對于問題的解決至關重要。 Java 使用動態內存分配。每次創建對象時，使用 `new` 關鍵字構建該對象的動態實例。這又帶來另一個問題：對象的生命周期。較之堆內存，在棧內存中創建對象，編譯器能夠確定該對象的生命周期并自動銷毀它；然而如果你在堆內存創建對象的話，編譯器是不知道它的生命周期的。在 C++ 中你必須以編程方式確定何時銷毀對象，否則可能導致內存泄漏。Java 的內存管理是建立在垃圾收集器上的，它能自動發現對象不再被使用并釋放內存。垃圾收集器的存在帶來了極大的便利，它減少了我們之前必須要跟蹤的問題和編寫相關代碼的數量。因此，垃圾收集器提供了更高級別的保險，以防止潛在的內存泄漏問題，這個問題使得許多 C++ 項目沒落。 Java 的垃圾收集器被設計用來解決內存釋放的問題（雖然這不包括對象清理的其他方面）。垃圾收集器知道對象什么時候不再被使用并且自動釋放內存。結合單繼承和僅可在堆中創建對象的機制，Java 的編碼過程比用 C++ 要簡單得多。我們所要做的決定和要克服的障礙也會少很多！