2. 程式人生 > >JVM理論：（二/1）內存分配策略

JVM理論：（二/1）內存分配策略

阿新 • • 發佈：2018-07-29
本地線程 準備 最大 機會 bubuko 空間不夠 嘗試 它的 日誌分析

　　Java技術體系中所提倡的自動內存管理最終可以歸結為自動化地解決兩個問題：給對象分配內存以及回收分配給對象的內存。

對象的分配可能有以下幾種方式：

1、JIT編譯後被拆散為標量類型並間接地棧上分配

2、對象主要分配在新生代的Eden區上，如果啟動了本地線程分配緩沖，將按線程優先在TLAB上分配

3、少數情況下也會直接分配在老年代

參考下圖：

　　技術分享圖片

5種內存分配策略

1、對象優先在Eden分配

　　大多數情況下，對象在新生代Eden區中分配，當Eden區沒有足夠空間進行分配時，虛擬機將發起一次Minor GC。

　　先來看看兩種GC類型的定義

　　新生代GC（Minor GC）：指發生在新生代的垃圾收集動作，因為Java對象大多具備朝生夕死的特性，所以Minor GC非常頻繁，一般回收速度也比較快。

　　老年代GC（Major GC/Full GC）：指發生在老年代的GC，出現了Major GC，經常會伴隨至少一次的Minor GC（Parallel Scavenge裏可設置直接進行Major GC，所以並非絕對），Major GC的速度一般會比Minor GC慢10倍以上。　

經典案例代碼：
private static final int _1MB = 1024 * 1024;  
/**  
* VM參數：-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8 
*/  
public static void
 
 testAllocation() {  
    byte[] allocation1, allocation2, allocation3, allocation4;  
    allocation1 = new byte[2 * _1MB];  
    allocation2 = new byte[2 * _1MB]; 
    allocation3 = new byte[2 * _1MB]; 
    allocation4 = new byte[4 * _1MB];  // 出現一次Minor GC  
}

運行結果：
[GC [DefNew: 6651K->148K(9216K), 0.0070106 secs] 6651K->6292K(19456K), 0.0070426 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

　　先看看設置的虛擬機參數，-Xms20M -Xmx20M -Xmn10M這3個參數限制了Java堆大小為20MB，不可擴展，其中10MB分配給新生代，剩下的10MB分配給老年代。-XX:SurvivorRatio=8決定了新生代中Eden區與一個Survivor區的空間比例是8：1，所以Eden有8MB的空間，一個Survivor區有1MB的空間，-XX:+PrintGCDetails表示虛擬機會在垃圾回收時打印內存回收日誌。

　　testAllocation()方法中嘗試分配3個2MB大小和1個4MB大小的對象，在執行分配allocation4對象的語句時，會發現Eden區已經被占用了6MB，剩余2M空間，已不足以分配allocation4所需的4MB內存，因此會發生一次Minor GC。GC期間虛擬機又發現已有的3個2MB大小的對象全部無法放入只有1MB大小的Survivor空間，所以根據分配擔保機制會提前轉移到老年代去。

　　根據打印的GC日誌，6651K->148K(9216K), 6651K->6292K(19456K)也可以看出，新生代從6651K變為148K，但總內存占用量幾乎沒有減少，也證實allocation1、allocation2、allocation3三個對象都是存活的，只是被轉移到了老年代，虛擬機幾乎沒有找到可回收的對象。這次GC後，程序執行完的結果是，Eden被allocation4占用4MB，Survivor空閑，老年代被allocation1、allocation2、allocation3三個對象占用6MB。

　　所以，對象在新生代Eden區中分配，當Eden區沒有足夠空間進行分配時，虛擬機將發起一次Minor GC。

*//堆空間分布日誌
Heap  
　　def new generation   total 9216K, used 4326K　　　　//年輕代分布   
　　eden space 8192K,  51% used ≈ 4MB
　　from space 1024K,  14% used ≈ 148KB，應該是之前的垃圾，忽略  
　　to space 1024K,   0% used
　　tenured generation   total 10240K, used 6144K 　　 //老年代分布  
　　the space 10240K,  60% used ≈ 2048KB*3
　　compacting perm gen  total 12288K, used 2114K 　　 //永久代（方法區）分布，本例不考慮  
　　the space 12288K,  17% used

　　再從上例中的內存對分布的角度來重新推測過程：當分配到allocation4時，發現eden空間不足，這時進行GC，但由於Survivor只有1MB，存不下allocation1、allocation2、allocation3中的任意對象，所以這三個對象都直接進入老年代，最後allocation4分配在Eden，占4MB。

2、大對象直接進入老年代

　　大對象是指需要大量連續內存空間的Java對象，典型大對象有長字符串和數組，大對象對虛擬機的內存分配來說是一個壞消息，寫程序時還要避免創建一些朝生夕死的短命大對象，經常出現大對象容易導致內存還有不少空間時就提前觸發垃圾收集以獲取足夠的連續空間來安置他們。

　　虛擬機提供-XX:PretenureSizeThreshold參數，令大於這個設置值的對象直接在老年代分配，這樣避免再Eden及兩個Survivor區間發生大量的內存復制，這個參數只對Serial和ParNew兩款收集器有效，如果遇到必須使用此參數的場合，可以考慮ParNew加CMS的組合。

3、根據對象年齡判定進入老年代

　　虛擬機給每個對象定義了一個對象年齡計數器，如果對象在Eden出生並經過第一次Minor GC後仍然存活，並且能被Survivor容納的話，將被移動到Survivor空間中，並且對象年齡設為1，對象在Survivor區中每熬過一次Minor GC，年齡就增加1歲，當它的年齡增加到一定程度（默認為15歲），就會被晉升到老年代中，可以通過-XX:MaxTenuringThreshold參數來設置年齡閾值。

代碼示例：
private static final int _1MB = 1024 * 1024;
/**
 * VM參數: -verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails
 * -XX:SurvivorRatio=8 -XX:+UseSerialGC -XX:MaxTenuringThreshold=1
 * -XX:+PrintTenuringDistribution
 */
@SuppressWarnings("unused")
public static void testTenuringThreshold() {
    byte[] allocation1, allocation2, allocation3;
    allocation1 = new byte[_1MB / 4];
    //什麽時候進入老年代決定於XX:MaxTenuringThreshold設置
    allocation2 = new byte[4 * _1MB];
    allocation3 = new byte[4 * _1MB];
    allocation3 = null;
    allocation3 = new byte[4 * _1MB];
}
堆空間分布日誌
以MaxTenuringThreshold=1參數來運行的結果：
Heap  
def new generation   total 9216K, used 4178K   //年輕代分布
eden space 8192K,  51% used ≈ 4MB 
from space 1024K,   0% used  
to   space 1024K,   0% used    
tenured generation   total 10240K, used 4500K  //老年代分布
the space 10240K,  43% used ≈ 4MB+256KB
compacting perm gen  total 12288K, used 2114K  //永久代分布先忽略
the space 12288K,  17% used
　以MaxTenuringThreshold=1的情況來分析，當要分配allocation3時，Eden空間不足，準備開始GC，照理Survivor（1MB）是能容納下allocation1（256KB）的，但因為MaxTenuringThreshold=1，allocation1對象在第二次GC發生時進入老年代，所以Survivor區沒有對象，老年代存放了
allocation1和allocation2，eden中存的是allocation3。
以MaxTenuringThreshold=15參數來運行的結果：
Heap  
def new generation   total 9216K, used 4582K   //年輕代分布
eden space 8192K,  51% used ≈ 4MB 
from space 1024K,  39% used ≈ 256KB 
to   space 1024K,   0% used  
tenured generation   total 10240K, used 4096K  //老年代分布
the space 10240K,  40% used = 4MB
　以MaxTenuringThreshold=15的情況來分析，當要分配allocation3時，Eden空間不足，準備開始GC，這次MaxTenuringThreshold=15，所以allocation1不會直接進入老年代，會到Survivor區域內，Survivor存不了allocation2，所以allocation2被移動到老年代，最後在Eden分配allocation3。

4、Survivor空間中相同年齡的對象過半直接進入老年代

　　上一點講到MaxTenuringThreshold參數，但虛擬機並不是永遠地要求對象的年齡必須達到MaxTenuringThreshold才能晉升老年代，如果Survivor空間中相同年齡所有對象大小的總和大於Survivor空間的一半，年齡大於或等於該年齡的對象就可以直接進入老年代，無須等到MaxTenuringThreshold中要求的年齡。

private static final int _1MB = 1024 * 1024;  
/**  
 * VM參數：-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 
 * -XX:+PrintTenuringDistribution  
 */  
@SuppressWarnings("unused")  
public static void testTenuringThreshold2() { 
  byte[] allocation1, allocation2, allocation3, allocation4;  
  allocation1 = new byte[_1MB / 4];   
  // allocation1+allocation2大於survivo空間一半  
  allocation2 = new byte[_1MB / 4];    
  allocation3 = new byte[4 * _1MB];  
  allocation4 = new byte[4 * _1MB];  
  allocation4 = null;  
  allocation4 = new byte[4 * _1MB];  
}

Heap  
def new generation   total 9216K, used 4178K      //年輕代
eden space 8192K,  51% used ≈ 4MB 
from space 1024K,   0% used  
to   space 1024K,   0% used  
tenured generation   total 10240K, used 4756K     //老年代 
the space 10240K,  46% used ≈ 4MB+256KB*2

　　根據堆內存分布日誌分析，當要分配allocation4時，發現Eden空間不夠進行GC，由於-XX:MaxTenuringThreshold設置為15，且Survivor區是可以容納下allocation1和allocation2的，照理說這兩個對象應該是要進入Survivor區的，但這兩個對象對沒有進入Survivor而是直接進入了老年代，這就是因為allocation1和allocation2兩對象相加為512KB，達到了Survivor的一半，且它們同年齡，所以會直接進入老年代。Survivor區不夠存allocation3也直接進入老年代，最後在Eden上分配allocation4。

5、空間分配擔保

　　關於分配擔保機制JDK6前後有一點差別。　　

　　JDK6之前，在發生Minor GC之前，虛擬機會先檢查老年代最大可用的連續空間是否大於新生代所有對象總空間。

　　如果檢查老年代最大可用的連續空間大於新生代所有對象總空間，那麽Minor GC可以確保是安全的。

　　如果檢查不成立，則虛擬機會查看HandlePromotionFailure設置值是否允許擔保失敗。

　 　　如果允許擔保失敗，那麽會繼續檢查老年代最大可用的連續空間是否大於歷次晉升到老年代對象的平均大小，這裏取平均值是因為在實際完成內存回收前無法明確知道有多少對象會存活下來，所以也存在一定風險。

　　　　　　如果大於歷次平均大小，將嘗試著進行一次Minor GC，盡管這次Minor GC是有風險的，Minor GC若執行失敗也會進行執行一次Full GC，這樣的失敗繞的圈子是最大的；

　　　　　　如果小於歷次平均大小，或者HandlePromotionFailure設置不允許冒險，那這時也要改為進行一次Full GC。

　　對以上的步驟歸納一下，先看老年代的可用空間能否容下新生代的所有對象，不能的話看是否開啟了分配擔保機制，允許就先執行Minor GC，否則直接進行Full GC。大部分情況下還是會將HandlePromotionFailure開啟分配擔保，避免頻繁Full GC。

　　JDK6後，HandlePromotionFailure不再影響到虛擬機的空間分配擔保策略，變為只要老年代的連續空間大於新生代對象總大小或歷次晉升的平均大小就會進行Minor GC，否則將進行Full GC。

參考鏈接：

　　https://www.jianshu.com/p/fa3569127416

　　https://segmentfault.com/a/1190000004606059

JVM理論：（二/1）內存分配策略

相關推薦

JVM理論：（二/1）內存分配策略

本地線程 準備 最大 機會 bubuko 空間不夠 嘗試 它的 日誌分析 　　Java技術體系中所提倡的自動內存管理最終可以歸結為自動化地解決兩個問題：給對象分配內存以及回收分配給對象的內存。 對象的分配可能有以下幾種方式： 1、JIT編譯後被拆散為標量類型並間接地棧上分配

JVM理論：（三/1）class類文件結構

src row classes java 通知 ans 統一 ron 引用 　　各種不同平臺的虛擬機，與所有平臺都統一使用的程序存儲格式——字節碼，是構成平臺無關性與語言無關性的基石。 　　Java虛擬機不和包括Java在內的任何語言綁定，它只與“Class文件”這種特定的

JVM理論：（二/3）垃圾收集算法、垃圾收集器

alt epg 掃描 read 一半 面向服務 參數 erl 數據結構 　　掌握三種垃圾算法，七種垃圾收集器，了解每種垃圾收集器使用的是哪種垃圾收集算法，以及關於SafePoint的知識點。 垃圾收集算法 1、標記-清除算法（Mark-Sweep） 　　先標記（如可達

JVM理論：（二/4）理解GC日誌、垃圾收集器參數總結

相關 serial inf 說明 test 日誌 虛擬機啟動 cool 收集 JVM的GC日誌的主要參數包括如下幾個： -XX:+PrintGC 輸出GC日誌 -XX:+PrintGCDetails 輸出GC的詳細日誌 -XX:+PrintGCTimeStamps 輸出GC

JVM理論：（三/7）關於類變量、成員變量、局部變量的案例總結

turn 用戶 操作數棧 類繼承 str 運算 標識 urn () 一、類變量、成員變量、局部變量的內存分布 　　結合前文，對類變量、成員變量、局部變量三種變量的內存分布進行總結 1）類變量：方法區。靜態變量隨類加載到方法區中。方法區中存儲已經被虛擬機加載的類信息、常量、靜

JVM理論：（三/8）關於String、StringBuffer、StringBuilder、final

avi stringbu .net int 新的 java程序 2個 chang 字符串 　　以下是從網上整理出的資料，不同作者對某些具體描述有略微差別，有的具體描述可能會存在不準確的情況，但結論是一致的。 一、String 　　equals比較值，==比較引用，我們主要關

JVM理論：（三/5）類加載機制

it! 4條 extend 用戶 輸入 編譯器 alac 實例化 結束 　　前文已經講了Class文件的存儲格式、方法的調用過程、字節碼的執行過程。但是虛擬機是如何加載這些Class文件的呢？Class文件中的信息進入到虛擬機後會發生什麽變化？ 　　虛擬機將描述類的數據從C

JVM理論：（四/2）編譯過程——晚期（運行期）

num 計算 圖片 標準 int 虛擬 java 方法 特殊情況 cap 一、解釋器與編譯器 　　當虛擬機發現某個方法或代碼塊的運行特別頻繁時，就會把這些代碼認定為“熱點代碼” 。為了提高熱點代碼的執行效率，在運行時，虛擬機將會把這些代碼編譯成與本地平臺相關的機器碼，並進行

JVM理論：（三/6）類加載器、雙親委派

rap 自定義 pan 類名 唯一性 sso 返回 工作過程 lse 一、類與類加載器 　　允許類加載階段中的“通過一個類的全限定名來獲取描述此類的二進制字節流”這個動作可以讓應用程序自己決定如何去獲取所需要的類。實現這個動作的代碼模塊稱為“類加載器”。 　　類加載器雖然只

JVM理論：（三/4）方法調用

script 定位 入口 重寫 並不是 rip 參數順序 java面向對象 以及 　　本文主要總結虛擬機調用方法的過程是怎樣的，JAVA虛擬機裏面提供了5條方法調用的字節碼指令。分別如下： 　　invokestatic:調用靜態方法 　　invokespecial:調用實例

JVM理論：（三/3）運行時棧幀結構、基於棧的字節碼解釋執行過程

指向 stat 中一 指令執行過程 字節碼指令 輸出 作用 引擎 jvm 一、棧幀結構 　　講棧幀結構有必要回顧一下前文Class文件中的Code屬性結構，如下圖。 　　 　　棧幀是用於支持虛擬機進行方法調用和方法執行的數據結構，它是虛擬機棧的棧元素。每一個方法從調用開始到

leveldb 閱讀筆記（1） 內存分配

erp ant 保存 系統調用 tin assert blog 方便 png 內存管理對於任何程序都是很重要的一塊，leveldb自己也實現了一個簡單了內存分配器，而不是使用一些其他開源軟件tcmalloc等，避免了對其他軟件的依賴。 自己實現內存分配器有什麽好處呢？

深入理解JVM：垃圾收集器與內存分配策略

四種 內存回收 第一次 不可達 append test 方法 static hot 堆裏面存放著Java世界差點兒全部的對象實例，垃圾收集器在對堆進行回收前。第一件事情就是要確定這些對象之中哪些還存活，哪些已經死去。推斷對象的生命周期是否結束有下面幾種方

jvm筆記-02-垃圾收集器與內存分配策略

對象實例 collect 地方法 ant 用戶交互 缺點 each 虛引用 生成 [TOC] 對象的生存與死亡 如何判定一個對象的生與死 引用計數法 Reference Counting 給對象中添加一個引用計數器，被引用加1，引用失效減1，計數器為0則對象可以被回收。

垃圾收集器與內存分配策略 （深入理解JVM二）

nali noclass eth 清理 full gc 原因 商業 jit編譯器 代碼 1.概述 垃圾收集（Garbage Collection,GC）. 當需要排查各種內存溢出、內存泄露問題時，當垃圾收集成為系統達到更高並發量的瓶頸時，我們就需要對這些&ldquo

深入理解jvm虛擬機讀書筆記-垃圾收集器與內存分配策略（二）

具體實現 地方 比例 並發 解決 垃圾收集 替換 map 而是 垃圾收集算法-標記清除算法 標記清除算法是最基礎的收集算法。算法分為“標記”和“清楚”兩個階段：首先標記出所有需要回收的對象，在標記過程完成後統一回收所有被標記的對象。後續的收集算法都是基於這種思路對其不足進行

詞向量原始碼解析：（6.1）fasttext原始碼解析

fasttext是word2vec的作者mikolov參與的製作的一個工具包，可以用來訓練詞向量和進行文字分類。目前已經引起了廣泛的關注。這個工具包在github上面的地址是 https://github.com/facebookresearch/fastText 這個專案

Golang教程：（二十三）緩衝通道和工人池

什麼是緩衝通道上一節我們討論的是基本的無緩衝區的通道，對一個無緩衝的通道進行傳送/寫入和接收/讀取資料是實時阻塞的。事實上我們可以建立一個帶緩衝區的通道，往通道中傳送資料時，只有當緩衝區滿的情況下才會阻塞；類似的，只有我們從通道中讀取資料時，只有讀到緩衝區空為止才會阻塞。帶緩

垃圾收集器與內存分配策略之篇二：垃圾收集器

開啟 full gc 行處理 意義 方案 發現 特征 sea 互聯網 五、垃圾收集器 如果說收集算法是內存回收的方法論，那麽垃圾收集器就是內存回收的具體實現。由於java虛擬機規範對垃圾收集器實現沒有任何的規範因此不同的廠商，不同的版本的虛擬機所提供的垃圾收集器都有可

Go語言內存管理（一）內存分配

特定 offset 閾值 簡化 思路 三種 私有ca 空間不足 ces Go語言內存管理（一）內存分配 golang作為一種“高級語言”，也提供了自己的內存管理機制。這樣一方面可以簡化編碼的流程，降低因內存使用導致出現問題的頻率（C語言使用者尤其是初學者應該深有體會），對程