什麼方法可以管理內存資源

1. 手機內存不足怎麼清理 快速清理手機內存的方法

手機內存不足怎樣清理最徹底
1、刪除不常用的軟體系統工具—設置—應用卸載，把不常用的軟體都刪了，因為現在有一些小程序，完全可以代替這些APP啦。2、清簡猛理手機垃圾系統工具—文件帆咐碧管理—清理，把應用緩存、垃圾文件、安裝包、卸載殘留、內存佔用這些全部清理掉3、逐一清理APP緩存這里估計有人就問學姐了，學姐呀，你上面說的清理緩存，為什麼這里還要清理緩存呢，是不是重復了？不是的，上面只是手機整體掃描緩存，整體掃描能清理百分之30就不錯了，剩下的需要手動一點點清理。系統工具—設置—應用管理，然後手動點開每個應用，學姐先點開微信，因為微信最占內存。這里重點來了，可執行的有兩個選項，一個是清除緩存，另外一個是清除全部數據。清除緩存，清理的垃圾不會太多，不夠徹底。清除全部數據，你的微信聊天產生的所有的文字，圖片，視頻，文件等資料都會被清理滑頃干凈，然後微信需要重新登錄。如果微信沒有重要的資料，或者備份完畢後，學姐建議大家可以這么清理，這樣清理非常徹底！4、刪除手機文件夾這信納陸招是學姐的大招！很多朋友估計都沒有用過，也不敢嘗試。學姐用了好幾年，沒有出現啥問題。系統工具—文件管理—文件夾，這時候你會看到有很多文件夾，都是英文名字，但是這裡面有一個文件夾的名字很特別，那就是tencent騰訊，這個文件夾。學姐建議這個文件夾別刪，其他都可以刪，為什麼呢？因為這個刪完，你的微信所有聊天記錄都沒有了。所以這是學姐的大招，這么做，會給很多垃茄畝圾清理干凈，但是前提，你的相冊，視頻需要備份哈。5、手機清理軟體再全盤清理以上學姐說的是手動清理方法，其實清理軟體有很多，學姐推薦的是騰訊手機管家，為什麼是這個呢？因為騰訊手機管家清理微信垃圾非常方便哈。在騰訊手機管家，點清理加速，然後點微信清理，下方還有微信深度清理，這樣能釋放很多微信存儲空間的緩存。6、手機恢復出廠設置學姐很自信得告訴你，上面這些方法你都用完了，發現肯定是不卡了。如果手機再卡，那學態舉姐還有個更牛的大招！那就是給手機恢復到出廠設置。方法是關閉手機，再重啟手機，重啟手機的同時按住音量+和電源鍵，這樣系統就進入recovery模式了，點wipe data/factory reset就可以清除所有數據了，這樣一部嶄新的新手機即將誕生！如果你手機恢復出廠後還是卡，那麼學姐告訴你，朋友，你該換手機了！
還有個重要的事，學姐提醒大家，大家在清理手機過程中，如果圖片或者視頻等數據被誤刪了，那就用數據恢洞高復軟體及時找回，這樣的軟體有很多，下載直接安裝應用缺脊即可伏顫滲。

手機內存不足怎樣清理最徹底
1、刪除不常用的軟體系統工具—設置—應用卸載，把不常用的軟體都刪了，因為現在有一些小程序，完全可以代替這些APP啦。2、清簡猛理手機垃圾系統工具—文件帆咐碧管理—清理，把應用緩存、垃圾文件、安裝包、卸載殘留、內存佔用這些全部清理掉3、逐一清理APP緩存這里估計有人就問學姐了，學姐呀，你上面說的清理緩存，為什麼這里還要清理緩存呢，是不是重復了？不是的，上面只是手機整體掃描緩存，整體掃描能清理百分之30就不錯了，剩下的需要手動一點點清理。系統工具—設置—應用管理，然後手動點開每個應用，學姐先點開微信，因為微信最占內存。這里重點來了，可執行的有兩個選項，一個是清除緩存，另外一個是清除全部數據。清除緩存，清理的垃圾不會太多，不夠徹底。清除全部數據，你的微信聊天產生的所有的文字，圖片，視頻，文件等資料都會被清理干凈，然後微信需要重新登錄。如果微信沒有重要的資料，或者備份完畢後，學姐建議大家可以這么清理，這樣清理非常徹底！4、刪除手機文件夾這招是學姐的大招！很多朋友估計都沒有用過，也不敢嘗試。學姐用了好幾年，沒有出現啥問題。系統工具—文件管理—文件夾，這時候你會看到有很多文件夾，都是英文名字，但是這裡面有一個文件夾的名字很特別，那就是tencent騰訊，這個文件夾。學姐建議這個文件夾別刪，其他都可以刪，為什麼呢？因為這個刪完，你的微信所有聊天記錄都沒有了。所以這是學姐的大招，這么做，會給很多垃圾清理干凈，但是前提，你的相冊，視頻需要備份哈。5、手機清理軟體再全盤清理以上學姐說的是手動清理方法，其實清理軟體有很多，學姐推薦的是騰訊手機管家，為什麼是這個呢？因為騰訊手機管家清理微信垃圾非常方便哈。在騰訊手機管家，點清理加速，然後點微信清理，下方還有微信深度清理，這樣能釋放很多微信存儲空間的緩存。6、手機恢復出廠設置學姐很自信得告訴你，上面這些方法你都用完了，發現肯定是不卡了。如果手機再卡，那學態舉姐還有個更牛的大招！那就是給手機恢復到出廠設置。方法是關閉手機，再重啟手機，重啟手機的同時按住音量+和電源鍵，這樣系統就進入recovery模式了，點wipe data/factory reset就可以清除所有數據了，這樣一部嶄新的新手機即將誕生！如果你手機恢復出廠後還是卡，那麼學姐告訴你，朋友，你該換手機了！
還有個重要的事，學姐提醒大家，大家在清理手機過程中，如果圖片或者視頻等數據被誤刪了，那就用數據恢洞高復軟體及時找回，這樣的軟體有很多，下載直接安裝應用缺脊即可伏顫滲。

• 如果我的回答可以幫到您，請您採納哦！

2. 內存不足怎麼辦

清理電腦垃圾，或者更換硬碟。
電腦硬碟是計算機最主要的存儲設備。硬碟由一個或者多個鋁制或者玻璃制的碟片組成。這些碟片外覆蓋有鐵磁性材料。
絕大多數硬碟都是固定硬碟，被永久性地密封固定在硬碟驅動器中。硬碟是非常害怕灰塵的了。如果灰塵吸到了電路板上的話，就會導致硬碟工作不穩定，或者導致內部零件損壞。
硬碟的功能工作狀態與壽命和溫度有很大的關系，溫度過高或是過低都會導致晶體振盪器的時鍾主頻發生改變，會造成電路元件失靈，而如果溫度過低時會導致，空氣中水分凝結在元件上，導致短路的現象。
其次，我們要定期整理你的硬碟。這樣會提高你的硬碟速度。如果，硬碟上的垃圾文件過多的話，速度會減慢，還有可能損壞磁軌。但是，不要三天兩頭的清理，這樣也會減少硬碟壽命的。
最後，就是防毒。病毒在硬碟的存儲的文件是一個最大的威脅。所也我們發現病毒應該及時採取辦法清除，盡量不要格式化硬碟。

3. 內存有幾種管理方式

3種 ：
段式管理（每次分配的大小不固定）
頁式管理（每次分配的大小固定）
段頁式（整體分段，段內分頁，和整體分頁，頁內分段）

頁式管理：把主存分為一頁一頁的，每一頁的空間要比一塊一塊的空間小很多，顯然這種方法的空間利用率要比塊式管理高很多。

段式管理：把主存分為一段一段的，每一段的空間又要比一頁一頁的空間小很多，這種方法在空間利用率上又比頁式管理高很多，但是也有另外一個缺點。一個程序片斷可能會被分為幾十段，這樣很多時間就會被浪費在計算每一段的物理地址上（計算機最耗時間的大家都知道是I/O吧）。

段頁式管理：結合了段式管理和頁式管理的優點。把主存分為若干頁，每一頁又分為若干段。

4. 電腦內存不足怎麼辦

擴大虛擬內存，磁碟清理，設置內存比例。
電腦提示內存不足，那肯定就是內存不足了，如果提示英文的話，可能會有部分用戶還不知道什麼意思呢，只會見到一個大大的感嘆號，還會有一聲「咚」的聲音。顧名思義內存不足，就是內存不足，電腦也有內存，就像我歲並森們使用乎畝的手機，RAM就是內存，RAM越大手機運行的越流暢，同理可證，電腦的RAM越大，肯定也是越好的。
電腦每次打開應用，都需要佔用內存，不然怎麼應用運行呢?有的用戶經常吐槽，電腦沒用多久變卡了，點一下管家就流暢了，這是很正常的，電腦變卡的原因主要還是因為內存越來越少，當然會變卡了，只需要清理一內存就可以了。
也就是把後台運行的程序關閉即可，所以遇到這種情況只需要選中任務欄，點擊滑鼠右鍵，啟動任務管理器，將佔用大量內存的應用全部停止運行就可以了，內存不足的蔽銷問題就解決了。

5. 計算機管理內存的方法有哪些優缺點是什麼

內存管理是操作系統最重要的一部分，它決定了操作系統的性能。為了說明如何進行內存訪問的操作，有必要先介紹有關內存管理的一些術語及背景。

2.1 虛擬內存

所謂虛擬內存就是用硬碟空間來彌補計算機物理內存不足的技術。Windows操作系統用虛擬內存來動態管理運行時的交換文件。為了提供比實際物理內存還多的內存容量，Windows操作系統佔用了硬碟上的一部分空間作為虛擬內存。當CPU有要求時，首先會讀取內存中的資料。當內存容量不夠用時，Windows就會將需要暫時存儲的數據寫入硬碟。所以，計算機的內存大小等於實際物理內存容量加上「分頁文件」（就是交換文件）的大小。Windows 98中分頁文件名採用Win386.swp形式，而Windows 2K/XP/2003中採用pagefile.sys，默認位於系統分區的根目錄下，具有隱藏屬性。如果需要的話，「分頁文件」會動用硬碟上所有可以使用的空間。

安裝好Windows以後，系統採用默認的設置自動處理虛擬內存，為了優化系統的 工作性能，根據Windows操作系統中虛擬內存的設置方法，可以自己動手設置內存管理參數。

2.2 CPU工作模式

計算機系統有不同的工作模式，在不同的模式下，CPU的定址方式是不一樣的，通常見到的CPU工作模式如下所述。

2.2.1．實模式

實模式是為了Pentium處理器與8086／8088兼容而設置的。8086和8088隻能工作於實模式，而80286及以上的處理器可工作於實模式或者保護模式下。實模式操作方式只允許微處理器定址第一個1MB的存儲空間，從0x00000～0xFFFFF。在實模式下的存儲器定址是段地址＋偏移地址。例如段寄存器的內容是0x1000，則它定址開始於0x10000的段，偏移量大小從0x0000～0xFFFF，即偏移量的空間大小是216=64KB。

2.2.2．保護地址模式

保護地址模式又稱為虛擬地址存儲管理方式。保護模式下主要有兩種特徵。
（1）內存分段管理
在保護模式下，各個16位的段寄存器裡面放置的是選擇符。各項任務共享的內存空間由全局選擇符來索引；而某個任務獨立使用的內存空間由局部選擇符來索引。由選擇符的高13位作為偏移量，再以CPU內部事先初始化好的GDTR（全局描述符表寄存器）中的32位基地址為基，可以獲得相應的描述符。由描述符中的線性地址決定段的基地址。再利用指令（或其他方式）給出的偏移量，便可以得到線性地址，即
線性地址=段線性基地址+偏移量
保護模式採用上面介紹的分段管理，可以實現的存儲器定址范圍為4GB，通常把通過段變換獲得的地址稱為線性地址。這種線性地址是同32位物理地址對應的，為了獲得更大的定址范圍，還可以對線性地址實行分頁管理。在保護模式下，處理器通過CRO控制寄存器的PG（page）位進行管理，當PG=0時，由段變換獲得的線性地址可直接作為物理地址使用；若PG=1，則進一步進行頁變換。
（2）內存分頁管理

分頁管理的基本思想是將內存分為大小固定為4KB或者1MB的若干頁，通過一定機制對內存進行管理。與前面的分段管理類似，程序或數據將根據其長度分配若干頁。為了進行頁面管理，在分頁管理機制中採用了頁表、頁目錄對線性地址作頁變換。

2.3 邏輯、線性和物理地址

在保護地址模式下，經常遇到三種地址：邏輯地址（Logical Address）、線性地址（Linear Address）和物理地址（Physical Address）。CPU通過分段機制將邏輯地址轉換為線性地址，再通過分頁機制將線性地址轉換為物理地址。
（1）邏輯地址
這是內存地址的精確描述，通常表示為十六進制：xxxx:YYYYYYYY，這里xxxx為selector（選擇器），而YYYYYYYY是針對selector所選擇的段地址的線性偏移量。除了指定xxxx的具體數值外，還可使用具體的段寄存器的名字來替代，如CS（代碼段），DS（數據段），ES（擴展段），FS（附加數據段#1），GS（附加數據段#2）和SS（堆棧段）。這些符號都來自舊的「段：偏移量」風格，在 8086 實模式下使用此種方式來指定「far pointers」（遠指針）。
（2）線性地址
線性地址是邏輯地址到物理地址變換之間的中間層，是處理器可定址的內存空間（稱為線性地址空間）中的地址。程序代碼會產生邏輯地址，或者說是段中的偏移地址，加上相應段的基地址就生成了一個線性地址。
如果啟用了分頁機制，那麼線性地址可以再經變換以產生一個物理地址。若沒有啟用分頁機制，那麼線性地址直接就是物理地址。不過，在開啟分頁功能之後，一個線性地址可能沒有相對映的物理地址，因為它所對應的內存可能被交換到硬碟中。32位線性地址可用於定位4GB存儲單元。
（3）物理地址

所謂物理地址，就是指系統內存的真正地址。對於32 位的操作系統，它的范圍為0x00000000～0xFFFFFFFF，共有4GB。只有當CPU工作於分頁模式時，此種類型的地址才會變得非常「有趣」。本質上，一個物理地址是CPU插腳上可測量的電壓。操作系統通過設立頁表將線性地址映射為物理地址。Windows 2K/XP所用頁表布局的某些屬性對於調試軟體開發人員非常有用。

2.4 存儲器分頁管理機制

程序代碼和數據必須駐留在內存中才能得以運行，然而系統內存量很有限，往往不能容納一個完整程序的所有代碼和數據，特別是在多任務系統中，如Windows，可能需要同時打開多個執行程序，如畫圖程序，瀏覽器等，想讓內存駐留所有這些程序顯然不大可能，因此首先能想到的就是將程序分割成小部分，只讓當前系統運行它所有需要的那部分留在內存，其他部分都留在硬碟（虛擬內存）。當系統處理完當前任務片段後，再從外存中調入下一個待運行的任務片段。於是，存儲器分頁管理機制隨之而被發明。
如前所述，在保護模式下，控制寄存器CR0中的最高位PG位控制分頁管理機制是否生效。如果PG=1，分頁機制生效，把線性地址轉換為物理地址。如果PG=0，分頁機制無效，線性地址就直接作為物理地址。必須注意，只有在保護方式下分頁機制才可能生效。只有在保證使PE位為1的前提下，才能夠使PG位為1，否則將引起通用保護 故障。

分頁機制把線性地址空間和物理地址空間分別劃分為大小相同的塊。這樣的塊稱為頁。通過在線性地址空間的頁與物理地址空間的頁之間建立映射，分頁機制可以實現線性地址到物理地址的轉換。線性地址空間的頁與物理地址空間的頁之間的映射可根據需要來確定。線性地址空間的任何一頁，可以映射為物理地址空間中的任何一頁。

2.5 線性地址到物理地址的轉換

線性地址空間的頁到物理地址空間的頁之間的映射用表來描述。目前所見到的有4KB和1MB大小的物理分頁，對於4KB頁面的分頁，線性地址到物理地址的轉換過程如圖所示。對於1MB頁面分頁，線性地址到物理地址的轉換與4KB的基本相似，不同的是線性地址的低22位對應一個物理頁面。

對於4KB頁面的線性地址到物理地址的轉換示意圖

對於4KB頁面分頁，頁映射表的第一級稱為頁目錄表，存儲在一個物理頁中。頁目錄表共有1024個頁目錄項（PDE，page directory entry），其中，每個PDE為4位元組長，包含對應第二級表所在物理地址空間頁的頁碼。頁映射表的第二級稱為頁表，每張頁表也被存儲在一個物理頁中。每張頁表有1024個頁表項（PTE，page table entry），每個PTE為4位元組長，其中PTE的低12位用來存放諸如「頁是否存在於內存」或「頁的許可權」等信息。

一個線性地址大小為4個位元組（32bit），包含著找到物理地址的信息，分為3個部分：第22位到第31位這10位（最高10位）是頁目錄中的索引，第12位到第21位這10位是頁表中的索引，第0位到第11位這12位（低12位）是頁內偏移。在把一個線性地址轉換成物理地址時，CPU首先根據CR3中的值，找到頁目錄所在的物理頁。然後根據線性地址的第22位到第31位這10位（最高的10bit）的值作為索引，找到相應的PDE，其中含有這個虛擬地址所對應頁表的物理地址。有了頁表的物理地址，再把虛擬地址的第12位到第21位這10位的值作為索引，找到該頁表中相應的PTE，其中就有這個虛擬地址所對應物理頁的物理地址。最後用線性地址的最低12位，也就是頁內偏移，加上這個物理頁的物理地址，就得到了該線性地址所對應的物理地址。

6. 常用的內存管理方法有哪幾種

常用的內存管理 方法 有哪幾種?下面是我給大家收集整理的一些相關方法技巧，希望對大家有幫助!

常用的內存管理方法

傳統的內存整理軟體工作原理大概是：先申請一塊“巨大內存”。因為物理內存幾乎全被內碼御譽存整理軟體佔用，因此Windows被迫把其他軟體的內存數據轉移到硬碟上的“虛擬內存交換文件”(PageFile)中，完成這一遲段過程之後內存整理軟體就會釋放掉剛剛申請的內存，至此整理過程完成，可用物理內存顯著增加。

大體上都是那麼回事，就是通過輔助空間，重新安排內存內容 ....

但是其中使用的演算法，效率是有很大的區別的 ～～ <script type="text/javascript"><!-- google_ad_client = "pub-4403405132739389"; google_ad_width = 250; google_ad_height = 250; google_ad_format = "250x250_as"; google_ad_type = "text"; //2007-10-22: 250*250 google_ad_channel = "7687946060"; google_ui_features = "rc:10"; //--> </script><script type="text/javascript" src=pagead2.googlesyndication/pagead/show_ads.js"> </script>

拓荒時代

國內的程序員大多是在 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 年的 Mola-3 語言， 1986 年的 Eiffel 語言， 1987 年的 Haskell 語言……它們都先後使用了自動垃圾收集技術。當然，每一種語言使用的垃圾收集演算法可能不盡相同，大多數語言和運行環境甚至同時使用了多種垃圾收集演算法。但無論怎樣，這些實例都說明，垃圾收集技術從誕生的那一天起就不是一種曲高和寡的“學院派”技術。

對於我們熟悉的 C 和 C++ 語言，垃圾收集技術一樣可以發揮巨大的功效。正如我們在學校中就已經知道的那樣， C 和 C++ 語言本身並沒有提供垃圾收集機制，但這並不妨礙我們在程序中使用具有垃圾收集功能的函數庫或類庫。例如，早在 1988 年， H. J. Boehm 和 A. J. Demers 就成功地實現了一種使用保守垃圾收集演算法( Conservative GC Algorithmic )的函數庫。我們可以在 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 資源而對其望而卻步，但二十多年前的程序員還曾因為高級語言速度太慢而堅持用機器語言寫程序呢!在硬體速度日新月異的今天，我們是要吝惜那一點兒時間損耗而踟躇不前，還是該堅定不移地站在代碼和運行環境的凈化劑——垃圾收集的一邊呢?