哪些內存需要回收？
什么時候回收？
如何回收？
一：哪些內存需要回收？
JAVA內存中不需要考慮內存回收問題的區域：
程序計數器、虛擬機棧，本地方法棧
（隨線程生滅，棧幀分配多少內存在類結構確定是就已知，因此它們的內存分配與回收具備確定性。方法結束或線程結束時，內存自然就跟著回收了）
需要考慮內存回收問題的區域：
JAVA堆和方法區
(創建哪些對象，創建多少對象，需要在運行期間才知道。不再用創建對象的類定義要從方法區回收)
二：堆中對象的回收
死去的對象才會被回收
如何判斷對象已死
a.引用計數算法：
給對象添加一個引用計數器，每當有一個地方引用它時，計數器值就加1。引用失效時，計數器值就減1.任何時候計數器為0的對象就是不可能再被使用的。
優點：引用計數算法實現簡單，判定效率也高。(使用在COM,FlashPlayer,Python等語言中)
缺點：它很難解決對象之間相互循環引用的問題。（因此JAVA中沒有選用它來管理內存）
b.根搜索算法
對于任何"GC Roots"都沒有路徑到達對象時，該對象就是不可用的。
主流的程序語言都用的是根搜索算法，包括JAVA語言。
哪些對象才是"GC Roots"
- 虛擬機棧(棧幀中的本地變量表)中引用的對象
- 方法區中的類靜態屬性引用的對象
- 方法區中的常量引用的對象
- 本地方法棧中JNI的引用的對象
JAVA中的引用分為：強引用（Strong Reference）、軟引用（Soft Reference）、弱引用（Weak Reference）、虛引用（Phantom Reference）四種，強度依次減弱
- 強引用：代碼中存在，類似 "Object obj = new Object()"這類。只要強引用存在，GC就永遠不會回收掉被引用的對象。
- 軟引用：描述一些還有用，但非必需的對象。在系統將要發生內存溢出異常之前，將把這些對象列進回范圍之中并進行第二次回收。如果這次回收還沒有足夠的內存，才會拋出內存溢出異常。通過 SoftReference類來實現軟引用。
- 弱引用：也用于描述非必需對象，但它的強度要比軟引用更弱一些，被弱引用關聯的對象只能生成到下一次GC發生之前。當GC工作時，無論當前內存是否足夠，都會回收弱引用關聯的對象。通過 WeakReference類來實現弱引用
- 虛引用：也稱為幽靈引用或幻影引用。設置虛引用關聯的唯一目錄就是希望這個對象被回收時收到一個系統通知。通過PhantomReference來實現虛引用
究竟什么樣的對象才會死掉呢？
要真正宣告一個對象死亡，至少要經歷兩次標記過程：如果對象在進行根搜索后發現沒有與 GC Roots 相連接的引用鏈，那它將會被第一次標記并放到“即將被回收的集合”中。
與此同時進行一次篩選，篩選的條件是此對象是否有必要執行 finalize() 方法。(當對象沒有覆蓋 finalize()方法，或者 finalize() 方法已經被虛擬機調用過，虛擬機將這兩種情況都視為 "沒有必要執行"。)如果這個對象被判定為有必要執行 finalize()方法，那么這個對象將會被放置到一個名為 F-Queue 的隊列之中，將在稍后由一條由虛擬機自動建立的，低優先級的 Finalizer 線程去執行（觸發finalize()方法而不等待）。finalize()方法是對象逃脫死亡命運的最后一次機會。對象要在finalize()方法中拯救自己，只要重新與引用鏈上任何一個對象建立關聯即可，這樣的話第二次標記時它被移除出“即將回收的集合”。如果對象這個時候還沒有逃脫，那就真的離死不遠了。
三：方法區的回收
主要回收兩部份內容：廢棄常量、無用的類
常量回收與堆中對象回收類似。
無用的類的判斷需同時滿足3條：
- 該類所有的實例都已經被回收，也就是說堆中不存在該類的任何實例
- 加載該類的 ClassLoader 已經被回收
- 該類對應的 java.lang.Class 對象沒有在任何地方被引用，無法在任何地方通過反射訪問該類的方法
虛擬機對滿足上述3個條件的無用類進行回收。（只是可以，不會是必然回收）是否對類進行回收，HotSpot虛擬機了 -Xnoclassgc參數進行控制。還可以使用 -verbose:class 及-XX:+TraceClassLoading 和 -XX:+TraceClassUnLoading查看類的加載和卸載信息。
四：垃圾收集算法
4.1 標記-清除算法
標記出所有需要回收的對象，標記完成后統一回收掉所有被標記的對象。（如何標記在堆對象回收部分有介紹）
它是最基礎的收集算法，后續收集算法都是基于這種思路改進而得到。
缺點：效率不高，產生大量不連續的內存碎片。
（空間碎片太多，分配較大對象時就無法找到足夠連續內存空間，而不得不提前觸發另一次垃圾收集動作）
4.2 復制算法
（為解決效率問題）
將內存按容量劃分為大小相等的兩塊，每次只使用其中的一塊。當這一塊內存用完了，就將還存活著的對象復制到另一塊上面，然后再把已使用過的內存空間一次清理掉。
優點：內存分配時不用考慮碎片的問題，實現簡單，運行高效
缺點：內存縮小為原來的一半。
當對象存活率較高時，需要較多的復制操作，效率將會變低。若不想浪費50%的空間，需要額外的空間進行分配擔保
現在的商業虛擬機都采用這種收集算法來回收新生代(IBM研究表明，新生代對象98%是朝夕死的)。不過，并不是按1：1的比例來劃分內存空間。而是將內存分為一塊較大的 Eden 空間 和兩塊較小的Survivor空間。每次只使用 Eden 和其中的一塊Survivor。當回收時，將Eden和Survivor中還存活著的對象一次性拷貝到另外一塊Survivor空間上，最后清理掉剛才的Eden和Survivor。默認Eden和Survivor比例是 8:1。（98%是一般場景，另外一些場景下，當Survivor空間不夠時，需依賴其它內存【老年代】進行分配擔保）
4.3 標記-整理算法
復制算法的缺點，決定老年代不能使用復制算法
根據老年代特點，提出了“標記-整理算法”。
標記過程仍然與“標記-清除”算法一樣，但后續步驟不是直接對可回收對象進行清理，而是讓所有存活的對象都向一端移動，然后直接清理掉端邊界以外的內存。
4.4 分代收集算法
當前虛擬機的垃圾收集都采用“分代收集”算法。
根據對象的存活周期將內存劃分為幾塊。一般將堆分為新生代和老年代，這樣根據各個年代的特點采用最適當的收集算法。
新生代采用復制算法
老年代采用“標記-清理”或“標記-整理”算法
五：垃圾收集器
算法是內存回收的方法論，垃圾收集器是內存回收的具體實現。
Serial收集器
缺點：單線程收集器，垃圾收集時必須暫停其它所有的工作線程（Stop the world）。
優點：簡單而高效，對于Client模式下的虛擬機來說是一個很好的選擇。（也是Client模式下的默認新生代收集器）
ParNew 收集器
其實就是 Serial 收集器的多線程版本
是Server模式下的虛擬機的首選新生代收集器。（一個重要原因是，目前除了Serial收集器外，只有它能與CMS收集器配合工作）
Paraller Scavenge 收集器
并行的多線程收集器
它的關注點與其它收集器的不同，它關注的是吞吐量
吞吐量=運行用戶代碼時間/(運用用戶代碼時間+垃圾收集時間)
Serial Old 收集器
是Serial收集器的老年代版本，同樣是單線程收集器。使用“標記-整理”算法
Parallel Old 收集器
是Parallel Scavenge收集器的老年代版本，使用多線和和“標記-整理算法”，JDK1.6才提供。
注重吞吐量及CPU資源敏感的場合，可以優先考慮Parallel Scavenge加Parallel Old組合。
CMS收集器 （Concurrent Mark Sweep）
是一種以獲取最短回收停頓時間為目標的收集器。
對于B/S類重視服務器響應速度，希望停頓時間最短類應用就比較適合。
基于“標記-清除算法實現”
內存回收過程與用戶線程起并發的執行。
缺點：
對CPU資源非常敏感。
無法處理浮動垃圾
收集結束時會產生大量空間碎片
G1收集器（Garbage First）`
JDK1.7正式發布時，很可能會有一個成熟的商業版本隨之發布。
相對CMS的改進：
基于“標記-整理”算法實現，不會產生空間碎片
可以非常精確的控制停頓
可以實現基本不犧牲吞吐量的前提下完成低停頓的內存回收