❶ 常用的內存管理方法有哪幾種
常用的內存管理 方法 有哪幾種?下面是我給大家收集整理的一些相關方法技巧，希望對大家有幫助!
常用的內存管理方法傳統的內存整理軟體工作原理大概是：先申請一塊“巨大內存”。因為物理內存幾乎全被內存整理軟體佔用，因此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 資源而對其望而卻步，但二十多年前的程序員還曾因為高級語言速度太慢而堅持用機器語言寫程序呢!在硬體速度日新月異的今天，我們是要吝惜那一點兒時間損耗而踟躇不前，還是該堅定不移地站在代碼和運行環境的凈化劑——垃圾收集的一邊呢?
❷ gc是什麼意思啊
GC有多層含義，一是計算機術語，指Gabage
Collection；二是網路用語，支持的意思；三是網路域中的GC，就是「全局目錄」Global
Catalog；四是科研用語，即Gas
Chromatography（氣相色譜法）。
詳見
http://ke..com/view/315216.htm
❸ GC是什麼意思
常用的GC演算法： 1）標記非活動對象 －－何為非活動對象，通俗的講，就是無引用的對象。追蹤root對象演算法： 深度追蹤root對象，將heap中所有被引用到的root做標志，所有未被標志的對象視為非活動對象，所佔用的空間視為非活動內存。2）清理非活動對象 Copy演算法： 方法：將內存分為兩個區域（from space和to space）。所有的對象分配內存都分配到from space。在清理非活動對象階段，把所有標志為活動的對象，到to space，之後清楚from space空間。然後互換from sapce和to space的身份。既原先的from space變成to sapce，原先的to space變成from space。每次清理，重復上述過程。優點：演算法不理會非活動對象，數量僅僅取決為活動對象的數量。並且在的同時，整理了heap空間，即，to space的空間使用始終是連續的，內存使用效率得到提高。缺點：劃分from space和to space，內存的使用率是1／2。Compaction演算法： 方法：在清理非活動對象階段，刪除非活動對象佔用內存，並且把活動對象向heap的底部移動，直到所有的活動對象被移到heap的一側。優點：無須劃分from sapce和to space，提高內存的使用率。並且compaction後的內存空間也是連續分配的。缺點：該演算法相對比較復雜。sun jdk gc介紹： 在減少gc之前，先來看看來自IBM的一組統計數據： 98％的java對象，在創建之後不久就變成了非活動對象；只有2％的對象，會在長時間一直處於活動狀態。如果能對這兩種對象區分對象，那麼會提交GC的效率。在sun jdk gc中（具體的說，是在jdk1.4之後的版本），提出了不同生命周期的GC策略。young generation： 生命周期很短的對象，歸為young generation。由於生命周期很短，這部分對象在gc的時候，很大部分的對象已經成為非活動對象。因此針對young generation的對象，採用演算法，只需要將少量的存活下來的對象到to space。存活的對象數量越少，那麼演算法的效率越高。young generation的gc稱為minor gc。經過數次minor gc，依舊存活的對象，將被移出young generation，移到tenured generation（下面將會介紹） young generation分為： eden：每當對象創建的時候，總是被分配在這個區域 survivor1：演算法中的from space survivor2：演算法中的to sapce （備註：其中survivor1和survivor2的身份在每次minor gc後被互換） minor gc的時候，會把eden survivor1(2)的對象到survivor2(1)去。tenured generation： 生命周期較常的對象，歸入到tenured generation。一般是經過多次minor gc，還 依舊存活的對象，將移入到tenured generation。（當然，在minor gc中如果存活的對象的超過survivor的容量，放不下的對象會直接移入到tenured generation） tenured generation的gc稱為major gc，就是通常說的full gc。採用compactiion演算法。由於tenured generaion區域比較大，而且通常對象生命周期都比較常，compaction需要一定時間。所以這部分的gc時間比較長。minor gc可能引發full gc。當eden＋from space的空間大於tenured generation區的剩餘空間時，會引發full gc。這是悲觀演算法，要確保eden＋from space的對象如果都存活，必須有足夠的tenured generation空間存放這些對象。Permanet Generation： 該區域比較穩定，主要用於存放classloader信息，比如類信息和method信息。對於spring hibernate這些需要動態類型支持的框架，這個區域需要足夠的空間。這部分內容相對比較理論，可以結合jstat，jmap等命令（當然也可以使用jconsole，jprofile，gciewer等工具），觀察jdk gc的情
❹ java gc中為什麼復制演算法比標記整理演算法快
1、因為復制gc只需要把「活」的對象拷貝到survivor
2、復制演算法：兩個區域A和B，初始對象在A，繼續存活的對象被轉移到B。此為新生代最常用的演算法
標記清理：一塊區域，標記要回收的對象，然後回收，一定會出現碎片，那麼引出
標記-整理演算法：多了碎片整理，整理出更大的內存放更大的對象。
3、每次都是對其中的一塊進行內存回收,沒存分配時也就不用考慮內存碎片等復雜情況,只要移動堆頂指針，按順序分配內存即可，實現簡單，運行高效。