第 9 章方法區

微信搜一搜: 全堆疊小劉，獲取文章全套 pdf版

1、堆疊堆方法區的互動關系

從記憶體結構來看

這次所講述的是運行時資料區的最后一個部分

從執行緒共享與否的角度來看

ThreadLocal：如何保證多個執行緒在并發環境下的安全性？典型應用就是資料庫連接管理，以及獨立會話管理

堆疊、堆、方法區的互動關系

下面就涉及了物件的訪問定位

Person 類的 .class 資訊存放在方法區中
person 變數存放在 Java 堆疊的區域變數表中
真正的 person 物件存放在 Java 堆中
在 person 物件中，有個指標指向方法區中的 person 型別資料，表明這個 person 物件是用方法區中的 Person 類 new 出來的

2、方法區的理解

官方檔案

https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-2.html#jvms-2.5.4

2.1、方法去的位置

方法區的位置

《Java虛擬機規范》中明確說明：盡管所有的方法區在邏輯上是屬于堆的一部分，但一些簡單的實作可能不會選擇去進行垃圾收集或者進行壓縮，
但對于HotSpotJVM而言， 方法區還有一個別名叫做Non-Heap（非堆），目的就是要和堆分開，
所以， 方法區可以看作是一塊獨立于Java堆的記憶體空間，

2.2、方法區的理解

方法區的基本理解

方法區主要存放的是 Class，而堆中主要存放的是實體化的物件

方法區（Method Area）與Java堆一樣，是 各個執行緒共享的記憶體區域
多個執行緒同時加載統一個類時，只能有一個執行緒能加載該類，其他執行緒只能等等待該執行緒加載完畢，然后直接使用該類，即 類只能加載一次，
方法區在JVM啟動的時候被創建，并且它的實際的物理記憶體空間中和Java堆區一樣都可以是不連續的，
方法區的大小，跟堆空間一樣，可以選擇 固定大小或者可擴展，
方法區的大小決定了系統可以保存多少個類，如果系統定義了太多的類，導致方法區溢位，虛擬機同樣會拋出記憶體溢位錯誤：

java.lang.OutofMemoryError:PermGen space
或者
java.lang.OutOfMemoryError:Metaspace

舉例說明方法區 OOM

加載大量的第三方的jar包
Tomcat部署的工程過多（30~50個）
大量動態的生成反射類

關閉JVM就會釋放這個區域的記憶體，

代碼舉例

代碼

public class EdenSurvivorTest {
    public static void main(String[] args) {
        System.out.println("我只是來打個醬油~");
        try {
            Thread.sleep(1000000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

簡單的程式，加載了好多類

2.3、方法區演程序序

Hotspot 方法區的演程序序

在 JDK7 及以前，習慣上把方法區，稱為永久代，JDK8開始，使用元空間取代了永久代，JDK 1.8后，元空間存放在 堆外記憶體中
我們可以將方法區類比為Java中的介面，將永久代或元空間類比為Java中具體的實作類
本質上，方法區和永久代并不等價，僅是對Hotspot而言的可以看作等價，《Java虛擬機規范》對如何實作方法區，不做統一要求，例如：BEAJRockit / IBM J9 中不存在永久代的概念，
現在來看，當年使用永久代，不是好的idea，導致Java程式更容易OOm（超過-XX:MaxPermsize上限）
而到了JDK8，終于完全廢棄了永久代的概念，改用與JRockit、J9一樣在本地記憶體中實作的元空間（Metaspace）來代替
元空間的本質和永久代類似，都是對JVM規范中方法區的實作，不過元空間與永久代最大的區別在于： 元空間不在虛擬機設定的記憶體中，而是使用本地記憶體
永久代、元空間二者并不只是名字變了， 內部結構也調整了
根據《Java虛擬機規范》的規定，如果方法區無法滿足新的記憶體分配需求時，將拋出OOM例外

3、設定方法區大小與 OOM

方法區的大小不必是固定的，JVM可以根據應用的需要動態調整，

3.1、JDK7 永久代

JDK7 之前版本設定永久代大小

通過-XX:Permsize來設定永久代初始分配空間，默認值是20.75M
-XX:MaxPermsize來設定永久代最大可分配空間，32位機器默認是64M，64位機器模式是82M
當JVM加載的類資訊容量超過了這個值，會報例外OutofMemoryError:PermGen space，

3.2、JDK8 元空間

JDK8 版本設定元空間大小

元資料區大小可以使用引數 -XX:MetaspaceSize 和 -XX:MaxMetaspaceSize 指定
默認值依賴于平臺，Windows下，-XX:MetaspaceSize 約為21M， -XX:MaxMetaspaceSize的值是-1，即沒有限制，
與永久代不同，如果不指定大小，默認情況下，虛擬機會耗盡所有的可用系統記憶體，如果元資料區發生溢位，虛擬機一樣會拋出例外OutOfMemoryError:Metaspace
-XX:MetaspaceSize：設定初始的元空間大小，對于一個 64位的服務器端 JVM 來說，其默認的 -XX:MetaspaceSize值為21MB，這就是初始的高水位線，一旦觸及這個水位線，Full GC將會被觸發并卸載沒用的類（即這些類對應的類加載器不再存活）， 然后這個高水位線將會重置，新的高水位線的值取決于GC后釋放了多少元空間，

如果釋放的空間不足，那么在不超過MaxMetaspaceSize時，適當提高該值，
如果釋放空間過多，則適當降低該值，

如果初始化的高水位線設定過低，上述高水位線調整情況會發生很多次，通過垃圾回收器的日志可以觀察到Full GC多次呼叫， 為了避免頻繁地GC，建議將-XX:MetaspaceSize設定為一個相對較高的值，

配置元空間大小示例

代碼


public class MethodAreaDemo {
    public static void main(String[] args) {
        System.out.println("start...");
        try {
            Thread.sleep(1000000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        System.out.println("end...");
    }
}

JVM 引數

-XX:MetaspaceSize=100m  -XX:MaxMetaspaceSize=100m

CMD 命令查看設定的元空間大小

C:\Users\Heygo>jps
C:\Users\Heygo>jinfo -flag MetaspaceSize pId
C:\Users\Heygo>jinfo -flag MaxMetaspaceSize pId

3.3、方法區 OOM

方法區 OOM 舉例

代碼：OOMTest 類繼承 ClassLoader 類，獲得 defineClass() 方法，可自己進行類的加載


public class OOMTest extends ClassLoader {
    public static void main(String[] args) {
        int j = 0;
        try {
            OOMTest test = new OOMTest();
            for (int i = 0; i < 10000; i++) {

                ClassWriter classWriter = new ClassWriter(0);

                classWriter.visit(Opcodes.V1_6, Opcodes.ACC_PUBLIC, "Class" + i, null, "java/lang/Object", null);

                byte[] code = classWriter.toByteArray();

                test.defineClass("Class" + i, code, 0, code.length);
                j++;
            }
        } finally {
            System.out.println(j);
        }
    }
}

不設定元空間的上限

使用默認的 JVM 引數，元空間不設定上限

設定元空間的上限

JVM 引數

-XX:MetaspaceSize=10m -XX:MaxMetaspaceSize=10m

元空間出現 OOM

com.atguigu.java.OOMTest
Exception in thread "main" java.lang.OutOfMemoryError: Metaspace
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:642)
	at com.atguigu.java.OOMTest.main(OOMTest.java:29)
8531

3.4、解決 OOM

如何解決 OOM？

要解決OOM例外或heap space的例外，一般的手段是首先通過記憶體映像分析工具（如Ec1ipse Memory Analyzer）對dump出來的堆轉儲快照進行分析，重點是確認記憶體中的物件是否是必要的，也就是要先分清楚到底是出現了記憶體泄漏（Memory Leak）還是記憶體溢位（Memory Overflow）
記憶體泄漏就是有大量的參考指向某些物件，但是這些物件以后不會使用了，但是因為它們還和GC ROOT有關聯，所以導致以后這些物件也不會被回收，這就是記憶體泄漏的問題
如果是記憶體泄漏，可進一步通過工具查看泄漏物件到GC Roots的參考鏈，于是就能 找到泄漏物件是通過怎樣的路徑與GC Roots相關聯并導致垃圾收集器無法自動回收它們的，掌握了泄漏物件的型別資訊，以及GC Roots參考鏈的資訊，就可以比較準確地定位出泄漏代碼的位置，
如果不存在記憶體泄漏，換句話說就是記憶體中的物件確實都還必須存活著，那就應當檢查虛擬機的堆引數（-Xmx與-Xms），與機器物理記憶體對比看是否還可以調大，從代碼上檢查是否存在某些物件生命周期過長、持有狀態時間過長的情況，嘗試減少程式運行期的記憶體消耗，

4、方法區的內部結構

4.1、方法區結構

方法區（Method Area）存盤什么？

《深入理解Java虛擬機》書中對方法區（Method Area）存盤內容描述如下：它用于存盤已被虛擬機 加載的型別資訊、常量、靜態變數、即時編譯器編譯后的代碼快取等，

型別資訊

對每個加載的型別（類class、介面interface、列舉enum、注解annotation），JVM必須在方法區中存盤以下型別資訊：

這個型別的完整有效名稱（全名=包名.類名）
這個型別直接父類的完整有效名（對于interface或是java.lang.Object，都沒有父類）
這個型別的修飾符（public，abstract，final的某個子集）
這個型別直接介面的一個有序串列

域（Field）資訊

JVM必須在方法區中保存型別的所有域的相關資訊以及域的宣告順序，
域的相關資訊包括：

域名稱
域型別
域修飾符（public，private，protected，static，final，volatile，transient的某個子集）

方法（Method）資訊

JVM必須保存所有方法的以下資訊，同域資訊一樣包括宣告順序：

方法名稱
方法的回傳型別（包括 void 回傳型別），void 在 Java 中對應的類為 void.class
方法引數的數量和型別（按順序）
方法的修飾符（public，private，protected，static，final，synchronized，native，abstract的一個子集）
方法的位元組碼（bytecodes）、運算元堆疊、區域變數表及大小（abstract和native方法除外）
例外表（abstract和native方法除外），例外表記錄每個例外處理的開始位置、結束位置、代碼處理在程式計數器中的偏移地址、被捕獲的例外類的常量池索引

代碼示例

代碼


public class MethodInnerStrucTest extends Object implements Comparable<String>, Serializable {

    public int num = 10;
    private static String str = "測驗方法的內部結構";

    public void test1() {
        int count = 20;
        System.out.println("count = " + count);
    }

    public static int test2(int cal) {
        int result = 0;
        try {
            int value = https://www.cnblogs.com/spiritmark/p/30;
            result = value / cal;
        } catch (Exception e) {
            e.printStackTrace();
        }
        return result;
    }

    @Override
    public int compareTo(String o) {
        return 0;
    }
}

反編譯位元組碼檔案，并輸出值文本檔案中，便于查看
引數 -p 確保能查看 private 權限型別的欄位或方法

javap -v -p MethodInnerStrucTest.class > Text.txt

型別資訊

插句嘴：在運行時方法區中，類資訊中記錄了哪個加載器加載了該類，同時類加載器也記錄了它加載了哪些類
從反編譯檔案可以看出，位元組碼檔案記錄了 MethodInnerStrucTest 繼承了哪些類，實作了哪些方法

public class com.atguigu.java.MethodInnerStrucTest
	extends java.lang.Object
	implements java.lang.Comparable<java.lang.string>, java.io.Serializable
</java.lang.string>

域資訊

descriptor: I 表示欄位型別為 Integer
flags: ACC_PUBLIC 表示欄位權限修飾符為 public

  public int num;
    descriptor: I
    flags: ACC_PUBLIC

  private static java.lang.String str;
    descriptor: Ljava/lang/String;
    flags: ACC_PRIVATE, ACC_STATIC

方法資訊

descriptor: ()V 表示方法回傳值型別為 void
flags: ACC_PUBLIC 表示方法權限修飾符為 public
stack=3 表示運算元堆疊深度為 3
locals=2 表示區域變數個數為 2 個（實力方法包含 this）
test1() 方法雖然沒有引數，但是其 args_size=1 ，這時因為將 this 作為了引數

  public void test1();
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=3, locals=2, args_size=1
         0: bipush        20
         2: istore_1
         3: getstatic     #3                  // Field java/lang/System.out:Ljava/io/PrintStream;
         6: new           #4                  // class java/lang/StringBuilder
         9: dup
        10: invokespecial #5                  // Method java/lang/StringBuilder."<init>":()V
        13: ldc           #6                  // String count =
        15: invokevirtual #7                  // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
        18: iload_1
        19: invokevirtual #8                  // Method java/lang/StringBuilder.append:(I)Ljava/lang/StringBuilder;
        22: invokevirtual #9                  // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
        25: invokevirtual #10                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
        28: return
      LineNumberTable:
        line 17: 0
        line 18: 3
        line 19: 28
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0      29     0  this   Lcom/atguigu/java/MethodInnerStrucTest;
            3      26     1 count   I
</init>

4.2、域資訊特殊情況

non-final 型別的類變數

靜態變數和類關聯在一起，隨著類的加載而加載，他們成為類資料在邏輯上的一部分
類變數被類的所有實體共享，即使沒有類實體時，你也可以訪問它

代碼示例

如下代碼所示，即使我們把order設定為null，也不會出現空指標例外
這更加表明了 static 型別的欄位和方法隨著類的加載而加載，并不屬于特定的類實體


public class MethodAreaTest {
    public static void main(String[] args) {
        Order order = null;
        order.hello();
        System.out.println(order.count);
    }
}

class Order {
    public static int count = 1;
    public static final int number = 2;

    public static void hello() {
        System.out.println("hello!");
    }
}

hello!

1

全域常量：static final

全域常量就是使用 static final 進行修飾
被宣告為final的類變數的處理方法則不同，每個全域常量在編譯的時候就會被分配了，

代碼示例

代碼


public class MethodAreaTest {
    public static void main(String[] args) {
        Order order = null;
        order.hello();
        System.out.println(order.count);
    }
}

class Order {
    public static int count = 1;
    public static final int number = 2;

    public static void hello() {
        System.out.println("hello!");
    }
}

反編譯，查看位元組碼指令，可以發現 number 的值已經寫死在位元組碼檔案中了

  public static int count;
    descriptor: I
    flags: ACC_PUBLIC, ACC_STATIC

  public static final int number;
    descriptor: I
    flags: ACC_PUBLIC, ACC_STATIC, ACC_FINAL
    ConstantValue: int 2

4.3、運行時常量池

運行時常量池 VS 常量池

官方檔案

https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html

方法區，內部包含了運行時常量池
位元組碼檔案，內部包含了常量池
要弄清楚方法區，需要理解清楚ClassFile，因為加載類的資訊都在方法區，
要弄清楚方法區的運行時常量池，需要理解清楚ClassFile中的常量池，

常量池

一個有效的位元組碼檔案中除了包含類的版本資訊、欄位、方法以及介面等描述符資訊外
還包含一項資訊就是 常量池表（ Constant Pool Table），包括 各種字面量和對型別、域和方法的符號參考

為什么需要常量池？

一個java源檔案中的類、介面，編譯后產生一個位元組碼檔案，而Java中的位元組碼需要資料支持，通常這種資料會很大以至于不能直接存到位元組碼里，換另一種方式，可以存到常量池
這個位元組碼包含了指向常量池的參考，在動態鏈接的時候會用到運行時常量池，之前有介紹

比如：如下的代碼：

public class SimpleClass {
    public void sayHello() {
        System.out.println("hello");
    }
}

雖然上述代碼只有194位元組，但是里面卻使用了String、System、PrintStream及Object等結構，
如果不使用常量池，就需要將用到的類資訊、方法資訊等記錄在當前的位元組碼檔案中，造成檔案臃腫
所以我們將所需用到的結構資訊記錄在常量池中，并通過 參考的方式，來加載、呼叫所需的結構
這里的代碼量其實很少了，如果代碼多的話，參考的結構將會更多，這里就需要用到常量池了，

常量池中有啥？

數量值
字串值
類參考
欄位參考
方法參考

常量池代碼舉例

代碼


public class MethodInnerStrucTest extends Object implements Comparable<String>, Serializable {

    public int num = 10;
    private static String str = "測驗方法的內部結構";

    public void test1() {
        int count = 20;
        System.out.println("count = " + count);
    }

    public static int test2(int cal) {
        int result = 0;
        try {
            int value = https://www.cnblogs.com/spiritmark/p/30;
            result = value / cal;
        } catch (Exception e) {
            e.printStackTrace();
        }
        return result;
    }

    @Override
    public int compareTo(String o) {
        return 0;
    }
}

來看下最簡單的 test1() 方法，帶 # 的位元組碼指令，就使用了常量池的參考
通過位元組碼指令可以看出， *拼接字串時，編譯器幫我們造了個 StringBuilder 物件，然后呼叫其 append() 方法完成了字串的拼接

  public void test1();
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=3, locals=2, args_size=1
         0: bipush        20
         2: istore_1
         3: getstatic     #3                  // Field java/lang/System.out:Ljava/io/PrintStream;
         6: new           #4                  // class java/lang/StringBuilder
         9: dup
        10: invokespecial #5                  // Method java/lang/StringBuilder."<init>":()V
        13: ldc           #6                  // String count =
        15: invokevirtual #7                  // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
        18: iload_1
        19: invokevirtual #8                  // Method java/lang/StringBuilder.append:(I)Ljava/lang/StringBuilder;
        22: invokevirtual #9                  // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
        25: invokevirtual #10                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
        28: return
      LineNumberTable:
        line 20: 0
        line 21: 3
        line 22: 28
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0      29     0  this   Lcom/atguigu/java/MethodInnerStrucTest;
            3      26     1 count   I

</init>

常量池

Constant pool:
   #1 = Methodref          #18.#52        // java/lang/Object."<init>":()V
   #2 = Fieldref           #17.#53        // com/atguigu/java/MethodInnerStrucTest.num:I
   #3 = Fieldref           #54.#55        // java/lang/System.out:Ljava/io/PrintStream;
   #4 = Class              #56            // java/lang/StringBuilder
   #5 = Methodref          #4.#52         // java/lang/StringBuilder."<init>":()V
   #6 = String             #57            // count =
   #7 = Methodref          #4.#58         // java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
   #8 = Methodref          #4.#59         // java/lang/StringBuilder.append:(I)Ljava/lang/StringBuilder;
   #9 = Methodref          #4.#60         // java/lang/StringBuilder.toString:()Ljava/lang/String;
  #10 = Methodref          #61.#62        // java/io/PrintStream.println:(Ljava/lang/String;)V
  #11 = Class              #63            // java/lang/Exception
  #12 = Methodref          #11.#64        // java/lang/Exception.printStackTrace:()V
  #13 = Class              #65            // java/lang/String
  #14 = Methodref          #17.#66        // com/atguigu/java/MethodInnerStrucTest.compareTo:(Ljava/lang/String;)I
  #15 = String             #67            // &#x6D4B;&#x8BD5;&#x65B9;&#x6CD5;&#x7684;&#x5185;&#x90E8;&#x7ED3;&#x6784;
  #16 = Fieldref           #17.#68        // com/atguigu/java/MethodInnerStrucTest.str:Ljava/lang/String;
  #17 = Class              #69            // com/atguigu/java/MethodInnerStrucTest
  #18 = Class              #70            // java/lang/Object
  #19 = Class              #71            // java/lang/Comparable
  #20 = Class              #72            // java/io/Serializable
  #21 = Utf8               num
  #22 = Utf8               I
  #23 = Utf8               str
  #24 = Utf8               Ljava/lang/String;
  #25 = Utf8               <init>
  #26 = Utf8               ()V
  #27 = Utf8               Code
  #28 = Utf8               LineNumberTable
  #29 = Utf8               LocalVariableTable
  #30 = Utf8               this
  #31 = Utf8               Lcom/atguigu/java/MethodInnerStrucTest;
  #32 = Utf8               test1
  #33 = Utf8               count
  #34 = Utf8               test2
  #35 = Utf8               (I)I
  #36 = Utf8               value
  #37 = Utf8               e
  #38 = Utf8               Ljava/lang/Exception;
  #39 = Utf8               cal
  #40 = Utf8               result
  #41 = Utf8               StackMapTable
  #42 = Class              #63            // java/lang/Exception
  #43 = Utf8               compareTo
  #44 = Utf8               (Ljava/lang/String;)I
  #45 = Utf8               o
  #46 = Utf8               (Ljava/lang/Object;)I
  #47 = Utf8               <clinit>
  #48 = Utf8               Signature
  #49 = Utf8               Ljava/lang/Object;Ljava/lang/Comparable<ljava lang string;>;Ljava/io/Serializable;
  #50 = Utf8               SourceFile
  #51 = Utf8               MethodInnerStrucTest.java
  #52 = NameAndType        #25:#26        // "<init>":()V
  #53 = NameAndType        #21:#22        // num:I
  #54 = Class              #73            // java/lang/System
  #55 = NameAndType        #74:#75        // out:Ljava/io/PrintStream;
  #56 = Utf8               java/lang/StringBuilder
  #57 = Utf8               count =
  #58 = NameAndType        #76:#77        // append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
  #59 = NameAndType        #76:#78        // append:(I)Ljava/lang/StringBuilder;
  #60 = NameAndType        #79:#80        // toString:()Ljava/lang/String;
  #61 = Class              #81            // java/io/PrintStream
  #62 = NameAndType        #82:#83        // println:(Ljava/lang/String;)V
  #63 = Utf8               java/lang/Exception
  #64 = NameAndType        #84:#26        // printStackTrace:()V
  #65 = Utf8               java/lang/String
  #66 = NameAndType        #43:#44        // compareTo:(Ljava/lang/String;)I
  #67 = Utf8               &#x6D4B;&#x8BD5;&#x65B9;&#x6CD5;&#x7684;&#x5185;&#x90E8;&#x7ED3;&#x6784;
  #68 = NameAndType        #23:#24        // str:Ljava/lang/String;
  #69 = Utf8               com/atguigu/java/MethodInnerStrucTest
  #70 = Utf8               java/lang/Object
  #71 = Utf8               java/lang/Comparable
  #72 = Utf8               java/io/Serializable
  #73 = Utf8               java/lang/System
  #74 = Utf8               out
  #75 = Utf8               Ljava/io/PrintStream;
  #76 = Utf8               append
  #77 = Utf8               (Ljava/lang/String;)Ljava/lang/StringBuilder;
  #78 = Utf8               (I)Ljava/lang/StringBuilder;
  #79 = Utf8               toString
  #80 = Utf8               ()Ljava/lang/String;
  #81 = Utf8               java/io/PrintStream
  #82 = Utf8               println
  #83 = Utf8               (Ljava/lang/String;)V
  #84 = Utf8               printStackTrace
</init></ljava></clinit></init></init></init>

常量池總結

常量池、可以看做是一張表，虛擬機指令根據這張常量表找到要執行的類名、方法名、引數型別、字面量等型別

運行時常量池

運行時常量池（Runtime Constant Pool）是方法區的一部分，
常量池表（Constant Pool Table）是Class位元組碼檔案的一部分，用于存放編譯期生成的各種字面量與符號參考，這部分內容將在類加載后存放到方法區的運行時常量池中，
運行時常量池，在加載類和介面到虛擬機后，就會創建對應的運行時常量池，
JVM為每個已加載的型別（類或介面）都維護一個常量池，池中的資料項像陣列項一樣，是通過索引訪問的，
運行時常量池中包含多種不同的常量，包括編譯期就已經明確的數值字面量，也包括到運行期決議后才能夠獲得的方法或者欄位參考， 此時不再是常量池中的符號地址了，這里換為真實地址，
運行時常量池，相對于Class檔案常量池的另一重要特征是：具備動態性，
運行時常量池類似于傳統編程語言中的符號表（symbol table），但是它所包含的資料卻比符號表要更加豐富一些，
當創建類或介面的運行時常量池時，如果構造運行時常量池所需的記憶體空間超過了方法區所能提供的最大值，則JVM會拋OutofMemoryError例外，

5、方法區的使用舉例

方法區圖解示例

代碼


public class MethodAreaDemo {
    public static void main(String[] args) {
        int x = 500;
        int y = 100;
        int a = x / y;
        int b = 50;
        System.out.println(a + b);
    }
}

圖解位元組碼指令執行流程

位元組碼執行程序展示：初始狀態

首先將運算元500壓入運算元堆疊中

然后運算元 500 從運算元堆疊中取出，存盤到區域變數表中索引為 1 的位置

然后運算元 100 從運算元堆疊中取出，存盤到區域變數表中索引為 2 的位置

將運算元 100 從

讀取本地變數 1 ，壓入運算元堆疊

讀取本地變數 2 ，壓入運算元堆疊

兩數相除，計算結果放在運算元堆疊頂，之后執行 istore_3 指令，將計算結果從運算元堆疊中彈出，存入區域變數 3 中

將運算元 50 壓入運算元堆疊

將運算元 50 從堆疊頂彈出，保存在區域變數 4 中

獲取 System.out 輸出流的參考（我不太確定）

將本地變數 3 的值取出，壓入運算元堆疊中，準備進行加法運算

執行加法運算后，將計算結果放在運算元堆疊頂

呼叫靜態方法 println() ，輸出加法結果

main() 方法執行結束

關于【符號參考 --> 直接飲用】的理解

上面代碼呼叫 System.out.println() 方法時，首先需要看看 System 類有沒有加載，再看看 PrintStream 類有沒有加載
如果沒有加載，則執行加載， 執行時，將常量池中的符號參考（字面量）轉換為直接參考（真正的地址值）

關于程式計數器的說明

程式計數器始終計算的都是當前代碼運行的位置，目的是為了方便記錄方法呼叫后能夠正常回傳，或者是進行了CPU切換后，也能回來到原來的代碼進行執行，

6、方法區演進細節

6.1、永久代演程序序

關于永久代的說明

首先明確：只有Hotspot才有永久代，
BEA JRockit、IBMJ9等來說，是不存在永久代的概念的，原則上如何實作方法區屬于虛擬機實作細節，不受《Java虛擬機規范》管束，并不要求統一
Hotspot中方法區的變化：

JDK 版本演變細節JDK1.6及以前有永久代（permanent generation），靜態變數存盤在永久代上JDK1.7有永久代，但已經逐步 "去永久代"，
字串常量池，靜態變數移除，保存在堆中

JDK1.8無永久代，型別資訊，欄位，方法，常量保存在本地記憶體的元空間，但字串常量池、靜態變數仍然在堆中，

JDK6

方法區由永久代實作，使用 JVM 虛擬機記憶體

JDK7

方法區由永久代實作，使用 JVM 虛擬機記憶體

JDK8

方法區由元空間實作，使用物理機本地記憶體

6.2、元空間出現原因

永久代為什么要被元空間替代？

官方檔案

http://openjdk.java.net/jeps/122

官方的牽強解釋：JRockit是和HotSpot融合后的結果，因為JRockit沒有永久代，所以他們不需要配置永久代
隨著Java8的到來，HotSpot VM中再也見不到永久代了，但是這并不意味著類的元資料資訊也消失了，這些資料被移到了一個與堆不相連的本地記憶體區域，這個區域叫做元空間（Metaspace），

由于類的元資料分配在本地記憶體中，元空間的最大可分配空間就是系統可用記憶體空間，這項改動是很有必要的，原因有：

為永久代設定空間大小是很難確定的，

在某些場景下，如果動態加載類過多，容易產生Perm區的OOM，比如某個實際Web工
程中，因為功能點比較多，在運行程序中，要不斷動態加載很多類，經常出現致命錯誤， Exception in thread 'dubbo client x.x connector' java.lang.OutOfMemoryError:PermGen space
而元空間和永久代之間最大的區別在于： 元空間并不在虛擬機中，而是使用本地記憶體，
因此， 默認情況下，元空間的大小僅受本地記憶體限制，

對永久代進行調優是很困難的，

方法區的垃圾收集主要回收兩部分內容：常量池中廢棄的常量和不再用的型別，方法區的調優主要是為了降低Full GC
有些人認為方法區（如HotSpot虛擬機中的元空間或者永久代）是沒有垃圾收集行為的，其實不然，《Java虛擬機規范》對方法區的約束是非常寬松的，提到過可以不要求虛擬機在方法區中實作垃圾收集，事實上也確實有未實作或未能完整實作方法區型別卸載的收集器存在（如JDK11時期的ZGC收集器就不支持類卸載），
一般來說這個區域的回收效果比較難令人滿意，尤其是型別的卸載，條件相當苛刻，但是這部磁區域的回收有時又確實是必要的，以前Sun公司的Bug串列中，曾出現過的若干個嚴重的Bug就是由于低版本的HotSpot虛擬機對此區域未完全回收而導致記憶體泄漏

6.3、字串常量池

字串常量池 StringTable 為什么要調整位置？

JDK7中將StringTable放到了堆空間中，因為永久代的回收效率很低，在Full GC的時候才會執行永久代的垃圾回收，而Full GC是老年代的空間不足、永久代不足時才會觸發，
這就 導致StringTable回收效率不高，而我們開發中會有大量的字串被創建，回收效率低，導致永久代記憶體不足， 放到堆里，能及時回收記憶體，

6.4、靜態變數位置

靜態變數存放在那里？

代碼示例 1

代碼


public class StaticFieldTest {
    private static byte[] arr = new byte[1024 * 1024 * 100];

    public static void main(String[] args) {
        System.out.println(StaticFieldTest.arr);
    }
}

運行環境 JDK8 ，JVM 引數

-Xms200m -Xmx200m -XX:MetaspaceSize=300m -XX:MaxMetaspaceSize=300m -XX:+PrintGCDetails

通過 GC 日志可以看出： 靜態變數參考對應的物件物體始終都存在堆空間（arr 陣列物件直接懟到老年區去了）

[B@4554617c
Heap
 PSYoungGen      total 59904K, used 5171K [0x00000000fbd80000, 0x0000000100000000, 0x0000000100000000)
  eden space 51712K, 10% used [0x00000000fbd80000,0x00000000fc28ceb0,0x00000000ff000000)
  from space 8192K, 0% used [0x00000000ff800000,0x00000000ff800000,0x0000000100000000)
  to   space 8192K, 0% used [0x00000000ff000000,0x00000000ff000000,0x00000000ff800000)
 ParOldGen       total 136704K, used 102400K [0x00000000f3800000, 0x00000000fbd80000, 0x00000000fbd80000)
  object space 136704K, 74% used [0x00000000f3800000,0x00000000f9c00010,0x00000000fbd80000)
 Metaspace       used 3473K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 381K, capacity 388K, committed 512K, reserved 1048576K

代碼示例 2

代碼


public class StaticObjTest {
    static class Test {
        static ObjectHolder staticObj = new ObjectHolder();
        ObjectHolder instanceObj = new ObjectHolder();

        void foo() {
            ObjectHolder localObj = new ObjectHolder();
            System.out.println("done");
        }
    }

    private static class ObjectHolder {
    }

    public static void main(String[] args) {
        Test test = new StaticObjTest.Test();
        test.foo();
    }
}

可以使用 JHSDB.exe，在JDK9的時候才引入的
分析：staticObj隨著Test的型別資訊存放在方法區，instanceObj隨著Test的物件實體存放在Java堆，localObject則是存放在foo()方法堆疊幀的區域變數表中，
測驗發現：三個物件的資料在記憶體中的地址都落在Eden區范圍內，所以結論： 只要是物件實體必然會在Java堆中分配，

接著，找到了一個參考該staticObj物件的地方，是在一個java.lang.Class的實體里，并且給出了這個實體的地址，通過Inspector查看該物件實體，可以清楚看到這確實是一個java.lang.Class型別的物件實體，里面有一個名為staticobj的實體欄位：

從《Java虛擬機規范》所定義的概念模型來看，所有Class相關的資訊都應該存放在方法區之中，但方法區該如何實作，《Java虛擬機規范》并未做出規定，這就成了一件允許不同虛擬機自己靈活把握的事情，JDK7及其以后版本的HotSpot虛擬機選擇把靜態變數與型別在Java語言一端的映射Class物件存放在一起， 存盤于Java堆之中，從我們的實驗中也明確驗證了這一點

7、方法區的垃圾回收

方法區垃圾收集

有些人認為方法區（如Hotspot虛擬機中的元空間或者永久代）是沒有垃圾收集行為的，其實不然，
《Java虛擬機規范》對方法區的約束是非常寬松的，提到過可以不要求虛擬機在方法區中實作垃圾收集，事實上也確實有未實作或未能完整實作方法區型別卸載的收集器存在（如JDK11時期的ZGC收集器就不支持類卸載），
一般來說這個區域的回收效果比較難令人滿意，尤其是型別的卸載，條件相當苛刻，但是這部磁區域的回收有時又確實是必要的，以前sun公司的Bug串列中，曾出現過的若干個嚴重的Bug就是由于低版本的HotSpot虛擬機對此區域未完全回收而導致記憶體泄漏，
方法區的垃圾收集主要回收兩部分內容： 常量池中廢棄的常量和不再使用的型別，

方法區常量的回收

先來說說方法區內常量池之中主要存放的兩大類常量：字面量和符號參考

字面量比較接近Java語言層次的常量概念，如文本字串、被宣告為final的常量值等
而符號參考則屬于編譯原理方面的概念，包括下面三類常量：
- 類和介面的全限定名
- 欄位的名稱和描述符
- 方法的名稱和描述符

HotSpot虛擬機對常量池的回收策略是很明確的，只要常量池中的常量沒有被任何地方參考，就可以被回收，
回收廢棄常量與回收Java堆中的物件非常類似，（關于常量的回收比較簡單，重點是類的回收）

方法區類的回收

判定一個常量是否"廢棄"還是相對簡單，而要判定一個型別是否屬于"不再被使用的類"的條件就比較苛刻了，需要同時滿足下面三個條件：

該類所有的實體都已經被回收，也就是Java堆中不存在該類及其任何派生子類的實體，
加載該類的類加載器已經被回收，這個條件除非是經過精心設計的可替換類加載器的場景，如OSGi、JSP的重加載等，否則通常是很難達成的，
該類對應的java.lang.Class物件沒有在任何地方被參考，無法在任何地方通過反射訪問該類的方法，

Java虛擬機被允許對滿足上述三個條件的無用類進行回收，這里說的僅僅是"被允許"，而并不是和物件一樣，沒有參考了就必然會回收，關于是否要對型別進行回收，HotSpot虛擬機提供了 -Xnoclassgc引數進行控制，還可以使用 -verbose:class 以及 -XX：+TraceClass-Loading、 -XX：+TraceClassUnLoading查看類加載和卸載資訊

在大量使用反射、動態代理、CGLib等位元組碼框架，動態生成JSP以及OSGi這類頻繁自定義類加載器的場景中，通常都需要Java虛擬機具備型別卸載的能力，以保證不會對方法區造成過大的記憶體壓力，

8、運行時資料區總結

執行緒私有結構：程式計數器、虛擬機堆疊、本地方法堆疊
每個虛擬機堆疊由由具體的堆疊幀組成，在堆疊幀的動態鏈接中，保存至對方法的參考
方法區在 JDK7 之前，使用永久代實作，在 JDK8 之后，使用元空間實作
Minor GC 針對于新生區，Major GC 針對于老年區，Full GC 針對于整個堆空間和方法區

9、大場面試題

百度

三面：說一下JVM記憶體模型吧，有哪些區？分別干什么的？

螞蟻金服：

Java8的記憶體分代改進
JVM記憶體分哪幾個區，每個區的作用是什么？
一面：JVM記憶體分布/記憶體結構？堆疊和堆的區別？堆的結構？為什么兩個survivor區？
二面：Eden和survior的比例分配

小米：

jvm記憶體磁區，為什么要有新生代和老年代

位元組跳動：

二面：Java的記憶體磁區
二面：講講vm運行時資料庫區
什么時候物件會進入老年代？

京東：

JVM的記憶體結構，Eden和Survivor比例，
JVM記憶體為什么要分成新生代，老年代，持久代，新生代中為什么要分為Eden和survivor，

天貓：

一面：Jvm記憶體模型以及磁區，需要詳細到每個區放什么，
一面：JVM的記憶體模型，Java8做了什么改

拼多多：

JVM記憶體分哪幾個區，每個區的作用是什么？

美團：

java記憶體分配
jvm的永久代中會發生垃圾回收嗎？
一面：jvm記憶體磁區，為什么要有新生代和老年代？

你只管學習，我來負責記筆記?? 關注公眾號！ ,更多筆記，等你來拿，謝謝

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

標籤：Java

上一篇：遠程觸發Jenkins的Pipeline任務的并發問題處理

下一篇：第 10 章物件的實體化記憶體布局與訪問定位

第 9 章 方法區

第 9 章 方法區

1、堆疊 堆 方法區的互動關系

2、方法區的理解

2.1、方法去的位置

2.2、方法區的理解

2.3、方法區演程序序

3、設定方法區大小與 OOM

3.1、JDK7 永久代

3.2、JDK8 元空間

3.3、方法區 OOM

3.4、解決 OOM

4、方法區的內部結構

4.1、方法區結構

4.2、域資訊特殊情況

4.3、運行時常量池

5、方法區的使用舉例

6、方法區演進細節

6.1、永久代演程序序

6.2、元空間出現原因

6.3、字串常量池

6.4、靜態變數位置

7、方法區的垃圾回收

8、運行時資料區總結

9、大場面試題

第 9 章方法區

第 9 章方法區

1、堆疊堆方法區的互動關系