【JVM】方法区详解

た入场券 2021-07-24 20:07 427阅读 0赞

### 文章目录 ###

*  1.栈、堆、方法区的交互关系
 *  2.方法区的理解
 *  3.设置方法区大小与OOM
 *  4.方法区的内部结构
 *   *  方法区中的运行时常量池
     *   *  常量池（字节码中的）
         *  几种在常量池内存储的数据类型包括：
         *  运行时常量池：
 *  5.方法区使用举例
 *  6.方法区的演进细节
 *   *  方法区的演进
     *  String Table为什么要调整位置？
 *  7.方法区的垃圾回收
 *  8.总结
 *  常见面试题

# 1.栈、堆、方法区的交互关系 #

运行时数据区的完整结构，其中方法区是运行时数据区的相当重要的一块内存。

![image-20201120143704887][]

从线程共享与否的角度来看

![image-20201120143836355][]

从代码层面看堆、栈、方法区的交互（配合）关系

public class Person{ 
        public static void main(String[] args){ 
            Person person = new Person();
        }
    }

![image-20201120144606182][]

看一下交互关系

![image-20201120144729330][]

# 2.方法区的理解 #

《Java虚拟机规范》中明确说明：“尽管所有的方法区在逻辑上是属于堆的一部分，但一些简单的实现不会选择去进行垃圾收集或者进行压缩。”但对于HotSpotJVM而言，方法区还有一个别名叫做Non-Heap（非堆），目的就是要和堆分开。

因此，`将方法区看作是一块独立于Java堆的内存空间。`

*  方法区（Method Area）与Java堆一样，是各个线程共享的内存区域。
 *  方法区在JVM启动的时候被创建，并且它的实际的物理内存空间中和Java堆区一样都可以是不连续的。
 *  方法区的大小，跟堆空间一样，可以选择固定大小或者可扩展
 *  方法区的大小决定可系统可以保存多少个类，如果系统定义了太多的类，导致方法区溢出，虚拟机同样会抛出内存溢出错误：java.lang.OutOfMemoryError:PermGen space或者java.lang.OutOfMemoryError:Metaspace
    
     *  怎么会导致方法区的OOM呢?
        
         *  方法区主要是存储类信息,那么当加载大量的jar包:Tomcat部署的工程过多(30-50)个;大量动态的生成反射类都会造成OOM
 *  关闭JVM会释放这个区域的内存

# 3.设置方法区大小与OOM #

方法区的大小不必是固定的，JVM可以根据应用的需要动态调整。

`JDK7及以前：`叫永久代

*  通过-XX:PermSize来设置永久代初始分配空间。默认是20.75M
 *  \-XX：MaxPermSize来设定永久代最大可分配空间。32位机器默认是64M，64位机器模式是82M。
 *  当JVM加载的类信息容量超过了这个值，会报异常OutOfMemoryError：PermGen space。

![image-20201120154455043][]

`JDK8及以后:`叫元空间

*  元数据区大小可以使用参数`-XX:MetaspaceSize`和`-XX:MaxMetaspaceSize`指定,替代上述原有的两个参数
 *  默认值依赖于平台。windows下，-XX：MetaspaceSize是21M（近似，实际上20.75多）-XX:MaxMetaspaceSize的值是-1,即没有限制
 *  与永久代不同,如果不指定大小,默认情况下,虚拟机会耗尽所有的可用系统内存.如果元数据区发生溢出,虚拟机一样会抛出异常OutOFMemoryError:Metaspace
 *  `-XX:MetaspaceSize`:设置初始的元空间大小。对于一个64位的服务器端JVM来说，其默认的`-XX:MetaspaceSize`值接近21M。这就是初始的高水位线，一旦触及这个水位线，Full GC将会被处罚并卸载没用的类（即这些类对应的类加载器不再存活），然后这个高水位线将会重置。新的高水位线的值取决于GC后释放了多少元空间。如果释放的空间不足，那么在不超过MaxMetaspaceSize时,适当提高该值。如果释放空间过多，则适当降低该值
    
     *  如果初始化的高水位线设置过低，上述高水位线调整情况会发生很多次。通过垃圾回收器的日志可以观察到Full GC多次调用。为了避免频繁地GC，建议将`-XX：MetaspaceSize`设置为一个相对较高的值。

**如何解决OOM?**

1.  要解决OOM异常或Heap space的异常,一般的手段是首先通过内存映像分析工具对dump出来的堆转储快照进行分析,重点是`确认内存中的对象是否是必要的`,也就是要分清楚到底出现了内存泄露(Memory Leak)还是内存溢出(Memory Overflow)。
2.  如果是内存泄露，可进一步通过工具查看泄露对象到GC Roots的引用链。于是就能找到泄露对象是通过怎样的路径与GC Roots相关联并导致垃圾收集器无法自动回收他们的。掌握了泄露对象的类型信息，以及GC Roots引用链的信息，就可以比较准确地定位出泄露代码的位置。
3.  如果不存在内存泄露，换句话说就是内存中的对象确实都还存活着，那就是由于虚拟机的区域的内存不足造成的OOM，此时要检查虚拟机的堆参数（-Xmx和-Xms），与机器物理内存对比按是否还可以调大一点，从代码上检查是否存在某些对象声明周期过长、持有状态时间过长的情况（比如尽量使用局部变量而不是使用成员变量），尝试减少程序运行期的内存消耗。

# 4.方法区的内部结构 #

![image-20201120192641635][]

《深入理解Java虚拟机》书中对方法区（Method Area）存储内容描述如下：

它用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存。（随着JDK的更新迭代，会发生变化）。

**类型信息**

对每个加载的类型（类class、接口interface、枚举enum、注解annotation），JVM必须在方法区中存储以下类型信息：

*  这个类型的完整有效名称（全名：包名+类名）
 *  这个类型直接父类的完整有效名（对于interface或者Object来说都是没有父类的）
 *  这个类型的修饰符（public ,abstract,final的某个子集）
 *  这个类型直接接口的一个有序列表

**域(Field)信息**

其实这里的域实际上指的就是Java中的属性

*  JVM必须在方法区中保存类型的所有域的相关信息和声明顺序。
    
     *  也就是说在Java类中我们属性声明的顺序也就决定了在字节码中的顺序，从而确定了在方法区中存储的顺序。
 *  域的相关信息包括：域名称、域类型、域修饰符（public,private,protected,static,final,volatile,transient的某个子集）

**方法(Method)的信息**

JVM中必须保存所有方法的以下信息,同域一样保存声明的顺序。

*  方法名称
 *  方法的返回地址（或void）
 *  方法参数的数量和类型（按顺序）
 *  方法的修饰符（public ,private,protected,static,final,synchronized,native,abstract中的一个）
 *  方法的字节码(bytecode)、操作数栈、局部变量表以及大小（abstract和native方法除外）
 *  异常表（abstract和native方法除外）
    
     *  异常表中包含每个异常的开始位置，结束位置，代码处理在程序计数器中的偏移地址、被捕获的异常类的常量池索引。

`实际上在方法区中还保存着加载的类的加载器。`

`而加载器也在方法区中加载,加载器中要记录该加载器都加载了哪些类`

**non-final的类变量**

*  静态变量和类关联在一起,睡着类的加载而加载,它们称为类数据在结构上的一部分。
 *  类变量被类的所有实例共享，即使没有类实例时也可以访问它。

`只是static类型和static final类型在字节码中是不同的`,在字节码中,static会加载,但是字节码没有进行显式的赋值,而static final类型的常量进行了显式赋值。

## 方法区中的运行时常量池 ##

### 常量池（字节码中的） ###

![image-20201121142517213][]

*  方法区中包含了`运行时常量池`
 *  在字节码文件中包含了`常量池`
    
     *  再次思考一下,如何查看字节码文件(反汇编)
        
         *  使用`javap命令得到相应的进程的id`
         *  使用javap -v -p Method.class
 *  类加载器将字节码文件加载到方法区的常量池就叫做运行时常量池

一个有效的字节码文件中除了包含类的版本信息、字段、方法以及接口等描述信息外，还包含一项信息那就是常量池表（Constant Poll Table），包括各种字面量和对类型、域和方法的符号引用。

**为什么需要常量池？**

一个Java源文件中的类、接口，编译后产生一个字节码文件。而Java中的字节码需要数据支持，通常这种数据会很大以至于不能直接存到字节码里，换另一种方式，可以存到常量池，这个字节码包含额指向常量池的引用。在动态链接的时候回用到运行时常量池。

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

这是一个很简单的类,实现的功能也很简单，但是里面却使用了String、System/PrintStream以及Object等结构。这里代码量比较小，如果代码量多，很可能需要引用的结构更多，我们不能在字节码中去存储使用到的所有类，而是只存储其符号引用，等到字节码真正去执行时，将符号引用转化为真正的引用对象。这就用到了常量池。

可以将常量池形象的比喻为：厨房炒菜时的调味料和食材，而将我们具体类的字节码比喻为我们要做的菜。

那么我们做不同的菜可能需要不同的食材和调味料，而这些食材和调味料都放在厨房，获取就比较方便。

### 几种在常量池内存储的数据类型包括： ###

*  数量值
 *  字符串值
 *  类引用
 *  字段引用
 *  方法引用

总结：

常量池，可以看做是一张表，虚拟机指令根据这张表找打要执行的类名、方法名、参数类型、字面量等类型。

### 运行时常量池： ###

*  运行时常量池（Runntime Constant Pool）是方法区的一部分。
 *  常量池表（Constant Pool Table）是Class文件的一部分，`用于存储编译期生成的各种字面量与符号引用`，这部分内容将在类加载后存放到方法区的运行时常量池。
 *  运行时常量池，在加载类和接口到虚拟机后，就会创建对应的运行时常量池。
 *  JVM为每个已加载的类型（类或接口）都维护一个常量池。池中的数据项像数组项一样是通过索引访问的。
 *  运行时常量池中包含多种不同的常量，包括编程期就已经明确的数值字面量，也包括到运行期解析后才能够获得的方法或者字段引用。此时不再是常量池中的符号地址了，这里转换为真实地址。
    
     *  运行时常量池，相对于Class文件常量池的另一重要特征是：具备动态性。
 *  运行时常量池类似于传统编程语言中的符号表（symbol table）,但是它所包含的数据却比符号表要更加丰富。
 *  当创建类或接口的运行时常量池时，如果构造运行时常量池所需的内存空间超过了方法区所能提供的最大值，则JVM会抛出OutOfMemooryError异常。

# 5.方法区使用举例 #

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

![image-20201121170636671][]

程序的执行过程中是相互配和的

*  将字节码文件加载到方法区的运行时常量池，存储这一些和类相关的信息。
 *  在栈的局部变量表中记录局部变量
 *  程序计数器记录下一行要执行的字节码指令的行号
 *  在操作数栈中对数据进行操作和存储临时结果

# 6.方法区的演进细节 #

*  在JDK7及以前,习惯上把方法区,称为永久代。JDK8开始元空间取代了永久代
 *  本质上方法区和永久代是不等价的。《Java虚拟机规范》中对如何实现方法区，不做统一要求。只是在HotSpot中两者可认为是等价的。

![image-20201120151332279][]

![image-20201120151347450][]

*  而到了JDK8,完全废弃了永久代的概念，因为在JDK7以及以前都是使用永久代，而永久代的内存空间也是有限的，当有大量的类信息需要加载时，就容易出现OOM问题。在JDK8及以后，使用元空间（本地内存）就不容易发生方法区的OOM。
 *  元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代最大的区别在于：`元空间不在虚拟机设置的内存中，而是使用物理内存`
 *  永久代、元空间不仅名字不同，内部结构也调整了。
 *  根据《Java虚拟机规范》的规定，如果方法区无法满足新的内存分配需求时，将抛出OOM异常。

## 方法区的演进 ##

![image-20201121171655890][]

![image-20201121171734408][]

![image-20201121171744340][]

![image-20201121171753838][]

**Java8中为什么用元空间来替换永久代呢?**

在《Java虚拟机规范中》说因为JRoctit虚拟机中没有永久代，现在Orcle公司收购了它，所以之后的虚拟机就用元空间来替换永久代。

*  随着Java8的带来，HotSpot VM中再也看不到永久代。但是并不意味着类的元数据信息也消失。这些数据被移到了一个与`堆不相连的本地内存区域,这个区域叫元空间(Metaspace)`
 *  由于类的元数据分配在本地内存中,元空间的最大可分配空间就是系统可用内存空间。

用元空间替换永久代的原因：

1.  永久代设置空间大小是很难确定的
    
     *  在某些场景下,比如web工程中,需要动态的加载大量的jar包和类,那么就可能会出现OOM问题。
2.  对于永久代进行调优是很苦难的。
    
     *  当永久代满，就需要发生GC，而永久代的GC可能会发生较长时间STW，那么就是损失性能的。

## String Table为什么要调整位置？ ##

从JDK的演进中发现在JDK7中我们将String Table放在了堆内存中，之前一直是放在永久代（方法区的），并且在后续的版本中，字符串常量一直放在了堆内存中。这是为什么呢？

JDK7中将StringTable放到了堆空间中。因为永久代的回收效率很低，在full GC的时候才触发（虽然说我们也不太愿意看到经常的看到Full GC）。而Full GC只有在老年代空间不足或者永久代空间不足的时候才会触发。

这就导致StringTable回收效率不高。而在开发中创建的大量的字符串就得不到及时的回收，导致永久代内存不足。放到堆里，能及时的回收。

# 7.方法区的垃圾回收 #

方法区的垃圾回收的目标主要包括：**常量池中废弃的常量和不再使用的类型。**

# 8.总结 #

**运行时数据区的详细结果**

![image-20201121204618894][]

# 常见面试题 #

百度：

*  三面：说一下JVM内存模型吧，有哪些区？分别干什么？

蚂蚁金服：

*  Java8的内存分代改进
 *  JVM内存分哪几个区？每个区的作用？
 *  一面：JVM内存分布、内存结构？栈和堆的区别？堆的结构？为什么两个survivor区？
 *  二面：Eden和Survivor的比例分配

小米：

*  JCM内存分区，为什么要有新生代和老生代

字节跳动：

*  二面：Java的内存分区
 *  讲讲JVM运行时数据区
 *  什么时候对象会进入老年代？

京东：

*  JVM的内存结构，Eden和Survior的比例
 *  JVM内存为什么要分成新生代，老生代，持久代。新生代中为什么要分成Eden和Survivor

天猫：

*  一面：JVM内存模型以及分区，需要详细到每个区放什么
 *  JVM的内存模型，Java8做了什么修改

拼多多

*  JVM内存分为哪几个区？每个区的作用？

美团：

*  java内存分配
 *  JVM的永久代中会发生垃圾回收吗？
 *  JVM内存分区，为什么要有新生代和老生代

跳动：

*  二面：Java的内存分区
 *  讲讲JVM运行时数据区
 *  什么时候对象会进入老年代？

京东：

*  JVM的内存结构，Eden和Survior的比例
 *  JVM内存为什么要分成新生代，老生代，持久代。新生代中为什么要分成Eden和Survivor

天猫：

*  一面：JVM内存模型以及分区，需要详细到每个区放什么
 *  JVM的内存模型，Java8做了什么修改

拼多多

*  JVM内存分为哪几个区？每个区的作用？

美团：

*  java内存分配
 *  JVM的永久代中会发生垃圾回收吗？
 *  JVM内存分区，为什么要有新生代和老生代

> 题外:  
> `种一颗树最好的时间是在十年前，其次是现在。`

[image-20201120143704887]: /images/20210724/c635f7c577164a588d659cd0a1f567b1.png
[image-20201120143836355]: /images/20210724/6a7f11962d614cfba6be15eb958e3b96.png
[image-20201120144606182]: /images/20210724/7ec226724ebd4d8e93cabdff4bbaf747.png
[image-20201120144729330]: /images/20210724/303eda32e14d4263b737a860da1ef868.png
[image-20201120154455043]: /images/20210724/76448420044d44acb3d42f72cc7203e2.png
[image-20201120192641635]: /images/20210724/a8bea9cacae948dcbae274deada3093b.png
[image-20201121142517213]: /images/20210724/4ac5a2b5c60544baafe27ac506b1bbc2.png
[image-20201121170636671]: /images/20210724/2f1516b7dc7f4f42b668b66fbf082f51.png
[image-20201120151332279]: /images/20210724/6955e59d0ee54dca9edf05e751f8219d.png
[image-20201120151347450]: /images/20210724/5a4afe3150bc4605a3b3e1e1a1b5659b.png
[image-20201121171655890]: /images/20210724/ad84d7fd26864faaa0395d3d2b0a9bac.png
[image-20201121171734408]: /images/20210724/364757a2f8dd45f4a9b6f3c2d8ff994f.png
[image-20201121171744340]: /images/20210724/a56a4c34b02e44b0a760d9ccdb4a95eb.png
[image-20201121171753838]: /images/20210724/354ea7a434074954b8c35811cea3d227.png
[image-20201121204618894]: /images/20210724/ffe389a278754ab2ab1da6cf24f571b9.png