Share via


記憶體管理中的開發者背景

您對記憶體管理的體驗會依您的開發背景而有所不同。在有些情況下,您必須調整程式設計方式來適應 Common Language Runtime 提供的自動記憶體管理。

COM 開發者

COM 開發者習慣於實作參考計數做為手動記憶體管理的技巧。每一次參考物件時,計數器都會遞增。當物件的參考超出範圍時,計數器便會遞減。當物件參考計數到達零的時候,物件就會結束而釋放記憶體。

參考計數配置是許多錯誤的來源。如果沒有精確地遵照參考計數規則,可能會讓物件過早釋放,或者讓未參考的物件在記憶體中累積。循環參考也是常見的錯誤來源。當子物件具有父物件的參考,而父物件又具有子物件的參考時,就會發生循環參考。這種情況會讓任何一個物件都無法被釋放或終結。唯一的解決之道是讓父物件和子物件協議一種使用和解構的固定模式,例如讓父物件永遠率先刪除子物件。

當您要以適用於 Common Language Runtime 的程式語言來開發應用程式時,Runtime 的記憶體回收行程會減少使用參考計數的需求,進而也排除了以手動方式管理記憶體配置所可能發生的錯誤。

C++ 開發人員

C++ 開發者已習慣於以人工方式管理記憶體的相關工作。在 C++ 中,當您使用 new 運算子配置物件的記憶體時,您必須使用 delete 運算子來釋放物件的記憶體。這可能會導致像是忘記釋放物件和造成記憶體遺漏 (Memory Leak),或嘗試存取已經被釋放之物件的記憶體這類錯誤。

當您使用 Visual C++ 或其他適用於 Common Language Runtime 的程式語言來開發應用程式時,可以不使用 delete 運算子來釋放物件。當應用程式不再使用該物件時,記憶體回收行程會自動替您執行這個動作。

C++ 開發者可能已經習慣避免使用暫時性物件,因為以手動方式管理這類物件記憶體的代價實在太高了。對於在回收之間建立然後超過範圍的 Managed 暫時性物件,其記憶體配置和回收代價卻是非常的低。在 .NET Framework 中,記憶體回收行程實際上是針對具有短暫存留期 (Lifetime) 之 Manage 物件最佳化的。在開發 Managed 應用程式時,如果使用暫時性物件能夠簡化您的程式碼,那麼使用它們是很恰當的。

Visual Basic 開發人員

Visual Basic 開發人員比較習慣於自動記憶體管理。您所熟悉的程式設計方式可以適用於大部分您在 .NET Framework 中建立的 Managed 物件。不過,您應該特別留意當您建立或使用封裝 Unmanaged 資源的物件時,所要使用之 Dispose 方法的建議設計模式。

.NET Framework 可支援適用 Common Language Runtime 的程式語言一定會比這裡提到的還要多。不論您使用何種 Managed 語言,.NET Framework 的記憶體回收行程都會提供自動記憶體管理。它會替 Managed 物件配置和釋放記憶體,並且在必要時執行 Finalize 方法和解構函式以適當地清除 Unmanaged 資源。自動記憶體管理能夠藉由消除手動記憶體管理配置所引發的一般錯誤來簡化開發。

請參閱

概念

Finalize 方法和解構函式

其他資源

記憶體回收