java基礎（一）：談談java內存管理與垃圾回收機制

看了不少java內存管理的文章或者博客，寫的要麼籠統，要麼劃分的不正確，且不少文章都千篇一概。例如部分地方將jvm籠統的分爲堆、棧、程序計數器，這麼分太過於籠統，沒法清晰的闡述java的內存管理模型；部分地方將jvm分爲堆、棧、程序計數器、常量池、方法區，這麼分，很全面，可是過於混亂，由於這些區域之間存在並列和包含關係，而最近再次刷《Java Thinking》這本書的時候，重新學習了關於內存模型的內容。基於上述緣由，我決定來談談jvm虛擬機的內存劃分。

至於垃圾回收機制，我的以爲應該和內存管理一同討論，因此在此，我也將內存回收機制拿出來進行一塊兒討論。

本片博客的大體結構：1.內存區域；2.內存回收機制；3.垃圾回收器

1.內存區域

首先看看官方的內存模型圖片：圖片來自《Java虛擬機規範（第2版）》

1.1.程序計數器：

程序計數器是一個比較小的內存區域，用於指示當前線程所執行的字節碼執行到了第幾行，能夠理解爲是當前線程的行號指示器。字節碼解釋器在工做時，會經過改變這個計數器的值來取下一條語句指令。因爲Java虛擬機的多線程是經過線程輪流切換並分配處理器執行時間的方式來實現的，在任何一個肯定的時刻，一個處理器（對於多核處理器來講是一個內核）只會執行一條線程中的指令。所以，爲了線程切換後能恢復到正確的執行位置，每條線程都須要有一個獨立的程序計數器，各條線程之間的計數器互不影響，獨立存儲，咱們稱這類內存區域爲「線程私有」的內存。 若是線程正在執行的是一個Java方法，這個計數器記錄的是正在執行的虛擬機字節碼指令的地址；若是正在執行的是Natvie方法，這個計數器值則爲空（Undefined），因爲程序計數器只是記錄當前指令地址，因此不存在內存溢出的狀況，所以，程序計數器也是全部JVM內存區域中惟一一個沒有定義OutOfMemoryError的區域。

1.2.棧

棧分爲虛擬機棧和本地方法棧，既然都是棧，那麼就具備相同的特性：私有的，線程安全，棧中存儲了基本數據類型和對象的引用

1.2.1.java虛擬機棧

一個線程的每一個方法在執行的同時，都會建立一個棧幀（Statck Frame），棧幀中存儲的有局部變量表、操做站、動態連接、方法出口等，當方法被調用時，棧幀在JVM棧中入棧，當方法執行完成時，棧幀出棧。實際上每一個方法的調用至關因而棧幀的入棧已經出棧操做。局部變量表中存儲着方法的相關局部變量，包括各類基本數據類型，對象的引用，返回地址等。在局部變量表中，只有long和double類型會佔用2個局部變量空間（Slot，對於32位機器，一個Slot就是32個bit），其它都是1個Slot。須要注意的是，局部變量表是在編譯時就已經肯定好的，方法運行所須要分配的空間在棧幀中是徹底肯定的，在方法的生命週期內都不會改變。虛擬機棧中定義了兩種異常，若是線程調用的棧深度大於虛擬機容許的最大深度，則拋出StatckOverFlowError（棧溢出）；不過多數Java虛擬機都容許動態擴展虛擬機棧的大小(有少部分是固定長度的)，因此線程能夠一直申請棧，直到內存不足，此時，會拋出OutOfMemoryError（內存溢出）。

1.2.2.本地方法棧

本地方法棧在做用，運行機制，異常類型等方面都與虛擬機棧相同，惟一的區別是：虛擬機棧是執行Java方法的，而本地方法棧是用來執行native方法的，如調用C++，C#編寫的方法。目前在不少虛擬機中（如Sun的JDK默認的HotSpot虛擬機），會將本地方法棧與虛擬機棧放在一塊兒使用。

1.3.堆

堆是線程共享的，存儲的是對象的實例，有的地方寫存儲的是對象的實例和數組，實際上數組是特殊的類，那麼數組也屬於對象的實例。在JVM所管理的內存中，堆區是最大的一塊，堆區也是Java GC發生的主要場所，在虛擬機啓動時建立，因此堆也成爲GC堆，按照java垃圾回收的概念，堆又能夠分爲新生代和老年代，永久代（只有部分虛擬機中有永久代的概念，sun公司的HotSpot虛擬機就有，其它的通常沒有，而hotSpot應用的比較普遍），其中新生代又能夠分爲Eden，From Survivor，To Survivor，其中每一塊具體的做用在垃圾回收模塊會詳細介紹。原則上講，全部的對象都在堆區上分配內存，可是隨着JIT編譯器的發展與逃逸分析技術的逐漸成熟，棧上分配、標量替換優化技術將會致使一些微妙的變化發生，全部的對象都分配在堆上也漸漸變得不是那麼「絕對」了。通常的，根據Java虛擬機規範規定，堆內存須要在邏輯上是連續的（在物理上不須要），在實現時，能夠是固定大小的，也能夠是可擴展的，目前主流的虛擬機都是可擴展的（經過-Xmx和-Xms控制）。若是在執行垃圾回收以後，仍沒有足夠的內存分配，也不能再擴展，將會拋出OutOfMemoryError:Java heap space異。

1.4.方法區

方法區（Method Area）與Java堆同樣，是各個線程共享的內存區域，它用於存儲已被虛擬機加載的類信息、常量、靜態變量、即時編譯器編譯後的代碼等數據。雖然Java虛擬機規範把方法區描述爲堆的一個邏輯部分，可是它卻有一個別名叫作Non-Heap（非堆），目的應該是與Java堆區分開來。對於習慣在HotSpot虛擬機上開發和部署程序的開發者來講，不少人願意把方法區稱爲「永久代」（Permanent Generation），本質上二者並不等價，僅僅是由於HotSpot虛擬機的設計團隊選擇把GC分代收集擴展至方法區，或者說使用永久代來實現方法區而已。對於其餘虛擬機（如BEA JRockit、IBM J9等）來講是不存在永久代的概念的。即便是HotSpot虛擬機自己，根據官方發佈的路線圖信息，如今也有放棄永久代並「搬家」至Native Memory來實現方法區的規劃了。Java虛擬機規範對這個區域的限制很是寬鬆，除了和Java堆同樣不須要連續的內存和能夠選擇固定大小或者可擴展外（經過設置permsize和MaxPermsize設置方法區的初始化大小和最大內存），還能夠選擇不實現垃圾收集。相對而言，垃圾收集行爲在這個區域是比較少出現的，但並不是數據進入了方法區就如永久代的名字同樣「永久」存在了。這個區域的內存回收目標主要是針對常量池的回收和對類型的卸載，通常來講這個區域的回收「成績」比較難以使人滿意，尤爲是類型的卸載，條件至關苛刻，可是這部分區域的回收確實是有必要的。在Sun公司的BUG列表中，曾出現過的若干個嚴重的BUG就是因爲低版本的HotSpot虛擬機對此區域未徹底回收而致使內存泄漏。 根據Java虛擬機規範的規定，當方法區沒法知足內存分配需求時，將拋出OutOfMemoryError異常。

1.5.常量池

運行時常量池（Runtime Constant Pool）是方法區的一部分。Class文件中除了有類的版本、字段、方法、接口等描述等信息外，還有一項信息是常量池（Constant Pool Table），用於存放編譯期生成的各類字面量和符號引用，這部份內容將在類加載後存放到方法區的運行時常量池中。 Java虛擬機對Class文件的每一部分（天然也包括常量池）的格式都有嚴格的規定，每個字節用於存儲哪一種數據都必須符合規範上的要求，這樣纔會被虛擬機承認、裝載和執行。但對於運行時常量池，Java虛擬機規範沒有作任何細節的要求，不一樣的提供商實現的虛擬機能夠按照本身的須要來實現這個內存區域。不過，通常來講，除了保存Class文件中描述的符號引用外，還會把翻譯出來的直接引用也存儲在運行時常量池中。 運行時常量池相對於Class文件常量池的另一個重要特徵是具有動態性，Java語言並不要求常量必定只能在編譯期產生，也就是並不是預置入Class文件中常量池的內容才能進入方法區運行時常量池，運行期間也可能將新的常量放入池中，這種特性被開發人員利用得比較多的即是String類的intern()方法。 既然運行時常量池是方法區的一部分，天然會受到方法區內存的限制，當常量池沒法再申請到內存時會拋出OutOfMemoryError異常。

2.垃圾回收算法

java 語言中一個顯著的特色就是引入了java回收機制，是c++程序員最頭疼的內存管理的問題迎刃而解，它使得java程序員在編寫程序的時候不在考慮內存管理。因爲有個垃圾回收機制，java中的額對象不在有「做用域」的概念，只有對象的引用纔有「做用域」。垃圾回收能夠有效的防止內存泄露，有效的使用空閒的內存；java語言規範沒有明確的說明JVM 使用哪一種垃圾回收算法，可是任何一種垃圾回收算法通常要作兩件基本事情：（1）發現無用的信息對象；（2）回收將無用對象佔用的內存空間。使該空間可被程序再次使用。

2.1.引用計數法(Reference Counting Collector)

引用計數是垃圾收集器中的早期策略。在這種方法中，堆中每一個對象實例都有一個引用計數。當一個對象被建立時，且將該對象實例分配給一個變量，該變量計數設置爲1。當任何其它變量被賦值爲這個對象的引用時，計數加1（a = b,則b引用的對象實例的計數器+1），但當一個對象實例的某個引用超過了生命週期或者被設置爲一個新值時，對象實例的引用計數器減1。任何引用計數器爲0的對象實例能夠被看成垃圾收集。當一個對象實例被垃圾收集時，它引用的任何對象實例的引用計數器減1。

2.1.2優缺點

優勢：引用計數收集器能夠很快的執行，交織在程序運行中。對程序須要不被長時間打斷的實時環境比較有利。

缺點：沒法檢測出循環引用。如父對象有一個對子對象的引用，子對象反過來引用父對象。這樣，他們的引用計數永遠不可能爲0.

2.2.tracing算法(Tracing Collector) 或 標記-清除算法(mark and sweep)

該算法是從離散數學中的圖論引入的，程序把全部的引用關係看做一張圖，從一個節點GC ROOT開始，尋找對應的引用節點，找到這個節點之後，繼續尋找這個節點的引用節點，當全部的引用節點尋找完畢以後，剩餘的節點則被認爲是沒有被引用到的節點，即無用的節點。

java中可做爲GC Root的對象有

1.虛擬機棧中引用的對象（本地變量表）

2.方法區中靜態屬性引用的對象

3. 方法區中常量引用的對象

4.本地方法棧中引用的對象（Native對象）

標記-清除算法採用從根集合進行掃描，對存活的對象對象標記，標記完畢後，再掃描整個空間中未被標記的對象，進行回收。分爲兩個階段：標記階段和清除階段。標記階段的任務是標記出全部須要被回收的對象，清除階段就是回收被標記的對象所佔用的空間。具體過程以下圖所示。標記-清除算法不須要進行對象的移動，而且僅對不存活的對象進行處理，在存活對象比較多的狀況下極爲高效，但因爲標記-清除算法直接回收不存活的對象，所以會形成內存碎片。

2.3.compacting算法 或 標記-整理算法

標記-整理算法採用標記-清除算法同樣的方式進行對象的標記，但在清除時不一樣，在回收不存活的對象佔用的空間後，會將全部的存活對象往左端空閒空間移動，並更新對應的指針。標記-整理算法是在標記-清除算法的基礎上，又進行了對象的移動，所以成本更高，可是卻解決了內存碎片的問題。在基於Compacting算法的收集器的實現中，通常增長句柄和句柄表。

2.4.copying算法(Compacting Collector)

該算法的提出是爲了克服句柄的開銷和解決堆碎片的垃圾回收。它開始時把堆分紅 一個對象 面和多個空閒面， 程序從對象面爲對象分配空間，當對象滿了，基於copying算法的垃圾 收集就從根集中掃描活動對象，並將每一個 活動對象複製到空閒面(使得活動對象所佔的內存之間沒有空閒洞)，這樣空閒面變成了對象面，原來的對象面變成了空閒面，程序會在新的對象面中分配內存。一種典型的基於coping算法的垃圾回收是stop-and-copy算法，它將堆分紅對象面和空閒區域面，在對象面與空閒區域面的切換過程當中，程序暫停執行。這種算法雖然實現簡單，運行高效且不容易產生內存碎片，可是卻對內存空間的使用作出了高昂的代價，由於可以使用的內存縮減到原來的一半。很顯然，Copying算法的效率跟存活對象的數目多少有很大的關係，若是存活對象不少，那麼Copying算法的效率將會大大下降。

2.5.generation算法(Generational Collector)

分代的垃圾回收策略，是基於這樣一個事實：不一樣的對象的生命週期是不同的。所以，不一樣生命週期的對象能夠採起不一樣的回收算法，以便提升回收效率。分代收集算法是目前大部分JVM的垃圾收集器採用的算法。它的核心思想是根據對象存活的生命週期將內存劃分爲若干個不一樣的區域。通常狀況下將堆區劃分爲老年代（Tenured Generation）和新生代（Young Generation）和持久代，老年代的特色是每次垃圾收集時只有少許對象須要被回收，而新生代的特色是每次垃圾回收時都有大量的對象須要被回收，那麼就能夠根據不一樣代的特色採起最適合的收集算法。

2.5.1.年輕代（Young Generation）

1.全部新生成的對象首先都是放在年輕代的。年輕代的目標就是儘量快速的收集掉那些生命週期短的對象。

2.新生代內存按照8:1:1的比例分爲一個eden區和兩個survivor(survivor0,survivor1)區。一個Eden區，兩個 Survivor區(通常而言)。大部分對象在Eden區中生成。回收時先將eden區存活對象複製到一個survivor0區，而後清空eden區，當這個survivor0區也存放滿了時，則將eden區和survivor0區存活對象複製到另外一個survivor1區，而後清空eden和這個survivor0區，此時survivor0區是空的，而後將survivor0區和survivor1區交換，即保持survivor1區爲空， 如此往復。

3.當survivor1區不足以存放 eden和survivor0的存活對象時，就將存活對象直接存放到老年代。如果老年代也滿了就會觸發一次Full GC，也就是新生代、老年代都進行回收

4.新生代發生的GC也叫作Minor GC，MinorGC發生頻率比較高(不必定等Eden區滿了才觸發)

2.5.2.年老代（Old Generation）

1.在年輕代中經歷了N次垃圾回收後仍然存活的對象，就會被放到年老代中。所以，能夠認爲年老代中存放的都是一些生命週期較長的對象。

2.內存比新生代也大不少(大概比例是1:2)，當老年代內存滿時觸發Major GC即Full GC，Full GC發生頻率比較低，老年代對象存活時間比較長，存活率標記高。

2.5.3.持久代（Permanent Generation）

用於存放靜態文件，如Java類、方法等。持久代對垃圾回收沒有顯著影響，可是有些應用可能動態生成或者調用一些class，例如Hibernate 等，在這種時候須要設置一個比較大的持久代空間來存放這些運行過程當中新增的類。

目前大部分垃圾收集器對於新生代都採起Copying算法，由於新生代中每次垃圾回收都要回收大部分對象，也就是說須要複製的操做次數較少，可是實際中並非按照1：1的比例來劃分新生代的空間的，通常來講是將新生代劃分爲一塊較大的Eden空間和兩塊較小的Survivor空間，每次使用Eden空間和其中的一塊Survivor空間，當進行回收時，將Eden和Survivor中還存活的對象複製到另外一塊Survivor空間中，而後清理掉Eden和剛纔使用過的Survivor空間。

而因爲老年代的特色是每次回收都只回收少許對象，通常使用的是Mark-Compact算法。

當Eden區滿的時候，會觸發第一次Minor gc，把還活着的對象拷貝到Survivor From區；當Eden區再次出發Minor gc的時候，會掃描Eden區和From區，對兩個區域進行垃圾回收，通過此次回收後還存活的對象，則直接複製到To區域，並將Eden區和From區清空。 當後續Eden區又發生Minor gc的時候，會對Eden區和To區進行垃圾回收，存活的對象複製到From區，並將Eden區和To區清空 部分對象會在From區域和To區域中複製來複制去，如此交換15次(由JVM參數MaxTenuringThreshold決定，這個參數默認是15)，最終若是還存活，就存入老年代。

3.垃圾回收（瞭解）

新生代收集器使用的收集器：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.年老代（Tenured）被寫滿

2.持久代（Perm）被寫滿

3.System.gc()被顯示調用

4.上一次GC以後Heap的各域分配策略動態變化

1.靜態集合類像HashMap、Vector等的使用最容易出現內存泄露，這些靜態變量的生命週期和應用程序一致，全部的對象Object也不能被釋放，由於他們也將一直被Vector等應用着。

2.各類鏈接，數據庫鏈接，網絡鏈接，IO鏈接等沒有顯示調用close關閉，不被GC回收致使內存泄露。

3.監聽器的使用，在釋放對象的同時沒有相應刪除監聽器的時候也可能致使內存泄露。

www.cnblogs.com/andy-zcx/p/…

www.cnblogs.com/wabi8754756…

blog.csdn.net/yubujian_l/…

www.cnblogs.com/dz-boss/p/1…