關于C++編程中對象生命周期管理的論文
摘 要：在C++編程過程中，很容易出現內存泄露等安全問題，而導致這些問題的核心原因就是在于沒有管理好對象生命周期。本文主要對C++編程中對象生命周期管理的幾種方式進行分析并提出自己的見解。
關鍵詞：C++編程；對象；生命周期
C++編程中對象生命周期管理主要包括生成、使用和消除三個階段。對象不僅可以改變自己變量的狀態，而且還擁有使用創建它的那個類中方法的能力，對象通過使用這些方法可以產生一定的行為。一個對象的生命周期結束而對象卻沒被釋放，那么內存泄露問題肯定會產生，因此，做好對象生命周期管理工作非常重要。
1. 業務邏輯
從理論上講，應用程序中申請的內存一般都有其作用域，當對象已經完成其業務邏輯后，需要將其釋放，避免造成內存泄露（全局對象除外）。例如，視圖和文檔，當視圖對象已經完成其業務邏輯后，用戶關閉對應窗口時，需要將其進行釋放，而文檔對象可以在所有視圖對象釋放時釋放。因此，系統代碼就可以直接根據業務邏輯來編寫，這樣的代碼不僅效率高，而且容易理解。雖然采用這種方法直接編寫代碼有很多優勢，但是隨著需求的不斷增加，系統規模將會越來越大，也就越來越復雜，因此，上述那種簡單的方法不適用于復雜的系統。例如，在上面的例子中加一個關閉文檔的操作，使用這個命令時，將文檔直接關閉，可此時視圖也有可能是開著的，關閉文檔需要將視圖先關閉，在視圖對象釋放時進行文檔釋放，那么此時用戶關閉對應的窗口就變成了視圖對象的釋放條件。在一個復雜的系統中，一個對象要想釋放需要滿足很多條件才能實現，此時都是按照業務邏輯來判斷程序，出錯則不可避免。由此可知，用業務邏輯來管理對象生命周期的方式僅適用于簡單對象系統。因此，筆者認為使對象生命周期的管理更加合理和簡化，需要設計另一些機制。
2. 釋放通知
如果對文檔對象進行釋放，將其釋放通知發送給相關的視圖對象，其二者關系是非常密切的。如果視圖對象暫時不釋放，可以清除文檔對象的引用，如若視圖對象釋放了，其結果也不會發生任何變化。當創建好文檔和視圖后，引用是相互的，這里先從單項開始，視圖引用文檔：（1）文檔的指針被視圖獲得；（2）文檔的regFreeNotifiC++ation方法被視圖調用，文檔自己將會充當參數，文檔對象釋放的通知列表中將會把文檔自己加入其中，也就是說，文檔對象釋放時，將其釋放的通知，需要讓列表中的所有對象都能夠知道；（3）此時文檔對象的指針，不會有什么不穩定的現象產生，視圖對象就可以安安心心、大大方方的擁有；（4）如果文檔對象釋放了，將其通知給所有的列表對象，并且讓所有的對象進行調用，由于視圖剛才已經注冊過了，因此視圖也包括在內。對列表中對象的freeNotifiC++ation方法進行調用就是通知的方法，充分利用這個方法，在視圖的這個方法中，將文檔的引用清除掉；（5）如果先釋放的不是文檔對象，而是視圖對象，此時文檔對象中的unregFreeNotifiC++ation方法就要被執行，然后從列表中移除自己。
在Delphi語言的VC++L庫中同樣可采用這種方法。上述三個方法在VC++L的TC++omponent類上都被抽象了，只不過名稱不同而已，因此通過采用這種方法TC++omponent類及其子類的對象之間可以相互引用，并且能保證像野指針這類問題是不會出現的。這種方法雖然有這么多的優勢，但是其也具有一定的缺點，使其在使用時受到制約，例如，成本高、效率不高等。因此，這種方法在簡單、高等級對象中比較適合使用。抽象對象引用以及后續的釋放環節是釋放通知機制的最大意義，使這個機制和業務邏輯本身無關。這樣，無論業務邏輯多么復雜，開發人員只要嚴格遵守這個機制，都可以確保野指針問題不會出現，從而使開發人員的工作量大大減輕，并且開發效率更高、程序質量更好。
3. 引用計數
由上述分析可以看出，釋放通知雖然在生命周期管理中是一個很好的機制，但是也存在一些不足。例如，每個對象需要維護一個列表，可否不對列表進行維護，而對其進一步抽象呢？在上文中已經提出每個對象釋放時機都不同，而這些釋放時機的決定因素有很多，其中業務邏輯是最重要的，但是這個合理的釋放時機的確定是隨著業務邏輯的復雜性越來越復雜，已經不是由單一的條件來決定，而是由多個條件同時制約。因此，要想滿足釋放必須滿足所有的條件，解決這個問題的`關鍵在于判斷這些條件。針對對象釋放，只關心這個條件能夠滿足釋放要求，而對具體業務條件是什么不做重點考慮。因此，誕生了引用計數的機制，每一個對象由一個計數器，當加一時就說明釋放的條件并沒有滿足條件，當減一時就說明釋放條件已經滿足條件，如果計數器為0就說明所有的條件都滿足，對象可以釋放了。如果文檔被視圖引用的話，那么文檔的addRef方法被視圖調用，計數器增1；若文檔被引用的視圖釋放，則文檔的release方法就被視圖調用，同時計數器減1。當計數器為0時，文檔對象釋放。但是如果在這個過程中文檔被其他視圖使用，那么addRef方法也被那個視圖執行，這樣就不會將文檔對象釋放，繼續由那個視圖使用，如此循環，直到release方法被那個視圖使用為止。[0]
class BaseRefObject
{
public:
BaseRefObject():m_nRefCount(0)
{
}
void addRef()
{
++m_nRefCount;
}
void release()
{
if (0 == m_RefCount)
{
return;
}
else
{
--m_nRefCount;
this;
}
private:
int m_nRefCount;
}
這種方法優勢較明顯，其方式簡單、效率高，可以在大規模對象系統中使用，但是同時也存在一些不足，具體表現在以下幾個方面：（1）文檔對象的釋放都是被動的，影響其因素很多，尤其是外界因素，即使業務上要求文檔關閉，它也不會關閉，但是可以保持文檔的內容且把其作為一種標志來放置，從而表明其已經關閉。此時如果文檔的方法再被視圖調用的話，直接返回錯誤。另外，這個過程的完成還可以借助使用事件的機制輔助來進行，就是需要在關閉時，向視圖發送事件，讓它將引用解除，這個步驟又與釋放通知有些相似；（2）循環引用問題。上面的例子都只是假設文檔被視圖引用，而事實上視圖也可以被文檔引用。那么如果視圖被文檔引用的話，就會出現兩個對象相互引用，此時如果沒有外力作用，兩個對象的引用計數都不會變為0，于是內存泄漏現象就由此產生了，它的產生是任何開發者都不愿意看到的�？傊�，引用計數也是一種機制，在微軟的C++OM中這種機制經常被使用，它與業務邏輯沒有任何關系。
4. 垃圾回收
野指針不是NULL指針而是指向非法內存的指針，產生野指針的原因主要有：（1）沒有初始化指針變量。任何指針變量剛被創建時不會自動成為NULL指針，它的默認值是隨機的，它會亂指一氣。因此，指針變量初始化是要么將指針設置為NULL，要么讓它指向有效內存。（2）指針p被free或者之后沒有置為NULL，讓人誤認為p仍是一個有效的指針。（3）指針操作超越了變量的作用范圍。其實避免野指針發生的一個簡單方法就是對象不釋放，但是對象不釋放會導致另一個問題產生--內存泄露，一旦出現了野指針，程序就會被迫停止運行，而內存泄露則不會導致程序立刻停止，它等到沒有資源再消耗時才停止。因此，為了避免野指針的發生，可暫時不管內存泄露問題，等到出現資源不足時再想其他辦法（如資源不足時，找出那些垃圾，將這些垃圾對象釋放掉，將其內存給其他對象用），這是一個比較簡單的方法。查找垃圾所采用的算法如下：首先,假設所有的對象都是垃圾；其次，利用全局變量和局部變量找出非垃圾對象，也就是找出沒有被它們引用的對象；再次，再從第二步找出的非垃圾對象中找出不是垃圾的對象，其方法就是非垃圾對象引用的對象也不是垃圾；第四步，將第三步驟循環下去，直到沒有新的非垃圾對象產生為止；最后，剩下的就都是垃圾。
由此可以看出，這種算法是非常簡單的，但是在C++中，全局變量、局部變量和成員變量不全是對象，此時這個算法就有些不合適了，在JAVA等這些語言中都是對象，此時需要語言級的支撐。到目前為止，最好的內存管理機制也就是垃圾回收了，其避免野指針的產生是不需要人工來參與的，它也不會產生內存泄露等問題，其效率是非常高的，但是需要花費大量的成本。
結語
業務邏輯決定了對象的生命周期。事實上，業務邏輯是不斷變化的，朝著復雜的方向發展，此時具體到某個對象其釋放的條件可能比較復雜，因此，需要對這些對象的生命周期的管理需要引進一些專門的機制來進行，由此，釋放通知、引用計數、垃圾回收等機制就產生了。之所以產生如此多的機制，那是因為沒有一個機制能夠完全解決一切問題，每個機制都有優點和不足。筆者通過多年來的工作和學習發現，用的最多的是引用計數，但是在使用的同時，也經常會出現循環引用的問題。由此可見，最好的方法就是：將引用計數作為基礎，在合適的地方根據業務邏輯加入釋放通知（這里主要使用事件通知，其實事件本身是為了業務的需要而設計，并非是為了對象釋放，但從本質上講業務決定著對象的生命周期）。
生命周期管理中這些機制的引用的原因有很多，其中一個重要原因就是減少一些內存問題的發生，并且達到高效率、高質量的目標。內存泄露是普遍存在且必須解決的問題，而本文所提到的這些機制沒有一個能真正解決內存泄露問題。因此，現階段程序員對此問題進行更深入的研究，將業務邏輯和編程事務性工作同時抓，同等程度重視二者。
參考文獻：
. C++omputer Integrated ManufaC++turing Systems-C++IMS, 2004, (01).
【關于C++編程中對象生命周期管理的論文】相關文章：
2.面試中編程實例
5.C++中memset ,memcpy和strcpy的根本區別
7.C語言編程練習
8.C語言編程題
9.軟件編程簡歷范文