記憶體整理的原理 整理自CSDN

記憶體整理的原理 整理自CSDN

拓荒時代
國內的程式員大多是在 Java 語言中第一次感受到垃圾收集技術的巨大魅力的，許多人也因此把 Java 和垃圾收集看成了密不可分的整體。但事實上，垃圾收集技術早在 Java 語言問世前 30 多年就已經發展和成熟起來了， Java 語言所做的不過是把這項神奇的技術帶到了廣大程式員身邊而已。

如果一定要為垃圾收集技術找一個孿生兄弟，那麼， Lisp 語言才是當之無愧的人選。 1960 年前後誕生於 MIT 的 Lisp 語言是第一種高度依賴於動態記憶體分配技術的語言： Lisp 中幾乎所有資料都以“表”的形式出現，而“表”所佔用的空間則是在堆中動態分配得到的。 Lisp 語言先天就具有的動態記憶體管理特性要求 Lisp 語言的設計者必須解決堆中每一個記憶體塊的自動釋放問題（否則， Lisp 程式員就必然被程式中不計其數的 free 或 delete 語句淹沒），這直接導致了垃圾收集技術的誕生和發展——說句題外話，上大學時，一位老師曾告訴我們， Lisp 是對現代軟體開發技術貢獻最大的語言。我當時對這一說法不以為然：布滿了圓括弧，看上去像迷宮一樣的 Lisp 語言怎麼能比 C 語言或 Pascal 語言更偉大呢？不過現在，當我知道垃圾收集技術、資料結構技術、人工智慧技術、平行處理技術、虛擬機器技術、中繼資料技術以及程式員們耳熟能詳的許多技術都起源於 Lisp 語言時，我特別想向那位老師當面道歉，並收回我當時的幼稚想法。

知道了 Lisp 語言與垃圾收集的密切關係，我們就不難理解，為什麼垃圾收集技術的兩位先驅者 J. McCarthy 和 M. L. Minsky 同時也是 Lisp 語言發展史上的重要人物了。 J. McCarthy 是 Lisp 之父，他在發明 Lisp 語言的同時也第一次完整地描述了垃圾收集的演算法和實現方式； M. L. Minsky 則在發展 Lisp 語言的過程中成為了今天好幾種主流垃圾收集演算法的奠基人——和當時不少技術大師的經曆相似， J. McCarthy 和 M. L. Minsky 在許多不同的技術領域裡都取得了令人豔羨的成就。也許，在 1960 年代那個軟體開發史上的拓荒時代裡，思維敏捷、意志堅定的研究者更容易成為無所不能的西部硬漢吧。

在瞭解垃圾收集演算法的起源之前，有必要先回顧一下記憶體配置的主要方式。我們知道，大多數主流的語言或運行環境都支援三種最基本的記憶體配置方式，它們分別是：

一、靜態分配（ Static Allocation ）：靜態變數和全域變數的分配形式。我們可以把靜態分配的記憶體看成是家裡的耐用傢具。通常，它們無需釋放和回收，因為沒人會天天把大衣櫃當作垃圾扔到窗外。

二、自動分配（ Automatic Allocation ）：在棧中為局部變數分配記憶體的方法。棧中的記憶體可以隨著代碼塊退出時的出棧操作被自動釋放。這類似於到家中串門的訪客，天色一晚就要各回各家，除了個別不識時務者以外，我們一般沒必要把客人捆在垃圾袋裡掃地出門。

三、動態分配（ Dynamic Allocation ）：在堆中動態分配記憶體空間以儲存資料的方式。堆中的記憶體塊好像我們日常使用的餐巾紙，用過了就得扔到垃圾箱裡，否則屋內就會滿地狼藉。像我這樣的懶人做夢都想有一台家用機器人跟在身邊打掃衛生。在軟體開發中，如果你懶得釋放記憶體，那麼你也需要一台類似的機器人——這其實就是一個由特定演算法實現的垃圾收集器。

也就是說，下面提到的所有垃圾收集演算法都是在程式運行過程中收集並清理廢舊“餐巾紙”的演算法，它們的操作對象既不是靜態變數，也不是局部變數，而是堆中所有已指派記憶體塊。

引用計數（ Reference Counting ）演算法
1960 年以前，人們為胚胎中的 Lisp 語言設計垃圾收集機制時，第一個想到的演算法是引用計數演算法。拿餐巾紙的例子來說，這種演算法的原理大致可以描述為：

午餐時，為了把腦子裡突然跳出來的設計構想記下來，我從餐巾紙袋中抽出一張餐巾紙，打算在上面畫出系統架構的藍圖。按照“餐巾紙使用規約之引用計數版”的要求，畫圖之前，我必須先在餐巾紙的一角寫上計數值 1 ，以表示我在使用這張餐巾紙。這時，如果你也想看看我畫的藍圖，那你就要把餐巾紙上的計數值加 1 ，將它改為 2 ，這表明目前有 2 個人在同時使用這張餐巾紙（當然，我是不會允許你用這張餐巾紙來擦鼻涕的）。你看完後，必須把計數值減 1 ，表明你對該餐巾紙的使用已經結束。同樣，當我將餐巾紙上的內容全部謄寫到筆記本上之後，我也會自覺地把餐巾紙上的計數值減 1 。此時，不出意外的話，這張餐巾紙上的計數值應當是 0 ，它會被垃圾收集器——假設那是一個專門負責打掃衛生的機器人——撿起來扔到垃圾箱裡，因為垃圾收集器的惟一使命就是找到所有計數值為 0 的餐巾紙並清理它們。

引用計數演算法的優點和缺陷同樣明顯。這一演算法在執行垃圾收集任務時速度較快，但演算法對程式中每一次記憶體配置和指標操作提出了額外的要求（增加或減少記憶體塊的引用計數）。更重要的是，引用計數演算法無法正確釋放循環參考的記憶體塊，對此， D. Hillis 有一段風趣而精闢的論述：

一天，一個學生走到 Moon 面前說：“我知道如何設計一個更好的垃圾收集器了。我們必須記錄指向每個結點的指標數目。” Moon 耐心地給這位學生講了下面這個故事：“一天，一個學生走到 Moon 面前說：‘我知道如何設計一個更好的垃圾收集器了……’”

D. Hillis 的故事和我們小時候常說的“從前有座山，山上有個廟，廟裡有個老和尚”的故事有異曲同工之妙。這說明，單是使用引用計數演算法還不足以解決垃圾收集中的所有問題。正因為如此，引用計數演算法也常常被研究者們排除在狹義的垃圾收集演算法之外。當然，作為一種最簡單、最直觀的解決方案，引用計數演算法本身具有其不可替代的優越性。 1980 年代前後， D. P. Friedman ， D. S. Wise ， H. G. Baker 等人對引用計數演算法進行了數次改進，這些改進使得引用計數演算法及其變種（如延遲計數演算法等）在簡單的環境下，或是在一些綜合了多種演算法的現代垃圾收集系統中仍然可以一展身手。

標記－清除（ Mark-Sweep ）演算法
第一種實用和完善的垃圾收集演算法是 J. McCarthy 等人在 1960 年提出並成功地應用於 Lisp 語言的標記－清除演算法。仍以餐巾紙為例，標記－清除演算法的執行過程是這樣的：

午餐過程中，餐廳裡的所有人都根據自己的需要取用餐巾紙。當垃圾收集機器人想收集廢舊餐巾紙的時候，它會讓所有用餐的人先停下來，然後，依次詢問餐廳裡的每一個人：“你正在用餐巾紙嗎？你用的是哪一張餐巾紙？”機器人根據每個人的回答將人們正在使用的餐巾紙畫上記號。詢問過程結束後，機器人在餐廳裡尋找所有散落在餐桌上且沒有記號的餐巾紙（這些顯然都是用過的廢舊餐巾紙），把它們統統扔到垃圾箱裡。

正如其名稱所暗示的那樣，標記－清除演算法的執行過程分為“標記”和“清除”兩大階段。這種分步執行的思路奠定了現代垃圾收集演算法的思想基礎。與引用計數演算法不同的是，標記－清除演算法不需要運行環境監測每一次記憶體配置和指標操作，而只要在“標記”階段中跟蹤每一個指標變數的指向——用類似思路實現的垃圾收集器也常被後人統稱為跟蹤收集器（ Tracing Collector ）

伴隨著 Lisp 語言的成功，標記－清除演算法也在大多數早期的 Lisp 運行環境中大放異彩。儘管最初版本的標記－清除演算法在今天看來還存在效率不高（標記和清除是兩個相當耗時的過程）等諸多缺陷，但在後面的討論中，我們可以看到，幾乎所有現代垃圾收集演算法都是標記－清除思想的延續，僅此一點， J. McCarthy 等人在垃圾收集技術方面的貢獻就絲毫不亞於他們在 Lisp 語言上的成就了。

複製（ Copying ）演算法
為瞭解決標記－清除演算法在垃圾收集效率方面的缺陷， M. L. Minsky 於 1963 年發表了著名的論文“一種使用雙儲存區的 Lisp 語言垃圾收集器（ A LISP Garbage Collector Algorithm Using Serial Secondary Storage ）”。 M. L. Minsky 在該論文中描述的演算法被人們稱為複製演算法，它也被 M. L. Minsky 本人成功地引入到了 Lisp 語言的一個實現版本中。

複製演算法別出心裁地將堆空間一分為二，並使用簡單的複製操作來完成垃圾收集工作，這個思路相當有趣。借用餐巾紙的比喻，我們可以這樣理解 M. L. Minsky 的複製演算法：

餐廳被垃圾收集機器人分成南區和北區兩個大小完全相同的部分。午餐時，所有人都先在南區用餐（因為空白間有限，用餐人數自然也將減少一半），用餐時可以隨意使用餐巾紙。當垃圾收集機器人認為有必要回收廢舊餐巾紙時，它會要求所有用餐者以最快的速度從南區轉移到北區，同時隨身攜帶自己正在使用的餐巾紙。等所有人都轉移到北區之後，垃圾收集機器人只要簡單地把南區中所有散落的餐巾紙扔進垃圾箱就算完成任務了。下一次垃圾收集的工作過程也大致類似，惟一的不同只是人們的轉移方向變成了從北區到南區。如此迴圈往複，每次垃圾收集都只需簡單地轉移（也就是複製）一次，垃圾收集速度無與倫比——當然，對於用餐者往返奔波於南北兩區之間的辛勞，垃圾收集機器人是決不會流露出絲毫憐憫的。

M. L. Minsky 的發明絕對算得上一種奇思妙想。分區、複製的思路不僅大幅提高了垃圾收集的效率，而且也將原本繁紛複雜的記憶體配置演算法變得前所未有地簡明和扼要（既然每次記憶體回收都是對整個半區的回收，記憶體配置時也就不用考慮記憶體片段等複雜情況，只要移動堆頂指標，按順序分配記憶體就可以了），這簡直是個奇蹟！不過，任何奇蹟的出現都有一定的代價，在垃圾收集技術中，複製演算法提高效率的代價是人為地將可用記憶體縮小了一半。實話實說，這個代價未免也太高了一些。

無論優缺點如何，複製演算法在實踐中都獲得了可以與標記－清除演算法相比擬的成功。除了 M. L. Minsky 本人在 Lisp 語言中的工作以外，從 1960 年代末到 1970 年代初， R. R. Fenichel 和 J. C. Yochelson 等人也相繼在 Lisp 語言的不同實現中對複製演算法進行了改進， S. Arnborg 更是成功地將複製演算法應用到了 Simula 語言中。

至此，垃圾收集技術的三大傳統演算法——引用計數演算法、標記－清除演算法和複製演算法——都已在 1960 年前後相繼問世，三種演算法各有所長，也都存在致命的缺陷。從 1960 年代後期開始，研究者的主要精力逐漸轉向對這三種傳統演算法進行改進或整合，以揚長避短，適應程式設計語言和運行環境對垃圾收集的效率和即時性所提出的更高要求。

走向成熟
從 1970 年代開始，隨著科學研究和應用實踐的不斷深入，人們逐漸意識到，一個理想的垃圾收集器不應在運行時導致應用程式的暫停，不應額外佔用大量的記憶體空間和 CPU 資源，而三種傳統的垃圾收集演算法都無法滿足這些要求。人們必須提出更新的演算法或思路，以解決實踐中碰到的諸多難題。當時，研究者的努力目標包括：

第一，提高垃圾收集的效率。使用標記－清除演算法的垃圾收集器在工作時要消耗相當多的 CPU 資源。早期的 Lisp 運行環境收集記憶體垃圾的時間竟佔到了系統總已耗用時間的 40% ！——垃圾收集效率的低下直接造就了 Lisp 語言在執行速度方面的壞名聲；直到今天，許多人還條件反射似地誤以為所有 Lisp 程式都奇慢無比。

第二，減少垃圾收集時的記憶體佔用。這一問題主要出現在複製演算法中。儘管複製演算法在效率上獲得了質的突破，但犧牲一半記憶體空間的代價仍然是巨大的。在電腦發展的早期，在記憶體價格以 KB 計算的日子裡，浪費客戶的一半記憶體空間簡直就是在變相敲詐或攔路打劫。

第三，尋找即時的垃圾收集演算法。無論執行效率如何，三種傳統的垃圾收集演算法在執行垃圾收集任務時都必須打斷程式的當前工作。這種因垃圾收集而造成的延時是許多程式，特別是執行關鍵任務的程式沒有辦法容忍的。如何對傳統演算法進行改進，以便實現一種在後台悄悄執行，不影響——或至少看上去不影響——當前進程的即時垃圾收集器，這顯然是一件更具挑戰性的工作。

研究者們探尋未知領域的決心和研究工作的進展速度同樣令人驚奇：在 1970 年代到 1980 年代的短短十幾年中，一大批在實用系統中表現優異的新演算法和新思路脫穎而出。正是因為有了這些日趨成熟的垃圾收集演算法，今天的我們才能在 Java 或 .NET 提供的運行環境中隨心所欲地分配記憶體塊，而不必擔心空間釋放時的風險。

標記－整理（ Mark-Compact ）演算法
標記－整理演算法是標記－清除演算法和複製演算法的有機結合。把標記－清除演算法在記憶體佔用上的優點和複製演算法在執行效率上的特長綜合起來，這是所有人都希望看到的結果。不過，兩種垃圾收集演算法的整合并不像 1 加 1 等於 2 那樣簡單，我們必須引入一些全新的思路。 1970 年前後， G. L. Steele ， C. J. Cheney 和 D. S. Wise 等研究者陸續找到了正確的方向，標記－整理演算法的輪廓也逐漸清晰了起來：

在我們熟悉的餐廳裡，這一次，垃圾收集機器人不再把餐廳分成兩個南北地區了。需要執行垃圾收集任務時，機器人先執行標記－清除演算法的第一個步驟，為所有使用中的餐巾紙畫好標記，然後，機器人命令所有就餐者帶上有標記的餐巾紙向餐廳的南面集中，同時把沒有標記的廢舊餐巾紙扔向餐廳北面。這樣一來，機器人只消站在餐廳北面，懷抱垃圾箱，迎接撲面而來的廢舊餐巾紙就行了。

實驗表明，標記－整理演算法的總體執行效率高於標記－清除演算法，又不像複製演算法那樣需要犧牲一半的儲存空間，這顯然是一種非常理想的結果。在許多現代的垃圾收集器中，人們都使用了標記－整理演算法或其改進版本。

增量收集（ Incremental Collecting ）演算法
對即時垃圾收集演算法的研究直接導致了增量收集演算法的誕生。

最初，人們關於即時垃圾收集的想法是這樣的：為了進行即時的垃圾收集，可以設計一個多進程的運行環境，比如用一個進程執行垃圾收集工作，另一個進程執行程式代碼。這樣一來，垃圾收集工作看上去就彷彿是在後台悄悄完成的，不會打斷程式碼的運行。

在收集餐巾紙的例子中，這一思路可以被理解為：垃圾收集機器人在人們用餐的同時尋找廢棄的餐巾紙並將它們扔到垃圾箱裡。這個看似簡單的思路會在設計和實現時碰上進程間衝突的難題。比如說，如果垃圾收集進程包括標記和清除兩個工作階段，那麼，垃圾收集器在第一階段中辛辛苦苦標記出的結果很可能被另一個進程中的記憶體作業碼修改得面目全非，以至於第二階段的工作沒有辦法開展。

M. L. Minsky 和 D. E. Knuth 對即時垃圾收集過程中的技術痛點進行了早期的研究， G. L. Steele 於 1975 年發表了題為“多進程整理的垃圾收集（ Multiprocessing compactifying garbage collection ）”的論文，描述了一種被後人稱為“ Minsky-Knuth-Steele 演算法”的即時垃圾收集演算法。 E. W. Dijkstra ， L. Lamport ， R. R. Fenichel 和 J. C. Yochelson 等人也相繼在此領域做出了各自的貢獻。 1978 年， H. G. Baker 發表了“串列電腦上的即時表處理技術（ List Processing in Real Time on a Serial Computer ）”一文，系統闡述了多進程環境下用於垃圾收集的增量收集演算法。

增量收集演算法的基礎仍是傳統的標記－清除和複製演算法。增量收集演算法通過對進程間衝突的妥善處理，允許垃圾收集進程以分階段的方式完成標記、清理或複製工作。詳細分析各種增量收集演算法的內部機理是一件相當繁瑣的事情，在這裡，讀者們需要瞭解的僅僅是： H. G. Baker 等人的努力已經將即時垃圾收集的夢想變成了現實，我們再也不用為垃圾收集打斷程式的運行而煩惱了。

分代收集（ Generational Collecting ）演算法
和大多數軟體開發技術一樣，統計學原理總能在技術發展的過程中起到強力催化劑的作用。 1980 年前後，善於在研究中使用統計分析知識的技術人員發現，大多數記憶體塊的生存周期都比較短，垃圾收集器應當把更多的精力放在檢查和清理新分配的記憶體塊上。這個發現對於垃圾收集技術的價值可以用餐巾紙的例子概括如下：

如果垃圾收集機器人足夠聰明，事先摸清了餐廳裡每個人在用餐時使用餐巾紙的習慣——比如有些人喜歡在用餐前後各用掉一張餐巾紙，有的人喜歡自始至終攥著一張餐巾紙不放，有的人則每打一個噴嚏就用去一張餐巾紙——機器人就可以制定出更完善的餐巾紙回收計劃，並總是在人們剛扔掉餐巾紙沒多久就把垃圾撿走。這種基於統計學原理的做法當然可以讓餐廳的整潔度成倍提高。

D. E. Knuth ， T. Knight ， G. Sussman 和 R. Stallman 等人對記憶體垃圾的分類處理做了最早的研究。 1983 年， H. Lieberman 和 C. Hewitt 發表了題為“基於對象壽命的一種即時垃圾收集器（ A real-time garbage collector based on the lifetimes of objects ）”的論文。這篇著名的論文標誌著分代收集演算法的正式誕生。此後，在 H. G. Baker ， R. L. Hudson ， J. E. B. Moss 等人的共同努力下，分代收集演算法逐漸成為了垃圾收集領域裡的主流技術。

分代收集演算法通常將堆中的記憶體塊按壽命分為兩類，年老的和年輕的。垃圾收集器使用不同的收集演算法或收集策略，分別處理這兩類記憶體塊，並特別地把主要工作時間花在處理年輕的記憶體塊上。分代收集演算法使垃圾收集器在有限的資源條件下，可以更為有效地工作——這種效率上的提高在今天的 JAVA 虛擬機器中得到了最好的證明。

應用浪潮
Lisp 是垃圾收集技術的第一個受益者，但顯然不是最後一個。在 Lisp 語言之後，許許多多傳統的、現代的、後現代的語言已經把垃圾收集技術拉入了自己的懷抱。隨便舉幾個例子吧：誕生於 1964 年的 Simula 語言， 1969 年的 Smalltalk 語言， 1970 年的 Prolog 語言， 1973 年的 ML 語言， 1975 年的 Scheme 語言， 1983 年的 Modula-3 語言， 1986 年的 Eiffel 語言， 1987 年的 Haskell 語言……它們都先後使用了自動垃圾收集技術。當然，每一種語言使用的垃圾收集演算法可能不盡相同，大多數語言和運行環境甚至同時使用了多種垃圾收集演算法。但無論怎樣，這些執行個體都說明，垃圾收集技術從誕生的那一天起就不是一種曲高和寡的“學院派”技術。

對於我們熟悉的 C 和 C++ 語言，垃圾收集技術一樣可以發揮巨大的功效。正如我們在學校中就已經知道的那樣， C 和 C++ 語言本身並沒有提供垃圾收集機制，但這並不妨礙我們在程式中使用具有垃圾收集功能的函數庫或類庫。例如，早在 1988 年， H. J. Boehm 和 A. J. Demers 就成功地實現了一種使用保守垃圾收集演算法（ Conservative GC Algorithmic ）的函數庫（參見 http://www.hpl.hp.com/personal/Hans_Boehm/gc ）。我們可以在 C 語言或 C++ 語言中使用該函數庫完成自動垃圾收集功能，必要時，甚至還可以讓傳統的 C/C++ 代碼與使用自動垃圾收集功能的 C/C++ 代碼在一個程式裡協同工作。

1995 年誕生的 Java 語言在一夜之間將垃圾收集技術變成了軟體開發領域裡最為流行的技術之一。從某種角度說，我們很難分清究竟是 Java 從垃圾收集中受益，還是垃圾收集技術本身借 Java 的普及而揚名。值得注意的是，不同版本的 JAVA 虛擬機器使用的垃圾收集機制並不完全相同， JAVA 虛擬機器其實也經過了一個從簡單到複雜的發展過程。在 JAVA 虛擬機器的 1.4.1 版中，人們可以體驗到的垃圾收集演算法就包括分代收集、複製收集、增量收集、標記－整理、並行複製（ Parallel Copying ）、並行清除（ Parallel Scavenging ）、並發（ Concurrent ）收集等許多種， Java 程式運行速度的不斷提升在很大程度上應該歸功於垃圾收集技術的發展與完善。

儘管曆史上已經有許多包含垃圾收集技術的應用平台和作業系統出現，但 Microsoft .NET 卻是第一種真正實用化的、包含了垃圾收集機制的通用語言運行環境。事實上， .NET 平台上的所有語言，包括 C# 、 Visual Basic .NET 、 Visual C++ .NET 、 J# 等等，都可以通過幾乎完全相同的方式使用 .NET 平台提供的垃圾收集機制。我們似乎可以斷言， .NET 是垃圾收集技術在應用領域裡的一次重大變革，它使垃圾收集技術從一種單純的技術變成了應用環境乃至作業系統中的一種內在文化。這種變革對未來軟體開發技術的影響力也許要遠遠超過 .NET 平台本身的商業價值。

大勢所趨
今天，致力於垃圾收集技術研究的人們仍在不懈努力，他們的研究方向包括分布式系統的垃圾收集、複雜事務環境下的垃圾收集、資料庫等特定系統的垃圾收集等等。

但在程式員中間，仍有不少人對垃圾收集技術不屑一顧，他們寧願相信自己逐行編寫的 free 或 delete 命令，也不願把垃圾收集的重任交給那些在他們看來既蠢又笨的垃圾收集器。

我個人認為，垃圾收集技術的普及是大勢所趨，這就像生活會越來越好一樣毋庸置疑。今天的程式員也許會因為垃圾收集器要佔用一定的 CPU 資源而對其望而卻步，但二十多年前的程式員還曾因為進階語言速度太慢而堅持用機器語言寫程式呢！在硬體速度日新月異的今天，我們是要吝惜那一點兒時間損耗而踟躇不前，還是該堅定不移地站在代碼和運行環境的淨化劑——垃圾收集的一邊呢？

http://www.contextfree.net/wangyg/b/tech_his/gc_history.html
--------------------------------------------------------------------------------------------------

PS:最佳化大師的記憶體整理
Windows系統的記憶體管理並不總是十分有效。許多使用者在剛啟動系統時，覺得Windows的運行速度蠻快速的，可是過了一陣以後（例如，玩了一會兒大型的3D電子遊戲退出後）就覺得整個系統的運行速度明顯下降了。這是怎麼回事呢？原來，由於實體記憶體總有上限,所以Windows系統採用了虛擬記憶體分頁映射的機制管理記憶體，也就是分頁系統通過分配部分硬碟作為附加記憶體。當被稱為頁的小塊記憶體不再使用時，可以將它們存放到磁碟上去，以便騰出更多的實體記憶體空間。當Windows9x啟動時，作業系統就要佔掉差不多20多M實體記憶體，一旦運行別的程式，Windows就會不斷在實體記憶體和虛擬記憶體之間交換記憶體頁。NT可以使用多達64KB的頁，但是Intel的CPU強制使用4KB的頁。系統已耗用時間一長，記憶體中的頁面片段將越來越多，這就是系統運行速度下降的原因。
針對Windows作業系統記憶體管理的缺陷，Windows最佳化大師提供了記憶體整理功能。它適用於Windows9x/2000/XP/2003作業系統，能夠在不影響系統速度的情況下有效釋放記憶體。在使用過程中，建議使用者先進入Wopti 記憶體整理的設定介面，單擊“推薦”後，選擇“儲存”返回軟體主介面，這樣將使Wopti 記憶體整理工作在最有效狀態。同時建議使用者在運行大型遊戲軟體時不要啟動記憶體整理，大一點的遊戲可能要吃掉大量的實體記憶體（通常都是100%），因此這時候整理和釋放記憶體可能會降低遊戲的速度。
深度整理：Windows最佳化大師記憶體整理模組提供的深度整理與大多數記憶體釋放軟體一樣，通過將實體記憶體中的內容移動到硬碟分頁檔的虛擬記憶體中，從而為將要啟動並執行應用程式提供更充裕的實體記憶體。深度整理能釋放出最多的實體記憶體，但弊端也是明顯的，由於不分青紅皂白將實體記憶體進行強行遷移，導致使用者正在啟動並執行應用程式被迫重新進行實體記憶體與虛擬記憶體的資料交換，反而造成系統總體效能的下降。
深度整理過程中CPU佔用率相對較低，並且整理過程中，使用者可以點擊“中止”按鈕來中斷記憶體深度整理釋放操作。
快速釋放：針對深度整理的弊端，Windows最佳化大師記憶體整理模組為WindowsNT/2000/XP/2003使用者提供了更為先進且獨具特色的快速釋放功能。它能在完全不影響系統速度的情況下，快速釋放出實體記憶體。使用者同時啟動並執行應用程式越多，則效果越顯著。快速整理後，應用程式的運行速度不僅不會降低，反而因為記憶體安排更合理，速度會有所提高。先進的快速釋放演算法，不僅使快速釋放速度極快（經測試，大多數情況下小於0.5秒即可完成），同時CPU佔用率極低（經測試，大多數情況下整理過程中CPU佔用率不超過5%）。快速釋放雖然能夠釋放的記憶體空間較深度整理少一些，但由於每一段被釋放的記憶體均經過精確計算，故效果更顯著，建議Windows2000/XP/2003使用者使用快速釋放而擯棄深度整理。
在Wopti 記憶體整理的設定選項中使用者可以自己調整要整理的記憶體地區(單位：MB)，調整範圍的最大值就是系統的實際實體記憶體大小。通常情況下，使用者應該將要整理的記憶體地區設定為最大，以便儘可能多的釋放實體記憶體。如果使用者在整理釋放記憶體後，依然覺得可用記憶體較小，也可以多整理兩次，不過能夠釋放的實體記憶體也有一個限度，例如，在一台的PIII733 256M記憶體的系統中最多也只能釋放91%的實體記憶體。
Wopti 記憶體整理還可以設定為根據可用實體記憶體的百分比來定時自動整理和釋放記憶體。建議使用者在選擇百分比大小時根據自己主要啟動並執行應用程式來進行設定。例如，如果主要啟動並執行程式是瀏覽器，可以將百分比調整為20%；而如果主要工作是文文書處理，則可以加大為25%。注意：選擇自動整理時，必須將Wopti 記憶體整理軟體駐留記憶體。方法為：單擊“確定”或者視窗右上的最小化按鈕，將Wopti 記憶體整理縮小為控制台表徵圖即可。
使用者還可以根據CPU使用率設定當CPU使用率超過一定限度時不整理釋放記憶體片段。
整理記憶體時自動清空Windows剪貼簿內容。選中此選項將在整理記憶體以前清空使用者的剪貼簿內容，如果您的剪貼簿中的內容已經不需要了，建議選擇此選項以便釋放更多的記憶體空間。
啟動Windows時自動運行Wopti 記憶體整理。如果使用者希望Wopti 記憶體整理自動整理釋放記憶體，可以讓它與Windows同時啟動。
每次啟動時自動縮小為工作列表徵圖。建議選擇了啟動Windows時自動運行Wopti 記憶體整理的使用者選擇此項。
運行時在狀態列顯示動態表徵圖。使用者可以根據自己的需求分別在工作列動態表徵圖為可用實體記憶體百分比、CPU佔用率、可用交換區百分比、可用虛擬記憶體百分比等。

Wopti 記憶體整理還向Windows2000/XP/2003使用者提供了進階設定選項，使用者可在此設定：
(1)、快速釋放和回收所有進程的記憶體片段。推薦選擇。
(2)、快速釋放和回收時，排除指定進程的記憶體地區。請點擊該項尾部的表徵圖添加需排除的進程。
(3)、僅快速釋放和回收指定進程的記憶體地區。請點擊該項尾部的表徵圖添加需排除的進程。

注1：重複進行記憶體深度整理雖然使用者將獲得最大的實體記憶體，卻會降低系統速度。因此，不建議連續多次深度整理記憶體。
注2：重複進行記憶體快速釋放使用者也有可能獲得更多的實體記憶體，但相對深度整理已相當有限。
注3：深度整理前，Wopti 記憶體整理會自動監測並分析當前系統是否有能力完成記憶體片段釋放，若不具備此條件則不允許整理操作。例如：當使用者的交換區即將耗盡時是不允許記憶體磁碟重組的。

 

本文來自CSDN部落格，轉載請標明出處：http://blog.csdn.net/zdl1016/archive/2009/11/11/4800329.aspx