第三章包括5個小部分，1.垃圾收集的基本概念，2.優秀垃圾收集器的特征，3.收集器的
設計選擇，4.性能度量指標，5.分代收集的基本原理。
內容比較長，我會分成2篇帖子發，本章的內容是通用的，也就說這些內容同樣適用于其他JVM的實現，甚至其他語言的VM的垃圾收集實現。
今天的部分包括1－3，以下是正文：
第三章 垃圾收集概念
垃圾收集器負責以下幾個事情：
1.分配
內存 2.確保被引用的對象留在內存中
3.回收執行中
代碼的引用無法到達的對象占用的內存（譯注：強調執行中是為了排除對象互相引用的情況。A、B互相引用，但沒有任何執行中
代碼引用他們，A、B也應被回收）
對象被引用稱為活著的（live）。不再被引用的對象稱為死掉的（dead），術語叫垃圾（garbage）。發現和釋放（或者叫回收（reclaiming））
這些垃圾占用的空間叫做垃圾收集（garbage collection）。
垃圾收集可以解決很多內存分配
問題，卻不能解決所有的內存分配問題。例如，你可以創建對象并無限期的引用著直到沒有內存可用。垃圾收集在
使用其自身的時間和
資源上是一個復雜的任務。
垃圾收集器負責的內存是由精確的算法來組織、分配和回收的，并對
開發人員隱藏。空間通常從一個被稱為堆（heap）的非常大的內存池分配出來。
垃圾收集的時間由垃圾收集器決定。通常，整個堆或堆的一部分被填滿或者達到某個閾值的時候，會觸發垃圾收集。
滿足內存分配的請求是一個困難的任務，這其中包括要從堆中找到一個足夠大的內存塊。對于大部分的動態內存分配算法，其主要的問題是需要在
保持內存分配和回收效率的同時避免內存碎片。
優秀的垃圾收集器的特征 垃圾收集器必須是安全有效的。就是說，使用中的
數據永遠不能被
錯誤的釋放，同時在很少的幾個收集周期內垃圾就應該被回收。
垃圾收集器的執行效率也必須很優秀，暫停時間不能太長。暫停的時候，
應用系統是不運行的。然而，像大部分的計算機系統那樣，這里也必須在
時間、空間、頻率之間做出權衡。例如，堆很小的時候，垃圾收集的速度很快但堆被填滿的速度更快，這樣就需要更頻繁的垃圾收集。相反的，大
的堆填滿的速度慢，收集的頻率也慢，但花費的時間會比較長。
另一個特征是有限的內存碎片（fragmentation）。當垃圾對象的內存釋放后，釋放的空間會在各種各樣的區域形成小塊的空隙以至于可能導致沒
有一個足夠大的連續區域分配給較大的對象。一種減少內存碎片的方法叫做壓縮（compaction），在下面垃圾收集器的設計決策部分會討論到。
可擴展性同樣很重要。在多核系統上運行的多線程程序中，內存分配、垃圾收集都不能成為瓶頸。
設計決策 設計和選擇垃圾收集算法時必須做出一系列選擇：
串行還是并行 在串行收集中，同一時間只做一件事情。例如，即便有多個cpu可用，卻只有一個進行收集工作。當使用并行收集時，垃圾收集任務會分
成幾個小的部分，這些小的部分在不同的cpu上同時執行。同時執行的操作使得收集速度更快，它的代價是額外的復雜性和可能更多的內存碎
片。
并發的（Concurrent）還是停止一切（Stop-the-world） 當執行停止一切（Stop-the-world）的垃圾收集時，應用系統在收集期間完全暫停（suspended）了。另外一種選擇是，一個或多個垃圾
收集任務可以和應用系統同時并發的執行。通常，一個并發的收集器，大部分工作并發的執行，但仍會有一些短暫的暫停（stop-the-world
pauses）。停止一切的垃圾收集比并發收集更簡單，因為整個堆都凍結了，在收集期間對象不會改變。它缺點是一些應用程序不喜歡的暫停
（paused）。相應的，并發收集的暫停時間更短，但收集器必須格外的小心，執行收集的同時應用系統可能會改變對象的狀態，這會增加一
些開銷。并發收集會影響
性能并且需要較大的堆內存。
壓縮 or 不壓縮 or 拷貝 當收集器判定內存中的對象哪些是存活的哪些是垃圾之后，收集器可以壓縮（compact）內存，將所有存活的對象放到一起，從而完全的
恢復剩余的內存。壓縮之后，在第一個空閑位置分配內存將會非常的容易和迅速。可以用一個簡單的指針維持下一個可分配對象的位置。相
對壓縮的收集器，非壓縮（non-compacting）的收集器在原地（in-place）釋放垃圾對象占用的空間，它不會像壓縮的收集器那樣移動存活
的對象創建一個大的回收區。非壓縮的好處是收集完成的很快，缺點是可能有內存碎片。一般來說，從原地釋放的內存分配空間比從壓縮的
堆分配內存更困難些。它必須搜素堆空間找到一個足夠大能容納新對象的連續內存區域。第三種可供選擇的是
復制（copying）收集器，拷貝
（或疏導evacuates）所有活動的對象到另一個不同的內存區域。它的好處是原來的區域可以直接置空，簡單快速的為隨后的內存分配做好準
備，缺點是需要額外的空間和時間。
此文已轉移到：
http://www.xiegq.com/2013/09/15/37.html