這個問題讀過jvm，看了網上其他人的一些想法，總結一下自己的想法
垃圾回收分3步：
1 回收什麼
2 回收的時間點
3 回收的方法
一 什麼時候回收
當內存中記錄的對象沒有用了，就回收了
“程序計數器、虛擬機棧、本地方法棧3個區域會隨着線程而生，棧中的棧幀隨着方法的進行有條不紊地執行着出棧和入棧操作。每一個棧幀中分配多少內存基本上是在類結構確定下來時就已知得，因此這幾個區域的內存分配回收都具備確定性，在這幾個區域就不需要過多的考慮回收的問題，因爲在方法結束或線程結束時內存就被回收了”
垃圾收集器所關注的是Java堆和方法區
2種方式判斷是否該回收
1.引用計數法（對象的引用數量）：當一個對象被應用了，數量+1，當數量爲0時候，回收。有個缺點，A引用B，B引用A，循環引用，這2個對象在其他地方沒有引用，則需要下面的方法。
2.可達性分析算法，通過特定的算法，去尋找所有對象，當發現某些對象不可達時，回收
3.引用
其實無論通過那種算法來判斷對象是否已死，判斷都與“引用”有關
Java中引用可分爲強引用、軟引用、弱引用、虛引用四種，這4中引用強度一次降低
1）強引用：程序間普遍存在的，類似“Object obj = new Object()”這類引用，只要強引用還存在，垃圾收集器就永遠不會回收掉被引用的對象
2）軟引用：用來描述一些還有用但並非必須的對象。對於軟引用關聯的對象，在系統將要發生內存溢出異常之前，將會把這些對象列進回收範圍之中進行第二次回收。如果這次回收還沒有足夠的內存，纔會拋出內存溢出異常
3）弱引用：也是用來描述非必須對象的，但是它的強度比軟引用更弱一些，被弱引用關聯的對象只能生存到下一次垃圾收集發生之前。當垃圾收集器工作時，無論當前內存是否足夠，都會回收掉被弱引用關聯的對象
4）虛引用：也成爲幽靈引用或者歡迎引用，它是最弱的一種引用關係。一個對象是否具有虛引用的存在，完全不會對其生存時間構成影響，也無法通過虛引用來取得一個對象實例
二回收的時間點
參考引用
三回收的方法
本來想寫點自己想法的，發現大部分網上都有，而且寫的非常全面，直接把圖抄過來了
1.標記-清除算法
最基本的收集算法“標記-清除”（Mark-Sweep）算法，算法分爲“標記”和“清除”兩個階段：首先標記出所有需要回收的對象，在標記完成後統一回收所有被標記的對象，之所以說它是最基本的收集算法，是因爲後續的收集算法都是基於這種思路並對其不足進行改進而得到的。它的主要不足有兩個：
一是效率問題，標記和清除效率都不高，二是空間問題，標記清除後會產生大量不連續的內存碎片，空間碎片太多可能會導致以後程序在運行過程中需要分配較大對象時，無法找到足夠的連續內存而不得不提前觸發另一次垃圾收集動作
執行過程如下圖：
2.複製算法
爲了解決效率問題，一種稱爲“複製”（Copying）的收集算法出現了，他將可用內存按容量劃分爲大小相等的兩塊，每次只使用其中的一塊。當這塊的內存用完了，就將還存活這的對象複製到另外一塊上面，然後再把已使用過的內存空間一次清理掉。這樣使得每次都是對整個半區進行內存回收，內存分配時也就不用考慮內存碎片等複雜情況，只要移動堆頂指針，按順序分配內存即可，實現簡單，運行高效。只是這種算法的代價是將內存縮小爲了原來的一半，未免太高了一點。
3.標記-整理算法
複製收集算法在對象存活率較高時就要進行較多的複製操作，效率將會變低。更關鍵的是如果不想浪費50%的空間就要使用額外的空間進行分配擔保（Handle Promotion當空間不夠時，需要依賴其他內存），以應對被使用的內存中所有對象都100%存活的極端情況
對於“標記-整理”算法，標記過程仍與“標記-清除”算法一樣，但是後續步驟不是直接對可回收對象進行清理，而是讓所有的存活對象都向一端移動，然後直接清理掉端邊界以外的內存，”標記-整理“算法示意圖如下：
4.分代收集算法
當前的商業虛擬機的垃圾收集都是採用“分代收集”（Generational Collection）算法，這種算法並沒有什麼新的思想，只是根據對象存活週期的不同將內存劃分爲幾塊。一般是把堆劃分爲新生代和老年代，這樣就可以根據各個年代的特點採用最適合的收集算法。在新生代中，每次垃圾收集時都發現有大批對象死去，只有少量存活，那就採用複製算法，只需要付出少量存活對象的複製成本就可以完成收集。而老年代中因爲對象存活率高、沒有額外空間對它進行分配擔保，就必須使用“標記-清理”或者“標記-整理”算法來進行回收