運行資料區

位元組碼只是一個二進制檔案存放在那里，要想在jvm里跑起來，先得有個運行的記憶體環境，

也就是我們所說的jvm運行時資料區，

1）運行時資料區的位置

運行時資料區是jvm中最為重要的部分，執行引擎頻繁操作的就是它，類的初始化，以及后面我們講的物件空間的分配、垃圾的回收都是在這塊區域發生的，

file

2）區域劃分

根據《Java虛擬機規范》中的規定，在運行時資料區將記憶體細分為幾個部分

執行緒私有的：Java虛擬機堆疊（Java Virtual Machine Stack）、程式計數器（Program Counter Register）、本地方法堆疊（Native Method Stacks）

大家共享的：方法區（Method Area）、Java堆區（Java Heap）

file

接下來我們分塊詳細來解讀，每一塊是做什么的，如果溢位了會發生什么事情

1.1 程式計數器

1.1.1 概述

程式計數器（Program Counter Register）

每個執行緒一個，是一塊較小的記憶體空間，它表示當前執行緒執行的位元組碼指令的地址，
位元組碼解釋器作業時，通過改變這個計數器的值來選取下一條需要執行的位元組碼指令，所以整個程式無論是分支、回圈、跳轉、例外處理、執行緒恢復等基礎功能都需要依賴這個計數器來完成，
由于執行緒是多條并行執行的，互相之間執行到哪條指令是不一樣的，所以每條執行緒都需要有一個獨立的程式計數器，各條執行緒之間計數器互不影響，獨立存盤，我們稱這類記憶體區域為“執行緒私有”的記憶體，
如果是native方法，這里為空

1.1.2 溢位例外

沒有！

在虛擬機規范中，沒有對這塊區域設定記憶體溢位規范，也是唯一一個不會溢位的區域

1.1.3 案例

因為它不會溢位，所以我們沒有辦法給它造一個，但是從class類上可以找到痕跡，

回顧上面javap的反匯編，其中code所對應的編號就可以理解為計數器中所記錄的執行編號，

file

1.2 虛擬機堆疊

file

1.2.1 概述

也是執行緒私有的！生命周期與執行緒相同，
它描述的是Java方法執行的當前執行緒的記憶體模型，每個方法被執行的時候，Java虛擬機都會同步創建一個堆疊幀，用于存盤區域變數表、運算元堆疊、動態連接、方法出口等資訊，每一個方法被呼叫直至執行完畢的程序，就對應著一個堆疊幀在虛擬機堆疊中從入堆疊到出堆疊的程序，

1.2.2 溢位例外

1）堆疊深度超出設定

如果是創建的堆疊的深度大于虛擬機允許的深度，拋出

Exception in thread "main" java.lang.StackOverflowError

2）記憶體申請不足

如果堆疊允許記憶體擴展，但是記憶體申請不夠的時候，拋出 OutOfMemoryError

注意！這一點和具體的虛擬機有關，hotspot虛擬機并不支持堆疊空間擴展，所以單執行緒環境下，一個執行緒創建時，分配給它固定大小的一個堆疊，在這個固定堆疊空間上不會出現再去擴容申請記憶體的情況，也就不會遇到申請不到一說，只會因為深度問題超出固定空間造成上面的StackOverflowError

如果換成多執行緒，毫無節制的創建執行緒，還是有可能造成OutOfMemoryError，但是這個和Xss堆疊空間大小無關，是因為執行緒個數太多，堆疊的個數太多，導致系統分配給jvm行程的物理記憶體被吃光，

這時候虛擬機會附帶相關的提示：

Exception in thread "main" java.lang.OutOfMemoryError: unable to create native thread

ps: 每個執行緒默認分配1M空間（64位linux，hotspot環境）

疑問：是不是改小Xss的值就可以得到堆疊空間溢位呢？

答：根據上面的分析，hotspot下不可以，還是會拋出StackOverflowError，無非深度更小了，

1.2.3 案例一：進出堆疊順序

1）代碼

package com.itheima.jvm.demo;

/**
 * 程式模擬進堆疊、出堆疊程序
 * 先進后出
 */
public class StackInAndOut {
    /**
     * 定義方法一
     */
    public static void A() {
        System.out.println("進入方法A");
    }

    /**
     * 定義方法二;呼叫方法一
     */
    public static void B() {
        A();
        System.out.println("進入方法B");
    }

    public static void main(String[] args) {

        B();
        System.out.println("進入Main方法");
    }
}

2）運行結果：

進入方法A
進入方法B
進入Main方法

3）堆疊結構：

main方法---->B方法---->A方法
file

1.2.4 案例二：堆疊深度溢位

1）代碼

這個容易實作，方法嵌套自己就可以：

package com.itheima.jvm.demo;

/**
 * 通過一個程式模擬執行緒請求的堆疊深度大于虛擬機所允許的堆疊深度；
 * 拋出StackOverflowError
 */
public class StackOverFlow {
    /**
     * 定義方法，回圈嵌套自己
     */
    public static void B() {
        B();
        System.out.println("進入方法B");
    }

    public static void main(String[] args) {

        B();
        System.out.println("進入Main方法");
    }
}

2）運行結果：

Exception in thread "main" java.lang.StackOverflowError
	at com.itheima.jvm.demo.StackOverFlow.B(StackOverFlow.java:12)
	at com.itheima.jvm.demo.StackOverFlow.B(StackOverFlow.java:12)
	at com.itheima.jvm.demo.StackOverFlow.B(StackOverFlow.java:12)
	at com.itheima.jvm.demo.StackOverFlow.B(StackOverFlow.java:12)
	at com.itheima.jvm.demo.StackOverFlow.B(StackOverFlow.java:12)

3）堆疊結構：

file

1.2.5 案例三：堆疊記憶體溢位

一直不停的創建執行緒就可以堆滿堆疊

但是！這個很危險，到32系統的winxp上勇敢的小伙伴可以試一試，機器卡死不負責！

package com.itheima.jvm.demo;

/*
* 堆疊記憶體溢位，注意！很危險，謹慎執行
* 執行時可能會卡死系統，直到記憶體耗盡
* */
public class StackOutOfMem {
    public static void main(String[] args) {
        while (true) {
            new Thread(() -> {
                while(true);
            }).start();
        }
    }
}

1.3 本地方法堆疊

1.3.1 概述

本地方法堆疊的功能和特點類似于虛擬機堆疊，均具有執行緒隔離的特點
不同的是，本地方法堆疊服務的物件是JVM執行的native方法，而虛擬機堆疊服務的是JVM執行的java方法
虛擬機規范里對這塊所用的語言、資料結構、沒有強制規定，虛擬機可以自由實作它
甚至，hotspot把它和虛擬機堆疊合并成了1個

1.3.2 溢位例外

和虛擬機堆疊一樣，也是兩個：

如果是創建的堆疊的深度大于虛擬機允許的深度，拋出 StackOverFlowError

記憶體申請不夠的時候，拋出 OutOfMemoryError

1.4 堆

1.4.1 概述

與上面的3個不同，堆是所有執行緒共享的！所謂的執行緒安全不安全也是出自這里，

在虛擬機啟動時創建，此記憶體區域的唯一目的就是存放物件實體，Java世界里“幾乎”所有的物件實體都在這里分配記憶體，

需要注意的是，《Java虛擬機規范》并沒有對堆進行細致的劃分，所以對于堆的講解要基于具體的虛擬機，我們以使用最多的HotSpot虛擬機為例，

Java堆是垃圾收集器管理的記憶體區域，因此它也被稱作“GC堆”，這就是我們做JVM調優的重點區域部分，

1.4.2 jdk1.7

jvm的記憶體模型在1.7和1.8有較大的區別，雖然1.7目前使用的較少了，但是我們也是需要對1.7的記憶體模型有所了解，所以接下里，我們將先學習1.7再學習1.8的記憶體模型，

file

Young 年輕區（代）

Young區被劃分為三部分，Eden區和兩個大小嚴格相同的Survivor區

其中，Survivor區間中，某一時刻只有其中一個是被使用的，另外一個留做垃圾收集時復制物件用

在Eden區間變滿的時候， GC就會將存活的物件移到空閑的Survivor區間中，根據JVM的策略，在經過幾次垃圾收集后，任然存活于Survivor的物件將被移動到下面的Tenured區間，
Tenured 年老區

Tenured區主要保存生命周期長的物件，一般是一些老的物件，當一些物件在Young復制轉移一定的次數以后，物件就會被轉移到Tenured區，一般如果系統中用了application級別的快取，快取中的物件往往會被轉移到這一區間，
Perm 永久區

hotspot 1.6 才有這貨，現在已經成為歷史

Perm代主要保存class,method,filed物件，這部份的空間一般不會溢位，除非一次性加載了很多的類，不過在涉及到熱部署的應用服務器的時候，有時候會遇到java.lang.OutOfMemoryError : PermGen space 的錯誤，造成這個錯誤的很大原因就有可能是每次都重新部署，但是重新部署后，類的class沒有被卸載掉，這樣就造成了大量的class物件保存在了perm中，這種情況下，一般重新啟動應用服務器可以解決問題，另外一種可能是創建了大批量的jsp檔案，造成類資訊超出perm的上限而溢位，這種重啟也解決不了，只能調大空間，
Virtual區：

jvm引數可以設定一個范圍，最大記憶體和初始記憶體的差值，就是Virtual區，

1.4.3 jdk1.8

file

由上圖可以看出，jdk1.8的記憶體模型是由2部分組成，年輕代 + 年老代，永久代被干掉，換成了Metaspace（元資料空間）

年輕代：Eden + 2*Survivor （不變）

年老代：OldGen （不變）

元空間：原來的perm區（重點！）

需要特別說明的是：Metaspace所占用的記憶體空間不是在虛擬機內部，而是在本地記憶體空間中，這也是與1.7的永久代最大的區別所在，

file

1.4.4 溢位例外

記憶體不足時，拋出

java.lang.OutOfMemoryError: Java heap space

1.4.5 案例：堆溢位

1）代碼

分配大量物件，超出jvm規定的堆范圍即可

package com.itheima.jvm.demo;

import java.util.ArrayList;
import java.util.List;

/**
 * 堆溢位
 *   -Xms20m -Xmx20m
 */
public class HeapOOM {
    Byte[] bytes = new Byte[1024*1024];
    public static void main(String[] args) {
        List list = new ArrayList();
        int i = 0;
        while (true) {
            System.out.println(++i);
            list.add(new HeapOOM());
        }
    }
}

2）啟動

注意啟動時，指定一下堆的大小：

file

2）輸出

1
2
3
4
5
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
	at com.itheima.jvm.demo.HeapOOM.<init>(HeapOOM.java:7)
	at com.itheima.jvm.demo.HeapOOM.main(HeapOOM.java:13)

1.5 方法區

1.5.1 概述

同樣，執行緒共享的，

它主要用來存盤類的資訊、類里定義的常量、靜態變數、編譯器編譯后的代碼快取，

注意！方法區在虛擬機規范里這是一個邏輯概念，它具體放在那個區域里沒有嚴格的規定，

所以，hotspot 1.7 將它放在了堆的永久代里，1.8+單獨開辟了一塊叫metaspace來存放一部分內容（不是全部！定義的類物件在堆里）

具體方法區主要存什么東西呢？粗略的分，可以劃分為兩類：

類資訊：主要指類相關的版本、欄位、方法、介面描述、參考等
運行時常量池：編譯階段生成的常量與符號參考、運行時加入的動態變數

（常量池里的類變數，如物件或字串，比較特殊，1.6和1.8位置不同，下面會講到）

小提示：

這里經常會跟上面堆里的永久代混為一談，實際上這是兩碼事

永久代是hotspot在1.7及之前才有的設計，1.8+，以及其他虛擬機并不存在這個東西，

可以說，永久代是1.7的hotspot偷懶的結果，他在堆里劃分了一塊來實作方法區的功能，叫永久代，因為這樣可以借助堆的垃圾回收來管理方法區的記憶體，而不用單獨為方法區再去撰寫記憶體管理程式，懶惰！

同時代的其他虛擬機，如J9，Jrockit等，沒有這個概念，后來hotspot認識到，永久代來做這件事不是一個好主意，1.7已經從永久代拿走了一部分資料，直到1.8+徹底去掉了永久代，方法區大部分被移到了metaspace（再強調一下，不是全部！）

結論：

方法區是一定存在的，這是虛擬機規定的，但是是個邏輯概念，在哪里虛擬機自己去決定

而永久代不一定存在（hotspot 1.7 才有），已成為歷史

1.5.2 溢位例外

1.6：OutOfMemoryError: PermGen space

1.8：OutOfMemoryError: Metaspace

1.5.3 案例：1.6方法區溢位

1）原理

file
在1.6里，字串常量是運行時常量池的一部分，也就是歸屬于方法區，放在了永久代里，

所以1.6環境下，讓方法區溢位，只需要可勁造往字串常量池中造字串即可，這里用到一個方法：

/*
如果字串常量池里有這個字串，直接回傳參考，不再額外添加
如果沒有，加進去，回傳新創建的參考
*/
String.intern()

2）代碼

/**
 * 方法區溢位，注意限制一下永久代的大小
 * 編譯的時候注意pom里的版本，要設定1.6，否則啟動會有問題
 * jdk1.6  :     -XX:PermSize=6M -XX:MaxPermSize=6M
 */
public class ConstantOOM {

    public static void main(String[] args) {
        ConstantOOM oom = new ConstantOOM();
        Set<String> stringSet = new HashSet();
        int i = 0;
        while (true) {
            System.out.println(++i);
            stringSet.add(String.valueOf(i).intern());
        }
    }
}

3）創建啟動環境

file

4）例外資訊：

...
19118
19119
19120
Exception in thread "main" java.lang.OutOfMemoryError: PermGen space
	at java.lang.String.intern(Native Method)
	at com.itheima.jvm.demo.ConstantOOM.main(ConstantOOM.java:19)

1.5.4 案例：1.8方法區溢位

1）到了1.8，情況發生了變化

可以測驗一下，1.8下無論指定下面的哪個引數，常量池運行都不會溢位，會一直列印下去

-XX:PermSize=6M -XX:MaxPermSize=6M
-XX:MetaspaceSize=10M -XX:MaxMetaspaceSize=10M

2）配置運行環境

file

3）控制臺資訊

不會拋出例外，只要你jvm堆記憶體夠，理論上可以一直打下去

file

4）為什么呢？

永久代我們加了限制，結果沒意義，因為1.8里已經沒有這貨了

元空間也加了限制，同樣沒意義，那說明字串常量池它不在元空間里！

那么，它在哪里呢？

file

jdk1.8以后，字串常量池被移到了堆空間，和其他物件一樣，接受堆的控制，

其他的運行時的類資訊、基本資料型別等在元空間，

我們可以驗證一下，對上面的運行時引數再加一個堆上限限制：

-Xms10m
-Xmx10m

運行環境如下：

file

運行沒多久，你會得到以下例外:

……
84014
84015
84016
84017
84018
84019
Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded
	at java.lang.Integer.toString(Integer.java:403)
	at java.lang.String.valueOf(String.java:3099)
	at com.itheima.jvm.demo.ConstantOOM.main(ConstantOOM.java:18)

說明：1.8里，字串inter()被放在了堆里，受最大堆空間的限制，

5）那如何才能讓元空間溢位呢？

既然字串常量池不在這里，那就換其他的，類的基本資訊總在元空間吧？我們來試一下

cglib是一個apache下的位元組碼庫，它可以在運行時生成大量的物件，我們while回圈同時限制metaspace試試：

附：https://gitee.com/mirrors/cglib （想深入了解這個工具的猛擊左邊，這里不做過多討論）

package com.itheima.jvm.demo;

import net.sf.cglib.proxy.Enhancer;
import net.sf.cglib.proxy.MethodInterceptor;
import net.sf.cglib.proxy.MethodProxy;

import java.lang.reflect.Method;

/**
 * jdk8方法區溢位
 *   -XX:MetaspaceSize=10M -XX:MaxMetaspaceSize=10M
 */
public class ConstantOOM8 {
    public static void main(final String[] args) {
        while (true) {
            Enhancer enhancer = new Enhancer();
            enhancer.setSuperclass(OOM.class);
            enhancer.setUseCache(false);
            enhancer.setCallback(new MethodInterceptor() {
                @Override
                public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable {
                    return methodProxy.invokeSuper(objects,args);
                }
            });
            enhancer.create();
        }
    }

    static class OOM{

    }
}

6）運行設定

file

7）運行結果

Caused by: java.lang.OutOfMemoryError: Metaspace
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:763)

結論：

jdk8引入元空間來存盤方法區后，記憶體溢位的風險比歷史版本小多了，但是在類超出控制的時候，依然會打爆方法區

1.6 一個案例

為便于大家理解和記憶，下面我們用一個案例，把上面各個區串通起來，

假設有個Bootstrap的類，執行main方法，在jvm里，它從class檔案到跑起來，大致經過如下步驟：

file

首先JVM會先將這個Bootstrap.class 資訊加載到記憶體中的方法區
接著，主執行緒開辟一塊記憶體空間，準備好程式計數器pc，虛擬機堆疊、本地方法堆疊
然后，JVM會在Heap堆上為Bootstrap.class 創建一個Bootstrap.class 的類實體
JVM開始執行main方法，這時在虛擬機堆疊里為main方法創建一個堆疊幀
main方法在執行的程序之中，呼叫了greeting方法，則JVM會為greeting方法再創建一個堆疊幀，推到虛擬機堆疊頂，在main的上面，每次只有一個堆疊幀處于活動狀態，當前為greeting
當greeting方法運行完成后，則greeting方法出堆疊，當前活動幀指向main，方法繼續往下運行

1.7 歸納總結

file

1）獨享/共享的角度：

獨享：程式計數器、虛擬機堆疊、本地方法堆疊
共享：堆、方法區

2）error的角度：

程式計數器：不會溢位，比較特殊，其他都會
兩個堆疊：可能會發生兩種溢位，一是深度超了，報StackOverflowError，空間不足：OutOfMemoryError
堆：只會在空間不足時，報OutOfMemoryError，會提示heapSpace
方法區：空間不足時，報OutOfMemoryError，提示不同，1.6是permspace，1.8是元空間，和它在什么地方有關

3）歸屬：

計數器、虛擬機堆疊、本地方法堆疊：執行緒創建必須申請配套，真正的物理空間
堆：真正的物理空間，但是內部結構的劃分有變動，1.6有永久代，1.8被干掉
方法區：最沒歸屬感的一塊，原因就是它是一個邏輯概念，1.6被放在了堆的永久代，1.8被拆分，一部分在元空間，一部分（方法區的運行時常量池里面的類物件，包括字串常量，被設計放在了堆里）
直接記憶體：這塊實際上不屬于運行時資料區的一部分，而是直接操作物理記憶體，在nio操作里DirectByteBuffer類可以對native操作，避免流在堆內外的拷貝，我們下一步的調優不會涉及到它，了解即可，

本文由傳智教育博學谷教研團隊發布，

如果本文對您有幫助，歡迎關注和點贊；如果您有任何建議也可留言評論或私信，您的支持是我堅持創作的動力，

轉載請注明出處！

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/538124.html

標籤：Java

上一篇：動態規劃篇——背包問題

下一篇：Spring Boot 多資料源配置

JVM運行資料區深度決議

運行資料區

1.1 程式計數器

1.1.1 概述

1.1.2 溢位例外

1.1.3 案例

1.2 虛擬機堆疊

1.2.1 概述

1.2.2 溢位例外

1.2.3 案例一：進出堆疊順序

1.2.4 案例二：堆疊深度溢位

1.2.5 案例三：堆疊記憶體溢位

1.3 本地方法堆疊

1.3.1 概述

1.3.2 溢位例外

1.4 堆

1.4.1 概述

1.4.2 jdk1.7

1.4.3 jdk1.8

1.4.4 溢位例外

1.4.5 案例：堆溢位

1.5 方法區

1.5.1 概述

1.5.2 溢位例外

1.5.3 案例：1.6方法區溢位

1.5.4 案例：1.8方法區溢位

1.6 一個案例

1.7 歸納總結