Java語言中一個顯著的特色就是引入了垃圾回收機制,使c++程序員最頭疼的內存管理的問題迎刃而解,它使得Java程序員在編寫程序的時候再也不 須要考慮內存管理。因爲有個垃圾回收機制,Java中的對象再也不有「做用域」的概念,只有對象的引用纔有「做用域」。垃圾回收能夠有效的防止內存泄露,有 效的使用空閒的內存。html
ps:內存泄露是指該內存空間使用完畢以後未回收,在不涉及複雜數據結構的通常狀況下,Java 的內存泄露表現爲一個內存對象的生命週期超出了程序須要它的時間長度,咱們有時也將其稱爲「對象遊離」。java
Java語言規範沒有明確地說明JVM使用哪一種垃圾回收算法,可是任何一種垃圾回收算法通常要作2件基本的事情:c++
(1)發現無用信息對象;
(2)回收被無用對象佔用的內存空間,使該空間可被程序再次使用。
1.引用計數法(Reference Counting Collector)程序員
1.1 算法分析 算法
引用計數是垃圾收集器中的早期策略。在這種方法中,堆中每一個對象實例都有一個引用計數。當一個對象被建立時,且將該對象實例分配給一個變量,該變量 計數設置爲1。當任何其它變量被賦值爲這個對象的引用時,計數加1(a = b,則b引用的對象實例的計數器+1),但當一個對象實例的某個引用超過了生命週期或者被設置爲一個新值時,對象實例的引用計數器減1。任何引用計數器爲 0的對象實例能夠被看成垃圾收集。當一個對象實例被垃圾收集時,它引用的任何對象實例的引用計數器減1。數據庫
1.2 優缺點網絡
1.3 引用計數算法沒法解決循環引用問題,例如:數據結構
public class Main { public static void main(String[] args) { MyObject object1 = new MyObject(); MyObject object2 = new MyObject(); object1.object = object2; object2.object = object1; object1 = null; object2 = null; } }
最後面兩句將object1和object2賦值爲null,也就是說object1和object2指向的對象已經不可能再被訪問,可是因爲它們互相引用對方,致使它們的引用計數器都不爲0,那麼垃圾收集器就永遠不會回收它們。多線程
2.tracing算法(Tracing Collector) 或 標記-清除算法(mark and sweep)併發
2.1根搜索算法
根搜索算法是從離散數學中的圖論引入的,程序把全部的引用關係看做一張圖,從一個節點GC ROOT開始,尋找對應的引用節點,找到這個節點之後,繼續尋找這個節點的引用節點,當全部的引用節點尋找完畢以後,剩餘的節點則被認爲是沒有被引用到的節點,即無用的節點。
java中可做爲GC Root的對象有:
2.2 tracing算法的示意圖
2.3 標記-清除算法分析
標記-清除算法採用從根集合進行掃描,對存活的對象對象標記,標記完畢後,再掃描整個空間中未被標記的對象,進行回收,如上圖所示。標記-清除算法 不須要進行對象的移動,而且僅對不存活的對象進行處理,在存活對象比較多的狀況下極爲高效,但因爲標記-清除算法直接回收不存活的對象,所以會形成內存碎 片。
3.compacting算法 或 標記-整理算法
標記-整理算法採用標記-清除算法同樣的方式進行對象的標記,但在清除時不一樣,在回收不存活的對象佔用的空間後,會將全部的存活對象往左端空閒空間 移動,並更新對應的指針。標記-整理算法是在標記-清除算法的基礎上,又進行了對象的移動,所以成本更高,可是卻解決了內存碎片的問題。在基於 Compacting算法的收集器的實現中,通常增長句柄和句柄表。
4.copying算法(Compacting Collector)
該算法的提出是爲了克服句柄的開銷和解決堆碎片的垃圾回收。它開始時把堆分紅 一個對象 面和多個空閒面, 程序從對象面爲對象分配空間,當對象滿了,基於copying算法的垃圾收集就從根集中掃描活動對象,並將每一個活動對象複製到空閒面(使得活動對象所佔的 內存之間沒有空閒洞),這樣空閒面變成了對象面,原來的對象面變成了空閒面,程序會在新的對象面中分配內存。
一種典型的基於coping算法的垃圾回收是stop-and-copy算法,它將堆分紅對象面和空閒區域面,在對象面與空閒區域面的切換過程當中,程序暫停執行。
5.generation算法(Generational Collector)
分代的垃圾回收策略,是基於這樣一個事實:不一樣的對象的生命週期是不同的。所以,不一樣生命週期的對象能夠採起不一樣的回收算法,以便提升回收效率。
年輕代(Young Generation)
eden
區和兩個survivor(survivor0,survivor1)
區。 一個Eden區,兩個Survivor區(通常而言)。大部分對象在Eden區中生成。回收時先將eden區存活對象複製到一個survivor0區,然 後清空eden區,當這個survivor0區也存放滿了時,則將eden區和survivor0區存活對象複製到另外一個survivor1區,而後清空 eden和這個survivor0區,此時survivor0區是空的,而後將survivor0區和survivor1區交換,即保持 survivor1區爲空,如此往復。年老代(Old Generation)
持久代(Permanent Generation)
用於存放靜態文件,如Java類、方法等。持久代對垃圾回收沒有顯著影響,可是有些應用可能動態生成或者調用一些class,例如Hibernate 等,在這種時候須要設置一個比較大的持久代空間來存放這些運行過程當中新增的類。
新生代收集器使用的收集器:Serial、PraNew、Parallel Scavenge
老年代收集器使用的收集器:Serial Old、Parallel Old、CMS
Serial收集器(複製算法)
新生代單線程收集器,標記和清理都是單線程,優勢是簡單高效。
Serial Old收集器(標記-整理算法)
老年代單線程收集器,Serial收集器的老年代版本。
ParNew收集器(中止-複製算法)
新生代收集器,能夠認爲是Serial收集器的多線程版本,在多核CPU環境下有着比Serial更好的表現。
Parallel Scavenge收集器(中止-複製算法)
並行收集器,追求高吞吐量,高效利用CPU。吞吐量通常爲99%, 吞吐量= 用戶線程時間/(用戶線程時間+GC線程時間)。適合後臺應用等對交互相應要求不高的場景。
Parallel Old收集器(中止-複製算法)
Parallel Scavenge收集器的老年代版本,並行收集器,吞吐量優先。
CMS(Concurrent Mark Sweep)收集器(標記-清理算法)
高併發、低停頓,追求最短GC回收停頓時間,cpu佔用比較高,響應時間快,停頓時間短,多核cpu 追求高響應時間的選擇。
因爲對象進行了分代處理,所以垃圾回收區域、時間也不同。GC有兩種類型:Scavenge GC和Full GC.
Scavenge GC
通常狀況下,當新對象生成,而且在Eden申請空間失敗時,就會觸發Scavenge GC,對Eden區域進行GC,清除非存活對象,而且把尚且存活的對象移動到Survivor區。而後整理Survivor的兩個區。這種方式的GC是對 年輕代的Eden區進行,不會影響到年老代。由於大部分對象都是從Eden區開始的,同時Eden區不會分配的很大,因此Eden區的GC會頻繁進行。因 而,通常在這裏須要使用速度快、效率高的算法,使Eden去能儘快空閒出來。
Full GC
對整個堆進行整理,包括Young、Tenured和Perm。Full GC由於須要對整個堆進行回收,因此比Scavenge GC要慢,所以應該儘量減小Full GC的次數。在對JVM調優的過程當中,很大一部分工做就是對於FullGC的調節。有以下緣由可能致使Full GC:
1.靜態集合類像HashMap、Vector等的使用最容易出現內存泄露,這些靜態變量的生命週期和應用程序一致,全部的對象Object也不能被釋放,由於他們也將一直被Vector等應用着。
Static Vector v = new Vector(); for (int i = 1; i<100; i++) { Object o = new Object(); v.add(o); o = null; }
在這個例子中,代碼棧中存在Vector 對象的引用 v 和 Object 對象的引用 o 。在 For 循環中,咱們不斷的生成新的對象,而後將其添加到 Vector 對象中,以後將 o 引用置空。問題是當 o 引用被置空後,若是發生 GC,咱們建立的 Object 對象是否可以被 GC 回收呢?答案是否認的。
由於, GC 在跟蹤代碼棧中的引用時,會發現 v 引用,而繼續往下跟蹤,就會發現 v 引用指向的內存空間中又存在指向 Object 對象的引用。也就是說盡管o 引用已經被置空,可是 Object 對象仍然存在其餘的引用,是能夠被訪問到的,因此 GC 沒法將其釋放掉。若是在此循環以後, Object 對象對程序已經沒有任何做用,那麼咱們就認爲此 Java 程序發生了內存泄漏。
2.各類鏈接,數據庫鏈接,網絡鏈接,IO鏈接等沒有顯示調用close關閉,不被GC回收致使內存泄露。
3.監聽器的使用,在釋放對象的同時沒有相應刪除監聽器的時候也可能致使內存泄露。
做者:Sunnier
文章源自:http://www.cnblogs.com/sunniest/p/4575144.html