程序計數器、虛擬機棧、本地方法棧隨線程而生,也隨線程而滅;棧幀隨着方法的開始而入棧,隨着方法的結束而出棧。這幾個區域的內存分配和回收都具備肯定性,在這幾個區域內不須要過多考慮回收的問題,由於方法結束或者線程結束時,內存天然就跟隨着回收了。java
而對於 Java 堆和方法區,咱們只有在程序運行期間才能知道會建立哪些對象,這部份內存的分配和回收都是動態的,垃圾收集器所關注的正是這部份內存。算法
一個對象不被任何對象或變量引用,就是無效對象,須要被回收。緩存
在對象頭維護着一個 counter 計數器,對象被引用一次則計數器 +1;若引用失效則計數器 -1。當計數器爲 0 時,就認爲該對象無效了。this
引用計數算法的實現簡單,斷定效率也很高,在大部分狀況下它都是一個不錯的算法。可是主流的 Java 虛擬機裏沒有選用引用計數算法來管理內存,主要是由於它很難解決對象之間循環引用的問題。線程
對象 objA 和 objB 都有字段 instance,令 objA.instance = objB 而且 objB.instance = objA,因爲它們互相引用着對方,致使它們的引用計數都不爲0,會使得垃圾收集器永遠沒法回收這兩個對象。
全部和 GC Roots 直接或間接關聯的對象都是有效對象,和 GC Roots 沒有關聯的對象就是無效對象。對象
GC Roots 是指:生命週期
GC Roots 並不包括堆中對象所引用的對象,這樣就不會有循環引用的問題。隊列
斷定對象是否存活與「引用」有關。在 JDK 1.2 之前,Java 中的引用定義很傳統,一個對象只有被引用或者沒有被引用兩種狀態,咱們但願能描述這一類對象:當內存空間還足夠時,則保留在內存中;若是內存空間在進行垃圾手收集後仍是很是緊張,則能夠拋棄這些對象。不少系統的緩存功能都符合這樣的應用場景。內存
在 JDK 1.2 以後,Java 對引用的概念進行了擴充,將引用分爲了如下四種:虛擬機
相似 "Object obj = new Object()" 這類的引用,就是強引用,只要強引用存在,垃圾收集器永遠不會回收被引用的對象。
軟引用是用來描述一些有用但並不是必需的對象,軟引用關聯着的對象,在系統即將發生內存溢出時,會將這些對象列入回收範圍進行回收。若是回收事後尚未足夠的內存,才拋出內存溢出異常。
弱引用也是用來描述非必需對象的,可是它的強度比軟引用更弱一些。當 JVM 進行垃圾回收時,不管內存是否充足,都會回收被軟引用關聯的對象。
虛引用也稱幽靈引用或者幻影引用,它是最弱的一種引用關係。一個對象是否有虛引用的存在,徹底不會對其生存時間構成影響。爲一個對象設置虛引用關聯的惟一目的就是能在這個對象被收集器回收時收到一個系統通知。
對於可達性分析中不可達的對象,也並非沒有存活的可能。
JVM 會判斷此對象是否有必要執行 finalize() 方法,若是對象沒有覆蓋 finalize() 方法,或者 finalize() 方法已經被虛擬機調用過,那麼視爲「沒有必要執行」。那麼對象基本上就真的被回收了。
若是對象被斷定爲有必要執行 finalize() 方法,那麼對象會被放入一個 F-Queue 隊列中,虛擬機會以較低的優先級執行這些 finalize()方法,但不會確保全部的 finalize() 方法都會執行結束。若是 finalize() 方法出現耗時操做,虛擬機就直接中止指向該方法,將對象清除。
若是在執行 finalize() 方法時,將 this 賦給了某一個引用,那麼該對象就重生了。若是沒有,那麼就會被垃圾收集器清除。
任何一個對象的 finalize() 方法只會被系統自動調用一次,若是對象面臨下一次回收,它的 finalize() 方法不會被再次執行,想繼續在 finalize() 中自救就失效了。
方法區中存放生命週期較長的類信息、常量、靜態變量,每次垃圾收集只有少許的垃圾被清除。方法區中主要清除兩種垃圾:
只要常量池中的常量不被任何變量或對象引用,那麼這些常量就會被清除掉。
斷定一個類是不是「無用的類」,條件較爲苛刻。
一個類被虛擬機加載進方法區,那麼在堆中就會有一個表明該類的對象:java.lang.Class。這個對象在類被加載進方法區時建立,在方法區該類被刪除時清除。
學會了如何斷定無效對象、無用類、廢棄常量以後,也就知道了垃圾收集器會清除哪些數據,接下來介紹如何清除這些數據。
判斷哪些數據須要清除,並對它們進行標記,而後清除被標記的數據。
這種方法有兩個不足:
爲了解決效率問題,「複製」收集算法出現了。它將可用內存按容量劃分爲大小相等的兩塊,每次只使用其中的一塊。當這一塊內存用完,須要進行垃圾收集時,就將存活者的對象複製到另外一塊上面,而後將第一塊內存所有清除。這種算法有優有劣:
爲了解決空間利用率問題,能夠將內存分爲三塊: Eden、From Survivor、To Survivor,比例是 8:1:1,每次使用 Eden 和其中一塊 Survivor。回收時,將 Eden 和 Survivor 中還存活的對象一次性複製到另一塊 Survivor 空間上,最後清理掉 Eden 和剛纔使用的 Survivor 空間。這樣只有 10% 的內存被浪費。
可是咱們沒法保證每次回收都只有很少於 10% 的對象存活,當 Survivor 空間不夠,須要依賴其餘內存(指老年代)進行分配擔保。
爲對象分配內存空間時,若是 Eden+Survivor 中空閒區域沒法裝下該對象,會觸發 MinorGC 進行垃圾收集。但若是 Minor GC 事後依然有超過 10% 的對象存活,這樣存活的對象直接經過分配擔保機制進入老年代,而後再將新對象存入 Eden 區。
在回收垃圾前,首先將廢棄對象作上標記,而後將未標記的對象移到一邊,最後清空另外一邊區域便可。
這是一種老年代的垃圾收集算法。老年代的對象通常壽命比較長,所以每次垃圾回收會有大量對象存活,若是採用複製算法,每次須要複製大量存活的對象,效率很低。
根據對象存活週期的不一樣,將內存劃分爲幾塊。通常是把 Java 堆分爲新生代和老年代,而後根據各個年代的特色採用最適當的收集算法。