Java 內存分配及垃圾回收機制初探

1、運行時內存分配

Java虛擬機在執行Java程序的過程當中會把它所管理的內存劃分爲若干個不一樣的數據區域。
這些區域都有各自的用途，以及建立和銷燬的時間，有的區域隨着虛擬機進程的啓動而存在，有些區域則依賴用戶線程的啓動和結束而創建和銷燬。

線程私有區域（生命週期與線程相同）

a) 虛擬機棧

虛擬機棧描述的是Java方法執行的內存模型：每一個方法在執行的同時都會建立一個棧幀（Stack Frame[1]）用於存儲局部變量表、 操做數棧、 動態連接、 方法出口等信息。 每個方法從調用直至執行完成的過程，就對應着一個棧幀在虛擬機棧中入棧到出棧的過程。

虛擬機棧中有一個局部變量表，存放了編譯期可知的各類基本數據類型（boolean、 byte、 char、 short、 int、float、 long、 double）、 對象引用（reference類型，它不等同於對象自己，多是一個指向對象起始地址的引用指針，也多是指向一個表明對象的句柄或其餘與此對象相關的位置）和returnAddress類型（指向了一條字節碼指令的地址）。

b）本地方法棧

本地方法棧（Native Method Stack）與虛擬機棧所發揮的做用是很是類似的，它們之間的區別不過是虛擬機棧爲虛擬機執行Java方法（也就是字節碼）服務，而本地方法棧則爲虛擬機使用到的Native方法服務。

c） 程序計數器

因爲Java虛擬機的多線程是經過線程輪流切換並分配處理器執行時間的方式來實現的，在任何一個肯定的時刻，一個處理器（對於多核處理器來講是一個內核）都只會執行一條線程中的指令。 所以，爲了線程切換後能恢復到正確的執行位置，每條線程都須要有一個獨立的程序計數器，各條線程之間計數器互不影響，獨立存儲，咱們稱這類內存區域爲「線程私有」的內存。

共享數據區

a）堆

對於大多數應用來講，Java堆（Java Heap）是Java虛擬機所管理的內存中最大的一塊。Java堆是被全部線程共享的一塊內存區域，在虛擬機啓動時建立。 此內存區域的惟一目的就是存放對象實例，幾乎全部的對象實例都在這裏分配內存。

根據Java虛擬機規範的規定，Java堆能夠處於物理上不連續的內存空間中，只要邏輯上是連續的便可，就像咱們的磁盤空間同樣。 在實現時，既能夠實現成固定大小的，也能夠是可擴展的，不過當前主流的虛擬機都是按照可擴展來實現的（經過-Xmx和-Xms控制）。

b）方法區

方法區（Method Area）與Java堆同樣，是各個線程共享的內存區域，它用於存儲已被虛
擬機加載的類信息、 常量、 靜態變量、 即時編譯器編譯後的代碼等數據。

相對而言，垃圾收集行爲在這個區域是比較少出現的，但並不是數據進入了方法區就如永久代的名字同樣「永久」存在了。 這區域的內存回收目標主要是針對常量池的回收和對類型的卸載，通常來講，這個區域的回收「成績」比較難以使人滿意，尤爲是類型的卸載，條件至關苛刻，可是這部分區域的回收確實是必要的。

Java對象建立過程

a） 虛擬機遇到一條new指令時，首先將去檢查這個指令的參數是否能在常量池中定位到一個類的符號引用，而且檢查這個符號引用表明的類是否已被加載、 解析和初始化過。 若是沒有，那必須先執行相應的類加載過程。

b) 爲對象分配內存（對象所需內存大小在類加載完成後便徹底肯定），對象所需內存的大小在類加載完成後即可徹底肯定（如何肯定將在2.3.2節中介紹），爲對象分配空間的任務等同於把一塊肯定大小的內存從Java堆中劃分出來。

2、垃圾對象斷定

1. 引用計數法

每一個對象都有一個引用計數的屬性，用來保存該對象被引用的次數。當引用次數爲0時，就意味着該對象沒有被引用了，也就不會在使用這個對象了，能夠斷定爲垃圾對象。可是，這種方式有一個很大的Bug，就是沒法解決對象間相互引用或者循環引用的問題：當兩個對象相互引用，他們兩個和其餘任何對象也沒有引用關係，它倆的引用次數都不爲0，所以不會被回收，但實際上這兩個對象已經再也不有用了。

2. 可達性分析（根搜索法）

在主流的商用程序語言（Java、 C#，甚至包括前面提到的古老的Lisp）的主流實現中，都是稱經過可達性分析（Reachability Analysis）來斷定對象是否存活的。這個算法的基本思路就是經過一系列的稱爲「GC Roots」的對象做爲起始點，從這些節點開始向下搜索，搜索所走過的路徑稱爲引用鏈（Reference Chain），當一個對象到GC Roots沒有任何引用鏈相連（用圖論的話來講，就是從GC Roots到這個對象不可達）時，則證實此對象是不可用的。 如圖3-1所示，對象object 五、 object 六、 object 7雖然互相有關聯，可是它們到GC Roots是不可達的，因此它們將會被斷定爲是可回收的對象。

這裏的GC Roots對象包括如下幾種：

虛擬機棧（棧幀中的本地變量表）中引用的對象。
方法區中類靜態屬性引用的對象。
方法區中常量引用的對象。
本地方法棧中JNI（即通常說的Native方法）引用的對象。

注： 這裏涉及Java中到四種引用，再也不細說。

在此我向你們推薦一個架構學習交流羣。交流學習羣號：478030634 裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化、分佈式架構等這些成爲架構師必備的知識體系。還能領取免費的學習資源，目前受益良多

3、典型的垃圾收集算法

在肯定了哪些垃圾能夠被回收後，垃圾收集器要作的事情就是開始進行垃圾回收，可是這裏面涉及到一個問題是：如何高效地進行垃圾回收。因爲Java虛擬機規範並無對如何實現垃圾收集器作出明確的規定，所以各個廠商的虛擬機能夠採用不一樣的方式來實現垃圾收集器，因此在此只討論幾種常見的垃圾收集算法的核心思想。

1.Mark-Sweep（標記-清除）算法

這是最基礎的垃圾回收算法，之因此說它是最基礎的是由於它最容易實現，思想也是最簡單的。標記-清除算法分爲兩個階段：標記階段和清除階段。標記階段的任務是標記出全部須要被回收的對象，清除階段就是回收被標記的對象所佔用的空間。具體過程以下圖所示：

從圖中能夠很容易看出標記-清除算法實現起來比較容易，可是有一個比較嚴重的問題就是容易產生內存碎片，碎片太多可能會致使後續過程當中須要爲大對象分配空間時沒法找到足夠的空間而提早觸發新的一次垃圾收集動做。

　2.Copying（複製）算法

爲了解決Mark-Sweep算法的缺陷，Copying算法就被提了出來。它將可用內存按容量劃分爲大小相等的兩塊，每次只使用其中的一塊。當這一塊的內存用完了，就將還存活着的對象複製到另一塊上面，而後再把已使用的內存空間一次清理掉，這樣一來就不容易出現內存碎片的問題。具體過程以下圖所示：

這種算法雖然實現簡單，運行高效且不容易產生內存碎片，可是卻對內存空間的使用作出了高昂的代價，由於可以使用的內存縮減到原來的一半。

很顯然，Copying算法的效率跟存活對象的數目多少有很大的關係，若是存活對象不少，那麼Copying算法的效率將會大大下降。

3.Mark-Compact（標記-整理）算法

爲了解決Copying算法的缺陷，充分利用內存空間，提出了Mark-Compact算法。該算法標記階段和Mark-Sweep同樣，可是在完成標記以後，它不是直接清理可回收對象，而是將存活對象都向一端移動，而後清理掉端邊界之外的內存。具體過程以下圖所示：

4.Generational Collection（分代收集）算法

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

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

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

注意，在堆區以外還有一個代就是永久代（Permanet Generation），它用來存儲class類、常量、方法描述等。對永久代的回收主要回收兩部份內容：廢棄常量和無用的類。

你們以爲文章對你仍是有一點點幫助的，你們能夠點擊下方二維碼進行關注。 《Java爛豬皮》 公衆號聊的不只僅是Java技術知識，還有面試等乾貨，後期還有大量架構乾貨。你們一塊兒關注吧！關注爛豬皮，你會了解的更多..............