JVM內(nèi)存分配策略

關(guān)于JVM的內(nèi)存結(jié)構(gòu)及內(nèi)存分配方式，不是本文的重點，這里只做簡單回顧。以下是我們知道的一些常識：

1、根據(jù)Java虛擬機規(guī)范，Java虛擬機所管理的內(nèi)存包括方法區(qū)、虛擬機棧、本地方法棧、堆、程序計數(shù)器等。

2、我們通常認為JVM中運行時數(shù)據(jù)存儲包括堆和棧。這里所提到的棧其實指的是虛擬機棧，或者說是虛擬棧中的局部變量表。

3、棧中存放一些基本類型的變量數(shù)據(jù)（int/short/long/byte/float/double/Boolean/char）和對象引用。

4、堆中主要存放對象，即通過new關(guān)鍵字創(chuàng)建的對象。

5、數(shù)組引用變量是存放在棧內(nèi)存中，數(shù)組元素是存放在堆內(nèi)存中。

在《深入理解Java虛擬機中》關(guān)于Java堆內(nèi)存有這樣一段描述：

但是，隨著JIT編譯期的發(fā)展與逃逸分析技術(shù)逐漸成熟，棧上分配、標量替換優(yōu)化技術(shù)將會導(dǎo)致一些微妙的變化，所有的對象都分配到堆上也漸漸變得不那么“絕對”了。

這里只是簡單提了一句，并沒有深入分析，很多人看到這里由于對JIT、逃逸分析等技術(shù)不了解，所以也無法真正理解上面這段話的含義。

PS：這里默認大家都了解什么是JIT，不了解的朋友可以先自行Google了解下

其實，在編譯期間，JIT會對代碼做很多優(yōu)化。其中有一部分優(yōu)化的目的就是減少內(nèi)存堆分配壓力，其中一種重要的技術(shù)叫做逃逸分析。

逃逸分析

逃逸分析(Escape Analysis)是目前Java虛擬機中比較前沿的優(yōu)化技術(shù)。這是一種可以有效減少Java 程序中同步負載和內(nèi)存堆分配壓力的跨函數(shù)全局數(shù)據(jù)流分析算法。通過逃逸分析，Java Hotspot編譯器能夠分析出一個新的對象的引用的使用范圍從而決定是否要將這個對象分配到堆上。

逃逸分析的基本行為就是分析對象動態(tài)作用域：當一個對象在方法中被定義后，它可能被外部方法所引用，例如作為調(diào)用參數(shù)傳遞到其他地方中，稱為方法逃逸。

例如：

public?static?StringBuffer craeteStringBuffer(String?s1,?String?s2) {
? ?StringBuffer sb =?new?StringBuffer();
? ?sb.append(s1);
? ?sb.append(s2);
? ?return?sb;
}

StringBuffer sb是一個方法內(nèi)部變量，上述代碼中直接將sb返回，這樣這個StringBuffer有可能被其他方法所改變，這樣它的作用域就不只是在方法內(nèi)部，雖然它是一個局部變量，稱其逃逸到了方法外部。甚至還有可能被外部線程訪問到，譬如賦值給類變量或可以在其他線程中訪問的實例變量，稱為線程逃逸。

上述代碼如果想要StringBuffer sb不逃出方法，可以這樣寫：

public?static?String?createStringBuffer(String?s1,?String?s2) {
? ?StringBuffer sb =?new?StringBuffer();
? ?sb.append(s1);
? ?sb.append(s2);
? ?return?sb.toString();
}

不直接返回 StringBuffer，那么StringBuffer將不會逃逸出方法。

使用逃逸分析，編譯器可以對代碼做如下優(yōu)化：

一、同步省略。如果一個對象被發(fā)現(xiàn)只能從一個線程被訪問到，那么對于這個對象的操作可以不考慮同步。

二、將堆分配轉(zhuǎn)化為棧分配。如果一個對象在子程序中被分配，要使指向該對象的指針永遠不會逃逸，對象可能是棧分配的候選，而不是堆分配。

三、分離對象或標量替換。有的對象可能不需要作為一個連續(xù)的內(nèi)存結(jié)構(gòu)存在也可以被訪問到，那么對象的部分（或全部）可以不存儲在內(nèi)存，而是存儲在CPU寄存器中。

上面的關(guān)于同步省略的內(nèi)容，我在《深入理解多線程（五）—— Java虛擬機的鎖優(yōu)化技術(shù)》中有介紹過，即鎖優(yōu)化中的鎖消除技術(shù)，依賴的也是逃逸分析技術(shù)。

本文，主要來介紹逃逸分析的第二個用途：將堆分配轉(zhuǎn)化為棧分配。

其實，以上三種優(yōu)化中，棧上內(nèi)存分配其實是依靠標量替換來實現(xiàn)的。由于不是本文重點，這里就不展開介紹了。如果大家感興趣，我后面專門出一篇文章，全面介紹下逃逸分析。

在Java代碼運行時，通過JVM參數(shù)可指定是否開啟逃逸分析，

?-XX:+DoEscapeAnalysis?： 表示開啟逃逸分析

?-XX:-DoEscapeAnalysis?： 表示關(guān)閉逃逸分析?

從jdk 1.7開始已經(jīng)默認開始逃逸分析，如需關(guān)閉，需要指定-XX:-DoEscapeAnalysis

對象的棧上內(nèi)存分配

我們知道，在一般情況下，對象和數(shù)組元素的內(nèi)存分配是在堆內(nèi)存上進行的。但是隨著JIT編譯器的日漸成熟，很多優(yōu)化使這種分配策略并不絕對。JIT編譯器就可以在編譯期間根據(jù)逃逸分析的結(jié)果，來決定是否可以將對象的內(nèi)存分配從堆轉(zhuǎn)化為棧。

我們來看以下代碼：

public?static?void?main(String[] args)?{
? ?long?a1 = System.currentTimeMillis();
? ?for?(int?i =?0; i <?1000000; i++) {
? ? ? ?alloc();
? ?}
? ?// 查看執(zhí)行時間
? ?long?a2 = System.currentTimeMillis();
? ?System.out.println("cost "?+ (a2 - a1) +?" ms");
? ?// 為了方便查看堆內(nèi)存中對象個數(shù)，線程sleep
? ?try?{
? ? ? ?Thread.sleep(100000);
? ?}?catch?(InterruptedException e1) {
? ? ? ?e1.printStackTrace();
? ?}
}

private?static?void?alloc()?{
? ?User user =?new?User();
}

static?class?User?{

}

其實代碼內(nèi)容很簡單，就是使用for循環(huán)，在代碼中創(chuàng)建100萬個User對象。

我們在alloc方法中定義了User對象，但是并沒有在方法外部引用他。也就是說，這個對象并不會逃逸到alloc外部。經(jīng)過JIT的逃逸分析之后，就可以對其內(nèi)存分配進行優(yōu)化。

我們指定以下JVM參數(shù)并運行：

-Xmx4G?-Xms4G?-XX:-DoEscapeAnalysis?-XX:+PrintGCDetails?-XX:+HeapDumpOnOutOfMemoryError

在程序打印出?cost XX ms?后，代碼運行結(jié)束之前，我們使用[jmap][1]命令，來查看下當前堆內(nèi)存中有多少個User對象：

? ?~ jps
2809 StackAllocTest
2810 Jps
? ?~ jmap -histo 2809

num ? ??#instances ? ? ? ? #bytes ?class name
----------------------------------------------
? 1: ? ? ? ? ? 524 ? ? ? 87282184 ?[I
? 2: ? ? ? 1000000 ? ? ? 16000000 ?StackAllocTest$User
? 3: ? ? ? ? ?6806 ? ? ? ?2093136 ?[B
? 4: ? ? ? ? ?8006 ? ? ? ?1320872 ?[C
? 5: ? ? ? ? ?4188 ? ? ? ? 100512 ?java.lang.String
? 6: ? ? ? ? ? 581 ? ? ? ? ?66304 ?java.lang.Class

從上面的jmap執(zhí)行結(jié)果中我們可以看到，堆中共創(chuàng)建了100萬個StackAllocTest$User實例。

在關(guān)閉逃避分析的情況下（-XX:-DoEscapeAnalysis），雖然在alloc方法中創(chuàng)建的User對象并沒有逃逸到方法外部，但是還是被分配在堆內(nèi)存中。也就說，如果沒有JIT編譯器優(yōu)化，沒有逃逸分析技術(shù)，正常情況下就應(yīng)該是這樣的。即所有對象都分配到堆內(nèi)存中。

接下來，我們開啟逃逸分析，再來執(zhí)行下以上代碼。

-Xmx4G?-Xms4G?-XX:+DoEscapeAnalysis?-XX:+PrintGCDetails?-XX:+HeapDumpOnOutOfMemoryError

在程序打印出?cost XX ms?后，代碼運行結(jié)束之前，我們使用jmap命令，來查看下當前堆內(nèi)存中有多少個User對象：

? ?~ jps
709
2858 Launcher
2859 StackAllocTest
2860 Jps
? ?~ jmap -histo 2859

num ? ??#instances ? ? ? ? #bytes ?class name
----------------------------------------------
? 1: ? ? ? ? ? 524 ? ? ?101944280 ?[I
? 2: ? ? ? ? ?6806 ? ? ? ?2093136 ?[B
? 3: ? ? ? ? 83619 ? ? ? ?1337904 ?StackAllocTest$User
? 4: ? ? ? ? ?8006 ? ? ? ?1320872 ?[C
? 5: ? ? ? ? ?4188 ? ? ? ? 100512 ?java.lang.String
? 6: ? ? ? ? ? 581 ? ? ? ? ?66304 ?java.lang.Class

從以上打印結(jié)果中可以發(fā)現(xiàn)，開啟了逃逸分析之后（-XX:+DoEscapeAnalysis），在堆內(nèi)存中只有8萬多個StackAllocTest$User對象。也就是說在經(jīng)過JIT優(yōu)化之后，堆內(nèi)存中分配的對象數(shù)量，從100萬降到了8萬。

除了以上通過jmap驗證對象個數(shù)的方法以外，讀者還可以嘗試將堆內(nèi)存調(diào)小，然后執(zhí)行以上代碼，根據(jù)GC的次數(shù)來分析，也能發(fā)現(xiàn)，開啟了逃逸分析之后，在運行期間，GC次數(shù)會明顯減少。正是因為很多堆上分配被優(yōu)化成了棧上分配，所以GC次數(shù)有了明顯的減少。

總結(jié)

所以，如果以后再有人問你：是不是所有的對象和數(shù)組都會在堆內(nèi)存分配空間？

那么你可以告訴他：不一定，隨著JIT編譯器的發(fā)展，在編譯期間，如果JIT經(jīng)過逃逸分析，發(fā)現(xiàn)有些對象沒有逃逸出方法，那么有可能堆內(nèi)存分配會被優(yōu)化成棧內(nèi)存分配。但是這也并不是絕對的。就像我們前面看到的一樣，在開啟逃逸分析之后，也并不是所有User對象都沒有在堆上分配。

轉(zhuǎn)載于:https://www.cnblogs.com/jay-wu/p/10137335.html

超強干貨來襲 云風(fēng)專訪：近40年碼齡，通宵達旦的技術(shù)人生

總結(jié)

以上是生活随笔為你收集整理的对象并不一定都是在堆上分配内存的的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。